[Owasp-delhi] Thanks...

Gunwant Singh gunwant.s at gmail.com
Fri Jan 16 13:08:31 EST 2009


Pranav,

Thank you very much for the wealth of information :)

Regards.

On Fri, Jan 16, 2009 at 5:29 PM, Pranav Joshi <pranav.joshi at kriss.in> wrote:
Hey Gunwant,

Apologies for the delay..

I had to sift through a lot of GHTQ material to gather em.

MD5Coll - http://www.stachliu.com/md5coll.c
StripWire - http://www.doxpara.com/stripwire-1.1.tar.gz
ConFoo.pl <http://www.doxpara.com/stripwire-1.1.tar.gzConFoo.pl> -
http://www.doxpara.com/research/md5/confoo.pl
MD5 Deep - http://md5deep.sourceforge.net/


All,

Since I see many people here on the mailing list who seem deeply
interested in the topic I'm sharing some notes I've compiled.

------------------------------
>
> -------------------------------------------------------------
>
> Around August of 2004 certain Researchers in China Published Research
> documents that they could hash collisions within MD5.. This was not very
> meaningful threat as they concentrated on creating two random blobs of
> data with colliding hashes. The researchers did not publish the details of
> their algorithm instead they published 'X' and 'Y' samples with colliding
> MD5 hashes for proving their theory.
>
> http://eprint.iacr.org/2004/199.pdf
>
> In 2005 Dan Kaminsky created a tool called 'stripwire'which could create
> certain perl scripts with colliding hashes,
>
> In early 2006 some guys figured out that they could do the same to
> PostScript documents.
>
> Some time later, Dan Kaminsky came back with 'ConFoo' showing that he
> could do it with web pages.
>
> 'MD5coll' is a tool you can use to create your very own 'X' and 'Y' with
> colliding hashes.
>
> Researchers have known for a very long time that if 'X' is not equal to
> 'Y' but share a hash collision then you can append 'Q' to both 'X' and 'Y'
> and the hash collision will be preserved provided X and Y are increments
> of 64 bytes in length.
>
> If one uses this information very cleverly some very interesting things
> can be made possible. Suppose we have evil code 'P' which opens up a
> backdoor, here we take 'X' which has a collission with 'Y', We take SHA-1
> of 'X' (this is not an attack against SHA-1 (we're using it simply to
> shrink it down to be able to use it as a key) to use it as an AES key to
> encrypt 'P' the evil code thus getting 'Q' (Which is the encrypted evil
> code 'P', encrypted using a key derived from 'X' which happens to have a
> hash collision with 'Y').
>
> Now we take the encrypted evil code 'Q' and append it to 'X and 'Y'...
>
> Dan Kaminsky calls the derived 'X'+'Q' and 'Y'+'Q' as 'Fire' and 'Ice'.
> Ice is completely innocuous blob of bits followed by something which is
> encrypted, which really cant fo anything.
> Fire, however is evil..
>
> To make fire work you need to do the following
>
> 1. Slice off the initial 'X' from 'X'+'Q'
> 2. Generate SHA-1 of 'X'.
> 3. Use the derived SHA-1 as the AES key to decrypt 'Q' and get 'P'
> 4. Execute 'P'.
>
> This functionality is incorporated into StripWire and is called as 'Evil
> Execution Harness'..
> Problem: Fire has the potential to do something evil but Fire can't do
> much without Ice as it is dependent on 'X'..
>
> Research suggests that MD5 collisions can be preserved by pre-pending evil
> data:
> http://www.doxpara.com/research/md5/232-md5-considered-harmful-slides.pdf
>
> If I could do pre-pending, then I could put the 'Evil execution Harness'
> upfront which upon execution would start cryptographic function and
> depending upon the result of the cryptographic function would start
> branching execution either launching benign code or malicious one.
>
> ConFoo can demonstrate this very nicely, it works by taking two separate
> web pages, convolving them together, adding the appropriate 'X' and 'Y',
> adding a javascript to implement the 'execution harness' and creating
> pages t1 and t2 with MD5 collisions.
>
> Bye,
> Pranav
>
> > Pranav,
> >
> > Thanks for the information. Would you mind sharing the name of the tools
> > for
> > MD5 cracking? I'll be thankful.
> >
> > All,
> >
> > I was curious about a question on Sessions which I wanted to ask you all
> > since some time back but did not get any chance due to some reasons. I
> > have
> > asked this question on some forums as well, so excuse me if you have
> > already
> > heard of this.
> >
> > As we all know salted MD5 hashing protects the authentication credentials
> > rightly from eavesdropping on the network. SSL does the same thing.
> > However,
> > in some scenarios SSL might not be feasible. For example, causing heavy
> > load
> > on the server or may be some applications don't support it, etc.
> >
> > Apparently we need to protect 2 crucial things in the HTTP header from
> the
> > person sniffing the network traffic. "Authentication Credentials and
> > Session
> > Credentials"
> >
> > We can protect the authentication credentials using salted MD5 hashing or
> > by
> > using SSL. In case SSL implementation is not feasible, salted MD5 will
> > still
> > protect the authentication credentials but not the Session Credentials.
> In
> > order to protect the Session credentials (Session ID, tokens, cookies,
> > etc)
> > on a non-SSL channel what measures can be taken?
> >
> > Thoughts?
> >
> > -Gunwant
> >
> >
> >
> > On Fri, Jan 9, 2009 at 1:34 PM, Pranav Joshi <pranav.joshi at kriss.in>
> > wrote:
> >
> >> Hi Gunwant,
> >>
> >> > Fyi, even SHA-1 is susceptible to collision attacks. Practically even
> >> if
> >> MD5
> >> > or SHA-1 are broken, this vulnerability still can't be readily used to
> >> exploit the certificate genuinity uptil 'Now'
> >>
> >> Absolutely, I completely agree with your point that SHA-1 is susceptible
> >> to collisions.
> >>
> >> The only difference between them is that colliding SHA-1 still a
> >> mathematical probability of 2^63 computational cycles, So far nobody has
> >> been able show a working collision for SHA-1.
> >>
> >> > IMHO I am sure this will be exploited with a solid rationale in the
> >> near
> >> future.
> >>
> >> Absolutely.. It's just a matter of biding time till someone figures out
> >> a
> >> way, IMHO, PS3's (Cell Based Systems) & GPUs are doing a remarkably
> >> praiseworthy job of shrinking the computational time-line.
> >>
> >> Having said that, the point I wanted to make regarding MD5 specifically
> >> was that POCs and tools for attacking MD5 have been available for close
> >> to
> >> 3 years and these attacks have been a part of GHTQ curriculum. but
> >> nothing
> >> was serious as this for MD5 uptil 'Now'... the metaphorical "final nail
> >> in
> >> the coffin".
> >>
> >> The best bet as of now is to rely on multiple hashing algorithms for
> >> critical systems; so even if one collision is generated other hashes
> >> would
> >> fail to match.
> >>
> >> NOTE: I can't recollect the names of those tools mentioned here but if
> >> someone is interested in knowing them lemme know, I'd be glad to
> >> re-lookup
> >> the same.
> >>
> >> Warm Regards,
> >> Pranav Joshi
> >> Consultant - Information Security [CISA/GHTQ/GWAS/Security+]
> >> Email: pranav.joshi at kriss.in
> >> Phone: +91-9958967766
> >>
> >> > Hi,
> >> >
> >> > Thanks for sharing the information. Just wanted to add some more to
> >> this.
> >> >
> >> > As you said:
> >> > "Since, MD5 is also used in signing certificates the browsers will
> >> have
> >> no
> >> > way of telling the difference between a genuine and a rogue website
> >> unless
> >> > other hashing algorithms like SHA-1 are also used."
> >> >
> >> > Fyi, even SHA-1 is susceptible to collision attacks. Practically even
> >> if
> >> MD5
> >> > or SHA-1 are broken, this vulnerability still can't be readily used to
> >> exploit the certificate genuinity uptil 'Now'. Having said that I did
> >> not
> >> > mean that it can't be exploited at all thereby further exposing
> >> insecurity
> >> > on the internet. What I am saying is until some more research is done
> >> on
> >> how
> >> > to exploit this in relevance to the certificates, we can unwind and
> >> count
> >> > on
> >> > atleast the certificates for now.
> >> >
> >> > Some guys have come up with a PoC for the same, however not at a very
> >> reasonable level.
> >> > May be you want to have a look at these:
> >> >
> >> > http://www.cryptography.com/cnews/hash.html<
> >>
> https://houmail.halliburton.com/OWA/redir.aspx?C=52ed613179914f85a1b0ae5a68761f71&URL=http%3a%2f%2fwww.cryptography.com%2fcnews%2fhash.html
> >> >
> >> http://www.securityfocus.com/columnists/488
> >> >
> >> > IMHO I am sure this will be exploited with a solid rationale in the
> >> near
> >> future.
> >> >
> >> > Thanks,
> >> > -Gunwant Singh
> >> >
> >> > On Fri, Jan 2, 2009 at 1:46 PM, Pranav Joshi <pranav.joshi at kriss.in>
> >> wrote:
> >> >
> >> >> Hello Everyone.
> >> >> It's been quite a while since security issues with MD5 algorithm
> >> started
> >> >> cropping up regarding reproducible hash collisions (a.k.a Birthday
> >> Attack), this one ups the ante by driving the final nail in it's
> >> coffin.
> >> >> Since, MD5 is also used in signing certificates the browsers will
> >> have
> >> no
> >> >> way of telling the difference between a genuine and a rogue website
> >> unless
> >> >> other hashing algorithms like SHA-1 are also used.
> >> >> http://blogs.computerworld.com/md5_ca_hack_and_the_ps3
> >> >> Warm Regards,
> >> >> Pranav Joshi
> >> >> Consultant - Information Security [CISA/GHTQ/GWAS/Security+]
> >> >> Email: pranav.joshi at kriss.in
> >> >> Phone: +91-9958967766
> >> >> _______________________________________________
> >> >> Owasp-delhi mailing list
> >> >> Owasp-delhi at lists.owasp.org
> >> >> https://lists.owasp.org/mailman/listinfo/owasp-delhi
> >> >
> >> >
> >> >
> >> > --
> >> > Gunwant Singh
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Gunwant Singh
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090116/81899248/attachment-0001.html 


More information about the Owasp-delhi mailing list