[HN Gopher] Barracuda Urges Replacing - Not Patching - Its Email...
       ___________________________________________________________________
        
       Barracuda Urges Replacing - Not Patching - Its Email Security
       Gateways
        
       Author : LinuxBender
       Score  : 146 points
       Date   : 2023-06-10 20:06 UTC (2 hours ago)
        
 (HTM) web link (krebsonsecurity.com)
 (TXT) w3m dump (krebsonsecurity.com)
        
       | znpy wrote:
       | I wonder what bcantrill's take on this will be.
       | 
       | He's been on his personal holy war on firmware for years now, I'm
       | not joking, I'm curious to read his opinions on this issue.
       | 
       | Maybe barracuda could use some kind of standalone 2u oxide server
       | instead of supermicro servers? ;)
        
         | brirec wrote:
         | With all due respect (and I really mean that -- bcantrill is
         | absolutely deserving of tremendous respect), why would using an
         | oxide server for the hardware be any different (better or
         | worse) than a SuperMicro server?
         | 
         | And further, is it even possible to get Oxide equipment yet? Is
         | there even a timeline? Or is it still vaporware?
        
       | Ccubidu wrote:
       | Seems like they can only patch the application remotely - and not
       | the OS - at least not at the same time (patch OS - then after
       | reboot - let the app look for updates. The time between could
       | have been enough to compromise it again)
        
       | PragmaticPulp wrote:
       | Barracuda is providing replacement hardware at no cost. This
       | critical piece of information is buried halfway down the article:
       | 
       | > In a statement, Barracuda said it will be providing the
       | replacement product to impacted customers at no cost
       | 
       | Obviously the time and effort to replace a device isn't free, but
       | at least they're doing the right thing by acknowledging the issue
       | and doing what they can to fix it definitively.
        
         | samstave wrote:
         | Way cheaper than a lawsuit!
         | 
         | But correct - its the right thing to do regardless of the true,
         | ultimate motivations...
         | 
         | But what I'd like to know is the impact of this? Like - how
         | much corporate opportunity loss may have been created through
         | information breaches which were unknown... That will never be
         | known, unless we can assuredly say 'none' which is doubtful...
         | 
         | -
         | 
         | > _Barracuda said the vulnerability existed in the Barracuda
         | software component responsible for screening attachments for
         | malware_
         | 
         | Heh -- uhm... Isn't that like _ _THE_ _ _CORE_ _ component of
         | the devices job?
         | 
         | Aside from ensuring filters on attachement egress blah blah...
         | 
         | --
         | 
         | > _No other Barracuda product, including our SaaS email
         | solutions, were impacted by this vulnerability_
         | 
         | I'd like to hear them directly say that this specific ESG
         | device line was NOT used in their Email SaaS offerings?
         | 
         | And to know exactly what ESG kit they are using?
         | 
         | Seems like a reasonable request if you're a large (or any)
         | customer of theirs...
        
       | atesti wrote:
       | Is the message archiver also affected?
        
         | upon_drumhead wrote:
         | > "No other Barracuda product, including our SaaS email
         | solutions, were impacted by this vulnerability," the company
         | said.
        
       | wazoox wrote:
       | What's funny is that obviously, the Barracuda "appliance" is a
       | standard Supermicro 2U server :)
        
         | ocdtrekkie wrote:
         | This is often the case. VM appliances are all little Linux VMs
         | where the user just doesn't have access to the internals. Heck,
         | that's basically Docker containers too.
         | 
         | Also, Barracuda cheaps out on these massively especially at the
         | low end. I've seen, in the modern Core i years, Barracuda 1U
         | appliances powered by Pentium III processors. I suppose they
         | are powerful enough for the job Barracuda is asking of them,
         | but it's worth a chuckle to see how many years old the chipset
         | they're shipping is.
         | 
         | The hardware is absolutely the cheapest part of the stack for
         | them.
        
       | nickdothutton wrote:
       | Given that this looks to be just a particular build of Supermicro
       | server, I wonder what mechanism the malware uses to achieve
       | persistence such that a reformat or FS restore wouldn't take care
       | of it. Does anyone know if these devices have supermicro IPMIs on
       | them? Those are notoriously insecure (like most lights out
       | managers) and a great place to hide malware persistently.
       | 
       | Edit: Typo.
        
         | kotaKat wrote:
         | They're not all Supermicro servers. Some are other mobo
         | vendors, I've seen some ESG 400s with MSI boards in them.
        
         | greggsy wrote:
         | If your IPMI is in any way exposed to anyone other than your
         | administrators, then you have other problems. These interfaces
         | should be segmented away from all other networks, irrespective
         | of any vulnerabilities they could have.
        
           | jwiz wrote:
           | Some supermicro will default to put IPMI on the shared
           | primary nic if the dedicated IPMI nic has no link at poweron.
        
         | Animats wrote:
         | This points out a major issue with IPMI and "management engine"
         | components on motherboards. If a vulnerability is found at the
         | lower levels, you may have to replace the hardware. Vendors may
         | be more reluctant to put that stuff in if it leads to legal
         | liability.
        
         | rvba wrote:
         | Is this the same super micro that hadd physical backdoors
         | inplemeted by china?
         | 
         | https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
        
           | ocdtrekkie wrote:
           | Yes except that article has remained wholly unsubstantiated
           | by facts for five years. It seems to have been bunk.
        
           | greggsy wrote:
           | That article captured the imagination of the public, but has
           | been derided by any and every cyber security professional
           | worth their salt almost from day dot.
           | 
           | Despite this, Bloomberg have refused to retract it or supply
           | any credible sources, presumably because and continues to
           | draw traffic.
        
             | technion wrote:
             | And yet "do we have any backdoored supermicro hardware" is
             | a common question from non technical management, even
             | today. It's infuriating that it hasn't been retracted as
             | I'm still talking about it. It's also at the forefront of
             | insurance questions
        
             | hypothesis wrote:
             | Given that outsize influence, you would think they would
             | sue Bloomberg... I guess they don't really care...
        
         | technion wrote:
         | Write ups reviewing the malware never suggested such
         | persistence. This seems to be something done out of caution
         | rather than a specific finding.
        
           | greggsy wrote:
           | The writeups I'm reading suggest that the malware was
           | specifically designed to maintain persistence via firmware
           | (i.e. rootkits), typically attributable to state actors.
        
       | mikece wrote:
       | Careful what you ask for Barracuda: we were already looking at
       | replacing ours with non-Barracuda hardware and now that you are
       | saying old gear cannot be updated all I can say is thank you for
       | making my case to my managers.
        
         | MattGaiser wrote:
         | Given that the replacement will be free, doesn't that make your
         | case harder to make?
        
           | katbyte wrote:
           | It's certainly not free to arrange getting the new device,
           | swap, reconfigure, and hopefully you have HA to avoid
           | downtime.
        
             | JumpCrisscross wrote:
             | > _certainly not free to arrange getting the new device,
             | swap, reconfigure, and hopefully you have HA to avoid
             | downtime_
             | 
             | Compared to migrating to a new vendor?
        
             | thanksgiving wrote:
             | It is an email server. You can set up some kind of system
             | that "catches" incoming email while you take your hardware
             | offline and replace it. Your internal users won't be able
             | to send or receive emails but anyone outside the
             | organization would be none the wiser that your system was
             | down. If you notify ahead of time and can keep downtime to
             | under an hour, will it matter?
        
             | loloquwowndueo wrote:
             | Which you would need anyway if you switch to hardware from
             | a different vendor.
        
           | blantonl wrote:
           | He's already made up his mind, so he'll probably just leave
           | out this important tidbit when discussing the issue with
           | "management"
        
         | vyst44 wrote:
         | Can I ask - which competing devices are you planning to replace
         | these Barracuda email security gateway servers with? Thank you.
        
         | jokowueu wrote:
         | They note that "In a statement, Barracuda said it will be
         | providing the replacement product to impacted customers at no
         | cost"
         | 
         | Would you still switch to a non barracuda device ?
        
           | insanitybit wrote:
           | If you have to go through the cost of a replacement anyways -
           | as in, the time and effort to actually do it - the cost of
           | the hardware matters a lot less.
        
             | Urist-Green wrote:
             | I suspect there is a higher level question at play stemming
             | from the "deny" comments. Do you think Barracuda is
             | uniquely vulnerable to these types of threats and, if not,
             | would their competitors make similar efforts to recover?
        
             | veave wrote:
             | If this is the mindset of some people it's no wonder that
             | companies would rather deny the problem and stick their
             | heads in the sand.
        
               | insanitybit wrote:
               | The mindset that changing a system out has risks and that
               | engineers/ops time is very expensive?
               | 
               | I mean, I hear you, it sucks that being honest about the
               | issue is leading to punishment, but rationally this is
               | just how people are going to end up responding. If they
               | really want to avoid this, don't give it to them for
               | free, _pay them_ for it.
        
           | phpisthebest wrote:
           | the physical cost of the equipment is often the cheapest part
           | of a deployment.
        
       | shrubble wrote:
       | Is it likely they will analyze the firmware on the ones that come
       | back, then wipe them and resell them either thru a refurbisher or
       | even put the new software on the known-good server and use
       | elsewhere, such as in the datacenter where they have their SaaS
       | offering?
        
       | nubinetwork wrote:
       | We know already... https://news.ycombinator.com/item?id=36061772
       | https://news.ycombinator.com/item?id=36136705
       | https://news.ycombinator.com/item?id=36143926
       | https://news.ycombinator.com/item?id=36156908
       | https://news.ycombinator.com/item?id=36233472
       | https://news.ycombinator.com/item?id=36238822
       | https://news.ycombinator.com/item?id=36248328
       | https://news.ycombinator.com/item?id=36255901
       | https://news.ycombinator.com/item?id=36261519
       | https://news.ycombinator.com/item?id=36263581
       | https://news.ycombinator.com/item?id=36267639
        
         | Prickle wrote:
         | I only saw it on twitter, not here.
        
         | sbierwagen wrote:
         | None of those submissions have more than 13 points.
        
           | [deleted]
        
         | throwaway54_56 wrote:
         | "We" doing some heavy lifting here
        
           | DirectorKrennic wrote:
           | Ah, the Royal "We".
        
             | dools wrote:
             | The editorial
        
       | jokoon wrote:
       | Why doesn't the NSA just AUDITS actual source code of the
       | software that it deems it deserves to increase its security?
       | 
       | I mean it's obviously an interest to national security.
       | 
       | They could do that while maintaining the backdoors they want to
       | keep so they can have an edge on cyber warfare.
        
         | hgsgm wrote:
         | Why would a vendor give their source code to the NSA to attack
         | and also risk leak?
         | 
         | The NSA does not protect the public's computers, they attack
         | them.
        
         | EdwardDiego wrote:
         | What makes you think this wasn't the NSA?
        
       | r3trohack3r wrote:
       | This actually seems great. They're taking the hard path here
       | admitting the devices are compromised, that the state can't be
       | trusted, and that the machine needs to be tossed. Then they're
       | offering to replace the vulnerable devices.
       | 
       | I'm used to companies taking the "deny, deny, deny" route and
       | these articles are then written by their community saying the
       | response is insufficient.
        
       ___________________________________________________________________
       (page generated 2023-06-10 23:00 UTC)