Software architect and Microsoft MVP, you’ll usually find me writing about security concepts and process improvement in software delivery.
What elmah does is keeps a nice little log of all the things that happen on your site which shouldn’t; internal server errors, illegal URL formats and most importantly in this context, page not found errors (the classic HTTP 404). You can also log your own custom messages as well, but that’s another story. Elmah makes all this wonderful information available via a custom handler which gives you all the details right within your site (don’t forget to secure this!)
Here’s what I awoke to:
There are two particular points of interest here:
- The paths being requested: elmah is saying no controller exists for these (it’s an MVC app), but the interesting bit is the actual paths themselves. You’ll see lots of references to “sql”, “php” and “admin”.
- The time of each request: All of this happened within the space of about a minute. Something is clearly not right here.
Actually, elmah gives you the whole YSOD with stack trace but that’s not very interesting when it’s a 404. The bits above are all the server variables which includes the interesting items you’ll see highlighted, most notably that the user agent is the “Gootkit auto-rooter scanner”. After having a bit of a laugh (“root” is interpreted a bit differently down under), a quick Google reveals all about what Gootkit attempts to do. Essentially it wants to break down the door to your site and infect your pages with redirects to nasty locations.
Of course the other piece of information we get out of all this is the IP address from where all the excitement originated. I couldn’t get this to resolve to a geo-location, but even if it did, it’s quite possibly some poor innocent individual who has just taken a hit of malware.
What I thought was most interesting about all this is that not only has ASafaWeb not launched, I’ve not even published links to the website. Actually that’s not entirely true because it’s on the Twitter account but that’s it. The point is that Gootkit found an altogether obscure site that nobody uses and hammered it with malicious requests. Keep this in mind the next time someone claims their site is “safe” because nobody knows it’s there!
But the other thing I thought was interesting – and this is the crux of this blog post – is that this episode didn’t worry me in the least. Here’s why:
- I don’t have any secrets I need to protect. The best way to keep a secret is to never have it and I’ve consciously decided not to keep secrets for this very reason which includes not keeping track of which sites are being scanned.
- The one secret I do want to protect (ok, so there is just one), is the password of my beta testers. I’ve well and truly taken my own advice here and used ASP.NET’s membership provider which implements cryptographically random salts before a SHA1 hash is created. Edit: this should be SHA256 - the default hashing algorithm changed to SHA256 in .NET 4
- In an absolute worst case, say the apocalyptic destruction of ASafaWeb, I can redeploy to AppHarbor in about 5 seconds. I’m going to talk more about these guys in the near future but I can’t tell you how reassuring it as to have such a powerful, immediate ability to redeploy.
- I know exactly what Gootkit was trying to do to ASafaWeb outside the expected bounds of operation because I have the elmah log. No log = no ability to do this.
- Anything publicly accessible is a target – be ready to get attacked from day one.
- Know your enemy – make sure you have some form of logging that you can easily access and preferably be automatically notified about.
- Don’t keep secrets if you don’t have to – it’s the best possible way not to disclose them!
- Be able to redeploy in a heartbeat – its awesome assurance for when things do go really wrong.
10 comments:
Oh wait, over the years you'll start to actually collect a list of all these bad requests using your ELMAH honeypot...
this way you can actually have a site that scans for vulnerabilities that is actually _collecting_ new ones all the time from unwitting script kiddies....
Queue Mr Burns key frame... EEEXXXCEEELLLEEEENT
I'm interested that you consider "apocalyptic destruction of ASafaWeb" to be the worst-case scenario. As a security guy, I'd have thought that a worst-case scenario would be more likely to include some of the more serious possibilities (I've listed a couple below). Redeploying an app is easy, but recovering from some of the other things that can go wrong can be far harder, especially if it damages your reputation among your users and / or wider audience. Technical problems are generally much easier to rectify than social ones.
* Exposure of password hashes. While salting helps, even a salted password isn't much use against a dictionary attack, if you have users who make the mistake of using a common password. Sadly, I have never come across an app that didn't have at least a few users like this - and those are also typically the users who reuse passwords.
Making the password hash very computationally expensive helps a lot (e.g. bcrypt); SHA1 is designed for speed & cryptographic security, not for protecting passwords). Even computational expense isn't enough to totally defeat a dictionary attack though - it just makes the process slower.
* Contamination of data (either via damaging the data [and thus rendering it useless], or by embedding something else evil in it). If you have a nasty on your page you don't notice, cleaning up afterwards isn't fun. Depending on how long the problem is in place, and what the implications are, you could potentially end up with some very unhappy users. While you *should* notice most such issues with your app, assuming that you'll notice everything immediately simply isn't a reasonable position to take, unless you're omniscient - and I doubt you're one of those developers who thinks this.
Troy I agree with your stance on it, but I think contamination of data is a Huge point to make emphasis on as one of the scenarios when things go wrong.
In that case, it's no longer a matter of how relevant the data you're storing is, but of taking over that data.
A site built and managed by a third party for a client was hacked after a few years it was online. Injected links and others were added through sql injection vulnerabilities that site had. So the site had multiple offenses to security (including not html encoding that data), still those are the type of sites that are usually hit by these bots.
The issue with that is that the data was added over time. By the time they had noticed they had:
- served a lot of those malicious links
- served malicious files / separate auto discovery hack they were hit with
- built up over 200k of those malicious links and info in a couple tables
In their case they could throw away those tables, but not every site can do that. Just like you said, a fresh svr/deploy was done from the sources. I agree that's key, I ran a comparisson just to check, and found a couple other files lying around that weren't yet being used in active attacks. And then in such an awfull scenario, you can't even be sure if a vulnerability at the server level was hit.
Just like you've been pushing for, companies really need to pay attention to security. Scenarios like the above happen for the classic factors: sql injections, no use of html encoding, no monitoring / logs, third party components/themes/others not mantained ... worst, not even used and still there with all those security issues unpatched.
Quite different than your scenario of course. That client and the third party that was managing their server/development, wouldn't even had noticed if the hosting provider didn't notify them they had the issue ... because the traffic was so much their internal network was being affected by all the access to all that injected data in the database.
To be clear, it's not the intention of this post to talk about the ramifications on data, it's really about those last four bullet points. There are numerous other locations throughout this site that go into extensive detail about practices for protecting data and I know you and I have discussed some of them in the past.
Your example is a good illustration of what happens when you have no ability to alert or even log malicious activity. Now elamh only does that to a very small degree and is clearly no substitute for a dedicated intrusion protection system, but the point is that with such easy configuration there's no excuse for not having some form of easily accessible logging and preferably also notification when this sort of activity occurs.
I have a big problem with these crack head, I had to shut down my web sites, what can you do, they keep trying from different IP-addresses
I must also raise concern surrounding usage of the built in ASP.Net SHA-1 Hashing as even when salted not only can easily be run against dictionary attacks but more worrying is SHA-1 is open to collisions (think this happened in 2005?)
I usually override the membership provider and use SHA-256 or something stronger than the built in FormsAuthentication MD5 or SHA-1 hashing
You can secure your site with the expectation that you'll be constantly and repeatedly attacked - that's the nature of the internet. It's unfortunate you needed to shut sites down, obviously there were pre-existing vulnerabilities which were successfully exploited.
You can forget about any sort of IP address filtering as these attacks are often launched from compromised PCs.
I'm going to agree then disagree with you Doug :)
Being very academic about it, SHA has been well and truly surpassed by adaptive hashing algorithms the likes of bycrypt. The computational expense of hashing (among other benefits), puts them ahead of the pack and there is reams of information about the advantages (Sam Saffron's question on the Security Stack Exchange site about Do any security experts recommend bcrypt for password storage? is a good place to start).
Being pragmatic, we're just not seeing properly salted hashes of MD5 or SHA1 being compromised (and please, if anyone has info the contrary, I'm genuinely interested in seeing it). All the big breaches in recent times have either stored passwords in plain text or with no salts at all. Last month @KevinSMcArthur laid down a challenge to show that salted MD5 is inferior to bcrypt by breaking an MD5 hash for which he provided the salt. As of this morning, it stands unbroken.
I will always advocate using the strongest hashing algorithm practically available and on that basis you need not stop at the higher SHA derivatives, there's always the likes of BCrypt.net, I just happened to choose the one of the box in this instance. But I do think people tend to get a little academic about the issue, that's all.
Since this spider is dumb enough to identify itself as malicious software, wouldn't blocking the User Agent work?
Possibly, assuming it always adheres to the same UA pattern. Of course this is something you'd want to do in addition to securing the app itself.
Post a Comment