Looks like it's worth avoiding Barracuda appliances even after this patch, since they're retaining the "remote" account.
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.
In reality, the CA=YES cert loaded onto a Barracuda MITM proxy at an enterprise would be a second-tier trophy in the biennial internal network penetration test.
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.
> 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.
I really hope this certificate is not installed/trusted by default on major browsers. Can somebody confirm it?
I believe IE and Chrome use the operating systems list of certs. So your corporate IT dept can deploy the trusted certificates pretty easily. Firefox has it's own list of certificates so in theory is less susceptible to these corporate MITM attacks.
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.
Seems like it would be possible to extract the private key then and use it elsewhere, no? So you wouldn't be limited to MITM'ing only at the company where this device sits, but you could effectively MITM (without generating any certificate errors or warnings) anywhere you can get in between the client and server?
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.
For a large enough organization, this could be enough. Would it be possible for a hacker to break in, extract the private key, cover their tracks, then create, say, a phishing website that uses the Barracuda CA? Would it show up as a self-signed certificate at any other organization, but it would show up as a trusted site within the organization?
Okay, I understood it as the CA certificate was signed by a "trusted" root CA (one already present/trusted by user's browsers). Glad to hear I'm wrong. Thanks.
A lot of companies do org-wide MITM CA keys, so just hitting one Barracuda box, stealing the CA key, etc. lets you attack all of that organization's users everywhere.
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.
If one were to get a widely-used SSL-cert, that could be used to MitM any domain ? Or would it only work for specific domains like, this one works for Google and Yahoo, but this one would work for Microsoft?
There are two types of sub-CAs that we could see leak from interception devices that chain to a widely-trusted root:
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.
If you have a signing cert that browsers trust, you can forge a cert for any site (unless your browser has previous knowledge and pinned the right cert for a site).
If you are going to put backdoors (I can't believe I am even saying this) on your product then it might be good to at least disable normal password logins and only do SSH key exchange.
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 SSHd running on an unexpected port, you could put in a banner: "Barracuda field service access".
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."
Reminds me of a situation I encountered at a prior gig. We were getting random log-ins to an administrative account from a user we didn't recognize. I sent email around the group asking if anyone knew what was up. Nope.
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.
I briefly worked for Barracuda support a few years ago. I don't know how they market or publicly document the boxes, but it seemed common knowledge that we had ssh access. None of the customers I talked to blinked an eye. Most of them outright expected it. So I'm not sure it's so much "backdoor" as "feature".
There's a very unfortunate [dead] comment by Intermernet in this thread. Unfortunate because it might be a good solution for someone who administers the affected hardware and wants to remove the backdoor after patching (as per the Workaround section in the OP, "Barracuda Networks offers an expert option that disables the SSH daemon.
For assistance contact the Barracuda Networks Support.")
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.
I attempted to view this URL at work. It was blocked by our Barracuda filter.
"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"
It's unfathomable to me why any company in the IT security industry would ship a product with an undocumented remote access mechanism built-in. This seems like a sure way, when the mechanism is inevitably discovered, to cause harm to your company's reputation.
I've always felt vaguely distrustful of Barracuda anyway, but it's nice to have some facts to cite when not recommending their products.
I'm more afraid of the nebulous criminal underground or national entities than I am of Barracuda's competitors. I'm not referring at all to Bitcoin (or putting companies out of busines...), it's surely cheaper to just use available "cloud cracking" assets directly (which I'm also sure is already being done).
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 services that already do this, but it's not really necessary in most cases. Even with my lonely workhorse I can smash through hundreds of millions of hashes a second. You only need additional reinforcements for more computationally harder hashes.
I worked for Barracuda, I left, because I felt the company was slimy. On the other hand, from a customer service point of view, this supposed back door is great, it makes the product much easier to support, for a customer base who is honestly, most of the time not that technically astute. If they were more astute, they would have bought a different product.
Wow thats amazing. Honestly feel bad for any IT admin who bought any of their products not knowing about those backdoors(assuming they arent disclosed anywhere). I personally would be extremely upset to read that A)they had backdoors in the box they sold me, and that B)they intend to keep them intact for "customer support"!
I've had an upswing in spam today on my systems, and it looks like a lot of them have headers indicating they've gone through a Barracuda device. It doesn't surprise me that spammers are all over this.
Knowing not much about network appliances and their role etc., when you're building a company, starting from scratch, are there good rule of thumb to not fall for the "enterprisey compromisey" piece of junk that such companies (Huawei -- state-sponsored espionnage-- ZTE, Barracuda, etc.) do sell?
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?
In the long run, I have more faith in software defined networking to de-shitify this space than any other single solution.
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.
Which is where leveraging Open Source comes into play. We have ROMs for home networking gear, we have bootable distros for security purposes, we have open source builds for Android. No reason similar projects couldn't be aimed at enterprise type kit. You'd still require hardware manufacturers, though open standards and whitebox builds might come into being. And there'd be distro wars, but very likely 2-3 lead contenders that would be the default safe choice.
You have to maintain a crappy closed firewall just as much as you have to maintain an open source one. In fact, installing, configuring and maintaining an openbsd firewall is much easier and less involved than any of the commercial firewalls I've had the misfortune of using.
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.