Hacking Databases; SQL Injection & Input Validation
In this lab I was able to obtain unauthorized access to a sample database within my test environment.
DISCLAIMER: This is not intended to be an instructional on how to hack for criminal intent. Introducing unwanted activity to another network, stealing digital files, and damaging systems is illegal and punishable under Canadian law.
Three machines were used;
- an Attacking machine; Linux distro of my preference (Kali)
- the Victim; Windows OS (Windows 7 to simulate the common business OS)
- and the server hosting the database; Ubuntu (running OWASP mutillidae for vulnerability testing and practice)
I crafted an encoded netcat payload on the attacking machine and delivered it to the victim via a disguised URL-email. The payload was designed to run a netcat client which would connect to a listening port from the victim machine, hiding the process behind a common service-host app which could be overlooked by a sysadmin. Encoding was an important part of this attack since it altered the digital signature which would normally be detected by a firewall application-- rendering my payload inert.
This was required to bypass the expected antivirus software on the victims host machine, which for purposes of education, was the default Windows 7 OS system firewall and an outdated trial version of the included Symantec Norton Anti-virus.
The spear-phishing attempt lead to netcat running in stealth mode, allowing me to silently connect the victim to my proxy for the purpose of capturing victim traffic via burpsuite. This man-in-the-middle attack (MITM) allowed me to sniff traffic and pass HTTP POST & GET requests while copying headers, data, or details of importance which would aid in the later success of an SQL injection.
MITM explained, Image source: https://securebox.comodo.com/ssl-sniffing/man-in-the-middle-attack/
Data that can be captured includes;
- Usernames, passwords (in plaintext at times)
- Browser information, version, and type
- Website activity, destination, URL and
- Browser cookies; a very useful piece of information that can be modified to conduct cookie injections (covered in another lab)
As mentioned earlier, the main focus of this lab was to investigate the ability to obtain unauthorized access to databases, specifically the OWASP mutillidae test database. MITM attacks can provide a basis for this alone since login information could be captured and readily available, but alternative methods exist in the event of quick-written code.
THE PROBLEMS WITH QUICK-CODE
OWASP provides an intentionally vulnerable platform for ethical hackers and security enthusiasts to practice on. These include deliberate vulnerabilities in source code for an injection to take advantage of escapes or input exceptions, a lot of which exist on open markets.
Behind every created product was a deadline. Shortcuts, pressure and a dwindling amount of business resources can result in a lesser-quality production of syntax or code logic that could result in exploitation. It's not done intentionally and generally is the byproduct of an effort to meet business time objectives. Quick-code is difficult to maintain, manage, and audit-- hence the name "spaghetti-code", one big mess of syntax readable only to the compiler.
Difficulty in maintaining the code may result in overlooked input validation and sanitation. This is the root of the SQL injection.
An important part of debugging is input validation and sanitizing code. When a program is written it's logic should be very linear without an option to derail it's purpose. A program shouldn't divert from it's intended and designed path, and should be tested against exceptions made during the input. A simple example of this is a basic HelloWorld!() program:
In my code example above, the program will PASS and print the username + Hello world IFa requirement is met. If the requirement isn't met (the username entered is less than or equal to 1), the program will default to it's DENY-- a request to enter a valid name.
An exception can be made which would result in a pass, though it should be a deny. If the user enters a number (a numerical value for a name, i.e 2), then the program should identify that the numerical value '2' is not a human name and is 1 character long, but since the exception of a numerical value bypassing the character count of a given name length was left unchecked or sanitized, the user defeats the program.
SQL INJECTION; ' OR 1 = 1' Attack
The same technique was used to breach a test database and view sample credit card information through use of an SQL injection (a ' OR 1 = 1' Attack). SQL Injections are the most common web attacks used by hackers today. The practice is much the same as the input validation example above-- only an attacker places malicious SQL code that runs behind the web page on the server or database.
The failure to sanitize code and leave input validation gaps can lead to an attack similar to this where the request for a 'PASSWORD' on a web page can be defeated by throwing an SQL statement which will always be true. (1 = 1)
Remember: programs are very linear and should not deviate from their intended purpose. A program requesting a password will always check the entered value against the expected value, or...
The server views the input as an SQL statement and accepts it since the source code wasn't prepared for the exception. This escape would bypass the need for a password if left unattended. Many programmers and debuggers work vigorously to ensure that an attack like this can't occur-- but with the global demand to remain competitive, some businesses risk quality of work for time and so SQL injections continue to exist across many platforms. Programs and code should be carefully audited to ensure this cannot occur regardless of the condition supplied. (example: 1 = 1, or 10 = 10, etc.)
Conclusively, with the payload successfully delivered via email and the information gathered from the MITM attack (the login username, server IP and socket number), the SQL injection bypassed the password requirement and gained access to a restricted test database containing financial information.
RESULT: a successful breach of a test database and some knowledge on how SQL injections/exception handling works with the end goal of preventing them in future.
Originally posted on LinkedIn: https://www.linkedin.com/pulse/hacking-databases-sql-injection-input-validation-hector-barquero/