05:15 PM
Connect Directly

Hacking The Adobe Breach

Financially motivated attackers could abuse stolen source code for broader attacks

At first glance, the massive breach at Adobe that was revealed last week doesn't neatly fit the profile of a pure cybercrime attack: Not only did the bad guys steal customer data and payment card information from the software company, but they also nabbed the source code for Adobe's ColdFusion, Acrobat, and Reader software.

It's still unclear just how the attackers got Adobe's customer data and its source code, and what, if anything, they have done to tamper with the source code for fraud purposes. But what is clear is that the attackers either purposely or inadvertently accessed both Adobe's valuable customer financial data and its intellectual property -- netting themselves multiple avenues for making money.

"These guys were financially oriented," says Alex Holden, CISO at Hold Security, who, along with Brian Krebs of KrebsOnSecurity, discovered the 40 gigabytes of Adobe source code on the same server as the stolen data from LexisNexis, Dun & Bradstreet, Kroll, and others. "Whether they had access to the source code first ... it remains to be seen."

Adobe late Thursday revealed that it had suffered massive "sophisticated attacks" on its network that resulted in the theft of sensitive information, including payment card information on 2.9 million customers, as well as of source code for multiple Adobe software products, including Adobe Acrobat, ColdFusion, ColdFusion Builder, and other Adobe software. Brad Arkin, chief security officer of Adobe, said the attacks may be related.

Hold Security's Holden says the attackers appear to have had the stolen data in their possession for at least two months. He says one of his biggest worries is that a zero-day attack may be under way against Adobe applications that hasn't yet been spotted. "They might have attacked high-level targets. That's an extremely disturbing and scary thought," Holden says.

Cybercriminals typically try to quickly cash in on stolen payment card information or user credentials. While the stolen Adobe customer payment card data was encrypted, according to Adobe, it's possible the attackers were able to glean the encryption keys or crack the crypto, depending on its strength and implementation, security experts say.

The attackers could monetize the source code by finding and selling exploits for Adobe apps, for instance, experts say. Or they could just keep the exploits for themselves to use in more widespread future attacks.

"If you're going after Adobe or any company, you're going to go after information you can monetize quickly, but also if you find some really good zero-days in Adobe Reader or ColdFusion, that might just lead to future attacks across several customers," says Benjamin Johnson, CTO of Carbon Black. "Everyone has Adobe ... it's such a huge surface area to target."

Exploit sales are lucrative, to the tune of tens of thousands of dollars for an Adobe app, for example. "The source-code is the money-making stuff -- it helps you find the vulnerabilities in Adobe products. For example, a single zero-day exploit for Adobe Reader can be worth $50,000 in the black market," says Timo Hirvonen, senior researcher at F-Secure.

Leveraging Adobe's source code would provide the attackers with a more efficient way to steal information. "In the past, it was so easy for [cybercriminals] to do spree attacks -- you could get millions of people through phishing and keyloggers," says Dan Hubbard, CTO of OpenDNS. "But now it looks more sophisticated, and they are doing things that are more planned, so instead of going after the client and human element, they are going at some of the weaknesses in the infrastructure and pulling data back and figuring out what to do ... It's definitely an interesting change in operations."

If the worst-case scenario becomes reality and the attackers actually poisoned the Adobe source code and then distributed it to Adobe customers, then the software firm was more of a means to an end for the attackers. "If indeed the source code stolen pertains to ColdFusion and Acrobat, this could leave thousands of Web servers open to at-will compromise and make it easier to compromise end-user systems. This breach is a chilling reminder that all software companies should be on guard, as they, too, could be a stepping stone to other targets," says Chris Petersen, CTO and co-founder of LogRhythm.

[Today's reality that you can't stop all cyberattacks means security teams must double down on smarter detection of threats and attacks rather than the traditional approach of mainly trying to prevent them. See CISO Shares Strategies For Surviving The Inevitability Of Attacks .]

It may be some time before the full picture of the Adobe attack emerges -- if it does at all. Security experts say if it indeed took Adobe up to six weeks to notice the attack, the software company is at a disadvantage from the start. "That's a head start the bad guys had," Johnson says. The key is always quick detection to mitigate the damage, experts say.

Bala Venkat, chief marketing officer of application security vendor Cenzic, agrees. "From the investigations underway, it appears this breach at Adobe actually started sometime in August and continued into late September. Such delayed detect and response mechanism is especially alarming. Organizations must ensure a continuous security monitoring process across all of their production applications is in place to detect and report on vulnerabilities real time when a breach occurs. If this policy is enforced with rigor, such breaches could have been contained and the damage minimized much faster and more effectively. “

Another concern is whether the attackers already have made inroads in targeting Adobe's customers. "One of my concerns is the lateral movement within the customer base," Carbon Black's Johnson says, where the attackers already have phished Adobe customers to steal information.

"It's going to be a while until we know the full ramifications of this," he says.

And Adobe is not the last victim of this cybercrime gang: Security experts say to expect further revelations of other organizations that were hit.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is Executive Editor at She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
10/15/2013 | 6:47:12 PM
re: Hacking The Adobe Breach
My clients use fingerprinting technology ("AccuMatch DLP - Gtb technologies) with their content aware reverse firewall - which works like a charm. They also have full coverage on those 'unknown' ports, not just SMTP channels, just in case they've "Got Malware, now what??"
User Rank: Strategist
10/8/2013 | 8:50:22 PM
re: Hacking The Adobe Breach
Hi Jeff--Holden wouldn't provide details on what they found besides what was made public previously (Lexis/Nexis, etc.) and now w/Adobe, but he indicated that there were other victims that have yet to be revealed.
User Rank: Apprentice
10/8/2013 | 2:53:04 PM
re: Hacking The Adobe Breach
Can I add that Adobe compounded their lack of security by sending unexpected emails to 3 million people with a request to change their security details by clicking on a link in the same email.

I cannot confirm that anyone has used this fact to try to get login and other information from Adobe users but since support on the Facebook page is basically saying "just click on the link" we have to hope that they will be getting an email with the right link.

If you see nothing wrong in what Adobe has done then you are advised to reset your PayPal Password here.

User Rank: Apprentice
10/8/2013 | 11:07:43 AM
re: Hacking The Adobe Breach
First, than you for covering this story. I'm always amazed at the lack of attention the larger media outlets pay to stories like this. What is puzzling me is what server was the software left on and how did Krebs and Holden find it? Was it open for anyone to view and why was the data not encrypted? Looks like the thieves were as sloppy as Adobe about protecting the source code.
Jeff Jones
Devastating Cyberattack on Email Provider Destroys 18 Years of Data
Jai Vijayan, Freelance writer,  2/12/2019
Up to 100,000 Reported Affected in Landmark White Data Breach
Kelly Sheridan, Staff Editor, Dark Reading,  2/12/2019
Register for Dark Reading Newsletters
White Papers
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c has an integer overflow on the result of multiplication fed into malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow.
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. In xmalloc.h, there is an integer overflow on the result of multiplication fed into the lsx_valloc macro that wraps malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow in channels_start in remix.c.
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow.
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c allows a NULL pointer dereference.
PUBLISHED: 2019-02-15
Vulnerability in FileUtils v0.7, Ruby Gem Fileutils <= v0.7 Command Injection vulnerability in user supplied url variable that is passed to the shell.