Michael Postado Abril 24, 2012 Compartilhar Postado Abril 24, 2012 No final deste tutorial irão algumas informações técnicas do porquê o bug ocorre, mas por enquanto iremos explicar o que isso pode acarretar, dependendo da configuração do seu servidor. Através de uma URL maliciosa, o atacante informa ao WHMCS para exibir o conteúdo de qualquer arquivo do sistema de arquivos que o WHMCS consiga acessar. Um arquivo importante, e que obviamente o WHMCS tem acesso, é o seu “configuration.php”. Neste arquivo estão as informações para acesso ao seu banco de dados (host, porta, usuário e senha). Nos sistemas onde o acesso é restrito somente ao localhost, isto é um pouco menos grave, pois o atacante ainda precisará de uma conta ou acesso local para manipular o seu banco de dados. Mas dependendo da configuração do seu servidor, ele permitirá acesso remoto, ou seja, o atacante neste momento tem acesso completo no seu banco de dados. Ok, o que isso proporciona a ele? Ele consegue efetuar login na sua seção de Administração, e se o seu WHMCS tiver dados de acesso para os servidores de autoconfiguração (exemplo a Access Hash do seu WHM), ele terá acesso completo nestes sistemas também. Ele também pode obter o seu banco de dados completo (clientes, planos), de forma a chantageá-lo futuramente, ou pode simplismente deletar tudo, de forma que se você não tiver backup, estará em sérios problemas. Pode enviar um email em massa denegrindo sua empresa, enfim, é um bug seríssimo. Além disso, se você não fez a troca da pasta de attachments para fora do seu diretório root web, ele pode através da manipulação do banco de dados, efetuar o upload de uma Backdoor PHP, o que lhe dá mais permissões ainda, permitindo a manipulação do sistema de arquivos, até mesmo podendo excluir ou fazer um deface em seu Website principal, não somente no WHMCS, em alguns casos. Em relação ao primeiro bug, é isto, abaixo teremos detalhes técnicos que podem ser interessantes para desenvolvedores Web, que não façam igual em suas aplicações. Note que é uma pequena distração na hora da codificação da página, com sérias implicações na segurança do software. Na página “cart.php”, por exemplo, temos o seguinte código: if ( $a == "add" ) { $templatefile = "configureproductdomain"; ....etc } if ( $a == "login" ) { $templatefile = "login"; ....etc } ... outputClientArea( $templatefile, $nowrapper ); Isto significa que a função outputClientArea irá exibir o seguinte arquivo: “./templates/orderforms/cart/{$templatefile}.tpl” Sendo que $templatefile é uma variável que é inicializada de acordo com uma condição pré-estabelecida. Porém, se esta condição não é cumprida, ex. “$a” recebe um valor não previsto: ?a=batatinha , o valor de $templatefile fica aberto a modificações pela URL: ?a=batatinha&templatefile=configuration.php (de maneira bruta, não irei especificar exatamente a maneira correta pois pode facilitar ações maliciosas). Ou seja, você especifica qual arquivo o sistema deverá exibir ao usuário. Isto é um defeito gravíssimo de software, e pode ser corrigido com a inicialização da variável: $templatefile = ""; if ( $a == "add" ) { $templatefile = "configureproductdomain"; ....etc } if ( $a == "login" ) { $templatefile = "login"; ....etc } ... outputClientArea( $templatefile, $nowrapper ); Isto ocorre também em outras páginas do sistema, e é parte culpa de uma rotina que faz a inicialização automática dos campos da URL para variáveis de mesmo nome (replicação do antigo comportamento da register_globals). Podemos dizer que isso ocorre por preguiça do desenvolvedor, de utilizar as superglobais ($_GET e/ou $_POST) somente quando um campo precisa ser lido do formulário, de fato. Muitos usuários sofreram com este problema, e muitos ainda estão vulneráveis e não fazem idéia. Há um patch liberado pelo desenvolvedor que deve ser aplicado, que está disponível na seguinte URL, dependendo da versão do seu WHMCS: 1) 4.0.x -> http://www.whmcs.com...p?type=d&id=107 2) 4.1.x -> http://www.whmcs.com...p?type=d&id=108 3) 4.2.x -> http://www.whmcs.com...p?type=d&id=109 4) 4.3.x -> http://www.whmcs.com...p?type=d&id=110 5) 4.4.x -> http://www.whmcs.com...p?type=d&id=111 6) 4.5.x -> http://www.whmcs.com...p?type=d&id=112 7) 5.0.x -> http://www.whmcs.com...p?type=d&id=113 Se você ainda não o aplicou, não perca tempo! A versão 5.0.3 já está com o patch aplicado. Relembramos que efetuamos este serviço e também a ressegurança do seu WHMCS após um ataque. Consulte-nos. Fonte: http://suportewhmcs.com.br/ Link para o comentário Compartilhar em outros sites More sharing options...
Jaime Silva Postado Abril 24, 2012 Compartilhar Postado Abril 24, 2012 Mas o arquivo cart.php não é protegido pelo Ioncube!? Como você conhece o conteúdo dele, hã, seu safadinho! :rolleyes: Não há bem nem mal que dure para sempre. Um dia tudo acaba. Link para o comentário Compartilhar em outros sites More sharing options...
avonni Postado Abril 24, 2012 Compartilhar Postado Abril 24, 2012 Ah, esse é o patch que foi disponibilizado no final de 2011! Pelo título do tópico dá entender que é uma falha recente. -_- Link para o comentário Compartilhar em outros sites More sharing options...
Cristian Augusto Postado Abril 24, 2012 Compartilhar Postado Abril 24, 2012 Mas o arquivo cart.php não é protegido pelo Ioncube!? Como você conhece o conteúdo dele, hã, seu safadinho! :rolleyes: Pelo que eu vi, o conteúdo do cart.php foi pego aqui http://suportewhmcs.com.br/ Link para o comentário Compartilhar em outros sites More sharing options...
Cristian Augusto Postado Abril 27, 2012 Compartilhar Postado Abril 27, 2012 Pessoal, tá tudo certo com o WHMCS de vocês? Os arquivos da pasta clientes (pasta do meu whmmcs) sumiram, literalmente. Link para o comentário Compartilhar em outros sites More sharing options...
Alexandre Duran Postado Abril 28, 2012 Compartilhar Postado Abril 28, 2012 Ah, esse é o patch que foi disponibilizado no final de 2011! Pelo título do tópico dá entender que é uma falha recente. -_- Porra quase infartei agora. Link para o comentário Compartilhar em outros sites More sharing options...
Posts Recomendados