Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By zwhalen on
Hi.
I wasn't sure where to post this, so I hope it's okay here. I'm still working on my drupal installation, so I check my logs frequently and the other day I found a series of what seem to be fishy php errors. They all reported /cron.php as their location and originated from an unfamiliar IP address. Here're some highlights:
Wrong parameter count for min() in /mysite/public_html/includes/menu.inc on line 272.
array_keys(): The first argument should be an array in /mysite/public_html/includes/menu.inc on line 272.
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: SELECT name FROM users WHERE uid = in /mysite/public_html/includes/database.mysql.inc on line 66.
That last one went 5 times in a row within 1 minute. I'm not sure what's going on, but it looks like something tried to pass arguments and SQL queries through cron.php, and judging from the query, they appear to have been looking for a login name. They appear to have failed, but I don't know that it would even log it if they had been successful. I really don't know enough to decide if this is sinister or not, so can anyone offer some insight?
Thanks,
zach
Comments
I was hacked
I was actually hacked late Monday night. I'm still trying to sort it all out, but he replaced my index.php file, letting me know that I was hacked, and sent about 28,000 spam emails through drupal using apache@localhost. It does not appear that he got into my system in any other way than through my 4.6.x drupal installation. I was running, 4.6.0, so I updated everything to 4.6.5 and am still trying to figure out what happened and how it happened. My immediate suspicion was that he did it through cron.php somehow. I will post more when I know more.
xml-rpc vulnerability.
Please sign up for the security list. 4.6.0 had a vlunerability that was annouced last year. 4.6.5 is the best to be running.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
you're right
I do need to sign up on the email list. There is a block on the security page, but there is no field for email, is there another page that you know of that I an sign up on?
Thanks for your help. I didn't post my problem originally because I figured it was my fault for running 4.6.0 (for some reason i though I was running at least 4.6.3). I've been battling this spam issue for a while now, so we'll see if this fixes it. I'll post a new issue if I have any further problems
Thanks again!
Jeremy
Click My accounts on the
Click My accounts on the right, then edit, then my newsletters
Choose which ones you want. :)
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Check your PHP and webserver settings.
Hey Zach,
Check your php and webserver settings as well.
In particular, whether PHP is allowing for defacto global variable assignments. Ie, if someone sets something like:
PHP won't automatically setup a variable alpha containing "beta" and a variable beta containing "alpha".
I think the php option to disable is: register_globals
If this is already disabled, then not sure what the hole might be. Could depend on the version of Drupal you're using, the webserver permissions on files/etc, and/or other php configuration options. :/
Logging
Regarding logging whether attempts were successful, you could put your backend database into debug mode to log debug output so that failed and successful attempts are logged as well. Could take up alot of space though and impact performance though.
The other option would be to increase logging on the webserver, so that entire GET/PUT/POST queries are logged.
Perhaps its time for someone to create module that monitors the admin logs for issues like this and auto-blocks IP addresses?
Well, I checked
Well, I checked register_globals, and its definitely off, so if that's how the hack was supposed to work, then I guess I'm safe.
Anyway, it turns out the IP address is actually my site, I just wasn't used to seeing it, and the request in to cron.php was the regularly scheduled cron job arriving at the scheduled time. I still don't know how it would have produced those errors, though, since it has worked fine every other time since setting it up (and each time since).
So if this is indeed a hack attempt, it might be deeper than sending information through GET to cron.php. It could also just be a random misfire or something.
server log
Don't know if it helps explain anything, but here's my server log for the moment in question:
It looks the same as all the other cron requests and there aren't any other requests to cron.php in the same vinicity.
Hmm... hiccups are the worst. :/ Btw, alot of SSH probings...
I take it that log message is inline with your other automated cron.php triggerings? Ie, cron.php is being called by a perl script(lwp-request)?
I've had hiccups on my own Drupal system, but not one where it was querying usernames in the error message. Some of them were when cron activated while I was trying to update the site at the same time.
Sorry the globals note didn't help.
Another thought would be to limit full/php code text entry on your site. My own site basically takes the BOFH approach: only admin creates/updates content and only approved comments show up on the system. Alot of comment spam floating around.
Btw, I'm noticing ALOT of SSH login attempts on my servers these days. Like the difference between a 3-10KB log notification to a 600-900KB log notification.
Nothing like a little judicious use of iptables against a /8 network range or three to quiet things down. Mostly coming from European countries and from US cable modem users. :|
cronning while updating
I was actually working on the site at the time, so it's possible, as you mentioned, that the cron coinciding with an update generated the specific errors, maybe. And the log message is indeed the same as other cron triggerings.
Thanks for the input.