It is common knowledge that people get phished on non-SSL HTTP web sites. RSnake has blogged and presented about the weaknesses in todays web browsers that make this possible. These same weaknesses are presumably what Moxie Marlinspike exploited after he thwarted SSL site-validation and encryption via man-in-the-middle (MITM) attacks against HTTP traffic on the Tor network, as discussed in his BlackHat DC talk.

While these weaknesses have been known, what makes Moxie’s presentation unique is that he launched this attack against a large sample set of real victims, and succeeded in capturing their login credentials. Further, Moxie has shown us that his tool SSLstrip, and others like it, can make these attacks easy and automatic – assuming you have a foothold as a MITM. Hopefully somewhere, upon reading Moxie’s slides, a browser UI designer has finally let out a “Doh!” and slapped his own forehead.

MITM attacks on SSL aside, the most interesting thing I’ve taken away from Moxie’s talk that he was able to identify user accounts for specific web sites on the Tor network. You can read about how Tor works on the Tor Project site, but the purpose of Tor is to provide reliable anonymity while surfing the Internet. Anonymity is key for folks who want to blog about their oppressive governments, as well as those who engage in less-than-ethical activities on the Internet.

Posting an anonymous blog on a free blog service is one thing. But what about anonymously logging into your bank’s web site? Or anonymously checking your PayPal account? Isn’t that kind of like anonymously presenting your drivers license to the bouncer at the bar? The person on the receiving end of the communication knows who you are claiming to be.

If I wanted to do something that would hide my identity, I would use the Tor network. However, if I were doing something to hide my identity, I would not do so using my own peronally identifiable information (PII). This really makes me wonder about the people that Moxie man-in-the-middled. Were they ignorantly using Tor, assuming that anonymity in the network provided them increased security to perform their online banking? Or were they bad guys (phishers) logging in to compromised accounts using Tor to hide their identity and protect them from prosecution?

There are a lot of misconceptions about SSL and “online security” in the non-security geek world. People don’t get it. The big question I have after Moxie’s presentation is “do similar misconceptions apply to the use of Tor”? I would be very interested to know more about the people compromised in Moxies experiment.

-Schmoilito

SSL PKI is designed to do two things: encrypt data on the wire, and allow web site validation through the use of trusted third party signatures. The former works pretty well, the Debian weak key debacle aside. Unfortunately, the latter seems about as robust and secure as Windows 98. Case in point, https://discovercard.com. As my colleague Mike Walker points out, DiscoverCard.com forces users to enter credentials on a page served over an insecure HTTP connection. In doing so, Discover leaves users with no real way to tell who they are giving their credentials to. This is a perfect example of an implementation specific design flaw that fails open and renders SSL site validation useless.

Unfortunately, Discover Card isn’t the only organization breaking PKI. The pillars of Internet security, our trusted third party Certificate Authorities, have been having a rough time recently. A number of implementation specific flaws at multiple CAs have allowed outsiders to abuse their systems and obtain certificates for which they are not authorized to hold. Sure, these implementation specific flaws can be fixed, but the lasting damage to the trust we have in PKI can’t be undone. Further, the way PKI has been handling these situations seems to further undermine whatever trust remains.

Last summer when I disclosed the details of how I got the live.com certificate to Microsoft, I told them I wasn’t going to do anything bad with it, they said thanks, we shook hands, and that was pretty much the end of it. A few weeks ago, when Sotirov and crew disclosed that they derived their very own key capable of signing certificates that would be trusted by all web browsers, the researchers told Microsoft, Mozilla, etc, that they wouldn’t do anything bad with it. These companies again said thanks, hands were shook, and that was pretty much the end of that.

We rely on WebTrust audits and other mechanisms to ensure that our commercial Certificate Authorities do their job well, and so we can be sure we’re sending our data to the web sites we trust. Unfortunately, when the audits are useless and the Certificate Authorities screw up like they did in the above two scenarios, companies like Microsoft and Mozilla are forced to make a tough call:

Do they
a) Revoke the root CA for which a duplicate signing key was derived by unknown individuals, thus breaking the Internet for many businesses and individual users
or
b) Do nothing and trust that these guys really only have an expired certificate, and didn’t generate one valid for the next couple of years since they so very easily could have.

In the end, the trust that backs PKI is replaced with the trust of a few select individuals at the organizations who manage our root certificate programs (a.k.a the browser vendors). The millions of dollars spent on web trust audits are meaningless. The CAs could have just paid all of their money earmarked for audits to Sotirov and Appelbaum in exchange for their silence, and PKI would lived to fall another day.

Burn your SSL Certificates?

PKI, while good on paper, is hard to implement securely. It has taken almost two decades for us to have web browsers that actually support the one method that PKI has to protect itself from rogue certificates: Certificate Revocation Lists. And it doesn’t really matter, since not everyone is using IE7 or Firefox 3 yet. CRLs, which are essentially blacklists, are completely ineffective when you don’t even know what rogue certificates are actually in existence.

I don’t think trusted third parties are enough. We need technology that puts the ability to make trust decisions back in the hands of end users, rather than trying to make these decisions for them.

So what can we do differently? I’m of the mindset that client side certificate / public key caching, like that of SSH, can drastically improve our ability to make trust decisions when communicating on the Internet. SSH shows us that we can communicate securely without trusted third parties. The next question is how best to apply this to web browsers. Hashes of public keys are not easily consumed by casual Internet users. Another Intrepidus colleague, Aaron Rhodes, brought up the idea of vanity hashes that are actually easily recognizable patterns. This could help, but it would certainly complicate key management.

In an effort to actually try and help make things better, rather than just ranting about how bad PKI is on this blog, I’ve actually been working on a plug-in for Firefox that lets users white list SSL public keys SSH style and alerts the user when they change. It is actually alot harder than it would seem. In my next post, I’ll talk more about this plug-in, and the challenges I’ve faced in getting it working.

-schmoilito

Authenticating to a web application is a mutual process. Before a user enters credentials into the application, they validate the web applications credentials: its hostname, content, and SSL certificate (assuming it uses SSL).

Essentially, you validate the web site against what you know to be true (hostname and expected content). The browser validates that a trusted third party signed the web sites public key, and together they vouch for the sites identity by showing you a visual cue.

If the web site passes your personal validation and you decide to provide them, the application will take your credentials and validate them against what it knows to be true: a directory or other repository with user information. If it validates your credentials, it lets you in.

Dan Kaminsky’s DNS flaw makes it possible for attackers to spoof one of the three credentials web servers use to authenticate against users: the host name. The look and feel of a particular web site is already easy to spoof: phishers have been doing this for years. The only remaining credential the web server has that can’t easily be compromised is its SSL certificate, and the signature of a trusted third party (one of the commercial certifcate authorities).

Now that two of the three credentials could be spoofed, I started wondering how hard it would be to spoof the third. If you can get a valid SSL certificate, you can completely steal the identify of a web site. Unfortunately, it is not too dificult, and it is through no technical fault of the SSL protocol.

For me, it required no social engineering, no illicit hacking or ninja skills. In fact, it was kinda scary in its simplicity, and the real fault is in the process of the certificate authority (a big one). Is it that bad? I attempted to get certs for three HUGE Internet sites, and I was successful with one. An interesting application logic problem prevented me from getting another, and the certificate authority basically told me no (over the phone) for the third. The one I did get, however, is a biggie.

I’ll drop the details at the beginning of my SSL VPN talk at BlackHat next week. I won’t divulge them sooner. Not even if Matasano kidnaps me, sends me overseas, and water boards me.

-Schmoilito

A few weeks ago I was looking into writing an application for my iPhone. At some point, I felt compelled to actually give it a shot, and I headed over to Apple’s web site to download XCode and whatever other tools I needed. Of course, I couldn’t remember my Apple developer center password, so I went through their “Forgot Your Password” routine on my Dell laptop.

A few seconds later, an email popped up on my Mac containing their magic link to pull up my change password form. I clicked it and went through the reset process, which ultimately asked me to authenticate with my new password.

Finally, I was redirected to the URL I originally requested . . . on my Dell. Hmm. How did my Mac get to where my Dell originally was?

Turns out Apple was maintaining a session for me on the server which retained my original URL. When you requested a URL that required authentication, Apple 302′d you to the login page with your desired URL contained in a query-string parameter. Once on the login page, you could tamper with the URL before it was stored in the session. You could also then enter your username (or, even better, someone elses’) and initiate the change password process.

When you chose to have Apple send you a link to change your password, the session you started with your original URL persisted via the data contained in the link. After you went through the process of changing your password and you finally authenticated, Apple sent down a small HTML file with a META-REFRESH tag that actually sent you where you originally wanted to go.

It is in this HTML where the badness happened. The original URL Apple stored in the session was being written here without being HTML encoded or properly validated. Apple did prevent you from specifying http://attackersite.com, but they did not validate against iphone.html”><SCRIPT>…</SCRIPT>.

The attack would have been as follows:
1. Tamper with the original URL and inject an XSS attack.
2. Enter someone elses’ username in the logon form, and click “Forgot Your Password”
3. Have Apple send the victim the password reset email.
4. Here is the kinda far fetched part: you need to hope/pray/socially engineer/somehow get the victim to go through the password change process, and authenticate.
5. Once they authenticate, you own their browser.

This attack is interesting to me for a number of reasons. First, it is a persistent XSS attack in a credential management system (ouch!). Second, the injection point is pre-auth, while the payload executes in the victims browser post-auth. Third, it is very easy to target individual users using legitimate emails from Apple: no spoofing required!

Apple was very quick to fix the problem, and even gave us credit here.

Good job Apple!

-Schmoilito

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”