[Bugbounty Study] #Bugcrowd _ CSRF

# CSRF / Account Takeover

https://ladysecspeare.wordpress.com/2020/04/05/how-a-simple-csrf-attack-turned-into-a-p1-level-bug/

How a Simple CSRF Attack Turned into a P1 Level Bug

※ 해당 취약점은 Bugcrowd의 비공개 버그헌팅으로, 타겟을 공개하지 않았다.

 

CSRF란?
Cross-site Request Forgery의 약자로, 공격자가 피해자의 의도하지 않은 행동을 수행하도록 하는 공격

[예방 방법]
-  CSRF 방지 Token 사용
-  추가 필드 사용 (ex. 현재 비밀번호 입력, 캡챠)
-  같은 사이트 쿠키 사용
-  Referrer 검증
-  Double Submit Cookie 검증*

 

CSRF 공격을 수행할 공격 포인트를 찾기 시작하였고, 효과적인 비밀번호 변경 옵션을 발견하였다.
비밀번호 변경을 클릭하면 아래 필드는 HTTP요청으로 전송된다.

 

피해자의 비밀번호를 변경할 때 공격자의 메일주소가 포함되어 작동하지 않았고,

피해자의 메일주소 값을 전송해주어야만 비밀번호 변경이 가능하였다.

 

따라서,

공격자는 악의적인 링크를 피해자에게 보낼 때,

피해자가 해당 링크를 클릭해 속이기 전에 피해자의 메일 주소를 사용하여야 한다.

 

해당 글의 원작자는 이 공격의 Impact를 높이기를 원했고, 아래와 같은 방법을 시도하였지만 효과가 없었다.

 

-  CSRF POC의 전체 필드 제거
-  필드의 값만 제거
-  필드에 임의의 랜덤 값 삽입 (ex. ajhgdsjhgd)

 

타겟 서버가 고급 CSRF 공격을 보호한다는 생각을 버렸고,

메일 형식을 맞춘 임의의 값으로 메일 값을 변경하는 것을 시도하였다. 이때, 유효한 이메일일 필요는 없다.

(ex. abcdefg@xyz.com)

 

피해자 계정의 다른 브라우저에서 임의의 메일 값으로 Submit을 클릭하였더니 아래와 같은 메시지를 받았다.

 

변경된 새로운 암호로 피해자 계정의 로그인을 시도하였더니, 성공적으로 로그인되었다.

 

[Impact]

해당 시나리오를 통해 메일 값을 피해자의 유효한 주소로 변경하지 않고,

피해자의 계정을 탈취할 수 있다. 또한, 링크 클릭만으로 피해자의 계정이 잠기게 되므로 심각성이 높아졌다.

 

Bugcrowd는 완벽한 계정 탈취 문제인 이 간단한 CSRF를 P1*으로 평가하였다.

 

[Why this was possible?]

서버단에서 메일 필드에 대한 유효성을 검증하지 않기 때문이다.

따라서, 필요한 검증이 반드시 이루어지도록 해야 한다.

 

[취약점에서 배울 점]

CSRF 공격을 시도할 때,

서버단에서 유효성 검사를 하지 않는다고 가정하고 랜덤 값도 삽입해보아야겠다.

 

---

*Double Submit Cookie 검증:

Security Token 검증의 한 종류로 세션을 사용할 수 없는 환경에서 사용할 수 있는 방법으로,

서버에 Token 값을 저장하지 않기 때문에 세션 검증보다 가벼운 방법이다.

 

- 특정 수행을 요청할 경우 스크립트를 통해 임의의 난수를 생성하여 쿠키에 저장
- 동일한 난수를 요청 파라미터(또는 헤더)에 저장하여 전송
- 서버에서 두 값이 동일한지 확인하여 검증

 

*P1 Level Bug:

Priority 1을 나타내는 것으로, 우선순위 1인 결함을 뜻하므로 즉시 수정해야 하는 중요한 버그이다.

숫자가 높을수록 취약점의 심각도가 낮으며, 회사마다 다른 단어로 표시할 수 있다.

[참고] https://webkit.org/bug-prioritization/