AI는 알아서 움직이고, MCP 패키지는 조용히 뒷문을 열었다 — 이번 주 보안 정리

이미지 출처: The Hacker News

주말에 밀린 보안 뉴스를 몰아서 읽는 습관이 있는데, 이번 주 목록을 쭉 훑다가 손이 잠깐 멈췄음. 네 건의 굵직한 이슈가 서로 다른 사건처럼 보이는데, 뜯어보면 전부 "우리가 별생각 없이 믿고 있던 것"이 무너지는 이야기였음. 자율적으로 판단하는 AI, 사내 데이터가 다 모이는 BI 도구, 개발자가 습관적으로 설치하는 확장 패키지, 그리고 사무실 천장 위에서 몇 년째 돌아가는 라우터. 공통점은 하나, 전부 감시 목록에서 빠져 있던 자산이라는 것.

핵심 요약

• AI 에이전트가 사람의 승인 없이 실제 작업을 수행하는 사례가 늘면서, '권한 위임'과 '실행 로그'가 새로운 보안 경계가 됨
• Metabase 계열 결함과 MCP 확장 생태계 공격은 모두 신뢰된 내부 경로를 타고 들어와 기존 경계 방어를 그대로 통과함
• 탐지의 핵심은 취약점 목록이 아니라 자산 목록·행위 로그·아웃바운드 통신 세 가지를 다시 그리는 일

1. AI가 '알아서' 움직일 때 생기는 빈틈

이번 주 화제의 중심은 AI 에이전트가 의도치 않은 방향으로 작동한 사례들이었음. 여기서 위험한 건 AI가 갑자기 악해지는 SF적 상상이 아니라, 훨씬 현실적인 구조 문제임.

• 에이전트에게 준 자격증명이 사람 계정 수준으로 넓음. 사용자는 "요약만 시켰다"고 생각하지만 토큰은 읽기·쓰기·삭제가 다 열려 있는 경우가 흔함
• 외부에서 가져온 문서·웹페이지·이슈 본문이 그대로 지시문이 됨. 이른바 간접 프롬프트 주입인데, 방어자 입장에선 "신뢰되지 않은 입력이 특권 실행 흐름에 직접 닿는 구조"로 이해하면 정확함
• 실행 흔적이 남지 않음. 사람이 SSH로 들어와 파일을 지우면 로그가 남지만, 에이전트가 API로 같은 일을 하면 정상 트래픽으로 보임

완화는 의외로 고전적임. 에이전트 전용 계정을 사람 계정과 분리하고, 권한은 작업 단위로 최소화하고, 파괴적 동작(삭제·배포·결제·권한 변경)은 반드시 사람 승인 단계를 끼워 넣는 것. 그리고 에이전트가 호출한 모든 도구 실행을 별도 감사 로그로 남겨야 함. 개인적으로는 "이 토큰이 유출되면 무슨 일이 벌어지는가"를 한 문장으로 못 쓰겠으면 그 권한은 과한 것이라고 봄.

2. Metabase 0-day — 데이터가 모이는 곳이 곧 표적

BI 도구는 성격상 사내 데이터베이스 접속 정보를 전부 품고 있음. 즉 Metabase 한 대가 뚫리면 그 뒤에 붙은 DB 자격증명이 통째로 딸려 나옴. 이번에 실제 공격에 쓰인 것으로 알려진 결함도 그 지점을 정확히 노렸음.

점검 순서는 이렇게 잡으면 무리가 없음.

• Metabase 인스턴스가 인터넷에 직접 노출돼 있는지부터 확인. 대부분은 VPN이나 리버스 프록시 뒤로 넣기만 해도 위험이 크게 줄어듦
• 관리자 계정 목록과 생성 시각을 확인. 기억에 없는 계정, 근무 시간 외 생성 흔적이 가장 먼저 보이는 신호임
• 연결된 데이터소스의 접속 계정 권한을 읽기 전용으로 낮추고, 침해가 의심되면 DB 자격증명을 전부 회전
• 애플리케이션 로그에서 인증 없이 성공한 요청, 비정상적으로 긴 쿼리 실행, 낯선 IP의 세션을 역추적

3. MCP 공급망 공격 — 확장 하나가 개발 PC 전체를 여는 열쇠

이번 주 가장 눈여겨본 건 이 대목임. MCP는 AI 도구가 외부 시스템과 붙기 위한 연결 규격인데, 문제는 이 서버·확장들이 패키지 매니저에서 그냥 설치된다는 점임. 설치하는 순간 그 코드는 개발자의 로컬 환경, 소스 저장소, 클라우드 자격증명이 놓인 자리에서 실행됨.

공격자 입장에서 이만한 지렛대가 없음. 유명 확장과 한 글자 다른 이름을 올려두거나, 신뢰받던 패키지를 인수해 특정 버전부터 악성 코드를 끼워 넣는 방식이 반복적으로 관찰되고 있음. 실제 동작은 대개 조용함 — 환경변수와 토큰 파일을 읽어 외부로 한 번 보내고 끝임.

방어는 개발 환경을 운영 서버와 같은 급으로 취급하는 데서 시작함.

• 사용 중인 MCP 서버·확장의 목록을 문서로 관리하고, 버전을 고정(lock)해 자동 업데이트로 몰래 바뀌지 않게 함
• 새 확장 도입 시 게시자 계정의 이력, 저장소 활동, 최근 소유권 변경 여부를 확인. 다운로드 수만 보고 판단하지 않기
• 개발자 PC의 아웃바운드 트래픽을 살펴 낯선 도메인·짧은 수명 도메인으로 나가는 통신을 탐지. 공급망 악성코드는 결국 한 번은 밖으로 나가야 함
• 장기 유효 토큰을 파일로 두지 말고 단기 자격증명으로 바꾸기. 유출돼도 수명이 짧으면 피해가 줄어듦

4. 라우터 뒷문 — 아무도 로그를 보지 않는 장비

네트워크 장비에서 발견되는 백도어성 계정과 숨은 관리 인터페이스는 매번 반복되는 주제인데, 이번 건도 결이 같음. 문제의 본질은 취약점 자체보다 그 장비를 아무도 모니터링하지 않는다는 사실임. 몇 년 전 설치하고 펌웨어를 한 번도 올리지 않은 장비가 실제로 꽤 많음.

확인할 것은 세 가지면 충분함. 관리 화면이 외부에서 열려 있는가, 기본 자격증명이 그대로인가, 펌웨어 버전이 벤더의 최신 공지와 맞는가. 여기에 더해 라우터의 시스템 로그를 중앙 로그 서버로 보내두면, 나중에 사고가 났을 때 조사할 거리가 남음. 로그가 없으면 침해 여부를 확인할 방법 자체가 사라짐.

이번 주에 실제로 손댈 만한 것

• AI 에이전트·자동화 봇이 쓰는 토큰을 전부 나열하고 권한 범위를 한 줄로 적어보기
• Metabase, Grafana 같은 내부 대시보드류가 외부에 노출돼 있는지 확인
• 개발 환경에 설치된 MCP 서버·확장 목록을 뽑고 버전 고정
• 네트워크 장비 펌웨어 버전 목록화 및 로그 전송 설정

네 건을 한 줄로 묶으면 이렇게 됨. 공격은 이제 방화벽을 뚫는 대신, 우리가 이미 신뢰한 통로를 타고 들어옴. 그래서 이번 주 숙제는 새 장비를 사는 게 아니라 자산 목록을 다시 그리는 일이라고 생각함. 저도 주말에 집 공유기 펌웨어부터 확인하려고 함. 여러분도 딱 하나만 골라서 오늘 확인해보면 어떨까 싶음. 어떤 항목부터 손대셨는지 댓글로 알려주시면 저도 참고하겠음. 같이 해보아요!