Normaltic 모의해킹 취업반 스터디 8기 - 16주차

containerxox·2025년 7월 23일
post-thumbnail

✅ 인증 / 인가 취약점

  • 인증 (Authentication)
    : 사용자 자신이 누구인지 증명하는 과정
    ex) 인증 방법으로는 비밀번호 입력, OTP, 생체 인증 등

  • 인증 취약점
    : 인증 절차를 우회하거나 생략

  • 인가 (Authorization)
    : 사용자가 특정 작업을 수행할 권한이 있는지 확인하는 것

  • 인가 취약점
    일반 사용자가 관리자 기능에 접근 가능한 경우 (권한 상승)
    즉, 자신에게 부여되지 않는 접근권한을 우회하여 접근 가능한 경우



✔️ 아래의 4개의 CTF 문제 복습하기

  • GET Admin
  • PINCODE Bypass
  • Admin is Mine
  • PinCode Crack




🔵 인증 취약점 대표 케이스

1. 쿠키를 통해 인증하는 경우

즉, 클라이언트 측 정보를 신뢰하여 인증을 하는 경우이다.

GET Admin 문제를 보면,
쿠키 값을 공격자가 원하는 값으로 변경하여 인증 우회하는 케이스이다.



2. 직접 접근 (direct access)

PINCODE Bypass 문제 처럼
직접 접근을 통해 본인 인증을 건너뛰는 경우이다.

예를 들어, 회원가입의 경우
(1) 약관 동의
(2) 본인인증 (휴대전화)
(3) 회원가입
👉 (2)번 단계를 안거치고 해당 단계를 뛰어넘어버리는 경우

경로가 step1.php, step2.php인 경우,
다음 경로는 step3.php이겠구나 하고 guessing 공격으로 예측하여
직접 접근하는 경우

  • PINCODE Bypass문제 참고 !



3. 파라미터 응답값 변조

프로그래밍, 설계가 잘못된 경우에 발생하는 케이스

  • 올바른 로그인 처리 구현 순서
    admin의 id, pass 입력 & 요청 → 인증 성공 → session = admin
  • 잘못된 로그인 처리 구현 순서
    admin의 id, pass 입력 & 요청 →session = admin → id, pass 검증
    → 틀리면 다시 로그인 페이지로 리다이렉트
    ➡️ admin 계정의 pw를 잘못입력해도 id와 pw를 검증 전에 session에 admin을 저장하기때문에, admin 계정으로 이미 로그인 되어 있는 상태일 것이다.

👉 모바일 앱에서는 파라미터 응답값을 변조해서 우회하는 케이스의
인증 취약점이 多

  • Admin is Mine 문제 참고!
    인터셉트 기능을 이용하여 응답을 {"result:"ok"}로 변조함.



4. 인증 횟수 제한하지 않는 경우

비밀번호를 몇번이든 입력해도 제한하지 않아서 계속 시도 가능한 경우.
➡️ 이런 경우 무작위 대입 공격(Brute force)이 가능 !

  • PinCode Crack 문제 참고



❓인증 취약점 관련 질문

🧔 파라미터 응답값 변조는 https에서는 불가능한가요?

A) https에서도 가능합니다 !

🧔 PINCODE Bypass 문제(미사일발사 문제)에서 원래 발사가 불가능한데, 직접 접근하면 발사할 수 있게 되니까 인가 취약점이 아니라 인증 취약점이 되는건가요?

A) PINCODE Bypass 문제에서 원래 일반 사용자가 발사를 할 수 없지만, 직접 URL에 direct access 하면 발사가 가능해진다.
그래서 나의 관점에서는 인증 과정을 우회했기 때문에, 인가 취약점보다는 인증 취약점이 적합하다고 생각해서 인증 취약점이라고 한 것이다.

발사 자체는 관리자 인증을 거친 후에 가능하도록 되어 있는데,
나는 직접 접근을 통해 인증을 우회해서 발사 페이지에 접근했으므로
이를 인증 취약점으로 판단한 것이다.

사실, 이에 인증 취약점인지 인가 취약점인지 용어를 정확히 나누는 것보다, 왜 그런 문제가 발생했는지 설명할 수 있는게 더 중요하다 !

헷갈릴 땐 대응방법을 떠올려보자 !!
이 문제의 본질은 관리자 인증이 제대로 동작하지 않았기 때문에
직접 접근이 가능해진 것이다.
즉, 인증 로직을 보완해야하므로 인증 취약점으로 분류하는게 적절하다고 판단한 것이다.

결국, 이건 상황에 따라, 그리고 보는 관점에 따라 달라질 순 있다.







🟠 인가 취약점 대표 케이스

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

또는 CSS를 이용해서 display:none으로 숨김처리하는 경우

🔸인가 CASE 1 ) authoirization 1

👉 방법 1) 내가 생각한 방법


로그인 하기 (sfUser:sfUser1234)


/auth2.index.php페이지를 보면,
나는 일반 유저 계정이여서 발사버튼이 화면에 표시되지 않는다.


만약, 관리자 계정이면, 주석처리된 부분이 해제되고 Fire 버튼이 화면에 표시되고, Fire 버튼을 클릭하면, fire_attack_danger.php로 요청이 갈 것이다.


하지만, 나는 관리자 계정이 아니다.
login.php의 응답을 보면, 로그인에 성공을 하면 스크립트가 실행되어index.php로 이동하게 된다.
이를 이용해 index.php 대신 fire_attack_danger.php로 이동하도록 변경하면, 로그인 성공 시 곧바로 해당 페이지로 이동하게 된다.
마치 관리자가 fire 버튼을 클릭한 것과 같은 효과 !


그렇게 하기 위해, 로그인 페이지에서 intercept on 하고
id와 pw를 입력하고 login 버튼 클릭


브라우저가 요청을 전송하지 않고 멈춰있을 때,
우클릭 → do intercept → response to this requset 클릭


index.php 대신 fire_attack_danger.php로 변경 후 intercpet off


플래그 획득 !
➡️관리자 전용인 fire 버튼에 대한 접근 권한을 우회하여 클릭하는 데 성공했다.

👉 방법 2) 주석 제거하여 버튼이 화면에 표시되게 만들기

sfUser:sfUser1234로 로그인 후,
/auth2/index.php 페이지를 보면, 주석처리로 인해
발사 버튼이 화면에 표시되지 않음.


주석을 제거해서 버튼이 표시되게 만들자 !
( intercept on → 응답값에서 주석 제거 )


이제 Fire 버튼이 화면에 표시됨.


Fire 버튼 클릭하면,fire_attack_danger.php로 이동.
플래그가 출력됨.


👉 방법 3) 주석에 적힌 해당 URL로 직접 접속


sfUser:sfUser1234로 로그인 후,
/auth2/index.php 페이지를 보면, 주석처리로 인해
발사 버튼이 화면에 표시되지 않음.


fire_attack_danger.php로 직접 접근하자.
플래그가 출력됨.



2. 인가 체크를 클라이언트 측에서 하는 경우

➡️ 실행되는 JavaScript를 찾을 수 있어야 한다 !

⭐ 인가(권한) 체크를 클라이언트 측에서 하는지, 서버 측에서 하는지 확인해봐야 한다 !

만약, 인가체크를 하는 자바스크립트가 난독화되어 있는 경우,
직접 접근이 힘들다 !

난독화 되어 있는 경우는
온라인에 있는 툴을 이용해서 난독화를 풀거나
동적분석을 진행하면 된다.

  • 정적 분석 & 동적 분석
    ↳ 정적 분석 : 실행하지 않고, 코드를 읽으면서 분석하는 것
    ↳ 동적 분석 : 코드를 실행해보면서, 코드를 분석하는 것

🔸인가 CASE 2 ) authoirization 2



로그인하기 (sfUser:sfUser1234)


인가(권한)체크를 서버 측에서 하는지, 클라이언트 측에서 하는지 확인해보자.
Intercept on → index.php에서 Fire 버튼 클릭
➡️ 서버로 가는게 없다 !
➡️ 즉, 서버에서 인가 체크를 하지 않는다는 의미 !!
➡️ 이제, Fire 버튼을 클릭했을 때 클라이언트 측 자바스크립트가 실행되는지 확인해봐야겠다 !


Fire 버튼 클릭하면 권한이 없습니다라는 알림창이 뜬다.


/auth3/index.php의 응답을 살펴보자.

✔️ /user.js/game.js 의 자바스크립트가 있다.
✔️ onclick="goMenu('1018','user')
: Fire 버튼을 클릭하면, /user.js/game.js JavaScript 둘 중 하나에 작성된 goMenu()함수가 호출된다.
호출 시 인자로는 1018user가 전달된다.


Fire 버튼을 클릭하면,
/auth3/js/user.js자바스크립트의 goMenu()함수가 호출된다.
해당 자바스크립트를 살펴보자.

현재 일반 계정으로는 goMenu()함수의 인자로 1018과 user를 전달하므로 권한이 없습니다라는 알림창이 뜨는 것을 확인할 수 있다.

./fire/nuclear_Attack.php를 실행시켜 발사시키고 싶다면,
admin이라는 userLevel 값이 필요하다.


인터셉트를 통해 응답을 변조하자.


useradmin으로 변경하고 intercepoff

Fire버튼 클릭
➡️ 플래그 획득
➡️ 관리자 전용인 fire 버튼에 대한 접근 권한을 우회하여 클릭하는 데 성공했다.


또는 인터셉트를 통해 응답을 변조하지 않아도
콘솔창에서 goMenu('1018', 'amdin')으로 직접 실행할 수도 있다.



🔸인가 CASE 2 ) authoirization 3


로그인하기 (sfUser:sfUser1234)


/auth4/ 페이지


응답을 보면,
✔️ /user.js와 /game.js 의 자바스크립트가 있다.
✔️ onclick="goMenu('9999','user')
: Fire 버튼을 클릭하면, JavaScript의 goMenu()함수가 호출된다.
호출 시 인자로는 9999user가 전달된다.


fire 버튼을 클릭하면, /auth4/js/user.js자바스크립트의 goMenu()함수가 호출된다.
해당 자바스크립트를 살펴보자.
현재 일반 계정으로는 goMenu()함수의 인자로 9999user를 전달하므로
권한이 없습니다라는 알림창이 뜨는 것을 확인할 수 있다.


/auth4/js/user.js 코드는 goMenu라는 JavaScript 함수로,
code와 userLevel이라는 두 개의 매개변수를 받고,
특정 조건 (code === '9999')일 때 복잡하게 암호화된 문자열을 디코딩하여 location.href (즉, 현재 페이지를 특정 URL로 이동시킴)를 설정한다.

전체적으로 난독화된 URL을 복호화해서 특정 관리자(admin)만 접근 가능한 페이지로 이동하는 기능이다.

이동할 URL은 문자열을 난독화하여 노출되지 않게 처리되어 있다.


goMunu() 함수의 userLevel 매개변수 값이 admin이여야
관리자로 접근하여 Fire 버튼을 클릭하여 핵미사일을 발사할 수 있다.

따라서, intercpt 기능을 이용하여 응답을 변조하자 !
userLevel 매개변수 값을 user에서 admin으로 변경


Fire 버튼을 클릭하면,
goMenu('9999', 'amdin')이 호출되면서,
관리자 권한으로 Fire 버튼 클릭이 가능 !


/auth4/fire_computer_world.php로 이동되고 flag 값이 알림창에 출력됨.
➡️관리자 전용인 Fire 버튼에 대한 접근 권한을 우회하여 클릭하는 데 성공 !



3. Guessing 공격

➡️ 경로를 추측 !



🔸인가 CASE 3 ) authoirization 4


회원가입 후 로그인 (TestUser04: TestUser04)


게시판으로 이동 (/auth5/index.php?page=board)
일반 유저 계정으로는 게시판에서 글 작성이 불가하다.


auth5/index.php?page=write가 글 작성 페이지일 것으로 예상하고,
페이지 이름을 추측하는 guessing 기법을 활용해 접근을 시도
➡️ 예측 적중 !


등록 버튼을 클릭하고 auth5/index.php?page=write응답을 살펴보면,
flag값이 출력되고,index.php?page=board페이지로 이동된다.



4. 파라미터 변조

( 예시 ) 1:1 문의 게시판 또는 비밀글

  • 비밀글을 보통 비밀번호를 입력해야 내용을 볼 수 있다.
  • 내가 직접 게시판에 글을 작성하면,
    내 글은 비밀번호 없이도 열람 가능하다.
  • 이때, 내 게시글 화면의 URL이나 파라미터에
    다른 사람의 글 번호를 입력해보자.

  • 만약, 다른 사람의 글이 그대로 열리는 경우,
    이는 파라미터 변조 취약점이다.
  • 즉, 접근 권한 확인 없이 파라미터만 바꿔도
    비밀글에 접근 가능한 것이다.



🔸인가 CASE 4 ) authoirization 5


회원가입 후 로그인 (TestUser06 : TestUser06)


게시판 페이지로 이동 (/auth6/index.php?page=board)


admin(관리자)가 작성한 게시글 클릭


normaltic, test 등 일반 유저들이 작성한 게시글을 클릭하면
타인의 글은 읽을 수 없습니다 라는 알림창 뜨며, 접근 제한이 됨.


TestUser06계정( 내 계정)으로 게시글 작성해보자.
✓ 내가 작성한 글은 열람 가능 !


id 파라미터값을 변조하여 normaltic이라는 일반 유저의 게시글을
열람할 수 있는지 확인해보자.
➡️ 타인의 글은 읽을 수 없습니다라는 알림창이 뜸
➡️ 접근 제한 됨

/auth6/index.php?page=read&id=게시글 번호으로 게시글에 열람(조회)하려고 하면,
서버에서 해당 글을 작성한 유저와 현재 접근하려는 유저가 동일한지 확인하는 것 같다.


하지만, 게시글 수정은 사용자 인가 검사를 하지 않는 것 같다.
normaltic이 작성한 게시글을 조회하려고 하면 접근 불가.
(/auth6/index.php?page=read&id=2)

/auth6/index.php?page=edit&id=2하면, 게시글 내용을 볼 수 있다.
➡️ 글 작성 페이지에서는 인가 검사가 이루어지지만,
글 수정 페이지에서는 인가 검사가 누락되어 있는 인가 취약점을 이용하여,
파라미터를 변조함으로써 일반 사용자의 게시글 내용을 볼 수 있다 !



🔸인가 CASE 4 ) authoirization 6


회원가입 후 로그인( TestUser07 : TestUser07)


TestUser07의 마이페이지 (/auth7/index.php?page=mypage&id=11)


id 파라미터 변조를 하면 관리자나 다른 유저의 마이페이지에 접근가능하지않을까?
➡️ id=1을 해보자 → flag 획득 → 관리자의 마이페이지에 접근 가능


id 파라미터 변조를 통해 다른 일반 유저의 마이페이지에도 접근 가능함.




💡 만약, 자바스크립트가 버프스위트의 history에 뜨지 않는다면,

f12 누르고
오른쪽 버튼 클릭하여
캐시 비우기 및 강력 새로고침을 해주세요 !

0개의 댓글