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 Credentials, możesz spróbować bruteforować usługę.
To jest przykład odpowiedzi couchdb, gdy masz wystarczające uprawnienia do wylistowania baz danych (To jest po prostu lista dbs):
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, a konkretnie 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ła, 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, można zaobserwować ciasteczko o nazwie "monster", 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 dotyczący nadużywania ciasteczek Erlang w celu 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 badania potwierdzają 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 eksploitu 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, używany jest nowy adres:
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
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
