After a short break (I had to teach the sec 504 in Paris for a week) I had finally the time to carry on parsing my hand written notes taken in recon Montreal 2018.
Tracing Struct accesses with struct stalker
First all let me mention that this tool works only at source code level. Yes, I was bit disappointed when I knew that. As you know C++ reversing is a very time consuming process and the tools that already exist and work at binary level depend on a lot of parameters (compilation chain, compilers, IDA version, etc). The second point that made more disappointed, is that when you read the talk title you guess that you're going to learn a lot about how identifying C++ structures techniques. The talk was more about LLDB internals than the tool itself!
The speaker started his talk by introducing libfuzzer (LLVM project). He pointed out that this tool mainly takes an entry point as an argument, but he underlined the fact that you might encounter some problems when you want to fuzz some arbitrary code that takes complicated structs. That was the main starting point that motivated him to write "Struct Stalker" tool by monitoring accesses to structures fields. To solve this latter problem, the researcher used the techniques of a second tool (Pointer Sequence Reverser)developed by his colleague (Nicholas Collisson).
Before moving to the main part of the talk, which deals with LLDB, he demoed "Struct Stalker" tool. Normally you can get the tool here, but once again I got a 404 error when writing this post.
The main part of this talk , as I said before, was about the lessons learned bout LLDB during the development of the previous tools. So the speaker went trough a lecture about LLDB:
At this time I stopped taking notes, as far as I'm concerned this kind of content like LLDB internals can be read quietly with a cup of coffee so I won't bother you by these details.
You can check the slides here.
Static instrumentation based on executable formats
The speaker presented a framework called LIEF. The idea behind this framework is to modify an executable structure (PE, ELF, Mach-O,etc) to do static instrumentation.
So modification that can be realized on the executable structure as: changing segment permissions, disabling ASLR, will be then managed by the OS loader and then the kernel.
Here LIEF comes to hand, this library developed in C++ exposes a friendly API and different languages bindings (Python,etc).
Some interesting modification that can be achieved by LIEF are
Finally, the speaker presented how FRIDA can be combined with LIEF to instrument Android applications. This technique consists in adding two files (libgadget.so and libgadget.config.so) into the target APK.
Slides can be downloaded here.
Discovering the iOS Instrument Server
Troy Browman goal's through this talk is to share his experience of reverse engineering Apple Instruments server.
So what is an Instruments server ? The speaker defines as a set of debugging tools as Time profiling, Leak checking, Tracking file I/O,etc.
The main question that the speaker attempted to answer is : How OSX Xcode side communicates with the iOS instruments server ? For that he started by analyzing how Xcode queries the Instruments server for the processes list.
The first step of the analysis consists in identifying the Service in charge of implementing Instruments server. That lead to DVTInstrumentsFoundation binary where core functionalities of Instruments server are located.
In that binary, the method DTDeviceInfoService runningProcesses seems to be the one called to list processes. The problem then is no cross call to this method is found.
The speaker introduced at this time the notion of DTXMessage. This latter is a class in charge of serializing/deserializing Objective-C messages. More interesting fact about this class, is that DTXMessage is a mechanism for transmitting Objective-C messages over the network.
To create a DTXMessage, the speaker decided to write a tool (dtxmsg) to log this type of messages and replay them. By the way, he presented the structure of a DTXMessage. The RE of this component helped him to write a second tool called dtxmsg_client to send his own DTXMessage buffers.
Slides can be downloaded here.
Bushwhacking your way around a bootloader
What I remember about this Talk is how the speaker managed to keep calm even if she noticed the she was presenting the wrong version of the slides :).
So I won't bullshit you here I tried to take some notes but I was lost after a while. It is all about an analysis of u-boot. A great summary of the talk can be found here and the slides here.
Exploiting User-land vulnerabilities to Get Rogue App Installed Remotely on iOS 11
Yeah, KeenTeam dropped a bomb again in this talk. These guys are really amazing !
In this talk the team presented their methodology used during Pwn2Own 2017 to pawn an iOS 11.
The talk was organized as the following:
Globally th exploitation scheme that is followed for iOS exploitation can be described as below:
For the Pwn2Own challenge there is no need to go for a Kernel bug to escape the Sandbox, the team said. However, they have to respect the OneClick policy that states that the exploit chain has to disable all the popups and alert messages.
For the Safari code execution:
The strategy then is :
One of the candidate service was Backboardd:
Regarding the exploitation the following CVEs were used/explained by the team:
The speakers explained then their techniques to exploit the double free vulnerability ,
a race condition (brute force approach is not stable, user instead OOL serailized messages with a slow parsing using CFAllocCtorAllocate with 0x20000 size instead of CFObject)
and how they bypassed ASLR (iOS share the same dyld_shared_cache_base) .
The last challenge that the team had to solve was code signing . In iOS CodeSign is enforced on code. All code must be signed by Apple, by a developer or by an Entreprise (in this two last cases a user interaction is required which is not compliant with the One Click Policy).
Webclips seems to be the solution. It appears that this not documented technology allows to install an HTML based application. The team then adopted the same approach as Pegasus APT. The technique consists in using a jsc script to trigger the vulnerability. Before that the content of the script into /Library/Webclips/Keelab/Exploit.html with an info.plist file(ULR= Attackerwebsite and fullscreen= TRUE to not open Safari). Exploit.html file will trigger the bug and bypass the SandBox and install a rogue app.
Finally the team ended their talk with a Demo of iOS 12 jailbreak !
Malware Analysis and Automation using Binary Ninja
Actually, I was a bit disappointed by this talk. Yeah the speaker attempted to promote a potential great tool Binary Ninja, but she (in my point of view) did not present a real case with real challenges that tried to solve using Binary Ninja. Instead she went for a description of the tool. Ok may be 5 slides are sufficient to introduce the tool. Yeah !In the slides , you'll find some slides about PlugX but it still the tool description took a lot of place in the talk.
Also, I do not agree with people who always try to compare a new tool to IDA pro. IDA pro is IDA pro full stop.
Slides can be downloaded here.
An Open-Source Machine-Code Decompiler
The talk is about RetDec : a tool for machine-code decompilation based on LLVM.
Actually RetDec is a set of Reversing tools chained together to get a generic code decompilation tool.
The core is based on LLVM and supports mainly 32 bits architecture as x86, ARM, PowerPC and MIPS.
RetDec starts by preprocessing a binary to extract as much information as possible from it. Indeed, this phase calls a set of file format libraries to get a binary representation of the the given file and then process it to identify the use of potential packers (yara signatures). The tool embeds a set of unpackers in addition to Avast unpacker to get the original binary image.
Another layer/tool that is implemented in RetDec is Stacofin which can be useful to detetc statically linked code.
FileInfo, is a tool in RetDec suite that can parse a lot of binary formats (PE, ELF, Mach-O,etc) and returns the results in json format.
RetDec core is based on LLVM and is in charge to transform the binary machine code to LLVM IR (using Capstone engine -Capstone2LLVMIR):
It is interesting to underline that RetDec can be used from IDA pro by adding RetDec plugin.
Slides can be downloaded here.
Unknown Known DLLs and other Code Integrity Trust Violations
No word can be said here to describe this talk. Alex Ionescu and James Forshaw did a great job !
I'll try to describe as much as possible their talk even if the content was very dense regarding the time slot they were given to speak.
Unfortunately, the slides are not available yet, so you have to wait a bit more ...
I put here all my notes, may be they are incomplete or even not accurate.
So the talk was about code integrity technologies in Windows and the flaws in its robustness. For that some notions were firstly explained by the speakers:
Code Intergrity technology can be distinguished for:
Protected Processes :
When a binary is loaded, CI checks are carried out to specify its context ( if the process is PP/PLL, policy, cache,etc). These checks depends on the machine (Phone, Xbox, Defender,etc) . CI module reads the DLLs on the disk.
Different cache levels exist :
James Forshaw tool (sandbox-attacksurface-analysis-tools) has Get-NtDirectory cmdlet to get information about KnowDLLs:
$d = Get-NtDirectory \knownDLLs
$d.SecurityDescriptor.ProcessTrustLabel
Unknown DLLs are loaded at boot then mapped.
Here, the question that the speakers will answer is : How to break the code signing a the beginning ?
To create a protected process service (Admin Only)
CreateProcessW (...,CREATE_PROTECTED_PROCESS,...) and the code ahs to have a correct signature
Trust SID : SID which defines a partial Trust : S-1-19-XXXX(process level)-YYYY(signer level)
(see RTLSidDomainForestTrust)
$p = New-Win32Process -creationFlags suspended,ProtectedProcess "....exe"
$t = Get-NtToken -Primary -Process $p.process
Trust ACEs:
SYSTEM_PROCESS_TRUST_LABEL=ACE_TYPE, you can read unknown DLLs and write unless you are a PPL process (majority of files on Windows ara catalog files signed).
Kernel Extended attributes (EA):
$Kernel (can only set by the Kernel)
$kernel-purge (don't look at it again)
EA.bin : EA cache format : _CI_ESB_EA_V3 / _CI_DATA_BLOB
Who sets the cake ?
NtSetCachedSigningLevel (undocumented API). The API allows a caller to set "validated" level ("Trust me") as long as the caller is PPL. Flag 0x02 and flag 0x40.
For driver signing the cache is not trusted at all.
Section creation bugs:
NtSatus NtSetCacheSigningLevel {
Flags --> 0 (needs ppl)
4 : to cache the signature
}
CVE 2017-11830
PPL cache attack:
Win the race as we are PPL (flag 0x02), write flag 0x40.
The USN Zero change journal Rebirth
Attempt to change USN journal before a change (CI does not check USN0 assumes it is signed) --> need physical attack.
Once you delete USN journal (USN has unique 64 bit ID however they are not randomly generated) , create a new one.
This case has been patched, you can not delet USN Journal.
The cached signing level duality
CVE 2018-8142
Section Mapping bugs
Abusing Known DLLs : write in KnownDLLs?
In conclusion , that was interesting to see how CI can be bypassed.
Tracing Struct accesses with struct stalker
First all let me mention that this tool works only at source code level. Yes, I was bit disappointed when I knew that. As you know C++ reversing is a very time consuming process and the tools that already exist and work at binary level depend on a lot of parameters (compilation chain, compilers, IDA version, etc). The second point that made more disappointed, is that when you read the talk title you guess that you're going to learn a lot about how identifying C++ structures techniques. The talk was more about LLDB internals than the tool itself!
The speaker started his talk by introducing libfuzzer (LLVM project). He pointed out that this tool mainly takes an entry point as an argument, but he underlined the fact that you might encounter some problems when you want to fuzz some arbitrary code that takes complicated structs. That was the main starting point that motivated him to write "Struct Stalker" tool by monitoring accesses to structures fields. To solve this latter problem, the researcher used the techniques of a second tool (Pointer Sequence Reverser)developed by his colleague (Nicholas Collisson).
Before moving to the main part of the talk, which deals with LLDB, he demoed "Struct Stalker" tool. Normally you can get the tool here, but once again I got a 404 error when writing this post.
The main part of this talk , as I said before, was about the lessons learned bout LLDB during the development of the previous tools. So the speaker went trough a lecture about LLDB:
- OK, at first glance LLDB , LLVM debugger ,seems to be compared to gdb, pretty scriptable and can deal with source and binary code.
- LLDB uses .lldbinit (as .gdbinit) where you can set your favorite parameters as settings set target.x86-disassembly-flavor intel
- Most useful LLDB commands : process, handle,status, continue, disassemble, breakpoint, thread, frame,memory, target, expression.
- LLDP exposes a python API (not very documented) : public API are prefixed by SB: SBBreakpoint, SBDebugger,SBTarget,SBProcess,SBThread,etc.
- Regarding LLDB python script skeleton(see slides), it should be noted that to setup a breakpoints you should write a callback function which can be sometime magic.
At this time I stopped taking notes, as far as I'm concerned this kind of content like LLDB internals can be read quietly with a cup of coffee so I won't bother you by these details.
You can check the slides here.
Static instrumentation based on executable formats
The speaker presented a framework called LIEF. The idea behind this framework is to modify an executable structure (PE, ELF, Mach-O,etc) to do static instrumentation.
So modification that can be realized on the executable structure as: changing segment permissions, disabling ASLR, will be then managed by the OS loader and then the kernel.
Here LIEF comes to hand, this library developed in C++ exposes a friendly API and different languages bindings (Python,etc).
Some interesting modification that can be achieved by LIEF are
- Hooking: by adding for example a trampoline code into the import table
- Exporting hidden function
- Code injection through shared librairies
Finally, the speaker presented how FRIDA can be combined with LIEF to instrument Android applications. This technique consists in adding two files (libgadget.so and libgadget.config.so) into the target APK.
Slides can be downloaded here.
Discovering the iOS Instrument Server
Troy Browman goal's through this talk is to share his experience of reverse engineering Apple Instruments server.
So what is an Instruments server ? The speaker defines as a set of debugging tools as Time profiling, Leak checking, Tracking file I/O,etc.
The main question that the speaker attempted to answer is : How OSX Xcode side communicates with the iOS instruments server ? For that he started by analyzing how Xcode queries the Instruments server for the processes list.
The first step of the analysis consists in identifying the Service in charge of implementing Instruments server. That lead to DVTInstrumentsFoundation binary where core functionalities of Instruments server are located.
In that binary, the method DTDeviceInfoService runningProcesses seems to be the one called to list processes. The problem then is no cross call to this method is found.
The speaker introduced at this time the notion of DTXMessage. This latter is a class in charge of serializing/deserializing Objective-C messages. More interesting fact about this class, is that DTXMessage is a mechanism for transmitting Objective-C messages over the network.
To create a DTXMessage, the speaker decided to write a tool (dtxmsg) to log this type of messages and replay them. By the way, he presented the structure of a DTXMessage. The RE of this component helped him to write a second tool called dtxmsg_client to send his own DTXMessage buffers.
Slides can be downloaded here.
Bushwhacking your way around a bootloader
What I remember about this Talk is how the speaker managed to keep calm even if she noticed the she was presenting the wrong version of the slides :).
So I won't bullshit you here I tried to take some notes but I was lost after a while. It is all about an analysis of u-boot. A great summary of the talk can be found here and the slides here.
Exploiting User-land vulnerabilities to Get Rogue App Installed Remotely on iOS 11
Yeah, KeenTeam dropped a bomb again in this talk. These guys are really amazing !
In this talk the team presented their methodology used during Pwn2Own 2017 to pawn an iOS 11.
The talk was organized as the following:
- iOS remote exploitation chain overview
- Sandbox bypass and explnation of the used Bug (CVE-2017-7162)
- Rogue application installation
- Demo
- iOS 12 hardening
Globally th exploitation scheme that is followed for iOS exploitation can be described as below:
For the Pwn2Own challenge there is no need to go for a Kernel bug to escape the Sandbox, the team said. However, they have to respect the OneClick policy that states that the exploit chain has to disable all the popups and alert messages.
For the Safari code execution:
- OS sandbox is enforced by process , but some crticial daemons don't have sandbox launched
- All 3rd webcontent app are applied with Sandbox profile
- Sandbox configuration is compiled
The strategy then is :
- Not use a kernel bug
- Find a service/daemon with no sandbox
- That service has to be reached from Safari Sandbox
- For that purpose, a tool to review each process and check Sandbox profile has been written (sb profile =0)
One of the candidate service was Backboardd:
- No Sandbox
- Complex MIG (Mach Interface Generator) interfaces (you can use jtool to list MIG interfaces)
- reachable from Safari
Regarding the exploitation the following CVEs were used/explained by the team:
- CVE-2107-13861 (iOS/MacOS kernel double free due to IOSurfaceRootUserClient not respecting MIG ownership rules)
- CVE-2017-7162 (Double free in backboardd)
The speakers explained then their techniques to exploit the double free vulnerability ,
a race condition (brute force approach is not stable, user instead OOL serailized messages with a slow parsing using CFAllocCtorAllocate with 0x20000 size instead of CFObject)
and how they bypassed ASLR (iOS share the same dyld_shared_cache_base) .
The last challenge that the team had to solve was code signing . In iOS CodeSign is enforced on code. All code must be signed by Apple, by a developer or by an Entreprise (in this two last cases a user interaction is required which is not compliant with the One Click Policy).
Webclips seems to be the solution. It appears that this not documented technology allows to install an HTML based application. The team then adopted the same approach as Pegasus APT. The technique consists in using a jsc script to trigger the vulnerability. Before that the content of the script into /Library/Webclips/Keelab/Exploit.html with an info.plist file(ULR= Attackerwebsite and fullscreen= TRUE to not open Safari). Exploit.html file will trigger the bug and bypass the SandBox and install a rogue app.
Finally the team ended their talk with a Demo of iOS 12 jailbreak !
Malware Analysis and Automation using Binary Ninja
Actually, I was a bit disappointed by this talk. Yeah the speaker attempted to promote a potential great tool Binary Ninja, but she (in my point of view) did not present a real case with real challenges that tried to solve using Binary Ninja. Instead she went for a description of the tool. Ok may be 5 slides are sufficient to introduce the tool. Yeah !In the slides , you'll find some slides about PlugX but it still the tool description took a lot of place in the talk.
Also, I do not agree with people who always try to compare a new tool to IDA pro. IDA pro is IDA pro full stop.
Slides can be downloaded here.
An Open-Source Machine-Code Decompiler
The talk is about RetDec : a tool for machine-code decompilation based on LLVM.
Actually RetDec is a set of Reversing tools chained together to get a generic code decompilation tool.
The core is based on LLVM and supports mainly 32 bits architecture as x86, ARM, PowerPC and MIPS.
RetDec starts by preprocessing a binary to extract as much information as possible from it. Indeed, this phase calls a set of file format libraries to get a binary representation of the the given file and then process it to identify the use of potential packers (yara signatures). The tool embeds a set of unpackers in addition to Avast unpacker to get the original binary image.
Another layer/tool that is implemented in RetDec is Stacofin which can be useful to detetc statically linked code.
FileInfo, is a tool in RetDec suite that can parse a lot of binary formats (PE, ELF, Mach-O,etc) and returns the results in json format.
RetDec core is based on LLVM and is in charge to transform the binary machine code to LLVM IR (using Capstone engine -Capstone2LLVMIR):
- hand coded sequences for core instructions
- Full semantics for only simple instructions
It is interesting to underline that RetDec can be used from IDA pro by adding RetDec plugin.
Slides can be downloaded here.
Unknown Known DLLs and other Code Integrity Trust Violations
No word can be said here to describe this talk. Alex Ionescu and James Forshaw did a great job !
I'll try to describe as much as possible their talk even if the content was very dense regarding the time slot they were given to speak.
Unfortunately, the slides are not available yet, so you have to wait a bit more ...
I put here all my notes, may be they are incomplete or even not accurate.
So the talk was about code integrity technologies in Windows and the flaws in its robustness. For that some notions were firstly explained by the speakers:
- Background on Windows code Integrity
- Protected processes
- Signature caching
- Trust SIDs and Trust ACEs
- Trust links in Tokens
- Known DLLs and mSection Object Mappings
Code Intergrity technology can be distinguished for:
- Kernel Mode Code Signing (KMCS): with x64 an secure boot windows drivers must be signed to be loaded. And from win 10 an extended validation certification was added
- User Mode Code Signing (UMCI) -v1: from windows 8/surface. An application can be
- 0->Unchecked, 1->Unsigned, 4->Authenticode, 8->Microsoft, 12->Windows .
- User Mode Code Signing (UMCI) -v2: Fine grained signed levels (1-15)
- 6->Store, 7->Anti Malware, 14->Windows TCB
Protected Processes :
- Deployed from Windows vista for DRM
- From Windows 8.1 Protected Processes Light (PPL) mechanism was deployed (Lsass.exe, Antivirus processes are protected)
- Hierarchy of process protection levels (Matrix)
- PP/PPL are used across the system and expanded dramatically by Windows Defender
- PP/PPL is not a security feature
When a binary is loaded, CI checks are carried out to specify its context ( if the process is PP/PLL, policy, cache,etc). These checks depends on the machine (Phone, Xbox, Defender,etc) . CI module reads the DLLs on the disk.
Different cache levels exist :
- First on the disk cache
- Second : once the image is proven
- Third : once mapped (no checks)
James Forshaw tool (sandbox-attacksurface-analysis-tools) has Get-NtDirectory cmdlet to get information about KnowDLLs:
$d = Get-NtDirectory \knownDLLs
$d.SecurityDescriptor.ProcessTrustLabel
Unknown DLLs are loaded at boot then mapped.
Here, the question that the speakers will answer is : How to break the code signing a the beginning ?
To create a protected process service (Admin Only)
CreateProcessW (...,CREATE_PROTECTED_PROCESS,...) and the code ahs to have a correct signature
Trust SID : SID which defines a partial Trust : S-1-19-XXXX(process level)-YYYY(signer level)
(see RTLSidDomainForestTrust)
$p = New-Win32Process -creationFlags suspended,ProtectedProcess "....exe"
$t = Get-NtToken -Primary -Process $p.process
Trust ACEs:
SYSTEM_PROCESS_TRUST_LABEL=ACE_TYPE, you can read unknown DLLs and write unless you are a PPL process (majority of files on Windows ara catalog files signed).
Kernel Extended attributes (EA):
$Kernel (can only set by the Kernel)
$kernel-purge (don't look at it again)
EA.bin : EA cache format : _CI_ESB_EA_V3 / _CI_DATA_BLOB
Who sets the cake ?
NtSetCachedSigningLevel (undocumented API). The API allows a caller to set "validated" level ("Trust me") as long as the caller is PPL. Flag 0x02 and flag 0x40.
For driver signing the cache is not trusted at all.
Section creation bugs:
NtSatus NtSetCacheSigningLevel {
Flags --> 0 (needs ppl)
4 : to cache the signature
}
CVE 2017-11830
PPL cache attack:
Win the race as we are PPL (flag 0x02), write flag 0x40.
The USN Zero change journal Rebirth
Attempt to change USN journal before a change (CI does not check USN0 assumes it is signed) --> need physical attack.
Once you delete USN journal (USN has unique 64 bit ID however they are not randomly generated) , create a new one.
This case has been patched, you can not delet USN Journal.
The cached signing level duality
CVE 2018-8142
Section Mapping bugs
Abusing Known DLLs : write in KnownDLLs?
In conclusion , that was interesting to see how CI can be bypassed.
No comments:
Post a Comment