Dicas de segurança em sites WordPress e CMS (Content Management System)
Ter um blog ou um site baseado em CMS é hoje em dia comum. Praticamente toda a gente já fez um site ou um blog ou já testou Joomla entre outros programas do mesmo género; o mal destes programas é serem extremamente populares e são open source.
Um CMS, por ser open source e de acesso público, pode ser explorado até à sua exaustão por um técnico de segurança que vai encontrar bugs facilmente caso existam. No caso ele não tivesse acesso ao source levaria mais tempo a encontrar erros e teria de fazer scans exaustivos a sites com esse programa e encontrar erros padrão. Desta forma o mundo aberto dos CMS leva-nos por vezes a abrir as portas do nosso servidor ao que der e vier.
Um dos maiores problemas que afectam o mais conhecido CMS do mundo, o Joomla, prende-se não no Joomla em si nem no Mambo, mas sim nos seus componentes ou outros addons que este CMS suporta. Já em fóruns de segurança e em conversa com amigos que tenho na net, alguns técnicos de segurança do Japão e peritos em SQL injection, chegámos a uma conclusão de que muitos componentes têm os mesmos autores e que descaradamente publicam novos componentes ou actualizações com os mesmos erros de forma repetida.
Isto significa que muitos dos erros que os sites da família Mambo sofrem podem mesmo ser premeditados em mais de 90% dos casos, assim, hackers podem em primeira mão, antes das falhas de segurança serem publicadas, lançar um update malicioso do seu componente o que permite às grandes empresas utilizar, e aceder em primeira mão, a falhas que dão acesso ao source de ficheiros, por exemplo em php, jsp (em alguns sites), ou mesmo fazer uma injecção SQL e obter desta forma os e-mails de todos os utilizadores ou as passwords que estão em hashes de MD5 na maioria dos casos e podem ser crackadas por bruteforce, com a utilização de serviços como www.plain-text.info / www.md5sha1.com / rainbow tables (este último, um pouco parecido com projectos como seti@home) entre muitos outros.
A prevenção e a precaução de quem utiliza este tipo de sites passa por diversos passos como por exemplo ter uma password extremamente complexa e utilizá-la apenas para o seu site e não para o site, o mail, o pin do telemóvel ou mesmo para tudo.
Há bons geradores de passwords no mercado e não se preocupe se a sua password tem maiúsculas, minúsculas, letras e números e um tamanho superior a 20 caracteres, guarde-a em local seguro e não a dê a ninguém. Desta forma mesmo que alguém obtenha a sua hash em md5, o seu site poderia estar seguro no que diz respeito à password, mas se quem o ataca chegar à sua hash md5 também poderá “roubar” os e-mails da base facilmente.
A utilização dos componentes deve ser feita apenas quando necessária e todos os componentes que não sejam utilizados devem ser removidos. Já encontrei vulnerabilidades em sites com módulos por exemplo de listagem de imagens que não eram utilizados.
Como o hacker ou mesmo uma criança com alguns conhecimentos básicos (script kiddies/google dorks) encontra uma vulnerabilidade em joomla?
Encontramos um bug e respectivo exploit sobre o componente “com_paxxgallery” que lista álbuns e imagens em joomla. Procuramos então no google de forma inicial em google.pt / páginas de Portugal por:
allinurl:”com_paxxgallery” “userid”
Isto significa que o endereço do site TEM que conter exactamente esta expressão que procuramos.
Obtivemos cerca de 8300 resultados na pesquisa mundial. Na portuguesa apenas um site e não é vulnerável porque foi actualizado. Logo na primeira pesquisa encontramos o site gardeninginsouthafrica.co.za que após injecção de SQL é possível ver os seus utilizadores e passwords encriptadas.
E está feito, em segundos encontramos um site vulnerável e agora alguém com intenções maliciosas poderá listar os administradores e creckar a hash – ad8f5412159c816d3509a1a55a994f38 – que representa a password de super-administrador para 2 utilizadores neste site. Provavelmente eles também poderão utilizar a mesma pass no seu mail, site de banco caso tal seja permitido etc.
E aqui está o verdadeiro problema: um hacker inteligente irá utilizar esta informação, guardá-la e verificar com frequência o site em vez de fazer um Deface e ganhar crédito. Um deface consiste em alterar a página do site em questão introduzindo alguma mensagem à escolha pelo hacker, para chamar a atenção, por birra, ou por outro qualquer motivo.
ESTA LISTA NÃO ESTÁ POR ORDEM DE PRIORIDADES!
- Dicas para WordPress
0 – Esta nem conta, manter o site sempre actualizado.
1 – Ninguém poder ter permissão de fazer pesquisas no servidor, apenas no site e dependendo da zona e permissão desse membro, quer seja guest, (em linux ~nobody e com permissões muito limitadas, mas caso não tenha hosting dedicado esqueça isto) quer seja membro do site. Portanto na sua pesquisa NUNCA utilize este código e caso ele exista remova-o ou altere-o no seu search.php
<?php echo $_SERVER [’PHP_SELF’]; ?>
Em vez disso utilize: <?php bloginfo (’home’); ?>
2- Outro código utilizado em tags de titulo ou templates de pesquisa
<?php echo $s; ?>
Este código permite execução ou injecção de comandos remotos sem necessidades de autenticação. Deverá utilizar:
<?php echo wp_specialchars($s, 1); ?>
3- Evite utilizar a tema que vem com o WordPress por defeito – Kubrick – Foram descobertos bugs recentemente neste tema. Um dos bugs reconhecidos:
/themes.php?page=functions.php
4- Style Switcher – A forma mais fácil
- Faça o download deste javascript
- Faça o upload do style switcher para a sua pasta de temas (pasta js)
- Copie o stylesheet do seu tema e altere o nome dele para style2
- Insira o javascript no header da página:
<script src=”<?php bloginfo(’template_directory’); ?>/js/ style-switch.js” type=”text/javascript”></script>
- Insira as duas stylesheets no seu header:
<link rel=”stylesheet” href=”<?php bloginfo(’stylesheet_url’); ?>” type=”text/css” title=”default” media=”screen” />
<link rel=”alternate stylesheet” type=”text/css” media=”screen” title=”style2″ href=”<?php bloginfo(’template_directory’); ?>/style2.css” />
Repare que a diferença é entre o titulo “default” para o seu stylesheet básico e para o segundo titulo “style2″. Varie o seu stylesheet básico aplicando novas regras ao seu id e classes.
Faça Upload das novas imagens do seu tema (se necessário)
Insira o script:
Styles: <a rel=”no follow” title=”Toggle stylesheets” href=”javascript : chooseStyle(’none’, % 20 60)”>#000</a>
5- Bloqueie search robots na sua página de arquivos prevenindo indexar os mesmo:
<?php if(is_archive()) { ?><meta name=”robots” content=”noindex”><?php } ?>
Cole o código onde quiser no header do seu tema actual antes do tag de fecho do header.
6 – Não permita que seja visível a versão do seu wordpress nas MetaTags do seu site, isto é altamente perigoso. Podem ser encontrados sites vulneráveis em segundos pesquisando no Google, MSN, Yahoo etc.
Esta tag está no seu header.php e mostra a sua versão actual do WordPress.
<meta content=”WordPress <?php bloginfo(’version’); ? />” name=”generator” />
6.1 – Remova ou altere-a para sua segurança. Se a deixar visível é fácil encontrar em pesquisas na net sites desactualizados, nem que seja por 1 dia, ficam vulneráveis e 100% expostos por causa de uma linha de código.
7 – Esconda e proteja a sua pasta wp-admin Um atacante pode utilizar com facilidade um ataque por brute-force ou encontrar erros que revelem informações vitais nesta pasta, há algumas soluções para este problema.
7.1 – Limite o acesso a esta pasta a um ip ou a um range de ips que você costuma ter. Por exemplo, imagine que tem netcabo, o seu ip tem um range, bloqueie o acesso a esse range.
7.2 – Utilize o pedido de password de zona protegida do Apache. Pode para tal utilizar este tutorial.
7.3 – Plugin “Login Lockdown” Este simples plugin vai guardar num log todas as tentativas correctas e falhadas de login no seu wordpress e bloqueia a página de login administrativo a essa pessoa se tiver mais de um certo número de tentativas falhadas. Também existem plugins semelhantes que bloqueiam o login mediante um número de tentativas em X segundos. Pode obter este plugin aqui.
8- Faça backups!! Toda a gente diz isto, é óbvio e na realidade pouca gente faz, quando a bomba estoura é o desastre total e absoluto! É tão simples fazer um dump da sua base de dados ou simplesmente instale um plugin de backup do WordPress, ver aqui.
Caso seja uma pessoa que se esquece com facilidade de fazer backups ou que não quer estar com trabalhos, defina os backups automaticamente ou meta um lembrete no seu telemóvel para os fazer no mínimo de 15 em 15 dias.
9 – Utilize o acesso via SSH/shell em vez do HTTP sempre que possível.
10 – Não se preocupe muito com o seu wp-config.php Proteja a sua base de dados, username e password com um simples passo: adicione esta linha ao seu ficheiro .htaccess (pasta principal da instalação do seu WordPress)
<FilesMatch ^wp-config.php$>deny from all</FilesMatch>
Isto irá fazer a vida difícil a quem tentar encontrar a sua password ou informações sobre a sua base de dados em caso de erros no seu servidor.Erros são extremamente importantes para atacantes; por vezes descobrem que você pode estar a utilizar um servidor diferente para a sua base de dados e isso muda muita coisa de figura.
DNS cache poisoning – Dica de segurança geral Muitas pessoas pensam terem os seus dados seguros em sites fabulosamente protegidos com imensos certificados, SSL, entre outras simpatias como teclado no ecrã e afins mas há algo interessante que vos pode mudar a vida em segundos, DNS cache poisoning.
Qualquer bom site no mundo com um problema de DNS por mais pequeno que seja pode tornar-se num inferno. Este tipo de problemas permite que um atacante com alguma experiência, em minutos faça um redireccionamento do site original para outro site.
Por exemplo, vamos imaginar que o sapo.pt que é um site com um tráfego assombroso e top 300 mundial, tem uma falha de DNS e vocês querem ir ao vosso mail. Um atacante identifica este problema e altera os nameservers do sapo, fazendo uma página exactamente igual num qualquer servidor do planeta, vocês fazem login, e ele fica com as vossas passwords, porque basicamente, quando pensavam estar a aceder a www.sapo.pt estavam na realidade a aceder a algo do género sapo.pt.hostinggratuito.com ou outra coisa do género que não necessite de ser uma máquina registada em nome dele.
Depois vocês são redireccionados para a página do sapo com login feito e não deram por nada. E está feito, ele fica com um log completo das vossas passwords em texto corrente, e-mail ou o que preencher. O DNS cache poisoning é utilizado na maioria dos casos para fazer dinheiro além de roubar dados.
Uma pessoa com essa intenção pode com extrema facilidade criar um redireccionamento mesmo para dentro da própria máquina, fazendo abrir um popup ou um frame no site, ganhando assim dinheiro. Estas situações podem ser de tal forma bem feitas que o dono do site poderá demorar meses a dar pelo problema.
Uma solução para este problema é utilizar passwords grandes e aleatórias para cada coisa que utilizem e não uma password em mais que um site.
Junto com este artigo que disponibilizei para o Pplware ofereci também um software muito simples que fiz há alguns anos para gerar passwords aleatórias com o tamanho pretendido. Para as gerirem sugiro utilizarem programas de gestão de passwords; alguns já foram mencionados aqui no Pplware. Uma pesquisa rápida e dão com o “bixo”.
Lembrem-se de alterar as vossas passwords com regularidade e de, se possível, utilizarem pelo menos dois mails para numa situação de desespero não ficarem apertados e sem soluções.
Informação aprofundada sobre DNS cache poisoning na Wikipedia.
NOTA: Este post foi desenvolvido por Paulo Ribeiro – iisop – Independent internet security of Portugal para o Pplware