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ąć 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 – aby podejrzeć zawartość linków, wymagane jest posiadanie konta w serwisie). 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 tekstowe 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ą nazywane 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ą portu 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 języku Python – eshell, prosta abstrakcja powłoki systemowej dla ElasticSearch, wygodniejsza alternatywa dla wypisywania 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 analiz 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ą 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 jest bardzo ważna, z uwagi na to, że wersje przed 1.4.3 oraz 1.3.8, są podatne na Remote Code Execution (Zdalne Wykonanie Kodu), poprzez dodanie spreparowanych skryptów. Od wspomnianych wcześniej wersji, dynamiczne skrypty są w fabrycznej 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 instalacji 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 na zgłoszenie możliwego naruszenia bezpieczeństwa:

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.