9 января в 18:50

Хакеры атакуют MongoDB: число скомпрометированных систем превысило 27 000



В СМИ попала информация о масштабной волне кибератак, жертвами которых становятся администраторы систем, использующих MongoDB. Злоумышленники получают к ним доступ, а затем удаляют данные из уязвимых или неверно настроенных систем, после чего требуют выкуп.

Норвежский исследователь информационной безопасности и работник Microsoft Ниал Мерриган (Niall Merrigan) зафиксировал всплеск атак, целью которых были системы MongoDB — по его словам всего за двенадцать часов их число увеличилось с 12 000 до 27 633. Часто злоумышленники вымогают у администраторов взломанных систем деньги за возвращение данных — на начало волны кибератак сумма составляла 0,2 биткоина ($184). Есть информация о том, что некоторые жертвы действительно осуществляли выплаты взломщикам.

Мерриган и его коллеги сумели отследить активность 15 хакеров — один из них, под ником kraken0, взломал 15 482 экземпляров MongoDB и требовал от их администраторов по одному биткоину ($921) за возврат данных — однако, пока никто ему не платил.

Ниал Мерриган и его коллега Виктор Жеверс (Victor Gevers) помогли 112 жертвам повысить защищенность их уязвимых систем. При этом, по словам Жеверса, всего уязвимы 99 000 систем MongoDB.

Защищенность систем MongoDB — известная проблема. Еще в 2015 году основатель поисковика Shodan Джон Мэзерли (John Matherly) публиковал данные исследований, согласно которым более 30000 экземпляров MongoDB были доступны из интернета без контроля доступа.
Автор: @ptsecurity
Positive Technologies
рейтинг 337,23

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

  • +19

    M310: MongoDB Security — курс лекций начинается завтра (10 Jan 2017 at 17:00 UTC)

    • +1

      Жесткий пиар?

      • +3

        Почему? Курс от создателей MongoDB, на их площадке. Просто полезная ссылка в рамках статьи.

        • 0
          Вещаю с рубки: очевидно, намёк на пиар со стороны создателей курса путём массового взлома своей же MongoDB :)
  • +7
    Вероятнее всего слово взломал/взломали в статье следует употреблять в кавычках, почти уверен что эти все базы имеют дефолтные настройки безопасности, т.е. без парольный доступ и сводит взлом к поиску открытого дефолтного порта и «настройки» этой самой безопасности атакующим.
    • 0
      То есть, вот так просто можно получить доступ извне? Ужас. Скорее всего это вынужденная жертва.
      Easy to learn hard to master
    • 0
      Описание установки MongoDB для Red Hat/CentOS с вами согласно.

      The default /etc/mongod.conf configuration file supplied by the 3.0 series packages has bind_ip set to 127.0.0.1 by default.
      — до этого в дефолтной конфигурации действительно, как минимум, слушались все интерфейсы.
    • +7

      Тоже подумал, что "взломщик" как-то так действовал:


      for ip in $ips
      do
        mongo --host $ip script.js
      done
  • +2
    Народ не совсем осознает, чем конкретно в mongodb пожертвовали ради няшности, user-friendly — имиджа и доступности представителям интеллектуального большинства. В частности пожертвовали принципом «Secure by default», доступностью данных, serializability и т.д.
    • –5

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

  • +7
    Глядишь, через годик эти «хакеры» узнают, что elasticsearch или там redis тоже по умолчанию открыты наружу без паролей.
    • 0
      А что такого важного можно в redis хранить?
      • 0

        А что такого неважного там может оказаться?

        • 0
          Ну например кеш шаблонов, какие-то счетчики которые пересчитывать при каждом обновлении страницы не очень хорошо и т.д. Не пароли же в редисе хранить, и не важный контент.
          • +2

            Модифицируем шаблоны в кеше — и внедряем на сайт произвольные скрипты или баннеры без модификации исходников. Как вам такой вариант?

            • 0
              А кто такое дело не шифрует? По-моему все популярные движки и фреймворки как-то шифруют свой кеш.
              • +2

                Разве что если шифрование по умолчанию настроено. Потому что тот кто не закрывает redis шифрование сам включать точно не станет.

              • +2
                Шифруют кеш? Что-то не встречал такое. Да и какой смысл в этом.
                • +2
                  Видимо для того, чтобы при каждом запросе содержимое кэша героически расшифровывать :) Ведь кэш делают как для того, чтобы было на что потратить свободные ресурсы CPU :)
      • 0
        Дело даже не в этом. В редисе были уявзимости позволяющие выполнять произвольный код.

        https://redislabs.com/blog/cve-2015-4335-dsa-3279-redis-lua-sandbox-escape#.WHTnuPF96kA

        А если мы говорим, о таких безолаберных «админах» которые даже порт закрыть не могут, то я сильно сомневаюсь, что они какие-то патчи накатывали.

        У меня есть знакоммые, у которых через редис тестовый сервел ломанули.
        • 0

          Я таких админов называю "безоблачные". Потому что они остаются без облака.

      • 0

        Может я удивлю, но redis оочень часто используется как session storage. И часто без всякого криптования. Что можно сделать плохого, имея токен сессии, думаю, объяснять не надо.

  • +7
    взломал 15 482 экземпляров MongoDB и требовал от их администраторов по одному биткоину ($921) за возврат данных — однако, пока никто ему не платил.

    однако, пока никто ему не платил

    Из 15 482 пострадавших 4 131 восстановили свою тестовую базу с прода, а 11 351 написали новый хелловорд, заменив NodeJS на Go.
  • 0
    --bind_ip=127.0.0.1

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

Самое читаемое Разработка