US Politicians Feel Impact of Health Data Breach; More Need to Join GitHub in Mandatory MFA for Developers; Prioritize Updating Jenkins to Mitigate Serious Vulnerabilities

The good news on this incident is that House Speaker Kevin McCarthy, R-Calif., and Minority Leader Hakeem Jeffries, D-N.Y., sent a letter to the DC Health Link saying the “incident significantly increases the risk that Members, staff and their families will experience identity theft, financial crimes, and physical threats.” Sometimes, not always, when lack of regulatory backing for raising the cybersecurity bar personally impacts politicians, we see progress.

This breach didn’t target the legislators directly even though their data was breached and is marked as SOLD in Intellibroker on the dark web. Here is the thing, whether or not your users were targeted or their data was taken, and possibly sold, it still hurts and they are going to be upset. Be proactive in notifying affected users, as DC Health was, and consider how you would feel if it’s your data. Don’t hold back on offering credit protection, including hand holding for those unfamiliar with this. Plan to engage an outside form to help with the investigation and recovery, your team is going to be need support, to include independent confirmation of their findings. Make sure your plan is both written down and verified as viable.

This cyber breach has garnered much attention because it involves the US House of Representatives. While not a straight-up ransomware attack, the information was made available for purchase and in this case, a subset was purchased. Bottomline, the evil doer obtained a payout.

Developers are targeted like never before. It is very good to see GitHub following through with their multi-factor authentication requirement they announced earlier.

I’m encouraged enough by movement towards MFA that I think by the end of 2024 this type of thing won’t be headline worthy. The news items will be “Laggard Ltd. was compromised because of its use of reusable passwords.

The cost of providing your developers hardware security keys is far less than recovery from a compromise. If you’re a developer and your employer won’t fund one, get your own.

It’s been an interesting journey getting to MFA. Let’s not lose the gains in adoption by arguing if one form of MFA is better than another. Any form of MFA is a vast improvement of continued use of passwords as the sole authentication mechanism.

Do not underestimate this vulnerability. Exploiting it will be tricky, but an exploit can be devastating. This is also an interesting case how a "simple" XSS vulnerability may become a remote code execution issue.

This article piqued my interest the most: if you don’t read much of the newsletter this week, this article is worth the read. But first is my gratuitous quote: “Oh, a Jenkins RCE? But why isn’t that a core feature?” Now that we have that out, what makes this interesting and scary? First, the XSS to RCE payload without user interaction is a great read for many reasons. This is an example if you struggle with “the worst-case scenario” with an XSS bug. Secondly, which is interesting but may not come across to the average user skimming this, is that this is enabled through a global plugin system in which every single Jenkins user can automatically download to install over the internet. The community first gatekeeps the plugin system. Still, once a plugin is allowed, it can later be updated to something much more malicious without any additional checking from the community. The XSS bug is triggered through a malicious version number that is not expecting script tags within the system. You can be sure there are probably other bugs in this system because that’s how the software goes. A supply chain attack that itself attacks the supply chain. Supply Chain Attack Inception.

Welcome to CorePlague! (Yeah. Ok you chain these together and see what name you come up with…) Effectively you’re able to execute arbitrary code on the Jenkins Server. All versions of Jenkins prior to 2.319.2 are vulnerable and updating to the latest version is the best fix.

Not much detail on the discovery timeline yet on this incident (or the DC Health Link one) but the worst trigger for discovering an incident is when you are notified your or your customer’s sensitive data is already for sale. Simple tools like file integrity management have long provided indication of compromise but often are so noisy they are ignored or alerting and analysis tools and personnel are up to the task of making sure meaningful alerts are bubbled to the top of work queues.

Acer is working to answer the question of “so what did they get?” Knowing what you have and what it does, with proper configuration and data access controls are essentially the first four CIS Critical Controls. Yes, with cloud services it’s trivial to create copies of data, without obfuscation or redactions, so you’re going to need tools to help check as this occurs, my point is that you need to plan for knowing what’s where. Yes, this takes time, insert start with single step cliche here, you can do this. You don’t want your IP walking out the door any more than you want privacy data leaving.

While this may not seem harmful, consider the amount of information your server, network, or infrastructure provider may have. Is this considered a supply chain attack? Arguably, as we don’t know what’s on that documentation server, this could have been far worse had their helpdesk system been breached.

This latest compromise continues a trend of cyber breaches affecting the company as far back as 2021. It also highlights some of the difficulties that CISOs have in implementing a cybersecurity program globally. Just remember, any loss of data has an impact on the Company and its brand.

This is nasty. If your device is infected, it watches for stages firmware and opens it and reinfects it on the fly. This firmware update is hardened including File Integrity Monitoring (FIM) and anomalous process detection. Push the update to your SM100 devices. Note that all versions prior to 10.x are EOL.

This story nicely ties to other stories this week. Firewall edge devices and/or VPN devices are at the top of the exploitation list. SonicWall is one of the players that, while seen in Enterprises, you will likely see these in smaller companies, perhaps with MSSPs or with SMB places that may not have a high level of telemetry to go up against nation-state TAs. I suspect this isn’t the end; we will probably see a round-robin of vendors in this space having vulnerabilities be disclosed. One common thing for this is lack of patching and not necessarily a 0 day being used. Many of these actors are just leveraging unpatched systems.

What’s troubling about this campaign is that it took advantage of unpatched edge devices using known vulnerabilities from 2019 and 2021. Maintaining a patch management process has to be near the top of every enterprise cybersecurity program. Harvesting and use of stolen credentials has become a primary attack technique used by evil-doers to get around cybersecurity defenses.

This move is consistent with their requirements for the passenger and freight rail operators and follows the EPAs move to raise the bar for the water sector. If you’re affected by this ruling don’t wait for a deadline to get your implementation plan together. These security measures are core things we all should already be addressing. Hopefully you can report many as complete.

Given the release of the National Cybersecurity Strategy, recent EPA cybersecurity rulemaking, and now new TSA cybersecurity rules, it is time to coalesce on a minimum set of cybersecurity safeguards for all critical infrastructure sectors. Each sector has more in common than not when it comes to cyber hygiene. By standardizing, it becomes easier to measure the state of cybersecurity for our critical infrastructure. A good place to start in creating the minimum set of safeguards is Implementation Group one of the CIS Critical Security Controls.

Given all the airline issues over the last few months, including those surrounding ancient IT systems, it would make sense that more scrutiny in this area is given. This dovetails the executive cybersecurity order that effectively starts to add to what is required of critical infrastructure in the US.

As much fun as it is to find a bypass for required procedures, there are times when you should not. Particularly when conducting an investigation, all actions must be above reproach to avoid having your case torn to shreds or otherwise disqualified. Given the FBI is asking the private sector to work with them to respond to breaches, making choices to ensure their reputation and integrity are beyond reproach is critical.

Location data has increasingly become important to both law enforcement and national security. As such, it is can be monetized with companies now ‘hoovering’ the data and making it available for sale. US privacy laws should be a decision factor in the use of this information by law enforcement.

Fortinet is in the news again. This time it is Fortinet FortiOS with one of two vulnerabilities. One that leads to Denial of Service (DoS) and one that is both DoS and Unauthenticated RCE. I know this patch was out several weeks ago, so if you haven’t patched it by now, please do. It appears that the patch is backported to support older versions, so there should be no excuse to keep your edge firewalls patched. It should go without saying that while these systems can lead to outages, not patching is not the most optimal choice for most users. Get used to patching your infrastructure kit. As a workaround, you should consider not placing your administrative interfaces on the open internet, but for some systems like cloud managers, you may have to do this. However, I advise avoiding placing management interfaces on the open internet if possible.

CVE-2023-25610 has a raw CVSS score of 9.3 and can be exploited without authentication and result in either remote code execution or a denial of service. Apply the patch and lock down your administration interface to only allowed devices. Don’t expose it to the Internet. As Fortinet has released patches for multiple products recently, ask your team if they’ve checked everything you have to make sure that your it overlooking needed updates.

This one will not get the normal treatment from me as this is an actual vulnerability in enterprise and service provider hardware and not in the non-Cisco IOS SMB Space. This one affects devices by sending malicious BFD packets on the network, which the hardware line card processes. Patching would be the optimal choice, but you can only patch this gear in some scenarios with lots of testing. The workaround is to disable BFD processing; just be aware BFD (Bidirectional Forwarding Detection) is used to look for failures on a network. The reason that it's being accelerated is to ensure that the packets have optimum priority on a very busy network. There can be a scenario in a high throughput network where BFD may not detect a failure if it is not accelerated. This is one of those risk scenarios in which you need to weigh in on how to patch and when to patch vs. keeping systems unpatched. This doesn't involve RCE, but a DoS scenario is also not ideal, depending on where this hardware is deployed.

CVE-2023-25610 has a raw CVSS score of 9.3 and can be exploited without authentication and result in either remote code execution or a denial of service. Apply the patch and lock down your administration interface to only allowed devices. Don’t expose it to the Internet. As Fortinet has released patches for multiple products recently, ask your team if they’ve checked everything you have to make sure that your it overlooking needed updates.

All three flaws have vendor updates, so addressing these is straightforward. That said, March 28th isn’t that far off when it comes to scheduling downtime for updates. You probably want one team starting the update/outage request process with another testing the update so you can get these behind you quickly.

The database now has 890 entries. I originally envisioned this as a database of “Currently Exploited” Known Vulnerabilities, but it doesn’t appear that this list is being pruned unless 890 is the right number of currently exploited vulnerabilities. The more that gets added to this database, my feeling is that security practitioners will have analysis paralysis. Is this more important than a CVE Database? It certainly is different, but does it deprioritize other bugs? Is the list being fully pruned? Only time will tell. This is a far fewer number than CVEs, but given how long it existed, the fact that we are currently at 890 does not give me hope that the list is actionable.