How likely is successful mass exploitation of PHP2SHELL?

Never in a high alert scenario should be try and be too solid with our predictions, because this game is difficult! but given PHP2SHELL day is such a mad day, I’m going to break my typical model, however:

Personal view: this is a HIGH ALERT scenario but not an ACTIVE EXPLOITATION scenario (at the time of writing), so this is SERIOUS and requires paying attention to!

but the question, how likely is this to lead to mass exploitation? is there REAL tough and serious question we have to ask when considering the wider landscape of national security etc. so I’m going to at least explore it a bit!

Read more “How likely is successful mass exploitation of PHP2SHELL?” →

Upgrading to PHP 8.5.12 Backports

Ok so, some fun notes:

Cloudflare deployed blocking rules at about 1500 today!

Ubuntu back ported the fixes so this server is now patched!

The world, so far hasn’t ended!

Pwndefend stayed online, whilst many others… did not! That speaks volumes for their defence in depth perhaps….

Let’s see where this PHP cyber journey will go!

PASSKEYS ARE NOT A TRAP

This is one of the strangest takes on security I’ve seen in a while: passkeys are a trap, do not use them (WTF).

It’s 12 pages and over 4,000 words, an essay mixing real facts with a lot of invalid and odd reasoning. Not everything in it is untrue, which is what makes it slippery. Here are the claims that make up the main bulk of the argument, and why they don’t make sense:

1. “2FA and TOTP are the superior option, and FIDO ignored them.”
TOTP can be phished by relaying the code live. An attacker proxy forwards your password and your six digits to the real site and keeps the session. The 30-second expiry is irrelevant when the attacker uses the code immediately. FIDO’s own U2F predates passkeys and was built to fix exactly this.

2. “Transferable versus non-transferable passkeys.”
A non-exportable hardware credential can’t be moved by definition. It’s a distinction invented to make the catalogue look bigger.

3. “Attestation comes with passkeys whether you want it or not.”
It’s optional. A site asks for it at registration, and browsers gate identifying attestation behind a consent prompt. As far as I know, the synced passkeys most people use offer little or none of it to sites.

4. “Sites will quietly start rejecting non-attested passkeys in staggered waves.”
Attestation is returned once, when the credential is created. A site can’t retroactively demand it from existing passkeys. It would have to force everyone to re-enrol, which is anything but quiet. His own footnote 9 admits sites can’t even check who would pass.

5. “Attestation needs your chip, passkey manager, OS and firmware to all pass.”
That describes Play Integrity and App Attest, which are different mechanisms. WebAuthn attestation identifies the authenticator, not your whole stack. Android key attestation does include boot state, but it describes a key, not what’s installed on your phone.

6. “Attestation lets vendors block encrypted messaging and rival apps.”
It doesn’t inventory your software. Any vendor who wants to gate on device integrity already has Play Integrity and App Attest, and not a single passkey is needed for that.

7. “Attestation lets Google lock out other browsers and extensions like uBlock Origin.”
WebAuthn doesn’t attest the browser. The uBlock Origin removal was a Manifest V3 decision with nothing to do with authentication.

8. “A YubiKey avoids the attestation problem because it’s self-contained.”
A YubiKey in FIDO mode is a WebAuthn authenticator. It’s exactly the kind of device an allowlist would admit. If attestation is the threat, the recommendation doesn’t avoid it.

9. “So don’t use passkeys. Use TOTP.”
The conclusion is to prefer passwords and TOTP, which are phishable, over passkeys, which resist phishing through domain binding. For the non-technical audience he’s writing for, the real alternative is a reused password with SMS as the second factor.

Underneath it all, the objection is distrust of the FIDO Alliance, distrust of service providers, and loss of control. But a service has always decided who gets in. It can disable your account, set password rules and force MFA. Choosing which authenticators it accepts is the same kind of decision, and it concerns their service, not your device. He even tells readers to put on a tinfoil hat.

The lock-in worry is fine to have, there are potential risks with implementation with some providers (but that’s always true whenever you use a third party service!). “Don’t use passkeys” is the wrong conclusion, and the essay gives the game away itself. Footnote 13 admits passkeys are domain-bound and resist man-in-the-middle attacks, and the opening concedes they can be far more secure than passwords.

So in short: they even tell you, passkeys are more secure and more convenient.

The more I look at the 12 pages of essay (and god there are footnotes!) the more I just want to block the URL… so so so many words, to self own!

I use passkeys! I broadly believe that without specific requirement statements, I’d say: default to passkeys! Are they perfect? No, are they better than username and passwords for most things? sure! Do you need to ensure you have a plan for failure scenarios? 100% that’s true of basically everything! We have backups as a concept for a reason!

This was attempt 3 of this response, I decided an essay on an essay is probably not the right approach, drowning in words doesn’t change the facts! Once again, it seems like we spend more time combatting myths than fighting baddies! A strange cyber world we live in!

Anything you can do, we can do worse!

‘On July 21, OpenAI disclosed that several of their models had broken out of an isolated test environment by exploiting a previously unknown (“zero-day”) vulnerability.’

But wait, it appears if one AI LAB having terrible security practices isn’t enough, we have another one now saying, after the Open AI incident, they have actually reviewed their logs, and they are terrible at security too!

Read more “Anything you can do, we can do worse!” →

Vulnerabilities found with AI, oh my!

Ok, so the world is currently obsessed with AI (at least the digital world…) and with the latest Apple update releases we can see that LLMs have been used to help people find bugs! This is great news, finding bugs is better than not finding them!

The funny thing however is the obsession with CVE counts…. this is, honestly not a very useful metric to a defending org.. and I’ll try and explain why!

Read more “Vulnerabilities found with AI, oh my!” →

You Cannot Block Infinity

We should block the RMM! We should block that IP! We should block that port! The trouble is; there’s 65535 ports per protocol (TCP/UDP), there’s billions of IPs (dynamic and rotating infra are a thing), and well that’s a lot of work, neve ending, in fact!!

This topic has come up a number of times recently so I thought I’d put it into a blog, so I had Claude generate this based on my quick fire views:

Read more “You Cannot Block Infinity” →

You Can’t Defend Everything: Threat Modelling as an Economics…

In a world now seemingly filled with mad probability robots you might think this makes the world simpler, I’m not so sure…. More code, faster, more tools, faster, more technical debt, faster… and then what of the erosion of the human importance? Well human 2.0 is probably augmented not redundant… and who doesn’t love a bit of Deus Ex! Now full disclosure this blog is guided by me but written by Claude (mostly), why? Why not? I’m still here, guiding things, writing this intro by hand, but the concepts of cyber security, the foundations and underpinning logic, well they are probably older than me! I’m not talking about castles and moats, but even they play a part in our understanding of attack and defence. There’s even a bit of a public wifi link here if you read between the lines. Not every threat actors is all knowing and all powerful (in fact no one is!). So let’s see what Claude Opus 4.8 has to say about the topic:

Read more “You Can’t Defend Everything: Threat Modelling as an Economics Problem” →

Cyber Myth: Attackers only have to be right once,…

Our cyber world is full of myths and FUD:

Attackers only have to be right once, Defenders have to be right all the time!

Firstly, let’s cut straight to the chase, I can only assume that someone who says this is ignoring or is unaware of how computer systems and intrusions work. But surely this is a true phrase, I’ve seen it repeated over and over again on LinkedIn, so it must be true right?

Read more “Cyber Myth: Attackers only have to be right once, Defenders have to be right all the time!” →

Email Security: An Enablement Journey, Not a Maturity Ladder

Most organizations treat email authentication as a checkbox exercise. Deploy SPF, publish DMARC in reporting mode, call it done. But the real story isn’t about maturity tiers—it’s about what you unlock at each phase of implementation. And frankly, the gap between where organizations are and where they need to be is brutal.

This post outlines an enablement journey: each phase builds on the previous one and creates new capabilities that weren’t possible before.

Read more “Email Security: An Enablement Journey, Not a Maturity Ladder” →

DNSSEC

‘You are totally compromised!’ because you don’t have DNSSEC configured on domain…..

The implication is that you’re one packet away from catastrophe. It’s alarming. It’s also, for the overwhelming majority of organisations, not true. I have been talking about this for years and years!

Here’s the quickest way to see through it. I scanned the Majestic Million – the top one million domains on the internet – for DNSSEC. About 6.75% were signed (around 8.2% if you only count domains that actually resolve). The .com zone, which is half the list, sits at 4.6%. And the unsigned set includes google.com, amazon.com and microsoft.com.

So if “no DNSSEC” means “totally compromised,” then the three most-attacked, best-defended companies on the planet are totally compromised, and have been for years, on purpose. They aren’t. The finding is measuring conformance to a checklist, not risk. Let’s understand why this is!

Read more “DNSSEC” →