Money, Agents, Apologies, Switcheroos, Hype, and Hope

MegaZone is your editor once again, for this belated issue of This Week In Security, covering the week of September 22-28, 2024.  Apologies, it was a very hectic week and every time I thought I'd have a chance to sit down and write this, something came up.  I planned to work on it Monday and the next thing I knew it was Friday afternoon and I still hadn't had a chance.  Sometimes that's just how the week goes.

Oddly, a few of the items I covered last time are back in the news this week - or, perhaps, still in it.  And here... we... go...

Show Me The MoneyGram

Legacy finance-flinging organization, MoneyGram, got hit with a cyberattack which took them offline for a week - with services failing on Friday and only resuming on Thursday.  The exact nature of the attack has not been specified, though speculation seems to be leaning toward ransomware.  Even after resuming partial operations on Thursday, they were dealing with a massive backlog of transactions.  So many services people rely on every day are subject to failure due to cybersecurity issues.  I fear it will only get worse before it gets better, if it ever does.  As I've said before, I think companies are going to need to see real economic, legal, and regulatory impacts before they make sufficient investments in cybersecurity and cyber resilience. 

• https://www.theregister.com/2024/09/23/moneygram_cybersecurity_issue/
• https://www.cybersecuritydive.com/news/moneygram-cyberattack-money-transfer/728318/

The Sleeper Awakes

Last time in the editor's seat I covered the botched attempt by North Korea to place an agent inside security vendor KnowBe4.  By coincidence, this week saw a fair bit of additional coverage on the subject of more successful North Korean sleeper agents on US companies' payroll.  As I said last time, the botched attempt was likely an indicator of other, successful, attempts.  Security vendor Mandiant (now part of Google Cloud) has interviewed 'dozens' of organizations which fell for the ruse and hired North Korean agents - and those would be the ones that eventually figured it out, of course.  Mandiant's angle is helping other firms avoid the same problem, but it really boils down to doing a better job checking candidates out during the hiring process and watching for suspicious behavior amongst employees.  I recommend checking out their blog for more details on their findings and suggestions.

Additionally, Stu Sjouwerman, founder and CEO, KnowBe4, published an article on the lessons learned from their experience, via SC Media.

• https://www.theregister.com/2024/09/24/mandiant_north_korea_workers/
• https://www.cybersecuritydive.com/news/north-korea-it-workers-insider-threat/727892/
• https://www.scworld.com/perspective/four-lessons-learned-from-our-experience-with-a-fake-north-korean-remote-it-worker
• https://cloud.google.com/blog/topics/threat-intelligence/mitigating-dprk-it-worker-threat

CrowdStrike's Apology Tour

Another encore from my last stint is the continuing fallout from the CrowdStrike incident.  CrowdStrike has been on their apology tour, talking about the changes to their software and organization to avoid future incidents, and literally apologizing before a US House of Representatives cybersecurity subcommittee looking into the incident.  We do get a little more insight into the incident.  I'm sure we'll be seeing this incident for a while, given the massive, global impact it had.

• https://www.theregister.com/2024/09/25/crowdstrike_to_congress_perfect_storm/
• https://www.scworld.com/news/crowdstrike-changes-software-update-system-after-widespread-outage
• https://www.cybersecuritydive.com/news/crowdstrike-mea-culpa-testimony-takeaways/727986/
• https://www.cybersecuritydive.com/news/crowdstrike-resilient-by-design/728194/

Understudy Takes The Stage

Since the US government banned Kaspersky from the US market back in July, they announced that they would be pulling out of the market in September, and selling their US customer based to UltraAV - an little-known player in the anti-malware space.  But what no one expected them to do was to use Kaspersky's software's ability to update to automatically replace itself with UltraAV on over one million end-user machines - which is obviously what they did, or I wouldn't be writing this.  Users suddenly found a software application they'd never heard of running on their machines, taking over security functions, while the Kaspersky software they'd installed was nowhere to be found.  I'm really not sure that was the best way to engender goodwill and trust with their users.

It's like finding a U2 album you never asked for on your device.  (Kids, ask your parents.)

Reading about UltraAV, I'm not sure I'd keep it if I found it on my machine.  Very little is known about it, even within the close-knit AV community.  The engine was apparently acquired a couple of years ago from Indian company Max Secure Software.  It has not been vetted by independent testers.  It has not been evaluated by the Anti-Malware Testing Standards Organization (AMTSO).  Most AV testing labs have not touched it, and those who have apparently took only a cursory look, with less than encouraging results.

"We did not run a full test – we only had a quick look," one tester told The Register. "But let’s put it this way: There is room for improvement in the protection and usability."

None of that is encouraging, especially in light of the way it was backdoored onto systems.   

• https://www.theregister.com/2024/09/24/ultraav_kaspersky_antivirus/
• https://www.scworld.com/news/kaspersky-automatically-installs-ultraav-deletes-itself-on-us-machine
• https://ultrasecureav.com/kl-transition

In Your CUPS

Recently, there was much furor over a batch of four Linux CVEs that were about to be disclosed.  Reportedly they scored as high as a 9.9 in CVSS 3.1 and it was going to be the end of the world, etc.  The usual panic about the sky falling.  Well, they're out: CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, and CVE-2024-47177 - and I just don't think they're that big of a deal.  Certainly not what the hype cycle had made them out to be.  There is no 9.9 Critical, rather one of the four is a 9.1, with two 8.6 High, and one 5.3 Medium.

They affect the Common Unix Printing System, aka CUPS, not just on Linux, but also BSD distributions, and possibly other UNIX-like OSes, including ChromeOS.  Exploitation requires CUPS to be installed and active, with the cups-browsed service running.  UDP port 631 needs to be accessible to the attacker, who then needs to wait for the victim to initiate a print job to open the door to an exploit.  So there are a few hoops through which the attacker must jump.

• https://www.cybersecuritydive.com/news/linux-cves-open-source/728310/
• https://www.scworld.com/news/cups-vulnerabilities-put-linux-systems-at-risk-of-remote-code-execution
• https://www.theregister.com/2024/09/26/cups_linux_rce_disclosed/
• https://www.cybersecuritydive.com/news/cups-vulnerability-near-miss-open-source/728424/

Good Riddance

I have a personal loathing for some long-standing password policies, such as being forced to pick a new password every 90 days, or the classic 'must contain' requirements lists.  We've known for years now that those aren't best practices, and can even create bad habits, but they just refuse to die.  Forcing someone to change their password regularly tends to result in users picking shorter passwords (less overall entropy), using minor variations on the same password, etc.  Because humans are bad at regularly coming up with a solid, unique password - or passphrase - and then remembering it.  If you allow users to pick a password and stick with it, unless and until there is evidence of a compromise, you can require longer passphrases, with more entropy.

Now NIST is considering barring some of these outdated practices.  It would bar the requirement to periodically change passwords or requiring specific characters or case.  Ars Technica has helpfully digested NIST SP 800-63-4 and summarized some of the proposed rules:

1. Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.

2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.

3. Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.

4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.

5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

6. Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.

8. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.

9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it).

I, for one, am very much in favor of these rule changes.  

• https://arstechnica.com/security/2024/09/nist-proposes-barring-some-of-the-most-nonsensical-password-rules/
• https://www.wired.com/story/nist-password-guidance-improvements/
• https://pages.nist.gov/800-63-4/sp800-63b.html

That Was the Week That Was

Thank you for your time and attention this week.  I hope you found something of value in my ramblings.

As always, if this is your first TWIS, you can always read past editions .  I also encourage you to check out all of the content from the F5 SIRT . 

Until next time, be well.