RADIUS/UDP Vulnerability Affects Multiple Networking Devices; Australia Directs Government Agencies to Assess Technology for Risk of Exposure to Adversaries; APT Threat Actors are Exploiting Vulnerabilities within Hours of Disclosure

The vulnerability was first made public a couple months ago. More details have now been made public. The issue is more of a protocol design issue, and the use of the MD5 hashing algorithm to protect message integrity. Running RADIUS over TLS may be the simplest solution, but mitigations need to take into account the capabilities of devices relying on RADIUS for authentication.

RADIUS needs to go away. With that said, I am not surprised by this. RADIUS was a clear text protocol for modems; I'm glad someone is calling attention to it. We need to fix the protocol internals. The current fix of TLS requires an immense amount of overhead in deploying the certificates and the certificate authorities. One 'wrong move' would crater the entire network in many organizations. There should be some mechanism in RADIUS to secure itself, and it needs to be kept up with crypto support. MD5 for this was good in 2003. Not in 2024. We either standardize dialup modems, or we need to fix this. Enable TLS/SSL in certain environments; be aware of the lift.

The attack is leveraging a MD5 hash collision race condition over UDP, as well as requiring MITM network access and only work on non-EAP authentication methods. Long term fixes will require updates to the RADIUS specification, and corresponding product updates. In the meantime, look at isolating RADIUS EAP authentication traffic over VLANs and requiring Message-Authenticators where possible. Note that Message-Authenticators may break older clients, so testing is needed. One hopes this will move the process forward towards standardizing RADIUS over TLS. The protocols have existed for a while, so check your implementation to see if you can switch to TLS. Note that is going to require a PKI infrastructure to support those communications.

This is a big deal as RADIUS is a mainstream protocol used in a large number of vendor products. The vulnerability is in the protocol, so those vendors are likely affected. The simplest mitigation in the short term is to run RADIUS over TLS.

If you have software using MD5 anywhere, be prepared for more discoveries of long dormant attack paths.

In any case, we should be providing alternatives and discouraging the use of dial access. (My newest laptop does not even have a dial modem.)

These directives went into effect Monday, July 8, and apply to "any hardware, software or information system" such as mobile apps, as-a-service offerings, hosting platforms and enterprise systems. They have until June 2025 to identify and report these FOCI risks. Included in these security directions is a restriction on use of TikTok on government devices based on the security risk of that application.

This type of effort should really require government entities to examine all technology for risk of exposure to external control, not just 'foreign' control. Remember: Solar Winds was not considered a 'foreign' company to US (and probably Australian) government agencies, nor were many vulnerability riddled VPN providers.

Some excellent recommendations and I strongly recommend that even if you are not an Australian entity that you take heed of them.

The lesson for the rest of us is that understanding the threat environment is essential to an effective and efficient security architecture.

Current APT40 activities leverage techniques that require user interaction, such as phishing campaigns, to obtain credentials for follow-on activities as well as leveraging compromised SOHO devices for launching point attacks which blend in with legitimate traffic. Mitigations for these attacks include enforcing MFA, replacing EOL equipment, implement a robust patch management system, disabling unneeded services/ports/protocols, and segmenting networks to limit horizontal movement/access.

The two biggest takeaways: 1) new vulnerabilities can be rapidly weaponized in hours by utilizing proof of concept code; and 2) the increasing use of compromised devices as operational infrastructure. The mitigations listed are standard security controls captured in mainstream cybersecurity frameworks like NIST CSF, ISO 270001, and CIS Critical Security Controls. Hopefully, organizations have already implemented those controls and underlying safeguards.

Your admin Snowflake users should already be on MFA; this completes the circle allowing you to require mandatory MFA for all users. MFA by default needs to become our mantra with the state of credential compromise.

Snowflake is going to keep giving for a while. This morning, AT&T announced that almost all customer phone records have been compromised, probably through Snowflake. This is an early report; however, enabling MFA is one step. This needs to go further.

Seatbelts went from an option to a standard feature provided by the automobile industry. Over time the government made its use mandatory for all drivers (and front seat passengers). We can expect the same for MFA, as legal settlements will drive its mandatory use as an example of reasonable cybersecurity.

We can mandate strong authentication on employees and new customers. However, because the user must be involved in setup, it is difficult to mandate it on existing customers. This approach seems like a useful compromise between option and mandate.

Previously, these users needed two hardware tokens for enrollment and login requires the password plus one physical security token; that will be replaced by the use of a Passkey which facilitates login in certain high-risk situations as well as simplifying the process of securing these accounts quickly. Make sure that your high-risk individuals are taking advantage of every available trick, such as passkeys, to secure their accounts.

If any of your management qualifies for this, take them to lunch and sell them on signing up.

Passkeys are the future in user authentication. High risk users can already take advantage of the technology but lose the added security advantages provided by APP. Google has simply streamlined the process and removed the need for a separate hardware token. Kudos to Google!

Passkeys are a more convenient option than passwords. In single user devices, they are more secure. In multi-user devices and multi-device users (e.g., support personnel) other strong authentication options (e.g., hardware tokens) should be available.

I recently published a video with tips to avoid OS command injection. See https://www.youtube.com/watch?v=7QDO3pZbum8: SANS Cloud Security | Operating System Command Injection

In addition to taking precautions in code to prevent exploitation, the guide advocates aggressive adversarial testing to assure the quality and security of the code throughout the development lifecycle. While that sounds burdensome, it's a lot easier to fix issues when looking at smaller sections of the code than after the entire application is integrated and deployed. Remember that our adversaries are not restricted by delivery timelines to discover flaws, so anything we can do to not only make our testing more comprehensive but also aid remediation, is a big win.

There are 142 vulnerabilities addressed by this patch set. The MSHTML flaw affects all hosts from Windows 2008 R2 onwards, including clients. These days, browser related patches should already migrate to the top of your priority list. Don't lose sight of CVE-2024-38021, RCE flaw in MS Office, CVSS score 8.8, which could be used to disclose NTLM hashes; while there is debate about the criticality of the update, as it's a flaw in user facing components which is relatively easy to exploit, I'd jump on that too.

I think the 1245 Microsoft Vulnerability Tuesday CVEs is MSFTÕs high-water mark but at the 2024 pace they will shatter that. Back in 2020, I had hoped the big year (which was followed by three years of 30% fewer vulnerabilities reported) might lead to long term improvement. But as the Cybersecurity Safety Review Board study of Microsoft and this month's numbers point out, the truth was Microsoft had really taken their eyes off the security ball. It is important to make sure cost of patching and mitigation before patching is possible are considering when evaluating software and cloud services - lowest acquisition cost is not always the most cost effective.

CVSS-2024-22280, Aria SQLi flaw, CVSS score 8.5, requires an authenticated user to exploit, affects VMware Cloud foundation 4.x and 5.x, as well as VMware Aria Automation version 8 prior to 8.17. The fix is to upgrade to 8.17, which can be done using Aria Suite Lifecycle, which will also pre-check your environment for compatibility and capacity.

It is 2024, we should not be seeing SQL-injection flaws in products and systems, especially products as critical to organisations as VMware is. It is this continuous lack of security in products, despite repeated assurances from vendors that they "take security seriously", that is forcing regulators to introduce laws and regulations on the minimal security requirements for the products we rely on.

You may already have traffic at your site on deploying this fix. Note this is for your local, self-hosted GitLab. Note that GitLab has modified their release process to combine security and patches to facilitate deployment. GitLab has not published a workaround; you need to deploy the updates.

You can imagine triggering pipelines as a different user can be a major issue. It appears this is limited to on-premises, in a public cloud service, which could be highly problematic.

Backup systems like Veeam have been in the crosshairs of attackers for a while. In particular ransomware attacks like to remove backups as a recovery option. But these systems can also be used for lateral movement. The backup processes may be corrupted to execute code on clients.

CVE-2024-27532, vulnerability in Veeam Backup & Recovery component, CVSS score 7.5, allows encrypted credentials in the configuration database to be obtained. The patch was released in March of 2023. Make sure that got deployed; if not, assume compromise. Initially abused by the FIN7 gang to obtain credentials, the EstateRansomware gang is now exploiting this flaw to deploy their LockBit variant both encrypting files and extorting payments.