WebGoat / Missing Function Level Access Control
첫 번째 문제 - Finding hidden items
첫 번째 문제를 번역기로 해석해 보니
숨겨진 아이템 찾기
일반적으로 UI가 공개적으로 노출되지 않는 기능을 찾는 힌트는 다음과 같습니다.
- HTML 또는 자바스크립트 주석
- 주석 처리된 요소
- CSS 컨트롤/클래스를 통해 숨겨진 항목
당신의 임무
아래 메뉴에서 공격자/악의적인 사용자가 관심을 가질 만한 두 개의 보이지 않는 메뉴 항목을 찾아 해당 메뉴 항목에 대한 레이블을 제출합니다(현재 메뉴에는 링크가 없습니다).
요약
1. 개발자가 UI에 표시되지 않도록 숨긴 항목이 있다.
2. 해당 항목을 찾아서 다음 단계로 넘어가 보자
Step 1 - 개발자 도구를 활용하자
개발자 도구를 사용하여 현재 UI에 숨겨진 hidden-menu-item 항목을 찾았습니다. 해당 항목에 CSS를 확인해 보면 visibility 속성이 있는데요. visibility 속성이 항목을 안 보이게 하는 기능을 제공합니다. 이제 visibility 속성을 비활성화하여 어떤 것이 숨겨져 있는지 확인해 보겠습니다.
결과 - 숨겨진 항목 Admin
Admin 드롭박스가 숨겨져 있었네요. 안에는 User와 Config라는 메뉴가 들어있네요. 이제 우리는 1번과 2번에 각각 메뉴 이름을 입력한 후 제출하면 문제가 해결되는 것을 볼 수 있습니다.
두 번째 문제 - Gathering User Info
두 번째 문제를 번역기로 해석해 보니
데이터 덤프는 SQL 주입과 같은 취약점으로 인해 발생하는 경우가 많지만 액세스 제어가 부족하거나 부족하여 발생할 수도 있습니다.
이를 얻으려면 여러 단계와 여러 번의 시도가 필요할 수 있습니다.
- 댓글과 유출된 정보를 주의 깊게 살펴보세요.
- 추측도 좀 해야 합니다.
- 도중에 다른 브라우저/계정을 사용해야 할 수도 있습니다.
이미 수집한 정보(숨겨진 메뉴 항목)부터 시작하여 사용자 목록을 가져온 다음 Jerry 계정에 대한 '해시'를 제공할 수 있는지 확인하세요.
요약
1. SQL Injection 공격으로 보통 정보 수집을 하지만, 부족한 접근 제어를 통해서도 가능하다.
2. 전에 숨겨진 Admin 항목에서 사용자 목록을 가져와 Jerry 계정에 대한 해시값을 구해라.
Step 1 - User 메뉴 확인하기
먼저 Admin 항목에 숨겨져 있던 첫 번째 User 메뉴를 클릭하여 어떤 요청을 보내는지 확인해 봅시다.
Request
요청 값을 확인해 보니 GET 방식으로 /access-control/users 이쪽으로 조회를 요청하고 있는 걸 볼 수 있습니다. 그렇다면 응답 값을 확인해 볼까요?
문제 발생 - 404 Not Found
Response
상태코드가 404 Not Found인 걸 보니 뭔가 요청이 잘못된 거 같네요. 우리는 분명 users에 있는 정보를 가져오려고 했는데 뭐가 문제였을까요?
문제해결 - 요청 경로 잘 확인하기
수정 전
수정 후
우리가 요청을 보낼 때 앞에 항상 /WebGoat가 있는 걸 명심해야 합니다. 이제 제대로 요청을 수정한 후 응답 값을 확인해 보겠습니다.
이번에는 상태코드가 500인 에러가 나왔습니다. 500 상태코드는 서버에서 생기는 오류를 의미합니다. 한번 브라우저에서는 어떻게 표현되는지 확인해 보겠습니다.
뭔가 어마어마한 양의 응답이 돌아왔는데요. 딱 봐도 문제가 생긴 거 같네요. 오류는 살펴보니 TemplateInputException: An error happened during template parsing (template: "class path resource [webgoat/templates/list_users.html]") 이런 문장이 보이는데 템플렛이 파싱되는동안 오류가 생긴 거 같다고 나온 거 같네요. 오류를 구글링해 보니 해당 오류는 약간 문제를 출제하기 위해 억지스러운 부분이 많은 부분이라고 다들 얘기를 합니다. 저도 자바를 공부하지 않아서 자세히는 모르지만 요약해서 간단히 설명해 보겠습니다.
위에 코드는 현재 문제를 구성하는 자바 코드입니다. 3번째 줄을 보면 consumes라는 변수가 보이는데 해당 코드는 요청받았을 때 요청 헤더의 Content-Type 콘텐츠 타입이 application/json 으로 보내야 한다는 설정입니다. 그러므로 우리는 요청 부분에 Content-Type: application/json 을 추가해서 보내주면 제대로 된 응답을 받게 될 것입니다. 한번 확인해 볼까요?
결과
이렇게 다른 사람들의 정보를 조회하는 데 성공하였습니다. 그럼, 이제 Jerry의 해시값을 찾아서 문제를 풀어봅시다.
Jerry의 해시값을 넣어서 해당 문제를 해결하였습니다.
세 번째 문제 - The company fixed the problem, right?
세 번째 문제를 번역기로 해석해 보니
회사에서 문제를 해결했지요?
회사는 엔드포인트가 너무 개방적이라는 사실을 발견하고 긴급 조치를 취했으며 관리자만이 모든 사용자를 나열할 수 있는 것이 아닙니다.
이미 수집한 정보(숨겨진 메뉴 항목)부터 시작하여 사용자 목록을 가져온 다음 Jerry 계정에 대한 '해시'를 제공할 수 있는지 확인하세요.
요약
1. 회사가 문제가 있다는 것을 발견하고 관리자만 조회가 가능하게 긴급 조치를 했다.
2. 하지만 여전히 취약점은 존재하니, fix가 된 문제에서 다시 Jerry의 해시값을 찾아라.
Step 1 - 요청 확인하기
이번에는 fix가 이루어진 두 번째 Users를 확인해 보도록 하겠습니다.
Request
첫 번째 Users와 마찬가지로 /WebGoat가 빠졌습니다. 이번에는 경로, 헤더를 잘 추가해서 요청을 해보도록 하겠습니다.
Response
응답에서 403 Forbidden 상태코드를 보냈습니다. 확실히 이번에는 권한이 없다고 접근을 막아버렸습니다. 그렇다면 이제는 정말로 취약점이 없는 걸까요? 그렇지 않습니다. 이번 문제는 아직도 취약점이 존재한다고 말했습니다. 해당 문제를 해결하기 위한 힌트가 이미 문제에서 주어줬습니다.
해결방법 - 권한부여
두 번째 문제에서 조회했던 사람들의 정보를 기억하시나요? 만약 기억나지 않는다면 다시 한번 위에 사진을 확인해주세요. 보시다시피 각각의 사용자들은 username, admin, userHash값을 가지고 있습니다. 그런데 여기서 주의 깊게 봐야 할 것은 타 사용자를 조회했을 때 실제로 WebGoat에 로그인한 사용자의 정보는 없었다는 것입니다. 그래서 이번에는 조회했을 때 권한이 없어서 다른 사용자를 조회할 수 없습니다. 즉, 임의의 사용자를 추가하면 어떻게 될까요? 우리는 Restful API가 HTTP에서 메서드를 통해 객체, 데이터 접근(GET)이나 생성(POST) 수정(PUT) 삭제(DELETE)를 할 수 있다고 했습니다. 이번에는 임의의 사용자를 추가해서 권한을 부여하고 조회를 할 수 있게 공격을 해볼 겁니다.
Step 2 - 임의의 사용자 추가하기
POST 메서드를 사용하여 임의의 사용자를 추가해 보겠습니다.
Request
POST로 요청을 전달하기 때문에 본문에는 우리가 새롭게 만들 사용자를 json형태로 담아서 보내줄 겁니다. username 저의 아이디를 넣어주었습니다. 그리고 admin 권한을 true로 하여 관리자 권한을 사용할 것입니다. 마지막으로 userHash값은 어떻게 생성되었는지 모르니 아무 값이나 넣어서 요청을 보내보겠습니다.
Response
응답으로는 200 상태코드가 보내졌습니다. 그렇다면 제대로 요청이 반영된 거 같습니다. 즉, 서버에 사용자 정보가 추가되었으며 사용자 조회에는 접근 제어 로직을 추가했지만, 사용자를 추가할 때는 접근 제어 로직을 추가하지 않았다는 걸 알 수 있습니다.
결과
Request
GET 메서드를 사용하여 조회를 요청해 보겠습니다.
Response
새롭게 생성한 자신을 추가함으로써 권한이 생긴 공격자는 조회를 수행할 수 있게 되었습니다. 이제 우리는 Jerry의 Hash 값을 문제에 입력하면 완료가 될 것입니다.
Jerry의 Hash 값을 넣어서 문제를 해결하였습니다.
마무리
이번 실습은 개발자가 UI에 Admin 관련 정보를 숨겨놓으면서 발생한 여러 문제점에 대한 공격 방법들에 대해서 알아보았습니다.
