Check for and Fix Insecure Direct Object References in Web Apps; New Ivanti Vulnerability Amplifies Risk; Faster Patching and Broader Fixes Critical to Mitigating Software Risk

These IDOR vulnerabilities were an entry in the OWASP top ten for many years, then were merged into Broken Access Control back in 2017. OWASP still has a good cheat sheet on IDOR at https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

The guidance comes down to suppliers using tools to detect insecure references, and using indirect reference maps to ensure IDs, Names, and keys are not exposed in URLs. Consumers evaluate web apps, prioritize those with best practices for SCRM, and keep them patched. Leverage OWASP and this guidance developing and accessing applications for security. IDOR is only one aspect of secure application development you need to track, don't get tunnel vision.

This second vulnerability is useful to attackers after they compromised a system using the initial authentication bypass. The new vulnerability requires admin access to exploit and is particularly useful for attackers attempting to establish persistence on the system. It should still be patched, but disclosure of the vulnerability is most important to incident responders attempting to contain an Invanti Mobileiron compromise.

This flaw (CVE-2023-35081, CVSS score of 7.2) requires an authenticated administrator to exploit but allows arbitrary file writes on the EPMM server. Make sure that you're on at least EPMM 11.8.1.1, ideally 11.10.0.2. As EPMM can manage not just your smartphones, but also your Windows and Mac systems, you need to be sure that you're including them in your consideration of the risk of compromise.

Unfortunately, of late, Ivanti products are on the receiving end of some ‘real-time’ pen testing. As with previous guidance, if you have been actively exploited, move to the top of the priority list and patch now.

When purchasing an Android device, it is important to select a device that will receive timely updates for the expected lifetime of the device. Your best bet are devices participating in the "Android One" program or devices marketed by Google directly.

Google has a good recommendation for you and for your software vendors: (1) Patch faster and more thoroughly and (2) Require all software vendors to release broader mitigations to make whole classes of vulnerabilities less exploitable, vs. simple patches that mitigate one attack but not the entire class of risk.

Patch lag in the Android ecosystem is a function of OEM's having to verify updated AOSP code from Google before making a patch available to their users. The tightest cycle is going to be for Google produced devices. Even so it's not all doom and gloom: talk to your enterprise Android suppliers about mitigations, such as sandbox or other security around corporate data, to mitigate some of the risks, as well as any choices that can reduce the interval on patch availability, such as unlocked devices that don't have carrier provided apps adding another layer to the regression testing process.

As a society, we continue to have a problem with updating software in a timely manner. Couple that with vendor rush to issue fixes for vulnerabilities and the annual Google Zero-Day report makes perfect sense. Vendors accelerate testing of fixes, often missing the root cause of the vulnerability. It’s understandable: they want to limit the attack surface. Meanwhile, cybercriminals pore over the original vulnerability and find ways to continue to exploit its root cause.

So far, the most scary part about this incident is Microsoft's continuing silence. Microsoft neither prevented, nor detected the compromise, and the continuing silence may indicate difficulties explaining what exactly happened.

Certainly, Microsoft has some explaining to do on how the MSA encryption key was protected and that may give rise to a failure to demonstrate a standard duty of care. That determination will most likely be made by the court.

US politicians of all types have long failed to enact any legislation that would support liability being assessed against software vendors. That is a necessary starting point for more than just posturing.

To quote from Spiderman, “With great power, comes great responsibility,” and the issues raised by Senator Wyden highlight to all cloud service providers, not just Microsoft, that if they want customers to engage with their services, they need to take the security of those services seriously.

While Microsoft is an easy target here, it's important to hold all cloud service providers equally accountable for cybersecurity to ensure they have a stake in the game. While there is little we can do about that, you can make sure that you've properly secured and approved cloud services, to include incident response and log file ingest capabilities. Even if you're using FedRAMP (or StateRAMP) cloud services, there are customer controls that must be implemented and verified.

There have been a number of cyber workforce development studies completed in the past two years; add this to the growing number. All seem to focus on familiar themes: 1) practical skills in addition to academic degrees; 2) public-private sector partnership; 3) education starting with K-12; and 4) need for additional funding. Now comes the hard part: actually implementing the strategy and showing results.

The EU Agency for Cybersecurity, ENISA, has published a similar skills framework for cybersecurity; the European Cybersecurity Skills Framework (ECSF) and is available at https://www.enisa.europa.eu/topics/education/european-cybersecurity-skills-framework. It outlines the various key roles in cybersecurity and the skills required for each one, together with a compendium of courses available to acquire those skills.

The trick is not only infusing everyone with needed skills, but also getting newly trained resources into the work force sooner than later. Some universities, such as Boise State, have developed both graduate and undergraduate programs focused on getting students prepared for cyber security positions, with a tight focus on skills needed for our industry. This strategy should empower these as well as other avenues to generate needed workers. If you're not talking to your local universities and community colleges about your current and future needs, you're missing an opportunity as they will also need your expertise to succeed.

According to a recent discussion on LinkedIn, experienced people are unable to find employment. Perhaps the real problem is not the absence of knowledge, skills, and abilities but an ineffective marketplace.

It appears the attack was initiated by leveraging a vulnerability in their CheckPoint firewall, a reminder to prioritize perimeter security: not just patching vulnerabilities, but also verifying that you are using current best practices securing them so you're not caught flat footed. Double check that your OT systems are suitably isolated/segmented, then evaluate the security of those systems that can interoperate with them. Think trust but verify and don't assume.

We’ve seen a rash of DDoS attacks play out over the last couple months, but this one appears to be that of a classic data breach. The owner/operator has voluntarily geo-blocked the site while it performs incident investigation/response.

Requiring a reason for using APIs that could compromise privacy is a no brainer, but meaningful enforcement is a complex issue. Evil app developers could pick reasons for such use from Apple’s approved reason list – somehow Apple has to make a determination that those reasons are valid for this particular application, or the whole thing is just a “answer all the questions and no one grades the answers” exercise.

The rationale has to be in the application manifest, starting this fall. Come spring 2024, you have to have an approval for that API use. The validation will be incorporated into Apple's historically opaque approval process for allowing apps in the Apple App Store. Apple also states the approved API may only be used for declared purposes, you many not use the APIs or derived data for tracking. While it's not clear how Apple will police their use, raising a bar in the integrity of these APIs is a move in the right direction.

This one serves as a reminder that with some level of remote work being the norm, it may be harder for co-workers to get suspicious and less convenient for them to tip off IT or IT security when a coworker seems to be doing something odd. In most insider cases, the logs had data showing something is up – closing the gap may require more tools that will spot anomalies and suspicious patterns.

More important than the information being taken home was the red flags in the employee’s behavior, to include working odd hours, being arrogant, frequent lies, display of inappropriate workplace behavior and sexual harassment, financial problems, and possessed company equipment. In addition to being careful about allowing work from home on sensitive systems, an eye must be kept on behavior which can indicate inappropriate activity is happening or could be triggered.