• XSS.stack #1 – первый литературный журнал от юзеров форума

Как определяют уязвимости в драйверах?

DX01001101

HDD-drive
Пользователь
Регистрация
03.11.2021
Сообщения
46
Реакции
51
Только начал заниматься реверсом драйверов и задаюсь вопросом есть ли может какая то таблица или правила по которым можно определять что уязвимость а что нет?

Наверное вы подумали что я спрашиваю о метриках как определяют шкалу CVE, но не в этом вопрос
Попробую объяснить что я имею ввиду. Я смотрел недавно рапорт от одной уязвимости в драйвере одной компании, там была уязвимость read what where, ресерчер который ее нашел получил багбаунти в размере 5000$ и компания выпустила патч для нее. Но вот загвоздка в том что этот патч как бы просто меняет IoCreateDevice на IoCreateDeviceSecure с правами администратора, то есть уязвимость и ioctl к функции которая и читает память остался не измененным, я вот как бы понять не могу то есть если чтобы получить чтение надо иметь права администратора, разве это меняет того что уязвимость все также присутствует ? Или получается если я им напишу об этом еще раз то также получу баг баунти?

Также вопрос на счет уязвимостей типа DOS, как они определяется? Если например у меня есть драйвер который требует права администратора, но при одном запросе ioctl из-за того что буфер плохо инициализируется или в функции в которую он передает инпут выдает бсод, это считается DOS уязвимостью которую можно репортить?

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

Я только несколько дней пытаюсь в этом всем варится но честно не очень понимаю как определяются уязвимости, буду рад если кто-то с опытом побольше чем у меня попробует мне объяснить.
 
Решение
Но вот загвоздка в том что этот патч как бы просто меняет IoCreateDevice на IoCreateDeviceSecure с правами администратора, то есть уязвимость и ioctl к функции которая и читает память остался не измененным, я вот как бы понять не могу то есть если чтобы получить чтение надо иметь права администратора, разве это меняет того что уязвимость все также присутствует ?
Ну с правами админа ты и так можешь читать юзермод память и можешь загрузить драйвер для чтение памяти в ринг0. Так что получается, что не уязвимость, потому что и так можно сделать без этого драйвера.
Также вопрос на счет уязвимостей типа DOS, как они определяется? Если например у меня есть драйвер который требует права администратора, но при одном запросе ioctl...
Пожалуйста, обратите внимание, что пользователь заблокирован
Но вот загвоздка в том что этот патч как бы просто меняет IoCreateDevice на IoCreateDeviceSecure с правами администратора, то есть уязвимость и ioctl к функции которая и читает память остался не измененным, я вот как бы понять не могу то есть если чтобы получить чтение надо иметь права администратора, разве это меняет того что уязвимость все также присутствует ?
Ну с правами админа ты и так можешь читать юзермод память и можешь загрузить драйвер для чтение памяти в ринг0. Так что получается, что не уязвимость, потому что и так можно сделать без этого драйвера.
Также вопрос на счет уязвимостей типа DOS, как они определяется? Если например у меня есть драйвер который требует права администратора, но при одном запросе ioctl из-за того что буфер плохо инициализируется или в функции в которую он передает инпут выдает бсод, это считается DOS уязвимостью которую можно репортить?
Впринципе считать можно. Если у тебя софт крашится из-за буфера (в данном случае у тебя вся система падает), то чем не DOS? Отказ в обслуживании произошел? -да
 
Решение
Впринципе считать можно. Если у тебя софт крашится из-за буфера (в данном случае у тебя вся система падает), то чем не DOS? Отказ в обслуживании произошел? -да
Но в теории и чтобы вообщем любой драйвер от какого нибудь третьесортного софта использовать в атаках даже если там IoCreateDevice, придется его загрузить, для чего нужны права администратора. А если мы говорим про кейсы где драйвер уже в системе, то получается мы позбываемся в нужде загрузки какого либо драйвера, что намного упрощает эксплуатацию да и детект систем АВ/АДР будет фатально ниже. Но я понял философию и ток мыслей, спасибо.
Впринципе считать можно. Если у тебя софт крашится из-за буфера (в данном случае у тебя вся система падает), то чем не DOS? Отказ в обслуживании произошел? -да

Понял, спасибо. Просто я думал тут также как и ты написал выше что можно подтянуть под то что имея права админа можно также вызвать бсод другими способами и без этого.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
если я им напишу об этом еще раз то также получу баг баунти?
Скорее всего нет. В твиттерах люди периодически жалуются, что их разворачивают с такими репортами.
Так что получается, что не уязвимость, потому что и так можно сделать без этого драйвера.
Тем не менее мелкософт на моей памяти однажды пофиксил такую уязвимость в одном из своих драйверов из-за использования оного лазарусом. У нас на ее базе конкурс был.
А вот если например драйвер не важно с правами администратора или нет, позволяет получить доступ к кернел функции которая может быть полезна при построении chain атак и использовании в цепочке с другими какими то экспоитами, но сама по себе не несет никакого импакта, это тоже считается как уязвимость?
Не совсем понял о чем речь, ты подразумеваешь "Arbitrary Pointer Dereference" или что? В любом случае потребуют ПоЦ.
 
Последнее редактирование:
Скорее всего нет. В твиттерах люди периодически жалуются, что их разворачивают с такими репортами.

Тем не менее мелкософт на моей памяти однажды пофиксил такую уязвимость в одном из своих драйверов из-за использования оного лазарусом. У нас на ее базе конкурс был.
Буду знать, спасибо!

Не совсем понял о чем речь, ты подразумеваешь "Arbitrary Pointer Dereference" или что? В любом случае потребуют ПоЦ.
Ну я когда писал вообщем имел ввиду если драйвер какие то интересные функции имеет, которые потенциально могут как-то быть использованны, но уже как щас понял как ты и написал что надо предоставить ПоЦ что впринципе в таких случаях невозможно, что делает то что это бессмысленно. Глупый вопрос кароче задал, уже понял что надо именно по факту предоставлять уязвимость и поц к ней, а какие то потенциальные возможные их не волнуют.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
надо именно по факту предоставлять уязвимость и поц к ней, а какие то потенциальные возможные их не волнуют.
Все верно, может быть когда-то и можно было так протолкнуться, но сейчас с этим довольно строго все.
 
Пожалуйста, обратите внимание, что пользователь заблокирован


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх