Many times, information system vulnerabilities are discovered several months (or years) after the initial exploit. Consider the malicious actor who only wants to “borrow” your computing power for, say, bitcoin mining. Although this example doesn’t compare to the potential monetary loss of financial fraud or other disruptions, organizations all face a similar threat landscape.
A common exploit used to gain control systems and steal information is SQL injection, which commonly occurs via html forms that are accessed through web browsers. Let’s take a look at how this happens. Then we’ll walk through the clean-up process and ways to prevent these types of attacks.
SQLi attacks take advantage of loosely defined variables and the default settings in SQL databases. The attacker mixes code with input data on a web form, which tricks misconfigured web applications. Often times, malicious actors find vulnerable sites using readily available tools such as Google “Dorking;” dorking is used to discover SQL syntaxes in website URLs. This vulnerability has even prompted federal officials to release a notice explaining Dorking.
…to locate information that organizations may not have intended to be discoverable by the public or to find website vulnerabilities for use in subsequent cyber attacks. “Google dorking” has become the acknowledged term for this malicious activity, but it applies to any search engine with advanced search capabilities. By searching for specific file types and keywords, malicious cyber actors can locate information such as usernames and passwords, e-mail lists, sensitive documents, bank account details, and website vulnerabilities.
Read more about Dorking here.
An example would be a password field on a log-in form that allows special characters; some characters, such as a back tick (`), followed by a SQL command using a wildcard (*) and an “OR” statement such as:
Select * FROM users WHERE username = abc OR 1=1
can trick the form into executing a SQL command. Default settings in SQL databases often leave passwords unencrypted. A statement such as this (though hastily written) can give an attacker access into your database. Additionally, loosely defined variables in your database can potentially allow an application to execute commands in web forms. There are numerous ways for these attacks to happen & often times reviewing your logs are the only means of discovery.
If a discovery has been made, you first want to stop the intruder from having control by resetting user passwords, disabling unnecessary accounts, and hardening your network/OS services. The cleanup process includes removing infected files, registries, services, and certificates. Next, a systematic way of monitoring logs for privilege escalations, and things like log-in failures and reboots should be implemented to detect anomalies. To prevent attacks like these from happening, a closer code review process and a better system for log monitoring needs to be implemented. Once you’ve cleaned your system(s) and patched the vulnerabilities, input your own random and unusual data strings to your applications input fields to verify that your implementations are effective; this is known as fuzzing.
Below are a few resources that can help your organization identify known vulnerabilities get you started in developing a cost-effective and compliant strategy for safeguarding your information.
EDIT: Since the creation of our article our friends at Guru99 have created a comprehensive tutorial on SQL Injections as part of their Ethical Hacking course. This course is free and covers basic topics such as hacking tools and cryptography, all the way to advanced subjects including DoS attacks and Linux OS Hacking.
Check out their course on SQL Injection here.
Useful Resources:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-150.pdf
https://github.com/hslatman/awesome-threat-intelligence
https://www.exploit-db.com
https://nvd.nist.gov
