Critical SSH Backdoor in multiple Barracuda Networks Products(archives.neohapsis.com)
archives.neohapsis.com
Critical SSH Backdoor in multiple Barracuda Networks Products
http://archives.neohapsis.com/archives/fulldisclosure/2013-01/0221.html
55 comments
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.
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?
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."
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."
No, the way these work is your IT deploys the internal CA cert as trusted on all systems in the enterprise.
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.
Wait, so is the private key for that certificate stored on the Barracuda device!?
If it's possible to become root on these devices, then ... wow.
If it's possible to become root on these devices, then ... wow.
Yes, it has to be able to sign all the fake certs it generates.
No, he means the ssh key.
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.
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?
Or am I missing something?
Or am I missing something?
You're 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.
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?
[deleted]
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.
The Barracuda device doesn't allow you to do anything you couldn't already do with other tools.
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.
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.
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.
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.
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?
That said why the hell are there UNDOCUMENTED backdoors? I mean it makes sense from a customer support perspective but really?
If you think thats bad, why are there undocumented backdoors that don't immediately trace back to Barracuda?
What do you mean?
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."
White hats tell you what they're doing and why.
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.
Does this add any security? Your fake sshd can also say "Barracuda field service access".
No, it's just to explicitly inform the customer that Barracuda has shell access to the appliance. These accounts were undocumented.
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.
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.
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"
"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"
Well, now you know how to fix that.
With a properly formatted request to the department responsible for maintaining the web filter, of course.
With a properly formatted request to the department responsible for maintaining the web filter, of course.
This is highly suspicious!
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've always felt vaguely distrustful of Barracuda anyway, but it's nice to have some facts to cite when not recommending their products.
Here is the timeline if you're interested - 14 days from contact to publication:
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.
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.
From the post to f-d:
> 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.
Oops. You are completely correct. I posted the timeline for the follow-up advisory! And it's too late to edit.
Oops! This is the correct timeline (the other one is a followup advisory):
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.
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.
I wonder how much it is worth to crack the root password that was left embedded in all the Barracuda devices even with the patch applied?
Is it the same in all devices? Is it ever changed? How many people know it?
To a competitor? Depends if people blame barracuda or can trace the cracking back to you.
Are you thinking of switching a bitcoin mining operation into a cracking-passwords-to-put-companies-out-of-business operation?
Are you thinking of switching a bitcoin mining operation into a cracking-passwords-to-put-companies-out-of-business operation?
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.
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.
The "patch" disables some but not all backdoor accounts on the machine. The root account is still present with password auth.
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.
Monitoring and support backdoors are common and pervasive in most networking gear. This isn't something that should be considered lightly.
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...
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...
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"!
[deleted]
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.
Why did they write pubic key in the solutions bit? Surely a sly joke..
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?
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.
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.
The easiest way is to just not buy that crap at all. Computers are cheap, open source software is available, put the two together.
People do not want to maintain that stuff. Your comparative advantage as a startup is not running your own firewall.
Nb: I am employed by a Barracuda competitor, but would probably still advise against trying to run things on your own.
Nb: I am employed by a Barracuda competitor, but would probably still advise against trying to run things on your own.
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.