GN⁺: 900개 사이트, 1억 2500만 계정, 1개 취약점

첫 번째 시도

• 파이썬으로 작성된 기본적인 스캐너가 Firebase 설정 변수를 체크함.
• 메모리 소모 문제로 인해 한 시간 내에 작동 중단.

두 번째 시도

• Go 언어로 재작성된 스캐너는 메모리 누수가 없음.
• 5백만 개 이상의 도메인을 스캔하는 데 예상보다 더 많은 시간 소요.

모든 도메인 수동 확인

• 55만 줄 텍스트 파일의 각 항목을 수동으로 검사함.
• 136개 사이트와 620만 개의 기록을 확인했으나, 자동화된 방법이 필요함을 인식.

촉매

• 잠재적으로 영향을 받을 수 있는 사이트 목록을 촉매라는 보조 스캐너로 검사함.
• 사이트나 .js 번들에서 공통 Firebase 컬렉션에 대한 읽기 접근을 자동으로 확인함.
• 데이터의 영향력을 평가하기 위해 100개의 기록 샘플을 수집하고 정보 유형을 확인함.
• 결과를 저장하기 위해 Supabase(오픈 소스 Firebase 경쟁자)를 선택함.

숫자

• 전체 기록: 1억 2460만 5664개
• 이름: 8422만 1169개
• 이메일: 1억 626만 766개
• 전화번호: 3355만 9863개
• 비밀번호: 2018만 5831개
• 결제 정보: 2748만 7924개
• 이 숫자들은 실제보다 클 수 있음을 유의.

영향을 받은 사이트 목록

1. Silid LMS

• 학생과 교사를 위한 학습 관리 시스템.
• 가장 많은 사용자 기록 노출, 2700만 명 영향.

2. 온라인 도박 네트워크

• 9개의 사이트로 구성되며, 모두 서로 다른 디자인.
• 일부 게임은 당첨 확률이 0%로 조작됨.
• 문제를 보고하려 할 때 고객 지원이 유혹을 시도함.
• 가장 많은 은행 계좌 정보 노출, 800만 개.
• 가장 많은 평문 비밀번호 노출, 1000만 개.

3. Lead Carrot

• 콜드 콜링을 위한 온라인 리드 생성기.
• 노출된 사용자 정보가 많은 상위 3개 사이트 중 하나, 2200만 명 영향.

4. MyChefTool

• 식당을 위한 비즈니스 관리 앱 및 포인트 오브 서비스 애플리케이션.
• 가장 많은 이름과 두 번째로 많은 이메일 노출, 각각 1400만 개와 1300만 개.

결과

• 13일 동안 842개의 이메일 발송.
• 85% 이메일 도달.
• 9% 이메일 반송.
• 24% 사이트 소유자가 설정 오류 수정.
• 1% 사이트 소유자가 회신.
• 0.2% (2개) 사이트 소유자가 버그 바운티 제공.

GN⁺의 의견

• 이 연구는 Firebase 보안 설정의 잘못된 구성이 얼마나 쉽게 발생할 수 있는지를 보여줌. 이는 개발자들에게 보안 설정에 대한 경각심을 일깨우는 중요한 사례.
• 보안 문제가 발견되었을 때 사이트 소유자들의 반응이 다양했음을 알 수 있음. 대부분은 문제를 수정했지만, 일부는 무시하거나 적절한 보상을 제공하지 않음.
• 이러한 보안 취약점을 찾기 위해 사용된 자동화 도구는 다른 보안 연구자들에게도 유용할 수 있음. 비슷한 기능을 제공하는 도구로는 OWASP ZAP, Burp Suite 등이 있음.
• Firebase와 같은 클라우드 서비스를 사용할 때는 보안 설정을 정확히 이해하고 적용하는 것이 중요함. 잘못된 설정은 대규모 데이터 유출로 이어질 수 있음.
• 이 사례는 오픈소스 대안인 Supabase를 포함한 다른 서비스를 고려할 때, 보안 기능과 사용 용이성을 비교하는 데 도움이 될 수 있음. Supabase는 PostgreSQL을 기반으로 하며, Firebase와 유사한 기능을 제공하지만 오픈소스임.

[neo]

Hacker News 의견

• Firebase에서 오랜 기간 근무한 한 사용자는 보안 규칙과 관련된 문제가 항상 제품을 괴롭혔다고 언급함. 여러 접근 방식을 시도했지만 여전히 많은 데이터베이스가 보안에 취약함을 발견함. 이는 Firebase의 보안 규칙이 새롭고 복잡한 개념이기 때문이며, 개발자들이 기존 데이터에 새로운 데이터를 추가할 때 보안 규칙을 수정하지 않는 경향이 있음. 또한, 맞춤형 백엔드 구현이 없어 대량 스캔이 쉬워지고, 실시간 데이터베이스의 보안 규칙 작성이 어렵고 확장성이 떨어짐. 그러나 자동화된 스캔이 열려 있는 데이터만 찾는 경우가 많아 이 문제는 생각보다 자주 발생하지 않음. Firebase 접근 방식 자체에는 기술적인 문제가 없지만, 저장된 데이터와 보안 규칙을 기반으로 하는 유일한 백엔드 중 하나이기 때문에 오해와 부적절한 사용, 그리고 이러한 문제에 취약함.
• 한 사용자는 이 상황이 미국의 패스트푸드 체인들을 해킹한 사례를 떠올리게 한다고 언급함.
• 다른 사용자는 이 포스트의 마지막 부분에 따르면, 이러한 취약점을 가진 사이트의 75%가 여전히 데이터 덤프를 기다리고 있다고 지적하며, 이는 미친 일이라고 평가함. 컴퓨터를 다루기 위해 자격증이 필요하다고 생각하는 날도 있다고 덧붙임.
• 한 사용자는 저렴하고 빠른 것을 선택하는 것이 불가피한 결과라고 지적하며, 일부 고객/사용자의 우려는 대화에서 누락되었고, 그들의 개인정보가 대가가 되었다고 언급함. 여기에 나열된 회사 중 리더십이 바뀌지 않은 회사는 조심해야 한다고 경고함. 많은 회사들이 고객을 보호하는 데 충분히 신경 쓰지 않는다는 것이 반복적으로 증명되었기 때문임.
• 다른 사용자는 이 포스트에서 언급된 대부분의 앱이 전적으로 정적으로 호스팅된 클라이언트 측 자바스크립트로 구현되었으며, 백엔드가 100% Google에 의해 호스팅된 Firebase 구성인지에 대해 기본적인 질문을 함. 만약 그렇다면, 수백만 명의 사용자를 가진 사이트에 이러한 아키텍처가 얼마나 일반적인지 깨닫지 못했다고 언급함.
• 한 사용자는 900개의 사이트, 1억 2500만 개의 계정, 1개의 취약점, 0개의 여자친구라는 농담을 함.
• 또 다른 사용자는 이러한 상황으로 인해 오래전에 비밀번호 관리자와 가상 카드를 선택한 것에 감사함을 표현함. 대부분의 사람들이 웹이 얼마나 취약하고 그들이 얼마나 취약한지 알지 못한다며 인터넷이 더 무섭게 느껴진다고 언급함.
• 한 사용자는 약 500개의 스레드를 가진 파이썬 프로그램이 시간이 지남에 따라 메모리를 점점 더 많이 사용한다는 것을 발견하고, 이 문제에 대한 추가 정보나 해결책이 있는지 질문함. 자신의 파이썬 스크레이퍼도 수백 개의 스레드를 가지고 있으며 많은 메모리를 사용하는 것 같다고 언급함.
• 한 사용자는 좋은 일을 했다고 칭찬하며, 어떻게 영향을 받은 사용자 수가 더 많을 것으로 추정하는지에 대한 결론에 도달했는지 알고 싶어 함. 언급된 일부 사이트(도박, 리드 캐럿)는 가짜 계정 데이터로 가득 차 있을 것으로 의심됨.
• 마지막으로 한 사용자는 고객 지원이 웃음을 줬다고 감사함을 표현함.