Time-to-exploit and large scale breaches - Jan 15th - 21st, 2024 - F5 SIRT - This Week in Security
This Week in Security
January 15th to 21st, 2024
Time-to-exploit, time-to-patch, breaches time-after-time, the passing of time and ... pixies
Aaron here as your editor this week and what a week it has been! Some high-profile vendors have had to make awkward statements (more on those later), giant breach-dumps (Naz[.]API and the MOAB) have appeared and there has been some sad news in the form of obituaries for pioneers of modern computing.
We in F5 SIRT invest lot of time to understand the frequently changing behavior of bad actors. Bad actors are a threat to your business, your reputation, and your livelihood. That’s why we take the security of your business seriously. When you’re under attack, we’ll work quickly to effectively mitigate attacks and vulnerabilities, and get you back up and running. So next time you are under security emergency please contact F5 SIRT.
How soon is soon enough when it comes to patching?
I think we all know that high-profile RCE CVEs are quickly weaponised by attachers, typically within days if not 24 hours of disclosure, so rapid patching of Critical or impactful vulnerabilities is essential for exposed services; but what if it turns out that threat actors have been exploiting a vulnerability long before it was made public? I expect most vendors, as F5, have processes built into the vulnerability management systems to handle such an event and everyone hopes they will never be battle-tested, but that's exactly what VMWare got to do recently when they discovered that UNC3886 had been exploiting CVE-2023-34048 (disclosed 10/24/2023) as far back as late 2021!
Of course, the question I ask above is silly - I'm not suggesting that early patching could have prevented this situation because the vulnerability in question was only fixed in vCenter 8.0U2 which was released 10/23/2023, and no amount of early patching can help if an attacker is exploiting a vulnerability before it has been fixed, but I am going to use this situation to suggest that you shouldn't wait until vulnerabilities are public knowledge before adopting updated versions of software into your environments. There are many times when vendors will either quietly fix bugs which might turn out to be exploitable, or when vendors support many release trains and must wait until all release trains have received a patch before they can disclose a vulnerability. In both cases, timely updates will ensure that you have the best chance of closing the hole before an attacker can try to exploit it.
Like I say, no amount of early patching could have helped here, but this is (thankfully!) the exception that proves the rule and in most cases attackers aren't leveraging vulnerabilities until after disclosure, and disclosure typically comes some time after fixes are released giving you a window of opportunity to ensure you can't be caught out.
Mandiant have a nice blog post explaining exactly why they believe this vulnerability was being leveraged by attackers long before public disclosure: https://www.mandiant.com/resources/blog/chinese-vmware-exploitation-since-2021
37C3 videos are up on YouTube
What's 37C3, you say? C3 is the Chaos Communication Congress, an annual conference organised by the Chaos Computer Club (so many Cs), Europe's largest collective of hackers and security professionals founded in 1981. The C3 event has happened every year since 1984 with few exceptions and has historically always been in December, since 2005 between Christmas and New Year. It is basically Europe's DEF CON in Hamburg instead of Las Vegas (colder, with better beer!), with Chaos Angels instead of DEF CON Goons for security.
There are quite a few videos online now from 2023's 37C3 (the 37th Chaos Communication Congress) but I wanted to call a couple out specifically:
- Writing Secure Software - https://www.youtube.com/watch?v=TaE28fJVPTk - which is a great dive into the topic presented with humour and candour, and 45 minutes well spent.
- SMTP Smuggling - https://www.youtube.com/watch?v=V8KPV96g1To - this research came out toward the middle of December and 37C3 was the first conference to witness the presentation. SMTP smuggling is an interesting concept; perhaps not as immediately accessible or powerful as HTTP request smuggling, but I can certainly see how it could be leveraged to target vulnerable individuals with better and more convincing phishing attacks. The good news for us at F5 is that BIG-IP APM's Protocol Security feature already detects many SMTP smuggling approaches and can easily be deployed in front of your organisations on-prem SMTP servers, if you still have them.
I recommend giving the video a watch and perhaps look out for a future article on the topic here on DevCentral.
The rest of the videos can be found on the CCCs YouTube channel - if you find one you really like for any reason, please leave a comment recommending it for others! https://www.youtube.com/@mediacccde/videos
I'm back on breaches again
Writing about security news it seems like breaches are the gift that keeps on giving.. in the last week or two we've had Microsoft disclosing that APT29 (aka Midnight Blizzard, BlueBravo, Cloaked Ursa, Cozy Bear etc) breached a test host using a password spraying attack and subsequently pivot internally into emails and exfiltrate sensitive emails and documents from their cybersecurity and legal teams (https://thehackernews.com/2024/01/microsofts-top-execs-emails-breached-in.html), Southern Water (who supply water to 4.7 million customers in much of the south of England) were breached by the Black Basta ransomware gang who made off with an apparently "limited amount of data" (https://www.theregister.com/2024/01/23/southern_water_confirms_cyberattack/), and of course we can't not mention the Naz[.]API credential stuffing list (https://www.troyhunt.com/inside-the-massive-naz-api-credential-stuffing-list/) which contained the details of over 70 million accounts from a myriad of different services and, importantly, much of it was new data rather than being entirely recycled data. Speaking of recycled data, we also had the "Mother of all Breaches" (https://www.malwarebytes.com/blog/news/2024/01/the-mother-of-all-breaches-26-billion-records-found-online) which is a breached data compilation containing 26 billion records.
Both of the last two, Naz[.]API and the MOAB, are the kinds of datasets which power credential stuffing and password spraying attacks like the one Microsoft succumbed to as well as spear phishing attacks (that is, phishing emails constructed to specifically target an individual or small set of individuals using intelligence gathered about them) and all four news articles serve to remind us of the importance of vigilance and maintaining a good personal security posture by doing things like:
- Using unique passwords for each service or account you create (password managers, for their potential faults, are essential here)
- Using multi factor authentication wherever possible. Even SMS-based 2FA is better than no 2FA, although as F5 Labs' 2024 Cybersecurity Predictions article (https://www.f5.com/labs/articles/cisotociso/2024-cybersecurity-predictions) and 2023 Identity Threat Report (https://www.f5.com/labs/articles/threat-intelligence/2023-identity-threat-report-the-unpatchables#multifactor_authentication_bypass) notes, MFA is now commonly defeated by techniques such as real-time phishing proxies, and so it is better to use MFA based on public key infrastructure where possible (like FIDO2) - but that is a choice for the developer of the application you are using, and as a user all you can do is enable whatever MFA the application supports and know that it is better than nothing
- Being vigilant to email based threats such as phishing, spear phishing or internal phishing and being cautious what files you open and links you click on, even if the email appears to be from a legitimate contact
The passing of time
Sometimes I am reminded just how young our industry is in comparison to even modern inventions like the automobile (circa 1880s), and the passing of those who were hugely influential in computing is one of those reminders. Just in the last few weeks we have lost Professor Niklaus Wirth and Professor David L Mills.
Professor Wirth was creator of the Pascal programming language, recipient of the Turing Award, the person who gave us Wirth's Law and someone who can be at least partly credited with my entire career since early in my career I cut my commercial programming teeth in Borland Turbo Pascal (and spent a number of years hunting use-after-free bugs in other people's code, grappling with DOS protected mode memory management); he passed at 89 on January 1st, 2024 (https://www.theregister.com/2024/01/04/niklaus_wirth_obituary/).
Professor David L Mills was the mind behind NTP (the Network Time Protocol) which is responsible for keeping the clock right on almost every device connected to the Internet and who passed at the age of 85: https://www.theregister.com/2024/01/23/david_mills_obit/
Don't get me wrong, these aren't necessarily the earliest pioneers of computing, but they most certainly are the earliest pioneers of the Internet, Unix and what you might call modern computing, and the world is poorer without them.
A pixie sized morsel
On January 16th, Quarkslab dropped a blog on a new set of nine vulnerabilities impacting the IPv6 network stack of EDK II, an open source reference implementation of UEFI firmware (the modern-day BIOS, responsible for first boot operations of all computers). These vulnerabilities are all in the networking code used by the Preboot eXecution Environment (PXE or "pixie") which is designed to allow a computer system to boot using software delivered over the network without any other configuration being in place - ideal for deploying new servers or systems in a datacenter, for example - and could allow an attacker with access to that network to poison a target system.
I think, for most readers, the implications here are limited; an attacker needs to have a foothold in your network already and you need systems that are configured to use network-boot to grab their initial boot image, but I recommend reading the full blog if you enjoy in-depth technical detail and a look into how the UEFI boot process works: https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html
This disclosure comes hot on the heels of a number of other UEFI issues like LogoFail (https://www.theregister.com/2023/12/01/uefi_image_parser_flaws/) and I think speaks to both the complexity of UEFI (certainly compared to legacy BIOS implementations) and increased research into the boot process as vulnerabilities there are key to bypassing low level security features aimed at preventing data theft.
Back to time-to-patch
Last up, a few general calls-to-patch from me:
If you're an Atlassian Confluence Data Center or Confluence Server administrator, look into patching CVE-2023-22527 on exposed systems immediately because it is already under large scale automated exploitation: https://thehackernews.com/2024/01/40000-attacks-in-3-days-critical.html
VMWare Aria Automation or Cloud Foundation administrators should take a close look at CVE-2023-34063 with CVSS 9.9: https://core.vmware.com/resource/vmsa-2024-0001-questions-answers
Ivanti Connect Secure or Policy Secure users should check out CISA's emergency directive of 1/19: https://www.cisa.gov/news-events/directives/ed-24-01-mitigate-ivanti-connect-secure-and-ivanti-policy-secure-vulnerabilities
Updated Jan 30, 2024
Version 15.0