Shifting yourself to space

June 27, 2011

Sick.

Filed under: Uncategorized — shift32 @ 3:50 pm

I got the flu inside me, so no progress at anything so far

Be back in a bit.

5points for he who shall know where this disasm if from (;

Some nice reading:
http://bit.ly/mq9CMf
http://www.google.com/search?q=%22%5BStart+Menu%5D%22+site:pastebin.com
http://www.securelist.com/en/analysis/204792180/TDL4_Top_Bot
http://volvent.org/
http://c-skills.blogspot.com/2011/04/evolution-of-race-condition-exploits.html

June 12, 2011

OpenBSD glob ‘GLOB_APPEND’ and ‘GLOB_DOOFFS’ flags integer overflow

Filed under: bugs,stupidity,Uncategorized — shift32 @ 1:35 am
Tags: ,

I usually don’t post about vuln dev, not because it’s not interesting, but because I love reading others people post about it (e.g xorl, cr0, etc)
The bug seems to exist in OpenBSD’s glob function, it’s definition is as follows:

glob(const char *restrict pattern, int flags,
int (*errfunc)(const char *epath, int errno),
glob_t *restrict pglob

According to globs man page, the glob function “The glob() function is a pathname generator that implements the rules for file name pattern matching used by the shell.”

The glob_t structure is what caught my eye, and has the following structure :

typedef struct {
int gl_pathc; /* count of total paths so far */
int gl_matchc; /* count of paths matching pattern */
int gl_offs; /* reserved at beginning of gl_pathv */
int gl_flags; /* returned flags */
char **gl_pathv; /* list of paths matching pattern */
} glob_t;

The integer overflow seem to reside in several functions, mostly because lame bounds checking and due to the fact the
the user has full control over almost everything, for example, take a look here:


int
160: glob(const char *pattern, int flags, int (*errfunc)(const char *, int),
161: glob_t *pglob)
162: {
163: const u_char *patnext;
164: int c;
165: Char *bufnext, *bufend, patbuf[MAXPATHLEN];
166: struct glob_lim limit = { 0, 0, 0 };
167:
168: patnext = (u_char *) pattern;
169: if (!(flags & GLOB_APPEND)) {
170: pglob->gl_pathc = 0;
171: pglob->gl_pathv = NULL;
172: pglob->gl_statv = NULL;
173: if (!(flags & GLOB_DOOFFS))
174: pglob->gl_offs = 0;
175: }
176: pglob->gl_flags = flags & ~GLOB_MAGCHAR;
177: pglob->gl_errfunc = errfunc;
178: pglob->gl_matchc = 0;
179:

Although checks are made for the initialization values of the pglob values, but no checks are made for any value less than zero or bigger than MAX_INT
Same goes for the globextend

static int
734: globextend(const Char *path, glob_t *pglob, struct glob_lim *limitp,
735: struct stat *sb)
736: {
737: char **pathv;
738: ssize_t i;
739: size_t newn, len;
740: char *copy = NULL;
741: const Char *p;
742: struct stat **statv;
743:
744: newn = 2 + pglob->gl_pathc + pglob->gl_offs;
745: if (SIZE_MAX / sizeof(*pathv) <= newn ||
746: SIZE_MAX / sizeof(*statv) gl_offs; i gl_pathv && pglob->gl_pathv[i])
750: free(pglob->gl_pathv[i]);
751: if ((pglob->gl_flags & GLOB_KEEPSTAT) != 0 &&
752: pglob->gl_pathv && pglob->gl_pathv[i])
753: free(pglob->gl_statv[i]);
754: }

Notice how the values of pglob->gl_pathv and pglob->gl_offs aren’t checked for any values, and since they’re transferred from globN (N represents glob1, glob0, there’re a few passes before the actual function gets called, but I’ve seen it calling this function several times in different locations), they’re possibly controlled by others.

Well, I don’t know whether or not this vuln is remotely exploitable since I haven’t seen any usage of it in code etc, but who knows, we’re not in 2001 however.

Have fun.

June 9, 2011

Nanomites – second thoughts

Filed under: Uncategorized — shift32 @ 6:05 pm
Tags: , , , ,

I’ve been fiddling around nanomites for quite a while, since I’ve first read about them
and saw them in action in different packers, I decided to write my own implementation
So far I haven’t done any breakthrough until last night me and another colleague managed to do something neat

Stay tuned for more results.

June 6, 2011

PE in thy blood

Filed under: Uncategorized — shift32 @ 4:42 pm

June 5, 2011

Spyeye: Father `n Son

Filed under: Uncategorized — shift32 @ 1:45 pm
Tags: , , , , ,

I do not work much on SpyEye, I only get a chance to view it on my days off nowadays, hence the slow progress, but here’s my latest progress with SpyEye.

Also, a short tip before I start digging a bit – I found that the collaboration of IDA and OllyDBG together (if you got two screen [ I don’t have two screen though 😦 ] ) is quite great, how is this possible some of you might ask ?
Well, you can use OllySync + IDA-Sync plugins in order to share comments etc
The plugin is a bit outdated and I plan to rewrite it a bit (though Pedram has done great work)
When trying to set function names in OllySync the IDA-Sync server fails to interpret it well, but comments are amazing and IDA’s analysis adds quite alot of information.

It seems that I was mistaken in my previous post , the function which I stepped into was not the decryption stub of anything, it was only an initial check of the system and grabbing some basic info about what’s what and where
basically, the function consisted of fetching the computer’s name, the windows version, and some other details which are not that interesting for us.

It seems that SpyEye’s resource section play an important role in it’s infection process, section C2 and C3 are the sections which SpyEye holds the compressed configuration and sections SC1 and SC2 (I might be mistaken here with the exact names, but they do reside under the “SC” dir in the resources) hold the parasite code

After gathering all the information SpyEye needs from the basic initialization function, SpyEye creates a mutex and constantly checks for the Volume:\algonic\ directory existence, the reason for that is because that’s where SpyEye creates it’s reboot-killer executable named algonic.exe, it also contains the config.bin which has all the juicy information and plugins one wants to obtain once SpyEye reversed.

SpyEye frequently calls RtlAdjustPrivilege in order to get max privileges and infect processes with it’s parasite (inside the resource dir).
Also – a small hint to those who fear the “600 functions spyeye contains” – the reason SpyEye holds so “many” functions is quite simple – SpyEye doesn’t import/export all the functions it uses, if the author would’ve been smarter, he would’ve used only GetProcAddress and used the PEB to get the kernel32.dll base address
SpyEye uses some sort of “special” macro which uses a classical technique to walk through the dll the function resides in and find it, it has a hardcoded value of the hash it’s looking for and whenever someone wants to call any function it just wraps it around some wrapper function
This could be easily evaded by writing some sort of pattern matching function
Since the function which finds the dll and walks through it is the same, and the push order is always the same to find the function – a simple pattern matching procedure could name all those functions by simple instrumentation

Another thing I wanted to discuss is the infection process, which I found a bit nice,
SpyEye calls CreateToolhelp32Snapshot to get a list of all running processes and walks through them using Process32Next, each time it finds a process which isn’t csrss, smss, or System (which are critical system processes :/) it injects itself into, the parasite injection process is as follows:


1. Spyeye Calls OpenProcess(CREATE_THREAD | VM_READ | VM_WRITE | QUERY_INFORMATION,FALSE,1144 /* explorer.exe */);
2. Called NtAllocateVirtualMemory in the remote process at address 0F60000 (RWE)
3. I started debugging explorer.exe and found the page spyeye is going to inject itself into and set a memory on access breakpoint
4. Spyeye Calls NtWriteProcessMemory
5. Called CreateRemoteThread to create a new thread for spyeye malicious parasite
6. Called WaitForSingleObject to figure out that the thread was injected correctly (?)
7. Called GetExitCodeThread to see if it was injected successfully

After that, the parasite SpyEye injected has finished executing or is executing at the moment, the parasite, from what I’ve seen so far does the following things:


1. open Volume:\algonic\
2. write Volume:\algonic\algonic.exe
3. execute Volume:\algonic\algonic.exe
4. delete the original malware executable using DeleteFileA
5. sleep
6. call ExitThread

I might be missing the whole hooking part, as while I’m writing this document seems to be part I’m currently debugging
As I’ve written previously – SpyEye has a loop which walks through all the processes and injects itself into them, somewhere inside it it performs the hooking process

I hope you’ve enjoyed this although it lacked assembly information, I’ll however try to edit the post and add some assembly code too.

Blog at WordPress.com.