The ongoing voyages of the Federation Support Ship USS [REDACTED]
First Officer’s log, Terrestrial date, 20230710, Officer of the Deck reporting.
The [REDACTED] reached her next destination without further incident, with a mission plan that involved picking up some research samples for a university closer to the Federation’s core, while dropping off some supplies, a spare heavy shuttle, a few kilos of refined dilithium, and a staff assistant who had been assigned to the Federation administrative center.
While we wouldn’t be in the system long, being scheduled for barely 36 hours, we did have time to authorize shore leave for some of the crew. We did not, however, expect to be contacted by another ship in orbit with a request to purchase supplies from our armory.
The executive officer took the call from, to all appearances, was a century-old [REDACTED] class ship that, on some levels, was similar to our own ship’s design, though still quite distinct with the class’s trademarked roll-bar mounted photon torpedoes and main phaser arrays.
“Hi, yeah. Good to meet you. We’re looking to pick up some class 5 photon torpedoes if you have any. Maybe a dozen? And a phaser plasma coupling if you can spare one.”
The ship’s captain, on screen, was not in any sort of Federation uniform. In fact, a quick check of the database showed that the ship, while very much a Federation ship, was not in the registry.
“An interesting request, Captain, but, well, who are you?”
“Oh, sorry for the missed introductions! You can call me Captain Max, and this is the Privateer warship Dauntless. Again, pleased to meet you. Now, about those torps?”
Wasn’t this the plot for a Bond film?
What happened
Multiple remote code execution (RCE) bugs have been identified in Contec’s SolarView Series software. The SolarView application is intended to provide monitoring capabilities for solar power installations at scale. The flaws affect internet facing systems, and threat actors behind the Mirai botnet, and others, have already been seen exploiting the flaws.
Why it matters
Internet of Things (IoT) and Operational Technology (OT) devices can be notoriously difficult to maintain. Updating configurations, installing patches, and general maintenance are often an afterthought when they are thought of at all. The situation can be better with the more expensive and complex OT devices, but they’re often subject to change management processes and operational considerations that make patching a chore.
The issue here is that the affected devices have no real business being exposed to the open internet. While it’s unlikely that a compromise will lead to a lot of damage, the fact is they shouldn’t be exposed in the first place. This kind of isolation is one of the reasons that IoT and OT devices can often get away with their ‘set it and forget it’ configurations. They’re kept out of harm’s way. But when they’re not, we get cases like this where exposed systems are vulnerable and the vendor remains a bit lax in providing patches.
What they said
Plenty have been shedding light on this one.
Switch – it off.
What happened
A vulnerability has been discovered in Cisco Nexus 9000 series switches that could potentially let an attacker read or modify encrypted traffic on devices set in ACI (Application Centric Infrastructure) mode. Details of the vulnerability are sparse, but Cisco has not released a patch as of this writing and is recommending customers disable vulnerable switches.
Why it matters
The advisory does not specify much about the potential attack, and only mentions an attacker possibly being able to use “cryptographic techniques” to read and possibly alter traffic on the fabric. Exactly how hard that would be is an interesting question, because it should be hard to break the encryption even if an attacker can position themselves to access the traffic.
That said, if Cisco is saying they recommend affected users down check the systems in question, then they probably have reason to believe there’s a good chance of threat actors actually exploiting this. So, until they have a patch, follow the advisory and turn off the problem children.
What they said
Not switching off are the news outlets, who have covered this story in detail.
We can totally trust everything in the app store, right?
What happened
Researchers have found two malicious applications in the Google Play Store that pose as file managers, while being loaded with spyware that sent data back to China. Both applications were attributed to the same developer on the Play Store, and both have been removed by Google.
Why it matters
If a threat actor can get you to install their payload for them, their job becomes orders of magnitude easier. If they can put their malware into a publicly available application marketplace, all the better. While most marketplaces do a solid job of policing their offerings to keep malware out, there have been quite a few instances of malware slipping through in the guise of a legitimate program.
For enterprises providing kit to their employees, it’s easy to restrict them to acceptable applications that have been vetted and tested to be clean. For private users, and organizations that allow BYOD (Bring Your Own Device) in their environment, the situation is a little more complicated. These users often balk at having the office control their private devices, which means they have to make sure they’re keeping their own systems secure.
There are relatively easy ways to avoid downloading suspect applications, starting with only downloading from known reputable developers.
What they said
This one got plenty of attention.
___________________________________________________________________________________________________________________________
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
