BusyBox, called the swiss army knife of embbeded linux, is a software application that combines tiny versions of common unix utilities into a single small executable, as we can read in the busyBox project page. It is widely used in embedded devices, specially in modem/routers, thought it is used too in other type of devices like music systems, ebooks (i.e. kindle), phones, etc…
BusyBox is single binary. It is implemented having in mind size-optimizations and limited resources environments. It implements a lot of common unix commands. To use each command, you should call BusyBox giving the command as parameter, i.e.: /bin/busybox ls. Usually, commands that are implemented by busybox have fewer options than the original full-featured command. BusyBox uses ash shell (/bin/busybox sh).
As we said, a lot of router devices are using BusyBox. It is quite probably that a router shows to you a limited command line interface to manage it, for example when you connect via telnet. However, these limited shells use BusyBox for executing some of the commands that they offer, and it is common to find devices that are vulnerable to command injection attacks that would let us to use directly the busybox ash shell.
In this article I am going to describe a way to execute code in windows kernel by using windbg local kernel debugging. It’s not a vulnerability, I am going to use only windbg’s legal functionality, and I am going to use only a batch file (not powershell, or vbs, an old style batch only) and some Microsoft’s signed executables (some of them that are already in the system and windbg, that we will be dumped from the batch file).
With this method it is not necessary to launch executables at user mode (only Microsoft signed executables) or load signed drivers. PatchGuard and other protections don’t stop us. We put our code directly into kernel memory space and we hook some point to get a thread executing it. As we will demonstrate, a malware consisting of a simple batch file would be able to jump to kernel, enabling local kernel debugging and using windbg to get its code being executed in kernel.
The article has five parts:
- Dumping files embedded into the batch file: a couple of methods for embedding and dumping binary files into the batch file.
- Executing the batch file as administrator: here a method to show the UAC prompt from the batch file (without using powershell, vbs…)
- Enabling local kernel debugging: how to enable local kernel debugging from the batch.
- Patch kernel memory with windbg to inject and execute our code in kernel mode: a way to patch kernel memory and execute our code in kernel by using windbg local kernel debugging from the batch file).
- Finally, we will put all these things together to make a proof-of-concept batch file that will target a windows 8.1 x64 machine, and we will do some tests.
There are lot of ransomware families around the world, however, since long time ago, they contain no new interesting features. VirRnsm.A is a malware that mixes characteristics of ransomwares and infectors. It is a ransomware capable to infect executable files (or an infector capable to encrypt your files). Technically, It doesn’t seem a great malware, but it is worth a look because, from my point of view, in the future we are going to start to see a lot of malwares of this type. Ransomware’s behaviour could end up being a payload of worms and infectors, rather than a malware by itself.
In spite of the fact that VirRnsm.A is an evolution in the ransoms world, probably, it would have spread itself faster if the malware, after infecting files, didn’t block the screen, showing a rescue message and revealing itself. Instead, imagine a worm or infector (a conficker, a sality,…), that arrives to a machine and hides itself with stealth techniques, trying to spread itself as much as possible, and waiting for a date to execute its payload (payload with ransomware behaviour). It could be a enormous chaos.
It’s common to reverse malware (or any type of software) that creates multiple processes or loads drivers, and it is useful to be able to debug the new created processes or loaded drivers from entry point.
To break at the entry point of the processes you can modify CreateProcess parameters to create child processes suspended (to attach debugger later), or introduce 0xCC at entrypoint on disk of the PE file that is going to be launched, or use plugins for debuggers to attach to child processes… There are lot of methods. From kernel mode you can set conditions that break into the debugger: sxe ld ntdll.dll, sxe cpr, etc… For breaking at a driver entry point you can use: bu <drivername>!DriverEntry (though, i don’t know why, sometimes it doesn’t work for me).
I will talk here about a couple of ways to do this from windbg kernel mode debugger, without needing to restart computer to enable exceptions that break into debugger, or modifying PEs in disk,…
Boredom is very dangerous because you start to waste time on nonsense, and this article is the proof of it 🙂
Here is a tiny ransomware implemented with only one python expression.
The last days my computer started to crash suddenly, with bug check 0x51 (REGISTRY_ERROR). It was totally random, so i decided to analyze the crash. I decided to write an article about this because, in spite of the fact that it doesn’t seem a security problem, i learnt some interesting things about windows registry.
A couple of days ago i found a weird behaviour in my computer. When i double-clicked a .docx file, an error message appeared saying c:\Program couldn’t be executed. I don’t know when and why i had an empty file named “c:\Program” on my computer (i had been doing tests with %PROGRAMFILES% envar in my code and i guess the file derived of this).
I investigated a bit about it and it seems to be a bug of the “Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint File Formats”. It seems it keeps into a registry key a path to wordconv.exe without quotes, so when svchost.exe tries to execute c:\Program files\Microsoft office\Office12\Wordconv.exe, if c:\Program exists in the machine, it executes c:\Program.
It’s not an important bug and doesnt seem a security problem, because c:\Program is executed in the context of the currently logged user. However i decided to analyze the bug and you can find the analysis in this article.