Category Archives: Web Apps
EA Origin vulnerabilities, responsible disclosure, and the Force
If you’re a gamer like me, you’ve probably been waiting for the release of Star Wars: The Old Republic, currently being developed by Bioware. I’ve been looking for beta codes, and came across Penny Arcade’s beta code give-away some time ago (bless their souls).
As I was signing up for the beta, I noticed something interesting: the registration page immediately told you if the email you’d typed in matched an EA Origin account. This piqued my interest: was this exploitable, other than testing if email addresses were associated with Origin? I signed up with my Origin account, and strangely, it asked for a new password, without authenticating my current password. Digging further, I realized that you could reset the password to a new one of your choosing, with one caveat: the holder of the email account needs to access the verification link sent to the email address as part of signup. Here’s the email:
NewUser:
Thank you for joining the Star Wars™: The Old Republic™ community! To complete your registration and activate your account, simply verify your email address by clicking here. Remember, we will update or create an EA account using this email address upon your email validation.
Normally, this would be good enough to prevent unauthorized password resets, but I found it strange that nowhere on the registration page or the email did it say that my password would be reset, and no indication after the reset. Conceivably, you could sign up a large number of Origin accounts for the SWTOR beta, and if the target doesn’t log into his Origin account immediately, he’d be unaware his account has been compromised. If you’re a gamer, you’ve probably signed up for a dozen betas, hoping to get lucky now and then – a “confirm you want to join the Star Wars beta” email from EA would raise no suspicions whatsoever.
I decided to report the issue to EA. I couldn’t find a security contact on their website, but a bit of e-stalking later with a colleague, found the email address of the EA CISO, and shot off an email describing what I’d found. To my surprise, instead of being ignored or receiving a letter from their legal department, I got a response within the hour – “Do you mind sharing your details so we can address the issue promptly? We take security very seriously and would like to get on it right away.” I couldn’t have asked for anything better.
Four days and some email exchanges later, I received an email from one of their Online Development Directors: thank you for reporting the issue, a patch has been deployed – oh and we’d like to send you some free SWTOR swag to show our appreciation.
This was a pretty fun experience for me. It wasn’t a critical vulnerability, but had the potential for mass abuse. EA was on the ball in fixing the bug, and kept me in the loop. You don’t get that too often. Now if only I could use this to have EA give me a permanent beta testing status for all games 
Bug Bounties: Do they work?
Two years ago at CanSecWest Charlie Miller, Alex Sotirov and Dino Dai Zovi declared there would be no more free bugs. One of the leading philosophies for the “no more free bugs” statement is that an organization paying an individual security researcher legitimizes that research and dramatically changes the organization’s posture on reported bugs. The paying organization is saying, “this has monetary value to us and we will pay you, not attack you, for finding bugs”. The researcher is incentivized because they get money and have a known, legitimate, working relationship with the organization paying the bug bounty. Fast forward to two years later. A lot of discussion has happened regarding bug bounties in the public eye. And a lot of money has been paid for security bugs.
The concept of a bug bounty is not new and many famous hackers have offered them over the years. Donald Knuth probably has one of the oldest, and most prestigious, bug bounty programs in existence. The idea of someone who writes software offering money, even $1, for a bug is rare. Fast forward to two years since that statement at CanSecWest. Google has a web bug bounty program and a browser bug bounty program. Mozilla has a bug bounty program. ZDI also has a prominent bug bounty program (they run Pwn2Own). The experiment on bug bounties is running full steam at this point in the information security community.
Looking at the list of recent rewards from the Google Chrome Releases blog and seeing all of the $ signs next to security bugs makes me happy. I don’t feel insulted when I get paid to report bugs. I do think getting Google dollars for hard research work is gratifying. This leads me to the conclusion that these kind of programs “work” at a fundamental level. How well they work is a discussion for another time. If you had $100K to augment your security budget, every one of those dollars spent in a bug bounty program would represent a lot of research for the amount of money involved.
Identifying Malware via User-Agent Headers
Can you tell if a host is remotely infected just by a single HTTP request? For some malware the answer is yes.
By now, I think our readers are pretty familiar with PhishMe. As you can imagine, we see a lot of hits to PhishMe from a variety of browsers. And even better, we see a lot of hits to PhishMe from a variety of browsers where the user is likely to click on things. Each time a user makes a requests a website, the user’s browser sends a “user-agent” string to the web server as part of the request. A simple user-agent string looks like:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Here’s a quick break down of what this string tells us. The Mozilla/4.0 portion indicates a Mozilla-based browser. This user is running Internet Explorer 7.0 and Windows NT 5.1 (Vista). You can check your user-agent here.
Now for Internet Explorer, it’s pretty easy to append information to this user-agent string by editing the registry. You will typically see a number of .NET related items coming from a normal user-agent header on a Windows system.
Where it gets interesting is when we see user-agents like these next ones. It seems that some viruses and malware (or “potentially unwanted software”) insert their name or a token into the user-agent string. Here’s some examples we found:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; AntivirXP08; .NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; PeoplePal 7.0; .NET CLR 2.0.50727)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.1.4322; .NET CLR 2.0.50727)This last user-agent string shows the user’s browser is infected with FunWebProducts which are not nearly as much fun as they sound.
If the malware instead appends a token to the user-agent string, this token could be used to track the user from site to site or to trigger certain behavior on malicious websites. We identified several pieces of potentially unwanted software and tallied the number of infected users using PhishMe. The graph below shows the most common pieces of malware found in user-agent strings:
We looked at IE 6, 7, and 8. Using this total number of “infected” users, we broke down the infections into browser version and divided by the total number of users running each browser version to get the percentage of each version’s population which is infected. As it turns out, the portion of infections is pretty similar across all IE versions. Isn’t IE 8 suppose to protect users much more than IE 6? This is a bit of a surprise, but suggests something we’ve known about the current state of attacks. You can have strong software controls, but security still depends as much on the user operating the software safely. Even given a browser that is relatively hardened against threats, users must know how to identify sites with malware and phishing schemes in order to stay safe. Patching and updates are important, but so is user awareness.
PhishMe clients can contact our support team for an analysis of your user base.
Your embedded web server is so 2003
Meet my new favorite web server, the GoAhead WebServer. We’ve been playing around with a handful of embedded devices recently and most developers now give you some sort of web interface to configure them over. Turns out we’ve been seeing a lot of them with GoAhead’s web server, which hasn’t had an official update from the vendor since 2003. This tiny guy is written in C and the source code is downloadable (although you do need a license).
While some vendors have highly customized the server, others are running it fairly as-is with just including their own customized Active Server Pages (ASP). What is interesting from a security stand point is that a number of recent devices we’ve seen are still using old versions of the web server. Old versions that include vulnerabilities like “%5C” directory transversal attacks and changing the file extensions of a request from “.asp” to “.as%70″ to view the server side source. DoS attacks are likely to work (although I think that can be a difficult issue for any embedded web server) and you are also likely to find CSRF attacks against the applications running on this web server since developers will need to roll their own mitigation control for this. Here’s a link to the release notes with security fixes from the latest version of the GoAhead WebServer, updated December 2, 2003.
http://data.goahead.com/Software/Webserver/2.1.8/release.htm
We are all aware how important patching systems can be. My home NAS device got a firmware update a few months ago that I applied. However, even though it’s up-to-date with my vendor, it’s still vulnerable to some issues which are over six years old because they haven’t patched the code from their vendor. So take a look at your embedded device and don’t be afraid to lob some 2003 sauce at them. You might find that it still works.
Old trick with byte. Bypassing the “Safe HTML” filter.
Sending attachments over email can sometimes be a game of getting around content filtering rules. Especially when you’re in the security field and you are sending something that may look like a security threat. Recently we found ourselves needing to send out attachments with HTML code to a user who was checking their mail with Outlook Web Access (OWA). Since OWA is a web application to allow exchange users to read their email, it makes a sense that OWA will try to block attachments it detects as malicious. Enter in the “Safe HTML” filter.
The Safe HTML filter isn’t meant to protect users from everything, it’s just one of those nice extras to hopefully stop some low hanging fruit. If it’s your OWA server, you can disable this filter, but we not about to recommend that to anyone. We just needed to get our HTML attachment through (I swear officer it’s not malicious, just good clean HTML tags). It didn’t matter what we named the file (foo.gif, bar.doc, baz.foo), if it had HTML in it, the file got truncated when the user attempted to download it. After digging into our bag of old tricks, it was nice to see one come through.
From my days of playing with browser caching options, I remembered an issue with some versions of Internet Explorer where it would only obey META tags regarding caching if you had them within the first 64 KB of the page. Well using that idea, it turns out if you pad the start of your attachments with something like 1024 space characters, your HTML attachments download and open just fine in OWA. I imagine someone has done this before and would love to see if there is a more thorough review of the Safe HTML filter out there, but for us, it was just a reminder that some tricks don’t die… they just may need a few more or less bytes.
XKCD – cool shell!
If you havent been over to XKCD to see their new shell, go check it out:
http://github.com/chromakode/xkcdfools/blob/master/xkcd_cli.js <– badass
guest@xkcd:/$ vi
You should really use emacs.
guest@xkcd:/$ WHAT
Unrecognized command.
guest@xkcd:/$ rm -Rf /
guest@xkcd:/$ woo
Unrecognized command.
guest@xkcd:/$ su
God mode activated. Remember, with great power comes great ... aw, screw it, go have fun.
I’m in ur 4sq, snarfin ur password — Part II
In Part 1 of this discussion on Foursquare’s mobile applications, I demonstrated how the Foursquare Android app utilizes HTTP basic authentication over plaintext HTTP. Another intriguing aspect of all of this comes in the form of a snippet from the Foursquare API documentation:
For most methods, we require either Basic Authentication or OAuth Authentication. OAuth is the method we prefer you use so that clients do not have to hang on to usernames and passwords but can initiate requests on a user’s behalf via a special token.
As mentioned in the above snippet, OAuth is basically a protocol for authenticating and authorizing an entity (such as, say the Foursquare Android app) to perform an action on behalf of a user — without having to know the user’s credentials. OAuth can also provide additional protections such as signatures, timestamps, and nonces (to prevent replay attacks). Why, the very concept of the OAuth signature was designed for non-HTTPS communications. As seen in Part 1, the Android application uses Foursquare’s non-preferred method of authentication.
Looking at the source code of the Foursquare Android app shows that OAuth support exists, but is incomplete (and clearly not used):
This behavior doesn’t end with the Android application, though. Shortly before I drafted Part I, Foursquare announced a new version of their BlackBerry app. I promptly downloaded the app, installed it in a BlackBerry simulator, fired up Wireshark, and observed the same activity all over again:
(Anecdotal evidence suggests that the Foursquare app on iPhone does this, too. I haven’t investigated the new Windows Mobile application.)
This behavior is symptomatic of larger problems that pervade mobile applications: 1. the reliance on simple authentication mechanisms (e.g. usernames and passwords), and 2. the failure to adequately protect those mechanisms (see CWE-522 if you’re so inclined). As noted before, OAuth is the preferred method for API authorization on Foursquare, yet the developer(s) of these mobile applications elected to use the suboptimal Basic Auth method. It may seem that I’m picking on Foursquare, but this is really par for the course. As development shops race to shove their applications out the door, while sifting through the nuances of each mobile platform (RIM, Android, iPhone, BREW, Symbian, etc.), simple AuthN and AuthZ schemes will continue to pervade. Here’s to hoping that changes soon.
(Quick note: I’d originally planned a much more grandiose post, but due to time constraints decided to just call this done rather than complete. If I’m so inclined, time permitting, I’ll consider following up with a Part III)
I’m in ur 4sq, snarfin ur password — Part I
Hi, my name is Zach, and I’m a Foursquare user. If you’re not familiar with Foursquare, it’s a location-based social network and game (of sorts). Users “check in” to venues and, based on their activity, unlock “badges” and/or become “mayor” of that particular venue. Opinions of the service aside, I’m here today to highlight some issues pertinent to security (and possibly privacy) discovered in the official Foursquare mobile applications, including those running on the Android, iPhone, and BlackBerry platforms. These findings are, to some degree, part of the larger picture of mobile application security, especially with the <marketspeak> rapid convergence of mobile and web technologies. </marketspeak>
One day, during the course of continuing my Foursquare mayorship of the local bagel shop, I decided I’d go ahead and casually glimpse at what Foursquare was doing on my Android handset. I nohup’ed tcpdump in a terminal session, “checked in” to said bagel shop, and enjoyed my breakfast. Upon returning home, I copied the packet trace from my handset and analyzed it in Wireshark. Amidst the XML flying back and forth between the client and server, I noticed this:
GET /v1/checkins?geohacc=10000.0 HTTP/1.1
User-Agent: com.joelapenna.foursquared 2010011401
Host: api.foursquare.com
Connection: Keep-Alive
Authorization: Basic emFjaEBzb21lLnRsZDpteXBhc3N3b3JkWhat’s troubling here is the “Authorization” header, and the first parameter, “Basic”. In the case of “Basic” authentication, the client typically provides its credentials in the form of a username and password, which are concatenated together, separated by a colon, then encoded using Base64. For example, a username of “jrhacker” and a password of “secret” becomes “jrhacker:secret”. This is then Base64 encoded, resulting in “anJoYWNrZXI6bXlwYXNzd29yZA==”. Of course, Base64 encoding is only that — encoding. Using the Base64 encoded string from snippet above, it’s quick and easy to get credentials:
quine@durandal% echo "emFjaEBzb21lLnRsZDpteXBhc3N3b3Jk" \\
| openssl enc -base64 -d
zach@some.tld:mypasswordSo, effectively, the official Foursquare application for Android utilizes HTTP Basic Authentication over a plaintext transport (HTTP). Attacks against the cellular network notwithstanding, the credentials are still fairly safe so long as they’re not going over WiFi. However, most WiFi enabled handsets will give priority to WiFi connections when they’re enabled, meaning the user’s credentials would be exposed to trivial sniffing attacks. I’ll recreate this simple Foursquare scenario and dive just a bit deeper after the bump.
Moxie Marlinspike Un-masks Tor Users
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
How do you trust?
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
