Не знаю актуально или нет, но раз ответов нет могу задать хотя бы направление.
Все зависит от того что это за драйвер и какой у него функционал. IOCTL это самая верхушка айсберга
Как пример тут же на форуме была статья по драйверам-фильтрам: LOL-драйверы Windows: алгоритм поиска уязвимостей
А так основные направления:
1. Определение свойств драйвера (inf-файлы, реестр windows, если мы говорим о ней)
2. Оценка доступности портов в зависимости от привилегий.
3. Оценка корректности используемых буферов.
4. Определение используемых IPC (тут все зависит от драйвера и с кем он общается)
4.1 Анализ и оценка корректности использования IPC (например ALPC и опять-таки на форуме есть хорошая статья с разбором этого механизма)
4.2 Фаззинг тестирование IPC (вот тут выбор средства зависит от того ваш это драйвер или нет и свойств самого драйвера)
В целом этапы примерно такие.
А так же на процесс влияет тип уязвимости, я встречал довольно интересные варианты DOS завязанные на блокировке имени создаваемого порта. Исследователи нашли этот тип уязвимости через реверс функций создающих DRIVER_OBJECT и DEVICE_OBJECT, там были захардкожены наименования и исследователи создали свой драйвер единственная функция которого была занять порты загрузившись раньше (а это определяется свойствами драйвера), что привело к DOS исследуемого драйвера.
Существует достаточно много информации в открытом доступе и тут на форуме и в целом в интернете по этой теме. Но это достаточно узкоспециализированная тема и довольно сложная, требующая понимания механизмов ОС.
Все зависит от того что это за драйвер и какой у него функционал. IOCTL это самая верхушка айсберга
Как пример тут же на форуме была статья по драйверам-фильтрам: LOL-драйверы Windows: алгоритм поиска уязвимостей
А так основные направления:
1. Определение свойств драйвера (inf-файлы, реестр windows, если мы говорим о ней)
2. Оценка доступности портов в зависимости от привилегий.
3. Оценка корректности используемых буферов.
4. Определение используемых IPC (тут все зависит от драйвера и с кем он общается)
4.1 Анализ и оценка корректности использования IPC (например ALPC и опять-таки на форуме есть хорошая статья с разбором этого механизма)
4.2 Фаззинг тестирование IPC (вот тут выбор средства зависит от того ваш это драйвер или нет и свойств самого драйвера)
В целом этапы примерно такие.
А так же на процесс влияет тип уязвимости, я встречал довольно интересные варианты DOS завязанные на блокировке имени создаваемого порта. Исследователи нашли этот тип уязвимости через реверс функций создающих DRIVER_OBJECT и DEVICE_OBJECT, там были захардкожены наименования и исследователи создали свой драйвер единственная функция которого была занять порты загрузившись раньше (а это определяется свойствами драйвера), что привело к DOS исследуемого драйвера.
Существует достаточно много информации в открытом доступе и тут на форуме и в целом в интернете по этой теме. Но это достаточно узкоспециализированная тема и довольно сложная, требующая понимания механизмов ОС.
Комментарии
1