http://www.sqlservercentral.com/blogs/brian_kelley/2007/11/23/whitepaper-on-malware-to-attack-databases/

Printed 2014/04/21 01:46AM

Whitepaper on Malware to Attack Databases

2007/11/23

Cesar Cerrudo of Argeniss Information Security has put out a new whitepaper (.pdf format), Data0: Next generation malware for stealing databases, describing how malware could be crafted to steal information out of databases. For the most part, it stays at a high-level, however, Cesar does give a few example queries (for SQL Server), the appropriate API calls to perform certain operations, etc., which delve a bit more into the technical side, but even these are fairly straight-forward. To demonstrate what he talks about in the whitepaper, he built a simple proof of concept (PoC), but based on what's in the whitepaper (and what is generally accepted as what's possible), nothing seemed outlandish or hard-to-do. Just for those worried about that PoC being out in the wild, Cesar states in the whitepaper he's not going to put it out for public consumption because he knows it'll be used for evil.

Which brings us to how the malware attacks. The typical anatomy for an attack is something similar to:
Since we're dealing with malware, the attack methods are well known. Keeping malware out of the corporate environment, especially considering most of the techniques for detecting malware are signature based, such as antivirus, is difficult. When users run as local administrators, all it takes is one person clicking on an email that sends that person to a website which exploits an Internet Explorer, Firefox, Microsoft Office, etc., vulnerability to download and install the malware. If the malware is new, there isn't a signature for it. Therefore, it'll likely pass through the scans.

But what about the web site and web filtering software used by the organization? Well, if the site hasn't been categorized yet, it really depends on how the web filtering software is configured to handle such sites (if such an option exists). Some web filtering products have heuristic engines which try to analyze the content to determine if it's objectionable or not. Some engines can scan words, others also have the capability to look at images, and the engine in question generates a score. Depending on the score, the page does or does not get displayed. (I'm greatly simplifying the process, but you get the idea.) So if you're building a page that hosts said malware, you ensure it says all the right things to look legitimate for business. In fact, it may very well be a copy of another business page because the only thing you're interested in is deploying the malware. If it has been categorized, there have been known exploits of well-known organizations, such as educational facilities and even Yahoo! in recent days. That means playing a catch up game before the individual page is categorized. So in other words, getting the malware deployed typically isn't the problem.

Therefore, Cesar concentrates on the malware itself. The pattern it follows is the following:
Discovery is where it locates database sources. The two most obvious, and most stealthy, is to check the ODBC DSNs on the local system and to look into existing processes to look for outbound connections to well-known ports (such as tcp/1433 for SQL Server). If necessary the malware could get substantially more noisy by doing a network scan (again, for well-known ports) or outright sniffing the network (but switched networks makes this extremely problematic and if you try to overcome this, it will be VERY noisy).

Once the targets are identified, the next step is to attack the servers. Connections, like to SQL Server, which use Windows authentication are trivial. Otherwise, it might have to resort to brute force. Brute force, in and of itself, can be noisy (depends on whether or not you are auditing failed login attempts). And once it gets in, it can check replication settings, linked servers, etc., to locate further targets, which adds to the discovery process. However, once it's in, it'll need to scan for interesting information, and this usually means looking at metadata for table and column names. Once something of interest is found, it's all about extracting the data.

After it has some data, it needs to get it off-site. Again, if you can get a site up where malware can be grabbed, getting back out isn't that difficult, either. Even if an organization is doing egress filtering, they still allow out HTTP and HTTPS. As long as the web site passes the filters, all is well. And the data is in the hands of a malicious individual or organization.

Afterwards, if necessary, the malware can cover its tracks by removing itself. This may be a good idea to make getting samples of the malware more difficult, thereby impeding a security company's ability to generate signatures on said malware.

If it is really this easy, how do you prevent this from happening? Several things make the malware's job more difficult. Some of them I've taked about how to get around, but they should still be in place.

Network Layer:
Client Workstation Layer:
Server Layer:
Database System Layer:
Notice I said more difficult, not impossible. A knowledgeable attacker, with a real desire to break into a system, will find a way to do so. The goal is to make it as difficult as possible while still being reasonable in budget and in functionality for the organization. An attacker who isn't specifically going after a certain company (such as what happened to Valve for Half Life 2) will likely move on to a much easier target.


Technorati Tags: | | | | | | | | | | SQL Server Security

Copyright © 2002-2014 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.