Monday, July 23, 2007

Hacking without credentials

It is common to be faced with a web application where you have no credentials to log in. Very often, the application contains a wealth of functionality that can be accessed without authentication and which you can start working on to find a way in. Typically, the most promising initial targets are the more peripheral functions supporting the authentication logic, like user registration, password change and account recovery.

But occasionally you will face a narrower challenge. Suppose the web root of the server returns a simple login form, with no other functions and no links anywhere else. You can try to guess a username and password, but is that all?

Here are just a few of the things to think about in this restricted situation:

  • Looking for names, email addresses and other information in the HTML source.

  • Fingerprinting the web server software, application platform and any other identifiable technologies in use, and researching these for vulnerabilities.

  • Enumerating the content that is currently hidden, by brute forcing file and directory names, running Nikto, etc., and checking whether the content discovered is properly access controlled.

  • Checking search engines and Internet archives for references to the target.

  • Tampering with any hidden parameters and cookies in the login request that may affect server-side logic.

  • Checking for any disabled form elements that may still be processed if you re-enable them.

  • Adding common debug parameters (like test=true) to your request.

  • Inspecting the ASP.NET ViewState (if present).

  • Testing for username enumeration via informative failed login messages or other differences.

  • Testing susceptibility to brute force attacks.

  • If the application issues session tokens prior to login, testing these for predictability.

  • Testing all request parameters and headers for common code-level flaws like SQL injection, XSS, script inclusion, etc.

  • Probing for logic flaws within the login function, by omitting parameters, interfering with the request sequence if multi-stage, etc.

  • If the application is hosted in a shared environment, looking for co-hosted applications that you may be able to leverage to attack your target.

Any one of these attacks might give you a sufficient foot in the door to get past the login and into the protected functionality behind it. If they do not, then the login mechanism is a lot more robust than most are, and it is probably time to try to get hold of credentials, or move on to another target.

Friday, July 13, 2007

All your header are belong to us

First there came XMLHttpRequest, and then came Flash. This week, Alex released some great research demonstrating a new technique for spoofing browser HTTP headers.

The original problem with Flash was that it could be used to spoof any HTTP header within the browser of a user who invoked the Flash object. The fix that was applied to Flash did not make the problem go away altogether. It prevented Flash being used to spoof certain built-in browser headers, such as Referer and User-Agent. However, if a vulnerable page echoes the contents of all the headers that it received (as often happens in diagnostic error messages), then Flash is still a viable delivery mechanism for a reflected XSS attack.

What Alex has noticed is that many programming languages use underscores instead of hyphens when naming a header whose value they wish to access. For example, in PHP the following will retrieve the value of the User-Agent header:


Predictably enough, a Flash object can be used to spoof a header containing the non-standard name:

req.addRequestHeader("User_Agent", "<script>alert('xss')</script>");

This is not blocked by the fix to the original problem, and yet in many languages (most notably PHP, Perl, Ruby and ColdFusion) the application will process the attacker's payload instead of the browser's built-in header. Very nice.

Alex also discusses some other attacks, which are well worth a read.

There is an important lesson in all of this, beyond the detail of the actual attack. The subject of request header spoofing arises in all kinds of situations, including XSS, XSRF and DNS pinning. Some people do not realise there is a problem at all, and many others think it has gone away through fixes to Flash and other client-side technologies. Even if the new hole is ultimately plugged, I'd bet that another one will be found soon enough. But regardless of that, we should in general make the working assumption that a malicious web site can spoof any request header of a user who accesses that site. If your application contains XSS when echoing request headers, then fix the bug. If your application trusts request headers when defending against other attacks, then find a more robust defence, before someone else finds a way to bypass it.

Tuesday, July 10, 2007

DNS pinning and web proxies

DNS-based attacks against browsers have been known about for years. These attacks have received increased attention recently, following the discovery of defects within browser-based DNS pinning defences.

So far, discussion has focused on browser issues. However, the same attacks can also be performed against web proxies. Browser-based DNS pinning does not apply when a web proxy is being used, because the DNS look-ups occur on the proxy, not the browser. Hence, even if DNS-based attacks are completely addressed within browsers, the problem is not going to go away altogether.

The most significant opportunities for DNS-based attacks are against web users on internal corporate networks, as a means of gaining unauthorised access to sensitive information and web applications on internal intranets. Given that a large proportion of these users access the Internet via a proxy server, attacks against web proxies may represent at least as significant a threat as those against browsers.

I've written a short paper which explains the problem, examines possible software-based solutions, and describes the defences that organisations and individuals can use to prevent attacks against them. In summary:
  • DNS-based attacks affect web proxies as well as browsers.

  • Today's proxies are vulnerable.

  • The problem is not straightforward to fix in software.

  • You can protect your own infrastructure against these attacks.

Wednesday, July 4, 2007

Book review: Cross Site Scripting Attacks

I just read XSS Attacks by Jeremiah Grossman, Robert Hansen, Anton Rager, Petko Petkov and Seth Fogie. The book is a comprehensive analysis of XSS and related vulnerabilities, and covers everything from a beginner's introduction to XSS through to advanced exploitation and the latest attack techniques.

Overall, the book is well-organised, technically accurate, and full of pertinent examples and code extracts to illustrate the different vulnerabilities and attacks being described. There are plenty of tricks that will benefit even experienced web app hackers, including a wealth of filter bypasses, and coverage of offbeat topics such as injection into style sheets and use of non-standard content encoding.

There is strong coverage of recent research including JavaScript-based port scanning, history stealing and JSON hijacking, as you would expect given that these techniques were largely poineered by some of the authors. All of their explanations are clear and precise, and contain sufficient detail for you to fully understand each issue, and put together working code to exploit it. The book also includes the use of non-standard vehicles such as Flash and PDF for delivery of XSS attacks.

Here and there, the book displays the effects of multiple authorship, notably in the discussion of the best tools for finding XSS flaws. I know that some of the authors have rather opposing views on that question, but it is always good to get different people's perspectives on the tools they find most useful. There are also a few typos and editorial glitches, but that is the price you pay for being quick to market, as they evidently are.

Overall, this is a great book that will benefit a wide range of people, from novices to seasoned hackers. It is fun to read, with plenty of lighter moments punctuating the technical meat. Nothing else currently available is hitting this target - get it while it's hot!

Monday, July 2, 2007

Lame bugs for a rainy day

Most web applications contain enough serious security defects to produce an impressive pen test report, demonstrate a job well done, and (implicitly) justify your fee. In this situation, it is easy to overlook, or fail to report, a wide range of less exciting vulnerabilities that do not provide a direct means of compromising the application.

Just occasionally, you encounter an application which is so nailed down that you can find little bad to say about it. I think I even remember one app that didn't have any XSS, but I may be wrong. Even here, there are usually a bunch of "lame" issues you can identify, to at least demonstrate your attention to detail. Some common examples include:

  • names and email addresses appearing in HTML comments;

  • overly liberal cookie scope;

  • autocomplete enabled;

  • failure to timeout user sessions;

  • broken logout functions;

  • informative error messages;

  • sensitive information transmitted in the query string;

  • session fixation;

  • directory listings;

  • caching of sensitive data;

  • arbitrary redirection.

Why do we think these bugs are lame? Presumably, because you cannot normally exploit them to do anything seriously malicious against your target. But this thought overlooks the possibility of chaining multiple low-risk flaws together. Very often, vulnerabilities that present no threat in isolation can, in skilled hands, be leveraged to completely compromise an application. RSnake's entertaining Death By A Thousand Cuts provides a classic example of this. If we are doing our jobs properly, we should be reporting all of these issues any time they arise, regardless of whether it is raining.