'Web Hacking/bWAPP'에 해당되는 글 24건

해당 취약점은 os의 command를 이용하여 공격하는 방식이다. 취약점 화면을 확인한다.

dns lookup을 실행해주는것 같다. lookup 버튼을 눌러서 확인해 본다.

실행 결과 www.nsa.gov의 dns 정보가 출력된다. lookup 버튼을 누르면 "dnslookup 텍스트박스" 이런식의 명령어가 실행되는 것 같다. 그래서 www.nsa.gov 뒤에 ; ls -al 명령어를 넣어 우회를 시도했다.

시도한 결과 위 그림과 같이 dnslookup 명령어와 함께 ls -al 명령어도 같이 실행되었다.

해당 취약점은 위 PHP 코드 인젝션과 같이 SSI 구문을 넣어서 취약점을 도출해 내는 방식인것 같다. SSI(Server Side Includes)는 서버가 HTML 파일을 사용자에게 보내기 직전에 포함할 수 있는 변수값을 치환하는 것이다. 우선 취약점을 확인한다.

이름을 입력하면 자신의 아이피를 보여주는 것 같다. 직접 입력하여 확인해봤다.

실제로 입력한 이름과 자신의 IP를 알려준다. 여기에 first name에 <!--#exec cmd="ls -al" -->를 입력하고 last name에는 1을 입력하여 출력되는 화면을 확인했다.

입력 결과 ls -al 명령어가 ssi 구문에 의해 실행되었다.

해당 취약점은 php코드를 이용하여 서버의 정보를 알아내는 취약점이다. 우선 어떤식의 문제인지 확인한다.

위와 같이 해당 페이지는 테스트페이지일 뿐이라는 문구와 함께 message 글자를 누를 수 있게 되어있다. 한번 눌러봤다.

위 그림과 같이 주소창에는 ?message=test라는 파라미터 값이 나왔고 화면에는 test라는 글이 나왔다. message라는 파라미터 값에 test를 입력하면 test가 출력되는 방식인 듯 했다. 그래서 message파라미터의 값을 test가 아닌 php 함수를 이용하여 system("ls -al")로 바꿔서 실행했다.

system 함수 사용 결과 위와 같이 system 함수 내에 작성한 ls -al 명령어가 동작하여 출력되었다.

해당 취약점은 블로그에 글을 저장할때 HTML Injection 공격을 하는 취약점이다. 취약점 화면을 보면 아래와 같이 블로그에 글을 올리도록 되어있다.

우선 Hi라는 글을 써서 저장했다.

위와 같이 entry에 Hi라는 글자가 작성되었다. 이전 HTML Injection에서 작성했던 <h1>Success</h1>을 입력하여 저장했다.

이전 문제들과 같이 Success 이미지가 저장되었다.

해당 취약점은 URL을 이용한 HTML Injection이다. 취약점 화면을 보면 아래 그림과 같이 자신의 URL이 나와있다.

사용하는 메소드가 GET 메소드인지 POST 메소드인지 확인하기 위해 패킷을 잡아봤다.

사용하는 메소드가 GET 메소드이다. 그러므로 URL 파라미터 값을 통해서 값을 전달한다. GET 옆에 있는 주소값(/bWAPP/htmli_current_url.php)에 ?<h1>Success</h1>을 작성하여 패킷을 전송했다. 전송하니 화면에 Success 이미지가 출력됬다.

해당 취약점은 HTML의 POST 메소드를 이용한 Injection 취약점이다. 취약점으로 들어가면 아래와 같이 성과 이름을 쓰는 페이지가 나온다.

이름(first name)에 kildong, 성(last name)에 hong을 입력후 Go 버튼을 누르니 아래와 같이 환영한다는 문구가 나온다.

GET과 POST의 차이점은 GET은 URL에 넘어가는 파라미터 값이 보이지만 POST는 보이지 않는다는 점이다. 우선 GET과 같은 방식으로 이름에는 <h1>Success</h1>을, 성에는 <img src="http://비박스 IP/bWAPP/images/bee_1.png">를 입력한다. 입력하면 GET의 결과와 같은 결과가 나온다.

패킷을 잡아서 POST로 가는지 GET으로 가는지 확인해본다.

POST로 전송되는 것을 확인했다.

해당 취약점은 XML Injection을 이용하여 로그인하는 취약점이다. 우선 문제를 살펴본다.

superhero로 로그인하면 되는 문제이다. 우선 '(싱글쿼터)를 입력하여 에러를 확인한다.

xml 관련 에러가 나온다. xml을 이용해야 하는게 맞고, 로그인이기 때문에 and 연산으로 id와 비밀번호를 호출한다고 추측할 수 있다. 이제 참이되는 'or 1=1 or ' 구문을 삽입했다.

구문 삽입 결과 neo로 로그인 되었다.

해당 취약점은 SOAP를 사용하는 웹 서비스의 SQL Injection 취약점이다. 접속하여 Go 버튼을 누르면 We have 100 movie tickets available in our stock.이라는 메시지가 나온다. 100장의 티켓을 가지고 있고 예매가 가능하다는 얘기인 것 같다.

url에 &action 앞에 ' or 1=1#을 입력해본다.

입력 결과 100이라는 숫자가 사라졌다. 또한 urlencoding으로 값이 전송되는 것을 url을 통해 확인했다. 그리고 error가 생긴듯 하다. 이번에는 ' or '1'='1을 입력했다.

입력 결과 100이 다시 출력되었다. ' or length(database())=5 and '1'='1을 입력하여 DB명의 길이가 5글자인 것을 확인했다.

' or length(database())=5 and '1'='1 구문을 변경하여 DB명, 테이블명, 컬럼명, 컬럼 내의 데이터 값을 확인할 수 있다.

해당 취약점은 앞서 했던 SQL Injection - Blind - Boolean-Based와 흡사하다. 차이점은 기존 Boolean-Based에 사용했던 쿼리문에 sleep함수를 추가하여 페이지의 로딩 중인것을 보고 확인한다. 앞서 했던 취약점과 쿼리문은 거의 동일 하기때문에 따로 설명하진 않겠다. ' or 1=1 and sleep(5)#을 대입하여 확인한다.

위 그림과 같이 작업 진행중을 의미하는 아이콘이 계속 돌고있다. 저게 돌면 쿼리문이 참이고, 안돌면 거짓이다. 앞서 boolean-based의 쿼리문에 and sleep(5)를 넣어서 확인하면 DB의 정보를 확인할 수 있다.

해당 취약점은 Blind SQL 인젝션의 boolean based이다. SQL Injection 중에서도 가장 노가다(?)스럽고 하나하나 일일이 값을 넣어가며 확인해야 하기 때문에 굉장히 오래걸린다. 

위와 같이 영화를 검색하는 방식이다. 하지만 DB에 검색하는 영화의 존재 유무만 알려주고 나머지는 알려주지 않는다. 그래서 '(싱글쿼터)를 넣어서 에러를 확인했다.

위와 같이 다른 문장을 넣었을 때와는 다르게 에러가 발생한다. 그래서 참을 만들어주는 SQL문(' or 1=1#)을 넣었다.

참을 넣으니 DB에 정보가 있다고 나온다. 이런식으로 참인 SQL 문을 넣으면 참인 메시지가, 거짓을 넣으면 거짓이라는 메시지나 에러 메시지가 출력된다. 컬럼 갯수를 확인 하기 위해 ' union select 1,2,3,4,5,6,7#을 넣었다. 처음 1부터 해서 7까지 늘리면 7일때 위와 같이 참 메시지가 나온다.

마찬가지로 DB명의 길이를 확인하기 위해 ' or 1=1 and length(databases())=5#을 넣었다.

역시 참 메시지가 나오는 것으로 보아 DB 명은 5글자이다. 그리고 ' or 1=1 and substring(database(),1,1)='b'#을 넣어 DB 명의 첫번째 글자가 b라는 것도 확인했다. 또는 ' or 1=1 and ascii(substring(database(),1,1))=98#을 넣어 b라는 것을 확인할 수 있다. 앞에 문장과 뒤의 문장의 차이는 asii 함수 이용의 차이이다. 값은 일치한다.

다음은 ' or 1=1 and length((select table_name from information_schema.tables where table_type='base table' and table_schema='bWAPP' limit 0,1))=4#을 입력하여 테이블명 길이를 확인한다.

다음은 ' or 1=1 and ascii(substring((select table_name from information_schema.tables where table_type='base table' and table_schema='bWAPP' limit 0,1),1,1)) > 100# 를 입력하여 테이블 명을 추측한다. ascii 함수를 사용하여 범위를 한정하여 추측하면 첫번째 테이블 명이 b로 시작하게 된다. 이렇게 계속 진행하면 네번째 테이블이 users라는 것을 알게 된다.

users라는 테이블명을 알게 되었다면 해당 테이블의 컬럼명의 길이를 파악하기 위해 ' or 1=1 and length((select column_name from information_schema.columns where table_name='users' limit 0,1))=2#를 입력하여 2글자라는 것을 파악했다.

이제 컬럼명을 추측하기 위해 ' or 1=1 and substring((select column_name from information_schema.columns where table_name='users' limit 0,1),1,1)='i'#를 넣어 i로 시작하는 2글자 인 것을 알게 되었다. 계속 추측하면 두번째 컬럼은 login 이라는 사실도 알 수 있다.

이제 login 컬럼에 있는 내용을 파악하기 위해 ' or 1=1 and length((select login from users limit 1,1))=3#을 넣어 컬럼 내용의 길이를 파악했다. 3글자다. 그리고 ' or 1=1 and substring((select login from users limit 1,1),1,1)='b'#을 입력하여 첫번째 글자가 b인 것도 확인했다.  계속 해보면 login 컬럼의 첫번째 내용은 bee다.

이제 두번째 컬럼을 알아보기 위해 ' or 1=1 and length((select column_name from information_schema.columns where table_name='users' limit 2,1))=8#을 입력했다. 두번째 컬럼명은 8글자이다. 컬럼명을 파악하기 위해  ' or 1=1 and substring((select column_name from information_schema.columns where table_name='users' limit 2,1),1,1)='p'#를 넣어 확인하니 첫번째 글자가 p인 것을 확인했다. 계속 찾아보니 password였다. password 컬럼은 비밀번호 원문이 아닌 해시 값이라는 추측이 가능해진다. 하지만 암호화 되어 있어 40글자를 일일이 하기에는 시간 소모가 너무 심하다. 우선 md5를 사용하였는지 확인하기 위해 ' or 1=1 and md5("bug")=(select password from users where login='bee')#를 넣은 결과 거짓 메시지가 나온다. 다시 sha-1인지 확인하기 위해 ' or 1=1 and sha1("bug")=(select password from users where login='bee')#를 넣으니 참이 나온다. 그래서 sha-1함수를 사용하는 것을 알 수 있다.

아래 표는 위에서 사용한 DB 쿼리문을 표로 정리해 놓았다.