The OpenNET Project / Index page

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

15.10.2014 23:51  Критическая уязвимость в системе управления web-контентом Drupal

В выпуске системе управления web-контентом Drupal 7.32 устранена критическая уязвимость (CVE-2014-3704), позволяющая осуществить подстановку SQL-кода. Уязвимости присвоен наивысший уровень опасности (Highly critical), сигнализирующий на возможность осуществления удалённой атаки, способной привести к получению доступа к системе.

Уязвимость вызвана ошибкой в реализации метода "prepared statement" в интерфейсе абстрактного доступа к БД и может быть эксплуатирована анонимным посетителем. Отправив специально оформленный запрос к сайту, реализованному на базе Drupal, атакующий может выполнить произвольный SQL-запрос на сервере, манипулируя которым можно добиться выполнения PHP-кода или получения доступа к серверу. Сообщается, что уже подготовлен рабочий прототип эксплоита, но он пока не опубликован в открытом доступе. В тестовом сценарии фигурирует передача значения "1 ;INSERT INTO {test} SET name = 'test12345678'; -- ".

Уязвимость была выявлена компанией Sektion Eins, нанятой одним из пользователей Drupal для аудита исходных текстов данной CMS. Проблеме подвержены все выпуски Drupal 7, при этом атаку достаточно сложно отследить. Всем пользователям Drupal рекомендовано немедленно обновить свои системы. Проблема проявляется в том числе и при закрытии сайта через перевод в режим сопровождения (Maintenance mode). Без обновления Drupal или применения патча избежать атаки можно только заблокировав доступ ко всем скриптам, например, перенаправив все запросы на статическую web-страницу.

Динамика обнаружения уязвимостей в Drumap

Дополнение: информация о технике атаки уже воссоздана некоторыми исследователями и опубликована в сети (эксплоит 1, эксплоит 2). Пример запроса для тестирования своих систем на наличие уязвимости:
"?name[0%20;update+users+set+name%3d'owned'+,+pass+%3d+'$S$test'+where+uid+%3d+'1';;#%20%20]=test3&name[0]=test&pass=shit2&test2=test&form_build_id=&form_id=user_login_block&op=Log+in"

  1. Главная ссылка к новости (https://www.drupal.org/drupal-...)
  2. OpenNews: Drupal.org подвергся взлому, база пользователей скомпрометирована
  3. OpenNews: Релиз системы управления web-контентом Drupal 7
  4. OpenNews: Белый Дом открыл код нескольких модулей для CMS Drupal
  5. OpenNews: Сайт Лондонского правительства переведен на свободную CMS Drupal
  6. OpenNews: В Bugzilla устранена опасная уязвимость, открывшая новый вид атак на web-приложения
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: drupal
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 00:20, 16/10/2014 [ответить] [показать ветку] [···]    [к модератору]
  • +5 +/
    > Drupal

    Я ни разу не удивлён. Но думал, что Джумлу вряд ли переплюнут.

     
     
  • 2.12, Джон (?), 04:54, 16/10/2014 [^] [ответить]    [к модератору]
  • +1 +/
    Есть сервер с голой джумлой. Взламываешь? 100 баксов твои. Надо больше говори, не вопрос.
     
     
  • 3.13, Аноним (-), 05:56, 16/10/2014 [^] [ответить]    [к модератору]
  • +1 +/
    > Надо больше говори, не вопрос.

    Ну это смотря насколько больше :). Если вы 31337 баксов как гугля предложите - у вас появится несколько чуваков, выискивающих баги fulltime, вероятно :)

     
  • 3.23, XakRu (ok), 10:46, 16/10/2014 [^] [ответить]    [к модератору]
  • +3 +/
    Если вас еще не взломали - это не значит, что ваша система неуязвима. Возможно вы просто нам не интересны!
     
  • 3.25, Michael Shigorin (ok), 12:20, 16/10/2014 [^] [ответить]    [к модератору]
  • +12 +/
    > Есть сервер с голой джумлой. Взламываешь? 100 баксов твои.
    > Надо больше говори, не вопрос.

    А теперь объясняю, как выглядит в жизни.

    Некую CMS засунули на хостинг, активно залатывают, сайт наполняют контентом.  Проходит год-два-три.  Изначальные студент/фрилансер/студия вроде как уже и не нужны, всё устоялось, проблем особых нет.  Латание плавно или скачком прекращается, продолжается наполнение.  Проходит ещё какое-то время, за которое поддерживаемая ветка закрывается, переезд на следующую требует как минимум обращения к с/ф/с, подчас нетривиальной мороки (т.е. времени и денег), изредка существенной переработки части функциональности.

    Так вот важно не то, сколько именно сейчас в условной "голой жумле", которая нафиг никому не упёрлась сама по себе, эксплуатируемых/известных уязвимостей.  Важно то, сколько их вылезет к тем нескольким годам плюс какому-то времени, и сколько будет заткнуто за эти первые годы.

    Я доступно излагаю?

     
     
  • 4.26, Аноним (-), 13:06, 16/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    Прям за меня сказал.
     
  • 4.29, Vov (?), 14:50, 16/10/2014 [^] [ответить]     [к модератору]  
  • +/
    А имеется ли разница между 100 потенциальными уязвимостями Жумлы или одной найд... весь текст скрыт [показать]
     
     
  • 5.32, Сергей (??), 15:03, 16/10/2014 [^] [ответить]    [к модератору]  
  • +2 +/
    Разница в том, что 50 из тех 100 могут быть известны только тем, кто ими пользуется.
     
  • 5.34, YetAnotherOnanym (ok), 15:25, 16/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    Если она одна и закрыта, потенциальные злоумышленники переключатся на ПО, в котором их находят пачками.
     
  • 5.44, Michael Shigorin (ok), 14:23, 17/10/2014 [^] [ответить]     [к модератору]  
  • +/
    Видите ли, практика показывает, что на условную сотню найденных уязвимостей жумл... весь текст скрыт [показать]
     
  • 3.43, yutoks (?), 11:05, 17/10/2014 [^] [ответить]    [к модератору]  
  • +/
    тут от мозга админа больше зависит, чем от скриптов.
    как рассчитал безопасность системы.
     
  • 1.2, all_glory_to_the_hypnotoad (ok), 00:23, 16/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +2 +/
    > Уязвимость вызвана ошибкой в реалиpации интерфейса абстрактного доступа к БД

    вот, значит, как теперь называется склеивание строчек в sql запрос на коленке в пыхе

     
     
  • 2.8, Нимо Ан (?), 00:48, 16/10/2014 [^] [ответить]    [к модератору]  
  • –1 +/
    Давно пора запретить передачу SQL от клиента (middleware) к серверу (СУБД) и реализовать унифицированный интерфейс к хранимым процедурам, а внутри уже пусть городят как хотят.
     
     
  • 3.10, vitalif (ok), 01:56, 16/10/2014 [^] [ответить]    [к модератору]  
  • +3 +/
    чур тебя
     
  • 3.14, Аноним (-), 05:57, 16/10/2014 [^] [ответить]    [к модератору]  
  • +3 +/
    > Давно пора запретить SQL

    //fixed. Bobby Tables meets John The Scripter.

     
  • 3.16, Аноним (16), 09:35, 16/10/2014 [^] [ответить]    [к модератору]  
  • +2 +/
    Мдя, как всё тяжко то у людей...
     
     
  • 4.20, Обычный аноним (?), 09:53, 16/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    > Мдя, как всё тяжко то у людей...

    Так ты марсианин???

     
     
  • 5.22, Аноним (16), 10:02, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/
    >> Мдя, как всё тяжко то у людей...
    > Так ты марсианин???

    А ты комменты читаешь по одному, не обращая внимания на иерархию? :)

     
     
  • 6.28, Обычный аноним (?), 14:03, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/

    > А ты комменты читаешь по одному, не обращая внимания на иерархию? :)

    Промах. Руки трясутся :))

     
  • 1.4, manster (ok), 00:27, 16/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ...сколько еще таких сюрпризов на просторах любителей экономить на prepare-параметрах...
    Возможно это от большой любви ко всякого рода ORM...

    Практически любой проект, не использующий prepare-параметры, но активно работающий с БД, имеет потенциальную возможность предоставить брешь.

     
     
  • 2.5, uldus (ok), 00:35, 16/10/2014 [^] [ответить]     [к модератору]  
  • +/
    Вообще-то эта уязвимость как раз в коде обработки prepare-параметров - Drupal... весь текст скрыт [показать]
     
     
  • 3.9, manster (ok), 01:16, 16/10/2014 [^] [ответить]     [к модератору]  
  • +1 +/
    gt оверквотинг удален Возможно, это предположение только Надо смотреть код С... весь текст скрыт [показать]
     
     
  • 4.11, vitalif (ok), 01:58, 16/10/2014 [^] [ответить]    [к модератору]  
  • +3 +/
    Да у них просто видимо этот prepare эмулируется их же кодом.
     
     
  • 5.18, Аноним (16), 09:50, 16/10/2014 [^] [ответить]     [к модератору]  
  • +/
    Там у них для облегчения есть функция expandArguments которая перед pdo-ным pr... весь текст скрыт [показать]
     
  • 3.17, Аноним (16), 09:39, 16/10/2014 [^] [ответить]     [к модератору]  
  • +/
    gt оверквотинг удален А то что при prepare запроса, prepared запрос на серве... весь текст скрыт [показать]
     
  • 3.24, Аноним (-), 11:03, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/
    prepared statements так не работает, это что-то похожее по api на него. Как уже некоторые заметили, некоторые ущербные биндинги эмулируют софтварно, например почти все к mysql
     
  • 3.36, angra (ok), 17:20, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/
    Можно еще сказать, что данная ошибка есть следствие дизайна PHP, в котором нет различия между обычными и ассоциативными массивами aka хешами.
     
     
  • 4.38, manster (ok), 18:16, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/
    Да есть такое. Типизированные массивы и списки тогда уж. Само по себе числовые индексы или символьные не большое зло - частный случай индексов. Но это плата за универсальность. Решили сэкономить на списках и кортэжах. Но ошибка не совсем с этим связана, "палёный код", впрочем от друпала не удивительно может быть.
     
     
  • 5.40, all_glory_to_the_hypnotoad (ok), 20:13, 16/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    > Cамо по себе числовые индексы или символьные не большое зло - частный случай индексов.

    ни что ни у чего тут не частный случай.

    > Но это плата за универсальность.

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

     
  • 2.6, demimurych (ok), 00:38, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/
    Вы бы в патч посмотрели
    или хотя бы новость внимательно прочли, чтобы понять в чем проблема и как она появилась.
     
     
  • 3.19, Аноним (16), 09:51, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/
    > Вы бы в патч посмотрели
    > или хотя бы новость внимательно прочли, чтобы понять в чем проблема и
    > как она появилась.

    http://www.opennet.ru/openforum/vsluhforumID3/99431.html#18

     
  • 1.7, Аноним (-), 00:42, 16/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Интересно whitehouse.gov и london.gov.uk уже пропатчили? Они когда-то громко кричали о переходе на Drupal Ж-)
     
  • 1.15, йцу (?), 08:52, 16/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Загуглите "prepared statement in" - удивитесь количеству одинаковых вопросов на stackoverflow (речь не только о PHP). Есть вообще БД API, которое поддерживает из коробки биндинг коллекций к одному плейсхолдеру? А ведь достаточно часто возникающий кейс.
     
     
  • 2.21, Аноним (16), 09:56, 16/10/2014 [^] [ответить]     [к модератору]  
  • –3 +/
    Оно не нужно, не дело СУБД разгребать коллекции, и реализация такого алгоритма д... весь текст скрыт [показать]
     
     
  • 3.27, йцу (?), 13:45, 16/10/2014 [^] [ответить]    [к модератору]  
  • +/
    Ну алгоритм-то зачастую один и тот же - взять список чисел/строк и впихнуть в IN выражение.

    Не дело СУБД - ok, но почему в тех же PDO, JDBC и т.п. API не добавить соответствующий метод? В DQL (doctrine) и HQL (hybernate) к примеру такая возможность есть (я понимаю, что это несколько более высокоуровневые штуки, но не вижу причину чтобы не реализовать это уровнем ниже - ну ведь нужная же вещь).

     
     
  • 4.31, Аноним (16), 15:01, 16/10/2014 [^] [ответить]     [к модератору]  
  • +/
    вы же сами ответили - разный уровень Если вы пришете в запросе in param , т... весь текст скрыт [показать]
     
     
  • 5.33, Аноним (16), 15:05, 16/10/2014 [^] [ответить]     [к модератору]  
  • +/
    хм почему то думал что in param это из mysql -кого синтаксиса, по сути в др... весь текст скрыт [показать]
     
  • 2.30, Zontus (?), 14:51, 16/10/2014 [^] [ответить]    [к модератору]  
  • –1 +/
    PERL DBI
     
     
  • 3.37, Прохожий (??), 17:40, 16/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    Perl-Pg и нормальная логика SQL с хранимыми процедурами, триггерами и т.д. Неубиваемая штука. Только все больше обрастает функционалом и обрастает.
     
  • 1.45, chuk (ok), 20:00, 17/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Вот дурачье! На кой вообще было изобретать 7-ю версию, которое ничего общего не имеет с 6-й?
    6-я - лучшая из Друпалов!
     

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


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