우리 코드의 취약점을 제보하세요

만약 우리의 코드나 기반 시설에서 보안 취약점을 발견하였다면, 우리에게 제보하고 복잡성과 잠재적 영향력에 따라, 취약점당 최대 €10,000의 보상을 받으세요.

어떻게 취약점을 제보하나요?
적격 취약점은 무엇인가요?
범위 외 취약점은 무엇인가요?
제보할 수 있는 특수 시나리오는 무엇입니까?
취약점이 어떻게 분류되나요?
얼마를 보상 받을 수 있나요?
누가 보상에 적격합니까?
누가 취약점 제보의 타당성을 결정합니까?
내가 제보한 취약점에 대해 들으려면 얼마나 걸리나요?

취약점을 제보하는 방법

우리는 당신의 데이터와 소통을 안전하게 지키는 영지식 암호화의 장점을 이용하여, 당신의 보안 체인의 강력한 고리가 되고자 노력하고 있습니다. 그러나, 누구도 완벽하지 않고, 우리도 그렇습니다. 그것이 우리가 당신이 우리의 코드나 기반 시설에서 발견한 적격 취약점을 발견한 것을 듣는 것을 좋아하는 이유입니다.

우리에게 연락하기 전에, 이 페이지의 모든 정보를 읽고 안내를 따라주세요.

어떻게 취약점을 제보하나요?

우리는 잘 구성되고 문제를 명확히 설명한 제보를 가치 있게 여깁니다. 그래야 우리가 문제를 이해하고 재현해보고, 당신은 더 높은 보상금을 빠르게 받을 수 있기 때문입니다. 버그 보상금 제보를 쓰는 법에 대한 팁을 이 글에서 읽어볼 것을 권장합니다.

신고가 준비되면, bug@mega.nz로 보내주세요

적격 취약점은 무엇인가요?

  • SQL 인젝션 결함을 포함하여, 어느 우리 서버에 대한 원격 코드 실행.
  • 서버측 요청 변조.
  • 어느 클라이언트 브라우저에 대한 원격 코드 실행; 예를 들어, 크로스 사이트 스크립팅을 이용한 경우.
  • 우리의 암호화 보안 모델을 파괴하고 키 또는 데이터에 대해 허가 없는 원격 접근 또는 조작을 가능하게 하는 어떠한 것.
  • 키 또는 이용자 데이터에 대하여 허가 없는 덮어쓰기 또는 삭제를 가능하게 하는 접근 제어 및 인증 우회.
  • 연결된 이메일 주소가 탈취 되었을 때 이용자 계정 데이터를 위험하게 만드는 어떠한 문제.

범위 외 취약점은 무엇인가요?

  • 피싱이나 소셜 엔지니어링 공격처럼, 이용자의 상호작용을 능동적으로 요구하는 어떤 것.
  • 약한 이용자 계정 암호.
  • 탈취하기 위해 많은 숫자의 서버 요청을 요구하는 취약점.
  • 탈취된 클라이언트 기기를 요구하는 공격.
  • 지원하지 않거나 오래된 클라이언트 브라우저의 이용을 통해 발생하는 문제.
  • 물리적 데이터 센터 접근을 필요로 하는 어떤 문제 (탈취된 서버를 허용하는 제한된 범위의 시나리오는 아래를 보세요).
  • 재판매업자 등, 제3자가 운영하는 서비스의 취약점.
  • 어떠한 과부하, 자원 고갈과 서비스 거부 유형의 공격.
  • 변조된 SSL 인증서에 의지하는 시나리오.
  • 추측 가능한 무작위 수로 추정되는 것을 포함하여 극한의 컴퓨팅 능력 (2^60 이상의 암호화 작업) 또는 양자 컴퓨터 작업이 필요한 어떠한 것 (만약 일반적인 추측이 아니라 실제 약점을 보여줄 수 있다면, 적격 버그 제보로 고려합니다).
  • 보안 취약점과 관계 없는 어떠한 버그 또는 문제

제보할 수 있는 특수 시나리오는 무엇입니까?

탈취된 정적 CDN 노드 (*.static.mega.co.nz)

만약 당신이 우리의 정적 콘텐츠 서버 중 하나를 탈취하였고 그곳에서 제공되는 파일(모든 JavaScript 코드를 포함)을 조작할 수 있다고 가정해봅시다. 우리의 탈취된 보안을 향상 시키는 데에 그 성과를 이용할 수 있습니까?

면책 조항: 변형된 이미지 파일을 이용하여 이용자의 행동에 영향을 주는 것은, 이 맥락에서 잠재적 취약점은 맞지만, 제외됩니다.

탈취된 이용자 저장소 노드 (*.userstorage.mega.co.nz)

우리의 저장소 노드 중 하나에 접근을 얻었고 마음대로 조작할 수 있다고 가정해봅시다. 당신이 당신의 피해자가 그 노드의 특정 파일을 다운로드하려고 하지만, 당신은 그 키가 없다는 것을 알고 있습니다. 그 컨텐츠를 조작하여 오류 없이 다운로드 되게 할 수 있습니까?

탈취된 핵심 기반 시설 (*.api.mega.co.nz)

이것은 가장 극단적인 시나리오입니다. 만약 당신의 우리의 운영 핵심인, API 서버를 탈취하였다고 가정해봅시다. 나가는 공유가 없는 계정이 파일에 대해 사용할 수 있는 키를 양도하도록 API 클라이언트를 속일 수 있습니까?

취약점이 어떻게 분류되나요?

MEGA는 취약점을 심각성에 따라 1에서 6의 척도로 분류합니다.

  • Severity class 6
    Fundamental cryptographic design flaws that are generally exploitable.
  • Severity class 5
    Remote code execution on core MEGA servers, such as application programming interface, database, and root clusters or major access control breaches.
  • Severity class 4
    Cryptographic design flaws that can be exploited only after compromising server infrastructure, either live or post-mortem.
  • Severity class 3
    Generally exploitable remote code execution on client browsers (cross-site scripting).
  • Severity class 2
    Cross-site scripting that can be exploited only after compromising the API server cluster or mounting a man-in-the-middle attack, for example by issuing a fake TLS/SSL certificate plus DNS/BGP manipulation.
  • Severity class 1
    All lower-impact or purely theoretical vulnerability scenarios.

얼마를 보상 받을 수 있나요?

복잡도와 잠재적 영향력에 따라, 취약점당 최대 EUR 10,000를 보상합니다.

개념 증명과 함께 문서화 되고, 잘 구성된 높은 수준의 버그와 취약점 제보는 각 심각도 등급의 최고 수준으로 보상 받습니다.

누가 보상에 적격합니까?

MEGA에 의해 재현 가능하고 검증 가능한 취약점을 제보한 첫번째 사람이 보상을 받습니다.

누가 취약점 제보의 타당성을 결정합니까?

당신의 제보가 적격한지 그리고 얼마를 보상 받을지 결정하는 것은 모두 우리의 재량입니다. 우리는 공정하고 관대하지만, 버그 제보를 접수함으로써, 당신은 우리의 결론이 최종임에 동의하고 수락하여야 합니다.

내가 제보한 취약점에 대해 들으려면 얼마나 걸리나요?

우리는 제보를 받은 후 며칠 이내에 답장하려고 노력합니다. 그러나 이러한 시간 내에 답변을 받지 못 했다면, 당신의 제보가 잘못 되었거나 충분히 고려할만한 충분한 상세 정보가 부족했음을 나타낼 수 있습니다. 만약 당신의 제보가 완벽하고 옳다고 생각하다면 이메일을 통해 더 알아보세요.

책임 있는 공개 정책

보고된 취약점이 인지되고 검증되기까지 90일의 시간이 필요하다는 내용이 포함된 업계 표준 책임 있는 공개 정책을 준수하고, 우리가 시험하고 수정 사항을 배포할 때까지 시간을 주세요.