вторник, 20 августа 2013 г.

Скрестить ужа с ежом/найти все-все 0day/захватить вселенную!11

Краткое содержание

несовместимость DAST/SAST; IAST - buzzword и реальность;третий путь;меньше скобок

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



У нас один и тот же разъем?...

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


Вот, как-то так оно и работает...

Однако вскоре стало понятно, что достоинство подобного подхода преувеличены. Дополнительные точки входа, передаваемые из SAST в DAST без понимания контекста (или дополнительных условий в нашей терминологии) зачастую приводит только к увеличению продолжительности работы. Представьте себе, что SAST обнаружил и передал в DAST 10000 комбинаций URL и параметров, но 9990 из них требует авторизации. Если SAST при этом не «объяснит» DAST, что авторизация нужна и как эту авторизацию проходить, то сканер будет бестолково стучаться по этим URL и время его работы увеличится в 1000 раз. Без особого изменения результата.
Но это не самое главное. Основной проблемой является несовместимость DAST и SAST по входу/выходу. Ведь в большинстве случаев на выходе статического анализатора вы получаете информацию «строке 36 недостаточная фильтрация ввода, а значит и XSS». Для DAST же родным будет HTTP-запрос а-ля /path/api?parameter=[XSS]&topic=important, с указанием типа уязвимости, и, желательно – множеством значений для фаззера с учетом фильтрующих функций.



Где-то тут XSS… Надо передать его в DAST! Но как?

Обратите внимание также на важный параметр «topic=important». Это как-раз то условие, которое необходимо соблюсти, чтобы фаззер попал в нужное, уязвимое API. Ведь не факт, что уязвимость также присутствует в параметре при обращении к пути /path/api?parameter=[XSS]&topic=other. Откуда статический анализатор возьмет эту информацию? Не ясно…
Дополнительных сложностей добавляют различные модули, а-ля mod_rewrite, фреймворки, настройки веб-сервера и прочие элементы, вносящие путаницу в.
В общем – не взлетело.

Hybrid theory

Второй подход был связан с появлением в индустрии buzzword IAST (Interactive или даже Intrinsic Application Security Testing). По сути, это расширение динамического анализа, заключающееся в трассировке выполнения серверной части приложения [в ходе фаззинга с использованием DAST]. Для этого используется либо инструментация веб-сервера, фреймворка или исполняемого кода, либо встроенные механизмы трассировки.


Хранимая XSS и ее трассировка SpyFilter

Так, для поиска SQL Injection очень удобно использовать результаты SQL Server Profiler или схожие утилиты, где можно воочию увидеть, что же реально «долетело» до сервера через фильтрующие функции.


Похоже, я опять сделал немножко IAST…

После того как dynamic taint analysis IAST в очередной раз пришел в индустрию AppSec, у него возникло множество одептов, превозносящих достоинства метода. К ним можно отнести возможность увеличить эффективность динамического анализа путем отслеживания распространения запросов фаззера через разные уровни приложения, что позволяет минимизировать ложные срабатывания и отлавливать например double blind SQL injection. Кроме того, инструментация на различных уровнях приложения дает возможность выявлять отложенные атаки, такие как stored XSS или second order SQL Injection, перед которыми традиционно пасуют и SAST и DAST.
Важно, что этот метод позволяет решить задачу URL-to-source mappings, т.е. соответствия между точками входа приложения и сроками исходного кода. Все это не просто, и делается в три этапа, и сервер надо инструментировать, но как-то делается.


Гибридный анализ, взгляд HP (RAST=IAST)

Однако у IAST есть и понятные недостатки. В первую очередь, это необходимость инструментации кода и/или установки агента для динамической инструментации веб-сервера/СУБД/фреймворков. Ясно, что такая ситуация (не) всегда (не) применима для промышленных систем и вызывает понятные вопросы с точки зрения совместимостям и производительности.
Кроме того, IAST в его текущем понимании, является расширением DAST (что, кстати явно указывает Gartner) и наследует не только положительные, но и отрицательные стороны этого метода. Ходят, конечно слухи о pure IAST, но это скорее в сторону Application IDS/Firewall, который может и уязвимости выявлять при удачном стечении обстоятельств (о чем я тоже скоро расскажу).
Возвращаясь к теме заметки, использование в качестве промежуточного звена IAST позволяет отчасти решить проблему совместимости SAST и DAST, но лишь отчасти. Хотя, в некоторых случаях, особенно при годном SAST все может получится вполне неплохо.


Coverity + NTOSpider – better together!

Чуть подробнее критика «гибридного анализа» приведена в заметке Chris Eng «A Dose of Reality on Hybrid Analysis». Замечу, что многое из этой критики актуально и простой корреляции результатов SAST и DAST и для гибридного анализа с использованием IAST.

Call to arms

Видимая громоздкость подхода требует лучшего. И лучшее грядет, хотя еще не ясно, откуда выгрядет. Для него еще пока не придуман соответствующий buzzword, но в научных публикациях различие его аспекты встречаются все чаще и чаще. Суть его заключается в решении задачи совмещения статического и динамического анализа без необходимости в промежуточном звене. Т.е. суть остается той же, но при этом статический анализ, как потенциально более полный, используется в качестве основного. Для решения этой задачи SAST должен иметь возможность подготавливать данные для верификации в «понятном» для DAST формате, например в формате HTTP-запроса, с указанием необходимых дополнительных условий и множеством значений параметров для фаззинга.  Например, так.



Эксплойт, бэкдор и два ствола доп. условие

Или так.




Тут double blind SQLi, нужен time-based...

Как этого достичь, тема отдельной заметки, но ничего невозможного здесь нет. Кстати, такой подход позволяет реализовать еще одну задачу – интеграцию SAST с Web Application Firewall, что весьма и весьма полезно для быстрого закрытия обнаруженных уязвимостей.


PS. Чтобы не сложилось ложное впечатление, автор совсем не против IAST, а даже за. Некоторая резкость, это реакция на заявления типа «I>S+D!» и проч. У этой технологии есть понятная ниша, кроме того, она позволяет реализовать концепцию continuous monitoring, что нонче вполне модно. Но, для получения результатов, сходных с IAST совершенно необязательно фаззить все приложение, а иногда нет необходимости его исполнять в прямом смысле этого слова. Но об этом, как уже было сказано – позже.

На вопрос, «доктор, где вы такие картинки берете», отвечу прямо – да, реклама. Positive Technologies Application Inspector

Комментариев нет: