Last week I wrote about Gootkit’s futile attack on ASafaWeb and then a funny thing happened: Suddenly my Google Analytics keyword results become very Gootkit-centric:
I see this as meaning either there is a lot of interest in Gootkit at the moment or there is not a lot of information available on what it is. Or both. Interestingly though, the activity appears to have ramped up right about the time of my initial post. The search results all turn up results in late September this year including Gootkit auto-rooter scanner – hello, Gootkit auto-rooter scanner and the log files for weee-recycling.com (c’mon guys, don’t put your logs on public display!)
Let me try and both answer what it is and provide a bit of info on some anti-Gootkit defences.
What is Gootkit?
Let’s look at it in two parts. Firstly, Symantec reports it as a Trojan horse, or in other words a piece of software which purports to do something innocent yet in fact has evil intent. Once Gootkit infects a host then it can begin performing malicious activity which is the second part of the problem.
Regarding that second problem, Symantec reports that Gootkit can act as a botnet that can then perform activities including:
- Injects arbitrary JavaScript code into HTML files
- May modify content in an FTP server, including listing, uploading, and deleting files
What this means is that Gootkit can strike you in a couple of different ways, either by infecting your PC or attacking your website. The mitigations for both attacks are quite different and whilst I want to focus on the second, let’s just recap quickly on defending against the first.
How do I protect my PC against Gootkit?
This is the usual 101 of protecting your PC against the baddies:
- Don’t install – or even run – anything from an untrusted source. This includes directly off websites, files received by email and especially USB sticks you find lying around in the parking lot!
- If files or links are sent from a trustworthy source but appear out of character, validate their authenticity with the sender before doing anything with them. If your boss posts about Justin Bieber getting a boner, you probably want to approach that one with caution.
- Always run a virus checker and always keep the definitions up to date. You can do this for free on Windows with Microsoft Security Essentials or pay for the likes of McAfee, Norton, Kaspersky, etc.
- Use a firewall. This may consist of features built into the tools above, the native Windows Firewall, the firewall features of your router, or a combination of each. Point is that you don’t want traffic coming in or going out over any old port or protocol.
- Backups – do them! Do them frequently and preferably do them offsite with a service that can also version the files so you can roll back if your valuable docs get corrupted. My solution is still working beautifully.
There’s some more detailed info at the bottom of the Symantec article which is also quite useful. With that out of the way, let’s get onto web app security.
How do I protect my website against Gootkit?
There doesn’t seem to be a lot of info available on Gootkit so I’m going to need to make some assumptions. The behaviour that I observed in the ASafaWeb attack was lot of GET requests, but then in the M86 post they clearly show attempts to FTP into remote servers.
The other thing clearly visible in the M86 post – and keep in mind they had Gootkit in captivity so they could monitor its behaviour – is that infected machines form part of a botnet which takes instructions from a control server. But firstly, here’s a bit of botnet 101 from Wikipedia:
A botnet is a collection of compromised computers connected to the Internet, termed bots, that are used for malicious purposes. When a computer becomes compromised, it becomes a part of a botnet. Botnets are usually controlled via standards based network protocols such as IRC and http.
The role of the control server is to orchestrate the bots to perform it’s bidding, which may include the behaviours we’ve observed above (attempts to FTP to a host or search for / attack webpages meeting particular patterns). Picture it as follows (the original image source on ZDNet):
So in the case of Gootkit, it could conceivably perform any task the control server assigns it. Clearly though the modus operandi appears to be attacking websites and injecting content into the pages.
One of the problems with protecting against botnets is that the traffic could literally come from anywhere. Ultimately these are innocents individual’s machines which are behind the attacks and as one commenter said on my previous post, attacks can easily come from totally different IP addresses on opposite sides of the world. One day it’s an infected machine in the US issuing the attacks, the next it could be somewhere down here in Australia.
Keep your framework versions up to date
Firstly, based on the attack patterns I saw against ASafaWeb, Gootkit is obviously very interested in PHP websites and MySQL databases. Pretty much every address it requested explicitly has “php” or “mysql” in the path.
In this case it’s looking for something specific; clearly the paths it’s hitting are predetermined. Often this will be to see if known vulnerabilities within a specific framework can be exploited. One thing OWASP talks about in part 6 of the Top 10, Security Misconfiguration, is to keep frameworks up to date. The first example scenario sums it up nicely:
Your application relies on a powerful framework like Struts or Spring. XSS flaws are found in these framework components you rely on. An update is released to fix these flaws but you don’t update your libraries. Until you do, attackers can easily find and exploit these flaws in your app.
Creating a website is a little like having a baby in this regard – responsibility for its health remains looooong after it begins life. Once a known vulnerability is published, you need to act decisively. PHP has had 5 framework updates this year and if you’re not staying abreast of them, you’re vulnerable to whatever bugs or security flaws they addressed.
The thing to remember here is that updating frameworks to current versions is not just about having the new and shiny (something those who don’t know any better have accused me of in the past!), it’s also about protecting your site, your data and often your reputation.
Use strong passwords and protect them appropriately
Over on the Webroot blog, they talk a little about how Gootkit has been observed compromising websites:
It connects to Web servers using stolen FTP credentials, and if successful, modifies any HTML and PHP files with extra code.
This should (hopefully) go without saying, but weak passwords and / or poor storage mechanisms for them leaves you very vulnerable. If your PC does become infected it’s not going to be a hard task to locate plain text passwords on the file system and have them extracted and sent off to the botnet controller.
Use a good password manager and ensure your passwords aren't memorable. But of course this isn’t fool proof – key loggers combined with the ability to retrieve the keychain can upset the applecart very quickly but it’s a darn site better than storing them in a Word doc or Outlook notes.
This last point should also go without saying, but clearly the very first thing you want to do if your site is compromised is change any passwords related to the site as an absolute matter of priority. Don’t even bother to start fixing things if the door is still open.
Don’t use insecure transport mechanisms for publishing
It’s not clear whether Gootkit can exploit this vector or not, but certainly transferring your data – and particularly your credentials – around the web in plain text is not a smart move. For example, when you publish via FTP your credentials are sent in a raw, unencrypted fashion. If anyone is sniffing network traffic between your machine and the host or even capturing packets locally as they move through your NIC, you’ve got a big problem.
So the answer is that you’ve got the likes of SFTP which is very frequently supported by web hosts or other secure protocols such as Web Deploy over HTTPS by Microsoft. Also, don’t forget the database – either use a VPN client to the host (assuming they support it), or investigate other secure protocols depending on your DB of choice. The point is that neither credentials nor data should be sent across public networks in the clear and doing so leaves you vulnerable.
Logging and notifications are invaluable
The only way I discovered the Gootkit attack was that ASafaWeb told me about it, or at least elmah running on the site did. With no notification service it never would have been raised to my attention and with no logging I would not have been able to inspect what actually happened. Having both of these is invaluable.
Naturally the choice of tool will differ by web framework, but here’s the sort of logging I’m talking about:
Once a “security event” does happen, the ability to perform some sort of forensic investigation can be absolutely invaluable. This includes the ability to see what was attacked, when it happened and where the attack came from. It allows you to piece the events back together to get an understanding of what went on and more importantly, how to recover from it and how to avoid it in the future.
Now I’m not saying elmah is the perfect tool for the job – far from it – but it did provide me with invaluable information and adding it to your ASP.NET website is literally a five minute job. In a perfect world, you’d look at a dedicated web application firewall which would not only provide significantly more logging but would also employ active defences against an attack.
Have a plan to minimise your RTO
So the worst has happened; you’ve been breached, your data has been exposed and manipulated plus your HTML pages are now full of iframes propagating the nasties out to visitors of your site; what now? This is where we start talking about RTO:
The recovery time objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.
In a nutshell, when everything hits the fan, how quickly can I get back up and running? On the data side, this would normally be a question of how accessible are backups of last known good versions of the data (not backups of corrupted versions). This is usually a question for your host or IT group’s disaster recovery plans (i.e. backups may need to come from offsite), and then your ability to integrate these back into the production environment. I say “integrate” because there may well be data collected since the breach which you need to retain. Having the tools available to rapidly compare and migrate this data (SQL Data Compare is a good place to start) can make all the difference when you need them in a hurry.
Of course restoring data may also apply to the web layer, but in the case of Gootkit, in all likelihood you’re going to need to redeploy website assets such as HTML pages. At a bare minimum, you want to be able to pull the same version out of source control as was previously in the live environment (you do use source control, don’t you?) Preferably, you want a continuous integration environment which allows you to redeploy the same version at a click of a button. It’s this last point that made me a bit cocky about ASafaWeb because AppHarbor provides the CI environment to automate this – redeploying the app is a cinch.
Remember: security in layers
So your frameworks are up to date and your passwords are well protected. Nice start, but that’s not enough. Think of software security as a practice of continually applying layers of defence at various levels throughout the application. Clearly one of these layers to use a strong set of credentials for administrative duties such as FTPing files, but what happens when even this fails? What happens, for example, if your host was storing these in plain text somewhere and they were compromised?
A last line of defence for your data is cryptographic storage. This may be the asymmetric encryption of sensitive customer data or the hashing of passwords using a strong hashing algorithm and cryptographically random salt. The point is that the total compromise of persistent data need not mean that sensitive info exposed, at least not without making it extremely difficult to get at.
Summary
This is really all just good, common sense web security practices and whilst it will help fend off Gootkit, all of the above is equally relevant to threats from other sources. The point I like to make – and admittedly I’m a little biased – is that software security needs to be approached as a feature and built into the process from day one. When you start tackling it retrospectively and particularly when you only start paying attention after a breach (which is very often the case), then you’ve got a big problem to deal with which in all likelihood could have been easily been avoided.
This last point is worth dwelling on for a moment because the message clearly doesn’t get through to many developers and organisations. The Gootkit auto-rooter scanner is a perfect example of just how indiscriminate website attacks are. ASafaWeb has next to zero public exposure yet it was still targeted by Gootkit. It wasn’t personal – it’s on the web so it’s a target. If you don’t treat every single publicly-facing asset (and don’t think for a moment that internal assets are perfectly safe), as something which will be continuously and unabatedly attacked and take proactive action to secure them, chances are you’ll be finding a post like this whilst trying to recover from a major breach. And that’s never fun.
For more reading about general web app security, make your way through the OWASP Ten Most Critical Web Application Security Risks or if you work in the .NET space, try my series on the OWASP Top 10 for .NET developers.