Hacking without credentials
Dafydd Stuttard |
23 July 2007 at 08:18 UTC
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.