Jump to content











Photo

Exploit vulnerable drivers

kernel memory eprocess driver

  • Please log in to reply
3 replies to this topic

#1 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2925 posts
  • Location:Nantes - France
  •  
    France

Posted 03 December 2020 - 06:12 PM

Hi Gents,

 

On my spare time, I took a look at unsecured drivers in the wild.

There is a long list of vulnerable drivers (specially coming from motherboard manucfacturers).

 

What is a vulnerable driver? A driver that will accept IOCTL's from anyone (rather than only a specific application).

What can you achieve? Modify memory in kernel land.

 

Therefore I gave it a go with rtcore driver (from MSI) and decided to play with the EPROCESS structure.

Quoting MS : "The EPROCESS structure is an opaque structure that serves as the process object for a process."

And there are a lot of goodies in this "opaque" structure - starting with the PPL flag ("protected process light").

 

Quoting Kapersky : "Protected Process Light (PPL) technology is used for controlling and protecting running processes and protecting them from infection by malicious code and the potentially harmful effects of other processes."

 

So there are times where you would like to shutdown a process or access or its virtual memory ... and you just cant.

 

Changing the flag of the process in its eprocess structure will make it possible.

 

The sourcecode and binaries are there.

 

Be (really and very) careful as you are playing with kernel there (and you should not) : BSOD's are right there at the next corner.

 

Syntax:

memRW.exe load "%cd%\rtcore64.sys"

memRW.exe list
memRW.exe removeppl PID
memRW.exe makesystem PID
memRW.exe stealtoken from_pid to_pid
memRW.exe unload "%cd%\rtcore64.sys"

 

In the future, I aim at reading/dumping memory right from the physical memory rather than from the virtual memory.

 

Comments, feedback, etc welcome.

 

Regards,

Erwan


  • Brito likes this

#2 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 813 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 05 December 2020 - 01:54 AM

I kind of figured that unsigned drivers would be more of a risk. Since anyone can just modify them, potentially injecting them with malware while doing so. Then redistribute and pass them off as legit.

#3 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2925 posts
  • Location:Nantes - France
  •  
    France

Posted 05 December 2020 - 12:49 PM

Actually we are talking legitimate signed drivers here released by motherboards, graphics cards, ... manufacturers.

 

Issue is that the developpers there dont always follow a proper security checklist and in particular will allow any user and any software to use their drivers for other purposes.

To over simplify it, lets say that the Access Credential List is weak or non existing on these drivers.

 

From there, you can use these drivers to achieve something which they not meant to in the first place.

 

Lots of game cheats for example use that technique to work around anti cheat softwares.

 

Malware also use that technique to work around anti virus and other system protection.

 

Principle being "if you cant do it in user land, do it in kernel land".

 

/Erwan


  • Brito likes this

#4 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 813 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 05 December 2020 - 07:59 PM

I'm aware that you meant the drivers are legit signed. You're exploiting something by tampering with its' memory, which doesn't change any driver files stored on disk.

You could try opening a dialogue with as many manufacturers as possible, explaining to them why their current practices leaves huge security holes. Show them your work as proof. Many may take you seriously, others wont.

Or maybe they'll notice your work and do something about it on their own...doubtful.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users