Monthly Archives: March 2011

Breaking down the Rootkit

My last post regarding my Rookit project was based on the research that I have been doing into it, though I feel comfortable enough to say that I haven’t gone about it in the easiest way possible. Lets stop and and actually think about what a Rootkit is, shall we?  Well straight off the name provides a clue, and that it is not one tool, but many. In this way, I can effectively break down the development of my Rootkit, instead of jumping straight into the deep-end (will I ever learn?) . Initially, the core functionality of the Rootkit has to be decided on. For my project, I have decided on the following as the core functionality that my Rootkit requires:

1. A mechanism for injecting the Rootkit. By this I mean a way to make it run, I could go along the lines of a virus and embed the code to start the Rootkit in a commonly used application. However, due to the easy of injection Loadable Kernel Modules (LKM’s) in  Linux (providing you have root) , a kernel based rootkit seems not only powerful, but achievable.

2. Way to ensure that the Rootkit is run after a re-boot. LKM’s that are required by the kernel are loaded, leading me to assume that there is some form of list of required LKM. The Rootkit’s LKM could be added to a list like this, or a legitimate LKM could be replaced. This however is likely to cause major dependable issues and very well might knock over the box.

3. Healing; A way to stop any  user or application from removing rootkit files. This is not strictly needed, but easy to implement at a basic level.

4. Evasion mechanism. Probably one of the harder features to implement. Requires ether the hooking of call tables or the patching of legitimate functions. It is considered a key part of any Rootkit however,  and worth implementing correctly.

5. A Brain per-say, code that governs the logic and operations of the Rootkit.

Other parts of the rootkit such as opening ports and listening for connections can be added later on. By breaking what is a complex piece of software down, we can see that it is made up of simpler modules.

Divide et impera (Divide and conquer)


Format String Attacks (Reposted from my 1st year blog)

Final Post

April 9th, 2010

My white paper was finished last week, and this is just a final conclusion to my project. Currently i am trying to further knowledge of format strings, and working on ways of manipulating format strings. I was looking at a way to work out an address of shellcode and realised that it would be easier if it was always at the same location. In this respect i am working on writing shellcode to an environment variable, and the plan is to overwrite a destructor and point it to the environment variable when the shellcode is located; so far i have managed to write 2 bytes of shellcode. The procedure is complicated, though im gonna stick with it because im determined to make it work.

80%

March 18th, 2010

just a note to say that im roughly about 80% of my way through the white paper. Ive done all the major things and now im onto talking about what can be done with format strings. Thats about it realli

White Paper

March 11th, 2010

This comment is not so much more than a note to say im on to my white paper. Though there is plenty more to blog about i kinda feel that my time would be better spent writing up the paper. After where i left off last time i moved into multple writing a value into a variable. The variable being i, which is a enviroment variable. thats all im gonna put down for this post.

Perl and Shellcode; my favorite flavour!

February 25th, 2010

As ive meantioned before the white paper will be 10 times for specific on everything ive done and learned.

So we are at the point of overwritting i, so we do some stack exploration

Remember me meantioning AAAA , %x and %s before? lol

AAAA_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x

this prints out some like AAAA [random crap with each % being a byte] 41414141 [more random crap]

obiously is not quite like this, this is for simplicity. so now we know how many bytes into stack we are (cant remember if i meantioned but when printf gets more arguments than it should it starts printing bits of the stack which is what we are seeing.) and we can now limit our %x’s string to the ammount we require and change our last %x into %s so that we can see what its pointing at, i.e. (character string pointed to by the argument.) but that dosent realli do much 2bh (unless u find a program which dosen clear a variable that contains say, a password? :P )  what is much more useful to us is %n. i meantioned it before, and it allows us to write directly to stack addresses. so, we have the address of i, for me it was “\x2c\xa0\x04\x08″ are we replace AAAA (a byte) with our shellcode address (also a byte).

it would look like this (using Perl to generate it):

`perl -e print’ “\x2c\xa0\x04\x08_%x_%x_%x_%x_%x_%x_%x_%x_%x_%x_%n”‘`

printf() has printed 67, and as a result our variable is now 67 :-)

so thats the basics down, we know on a basic level how to exploit using format strings, gets better than this though ;P

 

i found i 🙂

February 25th, 2010

Ok so i got i, and that rocked. i think the original value of i was 42 (meaning of life lol). but what if we dont want the value to be 42 ;P. well we can use Perl along with… infact i cant even remember if ive posted the information needed for this part… ok first of all quick recap.

printf(char*, …);    –    standard fromat for printf, each variable has a corresponding token to indicate how many variables are being passed and there formats. exploitation works around several factors, first human error, printf(variable) and printf( token, variable) are different, with the second being the correct and safe way of calling printf(). Second is misuse of the tokens. the ones ive been using for explotation are %x; just for printing the stack in hex (means i can locate my four A’s, ill explain this beter in the white paper, which in hex is 41414141 in hex. if u used AAAB instead it would be printed 42414141 because its the stack and prints backwards), %s  prints the string that your address is pointing to. and the most dangerous %n which is designed to print out the number of bytes that printf()    (along with other functions i assume) has output to the argument you are on in the stack which is considered to be a pointer to an integer and in retrospect means that we can write to the stack.

right think im just bout back on track…

so Perl is a tet editing program, it incorporates some of the most popular functions of other languages, including printf() from the C/C++ library. Bet this is sounding ominous lol…

 

Havent blogged in a bit

February 25th, 2010

Since this is madatory i guess i should yapper on a little more :-) . well ive been dead busy recently, and ive been taking screenshots and stuff for the whitepaper, though a whitepaper kinda implys no pictures… i have no idea lol. Anyways… long story short had some good breakthroughs where i was kinda stuck, first one is i figured out where i get shellcode from. basically u take your assembly programs and through it into gdb and debug it, it gives u hex command which are the equivalent of your assembly, and u add, say in th case of…

c8

4b

7a

0d

it becomes /xc8/x4b/x7a/x0d

so that was pretti handy :-)

on the note of the shellcode i managed to find the address of that variable i want to changed and print its address on the stack. i cant remember the exact address but it gave me a 7 hex digit address (building up to a interesting point here lol)

say for example in gdb i type “print &i” this would print the location of i

ex:

c7d83s9  –  keeping in mind that the stack is in reverse i thought i would go to /xc7/xd8/x3s/x90

/x90 however is wrong, and should be x09 as the extra 0 bit is added to the left has side of the 7 bit number.                       more comming but this blog is getting messy lol

 

Where to start

February 13th, 2010

Well from what i can gather formt string attacks are somewhat obsolete nowaday, however i like that they demonstrate how bad programming can be exploited. So ive started to learn C++ as what ive been reading all refer’s to C and C++, suggesting the C# cant be exploited in this way. Ether way C# and C++ syntax arent very different so using the programming notes from one of the CGAD modules ive went and learned everthing they have done in the first simester in one night (go caffine lol.) I now have the ability to move forward with my project, and have a couple of handy books to help me out. Buffer overflow attacks seems like its going to be the most useful lol

 

First Comments

February 13th, 2010

OK, well first of all if anyone reading this dosent know, a format string attack is a type of buffer overflow attack. Admittedly its a variation i have only just discovered, and did so while reading a book called hacking exposed, where there was a very small section on it. i researched it a little bit, and it appears that the exploit is little know about in comparison to its cousins suck as the stack overflow or heap corruption exploits. It was discovered in the year 2000 by a University (if i remember right it was Washington Uni,) and overnight its discovery rendered thousands of systems on the internet vulnerable. It basicalli exploits bad programming and the fact that in C and C++ you can pass in a variable ammount of arguments into a printf function, but the string never checks how many arguments it is meant to be receiving.

So thats the basic background, onto the work…

 


Rootkits: injection by syringe

Rootkits are an awesome technology, maintaining access to a victims system after they have been compromised. But how does a rootkit work? First of all the rootkit must be categorised. There are five types of rootkits; library, application, firmware, kernel and virtualised.

This post deals with Application level rootkits, which are the most basic. Unsurprisingly this makes it the easiest to detect. On a Linux machine the terminal application is stored at /bin/bash (/bin/sh is also a linux shell, though we will ignore that for the moment.) By removing the legitimate terminal application, and replacing it with the binary (compiled version of the rootkit application)  that is conveniently called  bash, we can trick the user into running that rootkit, when they think they are running the terminal. A major problem with just replacing the binary is dependency; if another application calls your binary is it robust enough to handle it? Generally to avoid anything conspicuous the legitimate code will also be run, and therefore this problem is worked around. Often this will be done in the form of patching, where the malicious rootkit code will be ether spliced into the application, or there will be some form of execution subversion so that the rootkits code will be run. The Issue with patching is that it increases file size. Ideally the way around this is to use a detour patch to jump out of the program into another, execute the malicious code, and then jump back into the original code. Generally speaking a detour patch will contain two jumps out of the application; the first  to initialize data and execute the patch, the second to clean up to avoid knocking the application/system over.

Again, by keeping the rootkit in userland we avoid the danger of knocking over the system. However, as anti-virus is userland based they are far more likely to detect the rootkit (ether through a recognition of the binary signature or through heuristic (behaviour) analysis. Other types of rootkit, though more difficult to code and implement have the advantage of being far harder to detect and remove.


Androids full of viruses; at least its not herpes …

So a report was released today that suggests that there are around 50 malicious app on the android app market. Well I cant say im surprised. Not to flaunt any discontent towards google; I myself am an avid googler, and think they should be in the guinness book of world records for the worlds longest wardrive. Anyway, not to digress… Having one location to download software from (for the typical user) mean that it would inevitably be taken advantage of. My analogy for this a football stadium, no matter what you try to do , eventually someone is going to get past security and run onto the pitch naked and screaming. They will of course be delt with, but by that point the act has already been performed.

It appears that the mechanism for spreading these viruses is to patch, or rather tach-on the additional, malicious code to popular and well known application. Then, repackaging them and hosting the new version on the app market. The name of the virus is DreamDroid, and affects current versions of Android, barring the newely released Gingerbread. The code allows the remote installation ( and by extension we can assume remote execution) of applications on your device, aswell as sending your personal information and phone id to a remote server. The open source basis of Android has arguably brought this on itself, that being said, the open source community is very likely to respond with a patch to this attack, though any changes to the app market are down to google to solve.

“don’t be evil” – google moto


Just what is it about Linux?

So Ryan and I were touring around prospective students today, and I couldn’t help but find myself preaching to them. In the end all it would do is benefit them (I guess that what all preachers say). Never the less it seems safe to say that Hackers love Linux. Thinking back to it I’m not sure that most of them will even knew what Linux is. When is was in that position, I knew what it was, though beyond that it was an operating system my knowledge was shamefully bare. But why do we like Linux? Yes it is open, and yes it is free, but so are most UNIX distribution. Surely it has to be more than that? Personally I enjoy the ease of it. The idea behind it makes sense; a system that I can change and redistribute till my heart is content. Having played about with the kernel components of Linux for a time now, I can honestly say that I actually enjoy the kernel. All of the header files are easily accessible (and alterable), and including your own headers is easy once you know what you are doing. Kernel modules are an excellent way of loading in drivers, or other software that you need running in the kernel (rootkits anyone?) Linux just ticks all of my boxes, and while I don’t dislike Windows, I find it a system that I use on a less frequent basis (avoiding proprietary format that force you to use Windows.) I guess the fact stands, penguins rock.


A consideration of Hacking

People in security can define a hacker.  It is not only a requirement of their job, but in general a part of their passion for what they do (assuming that they are as security obsessed as I am.) The worrying point is that the public have a false impression of what a hacker actually is. By surprising extension, even the Oxford definition a hacker is somewhat, misleading…

” a person who uses computers to gain unauthorized access to data.

informal an enthusiastic and skilful computer programmer or user.”

So yes, we might consider a hacker as someone who can break the security of a computer system. Though It is their intention and motive (as well as their contract and disposition) that dictates whether the system has been hacked or cracked. There should be, if their is not already, a movement within the security community to raise awareness among non-techies. To educate and reassure the public that a hacker is not the baddy, but rather a dark superhero fighting to make the world that little bit safer.

Ok, so maybe that is a little idealistic. What can i say, maybe one day