Em 2011 as atividades hackers foram bastante divulgadas e passaram de mera brincadeira de jovens desocupados para ações “organizadas” com cunho político libertário.
Os grupos que ganharam um rápido prestigio foram o Anonymous e LuLzSec, uma boa parte do marketing em cima das ações destes grupos ficou a cargo das redes sociais, pastebin e do youtube. A partir dai novas facções como AnonymousBR, iPiratesGroup, LuLzSecBR, GreyHatBR, AntiSecBR e alguns pichadores virtuais 
foram surgindo em busca de seus 15 min de fama.
Analisando os resultados divulgados não foi dificil entender o porque de tanto sucesso. Identifiquei erros simples como senhas fracas no ambiente de administação do sites ( e.g. admin@dominio/manager ) e muito mas muito SQLi e Blind SQLi.
Abaixo passo algumas dicas de como sobreviver após o comprometimento de sua infra-estrutura e como mitigar as falhas.
1 – Web Backdoors
Os web shells[1] [2] permitem o acesso ao ambiente comprometido mesmo após corrigidas as falhas. Estudar o código destas ferramentas facilita sua detecção e remoção.
Nestes casos um AV ajuda muito tanto no Ambiente Windows quanto no Linux, mas muito cuidado pois nem todos os AVs são capazes de detectar web backdoors bastantes conhecidos ( e.g Symantec ). Uma forma de validar a varredura é fazendo buscas manuais:
No Linux
grep -RPl –include=*.{php,txt,asp} “(passthru|shell_exec|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\(” /var/www/
No Windows
Usando a ferramenta de busca procure pelas palavras acima.
2 – Análise do alvo
Após o incidente é muito importante entender quais foram as vulnerabilidades que permitiram a invasão. Ferramentas para análise de vulnerabilidades como o Nessus, Arachni, Uniscan, Acunetix são de fundamental importância, pois elas indicam as possíveis portas de entrada e facilitam a criação do plano de mitigação.
Auditar o banco de dados é de extrema importância já que entradas indevidas podem ser adicionadas ( e.g contas fantasmas), e alguns lixos do ataque.
3 – Proteção extra e monitoramento
Aplicar uma camada a mais de segurança permite dificultar as tentativas de ataque não permitindo a varredura em busca de vulnerabilidades e portas abertas. Não deixe essa responsabilidade somente a cargo da ferramenta de proteção de borda ( e.g IPS ), por ela ser baseada em Pattern matching nem todos os ataques serão bloqueados e muito cuidado com os falsos positivos já que uma aplicação com falha no código fará com que o IPS entenda qualquer requisição como maliciosa, auditar todos os alertas muitas vezes sem bloqueá-los é o mais recomendado.
O Ossec juntamente com o Splunk, Portsentry, Samhaim e o ModSecurity são ferramentas que auxiliam bastante nesta tarefa. Outro hábito pouco utilizado é a análise dos logs, uma simples busca por palavras como Nikto, Havij, perl, whitehat, Uniscan, acunetix, fuck, scanner, timthumb, pma, phpmyadmin nos logs do Apache e do IIS permitem identificar algumas tentativas de ataque.
4 – Atualização e restrição de acesso
Manter o ambiente atualizado é uma boa prática pouco utilizada muito mais por medo principalmente quando o ambiente é de alta criticidade ( e.g SGBDs ). Nos ambientes Linux o cron-apt (Debian e derivados) e o Spacewalk (RedHat e derivados) ajudam muito, os sistemas Windows contam com o velho WSUS que geralmente fica esquecido sem a devida atenção.
Restringir o acesso aos ambientes administrativos do site ( e.g wp-admin, admin, administration ) e o FTP evitando assim ataques de brute-force, outra boa prática é a utilização de senhas fortes, isto soa bastante clichê, porém após analisar algumas áreas administrativas encontrei senhas ridiculas de acesso.
Conclusão
Estas dicas apenas mostram o caminho a ser seguido. Experiência, bom senso e estudo continuo são fatores que diferenciam na resolução dos incidentes e na prevenção.
Última dica: FERRAMENTAS FALHAM.
