I found this a few months ago and have been racking my brain for a way to use it in a pentest. Maybe somebody else can find a practical exploit for this; so far, I have nothing. I do think it's kind of funny though.

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.

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?

RSnake is starting to release details about his much-hyped 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.

Here's the first of many writeups for my "Hacker Challenge". Keep in mind, this isn't a penetration test- it's just a train-of-thought writeup of how I cracked an application. The idea is to demonstrate instances of various attacks in use, rather than the theoretical proof-of-concepts that appear in most security web sites.

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.

I work for a web development and hosting firm, where have an ongoing competition. Our webapp developers submit their newly-built sites for a voluntary cracking attempt. If I cannot in some way compromise, abuse, DOS, or gain escalated privileges, the developer in question gets a monetary prize.

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.