Todos os posts tagados rsnake

Entrevista com… Robert Hansen

Para quem ainda não conhece o Robert RSnake Hansen…

Robert Hansen, também conhecido como RSnake, é o fundador e CEO da empresa SecTheory. Trabalhou para empresas como Digital Island, Exodus Communications e Cable & Wireless ocupando diversos cargos desde Arquiteto de Segurança Sênior e eventualmente como gerente de produtos de diversos serviços da linha de serviços gerenciados de segurança. Também trabalhou no eBay como Gerente Global Sênior para Confiança e Segurança, focando em anti-phishing, anti-malware de DHTML e estratégias de anti-vírus. Posteriormente ele trabalhou como Diretor de Gerenciamento de Produtos para o site Realtor.com. Robert é membro do conselho consultivo para o Grupo Intrepidus, e anteriormente era membro do conselho consultivo técnico da ClickForensics e atualmente contribui para a estratégia de segurança de diversas companhias startup.

In OWASP.

Robert também é co-autor do livro XSS Exploits e autor do Detecting Malice.
Para muitos especialistas da área, é considerado uma das maiores influências na segurança web.

Tive o prazer de trocar umas palavras com o Robert, no qual transcrevo algumas das questões que lhe fiz: (para os interessados fica aqui a entrevista original em inglês):

David Sopas: Como te interessaste pela segurança web?
Robert Hansen: Um dia li um artigo que demonstrava como era possível usar o telnet para conectar a qualquer porta que quiséssemos e, no caso da porta 80, podíamos mesmo interagir com os servidores web.
Nem quis acreditar que era verdade, porque sempre pensei que o telnet era um simples programa que apenas conseguia comunicar com protocolos específicos e não um programa genérico que conseguia comunicar com vários protocolos.
Portanto, quando me conectei com o telnet à porta 80 e após algum tempo a vaguear, eu vi os cabeçalhos HTTP e alguma informação. Nem quis acreditar nos meus olhos.
Mal me apercebi desta situação foi como se fosse atingido por um raio.
Eu finalmente apercebi-me que que tudo estaria inseguro. Tenta entender, estávamos em 1995, não havia muitos aplicações web interessantes. Mas, todas as que existiam, estavam extremamente expostas e prontas a ser exploradas. Demorou-me uns anos para apreciar em pleno o como estava correcto, mas esta foi a altura da minha primeira experiência com a segurança web.
Hoje em dia, ainda me surpreende a quantidade de profissionais de segurança e web developers que nunca viram os cabeçalhos HTTP.

DS: Na tua opinião, como evoluiu a segurança web nos últimos anos?
RH: A segurança web não existia quando comecei. Não existia tal coisa… Ninguém estava interessado nesse aspecto. Nessa altura, apenas havia um pequeno grupo de analistas de segurança e, menos ainda, os que se preocupavam com websites. Era uma altura em que apenas interessava ser um bom administrador de sistemas e na segurança de redes.
Mais tarde, um conceito chamado CGI security estava em voga porque o SSI e o Perl abriu os olhos a muitas pessoas, principalmente na facilidade de construção de websites dinâmicos.
De seguida, surgiu o termo webappsec e mesmo nessa altura só alguns se interessavam pela segurança web aplicacional. Foram necessários muitos anos para perceberem que a segurança de redes tinha forçado tudo para o  HTTP Tunneling. No dia em que ouvi de um projecto que foi desenhado para fazer TCP Tunneling sobre HTTP foi quando percebi que não havia maneira de parar a segurança web. Está aqui para ficar.

DS: Os websites que analisas são mais inseguros hoje em comparação de 3 anos atrás? O que mudou?
RH: Já não analiso os mesmos websites que costumava analisar. O tipo de websites que agora analiso, tendem a ser bem maiores em escala, mas não, não vejo qualquer mudança significativa no número de vulnerabilidades, excepto se estiveres a falar de ASP.NET. A única razão para que o ASP.NET é mais seguro, é por causa dos ViewStates que, se encriptados e verificados cortam vários tipos de vulnerabilidades, como por exemplo CSRF e XSS. O resto das vulnerabilidades, infelizmente, estão ainda bem presentes. Não gosto de falar sobre conformidade mas o PCI parece que forçou as pessoas a corrigir alguns dos “frutos mais maduros”, mas se tu insistes nos websites um pouco mais ou deus me livre, consigas o login, descobres que esses scanners automáticos não fazem muito coisa.

DS: De todas as vulnerabilidades conhecidas, porque decidiste dedicar quase todo o teu trabalho ao XSS? Consideras o XSS o mais perigoso?
RH: Eu não considero o XSS como o tipo de vulnerabilidade mais perigosa. Essa honra deve ser reservada à injecção de comandos, RFIs, SQL Injection e por ai adiante. Considero o XSS como a mistura perfeita de facilidade de causar dano e de execução.
Se eu sou um atacante que é novato, mas que quer ganhar rios de dinheiro, porque razão vou investir dinheiro e tempo a aprender algo complicado, quando posso fazer o mesmo dano com uma simples linha de JavaScript? Não faz qualquer sentido.
Então, enquanto não acho que isso é o pior exploit lá fora, é tão fácil que é impossível de ignorar.
Os criminosos não se importam se o ataque é bonito ou não, eles apenas querem dinheiro – por isso não me interessa muito o que algumas pessoas da indústria de segurança tendem a pensar – estou bem mais interessado na realidade.
Penso que o XSS recebe uma má reputação porque não é tão bonito como outras vulnerabilidades. Se consegues comprometer toda a tua rede com algumas linhas JavaScript, ou pior, com uma simples linha de HTML se falarmos de CSRF, pessoalmente não me importo que as outras vulnerabilidades sejam mais cool – são apenas muito menos prováveis. XSS e CSRF estão aqui para ficar.

DS: Porque razão os erros XSS são tão fáceis de criar?
RH: Codificação de output é um conceito simples, mas ninguém quer compreender os diversos métodos que se podem utilizar para ultrapassar essas codificações. Só porque foi codificado alguma coisa para sair em HTML não significa que o teu colega, que também está a trabalhar no mesmo código, não o atira num espaço de JavaScript, CSS ou outro local. É muito difícil saber onde se vai utilizar, a não ser que controles todos os aspectos do código. E mesmo assim, requer que saibas da vulnerabilidade. É mais fácil errar do que acertar.

DS: Descreve-me alguns exemplos do dano que falhas XSS podem causar?
RH: Em vários casos já foram demonstrados ataques usando falhas XSS para entrar dentro de redes internas, controlar computadores locais, roubar credenciais, fazer phishing de nomes de utilizador e palavras passe, mudar informação em websites, scanear portas, etc… etc… A sério, à parte de esconder as tuas chaves do carro e namorar com a tua mulher, XSS é capaz de quase tudo que possas pensar. É o canivete suíço das vulnerabilidades client side.

DS: Fala-me do teu livro Detecting Malice. Porque é que as pessoas devem lê-lo e quem deve lê-lo?
RH: Eu escrevi o Detecting Malice como uma extensão ao meu blogue. Eu pensei que seria um boa ideia fornecer aos praticantes de segurança, programadores, analistas, e outros, a verdadeira natureza dos casos que tive durante os anos.
Mesmo focando tópicos muito complexos, tentei escrever numa maneira fácil de ler.
Também tentei usar muitos exemplos de situações reais, mesmo que em muitos casos eu fosse algo vago para proteger inocentes e culpados.
Muitos dos fornecedores de segurança compraram o livro e já mencionaram que tentaram implementar algumas das ideias no código deles. Isso é bem interessante!

DS: Qual é a próxima área na segurança de aplicações que devemos prestar mais atenção?
RH: Inter-protocol exploitation é uma enorme área por analisar em segurança. Adorava ver alguém aprofundar nesta área e provar a fragilidade do bloqueio de portas em blacklist do Mozilla.
Podem pensar que após os ataques ao VOIP, Sendmail, IMAP3 e IRC, a Mozilla poderia concordar que o uso de uma whitelist fazia mais sentido, mas presumo que eles estão mais preocupados em não quebrar nada. Eu detestava que tivéssemos de quebrar mais o browser, do que actualmente está, só para eles fazerem o que está certo, mas é onde estamos, penso eu.

DS: Quais são os teus planos para o futuro? Alguns novos projectos?
RH: Tenho mais projectos do que sei o que fazer com eles.
Vou fechar o ha.ckers.org mal chegue  aos 1000 artigos. Eu penso que após anos à frente do website, mereço uma pausa.
Infelizmente, eu estou mais ocupado que nunca, por isso os meus planos  é beber umas cervejas  com o id (o tipo que corre a rede) e voltar para o trabalho. Não existe tempo para descansar nesta área.

DS: Para terminar esta entrevista, tens algumas palavras finais para os leitores portugueses?
RH: Sim, se gostam de segurança, não permitam que as pessoas do topo da industria de segurança ditem os termos/regras no qual fazes a tua pesquisa/análise, divulgação de vulnerabilidades ou o teu trabalho. Tens imenso potencial e a vida é demasiado curta.
Como o meu pai costumava me dizer, “se tu gostas do que fazes nunca mais vais trabalhar um dia na tua vida”. Para uma melhor interpretação – se não te estás a divertir na segurança, estás a fazer algo de errado. Coloca um sorriso na cara e atira-te para o que te faz feliz!

Queria agradecer ao Robert pelo o tempo dispensado e, já lhe prometi, que quando estiver com ele, pago-lhe uma cerveja.

Para concluir, o Robert vai estar presente no evento OWASP AppSec Brasil que decorre nos dias 16 e 19 de Novembro.

Tornar um ataque XSS em Clickjacking

Um artigo no blogue do mestre do XSS – RSnake.

Phishing no Google Chrome

RSnake publicou um pequeno artigo sobre uma técnica algo antiga (corrigida no Firefox à uns bons anos) para enganar o um pedido de website no Chrome.

http://www.bankofamerica.com@ha.ckers.org/

Interessante também, como é habitual, o seguimento dos comentários. Ler [aqui].

Podcast com RSnake

Acabei de ouvir o podcast [aqui] que o Robert Hanson aka RSnake deu ao PaulDotCom onde fala de segurança web, da evolução dos websites (modo em que são programados e as novas tecnologias), dos browsers e  como começou nesta área influenciado por um amigo blackhat.

As 10 pessoas da Internet mais “perigosas” que você desconhece

Robert Hansen, mais conhecido pela grande maioria como RSnake, divulgou o que considerou a lista das 10 personalidades ou entidades mais importantes/perigosas da Internet.

1. iDefense, Verisign e Network Solutions
Basicamente, controlam os .com

2. Desconhecido em gtei.net
Controla os endereços IP 4.2.2.2 e 4.2.2.3, muitas das vezes escolhidos por administradores de redes para servidores DNS, provavelmente pela facilidade de memorização. Se estes IPs forem comprometidos, podem causar muitos problemas.

3. Desconhecido em 1 Wilshire
Um peering point para muito conteúdo da Internet, por isso pode snifar ou bloquear o tráfego de rede.

4. Desconhecido em Google Postini
Entradas e saídas das contas Gmail passam pelo Google Postini. Medo?

5. Chirag e Floyd do Adwords
XSS legítimo em quase 50% da Internet. Podem “roubar” muita informação em websites bem conhecidos.

6. Check In Engineer da Mozilla
Inserem código malicioso (por exemplo: sniffer) no motor do browser e toca a receber informação confidencial.

7. Desconhecido do Authorize.net
Maior serviço online de transacções de comercio electrónico. Têm muita informação de cartões de credito de milhares de websites.

8. Eddy Nigg da StarCom
Pode criar um wildcard certicate para qualquer domínio o que pode levar a uma facilidade em criar ataques man-in-the-middle.

9. Giorgio Maone
Criou o NoScript, extensão muito usada por diversos especialistas de segurança. Pode ser subornado a inserir código malicioso sem que ninguém se aperceba.

10. Network Engineer da C|Net
São os proprietários do domínio com.com. Pode ser usado, devido a erros tipográficos, para servir malware ou receber emails enviados por exemplo para o domínio cnet.com.com.