Google Warns of ccTLD Registry Hijacks; FortiBleed Attacks Continuing; Android Phones Shipped with Malware Pre-installed

Effectively a DNS hijack allowed certificate issuers’ domain validation checks to pass, allowing for bogus certificates to be issued. This leads to three things you need to do: First, deploy the updated Chrome/Chromium, which is likely an automatic process; second, monitor the domains you own to make sure they aren't getting hijacked; and third — this is likely new for you — implement CAA records that limit which certificate authorities can issue certificates for your domains, to include specific accounts and validation methods. CAA records are DNS records, so during a hijack they are not available, but when the service is restored, it'll help by not allowing cached validations to work, stopping additional certificate issuance. These steps are defense in depth; none is a 100% fix, but you're raising the bar.

This keeps happening to country code TLDs more often than other TLDs. ccTLDs were established "in the beginning of the internet" and do not always obey the modern rules of how TLDs are operated. With DNS often being used as a "proof of ownership" of a domain, DNS tampering can also affect the issuance of TLS certificates, which in some ways is supposed to be a backup for DNS in establishing if you are connecting to the correct site.

A sophisticated supply chain attack likely used to harvest credentials to facilitate malware distribution or phishing campaigns. As Google notes, the third-party operators managing these three country code top-level domains failed to implement reasonable cybersecurity standards. While these operators ideally should be delisted, contractual entanglements make that outcome unlikely. If you suspect you may be impacted, reviewing certificate transparency logs is a critical precautionary step.

Johannes's point about the way some ccTLDs are operated is a good reminder that a chain is only as strong as its weakest link, and attackers are relentless about finding that link and exploiting it. Many of the other links here are pretty darned strong, but compromising the registry layer let the attackers change authoritative DNS and then obtain certificates through the normal validation process for names they had temporarily taken control of. You can secure the site and still lose the name. Certificate Transparency monitoring matters here, but so does treating registrars, registries, DNS, and certificate issuance as one connected trust chain. Domain security does not stop at the domain owner.

Go back and read those numbers again: 86,600+ devices in 194 countries compromised. Yes, this is an attack on the SSL VPN service, which does need to be exposed to the Internet, but the management interface does NOT. We must make tight restrictions to management interfaces SOP. At this point, if you've got any form of remote access, make sure that all accounts, with no exceptions for special accounts/users, require phishing-resistant MFA. If you're a Fortinet shop, hunt for the IoCs in the IC3 advisory and verify all the mitigating steps were completed.

Continued reliance on replay-able credentials is reckless. All of our readers should already know that.

Ouch. This one is painful to read, and it worries me well beyond this particular malware campaign. The user did not install the malware; it arrived in firmware as a platform-signed system component with privileges ordinary apps can never obtain. The attacker has a foothold before the owner ever turns on the phone. At that point, app-store hygiene, careful permission choices, and all the other things we teach users cannot fix the root problem. If we cannot trust the software installed before first boot, everything above it inherits a compromised foundation. Supply-chain trust has to reach all the way back to firmware, signing, and the manufacturer building the device, or else we're cooked from the get-go.

Inexpensive Android devices, whether smartphones, car infotainment systems, or streaming devices, continue to come pre-loaded with malware and other unexpected "features." This is a supply-chain challenge; the malicious apps are embedded/pre-loaded in the firmware, possibly unbeknownst to the OEM, and there isn't much you can do to eliminate or even detect it. Do yourself a favor and stick with mainstream devices. Recovering the shenanigans of the malware will more than consume the cost difference.

The old adage, "You get what you pay for," pretty much sums this up. The interesting part is figuring out where the threat actors managed to compromise the MediaTek chips. Did they slip in through MediaTek's configuration control, the OEM, or an outside design house? Hopefully, MediaTek and the OEMs dig into this together. But when you strip it all away, it was just about cashing in.

The Android supply chain is very complex and risky. While there will always be individuals compromised, enterprises should identify a safe channel and require its use.

We were just talking about this PeopleSoft vulnerability in recent NewsBites issues, including why a WAF rule is a compensating control rather than a substitute for fixing the underlying flaw. Now comes the painful case study: A patch existed, a contractor failed to apply it, and the FBI was breached. You can outsource administration, but you cannot outsource the responsibility to carry out the security obligations you've accepted. Based on what has been publicly reported, I applaud the FBI for taking decisive action here. Removing the contractor sends an important signal to the broader government contracting community: Cybersecurity obligations are actual obligations, and failing to carry them out can have real consequences.

We're pretty good at tracking vulnerabilities and patching our hosted systems, but how about third-party/cloud services? Then what happens when they fall short? Having consequences for failing to maintain security controls is vital. While I don't advocate for terminating contracts or employment without cause, it's a good lever to have when you need it. Find out, likely from HR or legal, which policies carry the (possibly unspoken) consequence of "up to and including dismissal." You may want to add some cyber policies to that list. Then get with your contracting office to review your standard terms to make sure you're covered there as well. Don't forget that a contract worker is a procurement, not a hire.

It should not be news when a contractor is removed for enabling a breach; it should be a standard term in contractual agreements. Failure to patch and other common causes (like use of embedded passwords or lack of strong authentication for admin users) are evidence of lacking the essential security hygiene that should be required of all supply chain partners.

Accountability is an essential control. It is necessary for privileged entities and may be the only one that really works for them.

One detail here deserves attention: The attacker used a legitimate customer communication channel to send the malicious message. Once someone can push notifications through your official app, they're borrowing your brand's trust at scale. Treat customer messaging platforms like high-impact production systems: phishing-resistant MFA, tightly controlled administrative roles, approval workflows for mass sends, and alerting on unusual campaigns. The message may be fake, but the channel is real.

This was a multi-pronged compromise. Credential theft and third-party service compromise. An ASOS employee's credentials were obtained via social engineering, and the credentials were used to access information on third party platforms. You know what I'm going to say — you need to make sure that you're requiring phishing-resistant MFA everywhere. Be sure to close any gaps, including updating less secure MFA implementations. Then think about how ad-hoc access is granted; for example, do you provide a remote support desk admin with (reusable) credentials so they can just login and figure out the problem you reported? Have a policy on how those engagements are handled.

It's no surprise that cybercriminals are willing to loudly announce their thefts if it helps them force a payout. Beyond that, the rest of the incident is the same old story: phishing for initial access, followed by a pivot to privilege escalation.

Looking at the SonicWall site, it looks like AI-assisted firmware analysis was used to find these flaws, which means that you need to be on the lookout for more updates due to more frequent vulnerability discovery. If you have an SMA1000 Model 6210, 7210, or 8200v, apply the platform hotfix to get on the latest firmware. No workarounds; get this done before your coffee gets cold.

Apropos of nothing... Do customers ever go to sites like cvedetails.com to look at vulnerability trends before investing in a particular vendor?

Looking at this you are probably saying, wait, there are already NIST standards for control systems, OMB policy requiring implemented security controls before systems are authorized to operate, as well as BODs about risk-based approaches and resiliency — so what's up? In short, the OTCC is saying that agencies are not voluntarily implementing needed security controls for critical infrastructure, so publish a BOD that requires standards to be met, and includes required reporting, monitoring and consequences against those goals. The OTCC memo makes good points about how we should be securing and improving resilience of our critical infrastructure; given the number of privately operated utilities and critical infrastructure, it's not clear that the issues are at FCEB operated systems. The hard part, once a path to required implementation is established, is having this viewed as an unfunded mandate rather than re-enforcing needed security best practices.

I'll leave the specifics of whether a particular regulation or Binding Operational Directive is the right mechanism to the policy folks. But the architectural principle here is extremely important. The Cyber Informed Engineering goal that no cyber pathway, regardless of access level, should be able to cause physical destruction beyond the engineered safety envelope, deserves attention. For generations, engineers have used things like pressure relief valves, mechanical interlocks, and physical damping systems so that a failure does not automatically become a catastrophe. We need to preserve and strengthen analogous independent safety mechanisms as physical systems become increasingly digitally controlled. Cyber controls should reduce the chance of compromise, but engineering should also constrain what a compromised digital system can physically make happen. Assume some cyber controls will eventually fail, and engineer the physical process so that it still stays safe.

Having worked on a lot of segmentation projects, both macro and micro, the phrase "pragmatic microsegmentation" is a bit of an oxymoron. These projects are notoriously difficult to actually implement, due to the amount of upfront work required if one wants to avoid blocking legitimate east-west traffic; think of your worst asset management and networking projects, then slam them together. Macro segmentation is hard enough, and micro segmentation at an org below the security poverty line is... not a realistic expectation. It's not even a realistic expectation at many well-financed and staffed security teams.

Many industry professionals know what needs to be done, but resource and political roadblocks are real. Hopefully this effort will help some practitioners in critical infrastructure get leadership emphasis to raise the minimums for security practices. (Don't tell anyone, but a sizeable portion of pentesting happens for very similar reasons!)

Critical infrastructure has faced sporadic attacks for close to ten years. For just as long, experts have pushed for a minimum baseline security standard. But instead of spinning up yet another framework, why not use what's already out there? The truth is, the safeguards and controls needed to protect critical infrastructure are already written.

BODs are only mandatory for the government. That is not where the OT problem is. OT is sufficiently mature that we, specifically to include management, only notice it when it fails.

This is a positive move by the Senate, though the House is unlikely to take it up until after the new year. Rather than tasking HHS with defining minimum cybersecurity standards, lawmakers should simply mandate the top two or three globally recognized frameworks (i.e., NIST CSF, ISO 27001, CIS Critical Security Controls). Any of these would easily satisfy the baseline requirements outlined in the Senate bill. Several states have already adopted this approach in their data protection laws, meaning private healthcare entities in those regions are already measuring themselves against these established frameworks.

HIPAA privacy and security was well intentioned. In an effort to not be prescriptive, it asked covered entities to do a risk assessment and act accordingly, something that many, not to say most, were not equipped to do. Not only have all the bad things that it was intended to prevent happened, but the uncertainty that it created delayed the implementation of electronic health records by more than a decade. Perhaps at the time of HIPAA adoption we did not know enough to prescribe, but we do now. This bill seems to authorize and demand that we do so.

With all the healthcare breaches, we need to raise the bar on their security. With luck this bill will get passed, giving some ammunition healthcare facilities can use to leverage raising the bar versus continuing to push back. With luck this will lead to programs where facilities can apply for grants or other help to get there from here.

Despite many healthcare-related breaches, there's been a lack of progress raising the bar in healthcare security over the past several years. While this bill does not go very far, it would be good to see legislation finally passed to nudge the bar higher.