Cyberoam Packet Inspection Devices Open Traffic To Third Parties

New submitter jetcityorange tipped us to a nasty security flaw in Cyberoam packet inspection devices. The devices are used by employers and despotic governments alike to intercept communications; in the case of employers probably for relatively mundane purposes (no torrenting at work). However, the CA key used to issue fake certificates so that the device can intercept SSL traffic is the same on every device, allowing every Cyberoam device to intercept traffic that passed through any other one. But that's not all: "It is therefore possible to intercept traffic from any victim of a Cyberoam device with any other Cyberoam device - or, indeed, to extract the key from the device and import it into other DPI devices, and use those for interception. Perhaps ones from more competent vendors."

Comments

Why should they be competent

[Coeurderoy]

after all their clients are either incompetent or evil....

What would be really interesting would be a simple consumer level tool to detect DPI with crypto interception...
So at least you know how much your ISP loves you....

Re:Why should they be competent

[Coeurderoy]

I do apologize, I should have written something real useful like "first post", but it is the first time it happens to me, so I forgot :)

Re:Why should they be competent

[houstonbofh]

First time I have seen 3 posts before a "Frist Psots!!!"

Re:Why should they be competent

[Jeremiah Cornelius]

The most interesting aspect of this story, NOT HIGHLIGHTED IN THE SUMMARY, is that this was discovered by volunteers on the TOR project - and was being used as a compromise of a TOR node.

Re:Why should they be competent

[russotto]

What would be really interesting would be a simple consumer level tool to detect DPI with crypto interception... So at least you know how much your ISP loves you....

Just use a browser. Theoretically your ISP could intercept all the ways you could acquire a browser over their network and install their cert in each, but you could use a browser acquired elsewhere. Then go to any secure site and if you get a certificate warning, be suspicious.

Re:Why should they be competent

[fluffy99]

after all their clients are either incompetent or evil....

What would be really interesting would be a simple consumer level tool to detect DPI with crypto interception...
So at least you know how much your ISP loves you....

Well the fake certificates will only work if you trust the certificate the box is using to generate the fakes. Seems rather trivial to check your root/trusted certificates, eh?

Re:Why should they be competent

[Coeurderoy]

well the typical consumer has clicked: yes, yes, yes, yes ... a couple of month ago...
And does not understand how any of this works...

So a tools that tells him or her ... "I see a spy siting about ==> here" sniffing your youtube/facebook/etc... transaction would be
more helpful than being satisfied that you can :
If you use firefox do Edit/Preferences/Advanced/View certificate and see if any seems suspicious, btw it could probably even be called something like "Best Verisign for Trust in Your Region" or "ZTCK s.r.l Switerland" ...

And unless you are quite IT competent it is close to useless...

Re:Why should they be competent

[fluffy99]

If you're using IE, just click the little padlock and see who signed the certificate. In firefox, you click to the left of the URL. Of course it's a few more clicks to see the actual chain. FF also shows you the intermediate cert and not the root like IE.

You're probably right though, that some quick utility to make it idiot proof would be helpful.

Re:Why should they be competent

[Anonymous Coward]

I see no evidence that this was an attempt to compromise a TOR node. It sounds more like a TOR (and HTTPS-Everywhere???) user in Jordan noticed, due to browser-plugin reported SSL certificate anomalies and with assistance of the TOR team, that his ISP was using Cyberoam devices to intercept SSL traffic. I imagine this ISP monitor the SSL connections of all its users, not just the TOR using ones.

So the situation is more likely that Jordan monitors the communication of its citizens. Not a nice thing, but it is a well known fact.

This is suprising?

[houstonbofh]

People are surprised that a device that hacks it's way in to ssl communication is insecure? Contrary to popular belief, people that specialise in tearing down walls are not the best wall builders.

Re:This is suprising?

[PIBM]

Why aren't browsers warning against certificates signed by this bad keychain ? They should all ban them.

Re:This is suprising?

[houstonbofh]

It is part of a egress filter. If you do not accept the cert, you just do not get out...

Re:This is suprising?

[Anonymous Coward]

I didn't rtfa but I think you have to import the fake ca into your browser before it will work.

Companies will just preinstall the ca on desktops.

Re:This is suprising?

[Anonymous Coward]

I was wondering about this too. It seems like... if you add this "egress certificate", then by definition they can snoop on you. You know you don't have a private channel as soon as you add it.

There are ways to establish a private channel over a non-private channel, of course, but that won't generally be possible with any random web site.

Re:This is suprising?

[Anonymous Coward]

The browser normally does warn you. I have been seeing invalid certs for a month now. In fact I just got a bad cert for torproject.org when clicking on the first link.

I predict some kind of attack in the next six months.

Derp!

[girlintraining]

This just in: End to end encryption which does not form trust via a third party (like a certificate authority) still the best way of securing communications. The certificate authority system has been flawed from day one. IPSEC is still the way to go, along with secure DNS, but as you will note... companies and governments have been dragging their feet on it. A good indication that something is secure is that laws are passed against its use.

Re:Derp!

[Alimony Pakhdan]

>IPSEC is still the way to go
As long as you really know who you are communicating with. And as long as the whole network supports all the weird NAT out there. And as long as you really have it configured right. Oh never mind.
>A good indication that something is secure is that laws are passed against its use.
Thats some mighty secure methamphetamine you got there...

They have to inject the cert first

[Animats]

I don't think this is a cert issuer trusted by major browsers. Unless some "toolbar" or a corporate installation has managed to put this cert into your browser (which happens), this attack may be ineffective against browsers.

Re:They have to inject the cert first

[Anonymous Coward]

That's quite beside the point. These are devices that are used on managed networks, where the admins add the certificate to all computers and browsers, so that the traffic between "their network" and the whole wide world can be intercepted without disallowing encryption. The problem is that all these interception boxes use the same certificate. So now anyone who has access to one of these boxes can use this certificate to decrypt any data which is sent to/from networks where the admins installed one too. This is entirely unnecessary, since the certificate is self-signed anyway and could be different for every company. The interception box doesn't need to (and shouldn't) come preinstalled with a certificate at all. The way to get a certificate on these things should be that the admin presses a button to generate a new one or load one from a USB stick.

Dual SSL certification anyone?

[stanlyb]

I fail to see how this device would intercept my dual certificate handshaking, but also WHY no everyone out there thinks that one-way SSL certification makes your connection secure!!!

Re:Dual SSL certification anyone?

[stanlyb]

Or if i want to make myself clear, here is one sample:
FILENAME=server
openssl genrsa -out $FILENAME.key 1024
openssl req -new -key $FILENAME.key -x509 -days 3653 -out $FILENAME.crt
cat $FILENAME.key $FILENAME.crt >$FILENAME.pem
chmod 600 $FILENAME.key $FILENAME.pem



FILENAME=client
openssl genrsa -out $FILENAME.key 1024
openssl req -new -key $FILENAME.key -x509 -days 3653 -out $FILENAME.crt
cat $FILENAME.key $FILENAME.crt >$FILENAME.pem
chmod 600 $FILENAME.key $FILENAME.pem


CLIENT SIDE:
socat stdio openssl-connect:server.domain.org:4433,cert=$HOME/etc/client.pem,cafile=$HOME/etc/server.crt

SERVER SIDE:
socat openssl-listen:4433,reuseaddr,cert=$HOME/etc/server.pem,cafile=$HOME/etc/client.crt echo


VOILA. Now i would give anyone 2 cents if he manages to sniff my connection with this little tiny device...

Re:Dual SSL certification anyone?

[durdur]

Only a very tiny percentage of traffic on the web uses client authentication. Yes, it is secure. But if you have a lot of clients then certificate management becomes a major issue.

Re:Dual SSL certification anyone?

[Anonymous Coward]

I fail to see how this device would intercept my dual certificate handshaking, but also WHY no everyone out there thinks that one-way SSL certification makes your connection secure!!!

Because not everyone is a fucking nerd with no life outside of their computer.

dude i got hella diarrea

[Anonymous Coward]

also: fuck verizon

NetVCR

[Anonymous Coward]

The flaws in Niksuns NetVCR/NetDLive are worse!

How do you protect against SSL MITM attacks?

[Anonymous Coward]

How do you protect yourself against rogue CAs that issue "legit" certs that raise no warnings in browsers? Most people have no way of knowing who the issuer of their bank's cert is. Same goes for email... some rogue CA can issue a mail.google.com cert and someone can perform a MITM attack.

Is there a way to protect yourself against this?

CA trust injection via Active Directory

[ei4anb]

Most companies that do this type of SSL inspection at their Internet gateways can get Internet Explorer (and such companies often standardize on IE) on the user's PCs to trust the fake certificate by pushing the fake Certificate Authority Root Cert through their Active Directory.

Re:CA trust injection via Active Directory

[DarkOx]

Yes, but you push your own root certificate form your own CA. Then you generate the remote server certificates using that or a subordinate CA. What you don't do is use some certificate that came on your SSL intercept box, because if you do the private key is um, not private. If your SSL intercept solution does not allow you to setup your own trusted root find a new one.

This is whole problem is one born of simple incompetence.