Page 6 of 6
This is serious stuff. (Kim Zetter’s posts on the topic are excellent; read them.)
It’s a man-in-the-middle attack. “The Internet’s Biggest Security Hole” (the title of that first link) has been that interior relays have always been trusted even though they are not trustworthy.
EDITED TO ADD (9/12): This is worth reading.
Despite the best efforts of the security community, the details of a critical internet vulnerability discovered by Dan Kaminsky about six months ago have leaked. Hackers are racing to produce exploit code, and network operators who haven’t already patched the hole are scrambling to catch up. The whole mess is a good illustration of the problems with researching and disclosing flaws like this.
The details of the vulnerability aren’t important, but basically it’s a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com—there’s no way for you to tell the difference—and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.
Here’s the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There’s a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability—but not the details—and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.
Of course, the details leaked. How isn’t important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I’m kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.
What’s the moral here? It’s easy to condemn Kaminsky: If he had shut up about the problem, we wouldn’t be in this mess. But that’s just wrong. Kaminsky found the vulnerability by accident. There’s no reason to believe he was the first one to find it, and it’s ridiculous to believe he would be the last. Don’t shoot the messenger. The problem is with the DNS protocol; it’s insecure.
The real lesson is that the patch treadmill doesn’t work, and it hasn’t for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won’t prevent every vulnerability, but it’s much more secure—and cheaper—than the patch treadmill we’re all on now.
What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It’s not that he discovers all possible attacks before the bad guys do; it’s more that he anticipates potential types of attacks, and defends against them even if he doesn’t know their details. I see this all the time in good cryptographic designs. It’s over-engineering based on intuition, but if the security engineer has good intuition, it generally works.
Kaminsky’s vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That’s exactly the work-around being rolled out now following Kaminsky’s discovery. Bernstein didn’t discover Kaminsky’s attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn’t need to be patched; it’s already immune to Kaminsky’s attack.
That’s what a good design looks like. It’s not just secure against known attacks; it’s also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards … everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.
This essay previously appeared on Wired.com.
EDITED TO ADD (8/7): Seems like the flaw is much worse than we thought.
EDITED TO ADD (8/13): Someone else discovered the vulnerability first.
Last week’s dramatic rescue of 15 hostages held by the guerrilla organization FARC was the result of months of intricate deception on the part of the Colombian government. At the center was a classic man-in-the-middle attack.
In a man-in-the-middle attack, the attacker inserts himself between two communicating parties. Both believe they’re talking to each other, and the attacker can delete or modify the communications at will.
The Wall Street Journal reported how this gambit played out in Colombia:
“The plan had a chance of working because, for months, in an operation one army officer likened to a ‘broken telephone,’ military intelligence had been able to convince Ms. Betancourt’s captor, Gerardo Aguilar, a guerrilla known as ‘Cesar,’ that he was communicating with his top bosses in the guerrillas’ seven-man secretariat. Army intelligence convinced top guerrilla leaders that they were talking to Cesar. In reality, both were talking to army intelligence.”
This ploy worked because Cesar and his guerrilla bosses didn’t know one another well. They didn’t recognize one anothers’ voices, and didn’t have a friendship or shared history that could have tipped them off about the ruse. Man-in-the-middle is defeated by context, and the FARC guerrillas didn’t have any.
And that’s why man-in-the-middle, abbreviated MITM in the computer-security community, is such a problem online: Internet communication is often stripped of any context. There’s no way to recognize someone’s face. There’s no way to recognize someone’s voice. When you receive an e-mail purporting to come from a person or organization, you have no idea who actually sent it. When you visit a website, you have no idea if you’re really visiting that website. We all like to pretend that we know who we’re communicating with—and for the most part, of course, there isn’t any attacker inserting himself into our communications—but in reality, we don’t. And there are lots of hacker tools that exploit this unjustified trust, and implement MITM attacks.
Even with context, it’s still possible for MITM to fool both sides—because electronic communications are often intermittent. Imagine that one of the FARC guerrillas became suspicious about who he was talking to. So he asks a question about their shared history as a test: “What did we have for dinner that time last year?” or something like that. On the telephone, the attacker wouldn’t be able to answer quickly, so his ruse would be discovered. But e-mail conversation isn’t synchronous. The attacker could simply pass that question through to the other end of the communications, and when he got the answer back, he would be able to reply.
This is the way MITM attacks work against web-based financial systems. A bank demands authentication from the user: a password, a one-time code from a token or whatever. The attacker sitting in the middle receives the request from the bank and passes it to the user. The user responds to the attacker, who passes that response to the bank. Now the bank assumes it is talking to the legitimate user, and the attacker is free to send transactions directly to the bank. This kind of attack completely bypasses any two-factor authentication mechanisms, and is becoming a more popular identity-theft tactic.
There are cryptographic solutions to MITM attacks, and there are secure web protocols that implement them. Many of them require shared secrets, though, making them useful only in situations where people already know and trust one another.
The NSA-designed STU-III and STE secure telephones solve the MITM problem by embedding the identity of each phone together with its key. (The NSA creates all keys and is trusted by everyone, so this works.) When two phones talk to each other securely, they exchange keys and display the other phone’s identity on a screen. Because the phone is in a secure location, the user now knows who he is talking to, and if the phone displays another organization—as it would if there were a MITM attack in progress—he should hang up.
Zfone, a secure VoIP system, protects against MITM attacks with a short authentication string. After two Zfone terminals exchange keys, both computers display a four-character string. The users are supposed to manually verify that both strings are the same—”my screen says 5C19; what does yours say?”—to ensure that the phones are communicating directly with each other and not with an MITM. The AT&T TSD-3600 worked similarly.
This sort of protection is embedded in SSL, although no one uses it. As it is normally used, SSL provides an encrypted communications link to whoever is at the other end: bank and phishing site alike. And the better phishing sites create valid SSL connections, so as to more effectively fool users. But if the user wanted to, he could manually check the SSL certificate to see if it was issued to “National Bank of Trustworthiness” or “Two Guys With a Computer in Nigeria.”
No one does, though, because you have to both remember and be willing to do the work. (The browsers could make this easier if they wanted to, but they don’t seem to want to.) In the real world, you can easily tell a branch of your bank from a money changer on a street corner. But on the internet, a phishing site can be easily made to look like your bank’s legitimate website. Any method of telling the two apart takes work. And that’s the first step to fooling you with a MITM attack.
Man-in-the-middle isn’t new, and it doesn’t have to be technological. But the internet makes the attacks easier and more powerful, and that’s not going to change anytime soon.
This essay originally appeared on Wired.com.
Interesting. So often man-in-the-middle attacks are theoretical; it’s fascinating to see one in the wild.
(I’ve written about anonymity and the Tor network before.)
EDITED TO ADD (12/6): The guy claims that he just misconfigured his Tor node. I don’t know enough about Tor to have any comment about this.
It’s easy. Find a fast-food restaurant with two drive-through windows: one where you order and pay, and the other where you receive your food. This won’t work at the more-common U.S. configuration: a microphone where you order, and a single window where you both pay for and receive your food. The video demonstrates the attack at a McDonald’s in—I assume—France.
Wait until there is someone behind you and someone in front of you. Don’t order anything at the first window. Tell the clerk that you forgot your money and didn’t order anything. Then drive to the second window, and take the food that the person behind you ordered.
It’s a clever exploit. Basically, it’s a synchronization attack. By exploiting the limited information flow between the two windows, you can insert yourself into the pay-receive queue.
It’s relatively easy to fix. The restaurant could give the customer a numbered token upon ordering and paying, which he would redeem at the next window for his food. Or the second window could demand to see the receipt. Or the two windows could talk to each other more, maybe by putting information about the car and driver into the computer. But, of course, these security solutions reduce the system’s optimization.
So if not a lot of people do this, the vulnerability will remain open.
EDITED TO ADD (9/20): The video has been removed from YouTube. It’s available here.
Sid Stamm, Zulfikar Ramzan, and Markus Jakobsson have developed a clever, and potentially devastating, attack against home routers.
First, the attacker creates a web page containing a simple piece of malicious JavaScript code. When the page is viewed, the code makes a login attempt into the user’s home broadband router, and then attempts to change its DNS server settings to point to an attacker-controlled DNS server. Once the user’s machine receives the updated DNS settings from the router (after the machine is rebooted) future DNS requests are made to and resolved by the attacker’s DNS server.
And then the attacker basically owns the victim’s web connection.
The main condition for the attack to be successful is that the attacker can guess the router password. This is surprisingly easy, since home routers come with a default password that is uniform and often never changed.
They’ve written proof of concept code that can successfully carry out the steps of the attack on Linksys, D-Link, and NETGEAR home routers. If users change their home broadband router passwords to something difficult to guess, they are safe from this attack.
Additional details (as well as a nifty flash animation illustrating it) can be found here. There’s also a paper on the attack. And there’s a Slashdot thread.
Cisco says that 77 of its routers are vulnerable.
Note that the attack does not require the user to download any malicious software; simply viewing a web page with the malicious JavaScript code is enough.
Here’s a report of phishers defeating two-factor authentication using a man-in-the-middle attack.
The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit—a tactic used by some security-savvy people—you might be fooled. That’s because this site acts as the “man in the middle”—it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.
I predicted this last year.
Bank defends its bad security by saying that everyone else does it too.
Recent articles about a proposed US-Canada and US-Mexico travel document (kind of like a passport, but less useful), with an embedded RFID chip that can be read up to 25 feet away, have once again made RFID security newsworthy.
My views have not changed. The most secure solution is a smart card that only works in contact with a reader; RFID is much more risky. But if we’re stuck with RFID, the combination of shielding for the chip, basic access control security measures, and some positive action by the user to get the chip to operate is a good one. The devil is in the details, of course, but those are good starting points.
And when you start proposing chips with a 25-foot read range, you need to worry about man-in-the-middle attacks. An attacker could potentially impersonate the card of a nearby person to an official reader, just by relaying messages to and from that nearby person’s card.
Here’s how the attack would work. In this scenario, customs Agent Alice has the official card reader. Bob is the innocent traveler, in line at some border crossing. Mallory is the malicious attacker, ahead of Bob in line at the same border crossing, who is going to impersonate Bob to Alice. Mallory’s equipment includes an RFID reader and transmitter.
Assume that the card has to be activated in some way. Maybe the cover has to be opened, or the card taken out of a sleeve. Maybe the card has a button to push in order to activate it. Also assume the card has come challenge-reply security protocol and an encrypted key exchange protocol of some sort.
Defending against this attack is hard. (I talk more about the attack in Applied Cryptography, Second Edition, page 109.) Time stamps don’t help. Encryption doesn’t help. It works because Mallory is simply acting as an amplifier. Mallory might not be able to read the messages. He might not even know who Bob is. But he doesn’t care. All he knows is that Alice thinks he’s Bob.
Precise timing can catch this attack, because of the extra delay that Mallory’s relay introduces. But I don’t think this is part of the spec.
The attack can be easily countered if Alice looks at Mallory’s card and compares the information printed on it with what she’s receiving over the RFID link. But near as I can tell, the point of the 25-foot read distance is so cards can be authenticated in bulk, from a distance.
From the News.com article:
Homeland Security has said, in a government procurement notice posted in September, that “read ranges shall extend to a minimum of 25 feet” in RFID-equipped identification cards used for border crossings. For people crossing on a bus, the proposal says, “the solution must sense up to 55 tokens.”
If Mallory is on that bus, he can impersonate any nearby Bob who activates his RFID card early. And at a crowded border crossing, the odds of some Bob doing that are pretty good.
More detail here:
If that were done, the PASS system would automatically screen the cardbearers against criminal watch lists and put the information on the border guard’s screen by the time the vehicle got to the station, Williams said.
And would predispose the guard to think that everything’s okay, even if it isn’t.
I don’t think people are thinking this one through.
Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.
The problem with passwords is that they’re too easy to lose control of. People give them to other people. People write them down, and other people read them. People send them in e-mail, and that e-mail is intercepted. People use them to log into remote servers, and their communications are eavesdropped on. They’re also easy to guess. And once any of that happens, the password no longer works as an authentication token because you can’t be sure who is typing that password in.
Two-factor authentication mitigates this problem. If your password includes a number that changes every minute, or a unique reply to a random challenge, then it’s harder for someone else to intercept. You can’t write down the ever-changing part. An intercepted password won’t be good the next time it’s needed. And a two-factor password is harder to guess. Sure, someone can always give his password and token to his secretary, but no solution is foolproof.
These tokens have been around for at least two decades, but it’s only recently that they have gotten mass-market attention. AOL is rolling them out. Some banks are issuing them to customers, and even more are talking about doing it. It seems that corporations are finally waking up to the fact that passwords don’t provide adequate security, and are hoping that two-factor authentication will fix their problems.
Unfortunately, the nature of attacks has changed over those two decades. Back then, the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses.
Here are two new active attacks we’re starting to see:
See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.
The real threat is fraud due to impersonation, and the tactics of impersonation will change in response to the defenses. Two-factor authentication will force criminals to modify their tactics, that’s all.
Recently I’ve seen examples of two-factor authentication using two different communications paths: call it “two-channel authentication.” One bank sends a challenge to the user’s cell phone via SMS and expects a reply via SMS. If you assume that all your customers have cell phones, then this results in a two-factor authentication process without extra hardware. And even better, the second authentication piece goes over a different communications channel than the first; eavesdropping is much, much harder.
But in this new world of active attacks, no one cares. An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the log-in, since he can’t do it himself. And a Trojan attacker doesn’t care, because he’s relying on the user to log in anyway.
Two-factor authentication is not useless. It works for local login, and it works within some corporate networks. But it won’t work for remote authentication over the Internet. I predict that banks and other financial institutions will spend millions outfitting their users with two-factor authentication tokens. Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.
This essay will appear in the April issue of Communications of the ACM.
Sidebar photo of Bruce Schneier by Joe MacInnis.