iframe / javascript hacks?

[JamesSmith]

Originally Posted by ramprage

iframe attacks are pretty old actually, while the method in which they're impletmented varies, the effect is the same. To gain control of a wide array of site pages at once and launch a form of spyware, adware, malware or whatever else junk they want from the page rendering using another form of Zero day hole in something like your browser.

You really need to setup mod_security on your server with a custom ruleset. The exploit string in which you posted is really really old. Basically the attackers using a php include on a remote file that runs as if it were part of the code on the users page.

Any clients machines I secure and configure haven't been affected by this so it must be related to a few different things.

1) The attacker finds a hole in your users local PHP script
2) The inject their own PHP code from a remote file making it run as if they uploade the page by regular FTP.
3) There are numerous ways you can easily collect the usernames of accounts, very very very easy.
4) You can start to then brute guess passwords of user accounts
5) You can then start scouring the server for local exploits and use them to your advantage. EG: The script you metioned in that include checks to see if wget, gcc and other system binaries are on the system and asssible for the attacker to use.
6) With a list of whats installed and what they can use, they can now download hacks and start trying to crack your machine and compiling code attempting to gain root, etc.
7) They can search any and all 777 permission files/directories and inject whatever they feel like. Good times for them, crappy time for the site owners and server owners to clean up the mess.


Preventing this is a combination of things that I won't go into complete details about but I'll brief over so you get the idea.
1) Lock your system binaries, like wget, gcc, and others to stop anyone from using them.
2) Secure PHP by disabling functions used such as: proc_open, exec, system, passthru and so on.
3) Make sure PHP/Apache is up to date
4) Install mod_security and have CURRENT ruleset! Mod_security through cPanel install has NO ruleset! I have rulesets I give all my clients which are tried, tested and true.
5) Have a current kernel installed, there are many exploits that still work on a lot of providers.

There are tons you can do to help lock your machine. If you don't know, then hire someone that's what we're here for, besides our good looks of course

You failed to read my post entirely.

That is what cPanel "found" on the server, but it was completely irrelevant to what was happening. Out of 800 sites on one server 60 have had the "iframe" added to them and over half of these were simply .html single page sites, with no dodgy permissions and no PHP scripting at all.

The index files were downloaded over FTP and then 5 secs later re-uploaded. There is no manipulation of PHP or insecure scripts that is allowing them to FTP to these user accounts and the usernames are not being brute forced because there are no failed authentication attempts from the IPs that upload the amended and infected index files.

So the question is, how have the username + passwords been obtained in the first place.

[ramprage]

Originally Posted by JamesSmith

You failed to read my post entirely.

That is what cPanel "found" on the server, but it was completely irrelevant to what was happening. Out of 800 sites on one server 60 have had the "iframe" added to them and over half of these were simply .html single page sites, with no dodgy permissions and no PHP scripting at all.

The index files were downloaded over FTP and then 5 secs later re-uploaded. There is no manipulation of PHP or insecure scripts that is allowing them to FTP to these user accounts and the usernames are not being brute forced because there are no failed authentication attempts from the IPs that upload the amended and infected index files.

So the question is, how have the username + passwords been obtained in the first place.

Probably a insecure script in one of the 800 accounts.... with this I could easily get a list of users. Or, someone signed up for malicious reasons which happens but not as often. For example, a reseller client of yours has a automated account signup script...

If I compromise a single PHP script on a server I can get all the user accounts and start digging in users directories as well. Users usually make their account login password the same as MySQL passwords, etc.

As you can see, i'm just trying to offer suggestions and show you how easy getting into a system is.

[JamesSmith]

Originally Posted by ramprage

Probably a insecure script in one of the 800 accounts.... with this I could easily get a list of users. Or, someone signed up for malicious reasons which happens but not as often. For example, a reseller client of yours has a automated account signup script...

If I compromise a single PHP script on a server I can get all the user accounts and start digging in users directories as well. Users usually make their account login password the same as MySQL passwords, etc.

As you can see, i'm just trying to offer suggestions and show you how easy getting into a system is.

I'm well aware of how easy it can be to obtain sensitive information that could be used in a malicious way. But you didn’t bother to read post before you replied which riled me

As I said, some of the affected accounts are very basic one page html holding pages. No MySQL and no PHP.

[jack01]

Hi JamesSmith,

I think ramprage is saying that you CAN get the list of account user/pass via some script vulnerabilities, and hence go on to do any kind of mischief with these, such as the multiple FTP logins we have been discussing.

[JamesSmith]

You certainly *shouldnt* be able to do anything with the passwd file.

[ramprage]

JamesSmith - update to this.
Were you using ProFTP when your servers were affected or Pure-FTP?

[JamesSmith]

Originally Posted by ramprage

JamesSmith - update to this.
Were you using ProFTP when your servers were affected or Pure-FTP?

Yes and No.

We're aware there was an unpatched hole in ProFTPd at the time but we have since switched every server to Pure-FTPd. But we're still seeing possible instances of exploits appearing on the boxes with Pure-FTPd.

[Beansprout]

Could this be anything to do with it? http://secunia.com/advisories/24097/

Could affected people check /var/cpanel/objcache?

Doesn't seem like it's terribly useful, but it's all I can drag up to contribute

[JamesSmith]

Originally Posted by Beansprout

Could this be anything to do with it? http://secunia.com/advisories/24097/

Could affected people check /var/cpanel/objcache?

Doesn't seem like it's terribly useful, but it's all I can drag up to contribute

Nothing suspicious in that directory on any of our servers affected.

[Frankc]

I am no expert but maybe I found a potential problem.

The same happened with two different servers in different countries so I start digging and check any file that was modified on that particular date.

Except for the hacked/changed files as well as system files such as logs, on both servers I got the following.

./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBI/PurePerl.pm
./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBI/Gofer/Response.pm
./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBI/Gofer/Transport/Base.pm
./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/pipeone.pm
./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/http.pm
./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/Base.pm
./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/stream.pm


./usr/lib64/perl5/site_perl/5.8.0/DBD/Gofer/Policy/Base.pm
./usr/lib64/perl5/site_perl/5.8.0/DBD/Gofer/Policy/classic.pm
./usr/lib64/perl5/site_perl/5.8.0/DBD/Gofer/Policy/pedantic.pm
./usr/lib64/perl5/site_perl/5.8.0/DBI/ProfileDumper.pm
./usr/lib64/perl5/site_perl/5.8.0/DBI/Gofer/Request.pm
./usr/lib64/perl5/site_perl/5.8.0/DBI/Gofer/Transport/stream.pm
./usr/lib64/perl5/site_perl/5.8.0/DBI/Gofer/Transport/pipeone.pm

Anyone perhaps knows perhaps more about this please?

[katmai]

perl ? )

[tAzMaNiAc]

Ramprage --

Nice post, but that is not what is happening here.. We are having a cpanel root exploit no matter what. I have 3 servers experencing ALL the same thinga nd they are at C8800!!!!!!!!!!!!!!!!!!!!!!!!

Not to mention ftp logins at will -- probably using a "master" password cpanel left in for pure-ftpd use.. You know, how we all can still login ftp using our root password on any account? SAME IDEA!

Explaining it away as a list of excuses isnt gonna do any good.
The issue is -- it is not from a hack, it is not from a brute force (I have brute force detection.. nothing).. etc.. it is from a simple ONE time login, upload, mess, thats it.

Brenden

[jack01]

tAzMaNiAc, can you specify what PHP version, what FTP server (pure/pro)? Thanks.

[tAzMaNiAc]

PureFTPd is latest version (i forced it on all) 1.0.21 or something..

PHP is 4.4.4...

Brenden

[jack01]

OK, how about phpSuExec? and PHP Safe Mode? Thanks.