Nearly four months after it first reported it was investigating a data breach, the arts and crafts retail chain Michaels confirmed yesterday that most of its U.S. stores were compromised on and off for eight months and that payment card information of nearly three million of its customers may have been impacted.
The company operates more than 1000 stores across the United States and nearly all of them were breached, although the attack has been “fully contained” by now. According to a press release yesterday however, 2.6 million cards used at Michaels’ limited point-of-sale systems between May 8, 2013 and January 27, 2014, may have been compromised in the breach.
While some stores were only targeted once, others were targeted up to four different times, some for multiple months at a time, the longest gap spanning from May to October last year.
A lengthy 45-page document (.PDF) posted by the company yesterday runs down each store that was affected – more than 1,000 are listed – and how long users were exposed at each one.
Michaels downplayed the issue by pointing out that the number of affected cards only translates to roughly seven percent of payment cards used at its stores over the course of that time period.
As the point of sale systems contained information like customers’ credit or debit card numbers and expiration dates, they are the primary bits of information considered to have been compromised in the breach. The company insists however that customers’ names, addresses or PINs do not appear to have been breached at this time.
As many as 400,000 additional cards also appear to have been implicated in a separate breach that affected one of the company’s subsidiaries, the specialty framing and art supply chain Aaron Brothers. The same malware plagued 53 different Aaron Brothers stores (.PDF) between June 26, 2013 and February 27, 2014, mostly in California but also in Arizona, Washington, Oregon, Nevada, Colorado and Texas.
The news comes four months after the Irving, Texas, company announced it was investigating a potential data breach. Since then the company says it hired two security firms who were able to work in tandem with law enforcement, banks and payment processors to look into the issue.
While officials noticed the attack and were able to contain it at Michaels in late January it appears the attack at Aaron Brothers slipped by them, as malware continued to plague systems at those stores for another month afterwards, deep into February.
While similar, the Michaels data breach pales in comparison to this past winter’s Target attack, which affected the sensitive credit card information of over 40 million users. Like the Michaels attack, the Target attack, which came to light shortly before the new year, relied on hackers infecting the retail giant’s point of sale terminals with RAM scraper malware for several weeks, from Thanksgiving to mid-December last year.
In a blog post earlier this month experts at HP pointed out that while there has been an influx of retail credit card breaches – Target, Michaels, Sally Beauty Supply, etc. – there’s still no easy way to counteract these types of attacks since there’s only so many limits to what you can do with magnetic stripe technology.
“Memory scraping has become the new trend, but there is no easy way to defend against this technique as the magnetic stripe information is decrypted at some point,” Matt Oh, a Senior Malware Researcher with HP, pointed out. “This limitation with magnetic stripe technology and the history of cat and mouse between the credit card industry and the criminals tells us that it is time to adopt a new technology.”
*Michaels image via coolmikeoh‘s Flickr photostream, Creative Commons
A number of ICS products from Siemens and Innominate are vulnerable to the OpenSSL heartbleed flaw, some of which do not have updates available yet.
The list of products affected by the heartbleed vulnerability continues to grow by the day, with OpenVPN being one of the latest. A researcher on Friday said that he was able to extract a private key from a vulnerable OpenVPN server after hitting it with a large volume of requests over the course of several hours.
Now, the ICS-CERT has issued an advisory warning that several products from Siemens and one from Innominate are vulnerable to the heartbleed attack. The mGuard firmware from Innominate, versions 8.0.0 and 8.0.1 are vulnerable to the attack, but the company has issued an update that addresses the flaw.
Meanwhile, Siemens has identified a number of its products that contain the heartbleed vulnerability. The list of vulnerable products include:
- eLAN-8.2 eLAN prior to 8.3.3 (affected when RIP is used – update available)
- WinCC OA only V3.12 (always affected)
- S7-1500 V1.5 (affected when HTTPS active)
- CP1543-1 V1.1 (affected when FTPS active)
- APE 2.0 (affected when SSL/TLS component is used in customer implementation).
“A successful “HeartBleed” exploit of the affected products by an attacker with network access could allow attackers to read sensitive data (to include private keys and user credentials) from the process memory,” the advisory says.
By some estimates, OpenSSL is deployed on more than half of the SSL-protected Web servers worldwide, but that’s just one piece of the puzzle. The library also is used in embedded devices, industrial control systems and other systems, some of which are just coming to light now.
You can add OpenVPN to the growing list of products and services vulnerable to the Heartbleed OpenSSL vulnerability. Worse, researchers have been able to chain together exploits to steal private keys from traffic moving through the open source virtual private network software package.
A Swedish VPN company called Mullvad reported its findings to OpenVPN this week, which quickly urged users to update their OpenSSL library, revoke old private keys, generate new ones and create new certificates for the new private keys.
This process is going on worldwide for companies and Web-based services vulnerable to the bug in the OpenSSL crypto library’s heartbeat functionality. The bug returns 64KB of memory to any client or server making a request; if the pings are made often enough, an attacker could see in plaintext anything from user credentials to enough data to piece together a private SSL key.
Fredrik Stromberg, cofounder of Mullvad, said his company was able to extract “private key material” using a known Heartbleed proof-of-concept exploit. Stromberg told Threatpost that attacks against OpenVPN are a little more complicated because TLS session traffic is wrapped inside the OpenVPN protocol. Stromberg had to write a script that cracked the OpenVPN protocol and then used a Heartbleed exploit to dump memory similar to other attacks against Web servers, for example.
“What I did was I left it continuously running overnight pounding on my test server,” Stromberg said. “When I woke up in the morning, let’s say I had more than 1GB and less than 10GB in memory dumps, and found enough key material to reproduce a key.”
Stromberg joins a growing list of security researchers who have been able to extract private keys via Heartbleed exploits—a worst-case scenario. Most of the previous success stories were achieved through the CloudFlare Challenge against a purpose-built Web server. This is the first successful attempt against VPN software.“I can tell you the actual exploitation part is exactly the same as against TLS on a web server or email server,” Stromberg said.
“You need to know how the VPN works, but this specification is open. It’s a little more advanced than a normal Heartbleed exploit, but not very hard if you’re a competent programmer.”
OpenVPN acknowledged Stromberg’s findings and replacing the keys for each peer that was active while linked against a vulnerable OpenSSL session, its advisory said. Mullvad offers a secure OpenVPN connection for its clients for a monthly fee. Stromberg said his Heartbleed test against OpenVPN was part of due diligence for his customer base.
As far as a fix goes, VPN providers must go a step beyond patching servers, revoking certs and reissuing new ones and manually send a certificate revocation list to users and browser makers so that they won’t be accepted going forward.
“If you do not do that, you will still be vulnerable to man-in-the-middle attacks if someone sets that up,” Stromberg said. “It would be easy to impersonate a server.”
Stromberg noted in an email to OpenVPN that the TLS-auth feature in the software marginally protects against Heartbleed to the extent that the HMAC key used to authenticate packets that are part of a TLS handshake is kept secret.
“This means that while a small business may benefit from using tls-auth because only the employees have access to the key, a public VPN service such as ours does not, because anyone who is a customer has access to the key.”
SAN FRANCISCO–The problem of critical infrastructure security has become a key issue in the last few years, as high-profile attacks such as Stuxnet and others have grabbed headlines and alerted politicians and others to the weaknesses facing these vital systems. It’s an issue that Eugene Kaspersky has been thinking about for a long time, and isn’t sure that the organizations running these systems are any closer to addressing these threats than they were several years ago.
As with many other things in technology, there’s a lot of disagreement in the industry about critical infrastructure and SCADA security issues, even over what exactly qualifies as critical infrastructure. The term often is applied to the systems that run things such as utilities, power grids, transportation systems and the like, and the networks and systems they control typically use arcane software. Many of those software packages haven’t been subjected to the kind of security testing an scrutiny that typical commercial software has, and the process of patching and updating them is difficult and laborious.
The fragile nature of these systems has raised the concerns of security researchers, policymakers and others, and led to calls for regulation and standardization for security. What’s unclear in all of this is who or what entity should be involved in the creation of any standards. Should it be an international effort? Who should lead it?
Kaspersky, the CEO of Kaspersky Lab, said during an interview at the company’s Cyber Security Summit here, that he has little faith in any international push to develop such standards.“I vote for less regulation in technology and innovation,” he said.
“The older I am, the less and less I believe in international projects. Let the nations do it themselves, and they can be an example for the rest of the world. I think the United States will be first and then the rest of the world can copy and paste.”
A big issue in the SCADA and critical infrastructure security world when it comes to regulation and standards is that in most countries, the government doesn’t own any of these systems; they’re all in the hands of private companies. Tom Ridge, the former secretary of the Department of Homeland Security and former governor of Pennsylvania, said during a keynote at the summit Tuesday that, at least in the United States, that presents a major obstacle.
“The government has no critical infrastructure of its own. It relies on the private sector for that, and when it goes down, the government goes down,” Ridge said. “National security and economic security are intertwined.”
The critical infrastructure networks in the U.S. are prime targets for attackers, as is the case in other countries, but Kaspersky said the U.S. likely is at the top of the target list for skilled attackers.
“It’s very difficult to compare who is better protected. The U.S. is the most developed IT country in the world,” he said. “It has many more SCADA systems than any other country, so the U.S. is the biggest target. But it also has the most resources. So which nation is better protected, the one with all of the systems and resources or the one with fewer systems and is a smaller target?”
The bad news is that attackers likely won’t discriminate. Attackers take what they can get, usually regardless of geographic location or ownership. But Kaspersky said he has confidence that the market ultimately will provide an answer to the problem of critical infrastructure security.
“If you have many competing companies there’s much more chance that one of these will come up with something innovative. I vote for competition. I believe in a world that has independent and competing businesses,” he said. “There’s a much better chance that the right answer will be found much faster.”
Researchers published a video this week demonstrating how Samsung’s latest entry in the smartphone arena, the Galaxy S5, is vulnerable to a hack that involves lifting and copying fingerprints to trick the phone’s biometric sensor.
Much like the Apple iPhone 5S, the smartphone, which first hit the market last week, boasts a fingerprint scanner as an added layer of security.
Now the same research outfit that was able to hack the iPhone’s 5S’s Touch ID feature last year, Germany’s Security Research Labs (SRLabs), has managed to bypass a similar feature on the Galaxy S5. Like the iPhone hack the Galaxy hack relies on the attackers using a mold of a fingerprint; or in this case a lab-manufactured wood glue replica of a print, to carry out their attack.
In a video posted Tuesday the researchers claim their method allows for “seemingly unlimited authentication attempts without ever requiring a password.”
While this may sound like a pretty farfetched exploit vector – a user would have to have the Finger Scanner set up on this exact brand of phone and an attacker would have to go through the trouble of creating the fingerprint replica – as the folks from SRLabs note, it could have implications for those who use the new fingerprint scan feature on PayPal’s Android app.
That app allows users to transfer funds using their fingerprint as a biometric authenticator, meaning that if an attacker had access to your phone, and one of these fingerprint molds, they’d be able to make purchases and unsolicited money transfers from the account.
In the video the researchers demonstrate how an attacker could wire himself money via PayPal from a person’s debit account. Using the fingerprint replica it takes three swipes for PayPal to recognize the bogus fingerprint, but according to the researcher, attackers could be allowed “multiple attempts to make a successful swipe with this spoof.”
In a statement released by the company this week PayPal downplayed the issue, claiming they were taking SRLabs’ findings seriously but were confident that its app is still “easier and more secure” than using passwords or credit cards. PayPal added that it could simply deactivate cryptographic keys associated with fingerprints on accounts from lost or stolen devices and allow users to make a new one.
The company added that in the unlikely occurrence that one of its users gets duped by an attacker with one of these phony fingerprint scans, it will reimburse any losses they incur.
To use the S5’s fingerprint scanner, the phone requires users to swipe a finger eight times over the home button. The user can then use that fingerprint to lock their screen, verify their Samsung account or authenticate their PayPal account.
A number of critics have been vocal against using fingerprints as a biometric authentication measure for years now. Some of those voices, including researchers from the Chaos Computer Club (CCC) and SRLabs, have pointed out that whenever a fingerprint gets stolen, there’s no way to change it and that it’s easy to lift users’ fingerprints off of items, including their personal devices.
Still though, fingerprint spoofs, known in some circles as ‘fake fingers’ are not easy to produce. CCC hacker Starbug, who was famously the first to break Apple’s TouchID last fall, used a high resolution image of a fingerprint with latex to produce his.
“This demonstrates—again—that fingerprint biometrics is unsuitable as [an] access control method and should be avoided,” the CCC said in September.
The after effects of the OpenSSL heartbleed vulnerability continue to spread through the technology industry, nearly two weeks after the details of the flaw were disclosed. One of the latest repercussions is a huge increase in the number of SSL certificates being revoked, as site owners and hosting providers go through the process of replacing vulnerable certificates.
Certificate authorities and other organizations maintain certificate revocation lists that browsers can use to determine whether a certificate on a given site has been revoked. Site owners will revoke certificates for a number of reasons, including security problems. Those revocations typically go unnoticed, unless a high-profile site is involved or there’s some event that causes a large number of sites to need to replace their certificates.
Enter heartbleed.In the last few days, there has been a tremendous spike in the volume of certificate revocations.
A good portion of that increase–which saw revocations go from perhaps a few thousand a day to more than 70,000 earlier this month–can be attributed to CloudFlare replacing all of the certificates for sites that it manages. The company was one of the few organizations that got early warning about the OpenSSL bug before the software’s maintainers revealed the details.
“After learning the full extent of the bug and that it had been live on the Internet for two years, we started an investigation to see whether our private keys and those of our customers were at risk,” Nick Sullivan of CloudFlare wrote in a blog post.
“We started our investigation by attempting to see what sort of information we could get through Heartbleed. We set up a test server on a local machine and bombarded it with Heartbleed attacks, saving the blocks of memory it returned. We scanned that memory for copies of the private key and after extensive scanning, we could not find a trace of it.”
CloudFlare then issued a public challenge, asking researchers to see whether they could get the private key from a vulnerable server the company set up. Within a few hours, someone succeeded. And several other people later won the challenge, as well, retrieving the private key.
“A nagging question is why, when OpenSSL has functions to cleanse memory, are these chunks of keys being found in memory. We are continuing to investigate and if a bug is found will submit a patch for OpenSSL,” Sullivan wrote.
“The more HTTPS traffic the server serves, the more likely some of these intermediate values end up on the heap where Heartbleed can read them. Unfortunately for us, our test server was on our local machine and did not have a large amount of HTTPS traffic. This made it a lot less likely that we would find private keys in our experimental setting. The CloudFlare Challenge site was serving a lot of traffic, making key extraction more likely. There were some other tricks we learned from the winners about efficiently finding keys in memory.”
There’s been some discussion about whether it is practical for an attacker to retrieve the private key of a target server using the heartbleed attack, and Sullivan said he sees it as doable.
“Based on these findings, we believe that within two hours a dedicated attacker could retrieve a private key from a vulnerable server. Since the allocation of temporary key material is done by OpenSSL itself, and is not special to NGINX, we expect these attacks to work on different server software including non-web servers that use OpenSSL,” he wrote.
The Tor Project has begun blacklisting exit nodes vulnerable to the Heartbleed vulnerability in OpenSSL.
Researcher Collin Mulliner, with the Systems Security Lab at Northeastern University in Boston, published the results of an experiment he conducted using a publicly disclosed Heartbleed proof-of-concept exploit against 5,000 Tor nodes. Mulliner said that 1,045 nodes, or a little more than 20 percent, were vulnerable to the bug.
Mulliner said only Tor exit nodes were leaking plaintext user traffic, including host names, credentials and web content. Mulliner conducted his experiment for three days last Friday through Sunday, and his results are a point-in-time snapshot. A post yesterday from Tor Project leader Roger Dingledine on the Tor mailing list said that 380 vulnerable exit keys were being rejected.
Heartbleed was publicly reported on April 7. The vulnerability lies in the heartbeat function in OpenSSL 1.0.1 to 1.0.1f which publicly leaks 64 KB of memory to any client or server pinging a web server running the vulnerable crypto library. The memory leaks can disclose in plaintext anything from user credentials to private server keys if the attack is repeated enough. Several researchers have already managed to retrieve private SSL keys in an online challenge from vendor CloudFlare. Speculation is that intelligence agencies and/or hackers may have been exploiting it since November. Mulliner said he did not try to extract private keys from Tor, nor did he think it was possible.
Tor promises anonymity to its users by using proxies to pass encrypted traffic from source to destination. Mulliner said he used a random list of 5,000 Tor nodes from the Dan.me.uk website for his research; of the 1,045 vulnerable nodes he discovered, he recovered plaintext traffic that included Tor plaintext announcements, but a significant number of nodes leaked user traffic in the clear.”
“I found a significant amount of plaintext user traffic, complete Web traffic, session IDs; everything you would find if you ran Heartbleed against a normal Web server,” Mulliner said.
Heartbleed saves attackers the work of setting up their own exit node and waiting for traffic to pass through it. Using Heartbleed, all a hacker would have to do is query a vulnerable exit node to obtain traffic, Mulliner said.
Dingledine yesterday published the first list of rejected exit nodes and said those nodes will not be allowed back on the network.
“I thought for a while about trying to keep my list of fingerprints up-to-date (i.e. removing the !reject line once they’ve upgraded their openssl), but on the other hand, if they were still vulnerable as of yesterday, I really don’t want this identity key on the Tor network even after they’ve upgraded their OpenSSL,” Dingledine wrote. He added that he hopes others will add to this list as other vulnerable relays are discovered.
Tor acknowledged some of its components were vulnerable to Heartbleed in a post to its blog on April 7.
Mulliner said it was a fairly straightforward process to write a script to run a Heartbleed proof of concept.
“Anybody who can get the Python script can play around with it,” Mulliner said, adding that there are likely fewer vulnerable Tor nodes now than when he ran his scans last week since some have likely been patched and Tor has begun blacklisting. “The data is dated, but it’s a good picture of that point in time.”