REST Security (or lack thereof) part deux

Update: see this post on REST Threat Models and Attack surface for more ideas

Some people in the REST community are able to see the need for message level security so this is heartening somewhat. If the data is distributed and the security model is point to point (at best), we have a problem. It is a gap in REST today that due to REST's reliance on HTTP, that message level security is an exercise left to the implementer with no open, proven standards to back them up. It doesn't always have to be this way. Maybe some smart software organization can build something that provides these properties for the REST crowd, and get them reviewed. For the time being it is still a gap for REST, which Don Park knew back in 2002:

It is not a key exchange issue. With SOAP, you can easily separate routing information and data so that you can encrypt head and body elements independently, REST does not. Cool thing about SOAP approach is that you can sign with multiple keys so that no only routers don't know about the content, routers themselves don't know where it will eventually end up.

If you do come up with some standard structure to do the same in REST,
you are basically reinventing SOAP.

Right. we don't want the postal worker reading the contents of the envelope, just the addressing header to name on example. I don't have a dog in the REST vs. WS-* hunt, my main concern is the security issues. As Don Smith says - "The message is the king and the contract is the queen." If you want to shrink your perimeter to the message level you can use WS-Security or attempt to roll your own with REST.

Pete Lacey's post restates a bunch transport level security mechansism which offer no message level security:

The standard RESTful security approach is, of course, HTTP Basic or HTTP Digest or SSL certificate-based mutual authentication for propagating identity credentials (the actual act of authentication and authorization being the purview of the server) and SSL for data integrity (digital signatures) and data protection (encryption)

SSL helps with channel security (while rendering the IDS and NSM people blind I might add). He goes on to say

Gunnar notes that these technologies were state of the art in 1995, with the implication they are no longer sufficient for meeting the security needs of the 21st century. This is an example of what I call the “Gilligan, you can’t fly” argument; that is stating that something can’t be done even as somebody else is doing it. The fact is that billions of dollars of worth of business is conducted every year over because of SSL.

Yes, Pete, I honestly do believe that attacker have evolved since 1995. The above statement (and I have heard it many times so he is not alone) tells you what we are up against from a software security standpoint.

Luckily, Robert Sayre agrees that RESTians can learn from the AWS developer token example with regard to dealing with spoofing:

"Sending reusable credentials and messages over HTTP+TLS is extremely common, so the goal of the discussion should focus on preventing the endpoint from impersonating the sender. That’s why I agree with you that AWS is a good example we should build on."

AWS is the best publicly used example I have seen so far. He also has a good post here that gets to one of the main issues:

When I read posts like that, I often wonder how the following sentence from the REST thesis fits in.

"REST component interactions are structured in a layered client-server style, but the added constraints of the generic resource interface create the opportunity for substitutability and inspection by intermediaries."

We have a thriving credential theft industry on our hands, so I'm not sure we can claim TLS is an undeniable success. It's true that many phishing sites don't bother turning on TLS. They don't have to, because lots of banks and things don't serve their credential forms over TLS. They don't have a pleasant choice. It should be obvious that a data stream opaque to intermediaries has several desirable properties, but scalability and reusability are not among them. Besides, it's not like it's impossible to improve on Basic, Digest, and Forms with Cookies. Here is a Python example.

"Both of these standards address identity propagation, message encryption, and message integrity only, and neither will protect you from the threats just mentioned."

Well, some of WS-Security might. I am afraid to read it. I can tell you that the example above will prevent hostile servers from reusing credentials, unless they have broken more than one cryptographic primitive.

I cannot remember an app since 1998-99 that didn't have layers and layers of intermediaries.

Paul Downey says:

I trust the water piped directly to my house, but I’m more careful when it comes to packages which flop through my letterbox. A signed-sealed envelope delivered by a courier boosts my confidence, but helps a lot more if I know who sent it. So whilst WS-Security offers a little more than just TLS, it’s the thought and effort being expended to establish and exchange identity that currently gives WS-* the security edge over REST. It’s great to see that RESTians are starting to at least see the issue

And I totally agree with Don Park's assertion that:

As far as I am concerned, REST and SOAP are both tools. It’s better to focus on what each tool is better at than fighting over which is better.

If I need message level security today, my choices are limited. So just in case people are sitll wondering why we'd need message level security in some cases perhaps this story is helpful

“Using the methods outlined by the researchers, a hacker could siphon off thousands of PIN codes and compromise hundreds of banks, said Odelia Moshe Ostrovsky, the report’s principal author. Criminals could then print phony debit cards and simultaneously withdraw vast amounts of cash using ATMs around the world, she said. ... Word of the apparent security flaw first surfaced two weeks ago, when Ostrovsky and other researchers at Algorithmic Research (ARX) published a paper stating that it would be possible for someone with access to the ATM network to attack the special computers that transmit bank account numbers and PIN codes, called hardware security modules.

When consumers enter their personal identification numbers, or PINs, into an ATM, the PIN and account number must travel through several computers on a special network before they arrive at their home bank for verification. The data is encrypted immediately after it’s entered at the ATM into what is known as a PIN block, then sent on its way.

Rarely does the transmission go directly to a consumer’s bank. Instead, it is handed off several times on a banking network run by several third parties. Each time a bank passes the data along, it goes through a switch that contains the hardware security module and the PIN block is unscrambled and then rescrambled. It is at these intermediate points where hackers could trick the machines into divulging PINs, the ARX researchers said.

Any similarity between this and corporate data centers is strictly uninentional

“We show in these attacks that using only (a single) function we can reveal the content of every PIN block as if it’s not encrypted,” said Ostrovsky.

PINs thought to be unassailable in transit
The attack theory is significant because it has long been considered impossible to access PINs as they are traveling through the ATM network without the encryption key used by the card-issuing bank. But the ARX report said issuer keys are not necessary because computers along the network can be tricked into revealing PINs through a series of electronic queries that would enable criminals to make educated guesses about – and possibly break — the encryption code.”

Ostrovsky said her company shared the research with the Visa credit card association’s risk management team and other U.S. financial industry security experts six months ago, and recommended systemwide ATM network changes. But U.S. banks weren’t reacting fast enough to the risk, she said, so ARX decided to go public with its information and two weeks ago published a paper titled “The Unbearable Lightness of PIN cracking,” which is now available on the Internet (in Adobe Acrobat format).

Kim Bruce, a spokeswoman for the Secret Service, confirmed that the agency had been in contact with ARX to discuss the paper’s findings, but declined to provide additional detail.

Some questions to ponde. Where does your app terminate SSL? AT the firewall? At F5? At the web server? What is the lifecycle of the data that your REST app sent? How is the message itself protected?

Russian-language Web sites are abuzz with discussions about ATM network attacks, including discussion of the Israeli report, according to data gathered by the Secret Service and viewed by MSNBC.com.

“In the fall of 2005 work for everyone was so successful because an employee of one of America's processors sold a database of material that went through its processing center,” wrote a hacker who belongs to an online gang called Mazafaka, according to an English translation of a Russian Web site compiled by the Secret Service. “This material was then successfully exploited by our carder friends. The consequences of this deal could even be monitored on CNN, as well as in our own work (this applies to cashers). You may have noticed that after this event, ATMs more and more frequently give ‘transaction declined’ notices or give a small sum on the first transaction and then block the card.”

In another exchange cited in the Secret Service memo, a hacker offers to pay for databases of encrypted PINs, which theoretically should be useless someone had discovered a way to translate the data into valid PINs. In still another post, one claims to have recovered account data by “hijacking” hardware security modules

The biggest issue beyond he point to point nature of SSL is that it is an all or nothing proposition

The attacks described in the ARX paper could not be conducted remotely over the Internet. They would require a criminal to be on the same local network as the hardware security module. Because ATM switches are heavily guarded and monitored, such access is unlikely, argued a BITS representative, who spoke on condition of anonymity.

But such ATM switches can be located anywhere in the world, Ostrovsky countered. That creates a “weakest link” vulnerability in which one poorly guarded switch could theoretically be used to compromise every bank whose debit cards have flowed through that switch, she said.

Each switch contains a hardware security module, which is a simple computer in a tamper-proof box designed to perform a few PIN-related functions, beginning with decrypting and encrypting. But the boxes also contain other small programs, or functions, which allow the machines to change a customer’s PIN or calculate other PIN-related values. Most ATM switches don’t need these tools; however, they are often available by default.

This unnecessary software is exploited in some of the attacks described by ARX, which recommends that switch operators turn off the unnecessary functions. But even that’s not enough, Ostrovsky said. The one essential function of a switch -- encrypting and decrypting, a process known as “translate” -- is all an attacker needs to trick the machine into divulging PINs, a hack that would put nearly every ATM switch at risk, she said.

“This is not an attack on a certain configuration or installation. This is an attack on the protocol itself. It must be updated,” Ostrovsky said.

There are competing protocols, or PIN block formats, in use in the ATM network, and each machine must support all those formats, she explained. In one version, the 16-digit PIN block contains two formatting characters, four PIN characters, and 10 additional slots with information about the customer’s account number. That’s the standard used in the U.S. Another standard combines the formatting characters and PIN characters with random digits, and sends the account number separately.

The translate function not only assists in encrypting – it also allows the machine to translate the PIN block from one format to another. This allows an attacker to take advantage of the weaknesses of both, creating“least-common denominator” vulnerability, Ostrovsky said.

The BITS representative who spoke on condition of anonymity conceded such attacks are feasible, but called the risk “very, very, very, very remote.” He added that bank robbers have much easier ways of stealing money than complicated PIN prediction tactics.

Litan is not so sure. She said the research paper undermines the basic premise of ATM network security – the idea that only a computer loaded with the encryption key created by the issuing bank can reveal a PIN.

“The premise was ‘It doesn't matter what happens along the path,’ so even people who could access the PIN blocks couldn’t do anything with them,” she said. “This blows that out of the water.”

And finally

Bank industry officials point out that the attacks must be carried out by someone with direct access to an ATM switch, limiting the potential for abuse. But Litan said the limitation is hardly reassuring.

“It’s not much comfort that they have to be on the inside,” she said. “As we’ve already seen, it’s easy for criminals to open up their own ATM network. And banks do have insiders with flaws.”

I think a technology that is geared towards interoperability, should be able to have an end to end security model which accepts there will be multiple intermediaries in play. Brian Snow termed this "if we cannot trust, how can we safely use?"

Comments

[Mark Baker]

Good stuff, but again, you are continuing to misuse the word "REST" by using it as some sort of synonym for current practice with HTTP & URI.

REST does not require HTTP
REST cannot be compared to WS-*
You can use WS-Security RESTfully

[Gunnar]

Mark

>REST does not require HTTP

Fair enough. All of the example security mechanisms proposed in at the begning of this meme by REST folks fall back to HTTP

>You can use WS-Security RESTfully

Right, and not only that, but the key primitives that WS-Security uses, like XML Enc and XML Sig, are open so there is nothing to stop REST for using the same.

[Dan Pritchett]

Great post. The separation of SSL from security of the message is a concept that is often lost on SOAP developers as well. The need to move to more intelligent routers to handle a variety of QoS tasks is pushing SSL termination further from the application server. Assuming that your SSL connection is getting anywhere near your application is a fallacy.

[Gunnar]

Dan, By my estimate it is lost on 72% of SOAP developers
http://1raindrop.typepad.com/1_raindrop/2006/10/wsgameover_72_o.html

[Mark Baker]

REST discussion does tend to fallback to HTTP when talking about using it in practice, because HTTP is the only protocol in existance that resembles REST's uniform connector. FWIW, another one - Waka, intended as an HTTP replacement - will have its spec published soon. It will be interesting to see if it includes or suggests an approach to message based security.