스노우플레이크 데이터 유출: 해커, 인포스틸러 감염을 통한 접근 확인

• 2024년 5월 31일, 클라우드 기업 스노우플레이크가 대규모 데이터 유출을 겪음
• 해커는 인포스틸러 감염을 통해 접근했다고 허드슨 록에 확인해줌
• 해커는 티켓마스터와 산탄데르 은행을 포함한 여러 주요 회사의 데이터를 러시아어 사이버 범죄 포럼에 판매함

해킹 방법

• 해커는 스노우플레이크 직원의 ServiceNow 계정에 도용된 자격 증명을 사용해 로그인함.
• OKTA를 우회하여 세션 토큰을 생성하고 대량의 데이터를 유출함.
• 해커는 약 400개의 회사가 영향을 받았다고 주장함.

추가 증거

• 해커는 허드슨 록 연구원들에게 스노우플레이크 서버에 대한 접근 권한을 보여주는 CSV 파일을 공유함.
• 이 파일은 스노우플레이크의 유럽 서버와 관련된 2,000개 이상의 고객 인스턴스를 문서화함.

해커의 목표

• 해커는 스노우플레이크에게 2천만 달러를 요구하며 데이터를 되찾으려 함.
• 회사는 이에 응답하지 않음.

인포스틸러 감염의 증가

• 인포스틸러 감염은 2018년 이후 6000% 증가하여 주요 초기 공격 벡터로 자리잡음.
• 이는 랜섬웨어, 데이터 유출, 계정 탈취, 기업 스파이 활동 등을 포함한 사이버 공격을 실행하는 데 사용됨.

GN⁺의 의견

• 사이버 보안의 중요성: 이번 사건은 기업이 사이버 보안에 더욱 신경 써야 함을 보여줌. 특히 직원들의 자격 증명 관리가 중요함.
• 인포스틸러의 위협: 인포스틸러는 매우 빠르게 확산되고 있으며, 기업은 이에 대한 대비책을 마련해야 함.
• 대응 전략: 해킹 사건 발생 시 신속한 대응과 피해 최소화 전략이 필요함. 스노우플레이크의 대응이 늦어 피해가 커짐.
• 보안 교육: 직원들에게 보안 교육을 강화하여 자격 증명 관리와 피싱 공격에 대한 인식을 높이는 것이 중요함.
• 대체 솔루션: 스노우플레이크와 유사한 기능을 제공하는 다른 클라우드 저장소 솔루션을 고려해 볼 수 있음. 예를 들어, AWS S3나 Google Cloud Storage 등이 있음.

[GN⁺]

Hacker News 의견들

• 현재 링크된 URL이 /로 302 리다이렉트됨. @dang, 아래 아카이브 링크로 교체하는 게 나아 보임
  https://web.archive.org/web/20240531140540/https://www.hudso...

  • @dang 호출은 아무 효과 없으니, 푸터의 이메일로 연락하는 편이 나음
    다만 Hudson Rock이 블로그 글을 내린 것도 흥미로운 신호라서, 그냥 아카이브 링크로 바꾸고 넘어가면 안 됨. 무엇이 바뀐 걸까?
    추가: Snowflake의 공식 답변은 원문 글의 핵심 주장을 사실상 전부 부인하는 듯함. Hudson Rock이 부정직한 정보원에게 속았고, 실수를 깨닫고 글을 내린 것일 수도 있음
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

• Snowflake의 Felipe임. 이 이슈에 대한 Snowflake의 최신 입장은 여기 있음: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
  추가 소식이 있으면 이 URL을 계속 갱신하겠음

  • 링크가 기업식 표현으로 너무 가득해서 명확히 확인하고 싶음. Hudson Rock 글은 Ticketmaster와 Santander Bank 침해가 Snowflake 직원의 탈취된 자격 증명 때문에 발생했다고 명시적으로 주장함
    그런데 Snowflake의 “영향받은 고객 계정과 유사하게, 위협 행위자가 전직 Snowflake 직원 소유의 데모 계정에 대한 개인 자격 증명을 얻어 접근했다는 증거를 찾았다. 민감한 데이터는 없었다”라는 문장은 Snowflake가 Hudson Rock의 설명을 거짓으로 본다는 뜻으로 읽힘. 이 이해가 맞는가?
  • Hudson Rock의 원글은 단순히 한 고객의 자격 증명이 털린 게 아니라, 직원 자격 증명이 탈취됐고 2단계 인증이 없어서 그 엔지니어의 권한으로 다른 고객 계정에 들어갔다는 뜻으로 읽힘
    반면 Snowflake 글은 고객 계정 자격 증명이 유출됐고, 그걸로 끝이며 중앙 계정이나 다른 계정 접근은 없었다는 식으로 보임. 2단계 인증이 없는 직원 계정 정보 사용에 대해서는 아무 말도 없음
    Snowflake가 내부 직원의 모든 접근 자격 증명에 2단계 인증을 원할 것은 분명함. 예전에는 고객이 원하면 자기 데이터에 로그인하기 위해 이름/비밀번호만 만들고 2단계 인증 없이도 접근할 수 있었음
  • 여기 기사에 대해 직접적인 코멘트가 나올 예정인가?
  • salesforce.com 서버가 일시적으로 요청에 응답할 수 없다고 나옴. 불편을 끼쳐 죄송하며 잠시 후 다시 시도해 달라는 메시지만 보임

• 채팅 로그 스크린샷이 정말 인상적임. 이 회사는 실제 범죄자와 소통 중이라고 주장하고, 그 범죄자는 이 회사를 썼다면 침해를 막는 데 도움이 됐을 거라고 말함
  그래서 이 회사의 신뢰도에 대한 판단을 갱신했음

  • 순수한 추측이지만, 해커가 Snowflake에게 무시당하자 Hudson Rock과 접촉해서, 몸값을 내지 않은 Snowflake에 보복하려는 목적으로 이 보도를 터뜨릴 홍보 기회를 제공한 것처럼 보임
    Hudson Rock은 거기에 맞춰 실제보다 더 큰 침해처럼 부풀려 이야기를 띄운 듯함. 해커가 Hudson Rock에 먼저 갔는지, 아니면 받아준 첫 회사가 Hudson Rock이었는지도 궁금함
  • 그 대화는 기괴하고 만화 같음. 어떻게 받아들여야 할지 모르겠음
    “Hudson Rock의 보호를 샀어야 했고, 그러면 이번 건을 막을 수 있었을 것”
    “맞다, 분명 도움이 됐을 것”
  • 랜섬웨어나 보호비 갈취에서 흔한 완곡어법임. Akira 그룹이 감염된 머신에 남기는 메시지 중 좋아하는 게 대략 이런 식임
    “축하합니다. 귀사는 깜짝 정보보안 감사를 통과했고 랜섬웨어 피해자가 되었습니다.”
    [...]
    제공 항목: 1) 전체 복호화 지원 2) 데이터 삭제 증거 3) 발견한 취약점 보안 보고서 4) 데이터를 공개하거나 판매하지 않겠다는 보장 5) 향후 공격하지 않겠다는 보장
    결국 당신이 급여 명단에 올린 줄 몰랐던 보안 컨설팅 회사일 뿐임
    참고로 데이터 삭제 증거로 뭘 주는지 봤더니, 문자 그대로 rm -vrf data의 표준 출력뿐이었음. 부재의 증거를 제공하는 게 불가능하고 피해자에게 협상력이 없다는 건 이해하지만, 이 연출은 꽤 마음에 듦
  • 스크린샷을 보면 이건 완전히 조작됐거나, 아니면 완전히 마케팅 목적으로 보임
    설령 실제라 해도 Hudson Rock 메시지는 빼는 게 상식적이었을 것임. 이 회사는 머릿속 블랙리스트에 올렸음
  • 암묵적인 갈취처럼 들림

• 가해자의 표현만 보면, Snowflake는 단일 관리자 계정 하나로 모든 것에 전권을 주는 식으로 시스템을 설계한 것 같음
  Snowflake가 5월 31일 발표에서 “일부 고객에게 영향을 준 업계 전반의 신원 기반 공격”을 조사 중이라고 말한 점도 Ticketmaster와 Santander 이야기에 신빙성을 더함
  https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
  위협 행위자가 제대로만 했다면 역대 최대급 데이터 유출 중 하나가 될 수도 있음

  • 글이 암시하는 건 그렇지만 과장된 것 같음. 안타깝게도 탈취된 자격 증명의 주인을 식별할 만큼 정보가 제공돼 있고, 그 사람은 세일즈 엔지니어임
    데이터는 고객이나 잠재 고객용 데모를 만들 때 쓰던 그 사람의 Snowflake 계정에서 나온 듯함. 고객들이 실제 데이터 일부를 데모에 쓰라고 접근 권한을 줬을 가능성은 있지만, 고객의 Snowflake 데이터베이스 자체에 무제한 접근했다는 것과는 거리가 큼
    해커가 데모용 가짜지만 그럴듯한 데이터를 빼냈고, 그 차이를 모를 가능성도 충분함
  • Hudson Rock이 프로세스를 모르면서 추측하거나 권위 있는 척하려는 게 문제임
    한 명의 세일즈 엔지니어는 여러 계정을 담당함. Snowflake 세일즈 엔지니어는 보통 고객 환경 안에서 구축하지 않고, 누구나 만들 수 있는 400달러 크레딧 데모 계정을 세팅함. 데모 계정은 시간이 지나면 만료되기 때문에 계속 새로 만듦
    세일즈 엔지니어는 만든 데모 계정 안에서 구축하고 고객에게 보여줌. 30일 뒤 Snowflake는 신용카드가 없으면 계정을 잠그고, 이후 데모 인스턴스와 데이터를 삭제함
    작업을 위해 고객은 자기 Snowflake 인스턴스에서 세일즈 엔지니어가 만든 데모 인스턴스로 데이터를 공유하거나, SSO를 통해 그 Snowflake 세일즈 엔지니어에게 접근 권한을 줄 수 있음
    어느 쪽이든 조직들이 보안 태세를 충분히 제한적으로 운영하지 않은 문제에 가까움. 열심히 일하던 세일즈 엔지니어와, 직원/계약자/게스트 권한 범위를 제대로 제한하지 않은 고객을 찾았다는 점 외에는 새로울 게 없는 공격임
  • 약 1년 전 Snowflake 지원을 받은 경험으로는, Snowflake 팀이 뭔가를 보거나 하려면 고객 계정의 관리자가 Snowflake에 명시적으로 접근 권한을 부여해야 했고, 기억하기로 그 접근에는 만료 기간도 있었음
  • 위협 행위자가 제대로 움직였다면 역사상 가장 큰 데이터 침해가 될 가능성이 큼
  • 적절한 직원을 상대로 한 서비스형 악성코드 공격 한 번으로 전부 가능했다는 얘기임. 사용된 것은 Lumma였음
    흥미롭게도 첫 페이지에는 동유럽 NGO를 대상으로 Pegasus가 쓰였다는 인접한 이야기도 있음. 최소 권한 원칙도 중요하지만, 기기 보안도 중요함
    https://news.ycombinator.com/item?id=40535912

• Snowflake 직원은 아니지만 Snowflake와 그 세일즈 엔지니어 조직과 많은 시간을 함께 일함
  고객과 데모를 만들 때 세일즈 엔지니어들은 누구나 만들 수 있는 400달러 Snowflake 데모 계정으로 시연 환경을 만듦. 데모를 만들려면 고객이 그 세일즈 엔지니어에게 접근 권한을 주고, 세일즈 엔지니어는 일부 데이터를 데모 환경으로 가져가 작업함. Hudson Rock이 공개한 환경 이름도 이를 뒷받침함
  내가 보기엔 데이터를 공유하던 사람의 ID를 고객이 만료시키지 않았고, 위협 행위자가 자격 증명을 훔친 프로세스 문제임. 취약점 공격이 아니므로 새로울 건 없음
  그리고 Hudson Rock, 컴퓨터에 악성코드가 있어서 피해를 본 사람을 공개적으로 드러낸 걸 축하함. 계약자에게 자격 증명을 줬는데 그게 탈취된 경우와 다르지 않음. 아주 못된 짓임

  • “새로운 취약점 공격”이 아니라고 해서 큰일이 아닌 건 아님
    Snowflake는 세일즈 엔지니어의 자격 증명이 탈취될 수 있고, 그 자격 증명은 다단계 인증을 우회할 수 있으며, 기사에 따르면 만료도 없음. 이건 스트라이크 1, 2, 3임
    Snowflake의 보안 관행은 고객이 넓은 데이터셋 접근 권한을 Snowflake 직원에게 공유하도록 요구되거나 최소한 장려되는 상황을 만들었음. 스트라이크 4임
    고객이 너무 넓은 접근 권한을 부여한 책임도 있지만, 이런 접근이 필요 없도록 더 나은 시스템을 만들지 않았거나 최소한 이 전이적 접근을 더 잘 감독·통제하지 못한 책임은 Snowflake에도 있음
    이런 계정이 고객 데이터에 접근 권한을 받는 순간 더 이상 “데모 계정”이 아님. 실제 계정이고, 실제로 매우 가치 있는 데이터를 가진 계정이므로 그렇게 취급해야 함
    추가: Snowflake는 해당 데모 계정이 고객 데이터에 접근하지 않았고 유출의 출처도 아니라고 주장하며, 이는 공격자 주장과 모순됨
  • 침해된 계정의 로그인 이름을 언급한 건 정말 비전문적이고 불필요해 보임
  • Hudson Rock의 주요 제품 중 하나인 “Bayonet” 설명은 이렇음
    “전 세계 수십만 개의 침해된 회사와 활성 취약점을 갖춘 잠재고객 발굴 플랫폼에 접근해, 이들을 고객으로 전환할 수 있다고 상상해 보세요.”
    이런 유형의 회사를 몇 군데 봤고 상대해 봤는데, 꽤 저급한 전술이고 기술적으로도 숙련도나 노력 수준이 낮음
  • Hudson Rock의 다른 글 몇 개를 빠르게 읽어봤는데, 상당수가 “우리에게 보호를 샀어야지” 같은 식으로 끝남. 보호비 장사 냄새가 남
  • 블로그 글 전체가 극단적인 자기찬양 냄새가 나고, 피해자를 노출한 건 정말 쓰레기 같은 행동이 맞음. 전체적으로 Hudson Rock의 성과는 매우 형편없음

• Snowflake 공식 답변에는 이렇게 되어 있음
  “우리는 이것이 고객 데이터를 얻으려는 의도의, 업계 전반에서 진행 중인 신원 기반 공격의 결과라고 봅니다. 조사에 따르면 이러한 공격은 관련 없는 사이버 위협 활동을 통해 노출된 고객의 사용자 자격 증명으로 수행됩니다. 현재까지 이 활동이 Snowflake 제품 내의 취약점, 설정 오류, 악의적 활동 때문에 발생했다고 보지는 않습니다.”
  [0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

• 기사를 비공개로 돌린 것 같지만, Wayback Machine에는 아직 남아 있음: https://web.archive.org/web/20240531140540/https://www.hudso...

  • 보기 좋지 않음. 뭔가 틀렸다면 이런 주장과 비난을 한 뒤에는 정정문이 적절함. 아무 설명 없이 글만 지우는 건 무책임하고 비전문적임

• 이 글은 며칠 전 Ticketmaster 침해가 실제로는 Snowflake 직원의 도난당한 자격 증명을 통해 400개 이상 회사에 영향을 준 훨씬 광범위한 해킹이었다고 주장함
  지금은 hudsonrock.com에서만 보도하는 큰 이야기처럼 보임. Hudson Rock은 처음 들어보는데, 신뢰할 만한 출처인지 아는 사람이 있나?

  • Hudson Rock은 그들의 “CEO”가 몇 달 동안 수많은 침해를 주장하는 저품질 블로그 스팸을 보안 관련 서브레딧마다 뿌리기 시작하면서 처음 알게 됨
    여러 계정이 Reddit 운영자와 관리자에게 금지됐음. 개인적으로는 신뢰할 만하거나 믿을 만한 출처로 보지 않음
  • Santander 은행의 상당한 해킹에 대한 BBC News 보도가 있고, Snowflake와 연결돼 있음
    https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
  • Snowflake 직원들이 자기 주식을 다 팔 시간을 벌어야 함. 이 소식은 SNOW 주가에 큰 타격을 줄 것임

• Snowflake는 자기 잘못이 아니라 고객 잘못이라고 말하는 듯함
  https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
  https://www.hudsonrock.com/blog/snowflake-massive-breach-acc...가 완전히 지어낸 이야기가 아니라면 Snowflake는 사실을 조금 덜 정직하게 말하고 있음
  “조사에 따르면…”이라는 표현은 자체 조사인지 일반 보안 연구인지 모호함. “Snowflake 제품 내 취약점, 설정 오류, 악의적 활동 때문이라고 보지 않는다”는 문구도 가능한 시나리오들을 열거해 아니라고 하면서, 실제로 어떻게 일어났는지는 능숙하게 빠뜨림
  Hudson Rock을 믿는다면 Snowflake는 악성 행위자에게 연락을 받았으니, 어떻게 발생했는지 꽤 잘 알고 있었을 가능성이 높음

  • 인용한 문장 안에서 어떻게 일어났는지 암시하지 않나?
    “관련 없는 사이버 위협 활동을 통해 노출된 고객의 사용자 자격 증명으로 수행”됐다고 했으니, 지어낸 게 아니라면 자격 증명이 다른 곳에서 확보됐다고 보는 듯함
    마지막에는 고객에게 계정 설정을 검토하라고 했으니, 책임을 자기들에게서 돌리는 방향임. 다만 현재 출처가 해킹당했다는 회사와, 이 사건을 이용해 자기 제품을 홍보하면서 직원을 뻔뻔하게 신상 공개한 회사라서 더 자세한 정보가 나올 때까지 기다려야 할 듯함
  • 아니면 제대로 된 심층 분석 없이 고객 쪽이 침해됐다고 가정하고 그들에게 책임을 돌렸을 수도 있음
    해커는 리프레시 토큰을 만료시키지도 않았다고 주장하는데, 사실이라면 엄청나게 크고 명백한 문제임

• 기사는 “수백 고객 침해”라는 제목과 그다지 일관되지 않아 보임
  첫째, lift/okta 비밀번호는 ServiceNow 포털 접근만 허용하고 고객 계정 접근은 아닌 듯하므로, 리프레시 토큰 문제는 ServiceNow 포털에 제한되고 실제 고객 Snowflake 계정의 데이터 노출과는 관련 없어 보임
  둘째, 10개 회사 계정이 침해됐다는 스크린샷에는 서로 다른 Snowflake 계정 자격 증명 4개가 보이며, 그중 하나는 개인 데모 계정처럼 보임. 따라서 최대 3개 고객 침해 정도는 설명할 수 있지만, 다른 고객 침해를 보여주는 세부 정보는 없음
  세일즈 엔지니어가 작업하던 모든 고객에 대한 모든 자격 증명이 침해됐다고 가정해도, 침해 고객 수는 아마 낮은 두 자릿수일 것임. 각 고객 계정이 세일즈 엔지니어에게 접근 권한을 개별적으로 부여했어야 하기 때문임
  내부 Okta 포털의 리프레시 토큰 문제를 근거로 Snowflake 고객 전체가 침해됐다고 말하는 건 큰 비약이고, 그 문제는 어떤 고객 Snowflake 계정과도 연결돼 있지 않음

  • 침해된 계정이 정확히 어떻게 구성됐고 어떤 접근 권한을 받았는지 모르면 말하기 어려움. 내가 아는 “보안 중심 대형 통신사”에서도 어떤 기술 인력이 어떤 수준의 접근 권한을 갖는지 보면 놀랄 것임. 물론 모든 접근은 기록됨
  • ServiceNow 안에 다른 곳으로 횡적 이동하는 데 쓸 수 있는 자격 증명 등이 있었을 가능성은 충분함. 물론 추측임