SandBoxIE to harden SRP (software restriction policy)?
Re: SandBoxIE to harden SRP (software restriction policy)?
Will this white list also prevent a rogue DLL from being loaded and executed?
winXP-SP3 hacked into POSReady2009.
Re: SandBoxIE to harden SRP (software restriction policy)?
That is a vague question. A rogue DLL? From where? Loaded by what? Executed by what? You have already seen that SRP is not what some thought it was.
Why stick with it? Would SRP stop that rogue DLL? Would it at least contain it? Sandboxie will at the minimum contain and delete it,
and more likely prevent it from running at all. Your choice of browser and hardening that browser would be of more benefit.
Why stick with it? Would SRP stop that rogue DLL? Would it at least contain it? Sandboxie will at the minimum contain and delete it,
and more likely prevent it from running at all. Your choice of browser and hardening that browser would be of more benefit.
Re: SandBoxIE to harden SRP (software restriction policy)?
A rogue DLL could be downloaded to user's %TEMP% folder by his browser from a compromised site - either by a script or by user's own error.
This DLL could be executed by a shell code exploiting a 0-day in the browser.
Normally such kind of attack should be stopped by SRP/Applocker's "disallowed by default" policy.
As Didier Stevens has shown - this SRP/Applocker policy is almost trivial to circumvent.
All I'm asking for is a sort of a KB2531445 being provided by SandBoxIE for winXP-SP3/vista users.
Please re-read my opening post and my further reasonings on the topic.
Thank you!
This DLL could be executed by a shell code exploiting a 0-day in the browser.
Normally such kind of attack should be stopped by SRP/Applocker's "disallowed by default" policy.
As Didier Stevens has shown - this SRP/Applocker policy is almost trivial to circumvent.
All I'm asking for is a sort of a KB2531445 being provided by SandBoxIE for winXP-SP3/vista users.
Please re-read my opening post and my further reasonings on the topic.
Thank you!
winXP-SP3 hacked into POSReady2009.
Re: SandBoxIE to harden SRP (software restriction policy)?
So let's say this theory happens. Whatever it is, it can not install a driver. If you have whitelisted your programs it probably will not run. If you set up ClosedFilesPaths, it will not see anything. And if you set auto delete and close the sandbox it is gone. Totally gone, cleanly, completely gone. All of that balanced against Curt stating that the goal of Sandboxie is to contain and delete. And changing for your request would cause other programs not to work correctly. That is a lot to ask to handle this emergency. And yet you did ask again, for Curt to reconsider. Have you considered upgrading from Windows XP?
Re: SandBoxIE to harden SRP (software restriction policy)?
How can you be sure it will not be able to install a driver? I will not take any risks here.JoeHood wrote:... Whatever it is, it can not install a driver...
<snip>
... And changing for your request would cause other programs not to work correctly...
What other programs (apart from clearly mentioned that SOME installers possibly could - please read MS's documentation on the matter) would fail?
How many programs fail because of the "Drop rights" check-box marked?
I see SandBoxIE's task to discipline what a program running under SBIE's supervision could do.
The feature I'm asking for is clearly intended to improve the discipline (what was not pre-installed by an admin that should not be runnable for LUA).
winXP-SP3 hacked into POSReady2009.
Re: SandBoxIE to harden SRP (software restriction policy)?
I'd like to bring this up.
Could you please create a beta/testing version to check for alleged compatibility issues?
Thank you in advance.
Could you please create a beta/testing version to check for alleged compatibility issues?
Thank you in advance.
winXP-SP3 hacked into POSReady2009.
Re: SandBoxIE to harden SRP (software restriction policy)?
SRP, pfft, if it's spyware it's gonna (down)load in & execute any binary from memory, ASLR actually makes that a lot likelier.
(but assuming it's not malware to begin with...)
One could create a 1KB Sandboxie InjectDll(64) to hook and mask (or Xor) out any occurrence of those flags in those functions.
I'm disinterested as I don't know the exact SRP set up to test this, command line, please, I'm lazy. 2nd thought I'm too lazy.
(but assuming it's not malware to begin with...)
One could create a 1KB Sandboxie InjectDll(64) to hook and mask (or Xor) out any occurrence of those flags in those functions.
I'm disinterested as I don't know the exact SRP set up to test this, command line, please, I'm lazy. 2nd thought I'm too lazy.
Re: SandBoxIE to harden SRP (software restriction policy)?
Okay 3 KB for OS compatibility.
Sorry for being a lazy asswipe.
SANDBOXIE 32-BIT INJECTDLL INSTALLATION
ATTRIB +R "C:\SbieSRP.dll"
[GlobalSettings]
InjectDll=C:\SbieSRP.dll
SOURCE CODE (flat assembler 1.71.22 for Windows)
:: BUILDING THE BINARY - http://flatassembler.net/download.php
@
REM your working directory should be one level above your FASM path
@
SET "Path=%Path%;.\fasmw17122"
SET "INCLUDE=.\fasmw17122\INCLUDE"
@
FASM.EXE "SbieSRP.asm"
REM flat assembler version 1.71.22 (1048576 kilobytes memory)
REM 5 passes, 3072 bytes.
@
:: AUTOHOTKEY DEBUG TEST CALLS
@
ECHO DllCall("LoadLibraryExA","UPtr",NULL,"UPtr",NULL,"UInt",0xFFFFFFFF)|AutoHotkeyA32.exe *
ECHO DllCall("LoadLibraryExW","UPtr",NULL,"UPtr",NULL,"UInt",0xFFFFFFFF)|AutoHotkeyU32.exe *
ECHO DllCall("advapi32\CreateRestrictedToken","UPtr",VOID,"UInt",0xFFFFFFFF,"UInt",VOID, "UPtr",NULL,"UInt",VOID,"UPtr",NULL,"UInt",VOID,"UPtr",NULL,"UPtrP",VOID)|AutoHotkeyU32.exe *
ECHO DllCall("advapi32\SaferComputeTokenFromLevel","UPtr",VOID,"UPtr",NULL,"UPtr",VOID,"UInt",0xFFFFFFFF,"UPtr",VOID)|AutoHotkeyU32.exe *
@
AUTOHOTKEY POC TEST
Use Sysinternals' Process Explorer (Lower Pane DLLs view) to see that SbieSRP.dll is loaded into every Sbie BOXED, 32-bit process - all processes if WinXP & SP3.
Sorry for being a lazy asswipe.
SANDBOXIE 32-BIT INJECTDLL INSTALLATION
ATTRIB +R "C:\SbieSRP.dll"
[GlobalSettings]
InjectDll=C:\SbieSRP.dll
SOURCE CODE (flat assembler 1.71.22 for Windows)
Code: Select all
format PE GUI 4.0 DLL
entry DllEntryPoint
;include 'WIN32A.INC'
;include 'WIN32W.INC'
; "more advanced macroinstructions"
;include 'WIN32AX.INC'
include 'WIN32WX.INC'
;include 'WIN32AXP.INC'
;include 'WIN32WXP.INC'
LOAD_IGNORE_CODE_AUTHZ_LEVEL=0xFFFFFFEF ; ~0x10
SANDBOX_INERT=0xFFFFFFFD ; ~0x2
SAFER_TOKEN_MAKE_INERT=0xFFFFFFFB ; ~0x4
struct kernel32_
LoadLibraryExA dd ?
LoadLibraryExW dd ?
ends
struct advapi32_
CreateRestrictedToken dd ?
SaferComputeTokenFromLevel dd ?
ends
struct SbieDll_
Hook dd ?
ends
section '' data readable writeable
kernel32 kernel32_
advapi32 advapi32_
SbieDll SbieDll_
section '' code executable readable
proc DllEntryPoint hinstDLL,fdwReason,lpvReserved
; invoke DisableThreadLibraryCalls,[hinstDLL]
mov eax,TRUE
ret
endp
proc detour_LoadLibraryExA lpFileName,hFile,dwFlags
and [dwFlags],LOAD_IGNORE_CODE_AUTHZ_LEVEL
invoke kernel32.LoadLibraryExA,[lpFileName],[hFile],[dwFlags]
ret
endp
proc detour_LoadLibraryExW lpFileName,hFile,dwFlags
and [dwFlags],LOAD_IGNORE_CODE_AUTHZ_LEVEL
invoke kernel32.LoadLibraryExW,[lpFileName],[hFile],[dwFlags]
ret
endp
proc detour_CreateRestrictedToken ExistingTokenHandle,Flags,DisableSidCount,SidsToDisable,DeletePrivilegeCount,PrivilegesToDelete,RestrictedSidCount,SidsToRestrict,NewTokenHandle
and [Flags],SANDBOX_INERT
invoke advapi32.CreateRestrictedToken,[ExistingTokenHandle],[Flags],[DisableSidCount],[SidsToDisable],[DeletePrivilegeCount],[PrivilegesToDelete],[RestrictedSidCount],[SidsToRestrict],[NewTokenHandle]
ret
endp
proc detour_SaferComputeTokenFromLevel LevelHandle,InAccessToken,OutAccessToken,dwFlags,lpReserved
and [dwFlags],SAFER_TOKEN_MAKE_INERT
invoke advapi32.SaferComputeTokenFromLevel,[LevelHandle],[InAccessToken],[OutAccessToken],[dwFlags],[lpReserved]
ret
endp
proc InjectDllMain hSbieDll,UnusedParameter
invoke GetProcAddress,[hSbieDll],SbieDll_dll.SbieDll_Hook
mov [SbieDll.Hook],eax
or eax,eax
jz @f
invoke SbieDll.Hook,"LoadLibraryExA",[LoadLibraryExA],detour_LoadLibraryExA
mov [kernel32.LoadLibraryExA],eax
; or eax,eax
; jz @f
invoke SbieDll.Hook,"LoadLibraryExW",[LoadLibraryExW],detour_LoadLibraryExW
mov [kernel32.LoadLibraryExW],eax
; or eax,eax
; jz @f
invoke SbieDll.Hook,"CreateRestrictedToken",[CreateRestrictedToken],detour_CreateRestrictedToken
mov [advapi32.CreateRestrictedToken],eax
; or eax,eax
; jz @f
invoke SbieDll.Hook,"SaferComputeTokenFromLevel",[SaferComputeTokenFromLevel],detour_SaferComputeTokenFromLevel
mov [advapi32.SaferComputeTokenFromLevel],eax
; or eax,eax
; jz @f
@@:
ret
endp
struct _SbieDll_dll
SbieDll_Hook db 'SbieDll_Hook',0
ends
SbieDll_dll _SbieDll_dll
section '' import data readable writeable
library kernel32,'kernel32',advapi32,'advapi32'
import kernel32,\
GetProcAddress,'GetProcAddress',\
LoadLibraryExA,'LoadLibraryExA',LoadLibraryExW,'LoadLibraryExW'
import advapi32,\
CreateRestrictedToken,'CreateRestrictedToken',SaferComputeTokenFromLevel,'SaferComputeTokenFromLevel'
section '' export data readable
export 'SbieSRP.dll',\
InjectDllMain,'InjectDllMain'
section '' data discardable readable
data fixups
if ~ $-$$
dd 0,8
end if
end data
@
REM your working directory should be one level above your FASM path
@
SET "Path=%Path%;.\fasmw17122"
SET "INCLUDE=.\fasmw17122\INCLUDE"
@
FASM.EXE "SbieSRP.asm"
REM flat assembler version 1.71.22 (1048576 kilobytes memory)
REM 5 passes, 3072 bytes.
@
:: AUTOHOTKEY DEBUG TEST CALLS
@
ECHO DllCall("LoadLibraryExA","UPtr",NULL,"UPtr",NULL,"UInt",0xFFFFFFFF)|AutoHotkeyA32.exe *
ECHO DllCall("LoadLibraryExW","UPtr",NULL,"UPtr",NULL,"UInt",0xFFFFFFFF)|AutoHotkeyU32.exe *
ECHO DllCall("advapi32\CreateRestrictedToken","UPtr",VOID,"UInt",0xFFFFFFFF,"UInt",VOID, "UPtr",NULL,"UInt",VOID,"UPtr",NULL,"UInt",VOID,"UPtr",NULL,"UPtrP",VOID)|AutoHotkeyU32.exe *
ECHO DllCall("advapi32\SaferComputeTokenFromLevel","UPtr",VOID,"UPtr",NULL,"UPtr",VOID,"UInt",0xFFFFFFFF,"UPtr",VOID)|AutoHotkeyU32.exe *
@
AUTOHOTKEY POC TEST
Code: Select all
Global NULL:=0
Global TOKEN_ALL_ACCESS:=0xF01FF
Global SANDBOX_INERT:=0x2
;
szApplicationName:="C:\test\Dialog42.exe"
;
hToken:=""
hNewToken:=""
sPI:=""
VarSetCapacity(sPI,A_PtrSize==8?24:16)
sSI:=""
if(DllCall("advapi32\OpenProcessToken","UPtr",DllCall("GetCurrentProcess","UPtr"),"UInt",TOKEN_ALL_ACCESS,"UPtrP",hToken,"Int"))
{
if(DllCall("advapi32\CreateRestrictedToken","UPtr",hToken,"UInt",SANDBOX_INERT,"UInt",0,"UPtr",NULL,"UInt",0,"UPtr",NULL,"UInt",0,"UPtr",NULL,"UPtrP",hNewToken,"Int"))
{
VarSetCapacity(sSI,cb:=A_PtrSize==8?96:68,0)
NumPut(cb,sSI,"UInt")
if(DllCall("advapi32\CreateProcessAsUser","UPtr",hNewToken,"Str",szApplicationName,"UPtr",NULL,"UPtr",NULL,"UPtr",NULL,"Int",TRUE,"UInt",0,"UPtr",NULL,"UPtr",NULL,"UPtr",&sSI,"UPtr",&sPI,"Int"))
{
MsgBox,0x40040,,process created
}
else
MsgBox,% "CreateProcessAsUser fail`n" FormatMessage(A_LastError)
}
else
MsgBox,% "CreateRestrictedToken fail`n" FormatMessage(A_LastError)
}
else
MsgBox,% "OpenProcessToken fail`n" FormatMessage(A_LastError)
FormatMessage(dwMessageId)
{
static Buffer
VarSetCapacity(Buffer,nSize:=3000)
DllCall("FormatMessage","UInt",0x00001000,"UPtr",0,"UInt",dwMessageId,"UInt",0,"Str",Buffer,"UInt",nSize//2,"UPtr",0)
return RegExReplace(Buffer,"(.*)[`r`n]*$","$1")
}
-
- Posts: 291
- Joined: Wed Jul 04, 2012 6:40 pm
- Location: St. Louis area
Re: SandBoxIE to harden SRP (software restriction policy)?
My god, my god, my god. (This is about BUCKAROO's reply; I could no longer not reply.)
I saw this thread back in December when I checked backed here for the first time in awhile (been doing other stuff), and was going to tell ya, catBot, don't worry, I'll have something for us to take care of this in Sandboxie by Christmas/New Years (been meaning to for a long time, but it's not as trivial/obvious to do as BUCKAROO did; that naive approach I would have made available long ago). But I've still been using time to get other stuff done, so I'm glad I waited to say anything that I didn't give in time!
And I wanted to make a nice little GUI demo program you could use to see that it's working, etc.
Anyway, I was going to say before that I wouldn't expect them to do anything to prevent this bypass, nor would I ever expect them to (yes, I said "expect them" twice).
I saw this thread back in December when I checked backed here for the first time in awhile (been doing other stuff), and was going to tell ya, catBot, don't worry, I'll have something for us to take care of this in Sandboxie by Christmas/New Years (been meaning to for a long time, but it's not as trivial/obvious to do as BUCKAROO did; that naive approach I would have made available long ago). But I've still been using time to get other stuff done, so I'm glad I waited to say anything that I didn't give in time!
And I wanted to make a nice little GUI demo program you could use to see that it's working, etc.
What's this about...? Curt's comment, I guess (yes, silly, but they're not going to do any of this).catBot wrote:I'd like to bring this up.
Could you please create a beta/testing version to check for alleged compatibility issues?
Thank you in advance.
Anyway, I was going to say before that I wouldn't expect them to do anything to prevent this bypass, nor would I ever expect them to (yes, I said "expect them" twice).
Really? And what malicious stuff is actually doing that vs trying to load a real file? (Albeit not even attempting to use these "SRP bypass" flags...)BUCKAROO wrote:SRP, pfft, if it's spyware it's gonna (down)load in & execute any binary from memory, ASLR actually makes that a lot likelier.
XP Home-as-Pro SP3 (Admin) w/ continued updates (Embedded/POSReady 2009)
> Permissions + "2-level" SRP, latest Sandboxie (Pro/registered), EMET 4, no anti-anything (ever)
Did I make tzuk crazed... in his last days?
> Permissions + "2-level" SRP, latest Sandboxie (Pro/registered), EMET 4, no anti-anything (ever)
Did I make tzuk crazed... in his last days?
-
- Posts: 291
- Joined: Wed Jul 04, 2012 6:40 pm
- Location: St. Louis area
Re: SandBoxIE to harden SRP (software restriction policy)?
Sorry BUCKAROO, but all I could think after seeing your post is, "My god, please make it stop!"
No reason for assembly, basically ever. You just need a few lines of C. The compiler will generate much better code (usual case I mean; this simple stuff I don't see anything obvious). And I was like, "Why are you only ANDing the flags, instead of "& ~SOME_FLAG" but I see you defined them (named confusingly). The compiler should be doing that! (Even the assembler could... should?)
AutoHotkey... I hate that junk.
Where's the 64-bit for Vista? The answer is "assembly," right?
And, "you're doing it wrong." I didn't think it was good to hook at that high of a level (Advapi32 is too high up, for sure). What if malware, etc. bypasses those high level functions and begins to start a process or load a DLL in a more "manual" way using lower level functions directly (e.g. after calls that use those flags)?
So, long ago I was looking down to NtQueryInformationToken -- and still wondering if that was too high-level? Not sure how deep/low to go, so that's what I was sticking on, unless someone can provide better insight to image loading at the lowest level.
Finally, there's no need to hook the *A functions (ANSI) since they call the *W functions... Right?
No reason for assembly, basically ever. You just need a few lines of C. The compiler will generate much better code (usual case I mean; this simple stuff I don't see anything obvious). And I was like, "Why are you only ANDing the flags, instead of "& ~SOME_FLAG" but I see you defined them (named confusingly). The compiler should be doing that! (Even the assembler could... should?)
AutoHotkey... I hate that junk.
Where's the 64-bit for Vista? The answer is "assembly," right?
And, "you're doing it wrong." I didn't think it was good to hook at that high of a level (Advapi32 is too high up, for sure). What if malware, etc. bypasses those high level functions and begins to start a process or load a DLL in a more "manual" way using lower level functions directly (e.g. after calls that use those flags)?
So, long ago I was looking down to NtQueryInformationToken -- and still wondering if that was too high-level? Not sure how deep/low to go, so that's what I was sticking on, unless someone can provide better insight to image loading at the lowest level.
Finally, there's no need to hook the *A functions (ANSI) since they call the *W functions... Right?
Re: SandBoxIE to harden SRP (software restriction policy)?
Yeah. I wouldn't know exactly what stuff is doing that, but it's what I would do (were I that way inclined).DR_LaRRY_PEpPeR wrote:Really? And what malicious stuff is actually doing that vs trying to load a real file? (Albeit not even attempting to use these "SRP bypass" flags...)BUCKAROO wrote:SRP, pfft, if it's spyware it's gonna (down)load in & execute any binary from memory, ASLR actually makes that a lot likelier.
If the payload - let's say it's a ready-made trojan for the lazy skid - had its relocations section stripped (no fixups), but oh look, ASLR has conveniently freed up the payload's image base load address for the lazy, i.e. me, so time for my crafty loader to work its magic!DR_LaRRY_PEpPeR wrote:And, "you're doing it wrong." I didn't think it was good to hook at that high of a level (Advapi32 is too high up, for sure). What if malware, etc. bypasses those high level functions and begins to start a process or load a DLL in a more "manual" way using lower level functions directly (e.g. after calls that use those flags)?
So, long ago I was looking down to NtQueryInformationToken -- and still wondering if that was too high-level? Not sure how deep/low to go, so that's what I was sticking on, unless someone can provide better insight to image loading at the lowest level.
It is just a matter of having read in the binary (easily hidden in the main program or gotten creatively from the www, whatever). If no reserved section, a dabble of VirtualAlloc(Ex) then, WriteProcessMemory (but again hardly necessary for our current process), and there is a further stage I'll shrug off too (naively). Before lastly, either CreateThread for it, or jump the CPU there; that old black magic...
Windows image loading restrictions = defeated. So, SRP is (censored). And so should be the idea that any in-process Sbie InjectDll or system dll be invulnerable, forget about it -- without authoritatively higher up helper service and driver outside handling (censored), that agency Sbie has and we hope it does its jobs well enough.
Mmhmm. Not disagreeing but not concurring.DR_LaRRY_PEpPeR wrote:No reason for assembly, basically ever. You just need a few lines of C. The compiler will generate much better code (usual case I mean; this simple stuff I don't see anything obvious). And I was like, "Why are you only ANDing the flags, instead of "& ~SOME_FLAG" but I see you defined them (named confusingly). The compiler should be doing that! (Even the assembler could... should?)
AutoHotkey... I hate that junk.
I wanted to code an "InjectExe" [a Sbie .dll Contributed Utility even] for the reason that I detest Visual Studio and I want to get the latest AutoHotkey*.exe releases loaded and running in its own remote thread in each and every sandboxed process Haha so I can rejig hooked functions left and right with relative ease. And AutoHotkey's added memory footprint (and cpu time) would not bother me, I just do very much like a C/C++ style scripting language and this interpreter for Win centric shortcutting.
AutoHotkey script = high if not highest level language.
Flat assembler = low if not lowest level language next to machine code, and did I mention it rolls out flat binaries, as flat and linear as the source code is presented.
One that might mash the two together and use AHK to render FASM for on-the-fly assembalage, has best of both worlds. I've got a license to blah, you know!
Pfff. But but it's not my real competition entry...!DR_LaRRY_PEpPeR wrote:Finally, there's no need to hook the *A functions (ANSI) since they call the *W functions... Right?
Haha yeah that definitely, and that WIndows 8.1 core home version has no AppLocker for me to bother or to even test any of this SRP stuff.DR_LaRRY_PEpPeR wrote:Where's the 64-bit for Vista? The answer is "assembly," right?
Amending, I will add that it is possible to create a dll that has first say in hardening in-process security, but I won't be coding it unless in the key of middle "Clang", alas, my time and my health is not permitting. I must choose life and pick myself up, if I am to go on living, and really living, I need to forget about controlling every facet of "code". (Cool story.)
Re: SandBoxIE to harden SRP (software restriction policy)?
Make It Stop - volume 2:
SbieSRP8.dll is here for Vista feat. 64-bit. I suppose it works haha but I have both running globally, you want both for 32/64-bit processes. Process Explorer no longer reckons they're suspicious (adding friendly section names = no more purple highlight and "Image is probably packed" rubbish).
Btw, do too need to hook LoadLibraryExA, tests showed me! And it would be wrong to only hook something [(still) not doing this] at the deepest level at the user mode border, there could have been preparations on account of those flags, you never know.
=== === ===
Edit 2015/05/03:
64-BIT NEVER DID ANYTHING.
Does not pass initialization!
rcx,rdx,r8,r9; Too lazy to fix.
=== === ===
Edit 2015/05/08:
Removed binaries archive.
SbieSRP8.dll is here for Vista feat. 64-bit. I suppose it works haha but I have both running globally, you want both for 32/64-bit processes. Process Explorer no longer reckons they're suspicious (adding friendly section names = no more purple highlight and "Image is probably packed" rubbish).
Btw, do too need to hook LoadLibraryExA, tests showed me! And it would be wrong to only hook something [(still) not doing this] at the deepest level at the user mode border, there could have been preparations on account of those flags, you never know.
=== === ===
Edit 2015/05/03:
64-BIT NEVER DID ANYTHING.
Does not pass initialization!
rcx,rdx,r8,r9; Too lazy to fix.
=== === ===
Code: Select all
; Toggle build architecture
PtrSize fix 4 ; 32-bit
;PtrSize fix 8 ; 64-bit
;
PtrSizeAsc='0'+PtrSize
SbieSRP_dll equ 'SbieSRP',PtrSizeAsc,'.dll'
match =4,PtrSize{format PE GUI 4.0 DLL}
match =8,PtrSize{format PE64 GUI 5.0 DLL}
entry DllEntryPoint
match =4,PtrSize{include 'WIN32AX.INC'}
match =8,PtrSize{include 'WIN64AX.INC'}
!LOAD_IGNORE_CODE_AUTHZ_LEVEL=not 0x10
!SANDBOX_INERT=not 0x2
!SAFER_TOKEN_MAKE_INERT=not 0x4
macro m_lp [m]
{
if PtrSize=4
m dd ?
else if PtrSize=8
m dq ?
end if
}
macro mioli op1*
{
if PtrSize=4
mov op1,eax
else if PtrSize=8
mov op1,rax
end if
}
macro sioli op1*
{
if PtrSize=4
mov eax,op1
else if PtrSize=8
mov rax,op1
end if
}
macro tioli
{
if PtrSize=4
test eax,eax
else if PtrSize=8
test rax,rax
end if
}
struc kernel32_
{
m_lp .LoadLibraryExA,.LoadLibraryExW
}
struc advapi32_
{
m_lp .CreateRestrictedToken,.SaferComputeTokenFromLevel
}
struc SbieDll_
{
m_lp .Hook
}
section '.data' data readable writeable
kernel32 kernel32_
advapi32 advapi32_
SbieDll SbieDll_
section '.text' code executable readable
proc DllEntryPoint hinstDLL,fdwReason,lpvReserved
invoke DisableThreadLibraryCalls,[hinstDLL]
sioli TRUE
ret
endp
proc detour_LoadLibraryExA lpFileName,hFile,dwFlags
and [dwFlags],!LOAD_IGNORE_CODE_AUTHZ_LEVEL
invoke kernel32.LoadLibraryExA,[lpFileName],[hFile],[dwFlags]
ret
endp
proc detour_LoadLibraryExW lpFileName,hFile,dwFlags
and [dwFlags],!LOAD_IGNORE_CODE_AUTHZ_LEVEL
invoke kernel32.LoadLibraryExW,[lpFileName],[hFile],[dwFlags]
ret
endp
proc detour_CreateRestrictedToken ExistingTokenHandle,Flags,DisableSidCount,SidsToDisable,DeletePrivilegeCount,PrivilegesToDelete,RestrictedSidCount,SidsToRestrict,NewTokenHandle
and [Flags],!SANDBOX_INERT
invoke advapi32.CreateRestrictedToken,[ExistingTokenHandle],[Flags],[DisableSidCount],[SidsToDisable],[DeletePrivilegeCount],[PrivilegesToDelete],[RestrictedSidCount],[SidsToRestrict],[NewTokenHandle]
ret
endp
proc detour_SaferComputeTokenFromLevel LevelHandle,InAccessToken,OutAccessToken,dwFlags,lpReserved
and [dwFlags],!SAFER_TOKEN_MAKE_INERT
invoke advapi32.SaferComputeTokenFromLevel,[LevelHandle],[InAccessToken],[OutAccessToken],[dwFlags],[lpReserved]
ret
endp
proc InjectDllMain hSbieDll,UnusedParameter
invoke GetProcAddress,[hSbieDll],SbieDll_dll.SbieDll_Hook
mioli [SbieDll.Hook]
tioli
jz @f
invoke SbieDll.Hook,'LoadLibraryExA',[LoadLibraryExA],detour_LoadLibraryExA
mioli [kernel32.LoadLibraryExA]
invoke SbieDll.Hook,'LoadLibraryExW',[LoadLibraryExW],detour_LoadLibraryExW
mioli [kernel32.LoadLibraryExW]
invoke SbieDll.Hook,'CreateRestrictedToken',[CreateRestrictedToken],detour_CreateRestrictedToken
mioli [advapi32.CreateRestrictedToken]
invoke SbieDll.Hook,'SaferComputeTokenFromLevel',[SaferComputeTokenFromLevel],detour_SaferComputeTokenFromLevel
mioli [advapi32.SaferComputeTokenFromLevel]
@@:
ret
endp
struc SbieDll_dll_
{
.SbieDll_Hook db 'SbieDll_Hook',0
}
SbieDll_dll SbieDll_dll_
section '.idata' data readable import
library kernel32_dll,'kernel32.dll',advapi32_dll,'advapi32.dll'
import kernel32_dll,\
DisableThreadLibraryCalls,'DisableThreadLibraryCalls',GetProcAddress,'GetProcAddress',\
LoadLibraryExA,'LoadLibraryExA',LoadLibraryExW,'LoadLibraryExW'
import advapi32_dll,\
CreateRestrictedToken,'CreateRestrictedToken',SaferComputeTokenFromLevel,'SaferComputeTokenFromLevel'
section '.edata' data readable export
export SbieSRP_dll,InjectDllMain,'InjectDllMain'
section '.reloc' data discardable readable fixups
postpone
{
display '@',10
display ':: INSTALL FROM AN ELEVATED COMMAND PROMPT',10
display 'COPY /B /Y "',SbieSRP_dll,'" "C:\',SbieSRP_dll,'"',10
display '@',10
display 'ATTRIB +R "C:\',SbieSRP_dll,'"',10
display '@',10
display 'SET "Sbie=%ProgramFiles%\Sandboxie"',10
display 'SET "SbieIni="%Sbie%\SbieIni.exe""',10
if PtrSize=4
display '%SbieIni% append GlobalSettings InjectDll C:\SbieSRP4.dll',10
else if PtrSize=8
display '%SbieIni% append GlobalSettings InjectDll64 C:\SbieSRP8.dll',10
end if
display '@'
}
Removed binaries archive.
Last edited by BUCKAROO on Sat May 09, 2015 3:28 am, edited 3 times in total.
Re: SandBoxIE to harden SRP (software restriction policy)?
BUCKAROO, DR_LaRRY_PEpPeR,
Any update on the topic?
Any update on the topic?
winXP-SP3 hacked into POSReady2009.
Re: SandBoxIE to harden SRP (software restriction policy)?
Corrected 64-bit support... (for fun...)
I hope I am not forgetting something this time
(apart from the doctor's approved implementation - not happening).
I hope I am not forgetting something this time
(apart from the doctor's approved implementation - not happening).
Code: Select all
; Toggle build architecture
PtrSize fix 4 ; 32-bit
;PtrSize fix 8 ; 64-bit
; Toggle
OutputDebug equ 0
;OutputDebug equ 1
PtrSizeAsc='0'+PtrSize
SbieSRP_dll equ 'SbieSRP',PtrSizeAsc,'.dll'
match =4,PtrSize{format PE GUI 4.0 DLL}
match =8,PtrSize{format PE64 GUI 5.0 DLL}
entry DllEntryPoint
match =4,PtrSize{include 'WIN32WXP.INC'}
match =8,PtrSize{include 'WIN64WXP.INC'}
; BUCKAROO's trivial customization to fasmw17122\INCLUDE\MACRO\*
; Macroinstructions for making import section (32-bit or 64-bit)
macro import name,[label,string]
{
common
if PtrSize=4
rb (- rva $) and 3
else if PtrSize=8
rb (- rva $) and 7
end if
if defined name#.referred
name#.lookup:
forward
if used label
if string eqtype ''
local _label
if PtrSize=4
dd RVA _label
else if PtrSize=8
dq RVA _label
end if
else
if PtrSize=4
dd 80000000h + string
else if PtrSize=8
dq 8000000000000000h + string
end if
end if
end if
common
if $ > name#.lookup
name#.redundant = 0
if PtrSize=4
dd 0
else if PtrSize=8
dq 0
end if
else
name#.redundant = 1
end if
name#.address:
forward
if used label
if string eqtype ''
if PtrSize=4
label dd RVA _label
else if PtrSize=8
label dq RVA _label
end if
else
if PtrSize=4
label dd 80000000h + string
else if PtrSize=8
label dq 8000000000000000h + string
end if
end if
end if
common
if ~ name#.redundant
if PtrSize=4
dd 0
else if PtrSize=8
dq 0
end if
end if
forward
if used label & string eqtype ''
_label dw 0
label#.ansi:
db string,0
rb RVA $ and 1
end if
common
end if
}
match =4,PtrSize
{
dbz equ dd
wax equ eax
}
match =8,PtrSize
{
dbz equ dq
wax equ r10
}
macro mioli op1*
{
if PtrSize=4
mov op1,eax
else if PtrSize=8
mov op1,rax
end if
}
macro sioli op1*
{
if PtrSize=4
mov eax,op1
else if PtrSize=8
mov rax,op1
end if
}
macro tioli
{
if PtrSize=4
test eax,eax
else if PtrSize=8
test rax,rax
end if
}
macro m_lp [m]
{
m dbz ?
}
struc kernel32_
{
m_lp .LoadLibraryExA,.LoadLibraryExW
}
struc advapi32_
{
m_lp .CreateRestrictedToken,.SaferComputeTokenFromLevel
}
struc SbieApi_
{
m_lp .QueryProcess
}
struc SbieDll_
{
m_lp .Hook
}
struc SbieDll_dll_
{
.SbieApi_QueryProcess db 'SbieApi_QueryProcess',0
.SbieDll_Hook db 'SbieDll_Hook',0
}
!LOAD_IGNORE_CODE_AUTHZ_LEVEL=not 0x10
!SANDBOX_INERT=not 0x2
!SAFER_TOKEN_MAKE_INERT=not 0x4
section '.data' data readable writeable
SbieSRP_err_fail db SbieSRP_dll,' inject stage fail. - BUCKAROO',0
;[pid]
; [session_id] app [box_name] "image_name" ProcName "FileName" (flags was flags)
;[5592] [1] SbieSRP8 [DefaultBox] "AutoHotkeyU64.exe" CreateRestrictedToken "" (0x00000000 was 0x00000002)
szDbgFmt du '[%d] %hs [%ls] "%ls" %hs "%hs%ls" (0x%08X was 0x%08X)',0
szSbieSRP db 'SbieSRP',PtrSizeAsc,0
align 8
lpBuffer dbz ?
process_id dbz ?
box_name rw 34
image_name rw 96
sid_string rw 96
session_id dd ?
kernel32 kernel32_
advapi32 advapi32_
SbieApi SbieApi_
SbieDll SbieDll_
SbieDll_dll SbieDll_dll_
section '.text' code executable readable
proc DllEntryPoint hinstDLL,fdwReason,lpvReserved
if PtrSize=8
mov [hinstDLL],rcx
end if
invoke DisableThreadLibraryCalls,[hinstDLL]
match =1,OutputDebug{invoke OutputDebugStringA,szSbieSRP}
sioli TRUE
ret
endp
proc detour_LoadLibraryExA lpFileName,hFile,dwFlags
if PtrSize=4
mov wax,[dwFlags]
else if PtrSize=8
mov [lpFileName],rcx
mov [hFile],rdx
mov [dwFlags],r8
mov wax,r8
end if
and [dwFlags],!LOAD_IGNORE_CODE_AUTHZ_LEVEL
match =0,OutputDebug
{
cmp [dwFlags],wax
je @f
}
cinvoke wsprintfW,[lpBuffer],szDbgFmt,[session_id],szSbieSRP,box_name,image_name,LoadLibraryExA.ansi,[lpFileName],NULL,[dwFlags],wax
invoke OutputDebugStringW,[lpBuffer]
@@:
invoke kernel32.LoadLibraryExA,[lpFileName],[hFile],[dwFlags]
ret
endp
proc detour_LoadLibraryExW lpFileName,hFile,dwFlags
if PtrSize=4
mov wax,[dwFlags]
else if PtrSize=8
mov [lpFileName],rcx
mov [hFile],rdx
mov [dwFlags],r8
mov wax,r8
end if
and [dwFlags],!LOAD_IGNORE_CODE_AUTHZ_LEVEL
match =0,OutputDebug
{
cmp [dwFlags],wax
je @f
}
cinvoke wsprintfW,[lpBuffer],szDbgFmt,[session_id],szSbieSRP,box_name,image_name,LoadLibraryExW.ansi,NULL,[lpFileName],[dwFlags],wax
invoke OutputDebugStringW,[lpBuffer]
@@:
invoke kernel32.LoadLibraryExW,[lpFileName],[hFile],[dwFlags]
ret
endp
proc detour_CreateRestrictedToken ExistingTokenHandle,Flags,DisableSidCount,SidsToDisable,DeletePrivilegeCount,PrivilegesToDelete,RestrictedSidCount,SidsToRestrict,NewTokenHandle
if PtrSize=4
mov wax,[Flags]
else if PtrSize=8
mov [ExistingTokenHandle],rcx
mov [Flags],rdx
mov [DisableSidCount],r8
mov [SidsToDisable],r9
mov wax,rdx
end if
and [Flags],!SANDBOX_INERT
match =0,OutputDebug
{
cmp [Flags],wax
je @f
}
cinvoke wsprintfW,[lpBuffer],szDbgFmt,[session_id],szSbieSRP,box_name,image_name,CreateRestrictedToken.ansi,NULL,NULL,[Flags],wax
invoke OutputDebugStringW,[lpBuffer]
@@:
invoke advapi32.CreateRestrictedToken,[ExistingTokenHandle],[Flags],[DisableSidCount],[SidsToDisable],[DeletePrivilegeCount],[PrivilegesToDelete],[RestrictedSidCount],[SidsToRestrict],[NewTokenHandle]
ret
endp
proc detour_SaferComputeTokenFromLevel LevelHandle,InAccessToken,OutAccessToken,dwFlags,lpReserved
if PtrSize=4
mov wax,[dwFlags]
else if PtrSize=8
mov [LevelHandle],rcx
mov [InAccessToken],rdx
mov [OutAccessToken],r8
mov [dwFlags],r9
mov wax,r9
end if
and [dwFlags],!SAFER_TOKEN_MAKE_INERT
match =0,OutputDebug
{
cmp [dwFlags],wax
je @f
}
cinvoke wsprintfW,[lpBuffer],szDbgFmt,[session_id],szSbieSRP,box_name,image_name,SaferComputeTokenFromLevel.ansi,NULL,NULL,[dwFlags],wax
invoke OutputDebugStringW,[lpBuffer]
@@:
invoke advapi32.SaferComputeTokenFromLevel,[LevelHandle],[InAccessToken],[OutAccessToken],[dwFlags],[lpReserved]
ret
endp
proc InjectDllMain hSbieDll,UnusedParameter
if PtrSize=8
mov [hSbieDll],rcx
end if
invoke GetProcAddress,[hSbieDll],SbieDll_dll.SbieDll_Hook
mioli [SbieDll.Hook]
tioli
jz @f
invoke GetProcAddress,[hSbieDll],SbieDll_dll.SbieApi_QueryProcess
mioli [SbieApi.QueryProcess]
tioli
jz @f
invoke VirtualAlloc,NULL,2045,MEM_COMMIT+MEM_RESERVE,PAGE_READWRITE
mioli [lpBuffer]
tioli
jz @f
invoke GetCurrentProcessId
mioli [process_id]
invoke SbieApi.QueryProcess,[process_id],box_name,image_name,sid_string,session_id
tioli
jnz @f
invoke SbieDll.Hook,LoadLibraryExA.ansi,[LoadLibraryExA],detour_LoadLibraryExA
mioli [kernel32.LoadLibraryExA]
tioli
jz @f
invoke SbieDll.Hook,LoadLibraryExW.ansi,[LoadLibraryExW],detour_LoadLibraryExW
mioli [kernel32.LoadLibraryExW]
tioli
jz @f
invoke SbieDll.Hook,CreateRestrictedToken.ansi,[CreateRestrictedToken],detour_CreateRestrictedToken
mioli [advapi32.CreateRestrictedToken]
tioli
jz @f
invoke SbieDll.Hook,SaferComputeTokenFromLevel.ansi,[SaferComputeTokenFromLevel],detour_SaferComputeTokenFromLevel
mioli [advapi32.SaferComputeTokenFromLevel]
tioli
jz @f
ret
@@:
invoke OutputDebugStringA,SbieSRP_err_fail
ret
endp
section '.idata' data readable import
library kernel32_dll,'kernel32.dll',advapi32_dll,'advapi32.dll',user32_dll,'user32.dll'
import kernel32_dll,\
DisableThreadLibraryCalls,'DisableThreadLibraryCalls',GetCurrentProcessId,'GetCurrentProcessId',GetProcAddress,'GetProcAddress',\
LoadLibraryExA,'LoadLibraryExA',LoadLibraryExW,'LoadLibraryExW',\
OutputDebugStringA,'OutputDebugStringA',OutputDebugStringW,'OutputDebugStringW',\
VirtualAlloc,'VirtualAlloc'
import advapi32_dll,\
CreateRestrictedToken,'CreateRestrictedToken',SaferComputeTokenFromLevel,'SaferComputeTokenFromLevel'
import user32_dll,\
wsprintfW,'wsprintfW'
section '.edata' data readable export
export SbieSRP_dll,InjectDllMain,'InjectDllMain'
section '.reloc' data discardable readable fixups
postpone
{
display '@',10
display ':: INSTALL FROM AN ELEVATED COMMAND PROMPT',10
display 'COPY /B /Y "SbieSRP.dll" "%CommonProgramFiles%\',SbieSRP_dll,'"',10
display '@',10
display 'ATTRIB +R "%CommonProgramFiles%\',SbieSRP_dll,'"',10
display '@',10
display 'SET "Sbie=%ProgramFiles%\Sandboxie"',10
display 'SET "SbieIni="%Sbie%\SbieIni.exe""',10
if PtrSize=4
display '%SbieIni% append GlobalSettings InjectDll "%CommonProgramFiles%\SbieSRP4.dll"',10
else if PtrSize=8
display '%SbieIni% append GlobalSettings InjectDll64 "%CommonProgramFiles%\SbieSRP8.dll"',10
end if
display '@'
}
- Attachments
-
- SbieSRP_20150503.zip
- SbieSRP4.dll
SbieSRP8.dll
OutputDebug\SbieSRP4.dll
OutputDebug\SbieSRP8.dll - (5.36 KiB) Downloaded 199 times
Re: SandBoxIE to harden SRP (software restriction policy)?
Will this library work on winXP-SP3 and how to use it?BUCKAROO wrote:...
I hope I am not forgetting something this time
Thank you in advance.
winXP-SP3 hacked into POSReady2009.
Who is online
Users browsing this forum: No registered users and 0 guests