DigiCert Revokes Certificates; Mozilla Announces TLS-Distrust Date for Entrust Root Certificates; Domains Vulnerable to “Sitting Ducks” Hijacking

DigiCert's violation of the CA rules are relatively minor, and highly unlikely to cause issues. However, mass revocations like this can be disruptive for affected entities. One DigiCert customer obtained a court order to delay the revocation. The "CA ecosystem" has been the source of the most significant vulnerabilities in TLS in recent years. Compared to weaknesses in TLS algorithms and implementations, CA vulnerabilities have been exploited regularly. In response, the CA/Browser forum established very strict rules around verifying domain control. Seeing them enforce these rules is a good thing, but I don't think customers are ready for it yet. Expect more revocation actions like this in the future, and get a handle on how you manage the certificate lifecycle.

DC validation is one where they have you create a CNAME DNS record with a specific random value which they used to verify the domain was, indeed, yours. The problem is the random value didn't always start with an underscore, required by RFC1034, which meant it could collide with a legitimate CNAME. The flaw was introduced in a software update back in August 2019, which is now fixed. If you're a DigiCert user, you should have been notified that your cert was going to be revoked, and you needed to take action. The due date was July 31, 1930 UTC. Either check your account for certificate status or do a revocation check on existing DigiCert certificates if you're not certain this was addressed. While there was a delay option prior to the cutoff, if you're revoked the only option is to replace those certificates.

This is a good example of a Certificate Authority having a process in place and then actually taking action if a problem occurs. It is also a good test to see if your authentication processes will actually notice that certificates have been revoked …

Many people got hit with a short notice request to emergency swap their certificates. Be kind to your IT folks between this and the CrowdStrike fiasco; they have been kicked enough this month. For people leaders, how are you managing your individual people contributor’s burnout? Watch for it, as there have been a lot of people running around the last month putting out different fires.

See my comment about the DigiCert revocation. The CA/Browser forum is getting serious about enforcing CA rules. You must be ready to deal with mass-revocations or even CA removals.

If you're using Entrust's public CA for your SSL/TLS certificates, you have two options: Either stay the course, hoping Entrust can convince browser vendors to continue to trust their CA, or switch to a different provider for these certificates. While you can also configure browsers to continue to trust their CA, this is impractical with public/external facing services. While the changes to Mozilla and Chrome are scheduled for November, you probably don't want to wait until then if you're replacing certificates.

(Disclosure: I worked for Entrust in 1998-1999) It is good to see browser providers taking proactive action to assure the quality of certificates. Strong authentication is needed both to fight ransomware and to enable persistent ubiquitous data encryption. If you are at renewal time for Entrust certs, read their statements on how Entrust-branded certs will be provided in the interim.

This may be a first: a CA that has failed to meet the requirements set forth for EV certificates. This ends Entrust’s Root CAs. Google already removed them from the trusted list in Chrome.

Some finger pointing by Entrust but in the end, the right call by both Firefox and Google. This ends over 20 years of trust in the Entrust name but proves that oversight has a role in something as important as a root CA.

Remember that once you start using a new domain "for real", you are pretty much obligated to maintain it indefinitely. Even our honeypots, in particular those located in cloud environments, often see "orphan" DNS requests to IP addresses no longer acting as an authoritative DNS server for the particular domain. You must maintain a minimum DNS infrastructure even for inactive domain to prevent them from being taken over by others.

There are several scenarios that enable this attack, such as sub domains with different DNS servers or abuse of a stale/forgotten configuration allowing an attacker to leverage a typically expired domain. Check the security of your domain provider when you use a separate provider for DNS, validate your DNS delegation, particularly to services where the accounts may no longer be active or in your control, and check your DNS provider for mitigations for the Sitting Ducks attack. Additionally, you can leverage the free monitoring services from the Shadowserver Foundation to detect this attack.

This is a fascinating vulnerability. Please be sure to look at the issues with each DNS provider you are concerned about. I found one in which the “vulnerable” category was placed, but it had false positives because the responses that came back were different. This is to say that just because you are marked “vulnerable” does not mean you are exploitable, which will confuse everyone.

This update is particularly interesting for users of older devices. Apple included patches for an already exploited vulnerability. Current operating systems received these patches a few months ago, and now Apple is providing them for older versions as well.

Patch all your mobile devices, Laptop, iPhone, iPad, Apple Watch, Vision Pro, etc. before heading to Las Vegas, even if you're planning to keep them offline or in Airplane mode. These updates address a number of CVE's, some of which apply to multiple products. Note that fixes were applied to iOS/iPadOS 16 for the older devices. Even if you're not on the go, take a second to update. Don't miss the separate Safari update for macOS 12 & 13.

Just in time for Hacker Summer Camp! If you're on IOS, patch; it should be set as automatic.

Digitizing car titles is only part of the story. The use of the Avalanche blockchain to support the system, which will be connected to an app and digital wallet, has the potential to not only speed the processes around titles, but also make fraud much more difficult with immutable records in place. Note the system for owner access won't be in place until 2025.

We are about to determine how solid Blockchain is to verify ownership. I guess this is a risk if there is no other paper trail …

Stuart Haber, one of the inventors of blockchain, reports that many of the proposals that he has seen for the application of blockchain do not benefit from it, could be done with conventional databases. One wonders at such a directive. Rather, what is needed is permission to use it for appropriate applications.

n addition to asking affected hospitals to activate their shortage protocols, they have also reverted to manual mechanisms so they can continue to collect donations, albeit at a dramatically reduced rate, while resources like the AABB Disaster Task Force and Blood Centers across the country are routing blood and platelets to OneBlood. While it's not yet known which ransomware gang is behind the attack, given the criticality of the blood supply, it's safe to assume they see a high likelihood of a ransomware payout. There is an urgent need for O (positive and negative) as well as platelet donations; it is not a bad time to go to your local donation center and help out.

In today’s era, failover to manual processes will impact business operations. Work that into your disaster recovery plan. As far as the ransomware gang, shame, shame, shame.

Given Microsoft's claims of robust DDoS protections, this is a bit awkward. That the flaw in implementation amplified the attack rather than mitigated it is a distraction. Trends show the duration of DDoS attacks is shrinking, likely attributed to effective countermeasures. The thing to do here is ask those providing DDoS services for you about their testing and guarantee of effectiveness. Make sure you've got coverage for in-house and hosted (cloud or outsourced) services.

Definitely not on the scale (time and reach) of the recent CrowdStrike meltdown but impactful nonetheless. This continues a trend, industry wide, where internal quality assurance processes have not been fully implemented. Unfortunate for MSFT it keeps them on the cyber news cycle.

This three-year pilot program is evaluating the effectiveness of using the Universal Service Fund to support eligible cybersecurity service and equipment and how that raises the bar for schools and libraries. The pilot has a $200 million funding cap, which they are expecting to allocate to schools at $13.60/student, annually, with a minimum award of $15,000/year as well as a maximum award of $1.5 million/year. Library funding is based on locations and square footage with a range of $15,000 to $175,000/year. This is separate from the funds which provided for broadband connectivity to schools. If you're a school or library, which are currently ransomware targets, this could give the hand-up needed to implement needed protections.

Finally additional, new money, to support the cyber underserved. As a first step, K-12 schools and libraries should conduct a risk assessment to outline gaps in their cybersecurity program. If schools and libraries need help with the assessment, leverage the Multi-State ISAC for assistance.