I am Swedish but I thought it might be a good idea to post this in English just in case some Drupal exploit God comes in from …. wherever.
I am using a LAMP box with PSAD (port scan attack detection) with Snort rules that are in-line with the firewall. All this on a hardened Xen (dusted domain0) for vt-d attackes for -0 ring attacks. I did my daily Drush and took a look at my logs. Holy crap one of my Drupal slices had been owned! A ver-6.19 Drupal. I did a quick grep in the Apache logs on the guys IP. He had made himself an admin with God privileges. I found the below url in the logs and tried it out. Took me right into full admin on my site.
http://*******.com/user/reset/38/1285626010/6749a1115847130d782e=
A quick google showed his IP to be all over the place. My vhosts are set up to be rather immune to most XSS. All the same I am not ruling it out. He hit the blog, registered, got a mail (guess) and passed some funky url I can see. Not 100% sure though. He has been back a few times.
I replaced the url in question with the stars. Anybody know how this exploit was done. I have WireShark monitoring everything at the moment as a MITM.
***ATTACK STARTS
99.58.185.39 - - [28/Sep/2010:00:20:02 +0200] "GET /blog/1 HTTP/1.0" 200 5555 "http://*******.com/blog/1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]"
99.58.185.39 - - [28/Sep/2010:00:20:05 +0200] "GET /user/register HTTP/1.0" 200 6399 "http://*******.com/user/register" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]"
99.58.185.39 - - [28/Sep/2010:00:20:08 +0200] "POST /user/register HTTP/1.0" 302 - "http://*******.com/user/register" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]"
99.58.185.39 - - [28/Sep/2010:00:20:11 +0200] "GET / HTTP/1.0" 200 6378 "http://*******.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]"
99.58.185.39 - - [28/Sep/2010:00:20:14 +0200] "POST /v%C3%A4lkommen?destination=node%2F3 HTTP/1.0" 200 6448 "http://*******.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]"
99.58.185.39 - - [28/Sep/2010:00:23:22 +0200] "GET /user/reset/38/1285626010/6749a1115847130d782e= HTTP/1.0" 302 -
"http://*******.com/user/reset/38/1285626010/6749a1115847130d782e=" "Mozilla/4.0 (compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
***OWNED
99.58.185.39 - - [28/Sep/2010:00:23:24 +0200] "GET /user/password HTTP/1.0" 200 4905 "http://*******.com/user/password" "Mozilla/4.0 (compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
99.58.185.39 - - [28/Sep/2010:00:23:27 +0200] "GET /user HTTP/1.0" 200 5064 "http://*******.com/user" "Mozilla/4.0 (compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
99.58.185.39 - - [28/Sep/2010:00:23:32 +0200] "POST /user//user HTTP/1.0" 404 3321 "http://*******.com/user" "Mozilla/4.0 (compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
99.58.185.39 - - [28/Sep/2010:00:23:39 +0200] "POST /user HTTP/1.0" 302 - "http://*******.com/user" "Mozilla/4.0 (compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
99.58.185.39 - - [28/Sep/2010:00:23:44 +0200] "GET /users/ksetr HTTP/1.0" 200 4793 "http://*******.com/users/ksetr" "Mozilla/4.0 (compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
99.58.185.39 - - [28/Sep/2010:05:13:24 +0200] "GET /user/reset/38/1285626010/6749a1115847130d782e= HTTP/1.0" 302 - "http://*******.com/user/reset/38/1285626010/6749a1115847130d782e=" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:26 +0200] "GET /user/password HTTP/1.0" 200 4905 "http://*******.com/user/password" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:29 +0200] "GET /user HTTP/1.0" 200 5064 "http://*******.com/user" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:31 +0200] "POST /user//user HTTP/1.0" 404 3321 "http://*******.com/user" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:38 +0200] "POST /user HTTP/1.0" 302 - "http://*******.com/user" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:40 +0200] "GET /users/ksetr HTTP/1.0" 200 4795 "http://*******.com/users/ksetr" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:43 +0200] "GET /node/add HTTP/1.0" 200 4943 "http://*******.com/node/add" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:46 +0200] "GET /node/add/forum HTTP/1.0" 200 10239 "http://*******.com/node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:50 +0200] "POST /node/add/forum HTTP/1.0" 200 11808 "http://*******.com/node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:05:13:53 +0200] "GET /node/add/forum HTTP/1.0" 200 10239 "http://*******.com/node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
99.58.185.39 - - [28/Sep/2010:23:30:19 +0200] "GET /user/reset/38/1285626010/6749a1115847130d782e= HTTP/1.0" 302 - "http://*******.com/user/reset/38/1285626010/6749a1115847130d782e=" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:21 +0200] "GET /user/password HTTP/1.0" 200 4905 "http://*******.com/user/password" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:23 +0200] "GET /user HTTP/1.0" 200 5064 "http://*******.com/user" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:25 +0200] "POST /user//user HTTP/1.0" 404 3321 "http://*******.com/user" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:32 +0200] "POST /user HTTP/1.0" 302 - "http://*******.com/user" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:35 +0200] "GET /users/ksetr HTTP/1.0" 200 4796 "http://*******.com/users/ksetr" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:38 +0200] "GET /node/add HTTP/1.0" 200 4943 "http://*******.com/node/add" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:40 +0200] "GET /node/add/forum HTTP/1.0" 200 10239 "http://*******.com/node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:43 +0200] "POST /node/add/forum HTTP/1.0" 200 11812 "http://*******.com/node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:30:56 +0200] "POST /node/add/forum HTTP/1.0" 200 11812 "http://*******.com/node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
99.58.185.39 - - [28/Sep/2010:23:31:08 +0200] "POST /node/add/forum HTTP/1.0" 200 11812 "http://*******.com/node/add/forum" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
logs go on and on but you get the point in the above. All html is filtered on that site. No PHP allowed etc. on that blog. Use a <? required(' ') ?> that calls my settings from outside of the site root. Everything is drushed daily. Only use scp, no ftp, ssh without passwords. Most of the computers here are OpenBSD 4.7 or hardened Linux boxes. No Windows on this network.
Anybody got any ideas?
Comments
Hi, I do hope you have sent
Hi,
I do hope you have sent this to the drupal security team :)
http://drupal.org/security-team
at
security@drupal.org
/Thomas
How to report a security issue
If you discover a vulnerability in Drupal core or contributed module, keep it confidential. Mail us at security@drupal.org, do not post in the issue tracker or discuss it in IRC. The security team will investigate your report and create a fix. When the issue is about a contributed module, the team coordinates with a module maintainer. When a fix is ready, an advisory urging users to upgrade is published.
Read more at http://drupal.org/node/101494
That said, the url .com/user/reset/38/ looks like user with uid 38 has asked for a new password. Is uid 38 not a new account?
Yeah I tried that ....
Yeah I tried. No answers. This is a bot that is running rampant on the Internet and pwn'n "secure" Drupal sites. Just google the IP. The funny thing is that there was no user 38. I set up a WireShark box as a MITM between the OpenBSD firewall and the Xen/Linux slice Drupal is on. Last night I got a full TCP dump of the bot when it came back. I now know exactly what this bot is doing. Anyway from user 38 the bot escalated it privileges to user 1. Not going to get into the details here on how to pwn Drupal sites but I can tell you how to get yourself as user 1 again.
drush php-eval 'db_query("UPDATE
usersSETpass= MD5(\"yourNewPassWord\") WHEREuid=1;");'OK that worked. Why can't I log in? Your account might not be user 1. Go into phpmyadmin and then into the table "users" You will see the name of user 1. If you "freaked out" and blocked everybody (the real user 1) you can unblock it in the "users" table under the field "status". Just change status back to a "1" to reactive it.
I would also set up a http:BL from:
www.projecthoneypot.org.
This will in real time block bad bots or evil IPs from your site. It will also help protect you form future Zero-day exploits that use bot nets. There is even a module for Drupal that can use the IP block list they have. LOL I wasted 5 hours writing a mod in C for apache2 before I saw that!
Den enda anlendningen att jag skriver detta på engelska är för att jag inte är säker på att den man som svarade mig talar svenska.
MVH
qxt
I call your bullshit. Your
I call your bullshit. Your message was sent to the security team a few hours ago. And it is just as hysterical and unclear as what you posted here. Please give the security team time to analyze your query. We are volunteers.
The answer
The answer likely was the following or a slight variation thereof (appropriate sections bolded to aid the impatient):
And then from http://drupal.org/node/213320
Note that if you are logged into the site as uid 1, then use a random user reset url, you'll only get the message (if you print messages)
And you'll remain logged in.
The log looks like a typical run from a spambot.
edited to add: if you did confirm there's escalation taking place and you can reproduce this, please follow the template mentioned above.
Please dont get offended, but
Please dont get offended, but I am rather hesitant to take this that seriously. If you feel certain of this being a genuine exploit, and you dont get any answers by the security team or security team members in irc, ehm, please do describe the issue further. (privately with anyone on this board preferrably)
This reads like a rather simple/usual xss exploit. Example: Guests can register and post content. This content is not sanitized before display. You then, as a logged in administrator, view this content (containing javascript), letting the javascipt run as you and changing your password or stealing you session cookie. Sure there has been remote exploitable paths in drupal, but that was as far as I remember long ago.(xmlrpc 2005?)
From SysAdmin to moshe weitzman
Actually Linda did take offense.
She is just a web programmer and was not happy to 1st see that was compromised and 2ed to see the Drupal security team respond to her the way you did. I am the admin of the systems she is on. I am a lot less PC then she is and wholeheartedly say 'you are a fu*king moron moshe!' If you call 'Bull Shit' before you even looked into an incident then you suck as a security 'expert'.
I use to be a senior member of the BackTrack crew. Now more known as Remote-Exploit. I am also a member a few more 'underground groups' I have always treated all our members with respect. I did not care if it was Max Moser (who is a friend I worked with at times) to a BT newbie. I have years of experience in penetration testing. Enough sunshine up my ass. Linda did not want to disclose to much information about what transpired on a public forum. From what I understand she just copy pasted what was posted here and sent it to you, since others asked her to do so.
The perticuler server that was hit was configured like this:
A custom-configured Xen that uses things like VT-d for Dom0 disaggregation, TPM and TXT for secured boot, and high isolation through customized DomU partitioning. Each DomU is running a hardened version of Linux. There are only 2 ports open on any of the public servers. One on 80 and one way the hell out there for SCP/SSH. Every packet that goes into 80 is watched like a hawk for anything that Metasploit, Nessus, SAINT and other stuff I am not going to talk about might throw at it. IPv6 is not allowed since OpenBSD once was taken down with a IPv6 frag attack. The in thing now (in certain circles) is minus 2 attacks on SMM, minus 3 ring attacks on NICS and stuffing a thin minus 1 ring hypervisor under the OS in real time. Hence the kind of security I have. We play red team/blue team games but not on these servers. The above gear is just a habit.
Yes it could have been a lame XSS attack but but it is not likely. Learn from other peoples mistakes.
As you know Apache.org was taken out on the April 5th 2010 with a XSS attack. Tinyurl was used to redirect back to the Apache instance of JIRA, at a special URL containing a XSS attack. The admin who clicked on the URL had the session cookie stolen. This compromised the sessions not to mention the JIRA admin rights. All in all, the attackers were thereby able to login to brutus.apache.org, and gain full root access to the machine. This machine hosted the Apache installs of JIRA, Confluence, and Bugzilla. The point is if you can take out almost the entire infrastructure of Apache.org with a XSS attack you could just maybe take out a Drupal site. Any script kiddy could do this. I am not impressed. Just aware of the dangers.
Part of the Vhost reads like this making XSS a bit more difficult. I am not going to rule it out though. There is a hell of a lot more on the IPT netfilting and PSAD in-line firewall SNORT rules (behind the OpenBSD double sided firewalls) then below to help out with XSS.
Small cut of Vhost from her slice:
ServerSignature Off
/* Turns off TRACE will help against cross-site scripting attacks /
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule . - [F]
VirtualHost
Since this is Drupas problem and not mine I am not even sure I am willing to filter though the massive Transmission Control Protocol dump from her attack.
I keep telling users to stop using stupid CMS and write their own code. Using 3ed party modules and even worse JS is bloatware and just asking for it!
As for your knee jerk reaction on the 'Bull Shit Call' maybe you should have sent a private msg to her and asked her to send TCP dump.
Onryo
Thanks to most of you. Its all sorted now =)
Wow I kind of feel like I got squished between the system administer and the Drupal security team. I know Onryo used some harsh words. I don't know what to say =/ He was nice enough though to go though the TCP dump and tell me what happened in full detail. It reads close to what Heine said.
A few hours before I was attacked a bot checked out my site and followed all the links I had. It seemed to be looking for known modules and paths for Wordpress, Joomla and Drupal. Its IP was from Nigeria. 1 hour and 15 minutes later. A few bots tried to scan the server but they were all auto blocked for a few weeks since they scanned something other then port 80. A Russian IP 99.58.185.39 started randomly coming in and with a XSS and CSRF attacks for Drupal right off the bat. I later logged in and the bot nailed me. I told our administer about it.
I was told to stay “cool” since there are daily backups of every domain. That we would play cat and mouse. I changed the password and user 1 back to normal (the way I described above) since our administer said the bot had been logging into my site quite often. A trap was set with WireShark and sure enough the bots started up again. When I later logged into my site the details on how the XSS captured my session was recorded by WireShark. Most of the kinds of XSS and CSRF failed due to the server setup btw. Unfortunately one succeeded.
After being schooled by the BOFH _ j/k Onryo_ I was told that the only way to be a good whitehat was to be a good blackhat. Know your enemy so to say. Then some talk about Sun Tzu ???
I was also given some advice on how to prevent this sort of thing:
http://ha.ckers.org/xss.html (Cross Site Scripting for filter evasion)
“The 5 Whys is a Japanese questions-asking method used to explore the cause/effect relationships underlying a particular problem. Ultimately, the goal of applying the 5 Whys method is to determine a root cause of a defect or problem.”
….ahhh right and the word Onryo is also Japanese for an evil mean ghost! LOL
Well that wraps it up.
Thanks “Onryo” for the time you spent helping me sort this out. Props to Heine for acting civilized.
qxt
Hi LinEek, Glad you were able
Hi LinEek,
Glad you were able to sort it out! One additional suggestion: I do not think the
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)rule posted above is very effective. As I understand it this countermeasure blocks a loophole in httponly cookies, nothing more.Thx Grendzy !
Nice to see a friendly face =) I am not really sure what that code does since it is on a part of the server I can't get to. What I do know is that it is a real pain to have a USB stick in my computer just to change folders if it is not in the site folder.
Wait a second you might have just solved a mystery for me! phpmyadmin says $cfg['Servers'][$i]['tracking'] ... disabled. Could the code that Onryo put in there be the reason?
Maybe I could convince him to remove that vhost thing if it does not do all that much. Honestly this kind of security is pain to work with. If a little light blinks to much or “chi” feels wrong he whips out a samurai sword … well almost =)
Oh one more thing that book on Cracking Drupal is REALLY awesome! There is a chapter that shows us how to use DOM to gain user 1 access right off the bat with Drupal among other things...if you don't configure it right. The title is misleading. The book is about protecting Drupal. Whats more interesting is the next chapter “uncracking” Drupal. How to protect yourself.
Stay safe and thank you!
LinEek
qxt
Linda and Grendzy
Back in the day, I enjoyed poking my nose in remote systems. We used every trick in the book. Here is some info why I do not allow Track or Trace. In a lot of areas I also use this
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK)
From:
http://pauldotcom.com/wiki/index.php/Episode94
#
- Nikto 2.01/2.01 - cirt.net
+ Target IP:
+ Target Hostname: web.yourdomain.com
+ Target Port: 80
#
+ Server: Apache/1.3.34 Ben-SSL/1.55 (Debian)
+ /robots.txt - contains 1 'disallow' entry which should be manually viewed (added to mutation file lists) (GET).
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE
+ OSVDB-877: HTTP method ('Allow' Header): 'TRACE' is typically only used for debugging and should be disabled. This message does not mean it is vulnerable to XST.
+ Apache/1.3.34 appears to be outdated (current is at least Apache/2.2.6). Apache 1.3.39 and 2.0.61 are also current.
+ Ben-SSL/1.55 appears to be outdated (current is at least 1.57)
+ OSVDB-877: TRACK / : TRACK option ('TRACE' alias) appears to allow XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details
+ OSVDB-877: TRACE / : TRACE option appears to allow XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details
+ OSVDB-3092: GET /downloads/ : This might be interesting...
+ OSVDB-3268: GET /icons/ : Directory indexing is enabled: /icons
+ 4345 items checked: 9 item(s) reported on remote host
The web server is vulnerable to XST, or Cross-Site Request Tracking, which could potentially allow attackers to steal cookies or perform XSS attacks.
The TRACE and TRACK protocols are HTTP methods used in the debugging of webserver connections.
Although these methods are useful for legitimate purposes, they may compromise the security of your server by enabling cross-site scripting attacks (XST). By exploiting certain browser vulnerabilities, an attacker may manipulate the TRACE and TRACK methods to intercept your visitors’ sensitive data.
A false sense of security is worse then no security at all. This is just a little drop in the bucket and far from the answer to all XSS woes. There is still a lot of talk about the HTTP protocols
http://perishablepress.com/press/2009/09/06/disable-trace-and-track-for-...
/Onryo