Utomatic Exploit поколения , как это звучит, автоматический способ создания эксплойтов уязвимостей в программе. Это известно как вызов AEG. В этом документе подробно описывается первая комплексная система для полностью автоматической генерации эксплойтов. Команда CMU сначала показывает, как генерация эксплойтов для атак на управление потоком управления может быть смоделирована как проблема формальной проверки, затем предлагает предобусловленное символическое выполнение (новый метод нацеливания на символическое выполнение) и, наконец, представляет общий подход для генерации рабочих эксплойтов.
Также здесь есть хорошая демонстрация.
термины
Прежде чем я опишу, как работает система, я хочу рассмотреть некоторые ключевые термины, которые важны для понимания статьи.
Предыстория и предыдущие попытки
Вот хорошая цитата из статьи:
Современное состояние генерации эксплойтов потока управления позволяет человеку очень серьезно задуматься о том, можно ли использовать ошибку. До сих пор автоматическая генерация эксплойтов, в которых автоматически обнаруживаются ошибки и генерируются эксплойты, не была полезна для реальных программ.
Эта статья утверждает, что автоматически генерирует последовательности перехвата потока управления
Анализ исходного кода: одного только анализа исходного кода недостаточно, чтобы сообщить о возможности использования потенциальной ошибки, поскольку обнаруживаются ошибки в отношении абстракций на уровне исходного кода: анализ исходного кода подобен прочесыванию в программе синтаксических ошибок, но вероятность их ошибки. Те, которые мы собираемся использовать, являются семантическими, те, которые возникают из-за ошибок в логике или недостатков в абстрактном уровне кода.
В качестве альтернативы можно рассмотреть анализ двоичного кода (посмотреть, что именно код делает на каждом этапе пути, где мы можем найти какую-то ошибку в логическом потоке), подробности уровня времени выполнения, кадры стека, адрес памяти и т. Д. Однако это не масштабируется.
Объединение анализа на уровне исходного кода и двоичного анализа
Это довольно новая концепция, поскольку она сочетает в себе использование анализа исходного кода, который найдет конкретные ошибки, которые приведут к ошибочному выполнению, с неким семантическим смыслом / логикой посредством бинарного анализа. Обратите внимание, что оба метода ранее существовали, но сама мысль о том, чтобы их расчесывать, является новой. Кроме того, код будет работать для данной системы, а не только для конкретного куска кода.
Теперь, когда у нас есть некоторый пригодный для использования код, нам нужно найти пригодные для использования пути среди бесконечного числа путей, которые может использовать код. Программы могут иметь циклы, что означает, что они могут иметь бесконечное количество путей.
Вот где выдержан символическое исполнение вступает в игру. Условное символьное выполнение аналогично прямому символьному выполнению в том, что оно постепенно исследует пространство состояний для поиска ошибок, однако условное символическое выполнение принимает дополнительный параметр. Это уступает пути приоритизации пути.
Учитывая некоторый предикат (он же «дополнительный параметр»), который спрашивает пользователя, какой конкретный эксплойт он хочет выполнить, соединение предиката эксплойта будет накладывать ограничения на окончательное решение. Если окончательные ограничения не выполнены, мы считаем эту ошибку неиспользуемой.
Техника приоритизации пути - сначала используйте эвристику, чтобы выбрать наиболее подходящие пути
Почему это выгодно? Раньше у нас было бесконечное количество путей, по которым мы итерировали, пока не нашли что-то, что, возможно, имело эксплойт. Используя технику расстановки приоритетов, мы можем вместо этого пройти через конечное число путей, сосредоточившись сначала на наших более потенциальных путях.
Хорошо, теперь к фактическому процессу (из статьи):
Поиск ошибок на уровне исходного кода путем изучения путей выполнения ( выполняет iwconfic с использованием символических аргументов в качестве входных источников )
Следуйте по пути, обнаруживает ошибку «за пределами» или «память за пределами» по некоторой переменной.
AEG Решает текущие ограничения пути и генерирует конкретный ввод, который вызовет обнаруженную ошибку
Выполните динамический анализ двоичного файла iwconfig,используя входные данные из шага 2
Создайте ограничения, описывающие эксплойт, используя информацию из шага 3
Результаты
Их AEG удалось найти два эксплойта нулевого дня для ранее неизвестных уязвимостей. Их AEG также смогли обнаружить такие ошибки «в считанные секунды», что является довольно удивительным результатом.
Критические Проблемы
Во-первых, эта статья действительно технически сложна и трудна для понимания из-за ее сложности. У меня было много проблем с пониманием этого, и я полагался на моего консультанта и коллег, чтобы помочь мне понять это. Я до сих пор не думаю, что я полностью понимаю это.
Во-вторых, здесь нет ссылок на эвристику. Они упоминают использование эвристики, которая определена как некоторое практическое решение, которое не оптимизировано / рационально, но работает, фактически не указывая их ссылки для выбора упомянутой эвристики. Это немного подозрительно, но их результаты кажутся многообещающими.
Мой друг отметил, что если запуск занимает всего 1 секунду, почему бы не запустить больше тестов. Тем более, что это такая шокирующая статья, почему бы просто не запустить сотни или тысячи тестов, чтобы подтвердить, что AEG обязательно сработает? Большинство примеров в статье также посвящены проблемам памяти.
Следующие шаги
Есть еще проблемы, такие как создание AEG, который генерирует эксплойты непосредственно из двоичного файла. Другие проблемы включают в себя повышение производительности, масштабируемости и т. Д. Еще один момент, который авторы отметили, - это расширенные эксплойты. Они говорили о расширении AEG для обработки переполнений на основе кучи. Проблема здесь состоит в том, чтобы расширить рассуждения о потоке управления, чтобы также учитывать структуры управления кучей. Я хотел бы закончить цитатой из статьи, которая хорошо написана, хотя и техническая.
Мы также не утверждаем, что AEG является «решенной» проблемой; всегда есть возможность улучшить производительность, масштабируемость, работать с большим количеством классов эксплойтов и работать в новых настройках приложения.
Первоисточник
Также здесь есть хорошая демонстрация.
Прежде чем я опишу, как работает система, я хочу рассмотреть некоторые ключевые термины, которые важны для понимания статьи.
- Сквозная система. Как это ни звучит, сквозная система - это система, которая будет делать все, начиная от анализа исходного кода и заканчивая генерацией входных данных для эксплуатации системы. AEG анализирует исходный код, генерирует символьные формулы выполнения, решает их, выполняет бинарный анализ и генерирует определенный конкретный эксплойт, который вы хотите выполнить.
- Двоичный анализ: оценка угрозы и тестирование уязвимости на двоичном уровне. Смотрите здесь для получения дополнительной информации.
- Поток управления Hijack: эксплойты потока управления позволяют злоумышленнику выполнить произвольный код (или любой другой) на компьютере.
- Условное символическое выполнение: новая техника, которая нацелена на пути, которые с большей вероятностью могут быть использованы. Например, исследуйте только пути с максимальной длиной ввода или пути, связанные с запросами HTTP GET. Обратите внимание, что большинство путей в этой статье имеют дело с проблемами памяти
- Символическое выполнение: формальная методика проверки, которая исследует пути программы и проверяет, пригоден ли каждый путь
- Shell: пользовательский интерфейс для доступа к сервисам вычислительной системы.
- Как работает AEG:
- TL; DR: AEG находит ошибки, определяет, является ли ошибка уязвимой, если это так, генерирует строку эксплойта угонщика рабочего потока управления. Затем строка может быть напрямую передана в уязвимое приложение для получения оболочки.
Предыстория и предыдущие попытки
Вот хорошая цитата из статьи:
Современное состояние генерации эксплойтов потока управления позволяет человеку очень серьезно задуматься о том, можно ли использовать ошибку. До сих пор автоматическая генерация эксплойтов, в которых автоматически обнаруживаются ошибки и генерируются эксплойты, не была полезна для реальных программ.
Эта статья утверждает, что автоматически генерирует последовательности перехвата потока управления
Анализ исходного кода: одного только анализа исходного кода недостаточно, чтобы сообщить о возможности использования потенциальной ошибки, поскольку обнаруживаются ошибки в отношении абстракций на уровне исходного кода: анализ исходного кода подобен прочесыванию в программе синтаксических ошибок, но вероятность их ошибки. Те, которые мы собираемся использовать, являются семантическими, те, которые возникают из-за ошибок в логике или недостатков в абстрактном уровне кода.
В качестве альтернативы можно рассмотреть анализ двоичного кода (посмотреть, что именно код делает на каждом этапе пути, где мы можем найти какую-то ошибку в логическом потоке), подробности уровня времени выполнения, кадры стека, адрес памяти и т. Д. Однако это не масштабируется.
Объединение анализа на уровне исходного кода и двоичного анализа
Это довольно новая концепция, поскольку она сочетает в себе использование анализа исходного кода, который найдет конкретные ошибки, которые приведут к ошибочному выполнению, с неким семантическим смыслом / логикой посредством бинарного анализа. Обратите внимание, что оба метода ранее существовали, но сама мысль о том, чтобы их расчесывать, является новой. Кроме того, код будет работать для данной системы, а не только для конкретного куска кода.
Теперь, когда у нас есть некоторый пригодный для использования код, нам нужно найти пригодные для использования пути среди бесконечного числа путей, которые может использовать код. Программы могут иметь циклы, что означает, что они могут иметь бесконечное количество путей.
Вот где выдержан символическое исполнение вступает в игру. Условное символьное выполнение аналогично прямому символьному выполнению в том, что оно постепенно исследует пространство состояний для поиска ошибок, однако условное символическое выполнение принимает дополнительный параметр. Это уступает пути приоритизации пути.
Учитывая некоторый предикат (он же «дополнительный параметр»), который спрашивает пользователя, какой конкретный эксплойт он хочет выполнить, соединение предиката эксплойта будет накладывать ограничения на окончательное решение. Если окончательные ограничения не выполнены, мы считаем эту ошибку неиспользуемой.
Техника приоритизации пути - сначала используйте эвристику, чтобы выбрать наиболее подходящие пути
Почему это выгодно? Раньше у нас было бесконечное количество путей, по которым мы итерировали, пока не нашли что-то, что, возможно, имело эксплойт. Используя технику расстановки приоритетов, мы можем вместо этого пройти через конечное число путей, сосредоточившись сначала на наших более потенциальных путях.
Хорошо, теперь к фактическому процессу (из статьи):
Поиск ошибок на уровне исходного кода путем изучения путей выполнения ( выполняет iwconfic с использованием символических аргументов в качестве входных источников )
Следуйте по пути, обнаруживает ошибку «за пределами» или «память за пределами» по некоторой переменной.
AEG Решает текущие ограничения пути и генерирует конкретный ввод, который вызовет обнаруженную ошибку
Выполните динамический анализ двоичного файла iwconfig,используя входные данные из шага 2
Создайте ограничения, описывающие эксплойт, используя информацию из шага 3
Результаты
Их AEG удалось найти два эксплойта нулевого дня для ранее неизвестных уязвимостей. Их AEG также смогли обнаружить такие ошибки «в считанные секунды», что является довольно удивительным результатом.
Критические Проблемы
Во-первых, эта статья действительно технически сложна и трудна для понимания из-за ее сложности. У меня было много проблем с пониманием этого, и я полагался на моего консультанта и коллег, чтобы помочь мне понять это. Я до сих пор не думаю, что я полностью понимаю это.
Во-вторых, здесь нет ссылок на эвристику. Они упоминают использование эвристики, которая определена как некоторое практическое решение, которое не оптимизировано / рационально, но работает, фактически не указывая их ссылки для выбора упомянутой эвристики. Это немного подозрительно, но их результаты кажутся многообещающими.
Мой друг отметил, что если запуск занимает всего 1 секунду, почему бы не запустить больше тестов. Тем более, что это такая шокирующая статья, почему бы просто не запустить сотни или тысячи тестов, чтобы подтвердить, что AEG обязательно сработает? Большинство примеров в статье также посвящены проблемам памяти.
Следующие шаги
Есть еще проблемы, такие как создание AEG, который генерирует эксплойты непосредственно из двоичного файла. Другие проблемы включают в себя повышение производительности, масштабируемости и т. Д. Еще один момент, который авторы отметили, - это расширенные эксплойты. Они говорили о расширении AEG для обработки переполнений на основе кучи. Проблема здесь состоит в том, чтобы расширить рассуждения о потоке управления, чтобы также учитывать структуры управления кучей. Я хотел бы закончить цитатой из статьи, которая хорошо написана, хотя и техническая.
Мы также не утверждаем, что AEG является «решенной» проблемой; всегда есть возможность улучшить производительность, масштабируемость, работать с большим количеством классов эксплойтов и работать в новых настройках приложения.
Первоисточник