Hacker News

Muse exposes users' personal and business secrets when they share conversations

Muse 대화 공유 링크에서 개인·기업 정보 노출

Meta의 AI 에이전트 Muse가 공유 대화 링크를 쉽게 찾아낼 수 있는 구조를 사용해 민감한 정보가 노출됐습니다. 보안업체 Claroc은 링크 6,800개를 열거했고, Meta는 조사와 설계 변경 검토를 위해 공유 기능을 중단했습니다.

에디터 노트

확인된 노출 경로는 Muse의 모든 대화가 공개된다는 뜻이 아니라, 사용자가 공유한 대화 링크가 Passive DNS 기록에서 발견될 수 있다는 문제입니다. 링크를 열어야 DNS 정보가 기록된다는 조건도 있습니다. 따라서 쟁점은 사용자가 공유 기능으로 공개한 콘텐츠를 얼마나 쉽게 수집할 수 있었느냐에 있습니다. 댓글에서 공유 링크와 전체 대화 공개를 구분해야 한다는 질문이 나왔고, 다른 댓글은 고유 호스트 이름이 DNS 기록에 남는 구조를 설명했습니다. 이 설명은 기사에 나온 수집 경로와 맞닿아 있습니다. Meta가 공유 기능을 중단했지만, 링크 생성 방식 변경 여부와 이미 만들어진 링크의 처리 방식은 제공된 자료에 나오지 않습니다. 개인용 에이전트의 유용성이나 클라우드 서비스 전반의 신뢰 문제는 댓글에서 논쟁이 이어졌지만, 이번 사례에서 확인된 사실과는 구분해야 합니다.

AI 요약

Meta의 AI 에이전트 Muse에서 대화와 검색 결과 등을 공유할 때 만드는 링크가 쉽게 발견될 수 있다는 사실이 드러났습니다. 보안업체 Claroc 연구진은 링크 6,800개를 열거해 수백 개를 확인했고, 공개를 의도하지 않은 정보가 포함된 대화를 찾았습니다. 여기에는 AI 연구소와의 비공개 임원 채용 면담을 준비한 메모, CEO에게 전달된 기업 매출 검토 자료, 소상공인의 대출 신청액, 계좌 일부와 거래 내역이 적힌 은행 사기 경보 등이 있었습니다. 부동산 투자 실적과 직원 수십 명의 휴가 일정도 확인됐습니다.

링크가 발견된 경로

공유 기능은 특정 콘텐츠를 불러오는 URL을 만들고, 링크를 가진 사람이 페이지를 열 수 있게 합니다. 보통 링크에는 추측하기 어려운 긴 문자열을 넣어 무단 접근을 막습니다. Muse도 이런 방식처럼 보였지만, URL을 구성하는 설계 때문에 공유 링크를 찾아내기가 쉬웠다고 연구진은 설명했습니다.

Claroc 공동창업자 겸 CTO인 Asaf Aprozper는 연구진이 Meta의 버그 바운티 프로그램을 통해 10월 8일 제보했으며, LinkedIn으로 Meta 직원들에게 연락했지만 답변을 받지 못했다고 밝혔습니다. Ars의 질의에 Meta는 Muse의 버그 바운티 프로그램이 여러 사용 사례를 제보받기 위한 것이며, 링크 발견 방식을 검토하고 변경을 고려하는 동안 공유 기능을 중단한다고 답했습니다.

Passive DNS가 드러낸 링크

연구진이 링크를 찾는 데 사용한 방법은 Passive DNS 검색입니다. Passive DNS 시스템은 DNS 리졸버나 다른 인프라에 설치한 센서가 관찰한 DNS 응답을 기록합니다. 누군가 공유 링크를 열어 DNS 조회가 일어나면 고유 호스트 이름이 기록되고, 이후 검색 가능한 데이터베이스에 남습니다. 연구진은 이 기록에서 Muse 공유 링크를 찾아낼 수 있었습니다. 연구진은 사전에 예상했다면 링크 수집에 상당한 노력이 들 거라 봤겠지만, 실제로는 쿼리 한 번이면 됐다고 밝혔습니다.

Hacker News 반응

  • @omoikane — 여기서 얻을 교훈은 Passive DNS 기록 때문에 하위 도메인 이름을 조회할 수 있다는 점입니다. 추측할 수 없어야 할 정보를 하위 도메인 이름에 넣는 건 좋지 않은 설계입니다.
  • @JumpCrisscross — 분명히 하자면, 사용자가 이 대화를 누군가와 공유하려고 한 건가요? Meta가 추측하거나 열거하기 쉬운 기능 URL을 만든 건가요? 아니면 모든 Muse 대화가 알아내기 어려운 URL만 있으면 공개되는 건가요?
    • @fxwin — 전자인 것 같습니다. URL은 추측하거나 열거하기 쉽지만, 공유 기능으로 게시하지 않은 콘텐츠는 인증 뒤에 보호되는 구조 같습니다.
    • @cloudbonsai — Meta가 공유 대화마다 고유한 호스트 이름을 부여하는 것 같습니다. 예를 들면 fiscal-review-b4a5ff.cf.metaaiusercontent.com 같은 형태입니다. 링크를 열면 DNS 조회에 고유 호스트 이름이 드러납니다. 최초 제보자는 Passive DNS 기록에서 이런 URL을 수십 개 찾았습니다.
  • @piterrro — 역방향 DNS 조회로 쉽게 찾을 수 있는데 왜 DNS와 하위 도메인을 쓰는지 모르겠습니다. 고유한 URL을 생성했다면 쉽게 역조회되는 문제를 없앨 수 있었을 겁니다.
  • @Razengan — 피해자를 탓하려는 건 아니지만, 지금 Facebook 제품을 자발적으로 쓰는 사람이라면 어떤 일에 동의하는지 알아야 합니다.
  • @sksksk — 저는 개인용 AI 에이전트를 로컬에서 실행하고, 로컬 모델과 적당한 가격의 모델을 함께 씁니다. 몇 달 써보니 에이전트가 생활의 지루한 일을 많이 처리해 가족과 보낼 시간이 늘었습니다. 다만 Muse처럼 클라우드에서만 실행되는 서비스는 걱정됩니다. 집 네트워크에서 작동하는 소비자용 AI 에이전트 시장이 있을 거라고 봅니다.
    • @ad_fontes — 이 얘기가 나올 때마다 “모든 걸 해준다”, “인생이 바뀐다” 같은 막연한 답만 봅니다. 구체적으로 어떻게 쓰는 건가요? 저는 이런 말이 인터넷에 지나치게 몰입한 사람에게만 해당하는 것 같습니다.
    • @sksksk — 몇 가지 예를 들겠습니다. 이메일에서 영수증을 찾아 SQLite 데이터베이스에 구매 내역을 넣는 앱을 만들었습니다. 장보기 기록을 바탕으로 부족해질 물품을 예측하고, 매주 마트 사이트에 로그인해 배달 시간을 예약하고 필요한 물건을 담습니다. 기차가 지연되면 보상 신청도 자동으로 합니다. 이런 일은 대체로 결정적인 스크립트가 처리합니다. 지난달 토큰 비용은 하루 평균 2.6센트였습니다.
  • @skohan — 개인용 AI 에이전트가 유용하다는 점은 압니다. 하지만 대중을 위한 안전 문제는 이제 막 시작 단계입니다. 경험 있는 개발자도 에이전트를 샌드박스에 가두기가 쉽지 않습니다. 비밀번호를 모니터에 포스트잇으로 붙여두는 이모가 사기 메일을 전달하며 이런 도구를 쓴다고 생각하면 무섭습니다.

원문: Ars Technica / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗