>4. Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request
Huh? If you have this level of local privileges you can just read session cookies from the browsers store? I guess stealing all the keys is notable, but you can manipulate any password manager with this level of access right?
What's the threat model here, that synced passkeys should be secure in even in situations involving compromised clients? How?
>that synced passkeys should be secure in even in situations involving compromised clients?
I think that is the idea actually. By using secure hardware features it is in theory possible to secure the passkeys even in the case of compromised clients. Like how the iphone uses a security coprocessor to store the decryption keys and face id info out of the reach of iOS.
But this isn't overly concerning since it's still at a minimum as secure as passwords in a local compromise situation.
This is how I assumed it worked as well.
I wasn't aware of the non User Verification method.
I thought the passkey was tied to hardware.
I thought that was the entire point.
How wrong I was it seems.
As far as I can tell, Passkeys is just like ssh keys for normal people. But there's a lot of implementation details which get confused with the base specification. They can be tied to hardware, they can be stored on a secure zone that malware can't reach, but at the core they are pretty much just a pub/private key pair.
At least for accounts you want to keep very secure, session cookies are probably very time-limited. Stealing a passkey ensures persistent access in the future.
But I largely agree, if they're able to do this on your system you're already hacked and they can do a ton of very bad things.
It's not that simple. The stolen file has no clear text passwords and ideally, these passwords can only be decrypted on the right hardware with user confirmation. Of course, eternal and repeated confirmation requests are an anti pattern all their own, but the cloud attestation service not verifying the hardware sounds like a really glaring omission.
It kinda is. If they use Chrome and it's cloud backed password manager, odds are they use GMail. That plus full access to a trusted device (which you have in this scenario) allows you to change their Google account password. Boom, full persistence.
I can think of at least a dozen easier ways to do nefarious things with this level of access that are at least that simple. As an example, faking user attribution would be trivial.
How could Google patch this? If the client is compromised and the attacker can manipulate the local TPM or it's equivalent there's no defense.
Not on the public status page, you have to be signed in to a Microsoft account to access this link.
One of the recent updates:
>Starting at 14:44 UTC on 23 July, 2026, customers may have experienced intermittent connectivity failures, increased latency, or difficulty accessing Azure services in West US region. Customers with traffic traversing the West US region may also experience downstream impact. Impacted services include, but are not limited to:
>API Management, Application Gateway, Azure Database for PostgreSQL, Azure Kubernetes Service (AKS), ExpressRoute Circuits, ExpressRoute Gateways, Network Infrastructure, Power BI Embedded, Virtual WAN, VPN Gateway
>We have identified a potential trigger and are isolating certain impacted devices and redirecting portions of traffic to healthier devices as part of a mitigation plan. We are actively monitoring traffic patterns and service recovery. We will continue to evaluate the effectiveness of mitigation, assess customer impact, and investigate contributing factors. We will provide additional information as soon as it becomes available.
I don't think a modern firewall can MiTM HTTPS TLS without triggering a "Warning: Potential Security Risk Ahead" (Firefox) or "Your connection is not private" (Chrome).
I don't think _any_ firewall can MITM traffic without this happening unless you install the appropriate certificate in each client machine's trust store. I bet that with the advent of such all-in-one solutions as Fortinet or Cisco VPNs that this would be handled automatically. If not I'm sure an endpoint management solution could be coaxed into doing this via some glue scripts. I haven't been an "IT guy" in a decade-plus but I'd be surprised if this wasn't within reach fairly easily these days.
Yeah, that's what the IT at my company did. Installed Zscaler, rolled out a new root cert to Chrome, and then told people to configure the remaining apps they use to use the organization's root cert.
Which is why corporates who do this also use MDM to ensure that certs for the firewall/reverse proxy are installed on endpoints, RADIUS at network access points to authenticate devices by certificates and endpoint protection software to send nasty-grams if you fuck around.
That’s been my experience. The difference being in a corporate environment they can push policies to all employee endpoints that make this happen with no scary warning (trust the internal CA, etc).
Regarding SSH, the MitM would generate a new host key for the actual host you try to connect to. meaning when the MitM existed in the first place and you trusted the host key then (adding it to your Known_hosts), you will not get any additional security warning.
This can of course be avoided by the organization by distributing host keys to the client beforehand as they (maybe) would if the host keys were the actual keys from the host stored in /etc/ssh.
Correct. Companies that implement such a firewall must also install their own trust stores on the machines on the network. This can be a problem when you try to use some software that uses its own trust store from a public source like Mozilla (e.g. Python libraries).
It really makes you think how much your security hinges on that trust store yet it's something most people aren't even aware exists, let alone inspected themselves.
Pretty sure you still can, it just requires that the client system trusts the CA being used to sign the MITM certs. That obviously limits the cases where it works, but not to zero.
I don't for a moment believe that that's the reason (more likely, it's the apps trying to prevent reverse engineering), but yes, there's a bit of a cat/mouse game where you can read traffic but HTTPS prevents that but you can add a custom CA but apps can pin certs but you can modify the app to fix that. But I suspect that for the appliance case, a business can just require that the vendor allow a custom CA and block any traffic they can't decrypt.
In cases where I trust both the communication endpoints, e.g. an employee trying to SSH into an internal host, "trust" being established by other parameters that are not relevant to the firewall, why would I MitM such a connection?
At work I use a VPN to access the internal network, I then have to traverse multiple firewalls and a MitM breaking up my SSH connection in order to connect to a host running a webserver.
I have yet to understand how the MitM would increase security. Extra (well minus) points if the appliance in question auto-updates from the vendor's repository, offering no insight into the inner workings.
They can pin certs, but at least you know that you can't see that traffic and make a policy decision about allowing it anyways or trying to force the vendor to drop it.
The next level is to have another layer of encryption and wrap that in the TLS/SSH, and maybe use steganography to make it appear legitimate. Much harder to detect.
That stuff fundamentally does not work against anybody with enough of a clue to be playing tunneling games (or using ssh) in the first place. If you have any significant control over both ends of the connection, then it's trivial to obfuscate anything you want so that the firewall can't detect it.
... and those boxes, all of them, have a really bad history of security bugs themselves.
The risks you're taking by undermining the cryptography and putting random unnecessary devices in positions of trust are almost always greater than the risks you mitigate. What you're really buying with those devices is the illusion of control and/or the ability to claim you "tried".
TLDR: Bard will render Markdown images in conversations. Bard can also read the contents of your Google docs to give responses more context. By sharing a Google Doc containing a malicious prompt with a victim you could get Bard to generate Markdown image links with URL parameters containing URL encoded sections of your conversation. These sections of the conversation can then be exfiltrated when the Bard UI attempts to load the images by reaching out to the URL the attacker had Bard previously create.
Moral of the story: be careful what your AI assistant reads, it could be controlled by an attacker and contain hypnotic suggestions.
Hopefully it'll be tightly scoped and not like, hey I need access to read/create/modify/delete all your calendar events and contacts just so I can check if you are busy
Not everything is meant literally. When he says they ended up with $0 doesn't have to be $0, just hugely down and nearly worthless compared to before that was doing well.
In the same way $100M could just have been $99M or even $80M, and then $0 they started with could just as well have been $20K in savings he invested.
Assuming screenshot is real[0], they have over 1PB in their Google Drive, so chances are everyone just uses Google Drive with shared drives, and employees use Drive for Desktop (previously drive file stream)[1]. Shared drives are pretty powerful and access to them can be gated at the same level as you can regular Drive files.
My theory is that some high-level IT person either got phished and didn't have hardware 2fa, or that high-level IT person downloaded malware / got RAT'd and the Google Drive scanning was done in the background on their machine. Depending on the hierarchy, it might not have even been a scan, could've been the attackers sating their curiosity by browsing through all their internal files and happening to find some PAM credentials.
Maybe just clicking around until they found something. That's what many employees do on a daily basis looking for files on network drives, so nothing that would be noticed easily.
>Anyone who can articulate their ideas in language can implement them
I'd be shocked if even 10% of the users who can't navigate a GUI could accurately describe what they want the software to do. To the user who doesn't know they can use Ctrl-Z to undo, the first half dozen times the AI mangles their inherited spreadsheet might be enough to put them off the idea.
I’ve been thinking for a while about a common people programming language able to interface with machines with pure casual conversation ( not exact commands) and I feel something it’s coming in the next decades even if not earlier. Imagine the ability to casually chat with a widget which understands flawlessly and where most devices would be able to communicate as well. This could eventually be used in psychotherapy, everything automation around humans and in nefarious ways as well. I’m only hopeful of a human augmentation scenario but there are countless ways it could become totally different.
Certainly there is a huge middle ground. Vague, but common, use cases might have more articulate versions of the commands inferred. I find myself learning new tools all the time - I certainly have enough domain knowledge of many things to express intent without describing implementation. I suspect plenty of people are similar enough - just operating at different levels of abstraction.
What I find more concerning would be people operating under misconceptions, or being more precise than needed, thus not actually accomplishing their objective with the introduction of irrelevant detail.
Huh? If you have this level of local privileges you can just read session cookies from the browsers store? I guess stealing all the keys is notable, but you can manipulate any password manager with this level of access right?
What's the threat model here, that synced passkeys should be secure in even in situations involving compromised clients? How?