📌인가 취약점 예시

DATE : 2024/2/23

이번 POST에서는 인가 (Authorization)에서 다룬 각각의 예시들을 살펴볼 것이다.

1_주석으로 접근을 제한하는 경우

처음 살펴볼 케이스는 주석으로 접근을 제한하는 경우이다.

사용자가 자신의 계정을 입력하고 다음 페이지로 이동해보니

이와 같이 관리자만 버튼을 이용할 수 있다는 문구를 볼 수 있다.

아마 관리자 계정으로 로그인했다면 버튼이 포함된 페이지를 보여주고

그렇지 않은 경우에는 버튼이 보이지 않는 페이지를 출력하고 있는 듯하다.

그렇다면 숨겨진 버튼을 한 번 찾아볼까..? 라는 생각이 들 수 있을 것이다.

페이지 소스를 확인하거나 packet을 확인해 보면 어렵지 않게 주석 처리된 버튼을 찾을 수 있는데

이때 버튼을 사용하기 위해서는 (1)주석을 풀고 나서 클릭하는 방법과 (2)링크 tag에 적힌 주소로 직접

이동하는 방법이 있다.

개인적으로 편한 방법을 선택해 버튼이 클릭 된 경우 동작할 PHP를 요청하게 되면

원래는 관리자만 실행할 수 있도록 의도한 PHP code를 실행시킬 수 있게 된다!!

이렇게 특정 사용자에게만 기능이 보이도록 제어하는 과정에서 주석을 사용하거나

CSS로 display: none 처리를 하는 경우에는 사용자 측에서 변경이 가능하기 때문에

쉽게 드러날 수 있다는 점!

2_인가 판단을 Client 측에서 하는 경우

이번에는 인가를 서버가 아닌 client 측에서 제어하는 경우 생기는 문제를 보여준다.

사이트를 들어가 Fire 버튼을 누르면 팝업 창이 뜨는 데

이상하게도 서버와 주고 받은 기록이 남아있지 않다..!

그렇다는 현재 인가 여부를 서버가 아닌 client 측에서 판단하고 있다는 걸 의미한다.

메인 페이지 소스 코드에서 연결 되어 있는 JS file을 찾아볼 수 있는데

어떤 내용이 적혀 있는지 확인하기 위해 파일 경로로 접근해보았다.

js directory로 들어가 보면 총 4개의 js file이 나오는데

우리가 찾아야 하는 함수는 버튼을 클릭했을 때 동작하는 goMenu 함수이다.

각 js file을 열어 보면 user.js file에서 해당 함수를 찾아볼 수 있다!

function user_auth_check(needLevel, userLevel){

	if(needLevel == userLevel){
		return true;
	}else{
		return false;
	}
}

function goMenu(code, userLevel){
	switch (code){
		case '1018':
			if(user_auth_check('admin',userLevel)){
				location.href="./fire_nuclear_Attack.php";
				break;
			}else{
				alert('권한이 없습니다.');
				break;
			}
		case '1129':
			location.href="./logout.php";
			break;
		default:
			alert('없는 메뉴입니다.');
	}
}

코드를 읽어 보면 goMenu()로 전달된 첫 번째 인자는 code이고

두 번째 인자는 userLevel인데 userLevel이 admin이어야 fire_nuclear_attack.php가 동작함을 알 수 있다.

굳이 인자 값을 알맞게 넘겨 버튼을 클릭할 필요 없이 직접 해당 경로로 들어갈 수도 있다.

JS code에서 찾아낸 경로로 들어가게 되면 관리자만이 발사할 수 있는 미사일을

일반 사용자가 날려 버린 결과를 볼 수 있을 것이다..!

이처럼 "어떤 사용자가 어떤 권한을 부여해야지!" 라는 판단을 client 측에서 하는 경우,

해당 코드에 접근하여 분석하게 되면 공격자가 원하는 대로 인가 여부를 조작할 수 있기 때문에

인가 취약점이 발생하게 된다.

3_Guessing 공격

다음으로 살펴볼 예시는 바로 Guessing!! 말 그대로 예측한다는 소리다.

이게 무슨 대단한 공격인가 싶을 수 있지만, 흔히 사용되는 혹은 이런 이름으로 기능을 구현했을 거 같은데?

싶은 값을 넣어봄으로써 손 쉽게 숨겨진 기능을 찾아내는 경우들이 있다고 한다..!

(그래서 경험이 중요하다고..)

이번 문제의 목표는 관리자만 글을 작성할 수 있는 게시판에 글을 남기는 것이다.

로그인을 한 뒤, 공지 사항 페이지로 이동해준다.

공지 사항 페이지에는 admin이 남겨둔 공지 사항이 있는데 내용을 읽어보면

요즘 수상한 직원들이 있어 골치 아픈가 보다.ㅎㅎㅎ

공지 사항 페이지도 그렇고 상세 페이지도 그렇고 별 다른 기능이 보이지 않는데..

글을 어떻게 작성하라는 걸까??

이때 URL을 유심히 보면 notice_read.php 라는 파일명을 볼 수 있는데

만약 내가 이 사이트를 개발한 사람이라면 글을 작성하는 파일명은 비슷한 패턴으로 notice_write.php라

지었을 것이다.

그래서 URL에 notice_write.php를 입력해봤더니 위와 같이 성공적으로 게시물 작성 페이지로

이동할 수 있었다. 글을 모두 작성하고 하단에 create 버튼을 클릭하면

글을 업로드 했다는 의미로 flag를 얻을 수 있다.

이와 같이 사용자에게 제공되지 않는, 눈에 보이지 않아 없는 기능 같지만

사실은 대놓고 주어지지 않았을 뿐 큰 문제 없이 접근이 가능한 경우에 우리는 추측을 통해

이런 파일이 있겠는데?? 이런 directory 있겠는데?? 하면서 숨겨진 요소를 찾아낼 수 있다.

다만, 마구잡이 대입하기 보다는 위와 같이 작성된 파일 이름의 패턴 등을 참고해

값을 넣어보는 것을 추천한다.

(notice_read.php 파일이 있는데 다른 파일 이름은noticeWrite.php로 작성할 확률은 적으니..!)

4_파라미터 변조

마지막 케이스를 알아보기 위해 이번엔 마이 페이지로 들어가 볼 것이다.

마이 페이지로 들어가면 위와 같이 사용자 이름, 설명, 비밀번호를 나타내는 입력 칸이 있는데

사용자 이름을 입력하는 부분에 placeholder 값이 user parameter로 전달되는 값과 동일한 상태임을

볼 수 있을 것이다.

만약 서버가 이 파라미터를 기반으로 로그인 한 사용자에게 마이 페이지를 제공하는 것이라면

파라미터를 admin으로 변조해 전달했을 때 관리자의 마이 페이지를 얻을 수 있지 않을까??

예측한 바를 확인하기 위해 user parameter에 admin을 입력하고 전달해봤다.

결과는..! 성공적으로 관리자의 마이 페이지로 접속한 모습을 볼 수 있다..!

파라미터 변조는 인가 취약점을 잡아낼 때 제일 많이 활용되는 방식으로

예~~~전에 풀었던 문제에서는 파라미터를 가지고 Reflected XSS도 수행했었고

SQLi도 수행했는데 이번 사례를 통해 인가 취약점으로도 다뤄질 수도 있다는 점을 얻어간다..! 👍