Account Takeover

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

Authorization Issue

계정의 이메일을 변경하려 시도하고, 확인 프로세스를 반드시 검사해야 합니다. 만약 취약한 것으로 판명되면 이메일을 공격 대상의 이메일로 변경한 뒤 확인하세요.

Unicode Normalization Issue

  1. 공격 대상의 계정 victim@gmail.com
  2. 유니코드를 사용하여 계정을 생성해야 합니다\ 예: vićtim@gmail.com

As explained in this talk, the previous attack could also be done abusing third party identity providers:

  • third party identity에 victim과 비슷한 이메일을 일부 유니코드 문자를 사용해(vićtim@company.com) 계정을 생성합니다.
  • The third party provider shouldn’t verify the email
  • If the identity provider verifies the email, maybe you can attack the domain part like: victim@ćompany.com and register that domain and hope that the identity provider generates the ascii version of the domain while the victim platform normalize the domain name.
  • Login via this identity provider in the victim platform who should normalize the unicode character and allow you to access the victim account.

For further details, refer to the document on Unicode Normalization:

Unicode Normalization

Reusing Reset Token

만약 대상 시스템이 reset link를 재사용할 수 있게 허용한다면, gau, wayback, scan.io 같은 도구를 사용해 더 많은 reset link를 찾도록 노력해야 합니다.

Pre Account Takeover

  1. 피해자의 이메일을 사용해 플랫폼에 가입하고 비밀번호를 설정해야 합니다(확인을 시도해야 하지만 피해자의 이메일 접근 권한이 없으면 불가능할 수 있습니다).
  2. 피해자가 OAuth로 가입하여 계정을 확인할 때까지 기다립니다.
  3. 일반 가입이 확인되면 피해자의 계정에 접근할 수 있게 되기를 기대합니다.

CORS Misconfiguration to Account Takeover

페이지에 CORS misconfigurations가 있으면 사용자의 민감한 정보를 탈취하여 그의 계정을 takeover하거나 같은 목적을 위해 인증 정보를 변경하게 만들 수 있습니다:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

페이지가 CSRF에 취약하면 사용자가 비밀번호, 이메일 또는 인증 정보를 변경하도록 만들어 이후에 접근할 수 있습니다:

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

애플리케이션에서 XSS를 찾으면 cookies, local storage 또는 웹페이지에서 정보를 탈취하여 계정을 takeover할 수 있습니다:

XSS (Cross Site Scripting)

Same Origin + Cookies

제한된 XSS나 서브도메인 takeover를 발견하면 cookies를 조작(예: 고정화)하여 피해자 계정을 침해하려 시도할 수 있습니다:

Cookies Hacking

Attacking Password Reset Mechanism

Reset/Forgotten Password Bypass

Security-question resets that trust client-supplied usernames

If an “update security questions” flow takes a username parameter even though the caller is already authenticated, you can overwrite any account’s recovery data (including admins) because the backend typically runs UPDATE ... WHERE user_name = ? with your untrusted value. The pattern is:

  1. 임시 사용자로 로그인하고 세션 쿠키를 캡처합니다.
  2. 리셋 폼을 통해 피해자 username과 새로운 답변을 제출합니다.
  3. 방금 주입한 답변을 사용해 security-question 로그인 엔드포인트를 통해 즉시 인증하여 피해자의 권한을 획득합니다.
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

Anything gated by the victim’s $_SESSION context (관리자 대시보드, 위험한 stream-wrapper 기능 등)은 실제 인증정보를 건드리지 않고도 노출됩니다.

열거된 사용자명은 위의 overwrite 기법으로 타겟팅되거나 FTP/SSH password spraying 같은 보조 서비스에 재사용될 수 있습니다.

Response Manipulation

인증 응답을 단순한 boolean으로 축소할 수 있다면, false를 true로 변경해 접근이 가능한지 확인해보세요.

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. 비밀번호 재설정 요청을 시작한 후 Host 헤더가 변경됩니다.
  2. X-Forwarded-For 프록시 헤더를 attacker.com으로 변경합니다.
  3. Host, Referrer, Origin 헤더를 동시에 attacker.com으로 변경합니다.
  4. 비밀번호 재설정을 시작한 뒤 메일 재전송을 선택하면 앞서 언급한 세 가지 방법이 모두 사용됩니다.

Response Manipulation

  1. Code Manipulation: 상태 코드를 200 OK로 변경합니다.
  2. Code and Body Manipulation:
  • 상태 코드를 200 OK로 변경합니다.
  • 응답 본문을 {"success":true} 또는 빈 객체 {}로 변경합니다.

이러한 조작 기법들은 JSON을 통해 데이터 송수신이 이루어지는 경우에 효과적입니다.

Change email of current session

출처: this report:

  • 공격자가 자신의 이메일을 새 주소로 변경 요청합니다.
  • 공격자는 이메일 변경 확인 링크를 받습니다.
  • 공격자는 그 링크를 피해자에게 보내 피해자가 클릭하게 합니다.
  • 피해자의 이메일이 공격자가 지정한 주소로 변경됩니다.
  • 공격자는 비밀번호를 복구하고 계정을 탈취할 수 있습니다.

This also happened in this report.

Bypass email verification for Account Takeover

  • 공격자가 attacker@test.com으로 로그인하고 회원가입 시 이메일을 검증합니다.
  • 공격자가 검증된 이메일을 victim@test.com으로 변경합니다(이메일 변경에 대한 추가 검증 없음).
  • 이제 사이트는 victim@test.com으로 로그인을 허용하므로 피해자 사용자의 이메일 검증을 우회했습니다.

Old Cookies

자세한 내용은 in this post에 설명되어 있듯이, 계정에 로그인한 상태에서 쿠키를 저장하고 로그아웃한 다음 다시 로그인하면,
새 로그인에서 다른 쿠키가 생성되더라도 이전 쿠키가 다시 작동했습니다.

References

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기