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!

The ISC implementations DHCP (dynamic host configuration protocol) relies on a the posix random function and is seeded in an odd way. It is done with the time, pid of the process and the last 4 bytes of the MAC address. Because GCPs IP and Mac Address share the last 4 bytes, both 1 & 3 (time and MAC address), are essentially public.

The DHClient process starts rather early on Linux; somewhere between a pid of 290 and 315. All of the randomness of the DHCP client for a random function is broken! Now what?

From another post in 2020 on privilege escalation within the Google Cloud, there is a trick that can be used to take over boxes with insecure DHCP usage. In particular, a bad xid value can cause issues. The xid is a random value that is used to associate the client with an incoming DHCP pending message request.

As described in the post above, the knowledge of the xid value is enough to trick the local host into accepting arbitrary networking information. With how GCP processes these connections, it allows for the overwriting of the current network configurations of any service we want. On GCP, the metadata service is over HTTP as well. By overwriting the IP of the metadata server, the authentication information can be altered to always return true!

The previous attack required access to the machine because the xid's were being stored in the system logs. However, the new piece of information is that the xid's are now known because of the bad randomness. Using a similar attack as before with DHCP will rewrite the /etc/hosts of the metadata server with something a location that we control!

After overwriting the IP of the address of metadata.google.com, the connection goes offline for a moment. Then, google_guest_agent will attempt to create a TCP connection to our rouge metadata server. Now, we can instruct it to add our own SSH keys and log into the box.

There are some limitations to this attack though. The main limitation is that this attack only works when DHCP is requesting data. This only happens when DHCP renews the lease or the VM is restarted. To run this attack remotely the GCP firewall needs to be turned off because it filters out DHCP related packets.

The author reported this issue a while ago but GCP has not fixed the handling of the DHCP on the /etc/hosts file. So, the GCP boxes are still vulnerable to this attack. Although the DHCP issue is only exploitable on GCP because of a multitude of specific things, the issue is actually in an implementation of DHCP in this particular library. Overall, this is an awesome post that required an amazing amount of creativity and spec reading to work.