Анализ
ValterАлоха , подписчики, с вами Valter. Ранее мы уже говорили о причинах возникновения уязвимостей ( https://telegra.ph/Bezumnyj-tehprocess-09-10). причинами возникновения уязвимостей являются ошибки проектирования, реализации и эксплуатации. Но как их обнаруживают?
Анализ алгоритма программно-аппаратного обеспечения. Данный метод используется в основном для поиска уязвимостей проектирования. Примером практической реализации может служить система PVS (Prototype Verification System), разработанная в Computers Science Laboratory института SRI (http://pvs.csl.sri.com/ ).
На практике часто выполняется поиск ошибок реализации (кода), осуществляемых с помощью следующих методов.
Динамический анализ безопасности приложения. Одним из наиболее простых и распространенных при поиске уязвимостей реализации является DAST (Dynamic Application Security Testing) - динамический (т. е. требующий выполнения) анализ безопасности приложения без доступа к исходному коду и среде исполнения серверной части. Другими словами, анализ приложения методом «черного ящика».
В этом контексте довольно часто используется термин «фаззинг» (fuzz testing, fuzzing). Данный метод предполагает изучение поведения ПО с помощью подачи на вход различных значений переменных. Чаще всего это граничные или маловероятные значения, которые могут создать условия, приводящие к переполнению буфера, выходу за границы массивов, записи в недопустимые области памяти и т. д.
множество инструментов, позволяющих автоматизировать процесс поиска уязвимостей методом фаззинга, например:
• MiniFuzz (www.microsoft.com);
• FileFuzz (labs.idefense.com/software/ fuzzing.php).
Элементы фаззинга присутствуют в популярном инструменте эксплуатации уязвимостей metasploit. Механизмы фаззинга в том или ином виде встроены в сетевые сканеры безопасности. Например, в популярном сканере XSpider имеется очень простой «фаззер» для сетевых приложений (FTP, SMTP и т. д.)
множество инструментов, позволяющих автоматизировать процесс поиска уязвимостей методом фаззинга, например:
• MiniFuzz (www.microsoft.com);
• FileFuzz (labs.idefense.com/software/ fuzzing.php).
Статический анализ безопасности приложения. Этот подход подразумевает синтаксический и семантический анализ исходного текста, анализ конструкций, иногда делаются попытки построения алгоритма по исходному тексту. В некоторых случаях может использоваться дизассемблирование с последующим анализом полученного кода. В любом случае данный метод не требует выполнения приложения и предполагает доступ к его исходным кодам.
Часто этот метод называют SAST (Static Application Security Testing) - статический (т. е. не требующий выполнения) анализ безопасности приложения с доступом к исходному коду (или производным, например, байт-коду) приложения. В противоположность методу DAST SAST можно назвать анализом методом «белого ящика».
Наиболее популярный объект проверки методом SAST - это wеb-приложения, так как получить исходные коды для них обычно не вызывает затруднений.
Несмотря на то что есть ряд инструментов, позволяющих автоматизировать поиск «слабых мест» на основе исходного текста, данный метод используется достаточно редко. Анализ результатов такого поиска предполагает знание языков программирования, а существенное число ложных срабатываний требует дополнительной «верификации» найденных уязвимостей.
В качестве примера инструмента поиска уязвимостей в исходном тексте можно привести продукт Application Inspector компании Positive Technologies.
Дополнительно следует отметить, что в приведенном продукте верификация найденных уязвимостей может осуществляться с помощью автоматически сгенерированного эксплойта, что существенно облегчает в дальнейшем взаимодействие с разработчиками уязвимого кода.
Смешанный анализ безопасности приложения. В общем случае данный подход предполагает запуск приложения (как в DAST) и «наблюдение» за его действиями (вызванными подачей на вход различных данных).
Проверке могут подвергаться:
• корректность выполнения операций с памятью;
• корректность работы с указателями;
• вызовы потенциально «опасных» функций;
• «движение» данных.
В большинстве случаев подход основан на модификации анализируемого приложения: встраивании в определенные участки анализируемой программы специального кода или меток для трассировки. По сути, его можно применять даже на этапе разработки приложения, а механизмы могут встраиваться в отладчики и компиляторы. В качестве примера можно привести утилиту Неар Agent (http://www.microquill.com/ heapagent/ index.html), встраиваемую в компиляторы Microsoft Visual С++jVisual Studio.
Такой вариант анализа приложения I A S T ( I n t e r a c t i v e A p p l i c a t i o n S e c u r i t y Testing) называют динамическим анализом безопасности приложения с доступом к исходному коду и среде исполнения серверной части. Это смешанный подход, предполагающий запуск приложения (как в DAST) и доступ к его исходным текстам (как в SAST).
На этом подведём заключающую черту нашей сегодняшней статьи. Теперь вы понимаете что анализ безопасности приложения не такой уж и простой «однокнопочный процесс» как это кажется на первый взгляд. Всем спасибо за внимание, удачи 🍀