Irã e SSL, Apache DoS, Morto Worm, RSA Hack, Exploit Kits e +..

Como o blog passou um tempo acima do normal sem atualizações (2 semanas), os assuntos interessantes se acumularam - por este motivo aí vai mais um post no estilo "Curtas e Boas":

• Mais uma vez (assim como no caso do ComodoGate de março deste ano) o Irã é suspeito de estar monitorando tráfego criptografado (SSL) através do uso de certificados digitais forjados - o Google alertou hoje sobre uma autoridade certificadora holandesa chamada DigiNotar que teria emitido os certificados falsos em nome de serviços do Google (como o Gmail).

• O Team Cymru publicou mais um ótimo episódio no Youtube - Email Forensics, DDoS Mitigation Steps & Animations  <= Já são mais de 100 episódios, vale a pena dar uma olhada nos assuntos e assistir alguns mais antigos..

• A Kaspersky publicou um interessante resumo com dados e estatísticas sobre ataques de DDoS ocorridos no 2o 'quarter' de 2011

• Morto Worm  - Depois de um bom tempo sem um worm digno de nota, apareceu um que se conectar à RDP (Remote Desktop - tcp 3389) em máquinas Windows usando o usuário "Administrator" e uma lista de senhas pré-definidas. O modus operandi é similar ao dos Worms que se propagam por SSH utilizando senhas fáceis. Veja detalhes no site da Microsoft e do ISC/SANS. Para fazer download do binário, siga este link.

• Web Exploitation Tools: Drive-By-Downloads são cada vez mais comuns.  o Dancho Danchev publicou alguns dealhes interessantes de alguns kits neste post  Mais informações sobre exploit packs podem ser vistos neste Whitepaper: http://www.team-cymru.com/ReadingRoom/Whitepapers/2011/Criminal-Perspective-On-Exploit-Packs.pdf

• O Raphael Mandarino - do Gabinete de Segurança Institucional da Presidência da República - publicou, através do site Convergência Digital, um curto artigo entitulado "Sobre bandidos e hackers" - apesar de não achar estas discussões etimológicas produtivas, vale a leitura..

• De carona com outros ataques/vulnerabilidades de negação de serviço a servidores web, como o slowloris do RSnake e o Owasp HTTP Post Tool, foi divulgada uma nova ferramenta pronta para os script kiddies usarem, que explora uma vulnerabilidade deste tipo no Apache,  Estar em dia com os patches do seu servidor web ajuda (enquanto não sai o patch, veja as recomendações de mitigação em "Range header DoS vulnerability Apache HTTPD 1.3/2.x"  - obrigado pelo comentário, Fernando!), uma outra dica é utilizar um Web Application Firewall como o modsecurity. Uma ferramenta que pode ser utilizada para checar pelos 3 tipos de vulnerabilidade é a slowhttptest (mais detalhes aqui).

• Detalhes de como a RSA foi comprometida em março foram divulgados pela F-Secure (incluindo o .xls que carrega o payload - 0day na época - e instala o backdoor Poison Ivy). Tudo indica que um funcionário da EMC/RSA enviou um arquivo de mensagem do outlook (.msg) contendo o .xls para o VirusTotal ainda em março..

Comodo Hack e MySQL.com SQL injection

A poeira da invasao e possivel compremetimento do código do SecurID da RSA ainda não baixou e outros ataques que merecem nota já ocorreram nos últimos dias. Segue um breve resumo sobre o I) #ComodoGate e II) blind SQL injection do MySQL.com e Sun.com.

I) COMODOGATE:


Update (25/05/2011 - 09:34) - A ComodoBr.com (apesar dos varios selos estilo "HackerSafe" no rodape do site) foi tambem comprometida via SQL Injection e um dump parcial de seu Banco de Dados foi publicado: http://pastebin.com/9qwdL1pA

Update (04/04/2011- 12:17) - O cryptome.org acaba de publicar um .rar com dois arquivos com o backup dos bancos de dados da GlobalTrust (33M) e da InstantSSL (9,3M).

Update (30/03/2011 - 17:43) - Mais 2 Autoridades Registradoras da Comodo foram comprometidas (além da italiana GlobalTrust). Que outros certificados forjados foram gerados? Aguardemos..

Fonte: o "ComodoHacker" postou mais uma de suas mensagens no estilo "Avassalador" em http://pastebin.com/kkPzzGKW - Trecho:

"From listed resellers of Comodo, I owned 3 of them, not only Italian one, but I interested more in Italian brach because they had too many codes, works, domains, (globaltrust, cybertech, instantssl, etc.) so I thought they are more tied with Comodo".

A Comodo confirmou em mensagem de um executivo, que descreve algumas das ações de "contenção de danos" que estão sendo colocadas em prática pela empresa.

Update (29/03/2011 - 20:15) - o G1 Segurança (Globo.com) publicou bastante material sobre o tema - Hacker invade empresa de segurança e falsifica 'cadeados' de sites - incluindo link para este post. Obrigado @altieres!

Update (29/03/2011 - 14:33) - o jornal Alemão Der Spiegel também o entrevistou.

Update (28/03/2011 - 18:47) - o blog ErrataSec divulgou uma entrevista com o hacker iraniano responsável pelo "ComodoGate.

Update (28/03/2011 - 17:01h) - O "ComodoHacker" agora tem conta no twitter: @ichsunx e acaba de divulgar outros dois dados para confirmar que é ele o responsável pelos ataques: 1) o Certificado falso gerado para o site de addons da Mozila. 2) a tabela de hashes de um BD do RA invadido.

Todos os textos publicados pelo hacker podem ser visualizados no seguinte link: http://pastebin.com/u/ComodoHacker

1) O Certificado parece válido - eis a saída do comando " $ openssl x509 -in mozilla.crt -text -noout "

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

92:39:d5:34:8f:40:d1:69:5a:74:54:70:e1:f2:3f:43

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware

Validity

Not Before: Mar 15 00:00:00 2011 GMT

Not After : Mar 14 23:59:59 2014 GMT

Subject: C=US/postalCode=38477, ST=Florida, L=English/streetAddress=Sea Village 10, O=Google Ltd., OU=Tech Dept., OU=Hosted by GTI Group Corporation, OU=PlatinumSSL, CN=addons.mozilla.org

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (2048 bit)

Modulus (2048 bit):

00:ab:c6:6d:36:f3:15:73:78:83:73:ce:74:85:d5:

ae:ec:b2:f0:e0:24:1f:13:83:b8:20:ac:bb:9a:fe:

88:bb:ab:a1:1d:0b:1f:45:00:aa:49:b7:35:37:0c:

6a:ef:47:4c:b9:d1:be:e3:57:12:04:8d:92:c7:b6:

ec:01:bc:b6:da:c7:81:38:20:ad:72:85:e6:0e:fc:

81:6c:07:ad:68:76:38:c5:44:d7:cc:c6:4a:c5:97:

3e:64:f4:51:e6:f0:7e:b2:ec:56:f7:25:82:4d:49:

98:cb:16:98:dd:23:f1:89:91:d1:17:97:40:99:26:

d6:e2:a2:2b:5e:df:bd:89:f2:1b:1a:53:2d:cc:50:

41:7a:d0:3d:2a:0c:55:70:14:01:e9:58:49:10:7a:

0b:93:82:8b:e1:1e:ed:3a:80:10:82:ce:96:8a:34:

f0:cc:d7:d3:b9:b4:50:87:55:54:09:b8:9d:42:28:

55:00:e5:8c:35:54:bf:dd:25:91:46:b7:0d:e5:5d:

83:a8:e5:8b:fb:84:e4:3c:ae:76:da:c4:43:2b:5b:

74:0b:f8:be:5d:68:f1:78:5b:b5:ce:7d:f1:5d:99:

40:da:ca:ee:38:81:50:be:98:a1:6c:b8:24:ad:f3:

af:8c:0f:d7:11:28:2c:84:18:4c:7d:b5:d9:8f:30:

b5:1b

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Authority Key Identifier:

keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45

X509v3 Subject Key Identifier:

DD:80:D2:54:3D:F7:4C:70:CA:A3:B0:DD:34:7A:32:E4:E8:3B:5A:3B

X509v3 Key Usage: critical

Digital Signature, Key Encipherment

X509v3 Basic Constraints: critical

CA:FALSE

X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

X509v3 Certificate Policies:

Policy: 1.3.6.1.4.1.6449.1.2.1.3.4

CPS: https://secure.comodo.com/CPS

X509v3 CRL Distribution Points:

URI:http://crl.comodoca.com/UTN-USERFirst-Hardware.crl

URI:http://crl.comodo.net/UTN-USERFirst-Hardware.crl

Authority Information Access:

CA Issuers - URI:http://crt.comodoca.com/UTNAddTrustServerCA.crt

OCSP - URI:http://ocsp.comodoca.com

X509v3 Subject Alternative Name:

DNS:addons.mozilla.org, DNS:www.addons.mozilla.org

Signature Algorithm: sha1WithRSAEncryption

33:3b:63:15:fc:b1:ec:14:2c:93:dd:75:94:de:81:5a:d9:4e:

99:be:fb:4a:a4:39:55:4d:a1:40:7a:de:13:2a:87:a9:37:cf:

e8:d5:fb:ad:d1:7b:6d:6f:8c:20:87:82:54:e6:57:49:bc:20:

28:84:cd:d6:01:d9:93:8b:17:6e:23:66:e5:84:c8:80:3f:c6:

a1:70:80:e4:ec:4d:1d:f9:fc:91:5a:73:62:29:9a:f7:20:1c:

61:e0:8b:39:9f:ca:bc:7e:8d:dd:bc:d9:b1:e3:9f:9e:df:15:

53:91:21:52:0b:d9:1a:23:0f:66:36:db:ac:93:96:4a:a3:a5:

22:cf:29:f7:a2:99:a8:f6:b6:d9:40:ae:d9:7e:b6:f6:58:2e:

9b:ac:36:ca:64:8f:65:52:dc:86:9c:82:ab:6e:50:4b:da:5f:

fa:05:00:88:30:0e:de:8d:56:bf:81:47:8d:3d:06:e2:b2:62:

92:67:8f:9e:c8:9a:b2:e5:06:b8:70:24:b8:77:7c:23:0a:38:

c3:79:08:d8:b1:51:9d:ac:95:11:c7:40:17:9e:a3:1c:8f:f2:

11:a7:68:27:da:49:05:84:18:7c:58:2d:01:67:5c:e5:9f:a1:

29:bb:4a:39:45:2f:bf:11:aa:79:a2:ed:b4:d4:b5:65:43:b7:

93:46:8a:d3

A chave privada também foi postada:

-----BEGIN RSA PRIVATE KEY-----

MIIEowIBAAKCAQEAq8ZtNvMVc3iDc850hdWu7LLw4CQfE4O4IKy7mv6Iu6uhHQsf

RQCqSbc1Nwxq70dMudG+41cSBI2Sx7bsAby22seBOCCtcoXmDvyBbAetaHY4xUTX

zMZKxZc+ZPRR5vB+suxW9yWCTUmYyxaY3SPxiZHRF5dAmSbW4qIrXt+9ifIbGlMt

zFBBetA9KgxVcBQB6VhJEHoLk4KL4R7tOoAQgs6WijTwzNfTubRQh1VUCbidQihV

AOWMNVS/3SWRRrcN5V2DqOWL+4TkPK522sRDK1t0C/i+XWjxeFu1zn3xXZlA2sru

OIFQvpihbLgkrfOvjA/XESgshBhMfbXZjzC1GwIDAQABAoIBAQCJoijaEXWLmvFA

thiZL7jEATCNd4PK4AyFacG8E9w8+uzR15qLcFgBTqF95R49cNSiQtP/VkGikkkc

ao25aprcu2PnNA+lpnHKajnM9G3WOHuOXHXIps08es3MmBKTxvjNph6cUlqQULrz

Zry+29DpmIN/snpY/EzLNIMptn4o6xnsjAIgJDpQfFKQztxdmZU6S6eVVn0mJ5cx

q+8TTjStaMbh+Yy73s+rcaCXzL7yqWDb1l5oQJ/DMYNfufY6lcLgZUMwFxYKjCFN

ScAPCiXFUKTzY3Hy1Z4tLndFxipyEPywDep1TB2nMb+F3OOXUs3z+kKVjGFaGnLZ

591n3x3hAoGBAOOgsb4QybjHh9+CxhUkfsqcztGGdaiI3U5R1qefXL7R47qCWfGc

FKdoJh3JwJzHEDX68ZmHz9dPhSXw6YrlLblCi6U/3g7BOMme5KRZKBTjHFo7O9II

B0laE5ISRH4OccsOC3XUf9XBkm8szzEBj95DgzB0QydPL4jp7NY0h0QrAoGBAMEv

jEFkr/JCRe2RWUSx/a1WT/DHnVLMnDb/FryN2M1fAerpMYNUc2rnndjp2cYbsGLs

cSF6Xecm3mUGqn8Y5r8QqBwxCp5OunCFCXEJvkiU3NSs8oskCsB8QJ6vk3qmauUK

jClX91heSCigwhC2t+1txnF290m/y0T46EfqOSrRAoGAUlyVk4D9jEdeCWiHBaVj

3ynnx3ZQYj/LW4hPE+2coErPjG+X3c0sx/nuOL8EW3XHjtCS1IuIj45tTfIifqg3

6B2E67D1Rv9w7br5XeIIl64pVxixp2hSQp8+D49eiwHs+JzHVsYhzxUwR9u9yCyZ

gsGI2WJn3fRP7ck+ca8l9msCgYB4B2Hec3+6RqEKBSfwvaI+44TRtkSyYDyjEwT+

bCeLGn+ng/Hmhj8b6gKx9kH/i86g+AUmZtAXQZgmLukaBM/BYMkCkxnk2EeQh6gh

Goumrw8x+K7N8rvXcpv3vGEmcGW0H0SMn4In3pR44cER/2Tx2SXV87Obl9Xk6b3w

iL+yMQKBgFjXcmiBW8lw3l2CaVckd/1SzrT80AfRpMT9vafurxe+iAhl9SDAdoZe

3RlshoItDQLW1ROlkLhM7Pdq/XZvLRm128hiIGKTDBnxtfN8TKAg+V7V+/TTfdqv

8jq7epvZsq5vjOC1FZh2gOhf50QwpqDJktjdyka1sPiBKQSoxfbZ

-----END RSA PRIVATE KEY-----

Resumindo os passos:

a) usando o certificado publico da mozilla para addons.mozilla.org para criptografar um arquivo:

$ openssl rsautl -encrypt -inkey public.pem -pubin -in verify.txt -out encrypted

b) usando o certificado privado divulgado pelo hacker (acima) para descriptografar:

$ openssl rsautl -decrypt -inkey private.pem -in encrypted -out decrypted.txt

c) verificando que os arquivos são iguais e portando a chave privada é válida:

$ md5sum verify.txt decrypted.txt

830ea5a732ec9c497d5999ca7b9575b2 verify.txt

830ea5a732ec9c497d5999ca7b9575b2 decrypted.txt

A "prova dos 9" está postada em http://erratasec.blogspot.com/2011/03/verifying-comodo-hackers-key.html

2) a tabela de hashes do RA italiano comprometido - como era esperado - já começou a ser crackeada (fonte):

Post Original (28/03/2011 - 03h30):

No ano passado, no post "Root DNS, CA e AS - uma questão de (des)confiança" - já havíamos alertado para as falhas estruturais que foram exploradas pelo(s) hacker(s) que emitiram certificados emitidos pela Comodo:

Os Root Certificates são a base do sistema de confiança de comunicações criptografadas de comércio eletrônico, personal banking, etc - São utilizados em comunicações criptografadas e pré-cadastrados e autorizados por sistemas operacionais e navegadores, que possuem listas independentes que são enviadas aos usuários sem sua anuência.

Num exemplo corriqueiro, uma vez que um certificado SSL/TLS seja apropriadamente assinado por um destes certificados raiz, ele passa a ser "confiável" e o usuário verá o cadeado ao lado da URL iniciada porhttps no navegador - gerando uma sensação de confiança que muitas vezes pode não corresponder à realidade. (..continua.. )

E foi exatamente isto que aconteceu.. Uma vez que um atacante possua um certificado assinado por uma root CA e por conseguinte aceito pelo browser do usuário - game over. Ataques do tipo MITM (man-in-the-middle) podem ser aplicados - vide demo com o sslstrip. O resultado: nem o usuário, nem o site que utiliza https não perceberão que sua comunicação "https" está sendo "aberta" e lida por um adversário.

Muito se especulou sobre como o ataque teria ocorrido e sobre a atribuição de responsabilidade:

- Iran targets Gmail and Skype with fake SSL hack (PCPro - UK)
- Hack Obtains 9 Bogus Certificates for Prominent Web Sites - Traced to Iran (Wired)
- Iranian Hackers Suspected in Recent Security Breach (New York Times)

A própria empresa atacada (Comodo) liberou dados sobre o comprometimento - resumindo:

- 9 certificados falsos foram emitidos: entre eles Microsoft Live (Hotmail), Yahoo, Skype, Google , Gmail, Mozilla Addons [ nota:

- Evidências (IPs) indicam que ataque veio do Irã. [ nota: conforme Bejtlich e Coppert, a atribuição mais precisa de responsabilidade para este tipo de ataque precisa considerar mais pontos, dentre eles: 1)Timing, 2)Vítimas,3)Origem, 4)Mecanismo de Entrada, 5)Vulnerabilidade ou Exposição, 6)Exploit ou Payload, 7)Weaponization,8)Atividade pós-exploração, 9)Método de Comando e Controle, 10)Servidores de Comando e Controle,11)Ferramentas, 12)Mecanismo de Persistência, 13)Método de Propagação, 14)Dados Alvo, 15)Compactação de Dados, 16)Modo de Extrafiltração, 17)Atribuição Externa, 18)Profissionalismo, 19)Variedade de Técnicas, e 20)Escopo.

- O foco do atacante foi a infra-estrutura de comunicação, e não financeira como em um cybercrime tradicional [ nota: realmente, o atacante poderia ter lucrado milhões emitindo certificados falsos de bancos por exemplo. A análise dos pontos 2-vítimas 14-dados alvo e 20-escopo dentre as possíveis atribuições listadas acima parecem indicar um ataque focado na monitoração de comunicações e possivelmente com interesse político e não econômico.]

- O atacante somente pode fazer uso dos certificados se controlar a infra-estrutura de DNS [nota: para uma capacidade de "grampo" nacional, sim [ nota: no caso da suspeita do envovimento do governo do Irã), mas ataques a estrutura de DNS de pequenos ISP até root-dns são possíveis.. ]

- O perpetrador executou seus ataques com precisão cirúrgica / O governo do Irã recentemente atacou outros métodos de comunicação criptografada. [nota: bons pontos, mas a dificudade de atribuir a responsabilidade a um Estado por ações como esta é constante e já observamos no caso do Aurora, e do StuxNet, por exemplo. ]

Até que - supostamente (a ser confirmado) - o próprio "hacker" publicou - hoje - um "manifesto" sobre detalhes do ataque, seus objetivos e motivações (e completa falta de modéstia =) .Para comprovar a autoria do incidente, mais tarde ele publicou partes do código decompilado da biblioteca "TrustDLL" do parceiro da Comodo.

Dentre os comentários do "ComodoHacker" - destaco:

- o RA (Registration Authority) invadido foi a italiana GlobalTrust.it / InstantSLL.it
- não há um grupo de hackers envolvido no ataque, somente ele (com a "experiência de 1000")
- ele cita que decidiu hackear o algoritimo RSA - mas não há evidências que o liguem ao ataque ao SecureID (que discutiremos mais abaixo neste post)
- ele reclama que muita atenção está sendo dada a este ataque e mais ninguém escreve sobre o StuxNet e o envolvimento de Israel e dos EUA aos ataques às centrífugas iranianas, e também reclama que a mídia não dá atenção aos projetos HAARP e Echelon..

O "hacker" termina sua carta com a seguinte frase: "Janam Fadaye Rahbar”, que significa “Eu vou sacrificar minha alma pelo meu líder".

Os ingredientes da história indicam que se tratou de um ataque com o objetivo de possibilitar uma fácil monitoração de comunicação encriptada com SSL e - independente de quem foi o responsável - um possível "cliente final" é o governo do Irã (aliás, qualquer governo interessado em monitorar a comunicação de seus cidadãos) .

Algumas reações ao que foi publicado pelo "ComodoHacker":

- The Comodo hacker releases his manifesto (ErrataSec)
- Solo Iranian hacker takes credit for Comodo certificate attack (ComputerWorld)
- How the Comodo certificate fraud calls CA trust into question (ArsTechnica)

Contramedidas:

A criptografia por sí não é útil sem a autenticação / confiabilidade dos dois lados da comunicação, e por isto os principais browsers (Chrome, Firefox, IE) já atualizaram suas blacklists com a lista dos certificados SSL fraudulentos. Esteja certo que você utiliza a última versão do seu navegador e habilite a checagem "verificar revogação certificado" / OCSP - Online Certificate Status Protocol.

O problema é que um atacante em condições de interceptar as comunicações https também pode impedir que o processo de validação das blacklists funcione adequadamente - enviando para o cliente um código 3 OCSP - try later.

Mais detalhes sobre isto pode ser visto na apresentação de Moxie Marlinspike na BlackHat de 2009, chamada "More Tricks For Defeating SSL In Practice" - (se estiver com pressa, veja a página 129) e outro bom material sobre o assunto aqui (revocation is useless). Como vocês podem ver, mais uma vez o Chrome (e agora o FF4) sai na frente no quesito segurança por suportar HSTS - o que ao menos gera um alerta ao usuário..

Como já informamos por aqui anteriormente, um passo é manter em seu browser apenas os certificados-raiz realmente necessários.

Um tweet recente do Moxie Marlinspike sugere aos possíveis responsáveis pelo ataque (os iranianos) que liberem os americanos Shane and Josh caso o Irã esteja usando a ferramenta dele (sslstrip) com o modo autoupdate para evitar o download de add-ons de segurança do firefox (em http://addons.mozilla.org).

Outras dicas de como evitar a utilização de certificados forjados pelo seu browser foram publicadas nos links a seguir:

- How to avoid fraudulent SSL (Verisign)

- Detecting Certificate Authority compromises and web browser collusion (TorProject)

Do ponto de vista corporativo, você pode monitorar os certificados SSL vistos no seu gateway internet e revisá-los, com ferramentas free como o Bro-IDS ou o NetWitness Investigator.

II) MySQL.com / Sun.com Blind SQL injection:

Casa de ferreiro.. como sabemos, o MySQL foi adquirido pela Sun e a Sun foi adquirida pela Oracle.

Pois bem, hoje foi publicada na lista Full Disclosure a exploração via Blind SQL Injection dos principais bancos de dados do site Mysql.com, e o mysql do site Sun.com também foi comprometido via SQLi.

Vale ressaltar que SQL Injection consta como 2o lugar na lista do MITRE/Sans (http://cwe.mitre.org/top25/) que divulga os 25 erros mais comuns em softwares.

Dentre os dados divulgados estão as tabelas, colunas e hashes de senhas (MD5) de usuários do site que já estão sendo crackeadas e publicadas.. O header dos dados segue abaixo:

Vulnerable Target : http://mysql.com/customers/view/index.html?id=1170
Host IP : 213.136.52.29
Web Server : Apache/2.2.15 (Fedora)
Powered-by : PHP/5.2.13
Injection Type : MySQL Blind
Current DB : web

Atribuição de Responsabilidade:

O ataque é atribuído ao duo de hackers romenos "TinKode" e "No0h".

Mais informações/repercussões sobre este ataque:

-
How Mysql.com and Sun.com got hacked<\a> Infoworld

- MySQL WebSite Hacked by (Ironically) Blind SQL Injection (HP/@Wh1t3Rabbit)

- MySQL.com and Sun hacked through SQL injection (Sophos)

- MySql.com compromised (Sucuri)

- MySQL.com compromised via SQL Injection attack. Someone should have read Chapter 6. (Securing SQL Server)

Inscreva-se no RSS Feed e receba atualizações automáticas

Root DNS, CA e AS - uma questão de (des)confiança

[ Update - 27/05/2010 ]


Sobre o ítem II abaixo - ROOT CA's - hoje tomei conhecimento de um experimento interessante feito por Nasko (do site http://netsekure.org).

Da lista inicial de mais de 100 certificados raiz instalados nos navegadores Internet Explorer, Chrome (ambos lêem isto da lista do Windows) e no Firefox, apenas 10 foram realmente necessários depois de um mês de navegação intensiva.

Recomendado também são os demais posts do NetSekure, incluindo um sobre como remover os certificados raiz "confiáveis" do Windows.


[ Post Original - 12/04/2010 ]


Uma das bases psicológicas da segurança é a confiança. Por mais matemática e tecnologia que sejam continuamente aplicadas, muitos dos protocolos e sistemas que garantem o funcionamento "seguro" da infraestrutura de Internet são baseados neste princípio de delegação de segurança (confiança) em diferentes níveis, como por exemplo:

I) Domain Name System (DNS)

II) Certificados raiz SSL (ou Root CAs)

III) Autonomous Systems (ASs)

Vários incidentes recentes - descritos abaixo - chamam a nossa atenção para a fragilidade da dependência no modelo de confiança - e especialmente na implementação deste.

I) DNS

O DNS (Domain Name System) é um sistema hierárquico para resolução de nomes. Existem 13 root servers (A->M).

O ataque de redirecionamento de navegação através do controle da resolução de nome (DNS) pode ser feito de diversas formas, incluindo dns cache poisoning, a edição de arquivo hosts (muito usada em ataques de phishing), e a alteração ou criação de entradas nas tabelas de resolução de servidores DNS comprometidos, por exemplo.

Como sabemos, alguns países controlam a Internet usando técnicas similares às descritas. A China é um exemplo: ela obriga os provedores que atuam no país a redirecionar a resolução de nomes de sites proibidos (como YouTube, Twitter e FaceBook) para sites chineses onde o governo tem total controle do conteúdo.

Há poucos dias, o DNS raiz I - i.root-servers.net - começou a resolver endereços alterados chineses mesmo para clientes em países ocidentais, como o Chile e os Estados Unidos.

Depois do problema a empresa sueca NetNod - responsável pelo servidor DNS raiz "I" - deixou de fazer anúncio de rotas a partir desta instância do servidor DNS raiz localizada na China.

Mais tarde a empresa explicou que a instância do servidor I que roda na China é exatamente igual aos demais root servers e que as entradas de DNS alteradas foram inseridas em trânsito pelo governo Chinês. Este tipo de situação poderia ser evitada se os clientes utilizassem o DNSSEC.

Recentemente publicamos um post sobre o DNSSEC - que traz melhorias significativas de segurança no uso do serviço DNS e que já começou a ser implementada.

II - SSL/TLS

Outra implementação falha de confiança hierárquica é o baseado na utilização de certificados digitais assinados por "certificados raiz".

Os Root Certificates são a base do sistema de confiança de comunicações criptografadas de comércio eletrônico, personal banking, etc - São utilizados em comunicações criptografadas e pré-cadastrados e autorizados por sistemas operacionais e navegadores, que possuem listas independentes que são enviadas aos usuários sem sua anuência.

Num exemplo corriqueiro, uma vez que um certificado SSL/TLS seja apropriadamente assinado por um destes certificados raiz, ele passa a ser "confiável" e o usuário verá o cadeado ao lado da URL iniciada por https no navegador - gerando uma sensação de confiança que muitas vezes pode não corresponder à realidade.

Um paper (pdf) recentemente publicado por Christopher Soghoian e Sid Stamm mostra que a interceptação de comunicações SSL pode ser mais comum do que se pensa.

Qualquer um que possa obter um certificado falso - de qualquer autoridade certificadora confiada pelo S.O ou navegador - pode criar um website "seguro" com qualquer endereço. Os navegadores não emitirão nenhum aviso e aceitarão o certificado como se fosse legítimo. Mais detalhes aqui.

O vendor PacketForensics comercializa um appliance para interceptação de tráfego SSL que executa as ações descritas acima. Porém proxies SSL podem também ser criados usando ferramentas open-source como o nginx ou o httpd da apache.

Portanto, a questão importante para o sucesso da interceptação não é necessariamente o vendor usado e sim quão "bem falsificado" será o certificado. E em última instância, se você pode obter um (legalmente via mandado judicial ou ilegalmente via hacking) de uma das várias Autoridades Certificadores aceitas pelos navegadores.

Os autores do paper desenvolveram um plugin para Firefox chamado CertLock que gera um aviso caso seja detectada uma tentativa de forjar um certificado SSL e controla / avisa o usuário qual AC assinou um determinado certificado.

Minha opinião sobre o assunto - você não deve assumir que uma comunicação é segura a não ser que você tenha real controle sobre as chaves privadas envolvidas na comunicação.

Além disto, não se esqueça que existem computadores envolvidos na comunicações e portanto programas especialmente criados para monitoração de computadores podem ser utilizados - inclusive pelas Forças da Lei - quando autorizadas - (vide o software CIPAV usado pelo FBI)

III - Autonomous Systems

A RFC 1930, seção 3 descreve o funcionamento dos AS (Autonomous Systems). De forma simplificada - desde a criação da Internet na década de 60, houve um enorme crescimento das tabelas de roteamento, o que trouxe a necessidade de protocolos de roteamento hierárquicos. Os roteadores desde então são divididos em regiões chamadas Autonomous Systems. (ex: AS4230 - Embratel - gráfico de peering).

No começo deste mês um Provedor da China Telecom fez um hijack de uma parte considerável da Internet. Trata-se do AS23724 - gráfico de peering).

Apesar de ser responsável por apenas 40 prefixos, este AS começou a anunciar quase 40.000 prefixos que não eram de sua responsabilidade - em um ataque conhecido como BGP hijack ou prefix hijack.

Resultado? Sites como dell.com, cnn.com, www.amazon.de, www.rapidshare.com, www.geocities.jp, entre outros foram afetados diretamente.

Uma situação semelhante havia ocorrido em fevereiro de 2008 quando um provedor paquistanês fez hijack dos prefixos utilizados pelo Youtube.

O acesso ao site Youtube foi também afetado em 2007, no caso do vídeo na praia de Daniela Cicarelli - quando alguns AS´s brasileiros acataram a decisão judicial do Tribunal de Justiça do Estado de São Paulo e redirecionaram para 'null/0' todo o tráfego destinado ao Youtube.

Estamos acostumados a considerar a "boa fé" de usuários - que clicam em links, abrem anexos suspeitos, passam informações confidenciais a qualquer interlocutor - como um elo fraco da Segurança da Informação.

Os três exemplos citados (DNS, CA/SSL e AS/BGP) mostram que as fragilidades baseadas no modelo de confiança pré-existente são sérios e influenciam negativamente também a segurança da infraestrutura da Internet.

Vulnerabilidade SSLv3 e TLS

[ Update - 2010/01/13 ]

A Internet Engineering Task Force (IETF) publicou uma extensão de segurança para o protocolo SSL que corrige a falha desctrita no post original (que afeta implementações em servidores, navegadores, smartcards, produtos VPN, etc.).


Mais informações em:



http://www.darkreading.com/vulnerability_management/security/vulnerabilities/showArticle.jhtml?articleID=222300635

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tls-renegotiation-03.txt


[ Post Original - 2009/11/18 ]

Na última semana veio a público um trabalho de Steve Dispensa, Marsh Ray e Martin Rex que descreve uma séria vulnerabilidade na fase de renegociação dos protocolos SSLv3 e TLS.

Em linhas gerais, o ataque permite que um atacante faça um "Man in The Middle", injetando informações de sua escolha no começo do stream que será passado de volta para aplicação sendo "protegida" por SSL/TLS, permitindo desta forma algumas possibilidades de exploração bastante preocupantes, como o a escolha pelo atacante de que requisições / transações serão feitas a um internet banking - depois da autenticação do usuário, por exemplo.

O problema está na falta de associação a uma conexão existente durante a renegociação do handshake no SSL/TLS.

Uma descrição detalhada da vulnerabilidade e suas possíveis contra-medidas do lado do cliente e servidor, além de algumas aplicações práticas de exploração delas (SMTP, HTTPS) foi publicada hoje por Thierry Zoller, da G-SEC.

Entrada no CVE (Common Vulnerabilities and Exposures)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.

Mais detalhes: http://securosis.com/blog/what-the-renegotiation-bug-means-to-you/