영삼넷IT 강국 = 김영삼 블로그에 오신걸 환영합니다.

새삼스럽게 최근의 나온 것은 아니지만, 활용여부에 따라 테크닉에 상당한 도움이 될 것 같아 올려봅니다. 요즘 다시 DBMS 공부해보는데 참 재밌네요.(IMPERVA 문서를 많이 참고했습니다.)

SQL Injection Signatures Evasion
       
1. 이 문서에 대한 요약

URL Request에 arbitrary string(악의적인 문자열)을 삽입시키는 일반적인 형태는 다음과 같이 이루어 집니다. 웹 애플리케이션의 사용자 입력값을 받는 모든 폼, 검색창 형태들이 이에 해당됩니다. 아래의 예처럼 변수의 변수값에 직접적으로 삽입이 이루어진다.

예) 만약에 시스템에 string 필드 값이 존재하지 않는 경우에는 새로운 파라메터에 간단히 추가할 수 있다.(이런 경우 일부 웹 애플리케이션은 이를 차단하거나 무시함)

....$id=43&testparam=malicious code

SQL Injection이 탐지가 되는 경우에 SQL Comment 문자열(/* */)에 대한 signature가 존재하지 않을 때, 이럴 경우 간단히 injection시킬 수 있다.

....$dbid=original’ --

또 다른 테크닉 기법으로는 SQL Injection 취약점이 탐지되고, AND 키워드에 대한 Signature가 존재하지 않을 때 패턴은 다음과 같이 된다.

....$dbid=original’ AND ‘100’=’100’

대부분의 웹 사이트에서 이러한 취약점들을 가지고 있다. 이런 키워드 탐색을 통해서 SQL Injection의 가능성 여부를 알아볼 수 있다.
두번째 단계로 SQL 구문을 통한 공격이 이루어지 질 수 있는데, 아래와 같은 SQL 구문을 통해 필터링여부를 조사하게 된다.

- UNION SELECT
- OR 1=1
- exec sp_  또는 xp_  로 시작되는 스토어 프로시저(확장 스토어 프로시저)
- declare @s out
       
2. 일반적인 회피기법(Common Evasion Techniques)

1) Different Encoding : 다양한 인코딩 방식을 사용한 Evasion 기법
2) White Space 다양성(Diversity) : 일반적으로 SQL Injection 공격을 회피하기 위해 둘 이상의 스페이스 문자를 삽입시키는 경우 White Space에 의해 분리된다. 즉, 여러 개의 스페이스문자가 삽입되더라도 한번의 스페이스로 대체될 필요가 있다.

3) IP Fragmentation 및 TCP Segmentation
몇몇 Product에서는 TCP/IP 프레그먼트에 대한 취약점은 여전히 존재하고 있다.

3. Advanced 회피기법(Advancesd Evasion Techniques)

3.1 OR 1=1 Signature 기법
가장 일반적으로 사용되는 공격, 보통 탐지 Signature는 정규표현식으로 구성되어있다. 그러나 교묘한 방법을 사용하는 다양한 형태의 공격이 가능하다.

   - OR  ‘unusual’ = ‘unusual’

간단한 트릭을 쓰면 다음과 같이 ‘N’ 문자나 ‘+’를 삽입해 보는 경우이다. 이런 방식을 이용하면 간단히 Signature 기반의 탐지 메커니즘을 쉽게 우회할 수 있다. 광범위하고 다양한 정규표현식을 필터링을 하는 제품의 경우에는 이런 공격을 차단할 수 있다.
 
   - OR  ‘Simple’ = N’Simple’
   - OR  ‘Simple’ = ‘Sim’+’ple’
- OR  ‘Simple’  LIKE ‘Sim%’

또는 ‘<’, ‘>’ 를 사용하기도 한다.

  - OR  ‘Simple’ > ‘S’
  - OR  ‘Simple’ < ‘X’
  - OR 2 > 1

IN 또는 BETWEEN 구문을 사용하는 경우도 있다.(MS SQL 구문에서 유효함)

- OR  ‘Simple’  IN (‘Simple’)
- OR  ‘Simple’  BETWEEN ‘R’ AND ‘T’
(후자는 MS SQL에서만 유효하지만, 대부분의 DB에서도 간단하게 수정하는 것이 가능하 것으로 본다)  그러나 OR 키워드 형태로 Signature 했을 경우 발생가능한 오탐(false positive)의 경우도 있다.

  http://site/ordier.asp?ProdID=5&Quantity=4

3.2 White Spaces Evading Signature
  White space(스페이스 문자)가 포함된 공격에서의 Signature에 대한 정확도가 문제가 발생할 가능
  성을 염두에 둘 필요가 있다.
  단순히 ‘UNION SELECT’ 나 ‘EXEC SP_(XP_ )’ 형태의 탐지 패턴은 높은 정확성을 보일 수 있다.
  예를 들면 MS SQL 서버에서는 SQL 키워드 또는 number나 string 사이에 스페이스 문자는 생략될
  수 있어 아주 쉽게 Evasion이 허용될 수 있다.
 
..origText’  OR  ‘Simple’ = ’Simple’ 이 다음처럼 될 수 있다.
..origText’OR’Simple’=’Simple’

그러나 이런 공격은 UNION SELECT Statement 구문에서는 동작하지 않는다. 왜냐하면 두 키워드 사이는 반드시 분리되어야 하기 때문이다. 따라서 스페이스문자 보다는 C 언어의 Comment syntax를 이용하면 evasion이 가능할 수도 있다.(/*  … */ 이런 형태)

select *
from tblProducts   /* List of Prods */
where ProdID = 5

C-Like comment 형태의 공격은 다음과 같다. 실제로 comment 부분을 나타내는 ‘/**/’이 스페이스 문자로 대체된다.

....&ProdID=2  UNION  /**/  SELECT  name ....
....&ProdID=2/**/UNION/**/SELECT/**/name ....
....&origText’/**/OR/**/’Simple’=’Simple’

http://site/login.asp?User=X&Pass=Y

....login.asp?User=X’OR’1’1/* &Pass=Y*/=’1

실제 SQL 쿼리 구성은 다음과 같다
 
  Select * from Users where User=’X’OR’1’/* AND Pass=’*/=’1’

3.3 Evading Any String Pattern
  단독 키워드의 경우에는 false positive가 발생한다. 같은 Comment 형태로 MySQL에서는 다음과
  같은 형태로 공격에 사용될 수 있다.

     ....UN/**/ION/**/SE/**/LECT/**/  ....
 
  MS SQL에서 스토어 프로시저를 실행시키는 EXEC를 아래와 같은 형태로 공격을 할 수 있다.  
  INSERT INTO를 두부분으로 분리하여 Injection 시킨다. 이럴 경우 Signature 메커니즘에서 탐지가
  안된다.
  또한 이와 유사한 공격으로 MS SQL에서는 SP_EXECUTESQL 라는 확장 스토어 프로시저를 사용
  한다. 그러나 새로운 버전에서는 SP_SQLEXEC 프로시저로 이름이 변경되었다. 이들 모두 SQL 쿼
  리를 실행시킬 수 있다. 참고로 Oracle에서는 ‘EXECUTE IMMEDIATE’가 이와 동일한 기능을 수행
  한다.

     ....; EXEC (‘INS’+’ERT INTO....’)

한가지 주목할 점이 MS SQL에서 헥사코드로 인코딩된 스트링이 실행된다는 것이다. 이 방식대로 한다면 ‘SELECT’는 헥사코드 번호 0x73656C656374로 표현이 되고 탐지가 되지 않는다.
또 한가지 다른 예는 MS SQL 서버에서 OPENROWSET 구문과 관련된 것이다. 가장 널리 알려지고 오랜된 이 기법이 아직도 유효하게 사용되는 곳이 많이 존재하고 있고, 대부부의 Signature 기반의 제품들에서는 탐지를 못하는 경우가 발생하고 있다. 그리고 MS SQL 서버에서 SQL 쿼리를 실행시킬 수 있는 Unlisted 스토어 프로시저가 존재하고 있다.
sp_prepare, sp_execute 이 프로시저는 MS SQL 서버 어디에도 나타나지 않는다. 따라서 이들 프로시저를 이용한 공격은 탐지가 안될 가능성이 있다. 다른 DB에도 이와 유사하게 Undocument 프로시저가 있을 수 있다. Undocument 프로시저를 이용한 공격이 현재로서는 충분히 가능성 있어 보인다.

4. 결론

1) 모든 SQL 구문에 사용되는 문자열에 대한 탐지가 필요한데 이때 약간의 인공지능식 검색이 필요할 듯 싶다.(검색 조건의 AND와 OR 조건에 따른 오탐의 여부가 많은 것이 단점이다.)
(INSERT, INTO, UNION, SELECT, DELETE, UPDATE, CREATE, FROM, WHERE, OR, AND, LIKE, SQL, ROWSET, OPEN, BEGIN, END, DECLARE)

2) 모든 스토어 프로시저의 탐지 및 차단(실제 서비스에서는 프로시저를 써야하는 곳이 많아서 이부분은 적극적인 권장사항은 아니지만 가급적 최소화하는데 목적을 두고 싶다)
(EXEC, SP_, XP_ )

3) 모든 메타문자 차단
  (;  --  +  ‘  (  )  =  >  <  @  *)