Утечка данных покупателей магазинов re:Store, Samsung, Sony Centre, Nike, LEGO и Street Beat

    На прошлой неделе издание Коммерсантъ сообщило, что «базы клиентов 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

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

        0
        Разве кто-то до сих пор хранит пароли на серверах — не хэши?
          +2
          Это логи
            0
            А это разве оправдывает использование паролей в чистом виде? Что мешает посчитать хеш на клиенте чтобы это никуда не попало?
              +2
              Никто не хеширует пароли на стороне клиента.
                0

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

                  0
                  Так то да, но атакующий не узнает исходного пароля, и в другом месте, если там другая хеш-функция, не сможет воспользоваться. Так что плюсы а таком подходе есть.
                    0
                    Плюсы есть, хотя весьма сомнительные — если кто-то может перехватить пароль или хэш пароля, то это уже серьёзная проблема. К тому-же хэш будет или без соли или с солью с сервера, а это усложнение протокола с весьма сомнительным выигрышем.
                +1

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

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

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

                      А с точки зрения перехвата не вижу разницы, слать с клиента пароль или хэш, если и того и другого будет достаточно для авторизации на сервере.
                        0
                        При утечке базы с хэшами паролей теперь у злоумышленника будет доступ ко всем аккаунтам
                        А при утечке базы с plain text паролями разве не будет?
                        Кажется логичнее все таки хранить солёные хэши в базе, считать их можно от чистого пароля или от хэша на клиенте. По крайней мере в таком случае оно хотя бы по таблицам искаться не будет в случае утечки.
                          0
                          В базе всегда храним только хэши. Об этом даже речи не идет.
                          Мой комментарий отвечал на вопрос, где считать хэш — на сервере или клиенте, и в чем разница.
                            0
                            Надо обязательно солить хэши.
                            Считать и солить надо на сервере, иначе толку от соли не будет.
                            Все что происходит на клиенте, можно исследовать, в том числе момент соления.
                +2
                разумеется хранит. я постоянно пишу про это в статьях на Хабре.
              • НЛО прилетело и опубликовало эту надпись здесь
                  +5

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

                  • НЛО прилетело и опубликовало эту надпись здесь
                    +4
                    Могу лишь предположить, что за выкладывание таких баз, вполне себе, возможно наказание. И возможно, не только денежное.
                    А вот показать потенциальные проблемы при использовании подобных сервисов не только ненаказуемо, а даже полезно. При том, что владелец исходного ресурса уже уведомлен и исправил проблему на своей стороне.
                    0
                    Так есть где база, можно где-то проверить себя?

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое