Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог

Мелкодисперсный анализ кода

Аватар пользователя e.v.rodygin
Автор: Родыгин Евгений, Группа "Кронштадт"
(0)
()
Опубликовано в:

Здравствуйте друзья. Вот скажите. Случалось ли вам наблюдать такие события. Некий хакер находит уязвимость в коде и машет флагами что белому свету конец и все такое? Уверен что приходилось. В связи с этим хочу рассказать вам про Мелкодисперсный анализ кода ((с) swan) которым грешит большинство хакеров. Давайте на конкретном примере. Итак у нас есть программный комплекс который состоит из двух частей: Программа х86 и веб-морда. Программный комплекс работает так: в веб-морде пользователь вводит параметры, параметры передаются программе х86 которая их обрабатывает. Так вот в программе разработчик реализовал такую штуку: в переменную из 8 байт попадает параметр из веб-морды, программа на основе переменной производит переадресацию по адресам в таблице.
Тут появляется хакер и выясняет, что программа имеет таблицу только для двух байт. Явная уязвимость! Например, если в переменную попадает символьное число 00-99  то все в порядке, но если попадает символьное 199 то таблицы для этого значения нет и программа терпит крах с плохо предсказуемыми последствиями.
Хакер получил свое и радостно машет флагами!
Но не тут то было! Дело в том, что веб-морда при получении значения от пользователя проверяет чтобы в соответствующее поле не попадали значения отличные от 00-99 и найденная хакером «уязвимость» не имеет смысла! Хакер не провел анализ межпроектных связей. Он применил Мелкодисперсный анализ без учета связей в программном комплексе! Все бы хорошо, но этим грешат и многие SAST! Выдавая массу warning или critical они мягко говоря ошибаются. Та же проблема при проведении анализа части исходного кода.
Но мы можем не только ругать за такие методы производителей! Мы можем ругать аудиторов, пентестеров и т.п. Потому как проблема Мелкодисперсного анализа распространяется не только на код внутри программного комплекса. Проблема справедлива и для отдельного программного компонента и для крупных информационных систем включая орг.меры и особенности их эксплуатации.
Важно помнить: наличие уязвимости на одном уровне абстракции не всегда ведет к уязвимости на другом уровне! Так же помним, уязвимость не всегда интерпретируется в угрозу для ИС в целом!
Вывод: указанный подход к анализу приводит к появлению целого пласта выявленных «уязвимостей», которые или некорректны или никогда не могут быть использованы.

Оцените материал:
Total votes: 207
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.