캡차 공격이란?
CAPTCHA라는 것은 컴퓨터가 알 수 없는 흘려 쓴 글씨를 입력받아서 사람인지 확인하는 것이다. 회원가입, 덧글 입력처럼 사림이 직접 하지 않는 경우 심각한 오류를 일으킬 수 있는 경우 사용한다. 이를 제대로 구현하지 않는 경우 해커가 이를 우회해서 공격할 수 있다.
[공격 시나리오]
비밀번호 변경이 [1단계] CAPTCHA로 정말 사람인지 확인 [2단계] 1단계 확인 후 비밀번호 변경 이 과정이 제대로 구현되지 않는 경우 CAPTCHA단계를 통과하여 2단계, 비밀번호를 변경할 수 있다.
[실습 방법]
Low Level
Proxy -> HTTP history -> Response -> Raw
password_new를 hacker라고 보내고 있다. recaptcha_challenge_field : 랜덤 생성이다.
recaptcha_response_field에 우리가 입력한 값이 들어간다.
step이 1이라는 것을 주목한다.
두 번째 요청에서 step이 2이다. 두 요청 모두 패스워드가 포함되어 전송된다.
그러면 첫 번째 요청은 생략하고 두 번째 요청만 보내면 어떻게 되는가?
두 번째 요청에서 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_field가 hidden이 아니거나 HTTP_USER_AGENT 필드가 리캡챠가 아니다 라는 조건이다.
이 값을 조작하자
패스워드 변경 요청을 Repeater로 보낸다.(위의 방법처럼) 캡차에서 요구하는 값은 랜덤으로 생성되기 때문에 옛날에 사용한 캡차 값을 전송하면 틀렸다고 나오는 것이다.
그렇다면 recaptcha_response_field값에다가 hidd3n_valu3 값을 입력하여 이 값으로 바꾼다.
USER_AGENT에 reCAPTCHA라고 입력한다.
요청을 한 단계로 만든 것은 좋은 대응이지만 if문으로 우회할 수 있는 코드를 만드는 것이 문제가 된다.
개발자가 디버깅을 편하게 하고자 할 때 문제가 발생한다. 이런 코드가 포함되지 않도록 조심해야 한다.
[공격 대응]
]
하이 단계에서 디버깅 조건을 제거했다.
페이지를 보면 CSRF공격을 대응할 때와 마찬가지로 현재 패스워드를 다시 한 번 입력하라고 나온다.
하이 단계처럼 한 번에 처리한다.
만약 요청을 여러 단계에 거쳐야 한다면 모든 단계를 정상적으로 거치도록 해야 한다.
