Execution of Arbitrary Code on Fully Patched Windows 10 and Windows 7 Boxes (Heap-based Buffer Overflow Vulnerabilities)

Categories Buffer Overflow

Hossein Lotfi, (Secunia Research at Flexera Software) has discovered multiple vulnerabilities, which allow a hacker to execute arbitrary code, using specially crafted font files. These (remote) vulnerabilities impact fully patched installations of Windows 10 as well as Windows 7! :

* Hackers can exploit a vulnerability within the “LoadUvsTable()” function to cause a heap-based buffer overflow through a font file that has been crafted to contain specially crafted Unicode Variation Sequences tables.

* An integer overflow error within the “LoadFont()” function is able to be exploited in order to create a heap-based buffer overflow, again through a font file that has been crafted to contain specially crafted Unicode Variation Sequences tables.

As I mentioned at the outset these vulns are confirmed on fully patched Windows 10 Professional (gdi32full.dll version 10.0.14393.576) and Windows 7 Professional (usp10.dll version 1.626.7601.23585). Other versions
may be affected.

Fix this critical vuln by installing the update over at Microsoft’s Security TechCenter here.

The Anatomy of a ROP Attack

Categories ROP

ROP attacks bear much similarity to return-to-libc attacks in so much as they utilise code that already exists, however, ROP attacks do not need to rely upon complete functions, such as calling the libc function system(). Further, due to x86 processors using a variable length instruction set, a potential hacker needn’t rely on instructions originally intended by the compiler. To perform a ROP attack, a hacker must first identify enough gadgets(that is, sequences of assembly instructions within an application that accomplish a specific goal, usually very short and comprising a few instructions and ending with a control transfer instruction – typically a RET) to chain together to perform arbitrary tasks unintended by the original application. Usually this is accomplished with a buffer overflow to the call stack, overwriting it with addresses of the desired gadgets. Note that this is just a sequence of addresses not the hacker’s shellcode as with a normal buffer overflow!

Once the addresses are chained together, arbitrary sequences of instructions can be effectively executed (see the figure below).

The left side of the diagram shows a normal stack frame of a function. Labels indicate the bounds of the stack frame with the ESP and EBP registers as well as the layout of the passed-in functions and the local variables.

On the right-hand side, conversely, we can see the stack frame after a ROP attack has been performed. Utilising standard buffer overflow techniques, the hacker overwrites, with random data, all of the data on the stack leading up to the return address (old EBP value and local variables). Next, the hacker chains together all of the addresses of the gadgets.

This way, once a function has completed and the RET instruction is executed, program control is transferred to Gadget Address 1. As subsequent RET instructions are encountered at the end of each of the gadgets, the next gadget address will be used.

ROP does not need to execute any code from the stack, all it needs is to be able to write the chained gadgets to the stack and be able to read those addresses later on. The easiest targets for ROP attacks are apps that have not been designed with security in mind and apps that are just poorly written and can therefore have their security holes exploited. The most common protective mechanism used by CPU manufacturers and the like is DEP (Data Execution Prevention), DEP utilises the cooperation of an OS and CPU to enforce policies designed to prevent execution of arbitrary data contained in marked segments of memory. Another popular method is Address Space Layout Randomization (ASLR) which randomises the starting address of memory within which libraries are loaded as well as the location of the apps stack. ASLR is useful for preventing return-to-libc attacks able to bypass DEP restrictions. With return-to-libc, a hacker can modify the return address of a function so that the program continues execution within another function which is already loaded (typically within libc). ASLR causes the address of the desired function to be non-constant, thereby limiting the success rates of attacks.

These defences are not effective in preventing ROP, however. DEP is completely bypassed as ROP does not need to execute any code from the stack. ASLR has also been demonstrated to be insufficient in defeating ROP, the major Operating Systems including Linux, Windows, and OS X, each have their own shortcomings implementing ASLR which can be exploited.

Academics and security researchers are actively exploring new ROP protection methods that utilise on-the-fly encryption and decryption of return addresses at runtime. The focus should be on preventing A ROP attack by stopping a hacker from launching arbitrary commands, in the first place, to gain control of a system (rather than stopping buffer overflows). This can be achieved with the DynamoRIO Dynamic Instrumentation Tool Platform.

****************************Written by Alg3sic**********Feel free to reuse WITH CREDIT TO ME AND A LINK TO https://twitter.com/FidgetRoller**********

Consolidated Malware Sinkhole List

Categories Sinkholes

Lesley Carhart has compiled an epic list of sinkholes over at tisiphone.net [1]. She used methods in a paper by Michael B Jacobs [2] to detect and confirm these, primarily through DNS and behavioural analysis.

Consolidated Malware Sinkhole List:

[1] https://tisiphone.net/2017/05/16/consolidated-malware-sinkhole-list/
[2] https://www.first.org/resources/papers/conf2016/FIRST-2016-78.pdf

Cobalt Strike broken by Java 1.8u131 Startup Bug

Categories Bugs

Cobalt Strike (Adversary Simulation and Red Team Operations Software) has been impacted by a known bug in Java 1.8u131. The Java update creates a change that breaks the -XX:+AggressiveHeap cmd line option that Cobalt Strike utilises. This is affecting other applications that use this cmd line option.

One workaround for this on Linux systems is to update teamserver and cobaltstrike scripts to include the -XX:ParallelGCThreads=8 option after the Java command or, even better, don’t upgrade to Java 1.8u131 yet and downgrade to Java 1.8u121 if you have already upgraded.

You can read more about this issue on the Cobalt Strike blog

Automated Malware Sandboxing with VMWare and Noriben

Categories Sandboxes

Noriben is a simple script that allows you to run malware within a sandbox to analyse what processes it runs, what files it modifies, and what changes it makes to a system.

Running malware locally makes sense when there is a reluctance to upload files to online services such as Malwr.

Though most malware is run locally using Cuckoo, this requires some considerable effort to setup properly across different non-Linux based environments, such as Windows or OS X.

Noriben is, in essence, a wrapper for procmon – using it to collect hundreds of thousands of events which are then passed through for analysis against a list of whitelisted events, thereby having a reductive effect on the total list which can be more easily analysed.

A neat method to create an automated malware sandbox environment is to install Noriben within a VNWare virtualised environment and then use the vmrun command to revert the VM to a previous snapshot, import the malware, run Noriben, and then output the file in a zipped format to the host system for review. This can be used to generate a malware report within a couple of minutes.

You can download Noriben from here and read more about automated sandboxing via VMWare at Ghetto Forensics