Attacks/Breaches
1/14/2014
01:05 PM
Connect Directly
RSS
E-Mail
50%
50%

Target Breach: 8 Facts On Memory-Scraping Malware

Target confirmed that malware compromised its point-of-sale systems. How does such malware work, and how can businesses prevent infections?

4. US-CERT hint: Dexter, Stardust RAM malware. What particular type of malware was used to attack Target or Neiman Marcus? So far, both retailers have declined to answer that question. But on January 2, 2014 -- roughly two weeks after Target confirmed that it had been breached, and one day after Neiman Marcus confirmed that it had been breached -- the US Computer Emergency Readiness Team (US-CERT) released a memory-scraping malware alert aimed at retailers.

In particular, the US-CERT alert named two types of malware that are designed to dump POS memory or intercept credit card data being transmitted on internal networks. "Dexter, for example, parses memory dumps of specific POS software-related processes looking for Track 1 and Track 2 data," it said. "Stardust, a variant of Dexter, not only extracts the same track data from system memory, it also extracts the same type of information from internal network traffic."

5. Likely attack vectors. How do attackers infect POS systems with malware? To answer that question, it helps to understand that POS devices are network-connected, and thus any system that touches that network might be an infiltration point. Likewise, unsecured wireless networks may also give attackers an entry point.

That's why POS devices are vulnerable to phishing attacks, as long as attackers can get their malware to jump from an infected PC to POS devices. Attackers might also hack their way into the production network -- perhaps by using weak default credentials in remote-desktop or remote-access software, or by exploiting known vulnerabilities in Internet-facing servers.

Since the attack against Target compromised personal information on 70 million customers -- beyond the 40 million credit and debit cards that were also compromised -- it suggests that attackers didn't just sneak malware onto POS devices, they also gained direct access to servers or Internet-connected databases of customer information, since that's where that type of customer data would have been stored.

6. POS malware is easy to hide. If attackers gain access to the production network to which POS devices are connected, detecting or intercepting related malware-dropping attacks aimed at those POS devices may be quite difficult to detect. That's because attackers can use antivirus evasion techniques or packing tools to give the malware executable a never-before-seen checksum. "Most of the time the code that most malware-scrapers use can be detected, but unfortunately, you can just apply encryption or antivirus-evasion tools to bypass that detection," said RSA's Elisan.

7. POS network must be secured. How can retailers block attacks that aim to sneak malware onto POS devices? The US-CERT warning recommends these six best-practices: use strong passwords to access POS devices, keep POS software up to date, use firewalls to isolate the POS production network from other networks or the Internet, employ antivirus tools, limit access to the Internet from the production network, and disable all remote access to POS systems.

That's a good start, but businesses must also pay careful attention to the security hygiene of the POS-related production network, and beware the threat that an infected laptop or desktop might be allowed to connect to that network. "You can have different firewalls installed, but if you introduce a compromised system into the network -- instead of using a protected server to serve all of the updates to the POS -- that could possibly be the infection vector that the malware needs to get into the system," said Elisan.

8. Can POS device security be verified? Once malware does successfully infect a POS device, shouldn't retailers such as Target be able to spot that the checksum associated with the POS system's disk image has changed? That's a pertinent question after Target's admission that its POS systems were infected with malware.

"It suggests that Target may have dropped the ball somewhat, not only in terms of verifying those devices but verifying that the image on those devices hasn't changed," said Cluley. "Even if you can't detect a specific piece of malware, could they not detect that something could have been fiddled with or changed?"

But Elisan said he's not aware of these types of security checks being employed, at least by large retailers. "For a big company that has, say, 100,000 systems, I'm not so sure if that's really being practiced," he said. "Most of the time there's this false sense of security that POS systems won't get infected, because they're seen as being isolated."

Mathew Schwartz is a freelance writer, editor, and photographer, as well the InformationWeek information security reporter.

The complexity of enterprise IT systems and processes is growing, as are threats against organizations’ assets. Unfortunately, security budgets are not. Security pros must therefore play a high-stakes game of figuring out which problems to tackle and in what order. In this Dark Reading report, Using Risk Assessment To Prioritize Security Tasks And Processes, we explain how risk assessment techniques can inform the process of prioritizing security tasks and processes, and recommend steps security pros can take to apply data based on their own enterprise's risk profile. (Free registration required.)

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Mark Sitkowski
50%
50%
Mark Sitkowski,
User Rank: Moderator
1/16/2014 | 6:28:29 PM
Target Breach
I posted this against another article, but I think it's important enough to repeat here.

Before the hackers damage another retailer, let me suggest a way of preventing this happening again. The benefit of this solution, originall designed for internet purchasing, is that it saves the credit card companies from having to invest in expensive EMV cards and, as a side benefit, a lost or stolen card will be useless to the thief. Also, very little modification needs to be made to the POS terminal. Further, the customer never sends his credit card details to the retailer, and the retailer's transaction records contain no usable information.
1. Remove all data from the credit card and its magnetic stripe, except for a simple User ID and, perhaps, the expiry date.
2. The credit card company installs a fraudproof authentication system, as described in www.designsim.com.au/What_is_SteelPlatez.ppsx, in its data centre.
3. The customer and retailer have accounts on the authentication system.
4. When the customer needs to make a purchase, he logs in to the authentication system belonging to the appropriate credit card company, giving his user ID and the amount of the purchase.
5. The retailer also logs in to the system, giving his merchant number, or User ID, and the customer's User ID (taken from the POS in use)
6. The credit card company knows the user's card number, so if he's been authenticated, it checks for a match with the retailer's submission.
7. If there's a match, it performs the usual checks for limits, expiry etc, issues an approval, pays the retailer etc.
Simple
PaulS681
50%
50%
PaulS681,
User Rank: Apprentice
1/15/2014 | 7:30:13 PM
Re: Another reason...
 

Interesting concept. Paying with cash would make these POS machines obsolete however hackers would probably focus their efforts on financial institutions and hack you that way. I say that in jest as cards are not going away anytime soon but you make a good point.
Mathew
50%
50%
Mathew,
User Rank: Apprentice
1/15/2014 | 7:11:53 AM
Re: Another reason...
Indeed. The convenience factor of using a debit/credit card would also be offset by having to carefully review one's statement online every 24-48 hours for signs of abuse.
Thomas Claburn
50%
50%
Thomas Claburn,
User Rank: Moderator
1/14/2014 | 8:18:24 PM
Another reason...
...to pay with cash. I wonder what the relative risk of being robbed is compared to the risk of being hacked.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5619
Published: 2014-09-29
The Sleuth Kit (TSK) 4.0.1 does not properly handle "." (dotfile) file system entries in FAT file systems and other file systems for which . is not a reserved name, which allows local users to hide activities it more difficult to conduct forensics activities, as demonstrated by Flame.

CVE-2012-5621
Published: 2014-09-29
lib/engine/components/opal/opal-call.cpp in ekiga before 4.0.0 allows remote attackers to cause a denial of service (crash) via an OPAL connection with a party name that contains invalid UTF-8 strings.

CVE-2012-6107
Published: 2014-09-29
Apache Axis2/C does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

CVE-2012-6110
Published: 2014-09-29
bcron-exec in bcron before 0.10 does not close file descriptors associated with temporary files when running a cron job, which allows local users to modify job files and send spam messages by accessing an open file descriptor.

CVE-2013-1874
Published: 2014-09-29
Untrusted search path vulnerability in csi in Chicken before 4.8.2 allows local users to execute arbitrary code via a Trojan horse .csirc in the current working directory.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.