Defcon, vendor-hacker-shmoozing, and Storm Center Handlers in the Desert
Greetings ISC readers. Being out here at Vegas for a certain hax0r fiesta that will go unmentioned, I figured Id give the readers that are not here a glimpse of the bruhaha and the goings on.
Defcon is a fascinating collection of minds bringing hacker and fed, experts and wanabees. The talks are interesting, but what I found fascinating was amount of shmoozing that vendors were bestowing upon security researchers.
Think back six years ago or so...
1. security researcher finds flaw in product Z
2. researcher contacts vendor, and gives them a timeframe for release
3. vendor makes changes
4. researcher publishes flaw to bugtraq
Post 9-11, post DMCA, post PATRIOT Act...
1. security researcher finds flaw in product Y
2. researcher contacts vendor, and gives them a timeframe for release
3. vendor accuses researcher of violating DMCA
4. researchers start to horde malware
Defcon 13 (last year)
1. security researcher finds flaw in product X
2. researcher contacts vendor, and gives them a timeframe for release
3. resercher faces potential arrest... goes to worrk for the competition
Decon 14 (this year)
1. security researcher finds flaw in product W
2. vendor shmoozes him (as in wining and dining) at fabulous parties, interviews, PR opportunities, etc.
Microsoft, Apple, and many other mega-vendors were present to diffuse the FUD.
On that note, a big thank you to Microsoft for a fabulous party :)
Last but not least we spotted several handlers in Vegas... from Cory, Jason, Ed, Marc, Kevin, Adrien, Kyle, and me... (I probably forgot about 300 people, sorry)....
Mike Poor mike < at >
Defcon is a fascinating collection of minds bringing hacker and fed, experts and wanabees. The talks are interesting, but what I found fascinating was amount of shmoozing that vendors were bestowing upon security researchers.
Think back six years ago or so...
1. security researcher finds flaw in product Z
2. researcher contacts vendor, and gives them a timeframe for release
3. vendor makes changes
4. researcher publishes flaw to bugtraq
Post 9-11, post DMCA, post PATRIOT Act...
1. security researcher finds flaw in product Y
2. researcher contacts vendor, and gives them a timeframe for release
3. vendor accuses researcher of violating DMCA
4. researchers start to horde malware
Defcon 13 (last year)
1. security researcher finds flaw in product X
2. researcher contacts vendor, and gives them a timeframe for release
3. resercher faces potential arrest... goes to worrk for the competition
Decon 14 (this year)
1. security researcher finds flaw in product W
2. vendor shmoozes him (as in wining and dining) at fabulous parties, interviews, PR opportunities, etc.
Microsoft, Apple, and many other mega-vendors were present to diffuse the FUD.
On that note, a big thank you to Microsoft for a fabulous party :)
Last but not least we spotted several handlers in Vegas... from Cory, Jason, Ed, Marc, Kevin, Adrien, Kyle, and me... (I probably forgot about 300 people, sorry)....
Mike Poor mike < at >
Keywords:
0 comment(s)
Grisoft AVG False Positive
We have heard that earlier today there was a false positive involving Grisoft AVG antivirus product and certain files related to Windows XP SP1. From the report received, AVG was reporting the file C:\i386\REG.EXE, installed under some XP SP1 based systems, as a virus. As there is a free version of AVG used/installed on many K12 school, College/University and home computers, some of our readers may experience issues with this false positive.
Unfortunately, I do not see any confirmed information on the AVG website. If anyone can confirm the details shared to us earlier, or finds a news entry at Grisoft, please share with us and we will update this diary.
Update:
TechBlog's Dwight Silverman and poster Astro discussed this very same thing earlier today at this URL: http://blogs.chron.com/techblog/archives/2006/08/now_thats_what.html. Thanks to our reader, Claus, for pointing this to us.
Keywords:
0 comment(s)
MS Patch Tuesday Advance Notice
Microsoft released their Security Bulletin Advance Notification on Thursday afternoon. Next Tuesday appears to be a very active day as there are 12 security bulletins that will be released as well as 2 High Priority (though not security based) updates. In addition, the Malicious Software Removal Tool will have its monthly update.
From http://www.microsoft.com/technet/security/bulletin/advance.mspx:
* Ten Microsoft Security Bulletins affecting Microsoft Windows. The highest Maximum Severity rating for these is Critical. These updates will be detectable using the Microsoft Baseline Security Analyzer and the Enterprise Scan Tool. Some of these updates will require a restart.
From http://www.microsoft.com/technet/security/bulletin/advance.mspx:
* Ten Microsoft Security Bulletins affecting Microsoft Windows. The highest Maximum Severity rating for these is Critical. These updates will be detectable using the Microsoft Baseline Security Analyzer and the Enterprise Scan Tool. Some of these updates will require a restart.
* Two Microsoft Security Bulletins affecting Microsoft Office. The highest Maximum Severity rating for these is Critical. These updates will be detectable using the Microsoft Baseline Security Analyzer. These updates may require a restart.
Keywords:
0 comment(s)
Packet Analysis Challenge: The Solution
First off I'd like to thank everyone who took the challenge and submitted their thoughts on the capture! The response was overwhelming and I tried to answer everyone's email. If I missed someone, please accept my apologies. A thanks as well to Jon Wohlberg from Towson University who submitted this capture and allowed me to use it for the challenge.
I would also like to send a congratulations to the four individuals who figured it out: Brandon Greenwood, Jean-Philippe Luiggi, Peter Koch and Richard Bejtlich. As a side note, Richard has a great paper entitled "Interpreting Network Traffic: A Network Intrusion Detector's Look at Suspicious Events". Specifically look at the last part "A Final Case" which talks about this type of traffic.
Last, but definately not least, thanks to Johannes Ullrich who looked at the initial traffic with me and helped to determine the initial answer . Also, Scott Fendley who sat up very late with me one night while we dug through the second capture Jon submitted and worked to confirm our initial observations. It was a great team effort!
Now for what you have really been waiting for....the answer to this traffic. (Drum roll please)
The tentative solution was initially determined from the capture that I posted with this challenge. A later capture from Jon allowed it to be confirmed. As a summary from what you were given: the traffic came from multiple IPs and all destined for one primary DNS server. There were six characteristics of the traffic that you needed to take note of:
1. The repeating IP ID which rotated using only 1, 2, or 3
2. The windows size was a constant 2048
3. The TTLs which were usually 44/45 or very close to that.
4. It was always TCP connections to the primary DNS server. No UDP traffic was captured from those IPs.
5. The 24 0x00 data bytes (keep in mind that these are SYN packets)
6. The time stamps and source ports were also helpful in determining that these were not TCP retries.
Based on these characteristics and armed with Google, it is possible to solve the puzzle. After much research, I found there were other folks questioning very similar traffic, but not totally sure of what it was. There was alot of speculation to read through. However, looking at the characteristics of the traffic, an answer quickly emerged. It appeared to be traffic generated by a load balancer. Here is the study that really led to our initial conclusion, although it did not match totally:
http://www.sans.org/resources/idfaq/dns.php
Jon then sent us a second, more complete, capture that contained other information and allowed the initial conclusion to be confirmed and identify the load balancer being used. F5 has a product called BIG-IP and one of the modules to that product is the Global Traffic Manager (formally known as 3-DNS, same functionality) is what generated this traffic.
Here are some other URLs of exactly the same traffic (to include
source IP) in order of reading recommendation:
http://archive.cert.uni-stuttgart.de/archive/intrusions/2002/09/msg00123.html
http://lists.dshield.org/pipermail/intrusions/2004-June/008100.html
http://lists.grok.org.uk/pipermail/full-disclosure/2004-August/024687.html (read the entire thread)
Thanks again everyone for your participation and I hope that you learned as much from this capture as I did. We automatically tend to assume traffic anomalies are up to no good when in reality, there may be a very logical explanation. I have had many requests for more of these challenges. It's good to know there are other folks out there who love to look at packets as much as I do. I hope to do more of these in the near future so stay tuned!
UPDATE: Frank Knobbe sent us the following. Thanks Frank!
Ever since that fateful thread in FD, we had added Snort signatures for these probes to the BleedingSnort rules. They are in the SCAN category with SIDs 2001609-2001611.
A direct link is:
http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/SCAN/SCAN_F5_BIG-IP_Probe?rev=1.9&view=log
Latest version:
http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/SCAN/SCAN_F5_BIG-IP_Probe?view=markup
I would also like to send a congratulations to the four individuals who figured it out: Brandon Greenwood, Jean-Philippe Luiggi, Peter Koch and Richard Bejtlich. As a side note, Richard has a great paper entitled "Interpreting Network Traffic: A Network Intrusion Detector's Look at Suspicious Events". Specifically look at the last part "A Final Case" which talks about this type of traffic.
Last, but definately not least, thanks to Johannes Ullrich who looked at the initial traffic with me and helped to determine the initial answer . Also, Scott Fendley who sat up very late with me one night while we dug through the second capture Jon submitted and worked to confirm our initial observations. It was a great team effort!
Now for what you have really been waiting for....the answer to this traffic. (Drum roll please)
The tentative solution was initially determined from the capture that I posted with this challenge. A later capture from Jon allowed it to be confirmed. As a summary from what you were given: the traffic came from multiple IPs and all destined for one primary DNS server. There were six characteristics of the traffic that you needed to take note of:
1. The repeating IP ID which rotated using only 1, 2, or 3
2. The windows size was a constant 2048
3. The TTLs which were usually 44/45 or very close to that.
4. It was always TCP connections to the primary DNS server. No UDP traffic was captured from those IPs.
5. The 24 0x00 data bytes (keep in mind that these are SYN packets)
6. The time stamps and source ports were also helpful in determining that these were not TCP retries.
Based on these characteristics and armed with Google, it is possible to solve the puzzle. After much research, I found there were other folks questioning very similar traffic, but not totally sure of what it was. There was alot of speculation to read through. However, looking at the characteristics of the traffic, an answer quickly emerged. It appeared to be traffic generated by a load balancer. Here is the study that really led to our initial conclusion, although it did not match totally:
http://www.sans.org/resources/idfaq/dns.php
Jon then sent us a second, more complete, capture that contained other information and allowed the initial conclusion to be confirmed and identify the load balancer being used. F5 has a product called BIG-IP and one of the modules to that product is the Global Traffic Manager (formally known as 3-DNS, same functionality) is what generated this traffic.
Here are some other URLs of exactly the same traffic (to include
source IP) in order of reading recommendation:
http://archive.cert.uni-stuttgart.de/archive/intrusions/2002/09/msg00123.html
http://lists.dshield.org/pipermail/intrusions/2004-June/008100.html
http://lists.grok.org.uk/pipermail/full-disclosure/2004-August/024687.html (read the entire thread)
Thanks again everyone for your participation and I hope that you learned as much from this capture as I did. We automatically tend to assume traffic anomalies are up to no good when in reality, there may be a very logical explanation. I have had many requests for more of these challenges. It's good to know there are other folks out there who love to look at packets as much as I do. I hope to do more of these in the near future so stay tuned!
UPDATE: Frank Knobbe sent us the following. Thanks Frank!
Ever since that fateful thread in FD, we had added Snort signatures for these probes to the BleedingSnort rules. They are in the SCAN category with SIDs 2001609-2001611.
A direct link is:
http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/SCAN/SCAN_F5_BIG-IP_Probe?rev=1.9&view=log
Latest version:
http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/SCAN/SCAN_F5_BIG-IP_Probe?view=markup
Keywords:
0 comment(s)
Tip of the Day: Turn off your Computer
A computer can not be compromissed while turned off. In particular home computers are typically only used a couple of hours a day. So why not turn it off while you don't use it? Some DSL/Cable modems have a 'disconnect' switch. This switch will usually turn off the ethernet interface of the modem. Turning off the modem alltogether is another option.
You have to be a bit careful turning off your PC making sure you still get necessary patches. Typically, the DSL/Cable modem will check for updates whenever you turn it on. For the PC: It should still regularly check for updates while turned on. Rebooting the PC may be useful to make sure all the new code is loaded. In corporate environments: Do not turn off your PC unless you talked to the network administrator first. Techniques like 'Wake on Lan" can be used to turn on the PC remotely if needed to perform backups and to patch.
A turned off PC with a BIOS password is also a reasonable deterant to protect your PC from unauthorized use. In particular at home if you would like to prevent other household members from using your PC. (note however that this will usually not protect you from more sophisticated attacks and theft)
And don't forget that this will save energy as well.
If you have any tips to share, please send them to us via the contact form.
You have to be a bit careful turning off your PC making sure you still get necessary patches. Typically, the DSL/Cable modem will check for updates whenever you turn it on. For the PC: It should still regularly check for updates while turned on. Rebooting the PC may be useful to make sure all the new code is loaded. In corporate environments: Do not turn off your PC unless you talked to the network administrator first. Techniques like 'Wake on Lan" can be used to turn on the PC remotely if needed to perform backups and to patch.
A turned off PC with a BIOS password is also a reasonable deterant to protect your PC from unauthorized use. In particular at home if you would like to prevent other household members from using your PC. (note however that this will usually not protect you from more sophisticated attacks and theft)
And don't forget that this will save energy as well.
If you have any tips to share, please send them to us via the contact form.
Keywords: ToD
0 comment(s)
×
![modal content]()
Diary Archives
Comments