DEFCON SSL Compromise? NO!

[Dark Tangent]

I was working on the forums with my laptop on wireless and all of a sudden Firefox 3.01 warns me that the SSL cert for forum.defcon.org is not not signed by a trusted root!!

RED ALERT!

I checked on a different laptop on a different network, and everything is fine. What is going on?

I compare cert fingerprints and they do not match.. then I realize I am using tor on my wireless laptop, and not on my other, working, one. Is someone with an evil exit node targeting defcon.org? NO! I try to log into https:/twitter.com and get the same error!

They are dynamically creating false ssl certs where all the data matches EXCEPT the md5 / sha1 fingerprints do not match. I should go back to my logs and find out the exit node that is evil..

[TheCotMan]

I was working on the forums with my laptop on wireless and all of a sudden Firefox 3.01 warns me that the SSL cert for forum.defcon.org is not not signed by a trusted root!!

RED ALERT!

I checked on a different laptop on a different network, and everything is fine. What is going on?

I compare cert fingerprints and they do not match.. then I realize I am using tor on my wireless laptop, and not on my other, working, one. Is someone with an evil exit node targeting defcon.org? NO! I try to log into https:/twitter.com and get the same error!

They are dynamically creating false ssl certs where all the data matches EXCEPT the md5 / sha1 fingerprints do not match. I should go back to my logs and find out the exit node that is evil..

Maybe hackers are trying to steal access to the secret defcon 16 web-space. :-)

More likely? They are trying to steal credentials from people connecting to any and all https sessions: banks, IM, chat, and more, and not just targeting defcon.org.

The problem with detecting them, is that they are probably smart enough to re-tor their "exit" session through a kind of proxy, and then re-enter the tor network to make the real node more difficult to spot.

[Dark Tangent]

This time while NOT running tor I got someone trying to MITM forum.defcon.org and I've got pics!!

Here is a copy of the cert that was presented:

http://www.defcon.org/images/dtangent/-.opendns.com.txt

First is how it looked on Forefox:

http://www.defcon.org/images/dtangent/bad-forum.defcon.org.ssl.cert.png

Then how it looked on IE 7

http://www.defcon.org/images/dtangent/bad-forum.defcon.org.ssl.cert-ie.png

Then what happens when I temporarily accepted the cert:

http://www.defcon.org/images/dtangent/bad-forum.defcon.org.ssl.cert-ie-error.png

I waited about 30 minutes, tried again, and it worked normally.

WTF?

[TheCotMan]

This time while NOT running tor I got someone trying to MITM forum.defcon.org and I've got pics!!

Here is a copy of the cert that was presented:

http://www.defcon.org/images/dtangent/-.opendns.com.txt

[image chop]

I waited about 30 minutes, tried again, and it worked normally.

WTF?

With the comment seen above, in your image, I would suspect DNS reply.

You can try an experiment. From the same location, alter you client's /etc/hosts (or appropriate location for "hosts") to specify an IP address in use by opendns for thier ssl server but specify the hostname to be forum.defcon.org

Next, quit your browser (in case of dns caching) and if running an OS that tries to be helpful with more DNS caching, flush that, or reboot, whichever is easier, then start a web browser and navigate again to http://forum.defcon.org/

Do you see the same results? If so, then I would suspect:
*) Mistake in the DNS server configuration.
*) Cache poisoned DNS server.
*) MiM DNS reply (or blind "MiM" DNS reply) to lookup with crafted response specifying an alternate IP address

Also, visit https://www.opendns.com/ and then view their cert, and export it to a file. Then compare the text you downloaded to the cert you exported. They look the same to me.

Strongly suggesting that when your web browser asked for DNS resolution to pics.defcon.org or whatever you were looking for, it was given an IP address to server serving *.opendns.com content from them or someone else.

[Dark Tangent]

Cot, I think you could be correct. It seems very unlikely that opendns got their cert stolen, but also strange that somehow they would inject themselves into an http://forums.defcon.org/ request. I must ponder.

With the comment seen above, in your image, I would suspect DNS reply.

You can try an experiment. From the same location, alter you client's /etc/hosts (or appropriate location for "hosts") to specify an IP address in use by opendns for thier ssl server but specify the hostname to be forum.defcon.org

Next, quite you browser (in case of dns caching) and if running an OS that ries to be helpful with more DNS caching, flush that, or reboot, whichever is easier, then start a web browser and navigate again to http://forum.defcon.org/

Do you see the same results? If so, then I would suspect:
*) Mistake in the DNS server configuration.
*) Cache poisoned DNS server.
*) MiM DNS reply (or blind "MiM" DNS reply) to lookup with crafted response specifying an alternate IP address

Also, visit https://www.opendns.com/ and then view their cert, and export it to a file. Then compare the text you downloaded to the cert you exported. They look the same to me.

Strongly suggesting that when your web browser asked for DNS resolution to pics.defcon.org or whatever you were looking for, it was given an IP address to server serving *.opendns.com content from them or someone else.

[TheCotMan]

Cot, I think you could be correct. It seems very unlikely that opendns got their cert stolen, but also strange that somehow they would inject themselves into an http://forums.defcon.org/ request. I must ponder.

Do DNS requests pass through a proxy? Maybe it has bugs, and confused a DNS request from one user asking for DNS resolution on *.opendns.com, and the proxy switched the replies, or sent the same IP to both.

Maybe you run a DNS-caching service on your personal computer, and it is buggy, confusing one result for another. Maybe a buggy plugin in your web browser needs to be updated, or wasn't upgraded "properly" (in both web browsers?) when they were upgraded. (System service that both browsers use would be more likely.)

Other than that, I would check out the DNS you have configured to resolve names to IP addresses for you, and query each one for the same name, the next time this happens, to see if one of them is cache-poisoned. (You mention that it worked 30 minutes later, and combined with failure for 30 minutes until that 30 minute mark, suggests a TTL expiration in DNS, or a local DNS caching service.)

Then again, maybe it was hackers, or possibly terrorists. Whatever the cause, it wasn't done by ninja hackers -- they wouldn't have even left a hint of an attack until long after the attack succeeded. Maybe angry zombie-pirates did it! (heh heh) They can't be that smart if they are always looking for more brains. (Comments like this last paragraph are what happen when people deprive themselves of sleep. :-) Watch out for angry zombie-pirates! They are dangerous!

[Dark Tangent]

Cot, I was using my HSDPA AT&T wireless modem at the time, so dns was whatever their DHCP server handed out. It might be something wonky with their network.

In my experience most strangeness on the net is due to misconfiguration or unintended interactions between devices.



Do DNS requests pass through a proxy? Maybe it has bugs, and confused a DNS request from one user asking for DNS resolution on *.opendns.com, and the proxy switched the replies, or sent the same IP to both.

Maybe you run a DNS-caching service on your personal computer, and it is buggy, confusing one result for another. Maybe a buggy plugin in your web browser needs to be updated, or wasn't upgraded "properly" (in both web browsers?) when they were upgraded. (System service that both browsers use would be more likely.)

Other than that, I would check out the DNS you have configured to resolve names to IP addresses for you, and query each one for the same name, the next time this happens, to see if one of them is cache-poisoned. (You mention that it worked 30 minutes later, and combined with failure for 30 minutes until that 30 minute mark, suggests a TTL expiration in DNS, or a local DNS caching service.)

Then again, maybe it was hackers, or possibly terrorists. Whatever the cause, it wasn't done by ninja hackers -- they wouldn't have even left a hint of an attack until long after the attack succeeded. Maybe angry zombie-pirates did it! (heh heh) They can't be that smart if they are always looking for more brains. (Comments like this last paragraph are what happen when people deprive themselves of sleep. :-) Watch out for angry zombie-pirates! They are dangerous!

[SarperDomain]

DT,

Last site scans checked normal as of Tuesday, November 18th. Scans report clear and no discrepancies have been found. I ran into this once with my site using a Sprint Airnet card, I think it is DNS handouts by the low-budget cellular ISP's.