[Owasp-portuguese] Fwd: A mighty fortress is our PKI

Bruno Morisson morisson at genhex.org
Fri Jul 23 12:01:53 EDT 2010


2010/7/23 Nuno Loureiro <nuno at sig9.net>

> Viva,
>
> On Jul 23, 2010, at 11:53 , Jorge Pinto wrote:
>
> Bruno,
>
> Na realidade a parte de encriptação funciona e é útil, as minhas dúvidas
> são relativamente á questão da autenticação, que por estas e por outras é
> cada vez menos confiável.
>
>
> Concordo a 100%. Também me parece exagerado dizer que o SSL é irrelevante..
> Mesmo para o utilizador comum e com os problemas todos de autenticação, o
> SSL não deixa de oferecer um certo número de protecções contra um
> determinado número de ataques.
>
>
Certo, mas digo irrelevante porque estou plenamente convencido que o average
joe se está nas tintas para o cadeadozito. Aliás, basta ver alguma da
pesquisa do Moxie Marlinspike (nao tenho agora presente exactamente qual a
apresentação que tem esses dados, mas existe) em que ele testou fazer um
MITM retirando SSL dos sites (i.e., o user ia a https://www.banco.foo/ e
através de MITM redireccionava-o para http://www.banco.foo/, e o qual era
apenas um proxy controlado por ele) e a percentagem de sucesso (i.e. users
que utilizaram o site sem notar) era impressionante.

Ou seja, há um problema sério de educação dos utilizadores, o qual os certs
EV ajudam a minimizar pelas características visuais que aparecem no browser
(o aviso de SSL é bastante mais vísivel que o SSL normal, o que acho idiota,
mas isso é outra discussão), mas por outro lado a emissão de certificados é
uma bandalheira, como se vê.

Resumindo, e pegando na questão da cifragem vs autenticação, para
autenticação cada vez mais se comprova que deixam muito a desejar, em
relação a cifragem, se o utilizador não nota, e é vulneravel a MITM, afinal
qual é a utilidade ? Acho que continuamos a "confiar" no SSL apenas porque
achamos que um ataque real é pouco provável.

Para provar o meu ponto: se fizerem um MITM a um site de um banco nas vossas
organizações (com downgrade de SSL para clear), qual acham q vai ser a taxa
de sucesso do ataque ?


--
Bruno Morisson <morisson at genhex.org>



> Carlos,
>
> É verdade que pode ser complicado encontrar uma entidade que reunisse os
> níveis de segurança necessários para pudesse centralizar estas emissões,
> provavelmente uma departamento qualquer da ONU ou coisa parecida. No entanto
> quando eu olho para as trusted root CA's que tenho no meu sistema (OSX
> 10.6.4) verifico que confio em todos os certificados emitidos por uma
> qualquer entidade certificadora chinesa (e eu acho que existe uma delegação
> de uma root CA para a Coreia do Norte). Eu não confio em certificados
> passados por um pais que tem o historial que tem em termos de ataques á
> infra-estrutura de alguns países. Achas que se as pessoas soubessem que
> estes senhores podem emitir um certificado em nome de qualquer domínio a tal
> confiança em PKI's se manteria?
>
>
> O problema das root CAs e dos browsers é de facto um problema. É provável
> que existam organizações de crime organizado que tenham uma CA com
> certificado no browser. No IE, se não estou em erro, é uma questão de
> dinheiro. E noutros browsers não deve ser muito diferente, pelo menos não
> deve ser muito difícil (basta olhar para a lista de certificados que já vem
> incluído).
>
> Há outras questões como a que é referida no email. Para algumas root CAs,
> assinar certificados é uma bandalheira total. Há uns meses atrás vi nas
> notícias um researcher que conseguiu um certificado assinado para o yahoo
> (entre outros) pq criou uma conta ssladmin at yahoo.com e convenceu a CA que
> era do yahoo dessa forma.
>
> Esta questão que é referida no email só reforça a ideia de bandalheira a
> que me refiro, ou a falta de politicas consertadas bem definidas para
> assinar certificados. O autor do mail original diz no entanto que um simples
> XSS serviria para explorar o problema de um certificado para esses domínios
> todos, mas ou esta-me a escapar qualquer coisa ou não é bem assim.
>
> Claro que se a máquina for comprometida e o certificado for roubado, tudo
> bem. Um ataque qualquer de MiTM a mozilla.com (por exemplo) terá sucesso
> pois o certificado apresentado é valido. Mas um XSS não me parece
> suficiente. Peguei num dos hosts que está no certificado -
> www-cdn.pushplay.com - e verifiquei que fazendo um request a mozilla.com para
> o mesmo IP ele responde com a pagina do mozilla.com, i.e., o mozilla.com tem
> um VH proprio que está alojado no mesmo IP do que o pushplay.com.
>
> Para se tirar partido de um XSS neste caso, teria que modificar a pagina
> de www-cdn.pushplay.com para se parecer com a do mozilla e fazer o que
> quiser com a pagina (e tirar partido do certificado assinado para
> mozilla.com para mostrar ao user que de facto sou mozilla.com). No
> entanto, o ataque de MiTM, ao redireccionar para www-cdn.pushplay.com,
> enviaria o Host www.mozilla.com no request e no server deles há um VH que
> responde a esse host. A única forma que vejo para tirar partido do
> certificado era esse IP não ter um VH para mozilla.com e o default VH ser
> o www-cdn.pushplay.com, i.e., se fizer um request por mozilla.com para
> esse IP teria como resposta o www-cdn.pushplay.com (que se tivesse um XSS,
> fazia o que bem me apetecesse). É dificil de explicar por escrito, mas se
> pensarem um pouco percebem o que quero dizer. Agora a pergunta é: está-me a
> escapar alguma coisa ou é de facto exagerado dizer que um simples XSS é
> suficiente?
>
> Cumprimentos,
> Nuno
>
>
> On Fri, Jul 23, 2010 at 10:56 AM, Bruno Morisson <morisson at genhex.org>wrote:
>
>> Viva Jorge,
>>
>> é de facto absurdo.
>>
>> É engraçado perceber a razão... esse certificado está num provider de CDN,
>> ou seja, não se quiseram dar ao trabalho de ter diferentes instâncias do
>> webserver com ssl de forma a suportar todos os clientes...assim, one
>> size(cert) fits all :)
>>
>> É por estas e por outras que continuo a dizer q o SSL é irrelevante...
>>
>> --
>> Bruno Morisson <morisson at genhex.org>
>>
>>
>> On Fri, Jul 23, 2010 at 10:16, Jorge Pinto <jorge.pinto at gmail.com> wrote:
>>
>>> Boas,
>>>
>>> Apesar de não estar directamente ligado a segurança aplicacional a
>>> utilização de certificados nos sites é usada muita vezes (demasiadas) como
>>> um argumento que o site é "seguro". Este artigo que apareceu noutra mailing
>>> list é uma prova que este tipo de argumento é falso e só vem introduzir
>>> descrédito na forma como estes são emitidos. A minha opinião desde sempre é
>>> que a emissão de certificados digitais deveria ser feita por uma entidade
>>> supra-nacional e confiável, além de que o tipo particular de certificado
>>> referido no email não deveria sequer ser confiado.
>>>
>>> Comentários?
>>>
>>>
>>> -----Original Message-----
>>> From: owner-cryptography at metzdowd.com [mailto:
>>> owner-cryptography at metzdowd.com] On Behalf Of Peter Gutmann
>>> Sent: quinta-feira, 22 de Julho de 2010 8:48
>>> To: cryptography at metzdowd.com
>>> Subject: A mighty fortress is our PKI
>>>
>>> Readers are cordially invited to go to https://edgecastcdn.net and have
>>> a look
>>> at the subjectAltName extension in the certificate that it presents.  An
>>> extract is shown at the end of this message, this is just one example of
>>> many
>>> like it.  I'm not picking on Edgecast specifically, I just used this one
>>> because it's the most Sybilly certificate I've ever seen.  You'll find
>>> that
>>> this one Sybil certificate, among its hundred-and-seven hostnames,
>>> includes
>>> everything from Mozilla, Experian, the French postal service, TRUSTe, and
>>> the
>>> Information Systems Audit and Control Association (ISACA), through to
>>> Chainlove, Bonktown, and Dickies Girl (which aren't nearly as titillating
>>> as
>>> they sound, and QuiteSFW).  Still, who needs to compromise a CA when you
>>> have
>>> these things floating around on multihomed hosts and CDNs.
>>>
>>> Ian Grigg pointed out that this is also an EV certificate, I'm guessing
>>> that
>>> CDNs and multihomed hosts run into the same system-high problem that
>>> dogged
>>> MLS systems in the 1980s, they have to use the certificate at the highest
>>> level of any of the constituent domains.  So if you compromise (say)
>>> inpath-static.iseatz.com (which consists of a page that says "We're
>>> sorry, but
>>> something went wrong") or images.vrbo.com ("Directory Listing Denied")
>>> then
>>> you have an EV-validated site.  So the overall EV security becomes that
>>> of the
>>> least secure co-hosted domain.
>>>
>>> I've tried connecting to the above site with HTTPS and get a normal
>>> non-EV
>>> Sybil certificate even though it's rooted in an EV CA... well,
>>> pseudo-rooted,
>>> the "root" is then signed by an old Entrust certificate, and the
>>> certificate
>>> itself is another multi-domain one, for Delta, Amtrak, Air France, KLM,
>>> Alaska
>>> Air, and others.  I wonder if they have some context-specific way to
>>> override
>>> EV on a per-site basis when it's used with Sybil certificates?  At the
>>> moment
>>> it's rather hard to test because depending on where you are in the world
>>> you
>>> get different views of servers and certificates (for example when I
>>> connect to
>>> ISACA, which is an EV site, I get a standard non-Sybil certificate that's
>>> only
>>> valid for ISACA), and finding a particular hostname in a Sybil
>>> certificate
>>> doesn't mean that you'll see that particular certificate when you connect
>>> to
>>> the server.
>>>
>>> (Again, not wanting to pick on ISACA here, but finding a security audit
>>> organisation sharing a certificate with Dickies Girl is kinda funny.
>>>  You'd
>>> think there'd be a security audit process to catch this :-).
>>>
>>> What a mess!  A single XSS/XSRF/XS* attack, or just a plain config
>>> problem,
>>> and the whole house of cards comes down.
>>>
>>> (For the TLS folks, SNI (a client-supplied Server Name Indication when it
>>>  connects) won't fix this because (a) it's not widely-enough supported
>>> yet and
>>>  (b) the server admin would have to buy 107 separate certificates to do
>>> the
>>>  job that's currently done by one Sybil certificate, and then repeat this
>>> for
>>>  every other Sybil certificate they use).
>>>
>>>  666 2633:         SEQUENCE {
>>>  670    3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
>>>  675 2624:           OCTET STRING, encapsulates {
>>>  679 2620:             SEQUENCE {
>>>  683   15:               [2] 'edgecastcdn.net'
>>>  700   18:               [2] 'ne.edgecastcdn.net'
>>>  720   21:               [2] 'minitab.fileburst.com'
>>>  743   30:               [2] 'cdn.montimbrenligne.laposte.fr'
>>>  775   27:               [2] 'zeroknowledge.fileburst.com'
>>>  804   23:               [2] 'images.goldstarbeta.com'
>>>  829   25:               [2] 'radialpoint.fileburst.com'
>>>  856   19:               [2] 'wac.edgecastcdn.net'
>>>  877   22:               [2] 'ne.wac.edgecastcdn.net'
>>>  901   19:               [2] 'images.goldstar.com'
>>>  922   15:               [2] 'images.vrbo.com'
>>>  939   12:               [2] 'cdn.vrbo.com'
>>>  953   18:               [2] 'content.truste.com'
>>>  973   13:               [2] 'e1.boxcdn.net'
>>>  988   13:               [2] 'e2.boxcdn.net'
>>> 1003   13:               [2] 'e3.boxcdn.net'
>>> 1018   25:               [2] 'privacy-policy.truste.com'
>>> 1045   13:               [2] 'www.sonos.com'
>>> 1060   19:               [2] 'www.dickiesgirl.com'
>>> 1081   26:               [2] 'static-cache.tp-global.net'
>>> 1109   29:               [2] 'images.homeawayrealestate.com'
>>> 1140   14:               [2] 'cdn.verint.com'
>>> 1156   13:               [2] 'swf.mixpo.com'
>>> 1171   21:               [2] 'cdn.traceregister.com'
>>> 1194   14:               [2] 's.tmocache.com'
>>> 1210   17:               [2] 's.my.tmocache.com'
>>> 1229   23:               [2] 'ne1.wpc.edgecastcdn.net'
>>> 1254   23:               [2] 'gp1.wpc.edgecastcdn.net'
>>> 1279   23:               [2] 'gs1.wpc.edgecastcdn.net'
>>> 1304   23:               [2] 'ne1.wac.edgecastcdn.net'
>>> 1329   23:               [2] 'gp1.wac.edgecastcdn.net'
>>> 1354   23:               [2] 'gs1.wac.edgecastcdn.net'
>>> 1379   24:               [2] 'c1.socialcastcontent.com'
>>> 1405   21:               [2] 'www.steepandcheap.com'
>>> 1428   22:               [2] 'www.whiskeymilitia.com'
>>> 1452   17:               [2] 'www.chainlove.com'
>>> 1471   16:               [2] 'www.tramdock.com'
>>> 1489   16:               [2] 'www.bonktown.com'
>>> 1507   16:               [2] 'www.brociety.com'
>>> 1525   15:               [2] 'www.mozilla.com'
>>> 1542   22:               [2] 'resources.homeaway.com'
>>> 1566   21:               [2] 'ssl-cdn.sometrics.com'
>>> 1589   35:               [2] 'cache.vehicleassets.captivelead.com'
>>> 1626   17:               [2] 'static.woopra.com'
>>> 1645   20:               [2] 'images.cardstore.com'
>>> 1667   15:               [2] 'images.ink2.com'
>>> 1684   32:               [2] 'resources.homeawayrealestate.com'
>>> 1718   18:               [2] 'cdn1.adadvisor.net'
>>> 1738   24:               [2] 'www.pictureitpostage.com'
>>> 1764   26:               [2] 'images.vacationrentals.com'
>>> 1792   34:               [2] 'serviceportal.carestreamhealth.com'
>>> 1828   23:               [2] 'assets-secure.razoo.com'
>>> 1853   29:               [2] 'resources.vacationrentals.com'
>>> 1884   23:               [2] 'download.entraction.com'
>>> 1909   12:               [2] 'ec.pond5.com'
>>> 1923   21:               [2] 'images.esellerpro.com'
>>> 1946   15:               [2] 'use.typekit.com'
>>> [etc]
>>>
>>> Peter.
>>>
>>> ---------------------------------------------------------------------
>>> The Cryptography Mailing List
>>> Unsubscribe by sending "unsubscribe cryptography" to
>>> majordomo at metzdowd.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Owasp-portuguese mailing list
>>> Owasp-portuguese at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-portuguese
>>>
>>>
>>
> _______________________________________________
> Owasp-portuguese mailing list
> Owasp-portuguese at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-portuguese
>
>
>
> ----
> Nuno Loureiro <nuno at co.sapo.pt>
> Portugal Telecom - SAPO - http://www.sapo.pt/
>
> PGP fingerprint =3D 8A32 5174 E80C 2D40 9075 405E C107 6592 054A 4D05
> http://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=3D0xC1076592054A4D05=
>
>
> "Experience is what you get when you didn't get what you wanted." =97 =
> Randy Pausch (The Last Lecture)
>
>
> _______________________________________________
> Owasp-portuguese mailing list
> Owasp-portuguese at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-portuguese
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-portuguese/attachments/20100723/230efe1a/attachment-0001.html 


More information about the Owasp-portuguese mailing list