Zbr wrote at 2008-08-09 01:20:

Whatever ratelimiting is enabled, it will hurt normal users. It is even possible, that there will be no possibility for real reply packets to sneak in, so it is quite dangerous.

ISPs actually do have similar rates espcially mail servers. Root servers may have even more.

Ingres filtering will not work, since packets contain correct addresses and thus any filtering will hurt real users and/or servers.

DNSSEC will help. As long as querying other servers via TCP. Both solutions are quite cost from performance point of view, but they can be enabled after some statistics has been gathered (i.e. if fake IDs are detected, recursor can try to fetch the same record via TCP). Whatever method is decided to be used, it should be complex protection and likely requires lots of changes in DNS servers.

RobOnWndwrd wrote at 2008-08-09 09:39:

As a lay person, my question is the following: is it safe to use a bank site if the logon page uses the “two-way/two-factor logon” procedure?

RobOnWndwrd wrote at 2008-08-09 09:41:

As a lay person, my question is the following: is it safe to use a bank site if the logon page uses the “two-way/two-factor logon” procedure?

Zbr wrote at 2008-08-09 09:57:

If your DNS was poisoned, attacker can setup simple redirect on own site and dump the whole traffic incuding ssl initialization and hijack whatever authentification you have. Depending on various factors it can be unsafe to use such connection. But so far I believe it is quite unlikely to happen.

Adian wrote at 2008-08-09 10:26:

Zbr: Your comment in reply to RobOnWndwrd is not very accurate. No matter how insecure the communication channel, it is possible to have properly authenticated conversations over it provided you: 1. Have a separate secure channel to exchange credentials ahead of time 2. Actually *perform* the correct authentication steps.

In the case of an SSL website, if users correctly identify that the domain name is the one they want to use, then the browser will verify that the domain name matches the certificate and that the server has the certificate’s private key, thus proving identity (as well as Verisign thinks it is proven, at least). The biggest problem with online banking is that users don’t understand how to authenticate their sites. If you know how to use the tool right, it can be quite safe.

Zbr wrote at 2008-08-09 10:53:

I agree, that authntification may succeed no matter what channel is used, but in some cases of man in the middle attack the whole dataflow can be decrypted and hijacked. In some cases it is not possible: like when correct sertificate is already stored locally. If it is not, and has to be fetched from remote server first, attack will succeed.

It is always a game tradeoff between attacked and attacked: when one creates some additional step, another one need to implement something new too, and depending on level of the security it may or may not result in the suceeded attack.

Someone wrote at 2008-08-09 19:13:

Zbr, if the client downloads the SSL certificate from the server, makes sure that it’s valid, sends the server a secret encrypted with the server’s private key and then uses this secret to establish a secure channel, then it should be practically impossible to crack the session. This is how SSL generally works, no need for having the certificate already stored locally. And that is why it is so important to check the validity of certificates.

Zbr wrote at 2008-08-09 19:48:

If client downloads certificate via attacker’s proxy, it is already hacked. If client got certificate via trusted path, he has a hope.

Steve wrote at 2008-08-09 20:52:

Could always put the inside DNS server (the attacked one) on its own routed VLAN and then use router filters to make sure the public DNS server can’t be IP spoofed (i.e. a LAN PC cannot use a from IP of the external DNS server that the inside DNS is expecting a reply from.) And ideally find a way so no LAN PC can talk to any other on UDP ports so a bad PC can’t spoof the inside DNS server to the PC – hard because any LAN PC can spoof the IP of another PC on the VLAN or even another routed VLAN – Cisco VLAN filters seem useless for this.

And can’t we get common DNS servers to log these bad replies in some way so a log scanner immediately tells the admin this is happening ? Bad transaction IDs should be very rare so a million a minute should be somewhat obvious (though logs have to be rate-limited).

Jacob wrote at 2008-08-09 21:38:

This looks pretty bad, but it requires that the attack be launched from the inside of a high-bandwidth LAN–if Mallory already has a node on your LAN, you have a problem.

In the typical home environment, there’s one or maybe two nodes on the LAN–if Mallory is in a position to use one of those to blast the local DNS resolver, then Mallory can just steal data/passwords/money/etc. right from there, why flood the LAN and risk the owner wondering why their GigE LAN is so slow?

Probably the best mitigation would be for the DNS server to notice that it’s getting *lots* of bad repiles and take corrective action–return NXDOMAIN and blacklist the client that keeps making requests that bring in so many bogus replies, since this attack requires the attacker to make *many* DNS requests.

Another possible measure would be “internal egress filtering”–bind router ports to source IP addresses and drop any packets coming to the central switchpoint that have a source IP other than the one assigned to that port.

Pepito Grillo wrote at 2008-08-09 22:19:

On SSL the session key is encrypted using the PUBLIC server’s key no the private one. Only the server has the private key (therefore the name).

And downloading the certificate through the proxy of the attacker (man in the middle attack) it will not work unless the client, or more precisely, the user ignores all the warnings about the wrong certificate. The certificate from the server is always sent on SSL or TLS, but it has to be signed by a trusted CA installed on the user’s browser certificate store. The only way is to change the root CA certificate store from the user or trick the user to ignore all the warning messages.

If SSL/TLS is involved the authentication of the other party is guaranteed by the PKI involved and no man in the middle attack is possible and no data can be decrypted.

Zbr wrote at 2008-08-09 22:32:

You seems not to understand, that if there were no certificate on the local machine, than man in the middle attack does succeed.

Jacob, this attack can be mounted by botnet. Also you can have innocent office machine trojaned, which does not have any interesting data on it, but it can in turn poison DNS for the whole network.

Steve, such filtering can work, but you forget that attack can be mounted by even small 100 machines botnet, if receiving capacity of the server allows. Request logging can show that something is wrong, but it is no way a solution for the problem.

Pepito Grillo wrote at 2008-08-09 23:05:

What’s the point of not having the root CA certificates loaded on the local machine??? You just *can not* validate a web site certificate without the root self-signed certificate from the CA that issued it.

In normal browsers, JVMs, SSL libraries as OpenSSL and almost every bit of SSL software you DO have a set of Certification Authorities root certificates that it uses to validate the server’s certificate, which is ALWAYS sent on the SSL/TLS handshake. You don’t normally store the certificate from any server, you just validate it through normal PKI validation processes: digital signature processing, path validation and so on.

So again, with normal browsers and SSL software there is no way to make a man in the middle attack without detecting it since the signature on the server’s certificate can not be forged without knowing the CA’s private key or changing it on the cert store on the client machine, but if the client’s machine is infected, then what’s the point about attacking SSL/TLS? You already have access to the browser (windows hooks, rootkits, etc).

Getting back to the real subject the only solution is DNSSEC.

Zbr wrote at 2008-08-09 23:55:

Please read again how mitm attack work. And then note that attacker who controls your DNS controls all your traffic to whatever place you send your requests and whatever packet you send to the server.

DNSSEC is not a solution either. It provides too less security for too high performance price. But it is unlikely that something will be changed until DNSSEC is broken, so for the nearest time it is an appropriate solution.

Scott wrote at 2008-08-10 00:59:

Zbr,

The question here is: How did the man in the middle get a certificate for your www.onlinebank.com that was issued by Verisign (or some other trusted root CA)?

The answer is: he didn’t. Verisign, being a CA, has verified ownership of www.onlinebank.com as well as ownership of the organization (Class 2 certificate).

Now, since your man in the middle DOES NOT have a valid certificate for your domain, the browser is going to do at least one of two things. It will

1) Warn you the certificate does not match the domain

and/or

2) It will warn you that the CA which has signed this certificate is untrusted.

Only if the user ignores ALL OF THIS, does a man in the middle attack succeed on an SSL/TLS connection. The only other way this could work is if the man in the middle has inserted his custom made CA certificate into your root bundle. But since the root bundle IS NOT DOWNLOADED then, if he’s hacked that, you’ve got much bigger problems than some lame DNS spoofing.

Please, make sure you understand how SSL works before you start telling people their SSL connections aren’t safe.

Pepito Grillo wrote at 2008-08-10 01:22:

Thanks Scott, I was going to post a reply, but yours is much more clear than mine.

Zbr wrote at 2008-08-10 01:58:

Sigh, what I really like in theoretics, its theirs sincere consciousness.

You connect to www.paypal.com and get a note to recheck new root sertificate. Or you connect to verisign and get there new sertificate, which is not actually verisign one, otherwise secured connection does not establish and site bounces. Of course you will tell me right now, that anyone who sees ‘download new root certificate from site A, since we were compromised or whatever else’ on the verisign site, will not do that, since no one really trust content on the verisign site and will call the police. Mozilla site download you also do not trust… You should start

Whatever method you select, there will be always number of ways to break it, each of them you can pass, but still for each new trick there will be attacking counter-measures.

Security is not a black and white. DNS control gives attacker too much power to mount an attack, with additional steps will result in positive game result for him and at best zero to you. Think a bit wider than copy-book truth about ssl you pointed. It is not ssl which was broken, but way to use it.

I think it is enough stupid talks here.

John Sheehy wrote at 2008-08-10 07:17:

Another area that needs empirical testing is the source of randomness for this source port and ID randomization. Are there remote techniques that can influence the source ports and ID selected? Are these random numbers cryptographically strong?

John Sheehy wrote at 2008-08-10 07:18:

It would be help to benchmark all the major DNS server implementations with your code in an identical environment. This would allow for two things. First administrators to choose among the various implementations with a new piece of empirical data. Second, any material differences could be investigated and potential improvements replicated across the various implementations.

Zbr wrote at 2008-08-10 10:02:

Couple of days before I checked a small set of ports used by another DNS implementation (you can see them in ‘dns’ tag in the blog). There were some issues with port randomization, but ID space was more uniformly distributed.

I started an attack against powerdns, and it looks like in the same conditions it did not succeed. Bert Hubert (powerdns author) noted that there are some tricks in the implementation, which may help preventing the attack, so my blind bruteforce method may fail. It looks like it is Although I think that after checking powerdns sources and determining the traps, it is possible to mount an attack to ‘workaround’ it.

someone wrote at 2008-08-11 01:29:

Zbr, someone asked if the DNS attacks affects connecting to their bank. Your reply appeared to confuse server certificates which are downloaded in every session with CA certificates which are rarely if ever downloaded. When asked to explain your argument shifted to CA certificates. Specifically your attack vectors are convincing a user to download and install a root CA or to download and install a hacked version of Firefox or some other browser. Regardless of any DNS hijacking that may be going on, both would fail as long as the download is done over SSL or the content is signed. Thus your attack vector relies on a user using an insecure link to do something that materially affects their security. If a user is willing to do that then they are vulnerable to fake URLs in email or IM chat and those attacks are much easier to launch than a DNS hijack. A determined user can always thwart their own security and there is little that can be done about that. However, anyone with a common sense approach to security can be sure that their bank connection is safe regardless of any DNS hijacking that may be ongoing.

otherone wrote at 2008-08-11 01:53:

@someone go to read http://www.doxpara.com/DM>K_BO2K8.ppt

someone wrote at 2008-08-11 04:56:

otherone, how about you point at or quote the specific slide that you think is relevant? SSL depends on DNS to match the the IP to the host but for that to be a useful hack it requires the attacker to obtain a certificate from a root CA vendor. If they do not, then the IP is irrelevant, the certificate they present will not be signed by a root CA and so fail validation. One can question the background checks done the vendors and sometimes they do make mistakes, but if someone tries to get a certificate for say www.citibank.com, then I would expect the cert vendor would do more than a cursory examination of the requester to ensure that the domain did belong to the requester.

someone wrote at 2008-08-11 05:33:

Also if the argument is that “many Certificate Authorities validate a user’s control over a domain using email” then please name a sample of the many Certificate Authorities that do this? The documented Verisign procedures for verification do not include using email for authentication.

Zbr wrote at 2008-08-11 08:14:

@Someone, the simplest example: when user at www.paypal.com is aksed to download new root certificat from verisign. Verisign.com says, that certificate should be downloaded via SSL from host https://www.someotherdoma>in.com which does have valid certificate from the same verisign, which can be checked by old root one. Will you believe verisign.com, which does not use ssl to protect its own html content?

someone wrote at 2008-08-11 09:20:

Zbr, are you aware of an instance when Paypal or any bank has asked its customers to download a new root certificate from Verisign or any other certificate authority? If so, who and when? If your argument is simply that it _could_ happen, then yes I agree, but then a bank employee _could_ put a bunch of customer account details on a laptop, take it out and lose it or have it stolen. Either way, if there was any loss, the bank would have to make restitution or it would be sued and if the problem was actually with Verisign then bank would sue Verisign.

Zbr wrote at 2008-08-11 09:45:

The story with laptop happens all the time

I’ve shown the simplest case of such attack. If paypal domain in your dns cache is poisoned, then the majority (if not all) users will believe that paypal asks that. If it is a major ISP, then… Root certificate ‘compromise’ described in this fishy idea is a major problem to happen only the first time. One can harden it by poisoing multiple domains including some news ones, where big bold letters will tell about massive certificate hacking and so on. Another approach is to ‘update’ your browser/im/mail/whatever, when you will see a link on mozilla/ms/apple/whatever site to the controlled domain.

As a real example of this kind of attack: Sun has problems with its openid provider’s certificate.

There are at least 1.5% of broken (Debian openssl problem) certificates all over the world, which with this attack results in a really bad mess.

There are many ways to do this hacks. Some people will trust a mail from ‘payyypal.com’ others will not believe a note on verisign site, but whatever counter measures are applied, man in the middle, which controls your DNS, is always capable to make anti-counter-measures, so user will have to implement something else and so on.

someone wrote at 2008-08-11 10:35:

Zbr, if Paypal DNS is compromised in a users DNS cache then when the SSL connection is made the certificate check will fail and common sense says to not trust it. If the Paypal connection is not over SSL then the user would at least get to the fake Paypal site and see the request to download the root certificate. At this point any user who followed the request would be no better than those who click on links in emails asking them to verify their account details. Your argument is that if the hacker can subvert DNS they can always apply countermeasures. What countermeasure can they apply to a user who has common sense and who does not accept SSL connections where the certificate validation fails or does not follow instructions to do something that can clearly compromise their security e.g. install a new root certificate? Getting the certificate in there via an automated update would be one approach but that relies on a vendor not using SSL for updates or digitally signing updates or having some very lax rules for mirroring. I believe that Microsoft uses SSL so that covers 90% of users. That leaves various flavors of Unix (I’ll lump MacOS in this category) and there are too many vendors to know what they all do. However, any user using OS for banking where the vendor isn’t using digitally secure updates isn’t using their common sense.

Zbr wrote at 2008-08-11 10:46:

Please, read again, (poisoned) paypal will refuse to make ssl connection, since it will complain about hacked root certficate, which will need to be downloaded from (poisoned) versign, which in turn will redirect to httpS://someotherdomain.c>om, which will have valid certificate, checked by old root cert.

No one will ask you to connect via insecure channel, no need to enter any password: all will work via very legitimate dataflows, all links will be made from official sites.

If right now you will see on verisign site a request for root certificate download from httpS://certdownload.com, will you trust it? It is over SSL channel, but that link on verisign is not over SSL.

A. Peon wrote at 2008-08-11 11:20:

I see talk about DNSSEC here, which has always struck me as fiddly. I am not very awake right now, but is there any reason why djb’s “Nym” proposal couldn’t work? Potentially subject to other attacks, but less painful than getting into this same mess with Verisign.

http://cr.yp.to/djbdns/fo>rgery.html

Again, not very awake, but does this actually have to be embedded in the name or would it be possible to futz NA and NAAAA records to carry the fingerprint?

A. Peon wrote at 2008-08-11 11:52:

Put in some thinking on that – if the fingerprint is in a DNS record (as opposed to being an inalienable part of the name as djb proposed), you need to assume it might be valid (though it could’ve been poison) and then find out if the computer you’re reaching can actually sign against the same key… which the resolver/local cache could possibly do, though it’d require every host with a ‘nym record’ in DNS to keep a signature daemon available. Still less awful than giving Verisign all authority?

A. Peon wrote at 2008-08-11 12:08:

Sorry, fucked that up royally. If the attacker controls both the fingerprint and the machine, of course he can use his key for both. Glad I’m posting somewhat anonymously. (Argh, still must be a better way than either fingerprint-encrusted names or a central authority.)

guruperl wrote at 2008-08-11 14:30:

It’s works

nati wrote at 2008-08-12 01:58:

perhaps this idea can be used to overcome this DNS hijack threat (at least for organizations), not covering DOS attacks, but at least one will know he’s connected to the correct server and no.

the scheme relies on ssl certifactes signed by a CA, and that the organization has its own DNS server. the idea is to add the “aleged” IP address into the session establish step (add extra step to ssl handshake). this is not fixing any of DNS problems.

1. each server (holder of the cert private key) in the organiztion will have knowledge of its own valid IP’s, assuming the organztion DNS server (which is usually small and secured one) is accessible from inside the organiztion lan. 2. when doing the ssl handshake, the client will add to the first negotiation steps what IP address it thinks is the correct IP. (of course that at this stage the client, usualy makes sure that the server cert is valid). 3. the server will check the IP address that the client sent and will accept/reject the session, thus eliminating the option for man-in-the-middle attack. 4. some logics might be needed for proxies so the client behind a proxy will be able to know the “world” IP address of the server.

someone wrote at 2008-08-12 06:47:

Zbr, if DNS is hacked SSL detects a certificate mismatch, it does _not_ complain about hacked root certificate and there is no option to try and download one. For anyone to do what you say they would have to independently decide that CA certificate is bad and go to Verisign site to try and download a new one. If the Verisign is also hacked then the SSL will detect another mismatch and if the user has any common sense left they’ll stop there. To get a redirect to another site requires the user to ignore the SSL mismatch error and carry on with the connection. If the user is willing to do all this, then the easier hack would be to send them email saying you have some funds in a bank in Nigeria that you need their help to retrieve.

Zbr wrote at 2008-08-12 08:56:

There will be _no_ ssl connection. Poisoned paypal.com will not allow to connect over https, and http connection will tell, that https is dropped since your root certificate was compromised, so you need to go to (poisoned) verisign and update it. Verisign also will _not_ have ssl connection, but it will have a link to httpS (SSL) site where certificates are. This site (to download certificates) will have valid certificate signed by verisign, so you can download it via httpS (ssl). It is a matter of trust to verisign. We all trust verisign, since we allow them to sign our certificates.

There will be _zero_ ssl mismatches. You will _not_ enter any private data via unencrypted channel.