Wired has an article that says U.S. researchers have identified one of the coders behind the attacks on Google. It appear that he was tracked down using a posting on a hacking forum with code used in the attack, unfortunately it does not provide specifics on any of the details involved. It does mention that he only wrote part of the code involved, again no more details.
In cases like these the coder posting code to forums or mailing list are almost the only way to track code back to anyone specific. Even with that, if the code was posted by a individual it may not be the same one who used it.
The quotes from the researchers in the article hint at them knowing more about what’s going on then is revealed. Information like this is interesting but you really would not want to see anyone fire or worse in the coders case, because it has been released.
The article is here http://www.wired.com/threatlevel/2010/02/us-pinpoints-coder-behind-google-attack/
It does have a link inside to the Financial Times, but you need to register to get it all.
With everything in place you can now start suricata.
suricata -c /usr/local/etc/suricata.yaml -i em0
Got a good start.
70 rule files processed. 7977 rules succesfully loaded, 5 rules failed
Here is the 5 that did not load, I only added the emerging threats rules not the snort release set ( those caused Suricata to crash ).
 20/2/2010 -- 22:20:51 - (detect-bytetest.c:267) (DetectBytetestParse) -- [ERRCODE: SC_ERR_INVALID_OPERATOR(111)] - Invalid operator  20/2/2010 -- 22:20:51 - (detect.c:291) (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(29)] - Error parsing signature "alert udp $HOME_NET 1024:65535 -> $EXTERNAL_NET 1024:65535 (msg:"ET P2P eMule KAD Network Hello Request (2)"; content:"|e4 10|"; depth:2; byte_test:2,<=,65535,16,relative; byte_test:2,<=,65535,0,relative; threshold: type limit, count 5, seconds 600, track by_src; classtype:policy-violation; reference:url,emule-project.net; reference:url,doc.emergingthreats.net/2009971; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/P2P/P2P_eMule; sid:2009971; rev:4;)" from file /usr/local/etc/suricata/rules/emerging-p2p.rules at line 194  20/2/2010 -- 22:20:52 - (detect-distance.c:48) (DetectDistanceSetup) -- [ERRCODE: SC_ERR_DISTANCE_MISSING_CONTENT(88)] - distance needs two preceeding content options  20/2/2010 -- 22:20:52 - (detect.c:291) (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(29)] - Error parsing signature "alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Egspy Infection Report via HTTP"; flow:established,to_server; uricontent:"/keylogkontrol/"; content:"|0d 0a|User-Agent|3a| Mozilla/3.0 (compatible|3b| Indy Library)"; distance:0; classtype:trojan-activity; reference:url,research.sunbelt-software.com/threatdisplay.aspx?name=EgySpy&threatid=48410; reference:url,doc.emergingthreats.net/2008047; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Egyspy; sid:2008047; rev:2;)" from file /usr/local/etc/suricata/rules/emerging-virus.rules at line 915  20/2/2010 -- 22:20:52 - (detect-distance.c:48) (DetectDistanceSetup) -- [ERRCODE: SC_ERR_DISTANCE_MISSING_CONTENT(88)] - distance needs two preceeding content options  20/2/2010 -- 22:20:52 - (detect.c:291) (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(29)] - Error parsing signature "alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Generic Spambot (often Tibs) Post-Infection Checkin"; flow:established,to_server; uricontent:"/access.php?"; nocase; uricontent:"w="; nocase; uricontent:"&a="; nocase; content:"|0d 0a|Host\: "; distance:0; pcre:"/Host\: \d+\.\d+\.\d+\.\d+\x0d\x0a/"; content:"|0d 0a|Cache-Control\: no-cache|0d 0a|"; content:!"|0d 0a|User-Agent\: "; classtype:trojan-activity; reference:url,doc.emergingthreats.net/2008174; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Tibs; sid:2008174; rev:2;)" from file /usr/local/etc/suricata/rules/emerging-virus.rules at line 2240  20/2/2010 -- 22:20:52 - (detect.c:335) (SigLoadSignatures) -- [ERRCODE: SC_ERR_NO_RULES(32)] - No rules loaded from /usr/local/etc/suricata/rules/emerging-web.rules  20/2/2010 -- 22:20:55 - (detect-uricontent.c:303) (DoDetectUricontentSetup) -- [ERRCODE: SC_ERR_NO_URICONTENT_NEGATION(92)] - uricontent negation is not supported at this time. See bug #31.  20/2/2010 -- 22:20:55 - (detect.c:291) (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(29)] - Error parsing signature "alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET USER_AGENTS Suspicious Mozilla User-Agent - Likely Fake (Mozilla/5.0)"; flow:to_server,established; content:"|0d 0a|User-Agent\: Mozilla/5.0|0d 0a|"; nocase; uricontent:!"|0d 0a|Host\: download.releasenotes.nokia.com"; content:!"Mozilla/5.0|0d 0a|Connection\: Close|0d 0a 0d 0a|"; classtype:trojan-activity; reference:url,doc.emergingthreats.net/2009295; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/USER_AGENTS/USER_Agents_Suspicious; sid:2009295; rev:6;)" from file /usr/local/etc/suricata/rules/emerging-user_agents.rules at line 483  20/2/2010 -- 22:20:55 - (detect-distance.c:48) (DetectDistanceSetup) -- [ERRCODE: SC_ERR_DISTANCE_MISSING_CONTENT(88)] - distance needs two preceeding content options  20/2/2010 -- 22:20:55 - (detect.c:291) (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(29)] - Error parsing signature "alert udp any any -> any 53 (msg:"ET CURRENT_EVENTS DNS BIND 9 Dynamic Update DoS attempt"; byte_test:1,&,40,2; byte_test:1,>,0,5; byte_test:1,>,0,1; content:"|00 00 06|"; distance:8; content:"|c0 0c 00 ff|"; distance:2; reference:cve,2009-0696; classtype:attempted-dos; reference:url,doc.emergingthreats.net/2009701; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Bind; sid:2009701; rev:3;)" from file /usr/local/etc/suricata/rules/emerging-current_events.rules at line 65  20/2/2010 -- 22:20:55 - (detect.c:376) (SigLoadSignatures) -- 70 rule files processed. 7977 rules succesfully loaded, 5 rules failed  20/2/2010 -- 22:20:55 - (detect-engine-sigorder.c:787) (SCSigOrderSignatures) -- ordering signatures in memory SCSigOrderSignatures: Total Signatures to be processed by thesigordering module: 7989
Let’s to check to make sure the ids system is logging, check the config file for the logging dir, the default is /var/log/suricata/. You may have to create a noise rule ( any any -> any any ), but there should start to be alerts hitting the fast.log file.
Now that we know it kinda works, there is some configuration to do in part 3.
Installation of Suricata on FreeBSD i386.
Step by step.
cd /usr/ports/devel/pcre/ make install clean cd /usr/ports/textproc/libyaml/ make install clean cd /usr/ports/net/libnet/ make install clean mkdir /usr/local/pkgs/ cd /usr/local/pkgs/ fetch http://www.openinfosecfoundation.org/download/suricata-0.8.1.tar.gz tar -zvf suricata-0.8.1.tar.gz cd suricata-0.8.1 ./configure && make && make install
Move the config file to somewhere nice
cp suricata.yaml /usr/local/etc/ vi /usr/local/etc/suricata.yaml
Change `default-rule-path: /etc/suricata/rules/` and `classification-file: /etc/suricata/classification.config`, lets put them in the proper place.
mkdir /usr/local/etc/suricata/rules mkdir /var/log/suricata
We can populate the rules folder with something while we are at it.
cd /usr/local/etc/suricata/ fetch http://www.emergingthreats.net/rules/emerging.rules.tar.gz tar -xvf emerging.rules.tar.gz
You are also going to need some files from the snort ruleset release, go over to snort.org and register.
Get the latest release and unpack it just like the emerging set.
cd /usr/local/etc/suricata/ tar -xvf snortrules-snapshot-2.8.tar.gz
You really don’t need the entire set you just need one file specifically, the classification.config file. But we will pick that up in part 2.
I passed 70-642 with a solid 925/1000, I did not find the material specifically challenging but I am glad I had my previous experience with the CISSP. I don’t think I have any problems in how the material for 70-642 is presented in the self study kit, I just wish it had more depth in the technical aspects of the protocols involved in networking.
Personally with my own path I have taken, I found that understanding the protocols and functionality leads to understanding the configuration of devices involved. Looking at VPN or routing issues in environments with devices that you could have no experience on, you are able quickly identify the problem and the solution. The step in-between the problem and the solution is going to specific to the devices involved, once you know what needs to be done the fix is that much faster to implement.
A few weeks back I was asked to recover a ESX 3.5 host that had VM that was in a strange state. The VM was supposed to have been DMotion over to another datastore but it had failed. The VM was still running but no operations were possible on it, I could not edit it or control the power state.
When I checked the datastore with the VM it had it’s disks in the original datastore but the rest of the vm had been moved to the new location.
The datastore with the disks had several files inside that looked like snapshot files but named differently. In the virtual center console I tried to take / commit a snap shot thinking it might commit the disks and the DMotion files but it was the same as the rest of the options.
I was how ever able to commit the disks using the command line utilities on the console. By first creating a snapshot, them committing them. ( vmware-cmd ) is used for that. DMotion is something that I had never used before so after a quick bit of research I found the rest of the steps to recovery the VM back to a stable state.
The VM still thought it was being moved so you have to manually edit the vmx file.
The full instructions are here, http://www.van-lieshout.com/2009/03/how-to-recover-from-failed-svmotion/
Microsoft just released an advisory to this in the last couple days, I have been following this since October last year. http://support.microsoft.com/kb/977377
The basic premise of the attack is a man in the middle attack using SSL renegotiation. Here is what a basic attack would look like.
When Jimmy connected to the wireless network Sam (the attacker) poisoned his ARP cache and now all of Jimmy’s traffic is flowing through Sam’s laptop and then out to the internet.
When the connection to https://e-banking.com came through Sam’s laptop he held back those packets (Session #1) and opened a new connection to https://e-banking.com (Session #2). Sam then completes a full TLS handshake and triggers a renegotiation of the tunnel (This is a standard function of the protocol).
Then Session #1 that was held back is released to https://e-banking.com, this is done over the encrypted Session #2 tunnel. The server receives the Session #1 connection and associates the session with Sam (attacker) and not Jimmy (again this is expected behavior of the protocol, the server was expecting a renegotiation and a new connection looks exactly the same).
At this point Jimmy has no idea what has happened his browser still says he is connected to the site and that the SSL certificate is trusted.
This is overly simplified example of what could be done in a case like this.
Jimmy sends a get command to do a fund transfer.
GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=1234567 HTTP/1.1 Cookie: victimscookie
Sam gets this or any other packet with the cookie in it and adds the following.
GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=9876543 HTTP/1.1 X-Ignore-This:
After the X-Ignore-This Sam adds the information from Jimmy’s packet, and ends up with this when it arrives at the server.
GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=9876543 HTTP/1.1 X-Ignore-This: GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=1234567 HTTP/1.1 Cookie: victimscookie
The web server ignores the legitimate request because of the X-Ignore-This but processes the other GET request and uses the Cookie for authentication.
This exact setup was just proven using twitter by a researcher and they were able to get twitter to ‘tweet’ back the usernames and passwords from the high jacked sessions.
Here is a link to the story about the Twitter attack, http://www.theregister.co.uk/2009/11/14/ssl_renegotiation_bug_exploited/
The team at isc.sans.org has an BETA version of hash checking application. http://isc.sans.org/tools/hashsearch.html
I tired a few files from a FreeBSD machine I have, but it was not able to locate a match. I am sure there would have been more success if files from a Windows based system had been tried.
This will be an excellent tool to verify the integrity of files on systems, more then once I have been in a situation where I needed to validate the integrity of a file with out a know good sample available.
If the status of a machine is in question I would not even collect the has off the system while it is running, booting into a liveCD like Knoppix ( http://www.knoppix.org/ ) or my favorite FreeBSD ( http://www.freebsd.org/where.html ) is the best way to ensure the integrity of the hash.
On freebsd you can use the md5 or sha1 command.
> md5 /lib/libc.so.7
MD5 (/lib/libc.so.7) = e16f4e5c137bd7f445b32733f45ac268
After a lot of discussion on the sans diary ( sans.isc.sans.org ) it appears the MS10-015 rebooting machines have been traced back to a root kit (Tdss), more information about it can be found at http://www.prevx.com/blog/139/Tdss-rootkit-silently-owns-the-net.html . Emergingthreats.net has had signatures since Oct & Jan 09 and from some of the reports out, the major AV vendors are able to detect it as long as it is not running on the infected OS.
Now it’s going to be a race between system administrators to apply the MS10-015 to detect the root kit and the malware authors to update it so the patch won’t cause the system to blue screen and reveal the infection.
The number of reports of users having issues with the blue screen is surprising, cases like this are excellent reasons to have effective NIDS deployed. Malware like Tdss needs to check in and when it does that it cannot hide anymore.
The full discussion is available here http://isc.sans.org/diary.html?storyid=8209#comment .
I have been following this since there was first talk of creating a new engine. They have released version 0.80.
The engine is to load the current Snort rule sets and VRT rule sets out of the box!
Once I complete my exam this week I will have some extra time and will provide install instructions for FreeBSD.
The list of what they have added is extensive. (A the list to come is pretty long) There is more features on the way, listed in the official documentation.
Automatic Protocol Detection
– IP, TCP, UDP, ICMP, HTTP, TLS, FTP and SMB.
Independent HTP Library
– A total independant HTP libary that is also released under the GPLv2.
Standard Input Methods
– You can use NFQueue, IPFRing, and the standard LibPcap to capture traffic.
– You can use your standard output tools and methods with the new engine, 100% compatible!
– It’s possible to capture information out of a stream and save that in a variable which can then be matched again later.
Fast IP Matching
– The engine will automatically take rules that are IP matches only (such as the RBN and compromised IP lists at Emerging Threats) and put them into a special fast matching preprocessor.
HTTP Log Module
– All HTTP requests can be automatically output into an apache-style log format file. Very useful for monitoring and logging activity completely independent of rulesets and matching. Should you need to do so you could use the engine only as an HTTP logging sniffer.
Find can be given multiple date constraints to narrow down the results returned.
`find /vmfs/volumes/ -mtime +1 -mtime -10 -type -f -name “*00*.vmdk”`
Will locate files that where the file was last modified at least 1 day ago (-mtime +1) but not more then 10 (-mtime -10).
Find has several parameters to work with dates.
ctime – Locate items by the last status change time.
atime – Locate items by the last access time.
mtime – Locate items by the last modified time.
You can also get more granular on the time tests. With -amin, -cmin, and -mmin.
The -name is not specifically needed, you could also use a regular expression to locate the files that are needed.
find /vmfs/volumes/ -regex ‘.*[0-9]+\.vmdk$’ -type f
While the regular expression is useful it will preform the regex on the path returned as well so the results will differ from searching `/vmfs/volumes/` and `.`.
The full find man page is online here http://linux.die.net/man/1/find or you can type `man find` on the esx console.