An updated version of DNS hijacking malware 'Flush.M' is currently out in the wild, it originally popped up in December 2008. What is significant about this particular nasty is the methodology of network compromise, it's sharply more complex and creative in the way it hijacks it's prey.
Let me walk you through how it works:
Joe the Plumber clicks through a website with a malicious banner ad hosting a Flush.M laden PDF using Adobe's latest JBIG2 security flaw, once his browser auto-opens the PDF, the trojan is successfully installed on his machine.
Now the interesting part, the malware starts a rogue DHCP server advertising to the local lan with a 1 hour refresh rate. This means that if Joe is at the public library, the one 'Flush.M' infection will change the network settings on all machines of the same LAN.
Because DHCP has the capability to set the client machine's DNS servers 'Flush.M' resets all DNS resolvers to malicious external DNS hosts which then exposes the entire LAN to a giant man in the middle attack. Phishing, password stealing, more malware injection, click fraud, you name it...
So for the first time I can think of you have malware not spreading on the LAN via attacking known vulnerabilities but from using legitimate networking technologies to poison the environment and very quickly compromise an entire LAN. Nasty stuff.
If you want to know if Flush.M is on your network, here is a snapshot of it phoning home:
14:45:26.989321 IP 172.17.1.86.60307 > 55.55.55.55.53: 45585+ A?
isatap.snip.edu. (33)
0x0000: 4500 003d 040c 0000 7f11 c4b3 ac11 0156 E..=...........V
0x0010: 4056 8533 eb93 0035 0029 42f8 b211 0100 @V.3...5.)B.....
0x0020: 0001 0000 0000 0000 0669 7361 7461 7004 .........isatap.
0x0030: 6963 6970 0365 6475 0000 0100 01 snip.edu.....
Snort signature (thanks jp):
alert udp ![$SMTP_SERVERS,$DNS_SERVERS] any -> $DNS_SERVERS 53
(msg:"Flush DNS lookup isatap (Possible flush)"; content:"|06|isatap";
nocase; classtype:trojan-activity; sid:1021339; rev:1;)
Wednesday, March 18, 2009
Monday, March 16, 2009
Network Security Appliance testing and QA with Virtualization
While working on our newest Intrusion Prevention appliance Sentinel IPS 4.0, we are always working to streamline and automate all testing. Unfortunately an inline bridged network device can be a challenge...
Here are some of the strategies that have worked in the past and some of the issues we are currently struggling with:
The old fashioned way (QA environment round 1):
What the team before I joined was using, 4 separate physical machines configured like this:
QA Attacker/Tester (loaded with stateful attack scripts) --> Router (192.168.x.x <-> 10.10.x.x) <--> Sentinel IPS (inline bridged appliance) <--> Switch <--> QA Target Host/s
This works but is in my mind too much equipment and software to maintain, not only that but power consumption is in microwave oven levels. Adding a new attacker or target platform requires loading or reloading another piece of hardware.
QA environment round 2:
Hello Vmware! I believe it was VMware Workstation for Windows 5.x or so which added a wonderful new network feature called "teaming" in which you could create virtual labs by daisy chaining VM's and virtual interfaces together allowing Vmware to handle all of the routing.
Here is how it worked (QA Team1):
Attacker VM (Gentoo) <-bridged interface0-> Sentinel IPS VM <-Nat interface1-> Target VM1 (Windows Server 2000) Target VM2 (CentOS 5.x)
So you simply assign all of the VM's to a single team and the one interface each to your network appliance so it will bridge the traffic from your Attacker/Tester VM to the Internal target VM's. With one command you can start and stop the entire team or add and modify the attacker and target OS's. Adding Backtrack LiveCD as one of the attacker's is easy, simply install their VM and add it into the team using the bridged interface.
Now to avoid confusion there are two bridges in action, one which bridges the attacker and network appliance (Sentinel IPS in my case) to your normal physical LAN. This is chosen automatically by VMware but if you are on a laptop which may switch between wireless and wired networks you will want to manually create a bridged interface for your wireless card. They make it dead simple to switch your team interfaces around when your not on wireless.
The second bridge is the network appliance itself! If it is an inline bridge device like our IPS, then it will bridge the already bridged interface to the private NAT network which VMware created automatically. The auto NAT network is usually some derivative of 192.168.1xx.x which likely won't clobber your normal LAN.
Ok... so that seems like the perfect setup and it has worked rock solid for us requiring only one Windows machine with VMware, one actual real network interface and 2+ gig's of RAM. Pretty easy to come by these days.
Why do we want a new setup? Well I had to splurge on a Macbook Pro last year and VMware fusion does not support teaming.... Seem like small potatoes but it kills me that I can't put my 4 gigs or ram to good use. Yes my drive is encrypted :)
*** Update: maybe time to try Convirt 1.0 on my Mac
Here are some of the strategies that have worked in the past and some of the issues we are currently struggling with:
The old fashioned way (QA environment round 1):
What the team before I joined was using, 4 separate physical machines configured like this:
QA Attacker/Tester (loaded with stateful attack scripts) --> Router (192.168.x.x <-> 10.10.x.x) <--> Sentinel IPS (inline bridged appliance) <--> Switch <--> QA Target Host/s
This works but is in my mind too much equipment and software to maintain, not only that but power consumption is in microwave oven levels. Adding a new attacker or target platform requires loading or reloading another piece of hardware.
QA environment round 2:
Hello Vmware! I believe it was VMware Workstation for Windows 5.x or so which added a wonderful new network feature called "teaming" in which you could create virtual labs by daisy chaining VM's and virtual interfaces together allowing Vmware to handle all of the routing.
Here is how it worked (QA Team1):
Attacker VM (Gentoo) <-bridged interface0-> Sentinel IPS VM <-Nat interface1-> Target VM1 (Windows Server 2000) Target VM2 (CentOS 5.x)
So you simply assign all of the VM's to a single team and the one interface each to your network appliance so it will bridge the traffic from your Attacker/Tester VM to the Internal target VM's. With one command you can start and stop the entire team or add and modify the attacker and target OS's. Adding Backtrack LiveCD as one of the attacker's is easy, simply install their VM and add it into the team using the bridged interface.
Now to avoid confusion there are two bridges in action, one which bridges the attacker and network appliance (Sentinel IPS in my case) to your normal physical LAN. This is chosen automatically by VMware but if you are on a laptop which may switch between wireless and wired networks you will want to manually create a bridged interface for your wireless card. They make it dead simple to switch your team interfaces around when your not on wireless.
The second bridge is the network appliance itself! If it is an inline bridge device like our IPS, then it will bridge the already bridged interface to the private NAT network which VMware created automatically. The auto NAT network is usually some derivative of 192.168.1xx.x which likely won't clobber your normal LAN.
Ok... so that seems like the perfect setup and it has worked rock solid for us requiring only one Windows machine with VMware, one actual real network interface and 2+ gig's of RAM. Pretty easy to come by these days.
Why do we want a new setup? Well I had to splurge on a Macbook Pro last year and VMware fusion does not support teaming.... Seem like small potatoes but it kills me that I can't put my 4 gigs or ram to good use. Yes my drive is encrypted :)
*** Update: maybe time to try Convirt 1.0 on my Mac
Tuesday, March 3, 2009
Whole Foods RFID price tag security
A brand new Whole Foods opened up right next to our house so I had to check it out on opening day. What a nightmare of triple parked Prius', scooters and other granola eating eco-hipsters transportation devices. I'm not an anti-hippy but my love for red meat, beer and Marlboro lights is not so popular with that crowd. Anyways throughout the dozens of free yummy samples I happened to notice new digital price tags under the food. Well they are not connected to any physical wires and looks to be powered off watch batteries, must be RFID! A little bit of googleing confirmed my theory and we are off to the races.
Potential security issues:
Price modification (Choice Ribeye steak for $2/pound)
Customer product tracking
Store pricing denial of service (eggs and toilet paper now $99, maybe too believable at whole foods)
Price change sniffers (publish sale items on rss feed, hide behind the cantaloupe)
I would like to hear your ideas, thoughts, comments on this change which will likely ripple down to other big box grocers in the future.
Potential security issues:
Price modification (Choice Ribeye steak for $2/pound)
Customer product tracking
Store pricing denial of service (eggs and toilet paper now $99, maybe too believable at whole foods)
Price change sniffers (publish sale items on rss feed, hide behind the cantaloupe)
I would like to hear your ideas, thoughts, comments on this change which will likely ripple down to other big box grocers in the future.
Subscribe to:
Posts (Atom)