coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

GitBook: [#2742] change

Browse Source
This commit is contained in:
CPol 2021-10-10 22:24:28 +00:00 committed by gitbook-bot
parent fc0b171601
commit 15bece68ec
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
3 changed files with 55 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
cryptography/padding-oracle-priv.md
View File

@ -2,7 +2,7 @@
## CBC - Cipher Block Chaining
In CBC, the encryption uses the **previous encrypted block as IV** to XOR with the following block as you can see in the following image taken from [Wikipedia](http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation):
In CBC mode the **previous encrypted block is used as IV **to XOR with the next block:
![CBC encryption](https://assets.pentesterlab.com/padding_oracle/CBC_encryption.png)
@ -14,71 +14,70 @@ Notice how it's needed to use an **encryption** **key** and an **IV**.
## Message Padding
As the encryption is performed in **fixed** **size** **blocks**, **padding** is usually needed in the **last** **block** to complete its length.
As the encryption is performed in **fixed** **size** **blocks**, **padding** is usually needed in the **last** **block** to complete its length.\
Usually **PKCS7** is used, which generates a padding **repeating** the **number** of **bytes** **needed** to **complete** the block. For example, if the last block is missing 3 bytes, the padding will be `\x03\x03\x03`.
Let's look at more examples with a **2 blocks of length 8bytes**:
| Block \#0 | | | | | | | | Block \#1 | | | | | | | |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| byte \#0 | byte \#1 | byte \#2 | byte \#3 | byte \#4 | byte \#5 | byte \#6 | byte \#7 | byte \#0 | byte \#1 | byte \#2 | byte \#3 | byte \#4 | byte \#5 | byte \#6 | byte \#7 |
| P | A | S | S | W | O | R | D | 1 | 2 | 3 | 4 | 5 | 6 | **0x02** | **0x02** |
| P | A | S | S | W | O | R | D | 1 | 2 | 3 | 4 | 5 | **0x03** | **0x03** | **0x03** |
| P | A | S | S | W | O | R | D | 1 | 2 | 3 | **0x05** | **0x05** | **0x05** | **0x05** | **0x05** |
| P | A | S | S | W | O | R | D | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** |
| byte #0 | byte #1 | byte #2 | byte #3 | byte #4 | byte #5 | byte #6 | byte #7 | byte #0 | byte #1 | byte #2 | byte #3 | byte #4 | byte #5 | byte #6 | byte #7 |
| ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- |
| P | A | S | S | W | O | R | D | 1 | 2 | 3 | 4 | 5 | 6 | **0x02** | **0x02** |
| P | A | S | S | W | O | R | D | 1 | 2 | 3 | 4 | 5 | **0x03** | **0x03** | **0x03** |
| P | A | S | S | W | O | R | D | 1 | 2 | 3 | **0x05** | **0x05** | **0x05** | **0x05** | **0x05** |
| P | A | S | S | W | O | R | D | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** |
Note how in the last example the **last block was full so another one was generated only with padding**.
## Padding Oracle
When an application decrypts encrypted data, it will first decrypt the data; then it will remove the padding. During the cleanup of the padding, **if** an **invalid** **padding** triggers a detectable **behaviour**, you have a **padding oracle vulnerability**. The detectable behaviour can be an **error**, a **lack** of **results**, or a **slower response**.
When an application decrypts encrypted data, it will first decrypt the data; then it will remove the padding. During the cleanup of the padding, **if **an **invalid** **padding **triggers a detectable **behaviour**, you have a **padding oracle vulnerability**. The detectable behaviour can be an **error**, a **lack **of **results**, or a **slower response**.
If you detect this behaviour, you can **decrypt the encrypted data** and even **encrypt any cleartext**.
If you detect this behaviour, you can** decrypt the encrypted data** and even** encrypt any cleartext**.
### How to exploit
You could use [https://github.com/AonCyberLabs/PadBuster](https://github.com/AonCyberLabs/PadBuster) to exploit this kind of vulnerability or just do
```text
```
sudo apt-get install padbuster
```
In order to test if the cookie of a site is vulnerable you could try:
```bash
perl ./padBuster.pl http://10.10.181.45/index.php "Nl0OpaQYeGPMJeWSih2iiQ==" 8 -encoding 0 -cookies "auth=Nl0OpaQYeGPMJeWSih2iiQ=="
perl ./padBuster.pl http://10.10.10.10/index.php "RVJDQrwUdTRWJUVUeBKkEA==" 8 -encoding 0 -cookies "login=RVJDQrwUdTRWJUVUeBKkEA=="
```
**Encoding 0** means that **base64** is used \(but others are available, check the help menu\).
**Encoding 0** means that **base64 **is used (but others are available, check the help menu).
You could also **abuse** this **vulnerability** to **encrypt new data**. For example, imagine that the content of the cookie is "_user=MyUsername_", then you may change it to "_**user=administrator**_" and escalate privileges inside the application. You could also do it using `paduster`specifying the **-plaintext** parameter:
You could also **abuse **this **vulnerability **to **encrypt new data**. For example, imagine that the content of the cookie is "_user=MyUsername_", then you may change it to "_**user=administrator**_" and escalate privileges inside the application. You could also do it using `paduster`specifying the** -plaintext** parameter:
```bash
perl ./padBuster.pl http://10.10.181.45/index.php "Nl0OpaQYeGPMJeWSih2iiQ==" 8 -encoding 0 -cookies "auth=Nl0OpaQYeGPMJeWSih2iiQ==" -plaintext "user=administrator"
perl ./padBuster.pl http://10.10.10.10/index.php "RVJDQrwUdTRWJUVUeBKkEA==" 8 -encoding 0 -cookies "login=RVJDQrwUdTRWJUVUeBKkEA==" -plaintext "user=administrator"
```
If the site is vulnerable `padbuster`will automatically try to find when the padding error occurs, but you can also indicating the error message it using the **-error** parameter.
```bash
perl ./padBuster.pl http://10.10.181.45/index.php "Nl0OpaQYeGPMJeWSih2iiQ==" 8 -encoding 0 -cookies "hcon=Nl0OpaQYeGPMJeWSih2iiQ==" -error "Invalid padding"
perl ./padBuster.pl http://10.10.10.10/index.php "" 8 -encoding 0 -cookies "hcon=RVJDQrwUdTRWJUVUeBKkEA==" -error "Invalid padding"
```
### The theory
In **summary**, you can start decrypting the encrypted data by **guessing** the correct **values** that can be used to **create** all the **different paddings**. Then, the padding oracle attack will start **decrypting** bytes **from** the **end** to the start by **guessing** which will be the correct **value** that **creates a padding of 1, 2, 3, etc**.
In **summary**, you can start decrypting the encrypted data by **guessing **the correct **values **that can be used to **create **all the **different paddings**. Then, the padding oracle attack will start **decrypting **bytes **from **the **end **to the start by **guessing **which will be the correct **value **that **creates a padding of 1, 2, 3, etc**.
![CBC decryption](https://assets.pentesterlab.com/padding_oracle/CBC_decryption.png)
Imagine you have some encrypted text that occupies **2 blocks** formed by the bytes from **E0 to E15**.
In order to **decrypt** the **last** **block** \(**E8** to **E15**\), the whole block passes through the "block cipher decryption" generating the **intermediary bytes I0 to I15**.
Finally, each intermediary byte is **XORed** with the previos encrypted bytes \(E0 to E7\). So:
Imagine you have some encrypted text that occupies **2 blocks** formed by the bytes from **E0 to E15**.\
In order to **decrypt** the **last** **block** (**E8** to **E15**), the whole block passes through the "block cipher decryption" generating the** intermediary bytes I0 to I15**.\
Finally, each intermediary byte is **XORed** with the previous encrypted bytes (E0 to E7). So:
* `C15 = D(E15) ^ E7 = I15 ^ E7`
* `C14 = I14 ^ E6`
* `C13 = I13 ^ E5`
* `C12 = I12 ^ E4`
* `C13 = I13 ^ E5 `
* `C12 = I12 ^ E4 `
* ...
Now, It's possible to **modify `E7` until `C15` is `0x01`**, which will also be a correct padding. So, in this case: `\x01 = I15 ^ E'7`
@ -89,16 +88,19 @@ Which allow us to **calculate C15**: `C15 = E7 ^ I15 = E7 ^ \x01 ^ E'7`
Knowing **C15**, now it's possible to **calculate C14**, but this time brute-forcing the padding `\x02\x02`.
This BF is as complex as the previous one as it's possible to calculate the the `E''15` whose value is 0x02: `E''7 = \x02 ^ I15` so it's just needed to find the **`E'14`** that generates a **`C14` equals to `0x02`**.
This BF is as complex as the previous one as it's possible to calculate the the `E''15` whose value is 0x02: `E''7 = \x02 ^ I15` so it's just needed to find the **`E'14`** that generates a **`C14` equals to `0x02`**.\
Then, do the same steps to decrypt C14: **`C14 = E6 ^ I14 = E6 ^ \x02 ^ E''6`**
**Follow this chain until you decrypt the whole encrypted text.**
### Detection of the vulnerability
Register and account and log in with this account .
Register and account and log in with this account .\
If you **log in many times** and always get the **same cookie**, there is probably **something** **wrong** in the application. The **cookie sent back should be unique** each time you log in. If the cookie is **always** the **same**, it will probably always be valid and there **won't be anyway to invalidate i**t.
Now, if you try to **modify** the **cookie**, you can see that you get an **error** from the application.
But if you BF the padding \(using padbuster for example\) you manage to get another cookie valid for a different user. This scenario is highly probably vulnerable to padbuster.
Now, if you try to **modify** the **cookie**, you can see that you get an **error** from the application.\
But if you BF the padding (using padbuster for example) you manage to get another cookie valid for a different user. This scenario is highly probably vulnerable to padbuster.
## References
* [https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)

43
linux-unix/privilege-escalation/apparmor.md
View File

@ -2,11 +2,13 @@
## Basic Information
**AppArmor** is a kernel enhancement to confine **programs** to a **limited** set of **resources**. It's a Mandatory Access Control or **MAC** that binds **access control** attributes **to programs rather than to users**.
AppArmor confinement is provided via **profiles loaded into the kernel**, typically on boot.
**AppArmor** is a kernel enhancement to confine **programs** to a **limited** set of **resources **with **per-program profiles**. Profiles can **allow** **capabilities** like network access, raw socket access, and the permission to read, write, or execute files on matching paths.
It's a Mandatory Access Control or **MAC** that binds **access control** attributes **to programs rather than to users**.\
AppArmor confinement is provided via **profiles loaded into the kernel**, typically on boot.\
AppArmor profiles can be in one of **two modes**:
* **Enforcement**: Profiles loaded in enforcement mode will result in **enforcement of the policy** defined in the profile **as well as reporting** policy violation attempts \(either via syslog or auditd\).
* **Enforcement**: Profiles loaded in enforcement mode will result in **enforcement of the policy** defined in the profile **as well as reporting** policy violation attempts (either via syslog or auditd).
* **Complain**: Profiles in complain mode **will not enforce policy** but instead **report** policy **violation** attempts.
AppArmor differs from some other MAC systems on Linux: it is **path-based**, it allows mixing of enforcement and complain mode profiles, it uses include files to ease development, and it has a far lower barrier to entry than other popular MAC systems.
@ -20,7 +22,7 @@ AppArmor differs from some other MAC systems on Linux: it is **path-based**, it
### Profiles path
Apparmor profiles are usually saved in _**/etc/apparmor.d/**_
Apparmor profiles are usually saved in _**/etc/apparmor.d/**_\
With `sudo aa-status` you will be able to list the binaries that are restricted by some profile. If you can change the char "/" for a dot of the path of each listed binary and you will obtain the name of the apparmor profile inside the mentioned folder.
For example, a **apparmor** profile for _/usr/bin/man_ will be located in _/etc/apparmor.d/usr.bin.man_
@ -39,23 +41,23 @@ aa-mergeprof #used to merge the policies
## Creating a profile
* In order to indicate the affected executable, **absolute paths and wildcards** are allowed \(for file globbing\) for specifying files.
* In order to indicate the affected executable, **absolute paths and wildcards** are allowed (for file globbing) for specifying files.
* To indicate the access the binary will have over **files** the following **access controls** can be used:
* **r** \(read\)
* **w** \(write\)
* **m** \(memory map as executable\)
* **k** \(file locking\)
* **l** \(creation hard links\)
* **ix** \(to execute another program with the new program inheriting policy\)
* **Px** \(execute under another profile, after cleaning the environment\)
* **Cx** \(execute under a child profile, after cleaning the environment\)
* **Ux** \(execute unconfined, after cleaning the environment\)
* **Variables** can be defined in the profiles and can be manipulated from outside the profile. For example: @{PROC} and @{HOME} \(add \#include <tunables/global> to the profile file\)
* **r** (read)
* **w** (write)
* **m** (memory map as executable)
* **k** (file locking)
* **l** (creation hard links)
* **ix** (to execute another program with the new program inheriting policy)
* **Px** (execute under another profile, after cleaning the environment)
* **Cx** (execute under a child profile, after cleaning the environment)
* **Ux** (execute unconfined, after cleaning the environment)
* **Variables** can be defined in the profiles and can be manipulated from outside the profile. For example: @{PROC} and @{HOME} (add #include \<tunables/global> to the profile file)
* **Deny rules are supported to override allow rules**.
### aa-genprof
To easily start creating a profile apparmor can help you. It's possible to make **apparmor inspect the actions performed by a binary and then let you decide which actions you want to allow or deny**.
To easily start creating a profile apparmor can help you. It's possible to make **apparmor inspect the actions performed by a binary and then let you decide which actions you want to allow or deny**.\
You just need to run:
```bash
@ -184,12 +186,12 @@ apparmor module is loaded.
docker-default
```
By default **Apparmor docker-default profile** is generated from [https://github.com/moby/moby/blob/master/profiles/apparmor/template.go](https://github.com/moby/moby/blob/master/profiles/apparmor/template.go)
By default **Apparmor docker-default profile** is generated from [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
**docker-default profile Summary**:
* **Access** to all **networking**
* **No capability** is defined \(However, some capabilities will come from including basic base rules i.e. \#include &lt;abstractions/base&gt; \)
* **No capability** is defined (However, some capabilities will come from including basic base rules i.e. #include \<abstractions/base> )
* **Writing** to any **/proc** file is **not allowed**
* Other **subdirectories**/**files** of /**proc** and /**sys** are **denied** read/write/lock/link/execute access
* **Mount** is **not allowed**
@ -202,7 +204,7 @@ Once you **run a docker container** you should see the following output:
docker-default (825)
```
Note that **apparmor will even block capabilities privileges** granted to the container by default. For example, it will be able to **block permission to write inside /proc even if the SYS\_ADMIN capability is granted** because by default docker apparmor profile denies this access:
Note that **apparmor will even block capabilities privileges** granted to the container by default. For example, it will be able to **block permission to write inside /proc even if the SYS_ADMIN capability is granted** because by default docker apparmor profile denies this access:
```bash
docker run -it --cap-add SYS_ADMIN --security-opt seccomp=unconfined ubuntu /bin/bash
@ -216,7 +218,7 @@ You need to **disable apparmor** to bypass its restrictions:
docker run -it --cap-add SYS_ADMIN --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu /bin/bash
```
Note that by default **AppArmor** will also **forbid the container to mount** folders from the inside even with SYS\_ADMIN capability.
Note that by default **AppArmor** will also **forbid the container to mount** folders from the inside even with SYS_ADMIN capability.
{% hint style="info" %}
Usually, when you **find** that you have a **privileged capability** available **inside** a **docker** container **but** some part of the **exploit isn't working**, this will be because docker **apparmor will be preventing it**.
@ -239,4 +241,3 @@ find /etc/apparmor.d/ -name "*lowpriv*" -maxdepth 1 2>/dev/null
```
In the weird case you can **modify the apparmor docker profile and reload it.** You could remove the restrictions and "bypass" them.

4
linux-unix/privilege-escalation/seccomp.md
View File

@ -123,6 +123,10 @@ In the following example the **syscalls **of `uname` are discovered:
docker run -it --security-opt seccomp=default.json modified-ubuntu strace uname
```
{% hint style="info" %}
If you are using **Docker just to launch an application**, you can **profile** it with **`strace`** and **just allow the syscalls** it needs
{% endhint %}
### Deactivate it in Docker
Launch a container with the flag: **`--security-opt seccomp=unconfined`**