Results 1 to 22 of 22
  1. #1

    /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.

  2. #2
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    14,135
    Because it's a CGI script, it doesn't seem as though there is an easy way to block this.
    mod_security rules would block this, however you'd have to have a pretty specific rule, as you can't really block the filename, it'll change constantly.
    Tom Whiting, WHMCS Guru extraordinaire
    Linux problems? WHMCS Problems? Give me a shout
    Check out my WHMCS Addons

  3. #3
    Any idea what kind of rule? I was told the same thing by someone else....

  4. #4
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by InfluxHost

    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.

    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

  5. #5
    Join Date
    Jul 2002
    Posts
    3,734
    Quote Originally Posted by InfluxHost
    A user is able to use WebShell.cgi :

    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.
    How is this accomplished? The scripts to add root privs to a reseller can't be accessed outside of WHM. They aren't in the /scripts directory.

  6. #6
    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.

  7. #7
    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.

  8. #8
    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.

  9. #9
    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.

  10. #10
    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.

  11. #11
    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.

  12. #12
    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.

  13. #13
    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.

  14. #14
    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?

  15. #15
    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.

  16. #16
    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.

  17. #17
    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.

  18. #18
    Join Date
    Jul 2002
    Posts
    3,734
    Quote Originally Posted by InfluxHost
    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.
    I know what you can do with the shell, so that won't surprise me. However, unless your server permissions were all screwed up, he wouldn't have been able to access the hash on the server itself.

    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)

  19. #19
    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

  20. #20
    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?

  21. #21
    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.

  22. #22
    Join Date
    Oct 2004
    Posts
    302
    Do you have mod_security rule for this?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •