Friday, January 29, 2010

Chrome Supports Strict Transport Security (STS)

Good news for our continual efforts to increase SSL/TLS security in applications and browsers. The new release of Google Chrome supports Strict Transport Security! Hats off to the STS team and Paypal, one of the early adopters that helped get STS moving. In addition to Chrome 4.0.249.78, STS is also supported on Firefox via the NoScript plugin. So now that Chrome has adopted support, I'd like to see Firefox (without need for NoScript) and IE also provide STS support.

-Michael Coates

Friday, January 22, 2010

Cookie Forcing - Trust your cookies no more

Cookies are most often used to simply hold and exchange the session id with the application server. However, in some cases an application decides to implement a custom cookie. We all know this is generally a dangerous idea because the user can easily tamper with their cookies.

But, did you know that any attacker can easily tamper with your cookies too? In fact, an attacker executing an HTTP based man-in-the-middle attack can edit any of your cookies for any site? This includes cookies that have been marked "secure" or are set and exchanged with a site purely over HTTPS.

What does this mean?
  • Cookie integrity is dead. Any cookie can be modified by an attacker without any warnings to the user.
  • Custom cookies must now be eliminated. Any predictable information in a cookie could be modified by an attacker to cause undesirable results for the victim.
  • Cookie confidentiality is still secure. This issue allows an attacker to modify your cookies, but does not allow them to view your cookies.
  • This attack is an HTTP MitM attack. This is important because there will not be any certificate error messages to the user, this attack is nearly undetectable.
I have to admit, I didn't discover this issue on my own. I stumbled upon it one day here. I couldn't believe this item had slipped by with little discussion for the past year. In my disbelief I setup a few test cases in IE8 and Firefox 3.5 to confirm it is true.

To fully illustrate the issue, take a look at this chart I put together. A few things to note:
  • The man-in-the-middle never attempts to be in the middle of HTTPS traffic. That traffic stream is left untouched.
  • The MitM simply waits for any unrelated HTTP request from the victim (your browser sends plenty of these for updates, google prediction searches, or any unrelated browsing by the user)
  • The MitM intercepts and responds to an HTTP request with a meta refresh to the HTTP page of the site of the cookies to be attacked (http://bank.com in this case)
  • The MitM then intercepts the HTTP request and responds with the set-cookie statement.
  • Here is where the magic happens. The browser happily accepts the set-cookie statement from HTTP even though the cookies are marked "secure" and had previously been set via HTTPS.
  • In the last step you'll note that the MitM cookie is now active for the victim.
Potential Solution:
Change browser behavior to disallow HTTP set-cookie messages to modify cookies that had been originally set via HTTPS set-cookie message.




-Michael Coates

Sunday, January 17, 2010

AppSensor Podcast - Listen Now

Heard about AppSensor? Want to learn about it without reading a word? Take a listen to a recent podcast at TechTarget.com

Listen Now

Topics Discussed:
  • What is AppSensor?
  • Example of AppSensor detection points
  • Discussion of live demo http://DefendTheApp.com
  • Why use AppSensor over a WAF?
  • API abuse and malicious widgets
  • Trend Detection
-Michael Coates

Wednesday, January 13, 2010

IE8 XSS Filter Distorting Facebook

I've previously written about the IE8 XSS filter and how it can be used to alter the appearance of a webpage (potentially introducing new flaws). In my previous discussion I used google and yahoo as two examples to illustrate how IE8 modifies the page in response to a perceived XSS attack. Google chose to disable IE8 XSS protection and Yahoo did not. This provided a great example on the effects of the IE8 XSS filter. However, Yahoo has sinced disabled XSS protection and effectively killed my example.

So now, I leave you with this. Facebook has not disabled the IE8 XSS Filter. As a result, you can create a non-malicious link which invokes the XSS protection in IE8. This causes the resulting page to be significantly distorted.


This page is the result of visiting the link (shown below) as an authenticated user. To be clear, this is not a FaceBook design flaw. This is simply IE8 modifying the response within your browser to attempt to protect you against the benign search value of "IE8%3Cscript%3E"

http://www.facebook.com/search/?ref=search&q=IE8%3Cscript%3E&init=quick


-Michael Coates

Monday, January 11, 2010

Facebook Implements AppSensor Like Trend Monitoring

Facebook has focused its resources on monitoring user-generated content and detecting traffic spikes from Web applications tied into its framework. He said the popular social network now has the ability to take action if its systems detect an unusual surge in messages sent in a short period of time, or messages with links that could potentially send users to attack websites. [article]
It looks like applications are starting to get on board with application based intrusion detection and prevention. We talked about trend monitoring, web detection and attack detection at OWASP AppSec DC with the AppSensor presentation: Defend Yourself: Integrating Real Time Defenses into Online Applications [presentation pdf]

Any facebook security folks out there? The OWASP AppSensor team is happy to join forces with you on your attack detection & prevention efforts.

Interested in checking out a live demo application utilizing AppSensor attack detection? Check out http://DefendTheApp.com

-Michael Coates

SQL Injection + PII = $60 Million Fine

The Heartland settlement for their massive 2009 compromise will end up costing $60 million. It appears that the number could have been substantially higher since Bob Carr, Hearland's CEO, referred to this amount as "fair".

To recap the original attack, this was an application security based vulnerability that exploited SQL Injection flaws. Further, the attack also leveraged a lack of encryption on the internal network to enable sniffing of clear text sensitive data.

I leave you with this point for consideration; take a look at your application security budget for your critical applications. How does the budget compare with the potential for a $60 million dollar loss? Are you confident in your secure development processes, code review, and application security assessments?

Take a look at OWASP ASVS to evaluate the quality of your application security efforts.


-Michael Coates

Thursday, January 7, 2010

Geo Location Based DDOS from Mobile

The sharp rise of smart mobile phones is introducing a new and concerning attack vector - a geo-location based DDOS. Imagine a popular mobile application (bejeweled like game) that is downloaded by many. The app contains a small amount of code to reference the phone's GPS and also check in with a command and control website. The attacker decides on a city to target and a popular time of day and then updates the command and control website. The mobie applications all check in with the C&C site and all mobile applications in the city area begin downloading large video files from YouTube.

Result?
A massive sudden spike in high bandwidth usage of the mobile data network in a single metropolitan area. Most cellular networks run near capacity during the lunch rushes of popular cities. A sudden massive spike such as this would likely push the network over the edge and bring it down entirely.


This is a tough issue to address and I think it warrants a bit of consideration.



-Michael Coates

Monday, January 4, 2010

GSM Encryption Broken - Cellular Calls At Risk

GSM networks in the US and Europe use the A5/1 stream cipher to ensure cellular calls cannot be listened into by unauthorized parties monitoring radio traffic. However, the guarantee of privacy is no longer ensured. New attack techniques were unveiled at the Hacking at Random conference in The Netherlends which would allow an attacker to decrypt cellular calls made over a GSM network. The attacker only needs the new software and about $500 in radio monitoring equipment. The AS5/1 cipher has been criticized for many years, but this is one of the first publicly available exploits to demonstrate the weaknesses first hand.

The presentation is here.
The A5/1 cracking project homepage is here.

GSM is used by many major cellular providers such as AT&T and T-Mobile (see GSM Coverage Map). The main alternative to GSM network is CDMA which is used by providers such as Verizon, Alltel and US Cellular (see CDMA World Map).

Impacts?
The ability to decrypt A5/1 encryption would enable an attacker to listen in to all cellular communications made over a GSM network. To execute the attack the attacker would need to be close enough to the target to monitor the radio waves emitted from the phone. However, this isn't much of a restriction since the radio waves can be picked up from quite some distance.

This attack should raise serious concerns about the sensitivity of information exchanged over cell phones. An attacker with this equipment situated near a major corporate office or within a large city could easily glean very sensitive data from cellular voice calls.

Regarding data exchanged over cellular phones (e.g. 3G or EDGE), this shouldn't really have any impact. All sensitive data should already be configured to use SSL/TLS or VPN for protection during transmission. Therefore, the attacker could break the A5/1 cipher, but they would only see encrypted data being exchanged. However, all data that is exchanged using clear text protocols (HTTP, telnet, ftp, etc) would be visible to the attacker. This is not much of a concern since there should not be any expectation of confidentiality when using a clear text protocol anyway.

A bit about the attack
The attack leverages rainbow tables for a Time-Memory Trade-Off based attack. The A5/1 cracking project is enabling volunteers to help develop the rainbow tables for the A5/1 cipher and distributing the generated tables over bittorrent. Clever adaptations were made to the rainbow table generation to minimize the number of tables that were needed and thus dramatically reduced the required processing efforts.

-Michael Coates