Walkthrough of basic Linux privilege escalation techniques.

Enumeration

Privilege escalation sometimes could give you a bigger headache than getting into the target itself. This walkthrough is about to cover the main privilege escalation vectors and to give a better understanding of the process as in real-world penetration tests it is really rare to be able to gain initial access with administrative rights. After SSH-ing into the machine with the credentials provided, let’s start with getting the hostname, some general system information and environmental variables. The PATH variable may have a compiler or a scripting language (e.g. Python) that could be used to run code on the target system or leveraged for privilege escalation. We also can identify the running processes. Even with these couple of commands we could answer some of the questions of this section.

What is the hostname of the target system?

What is the Linux kernel version of the target system?

We should check what commands can be run with root privileges with the sudo command. Also it is a good practice when listing files ina directory to get the hidden files showed up with the “-la” switch.

The “id” command provides a general overview of the user’s privilege level and group memberships. This can be used for any user to check. The “/etc/passwd” file can be used to find all the users on the system. We are much better of with some trimming in the results and also with only listing actual human users whom probably have their folders in the “home” directory. Also it is useful to know all the interfaces using the “ifconfig” or “ip a” commands as potentially the target system may be a pivoting point to another network.

This can be further confirmed by the “ip route” and the “netstat” commands.

The “find” command is very useful to search for potentially important information. Also other linux commands might be conducive such as “version” to get a more precise picture about our victim computer. We also might harness some extra information about the operating system on the fly with writing out the content of the “os-release” file, however usually this is displayed anyway at the beginning of the SSH session. Anyways, we can answer some more questions in the section for sure.

What Linux is this?

What version of the Python language is installed on the system?

To find potential vulnerabilities on any targets usually it is a good practice to start with an online search. So, let’s start with that now too using the information gathered for the Linux kernel version earlier.

Ok, now we could either check directly the results in the browser or quickly look up some buzzwords found using the offline vulnerability database in our attacker machine for confirmation.

After copying and opening the C-code in a text editor and reading the comments I think it’s high time to try answering the last question of this section..

What vulnerability seem to affect the kernel of the target system?

Automated Enumeration Tools

There are automated enumeration tools also available online which could significantly speed up the process, for example LinPeas, LinEnum, LES, LSE or LPC.

Privilege Escalation: Kernel Exploits

Let us upload the appropriate Linux kernel exploit code to the victim machine. First starting with our usual Simple HTTP server from the right directory on our attacker machine, then navigating to the a directory on which write permission there are (e.g. /tmp). After this initiating a web request pointing to our attacker machine to get the file.

After this there is an important step to do.. the exploit source code needs to be compiled to make it executable on the target. In a situation like this a compiler needs to be available on the target to do that for us which is not guaranteed every time. We are lucky this time as GCC is there. Before jumping into this I also decided to upgrade the shell.

Now, we are in a position to harness flag1 as we already successfully found it above.

What is the content of the flag1.txt file?

Privilege Escalation: Sudo

System admins can configure which user with which privileges can execute different programs. To find out which programs a user can run with root privileges the “sudo -l” command should be used.

How many programs can the user “karen” run on the target system with sudo rights?

From the binary list above we can try any of them whether it is possible to break out from the restricted environment. Let us go to Get The Fuck Out Bins first and check these binaries for the possibilities to bypass local security restrictions on the target. Let’s try the “find” binary for a start.

Ok, that’s one option, let’s try it with the “less” binary.

The “less” binary is similar program to “more” but it does not have to read the entire input file before starting, so with large input files it starts up faster than other ones. What GTFOBins suggests is opening the “/etc/profile” file with it then simply changing the last line of the profile by pasting the “!/bin/sh” line as a substitute of “etc/profile/END” after the “fi” instruction which is basically the close of the “if” block. This would basically restart BASH with root privileges.

Let’s try “nano” out as well.

First call “nano” with sudo, then type CTRL+R (read file), then CTRL+X (exit). After this the “Command to execute” option will come up into which the “reset; sh 1>&0 2>&0” line should be pasted then hitting ENTER. Nano starts executing the command. After that all you need to do is just cancelling the process with CTRL+C and hit ENTER again a couple of times to get the root shell.

With this we are in a position to answer another question of this section.

What is the content of the flag2.txt file?

The next question could be easily answered with a simple search for Nmap on the GTFOBins site.

How would you use Nmap to spawn a root shell if your user had sudo rights on Nmap?

What is the hash of Frank’s password?

Privilege Escalation: SUID

Linux controls users vs file interactions via read/write/execute permissions within their allocated privilege levels. User privilege levels changes with SUID (Set-user Identification) and SGID (Set-group Identification). These allow files to be executed with the permission level of the file owner or the group owner, respectively. Let’s find first which files have SUID or SGID bits set on the victim machine.

From the list gathered the “base64” binary looks promising. Let’s look it up on GTFOBins whether the SUID bit of it can be tampered with.

Now, all we have to do is just using the SUID elevated privileges to get the user specific (user2) password and password shadow files printed. We specify the target files first, “/etc/shadow” and “/etc/passwd” then printing them out with the tampered base64 decoder program.

After this let’s copy them into two separate files on our attacker machine, “unshadow” them putting them into one file and finally let’s crack the hash with John. Now, we could answer some of the questions of this bit.

What is the password of “user2”?

Without grepping out “user2 ” from the shadow file, we could answer another question of the section.

Which user shares the name of a great comic book writer?

After locating “flag3.txt” we may use the same technique to answer the last question of the section.

What is the content of the flag3.txt file?

Privilege Escalation: Capabilities

Capabilities help manage privileges at a more granular level and such this also can be used to increase the privilege level of a process or binary. Let’s check first the enabled capabilities running the “getcap” command, so we could answer some questions of this section.

How many binaries have set capabilities?

What other binary can be used through its capabilities?

Now, we should go ahead and visit the GTFOBins site again and look up the listed binaries for capabilities issues. Let’s use the Vim binary for the break out. As all the prerequisites are there and ready, all we need to do is just using the 3rd command for Python 3 as suggested.

The command resets the screen and gives you a fresh root prompt.

This is also works for the other binary in question..

With the same clean root prompt returning.

Allowing us to answer the final question of the section..

What is the content of the flag4.txt file?

Privilege Escalation: Cron Jobs

There are two weak points of cron jobs. First is the privileges with which they run, second is the creator or system admin might has forgotten about it and it keeps running periodically no matter what. If the attacker is able to change a cron script which runs with root privileges the exploit code will run with the inherited root privileges. Let’s get the cron jobs listed first. What we can see is that there are a couple of binaries to be run in specific times and there are a number of jobs at the bottom of the screenshot which should run in every minute because in Layman’s Terms 5 asterisks means running a binary in every minute.

How many user-defined cron jobs can you see on the target system?

We can see that in Karen’s home folder the backup.sh file is there, so let’s go ahead and open it up in nano, modify line 2 and 3 and also adding the IP and port number of our attacker machine, then setup a feline listener on the same port.

After saving and exiting Nano, let’s not to forget to make it executable.

We should receive a root shell in a minute. Let’s get an interactive shell spawned and find the flag of the section.

What is the content of the flag5.txt file?

nc -nlvp 1234

whoami

python3 -c 'import pty;pty.spawn("/bin/bash")'

find / -name flag*.txt -type f 2 srcset=/dev/null

cat /home/ubuntu/flag5.txt” width=”781″ height=”381″>

Now, to answer the last question of this section we have get Matt’s password hash printed then crack it with John on our attacker machine.

What is Matt’s password?

Privilege Escalation: PATH

The way in Linux binaries are executed is using1 the PATH (all uppercase) environmental variable which defines the route (path – all lowercase) to where executables are. Commands which are not built into the shell or have no absolute path are looked up in folders defined by the PATH variable. To answer the first question of this section we have to run a simple search for writable folders up to the depth of 2 folder [cut -d “/” -f 2,3], limiting the results to one instance per path [sort -u] and focusing on only the “home” folder [grep home] as per the hints of the question.

What is the odd folder you have write access for?

find / -writable 2 srcset=/dev/null | cut -d "/" -f 2,3 | sort -u | grep home” width=”866″ height=”47″>

For the rest of the questions to answer there are a couple things to do. First, we have to check what folders are added to the PATH environmental variable. Then we have to compare these folders with the writable folders available for us and if nothing is there, we have to add one. Finally, in the writable directory, we have to create a file which would print out the content of the flag text file. Also a script must be available somewhere which could be utilized to “activate” the file to print out that flag text file for us and which can be run as root. The reason behind this 2-tier file run is that the user has no permissions to run a file, but the “test” script runs with root privileges and that makes the privilege escalation possible for now. So, summarily, the file we create must be placed into a directory which is writable and also added to the PATH variable as the test script which is prepared for the purpose of this section will look for our file in the paths which are in the PATH variable. As such, we have two options here, either we use the “/tmp” folder which is writable by default usually or we can use the above discovered writable directory. Let’s create our file now in the “/tmp” directory into which we place the “cat” command to read the flag text file later on. Also do not forget to give the file executable permissions. First of all though we obviously need to find the flag itself as well as the full path of it needs to be identified to be added to our file.

find / -name flag*.txt -type f 2 srcset=/dev/null

pwd

ls

echo "cat /home/matt/flag6.txt" > thm

chmod +x thm” width=”961″ height=”455″>

Now, let’s add the “/tmp” folder to the PATH variable.

echo $PATH

export PATH=/tmp:$PATH

echo $PATH

Now we can answer the rest of the questions of this section.

What is the content of the flag6.txt file?

For the sake of completeness, let’s check real quick how this would work with using the above discovered writable folder.

echo $PATH

export PATH=/home/murdoch:$PATH

echo $PATH

echo "cat /home/matt/flag6.txt" srcset= thm

chmod +x thm

./test” width=”962″ height=”430″>

Privilege Escalation: NFS

The first step of this this privilege escalation vector is to check the Network File Sharing (NFS) configuration which is kept in the /etc/exports file. This file is created during the NFS server installation and can usually be read by users. What we need to look for is the “no_root_squash” option as if this option is present on a writable share, we can create an executable with SUID bit set and run it on the target system. Let’s check the configuration first and then enumerate the mountable shares.

How many mountable shares can you identify on the target system?

How many shares have the “no_root_squash” option enabled?

cat /etc/exports

showmount -e 10.10.246.173

The way it will work in a nutshell is that we will create and compile an executable in the temporary directory “/tmp” of our target which is shared on our attacker machine. So, basically we will do all the steps on our own computer but the results will be mirrored on the target spawning a root shell for us. Let’s create and mount the chosen no_root_squash “/tmp” directory to our attacking machine first.

mkdir /tmp/victim

sudo mount -o rw 10.10.191.169:/tmp /tmp/victim

Now, let’s create a simple executable C-code on our attacker machine in the mounted share folder that will run “/bin/bash” on the target system then compile it with GCC. Finally, we set the SUID bit as well.

cd /tmp/victim

nano nfs.c

int main()
{       setgid(0);
        setuid(0);
        system("/bin/bash");
        return 0;
}

gcc nfs.c -o nfs -w

chmod +s nfs

ls

We can get back to our SSH session now and due to the fact that we were working in the shared folder of our victim, all we have to do is just running the file we compiled. That would spawn our desired root shell on the victim and we can answer the final question of this section as well.

What is the content of the flag7.txt file?

whoami

cd tmp

ls

./nfs

find / -name flag*.txt -type f 2 srcset=/dev/null

cat /home/matt/flag7.txt” width=”937″ height=”408″>

Thanks for reading and as always, any feedback is most welcome.

Walkthrough of an inital enumeration of a Windows machine.

Challenge Questions

We can answer most of the questions after a bit more sophisticated Nmap scan but I’ll present other routes as well.

What is the highest port number being open less than 10,000?

There is an open port outside the common 1000 ports; it is above 10,000. What is it?

How many TCP ports are open?

What is the flag hidden in the HTTP server header?

What is the version of the FTP server listening on a non-standard port?

Optionally we could get the HTTP server header using the Telnet tool.

We could get it with the use of Curl as well as a last resort.

The next question shall be answered using the Hydra password cracker specifying the special FTP port in use.

We learned two usernames using social engineering: eddie and quinn. What is the flag hidden in one of these two account files and accessible via FTP?

The final question to be completed by browsing to the machine in the browser and initiating an Nmap TCP Null scan. This is the least obtrusive type of Nmap scan with no TCP flags included in the packet. The target will be puzzled with it so will not reply and it is the clear indication of being the port open. If the target responds with a reset (RST) packet that means the port is closed on the device.

What is the flag?

Thanks for reading and as always, any feedback is most welcome.

Walkthrough of discovering and attacking an OT-ICS system using the ModBus protocol.

Introduction to OT/ICS

Operational Technology (OT) is basically a dedicated and tailored mixture of hardware and software to control industrial equipments. There is a wide variety of this type systems like Industrial Control Systems (ICS), Supervisory Control, Data Acquisition (SCADA) and Distributed Control Systems (DCS). Protocols utilized inside industrial control systems are usually rather specific to the application. In many cases, these protocols are built by vendors to require specific software and hardware for proprietary systems. However, irrespective of the origin of the protocol, they have one aspect in common: they were not designed with security in mind and are inherently insecure. This is a significant problem since their convergence with IT networks and the now-dominant Transmission Control Protocol (TCP)/Internet Protocol (IP)-based protocols and as such understanding these security flaws and how they are exploited is crucial for penetration testing and threat modeling. 

Introduction to Modbus protocol

Modbus- developed and published by Modicon in 1979 for use with its PLCs- is an application layer messaging protocol positioned at level 7 of the OSI model. It is for client/server communication between devices connected to buses or networks. The client requesting the information is called the Modbus master, and the server supplying the information is the Modbus slave. In a standard Modbus network, there is one master and up to 247 slaves, each with a unique address from 1 to 247. The connection between master and slave is asymmetric only the masters have write permissions on the slaves. This is most widely used network protocol in the industrial manufacturing environment and most common SCADA protocol. Modbus data is used to read and write “registers” which are 16-bit long. The most common register is called “holding register” which is readable and writable; registry type “input register” is readable only. The registers “coil” and “discrete input” are 1-bit long: coils are readable and writable, discrete inputs are readable only. Most common Modbus functions:

1 – Read Coil

2 – Read Discrete Input

3 – Read Holding Registers

4 – Read Input Registers

5 – Write Single Coil

6 – Write Single Holding Register

15 – Write Multiple Coils

16 – Write Multiple Holding Registers

We need to download the attached script package first and scrutinize them a little bit to answer the first questions.

Which is the function used to read holding registers in the pymodbus library?

Which is the function used to write holding registers in pymodbus library?

Discovery and play

After installing the necessary TCP library for Python (it’s already there for me) we are ready to go to answer the subsequent questions. 

After connecting to the plant using our browser, we can visually inspecting how it works and answer some more questions. The phases are moving the line up to the first bottle after starting the machine, then filling the bottle up, and then moving the line to the next bottle afterwards. The sensors are the red and green dots in the picture. The actuators are responsible for switching on/of the plant, starting on/off the roller and for opening/closing the nozzle (black square).

We can answer the rest of the questions using the discovery.py script or reading the code itself. Note, if we change the “time.sleep(1)” value to 30 sec in line 14 in the script, we receive one probe result for each phase which makes it easier to read.

Now, after starting the script we could easily answer the questions about the number of registers, how many of them keep changing, the minimum/maximum observed value, which one holds its value, which registries how to change during filling/moving the bottles or which registries are associated with the roller and the water level sensor.

Attack

We can do instant and significant damage with the scripts available and with some changes in them. That’s the way it could work in real life at the industrial level.

Thanks for reading and as always, any feedback is most welcome.