[DVWA] insecure CAPTCHA

안녕하세요 Retain0입니다. 이번 시간에는 " DVWA "라는 취약한 웹 애플리케이션을 통한 insecure CAPTCHA 공격을 해보도록 하겠습니다.

 

CAPTCHA 란

• Completely Automated Public Turing test to cell Computer and Humans Apart의 약자로 접근하고자 하는 대상이 실제 사용자인지 아니면 컴퓨터 프로그램인지 를 구별하기 위해 사용되는 방법입니다. 회원가입이나 비밀번호변경등 사람이 아닌 다른 무언가가 쉽게 변경하게 된다면 보안적인 측면에 있어서 큰 문제가 발생할 수 있기 때문입니다. 또한 대상 서비스에 대한 정보 또는 계정을 획득하기 위한 자동화 공격의 방어에 있어서도 효과적이기에 대부분의 사이트에는 CAPTCHA 기능이 구현되어 있습니다. (구글은 CAPTCHA 에서 비롯된 reCAPTCHA를 인수하여 현재까지 널리 사용되고 있습니다.)

하지만 이러한 CAPTCHA 기능이 제대로 구현되어 있지 않다면 우회가 가능하다는것을 확인해 보도록 하겠습니다. 실습을 위해선 " DVWA 가 구현된 환경에서 google 을통해 CAPTCHA 키를 받아서 등록해놔야 됩니다. 등록법은 유튜브나 구글링을 하시면 금방 나올 겁니다.

 

① LOW

 

(사진 1) 대상 폼

(사진 1) 우선 패스워드를 변경하면서 reCAPTCHA를 클릭 후의 정보를 프록시 도구를 통해 먼저 잡아서 확인해보도록 하겠습니다. 패스워드는 기억하기 쉬운 패스워드로 변경하시면 됩니다.

(사진 2) 프록시 화면

(사진 2) retain0라는 패스워드를 변경 후 reCAPTCHA를 인증후 의 모습입니다. 검정 박스의 g-recapcha-response 에 많은 값들이 있는데 이는 CAPTCHA 를 확인할 때 랜덤으로 생성되는 난수 들입니다. 그리고 step=1이라는 부분은 우선 기억해두겠습니다.

※ 그 전에는 recaptcha-challenge-field라는 매개변수 가 있었지만 현재는 g-recaptcha-response로 변경되었습니다.

(사진 3) 패스워드 변경

프록시도구의 Forward 를 통해 다시 보내주면 Password Changed 라는 문구와 함께 정상적으로 패스워드가 변경 된것을 확인 할수 있습니다. 그후 프록시 상태를 다시 확인하겠습니다.

(사진 4) 변경후 프록시 모습

(사진 4) 정상적으로 변경된 것을 확인하고 " history " 탭에서 변경 후의 상태를 확인해보니 step=2로 변경된 것을 확인할 수 있습니다. (사진 2)의 step=1과 현재의 step=2의 공통점은 사용자가 변경하고자 하는 패스워드가 모두 암호화되어있지 않고 평문으로 담겨있다는 것입니다.

즉 CAPTCHA 기능을 우회하기 위해 변경하고자 하는 패스워드 + 인증이 끝나 후의 값인 step=2 값으로 변경해서 전송해주면 손쉽게 변경이 가능해집니다.

(사진 5) LOW 레벨 우회

(사진 5)를 보시면 공격자는 " hacker "라는 값으로 CAPTCHA를 우회하여 패스워드를 손쉽게 변경시킬 수 있게 됩니다. step=2의 파라미터는 step=1과 마찬가지로 변경하려는 패스워드를 담고 있지만 step=2는 CAPTCHA를 인증한 상태에서 받는 파라미터 값이기에 손쉽게 우회가 된 것입니다.

 

---

② Medium

(사진 6) 재시도 실패

(사진 6) LOW 단 게에서 했던 방식으로 임의 값 retain0로 패스워드를 변경하고 캡챠 버튼까지 클릭하였습니다. 최종 변 Password Change 같은 문구가 뜬것까지 확인 후 reCAPTCHA 인증 전 후를 비교해보도록 하겠습니다.

(사진 7) 인증 전

(사진 8) 인증 후

(사진 7,8)을 비교해 보시면 마찬가지로 변경하고자 하는 패스워드가 동일하게 노출이 되고 step=1 이 인증 전 step=2 가 인증 후라는 패턴을 쉽게 알 수 있습니다. 하지만 새로운 매개변수가 생겼습니다. passed_captcha=true라는 것을 통해 step=2에서도 인증을 정상적으로 거쳤는지 재확인하는 개념이라 생각하시면 됩니다. 어차피 값은 true 또는 false 둘 중 하나일 것이므로 쉽게 유추하여 우회가 가능할 것으로 보입니다.

(사진 9) Medium 우회

(사진 9) 인증을 거친 후의 값인 step=2와 변경하고자 하는 임의 패스워드, 마지막으로 step=2를 무사히 거쳤다는 것을 위조하기 위한 passed_captcha=true로 넣고 전송해보면 성공적으로 변경된 것을 확인할 수 있습니다.

 

---

③ High

(사진 10) 패스워드 변경

(사진 10) 일단 패스워드를 그냥 변경해보도록 했습니다. 다른 점은 2단계가 없이 한 번에 바뀐다는 점입니다.

(사진 11) history 값 확인

(사진 11) 패스워드 변경 후 버프수트의 history 탭에서 확인해보도록 하겠습니다. 변경 후에도 step=1 인 것을 보아 확실히 검증을 2단계로 나눠서 하지 않고 있습니다. 또한 user_token이라는 매개변수 가 추가되서 전달이 되고 있습니다. 일단 소스코드를 확인해보도록 하겠습니다.

(사진 12) High 소스코드

(사진 12) 소스코드를 확인해 본 결과 resp라는 참값에 2가지의 조건이 있습니다. 하지만 여기서 문제는 " || " 파이프 기호입니다. 이 의미는 OR 연산을 하겠다는 것입니다. 그렇기에 최상단 소스에 자리 잡힌 reCAPTCHA 인증을 하지 않아도 resp에 속한 변수값만 충족해도 참값이 될 수 있다는 것입니다.

(사진 13) High 우회

(사진 13) history에 있는 대상을 reapter 탭으로 가져와 OR 연상에 맞게끔 resp의 참 값을 충족시켜주면 됩니다.

(1) User-Agent: reCAPTCHA

(2) g-recaptcha-response=hidd3 n_valu3

로 맞춰준후 변경하고자 하는 패스워드를 입력하면 우회가 되는 것을 확인하실 수 있습니다.

 

---

◆ 대응방안

Impossible 레벨 소스코드

소스코드를 확인해보시면 High 레벨 단계에서 존재했던 구문은 사라져 있고 현재의 패스워드를 추가적으로 입력해야 하는 폼을 추가하였습니다. 이는 즉슨 reCAPTCHA 기능을 우회하였다 하더라도 기존에 존재하던 패스워드를 입력해야 변경할 수 있으므로 reCAPTCHA를 우회한다는 건 사실상 힘들어졌다고 볼 수 있겠습니다. 또한 이러한 기법은 추후 배워볼 CSRF(Cross Site Request Forgery)의 대응방안 중 하나 이기도 합니다.

Low Medium 단계처럼 여러 단계를 거쳐 전송을 하게 되면 전과 후의 값 비교를 통해 우회가 가능해질 수 있으므로 1단계에서 끝내는 것이 좋습니다. 만일 여러 단계를 거쳐서 인증을 해야 한다면 Impossible 단계처럼 추가적으로 인증을 다시 할 수 있는 방법을 모색해두어야 합니다.