일렉트로닉 아츠 7억 개 계정 해킹 사건

 (battleda.sh)
1P by GN⁺ | ★ favorite | 댓글 1개
  • EA 인증·게이트웨이 API의 노출된 Swagger 문서와 persona 업데이트 권한 검증 실패가 맞물리며, 다른 사용자의 계정 데이터와 로그인 흐름까지 영향을 받을 수 있었음
  • 핵심은 /identity/pids/{pidId}/personas/{personaId}의 PUT 요청이 일반 EA Desktop OAuth 클라이언트의 dp.client.default 범위로 접근 가능했고, 본문 pidId와 경로 personaId의 소유권 검사가 부족했다는 점임
  • 공격자는 persona 사용자명 변경, BANNED 상태 설정, persona 이동, 숨김 계정 persona ID 검색, Xbox persona 기반 로그인 우회를 조합해 계정 웹 로그인까지 도달할 수 있었음
  • 영향 범위는 사용자명·일부 게임 데이터 탈취, 온라인 게임 접속 차단, 게임 밴 우회, Xbox를 통한 EA 계정 로그인까지 이어졌고, 심각도는 CVSS 10.0으로 평가됨
  • 취약점은 2024년 6월 16일 EA에 보고됐고, EA는 6월 25일 critical로 분류한 뒤 7월 8일부터 10월 8일까지 persona 소유권 검사와 문서 제거를 포함한 패치를 배포함

EA 인증 환경에서 시작된 API 문서 노출

  • EA Desktop에서 발견한 개발 환경 integration 테스트가 출발점이었음
    • 프로덕션 인증 API는 accounts.ea.com
    • integration 인증 호스트는 accounts.int.ea.com
  • integration 환경에서 권한 있는 access token을 얻을 수 있었고, 이 토큰으로 접근 가능한 API를 확인하기 위해 노출된 문서를 찾기 시작함
  • 인증 엔드포인트는 reverse proxy 뒤에 있었으며, /connect 경로와 일반 / 경로의 404 응답 형식이 달랐고 server 헤더는 istio-envoy였음
  • /connect/api-docs가 다른 /connect 경로와 다르게 빈 404를 반환해 별도 서비스 라우팅 가능성이 보였고, /connect/api-docs/index.json에서 Swagger 1.1 문서를 찾음
  • Swagger 문서는 /api-docs/connect를 가리켰으며, 이를 swagger-codegen-cli로 OpenAPI 3.0 명세로 변환해 로컬 Swagger UI에서 확인함

Gateway에서 드러난 내부 API 목록

  • EA Desktop은 “Service Aggregation Layer”라는 GraphQL API를 사용하지만, integration 환경의 SAL은 방화벽 뒤에 있었음
  • 이전 버전으로 보이는 gateway.ea.com의 gateway API는 proxy/{service}/{route} 형식의 엔드포인트를 사용함
  • gateway.int.ea.com/proxy/api-docs/index.json은 80개가 넘는 서비스 문서 목록을 반환함
    • addresses, agerequirements, billing, commerce 등 여러 서비스가 포함됨
  • 각 API 문서를 내려받아 최신 OpenAPI 명세로 변환한 뒤 접근 가능한 기능을 확인함
  • 일부 엔드포인트는 EA 게임 팀 관련 “projects” 데이터를 반환했고, basic.domaindata 권한 범위가 필요했으며 프로덕션에서 해당 범위를 가진 클라이언트도 찾음
    • 예시 데이터에는 취소된 Star Wars 게임과 Apex Legends가 Titanfall3 관련 그룹명으로 표시된 항목이 있었음
  • integration 환경에는 커스텀 게임 entitlement를 부여하는 방법도 문서화돼 있었지만, 다운로드와 플레이에 필요한 integration 서비스가 방화벽 뒤에 있어 실용성은 낮았음
  • Xbox Live Server Token을 반환하는 엔드포인트도 있었으나 sandbox ID가 RETAIL이 아니어서 더 깊게 조사하지 않음

프로덕션 계정 정보와 persona 구조

  • 문서의 각 엔드포인트는 필요한 인증 범위를 표시했고, 확인은 프로덕션 OAuth 클라이언트로 접근 가능한 엔드포인트를 중심으로 진행됨
  • /identity/pids/me는 계정의 일반 정보를 반환함
    • 이메일 마스킹 값, 이메일 상태, 생년월일 일부, 국가, 언어, 계정 상태, 약관 버전, 생성·수정·마지막 인증 시각, 2FA 활성화 여부 등이 포함됨
  • /identity/pids/me/personas는 계정에 연결된 persona 목록을 반환함
    • 기본 EA 계정은 cem_ea_id namespace를 사용함
    • Steam, Xbox 등 연결된 외부 계정도 각각 persona로 표시됨
  • 게임은 일반적으로 persona 아래에 통계, 인벤토리 같은 데이터를 저장할 수 있어 플랫폼별 데이터가 분리될 수 있음
  • 이후 cem_ea_id namespace의 persona를 “Origin” persona로 지칭함

핵심 취약점: persona 업데이트 권한 검증 실패

  • /identity/pids/{pidId}/personas/{personaId} 엔드포인트는 GET, PUT, DELETE 요청을 받음
  • PUT 요청은 dp.client.default와 dp.server.default 범위를 허용했고, 일반 EA Desktop 인증 클라이언트가 dp.client.default를 갖고 있었음
  • 요청 본문은 displayName, namespaceName, status, statusReasonCode, lastAuthenticated, nickName, pidId 등을 받을 수 있었음
  • 자신의 Origin persona에 대해 displayName을 바꾸는 PUT 요청은 성공했고, EA 계정 웹사이트의 사용자명이 변경됨
    • 이 요청은 사용자명 변경 쿨다운과 사용자명 변경 이메일 검증을 우회함
  • namespaceName 변경은 효과가 없었음
  • status 값은 ACTIVE, DISABLED, PENDING, DELETED, BANNED가 가능했고, 자신의 Origin persona 상태를 BANNED로 바꾸자 EA Desktop은 계속 사용할 수 있었지만 게임 로그인은 차단됨
  • 더 큰 문제는 요청 본문의 pidId를 다른 계정 ID로 바꿀 수 있었다는 점임
    • 자신의 Steam persona를 친구의 EA 계정으로 이동시키는 요청이 성공함
    • 이후 다시 자신의 계정으로 되돌리는 것도 가능했음

로그인 검증과 XSS 시도

  • 자신의 Steam persona를 친구 계정으로 옮긴 뒤 Steam으로 EA 웹사이트 로그인을 시도하자, 새 위치·신뢰되지 않은 기기 기반 이메일 검증이 나타남
  • 표시된 일부 이메일은 자신의 것이 아니어서 친구 계정으로 로그인하려는 흐름까지 도달했지만, 위치 기반 2FA 단계에서 막힘
  • persona 사용자명을 BattleDash <script>alert(1)</script> 형태로 변경하는 요청도 성공함
  • 계정 연결 페이지에서 alert가 실행돼 XSS가 가능했음
    • 사용자가 EA 계정에 로그인된 상태에서 해당 연결 페이지로 유도되면 브라우저에서 코드를 실행해 세션을 추출할 수 있는 상황이었음

다른 계정 persona 직접 조작

  • 경로의 personaId도 소유권 검증이 부족한지 확인하기 위해, 자신이 소유하지 않은 persona ID로 사용자명 변경을 시도함
  • 새 테스트 계정의 persona ID를 얻은 뒤, 피해 계정 인증 없이 해당 계정의 사용자명을 바꾸는 요청이 성공함
  • 같은 방식으로 status를 BANNED로 바꿀 수 있었고, 해당 계정은 게임에 로그인할 수 없게 됨
  • /identity/personas는 displayName으로 persona를 검색하고 persona ID, 계정 ID, 생성일, 마지막 로그인 시각을 반환함
    • 다만 계정을 숨긴 사용자는 표시하지 않음
  • /identity/namespaces/{namespace}/personas는 특정 namespace에서 검색하며, 사용자명과 persona ID만 반환하지만 숨김 계정도 반환함
    • 이 엔드포인트만으로도 필요한 persona ID를 얻을 수 있었음

persona 이동의 제약과 부분 계정 탈취

  • 다른 사용자의 Origin persona를 자신의 계정으로 옮기려 하자 TOO_MANY_PERSONAS_FOR_NAMESPACE 오류가 발생함
    • 자신의 계정에 이미 Origin persona가 있었기 때문임
  • 콘솔로 가입한 계정은 해당 플랫폼 persona만 있고 Origin persona가 없을 수 있다고 보고, 콘솔 계정을 이용해 namespace 충돌을 피함
  • 테스트 계정의 Origin persona를 콘솔 계정으로 옮긴 뒤, 피해 계정의 Origin persona를 자신의 계정으로 옮기는 방식이 가능했음
  • 이 상태에서 로그인하면 피해자의 사용자명, 비크로스플랫폼 게임 통계, 일부 기타 계정 세부 정보가 표시됨
  • 피해 계정으로 로그인하면 새 계정을 만든 것처럼 사용자명 선택을 요구하는 “Finish setting up my account” 흐름이 나타남
  • Battlefield 2042 같은 최신 크로스플랫폼 게임의 entitlement, 친구, 저장 데이터는 persona가 아니라 EA 계정 자체에 저장돼 전송되지 않았음
  • 그래도 공격자는 사용자 밴, 게임 밴 우회, 사용자명 탈취, 계정 데이터 인질화를 수행할 수 있었음

Xbox persona를 이용한 로그인 우회

  • 기존 상태에서 가능한 작업은 자신의 linked account persona를 임의의 EA 계정으로 이동, 임의 persona를 자신의 계정으로 이동, persona 밴·사용자명 변경이었음
  • 다른 사용자의 계정으로 로그인하려고 자신의 persona를 이동하면 이메일 검증이 나타났음
  • 콘솔에서 EA 게임을 플레이할 때 2FA 프롬프트를 본 적이 없다는 점에 착안해 Xbox/PSN 토큰 기반 로그인을 확인함
  • Nexus Connect API 문서에는 Xbox/PSN 토큰 전달 방식이 있었고, EA 사이트의 PSN 로그인 흐름에서 PSN client ID를 얻어 PSN 토큰 로그인을 시도함
  • PSN 토큰 로그인은 ps3 namespace persona를 만들고 2FA 없이 계정 로그인이 가능했지만, dp.client.default가 있는 클라이언트는 ps3 namespace를 다룰 수 없었음
  • /connect/tokeninfo에 X-Include-Namespace 헤더를 추가하자 OAuth 클라이언트별로 조작 가능한 persona namespace 목록이 있음을 확인함
    • 예시 JUNO_PC_CLIENT는 cem_ea_id, steam, epic, xbox namespace를 포함함
  • Xbox namespace는 허용됐지만 수동으로 게임 유효 Microsoft XSTS 토큰을 만들 수 없어, 실제 Xbox에서 테스트함
  • 새 Microsoft 계정을 만들고 Xbox persona를 테스트 EA 계정에 연결한 뒤, 그 Xbox persona를 피해자 계정으로 이동함
  • EA 웹사이트에서 Xbox 계정으로 로그인하면 새 위치 이메일 검증이 떴지만, Xbox에 Battlefield 2042를 설치해 게임에 로그인하자 피해 계정으로 접속됨
  • 이후 같은 Xbox 계정으로 EA 웹사이트에 로그인했을 때 이메일 검증 없이 피해 계정 웹 로그인까지 성공함

영향 범위와 심각도

  • 공격자가 사용할 수 있는 주요 경로는 두 가지였음
    • 다른 사람의 persona 데이터를 계정 밖으로 이동해 사용자명과 게임 데이터를 탈취함
    • 자신의 Xbox persona를 피해 계정으로 옮기고 Xbox에서 EA 게임에 로그인한 뒤, 네트워크가 신뢰된 상태가 되면 Xbox 계정으로 EA 웹사이트에 로그인함
  • 추가 영향도 컸음
    • 다른 사람의 persona를 밴 처리해 대부분의 온라인 게임 플레이를 막을 수 있음
    • 다른 사람의 사용자명을 바꾼 뒤 자신이 가져갈 수 있음
    • 게임 밴이 계정 전체 게임 entitlement 비활성화로 처리되기 때문에 persona를 새 계정으로 옮겨 게임 밴을 우회할 수 있음
  • 이 흐름은 사용자 상호작용 없이 주로 단일 API 엔드포인트를 통해 가능했음
  • 심각도는 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H 기준 CVSS 10.0으로 평가됨

수정 일정과 후속 의견

  • 취약점은 2024년 6월 16일 EA에 보고됨
  • EA는 2024년 6월 25일 확인을 보내고 critical 심각도를 부여함
  • 패치 일정은 다음과 같음
    • 2024년 7월 8일: Patch 1 배포, persona ownership check
    • 2024년 7월 18일: Patch 2 배포, 세부 내용 미상
    • 2024년 9월 6일: Patch 3 배포, 세부 내용 미상
    • 2024년 9월 10일: Patch 4 배포, 문서 제거
    • 2024년 10월 8일: Patch 5 배포, 세부 내용 미상
  • EA의 초기 예상은 수정이 연말까지 걸릴 수 있다는 것이었고, 노출된 문서와 단일 불안전 엔드포인트가 핵심인 사안에서는 더 빠른 임시 패치가 바람직했다는 평가가 나옴
  • EA에는 아직 bug bounty 프로그램이 없고, 실질적 신고 보상이 없으면 취약점을 비공개로 보유하는 사람이 생길 수 있다는 우려가 남음
  • 초기 테스트에 사용된 친구 계정은 동의를 받은 계정이었음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • EA는 여러 게임에 공통 시스템을 쓰는 걸 좋아함. Madden을 뒤져보다가 blaze라는 공통 백엔드가 있고, 범용 웹/TCP 엔드포인트가 있다는 걸 발견했음
    이 엔드포인트를 호출하는 도구를 만들었는데 XML을 업로드해야 했고, 나중에 알고 보니 호출할 때마다 EA 서버가 죽고 있었음
    요청마다 새 서버를 잡고 있었기 때문에 Madden 서버들을 하나씩 전부 크래시시키고 있었고, 결국 EA는 사람들이 뒤져보지 않게 하려고 API를 만들었음

    • Blaze는 온라인 게임용 커스텀 백엔드를 만들기 위한 C++ 프레임워크/서비스 이름임. 게임 팀이 온라인 기능을 표준 방식으로 개발하게 해주고, MySQL이 뒤를 받침
      기억상으로는 플레이어 5천~1만 명당 Blaze 인스턴스 하나 정도가 필요했음
    • 글 작성자인데, 작년에 내가 찾은 Blaze 취약점을 잔뜩 다룬 글도 썼지만 공개하진 않았음
      지금은 독점 포맷을 쓰고 있고, 아무도 인터페이스 방식을 알아내지 못할 거라고 가정하는 식의 보안, 즉 모호성에 의존한 보안에 꽤 안주하고 있었던 듯함
      언젠가 그 글로 다시 돌아가고 싶고, 최소한 꽤 재미있는 내용이 있음
    • 최근 다른 게임에서 이 API를 본 것 같음. GraphQL 프런트엔드 맞지 않나? 인트로스펙션은 꺼놨지만, 오류 메시지가 틀린 필드명에 대해 친절하게 추천을 해줌
      이런 유명 서비스의 API를 역공학할 때 팁은 GitHub 코드 검색을 쓰는 것임. 고유한 엔드포인트 이름을 넣어보면, 직접 작은 API 클라이언트를 해킹해서 만든 비슷한 사람들이 자주 나오고, 생각도 못 한 방식으로 내 조사에 도움이 됨
    • PSN 클라이언트 ID 반복값을 훑으면서 EA 게이트웨이 프록시에 로그인을 시도하면, 개인 데이터에서 가져온 namespacename 값이 반환됨. 2FA 토큰 정보는 JUNO에서 가져온 /tokeninfo/ 엔드포인트에서 해시되어야 함
      사후 통합을 시도하면 C++ API용 인프라가 PSN 사용자 ID를 반환하곤 했음

  • 정상적인 사람이라면 당연히 그랬겠지만, Xbox를 익일 배송으로 주문하고 Battlefield 2042를 설치한 뒤 결정적 순간을 기다렸고, 들어갈 수 있었음
    해커들이 정말 좋다 <3

  • 한 지점에서 다음 지점으로 어떻게 이동했는지 상세한 흐름이 재미있었음. 블로그 글처럼 깔끔하게 직선적이진 않았을 것 같음
    이런 공격에 실제로 드는 시간과 노력을 보여주려면, 아마 산더미 같은 노트가 있을 텐데 그걸 보는 것도 흥미로울 듯함

  • 이 모든 것에서 가장 이상한 건, EA가 기존 Xbox 계정 연결을 해제하고 새 계정으로 다시 연결하는 것이 수년간 기술적으로 불가능하다고 주장해왔다는 점임. https://www.reddit.com/r/XboxGamePass/comments/12gsy4i/ea_xb... 같은 글과 EA 포럼의 수많은 글을 보면 됨
    나도 이 벽에 부딪혔고, EA 지원과 몇 시간 통화했지만 아주 오래된 Xbox 계정을 연결해주지 못했음. 그래서 Xbox에서 어떤 EA 게임에도 로그인할 수 없고, 플랫폼에서 대부분 플레이할 수 없게 됐음
    그런데 여기서는 충분히 가능한 것으로 드러남

    • 2004~2005년에 내 Hotmail 계정은 일반적인 4MB 저장공간이었고, Microsoft가 모두에게 250MB 무료 업그레이드를 배포 중이던 때가 떠오름
      이상하게도 내 계정은 너무 오래 걸렸고, 1~2년 동안 여러 번 지원팀에 메일을 보냈지만 매번 계정을 최대한 빨리 업그레이드하고 있으나 작업이 워낙 커서 수년이 걸린다는 답을 받았음
      나중에 어떤 포럼에서 계정을 잠시 닫았다가 다시 열면 25MB로는 늘릴 수 있다는 꼼수를 봤지만, 약속한 250MB는 아니었음
      기존 계정 2~4MB, 신규 계정 25MB, 250MB까지 수년짜리 배포라는 상황은 Microsoft가 남는 저장공간을 찾는 데 엄청나게 고생한다는 인상을 줬음. 그런데 몇 달 뒤 Gmail과 경쟁해야 하자 모두에게 2GB를 주기로 했고, 내 계정을 포함한 모든 Hotmail 계정에 한 번에 배포됐음. 외계인이 하드디스크로 가득 찬 UFO를 가져다준 게 틀림없음
      [1] 그 꼼수에 대한 오래된 포럼 글 예시, 새로 나온 GMail을 칭찬하는 답글도 있음: https://bimmersport.co.nz/topic/5232-hotmail-upgrade-2mb-to-...
    • 이 공격은 연결을 바꾸고 게임을 플레이하는 것이 가능하다는 걸 보여주지만, 글에서 쉽게 검증한 시나리오 밖에서 어떤 부작용이 생길지는 알 수 없음
      연결 변경이 과금 시스템에 저장된 데이터를 무효화하거나, Microsoft Xbox 부서로 가는 월간 보고서를 망치거나, 내부 관리자 페이지가 로드 중 크래시하게 만들 수도 있음
      EA를 변호하려는 건 아니지만, 복잡한 마이크로서비스 시스템을 많이 다뤄보면 한 곳의 데이터 구조를 바꾸는 일이 항상 단순하진 않음
    • 아마 그 문제를 고치려고 이 기능을 추가하던 중이었는데, 공개 전에 안타깝게도 악용된 것일 수 있음
    • 안타깝게도 Battlefield 2042 같은 최신 크로스플랫폼 게임의 게임 권한, 친구, 저장 데이터는 페르소나가 아니라 EA 계정 자체에 저장되기 때문에 그 데이터는 이전되지 않음
    • 기술적으로 불가능한 게 아니라, 아마 고객지원팀이 처리하는 것이 불가능했을 가능성이 큼

  • 모든 계정을 밴하고 DB 백업이 없길 바라는 것도 재미있었을 듯함

    • 버그 바운티 프로그램이 없는 모든 10억 달러 규모 회사가 이런 일을 당하는 걸 보고 싶음. 취약점 신고에 아무 보상도 없으면 해커들이 자기 이익을 위해 악용하거나 혼란을 일으키도록 부추기는 셈임
      돈 내는 고객으로서 이런 회사들에 더 나은 태도를 기대하고, 프로그램이 없다면 해커들이 발견한 걸 악용해도 개인적으로는 비난하지 않겠음
    • 잠깐은 재미있을 수 있겠지만, 그들은 분명 백업을 갖고 있을 것임
      4억 개 레코드를 단일 머신에 저장하는 사람은 없고, 결국 서비스를 오후 내내 내리게 만든 뒤 연방 교도소 15년을 보내게 될 뿐임
    • 세상이 기술 업계를 등지게 된 이유가 이런 데 있음
      수백만 명에게 피해를 줘서 그들이 거래하던 회사에 교훈을 주는 것이 "재미있겠다"는 생각이 첫 반응, 적어도 지금 최고 평점 글이라는 점 때문임
    • 모든 계정에 모든 게임을 활성화하는 쪽이 훨씬 더 재미있었을 것임. 말 그대로 전부. 상상력이 좁음
    • 나도 이걸 생각해봤음. 실제로 신고하지 않고 마음먹고 장난쳤다면 결과가 어땠을까? 추적당했을까? EA가 몇 주 동안 내려갔을까?

  • 글에 이런 대목이 있음:
    I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had hardcoded credentials!), but I wasn't sure what I could do with it.
    이 부분을 조금 더 설명해줄 수 있나? 실행 바이너리에서 그런 자격 증명을 쉽게 읽어낼 수 없어야 한다고 생각했고, 게임 실행 파일이 원격 서버에 자기 자신을 인증해야 한다면 개발자가 달리 뭘 해야 하는지도 잘 모르겠음

    • 자격 증명은 문자열로 저장되기 때문에, 자격 증명처럼 생긴 패턴을 바이너리에서 검색하면 어딘가에 들어 있음
      클라이언트-서버 구조에서 클라이언트는 항상 신뢰할 수 없음. 실행 파일이 서버에 자기 자신을 인증할 필요가 없어야 함. 실행 파일은 사용자가 제공한 정보로 사용자나 계정으로 인증해야 함
      원격 측정 같은 경우 이런 엔드포인트는 보통 인증이 없거나 약한 인증의 데이터를 받고, 남용을 막기 위해 여러 단계의 검증을 수행함. 대개 쓰기/추가 전용이기도 함
    • 바이너리가 왜 쉽게 읽히지 않을 거라고 가정하는지 모르겠음. 잠겨 있지 않은 플랫폼에서 바이너리는 충분히 읽기 쉬움
      실행 파일을 암호화하고 CPU 다이의 보안 영역이 개인 키로 복호화를 처리하는 시스템이 필요할 텐데, 그래도 누군가 칩을 디리드해서 키를 얻는 건 시간문제일 가능성이 큼
    • 컴퓨터가 읽을 수 있고, 그 컴퓨터를 완전히 제어할 수 있다면 너도 읽을 수 있음. 물리 접근이 있으면 끝임
      암호화하고 암호화 키를 HSM에 넣더라도, 임의의 클라이언트 머신에서는 아마 불가능할뿐더러, 어느 시점엔 게임이 그 문자열을 복호화해 메모리에 올려야 함. 그리고 그 메모리는 읽을 수 있음
    • 프로그램이 자격 증명에 접근할 수 있고 그 프로그램이 내 컴퓨터에서 실행된다면, 어떤 식으로 난독화해도 나 역시 그 자격 증명에 접근할 수 있음
      게임 개발자가 해야 할 일은 백엔드에 계정 시스템을 두고, 플레이어가 게임 안에서 자기 자격 증명을 입력하게 하는 것임. 그러면 게임은 백엔드 서버에 이 플레이어로 자신을 식별할 수 있음
      이렇게 해야 백엔드에서의 행동을 특정 플레이어에게 귀속할 수 있고, 보안 결정을 내릴 좋은 기반이 생김
    • 실행 바이너리에서 그런 자격 증명을 찾는 건 어렵지만 불가능하진 않음. 축소된 JavaScript 파일에서 문자열을 뽑아내는 것보다 귀찮지만, 결코 불가능과는 거리가 멂
      IDA 같은 도구가 있어서, 문자열처럼 보이는 모든 것 사이에서 맨눈으로 자격 증명을 찾는 것도 아님
      문제는 바이너리에 하드코딩된 자격 증명이 있다는 점 자체보다, 그 자격 증명이 특권 권한을 갖고 있다는 점임

  • 이런 회사의 엔지니어로서, 사설 API와 이상한 버그, 더러운 내부 사정이 공개 침해 보고서에 드러나는 기분이 어떨지 가끔 궁금함
    다만 이런 경우 단일 개인이 취약점의 책임자였을 가능성은 낮음. 아마 5~6개 팀이 악용된 서로 다른 부분을 소유했을 것이고, 그래서 애초에 익스플로잇이 존재했을 것임. 모두가 자기 작은 부분만 이해하는 거대하고 복잡한 시스템이니까

    • 팀에 감정적으로, 혹은 단지 금전적으로라도 투자되어 있으면 기분이 나쁘지만, 내가 EA에 있었을 때는 감정적으로 투자하기 어렵게 만드는 데 거의 애쓰는 듯했음
      EA 정도 규모의 회사에서는 거의 확실히 이 일이 사내 정치에 쓰일 것이고, 회사 전체에는 해가 되더라도 사람들은 더 작아진 회사에 대한 더 큰 통제권을 얻는 데 활용할 것임
    • 그렇게 큰 대기업에서는 아무도 신경 쓰지 않음. 월급 받으러 하는 일일 뿐임
      모두가 대체 가능한 자원인데, 왜 일에 감정적으로 투자하겠나
    • 10년 전쯤 이 정확한 코드를 아직 관리하는 팀과 아마 같은 팀에서 일했던 사람으로서, 글을 빠르게 훑으며 내가 짠 코드나 건드린 부분인지 확인하게 됐음
      당시 팀 이름은 Nucleus였고, 그래서 글의 응답 중 하나에서 refType이 NUCLEUS였음. 이 팀은 권한, 계정, 결제용 백엔드 API를 만들고 관리했음
      여름 인턴십이었고, 1년 뒤 그 팀에서 제안을 받아 일하기 시작했음. 그때는 팀 이름이 EADP로 바뀌어 있었고 Origin과 천천히 합쳐지는 중이었음. DP가 Data Platform이었는지는 기억이 희미하지만, 그래서 엔드포인트 중 하나가 dp.로 시작함
      당시에는 GraphQL 데이터베이스가 없었고 전부 Enterprise Java, OCI, Spring, Hibernate 등이었으며, 떠나기 전에는 더 새로운 Groovy/SpringBoot도 일부 있었음. 클라우드가 아니라 데이터센터 서버에서 돌았음
      그래도 재미있는 일을 했고, 큰 사고가 터진 뒤 2~3년 만에 떠났지만 좋은 엔지니어들에게서 백엔드 개발을 많이 배웠음
      지금 팀이 어떤지, 엔지니어가 누구인지, 무슨 일이 벌어지는지는 전혀 모르지만 이런 걸 보니 안타까움. 당시 우리는 보안을 매우 의식했고, 로그인 페이지의 무차별 대입 시도를 감지하고 처리하는 시스템도 작업했음
      아직 활성 상태인지 실행 중인지는 모르지만, 침해 가능성과 공격 표면을 줄이기 위한 보안 점검/리뷰가 스프린트 작업의 일부였음
    • 특히 그 부서에서 일하지 않아 통제권은 없지만, 내가 그 부서보다 더 잘할 수 있다는 걸 알고 있다면 기분이 나쁨
    • 내가 그 API를 구현했다는 걸 아는 상태로 그런 글을 읽으면 속이 철렁할 것 같음

  • 이 글을 재미있게 읽었다면 HackerOne의 Hacktivity 같은 버그 바운티 플랫폼에서 더 많이 볼 수 있음: https://hackerone.com/hacktivity

  • 버그 바운티 프로그램을 설정하는 모범 사례 가이드가 어딘가에 있나?

    • 이 분야에서 일하고 있어서 어떤 정보가 빠져 있는지 알기 어렵지만, 내게는 꽤 단순해 보임
      웹사이트 어딘가에 조율된 취약점 공개 절차를 따른다는 조건에서 기술 보안을 점검해도 된다고 게시하고, 어떤 범위의 어떤 버그에 대해 어떤 보상을 줄지 적으면 됨. 물론 이 한 문장보다는 조금 더 구체화해야 함
      나이가 너무 어리거나 많으면 지급하지 않는다든지, 잘못된 국가에서 태어나 제재 대상이면 안 된다든지 하는 예외도 나중에 감정 상하지 않게 미리 적어두는 편이 좋음
      구체적인 질문이 있으면 답하거나 좋은 참고자료를 찾아볼 수 있음

  • 글의 이 부분을 보면:
    It's also disappointing that EA has yet to start a bug bounty program. Without any real incentive to report vulnerabilities, I know people who have instead chosen to keep them to themselves. I would love to see EA follow the rest of the industry's lead here.
    그러면 작성자는 이걸 신고하고 아무것도 못 받은 것인가?

    • 아무것도 못 받았다는 건 사실이 아님. 취약점을 신고했다는 이유로 법적 조치 위협을 받을 가능성은 항상 있음
    • 버그 바운티를 제공하지 않는 회사가 너무 많아 실망스러움. 수년 동안 찾아낸 취약점들이 머릿속에 쌓여만 있음
      신고에는 법적 위험이 있고, 기술적으로는 회사가 끝까지 소송을 걸 수 있다는 점도 도움이 안 됨. EU/UK 기준임
    • 이런 식이면 사람들이 더 그늘진 인터넷으로 가서 정보를 최고가 입찰자에게 팔게 됨
    • 맞음, 못 받은 것임
답변달기