LIVRO - COMO QUEBRAR CÓDIGOS - A ARTE DE EXPLORAR (E PROTEGER) SOFTWARE

"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


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

2006 by Pearson Education do Brasil Titulo original: Exploiting software: how to b1eak code

2004 by Pearson Education, Inc.

Tradu~ao 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

Em memoria de Nancy Simone McGraw

(1939-2003).

Pagina em branco

Sumario

Padroes de ataque xi

Apresenta~ao xiii

Prefacio xvii

Agradedmentos xxi

1 Software - a raiz do problema 1 Uma breve hist6ria do software 2 0 software defeituoso e onipresente 9 A trindade problematica 12 0 futuro do software 21 0 que e seguran~a de software? 29 Conclusao 31

2 Padroes de ataque 33 Uma taxonomia 34 Uma visao dos sistemas abertos 37 Um passeio por uma explora

V11l

As abordagens da engenharia reversa 70 Metodos do reversor 7 5 Escrevendo plugins para o IDA (Interactive Disassembler) 82 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 cobertura de c6digo 126 Conclusao 131

4 Explorando software servldor 133 0 problema da entrada confiavel 134 0 problema de elevac;ao de privilegios 136 Descobrindo os pontos de injec;ao 139 Rastreamento de caminhos de entrada 141 Explorando a confianc;a via configuracrao 146 Tecnicas especfficas e ataques contra software servidor 151 Conclusao 180

5 A arte de explora~ao de software cllente 181

6

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

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 Exemplo: Revertendo o I-Planet Server 6.0 Classificac;ao incorreta 237 Criando solicitac;oes "equivalentes" 238 Envenenamento de auditoria 247 Conclusao 248

228 232

Sumario

Sumario . lX

7 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 333 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 Adicionando suporte de rede a urn driver 389 Interrupcroes 397 Key logging 401 T6picos avan~ados em rootkit 403 Conclusao 404

Referencias 405 ,

lndice 407

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 15 S 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 17 4 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 19 3 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

No infcio de julho de 2003, recebi uma liga

.

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 estrutu-ras 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 e diferente 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 simples-mente 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 publi-car 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 aplica~ao em rede ou siste-ma 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! nao-confiavel 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 con-tra 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 de-monstrou 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 mim 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

Pagina em branco

Prefacio

Aseguran~a de softvvare esta ganhando for~a a medida que profissionais de seguran~a percebem que na realidade a 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 publico-alvo, 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 pro-fissionais 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

xvm Prefacio

Do que trata este livro Ele examina em profundidade varias exploras:oes de software do mundo real, expli-cando 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 utiliza-las para quebrar maquinas.

0 Capitulo 1 descreve por que o software e a raiz do problema em termos de seguran

Prefacio . XtX

buffer overflow que desenvolve o assunto muito alem dos outros textos sobre o as-sunto, 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 descre-ve 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. Tec-nicas avan

XX Prefacio

Se voce forum programador de seguran~a que conhece c6digos, voce ira adorar este livro.

0 publico principal deste livro e 0 programador de seguran~a, mas ha li~oes impor-tantes aqui para todo profissional de computa~ao.

Mas isso nao 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 so-bre 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

Este livro levou um Iongo tempo para ser escrito. Muitas pessoas ajudaram, direta e indiretamente. N6s nos consideramos responsaveis por todos os erros e omis-soes 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 en-quanta 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 conheci-mento tecnico. Um grande obrigado a Matt Hargett por aparecer com uma ideia genial e apresentar a perspectiva hist6rica necessaria para o sucesso. Alem disso, obri-gado 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 em-prestar 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

Agradecimentos .. XXIl

uma estrutura academica subjacente. Gary e muito direto, nao e do tipo academico ran~oso. lsso, juntamente como seu conhecimento profundo sobre o assunto, seen-caixa 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 con-juntura economica pessimista). Urn obrigado especial a equipe de executivos por agiien-tarem 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 auto-iniciativa 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 ocu-pado 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 ani-mais: 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

Entao, 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 inva-sao 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 calcanhar-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

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 rela-r;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: software Pronuncia: 'soft- 11 war, - 11 wer Fun

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

4

100%

90%

80%

70%

60%

50%

40%

30%

20%

10%

Telefone PC celular (1975) (1983)

Internet (1991)

Forno microndas

(1953)

Televlslio (1926)

Videocassete (1952)

Eletricidade (1873)


Aviao (1903)

Telefone (1876)

Autom6vel (1886)

0% ~~~~~~~~~~~~~~~~~~~~~~~~

" ......: ....... ..... Anos

Figura 1.1: 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.)

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 desen-volvimento 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 se-nha 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, nor-malmente 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 Software - a raiz do problema s

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


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: tradecraft PronCmcia: 'tdid-"kraft

Fun~ao: substantive Data: 1961 : tecnicas e procedimentos de espionagem ... (Webster's, pagina 1250) A espionagem moderna e realizada 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 progra-ma~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 qual-quer 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


3. 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


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 per-guntas sao importantes se quisermos abordar adequadamente o problema de criar sistemas segu-ros 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 fun-damento; 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 indepen-dentemente. Tradicionalmente, as empresas que solicitam esse tipo de software nao dao abso-lutamente 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, utili-zando 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 algu-mas das declarac;oes comumente citadas nessa atividade: Uma pessoa "bern informada" normal-mente 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 invaso-

res 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 segu-

ranc;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 explo-rada 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.


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 comprometi-mento 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 atri-buic;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 conhe-cidos 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.)


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 pro-blema foi uma simples tradw;ao computacional entre as unidades de medida do siste-ma 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 prema-ture dos motores de descida quando urn software interpretou errado urn sinal espu-rio 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 at-mosfera marciana.

Bagagem no aeroporto de Denver 0 moderno aeroporto internacional de Denver tem um sistema automatizado de ba-gagem que utiliza carrinhos nao-tripulados que COlTem ao Iongo de um trilho fixo-tudo controlado por software. Quando foram ativados pela primeira vez para testes, os carrinhos nao detectavam nem se recuperavam de falhas corretamente. Isso acon-tecia devido a varies problemas de software. Os carrinhos salam de sincronia, carri-nhos 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 aero-porto 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 adequada-mente. 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


Figura 1.2: 0 MV-22 Osprey em voo. Os softwares sofisticados 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.


,., 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 progra-mas enviados a partir de fontes possivelmente nao-confiaveis. Aparentemente, nin-guem 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 a casa 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 compu-tador. 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 a exploras: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


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 intei-ros 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 defei-tos: 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 siste-ma. 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 Solaris 7 17 milhoes 40 milhoes 10 milhoes 7 milhoes 35 milhoes 1,5 milhoes

14

45

40

35

l{l 30 .J::. c -Q; 25 "0

lG 20 O .J::.

~ 15 10

5

0 -Win 3.1

(1990)


Complexidade do Wjndows

/ /

Win NT

(1995)

Win 95

(1997)

NT 4.0 (1998)

Win 98

(1999)

...

~ /

/ /

NT 5.0 (2000)

Win 2k

(2001)

XP (2002)

l

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 valen-do, 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 de-pende 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 aproxi-madamente 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.


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 x 3.000 EXEs= 1_5_0_.o_oo_bu_,g!,_s EXE host host

Certamente, e uma grande quantidade de bugs, mas o verdadeiro problema ocor-re 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 instan-cias 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 = 4,5 bilhoes de instancias de bug host rede 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


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 x 1 0% = 500 milhoes de instancias de bugs de seguran~a

500 milh6es x 1 0% = 5 milh6es de alvos de bugs de seguran~a remotamente exploraveis

Obviamente, o invasor esta do !ado vencedor desses numeros. Nao e nenhuma sur-presa, 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 atualiza~oes ou extensoes, tambem chamadas de c6digo m6vel, de modo que a funcionalidade do sistema pode evoluir de modo incremental. Por exem-plo, uma Java Virtual Machine (JVM) instancia uma classe em um namespace (espa-


C6digo-tonte Compilador de Mecanismo Procesaode (qualquer lingua- c:ompl~ c6digo-fonte de metadados gem suportada)

....... / ....,

MSIL& ..

Compilador de me tad ados back-end ' l v ,

(.OBJ)

Optil & C6digo" Todas as entidades metadados & metadados dessa caixa podem (.OBJ)

-

(OBJ) tornecer evidencias ~

.......... . e usam verifica90es ( de permissao. Linker

....... + Gerenciamento Assembly de polftica de . !")(!" OU nl I \ seguranya

I( Common Language "\ Cache de

' Runtime Carregador ~ assembly declasse

Evid!!ncia ' Politica (de varias ...

" Framework

fontes) de base (.DLL) Verificador ~ Serviyos

' de perfil

.. t--Verificac6es

/ " Avalia9ao .. de permissao "v" JIT ,,Q, isola do da politica (lnspe~o "". .. .. de '"'' ~ de pilha) depurayllo .. \ t C6digo nalivo ~ ~o~de gerenciado Conjunto de permissoes ,., ''"'" , ~or metodo remoto de c6digo de

Execu~o l tempo de C6digo nativo ""J!() 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 e a menor enfase no suporte a multip las plata-formas. Em todo caso, os sistemas extensfveis vieram para ficar. Em breve, a expres-sao 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 e urn pesadelo de seguran~a. Veto res


ch1ssicos do passado, incluindo a "rede-peao" [snearkernet, transferencia de infor-ma~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 dissemi-nados 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 ativi-dade 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 em-presas 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 w0rm11 explora uma vulnerabilidade de buffer overflow em servido-res 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. E posslvel encomrar mais informa~oes sobre problemas do BIND em http://www.cert.org/advisories/ CA-98.05.


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 altamen-te divulgado, surgiram diversas varia~oes desse worm. 0 Code Red infecta urn servi-dor 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 velocida-de 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 suces-so 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 crfti-cas (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~amento 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 invaso-res 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.


Novos protocolos e meios de entrega sao desenvolvidos constantemente. 0 resul-tado 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 acon-teceria se urn vfrus infectasse a rede de telefonia celular.

Figura 1. 7: Este e urn telefone celular com-plexo oferecido pela Nokia . Conforme os telefones adquirem fun~6es como e-mail e navega


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 seguran-c;a de software mais urgente que nunca. Para infelicidade das pessoas de bern, a trio-dade 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 institui~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 compro-metidos, 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 con-testados, 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 e que 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, qual-quer pessoa que se propoe a prever o futuro esta fadada a erro). Portanto, seja caute-loso 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 con-solidando. 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 .


confi::lveis e seguros. As empresas que tern c6digo de missao crftica estao utilizan-do 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 desen-volvimento 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 extrema-mente util ao abordar o problema de cria~ao de softwares criticos para a seguran-c;a, porque os componentes-padrao que implementam uma arquitetura de segu-

ran~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


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 pro-mete 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 progra-mados remotamente e utilizam o paradigma do c6digo m6vel para receber e ins-talar 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 inte-ressante. 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 e diffcil faze-los funcionar perfeitamente. Os sistemas distribuidos mais comuns da atualidade estao colocados geografica-mente 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 e um sistema logicamente distribuido. Infeliz-mente, a complexidade e amiga da exploras;ao de software; sendo assim, os siste-mas 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 mer-cado, isso e urn 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.


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 sen-do 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


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


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 inteli-gentes" . 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 espe-cial" 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 a 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.

Dissemina


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 usua-

,

rios 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.

0 c6digo m6vel prevalecera: Devido a onipresenc;a dos sistemas em rede, no futu-ro todo c6digo sera m6vel. 0 termo c6digo m6vel cairci em desuso por ser redun-dante. 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 fo-ram 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 acelera-

18. Naturalmentc, isso e Ulll resquicio dos sistemas de tempo compartilhado das decadas de 1960 c 1970.


~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


' Sistemas auto-organizaveis e computa~ao emergente: E possfvel que seja inventa-do 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 futuro dis-tante 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. Evolu~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) Devido a 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


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


De fato, o software desempenha urn papel significativo na manuten~ao dos neg6cios da maioria das empresas atuais. Podemos tentar impedir que pessoas mal intenciona-das 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


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

U m problema bern real da seguranc;a computacional e a 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 segu-ranc;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 determi-nada 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.

1. Para informa~oes adicionais sobre a importancia da observabilidade e dos testes, consulte Software Fault Injection [Voas e McGraw, 1999].


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 in-completa e antiquada. A boa notlcia e que durante os ultimos anos urn grande con-junto de explora~oes de software especificos foi identificado, discutido e divulgado em varias partes da comunidade de software.

Duas cole

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 profis-sionais 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 "suprimi-dos". 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 pesquisa-dores 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 tratamen-to 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 so-mente 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


As vulnerabilidades podem ser definidas em termos de c6digo. Quanto mais com-plexa 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, e necessaria uma descri-c;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 en-tre 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 vulnerabili-dade 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 segu-ranc;a de software.

5. Michael Howard, comunica~ao pessoal.


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 normalmen-te esta presente em cada objeto e metoda, e o c6digo de tratamento de erro normal-mente 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 deter-minar 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 audito-ria/registro em log ou registro em log incorreto, erros de pedido e sincroniza~ao (espe-cialmente 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 con-seguem ter uma visao sistemica do problema. A tradi~ao de criar taxonomias de fa-lhas freqi.ientemente tenta separar os defeitos de codifica~ao e os "defeitos emergen-tes" (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 al-guns casas, um atague potencialmente fatal nao oferece, em ultima instancia, risco algum se o firewall conseguir bloquea-lo. Embora determinada parte do software-alva 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.


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


I II I App App

App

I Sistema operacional

Figura 2.1 : Uma visualiza~ao conceitual tlpica de aplicativos de software (app) como estruturas hierarquicas aninhadas. A realidade e 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


Risco Ao denominar tipos espedficos de vulnerabilidades, podemos come~ar a atribuir nf-veis 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 (acredita-mos 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 e urn 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. Ignora-mos 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). Port

Documents

LIVRO - COMO QUEBRAR CÓDIGOS - A ARTE DE EXPLORAR (E PROTEGER) SOFTWARE