WAF를 뚫는 “해커들의 트릭”, 완벽한 방어는 없다

들어가며

보안 담당자들 사이에서 자주 나오는 농담이 있습니다. WAF를 도입한 첫 달에는 잠을 푹 잤는데, 석 달이 지나니 오히려 더 불안해졌다는 이야기입니다. 이유는 간단합니다. 방화벽을 뚫는 방법을 연구하는 쪽도 결국 사람이고, 그 사람들은 규칙이 어떻게 생겼는지 이미 파악하고 있기 때문입니다.

실제로 2021년 말 전 세계를 뒤흔든 로그4j(Log4j) 취약점 사태 당시, 많은 기업들이 WAF 규칙을 서둘러 추가했지만 공격자들은 인코딩 방식을 살짝 바꾸는 것만으로 그 규칙을 우회했습니다. 오늘은 해커들이 WAF를 우회할 때 실제로 노리는 지점이 무엇인지 개념적으로 살펴보고, 완벽한 차단이 불가능하다는 전제 아래 어떻게 방어 체계를 겹겹이 쌓아야 하는지 이야기해보겠습니다.

WAF와 공격자의 끝나지 않는 숨바꼭질

WAF는 결국 정해진 규칙에 따라 요청을 판단하는 시스템입니다. 그리고 그 규칙은 공개된 취약점 정보나 과거 공격 사례를 바탕으로 만들어집니다. 문제는 공격자 역시 같은 정보를 볼 수 있다는 점입니다. 방어 규칙이 무엇을 기준으로 차단하는지 알면, 그 기준을 살짝 비껴가는 변형을 만드는 것은 생각보다 어렵지 않습니다.

이런 이유로 보안 업계에서는 이 관계를 흔히 고양이와 쥐의 게임에 비유합니다. 방어 쪽이 새로운 규칙을 만들면, 공격 쪽은 그 규칙을 피해가는 새로운 변형을 찾아냅니다. 그리고 그 변형이 알려지면 방어 쪽은 다시 규칙을 보강합니다. 이 순환은 구조적으로 끝나지 않습니다.

우회 기법이 파고드는 지점, 해석의 차이

WAF 우회 기법들을 자세히 들여다보면 공통점이 하나 있습니다. 대부분 WAF가 요청을 해석하는 방식과 실제 애플리케이션 서버가 그 요청을 해석하는 방식 사이의 미묘한 차이를 파고든다는 점입니다.

대표적으로 세 가지 유형을 개념적으로 살펴보면 다음과 같습니다.

• 인코딩을 활용한 변형: 공격 구문을 URL 인코딩이나 유니코드 등으로 변형해서 전송하면, WAF는 일반 텍스트 패턴만 검사하다가 이를 놓치고 애플리케이션 단에서 원래 형태로 복원되어 실행되는 경우가 있습니다
• 파라미터 중복 전송: 동일한 이름의 파라미터를 여러 번 담아 보내면, WAF와 백엔드 서버가 서로 다른 값을 읽어들이는 해석 차이가 발생할 수 있습니다
• 요청 분할: 하나의 공격 구문을 여러 조각으로 쪼개어 전송하면, WAF가 조각 하나하나는 정상으로 판단하지만 서버에서 조각들이 합쳐지는 순간 위험한 구문이 완성되는 경우가 있습니다

아래 그림은 이 세 가지 유형이 각각 어떤 원리로 방어선의 틈을 파고드는지를 개념적으로 정리한 것입니다. 세 방식 모두 특정 공격 코드를 알려주기 위한 것이 아니라, WAF가 가진 구조적인 한계가 어디서 비롯되는지를 이해하기 위한 목적으로 봐주시면 좋겠습니다.

로그4j 사태가 보여준 교훈

2021년 말 공개된 로그4j 취약점은 자바 기반 로깅 라이브러리의 심각한 원격 코드 실행 취약점이었습니다. 이 취약점이 알려지자마자 수많은 보안팀이 WAF에 관련 패턴을 차단하는 규칙을 급하게 추가했습니다. 그런데 공격자들은 곧바로 대소문자를 섞거나, 특정 구문 사이에 의미 없는 문자를 끼워 넣는 방식으로 초기 방어 규칙을 우회하는 변형을 퍼뜨렸습니다.

이 사례가 보여주는 교훈은 명확합니다. WAF 규칙 하나를 급하게 추가하는 것만으로는 새로 발견된 심각한 취약점을 완전히 막아낼 수 없다는 것입니다. 근본적인 해결은 결국 취약한 라이브러리 자체를 패치하는 것이었고, WAF는 그 패치가 적용되기 전까지 위험을 어느 정도 낮춰주는 임시 방편의 역할에 가까웠습니다.

완벽한 보안은 없다는 전제에서 시작하기

이 지점에서 보안 전략의 방향이 달라집니다. WAF 하나로 모든 공격을 막아내겠다는 목표 대신, WAF가 뚫릴 수 있다는 전제 아래 그다음 방어선을 준비해두는 접근이 필요합니다. 이것이 바로 심층 방어, 즉 디펜스 인 뎁스라는 개념입니다.

심층 방어의 핵심은 하나의 방어선이 아니라 여러 겹의 방어선을 겹쳐 쌓는 것입니다. 네트워크 경계의 방화벽부터 시작해서 WAF, API 게이트웨이의 인증 및 권한 검증, 애플리케이션 코드 자체의 안전한 입력 처리, 그리고 실행 시점에 이상 행동을 감지하는 런타임 보호까지, 각 계층이 서로 다른 관점에서 위협을 들여다봅니다. 아래 그림에서 볼 수 있듯, 어느 한 계층이 뚫리더라도 다음 계층이 그 공격을 잡아낼 가능성이 남아 있는 구조입니다.

실무에서 심층 방어를 구축하는 방법

심층 방어를 실제로 구축할 때 고려할 만한 접근을 정리하면 다음과 같습니다.

1. WAF 규칙은 주기적으로 업데이트하되, 그것이 유일한 방어선이라고 가정하지 않습니다
2. 애플리케이션 코드 수준에서도 입력값 검증과 안전한 라이브러리 사용을 기본 원칙으로 삼습니다
3. API 게이트웨이 단에서 별도의 인증과 권한 검증을 두어 WAF가 놓친 요청도 한 번 더 걸러냅니다
4. 런타임 애플리케이션 자체 보호 기술을 도입해 실행 중인 프로세스의 이상 행동을 실시간으로 감지합니다
5. 새로운 취약점이 공개되면 WAF 규칙 추가와 별개로 근본적인 패치 일정을 함께 관리합니다

결국 중요한 것은 어느 한 계층에 모든 것을 의존하지 않는 태도입니다.

결론, 뚫릴 수 있다는 것을 인정해야 더 안전해진다

WAF는 여전히 중요한 방어선이지만, 그 자체로 완벽할 수 없다는 사실을 받아들이는 것이 오히려 더 튼튼한 보안 체계를 만드는 출발점입니다. 공격자와의 숨바꼭질은 앞으로도 계속될 것이고, 그 게임에서 이기는 방법은 하나의 벽을 더 높이 쌓는 것이 아니라 여러 겹의 벽을 준비해두는 것입니다.

지금 우리 시스템이 WAF 하나에만 의존하고 있지는 않은지, 그 뒤에 다음 방어선이 준비되어 있는지부터 점검해보시길 권합니다.

참고

로그4셸(Log4Shell) 취약점 및 OWASP의 WAF 우회 관련 공개 자료를 참고하여 작성하였습니다.