Fully patched site hacked and cloaked
Hi, This is to share an (unpleasant) experience I had yesterday on a hacked site of a client (hacked despite fully patched modules and D6.15). It was apparent hackers used a cloaking method, i.e. the site appeared just fine to users but search engines saw a page full of drug advertisements. I found no trace of changes via user activity (revisions, user last access, etc.) and there was nothing suspicious in the source code of the cloaked pages. Eventually I found that the file bootstrap.inc had been altered (without changing the time stamp!) -- a whole chunk of obfuscated PHP code was added at the top of the usual Drupal code. I responded by reloading Drupal and locking up the site even more than up to now. This is to warn others about this hacking method, which may not be immediately apparent to webmasters. If anybody is interested in studying the obfuscated PHP code I found there, please contact me off the list. I also wonder whether Drupal could be adjusted so as to automatically set file bootstrap.inc, and perhaps other critical ones, as read-only. So far it is done only with settings.php file. Cheers, vacilando -- Tomáš J. Fülöpp http://vacilando.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tomáš Fülöpp (vacilando.org) schrieb:
Hi,
This is to share an (unpleasant) experience I had yesterday on a hacked site of a client (hacked despite fully patched modules and D6.15).
It was apparent hackers used a cloaking method, i.e. the site appeared just fine to users but search engines saw a page full of drug advertisements.
I found no trace of changes via user activity (revisions, user last access, etc.) and there was nothing suspicious in the source code of the cloaked pages.
Eventually I found that the file bootstrap.inc had been altered (without changing the time stamp!) -- a whole chunk of obfuscated PHP code was added at the top of the usual Drupal code.
I've seen a similar method used in a hacked Joomla install.
I responded by reloading Drupal and locking up the site even more than up to now.
Were you able to determine the attach vector that was used to be able to modify bootstrap.inc? Was it Drupal related? Do you run any custom code?
This is to warn others about this hacking method, which may not be immediately apparent to webmasters.
If anybody is interested in studying the obfuscated PHP code I found there, please contact me off the list.
I also wonder whether Drupal could be adjusted so as to automatically set file bootstrap.inc, and perhaps other critical ones, as read-only. So far it is done only with settings.php file.
If the Apache-User can do that, it can also be used to change this property again, so it makes little sense to do that from within Drupal. When deploying code I usually consider it mandatory that the webuser does not have this permission, ie the files belong to a different user. Unfortunately most/all fcgi setups have one user for both. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktgJ10ACgkQfg6TFvELooRLgQCfQkmtZ7roeZaGtmF2+Jbq7xyd wjcAn3si1XmTvQHKntBs9EeCYTZQKRKA =hqDR -----END PGP SIGNATURE-----
On Jan 27, 2010, at Wed 1/27/10 4:45am, Gerhard Killesreiter wrote:
Were you able to determine the attach vector that was used to be able to modify bootstrap.inc?
I just saw this performed on a D5 site. Bootstrap.inc was indeed altered, an additional system.php file was inserted in the modules folder, and the pernicious (drug) website files were inserted into the cgi folder *above* the webroot. The code was sniffing passwords. Several files contained nothing but hashes. I mention this because if we see a pattern across many sites, this entire conversation should move to security reports offline. Laura
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ? ----- Original Message ----- From: "Laura" <pinglaura@gmail.com> To: <development@drupal.org> Sent: Wednesday, January 27, 2010 9:53 AM Subject: Re: [development] Fully patched site hacked and cloaked On Jan 27, 2010, at Wed 1/27/10 4:45am, Gerhard Killesreiter wrote:
Were you able to determine the attach vector that was used to be able to modify bootstrap.inc?
I just saw this performed on a D5 site. Bootstrap.inc was indeed altered, an additional system.php file was inserted in the modules folder, and the pernicious (drug) website files were inserted into the cgi folder *above* the webroot. The code was sniffing passwords. Several files contained nothing but hashes. I mention this because if we see a pattern across many sites, this entire conversation should move to security reports offline. Laura
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ?
http://drupal.org/project/md5check But this is a drupal module, and thus pretty useless, because it is part of the system that you're looking to stop being modified. Better to just hash some files on cron or something if you care to leave your drupal installation writeable by the web server. Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk 2010/1/27 Nicolas Tostin <nicolast@logis.com.mx>:
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ?
----- Original Message ----- From: "Laura" <pinglaura@gmail.com> To: <development@drupal.org> Sent: Wednesday, January 27, 2010 9:53 AM Subject: Re: [development] Fully patched site hacked and cloaked
On Jan 27, 2010, at Wed 1/27/10 4:45am, Gerhard Killesreiter wrote:
Were you able to determine the attach vector that was used to be able to modify bootstrap.inc?
I just saw this performed on a D5 site. Bootstrap.inc was indeed altered, an additional system.php file was inserted in the modules folder, and the pernicious (drug) website files were inserted into the cgi folder *above* the webroot. The code was sniffing passwords. Several files contained nothing but hashes.
I mention this because if we see a pattern across many sites, this entire conversation should move to security reports offline.
Laura
http://la-samhna.de/samhain/ if you have the resources to run it (its complex) Or, an afternoons work should have something nice going on if you use tripwire http://sourceforge.net/projects/tripwire/ Not sure how to do this on a shared host tho. On Wed, Jan 27, 2010 at 4:41 PM, Steven Jones < steven.jones@computerminds.co.uk> wrote:
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ?
http://drupal.org/project/md5check
But this is a drupal module, and thus pretty useless, because it is part of the system that you're looking to stop being modified. Better to just hash some files on cron or something if you care to leave your drupal installation writeable by the web server.
Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites
Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk
2010/1/27 Nicolas Tostin <nicolast@logis.com.mx>:
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ?
----- Original Message ----- From: "Laura" <pinglaura@gmail.com> To: <development@drupal.org> Sent: Wednesday, January 27, 2010 9:53 AM Subject: Re: [development] Fully patched site hacked and cloaked
On Jan 27, 2010, at Wed 1/27/10 4:45am, Gerhard Killesreiter wrote:
Were you able to determine the attach vector that was used to be able to modify bootstrap.inc?
I just saw this performed on a D5 site. Bootstrap.inc was indeed altered, an additional system.php file was inserted in the modules folder, and the pernicious (drug) website files were inserted into the cgi folder *above* the webroot. The code was sniffing passwords. Several files contained nothing but hashes.
I mention this because if we see a pattern across many sites, this entire conversation should move to security reports offline.
Laura
-- -- -- Steve Power Principal Consultant Mobile: +44 (0) 7747 027 243 Skype: steev_initsix www.initsix.co.uk :: Initsix Heavy Engineering Limited --
I'm hosting a few Drupal 5 & 6 installs on Rackspace Cloud Servers; so far, no problems, but I'll definitely be on alert now. Also FTR, I've seen a similar (but not quite identical) sort of attack on a xcart installation on another host. Thanks, Matt On Wed, Jan 27, 2010 at 8:56 AM, Steve Power <steev@initsix.co.uk> wrote:
http://la-samhna.de/samhain/ if you have the resources to run it (its complex)
Or, an afternoons work should have something nice going on if you use tripwire http://sourceforge.net/projects/tripwire/
Not sure how to do this on a shared host tho.
On Wed, Jan 27, 2010 at 4:41 PM, Steven Jones <steven.jones@computerminds.co.uk> wrote:
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ?
http://drupal.org/project/md5check
But this is a drupal module, and thus pretty useless, because it is part of the system that you're looking to stop being modified. Better to just hash some files on cron or something if you care to leave your drupal installation writeable by the web server.
Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites
Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk
2010/1/27 Nicolas Tostin <nicolast@logis.com.mx>:
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ?
----- Original Message ----- From: "Laura" <pinglaura@gmail.com> To: <development@drupal.org> Sent: Wednesday, January 27, 2010 9:53 AM Subject: Re: [development] Fully patched site hacked and cloaked
On Jan 27, 2010, at Wed 1/27/10 4:45am, Gerhard Killesreiter wrote:
Were you able to determine the attach vector that was used to be able to modify bootstrap.inc?
I just saw this performed on a D5 site. Bootstrap.inc was indeed altered, an additional system.php file was inserted in the modules folder, and the pernicious (drug) website files were inserted into the cgi folder *above* the webroot. The code was sniffing passwords. Several files contained nothing but hashes.
I mention this because if we see a pattern across many sites, this entire conversation should move to security reports offline.
Laura
-- -- -- Steve Power Principal Consultant Mobile: +44 (0) 7747 027 243 Skype: steev_initsix www.initsix.co.uk :: Initsix Heavy Engineering Limited --
On 1/27/2010 12:43 PM, Matt Chapman wrote:
Also FTR, I've seen a similar (but not quite identical) sort of attack on a xcart installation on another host.
I've seen the osc / xcart attack. They created a subdirectory in the image directory... /yahoo ... and put an index.php file in it. The file checked the query string for a value. If it wasn't there, it would simply display an osc heading. If the value was there, it grabbed a base64 value from the query string, decoded it, and called eval against it.
Is that possible with an up to date .htaccess? On Jan 27, 2010, at 1:57 PM, Jeff Greenberg wrote:
On 1/27/2010 12:43 PM, Matt Chapman wrote:
Also FTR, I've seen a similar (but not quite identical) sort of attack on a xcart installation on another host.
I've seen the osc / xcart attack. They created a subdirectory in the image directory... /yahoo ... and put an index.php file in it. The file checked the query string for a value. If it wasn't there, it would simply display an osc heading. If the value was there, it grabbed a base64 value from the query string, decoded it, and called eval against it.
On Wed, Jan 27, 2010 at 10:56 AM, Steve Power <steev@initsix.co.uk> wrote:
http://la-samhna.de/samhain/ if you have the resources to run it (its complex)
Or, an afternoons work should have something nice going on if you use tripwire http://sourceforge.net/projects/tripwire/
Not sure how to do this on a shared host tho.
BZR or any other version control with a little diff shell script (cron) would do the trip. -- Jason A. Nunnelley ---------------------------------------- http://www.jasonn.com http://www.tekany.com +1 256 297 1652
On Wed, 27 Jan 2010 13:10:00 -0600 "Jason A. Nunnelley" <jason@jasonn.com> wrote:
On Wed, Jan 27, 2010 at 10:56 AM, Steve Power <steev@initsix.co.uk> wrote:
http://la-samhna.de/samhain/ if you have the resources to run it (its complex)
Or, an afternoons work should have something nice going on if you use tripwire http://sourceforge.net/projects/tripwire/
Not sure how to do this on a shared host tho.
BZR or any other version control with a little diff shell script (cron) would do the trip.
Not "any" other or at least not in a "cheap" way[1]. svn stores informations inside the working copy. Anyway that would make hacking the site a bit harder. [1] you'd have to store the revision # somewhere outside the working copy and diff with the remote repo. Still if you're actively developing a site you'd have to find some way to compare working copy with a moving code base... and maybe glue everything with some rcs hook. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 2010-01-27, at 3:57 PM, Ivan Sergio Borgonovo wrote:
[1] you'd have to store the revision # somewhere outside the working copy and diff with the remote repo. Still if you're actively developing a site you'd have to find some way to compare working copy with a moving code base... and maybe glue everything with some rcs hook.
Just use a different branch for your live sites. I ran into exactly this same issue with a client, and sites in VCS were much quicker to deal with. Most hacks I've encountered recently used base64decode(), so grepping for that was helpful. As well, a .htaccess rule redirecting the advertising pages is a useful stopgap to prevent from being delisted. Finally, those running their own machines can set up a firewall to block outgoing connections for the Apache user except to specific hosts (updates.drupal.org, configured RSS feeds, etc). Also, be sure to check your PHP tmp directory, as there may be scripts there running re-infecting your site. --Andrew
On 2010-01-27 16:09, Nicolas Tostin wrote:
Is it a good security tip to monitor the integrity of Drupal sources by using MD5 hashes on the files ? Is there a known/efficient way to achieve this ?
We deploy some client sites by RPM. That implicitly supports timestamp and hash verification tools. -- David Strauss | david@fourkitchens.com | +1 512 577 5827 [mobile] Four Kitchens | http://fourkitchens.com | +1 512 454 6659 [office] | +1 512 870 8453 [direct]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laura schrieb:
On Jan 27, 2010, at Wed 1/27/10 4:45am, Gerhard Killesreiter wrote:
Were you able to determine the attach vector that was used to be able to modify bootstrap.inc?
I just saw this performed on a D5 site. Bootstrap.inc was indeed altered, an additional system.php file was inserted in the modules folder, and the pernicious (drug) website files were inserted into the cgi folder *above* the webroot. The code was sniffing passwords.
You mean the code was sniffing the passwords that the users entered into the Drupal site?
Several files contained nothing but hashes.
Password hashes? Or were these obfuscated scripts? Feel free to sent them to me in private. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktg3NwACgkQfg6TFvELooQw6gCferHAGyPCl4Ifed+x6r4eeMgT 0a4AnA8gb9Ms4X96Tss+8PnCsNTV4xVj =0uE0 -----END PGP SIGNATURE-----
I also wonder whether Drupal could be adjusted so as to automatically set file bootstrap.inc, and perhaps other critical ones, as read-only. So far it is done only with settings.php file.
Well if they did it via FTP, that wouldn't help... F
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point. There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a *man-in-the-middle attack.* Ultimately though it's a good example of how Drupal can only go so far in keeping itself secure but there are still plenty of other ways out side Drupals area of responsibility that your site can be compromised. ----- Adam A. Gregory Drupal Developer & Consultant Web: AdamAGregory.com Twitter: twitter.com/adamgregory Phone: 910.808.1717 Cell: 706.761.7375 On Wed, Jan 27, 2010 at 6:53 AM, Fred Jones <fredthejonester@gmail.com>wrote:
I also wonder whether Drupal could be adjusted so as to automatically set file bootstrap.inc, and perhaps other critical ones, as read-only. So far it is done only with settings.php file.
Well if they did it via FTP, that wouldn't help...
F
I had something similar happen on WordPress. It was a simple FTP (non-secure) password sniffer watching network traffic to the host. My site would get hacked within twenty minutes of making a change via FTP. I finally forced the hosting provider to support SFTP for my account. On Wed, Jan 27, 2010 at 7:14 AM, Adam Gregory <arcaneadam@gmail.com> wrote:
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point.
There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a man-in-the-middle attack.
Ultimately though it's a good example of how Drupal can only go so far in keeping itself secure but there are still plenty of other ways out side Drupals area of responsibility that your site can be compromised. ----- Adam A. Gregory Drupal Developer & Consultant Web: AdamAGregory.com Twitter: twitter.com/adamgregory Phone: 910.808.1717 Cell: 706.761.7375
On Wed, Jan 27, 2010 at 6:53 AM, Fred Jones <fredthejonester@gmail.com> wrote:
I also wonder whether Drupal could be adjusted so as to automatically set file bootstrap.inc, and perhaps other critical ones, as read-only. So far it is done only with settings.php file.
Well if they did it via FTP, that wouldn't help...
F
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
Sounds to me like Gumblar Virus see this link http://blog.scansafe.com/journal/2009/11/18/where-to-look-for-gumblar-backdo... David A. Shaver D. A. Shaver Web Design Web Page Design for Small Business www.dashaver.com PO Box 594 Galesburg,IL 61402-0594 309.343.0027 On Wed, Jan 27, 2010 at 8:22 AM, Ken Rickard <agentrickard@gmail.com> wrote:
I had something similar happen on WordPress. It was a simple FTP (non-secure) password sniffer watching network traffic to the host. My site would get hacked within twenty minutes of making a change via FTP.
I finally forced the hosting provider to support SFTP for my account.
On Wed, Jan 27, 2010 at 7:14 AM, Adam Gregory <arcaneadam@gmail.com> wrote:
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point.
There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a man-in-the-middle attack.
Ultimately though it's a good example of how Drupal can only go so far in keeping itself secure but there are still plenty of other ways out side Drupals area of responsibility that your site can be compromised. ----- Adam A. Gregory Drupal Developer & Consultant Web: AdamAGregory.com Twitter: twitter.com/adamgregory Phone: 910.808.1717 Cell: 706.761.7375
On Wed, Jan 27, 2010 at 6:53 AM, Fred Jones <fredthejonester@gmail.com> wrote:
I also wonder whether Drupal could be adjusted so as to automatically set file bootstrap.inc, and perhaps other critical ones, as read-only. So far it is done only with settings.php file.
Well if they did it via FTP, that wouldn't help...
F
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
On 01/27/2010 08:09 PM, David Shaver wrote:
Sounds to me like Gumblar Virus see this link http://blog.scansafe.com/journal/2009/11/18/where-to-look-for-gumblar-backdo...
David A. Shaver D. A. Shaver Web Design Web Page Design for Small Business www.dashaver.com <http://www.dashaver.com> PO Box 594 Galesburg,IL 61402-0594 309.343.0027
On Wed, Jan 27, 2010 at 8:22 AM, Ken Rickard <agentrickard@gmail.com <mailto:agentrickard@gmail.com>> wrote:
I had something similar happen on WordPress. It was a simple FTP (non-secure) password sniffer watching network traffic to the host. My site would get hacked within twenty minutes of making a change via FTP.
I finally forced the hosting provider to support SFTP for my account.
On Wed, Jan 27, 2010 at 7:14 AM, Adam Gregory <arcaneadam@gmail.com <mailto:arcaneadam@gmail.com>> wrote: > This is more a server security issue rather than a Drupal one. I've seen > this happen with Drupal, Joomla, Wordpress and custom PHP code. It really > most likely means that access to the server/host was compromised at some > point. > > There are lost of things that can be done to prevent this like chmod/own-ing > your file system correctly(As Gerhard touched on). This is also a good > reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted > and FTP are not leaving them open to a man-in-the-middle attack. > > Ultimately though it's a good example of how Drupal can only go so far in > keeping itself secure but there are still plenty of other ways out side > Drupals area of responsibility that your site can be compromised. > ----- > Adam A. Gregory > Drupal Developer & Consultant > Web: AdamAGregory.com > Twitter: twitter.com/adamgregory <http://twitter.com/adamgregory> > Phone: 910.808.1717 > Cell: 706.761.7375 > > > On Wed, Jan 27, 2010 at 6:53 AM, Fred Jones <fredthejonester@gmail.com <mailto:fredthejonester@gmail.com>> > wrote: >> >> > I also wonder whether Drupal could be adjusted so as to automatically >> > set >> > file bootstrap.inc, and perhaps other critical ones, as read-only. So >> > far it >> > is done only with settings.php file. >> >> Well if they did it via FTP, that wouldn't help... >> >> F > >
-- Ken Rickard agentrickard@gmail.com <mailto:agentrickard@gmail.com> http://ken.therickards.com
No Flame Wars, but using Linux prevents viruses ;) -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
I'm hearing some complicated attack vectors being tossed around in here (password sniffing, mitm, etc) -- don't forget about a pretty simple one: dictionary attacks. I recently took over a project for a small-medium sized client and upon looking at the secure log noticed 50k+/day dictionary attacks against SSH. I installed fail2ban and now get 5-6 emails daily about brute-force hack attempts. YMMV, but food for thought. -D
On Wed, Jan 27, 2010 at 1:03 PM, Domenic Santangelo <domenics@gmail.com> wrote:
I'm hearing some complicated attack vectors being tossed around in here (password sniffing, mitm, etc) -- don't forget about a pretty simple one: dictionary attacks. I recently took over a project for a small-medium sized client and upon looking at the secure log noticed 50k+/day dictionary attacks against SSH. I installed fail2ban and now get 5-6 emails daily about brute-force hack attempts.
Just wonder why you don't simply block attempts beyond 5 or 10. -- Jason A. Nunnelley ---------------------------------------- http://www.jasonn.com http://www.tekany.com +1 256 297 1652
On Wed, Jan 27, 2010 at 1:11 PM, Jason A. Nunnelley <jason@jasonn.com> wrote:
On Wed, Jan 27, 2010 at 1:03 PM, Domenic Santangelo <domenics@gmail.com> wrote:
I'm hearing some complicated attack vectors being tossed around in here (password sniffing, mitm, etc) -- don't forget about a pretty simple one: dictionary attacks. I recently took over a project for a small-medium sized client and upon looking at the secure log noticed 50k+/day dictionary attacks against SSH. I installed fail2ban and now get 5-6 emails daily about brute-force hack attempts.
Just wonder why you don't simply block attempts beyond 5 or 10.
If you are going to go through the effort of fail2ban and similar software why not use Public Key Authentication and call it good? Samir Nassar http://samirnassar.com
On Jan 27, 2010, at 11:31 AM, Samir Nassar wrote:
On Wed, Jan 27, 2010 at 1:11 PM, Jason A. Nunnelley <jason@jasonn.com> wrote:
On Wed, Jan 27, 2010 at 1:03 PM, Domenic Santangelo <domenics@gmail.com> wrote: Just wonder why you don't simply block attempts beyond 5 or 10.
That's more or less what fail2ban does, with some other options.
If you are going to go through the effort of fail2ban and similar software why not use Public Key Authentication and call it good?
Cause "yum install fail2ban" wasn't actually a lot of effort. -D
On Wed, 2010-01-27 at 11:42 -0800, Domenic Santangelo wrote:
If you are going to go through the effort of fail2ban and similar software why not use Public Key Authentication and call it good?
Cause "yum install fail2ban" wasn't actually a lot of effort.
I run a coop server where some of the clients are *NIX users, some clueful Windows users, and some clueless Windows users. The *NIX and clueful Windows users all use SSH and SFTP, but the clueless Windows users refuse to use PuTTY or anything like it because "Microsoft FrontPage supports FTP!!!!". (Not all the sites on the server are Drupal.) I agree fail2ban is good stuff. I installed it a few months ago and saw a dramatic decrease in dictionary attacks. The would-be crackers mostly give up and go away after fail2ban blocks them for a while. Scott -- Syscrusher <syscrusher@4th.com>
Syscrusher wrote:
On Wed, 2010-01-27 at 11:42 -0800, Domenic Santangelo wrote: I run a coop server where some of the clients are *NIX users, some clueful Windows users, and some clueless Windows users. The *NIX and clueful Windows users all use SSH and SFTP, but the clueless Windows users refuse to use PuTTY or anything like it because "Microsoft FrontPage supports FTP!!!!". (Not all the sites on the server are Drupal.)
Microsoft FrontPage FTP is just as insecure as any FTP. That's a horrible excuse. I'm sure you'll find that the recommended practice from any vendor if you have to use FTP is to use a VPN. There are lots of software packages which are easier to use than PuTTY for file transfer. I have convinced many non-technical clients to use WinSCP over the years; it's very similar to most Windows tools. If they're referring to "publishing" from FrontPage or another legacy software to the site via FTP, make them use stunnel or PuTTY tunneling or a local FTP to SFTP gateway. There are many good solutions to this problem. Speak up! You're responsible for the security of your servers, so don't let anyone else make poorly-informed security decisions in your name! If they won't do it, raise a stink and insist on a signed release of liability for the inevitable loss of business from using bad practices. Every compromised account gives these abusers more encouragement to keep writing new attacks. </fire and brimstone> JT
Fail2Ban automatically adds a iptables rule to block all traffic from the atacking address, and then sends off an e-mail informing you - so it does do that 2010/1/27 Jason A. Nunnelley <jason@jasonn.com>
On Wed, Jan 27, 2010 at 1:03 PM, Domenic Santangelo <domenics@gmail.com> wrote:
I'm hearing some complicated attack vectors being tossed around in here (password sniffing, mitm, etc) -- don't forget about a pretty simple one: dictionary attacks. I recently took over a project for a small-medium sized client and upon looking at the secure log noticed 50k+/day dictionary attacks against SSH. I installed fail2ban and now get 5-6 emails daily about brute-force hack attempts.
Just wonder why you don't simply block attempts beyond 5 or 10.
--
Jason A. Nunnelley ---------------------------------------- http://www.jasonn.com http://www.tekany.com +1 256 297 1652
On Wed, 27 Jan 2010 11:03:59 -0800 Domenic Santangelo <domenics@gmail.com> wrote:
I'm hearing some complicated attack vectors being tossed around in here (password sniffing, mitm, etc) -- don't forget about a pretty simple one: dictionary attacks. I recently took over a project for a small-medium sized client and upon looking at the secure log noticed 50k+/day dictionary attacks against SSH. I installed fail2ban and now get 5-6 emails daily about brute-force hack attempts.
Disable password login and/or move the port. Otherwise you risk to see yourself closed out of your own box. What could be worse, you may even not be the one who closed the door. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 01/27/2010 05:44 PM, Adam Gregory wrote:
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point.
There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a *man-in-the-middle attack.*
Ultimately though it's a good example of how Drupal can only go so far in keeping itself secure but there are still plenty of other ways out side Drupals area of responsibility that your site can be compromised. ----- Adam A. Gregory Drupal Developer & Consultant Web: AdamAGregory.com Twitter: twitter.com/adamgregory <http://twitter.com/adamgregory> Phone: 910.808.1717 Cell: 706.761.7375
On Wed, Jan 27, 2010 at 6:53 AM, Fred Jones <fredthejonester@gmail.com <mailto:fredthejonester@gmail.com>> wrote:
> I also wonder whether Drupal could be adjusted so as to automatically set > file bootstrap.inc, and perhaps other critical ones, as read-only. So far it > is done only with settings.php file.
Well if they did it via FTP, that wouldn't help...
F
Yeah, this is more of a server security related thing. The server must have been open at some port probably FTP with insecure settings. -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Gregory schrieb:
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point.
There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a *man-in-the-middle attack.*
People still using FTP in 2010 should be shot on sight. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktgTlgACgkQfg6TFvELooRIfwCgwXmcYXDzZUotmMu7IwYCDa3s T84An0Indo7tLq2M5RsoY7JlwsM0yhkw =cMDj -----END PGP SIGNATURE-----
On 01/27/2010 08:01 PM, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Adam Gregory schrieb:
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point.
There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a *man-in-the-middle attack.*
People still using FTP in 2010 should be shot on sight.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAktgTlgACgkQfg6TFvELooRIfwCgwXmcYXDzZUotmMu7IwYCDa3s T84An0Indo7tLq2M5RsoY7JlwsM0yhkw =cMDj -----END PGP SIGNATURE-----
*ahem* Public mirrors do use them ? FTP is good if you can configure it properly. It can be a big bug in the security as happened in this case if not configured properly :) -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
Yes, but you don't On Wed, Jan 27, 2010 at 9:35 AM, Nilesh Govindarajan <lists@itech7.com>wrote:
On 01/27/2010 08:01 PM, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Adam Gregory schrieb:
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point.
There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a *man-in-the-middle attack.*
People still using FTP in 2010 should be shot on sight.
Cheers, Gerhard
*ahem*
Public mirrors do use them ?
FTP is good if you can configure it properly. It can be a big bug in the security as happened in this case if not configured properly :)
Yes, but public mirrors do not require passwords. What Gerhard is talking about is uploading stuff to your site via an FTP account with a user name and password. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Thanks for feedback, esp. to Steve who had some fun excavating the malicious PHP code layer by layer. News (and some answers to various points in this thread): The site got hacked again today, despite all FTP password changes etc. Because (though that is of course an assumption, but a reasonable one) bootstrap.inc was read-only the hacker *created *bootstrap.php in the includes/ folder. Not sure there was a way to use it but still, it got created. The logs were flooded with entries like this: [27-Jan-2010 06:04:13] PHP Warning: file_get_contents( http://95.168.177.240/spyder/796f757468666f72756d2e6f7267667266726f75725f776...) [<a href='function.file-get- contents'>function.file-get-contents</a>]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in .../web/content/includes/bootstrap.php on line 1 I reloaded Drupal and modules again and blocked that IP range, etc. No, no real custom modules, just a few views hooks. So the question remains how did anyone managed to write in Drupal's directory. This is a RackspaceCloud/Mosso installation; I've raised the issue with them -- in case they've got a hole in Apache, but I think that's unlikely. I always use SSH (Port 22, WinSCP) but I am now investigating the possibility of some of my clients using insecure FTP, which of course would be a very likely attack vector. (It may be a work of a virus but it's hard to say it's Gumblar, as I assume the PHP code cared for redirect based on referer, so not the iframe solution.) Any further ideas are of course appreciated. And those on RackspaceCloud, check your bootstrap.inc files today. vacilando / Tomáš On Wed, Jan 27, 2010 at 15:43, Khalid Baheyeldin <kb@2bits.com> wrote:
Yes, but you don't
On Wed, Jan 27, 2010 at 9:35 AM, Nilesh Govindarajan <lists@itech7.com>wrote:
On 01/27/2010 08:01 PM, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Adam Gregory schrieb:
This is more a server security issue rather than a Drupal one. I've seen this happen with Drupal, Joomla, Wordpress and custom PHP code. It really most likely means that access to the server/host was compromised at some point.
There are lost of things that can be done to prevent this like chmod/own-ing your file system correctly(As Gerhard touched on). This is also a good reason to use SFTP rather then FTP as passwords in SFTP are sent encrypted and FTP are not leaving them open to a *man-in-the-middle attack.*
People still using FTP in 2010 should be shot on sight.
Cheers, Gerhard
*ahem*
Public mirrors do use them ?
FTP is good if you can configure it properly. It can be a big bug in the security as happened in this case if not configured properly :)
Yes, but public mirrors do not require passwords. What Gerhard is talking about is uploading stuff to your site via an FTP account with a user name and password. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Now that's very interesting. If all of the FTP passwords were changed, and the attackers still got in this easily, it's far less likely that they sniffed the use of an unencrypted changed FTP password so quickly than that they already access via some other means. Perhaps they cracked your SSH password? Or perhaps there was a backdoor installed on the server itself which gave them immediate access? Your suggestion that RackspaceCloud users check their installations is a good one; it sounds like these servers have security weaknesses which are easily exploited. On Wed, Jan 27, 2010 at 9:25 AM, Tomáš Fülöpp (vacilando.org) <tomi@vacilando.org> wrote:
The site got hacked again today, despite all FTP password changes etc. Because (though that is of course an assumption, but a reasonable one) bootstrap.inc was read-only the hacker created bootstrap.php in the includes/ folder. Not sure there was a way to use it but still, it got created.
I always use SSH (Port 22, WinSCP) but I am now investigating the possibility of some of my clients using insecure FTP, which of course would be a very likely attack vector.
Any further ideas are of course appreciated. And those on RackspaceCloud, check your bootstrap.inc files today.
vacilando / Tomáš
On Jan 27, 2010, at Wed 1/27/10 8:56am, Chris Johnson wrote:
And those on RackspaceCloud, check your bootstrap.inc files today.
Another data point: The site to which I referred in my previous email also is on the Rackspace Cloud. (Mosso.)
It seems there have been lots of people reporting problems with Rackspace so if anyone's using them I'd be very wary. Even TechCrunch was hacked a couple days ago: http://www.techcrunch.com/2010/01/26/techcrunch-hacked/ http://www.inquisitr.com/59036/techcrunch-hacked/ Dave Reid dave@davereid.net On Wed, Jan 27, 2010 at 10:07 AM, Laura <pinglaura@gmail.com> wrote:
On Jan 27, 2010, at Wed 1/27/10 8:56am, Chris Johnson wrote:
And those on RackspaceCloud, check your bootstrap.inc files today.
Another data point: The site to which I referred in my previous email also is on the Rackspace Cloud. (Mosso.)
On Wed, Jan 27, 2010 at 5:16 AM, Tomáš Fülöpp (vacilando.org) <tomi@vacilando.org> wrote:
Eventually I found that the file bootstrap.inc had been altered (without changing the time stamp!) -- a whole chunk of obfuscated PHP code was added at the top of the usual Drupal code.
Wow, that's a big head's up. Thanks for sharing! -- Jason A. Nunnelley ---------------------------------------- http://www.jasonn.com http://www.tekany.com +1 256 297 1652
participants (26)
-
Adam Gregory -
Andrew Berry -
Chris Johnson -
Dave Reid -
David Shaver -
David Strauss -
Domenic Santangelo -
Fred Jones -
Frederik Grunta -
Gerhard Killesreiter -
Ivan Sergio Borgonovo -
Jason A. Nunnelley -
Jeff Greenberg -
JT Justman -
Ken Rickard -
Khalid Baheyeldin -
Laura -
Matt Chapman -
Nicolas Tostin -
Nilesh Govindarajan -
Sam Tresler -
Samir Nassar -
Steve Power -
Steven Jones -
Syscrusher -
Tomáš Fülöpp (vacilando.org)