Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Grabienie danych z Elasticsearch dla zabawy i zysku
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)
eshell 100.200.12.21 Connecting to elasticsearch server at address: 100.200.12.21 Connected to: 10.20.12.21 on port: 9200 ### Welcome to elasticsearch console! ### For more information, type 'help' es:~$ show Entering to cluster information menu. es:show~$ indices 1 health status index pri rep docs.count docs.deleted store.size pri.store.size 2 yellow open b0fffq9tck 5 1 578 0 145.5kb 145.5kb 3 yellow open b000a11da0 5 1 899 0 212.1kb 212.1kb 4 yellow open b00140tz71 5 1 668 0 179.3kb 179.3kb 5 yellow open b0fffzykc2 5 1 2873 0 568.4kb 568.4kb 6 yellow open b0fffpyak8 5 1 850 0 193.9kb 193.9kb
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:
es:show~$ indices_head b0fffq9tck 1 { 2 "took" : 13, 3 "timed_out" : false, 4 "_shards" : { 5 "total" : 5, 6 "successful" : 5, 7 "failed" : 0 8 }, 9 "hits" : { 10 "total" : 26, 11 "max_score" : 1.0, 12 "hits" : [ { 13 "_index" : "b0fffq9tck", 14 "_type" : "dashboard", 15 "_id" : "dis-system", 16 "_score" : 1.0, 17 "_source":{"user":"guest","group":"guest","title":"DIS - System","tags": [],"dashboard":"{\"id\":null,\"title\":\"DIS - System\",\"originalTitle\":\"DIS - System\",\"tags\": [],\"style\":\"dark\",\"t 18 }, { 19 "_index" : "b0fffq9tck", 20 "_type" : "dashboard", 21 "_id" : "redshift", 22 "_score" : 1.0, 23 "_source":{"user":"guest","group":"guest","title":"Redshift","tags": [],"dashboard":"{\"id\":null,\"title\":\"Redshift\",\"originalTitle\":\"Redshift\",\"tags\": [],\"style\":\"dark\",\"timezone\":\" 24 },
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:
es:show~$ nodes_ids id host ip port _Z-nL1rSRs6qiXs_kL3pGQ monitoring 10.0.1.16 9300 OnZSwXrlR8KzoZuh80RtHA central 10.0.1.20 9300
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:
es:show~$ nodes_jdk name host version build jdk pid Idunn iZ25esberwpZ 1.4.2 927caff 1.7.0_75 1421
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:
es:show~$ nodes_settings name: node-1 ip: 127.0.0.1 settings: client.type: node cluster.name: my-application config.ignore_system_properties: true foreground: false name: node-1 network.bind_host: 0.0.0.0 node.name: node-1 script.inline: on script.indexed: on path.conf: /etc/elasticsearch path.data: /var/lib/elasticsearch path.home: /usr/share/elasticsearch path.logs: /var/log/elasticsearch pidfile: /var/run/elasticsearch/elasticsearch.pid
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.
„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.
Hehe, może poczytali sekuraka:
http://www.tripwire.com/state-of-security/latest-security-news/1-5m-dating-site-users-passwords-exposed-by-misconfigured-database/#.V_URfCVEkL4.google_plusone_share
„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.
To samo z Grafana na porcie: 3000. W google np:
inurl:”:3000/” Grafana
default login/passwd: admin/admin