Do you like this story?
In a recent press release published by the FBI, details have emerged of the scale of the attacks against international newswire services such as PR Newswire and Business Wire. Between 2010 and 2015, Ukrainian hackers Oleksandr Ieremenko and Ivan Turchynov gained unauthorised access to various computer systems, enabling them to steal “yet to be published” press releases that had been scheduled by major financial organisations. Containing financial reporting and other sensitive data, the hackers sold on the information and facilitated an estimated $30 million in illegal trading profits.
Nine people have now been charged in connection with this case which involved the theft of over 150,000 press releases. The hackers used sophisticated methods of attack including malware and phishing, SQL injection and brute force. SQL injection is used to attack data-driven applications and involves inserting malicious SQL statements into an entry field for execution (enabling, for example, exfiltration of the database). This latest high profile case highlights the need for organisations to be aware of and resilient to this line of attack.
Mitigating the threat of SQL injection
Senior business managers may have read about this story and be wondering how they can better protect their organisation against this kind of threat. There are numerous steps that can be taken but perhaps one of the most fundamental preventative measures is to ensure that you regularly monitor and carry out checks on all of your network’s private and closed applications. Having adequate security procedures in place to protect your applications will significantly hinder attackers from being able to carry out this sort of attack in the first place.
However, to further reduce the threat of SQL injection, there are numerous steps that can be taken on a coding level to mitigate this form of attack. The priority steps include:
1. Using ‘parameterised’ SQL statements – putting clear parameters into SQL instruction.
2. Validating each parameter ID. For example, the ID parameter must be a number, or is restricted to certain terms.
3. Using ‘escape’ parameters before insertion to the SQL statement. This ensures the commands inserted by the hacker are treated as a variable rather than a command. So instead of comparing the id with ‘XX’ and then executing ‘truncate table news’, the id is compared with ‘XX; truncate table news’ which is not a legitimate id and is rejected.
In addition to the steps above, and dependant upon the framework used, the following should also be considered:
4. Performing validation on data being read from a database (as in points 1-3), in addition to data being inserted into it. This prevents second order injection. In short, trust no source of input.
5. Setting the permissions on the database so it’s limited to only the data it’s required to read. This won’t stop injection, but it might limit the impact.
It should be noted that using escape parameters as in point 3 is the least desirable method compared to 1 & 3 as there are many ways for an attacker to encode data.
Finally, don’t forget the basics. Change the passwords of application accounts into the database regularly. Update and patch all applications and databases as early as you possibly can.
About the Author
Mike James is part of the technical team at Redscan – a managed threat detection and security services company.