Apache ActiveMQ Vulnerability Actively Exploited; Okta Says Breach Impacted 134 Customers

Yes, patching is important, but also: services like this should be tucked away without so much as a public IP, if possible. The list of services mature organizations expose to the public internet are vanishingly few. If you have more than VPN, a website, and maybe some APIs available to the internet, it may be time to reexamine business processes.

CVE-2023-46604, CVSS score of 7.5, remote code execution flaw, allows attacker with network access “to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause the broker to instantiate any class in the classpath.” In short, insecure object deserialization. Current activity to exploit the vulnerability includes attempts to deploy HelloKitty ransomware. Two steps here: 1) Update to a fixed version ActiveMQ or ActiveMQ Legacy, 2) check for IOCs, including the M1.png, M2.png MSI files.

Although MQs should be internal, there are plenty of readily available targets on the internet. Many appear in Aliyun (Alibaba Cloud), which may stem from a potential configuration issue with a standard MQ rollout. It should be noted that these Message Queuing Systems are quite often used with larger applications so that the attack surface would be attractive.

Note that one remediation step Okta took was “Blocking the use of personal Google profiles with Google Chrome” – you may want to take the step. See https://support.google.com/a/answer/1668854?hl=en

While the focus may be on the compromise of an Okta account within a staff member’s personal Google account, we need to ensure our networks and systems are designed to be detect and respond to such abuse. If your environment’s security relies on users keeping their credentials secure, then you are likely to have bigger security problems.

Keeping work and business separated, for example not allowing a personal Google profile on a corporate device is worth running to ground. While it's convenient to allow incidental use, you may wish to put some guard rails around those actions, possibly providing a separate browser environment for that use, and vice versa. We need to include session tokens when considering sensitive data and how it impacts us.

Most interesting thing I learned from this breach was what a “HAR” file is. It’s always great to learn something new that you may have missed. If you are unaware of these, they are handy for support staff but can also be a treasure for attackers.

Unfortunately, creation and use of service accounts is common in providing for automating application access. Often these accounts are poorly configured and lack the ability to enforce with multi-factor authentication. That said, there are some things administrators can do to protect service accounts and it starts with active monitoring of the account.

Many of the vulnerabilities affecting QNAP and similar devices are due to addons. First thing to do is to reduce your attack surface by removing various addons that you do not need. These devices are sometimes just used for a single purpose, like as an iSCSI device or to host backups. In this case, many of the image sharing and other services can be disabled.

Both vulnerabilities carry high CVSS scores and allow for remote code execution. If you use QNAP for your network attached storage needs, download and update your device as soon as possible.

CVE-2023-23368, CVSS score of 9.8, and CVE-2023-23369, CVSS score of 9.0, warrant immediate attention. You need to update QTS, QuTScloud, QuTS hero, and your add-ons, as in multiple steps. This would be a good time to review the apps you've got enabled and remove the ones you don't actually need. Also review your accounts, making sure they are all current and needed.

Google’s response makes it clear that they don’t yet have a fix for this vulnerability yet. Until they do, educate Android users to never allow an app install unless it is direct from Google Play.

This even affects Android 14. The attackers claim their dropper works with Android 7 and above. Your best bet is to only allow apps from the Google Play store and/or your corporate app store. Use caution granting permissions to apps, grant only the minimum access, particularly if accessibility settings are requested. The malware has been seen the dropper deliver the SpyNote malware disguised as Google Translate, and banking Ermac trojans disguised as the Chrome browser.

Microsoft has disputed the severity of the vulnerabilities, and states that one of them is no longer exploitable after a patch was applied in August.

CVE values have not yet been assigned to the flaws. One is a deserialization issue, which could be used to execute code in the SYSTEM context. The remaining three are described as SSRF flaws. Applying the August Exchange update addresses the flaws. Again, time to re-assess running Exchange on-prem. Commodity services, such as email, are worth outsourcing so your staff can focus on mission delivery and supporting systems.

Kudos to Trend Micro for responsibly disclosing the four vulnerabilities to Microsoft. While Microsoft states that the vulnerabilities have already been patched or are not urgent, it’s still a good security practice to download and install the updates as part of your patch management process.

If your department is sufficiently large, it's probably a good idea to have one person playing with quantum-resistant crypto now. We'll all have to make that transition someday, and it has the potential to be incredibly disruptive if we're all caught flat-footed.

This is a very good read. As is this document from Europol on the impact of quantum computing and quantum technologies on law enforcement: https://www.europol.europa.eu/media-press/newsroom/news/exploring-second-quantum-revolution-new-report. Don’t let the title discourage you from reading it as there are some very good insights in that report.

Whether Q-Day is five years or ten years out, it's time to start following this space, identifying places you can test out PQC. Also get a firm handle on what is, and is not, affected. Pay attention to algorithms based on integer factorization such as RSA, and those based on the discrete logarithm problem such as Finite Field Diffie-Hellman, ECDH, DSA, ECDSA, EdDSA. When you're investigating PQC solutions, have frank conversations with your providers on how they are protecting you from changes as implementations finalize, or algorithms become added or disqualified.

For the cryptologists out there, an interesting primer on post-quantum cryptography. To exist securely in a post quantum world will require an upgrade in hardware to support the PQC algorithms. So, if your business provides internet and critical infrastructure services, plan for hardware upgrades in future budget years.

This white paper is well written and an easy read. It demonstrates that the community is responding to this issue in a timely and effective manner. Most of the content is for those who are in charge of infrastructure and the implementation of cryptography, but all of us should read at least the summary at the end of the paper. The net is that for most of us, for whom our use of cryptography is beneath our level of notice, choice, or management, we need not do anything; the necessary changes will also be beneath our notice. That is true for both individuals and most enterprises. The exceptional enterprises are those with bespoke applications of cryptography, or highly sensitive and long lived data of interest to nation states (that are storing encrypted data in anticipation of being able to decrypt it when cryptographically relevant quantum computers (CRQCs) become efficient).

The challenge of how much non-business work you wish to allow on your corporate fleet of mobile devices is ongoing. Regardless of where you fall here, document your decisions and reasoning. Then review it as conditions change. For example, when I first proposed to allow a mixture of corporate and private use, apps such as Signal, WhatsApp and TikTok didn't exist. Consider not only that they could be used to obfuscate company information/records when used, but also, they have access to sensitive information such as location and contacts, and in some cases data sharing with our adversaries. Beyond that, you have pressure from users to carry a single device which "does everything" which is why you need to consider your risks, document them and have them accepted at the appropriate level.

Interesting that ICE policy allowed downloading/use of ‘personal’ applications on government owned devices with little oversight. Simply put, that’s a poor security practice. The user should have no expectation of control over government furnished mobile devices; it’s provided to them for official purposes. The same logic applies for businesses that issue mobile devices to their employees.

This report is about the enterprise risk of user control of enterprise owned devices. The lesson for management of enterprises that permit this is in the highlighted section of the Register article and attributed to an ICE spokesman.