November 04, 2007
Interpretting a honeypot report
Honeypot.org has been trying to learn more about computer security and active exploits for years. Recently they had a browser in a Virtual Machine visit 300,000 URLs and record what happened. A honeypot is a network that pretends to be vulnerable and collects data about what is being done maliciously. This is done to see what exploits are being used today and what kind of defenses are effective. First they scanned with IE6 SP2. Then they surfed the "most malicious" of the URLs (about 30,000) with Firefox 1.5 and Opera 8.0. But Firefox or Opera was never infected. They attributed Firefox's exploit resistance to its built-in patching mechanism which makes it harder to exploit (shorter vulnerability window), and therefore also a less popular target. They also used black lists from MVPS.ORG and STOPBADWARE.ORG to see if they made a difference. A black list is a list of bad web-sites and they are used by many Anti-Spyware programs to alert you when you visit a site known to host malware. For years black lists have been scorned as ineffective since there were so many and they changed so rapidly. What this study found was that they did work. While the lists only identified about 12% of the sites as malicious, the majority of them called another site to download the actual malware. Most of those sites were on the lists. Most infections came from
- adult sites (57%)
- links in spam (16%)
- warez sites
- typos (e.g. googel.com instead of google.com)
- news sites,
- user content sites (blogs,...)
- music sharing
- write the attack code to disk
- execute the program with either a WScript.Shell object or Shell.Application object.
note: Microsoft supposedly disabled those exploits in 2004
- If a patched IE6 SP2 is used then use QuickTime or WinZip, with Microsoft's web view
- Several malicious EXEs were created on the client computer
- a service is set to run at startup.
- connect to a "malicious data collection server" (their wording).
- use encrypted traffic (some text was in the clear)
- note The data collection server was in Moldavia; it was registered to someone in the Ukraine.
- note The exploit server was in Russia, and registered to someone in Germany.
- Use a browser under a non-administrator account or in a sandbox (sandboxie, Amust, VMWARE, VCP)
- Use a Personal Firewall that blocks inbound and outbound traffic and have it configured by an expert.
- Use a blacklist but keep it up-to-date.
- use Secunia Software Inspector to identify known vulnerabilities in software applications.
- pay attention to Google's warnings when you are searching. Google lets you know that a site is known to be potentially harmful.
- Use of a non-mainstream web browser to be less of a target like Opera.
- the forum mentioned could have avoided problems by either not allowing posts with HTML
SECSIG meets in the Science building 203 at 11:15 am.
By attending the SECSIG you can ask questions and open discussions about troubling situations you are having now.
The RSS feed address is http://ocsecsig.blogspot.com/atom.xml
Dave Keays, SIG leader