제품 | 기술 정보 | 사용 지침서 | FAQ | 다운로드 | 연락처 | KR

제품 정보

소개

SQL Power Injector 는 penetration test시 웹사이트에 대한 SQL injectioin을 탐지해 'exploit'하는 것을돕기 위해 .Net 1.1기반으로 개발된 프로그램입니다.

현재는 SQL Server, Oracle, MySQL, Sybase/Adaptive Server, DB2 compliant 에서 쓸 수 있지만 인라인 인젝션(normal mode)을 이용하면 어떤 DBMS에도 사용 가능합니다. Normal mode는 기본적으로 매개변수에 입력해 서버로 보내는 SQL 명령어이니 말입니다.

인라인 SQL injection의 양상이 그 자체로 효과적이라면 인젝션의 멀티스레드 자동화 기능은 주요한 강점이 될 것입니다. 지루하고 시간만 잡아먹는 쿼리들을 자동화 할 수 있을 뿐 아니라 필요한 사항만을 얻을 수 있게끔 쿼리를 수정할 수도 있습니다. SQL injection 취약점을 공격하는 다른 여러가지 방법들은 결과가 웹페이지에 보여질 때 훨씬 빠르고 멋져보이지만 이 방법은 blind SQL injection에서 단연 효과적입니다. (한 예로 HTML 테이블에서 union select하면 에러가 500개가 생깁니다.)

두가지 방법으로 자동화를 할 수 있습니다 : 예상 결과들을 서로 비교하거나 시간 지연을 이용하는 방법입니다. 첫번째 방법은 일반적으로 에러나 긍정적 조건과 부정적 조건 사이의 차이를 대조 확인하는 것입니다. 두번째 방법은 시간지연이 서버로 보내졌을 때 어플리케이션의 매개변수와 일치하면 긍정 신호를 보내는 것입니다.

가장 중점을 둔 부분은 브라우저를 사용하지 않고도 SQL injection 취약점을 찾아내고 공격하는 가장 쉬운 방법을 찾는 것이었습니다. 그것이 바로 인젝선 결과를 보여주는 통합 브라우저가 있는 이유인데 연관된 어떤 표준 SQL에러라도 페이지의 나머지 부분 없이 매개변수화 하여 보여줍니다. 물론 서버를 가능한 수다스럽게(응답을 많이 하도록)만들기 위해 매개변수화 하는 방법은 이것 말고도 있습니다.

또 다른 주요한 부분은 GET method로 하건 POST method로 하건 SQL injection을 테스트 하고자 하는 웹페이지에서 모든 매개변수를 얻어내는 힘입니다. 데이터를 가로채기 위해 어플리케이션이나 프록시를 이것저것 사용할 필요 없이 모든 것이 자동화 되어 있습니다! 뿐만 아니라 이제는 Firefox plugin에서 session context(매개변수와 쿠키들)를 포함한 현재 웹페이지의 모든 정보가 들어있는 SQL Power Injector를 불러올 수도 있습니다.

사용성을 높이기 위해 많은 노력을 기울였음에도 불구하고 프로그램을 처음 사용하게 되면 쉽지 않은 부분이 있을수도 있을 것 입니다. 그러나 몇가지 사항만 이해하고 나면 꽤 사용하기 쉬울 것이라고 자신있게 말할 수 있습니다. 초보자들의 기본적인 사항에 대한 이해를 돕기 위해 Tutorial을 만들었는데 이를 통해 고급 SQL injection 기술에 대해 배울수도 있을 것입니다. FAQ에서는 몇몇 유용한 트릭들도 볼 수 있을 것이며 help file(chm) version 1.2에는 많은 유용한 SQL injection 정보들을 담고 있습니다.

내가 직접 pen testing과 SQL injection을 하던 방식으로 이 프로그램을 디자인 했습니다. 여러 실제 웹사이트를 통해 성공적으로 테스트를 거쳤고(물론 합법적으로) 무언가 미흡한 점이 보일 때 마다 계속해서 추가하고 있습니다. 물론 지금은 보안 업계에서 공식적으로 사용가능한 만큼 좀 더 엄격한 기준을 가지고 새로운 버전이 나올 때 추가하도록 해야 할 것입니다. 이 작업은 이미 진행중이고 많은 새로운 기능들이 시간을 가지고 추가 될 것입니다.

마지막으로, 이 프로그램은 무료로 제공될 것이며 보안 전문가들의 보안 평가시 또는 사용하는 기술 지식을 발전하고자 할 때 도움이 되기를 바랍니다.

위로

주의사항

이 프로그램으로 SQL injection취약점을 찾지 못할 수도 있지만 하나를 찾으면 적당한 syntax를 찾아낼 수 있습니다. 가장 주요한 강점은 좀 더 쉽게 취약점을 찾아내는 것이고 일단 찾아내면 그것을 자동화 함으로써 blind 기술을 사용한 인젝션만 가능한 경우에 매번 인젝션을 할 필요가 없게 하는 것입니다.

이미 많은 프로그램들이 존재하기 때문에 데이터베이스 추출 프로그램을 만들고자 의도하지는 않았습니다. 대부분의 추출된 자료들은 유의미하지 않고 데이터를 추출하는데 시간이 많이 소요되기 때문에 시간이 낭비 되기 쉽상입니다. 데이터를 정제해서 꼭 필요한 것만을 얻는 것이 휠씬 현명한 선택입니다.

마지막으로, HTML 형태로 결과를 얻기위해 미니 브라우저를 추가했는데 이것은 전문적인 브라우저의 모든 기능을 포함하고 있지는 않습니다. Internet Explorer나 Mozilla 등의 여러 브라우저들은 정말로 복잡한 소프트웨어이고 그 모든 기능을 이 프로그램에서 구현하는 것은 거의 불가능에 가깝기 때문입니다. 그래서 비록 비슷한 형태와 느낌이더라도 이 프로그램을 일반적인 브라우저와 동일하게 사용하지는 못할 것입니다.

위로

기능


위로

특징

솔직히 말해 다른 Tool들의 모든 세부사항들을 확인하지는 않았습니다. 단지 말하고자 하는 것은 그것들도 좋은 Tool이겠지만 SQL injections을 할 때 필요한 중요한 무언가가 항상 빠져 있었다는 것입니다.

어떤 프로그램은 가끔 잘못된 Positive결과를 도출하는SQL injection을 찾아주기도 합니다. 어떤 것들은 그냥 데이터베이스에서 데이터를 그대로 뽑아오기도 합니다. 그 중 몇몇은 좀 더 나아서 데이터베이스 목록을 뽑아냈을 때 필요한 것인지를 검토해 볼 수 있습니다. 아니면 현재 DB 사용자들이 하는 것 처럼 특정한 하드코드 데이터를 요청할 수도 있습니다.

하지만 제가 아는 한 그 누구도 원하는 것을 구체적으로 특정해서 요구할 능력은 갖고 있지 못합니다. 그런 능력을 갖추려면 대가가 필요합니다. SQL syntax를 알아야 하기 때문입니다. 하지만 한번 원리를 이해하게 되면 그렇게 많은 syntax가 필요하진 않다고 장담합니다.

또한 시간지연 특성을 적용한 프로그램을 본 기억도 없습니다. 시간지연 기술을 적용하지 않고 SQL injection 취약성을 exploit하기는 거의 불가능합니다. 수동으로하면 정말 지루하고 시간이 많이 걸려서 몇시간에 걸쳐 명령어를 복사, 붙여넣기 하다가 포기해 버리기 마련이지요.

또한 시간을 절약하는데 가장 중요한 멀티스레드를 사용한 사례도 보지 못했습니다. Blind SQL injection에서 25%의 시간절약 효과가 있는ASCII 문자 프리셋 기능도 마찬가지입니다.

SQL Power Injector를 배포하기 전해 이러한 방식들을 사용해 프로그램을 만들고 배포한 이가 있다면 미리 사과의 말씀을 드리는 바입니다. 연락을 주시면 해당 부분을 수정하도록 하겠습니다.

차이점 요약:

위로

스크린샷

이 프로그램에서 사용된 두 가지 기술을 보여주는 두개의 screenshot이 있습니다 : Normal 과 Blind.

SPInj Normal Technique
Screen 1: SQL Power injector with Normal technique

SPInj Blind Technique
Screen 2: SQL Power injector with Blind technique

위로

통계 자료

어떠한 과학적인 방법을 사용한 것이 아니기에 이 통계치를 과학적인 사실로 받아들이기 보다 당신의 기대치를 가늠해 볼 수 있는 일반적인 것으로 생각해 주시길 바랍니다. 특히 누구도 인터넷을 통한 유출을 통제하지 않기에 어떠한 의미있는 과학적인 데이터를 제공하도록 압박을 받을 것 같습니다. 또한, 이 수치의 목적은 당신이 기대할 수 있는 근사치를 보여주는 데 있기에 진정한 통계학적인 표본을 갖기에 충분한 양의 테스트를 거치지는 않았습니다.(각 스레드 당 10회)

게다가, 우리가 찾는 데이터의 크기에 따라 달라질 것입니다. 때로 스레드 수가 많은 것보다 적은 것이 더 효과적일 때도 있습니다. 사실, 변수의 길이로 스레드의 수를 나눌 수 있다면 걸리는 시간이 최적화 될 것입니다. 길이가 24라면 3,4,6,8이 다른 수 보다 더욱 빠를 것입니다. 모든 스레드 사이의 더 큰 시간 차는 어림잡아 1에서 2입니다. 여기에서 보듯이 크다고 항상 좋은 것은 아닙니다. 아래의 통계치에서 몇가지 예를 볼 수 있을 겁니다.

스레드 개수를 50까지 올릴수는 있지만 10개 이상이 되면 에러가 발생하고 점점 더 느려지기 시작합니다. 다시 말하지만 스레드 수가 많다고 더 좋은 것은 아닙니다. 스레드 수가 많으면 웹어플리케이션과 충돌이 생길 가능성도 높아진다는 점을 경고해 두어야 겠습니다.(웹 서버나 데이터베이스)

자신의 웹 서버를 테스트 해 볼수 있게 허락해 준 Nathaniel Felsen에게 감사하다는 말을 전합니다.

테스트 시 사용된 컴퓨터 사양 :

positive 응답 옵션으로 실행

6 문자
스레드 수
전체
최적화시
소요시간
리퀘스트
소요시간
리퀘스트
1
~36 s 0 ms
61
~26 s 193 ms
43
2
~20 s 314 ms
61
~15 s 561 ms
43
3
~20 s 883 ms
61
~15 s 755 ms
43
4
~22 s 705 ms
70
~17 s 540 ms
49
5
~22 s 14 ms
61
~17 s 171 ms
43
6
~19 s 878 ms
61
~15 s 227 ms
43

11 문자
스레드 수
전체
최적화시
소요시간
리퀘스트
소요시간
리퀘스트
1
~1 m 1 s 910 ms
106
~47 s 840 ms
80
2
~35 s 492 ms
106
~26 s 350 ms
80
3
~35 s 157 ms
106
~28 s 220 ms
80
4
~33 s 638 ms
106
~26 s 607 ms
80
5
~35 s 280 ms
106
~26 s 403 ms
80
6
~32 s 426 ms
106
~26 s 983 ms
80
7
~35 s 162 ms
115
~28 s 858 ms
86
8
~40 s 590 ms
106
~28 s 972 ms
80

23 문
스레드 수
전체
최적화시
소요시간
리퀘스트
소요시간
리퀘스트
1
~2 m 4 s 37 ms
214
~1 m 45 s 905 ms
175
2
~1 m 6 s 57 ms
214
~57 s 552 ms
175
3
~1 m 6 s 418 ms
214
~56 s 714 ms
175
4
~1 m 3 s 759 ms
214
~54 s 575 ms
175
5
~1 m 3 s 57 ms
214
~53 s 743 ms
175
6
~1 m 2 s 995 ms
214
~53 s 750 ms
175
7
~1 m 7 s 870 ms
214
~59 s 178 ms
175
8
~1 m 3 s 285 ms
214
~52 s 938 ms
175

187 문자
스레드 수
전체
최적화시
소요시간
리퀘스트
소요시간
리퀘스트
1
~16 m 42 s 991 ms
1692
~13 m 16 s 31 ms
1303
2
~8 m 32 s 604 ms
1692
~6 m 34 s 562 ms
1303
3
~8 m 24 s 751 ms
1692
~6 m 41 s 286 ms
1303
4
~8 m 9 s 943 ms
1692
~6 m 25 s 358 ms
1303
5
~8 m 10 s 97 ms
1692
~6 m 35 s 30 ms
1303
6
~8 m 12 s 256 ms
1692
~6 m 24 s 839 ms
1303
7
~8 m 14 s 811 ms
1692
~6 m 25 s 531 ms
1303
8
~8 m 13 s 168 ms
1692
~6 m 28 s 909 ms
1303

3초 타임 딜레이 시켰을 경우

6 문자
스레스 수
전체
최적화시
소요시간
리퀘스트
소요시간
리퀘스트
1
~2 m 3 s 337 ms
62
~1 m 40 s 941 ms
44
2
~1 m 17 s 114 ms
62
~1 m 7 s 308 ms
44
3
~1 m 16 s 273 ms
62
~1 m 4 s 770 ms
44
4
~1 m 22 s 970 ms
71
~1 m 8 s 701 ms
50
5
~1 m 17 s 349 ms
62
~1 m 4 s 448 ms
44
6
~1 m 13 s 998 ms
62
~1 m 1 s 981 ms
44

11 문자
스레드 수
전체
최적화시
소요시간
리퀘스트
소요시간
리퀘스트
1
~3 m 27 s 825 ms
107
~2 m 42 s 829 ms
80
2
~1 m 54 s 687 ms
107
~1 m 36 s 265 ms
80
3
~1 m 56 s 737 ms
107
~1 m 32 s 425 ms
80
4
~1 m 51 s 883 ms
107
~1 m 29 s 994 ms
80
5
~2 m 4 s 263 ms
107
~1 m 38 s 55 ms
80
6
~1 m 54 s 239 ms
107
~1 m 38 s 112 ms
80
7
~2 m 2 s 25 ms
116
~1 m 41 s 341 ms
80
8
~2 m 19 s 62 ms
107
~1 m 57 s 104 ms
80

23 문자
스레드 수
전체
최적화시
소요시간
리퀘스트
소요시간
리퀘스트
1
~7 m 4 s 531 ms
215
~6 m 11 s 70 ms
176
2
~3 m 42 s 679 ms
215
~3 m 31 s 982 ms
176
3
~3 m 41 s 82 ms
215
~3 m 23 s 911 ms
176
4
~3 m 41 s 791 ms
215
~3 m 22 s 364 ms
176
5
~3 m 43 s 176 ms
215
~3 m 17 s 817 ms
176
6
~3 m 38 s 604 ms
215
~3 m 22 s 348 ms
176
7
~3 m 58 s 906 ms
215
~3 m 41 s 586 ms
176
8
~3 m 38 s 255 ms
215
~3 m 13 s 52 ms
176

187 문자
스레드 수
전체
최적화 시
소요시간
리퀘스트
소요시간
리퀘스트
1
~59 m 19 s 88 ms
1692
~44 m 2 s 421 ms
1296
2
~30 m 50 s 515 ms
1692
~22 m 36 s 765 ms
1296
3
~30 m 27 s 572 ms
1692
~22 m 43 s 10 ms
1296
4
~30 m 10 s 437 ms
1692
~21 m 56 s 114 ms
1296
5
~29 m 48 s 328 ms
1692
~ 31 m 57 s 703 ms
1296
6
~29 m 41 s 322 ms
1692
~22 m 7 s 432 ms
1296
7
~29 m 26 s 499 ms
1693
~22 m 484 ms
1296
8
~30 m 17 s 641 ms
1692
~22 m 17 s 234 ms
1296

위로

Copyright © 2006-2014 Francois Larouche