[JIRA] (SSPCPP-961) Shibboleth SP - Windows - possible Privilege Escalation

Mon Nov 14 18:07:50 UTC 2022

Carl Pearson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=63728144489de2f7f46161a6 ) *created* an issue

Shibboleth SP - C++ ( https://shibboleth.atlassian.net/browse/SSPCPP?atlOrigin=eyJpIjoiMDhmNWZjMGM3MmQxNDdlMDhmOWUwYTVjZWE3NjgwMDMiLCJwIjoiaiJ9 ) / Bug ( https://shibboleth.atlassian.net/browse/SSPCPP-961?atlOrigin=eyJpIjoiMDhmNWZjMGM3MmQxNDdlMDhmOWUwYTVjZWE3NjgwMDMiLCJwIjoiaiJ9 ) SSPCPP-961 ( https://shibboleth.atlassian.net/browse/SSPCPP-961?atlOrigin=eyJpIjoiMDhmNWZjMGM3MmQxNDdlMDhmOWUwYTVjZWE3NjgwMDMiLCJwIjoiaiJ9 ) Shibboleth SP - Windows - possible Privilege Escalation ( https://shibboleth.atlassian.net/browse/SSPCPP-961?atlOrigin=eyJpIjoiMDhmNWZjMGM3MmQxNDdlMDhmOWUwYTVjZWE3NjgwMDMiLCJwIjoiaiJ9 )

Issue Type: Bug Affects Versions: 3.4.0 Assignee: Scott Cantor ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A5b78efc9-1379-42cc-a3f6-56c6ea3a0007 ) Attachments: shibboleth-sp permissions.PNG, shibd.cs Created: 14/Nov/22 1:07 PM Environment:

Tested with Shibboleth SP v3.4.0 x64 on Windows 10 x64 21H2 build 19044.2251.

I’ve attached a screenshot of the C:\opt\shibboleth-sp\ folder permissions for “Authenticated Users” group which includes unprivileged accounts on the local system. The screenshot was taken after a new install of Shibboleth SP.

Priority: Trivial Reporter: Carl Pearson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=63728144489de2f7f46161a6 )

-------
Summary
-------

Shibboleth service provider (SP) for Windows creates a new folder path C:\opt\shibboleth-sp\ and installs itself there by default. The Shibboleth SP service ("Shibboleth Daemon") executes the program at C:\opt\shibboleth-sp\sbin64\shibd.exe as NT AUTHORITY\SYSTEM on system startup.

The ACL permissions present on folder C:\opt\shibboleth-sp\ after a new Shibboleth SP install allow an unprivileged, local user account to read, write, modify, and rename contents. The permissions apply to subfolders and files, including folder sbin64/. An unprivileged user account can replace the legitimate Shibboleth shibd.exe binary with a malicious shibd.exe binary which executes with elevated privileges when the Shibboleth service next restarts. An unprivileged user can exploit this vulnerability to execute arbitrary code under privileged SYSTEM context.

------------
Reproduction
------------

Pre-requisites:

* a Windows host with Shibboleth SP installed in its default location of C:\opt\shibboleth-sp\
* .NET framework installed (should be by default on Windows 10)
* a normal, unprivileged (i.e. not an administrator) account present on the system.

The proof-of-concept payload I used is a .NET executable. I’ll provided the C# source code file for it with this report.

* Login to the system as the unprivileged user account.
* Download the attached shibd.cs C# source code file to the target Windows computer.
* Open a Powershell prompt and change to the directory with the downloaded shibd.cs file. For example, if you downloaded the file into C:\ProgramData, then enter:
cd C:\ProgramData\
* Compile the exploit code using the built-in C# compiler with the following command:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe shibd.cs
If .NET v4.0.30319 isn’t installed, adjust the path to match the installed version. The compiler should create a new file, shibd.exe, in the current folder.

While a Windows service is running, it's executable file is in use and locked. We cannot directly overwrite the existing C:\opt\shibboleth-sp\sbin64\shibd.exe because the Shibboleth Daemon service has the file open and Windows does not allow a process to overwrite a file opened by another process. However, Windows locks the file itself, not the folder and file path name. We can rename the shibd.exe's parent sbin64 folder, create a new folder named sbin64, and plant our shibd.exe binary in the new folder. The resulting file path C:\opt\shibboleth-sp\sbin64\shibd.exe then refers to our file and at next server restart our binary will execute.

* Rename the folder C:\opt\shibboleth-sp\sbin64\ to C:\opt\shibboleth-sp\sbin64original\
* Create a new folder named sbin64 in the shibboleth-sp folder.
mkdir C:\opt\shibboleth-sp\sbin64\
* Copy the compiled binary to the new folder
copy C:\ProgramData\shibd.exe C:\opt\shibboleth-sp\sbin64\shibd.exe

The file C:\opt\shibboleth-sp\sbin64\shibd.exe is now the attacker's file instead of the legitmate Shibboleth executable.

* Restart the computer. This represents a typical computer restart, such as applying monthly OS patches.
* When the restart completes, open the local users console (press Windows + R, type lusrmgr.msc, then hit Enter).
* Double click the Users folder.
* You should see a new user account named localadmin. If you right click the account, click Properties, then click Member Of, you should see the account is a member of the Administrators group on the local computer.

We have demonstrated that, as a unprivileged user account, we can exploit the Shibboleth SP service to gain privileged code execution.

-----------
Other Notes
-----------

The folder C:\opt do not exist by default and are created during installation. New folders created at the root of C:\ drive appear to be given a default ACL by Windows which allows any user account to create, modify, and delete child files and folders. The Shibboleth installer does not appear to modify this ACL to restrict non admin users from modifying contents.

The vulnerability does not exist if the Shibboleth installation folder is manually changed during install to be C:\Program Files. The C:\Program Files\ folder has an ACL which blocks unprivileged accounts from modifying subfolders and files.

( https://shibboleth.atlassian.net/browse/SSPCPP-961#add-comment?atlOrigin=eyJpIjoiMDhmNWZjMGM3MmQxNDdlMDhmOWUwYTVjZWE3NjgwMDMiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/SSPCPP-961#add-comment?atlOrigin=eyJpIjoiMDhmNWZjMGM3MmQxNDdlMDhmOWUwYTVjZWE3NjgwMDMiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100210- sha1:583150f )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20221114/4d687462/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-41482291-301b-44c0-90a3-d359277195f9
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221114/4d687462/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-trivial-248e4d80-dee6-4f47-ae39-26c3445ba0ad
Type: image/png
Size: 563 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221114/4d687462/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-aff0ec0a-3b67-4362-8d5a-82d0754fc600
Type: image/png
Size: 425 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221114/4d687462/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-4788d059-38ad-49f9-893f-38f86762b7f6
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221114/4d687462/attachment-0007.png>