bug no iCloud que causou vazamento de fotos: simples HTTP auth brute force?

Na noite de ontem a internet inteira acompanhou boquiaberta o vazamento de fotos íntimas afetando uma dúzia de celebridades – apesar de eu só ter visto umas 4 :’-(.

Como os detalhes de hackeamentos estupidamente simples não costumam demorar a aparecer, os caras da hackapp.com na manhã de hoje postaram no GitHub um código explorando supostamente o mesmo bug usado no hack, que eu imediatamente testei e confirmei que funciona como esperado:

ibruteA exploit nada mais é do que um simples brute force via HTTP basic auth numa API provavelmente obscura usada pelo iCloud, que pelo user-agent usado no código, parece fazer parte de alguma funcionalidade do recurso FindMyiPhone do iOS.

O erro da Apple foi não banir o IP do atacante ou bloquear a conta da vítima após X tentativas de login, vacilo clássico que sempre permite ataques de força bruta.

Ainda não há confirmação de que essa tenha sido de fato a brecha que causou o vazamento das fotos, mas esse bug em particular é real e não há desculpa para uma empresa com o tamanho da Apple deixar passar uma vulnerabilidade que, de acordo com a OWASP, está entre as 3 mais frequentes em aplicações web.

Como se proteger

Após a Apple corrigir esse bug em particular, outros poderão surgir a qualquer momento, então simplesmente considere não usar o iCloud pra sincronizar/backupear as fotos tiradas no iPhone. Mas se você quiser correr o risco mesmo assim, tenha certeza de usar uma senha forte e que não se repita em nenhum outro site ou serviço.

Segurança no WordPress: url /wp-admin, esconder ou não esconder?

tl;dr: Acho desnecessário e não vale a incompatibilidade causada. Se foque em medidas realmente eficazes (veja mais abaixo).

***

Durante anos, como medida de hardening recomendei a administradores de blogs WordPress a instalação de alguns plugins capazes de ocultar a página de login (/wp-admin e /wp-login.php), e costumava fazê-lo por uma simples razão: a url padrão sempre facilitou o acesso a uma infinidade de blogs vulneráveis a outros problemas.

Mas nem todos concordavam. O que alegavam é que essa seria uma desaconselhável forma de segurança por obscuridade. Argumentavam que ninguém considera o Gmail inseguro porque sua interface de login é acessível a qualquer um com posse das credenciais de acesso, e que portanto os esforços devem se voltar em fortalecer a chave do portão, e não em torná-lo invisível ao inimigo. O contra-argumento que sempre defendi lembrava que o problema seria considerar essa tática como uma substituição a outras medidas fundamentais de proteção. Se renomear a url da interface administrativa é apenas uma entre outras precauções indispensáveis, então podemos considerá-la como uma bem vinda estratégia de defesa em profundidade, que se vale de vários níveis de proteção, exigindo cada vez mais habilidade dos invasores e desmotivando muitos deles durante o processo.

Mas mesmo com esse entendimento e após todo esse tempo, eu mudei de opinião. O nível de incompatibilidade com plugins famosos acarretado por essa mudança é alto, além de ser desaconselhada pelos desenvolvedores do WordPress por uma única razão: é uma mudança que, querendo ou não, na prática tende a gerar uma falsa sensação de segurança tão grande ao ponto de inibir a adoção de medidas ideais e realmente eficazes.

Ao longo de anos ajudando a proteger blogs e investigando os motivos que levaram alguns a serem hackeados, conheci alguns casos onde foi exatamente isso que aconteceu. O administrador mudava a url pra algo ingênuo como /admin2 ou /gerencia (facilmente identificáveis em minutos de força bruta), se convencia de que era o suficiente e relaxava em outras estratégias de defesa.

E quais são as medidas realmente eficazes? “O que devo fazer pra proteger meu WordPress de fato, ao ponto de neutralizar a gigantesca maioria dos ataques?”. Além das óbvias recomendações de manter usuários com senhas fortes, sugiro 4 medidas que vão além e são matadoras ao ponto de não sobrar o menor espaço para um atacante convencional explorar o login do seu blog.

Renomeie a conta administrativa padrão

Versões mais recentes do WordPress não mais criam automaticamente a conta admin. Finalmente! Agora ao instalar o CMS,  é pedido ao administrador que crie um nome de conta. Mas e os blogs instalados em versões anteriores? Bem, esss vão continuar tendo uma conta admin até que o administrador a renomeie, o que só pode ser feito diretamente pelo banco de dados:

UPDATE wp_users SET user_login = 'outronome' WHERE user_login = 'admin';

Esconda todos os usernames

Se por um lado o WordPress progrediu quando não mais criou por padrão o usuário admin, forçando assim a criação de um outro username, por outro ele continua vacilando ao expor todos os usernames para potenciais atacantes (ainda um problema na versão 3.9.2, a mais atual no momento que escrevo esse post). Ferramentas como WPScan listam todos os usernames do sistema através de força bruta em /?author=, que como o código da ferramenta mostra, busca por IDs válidos que redirecionam pra uma url com o username. Saber os usernames facilita esses ataques e os tornam possíveis até mesmo onde a velha conta padrão foi deletada.

Felizmente, há uma simples solução pelo .htaccess que bloqueia esse abuso:

RewriteCond%{QUERY_STRING} author=\d
RewriteRule^/?[L,R=301]

Instale um plugin de autenticação em duas etapas

Cada simples hackeamento que acontece em blogs WordPress pelo roubo ou adivinhação do login/senha poderia ser evitado com essa medida. E não há a menor desculpa para não fazê-lo. O plugin Google Authenticator é gratuito, incrivelmente eficiente e deliciosamente fácil de usar. Como o nome sugere, ele é compatível com o app Google Authenticator do Google, o mesmo app que usuários do Dropbox e Evernote costumam usar.

Eu poderia recomendar ainda a solução da Duo Security, já que eles são famosos pelo impressionante nível de conhecimento na área e oferecem uma versão gratuita para até 10 usuários. Mas o plugin anterior é tão eficaz que não vejo razão pra se depender de uma solução que passe por servidores de terceiros.

Bana IPs maliciosos sem dó

Apenas instalar um plugin de autenticação dupla já é o suficiente para neutralizar ataques de força bruta. Mas um atacante insistente, mesmo sem obter sucesso em sua investida, pode consumir valiosos recursos do sistema, o que em alguns casos pode afetar a performance do seu site, além de comer sua preciosa banda. Uma boa forma de evitar isso é simplesmente banir IPs que tentem se logar na interface administrativa e falhem X vezes dentro de um período Y. Há alguns plugins que prometem fazer isso sem precisar instalar mais nada no servidor, ideal para quem usa o WordPress em shared-hosting, não tem acesso root e nem experiência como sysadmin; mas confesso que não testei nenhum desses e preferi usar direto o WP fail2ban. Com ele instalado qualquer ataque é bloqueado via iptables já nos seus primeiros segundos de ação.

Há outras medidas recomendadas de hardening no site do WordPress e que cobrem outros pontos da aplicação e valem a leitura. Falarei sobre outras em um futuro post.