...Application Security...

Geo Location Based DDOS from Mobile

2010-01-07T07:59:00.002-06:00

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

GSM Encryption Broken - Cellular Calls At Risk

2010-01-04T05:00:00.003-06:00

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

Video Stream for Unmanned Drone Hacked

2009-12-17T13:23:00.005-06:00

In what can only be described as a complete failure to plan for security, multiple news organizations are reporting that Iraqi insurgents are able to intercept the video stream sent from unmaned US drones.

It really is amazing that any data would be sent over an unencrypted channel. According to the article, the video was sent via satellite and did not use any sort of encryption. The insurgents were able to use a publicly available satellite grabbing software to intercept the stream.

I have to wonder if this design was something that "slipped through the cracks" or was deemed low risk and too expensive to implement encryption controls.

We will of course never know what decisions led to the lack of data encryption in the drone. We can only hope that this event will be a reminder that any electronic device of value must be designed with a threat model and comprehensive security controls to thwart digital attacks.

-Michael Coates

DefendTheApp - An OWASP AppSensor Project

2009-12-14T09:42:00.006-06:00

DefendTheApp.com is now live. This site provides a fully functioning demonstration application that has implemented an AppSensor detection and response capability. The site also provides easy links to all relevant AppSensor information.

Not familiar with AppSensor? The basic idea is this; currently applications use a variety of secure development techniques to prevent an attacker from being able to break into the application. Secure development is great, however, we can't just stop there.

Consider the defensive strategies used by physical banks, prisons, federal buildings, etc. We do use security controls to prevent attacks (locked doors, ID card to enter) , however, we also use a variety of methods to monitor and detect attackers before they have succeeded in their devious intents (cameras, guards, motion sensors, alarms). And in the real world, we put most of our faith in the ability to detect and catch a criminal, not in the ability to design a system that can withstand a relentless and unrestricted series of attacks.

This is the idea of AppSensor. Implement detection points within the application to discover a malicious user that is probing for vulnerabilities. Once the user is detected and a threshold of malicious activity is reached, report the user as an attacker and lock that user out of the application. If you can detect attackers and lock them out before the attacker finds a vulnerability, then you've significantly enhanced the security of your application.

-Michael Coates

Droid Jail Break Released

2009-12-11T10:39:00.005-06:00

Jail break code has been released for the new Motorola Droid phone running on Verizon network. The code works for Droid running on Android 2.0 or Android 2.0.1.

Unlike the iPhone, the Android platform is designed to be open. So it will be interesting to see what additional benefits are provided by jail breaking the droid.

A few things to consider before you jail break your droid.

You put all sorts of sensitive data in that phone.
The phone is linked to your credit card. A malicious app that calls up Cambodia each night will cost you $$$.
Do you trust that code you are installing on your phone? If it works as described, jail breaking will remove whatever barriers were left on an already open phone. More information is needed, but there is a potential that you are putting yourself at more risk by doing this.
(Unrelated to jail breaking) Please secure whatever apps you do end up installing. It really was pretty bad when people jail broke the iPhone and installed SSH with the default root password.

-Michael Coates

IP Spoofing

2009-12-08T14:50:00.004-06:00

If you are using any sort of IP based filtering within your application, then you need to evaluate how IP spoofing attacks affect your security controls. In order to make a fair evaluation you will need a basic understanding of IP spoofing attacks.

Let's look at two different scenarios.

Scenario #1 Attacker wants to spoof an arbitrary IP address and the attacker is not on the same subnet (broadcast domain) as the targeted IP address. Example: attacker is 1.2.3.4 and wishing to spoof 4.5.6.7

Scenario #2 Attacker wants to spoof an IP address of someone on his own subnet (broadcast domain). Example: attacker is 192.168.1.55 and wishing to spoof 192.168.1.58 (assuming subnet of 255.255.255.0)

Scenario #1

The attacker can create forged TCP packets and modifies the source IP address to be any value. One tool that can do this is HPING2.

What can you (the attacker) do:

Send an initial TCP packet with any source IP address
Send a series of UDP packets with any source IP address
Send a series of unrelated TCP packets from the same or varying IP addresses

What can't you (the attacker) do:

Receive any responses to your forged messages. The responses, if sent, would go to the forged IP address.
Send a string of related TCP packets (e.g. reconstruct an actual TCP exchange). This is because you can't complete the handshake or guess the necessary information to continue the TCP connection.

Scenario #2

The attacker can perform a variety of attacks to forge or take-over the IP address on the same subnet.

Attack Options:

Simplest - Statically define your IP address to the target IP address
Switch your MAC address to the MAC address of the current NIC for the target IP address and attempt to assume control of IP
Execute man in the middle attack via arp spoofing (see tool Cain & Abel) and then gain control of user's unencrypted transmissions. You could likely modify or redirect traffic to accomplish your original spoofing goal.

What can you (the attacker) do:

Assume control of the IP address. Note: This means you can send/receive valid data using the targeted IP address as your own. It does not grant you access to existing sessions that the user had with any websites (because you don't have the user's session cookies).

What can't you (the attacker) do:

Intercept encrypted (e.g. SSL/TLS) communication destined for the target IP address without alerting the targeted user in some way (browser warning message for MitM invalid certificate).

Hope this is helpful. This is by no means an exhaustive list of attack techniques, but something to consider if your are using IP related controls within an application.

-Michael Coates

iPhone Privacy Presentation

2009-12-04T08:14:00.003-06:00

Slides 1 - 14: History of iPhone privacy issues
Slide 15: Personal data that can be easily accessed by rogue applications
Slide 19: Recommendations to mitigate security concerns on iPhone

Link to original pdf

-Michael Coates

iPhone, Android Support Weak SSL Ciphers

2009-12-01T17:45:00.000-06:00

Mobile devices are handling increasingly sensitive data as financial and banking applications are deployed to the iPhone and Android based phones. However, the challenges of SSL/TLS are being revisited on these mobile devices. Unfortunately, we are not learning from our previous mistakes with standard browsers.

Today I discovered that both the iPhone and the Android software emulator (sorry, don't have a droid yet) both support weak cipher suites. For example, both devices support DES-CBC-SHA as well as a slew of other weak ciphers. To put that in perspective, DES was phased out of FIPS documents in 2002 and could be broken as early as 1999.

All modern web browsers that I have tested on computers (e.g. not mobile devices) have all disabled support for any weak cipher suites. It is quite amazing to see such a step back for mobile devices.

What's the impact? Unfortunately, many high profile web servers also support weak ciphers. As a result there is a possibility that the iPhone or Android browser could be paired up with one of these sites and decide upon a weak cipher suite. This means that all of that sensitive financial information will be exchanged using an encryption that could be broken by a determined attacker.

A few screen shots:

iPhone connecting with DES-CBC-SHA

Android emulator connecting with with DES-CBC-SHA

Confused about SSL/TLS? Let OWASP help you - TLS Cheat Sheet

-Michael Coates

Brazilian Voting Machine Attacked Via Radio Monitoring

2009-11-23T09:19:00.005-06:00

I'd like to make one point before diving into the details. And this is the reason why I am posting this story. Attackers are very clever. If you are designing a critical system that will be exposed to large numbers of people or handle sensitive transactions, then make sure you are approaching security correctly. Develop threat models, ensure secure design practices are used, train your developers to code securely, test your application for flaws, etc. Security is an entire process and mindset, not just something you can "address at the end". If you skip out on any of these items then it is just a matter of time before an attacker finds and exploits a security flaw.

And now, on to the story....

To test the new voting systems in place in Brazil, Tribunal Superior Eleitoral (TSE) hosted a hacking challenge. The team which most effectively violates the security of the system would win 5,000 R$.

The results are now in and it looks like the system did pretty well overall. Initially it was reported that none of the contestants were able to compromise the systems security. However, it was eventually revealed that one contestant, Sergio Freitas da Silva, was able to compromise the secrecy of votes by monitoring radio waves emitted as the user typed on the keyboard (Van Eck Phreaking)

"As I typed in the ballot box, tracked by radio to see if it detects any interference. I was able to track the interference that caused the wave, recording a WAV file with these sounds," he explains.

Sergio explained that after recording the sounds the buttons of the electronic ballot box have on the wave you can decode the sounds, which lead to the discovery of the candidates chosen by voters, shattering his confidence. [article]

There was some push back on the validity of this attack since it required the observer to be in close proximity to the system as the user typed on the keyboard. Sergio made the argument that a strong antenna and higher quality monitoring equipment would allow the attacker to observe from much greater distances.

Let's put things in perspective though. This is not a new attack. The Van Eck Phreaking attack has been documented since at least 1985 and the impacts of electronic emanations have been studied since at least the 1960s (TEMPEST). None-the-less, my hat is off to all of the contestants. Its only through challenges like this and secure code review that we can begin to uncover security flaws present in these critical systems.

-Michael Coates

The OWASP Mission

2009-11-21T15:32:00.003-06:00

Original document at owasp.org

OWASP AppSec DC 2009 Conference
Jeff Williams, OWASP Board Chair
The OWASP Mission

First I’d like to introduce the OWASP Board (Tom, Dave, Dinis,
Seba, and myself)
The board runs the OWASP Foundation, the 501c3 nonprofit which
provides support for all the activities that happen at OWASP. Like all
the people involved in OWASP, we volunteer our time to make the
project a success. I’d like to take this opportunity to thank each of
you for all the hard work you do to make OWASP a success.
I’d also like to thank Joe for the thoughtful keynote and for focusing
on the entire software supply chain. His focus on malicious intent is
right on and I’ll be talking about that extensively tomorrow.
If you combine all the materials available through his program and
what’s available at OWASP, we’ve got ALL the right stuff out there.
But we are still losing ground.

For years, we have watched as the software market fails to
produce secure applications.
Increasingly, this situation is worsening and there are two key
factors. First, the reliance that we put on our software infrastructure
increases every day. Application software controls our finances,
healthcare information, legal records, and even our military
defenses. Secondly, application software is growing and
interconnecting at an unprecedented rate. The sheer size and
complexity of our software infrastructure are staggering and
present novel security challenges every day.
While we have made some progress in security over the last decade,
our efforts have been almost completely eclipsed by these factors.
The software market and security experts still struggle to eliminate
even simple well-understood problems. Take cross-site scripting
(XSS) for example. In the last decade, XSS has grown from a
curiousity to a problem to an epidemic. Today, XSS has surpassed
the buffer overflow as the most prevalent security vulnerability of all
time. It’s the same for SQL injection. And CSRF will follow the same
pattern too.
These problems, while technically simple, have proven
extraordinarily difficult to eradicate. We can no longer afford to
tolerate software that contains this kind of easily discovered and
exploited vulnerabilities. Read about the RBS WorldPay attack from
this week – the level of coordination and sophistication required to
pull off this attack are stunning.
In addition to risks like this, we are already seriously limiting
innovation in the development of applications that can improve the
world.

Why doesn’t the software market produce secure software?
It’s possible that the risks we focus on are overblown and that the
market is actually working to produce an optimal level of security in
our applications. But the other possibility is that the software
market is broken. Despite what you might hear in economics class,
markets are not perfect. They have failures like monopolies, pricefixing,
and speculative bubbles.
One classic market problem was detailed in a Nobel Prize winning
paper by George Akerlof called “The Market for Lemons.” Basically
he showed that when sellers have more information than buyers –
like when you’re selling your used car that barely runs – buyers will
discount the price they’re willing to pay. That means people with
good cars can’t get a fair price and so they won’t sell. And that
means you can only buy lemons in the used car market.
Now think about that for software. Buyers really can’t tell the
difference between secure software and insecure software. So
they’re not willing to pay more for security.
We need radical innovative ideas to fix the software market. We are
not going to “hack our way secure” – it’s going to take a culture
change.
The automobile industry made the change over at 30 year period
after Ralph Nader exposed the industry….and today we have cars
that have safety features. The food industry made the change but
only after the FDA started the Nutrition Facts program. Even the
cigarette industry has been dramatically changed through
campaigns like the “Truth…” campaign.
The OWASP mission is to make application security visible. Creating
transparency goes directly to the heart of what is wrong with the
software market and has the potential to actually change the game.

Why is OWASP the right approach?
OWASP is a worldwide free and open community focused on
improving the security of application software. Everyone is free to
participate in OWASP and all of our materials are available under a
free and open software license.
In many ways, we’re like public radio. This allows us to reach a very
broad audience and it makes it possible for us to avoid difficult
commercial relationships that influence our activities. This freedom
from commercial pressures allows us to provide unbiased, practical,
cost-effective information about application security.
I believe this objectivity is absolutely critical. For too long, much of
the appsec information in the market has come from people selling
stuff, and our message has been lost.

What is OWASP doing?
Yesterday, OWASP Leaders from around the world got together to
discuss our progress and set our priorities for 2010. Each of our
Global Committees reviewed their accomplishments and we
discussed the agenda for the future. We just established these
committees last year and they are already making huge progress
establishing the foundation we need to achieve our mission.
Before I ask Tom to review our 2010 agenda,

-Michael Coates

IE8 XSS Filter Bug

2009-11-20T08:32:00.007-06:00

The register just ran an article (IE8 bug makes 'safe' sites unsafe) talking about a flaw in Internet Explorer 8's XSS filtering. I have researched the IE8 filter in the past and provided some of my thoughts on the matter.

As the article correctly states, I'm not aware of the actual flaw that has been discovered. According to the article, the flaw was made available to Microsoft several months ago and we can presume Microsoft is actively working on a solution.

With that said, I thought I would discuss some of the technical anomalies of IE8 XSS filter so that an organization can begin to evaluate if they should, at least temporarily, disable the IE8 XSS protection for the users of their site.

The intent of IE8's xss filter is to provide a feature which "makes reflected / “Type-1” Cross-Site Scripting (XSS) vulnerabilities much more difficult to exploit from within Internet Explorer 8." [blogs.msdn.com] I believe this is a noble goal which is similar to the noScript plugin for Firefox. The blog on msdn.com has a good example of the filter working as intended. The demo application has a reflected XSS vulnerability when accepting user data from the URL and returning it to the page without output encoding - classic XSS. IE8 xss filter detects this and safely renders the attack harmless.

How The Filter Works

Now let's take a look at how the protection works in the field. Luckily we have two sites available to illustrate the functionality. Google has turned off the XSS filter, with the header X-XSS-Protection: 0, whereas Yahoo has allowed IE8 to use the XSS filter as designed.

The following two links illustrate the changes that are made by the XSS filter when an attack is detected. Each link is the URL when searching for test<script>

http://www.google.com/search?hl=en&q=test%3Cscript%3E

http://search.yahoo.com/search?p=test%3Cscript%3E

The screenshot above shows the results when following the yahoo link. The reason that we see JavaScript on the rendered page is because the IE8 filter has performed a blanket replace of <script> with <sc#ipt> throughout the entire response. This does in fact render most XSS attacks inert, but it also has the unintended consequence of disabling all JavaScript on the resulting page.

Here is a snippet of the html from the Yahoo page. The change made by the filter is highlighted in bold. If you were to search through the entire response you would see that all <script> have been replaced with <sc#ipt>. Also, the final line with the "Search results" is an html entity encoding of the search value. This is performed by the yahoo page and unrelated to the IE8 filter. This is just yahoo practicing good design.

<html lang="en"><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=8"><sc#ipt>(function(){var h=document.documentElement;h.className+=" js";(new Image()).src='http://a.l.yimg.com/a/i/us/sch/gr4/srp_metro_20090910.png';})();</script><link rel="alternate" type="application/rss+xml" title="Yahoo! Search results for test<script>"

What's the Risk with the Filter?

There are two possible concerns that should be considered:
1. Is there a potential flaw in the output encoding that is being performed by the filter?
2. Does the act of disabling all script tags throughout the page actually introduce a new vulnerability?

#1
If an attacker could determine a flaw in the output encoding (which at this point is the translation of <script> to <sc#ipt>) then the attacker could potentially craft a value that would would evade detection by the filter. Alternatively, it may be possible to identify a weakness in the actual translation which allows an attacker to insert a particular value that will become malicious as a result of the translation.

A very basic example of this concept is a regex that would remove the first instance of the word "script" from a tag. If an attacker submitted <script> this imaginary filter would output <>. This would stop a basic attack. However, if an attacker submitted <scriptscript>then the resulting value would be <script> - which would be malicious. This is the idea of potential flaw #1.

#2
The second concern is that disabling JavaScript throughout the page will inadvertently introduce a new vulnerability. Consider a scenario where an application relies heavily on AJAX. What would happen if JavaScript was suddenly disabled as a result of the XSS filter? More than likely this would just break the page. This isn't a security concern, but a usability concern. I think I'm ok with the trade-off of usability and security for this example.

But what about a scenario where the application is using JavaScript as a security control to protect the user. (We all agree JavaScript cannot be used to protect the application from a user, but there are some possible scenarios where it could be used to protect the user from the content). For this scenario we will consider some sort of mashup application which uses JavaScript to perform output encoding on data from third party sources. For whatever reason the application made a design decision that the output encoding would be performed by client side JavaScript. In this scenario, IE8's disabling of script tags throughout the page could actually disable security related JavaScript code. Could this possibly allow malicious mash-up content from the third party source to now execute?

Should Your Site Disable The IE8 XSS Filter?

I wouldn't rush to judgment and disable the filter. At this point we have word that there is a potential weakness and it is being addressed by Microsoft. We don't know of a public exploit at this time and hence can't thoroughly evaluate the impact to our respective applications. I think it would be prudent to review the impact of the XSS filter on your particular application and determine the effects of suddenly disabling the script tags within the page. More than likely this will result in the page not functioning correctly. But hey, that's not so bad if it protects the user from XSS compromise.

-Michael Coates

Watch AppSecDC Live

2009-11-11T14:51:00.005-06:00

Unable to make it to OWASP AppSec DC this week? Watch it live below.

Follow the twitter stream at #AppSecDC

-Michael Coates

Yet Another SSL/TLS Vulnerability Released

2009-11-05T08:53:00.008-06:00

Another SSL/TLS vulnerability has been recently released. This weakness appears to affect applications which use client side certificates for user authentication. More specifically, the weakness lies in the renegotiation feature. For many people, this will not be an issue, since client side certificates are rarely used with large Internet facing applications.

However, some of the more secure applications do rely on client side certificates for two-factor authentication. These groups should take notice and start preparing to implement any fixes when they are available.

According to the Register article, this issue has been known since September and key players have been working to develop a solution. A new proposal is expected to be submitted to IETF today.

Here are the links so far. Anyone out there have any more info at this time?

Register Article
Martin Rex Related Security Research & Response
Analysis by Ivan Ristic

-Michael Coates

Image source:
http://www.flickr.com/photos/subcircle/500995147/
http://subcircle.co.uk

OWASP Application Security Conference - DC

2009-11-05T06:30:00.002-06:00

I really don't have to try to convince anyone. This is more of a last call notice. The upcoming OWASP DC conference is going to be great! But in the event you've been a small dark box for the last 6 months, here is the info once again.

Conference

Schedule Day 1
Schedule Day 2

Register

I'll be there and speaking on Day 1 (AppSensor, SSL/TLS).

Hit me up if you attend @_mwc

-Michael Coates

AppSensor Project Featured on OWASP Podcast 51

2009-11-03T06:00:00.002-06:00

The OWASP AppSensor Podcast is now available online! This podcast was recorded at OWASP AppSec EU Poland in May of this year.

Have a listen

Full OWASP Podcast List

Interested in AppSensor? Check out my upcoming talk at OWASP DC - Defend Yourself: Integrating Real Time Defenses into Online Applications

-Michael Coates

HTTPS Data Exposure - GET vs POST

2009-11-02T14:24:00.010-06:00

Here is a quick chart showing the data exposure when considering GET vs POST and also HTTP vs HTTPS. The secure choice for transmission of any sensitive data is to use POST statements over SSL/TLS. Any other option will expose data at some point in the communication.

URL arguments refer to arguments in the URL for GET or POST (e.g. foo.com?arg1=something).
Body arguments refer to data communicated via POST paramaters in the HTTP request body.

This chart does not address client side caching of temporary files. Caching is a separate issue from the protocol selection and should be addressed with appropriate cache-control headers.

-Michael Coates

OWASP TLS Protection Cheat Sheet

2009-10-18T13:53:00.009-05:00

I'm now officially launching the OWASP Transport Layer Protection Cheat Sheet. This cheat sheet joins the ranks of other successful OWASP cheat sheets such as the Cross Site Scripting Prevention Cheat Sheet.

The TLS Protection Cheat Sheet provides a quick but detailed explanation of the primary considerations when implementing TLS (e.g. SSL, HTTPS) for your web application.

Here's a taste:

Secure Server Design - How to do the login page correctly, Risks of HTTP to HTTPS redirects,"Secure" cookie, HTTPS referrer leakage
Server Certificate & Protocol Configuration - TLS vs SSL, Cipher selection, Certificate Authorities
FIPS 140-2 - Certified Cryptomodules
...and more

Many thanks to the reviewers (Mike Boberski, Dave Wichers, Tyler Reguly). The cheat sheet wouldn't be where it is today without your help.

If you are attending OWASP AppSec DC I'll be speaking about several of the items within the Secure Server Design section during my power talk : Advanced SSL: The good, the bad, and the ugly.

Twitter? Use #TLSCheatSheet.

-Michael Coates

PCI Requires Developers Receive Training in Secure Coding Practices

2009-10-12T13:37:00.001-05:00

Did you know that section 6.5.a of PCI requires that developers receive security specific training which incorporates security coding best practices such as those listed at OWASP?

6.5.a Obtain and review software development processes for any web-based applications. Verify that processes require training in secure coding techniques for developers, and are based on guidance such as the OWASP guide (http://www.owasp.org).

PCI v.1.2.1

On the note of PCI, be sure to check out last week's post on PCI Requirements Soon Change Per New OWASP Top 10.

-Michael Coates

PCI Requirements Soon Change Per New OWASP Top 10

2009-10-09T13:11:00.007-05:00

Section 6.5 of PCI requires that all web applications must be developed in accordance with the security guidelines produced by OWASP. PCI version v1.2.1 references these security areas in sections 6.5.1 - 6.5.10. In addition, PCI also states the following:

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when this version of PCI DSS was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements.

A release candidate of the OWASP Top 10 is scheduled for release at OWASP AppSec DC taking place in November in Washington DC.

This version will not be an official release and hence not immediately go into effect based on the above statement by PCI. However, you may want to attend this conference and get the first view of the new OWASP Top 10.

Once the document is finalized and officially released the guidelines put forth by the OWASP Top 10 will supersede the existing items in PCI sections 6.5.1-6.5.10. As such, compliance with PCI will immediately require that applications are designed with defenses to prevent against the vulnerabilities identified in the 2009 version of the OWASP Top 10.

-Michael Coates

Report Confirms - SSL Largely Misunderstood

2009-10-09T00:28:00.000-05:00

[All quotes from Dark Reading Story]

Interesting statistics on users, info sec users, and SSL from Tyler Reguly's research discussed at the SecTor Conference.

Regarding average web users:

Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords.

I'm not terribly surprised here. Most users are aware of the threat of "identity thieves" and have associated SSL with protecting their credit card. I don't believe that users think through the whole process. If the attacker steals your password, then they become you and can get any information provided by the app.

Want to get an even lower percentage response? Test to see how many users consider SSL an important factor after they've logged in (e.g. after login page, but not a page which accepts credit card data). My guess is none of them will care. That's because very few average users have any concept of the risk of session ID exposure. Many popular sites operate this way - facebook, linkedin etc.

Regarding information security professionals:

More than half of the respondents don't know what Extended Validation SSL (EVSSL) is and how it differs from SSL, while 36 percent say they do.

This is not good. Security professionals need to get on the ball here. EVSSL is especially important to understand. Because, although the extra verification of the owner is good, it is not a silver bullet by any means. There are numerous other ways a site can mess up SSL - even with an EVSSL cert. (Since the EV part is the manual verification of the company's identity and has nothing to do with the technical implementation of SSL itself)

Even so, nearly one-third say the only purpose of SSL is to encrypt their traffic so it can't be sniffed.

This is a common misconception. Remember, SSL offers end-point authentication, confidentiality, replay attack protection, and built in integrity checking.

Meanwhile, 51 percent of the survey respondents said they rely on browser error messages to alert them of flaws in Website security

That's just not good. I hope that percentage is based on the average user and not an info sec community poll. On the other hand, I think it is fair to judge that a site has poor security if they can't even get the SSL portion right. Just don't think the inverse. SSL is just one piece of a large pie.

-Michael Coates

UK's Website for Citizens to Spy is Insecure Itself

2009-10-07T09:04:00.009-05:00

The UK has always had a keen interest in recording and monitoring the general population. Its all in the name of "personal security" but is often compared to Orwell's 1984 classic. With the recent announcement of the ability for home citizens to monitor the CCTVs, the UK has taken another step towards Orwell's nightmare scenario.

Casting aside the debate on big brother, I found it very interesting that the new website, which will allow the public to register to became a government paid voyeur, is in itself insecure. Internet Eyes fails to employ even the most basic security controls to protect its users.

For example:

The registration page does not use SSL. This means that an attacker could monitor the information you enter, including your username, password, name, address, email and paypal email. There is also mention that you may need to provide financial information to receive payment, so that info would be available for the attacker as well.
If you attempt to browse to the equivalent SSL page, you see a huge browser warning that the SSL certificate is both expired and also only supposed to be used for a site called feedthelake.com

Both of these are huge red flags in the area of application security. And consider this, these items are some of the most fundamental security controls that can be easily observed by all users. If a site is having difficulty with these items, just imagine whats going on behind the scenes. It can't be good.

The other interesting item is that both of these security failures are in violation of the site's own privacy policy. (emphasis added)

13. Your information is stored on our servers located in the United Kingdom. We treat data as an asset that must be protected and use a number of tools (which may include encryption, passwords and physical security) to protect your personal information against unauthorised access and disclosure.

However, I think the next few sentences of item 13 really take the cake.

However, as you probably know, third parties may unlawfully intercept or access transmissions or private communications. Therefore we do not promise, and you should not expect, that your personal information or private communications will always remain private

Actually, I didn't know that. In fact, good security controls are supposed to be implemented to prevent this very issue. Though, judging by the security on your site, or lack there of, I guess you do have a valid point.

My advice, stay away from this site. Any user registering with this site will be putting their personal and financial information at significant risk.

-Michael Coates

SSL Null Prefix Attack in the Wild

2009-10-05T22:18:00.004-05:00

Moxie Marlinspike discussed the SSL Null Prefix Attack several weeks ago at BlackHat. Due to flaws in the handling of SSL Certificates, at the time of his talk, all browsers were vulnerable. Shortly after the talk Mozilla patched Firefox for the flaw. Unfortunately, other browsers have not yet followed suit.

What does this mean for you? There is now a ficiticious paypal certificate in the wild. The certificate looks like this:

www.paypal.com\0ssl.secureconnection.cc

If you are using a browser other than Firefox, your browser will determine the above certificate to be valid for SSL connections to paypal.com. This means that an attacker with this certificate can execute a Man-In-The-Middle attack against your connections to PayPal and your browser will not alert you to anything. Again, because the non-FF browsers believe the certificate to be legitimate.

Ikes.

It's time for the other browsers to catch up and patch this flaw ASAP.

-Michael Coates

OWASP Chicago Meeting Thursday 9/17

2009-09-15T10:48:00.003-05:00

OWASP Chicago Meeting

When: Thursday, 9/17/09 - 6pm
Where: America Plaza, 540 W Madison Street
RSVP: Yes - cory@crazypenguin.com

More Info

Agenda

6:00 Refreshments and Welcome

6:15 AppSensor: Real Time Defenses against Application Worms and Malicious Attackers - Michael Coates

7:15 Assessing Thick Web Applications - Timur Duehr

-Michael Coates

OWASP DC Conference Schedule Posted

2009-08-23T13:32:00.001-05:00

The 2009 OWASP DC Conference Schedule is now available online!

I hope to see many of you there. I'll be speaking on the following two topics:

Defend Yourself: Integrating Real Time Defenses into Online Applications

Advanced SSL: The good, the bad, and the ugly

-Michael Coates
http://michael-coates.blogspot.com

SQL Injection Leads to Heartland's 130 Million Credit Card Compromise

2009-08-18T09:20:00.005-05:00

From the indictment of Albert Gonzales:

Beginning on or about December 26, 2007, Heartland was the victim of a
SQL Injection Attack on its corporate computer network that resulted
in malware being placed on its payment processing system and the
theft of more than approximately 130 million credit and debit card
numbers and corresponding Card Data.

The indictment continues and details how Gonzales was involved in multiple attacks against credit card process.

Beginning in or about August 2007, 7-Eleven was the victim of a SQL Injection
Attack that resulted in malware being placed on its network and
the theft of an undetermined number of credit and debit card
numbers and corresponding Card Data.

Don't forget about the Hannaford compromise, Gonzales was involved there too.

In or about early November 2007, a related company of Hannaford was
the victim of a SQL Injection Attack that resulted in the later
placement of malware on Hannaford’s network and the theft of
approximately 4.2 million credit and debit card numbers and
corresponding Card Data.

Two other companies are referenced in the indictment as victims of similar attacks. Their names are not available at the moment.

The basic attack went like this:

Go to the stores and identify the payment processing systems in use.
Scour the company's website for application layer vulnerabilities
Locate and exploit SQL injection vulnerabilities
Steal credit card data via SQL injection
Utilize compromised SQL server to access internal network. Install sniffers on server and any other compromised hosts.
Steal all unencrypted credit card data as it passed through the internal network payment processing.
Install backdoors to gain future access to networks as needed.

What are the glaring lessons that we can learn from this?

Application vulnerabilities can be very bad. It is not simply a matter of a defaced website, SQL injection was the launching pad for these attacks.
Sensitive data must not be transmitted without encryption. The argument of a secure internal network is flawed and demonstrates the inability for an organization to adequately understand the threats facing modern corporations.
The attackers are smart and will work hard to compromise your sensitive data. How confident are you in your application's security?

-Michael Coates