엣지에서 크리덴셜 스터핑 차단하기

크리덴셜 스터핑(Credential stuffing)

공격은 자동화 도구를 사용해 탈취한 사용자명·비밀번호 조합을 로그인 페이지에 대입한다. 공격 규모는 거대하다. 단일 운영자가 수백 개의 대상 사이트에 걸쳐 하루에 수백만 건의 크리덴셜을 시험하기도 한다. 레이트 리미팅이나 CAPTCHA 같은 전통적 방어는 충분하지 않다. 공격자가 요청을 수천 개의 IP 주소로 분산시키고 CAPTCHA 풀이 서비스를 이용하기 때문이다. 다음은 우리가 크리덴셜 스터핑을 엣지에서, 요청이 인증 시스템에 도달하기 전에 차단하는 방법이다.

공격 표면

전형적인 크리덴셜 스터핑 작전은 탈취한 크리덴셜 목록(다크웹 마켓플레이스에서 100만 건당 단돈 10달러에 구할 수 있다), 자동화 도구(대개 커스텀 스크립트나 OpenBullet 같은 도구), 그리고 프록시 IP 풀(IP 기반 레이트 리미팅을 회피하기 위해 요청마다 로테이션되는 레지덴셜 프록시)을 사용한다.

공격자는 도구를 설정해 통제된 속도로 로그인 요청을 보낸다. 단순한 레이트 리밋을 건드리지 않을 만큼 느리면서도, 시간당 수천 건의 크리덴셜을 시험할 만큼 빠르게 말이다. 각 요청은 서로 다른 IP 주소에서 서로 다른 user agent 문자열을 달고 오기 때문에, 여러 사용자로부터 오는 정상적인 로그인 시도의 흐름처럼 보인다.

레이트 리미팅이 실패하는 이유

IP 기반 레이트 리미팅은 대부분의 팀이 가장 먼저 배치하는 1차 방어선이자, 가장 먼저 무너지는 방어선이다. 레지덴셜 프록시 서비스는 수백만 개의 실제 IP 주소(가정용 라우터, 모바일 기기, IoT 기기)에 대한 접근을 제공하며, 이 IP들은 요청마다 로테이션된다. 서버 관점에서는 각 로그인 시도가 악용 이력이 전혀 없는 고유한 레지덴셜 IP에서 오는 것처럼 보인다.

계정 기반 레이트 리미팅(사용자명당 로그인 시도 제한)은 더 효과적이지만 서비스 거부(DoS) 취약점을 만든다. 공격자가 특정 사용자명에 대해 고의로 여러 번 로그인을 실패시켜 정상 사용자를 잠가버릴 수 있기 때문이다.

토대가 되는 디바이스 핑거프린팅

디바이스 핑거프린팅은 판을 바꾼다. 사용 중인 IP가 아니라 공격을 실행하는 디바이스를 식별하기 때문이다. 단일 머신이나 VM 팜에서 돌아가는 크리덴셜 스터핑 도구는, 어떤 프록시 IP로 로테이션하든 상관없이 모든 요청에 걸쳐 일관된 디바이스 핑거프린트를 만들어낸다.

우리의 Bot Detection 엔진은 자동화 도구 자체를 식별한다. Selenium은 navigator.webdriver 흔적을 남긴다. Puppeteer와 Playwright는 특징적인 JavaScript 런타임 특성을 가진다. 헤드리스 Chrome은 헤드가 있는(headed) Chrome이 포함하는 특정 브라우저 API가 빠져 있다. JavaScript를 실행하지 않는 커스텀 HTTP 클라이언트조차 TLS 핑거프린팅으로 탐지된다. 그들의 Client Hello 메시지가 기반이 되는 HTTP 라이브러리를 드러내기 때문이다.

디바이스별 속도(Velocity) 추적

안정적인 디바이스 식별자를 확보하면(Device Identification을 통해), IP 수준이 아니라 디바이스 수준에서 속도 검사를 적용할 수 있다. 하나의 디바이스가 5분 안에 50번의 로그인을 시도한다면, 그 요청들이 몇 개의 서로 다른 IP에서 왔든 상관없이, 이 패턴은 틀림없는 크리덴셜 스터핑이다.

우리의 IP Intelligence 모듈은 세 가지 시간 윈도, 즉 5분, 1시간, 24시간에 걸쳐 속도를 추적한다. 이 다중 윈도 접근법은 공격적인 공격(분당 수백 건의 시도)과 저속·저강도 공격(며칠에 걸쳐 시간당 몇 건씩 지속되는 시도)을 모두 잡아낸다.

행동 신호 분석

봇 탐지와 속도 추적을 넘어, 우리의 Smart Signals 분석은 자동화 공격을 정상 로그인과 구별하는 행동 신호를 살핀다. 실제 사용자는 요청 타이밍, 타이핑 속도, 탐색 패턴에서 자연스러운 변동을 보인다. 자동화 도구는 기계적으로 일관된 타이밍, 동일한 요청 헤더를 만들어내는 경향이 있으며, 마우스 움직임이나 스크롤 이벤트가 없다.

또한 우리는 환경 스푸핑을 나타내는 신호 불일치도 점검한다. macOS의 Chrome이라고 주장하면서 Linux VM과 연관된 WebGL 파라미터를 제시하는 브라우저는 즉시 플래그 처리된다. TLS 핑거프린트와 일치하지 않는 user agent 문자열은 변조 경보를 유발한다.

엣지 배포

크리덴셜 스터핑을 막는 핵심은, 그것이 인증 시스템에 도달하기 전에 막는 것이다. 우리의 에이전트는 로그인 페이지에서 로드되며, 사용자(또는 봇)가 크리덴셜을 제출하기 전에, 즉 페이지 로드 중에 신호를 수집한다. 핑거프린트와 봇 탐지 결과는 로그인 폼이 제출될 시점에 이미 준비되어 있어, 서버가 자동화 시도를 즉시 거부할 수 있다.

물량이 많은 대상의 경우, CDN 엣지에서 핑거프린트 검증을 실행하는 Cloudflare Worker 또는 CloudFront Lambda@Edge 통합을 배포할 것을 권장한다. 이는 크리덴셜 스터핑 요청이 공격자와 가장 가까운 엣지 노드에서 차단되어 오리진 서버에 결코 도달하지 않는다는 뜻이다.

결과

우리 고객들은 로그인 페이지에 tracio.ai를 배포한 뒤 크리덴셜 스터핑 물량이 99% 감소했다고 보고한다. 남은 1%는 정교하게 스푸핑된 신호와 함께 완전한 브라우저 자동화를 사용하는 고도로 정교한 공격으로 구성되며, 이는 속도 패턴이 드러나면서 첫 수십 건의 요청 안에 우리의 다중 방식 탐지에 의해 잡힌다.