Results 1 to 21 of 21
  1. #1
    Join Date
    Oct 2007
    Posts
    240

    Anyway to protect server from C99MadShell or similar if uploaded?

    Ok, subject might be a little confusing, but what I mean is this. If you have a script exploited, like the recent vBulletin or past Wordpress or Joomla vulnerabilities that allow someone to upload and execute a shell program like C99MadShell or the like, is there any hardening of the server that would restrict the damage to a single cpanel user account (assuming Centos + cpanel)?

    If you have Suphp, SSH keys, etc., will it restrict the malicious code to only the exploited cpanel account, or with things like C99, if they find a vulnerability that allows them to upload and execute it, do they then have full control of your server?

    I'm not trying to clean a server, but instead cover all my bases to prevent such exploits from rooting a server in the future.

    Thanks
    BroncosForums - Broncos message board and live news feed

  2. #2
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    There's quite a lot of stuff you can do to help, all based along hardening the server. Hardening essentially consists of closing known holes and reducing attack opportunities.

    Suphp does more or less limit the access to the attacked account, which is why it's (or something similar is) considered essential for shared hosting. It does this by making PHP run as the user, and the user doesn't have access to other user accounts. There are ways around these restrictions (eg symlink attacks), but the point of hardening is to reduce these.

  3. #3
    Join Date
    Mar 2003
    Location
    Canada
    Posts
    9,072
    You gotta keep in mind that c99 shell is just fancy ways of doing what an attacker could do via SSH, CGI (Perl), PHP, Python and even Cron.

    If you want to prevent root compromises, outside of pure negligence on your part, you gotta keep everything up to date especially the kernel. c99 and all those PHP shells alone will not lead to a root compromise, but an existing local (or remote) vulnerability always will.

    Have you looked at CloudLinux? http://www.cloudlinux.com/

    While it's not the end all of security, it sure as hell will keep things safer especially if you have a lot of un-trusted users on your server - such as shared hosting. Running something like that will prevent one account from interfering with another account and should stop most local (root) vulnerabilities in their tracks.
    RACK911 Labs | Penetration Testing | https://www.RACK911Labs.ca

    www.HostingSecList.com - Security Notices for the Hosting Community.

  4. #4
    Join Date
    Oct 2007
    Posts
    240
    Thanks Patrick & Brian for the info. I definitely understand the importance of keeping scripts up to date, and implementing as many layers/safeguards (SSH keys, WAF, etc) to minimize access points.

    Following this vBulletin exploit with much interest, I know of a couple instances where sites that appeared to be everything right (SuPHP, SSH keys, up to date kernel, etc) were still compromised and the hackers got root level access. This surprised me, since I thought SuPHP was supposed to help prevent such things in a shared environment.
    BroncosForums - Broncos message board and live news feed

  5. #5
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by tnedator View Post
    Thanks Patrick & Brian for the info. I definitely understand the importance of keeping scripts up to date, and implementing as many layers/safeguards (SSH keys, WAF, etc) to minimize access points.

    Following this vBulletin exploit with much interest, I know of a couple instances where sites that appeared to be everything right (SuPHP, SSH keys, up to date kernel, etc) were still compromised and the hackers got root level access. This surprised me, since I thought SuPHP was supposed to help prevent such things in a shared environment.
    You had an exploit elsewhere in the server if they gained root through vbulletin.
    Exploiting vbulletin alone will not grant root access. Is it possible you password reused and your server password was your VB admin password?

    Ssh keys is not very secure when you factor in if they get your root password they can gain root ssh through whm.

    I can say with confidence VB is not how they gained root. It helped but its not how it was done. If it was as simple as VB then every host would be compromise because a simple shell would grant root.
    Last edited by Steven; 09-18-2013 at 08:34 PM.
    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

  6. #6
    Join Date
    Oct 2007
    Posts
    240
    Quote Originally Posted by Steven View Post
    You had an exploit elsewhere in the server if they gained root through vbulletin.
    Exploiting vbulletin alone will not grant root access. Is it possible you password reused and your server password was your VB admin password?

    Ssh keys is not very secure when you factor in if they get your root password they can gain root ssh through whm.

    I can say with confidence VB is not how they gained root. It helped but its not how it was done. If it was as simple as VB then every host would be compromise because a simple shell would grant root.
    Which was my understanding, which is the reason I'm trying to understand what might have happened.

    As I understand it, the install directory compromise in vB allowed vB admin access, and then a plugin was created, that had Base64 code that installed C99MadShell, among possibly other things. Angel_bc and some other files were then uploaded to /tmp, and sometime after that a centos account was created and elevated to superuser.

    The server in question had SuPHP, mod_security, CSF, no common passwords with vB accounts, a strong, non-dictionary based root password, etc.
    BroncosForums - Broncos message board and live news feed

  7. #7
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Are you absolutely without a doubt sure your kernel was patched at time of compromise? Some bad exploits this year.

    Lots of Cpanel plugin exploits too that would grant root access.
    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

  8. #8
    Join Date
    Oct 2007
    Posts
    240
    According to host, yes, but I can't say with 100% certainty.

    So, bottom line, even if a script like vB, Wordpress or the like allows for injecting and running base64 code that loads something like C99, should not be able to get around SuPHP and the other layers of security, unless there is additional vulnerability(s) that are exploited?
    BroncosForums - Broncos message board and live news feed

  9. #9
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    I would take the hosts word with a grain of salt. So many compromises we see are due to one person saying one thing and another thing actually happening. Most likely was the kernel. Recent exploits are being used pretty extensively right now.

    Yes you would need a system level exploit. A php script alone is not going to grant root access.
    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

  10. #10
    Join Date
    Oct 2007
    Posts
    240
    Quote Originally Posted by Steven View Post
    I would take the hosts word with a grain of salt. So many compromises we see are due to one person saying one thing and another thing actually happening. Most likely was the kernel. Recent exploits are being used pretty extensively right now.

    Yes you would need a system level exploit. A php script alone is not going to grant root access.
    Ok, good or bad, that at least is somewhat re-assuring. So, it's probably a case where the server's initial vB compromise, simply opened the path to load a php script/shell that then used a system level exploit.
    BroncosForums - Broncos message board and live news feed

  11. #11
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by tnedator View Post
    Ok, good or bad, that at least is somewhat re-assuring. So, it's probably a case where the server's initial vB compromise, simply opened the path to load a php script/shell that then used a system level exploit.
    Yep, exactly.
    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

  12. #12
    Join Date
    Mar 2006
    Location
    Servers
    Posts
    1,590
    Use mod_security to avoid PHP shells of being uploaded to the server or executed. May limit exec/shell_exec PHP functions as well. Also clamav is identifying some of the shells you can run it via cron to be informed if this happen.
    QHoster.com - Web Hosting with DDoS Protection | Shared & Reseller in Europe/North America
    Linux/Windows RDP VPS 13 Locations : UK, US (5 states), Mexico, Canada, Bulgaria, Lithuania,
    Italy, France, Germany,Netherlands, Switzerland, Rissia, Singapore | OpenVPN/PPTP Enabled
    INSTANT | PayPal, Skrill, Payza, Bitcoin, WebMoney, Perfect Money, Ukash, CashU, paysafecard

  13. #13
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by WebHostDog View Post
    Use mod_security to avoid PHP shells of being uploaded to the server or executed. May limit exec/shell_exec PHP functions as well. Also clamav is identifying some of the shells you can run it via cron to be informed if this happen.
    This helps to an extent. However a simple 3 lines perl script could be uploaded, so the php functions won't limit anything, mod security may not detect it, and clamav will definitely not see it.
    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

  14. #14
    Join Date
    Mar 2006
    Location
    Servers
    Posts
    1,590
    Quote Originally Posted by Steven View Post
    This helps to an extent. However a simple 3 lines perl script could be uploaded, so the php functions won't limit anything, mod security may not detect it, and clamav will definitely not see it.
    If you limit everything yes this will kill all the functionality. Also can check this product:

    http://www.configserver.com/cp/cxs.html

    Well configured it will help you fighting
    QHoster.com - Web Hosting with DDoS Protection | Shared & Reseller in Europe/North America
    Linux/Windows RDP VPS 13 Locations : UK, US (5 states), Mexico, Canada, Bulgaria, Lithuania,
    Italy, France, Germany,Netherlands, Switzerland, Rissia, Singapore | OpenVPN/PPTP Enabled
    INSTANT | PayPal, Skrill, Payza, Bitcoin, WebMoney, Perfect Money, Ukash, CashU, paysafecard

  15. #15
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by WebHostDog View Post
    If you limit everything yes this will kill all the functionality. Also can check this product:

    http://www.configserver.com/cp/cxs.html

    Well configured it will help you fighting
    Again, these things only work so much. There is so many ways it can be defeated.
    Yes these things do help, but it is wise to assume it will not catch everything.
    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

  16. #16
    Join Date
    Mar 2006
    Location
    Servers
    Posts
    1,590
    If you have really broken WordPress and Joomla may be they are not. Mod_security should catch the perl code I assume. Also most of the hacks are totally automated. I doubt it somebody will start engineering how to hack you in particular. If the shell code is custom smart design may be no chance of being caught again. So may be the whole idea is to limit the possibility instead of fully avoid/block such threats.
    QHoster.com - Web Hosting with DDoS Protection | Shared & Reseller in Europe/North America
    Linux/Windows RDP VPS 13 Locations : UK, US (5 states), Mexico, Canada, Bulgaria, Lithuania,
    Italy, France, Germany,Netherlands, Switzerland, Rissia, Singapore | OpenVPN/PPTP Enabled
    INSTANT | PayPal, Skrill, Payza, Bitcoin, WebMoney, Perfect Money, Ukash, CashU, paysafecard

  17. #17
    Join Date
    Apr 2007
    Location
    Everywhere
    Posts
    273
    As others said, There is a lot that can be done.

    Having a WAF (I.E: mod_security) with a decent ruleset is certainly going to help and block a lot of malicious requests. It can be configured to alert and email you about any attempts so it can be used as an intrusion detection system too which provides early alerting and notifications.

    You can tweak your php.ini config file and a properly tweaked php.ini is going to help.

    So, Rule #1 Make sure safeguards and controls are in place with decent configurations.

    If your site/account doesn't use or require cgi/perl then disable and restrict it's usage on the server. Rule #2 enable what you need and what you use only. Follow the need to know/Need to have methodology.

    Also, You need to set correct permissions on your files/binaries (Rule#3 least privilege)

    Rule #4 , Follow best practices and keep everything updated.

  18. #18
    Join Date
    Aug 2005
    Location
    Egypt
    Posts
    111
    install cxs
    GNU/Linux system Engineer
    Contact Me: 00201003338749

  19. #19
    Join Date
    Mar 2013
    Location
    North and South America
    Posts
    192
    Mr. Ciaburri is right. And you are wise to want to learn what happened.

    Good tools and a solid hardening are wonderful, but you need regular log review and the knowledge to use the tools that are installed. Hiring a pro to set things up and help you learn how to review things would be wise.

    Solid hardening. Monitoring and and educating users to keep scripts updated. Knowing what scripts are vulnerable. Mod security with good rules, CXS (aggressively tuned with log review and followup to investigate). Good isolation and proper permissions. Regular strong password rotation, for you and encouragement for the same to your users.

    Start with expert assistance and learn to do it yourself, even if you always have pros do it.
    Last edited by gPowerHost; 09-21-2013 at 08:47 PM. Reason: typo

  20. #20
    You can block certain critical strings from the files code. By Googeling the string, make sure that it isn't used for any other important scripts.

    How was the file uploaded? Security hole / FTP got hacked?

  21. #21
    Join Date
    Mar 2013
    Location
    North and South America
    Posts
    192
    Great point. You can use ConfigServer eXploit Scanner (CXS) along with good rules and a scanning schedule to either block certain things (critical strings) when uploaded and/or upon daily scan. The blocked files can go to quarantine and you can easily view the file and either return in (and approve the checksum) or delete it. We review the quarantine on every server daily (right after the run). We catch a great deal of stuff and false positives can easily be added to a whitelist (in a variety of ways). CXS isn't free to install but it isn't expensive (one time setup) and it catches so much!

Similar Threads

  1. Tracking down who uploaded a file to a server?
    By Christian Little in forum Hosting Security and Technology
    Replies: 4
    Last Post: 09-20-2011, 12:09 PM
  2. Hacked By C99madshell
    By mwoody in forum Hosting Security and Technology
    Replies: 7
    Last Post: 06-03-2011, 08:40 PM
  3. FTP ISSUE: files uploaded "not uploaded", disconnect
    By wheimeng in forum Hosting Security and Technology
    Replies: 6
    Last Post: 10-13-2005, 06:55 PM
  4. Virus was uploaded to my server.
    By host-pod in forum Hosting Security and Technology
    Replies: 6
    Last Post: 01-30-2005, 11:04 PM
  5. Replies: 5
    Last Post: 08-05-2001, 10:50 PM

Posting Permissions

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