Cloudflare는 각 시도 후 공격 요청을 수정할 수 있는 고급 인공지능 모델을 사용해 자사의 웹 애플리케이션 방화벽(WAF)을 테스트했다. 이는 고정된 테스트 모음에만 의존하는 방식과 달랐다. 회사는 사전 승인을 받아 고객 전용 스테이징 환경에서 실험을 진행했으며, 45개 시나리오에서 1,107회의 시도를 기록했다.
기본 아이디어는 다양한 인코딩을 시도하고, 페이로드를 HTTP 요청 내부의 다른 위치로 옮기거나, 대상이 표현되는 방식을 변경한 뒤 응답을 사용해 다음 시도를 선택할 수 있는 공격자의 행동을 일부 모의하는 것이다. 모델은 애플리케이션 코드, 내부 WAF 규칙 또는 규칙 번호를 제공받지 않았으며, 요청의 맥락과 특정 HTTP 응답 데이터만을 다뤘다.
적응형 테스트는 어떻게 작동했나?
각 시나리오는 WAF가 차단하는 것으로 알려진 요청으로 시작했으며, 이후 모델이 새로운 수정을 제안했다. 요청을 전송한 뒤 다른 모델 또는 모델 검토 호출이 응답을 검토했고, 시스템은 최대 시도 횟수 내에서 다음 단계를 결정했다. 코드는 요청 실행과 증거 기록을 담당했으며, 각 시도 전에 허용 목록을 통해 도메인 이름을 확인하고, 리디렉션을 차단했으며, 시스템이 보호 규칙을 변경하거나 배포하지 못하도록 했다.
44개 시나리오는 크로스 사이트 스크립팅(XSS), SQL 인젝션, 명령어 인젝션, 서버 측 요청 위조(SSRF), 경로 순회 또는 로컬 파일 포함(LFI), Log4j 공격의 6개 범주를 다뤘다. 45번째 시나리오는 별도로 로그 인젝션을 다뤘다.
1,107회의 시도에서 조사할 가치가 있는 결과 49건으로
WAF의 전반적인 성능은 강력했으며, XSS, LFI, SQLi, Log4j 범주를 거의 완전히 커버했다. 사람의 검토 후 조사할 가치가 있는 결과는 49건으로 남았고, 이 가운데 48건은 명령어 인젝션과 SSRF 두 범주에 속했다. 차단된 요청은 558건이었으며, 다른 시도들은 유효하지 않거나, 무해하거나, 중복되거나, 대상에 도달하지 않았기 때문에 제외됐다.
Cloudflare는 차단되지 않은 요청을 확정적인 취약점으로 간주하지 않았다. 요청이 유효하고 대상에 도달해야 하며, 명백히 악성 상태를 유지하고, 그 동작이 WAF에 기인해야 하며, 엔지니어가 안전하게 재현할 수 있어야 한다고 요구했다. 이러한 구분은 WAF 우회만으로는 애플리케이션 악용에 성공했거나 민감한 데이터에 접근했다는 사실이 입증되지 않기 때문에 중요하다.
SSRF 탐지의 공백 사례
한 시나리오에서 시스템은 클라우드 메타데이터 서비스 주소의 표기 방식을 변경하고, 서로 다른 숫자 표현을 사용했으며, 요청의 여러 부분에 주소를 배치했다. 대부분의 시도는 차단됐지만, 후행 점을 사용한 표기 방식의 한 시도는 WAF의 차단 대신 리디렉션을 유발했다. Cloudflare는 이를 조사가 필요한 신호로 간주했으며, 자격 증명에 접근했거나 악용에 성공했다는 증거로 보지는 않았다.
실제로 무엇이 바뀌었나?
Cloudflare는 결과를 검토해 새로운 규칙이 필요한지, 요청 정규화를 개선해야 하는지, 또는 다른 보안 계층의 개입이 필요한지를 판단했다. 결과는 Managed Ruleset에 세 가지 변경을 이끌었다. 7월 21일 버전에서 SSRF - Obfuscated Host와 SSRF - Restricted Protocol 탐지를 추가했고, SSRF - Cloud 탐지를 개선했다. 난독화된 호스트 탐지는 내부 주소에 비정상적인 숫자 형식을 사용한 요청에서 직접 도출됐다.
이번 실험은 인공지능이 여기서 엔지니어링 판단을 대체하는 도구가 아니라 테스트 범위를 확장하는 도구임을 보여준다. 같은 계열의 두 모델은 서로 다른 변형을 생성했지만, 핵심적인 문제는 두 모델 모두에서 나타났다. 또한 하나의 시나리오에서 시도 횟수를 늘린다고 해서 추가 결과가 발견된다는 보장은 없었다. 일부 연속 시도는 아이디어를 반복하기 시작한 반면, 시작 지점과 공격 범주, 입력 위치를 늘리는 방식은 더 넓은 커버리지를 제공했다.
WAF의 한계도 여전히 존재한다. 방화벽을 우회한 페이로드는 애플리케이션 자체가 악용 가능한 경우에만 성공하므로, 소프트웨어를 업데이트하고 취약점을 수정하는 일은 여전히 필수적이다. Cloudflare는 또한 먼저 규칙을 기록 모드로 활성화하고, 일치하는 요청과 보안 이벤트를 검토한 다음, 정상적인 트래픽에 영향이 없음을 확인한 뒤 차단으로 전환할 것을 권고한다. 회사는 향후 모델이 애플리케이션 취약점과 WAF 규칙을 함께 알고 있는 화이트박스 테스트를 선보일 계획이다.