пятница, 29 мая 2009 г.

Неприятный 0-day в DirectX

Критическая уязвимость в декодере QuickTime может использоваться для выполнения произвольного кода. Векторы использования - Web (activex, download), почта (присоединенный файл QuickTime) и т.д.

Подробности и рекомендации по устранению:
http://www.securitylab.ru/news/380518.php

Текущий статус исправления:
http://www.securitylab.ru/vulnerability/380517.php

воскресенье, 24 мая 2009 г.

Online-семинар RISSPA по вопросам DDOS

Ассоциация професcионалов в области информационной безопасности RISSPA приглашает Вас на вебинар по защите от DDOS атак, который начнется 27 мая в 10-00 по Московскому времени (GMT +3).
Участие в вебинаре бесплатное, при условии предварительной регистрации по адресу: http://risspa.org/seminary/blig_seminar/
DDoS-атаки - распределенные атаки типа отказ в обслуживании (DDoS - Distributed Denial of Service). Сегодня подобный тип атак является одним из самых распространенных и опасных. Ежегодно атаки DDoS стоят различным компаниям и госструктурам миллиарды долларов и таят в себе серьезную угрозу для любой компьютерной системы. Результат таких атак - длительные простои системы, потерянная прибыль и др.
Программа семинара и докладчики:

1) «Стратегии защиты от DDoS-атак», Ларин Виктор, глава представительства ARBOR Networks в России и СНГ;
2) Решение Cisco Clean Pipes по защите от DDoS-атак», Антонов Павел, технический консультант, Cisco Systems;
3) «Оценка эффективности противодействия DDoS-атакам», Сергей Гордейчик, руководитель отдела консалтинга и аудита, Positive Technologies;
4) «Практические аспекты защиты от DDOS-атак», Емельянов Роман, начальник отдела развития систем информационной безопасности, ТТК.

Отчет о PCI Moscow

В четверг закончилась конференция PCI Moscow. Не смотря на узкую специфику мероприятие оказалось достаточно интересным и хорошо организованным.
Из запомнившихся докладов:

"Безопасность банкоматов. Опыт борьбы с кибер-преступниками."
Иван Стригин, Системный инженер, Московское представительство компании «Диболд, Инк»



"Стандарты PCI DSS и СТО БР ИББС 1.0. Сходства и отличия"
Павел Гениевский, Секретарь Совета Сообщества ABISS


Иван раскрыл timeline "борьбы" со злобным вирусом, занимавшимся кражей данных пластиковых карт из банкоматов. И выразил неодобрение отсутствием координации разглашения со стороны антивирусных вендоров. Теперь не только исследователи уязвимостей стоят на тонком льду Full-Disclosure :)). Что хуже - антивирусных вендоров подталкивает мощная маркетинговая машина.

Организаторы обещают опубликовать материалы и презентации на сайте в течении недели.

Мой доклад - "Измеряя защищенность. Метрики безопасности для PCI DSS" ниже.


вторник, 19 мая 2009 г.

Добавляем защиту - добавляем "дыру"

Забавная новость:

Новая защита Wi-Fi-роутеров D-Link оказалась брешью в безопасности

Не успела компания D-Link анонсировать обновленное микропрограммное обеспечение для беспроводных роутеров с функцией защиты от автоматических регистраций (CAPTCHA), как сразу несколько энтузиастов обнаружили, что новая мера защиты делает владельца такого роутера еще более уязвимым для похищения паролей доступа.


http://www.securitylab.ru/news/379779.php

Детали тут:

http://www.sourcesec.com/2009/05/12/d-link-captcha-partially-broken/

На форуме SecurityLab уже успели отметится товарищи с заявлениями типа:

Я не понял, опять взлом метода ввода дефолтного пароля?

На самом деле, ситуация гораздо забавнее. Дело в том, что CAPTCHA была задействована D-link для защиты от Cross-Site Request Forgery (CSRF), которую (точнее метод её эксплуатации на роутере) Symantec громко назвал Drive-by Pharming. Но ошибка реализации, а именно прием запросов с "правильным" хэшем без значений CAPTCHA делает эту защиту уязвимостью.

В случае со стандартными паролями и так существовал трюк обхода Basic-аутентификации, используя Javscript (см. "Пробиваем периметр" http://www.securitylab.ru/analytics/292473.php ).

Но если пароль (или его производная, такая как хэш) передается в GET (в качестве дублирования Basic), то ситуация становится еще интересней - злоумышленник может использовать не только хэщ стандартного пароля, но реализовать на Javascript подбор пароля пользователя с использованием CSRF, от которой CAPTCHA была призвана защищать.

Т.е. эта уязвимость распространяется не только на стандартные пароли, но и может повысить эффективность подбора паролей пользователей с использованием CSRF, причем стандартные механизмы парольной защиты (таймауты, временная блокировка и т.д.) работать не будут, поскольку идет не собственно подбор, а попытки соединения с различными значениями "как бы" нормального хэша пароля, используемого вместо идентификатора сессии. Для этого достаточно написать элементарный скрипт, обращающийся по адресу

GET /post_login.xml?hash=

и проверяющий "успешность" входа. Главное - заставить человека зайти на нужную страницу :)

В общем, достаточно интересная ошибка проектирования механизма аутентификации Web-приложения.

понедельник, 18 мая 2009 г.

Утилита для проверки WINS и DNS (MS-09-008)

Утилита для выявления потенциально опасных записей в базе DNS- и WINS-служб. Утилита также позволяет сканировать доступную локальную сеть на предмет существования хостов с опасными NetBIOS-именами. Периодическое использование утилиты позволит системным администраторам, а также администраторам по безопасности контролировать использование потенциально опасных записей в серверах имен и присутствие в сети узлов с опасными NetBIOS-именами.




Подробная информация в статье Сергея Рублева:
http://www.securitylab.ru/analytics/379619.php

Ссылка для загрузки:
http://www.ptsecurity.ru/download/wpadcheck.zip

четверг, 14 мая 2009 г.

Compliance как угроза. Анализируем риски #2

В ходе обсуждения пришла в голову мысль.


Дарю идею интеграторам, продвигающим ЗПД: сделать online калькулятор рисков. Вводишь отрасль, годовой оборот, регион и принятые меры по защите и получаешь вероятность реализации угроз (административная, уголовная) и даже риски. Данные все открытые, с поддержкой справится студент.

Кстати, еще нет данных по эффективности контр-мер. Иметь бы источник (открытый), кто из интеграторов делал проекты ЗПД для компаний и коррелировать это с последствиями проверок :)))

среда, 13 мая 2009 г.

Compliance как угроза. Анализируем риски

Если рассматривать вопрос соответствия требованиям с точки зрения анализа рисков, т.е. принимать:

угроза - прописанные регулятором последствия нарушения
уязвимость - несоблюдение требований
атака - проверка регулятора
контрмера - соблюдение требований

возникает практически беспрецедентная ситуация - у нас присутствую все необходимые исходные данные для проведения количественного анализа рисков на основе классической методики ARO x SLE = ALE.

http://www.windowsecurity.com/articles/Risk_Assessment_and_Threat_Identification.html

У нас есть:

ARO - вероятность проверки регулятором
SLE - прописанные регулятором последствия нарушения

Этот интересный случай доказывает не только тот факт, что школьные правила все же иногда работают, но и великую пользу compliance как двигателя информационной безопасности.

И так, рассмотрим пару примеров, которые сейчас "на слуху" - ФЗ 152 (ЗПД) и PCI DSS.

PCI DSS

Здесь все довольно просто, потому как в связи с известными событиями в мировой экономике Visa и другие платежные системы решили "не кошмарить бизнес", и, в большинстве случаев позволяют сдвигать action plan. Это дает отсрочку в реализации атаки в несколько лет. Беспрецедентная ситуация, когда вы точно знаете, что данная конкретная атака не произойдет в течение года. Или двух. Представьте себе индульгенцию от вирусных атак или кражи оборудования сроком на год... Великолепная штука.


Итак:

угроза - штраф (N децикило $) или ущерб от запрета операций (пусть для простоты будет тоже N децикило $), SLE
уязвимость - несоблюдение требований (PCI DSS)
атака - реакция регулятора на отступление от action plan (вероятность наступления, ALE - 0 раз в год)

Итого, получаем:

Риск = (N децикило $) x (0) = 0

Т.е. можно ничего не делать!!!

Но! Ключевым условием является наличие action plan. Соответственно надо его сформировать. Самому, или с помощью QSA - по желанию. К сожалению, у меня нет информации о реакции регуляторов на отсутствие action plan по PCI DSS, но думаю, что SLE в этом случае будет на уровень стоимости контрмеры (аудита).

ФЗ 152

Тут все просто.

угроза - несколько вариантов

1. Административная ответственность - штрафы
2. Приостановление или прекращение обработки персональных данных в компании - время простоя/деградации связанных бизнес-процессов "до устранения". Думаю, можно смело взять минимум 1/6 года.
3. Привлечение компании и (или) ее руководителя к уголовной (гражданской, дисциплинарной и иным видам ответственности) - катастрофический риск.
4. Приостановление действия или аннулирование лицензий на основной вид деятельности компании - в текущей ситуации ближе к катастрофическому.


атака - проверка регулятора

В связи с новизной и интересностью для регулятора и возможность инициации внешними силами (заявление), вероятность реализации в 2010 году можно принять равной 1.
Если кого-то интересует более детальные расчеты по отраслям деятельности и регионам, можно использовать статистику:

http://community.livejournal.com/personal_data/721.html

Итого, получаем:

Риск = (стоимость бизнеса) x (1) = (стоимость бизнеса)

Т.е. проблема есть и ее надо решать.

PS. Не надо делать далеко идущие выводов. Просто анекдот.

вторник, 12 мая 2009 г.

PCI Moscow - Обеспечивая безопасность данных платежных карт в России


21 мая пригласили поучаствовать в "франшизе" международной конференции по безопасности платежных карт PCI Moscow

http://www.pci-portal.com/lang-ru/events/event-info/pcimoscow/agenda

Доклад будет посвящен метрикам безопасности в контексте PCI DSS. Планирую поделиться нашими наработками в этой области и международным передовым опытом. Тезисы ниже:

Измеряя защищенность. Метрики безопасности для PCI DSS


Цикл практических работ по обеспечению соответствия PCI DSS кроме ежегодных аудитов включает ежеквартальное сканирование периметра сети, анализ защищенности Web-приложений и тесты на проникновение. В ходе этих работ, как правило, обнаруживаются уязвимости различной степени риска, приводящие к несоответствию стандарту. Многие из этих проблем требуют серьезных затрат для полного устранения и их полное искоренение может занять не один год. Какие типы уязвимостей наиболее распространены? Какова вероятность обнаружения той или иной проблемы? Какие компенсационные меры наиболее адекватны? Как продемонстрировать прогресс в обеспечении соответствия стандарту?


PS. Как ни печально, практически не слышал интересных выступлений на тему PCI. Все в основном сводится к "пугалам", или пересказу основных требований стандарта. Хотя есть и редкие исключения. Например, доклад Максима Эмма по наиболее распространенным нарушением.

понедельник, 4 мая 2009 г.

«Как мне защитить свой сайт от бретанских хакиров?»

Запущен пилот экспертных панелей на SecurityLab.

Из анонса:

В течение 10 дней компании «1С-Битрикс», Positive Technologies и Aladdin проводили совместную акцию на портале Securitylab - любой пользователь мог задать свой вопрос экспертам компаний. За это время были получены десятки вопросов*, ниже опубликованы ответы на самые актуальные и интересные. Компании благодарят всех принявших участие в акции и обещают, что ни один вопрос не останется без ответа – ответы на оставшиеся вопросы будут высланы участникам по электронной почте.


Коллеги отнеслись к предложению с юмором. В заголовок поста вынесен один из наиболее волнующих общественность вопросов. "Бретанские хакиры" волнуют всех.

Просмотреть вопросы и ответы можно тут:

http://www.securitylab.ru/news/378798.php


Если есть интерес к подобным мероприятиям - продолжим.