"등록할 땐 공인 IP였는데요" — MLflow 웹훅이 남의 메타데이터를 대신 읽어준 사건

이미지 출처: CISA KEV

CVE 번호가 배정되고 몇 시간 만에 전 세계 허니팟 센서에 스캔이 잡혔다. 표적은 인터넷에 그대로 열려 있던 MLflow 트래킹 서버였고, 공격자들이 노린 건 모델도 실험 기록도 아니었음. 그 서버가 올라타 있는 클라우드 인스턴스의 임시 자격증명이었다.

핵심 요약

• MLflow 웹훅 테스트 엔드포인트(POST /api/2.0/mlflow/webhooks/{id}/test)가 인증 없이 호출 가능하고, 등록 때 검증한 주소를 리다이렉트 이후 다시 확인하지 않아 전(全)내용 열람형 SSRF가 성립함. CVSS 9.3.
• 3.15.0 미만 전 버전이 영향권. 3.15.0은 검증된 주소를 연결 시점에 고정하는 방식으로 수정됨.
• 이미 실전 악용 중이며 KEV 목록에도 등재됨. 패치와 함께 아웃바운드 통제·IMDSv2 강제가 같이 가야 함.

1. 어디가 열렸나

MLflow에는 실험이나 모델 등록 같은 이벤트가 발생하면 외부 URL로 알림을 쏘는 웹훅 기능이 있음. 사용자가 URL을 등록하면 _validate_webhook_url이 그 주소를 검사해서 사설 대역이나 루프백으로 향하지 않는지 확인함. 여기까지는 교과서적인 SSRF 방어임.

문제는 그 다음. 웹훅이 실제로 발사될 때 HTTP 클라이언트가 리다이렉트를 그냥 따라감. 등록 시점엔 멀쩡한 공인 IP를 반환하던 서버가, 호출 시점에 302로 내부 주소를 가리키면 검증은 이미 지나간 뒤라 아무도 막지 않음. 전형적인 TOCTOU(검사 시점과 사용 시점의 불일치) 구조임. 같은 원리로 DNS 리바인딩 — 짧은 TTL로 같은 도메인의 응답을 공인 IP에서 사설 IP로 바꿔치기하는 방식 — 도 통함.

결정타는 접근 통제. 웹훅을 테스트하는 엔드포인트가 인증을 요구하지 않아서, 서버 주소만 알면 누구나 "이 웹훅 한번 쏴봐"를 시킬 수 있었음. 게다가 응답 본문이 호출자에게 되돌아오는 full-read SSRF라, 내부 서비스를 두드리는 데서 끝나지 않고 읽어낸 내용까지 회수됨.

2. 공격자가 실제로 가져간 것

구체적인 요청 형태는 굳이 적지 않겠음. 방어자 입장에서 중요한 건 도착지임. 클라우드 인스턴스는 대부분 링크로컬 주소의 메타데이터 서비스를 통해 자기 역할(role) 자격증명을 받아오는데, SSRF로 그 경로를 대신 읽게 만들면 AWS IAM 임시 토큰, GCP 서비스 계정 키, Azure 관리 ID 토큰이 통째로 노출됨.

이 자격증명이 왜 무서운가 하면, 그 뒤부터는 취약점이 필요 없어지기 때문임. 정상적인 API 호출로 스토리지 버킷을 훑고, 시크릿 매니저를 열고, 다른 인스턴스로 옆걸음질하는 단계로 넘어감. 실제로 초기 침투 브로커들이 자동화 스캐너로 노출 서버를 긁어 자격증명을 수집하고 있다는 관측이 여러 곳에서 나왔음.

3. 탐지 — 로그 어디를 볼 것인가

• 애플리케이션 로그: /api/2.0/mlflow/webhooks 경로에 대한 등록 요청과, 그 직후 이어지는 /test 호출. 사람이 쓰는 패턴이면 드문드문이지만 스캐너는 초 단위로 반복함.
• 아웃바운드 트래픽: MLflow 서버에서 169.254.169.254, metadata 관련 내부 호스트명, 127.0.0.1, RFC1918 사설 대역으로 나가는 HTTP 요청. 정상 운영에서는 웹훅이 내부를 향할 이유가 거의 없음.
• 리다이렉트 체인: 3xx 응답을 받은 직후 목적지가 공인 IP에서 사설 IP로 바뀌는 흐름. 프록시 로그가 있으면 여기가 제일 선명함.
• DNS: 동일 도메인이 짧은 간격으로 공인 → 사설 IP로 응답을 바꾸는 리졸브. 리바인딩의 지문 같은 것임.
• 클라우드 감사 로그: 인스턴스 역할 자격증명이 해당 인스턴스가 아닌 IP에서 사용된 흔적. AWS라면 GuardDuty의 자격증명 외부 유출 계열 탐지가 여기에 걸림. 침해 확인용으로는 이게 가장 확실한 신호임.

4. 완화 — 순서대로

• 3.15.0 이상으로 올린다. 검증한 주소를 연결 시점에 고정하는 방식으로 바뀌었음. KEV 등재 항목이라 공공기관은 기한까지 붙어 있고, 민간도 그 기준을 그대로 따라가는 게 안전함.
• 트래킹 서버를 인터넷에서 내린다. MLflow는 원래 인증이 얇은 도구임. 리버스 프록시에 인증을 걸거나, VPN·사설망 뒤로 넣는 게 정석임.
• egress 기본 차단. 웹훅이 나갈 곳이 정해져 있다면 allowlist로 묶어두면 됨. SSRF는 나가는 길이 막히면 상당 부분 무력화됨.
• IMDSv2 강제 + hop limit 1. 토큰 기반 요청만 받게 하고 홉 수를 제한하면, 단순 GET형 SSRF로는 메타데이터에 닿지 못함. 개인적으로는 패치보다 이쪽을 먼저 확인해보길 추천함 — 다음번 SSRF까지 같이 막아주는 설정이라서.
• 권한 최소화와 회전. 인스턴스 역할에 붙은 정책이 넓으면 SSRF 하나가 계정 장악으로 번짐. 노출 정황이 있으면 자격증명 회전은 선택이 아니라 필수임.

5. 남는 이야기

이번 건을 보면서 계속 걸렸던 건, 방어 코드가 없어서 뚫린 게 아니라 있는 방어 코드가 한 박자 일찍 실행돼서 뚫렸다는 점이었다. 검증은 분명히 했는데, 검증한 값과 실제로 연결한 값이 달랐던 거죠. URL 필터링은 SSRF 방어의 절반밖에 안 되고, 나머지 절반은 "실제로 연결하는 그 순간"에 걸어야 한다는 게 이 CVE가 남긴 교훈인 것 같다.

MLOps 스택은 실험 편의를 위해 만들어진 도구가 어느새 프로덕션 경계에 서 있는 경우가 많다보니, 이런 구멍이 유난히 크게 번짐. 사내에 MLflow를 굴리고 계신다면 오늘은 버전 확인이랑 외부 노출 여부, 이 두 가지만이라도 같이 점검해보아요. 확인해보고 애매한 부분 있으면 댓글로 남겨주세요, 같이 찾아봅시다.