| Издательский дом ООО "Гейм Лэнд" | СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #75, ФЕВРАЛЬ 2007 г. |
горькая правда
АНДРЕЙ КАРОЛИК
Хакер, номер #075, стр. 054
(ANDRUSHA@REAL.XAKEP.RU)
АУДИТ БЕЗОПАСНОСТИ
ЕВГЕНИЙ ДОКУКИН AKA MUSTLIVE В ИТ-ИНДУСТРИИ УЖЕ БОЛЕЕ 14,5 ЛЕТ, - С ТОГО МОМЕНТА, КОГДА ПАПА ПОДАРИЛ ПЕРВЫЙ КОМПЬЮТЕР — ПОИСК 2 :). ВЕБ-ПРОГРАММИРОВАНИЕМ ЗАНИМАЕТСЯ С 2001 ГОДА. ПУБЛИЧНУЮ ДЕЯТЕЛЬНОСТЬ В СФЕРЕ ВЕБ-БЕЗОПАСНОСТИ НАЧАЛ СО СВОЕГО MUSTLIVE SECURITY PACK (HTTP://WEBSECURITY.COM.UA/SECURITY-PACK/). ПОЗЖЕ БЫЛ ОНЛАЙНОВЫЙ ИНТЕРПРЕТАТОР MUSTLIVE PERL PASCAL PROGRAMS INTERPRETER (HTTP://MLFUN.ORG.UA/PPI/). ИЗВЕСТЕН МНОГИМ ПО ПРОЕКТУ WEBSECURITY (HTTP://WEBSECURITY.COM.UA), КОТОРЫЙ ПОСВЯЩЕН ИСКЛЮЧИТЕЛЬНО ВЕБ-БЕЗОПАСНОСТИ. АКТИВНО ЗАНИМАЕТСЯ СОЦИАЛЬНЫМ СЕКЬЮРИТИ-АУДИТОМ — БЕЗВОЗМЕЗДНЫМ ПОИСКОМ ДЫР И ОПОВЕЩЕНИЕМ АДМИНОВ РАЗЛИЧНЫХ ВЕБ-САЙТОВ О НАЙДЕННЫХ УЯЗВИМОСТЯХ
Вопрос:
Аудит безопасности — это дорогое удовольствие?
MustLive:
Дороговизна услуг по аудиту безопасности — это миф. Но это с одной стороны, а с другой — потенциальные заказчики, в основном, пофигисты, в том числе и ребята, работающие в компаниях-гигантах. Любят, чтобы им дыры находили на халяву, реагируют, когда их или их клиентов похакают, и аудиты безопасности особо заказывать не любят. Так что сама отрасль только в начале своего пути (я имею в виду ручной аудит, так как сканеры уже заняли свою нишу). Кто-то начинает пользоваться сканерами безопасности (если он о них, конечно, слышал), которые по-настоящему дороги и порой малоэффективны, что подтверждают сообщения о дырах на сайтах секьюрити-компаний, в том числе производителей этих самых сканеров. Да и в целом аудит безопасности, заказанный у специалиста, будет эффективнее и обойдется значительно дешевле.
Цена зависит от сайта, его размеров и количества сервисов на нем (а также количества типов уязвимостей для тестирования). Чем больше сайт, тем больше сроки тестирования и итоговая цена. Но всегда можно договориться и найти приемлемую цену проверки конкретного ресурса. Для небольших ресурсов ее стоимость может быть в районе нескольких сотен долларов. Другими словами, цена договорная. Причем аудит может быть разовым, а повторно обращаться к нему можно через некоторое время уже по мере необходимости.
Вопрос:
Если бы ты составлял рейтинг угроз извне, то какое место заняли бы SQL Injection и XSS в этом «хит-параде»?
MustLive:
Данные уязвимости были бы одними из первых. Логичнее разделить их «топ» на два: наиболее опасная и наиболее распространенная уязвимость.
В рейтинге наиболее опасных на первое место я поставил бы PHP-инклудинг и удаленное исполнение кода (через тот же PHP file inclusion). Далее идет XSS, в различных его проявлениях. Далее SQL Injection. А после - другие уязвимости, такие как слабые пароли (что нередко встречается), Directory indexing, Full path disclosure и другие.
В рейтинге наиболее распространенных вначале поставил бы Cross-Site Scripting, далее Full path disclosure, PHP-инклудинг, SQL Injection, Directory indexing и другие.
Вопрос:
Какие цели обычно преследуют хакеры, используя SQL Injection или XSS? И что реально они могут получить?
MustLive:
Основная цель хакеров — это получение конфиденциальной информации, паролей и других данных (например, текущей сессии пользователя), в основном с целью наживы. И вне зависимости от того, действует ли хакер в одиночку или же это организованная преступная группа, их цель — это деньги. Конечно, это может быть еще промышленный шпионаж, месть или просто желание навредить, но основной упор все же на получение прибыли.
Захватывают обычно логины и пароли (или сессии) с нужных сайтов, где хранятся деньги или непосредственно учетные данные веб-кошельков, либо информация кредитных карт. Другой вариант — захват важных данных с целью перепродажи или шантажа. Цель нанесения ущерба также возможна, в том числе на заказ. А вот случаев баловства, взлома от нечего делать или для демонстрации своих возможностей все меньше и меньше.
Все чаще встречаются именно спланированные целенаправленные атаки. А также взломы ради получения данных для спам-рассылок или захвата ПК с целью создания спам-бота (опять же, для спам-рассылок).
Вопрос:
Каков процент сайтов, которые можно в любой момент атаковать посредством SQL Injection или XSS?
MustLive:
Точно сказать сложно, как в глобальных масштабах, так и в масштабах ruнета или uанета в частности. Статистику мало кто ведет, проводится очень мало соответствующих исследований. Можно в качестве примера использовать данные компании Acunetix (http://websecurity.com.ua/120/): SQL Injection имеет 9%, а Cross Site Scripting — 27% сайтов. Эти данные компания приводит, исходя из ошибок, найденных их сканером безопасности (и это в основном западные сайты).
Я исхожу из своей практики обнаружения уязвимостей — в ruнете и uанете XSS-уязвимости нахожу практически на каждом сайте, так что потенциально XSS-уязвимости могут быть на 90% сайтах. SQL Injection встречается реже, потенциально до 10% сайтов могут иметь подобные уязвимости. Причем XSS- уязвимости могут быть на сайтах без использования серверных скриптов (http://websecurity.com.ua/127/), и от платформы сайта это не зависит.
Вопрос:
Практически все новостные ленты, посвященные безопасности, кишат предупреждениями о возможности SQL Injection или XSS. Тем не менее, создается впечатление, что их читают только сами модераторы и узкий круг специалистов, которые порой могут не иметь прямого отношения к web. Что это - рядовой пофигизм?
MustLive:
С одной стороны, имеет место равнодушие к проблеме. С другой стороны, причина этому - недостаток знаний. Общественность нужно просвещать на тему безопасности. Люди должны знать, что существуют уязвимости, что они могут нанести вред и что нужно следить за безопасностью своих веб-сайтов, веб-приложений и веб-систем. Нужно регулярно проводить аудит безопасности и следить за новостями о вновь найденных уязвимостях. А также нужно просвещать веб-разработчиков по вопросам безопасности, что я и делаю в своем руководстве — http://websecurity.com.ua/security/. Иначе, действительно, подобные материалы читают лишь специалисты по безопасности, так и те, кому эта тема интересна как смежная с их деятельностью. А также хакеры, которые разрабатывают или используют эти же дыры и эксплойты. Ну, и скрипт-кидисы.
Вопрос:
Как и в какой последовательности ты проверяешь ресурсы на брешь в системе безопасности?
MustLive:
Меня часто спрашивают, какие сканеры я использую... Я не использую никаких. И регулярно пишу у себя в новостях о дырах на сайтах секьюрити-фирм (например, на сайте разработчика ISS Internet Scanner — http://websecurity.com.ua/378/), которые эти сканеры выпускают. Так что проку от них немного. Использую исключительно свои знания и опыт, а в качестве рабочих инструментов выступают браузер (Mozilla в основном) и текстовый редактор (GVIM). Первый для тестирования, второй — для записи результатов. Причем оба инструментария open source, так что у меня весьма открытый подход :). И знания мои от части open source, так как делюсь с посетителями моего проекта (http://websecurity.com.ua), публикуя информацию о своих исследованиях.
Последовательности поиска уязвимостей как таковой не существует, к каждому ресурсу я всегда подхожу индивидуально. Плюс интуитивно чувствую, где могут быть дыры. Если на сайте присутствуют фильтры (защищающие, например, от XSS), то стараюсь их обойти, когда чувствую, что есть такая возможность, для чего разрабатываю собственные методы. Поэтому если дыра есть, обязательно найду и разработаю методику ее эксплуатации (чтобы показать админам этого сайта потенциальную возможность использования существующей уязвимости).
Вопрос:
Как люди обычно реагируют на твои сообщения об уязвимостях?
MustLive:
Реагируют весьма разнообразно. Кто просто благодарит, кто вдобавок к благодарности просит, чтобы еще сообщили о каких-либо уязвимостях на их сайте. Некоторые предлагают сотрудничество, причем в различных направлениях: кто в области безопасности и на длительный срок, кто предлагает провести детальный секьюрити-аудит сайта, кто в области веб-разработки. А бывают случаи, когда предлагают купить и меня, и мой сайт со всеми потрохами. Некоторые люди задают вопросы касательно дыр на их сайте, в частности, по некоторым типам уязвимостей и по их эксплуатации. Но главное, чтобы люди поняли риски найденных на их сайте уязвимостей и исправили их.
Также бывает, что грубят. Что мол, не понимают ничего в данном вопросе и не видят никакой опасности, либо вообще не знают, о чем я толкую. Или не видят повода для беспокойства. А бывает, и нередко, что вообще никак не реагируют. И сайты так и остаются дырявыми...
Вопрос:
Сколько администраторов прислушивается к твоим предупреждениям об уязвимостях?
MustLive:
Если попытаться усреднить, то получится следующая картина. 60% админов отвечают на мое письмо, из них 59% админов исправляют уязвимости, 1% админов — не исправляют. 40% админов не отвечают на мое письмо, из них 30% админов — исправляют уязвимости, 10% админов — не исправляют. Так что практически 90% админов исправляют указанные мною уязвимости. Это и есть эффективность публичной работы. А ведь эти дыры могли бы годами висеть и эксплуатироваться «добрыми» людьми.
Вопрос:
Как проверить собственный ресурс? Есть ли какие-нибудь готовые тесты, с помощью которых можно локализовать лазейки для применения SQL Injection или XSS?
MustLive:
Тестировать свой ресурс можно как самостоятельно, так и обратившись к профессионалам. Есть различные компании, фирмы и частные секьюрити-специалисты, которые занимаются этим профессионально. Другое дело, что именно на веб-безопасности мало кто специализируется, но и такие деятели есть. Их можно найти через личные сайты, на сайтах секьюрити-тематики или на хакерских форумах. Достаточно обратиться с просьбой найти исполнителя, который протестирует сайт на уязвимости.
Готовых тестов нет, но есть секьюрити-сканеры. Например, XSpider российского разработчика Positive Technologies (недавно вышла 7-ая версия). Есть у него и онлайн-версия — http://online.xspider.ru. Но сканеры могут лишь частично решить вопрос тестирования безопасности веб-сайта или веб-приложения. Ни один сканер не заменит эксперта.
Вопрос:
Есть ли пошаговое пособие, как защититься от SQL Injection и XSS? Или все сугубо индивидуально?
MustLive:
Нужны знания. Поэтому нужно читать о разных типах уязвимостей, чтобы знать их особенности. Также нужно читать об уязвимостях в различных системах, о конкретных дырах. Чтобы знать, где в твоей системе дыра и как исправить (при наличии навыков программирования) именно ее. Нередко в описании уязвимостей сразу приводят необходимые исправления для устранения указанных дыр. Например, MustLive Security Pack (http://websecurity.com.ua/security-pack/) — мое собственное руководство по исправлению уязвимостей. Так что информация есть, нужно лишь искать ее.
Вопрос:
Как от SQL Injection и XSS защищаются гиганты рунета типа Яндекса, Рамблера и Mail.ru?
MustLive:
Не лучшим образом. Это я знаю не понаслышке и не из новостей секьюрити-сайтов, а из собственного опыта. Так как регулярно нахожу уязвимости на таких крупных сайтах. Причем SQL Injection на подобных проектах мне не попадались, а вот XSS — весьма часто.
Яндекс:
- XSS НА IMAGES.YANDEX.RU (HTTP://WEBSECURITY.COM.UA/3/);
- XSS НА www.yandex.ru (http://websecurity.com.ua/36/);
- XSS В КОДЕ ЯНДЕКС-ДИРЕКТ, ЧТО ПОДВЕРГАЮТ XSS-АТАКАМ САЙТЫ ПАРТНЕРОВ (HTTP://WEBSECURITY.COM.UA/398/).
Рамблер:
- XSS НА ADSTAT.RAMBLER.RU (HTTP://WEBSECURITY.COM.UA/11/);
- XSS НА WWW.RAMBLER.RU (HTTP://WEBSECURITY.COM.UA/17/);
- XSS НА LENTA.RU (HTTP://WEBSECURITY.COM.UA/23/);
- XSS НА HOROSCOPES.RAMBLER.RU (HTTP://WEBSECURITY.COM.UA/40/);
- XSS НА LENTA.RU (HTTP://WEBSECURITY.COM.UA/149/).
Mail.ru:
- XSS НА DRIVE.MAIL.RU (HTTP://WEBSECURITY.COM.UA/405/)
Кроме этих лидеров доводилось находить уязвимости на многих других известных и популярных ресурсах: aport.ru, go.km.ru, cnews.ru, www.rbc.ru, www.quote.ru, spylog.ru, на сайтах многих рекламных брокеров, 3dnews.ru (и blog.3dnews.ru) и многих других. И это только те, о которых я так или иначе упомянул у себя на сайте.
Вопрос:
Некоторые идут более простым путем — максимально маскируют работу движка, дабы не перебирать все возможные варианты. Не видно - и ладно: злоумышленник даже не узнает, успешно ли прошла атака. Но так ли это в действительности?
MustLive:
Такой вариант возможен, и маскировка является одним из вариантов защиты. Если используешь какой-нибудь открытый движок, берешь себе новый скин, убираешь все упоминания о версии движка или даже об его имени, при желании меняешь структуру каталогов (нередко именно она выдает тебя, как бы ты не «прятал» движок). Или, как вариант, меняется расширение. Например, на HTML, хотя используется Perl или PHP — с целью ввести атакующего в заблуждение.
Правда, все эти приемы могут отпугнуть новичка, неопытного хакера или скрипт-кидиса, а профессионала не проведешь. И если есть дыра, то он ее обязательно найдет. Или если каким-то образом узнает, какой движок на самом деле на сайте, то сможет простым перебором уязвимостей и эксплойтов выяснить, какая версия, и похакать сайт. Или же проведет исследование системы как черного ящика и самостоятельно найдет уязвимость.
Так что маскировка — малоэффективный способ. Исключением является лишь отключение вывода сообщений об ошибках базы данных. В таком случае проводить атаку SQL Injection сложнее, но и это не проблема для профи (ведь есть же Blind SQL Injection). Отключение ошибок спасает от SQL DB Structure Extraction и в некоторых случаях от XSS-уязвимостей (когда через вывод сообщения об ошибке производят XSS-атаку, что встречается в различных движках).
Вопрос:
Правда ли, что сайты на Flash избавлены от проблем SQL Injection и XSS? Или это миф?
MustLive:
Сам флеш или флеш-элементы, которые используются на сайте, неуязвимы для SQL Injection и XSS. Но в случае использования на сайте каких-либо скриптов (например, PHP-скрипта для доступа к БД) классические уязвимости могут иметь место.
Хотя и с флешем не все так гладко. Во флеше имеется возможность (необходим флеш-плеер соответствующей версии, не пропатченный) отсылать HTTP-запрос (www.securitylab.ru/analytics/271169.php), что позволяет создать злоумышленную флешку, которая будет совершать XSS-атаки на пользователей, просматривающих ее в своем браузере. Например, можно загрузить флешку в «социальные сети» или разместить ее на сайте, и каким-то образом заманить туда пользователей. Или даже разместить флеш-баннер в баннерной сети или в рекламном брокере, включив в него зловредный код. То есть атакованный сайт не обязательно должен быть на флеше, даже наоборот — он вполне может быть на HTML (и даже не содержать никаких флеш-элементов).
Подробнее касательно межсайтового скриптинга в языке Flash можно прочитать на http://websecurity.com.ua/18/, а про инъекции в HTTP-заголовке — на http://websecurity.com.ua/373/.
Вопрос:
Насколько актуальна тема удаленного контроля через XSS?
MustLive:
Весьма. Так как проводятся дополнительные исследования в этой области (http://websecurity.com.ua/361/), появляется различный инструментарий для подобных задач (www.securitylab.ru/analytics/271931.php), например XSS Proxy, backweb, BeEF Exploitation Framework и XSS Shell. Все это может использоваться (и используется) для различных, в основном точечных атак, с целью хищения конфиденциальной информации, паролей и для промышленного шпионажа.
Также удаленный контроль через XSS может быть использован для более глобальных атак, начиная от захвата сайтов (которые просто так не взломаешь) и заканчивая атаками на локальные машины и локальные сети предприятий (http://websecurity.com.ua/369/).
Вопрос:
Что посоветуешь тем, кто только проектирует свой будущий ресурс?
MustLive:
Уже на этапе проектирования уделяй внимание безопасности. И пиши корректный код. А для этого нужен опыт и знания. Читай информацию по теме, например мое руководство по безопасности (http://websecurity.com.ua/security/), предназначенное для веб-разработчиков.
Проверяй свои веб-сайты, веб-приложения и веб-системы на уязвимости — проводи аудиты безопасности. По возможности делай это на начальном этапе. Но и для уже существующих проектов эти же мероприятия не менее актуальны. И не забывай после внесения изменений в веб-приложения проводить повторные проверки.
http://websecurity.com.ua/120/
статистика веб-атак
http://websecurity.com.ua/127/
хакинг сайта через уязвимости в коде внешних систем
http://websecurity.com.ua/474/
хакерская активность в uанете в 2006 году
http://websecurity.com.ua/security/
руководство по безопасности
http://websecurity.com.ua/378/
уязвимость на www.iss.net
http://online.xspider.ru
XSpider Online
http://websecurity.com.ua/security-pack/
MustLive Security Pack
http://websecurity.com.ua/3/
Cross-Site Scripting на Яндексе
http://websecurity.com.ua/36/
новые уязвимости на Яндексе
http://websecurity.com.ua/398/
уязвимости в Yandex-Direct
http://websecurity.com.ua/11/
Cross-Site Scripting на Рамблере
http://websecurity.com.ua/17/
новая уязвимость на Рамблере
http://websecurity.com.ua/23/
XSS на lenta.ru
http://websecurity.com.ua/40/
новая XSS-уязвимость на Рамблере
http://websecurity.com.ua/149/
уязвимость на lenta.ru
http://websecurity.com.ua/405/
уязвимость на drive.mail.ru
http://www.securitylab.ru/analytics/271169.php
подделка заголовков http-запроса с помощью Flash ActionScript
http://websecurity.com.ua/18/
межсайтовый скриптинг в Shockwave Flash
http://websecurity.com.ua/373/
Flash plugin HTTP header injection
http://websecurity.com.ua/361/
XSS для удаленного контроля
http://www.securitylab.ru/analytics/271931.php
продвинутый межсайтовый скриптинг с удаленным контролем в реальном времени
http://websecurity.com.ua/369/
использование уязвимостей на локальных машинах