Критическая уязвимость в декодере QuickTime может использоваться для выполнения произвольного кода. Векторы использования - Web (activex, download), почта (присоединенный файл QuickTime) и т.д.
Подробности и рекомендации по устранению:
http://www.securitylab.ru/news/380518.php
Текущий статус исправления:
http://www.securitylab.ru/vulnerability/380517.php
пятница, 29 мая 2009 г.
воскресенье, 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-атак», Емельянов Роман, начальник отдела развития систем информационной безопасности, ТТК.
Участие в вебинаре бесплатное, при условии предварительной регистрации по адресу: 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" ниже.
Из запомнившихся докладов:
"Безопасность банкоматов. Опыт борьбы с кибер-преступниками."
Иван Стригин, Системный инженер, Московское представительство компании «Диболд, Инк»
"Стандарты 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-приложения.
Новая защита 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
Подробная информация в статье Сергея Рублева:
http://www.securitylab.ru/analytics/379619.php
Ссылка для загрузки:
http://www.ptsecurity.ru/download/wpadcheck.zip
четверг, 14 мая 2009 г.
Compliance как угроза. Анализируем риски #2
В ходе обсуждения пришла в голову мысль.
Дарю идею интеграторам, продвигающим ЗПД: сделать online калькулятор рисков. Вводишь отрасль, годовой оборот, регион и принятые меры по защите и получаешь вероятность реализации угроз (административная, уголовная) и даже риски. Данные все открытые, с поддержкой справится студент.
Кстати, еще нет данных по эффективности контр-мер. Иметь бы источник (открытый), кто из интеграторов делал проекты ЗПД для компаний и коррелировать это с последствиями проверок :)))
Дарю идею интеграторам, продвигающим ЗПД: сделать 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. Не надо делать далеко идущие выводов. Просто анекдот.
угроза - прописанные регулятором последствия нарушения
уязвимость - несоблюдение требований
атака - проверка регулятора
контрмера - соблюдение требований
возникает практически беспрецедентная ситуация - у нас присутствую все необходимые исходные данные для проведения количественного анализа рисков на основе классической методики 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
Если есть интерес к подобным мероприятиям - продолжим.
Из анонса:
В течение 10 дней компании «1С-Битрикс», Positive Technologies и Aladdin проводили совместную акцию на портале Securitylab - любой пользователь мог задать свой вопрос экспертам компаний. За это время были получены десятки вопросов*, ниже опубликованы ответы на самые актуальные и интересные. Компании благодарят всех принявших участие в акции и обещают, что ни один вопрос не останется без ответа – ответы на оставшиеся вопросы будут высланы участникам по электронной почте.
Коллеги отнеслись к предложению с юмором. В заголовок поста вынесен один из наиболее волнующих общественность вопросов. "Бретанские хакиры" волнуют всех.
Просмотреть вопросы и ответы можно тут:
http://www.securitylab.ru/news/378798.php
Если есть интерес к подобным мероприятиям - продолжим.
Подписаться на:
Сообщения (Atom)