Request: Manually Add Capability SIDs

WildByDesign commented 5 years ago

At the moment, it is not possible to add AppContainer Capabilities aside from the main Well Known SID types. In a previous issue, we had discussed this and realized that it needs more time to figure out and more development in that regard.

For right now, it would be a nice feature if we could manually add some Capability SIDs. Possibly in the user interface, maybe have another button in which we can add a list of other Capability SIDs and type/copy those SIDs in manually.

For example, I figured out a way to determine Capability SIDs by using @tyranid 's Token Viewer program from https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools repo combined with some command line flags for Chromium browser.

Some Capability SIDs that I have discovered thus far are:

broadFileSystemAccess S-1-15-3-1024-3247244612-4072385457-573406302-3159362907-4108726569-214783218-394353107-2658650418 internetExplorer S-1-15-3-1024-3074157858-2547534938-2297668728-3066639066-623563824-3135784797-1864023905-3488129466 constrainedImpersonation S-1-15-3-1024-1604681682-535129537-3273749797-3666938095-336295784-2177615760-2743807136-2867270584 runFullTrust S-1-15-3-1024-1365790099-2797813016-1714917928-519942599-2377126242-1094757716-3949770552-3596009590 registryRead* S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681 lpacAppExperience S-1-15-3-1024-1502825166-1963708345-2616377461-2562897074-4192028372-3968301570-1997628692-1435953622

But of course there are many more. Therefore, if we had an option in the user interface to manually add Capability SIDs that would be very handy for the time being.

tyranid commented 5 years ago

Worth noting the current list of capability names I've gathered from the system are in https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/blob/master/NtApiDotNet/SecurityCapabilities.cs. You can use DeriveCapabilitySidsFromName to convert a named capability to a SID to add to the AppContainer token.

fcharlie commented 5 years ago

@WildByDesign @tyranid In fact, wsudo supports the Capabilities listed in https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/blob/master/NtApiDotNet/SecurityCapabilities.cs, using the DeriveCapabilitySidsFromName function, but Privexec does not have a good GUI interface design. (I am not very good at GUI) So you can't see those changes.

commit: https://github.com/M2Team/Privexec/commit/b1f0a9e2bc44677faa4a3a8eed785e99eaea8afa

https://github.com/M2Team/Privexec/blob/b1f0a9e2bc44677faa4a3a8eed785e99eaea8afa/include/process/details/appcontainer.ipp#L205

wsudo -n -a -x F:\Code\example\xml\windbg.xml notepad

windbg.xml

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3" xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10" xmlns:desktop2="http://schemas.microsoft.com/appx/manifest/desktop/windows10/2" xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" IgnorableNamespaces="uap3 desktop2" xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest">
  <Identity Name="Microsoft.WinDbg" ProcessorArchitecture="neutral" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="1.1810.2001.0" />
  <Properties>
    <DisplayName>WinDbg Preview</DisplayName>
    <PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
    <Logo>Resources\WinDbg_150.png</Logo>
  </Properties>
  <Resources>
    <Resource Language="en-us" />
  </Resources>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14257.0" MaxVersionTested="10.0.14257.0" />
  </Dependencies>
  <Capabilities>
    <rescap:Capability Name="runFullTrust" />
    <rescap:Capability Name="packageQuery" />
  </Capabilities>
  <Applications>
    <Application Id="Microsoft.WinDbg.DbgSrv64" Executable="amd64\dbgsrv.exe" EntryPoint="Windows.FullTrustApplication">
      <uap:VisualElements AppListEntry="none" DisplayName="WinDbg Preview DbgSrv 64-bit" Description="WinDbg Preview DbgSrv 64-bit" BackgroundColor="#777777" Square150x150Logo="Resources\WinDbg_150.png" Square44x44Logo="Resources\WinDbg_44.png" />
      <Extensions>
        <uap3:Extension Category="windows.appExecutionAlias" Executable="amd64\dbgsrv.exe" EntryPoint="Windows.FullTrustApplication">
          <uap3:AppExecutionAlias>
            <desktop:ExecutionAlias Alias="dbgsrv64.exe" />
          </uap3:AppExecutionAlias>
        </uap3:Extension>
      </Extensions>
    </Application>
    <Application Id="Microsoft.WinDbg.DbgSrv32" Executable="x86\dbgsrv.exe" EntryPoint="Windows.FullTrustApplication">
      <uap:VisualElements AppListEntry="none" DisplayName="WinDbg Preview DbgSrv 32-bit" Description="WinDbg Preview DbgSrv 32-bit" BackgroundColor="#777777" Square150x150Logo="Resources\WinDbg_150.png" Square44x44Logo="Resources\WinDbg_44.png" />
      <Extensions>
        <uap3:Extension Category="windows.appExecutionAlias" Executable="x86\dbgsrv.exe" EntryPoint="Windows.FullTrustApplication">
          <uap3:AppExecutionAlias>
            <desktop:ExecutionAlias Alias="dbgsrv32.exe" />
          </uap3:AppExecutionAlias>
        </uap3:Extension>
      </Extensions>
    </Application>
    <Application Id="Microsoft.WinDbg" Executable="DbgX.Shell.exe" EntryPoint="Windows.FullTrustApplication">
      <uap:VisualElements DisplayName="WinDbg Preview" Description="WinDbg Preview" BackgroundColor="#777777" Square150x150Logo="Resources\WinDbg_150.png" Square44x44Logo="Resources\WinDbg_44.png" />
      <Extensions>
        <uap:Extension Category="windows.fileTypeAssociation">
          <uap3:FileTypeAssociation Name="newtypes" Parameters="-z &quot;%1&quot;" desktop2:UseUrl="true">
            <uap:SupportedFileTypes>
              <uap:FileType>.run</uap:FileType>
              <uap:FileType>.dmp</uap:FileType>
              <uap:FileType>.mdmp</uap:FileType>
              <uap:FileType>.hdmp</uap:FileType>
              <uap:FileType>.kdmp</uap:FileType>
              <uap:FileType>.ndmp</uap:FileType>
            </uap:SupportedFileTypes>
          </uap3:FileTypeAssociation>
        </uap:Extension>
        <uap3:Extension Category="windows.appExecutionAlias" Executable="DbgX.Shell.exe" EntryPoint="Windows.FullTrustApplication">
          <uap3:AppExecutionAlias>
            <desktop:ExecutionAlias Alias="WinDbgX.exe" />
          </uap3:AppExecutionAlias>
        </uap3:Extension>
      </Extensions>
    </Application>
  </Applications>
  <mp:PhoneIdentity PhoneProductId="cc80b52c-c459-4524-aeab-79ffc8f0d8f0" PhonePublisherId="95d94207-0c7c-47ed-82db-d75c81153c35" />
</Package>

Process Explorer Security:

WildByDesign commented 5 years ago

@fcharlie Thank you for confirming the details and command for wsudo. Since both wsudo and Privexec both parse the Package.appxmanifest / xml files for Capabilities, I think this issue can be closed. Now that I am aware of this, there is no need for additional UI feature in Privexec. So I will close this issue now, however, I do have a question that may (possibly) be another issue/bug.

I noticed that with Privexec, the User is always privexec.core.appcontainer.v2 when launching within AC sandbox. Privexec is setting user as privexec.core.appcontainer.v2 when parsing appx/xml for capabilities. Privexec will not launch within AC sandbox if user does not choose capability or parse appx/xml.

I noticed that with wsudo, the User is privexec.core.appcontainer.v2 when launching within AC sandbox only when not parsing app/xml for capabilities. wsudo sets User as privexec.core.appcontainer.v3 when parsing appx/xml for capabilities which seems opposite of Privexec.

wsudo is working 100% great.

I am wondering if this is a bug in Privexec (not bug in wsudo) in which Privexec is parsing the appx/xml for capabilities (just like wsudo) but not successfully adding the Restricted Capabilities (rescap) while wsudo is successful in parsing those. If that is indeed a bug in Privexec, should I open another issue for that?

Thank you.

fcharlie commented 5 years ago

@WildByDesign This issue is confirmed, Privexec does not support rescap, which means that the new Capabilities parsing is only OK in wsudo.

fcharlie commented 5 years ago

Lookup: https://github.com/M2Team/Privexec/blob/b1f0a9e2bc44677faa4a3a8eed785e99eaea8afa/include/process/details/capabilities.hpp#L11

Total 788 Capability Names

fcharlie commented 5 years ago

@WildByDesign Look: https://github.com/M2Team/Privexec/blob/master/docs/changelog.md#2018-12-22

WildByDesign commented 5 years ago

@fcharlie I just tested the latest build from AppVeyor and Privexec is working 100% correct now with regard to capabilities. Excellent! Thank you.

Also, the user interface changes look nice as well.

M2Team / Privexec

Request: Manually Add Capability SIDs #11