워드프레스 플러그인 취약점 분석 사례(1)
보안프로젝트 매거진
※ 주의사항
아래 공격 코드는 연구 목적으로 작성된 것이며, 허가 받지 않은 공간에서는 테스트를 절대 금지합니다.
악의 적인 목적으로 이용할 시 발생할 수 있는 법적 책임은 자신한테 있습니다. 이는 해당 글을 열람할 때 동의하였다는 것을 의미합니다.
해당 문서의 저작권은 저자들에게 모두 있습니다. 다른 용도로 사용되면 법적 조치가 가해질 수 있습니다.
이 문서는 보안프로젝트 유희만 연구원이 작성한 내용입니다. 워드프레스 취약점 보안위협을 강조하기 위해 공개합니다.
01. 개요
이번에는 Blind SQL Injection을 수행함에 있어서 수동 진단의 경우 한계점이 있으며, 이를 자동화된 도구 Sqlmap을 이용하여 손쉽게 공격하는 과정과 Blind SQL Injection에 대한 대응 방안 및 패치코드 작성에 알아보겠다.
02. 취약점 검증
먼저 Exploit-db에 등록된 플러그인의 취약점 정보를 살펴보자.
[그림 1.1] Gallery Object
위의 정보에 따르면 2014년 7월 18일에 발견된 취약점이며 Gallery Objects 플러그인의 v0.4 버전에서 발견된 SQL 인젝션 취약점이다. 취약점 정보에 따르면 GET 방식에서 발생되는 'viewid'라는 파라미터에 SQL 인젝션 취약점이 발생한다. 해당 취약점을 테스트하기 위해 플러그인에서 viewid의 파라미터를 사용하는 컨텐츠를 추가시키도록 하자.
[그림1.2] viewid 값 추가
위처럼 viewid의 값이 추가 된 것을 볼 수있다. 수동으로 패턴을 삽입하는 것은 공개문서에서는 생략하겠고, 지금부터는 Sqlmap을 이용하여 현재 DB의 유저 정보를 추출하도록 해보겠다. 필자는 아래와 같은 옵션을 반영하였다.
[그림 1.3] Sqlmap 공격 옵션
해당 옵션에 대해서 간단히 설명하자면 '-u'는 타켓 URL을 지정해준다. '-P'의 경우 Vector(취약포인트)가 되는 파라미터명을 입력한다. '--dbms=mysl'을 통해 타켓의 DBMS형태를 지정한다. 그후 '--current-user' 옵션을 추가하여 현재 DB의 User정보를 추출하도록 한다.
[그림 1.4] Sqlmap 공격 결과
Sqlmap으로 스캔한 결과가 출력되었다. 먼저 GET Method형식으로 전달되었으며 취약한 파라미터는 'viewid'임을 알려주고있다. 또한 SQL Injection에 사용되는 공격법은 Time Based Blind SQL Injection임을 알 수 있다. 먼저 피해 시스템의 WAS정보 및 DBMS정보를 추출했으며 그 후 현재 DB사용자인
'root@localhost'
를 추출하여 보여주었다. 어떠 방식으로 Blind SQL Injection을 수행했는지 패킷을 확인해보자.
[그림 1.5] SQL injection 공격 패킷 추출
위의 그림은 공격도중 캡쳐한 와이어샤크의 패킷 결과이다. 전달되는 SQL Injection 코드 값은 URL 인코딩되어 전달된다. 이를 정확하게 확인하기 위해 'Burpsuite'의 Decoder 기능을 이용하자.
[그림 1.6] URL 디코딩
Decoder 기능을 이용하면 손쉽게 평문으로 확인이 된다. 먼저 쿼리문을 살펴보면 IFNULL 함수를 사용하는데 해당 함수의 경우 IFNULL(value, value2)인 경우 value가 참이면 value를, 그렇지 않으면 value2를 리턴하는 함수이다. 따라서 CURRENT_USER의 각 자리 값과 비교하는 아스키 코드 값이 참이면 아스키 코드 값을 반환하므로 최종적으로는 'viewid=2 and 9227=1을 반환하게 되므로 거짓이 된다. 거짓의 경우 아래와 같은 화면을 반환하며 소스코드 상으로 보면 단지 0의 문자열을 반환한다.
[그림 1.7] 결과값이 거짓인 경우의 화면
좀더 명확히 하기 위해 현재 데이터베이스 이름을 추출하는 SQL Injection 쿼리문을 분석해보자. 먼저 디코딩된 첫번째 SQL 쿼리문을 보게되면 현재 DB네임의 2번째 문자는 'o'이므로 아스키 10진수 값으로 '111'을 가지고 있다. 따라서 결과 DATABASE() AS CHAR,0x20)),2,1))>108의 결과는 참이되므로 최종적으로 'viewid=2 and 7371=1'이 된다. 반환되는 패킷에는 정상소스코드가 아닌 0의 문자만을 반환하게 된다. 그 아래 SQL 쿼리문을 살펴보면 DATABASE() AS CHAR,0x20)),2,1))!=111이므로 '!='에 의해 거짓 값이 된다. 따라서 IFNULL의 경우 value의 값이 거짓이면 value2의 값을 반환하므로 'viewid=2 and 7371=7371'이 되므로 정상적인 소스코드 화면을 반환하여 현재 DB네임, DB사용자, 테이블명등의 비교가 가능하다.
CURRENT_USER의 값을 앞에서부터 1자리씩 아스키코드 값과 비교하여 해당 값을 추출한다. [{CURRENT_USER()AS CHAR),0x20))9,1))>104)]을 살펴보면 현재 9,1의 값을 비교함을 알 수 있다. 결과를 통해 알 수 있는 값은 1,1이 'r'이다. 공격이 수행될 당시 (DB에서의 1,1)의 값을 아스키 코드 값과 비교하여 참의 결과가 떨어지면 해당 아스키코드값에 해당하는 문자열이 CURRENT_USER의 첫 글자가 된다.
03. 취약점 분석
소스코드를 따라가면 차근차근 분석해보도록 하자. 먼저 취약한 파라미터인 viewid를 검색 필터인자로 잡아 어디서 취약점이 발생되는지 살펴봐야 된다. 'gallery-objects.php'파일을 에디터프로그램을 통해 오픈한 후 'viewid'를 검색해보자.
==========================================================================
<strong>[galobj viewid=<?php echo $iid; ?>]</strong>
</td></tr></table>
<br /><br />
<div class="go-form">
<?php _e('Edit View Settings Here.','gallery-objects'); ?>
<form method="post">
<input type=hidden name="go-action" value="edit-view">
<input type=hidden name="go-step" value="1">
<input type=hidden name="go-view-id" value="<?php echo $iid; ?>">
<table border=0 cellpadding=4 cellspacing=4><tr><td valign=top>
<?php _e('View ID','gallery-objects'); ?> </td><td valign=top>:</td><td valign=top>
<?php echo $iid; ?></td></tr><tr><td valign=top>
<?php _e('View Name','gallery-objects'); ?> </td><td valign=top>:</td><td valign=top>
<input type=text name="go-name" size=53 maxlength=64 value="<?php echo $go_name ?>">
</td></tr><tr><td valign=top>
<?php _e('View Type','gallery-objects'); ?> </td><td valign=top>:</td><td valign=top>
<select name="go-type">
<option value="1">1 AD Gallery - Slideshow</option>
</select>
==========================================================================
먼저 위의 소스코드는 Line 469 ~ 488까지의 내용이다. [그림 1.2]에서 확인한 값들이 위의 소스코드를 통해 사용자에게 출력된다.
==========================================================================
echo "<input type=button value='Preview Settings' onclick=\"go_iframe_reload(this.form,'ifid','"
. dirname($_SERVER['PHP_SELF']) . "/admin-ajax.php?action=go_view_object&viewid=" . $iid . "&type=html')\">\n";
echo "</td><td width=10></td><td colspan=2 align=center>\n<br />\n";
echo "<input id=\"go-button-save\" type=image onClick=\"go_save_view_settings(this.form); return false;\" src=\"";
echo $go_folder . "images/save-settings.png\">\n";
echo "</td></tr></table>\n";
echo "</form>\n";
// Shall we do an iframe here for the view now?
echo "<iframe frameborder=0 id=ifid allowtransparency='true' width=100% height=800 "
. "src=\"" . dirname($_SERVER['PHP_SELF']) . "/admin-ajax.php?action=go_view_object&viewid=$iid&type=html\">\n";
echo "</iframe>\n";
echo "<br /><br />\n";
==========================================================================
이어서 Line 821 ~ 835까지의 내용이다. 이 부분은 플러그인의 목적인 각 ID값 마다 서로다른 디렉토리를 생성하여 관리를 용이하게 해주는 부분이다. 여기서 서로 다른 디렉토리를 구분하는 인자가 바로 'viewid'값이 된다. 우리가 그림에서 확인한 viewid = 2에서 실제 2가 '$iid' 변수에 반영된다. 그러면 해당 내용을 DB에서 추출하는 부분은 어디인지 살펴보자.
==========================================================================
function _goget_view_settings($viewid=0,$viewtype=0) {
GLOBAL $wpdb, $go_table_name, $go_defaults;
$reset = 0;
$update = 0;
if ((!$viewid) && (!$viewtype)) return null; // You MUST supply either a viewid OR a viewtype OR both
if ($viewid) { // Retreive Settings from DB
$golink = $wpdb->get_row("SELECT * FROM $go_table_name WHERE id=$viewid");
$go_data = unserialize($golink->value);
if ($viewtype) {
if ($viewtype!=$go_data['viewtype']) { // Lets reset to the default settings
$reset = 1;
$go_data['viewtype'] = $viewtype;
}
}
==========================================================================
Line 1097 ~ 1113까지의 내용이다. '_goget_view_settings'라는 함수를 선언한 후 워드프레스API에서 제공하는 전역변수인 ($wpdb, $go_table_name, $go_defaults)를 선언하고 있다. 여기서 $wpdb의 경우 워드프레스 데이터베이스에 대한 접속정보 및 관련정보를 가지고 있는 변수이다. 따라서 해당 변수를 이용하여 '$wpdb->get_row("SELECT * FROM $go_table_name WHERE id=$viewid'를 수행하여 '$go_table_name'의 전역변수에 저장된 테이블명을 가져와 해당 테이블에서 viewid 컬럼값을 통해 DB 내용을 추출하게 된다. 여기서 viewid의 값에 대해서 어떠한 필터링 또는 시큐어코딩이 되어 있지 않기 때문에 SQL Injection의 취약점이 노출되게 된다.
03. 대응방안 및 패치코드 작성
============================================================================
function filter($sqlinjection){
$sqlinjection=htmlspecialchars($sqlinjection, ENT_QUOTES);
$sqlinjection=strip_tags($sqlinjection);
$sqlinjection=mysql_real_escape_string($sqlinjection);
}
filter($viewid = _goget['viewid']);
if(strstr(_goget['viewid'], "CURRENT")||strstr(_goget['viewid'], "SELECT"))
{
echo "<script>alert('SQL Injection GO OUT!!')</script>";
exit();
}
============================================================================
패치코드의 경우 위와같이 작성해줄 수 있지만 이에 대한 우회가 가능하기 때문에 Prepared Statement 방식으로 변수를 바인딩처리 하는 것을 권고 한다. Prepared Statement방식을 php환경에서 적용한다면 아래와 같을 수 있다.
==========================================================================
$qry = "select * from olympic where project_name=BoanProject and project_user='Securely' ";
$result = cubrid_execute($con, $qry);
$row = cubrid_fetch($result);
이것을 Prepared statement 를 사용하도록 하면 다음과 같은 형식이 됩니다.
$PROJECT_NAME = BoanProject;
$PROJECT_USER = "Securely"
$qry = "select * from olympic where project_name= ? and project_user= ? ";
$req = cubrid_prepare($con, $qry);
$res = cubrid_bind($req, 1, $PROJECT_NAME, "STRING");
$res = cubrid_bind($req, 2, $PROJECT_USER, "STRING");
$result = cubrid_execute($req);
$row = cubrid_fetch($req);
....
if ($req > 0) cubrid_close_request($req);
===========================================================================
