Critical SSH Backdoor in multiple Barracuda Networks Products
archives.neohapsis.com
archives.neohapsis.com
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.
That said why the hell are there UNDOCUMENTED backdoors? I mean it makes sense from a customer support perspective but really?
If you've got accounts on the system, they can have GECOS fields saying the same.
And put it in the manual. "Disabling the fieldservice account will prevent service personnel from logging in. Customers with active support contracts should not do so."
White hats tell you what they're doing and why.
Started tracing IPs. Turned out it was coming from a gateway used by our corporate parent (very large organization). Further tracing localized it to our office.
Turned out my seatmate (who I'd included on the initial email and who had heard me muttering over this for 2 days) was the guy who had some random bozo named account that he was using for test purposes ... but had neglected to tell anyone about.
Sort of pissed me off.
One reason for documenting these backdoors is so that, if you're OK with their legitimate use, you can properly audit and account for their legitimate use. That said: given shared keys and common access, I'd be inclined to consider the device unsecurable.
Note, I have no idea why the user is dead, nor if this solution actually works, but I'm posting Intermernet's post below:
The workaround mentioned involves:
1. Log in to the device and go to the "Advanced" tab on the web GUI.
2. Add "&expert=1" to the end of the URL.
3. Click on the red "Expert" button.
4. Scroll to the bottom and disable remote support.
You will need to reverse this process if you ever actually require the barracuda remote support.
"The link you are accessing has been blocked by the Barracuda Web Filter because it contains spyware. The name of the spyware is: Spyware.Exploit.Misc.MWBR"
With a properly formatted request to the department responsible for maintaining the web filter, of course.
I've always felt vaguely distrustful of Barracuda anyway, but it's nice to have some facts to cite when not recommending their products.
2013-01-10: Sending advisory and proof of concept exploit via encrypted channel.
2013-01-14: Vendor confirms receipt and provides BNSEC IDs.
2013-01-14: Vendor sends listing of reported vulnerabilities and release schedule.
2013-01-21: Conference call - discussing implemented solutions.
2013-01-23: Barracuda Networks releases alert & secdef
2013-01-24: SEC Consult releases coordinated security advisory.
> 2012-11-29: Contacting vendor. > 2012-11-29: Sending advisory and proof of concept exploit via encrypted channel.
2012-11-29: Contacting vendor.
2012-11-29: Sending advisory and proof of concept exploit via encrypted channel.
2012-12-04: Vendor confirms receipt and provides BNSEC IDs.
2012-12-05: Requesting further coordination (conference call).
2012-12-13: Sending reminder regarding SEC Consult disclosure policy.
2012-12-15: Vendor responds - arranging conference call.
2012-12-18: Conference call: Addressing the risks the discovered vulnerabilities pose to customers and release schedule.
2013-01-14: Vendor sends listing of reported vulnerabilities and release schedule.
2013-01-21: Conference call - discussing implemented solutions.
2013-01-21: Vendor provides information about some questions which came up.
2013-01-22: Asking for definitive listing of affected appliances.
2013-01-23: Barracuda Networks releases alert & secdef
2013-01-24: SEC Consult releases coordinated security advisory.
Are you thinking of switching a bitcoin mining operation into a cracking-passwords-to-put-companies-out-of-business operation?
Since it's apparently unclear, I'm not talking about taking action myself, but I will say that due diligence for any company using Barracuda hardware means that they should be asking the same question themselves.
There's been some hullaboo about Chinese manufacturers putting backdoor access into their devices, Huawei Technologies and ZTE Corporation particularly: http://www.infosecisland.com/blogview/21930-China-Has-Backdo...
Legally mandated backdoors exist on Cisco gear as well: http://www.forbes.com/2010/02/03/hackers-networking-equipmen...
Is there anything you can do to be at least a little bit safe?
Are there vendors that still value security or is it just accepted now that MITM and state-sponsored attacks are a normal way of operating?
We're actually working on some tech solutions which might help in the software defined networking security area, but it'll be 6-12 months. Ideally some of it will be open sourced and/or standardized.
Nb: I am employed by a Barracuda competitor, but would probably still advise against trying to run things on your own.