Posts Tagged: Bit9


4
Feb 14

These Guys Battled BlackPOS at a Retailer

Ever since news broke that thieves stole more than 40 million debit and credit card accounts from Target using a strain of Point-Of-Sale malware known as BlackPOS, much speculation has swirled around unanswered questions, such as how this malware was introduced into the network, and what mechanisms were used to infect thousands of Target’s cash registers.

BLACKPOS copyRecently, I spoke at length with  Tom Arnold and Paul Guthrie, co-founders of PSC, a security firm that consults for businesses on payment security and compliance. In early 2013, these two experts worked directly on a retail data breach that involved a version of BlackPOS. They agreed to talk about their knowledge of this malware, and how the attackers worked to defeat the security of the retail client (not named in this story).

While some of this discussion may be geektacular at times (what I affectionately like to call “Geek Factor 5″), there’s something in here for everyone. Their observations about the methods and approaches used in this attack point to an adversary that is skilled, organized, patient and thorough.

So you first saw BlackPOS at a retailer in early January 2013?

Tom: Yes, it did seem like a game changer at that point because of the way it hooked into the POS system. By that I mean the fact that it hooks into the POS process, and it’s not just a general memory scraper like some people have stated.

Help me understand the distinction between a memory scraper and malware that runs completely in memory?

Tom: Well, it’s very specific. It’s what’s called an inter-process communications hook. If you look at a memory scraper — so if you were to dump the memory on your laptop right now — you would get this big old blob of information and you would have to filter through it to find what you’re looking for. But this [malware] is very specific: It’s very much designed for the POS system it’s running on, because it knows exactly where to hook and where the memory location is going to be when the data it’s looking for is flowing through it. But if you look at what it captures, it captures only the track data [information stored on the magnetic strip on the backs of cards]. So, it’s actually very, very sophisticated and that’s why I think this isn’t just a teenage hacker who put this together in his basement. I think this is a more sophisticated development effort. [HP last week published some interesting, uber-geeky details about the memory behavior of the version of BlackPOS found at Target].

Paul:  It certainly hooks into a specific process, but we did not figure out if it was just good at scraping the memory of that process, or whether it actually altered the process to hook into the code somehow.  That part of the code was obfuscated and not reviewed during the engagement.

What did you think of the iSight paper?

Tom: The iSight paper was good, and what it described was very similar to what we saw in the first variants of BlackPOS. But it didn’t talk about how it appeared on the network or where it came from or how a retailer might defend themselves against it.

In your prior experience with BlackPOS, has it been used against the same POS that Target uses? A source who seemed to have a clue told me that their setup was somewhat homegrown.

Tom: That I don’t know.  I haven’t really looked at what Target uses. With a homegrown system, the problem is if you’re going to build a process hook, you have to have a test environment, you have to know what you’re looking at and what memory addresses to go after, and that’s not exactly something that gets published.

Paul: Target has a homegrown POS.

So you think it’s likely they were using some off-the-shelf equipment and software? Wouldn’t it be enough for the attackers in this case to have obtained a physical point of sale device that was once used at Target?

Tom: If they have one, sure, that would be different. I don’t know if they’re using a commercial product. A lot of the big retailers use commercial products and will customize those with their back end system. But at the front end and what happens at front of the house…a lot of those are just retail off-the-shelf applications. A lot of those retailers, when you have a hard disk that breaks on one of the [checkout] lanes, they’ve got an outsourced service provider of that POS that comes out there with a new hard disk and fixes it.

How do the bad guys break in, and how do they actually get the malware pushed out to the point-of-sale?

Tom:  A lot of the POS systems use whitelisting software of some kind, such as Bit9 or SolidCore. Those two companies are the two you see most out there in the industry.

Paul: It could also come in through the point-of-sale application update process.

By whitelisting, you mean sort of the opposite approach of antivirus, right? As in, if the file or program isn’t approved by the whitelisting software, it simply won’t run on the system?

Tom: The software update processes at a point-of-sale that is running one of those [whitelisting applications] has to come through one of the software update channels and has to be reviewed for the update and approved. And when it’s approved, the whitelisting software says okay this patch is approved to come online.

It’s probably a good idea at this point to make sure we’re defining the terminology in a uniform way. When you think of point-of-sale device, are you talking about the cash register, or the card swipe terminal, or…

Tom: I’m using point-of-sale to mean the payment application that is running on the cash register. The vast majority of those devices, when you check out at the grocery store or large retailer, those are just PCs, and yes they’re mostly running Windows XP or WEPOS as their operating system. But above that, you have what I call the point-of-sale, or the point-of-sale application, and that’s the stuff that the cashier is interfacing with at the time you’re checking out. It’s a software application, running as multiple pieces of software inside the register itself. And whitelisting is put on to protect the register from any sort of unsolicited modification. A lot of the attacks before this [whitelisting became more broadly used] involved where you corrupt a sales clerk to put a USB stick in the cash register and infect the PC with some malware. But by using a whitelisting software, the USB stick will not work and the operations personnel back in the head office will get notified that something isn’t right with that register.

If they get past a whitelisting system, doesn’t that suggest that someone on the inside would have to be involved?

Tom: No, not really. You have to also consider the distribution server that distributes the point-of-sale software.

Paul: Right… three possible ways… it could come through a legitimate update channel, or the retailer was lax in their update procedures, or the attackers hacked the console of the whitelisting software and just whitelisted it themselves.  

Continue reading →


20
Feb 13

Bit9 Breach Began in July 2012

Malware Found Matches Code Used Vs. Defense Contractors in 2012

Cyber espionage hackers who broke into security firm Bit9 initially breached the company’s defenses in July 2012, according to evidence being gathered by security experts investigating the incident. Bit9 remains reluctant to name customers that were impacted by the intrusion, but the custom-made malicious software used in the attack was deployed last year in highly targeted attacks against U.S. Defense contractors.

bit9Earlier this month, KrebsOnSecurity broke the story of the breach at Waltham, Mass.-based Bit9, which involved the theft of one of the firm’s private digital certificates. That certificate was used to sign malicious software, or “malware” that was then sent to three of the company’s customers. Unlike antivirus software, which tries to identify and block known malicious files, Bit9’s approach helps organizations block files that aren’t already digitally signed by the company’s own certificates.

After publishing a couple of blog posts about the incident, Bit9 shared with several antivirus vendors the “hashes” or unique fingerprints of some 33 files that hackers had signed with the stolen certificate. KrebsOnSecurity obtained a list of these hashes, and was able to locate two malicious files that matched those hashes using Virustotal.com — a searchable service and database that lets users submit suspicious files for simultaneous scanning by dozens of antivirus tools.

The first match turned up a file called “media.exe,” which according to Virustotal was compiled and then signed using Bit9’s certificate on July 13, 2012. The other result was a Microsoft driver file for an SQL database server, which was compiled and signed by Bit9’s cert on July 25, 2012.

Asked about these findings, Bit9 confirmed that the breach appears to have started last summer with the compromise of an Internet-facing Web server, via an SQL injection attack. Such attacks take advantage of weak server configurations to inject malicious code into the database behind the public-facing Web server.

In an exclusive interview with KrebsOnSecurity, Bit9 said it first learned of the breach on Jan. 29, 2013, when it was alerted by a third party which was not a customer of Bit9. The company believes that the trouble began last July, when an employee started up a virtual machine that was equipped with an older Bit9 signing certificate which hadn’t been actively used to sign files since January 2012.

Harry Sverdlove, Bit9’s chief technology officer, said the company plans to share more details about its investigation into the intrusion in a post to be published Thursday on Bit9’s blog. For instance, he said, the control server used to coordinate the activities of the malware sent by the attackers traced back to a server in Taiwan.

Sverdlove said Bit9 will not reveal the identities of the customers that were apparently the true target of the breach; he would only characterize them as “three non-critical infrastructure entities.” Sverdlove said although it is clear now that Bit9 was hacked as a jumping-off point from which to launch more stealthily attacks against a handful of its customers, that reality hardly softens the blow.

“Although it doesn’t make us feel any better, this wasn’t a campaign against us, it was a campaign using us,” Sverdlove said. “We don’t take any solace in this, but the good news is they came after us because they weren’t able to come after our customers directly.”

It’s not clear why the attackers waited so long to use the stolen certs, but in any case Bit9 says the unauthorized virtual machine remained offline from August through December, and was only turned on again in early January 2013.

Continue reading →


8
Feb 13

Security Firm Bit9 Hacked, Used to Spread Malware

Bit9, a company that provides software and network security services to the U.S. government and at least 30 Fortune 100 firms, has suffered an electronic compromise that cuts to the core of its business: helping clients distinguish known “safe” files from computer viruses and other malicious software.

bit9Waltham, Massachusetts-based Bit9 is a leading provider of “application whitelisting” services, a security technology that turns the traditional approach to fighting malware on its head. Antivirus software, for example, seeks to identify and quarantine files that are known bad or strongly suspected of being malicious. In contrast, Bit9 specializes in helping companies develop custom lists of software that they want to allow employees to run, and to treat all other applications as potentially unknown and dangerous.

But earlier today, Bit9 told a source for KrebsOnSecurity that their corporate networks had been breached by a cyberattack. According to the source, Bit9 said they’d received reports that some customers had discovered malware inside of their own Bit9-protected networks, malware that was digitally signed by Bit9’s own encryption keys.

That last bit is extremely important, because Bit9 is a default trusted publisher in their software, which runs on customer PCs and networks as an “agent” that tries to intercept and block applications that are not on the approved whitelist. The upshot of the intrusion is that with a whitelist policy applied to a machine, that machine will blindly trust and run anything signed by Bit9.

An hour after being contacted by KrebsOnSecurity, Bit9 published a blog post acknowledging a break-in. The company said attackers managed to compromise some of Bit9’s systems that were not protected by the company’s own software. Once inside, the firm said, attackers were able to steal Bit9’s secret code-signing certificates.

“Due to an operational oversight within Bit9, we failed to install our own product on a handful of computers within our network,” Bit9’s Patrick Morley wrote. “As a result, a malicious third party was able to illegally gain temporary access to one of our digital code-signing certificates that they then used to illegitimately sign malware. There is no indication that this was the result of an issue with our product.  Our investigation also shows that our product was not compromised.”

The company said it is still investigating the source of the breach, but said that it appears that at least three of its customers were sent malware that was digitally signed with Bit9’s certificate.

Continue reading →


18
Nov 10

Why Counting Flaws is Flawed

Once or twice each year, some security company trots out a “study” that counts the number of vulnerabilities that were found and fixed in widely used software products over a given period and then pronounces the worst offenders in a Top 10 list that is supposed to tell us something useful about the relative security of these programs. And nearly without fail, the security press parrots this information as if it were newsworthy.

The reality is that these types of vulnerability count reports — like the one issued this week by application whitelisting firm Bit9 — seek to measure a complex, multi-faceted problem from a single dimension. It’s a bit like trying gauge the relative quality of different Swiss cheese brands by comparing the number of holes in each: The result offers almost no insight into the quality and integrity of the overall product, and in all likelihood leads to erroneous and — even humorous — conclusions.

The Bit9 report is more notable for what it fails to measure than for what it does, which is precious little: The applications included in its 2010 “Dirty Dozen” Top Vulnerable Applications list had to:

  • Be legitimate, non-malicious applications;
  • Have at least one critical vulnerability that was reported between Jan. 1, 2010 and Oct. 21, 2010; and
  • Be assigned a severity rating of high (between 7 and 10 on a 10-point scale in which 10 is the most severe).

The report did not seek to answer any of the questions that help inform how concerned we should be about these vulnerabilities, such as:

  • Was the vulnerability discovered in-house — or was the vendor first alerted to the flaw by external researchers (or attackers)?
  • How long after being initially notified or discovering the flaw did it take each vendor to fix the problem?
  • Which products had the broadest window of vulnerability, from notification to patch?
  • How many of the vulnerabilities were exploitable using code that was publicly available at the time the vendor patched the problem?
  • How many of the vulnerabilities were being actively exploited at the time the vendor issued a patch?
  • Which vendors make use of auto-update capabilities? For those vendors that include auto-update capabilities, how long does it take “n” percentage of customers to be updated to the latest, patched version?

Continue reading →