Атоматическая генерация эксплойтов на основе патчей

 

 

 

 

 

 

 

Курсовая работа

на тему

"Атоматическая  генерация эксплойтов на основе  патчей"

 

 

 

 

 

       Студентка группы ИУ10-61 

             (Подпись, дата)                           (И.О. Фамилия)

 

           Руководитель курсового проекта 

                             (Подпись, дата)                      (И.О. Фамилия)

 

 

 

 

 

 

 

Москва, 2015 

Содержание:

 

 

1. Введение

 
2. Автоматическая генерация эксплойтов на основе патчей: определение проблемы и подход.

2.1 Определения 
 2.2  Задача автоматической генерации эксплойтов на основе патчей.

2.3  Границы задачи и подход.

 
3. Автоматическая генерация эксплойтов на основе патчей

3.1 Вычисление различий двух бинарных кодов используя готовые инструменты

3.2 Генерация формулы ограничений

3.2.1 Ключевые моменты разработки 
  3.2.2 Создание формулы ограничений из образца исполнения

3.2.3 Создание формулы ограничений из CFG

3.2.4 Создание формулы с помощью комбинирования статического и динамического подхода

   3.3 Генерирование потенциального эксплойта из формулы ограничений

3.4 Генерирование полиморфных эксплойтов

 3.5 Подтверждение потенциального эксплойта

 

4. Оценка

4.1 Описания уязвимостей и эксплойтов

4.2 Генерация эксплойта с использованием динамического анализа

4.3 Генерация эксплойта с использованием статического анализа

  4.4 Генерация эксплойта с использованием комбинированного анализа

 

5. Заключение

 

6. Ссылки

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 Введение

 

На первый взгляд, выпуск патча, устраняющего уязвимость, может принести безопасности только пользу. Однако, нужно учитывать все время, в течение которого распространяется патч. Новый патч раскрывает некоторую информацию, и получение раннего доступа к патчу может дать злоумышленнику преимущество. С точки зрения безопасности, следует учитывать: 
a) какая информация о потенциально неизвестных уязвимостях раскрывается в патче,  
b) как быстро эта информация может быть получена из оригинальной и из пропатченной программы,  
c) какие преимущества эта информация даст атакующему.

 

Задача автоматической генерации эксплойтов на основе патчей (APEG)  состоит в следующем: дана программа P и пропатченная версия программы P ′ , нужно автоматически сгенерировать эксплойт для потенциальных неизвестных уязвимостей присутствующих в P но исправленных в P ′. Успешная APEG покажет, что атакующий может использовать патч для создания эксплойтов. APEG ранее не была продемонстрирована в литературе. Таким образом, вопрос, осуществима ли APEG для реальных программ, остается без ответа.

 

В данной работе будет показано, что автоматическая генерация эксплойтов на основе патчей возможна, как продемонстрировано в экспериментах с использованием пяти программ Windows которые недавно были пропатчены. Не утверждается, что предложенный метод работает во всех случаях или для всех уязвимостей. Однако, главная его задача -  дать примерную оценку возможностей злоумышленников. Предполагая это, APEG следует считать возможным для практического применения.

 

Важное следствие полученных результатов состоит в том, что получение доступа к патчу дает значительное преимущество над тем, у кого нет доступа к патчу. Преимущества в безопасности очень важны в свете нынешней практики распространения патчей, которая растягивает распространение на час, день или дольше. Например, такие исследователи как Кристос Гкантсидис и другие, показали, что Центру обновлений Windows требуется около 24 часов чтобы 80% уникальных IP-адресов были проверены на наличие патча.

All inputs	Safe Inputs

 

 

Рис 1.

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

 

Входные данные подтверждающие уязвимость. Как показано на рис. 1, безопасные входные данные являются подмножеством всех входных данных P. А разность этих множеств является набором входных данных эксплойтов. Общий подход для исправления таких уязвимостей это добавление дополнительных проверок в P , чтобы только безопасные входные данные могли обрабатываться дальше.

 

Рис. 2 показывает типичное целочисленное переполнение. Этот пример был выбран исходя из реальной уязвимости в Internet Explorer. Все целочисленные значения в этом примере занимают 32 бита, и более того, все вычисления производятся по модулю 232. В строке 1, целочисленная переменная input проверяется на четность: если это так, временной переменной s присваивается         input+2 (mod 232), если нечетное, то         input+3 (mod 232). Строка шесть вызывает realloc, шаблон ручного управления памятью, который изменяет размер в ptr чтобы указать на выделенные s биты памяти. Например, если s меньше чем размер, который в настоящее время указан ptr, Затем в результате указатель будет указывать на меньшую площадь памяти.

В этом примере, определяются любые входные данные, вызывающие переполнение во 2-ой или 4-ой строке как эксплойты. Таким образом , набор входных значений, являющихся эксплойтами, лежит в диапазоне 232 − 3 ≤ input ≤ 232 − 1. В лучшем случае, любой эксплуатации вызовет после 6-ой строки DoS- атаку, или в худшем случае, позволит атакующему захватить контроль над программой. Пропатченная P ′ добавляет проверки на переполнение в 5-ой строке. Любые входные данные, являющиеся эксплойтами для P не пройдут эти проверки в P ′ .

 

P :   i n p u t   i s   a  u s e r   i n p u t

 

1 . i f ( i n p u t %2 == 0 ) g o t o 2 e l s e g o t o 4 ; 
2 . s : = i n p u t + 2 ;

 

3 .   g o t o   5 ;

 

4 . s : = i n p u t + 3 ; 
5 . <nop>

 

6 . p t r : = r e a l l o c ( p t r , s ) ; 
7 . . . u s e o f p t r . . . ;

 

P ′ :   i n p u t   i s   a  u s e r   i n p u t

1 .	i f ( i n p u t %2  ==  0 )   g o t o  2  e l s e   g o t o   4 ;
2 .	s  : =   i n p u t + 2 ;

 

3.	g o t o	5 ;
4 .   s  : =		i n p u t + 3 ;
5 .	i f   ( s  >  i n p u t )   g o t o  6  e l s e   g o t o  ERROR ;
6 .	p t r   : =   r e a l l o c ( p t r ,   s ) ;
7 .	. . .   u s e  o f   p t r   . . .

 

Рис 2.

 

 

Проблемы. Одна из проблем APEG состоит в том, что программное обеспечение часто доступно только в бинарной форме. Таким образом, в предложенном подходе и реализации, мы нацеливаемся на случай, когда P and P ′ представлены в виде двоичного кода. В нашей ситуации, P and P ′ могут быть как исполняемыми программами так и библиотеками. Обращение APEG к библиотекам важно, поскольку 
a) уязвимость библиотеки может быть использована множеством программ, использующих библиотеку  
b) на многих ОС обновления безопасности часто выпускаются для библиотек. Например, была проведена проверка патчей, выпущенных Microsoft в 2006 году и обнаружено, что 84% обновлений, связанных с безопасностью, были изменениями в библиотеках. Если P является библиотекой, то сгенерированный эксплойт Х - действительный набор аргументов для экспортируемой (например, вызываемой) функции в библиотеке, в то время как, если P - программа, то Х - входные данные программы.

Другая проблема - выделить, какие изменения произошли между P and P ′. Чтобы решить эту проблему, был разработан инструмент, такой как bin-diff [33] и EBDS [13], которые сначала дизассемблируют P и P ′ , и затем определяют, какие инструкции были изменены.

 

Однако, недостаточно просто обнаружить инструкции, которые были изменены между P и P ′ . Для того, чтобы APEG была возможной, нужно решить сложнейшую проблему автоматически стоящихся входных данных, которые используют уязвимости в оригинальных не пропатченных программах. Более того, важно знать скорость (когда это возможно) с которой эксплойты могут быть сгенерированы из патчей в целях разработки достаточной защиты.

 

Обзор подхода. Предложенный подход к APEG основан на наблюдении, что ошибки входных данных обычно исправляются добавлением отсутствующих проверок. Добавленные проверки P ′ определяют 
a) где есть уязвимость 
b) в каких условиях входные данные могут воспользоваться уязвимостью. Предположение для нашего подхода заключается в том, что входные данные, которые не проходят добавленных проверок в P ′ вероятно являются эксплойтами для P . Цель:

1) Определить проверки, добавленные в P ′  
2) автоматически сгенерировать входные данные которые не пройдут добавленных проверок. На рис. 2, Цель в том, чтобы сначала обнаружить проверку, добавленную в 5-ой строке, затем сгенерировать значения для input, которые не пройдут проверку и вызовут состояние ERROR.

Назовем пути выполнения программы, при которых новая проверка не проходится в P ′ эксплойтными путями. И все входные данные, при которых программа пойдет по этому пути будут. вероятнее всего, являться эксплойтами для P . Может быть много путей эксплойтов, например, есть 2 пригодных пути кода в нашем текущем примере. Однако, количество путей с эксплойтами обычно лишь малая доля от всех возможных путей исполнения программы.

 

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

 

Обзор результатов. Для оценки эффективности предлагаемого подхода, были проведены эксперименты, используя 5 программ от Microsoft. Каждая программа изначально имела серьезную уязвимость безопасности, которая была исправлена с помощью патча. Результаты показали, что каждый из трех предложенных подходов полезен для различных уязвимостей. В каждом случае мы можем сгенерировать эксплойт обычно в течение нескольких минут. Наименьшее время генерации эксплойта менее 30-ти секунд. Вполне вероятно, что при дальнейшей работе над данным исследованием прототипа, это время будет уменьшено.

 

В оценке результатов, для случаев, когда публичный proof-of-concept эксплойт становится доступным, эксплойты, которые мы сгенерировали часто отличаются от тех, которые публично описаны. Также в работе будет продемонстрировано, что возможно автоматически сгенерировать полиморфные варианты  эксплойта. Наконец, можно автоматически генерировать эксплойты для уязвимостей, которые раньше не имели опубликованных эксплойтов.

 

Актуальность. Эта статья показывает, что автоматическая генерация эксплойтов из патчей в течение нескольких минут следует рассматривать с практической точки зрения. Существующая система распространения патчей не разработана с учетом угрозы автоматической генерации эксплойтов. Полученные результаты предполагают, что следует незамедлительно начать переосмысление существующей системы, и с этой целью, предлагается несколько направлений исследований.

 

Не смотря на то, что данная работа сосредоточена на случае, когда APEG используется злоумышленниками, APEG также может быть полезна для разработчиков систем безопасности. Например, после того, как APEG демонстрирует, что ошибка может быть использована для атаки, это может быть использовано поставщиками для исправления ошибки.

 

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

 

• Автоматическая генерация эксплойтов на основе патчей: определение проблемы и подход.
• 2.1 Определения
• Программа определяет отношения между начальным и конечным пространствами состояний. Пространство состояний программы состоит из всех переменных и памяти. Все регистры моделируются как переменные, и каждая ячейка памяти также можно считать отдельной переменной, когда это удобно. На рис. 2, пространство состояний состоит из памяти и переменных s и input. При желании, мы можем также различать переменный по месту их обновления, например переменная s в строке 2 и s в строке 5.
• Политика безопасности φ - логическое утверждение из пространства состояний программы имеющее одно из двух значений: safe или unsafe. В нашей ситуации, мы будем рассматривать только политики безопасности осуществляемые через контроль выполнения. На высоком уровне, такие политики позволяют оценить логическое выражение в пространстве состояний программы на каждом этапе выполнения, а также отслеживать все предыдущие состояния. Общий контроль за исполнением политики безопасности включает динамический анализ заражения, проверка целостности адресов возврата, и динамический тип принуждения.
• Обозначим исполнение программы P с исходными данными x как P (x), и исполнение инструкции i как Pi (x). Мы обозначили проверку политики безопасности на этапе выполнения i как φ(Pi (x)). Точка уязвимости это первая инструкция i такая, что φ(Pi (x)) = unsafe.
• Термин эксплойт используется для обозначения входных данных x для которых политика безопасности возвращает значение unsafe. Например, если мы используем политику динамического анализа заражения, эксплойтом будут любые входные данные вызывающие предупреждения при анализе. Одна из причин, почему мы используем это определение эксплойта - оно не предполагает конкретных целей атак, например раскрытие информации, отказ сервиса или захват контроля. Это имеет смысл в данном контексте, так как уязвимость сама по себе определяет, возможны ли такие специфические атаки. Следует обратить внимание, что потенциально есть много различных эксплойтов, каждый из которых является  полиморфным вариантом.
• Политики безопасности являются достаточно мощными чтобы указать конкретные виды атаки когда это нужно. Например, можно указать политику безопасности, которая нарушается только атакой с целью захвата контроля. Например, можно создать политику безопасности в которой говорится, что адреса возврата в стеке не должны быть перезаписаны входными данными пользователя. Такая политика безопасности может быть нарушена только типичным переполнением буфера для захвата контроля.
• Граф потока управления (CFG) G = (V, E) это граф, где каждая вершина ∈ V это прямолинейный участок кода, и есть дуги (i1, i2) ∈ E если есть возможность передачи управления от инструкции i1 к i2. Путь исполнения это набор вершин в графе потока управления такой, что для каждой вершины существует дуга к следующей вершине в CFG (Заметим, что вершины могут повторяться).