Results 1 to 22 of 22
-
01-14-2007, 01:59 PM #1Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
/scripts vulnerability using WebShell.cgi
A user is able to use WebShell.cgi :
[url removed]
In order to run commands from the /scripts folder. This is especially dangerous as a user can give an account reseller priviledge with full root access.
Because webshell.cgi is running with the uid/gid of apache, it can access all files which can be access with apache. And guess what.... the /scripts folder is one of them.
Because it's a CGI script, it doesn't seem as though there is an easy way to block this.
However, can anyone prove me wrong?Last edited by bear; 01-14-2007 at 05:02 PM.
-
01-14-2007, 02:11 PM #2Because it's a CGI script, it doesn't seem as though there is an easy way to block this.Tom Whiting, WHMCS Guru extraordinaire
Linux problems? WHMCS Problems? Give me a shout
Check out my WHMCS Addons
-
01-14-2007, 02:27 PM #3Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
Any idea what kind of rule? I was told the same thing by someone else....
-
01-14-2007, 03:00 PM #4Problem Solver
- Join Date
- Mar 2003
- Location
- California USA
- Posts
- 13,681
Originally Posted by InfluxHost
are you not using suexec? cgi scripts should run as the users account.Steven Ciaburri | Industry's Best Server Management - Rack911.com
Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance
-
01-14-2007, 04:05 PM #5Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
Originally Posted by InfluxHost
-
01-14-2007, 04:25 PM #6Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
Suexec is running.
Andrew, they can still be accessed. I saw it done, and have reproduced it.
Try uploading the ShellWeb.cgi into a cgi-bin and you'll be able to browse around your entire server.
-
01-14-2007, 04:34 PM #7Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
What exactly have you seen done?
Can I see a log of it?
Much of the the things in /scripts are not actually used in WHM. You will find that many of the times that WHM calls /scripts/whatever , the script itself does not exist and it is sending commands to a compiled binary instead of using a script in /scripts. That's what it is also doing whenever it access the nonexistent /scripts2 directory.
-
01-14-2007, 04:39 PM #8Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
I'll add that those commands and nonexistent scripts are not usable from the command line for anyone.
You can use the ones that exist, like wwwacct, which doesn't complete it's task, but is runable for any user. However, adding privs to resellers is done in the manner I described above, NOT with one of the scripts in /scripts. Therefore, I would very much like to know how you accomplished adding root reseller privs to an account in this manner.
-
01-14-2007, 04:41 PM #9Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
127.0.0.1 - root [12/Jan/2007:23:19:29 -0500] "GET /scripts/wwwacct?remote=1&nohtml=1&username=USERACOUNT&password=__HIDDEN__&domain=DOMAIN.com&plan= HTTP/1.1" 0 "" ""
127.0.0.1 - root [12/Jan/2007:23:19:30 -0500] "GET /scripts/addres?res=USERACCOUNT HTTP/1.1" 0 "" ""
127.0.0.1 - root [12/Jan/2007:23:19:30 -0500] "GET /scripts2/editressv?res=USERACCOUNT&acl-all=1 HTTP/1.1" 0 "" ""
What can you say about this? USERACCOUNT is where an actual username was turned into a reseller. From the apache logs, we see the use of WebShell.cgi from the account.
-
01-14-2007, 04:44 PM #10Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
That is a log, presumably from /usr/local/cpanel/logs/access_log that shows someone accessing those scripts FROM WHM, NOT from any script.
If they accessed those commands from WHM, they likely already had root.
-
01-14-2007, 04:51 PM #11Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
The user most definately did not have root, otherwise they wouldn't be looking to give a reseller root priviledge.
Look at the times in between the 3. They are different by 1 second, and the last 2 are within the same second.
You can't tell me those were done by a human...
We have more logs showing the same user using WebShell.cgi
Before those commands were executed that were shown in the logs I gave, there was no access to WHM, only cPanel. After they added the reseller with root privs, they were in WHM.
-
01-14-2007, 04:53 PM #12Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
Run the commands, man. Try them. They won't work.
Hell, go as root and try and run:
/scripts2/editressv
There is no such script. It must be run one of two ways:
1) WHM
2) The WHM remote accounting features.
-
01-14-2007, 04:58 PM #13Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
He even used the secure WHM port to run these commands, which is why it is reading as 127.0.0.1 in the logs.
Look at the logs you posted. He already was logged in as root when he gave the other account permissions.
-
01-14-2007, 05:00 PM #14Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
What are the WHM remote accounting features?
So how do you explain they ran those commands? There was no logins via root, not to mention we have root SSH disabled.
On top of that APF was blocking port 2986 and 2087, restricting it with the allow filter. Yet somehow they were able to logon to WHM...
Any ideas?
-
01-14-2007, 05:02 PM #15Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
Excuse me, he wasn't logged as root.
He used the remote accounting features of WHM, apparently with your root access hash.
This can be seen by the presence of the remote and nohtml variables in the log, as well as the GET method being used instead of POST.
How'd he get that access hash is the question.
-
01-14-2007, 05:09 PM #16Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
Maybe the fact that with WebShell.cgi you can browse the entire server, open /etc/passwd? This would make sense no?
You should check out the file and see what you can do with it, you'd be surprised.
-
01-14-2007, 05:10 PM #17Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
He was either allowed by your rules, or it's also possible that blocking 2087 doesn't do any good with the way stunnel works.
The remote access features are sort of an API for WHM, so you can control it from remote machines. When you look in root WHM and see 'setup remote access key', what you are setting up in there is an access hash that this guy managed to get a hold of somehow and used it to access your server.
This could be done if the person had rooted another one of your machines that had a dns relationship set up with this server.
Also, if your billing system creates accounts automatically, check your it for signs of compromise. Check the logs and make sure nobody's been messing with it. To me, that seems like it would be the weakest link to me and the most likely culprit.
-
01-14-2007, 05:17 PM #18Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
Originally Posted by InfluxHost
Try with the cgi script to cd /root/
You should see 'permission denied'.
The WHM access hash for root is stored at /root/.accesshash and is unreadable to any user that doesn't have root. (unless, like I said, the perms are screwed)
-
01-14-2007, 05:28 PM #19Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
Right, I do get a permission denied.
Therefore you think they got the hash from ModernBill or something to the sort in order to run those commands? I do run a secure version of ModernBill and know for a fact no one has access to it.
Not to mention while searching the apache logs of his IP, the only things that came up was his access to that WebShell.cgi
-
01-14-2007, 05:34 PM #20Web Hosting Master
- Join Date
- Jul 2002
- Posts
- 3,734
I'd look at modernbill, yes. If he was able to guess your password for modernbill, he could get in.
Was all this stuff on the same machine?
-
01-14-2007, 05:39 PM #21Junior Guru Wannabe
- Join Date
- Dec 2002
- Posts
- 39
It did happen on 2 servers...
However looking at the access_log of apache, it doesn't seem they ever went to my billing system.
-
01-15-2007, 08:38 PM #22Web Hosting Guru
- Join Date
- Oct 2004
- Posts
- 302
Do you have mod_security rule for this?