As to why they did this -- feature checklist compatibility with Huawei and ZTE is my guess.
Remember most of these do intercept -- they have an SSL CA cert which is trusted by all your business client devices, to do MITM. So, if you pwn the box, you can pwn all the SSL traffic at the target company, too. It's an excellent place to attack.
Internal netpens for F-500 companies are often (maybe usually) considered failures for the pentest team if they don't yield mass server compromises from an unprivileged starting point.
If you can log into a middlebox like a MITM proxy from the Internet at all, you now have an Internet to internal-network pivot. You are at the "unprivileged starting point" of an internal net pentest. Go ahead and grab the CA=YES cert, but then get on with owning up the whole network.
Internal network security at large enterprise networks (the kinds that routinely MITM intercept SSL traffic) is extremely bad.
I really hope this certificate is not installed/trusted by default on major browsers. Can somebody confirm it?
EDIT:
https://www.barracudanetworks.com/news/press_release/33
"Transparent deployment of this enhanced SSL Inspection feature requires deployment of a trusted root certificate on client Web browsers."
If it's possible to become root on these devices, then ... wow.
Edit: Nevermind, he doesn't...I thought that's what "become root" meant.
There are ssh pub keys on it, so anyone with the private key can log in. I believe F5 networks had appliances with this problem, and the corresponding ssh private key was also left on the device.
Or am I missing something?
These aren't certificates signed by a CA that's trusted by most browsers - they're self-signed certificates (signed by the appliance) that are trusted within the organization using the Barracuda hardware by provisioning employee browsers to accept the CA.
If you were to extract the private key and use it to sign certificates elsewhere, you'd get the same warning as though you generated a random certificate and used it; the key is only useful within the organization that trusts it.
However, if an organization were able to get a widely-trusted MitM cert (such as this one http://www.theregister.co.uk/2012/02/09/tustwave_disavows_mi... or this one http://ssl.entrust.net/blog/?p=1696 ) and deployed it on their Barracuda, it could likely be extracted by someone with root-level access.
It wouldn't surprise me to see some "loose nukes" arise out of Barracuda's utterly irresponsible behavior here.
Generally if you're targeting a specific organization, that's what you care about, anyway. You're not hacking into random companies to build a botnet; you're going after a specific organization to gain some economic or intelligence/military benefit.
I don't know what important organizations use Barracuda, though. It's generally SME-focused. Might be some interesting law firms and other organizations with sensitive data belonging to larger organizations, though.
1. Unconstrained, like the Trustwave and Turktrust examples. These can be used to MitM any domain, with a very few exceptions like Chrome talking to Gmail. This is the normal kind of subCA.
2. Name-constrained sub-CAs such as described here https://groups.google.com/forum/?fromgroups=#!topic/mozilla.... These are very new. They aresupposed to be for organizations (say example.com) that want to issue their certs for www.example.com, intranet.corp.example.com, and so on without using a wildcard cert or paying extra for every single cert.
Neverheless, these private keys can sign MitM certs for any domain, however, whether or not it's valid is in the mind of the client application. Recent versions of the the three major browsers should in theory only accept them for names that sub-CA is approved for. But few if any non-browser SSL/TLS clients recognize these name constraints, so it represents full MitM capable attacker to those clients. Of course, there are a lot of TLS clients that don't validate or even check the subject name on the server cert at all, so many of these apps are pwned anyway.