вторник, 19 июня 2012 г.
Рунет в осаде: взломан каждый десятый крупный сайт
Ссылка: http://www.cnews.ru/reviews/index.shtml?2012/06/19/493446 и мультики по теме.
А devteev.blogspot.com не показывает свое лицо и взламывает корпорацию Potato. Вот так-то.
пятница, 8 июня 2012 г.
PHP более "дырявый" чем ASP.NET?
На самом деле все не так. На самом деле вероятность найти уязвимость в приложении на PHP гораздо проще найти уязвимость при соблюдении следующих условияй:
— вы анализируете приложение российских компаний из топ 100
— в вашем поле зрения наиболее бизнес-критичные системы, доступные из Интернет (именно с ними связаны основные риски, именно их и заказывают)
— вы честно признаетесь, что не можете найти ВСЕ уязвимости. Поскольку ограничения методики, которая не дает гарантии, да и все мы люди-человеки.
К сожалению других чисел у нас нет. То, что делает WASC и Whitehat Security чуть менее адекватно, поскольку содержит либо смесь черного и белого ящика (WASC), либо только черный с ручной верификацией (Whitehat).
Из highlighs - на 10% всех сайтов мы встречали вредоносное ПО либо закладку под его установку. Т.е. кто-то там уже был.
Вот такие вот пироги. Подробнее:
Русский
English
среда, 2 февраля 2011 г.
Истинная цена Compliance
Расходы организаций, не соблюдающих правила информационной безопасности, в среднем превышают расходы организаций, их соблюдающих, в 2,65 раза, подсчитали аналитики из Ponemon Institute.
http://hitech.newsru.com/article/02feb2011/moresafe
http://www.tripwire.com/ponemon-cost-of-compliance/pressKit/True_Cost_of_Compliance_Report.pdf
Смело заявление. Надо покурить методику.
четверг, 5 августа 2010 г.
Обзор инцидентов: Verizon Breach Report 2010
Опубликован обзор инцидентов Verizon Breach Report 2010. Рекомендую.
http://www.verizonbusiness.com/go/2010databreachreport/

PS. В отчете широко используется WASC WATCv2. Приятно.
PPS. Без комментариев:
вторник, 25 мая 2010 г.
Статистика уязвимостей Web 2009
В этом году были проанализированы данные о 5560 веб-приложениях протестированных специалистами компании Positive Technologies в ходе предоставления консалтинговых и сервисных услуг по информационной безопасности, таких как тесты на проникновение, анализ защищенности в рамках стандарта PCI DSS и мониторинг защищенности внешнего периметра с использованием системы MaxPatrol.
Практически половина проанализированных систем содержали уязвимости. Суммарно во всех приложениях было обнаружено 13434 ошибок различной степени риска, зафиксировано 1412 образцов вредоносного кода, содержащихся на страницах уязвимых систем. Доля скомпрометированных сайтов распространявших вредоносное программное обеспечение составила 1,7%. Каждый из таких сайтов содержал уязвимости, позволяющие выполнять команды на сервере, что подтверждает возможность использование этих уязвимостей для компрометации системы.
Основной результат исследования неутешителен. Вероятность обнаружения критичной ошибки в веб-приложении автоматическим сканером составляет около 35% и достигает 80% при детальном экспертном анализе. Этот факт демонстрирует невысокую защищенность современных Web-приложений не только от атак со стороны квалифицированных злоумышленников, но и от действий атакующих, вооруженных готовыми утилитами для «автоматического взлома».
Как и ранее, наиболее распространенными ошибками, допускаемыми разработчиками приложений, являются уязвимости «Межсайтовое выполнение сценариев» и «Внедрение операторов SQL» на которые пришлось более 19% и 17% всех обнаруженных уязвимостей соответственно.
С точки зрения соответствия требованиям регуляторов (compliance management) ситуация улучшилась незначительно. До 84% веб-приложений не удовлетворяет требованиям стандарта по защите информации в индустрии платежных карт PCI DSS и 81% не соответствуют критериям ASV-сканирования, определенного в стандарте.
Сравнение результатов с отчетами предыдущих четырех лет показал, что ситуация со степенью защищенности веб-приложений в 2009 в целом улучшилась. Так, анализ устранения уязвимостей на 768 сайтах проверявшихся в 2008 и 2009 году показал, что более 60 процентов владельцев устранили все критичные уязвимости в течение года и существенно повысили защищенность своих ресурсах. В целом регулярный анализ защищенности веб-приложений и налаженный процесс устранения выявленных недостатков позволяют за год уменьшить число уязвимых сайтов в среднем втрое.
Ссылки: pdf html
вторник, 9 марта 2010 г.
Verizon опубликовал Verizon Incident Metrics Framework
Итересную новость опубликовал Verizon. В ответ на критику Data Breach Investigations Report был подготовлен опросник для обмена данными об инцидентах. Полезный документ, думаю, что компаниям, работающим в этой области стоит взять на вооружение.
Что приятного - в качестве классификации Web используется WASC WATCv2. Дополнительно - Verizon "вернул" группировку атак и уязвимостей по классам, чего мне очень не хватало во второй версии:
- Authentication
- Authorization
- Command Execution/Injection
- Abuse of Functionality
- Denial of Service
- Client-side
- Encryption
- Protocol Manipulation
- Miscellaneous
понедельник, 25 января 2010 г.
Иногда автоматизация вредна...
Данные, предоставленные Imperva - немного расходятся с действительностью. И не потому, что они где-то просчитались. Просто какой-то из продуктов, используемый для форматирования документа, заменил "неправильный" password на "правильный" Password и далее по всем "словарным" паролям.
Анекдотс.
понедельник, 19 октября 2009 г.
Статистика безопасности Web-приложений 2008
Русский вариант для загрузки.
WASC Web Application Security Statistics 2008 (Russian)
Публикация содержит обзорную статистику уязвимостей Web-приложений, полученную в ходе работ по тестированиям на проникновение, аудитов безопасности и других работ, проводимых Компаниями, входящими в консорциум WASC в 2008 году. Всего статистика содержит данные о 12186 сайтах, в которых было обнаружено 97554 уязвимости различной степени риска.
Дмитрий Евтеев опубликовал сравнение с нашей статистикой:

Забавно, но между русским (первоначальным, как вы могли догадаться) и "word-wide" есть некоторые различия. Для соблюдения политесу был выкинут раздел 4.3 - сравнение различных методик . Вот он, свободный демократический мир :)
понедельник, 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
воскресенье, 24 мая 2009 г.
Отчет о PCI Moscow
Из запомнившихся докладов:
"Безопасность банкоматов. Опыт борьбы с кибер-преступниками."
Иван Стригин, Системный инженер, Московское представительство компании «Диболд, Инк»
"Стандарты PCI DSS и СТО БР ИББС 1.0. Сходства и отличия"
Павел Гениевский, Секретарь Совета Сообщества ABISS
Иван раскрыл timeline "борьбы" со злобным вирусом, занимавшимся кражей данных пластиковых карт из банкоматов. И выразил неодобрение отсутствием координации разглашения со стороны антивирусных вендоров. Теперь не только исследователи уязвимостей стоят на тонком льду Full-Disclosure :)). Что хуже - антивирусных вендоров подталкивает мощная маркетинговая машина.
Организаторы обещают опубликовать материалы и презентации на сайте в течении недели.
Мой доклад - "Измеряя защищенность. Метрики безопасности для PCI DSS" ниже.
вторник, 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. Все в основном сводится к "пугалам", или пересказу основных требований стандарта. Хотя есть и редкие исключения. Например, доклад Максима Эмма по наиболее распространенным нарушением.
четверг, 23 апреля 2009 г.
Материалы Рускрипто 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
понедельник, 20 апреля 2009 г.
Microsoft SIR. Россия в лидерах!
Россия среди лидеров по проценту зараженных компьютеров:
У нас метрика заражений на 1000 запусков "чистилки" составляет 21,1, тогда как среднемировой показател 8,6.
Очень странный показатель.
Возможно он плотно связан с вероятностью заражения различных платформ:
Думаю, ни кто не будет удивлен, что у большинства домашних пользователей стоит XP SP0, SP1, который "боятся" обновлять, чтобы не "слетела" крякнутая активация. Хотя тогда откуда у них Malicious Software Removal Tool? Не на дискете же "мастер" принес? Скорее уж что-то от Касперского или DrWeb.
Странно все это. Неужели корпоративщики?
PS. Вообще - удивительный отчет.
В России наиболее распостраненная угроза - Taterf, распространяющийся через общие папки, в USA - Win32/Renos и Win32/Zlob. Про Conficker написано очень много, но первых строчках статистики он отсутствует.
Чудеса?
воскресенье, 19 апреля 2009 г.
РИФ+КИБ 2009
Планирую "зарелизить" 0-day, свежую статистику WASC (http://www.webappsec.org/projects/statistics/) за 2009 год. Официальный релиз планируется на первую декаду мая.
http://ok2009.ru/program/?type=group&gid=22.17001900&id=230
четверг, 19 февраля 2009 г.
Сложно ли взломать сайт?
Именно такова вероятность обнаружения уязвимостей высокой степени риска в ходе наших работ. Даже самому страшно.
Отрелизили статистику безопасности Web-приложений за 2008 год.
Это уже третий релиз:
2008
2007
2006
В этом году в качестве исходных данных использовались результаты анализа 59 Web-приложений различными жестокими методами от fuzzing до dynamic source code analysis и более чем 10000 сайтов, расположенных на Хостинг-Центре РБК, которому мы (и MaxPatrol) помогаем оказывать услугу "Проверка Безопасности Сайта".
В первый раз в статистику вошли данные по обнаруженным последствиям "взлома", т.е. по тем сайтам, на которых MaxPatrol обнаружил вредоносный код, php-shell и т.п.
В этом году обнаружилась еще одна интересная аномалия. Это нереально большое количество SQLi (обнаружено в 68% всех сайтов при детальном анализе). Просто прорыв какой-то...
Вот такие жестокие цифры...
понедельник, 26 января 2009 г.
Риски, риски, риски...
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php
Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:
Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:
- зависимость от контекста;
- зависимость от конфигурации системы;
- зависимость от метода определения.
В различных приложениях уязвимости одного типа могут иметь различную степень риска. Так, уязвимость «Подделка HTTP-запроса» может не представлять угрозы для типичного репрезентативного сайта или поисковой машины, и наоборот – классифицироваться как проблема высокой степени риска в Web-интерфейсе электронной почты или платежной системы. В результате утечки информации злоумышленник может получить доступ к журналам работы приложения (низкая или средняя степень риска), а может загрузить резервную копию исходных текстов сайта (высокая степень риска).
Конфигурация конкретной системы также может оказывать серьезное влияние на степень риска. Так, уязвимость «Внедрение операторов SQL» обычно классифицируют как имеющую высокую опасность. Однако в случае если Web-приложение работает с сервером СУБД с ограниченными привилегиями, она может быть отнесена к проблемам средней или низкой степени риска. В другой инсталляции или реализации приложения эта же уязвимость может быть использована для получения доступа к операционной системе с правами суперпользователя, что естественно делает её наиболее критичной.
В зависимости от метода у глубины анализа степень одна и та же уязвимость может быть оценена по-разному. Если взять приведенный выше пример «Внедрения операторов SQL», использование сетевого сканера позволит только констатировать наличие проблемы. Для определения привилегий, доступных потенциальному злоумышленнику требуется либо попытаться использовать ошибку, либо уточнить порядок взаимодействия между Web-приложением и СУБД методом «белого ящика».
Т.е. крайне некорректно относить две различные уязвимости одного типа (например SQL Injection) к одной степени риска без детального анализа.
Привожу пример.
Предположим SQL Injection позволяет получить доступ к СУБД минимально необходимыми для Web-сервера привилегиями, например db_reader. Причем Web-приложение не хранит в СУБД конфиденциальной информации, например паролей.
Тогда вектор и степень риска CVSSv2 будет равены:
(AV:N/AC:L/Au:N/C:P/I:N/A:P/E:H/RL:W/RC:C) = 6.1
(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C) = 8.1
Если же Web-сервер работает с SQL-server с чрезмерными привилегиями, например sa, то эта же уязвимость будет гораздо более опасной:
(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5
Если перевести эти оценки к "светофорной" модели или 5 уровням, принятых в PCI DSS (Urgent, Critical, High, Medium, Low), то получим:
1. Средний (2) и High (3)
2. Средний (2) и Critical (4)
3. Высокий (3) и Urgent (>4).
Т.е. степень риска одной и той же уязвимости может серьезно меняться в зависимости от конкретной системы и её настроек.
Что же касается XSS с которого начиналась заметка, то ее вектор будет
(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9
Т.е. с точки зрения PCI DSS (а именно эту модель сейчас "модно" использовать) степень риска данной проблемы можно обозначить как High или даже Critical, а не Low. В любом случае, аудит провален :)).
ЗЫ. Хотя я могу понять вендора, ведь если безопасность не заложена в приложение изначально, то, цитирую: "hardening the management interface would probably imply a complete redesign of it".
Вот такая она разная, оценка рисков.
четверг, 18 декабря 2008 г.
Анализ рисков. Web-приложения
Но обилие порождает проблему выбора и определения применимости тех или иных иточников в конкретной ситуации.
Статья Оценка рисков использования Web-приложений касается этой проблемы в контексте Web-приложений.
Полагаю, что собранные в ней данные и источники будут полезны для широкого круго специалистов.
