1P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • 보안 연구자가 홈디포 직원이 실수로 온라인에 게시한 GitHub 접근 토큰을 발견해, 1년간 내부 시스템이 외부에 노출되어 있었다고 밝힘
  • 해당 토큰은 수백 개의 비공개 소스 코드 저장소에 접근 및 수정 권한을 제공했고, 클라우드 인프라·주문 처리·재고 관리 시스템 등에도 접근 가능했음
  • 연구자는 홈디포에 여러 차례 이메일과 LinkedIn 메시지를 보냈으나 수주간 응답이 없었음
  • 홈디포는 TechCrunch가 연락한 이후에야 노출을 수정하고 토큰 접근을 철회함
  • 홈디포에는 취약점 신고나 버그 바운티 제도가 없어, 이번 사건은 보안 대응 체계 부재의 문제를 드러냄

홈디포 내부 시스템 접근 노출 사건 개요

  • 한 보안 연구자가 홈디포 직원이 온라인에 게시한 비공개 접근 토큰을 발견
    • 이 토큰은 2024년 초부터 노출된 것으로 추정됨
    • 연구자는 이를 통해 홈디포의 GitHub 저장소 수백 개에 접근 및 수정이 가능함을 확인
  • 노출된 키는 홈디포의 클라우드 인프라, 주문 처리 시스템, 재고 관리 시스템, 코드 개발 파이프라인 등 다양한 내부 시스템 접근을 허용
    • 홈디포는 2015년부터 개발 및 엔지니어링 인프라 대부분을 GitHub에 호스팅 중임

연구자의 경고와 회사의 대응

  • 연구자 Ben Zimmermann은 홈디포에 여러 차례 이메일을 보냈으나 수주간 응답이 없었음
    • 홈디포의 최고정보보안책임자(CISO) Chris Lanzilotta에게 LinkedIn 메시지를 보냈지만 답변이 없었음
  • Zimmermann은 최근 몇 달간 다른 기업들의 유사한 노출 사례를 보고했고, 대부분의 기업은 감사의 뜻을 표했음
    • 그는 “홈디포만이 나를 무시했다”고 언급

TechCrunch 개입 이후 조치

  • 홈디포에는 취약점 신고나 버그 바운티 프로그램이 존재하지 않음
    • 이에 Zimmermann은 TechCrunch에 연락해 문제 해결을 요청
  • TechCrunch가 12월 5일 홈디포 대변인 George Lane에게 연락하자, 이메일 수신은 확인했으나 이후 추가 질의에는 응답하지 않음
  • 이후 노출된 토큰은 온라인에서 제거되었고, 접근 권한도 TechCrunch의 연락 직후 철회됨

추가 확인 요청 및 미응답

  • TechCrunch는 홈디포가 로그 등 기술적 수단을 통해 해당 토큰이 다른 사람에 의해 사용되었는지 확인할 수 있는지 문의했으나 답변을 받지 못함
  • 이로 인해 실제 외부 접근 여부나 피해 규모는 확인되지 않은 상태임

사건의 의미

  • 이번 사례는 대형 기업에서도 기초적인 접근 키 관리 실패가 장기간 방치될 수 있음을 보여줌
  • 또한 보안 취약점 신고 체계의 부재가 문제 해결을 지연시킬 수 있음을 드러냄
  • TechCrunch의 개입 이후에야 조치가 이루어진 점은 외부 감시의 중요성을 부각함
Hacker News 의견들
  • TechCrunch가 Home Depot에 노출된 액세스 토큰 관련 문의를 했지만, 회사는 법무팀으로 사안을 넘기고 침묵 모드에 들어간 듯함
    아마도 향후 나올 공식 입장은 법률적 표현으로 가득한 책임 회피형 문장일 것임

    • 그래서 나도 이런 경우엔 바로 우편으로 법무팀에 연락함
      실제 법적 사안일 수도 있어서, 그쪽은 읽고 조치할 수 있는 사람이 대응함
      예전에 은행이 신원 확인 문제로 나와 연락을 끊었을 때도, 편지 한 통으로 바로 해결된 경험이 있음
    • 요즘처럼 소송 리스크가 큰 환경에서는 Home Depot의 대응이 현실적으로 맞는 선택이라 생각함
      물론 우리는 내부 분석 보고서를 보고 싶지만, 주주 중심의 세상에서는 조심스러울 수밖에 없음
  • 지난주에 실수로 내 OpenAI, Anthropic, Gemini API 키를 노출했음
    Claude Code 로그에 키가 그대로 찍혀 있었는데, Anthropic은 즉시 메일을 보내 키를 비활성화했음
    반면 OpenAI와 Google은 아무런 알림이 없었음
    특히 Google의 Gemini 키는 찾는 데만 10~15분이 걸렸고, 여전히 활성 상태로 보였음
    요즘처럼 vibe coding이 많을수록 발급자와 사용자 모두 키 관리 위생이 중요해짐

    • 이렇게 세분화된 키 관리가 너무 많아지니, 오히려 보안 불안감이 커지고 뭘 하고 있는지도 모르겠음
    • “vibe coding”이란 말을 듣자마자 등골이 서늘해짐
      이미 brogramming으로 인한 보안 사고도 많은데, 그게 100배로 늘어날 수도 있음
    • 키가 어떻게 새나갔는지 궁금함
      단순히 Claude Code 로그에 남은 거라면, Google이 그걸 인지했다는 게 놀라움
  • 나도 예전에 개인 GitHub PAT를 실수로 공개 저장소에 올린 적이 있었음
    그때마다 GitHub이 즉시 토큰을 비활성화하고 알림을 보냈음

    • GitHub의 자동 토큰 감지 기능이 꽤 인상적이었음
      내 경우엔 큰 피해는 없었지만, 시스템이 잘 작동했음
  • “Home Depot 2x4” 농담처럼, 1년 동안 마음껏 자재를 가져갈 수 있었다면 누군가 나무 구체라도 만들었을 것 같음

    • 하지만 목재가 심해 환경에서 얼마나 버틸지는 모르겠음
  • 비밀 관리(secrets management) 를 어떻게 하면 좋을지 고민 중임
    지금은 수동으로 SSH 접속해서 .env 파일을 수정하고 있음

    • 단일 앱이라면 .env 파일로도 충분함
      어차피 앱이 침해되면 메모리에 비밀이 남기 때문에 노출은 피할 수 없음
      가능하다면 IP 기반 접근 제한을 걸어두는 게 가장 강력한 방어책임
    • SOPS를 쓰면 관리 범위를 줄일 수 있음
      Age를 백엔드로 쓰면 서버에 하나의 장기 개인키만 두면 됨
    • 또는 VM 플랫폼의 네이티브 시크릿 기능이나 1Password API를 활용하는 것도 방법임
  • 누군가 “그 정보로 어떤 피해를 줄 수 있었을까?”라고 물었음

    • 내부 소스코드 전체를 다운로드해 취약점을 분석하거나,
      GitHub을 배포에 사용한다면 악성 기능을 프로덕션에 주입할 수도 있음
    • 예를 들어 Atlas Lion이라는 해킹 그룹은 대형 리테일러의 내부 시스템을 노려
      기프트카드 탈취로 수익을 내고 있음
      최근에는 Salesloft의 GitHub을 통해 AWS로 침투해 OAuth 토큰을 훔쳐 수백 개의 Salesforce 고객 계정에 접근한 사례도 있음
  • 공개된 문자열이 실제 API 키인지 단순한 랜덤 값인지 구분하기 어렵음

    • 그래서 요즘은 많은 서비스가 키 앞에 pat_, sk_ 같은 접두사(prefix) 를 붙임
  • Open Source Home Depot”라는 말이 묘하게 잘 어울림

  • GitHub이나 OpenAI가 자체적으로 토큰 해시 스캔 자동화를 제공하지 않는 게 의외임
    고객 안전을 위해 간단히 구현할 수 있을 것 같음
    플랫폼 독립적인 스캐닝 서비스를 만들면 어떨까 제안함

    • GitHub은 이미 비밀 스캐닝 프로그램을 운영 중임
      예전엔 Discord 토큰이 노출되면 즉시 비활성화되고 시스템 계정이 DM을 보냈음
    • GitHub의 스캐닝은 꽤 정교함
      공식 문서에 따르면
      주요 공급자별 패턴을 자동 검증하고, 필요 시 토큰을 자동 폐기함
      다만 GitHub 외부에 노출된 토큰은 탐지하기 어려움
    • 그래도 여전히 누락되는 경우가 많음
      나는 버그 바운티 프로그램을 통해 종종 유출된 키를 보고함
      아쉽게도 Home Depot은 버그 바운티가 없음
    • 토큰이 공개 저장소 커밋에서 발견된 것인지 궁금함
      GitHub의 무료 스캐너로도 충분히 탐지 가능함
    • GitHub은 다양한 SaaS/PaaS 업체와 자동 토큰 검증 및 폐기 파트너십을 맺고 있음
  • 누군가는 이 내부 시스템 데이터로 내부자 거래 수준의 일을 할 수도 있었을 것이라 언급함