WebGoat ) SQL Injection

 

 

 

1. SQL Injection with WebGoat (100 pts)

- Run WebGoat developer version.
A) Solve the problem ([Injection Flaws] - [LAB: SQL Injection] - [Stage 1: String SQL Injection]). (20 pts)

Stage 1. 의 string SQL injection 문제이다. 입력할 수 있는 공간을 보면 Password 란에 user 의 input 이 들어갈 수 있는걸 알 수 있다.

문제의 명시 사항은 SQL injection 을 이용해 권한을 bypass 하여, Neville 의 계정에 올바른 password 없이 로그인 하는 것이다. 또한 관리자로서의 기능을 확인하는 것이다.

일반 사용자에서 아무런 password 를 입력하여 login 버튼을 누르면 Login Error 가 발생한다. 당연하다 password 를 모르고, 아무거나 입력했으니까.

 

그렇다면 이 password 란에 ‘==’’or’ 를 집어넣고 Login 을 한다.

그렇다면 로그인에 성공한 것을 볼 수 있다.

--문제를 이미 푼 뒤여서 이 이미지는 강의 영상을 캡쳐 했습니다.---

이 처럼 관리자 계정에 접근 하여 관리자의 기능들을 모두 사용할 수 있는 것으로 보여진다.

 

문제 푸는데 성공했다.  그렇다면 이러한 string injection 이 어떻게 통하게 된 건지. 어떤 부분이 취약했던 건지 알아보자.

우선 ‘=’’or’ 이 무엇일까 ?

WebGoat 의 js 파일을 확인해볼 필요가 있다. Java source 의 Login.jsp 의 소스를 확인해보면 login 을 할때 sql query 를 만드는 문장이 있다.

WebGoat Developer Version 의 Java 코드이다.

다음과 같은 문장이다. Userid 는 스크롤을 통해 정해지고 password 는 사용자가 입력하는 password 가 그대로 들어가게 된다. 따라서 우리가 입력한 ‘=’’or’ 는 다음의 SQL 구문 처럼 NULL or NULL=NULL 이 된다. 따라서 항상 TRUE 값을 가지게 되는 것이다.

 

 

 

SQL QUERY

---

위의 query 를 짚고 넘어간다. Sql 문장에는 DDL(Data Definition Language), DML(Data Manipulation Language), DCL(Data Control Language) 가 있다. 그 중에서 js 안에 포함 되어 user 에게 직접적으로 사용되는 문장은 대부분 DML 이다. DML 은 데이터의 삽입, 수정, 삭제 의 기능들을 담당한다.

위의 sql query 는 SELECT * FROM employee where userid = ‘’ and password ‘’ 이다.

Select 는 데이터를 데이터베이스로부터 가져와서 사용자에게 보여주는 역할을 한다.

‘ * ’ 는 모든 속성의 데이터를 가져온다는 것을 의미하고 From 은 데이터를 가져올 스키마를 지정한다.

Where 은 속성의 특정 값을 가져와 사용자에게 보여줄 지 결정하는데,데이터베이스에 존재하는 id 와 password 가 그 대표적인 예 이다.

---

 

이와 같은 형태로 sql query 에 완성이 되는데 -‘’or’’=’’ – 기존의 sql 문장에 있던 작은 따옴표와 함께 완성이 되어 Null or Null=Null  이 되는 것이다. Null 은 false 인데 , null=null 은 항상 True 가 된다. 따라서 ‘’or’’=’’ 는 항상 참이 되는 문장인 것이다. 따라서 password 에 true 가 전달 되면서 admin 계정에 access 할 수 있었던 것이다.

위에서 본 것 처럼 사용자가 입력하는 string 이 그대로 sql query 에 들어가게 된다면 password 에 true 값을 전달할 수 있게 된다. 그렇다면 인증이 뚫리게 되는 취약점을 발생시키는 것이다.

그렇다면 user input 을 그대로 전달하지 않는다면 취약점이 발생하지 않는 것이 아닌가 ? 맞다. 단순한 true 값을 전달하는 그것을 막을 수 있는 방법이 다음 문제에서 등장한다.

B) Solve the problem ([Injection Flaws] - [LAB: SQL Injection] - [Stage 2: Parameterized Query #1]). (20 p

문제의 명시 사항은 block sql injection using parameterized query, verify that the attack is no longer effective

앞서 말한 것처럼 stage 2 의 문제는 stage 1 의 string injection 을 막는 것 이다. 또한 취약점이 실제로 보완이 되었는지 또한 확인한다.

주목해야할 점은 using parameterized query매개변수로 된 쿼리를 이용하여 injection 을 막으라는 것 이다. 생각해보면 위에서 확인한 sql 문장의 경우 user 의 input 을 그대로 사용했다. 그렇다면 매개변수로 된 query 가 안전하다는 말이 되겠다.

이 취약점은 query 를 처리하는 java 파일에 존재한다. Login 과 관련 된 login .jsp 파일을 찾는다.

Login java 파일의 login method 가 보인다. 들어가보면 우리가 로그인 입력 시에 사용 한 query 문이 보인다.

앞서 말한 것 처럼 이 query 문장에서는 사용자의 입력 ( string) 을 그대로 집어 넣는다. 그렇기 때문에 저 부분을 매개변수 화 하여 값을 전달하는 방법으로 접근 해야 할 것 이다.

 위에서 분석해 본 query 를 조금 변경한다. Where 절의 userid 와 password 는 인자를 그대로 전달하는 방식 이였는데, ?, ? 로 변경을 했다. 이는 객체의 함수를 이용하여 그에게 인자를 전달하려는 방식이다.

그렇게 하기 위해서 기존의 statement 객체를 PreparedStatement 객체로 변경해준다.

 

그 후에 인자를 전달해주는 함수를 사용한다. 1,2 는 ‘ ? ’ 로 지정 한 매개변수의 위치를 인덱스로 표현 한 것 이다.

 

ExecuteQuery 문을 사용하여 데이터베이스와의 통신을 한다.

 

바뀐 자바 소스를 볼 수 있다. 저장을 한 후에 다시 실행해보도록 한다.

 

‘or’’=’ 를 입력했더니 로그인 실패가 되는 것을 알 수 있다.

조금 전 까지는 string 을 이용한 injection 이 성공했지만 지금은 login failed 가 발생 한 것을 볼 수 있다. Stage2 또한 성공했다.

 

 

Statement and Prepared Statement

---

그렇다면 Statement 와 Prepared Statement 는 무엇일까? 한번 알아보도록 한다.

먼저 Statement를 알 필요가 있다.

그 형태는 다음과 같다.

String name= “ 홍길동”;

String memo =“ test memo, hong’s notepad”;

String priority = “1”;

String sql = String.format(“insert into tblMemo values(memoSeq.nextval,’%s’,’%s’,default,%s)”, name, memo, priority);

보이는 것과 같이 일정 변수들을 그대로 sql query 에 삽입하여 query 문을 만드는 것을 볼 수 있다. Injection 에 취약할 수 있는 특수문자에 대한 어떠한 정의 없이 string 을 그대로 넘긴다. Stage1,2 에서 볼 수 있었던 ‘’or’’=’’ 와 같은 공격이 먹혀들 수 있는 문장이다.

 

그렇다면 preared Statement 는 어떨까 ? 위에서 본 것처럼 매개변수를 사용한다.

 

보이는것과 같이 pstat 객체를 이용하여 sql 문장을 인덱스에 따라 채우고 있다.

java.sql.PreparedStatement 는 java.sql.Statement와 동일한 기능을 제공한다. 차이점 이 있다면PreparedStratement는 SQL 쿼리의 틀을 미리 생성해 놓고 값을 나중에 지정한다는 것이다.

출처 : https://sas-study.tistory.com/160

---

C) Solve the problem ([Injection Flaws] - [LAB: SQL Injection] - [Stage 3: Numeric SQL Injection]). (20 pts)

문제 C 의 경우는 larry 로 로그인하여 sql injection 을 이용해 Neville 의 프로필을 보는 것이다. 문제가 생겼다. 강의에서 본 대로라면 Larry Stooge 의 password 는 ‘Larry ‘가 맞을텐데 로그인이 안 된다. 새로운 방법으로 injection 해야 할 것 같다.

주석을 이용하는 방법으로 도전 해보도록 한다.

Query 의 password 가 들어갈 자리에 ‘’or1=1 – 이 들어가도록 하겠다. Sql 문법에서는 ‘- -‘ 는 이후가 주석처리 된다.

실패했다. 안될이유가 없을 것이다. 자바 파일안의 로그인 query 는 위에서 본 것 처러 select * from employee where userid ? and password ? ; 가 맞을테니까. 이클립스에서 system 출력으로 서버에 전달 된 query를 확인해보자.

 - 가 한개밖에 들어가지 않았다. 아무래도 글자수 제한이 있는 것 같다. 글자수 제한을 없애 보도록 하겠다

예상이 맞았다. Maxlegth 가 8로 되어 있었고, 내가 입력한 ‘’or1=1—는 9 글자였다. 앞으로도 injection 이 수월 했으면 좋겠다. Maxlength 를 없애도록 하겠다.

이런 노력에도 로그인이 되지 않았습니다. 오류 구문은 java.sql.SQLException 으로 sql 구문에 문제가 있다는 것이 였습니다. Sql 구문을 바꾸고, 설정을 바꿔도 해결이 되지 않아 다른 파일에 있던 login 함수를 그대로 복사 붙여 넣기 하여 로그인 문제를 해결 했습니다.

 

Larry 의 프로필로 로그인이 된 것을 확인 할 수 있다.

이제 burpsuite 를 켜서 ViewProfile 요청을 보낼 때 조작을 해보도록 하겠다.

POST method 로 ViewProfile 을 요청한 것을 볼 수 있는데. 이때 employee_id 가 101 이고, 이는 larry 의 employee_id 이다.

Java 파일을 확인해보면 101 이 첫번째 employee_id value 임을 알 수 있다. Select query 의 경우 가장 상위에 나타나는 것만 반영 되기 때문에, 이처럼 마지막 부분이 필요한 상황에서는 Order by 구문을 이용하여 역순으로 뒤집어주어야 한다.

employee_id 에 해당하는 body 값을  101 or 1=1 order by employee_id desc 로 바꿔주고 요청을 전송한다.

보이는 것 처럼 Larry 의 아이디로 로그인 한 상태지만, ViewProfile에서 Neville 의 프로필을 보는 것처럼 성공한 모습을 볼 수 있다.

 

성공한 것을 볼 수 있다. 

 

Order by ? desc ?

---

SQL 의 Order by 절은 SELECT 문으로 검색 된 데이터를 오름차순 (ASC) 나 내림차순 (DESC) 로 정렬 시킬 때 사용 한다. Default 값은 ASC 로써 생략 가능하며 Order by 절에 선택 된 컬럼이 여러 개일 경우 앞에 정의 된 컬럼을 기준으로 먼저 정렬한다.

---

D) Solve the problem ([Injection Flaws] - [LAB: SQL Injection] - [Stage 4: Parameterized Query #2]). (20 pts)

Stage 4 는 stage 3 의 문제점을 해결하기 위해 소스코드를 수정하는 문제이다.

우리는 eclipse 를 통해서 소스코드를 확인하고 수정할 수 있다. ViewProfile 에서 적절하게 injection 을 막아보도록 한다. Eclipse 로 ViewProfie 에서 submit 에 관한 정보를 찾는다.

Submit 을 누르면 SQLinjection.LISTSTAFF_ACTION 이 실행 된다.

그 요청을 처리하는 java 파일이  다음과 같은 ViewProfile 파일 이다.

 

이 파일 안의 취약한 함수는 Stage2 와 같은 Statement 객체를 사용한select sql 구문이다. Stage2와 마찬가지로 PreparedStatement 객체를 사용하는 매개변수를 이용한 구문으로 바꾸어준다.

취약한 query 를 PreparedStatement 를 사용하여 보완 한 모습이다. 저장하여 서버에 변경 된 코드를 적용시킨 후에 다시 stage 3 에서 했던 것 처럼 burp suite에서 salary 의 값을 조작해 Neville 의 정보를 조회하도록 해본다.

 

에러가 발생하며 성공한 것을 알 수 있다. 강의에서 했던 것 처럼 An error has occurred 를 Don’t try SQL injection으로 바꿀 수도 있다.

 

 

BurpSuite 작동 안할 때

---

이번 챕터를 진행하면서 이유없이 안되는 경우가 너무나도 많았다. 확인 해본 결과 firefox 가 허락 없이 업데이트 되어서 로컬호스트로 프록시 서버를 지정하지 못했던 것 이였다. Firefox 를 삭제하고, 재 설치 후옵션에서 자동 업데이트 기능을 해제했다.

앞서서 한 모든 실습들이 Statement 객체를 이용하여 발생한 취약점 때문이었다. PreparedStatement 를 사용할 필요가 있다. 실제 서비스에서도 PreparedStatement 를 사용하는지 그렇지 않으면 더 안전한 객체를 사용하는지 알아보도록 해야겠다.

---

 

 

E) Solve the problem ([Injection Flaws] - [Database Backdoors]). (20 pts) - Solve step1 & step2 problem.

E 번 문제의 경우 Database 에 Backdoor를 설치하는 것으로 보인다. Sql 문법에서 TRIGGER 라는 문법이 있는데 특정 테이블에 INSERT,DELETE,UPDATE 같은 DML문이 수행 되었을 때 데이터베이스에서 자동으로 작동하도록 작성된 프로그램 ( 코드 ) 이다. 사용자의 호출이 아니라 데이터베이스에서 자동으로 호출하는 것이다.

 

UserId 에 larry 의 userid 인 101 을 집어 넣었더니 larry 에 관한 정보가 나왔다.

그리고 UserID 에 있는 select 구문이 실행 된다는 것을 보여주는 것 같다.

바로 101; 이후에 query 가 작동하는 것을 볼 수 있다. Update 문장을 통해서 larry 의 정보를 조작했다.

 

Stage1 을 clear 했다. 바로 다음 Stage2 로 넘어오면서 Stage2 에 관한 설명이 나온다. String SQL Injection 을 이용해 백도어를 설치하는 것이다. CREAT 트리거는 “CREAT TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email=’john@hackme.com’ where userid = NEW.userid”

이다. 짚고 넘어갈 필요가 있다

 

CREAT TRIGGER

---

앞서 말한 것 처럼 트리거를 생성하면 지정된 SQL 문이 실행  될 때 다른 SQL 문을 자동으로 수행할 수 있다. 트리거를 생성하는 형식은 다음과 같다.

그렇다면 우리가 WebGoat 에서 작성한 SQL 문을 확인해보자

1)    CREAT

생성하는 명령어이다. 경우에 따라 Table 을 생성할 수도 있지만 이경우는 TRIGGER  를 CREAT 하는 경우이다.

2)    TRIGGER –

CREAT 에 해당하는 인자로 TRIGGER 를 생성하겠다는 명령어이다. 바로 뒤에오는 string 은 trigger 의 이름을 의미한다.

3)    BEFORE

트리거의 조건 영역과 실행 영역이 실행 되는 시점을 지정하며 BEFORE,AFTER,DEFERRED 가 있다.

4)    INSERT

조건 영역과 마찬가지로 INSERT 될 때 작동한다는 의미이다. 인자로는 INSERT ,UPDATE, DELETE 가 있다.

5)    ON –table—

INSERT 바로 뒤에 나온 입자로 어떤 테이블에 해당 구문이 작동하는지 지정하는 위치이다.

6)    FOR EACH ROW

각 행에 해당 TRIGGER 를 적용한다는 의미이다.

7)    BEGIN

실제 작동할 코드가 이 뒤에 나타난다.

8)    UPDATE employee SET email=’john@hackme.com’ where userid = NEW.userid”

TRIGGER 에서 실제 작동 할 코드들이다.

---

이제 실제로 User ID 에 입력을 해보도록 하자.

101; CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='john@hackme.com'WHERE userid = NEW.userid  를 입력 해주었다.

마지막 실습까지 성공한 모습을 볼 수 있다.

 

자료 출처

나의 블로그

https://limkydev.tistory.com/154