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/

Mas o arquivo cart.php não é protegido pelo Ioncube!? Como você conhece o conteúdo dele, hã, seu safadinho! :rolleyes:

Ah, esse é o patch que foi disponibilizado no final de 2011!

Pelo título do tópico dá entender que é uma falha recente. -_-

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/

Pessoal, tá tudo certo com o WHMCS de vocês?

Os arquivos da pasta clientes (pasta do meu whmmcs) sumiram, literalmente.

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.