1

Working on cleaning up a site compromise for a client. Leaving aside that the site is using bunch of custom CodeIgniter code written by someone who had no concept of security, I've ran into a roadblock and wanted to see if some other IT Security guys could sort of double check my work flow. Additionally the site is hosted on DreamHost who seems to have had some sort of trouble with Pharma Spam redirect in March, so I'm not sure if the issue is my clients site, or DreamHost got pwned and won't pony up to it.

Essentially what is happening is upon inputting an ORDER BY statement into the search parameter of the site URL, a file titled quickstart.dat is placed in the user's home directory. This dat file is populated with the exact HTML of the pharma site, so that afterwards when ever using one of the anchored links on the site the HTML from this dat file is loaded. It does NOT redirect to the pharma site, it creates local web content which in turn links to the Pharma site.

I can replicate this every time after deleting the quickstart.dat to restore normal functionality, than use the ORDER BY statement and start the whole process over. This leads me to believe I should be searching through the MySQL databases looking for malicious code inserted into the tables which are referenced by the search.php file?

UPDATE: OK so I found the issue as far as I can tell. Going through one of the index.php files something caught my eye. There was a require_once statement pointed towards a pdf file in a tmp directory. Pulled that pdf down, put it through an online sandbox, indicated it was actually PHP script. When I changed the file extension and opened it up in notepad, blamo, base64 code everywhere. So I deleted the PDF and removed that line from index.php file, normal functionality is restored. Thanks for everyone who steered me away from the database.

Improve this question
3
  • 2
    This could be rather in overwritten php code which is using orderby. If you record complete $_SERVER and $_POST and $_GET for each request, you can trace this via logfile while it's being injected remotely and filter it out at least on php level, so on the top of index.php it would scan all variables and check if the data type is OK, that there are no banned characters and that there is no php code, bash command, UNION injection etc, and run check thru all the code and look into all lines with a editor wrapping the lines where it is on the source tree.
    – Andrew Smith
    Commented Jul 22, 2012 at 19:50
  • which log file should I be looking for in this case? straight HTTP request logs?
    – Stev0
    Commented Jul 22, 2012 at 19:59
  • In normal logs you can find GET requests, if these are POSTs, it might require coding to log them and filter them.
    – Andrew Smith
    Commented Jul 22, 2012 at 21:07

2 Answers 2

Reset to default
3

There are just so many things that could have happened. I'll try and list all ideas I have of what could possible have happened.

You could try the following:

  • Check the .htaccess file if it contains anything
  • Check the routes file in codeigniter which handles redirection, it is located at /application/config/routes.php and check if there are any re-directions in there.
  • search through all php files using the command line and look for "base64_decode("
  • Delete the .dat file perhaps?

You could also try and search for files with large hashstrings that are usually used to obfuscate code, enter the following code in shell:

find ./ -name "*.php" -type f -print0 | xargs -0 grep '[a-zA-Z0-9]\{400\}'
Improve this answer
3
  • Yah I've deleted the dat file and searched for base64_decode, havn't found anything. Also checked htaccess, nothing. I'll check that route.php file.
    – Stev0
    Commented Jul 22, 2012 at 20:08
  • Check the .htaccess if its using something like mod_rewrite or redirecting to the pharma site. You should also look for eval() which is also used a lot for backdoors
    – Kush
    Commented Jul 22, 2012 at 20:10
  • routes.php is clean. the find code you posted above came back clean. Only large block of text is from another domain, and its a CakePHP test case. grepping for eval(base64_decode( is also coming back clean.
    – Stev0
    Commented Jul 22, 2012 at 20:16
1

I'm sorry to hear of the trouble. While we have been aware of this and similar hacks, there has been no widespread hack specific to our servers; systematic hacks designed to exploit known vulnerabilities in web software often share other characteristics like the files they keep malicious data in, and can usually be avoided by keeping the install and all related themes/plugins completely up to date. CodeIgniter 1.x did have some critical vulnerabilities that may explain it if it were that old, but it could have been any number of things. We may have some specific documentation prepared in the future, but in the meantime please feel free to contact support directly for a full diagnosis if you come across this or any similar hack again!

Improve this answer

You must log in to answer this question.

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