ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Bugbounty Study] #Account Takeover
    Study/Bugbounty Study 2021. 3. 6. 02:12

    # Account Takeover Due to Response Manipulation _ \$4100

    avanishpathak46.medium.com/an-account-takeover-vulnerability-due-to-response-manipulation-e23fe629bd1

     

    An Account Takeover Vulnerability Due to Response Manipulation.

    - No doesn’t necessarily mean no.! Responses can always be manipulated

    avanishpathak46.medium.com

    원작자는 해당 타겟 사이트에서 이전에도 Account Takeover 취약점을 발견한 이력이 있다.

    우선, 이전 글을 살펴보자.


    Account Takeover 취약점이란?
    공격자가 어플리케이션에 존재하는 인증 결함을 이용하여 아무런 자격 증명 없이 피해자의 계정을 무단으로 제어할 수 있는 취약점 중 하나이다.
    간단히, 계정 탈취가 가능한 취약점이다.

     

    타겟 사이트는 사용자가 등록한 이메일로 전송되는 4자리의 OTP코드를 입력하면 로그인하는 기능이 있다.
    OTP 길이가 짧아 Brute-force를 시도하였으나, 10번의 잘못된 요청을 보내면 일정 시간동안 요청 가능한 수가 제한되어 있어 HTTP 429 Too Many Requests를 응답하였다.

    또한, 이전의 응답 패킷에 OTP 코드가 노출되어 있는지 확인하였으나 찾을 수 없었다.

     

    올바른 OTP 코드를 입력하였을 때  /login/signin에서 발생하는 요청은 아래와 같다.

     

     

    {"email":"usermail@gmail.com", "code":XXXX} CORRECT OTP

     

    POST 요청은 이메일 주소이메일로 전송된 OTP 두 가지 파라미터를 포함한다.

    이때, 해당 파라미터의 이메일 주소를 다른 계정으로 하고, OTP 코드를 공격자의 이메일로 받은 값을 입력해주면 로그인된다. 이는 이메일과 OTP 코드가 느슨하게 연결되어 있고, OTP 코드가 유효한지만 검사하였기 때문이다.

     

    {"email":"admin@example.com", "code":XXXX} CORRECT OTP

     

    패치:

    타겟 사이트는 /login/singin에서 발생하는 요청에서 email 파라미터를 제거하고, 로그인을 시도하는 사용자에게 전송된 OTP인지 확인하는 작업을 추가하여 패치하였다.

     

    [참고]

    avanishpathak46.medium.com/an-interesting-account-takeover-vulnerability-a1fbec0e01a

     

    An Interesting Account Takeover Vulnerability

    - Login feature bypassed which leads to an Interesting Account Takeover

    avanishpathak46.medium.com


    본문으로 돌아와서 타겟 사이트의 로그인 흐름을 간단히 설명하면 아래와 같다.

    1. 타겟 서버가 4자리의 OTP 코드 이메일로 전송
    2. 받은 OTP 코드를 타겟 서버에 입력할 때만 사용자의 유효성 확인
    3. 유효한 코드를 가진 인증된 사용자만 사용자 계정 접근 허용 

     

     

    이전의 제보처럼 OTP의 길이가 짧아 Brute-force 공격이 가장 먼저 떠올랐으나, 타겟 사이트는 엄격한 속도 제한이 설정되어 있어 10번의 잘못된 시도를 할 경우, 마찬가지로 HTTP 429 Too Many Requests을 응답하였다.

    심지어 시간 지연 등 다양한 방법으로 Brute-force를 시도하였지만 같은 응답을 받았고, 응답에서 인증 코드 또한 노출되지 않아 어떤 것도 얻지 못하였다.

     

    정상적인 로그인 흐름을 살펴보기 위해 테스트 계정인 이메일로 로그인 요청 후 Burpsuite를 이용하여 요청 패킷을 잡아 살펴보고 저장한 다음 요청을 삭제하였다.

     

    잘못된 인증 코드를 입력하였을 경우를 살펴보니 401 Unauthorized error code를 응답받았다.

     

     

    다양한 시도 끝에 응답 body에 포함된 에러 응답인 {"code":"invalid_credentials"}에 주목하였고,

    해당 값을 이전에 저장해 둔 올바른 인증 코드의 응답 값으로 변경해보았다.

     

     

    HTTP/1.1 401 Unauthorized -----> HTTP/1.1 200 OK
    {"code":"invalid_credentials"} -----> {"verify":"true"}

     

     

    그 결과, Account Takeover이 되었다.

    이는 클라이언트 측 JavaScript가 수신한 응답을 기반으로 후속 요청을 발생시켜 새로운 세션 쿠키를 인증된 사용자로 설정하기 때문이다. (인증 검증은 서버 측에서 하는 것이 안전하다.)

     

     

    패치:

    로그인의 전체 흐름을 수정하였고, 클라이언트 측 JavaScript를 이용한 유효성 검사를 제거하였으며,

    응답에 대한 사용자 입력 값을 허용하지 않아 응답이 조작되었을 경우에는 오류 메시지를 표시하도록 패치하였다.

    댓글

@Jo Grini's Blog