shared hosting and attacks [FWD: [funsec] HostGator: cPanel Security Hole Exploited in Mass Hack]
Hi, the following post is a forward of an email by Fergie to funsec. This story by itself is not relevant to NANOG, but it does illustrate a problem nearly all of us have been facing. Mass exploitation of servers in our nets, colos and hosting farms. Nearly ever (relevant, not say, just a transit one) ISP I spoke to globally has this problem. With thousands of sites on every server and virtual machines everywhere, all it takes is one insecure web application such as xxxBB or PHPxx for the server to be remote accessed, and for a remote connect-back shell to be installed. The rest is history. This is often soon followed with masses of defacements, spam, bots, ddos, etc. We all (well, never say all, every, never, ever, etc.), many of us face this. What solutions have you found? Some solutions I heard used, or utilized: 1. Remote scanning of web servers. 2. Much stronger security enforcement on servers. 3. "Quietly patching" user web applications without permission. 4. JGH - Just getting hacked. What have you encountered? What have you done, sorry, heard of someone else do, to combat this very difficult problem on your networks? The whole business of this hosting is the low cost, and everyone wastes countless man hours on killing fires. This is not about BGP, but it is an operational problem that bugs us, operators. Thanks, Gadi. ---------- Forwarded message ---------- Date: Sat, 23 Sep 2006 21:47:37 GMT From: Fergie <fergdawg@netzero.net> To: funsec@linuxbox.org Subject: [funsec] HostGator: cPanel Security Hole Exploited in Mass Hack Via Netcraft. [snip] HostGator says hackers compromised its servers using a previously unknown security hole in cPanel, the control panel software that is widely used by hosting providers. "I can tell you with all accuracy that this is definitely due to a cPanel exploit that provides root access and all cPanel servers are affected," said HostGator system administrator Tim Greer. "This issue affects all versions of cPanel, from what I can tell, from years ago to the current releases, including Stable, Release, Current and Edge." cPanel has just released a fix. "Running /scripts/upcp will fix the vulnerability in all builds," cPanel said in a message on its user forums. "Please note that this is a local exploit which requires access to a cPanel account. ... If you believe you have been exploited through this vulnerability, you are welcome to submit a support request for assistance." Hackers gained access to HostGator's servers late Thursday and began redirecting customer sites to outside web pages that exploit an unpatched VML security hole in Internet Explorer to infect web surfers with trojans. The existence of the new "0-day" exploit of cPanel leaves a large number of hosting companies vulnerable to similar attacks until they install the patch. The riusk is mitigated somewhat by the fact that it is a local exploit, meaning any attack on a host must be launched from an existing account with cPanel access. HostGator site owners said iframe code inserted into their web pages was redirecting users to the malware-laden pages. Company staff made several efforts to reconfigure servers on Friday, only to have the exploits recur. By early Saturday morning, HostGator managers were assuring users that the cause of the redirections had been isolated, and was due to a new exploit targeting cPanel. [snip] Link: http://news.netcraft.com/archives/2006/09/23/hostgator_cpanel_security_hole_... - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
On 24 Sep 2006, at 04:00, Gadi Evron wrote: [...]
With thousands of sites on every server and virtual machines everywhere, all it takes is one insecure web application such as xxxBB or PHPxx for the server to be remote accessed, and for a remote connect-back shell to be installed. The rest is history.
Hence why I'm rather partial to the ROT13 of a certain such application: cucOO. [...]
We all (well, never say all, every, never, ever, etc.), many of us face this. What solutions have you found?
Some solutions I heard used, or utilized: 1. Remote scanning of web servers.
Well, I *did* at one point have a script that looked for files with any of a list of MD5 sums and chmod them 000 if it found one. Grepping for "Matt Wright" in Perl scripts and chmodding them is also not a bad idea :)
2. Much stronger security enforcement on servers.
Actually, even bothering to use Unix user accounts rather than running everything under the Apache uid (or sometimes nobody or root!) would be a fine start.
3. "Quietly patching" user web applications without permission.
I would like to plead the Fifth at this point.
4. JGH - Just getting hacked.
This seems to be a popular enough technique, as long as the money still keeps rolling in, but not one I particularly subscribe to because the bad reputation gets round after a while.
What have you encountered? What have you done, sorry, heard of someone else do, to combat this very difficult problem on your networks?
Hacked accounts aren't evenly distributed over the customer base. A judiciously-applied account suspension or bollocking goes a long way.
participants (2)
-
Gadi Evron
-
Peter Corlett