Insecure CAPTCHA이란
CAPTCHA는 사람과 컴퓨터를 구분하기 위해 사용하는 보안기술로 웹사이트에서 자동화된 봇의 무차별 공격을 방지하기 위해 사용됩니다.
공격자는 CAPTCHA에 존재하는 취약점을 활용하여 CAPTCHA를 우회하거나 무효화할 수 있습니다. 이는 웹 애플리케이션의 보안을 심각하게 손상시킬 수 있으며, 무차별 대입 공격이나 계정 탈취 시도에 취약해질 수 있습니다.
(참고) 요즘은 CAPTCHA보다는 cloudflare turnstile을 많이 활용하는 것 같습니다.
DVWA 실습으로 알아보기
참고로 해당 실습을 수행하기 위해서는 DVWA CAPTCHA 설정이 필요합니다.
CAPTCHA가 적용된 페이지가 어떻게 동작하는지 확인해 보겠습니다.
패스워드 변경을 하는 페이지로 보이며, 변경할 패스워드(test)를 입력하고, 캡챠버튼을 누르면
캡챠가 퀴즈를 냅니다.
퀴즈를 맞히고 change 버튼을 누릅니다.
CAPCHA에 통과했다는 창이 뜨고, 패스워드 변경을 확인한다는 의미로 change 버튼을 한 번 더 누르라고 하네요
패스워드가 바뀌었는지 로그아웃해 보고
변경된 패스워드(test)로 로그인을 다시 해보면, 로그인이 성공하는 것을 알 수 있습니다.
이번에는 내부적으로 어떤 패킷을 주고받는지 분석하기 위해 Burp Suite를 활용하겠습니다.
CAPTCHA 인증이 성공한 상태로 BurpSuite를 켭니다.
프록시 탭에 들어가 패킷 가로채기 켭니다.
Change 버튼을 누르면
패킷이 확인되고, 변경할 패스워드인 test가 해당 위치에 적인 것을 볼 수 있습니다.(step1이라는 단어를 기억해 둡시다.)
이후에 Forward 버튼을 눌러 해당 Request를 전송시키면
해당 페이지가 뜨게 되고, change 버튼을 누르면
패스워드를 test로 변경하겠다는 패킷이 확인됩니다.(step 2로 써져 있다)
대충 유추해 보면,
1. step1 패킷을 넘기면, 다음 페이지로 넘어가고
2. step2 패킷을 넘기면, 패스워드가 변경되는 구조로 보입니다.
따라서 바로 step2로 Request를 날리면 캡챠 없이 패스워드를 변경하는 우회가 가능할 수 있겠다고 유추가 가능합니다.
해당 패킷을 Repeater로 넘겨서 실제로 가능한지 실험해 봅시다.
그리고 Intercept on을 해제하고, Insecure CAPTCHA 초기화면으로 이동합니다.
패스워드를 hacked로 수정하고 패킷을 전송합니다.
로그인을 통해 확인 시, 패스워드가 hacked가 되어 로그인이 성공하는 것을 확인할 수 있습니다.
대응방안
위 실습에서 보면, step1의 CAPTCHA검증 없이 바로 step2의 패킷이 허용되는 것을 볼 수 있습니다.
해당 취약점이 존재하지 않도록 각 단계별 검증을 필수적으로 수행하도록 로직을 구현해야 합니다.