Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-40134PUBLISHED: 2023-01-30An information leak vulnerability in the SMI Set BIOS Password SMI Handler in some Lenovo models may allow an attacker with local access and elevated privileges to read SMM memory.
CVE-2022-40135PUBLISHED: 2023-01-30An information leak vulnerability in the Smart USB Protection SMI Handler in some Lenovo models may allow an attacker with local access and elevated privileges to read SMM memory.
CVE-2022-40136PUBLISHED: 2023-01-30An information leak vulnerability in SMI Handler used to configure platform settings over WMI in some Lenovo models may allow an attacker with local access and elevated privileges to read SMM memory.
CVE-2022-40137PUBLISHED: 2023-01-30A buffer overflow in the WMI SMI Handler in some Lenovo models may allow an attacker with local access and elevated privileges to execute arbitrary code.
CVE-2022-48006PUBLISHED: 2023-01-30An arbitrary file upload vulnerability in taocms v3.0.2 allows attackers to execute arbitrary code via a crafted PHP file. This vulnerability is exploited via manipulation of the upext variable at /include/Model/Upload.php.
User Rank: Ninja
6/27/2019 | 2:10:54 PM
I agree with this assertion, look at what we are doing (US):
I mean at some point, we had to know that they were going to reverse engineer this virus and unleash a Cyber-Apocalypse on the US. I am not so sure if our utility infrastructrure will be able to handle it . Also, remember, they have tried this already with Triton, thankfully this was thwarted most recently https://ubm.io/2IFcbA0 (Triton Attack). This is what "FireEye" said about the attack - https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html
The TRITON malware contained the capability to communicate with Triconex SIS controllers (e.g. send specific commands such as halt or read its memory content) and remotely reprogram them with an attacker-defined payload. The TRITON sample Mandiant analyzed added an attacker-provided program to the execution table of the Triconex controller. This sample left legitimate programs in place, expecting the controller to continue operating without a fault or exception. If the controller failed, TRITON would attempt to return it to a running state. If the controller did not recover within a defined time window, this sample would overwrite the malicious program with invalid data to cover its tracks.
This sounds very similar to Stuxnet (we made this), we need to initiate a "a stand-down" order on the attacks we are initiating from the US to other OCONUS locations or this situation will only get worse. A word to the wise, I think we have been warned enough and we continue to play with fire.