![]() My goal here is to illustrate a general approach on performing the initial bug analysis through IDA and WinDbg, run a simple fuzzing test and then construct the exploit bottom-up. (Well, sometimes the vulnerable driver or kernel component can be owned even remotely - EternalBlue anyone? :) In this post I would like to cover the “low-hanging fruits” those hidden and still undiscovered vulnerabilities in signed and trusted production drivers which are, too often than not, widely deployed on consumers and enterprise endpoints.Īn exploitable kernel driver vulnerability can lead an unprivileged user to SYSTEM, just because the vulnerable driver is locally available to anyone. More information on the whole driver signing process can be found here. ![]() Starting from Windows 1607 Anniversary Update, only signed drivers through WHQL certification process are now allowed to be loaded and, as a consequence of that, crafting and shipping your own bug door is not possibile straightforward anymore. So why attacking drivers? Besides the ones shipped by Microsoft, third-party drivers are the only and more accessible means for third parties to get code execution into ring 0. ![]() Regrettably, during recent times, it has also increased in complexity and its mitigation way improved. Being one of the toughest to scrutinize due to its lack of source code and undocumented APIs, it is now being more documented thanks to the immense effort from the research community. Kernels are, no euphemism intended, complex piece of software and the Windows OS is no exception. Preamble - Why are drivers still a valuable target? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |