The old JavaScript cPanel Server exploit »

The Javascript exploit has been an old saga on a few Linux distros running cPanel and Plesk .

The compromise is at the root level and a rootkit has been installed. This rootkit will attach to several syscalls within the kernel and begin serving malicious javascript to random web visitors.

This root compromise is not related to cPanel directly, as it has been reported on many different control panels on many different servers. The compromise is at the system level, and only Redhat 4, CentOS 4, and FC6 appear to be vulnerable at this time. We are actively researching this issue and will have an in-depth analysis of current information posted soon.

http://forums.cpanel.net/showthread.php?t=74963&page=10&highlight=centos5

The easiest way to confirm the compromise is to attempt to make a directory with a numerical name. Run ‘mkdir 1’ or ‘touch 2’. If this fails with an error similar to the errors below, then it’s recommended to contact your datacenter, NOC or a qualified admin who can recover the system properly.

Code:

[root\@cpanel ~]# mkdir 1
mkdir: cannot create directory `1': No such file or directory
[root\@cpanel ~]# touch 2
touch: cannot touch `2': No such file or directory

__________________

These attacks have started slowing down as the attackers behind this know the heat is on. They appear to be changing a few parts of the attack to make it much harder to notice. If anyone feels they are infected, please run the tcpdump command below to briefly watch the web requests for the javascript being served.

More details can be found at http://www.cpanel.net/security/notes…s_toolkit.html

Code:

tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"

This command on a server infected by this specific rootkit will result in something similar to:

Code:

root@server log]# tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 2048 bytes
<script language='JavaScript' type='text/javascript' src='ateyc.js'></script>
<script language='JavaScript' type='text/javascript' src='taopp.js'></script>
1311 packets captured
2627 packets received by filter
0 packets dropped by kernel

__________________
Todd Shipway
cPanel Technical Support

Another is to check your outgoing packets,

Quote:

tcpdump -nAs 2048 src port 80 | grep “[a-zA-Z]\{5\}\.js'”

For older versions of tcpdump (Such as the ones provided with RHEL3/centOS3)

Quote:

tcpdump -XX -ns 2048 src port 80 | grep “[a-zA-Z]\{5\}\.js'”

The grsecurity fix people are mentioning does not remove this, it simply stops it from writing to /dev/mem (or /dev/kmem depending on what is available) however the second you boot out of this kernel you are likely to be vulnerable again.

The rootkit itself is rather simple in terms of how it actually functions, it uses common binaries as listed in the article (there’s another binary not listed from the older variants of this [that don’t prevent the numbers at the start of file names/directories]). Replacing those binaries in the manner suggested is not the safest option and there is not always a copy, you should replace these from the binaries from your distribution. In the particular case it’s actually rather easy to do , simply remove the attributes to the files, remove the files themselves(not needed, but do it anyway) and then reinstalled the RPM’s (As this is always on an RPM based distribution) there’s only 3 rpm’s that are needed to be reinstalled.

Lastly, if you are not comfortable working with the kernel/debuggers then HIRE A QUALIFIED ADMINISTRATOR there’s plenty of them out there

Project Datum’s DAT Token: How’s it Flowin’?

Emblematic Group and Mozilla Team Up to Showcase Next Generation of Storytelling on the Web

Strikes, Boycotts, and Outages Mar Amazon Prime Day

Dott raises $34 million to build a sustainable scooter startup

Spread the love