Covenant

본 포스트는 https://www.udemy.com/의 강좌 화이트헤커가 되기 위한 8가지 웹 해킹 기술 강좌를 바탕으로 작성했습니다.



캡차 공격이란?

 CAPTCHA라는 것은 컴퓨터가 알 수 없는 흘려 쓴 글씨를 입력받아서 사람인지 확인하는 것이다. 회원가입, 덧글 입력처럼 사림이 직접 하지 않는 경우 심각한 오류를 일으킬 수 있는 경우 사용한다. 이를 제대로 구현하지 않는 경우 해커가 이를 우회해서 공격할 수 있다.

 

[공격 시나리오]

비밀번호 변경이 [1단계] CAPTCHA로 정말 사람인지 확인 [2단계] 1단계 확인 후 비밀번호 변경 이 과정이 제대로 구현되지 않는 경우 CAPTCHA단계를 통과하여 2단계, 비밀번호를 변경할 수 있다.


 

[실습 방법]

Low Level

Proxy -> HTTP history -> Response -> Raw

 

password_newhacker라고 보내고 있다. recaptcha_challenge_field : 랜덤 생성이다.

 

recaptcha_response_field에 우리가 입력한 값이 들어간다.

 

step1이라는 것을 주목한다.

 

두 번째 요청에서 step2이다. 두 요청 모두 패스워드가 포함되어 전송된다.

 

그러면 첫 번째 요청은 생략하고 두 번째 요청만 보내면 어떻게 되는가?

 

두 번째 요청에서 Send to Repeater를 누르고 -> Repeater -> password_new, password_conf에 비밀번호 설정

 

GO를 누르고 Response에서 Render를 누르면 비밀번호가 바뀌었다는 것이 보인다.

 

 

Medium Level

Low level과 마찬가지로 새로운 비밀번호를 입력하고 캡차를 입력한다.


step2가 나온다. 한 가지 추가된 것은 passed_captcha를 이용해서 captcha가 바르게 전송이 되었는지 확인한다.

그러나 여전히

두 번째 요청에서 Send to Repeater를 누르고 -> Repeater -> password_new, password_conf에 비밀번호 설정

 

GO를 누르고 Response에서 Render를 누르면 비밀번호가 바뀌었다는 것이 보인다.

Low 단계와 마찬가지로 쉽게 공격할 수 있다.

 

High Level

이번에는 두 단계를 거치지 않고 바로 변경 된다.

다만 소스코드에서 문제가 있다


캡챠가 실패했을 때 if문이 있다. 응답이 valid하지 않으면 뒤에 추가 조건을 검사하고 있다.

recaptcha_response_fieldhidden이 아니거나 HTTP_USER_AGENT 필드가 리캡챠가 아니다 라는 조건이다.

이 값을 조작하자

 

패스워드 변경 요청을 Repeater로 보낸다.(위의 방법처럼) 캡차에서 요구하는 값은 랜덤으로 생성되기 때문에 옛날에 사용한 캡차 값을 전송하면 틀렸다고 나오는 것이다.


그렇다면 recaptcha_response_field값에다가 hidd3n_valu3 값을 입력하여 이 값으로 바꾼다.

USER_AGENTreCAPTCHA라고 입력한다.

 

요청을 한 단계로 만든 것은 좋은 대응이지만 if문으로 우회할 수 있는 코드를 만드는 것이 문제가 된다.

개발자가 디버깅을 편하게 하고자 할 때 문제가 발생한다. 이런 코드가 포함되지 않도록 조심해야 한다.

 


[공격 대응]

]


하이 단계에서 디버깅 조건을 제거했다.

페이지를 보면 CSRF공격을 대응할 때와 마찬가지로 현재 패스워드를 다시 한 번 입력하라고 나온다.

하이 단계처럼 한 번에 처리한다.

만약 요청을 여러 단계에 거쳐야 한다면 모든 단계를 정상적으로 거치도록 해야 한다.