Botnet malware defense

Published: 2008-03-13
Last Updated: 2008-03-14 05:18:00 UTC
by Jason Lam (Version: 1)
3 comment(s)

Today, we solicited ideas on protecting against botnet malware infections from an organization standpoint. The focus is on ideas or experience on certain defense approach or technologies to fight off botnet infections or detect infected machines.


- Ensure OS and software patches on the desktop are up to date

- Disallow installation of new software on desktop (users have no administrative rights)

- Block domains that are known to be distributing malware.
    - Malware domains
    - C&C list    
    - RBN list

- Utilize a different AV scanning on web proxy (defense in depth)

- Blocking IRC ports which offers some protection against older generation of botnets

- Blocking all bad ports and make all traffic go through proxies, where traffic and anonymous behavior can be monitored.

- Browser hardening using Firefox Noscript and IE zones

- Watch office documents in email, particularly from spoofed sources.  If the incoming source IP doesn't match the header information, drop the email

- When performing JRE updates, ensure the old version get removed.

- Using HIPS (Host Intrusion Prevention System) to prevent potential harmful or abnormal behavior on the desktops


- Deploy listening nepenthes sensors on local IP space for early detection of infected machines.

- Deploy commercial and opensource detection systems - BotHunter, MainNerve .          

- Setting up internal darknets to detect bots that are wildly spreading thru blind network scans

- Egress monitoring during off-hours to pick out phone homes

- Monitor user-agent strings on the web proxy and detect anomalies.

- Content monitoring using Data Loss Monitoring systems

 - Scan for BHO (Browser Helper Object) and match it against known bad list such as the one at Castlecops


Thanks to the following people for contributing information,
Russ McRee, Ned Slider, Gary K, Nate, Paul Tatarsky, Drew Hunt, dxp

Jason Lam

3 comment(s)

Remote File Include spoof!?

Published: 2008-03-13
Last Updated: 2008-03-13 06:19:26 UTC
by Jason Lam (Version: 1)
0 comment(s)

Recently, I was preparing some Remote File Include (RFI) demo for one of my Web Application Security class. I headed straight to my favorite vulnerability tracking site and picked out the first 3 Opensource packages that are vulnerable to RFI. After downloading the vulnerable version of the applications, I got them loaded on my test web app server. This script kiddie is ready for some pwning actions!

It wasn’t even ten minutes into testing that I noticed none of the exploits were working, this is not just one Opensource package, but three, something must be wrong. Time for some kung-fu to kick in, I first inspected the PHP environment using the phpinfo() function call which display everything under the Sun about the running PHP environment. Everything looks as vulnerable as it should be,
allow_url_fopen = On
register_globals = On

[PHP version < 5.20, so allow_url_include option not available yet, otherwise I would check that as well]

Please note these settings are very insecure, don’t try this at home!  :-)

Everything in PHP looked fine to me, the problem might be elsewhere. I started digging into the code to see what the problem is. In the supposingly vulnerable PHP file, I have the follow lines of code at the beginning of the file,
include (‘config.php’);

The exploit inject PHP commands into $lang. From the looks of it, exploit should work as the $lang is a variable that could potentially be user input. More digging required.... The whole thing became clear when config.php was inspected, in the config.php, there is a line,
$lang = “english”;

That explained why exploit attempts did not work, $lang is statically defined within the program code, the user input of $lang can be global variable but it is overwritten by the static definition. The code certainly look suspicious but this one is not RFI. I inspected the other OpenSource packages I downloaded, they are all NOT vulnerable due to similar control in place.

I have also found some previous mis-reported “RFI vulnerabilities” (see links below). These are all reported in most major vulnerability tracking sites.

RFI is definitely a very serious web application security issue, don't let all these false positives make you think otherwise. Moral of the story is, use discretion when handling vulnerability information. Perform proper testing with any potential vulnerability, understanding how vulnerability works is the key to handling these information properly.

Jason Lam

0 comment(s)


Diary Archives