Recon the con !
Recon is a very famous Reverse engineering oriented conference held in Montreal. This year I had the opportunity to attend this year Bruce Dang training training and the conference.
My first feedback is that this conference is an amazing one for those interested by computer security in general and in reverse engineering in special. And Let me tell you that this year the conference materials was extremely mind blowing !
Before I go for a summary of the main notes that I took, here are the best talks in my point of view. I put them following their given slot in the the conference:
Recon is a very famous Reverse engineering oriented conference held in Montreal. This year I had the opportunity to attend this year Bruce Dang training training and the conference.
My first feedback is that this conference is an amazing one for those interested by computer security in general and in reverse engineering in special. And Let me tell you that this year the conference materials was extremely mind blowing !
Before I go for a summary of the main notes that I took, here are the best talks in my point of view. I put them following their given slot in the the conference:
- Day 1
- Reverse Engineering Windows Defender Part II (Alexei Bulazel)
- PreVice: Static Detection of Hooking Capabilities in Machine Code (Andy Wortman,Claudiu Teodorescu,Derek Soeder)
- Meet Salinas, the first ever SMS-commanded Car Infotainment RAT (Daniel Regalado,Ken Hsu, Gerardo Iglesias)
- Pwning Intel PIN(Julian Kirsch,Zhechko Zhechev)
- Day 2
- Static instrumentation based on executable file formats (Romain Thomas)
- Discovering the iOS Instruments Server (Troy Bowman)
- Exploiting User-land vulnerabilities to Get Rogue App Installed Remotely on iOS 11 (Liang Chen, Marco Grassi)
- Unknown Known DLLs and other Code Integrity Trust Violations (Alex Ionescu, James Forshaw)
- Day 3
- Analyzing TRISIS - the first Safety Instrumented System malware (K. Reid Wightman, Jimmy Wylie)
- SiliVaccine: North Korea's weapon of Mass Detection (Mark Lechtik, Michael Kajiloti)
- PWN Flash with Reflection and HashTables (Tao Yan, Bo Qu)
Reverse Engineering Windows Defender Part II
You might go and start following this guy on Twitter, his talk is one of the best that I can recommend. His previous studies concern inner working of antivirus engines. The talk, which can be considered a second part of a fist talk.
The speaker explains in his talk the methodology that he adopted to reverse Windows Defender Antivirus engine and sheds light on all the challenges where he struggled during his analysis. The cool thing that I appreciate in his talk is the fact that he went through the talk smoothly by insisting on the process itself and not throwing technical details ont the face of the attendees.
Windows defender is a the builtin Windows antivirus engine, that run with SYSTEM privileges in an unsandboxed process. Alexei's research focuses this time on reing the binary emulator in charge to scan malicious code.
The Antivirus engine is an emulator (not virtualization) that loads an unknown binary, run it from its entrypoint and collect observations basing on various heuristics. For that the emulator has to manage to emulate the cpu, OS, OS Api and the environnement (filesystem, processes, settings,etc).
Alexei's used his previous works about antivirus engine that allowed him to develop techniques for introspecting the antivirus engine and leaking his internal structures and functions.
The main targets of the research are:
- Microsoft Malware Protection Engine: mpam-fe.exe
- Microsoft Malware Protection: mpengine.dll
- Signature Update Stub: MPSigStub.exe
- Signature databases
- mpasbase.vdm
- mpasdlta.vdm
- mpavbase.vdm
- mpavdlta.vdm
The analysis process as for each reing project consisted in :
- Static analysis phase : using IDa pro, public MS Pdbs and bindiffs basing on Google Project 0 findings. Some other tools were used especially for code coverage as Lighthouse IDA plugin and Taviso's Coverage tool.
- Dynamic phase: this one seemed to be complicated knowing the defender components run in a protected Windows process and the scanning process may not be triggered on demand and that could reduce the code reachability. That where Taviso's tool comes in hand, LoadLibrary and especially mpclient.exe allows load Defender engine and exposes its interfaces. Alexei's demoed this tool the main workflow was : mpclient.exe Eicar.com --> WinApi emulation --> _rsignal(Defender engine interface) --> Engine emulator.
Reing the engine components allowed to make some observations: When a malware is getting emulated, _rsignal (main entrypoint) function is called, it takes a buffer as an argument. The emulation initialization step starts then to allocate memory, init various objects, load the binary, init emulated DLLs and start recording heuristics. The cpu emulation consists in a dynamic translation of instructions (IL lifting : IL-tox-86 Jit translation).
For emulator instrumentation task, the idea was writing a custom malware that can install a hook in an internal engine structure called g_syscalls (Winexec). And for mapping emulator adresses a hook has been installed on OutputDebugStringA. However, a binary might not be emulated if it has some characteristics(low entropy, linking against unknown DLLs).
Alexei's then explained how he dumped the virtual file system and virtual processes (apparently using the same trick as OutputDebugStringA).
Windows API emulation seems to be based on two DLL types:
- Emulated ones : VDLL, that stay inside the emulator, and complex ones are coded to return hard coded valus
- Normal ones: triggers a syscall outside the emulator.
The UM-KM emulator communication is carried out using an internal emulator instraction function called api_call that takes as arguments : crc32(Dll_name) ^ crc32(dll_function). The disaseembky of api_call still a challenge and may be presented in a future GTFO || POC paper.
api_call links emulator Apis to the outside world.
Kernel emulator functions are embedded in native code. This kernel has its own Object manager but the managed objects are fewer than a normal kernel, there are aonly : File, Thread, Event, Mutant and semaphore objects (dt mpengine!objectmanager.FileObject). Objects are stored in a map
Last but not least, Alexei exposes some intersing Defender engine functions : MpaddToScanqueue, MpCreateMemeryEngine and MpReportEvent.
Finally, Alexei pointed out that mpengine.dll embeds also other components as unpackers, parsers, scanning engines,etc. And It might be interesting to bootstrap a research project on that. Main developed code will be published at BH.
NB: Emulator IL was not dumped but it can be doable.
Cloudy With a Chance of Malware
I was not very excited by talk may be because I'm not interested by Threat Intelligence field. However, I'll try to stay partial when writing my notes.
Marika Chauvin presented a comparison between two malwares KasperAgent and Cloudy in order to highlight their differences and similarities.
The story begins with KasperAgent which seemed linked to Micropsia Android malware. The first campaign was in May 2017, one of the main indicator related to this malware was the use of a specific User Agent : OPAER. This malware targeted Palestinian authorities using fake administrative documents. Some pdb strings seem to be used by this malware.
The analysis of KasperAgent allowed to spot a second variety called Cloudy, however the attack vector used by this malware consisted in fake document used to be exchanged between inter-nation relation states.
At the opposite of KasperAgent, Cloudy malware target other countries as : Israel, India and UAE.
Both malware were attributed UAE.
SiliVaccine: North Korea's weapon of Mass Detection
That was an interesting talk where the speakers shed light on some shady zones inside a north Korean antivirus known as Silivaccine.
First of all, Checkpoint resarchers said that they obtained the antivirus from Martyn Wiliams who's a journalist specialized in North Korea.
After its installation, the speakers presented the general picture of the antivirus architecture. The antivirus components can be splitted into:
During their investigation, the researcher stumbled from surprise to surprise. Looking at the strings, allows them to spot a DLL name (vspai32.dll) which belongs to Trend Micro Antivirus. In addition to that the bindiffing between Silivaccine and Trend Micro dlls resulted in 100% match and similar call graphs. The only differences concern inlining some functions in Sillivaccine (that might let suppose that Silivvacine has access to some source code) .
As Silivaccine has potentially the same antivirus engine as TrendMicro, Checkpoint researchers wondered if it has the same database signature format. Hence, they find that Silivaccine has added an encryption layer to Trend Micro signature databases (using "Pattern Encryption" as an encryption key in Korean keyboard). Moreover, Silivaccine authors modified the naming convention of the virus and malwares that can be identified (TM : MAL_NUCRP_5 becomes mal.nucrp.f in SV) . By the way they discovered that this malware is white-listed by SV even this specimen is a generic one. They did not come across about the reason of this exception.
Regarding KM drivers, it seems that they were packed using an old Russian packer (simple xor with 0x42):
Some coding styles made the analysis funnier. For example, the researchers spotted that in a UM component the length of a buffer can be set to a fixed value (0x12) and when the KM module receives the buffer it checks its length as : if ( len(buffer) == 0x12 return ERROR). Maybe the two modules were written by two different person who does not communicate.
Another joke concerns the use of debugging message with IDA pro names : Dbgprint (" sub_xxxx bah"), which may indicate that SV authors dumped a lot of code from their TrendMicro reversing sessions.
The last part of the talk focused on Silivaccine origins. Different hypothesis were emitted here (STS tech service: a ghost company, a collaboration with a Japanese company).
In all cases, it seems that Silivaccine is distributed with a MS patch signed by Kaspersky and that latter corresponds to Jaku malware first stage (may be because it targeted Martyn Wiliams).
Building a Damned Good Watch
Actually, this field is not my cup of tea. However Travis Goodspeed is a passionate security researcher and he's able to communicate his passion. So let's see if I picked up something or not !
So yeah Travis one day dreamed about "a nifty wristwatch. It would have years of battery life, with an MSP430 microcontroller and RPN calculator. It would be able to receive and transmit on amateur radio frequencies, in a variety of digital modes. It would look spiffy."
I suspect that you guess it, it's better for you to go to his blog and read the article, either I'll confuse with my notes.
I was not very excited by talk may be because I'm not interested by Threat Intelligence field. However, I'll try to stay partial when writing my notes.
Marika Chauvin presented a comparison between two malwares KasperAgent and Cloudy in order to highlight their differences and similarities.
The story begins with KasperAgent which seemed linked to Micropsia Android malware. The first campaign was in May 2017, one of the main indicator related to this malware was the use of a specific User Agent : OPAER. This malware targeted Palestinian authorities using fake administrative documents. Some pdb strings seem to be used by this malware.
The analysis of KasperAgent allowed to spot a second variety called Cloudy, however the attack vector used by this malware consisted in fake document used to be exchanged between inter-nation relation states.
At the opposite of KasperAgent, Cloudy malware target other countries as : Israel, India and UAE.
Both malware were attributed UAE.
SiliVaccine: North Korea's weapon of Mass Detection
That was an interesting talk where the speakers shed light on some shady zones inside a north Korean antivirus known as Silivaccine.
First of all, Checkpoint resarchers said that they obtained the antivirus from Martyn Wiliams who's a journalist specialized in North Korea.
After its installation, the speakers presented the general picture of the antivirus architecture. The antivirus components can be splitted into:
- UM components: SVshell.dll, SVkernel.dll (file scanning engine), SVregsrv.dll, SV2Tray.exe, SVupdate.exe, SVDiffUpd.exe (integrity checker), SVMain.exe and SVdealer.exe
- KM components: SVhook.sys, SVstdi2.sys (supposed to hook tcp communication but it does nothing), SVFiltmsg.sys
During their investigation, the researcher stumbled from surprise to surprise. Looking at the strings, allows them to spot a DLL name (vspai32.dll) which belongs to Trend Micro Antivirus. In addition to that the bindiffing between Silivaccine and Trend Micro dlls resulted in 100% match and similar call graphs. The only differences concern inlining some functions in Sillivaccine (that might let suppose that Silivvacine has access to some source code) .
As Silivaccine has potentially the same antivirus engine as TrendMicro, Checkpoint researchers wondered if it has the same database signature format. Hence, they find that Silivaccine has added an encryption layer to Trend Micro signature databases (using "Pattern Encryption" as an encryption key in Korean keyboard). Moreover, Silivaccine authors modified the naming convention of the virus and malwares that can be identified (TM : MAL_NUCRP_5 becomes mal.nucrp.f in SV) . By the way they discovered that this malware is white-listed by SV even this specimen is a generic one. They did not come across about the reason of this exception.
Regarding KM drivers, it seems that they were packed using an old Russian packer (simple xor with 0x42):
- SVFilter is loaded by SVdealer.exe and it's in charge of real time scanning and protection of SV binaries
- SVhook.sys: loaded by SVMain.exe and only query kernel objects without any hooking techniques and contains a lot of code that is never used.
Some coding styles made the analysis funnier. For example, the researchers spotted that in a UM component the length of a buffer can be set to a fixed value (0x12) and when the KM module receives the buffer it checks its length as : if ( len(buffer) == 0x12 return ERROR). Maybe the two modules were written by two different person who does not communicate.
Another joke concerns the use of debugging message with IDA pro names : Dbgprint (" sub_xxxx bah"), which may indicate that SV authors dumped a lot of code from their TrendMicro reversing sessions.
The last part of the talk focused on Silivaccine origins. Different hypothesis were emitted here (STS tech service: a ghost company, a collaboration with a Japanese company).
In all cases, it seems that Silivaccine is distributed with a MS patch signed by Kaspersky and that latter corresponds to Jaku malware first stage (may be because it targeted Martyn Wiliams).
Building a Damned Good Watch
Actually, this field is not my cup of tea. However Travis Goodspeed is a passionate security researcher and he's able to communicate his passion. So let's see if I picked up something or not !
So yeah Travis one day dreamed about "a nifty wristwatch. It would have years of battery life, with an MSP430 microcontroller and RPN calculator. It would be able to receive and transmit on amateur radio frequencies, in a variety of digital modes. It would look spiffy."
I suspect that you guess it, it's better for you to go to his blog and read the article, either I'll confuse with my notes.
PreVice: Static Detection of Hooking Capabilities in Machine Code
The main idea if PreVice tool is to detect hooking capabilities in Windows PE before it happens. The speakers began their talk by a demo of the tool. Then the went through a brief introduction of the different hooking (Unsanctioned interception of execution, unofficial, no contract) techniques. They distinguished between:
Before presenting the internals of PreVice tool, the speakers gave an overview of existent tools:
The static analysis approach exposed by the speaker consists in considering a program as a set of functions that gives a state instead of taking it as state that changes during the execution. The main challenges that they fixed are performance and accuracy.
So, Previce inner working includes:
Having a code view of the code they can apply a set of signature to identify potential hooking regions (ex: FS → TEB → PEB → ImageBase → ImortTable).
Meet Salinas, the first ever SMS-commanded Car Infotainment RAT
This talk was just amazing, the speakers were very enthusiastic and engaged in their explanations.
The idea here is to find a way to compromise a car infotainment system by targeting the car driver (especially his phone) instead of the car directly.
The first challenge that they had to overcome was to find an Infotainment system and its wiring diagram. Moreover, the infotainment ideally has to be an ARM architecture with a bluetooth stack, a CAN bus, USB and ethernet plug.
The first step that they achieve, once they got their Infotainment system (201B 0920-201B) is they got a shell access (after a port scan that pops up a SSH access and a password brute force attack).
To have a persistant access to the Infotainment system, the researchers exploited similar to Windows Service management (SCM) based on a configuration file (sm.conf) to add a new service after remounting system partition in read/write. This service will be used a component in the RAT design.
Before introducing how the RAT actually was developed, it is interesting to know that some Infotainment internal architecture. This latter is organized around the MMUI -Multi Medi User Interface (an opera browser + local webserver + websocket) . The MMUI is linked to other components (Service manager, Radio, GPS, Bluetooth stack, CAN bus,etc) over DBUS.
To interact with these different component, the speakers discovered a test application left by the vendor that can be configured using a xml file to trigger specific tests. Thus reversing this application allowed them to understand how to communicate with these components. By the way they crashed at this stage their infotainment 3 weeks before recon CFP closing. Hopefully they got a second access through an UART port.
Analyzing the communication between MMUI and a linked phone via Bluetooth, it was possible for them to understand how a SMS is handled by the Infotainment system.
Infotainment --> MMUI --> MSG interface/DBUS --> BDS (Bluetooth Developer Studio) --> Phone
The main idea if PreVice tool is to detect hooking capabilities in Windows PE before it happens. The speakers began their talk by a demo of the tool. Then the went through a brief introduction of the different hooking (Unsanctioned interception of execution, unofficial, no contract) techniques. They distinguished between:
- Code hooking (detours): export and import table
- System Call : SYSCALL, SYSENTER, MSR, IDT and SSDT
Before presenting the internals of PreVice tool, the speakers gave an overview of existent tools:
- VICE - catch the hooks (2004)
- System Virginity Verifier (Ruthwoska 2005)
- HoolScout (Yin et Al 2010)
- RAIDE (2006)
- HookFinder : Full system emulation
- grep IDA ouptut for suspicious calls
- Back to static analysis for kernel level rootkits (Musavi and Kharrazi)
The static analysis approach exposed by the speaker consists in considering a program as a set of functions that gives a state instead of taking it as state that changes during the execution. The main challenges that they fixed are performance and accuracy.
So, Previce inner working includes:
- Code machine to instructions translation
- Constraint propagation
- Symbolic execution
- Type information propagation
- Static Single Assignment (SSA)
Having a code view of the code they can apply a set of signature to identify potential hooking regions (ex: FS → TEB → PEB → ImageBase → ImortTable).
Meet Salinas, the first ever SMS-commanded Car Infotainment RAT
This talk was just amazing, the speakers were very enthusiastic and engaged in their explanations.
The idea here is to find a way to compromise a car infotainment system by targeting the car driver (especially his phone) instead of the car directly.
The first challenge that they had to overcome was to find an Infotainment system and its wiring diagram. Moreover, the infotainment ideally has to be an ARM architecture with a bluetooth stack, a CAN bus, USB and ethernet plug.
The first step that they achieve, once they got their Infotainment system (201B 0920-201B) is they got a shell access (after a port scan that pops up a SSH access and a password brute force attack).
To have a persistant access to the Infotainment system, the researchers exploited similar to Windows Service management (SCM) based on a configuration file (sm.conf) to add a new service after remounting system partition in read/write. This service will be used a component in the RAT design.
Before introducing how the RAT actually was developed, it is interesting to know that some Infotainment internal architecture. This latter is organized around the MMUI -Multi Medi User Interface (an opera browser + local webserver + websocket) . The MMUI is linked to other components (Service manager, Radio, GPS, Bluetooth stack, CAN bus,etc) over DBUS.
To interact with these different component, the speakers discovered a test application left by the vendor that can be configured using a xml file to trigger specific tests. Thus reversing this application allowed them to understand how to communicate with these components. By the way they crashed at this stage their infotainment 3 weeks before recon CFP closing. Hopefully they got a second access through an UART port.
Analyzing the communication between MMUI and a linked phone via Bluetooth, it was possible for them to understand how a SMS is handled by the Infotainment system.
Infotainment --> MMUI --> MSG interface/DBUS --> BDS (Bluetooth Developer Studio) --> Phone
- Receiving a SMS triggers an event in BDS
- BDS sends a notification over DBUSto MSG interface (service)
- At the other hand the MMUI usi MSG interface apis to to respond to an incoming SMS
- The SMS is stored then in a local sqlite DB (not encrypted)
The last that they have to resolve before completing the RAT is to identify the phone number linked to the car. For that they opted to sniffing DBUS communication (use dbus_monitor and dbus_send).
Finally, the attack demo consisted in:
- connecting a USB key with Salinas RAT to be installed on the Infotainment system
- Disconnecting the paired phone
- Intercepting the new pairing session
- grab the phone number by sniffing DBUS communication
- send SMS commands to the paired phone that will transfer it to the RAT.
I hope that I did not missed a point !
