Barracuda Urges Users to Replace Compromised ESGs; CL0P Ransomware Group is Exploiting MOVEit Vulnerability; Prioritize MFA

It is always recommended to rebuild systems involved in a compromise "from scratch," and to not just remove specific artifacts left behind by the attacker. But we hardly ever see a vendor's full support. I have not seen details about how Barracuda will replace the devices (easier if they are virtual), but applaud Barracuda. In particular for somewhat customized appliances, it can be difficult to conclusively assess what modifications were made by an attacker.

A long list of email security and web security gateways have been announcing discovering long resident zero days. Good idea to preemptively check patch status of ESGs and WSGs appliances in particular, and to prioritize threat hunting on those network segments.

Barracuda had previously said they were replacing affected appliances or virtual machines, which has likely generated a queue for physical hardware, so don't wait, get ahold of your sales rep (now) to not only get your request queued up, but also find out what your options are. Have your staff brush up on the replacement process, you don't want the replacement sitting on a shelf, or running in parallel or standby any longer than is absolutely needed. Consider recreating the configuration rather than exporting it from a potentially compromised device.

Well, this is the worst-case scenario. If someone has a Barracuda Email Security Gateway they want to send my way instead of sending it to the trash, I’m happy to have it. Will this keep Barracuda customers in their eco-system or move them to a cloud-based service? Hard to tell what the impact here is since many customers may be used to refreshing this hardware frequently.

It seems as though email security gateways have been a target of evil-doers over the last year. Even if you don’t use Barracuda appliances, I still recommend checking patch status for your chosen email security gateway. For Barracuda users, no time like the present to have that difficult customer service discussion with them… and update the appliance.

Do not focus too much on specific IoCs if you are using MOVEit. Assume compromise. This vulnerability has been exploited at least since May 31st, and CL0P is just the latest group to jump on the bandwagon.

This attack with MOVEIt is very interesting. It’s another SolarWinds-like attack where you have a potentially small to medium business software package from Ipswitch. If the name is familiar, they are the makers of the WS_FTP software package that was widely popular in the 90s and early 2000s. This attack is brilliant because they are going after something that we would assume is no longer prevalent in most enterprises: perimeter services. These were classically services you would find on the edge of a network, and today those have mostly gone away due to cloud services. What may remain are packages like these that are perfect for attackers to look at but not thoroughly vetted.

If you've been waiting on deploying updates to your MOVEit file transfer service, you're likely compromised. Don't get distracted by CL0P, they are just the latest gang jumping into the mix. The CISA bulletin suggestions highlight the value of the basics, keeping an accurate inventory of what you have, and what it should be doing; only assigning admin privileges where needed, keeping software and services updated, using secure configurations, and monitoring.

As this has been widely reported over the last week or so, no time like the present to patch this critical vulnerability. The CISA/FBI advisory only adds to the chorus to revisit your patch management process and prioritize the update.

Not really anything new in this document and I think it should prioritize requiring MFA for all remote access at least as much as it mentions phishing education requirements. The section on Recommendations for MSPs and IT Administrators does include MFA recommendations and other requirements that are good to use in RFPs and evaluations of managed services and remote access as a service offerings.

What they are reminding us about is that there are packages that can provide remote access to endpoints, without the need of your corporate VPN, via various techniques, and our job is to detect these, only allowing authorized services, and then to properly secure those services. Make sure any service that provides for remote connection is using strong authentication (read: not passwords) such as MFA and that you can monitor their use. With a hybrid workforce, implementing controls has to be more than just at the boundary, they need to also hit the endpoint. Add VNC Connect to their list of services to check for.

As with the last one, we have remote access software, another perimeter service, that gets abused. The advantage here is that you don’t need to find SQL Injection or Remote Execution to get into the environment; the service provides this. Hopefully, you are still using secured remote access software and not just opening RDP to the internet for access. Use a strong authentication standard, and if you can find a system that provides mutual authentication standards even better.

While the guide is perhaps helpful, if really doesn’t contain anything new. At least one cybersecurity framework already prioritizes a set of cybersecurity safeguards that are highly effective against attacker techniques, and those critical security safeguards are independent of the software application.

The major finding was a failure to move to MFA for most (89%) of high value assets. The DoI response was to cite many memos that were written and to state “The Department and the bureaus and offices will take a risk-based approach in prioritizing the conversion of systems and applications from legacy authentication methods to MFA.” There is no real risk-based approach that wouldn’t prioritize moving away from reusable passwords for critical systems. The issue is not risk assessment, it is overcoming bureaucratic and operational obstacles to having a successful transition to strong, phishing-resistant authentication.

This problem is easier to work today than even five years ago. Everyone got excited about not having to change passwords when NIST SP 800-63-3 came out a few years back. Unfortunately, many didn't catch the part about reviewing them against breach data, not allowing banned words, etc. The good news is there are services you can integrate with your domain controllers to help AD managed passwords meet these requirements, including services in Microsoft Azure. Even so, you're not done at that point: you need to make sure that local passwords and systems not authenticating against AD are included. The good news is most applications now support SAML 2.0 or other mechanisms your IDP already speaks, and the IDP can enable SSO, MFA, and other authentication improvements without re-working the services and applications behind them.

This OIG report simply highlights the fact that [weak] passwords are still the primary authentication mechanism throughout the federal government. EO 14028, Improving the Nation’s Cybersecurity, called for a move to a zero-trust architecture, with an emphasis on multi-factor authentication (MFA). OMB followed shortly with their own memorandum, M-22-09, that required agencies to meet specific cybersecurity standards in the EO by end of FY2024. I suspect password changes will be made in the short-term but doubtful that we’ll see a move to MFA for another year or so.

The recommendations not only include clarifying and updating expectations and roles, but also increased information sharing and better cataloging of critical infrastructure. All these are good things, and if the directive is not accompanied with funding, not only for CISA, but also for the downstream agencies expected to comply, success becomes dubious. Agencies need to be able to meet these requirements as well as mission objectives, to remain viable.

No argument that directives should be reviewed and updated [as needed] on a regular basis – it’s been 10 years. What can inform that review is a ‘cybersecurity scorecard’ of the country’s critical infrastructure. Unfortunately, such a scorecard doesn’t exist. What we have is irregular reporting on the state of cybersecurity for each critical infrastructure as they are targeted. Perhaps now is the time to establish that common set of cybersecurity requirements across every sector. That way, at least we know the state of cybersecurity for our critical infrastructure and where additional emphasis needs to be placed.

A discovered flaw in SPF enabled the BIMI authenticity check to be fooled. Bug reports were previously responded to as “intended behavior, won't fix” until Google finally saw the volume of email leveraging the bypass and addressed it. The short version is they were assuring DMARC alignment via either SPF or DKIM, now they are requiring DKIM. DMARC and other validation services need to be used; we need to stack the deck to help the end-user, and we need to not loose site of the fact that the user still has skin in the game.

Google should be applauded for ‘owning’ the issue and requiring DKIM to qualify for the blue checkmark status. It’s a little more effort to implement, but ensures protection against phishing and email spam. The blue checkmark is something that should mean something from a security perspective.