CyberArk Responds: Opera Software Attacked – It’s Not a Trojan Horse, It’s a Trojan Whale…

August 29, 2013 CyberArk

by Roy Adar

 Web browser company Opera Software recently revealed that the company was the victim of an advanced cyber threat that targeted their internal network infrastructure. Fortunately, the attack was uncovered in time for Opera to contain the breach before widespread damage occurred. Nonetheless, the attackers were still able to obtain at least one old and expired Opera code signing certificate. In some cases, one is all it takes. With just one digital certificate, attackers can easily disperse malware and trick users into installing a virus-ridden software program that appears to users as genuine and originating from a well-known and trustworthy source.

While details of how attackers gained access to the certificate have still yet to surface, the potential ramifications of this breach warrants further analysis.

Most critically, this attack once again reveals that attackers are no longer looking to merely hide their malware within a single document or email attachment (i.e. Trojan horse attack).  Attackers are going big and hiding the latest malware and attack platforms inside what I call Trojan whales – malware hidden inside software that looks genuine and displays the digital signature of trusted vendors.

These Trojan whale advanced attacks are increasingly targeting entire software suites to inflict more widespread damage. The attacker penetrates to the development environment of a popular software vendor and plants the malware in the software, or alternatively signs malware using the software’s vendor certificate. Once customers install or upgrade their favorite browser, spreadsheet editor or Instant Message tool, for example, they are likely to have installed a compromised application.

These attacks are devastating and hard to identify because they’re using the businesses’ trust in their vendors against them.  This also makes it harder to defend against social engineering attacks on employees. While it’s one thing to tell employees not to open random documents sent to them in email, even if appearing to have been sent by one of their friends, it’s much more difficult to tell a developer not to install what appears to be a legitimate software update from a well-known and trusted vendor.

Because of this, it’s incumbent on these software providers to take extra steps in securing their software development environment AND their end customers against these sophisticated attacks.

Operation Aurora, which began in 2009, is one of the first examples in which dozens of popular software vendors were breached exactly for this purpose of allowing attackers to exploit vendors with a trusting customer base in order to gain entry to end-point customers.

Unfortunately, the problem here is that many companies still treat their “dev/test” environment as less critical when prioritizing security projects.  Some companies don’t appreciate the gravity of the risks, while others want to avoid removing privileges from developers in an effort to maintain productivity.

There are some “low hanging fruit” steps software vendors should follow for securing their development environment:

  • Remove all hard-coded passwords from scripts in the Build environment;
  • Developers should run in “least privileged” mode in their development and software staging environment to help reduce the attack surface for malware;
  • Access to the build machines should be separated from the day to day software development machines, ideally isolated using secure jump server concepts;
  • Privileged and shared accounts on the build machines should be well protected and monitored. Access to these accounts should be managed and users should be able to use such accounts when needed, but without being exposed to the passwords, what is known as “privileged single-sign-on;”
  • The private keys used to sign software on the build environment should be stored on hardware security modules (HSM) to prevent attackers from extracting them
  • Ensure access to the build environment is fully monitored to allow quick assessment of which assets were impacted in case of compromise.

With this evolving threat landscape, it’s abundantly clear that many software vendors need to change as well. These “trusted vendors” provide attackers with tens of thousands of end-points to high value customer assets that can be attacked and stolen all at once.

It’s a whale of a problem…


Previous Article
Pass the Hash II: Briefing at Black Hat
Pass the Hash II: Briefing at Black Hat

by Cory Friend, Systems Engineer, Atmos Energy At a briefing similar to the one I covered yesterday, Skip D...

Next Article
Honk if You’re Hackable
Honk if You’re Hackable

by John Worrall Coming out of Black Hat, vehicle and car hacks grabbed a lot of the attention. Some of the ...