На прошлой неделе издание Коммерсантъ сообщило, что «базы клиентов Street Beat и Sony Centre оказались в открытом доступе», но на самом деле все гораздо хуже, чем написано в статье.



Подробный технический разбор данной утечки я уже делал у себя в Telegram-канале, поэтому тут пробежимся только по основным моментам.


Дисклеймер: вся информация ниже публикуется исключительно в образовательных целях. Автор не получал доступа к персональным данным третьих лиц и компаний. Информация взята либо из открытых источников, либо была предоставлена автору анонимными доброжелателями.

В свободном доступе оказался очередной сервер Elasticsearch с индексами:


  • graylog2_0
  • readme
  • unauth_text
  • http:
  • graylog2_1

В graylog2_0 содержались логи начиная с 16.11.2018 по март 2019, а в graylog2_1 – логи начиная с марта 2019 и по 04.06.2019. До момента закрытия доступа к Elasticsearch, количество записей в graylog2_1 росло.


По данным поисковика Shodan этот Elasticsearch находился в свободном доступе с 12.11.2018 (при этом, как написано выше, первые записи в логах датированы 16.11.2018).


В логах, в поле gl2_remote_ip были указаны IP-адреса 185.156.178.58 и 185.156.178.62, с DNS-именами srv2.inventive.ru и srv3.inventive.ru:



Я оповестил Inventive Retail Group (www.inventive.ru) о проблеме 04.06.2019 в 18:25 (МСК) и к 22:30 сервер «тихо» исчез из свободного доступа.


В логах содержалось (все данные – оценочные, дубли из подсчетов не удалялись, поэтому объем реальной утекшей информации скорее всего меньше):


  • более 3 млн. адресов электронной почты покупателей магазинов re:Store, Samsung, Street Beat и Lego
  • более 7 млн. телефонов покупателей магазинов re:Store, Sony, Nike, Street Beat и Lego
  • более 21 тыс. пар логин/пароль от личных кабинетов покупателей магазинов Sony и Street Beat.
  • большинство записей с телефонами и электронной почтой также содержали ФИО (часто латиницей) и номера карт лояльности.

Пример из лога, относящийся к клиенту магазина Nike (все чувствительные данные заменены на символы «Х»):


"message": "{\"MESSAGE\":\"[URI] /personal/profile/[МЕТОД ЗАПРОСА] contact[ДАННЫЕ POST] Array\\n(\\n    [contact[phone]] => +7985026XXXX\\n    [contact[email]] => XXX@mail.ru\\n    [contact[channel]] => \\n    [contact[subscription]] => 0\\n)\\n[ДАННЫЕ  GET] Array\\n(\\n    [digital_id] => 27008290\\n    [brand] => NIKE\\n)\\n[ОТВЕТ СЕРВЕРА] Код ответа - 200[ОТВЕТ СЕРВЕРА] stdClass Object\\n(\\n    [result] => success\\n    [contact] => stdClass Object\\n        (\\n            [phone] => +7985026XXXX\\n            [email] => XXX@mail.ru\\n            [channel] => 0\\n            [subscription] => 0\\n        )\\n\\n)\\n\",\"DATE\":\"31.03.2019 12:52:51\"}",

А вот пример того, как в логах хранились логины и пароли от личных кабинетов покупателей на сайтах sc-store.ru и street-beat.ru:


"message":"{\"MESSAGE\":\"[URI]/action.php?a=login&sessid=93164e2632d9bd47baa4e51d23ac0260&login=XXX%40gmail.com&password=XXX&remember=Y[МЕТОД ЗАПРОСА] personal[ДАННЫЕ  GET] Array\\n(\\n    [digital_id] => 26725117\\n    [brand]=> SONY\\n)\\n[ОТВЕТ СЕРВЕРА] Код ответа - [ОТВЕТ СЕРВЕРА] \",\"DATE\":\"22.04.2019 21:29:09\"}"

Официальное заявление IRG по данному инциденту можно почитать тут, выдержка из него:


Мы не могли оставить этот момент без внимания и сменили пароли к личным кабинетам клиентов на временные, во избежание возможного использования данных из личных кабинетов в мошеннических целях. Утечки персональных данных клиентов street-beat.ru компания не подтверждает. Оперативно были проверены дополнительно все проекты Inventive Retail Group. Угрозы для персональных данных клиентов не обнаружены.

Плохо, что в IRG не могут разобраться с тем, что утекло, а что нет. Вот пример из лога, относящийся к клиенту магазина Street Beat:


"message": "{\"MESSAGE\":\"'DATA' => ['URI' => /local/components/multisite/order/ajax.php,'МЕТОД ЗАПРОСА' = contact,'ДАННЫЕ POST' = Array\\n(\\n    [contact[phone]] => 7915545XXXX\\n)\\n,'ДАННЫЕ  GET' =\\n\\t\\tArray\\n(\\n    [digital_id] => 27016686\\n    [brand] => STREETBEAT\\n)\\n,'ОТВЕТ СЕРВЕРА' = 'Код ответа - '200,'RESPONCE' = stdClass Object\\n(\\n    [result] => success\\n    [contact] => stdClass Object\\n        (\\n            [phone] => +7915545XXXX\\n            [email] => XXX@gmail.com\",\"Дата\":\"01.04.2019 08:33:48\"}",

Однако, перейдем к совсем плохим новостям и объясним, почему это именно утечка персональных данных клиентов IRG.


Если внимательно присмотреться к индексам данного свободно доступного Elasticsearch, то можно в них заметить два имени: readme и unauth_text. Это характерный признак одного из многочисленных скриптов-вымогателей. Им поражено более 4 тыс. серверов Elasticsearch по всему миру. Содержимое readme выглядит так:


"ALL YOUR INDEX AND ELASTICSEARCH DATA HAVE BEEN BACKED UP AT OUR SERVERS, TO RESTORE SEND 0.1 BTC TO THIS BITCOIN ADDRESS 14ARsVT9vbK4uJzi78cSWh1NKyiA2fFJf3 THEN SEND AN EMAIL WITH YOUR SERVER IP, DO NOT WORRY, WE CAN NEGOCIATE IF CAN NOT PAY"

За время пока сервер с логами IRG находился в свободном доступе, к информации клиентов точно получал доступ скрипт-вымогатель и, если верить оставленному им сообщению, данные были скачены.


Кроме того, у меня нет никаких сомнений, что эту базу нашли еще до меня и уже скачали. Я бы даже сказал, что уверен в этом. Нет никакого секрета в том, что подобные открытые базы целенаправленно ищутся и выкачиваются.


Новости про утечки информации и инсайдеров всегда можно найти на моем Telegram-канале «Утечки информации»: https://t.me/dataleak.

Комментарии (21)


  1. tvr
    12.06.2019 10:24
    +1

    Никогда такого не было и вот...
    А если серьёзно, то:
    «Для доступа в систему необходимо перейти по следующей ссылке: xyz.ru
    В поле Логин введите: xxxxx
    Ваш пароль для доступа в систему: yyyyy»
    Письмо от одного из ведущих вендоров телеком железок и потребительской электроники, при восстановлении/плановом обновлении пароля для доступа к некоторым сервисам.
    А вы тут про магазины.


  1. Foreglance
    12.06.2019 13:18

    Разве кто-то до сих пор хранит пароли на серверах — не хэши?


    1. Protos
      12.06.2019 14:44
      +1

      Это логи


      1. hunroll
        12.06.2019 15:27

        А это разве оправдывает использование паролей в чистом виде? Что мешает посчитать хеш на клиенте чтобы это никуда не попало?


        1. freeExec
          12.06.2019 16:13
          +2

          Никто не хеширует пароли на стороне клиента.


          1. ivanrt
            13.06.2019 04:52

            Атакующий пошлет сразу правильный хэш. Это не отменяет того что в логах пароли должны или врезаться или заменяться с помощью односторонней функции


            1. freeExec
              13.06.2019 09:17

              Так то да, но атакующий не узнает исходного пароля, и в другом месте, если там другая хеш-функция, не сможет воспользоваться. Так что плюсы а таком подходе есть.


              1. ivanrt
                13.06.2019 13:59

                Плюсы есть, хотя весьма сомнительные — если кто-то может перехватить пароль или хэш пароля, то это уже серьёзная проблема. К тому-же хэш будет или без соли или с солью с сервера, а это усложнение протокола с весьма сомнительным выигрышем.


        1. Protos
          12.06.2019 17:19

          Не оправдывает наличие конфи в логах да ещё и анализ их в левом ПО. Хэшировать пароли на клиенте ещё глупее занятие, особенно бесит аутентификации по ntlm хэшу, когда достаточно его перехватить и пароль далее не надо знать


          1. hunroll
            12.06.2019 17:27

            когда достаточно его перехватить и пароль далее не надо знать

            Ну так если мы перехватываем пакет авторизации — то там будет пароль в чистом виде. И перехватчику уже побоку сайт Сони или Найка или кого-то там ещё, он пойдёт вставлять этот пароль в более интересные учётки.
            Я не троллю, просто не понимаю, как отправка пароля по сети в чистом виде может быть безопаснее? Как сейчас принято делать «по-уму»?


            1. Revertis
              12.06.2019 17:51

              Обычно надеются на HTTPS.


            1. KarimSI
              12.06.2019 18:22
              +3

              Если считать хэш на клиенте, это будет означать что сервер начинает принимать хэш вместо пароля для авторизации. При утечке базы с хэшами паролей теперь у злоумышленника будет доступ ко всем аккаунтам. Если же сервер принимает только пароли и сам считает хэш, утечка базы с хэшами паролей становится чуть менее страшной.

              А с точки зрения перехвата не вижу разницы, слать с клиента пароль или хэш, если и того и другого будет достаточно для авторизации на сервере.


              1. onlinehead
                12.06.2019 19:42

                При утечке базы с хэшами паролей теперь у злоумышленника будет доступ ко всем аккаунтам
                А при утечке базы с plain text паролями разве не будет?
                Кажется логичнее все таки хранить солёные хэши в базе, считать их можно от чистого пароля или от хэша на клиенте. По крайней мере в таком случае оно хотя бы по таблицам искаться не будет в случае утечки.


                1. KarimSI
                  12.06.2019 19:45

                  В базе всегда храним только хэши. Об этом даже речи не идет.
                  Мой комментарий отвечал на вопрос, где считать хэш — на сервере или клиенте, и в чем разница.


                  1. Samver
                    13.06.2019 15:04

                    Надо обязательно солить хэши.
                    Считать и солить надо на сервере, иначе толку от соли не будет.
                    Все что происходит на клиенте, можно исследовать, в том числе момент соления.


    1. ashotog Автор
      12.06.2019 15:41

      разумеется хранит. я постоянно пишу про это в статьях на Хабре.


  1. megapro17
    12.06.2019 16:23
    -5

    Зачем нужны ваши бесполезные статьи, без самих баз?


    1. alexesDev
      12.06.2019 17:06
      +1

      Потому что за базы следователь может пригласить?


      1. megapro17
        12.06.2019 18:55

        TOR и I2P отменили?


    1. bestie
      12.06.2019 18:55
      +1

      Могу лишь предположить, что за выкладывание таких баз, вполне себе, возможно наказание. И возможно, не только денежное.
      А вот показать потенциальные проблемы при использовании подобных сервисов не только ненаказуемо, а даже полезно. При том, что владелец исходного ресурса уже уведомлен и исправил проблему на своей стороне.


  1. Kellis
    13.06.2019 12:55

    Так есть где база, можно где-то проверить себя?