[cryptography] skype backdoor confirmation

ianG iang at iang.org
Fri May 17 03:26:07 EDT 2013


On 17/05/13 00:48 AM, Adam Back wrote:
> I saw someone mentioned on Ians blog that they had seen the HTTP requests
> arrive too.  Looking I did also (these two are in http access log) the two
> in parent article are in ssl access log as I mentioned.  Its not just SSL.
>
> 65.52.100.214 - - [16/May/2013:13:04:48 -0400] "HEAD
> /Leghirs3cleQuiWruAg6fenfAryib7CajVisBeb8.php?user=foo&pass=yeahright
> HTTP/1.1" 200 -
> 65.52.100.214 - - [16/May/2013:13:37:26 -0400] "HEAD
> /Leghirs3cleQuiWruAg6fengyarrUg5blettOlyurc7.html HTTP/1.1" 200 -
>
> The real question is how.  Is this happening on the server.  Or is it
> happening in the client, reporting URLs to mothership.


Precise.  As the Germans would say.  Is there some form of universal 
backdoor built in, or is there a limited, hard-backed & anonymised code 
patch that just does URLs for spam monitoring?

And, what happens when they find a URL that is dodgy?  Do they alert 
that user?  Or is it just a general internal warning to their team? 
Tricky questions for the legal department -- having just watched a user 
lose their life savings to a ukrainian phishing attack ... they did ... 
precisely nothing?


> And how dare they also.  Very double plus ungood, microsoft.  Shades of the
> Lotus Notes OU=MiniTruth CN=BigBrother (actual strings contained in the
> binary for lotus notes to describe the certificate backdooring their email
> security).  http://cypherspace.org/adam/hacks/lotus-nsa-key.html


:)  So someone in the tech department left some clues.

> I wonder what else microsoft have backdoored of their many products with
> SSL
> and other forms of encryption in them.  Maybe the OS itself.  People may
> remember microsoft's own NSA key
> http://cypherspace.org/adam/hacks/ms-nsa-key.html
> - did they go the whole hog and just backdoor the OS?  They issued some
> non-denial denials at the time.  But maybe its us who is being massively
> naive here.  Crypto-geekery while they've been having a decade long massive
> backdooring party.


The absence of information -- hard denials as you put it -- works to the 
benefit of the attacker.  Anyone who suspects can be attacked in public 
as a conspiracy nut.  Or, the common thing is that they can be told to 
prove their terrible accusations against a fine corporate citizen.

We should really be thinking the other way -- what is reasonable to 
assume is likely from the motives and past history of the actors, given 
their tendency to not confirm or deny what is asked of them?  Perhaps 
this is the Israeli nuclear bomb question...



Another observation is that this appears to be a normal cycle, a sort of 
PLC for security products as it were.

A new security tool starts up with great claims and great proofs. 
Everyone swarms to it and it becomes part of the environment.  The 
vendor maintains good security.  For a while.  A few sales, transfers, 
etc ... and the new owners don't understand the original context, but 
now have to squeeze the users for revenue to pay for the buyout.  While 
fighting those fires, security seems to become more aligned with 
interests.  Friends can help them...  A few discoveries later, the 
mantra is "well, we always intended not to keep it secure in that way..."

Is it unreasonable for us to expect Skype to go another way?  Are we 
asking too much?



iang



PS: PLC is "product life cycle"




> Adam
>
> On Thu, May 16, 2013 at 09:52:24PM +0200, Adam Back wrote:
>> To my surprise I see this two entries in the apache SSL log:
>>
>> 65.52.100.214 - - [16/May/2013:13:14:03 -0400] "HEAD
>> /CuArhuk2veg1owOtiTofAryib7CajVisBeb8.html HTTP/1.1" 200 -
>> 65.52.100.214 - - [16/May/2013:14:08:52 -0400] "HEAD
>> /CuArhuk2veg1owOtiTofAyarrUg5blettOlyurc7.php?user=foo&pass=yeahright
>> HTTP/1.1" 200 -
>>
>> I was using skype on ubuntu, my Ian on the other end was using MAC
>> OSX.  It
>> took about 45mins until the hit came so they must be batched.  (The gap
>> between the two requests is because I did some work on the web server
>> as the
>> SSL cert was expired and I didnt want that to prevent it working, nor
>> something more script like with cgi arguments as in the article).
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography



More information about the cryptography mailing list