모의해킹 스터디 16주차: 인증/인가

목차

• 인증, 인가란?
• 대표적인 인증 취약점 케이스
• 대표적인 인가 취약점 케이스
• 인증 취약점과 인가 취약점의 구분

 

 

 인증 / 인가 

 

1) 인증 (Authentication)

• 이 사람이 본인이 맞는지 확인하는 작업
• 비밀번호나 휴대폰 인증 OTP 번호 등이 이 과정에 쓰임

2) 인가 (Authorization)

• 특정 권한을 부여하거나 제한하는 일
• 예시: 본인이 올린 글만 삭제하거나 수정할 수 있게 함 등

 

 

   대표적인 인증 취약점 예시       

• 이 사람이 본인이 맞는지 확인이 제대로 되지 않음
• 인증 과정에서 발생

 

▷ 쿠키 등 클라이언트 측 정보를 통해 인증

 

♪   admin 계정으로 로그인하기

1) 로그인

2) 쿠키에 사용자 정보 저장 (User=doldol)

3) 쿠키 값 변조 (User=admin)

4) admin 계정으로 로그인 성공

로그인 인증 과정 넘어감

 

 

▷ 프로세스 점프

 

♪    핵미사일 발사 페이지에서 미사일 발사하기

1) 메인 페이지 -> 확인 버튼 클릭 -> 비밀번호 입력 -> 인증 성공 시 fire 버튼 나타남 -> 버튼 누르면 핵미사일 발사됨

2) 페이지 이름: index.php -> step1.php -> step2.php 이런 식

3) step3.php 요청

4) 비밀번호 인증 없이 핵미사일 발사 버튼 누를 수 있게 됨

비밀번호 인증 과정 생략

이전 프로세스에 대한 데이터 필요

 

 

▷ 파라미터 변조를 통한 직접 접근

 

♪    admin 계정으로 로그인하기

1) 정상 로그인

2) 로그인 성공 시 요청에 대한 응답에 {"result":"ok"}

3) admin 계정으로 로그인 시도 -> 응답 intercept

4) 응답의 "fail"을 "ok"로 변경 후 forward

5) admin 계정으로 로그인됐지만 로그인 페이지로 리다이렉션됨

6) 다시 시도하여 응답 인터셉트 후 인덱스 페이지의 리다이렉션 js 코드를 삭제

7) admin 계정으로 메인 페이지 접속 성공

로그인 시 일단 세션에 저장하고 id 인증 처리하는 프로세스가 문제 (정상: id 인증 후에 세션 저장) 세션에 저장하고 로그인 인증에 성공하면 ok 실패하면 fail 보내는데 ok를 받으면 메인 페이지로 리다이렉션시키는 듯 (그럼 자바스크립트 리다이렉션 코드는 서버에서 처리한 결과로 쓰는 건가?)

모바일 앱 취약점에서 많이 보임

 

 

▷ 인증 횟수 제한 없음

 

♪   OTP 번호 맞추기

1) 사용자에게 인증번호 4자리 발송

2) 무작위 대입 공격 (Brute Force Attack)으로 인증번호 맞을 때까지 시도함

3) 횟수 제한이 없어서 결국 4자리 번호를 맞춤

4) 인증 완료

"비밀번호 횟수 제한 미흡" 관련

로그인 페이지에선 횟수 제한을 둬도 마이페이지 등에선 횟수 제한을 안 두는 경우도 있음

 

 

 

   대표적인 인가 취약점의  예시       

• 권한이 인가되지 않았는데 접근 및 사용 가능
• 원래 못해야 하는 걸 할 수 있게 됨

 

▷ 클라이언트 측에서 접근 제한

 

♪   누를 수 없는 버튼 클릭하기

1) 일반 사용자 계정으로 로그인

2) 브라우저 화면에 버튼 보이지 않지만 응답 값에는 버튼 요소 보임

3) 응답을 intercept하여 주석 처리된 버튼 요소의 <!--주석 처리-->를 제거

4) forward하여 브라우저 화면에 출력된 버튼 클릭

5) 혹은 스크립트에 a 태그된 링크로 직접 접근도 가능

프론트엔드 단에서 사용자 인증을 구현해버린 케이스

백엔드에서 접근 제한해야함

 

 

▷ 클라이언트 측에서 권한 체크

 

♪   들어갈 수 없는 페이지 들어가기

1) 일반 사용자 계정으로 로그인

2) 권한 없다고 뜸

3) intercept 켜고 다시 버튼을 눌러 서버로 가는 요청이 있는지 확인

4) 없음. 현재 클라이언트 측에서 권한을 체크하는 중.

5) 버튼 누를 때 실행되는 자바스크립트 코드 찾아 로직 확인

6) 사용된 함수에 admin 파라미터를 넣어 콘솔에 실행

7) 혹은 href된 주소로 직접 접근

8) 혹은 응답 intercept하여 버튼 onclick 핸들러에 admin 파라미터 추가한 뒤 forward, 브라우저에서 버튼 클릭 

백엔드에서 권한 체크하고 프론트에선 결과 통보만 해야함

 

[+] 코드가 난독화되었을 경우 복구시키든가 동적 분석을 진행해야함

-> 복구: 툴 등 사용

-> 동적 분석: if문 등을 기점으로 이렇게 저렇게 실행시켜보며 뭘 하는 함수인지 알아냄

 

 

프론트에서 다뤄야하는 기능

클라이언트 측에서는 됐다, 안됐다, 형식 이상하다 등의 편의성만 체크해야함.

권한이나 본인 인증 등을 클라이언트 측에서 체크하는 경우 다 우회됨.

 

▷ Guessing 공격

• 지인짜 자주 만나는 케이스라고 함
• 버튼이나 기능이 서버측의 필터링으로 안보인다면 추측해서 공격

♪   게시글을 쓸 수없는 게시판에 글쓰기

1) 사이트의 게시글 관련 페이지 이름을 둘러봄

2) notice_list.php, notice_read.php 이런 꼴임

3) notice_write.php로 시도해서 url 직접 접근

4) 게시글 작성 후 업로드 성공

 

♪   읽을 수 없는 게시글 읽기

1) 게시글 작성

2) 게시글 읽기 페이지에서 게시글 id 파라미터 변조 -> 실패

3) SQLi 으로 게시글 불러오기 -> 실패

4) 게시글 수정 페이지 들어가서 id 값 변조 -> 성공

게시글 읽기 페이지에선 인가 과정이 적절히 이루어져도 게시글 수정 페이지에서는 허점이 있을 수 있음

당사자만 해당 페이지 접근할 수 있게 제한하는 코드 추가

 

 

▷ 파라미터 변조 다양한 유형

• 인가 취약점에서 자주 보이는 기법
• 내가 이 파라미터에 a를 넣으면 어떤 값이 나오겠구나 생각하면 인가 취약점 많이 접할 수 있음
• 이거 테스트할 땐 내가 작성한 글을 대상으로 할 것. (계정 2개 필요)

♪  파라미터 변조로 다른 사람 개인정보 확인

1) 로그인

2) 마이페이지 접근

3) 요청 데이터의 쿠키 헤더 확인. User=sfUser

4) sfUser를 admin으로 수정한 뒤 재요청 -> 성공

해당 파라미터를 기준으로 데이터 조회하는 중

수정할 수 없는 데이터로 식별해아함

 

 

인가 취약점은 무엇보다 경험이 중요

개발 많이 해보든가 플젝 많이 나가보든가 사례를 많이 알고 있을 수록 좋음

 

 

 

   인증 / 인가 구분하기       

컨설턴트 주관에 따름

 

1) 인증: 야가 갸다.

2) 인가: 님 이거 ㄱㄴ. 아니 님 말고.

 

• 문제:

인증 취약점 케이스에서 다뤘던 핵미사일 발사 문제처럼 헷갈리는 경우가 있음.

 

이 문제의 경우 접근할 수 없는 기능에 접근할 수 있게 하기 때문에 인가 취약점으로 보는 컨설턴트도 있을 것이고 인증 과정을 뛰어넘었기 때문에 인증 취약점으로 잡는 컨설턴트도 있을 것

 

혹은 단계를 나눠서 페이지를 넘는 건 인증 취약점으로 잡고 발사 버튼을 누르는 건 인가 취약점으로 보는 컨설턴트도 있음

 

• 결론:

이건 뭐가 맞다 틀리다 문제가 아니라 주관에 맞춰 설명할 수 있으면 되는 일임.

 

• 노말틱님의 관점:

노말틱님은 핵미사일 발사 문제의 대응이 인증 과정을 추가하는 거라고 보셨기 때문에 인증 취약점으로 잡으심.

이 기준은 대응까지 자연스럽게 연결할 수 있어서 무엇보다 타인에게 설명하기가 좋아보임.

 

 

 

   그와는 별개로 핵미사일 발사 문제는 딱 나누기 어려운 케이스로 보이긴 함.

   발사를 막아도 비밀번호 입력 칸을 넘길 수 있다면 인증 과정에서 일어난 인증 취약점임. 달리 말하면 비밀번호 입력 칸을 넘길 수 없게 해도 발사 버튼을 누를 수 있다면 인가 취약점이 될 것임.

   하지만 어쨌거나 인증 과정이 포함된 취약점이기도 하고 그 인증 데이터를 토대로 발사 버튼에 대한 접근을 제한해야할 거 같아서 나도 인증 취약점 케이스에 한 표를 던져봄...