Recently in Incident Response Category
Just a quick reminder: I will be starting a new SANS mentor session for Security 504: Hacker Techniques, Exploits and Incident Handling on January 7 out of Garden City, NY (Long Island). Some spots are still available, so please sign up if you are interested. We'll convene once a week on Wednesday evening from 7.30pm-9.30pm.
More information at: http://www.sans.org/mentor/details.php?nid=14803
Late last week, I formulated the hypothesis that we might have some rogue DHCP servers popping up here and there.
Since the machines that were having the problems revert to a presumed-good image upon reboot, finding the actual problem was a little bit of a challenge. Our only real option was to wait for another outbreak, followed by a focused and temporary capture of network traffic.
A few days ago, we got a call that machines were experiencing browsing difficulties, and we were able to capture some network traffic that confirmed my hypothesis; a box that not one of our DHCP servers was sending out DHCP offers.
The offers convinced the clients that received them to switch their DNS to an external machine. We block outbound DNS to anything but our own servers, so the result was that the infected machined were no longer able to resolve any host names. Not a good thing, since they are primarily used as web browsers (non-proxied).
As we were wrapping up the incident, segmenting our network even further, putting in additional monitoring, and doing some additional hardening in certain areas, the Internet Storm Center posts a diary message that was timely and on topic. The subject of the message was Rogue DHCP servers.
Not even a half-day later, I was on the phone with my previous employer and 'lo and behold: they were suffering outages and seeing strange DHCP traffic. It seems that whatever site is offering this Trojan.Flush.M-malware is very effective at reaching institutes for higher education world-wide.
Symantec ranks the risk of this malware as "risk level 1: very low". I disagree with this; risk is a function of probability and impact, and looking at my own experiences, both are high. I have first-hand knowledge of at least three institutes that have been hit, and the impact of getting hit (loss of the ability to resolve hostnames) is also large.
How do we defend against this? The most important steps are to ensure proper network segmentation and providing up-to-date anti-malware software on workstations. On servers, you probably want to statically configure your DNS settings. Make sure you can monitor what's happening on your network; block outbound DNS traffic to everything except your own servers, and consider deploying hardened proxy servers for browsing.
I teach a basic undergraduate computer security class, which is a mix between ethical hacking, incident response, and a little bit of security management. My students do their assignments in a virtual security lab (7 hosts in a VMWare environment). When class is over, I'll post how I set up this lab in a little more detail.
Getting to work this morning, I found the following message in my mailbox:
Subject: host5 is down
Date: 11/25/2008 2:10 AMGood Morning,
I crashed host5 by trying to run the following exploit:
http://milw0rm.com/exploits/7091
The files that should be removed: ~mikei/data/1.c and ~mikei/data/1
~Apologies
The Forum for Incident Response and Security Teams is the premier organization and recognized global leader in incident response.
FIRST brings together a variety of computer security incident response teams from government, commercial, and educational organizations. FIRST aims to foster cooperation and coordination in incident prevention, to stimulate rapid reaction to incidents, and to promote information sharing among members and the community at large.
I recently joined the FIRST community as a liaison member, and I am looking forward to contributing to the community, as well as benefiting from the large professional network and body of knowledge that it provides.
It look like the Fall 2008 phishing season has re-opened. In the last few days, I have seen more variations of the same phishing attack than I have whole summer. The scam usually revolves around scaring users to give up their username, email address and/or password. The reasons are usually varied: ranging from expired email addresses to incorrect claim that the account was involved in illegal activities or in spam abuse.
A common message typically looks something like this:
About a week ago, I put up a quick post asking if anyone knew what kind of traffic is directed at tcp/32709. Since there did not seem to be much known about this port, I did some snooping around myself. I fired up a simple netcat port listener on port 32709 and waited for incoming connections:
$ nc -vvlp 32709 |tee 32709.log
listening on [any] 32709 ...
Warning: forward host lookup failed for hn.kd.dhcp:Unknown host
connect to [72.249.83.37] from hn.kd.dhcp [61.53.152.179] 1976
�@u)�o�=5��[CHN][VeryCD]yourname<�B4���ff��Y�T�
sent 0, rcvd 106 : Connection reset by peer
While mostly binary, there are some clues in here. Specifically [CHN] and [VeryCD]. Given the fact that all the scans that I detected originated from Chinese IP ranges, I suspect that [CHN] stands for "Chinese". Not sure if it is Chinese encoding, Chinese language, or something else.
I am preparing to head out to Defcon later this week. Unlike some of my previous trips, this time I will be carrying my laptop with me. There is some stuff that I would like to demo to some people and I also need to be able to connect back to work. The Defcon network is lovingly described as the most hostile network on Earth. While I have never had the please to attend the convention, I have no reason to doubt the complete and utter Truth of this statement.
What are the things that I fear the most (on order of importance)?
- Interception of authentication credentials
- Compromise of machine
- Theft of data
- Theft of hardware
To protect against these Bad Things from happening, I took some precautions. This time around, I I am taking a machine with me that does not contain any real data. The machine has been reinstalled from scratch specifically for this event and when I get back, it is going to be re-imaged before it is allowed back onto the network.
Rather than running Windows, I reinstalled the box with Ubuntu Linux (8.04.1) and hardened it by disabling all services and running iptables with a default deny policy on top of that.
Whenever I am going to turn on the machine, I will VPN back to a less-unsafe environment before doing anything else. On the machine, I installed VMWare server and my demo-environment runs in a host-only Virtual Machine that will not be allowed out onto the network.
Looking at the risks above, I feel reasonably comfortable that I am protected from theft of data (there is nothing to steal; all caches are set to purge automatically). The only real attack vector to pwn the box would be via a driver sploit for the wireless card (no hardware off-switch), but that's a risk I'm mitigating by only selectively removing the machine from the hotel room.
Interception of login credentials should be near-impossible if I can force myself to not do anything without VPN'ing into a safe environment using a good VPN protocol. That leaves the theft of hardware part. The impact of that happening should be small enough since the machine I am carrying has been taken out of rotation due to its age. Besides; it is not mine anyway ;)
Did I forget anything? If so, please let me know ;)
Dutch security news site security.nl features an article that reports the arrest of a 19-year old computer criminal who is accused of building a bot net containing around 100.000 nodes. The High Tech Crime Team of the Dutch national police arrested the alleged criminal at an outdoors terrass while sealing the deal with a 35-year old Brazilian.
The price of the transaction? Around 25.000 Euro's. Do the math...
The investigation was initiated in July, after the Dutch authorities received a request of the American Department of Justice. The Brazilian is being extradited to the United States. The Dutch citizen will appear before a Dutch judge today.
A vulnerability in the DNS protocol was discovered yesterday by Dan Kaminsky and announced in several places. Although it is not entirely clear if this was the first time the vulnerability was discovered, this is definitely the first time it gets acknowledged by the Internet comminity as a whole.
As I was out of the office yesterday all day, I spoke to a few colleagues today to discuss it.
Most of my co-workers are technically very skilled, which is why I was rather surprised to find out that most of them do not know in detail how DNS works. It goes too far to outline exactly what terms like recursive lookup, Query ID, root server, caching server, resolving, zone transfer, etc. mean in this post, but let me summarize the vulnerability in the way I explained it to the C-level.
"Keep information about your systems simple, neat, documented, and secure."
Especially during an emergency, the last thing you want to have to worry about is where you filed your incident response plan, your contact list, IP plan, etc. Good stuff. Go read it and be enlightened.
This might have to become an Essential Truth!
