Leave a comment
The original website in question was built up over a long time and I mean years and consisted of static content but as you can image there was a lot of it, and it’s used all the time.
Yikes - This is not good it was Horror and Panic, Ok that’s over getting on with the story.
Let’s break this down. This naughty site is on a different domain, which means that something on the original domain must be sending the user to evil sugar site. A simple trace confirmed this, when the browser hit the server for the good site it was being returned a “Permanent redirect” to this bad site.
A Permanent redirect is one that tells browsers and search engines that the site has moved and won’t be back and to forget where it was, Remember the hacker isn’t a nice person so they want search engines to update all the links they hold for the good site as well.
Post-mortem - how was this happening….
There was two bits to it. The first was a config change, and the second was some code that was added in.
Let’s have a look at the config first, they added a file called web.config – which contains configuration used by asp.net and it tells the server how to behave, it’s normal and very common, you would expect to see it. But what they did was to modify it to include a “rewrite rule” and they called it : “Protect files and directories from prying eyes” (someone’s a joker) – this rule basically said – for any request to any file send a file called “default.php” back instead; php is a scripting language that allows code to run and do stuff…. so any page request hitting the server actually made it run that script. It’s interesting the mix of technologies here.
This “default.php” file is the second part – Mr Evil; has tried to make life hard by encoding the file, all they achieved was a small delay because a couple of clicks and a website later and it’s all nice and readable.
I won’t bore you with the details, but it did all sorts, created files, directories and generally made a mess. But it was a simple case of deleting all these files and we’ve saved the day!
I admit to a bit of luck in that the site wasn’t written to use php, nor does it have any forms or any interactive code at all – just HTML. So, deleting these files was easy. However, this code did capture everything sent to it, which would include any forms completed on the real site had there been any so the risk was real.
Now the site is back, we don’t know the entry route, but the passwords have been changed anyway, it’s on shared hosting so it could be a server compromise instead so if it reoccurs it's a change of hosting provider which we might do anyway.
Hopefully interesting and useful, in today’s world everyone is at risk and we all need to take steps to protect ourselves.