Monday, January 30, 2012

Windows Loader and ASLR on Binaries

Hi Folks, this morning I'd like to share a nice resource for analyzing ASLR on Windows Binaries. So far if you'd like to know if a given binary is currently using ASLR or not, you need to run it. You could run it through your favorite debugger (such as IDA or Olly ...) or by itself and later append to the run process an analyzer. But, obviously windows loader needs to know it before running the desired binary. So how does it work ? How does the loader know about ASLR on a given binary ?  If you are an avid reader of this blog you might had a chance to know answers to these questions ( here ). So what new about that ?  I've never found a static tool for that.

Summing up for newer readers, Widows Loader looks for a specific FLAG into the PE Header. In the PEHeader, specifically in the IMAGE_OPTIONAL_HEADER section there is a flag called DLLCharacteristics that defines many features for the executable during its loading time, 1 of them being ASLR.  If you take a closer look at the definition (you can find definition here) you might see the definition for DEP (NX bit) and for SEH too. 


Definition for IMAGE_OPTIONAL_HEADER, PEHEader section defining optional binaries features.

Myne-us wrote a simple ruby script which investigates through given binaries helping you in figuring out what "optional features" have been enabled on the passed binary. You can download the script here.  The script firstly loads the binary making the opportune controls over the PE format and later moves on the known offset checking bytes and filling on a main internal structure

Checking and moving to desired offset



Internal Structure

Personally I do like this simple script, it has been written in modular and very easy way. Pretty quick to upgrade with new features. I really would like to see a more complete static analysis from it, lets see if it will be uploaded ! ;) In the meantime it could be very useful to make static analysis over multiple files. Let assume you want to know how many binaries have ASLR or DEP enabled on your system, with current tools you need to open every binary dynamically and perform dinamic analysis. It would take forever. By using this simple script you might just cycle over every PEHeader and save output on a .text file ready to be analyzed from your favorite spreadsheet. Good Job !




Monday, January 23, 2012

Breaking The linux Kernel SLOB Allocator

Today I suggest another interesting paper from security.com entitled "A Heap of Trouble: Breaking the Linux Kernel SLOB Allocator".  In this paper, Dan Rosenberg evaluates the implementation of the Linux kernel SLOB allocator to assess exploitability. He presents new techniques for attacking the SLOB allocator, whose exploitation has not been publicly described. These techniques will apply to exploitation scenar- ios that become progressively more constrained, starting with an arbitrary- length, arbitrary-contents heap overflow and concluding with an off-by-one NULL byte overflow.

The paper offers a nice background on Kernel Allocators, the following picture sums up the entire section
The paper follows on describing some different ways to compromise the linux kernel allocator, such as:
  • Block Data Overwrite
  • Free Pointer Overwrite
  • Free Small Block Attack
  • Block Growth Attack
  • Little Endian Block Fragmentation Attack


  • Big Endian Block Fragmentation Attack

The above pictures are taken from the original paper, each one represents the corresponding attack scenario. I decided to paste them here just to remember the main attack principles. Have a nice reading.

Sunday, January 15, 2012

Automotive Attack Surface

This morning I suggest this interesting paper titled: "Comprehensive Experimental Analyses of Automotive Attack Surfaces".  In their second paper autosec.org group analyze most of the possible attack vectors available on "last generation" automobiles. The following image shows, very well,  the amount of public interfaces in a modern cars.

Abstract :
Modern automobiles are pervasively computerized, and hence potentially vulnerable to attack. However, while previous research has shown that the internal networks within some modern cars are insecure, the associated threat model — requiring prior physical access — has justifiably been viewed as unrealistic. Thus, it remains an open question if automobiles can also be susceptible to remote compromise. Our work seeks to put this question to rest by systematically analyzing the external attack surface of a modern automobile. We discover that remote exploitation is feasible via a broad range of attack vectors (including mechanics tools, CD players, Bluetooth and cellular radio), and further, that wireless communications channels allow long distance vehicle control, location tracking, in-cabin audio exfiltration and theft. Finally, we discuss the structural characteristics of the automotive ecosystem that give rise to such problems and highlight the practical challenges in mitigating them.

While past researches, included the autosec.org first paper, focused on specific car vulnerabilities this paper tries to abstract vulnerabilities describing high level threats. In particular this research describes four vulnerability class such as:  Direct Physical,  Indirect Physical, short-range wireless and long-range wireless.

I like this paper, very easy to read and very entertaining. Nothing really innovative (at least from my persona point of view) but interesting to see how common "computer security" attacks could be applied to automobiles. I really hope they don't want to build their own testing methodology, I will hate to see another personal-and-specific security testing methodology. I rather hope they will learn/adopt common security testing methodologies.





Tuesday, January 10, 2012

Today's threats.

A very nice map to fix some of the most important threats.


via

Wednesday, January 4, 2012

Detection of Metamorphic Malware

Hi Folks, 
this morning I'd like to share an interesting paper entitle: Detection of Metamorphic and Virtualization-based Malware using Algebraic Specification, from Matt Webster and Grant Malcolm.

They present an overview of the latest developments in the detection of metamorphic and virtualization- based malware using an algebraic specification of the Intel 64 assembly programming language. After giving an overview of related work, they describe the development of a specification of a subset of the Intel 64 instruction set in Maude, an advanced formal algebraic specification tool. 

They have been developing the technique of metamorphic malware detection based on equivalence-in-context so that it is applica- ble to imperative programming languages in general. They finally give two examples of how this might be used in a practical setting to detect metamorphic malware.

From Webster and Malcolm's  paper

The image shows their basic concept. Signature-based detection of a metamorphic computer virus, by application of  "equivalence- in-context".Instruction sequences c and σ are semi-equivalent with respect to W . Applying the result in Corollary 1 (If p1 ≡W p2 and p1; ψ ≡W ∪Vout (ψ) p2; ψ for instruction se- quences p1, p2, ψ and W ∪ Vout(ψ) = V , then p1;ψ ≡ p2;ψ.) to c,σ and ψ reveals that in fact c;ψ ≡ σ;ψ and therefore c has been identified as equivalent to signature σ, resulting in detection of the virus. This method could result in a false positive as there may be a non-malware instruction sequence which is equivalent-in-context of some signature.

It's not an easy paper to be read (at least for myself), but I think it is something very useful to know. I am not interested in the details so far, but having the possibility to know what you can do (in term of Malware detection) through formal analysis let you open new doors in terms of detections.