Moving blogging platform

Hello all,

The moving of blogging platform has finished. All posts can now be found in http://zqyves.wordpress.com (apart from one where I was being an ass).

Thanks.

./Z

Cloud Computing Security as its never seen before..

Hilarious...

Application Behavioural Changes

I was recently at a situation where I needed to test the security of a purely fat client, that is no server-side component was used at the application, rather a database hosting the application data. As such, all input validation and integrity checks where done at the fat client. After reversing part of the application it was evident that the application runtime behaviour would need to be changed per my needs in order to subvert these checks. To put things into perspective, by the term application runtime I am referring to the values held by the registers at program execution.

The primary point of interest was, of course, subverting the password authorisation scheme of the application. Due to runtime protection it was not possible to permanently patch the application binary so I had to apply the patches at every execution. That lost its glamour after the first 15 times so I devised an Immunity Debugger PyCommand that would apply the patch after attaching to the application binary. Then I issued the same command for all 9 points that I had to patch. It took about 4 runs for that to also loose its magic...

By now you must know where I am going with this...

So I devised a PyCommand that takes a ; separated of : separated quadruples of the information required to setup the hooks. I was feeling quite imaginative that afternoon.

The idea behind this PyCommand is that a breakpoint is set at each point that the program execution must be manipulated. Once the breakpoint is hit, the relevant manipulation associated with it will be executed. That may be setting the value of a register to a specified value (eg. EAX=0x00000000) or to the contents of another register (eg. EAX = EBX) .

The required information in order to setup the breakpoint hooks is:

• ID: A unique - descriptive - name in order to identify the hook by
• ADDRESS: The address that the breakpoint will be set
• REGISTER: The register to be modified
• VALUE: The value to be set to the register, this can either be static (0x00000000) or the name of another register in which case the value of that register is being copied to the one we wish.

So at the end of the day I ended up with something along the lines of:

!bsu.py -b PREJMP:0x0040501290:EAX:EBX;POSTCMP:0x00407612:EAX:00000001

You can get the PyCommand from here.

The code is messy, but it works. I will try to put comments in it but I cannot guarantee that it will continue to work. To those wondering, yes putting comments in my code CAN break normal functionality.

./Z

AES Made Easy

Never before has reading about AES been so fun.

HackThisSite Application 7 Solution Using In Memory Fuzzing

Hello All,

This post is meant to describe a 'different' approach to solving the Application 7 challenge of www.hackthissite.org. It does so by using a technique called 'In Memory Fuzzing'. To avoid any flames as to whether that is fuzzing or bruteforcing you can call it whatever you want - I call it recursive fuzzing as per owasp.

Tools that will be utilised are:

• Immunity Debugger v1.4
• Python 2.5.1
• pydbg (edited pydasm.dll to support python25.dll)

Providing a detailed analysis of the binary is not part of this post. Other's have done it - a lot better than I could have done it. So here goes...

Rough binary(app7win.exe) breakdown

The following is a rough decomposition of the app7win.exe binary in logical blocks:

We can see that the only purpose the password that is inputted by the user serves is to add all the characters in one key and use it to decrypt the file and produce the final password. This Key (K) is stored in [EBP-1C]. That is what we will fuzz - "bruteforce".

In-Memory Fuzzing in a Nutshell
So now that we have broken down our interesting function it is time to start preparing for our fuzzing. In Memory fuzzing works by

1. Taking a process snapshot at an ideal – for your type of tests – point. This will be used a the initial state of your tests and is the state that the process will be restored to after each test run.
2. Setting several break points:
1. The breakpoint(s) at which you need to perform you actions (such as altering memory contents)
2. he restore breakpoint (s) that designate the end of your test and at which you will need to restore the initial process snapshot
3. Setting callbacks. Those are action you need to take at each breakpoint hit. It may be different actions per breakpoint

For a more thorough explanation of Memory Fuzzing have a look at the book ‘Fuzzing: Brute Force Vulnerability Discovery’ by Amini, Sutton, Greene.

Let's start fuzzing

As a rule of thumb – which is sometimes bent

a bit due to special circumstances – we will try to alter the execution of the original binary as little as possible.

Thus far we have identified that the contents of [EBP-1C] are used as the sole basis to perform several mathematical operations on the encrypted.enc contents and subsequently - based on the outcome of these operations ( 0040118C |CMP DWORD PTR SS:[EBP-18],0DCA ) - provide the password.

Another parameter we must work out is the range of the fuzzing parameter (bruteforcing). This was calculated as the result of hex(7D) (max ascii printable character code) * 20 (possible password length) = hex(9C4). It was decided to round that up to hex(1000).

Try 1: After Initial Calculation

For our first run we used

• 0x00401064 (immediately after the password has been inputted) as our process snapshot point
• 0x004010E0 (just before reading the key for the first time) as our rewrite memory breakpoint
• 0x004011AD (at the ‘Display Invalid Password' code segment) as our rewind breakpoint.

This never worked past the first iteration. It kept breaking with a

ACCESS VIOLATION ERRORS. If anyone can point as to why I would be grateful.

Try 2: Entry Point

For our second run we used

• 0x004014C0 (process entry point) as our process snapshot point
• 0x004010E0 (just before reading the key for the first time) as our rewrite memory breakpoint
• 0x004011AD (at the ‘Display Invalid Password' code segment) as our rewind breakpoint.

Executing the fuzzer at this point worked OK with a small glitch, it was asking for the password every time. It was time to bend our previous rule of thumb. The only use password entry was serving was to calculate the initial key, that is the value being stored in [EBP-1C] which we were resetting after all. So the password entry point was NOPed as is shown in the following screenshots.

At this point the fuzzer worked as expected. The fuzzer source code is provided in the file accompanying this post.

Although it is mentioned explicitly in the fuzzer source code I must stress that a large part of my fuzzer source code is ripped from the In Memory Fuzzer found in http://www.fuzzing.org. So kudos to those guys.

Fuzzer Source Code

Sulley on Python 2.5.

Sulley is a multipurpose fuzzer created by the guys at TippingPoint (3Com) in Python. More on sulley can be found at the BlackHat USA 2007 talk titled "Fuzzing Sucks! Introducing Sulley Fuzzing Framework" (pdf) (mp4).

The installer comes with local copies of the Python 2.4.3 programming language, the pcapy python library, the ctypes python library and WinPcap 4.0.3. All of these are installed along with the sulley fuzzing framework.

Although not exactly rocket science I did not find anywhere a guide on installing sulley in a Python 2.5 environment. So I decided to give it a go and create one myself.

Steps:

• Install Python 2.5
• The ctypes python library is, as of Python 2.5, included in the Python core so nothing needs to be done as far is this is concerned.
• The pcapy python library on the other hand is not, so it needs to be downloaded from http://oss.coresecurity.com. The file that worked for me is pcapy-0.10.5.win32-py2.5.exe. (sha1sum = 04e2e969e343e01adaec44680376714a6b10c97b)
  
• Install Winpcap (Optional)
• Install Sulley Fuzzing Framework cancelling out on all additional packages it prompts you to install with the exception of WinPcap (based on whether you chose to pre-install it or not - See previous step).
• Finally, sulley comes with a Python 2.4 based version of pydasm.pyd. My preferred way is Hexedit the pydasm.pyd and change the python24.dll with python 25.dll.

Et voila!!!! A working sulley installation.

Hello World!

So I started blogging... Big deal...

Anyway, this blog is going to be largely related to information security in random topics I am interested in (the rand part of it) and at various other aspects of our life (the rant part of it).

A few words about myself...

1. check the box on the upper right corner of the page you are in.
2. I work in the field of information security. My current interests are:
• Reverse Engineering
• Malware
• Penetration Testing
• .Net Programming (C# mainly)
• Fuzzing

I hope to see you again...

./Z