
AI로 생성한 주제 설명용 이미지입니다.
- 원문: arXiv 2609.18518
- 저자: Suphannee Sivakorn, Samantha Gottlieb
- 공개일: 2026-09-16 (arXiv v1, ISC 2026)
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
reCAPTCHA의 visual fallback은 더 이상 “사람만 풀 수 있는 문제”라는 보안 가정을 충족하지 못한다. 무료 local CLIP·OWLv2 조합이 별도 학습 없이 실제 500개 session에서 92.6% 통과했고, 자연어 skill만 사용한 범용 multimodal assistant도 offline Type A 95.5%를 기록했다.
중요한 구분은 local solver와 prompt-only solver다. 제목의 zero cost는 API 과금이 없는 local model 경로에 해당하며, Claude 기반 prompt-only 경로는 구독·지연 비용이 있고 정식 online 성공률도 보고되지 않았다.
연구 배경
reCAPTCHA v2는 낮은 신뢰도의 사용자를 visual challenge로 보내고, v3도 위험 점수가 낮으면 fallback으로 이를 사용할 수 있다. 행동 기반 평가가 bot을 의심해 challenge를 제시해도 그 challenge 자체를 자동화가 쉽게 풀면 마지막 방어선이 약점이 된다.
기존 solver는 특정 13개 class로 학습한 YOLO나 유료 cloud VLM에 의존했다. 연구진은 open-vocabulary zero-shot model로 임의 keyword를 처리하고 local hardware에서 비용 없이 구동할 수 있는지를 측정했다.
공격 모델 / 전제 조건
공격자는 fresh browser에서 visual challenge를 받으며 Google 계정 평판이나 기존 cookie를 사용하지 않는다. Selenium이 nested iframe을 탐색해 instruction, keyword, tile image를 추출하고 모델 예측에 따라 click·submit·retry를 수행한다.
Type A는 독립 3×3 tile이며 static 또는 클릭 후 이미지가 바뀌는 dynamic 변형이 있다. Type B는 한 사진을 4×4로 자른 grid다. 공격자는 challenge session 만료 약 2분 안에 일련의 문제를 해결해야 한다.
비판적 검토 / 아쉬운 점
첫째, offline threshold와 모델 선택에 같은 1,000개 labeled dataset을 사용해 사실상 evaluation set에 맞춘 calibration이 포함된다. “학습 없음”은 맞지만 완전한 사전 고정 zero-shot 평가와는 다르다. 별도 시기·지역·keyword의 blind test가 필요하다.
둘째, online 500 session의 도메인 분포, challenge 수, risk-score 변화가 Google backend 정책에 따라 달라질 수 있다. 실제 success가 모델 정확도뿐 아니라 retry 허용·human ambiguity tolerance에 영향을 받으므로 다른 네트워크·브라우저·시점 반복이 필요하다.
셋째, “zero-code barrier”는 과장될 여지가 있다. prompt-only online 경로는 연구진이 제공한 Selenium automation script를 자연어 skill이 구동하는 구조이며, 느린 조건에서 모든 실패가 timeout이었다. 비기술 사용자가 자연어만으로 처음부터 전체 harness를 재현했다는 증명은 아니다.
핵심 Root Cause
깨진 보안 불변조건은 “visual object recognition의 계산 난이도가 사람과 자동화를 구분한다”는 가정이다. open-vocabulary vision model이 challenge 의미를 충분히 이해하고, 서버가 오답·재시도에 인간 친화적 관용을 주면서 낮은 1회 정확도도 높은 session 성공률로 증폭된다.
행동 기반 risk와 visual fallback도 독립 방어층으로 결합되지 않는다. bot으로 의심된 세션이 자동화 가능한 challenge로 결정적으로 전환되므로 fallback이 오히려 예측 가능한 공격 경로가 된다.
핵심 공격 원리
Type A는 tile별 CLIP image-text similarity를 계산해 keyword와 임계값 이상인 tile을 고른다. Type B는 OWLv2가 전체 이미지에서 object bounding box를 찾고 각 grid cell과의 overlap이 10% 이상이면 선택한다.
prompt-only 방식은 multimodal assistant가 tile의 구체 물체를 먼저 설명한 뒤 keyword 포함 여부를 판단한다. Type B에서는 보이는 흔적이 조금이라도 있으면 선택하게 해 경계 tile 누락을 줄인다.
공격 흐름
- fresh unauthenticated Chrome session에서 checkbox를 누른다.
- challenge iframe에서 keyword와 tile 이미지를 수집한다.
- Type A/B와 dynamic 여부를 판별한다.
- CLIP, OWLv2 또는 multimodal skill로 tile index를 예측한다.
- Selenium이 tile을 클릭하고 제출한다.
- dynamic refresh나 추가 challenge가 나오면 session 만료 전 반복한다.
성공 조건 / 실패 조건
성공에는 visual challenge 노출, DOM·screenshot 접근, 충분한 retry budget, 모델이 지원하는 object category, session 만료 전 추론이 필요하다. local solver는 한 challenge를 1초 이내 처리해 시간 조건에 유리하다.
Type B 경계 object, OWLv2가 감지하지 못한 crosswalk, dynamic tile refresh, 높은 challenge volume은 실패를 늘린다. prompt-only solver는 평균 38.4~83.7초, 최악 276.9초라 정확한 예측도 제출 전에 만료될 수 있다.
연구진의 실험 환경
fresh·비로그인 browser로 실제 사이트에서 1,000개 challenge를 수집해 사람이 정답을 표시했다. Type A 662개, Type B 338개이며 13개 keyword를 포함한다. 모든 실험은 dedicated GPU 없는 consumer laptop에서 수행됐다.
offline은 모든 정답 tile을 고르고 오답을 하나도 고르지 않은 exact match로 평가했다. prompt-only Type A와 B는 각각 200개 표본을 사용했고, online local solver는 실제 reCAPTCHA 500 session을 평가했다.
주요 실험 결과
Type A에서 CLIP ViT-B/32 345/662(52%), ViT-L/14 374/662(56%), ViT-H/14 387/662(58%)였다. Type B에서 OWLv2는 147/338(43.5%), tile별 CLIP은 12.7%였다. OWLv2는 crosswalk 0%인 반면 bus 72.7%, taxi 75%로 class 편차가 컸다.
prompt-only Sonnet 5는 Type A 191/200(95.5%), Type B 101/200(50.5%)였다. local online solver는 500 session 중 92.6%를 통과했고, Type B가 0%인 session은 218개 중 99.5%, Type B가 절반 이상이면 85.8~88.4%였다. 성공 session 평균 시간은 81초, 실패는 282초였다.
실제 발견된 취약점 / 사례
새 CVE가 부여된 소프트웨어 버그라기보다 reCAPTCHA visual challenge의 설계 가정 붕괴를 실증한 연구다. 연구진은 2026-09-06 Google Bug Hunters에 issue 557908167로 disclosure했다.
계정 생성·credential stuffing·form abuse에서 visual challenge만 자동화 억제의 핵심으로 쓰는 사이트가 실제 영향 범위다. 단, 사이트별 rate limit·device reputation·추가 MFA까지 우회됐다는 의미는 아니다.
저자 주장 vs 실제 증명 범위
무료 local model이 500개 live session에서 92.6%를 기록했다는 주장은 직접 측정됐다. 반면 5회 독립 retry로 94.3~98.7%가 된다는 값은 단순 확률 모델이며 실제 측정 success가 아니다.
prompt-only 접근이 비기술적 공격자의 진입 장벽을 낮춘다는 정성 주장은 설득력 있지만, online formal success rate는 latency와 작은 검증 규모 때문에 보고되지 않았다. 따라서 local solver 결과와 prompt-only 결과를 합쳐 “자연어만으로 92.6%”라고 표현하면 잘못이다.
기존 공격 / 기존 점검 방식과의 차이
기존 YOLO solver는 CAPTCHA class에 맞춘 14,000개 labeled image와 고정 class가 필요했다. 이 연구의 CLIP·OWLv2는 별도 fine-tuning 없이 keyword를 받아 처리하고 local에서 실행된다.
또 offline image accuracy만 보지 않고 fresh reputation 조건의 end-to-end session을 측정했다. strict offline accuracy가 43.5~58%인데 live session이 92.6%인 차이는 실제 acceptance와 retry 정책이 공격자에게 유리함을 보여준다.
연구의 한계와 주의해서 볼 부분
수집 데이터가 13개 keyword와 mid-2026 정책에 한정되고 Google의 adaptive risk system 내부는 알 수 없다. session·challenge가 독립이라는 보장도 없으므로 단순 retry 수학을 운영 예측으로 쓰면 안 된다.
연구가 visual fallback을 깨뜨렸다고 해서 reCAPTCHA v3의 behavioral score 전체를 우회한 것은 아니다. 실제 사이트 위험 평가는 visual solve 이후 server-side token 검증, rate limit, 계정 보호를 함께 봐야 한다.
공개 PoC / Exploit / Tool / Artifact 분석
공식 GitHub 저장소는 2026-09-18 현재 공개 접근 가능하다. dataset/에 1,000개 labeled challenge, reCAPTCHA-solver/SKILL.md에 offline prompt-only 분류 지침, scripts/validate.py에 schema 검사가 있다.
중요하게도 end-to-end online solver와 source code는 오용 방지를 위해 공개하지 않았다. 따라서 공개 자료는 image classification 결과를 검증할 수 있는 dataset·skill이지 live reCAPTCHA를 즉시 자동 우회하는 공개 exploit이 아니다.
레드팀 / 모의해킹에서 어떻게 활용할까
허가된 staging에서 CAPTCHA를 단독 방어선으로 쓰는 가입·로그인·복구 흐름의 residual control을 평가하는 근거로 활용할 수 있다. Google production을 반복 공격하기보다 자체 test challenge와 synthetic account로 visual pass 이후 rate limit·MFA·risk step-up이 남는지 확인해야 한다.
중단 기준은 production account 영향, third-party 자원 소모, service 약관 위반 가능성이 생기는 시점이다. 공개 dataset으로 모델 인식 능력을 먼저 확인하고 live 자동화 재현은 피하는 것이 적절하다.
실제 점검 시 추가할 체크리스트
- CAPTCHA 통과를 인증·인가 성공과 동일시하는가
- 가입·로그인·복구에 rate limit과 device risk가 별도로 있는가
- visual fallback 후 추가 MFA 또는 anomaly detection이 있는가
- CAPTCHA token을 server-side에서 action·session에 바인딩하는가
- 반복 실패·재시도 패턴을 계정과 IP 외 신호로 탐지하는가
- accessibility fallback이 더 약한 고정 challenge가 아닌가
- bot 탐지가 실패 폐쇄형인지 정상 사용자 DoS를 만드는지 확인했는가
- CAPTCHA provider 정책 변화에 대한 회귀시험이 있는가
실무 가치 평가
웹 모의해킹에서 CAPTCHA를 “자동화 불가” 전제로 제외하지 말아야 한다는 강한 근거다. 다만 공격 recipe보다 CAPTCHA 이후의 계층형 통제와 business abuse 방어를 평가하는 방향으로 쓰는 것이 안전하고 실용적이다.
결론
visual challenge의 난도는 더 이상 안정적인 보안 primitive가 아니다. CAPTCHA는 속도 저하·risk signal 중 하나로만 사용하고 계정·거래·복구 authorization을 독립적으로 보호해야 한다.
'Hack > Web' 카테고리의 다른 글
| HTTP/3 in Burp Suite: 초고속 요청, 서버 측 레이스, 프로토콜 다운그레이드 점검 (0) | 2026.09.24 |
|---|---|
| Secrets That Survive Everything: Runtime Credential Exposure in Production Web Applications (0) | 2026.09.23 |
| Towards Tackling Application Logic Flaws through Autonomous Formal-Logic Modeling and Automated Reasoning (0) | 2026.09.22 |
| What's in a tag name? JavaScript, apparently (0) | 2026.09.13 |
| 파일 업로드 취약점 (0) | 2025.05.26 |
댓글