Prioritize Patching of all iOS and Android Devices; Are Your Crash Dumps Giving Away the Keys to Your Castle?

You probably want to have these vulnerabilities patched by the weekend. Note that Apple will likely release major operating system versions within a week or two. It will be interesting to see if these new versions arrive with patches for these vulnerabilities.

While there are only two vulnerabilities, CVE-2023-41064, Buffer overflow in ImageIO and CVE-2023-41061, a validation issue in Wallet. One or the other exists in the updated iOS/iPadOS 16.6.1, macOS 13.5.2 and watchOS 9.6.2. Queue these up for pushing to devices as soon as they are available in your MDM. Odds are iOS/iPadOS 17 will drop next week, you want to get these updates out, so you have time to not rush the decision to pull the trigger on iOS/iPadOS 17.

See item below about critical Android vulnerabilities needing priority patching as well this week.

It was very important for Microsoft to shed some light into what exactly happened. The explanation sounds reasonable, but Microsoft admits that its logs were incomplete due to its limited log retention. I find it interesting that the adversary noted the key embedded in the crash dump.

Several takeaways: (1) Are you exposing keying material/auth tokens in crash dumps? (2) Are crash dumps ending up in exposed network segments? And (3) Has your business made it too easy for consumers and workers to simultaneously be customers and employees?

This isn't a case of just one thing allowing that key to be compromised. Multiple factors led to the disclosure, all of which have been fixed. Read the Microsoft analysis and consider how your secure environments could be impacted through inadvertent data transfer to less secure environments. Crash dumps have historically contained a lot of sensitive data, which makes them useful for analysis and debugging, make sure that you're considering that when moving or sharing them, internally and externally, particularly with third parties , make sure that you're aware of access, retention and protections before just sending dumps or raw log files.

If we are to take Microsoft at their word and no reason not to, an unfortunate sequence of events coupled with a generous amount of luck by the adversary in finding the signing key in the crash dump. It does beg the question why the signing key would have been in the crash dump to begin with, but it is what it is, and it has now been corrected. I do applaud Microsoft for describing the sequence of events, even with the likelihood of facing additional ridicule.

Kudos to Microsoft for sharing this report and the technical details. It is well worth reading this report as it highlights how an advanced attacker can rely on dwell time and their skills, not to mention some luck, to compromise a target.

This seems like a highly unlikely congruence of failures and events that explains in part why it has taken Microsoft so long to inform. There are two lessons for the rest of us. Signing keys should not be online when not in use and strong authentication is essential for all personnel. The lesson for Microsoft and its competitors is that their signing is a sensitive application: it plays a role on which their customers, indeed all of us, depend.

Seems like both Android and iOS have seen a lot of high severity vulnerabilities discovered. Given that a very high percentage of user and business transactions have moved from Windows to those two operating systems, that makes sense – and demands that “time to patch” for phones and tablets be shortened.

With both Android and Apple updates this week, it's a good time to get those pushed out to your fleet of devices. Make sure you're casting the risk of patching/updates commensurate with the amount of business conducted on these devices.

A particularly tough security fix month for Android. This coupled with an increase in Apple iOS vulnerabilities begs the question, are we seeing a transition in how adversaries target organizations. The reality is that more and more business functions are carried out using mobile devices. The adversary is simply shifting their tactics to this new reality.

Many of the nerds and geeks that have been the great champions of Android (and other open systems) are able to assess the risk of using it and use it accordingly. This includes configuration management and timely patching. Most of its users, specifically including children and the elderly, are not so able. Those who sell Android to such users should provide stable and reliable configurations and maintain such configurations on a timely schedule.

The four day reporting clock doesn’t start until a management decision is made that an incident is deemed “material.” I think the worry that such decisions by corporate management will be rushed is overplayed – past experience has been more that early estimates of impact usually turn out to be lower than actual financial impact.

If you're publicly traded, of any size, you need to read and understand these rules. Effectively you have four days to report any incident which is "material" in nature. Make sure you have a clear understanding of what material means as well as what you're expected to report and how. As you refine your working definition of material, make sure that your legal team is involved. Note that in addition to the reporting rule, requirements about describing your cybersecurity risk management strategy as well as board/management role definition in their oversight in cybersecurity went into effect on the 5th. Make sure that what you report is defendable as meeting requirements as well as able to survive an audit.

And so it begins. I do hope that the SEC anonymizes the risk management strategies into some sort of annual report. We can all benefit in learning how publicly traded financial companies manage cyber risk and perhaps apply that to other industrial sectors.

Herein lies one of the principal concerns in using open-source software; for critical vulnerabilities, who is on point to develop and release a patch. Notwithstanding a White House meeting last year with agreement by commercial software vendors to ‘stabilize’ open-source products, vulnerability management is still a problem. With the vulnerability disclosure certain details are now known with no patch available. For those 15 million websites, buckle up, mischief and mayhem are heading your way.

CVE-2023-2453, local file inclusion, CVSS score 8.3, CVE-2023-4480, arbitrary file read, CVSS score 5.2, both don't have patches. The file inclusion flaw requires an authenticated user, at any level, to exploit, the arbitrary read flaw requires admin access. While you can mitigate the local file inclusion flaw by disabling the Fusion file manager, you may not be able to live with the reduced functionality. It may be simpler to leverage a WAF to block nefarious attempts to exploit either flaw until a fix is released. Also make sure you are reviewing user accounts to make sure they are all legit.

It is worth noting that this is not how you keep your regulator at bay. BaFin states they did all the right things to prevent a DDoS attack, and even so, they were impacted. Keep an eye out for lessons learned from them. In the meantime, make sure you're doing all the right things, and get a list of what that means to your staff. Walk through your environment(s) to make sure nothing is left without protection.

There has been a serious uptick in DDoS attacks globally over the last few months. This event provides an opportunity for organizations to revisit their risk mitigation procedures against DDoS attacks. One question to be answered, what is the SLA with the service provider to limit the effect of a DDoS attack on business operations.

Back in October 2022 CISA put out guidance essentially telling agencies to look at existing service offerings to protect high value assets against DDoS and other attacks. Not sure there is really much need for a lot of risk assessments now – just clean the pipes.

Public or private sector, the guidance is relevant. Use the process to assess the impact first as that factors into your consideration of mitigations, on premise, cloud or CDN based. Note the trade offs and considerations for each option listed.

The frequency and duration of DoS attacks is sufficiently high that most enterprises should plan for them. Mitigation may involve upstream providers who should be included in the planning.

The risk is that the MIIT data is shared with state sponsored threat actors, allowing for targeted attacks, likely faster than patches or fixes are released, let alone implemented. Consider which platforms or products you're using which fall under this VDP and evaluate those relationships. Even if you change nothing, note the risk and make sure it's accepted at an appropriate level.

A valuable report that highlights how nation-state’s can use their laws to essentially ‘weaponize’ vulnerability disclosure for their advantage. This presents an opportunity for aligned nations to flag this law as problematic and offer to work towards standardizing a reasonable vulnerability reporting requirement available to every nation.