Skeptikal.org http://skeptikal.org/index.php Copyright 2009, Mike Bailey (mckt) Mike Bailey (mckt) en-US SPHPBLOG 0.5.1 Qwest XSS http://skeptikal.org/index.php?entry=entry081230-113011
Due to the location of my residence and the ineptness of my HOA, the buildings around me get fiber optic, but I can't. So I use Qwest DSL for my home internet access. While I'm not a huge fan of the company, they generally tend to get things done and not cause me too much grief. There's a lot I don't like, but not enough to quit using their service.

About a year ago, I was paying my bills and visited the "My Profile" page. Out of curiosity, I stuck a few quotes and HTML tags into a few fields and much to my surprise (not really), found some permanent XSS holes. While I don't like seeing it, this alone isn't really news (as evidenced by the recent string of holes we've been finding on bank and credit company websites). I left one field set to pop up an alert box every time I log in and mostly forgot about it.



A few months later there was an internet outage. The Tech Support call was a whole 'nother adventure (what "scheduled router maintenance" results in a 30+ hour outage? There's something they weren't telling me), but the interesting part was when the rep brought up my account information. She sounded confused on the phone, said something like "what's this? This is weird..." and after a few loud clicks, seemed to get back on track and finish the call. It wasn't until after I hung up that I realized what had happened- my XSS has executed in the context of a Tech Support rep, who presumably has access to other accounts, network information, and other goodies...

I never did anything with it, but did mention it to a few of Qwest's IT people I met a few months later. They didn't seem too concerned. I then looked through the Qwest website a bit more and found a few more XSS holes- these ones in the public side. I reported them, posted them on XSSed, and forgot about them. They never did get fixed.

While finding security holes in the financial sector seems to be all the rage these days, I'm going to focus for the next while on some public utilities. Frankly, they scare me more- they're often government owned and operated, so have less market-driven controls in place. Most of them know your Social Security number, your credit card number, your checking account information, and they directly affect your everyday life.

Wouldn't it be scary if your power company used outdated perl scripts to handle billing and account management? Mine does.
]]> http://skeptikal.org/index.php?entry=entry081230-113011 Mike Bailey (mckt) Tue, 30 Dec 2008 18:30:11 GMT http://skeptikal.org/comments.php?y=08&m=12&entry=entry081230-113011 Reporting Security Holes http://skeptikal.org/index.php?entry=entry081223-213811 latest blog post came links to a few articles dealing with the recently exposed American Express XSS holes. In short, AmEx dealt with it badly- ignoring Russ's three attempts to contact them and only fixing the issue when it got posted publicly (after their PR watchdogs brought the post to their attention).

One of the more interesting articles was at BetaNews. Please read it.

I don't think that AmEx's web developers read my blog (at least I haven't seen many related IPs pop up in my logs), but maybe they should. Their primary excuse for not fixing the flaw is that it didn't get to the right people.

Now, exactly whose fault is that?

I wrote a few months ago, in my "Open Letter to The Internet" that website owners need to make it painless to report security issues. If they don't provide a simple process for doing so, I have a hard time feeling sorry for them. Russ's goal was to get the bug fixed, and contacting the company didn't do it. Once he posted it publicly, people actually started caring. (Unfortunately, the fix only lasted a day before getting broken by two more researchers, which makes me think that AmEx's programmers are inept to begin with).

Russ made a good-faith attempt to contact the company not one, but three times. He sent messages to two different entities and gave them two weeks to respond. If it had been me reporting the bugs, I certainly wouldn't have given them that much effort unless I was on their payroll.

As I wrote back in August, "We are here to help, but we aren't necessarily here to help you."

]]> http://skeptikal.org/index.php?entry=entry081223-213811 Mike Bailey (mckt) Wed, 24 Dec 2008 04:38:11 GMT http://skeptikal.org/comments.php?y=08&m=12&entry=entry081223-213811 cPanel Followup http://skeptikal.org/index.php?entry=entry081219-104210
You may be wondering why, with its massively widespread use, cPanel wasn't already PCI compliant. Basically it dealt with a variety of SSL issues- the administration interface supported weak SSL ciphers and there was no way to change that through cPanel. You had to hack it together, disabling cPanel's internal SSL libraries and using other tools to implement it properly.

While I'm happy that they got around to fixing that issue (after only about 4 months), they still haven't fixed the XSS or CSRF issues that I sent to them in June and posted here back in August.

...But I'm getting awfully jaded, and I'm not expecting them to ever fix it.]]> http://skeptikal.org/index.php?entry=entry081219-104210 Mike Bailey (mckt) Fri, 19 Dec 2008 17:42:10 GMT http://skeptikal.org/comments.php?y=08&m=12&entry=entry081219-104210 Redirecting Safely http://skeptikal.org/index.php?entry=entry081203-105048
In many PHP applications, there is an admin side and a public side. It is common for developers to have an "admin check" in the code header of the admin side, which essentially evaluates whether a user is authorised to view a resource and either redirects them to the login page, the public page, or lets them through to the resource.

What many developers don't realize is that a browser doesn't have to terminate a connection as soon as it receives a 302 redirect. If you are relying on the following call to keep the riffraff out of your admin pages, you may be vulnerable:

header('Location: login.php');

I can't tell you how many times I've been able to access reports full of user logins, order information, or even account modification functionality, simply by asking my browser to continue loading a page after receiving a redirect. If you need a testing tool to see if you are vulnerable, I whipped up this perl script one day to allow me to simply snag admin pages or post content to them during a penetration test.

In case it isn't obvious, you can prevent this hole simply by halting the flow of the application. If you aren't using more advanced templating and flow control (which I'd recommend anyways), this will work:

header('Location: login.php');
die('Kindly piss off.');

While obvious, this issue is incredibly widespread, and I have to wonder how many developers are unaware of it.
]]> http://skeptikal.org/index.php?entry=entry081203-105048 Mike Bailey (mckt) Wed, 03 Dec 2008 17:50:48 GMT http://skeptikal.org/comments.php?y=08&m=12&entry=entry081203-105048 PHP's Most Useless Security Bug http://skeptikal.org/index.php?entry=entry081021-101639
With display_errors on, PHP will send errors to the browser, along with the location of the buggy code. This is often useful for debugging, and helpful to malicious users. Interestingly, it doesn't filter the filename for HTML characters.

If you were able to, say, create a folder named "<script>alert(1337)<", and within it, place a file called "script>.php", which in turn threw an error, you'd get something like this.]]> http://skeptikal.org/index.php?entry=entry081021-101639 Mike Bailey (mckt) Tue, 21 Oct 2008 16:16:39 GMT http://skeptikal.org/comments.php?y=08&m=10&entry=entry081021-101639 More McAfee Snake Oil http://skeptikal.org/index.php?entry=entry081009-213000 The McAfee Secure certification is useless.

Over at holisticinfosec.org, Russ McRee has been covering this in depth, but I've had the fortune to know the inside story.

Russ has been making snake oil vendors' deficiencies public for some time. A few weeks before Black Hat, he and I were talking about this, and he showed me a handful of "McAfee Secure" sites. All of them had XSS holes, and many had much worse- SQL injection and other serious issues. Over the next few weeks, we traded more vulnerabilities as we found them, and he amassed a pretty impressive list of weak, but certified secure sites. To top all of this off, we found XSS holes on McAfee's own domain.

We also got our hands on a PCAP dump of one of their scans, which revealed quite a bit of insight into the scanning process. We were able to prove that they do not revoke PCI compliance or McAfee Secure certifications for XSS, though the engine does indeed fuzz for (and occasionally even find) them.

While they were being awarded their Pwnie, Russ put together a paper detailing these findings. He sent the paper to McAfee before publishing, in order to give them a chance to address the issues before they were made public. They surprised us both by responding positively. Some of McAfee's top people spoke with Russ in person a few weeks later, resulting in him publishing this blog post.

That was some time ago, but we still haven't seen any progress. A published standard for what exactly "McAfee Secure" means was promised after 2-3 weeks, and we're now pushing five. The information that we have isn't encouraging- it appears that McAfee Secure will have a different set of standards for enterprise websites and the smaller "Ma and Pa" shops. The latter will not be required to fix XSS issues and the former will not have to do so until an arbitrary time period has expired. What this means is that, to a user looking for evidence that a site can be trusted, the "McAfee Secure" badge on a website will mean exactly what it does now: Absolutely nothing.

I suppose that anybody can offer their own meaningless certifications (and some people have), but as Rafal noted yesterday, calling these sites "McAfee Secure", "Hacker Safe" or anything of the sort is in poor taste at best- fraudulent on the other end of the spectrum.

This brings us to today.

It appears that McAfee intendes to leverage their brand recognition and captalize on the trust of the ill-informed. They have a new service advertised on parts of their website. Found at secureshopping.mcafee.com, it is basically a meta-search engine which will allow one to "shop with confidence at McAfee SECURE certified merchants", according to the text on the site. This actually doesn't strike me as a bad idea, provided the certification is worth something. Considering the certification isn't, the whole thing is rather laughable.

I first stumbled across this site just before Black Hat. The app was probably not intended to be public then, but I immediately (accidentally, actually) discovered an XSS hole in it (this was one of the holes on McAfee's domain mentioned above). While that hole has since been fixed, the situation really isn't any better now.

To begin with, the application doesn't use transport-layer encryption, and is therefore vulnerable to sniffing, tampering, and all the man-in-the-middle attacks that we already know and love. But who bothers with SSL these days?

The shopping application itself seems to be based on the same code as that of become.com. Actually, they appear to have partnered for this service, because when you click a link from McAfee's site to a particular product, you are given a 302 redirect to partner.become.com, then to stat.dealtime.com (whoever that is). From there you are 302-ed anywhere from one to three more times before landing on the requested product page, provided by a McAfee Secure merchant.

In theory, at least.

For the sake of breaking things, let's build a link that will take us through the McAfee Secure gateway to an uncertified website. We'll go to www.become.com, find a product, then deconstruct the link and pass its unique identifier to McAfee shopping center (which, being based on the same code, uses the same format for its links). Lo and behold, the following link will take you directly to the product on Amazon.com- which according to McAfee Secure, is not McAfee Secure.

Next, let's take a look at the app's session ID generation. Admittedly, sessions don't appear to be used for anything in the site (except maybe tracking user activity), but I have to assume that session functionality was added for some reason, and it nicely demonstrates their own lack of understanding of web application security. Can you find the pattern?
1223516988361-0-9IDB
1223516989602-0-gnpY
1223516990254-0-SZPR
1223516990913-0-F9jC

That's right folks, they're using timestamps as session IDs. Now, I've seen this practice used by banks, mortgage companies, and ecommerce sites, but I never expected to see such poor practices on the website of the "world's largest dedicated security technology company" (their boast, not mine).

Finally let's look at the partners, who we have to assume will help provides us "a secure online shopping experience with thousands of McAfee SECURE sites". The sites at become.com and dealtime.com are themselves riddled with XSS and open redirect holes (not to mention storing the answer to a CAPTCHA within the form to be submitted).

With such poor decisions being made, can we really expect McAfee Secure to live up to its name?]]> http://skeptikal.org/index.php?entry=entry081009-213000 Mike Bailey (mckt) Fri, 10 Oct 2008 03:30:00 GMT http://skeptikal.org/comments.php?y=08&m=10&entry=entry081009-213000 Clickjacking Exploits http://skeptikal.org/index.php?entry=entry081007-195714 clickjacking exploits, and I have to say, I'm a bit disappointed.

Basically, the attack boils down to using Javascript, Flash, or CSS to surreptitiously place links or other controls under the user's cursor right before he clicks. A clever attack, but I was expecting something new. I've been doing this for years, and Rsnake mentioned something like it back in 2006. He even noted that some of these attacks have been around since 2002. It still hasn't been fixed, but this isn't exactly news.

The "news" part which sparked some drama is that Flash is particularly vulnerable, and can be used to access client-side devices like microphones and cameras. Considering Flash's past record, even earning a Pwnie nomination, it's not all that shocking. Due to RSnake's holding off on releasing the vulnerability, this bug has already been resolved by the vendor.

I suppose due to Flash's huge market penetration, this is somewhat noteworthy, but none of the users seem to care.

Call me cynical, I guess.

That's why I just use Lynx.]]> http://skeptikal.org/index.php?entry=entry081007-195714 Mike Bailey (mckt) Wed, 08 Oct 2008 01:57:14 GMT http://skeptikal.org/comments.php?y=08&m=10&entry=entry081007-195714 Diary of a Hacker - Part 1 http://skeptikal.org/index.php?entry=entry081006-152832
The site is a file repository- basically customers can pay a monthly fee to have access to a virtual filing cabinet-type-thing. I don't think that's a fabulous business model, but that's not the point of this blog. After familiarizing myself with the site, my first attempts were file upload attacks (naturally, given the purpose of the site). Fortunately, the site used several layers of protection for uploaded files- first, it only allowed a whitelist of filetypes, preventing malicious files from being uploaded. Next, it stored those files in a non-web-accessible directory. Even if I could get a malicious file uploaded, I could not access it directly. Finally, the filenames were randomly generated- if I found a way to circumvent the access control, I still would not know the name of my malicious file.

Basically, this type of attack didn't work; I moved on.

Throughout the site, inputs were validated thoroughly (excessively in some cases). No matter where I looked and how much I mangled the inputs, I could not find an SQL injection hole. I did find a reflected XSS hole in an obscure stock script, so I decided to work with that. My goal was to
steal an admin session using Javascript, and after setting up my evil little javascript-session-stealing kit (I'm quite proud of it), found out that this also wouldn't work so easily. The developer had added the following directive to php.ini:
session.cookie_httponly = 1
This directive made it so that session IDs were inaccessible to client-side Javascript. I could have still used the XSS hole for other things, such as forcing the administrator to perform actions on my behalf, but this would require work and inside knowledge to code, and would have a relatively low chance of success.

I'm rather lazy, so I moved on.

I went to myipneighbors.com and found a list of sites on the server. It didn't take me long to find one with some known vulnerabilities, and next thing I knew, I had filesystem access. Faithful readers already know where I'm going with this, but mass-hosted servers are a Bad Idea. Even so, it is possible to configure file permissions and code a site so that an attacker can't simply walk in and read your configuration files.

I whipped up a quick script and ran it on the compromised account (The server runs FreeBSD and cPanel). This script monitored the output of `ps -aux` while fetching a page from the target account. Because of suexec, I immediately knew the username of the targeted website.

With this information, I tried to read files from the public_html directory, but the permissions were set up (mostly) correctly and prevented access. While I couldn't list the files in the directory, I could guess at their filenames, and eventually landed on one file that was readable- php.ini.

Reviewing the site's php.ini file, I could tell the server was relatively locked down, but one line in particular caught my attention:
session.save_path = /home/theSiteUsername/tmp/
I tried to list the files in that directory and was able to view a list of open sessions' IDs. This was the hole I needed to compromise the account:
$ ls -la /home/theSiteUsername/tmp/ | grep sess
-rw-------   1 theSiteUsername  theSiteUsername  5068 Sep 18 09:20 sess_1a1aexxxxxxx5e282e1a5747694ec8e2
-rw-------   1 theSiteUsername  theSiteUsername  5023 Sep 18 09:19 sess_462fexxxxxxx13dafa331bc15e962e22
-rw-------   1 theSiteUsername  theSiteUsername  5109 Sep 18 10:51 sess_717edxxxxxxx653df341f91d096e0484
-rw-------   1 theSiteUsername  theSiteUsername  5079 Sep 18 09:14 sess_91850xxxxxxxef480524c23412b23dc1
-rw-------   1 theSiteUsername  theSiteUsername  5011 Sep 18 10:38 sess_9246dxxxxxxxe6e710a9e623af23ca95
-rw-------   1 theSiteUsername  theSiteUsername  5079 Sep 18 09:25 sess_a4cdcxxxxxxx065ede6ecb062d443f86
I then manually set the SESSID cookie in my browser to those found in the session filenames, and confirmed that I could hijack other accounts' sessions. Unfortunately, none of those sessions were administrators. I wrote a shell script to watch the directory in question and send a text message to my cell phone when a new session is created, but no admins logged in over the 50-something
hours that I waited.

While this tactic would eventually work, I wanted to speed things up. I sent the following email to the programmer:
Log into the admin section and check the 'edit_users.php' page.

;)
The developer and I have done a fair amount of trash-talking about this account in the past, so worried that I had successfully hacked the site, he logged in to check the admin section. As soon as his new session was created, I hijacked it, accessed the admin page, and snagged a screenshot as proof.

So what could have been done to prevent this attack? A few little things.

First, making the ~/tmp directory globally unreadable would have prevented me finding session IDs. This isn't failproof, as there are other ways I could have found them, but every little bit helps.

Second, adding further session validation would have made hijacking the session very difficult. This can be as simple as storing the source IP address in the $_SESSION array on login, then comparing it on each pageload to make sure the user isn't suddenly coming from the other side of the world. Admittedly, there are legitimate uses that would have issues (web proxies and Tor, specifically), but it would have closed the hole. If the site's user base are likely to be behind proxies, there is other information that can be used to identify the browser uniquely- client's user agent, supported protocols, OS, connection latency, etc.

The biggest lesson here, though, is to follow the 'defense in depth' mantra.]]> http://skeptikal.org/index.php?entry=entry081006-152832 Mike Bailey (mckt) Mon, 06 Oct 2008 21:28:32 GMT http://skeptikal.org/comments.php?y=08&m=10&entry=entry081006-152832 A Hacker's Diary http://skeptikal.org/index.php?entry=entry080918-143113
So far, I have not failed, and the prize keeps getting bigger.

Of course, it isn't really a code audit or even a penetration test. Primarily, it's a way for me to hone my own skills while informing our developers about web security issues. The contest has a somewhat limited scope- I must get in by abusing a hole in the code or configuration, so social engineering, server configuration, and other attacks are out (at least as the primary attack vector, though I may use them as leverage against another hole). It also is limited to single-developer applications, so they tend to be small in scale.

I'm writing about this here for two reasons. First, I think it's a very good idea. We have had an extremely positive response from the developers. They code better than ever. They are actively engaged in maintaining the security of the applications, rather than building and then forgetting about them. The contest has sparked many insightful discussions about various security concepts, including CAPTCHA, PHP session management, and XSS filtering. If anybody out there manages a team of developers, I highly recommend holding a similar competition.

The second reason is because I've received permission from the higher-ups to publish some of the post-exploitation writeups on this blog. I hardly consider myself to be the best web application hacker out there, and I don't think I'm a definitive authority on the subject, but I've found (and I'm not alone) that very few non-security people, particularly the developers in charge of building the applications, know how an attacker works.

I'm hoping that by showing the thought process and techniques that I use, I can enlighten a few developers, project managers, and maybe even a few other security-folk.]]> http://skeptikal.org/index.php?entry=entry080918-143113 Mike Bailey (mckt) Thu, 18 Sep 2008 20:31:13 GMT http://skeptikal.org/comments.php?y=08&m=09&entry=entry080918-143113 A Grain of Salt http://skeptikal.org/index.php?entry=entry080909-153605
I evaluated V3 Chat, a web-based instant messenger service, about a year ago for a client. Based on the high number of XSS and other holes in the software, I strongly recommended against it. The client found another solution, and life went on.

Today I was asked to look at it again, as another client wanted to use it and a new version has since been released. Within seconds, I found the first of many holes in their demo.

Normally, this wouldn't irritate me so much- recommend that they not use it, move on with life, etc. But the vendor's web site states the following as a bullet point:

"New! - Improved User Security. Greater safety and security for private chat conversations. Increased protection against XSS and MySQL attacks."

The really irritating part to me here is the fact that they are using improved user security as a sales point, when not just the original, but the "improved" version of the software would not pass basic PCI compliance testing. They haven't even fixed the XSS hole that I emailed to the vendor several weeks before sending it to XSSed.com about a month ago (this was partially the inspiration for my Open Letter to the Internet at about the same time). While this software is, in my professional opinion, lousy, this is nothing new to the web. Unfortunately, there is a lot of broken software out there, and very few vendors, much less their customers, realize this.

What would it take to fix the web? A lot, I'm afraid. Bruce Schneier keeps telling people that it starts with legal accountability on the vendor's part, which I'm inclined to agree with. In the meantime, you can secure your own web services with a healthy dose of skepticism (hence, the title of my blog). It's common enough that it's not even news anymore, but I've seen far too many instances of encrypted, unbreakable, or "improved" software turning out to be insecure.

Whenever my company is looking to use some commercial software, they run it by me first. I talk to the sales representative and am always told that the product is perfectly secure, will solve all my problems and whiten my teeth while I sleep. Invariably, I get a demo copy and find holes in the software.

This in itself isn't always enough to get a negative recommendation; I send the vendor my findings, and watch how quickly the issues are resolved. After evaluating the vendor's response to the problems, I can finally make a recommendation. Usually, we end up building whatever we needed in-house. The times that we don't, we usually wish we had.

Often, the vendor is the most surprised to find out that their magical software is full of holes. At least, they act surprised. Don't trust the marketing, don't trust the reviews in ad-supported-magazine weekly. If it's going to be used somewhere important, it's worth your time to look for yourself. If the vendor won't let you demo a copy, move on. If you haven't the time or the knowledge to evaluate it, I have both, but less money than I would prefer.

That's my rant for the day.

]]> http://skeptikal.org/index.php?entry=entry080909-153605 Mike Bailey (mckt) Tue, 09 Sep 2008 21:36:05 GMT http://skeptikal.org/comments.php?y=08&m=09&entry=entry080909-153605