16. BeeBox와 인증처리미흡 취약점

BeeBox

BeeBox는 자동으로 취약점을 생성하여 이를 실습할 수 있는 환경을 마련해주는 운영제체로, 리눅스 기반으로 하고 있다.

업데이트가 끊긴지는 오래지만, 여기 있는 취약점들만 풀 수 있다면 웹 해킹 대비에는 충분히 문제가 없다.

VMware환경으로 연 BeeBox이다.

로컬 주소로 진입하면 자동으로 웹 사이트가 생성된 것을 확인할 수 있다.

gm 페이지를 하나 만들어준다.

미리 준비해준 .zip파일을 복사한다.

압축을 풀고 로컬 주소 밑의 gm 폴더로 접속하면, 뭔가 오류가 어마어마하게 나와있는 것을 확인할 수 있다.

이건 mysql과 뭔가 연동문제가 생긴 것으로, 따로 DB지정을 하지 않았기에 그냥 넘어간다.

압축 푼 파일에 특정 sql을 만들어뒀던 DB안에 넣는다.

그럼 /gm 페이지가 오류가 사라지고 페이지가 나온 것을 확인할 수 있다.

 

 

인증처리미흡 취약점

인증이 필요한 페이지, 관리자 페이지 등..

인증 처리 및 세션 처리가 로직 상 잘못 구현되어 접근이 가능한 취약점.

이게 있다면 주요 정보가 노출되고, 다른 사용자 게시물을 수정/삭제, 정보 수정이 가능하게 되는 위험한 취약점이다.

 

Administarative Portals를 고르고 시작해보자

잠긴 페이지가 하나 나오고, 여기에서 Admin 권한을 획득하라는 것이 주요 목표다.

URL을 확인해보면, PHP 변수로 admin=0이 넘어가는 것을 확인할 수 있다.

즉 저 변수를 직접적으로 수정하면 권한을 뺏을 수 있을 가능성이 높다.

admin=1로 수정하니, 성공했다는 메시지가 출력한 것을 확인할 수 있다.

 

 

난이도를 Medium으로 올려보자

이번에는 URL에 변수를 안주고 쿠키에 변수를 저장한 듯 하다.

쿠키값을 살펴보자.

쿠키 값을 살펴보면, admin값이 0으로 주어지는 것을 확인할 수 있다.

이를 1로 수정한 후, 저장하면

문제가 풀리는 것을 확인할 수 있다.

이는 Burp Suite에서도 확인할 수 있다. 아래의 10번줄에 Cookie값을 확인하면, 아까 편집한 Admin변수가 있는 것을 확인할 수 있다.

Admin 값을 1로 고치고 프록시를 넘기면, 똑같은 성공화면이 나오는 것을 확인할 수 있다.

또한, chrome의 개발자 도구에서도 이를 확인할 수 있다. Application > Storage > Cookies로 접근하면 원하는 값이 있는 것을 확인할 수 있다. 당연하게도, 이 Admin 값을 수정해도 성공화면이 나온다.

 

 

Insecure Login Forms를 선택한 후, 이것을 풀어보자.

이 취약점의 절대적인 목표는, 아이디와 비밀번호를 알아내는 것이다.

개발자 도구로 이 사이트의 HTML 문서를 보면, 대놓고 아이디와 비밀번호가 적혀있는 것을 확인할 수 있다.

즉, 전체 선택을 해도 이게 보였다는 뜻

성공적으로 로그인이 된 것을 확인할 수 있다.

 

 

난이도를 올려서 Medium을 풀어보자

이번에는 대놓고 아이디와 비밀번호를 적어두지 않았다.

HTML에서 요소를 확인해보자.

제공하는 HTML 문서에서 제출하는 버튼에 이상한 함수 하나가 물려있다.

이 함수가 정의를 제공하고 있는지 확인해보자

다행히도 HTML 헤드 안에 함수 정의가 되어 있다.

코드를 분석하면 비밀번호는 secret인데, 이 secret은 처음 지정된 문자열 bWAPP에서 정해진 위치의 문자를 가져와서 조합하는 형태로 되어 있다. 일종의 카이사르 암호인 점.

이걸 하나하나 찾아도 되지만, 콘솔 기능으로 쉽게 알아낼 수 있다.

비밀번호는 hulk smash!였다.

로그인을 시도해보자.

성공적으로 로그인이 된 모습을 확인할 수 있다.

 

 

난이도를 한단계 더 높여 high 난이도를 도전해보자

이번에는 그 어떠한 정보또한 제공하지 않고 있다.

하나 알 수 있는 점은, 아이디와 비밀번호를 form 형태로 받아,

로그인 할 때 /bWAPP/ba_insecure_login_3.php라는 곳을 확인하고 있다는 점이다.

즉, 이 로그인 php 사이트 안에 계정 정보를 같이 담아두고 있다는 뜻.

cewl 도구는 특정 주소의 저장소를 정해준 깊이까지 크롤링을 하는 도구로, 무차별대입 공격에 주로 사용하는 도구다.

방금 저 도메인 주소에서 /bWAPP/ba_insecure_login_3.php라는 곳을 참고하고 있으므로, 이 도구를 사용하여 내용을 전부 가져와보면, 정체는 모르겠지만 사용하고 있는 단어 리스트가 전부 있는 것을 확인할 수 있다.

이 단어들의 출처를 생각했을 때, 아이디, 혹은 비밀번호일 가능성을 열어두고 무차별 대입을 해보자.

burp suite의 Intruder는 원하는 곳의 정보를 변경하면서 반복적으로 전송할 수 있는 기능을 지원한다.

방금 얻은 wordlist로 프록시를 Intercept 했을 때 얻은 HTML문서에 집어넣어 동작시켜보자.

공격 종류는 Cluster bomb으로, 변경하는 부분은 login과 password 부분으로 두고 설정하고,

Payload set 1번은 아이디, Payload set 2번은 비밀번호일 것이다. 각각 wordlist.txt 파일을 물려준다.

이렇게되면 아이디/비밀번호로 wordlist 텍스트 파일에 있는 모든 단어를 한번 씩 검사 할 것이다.

아이디/비밀번호 설정한 것은 다 좋은데, 로그인이 성공했는지 실패했는지 알려주는 인디케이터가 필요하다.

이는 로그인을 실패할 때 나오는 Invalid credentials! 문구를 활용할 것이다.

틀린 로그인을 하였다면 이 문구가 반드시 나오게 될 것이고, 이 인디케이터에 잡힐 것이다.잡히지 않았다면, 그것은 로그인을 성공한 것이다.공격을 시도해보자.

그럼 이렇게 bee/bug 항목만 Invalid 체크가 해제되어 있는 것을 확인하고 있다.

buggy/the가 해제되어 있는 이유는 동작중인 항목이라 그런 것.

bee/bug으로 로그인을 시도하면 정상적으로 로그인이 되는 것을 확인할 수 있다.

 

 

실 홈페이지 실습

/gm 페이지에서 더 많은 것들을 시도해보자

1:1 문의 게시판에서 남이 올린 게시물을 볼 것이다.

burp를 켠 후, 게시물을 눌러보자

url 인코딩이 되어있는 것을 확인할 수 있다. 즉, url 안에 정보들이 들어가있다는 것.

인코딩 된 정보에서 idx값을 변경하면 남의 게시물에 접근할 수 있을 것이다.

왜 이런일이 일어날까?

이유는 게시물에 접근 시, 세션값을 확인하지 않고 url 인코딩 되어있는 정보만 확인하기 때문에 이런 일이 일어나는 것이다.

때문에 단순히 열람 뿐 아니라, 수정, 삭제까지 가능할 것이다.

실제 업무에서도 세션을 확인하지 않는 부분을 전부 확인하는 것이 주 업무다.

 

자유게시판에서의 경우에서 한번 풀어보자

자유게시판의 글들은 비밀번호가 걸려있는 경우가 있다.

이 경우를 풀어볼 것이다.

잠금글의 경우, lock_pwd로 암호가 걸려있는 것을 확인할 수 있다.

이 페이지의 이름은 board_lock.php이다.

잠금을 풀고 간 페이지의 이름은 board_view.php

수정 페이지의 이름은 board_edit.php

 

idx값을 수정해도 결국에는 페이지의 암호를 나타내는 창을 통과해야한다.

즉, 서버단에서 페이지의 암호를 검사하기 때문에 뚫기가 힘들다

노려볼만한 board_view 창을 노려보자

 

이 페이지에서 수정으로 프록시를 확인해보자.

여기서 idx값을 수정해서 다른 페이지 수정으로 갈 수 있는지 확인해보면,

또 안된다고 나온다.

즉, board_view도 꽝인 것.

board_edit을 확인해보자.

 

중간에 idx값을 입력받고 있는 것을 확인할 수 있다.

여기서 idx값을 수정하고 비밀번호를 확인하고 있는지 확인해보자.

분명 권한이 없어 거부가 되었어야할 페이지가 수정이 되었다고 나온다.

즉, 게시글 수정 창에서는 비밀번호를 검사하지 않는다는 뜻

이걸 이용하여 원하는 게시글의 비밀번호를 수정하고 편집할 수 있을 것이다.

또한, 아까 수정한 idx값으로 1:1 문의 게시판에서 수정하면, 이번엔 비밀번호도 안물어보고 그냥 보여준다.

수정과 삭제 또한 가능하다.

이런 일이 일어난 이유가 무엇일까?

1. 세션 버그를 그대로 방치하였다.

2. DB가 동일한 곳으로 저장되어 있다.

이정도가 될 수 있을 거 같다.

 

 

또 다른 사이트이다.

이 사이트는 회원가입을 할 때 주민등록번호를 입력받는데, 이 번호가 틀리게 되면 alert로 틀렸다고 알람이 뜨게 된다.

문제는 이러한 경우에는 서버에서 처리되는 것이 아니라 클라이언트에서 처리하는 것이기 때문에, Burp가 잡아내지 못한다.

때문에 새로고침을 하여 강제로 요청을 띄워야한다.

응답으로 들어온 HTML 문서 중 일부이다.

보면 <script> 헤더 안에 각 함수들이 써있고, if문으로 처리가 되어 있는 모습을 확인할 수 있다.

함수에서 필요한 정보는 document.form.submit()라는 코드만 있으면 된다.

저 코드가 있어야 확인을 누르면 form이 제출이 된다.

그래서 복잡한 if문들을 싹 지운다.

그럼 이렇게 될리가 없는 주민등록번호로 회원가입이 되는 모습을 확인할 수 있다.

여기서도 똑같이 적용시킬 수 있다.

아이디/비밀번호만을 가지고 연락처, 이메일, 주소정보 없이 회원가입을 하게 만들 수 있다.

대충 이런 if문을 싹 지우면 된다.

귀찮은 정보입력을 전부 날리고 회원가입을 시도하면

회원가입이 완료되었으며 로그인을 하라는 창이 나오게 되고

로그인이 성공했다는 문구를 볼 수 있다

 

이 설문조사 폼을 수정해볼 것이다.

투표하기를 눌러도 alert로만 정보가 전달되어 서버로 가지지 않는다. Burp가 잡지 못한다는 소리.

새로고침하여 정보를 불러보자

Burp에 들어온 정보를 확인하면, 투표와 관련된 정보가 들어있는 것을 확인할 수 있다.

이걸 통째로 날리게 되면 인증과정 없이 투표가 될 것이다.

정상적으로 투표가 된 모습을 확인할 수 있다.