PowerPoint, ArcaneDoor, the Z80 and Kaiser Permanente

Aaron back with you as This Week In Security editor for April 21-27, 2024 for another round-up of the news; this time I'm going to look at the notable security news from the week of April 21st with a small side of nostalgia now that the venerable Zilog Z80 CPU has been sent off for a well-earned retirement break. We'll dive into the exploitation of an old PowerPoint CVE from 2017, ArcaneDoor, and the targeting of Cisco perimeter devices and an enormous breach of Kaiser Permanente user information!

More old Office CVEs exploited in the wild

Last week, Dharminder wrote about SteganoArmor and exploitation of an Excel vulnerability (CVE-2017-11882) being used to deliver the Agent Tesla RAT (Remote Access Trojan - a specific class of malware which allows an attacker to take control of a computer remotely), and this week I find myself writing about exploitation of a PowerPoint vulnerability (CVE-2017-8570) delivering a cracked copy of Cobalt Strike (a legitimate pentesting tool which I honestly believe is more commonly used for illegitimate activities than pentesting, at this point!) to Ukrainian armed forces using a PowerPoint slideshow file (with the extension .ppsx, rather than the more usual .ppt(x)). The PowerPoint slideshow file uses an external OLE object reference (to weavesilk[.]space) to download first stage JavaScript, that JS then writes to the registry and drops a second stage loader DLL impersonating the Cisco AnyConnect VPN client and, finally, the DLL loads Cobalt Strike Beacon which will wait for instructions from a C2 (command and control) server at petapixel[.]fun.

I realise that the target landscape isn't exactly your average office environment, but the fact that adversaries are still able to exploit vulnerabilities that are now seven years old is, frankly, hugely disappointing. We should be better at this, by now, as an industry and as society - if we can't persuade people to update voluntarily then I do think as an industry we're going to have to find ways to get people to update involuntarily. Perhaps these target environments are unique and designed to be isolated (and therefore automatic updating is impossible), if that's the case we might need to rethink how systems are isolated since it evidently isn't working very well!

1. https://thehackernews.com/2024/04/ukraine-targeted-in-cyberattack.html

ArcaneDoor - perimeter devices under attack

This week, Cisco Talos revealed that a previously unknown threat actor (UAT4356 per Talos, STORM-1849 per Microsoft) was breaching network edge devices from Cisco and others (Talos only list Microsoft Exchange, specifically); as part of this analysis they discovered two vulnerabilites in Cisco ASA (Adaptive Security Appliance) and FTD (Firepower Threat Defense) devices, CVE-2024-20353 and CVE-2024-20359. Both of those CVEs were added to CISA's KEV (Known Exploited Vulnerabilities) list on the same day as being disclosed by Cisco, likely as part of a working partnership between the two - something F5 also has with CISA in an effort to ensure that customers are kept informed of the real-world risk to their systems from published vulnerabilities.

What stands out to me in the Talos blog is not really that the threat actor is new, or that they are targeting multiple vendor systems, or even that this was discovered because someone noticed something odd on a production ASA system, but actually the fact that Cisco isn't sure how initial access occurs. Clearly they know the two CVEs noted above are a part of the exploit chain, but if we check the details, CVE-2024-20353 is a Denial of Service caused by an infinite loop and CVE-2024-20359 is a local privilege escalation (LPE) from Administrator to root. This means that the threat actor has already found a way into the system and then subsequently used these CVEs to escalate privileges and carry out further tasks - it's entirely possible that initial access was simply through weak, default or leaked credentials being used (Brute Force attacks are very common) and that supposition is backed up by the general advice in the blog of "use MFA".

Now I have to be clear here, I am not criticising Cisco for not being able to identify the initial access vector (IAV) for this attack chain - it's often the case that in production environments sufficient audit logging simply isn't available or enabled, especially when the IAV was stolen or weak credentials which may leave logs indistinguishable from that of a regular administrative user. In fact, that's why I'd like to highlight another part of their advice - log to a secure, centralised system.

That's great advice for everyone, including BIG-IP administrators! Logs are often (as with BIG-IP) rotated out at very regular intervals and may only exist for a matter of days before being deleted, while compromise often goes unnoticed for weeks or months (or years - IBM reported an average time of 277 days for a breach to be identified, with that rising to 327 days where stolen credentials were used, though Mandiant more recently suggest the average dwell time is now under a month), making forensic analysis to determine how compromise took place impossible to perform.

So, outside of patching your ASA & FTD devices, heed Cisco's advice:

• Turn on and use strong MFA wherever possible
• Log to a centralised, secure location
• Patch regularly

To that, I will add:

• Enable audit logging wherever possible (and ensure they are sent to the same centralised location), something F5 enabled by default for BIG-IP devices back in 2015
• Ensure management interfaces are not internet facing and are accessible only via secure networks (see https://my.f5.com/manage/s/article/K13092 for advice for F5 products)
• Enable brute force mitigation strategies where available (e.g., fail2ban for SSH) and especially where access is permitted from insecure networks

If you are a Cisco user or enjoy reading reverse-engineering of exploits, I do highly recommend reading the full Cisco Talos blog post for more details!

1. https://blog.talosintelligence.com/arcanedoor-new-espionage-focused-campaign-found-targeting-perimeter-network-devices/
2. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Z(80)s dead, baby..

This news spanned a couple of weeks really, with initially appearing somewhere around April 19th when Hackaday announced it, and most recently on The Register just a couple of days ago. I even made a throw-away reference to it when we recorded AppSec Monthly (formerly This Month in Security) last week.. but last month, Zilog officially sunset the Z80 microprocessor after almost 50 years of service - at least in DIP (Dual in-line package) form, though it survives in eZ80 LQFP package form as a sort of turbo-charged variant.

The Z80 almost single-handedly powered an entire digital revolution in the UK, at least in my opinion. While the 6502 reigned supreme in other territories with Commodore and Apple (the VIC-20, PET, C64, Apple II etc) it never quite took off in the home in the same way in the UK (although it still has a special place in many hearts thanks to its use in the BBC/Acorn range of computers), the Z80 reigned in the UK thanks to the ZX Spectrum and successors, the Amstrad CPC range and thanks to low cost and simplicity made its way into many other markets as well - Spain had a range of ZX Spectrum clones, as did India, but notably there were many unofficial clones in countries like Czechoslovakia, East Germany, Hungary, Poland, Romania and an almost endless list of Russian clones. Personally, I think that makes the Z80 more globally important than the 6502; Sinclair may have sold far, far fewer units of the Spectrum than Commodore did of the C64 alone, but its reach behind the Iron Curtain brought easy to understand computing to masses who might otherwise never have been able to experience it themselves.

How does all this relate to security, you are asking yourself? It doesn't, directly, I suppose - the Z80 (and the 68000 that I have previously waxed lyrical over) gave me my start in computing back in the 1980s, it introduced me to concepts of logic, conditionals, branching etc through BASIC and a hint of Z80 assembly, and it's very likely I wouldn't be talking to you now if it weren't for the ZX Spectrum as we weren't affluent enough to be able to afford the more expensive BBC Model B or Commodore 64; though I do realise that we were still relatively well off, being able to afford a ZX Spectrum at all once the price dropped to £129 (£422 or $526 today) from £175!

The 8- and early 16-bit eras are always something I think back to in the context of modern processor vulnerabilities, though; back then we didn't have multiple execution pipelines and speculative execution, so problems like Spectre & Meltdown simply couldn't exist, but on the flip side we didn't have any kind of memory protection like virtual adressing (or Protected mode as Intel called it in the 80286) so early multi-tasking operating systems were highly susceptible to crashing the entire machine should a program write to the wrong area of memory and, similarly, any program could, with very little work, read from areas of memory belonging to other programs. In retrospect, and completely ignoring performance for a moment, I think we are significantly more secure now even with the dangers of speculative execution.

So long, little buddy.. I'll miss you.

(Image by Bill Bertram, source: https://en.m.wikipedia.org/wiki/File:ZXspectrum_mb.jpg)

Kaiser Permanente discloses breach of patient records

Kaiser Permanente manages one of the largest nonprofit health plans in the U.S. and, last week, disclosed a breach of information relating to 13.4 million current and former members and patients thanks to their use of third-party trackers on their websites and mobile applications. To quote their own disclosure:

“Kaiser Permanente has determined that certain online technologies, previously installed on its websites and mobile applications, may have transmitted personal information to third-party vendors Google, Microsoft Bing, and X (Twitter) when members and patients accessed its websites or mobile applications” - Kaiser Permanente

My first thought was that the headline sounds worse than the reality - surely this was "only" PII (Personal Identifiable Information) rather than PHI (Protected Health Information); things like IP addresses, browser information, perhaps location and maybe name? But, no, it's worse than that and while I think they likely skirt around the definition of PHI it certainly gets pretty close in my opinion. Kaiser Permanente clarified that the information contained IP addresses, names, whether or not that person was signed into a Kaiser Permanente account or service, how they interacted with and navigated through the website or application and - and this is the kicker for me - search terms used in their health encyclopedia. While the statement goes to pains to highlight that the information did not include Social Security Numbers, passwords or financial information, and that's good, including information on what health information people are searching is pretty close to disclosing what health issues those people have, surely? It's not a stretch (in my opinion) to imagine that information could be used for advanced phishing attacks against individuals or, in some cases, perhaps direct extortion.

Is this breach worse than the one they disclosed in 2022 which directly exposed the PHI of almost 70,000 people (including full names, medical records and lab results)? Probably not - it will take more work to weaponise the information they leaked this time, but this time they leaked a whole lot more of it.

Whether or not you should take action to - going forward at least - protect yourself from third-party trackers probably depends very much on your threat profile, and in mobile applications there is very little you can do at all - but if you are concerned about trackers in websites, look at browser extensions like Privacy Badger, uBlock Origin and Ghostery (personally I use Privacy Badger and uBlock Origin and they rarely break websites).