[ale] Skype on Linux
Michael H. Warfield
mhw at WittsEnd.com
Thu Jun 28 11:49:08 EDT 2012
I'm still catching up from having been in Malta all last week and then
some...
On Mon, 2012-06-18 at 16:15 -0400, Jim Kinney wrote:
> hash collision my A$$!
If I may make a humble request please... If you don't understand the
math or the processes involved, please check your tin foil hats at the
door.
Fact - MD5 is subject to collisions.
Fact - It takes a lot of horsepower and time.
Fact - MS was signing RDP certs with MD5 hashes.
Fact - MS has the certificate which was signed from the signing.
Fact - The security community has the fake certificate from Flame.
Fact - The two certificates have the same MD5 sum.
Fact - This can only be an artificially manufactured collision.
I don't know for sure but I also strongly suspect those certificates
will bear the various artifacts from the prerequisite manipulations such
as unusual nounces and non-functional attributes that were used to
manipulate the MD5 hashes.
The procedure for doing this is long and complicated. You can not take
any old blob and magically find another blob that has the same MD5 hash.
Instead, you artificially create two blobs with the same hash exploiting
certain weaknesses in MD5 and modifying both in ways that you change
their MD5 hashes until they match each other. Because of the way MD5
works, if you create two small blobs in this way, you can append
identical data to them and still maintain that collision.
In the case of certificates, you create your two certificate signing
requests (the innocuous one and the malicious one) and add additional
payload and padding data to each until you can converge onto a pair of
certs with the same hash when they become certificates. The innocuous
one (the one you will get signed) will have some odd cruft in the
nounces, padding, and payloads that do not trigger any warns and which
do not interfere with the real data in the X.509 structure. This you
get signed and you get a signature back signing with the MD5 has of your
innocuous cert. The malicious one will also have odd non-functional
cruft to make it match its twin. You then splice together your
malicious cert with the same hash and the signature and cert chain from
the cert you got signed. Voila, new cert that does what you want, with
the controlling attributes you desired, and not what the CA signed and
dictated. Takes a supercomputer or a whole raft of PS3s w/ GPUs to pull
it off but it is doable if you have the incentive and capability.
One complicating factor is that the CA is going to introduce information
to your cert such as serial numbers and X.509 extended attributes over
which you have no control. You have to predict what these will be so
you can manufacture your collision cert to match what the resulting
signed cert will be, not what your cert signature request is. It adds a
degree of difficulty to it but one which can be overcome if you have
enough information on the CA's procedures. My guess is that MS also was
cutting those certs with sequential serial numbers making that guess
relatively easy, but I have nothing to confirm that. If they made the
mistake of still using MD5, it's easy to see them making this mistake as
well. Most CAs now issue random serial numbers to prevent similar
attacks.
> On Mon, Jun 18, 2012 at 4:15 PM, Jim Kinney <jim.kinney at gmail.com> wrote:
>
> >
> > um, duh!
> >
> > What's the easiest way to get a working Microsoft software installation
> > certificate created for your new cool weapon? Ask an employee on the
> > payroll to sign your self-generated one.
This is blatantly false. Only an extremely small number of people
would / should have access to the actual keys and certificate signing
device. Any old employee would not have access or even know how to
begin. I don't even think my evil twin, Dave, over there could get
access to that service in the way you describe and he's one of their top
security people.
The certificate signing process itself would be / should be locked down
to only sign certificates with specific attributes. In fact, what
generally happens is that certain extended attributes are added to the
CSR (Certificate Signing Request) by the CA during the signing, which
you have no control over, limiting the scope and authority of that
certificate. So, even if said employee had access to the certificate
signing device, they still would not be able to generate a certificate
of this type (CA, Code Signing, etc) without altering the device or
entering into some sort of elevated authorization, bypassing the normal
controls. All this in the middle of normal business operations?
Right...
The real damning issue here is that if this had occurred, MS would know
who the guilty party was (you don't just sneak in and do something like
this - there are logs, you know) and you would get rapidly caught. The
perps would never take this route.
It was exactly as was claimed. A masterfully engineered exploitation of
the known MD5 weaknesses and cert procedural weaknesses resulting in a
manufactured hash collision in two certificates. Fact is, the easiest
way to accomplish this with the least chance of inadvertent discovery,
by the parties we suspect were involved and the resources they have, is
exactly what has been described. Anything else is either harder or
entails an elevated risk of discovery.
Regards,
Mike
> > On Mon, Jun 18, 2012 at 4:09 PM, Robert L. Harris <
> > robert.l.harris at gmail.com> wrote:
> >
> >>
> >>
> >> http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft
> >>
> >>
> >>
> >> On Fri, Apr 20, 2012 at 7:54 AM, JD <jdp at algoloma.com> wrote:
> >>
> >>> <snip>
> >>>
> >>> > Security concerns noted and appreciated. While I understand where
> >>> you're coming
> >>> > from, (and each user is different), I don't use Skype for sensitive
> >>> comms.
> >>> > Mainly business stuff between colleagues (and Skype is the standard
> >>> where I
> >>> > work, so I more or less have to use it for that), and talks to my
> >>> family about
> >>> > dull family stuff when I'm away from the house.
> >>> >
> >>> > Given that Skype's data goes through a (large?) number of different
> >>> routers,
> >>> > networks, and such before and after it hits Skype's/MS' servers,
> >>> worrying about
> >>> > MS specifically recording my calls is actually the least of any
> >>> worries I'd have
> >>> > (if I had any to begin with).
> >>> >
> >>> > In short, I'm less concerned about THAT attack vector on my calling
> >>> since I
> >>> > believe there are so many other easier ones*. And the NSA has all my
> >>> data already.
> >>> >
> >>>
> >>> <snip>
> >>>
> >>> Main points about using Skype now that MS owns them was concern over
> >>> good Linux
> >>> platform support. In my use of SisToSip, I learned that most businesses
> >>> using it
> >>> * setup skype on Linux servers
> >>> * used an old, now unavailable, version of Skype for the best sound and
> >>> stability - v2.0.0.72 (I believe, but this is from memory)
> >>> * were extremely concerned that MS would introduce incompatibilities so
> >>> their 3+
> >>> yr old version that doesn't crash and doesn't need to be rebooted
> >>> weekly/daily
> >>> no longer worked
> >>>
> >>> In my months of using it inside a VM, I ended up having to automatically
> >>> restart
> >>> skype daily so it didn't crash and inbound calls would ring. I also had
> >>> it setup
> >>> to send and receive normal POTS telephone calls. Picking up any regular
> >>> handset
> >>> in my home and using the dialpad to make calls worked ... once I started
> >>> the
> >>> daily reboot and if there wasn't a Skype system-wide outage. Early on it
> >>> was
> >>> often frustrating when the first inbound/outbound call of a day failed
> >>> until I
> >>> killed Skype on the server and restarted it.
> >>>
> >>> I haven't used Skype much the last year, so perhaps it is better?
> >>>
> >>> As to whether MS can or will be able to record skype calls ... if they
> >>> have a
> >>> court order and I'm inside the USA, then I don't have any issue. Of
> >>> course, I
> >>> have an expectation of privacy in any form of communication, especially
> >>> voice,
> >>> regardless of the actual technology employed.
> >>>
> >>> It is when they do it as a favor for any government anywhere or just for
> >>> fun,
> >>> that I'm concerned. I haven't read the methods proposed to record calls
> >>> by MS. I
> >>> thought that if one side of the skype call had an open inbound port,
> >>> then no
> >>> "supernode" was involved in the call, so no 3rd party would be needed
> >>> after the
> >>> initial "what is your IP" was determined. I thought that opening an
> >>> inbound port
> >>> for skype turned the system into a supernode for others to leverage, so
> >>> this
> >>> isn't a perfect solution. Seems that recording would need to happen on
> >>> one of
> >>> the systems involved in the call and transmitted to a remote system.
> >>>
> >>> I also read that a team had reverse engineered the Skype encryption and
> >>> released
> >>> the code
> >>>
> >>> http://www.h-online.com/security/news/item/Skype-s-encryption-procedure-partly-exposed-1034577.html
> >>> . That doesn't mean the encryption has been cracked.
> >>> _______________________________________________
> >>> Ale mailing list
> >>> Ale at ale.org
> >>> http://mail.ale.org/mailman/listinfo/ale
> >>> See JOBS, ANNOUNCE and SCHOOLS lists at
> >>> http://mail.ale.org/mailman/listinfo
> >>>
> >>
> >>
> >>
> >> --
> >> :wq!
> >>
> >> ---------------------------------------------------------------------------
> >> Robert L. Harris
> >>
> >> DISCLAIMER:
> >> These are MY OPINIONS With Dreams To Be A King,
> >> ALONE. I speak for First One Should Be A Man
> >> no-one else. - Manowar
> >>
> >> _______________________________________________
> >> Ale mailing list
> >> Ale at ale.org
> >> http://mail.ale.org/mailman/listinfo/ale
> >> See JOBS, ANNOUNCE and SCHOOLS lists at
> >> http://mail.ale.org/mailman/listinfo
> >>
> >>
> >
> >
> > --
> > --
> > James P. Kinney III
> > *
> > *Every time you stop a school, you will have to build a jail. What you
> > gain at one end you lose at the other. It's like feeding a dog on his own
> > tail. It won't fatten the dog.
> > - Speech 11/23/1900 Mark Twain
> > *
> > http://electjimkinney.org
> > http://heretothereideas.blogspot.com/
> > *
> >
>
>
>
> --
> --
> James P. Kinney III
> *
> *Every time you stop a school, you will have to build a jail. What you gain
> at one end you lose at the other. It's like feeding a dog on his own tail.
> It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
> *
> http://electjimkinney.org
> http://heretothereideas.blogspot.com/
> *
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120628/933a77ed/attachment-0001.bin
More information about the Ale
mailing list