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

Nuno Loureiro nuno at sig9.net
Fri Jul 23 11:49:52 EDT 2010


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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-portuguese/attachments/20100723/6c7b172d/attachment-0001.html 


More information about the Owasp-portuguese mailing list