by Andy Givens
A recent article from Ars Technica focused on one of the largest ever hacking infiltration attacks alludes to the compromise of databases that allowed attackers to run malicious code. The article states:
“The hacking gang traded text strings that exploited SQL-injection vulnerabilities in the victim companies’ websites to obtain login credentials and other sensitive data, then installed malware that gave them persistent backdoor access to the networks.”
An interesting progression in this attack is the escalation of privileges from database user to system administrator, which allowed the attackers to execute malicious code. Once a database has been compromised, an attacker is likely to target privileged accounts to gain system level access while using the database as a conduit to plant malicious binaries on the file system.
To avoid this type of vulnerability, the regular rules for preventing SQLi still stand – Turn off detailed error reporting in your web server, use stored procedures and/or parameterized data as often as possible, scrub user submitted variables, etc. These best practices will greatly reduce the possibility of intrusion via SQLi methods, and help to protect the information local to that database.
But securing your databases is only half of the battle. How can you mitigate the possibility of an attacker gaining system level access if a database is ever compromised? First of all, never run your applications with more database privileges than necessary. Do not use root or local administrator as an application account – these accounts allow access to search the database security tables. Second, always enforce strong password policies on privileged accounts. Strong policies not only include unique, complex and random passwords but also frequent rotation in order to mitigate persistent vulnerabilities.
