Opera got pw0n3d: But did you get pw0n3d too?

Published: 2013-06-28
Last Updated: 2013-06-28 02:11:16 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

Opera recently suffered a compromisse to one of the servers it uses to distribute software updates. You probably read about the fact, that as part of this compromisse an expired certificate was used to sign malicious software. This software was then distributed using Opera's update servers. Users checking for updates during the time the malicious software was live automatically downloaded and installed the software using Opera's automatic update feature.

We can talk a lot about what may or may not have been done by Opera to prevent this from happening. At least, they detected the problem quickly, but then again, it took them a few weeks to notify users. But not too many of you are probably distributing major software packages. However, we all rely in some ways on automatic updates, and hope that vendors deliver "clean" (even if not bug free) software.

So what can you do to detect and clean up malicious software that was installed directly from a trusted vendor?

TrustNo1

A very long time ago, before we hashed passwords, this was one of the favorite once used by our users and somewhat indicates the attitude of many of our readers. Is paranoia still paranoia if they are actually out there to get you? In real live, this usually doesn't get you far. Features like auto-updates, and trusting digital signatures, are necessary to survive with non existing patch windows. You should however always think "defense in depth". There may be other controls to make sure the software behaves as expected. For example, if software "calls out" to other sites. Sadly, for a web browser, outbound connections are expected and hard to verfiy.

Anti-Malware

At this point in time, the malware distributed via the Opera update is widely recognized. However, if your system was infected, Anti-Malware is likely no longer functioning as designed. The attacker had a couple weeks to download and install additional components. One trick that may still work is an offline malware scan using a bootable CD. This method however doesn't scale well and is time consuming even for individual PCs. As a compromisse, you may want to scan the suspicous drive over the network by mounting it to a known clean system

Whitelisting

Many whitelisting systems will not flag software if it comes with a valid signature. Also, in this case, you may have added an exception thinking that the update to Opera was legitimate as it came from a legitimate Opera server and was signed.

Network Based Controls

This is probably the best way to avoid modifications made by the malware to the host. But properly configuring network based controlls (Firewall, Intrusion Detection or Prevention Systems) is tricky. You are likely still relying on signatures, and the signature may come too late in this case after the malware installed additional tools that no longer match the original signature. But a well tunes IDS is probably your best bet to detect this.

Host based Intrusion Detection/Prevention

HIPS comes in many forms, but I am thinking here of behavioral tools that detect processes escalating privileges and accessing files they shouldn't access (or establishing network connections). This may work here, if the malware doesn't manage to disable these tools.

My summary: Start with the host. If it is patched and well protected (Anti Malware / Whitelists ...), then chances are smaller that the malware will disable these features. The chance isn't 0, but smaller. Secondly, make sure your network defenses are in order and provide meaningful alerts that suplement hostbased detection.

Any other ideas I missed?

 

[1] http://my.opera.com/securitygroup/blog/2013/06/26/opera-infrastructure-attack

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
5 comment(s)

Comments

I don't draw on auto-update if possible.
Full-package installs can be counter checked by his checksum.

Those can easily distributed to the whole network as well.
Should automatic patch installers / setup programs have sufficient privileges to install system components?
I think not. Bad OS design.

It seems like the Opera update installer should have been designed to run as a non-privileged user with Write access to only the Opera program files, opera settings files, and /not/ system settings files, or not privilege to add system component..

So that the impact of any malware could be limited to users that start the Opera application.

@Mysid

That's all well and good, but if you open your favorite banking or shopping site within this "limited impact" (browser) it may be a Bull's eye for the attacker.


If I'm a bad guy and I want my trojan delivered by a browser update it is more than likely that this would be the main target.
@Robert,
Yes; I am aware of that, in as much as the browser itself is a target. However, Opera may be installed but not utilized on a daily basis for banking or shopping.

So in case the trojan is limited to the browser install itself, the damage done may be less, in the time before the issue is discovered.

Many people utilize multiple browsers, and Opera might be used rarely. Some risks to banking transactions may be reduced through token-based two-factor authentication and transaction confirmation.


Although this does speak well for software companies having _two_ digital signatures required for automatic updates, and also segmenting the program into separate pieces.

Such as a 'core control module' that provides instructions, and a 'rendering engine' module that prepares content for display, but cannot directly access the network. And a specific certificate's digital signature required for each piece of code.


One digital signature of the installer program.
And a separate digital signature of the "automatic update" payload or a "verification file" with a secure hash of the files to be downloaded, required for an updater client to process the update.

Controlled by separate processes; with both signings controlled by a hardware security module, requiring smart cards from a specified plurality of authorized users that can confirm the final build executed on an offline build server.




I have to join Mysid here, Robert. Nobody's saying that reducing the amount of code that needs to run with system privs will make all your security problems go away. But it will reduce the attack surface, which can only help. (Remember "Defense in depth"? Johannes even mentions it by name in the posting.)

I have a question for the gang here: I find myself unpleasantly surprised by the apparent fact that Opera's updater software trusts EXPIRED certs. Am I just being naive and/or idealistic?

Diary Archives