The ongoing voyages of the Federation Support Ship USS [REDACTED]
First Officer’s log, Terrestrial date, 20230619, Officer of the Deck reporting.
It took some time at our standard cruising warp speed to reach the first of the outer colony worlds we’d been dispatched to, with the ship operating normally and the crew settling into the usual routines of a long-range, low-impact, mission. While there was something to be said for excitement, we weren’t a front-line ship and were not built for the kind of excitement those ships routinely encountered. Recent events notwithstanding.
The only real challenge with this mission was that some of the cargo was fragile, some was perishable, and some was both. In each case, it was material that could not be effectively replicated on site and required a physical delivery. Which was the case with our first two deliveries.
In the first case, we delivered a cargo of medical supplies that were running short on a remote colony world. While the colony was not in immediate danger, which would have justified our sustaining maximum warp, or Starfleet sending a high-warp courier ship, the medical condition in question was unique to that world and the medication could not be replicated.
The second shipment was destined for a small research station only a few parsecs from the colony. The system itself was quite unusual, being a quasi-binary with a K class main star orbited by a brown dwarf that was, itself, accompanied by a similar mass companion with a density that suggested it was part of a shattered neutron star.
The station was in the trailing Lagrange point of the pair and was expressly placed to study the apparent fragment. Our cargo was some specialized, fragile, equipment they required for their studies. Though, other than the navigational challenge of needing to use the Impulse engines because the gravitational gradients made it difficult to use the warp drive, the delivery was routine.
On the way to our third destination, however, we received a communication from the [REDACTED] which was still docked at the Starbase while they sorted out the newly minted AI that was living in their ship’s computer. Specifically, it was the AI itself, the holographic image looking mildly distraught on screen, asking to speak to the leader of our integration team.
After a nodded acknowledgement from the Captain, comms responded “Please stand by, [REDACTED]. We’ll fetch him for you.”
Fix it, then talk about it.
What happened
Fortinet recently released patches for FortiOS firmware versions 6.0.17, 6.2.15, 6.4.13, 7.0.12 and 7.2.5 which, amongst other things, addressed a critical vulnerability tracked as CVE-2023-27997. The patches were released ahead of the flaw’s disclosure, giving threat actors less time to analyze the threat and potentially develop an exploit based on that information.
Why it matters
Fortinet has had to deal with a number of issues recently and it’s good to see them proactively addressing them, rolling out updates, supporting their customers, and responsibly disclosing vulnerabilities through the usual public channels.
As for the question of whether it’s “normal” for a vendor to have a patch ready before releasing information on a vulnerability, the answer is yes. Unless there’s a case of active exploit in the wild, where releasing information and including compensating controls while they work on the fix, it’s not at all uncommon for a vendor to make sure there’s a fix before they let the world know something is broken. After all, the first thing that happens when a vulnerability is announced is someone tries to create a PoC that can exploit it – or to weaponize an existing PoC.
What they said
This one got plenty of attention.
The MOVEit thing may be bigger than it seems?
What happened
In response to the MOVEit exploitation, the U.S. Cybersecurity and infrastructure Security Agency (CISA) is supporting a number of US government organizations that have apparently been affected. While the exact number is not stated, which is normal, it is notable that they are now involved. Regardless of whether an organization is covered by CISA mandates, if they use the MOVEit application, they are advised to take appropriate action immediately.
Why it matters
The MOVEit attacks have been attributed to the CLOP ransomware gang, with some supposition that, given the recent targets, the attacks are geopolitically motivated. And they may be. Even if there is no direct involvement by State level intelligence agencies, cybercriminal groups have been known to have their own politically motivated agendas. After all, even if you’re a criminal, you’re less likely to catch flack from your local law enforcement agencies when your victims are all in a “hostile” foreign country.
Regardless, there’s two takeaways here. 1st, when CISA releases an advisory it’s a good idea to follow it if you use the affected software. Whether you have to or not, it’s good advice. 2nd, there is still a place for encrypting files at rest. After all, it is far less damaging for a file to escape when the attacker can’t actually do anything with it. Considering there have been commercial and open-source file encryption options for decades, there’s no reason – other than convenience – to not use them.
Old school, I know, but GPG (Gnu Privacy Guard) is still a thing*.
What they said
*: Yeah, I know, managing GPG/PGP keys is still annoying, but there are still use cases where encrypting files and digitally signing them is worth the effort.
So first fake repositories, and now fake developers?
What happened
Research has revealed that an unidentified threat actor has taken the practice of creating a malicious library and posting it to a public repository to a new level, by creating a fictional security company. The deception includes the fake company, and a range of fictional developer profiles to help “flesh out” the ruse.
Why it matters
One of the things that can make malicious libraries easy to identify is that there’s often not a lot of there there, besides the package itself. Now, there is at least one threat group who’s putting time and effort into making their malicious package look much more legitimate. It’s the social engineering aspect that’s usually missing.
Given our own recent research on AI Package Hallucinations, we could be seeing a new wave of more sophisticated software supply chain attacks. If threat actors were to take a hallucinated finding and add a layer of legitimacy with a faked development team? Yeah. That has the potential to be very “not good.”
This comes back to the one thing you need to be doing whenever you are using development libraries from an open repository – vetting your code. Start with making sure the source is legitimate, and then review the code itself to make sure there’s nothing suspect in there. It may never be 100% possible to guarantee a package doesn’t have something buried deep inside it, but the more work developers do up front, the harder it is for threat actors to make them inti victims.
What they said
There’s nothing fake about the concern in the industry.
___________________________________________________________________________________________________________________________
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
