Dell & Ticketmaster breaches, CVE & patch roundup and ProxyShell is back

Notable security news for the week of May 20th-26th, 2024, brought to you by the F5 Security Incident Response Team. This week, AaronJB is taking a look at breach news from Dell, a novel DNS attack technique, how threat actors still exploit old CVEs (like Exchange's ProxyShell CVE-2021-34473, CVE-2021-34523 & CVE-2021-31207), why Industrial Control Systems shouldn't be connected to the Internet and a quick round-up of vendor patches you should take a look at from Ivanti, Fortinet, TP-Link and F5.

Huge breaches, still in fashion

I originally had this segment planned so that I could talk about the recent Dell data breach which exposed the records of 49 million customers - name, physical address, Dell order information - you know, the usual kind of information that an adversary could use to construct a very convincing spearphishing attack (yet Dell consider low risk, apparently); but there is some late breaking news which potentially makes this breach look tiny. I'll get onto that later.

The Dell breach is interesting though as it was actually achieved using one of the most basic techniques (which I thought was long since 'fixed') - web scraping. The attackers simply registered a partner account using fake company details and then used a generated list of service tags to scrape the details of every order relating to those service tags - they sent 5000 requests per minute for three weeks straight, and nobody noticed a thing. Dell Service Tags are a unique asset identifier consisting of seven alphanumeric digits - consider them a serial number - so the attackers just needed to generate every possible combination of service tag and then, one by one, request the details of the order behind that tag. Apparently, the attackers even tried to disclose this security issue to Dell but received no response and set about monetizing their discovery instead.

It strikes me that there are so many places this could have been fixed ahead of time:

• Least privilege: Does every partner account really need to be able to access the details of every possible service tag? (I would have thought no!)
• Rate limiting: Does that API really need to be able to support endless requests from a single partner account? (I would have thought no!)
• Logging: I don't know what the base requests-per-second rate is for that API, but shouldn't there at least have been some logging happening to a central SIEM about suspicious activity?

Any of the above could have stopped this attack dead - heck, I get the impression that Dell could have stopped the attack had they interacted with the original report sent to them; though perhaps the original report (in part redacted) was looking for a bounty and Dell declined to interact on such basis. Still, the published partial email does seem to indicate that the attackers provided a full PoC from the outset..

 

But wait, I said there was something bigger? Yes! This is late breaking and we don't have all the facts yet, but a couple of days ago posts began appearing on X suggesting that Ticketmaster had suffered a breach of 1.3TB of data which included names, physical addresses, email addresses, phone numbers and the last four digits and expiry of payment cards associated with orders - 560 million rows of data. The validity of this was initially questioned but, unfortunately for us, later verified to be true; as vx-underground says:

Sometime in April an unidentified Threat Group was able to get access to Ticketmaster AWS instances by pivoting from a Managed Service Provider.

At least this wasn't a simple web scraping attack, I suppose, but it highlights something for me: You need to be very careful who you trust to manage your systems, because your security is entirely in their hands. Meanwhile, your reputation is entirely in your hands - when and if you are breached, your customers won't come with pitchforks for your MSP, they will come for you. This is also true of SaaS services, of course, and why SaaS companies (including ours) invest heavily in internal training, processes and patch management.. I wonder if the MSP did, in this case?

 

Vendor patch watch

It's like Spring Watch (for UK readers; for the rest of the world, that's a daytime TV show where cameras get shoved in badger sets, bird houses etc and people watch baby animals that were born in springtime), but for vulnerabilities..

Ivanti published patches for six Critical severity vulnerabilities (plus four High) in Ivanti EPM, and a handful of other Ivanti products; if you use any of those you really should patch ASAP, although none have appeared in CISA's Known Exploited Vulnerabilities (KEV) list yet.

Proof of Concept exploits were released for Fortinet's CVE-2024-23108 (disclosed in January) so if you haven't patched, you absolutely must as the time from PoC availability to widespread exploitation is typically 24 hours or less. Rather unfortunately, the PoC reveals that CVE-2024-23108 is basically CVE-2023-34992 just in a different argument - still, we have all been there!

TP-Link disclosed a CVSS10.0 vulnerability in their Archer C5400X gaming router and if you have one of those then you really need to patch - home routers are common targets for attackers looking to create botnets to carry out further attacks, and earlier TP-Link CVEs quickly appeared in CISA's KEV list as well as F5 Labs' Sensor Intel Series which showed that CVE-2023-1389 (TP-Link Archer AX-21) was the most targeted vulnerability in March 2024!

Finally, and not to be outdone, F5 had two disclosures in May; this is unusual for us as we typically coordinate our disclosures for Quarterly Security Notifications however, this month, we had both a QSN and an Out-of-Band notification affecting NGINX products. You can find the details of our May 8th QSN in K000139404 and details of our NGINX-specific May 29th OOBSN in K000139628; fortunately for us the highest CVSS in our QSN was an 8.0, and in our OOBSN a 6.5 (and the OOBSN NGINX issues are all specific to QUIC, as well). As I say, we try to coordinate our disclosures for QSNs so that our customers can have a predictable cadence around which to plan updates & upgrades; we are committed to security, to working with external researchers, and to the security of the open-source community however, and in some cases we must disclose issues out of band in order to best protect and serve our customer base, and maintain the balance between transparency and security.

 

Novel DNS attack - DNSbomb

DNSbomb - I originally spotted this a couple of weeks ago, but last week it was the topic of a talk at the 2024 IEEE Symposium on Security and Privacy so has had a bit more coverage and there is now an easy-to-digest slide set available (with a video to follow) and even a one-page poster for your wall (seriously though, I actually love the idea of a one-page poster like this for new research; it's great for those of us who are attention-span challenged!).

The idea behind this attack is to use a low-rate of requests from a large number of hosts to fly under the radar, but rather than simply having those hosts query the target victim, those hosts send their queries to some intermediary concentrator (which could be a recursive resolver, CDN or similar) which will queue all of those requests up and send them in one big burst to the target victim (hence the "bomb" part of the name).

The technique is interesting and novel, promising a theoretical amplification factor of 20,000x or greater and a peak "bomb" in the 9Gb/s range, but I must admit that I haven't been able to properly go through the research paper or try to replicate their findings yet. Perhaps that will be the basis of a future DCCO article! If anyone has had chance to really understand the research - or better still, was at the IEEE Symposium - I'd love to hear from you!

 

Don't put your Industrial Control Systems on the Internet?

I thought this fell under the heading of "obvious news" but apparently, not so obvious; Rockwell Automation and CISA have "encouraged" customers to assess and secure their public internet exposed ICS assets. Personally, I'm struggling to understand why Industrial Control Systems would be exposed to the Internet, ever, but perhaps I am being naïve here? Is the public internet just considered "easy connectivity" for ICS & IoT systems? Certainly, a quick google for things like "water treatment plant internet" shows plenty of articles discussing IoT for waste treatment monitoring, but do you really want the gate valves separating brown water from clean being controlled by a PLC hooked up to the Internet?

OK, silly example, but my point stands - industrial controls typically look after things that are mission- or human-critical, toxic waste, nuclear power stations, manufacturing plants and so on. None of that stuff should ever be connected to the internet, and it terrifies me that Rockwell & CISA felt the need to reiterate that...

 

One last thing..

An article about MS Exchange flaws being leveraged to deploy keyloggers in highly targeted attacks. What caught my eye there wasn't the keylogger part (although that is neat; at least neat to see something that isn't just ransomware!) but rather that the threat actor is leveraging Exchange vulnerabilities from 2021 in the form of ProxyShell (CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207). I talk about this often, but as an industry we have to get better at patching exposed systems; perhaps the problem is we simply don't know what systems are exposed, perhaps the problem is a lack of time to patch, or a lack of corporate will to suffer potential downtime and push-back by Change Advisory Boards, but whatever the problem is we really have to tackle it.

I'd love to hear your stories from the front lines of patching things like ProxyShell; how long did it take, was there any fallout, management push-back etc?

Ancient Exchange flaws exploited - https://thehackernews.com/2024/05/ms-exchange-server-flaws-exploited-to.html