SQL injection, wykonanie kodu w OS, problemy z Kubernetesem, sekrety w obrazach Dockera. Można było podmieniać bazowe obrazy w części cloudu IBMa

Niebanalny research tutaj. Pierwszym krokiem było zlokalizowanie podatności SQL injection (z poziomu zwykłego użytkownika cloudu IBMa):

Ale w sumie co daje SQL injection, jak przecież wykupując swoją bazę danych w IBM cloud i tak mamy możliwość wykonywania dowolnych poleceń SQL-owych?

Odpowiedź znajduje się powyżej. Zobaczcie że zdefiniowana przez IBM funkcja posiada znacznik SECURITY DEFINER. Oznacza to, że uruchamia się z uprawnieniami użytkownika bazodanowego, który stworzył tę funkcję. W tym przypadku to user 'ibm’ mający uprawnienia admina (superuser :)

A od superusera do wykonania kodu w OS – w przypadku PostgreSQL – jest już bardzo prosto:

Co dalej? Będąc na systemie operacyjnym, badacze wykonali mały rekonesans znajdując klucz API do Kubernetesa. Plik: /var/run/secrets/kubernetes.io/serviceaccount/token

[tu trzeba oddać hołd ekipie IBMa – wykryli oni sam fakt realizacji rekonesansu, ale dali zgodę badaczom na dalsze atakowanie]

Co można było dokładnie uzyskać posiadając klucz API? Pokazało to (zuploadowane przez badaczy) narzędzie kubectl:

Dalej, wylistowanie podów kubernetesowych:

$ kubectl get pods -o json

a następnie zassanie sekretów z poda:

Po zdekodowaniu z Base64 pierwszego widocznego powyżej ciągu, oznaczonego jako **REDACTED** można było otrzymać klucze dające dostęp do prywatnego zasobnika kontenerów cloudowych (container registry) IBMa. Co więcej ten dostęp był w trybie rw (ała!)

Trzeba jednak przyznać, że kiedy badacze chcieli podmienić / dodać nowy kontener coś nie zadziałało (uff!). Zaczęli więc analizować kontenery, które mogli odczytać (poszukiwanie różnych zapomnianych artefaktów czy sekretów). Kontenerów było dużo, więc przydała się mała automatyzacja (narzędzie Yelp). Jeden z przykładów poszukiwania:

Udało się m.in. zlokalizować dane logowania do FTP czy do repozytorium artefaktów (czyli niewielkich fragmentów danych używanych podczas budowania finalnego obrazu kontenera).

Wreszcie moment kulminacyjny:

utworzyliśmy kilka plików w repozytoriach używanych w procesie budowania obrazu PostgreSQL. Dowiodło to, że możemy nadpisać dowolne pliki w pakietach, które zostałyby zainstalowane w każdej instancji PostgreSQL [dla dowolnego innego użytkownika – przyp. sekurak]

we created a few files in the repositories used in the build process of the PostgreSQL image. This proved that we could overwrite arbitrary files in the packages that would have been installed on every PostgreSQL instance, establishing the supply-chain attack path.

~Michał Sajdak