поиск 0day

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

Так вот вопрос, насмотревшись этих Trend-micro zeroday-intiative, google project zero и прочих, возникает вопрос, а какие инструменты они юзают для поиска дыр?

Неужели только одни фаззеры? Или он там на стимуляторах сидят? Они находят зеродеи каждый месяц, порой от одного и того же человека.

Как? Карл, как? Давайте делиться тут инструментами полезными для эксплойт-дев и поиска зеродеев.

 

Мне кажется, что прям вот методы нету иначе бы они не были 0day. Те не берем задачу диффов обновлений, а прям тру 0дэй если.

Например
https://bugs.chromium.org/p/project-zero/issues/detail?id=1540

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

Как мне кажется, это в сторону виндбг со своими плагинами, скриптами. Собирать например просто аномалию, чтобы схлопнуться в задаче до какого-то модуля/подсистемы/куска кода - но тут уже приходишь к задаче, что именно смотреть, непонятно)

Ну это имхо.

 

надысь смотрел WinAFL https://github.com/ivanfratric/winafl
нужно было функу в библиотеке профазить, написал свою прогу использующую эту библиотеку
нафазил в своей проге сдесяток кандидатов
начал тестить под отладчиком - ничего не подошло)
а идея WinAFL мне понравилась - тупой coverage-guided fuzzing

 

Ок, допустим. А это тоже реверс?

 

zerodawn,

> Как? Карл, как?

Статистикой. Производители софта собирают инфу по крэшам. Если ось слетела сотни тысяч раз, они все эти дампы имеют и их анализят. Не статистические методы есть, к примеру на вм известные люди https://twitter.com/j00ru мониторили дереференс указателей(RC) для всей ОС, это дало кучу уязвимостей, авторы опубликовали конечно же лишь не значительную их часть. Это по части автоматики, но это промежуточное решение, так как это просто отслеживание асинхронных выборок визором, тоесть просто наблюдали за всеми потоками.
Аналитического пути/решения нет. Я тоже потратил кучу времени на эту задачу, она тупиковая. В данный момент алгоритмически задача не резолвится.

 

Это разве не аналогично фаззингу? Смысл запускать операционку и ждать редких крашей? По-идее, надо ей что-то скормить в качестве входных данных?

Ну, ок, допустим. А люди из Trendmicro как находят дыры? Им же производители вряд ли дают некий API к их краш-репортам?

 

zerodawn, крашдампов у всех полно))) даже у них, я про трендмикро. но чето я соменваюсь, что прям это вот оно.

кстати кто тебе мешает напрямую написать яну биру и спросить - смотрю на твой список 2014 и в шоке... колись как искал - автоматикой или головой) кстати тоже вариант, по крайне мере может ответят - либо да либо нет.

 

zerodawn,

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

 

zerodawn,

> Это разве не аналогично фаззингу?

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

 

zerodawn, Клейн Т. - Дневник охотника за ошибками. Саттон М., Грин А., Амини П.-Fuzzing-Исследование уязвимостей методом грубой силы

 

это раньше было
сейчас фазеры поумнее, например WinAFL - подает на вход мутированные данные из набора валидных и с помощью DinamoRIO наблюдает появление новых блоков кода (покрытие), если появился новый блок, AFL запоминает входные данные которые привели к увеличению покрытия и ставит их в очередь для мутации

 

морально устарела лет 5 назад а то и больше

 

vx1d,

Не хочется давать название и оценку этому шедевру DinamoRIO, так как забанят. И про покрытие туда же.

Если атакуемый обьект это ядерная функция, к коду которой доступа нет из за изоляции режимов, то ни о каком анализе через dbi речи быть не может. Так что не пишите чушь.

 

чем плох DinamoRIO, я не в курсе?

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

 

ты меня на мысль навел - все краши которые нафазил, это были краши DinamoRIO)

 

тут стоит определиться с перечнем ошибок..

1. переполнение буфера.
2. погрешности округления плавающей запятой.
3. переполнение целочисленной переменной.
4. утечки озу.
=====
хмм.. список неполный, но суть в том, что тест строится либо на дизасме, либо на сырцах.

 

Раз уж Убивец отметился, оставлю ссылку тоже, интересно ЧЕМ и КАК они такое делают, https://www.joesecurity.org/joe-sandbox-reports

Там очень много всего, и я так понял, они что-то доселе неизведанное тоже пропускают через это "сито".

 

акь минимум это течь озу и автоматика такое вполне ловит.

 

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

 

Я когда-то читал одну книжку, про эксплойты (самое простое, типа как переполнение буфера происходит и все такое). Понял, что это не мое - общие вещи я понимаю, как и что, но что-то более сложное мне даже повторить непросто было бы, не то что самому исследовать. Надо, видимо, было начать изучать сискодинг лет так 20 назад + юзать какие-то эфедрины.