Anthony Weems

Learn how Google CVR could have potentially exfiltrated Gemini 1.0 Pro before launch last year. We describe the vulnz, the fix, and tips for bughunters. Also, shout-out to @epereiralopez for teaming up to adapt this work to another cloud provider. bughunters.google.com/blog/567986357…

Introducing ZERODAY.CLOUD🕵️‍♀️ Be the first to participate in the first-of-its-kind cloud hacking competition. 🤝 WIN PRIZES from our 4.5M$ prize pool. 💰 Register your exploit > zeroday.cloud @msftsecresponse @awscloud @googlecloud

🕺"Leaving tradition" is one of the best parts of Google's security culture and has led to some of the most interesting attack chains I've gotten to work on. There's nothing quite like starting with a blank slate and ending with a root shell.💃

@rez0__ Transparency. Microsoft announced a similar change after the CSRB report on Storm-0558. msrc.microsoft.com/blog/2024/06/t…

@amlweems pretty cool but why?

Effective today, Google will issue CVEs for critical vulnerabilities in Google Cloud that are fixed internally and do not require customer action or patching. cloud.google.com/blog/products/…

Details: github.com/google/securit…

Exciting update on Project Zero’s LLM research: googleprojectzero.blogspot.com/2024/10/from-n…

Before joining Google, I submitted some Cloud bugs to the Google Vulnerability Rewards Program (VRP). Today, we announced a dedicated Cloud VRP and I'm so excited to be a part of the program that got me into Google in the first place. Send us vulnz 🙂 cloud.google.com/blog/products/…

Cloud CISO Perspectives Blog for mid-October ‘24 is up covering: - Sharing AI vulnerability research - Virtual red teams - Advances in DDoS mitigation - Securing inherited cloud deployments - Can AI keep a secret? - and more….. cloud.google.com/blog/products/…

Excited to share this blog post about server-side memory corruption that my team exploited in production. Shout-out to @scannell_simon, @epereiralopez, and @thatjiaozi - this was a very fun project. :-) bughunters.google.com/blog/622075742…

The Mines of Kakadûm: Blindly Exploiting Load-Balanced Services by @scannell_simon and @amlweems is now live!

Very excited to present this with @amlweems! See you in Berlin! (@epereiralopez and @thatjiaozi) were also working on that project and will also be there :)

@bl4sty @julianor Yeah, I noticed this and was wondering if it was a bug. It seems strange to allow setting the request type but not the body.

@amlweems @julianor also the third command byte lets you override the monitor_reqtype that is sent to the monitor process, I'm trying to figure out how that is useful right now (as the body of the monitor request is still formed like a MONITOR_REQ_KEYALLOWED request..)

Reverse engineering by @amlweems reveals 3 flaws that allows attackers to use the backdoor without the private key, using only a captured message signed for the target host: 1. Lack of replay protection 2. Symmetric encryption with a hardcoded key, 3. Partially signed commands

@bl4sty @julianor Yes, but I don't yet understand their purpose. My hunch is that command 1 might be for identifying a vulnerable server w/o calling system(). Command 3 looks interesting.

@amlweems @julianor yeah, the last 2 bytes of the 5 bytes flag for command 0x2 are a u16 size of the command string to be included in the signature. have you played with commands 1 and 3 at all?

@therealshodan fyi: if you search for keys, the magic command byte can be obfuscated, I've updated the code with an example.

Payload format is now documented

@solardiz This is an excellent point, I had only been considering the simple case where the values were e.g. 2*1+0, but it makes more sense that they'd be large ints to look less suspicious. I'll update the .patch later today.

@amlweems That's a cool project, thanks! You describe the 3 magic values as 32-, 32-, and 64-bit, but in openssh.patch you treat them as bytes (which means more false positives). How is it in backdoor code? I think either your description or the "patch" should be adjusted to match.

I've been reverse engineering the xz backdoor this weekend and have documented the payload format and written a proof-of-concept exploit for the RCE. The payloads are signed with an ED448 key, so I patched my own key into the backdoor for testing. :-) github.com/amlweems/xzbot

@julianor @vx__notduck1e @CodeAsm_ I've tested and signature replay works as expected, allowing modification of the command (except the first 5 chars). But I agree it is unrealistic until we actually capture a real signature (which may never happen).

@vx__notduck1e @CodeAsm_ @amlweems About the PoC: I agree with you about PoCs I could make a PoC of the replay with the command extended using amlweems code, however, it will be unrealistic because we don't know if we can capture a signed message in real life (SSH handshake)

@therealshodan Did you capture SSH certificates as well? The payload is embedded in the CA signing key in the cert and will always start with 16 bytes that match a specific pattern. (see github.com/amlweems/xzbot for the payload format)

6 years ago I started logging every public key that tried to log into my vast honeypot network. I used to see hundreds but this has dropped in recent years. We’ll see if the libxz backdoor key turns up.