[SegFault] (Authentication Bypass) - Admin is Mine

[SegFault] Authentication Bypass (Admin)

Admin is Mine.

admin 계정으로 로그인하자!

문제 파악

• 위의 페이지에 접속하면 아래와 같은 화면이 나온다.
• 알고 있는 계정 :  [ID/PW] : doldol / dol1234

• Burp Suite을 이용하여 사이트 접속 과정의 상태코드(Status code) 확인
  
  • 200 OK : 정상적인 응답
• 로그인 과정의 구조를 알기 위해, 먼저 알고 있는 정보로 로그인 해본다.

• 제공된 ID/PW를 입력했음에도 해당 창에서 넘어가지 않음을 확인, 로그인이 진행되지 않는다?!
• 로그인 과정의 히스토리(HTTP history) 확인 해보자 !

• ID와 PW를 입력했음에도 파라미터(Params)가 들어가지 않고있음을 확인할 수 있다.
• 요청(Request)과 응답(Response)을 살펴보자 !

<script>location.href='login.php';</script>

• 강제로 리디렉션 시키고 있음을 확인할 수 있다.

<script src="js/login.js">

• login.js이 존재하는 것을 확인하고,, 내부를 들여다 본다.

const userId = loginForm.querySelector("#inputUserid").value;
const userPw = loginForm.querySelector("#inputPassword").value;

const url = `/4/loginProc.php?userId=${userId}&userPw=${userPw}`;

• 위의 login.js 를 통해 loginProc으로의 parameter 전송 방식을 확인할 수 있다.

---

풀이 과정 (해결 방안)

1. intercopt 후, 브라우저 창 및 히스토리(HTTP history) 확인해본다.

2. 경로를 /4/loginProc.php로 설정하고 파라미터를 담아서 Forward 해준다.

1. (제공된) 로그인 시도
2. 인터셉트(Intercept) : /4/
3. GET /4/loginProc.php?userId=doldol&userPw=dol1234 으로 변경
4. Forward -> GET /4/index.php
5. GET /4/loginProc.php?userId=admin&userPw=dol1234 으로 변경
6.  Forward -> 새로고침

3. 강제로 로그인 시켜주면, 로그인되는 것을 확인할 수 있다.

왜? 강제로 로그인 시켜준다면 로그인이 되는 것일까?

이 문제의 경우 이미 정답(로그인이 되고 있었다)을 뿌려주고 있었다.
하지만!
토큰이 없는 경우 js에 의해서 리디렉션 시키고 있었을 뿐이다.
그래서 토큰 리디렉션을 강제로 시켜주면 로그인이 되는 것 처럼 보이는 것이다.

4. 브라우저를 새로고침하면 Flag가 나오는것을 확인할 수 있다.

---

풀이 방식의 오류

사실 해당 풀이 방법은 잘못되었다.

위의 풀이로 풀어졌기에 넘어간 뒤에 깨달았다는 사실을 반성하며 정리해보려 한다.

잘못된 풀이 (왜 가능했는가?)

해당 문제가 위의 풀이 방법으로 풀린 이유를 먼저 생각해보자.

기존에 주어진 id/pw로 로그인하여 인증 성공시에 세션에는 다음과 같은 값이 담긴다.
$_SESSION['loginUser'] = 'doldol';
$_SESSION['loginStatus'] = 'ok';

여기서 원래라면 로그인 인증에 실패하는 경우에는 다음과 같은 과정이 필요하다.
$_SESSION['loginStatus'] = 'ok'; 의 값을
$_SESSION['loginStatus'] = 'fail'; 과 같이 fail로 바꿔줘야 한다는 것이다.

하지만 본 문제의 경우 로그인 인증 실패시 안 넣어 준 것이다.(잘 못 된것)
그래서 admin으로 재요청시 세션의 값은 다음과 같았다.
$_SESSION['loginUser'] = 'admin';
$_SESSION['loginStatus'] = 'ok';
위와 같이 날아간 경우이기 때문에 admin으로 로그인이 된 것이라는 것이다.

사실 문제의 또 다른 취약점에 의해 문제가 풀린 것이었고, 해당 문제의 의도와는 달랐다는 것이다.

문제의 원래 의도 (올바른 풀이법)

본 문제의 올바른 풀이법은 다음과 같이 2가지 이다. 

1. fail 로 처리되어 있는 응답을 변조하여 ok로 바꾸어 진행한다.
2. 응답의 javascript를 삭제하여 리디렉션을 저지한다.

(결국 응답을 변조한다는 것으로 보면 같은 풀이법이다.)

---

취약점에 관한 고찰

본 문제의 취약점은 인증 취약점으로서 응답 변조를 통하여 인증을 무시하는 것에 있다.
응답 변조 (Response Mod) 를 통하여 로그인에 실패하여 $_SESSION['loginStatus']  = fail 이라고 나오고 있는 응답을 $_SESSION['loginStatus']  = ok로 변조하거나, 강제로 페이지를 리디렉션 시키고있는 javascript를 삭제하므로써 진행이 가능하다는 것이다.

하지만 여기서 생각해볼 점은 해당 취약점의 경우 이런 것도 있다 라고 알려주기 위해 인위적으로 만든 취약점으로서 프로그래밍 자체를 잘못한 것이라고 할 수 있다. 일반적으로는 나오지 않는 취약점이라는 것이다.

login 처리 구현
올바른 순서 : id/pw -> 인증 성공 -> session=admin

해당 문제의 경우
요청이 들어오면 일단 세션에 넣어둔다. (session=admin) -> id/pw 검증

위와 같이 이미 세션에 값이 들어있는 경우에 해당하는 취약점으로서 웹페이지에서는 많이 나오지 않는 취약점이라고 한다.(하지만 모바일 앱에서는 생각보다 많이 나오는 취약점이라고 하니 생각해볼만 하다.)

---

질문 환영, 수정 및 보완에 대한 지적 환영