▲

내부 호스트명이 클라우드에 유출될 때

 (rachelbythebay.com)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 가정용 NAS 장비의 웹 인터페이스가 내부 전용 호스트네임을 외부 서비스로 전송하는 사례 발견
  • NAS 웹 UI에 포함된 sentry.io 오류 보고 스크립트가 스택 트레이스와 함께 내부 호스트네임을 외부로 전송
  • sentry.io 측에서 해당 호스트네임으로 TLS 연결을 역으로 시도하지만 실제 요청은 보내지 않는 이상한 동작이 관찰됨
  • 와일드카드 DNS를 미리 설정해 둔 덕분에 유출 사실을 탐지할 수 있었으며, 민감한 호스트네임 사용 시 심각한 정보 노출 위험 존재
  • 이 메커니즘을 악용하면 임의의 호스트에 대한 DNS 스캔을 유도할 수 있는 잠재적 보안 문제

NAS 설치와 내부 호스트네임 구성

  • NAS 장비를 구매해 드라이브를 장착하고 홈 네트워크에 연결, HTTPS 모드로 운영
  • 공개 인터넷에서 의미 없는 도메인의 하위 서브존(예: *.nothing-special.whatever.example.com)에 대한 와일드카드 TLS 인증서를 설치
  • /etc/hosts 파일에 172.16.12.34 nas.nothing-special.whatever.example.com과 같은 로컬 전용 항목을 추가하여 브라우저에서 접근

외부로부터의 예상치 못한 접속 발견

  • NAS 설치 며칠 후, 동일한 호스트네임으로 외부("outside world")에서 요청이 들어오기 시작
  • 해당 호스트네임은 노트북의 /etc/hosts 파일에만 존재하는 완전히 내부 전용 이름
  • 사전에 *.nothing-special.whatever.example.com 전체에 대해 자신이 관리하는 머신으로 향하는 와일드카드 DNS 항목을 설정해 두었기 때문에 유출을 탐지 가능
  • NAS를 로드할 때마다 GCP 호스트가 해당 내부 호스트네임을 SNI로 제시하며 접속을 시도

유출 원인: sentry.io 오류 보고

  • NAS 웹 인터페이스에 폰홈(phone home) 기능이 포함되어 있으며, 그 일부로 sentry.io에 스택 트레이스를 전송
  • 브라우저가 sentry.io에 콜백하면서 내부 스토리지 장비에 사용하는 호스트네임을 함께 전달
  • sentry.io 측에서 해당 호스트네임으로 TLS 연결을 역으로 생성하지만, 실제 HTTP 요청은 전혀 보내지 않는 동작 확인

보안 시사점과 대응

  • 호스트네임에 민감한 정보(예: mycorp-and-othercorp-planned-merger-storage 같은 이름)를 포함할 경우 심각한 정보 유출 위험
  • 이 sentry 보고 메커니즘을 이용해 임의의 외부 호스트에 대한 DNS 스캔을 유도하는 것이 가능(구체적 방법은 독자에게 맡김)
  • 대응 조치로 Little Snitch를 실행해 해당 도메인 전체를 모든 앱에 대해 차단 처리
▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 사람들이 오해하고 있는 것 같음. 이건 CT 로그 문제가 아니라 와일드카드 인증서 관련임
    Sentry가 클라이언트 측 트레이스를 수집하면서 요청을 보낸 호스트명을 추출해 그걸 다시 폴링하려다 거부당한 상황임

    • 아마도 트레이스 UI에서 보여줄 favicon을 가져오려는 시도였을 수도 있음
    • 하지만 이런 구조라면 Sentry가 임의의 IP로 요청을 보낼 수 있는 보안 취약점이 생길 수 있음. 특히 자동으로 악성 트래픽을 신고하는 IP에 반복적으로 접근할 수도 있음
    • 사람들이 헷갈리는 이유는 블로그 글이 너무 혼란스럽고 불명확하게 작성되어 있기 때문임

  • 호스트명은 본질적으로 비공개 정보가 아님
    DNS 쿼리나 TLS 인증서 등 여러 경로로 외부에 노출됨
    비공개 서비스를 숨기려면 호스트명 대신 URL 경로에 비밀을 넣는 게 나음
    예시로 fileservice.example.com/my-hidden-service-007-abc123/처럼 하면 HTTPS로만 전달되어 노출이 훨씬 적음

    • 물론 이 경우에도 Sentry 같은 외부 서비스로 경로가 전송될 수 있으므로, 불투명한 URL을 쓰고 비밀을 URL에 넣지 않는 습관이 필요함
    • “HTTP만 쓴다면 이런 노출이 줄어드나?”라는 질문도 있었음

  • “clown GCP Host”가 기술 용어인지 궁금했음. 알고 보니 작성자가 cloud를 풍자해서 쓴 표현이었음
    NAS 웹 인터페이스가 Sentry로 로그를 보내면서 내부 호스트명이 포함된 게 문제의 핵심임
    나는 이런 경우 신뢰할 수 있는 오픈소스 OS로 교체하거나, PiHole 같은 DNS 차단으로 Sentry 호출을 막을 것 같음

    • “clown”은 Big Tech의 cloud를 비꼬는 표현으로, 예전 IRC에서도 “clown computing”이란 말을 썼다고 함
      어떤 이는 로컬 DNS와 TLS 프록시를 써서 외부로 나가는 트래픽을 완전히 차단한다고 설명함
    • 또 다른 사람은 “clown”이 대형 클라우드 제공자와 그 사용자를 풍자하는 오래된 용어라고 덧붙였음
    • 어떤 이는 “clown” 대신 “weenie”라는 단어를 쓰기도 한다고 농담함
    • “서커스는 떠났지만 광대들은 남았다”는 식의 유머도 있었음

  • 이런 사례 때문에 나는 uBlock Origin을 웹 보안의 최소 기준으로 봄
    대부분의 웹페이지가 제3자 스크립트를 잔뜩 불러와 데이터를 새는 게 너무 심각함
    근본적인 해결은 아니지만, 당장 우리가 할 수 있는 최선임

    • 나도 AdGuard Home을 라우터에 설치했는데 트래픽의 15~20%가 차단됨. 추적과 광고가 얼마나 심한지 실감함

  • 이런 문제를 막으려면 Nginx 리버스 프록시를 앞단에 두고 CSP 헤더를 주입하는 게 좋음
    이렇게 하면 NAS가 외부로 요청을 보내는 건 막지 못하지만, 브라우저가 대신 요청하는 건 차단 가능함
    예를 들어 Steam 아바타 요청(https://avatars.steamstatic.com/HASH_medium.jpg)도 CSP 정책으로 막을 수 있음
    필요하면 일부만 열어두면 됨. 또 Referrer-Policy: no-referrer를 추가해 호스트명이 외부 로그에 남지 않게 함

    • 누군가는 “ATM machine”이라며 중복 표현을 지적했고
    • 또 다른 사람은 “NPM은 꽤 간단함”이라며 농담처럼 답했음

  • 나는 Synology NAS를 샀는데 여러 번 후회했음
    커뮤니티 소프트웨어 외에는 할 수 있는 게 거의 없음
    Let's Encrypt로 SSL 적용도 복잡하고, 경로가 비표준이라 설정 위치를 찾기 힘듦
    오래된 rsync 버전, 기본 유틸 부족 등 불만이 많음. 차라리 리눅스나 BSD 기반 NAS를 쓸 걸 그랬음

    • Synology는 파일 서버로만 쓰면 매우 안정적이라 만족한다는 의견도 있었음. 다만 폐쇄적인 정책 때문에 UniFi NAS로 옮길 계획이라는 사람도 있었음
    • “서버를 원하면서 NAS가 서버가 아니라고 불평하는 건 모순”이라는 반응도 있었음
    • Synology NAS에 최신 Debian을 올리는 가이드가 Doozan 포럼에 있다고 공유한 사람도 있었음
    • “그냥 파일/iscsi 서버로만 두면 매우 안정적이니 건드리지 말라”는 조언도 있었음
    • 반대로 RS217 모델을 $100에 사서 최고의 구매였다고 한 사람도 있었음. Synology Office를 Google Docs 대신 쓰고, UI 완성도에 감탄했다고 함

  • 최근 Sentry를 설정해봤는데, 이 시스템이 자동으로 업타임 모니터링을 구성하려는 기능이 있음
    호스트를 인식하면 주기적으로 핑을 보내고, 며칠 안정적으로 응답하면 “이 호스트에 업타임 모니터링을 설정할까요?”라는 알림을 띄움

    • 누군가는 “확장 기회”라고 짧게 코멘트함

  • 나는 개인적으로 Sentry 관련 도메인 전체를 차단함
    일반적인 해결책은 아니지만 내 환경에서는 그게 최선임

  • 역방향 주소 조회 서버는 내부 네트워크 주소(ULA, RFC1918)까지도 해석하려는 시도를 종종 봄
    이런 데이터를 다른 정보와 결합하면 내부 상태를 추론할 수 있음
    “Darknet 수집 중 UDP 오디오가 포착된 적도 있다”고 함

    • 이에 대해 “그 UDP 오디오는 어느 해의 SIP 트래픽이었는가?”라는 질문이 나왔음

  • 예전에 Heroku에서 비슷한 현상을 조사했음
    새 앱을 만들면 무작위 서브도메인이 부여되는데, DNS 조회를 하지 않아도 바로 취약점 스캐너의 요청이 들어옴
    Heroku에 문의하니, 새 앱의 URL이 인증서 투명성(CT) 로그에 공개되기 때문이라고 함

    • 누군가는 “이건 새 서비스마다 ‘나를 공격해 주세요’ 표지판을 붙이는 셈”이라며, CT 로그에 실제 인증서 대신 해시만 기록했어야 했다고 지적함
      Certificate Transparency 작동 방식 링크도 공유함
    • 또 다른 사람은 “나는 와일드카드 도메인을 써서 그런 문제를 피하고 있다”며 스크린샷(이미지 링크)을 올렸음
답변달기