Skeptikal.org

Old-School Hackers

2010-03-10T12:41:00.000-08:00

My mom's uncle Bob passed away last night. That's too bad, I never really spent a lot of time with him, and I didn't even know he existed until about a year ago, when I was traveling through southern Utah with my family and we decided to pop in and visit. He was awesome.

While I'm not really active in the DIY community, I always had that mentality- when I was a kid, I'd spend days playing with my Erector set or taking apart toasters and hard drives, eventually graduating to cars and motorcycles, and finally getting into the software side of computers. I consider breaking, fixing and building things an essential part of life, but anything I can do pales in comparison to Uncle Bob. He lived through the Great Depression, and spent most of his life in a farming community that never really made it out of the depression. He never threw anything away, and his back yard was a massive junk yard- the kind of place that car people fantasize about. Old tractors, vintage Fords, Chevys, Cadillacs, and a weather-beaten-but-mostly-intact International Harvester (remember Mater from the film Cars?). Most of them aren't salvageable, but there are some gems. He flew a Cessna until its hangar collapsed in a windstorm, at which point he bought a Corvette "so he could still fly." Like many of us, he was a serial career changer, doing what he thought was interesting, moving on when he found something else.

Uncle Bob had a perpetual motion machine (Except he didn't like people calling it that, because that's impossible. It was a "generator") that would lift a weight up an inclined plane, let it slide down, powering a generator that charged a battery that in turn would lift the weight up... I have no idea how it was supposed to work, because he never did figure out the friction issue. Maybe somebody here has ideas. It was a pretty cool bit of fabrication, at any rate.

No point to this post really, I've just been meaning to write about him since I met him. We could all learn a lot from the hot rodders, builders, mechanics, and DIY-enthusiasts-by-necessity of past generations.

If not, they still have great stories.

Making A Change²

2010-02-17T08:07:00.000-08:00

Sometimes, you go out looking for change, and sometimes it just happens.

Since I joined Foreground Security, I've been lucky enough to work with some top-notch skilled and dedicated people. Among them is Mike Murray, one of the world's leading experts on social engineering via psychology, linguistics and sneaky peoplehacking. Suffice it to say, I've learned a lot from him, and I've enjoyed every minute of it.

When I learned he was leaving Foreground, I was a bit disappointed. When he called me up a few weeks later to offer me a position with Mad Security, I was less disappointed. It was a tough decision, as I've had nothing but good experiences at Foreground, but I feel like I have a lot to learn yet, and I'm pretty excited about some of the new opportunities that come with it.

I'll be doing much of the same security research and penetration testing work, but with an additional focus on training- for security people, IT people and non-IT people. With everybody from developers to users, training is the most useful security tool in the bag, and is used less effectively than any other.

Financial Sector Fail

2010-02-06T21:27:00.000-08:00

The fail keeps rolling in. I'm not really sure what the story is behind this screenshot, but I'm pretty sure I can guess: A user notices that American Express's password policy forces weak passwords, then emails them to get more information. Amex responds with the following bit of creative writing:

I would like to inform you that our website has a 128 bit encryption. With this base, passwords that comprise only of letters and alphabets create an algorithm that is difficult to crack. We discourage the use of special characters because hacking softwares can recognize them very easily.

The length of the password is limited to 8 characters to reduce keyboard contact. Some softwares can decipher a password based on the information of “most common keys pressed”.

Therefore, lesser keys punched in a given frame of time lessen the possibility of the password being cracked.

Moreover, American Express is committed to protecting the privacy and security of all of our Cardmembers, both on-line and off-line. We believe that our current security measures, which include our sophisticated monitoring systems to detect unusual or fraudulent card activity, provide strong, ongoing protections for our Cardmembers.

This response may not make much sense to a non-security person, but to a security person, well... it still doesn't make much sense. 128 bit encryption makes passwords with just alphanumerics stronger than ones with a larger character set? Hacking software recognizes special characters easily? Deciphering passwords based on the most common letters? They wouldn't dare... is American Express really just using substitution ciphers to "encrypt" passwords? That is the only thing that vaguely makes sense.

This is absolutely unbelievable.

At least it would be, if I didn't have more of the same kind of stories. Fortunately mine deals with a local mortgage company, and not a $15 billion global financial services company. I sent them an email in early 2009 detailing about half a dozen issues with their website (an ancient payment and account tracking application), all of which I would rate as critical in any penetration test, and all of which could be tested unintrusively, on the client side. Things like predictable Session IDs (a timestamp, with a granularity of only seconds), password retrieval features (all you need to do is guess a username and the answer to the secret question and it echoes the password back), cross-site scripting, publicly available statements (a directory full of pdfs. Guess my loan ID (sequentially assigned), get my statements. If it's tax season, you get my SSN with it). Lack of two-factor authentication.

Bad stuff. Of course, you'd expect them to be happy to recieve a free assessment from somebody as distinguished as myself (okay Mikey, hold back the ego). My rates aren't cheap, after all. You'd expect them to at least fix things by now, but they haven't. Instead, I got an email detailing why the issues (which I had not only described, but also demonstrated to myself) would not work. The usual lies:

our #1 priority is the protection of personal information and we appreciate feedback we receive from our customers to continually improve and/or test that protection.

No, it isn't. Your #1 priority is making money from loans. You are a mortgage company, after all. If your #1 priority was security, you would be a security company.

we look at the user-id and question as the two-factor authentication. the system has been re-written (and will be implemented soon) to add a 3rd factor (ssn) and then the password will be sent to the email address on file or the user can have the option of setting themselves up again.

Oh that's good. Keep my SSN on file in the database with it. It's bad enough you're putting that data in the publicly-accessible reports.

[On XSS:] This is an area that is like a moving target. It is a high priority with us. You can also include xss cookie theft, hijacking sessions, etc. etc. we have several safeguards in place. i am not at liberty to discuss them since they are a major key to the security of our site

How comforting, you're one of those people who thinks "secret filter" is a solution for XSS. And yet, my XSS still executes. Every time. Even now, almost a year later.

[On Session ID Generation] This algorithm is extremely secure. Of course i’m not going to explain how it’s programmed. We also use hacker and virus proof servers. Once again, the algorithm in place will not allow this to happen. As i stated in my previous email the only place SSNs were visible were on the January 2009 statements, which we have removed even though we feel they were secure.

I'm tearing my hair out at this point. What algorithm is "extremely secure"? The one that takes a timestamp, and turns it into a Session ID? Remember, this was not conjecture, I actually demonstrated it for my initial email. The SSNs were only visible in the January statements, but they were never removed from the server. The links to the PDF files sure were, but all I have to do is take the link to the February statement and change a "2" to a "1". That's epic hax right there.

This shit pisses me off, and what's more, I don't have any reasonable recourse. My mortgage was sold to this company by the group I originally financed my house through. At the time, I did some research but never came up with a good answer of who to report the issue to (I'm no lawyer, but I believe this is a pretty clear violation of the GLBA). Even when I no longer have that mortgage, they're required by law to hang onto my personal data for several more years.

They aren't the first people to act negligently with my personal data, and they won't be the last. While writing this piece, I was registering a domain name on another screen, and while making the payment, I ran across more of the same stupidity, this time from my credit card company.

At that point, I couldn't help laughing.

Adobe Update Fail

2010-02-06T19:38:00.001-08:00

Hot on the tail of Mozilla's fail, we get notification from Adobe. Apparently they forgot to fix a critical Flash Player crashing bug.

Really. They just forgot.

This is not okay. Ironically, Dan Goodin wrote a piece in The Register just yesterday, remarking that an overhaul of their security program is long overdue.

I think this pretty much confirms it.

Mozilla Malware Fail

2010-02-06T15:03:00.000-08:00

Apparently Mozilla has been spreading malware in the form of a few user-submitted Firefox addons. They were infected with trojans, and some 4,600 people downloaded them. This fail doesn't suprise me- people have been talking about potential exploits from Firefox addons for years now.

I am a bit surprised that it was client-pwning malware, and not Chrome-based sniffers or keystroke loggers or something else that could work within the DOM. I have to wonder if any of those exist... Somebody should download all the extensions off addons.mozilla.org and do some static code analysis. Maybe I will, if I find myself bored in the next few weeks.

But you know what really grinds my gears? Here's the quote from Mozilla:

These were not originally detected with the anti-malware scanning tools that we have been using. We have since increased the number of scanning tools, and will be taking additional steps to minimize the risk of further incidents.

Now, I don't have much personal experience with the Mozilla team, and what I have had has been generally very good, but really? Your malware-scanning approach didn't work, so you decided... to add more scanners? Really? Do you think that's solving your problem?

I want to know more about these "additional steps," because I'm not sold. Considering this last round of screwups, I don't have a lot of faith in your scanning.

We Suck At Security

2010-02-05T00:38:00.000-08:00

Disclaimer: This is a rant. It meanders. It rambles. It contradicts itself. It uses mildly dirty words. It alternates clumsily between idealism, cynism, frustration, ignorance, and brilliance. Read at your own risk, and don't complain if you don't like what I have to say. Feel free to discuss, but don't complain. By the time you read this, I probably won't agree with me either.

We suck at security.

A few months ago, I ran across a copy of Lincoln D. Stein's Web Security FAQ. It's an awesome document that first showed up around 1994. I tried to track down the original version, and the best I could do was 1.1.4, which was published December 1995. I even went so far as to contact the guy and buy a copy of his book (1997). The "current" version of the FAQ is dated 3.1.2 February 2002.

I probably first read that FAQ in the late '90s, but I wasn't a security guy then. I was just a crappy web developer with an unhealthy love of animated GIFs. If you've never read this document, print out a copy and put it on your kitchen table. Not only will you get a kick out of it, but there are some very interesting lessons to be learned.

A high point:

Q33: What CGI scripts are known to contain security holes?

Just including this question shows how small and non-interactive the web was back then. Only two CGI scripts are named explicitly, but I find it particularly funny that FormMail is listed. FormMail is basically a script that allowed us to put contact forms on our websites, process the results, and send them to our email inboxes. Early versions had gnarly code execution bugs- the kind of thing you find in every "Hacker Training" course, but rarely find in the wild anymore. You'd think that such a dated script wouldn't be an issue today, wouldn't you? You'd be wrong.

FormMail has been revised and rewritten hundreds of times, in practically every language in use on the web. FormMail.php is now a common one, as is FormMail.cgi (AKA FormMail.pl), which is included by default with every site on every cPanel installation. Both are vulnerable to XSS. This has been known for years, but people are still using it. It's not caught by any of those PCI/Web Security scanners that regularly certify cPanel-hosted sites. I've reported it to cPanel, and it's not being fixed. It's not being removed. Bad coders are copying bad coding practices from fifteen year old scripts. Splendid.

These things aren't getting fixed, but do you think this is wholly the developers' fault? Dead wrong. This is our fault.

A recent post to the web security mailing list said "who would be 'stupid' enough to click a malicious link like bit.ly/xxxxx?" This bugs the hell out of me. bit.ly is a useful service. Somebody has to be stupid to use a useful service? I click bit.ly links every day. bit.ly has its share of problems, but if our "solution" is expecting people to not click a link we're going to fail. Expecting J. Random User to understand how bit.ly can be abused in order to not be "stupid" on the web is equally moronic. It's not his fault, the web is just designed very, very wrong.

And it's because we suck at security.

The biggest thing we're currently doing well? We're making some things easier to do right than do wrong. The code execution bugs of the 90s are indeed getting rarer, because most PHP programmers are taught to be scared of backticks, and are given libraries for interfacing with third-party applications (rather than being asked to run ImageMagick as a shell command). Sure, it still happens, and more than I'd like, but it's happening far less than it was. Let's take a lesson from that.

Side note: If you're a developer and you haven't played with the OWASP ESAPI yet, why not make your life simpler while making your code more secure? Wave of the future, man.

Specifically, the issues I like to talk about here are what I call the "application boundary bugs". These are the things like CSRF, XSS, Clickjacking, even that stupid "XSHM" one that was "released" last week. In these attacks, the exploit stems from a webapp forcing a browser to do something to another webapp. Why does it work? Because cross-domain communication is a common, legitimate, insane, and unnecessarily necessary thing for a website to do.

You know what would fix that? Putting hard boundaries on web applications. Not this Same-Origin Policy bullshit, which is regularly bypassed with ease by attackers and developers alike. Not this zone crap, which makes the outdated assumption that the sensitivity of data is related to where it's found on the network. We need boundaries that cannot be crossed under any circumstances. They need to be defined by websites, opt-in today, opt-out tomorrow, mandatory down the road, extremely easy to implement correctly, and extremely difficult to implement wrong. Let's find a solution.

It's easy to blame poor coding practices, poor site maintenance, backwards compatibility, or weird browser quirks for the issues we're dealing with today, but frankly, that's bullshit. Every party, be he browser (or plugin) designer, security appliance vendor, web developer, user, UX guy, security guy, or alcoholic vagrant (okay, those last two are pretty much the same thing), has some role to play here. My biggest complaint with this entire situation really has nothing to do with security: it is the "Somebody Else's Problem" attitude. This is everybody's problem. Whichever party you are, suck it up and be the one to handle it. Fix it for your users, your customers, or yourself. Have your marketing department spin it however they like. Charge people for a "premium" package. Please, just start fixing things. Let's fix them right. Let's fix them permanently.

NoScript is a perfect example of the "wrong" fix. Not to say it isn't useful. Today, it's a necessity, but it shouldn't be a long-term solution. It plugs countless specific holes, but does not address the major design issues around the web. On the other hand, if you've played with Request Policy, it cleanly solves CSRF, XSS, (some) history theft, and other issues. It renders the web virtually unuseable in the process, but it absolutely does solve those problems.

It's not all bad news- we're starting to get some other solutions. Mozilla's Content Security Policy may turn out to be the best thing to happen to web security in years, but it's complex, and it does very little for CSRF. There's a proposed "Origin" header to prevent CSRF, but frankly, it won't help unless it's insanely easy to enable and enforce. X-Frame-Options is great, but still pretty rough. None of these feel like complete "solutions."

Seriously, we're hackers. Hackers are supposed to be guys who can do, break, and fix anything.

What a delusional bunch we are.

Perspective on Pentagon "Pwnage"

2009-12-08T12:23:00.000-08:00

Last night, Daniel Kennedy posted on his blog about a vulnerability in the Pentagon's web site. The vulnerability that was identified used XSS to steal session cookies. The story bothered me for a few reasons. Partially because it's usually a great blog, and the wording of the post made the vulnerability sound worse than it was. Daniel has since changed the wording, and I'm perfectly okay with that.

On to the exploit. My first reaction was that it isn't news. To begin with, the vulnerability is an old, known one- posted to XSSed last April. The site with the vulnerability contains no sensitive information, and unless you want to force somebody to book a tour of the Pentagon, really doesn't appear that useful at first brush. On top of this, there is no shortage of XSS vulnerabilities in much more sensitive .gov and .mil sites. The biggest story here really is that this vulnerability has been known for so long, and still has not been patched. Sadly, lack of fixes for every found XSS vulnerabilty isn't exactly a rare thing either.

I truly believe that XSS is one of the biggest threats on the web today. I'm not one to trivialize this kind of thing, but this one is small. As far as XSS holes go, this is about as trivial as can be. That said, this is still very dangerous.

Remember my cross-subdomain cookie attacks paper from last month? This is a perfect example of how widespread these issues are. The military has a hierarchical structure. It makes sense to give military websites a hierarchical structure. In this case, the domain with the vulnerability is pentagon.afis.osd.mil. Each of these subdomains means something- .mil for military, .osd for "Office of the Secretary of Defense," .afis. for "Armed Forces Information Services", and pentagon stands for, well, the Pentagon. Each department can have its own website, and its sub-departments have subdomains.

This is exactly how the web was designed. Academic Institutions' (.edu) websites also use this model heavily. It makes sense, particularly given the military and academic background of the web. Unfortunately, due to the cross-subdomain leakage of cookies described in my previous paper, any osd.mil website (there are hundreds, if not thousands of them, in various departments, serving various functions, and with various levels of sensitive data, user interaction, and exploitability) can be attacked due to this single, seemingly useless XSS hole.

As noted, finding such an XSS hole is rarely difficult. In less than half an hour, I was able to find half a dozen such domains vulnerable to XSS, some vulnerable to much worse. Most of those websites are simple informational websites, but there are a few with user logins, adminstrative sections, and sensitive data. This is where things get really scary.

Putting XSS in Perspective

After all that doom and gloom, I want to put this in perspective. As bad as an XSS hole is, it still requires somebody with the right level of access to click on it. Not necessarily hard, but definitely harder than a more direct exploit such as, for example, SQL injection. If somebody documents an XSS hole, they have not "hacked" that server. The Pentagon's website has not been "pwned." XSS is, and should be considered, a critical issue, but, at risk of appearing to agree with one of the dumbest quotes in the history of web security, it isn't generally used to hack into servers. Usually, that's not the point anyways- the attackers are after information, not a root shell.

Keep in mind, this is not a checklist of things you can and can't do with XSS. Don't use this in a risk assessment. Don't even quote me on it. This is just an attempt to put a realistic perspective around stories like the one mentioned above. I've seen too many headlines saying "$SITE Is Serving Malware!" or "$COMPANY Is Bad At Security" when there is no evidence of that happening. Web security is in a pretty dismal state right now, but spreading ungrounded FUD is simply not useful.

A single XSS vulnerability doesn't mean a company is bad at security. Frankly, a non-trivial application that is completely free of vulnerabilities is like a unicorn: It might exist, people claim to have seen them, but I have my doubts. I'd love to see organizations be more careful here, but in my experience, XSS vulnerabilities somewhere on a network is a virtual certainty. Security-wise, the key issue is what controls are in place to limit data leakage. News-wise, the key issue is how the organization responds to a vulnerability report.

XSS attacks are, by themselves, not actually very useful. However, they are attacks that stack beatifully with CSRF, credential theft, and clickjacking. They can also be leveraged nicely against vulnerable browsers and plugins to attack the client himself. It's worth noting though- unless you're stealing sensitive information directly from the page you're embedding the exploit in, it takes more than just XSS to do something malicious.

An XSS vulnerability in an application with sensitive data or access to sensitive resources (such as an internal network) is a serious matter indeed. A single targeted attack can compromise the data or allow an attacker to use the increased access of that user's browser as a jumping-off point for further attacks.

If that application is also popular, it is even more serious. The attack doesn't need to be targeted: it can be used in drive-by attacks or worms to hit a large number of users. As common as it is, this is in my opinion a worst-case scenario for XSS.

An XSS vulnerability can be used to anonymize attacks, but from what I've seen, attackers rarely bother. Using it this way generally just adds complexity without a lot of added benefit.

With cross-subdomain cookie attacks, an XSS vulnerability in one subdomain may attack another subdomain. Domains with many applications on their namespace (such as osd.mil) probably have other, more sensitive applications. Check before you disregard such a vulnerability on a non-sensitive application. They also may not. Check before you get too excited.

XSS works remarkably well for phishing. Currently, it's not particularly common to see it used this way, but it's happened before, and it will happen a lot more in the future.

There are many more uses for XSS, and there are just as many controls (ineffective as they are) for limiting XSS. The actual risks presented by an XSS vulnerability are extremely dependent on environment- the application, the server, other servers within the namespace, the web browsers being exploited, and security controls that are in place. Making vague statements about XSS vulnerabilities isn't particularly useful, and in most cases borders on FUD.

CSRF Isn't Just For Access

2009-12-04T18:38:00.000-08:00

One common assumption people make with regards to CSRF is that it is used to escalate privileges or otherwise abuse sessions. While it's certainly useful there, CSRF can also be used to DoS a website by having a few hundred visitors to your site load a resource-intensive page on the target's server. It could also be used to anonymize sql injection, remote file inclusion, and other attacks.

The concept of having a website's normal users abuse another site has fascinated me for a long time- essentially, any high-traffic website could be used to create dynamic, temporary botnets of web browsers. This is neat.

Hold that thought. Wired Magazine is in the running for AdweekMedia's "Best of the 2000s" top magazine of the decade. I'm a big fan of Wired. I'm not a big fan of Rachel Ray, whose magazine is currently in the lead. I'd never heard of Adweekmedia, but like others before me, I can't help laughing when I see an online poll, survey, petition or other people-oriented data-gathering application. While gaming such systems isn't usually very hard, I laugh even harder when I notice the application is vulnerable to CSRF. In the case of this poll, it allows one vote per IP address, but doesn't appear to contain any other restrictions.

It probably raises some ethical issues to perform this kind of attack, and I certainly wouldn't condone this kind of thing. If you want to vote for Wired, you can do so manualy with this url:

http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850

For demonstration purposes only, here's a bit of HTML that you could theoretically place in your own website, harnessing the power of your users.

<!-- Help Wired win magazine of the year VIA CSRF. Copy/paste the following code into your websites -->
<img src="http://answers.polldaddy.com/vote/?va=10&amp;pt=0&amp;r=2&amp;p=2232025&amp;a=10937850" width="1" height="1" onerror="this.parentNode.removeChild(this)">

Putting that payload into an XSS worm would get a nice spread of visitors. On the off chance that they check referers, you can iframe in a page with an HTML injection/XSS hole to do it for you:

<!-- Help Wired win magazine of the year VIA CSRF. Copy/paste the following code into your websites -->
<iframe src="http://polldaddy.com/ratings/rate.php?cmd=get&id=61037&uid=wp-comment-29028&item_id=_comm_29028%22%3E%3Cimg%20src=%22http%3A%2f%2fanswers.polldaddy.com%2fvote%2f%3Fva%3D10%26pt%3D0%26r%3D2%26p%3D2232025%26a%3D10937850%22%3E" width="1" height="1" >

To be fair, XSS isn't really necessary. They provide us with a bit of Javascript to embed the poll in our own websites. All we have to do is use a bit of our own javascript, and we can hijack that method of poll submission as well.

But why should we restrict ourselves to web browsers? Lots of other applications make HTTP requests, and we can certainly use those ones. favicon.ico and robots.txt are some of the most common URLs for non-web-clients to hit. A few .htaccess rules can be used to help herd bots, malware, and non-browser RSS readers in the right direction:

Redirect /robots.txt http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /favicon.ico http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /info.php http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /errors.php http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /rss.xml http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /atom.xml http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850

By posting a few links to Twitter, we can also get the URL prefetchers, anti-malware applicatons, and other bots in line.

Now when I think "Where can I get a lot of IP addresses?" the obvious answer is BitTorrent. We can add the URL in question (or something that redirects to it) to the "announce" and "scrape" sections of a .torrent file. The clients will perform GET requests to specified URL, and everybody is happy. Uploading a torrent of a popular TV show will get you an awful lot of clients, awfully fast. There is another way to get BT clients making requests- an unofficial extension known as WebSeeding allows one to serve up chunks of a file from an HTTP server. Again, there's no reason that BT clients won't follow the occasional redirect and snag a piece from the wrong place. They'll even recognize the pieces as invalid and download them from another location- nobody will ever know that the request was made.

This concludes my random thoughts for the day. Isn't abusing the web fun?

Today's Bad Idea: MyMoney

2009-12-02T14:12:00.000-08:00

Warning: This post makes heavy use of a cutting-edge rhetorical device known as "sarcasm." If your brain has a defective superior frontal gyrus, please consult your doctor before continuing.

I'm a heavy Facebook user, and most of my friends are too. I love it! Facebook is like an online portal to my social life. It also has a convenient platform for including third-party applications, so I can not only communcate with my friends: I can also play online poker, have (simulated) gang wars, and send fun quizzes to them. Awesome!

The only thing I was really missing was the ability to manage my finances from my facebook page. It drives me insane to have to fire up a separate web browser, navigate to my bank's website, type in a username and a password and punch in those frustrating digits from my hardware token. That's just too much work. If I had my way, I'd have a running counter of my net worth on my Facebook wall, like a villain from a James Bond movie. Bummer!

Imagine how excited I was to receive an email from Etienne Janot, letting me know that the future is here: Fiserv has a product called MyMoney. MyMoney is an application that "enables Facebook users to search for and join a financial institution and manage their funds via the familiar Facebook interface." Sweet!

The video on Fiserv's website really sells it to me: it helps bring the boring world of banking to us fast-paced Gen Y users. Not only that, but (quoting from their website, because I really couldn't make this up) "MyMoney also leverages Facebook's viral marketing opportunities. When Facebook users add MyMoney to their profile, their friends are notified and given the opportunity to add it too, enabling financial institutions to extend their reach, particularly within the Gen Y market." I've always wanted to know who my friends bank with, and now, thanks to MyMoney, I can! Woot!

I know you're thinking this is a bad idea, and are concerned about MyMoney's security. Don't worry, I checked it out. They have "multiple layers of security protecting...data and accounts." The application iframes you into their site (hosted on https://mm.galaxyplus.com). If you forget the URL, they left zone transfers enabled for you, so you can just select from a list of galaxyplus.com subdomains. The iframe's URL has a parameter called "fb_sig_user." If you manipulate this parameter, you get to see the contents of all your friends' accounts (presumably so you can borrow money without all that awkward asking). The only thing I don't like about this application is that they left error reporting on. I don't like seeing those ugly ASP stack traces every time I use an HTML tag as a form parameter. Lol!

All in all, I'd say this whole MyMoney thing is a pretty damn good idea. I'm glad somebody did it.

XSS Kiosk Busting

2009-11-16T14:47:00.000-08:00

You know those kiosks that you find in bookstores for looking up inventory? The idea of XSS-ing one occured to me a few years ago, but I never really got a chance to play with any and forgot about it until recently. I was at Sur La Table last weekend, trying to figure out which kitchen supplies I haven't bought yet (turns out, it was more knives), and noticed the wedding/gift registry...

Mostly, I just think this is funny, but there are potential malicious applications for this kind of thing. For example, Wal-mart's job applications are done through a web application running on a kiosk in the customer service area. If you can inject javascript into that application, you could rewrite the whole thing to log personal information from applicants.

Presuming that those computers are connected to the internet (and I expect they are), it would only require that you inject a single <script> tag, and you could do all the rest with BeEF. Since it's a kiosk, nobody is able to look at the address bar or status bar and see that anything is wrong.

Adobe Responds... Sort Of

2009-11-14T12:05:00.000-08:00

Adobe has published a response to the latest issues I've been talking about. Somehow, they have managed to neatly dodge the issues in question and fixate on the Same Origin Policy. Is that policy news to anybody? Of course not. That's not the point. That's not even the issue, though I do believe the policy is flawed, which I'll explain in a few paragraphs.

Adobe continues to compare this to uploading Javascript files. Here's the difference:

If I upload a .js file to a webserver, I cannot execute it in the context of that server. Javascript alone will not execute.

If I upload a .html file to a webserver, I can execute Javascript within it in the context of that server, because my browser recognizes the text/html content-type header that the webserver sends.

If I upload a .html file to a webserver, but an application/zip header is sent by the server, it will not render at all.

If I upload an HTML file with a non-html extension to a webserver, and the server does not send a text/html content-type when serving the file, I cannot render HTML or execute Javascript.

If I upload a ZIP file with HTML prepended to it, I cannot render HTML or execute Javascript.

If I upload a .swf file to a webserver, I can execute it in the context of that server.

If I upload a SWF file with a non-SWF extension to a web server, I can execute it in the context of the server.

If I upload a ZIP file with a SWF file prepended to it, and the server sends an "application/zip" content-type, I can execute it in the context of the server.

Flash's handling of potential code is clearly MUCH more permissive than Javascript's.

This makes it far easier to upload an object to a webserver- a Flash file can look like anything to the server and still be executable, as long as it starts with the right sequence of bytes. In many cases, simply changing the file's extension is enough to bypass upload restrictions. In other cases, you have to get crazy with it, but as noted in the original post, the entire ZIP family of files can have a SWF embedded in them while still being valid. Checking whether the file is a valid ZIP file will do you no good. The only way to be sure that the file does not contain a SWF is to specifically look for a SWF header. Any security professional will tell you that a technology that requires a blacklist approach to input validation is poorly designed.

There are some solutions for the security administrator. They aren't easy to implement. The best thing to do is place all your user-generated content on a separate server. For large web applications, this is probably already happening. But do you think that every prebuilt forum, ecommerce, blog, and gallery application out there is going to get redesigned to fix Flash's problem? Do you think the hobbyists and mom-and-pop shops are going to set up a separate server for holding this content? As most of them don't even have one dedicated server, this is not just unrealistic to expect, it's virtually impossible. Again, I'll pull out the example of bugs.adobe.com, a prebuilt issue tracking application that stores files on... bugs.adobe.com. I reported this issue several days ago, and not only have they not moved all user-generated content off the server, they haven't even disabled the file upload feature.

The other solution for administrators is to serve user-generated files with the content-disposition: attachment header. This is relatively easy to do, and it's the only reasonable thing they've suggested. It is still hardly an ideal solution though. First off, some user-uploaded content shouldn't be served with this header. Images that people expect to be able to inline in other web pages are one example. Validating images is obviously easier (and more common) than validating zip files, but the point stands.

Now, let me be clear: The Same Origin Policy is a completely separate issue from the execution of the content, but since Adobe won't stop talking about Flash's Same Origin Policy, allow me to demonstrate exactly why it is designed wrong.

If a Javascript file hosted on foo.com is included in a web page on bar.com, that file can only affect the bar.com domain. Same origin policy. Woot.

If an HTML file hosted on foo.com is iframed into a web page on bar.com, that file can only affect the foo.com domain. Same origin policy. Woot.

If a Flash file hosted on foo.com is embedded in a web page on bar.com, that file can run Actionscript on foo.com, as well as execute Javascript on bar.com.

All the attention to this point has been on uploading malicious files, but let's take a look from another angle. What if victim.com has its own Flash objects, which use Javascript calls to interact with the web pages they're included on? This is not an unreasonable assumption- it's the very reason that a Javascript interface is built into Flash player. Here's the problem: these Flash objects can be embedded in evil.com's webpage. evil.com can run his own Javascript which modifies function prototypes (again, only in the context of evil.com), poisoning the functionality that victim.com's Flash object relies on. When that Flash object then uses data from the Javascript side of things to communicate with its origin server, you again have cross-origin interaction.

What kind of Same Origin Policy allows code to execute on multiple origins? A seriously flawed one.

From Adobe's response: "[The Same Origin Policy] states that two pieces of content hosted on the same domain and loaded by the same protocol trust each other. Conversely, two pieces of content hosted on different domains do not trust each other and cannot interact." If this was the way it worked, we would have no problem. In my examples, I used 2 pieces of content (a SWF and an HTML page with Javascript), on two domains (foo.com and bar.com), using the same protocol (HTTP), and I made them trust each other. By their own definition, Flash's policy does not work. Adobe's response is dead wrong.

Flash Origin Attack FAQ

2009-11-13T08:16:00.000-08:00

Okay, people are looking at this Flash issue. Neat. A lot of people don't fully understand it, which may be my fault. Here, I'm going to try to respond to some of the questions and comments that I've received from various parties.

This is not a single issue

While it is a single, basic issue that enables this exploit, it is the
intersection of that and several others that makes it critically bad.

Specifically, the fact that an uploaded file can attack a server is hardly news. As mentioned in my original post, Adobe has acknowledged this issue with advisories multiple times. If you were already aware of it, good on you. However, it still is new to most website administrators, and more importantly, these are the people that Adobe expects to fix it.

The part that is new, is the focus of this research, and admittedly could have been described better, is that the Flash player will execute any file it is asked to execute. The HTML <embed> tag is used to include objects that the browser may not be natively able to handle. Arguably, this may be a browser issue as well, as the content-type supplied by HTTP headers should take precedence over the type attribute specified in the HTML page, but the plugin itself should also verify that the proper content-type is sent in the server's response HTTP headers before executing the plugin. Flash's plugin does not do so.

If Flash's plugin did handle this correctly, the other issue documented here- that of overloading various filetypes, primarily ZIP, would be nearly useless. The point of that work was to demonstrate just how difficult it is for administrators to filter uploaded content by file validation, and to provide various examples of how to bypass such validation with 100% legal files, which are still potentially malicious. More on that in a moment.

This is not a cross-site scripting attack

The end result of the attack can indeed be XSS, as Actionscript may execute Javascript through the "ExternalInterface" method, but the source of this problem is not necessarily input sanitization. It is a core design flaw in Flash's same-origin policy, combined with the weak content ownership management that is already common on the majority of websites and prebuilt web applications on the internet.

Calling this attack XSS, when it involves no Javascript (arguably, not really a requirement), is not cross-site (again, not really a requirement, despite being in the name), and involves no HTML injection, is a stretch, but the similarity is certainly there, bringing me to the next point:

This attack abuses the user to attack the server

This is where it is very similar to XSS. The whole point is to hijack the user's browser and have the ability to issue requests to, and read the results from the server. In the context of a user's session, this can be a very bad thing. Neither the server itself nor the client's computer is being compromised directly; The web application, and any data or functionality within, is now accessible to the attacker.

Adobe does not intend to fix it

As they have made abundantly clear, Adobe considers this to be the web administrators' problem. Regardless of whether you agree with them or not on this, it is hard to dispute that Adobe's expectation of administrators to prevent this issue is unrealistic.

In fact, Adobe does not appear to be able to manage this issue on their own web properties. For example, photoshop.com is an interactive image library application. Uploaded images are not validated fully, and are stored on (and executable from) api.photoshop.com. This is indeed a separate domain from the rest of the application, and should be safe (though I'd point you to my paper on cross-subdomain attacks and say it is still poor practice), but www.photoshop.com's crossdomain.xml policy specifically allows access from *.photoshop.com.

Next, take a look at bugs.adobe.com. This third-party issue tracking system allows users to upload screenshots (or zip files of screenshots) of bugs. These files are hosted on bugs.adobe.com, and can be used to exploit not only bugs.adobe.com, but again through crossdomain policies, www.adobe.com, www.acrobat.com, www.photoshop.com, and other Adobe web properties.

You'll never guess where www.photographersdirectory.adobe.com keeps its uploaded images. Or where forums.adobe.com keeps users' uploaded avatars.

Clearly, expecting website administrators to understand, not to mention be able to fix this issue is ridiculous and unrealistic. I originally compared this to the GIFAR exploit, which uses very similar attack techniques against the Java plugin. Unlike Adobe, Sun took responsibility and fixed their plugin. Whether they are wrong or right, Adobe is uniquely in a position to create a client-side fix for the Flash users. Until they do so, many websites will remain vulnerable.

When Flash Attacks...

2009-11-12T10:13:00.000-08:00

Adobe doesn't have a great reputation in the security community, given the long string of exploits and 0-days that have come out over the past few years. Most of the research that I've seen, however, has been attacking the Flash player directly, rather than using it to attack web applications. This is akin to looking for buffer overflows in a Javascript parser, but completely disregarding cross-site scripting as an attack strategy.

The attackers, on the other hand, aren't so picky. From the LiveJournal worm that came out a few weeks ago, as well as some other things-I-can't-talk-about, it's clear that they are beginning to play with the interaction of Flash and web applications.

So, I've been researching this stuff as well. I've found a lot of interesting things, all of which will get released eventually. The first piece, on how to abuse a quirk in Flash's origin policy (complete with a ridiculous multistage Gmail exploit), just went live on Foreground Security's website.

Eventually, there will be a whitepaper, a talk, and some tools released. Stay tuned.

Cross-subdomain Cookie Attacks

2009-11-03T09:32:00.000-08:00

I did a talk at Toorcon last weekend on exploiting client-side applications' trust in subdomains. Primarily, it formalized and demonstrated a few attacks on cookies, which implement security policies backwards by placing more trust in a subdomain of a trusted domain, rather than less, as the hierachical nature of DNS would suggest.

Last night, I put together a quick paper summarizing these problems, with interesting proof-of-concept attacks against Google's new CSRF protection feature and Expedia.

I'm still looking into the ways that other client-side technologies (Flash, Java, etc) handle these issues, so expect a version 2.0 in the future. Also, I'm looking forward to some relevant new tools that will be released at AppSec DC next week.

Note: All the attacks outlined in this paper were responsibly disclosed, and the Google and Expedia ones, specifically, have been fixed for several weeks.

Apathy in the Security Community

2009-10-30T11:29:00.000-07:00

I've been traveling a lot lately. I've seen a lot of interesting things, done some interesting things, and talked with some interesting people, some boring people, and some legitimate crazies. I have a lot of material to discuss, and a lot to ponder.

I mentioned in a previous blog post that Black Hat and Defcon left me with some insights into the world of security, and they were largely confirmed in the past weeks. Here are a few random thoughts and reactions:

The hacker community is getting stale. Sure, the attendee numbers at conferences are still growing, but in most cases, the hacker mentality just isn't there. Before I get flamed, yes, I know that it was always a small core of people, and those people are still there. In addition, I'm actually all for having the noobs show up at Defcon, just to get a taste of what we're all about. But... I keep thinking that when I go to these events, the excited-to-be-here and stoked-to-do-things vibe isn't nearly as strong as it was just a few years ago. Geeks aren't particularly social people- I can deal with that, but I'm seeing a lot of people who are just there to be there. I guess that happens in every community- I've seen the same thing happen various other communities over the years, but I really don't like the idea of it happening to the hacker scene.

That said, there are always some bright spots. At Toorcon, I happened to be watching as two attendees rigged the candycorn-counting-contest. One asked the staff at the registration desk to stand up and face him for a photograph, and the other walked by and swapped out the jar of candycorns while their backs were turned. Most places, this kind of cheating would be unacceptable behavior, but at a hacker convention... I'm disappointed when I don't see it.

Short version... I dunno... I just want to see the attendees get more involved in those things. It's more fun that way anyways. You don't have to be a 1337 haxx0r who hasn't showered all week to make exciting things happen.

On the other side of a fast-growing split between the security community and the hacker community, we're seeing the same problem. I was in DC for CSI this week. I spoke on a 3-hour web security panel with Rafal Los, Joshua Abraham, Jennifer Jabbusch, and Sharon Besser. The people on the panel were smart, lively, and passionate about what they did. We had a great discussion. The people in the audience though... they didn't really care what was going on. I get the impression that half of them were just there for CPE credits, and the other half were government employees looking for a paid vacation. The fact that these people are tasked with securing data in both the government and corporate worlds scares the crap out of me.

There were a few people there who were willing to ask questions and actively participate in the discussion, but they were the exceptions. I don't understand how a person can work in security and not be extremely passionate about his job. We do very cool work here and we work with very interesting people. Having spent time in a lot of other industries, I can honestly say that I've never worked with a better group of people. What's more, if you aren't passionate about it, there is no way you can keep up. The security world changes daily, and while we joke about our addictions to our smartphones, email, and twitter, if you take a few days off, you really will get left behind. It takes serious commitment just to keep up, but it's totally worth it.

If you're one of those people who just doesn't care, get out of this industry. There's got to be a better use for your time. If you do want to stick around, find a project to work on, something to get involved in, or at least start a blog with random thoughts. Even if you're wrong, ridiculed, and flamed, it's helpful to you, the community, and everybody else.

Maybe I'm an idealist, but I just want to see other people get as excited as I am.

Browser Security Tools: RequestPolicy

2009-10-02T15:20:00.000-07:00

Note: I originally posted this piece on my employer's blog. I'm shamelessly cross-posting it because this is a really cool extension, and I want lots of people to check it out.

I spoke about CSRF attacks at Defcon a few months ago, and while I was there, I had the opportunity to meet with Justin Samuel, the creator of RequestPolicy. RequestPolicy is a Firefox extension designed to provide CSRF protection and enforce web application boundaries. I love it.

Request Policy completely breaks the web... in all the right ways. You'll initially hate using it. StumbleUpon links will no longer work, due to their use of cross-site iframes. Shortened bit.ly and tinyurl links will present you with an intermediate page instead of following 302 redirects. Deeplinked images on blogs, social networking sites, and other pages won't show up. You will have to manually approve off-domain requests on a case-by-case basis. It's not convenient, but it's a lot safer than letting your browser blindly request resources.

In short, RequestPolicy gives you granular control over your browser. If you know what you're doing, this is a good thing. If you're a normal user, you'll probably find yourself checking the "Temporarily Allow All Requests" box or disabling the extension completely. I can't say I'd blame you, but try not to. The extension is still very young in its development process, and most of the issues that I've run into are UI/usability problems. The developer is aware of many of these issues and working to fix them, but it's not easy. Samuel is very open to suggestions, feedback, and criticism, so if you have useful input, I'm sure he'd be happy to hear it- just hit the contact link on the extension's website.

The UI is heavily modeled after NoScript, so if you're a fan of that extension (and you should be), it isn't too difficult to figure out. Off-domain requests are disabled by default, and can be enabled on a per-site, as-needed basis. The preferences pane is simple and fairly easy to understand, allowing you to more easily manage your whitelist of allowed domains. Additionally, the extension ships with a setup wizard to create generic whitelists based on common sites (recaptcha, for example, has to be whitelisted for every domain that uses it). All in all, it's pretty easy to set up, and though it will break a lot of sites at first, as you fine tune the settings to your browsing habits, it really doesn't get in the way too much.

RequestPolicy was created for a very specific purpose: to give users the ability to better control their browsers and prevent CSRF. It's a bit rough at the moment, but it's very good at it.

Inside the LiveJournal Worm

2009-09-25T07:12:00.000-07:00

On Wednesday morning, LiveJournal was hit by a Flash worm. It was brought to my attention by Dan Goodin over at the Register, and I discussed it briefly with him as he wrote an article about it. Because I've been looking at Flash in depth lately (more on that coming soon), I decided to take a deeper look at the attack. I was able to track down the HTML side of the malware, but couldn't find a copy of the malicious SWF. An email to the LiveJournal staff fixed that, and they were kind enough to also include their own analysis of the attack. Their earlier post generally covers it, but I'll go into a bit more detail here.

It's really a fairly simple worm. As noted by the LiveJournal staff, the payload did much less than it could have.

The real source of the vulnerability was an overly permissive crossdomain.xml file on www.livejournal.com. This is a well-known, but surprisingly common issue- Jeremiah Grossman came up with some basic statistics for this issue in May of 2008- Some 18% of websites (from a very limited, but high-value set of sites) have crossdomain policies that I would consider "permissive." Coincidentally, I have more research on that coming up soon, but for the moment, I'll just say that only a year and a half later, the numbers are considerably worse.

At any rate, LiveJournal's crossdomain policy allowed Flash objects from their lj-toys.com sandbox domain more access than it should have, and allowed this worm to perform requests across domains. From there, it is pretty simple- embed malicious objects in a post, and have those objects make requests to www.livejournal.com, propogating to the profile of any user that views them. The exact steps that the worm takes are as follows:

Perform a blind request to bit.ly (more on this in a moment)
Check whether a user is logged in by requesting and parsing http://www.livejournal.com/manage/profile/
Extract username and email address from that page
Extract last post ID from http://www.livejournal.com/editjournal.bml
Request the contents of that last post
Check whether the post is already infected
Perform another blind request to bit.ly
Infect the post, appending the SWF payload to the body
Perform requests to one of three outside servers (chosen at random), submitting the following as GET variables: username, email address, and the data from the last post

The requests to bit.ly are interesting. Each time the malware is run, it sends a request to bit.ly. Just before infecting another account, it sends a request to another bit.ly link. The results of these requests are discarded, so I believe that they are only made to provide tracking data for the malware author via bit.ly's "info" page for each link. Based on the information from those pages, I estimate that the payloads were executed 9,700 times, and around 3,300 accounts were infected (accounting for a handful of "false clicks" from myself, the malware author, and others). The data on the bit.ly page doesn't provide enough granularity to generate a useful profile of the attack's timing, so I've contacted bit.ly staff to see what further information can be provided. While they are being helpful, I'm not sure I'll be able to get much useful data (I sure wouldn't give it to me).

What lessons can we learn from this? For a user, Flash can be dangerous. It should be disabled by default. Is this news? No. But this is a very clear sign that the attackers know it as well, and it is being exploited. We, on the good guys' side, should be paying attention. For the administrators of a website, there are a few lessons. First, the crossdomain.xml policy is a major failure point, and many sites are vulnerable. Know when you are allowing access. Second, embeddable content can be dangerous. While LiveJournal's system for embedding content is actually quite good, there are really too many things that can be done with active content like Flash to allow it without seriously considering the consequences.

On the plus side, a few things were really done right. Within minutes of receiving reports of strange account activity, LiveJournal staff determined that active content was the culprit and disabled it throughout the site. A crude whitelist of trusted sources (such as YouTube) were enabled soon thereafter, and within a few hours, the faulty crossdomain.xml file was found and fixed.

That fast of a reaction is really impressive, and the corrective measures were pretty much spot on. What's more, LiveJournal decided to be transparent about the whole issue, releasing informative alerts to their users and working with them to fix compromised accounts. Tupshin Harper, director of Engineering and Operations, was particularly helpful to me in analyzing the attack and providing useful data. My hat is off to them- if more people reacted to breaches this way, the web security community would be in a lot better position to deal with attacks.

A few questions are still left unanswered- primarily about the attacker and his motives. The data that was logged by the malware really wasn't particularly sensitive- an email address and a username, basically. I suppose it could be useful for future phishing and spamming attacks, but given the wealth of other presumably-useful information available in a LiveJournal profile, I'm not sure that this was the goal. The code in the SWF isn't particularly refined, so I think that "Proof of Concept" is the most likely explanation. It's also worth noting that the SWF's code is in English, and while psychological profiling isn't really my strong suit, I get the impression this was intended to be neither subtle nor malicious. The servers that received user data to were all cPanel mass-hosting servers, running vulnerable instances of phpBB, Joomla, and other commonly-attacked software. One of the servers is located in Washington, one in Hungary, and one in the Ukraine. I've requested information from those hosting companies, but don't really expect a response. It is also interesting that the "logging" scripts do not actually exist on any of those servers (nor could they, being ASP scripts and the servers running PHP), but the data is sent as GET variables. If the attacker intended to retrieve that data, he would need to compromise either the FTP account or the cPanel account in question to get it from the access logs- a reasonable assumption, but not (by me at least) a provable one.

I'll leave it as an exercise to LiveJournal, bit.ly, and the hosting companies involved to locate the "patient zero" LiveJournal account and, presumably, the attacker. I have no doubt that the data required to locate him is there, but getting it all into one place will probably prove tricky.

Making a Change

2009-08-13T14:54:00.000-07:00

I officially parted ways with my company today. I have serious appreciation for the opportunities and education I've gained through working with their developers, clients, and systems, but I've come to a point where I have made huge improvements there, and want to work on other things. I feel like, at this stage, my skills will be better put to use elsewhere, and it is time for me to move on.

I've been asked to join the team at Foreground Security. While I'm a natural skeptic, I am very excited about this opportunity. I'll be working with a very different set of applications, developers, and clients. The people over there have been great so far, and appear to be quite supportive of my continuing research in the WebAppSec field. I'm looking forward to some seriously cool stuff, and I couldn't be happier about the situation.

With this change, I'll also let you know there will be a shift in the material that I post here. Black Hat and Defcon had some really eye-opening moments about the state of the security community, what we're doing right, and the many things we're doing wrong. I still need to take some time to process all of the ideas that came out of the conferences, but suffice it to say, I'll be approaching future research very differently.

Finally, I want to throw out a thank you to all the people who have helped me out behind the scenes over the last few months on the job change, research, and a variety of other issues- I won't name names for fear of leaving somebody out (or publicizing somebody that doesn't want it), but you all know who you are, and I'm extremely appreciative. Even the opportunities that didn't work out resulted in me meeting bright people and having incredible discussions- things that I would love to one day follow up on.

The security community really is one of the greatest groups of people on the planet. Thank you all for being here.

PHP Casting Errors in Wordpress

2009-08-11T10:02:00.000-07:00

Did you see the Wordpress vulnerability that was published last night?

While Wordpress vulns aren't really news, this one was fascinating. All it does is allow an attacker to reset the adminsitrator's password- locking him out of the account. Annoying, but not fatal. I'm interested in the vuln itself, as it stems from PHP's flexible casting. In particular, the following lines of code (paraphrased for context and clarity):

$key = preg_replace('/[^a-z0-9]/i', '', $_GET['key']);

if ( empty( $key ) ){
   return new WP_Error('invalid_key', __('Invalid key'));
}

$user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s", $key));

This code can be exploited by passing the vulnerable script an empty array rather than a string for $_GET['key']. You can pass an array in a query string using the [] syntax:

wp-login.php?action=rp&key[]=

Go back and step through the vulnerable code again. The value of $_GET['key'] would look like this in PHP form:

$_GET['key'][0]='';

The array is handed to preg_replace, which, when given an array to work with, will perform the regex substitution on each element of the array, then return that array. Again, this array contains one element, an empty string, so when it hits the "if(empty($key))" line, it returns false (as the array is not empty). This, in turn, is important because the wpdb->prepare() statement receives an array when it is expecting a string, flattens that array out, and gives you the following query:

SELECT * FROM `users` WHERE user_activation_key = ''

Since the admin user is the first row in the database, and his activation key is blank (assuming nobody has performed a password reset on the account yet), that user is returned, and his password is changed.

That probably wasn't the best explanation, but if you're still with me, that brings us to the question of "what did they do wrong?" The first problem was assuming that $_GET['key'] was a string. While the programmer checked that string for malicious characters (in the preg_replace), he didn't check the type of the variable. Flexible casting of variables is common in PHP apps, but as this example demonstrates, this can be dangerous. As part of your input validation process, you should be either checking or forcibly casting the type of that input. I suspect that the programmer thought he was forcibly casting the input with preg_replace(), but was not aware of how it handles arrays.

Here is the official fix:

if ( empty( $key ) || ( is_array( $key )){
   return new WP_Error('invalid_key', __('Invalid key'));
}

Can you see the problem here? This is a classic bad approach to fixing security bugs- patching the exploit, not the vulnerability. Instead of checking whether the input is what you expect (is_string), they are making sure that it isn't what they don't expect (is_array). While this does fix the issue, it is a blacklist approach, not the whitelist approach that would be recommended. What will happen if an attacker figures out how to pass another data type to this function? It may break, it may not. Either way, it's not very fault-tolerant coding.

The reason I'm bringing it up is that this is an excellent case study of an underappreciated programming bug. As useful as PHP's loose casting and overloaded functions can be, you still need to validate your inputs and explicitly verify that they are what you expected.

Thanks to Rafal Los for making me look at this, and working through the mess that is the Wordpress codebase with me.

TweetMyPC: What I've learned From Your Screenshots

2009-07-09T20:33:00.000-07:00

I've been watching the Twitter traffic pertaining to TweetMyPC. So far, I've amassed a decent collection of users' screenshots, all of which reveal private data.

First off, I have already confirmed my previous statement:

Your Twitter feed is public. Even if you make it private, recent incidents with Twitter should be enough to make you consider it public.

When TweetMyPC posts a screenshot, it uses Twitpic to do so. Though the TweetMyPC documentation encourages users to make the "command" Twitter accounts private, it makes no mention of TwitPic, which is a completely different service, and does not reflect Twitter's privacy settings. This being the case, locating command Twitter accounts (even the private ones) is a simple matter of searching through Twitpic's archives for the string "TweetMyPC -> Screenshot".

While Twitpic doesn't have a search feature (they've been promising one for some time), they do have a public feed, and there are third party (fourth party, I suppose) sites that allow you to do just that.

The next thing I learned is also a TwitPic issue (a bug, perhaps). You won't see this one on the Month of Twitter Bugs, but it turns out that deleted photos on TwitPic aren't actually deleted. An example: TwitPic claims that the image with the ID 9s4gx no longer exists. However, if you go directly to the full-sized image, you'll see that you can download the image- a screenshot of that user's Windows registry.

It's worth noting that this user has indeed protected his updates on Twitter... not that it did a lot of good.

Now let's get to the screenshots themselves.

Even the tiniest bit of information can be extremely useful to an attacker. It all depends on his motivation, his expertise, and how much free time he has. As none of this is predictable, I recommend that you use extreme caution in posting screenshots online.

This screenshot displays the contents of the user's Gmail account, his Gmail address, and the IP address that he is logged into Gmail from. From his bookmarks toolbar, we can guess what websites he visits regularly, and from the browser's status bar, we know that he is using Greasemonkey. From the Windows XP taskbar, we can see what software he is currently running, including antivirus and instant messaging. We know that he's not using NoScript, and that he appears to be a relatively savvy computer user.

I think we've got enough info to own this computer. Let's move on.

This guy is clearly logged into his investment management portal. Combining the info in this screenshot with some of the other information revealed in that user's Twitter account, and noting that there's an XSS hole on the investment site, I'm betting I could XSS him out of his stock portfolio.

Want more? You just have to look.

Desktop shortcuts, NoScript settings, browser history, Yahoo mailboxes, network and firewall settings, not to mention everyday activity, from piracy to IM conversations to grocery lists, are all freely available.

RIP Milw0rm (or not)

2009-07-08T07:56:00.000-07:00

Sadly, Milw0rm.com is going offline- permanently, from the sound of it. Str0ke posted the following message on the site before it went dark:

Well, this is my goodbye header for milw0rm. I wish I had the time I did in the past to post exploits, I just don't :(. For the past 3 months I have actually done a pretty crappy job of getting peoples work out fast enough to be proud of, 0 to 72 hours (taking off weekends) isn't fair to the authors on this site. I appreciate and thank everyone for their support in the past. Be safe, /str0ke

While it gets a bad rap for its large script kiddie user base, I've learned a lot from the exploits on that site, and it will be missed. Thanks Str0ke.

If anybody has info about where I can get a copy of the milw0rm archives, I'd be happy to mirror it here.

Update 7/8/2009 2:47 PM: While Str0ke isn't going to be running things, it looks like he found some other people to take over for him. Exploit submissions are still closed for now, and milw0rm.com is still offline, though that may just be server overloading.

Today's Bad Idea: TweetMyPC

2009-07-06T12:21:00.000-07:00

Some people just don't think.

TweetMyPC is an application you can install on your PC. It will read your Twitter feed and execute commands based on your tweets. How did somebody get all the way through writing this app without considering what a supremely poor idea it is? A few problems:

Your Twitter feed is public. Even if you make it private, recent incidents with Twitter should be enough to make you consider it public.

Do you really want the whole world to be able to view all your screenshots?

The entire security model of this app (if it could be considered such) relies on the idea that only you can post things to your Twitter account. Aviv Raff and his month of Twitter bugs are proving this wrong every day.

What is wrong with people? I know I'm a security guy, but seriously, think before you install remote access software for your PC. From the looks of the chatter, a lot of people are using this app already.

Remote desktop works fine, and there's no reason to use Twitter as your carrier. Twitter is not a network protocol. It's not even a great social networking app.

Edit: I'm collecting screenshots of personal information or other sensitive data here. I'll probably write a bot to do this for me soon enough

Parsing Quirk Causes bit.ly XSS

2009-06-24T07:56:00.000-07:00

Fun fact: When your browser parses a document, it locates <script> and </script> tags before evaluating the javascript within. While this appears to make sense, it creates an interesting quirk- injected </script> tags, even within quoted javascript strings, will force it to end a block of javascript code and throw a parse error. It will also allow you to start a new block of unquoted (and therefore, executed) code.

I put together a basic demonstration of this quirk a while ago and bounced it off a few people. As it turns out, this is known behavior, and was even used in one of the first examples on RSnake's XSS Cheat Sheet.

Arguably, this is not really even a bug. It stems from the order in which the document is parsed- structure (tags) is handled before parsing javascript content. I looked into the various standards that apply and didn't see anything dictating how this behavior should be handled, but I confess I didn't look that hard.

At any rate, the reason I'm writing about it today is because I found an XSS hole in the popular URL shortener, bit.ly. This can be used to compromise browsing history, tamper with a user's bit.ly settings, and even abuse Twitter accounts (they have a Twitter API).

Due to the nature of the exploit the link only works once, so I can't send you directly there. However, if you take the following URL and make "CHANGEME" a unique string, it should work.

http://bit.ly/?url=http%3A%2F%2Fskeptikal.org&keyword=%22%3C/script%3E%3Cscript%3Ealert(1337)%3C/script%3ECHANGEME

While it's generally known that putting user-supplied input into executable code is a bad idea, many developers still do it, especially with javascript. Don't assume that just because the input is wrapped in quotes, it will not be XSS-able.

Watch Out For Suspicius Links

2009-06-15T11:45:00.000-07:00

As part of our recent research on CSRF attacks, Russ McRee found a vulnerability in the Linksys WRT160N router. Sadly, this wasn't a huge shock to us, but what was surprising was the response from Linksys:

We can’t reasonably prevent CSRF's without bogging down our code. The compromise we had made here is to have a timeout on the web interface, so users are logged out after 10 mins of inactivity. We have also advised users to not click on suspicious links while logged in to the web interface, or close the web interface as soon as they are finished configuring the router

As ridiculous as the entire response is, I'd like to focus on the "Don't click suspicious links" bit. Most users will click on any link you throw at them, particularly from link-heavy social sites such as Twitter. In fact, if you clicked through to this page from my Twitter post, the page you're currently on should be at "http://skeptikal.org/a_very_suspicious_link."

Why did you click it?

Because you trust me. And you trust Twitter. And you trust my hosting company. And your DNS servers. And my DNS servers. And TinyURL.

I could rant on this topic for a while, but I know I'd be preaching to the choir. Don't trust any links, anywhere. Especially don't trust the ones from TinyURL, bit.ly, or any other URL shortening service. You have no way of knowing whether a site is malicious or not until you load it into your browser. Even then, it's doubtful that you'd ever notice. You're probably not a normal user, but most people wouldn't ever recognize real malware for what it is, especially if it's properly obfuscated.

In theory, a goal of never clicking a malicious link is impossible to achieve. In practice though, many malicious links are fairly easy to recognize if you just look at the URL. This is why sites like TinyURL allow you to preview links before being redirected to them. Earlier today, @OWASP_podcast sent out the following tweet:

http://tinyurl.com/preview.php?enable=1 will force all TinyURLs to appear in preview mode on your machine.

It's a good idea, but this is clearly a URL that modifies user preferences based on GET variables, and I couldn't help noticing that the same preference could be disabled with a bit of CSRF:

<img src="http://tinyurl.com/preview.php?disable=1">

I'd call this a failure on TinyURL's part, but even if you did preview the URL, there's no guarantee the seemingly innocent link won't have malicious content, redirects, cross-site scripting, HTML injection holes, poorly configured DNS, poorly coded flash files, content ownership problems, compromised FTP accounts or other issues.

Just keep that in mind- previewing a link is a convenience, not a security feature.

GuestCentric Systems- Not Really That Secure.

2009-06-11T10:22:00.000-07:00

I ran across a press release from GuestCentric Systems dated April 20, in which they announced their partnership with McAfee to put the McAfee Secure logo on all their client's pages.

GuestCentric offers a booking management service to independent hotels, and from the looks of things, it's actually a pretty cool app. They appear to be awfully proud of that system, and the fact that it was certified as secure. Now we all know that the McAfee Secure certificaton has serious deficiencies, but that horse doesn't appear to be dead yet, so I'll keep flogging.

The video on GuestCentric's press release essentially mimics the hype from McAfee- put the logo on your website, watch your sales jump 14%. It says nothing about the actual state of security in the app, and is purely marketing fluff. This always irritates me, but it doesn't surprise me. Of course, it also should come as no surprise that GuestCentric has XSS holes on their website, or that the booking application itself contains XSS holes as well. It also has CSRF holes and more.

What is interesting to me in this instance is that the GuestCentric app is almost completely AJAX. While McAfee secure is terrible at finding XSS and CSRF holes in the first place, it certainly does not parse AJAX and does not intelligently fuzz for these vulnerabilities. Short of detecting out of date software on the server, scanning this application with McAfee Secure is particularly useless.

The really amazing thing to me is that McAfee values their brand so little. Their name and logo are put on so many websites that they have so little to do with, nobody actually trusts (or in most cases, even sees) their certification.

McAfee keeps citing their 14% number. While I have doubts about the validity of that study (and real data has never been released), I have to wonder whether those numbers would be the same today. Something tells me that the answer is a resounding "no."