Michael Posted April 24, 2012 Share Posted April 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 to comment Share on other sites More sharing options...
Jaime Silva Posted April 24, 2012 Share Posted April 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 to comment Share on other sites More sharing options...
avonni Posted April 24, 2012 Share Posted April 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 to comment Share on other sites More sharing options...
Cristian Augusto Posted April 24, 2012 Share Posted April 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 to comment Share on other sites More sharing options...
Cristian Augusto Posted April 27, 2012 Share Posted April 27, 2012 Pessoal, tá tudo certo com o WHMCS de vocês? Os arquivos da pasta clientes (pasta do meu whmmcs) sumiram, literalmente. Link to comment Share on other sites More sharing options...
Alexandre Duran Posted April 28, 2012 Share Posted April 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 to comment Share on other sites More sharing options...
Recommended Posts