F5의 BIG-IP APM 힙 오버플로우 취약점, OAuth 프로파일을 통해 원격 코드 실행 가능하게 함

요약

• BIG-IP APM은 F5가 BIG-IP 플랫폼에 추가한 접근 정책 모듈로, 사용자 요청이 애플리케이션에 도달하기 전에 사용자가 누구인지 확인하는 데 기업이 네트워크 엣지에서 운영하는 구성 요소입니다.
• F5는 2026년 9월 22일 CVE-2026-94127을 발표했으며, CVSS v3.1 기준 Critical 등급(9.8)과 v4.0 기준 9.3으로 평가했습니다. 이는 자격 증명 없이 공격자가 코드를 실행할 수 있게 하는 힙 기반 버퍼 오버플로우 취약점입니다.
• 취약점은 하나의 가상 서버에 노출되어 있습니다: APM 접근 정책과 OAuth Authorization Server 프로파일이 모두 구성된 경우이며, APM을 OAuth 클라이언트나 리소스 서버로만 사용하는 배포는 영향을 받지 않습니다.
• 취약한 버전은 21.1.0, 17.5.0부터 17.5.1까지, 그리고 17.1.0부터 17.1.3까지이며, F5는 각 버전에 엔지니어링 핫픽스로 수정 패치를 배포할 예정입니다.
• 이 결함은 데이터 플레인에 존재하며, 어플라이언스 모드(Appliance mode)의 시스템도 취약합니다. 제어 플레인 노출은 없으므로 요청 경로가 공격 경로가 됩니다.
• F5는 세 가지 지표를 제시했습니다: 반복되는 OAuth 실패, 직후 기록된 의심스러운 명령어, 그리고 트래픽 마이크로커널이 루프에 빠질 때 발생하는 TMM SIGABRT입니다.
• CISA는 핫픽스가 예정되는 동안 임시 iRule을 통해 트래픽 패턴을 유지하고 있으며, CISA는 최종 패치가 적용되기 전에 포렌식 분류(forensic triage)를 요청했습니다.
• CISA는 발표 당일 이 결함을 알려진 악용 취약점 목록(Known Exploited Vulnerabilities catalog)에 추가했으며, 마감일은 9월 25일이고, F5는 해당 취약점이 이미 악용된 것을 확인했다고 밝혔습니다.

하나의 가상 서버가 전체 노출을 담당함

F5의 권고문은 유발 조건을 명확히 밝힙니다:

Capture of the vulnerable-versions table in F5's security advisory K000162605, listing the BIG-IP APM branches and the engineering hotfix for each.

F5의 공식 보안 권고(security advisory) K000162605 (my.f5.com, 2026년 9월 22일 게시, 2026년 10월 8일 조회): 취약점으로 알려진 BIG-IP APM 브랜치들, 각 브랜치에 대한 엔지니어링 핫픽스(hotfix), 그리고 APM OAuth 컴포넌트에 대한 Critical 9.8 및 9.3 등급을 다루고 있습니다.

이 공급업체는 일반적으로 악용 조건(exploit condition)을 둘러싸고 존재하는 모호성을 제거합니다. "APM을 오직 OAuth 클라이언트/리소스 서버로만 사용하는 배포 환경(OAuth 인증 서버 프로파일이 구성되지 않은 경우)은 이 취약점의 영향을 받지 않습니다." 따라서 자신의 APM 프로파일이 어떤 역할을 하는지 아는 팀이라면, 한눈에 자신이 영향을 받는 집단인지 알 수 있습니다.

그 영향받는 집단은 설치된 기반(installed base)보다 작지만, 단순한 호기심거리보다는 큽니다. 인증 서버로 구성된 APM은 조직이 내부 애플리케이션에 토큰을 발행하는 자체 게이트웨이를 원할 때 사용하는 패턴이며, 이는 애플리케이션 로그인을 기업 경계(corporate perimeter) 내부에, 그리고 보안팀이 이미 감사하는 ID 시스템 내부에 유지하게 합니다. 네트워크 상에서 그 결과는 인터넷으로부터 요청을 받고 OAuth 엔드포인트가 연결된 하나의 가상 서버이며, 이 엔드포인트에는 힙 기반 버퍼 오버플로우(heap-based buffer overflow)가 존재합니다.

F5는 이 결함을 CVSS v3.1 기준으로 Critical 9.8, v4.0 기준으로 9.3으로 평가하고, CWE-122로 분류하며, 제품 개발 ID 2524777 아래 추적합니다. 두 점수 모두 동일한 도달 범위(reach)를 설명합니다: 네트워크 접근, 권한 없음, 사용자 상호 작용 없음. Rapid7은 이 노출도를 같은 방식으로 요약하며, 이 결함이 기본 구성(default configuration)에서는 존재하지 않으며 악용을 위해서는 APM 액세스 정책과 OAuth 프로파일이 모두 구성된 가상 서버가 필요하다고 지적했습니다.

어플라이언스 모드(Appliance mode)가 요청 경로를 데이터 플레인(data plane)에 유지하는 이유

영향도 설명(impact statement)이 이 보안 권고가 주목받는 부분인데, 이는 요청 경로 자체에 존재하는 결함을 설명하기 때문입니다. "이 취약점은 인증되지 않은 공격자가 원격 코드 실행(RCE)을 수행할 수 있게 합니다. 어플라이언스 모드의 BIG-IP 시스템 역시 취약합니다. 이것은 데이터 플레인 문제이며, 제어 플레인 노출은 없습니다."

어플라이언스 모드는 기본 운영체제를 관리자로부터 폐쇄하고 하나의 작업만 수행하는 강화된(hardened) 어플라이언스를 남기기 위해 존재합니다. 이는 트래픽 처리 마이크로커널이 자체적으로 도달하는 결함에 대해서는 아무것도 하지 못한다는 의미입니다. 관리 접근을 잠그고, 쉘 계정을 제거하며, 관리 인터페이스를 운영 네트워크로 제한한 팀은 대부분의 어플라이언스 공격에 대해 진정으로 입지를 개선했지만, 이 취약점에는 아무것도 바꾸지 못했습니다. 왜냐하면 요청이 합법적인 애플리케이션 트래픽과 동일한 리스너(listener)에서 도착하기 때문입니다.

Rapid7은 운영상의 결론을 도출했습니다. "영향을 받는 BIG-IP 시스템이 조직의 네트워크 엣지에서 트래픽을 처리할 수 있으므로, 이 구성을 사용하는 조직은 패치 적용을 우선순위로 해야 합니다." 엣지 ID 게이트웨이는 정의상 신뢰할 수 없는 네트워크로부터 도달 가능하므로 노출은 당연한 것이며, 팀이 답해야 할 질문은 하나의 가상 서버가 두 프로파일을 동시에 가지고 있느냐 여부입니다.

Capture of page one of F5's official BIG-IP Access Policy Manager product overview document.

F5의 공식 BIG-IP Access Policy Manager 제품 개요(f5.com, 2026년 10월 8일 검색): 원격, 네트워크 및 웹 액세스를 하나의 정책 인터페이스로 통합하는 모듈에 대한 공급업체 자체 설명.

두 기록은 해당 문제가 이론적인 것이 아니라 실제 발생했음을 확인해 줍니다. F5의 권고문에는 이 취약점이 이미 악용되었다는 내용이 포함되어 있으며, 뉴욕주의 같은 문제에 대한 권고문에서는 F5가 야생 상태(in the wild)에서 악용을 확인했다고 명시합니다. 두 기록 모두 피해자를 특정하지 않는데, 이는 공급업체 확인의 일반적인 형태이며 자산 조사(asset query)가 단순히 기다리는 자세보다 더 가치가 있는 이유입니다.

방어자가 찾아야 할 세 가지 지표

권고문의 탐지 지침은 충분히 구체적이어서 활용할 수 있으며, 이는 오늘날 방어자가 조치할 수 있는 부분입니다. F5는 시도 패턴을 한 문장으로 설명합니다: “여러 OAuth 인증 실패에 이어 의심스러운 명령어들이 발생하고, 그 직후 TMM SIGABRT가 발생하는 형태.” 권고문은 응답의 기준을 제시합니다: “비교적 짧은 시간 간격으로 관찰된 세 가지 지표는 추가 조사를 해야 할 이유로 간주되어야 합니다.”

첫 번째 지표는 APM 로그에서 나타나는 OAuth 실패 노이즈입니다. 단일 실패 메시지는 바쁜 게이트웨이에서는 흔한 일이지만, 신호는 반복입니다. 권고문은 여기에 수치를 부여합니다: 하나의 로그에서 10개 이상의 항목이 지속적으로 반복되면 검토할 가치가 있으며, 특히 모든 항목이 단일 IP 주소에서 발생했을 때 더욱 그렇습니다. 실패하는 라인은 유효하지 않은 토큰과 사용자 정보를 요청한 출처를 명시하여 로그 검색을 용이하게 합니다.

두 번째 지표는 이러한 실패 직후 감사(audit) 로그에서 발생하는 명령어 활동이며, 여기서 읽기 원시값(read primitive)이 장치(box)의 연산자(operator)로 변모합니다. 세 번째는 TMM 코어 파일인데, 이는 트래픽 마이크로커널이 루프에 진입하고 상태 데몬(state daemon)이 이를 중단(abort)할 때 생성됩니다. 권고문 자체의 문구는 “TMM이 루프에 진입하여 SOD 데몬이 SIGABRT를 보내게 하는 것을 관찰했습니다.”라고 합니다. F5는 또한 관리자들에게 전역 OAuth 통계 카운터로 주의를 돌리는데, 여기서 실패한 총합의 설명할 수 없는 증가는 추적해야 할 숫자입니다.

순서대로 보면, 이 세 가지 지표는 방어자가 사후에 재구성하고 사전에 모니터링할 수 있는 타임라인을 형성합니다. OAuth 실패가 먼저 반복적으로 나타나고, 그 뒤를 명령어들이 바짝 따르며, 핵심 파일이 순서를 마무리 짓습니다. 각각 하나만으로는 바쁜 게이트웨이에서 평범한 노이즈에 불과하지만, 가치는 이 순서 배열에 있으며, 이 순서 배열은 공급업체가 공개한 것입니다.

iRule을 통해 트래픽 유지 및 패치 적용 예정

이 해결 경로는 두 번 읽어볼 만한 세부 사항이 있는데, 이는 작업 계획 방식을 변경하기 때문입니다. F5는 영향을 받는 모든 브랜치에 엔지니어링 핫픽스(hotfix) 형태로 수정 사항을 배포하고 있습니다. 버전 21.1.0은 Hotfix-BIGIP-21.1.0.2.0.30.22-ENG로, 버전 17.5.0부터 17.5.1까지는 Hotfix-BIGIP-17.5.1.9.0.160.12-ENG로, 그리고 버전 17.1.0부터 17.1.3까지는 Hotfix-BIGIP 17.1.3.5.0.41.14-ENG로 이동합니다. 핫픽스는 유지보수 기간(maintenance window)이 지정된 유지보수 이벤트이며, 로드 밸런싱 페어(load-balanced pair)의 경우 이는 작업(task)이라기보다는 일련의 과정(sequence)을 의미합니다.

Netics editorial statistic card showing the 9.8 CVSS v3.1 rating, the absence of any authentication requirement, and the configuration the flaw depends on.

F5의 권고문에서 만든 Netics 에디토리얼 카드는, APM 접근 정책과 OAuth 인증 서버 프로파일을 모두 처리하는 가상 서버(virtual server)에 네트워크 접근만으로도 필요한 힙 기반 버퍼 오버플로우(heap-based buffer overflow) 취약점에 대한 공급업체 자체 평가입니다.

업그레이드가 한 번에 이루어질 수 없는 경우, F5는 지원 사례(support case)를 통해 얻은 iRule을 제공하여 영향을 받는 가상 서버의 악성 트래픽 패턴을 제한합니다. CISA의 지침은 작업 순서에 대해 명확하게 언급하고 있습니다:

해당 결함은 벤더 내부에서 발견되었습니다. 보안 권고문(advisory)에 따르면 이 문제는 F5가 자체적으로 내부에서 발견한 것으로 명시되어 있어, 이는 벤더 기원(vendor-originated) 발견 사례 중 비교적 작은 범주에 속합니다. 또한 이는 공개 기록이 벤더 자신의 것이며, 해당 취약점이 2026년 9월 22일 연방 카탈로그에 등재되었을 당시 제3자 개념 증명(proof of concept)은 확인되지 않았음을 의미합니다.

패치 시점과 포렌식 분류의 교차점

연방 기록은 시간표를 추가합니다. CISA는 2026년 9월 22일 CVE-2026-94127을 알려진 악용 취약점(Known Exploited Vulnerabilities, KEV) 카탈로그에 등재하면서 2026년 9월 25일까지의 기한을 설정하고, 해당 사례를 BOD 26-04에 따른 포렌식 분류(forensic triage)가 필요함을 표시했으며, 랜섬웨어 연관성은 알 수 없음으로 남겨두었습니다. Rapid7은 같은 항목을 기록하면서 민간 부문 독자에게 중요한 세부 정보를 추가했습니다: “2026년 9월 22일 기준으로 CVE-2026-94127이 CISA KEV에 추가되었으나, 공개적으로 사용 가능한 개념 증명(proof of concept)은 확인되지 않았습니다.”

해당 카탈로그 등재는 관찰된 악용을 통해 이루어지며, 벤더의 시간표를 접하지 못하는 조직들까지 도달합니다. 자체 게이트웨이를 운영하는 회사라면, 그 순서는 벤더와 기관이 모두 설명하는 것과 동일한 순서를 따릅니다. 먼저 자산 질의(asset query)가 옵니다: APM 접근 정책과 OAuth 인증 서버 프로파일을 모두 가지고 있는 가상 서버는 무엇이며, 그중 어느 것이 외부로부터 요청에 응답하는지 확인합니다. 다음은 OAuth 실패 카운터와 해당 타임스탬프 주변의 감사 로그를 기반으로 구축되는 탐지(detection)가 옵니다. 그다음에는 iRule을 이용한 격리(containment)가 오고, 영향을 받은 모든 노드에 대한 핫픽스(hotfix)가 오며, 마지막으로 변경 이전의 로그를 읽는 검토(review)가 이어집니다.