Locate Conficker infected hosts with a network scan!
The Honeynet Project has discovered an anomaly in Conficker that makes it possible to detect infected hosts with an elaborate fingerprint scan over the network. This is great news if you suspect an infection and have no other means to check, or if you simply want to double-check information that your other defense mechanisms (IDS, AntiVirus, etc) provide.
The write-up and scanning tool are available on the Honeynet Website.
Nessus Plug-In 36036: www.nessus.org
Instructions on how to scan for Conficker with NMAP: http://www.skullsecurity.org/blog/?p=209 . http://seclists.org/nmap-dev/2009/q1/0869.html has specific tips on how to scan large networks with the new NMAP feature.
Be careful when searching for any of these tools with a search engine. A good part of the search results returned on the keyword "Conficker" are scare-ware and fake anti-virus that try to cash in on the Conficker scare. We have a summary of removal tools with links available on isc.sans.org/conficker
The Honeynet project have also published a new write-up at http://www.honeynet.org/papers/conficker
Watch your Internet routers!
ISC reader Nick contacted us to share information about an Internet router at his workplace that got hacked this weekend. There's several nuggets to learn from in this story, so here goes.
3/28/2009 8:34:02 Authen OK test
3/28/2009 8:34:04 test Default Group where <cr>
3/28/2009 8:34:05 test Default Group who <cr>
3/28/2009 8:34:13 test Default Group who <cr>
3/28/2009 8:34:19 test Default Group show version <cr>
3/28/2009 8:34:23 test Default Group who <cr>
A successful login of a user "test" is definitely not a welcome sight in the TACACS authentication log of an Internet router. And the commands that follow are a clear indication that something sinister is going on. We know since Cliff Stoll's experience that somebody who needs to constantly look over his shoulder while connected (issuing the "who" command) isn't up to any good.
At this time though, Nick's firm didn't know this yet ... And the command log continues
3/28/2009 8:38:38 test Default Group show configuration <cr>
3/28/2009 8:38:59 test Default Group show interfaces <cr>
3/28/2009 8:39:48 test Default Group configure terminal <cr>
3/28/2009 8:39:50 test Default Group interface Tunnel 128 <cr>
3/28/2009 8:39:57 test Default Group show interfaces <cr>
3/28/2009 8:41:48 test Default Group configure terminal <cr>
3/28/2009 8:41:49 test Default Group access-list 20 permit 192.168.2.2 <cr>
3/28/2009 8:41:50 test Default Group ip nat pool new [removed] netmask 255.255.255.252 <cr>
3/28/2009 8:41:51 test Default Group ip nat inside source list 20 pool new overload <cr>
3/28/2009 8:41:52 test Default Group ip nat inside source static tcp 192.168.2.2 113 [removed] 113 extendable
3/28/2009 8:41:52 test Default Group interface Serial 1/0 <cr>
3/28/2009 8:41:53 test Default Group ip nat outside <cr>
3/28/2009 8:41:53 test Default Group interface Tunnel 128 <cr>
3/28/2009 8:41:53 test Default Group ip nat inside <cr>
3/28/2009 8:41:54 test Default Group ip address 192.168.2.1 255.255.255.0 <cr>
3/28/2009 8:41:54 test Default Group ip tcp adjust-mss 1400 <cr>
3/28/2009 8:41:55 test Default Group tunnel source Serial 1/0 <cr>
3/28/2009 8:41:55 test Default Group tunnel destination [removed] <cr>
Whoa! The bad guy is not wasting any time. Barely five minutes after connecting, and he has configured a network tunnel back to his home base.
3/28/2009 8:47:23 test Default Group configure terminal <cr>
3/28/2009 8:47:26 test Default Group line console 0 <cr>
3/28/2009 8:47:32 test Default Group password *****
3/28/2009 8:47:45 test Default Group who <cr>
3/28/2009 8:47:55 test Default Group configure terminal <cr>
3/28/2009 8:48:01 test Default Group line vty 0 1052 <cr>
3/28/2009 8:48:06 test Default Group password *****
3/28/2009 8:49:12 test Default Group no transport input <cr>
3/28/2009 8:49:26 test Default Group transport input ssh <cr>
As a next step, the bad guy changes the locally configured passwords. This doesn't make much of a difference, since these accounts only are used when the central TACACS database is not reachable. While the hacker shows quite some familiarity with setting up an IP tunnel on a Cisco router, he doesn't seem to fully grasp the significance of the TACACS entries in the configuration: since TACACS includes accounting logs, all his commands get recorded.
At 08:52, the bad guy logs off, and Nick's firm is still completely unaware that their perimeter router has just been subverted. But not for long: At 09:00, their "RANCID" script kicks in, pulls the current configuration off the router, compares it with the "last known good" configuration, and immediately e-mails the changes to the network admin. Luckily, the admin understands the significance of what he sees right away, and alerts the incident response team. A while later, the "test" user is removed, the config is cleaned up again, and the bad guy is locked out.
Nick's own "lessons learned" that he shared with us are:
- Disable outside management of Internet routers unless 100% required
- Log!! Log!! Log!!
- Review logs, review logs, review logs.
- Dont use easy usersnames/passwords.
- Talk to people, this includes ISP's. Get the word out of wrong doing.
- Dont hack back...(we didnt, but people sometimes feel the need to retaliate). This is against the law.
- Keep router firmware upgraded.
To which we at SANS ISC would like to add our own
- What saved the day here is the use of "RANCID", which acted like a trip wire. Something the bad guy clearly didn't expect
- Having a privileged user named "test" with a guessable password is of course unwise. But mistakes happen all the time - that's why we security folks all strive to build our defenses in a way that one single mistake isn't enough to sink the ship. Defense in depth works!
Thanks to Nick for sharing the logs and information about the attack!
Comments