There’s an interesting an pretty intelligent thread on bugtraq about why PHP is an insecure language and how to solve it.  Most of the thread is pretty pedantic, but the most recent post by Glynn Clements is pretty interesting.  In his post, he describes what a secure language from the standpoint of XSS and SQL injection might be.

My theory is there is no such thing as a safe language.  When there was C there was buffer overflows and stack smashing.  When there was PERL there was null byte injection, now that we have PHP there is, well, everything that PERL had wrong, minus null bytes (sorta).  What would a new language look like that could protect you from all the wrong doings of your web users?

It would have to protect you from CSRF, it would have to protect you from injection, wether it’s script injection, HTML injection or otherwise.  It would need to validate the authenticity of any uploaded files to be the files they were expected to be.  It would have to identify and stop robotic activity, like blog spamming, without blocking valid users.  It would need to keep state (session management), and not allow cookie replaying.  It would have to clean up memory properly.  It would have to abstract databases so credentials could not be leaked.  It would have to properly escape all chars bound for the database through a database access teir.  It would have to escape all presentation bound data to be presented in the way it should.  It should monitor all outbound activity for patterns that could denote database dumping (credit cards or otherwise) and stop them.  And probably about a dozen other things…

Would that make it secure?  What would that solve exactly?  Well now that I’ve got all that stuff taken care of, I’m still not sure that I’m secure.  What about basic content filters?  Those are different on every site.  What about insuring that you aren’t allowing illicit content to be uploaded (okay, you can argue a content filter could detect illegal porn, but I wouldn’t buy it).  What about those Chinese bad words, we discussed?  Yes, we’d have to go out of our way to block those so our Chinese brothers could visit our site.  My point being, no matter what you do, you still end up having to customize your application to deal with the other security risks that your organization faces (if you care).

Why can’t this all be a module?  Why can’t I just include CGI.pm in PERL and have it magically take care of all this stuff for me?  Why do I need a new language?  How is that new language any better than a single inline module?  Does it help me as a developer?  My guess is that no, it doesn’t.  Firstly it forces me to learn a new programming language, which by the looks of his article would be less than trivial.  Secondly, it is still vulnerable to some attacks, no matter what you do.  Third, I still end up having to include modules to do the application logic that I need, like thumbnailing or polling widgets or whatever.

Since PHP is abstracted already, and has the concept of libraries and includes, why don’t we just create a module that overwrites all of the base functions to make them more secure?  Wouldn’t that go a lot further to solving the problem than creating a new language, on top of which would need to be re-created every dynamic application that has already be built?  I think re-inventing the wheel (again) isn’t solving the problem, it’s just abstracting it and making developer’s lives more difficult.

Simo64 posted a vulnerability to Bugtraq today, that demonstrated a pretty useful vector. It’s pretty obvious but it’s also not used that often. A TITLE tag is encapsulated with everything other than an end TITLE tag. An end title tag will allow any HTML to be rendered inside of the HEAD tag that it resides.

Simo64 pointed out this vector by popping out of the TITLE tag in the Open Guestbook software, which allowed a cross site scripting vulnerability to render. There’s also an SQL injection vector, which is actually slightly less interesting as it’s a pretty typical SQL injection. Anyway, good job, Simo64!

OWASP (Open web application security project) just came out with their OWASP PHP Top 5 vulnerabilities list.  It details a number of what they consider to be the highest priority security vulnerabilities for PHP.  Coming in at number two was cross site scripting.  On the document it says that it was the research behind the PHP section of the SANS top 20, however cross site scripting was not named at all in that document.  It’s interesting to see how these lists evolve, based on the number of vulnerabilities are documented in a year’s time.  I wouldn’t expect this to do anything but grow!

I happened upon an interesting way to detect 404 ErrorDocuments under Apache a few days ago that I thought might be relevant to the SEO (Search Engine Optimization) community. For those who don’t know know what ErrorDocuments are, they are catch alls that attempt to capture any traffic that is going to the wrong page and sends them to a known page that lets them know that “hey, you screwed up and here is an error page telling you that.” This is particularly useful for things like httprint that use server signatures to tell what a server is.

Anyway, the simple way to create an ErrorDocument under Apache is to create a .htaccess file in the root directory with something like this:

ErrorDocument 404 http://ha.ckers.org/

Here’s what a typical HTTP 404 page looks like:

HTTP/1.1 404 Not Found
Date: Mon, 26 Jun 2006 20:34:30 GMT
Server: Apache
Content-Length: 202
Connection: close
Content-Type: text/html; charset=iso-8859-1

Which accompanies text that says:

Not Found
The requested URL /BLAH was not found on this server.

Now that page will never appear if they are using an ErrorDocument, which screws up HTTP fingerprinting techniques. Instead you’ll see wherever they were sending you. That is, unless of course, you use a little trick. I found that if you include a NULL character along with the URL, you actually get another page (something like http://ha.ckers.org/BLAH%00 with the null at the end). Here is what you see:

HTTP/1.1 404 Not Found
Date: Mon, 26 Jun 2006 20:54:45 GMT
Server: Apache
Content-Length: 202
Connection: close
Content-Type: text/html; charset=iso-8859-1

With the text:

Not Found

The requested URL /BLAH was not found on this server.

Then I tried against an IIS6.0 server and got:

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Mon, 26 Jun 2006 20:51:11 GMT
Connection: close
Content-Length: 34

With the text:

Bad Request (Invalid URL)

As you can see, they are wildly different, despite the fact that the Apache instance above had an ErrorDocument. I have not been able to validate against the same type of error handling under IIS but based on this, I don’t believe IIS would handle the request at all, seeing it entirely as invalid (a 400 error instead of a 404 error). This could easily allow you to fingerprint a machine between IIS and Apache alone on a single malformed request, which could easily be built into httprint, xprobe or nmap or other similar tools.

There’s been a lot of talk on the Webappsec mailing list lately around browser content restrictions (something I came up with a few years back and proposed to Rafael Ebron at Mozilla which was later picked up by Gerv while I was working for a huge dot com). As a side note Gerv also came up with another idea on his own called script keys that uses a unique string to denote which script is allowed to run and none other.

The idea of content restrictions was to enable webmasters to limit their exposure to certain forms of attack (in the same way Microsoft’s HttpOnly attempted to limit cookie theft). The problem with both content-restrictions and script-keys are that no one is devoting resources to investigate them or build them - so they sit for a later day.

But as an academic excersize, let’s talk through Brian Eaton’s latest email to the list:

First of all the original idea of content restrictions was to limit the text on the page. So my first proposal was to wrap user generated output in tags that would limit the page (of course you’d either need to parse against the end tag, or you’d have to take the second one in order to make sure they didn’t end the tag and start some malicious XSS). It was to take the form of either a Meta tag, or a HTTP header or both. Our original idea was to wrap the text in an iframe, but scrollbars were not an option for our user community and because of the cross domain issues (knowing how big a page is can tell you the state of the user visiting it) it was dropped.

Content restrictions was never designed to stop basic CSRF, unless you are talking about functions that could only be affected by JavaScript, which would inherently be stopped. Brian’s comment that this would not help with reflected JS should be inaccurate, as any JavaScript would be affected (part of the problem was that it could end up killing valid JS on the page, which was something we were attempting to overcome in our first iteration of the idea by wrapping the possible offending output in tags to be parsed out by the browser as safe content).

The use of an XML document has issues. Firstly, the policies will vary from page to page and on some sites that could mean millions of pages. Having it in the root directory won’t help with this, since you’d have to have a mapping of every variant of every page with every parameter mapped out. So we opted to dynamically outputted on the page. An XML document could work if you are talking about having one in each directory, but even that could be a tremendous amount of work unless you can use star operators, and I’m sure on some websites that would be a terrible burden.

Also, avoiding CSRF is very difficult… because many websites want to allow linking to remote images. If you link to a remote image, that can actually be a HTTP 301 redirect back to your site function. It’s very tricky to avoid that issue from a business perspective without allowing people to upload photos, and if they upload photos you are risking them linking to their own malicious content hosted on your website (let’s hope you don’t have script injection issues). Anyway, that’s an issue that has not been well thought out as CSRF is really a completely different beast.

Another major problem for this security model is things like Akamai. When you are running a very large website and you want to use a content caching service to optimize your website, you inherently need to link to other domains with your JavaScript. And if you ever intend to have personalization the JavaScript will almost invariably have to have access to one or more cookies.

Brian didn’t mention are DOM based injection explicitly (he did mention XSS, but this is a particular example), which should be allowed given the script in question should have the authority to do whatever it needs to. As a webmaster, I might WANT to pull in remote images or remote XML files, and stupidly, I might rely on user input to do that. But yes, redirection is a huge issue as well. For almost all major websites, there is tracking, and unfortunately they almost always use a basic redirection technique that would allow bypassing of the cross domain linking policies.

Ultimately my major problem with this technology is the same problem that Microsoft’s HTTPOnly faced. It was a pretty good precaution, that had a few small holes and was never properly picked up by the rest of the browser community, making it not cross platform compatible in some cases (like IE5.0 on Mac - completely breaks cookies with HTTPonly in them). And the clincher here is that no one is coding it. So… it’s a wait and see game with the browser community as far as I’m concerned.

I was doing some thinking on the most common places you are likely to find XSS vulnerabilities - in particular reflected XSS vectors that take URL parameters. Of course, the first thing that comes to mind is error conditions, like “Cannot find ….”. That’s probably obvious, of course and maybe there’s room to have a custom error reporting function that deals with the problem better than simply outputting text to the page, but that’s less interesting than my next thought.

The other place I have seen this type of vulnerability is in custom 404 scripts. One example was the UTF-7 exploit found in Google’s custom 404 script. One of the great things about custom 404 scripts is that they are incredibly easy to locate, if they exist.

A simple scanner that simply loads up a list of websites and/or IP addresses could work through a huge list relatively quickly, outputting a potentially huge list of vulnerable XSS reflections.A simple script testing for a function like http://www.example.com/<XSS> or one of the other payloads on the XSS Cheat Sheet that then watches for return output looking for the same thing outputted could be far more efficient for finding large swaths of vulnerable websites than by-hand auditing could. Of course this would miss a huge percentage of vulnerable applications, but for a spray and pray approach, this would be far more effective than most other methods. This could also have huge implications for the Blackhat SEO community.

I’ll talk about other (and arguably better) methods of doing large scale XSS vulnerability assessments at a later date, but I did want to get this out there.

Last year there was a lot of press around how MD5 was finally proven to have significant issues. Then there was a bit of an uproar in the webappsec community around abandoning it for other safer hashing systems. When I first read the news, I was really saying to myself, “Well, even if it wasn’t broken in this way, rainbow crack is a more significant threat to hashing algorythms than anything else anyway.” Rainbow crack uses a time memory trade-off by precomputing all hashes. (It gets is name because the tables sorta look like a rainbow if you gloss your eyes).

I wouldn’t even bother using L0phtcrack anymore now that rainbowtables is in existance and free versions availible by the schmoo group. There are even companies that sell rainbow tables on CDs and talk of a distributed rainbow tables project.

MD5 isn’t broken. It’s got a flaw, yes. For normal password length strings, it’s broken by time-memory trade off. But is it broken for web application use? I dare say no.

What is a hash? A hash is a one way algorythm (at least in theory) that in general has non-repudiation built into it (that’s one of MD5’s flaws actually - for any plaintext it should create just one hash, but in reality multiple plaintexts could end up being a single hash). To put it in simple terms, a hash is a mathematical computation that creates an answer that is very difficult (impossible) to derive the question from.

Where are MD5 hashes generally used? There are two places I see MD5s in wide use in web applications. The first is in password storage. Okay, you got me, MD5s are an issue for password storage as rainbow crack shows. The second usage is in cookies. People often hash long strings with a regularly changing secret string (or salt) to compute a hash that they include in the payload of the cookie. Cookies that are tampered with will not match the hash and the website can detect that the cookie has been compromised.

Rainbow crack really is a great tool, but it has one major flaw in it. It takes a LOT of time to calculate every known hash of every password and worse yet, a lot of space to keep them all organized. Passwords are generally less than 8 characters, but even still, I’ve seen passwords that can get up to dozens of chars long (like GnuPG or PGP passphrases, for instance). What about long strings, like cookies? Cookies are arbitrary things that can be any lenght (well, in reality they must total less than 4k otherwise Internet Explorer can’t deal with them in JavaScript space). So let’s just use 4k as a hard stop.

Four thousand characters is slightly longer than say, 8 (the size of a normal password) to say the least and even with 8 characters you are talking about a CD sized rainbow table disc of possible combinations. With every extra digit you add an order of magnitude. Given the size of the total possible combinations of a cookie, even though rainbow crack can technically do what I am proposing the amount of disc space to generate such a table would be ultramassive, and far beyond the scope of the rainbow tables projects. Will I continue to use MD5 in web applications? Of course! It’s a valuable tool. Will I rely on it for password integrity alone? Absolutely not. Is it broken? Sorta.

In the spirit of my post on why companies shouldn’t use laptops like firewalls I did a little research on ways to mitigate giving users no access while still maintaining some level of control over Windows operating systems for when users need to install certain programs as administrator.  Then I came accross an interesting blog article that had a funny quote in it, speculating that it is in fact better to be a local user without admin privileges and without anti-virus than it is to be an admin with AV installed. In the same article he posted a link to SudoWN which is essentially sudo for Windows.

It’s a pretty clever idea, to allow users access only when it is known and intentional.  Of course there are unknown security holes in the system itself, and given keystroke loggers it sorta makes the point moot (yes you can build a keystroke logger in JavaScript even, no admin rights needed).  But it’s a concept worth exploring nontheless.

Charlie over at thehackersplace.org sent me this email (snipped for reading) about a XSS and a CSRF vulnerability in gameplay.co.uk (a big online game retailer):

http://shop.gameplay.co.uk/webstore/advanced_search.asp?Keyword=&terms=

!&badterm=%3Cscript&3Ealert(document.cookie)%3C/script%3E

also..

the gameplay password change doesnt request the old password so a script could be made to automatically change the password.

https://shop.gameplay.co.uk/gameplay/myaccount.asp

test account:
user=thisisatestingme
pass=xssxssxss

https://shop.gameplay.co.uk/gameplay/changepassword.asp

Actually more interesting than the XSS is the CSRF in my mind. In this particular example the CSRF does not require any user interaction to perform one of the most significant site functions (password change). Maybe this isn’t that big of a site, considering it’s not a community site, but the premise is the same. Requiring user interaction (like requesting that the user type their old password in) is a pretty common sense way to stop that particular attack. It’s safe to assume that if they have your password already, you have bigger issues, but even still, omitting a one time token on the page that can’t be faked that must be seen on the next page is another way to reduce the threat.

Notice I don’t say solve, I say reduce. That’s also assuming that on the page in question there isn’t an XSS vulnerability that can read that one time token. One time tokens definitely aren’t 100%, they must be on pristine pages to function properly. Anyway, thanks to Charlie for the info!

As if you needed another reason to visit Blackhat this summer, two researchers just found a way to hack into wireless cards remotely and take over laptops. David Maynor and Jon Ellch will demonstrate it in August, at the convention.

This is really the problem with how companies treat laptops.  People are given laptops to be more mobile, which is great, but they are protected by the systems that no one in thier right mind would put on an unprotected network.  Then they are allowed to go out into the world and log into whatever network they choose.  Obviously this is a perfect time for viruses, trojans, keystroke loggers and malware of all variety to infect the machines.

The problem is peoople treat laptops like corporate firewalls.  If there is an access to entry, the bad guys will take it.  It’s really not that hard either.  Keeping a system dormant or sending out one packet once in a while until you find it omitting packets from an interesting network, is pretty trivial.  Treating corporate laptops as the front line security, but then not adding additional protection on top of them seems like asking for disaster to strike.

Of course, the wireless protocols that exist today are all prone to insane problems.  If you read the article on the six dumbest ways to secure a wireless LAN you know that there are a half dozen obvious problems with configuration, and probably an equal amount of tricks to get access, like spoofing access points, attacking the access point directly, cracking WEP, etc…  And that’s without even doing anything to the laptop itself.  Now, you add on the ability to hack the basic fundamental peice of hardware that can secure the transmission of data to your network, and you have a clear path to gaining access to that network.

Of course there’s more to it - there are way more protocols than just 802.11b that are at risk here. People have AIM/YIM/IRC sessions, email, NNTP, HTTP, and god knows what else.  All of which are viable transport mechanisms for malicious users to gain access to the laptop, which sits well behind the DMZ.

I had lunch with the CSO of a big bank at one point and he said the best advice he ever got to securing a large scale network was from a guy at Gartner who told him to “not let the local admin rights genie out of the bottle.”  I think that’s the right first step, but taking it further, allowing the user to have any access to the network beyond what is “safe” and secured seems like a bad idea.  Not to mention that 70% of successful hacks attempts are from employees anyway.

So anyway, go to Blackhat, and listen to Jeremiah Grossman’s talk as well as David Maynor and Jon Ellch’s talk if you get a chance.  I bet it’ll be interesting.