I am not sure how it happened, but somebody (or some robot) managed to insert some malicious code into my wiki. Random people were receiving emails with links to URLs within the wiki and when they followed the links, they were redirected to malicious pages.
The URLs within the wiki resembled these:
- sindark.com/wiki/images/thumb/c/c4/Labelled_overview.png/kmdlss.html?dhe=fh.dhplh&zazssr=fe.dh&ahf=jgtf
- sindark.com/wiki/images/thumb/c/c4/Labelled_overview.png/kmdlss.html?er=edo.dhega&rdpy=fm.eza&zso=fbcb
- sindark.com/wiki/images/thumb/c/c4/Labelled_overview.png/kmdlss.html?vbh=egr.mdjgp&fvsa=fm.dhr&rdvh=ufrv
I removed the whole Labelled_overview.png folder, which it shouldn’t have been possible for a wiki user to upload, given that I had my wiki set up to only allow logged-in users to make edits. In addition to removing the folder, I have also updated MediaWiki to the newest version. I have also set up DreamHost’s system for automatically updating MediaWiki when new versions are released, though that risks breaking extensions that are not compatible with the new software and possibly causing other problems.
I still don’t know how the malware got introduced (perhaps through a vulnerability in an old version of MediaWiki or one of my extensions), so I am keeping the whole wiki inaccessible for now.
My apologies to anyone who followed one of the malicious links.
The whole incident shows one of the annoying things about the internet. Whenever you set up a content management system like WordPress or MediaWiki, you have to be aware that there will be efforts to compromise it. As such, you need to keep it well-updated and keep an eye out for malicious activity. You can’t just set it up and forget about it.
This is what was in the offending folder. Very antisocial!
I am seeking advice here.
Troubleshooting Hacked Sites
Hello,
During a recent security scan we have identified that one or more of your hosted sites show signs of being compromised as they are hosting known, malicious web-based backdoors. Specifically, the following file(s) have been accessed by intruders and have been associated with unsolicited bulk email, denial of service or other abusive activity:
We have identified the following known backdoors under your account:
/home/sindark/sindark.com/wiki/images/thumb/c/c4/Labelled_overview.png/prlinks.php
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/googlebot.php
We have identified the following files associated with known spam activity, the attackers use these pages to direct people to malicious URLS:
/home/sindark/sindark.com/wiki/images/thumb/c/c4/Labelled_overview.png/kmdlss.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/cvlr.php
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/mfkgf.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/irrk.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/tkjvfl.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/iiis.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/xxxxr.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/mskgf.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/thjfle.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/mmdl.html
/home/sindark/burycoal.com/blog/wp-content/themes/thesis_1_6/custom/cache/pfng.html
We have disabled the page(s) in question (via adjusting permissions on the files, e.g.. chmod, or backing up the file first renaming it to “filename.INFECTED” and cleaning up the injected code) until you are able to address this matter.
The existence of these pages on your website(s) is likely a sign you have been compromised. We completely empathize with your problem — having a site hacked can be a frustrating and stressful experience but we hope that this notification helps prevent this matter from being a serious one. We’re here to help but we need your assistance first as there are some actions we’re not able to take on your behalf as they involve changes to software versions and files under your account. To that end, we highly recommend that you take the following steps:
– Update any 3rd party software under the account, including content management systems, gallery software, weblogging tools, etc. Be sure to use current, secure versions and keep them up-to-date.
– Update any plugins and/or themes on your sites (Recent attacks against websites have targeted vulnerable software such as timthumb.php which is included in some wordpress themes, separate from the core files)
– Check your website(s) files for any signs of tampering (file timestamps show recent editing) or files you did not upload yourself and remove them. Looking at the reported files above should give you a good starting point.
– Check your website(s) files for any 777 directories, (e.g.. a directory that allows anyone on the server to write or edit the files in the directory; these permissions will look like rwxrwxrwx via the command line)
– Change your FTP password(s). Be sure they are at least 8 characters in length and do not contain English words. Random numbers and letters work best.
If you have any questions, please feel free to reply to this email and we will be more than happy to assist you with securing your sites.
Sincerely,
The DreamHost security team
I have removed the listed files. I have an encrypted copy if anyone wants to do legitimate research on them.
Now, I need to figure out how they were placed on the server in the first place…
There are a multitude of ways such malware could get in place. It could be a vulnrability in your web server, it could be a vulnrability in another web application. (For example, I’ve heard people complain before about getting attacked via a vulnrability in word press, and then the attacker inserts php code in MediaWiki files). It could also be a vulnrability in a MediaWiki extension, or even MediaWiki itself (However most security vulnrabilities reported in MediaWiki are XSS type vulnrabilities, or of the form Allow user X to block someone when they’re not supposed to be able to. I believe you’d have to be using a very very old version of MediaWiki for it to have a known vulnrability allowing someone to write a php file to disk [OTOH as a MediaWiki fan I could be biased ;)]). I personally think what most likely happened was there was a vulnrability in something else, and the MediaWiki image directory was the only directory writable by the webserver, so that’s where the attacker put the evil php file (Of course that is pure guess, I have nothing whatsoever to back up that theory).
Also, I personally think its unlikely the evil file was uploaded through MediaWiki’s upload facilities, since its in the thumbnail directory (if someone managed to upload it using normal upload facilities of MW, it would be in just the image directory most likely.). Also MW does many checks to prevent html/php files from being uploaded. So I would more likely conclude some other means was used to upload the file.
In general we strongly recommend disabling php execution in the upload directory (Or any other directory the web server has write access to), so that if someone does manage to get an evil file in one of those directories, it can’t be executed as php, as was done in your case. See Manual:Security#Upload_security
p.s. I Should note I’m not a security expert by any means, so take any of my opinions with a grain salt.
Bawolff (talk)13:00, 22 June 2012
WARNING: Malicious code. Do not run this code! Do not install this sort of code on the web servers of other people!
For the sake of education, here are some neutered image files showing the contents of the malware:
Whatever you do, do not use optical character recognition to turn these back into text files, then upload them to a web server and execute them!
Backdoor scripts will vary from 100s of lines of code to 1 or 2 lines of code. The listing below is for a very common backdoor script called “FilesMan”. Typically backdoor scripts are written in php.
How to prevent your site from getting hacked. How to repair a damaged site. Website security precautions.
Website security: How to find backdoor PHP shell scripts on a server