DEFCON SSL Compromise? NO!

[The 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]

Re: DEFCON SSL Compromise? NO!

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.

[The Dark Tangent]

Re: DEFCON SSL Compromise? NO!

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:

https://www.defcon.org/images/dtange...pendns.com.txt

First is how it looked on Forefox:



Then how it looked on IE 7



Then what happens when I temporarily accepted the cert:



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

WTF?

[TheCotMan]

Re: DEFCON SSL Compromise? NO!

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:

https://www.defcon.org/images/dtange...pendns.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 https://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.

[The Dark Tangent]

Re: DEFCON SSL Compromise? NO!

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 https://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 https://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]

Re: DEFCON SSL Compromise? NO!

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 https://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!

[The Dark Tangent]

Re: DEFCON SSL Compromise? NO!

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]

Re: DEFCON SSL Compromise? NO!

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.

[xAlimorAx]

Re: DEFCON SSL Compromise? NO!

I ran into this same problem yesterday... First on my Inspiron 1501 laptop, built in wireless, then on a p5e3 deluxe asus custom build, also using built in wifi-ap! Both times running firefox, it was within 30 minutes apart. I think both mine where on yahoo. I've spoke with a few others with exact symptoms!?!?!

ITS AN EPIDEMIC RUN!!

-xAlimorAx
"Of All The Things I've Lost, I Miss My Mind The Most!"

[xor]

Re: DEFCON SSL Compromise? NO!

I ran a dnsstuff.com DNS Report on defcon.org and got 4 warning and 2 failures. Some of which indicate possible non-RFC compliance.

Perhaps that is causing the wonkiness.

xor

[The Dark Tangent]

Re: DEFCON SSL Compromise? NO!

I ran a dnsstuff.com DNS Report on defcon.org and got 4 warning and 2 failures. Some of which indicate possible non-RFC compliance.

Perhaps that is causing the wonkiness.

xor

I used to run those until they started charging for it. What are the current issues? I'll hunt 'em down and fix 'em.

[xor]

Re: DEFCON SSL Compromise? NO!

I used to run those until they started charging for it. What are the current issues? I'll hunt 'em down and fix 'em.

Again no expert but I may get lucky. There are some tools I don't mind paying for. Just makes things easy or can't duplicate them other ways. Vector Trace is an interesting beta tool they offer.

Here ya go.

WARNING. The parent servers (I checked with a0.org.afilias-nst.info.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

WARNING: Your SOA REFRESH interval is : 86400 seconds. This seems high. You should consider decreasing this value to about 3600-7200 seconds (or higher, if using DNS NOTIFY). RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours, with the longer time periods used for very slow Internet connections), and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommend 86400 seconds if using DNS NOTIFY). This value determines how often secondary/slave nameservers check with the master for updates. A value that is too high will cause DNS changes to be in limbo for a long time.

WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can't reach the primary nameserver.

Next one was actually considered a failure:

WARNING: Your SOA MINIMUM TTL is : 2419200 seconds (over 2 weeks). This seems very high. You should consider decreasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

The last one was about the lack of or not being able to connect to a mail server. I don't think you guys run one anyway, right; Cot is using gmail for the site.

If you don't think these could or would cause problem I would be interested in hearing the why. Always trying to learn ;-).

xor

[TheCotMan]

Re: DEFCON SSL Compromise? NO!

Again no expert but I may get lucky. There are some tools I don't mind paying for. Just makes things easy or can't duplicate them other ways. Vector Trace is an interesting beta tool they offer.

Here ya go.

WARNING. The parent servers (I checked with a0.org.afilias-nst.info.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

WARNING: Your SOA REFRESH interval is : 86400 seconds. This seems high. You should consider decreasing this value to about 3600-7200 seconds (or higher, if using DNS NOTIFY). RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours, with the longer time periods used for very slow Internet connections), and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommend 86400 seconds if using DNS NOTIFY). This value determines how often secondary/slave nameservers check with the master for updates. A value that is too high will cause DNS changes to be in limbo for a long time.

WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can't reach the primary nameserver.

Next one was actually considered a failure:

WARNING: Your SOA MINIMUM TTL is : 2419200 seconds (over 2 weeks). This seems very high. You should consider decreasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

The last one was about the lack of or not being able to connect to a mail server. I don't think you guys run one anyway, right; Cot is using gmail for the site.

If you don't think these could or would cause problem I would be interested in hearing the why. Always trying to learn ;-).

xor

First two would be worthy of investigation. The last three only deal with latency for record updates such as the SOA timeout and the TTL for records (defaults and explicit.)

There are advantages to long TTL, to saving throughput in a network pipe when changes to host/IP are uncommon. There are also advantages to shorter TTL when you think you might need to move your operation to a new network, or worry about availability while in transition. The latency specified is longer than what I would choose, but each network admin has their own view on such times.

[nweaver]

Re: DEFCON SSL Compromise? NO!

(Yes this is a zombie thread, but I've been deep into DNS issues for a while now...)

Here's what I bet happened:

OpenDNS had a failure, and something along the line was configured to use OpenDNS for the DNS server rather than the one from the ISP. (I haven't heard of a major ISP deligating to OpenDNS).

Now when OpenDNS doesn't succesfully look up a name for any reason, they have a wildcard entry by default which points to their servers. (They play the old Verisign site-finder game of returning a valid response on errors to sell adds).

And I suspect that the wildcard is effectively the last rule in the chain: thus regardless of the source of the error, the rule gets applied.

Also, OpenDNS uses a fairly long TTL for these errors (10 minutes).

So your browser tries to connect to https:// resolver1.opendns.com but as forum.defcon.org, which properly gives OpenDNS's cert, which firefox rightly bitches about.

You can disable these properties in the OpenDNS dashboard, but because it needs to track you, unless you also do their notification business so they know when you change your IP, this behavior will recur.


Example of this behavior:

nweaver% dig forumtypo.defcon.org @208.67.222.222
; <<>> DiG 9.4.3-P1 <<>> forumtypo.defcon.org @208.67.222.222
;; QUESTION SECTION:
;forumtypo.defcon.org. IN A

;; ANSWER SECTION:
forumtypo.defcon.org. 0 IN A 208.67.219.132


nweaver% dig -x 208.67.222.222
;; QUESTION SECTION:
;222.222.67.208.in-addr.arpa. IN PTR

;; ANSWER SECTION:
222.222.67.208.in-addr.arpa. 86400 IN PTR resolver1.opendns.com.

;; AUTHORITY SECTION:
222.67.208.in-addr.arpa. 86400 IN NS auth1.opendns.com.
222.67.208.in-addr.arpa. 86400 IN NS auth2.opendns.com.
222.67.208.in-addr.arpa. 86400 IN NS auth3.opendns.com.


And if you are using OpenDNS, https://forumtypo.defcon.org will give you exactly this behavior seen.


instead of the proper response:


nweaver% dig +norecurse forumtypo.defcon.org @dns-1.datamerica.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49826
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;forumtypo.defcon.org. IN A

;; AUTHORITY SECTION:
defcon.org. 864000 IN SOA dns-1.datamerica.com. hostmaster.datamerica.com. 2008111304 86400 600 3600000 2419200



which will cause the browser to say "Address not found"

[The Dark Tangent]

Re: DEFCON SSL Compromise? NO!

To back some of that up, I have noticed that AT&T is using OpenDNS for their HSDPA customers. I bet you are right.