5984,6984 - Pentesting CouchDB
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CouchDB to wszechstronna i potężna baza danych zorientowana na dokumenty, która organizuje dane za pomocą struktury mapy klucz-wartość w każdym dokumencie. Pola w dokumencie mogą być reprezentowane jako pary klucz/wartość, listy lub mapy, co zapewnia elastyczność w przechowywaniu i pobieraniu danych.
Każdemu dokumentowi przechowywanemu w CouchDB przypisywany jest unikalny identyfikator (_id
) na poziomie dokumentu. Dodatkowo, każda modyfikacja dokonana i zapisana w bazie danych otrzymuje numer rewizji (_rev
). Ten numer rewizji umożliwia efektywne śledzenie i zarządzanie zmianami, ułatwiając łatwe pobieranie i synchronizację danych w bazie danych.
Domyślny port: 5984(http), 6984(https)
To wysyła żądanie GET do zainstalowanej instancji CouchDB. Odpowiedź powinna wyglądać mniej więcej jak jedna z poniższych:
Zauważ, że jeśli uzyskując dostęp do głównego katalogu couchdb otrzymasz 401 Unauthorized
z czymś takim jak: {"error":"unauthorized","reason":"Authentication required."}
nie będziesz mógł uzyskać dostępu do banera ani żadnego innego punktu końcowego.
To są punkty końcowe, do których możesz uzyskać dostęp za pomocą żądania GET i wyodrębnić interesujące informacje. Możesz znaleźć więcej punktów końcowych i bardziej szczegółowe opisy w dokumentacji couchdb.
/_active_tasks
Lista uruchomionych zadań, w tym typ zadania, nazwa, status i identyfikator procesu.
/_all_dbs
Zwraca listę wszystkich baz danych w instancji CouchDB.
/_cluster_setup
Zwraca status węzła lub klastra, zgodnie z kreatorem konfiguracji klastra.
/_db_updates
Zwraca listę wszystkich zdarzeń bazy danych w instancji CouchDB. Istnienie bazy danych _global_changes
jest wymagane do korzystania z tego punktu końcowego.
/_membership
Wyświetla węzły, które są częścią klastra jako cluster_nodes
. Pole all_nodes
wyświetla wszystkie węzły, o których ten węzeł wie, w tym te, które są częścią klastra.
/_scheduler/jobs
Lista zadań replikacji. Opis każdego zadania będzie zawierał informacje o źródle i celu, identyfikator replikacji, historię ostatnich zdarzeń i kilka innych rzeczy.
/_scheduler/docs
Lista stanów dokumentów replikacji. Zawiera informacje o wszystkich dokumentach, nawet w stanach completed
i failed
. Dla każdego dokumentu zwraca identyfikator dokumentu, bazę danych, identyfikator replikacji, źródło i cel oraz inne informacje.
/_scheduler/docs/{replicator_db}
/_scheduler/docs/{replicator_db}/{docid}
/_node/{node-name}
Punkt końcowy /_node/{node-name}
może być użyty do potwierdzenia nazwy węzła Erlang serwera, który przetwarza żądanie. Jest to najbardziej przydatne podczas uzyskiwania dostępu do /_node/_local
, aby uzyskać te informacje.
/_node/{node-name}/_stats
Zasób _stats
zwraca obiekt JSON zawierający statystyki dla działającego serwera. Literalny ciąg _local
służy jako alias dla lokalnej nazwy węzła, więc dla wszystkich adresów URL statystyk, {node-name}
może być zastąpione _local
, aby interagować ze statystykami lokalnego węzła.
/_node/{node-name}/_system
Zasób _system zwraca obiekt JSON zawierający różne statystyki na poziomie systemu dla działającego serwera_._ Możesz użyć ___local
jako {node-name}, aby uzyskać informacje o bieżącym węźle.
/_node/{node-name}/_restart
/_up
Potwierdza, że serwer jest uruchomiony, działa i jest gotowy do odpowiadania na żądania. Jeśli maintenance_mode
jest true
lub nolb
, punkt końcowy zwróci odpowiedź 404.
/_uuids
Żąda jednego lub więcej Uniwersalnych Unikalnych Identyfikatorów (UUID) z instancji CouchDB.
/_reshard
Zwraca liczbę zakończonych, nieudanych, uruchomionych, zatrzymanych i całkowitych zadań wraz z stanem reshardingu w klastrze.
Więcej interesujących informacji można wyodrębnić, jak wyjaśniono tutaj: https://lzone.de/cheat-sheet/CouchDB
Jeśli ta prośba zwraca 401 nieautoryzowany, potrzebujesz ważnych poświadczeń, aby uzyskać dostęp do bazy danych:
Aby znaleźć ważne dane logowania, możesz spróbować przeprowadzić atak brute force na usługę.
To jest przykład odpowiedzi couchdb, gdy masz wystarczające uprawnienia do wyświetlenia baz danych (to tylko lista baz danych):
Możesz uzyskać informacje o bazie danych (takie jak liczba plików i rozmiary) uzyskując dostęp do nazwy bazy danych:
Wymień każdy wpis w bazie danych
Przeczytaj zawartość dokumentu w bazie danych:
Dzięki różnicom między parserami JSON w Erlangu i JavaScript możesz utworzyć użytkownika administratora z danymi uwierzytelniającymi hacktricks:hacktricks
za pomocą następującego żądania:
Więcej informacji na temat tej luki tutaj.
Przykład stąd.
W dokumentacji CouchDB, szczególnie w sekcji dotyczącej konfiguracji klastra (link), omawiane jest użycie portów przez CouchDB w trybie klastra. Wspomniano, że, podobnie jak w trybie samodzielnym, port 5984
jest używany. Dodatkowo, port 5986
jest przeznaczony dla lokalnych API węzłów, a co ważne, Erlang wymaga portu TCP 4369
dla Daemon Port Mapper Erlang (EPMD), ułatwiającego komunikację między węzłami w klastrze Erlang. Ta konfiguracja tworzy sieć, w której każdy węzeł jest połączony z każdym innym węzłem.
Podkreślono istotne ostrzeżenie dotyczące portu 4369
. Jeśli ten port jest udostępniony w Internecie lub w jakiejkolwiek niezaufanej sieci, bezpieczeństwo systemu w dużej mierze opiera się na unikalnym identyfikatorze znanym jako "ciasteczko." To ciasteczko działa jako zabezpieczenie. Na przykład, w danej liście procesów, ciasteczko o nazwie "monster" może być obserwowane, co wskazuje na jego rolę operacyjną w ramach systemu zabezpieczeń.
Dla tych, którzy są zainteresowani zrozumieniem, jak ten "ciasteczko" może być wykorzystane do zdalnego wykonania kodu (RCE) w kontekście systemów Erlang, dostępna jest dedykowana sekcja do dalszego czytania. Opisuje ona metodologie wykorzystywania ciasteczek Erlang w nieautoryzowany sposób w celu uzyskania kontroli nad systemami. Możesz zbadać szczegółowy przewodnik na temat nadużywania ciasteczek Erlang dla RCE tutaj.
Przykład stąd.
Ostatnio ujawniona luka, CVE-2018-8007, wpływająca na Apache CouchDB, została zbadana, ujawniając, że wykorzystanie jej wymaga uprawnień do zapisu w pliku local.ini
. Chociaż nie jest to bezpośrednio stosowane do początkowego systemu docelowego z powodu ograniczeń bezpieczeństwa, wprowadzono modyfikacje, aby przyznać dostęp do zapisu w pliku local.ini
w celach eksploracyjnych. Poniżej przedstawiono szczegółowe kroki i przykłady kodu, ilustrujące ten proces.
Najpierw środowisko jest przygotowywane poprzez upewnienie się, że plik local.ini
jest zapisywalny, co jest weryfikowane poprzez wylistowanie uprawnień:
Aby wykorzystać lukę, wykonywana jest komenda curl, celując w konfigurację cors/origins
w local.ini
. To wstrzykuje nowy origin wraz z dodatkowymi komendami w sekcji [os_daemons]
, mając na celu wykonanie dowolnego kodu:
Następna weryfikacja pokazuje wstrzykniętą konfigurację w local.ini
, porównując ją z kopią zapasową, aby uwydatnić zmiany:
Początkowo oczekiwany plik (/tmp/0xdf
) nie istnieje, co wskazuje, że wstrzyknięte polecenie nie zostało jeszcze wykonane. Dalsze badania ujawniają, że działają procesy związane z CouchDB, w tym jeden, który potencjalnie mógłby wykonać wstrzyknięte polecenie:
Poprzez zakończenie zidentyfikowanego procesu CouchDB i pozwolenie systemowi na automatyczne jego ponowne uruchomienie, wywoływana jest egzekucja wstrzykniętej komendy, co potwierdza istnienie wcześniej brakującego pliku:
To badanie potwierdza wykonalność eksploatacji CVE-2018-8007 w określonych warunkach, szczególnie wymóg dostępu do zapisu do pliku local.ini
. Podane przykłady kodu i kroki proceduralne oferują jasny przewodnik do powtórzenia eksploatu w kontrolowanym środowisku.
Aby uzyskać więcej informacji na temat CVE-2018-8007, zapoznaj się z komunikatem mdsec: CVE-2018-8007.
Przykład stąd.
Zbadano lukę znaną jako CVE-2017-12636, która umożliwia wykonanie kodu za pośrednictwem procesu CouchDB, chociaż konkretne konfiguracje mogą uniemożliwić jej eksploatację. Pomimo licznych odniesień do Proof of Concept (POC) dostępnych w Internecie, konieczne są dostosowania, aby wykorzystać lukę w wersji CouchDB 2, różniącej się od powszechnie atakowanej wersji 1.x. Początkowe kroki obejmują weryfikację wersji CouchDB i potwierdzenie braku oczekiwanego ścieżki serwerów zapytań:
Aby dostosować się do wersji CouchDB 2.0, wykorzystuje się nową ścieżkę:
Próby dodania i wywołania nowego serwera zapytań spotkały się z błędami związanymi z uprawnieniami, co zostało wskazane przez następujący wynik:
Dalsze śledztwo ujawniło problemy z uprawnieniami do pliku local.ini
, który nie był zapisywalny. Poprzez modyfikację uprawnień pliku z dostępem root lub homer, stało się możliwe kontynuowanie:
Subsequent attempts to add the query server succeeded, as demonstrated by the lack of error messages in the response. The successful modification of the local.ini
file was confirmed through file comparison:
Proces kontynuowany był od utworzenia bazy danych i dokumentu, a następnie próby wykonania kodu za pomocą niestandardowego widoku mapującego do nowo dodanego serwera zapytań:
A podsumowanie z alternatywnym ładunkiem dostarcza dalszych informacji na temat wykorzystania CVE-2017-12636 w określonych warunkach. Przydatne zasoby do wykorzystania tej podatności obejmują:
port:5984 couchdb
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)