The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Некорректное использование Memcached приводит к уязвимостям сайтов

07.08.2010 11:23

На конференции BlackHat был прочитан доклад, в котором рассказывалось об организации атаки, позволяющей получить доступ к закрытой информации, такой как пароли пользователей, воспользовавшись некорректной настройкой системы кэширования Memcached. Проблема вызвана тем, что некоторые администраторы используют привязку Memcached к реальному IP (при запустке memcached на одном хосте с сайтом рекомендуется привязать его к адресу 127.0.0.1), забывая блокировать сетевой порт 11211 межсетевым экраном.

Так как в Memcached отсутствуют средства аутентификации, при наличии доступа к открытому сетевому порту злоумышленник может легко получить полный доступ (чтение и запись) ко всем хранимым в кэше данным. На первый взгляд может показаться, что атаке могут быть подвержены только сайты, на которых используются стандартные web-приложения для которых известна логика формирования ключей для хранения данных в кэше. Но это не так, дело в том, что значения ключей для закрытого сервиса можно легко вычислить используя встроенные в Memcached отладочные инструменты и команды для просмотра статистики. В качестве демонстрации приводится пример получения доступа к одному из аккаунтов социальной сети Gowalla.

Кроме того, в докладе обращается внимание на распространенность подобных ошибок, интернет оказался буквально наводнен сайтами с незакрытым портом memcached, среди которых встречаются такие крупные ресурсы как Gowalla, bit.ly и PBS. В частности, сканирование IP-адресов в течение 50 дней выявило в сети 229 серверов не блокирующих доступ к Memcached. В загруженных из кэша этих серверов данных, были обнаружены пароли (открытые и MD5), email-адреса, разнообразные сериализованные объекты, параметры пользовательских профилей и другая информация. Интересен также способ, которым экспериментаторы пользовались для определения соответствующего MD5-хэшу пароля - хэш достаточно было запросить в поисковой системе Google.

Для автоматизации проведения атаки, выявления важной информации из отладочных slab-дампов Memcached и подстановки своих данных в кэш автор доклада подготовил специальную утилиту go-derper.

  1. Главная ссылка к новости (http://www.sensepost.com/blog/...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/27552-security
Ключевые слова: security, memcached, cache, attack
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (22) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Антон (??), 11:50, 07/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А не это ли причина нашумевшего взлома аккаунтов в LiveJournal. Официально говорили, что был BrouteForce и перехват паролей троянами, но слишком уж много пользователей божилось, что пароли у них были не словарные и Windows они не пользуются или обложены антивирусами со всех сторон, не нашедших никаких троянов.
     
     
  • 2.5, klalafuda (?), 12:03, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > А не это ли причина нашумевшего взлома аккаунтов в LiveJournal. Официально говорили, что был BrouteForce и перехват паролей троянами, но слишком уж много пользователей божилось, что пароли у них были не словарные и Windows они не пользуются или обложены антивирусами со всех сторон, не нашедших никаких троянов.

    Не думаю. Ну не могут быть админы столь крупного и явно не бедного сервиса быть настолько тупыми.

     
     
  • 3.6, Aquarius (ok), 12:30, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    почему?
     
     
  • 4.7, klalafuda (?), 12:42, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > почему?

    Подсознательная вера в Большого Брата и в то, что он для рулежки своими критическими сервисами не будет нанимать совсем уж безголовый персонал. Выставить голой попой memcached наружу - это именно из этой оперы. Причем что каких-то обоснованных причин его туда выставлять я не вижу. Это или раздолбайство или махровое невежество. Минимально вменяемый админ себе такого не позволит.

     
     
  • 5.17, filosofem (ok), 18:28, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >и в то, что он для рулежки своими критическими сервисами не будет нанимать совсем уж безголовый персонал

    Вы не из России?

     
     
  • 6.18, klalafuda (?), 20:14, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы не из России?

    Ну нельзя же так уж совсем то ниже плинтуса опускать отечественных ITшников. Всему есть свой предел.

     
     
  • 7.19, filosofem (ok), 22:49, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не айтишников, а тех, кто нанимает безголовых айтишников.
     
  • 6.25, Aquarius (ok), 11:53, 14/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>и в то, что он для рулежки своими критическими сервисами не будет нанимать совсем уж безголовый персонал
    >
    >Вы не из России?

    обратите внимание на http://ru.wikipedia.org/wiki/Принцип_Питера
    и заметьте, что принцип сформулирован не россиянином и не на основе наблюдений за Россией

     
  • 3.12, Антон (??), 15:31, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Не думаю. Ну не могут быть админы столь крупного и явно не
    >бедного сервиса быть настолько тупыми.

    Насколько я понимаю у LJ очень большая сеть memcached-серверов, если на одном забыть настроить фаервол, то этого будет достаточно для взлома группы аккаунтов. Не факт, что пароли были получены, более похоже, что id определенных сессий перехватили и пароли поменяли. Вполне возможно, что сниффером а не через memcached, или с OpenID какие-нибудь манипуляции, например, через подставные формы паролей насобирали.


     

  • 1.3, pavlinux (ok), 11:53, 07/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Гугле рулит!!
     
     
  • 2.23, upyx (ok), 06:45, 09/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Интересен также способ, которым экспериментаторы пользовались для определения соответствующего MD5-хэшу пароля - хэш достаточно было запросить в поисковой системе Google.

    Да, таки на простых паролях работает :)

     

  • 1.4, klalafuda (?), 11:54, 07/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Мельчают, мельчают блекхатовцы. Через пару лет они так для себя и psexec глядишь откроют, да. Как очень оригинальный и свежий инструмент.
     
     
  • 2.16, sd (??), 17:29, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Мельчают, мельчают блекхатовцы. Через пару лет они так для себя и psexec
    >глядишь откроют, да. Как очень оригинальный и свежий инструмент.

    Ждём все когда Клалафуду клалафу родит свой первый мега опасный эксплойт, а пока ты не на defcon лучше такими фразами не бросаться.

     

  • 1.8, grearkir (?), 13:09, 07/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >>Для автоматизации проведения атаки, выявления важной информации из отладочных slab-дампов Memcached и подстановки своих данных в кэш автор доклада подготовил специальную утилиту go-derper.

    ./go-derper.rb -l -s ya.ru
    [memcache-client] Could not load SystemTimer gem, falling back to Ruby's slower/unsafe timeout library: no such file to load -- system_timer
    [w] No output directory specified, defaulting to ./output
    [w] No prefix supplied, using "run1"
    [E] Can't enable debug mode on server, leaching only through brute-force is currently unsupported
    Что бы это значило?

     
     
  • 2.15, Митра (?), 16:05, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Относительно первого предупреждения - [sudo] gem install system_timer
    Остальное - нужно читать src, наверно, защита от srcipt kiddies.
     

  • 1.9, Ivan1986 (?), 13:16, 07/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Мдя, выставлять мемкеш на внешний интерфейс...
    Он же по умолчанию привязывается к 127.0.0.1
    а если на нескольких серверах, то конечно фаер или внутренняя сетка.
     
  • 1.10, daevy (??), 13:54, 07/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    еще пример: в редхате и центосе при установке mysql дефолтная конфигурация запускает его на 0.0.0.0  :))
     
     
  • 2.11, Аноним (-), 15:16, 07/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не знаю, как в редхате, а вот в центосе по дефолту снаружи открыт только 22-й порт... так что всё не так уж плохо
     

  • 1.14, Антон (??), 15:42, 07/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да, кстати. Приходилось видеть связки nginx + кэширование в memcached, в которых без префикса вначале проверяется ключ uri в кэше, если он есть выводится из memcached, нет - идет обращение к бэкенду. Ведь такие системы тоже можно атаковать похожим способом, подставляем вместо URL включение дебаг режима и узнаем ключи для пользовательских сессий. Насколько мне память не изменяет, nginx передает uri как есть, не экранируя.

     
  • 1.20, Аноним (-), 08:55, 08/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Это не новость. Давно блочим :)
     
     
  • 2.21, Аноним (-), 09:16, 08/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Это не новость. Давно блочим :)

    Новость в том, что оказывается кто-то не блокирует.

     
     
  • 3.22, klalafuda (?), 21:18, 08/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Новость в том, что оказывается кто-то не блокирует.

    Я может кого-то сильно удивлю, но есть масса людей, которые используют прости хоссподи виндовс. И ничего, живут как-то. С грехом пополам.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру