<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Docker to **wiodąca platforma** w branży **konteneryzacji**, prowadząca **ciągły rozwój**. Umożliwia łatwe tworzenie i dystrybucję aplikacji, obejmujących zarówno **tradycyjne, jak i futurystyczne**, oraz zapewnia ich **bezpieczne wdrożenie** w różnych środowiskach.
- **[containerd](http://containerd.io)**: Jest to **podstawowy runtime** dla kontenerów, odpowiedzialny za kompleksowe **zarządzanie cyklem życia kontenera**. Obejmuje to obsługę **transferu i przechowywania obrazów**, a także nadzór nad **wykonywaniem, monitorowaniem i sieciowaniem** kontenerów. **Szczegółowe informacje** na temat containerd są **dalej omawiane**.
- **container-shim** odgrywa kluczową rolę jako **pośrednik** w obsłudze **bezgłowych kontenerów**, płynnie przejmując po **runc** po zainicjowaniu kontenerów.
- **[runc](http://runc.io)**: Ceniony za swoje możliwości **lekkiego i uniwersalnego uruchamiania kontenerów**, runc jest zgodny ze **standardem OCI**. Jest używany przez containerd do **uruchamiania i zarządzania kontenerami** zgodnie z **wytycznymi OCI**, ewoluując z pierwotnego **libcontainer**.
- **[grpc](http://www.grpc.io)** jest niezbędny do **ułatwiania komunikacji** między containerd a **docker-engine**, zapewniając **efektywną interakcję**.
- **[OCI](https://www.opencontainers.org)** odgrywa kluczową rolę w utrzymaniu **specyfikacji OCI** dla uruchamiania i obrazów, a najnowsze wersje Dockera są **zgodne zarówno ze standardem OCI dotyczącym obrazów, jak i uruchamiania**.
**Containerd** został specjalnie opracowany, aby sprostać potrzebom 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 abstrakcję funkcjonalności i wywołań systemowych specyficznych dla systemu operacyjnego. Celem Containerd jest uwzględnienie tylko niezbędnych funkcji wymaganych przez użytkowników, dążąc do pominięcia zbędnych komponentów. Jednak osiągnięcie tego celu w pełni jest uznawane za wyzwanie.
Kluczową decyzją projektową jest to, że **Containerd nie obsługuje sieci**. Sieć jest uważana za istotny 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 obsługiwane przez niego platformy.
Podczas gdy **Docker wykorzystuje Containerd** do uruchamiania kontenerów, ważne jest zauważenie, że Containerd obsługuje tylko podzbiór funkcji Docker'a. Konkretnie, Containerd nie posiada możliwości zarządzania siecią obecnymi w Dockerze i nie obsługuje bezpośrednio tworzenia grup Docker. Ta różnica podkreśla skoncentrowaną rolę Containerd jako środowiska uruchomieniowego kontenerów, delegując bardziej wyspecjalizowane funkcje do platform, z którymi się integruje.
**Podman** to otwarty silnik kontenerów, który przestrzega standardów [Open Container Initiative (OCI)](https://github.com/opencontainers) i jest rozwijany oraz utrzymywany przez firmę Red Hat. Wyróżnia się on kilkoma unikalnymi cechami, w szczególności swoją **architekturą bez demona** i obsługą **kontenerów bez uprawnień root**, umożliwiając użytkownikom uruchamianie kontenerów bez uprawnień root.
Podman został zaprojektowany tak, aby był kompatybilny z interfejsem API Dockera, co pozwala na korzystanie z poleceń CLI Dockera. Ta kompatybilność obejmuje również ekosystem narzędzi, takich jak **Buildah** do budowania obrazów kontenerów i **Skopeo** do operacji na obrazach, takich jak push, pull i inspect. Więcej szczegółów na temat tych narzędzi można znaleźć na ich [stronie GitHub](https://github.com/containers/buildah/tree/master/docs/containertools).
- **Architektura**: W przeciwieństwie do modelu klient-serwer Dockera z tłem demona, Podman działa bez demona. Taki projekt oznacza, że kontenery uruchamiane są z uprawnieniami użytkownika, który je uruchamia, poprawiając bezpieczeństwo poprzez eliminację potrzeby dostępu root.
- **Integracja z systemd**: Podman integruje się z **systemd**, aby zarządzać kontenerami, umożliwiając zarządzanie kontenerami za pomocą jednostek systemd. Kontrastuje to z użyciem systemd przez Dockera głównie do zarządzania procesem demona Dockera.
- **Kontenery bez uprawnień root**: Kluczową cechą Podmana jest możliwość uruchamiania kontenerów przy uprawnieniach użytkownika inicjującego. Taki podejście minimalizuje ryzyko związane z naruszeniem kontenera, zapewniając, że atakujący uzyskują tylko uprawnienia skompromitowanego użytkownika, a nie dostęp root.
Podejście Podmana oferuje bezpieczną i elastyczną alternatywę dla Dockera, podkreślając zarządzanie uprawnieniami użytkownika i kompatybilność z istniejącymi procesami pracy z Dockerem.
Należy zauważyć, że ponieważ podman ma na celu obsługę tego samego interfejsu API co Docker, można używać tych samych poleceń z podmanem, co z Dockerem, takich jak:
Zdalne API domyślnie działa na porcie 2375, gdy jest włączone. Usługa domyślnie nie wymaga uwierzytelniania, co pozwala atakującemu uruchomić uprzywilejowany kontener Docker. Korzystając z Zdalnego API, można podłączyć hosty / (katalog główny) do kontenera i odczytywać/zapisywać pliki z środowiska hosta.
Jeśli możesz **skontaktować się z zdalnym interfejsem API Docker za pomocą polecenia `docker`**, możesz **wykonać** dowolne z [**wcześniej omówionych** poleceń Docker](2375-pentesting-docker.md#basic-commands) w celu interakcji z usługą.
Czasami zobaczysz, że **2376** jest dostępne 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.
Jeśli chcesz uzyskać więcej informacji na ten temat, więcej informacji jest dostępnych tam, gdzie skopiowałem polecenia: [https://securityboulevard.com/2019/02/abusing-docker-api-socket/](https://securityboulevard.com/2019/02/abusing-docker-api-socket/)
Wykorzystując to, można uciec z kontenera i skompromitować maszynę. Możesz uruchomić słaby kontener na zdalnej maszynie, uciec z niego i skompromitować maszynę:
Jeśli znajdujesz się wewnątrz hosta korzystającego z Dockera, możesz [**przeczytać te informacje, aby spróbować podnieść uprawnienia**](../linux-hardening/privilege-escalation/#writable-docker-socket).
* Możesz użyć narzędzia [https://github.com/docker/docker-bench-security](https://github.com/docker/docker-bench-security), aby sprawdzić swoją obecną instalację Dockera.
*`./docker-bench-security.sh`
* Możesz użyć narzędzia [https://github.com/kost/dockscan](https://github.com/kost/dockscan), aby sprawdzić swoją obecną instalację Dockera.
*`dockscan -v unix:///var/run/docker.sock`
* Możesz użyć narzędzia [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained), aby sprawdzić uprawnienia kontenera przy użyciu różnych opcji zabezpieczeń. Jest to przydatne do zrozumienia konsekwencji korzystania z 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`
* Możesz użyć obrazu Dockera [https://github.com/quay/clair](https://github.com/quay/clair), aby przeskanować inne obrazy Dockera i znaleźć podatności.
*`docker run --rm -v /root/clair_config/:/config -p 6060-6061:6060-6061 -d clair -config="/config/config.yaml"`
* Możesz użyć narzędzia [https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter), aby **sprawdzić swój plik Dockerfile** i znaleźć wszelkiego rodzaju błędy konfiguracji. Każdemu błędowi zostanie przypisane ID, tutaj [https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md) znajdziesz informacje, jak je naprawić.
* Możesz użyć narzędzia [https://github.com/replicatedhq/dockerfilelint](https://github.com/replicatedhq/dockerfilelint), aby **sprawdzić swój plik Dockerfile** i znaleźć wszelkiego rodzaju błędy konfiguracji.
* Możesz użyć narzędzia [https://github.com/RedCoolBeans/dockerlint](https://github.com/RedCoolBeans/dockerlint), aby **sprawdzić swój plik Dockerfile** i znaleźć wszelkiego rodzaju błędy konfiguracji.
* Możesz użyć narzędzia [https://github.com/hadolint/hadolint](https://github.com/hadolint/hadolint), aby **sprawdzić swój plik Dockerfile** i znaleźć wszelkiego rodzaju błędy konfiguracji.
* Możesz użyć narzędzia [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco), aby wykrywać **podejrzane zachowanie w uruchomionych kontenerach**.
* Zauważ w poniższym fragmencie, jak **Falco kompiluje moduł jądra i go wstawia**. Następnie ładowane są reguły i **rozpoczyna się rejestrowanie podejrzanej aktywności**. W tym przypadku wykryto 2 uruchomione kontenery z uprawnieniami, z czego jeden z nich ma wrażliwe montowanie, a po kilku sekundach wykryto otwarcie powłoki w jednym z kontenerów.
mkdir: cannot create directory '/lib/modules/5.0.0-20-generic/kernel/extra': Read-only file system
cp: cannot create regular file '/lib/modules/5.0.0-20-generic/kernel/extra/falco-probe.ko': No such file or directory
depmod...
DKMS: install completed.
* Trying to load a dkms falco-probe, if present
falco-probe found and loaded in dkms
2021-01-04T12:03:20+0000: Falco initialized with configuration file /etc/falco/falco.yaml
2021-01-04T12:03:20+0000: Loading rules from file /etc/falco/falco_rules.yaml:
2021-01-04T12:03:22+0000: Loading rules from file /etc/falco/falco_rules.local.yaml:
2021-01-04T12:03:22+0000: Loading rules from file /etc/falco/k8s_audit_rules.yaml:
2021-01-04T12:03:24+0000: Starting internal webserver, listening on port 8765
2021-01-04T12:03:24.646959000+0000: Notice Privileged container started (user=<NA> command=container:db5dfd1b6a32 laughing_kowalevski (id=db5dfd1b6a32) image=ubuntu:18.04)
2021-01-04T12:03:24.664354000+0000: Notice Container with sensitive mount started (user=<NA> command=container:4822e8378c00 xenodochial_kepler (id=4822e8378c00) image=ubuntu:modified mounts=/:/host::true:rslave)
2021-01-04T12:03:24.664354000+0000: Notice Privileged container started (user=root command=container:4443a8daceb8 focused_brahmagupta (id=4443a8daceb8) image=falco:latest)
2021-01-04T12:04:56.270553320+0000: Notice A shell was spawned in a container with an attached terminal (user=root xenodochial_kepler (id=4822e8378c00) shell=bash parent=runc cmdline=bash terminal=34816 container_id=4822e8378c00 image=ubuntu)
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.