O seu blog é seguro?
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”.
Download: Password Generator [19.6KB]
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
Este artigo tem mais de um ano
Mas que grande post! Muito completo e esclarecedor. É de facto assustador verificar a facilidade com que se obtem informação protegida usando um simples url…
———————————————
http://www.revolucaodigital.net
obrigado Nastase
Muito bom 😉
wow este post tá altamente !
Muito completo e sem duvida nenhuma ÚTIL (com letras grandes, à pois é !)
😉
__________________
http://www.otal.pt.vu
Está aqui um post que muito jeito me dará…mas não resisto a comentar um pequeno aparte do post que me pôs a rir…
A certa altura (logo no inicio) dizes tu no post:
“…pode ser explorado até à sua exaustão por um técnico de segurança que vai encontrar bugs facilmente caso existam…”
Desculpa lá, mas esta frase dava para comentar durante bastante tempo….
Não dá nada! Ele referiu e bem, caso existam!!! Sim já sei que vão dizer que é impossível não haver bugs….q há sempre…blá blá…
Mas também não se pode partir do pressuposto que os há sem saber… Portanto… escreveu mt bem!
@Burgada
a única coisa que vejo nessa minha frase que poderá ter uma alteração é remover a palavra “fácilmente” de todas as formas não vejo motivo para nenhuma indignação. Conheço técnicos de segurança que nem se xateiam e ganham a vida a vender licenças de SSL para sites grandes, instituições e bancos por valores na casa dos 7000€ por ano, e conheço pessoas que ganham a vida a resolver problemas de programação diversos programas, sites, sistemas open source e não ganham nada.
quando falo em explorar algo até à exaustão digo que por exemplo um erro numa página que tenha um output de uma base de dados e que contenha algo tão estupido como “access denied for user xxxx using password NO” isto já permite bruteforce nessa base de dados, seja qual for o servidor, a sua versão, e a protecção k ele possa ter. muitas vezes encontra-se erros tarde demais em sites cuja culpa é mero esquecimento do seu programador em não ter removido uma determinada linha de ECHO em PHP que permita brincadeiras deste tipo, chamo a isto explorar a informação até ao limite.
quanto ao resto, simplesmente não compreendi, e repito, não vejo motivo para alterar a frase.
caso vejas avisa.
Este e outros artigos poderão vir a ser publicados noutros locais e mesmo no futuro site da iisop e não queremos publicar coisas que deixem dúvidas a ninguém, plo menos tentaremos
Post excelente! Obrigado ao autor!
Cumprimentos, David Carreira
Dicas simples e eficazes!
@Paulo Ribeiro: Em primeiro lugar, parabéns pelo artigo. Não só fizeste referência a alguns importantes problemas de segurança como apresentaste soluções para esses mesmos problemas.
No entanto eu também tenho alguma alguma dificuldade em digerir alguns comentários tais como “(…) o mal destes programas é serem extremamente populares e são open source (…) 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 (…) “, não por não ser verdade, mas porque não considero que isto seja necessariamente um aspecto negativo. A partilha de código não é uma coisa má, o mau é existirem pessoas que detectam essas falhas e em vez de as reportarem ou de as corrigirem, as exploram e tentam ganhar dinheiro com isso, utilizando algo que foi desenvolvido por alguém (à partida) sem segundas intenções, num espírito de partilha.
Por outro lado é triste verificar que existem ainda os programadores que desenvolvem plugins com exploids no sentido de mais tarde explorarem essas falhas. Isto parece-me um bocado a política de aqueles que desenvolvem software proprietário com falhas para depois venderem o suporte e a respectiva resolução. Felizmente no software opensource existe a vantagem de estas falhas poderem ser corrigidas por quem quiser uma vez que o código é aberto e não está escondido num repositório fechado qualquer.
Mesmo assim, e apesar de divergirmos na forma como vemos o software opensource, o artigo está bastante bom. Parabéns.
Viva,
Bom artigo e extremamente actual.
Penso que nunca é de mais referir, e neste caso para os leitores que usam o Joomla como CMS de eleição, que há uma lista oficial de extensões não-seguras que devem consultar antes de instalar qualquer add-on.
Abraço.
@phoenux
eu nao axo o opensource mau, apenas axo que fica muito exposto a análise de quem tem segundas intenções.
em ambiente windows ha coisas dificeis de alterar entao o cracking passou directamente para os trojans aqui à uns anos. open source é solução a muita coisa, mas o meu ponto de vista seria que uma empresa com poderio monetário deveria utilizar um site feito apenas para aquela empresa e não utilizar um site em CMS por exemplo porque nesse caso arrisca bases de dados com informações sobre clientes etc etc.
no fundo o open source é o novo poderio das massas, que dá porrada velha à microsoft que agora se vira para contratos com governos dos paises e grandes empresas em vez de pensar no cliente pequeno.
um bom exemplo é o open office… 😉
E dicas para segurança do JOOMLA? Alguém tem?
nuno começa pelos metas do site e ve o que ele guarda em cache, de resto joomla em si é seguro o problema sao permissoes de certos ficheiros e inclusões remotas de ficheiros, porém fica a dica para um futuro manual completo para protecção de joomla 😉
Excelente artigo!
Parabéns
O artigo está bastante bom, menos bom foi terem exposto o site africano… :\
Grande post e grando o site deles !
Minha filha está a fazer um blogger, no entretanto, meu temor é com hacker então, pergunto, fazendo favor, dá para saber o IP de quem entra e apenas poe-se a ler? E se posta uma mensagem, como se há de verificar o seu IP?
Desculpem mas não percebo muito bem, se alguém quiser fazer favor, pode mandar uma respost^?
Melhores cumprimentos
Maria da Graça Regina de Fatima
Este post foi muio bom!!!