Adversary Emulation w/ Carlos Perez – PSW #789

Developing reliable checks for vulnerabilities that are both accurate and safe (i.e. don't cause the process or system to crash) is tricky business. Bishop Fox has highlighted their work creating such a check for one of the recent FortiGate vulnerabilities. You can download the checking tool here: https://github.com/BishopFox/CVE-2023-27997-check. There is still a chance that checking for the vulnerability can cause the system to crash. Perhaps a better way is to query your systems for the latest version of software/firmware, then see if its the latest, then cross-reference that with known CVEs. While safer, you rely on the data being accurate vs. actually checking for the vulnerability. My advice has always been to use both methods.

This post was very well-written. It documents the methods and findings of the researchers who were able to enumerate all the controller devices and install malicious firmware. I found it interesting that the company also provided the researchers with a new (but older) product to test as the version tested was claimed to be a development board. The researchers found the same problems. While I would love to be able to control, and get more data, from HVAC equipment in my home, the security of these products has to be up to par. The product in question was used in an apartment building, so you can imagine the impact of attacks. Don't like your neighbor? Maybe someone freezes them out or tries to melt them. Unethical for sure, but shows the real-world impacts of poor security in devices.

This is important to read and understand: "the FDA mandates that medical device manufacturers submit "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits" and to "design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure." This includes patching "on a reasonably justified regular cycle" and as-soon-as-possible patches for serious vulnerabilities found outside of the normal patch cycle." - They also have to include an SBOM. This impacts OSS as well, it could mean we get more secure OSS and medical devices. It could also be a barrier to entry to creating OSS as people may not want to deal with the headache. This is why it is important for OSS software groups, such as the Linux Foundation, to continue to work on projects that make it easy for developers to create SBOMs. IN fact, you may not even have to worry about it, it will just happen.

"The plugin uses a variety of methods to perform this detection. Previously, one of the methods used in some cases was to execute the java runtime binary with a -version argument and read the output. This method has been removed from the plugin, and replaced with different methods that provide equivalent detection." - This is plugin that executes locally, so an attacker would have to replace the Java command with a malicious version, then that version would be executed when the system is scanned with higher privileges. This issue has been fixed, and I don't believe we need to change how we do vulnerability management as a result.

I believe attack surface management is key to mitigating the risk posed by exposed services that were discovered: "We discovered nearly 250 instances of web interfaces for hosts exposing network appliances, many of which were running remote protocols such as SSH and TELNET," Censys said. "Over 15 instances of exposed remote access protocols such as FTP, SMB, NetBIOS, and SNMP were also found running on FCEB-related hosts." Censys also discovered multiple servers hosting MOVEit transfer, GoAnywhere MFT, and SolarWinds Serv-U managed file transfer platforms, known attack vectors in data theft attacks." - This must be part of your organization's strategy, CISA mandates it for federal agencies, hopefully there is work being done to remmediate.

Why is it for science? This particular vulnerability happens during the DXE phase, and is "closed off" once DXE ends. An attacker would need another vulnerability to exploit this vulnerability. Interesting how it was found in the reference implementation, EDK II, my co-workers audited that code some time ago and kill a ton of bugs. This could be important later. Also, I am glad people are looking at these vulnerabilities!

The opening paragragh will spark some debate: "We all know the drill when it comes to online security — something you know, and something you have. But when the “something you have” is a two-factor token in a keyfob at the bottom of a backpack, or an app on your phone that’s buried several swipes and taps deep, inconvenience can stand in the way of adding that second level of security. Thankfully, this “2FA Sidecar” is the perfect way to lower the barrier to using two-factor authentication." - The project is super cool, rather than digging out your phone you can build this and press a key to generate the auth codes. The ESP32S3 was used, along with some other hardware, as described in the post.

"Because BlackLotus integrates Shim and GRUB into its implantation routine, Linux administrators should also be vigilant for variants affecting popular Linux distributions." - Whoa, interesting to think about this idea. This is a "why didn't I think of that" moment: "The Linux community may remove the Microsoft Windows Production CA 2011 certificate on devices that exclusively boot Linux."

I helped write this one