ICANN: Initial Report of the GNSO Fast Flux Hosting Working Group

Thursday, January 29. 2009
Fast-Flux Service Networks is a phenomenon I covered in this blog a couple of times earlier on. We als published two papers on this topic and made the data collected during our study available. Back in May 2008 ICANN had formed a working group to address this problem which should answer the following questions:
  • Who benefits from fast flux, and who is harmed?

  • Who would benefit from cessation of the practice and who would be harmed?

  • Are registry operators involved, or could they be, in fast flux hosting activities? If so, how?

  • Are registrars involved in fast flux hosting activities? If so, how?

  • How are registrants affected by fast flux hosting?

  • How are Internet users affected by fast flux hosting?

  • What technical (e.g. changes to the way in which DNS updates operate) and policy (e.g. changes to registry/registrar agreements or rules governing permissible registrant behavior) measures could be implemented by registries and registrars to mitigate the negative effects of fast flux?

  • What would be the impact (positive or negative) of establishing limitations, guidelines, or restrictions on registrants, registrars and/or registries with respect to practices that enable or facilitate fast flux hosting?

  • What would be the impact of these limitations, guidelines, or restrictions to product and service innovation?

  • What are some of the best practices available with regard to protection from fast flux?

Since a few days the initial report of this working group is available and the report is an interesting read. Public comments should be sent directly to ICANN until February 15, 2009 - so if you have comments, please send them to ICANN.

Posted by Thorsten Holz in malware, paper at 23:50 | Comments (0) | Trackbacks (0)

Storm Worm, Encryption, Disruption, and more...

Saturday, January 17. 2009
Dancho did an interview on the topic of Storm Worm, in which some wrong facts are described by Georg Wicherski, who said: "On the 24c3 congress at the end of 2007, Thorsten Holz gave a presentation on disrupting Zhelatin’s command and control infrastructure, involving a /16 network or 65536 nodes in other terms." This statement is wrong: we did not use 65536 machines, but just 2 machines - one machine in Sophia Antipolis, France and the other one in Mannheim, Germany. Actually everything is also possible with just one machine: the second machine was just used for measurements and to verify the results. I'm not sure what caused this confusion, presumably they did not read our paper on the topic :)

We also found out that the "authentication" used by Storm is very weak: The four byte XOR key is a simple obfuscation scheme, whereas the 64bit RSA needs a little bit more work to break the crypto. Actually we published our results back in April 2008 during the First USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET '08), a fact that some people seemed to have missed. Frederic Dahl also summarized all of these aspects in his diploma thesis which was published in March 2008.

My presentation from back then is available as "Measurements and Mitigation of Peer-to-Peer-based Botnets" and I also did a talk during the work-in-progress session on the crypto aspects of Storm Worm: "Other Aspects of Storm Worm".

Nowadays Storm Worm is not a very interesting botnet, we actually stopped the crawler several months ago since not many infected machines are still online in the network...
Posted by Thorsten Holz in malware at 12:03 | Comments (2) | Trackbacks (0)

Using Honeypots to Study Web-based Attacks

Wednesday, January 14. 2009
The Internet Storm Center has an interesting entry on how to use honeypots to capture attacks against web-applications: "Roundcube Webmail follow-up":
A fermented honeypot is one that has been set up based on exploit attempts identified by a first stage honeypot. What happens is that the attacker(s) get all sticky in the original honeypot and when they come back for more sweetness, they get the fermented honeypot too. Now, along with getting all sticky in the first honeypot, they get all drunk on excitement in the fermented honeypot. [...] Development of a fermented honeypot is not without effort. There is no typical Win32 click-n-create nonsense. A fermented honeypot must be specifically crafted to correctly emulate the focused attack. The author, or 'brew master', is well capable of taking a traditional honeypot and fermenting it accordingly.

Basically they first observe the scanning/exploitation attempts against the Roundcube html2text.php vulnerability and then set up a second-stage honeypot that responds to these scanning attempts, offering more bait for the attacker. This is a good example how honeypots work and it also helps them to observe the actual infection of a vulnerable system.


Posted by Thorsten Holz in honeynets at 23:08 | Comments (0) | Trackbacks (0)

Malicious PDFs Analysis Continued

Monday, January 12. 2009
CWSandbox
After my initial posting about the possibility to analyze PDF files with CWSandbox we received a few more such samples. In all cases the PDF file exploits a vulnerability in Acrobat Reader once the file is opened. With the help of CWSandbox it is possible to observe this exploit and also the actions of the malware after the compromise (e.g., downloading of additional malware from another server). Please find below three additional examples of such reports:

If you happen to have more malicious PDFs, please submit them at cwsandbox.org :-)
Posted by Thorsten Holz in CWSandbox, malware at 13:18 | Comments (0) | Trackbacks (0)

Call for Papers: LEET'09 and EuroSec'09

Saturday, January 10. 2009
Just a quick reminder of two upcoming deadlines for workshops I am involved with:

Looking forward to your submissions!

Posted by Thorsten Holz in paper at 11:03 | Comments (0) | Trackbacks (0)
(Page 1 of 2, totaling 6 entries) » next page