Pilihanraya Kecil Permatang Pauh: 4/19/20

Friday, April 24, 2020

macSubstrate - Tool For Interprocess Code Injection On macOS

macSubstrate is a platform tool for interprocess code injection on macOS, with the similar function to Cydia Substrate on iOS. Using macSubstrate, you can inject your plugins (.bundle or .framework) into a mac app (including sandboxed apps) to tweak it in the runtime.

All you need is to get or create plugins for your target app.
No trouble with modification and codesign for the original target app.
No more work after the target app is updated.
Super easy to install or uninstall a plugin.
Loading plugins automatically whenever the target app is relaunched.
Providing a GUI app to make injection much easier.

Prepare

Disable SIP
Why should disable SIP

System Integrity Protection is a new security policy that applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted.

Usage

download macSubstrate.app, put into /Applications and launch it.
grant authorization if needed.
install a plugin by importing or dragging into macSubstrate.
launch the target app.
step 3 and step 4 can be switched
Once a plugin is installed by macSubstrate, it will take effect immediately. But if you want it to work whenever the target app is relaunched or macOS is restarted, you need to keep macSubstrate running and allow it to automatically launch at login.
uninstall a plugin when you do not need it anymore.

Plugin
macSubstrate supports plugins of .bundle or .framework, so you just need to create a valid .bundle or .framework file. The most important thing is to add a key macSubstratePlugin into the info.plist, with the dictionary value:

Key	Value
`TargetAppBundleID`	the target app's `CFBundleIdentifier`, this tells macSubstrate which app to inject.
`Description`	brief description of the plugin
`AuthorName`	author name of the plugin
`AuthorEmail`	author email of the plugin

Please check the demo plugins demo.bundle and demo.framework for details.

Xcode Templates
macSubstrate also provides Xcode Templates to help you create plugins conveniently:

ln -fhs ./macSubstratePluginTemplate ~/Library/Developer/Xcode/Templates/macSubstrate\ Plugin
Launch Xcode, and there will be 2 new plugin templates for you.

Security

SIP is a new security policy on macOS, which will help to keep you away from potential security risk. Disable it means you will lose the protection from SIP.
If you install a plugin from a developer, you should be responsible for the security of the plugin. If you do not trust it, please do not install it. macSubstrate will help to verify the code signature of a plugin, and I suggest you to scan it using VirusTotal. Anyway, macSubstrate is just a tool, and it is your choice to decide what plugin to install.

Download macSubstrate

Thursday, April 23, 2020

Reversing Rust String And Str Datatypes

Lets build an app that uses several data-types in order to see how is stored from a low level perspective.

Rust string data-types

The two first main objects are "str" and String, lets check also the constructors.

Imports and functions

Even such a basic program links several libraries and occupy 2,568Kb, it's really not using the imports and expots the runtime functions even the main.

Even a simple string operation needs 544 functions on rust:

Main function

If you expected see a clear main function I regret to say that rust doesn't seem a real low-level language In spite of having a full control of the memory.

Ghidra turns crazy when tries to do the recursive parsing of the rust code, and finally we have the libc _start function, the endless loop after main is the way Ghidra decompiles the HLT instruction.

If we jump to main, we see a function call, the first parameter is rust_main as I named it below:

If we search "hello world" on the Defined Strings sections, matches at the end of a large string

After doing "clear code bytes" we can see the string and the reference:

We can see that the literal is stored in an non null terminated string, or most likely an array of bytes. we have a bunch of byte arrays and pointed from the code to the beginning.
Let's follow the ref. [ctrl]+[shift]+[f] and we got the references that points to the rust main function.

After several naming thanks to the Ghidra comments that identify the rust runtime functions, the rust main looks more understandable.
See below the ref to "hello world" that is passed to the string allocated hard-coding the size, because is non-null terminated string and there is no way to size this, this also helps to the rust performance, and avoid the c/c++ problems when you forgot the write the null byte for example miscalculating the size on a memcpy.

Regarding the string object, the allocator internals will reveal the structure in static.
alloc_string function call a function that calls a function that calls a function and so on, so this is the stack (also on static using the Ghidra code comments)

1. _$LT$alloc..string..String$u20$as$u20$core..convert..From$LT$$RF$str$GT$$GT$::from::h752d6ce1f15e4125
2. alloc::str::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$str$GT$::to_owned::h649c495e0f441934
3. alloc::slice::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$$u5b$T$u5d$$GT$::to_owned::h1eac45d28
4. alloc::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::to_vec::h25257986b8057640
5. alloc::slice::hack::to_vec::h37a40daa915357ad
6. core::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::len::h2af5e6c76291f524
7. alloc::vec::Vec$LT$T$GT$::extend_from_slice::h190290413e8e57a2
8. _$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$$RF$T$C$core..slice..Iter$LT$T$GT$$GT$$GT$::spec_extend::h451c2f92a49f9caa
...

Well I'm not gonna talk about the performance impact on stack but really to program well reusing code grants the maintainability and its good, and I'm sure that the rust developed had measured that and don't compensate to hardcode directly every constructor.

At this point we have two options, check the rust source code, or try to figure out the string object in dynamic with gdb.

Source code

Let's explain this group of substructures having rust source code in the hand.
The string object is defined at string.rs and it's simply an u8 type vector.

And the definition of vector can be found at vec.rs and is composed by a raw vector an the len which is the usize datatype.

The RawVector is a struct that helds the pointer to the null terminated string stored on an Unique object, and also contains the allocation pointer, here raw_vec.rs definition.

The cap field is the capacity of the allocation and a is the allocator:

Finally the Unique object structure contains a pointer to the null terminated string, and also a one byte marker core::marker::PhantomData

Dynamic analysis

The first parameter of the constructor is the interesting one, and in x64 arch is on RDI register, the extrange sequence RDI,RSI,RDX,RCX it sounds like ACDC with a bit of imagination (di-si-d-c)

So the RDI parámeter is the pointer to the string object:

So RDI contains the stack address pointer that points the the heap address 0x5578f030.
Remember to disable ASLR to correlate the addresses with Ghidra, there is also a plugin to do the synchronization.

Having symbols we can do:
p mystring

and we get the following structure:

String::String {
vec: alloc::vec::Vec {
buf: alloc::raw_vec::RawVec {
ptr: core::ptr::unique::Unique {
pointer: 0x555555790130 "hello world\000",
_marker: core::marker::PhantomData
},
cap: 11,
a: alloc::alloc::Global
},
len: 11
}
}

If the binary was compiled with symbols we can walk the substructures in this way:

(gdb) p mystring.vec.buf.ptr
$6 = core::ptr::unique::Unique {pointer: 0x555555790130 "hello world\000", _marker: core::marker::PhantomData}

(gdb) p mystring.vec.len

$8 = 11

If we try to get the pointer of each substructure we would find out that the the pointer is the same:

If we look at this pointer, we have two dwords that are the pointer to the null terminated string, and also 0xb which is the size, this structure is a vector.

The pionter to the c string is 0x555555790130

This seems the c++ string but, let's look a bit deeper:

RawVector
Vector:
(gdb) x/wx 0x7fffffffdf50
0x7fffffffdf50: 0x55790130 -> low dword c string pointer
0x7fffffffdf54: 0x00005555 -> hight dword c string pointer
0x7fffffffdf58: 0x0000000b -> len

0x7fffffffdf5c: 0x00000000
0x7fffffffdf60: 0x0000000b -> low cap (capacity)
0x7fffffffdf64: 0x00000000 -> hight cap
0x7fffffffdf68: 0xf722fe27 -> low a (allocator)
0x7fffffffdf6c: 0x00007fff -> hight a
0x7fffffffdf70: 0x00000005

So in this case the whole object is in stack except the null-terminated string.

More info

Voodoo-Kali - Kali Linux Desktop On Windows 10

How it works?
* Kali Linux with XFCE Desktop Environment in Windows Subsystem for Linux (WSL)
* VcXsrv X Server for Windows is doing the hard GUI lifting
* XFCE is started natively in WSL and displayed by VcXsrv

Install Voodoo-Kali:
1, Enable WSL and install Kali Linux from the Microsoft Store. Read Install Kali Linux desktop on Windows 10 from Microsoft Store

2, To start Kali Linux in Windows 10, open Command Prompt and enter the command: kali

3, Enter this commands:
  apt install wget -y
  wget https://raw.githubusercontent.com/Re4son/WSL-Kali-X/master/install-WSL-Kali-X
  bash ./install-WSL-Kali-X

4, Download and install VcXsrv Windows X Server from SourceForge

5, Start VcXsrv, accept change in firewall rules, exit VcXsrv

Run Voodoo-Kali:
Start kali in Windows as normal user (that's default), and launch Voodoo-Kali:
* as normal user: ./start-xfce
* as root: sudo /root/xtart-xfce

Run Kali Desktop in an RDP session:
In Kali Linux WSL, type: sudo /etc/init.d/xrdp start
In Windows 10, open Run and enter mstsc.exe and connect to "127.0.0.1:3390"

Status: Voodoo-Kali is in its infancy and it is far from being elegant. I'm working on it though and step by step I'll push out improvements. Below a snippet of the To-Do list:
* Clean up and comment the scripts
* Make for a cleaner exit
* Better error handling and dependency checking (get rid of sleep, etc.)
* Improve stability of Java programs
* Improve the looks??
* …

Any help is truly appreciated, in any shape or form – from tips to pull requests.
Why don't you join the forums to discuss?

Further Information:
* Offsec – Kali Linux in the Windows App Store
* MSDN – Windows Subsystem for Linux Overview

Download Voodoo-Kali

Related articles

Many Ways Of Malware Persistence (That You Were Always Afraid To Ask)

TL;DR: Are you into red teaming? Need persistence? This post is not that long, read it ;)

Are you into blue teaming? Have to find those pesky backdoors? This post is not that long, read it ;)

In the previous post, I listed different ways how a Windows domain/forest can be backdoored. In this new post, I am digging a bit deeper, and list the most common/known ways malware can survive a reboot, just using local resources of the infected Windows system. The list is far from complete, and I would like to encourage everyone to comment on new methods, not yet listed here.

From an incident response point of view, one of the best strategies to find malware on a suspicious system is to search for suspicious entries that start with the system. In the good old days, you had to check for 2-3 locations to cover 99% of the infections. Nowadays, there are a thousand ways malware can start. The common ones automatically start whenever Windows starts (or the user logs in), but some tricky ones are triggered by other events.

Autoruns

My favorite choice when it comes to malware persistence is Sysinternals tools, Autoruns. In this paragraph, I mainly quote the official built-in help, but bear with me, it is still interesting.

On a side note, there are some problems with the Autoruns tool: it can only run on a live system. (EDIT: This is not true, Autoruns can analyze offline systems as well! Thanks to a comment from Justin.) And usually, this is not the case - I usually have dd images. And although VBoxManage can convert the dd images to VirtualBox disk image format, usually I don't have the time and storage to do that. This is where xmount awesomeness is here to rescue the day. It can convert dd and Encase images on-the-fly in-memory to Virtualbox format. Just attach the disk image to a new Virtualbox machine as the main boot HDD, modify the CPU/disk/controller settings until Windows starts instead of crashing, and voila, you can boot your forensic image - without modifying a single bit on the original evidence dd file. Another problem with malware analysis on a live system is that a good rootkit can fool the analyst easily.

For quick wins, I usually filter out Microsoft entries, look for per-user locations only and check for unverified (missing or invalid Authenticode) executables. This usually helps to find 90% of malware easily. Especially if it has a color like purple or pink, it is highly suspicious. To find the rest, well, one has to dig deeper.

Zeus "hiding" in the usual random directory - check the faked timestamp

To implement "poor-mans monitoring", regularly save the output of Autoruns, and during incident response, it will be highly valuable. Howto guide here.

Logon

"This entry results in scans of standard autostart locations such as the Startup folder for the current user and all users, the Run Registry keys, and standard application launch locations."

There are 42 registry keys/folders at the moment in Autoruns, which can be used to autostart a malware. The most common ways are the HKCU\Software\Microsoft\Windows\CurrentVersion\Run and the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup folder.

One of my favorite regarding this topic is the file-less Poweliks malware, 100% pure awesomeness. Typical ring 3 code execution.

Explorer

"Select this entry to see Explorer shell extensions, browser helper objects, explorer toolbars, active setup executions, and shell execute hooks". 71 registry keys, OMG. Usually, this is not about auto-malware execution, but some of them might be a good place to hide malware.

Internet explorer

"This entry shows Browser Helper Objects (BHO's), Internet Explorer toolbars and extensions". 13 registry key here. If a malicious BHO is installed into your browser, you are pretty much screwed.

Scheduled tasks

"Task scheduler tasks configured to start at boot or logon." Not commonly used, but it is important to look at this.

I always thought this part of the autostart entries is quite boring, but nowadays, I think it is one of the best ways to hide your malware. There are so many entries here by default, and some of them can use quite good tricks to trigger the start.

Did you know that you can create custom events that trigger on Windows event logs?

Did you know you can create malware persistence just by using Windows tools like bitsadmin and Scheduled tasks?

Scheduler in the old days

Scheduler in the new days

Services

HKLM\System\CurrentControlSet\Services is a very commonplace to hide malware, especially rootkits. Check all entries with special care.

Drivers

Same as services. Very commonplace for rootkits. Unfortunately, signing a driver for 64-bit systems is not fun anymore, as it has to be signed by certificates that can be chained back to "Software Publisher Certificates". Typical startup place for Ring 0 rootkits.

Starting from Windows 10, even this will change and all drivers have to be signed by "Windows Hardware Developer Center Dashboard portal" and EV certificates.

Codecs

22 registry keys. Not very common, but possible code execution.

Boot execute

"Native images (as opposed to Windows images) that run early during the boot process."

5 registry keys here. Good place to hide a rootkit here.

Image hijacks

"Image file execution options and command prompt autostarts." 13 registry key here. I believe this was supposed for debugging purposes originally.

This is where the good-old sticky keys trick is hiding. It is a bit different from the others, as it provides a backdoor access, but you can only use this from the local network (usually). The trick is to execute your code whenever someone presses the SHIFT key multiple times before logging into RDP. The old way was to replace the sethc.exe, the new fun is to set a debug program on sethc.

If you see this, you are in trouble

AppInit

"This has Autoruns shows DLLs registered as application initialization DLLs." Only 3 registry keys here. This is the good old way to inject a malicious DLL into Explorer, browsers, etc. Luckily it is going to be deprecated soon.

Known DLLs

"This reports the location of DLLs that Windows loads into applications that reference them." Only 1 registry key. This might be used to hijack some system DLLs.

Winlogon

"Shows DLLs that register for Winlogon notification of logon events." 7 registry keys. Sometimes used by malware.

Winsock providers

"Shows registered Winsock protocols, including Winsock service providers. Malware often installs itself as a Winsock service provider because there are few tools that can remove them. Autoruns can disable them, but cannot delete them." 4 registry keys. AFAIK this was trendy a while ago. But still, a good place to hide malware.

Print monitors

"Displays DLLs that load into the print spooling service. Malware has used this support to autostart itself." 1 registry key. Some malware writers are quite creative when it comes to hiding their persistence module.

LSA providers

"Shows registers Local Security Authority (LSA) authentication, notification and security packages." 5 registry keys. A good place to hide your password stealer.

Network providers

"Missing documentation". If you have a good 1 sentence documentation, please comment.

WMI filters

"Missing documentation". Check Mandiant for details.

Sidebar gadgets

Thank god MS disabled this a while ago :)

We all miss you, you crappy resource gobble nightmares

Common ways - not in autoruns

Now, let's see other possibilities to start your malware, which won't be listed in Sysinternals Autoruns.

Backdoor an executable/DLL

Just change the code of an executable which is either auto-starting or commonly started by the user. To avoid lame mistakes, disable the update of the file ... The backdoor factory is a good source for this task. But if you backdoor an executable/DLL which is already in Autoruns listed, you will break the Digital Signature on the file. It is recommended to sign your executable, and if you can't afford to steal a trusted certificate, you can still import your own CA into the user's trusted certificate store (with user privileges), and it will look like a trusted one. Protip: Use "Microsoft Windows" as the codesigner CA, and your executable will blend in.

See, rootkit.exe totally looks legit, and it is filtered out when someone filters for "Hide Windows entries".

Hijack DLL load order

Just place your DLL into a directory which is searched before the original DLL is found, and PROFIT! But again, to avoid lame detection, be sure to proxy the legitimate function calls to the original DLL. A good source on this topic from Mandiant and DLL hijack detector.

Here you can see how PlugX works in action, by dropping a legitimate Kaspersky executable, and hijacking the DLL calls with their DLL.

Hijack a shortcut from the desktop/start menu

Never underestimate the power of lame tricks. Just create an executable which calls the original executable, and meanwhile starts your backdoor. Replace the link, PROFIT! And don't be a skiddie, check the icon ;) I have seen this trick in adware hijacking browsers a lot of times.

IE hijacked to start with http://tinyurl.com/2fcpre6

File association hijack

Choose the user's favorite file type, replace the program which handles the opening with a similar one described in the previous section, and voila!

COM object hijack

The main idea is that some COM objects are scanned for whether they are on the system or not, and when it is registered, it is automatically loaded. See COMpfun for details.

Windows Application Compatibility - SHIM

Not many people are familiar with Windows Application Compatibility and how it works. Think about it as an added layer between applications and the OS. If the application matches a certain condition (e.g. filename), certain actions will take place. E.g. emulation of directories, registry entries, DLL injection, etc. In my installation, there are 367 different compatibility fixes (type of compatibility "simulation"), and some of those can be customized.

Every time IE starts, inject a DLL into IE

Bootkits

Although bootkits shown here can end up in Autoruns in the drivers section (as they might need a driver at the end of the day), I still think it deserves a different section.

MBR - Master boot record

Malware can overwrite the Master boot record, start the boot process with its own code, and continue the boot process with the original one. It is common for rootkits to fake the content of the MBR record, and show the original contents. Which means one just have attached the infected HDD to a clean system, and compare the first 512 bytes (or more in some cases) with a known, clean state, or compare it to the contents shown from the infected OS. SecureBoot can be used to prevent malware infections like this.

There is a slight difference when MBR is viewed from infected OS vs clean OS

VBR - Volume boot record

This is the next logical step where malware can start it's process, and some malware/rootkit prefers to hide it's startup code here. Check GrayFish for details. SecureBoot can be used to prevent malware infections like this.

BIOS/UEFI malware

Both the old BIOS and the new UEFI can be modified in a way that malware starts even before the OS had a chance to run. Although UEFI was meant to be more secure than BIOS, implementation and design errors happens. Check the Computrace anti-theft rootkit for details.

Hypervisor - Ring -1 rootkit

This is somewhat special, because I believe although rootkit can run in this layer but it can't persist only in this layer on an average, physical machine, because it won't survive a reboot See Rutkowska's presentation from 2006 But because the hypervisor can intercept the restart event, it can write itself into one of the other layers (e.g. install a common kernel driver), and simply delete it after it is fully functional after reboot. Update: There is a good paper from Igor Korkin about hypervisor detection here.

SMM (System Management Mode) malware - Ring -2 rootkit

Somehow related to the previous type of attacks, but not many people know that System Management Mode can be used to inject code into the OS. Check the DEITYBOUNCE malware for more details ;) Also, abusing Intel Dual Monitor Mode (DMM) can lead to untrusted code execution, which basically monitors the SMM mode.

Intel® Active Management Technology - Ring -3 rootkit

According to Wikipedia, "Intel Active Management Technology (AMT) is hardware and firmware technology for remote out-of-band management of personal computers, in order to monitor, maintain, update, upgrade, and repair them". You can ask, what could possibly go wrong? See Alexander Tereshkin's and Rafal Wojtczuk's great research on this, or Vassilios Ververis thesis about AMT.

As not many people click on links, let me quote the scary stuff about AMT:

Independent of the main CPU
Can access host memory via DMA (with restrictions)
Dedicated link to NIC, and its filtering capabilities
Can force host OS to reboot at any time (and boot the system from the emulated CDROM)
Active even in S3 sleep!

Other stuff

Create new user, update existing user, hidden admins

Sometimes one does not even have to add malicious code to the system, as valid user credentials are more than enough. Either existing users can be used for this purpose, or new ones can be created. E.g. a good trick is to use the Support account with a 500 RID - see here, Metasploit tool here.

Esoteric firmware malware

Almost any component in the computer runs with firmware, and by replacing the firmware with a malicious one, it is possible to start the malware. E.g. HDD firmware (see GrayFish again), graphic card, etc.

Hidden boot device

Malware can hide in one of the boot devices which are checked before the average OS is loaded, and after the malware is loaded, it can load the victim OS.

Network-level backdoor

Think about the following scenario: every time the OS boots, it loads additional data from the network. It can check for new software updates, configuration updates, etc. Whenever a vulnerable software/configuration update, the malware injects itself into the response, and get's executed. I know, this level of persistence is not foolproof, but still, possible. Think about the recently discovered GPO MiTM attack, the Evilgrade tool, or even the Xensploit tool when we are talking about VM migration.

Software vulnerability

Almost any kind of software vulnerability can be used as a persistent backdoor. Especially, if the vulnerability can be accessed remotely via the network, without any user interaction. Good old MS08-067...

Hardware malware, built into the chipset

I am not sure what to write here. Ask your local spy agency for further information. Good luck finding those!

PENGUMUMAN...!!!