AV Versus Old and New Bot Code

Today, in my research work on the data from the HoneyPoint Internet Threat Monitoring Environment (HITME), I uncovered an old (2008) piece of PERL code embedded inside a PHP bot-net infector client that I discovered from the HITME logs. This perl code was included in the PHP bot as a base64 string, which is quite common. The PHP code unencodes the perl script and drops it on your hard disk when the PHP bot herder wants to have a reverse shell to execute commands on your system.

In this case, the placement of the PHP bot was via PHP Remote File Injection, so the malware would be placed on your victimized web server. For enterprises, that means that if your web server got hacked in this way, then you would expect your anti-virus to be the last line of defense for protecting you against this malware.

Here’s where it gets weird. AV detection was absolutely horrible for both of these pieces of code. For the perl backdoor, the detection rate at VirusTotal was just 55% and that code has been known for years. For the PHP bot, in its entirety, the total was even worse with detection rates of just 46%.

Even worse to me than the percentages are the vendors that caught vs missed these simple scripts. Check the list for your AV vendor, because I was shocked to see that some of the big name, enterprise class products missed these forms of malware entirely. Some of the small freeware vendors we might expect to miss some of the malware targeted at servers, but I would think we should expect more from the enterprise AV vendors, especially if you read the hype of their marketing.

Now, a lot of folks are going to say, of course AV misses stuff. There’s polymorphic code out there, Brent, and a lot of the bad guys have really spent a ton of resources to obfuscate and modify their code on the fly. I agree with this. But, in this case, we are not talking about custom designed binary code with trapdoors, memory injection, polymorphism or anything of the like. These are simple script files, in plain text. Neither of them is obfuscated. You can see the PERL back door code for your self. I just published it on my Posterous blog for supporting materials. I think after you check that out, you can see that the “complex malware code” argument, just doesn’t hold water in this scenario.

The bottom line is this, your AV software and other mechanisms that are heuristics based are likely not doing the job of protecting you that you might imagine. Just something to keep in mind when you do your next risk assessment, threat model or the like.

Thanks for reading!

Port Knocking and SPA – Thoughts

A colleague of mine pointed me to an article on Port Knocking, more specifically, Single Packet Authorization. I wasn’t too familiar with either but once I started reading, some thoughts came to mind. Does this look far to cumbersome and “pain in the butt” to implement for such a small gain to anyone else? This is just another method of implementing the doomed “security by obscurity”.
First off, Port Knocking “is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports.” [1] Single Packet Authorization is similar, but requires only one encrypted packet. While this may impress some people with it’s technical savvy, this solution should be thoroughly evaluated before implementing. As far as enterprise usability goes – limited at best. Talking amongst ourselves here we did think of one implementation that would actually be useful. That is to prevent your ISP from knowing you’re hosting a service without having to create extensive black or white lists. You could host an ftp server for example without the port ever showing as open to an overly intrusive ISP. Of course we do not condone the breaking of any agreements with an ISP.
However, for enterprise environments Port Knocking and Single Packet Authorization are in my opinion no way a replacement for good security practices These include keeping the service up to date with any patches/updates provided by the vendor. Be aware of any newly developed or developing threats to the service you’re hosting. Implement proper ACLs at the firewall. Block all of Eastern Asia from accessing your SSH service if need be. Use VPN clients. This is critical, there’s no real reason to have remote access ports opened without protection. Use VPN clients. Just about every enterprise firewall comes with some sort of VPN option. Last but not least, do not forget the importance of a strong password policy. Brute force attacks really become a non issue with a complicated enough password.
In conclusion, PK and SPA sound good in practice, and implemented as part of a greater defense in depth solution could work; otherwise, stand alone PK and SPA in my opinion are less than ideal.

[1] http://en.wikipedia.org/wiki/Port_knocking