Анализ

Алоха , подписчики, с вами 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).

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