С этого года решили возобновить публикацию информации об обнаруженных в ходе исследований и тестов на проникновение уязвимостях.
http://www.securitylab.ru/lab/
В 2006 году, в связи с рядом причин, было решено переложить бремя публикации обработки уязвимостей на вендора и приостановить публикацию ранее найденных проблем (http://www.ptsecurity.ru/advisory.asp). Однако многие заказчики просят содействовать в устранении уязвимостей в программах третьих производителей, в связи с чем, пришлось возобновить процесс.
Наиболее интересной проблемой из текущих (по моему мнению) является набор уязвимостей в VMWare, которые позволяют "выйти" из гостевой операционной системы на узловую. Причем сразу в kernel.
Персонально я в свое время побаловался с разными методами устранения уязвимостей в продуктах третьих производителей, от экстремизма Full-Disclosure до продажи уязвимостей на «белом» рынке, например iDefense (http://labs.idefense.com/vcp/). Некоторые соображения по этим вопросам доступны здесь:
http://www.securitylab.ru/analytics/241826.php
вторник, 10 марта 2009 г.
среда, 4 марта 2009 г.
Рускрипто 2009. Интернет и информационная безопасность
Важным отличием Рускрипто от других ИБ-мероприятий является тот факт, что конференция делается специалистами для специалистов. В меньшей степени это маркетинговое мероприятие, в большей научная, академическая конференция.
Это делает конференцию уникальной площадкой для общения экспертов в раличных областях информационной безопасности.
Секция «Интернет и информационная безопасность» проводится в рамках конференции Рускрипто второй раз. В 2008 году в рамках секции было сделано восемь докладов совершенно разной направленности, от организации процесса обеспечения информационной безопасности Интернет-служб в Яндексе (Адрей Бабий, Яндекс), до методов поиска уязвимостей в антивирусном ПО (Евгений Легеров, GLEG Ltd.). Большой интерес вызвали работы, в которых затрагиваются перспективные вопросы информационной безопасности, такие как безопасность протокола IPv6 (Андрей Абрамов, Positive Technologies) и моделирование DDOS-атак (И. Котенко, А. Уланов, СПИИРАН).
В этом году планируется выделить подсекцию безопасности Web-приложений, в рамках которой прозвучат доклады Сергея Рыжикова (1-С Бирикс), Дмитрия Васильева (АИСТ), Андрея Бабия и Александра Матросова (Яндекс). Каждый из них поделится своими наработками в вопросах обеспечения безопасности Web-приложений, причем многие темы пересекаются с вопросами, поднятыми в прошлом году. Так, например, по данным службы техподдержки CMS Netcat, наиболее распространенной причиной взлома сайтов является заражение вирусом компьютера, с которого осуществляется управление системой.
Как бы в ответ на этот тезис на конференции прозвучат доклады Александра Матросова «Вирус подмены страниц: изменение поведения веб-сервисов без ведома их создателей» и Сергея Гордейчика «Positive WebSpider – экспресс тест на безопасность».
Кроме того, на секции будут представлены доклады Ильи Сачкова (Group-IB) о тенденциях борьбы с кибепреступностью в России и Александра Полякова (Digital Security) о последних тенденциях безопасности СУБД Oracle. Но этим список тем конференции не ограничивается. Получить свежую программу можно на сайте ассоциации Рускрипто (http://ruscrypto.ru/conference/program/).
вторник, 24 февраля 2009 г.
Утилитка для (против) MS08-065, MS08-067 и MS09-001
Опубликовали сетевую утилиту для проверки наличия исправлений, описанных в бюллетенях безопасности MS08-065, MS08-067 и MS09-001 без использования административных привилегий (методом pentest).
Отзыв по предыдущему релизу был достаточно позитивным, решили обновить.
Подробная информация:
http://www.securitylab.ru/news/368759.php
Ссылка для загрузки:
http://www.ptsecurity.ru/download/pt-check-09-001-ru.zip
Сейчас думаем над возможностью выпуска утилиты таким же образом обнаруживающей Conficker
Отзыв по предыдущему релизу был достаточно позитивным, решили обновить.
Подробная информация:
http://www.securitylab.ru/news/368759.php
Ссылка для загрузки:
http://www.ptsecurity.ru/download/pt-check-09-001-ru.zip
Сейчас думаем над возможностью выпуска утилиты таким же образом обнаруживающей Conficker
четверг, 19 февраля 2009 г.
Сложно ли взломать сайт?
Как показывает наша статистика - квалифицированный человек сделает это с вероятностью 0,8...
Именно такова вероятность обнаружения уязвимостей высокой степени риска в ходе наших работ. Даже самому страшно.
Отрелизили статистику безопасности Web-приложений за 2008 год.
Это уже третий релиз:
2008
2007
2006
В этом году в качестве исходных данных использовались результаты анализа 59 Web-приложений различными жестокими методами от fuzzing до dynamic source code analysis и более чем 10000 сайтов, расположенных на Хостинг-Центре РБК, которому мы (и MaxPatrol) помогаем оказывать услугу "Проверка Безопасности Сайта".
В первый раз в статистику вошли данные по обнаруженным последствиям "взлома", т.е. по тем сайтам, на которых MaxPatrol обнаружил вредоносный код, php-shell и т.п.
В этом году обнаружилась еще одна интересная аномалия. Это нереально большое количество SQLi (обнаружено в 68% всех сайтов при детальном анализе). Просто прорыв какой-то...
Вот такие жестокие цифры...
Именно такова вероятность обнаружения уязвимостей высокой степени риска в ходе наших работ. Даже самому страшно.
Отрелизили статистику безопасности Web-приложений за 2008 год.
Это уже третий релиз:
2008
2007
2006
В этом году в качестве исходных данных использовались результаты анализа 59 Web-приложений различными жестокими методами от fuzzing до dynamic source code analysis и более чем 10000 сайтов, расположенных на Хостинг-Центре РБК, которому мы (и MaxPatrol) помогаем оказывать услугу "Проверка Безопасности Сайта".
В первый раз в статистику вошли данные по обнаруженным последствиям "взлома", т.е. по тем сайтам, на которых MaxPatrol обнаружил вредоносный код, php-shell и т.п.
В этом году обнаружилась еще одна интересная аномалия. Это нереально большое количество SQLi (обнаружено в 68% всех сайтов при детальном анализе). Просто прорыв какой-то...
Вот такие жестокие цифры...
вторник, 27 января 2009 г.
Резвые пользователи WiFi (дополнение)
Вспомнил WIDS, вспомнил про старенькую публикацию, отчасти связанную с предыдущей заметкой.
Атаки на системы обнаружения беспроводных атак
http://www.securitylab.ru/analytics/275562.php
Системы обнаружения беспроводных атак (Wireless Intrusion Detection System, WIDS) пока не настолько популярны, как их проводные аналоги, но современные тенденции позволяют предсказывать рост числа их внедрений. Положительным фактором является интеграция подобных программ с активным сетевым оборудованием и осознание руководством рисков, связанных с несанкционированным использованием беспроводных устройств. Последнее приводит к увеличению числа инсталляций WIDS даже в сетях, где беспроводные сети не используются. В связи с этим у специалистов в области безопасности возникает необходимость оценить не только качественные характеристики того или иного продукта, но и прогнозировать возможное негативное влияние от его внедрения на безопасность корпоративной сети.
Атаки на системы обнаружения беспроводных атак
http://www.securitylab.ru/analytics/275562.php
Системы обнаружения беспроводных атак (Wireless Intrusion Detection System, WIDS) пока не настолько популярны, как их проводные аналоги, но современные тенденции позволяют предсказывать рост числа их внедрений. Положительным фактором является интеграция подобных программ с активным сетевым оборудованием и осознание руководством рисков, связанных с несанкционированным использованием беспроводных устройств. Последнее приводит к увеличению числа инсталляций WIDS даже в сетях, где беспроводные сети не используются. В связи с этим у специалистов в области безопасности возникает необходимость оценить не только качественные характеристики того или иного продукта, но и прогнозировать возможное негативное влияние от его внедрения на безопасность корпоративной сети.
В данной статье описываются результаты исследований систем обнаружения беспроводных атак с точки зрения специалиста в области безопасности приложений. Обнаруженные ошибки проектирования в статье не обсуждаются, поскольку их устранение требует от производителя существенных трудозатрат.
Резвые пользователи WiFi
Недавно в форуме всплыла ситуация, которая периодически встречается в ходе работ по оценке защищенности - "резвые" пользователи корпоративных сетей используют окружающие точки доступа для выхода в Internet "в обход" корпоративных средств защиты.
Т.е. гонят свой (а подчас и корпоративный) трафик "по воздуху" без всяких там шифрований, МСЭ, антивирусов и других условностей. А что они при этом могут "слить" из сети, прикинувшись "инсайдером", так просто страшно становится. Я уж не говорю про ситуации, когда об таких пользователях узнает "аутсайдер"...
Цитирую:
1 2
Доброго времени суток. Руководством компании поставлена задача выявить Wi-fi подключение сотрудника(ов) компании к точке доступа которая ориентировочно находится в соседнем здании. В крайнем случае просто закрыть этот канал утечки. Глушить весь диапазон не предлагать, поставлено условие: мобильники должны работать.
ЗЫ. Уважаемые коллеги, заранее прошу не уходить от темы типа: "все равно есть кпк... коммуникаторы..." и все такое. Конкретно про wi-fi!
Как решить проблему?
Мой ответ:
offtopic
Простой вариант - ноутбук с Linux с достаточно мощной антенной, лучше направленной, например http://www.antennas.spb.ru/pdf/2_rus.pdf.
Для выявления и "подавления" своих нерадивых сотрудников используется комплект программ aircrack-ng.
С помощью airodump-ng составляется список "нерадивых" пользователей, цепляющихся к злобной точке доступа. Туда-же можно добавлять и MAC-адреса, полученные в процессе инвентаризации сети.
А с помощью aireplay-ng рвутся коннекты своих клиентов к злобной точке доступа.
Вот и все. Можно конечно все это автоматизировать с помощью пары скриптов.
Более грубый вариант - просто слать broadcast deauthentication для точки доступа, но это имхо - перебор. Не подгадаешь с зоной покрытия - и будешь посторонних людей от сети отключать.
Можно купить коммерческую систему WIDS, например Airmagnet, или задействовать фичи Aironet. В них присутствуют возможности по "отключению" нелегитимных соединений. Но задачу инвентаризации (т.е. составления списка "своих" MAC-адресов) они не отменяют.
ЗЫ. Есть хороша книжка, касающаяся этих вопросов:
http://www.securitylab.ru/news/306357.php
Здесь хорошо всплавает основна систем обнаружения беспроводных атак (WIDS), а именно - аномальный подход. Ограниченные канальным уровнем, WIDS, как правило, содержит небольшое количество сигнатур. Настоящая работа таких систем начинается только после правильной настройки - создания черных и белых списков точек доступа и клиентов, привязка источников сигнала к карте, указания "правильных" протоколов и т.д. А в основе этого - инвентаризация, как базис любых процессов ИБ.
Т.е. гонят свой (а подчас и корпоративный) трафик "по воздуху" без всяких там шифрований, МСЭ, антивирусов и других условностей. А что они при этом могут "слить" из сети, прикинувшись "инсайдером", так просто страшно становится. Я уж не говорю про ситуации, когда об таких пользователях узнает "аутсайдер"...
Цитирую:
1 2
Доброго времени суток. Руководством компании поставлена задача выявить Wi-fi подключение сотрудника(ов) компании к точке доступа которая ориентировочно находится в соседнем здании. В крайнем случае просто закрыть этот канал утечки. Глушить весь диапазон не предлагать, поставлено условие: мобильники должны работать.
ЗЫ. Уважаемые коллеги, заранее прошу не уходить от темы типа: "все равно есть кпк... коммуникаторы..." и все такое. Конкретно про wi-fi!
Как решить проблему?
Мой ответ:
offtopic
Простой вариант - ноутбук с Linux с достаточно мощной антенной, лучше направленной, например http://www.antennas.spb.ru/pdf/2_rus.pdf.
Для выявления и "подавления" своих нерадивых сотрудников используется комплект программ aircrack-ng.
С помощью airodump-ng составляется список "нерадивых" пользователей, цепляющихся к злобной точке доступа. Туда-же можно добавлять и MAC-адреса, полученные в процессе инвентаризации сети.
А с помощью aireplay-ng рвутся коннекты своих клиентов к злобной точке доступа.
Вот и все. Можно конечно все это автоматизировать с помощью пары скриптов.
Более грубый вариант - просто слать broadcast deauthentication для точки доступа, но это имхо - перебор. Не подгадаешь с зоной покрытия - и будешь посторонних людей от сети отключать.
Можно купить коммерческую систему WIDS, например Airmagnet, или задействовать фичи Aironet. В них присутствуют возможности по "отключению" нелегитимных соединений. Но задачу инвентаризации (т.е. составления списка "своих" MAC-адресов) они не отменяют.
ЗЫ. Есть хороша книжка, касающаяся этих вопросов:
http://www.securitylab.ru/news/306357.php
Здесь хорошо всплавает основна систем обнаружения беспроводных атак (WIDS), а именно - аномальный подход. Ограниченные канальным уровнем, WIDS, как правило, содержит небольшое количество сигнатур. Настоящая работа таких систем начинается только после правильной настройки - создания черных и белых списков точек доступа и клиентов, привязка источников сигнала к карте, указания "правильных" протоколов и т.д. А в основе этого - инвентаризация, как базис любых процессов ИБ.
понедельник, 26 января 2009 г.
Риски, риски, риски...
Недавно, в ходе работ по анализу защищенности наткнулись на уязвимость Web-интерфейса управления одним UTM-устройством. Достаточно типичное сочетание CSRF и XSS примечательно тем, что через Web-интерфейс позволяет получить доступ к коммандной строке устройства и интерактивно "рулить" системой в браузере администратора. Но не суть, уязвимость типичная.
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php
Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:
(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C) = 8.1
Если же Web-сервер работает с SQL-server с чрезмерными привилегиями, например sa, то эта же уязвимость будет гораздо более опасной:
(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5
Если перевести эти оценки к "светофорной" модели или 5 уровням, принятых в PCI DSS (Urgent, Critical, High, Medium, Low), то получим:
1. Средний (2) и High (3)
2. Средний (2) и Critical (4)
3. Высокий (3) и Urgent (>4).
Т.е. степень риска одной и той же уязвимости может серьезно меняться в зависимости от конкретной системы и её настроек.
Что же касается XSS с которого начиналась заметка, то ее вектор будет
(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9
Т.е. с точки зрения PCI DSS (а именно эту модель сейчас "модно" использовать) степень риска данной проблемы можно обозначить как High или даже Critical, а не Low. В любом случае, аудит провален :)).
ЗЫ. Хотя я могу понять вендора, ведь если безопасность не заложена в приложение изначально, то, цитирую: "hardening the management interface would probably imply a complete redesign of it".
Вот такая она разная, оценка рисков.
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php
Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:
Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:
- зависимость от контекста;
- зависимость от конфигурации системы;
- зависимость от метода определения.
В различных приложениях уязвимости одного типа могут иметь различную степень риска. Так, уязвимость «Подделка HTTP-запроса» может не представлять угрозы для типичного репрезентативного сайта или поисковой машины, и наоборот – классифицироваться как проблема высокой степени риска в Web-интерфейсе электронной почты или платежной системы. В результате утечки информации злоумышленник может получить доступ к журналам работы приложения (низкая или средняя степень риска), а может загрузить резервную копию исходных текстов сайта (высокая степень риска).
Конфигурация конкретной системы также может оказывать серьезное влияние на степень риска. Так, уязвимость «Внедрение операторов SQL» обычно классифицируют как имеющую высокую опасность. Однако в случае если Web-приложение работает с сервером СУБД с ограниченными привилегиями, она может быть отнесена к проблемам средней или низкой степени риска. В другой инсталляции или реализации приложения эта же уязвимость может быть использована для получения доступа к операционной системе с правами суперпользователя, что естественно делает её наиболее критичной.
В зависимости от метода у глубины анализа степень одна и та же уязвимость может быть оценена по-разному. Если взять приведенный выше пример «Внедрения операторов SQL», использование сетевого сканера позволит только констатировать наличие проблемы. Для определения привилегий, доступных потенциальному злоумышленнику требуется либо попытаться использовать ошибку, либо уточнить порядок взаимодействия между Web-приложением и СУБД методом «белого ящика».
Т.е. крайне некорректно относить две различные уязвимости одного типа (например SQL Injection) к одной степени риска без детального анализа.
Привожу пример.
Предположим SQL Injection позволяет получить доступ к СУБД минимально необходимыми для Web-сервера привилегиями, например db_reader. Причем Web-приложение не хранит в СУБД конфиденциальной информации, например паролей.
Тогда вектор и степень риска CVSSv2 будет равены:
(AV:N/AC:L/Au:N/C:P/I:N/A:P/E:H/RL:W/RC:C) = 6.1
(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C) = 8.1
Если же Web-сервер работает с SQL-server с чрезмерными привилегиями, например sa, то эта же уязвимость будет гораздо более опасной:
(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5
Если перевести эти оценки к "светофорной" модели или 5 уровням, принятых в PCI DSS (Urgent, Critical, High, Medium, Low), то получим:
1. Средний (2) и High (3)
2. Средний (2) и Critical (4)
3. Высокий (3) и Urgent (>4).
Т.е. степень риска одной и той же уязвимости может серьезно меняться в зависимости от конкретной системы и её настроек.
Что же касается XSS с которого начиналась заметка, то ее вектор будет
(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9
Т.е. с точки зрения PCI DSS (а именно эту модель сейчас "модно" использовать) степень риска данной проблемы можно обозначить как High или даже Critical, а не Low. В любом случае, аудит провален :)).
ЗЫ. Хотя я могу понять вендора, ведь если безопасность не заложена в приложение изначально, то, цитирую: "hardening the management interface would probably imply a complete redesign of it".
Вот такая она разная, оценка рисков.
Подписаться на:
Сообщения (Atom)