6

I have a client who's asked me to try and analyze a site for vulnerability.

What's happening is, every weekend or so, on field of one record of one table in the database gets changed to the same thing every time. From Jewelry to Jewelery <a href="http://[**REMOVED-FOR-SF**]/viewPress?press_id=407">[**REMOVED-FOR-SF**]</a><a href="http://[**REMOVED-FOR-SF**]/[**REMOVED-FOR-SF**].html">[**REMOVED-FOR-SF**]</a>. The fact that it's always the same record makes me think it's some sort of automated script, but if it is, I can't find it.

The following has been accomplished:

  • Fixed SQL injection vulnerabilities
  • Prevented PHP execution in 777 directories
  • Changed the database password after every fix
  • Changed the CMS password after every fix

What's the next step?

Matt Alexander
  • 250
  • 2
  • 10
  • 1
    Are you logging HTTP requests in the Web Server (Apache, IIS, etc.)? – gravyface Sep 13 '10 at 23:07
  • 3
    How are you *completely* sure that you've eliminated all SQL injection vulnerabilities? – Hello71 Sep 13 '10 at 23:09
  • 2
    Are you totally sure that this isn't being done by code on your own site? – John Gardeniers Sep 13 '10 at 23:17
  • @gravyface @Hello71: I've set up a timestamp field in the database that told me when that record was edited. When it was again, I cross-referenced it with the Apache logs and didn't find anything that looked weird. – Matt Alexander Sep 13 '10 at 23:23
  • @John: Well, I didn't write it so I guess it's a slight possibility, but there isn't really too much write access except for from within the CMS, which I believe is secure (changed passwords; SQL inject fixes). – Matt Alexander Sep 13 '10 at 23:25
  • @mattalexx, it's worth searching the web site files for parts of that string. It's easy enough to do and just might find the problem. – John Gardeniers Sep 13 '10 at 23:30
  • You mention DBS and CMS in the same question. Are you sure this isn't just a comment field in the DB from the CMS? If you think the server has been hacked, that server can no longer be trusted and can't really be *cleaned* so to speak. – GregD Sep 13 '10 at 23:40
  • is there no data-logging in place so you can track down the user that made the change? You could also try modifying the stored procedure relevant to update transactions so it log activity, or even add a table trigger to log activity. – Hardryv Sep 13 '10 at 23:44
  • I would absolutely not trust the database at this point so your timestamp fields should be disregarded (until proven otherwise). Is the Webserver (I'm assuming Apache) and MySQL running on the same box? – gravyface Sep 14 '10 at 01:17
  • Well all of this is said and done, please do the internet a favor and e-mail the abuse contact for opendns.com to let them know that one of their clients is abusing *your* service to spamvertize the reputationdefender.com and lead411.com domains. – danlefree Sep 14 '10 at 07:20
  • @John Gardeniers Yes, I did that. Grepped the whole site and didn't come up with anything. Even searched for fractions of the strings involved and raked through a bunch of stuff.. – Matt Alexander Sep 15 '10 at 11:34
  • @gravyface, No they are on separate machines. Yes, Apache and MySQL. – Matt Alexander Sep 15 '10 at 11:35
  • @danlfree, What steps did you take to get to opendns.com? – Matt Alexander Sep 15 '10 at 11:40

6 Answers6

5

The attacker most likely doesn't need to know the password to execute the change - here's how I would address it:

Locate the query function wrapper for your CMS and update it to log to a file and/or send an e-mail whenever a regexp on the query string matches your spam string - include any and all relevant server and CMS variables which may help identify the source of the issue.

Note that you can call debug_backtrace() on PHP 4.3+ to isolate include files if this could be the work of a malicious plug-in.

danlefree
  • 2,923
  • 1
  • 19
  • 20
  • Unfortunately, the site uses direct calls to `mysql_query()` all over the place, but I think this sounds like a great direction to head in. It's not really a big deal to write a wrapper for `mysql_query()` and point everything towards it. – Matt Alexander Sep 15 '10 at 11:38
2

Probably a leftover injection attack - can you set up a DB trigger to let you know when the record changes again? Then correlated that with your webserver logs - should lead to the culprit immediately.

Also ensure you are logging as much as you can get away with (referrers, etc)

gabbelduck
  • 329
  • 1
  • 3
  • I've set up a timestamp field in the database that told me when that record was edited. When it was again, I cross-referenced it with the Apache logs and didn't find anything that looked weird. – Matt Alexander Sep 15 '10 at 11:07
0

Have you looked at the SQL server yet? Maybe there is a script running there or some procedure is setup to make an update that was done for a legitimate reason (or even just testing purposes) and has since been forgotten but is still getting triggered. Likely has some hard coded values like that typo.

Shial
  • 1,017
  • 1
  • 9
  • 14
0

Did you install a link generator in your CMS? Some sites automatically link to generate backlinks to blog posts. This looks like the same sort of thing. Check your CMS's extensions and see if there's something in there.

0

How heavily loaded is the site? Perhaps a packet capture could be an option, showing you anything and everything that came through from the outside world when this changed. This will at least let you know if something internal to the server is changing things, or where your vulnerability is.

Ryan Gooler
  • 352
  • 1
  • 9
0

You could setup modsecurity and add a rule to log the POST data whenever it sees the misspelled version. If it is someone editing it, or a SQL injection it should get logged.

mfarver
  • 2,576
  • 14
  • 16