Category Archives: University Work and/or research

Hacking with Python #0

Its been a while since ive posted anything, and for that I apologise.

Typically, my programming experience is derived from what ive been taught, as opposed to what language I found best for the job. In school, I was taught Visual Basic, in Uni I was taught C#. However, as most hackers do I taught myself C (well, enough C to explore stack based attacks) and what little assembly I could understand before my brain melted. However, the past two months I have programmed solely in Python, and by god, what an experience.

Python has so many fantastic things associated with it, that I hardly know where to begin. To start with the most obvious Python code is generally substantially shorter than any of the 3rd/4th generation languages. This is in part thanks to the massive  range of libraries associated with it. Though this does bring in the disadvantage that if an application requires a specific 3rd party library to run, you must first install it before you can run the application. However, Python is still cross platform, and extremely easy to develop in. In addition, Python is also an Object Orientated language, though it is worth noting that Python is extremely strict on indentation, and all python indents should be 4 character space in length.

Python development is as easy as typing python into your terminal (Linux/Unix boxes utilise python scripts, therefore some version of python will already by installed on them)

rorie@boo:~$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.

this is the python interpreter, we can run commands straight from here, or we can save them with the .py extension and run it as a script

>>>print “hello”

hello

Ok, so that was easy. It was also pretty boring…

The really amazing thing about python is the amount of different frameworks and API’s built on top of it. I want to show you some of the cross platform frameworks built on top of python, and just how easy they are to use thanks to awesome pythonic coding.

Scapy – Scapy is a packet manipulation tool. It allows you to literally build a packet from the ground up, as well as send an receive them. If installed from the Ubuntu repository the set-up of the environment variables is done for you and we can jump right in.

rorie@boo:~$ sudo scapy
[sudo] password for rorie:
INFO: Can’t import python gnuplot wrapper . Won’t be able to plot.
INFO: Can’t import PyX. Won’t be able to use psdump() or pdfdump().
WARNING: No route found for IPv6 destination :: (no default route?)
Welcome to Scapy (2.0.1)
>>> IP(dst=”192.168.1.1″, src=”192.168.1.100″/TCP(dport=[80

We can ignore the info messages as what we are using scapy for does not require the additional packages. We can easily create a ping packet as follows:

>>>packet = IP(dst=”192.168.1.254″, src=”192.168.1.100″)/TCP(dport=[80])

and we can send it with

>>>sr(packet)
<IP  version=4L ihl=5L tos=0x0 len=44 id=0 flags=DF frag=0L ttl=64 proto=tcp chksum=0xb619 src=192.168.1.254 dst=192.168.1.100 options=” |<TCP  sport=www dport=ftp_data seq=4256930905L ack=1 dataofs=6L reserved=0L flags=SA window=5840 chksum=0x6219 urgptr=0 options=[(‘MSS’, 1460)] |>>

You need to remembers that packets are build out of headers. Since TCP and IP are actually different headers, we need to create them separately and put them together. The source is the local machines IP, and in this case the destination is the local router.

Scapy’s sr (send an receive) function sends your packet, the waits for a reply.

Lets take a look at doing this again, but for IPv6.

>>> a = IPv6(dst=”fe80::20c:29ff:fe5f:f12″,src=”fe80::20c:29ff:fe51:5e07″)/ICMPv6EchoRequest()
>>> sr1(a)
Begin emission:
*Finished to send 1 packets.

Received 1 packets, got 1 answers, remaining 0 packets
<IPv6  version=6L tc=0L fl=0L plen=8 nh=ICMPv6 hlim=64 src=fe80::20c:29ff:fe5f:f12 dst=fe80::20c:29ff:fe51:5e07 |<ICMPv6EchoReply  type=Echo Reply code=0 cksum=0xbfd9 id=0x0 seq=0x0 |>>

This demonstration is by no means a detailed description of what scapy, or indeed python can do. But I hope it has been a nice little last of it. This is the first, in what will be a serious of tutorials I will release involving the use of python.

P.S – I am no way near done with Scapy, and there is alot more coming shortly!

 


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.