Share

Related Links

Top 5 Stories

News

Adobe Hacked – Customers' Card Details and Adobe Source Code Stolen

04 October 2013

Adobe has been hacked. Source code for numerous Adobe products including Acrobat and ColdFusion has been stolen. Customer IDs and passwords have been accessed; and card details for 2.9 million customers stolen.

Security researcher Brian Krebs warned an announcement was coming: "Adobe Systems Inc. is expected to announce today that hackers broke into its network and stole source code... [and] also accessed nearly three million customer credit card records, and stole login data for an undetermined number of Adobe user accounts."

On Thursday morning the announcement came from Brad Arkin, Adobe's CSO. "Very recently, Adobe’s security team discovered sophisticated attacks on our network, involving the illegal access of customer information as well as source code for numerous Adobe products." He added that the hackers also took customer IDs and encrypted passwords, and card details on 2.9 million Adobe customers, "including customer names, encrypted credit or debit card numbers, expiration dates, and other information relating to customer orders."

There are two sides to this breach: the loss of source code, and the loss of bank card details. Adobe says it believes that the two losses are related. Krebs says more. He learnt of the breach more than a week ago when he and Alex Holden, CISO at Hold Security LLC "discovered a massive 40 GB source code trove stashed on a server used by the same cyber criminals believed to have hacked into major data aggregators earlier this year, including LexisNexis, Dun & Bradstreet and Kroll."

It doesn't appear as if Krebs found any card details, but when he spoke to Adobe the firm said that they had been investigating "a potentially broad-ranging breach into its networks since Sept. 17, 2013." In this conversation Krebs was told about the suspected loss of card details, and that "the company believes that hackers accessed a source code repository sometime in mid-August 2013, after breaking into a portion of Adobe’s network that handled credit card transactions for customers."

Adobe has contacted the FBI and is working with the LEA on its investigation. This is often used as a reason for not 'going public' about a breach, in order not to compromise the investigation. However, it seems clear from what Adobe told Krebs that the firm has known about the loss of card details for at least two weeks, and that they were lost seven or eight weeks ago. This means that the hackers have had potentially seven weeks to attempt to crack users' card details; and it also raises the question on whether Adobe would have gone public at all were it not for Krebs' involvement.

Infosecurity asked independent pentester and password expert Robin Wood to look at Adobe's comments on the card detail loss. Firstly, he believes that by 'encryption', Adobe probably means 'hashed'. (There is some debate on whether encryption and hashing is the same thing; Andrew Gilhooley at RandomStorm for example believes that hashing can be described as encryption.) But can they be cracked? "If they were hashes then it depends what algorithm they used and whether they used salts or not," explained Wood. "Bcrypt should be OK but unsalted md5 would be easily crackable."

Gilhooley explains further. "MD5 is broken. SHA1 is widely regarded as broken. The problem with most hashing algorithms is that they are designed for speed which makes them vulnerable to brute-forcing." But he agrees that if Bcrypt was used, it upsets the traditional brute force model by adding extra time and cost so that "an attacker can no longer calculate millions of hashes per second."

Adobe also says that "we do not believe the attackers removed decrypted credit or debit card numbers from our systems." Wood told Infosecurity that he probably means clear text versions of the card numbers. "They should be stored encrypted but at some point have to be decrypted to be used so that would be the ideal place to grab them."

The implication is that this was not a simple hack and grab situation, where the hackers break in, steal the password database, and leave. The implication is that they had a presence within Adobe's system able to wait and watch and potentially steal the details as they were being used – which seems to be what Adobe is saying did not actually happen.

Gilhooley offers an alternative option: “If they have unencrypted card numbers on their systems, they will be in a lot of trouble with the card brands. I suspect that they have encrypted card numbers stored, and they are currently trying to identify if their attackers have compromised the encryption keys used to protect them.”

One head of security who asked not to be named (getting corporate approval would take too long) and who clearly believes that encryption and hashing are entirely separate processes, told Infosecurity, "I really hope they don't mean encrypted passwords. Passwords should never be stored in the clear or in way which allows a user or system to retrieve the original value." Since encryption is reversible, encrypted passwords can provide the original value. And if "they are hashed with a weak or non existent salt then they will be brute forced extremely quickly using specialist tools such as hashcat."

So, were they encrypted or hashed? "Brad Arkin (the CSO) isn’t new to the security world," he added, "and I couldn’t see him mixing up encrypted and hashed…"

Adobe is holding its cards closely. At the moment we simply do not know how it protected the card details and account passwords, nor what if any trojan was used to hijack the details. Adobe is, however, resetting all customer passwords and offering US customers the option of a year's complementary credit monitoring.

This article is featured in:
Encryption  •  Internet and Network Security  •  Malware and Hardware Security

 

Comment on this article

You must be registered and logged in to leave a comment about this article.

We use cookies to operate this website and to improve its usability. Full details of what cookies are, why we use them and how you can manage them can be found by reading our Privacy & Cookies page. Please note that by using this site you are consenting to the use of cookies. ×