Entries Tagged "man-in-the-middle attacks"

Page 5 of 6

Putting Unique Codes on Objects to Detect Counterfeiting

This will help some.

At least two rival systems plan to put unique codes on packages containing antimalarials and other medications. Buyers will be able to text the code to a phone number on the package and get an immediate reply of “NO” or “OK,” with the drug’s name, expiration date, and other information.

To defeat the system, the counterfeiter has to copy the bar codes. If the stores selling to customers are in on the scam, it can be the same code. If not, there have to be sufficient different bar codes that the store doesn’t detect duplications. Presumably, numbers that are known to have been copied are added to the database, so the counterfeiters need to keep updating their codes. And presumably the codes are cryptographically hard to predict, so the only way to keep updating them is to look at legitimate products.

Another attack would be to intercept the verification system. A man-in-the-middle attack against the phone number or the website would be difficult, but presumably the verification information would be on the object itself. It would be easy to swap in a fake phone number that would verify anything.

It’ll be interesting to see how the counterfeiters get around this security measure.

Posted on October 6, 2010 at 6:59 AM • View Comments

UAE Man-in-the-Middle Attack Against SSL

Interesting:

Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft’s software trusts more than 100 private and government institutions.

Disturbingly, some of these trusted certificate authorities have decided to delegate their powers to yet more organizations, which aren’t tracked or audited by browser companies. By scouring the Net for certificates, security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motors­and a UAE mobile phone company called Etisalat.

In 2005, a company called CyberTrust­—which has since been purchased by Verizon­—gave Etisalat, the government-connected mobile company in the UAE, the right to verify that a site is valid. Here’s why this is trouble: Since browsers now automatically trust Etisalat to confirm a site’s identity, the company has the potential ability to fake a secure connection to any site Etisalat subscribers might visit using a man-in-the-middle scheme.

EDITED TO ADD (9/14): EFF has gotten involved.

Posted on September 3, 2010 at 6:27 AM • View Comments

Man-in-the-Middle Attacks Against SSL

Says Matt Blaze:

A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don’t even do that much.

Scary research by Christopher Soghoian and Sid Stamm:

Abstract: This paper introduces a new attack, the compelled certificate creation attack, in which government agencies compel a certificate authority to issue false SSL certificates that are then used by intelligence agencies to covertly intercept and hijack individuals’ secure Web-based communications. We reveal alarming evidence that suggests that this attack is in active use. Finally, we introduce a lightweight browser add-on that detects and thwarts such attacks.

Even more scary, Soghoian and Stamm found that hardware to perform this attack is being produced and sold:

At a recent wiretapping convention, however, security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications—without breaking the encryption—by using forged security certificates, instead of the real ones that websites use to verify secure connections. To use the appliance, the government would need to acquire a forged certificate from any one of more than 100 trusted Certificate Authorities.

[…]

The company in question is known as Packet Forensics…. According to the flyer: “Users have the ability to import a copy of any legitimate key they obtain (potentially by court order) or they can generate ‘look-alike’ keys designed to give the subject a false sense of confidence in its authenticity.” The product is recommended to government investigators, saying “IP communication dictates the need to examine encrypted traffic at will.” And, “Your investigative staff will collect its best evidence while users are lulled into a false sense of security afforded by web, e-mail or VOIP encryption.”

Matt Blaze has the best analysis. Read his whole commentary; this is just the ending:

It’s worth pointing out that, from the perspective of a law enforcement or intelligence agency, this sort of surveillance is far from ideal. A central requirement for most government wiretapping (mandated, for example, in the CALEA standards for telephone interception) is that surveillance be undetectable. But issuing a bogus web certificate carries with it the risk of detection by the target, either in real-time or after the fact, especially if it’s for a web site already visited. Although current browsers don’t ordinarily detect unusual or suspiciously changed certificates, there’s no fundamental reason they couldn’t (and the Soghoian/Stamm paper proposes a Firefox plugin to do just that). In any case, there’s no reliable way for the wiretapper to know in advance whether the target will be alerted by a browser that scrutinizes new certificates.

Also, it’s not clear how web interception would be particularly useful for many of the most common law enforcement investigative scenarios. If a suspect is buying books or making hotel reservations online, it’s usually a simple (and legally relatively uncomplicated) matter to just ask the vendor about the transaction, no wiretapping required. This suggests that these products may be aimed less at law enforcement than at national intelligence agencies, who might be reluctant (or unable) to obtain overt cooperation from web site operators (who may be located abroad).

Posted on April 12, 2010 at 1:32 PM • View Comments

Man-in-the-Middle Attack Against Chip and PIN

Nice attack against the EMV—Eurocard Mastercard Visa—the “chip and PIN” credit card payment system. The attack allows a criminal to use a stolen card without knowing the PIN.

The flaw is that when you put a card into a terminal, a negotiation takes place about how the cardholder should be authenticated: using a PIN, using a signature or not at all. This particular subprotocol is not authenticated, so you can trick the card into thinking it’s doing a chip-and-signature transaction while the terminal thinks it’s chip-and-PIN. The upshot is that you can buy stuff using a stolen card and a PIN of 0000 (or anything you want). We did so, on camera, using various journalists’ cards. The transactions went through fine and the receipts say “Verified by PIN”.

[…]

So what went wrong? In essence, there is a gaping hole in the specifications which together create the “Chip and PIN” system. These specs consist of the EMV protocol framework, the card scheme individual rules (Visa, MasterCard standards), the national payment association rules (UK Payments Association aka APACS, in the UK), and documents produced by each individual issuer describing their own customisations of the scheme. Each spec defines security criteria, tweaks options and sets rules—but none take responsibility for listing what back-end checks are needed. As a result, hundreds of issuers independently get it wrong, and gain false assurance that all bases are covered from the common specifications. The EMV specification stack is broken, and needs fixing.

Read Ross Anderson’s entire blog post for both details and context. Here’s the paper, the press release, and a FAQ. And one news article.

This is big. There are about a gazillion of these in circulation.

EDITED TO ADD (2/12): BBC video of the attack in action.

Posted on February 11, 2010 at 4:18 PM • View Comments

Hacking Two-Factor Authentication

Back in 2005, I wrote about the failure of two-factor authentication to mitigate banking fraud:

Here are two new active attacks we’re starting to see:

  • Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.
  • Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

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.

Here’s an example:

The theft happened despite Ferma’s use of a one-time password, a six-digit code issued by a small electronic device every 30 or 60 seconds. Online thieves have adapted to this additional security by creating special programs—real-time Trojan horses—that can issue transactions to a bank while the account holder is online, turning the one-time password into a weak link in the financial security chain. “I think it’s a broken model,” Ferrari says.

Of course it’s a broken model. We have to stop trying to authenticate the person; instead, we need to authenticate the transaction:

One way to think about this is that two-factor authentication solves security problems involving authentication. The current wave of attacks against financial systems are not exploiting vulnerabilities in the authentication system, so two-factor authentication doesn’t help.

Security is always an arms race, and you could argue that this situation is simply the cost of treading water. The problem with this reasoning is it ignores countermeasures that permanently reduce fraud. By concentrating on authenticating the individual rather than authenticating the transaction, banks are forced to defend against criminal tactics rather than the crime itself.

Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card’s existence isn’t even verified. The credit card companies spend their security dollar authenticating the transaction, not the cardholder.

More on mitigating identity theft.

Posted on September 22, 2009 at 6:39 AM • View Comments

Man-in-the-Middle Trucking Attack

Clever:

For over three years the pair hacked into a Department of Transportation website called Safersys.org, which maintains a list of licensed interstate-trucking companies and brokers, according to an affidavit (.pdf) filed by a DOT investigator. There, they would temporarily change the contact information for a legitimate trucking company to an address and phone number under their control.

The men then took to the web-based “load boards” where brokers advertise cargo in need of transportation. They’d negotiate a deal, for example, to transport cargo from American Canyon, California, to Jessup, Maryland, for $3,500.

But instead of transporting the load, Lakes and Berkovich would outsource the job to another trucking company, the feds say, posing as the legitimate company whose identity they’d hijacked. Once the cargo was delivered, the men invoiced their customer and pocketed the funds. But when the company that actually drove the truck tried to get paid, they’d eventually discover that the firm who’d supposedly hired them didn’t know anything about it.

Actually, not so clever. I’m amazed it went on for three years. You’d think that more than a few of the subcontracters would pick up the phone and call the original customers—and they’d figure out what happened. Maybe there are just so many trucking companies, and so many people who need cargo shipped places, that they were able to hide for three years.

But this scheme was bound to unravel sooner or later. If the criminal middlemen had legitimately subcontracted the work and just pocketed the difference, they might have remained undiscovered forever. But that’s much less profit per contract.

Posted on August 13, 2009 at 5:09 AM • View Comments

NSA Patent on Network Tampering Detection

The NSA has patented a technique to detect network tampering:

The NSA’s software does this by measuring the amount of time the network takes to send different types of data from one computer to another and raising a red flag if something takes too long, according to the patent filing.

Other researchers have looked into this problem in the past and proposed a technique called distance bounding, but the NSA patent takes a different tack, comparing different types of data travelling across the network. “The neat thing about this particular patent is that they look at the differences between the network layers,” said Tadayoshi Kohno, an assistant professor of computer science at the University of Washington.

The technique could be used for purposes such as detecting a fake phishing Web site that was intercepting data between users and their legitimate banking sites, he said. “This whole problem space has a lot of potential, [although] I don’t know if this is going to be the final solution that people end up using.”

Posted on December 30, 2008 at 12:07 PM • View Comments

Aspidistra

Aspidistra was a World War II man-in-the-middle attack. The vulnerability that made it possible was that German broadcast stations were mostly broadcasting the same content from a central source; but during air raids, transmitters in the target area were switched off to prevent them being used for radio direction-finding of the target.

The exploit involved the very powerful (500KW) Aspidistra transmitter, coupled to a directional antenna farm. With that power, they could make it sound like a local station in the target area.

With a staff of fake announcers, a fake German band, and recordings of recent speeches from high-ranking Nazis, they would smoothly switch from merely relaying the German network to emulating it with their own staff. They could then make modifications to news broadcasts, occasionally creating panic and confusion.

German transmitters were switched off during air raids, to prevent them from being used as navigational aids for bombers. But many were connected into a network and broadcast the same content. When a targeted transmitter switched off, Aspidistra began transmitting on their original frequency, initially retransmitting the German network broadcast as received from a still-active station. As a deception, false content and pro-Allied propaganda would be inserted into the broadcast. The first such “intrusion” was carried out on March 25, 1945, as shown in the operations order at the right.

On March 30, 1945, “Aspidistra” intruded into the Berlin and Hamburg frequencies warning that the Allies were trying to spread confusion by sending false telephone messages from occupied towns to unoccupied towns. On April 8, 1945, “Aspidistra” intruded into the Hamburg and Leipzig channels to warn of forged banknotes in circulation. On April 9, 1945, there were announcements encouraging people to evacuate to seven bomb-free zones in central and southern Germany. All these announcements were false.

The German radio network tried announcing “The enemy is broadcasting counterfeit instructions on our frequencies. Do not be misled by them. Here is an official announcement of the Reich authority.” The Aspidistra station made similar announcements, to cause confusion and make the official messages ineffective.

EDITED TO ADD (11/13): Photos here.

Posted on November 10, 2008 at 7:07 AM • View Comments

The DNS Vulnerability

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.

Posted on July 29, 2008 at 6:01 AM • View Comments

1 … 3 4 5 6

Sidebar photo of Bruce Schneier by Joe MacInnis.