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
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/
é 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...
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.
• *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...
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...
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...
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 . . .
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.
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.
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...
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.
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.
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.
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.
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...
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.
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 !
, 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
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...
, 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...
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
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...
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
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 . . .
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...
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.
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.
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...
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.