Ошибки в коде Windows и их патчи

[varwar]

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

1. Познакомить новичков с современными инструментами бинарного анализа на реальных примерах, а не синтетики
2. Учиться распознавать ошибки в коде на уровне ассемблера и декомпилятора
3. Решение проблем, связанных с ошибками самих инструментов бинарного анализа
4. Обмен опытом, какими-то трюками
5. Обсуждение решений автоматизации поиска багов и уязвимостей. Например, при помощи AST Hex-Rays'а или других инструментов
6. Учение на чужих ошибках

Я пойму тех, кто не захочет делиться своими "ноу-хау" и не требую сливать информацию, которую кто-то сможет за вас продать. Действуйте на свое усмотрение. Начну с простого бага, который нашел в драйвере cng.sys.

На скриншоте ниже кусок функции SymCryptHmacSha1ExpandKey, которая содержит патч (серый базовый блок). Ваша задача понять смысл патча. В качестве хинта добавлен скриншот с декомпилированным кодом, полученного с помощью Diaphora.

Спойлер: Результат Diaphora

В общем присылайте свои примеры. Скоро добавлю еще несколько.

 

[varwar]

Пожалуй недооцененной функциональностью является граф вызовов в BinDiff, который иногда позволяет довольно быстро обнаружить баг или уязвимость. Например Microsoft иногда патчит целочисленные переполнения путем добавления функций из ntintsafe.h. В графе вызовов этот паттерн может выглядеть таким образом: перед вызовом аллокатора или обертки, как в данном случае (над ExAllocatePoolWithTag) происходит безопасный подсчет размера буфера в методе RtlUShortMult.

 

[varwar]

Иногда Microsoft решает, что лишние вызовы ему не нужны и упрощает проверку. На скриншоте ниже вызов RtlUShortMult уже удален.

Однако, добавлена проверка на переполнение при умножении с максимальным 16-битовым числом - 0xFFFF.

 

[varwar]

Распространенный паттерн, когда при вызове аллокатора происходит подсчет размера в аргументе. Если отсутствует проверка размера одного из операндов, который затем в качестве размера передается в функцию копирования (в данном случае memmove), то может произойти целочисленное переполнение в результате которого выделится буфер маленького размера. На скриншоте ниже потенциальный баг в ядре Windows. К сожалению, его скорее всего невозможно стригеррить (было потрачено много времени на выяснение).

 

[isucukbx]

На скриншоте ниже кусок функции SymCryptHmacSha1ExpandKey, которая содержит патч (серый базовый блок). Ваша задача понять смысл патча. В качестве хинта добавлен скриншот с декомпилированным кодом, полученного с помощью Diaphora.

memove + check for null value => null pointer dereference exception => dos, угадал?Или можно до чего-то большего раскрутить такое?

Скажи как ты отслеживаешь где именно они тихо попатчили что-то?Берешь хеши всех файлов и сравниваешь до/после?
Я помню очень давно пользовался тулзой total uninstall для отслеживания изменений, но возможно есть более элегантные варианты(мб обертка под что-то из sysinternals)

 

[varwar]

memove + check for null value => null pointer dereference exception => dos, угадал?Или можно до чего-то большего раскрутить такое?

Не совсем. Проверка размера входящего буфера на неравенство нулю добавлена. В общем ничего злонамеренного с точки зрения повреждения памяти или обращения к невалидной памяти не происходит. Ключ, который далее должен хешироваться в итоге хешируется некорректно, но я не могу оценить импакт, ибо не криптограф. Эта ошибка встретилась в итоге в 3 или 4 похожих функций с постфиксом *ExpandKey, видимо тупо код копировали.

Скажи как ты отслеживаешь где именно они тихо попатчили что-то?Берешь хеши всех файлов и сравниваешь до/после?

Никак т.к. не вижу в этом нужды. Во-первых, это будет огромный объем данных и работы, который осилить можно разве что автоматикой и поверхностно, но тут опять же - получение диффа и фильтр будет занимать очень много времени. Diaphora 12 метров ядра у меня дифает около часа и чем больше различий между версиями ядра, тем этот процесс дольше (плюс зависит от того, какие эвристики в настройках используются). Тут речь даже не про сотни семплов, а про тысячи. Каждые 2 недели тысячи семплов анализировать по-моему нереально. Мне кажется разумнее взять контекст какой-нибудь технологии, например кому хочется найти RCE, то имеет смысл изучить TCP/HTTP-стек на уровне RFC и ковырять tcp.sys, http.sys какой-нибудь. Кто в графике шарит, тому будет проще ориентироваться в графической подсистеме. Вообще под 1-day писать эксплойты мне кажется сейчас нет смысла. Исключением может быть разве что какой-нибудь уязвимый third-party драйвер для реализации BYOVD-атак.

Вот что, например, писал Ian Beer из P0 об эксплойте под iOS и сколько времени на него потратил. Важный момент подчеркнул. Т.е. желательно знать область по отношению к которой хочешь что-то разрабатывать. Вроде очевидно, но...

This has been the longest solo exploitation project I've ever worked on, taking around half a year. But it's important to emphasize up front that the teams and companies supplying the global trade in cyberweapons like this one aren't typically just individuals working alone. They're well-resourced and focused teams of collaborating experts, each with their own specialization. They aren't starting with absolutely no clue how bluetooth or wifi work. They also potentially have access to information and hardware I simply don't have, like development devices, special cables, leaked source code, symbols files and so on.

И еще несколько важных мыслей о находке и процессе.

One of the ways I like to procrastinate is to scroll through this enormous list of symbols, reading bits of assembly here and there. One day I was looking through IDA's cross-references to memmove with no particular target in mind when something jumped out as being worth a closer look.

Having function names provides a huge amount of missing context for the vulnerability researcher. A completely stripped 30+MB binary blob such as the iOS kernelcache can be overwhelming. There's a huge amount of work to determine how everything fits together. What bits of code are exposed to attackers? What sanity checking is happening and where? What execution context are different parts of the code running in?

Т.е. вместо того, чтобы придумывать как дифать миллиард семплов просто берешь бинарь и начинаешь втыкать, изучая контекст работы параллельно (изучая документацию). Желательно технологию, которая тебе интересна и у которой есть поверхность атаки.