So, does anyone know how to 'hack'?

[yllus]

To finish off my school career, among other classes I will be one entitled Computer Forensics and Security. My first assignment:

This assignment is about using remote exploits on a prescribed set of victim machines.

The goal of this assignment is to compromise several systems on a private network. In addition to fairly standard daemons running on your private victim systems, there is an instance of a server with a buffer overflow problem. You must generate an exploit for that program for each of Linux and Windows.

Pretty cool huh? Basically I require help in two areas:

1) I need to execute a successful buffer overflow in this program. Those 'in the know' recognize that C functions like gets() are inherently insecure because of the lack of bounds checking. However, this is the line I'm dealing with (edited to highlight the code to attack):

char *bp;
int s;

read(s, bp, 99);

Does anyone know what the approach should be to overload the read() command successfully? It's possible that I'm misled about what code to target and attack, but I'm pretty sure the above is correct.


2) The other servers will be running IIS 5.0, older versions of Apache, etc. Is there a certain site where I can collect prewritten exploits to compromise the systems they're running upon? We are not required to write our own code to accomplish these goals - the point is to dig and break in as efficiently as possible.

 

[notfred]

I want to take that class.

 

[Falloutboy]

ditto sounds like fun...the extent of my hacking knowledge ends with netbus type programs. and thats not even real hacking

 

[kamper]

First off: you've got to learn the correct terminology

A "hacker" is a good thing. One definition might be one who takes a difficult programming problem and codes an ingenious solution.
A "cracker" is what you want to be. A cracker breaks systems in a malicious manner.

I'm sure you're aware of it, but since you didn't mention it, I believe what you want is buffer overflow. Basically, send more data than a buffer was expecting. The vulnerability would then consist of the target program not stopping you from writing whatever data you want into a piece of memory that it didn't anticipate you having access to. The data you send is probably machine code that will execute some malicious action.

I think to do this right you have to understand the stack frame layout of the vulnerable program. Every function has a return address which specifies where in memory the previous (calling) function code is located. If you can overwrite the return address you can start the program executing anything you want. The trick would be figuring out what memory location to send it to.

 

[notfred]

Originally posted by: kamper
I'm sure you're aware of it, but since you didn't mention it, I believe what you want is buffer overflow...

Uh, it says "buffer overflow" right in the assignment.

 

[yllus]

Originally posted by: notfred
I want to take that class.

This is the coolest class ever. 20 students, senior year students only, competing against each other in assignments with a number of lectures being given by federal and provincial police force representatives. I'm actually expecting to learn something for once.

Originally posted by: kamper
First off: you've got to learn the correct terminology

A "hacker" is a good thing. One definition might be one who takes a difficult programming problem and codes an ingenious solution.
A "cracker" is what you want to be. A cracker breaks systems in a malicious manner.

I'm sure you're aware of it, but since you didn't mention it, I believe what you want is buffer overflow. Basically, send more data than a buffer was expecting. The vulnerability would then consist of the target program not stopping you from writing whatever data you want into a piece of memory that it didn't anticipate you having access to. The data you send is probably machine code that will execute some malicious action.

I think to do this right you have to understand the stack frame layout of the vulnerable program. Every function has a return address which specifies where in memory the previous (calling) function code is located. If you can overwrite the return address you can start the program executing anything you want. The trick would be figuring out what memory location to send it to.

Hey kamper, thanks for the reply. I actually know the terminology and all, but decided to go with a more appealing title over one that's strictly accurate. Note the quotes around the word 'hack' in the topic title.

I agree, overflowing the stack is exactly what part one of this assignment comes down to. By using gdb, nm and online resources I've figured out well enough what my attack approach will be. All of it was quite elementary and is well-outlined in Aleph One's Smashing The Stack For Fun And Profit.

What it's come down to is how hole.c is written. To fill the 100-character buffer, it executes the read() function as detailed in my first post. The problem is, I simply don't know how read() can be exploited. I can carry the rest of the load knowing that.

 

[EngenZerO]

@ your unix promt type man read

it may help you garner more insight.

 

[kamper]

Originally posted by: notfred

Originally posted by: kamper
I'm sure you're aware of it, but since you didn't mention it, I believe what you want is buffer overflow...

Uh, it says "buffer overflow" right in the assignment.

Heh, whoops

 

[montag451]

if you are taking a class sponsored by law enforcement, then the chances are that the qualification you will get is going to lead you into a job that will attempt to stop the activities of the people you are now asking information from!!!!

WTF are you doing?

prick

 

[yllus]

Originally posted by: montag451
if you are taking a class sponsored by law enforcement, then the chances are that the qualification you will get is going to lead you into a job that will attempt to stop the activities of the people you are now asking information from!!!!

WTF are you doing?

prick

What the hell are you talking about?

 

[Mr Smiley]

Originally posted by: kamper
A "cracker" is what you want to be.

Hey, Im a cracker!!! O wait...

 

[Schadenfroh]

Originally posted by: Falloutboy
ditto sounds like fun...the extent of my hacking knowledge ends with netbus type programs. and thats not even real hacking

same.

 

[CTho9305]

I took a class where we had to exploit a buffer overflow many different ways - first a basic stack smash, then with progressively harder restrictions (not crashing the victim program, not being detected using various ways, etc). It was a sophomore level CS course. I'll edit this post in a bit after checking out your victim app.

edit: you're right, that's the vulnerable point. Here's what the readit function is doing:
1. read up to 99 bytes into bp (points to beginning of a 100 byte buffer)
A. if there was an error, die
B. if you're out of data, return 0
2. otherwise, advance bp by the amount of data read.
3. if the buffer has a newline before the end of it, return 1.

The vulnerability here is that it keeps advancing bp and tp for each read. The first read is safe - worst case, you read 99 bytes into the buffer. However, the next time around, it's reading up to 99 bytes starting from the point in the buffer where it ended up last time. Now unfortunately, buff wasn't allocated in readit, but in process. As a result, the return from readit isn't exploitable. However the 4th to 8th bytes after the 100th will overwrite the return address for process(). The trick is properly setting the other values nearby (0th-3rd bytes, others) so that the dup() functions work properly, because you need process() to return, not just die.

The easiest thing to do would probably be to open up a shell and do the rest of your exploiting as the user on the victim machine. To get the exploit to work reliably, you may need to use a lot of NOPs, because the enviornment variables affect stack offsets (NOPs make it possible to just set the return address to "close enough" to the actual exploit code and still have it work). You can probably get some linux shellcode online from crack sites, or just compile your own app that does exec("/bin/sh") and look at the resulting binary.

The fact that you have to exploit 4 different systems adds a little bit of difficulty. I think you can just connect 4 clients at once, one for each target. Linux will be trivial to crack - you just need to run the vulnerable program under a debugger to get the values on the stack that you can't clobber. Same goes for windows. The trick for the unknown system(s) is going to be finding your stack offset - if you're lucky, they'll be within a few thousand of the linux & win2k targets and you can just pad your exploit with NOPs.

 

[onelin]

read looks safe to me. I suggest you take a look at strcmp()

 

[Bulldog13]

Might have better luck in OT with this one.

 

[n0cmonkey]

packetstormsecurity.org
securityfocus.com

 

[leeland]

very interesting read

 

[CTho9305]

Originally posted by: onelin
read looks safe to me. I suggest you take a look at strcmp()

strcmp isn't usefully exploitable - at worst, you can crash the program with it, but not take control of anything. Read my reply right above yours - the read is in fact vulnerable. A correct implementation would have reset bp and tp to the start of buff every time right before the read, but they fail to do that.

 

[onelin]

I was certainly curious how it could be usefully exploitable... crashing it doesn't require much. Just saw your full update, very cool stuff

 

[shadowfaX]

cool stuff. too bad my school didn't have a course on this. but then again, i guess there's a certain joy from figuring it out on my own?

 

[yllus]

Originally posted by: CTho9305
The vulnerability here is that it keeps advancing bp and tp for each read. The first read is safe - worst case, you read 99 bytes into the buffer. However, the next time around, it's reading up to 99 bytes starting from the point in the buffer where it ended up last time. Now unfortunately, buff wasn't allocated in readit, but in process. As a result, the return from readit isn't exploitable. However the 4th to 8th bytes after the 100th will overwrite the return address for process(). The trick is properly setting the other values nearby (0th-3rd bytes, others) so that the dup() functions work properly, because you need process() to return, not just die.

Ah, excellent, a person who's done this before. I'm doing exactly what you're describing, but I have a question. How have you narrowed it down to the 4th to 8th byte after the 100th as the return address for process()?

I'm currently using this program - exploit.c - to connect to the port that hole.c is running upon, then sending a specially formatted string. It just won't fly so far.

 

[CTho9305]

First off, it's past 2am here, and I'm tired, so hopefully this reply is clear enough

Secondly, here is the assignment I did.

How have you narrowed it down to the 4th to 8th byte after the 100th as the return address for process()?

You have to look at how the stack is used. Slide 37 (page 10) of this lecture shows a little bit of the stack (I'm sure there's a better lecture somewhere, but I don't have time to find it, sorry).

From it, we can see that bytes 0-3 are the saved value of the %ebp register, and they're followed (bytes 4-7) by the return address. If you disassemble a function, usually the first instruction you see will be "push %ebp", and the last two will be "pop %ebp" and "ret".

Anyway, when we enter the process() function, we allocate a static 100 byte buffer "buff". In assembly, a static allocation like this is just a "sub %esp, 100" (move the stack pointer down 100), and since there are no other local variables in process, there's no chance that other things get allocated first. Therefore, if the start of buff is at location foo, it ends at foo+99, and is followed by the saved %ebp and return address (since they follow buff immediately on the stack).

So that's how I know that process's return address is bytes 4-7.

My first realization: you're going to have to not clobber s. When readit starts, the stack looks something like this (each row is 4 bytes) (read it from the bottom to the top):
<s> <-- I know s is here, because when you call a function you push its arguments, so main pushed s just before calling process()
<process return addr>
<saved ebp>
<buff 96-99> (fortunately for you, 100 bytes is divisible by 4 )
...
...
<buff 4-7>
<buff 0-3>
<s> <- passed to readit by process
<&buff> <- passed to readit by process
<readit return addr>
<saved ebp>
<c>
<tp>
<bp>

So, in order to exploit this properly, I believe you can clobber the saved ebp, but not s. You need to hook up a debugger to get the address of buff on the stack to put in bytes 104-107 of your exploit, and your exploit code should be short enough to fit into 104 bytes (buf plus the saved ebp). This will work as long as the stack offsets aren't changing - as I mentioned above, environment variable differences between your test area and the victim machine can make this assumption invalid.

If you can't fit the exploit into the 104 bytes of clobberable space, you're going to need to guess what the value of s is. They're tricky, so just using 0 and 1 won't work (because they close 0 and 1 before dup()ing them). Using 2 might work - they don't check if the third dup(s) succeeds. I think you'll hit:

else
write(s,ERROR_MSG,sizeof(ERROR_MSG)-1

but I don't think that will be a problem. So I think as long as you put "2" in bytes 108-111 of your exploit, you can pad it with NOPs as needed. Your exploit would look like this, if you need to defend against varying stack locations (top of this list is lowest memory location, i.e. address of buff):

104 bytes junk
return address into the middle of the NOPs
a few hundred or thousand NOPs (the environment size shouldn't vary THAT much)
exploit code

I'll proofread this at some point tomorrow if I have time.

edit: already found one mistake

 

[yllus]

Hey guys, just wanted to let you know how the assignment turned out. I was able to spawn a shell in my test environment but didn't have the time to pull it off on the assignment's network. Exploited a Windows 2000 IIS 5.0 server successfully, though. Here's my writeup.

CPS840 Assignment 1 Documentation

Thanks to all who responded, CTho9305 in particular.

 

[SagaLore]

Yes I know how to hack, but not at the level that you are describing. I wish I did though.