NIST Revised Identity Guidelines Address Human Element in Authentication; Linux CUPS Vulnerability; Attackers are Targeting Critical Infrastructure Systems

In this document, Authentication Assurance Level 1 still says reusable passwords provide 'basic confidence that the claimant controls an authenticator bound to the subscriber account being authenticated.' Note: this is NOT confidence about identity, it is confidence that the account name entered and password match - every successful phishing attacker gains this 'basic confidence' level. AAL 2 requires phishing-resistant authentication be in use and should be the starting point. Also note: the guidelines remove requirements for regular password reset but require immediate reset when a password is compromised. That requires monitoring one of the many (often free) password compromise exposure feeds and will very likely result in resets needed more frequently! Moving away from reusable passwords avoids that increased cost.

This change has been a long time coming. What NIST has done (and congrats for it) is start addressing the human element in authentication. Requiring extremely complex, time-consuming, and unrealistic behaviors only frustrates people to the point that we drive them to the wrong behaviors. These new password requirements dramatically simplify passwords for people, enabling them to exhibit the behaviors we do want. Now, what I would love to see is the discussion shift to how can we make MFA as simple as possible for people. The simpler a behavior, the more likely people will exhibit it.

These updated requirements are a great refresh to move us forward to more sensible authentication policies. Must read for anybody defining authentication requirements.

To my old co-worker Jason: we tried for years back in 2009-2010 to tell PCI auditors that having us change our 20+ character passwords every 90 days was a silly idea. IT ONLY TOOK 15+ YEARS!

NIST has slowly been evolving its thinking on password creation and management. This revised draft guidance continues that trend. Bottom line, a set of practical rules that consider the threat, changing identity and access management technology, and dare I say it, common sense. Hurry up and go final before the cybersecurity 'borg' consumes you!

It's been repeatedly proven that frequent password changes results in a lowering of security, as does special character requirements (as opposed to long complex passphrases) as composition requirements can, again, lead to weaker passwords. Beyond getting sane about password requirements, MFA, particularly phishing-resistant MFA, needs to be SOP. The window for comments on this draft close at 11:59 Eastern on October 7th. PCI's DSS 4.0 will need to catch up as it still requires a 12-character password with upper/lower/numbers and a unique symbol. DSS 4.0 does include MFA requirements.

Bits are bits and it is true that length is a more convenient way to get them than awkward complexity rules (introduced to get bits when password length was restricted for efficiency). However, one should NOT infer from this discussion that strong but replayable passwords are useful, secure, or appropriate for any but the most trivial applications. While strong passwords do protect against brute force, "fuzzing," spraying, and dictionary attacks, we are not seeing these attacks. They do not protect against the fraudulent reuse of compromised credentials, implicated in so many breaches. They are not even more convenient than such strong authentication mechanisms as Passkeys.

Bug hunters need some soft skills in reporting vulnerabilities. In particular for a volunteer run project like CUPS, a little bit of empathy and recognition for their work goes a long way. The now public GitHub exchange between Margaritelli and CUPS developers show that while Margaritelli had great technical skills, they were lacking professionalism in communicating these issues.

The person who discovered this bug alludes to a few things. First, they verified 200-300K machines that responded to malicious IPP requests and were vulnerable. It's hard to know; default Ubuntu 24.0.4.2 systems have this service running, while something like Kali Linux does not. There is a lot of drama here; the author also mentioned that they baked the exploit into Bettercap, their adversary in the middle tool. This is getting exploited right now. It appears to be trivial to do. Second, and maybe more interesting, this is one of many blog posts, and the Apple logo keeps showing up.

Initially, around September 23rd, a disclosure of an unauthenticated RCE flaw with a CVSS score of 9.9 rating which affected multiple Linux distributions was made. When the dust settled, this became vulnerabilities which affect CUPS. Four vulnerabilities were released for CUPS, CVSS scores ranging from 8.4 to 9.1. The exploit consists of sending a carefully crafted packet to UDP port 631. Odds are you don't need to allow UDP 631 inbound through your firewall, doubly so until fixes can be made. Also you're going to want to disable cups-browsed until patches are available.

One thing you can always count on, the adversary changing TTPs as defenses stiffen. Generative AI will only hasten changes in TTPs. What's common though is the use of stolen credentials. And while we point to anti-phishing training as a means to mitigate, lures do get through, especially if they are using legitimate credentials. The best defense remains patch (update), configure, and actively monitor your network for signs of compromise.

These attacks are very sophisticated as they start with BEC (Business Email Compromise) attacks - cyber threat actors taking over individuals' email accounts and then interjecting themselves in existing email threads. At this point itÕs very difficult to train and unrealistic to expect people to detect these attacks. This is where we need to start at the source, securing these accounts with MFA making it that much harder to take over them.

BEC largely relies on social engineering and compromised credentials. Help users help themselves by making sure you've got your MFA enabled on your email accounts, and that you've enabled your email security tools. Not just DMARC/SPF/DKIM, but also tagging and quarantine capabilities. Consider a one-button widget for user reporting. Consider that these attacks will not remain focused on one sector or another, they are not just "someone else's problem."

CISA is reporting that compromises of OT/ICS systems continue via unsophisticated means. In other words, these systems are still Internet accessible (often via VNC port 5900) or exposed to the business' Intranet without proper isolation and protection. Do you know what's externally available over RDP and VNC port ranges in your shop? Are there ad-hoc relay services, e.g., LogMeIn, VNC cloud connection, etc.? Make sure such remote access services are vetted and secured. The cost and friction from a VPN is far lower than recovery from a compromise.

One cautions against equating power and water. The grid may make multiple power systems vulnerable to a successful attack on one. Said another way, the grid is one big attack surface. A successful attack on one water system may reduce the cost of attack against others only to the extent that they use similar software and controls.

Power and Water should be at the top of everything we should be worried about. Maybe this is a sign that we should, you know, invest in these areas.

Critical infrastructure vulnerabilities have been a growing concern over the last twelve months. What's been common is the use of hardcoded credentials by vendors and remote accessibility by users. While the first requires a secure design change by the vendor, the second is controlled by the user and is easily mitigated by isolating the OT network or restricting remote access. This is yet another wake-up call to protect critical infrastructure components.

A good reminder that almost all 'automated monitor/manage' vendor (and not just to OT systems) connections are vulnerable out of the box even today. Good idea to have annual inventory and pen test/vulnerability assessment of all such connections.

The vulnerability CVSS scores range from 5.1 to 10.0, and most are over 8. The fix is to apply the vendor provided updates as well as minimize access to these systems over the network, behind firewalls; don't expose them to the Internet and isolate control systems from the business network. To which I would add monitoring. Make sure that you've got eyes on traffic associated with your control system to detect anomalous behavior expeditiously.

There has always been significant overlap in botnets between those used "for fun" and botnets used by nation state or organized crime actors to build attack infrastructure. The differences in code are often minor and it is frequently impossible to tell them apart. There is no need for sophisticated attackers to step out of the noise if these simple tactics work.

Botnet herders, purportedly China in this case, are simply taking advantage of poor cyber hygiene practices by consumers. By simply patching, updating, and regular rebooting your device you solve a world of potential cybersecurity problems. The question becomes, what is your liability for not following standard duty of care practices and one of your devices gets used as part of a wider cyber-attack?

IOC's for RaptorTrain are in Black Lotus Lab's full report: Derailing the Raptor Train (https://assets.lumen.com/is/content/Lumen/raptor-train-handbook-copy) along with enumeration of campaigns which stretch back to May 2020. The good news is that mitigations are straightforward and center around updates, lifecycle management, using strong credentials and not allowing unauthorized devices access to management capabilities, which is not terrible for a business, but harder for many "set it and forget it" home users. Which is where we hope to see inroads made with secure by default configurations, and device certification efforts.

Hot Take. Things like this make me consider telling family and friends to use a VPN full-time. The one place I cannot do proper telemetry is my ISP router/modem. If it's compromised, I will be slightly at a loss to figure this out correctly, at least not from inside my network. We need to do better in this regard.

Microsoft's good intentions notwithstanding, the popularity of their products makes them prime targets.

This should become required reading for our AD admins, as well as the cyber team so they are on the same page. Beyond the attacks, guidance is provided on tools to aid our team getting their arms around our AD implementation and its security. The 17 techniques include Tim Medin's Kerberoasting, password spraying, Golden/Silver tickets, SAML, and even Entra Connect; with each is not only a description of the attack but also how to detect, including event IDs, and mitigate each.

This doesn't just impact cloud environments, but it does affect many cloud systems.

TOCTOU vulnerabilities are pervasive though rarely exploited. They are pervasive because developers are not taught that they must bind conditions that they will later rely upon. Nonetheless, they are difficult to exploit.

Both vulnerabilities affect Container Toolkit versions 1.16.1 and below as well as GPU Operator versions 24.6.1. The fix is to update to version 1.16.2 and 24.6.2 respectively.

My network engineers, please patch. While you're at it, turn off Smart Install; we keep finding it.

Take note that the six DoS flaws can be remotely exploited without authentication. Cisco also warns that CVE-2024-20381 (improper authorization checks) which could allow an attacker to create a new account or elevate privileges, affects multiple products including the RV340 VPN, and won't be getting an update as it is EOL. You need to not only check all your Cisco devices for updates and apply them, but also review your Cisco inventory for EOL products which need forklift replacements. Don't forget to clear EOL items out of your storage/just-in-case closet, as well as update supported devices; you're not going to have time for that when you press these into service.

I'm not 100% sure this is a good thing. We permanently 'lose' something when fundamental changes are made. What we are losing here is the fact that many customers may delay needed updates. What we do in policy and what happens in practice are typically not the same thing, so we will see if this ends up being a new vulnerability to individuals.

CrowdStrike's testimony before the Congressional committee is available on YouTube. I found it very disappointing. Instead of improving the management controls over the release of updates, CrowdStrike is transferring the responsibility to their customers to control the application of the updates. CrowdStrike is also attempting to limit its responsibility to "make its victims whole" to helping them recover.

*Not* treating 'content as code' is what has enabled buffer overflow attacks to succeed for many years and why fuzzing is an important element in thorough code testing. Query all your security vendors about their practices in this area.

While CrowdStrike is getting pushback for having kernel level access, EDR products need kernel access as malware and threat actors are gaining kernel access, so kernel access is needed to detect and stop their activity. Until such time as we're all out of the kernel, take a look at your settings for deploying content updates, and consider staggering it for servers or critical systems which are not Internet-facing. This is not one of those cases where, like we did in the old AV days, having multiple EDR products would have prevented the impact, which is why you need to tune your settings to mitigate a future event. It's estimated that the flawed update cost Fortune 500 companies more than $5.4 billion, not to mention impact on shareholders when the share prices took a dive, so expect the litigation attempts to continue.

This vulnerability and similar ones in the past demonstrate a lack of cyber-informed engineering. This will only continue as the world continues to connect devices to the Internet. Two possible remedies: 1) Start teaching cybersecurity as part of the engineering discipline; and 2) Embed cybersecurity engineers as part of the product design team. The first will take time. The second will take resources and added costs.

This affects most Kia vehicles made after 2013 and doesn't require an active Kia Connect subscription. Attackers would generate a dealer token, fetch the victim phone/email associated with the VIN, demote the owner, add the attacker as primary owner, then use that account to execute commands via VIN. There was no indication to the user that their vehicle had been accessed or their permissions changed. With increased connectivity for vehicles, appliances and other traditionally stand-alone devices, comes a requirement for increased security testing and validation to minimize opportunities for abuse.

Here comes our next installment of the CT Kia Boyz on TikTok. If you don't know about this, watch some videos and be shocked.