1 Raindrop

It a Vulnerability Mashup: Web 2.0 Security in a Nutshell

Matasano: Vulneraility Reporting in a Web 2.0 World. Same old security problems, just no one to report it to or fix 'em.

Step #1: I send in a vulnerability report. I explain the vulnerability in a concise email and include repro steps.

They reply:

Thanks for the tip, David. It’s been noted.

BTW, most of the talks at OWASP Milan last week were on Web 2.0 attacks.

The Dark Side of AJAX, Brian Chess, Chief Scientist, Fortify Software (a sampling of 400 different known XSS vulns, goes through the popular frameworks (Atlas, Dojo, et. al.) to see which ones address Jaavscript hijacking today (basically none) and whichs ones have fixes in next versions (rsn) more info)

Overtaking Google Desktop - Leveraging XSS into Mayhem, Yair Amit, Sr. Security Researcher, Watchfire (pass XSS and CSRF attacks through to Google desktop)

Advance Web Hacking Revealed, Petko D. Petkov (AKA PDP Architect), Senior Security Researcher (showed some interesting ways to extend fundamental XSS/CSRF and mash those atatcks up using Yahoo Pipes and Google APIs)

Protecting Web Applications from Universal PDF XSS: A discussion of how weird the web application security world has become – Ivan Ristic (not possible to see attack on server)

Testing Flash Applications: A new attack vector for XSS and XSFlashing, Stefano di Paola (Summarized several existing known Flash attacks and a new one Cross Site Flashing (XSF))

I think the term Vulnerability Mashup describes the current Web 2.0 security situation pretty well. You can take your javascript attack and use it across domains, requests, and technologies. It turns out attackers can leverage the Web 2.0 ethos "web as a platform" as easily as a portlet developer. So as Web 2.0 programs struggle to achieve a secuirty 1.0 posture, they will have an interesting time dealing with attacker 3.0. In other words, Google Maps looks great, but you really don't want to run your business on this stuff.

Web 2.0 Attacker Meme Map

Web 1.0		Web 2.0
Attack server	---->	Attack client & server
Attack sites	---->	Attack sites & users
Web 1.0 security model	---->	Web 1.0 security model
OWASP Top 10	---->	CVE 400

Plaintext in schema and XML encrypted element

Is encrypted element the weakest form of encryption? It could be if the schema falls into the wrong hands. So there are three ways to encrypt XML, let's consider a sample schema that includes:

<xs:element name="Name"...>

<xs:element name="Address"...>

<xs:element name="CreditCard"...>

and a document that includes:

<name>
Joe Smith
</name>
<address>
1234 Jones Street
</address>
<creditcard>
123456789
</creditcard>

For confidentiality you can

1. Encrypt the whole document

<?xml version='1.0' ?>
<enc:EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'...>
<enc:CipherData>
<enc:CipherValue>ASDF9KFLK...</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedData>

2. Encrypt the element (in this case credit card element and content)

<?xml version='1.0' ?>
<name>
Joe Smith
</name>
<address>
1234 Jones Street
</address>
<enc:EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Content'
<enc:CipherData>
<enc:CipherValue>ASDF9KFLK...</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedData>

3. Encrypt the content (in this case credit card number)

<?xml version='1.0' ?>
<name>
Joe Smith
</name>
<address>
1234 Jones Street
</address>
<creditcard>
<enc:EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Content...>
<enc:CipherData>
<enc:CipherValue>ASDF9KFLK...</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedData>
</creditcard>

The problem with encrypting the element (and to a possibly lesser extent the document) is that if the attacker has access to the schema, then this could be a relatively huge amount of known plaintext to figure out the key. This is because schema tells you to expect in terms of the plaintext elements <creditcard></creditcard>, and there can be many cases where the element tag is larger than the content it brackets (that you are trying to protect) <creditcard>16digitccnumber</creditcard> would be 25 characters of known plaintext and 16 digits to guess.

Some solutions include:

Solution 1: Longer keys
Keith Brown points out that we need to use a key long enough to make a known plaintext attack infeasible for the duration of the time the data must be kept secret. He points to Ferguson & Schneier in Practical Crypto - "always use crypto keys and primitives which give you a the level of security you need. 256-bit symmetric keys for a 128-bit level of security."

Solution 2: Add Salt
Pump up the randomness.

Solution 3: Encrypt the content instead, same as original example encrypted content
do you care if anyone knows what the tag is <creditcard></creditcard> if the value is encrypted?

Common Attack Pattern Enumeration and Classification (CAPEC)

The first draft of CAPEC is now live. This is a list of common attack patterns (some of which appear in Hoglund and McGraw's book), where CWE and CVE give insight into weaknesses, the goal of the attack patterns is to examine these weaknesses from an attacker point of view.

Attacks are classified as:

Common Attack Pattern Enumeration and Classification

Abuse of Functionality
Spoofing
Probabilistic Techniques
Exploitation of Authentication
Resource Depletion
Exploitation of Privilege/Trust
Injection (Injecting Control Plane content through the Data Plane)
Data Structure Attacks
Data Leakage Attacks
Resource Manipulation
Time and State Attacks

Further each attack pattern has a description, attack prerequisites, probing techniques, related CWE/CVE, and some countermeasures. I contributed to several patterns, I think CAPEC is taking a step in the right direction by mapping out at least some of the known attacks. For example

From Choosing a Message/Channel Identifier on a Public/Multicast Channel:

Attack Execution Flow

1. Determine the nature of messages being transported as well as the identifiers to be used as part of the attack

2. If required, authenticate to the distribution channel

3. If any particular client's information is available through the transport means simply by selecting a particular identifier, an attacker can simply provide that particular identifier.

4.Attackers with client access connecting to output channels could change their channel identifier and see someone else's (perhaps more privileged) data.

...

Example Instance: A certain B2B interface on a large application codes for messages passed over a MQSeries queue, on a single "Partners" channel. Messages on that channel code for their client destination based on a partner_ID field, held by each message. That field is a simple integer. Attackers having access to that channel, perhaps a particularly nosey partner, can simply choose to store messages of another parnter's ID and read them as they desire. Note that authentication does not prevent a partner from leveraging this attack on other partners. It simply disallows Attackers without partner status from conducting this attack.

Whereas CWE, CVE, et. al. show some valuable info about known weaknesses, its always a good idea to look at things from an attack point of view as well.

Estonia under attack

The computer security lesson here is that the products and technologies used in Estonia, like anywhere else, assume a relatively benign environment with white picket fences (oops I mean network firewalls and SSL) to keep the bad guys out. When these assumptions are confronted by malice, then you move quickly to the scenarios below. It is highly unlikely that Estonia is vulnerable to these attacks:

WaPo on Cyber Assaults against Estonia:

TALLINN, Estonia, May 18 -- This small Baltic country, one of the most wired societies in Europe, has been subject in recent weeks to massive and coordinated cyber attacks on Web sites of the government, banks, telecommunications companies, Internet service providers and news organizations, according to Estonian and foreign officials here.

Computer security specialists here call it an unprecedented assault on the public and private electronic infrastructure of a state. They say it is originating in Russia, which is angry over Estonia's recent relocation of a Soviet war memorial. Russian officials deny any government involvement.
...
"These attacks were massive, well targeted and well organized," Jaak Aaviksoo, Estonia's minister of defense, said in an interview. They can't be viewed, he said, "as the spontaneous response of public discontent worldwide with the actions of the Estonian authorities" concerning the memorial. "Rather, we have to speak of organized attacks on basic modern infrastructures."
...
By April 30, Aarelaid said, security experts noticed an increasing level of sophistication. Government Web sites and new targets, including media Web sites, came under attack from electronic cudgels known as botnets. Bots are computers that can be remotely commanded to participate in an attack. They can be business or home computers, and are known as zombie computers.

When bots were turned loose on Estonia, Aaviksoo said, roughly 1 million unwitting computers worldwide were employed. Officials said they traced bots to countries as dissimilar as the United States, China, Vietnam, Egypt and Peru.

By May 1, Estonian Internet service providers had come under sustained attack. System administrators were forced to disconnect all customers for 20 seconds to reboot their networks.
...
"It was a concerted, well-organized attack, and that's why Estonia has taken it so seriously and so have we," said Robert Pszczel, a NATO spokesman. Estonia is a new member of NATO and the E.U.
...
On May 9, the day Russia celebrates victory in World War II, a new wave of attacks began at midnight Moscow time.

"It was the Big Bang," Aarelaid said. By his account, 4 million packets of data per second, every second for 24 hours, bombarded a host of targets that day.

"Everyone from 10-year-old boys to very experienced professionals was attacking," he said. "It was like a forest fire. It kept spreading."

By May 10, bots were probing for weaknesses in Estonian banks. They forced Estonia's largest bank to shut down online services for all customers for an hour and a half. Online banking remains closed to all customers outside the Baltic States and Scandinavia, according to Jaan Priisalu, head of the IT risk management group at Hansabank, a major Baltic bank.

"The nature of the latest attacks is very different," said Linnar Viik, a government IT consultant, "and it's no longer a bunch of zombie computers, but things you can't buy from the black market," he said. "This is something that will be very deeply analyzed, because it's a new level of risk. In the 21st century, the understanding of a state is no longer only its territory and its airspace, but it's also its electronic infrastructure.

"This is not some virtual world," Viik added. "This is part of our independence. And these attacks were an attempt to take one country back to the cave, back to the Stone Age."

Increasing assurance in the system is part of engineering your system to be resilient to malicious abuse.

"Software security is the idea of engineering software so that it continues to function correctly under malicious attack," Gary McGraw

XML Security Gateway Evaluation Criteria Project Update

Here is the deck from my OWASP Europe presentation today on day 1 in Milan.

Dave Wichers on Good Enough Security

Dave Wichers "I am always looking for things that raise the _whole_ floor two inches" on the new SANS secure programming ceritification.

OWASP Milan

Yesterday, I gave the SOA, Web services, and XML security training class at OWASP Europe. Today, I am giving an update on the XML Security Gateway Evalution Criteria Project (XSGEC). Pravir Chandra is about to give an update on the progress with CLASP. Also, Pravir told me about some really interesting stuff he did with Kent Beck on applying security to XP. If he doesn't write it up soon on his blog then I will.

**
SOA, Web services, and XML Security training - FISA (June 4, Helsinki) & Speaking at OWASP Helsinki June 5

The Fighting Sioux

From Diggings

At the annual National Cable & Telecommunications Association, Time Warner CEO Richard Parsons stated, “The Googles of the world, they are the Custer of the modern world. We are the Sioux Nation. They will lose this war if they go to war. The notion that the new kids on the block have taken over is a false notion.”

I would have to agree they have not taken over the block - they built another, better block.

In an overly simplistic manner of assessing winners and losers, Time Warner has created virtually no shareholder value in the past 5 years, while Google’s stock is up more than 300%. Of course, there are plenty of ways to measure the scoreboard for companies like Time Warner and Google, but I’d argue that building shareholder value is perhaps the most appropriate in this context, and by this measure, Google has absolutely annihilated Time Warner.

Time marches on. I wonder what Vanilla Ice is doing these days?

MetriCon 2.0

MetriCon 2.0 is fast approaching...to get a flavor for what this collaborative workshop is about, see SecurityMetrics.org and the MetriCon 1.0 digest.

It is August 7 in Boston, during Usenix Security. There are still a few days to notify the committee if you are interested in participating.

Security, Naturally

I am with Pete Lindstrom on this because, well, crikey, it makes no sense - Schneier says - we don't need an IT security industry. Its a big historical accident. Programs should just be naturally secure. Uuuhhhmm...okkk....that's great and all, we'll just move all our lives, assets, money, businesses, and stuff to the digital world and these perfectly secure programs will magically protect them all. If ifs and buts were candy and nuts, we'd all have a Merry Christmas.

Except in real life these things don't protect themselves either, we seem to spend 500 billion USD annually on the military, plus law enforcement, fraud detection, and so on, because we have assets that need to be protected (I have never seen (so far) a $100 bill defend itself from a criminal, this may be a utopian vision, but perhaps with sufficient nanotechnology in my lifetime...sheesh). Some percentage of what your asset is worth gets put towards protecting it. Our assets are increasingly digital. Oh yeah, and no one has actually figured out how to write/deploy/scale secure programs either (want to be secure? buy a firewall...want to be twice as secure? buy two!)...the US navy exists today not to fight wars, but to keep supply routes open for commercial ships (many of which are not US ships), the ships, the ocean, and the shipping lanes are not "naturally secure". You know why? Because nothing is!

Why did Brazil never have wars? he wondered. Brazil was a really big country on a big American continent. How come Brazil had no enemies? It didn't make sense... Brazilians didn't invent much. Well, that explained it. -Bruce Sterling, Zenith Angle

I do agree that the way the IT security industry is presently constituted, is not effective, focuses WAY too much on network security instead of app and data security, and is incredibly reactive and tactically focused. So the lineage of how we got here versus the real issues needs to be addressed going forward; but that is a lot different from saying that these products and services will just secure themselves.

The pharmaceutical industry is just an historically accidental aftermarket that cropped because human bodies are not naturally resilient.

Dentistry is just an historically accidental aftermarket that cropped because teeth are wimpy.

Insurance is just an historically accidental aftermarket that cropped because people should know when they are going to die/get sick/have a fire in the house.