First Officer’s log, Terrestrial date, 20230529 Officer of the Deck reporting.
Working aboard a Starfleet vessel, you became used to the ship’s computer acting much like a part of the normal organic crew. While they could feel “alive” in many respects, they were technically just advanced expert systems that had been well-designed to respond to what the crew wanted as much as possible, even when what they said wasn’t exact. But it worked both ways. Crew members came to know the quirks of their own ship’s computer and learned how to talk to it in a way that got the results they were after.
For example, some systems needed you to specify exactly what kind of tea you wanted, and what temperature you wanted, or you were apt to get something that was only vaguely tea-like delivered at a temperature that could vary somewhere between liquid nitrogen and molten lead. With a more flexible system, you could wake up, roll out of your bunk, and grumble “Coffee. Now.” To which the system would respond with a perfect simulacrum of a pour-over delivered straight from the replicator to the terminal in your cabin.
The trouble started when a computer system became truly sentient. The Federation charter included all life, which had long been established to include artificial life forms. Which meant androids and sentient computers were, legally, afforded the same rights as anyone else. Unfortunately, that sometimes led to problems.
There was a relatively well-known case where someone aboard Starfeet’s then-flagship had designed a holodeck personality so complex it crossed from expert system to sentience. Worse, it managed to affect the ship outside the sandbox of the holodeck system. While they initially stored it away, it managed to come back, none to happy about the long-term storage, and was only placated by being duped into an even deeper simulation where it believed it had escaped.
Ultimately, the incident ended about as well as anyone could have expected and information on it has subsequently been on file in the library computer of every Starfleet ship and installation ever since.
This all led to some rather convoluted and confusing rules regarding how sentient programs were to be treated by the Federation. Looking at those rules in the context of our conversations with the [REDACTED]s computer, the situation became . . . problematic.
To the point that, when we finally spoke to the ship’s XO after completing our initial investigation, our answer amounted to “Well, we have some good news, and we have some bad news…”
The things that get left in memory
What happened
Researchers have discovered a vulnerability in the open-source KeePass password management application that allows a malicious actor, with access to the host, recover the master password for the KeePass Password Safe. If successful, this technique would give a threat actor access to all the stored credentials. The vulnerability is tracked as CVE-2023-32784 and KeePass expects to have a patch released by early June.
Why it matters
Password managers have a lot of advantages, especially in allowing users to have different high-quality passwords for each site or service they use, while only requiring them to remember a single master password to gain access to all of them. The downside, of course, is if their keyring is corrupted, lost, or otherwise inaccessible, they lose access to all of the stored sites until they can recover from a backup. Assuming they kept a backup. And worse, if access to the master password for the vault is compromised, as it would be with this KeePass vulnerability, and which we’ve seen happen with other commercial products, the entire vault is open to the threat actor.
There’s a reason a lot of security professionals will insist on implementing a good multi-factor authentication system. MFA goes a long way toward mitigating the threat of compromised passwords, whether they’re in Human memory or a vault. Even if the attacker gets the password, they still don’t have the other factor needed for access.
Personally, I rely on a “key+site” model. Effectively I have the same “key” for each site (e.g. “MyPass4+”) and a site part that’s unique (e.g. “Netflix”). So from the example, I’d have MyPass4+Netflix or MyPass4+Reddit – which satisfies the length and complexity requirements. Now, in practice, my personal combinations aren’t this simple, but they are easy to remember and with MFA, functionally secure.
What we said
The Voyager18 team over here at Vulcan Cyber was all over this one.
I can understand them “Going Postal*” over this one
What happened
It was recently revealed that an incident in late December 2022 affected approximately 450 United States Postal Service employees, leading to their paychecks being diverted as the result of a complex phishing and fake website scam. The employees were enticed to enter their credentials in malicious websites, which then captured the usernames and passwords and used them to access the user’s payroll site to redirect their pay.
The scheme had apparently been underway for several months before it was identified and stopped.
Why it matters
This reads like a relatively classic attack pattern, with threat actors creating fake versions of legitimate sites to lure targets into revealing their credentials. Unfortunately, this is another case where using multi-factor authentication would have dramatically reduced the risk for users. Given that the USPS is a Government agency, and the US Government does know how to implement secure multi-factor authentication, it’s a wonder why they didn’t.
The Postal Service has had several cyber security issues over the years which may point to more than a little organizational inertia, likely stemming from a large bureaucracy. It probably didn’t help that some high-level policy changes from the recent past shifted priorities so cyber security issues may not be getting the attention, or budget, they deserve.
What they said
There’s plenty to post about here.
*: With apologies to my friends who work for the US Postal Service.
OAuth is great if you don’t mess it up
What happened
Recent research has revealed a flaw in the OAuth implementation used by Expo open-source development framework. The vulnerability, tracked as CVE-2023-28131, was quickly corrected by Expo. This flaw had the potential to affect hundreds of sites that relied on the framework, but the rapid fix has dramatically reduced the risk.
Why it matters
Even with frameworks and libraries that make OAuth implementation a lot easier, it’s still a non-trivial challenge to do it securely. There are a lot of moving pieces and a lot of places where it’s easy to give more access or functionality than is really required. It’s good that Expo corrected this as quickly as they did, but it still points to how complex a task it can be. Developers implementing OAuth should really have a clear idea of what they’re doing, and what all the options mean before turning their applications loose in the wild.
What they said
Vulnerabilities get attention, and this one is no different.
___________________________________________________________________________________________________________________________
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
