▲

GN⁺: 당신은 단순히 비공개 보안 링크에 공개적으로 접근할 수 없습니다, 그렇지 않나요?

 (vin01.github.io)
2P by neo 5달전 | favorite | 댓글 1개

공개적으로 접근할 수 없는 개인 보안 링크, 정말 그럴까?

  • 인기 있는 멀웨어/URL 분석 도구들인 urlscan.io, Hybrid Analysis, Cloudflare radar URL 스캐너는 정보 수집과 공유를 위해 대량의 링크를 저장함.
  • 이러한 서비스들이 실수로 사용자에 의해 제출되거나 잘못 구성된 스캐너와 확장 프로그램에 의해 공개 데이터로 스캔된 개인적이고 민감한 링크들을 저장하고 있다는 사실은 널리 알려져 있지 않음.

어떤 링크들을 말하는 거지?

  • 클라우드 스토리지 도구(Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 등)를 사용하여 공유된 파일들.
  • 클라우드 연결 NAS 도구(Western Digital Mycloud 등).
  • 기업 커뮤니케이션(Slido, Zoom, Onedrive, Airtable 등).
  • 비밀번호 재설정 링크, Oauth 로그인 링크 등.
  • 이러한 서비스들은 무작위 식별자를 포함한 단일 개인 링크를 사용하여 서비스에 접근할 수 있게 하는 공통점이 있음. 때때로 비밀번호나 암호 구절을 사용하여 추가 보호되기도 하며, 이 경우 링크에 접근한다고 해서 데이터 노출이 발생하지 않음.

누가 책임져야 하나?

  • Hybrid Analysis와 urlscan.io의 이용 약관에 따르면, 제출된 콘텐츠에 대한 책임은 사용자에게 있으며, 민감한 링크를 검토하고 제거하는 메커니즘이 없음.
  • 자동화된 방식으로 이를 구현하는 것도 쉽지 않을 수 있음.
  • 보안 연구원으로서 이러한 링크의 출처를 파악하기 어려움.

우리는 위협 사냥꾼! 모든 링크는 우리의 것!

  • urlscan Pro는 유료 사용자/회사에게 Public뿐만 아니라 Unlisted 스캔에 대한 접근을 허용함.
  • Unlisted는 공개 페이지나 검색 결과에는 보이지 않지만, urlscan Pro 플랫폼의 고객에게는 보임.
  • TheHive의 Cortex-Analyzers는 urlscan.io 분석기에서 public:on 구성을 명시적으로 사용하여 링크가 unlisted로 나타나도록 함.
  • urlscan Pro 사용자들에게는 데이터가 공개되지 않지만 접근할 수 있으므로 더 많은 민감한 정보가 유출될 위험이 있음.

민감한 링크를 어떻게 제거할 수 있나?

  • Urlscan과 Hybrid Analysis는 링크를 플래그하여 제거할 수 있도록 함.
  • Hybrid Analysis의 경우, 공개 샌드박스에 제출된 모든 파일이 검색 가능하고 전 세계에 공개됨.

결론

  • 이 문제가 계속될 것임은 확실하지만, 스캔을 기본적으로 비공개로 유지하는 것이 가장 좋은 해결책일 수 있으나, 보안 커뮤니티의 위협 인텔리전스 및 분석 공유 관행의 목적에는 부합하지 않음.
  • 이러한 서비스를 사용할 때 스캔의 가시성에 주의해야 함.

면책 조항

  • url 데이터베이스에서 이러한 링크/파일에 접근하기로 선택한 경우, 실제 악성 파일과 링크에 주의해야 함.
  • 일부는 단순한 피싱 시도일 수 있으며 실제 멀웨어를 포함할 수 있음.
  • 샌드박스 환경을 사용할 것을 권장함.

유용한 링크

  • urlscan.io의 SOAR spot: Chatty security tools leaking private data (2022)
  • urlscan.io Search API Reference
  • Falcon Sandbox Public API
  • Cloudflare Radar URL Scanner

GN⁺의 의견

  • 이 기사는 보안 도구들이 어떻게 민감한 정보를 실수로 공개할 수 있는지를 보여줌으로써, 보안 연구원과 일반 사용자 모두에게 경각심을 일깨워줌.
  • 이러한 문제는 사용자의 실수나 도구의 잘못된 구성으로 인해 발생할 수 있으며, 이는 보안 커뮤니티 내에서 민감한 정보의 취급에 대한 더 많은 주의와 책임을 요구함.
  • 이 기사는 또한 개인과 기업이 자신의 데이터를 보호하기 위해 어떤 조치를 취해야 하는지에 대한 중요성을 강조함.
  • 비판적인 시각에서 볼 때, 이러한 유출은 개인의 프라이버시 침해와 기업의 기밀 유지에 심각한 위협이 될 수 있으며, 이는 보안 도구와 서비스의 신뢰성에 대한 의문을 제기할 수 있음.
  • 이와 유사한 기능을 제공하는 다른 프로젝트로는 VirusTotal이나 Any.run과 같은 멀웨어 분석 플랫폼이 있으며, 이러한 서비스를 사용할 때는 항상 데이터의 공개 여부를 신중하게 검토해야 함.
▲
neo 5달전  [-]
Hacker News 의견

  • 링크에 접근 제어가 없는 것이 기본적인 문제로, 공개적인 인덱스가 없기 때문에 사적이라고 가정된다. AWS 계정 ID를 버킷을 통해 발견하는 것과 관련된 이야기가 해커뉴스에서 인기를 끌었는데, 댓글에서 도출된 합의는 계정 식별자의 비공개성을 보안의 일부로 의존하는 것이 잘못된 접근이라는 것이다. 이는 단순히 또 다른 'dorking' 방법일 뿐이다.

    • 링크의 비공개성: 링크가 공개적으로 인덱싱되지 않는다는 이유로 사적이라고 가정하는 것은 문제가 있음. AWS 계정 ID의 비공개성에 의존하는 것은 보안상 올바르지 않은 접근이며, 이는 새로운 보안 이슈가 아니라 'dorking'의 한 형태임.

  • 개인적으로 공유 가능한 링크를 생성하려면 URL의 해시 부분에 비밀 정보를 저장해야 한다. 해시는 DNS 쿼리나 HTTP 요청에 포함되지 않는다. 예를 들어, links.com#<secret> 형식의 링크는 브라우저를 벗어나지 않는다. 해시 부분의 데이터를 URL 안전 Base64 문자열로 인코딩하는 것이 좋다.

    • 링크의 안전한 공유: URL의 해시 부분에 비밀 정보를 저장하여 링크를 안전하게 공유할 수 있음. 이 방법은 해시가 DNS 쿼리나 HTTP 요청에 포함되지 않기 때문에 더 안전함.

  • 무한 사용이 가능한 "사적인" 링크에 대해 항상 의심스러웠다. 이것은 단지 오브스큐리티를 통한 보안이다. 구글 문서와 같이 "URL을 가진 사람이라면 누구나 접근할 수 있다"는 명시적인 옵션이 있는 경우가 더 낫다. 필자가 구축한 시스템에서는 짧은 수명을 가진 서명된 URL을 사용하며, 이 URL은 사용자에게 직접 보여지지 않는다.

    • 사적인 링크에 대한 의구심: "사적인" 링크가 실제로는 오브스큐리티를 통한 보안에 불과하며, 짧은 수명을 가진 서명된 URL을 사용하는 것이 더 안전한 방법임.

  • 빠른 리다이렉트 루프의 일부가 아닌 링크는 복사되어 공유될 것이다. URL은 보편적이며, 프로토콜 상의 자원에 접근을 용이하게 한다. 짧지 않은 수명을 가진 모든 것에 대한 접근 제어는 URL 외부에서 이루어져야 한다. e2ee가 아닌 채널에서 링크를 공유할 때, URL에 처음 접근하는 주체는 전송 대상자가 아니라 채널의 서비스일 수 있다. 이러한 스캐너 도구는 사용자에게 스캔이 공개적임을 명시하면 UX가 개선되지 않을 것이다.

    • URL을 통한 접근 제어: URL은 자원에 대한 접근을 용이하게 하기 위해 공유되며, 접근 제어는 URL이 아닌 다른 방법으로 이루어져야 함. 스캐너와 같은 도구는 사용자에게 공개적인 스캔을 알리면 사용자가 서비스 사용을 망설일 수 있으므로 UX 개선에 도움이 되지 않음.

  • "이메일 기반 인증" 문제에 대한 해결책은 계정과 비밀번호를 만드는 단계 없이, URL이 실수로 공유되더라도 문제가 되지 않는 일회용 코드를 사용하는 것이다. 사용자가 "사적인" 링크를 방문하면, 사이트는 시간 제한이 있는 일회용 코드를 이메일로 다시 보내고, 사용자는 이메일 소유를 확인하기 위해 임시 코드를 입력한다.

    • 이메일 인증과 일회용 코드: 이메일 기반 인증 문제를 해결하기 위해 일회용 코드를 사용하며, 이는 URL이 실수로 공유되어도 문제가 되지 않음.

  • 인터넷에서 URL에 무작위 문자열 이상의 보호가 없다면 그것들은 사실상 사적이지 않다. 인터넷에 연결된 웹캠을 찾는 것과 같은 이야기다. 우리는 이미 이를 알고 있어야 한다. "누가 책임져야 하는가" 섹션에서 이를 언급하지 않는 이유는 무엇인가?

    • URL의 사적인 성격: URL에 무작위 문자열 이상의 보호가 없으면 사적이지 않으며, 이는 이미 알려진 사실임.

  • 주제에서 벗어난 이야기이지만, Cloudflare Radar가 1.1.1.1에서 데이터를 채굴한다는 링크가 있다. 1.1.1.1이 사용자 데이터를 어떠한 목적으로도 사용하지 않는다고 생각했는데?

    • Cloudflare Radar와 1.1.1.1: Cloudflare Radar가 1.1.1.1에서 데이터를 채굴한다는 주장이 있으며, 이는 1.1.1.1이 사용자 데이터를 사용하지 않는다는 기존의 인상과 상충함.

  • Zoom 회의 링크는 종종 쿼리 매개변수로 비밀번호를 추가한다. 이 링크가 "사적이고 안전한" 링크인가? 비밀번호 없이는 "사적이고 안전한" 링크인가?

    • Zoom 회의 링크의 안전성: Zoom 회의 링크에 비밀번호가 포함되어 있을 때와 없을 때의 안전성에 대한 질문.

  • 다음 두 가지 사례 중 어느 것이 더 안전한지 설명해 줄 수 있는가?

    1. domain.com/login 사용자: John 비밀번호: 5자리 무작위 비밀번호
    2. domain.com/12자리 무작위 URL 두 경우 모두 같은 무작위/속도 제한 보호를 가정하거나 전혀 없다고 할 때, 왜 1번이 2번보다 더 안전한가?
    • 로그인 안전성 비교: 두 가지 다른 로그인 방식의 안전성 비교에 대한 질문.

  • private airtable.com 앱에 업로드된 모든 미디어/사진은 공개 링크로, URL을 알고 있으면 인증 없이 접근할 수 있다.

    • Airtable.com의 공개 링크: Airtable.com에 업로드된 미디어/사진은 공개 링크로, URL만 알면 누구나 접근할 수 있음.
답변달기