Upgrade to Pro — share decks privately, control downloads, hide ads and more …

entendendo vulnerabilidades

entendendo vulnerabilidades

entendendo e descobrindo vulnerabilidades introdução

Cooler_ mad coder

April 13, 2012
Tweet

More Decks by Cooler_ mad coder

Other Decks in Technology

Transcript

  1. Quem Sou ? • Antonio Costa, aka Cooler_ • Desenvolvedor

    em ASM,C, C++,Common Lisp,Perl,PHP e Ruby, pesquisador... • Fundador e colaborador da e-zine cogumelo binário “cogubin.leet.la” • Membro do BugSec Team “bugsec.googlecode.com ” • Como hobby estudo microcontroladores AVR e eletrônica. • Trabalho na CONVISO como Desenvolvedor e pesquisador em segurança
  2. Alguns projetos • “Cactoo” CMS em PHP http://code.google.com/p/cactoo/ • “TombPool”

    biblioteca de piscina de conexões em linguagem C para Unix http://code.google.com/p/tombpool/ • “hyde” packet injector usando Spoofing para testes de DoS... https://github.com/CoolerVoid/hyde • “Beer” biblioteca em C com funções diversas para tarefas em arquivos,strings... http://code.google.com/p/beer/
  3. Vulnerabilidades • Bug o que é ? • vulnerabilidade o

    que é ? • A cultura • Exposição (disclosure) • Como procurar uma vulnerabilidade • Vulnerabilidade na prática
  4. O que é um Bug ? • Bug(inseto ou defeito)

    é um termo computacional para definir um acontecimento inesperado de um determinado software. • Diz a lenda que esse termo foi criado por Thomas Edison quando um inseto causou problemas de leitura em seu fonógrafo em 1878. Outros dizem que o termo surgiu, porque as válvulas de antigos computadores atraiam insetos, logo causavam curto circuito fazendo queimar...
  5. O que é um Bug ? • Primeiro vetor dos

    problemas • Falta de experiência ; conhecido pelos programadores "old school" como "pitfall" ,Quando falamos em “Pitfall“, falamos de uma analogia a armadilhas da programação ou seja buracos , que quando se cai fica ruim de subir sem ajuda de alguém , onde um programador iniciante pode errar e não conseguir ver onde está o erro.
  6. O que é um Bug ? • problemas com sinais

    • *isso “!=” é diferente disso ‘=!’ • “!=” sinal de diferente para fazer comparação “if(x!=y)” • “=!” você seta uma var para NOT,if(x=(!y)) • Erros de sintaxe em geral...
  7. O que é um Bug ? • Segundo vetor dos

    problemas • erro de má prática • Erro por não seguir padrões da linguagem,não seguir padrão de uma biblioteca,não higienizar variáveis onde se tem INPUT bem como validar, problemas de memory leaks ao usar "new" não usar "delete", ao usar "malloc()" não usa "free()",permissões erradas em arquivos temporários podendo ser explorado um race condition, variáveis com problemas de reentrância em algo concorrente...
  8. O que é um Bug ? • O que o

    correu se chama Buffer Overflow,é o transbordamento da memória que ocorre quando armazenamos mais dados do que se pode suportar em um buffer,no caso "string_3" suporta apenas "8" char e colocamos "9",teve um comportamento inesperado, a partir do overflow dependendo do caso pode-se executar um código reverso manipular endereços etc...
  9. O que é Vulnerabilidade ? • Vulnerabilidade é um Bug

    que pode afetar a segurança do sistema. Exemplo:
  10. Por que falamos de linguagem C ? • LibC é

    usada em vários sistemas operacionais como MacOS,Solaris,Linux(android,debian,redhat...), FreeBSD,AIX,HP-UX etc. usada no core utils bem como comandos como “ls,rm,mv,mkdir...” todos feitos em C, labels para syscall da “unistd.h” para o código com inline Assembly. Um simples arquivo aberto em uma linguagem como Java já passa pela libC para usar um syscall de “open()”. • Kernel é feito em C com muitos inline Assembly,drivers também etc... • OpenMPI que usamos em “msg passing” em clusters é em linguagem C . . .
  11. A Cultura • Vulnerabilidade em geral tem um estereótipo para

    cada tipo, a dogma se dá graças a fatos empíricos anteriores de pesquisadores, desenvolvedores, pentesters, hackers em geral... • Assim fazendo divulgação(disclosure) do problema, cada um com sua perspectiva independente de cada tribo.
  12. Exposição (disclosure) • Para tal temos "CVE"(Common Vulnerabilities and Exposures)

    um padrão para exposição de falhas comuns em sistemas, mantido pela Mitre "cve.mitre.org",tem suas próprias paradigmas para exposição e sua própria ética, profissionais de segurança do mundo todo as usam para expor falhas... • também temos a OSVDB"The Open Source Vulnerability Database" que se encontra em "osvdb.org", provê dos mesmos fins do CVE porém com algumas diferenças.
  13. Exposição (disclosure) • Temos diversos outros locais como "exploit-db" extremamente

    popular vide "exploit-db.com" ,mantido pelo pessoal do "offensive security" criadores de uma distribuição linux para pentest chamada back|track , pelo exploit-db podemos ver vulnerabilidades recentes CVE,OSVDB... • tem a "bugtraq" lista da security focus "securityfocus.com" que dispõe de uma boa lista de discusão, entre outras listas...
  14. Exposição (disclosure) • Claro que alguns não seguem regras nem

    padrões,fazendo ai exposição indevida de certas informações, tem muito mercado negro funcionando 24h em servidores do IRC, chats privados com SSL para vendas de falhas chamadas de "0day", das quais tem alto valor no mercado, sua validade varia entre 1 a uma eternidade, claro que pesa questões de aleatoriedade também.
  15. Como procurar uma vulnerabilidade ? • Tem muitas formas de

    se abstrair informações para conseguir tal informação, podemos fazer manualmente como também desenvolver softwares de forma otimizar esta busca ou usar um já existente como Nessus,OpenVas,Armitage,Nikto... Repare que o contexto aqui é "procurar" uma vulnerabilidade e não "descobrir", partindo desse ponto,sabemos que olhando o CVE,Bugtraq... vemos que todo software tem uma versão , quando é feita exposição de uma falha é colocado sobre a mesa todas as versões vulneráveis daquele software, os desenvolvedores lançam um "patch" para deixar a aplicação estável.
  16. Como procurar uma vulnerabilidade ? • Então a partir dai

    você já tem uma utopia do que deve ser feito, digamos ai ter uma database composta por campos como "nome da falha","string de busca" e "CVE"... "string de busca" seria para procurar por um determinado "banner" que comprove existência do mesmo por exemplo "ProFTPd 1.3*". • exemplo usando protocolo TCP/IP veja como o netcat pega banner de um serviço.
  17. Como procurar uma vulnerabilidade ? • Bom já sabemos versão

    do serviço "Sendmail", com isso podemos procurar em algum repositório de falhas a versão "8.14.5", evidente que essa versão pode ser um honeypot(pote de mel),levando o ponto que é fácil mudar o "banner" de algum software ainda mais se for OpenSource. • Agora o que interessa, o código do netcat é meio que grande para explicar o funcionamento, tem validações getopt, entretanto desenvolvi algo simples para tentar ilustrar algo com Sockets, somente nesse ponto de mostrar banner de serviço.
  18. Como procurar uma vulnerabilidade ? • A partir disso poderá

    fazer seu próprio scanner de banners, para chegar ao nível do Nmap esta bem longe, teria que usar raw sockets para chegar num nível stealth e usar spoofing entre outras coisas... última dica o paper "The Art of Port Scanning" do Fyodor. • Claro que tem alguns protocolos como o HTTP que além de poder ver a versão do servidor,podemos testar inputs na URL para tentar um possível DoS rumo a um "crash" ,podemos explorar falhas nos sistemas web hospedados, bem como procurar padrões para SQL injection,XSS,Local file injection,remote file injection , disclosure...
  19. Vulnerabilidade na Prática • Nestes tempos 60% das falhas expostas

    são WEB ou seja estão dentro do protocolo HTTP, por este número vamos focar agora em web pelo menos nesta parte de descobrimento, sem falar que é bem mais fácil descobrir falhas em aplicações web, pois proteções como ASLR,PAX não afetam aplicações no protocolo HTTP, claro que um WAF(web application firewall) pode atrapalhar mas nada no ramo de software é 100% certo,mesmo com um bom Sniffer dando parser com uma regex"expressão regular" genial,pode ter alguém para burlar.
  20. SQL injection • SQL injection “injeção de SQL” ocorre quando

    o atacante consegue inserir uma série de instruções SQL dentro de uma “query” , através da manipulação da entrada de dados de uma aplicação. • Isso pode ocorrer tanto via ARGV”argumento”,como em um form em uma GUI,via HTTP com POST,GET,COOKIE via OCR, Basta ter input !
  21. SQL injection • Não gosto de teoria adoro a prática

    , então desenvolvi dois códigos vulneráveis a SQL injection, um em Linguagem C com LibCGI, e outro em PHP. • Sim é um wargame bem simples • http://bugsec.googlecode.com/files/Coolers_sqli_game.zip • https://github.com/CoolerVoid/neilmonkey
  22. SQL injection • Antes de ir para a prática com

    SQL injection , vamos entender o funcionamento comum de um sistema Web que usa banco de dados.
  23. SQL injection • Tentamos testar com uso de ' para

    ver log de erro • Veja esta vulnerável a SQL injection • Sabendo disso podemos fazer algo sério exemplo: '; DROP TABLE neiluser;-- imagine impacto disso em um sistema com muitos usuários...
  24. SQL injection • Uma dica em ataques de SQL injection

    , usar o sqlmap , uma ferramenta feita em python com um banco de querys para fazer Fuzzer em formulários, ao resultar algo o programa deixa a mostra, interessante que ao testar o programa ele tomou controle e deu dump muito além do banco de dados usado, poderia facilitar ai para implantar um backdoor então depois subir privilégios com um exploit local então...
  25. SQL injection • Questão de 3 minutos o sqlmap deu

    dump de todo banco de dados e de todas as tabelas.”isso não só a neiluser” , dominou o sistema todo, agora só quebrar algumas hash com john e logar. • Devastador o ataque foi um sucesso ! • No caso de blackbox usar o argumento -tor ou -proxy do sqlmap pode garantir um anonimato
  26. E agora ? Casa caiu ! • SysAdmin • DBA

    • WebMaster backup ? Snort ? Polícia ? GAME OVER !
  27. OCR

  28. XSS “Cross-site scripting” • Consiste em uma vulnerabilidade Web, onde

    o atacante por meio de uma entrada sem filtro manda seu javascript malicioso. • Campos de texto de formulários em um POST ou GET • Embora seja um ataque muito ignorado , é usado para roubar cookies, o que pode ser devastador. • Logar na conta do usuário ,pelo fato do usuário abrir uma URL vulnerável a XSS, por meio de roubo de cookies. • Outros ataques...
  29. RFI “Remote File Inclusion” • Um tipo de vulnerabilidade onde

    o atacante inclui um arquivo remoto,através de entradas do sistema alvo.
  30. LFI “Local File Inclusion” • Um tipo de vulnerabilidade onde

    o atacante inclui um arquivo Local,através de entradas do sistema alvo. • Mesma ideia de RFI porém algo local exemplo: • http://alvo.com/index.php?file=../../../../etc/passwd
  31. Burlando filtro de um web application firewall • Ao encontrar

    um sistema vulnerável , algumas vezes nos deparamos com algum erro inesperado, se esta vulnerável por que não consegue explorar ? • HoneyPot • Um WAF “web application firewall” • São problemas a se pensar , como nem tudo na vida é 100% seguro . . .
  32. Burlando filtro de um web application firewall • Filtros em

    aplicações web ,são feitos da leitura do protocolo HTTP, bem como passar por várias expressões regulares para achar certos padrões baseados em uma “black list”, para assim poder bloquear acesso e logar o ataque. • Então podemos tentar entender certos filtros • Codificar(encode) dados do POST,GET,COOKIE para estar enganando filtros...
  33. Fuzzer • http://bluered.sourceforge.net/ • Ferramenta para pegar todas URLs de

    um host, então testar INPUTs baseadas de uma lista. • Testa um por um, o que retornar algo interessante rotula como vulnerável. • Ferramenta feita em Perl pelo meu amigo “Victor Ramos Mello” o “m0nad”, do grupo de pesquisa que faço parte BugSec. • Bom de um Fuzzer que a partir de testes brutos ele descobre falhas novas, que scanners como nikto não iriam conseguir já que são baseados em falhas já existentes.
  34. Fuzzer • http://bluered.sourceforge.net/ • Ferramenta para pegar todas URLs de

    um host, então testar INPUTs baseadas de uma lista. • Testa um por um, o que retornar algo interessante rotula como vulnerável. • Ferramenta feita pelo meu amigo “Victor Ramos” o “m0nad”, do grupo que faço parte BugSec • Bom de um Fuzzer que a partir de testes brutos ele descobre falhas novas, que scanners como nikto que não são inteligentes não conseguiriam.
  35. Backdoor,web Shells... • Tanto no underground, como no meio de

    segurança em geral é tradição falar de Backdoors. • Já esta fora de moda Backdoors simples com netcat ou em Web como shells r57,c99 etc... • Mesmo por que uma varredura com Nmap já irá revelar a porta, ou no caso de HTTP algum aplicativo poderá apontar o local do mesmo bloquear... • Sniffer com analisador de CMDs poderá dificultar etc... • Usar Raw sockets ? Genial assim nem o Nmap acharia a porta , mas para usar Raw precisaria ser Root...
  36. Backdoor,web Shells... • https://github.com/CoolerVoid/Cakeman • Uma das muitas soluções ,

    um backdoor utilizando COOKIE, claro que um WAF poderá detectar ,mas se codificar “encode” pode dar mais trabalho achar, fora que o serviço vai usar o protocolo HTTP, diminui as suspeitas.
  37. Muito Obrigado ! thanks: Professor Clodonil amigos do grupo de

    estudo Agnei,Felipe Naranjo,Marina,Aline,Liliane. Amigos do Bugsec , Tiago Natel,Victor Ramos, Felipe Pena, Bellani, Sergio Renan. •