5

Recently I was contacted by a person saying that they had found a vulnerability in my site. They were able to prove it, by sending me a list of my own databases (some of which had been created but never used or referenced by anything), a full directory listing of my webroot (not as impressive, but it did include hidden files), as well as contents of configuration files for MediaWiki and a sample from one of the databases. It seems that they have been able to drop a database, as well as run a mass update on another to introduce spam links on the Wiki.

I appear to have vexed them by saying that I don't use bitcoin and therefore cannot pay them for any "report" on how they are doing this - not that I actually want to, of course.

I really need help in figuring out anything I can to stop this attack before any further damage is caused - I apologise if this is not the correct place for such things, but it's the first thing that came to mind. Any advice, ranging from stopping the attack to possibly turning the tables entirely would be very much appreciated. If you need more info, please ask!

Improve this question
1
  • 1
    Before you pull the plug on your server, access your website one last time from a live CD environment and download all the HTML, JS and CSS files for forensic investigation as it may contain important clues that you won't find on the files in your webroot.
    – Question Overflow
    Commented Dec 27, 2014 at 4:33

2 Answers 2

Reset to default
9

Do not try to turn the tables.

Simply disconnect the site from the internet, take forensic copies (if you want to try and find out exactly what happened, or pass into to law enforcement) and then wipe and rebuild from scratch.

As the odds of tracking down the perpetrators are incredibly slim, I would suggest not wasting your money. Just wipe and rebuild, and look to garden your installation before you connect it online again. This should include latest patches for platform, OS, applications etc., config options and general hardening guidance.

Improve this answer
1
  • 2
    Agreed. Most important thing is to take the site offline first so as to prevent further damage.
    – limbenjamin
    Commented Dec 27, 2014 at 2:55
3

This is impossible to answer completely without knowing anything about the site or having permission to test it. I assume the site is "pokefarm.com"?

Here is a general overview of what I would do if I were you.

You've got some learning to do about secure coding and security tools, and trying to secure a site while it is actively being attacked will be frustratingly ineffective. You don't know what level of access they have or anything.

So, take the site offline and build it clean and run it in a test environment / virtual machine until it is fixed. I could argue that it is irresponsible to leave it up if it is compromised as it could be used to attack others.

Look in the web server logs for how they might have got in and where they might be coming from. In the logs look for database errors, file not found, and any other mysterious behavior. (Rory Alsop's suggestion to take a full forensic copy is a good one)

To fix:

  1. Review the OWASP Top Ten. Try to find locations in your code or configuration where you may have introduced some of the vulnerabilities described there. For example, locations where you failed to properly sanitize user provided parameters. Fix those locations.

  2. Run an open source security scanner against your app. (ZED,W3AF,SQLMap) SQLMap is good for SQL Injections. SQLMap will be time consuming for you unless you can narrow down where the bug(s) is/are. W3AF could help narrow down the locations.

  3. Fix the bugs you found with the scanner.

  4. Install mod_security for your apache to block common web attacks.
  5. Put site back up.

Ongoing maintenance:

Watch the logs. Have a way to be alerted when certain hidden directories and / or database tables are accessed via the web. Log other security related events (role changes, new users, failed logins, successful logins)

Improve this answer
2
  • It's actually the "side-stuff", such as the support centre, wiki etc. that's been affected. All of that stuff is hosted on a clustered hosting package completely separate from the main site - which is lucky, because if they'd gotten the main site... It also means it's specifically something in a sub-site that is vulnerable, which helps a bit.
    – Niet the Dark Absol
    Commented Dec 26, 2014 at 23:50
  • 1
    @NiettheDarkAbsol well it's possible that the attackers have access to the main site as well but are keeping it secret to give themselves some kind of strategic advantage. If the side sites and main site are on the same server, or different servers that have easy access to each other, I think it's a safe assumption that once one of them is compromised, all should be considered compromised.
    – David Z
    Commented Dec 27, 2014 at 7:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .