We provide an overview of the MS-ISAC K-12 Report including where K-12 organizations stand in terms of their cybersecurity resources.
Daily Archives: November 14, 2022
A Digital Red Cross
The International Committee of the Red Cross wants some digital equivalent to the iconic red cross, to alert would-be hackers that they are accessing a medical network.
The emblem wouldn’t provide technical cybersecurity protection to hospitals, Red Cross infrastructure or other medical providers, but it would signal to hackers that a cyberattack on those protected networks during an armed conflict would violate international humanitarian law, experts say, Tilman Rodenhäuser, a legal adviser to the International Committee of the Red Cross, said at a panel discussion hosted by the organization on Thursday.
I can think of all sorts of problems with this idea and many reasons why it won’t work, but those also apply to the physical red cross on buildings, vehicles, and people’s clothing. So let’s try it.
Stories from the SOC: Fortinet authentication bypass observed in the wild
Executive summary:
Fortinet’s newest vulnerability, CVE-2022-40684, allowing for authentication bypass to manipulate admin SSH keys, unauthorized downloading of configuration files, and creating of super admin accounts, is put a big target on the back’s of unpatched and exposed Fortinet devices.
An AT&T Managed Extended Detection and Response (MXDR) customer was involved in a true positive compromise that was discovered through a threat hunt initiated off an Intrusion Protection System (IPS) alert from Fortinet. With coordination between customer and MXDR and the customer’s network and security teams, the threat was remediated and contained, and the vulnerable devices were patched.
Investigation
The initial investigation began during a tactical check-in with the customer, who mentioned an investigation regarding an IPS detection for two IP addresses that were attempting the authentication bypass exploit.
If we pivot to the event, we can see Fortinet created detections for potentially unauthorized API requests to the cmdb filepath.
Through Fortinet’s advisory on the vulnerability, we learned that potential malicious activity would originate from a user Local_Process_Access and would utilize the Node.js or Report Runner interface. Reports indicate that some of the handlers for API connections check certain conditions, including IP address being a loopback address and User-Agent being either Report Runner or Node.js. Off that information, we’re able to turn our attention to potential true positives that weren’t picked up by the IPS. Doing a quick filter on the Local_Process_Access user produced some interesting events:
This doesn’t look good. The first event we can see the attacker manage to successfully download the Local Certificate:
This allows the attacker to see certificate information such as email address for the certificate owner, IP address of the Fortigate, company name, location where the Fortigate was installed, and other sensitive details. These local certificates a generated and provided to the Certificate Authority (CA) for environment trust.
Shortly after, the attacker managed to download the system config of the Fortigate:
Finally, a few hours later they managed to upload a script and run it to create a super_admin user:
This is where the observable activity ended from the Local_Process_User and newly created admin account. Remediation began at this point.
Response
After discovery of the administrator account, a network administrator was urgently contacted and was able to remove the account. During the remediation process, the network administrator observed that the management port’s external interface had HTTPS open, which is likely how the attacker gained the initial foothold. It’s believed the super_admin account that was created was to be used as a backdoor in case the device was patched, as no activity was seen from the account after creation. The script used by the attacker was not recovered, but following its upload and execution it was likely just used to create the admin account.
Importance of patching:
Fortinet did release a patch the day this vulnerability was announced, as well as mitigation steps if patching was not immediately feasible. One of the mitigation steps was to disable HTTPS/HTTP on the external facing management interface if not needed. The Fortinet Fortigate in question was the only device that had the management interface open, and thus allowed the attacker an easy path to exploit the vulnerability.
As a result of the detection of this activity through threat hunting through customer logs, additional correlation logic was created for the USM Anywhere platform to detect future compromises.
Mass Email Extortion Campaign Claims Server Hack
Threat actors claim they’ll destroy victims’ reputation if they don’t pay
UK Shoppers Lost £15m+ to Scammers Last Winter
How Cisco keeps its APIs secure throughout the software development process
Software developers know not to reinvent the wheel. So, they lean on reusable micro-services – and their corresponding application programming interfaces (APIs) – as building blocks for application components. “Developers want to focus on the added value they can bring instead of rebuilding things that have great solutions out there already,” says Grace Francisco, vice president of developer relations, strategy, and experience at Cisco. “APIs make that easy for developers to consume.”
And they have been consuming: Nearly 90% of developers use APIs in some capacity, according to a 2020 SlashData survey.
Ukrainian CERT Discloses New Data-Wiping Campaign
varnish-7.1.2-1.fc37 varnish-modules-0.20.0-4.fc37
FEDORA-2022-0d5dcc031e
Packages in this update:
varnish-7.1.2-1.fc37
varnish-modules-0.20.0-4.fc37
Update description:
New upstream release: A security release. This release includes fix for CVE-2022-45059 (VSV00011) and CVE-2022-45060 (VSV00010). From the upstream release notes:
VSV00010 Varnish Request Smuggling Vulnerability
Date: 2022-11-08
A request smuggling attack can be performed on Varnish Cache servers by requesting that certain headers are made hop-by-hop, preventing the Varnish Cache servers from forwarding critical headers to the backend. Among the headers that can be filtered this way are both Content-Length and Host, making it possible for an attacker to both break the HTTP/1 protocol framing, and bypass request to host routing in VCL.
VSV00011 Varnish HTTP/2 Request Forgery Vulnerability
Date: 2022-11-08
A request forgery attack can be performed on Varnish Cache servers that have the HTTP/2 protocol turned on. An attacker may introduce characters through the HTTP/2 pseudo-headers that are invalid in the context of an HTTP/1 request line, causing the Varnish server to produce invalid HTTP/1 requests to the backend. This may in turn be used to successfully exploit vulnerabilities in a server behind the Varnish server.
CVE-2021-38828
Xiongmai Camera XM-JPR2-LX V4.02.R12.A6420987.10002.147502.00000 is vulnerable to plain-text traffic sniffing.
CVE-2021-38827
Xiongmai Camera XM-JPR2-LX V4.02.R12.A6420987.10002.147502.00000 is vulnerable to account takeover.