Finally, you have RCE. At this point, you should probably consider getting a stable shell using your preferred method. While the entire challenge can be solved from a single notebook, this is just making your life more difficult than it honestly should be. Go get that stable shell before moving on.
Note: A bit of an added twist, but reverse shells will probably not do the trick in this lab, since the Hadoop network does not have the relevant routes to communicate back on the VPN. This is often normal behaviour in Hadoop networks for additional security, ensuring that the network can't communicate out itself. This may be the ideal time to test your bind shell skills.
You're back? Awesome!
You are still left with the same problem, you can't access the datalake without Kerberos authentication. The question then becomes, if everything has to do with Kerberos authentication, how can this process be automated? If you have this many Hadoop services running and each of them has to authenticate itself before it can perform actions, there has to be an automated way of doing this? Ever heard of Kerberos keytabs?
Keytabs are magical things. Think of them as a Kerberos Key. Essentially, you are storing all the information required (including the password) to authenticate in a file. Keytabs can be generated by interfacing with the Kerberos server and executing the following command:
ktpass /pass <Krb Password> /mapuser <Krb Username> /out <ex.keytab> /princ <username>/<hostname>@<example.com> /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT /Target example.
But wait, how is that secure? Simple! The security of keytabs relies on restricting access to the associated keytab file. So file permissions should be used to protect the keytab file in question, similar to how SSH private keys are protected. However, by default, these keytab files do not inherit secure file permissions, especially during the initialisation phase when the datalake is created and these keys have to be distributed to each node in the cluster.
With this being said, go find the keytabs of the Hadoop services stored on this host. Use whatever enumeration techniques or scripts you would normally follow for privilege escalation after the initial compromise.
Did you find them? Great! Now let's use them.
Let's start small. Let's try to authenticate with Keberos and the keytab associated with our user. The following guide provides excellent assistance on using keytabs for authentication:
https://kb.iu.edu/d/aumh
We are interested in two commands:
klist:
The klist command can be used to gather information from a keytab, since cat'ing the keytab usually ends badly for your shell. We can use the following command to output the principals stored in the keytab file:
klist -k <keytabfile>
kinit:
The kinit command can be used to use a keytab, authenticate to the Kerberos server, and request a ticket. We can use the following command:
kinit <principal name> -k -V -t <keytabfile>
While the -V flag is not really needed, I highly recommend adding it for additional verbosity, such as actually knowing that you are authenticated. Without it, you won't see any useful output.
Start by listing the principals stored in the service's associate keytab and then try to authenticate with the keytab. Use the -V flag for verbose mode to make sure you can see the output.
Now that you are authenticated, we can finally start to interface with the datalake! However, you will soon notice that you don't have access to the CLI tools associated with Hadoop. The simple reason? The compromised user does not have the correct environment paths set to use the Hadoop services. Go find the associated bin directory for the Hadoop services and either add this to your environment path or navigate to this directory to execute the associated Hadoop services.
For starters, we are interested in interfacing with the datalake's file system. Thus, we will make use of the hdfs application. Have a read through this guide to get an understanding of the type of commands you can execute:
https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html
The command that we are specifically interested in is the dfs command, which allows us to run file system commands on the datalake. Using this command, go hunt down the flag stored in this user's HDFS home directory.
