Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Google Cloud Account Takeover via URL Parsing Confusion- 1648

Mohamed BenchikhPosted 10 Months Ago
  • On the Google Cloud CLI gcloud, the authentication process works using OAuth and a server that is quickly setup on the computer at localhost:50000. This means that http://localhost is actually a valid redirect_uri on OAuth! Given that we have a browser parsing doing the redirect and a backend parser validating the redirect, this becomes the perfect chance to find an account takeover via an evil redirect.
  • At first, this didn't make sense to me. Most of the time, these are static string checks and are an allowlist, giving very little wiggle room. The author of the post tried 127.0.0.1 and noticed that this worked. This meant that they were parsing the URL rather than just doing a static string check on the backend. With two parsers in play, it's time to find a difference!
  • They wrote a Python script that performed a large amount of URL mutations. Encoding trips, private IPs, weird schemas, IPv6, etc. After running their fuzzing script for a while, they found a match:
    http://[0:0:0:0:0:ffff:128.168.1.0]@[0:0:0:0:0:ffff:127.168.1.0]@attacker.com/
    
  • This URL is super weird. The @ symbol is used as the separator between the username and the password on a URL. It's actually invalid to have two of them. Chrome mitigates this edge case by encoding all non-reserved characters and earlier occurrences of reserved characters. However, the parser on the backend likely ignored the attacker.com part of the URL and grabbed the proper data from the set positions. Neat!
  • What's interesting is that this only happened when using IPv6. When using IPv4, this didn't work. A working redirect_uri is as follows: http://[::1]@[::1]@attacker.com. The server would parse the second [::1] as the server information and skip the attacker.com entirely. However, Chrome would parse attacker.com as the host.
  • Mixing this with OAuth gave the author an arbitrary redirect to steal the OAuth to be logged into the users account. That's a pretty rad bug with good visuals and background.