The ongoing voyages of the Federation Support Ship USS [REDACTED]
First Officer’s log, Terrestrial date, 20230424 Officer of the Deck reporting.
The captain, showing extraordinary grace and professionalism, rendered assistance to the crippled [REDACTED] ship, towing them out of the debris field and making sure that at least their life support and power systems were working satisfactorily before sending a message to their homeworld to have one of their own ships come and tow them home. It was above and beyond, considering how they had tried to ambush us after a faked distress call. But it was also in accordance with the Federation’s highest principles.
Our hack to disrupt their weapon systems had been surprisingly effective and the cascade of failures unexpectedly took out nearly half the associated systems. It was likely we would have to face an inquiry into the event, since using a communications hack was, at least technically, against protocol. However, we had been ambushed and the non-standard solution disabled the attacking ship without causing any casualties.
Hopefully, the possibility of the [REDACTED] ship suffering a warp core breach as a result of the hack, and being completely obliterated as a result, would not be raised.
With that immediate issue solved, we were able to bring our own drive back on line and resume course to return the embarked diplomatic team to their point of origin.
The unexpected delay, however, had the ship running slightly behind schedule to arrive at another conference. That meant another dash at near maximum warp to reach the conference site, where the captain and several senior officers would be presenting. It was an annual event, but the vagaries of interplanetary conference schedules meant it didn’t always happen at the same time each year.
But it wasn’t a problem. In fact, it was barely an inconvenience.
The USS [REDACTED] would be there, ready to share what we do and how we do it.
Breaking that 4th wall
It’s been nearly a year since starting the Voyages of the USS Redacted, with the 3rd issue making a reference to a certain security conference in San Francisco. That being RSAC, of course, the timing of which has me AT RSAC as this is posted. While I won’t be tweeting from RSAC, I will BE there with my personal stash of Sightglass coffee, a hand grinder, and an AeroPress. If you’re a regular reader and manage to make it to the show, stop by the booth and say you’re looking for the Officer of the Deck. If you’re a coffee drinker, I’ll do my absolute best* to make sure you get a sample from my secret stash.
Who didn’t see this one coming?
What happened
It has recently surfaced that there have been at least 3 instances of employees at Samsung Electronics sharing proprietary information with ChatGPT, effectively leaking that information to the outside world as a whole. In one case, for example, the employee shared problematic code with ChatGPT looking for a solution. Unfortunately for Samsung, there is no practical way to recover or delete the exposed code.
Why it matters
While Samsung was the “victim” in this case, it could easily have been anyone. ChatGPT can generate usable code, and probably do a fair job of troubleshooting broken code, but that requires sharing said code samples with ChatGPT. Which means sharing the code with ChatGPT and, at least potentially, its entire user base.
It’s easy to forget that tools like this are not private and anything you share with it is likely to wind up in unexpected places. It’s like posting a code sample to any of the public forums and asking for help. Just because the helper isn’t Human doesn’t mean it’s not a public share.
There are safe ways to do it, of course. But sharing your proprietary code with a world-accessible chatbot is not it.
What they said
This story got plenty of attention.
You’ve got automatic updates turned on, right?
What happened
Google has patched two vulnerabilities that were being exploited in the wild, including one with their GC2 (Google Command and Control) red-teaming tool that was being actively leveraged by Chinese persistent threat actor APT41. The other, identified as CVE-2023-2136, that was rated as a high severity, but has not yet (as of this writing) had a CVSS score assigned.
These issues have been addressed for Mac and Windows and will be addressed shortly for Linux, and may be available as you read this.
Why it matters
Chrome is, by far, the most widely used browser in the world, which makes it an obvious target for threat actors the world over. Fortunately, Google’s been responsive when issues come up and the automatic update feature can keep Chrome up to date without any real effort on the user’s part.
As browsers have evolved over the years from simple HTML parsers to the main interface for myriad applications, it’s no surprise that threat actors focus so much attention on them. It’s a testament to the skill and persistence of the developers behind our main browsers that there aren’t more exploits against them. The thing is we can expect to see more vulnerabilities come out, and exploits come up, as threat actors look for new and exciting ways to ply their trade.
What they said
A vulnerable Google naturally gets people talking.
A threat by any other name would be as bad
What happened
Microsoft has introduced a new naming taxonomy for threat actor groups using weather phenomena as its theme. For example, threat actors associated with Russia are variations of Blizzard, while Chinese groups carry Typhoon names, and Iranian groups get names including Sandstorm. This replaces their existing taxonomy and is presented as an effort toward consistent naming to add some clarity about the origin of the many active threat groups.
Why it matters
The idea of having a single naming convention for threat actors isn’t actually bad. The trouble is getting everyone on the same page, when different researchers, agencies, and organizations all have their own names. There are probably people who’ll ignore these names specifically because Microsoft proposes them. There’s also the issue of including both Region and Agenda (financial, vs destructive, vs whatever) in the convention when you can have multiple elements in the same group. If you’ve got two out of Iran, for example, but one’s focused on ransomware and the other goes after infrastructure, which name takes precedence?
It’s not a bad idea, but I seriously doubt it’ll catch on outside Microsoft’s security ecosystem. While I wouldn’t suggest someone should be in charge of naming threat groups, it seems likely that some non-commercial entity like, say, NIST, MITRE, or one of the international CERT teams would be the more likely source for common names.
Also, someone should probably tell the good folks over at MS that a Tsunami is a marine phenomenon and not weather related. Just sayin’.
What they said
There’s been a storm of attention for this one.
*: My personal coffee stash is subject to running out, and I can’t guarantee I’ll be able to brew you a cup if you come by. Because, well, we all know how these conferences go. This is a ‘best effort’ kinda thing and all meant in good fun.
___________________________________________________________________________________________________________________________
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
