From iPhone to NT AUTHORITY\SYSTEM – exploit ‘Printconfig’ dll with a real-world example

From iPhone to NT AUTHORITY\SYSTEM – 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)

Some time ago, me and my “business partner”  @padovah4ck, were 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 time of writing)
• For testing purposes, you need physical access to the machine in order to plug in 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 [email protected]
• 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, the post has been published

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.

Original post available at the following URL:

https://decoder.cloud/2019/12/12/from-iphone-to-nt-authoritysystem/

About the authors

Andrea Pierini (@decoder_it)
“Andrea is an IT Architect & Security Manager with long-term experience and in-depth knowledge covering all aspects of IT: from SW development to systems administration; networking administration and IT security. He can define himself “security enthusiast”, interested in all emerging technologies in offensive and defensive security. He likes writing and speaking about IT security and bug hunting. Cycling and addicted”

Christian Danieli  (@padovah4ck)

“Chris is an “old-school” developer turned into Security Engineer and Automation Operator. He still codes a lot and has an innate ability to find bugs and solve problems. He saw and explored almost everything an IT guy could have seen since 1995. OS Windows Lover especially for the bug hunting part!  Fishing and spearfishing addicted.” 

Pierluigi Paganini

(SecurityAffairs – iPhone, Printconfig)

[adrotate banner=”5″]

[adrotate banner=”13″]

Share On