As promised in my previous post , I will show you how to exploit the “Printconfig” dll with a real world example.

But what does Apple’s iPhone have to do with it??

Well, keep on reading… (sorry  no TL;DR)

Some time ago, I was looking for possible privileged file operations exploitable via hardlinks.

At some point, the directory c:\programdata\apple\lockdown caught our attention.

This folder is used by the “Apple Mobile Device Service” which is installed by  the iTunes Software. The service, running with Local System  privileges, is responsible for handling the communications via USB port with Apple devices (iPhone, iPad, etc..).

As you can see below, standard users can add files in this directory:

Each time a new device is plugged in, the driver will write a “pairing certificate” file in this directory in the form of <UDID>.plist, where UDID is the universal Id of the Apple device.

So let’s plugin our Apple device. A “pairing certificate” will be generated and the permissions set on this file are the following:

As you can see, users have only read access to this file.

But now comes the funny part. If you unplug the device and then plugin again, some “magic” happens, granting to users Full Control over that file:

We observed this “strange” behavior using the “procmon” tool from Sysinternals:

A SetSecurity call is made from an elevated context (SYSTEM) and will grant full control to users on the resource. So the question is, can this operation be exploitable?

Yes!! You got it, enter “native hardlinks“…

Standard Windows users do not need special privileges to create this type of links and we can use Forshaw’s utilties to  manage them.

So why not setting a “native hardlink” on this file and let him point to a resource where only SYSTEM has full control?

This is what we are going to do, setting a hardlink from our <udid>.plist file to license.rtf  located in  System32 folder:

Now we just need to plugin our Apple device in order to alter the permissions on destination file:

And yes, it works!

At this point we have all the pieces of the puzzle, we only need to change the destination file to printconfig.dll, then overwrite it with our own dll, start the XPS print job and  finally enjoy the SYSTEM shell  (this exercise is left to the reader) 😉

Here you can watch a video of the POC.

Boundary conditions

• You need a user shell access on the Windows machine.
• iTunes along with Apple Mobile Device Service should be installed.  We tested it with the latest iTunes release (12.10.3 at the the time of writing)
• For testing purpose, you need a physical access to the machine in order to plugin your Apple device, but this is not strictly necessary. In an “attacker scenario”  you could delete the *.plist files, create hardlinks of the same *.plist files pointing to the destination dll and wait for the device plugin.  We observed that sometimes full permissions are set even without pairing a device, but we need to investigate more about it.

Disclosure timeline:

• 13th September 2019: We submitted the issue to product-security@apple.com
• 18th September 2019: Apple asked us the resend the screen shots
• 10th October 2019: Apple told us that they were planning to address this issue in a future update
• 30th October 2019: Apple released version 12.10.2 of iTunes but did not fix the issue
• We asked several times about this case but no answer from Apple
• 9th December 2019: We informed Apple that we would release a public post about this issue on 12th of December (90 days since the initial submission)
• 11th December 2019: Apple released version 12.10.3 of iTunes but did not fix the issue
• 12th December 2019: still no answer, post has been published

Possible Countermeasures

Waiting for the new (hopefully  patched) release, meantime you could remove the “Write”  permissions  for “Users” on the  “Lockdown” folder and you should be fine

Side note

Generic hardlink “abuse” will no more work in future releases of Windows. In the latest “Insider” previews, MS has added some supplementary checks, so if you don’t have write access to the destination file you get an access denied error when you try to create a hardlink.

 

That’s all 🙂