Раскрытие директории в модуле сессий, часть 2
Что ж… модуль сессий в ЛС оказался слегка дырявым всего-навсего в пределах одного метода. Первая часть по раскрытию путей находится здесь, все тесты и описание будут приводится на основе исправленного модуля сессий из предыдущего топика.
В данном топике будет рассмотрено и исправлено 2 способа раскрытия путей на сайте под управлением ливстрит последней доступной версии (1.0.2).
Если на сервере в php.ini опция session.use_only_cookies установлена в 0, то злоумышленник может выключить куки в браузере и тогда появляется возможность установки сессии через метод GET, а передача этого параметра как массива:
приведет к ошибке:
Если отредактировать имя куки с названием сессии (по-умолчанию в ЛС это обычное PHPSESSID), добавив к имени этой печеньки скобки (PHPSESSID[], можно как с указанием ключа так и без), то при конвертации такой записи php автоматически превратит ёё в массив, внутри которого — нужный айдишник сессии.
В php в session.name записано имя куки, которая хранит идентификатор сессии, но php'ный массив $_COOKIE автоматически конвертирует куки с именем "some_name[some_key]" в "$_COOKIE ['some_name']['some_key']", поэтому когда обработчик сессии пытается прочитать куку чтобы извлечь айдишник сессии — он падает в обморок т.к. вместо ожидаемой строки получает массив при вызове метода:
и генерирует ошибку конвертации:
Подобная ошибка уже была когда-то найдена для ключа авторизации пользователя (кука «key») и исправлена, но про сессию, видимо, никто не вспомнил.
Для нестандартного режима сессий я не делал исправления (по-умолчанию отключен и не рекомендован к использованию).
Все вышеописанные исправления безопасности в файле сессий для лайвстрита 1.0.2 + правки из предыдущего топика можно скачать здесь.
Это кросспост из гида по livestreet cms. Хотите быть в курсе последних новостей о безопасности ЛС? Подписывайтесь на соответствующий блог.
P.S. Максим нещадно минусует мои топики о проблемах с безопасностью, аргументируя это тем, что вначале нужно было сообщить разработчикам и что ему не нравится что я рекламирую свой сайт. Хочу заметить, что в топике я сразу даю заплатку. Поэтому это мой последний пост о проблемах с безопасностью на данном сайте. Больше сообщать здесь о таких проблемах я не буду, если ort это не угодно. Хотите быть в курсе событий? Вы знаете где можно об этом почитать.
В данном топике будет рассмотрено и исправлено 2 способа раскрытия путей на сайте под управлением ливстрит последней доступной версии (1.0.2).
- Уровень опасности: средний
- Тип: раскрытие имени пользователя (аккаунта) на сервере
- Версии движка, которые подвержены данной опасности: все версии без исключения
Метод № 1: отключение кук в браузере
Описание
Если на сервере в php.ini опция session.use_only_cookies установлена в 0, то злоумышленник может выключить куки в браузере и тогда появляется возможность установки сессии через метод GET, а передача этого параметра как массива:
http://site.com/?PHPSESSID[]=any_value
приведет к ошибке:
Notice: Array to string conversion in /home/webmaster/www/site.com/www/engine/modules/session/Session.class.php on line 88 Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/webmaster/www/site.com/www/engine/modules/session/Session.class.php:92) in /home/webmaster/www/site.com/www/engine/modules/session/Session.class.php on line 92
Решение
Для устранения данной возможности нужно после 78 строки в /engine/modules/session/Session.class.php вставить код:if (@ini_get ('session.use_only_cookies') === "0" and getRequest (Config::Get ('sys.session.name')) and is_array (getRequest (Config::Get ('sys.session.name')))) { //die ('Have you done your homework?'); session_name ($this -> GenerateId ()); // block manual session setup replacing it with new one $this -> Message_AddError ('Your session name is broken (set as array by request)', 'Error'); }
Метод № 2: редактирование кук в браузере
Описание
Если отредактировать имя куки с названием сессии (по-умолчанию в ЛС это обычное PHPSESSID), добавив к имени этой печеньки скобки (PHPSESSID[], можно как с указанием ключа так и без), то при конвертации такой записи php автоматически превратит ёё в массив, внутри которого — нужный айдишник сессии.
Более подробно:
В php в session.name записано имя куки, которая хранит идентификатор сессии, но php'ный массив $_COOKIE автоматически конвертирует куки с именем "some_name[some_key]" в "$_COOKIE ['some_name']['some_key']", поэтому когда обработчик сессии пытается прочитать куку чтобы извлечь айдишник сессии — он падает в обморок т.к. вместо ожидаемой строки получает массив при вызове метода:
session_start ();
и генерирует ошибку конвертации:
Notice: Array to string conversion in /home/webmaster/www/site.com/www/engine/modules/session/Session.class.php on line 99 Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/webmaster/www/site.com/www/engine/modules/session/Session.class.php:99) in /home/webmaster/www/site.com/www/engine/modules/session/Session.class.php on line 99
Решение
Для устранения данной возможности нужно после 78 строки в /engine/modules/session/Session.class.php вставить код:if (isset ($_COOKIE [Config::Get ('sys.session.name')]) and is_array ($_COOKIE [Config::Get ('sys.session.name')])) { //die ('Have you done your homework?'); session_name ($this -> GenerateId ()); // block manual session setup replacing it with new one $this -> Message_AddError ('Your session name is broken (set as array in cookies)', 'Error'); }
Лирическое отступление:
Подобная ошибка уже была когда-то найдена для ключа авторизации пользователя (кука «key») и исправлена, но про сессию, видимо, никто не вспомнил.
Для нестандартного режима сессий я не делал исправления (по-умолчанию отключен и не рекомендован к использованию).
Резюме
Все вышеописанные исправления безопасности в файле сессий для лайвстрита 1.0.2 + правки из предыдущего топика можно скачать здесь.
Это кросспост из гида по livestreet cms. Хотите быть в курсе последних новостей о безопасности ЛС? Подписывайтесь на соответствующий блог.
P.S. Максим нещадно минусует мои топики о проблемах с безопасностью, аргументируя это тем, что вначале нужно было сообщить разработчикам и что ему не нравится что я рекламирую свой сайт. Хочу заметить, что в топике я сразу даю заплатку. Поэтому это мой последний пост о проблемах с безопасностью на данном сайте. Больше сообщать здесь о таких проблемах я не буду, если ort это не угодно. Хотите быть в курсе событий? Вы знаете где можно об этом почитать.
Если для вас актуальна тема безопасности, то рекомендуем обратить внимание на оборудование для систем безопасности. Здесь представлен довольное широкий спектр различных security систем.
17 комментариев
заплатка есть в топике.
я не согласен: половина пользователей тогда не позакрывает баги у себя на сайтах до выхода оф. версии. Я в «публичном», как вы выразились, топике сразу даю решение, а не бросаю на произвол судьбы.
Почему? О каком именно вреде идет речь?
Как показывают мои наблюдения, человек всегда верит, что-бы не случилось — это случится не с ним.
Ну 10 человек закроет у себя уязвимость после публикации на оффсайте движка. Уверен, что большинство недохакеров врядли созреет мозгами пасти репозиторий на гитхабе и уж тем более анализировать его. А вот когда тебе дают эксплоит на блюдечке с голубой каемочкой, почему бы не поэксперементировать, благо список сайтов на LS тут в соседнем топике.
Так что общемировая практика по публикации сообщений об уязвимостях после выпуска корректирующего релиза не просто так возникла. Оперативность выпуска релиза и своевременного информирования пользователя об уязвимостях — это уже на совести мейнтенера.
А что касается обладателей своих серваков, так ведь у них вообще все по другому будет.
Тут скорее нужно чтобы совпало несколько вещей, например раскрытие дирректории и скажем неправильный .htaccess который позволял бы листать в браузере ту же uploads.
А PSNet просто акцентирует внимание, на этом недочете, чтобы его не забыли включить в следующей версии, ничего плохого тут нет.
И мы вроде не обсуждаем конкретно данную уязвимость, а говорим о подходе в принципе. Сначала фикс, потом препарация уязвимости. Иначе это выглядит как простое тщеславие.
Вот из-за таких вещей у ЛС никогда и не будет вменяемого сообщества. Что печально.
В этом случае не поступает фиксов в виде коммитов в саму систему, это лишь поверхностная, но показуха. Как можно заметить Максиму пришлось оформить коммит самому github.com/livestreet/livestreet/commits/master
Ни кто о безопасности как таковой не заботиться, исправил для себя, сообщил, что будет дальше пусть сами разбираются. Меня такой подход не устраивает.