суббота, 26 декабря 2009 г.

Ruscripto 2010 CFP

Коллеги, поздравляю вас с наступающими праздниками и приглашаю принять участие в формировании программы Рускрипто 2010.

Программа конференции полностью открыта. Тезисы работ можно присылать в адрес программного комитета, а доклады следующих секции можно согласовать со мной:

«Penetration testing internals»
«Интернет и информационная безопасность»

В этом году на Рускрипто планируется ряд интересных нововведений, таких как мастер-классы и даже CTF между вузовскими командами... Но об этом позже.

Удачных выходных!

среда, 16 декабря 2009 г.

ПД умерли?! Да здравствуют ПД!

Не мог обойти вниманием перенос "приведения в соответствие" 152-ФЗ на год.

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

С точки зрения маркетинга - неплохой способ "освежить тему" :)
Кстати, кто-то в знает, как там Visa? Все еще "переносит"?

четверг, 19 ноября 2009 г.

Юридические аспекты консалтинга в области ИБ

Опубликовал презентацию доклада «Всех аудиторов «посодют»?! Юридические аспекты консалтинга в области ИБ»:

http://www.ptsecurity.ru/news_page.asp?id=75

Обратная связь приветствуется.

понедельник, 9 ноября 2009 г.

Всех аудиторов «посодют»?! Серия 2.

В рамках II Межотраслевого Форума директоров по информационной безопасности решил собраться с мыслями и поднять снова эту щекотливую тему. Пора уже скомпилировать статью, но... Конец года...

Презентацию, естественно выложу.

Всех аудиторов «посодют»?! Юридические аспекты консалтинга в области ИБ

Сергей Гордейчик, Positive Technologies

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

Ищу человека

Скопилось огромное количество дел на работе, которыми готов поделится с хорошим(и) человек-ом(-ами). На постоянной основе и за адекватное вознаграждение, естественно.

Как уже говорил - работы много, и пока есть возможность выбирать. Как пишут на ценниках - работа в асс. :) Не смотря, на то, что практически все связанно с MaxPatrol, широта и глубина продукта (plug) позволяют захватывать, пахать, расширять и углублять широченный пласт информационной безопасности, что полезно для головы.

Консалтинг

Широкий пласт задач, связанный с запуском и поддержкой у Заказчиков процессов управления уязвимостями и соотвествия стандартам.
• Разработка и адаптация регламентов и проч. с учетом использования средств автоматизации.
• Разработка и адаптация существующих технических стандартов и типовых профилей защиты.
• Реализация типовых профилей защиты и процесса мониторинга ИБ в рамках MaxPatrol.
• Разработка набора ключевых показателей эффективности и метрик безопасности для оценки эффективности внедляемых процессов.
• Реализация ключевых показателей эффективности и метрик безопасности в рамках MaxPatrol.
• Поддержка и оптимизация процессов.
• И т.д. и т.п.

Причем для нас крайне важно, чтобы процессы "крутились", продукт использовался, поэтому реализации только первого этапа недостаточно :). Это плавно подводит нас к следующей задаче.

Сервисные услуги

Можете называть это, если угодно "аутсорсингом". Суть та же, что и в предудущем случае, но степень включения во внутренние процессы выше. Ну и капитальные расходы на OPEX перенести можно :)

Развитие MaxPatrol

Тут есть где развернуться фантазии.
  • Конкурентный анализ.
  • Формирование требований к системе.
  • Мониторинг перспективных разработок в области Compliance Management.
  • Формализация и кросс-проекции требований государственных, отраслевых, международных стандартов.
  • Формализация требований к безопасности и формирорание технических стандартов к различным системам (а-ля CIS, только правильных).
  • ...

Пресейл

Заказчики/конференции/публикации/демонстрации/пилотные проекты/спецификации/сопроводжение работ интеграторов.....

Внедрение

Обследование/Опытная эксплуатация/ПИ/Промышленная эусплуатация/ТРП (в алфавитном порядке)


Понятно, что не все и не одновременно. Вполне можно сосредоточится на чем-то одном, или чередовать по желанию/необходимости.

Где работать?

http://www.ptsecurity.ru/contacts.asp

С кем работать?

http://www.ptsecurity.ru/analytics.asp

http://malotavr.blogspot.com/

http://devteev.blogspot.com/

Если интересно или есть вопросы, пишите в почту или сюда.

воскресенье, 1 ноября 2009 г.

Семинар RISSPA от 29.10.2009

Довелось выступить на довольно интересном мероприятии: семинар RISSPA "Технический взгляд на актуальные угрозы информационной безопасности". Этакий междусобойчик российских вайтхэтов и гуру менеджмента ИБ. В принципе понравилось - непринужденно и по делу. Из докладов произвело впечатление выступление Ильи Сачкова из Group IB. Несмотря на прессинг со стороны оппонентов (как оказалось - соратников и конкурентов).

Мой доклад:




Запись online трансляции (c эклюзивной привет-одей заставкой):





Презентации других выступающих:

http://risspa.org/12seminar

Отзывы и обсуждения:

http://securityaudit.blogspot.com/2009/10/blog-post_29.html

http://iso27000.ru/blogi/oleg-bezopasnik/seminar-ot-risspa-tehnicheskii-vzglyad-na-aktualnye-ugrozy-informacionnoi-bezopasnosti/

В целом мероприятие удалось, огромное спасибо организаторам и спонсорам.

среда, 28 октября 2009 г.

Выступление на "Разработке ПО 2009"

Сегодня выступал на мероприятии, которое странным образом оказалось знакомым. Пока готовил презентацию, понял, что такое уже делал. Посмотрел и действительно, с подобным докладом выступал на SQL Days. Но сейчас доклад получился более помпезным. Видимо окружение обязовало.
На этом же круглом столе выступал также Юрий Гуревич из Microsoft Research. Оказывается Microsoft упорно пишит аналог MaxPatrol. Я в шоке :). Придется интегрироваться... Пообщались, проблемы теже. В том числе и управление требованиями. И тоже пока не решена.



К сожалению, работа не дала возможности остаться на все выступления. Пришлось убежать.

понедельник, 26 октября 2009 г.

Мероприятия на этой неделе

В среду и в четверг буду участвовать в конференции "Разработка ПО 2009" (CEE-SECR 2009, http://cee-secr.org/) и очередном семинаре RISSPA.




http://cee-secr.org/round-tables/information-security-of-computer-systems/


Безопасность прикладных систем. Разработчик, аудитор, пользователь.


Все, что сделано руками людей далеко от совершенства. В результате ошибок проектирования, реализации и эксплуатации в компьютерных системах возникают уязвимости, т.е. свойства системы, использование которых злоумышленником может привести к ущемлению интересов владельца этой системы. Многие уязвимости обнаруживаются производителем на этапе разработки, тестирования и сопровождения продуктов, однако часть их обнаруживается владельцами систем, независимыми исследователями и аудиторами. В докладе предлагается обзор следующих вопросов:
- статистики распространенных проблем безопасности приложений';
- требований регуляторов в части безопасности прикладных систем (PCI DSS, 152-ФЗ «О персональных данных» и т.д.);
- существующих практик безопасной разработки, покупки и сопровождения прикладных систем;
- подходов к взаимодействию производителя или владельца ресурса и исследователя, обнаружившего проблему.

В рамках доклада анонсируется вторая версия классификации Web-узвимостей Web Application Security ConsortiumThreat Classification version 2.




http://risspa12.eventbrite.com/?ref=ecount

«(Бес)проводная (без)опасность»

В рамках доклада рассматриваются типичные проблемы, связанные с беспроводными технологиями, вопросы управления регулятивными требованиями в этой области, дается обзор передового опыта и принятых практик. Материал построен на практическом опыте компании Positive Technologies в области тестирования на проникновения и построения процессов Compliance Management.

понедельник, 19 октября 2009 г.

Статистика безопасности Web-приложений 2008

Опубликована статистика уязвимостей Web-приложений за 2008 г. консорциума Web Application Security Consortium (WASC). Ознакомиться с ней можно здесь.

Русский вариант для загрузки.

WASC Web Application Security Statistics 2008 (Russian)

Публикация содержит обзорную статистику уязвимостей Web-приложений, полученную в ходе работ по тестированиям на проникновение, аудитов безопасности и других работ, проводимых Компаниями, входящими в консорциум WASC в 2008 году. Всего статистика содержит данные о 12186 сайтах, в которых было обнаружено 97554 уязвимости различной степени риска.

Дмитрий Евтеев опубликовал сравнение с нашей статистикой:



Забавно, но между русским (первоначальным, как вы могли догадаться) и "word-wide" есть некоторые различия. Для соблюдения политесу был выкинут раздел 4.3 - сравнение различных методик . Вот он, свободный демократический мир :)

четверг, 15 октября 2009 г.

PCI DSS и беспроводные сети

В очередной раз воник вопрос о PCI DSS и беспроводных сетях

http://www.securityfocus.com/archive/137/507096

But how can we determine if this rogue AP and especially rogue wireless
clients (WLAN card into a back office server)
are inside CDE? By signal level? But Kismet shows this information only
for APs (not for clients) :(


Я уже отвечал на этот вопрос на сайте информзащиты, повторюсь.


>как узнать, что беспроводная точка с включенным шифрованием принадлежит к нашей локальной сети?


Принадлежность точки может вычисляться различными способами. Самый простой - по трафику, "летающему" в воздухе. Даже есть точка использует нормальное шифрование (не WEP), то в открытом виде передается достаточное количество информации для идентификации сегмента. Например - mac адреса отправителя. Поскольку точка доступа является устройством канального уровня, она будет ретранслировать все широковещательные запросы сегмента "в воздух". А поскольку в сети таких запросов достаточно много (ARP, NetBIOS, IPv6 и т.д.), то сравнив MAC-адреса отправителей пакетов через точку со списком известных MAC-адресов своей сети можно легко идентифицировать место, куда включена точка. Дополнительно можно спровоцировать отправку большого количества широковещательных пакетов в сегменте с помощью утилит, реализующих ARP-ping, таких как Cain или nmap. А бегать с антенной за каждым beacon - задача не для слабонервных.

>А где можно почитать про технологию поиска точек методом
>триангуляции и какую лучше антенну использовать?


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

http://www.wifilab.ru/catalogue/catalogue.php?cat_id=51

Крайне рекомендую мою книгу ;)

http://www.techbook.ru/gordejchik.html


>А если это действительно правильно сконфигурированая точка WPA2+hidden+MAC
> filter. Долго придется искать пока не будет активности.


Такая точка подключенная к сети все равно "фонит":
- рассылает beacon (пусть и с пустыми ESSID)
- транслирует broadcasts и multicast с Mac-адресами источника в открытом виде

Трудно представить себе сеть без широковещательных запросов. А о том как по ним идентифицировать местоположение точки доступа я писал ранее.

>Определение клиентов, подключающимся к внешним точкам доступа

Клиентов, санкционировано подключающихся к "внешним" точкам доступа можно определять с помощью активных средств оценки защищенности. Например в MaxPatrol есть три механизма, позволяющие решать эту задачу: - инвентаризация, в рамках которой анализируются настройки беспроводных клиентов Windows - оценка защищенности, в рамка которой проводится анализ небезопасных конфигураций (например, multihomed, отсутствие шифрование, использование WEP) - контроль соответствия (compliance), позволяющий указывать черные и белые списки точек доступа, разрешенных в сети.

Путем мониторинга беспроводной сети, но для этого надо предварительно составить список "своих" MAC-адресов. Можно это сделать активными средствами (см выше) или пассивными (см. ниже).

>Как понять, твои ли это пользователи?


Немного об этом писал здесь.

Но в любом случае, рабочая станция (особенно под управлением Windows) рассылает очень много интересного трафика, по которому можно определить принадлежность к сети. Это и NetBIOS Broadcast и запросы WPAD и DHCP-запросы в которых передается имя узла и домена...

Остается открытым вопрос - как спровоцировать на отправку данного трафика? Тут нам на помощь приходит Gnivirdraw.

>Активные сканеры нам не помогут!!!

Конечно, полезно иногда пробежаться с ноутбуком :). Но сканеры вполне могут помочь решить следующие задачи:

- инвентаризация (fingerprint) в режиме pentest сетевых устройств (в том числе и AP).
- инвентаризация настроек беспроводных клиентов (MAC-адресов, списков сетей)
- анализ конфигурации точек доступа
- анализ журналов беспроводных устройств с точки зрения "нехороших" событий

среда, 14 октября 2009 г.

Интеграция MaxPatrol и Cisco MARS

На прошедшей Cisco Expo выступал с докладом по интеграции MaxPatrol и Cisco MARS.
Пресс релиз:
http://www.securitylab.ru/news/386246.php

Кроме CS MARS теперь работаем также с ArcSight.

Документация по настройке доступна через службу технической поддержки.

вторник, 1 сентября 2009 г.

Всех пентестиров посодют?

Компании "Инфовотч" видимо надоели обвинения в нарушении Конституции РФ и тайны переписки, и они решили перевести внимание на другую группу, подставив экспертов в области тестирования на проникновение. Инкриминируют им не много, ни мало - 273 статью УК - т.е. до 3х лет.
Понятно, что все это глупости, и настоящие пентестеры не создают вредоносное программное обеспечение, а используют утилиты удаленного управления, НО!
Между пентестерами и антивирусной индустрией действительно существует некоторый конфликт.

Г-н Гостев из ЛК в своем блоге комментирует:

конкретизирую еще больше: присесть по 273 пентестер может только если заказчик окажется недоволен или решит сэкономить на оплате. Но возникнут серьезные проблемы с доказательством "создания" и туманным наличием "распространения". Гораздо проще пентестера пустить не по 273, а по 274. Или 272 :)

Тут есть не совсем правда. Дело в том, что по 274 у нас практически нет правоприменительной практики. 272 практически полностью закрывается договором, где прописывается возможность нарушения целостности, доступности и конфиденциальности, а также меры по минимизации последствий.
НО! 273 - подразумевает такую вещь как разработка и распространение вне зависимости от последствий (ущерба). Казалось бы - что здесь такого?

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

Детализирую. Сложность "утилит удаленного управления" может меняться в зависимости от ТЗ на работы. Это могут быть относительно простые вещи (даже HTML или HTA-файлы), которые оставляют маркер в уязвимой системе или на внешнем сервере, демонстрируя наличия проблемы. Такой подход часто используется в ходе оценки эффективности программы повышения осведомленности в области ИБ, когда "закрепление" в нескольких тысячах систем тестируемых сотрудников не имеет смысла.
Но иногда, в ходе глубоких Red Team Pentest заказчика интересует, сумеет ли "продвинутый" злоумышленник обойти комплекс средств защиты, куда входят и антивирусы...
В этой ситуации пентестерам приходится искать недостатки в антивирусных программах и разрабатывать "утилиты удаленного управления", обходящие защиту.
Казалось бы - и в чем проблема? На то они и пентесты, чтобы искать уязвимости. По окончанию - отрапортовали антивирусному вендору об уязвимости, он закрыл проблему, и все счастливы...

Но.......................................
Жалко!

Достаточно дорого и затратно разрабатывать новые и новые методы обхода антивирусных средств для каждого теста. Хочется использовать их пока вендор сам не закроет проблему. И сменить responsible (или full) disclosure на non-disclosure.

И тут возникает конфликт. Антивирусному вендору тоже обидно, что кто-то нашел у него уязвимость и во всю использует, не ставя его в известность.

Таким образом, потенциальная проблема есть, но существует она в основном из-за конфликта интересов пентестеров и антивирусных вендоров. И, соответственно, решать её придется каждой компании, занимающейся пентестами для себя индивидуально.

пятница, 28 августа 2009 г.

WPA взломан?! Опять?!

Toshihiro Ohigashi и Masakatu Morii опубликовали работу об улучшенной атаке на WPA. Вместо QoS используется MitM, но логика та же. Результаты - восстановление MIC, расшифрование коротких пакетов.
Время атаки уменишилось на порядок (с 10-15 до 1-2 минут), но результаты пока не критичны.

В любом случае WPA-TKIP стоит держать только для совместимости.

пятница, 17 июля 2009 г.

Уважаемый. Напишите о практической реализации MITM атаки на Wi-Fi сеть инсайдером!

Вот такой странный комментарий появился у меня в журнале.

Ну что ж, по просьбе зрителей.

Данная информация предоставляется на условиях "КАК ЕСТЬ", без предоставления каких-либо гарантий и прав. Все информация в этом сообщении носит информационный характер и не должна использоваться для нарушения Российского и международного законодательства. Используя данную информацию, Вы соглашаетесь с тем, что авторы не несут ответственности за использование Вами данной информации, и Вы принимаете на себя весь риск, связанный с использованием данной информации. Авторы не несут ответственности за использование данной информации третьими лицами.

Вариант 1 (сложный). Двойной MITM

Необходимо:
1. Точка доступа (AP)
2. Рабочая станция под управлением Windows (WS)
3. Опционально - рабочий набор утилит Aircrack с возможностью внедрения фреймов (HS) (может быть под Windows или под Linux). Это требование включает в себя "правильную" сетевую карту, драйверы и т.д.

Последовательность действий:
1. AP настраивается в режиме AP :) с использованием известного злоумышленнику ключа WPA2 и SSID реальной точки доступа.
2. WS подключается к AP и к проводной сети. Сетевые адаптеры переводятся в режим моста (bridge) для проброса трафика между проводным и беспроводным сегментом.
3. Атакуемый отключается от реальной точки доступа с помощью HS, реализующей атаку deauth flood .
4. На WS запускается программа Cain & Abel, реализующая атаку MITM на протокол SSL с использованием ARP-spoofing через проводной адаптер.
5. Задача решена, землекопа полтора.

Вариант 2 (простой). Просто MITM

Необходимо:
1. Рабочая станция под управлением Linux (HS) с Aircrack (HS).
2. Виртуальная машина Windows WS (я использую VmWare) на HS.

Последовательность действий:
1. HS подключается к легитимной точке доступа с использованием известного плохому парню ключа WPA2.
2. На WS запускается программа Cain & Abel, реализующая атаку MITM на протокол SSL с использованием ARP-spoofing.
3. Задача решена, землекопа полтора.

Поскольку все это шаманство связанно с тем, что WinPcap не умеет работать с беспроводными адаптерами, а Cain&Abel и круче ettercap и вообще rulezz foreva , но не очень работает на Linux то существует еще:

Вариант 3. Kiddie-style

Необходимо:
1. Рабочая станция под управлением Windows (WS) с установленным AirPcap.

Последовательность действий:
1. WS подключается к легитимной точке доступа с использованием известного плохому парню ключа WPA2.
2. На WS запускается программа Cain & Abel, реализующая атаку MITM на протокол SSL с использованием ARP-spoofing.
3. Задача решена, землекопа полтора.

PPS. Вообще работать с WiFi стало как-то скучно. Недавно, проводя внутренне обучение обнаружил, что в AirCrack уже встроили wep0ff и wep0ff_ng.

Просто - запускай и взламывай тестируй.

среда, 15 июля 2009 г.

Новые 0-day

Две полезных заметки Валерия Марчука про незакрытые и активно используемые злоумышленниками уязвимости:

Уязвимости нулевого дня и защита от текущих угроз

Защита от 0-day в Microsoft DirectShow

PS. Поздравляю Валерия с получением статуса MVP. Сейчас с Positive Technologies и SecurityLab сотрудничает уже 3 эксперта, сертифицированные как MVP in Enterprise Security.

четверг, 25 июня 2009 г.

Сколько людей, столько мнений. Аудиторы PCI о хранении PAN

Практически одновременно запущенно два сайта по PCI DSS: один от Информзащиты и второй от Digital Security.

Интересным оказалось наличие у аудиторов двух диаметрально противоположных взглядов на хранение PAN.
Если Digital Security достаточно категорично выступает против хранения PAN в открытом виде и предлагает использовать их хэш-значения, то Информзащита не видит ничего противоречащего требованиям PCI в хранении PAN в открытом виде в почтовых ящиках пользователей.

Цитировать и вырывать из контекста не хочу, лучше посмотреть оригинальные обсуждения.

понедельник, 22 июня 2009 г.

Secret, Sex, Love, God? Нет, 1234567!

Опубликован подготовленный Дмитрием Евтеевым обзор наиболее распостраненных нарушений парольной политики в российских компаниях.
Как показано в публикации, статистика используемых паролей российских пользователей значительно отличается от данных западных исследований. Так, список наиболее распространенных паролей включает только фразы, составленные из расположенных рядом символов, таких как 1234567 и qwerty, тогда как западные пользователь больше склонны использовать слова английского языка (password, love и т.д.). Более 50% используемых паролей состоят только из цифр, что крайне негативно сказывается на их стойкости.
Требования PCI DSS нарушаются в 74 случаях из 100, а администраторы более склонны к использованию пустых паролей чем обычные пользователи.

Полный текст исследования:
http://www.ptsecurity.ru/download/PT-Metrics-Passwords-2009.pdf

Другие исследования Positive Technologies:
http://www.ptsecurity.ru/analytics.asp

воскресенье, 7 июня 2009 г.

вторник, 2 июня 2009 г.

Материалы семинара RISSPA по DDoS

Опубликованы материалы семинара RISSPA по теме DDoS. Презентации и аудио доступны для загрузки по следующей ссылке:
http://risspa.org/seminary/prosched_seminar/materialy/

Ниже моя презентация и тезисы.




ОЦЕНКА ЭФФЕКТИВНОСТИ ПРОТИВОДЕЙСТВИЯ
DDOS-АТАКАМ


Сергей Гордейчик, руководитель отдела консалтинга и аудита Positive Technologies
http://sgordey.blogspot.com/


Резюме


Распределенные атаки типа «Отказ в обслуживании» (DDoS) являются одной из наиболее актуальных угроз, связанных с использованием сети Интернет. Защитные меры, используемые для противодействия DDoS-атакам, представляют собой сложный комплекс мероприятий, реализуемых на техническом и организационном уровне. Зачастую неизвестно, достаточны ли они для противодействия текущему уровню угрозы.
В докладе рассматриваются практические подходы к оценке эффективности мер по противодействию DDoS-атака на уровенях приложений, сетевой инфраструктуры, доступа к сети Интернет с использованием паттернов реальных DDoS-атак.



Введение


Распределенные атаки типа «Отказ в обслуживании» (DDoS) являются одной из наиболее актуальных угроз, связанных с использованием сети Интернет. В то время как зависимость бизнеса от внешних сервисов, предоставляемых с помощью Интернет, растет, злоумышленники совершенствуют механизмы осуществления атак и наращивают мощности бот-сетей, используемых для DDoS.
Защитные меры, используемые для противодействия DDoS-атакам, представляют собой сложный комплекс мероприятий, реализуемых на техническом и организационном уровне. Зачастую неизвестно, достаточны ли они для противодействия текущему уровню угрозы. При стечении ряда обстоятельств может оказаться, что защита недостаточно эффективна, и сервисы и приложения при проведении реальной атаки будут заблокированы.
Таким образом, комплекс мер защиты от DDoS-атак нуждается в периодическом тестировании. По опыту компании Positive Technologies наиболее эффективным методом является сочетание анализа технических и организационных средств защиты с практическим нагрузочным тестированием компонентов ИС, эмулирующим реальную DDoS-атаку.

Уровень приложений


Обычно атаки, направленные на отказ в обслуживании реализуются на сетевом уровне, однако они могут быть направлены и на прикладной уровень. Используя функции приложения, злоумышленник может исчерпать критичные ресурсы системы или воспользоваться уязвимостью, приводящий к прекращению функционирования системы.
Атаки могут быть направлены на любой из компонентов приложения, например, на сервер СУБД, DNS, сервер аутентификации и т.д. В отличие от атак на сетевом уровне, требующих значительных ресурсов злоумышленника, атаки на прикладном уровне обычно легче реализовать.
В ходе работ проводится экспресс-анализ доступных функций приложения, и составляется оценка ресурсоемкости данных функций с точки зрения функционирования всего приложения. Затем проводится нагрузочное тестирование согласованного перечня функций с заданной нагрузкой.

Уровень сетевой инфраструктуры


Зачастую узким местом при проведении DDoS-атак является сетевая инфраструктура, обеспечивающая функционирование приложений. Опыт компании Positive Technologies показывает, что в ряде случаев отказ в обслуживании возникает в результате ошибок в конфигурации систем и средств защиты, которые призваны снизить последствия атаки. Стек TCP/IP серверов, межсетевые экраны, средства балансировки нагрузки, системы предотвращения атак (IDS/IPS), маршрутизаторы и коммутаторы имеют свои предельные эксплуатационные характеристики. В результате повышенной нагрузки, возникающей в ходе DDoS, один из ключевых компонентов сетевой инфраструктуры может прекратить нормальное функционирование и усугубить ущерб от атаки.

Уровень доступа к сети Интернет


Одним из наиболее деструктивных факторов DDoS-атаки является загрузка «мусорным» трафиком магистральных каналов доступа к сети Интернет. В результате уязвимым местом становятся каналы связи Интернет-провайдера. В случае подобной атаки важно наличие отлаженного регламента взаимодействия Заказчика с персоналом Интернет-провайдера. При обнаружении атаки необходимо оперативно скоординировать действия по снижению последствий атаки (перенос сервиса на резервные площадки, включение дополнительных мощностей, активация средств защиты и т.д.). Для проверки эффективности данного взаимодействия можно использовать аналитический и практический анализ эффективности существующего регламента взаимодействия в случае DDoS.
В рамках аналитической части проводится экпертиза существующих регламентов с точки зрения передового опыта и международных стандартов по обеспечения информационной безопасности и обеспечению непрерывности бизнеса (business continuity planning, BCP).
При практической проверке проводится практический прогон ситуации возникновения DDoS-атаки и анализируется скорость и качество реализации требований регламента специалистами Заказчика и Интернет-провайдера.
Для полного приближения к ситуации может использоваться имитация реальной DDoS-атаки на указанные ресурсы Заказчика. Объемы генерируемого во время атаки трафика рассчитываются таким образом, чтобы максимально использовать пропускную способность каналов связи с Интернет.
В ходе работ могут использоваться как dumb-bot – примитивные систем генерации трафика, и эффективные решения (smart-bot), эмулирующие поведение стандартного сетевого клиента и агента DDoS, что затрудняет блокирование атаки средствами защиты от DDoS.

понедельник, 1 июня 2009 г.

План проверок по ФЗ 152

В сообществе personal_data появилась удобная выборка из плана проверок РКН по теме персональных данных.
Проверки разбиты по месяцам, что облегчает поиск:

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

Удобно :)

Исходные данные:

http://www.rsoc.ru/main/directions/contr/

пятница, 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


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

четверг, 23 апреля 2009 г.

Закрыли Radarix

Вот такое объявление:

Ресурс закрыт в соответствии с конвенцией совета Европы "О ЗАЩИТЕ ФИЗИЧЕСКИХ ЛИЦ ПРИ АВТОМАТИЗИРОВАННОЙ ОБРАБОТКЕ ПЕРСОНАЛЬНЫХ ДАННЫХ"

И редирект по ссылке на http://www.fsb.ru/.

Все серьезно.

Кто не знает:
http://www.securitylab.ru/opinion/353448.php

Материалы Рускрипто 2009

Началась публикация материалов конференции.

Презентации:

http://ruscrypto.ru/conference/download/

Видео:

http://rutube.ru/tracks/tag.html?t=ruscrypto





Официальные отзывы:

http://ruscrypto.ru/conference/testimonials/

http://osp.ru/cw/2009/13/7692589/

Неофициальные отзывы:

http://securityaudit.blogspot.com/2009/04/2009.html

http://matros0ff.ya.ru/replies.xml?item_no=1418

среда, 22 апреля 2009 г.

ЗПД всех устал

http://cnews.ru/news/top/index.shtml?2009/04/22/345142

Российские банки просят Роскомнадзор перенести сроки аудита информационных систем персональных данных на соответствие закону 152-ФЗ. На проверки нет ни денег, ни времени, утверждают они; кроме того, в законе имеются некоторые противоречия. Игроки рынка инфобезопасности, в свою очередь, предупреждают, что на фоне законодательного хаоса отсрочка не решит проблему, а лишь отодвинет ее на неопределенный срок.

Понятно, что "регулируемым" (в основном банкам) вся эта беготня с ЗПД в текущей ситуации совершенно не вовремя, а интеграторам и производителям очень даже наоборот.
Думаю, что идея "отложить" имеет право на жизнь. Только откладывать надо не аудиты, а карательные меры. Аудиты пускай как-раз идут. Наработается методика, компенсационные контроли и т.д., может и требования нормальные сформируются.
Как делает PCI Security Standards Council с PCI DSS - требования вводят очень осторожно, давая достаточно времени на подготовку и аудиторам и производителям СЗ и интеграторам и "регулируемым". И это при том, технологическая и методическая обвязка PCI DSS на две головы выше чем ЗПД, взять хотя бы пресловутое "четырехкнижие".

понедельник, 20 апреля 2009 г.

Microsoft SIR. Россия в лидерах!

Microsoft опубликовала очередной отчет Security Intelligence Report.

Россия среди лидеров по проценту зараженных компьютеров:



У нас метрика заражений на 1000 запусков "чистилки" составляет 21,1, тогда как среднемировой показател 8,6.
Очень странный показатель.

Возможно он плотно связан с вероятностью заражения различных платформ:



Думаю, ни кто не будет удивлен, что у большинства домашних пользователей стоит XP SP0, SP1, который "боятся" обновлять, чтобы не "слетела" крякнутая активация. Хотя тогда откуда у них Malicious Software Removal Tool? Не на дискете же "мастер" принес? Скорее уж что-то от Касперского или DrWeb.

Странно все это. Неужели корпоративщики?

PS. Вообще - удивительный отчет.

В России наиболее распостраненная угроза - Taterf, распространяющийся через общие папки, в USA - Win32/Renos и Win32/Zlob. Про Conficker написано очень много, но первых строчках статистики он отсутствует.

Чудеса?

"Взлом" смартфонов через WAP-push

Очередное громкое заявление о "взломе" телефонов с помощью SMS. При детальном рассмотрении роликов http://www.securitylab.ru/news/378096.php оказывается, что "хакеры" используют вполне легальный механизм WAP-Push для внесения изменений в реестр. Странно, что не закидывают троян, ведь с помощью WAP-Push можно легко загрузить cab (для Windows) или SIS (для Symbian) и запустить его.

Все это очень страшно, НО!
По умолчанию WAP-Push сообщения должны быть подписаны или приходить через фиксированный шлюз:

http://msdn.microsoft.com/en-us/library/ms889564.aspx

http://technet.microsoft.com/en-us/library/cc182289.aspx

; SL Message Policy
; (default: SECROLE_PPG_TRUSTED)
[HKEY_LOCAL_MACHINE\Security\Policies\Policies]
"0000100c"=dword:800

; SI Message Policy
; (default: SECROLE_PPG_AUTH | SECROLE_PPG_TRUSTED)
[HKEY_LOCAL_MACHINE\Security\Policies\Policies]

"0000100d"=dword:c00
Что в переводе означает, что стандартная политика безопасности требует аутентификации WAP-Push шлюза.

Я допускаю, что некоторые производители устройств могли ослаблять политику безопасности. И в принципе, это нехорошо. Хотя случается:

http://www.youtube.com/watch?v=QhJ5SgD-bdQ

PS. Надо побаловаться с Nokia и "китайским сертификатом".

PSS. А для перехвата WiFi и так есть достаточно приемов, например:

http://www.securitylab.ru/analytics/287596.php
http://www.securitylab.ru/analytics/312606.php

В оригинале, правда, отключается SSL через WAP-Push, но если ты в незащищенной сети WiFi, то проще просто сделать MITM на SSL чем-нибудь а-ля Cain, заодно и Base64 расшифруется.

воскресенье, 19 апреля 2009 г.

РИФ+КИБ 2009

Пригласили сделать обзор Web-угроз на РИФ'е.
Планирую "зарелизить" 0-day, свежую статистику WASC (http://www.webappsec.org/projects/statistics/) за 2009 год. Официальный релиз планируется на первую декаду мая.

http://ok2009.ru/program/?type=group&gid=22.17001900&id=230

воскресенье, 12 апреля 2009 г.

Безопасность и жизнь

Вылетал недавно из Домодедово, много думал.



Думы мои были тяжелы. Надеюсь только в Британии и только на подводных лодках.

PS. Если кто-то не узнал - Symantec - Kido/Conficker/Downadup.

среда, 8 апреля 2009 г.

Про консалтинг. Классика

Развернулась нешуточная дискуссия о выступлении Михаила Хромова (Лукойл-Информ) на Рускрипто по вопросам консалтинга:

https://www.blogger.com/comment.g?blogID=4065770693499115314&postID=4943265668225200494

На этом фоне вспомнилась классика.

Про розы и кактусы

Может, пригласить консультантов? А это мысль. Говорят, около столичного офиса есть пара вполне приличных компаний...
И каких! Весь цвет мирового управленческого консалтинга находился от офиса «Уникака» на расстоянии одной остановки на такси. Тут были «Туалет и Душ», «Кто Подставил Михаила Горбачева», «ПолицайУытерносКомупамперс», «Большая Консалтинговая Группа», «Молодой&Честный», «Международные Большие Машины» и «Оракул».

Консалтинг/не консалтинг, отечественный/зарубежный по ИБ или не по ИБ... Какая разница?

пентесты и Пентесты.. Я в шоке

Попался на глаза опус:

http://www.iso27000.ru/blogi/aleksandr-astahov/pentest-stoit-li-ovchinka-vydelki


Я в шоке, мой ноутбук в шоке и даже игрушечная собачка моего сына в шоке.

Понимаю, если бы это было написано в 2000 году, когда зрелость российского рынка консалтинга была близка к нулю. Но сейчас... Все таки не зря на Рускрипто целая секция была практически повещена тестированию на проникновение (понимаю, что я уже делал слишком много анонсов, но подождите, в скором времени опубликуем презентации и даже видео некоторых выступлений).

И так, пройдемся по тезисам:


Польза от пентеста для заказчика заключается в следующем:

# возможность обнаружения и устранения одной или нескольких серьезных уязвимостей


В рамках пентеста обнаруживаются сотни проблем в безопасности и ошибок в реализации СУИБ, на устранение которых зачатую уходят годы. Примеры - недостаточная осведомленность сотрудников или ошибки в процессе защиты Web-приложений. Только сегодня проводили совместно с 1С-Bitrix представление их нового продукта - модуля проактивной защиты. Яркий пример компании, которую пентест подвиг не только на устранение уязвимостей, но и на изменение процессов (аудит исходного кода, создание штата разработчиков), и даже больше - к созданию собственного продукта в области безопасности - web application firewall.

Полезность пентеста для исполнителя состоит в следующем:

  • возможность заработать приличные деньги (пентест - услуга высокорентабельная)

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

Теперь о том, чего заказчик не получает от пентеста:

* объективной оценки защищенности своей корпоративной сети


Объективной оценки, господа, не дает ничего. Даже, простят меня, сертификация. Есть только уязвимости и вероятность реализации угрозы, полученные в рамках указанной модели угроз и бюджета. То, что уязвимости никто не обнаружил, не говорит о том, что её нет. Иначе бы Microsoft, тратящий миллионы и миллионы на безопасность, аудит кода, построение безопасных процессов разработки и т.д. и т.п., уже давно бы выпускал программы без уязвимостей. И мы бы забыли про вторые вторники...

идентификации и анализа всех существующих уязвимостей корпоративной сети, позволяющих судить об общем уровне защищенности (для успешного проникновения достаточно обнаружить лишь одну или несколько уязвимостей)

Процитирую свою небольшой кусок из тезисов к Рускрипто:

Цель пентеста в том, чтобы взломать

Цель пентеста в том, чтобы оценить эффективность существующей СУИБ и продемонстрировать наиболее яркие проблемные места в рамках выбранной модели злоумышленника, устранить которые требуется в первую очередь. Сам "взлом" только подручный механизм реализации основной задачи и может использоваться с различными целями. Например, для облегчения понимания результатов работ руководством или для развития хода работ, например прыжка их Интернет в ДМЗ, из ДМЗ в технологическую сеть и т.д. Если проводить работы с установкой на "взлом", то максимум к чему может привести тест, это обнаружение нескольких "страшных" уязвимостей, устранение которых может занять несколько минут или часов. И в такой ситуации пентест полностью оправдывает отношение как к фрагментарной, малоэффективной услуги.

# уверенности в том, что удалось устранить имеющиеся уязвимости и повысить защищенность систем (исполнитель продемонстрировал заказчику лишь один или несколько возможных сценариев проникновения, а сколько их еще может быть?)

Странный тезис. Уязвимости были устранены? Были. Защищенность была повышена? Несомненно. Исполнитель продемонстрировал только один сценарий? А что в ТЗ было написано? Поломайте меня как-нибудь?

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

Это вообще полный бред. Утечка регулируется соглашением о конфиденциальности. Ни один из вменяемых исполнителей не будет против, если в ходе работ будет присутствовать представитель заказчика. Более того, тесный контакт с заказчиком и согласование "ходов", это залог успешных работ. Я обычно даже люблю в ходе внутреннего теста "почитать лекции" о том, что я сейчас делаю, и как все это ловко у меня получается :) Или не получается :(

Обычный анализ защищенности корпоративной сети при помощи сетевых и хостовых сканеров, требующий куда меньше времени (и квалификации) от исполнителя и денежных затрат от заказчика, позволять получить куда как более полезные результаты, а именно:

* идентифицировать и проранжировать все имеющиеся технические уязвимости (по крайней мере те, о которых известно из доступных исполнителю источников)
* дать объективную оценку уровня защищенности систем заказчика и его адекватность
* разработать подробный план действий по устранению, либо смягчению всех имеющихся уязвимостей, а не только тех, которые использовались в ходе пентеста


Тут я теряюсь совершенно. Опять эта объективная оценка всплыла... Как пентест, в ходе которого используется пяток специализированных сканеров, дополнительных утилит для верфикации и эксплуатации уязвимостей, ручной анализ уязвимостей может дать худший результат, чем просто запуск сканера? Как сканер реализует задачи глубокой оценки защищенности Web или беспроводных сетей, или уровня оценки персонала? Мне не понятно.
Сканеры никто не отменяет, но за ними должен сидеть человек, который "делает пентест в голове", чтобы расставить приоритеты и эффективно устранять обнаруженные проблемы. Сами сканеры этого не могут. Хотя мы работаем над этим :)

Если вам нужен именно анализ защищенности, либо оценка рисков, тогда глупо заказывать пентест, т.к. заплатите вы намного больше, а требуемого результата в виде реального повышения уровня защищенности и уменьшения рисков не получите.

Еще раз - пентесты не стоят дорого. Так сложился рынок. Есть дорогие задачи, когда пентест может стоить на уровне аудита. Но как правило это задачи с большим объемом работ или с узкой специализацией (например пентест специфического приложения). Более того, нормальный аудит, без которого невозможен нормальный анализ рисков, как правило включает в себя пентест. Где логика?

Я понимаю, что многим хочется быть Брюсом (http://www.schneier.com/blog/archives/2007/05/is_penetration.html), на повторять его спорные мнения не стоит.
Пентест, это одна из работ в области ИБ со своими плюсами и минусами, ограничениями, со своей методиками и целями. И зачастую с ожидаемыми результатами. Пугающими?...

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

Злобные украинские хакеры взламывают российские системы Интернет-коммерции :)

Не знаю, плакать или смеяться. MustLive зачем-то "задефейсил" страничку с книгой
Безопасность беспроводных сетей. Просто злобный хакер какой-то.




Совсем Web-хакеры в погоне за пеаром осторожность потеряли...

среда, 25 марта 2009 г.

Взломанны банкоматы крупнейших банков

Троян сохранял не только магнитную полосу, но и PIN. Это позволяет создать клон карточки и обналичивать в произвольном банкомате.

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

Сколько будет продолжаться эта эпопея с магнитными карточками? Всем на чипы!

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

CSO Summit II

Закончился Russian CSO Summit II (Второй Съезд директоров по информационной безопасности) http://www.cso-summit.ru/.
В этом году визуально было меньше участников. Видимо, сказалось пересечение по времени с другими меропрятиями.

В целом были все прошло достаточно динамично, с присущими этому меропрятию баталиями и спорами. В узком кругу коллег CSO и CIO явно чуствуют себя свободнее и не стесняются поднимать острые и щекотливые темы.

Презентации участников:
http://www.cso-summit.ru/?page=program


В рамках дискуссии «Реальная» и «бумажная» безопасность: как найти золотую середину? делал доклад по теме Compliance Management. Живой отклик вызвала "страшилочная" часть, в ходе которой комментировалась "почти реальная история pentest'а некой компании".



Из зала прозвучал достаточно типичный комментарий "Мы тоже делаем пентесты, и они успешны на 100% (99%, 83,463%)"

Зачастую такую фразу можно услышать на выступлениях или в кулуарах. Если понимать под "успехом” пентеста непосредственно "взлом", то тогда в качестве достоверной может быть выбрана любая из приведенных цифр. Но при такой постановке задачи гораздо проще воспользоваться ”сервисом" Брюса Шнаера, предлагающего любому желающему бесплатный пентест: "Вы уязвимы"... Если измерять пользу услуги, то она должна отталкиваться от того, что она принесла заказчику. Например, было продемострированно (не)соответсвие требованиям стандартов, внедрены Web Application Firewall, запущенна программа повышения осведомленности в вопросах ИБ, достигнуто понимание между ИТ и ИБ подразделением. Только в этом случае пентест может считаться действительно успешным.

Планирую подробнее обсудить эту тему в рамках Рускрипто:
http://www.securitylab.ru/news/370275.php

четверг, 19 марта 2009 г.

Webspider. Экспресс-анализ защищенности

Опубликовали на SecurityLab концепт-превью экпресс-сканера безопасности Webspider.
Webspider – это инструмент, позволяющий за считанные секунды проанализировать защищенность наиболее часто используемых злоумышленниками программных продуктов. Система ориентирована на экпресс-тестирование защищенности пользователей Internet- и Intranet- приложений, систем электронной коммерции и клиентов Интернет-провайдров.

Желающие протестировать, извольте:
http://www.securitylab.ru/addons/webspider3/fast_check.php



Текущая версия способна определить наличие уязвимости в популярных ActiveX компонентах и плагинах, браузерах Mozilla Firefox, Opera, приложениях Java и Adobe Flash, а также наличие на системе исправлений MS07-042, MS08-069 и MS09-002.

В апреле планируется публикация развенутой статьи об технологии.

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

Лаборатория безопасности Positive Technologies

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

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

среда, 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

четверг, 19 февраля 2009 г.

Сложно ли взломать сайт?

Как показывает наша статистика - квалифицированный человек сделает это с вероятностью 0,8...




Именно такова вероятность обнаружения уязвимостей высокой степени риска в ходе наших работ. Даже самому страшно.

Отрелизили статистику безопасности 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 даже в сетях, где беспроводные сети не используются. В связи с этим у специалистов в области безопасности возникает необходимость оценить не только качественные характеристики того или иного продукта, но и прогнозировать возможное негативное влияние от его внедрения на безопасность корпоративной сети.

В данной статье описываются результаты исследований систем обнаружения беспроводных атак с точки зрения специалиста в области безопасности приложений. Обнаруженные ошибки проектирования в статье не обсуждаются, поскольку их устранение требует от производителя существенных трудозатрат.

Резвые пользователи 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, как правило, содержит небольшое количество сигнатур. Настоящая работа таких систем начинается только после правильной настройки - создания черных и белых списков точек доступа и клиентов, привязка источников сигнала к карте, указания "правильных" протоколов и т.д. А в основе этого - инвентаризация, как базис любых процессов ИБ.

понедельник, 26 января 2009 г.

Риски, риски, риски...

Недавно, в ходе работ по анализу защищенности наткнулись на уязвимость Web-интерфейса управления одним UTM-устройством. Достаточно типичное сочетание CSRF и XSS примечательно тем, что через Web-интерфейс позволяет получить доступ к коммандной строке устройства и интерактивно "рулить" системой в браузере администратора. Но не суть, уязвимость типичная.
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php

Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:

Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:

  1. зависимость от контекста;
  2. зависимость от конфигурации системы;
  3. зависимость от метода определения.

В различных приложениях уязвимости одного типа могут иметь различную степень риска. Так, уязвимость «Подделка 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".

Вот такая она разная, оценка рисков.