[기록일지] 📚 16주차 (인증/인가 취약점)

인증 / 인가 취약점

인증

인증(Athentication)이란, 그 사람이 본인이 맞는지 확인하는 것이다.

흔히 비밀번호나, 인증코드를 입력하는 과정 등이 이에 해당하는데, 다른 이용자가 알지 못하는 본인만 아는 정보를 통해 본인임을 확인하는 것이다.

그러므로 인증 취약점은 인증 과정에서 일어나는 취약점으로서, 인증을 무시하는 공격이 가능한 것을 의미한다.

 

인가

인가(Athorization)란, 특정 사람에게 특정 권한을 부여하는 것이다.

이용자마다 각각에 해당하는 권한을 부여하는 것이다. 권한 간에는 가능한 것의 차이가 존재하고, 원래는 하지 못해야하는 이용자가 상위의 권한에 해당하는 것을 할 수 있는 경우에 문제가 되는 것이다.

그러므로 인가 취약점은 해당 유저가 원래는 하지 못해야 하는걸 하는 것이 가능한 취약점이다.

ex) 관리자만 가능한 것을 일반 유저가 할 수 있는 경우

---

인증 취약점의 대표 케이스

1. Cookie를 통해 인증하는 케이스

쿠키(Cookie)와 같이 클라이언트 측 정보(파라미터)를 통해서 인증하는 경우에 문제가 된다. 클라이언트 측 정보를 신뢰하여 인증을 하게되면, 변조가 가능하기 때문이다.

로그인 한 사용자의 인증을 Cookie를 통해 하는 경우, 서버에서 이 Cookie를 바탕으로 사용자가 누구인지 식별하고 그에 맞는 권한을 부여하는 경우, 이를 변조하여 다른 이용자인 것처럼 인증 과정을 우회할 수 있다는 것이다.

클라이언트 측 인증을 한다는 것은 자물쇠와 함께 열쇠를 걸어둔 것이나 마찬가지이다.🔐

[SegFault] (Authentication Bypass) - Get Admin

[SegFault] (Authentication Bypass) - Get Admin

위의 문제의 경우 쿠키 변조를 통해 관리자 권한이 취득 가능한 인증 취약점이다.

 

2. Process 점프 (직접 접근)

Process를 뛰어넘어 직접(direct) 접근이 가능한 경우를 말한다. 일반적으로 본인 인증을 우회하는 경우에 많이 사용된다.

원래 본인인증 절차를 거쳐서, 이후의 페이지에 접근이 가능하다면 Process를 넘기는 것이 가능한 경우, 다음페이지로의 경로를 직접 입력함으로써 직접접근이 가능하다는 것이다. 인증 된 사용자인지 확인하는 절차를 무시할 수 있기 때문에 인증을 할 필요 자체가 없어지는 것이다.

이런 경우에는, 어떻게 생각해야할까?

인증을 뛰어 넘었기 때문에 인증 취약점이라고 해야하는가? 원래 못하는 건데 할 수 있었기 때문에 인가 취약점이라고 해야하는가?

여기서는 대응방식에 대햐여 생각해봐야 한다.

대응 방식은 인증을 뛰어 넘어서 발생한 것이기 때문에 이것을 고치게 한다는 생각을 하면 인증 취약점이 맞다는 것이다.

[SegFault] (Authentication Bypass) - PIN Code Bypass

[SegFault] (Authentication Bypass) - PIN Code Bypass

위의 문제의 경우 인증 취약점과 함께,  인가 취약점이라고도 분리할 수 있다.

인증 · 인가 취약점의 경우 어느정도 주관이 들어가는 부분으로서, 설명만 할 수 있다면 취약점으로 잡을 수 있다.

 

3. 응답 값 변조

응답 변조를 통해 인증을 무시하는 경우이다. Burp의 responseMod 를 통해 응답을 변조하는 것으로서 클라이언트 측 제어를 하는 것이다.

응답에 존재하는 파라미터(Parameter)의 값을 수정하거나, Javascript를 수정하거나 삭제하여, 인증을 무시하는 것이 가능하다는 것이다.

[SegFault] (Authentication Bypass) - Admin is Mine

[SegFault] (Authentication Bypass) - Admin is Mine

 

4. 인증 횟수 제한 X

비밀번호 횟수 제한이 미흡한 경우에는 인증 취약점으로 잡는다. 이런 경우 브루트포스(BruteForce) 무작위 대입 공격에 대하여 취약하게 된다는 것이다.

[SegFault] (Authentication Bypass) - Pin Code Crack

[SegFault] (Authentication Bypass) - Pin Code Crack

Brute Force (무작위 대입 공격)의 경우, 값을 계속해서 변경하면서 여러번 시도하는 공격이다.
그런데, 인증 횟수에 제한이 없다면, 이는 해당 공격에 보다 취약해지는 것으로서, 일정 횟수 이상 오류가 발생했을 시에는 일정시간 인증이 불가능 하도록 하거나, 다른 인증 수단을 사용하도록 해야한다.

---

인가 취약점 케이스

인가 우회의 경우 파라미터 변조와 직접접근이 일반적인 전략이다.

1. 주석으로 접근 제한

(주석에 남겨진 페이지를 이용한다.)

주석 / css / display:none 등으로 구성하는 경우

주석이나 css와 같은 것들을 이용하여 특정 이용자에게만 특정 요소들이 보이도록 처리하는 경우에는, 주석 또는 속성을 제거하는 응답 변조를 통해 우회가 가능하다. 또한 주석 처리되어 있는 경로가 있는 경우, 해당 경로를 그대로 복사하여 주소창에 넣어 주는 경우에도 우회가 가능한 경우가 있다.

프론트엔드에서 너무 많은 것을 처리하려고 하면 문제가 있다는 반증이다.

[SegFault] (Authorization) - authorization 1

[SegFault] (Authorization) - authorization 1

 

2. 인가 확인을 클라이언트 측에서 하는 경우

(JS (클라이언트) 우회)

인가 확인(Check)을 클라이언트 측에서 하고 있는 경우에는 실행되는 자바스크립트(Javascript)로 찾아갈 수 있어야 한다. 실행되는 코드를 찾아내게 되면 분석을 통해 의도하지 않게 권한을 얻을 수도 있기 때문이다.

클라이언트 측에서 점검하는 것은 편의성을 위해서만 해야한다.

인증과 권한을 클라이언트 측에서 확인하는 경우 우회가 가능하다. 권한을 확인, 검사, 검증하는 것은 클라이언트(Client)측에서 할게 아니라 서버(Server) 측에서 처리해야한다는 것이다.

클릭했을 때, 권한을 누가 확인하는지를 봐야한다. 서버가 확인하는 것인지, 클라이언트 측에서 확인하는 것인지를 확인해야한다. 

버튼을 눌렀을 때 Burp에서 아무것도 뜨지 않는 다는 것은 서버로 가고 있는 요청이 없다는 것이다.

즉, 인가를 서버에서 처리하는 게 아니라는 것은 클라이언트가 체크하고 있는 것으로서 클라이언트(Client) 측 어딘가에 인가 여부를 판단하는 코드가 작성되어 있다는 것을 의미한다. 리버싱을 통해 해당 버튼을 눌렀을 때 어떤 Javascript가 실행되는지 확인해봐야 한다.

해당 페이지에서 함수가 선언되어 있는 곳이 없다면? Javascript에서 선언되어 있을 것이라는 생각을 해야한다. script의 로드를 확인해봐야 한다는 것이다.

[SegFault] (Authorization) - authorization 2

[SegFault] (Authorization) - authorization 2

[SegFault] (Authorization) - authorization 3

[SegFault] (Authorization) - authorization 3

 

3. 직접 접근 (기능페이지에 직접 접근)

직접 접근은 가장 일반적인 전략중에 하나로, 해당 경로로 직접적인 접근을 시도하는 경우에 우회가 가능한 경우이다.

[SegFault] (Authorization) - authorization 4

[SegFault] (Authorization) - authorization 4

[SegFault] (Authorization) - authorization 5

[SegFault] (Authorization) - authorization 5

 

4. 난독화 분석

난독화 되어 있다고 읽어내지 못하는 것이 아니다.

정적분석 : 실행하지 않고, 코드를 읽으면서 분석
동적분석 : (분기문을 중점으로)코드를 직접 실행해보면서 분석

 

5. Guessing 공격

가장 많이 나오는 케이스가 이것이다.

눈에 보이는 것이 전부는 아니기 때문에 숨겨진 디렉토리(Directory)나 Elements를 찾아내기 위해서 많이 사용되는 디렉토리 이름이나 URL의 파라미터들을 보고 "이런 경로이지 않을까?", "이런 파일이 있지 않을까?", "이런 파라미터의 경우 이런식으로 동작하지 않을까?" 등의 추측을 이용하는 것이다.

권한에 따라 (버튼이나 무언가가 있는) 페이지를 따로 만드는 것이 아니라 권한에 따라 눈에 안보이는 것이 많다는 것이다. 또한 경로, 이름, 등이 추측(Guessing)을 통해서 때려 맞히는 경우가 있다는 것이다.

즉, 추측을 통해 부여되지 않은 것처럼 보였던 기능(권한)을 얻게 될 수 있다는 것이다.

 

6. 파라미터 변조

인가 취약점을 다룰 때 자주 사용되는 방식으로 파라미터 변조를 통해 권한이 없는 페이지에 접근하는 것이 가능한 경우에 해당한다.

[SegFault] (Authorization) - authorization 6

[SegFault] (Authorization) - authorization 6

---

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