버그 바운티

버그 바운티는 바깥 사람이 우리 서비스의 보안 구멍을 찾아 알려 주면 상금을 주는 제도입니다. 회사 안의 보안팀만으로는 다 못 찾는 구멍을 많은 사람의 눈을 빌려 찾습니다. 구멍을 찾은 사람에게는 공격에 쓰는 대신 회사에 먼저 알릴 이유가 생깁니다.

상세

가게 주인이 문 앞에 「우리 가게 자물쇠의 허점을 찾아 알려 주시면 사례합니다」라고 써 붙였습니다. 지나가던 열쇠공 여럿이 저마다 문을 살펴봅니다. 허점을 찾은 열쇠공은 문을 따고 들어가는 대신 주인에게 먼저 알려 주고 사례금을 받습니다.

버그 바운티는 조직이 자기 소프트웨어의 취약점을 찾아 신고한 외부 사람에게 보상을 약속하는 제도입니다. 취약점은 공격자가 시스템을 만든 사람의 뜻과 다르게 부릴 수 있게 해 주는 틈입니다. 로그인한 사용자가 주소의 숫자 하나를 바꿔 남의 주문 내역을 여는 화면이 그런 틈입니다.

이름에는 「버그」가 들어가지만 모든 버그가 상금 대상은 아닙니다. 화면의 오타나 느린 페이지는 불편할 뿐 공격자에게 이득을 주지 않습니다. 상금이 걸리는 것은 공격자가 일부러 밟아서 남의 데이터나 권한을 얻을 수 있는 버그뿐입니다.

이 절은 네 가지를 차례로 봅니다. 왜 바깥의 눈을 빌리는지, 프로그램이 무엇으로 이루어지는지, 신고 하나가 어떤 순서로 처리되는지, 그리고 비슷한 제도와 무엇이 다른지입니다. 예로는 앞에서 든 주문 내역 화면을 끝까지 씁니다.

바깥의 눈을 빌리는 까닭

코드를 짠 팀은 그 코드를 짤 때 품은 가정을 함께 가지고 있습니다. 「이 주소는 우리 화면에서만 부른다」고 믿으면 그 주소에 권한 확인이 빠져도 눈에 잘 안 띕니다. 바깥 사람은 그 가정을 모릅니다. 그래서 팀이 한 번도 안 눌러 본 순서로 요청을 보내 봅니다.

구멍을 먼저 찾은 사람에게는 길이 셋 있습니다. 공격에 쓰거나 파는 길, 인터넷에 바로 공개하는 길, 회사에 조용히 알리는 길입니다. 알릴 창구가 없거나 알렸다가 고소를 당할까 걱정되면 셋째 길이 제일 손해입니다. 버그 바운티는 셋째 길에 창구와 보상과 법적 안심을 붙여 가장 나은 선택으로 만듭니다.

돈을 내는 방식도 다릅니다. 보안 업체에 점검을 맡기면 일한 시간에 돈을 냅니다. 버그 바운티는 찾아낸 결과에만 돈을 냅니다. 아무도 구멍을 못 찾으면 상금도 나가지 않습니다.

프로그램을 이루는 네 가지

버그 바운티를 연다는 것은 참가자가 읽을 규칙 문서를 공개한다는 뜻입니다. 그 문서에는 대개 네 가지가 들어갑니다.

표에서 범위와 규칙이 따로 있는 까닭은 막는 것이 달라서입니다. 범위는 어디를 두드려도 되는지를 정하고, 규칙은 어떻게 두드려도 되는지를 정합니다. 규칙에서 흔히 막는 것은 셋입니다. 서버를 일부러 멈추게 하는 서비스 거부 공격, 직원을 속여 정보를 빼내는 사회공학, 그리고 다른 실제 사용자의 데이터를 읽거나 고치는 일입니다.

면책 약속은 영어로 세이프 하버(safe harbor)라고 부릅니다. 허락 없이 남의 시스템을 두드리는 일은 원래 불법이 될 수 있습니다. 이 약속이 있어야 참가자가 안심하고 찾은 것을 이름을 걸고 신고합니다.

프로그램은 누구나 참가할 수 있게 열기도 하고, 초대한 사람만 참가하게 닫아 두기도 합니다. 처음 여는 조직은 대개 초대제로 시작합니다. 신고가 한꺼번에 몰리지 않게 하면서 처리 절차를 다듬으려는 것입니다.

신고 하나가 지나가는 순서

신고서가 들어오면 바로 상금이 나가지 않습니다. 보안팀이 먼저 걸러 내고, 개발팀이 고치고, 그다음에 상금과 공개가 정해집니다. 아래 그림은 주문 내역 구멍 신고 하나가 거치는 순서입니다.

sequenceDiagram
    participant 참가자
    participant 보안팀
    participant 개발팀
    참가자->>보안팀: 신고서를 낸다
    Note over 보안팀: 재현해 보고 중복인지 가린다
    보안팀->>개발팀: 고쳐 달라고 넘긴다
    개발팀-->>보안팀: 고친 버전을 배포한다
    보안팀->>참가자: 위험도를 매겨 상금을 준다
    Note over 참가자,보안팀: 합의하면 신고 내용을 공개한다

처음 단계에서 들어온 신고를 걸러 내는 일을 분류(triage)라고 부릅니다. 보안팀은 신고서대로 따라 해서 구멍이 재현되는지부터 봅니다. 같은 구멍을 먼저 신고한 사람이 있으면 뒤 신고는 중복으로 닫힙니다. 상금은 대개 가장 먼저 신고한 사람에게만 갑니다.

재현된 신고는 개발팀으로 넘어갑니다. 백엔드 개발자가 버그 바운티를 만나는 곳이 대개 여기입니다. 주문 내역 구멍이라면 주문을 돌려주기 전에 그 주문이 요청한 사용자의 것인지 확인하는 코드를 넣습니다.

상금은 위험한 정도에 따라 정해집니다. 위험한 정도를 매길 때는 CVSS(Common Vulnerability Scoring System, 공통 취약점 점수 체계) 같은 점수표를 쓰거나 회사가 만든 등급표를 씁니다. CVSS 는 구멍마다 0점부터 10점까지 점수를 매겨 급한 것부터 고치게 돕는 점수표입니다.

고친 뒤에는 신고 내용을 세상에 공개할지 정합니다. 고치기 전에 공개하면 아직 막히지 않은 구멍을 공격자에게 알려 주는 셈입니다. 그래서 고친 버전이 나온 뒤에 공개하고, 찾은 사람은 그때까지 입을 다뭅니다. 이 순서를 책임 있는 공개라고 부릅니다.

신고서에 담기는 것

신고서의 목적은 보안팀이 읽고 그대로 따라 해서 같은 결과를 보게 하는 것입니다. 따라 할 수 없는 신고는 분류 단계에서 닫힙니다. 그래서 신고서는 무엇이 어디서 터지는지, 어떤 순서로 재현하는지, 그 결과 공격자가 무엇을 얻는지를 담습니다.

재현 순서의 핵심은 대개 요청 몇 줄입니다. 주문 내역 구멍의 신고서라면 이 두 줄이 들어갑니다.

GET /orders/1042  // 내 주문: 정상
GET /orders/1043  // 남의 주문도 열림

첫 줄은 참가자가 자기 계정으로 자기 주문을 연 요청입니다. 둘째 줄은 같은 계정으로 번호만 하나 올렸는데 남의 주문이 열린 요청입니다. 이 두 줄이 있으면 보안팀은 설명을 길게 안 읽어도 구멍을 바로 봅니다. 이런 결함을 IDOR(Insecure Direct Object Reference, 안전하지 않은 직접 객체 참조)라고 부릅니다.

구멍이 실제로 밟힌다는 것을 보이는 최소한의 재현을 개념 증명이라고 부릅니다. 영어로는 PoC(Proof of Concept)입니다. 규칙은 대개 개념 증명까지만 허락합니다. 남의 주문이 열리는 것을 보였으면 거기서 멈추고, 다른 주문을 더 모으지 않습니다.

비슷한 두 제도와의 차이

버그 바운티와 자주 나란히 불리는 제도가 둘 있습니다. 보안 업체에 맡기는 침투 테스트와 상금 없이 신고 창구만 여는 취약점 공개 정책입니다. 셋은 누가 찾는지와 무엇에 돈을 내는지로 갈립니다.

표의 마지막 줄이 가장 큰 차이입니다. 침투 테스트는 계약서에 적은 곳을 빠짐없이 훑습니다. 버그 바운티 참가자는 상금이 크거나 찾기 쉬운 곳으로 몰립니다. 그래서 둘은 서로를 대신하기보다 같이 씁니다.

취약점 공개 정책은 영어로 VDP(Vulnerability Disclosure Policy)라고 줄여 부릅니다. 「구멍을 찾으면 이 주소로 알려 달라, 규칙 안에서 한 시험은 문제 삼지 않겠다」는 약속만 있고 상금은 없습니다. 버그 바운티는 이 약속에 상금표를 얹은 것으로 볼 수 있습니다.

쓰면 생기는 부담

신고가 많이 들어오지만 쓸모 있는 신고는 그중 일부입니다. 중복, 범위 밖, 재현되지 않는 것, 위험하지 않은 것이 섞여 옵니다. 이것을 걸러 내는 사람이 있어야 합니다. 그래서 신고 접수와 분류, 상금 지급을 대신 맡아 주는 중개 플랫폼을 끼고 여는 조직이 많습니다.

운영 서버로 시험용 요청이 들어옵니다. 참가자는 대개 실제 서비스를 두드리므로 감시 알람이 울리고 로그에 시험 요청이 섞입니다. 시험용 계정이나 따로 떼어 둔 환경을 참가자에게 주는 프로그램도 있습니다.

기본 점검이 안 된 서비스가 문을 열면 쉬운 구멍마다 상금이 나갑니다. 자동 도구로도 찾을 구멍에 사람 값을 치르는 셈입니다. 그래서 정적 분석이나 동적 분석 같은 자동 검사와 침투 테스트로 쉬운 구멍을 먼저 치운 뒤에 버그 바운티를 여는 순서를 밟습니다.

설계 단계의 결함이나 바깥에서 닿지 않는 내부 시스템은 버그 바운티가 잘 못 봅니다. 참가자는 밖에서 두드릴 수 있는 것만 봅니다. 그런 곳은 위협 모델링이나 보안 코드 리뷰처럼 안에서 들여다보는 방법이 맡습니다.

관련 항목

버그 바운티가 찾으려는 대상

취약점 · CWE · CVE · 제로데이 · 익스플로잇 · IDOR · 권한 상승 · 원격 코드 실행 · SQL 인젝션 · 교차 사이트 스크립팅

버그 바운티와 나란히 쓰는 보안 점검 방법

침투 테스트 · 레드 팀 · 정적 분석 · 동적 분석 · 퍼징 · 취약점 스캐너 · 보안 코드 리뷰 · 위협 모델링

신고를 받고 처리하는 절차와 약속

책임 있는 공개 · 취약점 공개 정책 · 세이프 하버 · 보안 공지 · 패치 · 취약점 관리 · CNA

신고의 위험도를 매기는 점수표

CVSS · EPSS · OWASP Top 10 · NVD

버그 바운티를 중개하는 플랫폼

HackerOne · Bugcrowd · Intigriti · YesWeHack

버그 바운티에 참여하는 사람과 조직

화이트 해커 · 보안 연구자 · 보안 엔지니어링 · PSIRT