Grabienie danych z Elasticsearch dla zabawy i zysku

06 października 2016, 13:33 | Teksty | komentarze 4
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

W tym artykule znajdziesz odpowiedź na pytanie: dlaczego pozostawianie odsłoniętych publicznie baz – prędzej czy później – kończy się wyciekiem danych?

Dowiesz się też o tym, jak łatwo wydobyć dane z serwera ElasticSearch i – wyjątkowych przypadkach – uzyskać dostęp do systemu operacyjnego.

Pamiętajcie też aby nie atakować systemów innych bez formalnego pozwolenia.

Wstęp

W 2015 roku, dane 13 milionów użytkowników programu MacKeeper wyciekły, z powodu przechowywania ich w otwartej bazie MongoDB. Wówczas, sam autor wyszukiwarki shodan.io przeprowadził badanie i wykrył, że publicznie dostępnych jest około 600 TB danych. Po publikacji wyników badania w lipcu ubiegłego roku, już w grudniu okazało się, że ilość publicznie dostępnych baz NoSQL wzrosła o 5 tysięcy, a ilość danych osiągnęła wolumen 685 TB. Świat devopsów, zamiast wyciągnąć wnioski z zaistniałej sytuacji, jeszcze bardziej pogrążył się w koszmarze nieautoryzowanego dostępu do danych.

MongoDB nie było i nie jest jedyną bazą danych, z której wyciekły dane –  problem występuje również dla Redis, CouchDB, Cassandra oraz Riak (jeśli chodzi o bazy NoSQL).

Uwaga: aby podejrzeć zawartość linków, wymagane jest posiadanie konta w serwisie (istnieje możliwość jego darmowego założenia).

W shodanie występuje jeszcze jedna interesująca pozycja. Adresuje ona potrzeby procesowania dużych ilości danych, pozwala na automatyzację instalacji i konfiguracji, zarazem posiadając cechy rozproszonej architektury skierowanej na usługi,  nie będąc silnikiem NoSQL. Sam github używa jej jako własnej wyszukiwarki, natomiast w projektach języka Java, stanowi numer #1 .

Tak jak LAMP stał się akronimem dla Linux, Apache, (MariaDB|MySQL), (PHP|Perl|Python), tak dzisiaj ELK jest rozpoznawany jako ElasticSearch, Logstash i Kibana. Większość projektów z udziałem ElasticSearch, wiąże się głównie z analizą logów ze względu na graylog2, ale równie popularne zastosowania znajduje w analizie danych oraz wyszukiwaniu pełnotekstowym. Według shodana, obecnie funkcjonuje około 8.000 otwartych serwerów ElasticSearch, które oferują różne usługi i dane. Czasem możemy trafić na testowe bazy tworzone w celu analizy produktów konkurencji, niekiedy są to zapisy z urządzeń służących do rejestrowania kart dostępu, a w innych przypadkach – nawet dane autoryzacyjne. Raport z podziałem na kraje, dostawców hostingu oraz użytych wersji ES i systemów operacyjnych, znajdziemy tutaj.

Struktura danych, przykłady realizacji testów

Zanim przejdziemy do przedstawienia konkretnych przykładów testów penetracyjnych, zapoznajmy się z podstawami architektury danych. Elastic przechowuje dane w obiektach. De facto, są to obiekty JSONowe. Wiele obiektów, połączonych w spójną całość na najwyższym poziomie tworzących jeden spójny JSON, są nazywanane dokumentem. Każdy dokument jest przechowywany w odpowiednim (użytkownik decyduje, w jakim) indeksie, pod unikalnym ID. Dlatego, aby wydobyć przykładowe dane z serwera ES, musimy podłączyć się do wybranej instancji za pomocą API, wyświetlić listę dostępnych indeksów, a następnie przejrzeć kilka dokumentów, aby zapoznać się z ich strukturą i informacjami, jakie przechowują.

Dla uproszczenia podejścia, w opisanych niżej przykładach użyty został skrypt napisany w Pythonie – eshell, prosta abstrakcja powłoki systemowej dla ElasticSearch, wygodniejsza alternatywa dla wpisywania poleceń za pomocą curl. Przetestowany oraz stworzony z wersją 1.7.x, bez problemu realizuje także podstawowe polecenia dla wersji 2.x.

1. Połączenie do serwera oraz wyświetlenie listy dostępnych indeksów z dokumentami

Serwer ES dla REST API standardowo udostępnia port 9200 – jeśli nie jest zajęty – oraz 9300, dla protokołu transportu)

Pod kolumną index, znajduje się jego nazwa, a docs.count informuje nas, ile dokładnie dokumentów znajduje się w danym indeksie. Aby wyświetlić zawartość dowolnego indeksu i jego 15 pierwszych dokumentów wystarczy, że wydamy polecenie:

W tym przypadku, trafiliśmy na dane systemu Grafana do tworzenia dashboardów oraz analizy metryk. Jeśli wpadną nam w ręce interesujące treści, które chcielibyśmy przeanalizować off-line, lub poddać archiwizacji w celu okazania dowodu – możemy to wykonać za pomocą narzędzia napisanego w nodejs – elasticdump. Jest ono w stanie zrzucić nam konkretne indeksy do plików, lub nawet zapewnić import do innych serwerów ElasticSearch.

2. Rozpoznanie wewnętrznej adresacji sieci

Serwery ES oferują możliwość tworzenia klastrów, które komunikują się zazwyczaj po lokalnej sieci, aby nie stracić spójności danych w przypadku częstych niestabilności sieciowych:

Mimo, że podłączyliśmy się po zewnętrznym interfejsie, jesteśmy w stanie uzyskać informację o wewnętrznej sieci oraz adresach sąsiadujących serwerów.

3. Wersja JDK oraz możliwość dodawania skryptów w różnych językach

Sprawdzenie, jaka wersja JDK jest zainstalowana w systemie oraz czy dana wersja ES jest podatna na CVE-2015-1427, lub posiada konfigurację umożliwiającą tworzenie skryptów:

Kolumna „version” informuje nas, w jakiej wersji jest zainstalowany serwer ElasticSearch, „jdk” wskazuje na wersję Java Development Kit (przydatne, jeśli na serwerze działają różne aplikacje, które chcemy poddać testom na inne ataki). Wersja ES bardzo ważna, z uwagi na to, że wersje przed 1.4.3 oraz 1.3.8, są podatne na Remote Code Execution, poprzez dodanie spreparowanych skryptów. Od wspomnianych wcześniej wersji, dynamiczne skrypty są w standardowej konfiguracji wyłączone. Dlatego, w wyższych wersjach – zamiast na „ślepo” sprawdzać możliwość dodania skryptów, możemy po prostu sprawdzić, czy w ustawieniach węzłów są przebite wartości:

Podsumowanie

Wiemy, że skala przedstawionego procesu jest dość duża (ilość publicznych instancji), ale czy jest poważna?

Przed publikacją tekstu, po zbadaniu zaledwie kilkunastu sprofilowanych instancji ES według: 1. kraju 2. właściciela sieci, udało mi się uchronić jedną z polskich firm teleinformatycznych przed wyciekiem 2529 prywatnych danych, w postaci: imię, nazwisko, e-mail. Poniżej cytuję treść odpowiedzi:

Witam, dziękuję za informację.

Faktycznie jedna z aplikacji zainstalowanych na serwerze wymagała usługi elasticsearch.

Usługa została uruchomiona, ale niewłaściwie skonfigurowana, w tej chwili nie jest już dostępna z zewnątrz.

Szczęście miała również jedna z topowych firm hostingu dedykowanego – przeprowadzone przeze mnie badanie, uchroniło ją przed dostępem do logów prywatnych chmur obliczeniowych, zawierających wrażliwe dane odnośnie architektury oraz procesów zachodzących w ich rozwiązaniu, opartym na OpenStack.  Poniżej treść odpowiedzi:

Dear Patryk:

Thanks for your report. This issue has been fixed. Please verify. Have a great day.

Całość operacji zajęła nie więcej niż 40 minut, co obrazuje łatwość i szybkość doprowadzenia do kolejnego wycieku (i podbicia statystyk), lub dalszej infiltracji sieci i systemów. Bardzo wiele rozwiązań do przechowywania danych, które powstały w ostatnich latach, zdecydowanie ułatwiają życie w procesie tworzenia i rozwoju aplikacji internetowych. Jednak, jak każde narzędzie nienależycie skonfigurowane, stanowi miecz obosieczny mogący ranić jego użytkownika. Wydaje się, że tempo rozwoju opisywanej technologii jest szybsze, niż wzrost świadomości jej konsumentów.

– Patryk Krawaczyński

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. pani_od_polskiego

    „zastosowania znajduje w analityce danych”
    Powinno być ‚w analizie’ danych. Oczywiście jest w języku polskim słowo analityka, ale w tym kontekście nie ma zastosowania.

    Odpowiedz
  2. a.nie

    „Adresuje ona potrzeby procesowania dużych ilości danych”
    Odkryliście generator korpogadki i losowo umieszczacie teraz w artykułach? :)
    Abstrahując od mojego czepialstwa – artykuł całkiem ciekawy – dzięki.

    Odpowiedz
  3. OiSiS

    To samo z Grafana na porcie: 3000. W google np:
    inurl:”:3000/” Grafana
    default login/passwd: admin/admin

    Odpowiedz

Odpowiedz