Metabase 관리자 계정이 비밀번호 없이 만들어지고 있음

이미지 출처: The Hacker News

출근해서 Metabase 관리자 화면의 People 탭을 열었는데, 어제까지 없던 관리자 권한 계정이 하나 늘어 있다고 상상해보자. 사내 메일 도메인을 흉내 낸 주소, 가입 경로는 불명, 마지막 로그인은 새벽 세 시. 이번에 실제 공격에 쓰인 것으로 확인된 Metabase 제로데이가 만들어내는 장면이 딱 이렇다. 취약점의 결과물이 셸이나 랜섬노트가 아니라 멀쩡해 보이는 관리자 계정 한 줄이라 더 늦게 발견됨.

핵심 요약

• Metabase의 인증 처리 경로에 결함이 있어, 로그인 절차를 거치지 않고도 관리자 수준 접근이 가능한 상태였고 이미 실제 공격에 악용됨.
• Metabase는 사내 DB 접속 정보를 통째로 들고 있는 서비스라, 침해 시 피해 범위가 Metabase 한 대에서 끝나지 않고 연결된 데이터베이스 전체로 번짐.
• 패치가 최우선이지만, 패치 전에 이미 심어진 계정·API 키·DB 커넥션이 남아 있을 수 있으므로 사후 점검이 반드시 따라와야 함.

이번 건이 왜 다른가

보통 웹 애플리케이션 취약점은 "일단 낮은 권한으로 들어간 뒤 권한을 올린다"는 두 단계를 거침. 그런데 인증 우회 계열은 그 첫 단계를 통째로 건너뜀. 로그인 폼 앞에서 멈춰야 할 요청이 내부적으로는 이미 인증된 것처럼 처리되면서, 관리자만 접근 가능한 설정·사용자 관리·데이터 소스 영역까지 그대로 열림.

공격 재현은 개념 수준으로만 짚고 넘어가면, 요지는 세션이나 토큰의 유효성을 검증하는 지점과 실제 권한을 부여하는 지점이 어긋나 있었다는 것임. 서버가 "이 요청은 아직 인증되지 않았다"고 판단할 기회를 갖기 전에 관리자 기능을 태워버리는 구조. 그래서 익스플로잇이 단순하고, 단순한 만큼 대규모 스캔에 바로 실림. 실제로 인터넷에 노출된 Metabase 인스턴스를 훑는 자동화 트래픽이 붙는 데 오래 걸리지 않았음.

Metabase가 털리면 잃는 것

Metabase는 그 자체로 데이터를 만들지 않음. 대신 다른 데이터베이스에 붙기 위한 자격증명 창고 역할을 함. 프로덕션 PostgreSQL, 분석용 BigQuery, 결제 로그가 쌓이는 MySQL... 이런 것들의 접속 정보가 한곳에 모여 있음. 관리자 권한을 쥔 공격자는 굳이 취약점을 더 파고들 필요 없이, 정상 기능인 Native Query 창을 열어 SQL을 그대로 던지면 됨.

• 회원 테이블, 주문 테이블 전량 조회 후 CSV/JSON으로 내려받기
• 새 데이터 소스 등록을 가장한 외부 서버 연결 시도
• 지속성 확보용 관리자 계정 추가 및 API 키 발급
• 대시보드 구독(Subscription) 기능을 이용해 조회 결과를 외부 메일·웹훅으로 정기 발송

마지막 항목이 특히 고약함. 백도어를 심는 게 아니라 제품의 정상 기능을 그대로 쓰는 것이라, 안티바이러스도 EDR도 반응하지 않고 로그상으로도 "누군가 리포트를 예약했다"로만 남음.

지금 당장 확인할 다섯 가지

패치를 올렸다고 끝이 아님. 이미 들어왔다 나간 흔적이 있는지부터 봐야 함. 순서를 정하자면 이렇게 하는 걸 개인적으로 추천함.

• 관리자 계정 목록 — 인사 담당자가 모르는 계정, 생성일이 최근인데 초대 기록이 없는 계정, 그룹이 Administrators로만 묶인 계정을 우선 확인.
• API 키와 세션 — 발급된 키 전량을 대조하고, 설명이 비어 있거나 이름이 무의미한 문자열인 것은 일단 폐기. 확실치 않으면 전체 세션 강제 만료가 제일 안전함.
• Native Query 실행 이력 — 감사 로그나 DB 측 쿼리 로그에서 대량 SELECT, 시스템 테이블 조회, 평소 안 쓰던 시간대의 실행을 추림. 대시보드 없이 쿼리만 단독 실행된 기록이 신호가 됨.
• 데이터 소스 설정 변경 — 새로 추가된 커넥션, 호스트 주소가 사내 대역 밖인 항목, SSL 옵션이 갑자기 꺼진 항목을 점검.
• 구독·알림 설정 — 수신자에 외부 메일 주소나 낯선 웹훅 URL이 들어간 항목이 있는지 전수 조사.

웹 서버나 리버스 프록시 로그가 있다면 인증 관련 엔드포인트로 향한 요청 중 로그인 성공 기록 없이 곧바로 관리 API를 호출한 흐름을 찾아보는 것도 유효함. 정상 사용자는 절대 그런 순서로 움직이지 않음.

완화와 구조 개선

당장의 조치는 명확함. 벤더가 배포한 최신 버전으로 올리고, 올리는 동안에는 인스턴스를 인터넷에서 떼어놓는 것. 그런데 이 사건이 남기는 진짜 숙제는 따로 있다고 봄.

• BI 도구를 공개 인터넷에 두지 않기 — VPN이나 제로트러스트 프록시 뒤로 넣으면 이런 부류의 인증 우회는 대부분 도달조차 못 함.
• Metabase 전용 DB 계정을 읽기 전용으로 — 최소 권한이 지켜졌다면 관리자 계정을 뺏겨도 데이터 변조·삭제까지는 못 감. 민감 컬럼은 뷰로 마스킹해서 노출.
• DB 측에서 감시하기 — 애플리케이션 로그는 공격자가 지울 수 있지만, 데이터베이스 서버의 접속·쿼리 로그는 별도 권한 영역임. 여기에 임계치 알림을 걸어두면 대량 유출을 조기에 잡을 수 있음.
• 이그레스 통제 — Metabase 서버가 외부로 나가는 트래픽을 화이트리스트로 묶어두면 데이터 반출과 웹훅 유출을 동시에 막음.

마무리

사내 대시보드는 보안 점검 목록에서 자꾸 뒤로 밀림. "우리끼리 보는 통계 화면인데 뭘"이라는 감각 때문인데, 정작 그 화면 뒤에는 회사에서 제일 민감한 테이블들이 줄줄이 연결돼 있음. 관리자 목록 한 번 열어보는 데 1분도 안 걸리니, 이 글 읽고 나서 바로 확인해보시길. 혹시 점검하다가 애매한 로그를 발견했다면 댓글로 남겨주세요, 같이 들여다봐요.