The ongoing voyages of the Federation Support Ship USS [REDACTED]
First Officer’s log, Terrestrial date, 20230410. Officer of the Deck reporting.
As Engineering worked quickly to restore power, bringing basic sensors and communications back online only a few minutes after the captain told the [REDACTED] that we’d see what we could do, helm explained their idea for getting us out of this mess.
“Captain, we know the [REDACTED] integrate advanced components into their ships from wherever they can get them, right? They trade, buy, or steal whatever goes into their ships. Weapons. Warp drive. Reactor cores. Computers. Communications. Transporters. The works. They’ve got some talent for bodging it all together, but they don’t really understand how most of it works.”
The captain nodded, looking up at the main viewscreen as it wavered back to life and the other ship slid into frame. “They’re known for it. Yes. That’s what got them taken out of the integration we dealt with a few months ago. You think we can use that to our advantage?”
“I do, Sir. Look, see there?” Helm gestured to the opposing ship. “Those disruptor banks look like they came from a [REDACTED] warbird. That’s a pulse missile launcher the [REDACTED] have been selling for decades, and I think that’s a cluster of phaser banks that were used on a Federation runabout’s weapons pod.”
“Go on.”
“Same with the comms array there, and that deflector shield looks like a [REDACTED] light cruiser’s array. Point is, Sir, to get all those systems talking to each other, they’ve either got to have a first-rate translation system that works securely with all of them, or they took the easy way and just left everything wide open at the defaults.”
The captain’s expression changed to a sly smile. “You’re suggesting we can leverage that and hack their ship.”
“I’m suggesting we hack their ship.”
The captain then turned to Comms, trying to keep the amusement out of his voice. “Lieutenant, see if you can get our friends to open a data channel. I’ll leave the details to you.”
“Aye, Sir,” Comms responded, starting the ploy in motion.
Now where did I leave my keys?
What happened
In an effort to get ahead of potential threat actors after their private Secure Shell (SSH) key was exposed in a public repository, GitHub has rotated the exposed SSH private key. This will require people who relied on the key to update their access. Only the RSA SSH key was affected, and the key did not control access to company infrastructure or customer data. At this time, there is no indication that threat actors were able to abuse the key. Other secure methods, such as Git over HTTPS, were not affected.
Why it matters
Secure Shell has been a major part of secure communications for management, data transfer, and other functions for years. But key management has always been something of a challenge. Changing keys can be a minor headache for administrators and users, but the longer keys remain in use, the more likely they are to be exposed. Like they were here. On some levels, it’s good that these were exposed unintentionally and not as part of a breach, but it’s also bad on others that they were exposed unintentionally and not as part of a breach.
Fortunately, GitHub has been very transparent and evidently acted before a threat actor could find the exposed keys and abuse them. Kudos to them for both the transparency and their fast actions.
What they said
Even if the threat was averted, this still made headlines.
It’s becoming kind of a thing
What happened
The Advanced Persistent Threat (APT) group known as DeadBolt has again exploited vulnerabilities in QNAP devices to deploy ransomware attacks against organizations that have deployed QNAP equipment. This is the latest in a series of attacks against GNAP going back over a year, with this APT showing marked persistence against their target. The relevant vulnerabilities are tracked as CVE-2022-27597 and CVE-2022-27598, and patches are “under development” by the vendor as of this writing.
Why it matters
QNAP devices have suffered from multiple exploits over the last year or so, which must be a pain for them and their customers. The DeadBolt ransomware gang has been behind several of the attacks which begs the question of why this group is so focused on QNAP. There is an adage that when you find one vulnerability, it is often worth looking for more. And that may be what’s happening here. Or maybe they have acquired source code that makes it easier to find bugs. Or something. Regardless, it’s been a trying year for QNAP and their customers.
The takeaway, of course, is to keep your systems patched, deploy them according to industry and vendor best practices, and do whatever you can to reduce the risk imposed by internet-facing assets. Sometimes, unfortunately, after a history of vulnerabilities, that “best practice” may be to find a different vendor.
What they said
Unsurprisingly, this got a lot of attention.
The vulnerability that would not die
What happened
Threat actors are still able to find and exploit the Log4j vulnerability on unpatched hosts. The current wave of attacks has focused on threat actors using the exploit to gain control of a host, which then gets a proxyware application installed. The attacker gains a small but steady income from the proxyware service for the resold bandwidth. While the attack is less destructive than other potential malware, it can still subject the victim to increased costs and additional risks.
Why it matters
The Log4j vulnerability was patched over a year ago, which makes this a good (but sad) example of the long-tail effect. You’d think that by now, we wouldn’t be dealing with Log4j anymore, but there are still systems out there that remain vulnerable. Eventually, all of them will be either patched, retired, or compromised, and the long tail will run out. But until then, we can expect to see this keep playing out.
What is interesting in this one is that the attackers aren’t using the compromised hosts for conventional ransomware or related malware attacks but are dropping proxyware on the hosts. That’s something of a new business model for cybercrime that’s lower profit for the attacker, less disruptive to the victim, but also likely to go undetected for some time.
Though it does point out how shady some of the proxyware services can be.
What they said
As with all things Log4j, this had plenty of people talking.
___________________________________________________________________________________________________________________________
Want to get ahead of the stories?
- Join the conversations as they happen with the Vulcan Cyber community Slack channel
- Try Vulcan Enterprise for 30 days
