민감한 정보 유출, 채팅 기록 포함한 DeepSeek 데이터베이스 노출

 (wiz.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • DeepSeek의 외부 공격 표면 점검 과정에서 인증 없이 열린 ClickHouse 데이터베이스가 발견됐고, DeepSeek는 제보 뒤 노출을 즉시 차단함
  • 노출 지점은 oauth2callback.deepseek.com과 dev.deepseek.com의 8123·9000 포트였으며, 외부에서 데이터베이스 전체 제어와 내부 데이터 접근이 가능했음
  • log_stream 테이블에는 100만 건 이상의 로그가 있었고, 2025년 1월 6일부터의 채팅 기록, API Keys, 백엔드 세부 정보, 운영 메타데이터가 평문으로 포함됨
  • ClickHouse HTTP 인터페이스의 /play 경로로 브라우저에서 임의 SQL 쿼리를 실행할 수 있었지만, Wiz Research는 윤리적 연구 관행에 따라 열람 범위를 열거 수준으로 제한함
  • AI 서비스의 빠른 도입에서 당장의 위험은 모델 자체뿐 아니라 데이터베이스의 우발적 외부 노출 같은 기본 인프라 보안 문제에서도 발생함

인증 없이 열린 DeepSeek ClickHouse 데이터베이스

  • Wiz Research는 DeepSeek에 속한 공개 접근 가능 ClickHouse 데이터베이스를 식별함
  • 해당 데이터베이스는 인증 없이 접근 가능했고, 내부 데이터 열람뿐 아니라 데이터베이스 작업을 완전히 제어할 수 있는 상태였음
  • 노출된 정보에는 채팅 기록, API Keys, 백엔드 세부 정보, 로그 스트림, 운영 세부 정보가 포함됨
  • Wiz Research는 문제를 DeepSeek에 즉시 제보했고, DeepSeek는 노출을 빠르게 차단함

외부 공격 표면 조사와 노출 지점

  • DeepSeek는 중국 AI 스타트업으로, DeepSeek-R1 추론 모델을 통해 최근 큰 주목을 받음
    • DeepSeek-R1은 OpenAI의 o1 같은 선도 AI 시스템과 성능 면에서 경쟁한다고 알려짐
    • 비용 효율성과 효율성이 주요 특징으로 다뤄짐
  • Wiz Research는 DeepSeek의 외부 공격 표면을 평가하기 위해 공개 도메인을 조사함
  • 수동·능동 하위 도메인 탐색으로 약 30개의 인터넷 노출 하위 도메인을 식별함
    • 대부분은 챗봇 인터페이스, 상태 페이지, API 문서처럼 초기에는 고위험 노출로 보이지 않는 항목이었음
  • 표준 HTTP 포트인 80/443을 넘어 탐색하자 8123과 9000 포트가 열려 있음이 확인됨
    • 대상 호스트는 oauth2callback.deepseek.com과 dev.deepseek.com이었음

/play 경로를 통한 SQL 실행

  • 확인된 포트는 인증 없이 접근 가능한 ClickHouse 데이터베이스로 이어짐
  • ClickHouse는 대규모 데이터셋의 빠른 분석 쿼리를 위해 설계된 오픈소스 컬럼형 데이터베이스 관리 시스템임
    • Yandex가 개발함
    • 실시간 데이터 처리, 로그 저장, 빅데이터 분석에 널리 사용됨
  • ClickHouse의 HTTP 인터페이스에서 /play 경로를 이용하면 브라우저에서 임의 SQL 쿼리를 직접 실행할 수 있었음
  • SHOW TABLES; 쿼리로 접근 가능한 데이터셋 목록이 반환됐고, 그중 log_stream 테이블이 특히 민감한 로그를 담고 있었음

log_stream에 담긴 민감 로그

  • log_stream 테이블에는 100만 건 이상의 로그 항목이 포함됨
  • 주요 컬럼과 노출 정보는 다음과 같음
    • timestamp: 2025년 1월 6일부터의 로그
    • span_name: 다양한 내부 DeepSeek API 엔드포인트 참조
    • string.values: 채팅 기록, API Keys, 백엔드 세부 정보, 운영 메타데이터를 포함한 평문 로그
    • _service: 로그를 생성한 DeepSeek 서비스 표시
    • _source: 로그 요청의 출처를 노출하며, 채팅 기록, API Keys, 디렉터리 구조, 챗봇 메타데이터 로그 포함
  • 이 수준의 접근은 DeepSeek 자체 보안과 최종 사용자에게 중대한 위험을 만들 수 있었음
  • 공격자는 민감 로그와 실제 평문 채팅 메시지를 가져갈 수 있었고, ClickHouse 설정에 따라 SELECT * FROM file('filename') 같은 쿼리로 서버의 평문 비밀번호, 로컬 파일, 독점 정보를 직접 유출할 가능성도 있었음
  • Wiz Research는 윤리적 연구 관행을 지키기 위해 열거를 넘는 침입적 쿼리를 실행하지 않음

AI 도입 속도와 인프라 보안 리스크

  • AI 애플리케이션의 즉각적인 보안 위험은 모델 자체보다 이를 지탱하는 인프라와 도구에서 발생할 수 있음
  • AI 보안 논의가 미래형 위협에 집중되는 동안에도, 데이터베이스의 우발적 외부 노출 같은 기본 보안 위험은 보안팀의 최우선 과제로 남아야 함
  • 조직이 다양한 스타트업과 제공업체의 AI 도구·서비스를 빠르게 도입하면서, 민감 데이터를 이들 회사에 맡기는 경우가 늘어남
  • 빠른 도입 속도는 보안을 간과하게 만들 수 있으므로, 고객 데이터 보호가 우선순위가 되어야 함
  • 보안팀은 AI 엔지니어와 긴밀히 협력해 사용 중인 아키텍처, 도구, 모델에 대한 가시성을 확보해야 데이터 노출을 막을 수 있음
  • AI 기업들이 광범위한 도입에 통상 수반되는 보안 프레임워크 없이 핵심 인프라 제공자로 빠르게 성장하고 있어, 민감 데이터 처리 위험에 맞는 보안 관행이 필요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 아마 엄청 멍청하고 주제에서 벗어난 질문일 수 있는데, 왜 데이터베이스 스키마와 로그가 영어로 되어 있는지 궁금함
    DeepSeek 개발자가 이 시스템을 의도대로 쓸 때도 컬럼, 키 등을 영어로 보게 되는 건가? 보통 번역 단계가 있는 건지, 아니면 전 세계 개발자들이 대부분의 도구를 쓰기 위해 어쩔 수 없이 영어를 배워야 하는 건지 궁금해짐
    비영어권 소프트웨어 엔지니어링에 대해 내가 많이 모른다는 걸 깨달음

    • 정확히 그렇게 됨. 개발자가 비영어권 국가 출신이어도 코드와 데이터베이스가 영어로 작성되는 건 드물지 않음
      생각해보면 도구 체인, 프로그래밍 언어, 라이브러리가 어차피 전부 영어 기반임
    • 영어가 예상보다 덜 자연스러운 곳에서 보이면 신뢰도가 낮아 보일 수 있지만, 이렇게 생각해볼 수 있음: Yandex가 만든 ClickHouse 데이터베이스가 전부 러시아어로 되어 있었다면 중국 개발자들이 채택했을까?
      질문 자체에는 일리가 있음. 비즈니스/도메인 관련 용어는 원래 언어로 남겨야 한다는 암묵적 규칙이 있고, 이게 끝없는 좌절의 원천이 되기도 함. 안 그러면 실제 사례처럼 "Leitungsauskunft"가 "line information"이나 "channel interface"로 번역될 수 있음. 정확히는 "pipeline inquiry"가 맞고, 독일 정부에서 발급받을 수 있는 문서의 한 종류임
      아이러니하게도 지금 일하는 환경에서는 그런 용어를 번역하기로 했는데, 비즈니스 로직 이해에는 전혀 도움이 되지 않았음. 게다가 누군가 "더 정확한 번역"을 들고 올 때마다 놀라움과 논쟁거리가 추가됨
      결국 영어는 고유명사까지 번역하려 들기 전까지는, 산전수전 겪은 개발자의 흔적처럼 보임
    • 몇 년 전 비영어 환경에서 일해봤는데, 어떤 맥락에서는 현지어를 쓰기도 하지만 대부분은 영어를 쓰게 됨
      프로그래밍 언어와 API의 영어에 다른 언어가 섞이면 꽤 어색하게 느껴지기 때문임
    • 거의 모든 소프트웨어 엔지니어가 어느 정도 영어는 배움. 진짜로 지역화된 프로그래밍 환경은 꽤 별난 편이고, 떠오르는 대부분의 주류 사용 사례에는 사실상 사용 가능하지 않음
      회사 문화와 정책에 따라 가장 흔한 모습은 영어 변수명/함수명에 모국어 주석이 섞이는 형태임. 가끔 모국어 변수명과 함수명도 보이는데, 내 경험상 라틴 문자권 언어, 특히 스페인어와 포르투갈어 사용자 사이에서 훨씬 흔함. 중국어 코드 대부분은 대략 영어식 변수명과 함수명을 쓰는 것처럼 보임
    • 영어 원어민이지만, 비영어권 개발자들이 작성한 여러 코드베이스를 보면 대체로 그 말이 맞는 듯함
      얼마 전까지만 해도 많은 컴파일러가 비ASCII 주석조차 안정적으로 처리하지 못했고, 변수명과 함수명은 말할 것도 없었음

  • 이 문제는 DeepSeek에 책임 있게 공개했고, 수정된 뒤 게시했으며, 오늘 DeepSeek 팀으로부터 기여에 대한 확인을 받았음

    • 이 "dev" 도메인들이 실제 프로덕션 데이터를 담고 있었던 건가? 블로그 글만으로는 명확하지 않음

  • 흥미로운 점: 개발 인프라, 관측성 데이터베이스(OpenTelemetry 스팬), 그리고 로그에는 당연히 채팅 데이터가 들어감. 로깅을 하면 결국 그렇게 되기 때문임
    공유된 충격적인 로켓 제작 프롬프트 스크린샷은 당연히 놀라움을 주려는 의도겠지만, 스팬 속성에 "finish_reason":"stop"이 포함된 걸 보면 아마 DeepSeek이 그런 프롬프트를 완성하지 않도록 막기 위한 학습 데이터였을 가능성이 큼
    그래도 명백히 꽤 나쁜 상황이고 추가 침해로 쉽게 이어질 수 있었지만, Wiz는 이걸 어디까지 밀어붙일 수 있는지 보기보다 현재의 미디어 흐름을 타고 글을 낸 것 같음. 공개되고 빠르게 패치된 건 다행임

    • 내가 이해하기로 API 응답에서 종료 이유가 “stop”이라는 건 보통 AI가 출력을 정상적으로 끝냈다는 뜻임. 어쨌든 학습 데이터가 프로덕션 로그에 들어갈 이유도 모르겠고, 일반 사용자가 쓸 법한 프롬프트에 응답하지 않도록 막고 싶어 했을 이유도 잘 모르겠음
      보안 연구자들은 발견 사실을 확인하는 수준을 넘어서 더 파고들지 말아 달라는 요청을 자주 받음. 더 진행하는 게 도움이 안 되거나 실수로 일을 망칠 수 있기 때문임. 이 연구자들이 DeepSeek 시스템을 깊게 테스트하도록 초대받은 건 아닐 테니, 예의 있는 접근이었다고 봄
      그래도 이 실수는 DeepSeek 입장에서는 완전 아마추어 수준임. 보안 쪽에 깊이 파고든 사람은 아니지만 뭔가 찾는다면 제일 먼저 서버에 nmap을 돌려 열려 있는 흥미로운 포트가 있는지 볼 것 같음. 다른 사람들도 이미 찾았어도 전혀 놀랍지 않음

  • 공개로 노출된 ClickHouse는 지난 10년간 흔했던 공개 노출 Elasticsearch의 이번 세대 버전 같음

    • 내가 알기로 오픈소스 Elasticsearch는 설치 직후 인증을 제공하지 않았던 기간이 여러 해였지만, ClickHouse는 인증을 제공함. 오히려 수년간 도입된 인증 메커니즘이 꽤 많고 쉽게 설정할 수 있어서 종종 놀람
      비밀번호 인증(bcrypt, sha256 해시), 인증서 인증(서버 간 통신에 훌륭함), SSH 키 인증(개인적으로 가장 좋아함. 개발자가 쉽게 작업할 수 있게 모든 데이터베이스가 이런 인증 방식을 가져야 한다고 봄)이 있음
      인기는 덜하지만 LDAP와 HTTP 인증 서버도 좋은 선택지임
      DeepSeek 엔지니어들이 ClickHouse 인스턴스를 어떻게 배포했는지도 궁금함. yum/apt install로 배포하면 설치 단계에서 말 그대로 기본 비밀번호를 입력하라고 물어봄
      ClickHouse 바이너리로 수동 설정하더라도 기본 구성은 외부 네트워크 접근을 막고, 기본 사용자는 Alex가 여기서 설명한 것처럼 localhost에만 노출됨: https://news.ycombinator.com/item?id=42871371#42873446
    • 원래는 공개 노출 MongoDB였고, 그다음은 MySQL/phpMyAdmin, 그다음은 노출된 FTP, 그다음은 노출된 Telnet이었음
    • 내가 나이 들었다는 게 드러남. 아직도 “노출된 Elasticsearch” 시대인 줄 알았음
    • 공개 노출 S3 버킷은 지난 10년간 흔했던 공개 노출 S3 버킷의 이번 세대 버전임

  • DeepSeek에 내가 모르는 버그 바운티 프로그램이 있고 범위가 명확히 정의되어 있나? 보기에는 Wiz가 허락 없이 DeepSeek 시스템을 탐색하고 접근한 뒤 글을 쓴 것처럼 보임
    이런 일을 할 때 연구 대상 회사가 어떤 형태로든 허가를 주지 않았다면, 미국의 CFAA나 전 세계 다른 법률 아래에서 큰 곤란을 겪을 수 있음
    이 사례를 따라 하지 말아야 함. 탐색하고 접근하기 전에 버그 바운티 프로그램에 등록하거나 회사와 직접 협업해 허가를 받고, 허가된 접근 범위를 넘지 말아야 함

    • 그런 자세 잡기는 불필요함. 첫 문단에 말 그대로 이렇게 나옴:

      The Wiz Research team immediately and responsibly disclosed the issue to DeepSeek, which promptly secured the exposure

    • 공개 노출된 데이터베이스를 열어둔 건 DeepSeek 쪽임. 글을 게시하기 전에 회사에 알렸을 거라고 봄. 왜 Wiz를 탓하는지 모르겠음
    • 동의하지만, DeepSeek이 문제를 고쳤고 Wiz를 상대로 법적 조치를 하지 않겠다는 암묵적인 신사협정 같은 게 있었을 가능성도 있음. Wiz가 도움이 됐고 악의적인 행동을 하지 않았기 때문임
      나도 예전에 비슷한 일을 했음. 어떤 교육 플랫폼 스타트업의 웹 서버가 잘못 설정되어 있어서 .git에 접근 가능했고, 로컬로 저장소를 복제할 수 있었음. 문제가 생길까 봐 일회용 계정으로 즉시 이메일을 보내 설정 문제를 알렸음. 그들은 경고와 제안에 감사했고, 심지어 자기 회사에 취업할 수도 있다고 말했음
    • 이 얘기 때문에 일회용 계정으로 씀
      Wiz 사람들은 수상한 행태로 악명 높음. 선을 많이 넘음. Amazon과 Microsoft에도 이런 식으로 해서 이름을 알렸고, 매우 비윤리적임
      제품 자체는 끔찍하진 않지만 영업 인력은 정말 별로임. 완전히 정떨어짐. 대부분 Zscaler 출신 멍청이들임
    • CFAA는 미국 법임. 설령 위반했다고 해도 그게 실제 문제가 되려면 미국 검사가 시간을 내서 기소해야 함. DeepSeek이 미국 내 존재감이 있기는 한가?
      마찬가지로 중국 법을 위반했을 수도 있음. 하지만 중국 밖에서는 별 의미가 없음

  • 아이러니함. DeepSeek R1에게 ClickHouse 설정 방법을 물으면 올바른 방법을 알려줄 것 같음

  • 웹 브라우저에서 임의의 SQL 쿼리 실행이 가능하다고 상상해볼 수 있나? :D
    인증 없이 DeepSeek 환경 안에서 데이터베이스를 완전히 제어하고 잠재적으로 권한 상승까지 가능했음

  • 그래서 모델을 로컬에서 돌려야 함. 원격 채팅 모델을 원한다면 서버에 저장된 채팅이 남지 않도록 AWS Bedrock custom model import 같은 상태 비저장 방식을 쓰는 게 나음

    • 게이머가 아닌 사람들 중에는 그런 모델을 로컬에서 돌릴 수 있는 하드웨어를 가진 사람이 많지 않음. 기술 역량은 말할 것도 없음
      대부분의 사람에게 bash는 컴퓨터와 상호작용하는 도구가 아니라, 컴퓨터에 대한 좌절을 표현하는 방식임. 가끔 키보드가 망가지기도 함
    • Nvidia의 신뢰 실행 환경에서 돌아가는 모델을 쓸 수도 있음

  • Big Tech가 의미 있는 경쟁자(DeepSeek)에게 위협받자마자, 그 경쟁자는 “훔쳤다”(웃음)고 몰리고, 주요 온라인 추론 포털은 강한 해킹 공격을 받음
    이게 Big Tech의 진짜 얼굴임. 무료로 제공한 포털 뒤에 서비스를 가둬 경쟁을 죽이고, 나중에 사용자에게서 돈을 짜내는 것만으로는 충분하지 않은 듯함. 더럽게, 정말 더럽게 싸우기도 함

  • 좋은 발견임. 이런 윤리적 해킹과 책임 있는 공개에서 보통 타임라인이 잘 논의되지 않는 것 같음

답변달기