[Owasp-brazilian] retomando a discussao sobre comunicacoes inseguras

Thiago Zaninotti thiago at zaninotti.net
Fri Feb 20 15:05:00 EST 2009


Oi Nash,

Talvez você tenha se confundido sobre o tipo de ataque. O problema não é
confiar a segurança nas mãos da "infraestrutura SSL", mas simplesmente pelo
fato que a combinação de fatores simples e culturais no dia-a-dia do usuário
de aplicações Web acabam por permitir que esta condição prospere:

- As pessoas acessam aplicações seguras (HTTPS) a partir de links promovidos
por aplicações abertas (HTTP);
- Administradores de aplicações seguras (HTTPS) geralmente também permitem
que uma transação seja invocada usando HTTP (mesma aplicação "bindeada" em
portas 80 e 443);
- As pessoas são facilmente confundidas com símbolos tradicionais do
e-commerce -- basta alterar seu o favicon do browser para um cadeado para se
achar que está em SSL;
- As pessoas precisam de uma resposta negativa para achar que existe um
problema com a comunicação segura do browser (e algumas inclusive não dão a
mínima para a tela de "Warning").
- Quando a idéia é validar uma comunicação SSL, os navegadores estão
geralmente satisfeitos em autenticar e garantir que existe confiabilidade na
cadeia de assinatura dos certificados (pouco importa se a "Geotrust" não é a
CA escolhida pelo Banco XPTO para garantir a integridade e origem do DN/CN
www.bancoxpto.com.br).

O uso do "PKI" de nada ajudaria nos casos acima citados. Se falarmos em
verificação de "BasicConstraints" do lado da implementação (e.g: OpenSSL),
provavelmente vamos cobrir uma pequena parte do problema (ex:
$certificado->dn == $url->dn).

Existe um outro problema que você não citou mas é o uso de IDN para
confundir as pessoas. Eu posso usar caracteres unicode (se vc for para a
Latvia vai saber o que estou falando) para compor meu domínio e escolher
símbolos que parecem com letras do nosso alfabeto ocidental (o 'a' por
exemplo). Apesar do problema estar corrigido com o advento do "Punycode" (
http://en.wikipedia.org/wiki/Punycode) para domínios .com/.net/.org/.us, os
browsers vão renderizar estes elementos em um top level domain regional (no
caso do Marlin, ele pegou um .CN). Basta escolher caracteres que pareçam com
"?/" e outros que comumente aparecem em queries/URLs e o usuário é
facilmente enganado (veja o exemplo do gmail).

Enfim, o problema é mais embaixo. Talvez as pessoas precisem começar a se
preocupar com a forma de distribuir os links de forma segura para suas
aplicações SSL. Mesmo quando você não tem um virtualhost cujo acesso se faz
tanto em SSL quanto em HTTP, o problema dos ataques homográficos continua.

Resumindo: O usuário precisa deliberadamente acessar
https://minhaaplicacao.net/meulogon diretamente, sem passar pelo lado
"claro" para obter um redirecionamento. (E Deus queira que o seu DNS não
esteja envenenado -- veja a briga de DNSSEC do Kaminsky).

Abraços,
-- 
Thiago Zaninotti,Security+,CISSP-ISSAP,CISM
Sr. InfoSec Professional




2009/2/20 Nash Leon <nashleon at yahoo.com.br>

>
> Como vai, pessoal?
>
> Voces devem estar acompanhando as discussões sobre os truques de
> man-in-the-middle contra SSL divulgados na BlackHat:
>
>
> https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
>
> Esse é mais um caso que demonstra a necessidade de se pensar em segurança
> em profundidade, levando novamente a questionarmos se é seguro deixar
> toda a segurança dos dados sensíveis nas mãos da infraestrura, nesse caso
> SSL.
>
> Percebam claramente que se uma aplicação implementar PKI, ela própria
> (via javascript,via applet java, etc), esses problemas não seriam tão
> facilmente explorados. Exigiria um skill e uma dedicação maior do atacante
> do que simplesmente empurrar um proxy num ataque de MITM forçando http ao
> invés de https.
>
> Os dados transitando em HTTP seriam também criptografados. A princípio,
> um atacante no meio do caminho não conseguiria capturar senhas, hashes
> estáticos e etc... apenas dados cifrados.
>
> Obviamente, que o uso de PKI direto na aplicação não resolveria todos
> os problemas de MITM, no entanto, se usado de forma inteligente,
> eliminaria qualquer ataque genérico de captura de dados como os
> citados nessa palestra.
>
> Acho que já está na hora de se discutir medidas mais seguras para
> as aplicações que não dependam da infra-estrutura, como nesse caso
> do SSL. Outros ataques de SSL devem se tornar públicos em breve,
> logo seria sábio a implementação de contra-medidas para atenuar os
> problemas que esse recurso de infra-estrutura irá causar
> na segurança da aplicação.
>
>
> Um cordial abraço,
>
> Glaudson Ocampos aka Nash Leon.
>
>
>      Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
> _______________________________________________
> Owasp-brazilian mailing list
> Owasp-brazilian at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-brazilian/attachments/20090220/51426600/attachment.html 


More information about the Owasp-brazilian mailing list