At first, Asprox seemed to be just another phishing botnet. Infected machines would send out spam emails, asking recipients to enter their banking details on fake websites. Nothing new there. Then, one Friday, researchers saw some strange activity. The command and control server updated all of the infected machines to start automatically hitting web servers with SQL injection attacks. Within a few days, thousands of web sites had been turned into malware servers.
Given that SQL injection has been around for at least six years, it’s depressing how many websites still get pranged by it. But on the other hand, it’s hardly surprising that online criminals are exploiting it. As vendors hardened server operating system platforms and made it difficult for attackers to exploit them, the focus shifted to web applications and the databases that serve them. After all, in a world where hacking is financially motivated, customer data is where the money is.
Searchable vulnerabilities
Any coder worth even a meagre salary should be protecting against SQL injection (which involves the insertion of database commands into web forms or URLs, to manipulate databases in unauthorised ways). But there are many other vulnerabilities in web applications, and they’re so common these days that you can search for them in Google.
Vulnerabilities that expose web applications start with the database and work outwards towards the application code itself. The default sa account password is NULL in SQL Server, for example. If you don’t change it, you make it easier for attackers to gain access. Just like SQL injection, these attacks may also be automated; the Voyager Alpha Worm last year targeted SQL Server databases with blank sa passwords.
“It’s best to disable that [account] entirely and only use Windows authentication via Active Directory. User accounts can benefit from the same permissions and models that the directory does,” says David Hartley, senior security consultant at IT consulting firm Activity. “That means that you have a fine and granular approach. It means that people are limited in their activities.”
If you’re not on the list…
When it comes to application security, limiting privileges is the golden rule. Users or application functions should only be given as much access to the database as necessary. Disabling (or at least properly protecting) the administrator account isn’t the only measure you should be taking.
How many accounts is the application using to access the database, for example? Just one? With all permissions allowed? Oh dear. Better to have multiple accounts, so that the application is only allowed to access the functions that it needs. Why would a ‘search for product’ script in a web form need DROP TABLE permissions, for example? If a hacker exploits the application to get to the database, he could use that command to trash your database.
Unfortunately, setting up multiple accounts won’t matter if the application isn’t coded to use them. Poorly-written software not only uses a single account with all permissions set, but will often use ‘lazy’ queries. A function might only need a customer’s name from the database, but may use ‘SELECT *’ in its query because the developer couldn’t be bothered to code a more refined query. The resulting array could hold much more sensitive data in memory - including credit card and social security numbers, for example - which could then be susceptible to other exploits.
These other exploits can often rely on weaknesses in the code, which leads to another problem with web applications; updates. Even though core operating system code can often be patched using automated software update mechanisms, it may not happen in a timely manner, thanks to the sometimes necessary bureaucracy surrounding change management. Web applications often rely on manual updates which may take months or years to occur. A month before Infosecurity went to press, an emergency patch was released for a show-stopping security bug in Joomla, the open source content management system. The bug enables attackers to change the admin password. By the time this article hits your desk, many unpatched instances of Joomla will remain, ripe for the picking.
| "The problem today is that we layer security on after the application's functionality" |
| David Ting |
Even a web app with the most tightly-written and well-patched code could be subject to attack if the developer’s own business logic is at fault, however. There’s a difference between the underlying code and the system’s fundamental design.
Let’s say that your online banking system lets customers transfer money from your account to someone else’s, but only allows a maximum of £1000 per day. Then, someone who gained access to your password in a phishing attack makes a £1000 transfer. The system checks that it doesn’t exceed the maximum daily transferred amount, and approves the transaction. Before it executes, it asks to confirm that this is the amount you wish to transfer, and gives you the chance to alter the amount. Did the developer remember to check the amount again when the attacker submits that second page? If not, he can simply alter the amount to £2000, and because the developer forgot to put a second check at this point, the transaction will execute the unauthorised transaction.
There are a host of application and business logic vulnerabilities too numerous to go into here. A good point of reference is the Open Web Application Security Project (OWASP), which regularly reviews and updates current categories of vulnerability and attack. SQL injection aside, popular attacks today include cross-site request forgery (aka CSRF or ‘sea-surf’). This uses carefully constructed parameters to force an application’s browser into performing an unauthorised action, such as logging out or transferring money. Others, such as session hijacking (using sessions that haven’t expired to assume another user’s privileges). Last December, a user discovered that it was possible to view personal details for other members of the public on the Canadian passport web site, simply by altering a parameter in the URL.
Which comes first; functionality or security?
Why are these security bugs there in the first place? “The problem today is that we layer security on after the application’s functionality,” says David Ting, founder and CTO of Imprivata, which sells single sign-on and access management products. “The days of doing that are completely over. Today, when you design an application you have to think of not only functionality, but at the core you have to worry about data security and data privacy.”
What a sweet and naive idea. The problem is that business models don’t often support the security-before-functionality ethos. Customers want functionality, and don’t think about security. Companies are eager to give it to them as quickly as possible. And by the time bad code is delivered, it’s often considered commercially unviable to change it.
| "Even a web app with the most tightly-written and well-patched code could be subject to attack if the developer’s own business logic is at fault" |
“There’s very little ROI to code mitigation projects. It’s unlikely that they’re going to make those kinds of changes any time soon, so organisations need a compensating control to cope with that,” warns Ted Julian, vice president of marketing and strategy at Application Security. “This is similarly true when it comes to patching databases.”
Customers with lots of database instances will often enter triage mode, patching some but not upgrading others, due to cost or change management constraints, he argues. Even though the unpatched databases may not hold sensitive data, they may be connected to other parts of the infrastructure that do. How can companies protect all of their web code and database engines?
Traffic patterns
Security tools can be inserted in front of or behind the web application. Web application firewalls are the obvious choice. Instead of simply monitoring packets at a port level, they carry out deep packet inspection to understand what the traffic is doing.
“The threats we prevent are the usual ones we’d expect, such as cross-site scripting, hidden field manipulation and cookie poisoning.” says Ian Schenkel, EMEA vice president of Protegrity, which sells an application firewall product. “We have a combination of whitelist and also negative firewalling. So we will update the whitelist of known attacks from time to time while making sure that its up to date,” he says.
Whitelisting checks traffic patterns against an expect traffic profile for a particular application. If the traffic doesn’t match the expected pattern, it gets dropped. Negative firewall models rely on blocking known attacks. Each has their own merits, explains Schenkel’s colleague, Mohamed Zouine, senior technical consultant at Protegrity.
Whitelists are more secure, because they can block unexpected attacks, but they’re also prone to false positives and are best suited to applications that will only be accessed by a small number of controlled sources, he says. An application only accessed as a web service by other applications in the country might be a good example. Negative models work better for applications with a large base of users accessing a web application unpredictably.
Another mitigation option is to impose access control or encryption on the database. Application Security’s dbProtect product can monitor access to the database and raise the alert should something suspicious happen. “We look for not only known security issues, but also unusual behaviour like the DBA performing a SELECT on the credit card column,” says Julian. That helps to monitor for insider attacks, too.
Databases have featured native encryption for some time. SQL Server has had it since version 2005, and Oracle started shipping data encryption in version 10g release 2. However, Protegrity’s Zouine argues that with many companies using multiple databases from different vendors, it becomes increasingly difficult to manage native encryption. Instead, he advocates the firm’s own solution, which handles the encryption process and keys centrally.
With so many vulnerabilities to worry about, and with so little time and budget, life can be depressing for people in charge of web and application security. Still, keep your chin up. It turns out that these attacks work both ways. For every sophisticated coder working in the criminal underground, there are tens of neophytes looking to make a quick buck. They use phishing toolkits and slap sites together just as ineptly as the most unsuccessful corporate programmers.
There is a growth market in hacking phishing sites, many of which store entered password details in something as simple as a text file generated from an online guest book. They can have their data stolen even more easily than you can. It may be cold comfort, but at least legitimate coders aren’t the only ones getting frustrated with online crime.