• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

c coding . How do i exploit this code?

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exploits // System Weaknesses

View previous topic :: View next topic  
Author Message
blackmagic22
Just Arrived
Just Arrived


Joined: 20 Dec 2002
Posts: 0


Offline

PostPosted: Wed Sep 05, 2007 5:34 pm    Post subject: c coding . How do i exploit this code? Reply with quote

Is it even possible?

Code:

/*local stack overflow exploit pratice*/

#include <stdio.h>
#include <string.h>
haha();

int main()
{
  char buff[15];

  printf( "login:" );
  scanf( "%s",&buff );
  getchar();
  printf( "You entered %s",buff );
  getchar();

  return 0;
}

int haha()
{
  printf("exploited !!\n");  /*use this as our eip so we know it worked*/
  return 0;
}
Back to top
View user's profile Send private message
MattA
Trusted SF Member
Trusted SF Member


Joined: 13 Jun 2003
Posts: 16777193
Location: Eastbourne + London

Offline

PostPosted: Wed Sep 05, 2007 7:06 pm    Post subject: Reply with quote

Yes it is, you've got a 15 char buffer there , so entering any string longer than
15char will start over writing addresses in memory Smile

What O/S are you using? it's different writing exploits under linux than win32, you might also have to turn off stack protection on the O/S.

Turn on memory dumps and then examine the dumps created when the app crashes with GDB. I'd use a string like AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
then search through the dump for the string.
Back to top
View user's profile Send private message
blackmagic22
Just Arrived
Just Arrived


Joined: 20 Dec 2002
Posts: 0


Offline

PostPosted: Wed Sep 05, 2007 7:38 pm    Post subject: Reply with quote

Thanks alot for your answer Matta.

I have tried to exploit it ,but no luck.
I'm doing something very wrong because the program comes up with the login window but it's no putting in anything anutomatically for the login.

I'm on windows xp sp2.

Code:

#include <windows.h>
#include <stdio.h>
#include <string.h>

int main()
{
  char program[15]="c:\\exploit.exe "; /*15*/
  char ret[]= "\xA5\x12\x40";      /*3*/
  char overflow[]=
  "AAAABBBBCCCCDDDDEEEE"; /*20*/

  printf("vulnerable Stack overflow exploit\n");

  strcat(overflow,ret);

  WinExec(program,overflow);
return 0;
}
Back to top
View user's profile Send private message
Advocate
Just Arrived
Just Arrived


Joined: 31 Aug 2006
Posts: 0
Location: Amsterdam, NL

Offline

PostPosted: Fri Sep 07, 2007 3:20 pm    Post subject: Reply with quote

It looks to me like you're passing overflow on the command line to exploit.exe whereas exploit.exe doesn't take input from the command line; it expects an interactive session.


I could be wrong, only glanced at this.
Back to top
View user's profile Send private message
Colonel_Panic
Just Arrived
Just Arrived


Joined: 13 May 2004
Posts: 2


Offline

PostPosted: Fri Sep 07, 2007 5:33 pm    Post subject: Reply with quote

yes, this version of main() does not take command line parameters.
You need to use main(int argc, char *argv[]) and change your exploitable program to read argv[1] into buff. (if I remember right, argv[1] is the first parameter)

Also, check syntax for winexec() for correct use of quotations.
Back to top
View user's profile Send private message
blackmagic22
Just Arrived
Just Arrived


Joined: 20 Dec 2002
Posts: 0


Offline

PostPosted: Fri Sep 07, 2007 6:01 pm    Post subject: Reply with quote

So your saying that the only way i can exploit this is by changing the code of main()
to
Code:
main(int argc, char *argv[])


Thanks guys.
Back to top
View user's profile Send private message
Iņaki Viggers
Just Arrived
Just Arrived


Joined: 26 Aug 2008
Posts: 0


Offline

PostPosted: Tue Aug 26, 2008 6:50 pm    Post subject: Re: How do I exploit this code? Reply with quote

Hi, I know this thread is a somewhat old, but the conclusion above is not accurate.

That program is exploitable without modifying its source code at all.
The following input sets IP to 402059 (to print "exploited!" as requested) and it's clean in the sense that the program doesn't crash and it even has 0 as Exit code:

0x66,0x81,0xF1,0xA5,0x81,0x51,0x80,0xE9,0xBC,0xFE,0xCD,0x51,0x8B,0xEC,0xC3,0x41,0x41,0x41,0x41,0x41,0x70,0xFF,0x12

Or in terms of opcodes:
Code:
XOR CX,81A5h
PUSH ECX
SUB CL,0BCh
DEC CH
PUSH ECX                            ; edit: 'PSUH' was a typo
MOV EBP,ESP
RETN
INC CX
INC CX
INC CX
INC CX
INC CX
DB 70h
DB 0FFh
DB 12h


Nice exploitme. I'd be glad to know if you have more exercises like this.

Iņaki Viggers

Moderator note: added code tags - capi


Last edited by Iņaki Viggers on Fri Oct 03, 2008 1:32 pm; edited 1 time in total
Back to top
View user's profile Send private message
BluePass
Just Arrived
Just Arrived


Joined: 23 Mar 2008
Posts: 0


Offline

PostPosted: Fri Oct 03, 2008 8:13 am    Post subject: Reply with quote

I'm going to try to explain this tomorrow, because I think that Iņaki did not explain things as thoroughly as he should've. I hope this topic is still interesting to some people and I'm not doing this for nothing. I do realize that the initial post was over a year ago and has been brought back by Iņaki recently.

If this is done on Linux or other Unix-like operating system, it would be trivial. On Windows it's a bit different because of the memory address stack variables and functions tend to have (the highest byte being 00), which would normally terminate a string in C/C++.

The first thing Iņaki overlooked was that haha() will have different addresses on different systems. The second thing was that if blackmagic22 wanted to run that exploit and launch the the vulnerable program with WinExec, he would need to have main() declared as: main(int argc, char **argv), but the vulnerable program had to somehow use those command-line arguments, possibly copying them into 'buff' without bounds checks.

Without modifying the vulnerable program at all it may or may not be done -- this is something I am going to be tackling tomorrow. I have a few ideas/tricks up my sleeves. Cool

EDIT: The fact that it's the highest byte that's null makes this very trivial, so no need for tricks. I will explain tomorrow. Smile
Back to top
View user's profile Send private message
Iņaki Viggers
Just Arrived
Just Arrived


Joined: 26 Aug 2008
Posts: 0


Offline

PostPosted: Fri Oct 03, 2008 1:29 pm    Post subject: Reply with quote

BluePass,
First: The question was about how to exploit, not why that happens. Then Blackmagick22 asked "Is it even possible?", so I showed it was possible and provided an exploit.

Second: Note that the third posting refers to "windows.h", which discards the POSIX compliant platforms. Therefore it wasn't necessary to specify that my exploit addressed Windows ... Right, there are different releases of Windows, but Blackmagic22 further specified Windows XP SP2. That's the version for which I developed the exploit.

Third: That being a short application, its image is not likely to be splitted by OS on grounds of Virtual Relative Addressing. To be honest I didn't deploy these opcodes on a large number of systems. But should you find a machine assigning different values, you can modify the constants in the exploit to suit the runtime values accordingly. The logic and structure of exploit would be the same.

Fourth: At the end you say "without modifying ... it may or may not be done". If you mean done on Windows, then I already showed it's definitely possible. If you mean Linux/Unix, then that's an extension to the thread, not that somebody overlooked whatever.

And yes, historically exploits for Linux are known to be less tricky than those for Windows. I just haven't tried the new features of gcc compiler to prevent bounds checking.

(Edited, per Capi's suggestion below).


Last edited by Iņaki Viggers on Fri Oct 03, 2008 4:25 pm; edited 2 times in total
Back to top
View user's profile Send private message
capi
SF Senior Mod
SF Senior Mod


Joined: 21 Sep 2003
Posts: 16777097
Location: Portugal

Offline

PostPosted: Fri Oct 03, 2008 1:48 pm    Post subject: Reply with quote

Let's play nice, friends... It's been a while since we've even had any exploits discussion, try and make the best of it Smile

Now, I don't want to mix moderation with participation, and I'm sure this is obvious to everyone here, but in the interest of preventing any miscommunication due to things being left implied: note the scanf reading into buff, and think overflow through standard input. Also, remember argv is still placed in the stack regardless of whether or not main looks at it.

Carry on, and have fun! That's what we're here for.
Back to top
View user's profile Send private message
BluePass
Just Arrived
Just Arrived


Joined: 23 Mar 2008
Posts: 0


Offline

PostPosted: Fri Oct 03, 2008 8:05 pm    Post subject: Reply with quote

Thanks, capi! You're the man! Very Happy

Now to answer Iņaki first...

I did not say that I was going to explain why it happens -- I am assuming that if blackmagic22 has gotten to the point he's playing with exploits, he has a basic understanding of at least the theory behind stack overflows. However, I also don't believe that the way to explain things is by simply throwing in a few addresses, the input that will cause the overflow and make the program reach haha(), and not explain how you've gotten there. The reason he's here in the first place is to learn.

For the second part, I have only mentioned Linux and other Unix-like operating systems once and that was to say that it would've worked much easier if the addressing was done that way. Later I realized that the way Windows does things is just as easily exploitable. I haven't really made any connection between what you've said and POSIX compliant platforms.

For the third part, one could modify those constants only if they understand what you're doing there and you haven't given anyone any insight as to what you're doing. Further off, I've tested it and it didn't do anything -- and I am running Windows XP SP2. I didn't have time to debug it and see what you're doing there, yet, but when I will, I will check it out.

Finally, I said that it may or may not be done, because at the time I made the post I haven't yet tried anything. Later in the night I actually got around to trying it and found the exploit method to be trivial.
Back to top
View user's profile Send private message
Iņaki Viggers
Just Arrived
Just Arrived


Joined: 26 Aug 2008
Posts: 0


Offline

PostPosted: Sat Oct 04, 2008 5:10 am    Post subject: Reply with quote

You know what? It's really boring to answer each one of the mutating objections, so I'll bypass most of them and hopefully there's an end to it.

There's a couple of remarks I need to add:
I. Since our starting point is a source code (not an executable), each different compiler will create a different binary. This results in different function offsets. I used Digital Mars C/C++ Compiler ... Version 8.50 ... and compiled with all the default options. That's how I got the value 402059 as target IP. This value is most likely to change under other compilers and I forgot to point it out. However it's false that with XP SP2
"haha() will have different addressses on different systems"
It's not about that.

II. This is a brief explanation of what these opcodes do when stack is overflown:
Opcodes 1-4: Take advantage of initial value of ECX and make it equal to target IP.
Opcode 5: Push ECX, which is now the target IP
Opcode 6: restore EBP to avoid crash after printing "exploited!"
Opcode 7: Return, now to target IP
Opcodes 8-12: Slack bytes
Opcodes 13-15: Override caller offset and redirect to the opcodes above (in the stack).

Indeed it's possible to exploit the target program without modifying it at all.
Back to top
View user's profile Send private message
BluePass
Just Arrived
Just Arrived


Joined: 23 Mar 2008
Posts: 0


Offline

PostPosted: Sat Oct 04, 2008 10:07 pm    Post subject: Reply with quote

It's pretty pointless arguing about this, especially if you're going to take my words and twist them somehow to try to show that I'm wrong. So I'm going to stop here too.

However, for those that do want to know the quick and easy way to reach haha() -- it's a simple stack overflow like any other.

For your usual stack overflow, assuming you have a large enough buffer to store some code, you would overwrite the variable with that code, a NOP padding and overwrite the stored EIP address below with the address of that variable. This would cause the processor to start executing the code from the stack, and more precisely the variable you've overrun.

For this example, you don't have to worry about having to put any shellcode in there -- all you want to do is overwrite EIP with haha()'s address. You'd open up OllyDbg or a debugger of your choice and find haha()'s stack frame and write down the address where it begins.

You'll reverse this address (assuming little endian): so from 004012FD to FD124000, and separate it into individual bytes. Now you want the ASCII representation of those 4 bytes (really, you want only the first 3, because the last byte is null). The quick way to get the ASCII representation of these is something like: printf("%c%c%c\n", 0xFD, 0x12, 0x40);

Now all you have to do is append these 3 characters to a series of 28, say, "a"s -- you don't have to worry about the 00 as it will be inserted automatically to represent the end of the string. The best way is to try this out in OllyDbg a few times and watch what happens in the memory as you input more "a"s. You'll want your "a"s to fill to the address right above the first return address (which is given to you by OllyDbg as a comment) as that will be the return address of main().

I hope this makes sense. It's not clean as a shellcode would be, but it doesn't require any knowledge of assembly.
Back to top
View user's profile Send private message
BluePass
Just Arrived
Just Arrived


Joined: 23 Mar 2008
Posts: 0


Offline

PostPosted: Mon Oct 06, 2008 3:17 am    Post subject: Reply with quote

Could somebody confirm that Iņaki's input actually works?

I've just gone through it a couple of times and ECX doesn't get a value anywhere near that of a text or data address. Maybe it's a compiler-related issue, but I'd like to know. In fact his input is not even lengthy enough to overwrite the stored EIP on my executable.

And don't think that I'm trying to pick an argument with him or something. I'd just like to understand what he tried to do there and I'm not having any luck.
Back to top
View user's profile Send private message
Iņaki Viggers
Just Arrived
Just Arrived


Joined: 26 Aug 2008
Posts: 0


Offline

PostPosted: Tue Oct 07, 2008 1:24 am    Post subject: Reply with quote

Try with the compiler, version & default options I mentioned above, it's downloadable from Digital Mars website. The reason is that each compiler has its own strategies for machine code generation, use of registers, optimization, memory allocation and alignment.

Your compiler must be building executables with some alignment policy, so that's why the exploit above doesn't even fill the buffer in your binary.

Compilers might even use different registers. In this exploit ECX is the central register, but with other compilers another register might become more convenient. In the worst case scenario a redesign of exploit would be needed.

When it comes to exploits the best option is to take an executable (not its source code) as a starting point. If you prefer you can compile the code "as is" and upload it so we all look at the same binary.
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exploits // System Weaknesses All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register