Double-barrel net infrastructure hack threatens ecommerce Security watchers warn that hackers might be able to develop potent attacks that would be extremely hard to foil by combining DNS hacks of the kind that affected The Register and other high-profile websites over the weekend with DigiNotar-style forged digital certificates. An attack on Domain Name System (DNS) service provider …
Well, then, just don't do anything that's "a pain", right? And, in the bargain, tell your clients that doing this most basic of security tasks is "a pain", but that "probably" nothing will happen, because, after all, executing an SQL injection attack is, coincidentally, also a bit of "a pain". Truly sad. One hopes you're not a professional ... because if you are, then you're giving a bad name to professionals. "A pain". Woot! Ridiculous.
The problem is that in the messy real world there are unfortunately developers that give the rest of us a bad name with their cowboy laziness and corner cutting. I'm not averse to cutting the odd corner when constructing something for time pressure reasons but I prefer not to undermine the entire foundations. This smacks of laziness, ineptitude, or both.
@Chris Miller: "True in theory, but in the messy real world the problem is that a single site may provide thousands of opportunities for SQLi attacks, and checking every single one is a pain".
No it isn't messy, you use stored procedures, no one in their right mind allows a client to inject SQL queries from a client ...
An SSL certificate certifies that a given domain name maps to an IP address - this is the whole reason we have CA's and a trust model, because the point of the certificate is to certify the information returned to your by your DNS server.
So forging the certificate verifying this information *without* altering the DNS to return this information in the first place would be pointless - a poisoned DNS is required for this to work. Whether it comes as a result of a hack or the Iranian government dictating the change isn't really important.
I really hope this conclusion didn't take a full week to dawn on Rik Ferguson.
"An SSL certificate certifies that a given domain name maps to an IP address"
No, an SSL certificate certifies that the entity whose distinguished name (which may or may not include a domain name) appears in the certificate is actually in possession of the private key corresponding to the public key in the certificate.
We are not talking DNSSEC here. Though we might.
All an SSL cert buys you is encryption and the comfort that the system you are talking to is trusted by *a* CA that it is the DNS name it says it is. There is no verification of IP address at any point.
Anyway, the system is already broken without DNS exploits. You don't need to hijack the DNS system to employ a man-in-the-middle attack... all you need to do is hijack the traffic.
What hijacking DNS and a CA allows is for you to get all of the traffic to your server... not just whatever traffic you can sit on top of with a MITM.
"An SSL certificate certifies that a given domain name maps to an IP address" ... err, no it doesn't.
An SSL certificate merely informs you that *at the time of issue* the holder was validated to be authoritative over the Common Name (CN) that it identifies (e.g. my.onlineshop.com). Unfortunately it would appear that certificates have been being issued without sufficient checks on whether the applicants were indeed authoritative over the [sub]domain/CN, so this trust is effectively broken for those CAs (hence removal of the CA roots from various browsers and OSes).
DNS poisoning is entirely separate and very useful, but ineffective on sites secured without SSL if you haven't already got your hands on either the original signing key from the site your subverting or an alternative certificate from a lazy CA who didn't check your credentials properly.
A more scary prospect is that a lot of CAs will issue certs purely based on sending an email to addresses like administrator@domain.com. If you've managed to take control of the DNS for a short period, you could probably get a cert issued using this method ready for a later attack.
re: "Imagine a scenario where someone is able to modify DNS records for, say yourbank.com to a destination of their choice and at the same has got hold of fraudulent certificates to certify its identity,"
Every company in the world that runs internal dns servers, an internal certificate authority, and internal proxy servers has had this ability for a very long time, at very little cost.
This is just a reminder that if you accept https connections that contain BlueCoat cookies, You don't have any security, and you should be wary of making any such claims. Whether or not the end-user had to sign a terms-of-use agreement with their employer makes no difference to the statements you make on your website about security of your transactions.
Since the attack was SQL injection, it wasn't the DNS protocol that was subverted. When the servers are hacked via SQL injection, then the web-based management has died, so you can fill the databases with whatever you like. Once the attacker has global access, a script can be employed to make a complete mess of everything. How many people check the full chain of the SSL cert before entering CC details and the like?
Of course SQL injection still works with poorly implemented WEB sites. That shouldn't be a surprise. DNS is still working fine, so secure the site management.
Unfortunately the PROTECT-IP act in the US Congress would prohibit DNSSEC and require DNS be falsifiable.
The jihad against file-sharing is increasingly on a collision course with security. Basically, we can have real security of communications, or government ability to intercept and censor, but not both.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
