…and I couldn’t be happier.  I’m going to start writing “weaponized code” instead of “exploits”.  This will totally make up for having to give up “reverse-engineering” for “deep analysis” for “legal reasons” ;) .

However you feel about people publishing exploits for the DNS flaw already, there’s a selection of them out there now, and you might as well have a look at the code if you’re a penetration tester.  Now, I’m going to give out some links to these, so if you happen to be a blackhat that relies only on this site for your exploit needs, I’m going to have to ask you to go ahead and close your browser:

  • I)ruid and H D Moore’s metasploit module (and in the context of the trunk version of metasploit) – This one’s pretty nice.  Like a good metasploit module, it has functionality built in to test a server for vulnerability.  It can’t spoof if there’s already a cached entry for the domain you’re trying to spoof, however it is smart enough to check for this ahead of time and sleep until it can try again.  This one also randomizes the domain names it’s using while it tries to guess the transaction ID.
  • Julien Desfossez’s standalone exploit – Less frills than the metasploit modules, but it gets points for being written in python with the excellent Scapy .  From the code, it looks like the domain names it’s using while guessing the transaction ID are pretty predictable:  a3.victim.com, a4.victim.com, a5.victim.com, etc. etc. etc.

I’ll talk about other exploits when I see them, if I think they’re interesting.  I’m honestly surprised it’s taken as long as it has for exploits to come out, as it’s a pretty easy vulnerability to wrap your head around, and pretty straightfoward to generate the packets.

This’ll give you something to play with in the lab whilethe Internet crumbles around you.


This about sums up my thoughts:

I guarantee that |)ruid/hdm’s exploit was not the first. Who would you prefer poisons your cache: discreet pros or kiddies with metasploit?

Thanks Dino.


The folks who put on the excellent Securabit podcast have decided to put together a quick and dirty episode-between-episodes on the recent DNS vulnerability.  They’ve decided to call these spontaneous episodes “Securabytes”, and this is the first one:

Since Dan Kaminsky doesn’t leap around the apartment to find his headset in order to podcast on a 10 minute notice at 10PM, I was grabbed off IRC to discuss the details of the vulnerability and its impact.  I had a blast recording this episode with Rob, Joel, and Martin McKeay (of the great Network Security podcast and blog).  Being able to bounce it off these guys really helped to convey not only the vulnerability itself, but what it means for admins, end users, and even penetration testers.

I hope you give it a listen, and subscribe to Securabit in your iTunes or RSS!


First, a post went up on Matasano and promptly disappeared, and now Kaminsky has posted on Doxpara:

Patch.  Today.  Now. Yes, stay late.  Yes, forward to OpenDNS if you have to.  (They’re ready for your traffic.)  Thank you to the many of you who already have.

From what I can tell, it’s out of the bag.  I haven’t done any testing to make sure, but what I’ve read makes sense.  If you’re not entirely sure about your DNS, set yourself up on OpenDNS now.

Edit: Ah to heck with it, looks like everyone knows where to find it now anyways.  Here ya go, on Halvar Flake’s blog.

Edit Edit: Actually that’s not quite right, I think, but Matasano was, and I think you can figure it out from there.

Edit Edit Edit: Well, seeing as you can find out from comments on a Slashdot post, and other blogs, here’s the juicy part of the Matasano post:

Let’s try again to convince Bob that WWW.VICTIM.COM is

This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re going to be clever (sneaky).

Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM. Mallory has an answer. We’ll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM.

Alice’s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is!

Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didn’t just say CXOPQ.VICTIM.COM was It also contained Additional RRs pointing WWW.VICTIM.COM to Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.

Patch patch patch (then play with it in your test environment).


Whenever a new sure-fire blockbuster movie sequel comes out, there’s always the attempt to wring some more cash out of the previous entries.  There’ll be a DVD box set that runs about $10 a disc, with all the previous films in one nice looking collection.  These sell well, both to people new to a series wanting to catch up, as well as long-time fans.

Dan Kaminsky’s talk at this year’s Black Hat USA conference on August 6th where he drops the new DNS 0-day will undoubtedly be the sure-fire blockbuster talk of the conference.  Kaminsky has given excellent talks on various network security topics for years now, so in the spirit of a cash-in box set, I’ve spent a little time today collecting up links to previous talks he’s given.

Most of these are in his recurring theme of “TCP/IP Black Ops”, and I have learned a lot over the years, listening to these talks.  The recent ones were fairly easy to find on Google Video, however some of the older ones required digging around a bit (mostly on the EasyNews mirror).  I’ve embedded or linked video, where available.  Some talks I could only find in mp3 format.  Some of the older Defcon talks may be available in realmedia video format on the defcon site, but I really prefer to stick to non-realmedia formats.

If you need slides to go along with the audio-only talks, it looks like most of them are available on Kaminsky’s bio page.

As I said, I’ve learned a lot from these talks, and highly recommend them to anyone else interested in getting elbows-deep into network security.  Enjoy!

If you’re handy with Gimp and create box art for a Dan Kaminsky box set, leave a comment ;-)

Defcon 9 (2001): Gateway Cryptography: Hacking Impossible Tunnels Through Improbable Networks with OpenSSH

Defcon 10 (2002): Black Ops of TCP/IP

Defcon 11 (2003): Stack Black Ops

Blackhat 2004: Black Ops of DNS

22C3: Black Ops Of TCP/IP 2005.5

Toorcon 2006 – Black Ops Of TCP-IP 2006

Shmoocon 2007 – Weaponizing Noam Chomsky (or Hacking with Pattern Languages)

Defcon 15 – Black Ops 2007: Design Reviewing The Web


Regarding “Homer Simpson and the Kimya Botnet“, a new away message for Chunkylover53 (Homer Simpson’s AOL account, revealed in one of the episodes, and since hijacked) drops some names:

KRYOGENIKS EBK and DEFIANT RoXed HOMER sHouTz To VIRUS Warlock elul21 coll1er and Slacker.

I wouldn’t advise keeping him on your buddy list at this point, as the account is pushing out malware occasionally.


I was just going to del.icio.us this, write a snippet on it, and let it post on the daily links update, but I don’t think I could quite squeeze what I have to say about this into the size limitation there.  Read this, then come back here:

Regarding this:

Although the exploits that we have seen so far do not yet appear to be functional, they appear to have the right general idea in their exploitation.

Why would you test an non-public that’s not “functional” in the wild?  Reasons given:

It is possible that these exploits either have been leaked and are “in-work”, or that they are functional on some platform that we have not tested.

Again, even if I’m not that bright and I’ve managed to get ahold of leaked private stuff, I can’t imagine being dumb enough to start using it before I’ve verified that it works at least on some percentage of the targets.  The the latter reason seems to me like the only one that makes sense.  There’s a very good chance this works on something.

Kudos to Symantec for the information.  I’m not questioning their take on the situation or anything, I just think that people should think about it for a moment and evaluate what the most likely situation is here.


Update: Check out the comments!  Supposedly it’s patched but I tried it again and it worked.  I probably caught them in the middle of a fix, so it’ll probably be fixed soon, maybe by the time you read this. OK, it’s patched, for-real now!

The post is still worth reading if you’re interested in CSRF vulnerabilities, though.  A friend of mine read it, with no previous knowledge and then found an even better vulnerability in an even bigger app than this in what seemed like minutes. I’m totally jealous.

The quick and dirty: By viewing a page on a completely unrelated site while logged into Twitter, you can be forced to post something to your Twitter that you did not intend to post.


If you have a valid login session with Twitter going right now, click here to make yourself post an inspirational message about me. Nevermind the certificate: the same can be done with a good cert.

This still works, but I’m going to go ahead and post about it for a few reasons:

  1. It’s not easy to figure out where you’re supposed to submit or email security concerns to Twitter. I submitted something to http://twitter.com/help/, but I don’t even know if anyone read it.
  2. Regarding (1), if you search Google for: twitter “security contact” right now, it turns out that I’m the first hit.
  3. If someone manages to trick you into posting something to your twitter, it’s bad, but it’s not exactly the end of the world.
  4. It’s fairly easy for you, as a Twitter user, to avoid it.
  5. It’s a good, simple, real-world example of CSRF and might get you thinking about how handle this in your own applications.

For those of you who are new to the concept, Cross-Site Request Forgery (CSRF) is an attack where a page on one site causes the user’s browser to submit a request to another site. If the browser has a valid cookie for a logged-in session on the target site, then requests can be made to do very bad things. It’s easy to make cross-site GET requests: just put your URL with the parameters you want to send into an img tag. It’s only slightly less trivial to do the same with POSTs, which requires a little bit of javascript.

One good way to protect against CSRF attacks is to have an unpredictable, generated token as a hidden value in each form presented to the user, and to check that token when the form is submitted. If the page that is submitting a request to the other site can’t guess what the token is, then the request fails. If you look at the Twitter interface’s update form, it looks like they implement this kind of protection:

<form action="/account/update_send_via" id="send_via_form"
 method="post" onsubmit="new Ajax.Request('/account/update_send_via',
{asynchronous:true, evalScripts:true, 
parameters:Form.serialize(this) + '&authenticity_token='
+ encodeURIComponent('0e7c1206546db5df229099cf9e8a7cb503d25cab')});
return false;"><div style="margin:0;padding:0"><input
name="authenticity_token" type="hidden"
value="0e7c1206546db5df229099cf9e8a7cb503d25cab" /></div>
               <input checked="checked"
               type="radio" value="im" />
       <label for="current_user_send_via_im">im</label><br /> 

<input id="current_user_send_via_none"
       onclick="$('send_via_form').onsubmit()" type="radio"
       value="none" />
       <label for="current_user_send_via_none">web-only</label>

I actually didn’t even try to CSRF the above. There’s an “authenticity_token” input, which looks to be the token I mentioned above. It’s all very complicated looking, and I didn’t feel like bothering with it when I knew what I really ought to be looking at: the mobile interface.

Twitter’s mobile interface, which you can switch to at the bottom of your Twitter page, has a much simpler form for updating:

<form action="/status/update" method="post">
<input type="hidden" name="source" value="mobile" />
<input type="text" name="status" id="status" 
maxlength="140" class="i" value=""/>
<input type="submit" value="update" class="b"/>

Much easier. I whipped up this test HTML and put it on my web space:

function post_form()
<body onLoad='post_form()'>
<form action='http://m.twitter.com/status/update' 
name='twitform' method='POST'>
<input type='hidden' name='source' value='mobile'>
<input type='hidden' name='status' value="I truly believe 
@McGrewSecurity to be the nicest guy I've ever known. http://tinyurl.com/3fjvn5">

Then, I navigated to it, and was surprised to see…

Bad news and good news for the attacker. Bad news: it checks the referrer. Good news: it comes right out and tells us what we need to do. There are a few situations where HTTP_REFERER is suppressed. The easiest way we can make this happen is by hosting the code at an https:// URL.

If you have a valid login session with Twitter going right now, click here to allow a page to post a message about me to your Twitter.  For the example to work, you’ll need to accept the certificate, however there the same trick will work if the site has a properly signed cert.  There are other situations where HTTP_REFERER is not passed: local files and FTP URLs, for example.

If you want to avoid falling prey to this until it is patched, it’s pretty simple: use a third-party Twitter client and leave yourself logged out of the web-based interface unless you need it at the moment. If you’re a serious Twitter user, you’re probably already doing this.


This is why you should have an RSS reader pointed at this site!  You may otherwise miss out on some very strange things.  Thanks to a friend of mine giving me a call this morning and waking me up, I had this taken care of pretty quickly.  If you missed it:

hacked hah

There goes all my cred :) . Apparently the guy who runs this script kiddie haven finally found out about this post.  I was wondering when that would happen. Apparently even the barely-literate can knock over a WordPress blog.

Let’s go to the logs! 

20080402.log: - - [02/Apr/2008:07:55:24 -0400] "GET /wp-login.php?action=lostpassword HTTP/1.1" 200 799 "http://www.mcgrewsecurity.com/wp-login.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

20080402.log: - - [02/Apr/2008:07:55:29 -0400] "POST /wp-login.php?action=lostpassword HTTP/1.1" 302 20 "http://www.mcgrewsecurity.com/wp-login.php?action=lostpassword"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

20080402.log: - - [02/Apr/2008:07:55:31 -0400] "GET /wp-login.php?checkemail=confirm HTTP/1.1" 200 645 "http://www.mcgrewsecurity.com/wp-login.php?action=lostpassword"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

20080402.log: - - [02/Apr/2008:07:55:48 -0400] "GET /wp-login.php?action=rp&key=QA3Ex6N HTTP/1.1" 302 20 "http://us.mc587.mail.yahoo.com/mc/showMessage?fid=Inbox&sort=date&order=
%2FFfbQMiqwTF%2Fp8,1_386934_ALxkxEIAAYHqR%2FFaSAIQbVuPve4," "
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

20080402.log: - - [02/Apr/2008:07:55:51 -0400] "GET /wp-login.php?checkemail=newpass HTTP/1.1" 200 641 "http://us.mc587.mail.yahoo.com/mc/showMessage?fid=Inbox&sort=date&order=do
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

20080402.log: - - [02/Apr/2008:07:57:11 -0400] "GET /wp-login.php HTTP/1.1" 200 860 "http://us.mc587.mail.yahoo.com/mc/showMessage?fid=Inbox&
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

20080402.log: - - [02/Apr/2008:07:57:17 -0400] "POST /wp-login.php HTTP/1.1" 302 20 "http://www.mcgrewsecurity.com/wp-login.php"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

20080402.log: - - [02/Apr/2008:07:57:19 -0400] "GET /wp-admin/ HTTP/1.1" 200 2669 "http://www.mcgrewsecurity.com/wp-login.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/"

This is followed by him going to town in my WordPress admin panel.  Check out how he gets in, though.  He’s uses the “lost password” functionality, then comes back in as if the password email were sent to a yahoo account under his control.  Either he brute forced a password (changed to a much stronger one now!) and POP’d the email to his Yahoo account (nope, my host grepped the mail server logs),  there’s some 0-day in WordPress’ password recovery, or there’s something else I’m just missing.  I unfortunately don’t have whatever he POST’d to that form.  I’ll be going through the logs more carefully over the next few days probably.  In the meantime, if you’re a web app bug hunter, you might want to take a good look at this part of WordPress 2.5.  

Edit:  Scratch that, it was something I was missing.  Attacker grabbed the username from a PHP error, and bruted an unfortunately bad database password.  Nothing to see here :) .  I should have known better than to attribute an obvious skiddie attack to 0-day so quickly.

Check out what other miserable things this IP address has been up to on the Internet, as revealed by Google:

The owner of this range of IP addresses, http://servercentral.net/ , is being notified.  I’m not sure what SecAnalyst has to do with any of it, but I doubt that taking my site down for an hour or so is worth being implicated in with some more serious scams.
I’ll post updates if and when there are any.

Since I bought my MacBook, I’ve been primarily using Safari, so I haven’t paid as close attention to the recent Firefox vulnerabilities as I should have. I did, however, read about one in the very fresh release (and older). It’s a directory traversal exploit that allows sites to remotely include things that are in Firefox’s program directory. It’s completely trivial to do as well:


I’m partially posting this because it’s a very simple vulnerability with some interesting impact, but also because I really like 0×000000.com . If you don’t already have it in your feed reader, you need to throw it in there.


Videos of this past year’s Blackhat conference in Vegas are now available on mirrors.easynews.com (a great place to pick up all sorts of hacker conference materials and media). Some of the talks seem very interesting (especially the “extended” edition of “Tactical Exploitation”), and I’m eager to dig into them:


Audio is also available if you go up a directory, or search for Blackhat on iTunes (I’ve loaded up my iPod).

© 2012 McGrew Security Suffusion theme by Sayontan Sinha