Сразу скажу, что эта заметка скорее обучающая, для новичков, чем отвечающая на конкретные вопросы. Для экспертов в ИБ заметка будет, наверное, капитанством.

В заметке мы ограничимся только сканерами, работающими с веб-приложениями методом черного ящика: т.е. сканер взаимодействует с веб-приложением так же, как и типичный пользователь, через веб-интерфейс по сети по протоколу HTTP(S).

В целом, если говорить о задаче сравнения сканеров веб-приложений, можно рассмотреть следующие задачи:

• сравнение функций сканеров;
• бенчмарк сканеров с целью определения эффективности их работы на самых различных видах веб-приложений (качество и скорость поиска уязвимостей);
• выбор сканера под нужды заданного владельца веб-приложений.

Сравнение функциональных возможностей

Первую задачу, в целом, понятно как решать. Методика сравнения функциональных возможностей сканеров такова: необходимо принять за основу сравнения некоторый контрольный список [1] возможностей идеального сканера и оценить пилотируемые инструменты на поддержку этих возможностей. Итогом является таблица, в строках которой перечислены критерии сравнения, в столбцах – инструменты, а в ячейках дана оценка каждому средству по данному критерию.

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

Бенчмарк эффективности сканеров

Со второй задачей возникают трудности. Методика сравнения эффективности сканеров вообще (без привязке к классу приложений или типам уязвимостей) является предметом споров и разногласий в сообществе и по сей день.

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

У описанного подхода есть два недостатка:

• указанные показатели зависят от тестовой выборки;
• такое определение эффективности является бесполезным с практической точки зрения.

Первый недостаток означает, что показателями эффективности при сравнении инструментов между собой можно манипулировать, включая или исключая из тестовой выборки для бенчмарка те или иные веб-приложения или уязвимости в них. Данное обстоятельство порождает отдельную нетривиальную задачу: как построить и доказать корректность тестовой выборки веб-приложений, чтобы это устроило все стороны сравнительного теста?

Второй недостаток требуется раскрыть подробнее. Рассмотрим в качестве примера следующую ситуацию: пусть сравниваются два сканера – А и Б; у первого сканера показатели эффективности на заданной выборке – (0.65, 0.01), а у второго – (0.35, 0.01). На первый взгляд, сканер А лучше сканера Б. Но на самом деле, без информации о том, как соотносятся множества обнаруженных сканерами уязвимостей, сделать вывод о победителе не представляется возможным. Например, сканер А мог обнаружить в тестовой выборке все уязвимости к атакам класса XSS и ни одной уязвимости к атакам других классов, а второй – все уязвимости к атакам класса SQL injection и ни одной уязвимости к атакам других классов; при этом 65 и 35 – это количественные характеристики тестовой выборки по классам уязвимостей к атакам XSS и SQL injection соответственно.

Отдельным важным фактором при сравнении эффективности сканеров является оценка эффективности их crawler’ов. Так как у автоматических средств сканирования первым этапом анализа является навигация по веб-приложению и определение точек ввода входных данных (DEP’ов, от “Data Entry Points”), плохие результаты на этом этапе существенно влияют на возможность найти уязвимости при тестировании найденных DEP’ов. Так, например, известны типичные проблемы сканеров при обходе современных веб-приложений класса SPA (Single Page Applications) и приложений, навигация по которым реализована исключительно через JavaScript. Подробнее про эти проблемы можно узнать из доклада на первой встрече OWASP Russia или из нашей статьи.

Выбор сканера для себя

Понимая особенности решения задач в первой и второй формулировках, стоит обратиться к третьей задаче: «как выбрать сканер под нужды владельца конкретных веб-приложений». И тут-то возникает вот это вот: «смотря для каких целей». Так как мы не рассматриваем задачу выбора сканера консалтинговыми компаниями в области ИБ, сосредоточимся на задачах владельцев веб-приложений.

Напомним, что с помощью сканеров веб-приложений можно обнаружить уязвимости следующих категорий:

1. Уязвимости этапа кодирования. Лучше всего среди уязвимостей этого типа обнаруживаются т.н. уязвимости, связанные с некорректной обработкой входных и выходных данных (англ. Injection Flaws, в т.ч. возможность SQL injection, возможность XSS и т.д.), а хуже всего – логические уязвимости.
2. Уязвимости этапа внедрения и конфигурирования приложения. К этим уязвимостям относятся некорректные настройки окружения веб-приложения: веб-сервера, сервера приложений, SSL/TLS, фреймворка, сторонних компонент, наличие DEBUG-режима и т.п.
3. Уязвимости этапа эксплуатации приложения. К этим уязвимостям относятся использование устаревшего ПО (не обновлённого веб-сервера, фреймворка, сторонних библиотек и т.п.), простых паролей, хранение архивных копий на веб-сервере в общем доступе, наличие в общем доступе служебных модулей (phpinfo) и т.п.

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

В ручном режиме оператор работает с анализируемым приложением через веб-браузер, который подключен к приложению через сканер как через промежуточный прокси-сервер. При этом оператор наблюдает все HTTP-запросы и HTTP-ответы в сканере и по своему выбору может на их основе составить и отправить необходимые тестовые запросы. При работе со сканером в таком режиме имеются следующие особенности: во-первых, предъявляются повышенные требования к квалификации оператора, во-вторых, оператору важно получить от сканера максимум удобных инструментов для автоматизации создания и отправки тестовых запросов и анализа ответов приложения на них. Типичными представителями указанного класса сканеров являются Burp Suite и ZAP Proxy.

В автоматическом режиме работы от оператора требуется только сконфигурировать параметры запуска сканера: указать URL приложения и логин/пароль пользователя (при тестировании закрытой части). Типичными представителями указанного класса являются инструменты HP WebInspect, Acunetix и т.п.

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

Рассмотрим типичные сценарии использования сканеров:

1. Запуск в процессе тестирования веб-приложения в тестовом окружении для обнаружения уязвимостей этапа кодирования. Варианты:
   1. запускается службой ИБ при приемке веб-приложения, разработанного на заказ сторонним подрядчиком;
   2. запускается службой ИБ после прохождения очередного релиза приложения, разрабатываемого внутри компании, всех тестовых процедур;
   3. запускается тестировщиками веб-приложения во время тестовых процедур;
   4. запускается службой ИБ по инициативе (тикету) разработчиков (например, после добавления новых элементов в графический интерфейс).
2. Запуск после разворачивания новой версии веб-приложения в продукционной среде для обнаружения уязвимостей этапа конфигурации. Варианты:
   1. запускается службой ИБ перед подписанием бумажки а-ля «ввод в эксплуатацию разрешаю»;
   2. запускается службой эксплуатации (администраторами/девопсами) в рамках соблюдения регламента по безопасному вводу в эксплуатацию новых релизов/приложений.
3. Периодическое сканирование веб-приложения в продукционной среде для обнаружения уязвимостей этапа эксплуатации. Обычно запускается на периодической основе службой ИБ для внутреннего контроля соблюдения политик администрирования ИТ-ресурсов.

Зачем были перечислены эти сценарии? Каждый сканер (и режим работы) предъявляет определенные требования к оператору. Квалификация важна при выборе режима работы сканера, при конфигурировании запусков сканера, при интерпретации результатов (ложное или неложное срабатывание, критичность неложного срабатывания).

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

1. Автоматизируемость запуска (например, наличие интерфейса командной строки или API) и возможность внедрения в процесс непрерывной интеграции (CI).
2. Воспроизводимость результатов сканирования: на одной и той же сборке анализируемого приложения прогон средства должен давать стабильные результаты.
3. Удобство перепроверки: сканер должен предоставлять возможность проверить, была ли исправлена известная уязвимость в новом релизе (желательно без полноценного прогона), а также классифицировать найденные уязвимости на новые или вновь открывшиеся старые.

Резюме

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

1. Функциональное сравнение сканеров сделать методически несложно. Имея список функциональных критериев, можно сравнительно недорого получить оценку соответствия этим критериям для каждого инструмента из списка на выбор.
2. Бенчмарк сканеров – это не то, на что следует ориентироваться при выборе средств. Признанных бенчмарков нет.
3. Важными шагами при выборе сканера для себя будут:
   1. определение сценария использования сканера и оценка требуемой квалификации оператора;
   2. определение существенных функциональных требований к сканеру и сравнение инструментов по существенным критериям (примеры таких критериев – возможность запуска через CLI, возможность интеграции с такими-то ИТ-системами, поддержка многопользовательского режима работы и т.п.);
   3. оценка поддержки сканером веб-технологии вашего приложения; примеры веб-технологий, где это будет иметь значение:
      1. GWT и прочие технологии с нетривиальным способом передачи параметров серверу или менеджментом сессий;
      2. RIA и SPA-приложения, а также веб-приложения, интерфейс которых существенно динамический (т.е. его нельзя обойти, статически анализируя код веб-страниц);
      3. приложения, требующие реализации на клиенте нестандартных криптографических примитивов (см. системы класса ДБО).
   4. наличие специальных профилей сканирования под различные веб-технологии (т.е. фаззинг GWT надо проводить по одной стратегии, а приложения на ASP.NET Web Forms – по другой).

p.s. Спасибо за фидбек по заметке Денису Колегову, Алексею Синцову, Георгию Носеевичу и Сергею Герасимову.

[1] Список, например, составляется на основе комбинации критериев, перечисленных в проектах «Web Application Security Scanner Evaluation Criteria» и «OWASP Web Application Scanner Specification Project».

Факультет ВМК МГУ имени М.В. Ломоносова в рамках XXIV Международной конференции-выставки «Информационные технологии в образовании» («ИТО-2014») приглашает учащихся 7-11 классов школ Москвы и Московской области принять участие в MOSCOW CTF 2014.

Мероприятие пройдёт на факультете ВМК. Для участия необходимо пройти процедуру регистрации на сайте http://ctf.cs.msu.su/. Задания ориентированы на школьников 7-11 классов. Количество участников в команде: 3-5 человек. Наличие у участников собственных ноутбуков приветствуется, но не является обязательным.

Подробности:
Дата: 9 ноября 2014 года.
Место: 2-ой учебный корпус МГУ.
Адрес:г. Москва, Ленинские горы, д. 1, стр. 52.
Продолжительность олимпиады: 5 (пять) астрономических часов.

Предварительное расписание и другую информацию можно найти на сайте: http://ctf.cs.msu.su/ и страничке ВКонтакте: https://vk.com/mskctfschool2014

Итак, дано:
Есть доступ в систему ДБО. Логин-пароль, вход подтверждается по SMS, вход возможен только при наличии eToken’а класса Aladdin Pro. Подпись документов, отправляемых в банк, происходит тоже с помощью ключей.

Требуется:
Организовать возможность доступа в систему ДБО в общем случае N удаленных людей.

Решение:
Вся инфраструктура в нашей локальной сети доступна удаленным пользователям через OpenVPN. В локальной сети поднимается виртуальная машина, в хост в USB вставляется eToken и подключается к виртуальной машине. На виртуальную машину устанавливается ПО USB over Network, которое позволяет подключить удаленное USB-устройство к локальной машине так же, как если бы оно было вставлено в локальный USB-порт. Далее eToken расшаривается для удаленного доступа, конечно с паролем.

Теперь SMS. Берется любой планшет или телефон на Android, ставится программа SMS Forwarder, в которой задается правило: все смс с такого-то номера отправлять на такие-то почтовые адреса. Android-устройство подключатся к WiFi-сети нашей инфраструктуры. Очевидно, в устройстве должна стоять та SIM-карта, на которую приходят одноразовые пароли.

Works like Charm.

p.s. Чего-то мне кажется, что всякие банковские трояны используют эту схему уже давно. Полагаю, спецы подтвердят.

Шаг 1. Берем статью 2010-2011 года близкой нам тематики из любого источника из списка ниже:
— https://seclab.cs.ucsb.edu/academic/publishing/
— http://www.iseclab.org/publications.html
— http://www.ieee-security.org/TC/SP-Index.html
— https://www.usenix.org/publications/proceedings
Пусть, например, мы выбрали статью про создание black-box сканера уязвимостей, который учитывает состояние веб-приложения: «Enemy of the State: A State-Aware Black-Box Web Vulnerability Scanner».

Шаг 2. Берем интересные нам статьи и ищем, кто за последние годы на них ссылался. Делается это так:
— либо ищем название статьи в Google Scholar и кликаем в выдаче «Cited By»; в нашем случае будет выдано 17 статей — http://scholar.google.com/scholar?cites=15644735933810005707
— либо ищем название статьи в portal.acm.org и переходим во вкладку «Cited By»; в нашем случае будет выдано 4 статьи — http://dl.acm.org/citation.cfm?id=2362793.2362819.

Шаг 3. Для каждой новой заинтересовавшей нас статьи из ссылающихся на исходную повторяем Шаг 2. Обычно рекурсия не заходит глубже второго уровня.

Шаг 4. Качаем выбранные статьи и читаем. Для тех, кто не в курсе, платные статьи можно скачать через http://sci-hub.org/.

Удачной охоты!

p.s. Буду благодарен за related типсы и триксы, если кто знает.

Но viam supervadet vadens. Любой же путь хорош привалами, на которых можно оглянуться назад, прикинуть, что впереди, поделиться с соратниками впечатлениями, послушать советов, пристроить путевые заметки в публикацию…

Вот уже в третий раз на форуме Positive Hack Days состоится огонёк для молодых ученых, Young School. Информацию по первому Young School можно найти вот тут, а по второму — вот тут.

В моем понимании, основной профит от участия в CFP, подобных нашему (т.е. с перекрестным анонимным рецензированием) — это _бесплатное_ получение квалифицированных рецензий на свою работу. Поверьте, чем раньше исследование попадает на оценку к непричастному человеку, тем лучше.

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

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

Правила конкурса опубликованы на офисайте форума. По всем вопросам можно смело писать на секретный ящик youngschool@phdays.com или задавать тут.

Хочу написать, почему сам я бы никогда не взялся сделать конфу, которая будет позиционироваться, как мега-хардкорная техническая конфа, русский BlackHat.
TL;DR — я вижу неустранимое противоречие в позиционировании и тактике формирования программной сетки.

Все остальное — мое мнение, которое, скорее всего, не будет совпадать с вашим на 100% =)

Что такое хардкорная техническая конфа с точки зрения активностей?

Хардкорные воркшопы, конкурсы с высоким уровнем вхождения участников, зона с недоступными в повседневной жизни девайсами (банкоматы, hardware village, lockpicking zone, etc.), секции с докладами. Все остальное (бар, Mortal Kombat и Atari, ток-шоу, ключевые докладчики) — важные атрибуты, но не вносящие вклад в слово «хардкорная».
Так вот, при вменяемом подходе (и мы это видели), у организаторов мероприятий в России нет никаких проблем с воркшопами, конкурсами и hack-зонами с мега-девайсами.

А вот как построить хардкорную секцию с докладами — непонятно.
Для меня критерий хардкорности секции — это т.н. премиум контент, который доносит докладчик. У премиум контента есть важное свойство: он является премиум только в процессе своего первого донесения до аудитории. После публикации/рассказа — это уже просто полезный справочный материал, который должен быть изучен любым экспертом из соответствующей предметной области.
Получается, что хардкорная конфа случится, если докладчики выдают свой качественный контент впервые.
Рассмотрим вопросы:
— если у российского исследователя есть премиум контент, какое CFP он предпочтет — российского мероприятия или западного?
— если у иностранного исследователя есть премиум контент, есть ли варианты, при которых он предпочтет CFP российского мероприятия?
Почему-то мне кажется, что мат ожидание ответа на первый вопрос будет «западного», а на второй — «только если ему уже дали reject’ы на других CFP». Причин тому масса, и виза — не последняя.

Выходит, при честном CFP вероятность роста числа заявок докладов с премиум-контентом от западных исследователей практически нулевая.

Как же тогда набирать программу?
Есть вариант обращаться к знакомым топовым исследователям и просить подготовить новый доклад к конференции за деньги, выступить опять же за деньги.
Второй вариант, который мы видели на ZN и PHD — приглашать с уже готовыми докладами, которые презентовались elsewhere.

Получается замкнутый круг:
1. Чтобы на CFP откликнулись ведущие исследователи с новыми темами, для них cost-benefit анализ должен завершаться в пользу российского мероприятия.
2. Для этого для иностранных исследователей плюсы должны превышать как минимум проблемы с визой и плюсы других аналогичных западных мероприятий. Если это не получаемое вознаграждение, а именно статусность мероприятия, то получаем п.3.
3. Как повышать статусность мероприятия при отсутствии денег (аудитория идет только на статусные мероприятия, спонсоры идут на массовые мероприятия), если для создания этой статусности не приезжают ведущие докладчики?

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

Т.е., резюмируя, как сделать реально хардкорную международную техническую конференцию в России — хрен его знает. Такие вот мысли.

Так как я человек впечатлительный и легко поддающийся на троллинг, решил написать своё ответное мнение в серии постов на тему «Типичный булшит в якобы аналитических заметках про технологии анализа исходного кода».

Итак, сегодня — первая серия, и поговорим мы вот про какие заявления (встречаются в произвольной комбинации): «сигнатурный анализ не может обеспечить полноту», «сигнатурный анализ дает много ложных срабатываний», «сигнатурный анализ хуже, чем анализ потоков данных», «анализ потоков данных дает офигительную полноту при низком числе ложных срабатываний», «о какой полноте может идти речь при наличии в базе N сигнатур» и вот это вот всё.

Для тех, кто испугался объема, сразу выводы:

1. Все применяемые сейчас вида анализа кода — сигнатурные (в т.ч. taint анализ на основе потоков данных).

2. В свете п.1. сравнивать подходы и продукты по количеству сигнатур — нонсенс. Сигнатура может описывать как целый класс недостатков (например, input validation), так и один-единственный экземпляр (unserialize($_GET[.*])).

3. Про полноту и точность можно говорить только после фиксирования класса недостатков (например, input validation). Полноты «вообще» — не существует. В свете разговора про каждый класс недостатков на первое место выходит формальная модель описания недостатка. По факту, сейчас почти всегда используется модель невмешательства (aka taint). Данная модель описывает только уязвимости класса input validation. Она бесполезна для недостатков авторизации. Полнота, говорите?

4. Даже в рамках одного класса недостатков, например, input validation, существующая модель невмешательства не может обеспечить не только полноту, но и даже приемлемую точность. Ограничения модели невмешательства расписаны вот тут (англ).

Итак, начнем.

В задаче анализа исходного кода просто необходимо выделять существенные составляющие.
Первая ключевая составляющая — это представление программы, на котором происходит анализ. Типичные представления будут такими: текст программы, поток лексем, дерево синтаксического разбора (AST), граф потоков управления (CFG), графы зависимостей по данным (SDG, PDG), набор состояний (например, значений переменных) в каждой точке, собранный бинарник.

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

Первый вывод: статический анализ на основе потоков данных — тоже сигнатурный (упс!!!). Действительно, для поиска недостатка необходимо специфицировать, какой подграф в графе программы надо найти. Для модели Non Interference (aka taint) это будет граф зависимости вида <получение данных от пользователя> -> <использование в критичной функции без предварительной обработки>. Но это же сигнатура!

Второй вывод: «о какой полноте может идти речь при наличии в базе N сигнатур» — бред с той точки зрения, что одна сигнатура может описывать как целый класс недостатков, так и вполне конкретный экземпляр недостатка. Соответственно, сравнение (и характеристика) подходов и продуктов по количеству сигнатур — нонсенс.

На этом месте справедливо было бы поставить такой вопрос: хорошо, но может представление прямо или косвенно влияет на выразительную силу сигнатур, которые для него создаются? Т.е., например, в представлении потока лексем нет понятия «зависимость», а следовательно нельзя формулировать и правила в терминах зависимостей; напротив, понятие «зависимость» — основа для представлений класса System или Program Dependence Graph, и там правила, использующие это понятие, будут работать.

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

Теперь давайте разберем этап формулирования искомых свойств. Логично, что недостатки объединяются в классы по схожести их проявления в коде. Соответственно, для класса схожих недостатков формулируется его модельное описание. Напомню, что про модели недостатков написано вот тут. Перейдем к рассуждения про полноту и точность.

[Manipulation mode on]
Любому здравомыслящему человеку должно быть очевидно, что полнота поиска уязвимостей вообще — бесполезнейшая характеристика, которую к тому же невозможно измерить. [Manipulation mode off]

В общем, меряться полнотой и точностью можно только в рамках зафиксированного класса недостатков. Например, в рамках класса input validation, или более гранулярного — sql injection, или класса другой категории — authorization flaws или memory leakage в контексте DoS. Давайте же зафиксируем класс и померяемся полнотой и точностью.

В посыле поста звучало про анализ потоков данных («анализ потоков данных дает офигительную полноту при низком числе ложных срабатываний»). Хорошо, зафиксируем класс недостатков input validation. Учитывая, что для описания этого класса используется модель невмешательства (aka taint), которая сформулирована в терминах зависимостей по данным, то недостатки этого класса просто созданы для анализа потоков данных! Ура! Полнота! Точность! Да, но нет.

Убыль в точности я отметил уже на этапе построения представления. Другая убыль в точности — это ограничения модели невмешателсьтва (подробности тут). Плюс, не забываем про убыль в полноте за счет невоможности поиска межмодульных уязвимостей (stored XSS, second order sql injection). Конечно, всегда, можно скатиться в 100% полноту, пометив все строчки недостатками, но этот вариант мы не рассматриваем.

В отличие от ортодоксального научного подхода к поиску недостатков класса input validation, есть еще рабоче-крестьянский, который практикуют многие аудиторы кода — регулярные выражения и grep. Тут кто-то должен сказать про работу из коробки vs необходимость эксперта. Да, но это уже тема совершенно другого поста. Если же говорить про сравнение по точности, регулярные выражения и grep очевидно способны зарулить подход на основе модели невмешательства и анализа потоков данных. В общем, как говорят у нас в МГИМО — for whom how.

Аннотация. Каждый месяц Фейсбуком пользуются больше людей чем жителей любой страны мира, за исключением Китая и Индии. Более того, эти пользователи проводят там порядка получаса каждый день, просматривая чужие или обновляя свои статусы, или просто «тусясь». Поэтому не удивительно, что социальные сети привлекают огромное внимание широкой и разносортной публики. К примеру, в 2011 активисты «Арабской весны» использовали социальные сети как средство коммуникаций, а в 2012 году американский президент Обама во время перевыборных собрал $690 миллионов через социальные сети. Не обошли стороной социальные сети и разного рода организации (коммерческие и правовые), которые, законно и не очень «проталкивают» свои услуги и товары, или собирают информацию по интересующих им пользователям. Такое множество заинтересованных лиц остро ставит интригующий и спорный вопрос безопасности и конфиденциальности в современных социальных сетях. В данной лекции будет проведён обзор международных исследований по этому вопросу, опубликованных за последние 5 лет. Материал лекции предназначен для широкой аудитории. Лекция будет на английском языке, вопросы и ответы могут быть на русском.

О лекторе:
Konstantin Beznosov, Associate Professor in Laboratory for Education and Research in Secure Systems Engineering, Department of Electrical and Computer Engineering, University of British Columbia

Био: http://konstantin.beznosov.net/professional/bio

Как обычно, для прохода в МГУ понадобится пропуск МГУ, либо можно пройти по паспорту, прислав предварительно мне (petandr на gmail.com) или Денису Гамаюнову (gamajun на cs.msu.su) полные фамилию, имя и отчество.

Судя по аннотациям докладов, ожидаются как выступления с научными результатами, так и с передачей опыта или суммы знаний по конкретным задачам предметной области (мои любимые типы докладов).

А вот и расширенная аннотация моего доклада.

Обнаружение уязвимостей логики приложений методом статического анализа: где правда, где реклама?

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

К типичным недостаткам относятся недостатки, возникающие вследствие некорректного использование какого-либо известного API, функций стандартной библиотеки, конструкций языка и т.д. Примерами типичных недостатков являются различные переполнения, уязвимости форматной строки, разыменование нулевого указателя, возможность внедрения операторов SQL (SQL injection), возможность внедрения кода на языке Javascript (XSS) и т.п. Для обнаружения подобных недостатков подходят известные модели, основанные на потоках данных (например, модель non-interference, которая после была адаптирована в т.н. taint analysis), или классические задачи статического анализа (например, анализ возможных значений переменных).

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

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

С методической точки зрения задачу поиска специфичных уязвимостей на западе решают в научных кругах (по крайней мере, для веб-приложения) с 2008 года. Достаточно привести в пример такие работы, как «Toward automated detection of logic vulnerabilities in web applications», «Static detection of logic flaws in service-oriented applications», «Static detection of access control vulnerabilities in web applications» и др. С практической же точки зрения дела обстоят намного интереснее: многие автоматизированные средства (статические анализаторы) поиска недостатков безопасности в коде заявляют, что умеют находить в приложениях не только типичные недостатки, но и специфичные.

В докладе будут кратко рассмотрены типы существующих статических анализаторов (сигнатурные/основанные на потоковых моделях/основанные на абстрактной интерпретации и др.) и представления программ, на которых они работают (текст/набор лексем/AST/граф потоков управления/граф зависимостей по данным/автоматы состояний приложения и др.). После этого будет проведена подробная аргументированная оценка справедливости их высказываний о своих возможностях по поиску специфичных недостатков безопасности в приложениях. Если кратко, то ни одно автоматизированное средство не может находить специфичные недостатки безопасности хоть со сколь-нибудь приемлемым качеством без серьезного участия оператора (например, аннотирования).

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

В 2012 года в рамках форума Positive Hack Days 2012 состаялась первая версия конкурса Young School. Небезынтересная статистика следует ниже.

Всего на конкурс поступило 19 заявок от резидентов следующих стран (порядок перечисления соответствует количеству заявок): Россия, Казахстан.

География заявителей по городам: Новосибирск, Санкт-Петербург, Москва, Красноярск, Таганрог, Костанай, Самара.

География заявителей по организациям: Новосибирский Государственный Университет, Московский государственный горный университет, Сибирский Государственный Аэрокосмический Университет им. М.Ф. Решетнева (СибГАУ), МИФИ, Таганрогский технологический институт Южного Федерального Университета, МГУ имени М.В.Ломоносова, Костанайский государственный университет имени Ахмета Байтурсынова, Самарский государственный аэрокосмический университет имени академика С.П. Королёв, Департамент информационных технологий ФГУП «ЦНИИ ЭИСУ» Министерства обороны РФ Москва, СПИИРАН.

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

В финал вышли 4 работы в конкурсной сетке и 4 интересные работы вне конкурса. Эти работы были представлены непосредственно на форуме. Кроме того, один из членов программного комитета, Павел Ласков из Дармштадского Технического Университета (Германия), выступил с результатами своего исследования по обнаружению вредоносных PDF-документов.

Победителями были признаны две работы (если кому интересно ознакомиться с этими работами, пишите — пришлю):
— работа Дарьи Кавчук (Таганрогский технологический институт ЮФУ) на тему «Метод оптимизации автоматической проверки уязвимостей удаленных информационных систем»;
— и работа Анастасии Щербининой (факультет ВМК МГУ) на тему «Обнаружение полиморфного шелл-кода на основе подобия».

Теперь коротко об удачах и неудачах (куда без них) первой версии.

Неудачи: неразбериха с объявлением победителей и вручением призов на церемонии закрытия форума; переносы сроков публикаций тезисов.

Удачи:
— высокое качество исcледований, представленных на форуме;
— успешное решение логистических и финансовых вопросов по доставке заявителей, их научных руководителей и рецензентов в Москву и на форум (это полностью заслуга Positive Technologies, которые сработали отлично);
— принятие ВСЕХ восьми отобранных работ к публикации в ВАКовском журнале «БИТ» (было повторное рецензирование ред. коллегией); это значит, что программный комитет также сработал на отлично; по словам редакции, тезисы будут опубликованы в первом номере 2013 года.

И вот теперь 2013 год и вторая серия конкурса Young School. Постараемся устранить все неудачи прошлого года, а также расширить и углубить прошлогодний список бонусов и плюшек.

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

p.s. Ходят слухи, что как и во всех академических CFP, дедлайн подачи заявок в самый последний момент отодвинут на две недели…