Kernel Exploitation

Intro

Exploitation of the kernel will generally lead to an unstable system and should be avoided if possible. This is generally one of the last things you should try when elevating privileges because the Linux kernel plays such a monumental role in the operating system. The first step to learn more about the kernel is to enumerate it. Below are some of the commands used to enumerate the kernel information:

cat /etc/issuecat /proc/versionuname -arpm -q kernel # For Redhat Linuxdmesg | grep Linux # Debian

Example output of the uname -a command:

You will notice a few things in the output. The kernel version will generally start with a 2, 3, 4 or 5 at the time of this writing. In this case, the kernel version everything before the first dash which is 4.18.0. . The next thing to notice is the version this kernel was packaged for. In this case, the version of Ubuntu is Ubuntu 18.04.1. The next piece of information is the type of processor. In this instance, it is a x86_64 processor which is a 64-bit processor.

The next step is to search for an exploit that contains the specific kernel information we previously enumerated. For our next example, let’s pretend our kernel version is 3.10. With this information, we can Google for a known exploit for that particular distribution and kernel.

The first result looks like a denial of service attack which is mostly likely useless to us since we are trying to do a privilege escalation. The second result looks promising. Since our Linux kernel number is 3.10 and the exploit shows it works for version 2.6.22 through 3.9. We may have something promising.

This is where things will differ based on the exploit. Some exploits have well documented code, and others are nearly impossible to understand without additional resources. In our case, the exploit looks fairly simple to run. But with any exploit you find online, the first step is read the comments and see what needs to be changed. This particular exploit leaves us well documented instructions on how to execute this exploit. Below is a snippet of the exploit comments.

Reading through the exploit, I now have a pretty good idea of what I need to do. Below is how I would compile and run the exploit on the target computer:

  1. Navigate to the /tmp folder on the target machine.
  2. Download the exploit doing a wget on the file. If this is not possible, try copying the file to your attacking machine then transfer it to the target using an alternative method. To copy the file using wget, I right click on the download button on the Exploit DB page and select “copy link location”

The next steps in the exploit tell me to change the variable name to a new user we want to create on the machine. In this case it will be noob. I do this by opening my favorite text editor and simply changing the username to noob.

I now compile the exploit. But first I rename my file to dirty.c so the command compiles the correct file.

I then run the exploit with the new password as a parameter.

If all goes well, we run the command su noob and we should have a user with root privileges. After we run the command, we are now the noob user which has sudo privileges. Running the sudo su command gives us root!

Troubleshooting

What do we do if the exploit doesn’t work? There are a few things I like to check. Were there any variables I forgot to change? Does the kernel version of the computer match the required kernel version in the exploit? Did I get any errors upon compiling the exploit? Did I copy over the correct exploit?

Make sure to check everything when troubleshooting. Another thing to consider during kernel exploits, is that you may only get one shot at it. When you exploit the Linux operating system at the kernel level, you are tinkering with the backbone of the operating system and there is a high chance you will create instability in the system. If everything else seems to be right, you may want to search for other kernel exploits that are compatible with this version, or you may want to try again. Sometimes kernel exploits require multiple runs to actually work. I remember one time I ran a kernel exploit and it took 4 times before it worked. What did I change between each of the 4 times I ran it? Nothing. I just ran it 4 times out of frustrations and on the 4th time it worked. Remember though, kernel exploits should be one of the last things you try during privilege escalation.

--

--

--

I am a Security Consultant and formerly worked at PayPal as a Penetration Tester. At night I teach Cyber Security at UTexas. OSCP

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

CIRUS, The DATA Sector Game-Changer!

Welcome to The Great Return

PrivacySwap Referral Program.

From 3,99 to 1,650 USD (Part I) — Simple Vertical Privilege Escalation by Changing HTTP Response

How Istio Ensure the Security of Inter-Service Communication?

How Does Setting Up CORS Help Prevent Cyber Attacks?

Users at a laptop

Write-up: CORS vulnerability with trusted null origin @ PortSwigger Academy

Disruption and Other Threats to Business Growth in 2018 | ThreatMetrix

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Recipe For Root

Recipe For Root

I am a Security Consultant and formerly worked at PayPal as a Penetration Tester. At night I teach Cyber Security at UTexas. OSCP

More from Medium

Kubernetes Network Policy or Blocking External Traffic will Slightly Reduce log4j Attack, not…

Linux Privilege Escalation Resources

Docker breakout: Mounted docker socket

Log4j zero-day vulnerability : Exploitation, Detection & Mitigation