My drupal is being hacked at delaflamme.org/site/

By different computers on 29 Mar 2005 at 16:48 UTC

Hi there.

First off I'll freely admit that I have extremely limited php and sql skills. I've installed drupal using my ISP's autoinstaller and it worked like a charm to their mySQL databases

I had been lazy about updating my drupal install on http://delaflamme.org/site/ , and some script kid took advantage of it. Somehow he injected about 50 new forums into my site.

So I upgraded my install to the current 4.5.2 version, banned the kid's IP address and reported it to my ISP, figuring that would be it.

Well, about two hours ago, it happened again. Different IP, different "owned" message, and only one forum created with the admin's permissions. The details make me wonder if it is one of the first kiddie's buddies, rather than the original teenager.

I'm posting here for several reasons: first, if these kids have found some new drupal exploit, you all obviously need to know about it. Tell me what parts of my logs you'd like me to post and I will, though I don't see anything that looks really useful.

Second, I'd love some help in stopping them. Any advice appreciated.

Oh, and for some reason after the 4.5.2 upgrade, authenticated users can't edit their own entries any more, except for through the admin interface. Thoughts?

Comments

watchdog

carl ditzler commented 29 March 2005 at 17:16

Do you mind sharing info from watchdog? Was the user registered and login? Did they use an admin login?

watchdog/admin

different computers commented 29 March 2005 at 17:25

I'm happy to give you the info you need.

The user is getting admin access spuriously. I'm sure that if he really had the admin password, he'd be screwing up the system more than just creating forums.

The forums being created appear as having been done by the admin. Here's the watchdog info, though it's pretty vanilla:

Type
special

Date
Tuesday, March 29, 2005 - 8:19am

User
Corby

Location
/site/?q=node/add/forum

Message
forum: added RAWR owned again RAWR.

Hostname
216.63.107.58

I don't see any other info in watchdog.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

Some one tried to hack my

stephenhendry commented 29 March 2005 at 17:44

Some one tried to hack my site a while back.

First of all make sure your email address is still correct for the admin site and request a new password. Then log in with the new random password which has jsut been sent to your email address. Then go back in and disable all other user accounts so the Admin is the only person who can edit anything. Then I would again rest the admin password just in case. Then log in again.

Hopefully you should be the online person who can edit anything now. Go through the watchdog and look for anything that has been changed and get it right.

Once you got things to back to hwo they were back it all up!

Then go back and it would be best to reset any userpasswrods who had admin roles before. Then restore the correct edit permissions.

Then back up again.

different computers commented 29 March 2005 at 17:44

03/29/2005 - 8:19am RAWR owned again RAWR
Corby
216.63.107.58 http://delaflamme.org/site...
track user
track title
track host

03/29/2005 - 8:19am Submit
Corby
216.63.107.58
http://delaflamme.org/site...
track user
track title
track host

03/29/2005 - 8:19am Preview
Corby
216.63.107.58
http://delaflamme.org/site...
track user
track title
track host

03/29/2005 - 8:18am Submit forum topic
Corby
216.63.107.58
http://delaflamme.org/site...
track user
track title
track host

03/29/2005 - 8:18am create content
Corby
216.63.107.58
http://delaflamme.org/site...
track user
track title
track host

03/29/2005 - 8:17am (node)
Corby
216.63.107.58
http://delaflamme.org/
track user
track host

03/27/2005 - 8:07pm ()
Corby
216.63.107.58
http://delaflamme.org/site...
track user
track host

topic create

moshe weitzman commented 29 March 2005 at 21:11

this chain shows him creating a forum topic, not a forum. are you saying that authenticated users cannot create topics in your permissions config?

Yes they can

different computers commented 30 March 2005 at 13:38

Here's the thing--he was spoofing being authenticated. I'm "Corby" and I didn't create that. Corby is the admin. I think he injected data as the admin account.

If he had the admin password, then he would have likely done much more violent things to the site--like changing the theme, or well, anything.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

Old trick, name likeness

LuckyOne commented 31 March 2005 at 05:44

Hey, I know what's happening. It's an old joke about username which looks like admin name :-) Here it is: user registers as normal user, but with admin-like name. In your case it would be 'Corby', but 'o' letter is typed in any other language like Russian, Ukrainian... Drupal uses unicode, so it is always possible. This does not grant any admin rights to malicious user!!! Usually it is accompanied with profile likeness.

This could be easily ruled out by showing up the registration date everywhere. Admin has the oldest date, right? Who will believe that Admin registered half an hour ago to post this emergency warning? ;-)

Not the case

different computers commented 31 March 2005 at 13:35

Interesting thought, but this isn't the case. There's no "normal" user with the admin name.

Just the admin. If I understand what you're saying.

Also, the first time someone did this, they created about FIFTY forums in a very short amount of time, leading me to think that it was done with some sort of script, not manually.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

Just a thought

media girl commented 30 March 2005 at 00:24

Are you on a winderz machine? You might try downloading and running AdAware and Spybot and see if perhaps you have some software on your computer telling tales out of school.

Also, if you have an alternative email address, change your own admin email to that and change your password. Somehow he could be peeking at your email.

You also could block his IP in htaccess, though IP addresses can change.

Finally ....um....do you trust your ISP and host?

--
mediagirl.org

Forums or forum topics?

Steven commented 29 March 2005 at 17:43

Is he adding forum topics/discussions or whole new forums?

--
If you have a problem, please search before posting a question.

Forums

different computers commented 29 March 2005 at 17:54

He's adding new forums. both times.

Other info: "Corby" is the only admin and that's me. There's been no indication that any other user has done anything odd. And there are only 28 users, all of whom I know personally.

I've changed Corby's admin password for drupal.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

Dou you have access to the

Uwe Hermann commented 29 March 2005 at 19:38

Dou you have access to the webserver logs? Please post those here (with private/sensitive data like IPs/passwords etc. removed or changed), that might help...

Uwe.
--
hermann-uwe.de | crazy-hacks.org | unmaintained-free-software.org

Do you use PHP 4.3.10 or

nsk commented 29 March 2005 at 20:04

Do you use PHP 4.3.10 or 5.0.3 ?

--
NSK, Admin of Drupal-based site http://www.wikinerds.org

4.3.10

different computers commented 30 March 2005 at 02:26

I use 4.3.10

All my machines are macs. I don't think I've EVER logged into my site from an unsecured PC.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

PHP 4.3.10

different computers commented 30 March 2005 at 15:03

I use the ISP's install of 4.3.10.

this seems to be the only stuff of any interest, or at least the only thing I cannot be sure is harmless.
He repeated this first thing six times

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:17:09 -0500] "GET / HTTP/1.0" 304 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

These look innocuous to me, but they are POSTs so I include them

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:00 -0500] "POST /site/?q=node/add/forum HTTP/1.0" 200 17990 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:07 -0500] "POST /site/?q=node/add/forum HTTP/1.0" 200 17990 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:15 -0500] "POST /site/?q=node/add/forum HTTP/1.0" 200 17998 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:32 -0500] "POST /site/?q=node/add/forum HTTP/1.0" 200 17978 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:36 -0500] "POST /site/?q=node/add/forum HTTP/1.0" 302 0 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:36 -0500] "GET /site/?q=node/228&PHPSESSID=08394876e5c11f43b8dc5b91799931a0 HTTP/1.0" 200 11705 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

Thanks much.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

too bad

bertboerland commented 30 March 2005 at 16:07

POST-es arent logged by default so we dont know what (s)he send. My best quess would be since
1) this seems not to be an automated tool but a real user
2) you seem to be the only one suffering
this is related to your specific setup.

Best to change your passwd, recheck your email address (and the pop3 password for that!) and file an abuse at swbell.net.

It might be wise to GREP for some other hits this address made the last couple of weeks.

--
groets
bertb

--
groets
bert boerland

Did anyone notice this?

kbahey commented 31 March 2005 at 02:57

Did anyone notice this?

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:36 -0500] "POST /site/?q=node/add/forum HTTP/1.0" 302 0 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

Why would two attempts of node/add/forum return the same number of bytes (17990). Try doing that and see how many bytes there is, and if it variable every time. Is your home page 17990 bytes? I recall that with Drupal 4.4 there was no 404, and you got a 200 with the home page instead. Could it be something similar here?

The referer is is also node/add/forum. How can this be?

Also:

adsl-216-63-107-58.dsl.bumttx.swbell.net - - [29/Mar/2005:08:19:36 -0500] "GET /site/?q=node/228&PHPSESSID=08394876e5c11f43b8dc5b91799931a0 HTTP/1.0" 200 11705 "http://delaflamme.org/site/?q=node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1)"

Note that PHPSESSID here. This says that the user is not logged in anymore, otherwise the session would be stored in the databasee. Why is this so?
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Just a thought, but are you and the kiddie using same isp?

tatonca commented 30 March 2005 at 18:22

...and does the ISP use a proxy server?

This may be an example of the whole cached pages problem - he may not actually have your password, but maybe just access to a cached page that exposes the forum creation form...

Access in drupal is dependant on what you see, not what you do. So there is no additional access check when a form is being submitted, because all the access checks are done when the page is rendered.

If the kiddie can access a cache version of the page off the ISP proxy, he can do whatever the person that last accessed that page can do, cause that is how the page got rendered...

This reminds me

media girl commented 30 March 2005 at 22:46

Several months ago I looked in my logs at referrers, and followed a link to someone else's admin logs on their Drupal site -- and got in. I was able to walk all around their site with impunity. In other words, they linked to my site via their logs, and thus their logs' url was logged as a referrer in my logs. By following that referrer link back, it was as if I was logged in on their site as admin.

I messaged them and we exchanged some emails as to what might have been happening. We couldn't figure it out. I was able to repeat the process once or twice, until finally they logged out. They were never able to do the same to me, by following their referrer link into my admin pages.

I don't know what came of it, and for the life of me I cannot remember what site it was. Maybe this post will jar someone's memory here?

Whether this is related, I don't know.
--
mediagirl.org

Yeah - I'm not sure if it's related either...

tatonca commented 31 March 2005 at 00:16

but there was a discussion here if you are interested..

http://drupal.org/node/18390

Since then I have started having issues again, and have yet to try the second suggestion in that thread. I would be interested in what you think...

The only possibility which

Uwe Hermann commented 31 March 2005 at 02:30

The only possibility which comes to my mind of why this could happen is this: The other admin had the session ID in his URL (for whatever reason, be it a bug in previous Drupal versions or misconfigured PHP, whatever). Then you followed the URL from his referrer (which included the session ID) and hence were able to view his logs. You provided the valid session ID after all...

That's my humble guess how it might have happened.

Uwe.
--
hermann-uwe.de | crazy-hacks.org | unmaintained-free-software.org

Session IDs

media girl commented 31 March 2005 at 02:36

They appear all the time in my urls on all of my Drupal installations (on several different hosts). Is this not supposed to happen?

--
mediagirl.org

Yes, it's usually a bad idea

Uwe Hermann commented 31 March 2005 at 04:23

Yes, it's usually a bad idea to have session IDs in the URL. Drupal's default .htaccess file ensures that they don't appear in the URL, if I remember correctly. Do you have the .htaccess file installed?

Uwe.
--
hermann-uwe.de | crazy-hacks.org | unmaintained-free-software.org

htaccess, yes

media girl commented 31 March 2005 at 05:19

I don't see the session IDs usually, but I always do immediately after posting something.
--
mediagirl.org

htaccess

different computers commented 31 March 2005 at 13:40

My ISP can create a drupal install automatically, and that's what I used. I can post the .htaccess file for you to see if you like.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

If it is a cache issue...

tatonca commented 31 March 2005 at 16:39

...and you have PHP sessions in your URLs, the kiddie wouldn't need your password if he has access to your cached copy... ...as I understand it anyway. As long as the session hasn't expired yet, he would have the same privelleges as the person who initiated that PHP session...

Possible?

~Tat~

drupal's htaccess

different computers commented 31 March 2005 at 17:46

I double checked my htaccess and it appears to be drupal-customized.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

code

silverwing commented 31 March 2005 at 06:57

I think you can add this to your .htaccess to stop the session IDs

# Fix for ?PHPSESSID in clean URLs
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1
# End of fix

Thanks

media girl commented 31 March 2005 at 07:47

Those were not in the htaccess files I have. Much appreciated!
--
mediagirl.org

Clean URLs disabled

different computers commented 31 March 2005 at 13:45

Will this htaccess fix work if I don't have Clean URLs enabled?

I've added it to my htaccess anyway.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

Thanks. That was good and

hpk commented 31 March 2005 at 15:40

Thanks. That was good and useful information.

hpk a.k.a. vikram
[De-centralizing the central issues]
National Institute of Design, India

If I add this ...

escoles commented 7 April 2005 at 18:03

... it generates a server internal error. Unless I put it inside of a conditional block ["IfModule mod_php4.c /"] that I inserted for reasons I don't recall -- I assume that means that inside the conditional, the code doesn't execute.

That's where I put it

media girl commented 7 April 2005 at 18:07

My whole relevant string:

<IfModule mod_php4.c>
   # If you are using Apache 2, you have to use <IfModule sapi_apache2.c>
   # instead of <IfModule mod_php4.c>.
   php_value register_globals        0
   php_value track_vars              1
   php_value short_open_tag          1
   php_value magic_quotes_gpc        0
   php_value magic_quotes_runtime    0
   php_value magic_quotes_sybase     0
   php_value arg_separator.output    "&amp;"
   php_value session.cache_expire    200000
   php_value session.gc_maxlifetime  200000
   php_value session.cookie_lifetime 2000000
   php_value session.auto_start      0
   php_value session.save_handler    user
   php_value session.cache_limiter   none
   php_value allow_call_time_pass_reference  On
   php_flag zlib.output_compression On
   php_value zlib.output_compression_level 5
# Fix for ?PHPSESSID in clean URLs
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1
# End of fix
</IfModule>

--
mediagirl.org

If I put it there, it has no effect

escoles commented 7 April 2005 at 18:25

Session IDs still show up in the URL. So I'm operating under the assumptions that:

There's something my hosting provider doesn't like in those directives;
the code's not getting executed inside the "IfModul" conditional.

PHP suexec

kbahey commented 7 April 2005 at 18:31

At one point, my hosting provider changed PHP from an Apache module to PHP SuExec.

I started seeing those SESSID's in the URLs. It turns out that under SuExec, the .htaccess directives for PHP are totally ignored.

So, what you need to do if this is the case, is to copy those directives to a php.ini file under your public_html.

That worked for me without a problem.

UPDATE: An easy way to diagnose if you have SuExec or not is to create a file called phpinfo.php and put in it:
phpinfo();
And place it in the public_html directory.

Then create a php.ini file and change the values in it. Browse tothe above file and see if the values change as you change them in the php.ini file. If they change, then go ahead with that, since .htaccess is ignored.
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Placing the directives in php.ini does the trick, but...

escoles commented 7 April 2005 at 19:03

... what are the reasons that an ISP would make that change? Doesn't it load the system more heavily and reduce scalability dramatically? (Of course, that could explain why comment spammers are able to DOS my site...)

My host does this to allow

carlmcdade commented 7 April 2005 at 19:37

My host does this to allow me to run php5 or php4 but other hosts do it for security reasons. Here's a webhost admin explaination of why they do this:

The reason why PowWeb uses the CGI version of PHP versus the module is mainly because of security. PowWeb uses the Apache Web Server with suexec, a cgi wrapper that allows all customers to run their scripts as them. mod_php does not work with suexec and runs as the webserver user. This is a problem for a number of reasons. If you were to upload your files they would be owned by you, and most likely would be editable only by you as you would not want anyone else on the server to edit your files. If you CGI programs needed to edit that file, and it was running as the webserver user, it would not have permissions to edit that file. If you made that file editable to the webserver user, then anyone else using mod_php on the server would then also be able to edit the file.

Another good example is if you had a mysql Database. Your database requires you to provide a username and password when connecting to ensure that you have the privileges to do what ever it is you are going to do. You would not want these credentials in a file that would be readable by the webserver user otherwise anyone on the server would also be able to read them. Instead, you would put them in a file that was readable only by you, and so therefore the php script would have to execute as you in order to read that file, get that information, and connect to the database.

There are more reasons as to why we use the CGI method, however securtiy is the main one. When mod_perl, mod_php, or any module for that matter works with suexec, then PowWeb will probably use them because their are benefits with doing so. I am hoping with apache 2.0's Multi-processing modules that this problem is resolved..... however I have not really looked into this yet as it is still in beta and will probably be a long time before PowWeb can support it.

---------------------------
Hivemindz CMSopedia
__________________________
Carl McDade
Information Technology Consult
Team Macromedia

FOLLOWUP: Not all directives take effect

escoles commented 10 April 2005 at 14:09

On my account, only a few of the directives will actually take effect when included in a php.ini file. Most have no impact on the value of PHP vars. Fortunately, I do seem to be able to kill session IDs in the querystring...

Unless you run your own host

kbahey commented 10 April 2005 at 15:22

Unless you run your own host (I mean your own instance of Apache, whether VPS or a physical machine), your hosting provider may restrict the ability for you to override certain variables.

Hence, in a shared hosting environment, whether you are using PHP as an Apache module, or as a CGI SuExec, you may not be able to set certain parameters.
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

yes

harald.walker commented 31 March 2005 at 06:53

Yes, that's what it is and I think also the reason for Mike's 'Hacker' problem. If you have site where this happens, don't forget to LOG OUT. Then the session is invalid and the link doesn't work (well it will work, but won't log you in).

Sounds similar to what I've noticed....

escoles commented 7 April 2005 at 17:51

... in the past few days on my site: I found someone had posted a comment, and it showed up as being from me. I have what I think are good reasons to suppose that the poster was non-malicious; he was someone I'd linked to in a story, though, he may have linked to me from his logs. That said, he looked to me to be using Moveable Type.

http://drupal.org/node/20125

Access in drupal is

drumm

he/him

NY, US

commented 31 March 2005 at 01:04

Access in drupal is dependant on what you see, not what you do. So there is no additional access check when a form is being submitted, because all the access checks are done when the page is rendered.

This is untrue. The same permissions checks are almost always done for POST requests as GET requests. On some pages which have slightly different forms for differently permissioned users, such as node submission, the data is cleaned so those with lower permissions can not construct a malicious request to change data which they don't have permission for.

Access checks

Steven commented 31 March 2005 at 01:21

Access in drupal is dependant on what you see, not what you do. So there is no additional access check when a form is being submitted, because all the access checks are done when the page is rendered.

This is not at all true. Access checks are performed for every page request, whether it is a GET or a POST. The menu system is the first layer of access, while the module is then later free to deny access on top of that.

Drupal's node.module has:

function node_submit(&$node) {
  ...
  if (node_access('create', $node)) {
    ...
  }
  ...
}

The access check is being performed as it should be. No database changes are performed without that check being true.

Perhaps you have a defective or outdated module, but I think you need to look at the reason why this person is acting under your account. If Drupal thinks he is you, then of course Drupal will allow him to post. Look in the watchdog for an entry which says "Session opened for /your username/" with the IP/Host of the cracker.

--
If you have a problem, please search before posting a question.

Thanks for the clarification...

tatonca commented 31 March 2005 at 16:49

...Drumm as well...

I went looking for precisely that and didn't find it in the code - only the hook_menu access checks...

However, as I questioned more recently above, if the PHP session is in the URL would this then provide the access required from a cached page?

Without PHP session in the url, then the only problem with proxy cache is the ability to view admin pages but not do anything with them correct?

No session opened

different computers commented 31 March 2005 at 17:44

Looking at the most recent hack, there is no record of a session being opened prior to the kid inserting the new forum. In fact, there's no list of that IP address doing ANYTHING except adding a forum as the admin.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

I think this supports the idea...

escoles commented 7 April 2005 at 18:05

... that it's due to session ID's being embedded in a link that showed up in his logs, somehow. I.e., there would be no new session created, because he was using an existing one. Am I getting this?

My ISP

different computers commented 31 March 2005 at 13:37

I was just reading yesterday that my ISP (which is also my power company) only has about 2000 clients. None in Texas, where the first attack took place

My other ISP is a university. Also not in texas.

Or do you mean my web hosting company? That seems unlikely.

If you don't love your computer, you need Different Computers.
http://differentcomputers.com

devel and og

kae commented 7 March 2006 at 01:41

i had a problem where i had devel og ecommerce and node privacy by role running and anonymous had admin rights. do you have those running?

Year old thread.

sepeck commented 7 March 2006 at 01:56

Year old thread.

-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}

My drupal is being hacked at delaflamme.org/site/

Comments

New forum topics