...Application Security...

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.007-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

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.008-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. (emphasize 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

WebScarab Template - DOS Testing

2009-07-31T13:53:00.004-05:00

The series of WebScarab templates continues. Today's entry is for the "Scripted" portion of WebScarab . The below code will allow you to send numerous parallel requests to your target. This is effective for testing how an application handles a large number of requests for some sort of intensive operation. As always, I provide this information to help the authorized security assessors. For all others, you are on your own.

FYI, there are several other WebScarab templates. You can find links to them on the right side of the page and also included below:

-Michael Coates

/* ======================================= */
/* Provided by http://michael-coates.blogspot.com */
/* ======================================= */

import org.owasp.webscarab.model.ConversationID;
import org.owasp.webscarab.model.HttpUrl;
import org.owasp.webscarab.model.Request;
import org.owasp.webscarab.model.Response;

// define subroutines BEFORE the main part of the script executes,
// otherwise they won't be found

//========================================
//printRequestSmall method
// Optional use this if desired by calling within editable section
void printRequestSmall(Request request){
out.println("Req "+i+" of "+TotalRequests+" to "+request.getMethod()+" "+request.getURL());
}

//========================================
//printRequest method
// Optional use this if desired by calling within editable section
void printRequest(Request request){
out.println("========");
out.println(request.getMethod());
out.println(request.getURL());
out.println(request.getVersion());
String[] headers=request.getHeaderNames();
for(String header : headers){
out.println(header+" : " + request.getHeader(header));
}
out.println("========");
}

//========================================
//printResponse method
// Optional use this if desired by calling within editable section
void printResponse(Response response){
out.println("========");
out.println(response.getStatus());
out.println(response.getMessage());
//print the headers
String[] headers=response.getHeaderNames();
for(String header : headers){
out.println(header+" : " + response.getHeader(header));
}
out.println("");
//print the content
byte[] data=response.getContent();
String data_response=new String(data);
out.println(data_response);

out.println("========");
}

// call this to fetch them in parallel
// the number of simultaneous connections is unbounded
// requests will be sent as fast as possible until reaching the
// limit set in the section at the end
void fetchParallel() {
while (hasMoreRequests() || scripted.isAsyncBusy()) {
while (hasMoreRequests()) {
request = getNextRequest();
scripted.submitAsyncRequest(request);
//printRequest(request);
printRequestSmall(request);
}

if (scripted.hasAsyncResponse()) {
while (scripted.hasAsyncResponse()) {
response = scripted.getAsyncResponse();
request = response.getRequest();
//printResponse(response);
}
} else Thread.sleep(100);
}
}

// a counter, so we can know when to stop
int i=0;
int TotalRequests;
boolean hasMoreRequests() {
return i < TotalRequests;
}

/******************************************************************************
***************** USER EDITABLE SCRIPT STARTS HERE ***************************
* *
* Of course, you can modify the bits above, but you shouldn't need *
* to, if you follow the algorithm suggested below. *
* *
******************************************************************************/
//====Set the number below equal to the total number of requests====
TotalRequests=5;

// modify this routine to construct the next request - no changes needed
Request getNextRequest() {
// create a new request copied from the template
Request request = new Request(template);
i++;
return request;
}

//====Edit this section====
// create a template that contains the basics
Request template = new Request();
template.setMethod("GET");
template.setURL(new HttpUrl("http://www..com"));
template.setVersion("HTTP/1.0");
template.setHeader("User-Agent","WebScarab");
template.setHeader("Host","www.google.com:80");
template.setHeader("Accept"," text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5");
template.setHeader("Accept-Language"," en-us,en;q=0.5");
template.setHeader("Accept-Encoding"," gzip,deflate");
template.setHeader("Accept-Charset"," ISO-8859-1,utf-8;q=0.7,*;q=0.7");
template.setHeader("Keep-Alive"," 300");
template.setHeader("Proxy-Connection"," keep-alive");
//template.setHeader("Cookie"," Some cookie values here");

//===Fetch in Parallel===
fetchParallel();

CSRF Tokens Are Not Broken

2009-07-24T11:23:00.002-05:00

You may have just read this story about a new attack against CSRF Tokens. The attack is a clever combination of the old CSS history attack against today's CSRF defense token. I give "Inferno" credit for this new discovery and applaud the creativity and technical skills which keep everyone in the industry on their toes.

However, CSRF tokens are still the most effective way at preventing CSRF attacks. This attack is a brute force attack against the CSRF token. As the article states,

[The attack] was able to find two five-figure tokens in under seven minutes.

Luckily, the normal CSRF token is much more complex. For example, here is a token generated through ESAPI (ie CSRF Guard)

G8bGdoWkA3GVARPOKsmzQUplynLJ0to1

A token with this level of complexity would not be brute forced in any reasonable amout of time. And consider this, if we could brute force this sort of value in a resonable time frame, then we would brute force the sessionID instead and just take over the user's session with the application!

-Michael Coates

IE 8 Anti-XSS A Bit Overblown

2009-07-19T13:37:00.002-05:00

IE 8's anti-xss filters may help protect users. However, its pretty strict and catches all sorts of random things. It looks like it functions on GETs only - POSTS are excluded. Based on this it would protect users against reflected XSS issues only. Any sort of stored XSS would not be mitigated by this browser control.

Here is an interesting look at some of the false positives:

Firing on just "<script>" in the url
Google: Search for <script> using the normal website. It will work.
But try going directly to the URL http://www.google.com/search?hl=en&q=%3Cscript%3E
IE 8 XSS filter kicks in.

Here are a few more
Firing on javascript:alert(document.cookie)
Ok, maybe its looking for any sort of javascript in the URL. Even though no real attacker would just pop-up a message box with the cookie.
http://www.google.com/search?hl=en&q=javascript%3Aalert%28document.cookie%29&aq=f&oq=&aqi=

Firing on javascript:a
Hmm, seems like it fires on "javascript:" followed by anything.
http://www.google.com/search?hl=en&q=javascript%3Aa&aq=f&oq=&aqi=g10

Firing on ";alert(123);
Maybe this is someone looking for an xss issue, but that is stretching it. Again, no real attack would use this.
http://www.google.com/search?source=ig&hl=en&rlz=1G1GGLQ_ENUS247&=&q=";alert(123);

Firing on ";abc(123);
Oh, nevermind, the far reaching filter fires on any JavaScript looking method following "; Doesn't matter if it actually exists or not.
http://www.google.com/search?source=ig&hl=en&rlz=1G1GGLQ_ENUS247&=&q=";abc(123);

So it looks to me that the xss filter is firing pretty liberally. The problem will begin when more people adopt IE 8 and websites start to see this filter breaking legitimate functionality. At that point the websites will begin disabling the xss filter by adding the following response header.

X-XSS-Protection: 0

http://msdn.microsoft.com/en-us/library/dd565647(VS.85).aspx

That's right. The website has the ability to disable security controls setup in your browser. Seems a little bit of an odd model right? So don't go and rely on this control for your security. If you want to take action to protect yourself then I recommend Mozilla and noScript plugin.

Also, if you are conducting security reviews and need to use IE 8 then check out this post on automatically disabling IE 8 xss with WebScarab's bean shell.

-Michael Coates

WebScarab - BeanShell to Disable IE8 XSS

2009-07-16T17:28:00.001-05:00

Using WebScarab for security testing? Here's how to disable the IE8 XSS filter. This is a good move since the IE8 filter is filled with so many false positives that its impossible to perform a fair test unless this feature is turned off.

Add the following to WebScarab's BeanShell. This can be found under Proxy->Bean Shell. Make sure the enable box is checked and hit commit.

/* Please read the JavaDoc and/or the source to understand what methods are available */
/* Template provided by http://michael-coates.blogspot.com/ */

import org.owasp.webscarab.model.Request;
import org.owasp.webscarab.model.Response;
import org.owasp.webscarab.httpclient.HTTPClient;
import java.io.IOException;
import java.io.*;

public Response fetchResponse(HTTPClient nextPlugin, Request request) throws IOException {

//=====Make changes to the requests=========
//=====Remember: These changes will be applied to all requests while the bean is enabled. ============
//request.setHeader("User-Agent","MySuperBrowser");
//==============

//Send the request and fetch the response - this is required for requests to work
Response response = nextPlugin.fetchResponse(request);

//=====Make changes to the response=========
//Modify the response to set the anti-xss header for IE8
response.setHeader("X-XSS-Protection","0");

return response;
}

-Michael Coates

Users Don't Value Their Own Data prt 2

2009-07-15T09:14:00.004-05:00

There must be chemicals in the coffee telling people not to protect their data. A few weeks back I talked about the guy who applied for a credit card over the phone while in the middle of a busy Caribou (that's a coffee house for those not living in the Midwest). Needless to say, I learned his whole life story and all PII possible.

Well, today I walked into my local caribou and was a bit irked that one woman had spread out all sorts of papers over the single large table. Normally reserved for large groups or shared by several people, she had taken the whole thing. Didn't even order a drink. Anyways, out of curiousity I glanced at the paperwork and noticed it appeared to be financial records of some sorts - invoices, investement statements, bank statements, etc. Based on the sheer quantity of documents I assume she works in the financial industry and these are the records of her clients.

So whats the security concern? Maybe someone could look over her shoulder and see the documents? True, but that's not what prompted me to tell the story. After just a few minutes of sitting here I notice the women stand up, walk over to the trash and just dump a bunch of records in the trash can! From what I could tell, they were statements from a Fidelity investment account.

Once again, despite our best efforts to protect users, we can never protect them from their own stupidity and sheer carelessness for security.

-Michael Coates

Poor Man's SSL

2009-07-14T13:35:00.004-05:00

Sometimes the 9.95 SSL certificate is just too expensive. But hey, at least they are a "thawte secure site".

-Michael Coates

Picks for Black Hat 2009

2009-07-06T19:53:00.004-05:00

If you been following the black hat course training and speaker page then you probably have realilzed that there has been a large number of changes. From selecting speakers in a delayed two group selection to canceling a large number of training classes, I can only presume the economy and limited budgets have been at play.

None-the-less, here are some talks that look interesting and I'd recommend you check out.

Day 1
1000 - 1100	Billy Hoffman & Matt Wood: Veiled - A Browser Based Darknet
1115 - 1230	Nathan Hamiel & Shawn Moyer:Weaponizing the Web
1345 - 1500	Moxie Marlinspike:More Tricks for Defeating SSL
1515 - 1630	Jeff Williams:There's a Fox in the Henhouse
Day 2
1000 - 1100	Zane Lackey & Luis Miras:Attacking SMS
1345 - 1500	Haroon Meer:Clobbering the Cloud!
1515 - 1630	Alexander Sotirov & Mike Zusman:Breaking the Security Myths of Extended Validation SSL Certificates

-Michael Coates

OWASP AppSec 2009 - Washington DC - Mark Your Calendars Now

2009-06-11T12:26:00.003-05:00

Save a few dollars of your training budgets and mark your calendars for OWASP AppSec 2009.

When: November 10-13, 2009
Where: Washington DC - Walter E. Washington Convention Center
Registration: here
More Info: OWASP AppSec 2009

Also, call for papers is closing on Monday, June 15th. If you are in the AppSec field and have something interesting to say, then submit your abstract.

Here's a hint for you early registers. If you are a OWASP member the registration cost is $50 cheaper. Since OWASP membership is $50 for a year, you are basically getting a free membership.

Update:
Linkedin Event: http://events.linkedin.com/OWASP-AppSec-DC-2009/pub/85151
Linedin Group: http://www.linkedin.com/groups?about=&gid=2030432

-Michael Coates

Testing with OpenSSL

2009-06-06T19:57:00.011-05:00

In addition to creating your own certificates, OpenSSL provides several useful features for security testing. One of my favorites is the s_client command. This command tells openssl to establish a connection with a site. If you add on the cipher argument, you can specify what level of ciphers to use when establishing the SSL connection. Interesting note: many of the largest banks still support weak DES encryption for connections to their web server. More on this in a few.

Here's the command:
openssl s_client -connect site.com:443 -cipher LOW

The cipher argument accepts NULL, LOW, MEDIUM, HIGH and FIPS.

The NULL cipher setting simply means that an SSL connection is established, but the data is sent across in clear text. This is obviously bad.

If you are curious about what ciphers are included in each of these categories, then just run the following command:
openssl ciphers LOW -v

FYI, for those looking for a list of FIPS approved ciphers, here they are (add -v for more info):
>openssl ciphers FIPS
ADH-AES256-SHA
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
AES256-SHA
ADH-AES128-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
AES128-SHA
ADH-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
DES-CBC3-SHA (note: this is actually 3des, add -v to see this info)

Now, lets discuss the impact of a server supporting weak ciphers. The main threat is a cipher downgrade attack. In this attack a man-in-the-middle tampers with the initial messages sent by the client to establish the SSL connection with the server. During these first few packets the client and server are exchanging a list of ciphers which they each support. If the client were to say, I only support DES-CBC-MD5 (weak cipher!), then the server has two options. One, drop the connection because no ciphers are mutually supported. Or two, provide support for that cipher and begin an encrypted session with the weak DES-CBC-MD5. In scenario two the user would have a normal SSL connection with the server, nice little HTTPS in the url and everything would be great. Except for one thing, DES would be the encryption algorithm used for protecting the data in transit. At this point an attacker could capture the stream of data and break the DES encryption offline at their leisure.

Should you be concerned that you may be a victim of this attack? If you are using a recent version of any browser then the answer is no. Luckily modern browsers have removed weak ciphers almost entirely. To see what ciphers are supported by your browser you can setup openssl as a server and connect to it. This is a bit more complex and requires a server cert and private key. Perhaps another post is needed to explain how to create those items.

openssl s_server -www -cert cacert.pem -key cakey.pem

Connect to the openSSL server at https://127.0.0.1:4433/ and the returned page will show a bunch of stuff including the following:

Ciphers common between both SSL end points:
DHE-RSA-AES256-SHA         DHE-DSS-AES256-SHA         AES256-SHA             
DHE-RSA-AES128-SHA         DHE-DSS-AES128-SHA         RC4-MD5                
RC4-SHA                    AES128-SHA                 EDH-RSA-DES-CBC3-SHA   
EDH-DSS-DES-CBC3-SHA       DES-CBC3-SHA

So you can see that the webbrowser used for this test (Firefox 3.0.5) only supports stronger ciphers. If you weren't convinced, just rerun the server command and specify -cipher LOW. If a connection is established, then you know the browser supports weak ciphers. If your browser does not support weak ciphers, then you should get the error message similar to:

Cannot communicate securely with peer: no common encryption algorithm(s)

Now, one final point is left to discuss. If modern browsers don't support weak ciphers, then why should we care about this at all. The answer is because plenty of applications are being designed to automatically connect to webservers and perform some sort of automated operations. During design a decesion must be mage regarding what ciphers will be support for SSL connections. If the custom application and the server both support weak ciphers (in addition to the strong ones), then there is a risk for a man in the middle cipher downgrade attack.

To wrap things up, don't just assume that because you are using SSL you are actually using a strong encryption. Make sure the client and server are both configured to only allow strong ciphers.

FYI, this is a very common problem. I took a look at several of the top banking websites and most of them support LOW ciphers. So you can thank your browsers for removing weak ciphers and protecting you on this one.

-Michael Coates

AppSensor Response to Log Monitoring

2009-05-21T17:54:00.005-05:00

As you may have noticed from the AppSensor project and the recent OWASP EU presentation, I'm not a big believer in manual log analysis to detect and block malicious activity. Here's my response to a recent article on Dark Reading recommending log analysis.

The article:
Tippett: Use Application Logs To Catch Data Breaches

My response:

There are several major barriers to utilizing logs to prevent data breaches.
1. Most systems are not properly configured to capture all of the required information to detect an attack.
2. Humans are required to manually review log data. This either requires a large number of skilled humans to monitor logs or requires automation which loses the benefit of human interpretation. In addition, the number of log entries generated by an application can grow to incredible numbers very quickly making it difficult to quickly identify malicious patterns.
3. Even if the log data is complete and the analyzers notice the events, they must detect the attacker and stop them before they are successful. As the article points out, it often takes an attacker less than 1 hour.

Recognizing this as a substantial challenge, the Open Web Application Security Project (OWASP) is developing guidance for a solution named AppSensor. Instead of attempting to solve this problem with log analysis, let’s move into the application and detect the attackers there. By utilizing detection points with low false positive rates, it is possible to detect attackers probing for weaknesses in the application. The detection mechanism ties into a response agent which can automatically lock an account after the user is deemed malicious. This approach requires no human analysis or intervention. Attackers are automatically identified and blocked.

The AppSensor approach greatly differs from traditional WAF or network based IDS devices because it is actually built into the application itself. This approach allows the detection agent to understand attacks against business logic and access control – areas traditionally ignored by products.

Everything at OWASP is free and open. Check out AppSensor if this sounds interesting.
http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

-Michael Coates

OWASP AppSec Poland in Review

2009-05-18T14:39:00.005-05:00

I just got back from OWASP Poland. I was there for a week and taught the 2 day advanced course class, attended 2 days of OWASP talks and gave my own presentation on Thursday.

Just wanted to let everyone know that the conference was a huge success. I was very impressed with the presentations and the planning/delivery of the conference. Having now attended a few OWASP conferences and a several other popular security conferences, I would definitely recommend an OWASP conference over the others any day.

In addition to the presentations, it was great to talk with others that focus on app sec all day too. There were some great people there and it’s always good to pick their brains a bit too.

The presentations are all online now (Day 1, Day 2). I’d recommend you take a look at a few of them.

• OWASP Live CD (PPT) – Matt Tesauro
Whenever attempting to run a new OWASP tool, start here. Its probably already installed and working.

• Threat Modeling (PPT) - John Steven
Always good to get some more feedback and consideration on how to increase the quality of threat diagrams for architecture type assessments.

• O2 - Advanced Source Code Analysis Toolkit - Dinis Cruz
No slides available, but this talk was really interesting. Dinis is moving towards a tool which blends static and run time analysis via breakpoints. The demo showed some very interesting call flow graphs to help analyze data from source to sink.

• The Software Assurance Maturity Model (SAMM) (PPT) - Pravir Chandra
Definitely should take a look at SAMM if you haven’t already.

• HTTP Parameter Pollution (PDF) - Luca Carettoni, & Stefano Di Paola
This was an interesting talk. It could have used a little more organization and clarity to drive home the root issue. However, what I took away was that different application servers handle the presence of duplicate URL parameters differently (ie http://somesite.com?var1=abcd&va1=efgh).

Some app servers take the first, others take the second, and some concatenate. This can be used maliciously in two different ways.
1. Bypass URL filtering put in place by WAFs (ie http://somesite.com?var1=Select user,pass,&var1=dob From USERS).
2. It can be used to potentially overwrite statically defined URL arguments if a dispatcher model is used in code. Ie

protected void doGet(HttpServletRequest request, HttpServletResponse response){
//dispatch request
String URL="http://internalPage.com/search?role=user&"+request.getParameter("query");
...

Which would be attacked by the attacker sending the following (attacker adds bold text)
http://somePublicPage.com/searchDispatch?query=abc&role=admin

• Real Time Defenses against Application Worms and Malicious Attackers (PPT) - Michael Coates
My talk went very well. Feel free to take a look at the slides. Lots of good things in store for AppSensor. I’m planning to make some big updates to the book and get a new version out in the next few months. ESAPI integration is also in the plans.

I'm always looking for new contributors, reviewers, and feedback. If you're interested post to the mailing list or shoot me an email.

-Michael Coates