91. When Security Hits a Rough Patch
Here are a few highlights from each article we discussed:
- The Windows Print Spooler, the piece of software responsible for managing printing on Microsoft Windows, has a remote code execution vulnerability that rather trivially lets attackers execute code with system privileges. This, naturally, is a big problem.
- What makes this huge is that it’s rather trivial to execute and almost all machines will have the print spooler running, even if they are not even hooked up to a printer. The print spooler is required to print on locally connected printers as well as networked remote printers so almost every machine will have it running if they want to print. Proof-of-concept code was publicly released and quickly spread making this super easy to exploit for the skiddie crowd.
- So far the impact of this attack has mostly been organizations rushing to patch, then finding that the patch actually breaks some of their networked printers. Organizations can’t just disable printing—even though it is 2021 and we all wish they would—but yeah so this is just out there in the wild. My guess is it’s already being used by some ransomware groups, but I haven’t seen that yet.
- After this vulnerability was revealed publicly They dropped a patch on their usual patch Tuesday as well as dropped an advisory containing workaround steps that basically come down to disabling printing.
- Unfortunately Microsoft’s first patch was circumventable and the developer behind Mimikatz showed as much within 12 hours of the patch dropping. Everything around the print spooler is being combed over now since this isn’t the first big bug even these last two months for the spooler. Printing it turns out is a little difficult to secure.
- The PoC drop then pull back was the initial oh crap moment. I think we’re all so fatigued from the ransomware epidemic that another new, high-profile, easy-to-exploit vulnerability on a weekend wasn’t what everyone wanted to have to deal with right now. The subsequent patches were just disappointing I’d imagine for Windows admins everywhere. InfoSec Twitter has been its naturally snarky self through all of this.
- Update the patches and follow the steps for Microsoft’s advisory. If you don’t need printing, definitely disable the printing service. And really we all hate managing printers anyways so just convince your management to lease a managed networked printer or two with techs you can just call because otherwise you’ll eventually pull an Office Space if you manage printers long enough.
- Kaseya is a software that managed service providers use to, well, manage their services. So it gives them access into their customers’ environments to manage things like provisioning and patch management, firewall rules, networking and routing, etc. So as you can imagine, it’s kind of the keys to the kingdom. A lot of small and medium sized companies, and even some larger ones, use managed services for some to all of their IT operations, and a lot of MSPs use Kaseya or one of its competitors to efficiently carry that management out.
- First of all, gotta love the Friday timing (the incident occured on July 2nd). What a crap move, like, isn’t it bad enough that you’re launching a ransomware attack, but you’re doing it on a Friday too…but I guess we shouldn’t expect much in the way of kindness from ransomware actors. At any rate, the malicious code was timed to activate on July 2nd, which is why that date is the anchor point for discussing this event, but of course there was groundwork that had to be laid before then. As we all know at DomainTools, adversaries do quite a bit of infrastructure preparation before whatever the big explosive event is.
- While this was a kind of supply chain attack, and lots of folks will naturally and rightly compare it to SolarWinds, it actually was staged in a very different way. Whereas in SolarWinds the attackers were able to get into the build system and infect the SolarWinds software itself, in this case with Kaseya, the initial vector was by exploiting a couple of zero day vulns. This lets them bypass authentication and run arbitrary commands. They did this, by the way, against on-prem VSA servers. So you have malicious actors with pretty much the keys to the kingdom. While this was a ransomware event, if the motivation had been espionage, intellectual property theft, or any number of other malicious activities, this would have facilitated those as well. But this was the access they needed to infect endpoints with the ransomware that went active on July 2.
- Yeah, no burying the lede here; this was REvil. Unlike some kinds of campaigns, there wasn’t any real effort to hide what group was behind this one.
- Kaseya did what we’re seeing most companies do these days, which is a bit of a silver lining to the dark clouds of the ransomware epidemic: they were pretty forthcoming about what happened, what they were doing about it, and what their customers needed to do about it (what they needed to do, by the way, was shut down their on-prem Kaseya VSA servers, and Kaseya also shut down the SaaS VSA infrastructure. They also had a statement about the scope of the incident, at least as of the time of their writing last week, which was around 60 Kaseya customers. Now, keep in mind that they make products for managed service providers, so those 60 or so Kaseya customers represent more like 1500 end-user businesses.
- Kaseya engaged Mandiant right off the bat. This was a good move. Mandiant must be just exploding these days, and rightly so in that they have earned their good reputation in this business. It was interesting to me that Kaseya said this, rather than “we’ve engaged a good IR team” or something generic like that. Clearly the thinking in at least their PR department, and probably many companies, is that it’s beneficial to your messaging to name-drop Mandiant.
- It’s really hard to guess if Kaseya will pay the demand. They’re damned if they do and damned if they don’t. I’m really glad I don’t have to make the decision. I imagine they are listening to a lot of different viewpoints, from their customers the MSPs and from the downstream customers of those MSPs. The pressure must be enormous.
- The MSP is a force multiplier for any malicious actor who can compromise one, but the MSP vendor is a force multiplier on top of a force multiplier. I guess it’s a force-squarer. We’re going to see more of this down the road. SolarWinds and now Kaseya are not the last of these, unfortunately. This is part of the reason why the stakes of whether or not Kaseya pays the ransom are so high. A denied payment would be a strike against the viability of these sorts of attacks in the future. We’ll have to see what happens, but unfortunately I’d pretty much bet the ranch that we’ll see more attacks either on MSPs directly or on their suppliers.
Two Truths and a Lie
Introducing our newest segment on Breaking Badness. We are going to play a game you are all likely familiar with called two truths and a lie, with a fun twist. Each week, one us with come prepared with three article titles, two of which are real, and one is, you guessed it, A LIE.
You’ll have to tune in to find out!
This Week’s Hoodie/Goodie Scale
A Thing of Shreds and Patches
[Chad]: 9/10 Hoodies
[Tim]: 9/10 Hoodies
An Unnecessary REvil
[Chad]: 9/10 Hoodies
[Tim]: 9/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included on our podcast recap. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!