Real World Exploit for Bleichenbachers Attack on SSL from Crypto'06 working
Hi I had an idea very similar to the one Peter Gutmann had this morning. I managed to write a real world exploit which takes as input: * an CA-Certificate using 1024 Bit RSA and Exponent 3 (ca-in) * a Public Key, using an algorithm and size of your choice (key-in) and generats an CA-Certificate signed by ca-in, using public key key-in. At least 3 major webbrowsers on the marked are shipped by default with CA certificates, which have signed other intermediate CAs which use rsa1024 with exponent 3, in their current version. With this exploit, you can now sign arbitary server certificates for any website of your choice, which are accepted by all 3 webbrowsers without any kind of ssl-warning-message. I used the following method: I first generated a certificate, with BasicConstraints set to True, Public Key set to one of my keys, and Issuer to the DN of a CA using 1024 Bit RSA with Exponent 3. I used usual values for all the other fields. When I signed a Certificate I shiftet all my data to the left. I had 46 bytes of fixed valued (this can perhaps be reduced to 45 bytes, I have not checked yet, but even with 46, this attack works). They had the form 00 01 FF FF FF FF FF FF FF FF ASN1DataWithHash. This gives me 82 bytes I can fill with arbitary values (at least, if the implementations skipps some part of the asn1-data, I can choose some bytes there too). If you now set all the bytes right of your ASN1DataWithHash to 00, and interpret that as a number n, and compute: y = (ceil(cubeRoot(n)))^3 Where ceil means rounding to the next bigger natural number and cubeRoot computes the third Root in R. y will be a perfect cube and have the form: 00 01 FF FF FF FF FF FF FF FF ASN1DataWithHash' Garbage and ASN1DataWithHash' looks quite similar to your original ASN1DataWithHash, with perhaps 2-3 rightmost bytes changed. These bytes are part of the certificate hash value. This signature is useless, because every certificate has a fixed hash value. But you don't need to sign a fixed certificate. So i started adding some seconds to the notAfter value of the certificate and computed the hash again. I brute forced until I had a certificate where the computation of y did not alter any bytes of the ASN1DataWithHash. I had to try 275992 different values which took 2-3 minutes on my 1.7 GHz Pentium using an unoptimized java-implementation. I used this cert and my key to sign an end-entity certificate which I used to set up an webserver. I have to check some legal aspects before publishing the names of the browser which accepted this certificate and the name of the ca-certificates with exponent 3 I used in some hours, if nobody tells me not to do that. Depending on the advice I get, I will release the sourcecode of the exploit too. Thanks go to Alexander May and Ralf-Philipp Weinmann who helped me. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: Real World Exploit for Bleichenbachers Attack on SSL fromCrypto'06 working
Am Donnerstag, den 14.09.2006, 22:23 -0700 schrieb Tolga Acar: > You need to have one zero octet after bunch of FFs and before DER encoded > has blob in order to have a proper PKCS#1v1.5 signature encoding. > > Based on what you say below, "I used this cert and my key to sign an > end-entity certificate which I used to set up an webserver", it appears that > implementations you used don't check for this one zero octet, either. Yes, I have, I counted this to the ASN1DataWithHash part. I did not theck if it works without. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Real World Exploit for Bleichenbachers Attack on SSL from Crypto'06 working
Am Freitag, den 15.09.2006, 00:40 +0200 schrieb Erik Tews: > I have to check some legal aspects before publishing the names of the > browser which accepted this certificate and the name of the > ca-certificates with exponent 3 I used in some hours, if nobody tells me > not to do that. Depending on the advice I get, I will release the > sourcecode of the exploit too. OK, so here are the names of the browsers I tried: * Mozilla Firefox Version 1.5.0.6 and all previous versions including all old versions like netscape 4 seem to be affected. They don't display any kind of warning message at all, nor has the user the possibility to see something if he looks at the ssl connection properties. Firefox 1.5.0.7 was released yesterday and contains a fix. Netscape is not longer supported and netscape phoned me and suggested switching to another browser like seamonkey. * Opera 9.01 is affected. Opera is going to release 9.02 very very soon which will contain a bugfix. Opera users are automatically notified once a week when a new version is available. * Konqueror from the kde project uses openssl for ssl-connections. They are affected, but after having patched openssl, konqueror is fixed too. The following certs could be used in the attack: Starfieldtech has issued the following certificate: Issuer: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Cla ss 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@ valicert.com Subject: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., OU=http://www.starfieldtech.com/repository, CN=Starfield Secure Certification A uthority/[EMAIL PROTECTED] X509v3 Basic Constraints: CA:TRUE Serial Number: 260 (0x104) RSA Public Key: (1024 bit) Exponent: 3 (0x3) This can be used to create an CA certificate which seems to be signed by Starfieldtech There is another certificate by default in a lot of browsers: Issuer: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority Subject: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority RSA Public Key: (1024 bit) Exponent: 3 (0x3) X509v3 Basic Constraints: CA:TRUE Serial Number: 927650371 (0x374ad243) This one can be used too. Depending on the browser you use, there are some other certificates. Here is a list of all Subject DN of all CA certs we have found so far, which seems to be affected: * C=US, O=Digital Signature Trust Co., OU=DSTCA E1 * C=US, O=Digital Signature Trust Co., OU=DSTCA E2 * C=US, O=Entrust.net, OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limits liab., OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Client Certification Authority * C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority * C=EU, O=AC Camerfirma SA CIF A82743287, OU=http://www.chambersign.org, CN=Chambers of Commerce Root * C=EU, O=AC Camerfirma SA CIF A82743287, OU=http://www.chambersign.org, CN=Global Chambersign Root * C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority * C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority I decided to keep the actual implementation of the exploit secret for the moment. We put up a little webpage summarizing some postings related to the attack. This is written primary for end users who want to secure their browsers, but contains links to some intresting mailing list posts too. http://www.cdc.informatik.tu-darmstadt.de/securebrowser/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Exponent 3 damage spreads...
Am Montag, den 25.09.2006, 01:28 +0200 schrieb Philipp Gühring: > Hi, > > We have been researching, which vendors were generating Exponent 3 keys, and > we found the following until now: > > * Cisco 3000 VPN Concentrator > * CSP11 > * AN.ON / JAP (they told me they would change it on the next day) > (perhaps more to come) > > My current estimate is that 0.26% of the certificates in the wild have > Exponents <=17 I did a little survey one month ago for my bsc. thesis. I found out, that round about 1.19% of all https-server-certs use an exponent <= 17. I did choose round about 32,000 random webservers for this survey. What is intresting is what happens when it comes to imap-ssl. Here, only 0.1% of all servers use a server-cert with exponent <= 17. Imap-ssl users seem to be the better ssl-users, tls 1.0 is more widespread there, small rsa-modulus-sizes are more seldom, and ssl 2.0 is not so common there too. I will publish some more details later. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: TPM & disk crypto
Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: > Anyone have any information on how to develop TPM software? Yes, thats easy. We created a java library for the tpm chip. You can get it at http://tpm4java.datenzone.de/ Using this lib, you need less than 10 lines of java-code for doing some simple tpm operations. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: TPM & disk crypto
Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.: > On 10/2/06, Erik Tews <[EMAIL PROTECTED]> wrote: > > Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: > > > Anyone have any information on how to develop TPM software? > > http://tpm4java.datenzone.de/ > > Using this lib, you need less than 10 lines of java-code for doing some > > simple tpm operations. > > Interesting, but not what I meant. I want to program the chip to verify > that the BIOS, boot sector, root partition conform to *my* specification. > > I don't want binary-only hardware-enforced vendor lock-in, that went > out of fashion > with the mainframe and proprietary data[base] formats. You can do that (at least in theory). First, you need a system with tpm. I assume you are running linux. Then you boot your linux-kernel and an initrd using the trusted grub bootloader. Your bios will report the checksum of trusted grub to the tpm before giving control to your grub bootloader. Your grub bootloader will then report the checksum of your kernel and your initrd to the tpm before giving control to them. After your kernel has bootet and given control to your initrd, you can checksum your root-partition (or do something similar, like just checking if there are setuid binarys or checksum just your shadow-file) and report that to the tpm using a little java-application and tpm4java. Later, you can remotely query your system and get a report what has been bootet on your system. You can do this query using a java application and tpm4java. All applications like linux, grub, tpm4java are open source (you will need a java-vm, there are some open source vms, you should be able to use with tpm4java). The only thing which is not open source is the bios and the exact hardware design of your tpm chip in your pc. One thing you should know is, that a tpm can never find out, if a software meets some specifications, like does not have an buffer overflow or does not execute code from the network or so. You just can check is has not been altered. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: TPM & disk crypto
Am Freitag, den 06.10.2006, 17:29 -0400 schrieb Thor Lancelot Simon: > On Thu, Oct 05, 2006 at 11:51:49PM +0200, Erik Tews wrote: > > Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.: > > > On 10/2/06, Erik Tews <[EMAIL PROTECTED]> wrote: > > > > Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: > > > > > Anyone have any information on how to develop TPM software? > > > > http://tpm4java.datenzone.de/ > > > > Using this lib, you need less than 10 lines of java-code for doing some > > > > simple tpm operations. > > > > > > Interesting, but not what I meant. I want to program the chip to verify > > > that the BIOS, boot sector, root partition conform to *my* specification. > > > > > You can do that (at least in theory). > > > > First, you need a system with tpm. I assume you are running linux. Then > > you boot your linux-kernel and an initrd using the trusted grub > > bootloader. Your bios will report the checksum of trusted grub to the > > tpm before giving control to your grub bootloader. > > And the TPM knows that your BIOS has not lied about the checksum of grub > how? The TPM does not know that the BIOS did not lie about the checksum of grub or any other bios component. What you do is, you trust your TPM and your BIOS that they never lie to you, because they are certified by the manufature of the system and the tpm. (This is why it is called trusted computing) So if you don't trust your hardware and your manufactor, trusted computing is absolutely worthless for you. But if you trust a manufactor, the manufactor trusts the tpms he has build and embedded in some systems, and you don't trust a user that he did not boot a modified version of your operating system, you can use these components to find out if the user is lieing. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: TPM & disk crypto
Am Donnerstag, den 12.10.2006, 14:31 -0400 schrieb Ivan Krstić: > Kuehn, Ulrich wrote: > > Who is "we"? In the case of my own system I payed for (so speaking > > for myself) I would like to have such a mechanism to have the system > > prove to me before login that it is not tampered with. The TCG > > approach does not provide this. > > What does "prove" mean here? Does having a hash of the system state for > visual inspection before boot do it? The problem is, just displaying anything like a hash value won't help. You will need a second device to do a RPA. This device could be a much smaller one, at least in theory, something like a mobile phone or an pda would be sufficient. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: A web site that believes in crypto
Am Mittwoch, den 10.01.2007, 18:31 -0500 schrieb Steven M. Bellovin: > I just stumbled on a web site that strongly believes in crypto -- > *everything* on the site is protected by https. If you go there via > http, you receive a Redirect. The site? www.cia.gov: http://www.trustedcomputing.org/ does this for some time now. A lot of years ago, http://www.ccc.de/ (german hacker club, something like 2600 in the usa) switched to https only, but switched back to http later. This happened when netscape 4.x was the most common browser and a lot of users had problems with https. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: SSL Server needs access to raw HTTP data (Request for adivce)
Am Samstag, den 13.01.2007, 19:03 -0800 schrieb Richard Powell: > I was hoping someone on this list could provide me with a link to a > tool > that would enable me to dump the raw HTTP data from a web request that > uses SSL/HTTPS. I have full access to the server, but not to the > client, and I want to know exactly/precisely what the client is > transmitting. I think http://www.rtfm.com/ssldump/ should do the job. But this only works in some configurations. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: OT: SSL certificate chain problems
Am Dienstag, den 23.01.2007, 20:47 -0600 schrieb Travis H.: > Verify return code: 21 (unable to verify the first certificate) > --- > DONE > > I can't seem to get that certificate chain to have any contents other > than what you see above, no matter what I do, and hence can't get rid > of the Verify return code: 21... does anyone have any advice on what > to do next? URLs or references to other mailing lists welcome. Did you try -CAfile, with this command you can give s_client a file with CAs you trust. If the Thawte Consulting certificate is in this file, you should have no problems with verifying. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: man in the middle, SSL
Am Freitag, den 02.02.2007, 16:15 -0500 schrieb James Muir: > > You can find more and download Odysseus here: > > > > http://www.bindshell.net/tools/odysseus > > It is my understanding that SSL is engineered to resist mitm attacks, > so > I am suspicious of these claims. I wondered if someone more familiar > with SSL/TLS could comment. > > Isn't in the case that the application doing SSL on the client should > detect what this proxy server is doing and display a warning to the > user? A unmodified SSL/TLS client should display a warning message, that the server certificate is invalid or something similar. So this is not a valid man in the middle attack agains SSL/TLS. Perhaps you are going to use this tool for debugging purpose. If so, you can perhaps generate a certificat with a private key. The certificate is installed in your SSL/TLS client as a trusted certification authority and the certificate and the private key is then used by odysseus to make this warning messages go away. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: AES128-CBC Question
Am Mittwoch, den 18.04.2007, 23:29 -0700 schrieb Aram Perez: > Hi Folks, > > Is there any danger in using AES128-CBC with a fixed IV of all zeros? This is > being proposed for a standard "because that's how SD cards implemented it". That depends. What would be a valid attack on a SD-card? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: How the Greek cellphone network was tapped.
Am Freitag, den 06.07.2007, 02:52 -0400 schrieb silvio: > > http://www.spectrum.ieee.org/print/5280 > > So what are the options these days (the article even mentions > end-to-end > encryption to make such an attack far more difficult)? > Every "crypto-phone" offering seems to go stale and disappear after a > while...perhaps related to the fact of being ridiculously expensive. > Aren't run-of-the-mill cellphones these days powerful enough to use > available software like OpenSSL to encrypt voice/datastreams? > Again...what are the options for end-to-end cell encryption right now? For example, I owne an Nokia E70 smartphone running symbian. There is an application called fring, which is basically skype for symbian which runs on the E70. Fring offers VoIP calls over skype with your mobile phone. The data is send over the Cellular network (UMTS or so) or Wireless LAN, which is supported by some phones too. I don't know how much encryption Fring does (and I don't want to speculate how secure it is here), but it shows, that you can do VoIP on usual high end consumers hardware. So writing an application, which does basically the same as fring and uses extra cryptography should be possible. I have written some java code for the E70, and I know that it can do AES, RSA and DH in a reasonable time, even if all computations are done in Java. But this is all just about end-to-end encryption, you could still try to backdoor the phones firmware, or bug the phone itself (in hardware). Additionally, you need some kind of public key infrastructure, if you want to call arbitrary people securely. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: debunking snake oil
Am Donnerstag, den 30.08.2007, 20:43 -0500 schrieb travis [EMAIL PROTECTED]: > If you have a break of some scheme you wish to contribute, please > do forward me a URL and I'll link to it. Sorry, german, but definitely worth reading: http://www.kryptochef.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
