A Flash in the pan?

Opinion by Ken Munro

A recent Flash Player vulnerability shows exploits have reached alarming new heights of sophistication

A recent Flash Player vulnerability shows exploits have reached alarming new heights of sophistication.

April saw the emergence of one of the most technically ingenious attacks we've seen in recent times. Taking advantage of a partially known vulnerability in Adobe's Flash Player, this attack also made use of SQL injection and cross-site scripting to potentially devastating effect. Even more impressively, the code used within it was convoluted and obfuscated, making unravelling and defending the attack doubly hard.

The attack was unusually 'intelligent', in that it had access to a library of different exploits, including the ability to fingerprint the target system and then select the correct exploit with which to attack it. This meant it took a very different approach to the usual one-exploit "hit and hope" attempts.

While most worms spread by looking for another vulnerable system, infecting it, then moving on to another, this attack was on another level. On compromise, it then downloaded more malware on to the infected system, tried to join it to a botnet, took control of it, and moved on. The result was exponential growth in infections.

Older worms would propagate at the network layer, looking for a specific port and service. One example would be tcp/445 in the case of the Blaster worm. These travelled fairly quickly, but it was still a trivial task block propagation into the LAN from the internet by simply closing the port at the firewall. Given that the port really shouldn't have been open in the first place, even a basic security policy and firewall configuration would have protected the corporate from internet-based infection routes.

Fortunately for this attack, it emerged that the latest version of Flash Player was not vulnerable. Consequently, the buffer overflow the attack exploited was not considered "zero day". Where there are grounds for significant concern, however, is its effects when used in combination with mass SQL injection worms, as mentioned earlier.

We are beginning to see a trend emerging in which large numbers of client systems are attacked using malicious web content. These are increasingly well co-ordinated and demonstrate an approach to writing exploits akin to software development, showing both intelligence and possible outside funding.

Users install browser plug-ins on trust, with little thought to their security. We may know about Flash, but what about recent issues with Real Player, problems with Active X, the cross-site scripting vulnerability in PDF files and even good old Java Runtime? As security professionals patch and secure infrastructures and applications, the hacker directs their attention towards the client. The distinction between remote and local exploits is also becoming blurred as we see local vulnerabilities being remotely exploited through web browsers using malicious web content.

The simplest solution to this problem would be to block corporate users from using plug-ins. After all, few corporate websites require them to view legitimate content, and it is certainly rare to have to use Flash for business purposes unless your corporate applications are written in it.

This, however, then raises the question of where do you stop? It may be safer, but is it realistic to block everything but plain text or HTML? A better solution may be to look for malicious code proactively, performing deep-packet inspection of your content filters. Most browsers also allow for policy controlling plug-in installation. At the very least, plug-ins should only be installed from the vendor's site, giving a degree of confidence that the code itself is uninfected.

The rest is general good housekeeping, ensuring that content filters, servers and clients are updated regularly. Installed components other than the OS should also be updated and tested thoroughly.

As has always been the case with the internet, functionality is still being added faster than security. Our challenge is to try and stay ahead of increasingly well-organised hackers as best we can.

- Ken Munro is managing director of SecureTest. He can be contacted at ken.munro@securetest.com.


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events