Vụ hack 700 triệu tài khoản Electronic Arts

• Tài liệu Swagger bị lộ của API xác thực/gateway EA kết hợp với lỗi kiểm tra quyền cập nhật persona, khiến dữ liệu tài khoản của người dùng khác và cả luồng đăng nhập có thể bị ảnh hưởng
• Điểm cốt lõi là request PUT tới /identity/pids/{pidId}/personas/{personaId} có thể được truy cập bằng scope dp.client.default của OAuth client EA Desktop thông thường, trong khi việc kiểm tra quyền sở hữu giữa pidId trong body và personaId trên path không đầy đủ
• Kẻ tấn công có thể kết hợp đổi tên người dùng persona, đặt trạng thái BANNED, di chuyển persona, tìm ID persona của tài khoản ẩn, và vượt qua đăng nhập dựa trên persona Xbox để cuối cùng đăng nhập được vào web tài khoản
• Phạm vi ảnh hưởng bao gồm đánh cắp tên người dùng và một phần dữ liệu game, chặn truy cập game online, vượt qua lệnh cấm game, cho đến đăng nhập tài khoản EA qua Xbox; mức độ nghiêm trọng được đánh giá là CVSS 10.0
• Lỗ hổng được báo cáo cho EA ngày 16/6/2024; EA phân loại là critical vào ngày 25/6, rồi triển khai các bản vá từ 8/7 đến 8/10, bao gồm kiểm tra quyền sở hữu persona và gỡ bỏ tài liệu

---

Lộ tài liệu API bắt đầu từ môi trường xác thực của EA

• Điểm khởi đầu là thử nghiệm môi trường phát triển integration được phát hiện trong EA Desktop
  • API xác thực production là accounts.ea.com
  • Host xác thực integration là accounts.int.ea.com
• Có thể lấy access token có quyền trong môi trường integration, và bắt đầu tìm tài liệu bị lộ để kiểm tra các API có thể truy cập bằng token này
• Endpoint xác thực nằm sau reverse proxy; định dạng phản hồi 404 của path /connect khác với path / thông thường, và header server là istio-envoy
• /connect/api-docs trả về 404 rỗng khác với các path /connect khác, cho thấy khả năng được route tới một service riêng; tài liệu Swagger 1.1 được tìm thấy tại /connect/api-docs/index.json
• Tài liệu Swagger trỏ tới /api-docs/connect; tài liệu này được chuyển đổi sang đặc tả OpenAPI 3.0 bằng swagger-codegen-cli rồi kiểm tra trong Swagger UI cục bộ

Danh sách API nội bộ lộ ra từ Gateway

• EA Desktop sử dụng một API GraphQL gọi là “Service Aggregation Layer”, nhưng SAL trong môi trường integration nằm sau tường lửa
• Gateway API của gateway.ea.com, có vẻ là phiên bản cũ hơn, sử dụng endpoint dạng proxy/{service}/{route}
• gateway.int.ea.com/proxy/api-docs/index.json trả về danh sách tài liệu của hơn 80 service
  • Bao gồm nhiều service như addresses, agerequirements, billing, commerce
• Tải từng tài liệu API xuống, chuyển đổi sang đặc tả OpenAPI mới nhất, rồi kiểm tra các chức năng có thể truy cập
• Một số endpoint trả về dữ liệu “projects” liên quan đến các đội game của EA, cần scope quyền basic.domaindata, và cũng tìm thấy client có scope đó trong production
  • Dữ liệu ví dụ có mục hiển thị một game Star Wars đã bị hủy và Apex Legends với tên nhóm liên quan đến Titanfall3
• Trong môi trường integration cũng có tài liệu về cách cấp entitlement game tùy chỉnh, nhưng tính thực dụng thấp vì các service integration cần cho tải xuống và chơi game nằm sau tường lửa
• Cũng có endpoint trả về Xbox Live Server Token, nhưng do sandbox ID không phải RETAIL nên không điều tra sâu hơn

Thông tin tài khoản production và cấu trúc persona

• Mỗi endpoint trong tài liệu hiển thị scope xác thực cần thiết, và việc kiểm tra tập trung vào các endpoint có thể truy cập bằng OAuth client production
• /identity/pids/me trả về thông tin chung của tài khoản
  • Bao gồm giá trị email đã che, trạng thái email, một phần ngày sinh, quốc gia, ngôn ngữ, trạng thái tài khoản, phiên bản điều khoản, thời điểm tạo/sửa đổi/xác thực lần cuối, trạng thái bật 2FA, v.v.
• /identity/pids/me/personas trả về danh sách persona được liên kết với tài khoản
  • Tài khoản EA mặc định dùng namespace cem_ea_id
  • Các tài khoản bên ngoài đã liên kết như Steam, Xbox cũng được hiển thị dưới dạng từng persona
• Game thường có thể lưu dữ liệu như thống kê, inventory bên dưới persona, nên dữ liệu theo từng nền tảng có thể được tách riêng
• Từ đây về sau, persona trong namespace cem_ea_id được gọi là persona “Origin”

Lỗ hổng cốt lõi: lỗi kiểm tra quyền cập nhật persona

• Endpoint /identity/pids/{pidId}/personas/{personaId} nhận các request GET, PUT, DELETE
• Request PUT cho phép scope dp.client.default và dp.server.default, trong khi client xác thực EA Desktop thông thường có dp.client.default
• Body request có thể nhận displayName, namespaceName, status, statusReasonCode, lastAuthenticated, nickName, pidId, v.v.
• Request PUT đổi displayName trên persona Origin của chính mình thành công, và tên người dùng trên website tài khoản EA bị thay đổi
  • Request này vượt qua thời gian chờ đổi tên người dùng và bước xác minh email khi đổi tên người dùng
• Thay đổi namespaceName không có tác dụng
• Giá trị status có thể là ACTIVE, DISABLED, PENDING, DELETED, BANNED; khi đổi trạng thái persona Origin của chính mình thành BANNED, EA Desktop vẫn dùng được nhưng đăng nhập game bị chặn
• Vấn đề lớn hơn là có thể đổi pidId trong body request thành ID tài khoản khác
  • Request di chuyển persona Steam của mình sang tài khoản EA của bạn bè đã thành công
  • Sau đó cũng có thể chuyển lại về tài khoản của mình

Kiểm tra đăng nhập và thử XSS

• Sau khi chuyển persona Steam của mình sang tài khoản bạn bè, khi thử đăng nhập website EA bằng Steam, quy trình xác minh email dựa trên vị trí mới/thiết bị không tin cậy xuất hiện
• Một phần email hiển thị không phải của mình, nghĩa là đã đi tới luồng cố đăng nhập vào tài khoản bạn bè, nhưng bị chặn ở bước 2FA dựa trên vị trí
• Request đổi tên người dùng persona thành dạng BattleDash <script>alert(1)</script> cũng thành công
• Alert được thực thi trên trang liên kết tài khoản, nên XSS là khả thi
  • Nếu dụ người dùng đang đăng nhập tài khoản EA truy cập trang liên kết đó, có thể thực thi mã trong trình duyệt để trích xuất session

Thao tác trực tiếp persona của tài khoản khác

• Để kiểm tra liệu personaId trên path cũng thiếu kiểm tra quyền sở hữu hay không, đã thử đổi tên người dùng bằng một persona ID không thuộc sở hữu của mình
• Sau khi lấy persona ID của một tài khoản thử nghiệm mới, request đổi tên người dùng của tài khoản đó mà không cần xác thực tài khoản nạn nhân đã thành công
• Theo cách tương tự, có thể đổi status thành BANNED, khiến tài khoản đó không thể đăng nhập game
• /identity/personas tìm kiếm persona theo displayName và trả về persona ID, tài khoản ID, ngày tạo, thời điểm đăng nhập lần cuối
  • Tuy nhiên không hiển thị người dùng đã ẩn tài khoản
• /identity/namespaces/{namespace}/personas tìm kiếm trong một namespace cụ thể, chỉ trả về tên người dùng và persona ID nhưng cũng trả về tài khoản ẩn
  • Chỉ riêng endpoint này cũng đủ để lấy persona ID cần thiết

Hạn chế của việc di chuyển persona và chiếm đoạt tài khoản một phần

• Khi thử chuyển persona Origin của người dùng khác sang tài khoản của mình, lỗi TOO_MANY_PERSONAS_FOR_NAMESPACE xảy ra
  • Vì tài khoản của mình đã có persona Origin
• Dựa trên nhận định rằng tài khoản đăng ký bằng console có thể chỉ có persona của nền tảng đó và không có persona Origin, đã dùng tài khoản console để tránh xung đột namespace
• Có thể chuyển persona Origin của tài khoản thử nghiệm sang tài khoản console, rồi chuyển persona Origin của nạn nhân sang tài khoản của mình
• Khi đăng nhập ở trạng thái này, tên người dùng của nạn nhân, thống kê game không cross-platform và một số thông tin tài khoản khác được hiển thị
• Khi đăng nhập bằng tài khoản nạn nhân, luồng “Finish setting up my account” xuất hiện, yêu cầu chọn tên người dùng như thể đang tạo tài khoản mới
• Entitlement, bạn bè và dữ liệu lưu của các game cross-platform mới như Battlefield 2042 được lưu trên chính tài khoản EA chứ không phải persona, nên không được chuyển đi
• Tuy vậy, kẻ tấn công vẫn có thể cấm người dùng, vượt qua lệnh cấm game, đánh cắp tên người dùng và bắt dữ liệu tài khoản làm con tin

Vượt qua đăng nhập bằng persona Xbox

• Ở trạng thái hiện có, các thao tác khả thi gồm di chuyển persona linked account của mình sang tài khoản EA bất kỳ, di chuyển persona bất kỳ sang tài khoản của mình, cấm persona và đổi tên người dùng
• Khi di chuyển persona của mình để đăng nhập vào tài khoản người khác, xác minh email xuất hiện
• Từ việc chưa từng thấy prompt 2FA khi chơi game EA trên console, đã kiểm tra đăng nhập dựa trên token Xbox/PSN
• Tài liệu Nexus Connect API có cách truyền token Xbox/PSN; sau khi lấy PSN client ID từ luồng đăng nhập PSN của site EA, đã thử đăng nhập bằng token PSN
• Đăng nhập bằng token PSN tạo persona namespace ps3 và có thể đăng nhập tài khoản mà không cần 2FA, nhưng client có dp.client.default không thể xử lý namespace ps3
• Khi thêm header X-Include-Namespace vào /connect/tokeninfo, phát hiện mỗi OAuth client có danh sách namespace persona có thể thao tác
  • Ví dụ JUNO_PC_CLIENT bao gồm các namespace cem_ea_id, steam, epic, xbox
• Namespace Xbox được cho phép, nhưng không thể tự tạo thủ công Microsoft XSTS token hợp lệ cho game, nên đã thử trên Xbox thật
• Tạo tài khoản Microsoft mới, liên kết persona Xbox với tài khoản EA thử nghiệm, rồi di chuyển persona Xbox đó sang tài khoản nạn nhân
• Khi đăng nhập bằng tài khoản Xbox trên website EA, xác minh email vị trí mới xuất hiện; nhưng khi cài Battlefield 2042 trên Xbox và đăng nhập game, đã truy cập được vào tài khoản nạn nhân
• Sau đó, khi đăng nhập website EA bằng cùng tài khoản Xbox, đăng nhập web vào tài khoản nạn nhân cũng thành công mà không cần xác minh email

Phạm vi ảnh hưởng và mức độ nghiêm trọng

• Có hai hướng chính mà kẻ tấn công có thể dùng
  • Di chuyển dữ liệu persona của người khác ra khỏi tài khoản để đánh cắp tên người dùng và dữ liệu game
  • Chuyển persona Xbox của mình sang tài khoản nạn nhân, đăng nhập game EA trên Xbox, rồi khi mạng đã được tin cậy thì đăng nhập website EA bằng tài khoản Xbox
• Ảnh hưởng bổ sung cũng lớn
  • Có thể đặt persona của người khác vào trạng thái bị cấm, chặn họ chơi hầu hết game online
  • Có thể đổi tên người dùng của người khác rồi chiếm lấy tên đó
  • Vì lệnh cấm game được xử lý bằng cách vô hiệu hóa entitlement game trên toàn tài khoản, có thể chuyển persona sang tài khoản mới để vượt qua lệnh cấm game
• Luồng này chủ yếu có thể thực hiện qua một endpoint API duy nhất mà không cần tương tác người dùng
• Mức độ nghiêm trọng được đánh giá là CVSS 10.0 theo AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Lịch sửa lỗi và ý kiến tiếp theo

• Lỗ hổng được báo cáo cho EA vào ngày 16/6/2024
• EA gửi xác nhận vào ngày 25/6/2024 và gán mức độ nghiêm trọng critical
• Lịch vá như sau
  • 8/7/2024: Triển khai Patch 1, kiểm tra ownership của persona
  • 18/7/2024: Triển khai Patch 2, chưa rõ chi tiết
  • 6/9/2024: Triển khai Patch 3, chưa rõ chi tiết
  • 10/9/2024: Triển khai Patch 4, gỡ bỏ tài liệu
  • 8/10/2024: Triển khai Patch 5, chưa rõ chi tiết
• Dự đoán ban đầu của EA là việc sửa lỗi có thể kéo dài đến cuối năm, và có đánh giá rằng với một vấn đề cốt lõi là tài liệu bị lộ cùng một endpoint không an toàn duy nhất, nên có bản vá tạm thời nhanh hơn
• EA hiện vẫn chưa có chương trình bug bounty, và còn lo ngại rằng nếu không có phần thưởng thực chất cho việc báo cáo, có thể sẽ có người giữ kín lỗ hổng
• Tài khoản bạn bè dùng trong thử nghiệm ban đầu là tài khoản đã được đồng ý

[GN⁺]

Ý kiến trên Hacker News

• EA thích dùng hệ thống chung cho nhiều trò chơi. Khi mày mò Madden, tôi phát hiện có một backend chung tên là blaze và có các endpoint web/TCP dùng chung
  Tôi đã tạo một công cụ để gọi endpoint này, nhưng phải tải XML lên; về sau mới biết mỗi lần gọi là máy chủ EA lại chết
  Vì mỗi request đều chiếm một máy chủ mới, tôi đã làm crash lần lượt toàn bộ các máy chủ Madden, và cuối cùng EA tạo API để mọi người khỏi mày mò nữa

  • Blaze là tên của một framework/dịch vụ C++ để tạo backend tùy chỉnh cho game online. Nó cho phép các đội game phát triển tính năng online theo một cách tiêu chuẩn, với MySQL ở phía sau
    Theo tôi nhớ thì khoảng 5.000–10.000 người chơi cần một instance Blaze
  • Tôi là tác giả bài viết; năm ngoái tôi cũng viết một bài đề cập rất nhiều lỗ hổng Blaze mà tôi tìm thấy, nhưng chưa công bố
    Có vẻ như hiện giờ họ dùng định dạng độc quyền và khá tự mãn với kiểu bảo mật dựa trên giả định rằng không ai sẽ tìm ra cách giao tiếp với nó, tức là bảo mật bằng sự mập mờ
    Một ngày nào đó tôi muốn quay lại bài đó; ít nhất thì nội dung cũng khá thú vị
  • Gần đây tôi nghĩ mình đã thấy API này trong một game khác. Có phải là frontend GraphQL không? Họ đã tắt introspection, nhưng thông báo lỗi lại tử tế gợi ý cho các tên trường bị nhập sai
    Mẹo khi reverse engineer API của một dịch vụ nổi tiếng như vậy là dùng tìm kiếm mã trên GitHub. Thử đưa vào một tên endpoint độc nhất; thường sẽ thấy những người tương tự từng tự hack một API client nhỏ, và điều đó giúp ích cho việc điều tra của tôi theo những cách không ngờ tới
  • Nếu quét qua các giá trị lặp của PSN client ID và thử đăng nhập vào proxy gateway của EA, nó sẽ trả về giá trị namespacename lấy từ dữ liệu cá nhân. Thông tin token 2FA cần được băm tại endpoint /tokeninfo/ lấy từ JUNO
    Khi thử tích hợp hậu kỳ, hạ tầng cho API C++ thường trả về ID người dùng PSN

• Như một người bình thường hiển nhiên sẽ làm, tôi đặt mua Xbox giao hàng ngày hôm sau, cài Battlefield 2042, rồi chờ khoảnh khắc quyết định — và đã vào được
  Hacker đúng là tuyệt vời <3

• Điều thú vị là luồng chi tiết họ đi từ điểm này sang điểm tiếp theo. Chắc hẳn ngoài đời nó không gọn gàng, tuyến tính như một bài blog
  Để cho thấy thời gian và công sức thực tế cần cho kiểu tấn công này, hẳn phải có cả núi ghi chú; xem những ghi chú đó chắc cũng thú vị

• Điều kỳ lạ nhất trong toàn bộ chuyện này là EA đã khẳng định suốt nhiều năm rằng việc hủy liên kết tài khoản Xbox hiện có rồi liên kết lại với tài khoản mới là bất khả thi về mặt kỹ thuật. Cứ xem các bài như https://www.reddit.com/r/XboxGamePass/comments/12gsy4i/ea_xb... và vô số bài trên diễn đàn EA
  Tôi cũng từng đâm vào bức tường này, nói chuyện với hỗ trợ EA hàng giờ, nhưng họ không thể liên kết tài khoản Xbox rất cũ của tôi. Vì vậy tôi không thể đăng nhập vào bất kỳ game EA nào trên Xbox, và gần như không chơi được gì trên nền tảng đó
  Vậy mà ở đây hóa ra chuyện đó hoàn toàn có thể

  • Tôi nhớ vào năm 2004–2005, tài khoản Hotmail của tôi có dung lượng lưu trữ 4MB thông thường, trong lúc Microsoft đang triển khai nâng cấp miễn phí lên 250MB cho mọi người
    Kỳ lạ là tài khoản của tôi mất quá nhiều thời gian; trong 1–2 năm tôi đã nhiều lần gửi email cho hỗ trợ, nhưng lần nào cũng nhận được câu trả lời rằng họ đang nâng cấp tài khoản nhanh nhất có thể, nhưng khối lượng công việc quá lớn nên sẽ mất nhiều năm
    Sau đó trên một diễn đàn tôi thấy một mẹo: tạm đóng tài khoản rồi mở lại thì có thể tăng lên 25MB, nhưng vẫn không phải 250MB như đã hứa
    Tình cảnh tài khoản cũ 2–4MB, tài khoản mới 25MB, còn việc triển khai lên 250MB kéo dài nhiều năm khiến tôi có ấn tượng rằng Microsoft đang vật lộn khủng khiếp để tìm dung lượng lưu trữ còn trống. Nhưng chỉ vài tháng sau, khi phải cạnh tranh với Gmail, họ quyết định tặng mọi người 2GB, và triển khai cùng lúc cho toàn bộ tài khoản Hotmail, bao gồm cả tài khoản của tôi. Chắc hẳn người ngoài hành tinh đã mang đến một UFO chất đầy ổ cứng
    [1] Ví dụ một bài diễn đàn cũ về mẹo đó, cũng có bình luận khen GMail mới ra mắt: https://bimmersport.co.nz/topic/5232-hotmail-upgrade-2mb-to-...
  • Cuộc tấn công này cho thấy có thể thay đổi liên kết và chơi game, nhưng không biết sẽ có tác dụng phụ nào ngoài kịch bản dễ kiểm chứng trong bài viết
    Việc thay đổi liên kết có thể làm vô hiệu dữ liệu lưu trong hệ thống tính phí, làm hỏng báo cáo hằng tháng gửi tới bộ phận Microsoft Xbox, hoặc khiến trang quản trị nội bộ bị crash khi tải
    Tôi không định bênh EA, nhưng nếu đã xử lý nhiều hệ thống microservice phức tạp, bạn sẽ thấy việc thay đổi cấu trúc dữ liệu ở một nơi không phải lúc nào cũng đơn giản
  • Có thể họ đang thêm tính năng này để sửa vấn đề đó, nhưng không may nó bị lợi dụng trước khi công bố
  • Đáng tiếc là với các game đa nền tảng hiện đại như Battlefield 2042, quyền chơi game, bạn bè và dữ liệu lưu được lưu trên chính tài khoản EA chứ không phải persona, nên dữ liệu đó không được chuyển sang
  • Có lẽ không phải là bất khả thi về mặt kỹ thuật, mà nhiều khả năng là đội hỗ trợ khách hàng không thể xử lý

• Có lẽ cũng sẽ thú vị nếu khóa tất cả tài khoản và mong là họ không có bản sao lưu DB

  • Tôi muốn thấy mọi công ty quy mô 10 tỷ USD mà không có chương trình bug bounty đều gặp chuyện như thế này. Nếu không có bất kỳ phần thưởng nào cho việc báo cáo lỗ hổng, chẳng khác nào khuyến khích hacker khai thác vì lợi ích riêng hoặc gây hỗn loạn
    Với tư cách khách hàng trả tiền, tôi kỳ vọng các công ty này có thái độ tốt hơn, và nếu họ không có chương trình như vậy thì cá nhân tôi cũng sẽ không trách các hacker nếu họ khai thác những gì tìm được
  • Có thể vui trong chốc lát, nhưng chắc chắn họ có sao lưu
    Không ai lưu 400 triệu bản ghi trên một máy duy nhất cả, và rốt cuộc bạn chỉ khiến dịch vụ bị sập cả buổi chiều rồi nhận 15 năm tù liên bang mà thôi
  • Đây chính là lý do thế giới quay lưng với ngành công nghệ
    Vì phản ứng đầu tiên, hoặc ít nhất là bài đang được chấm điểm cao nhất lúc này, lại là ý nghĩ rằng gây thiệt hại cho hàng triệu người để dạy cho công ty họ giao dịch một bài học thì sẽ “vui”
  • Bật tất cả trò chơi cho mọi tài khoản thì còn vui hơn nhiều. Theo đúng nghĩa là tất cả. Trí tưởng tượng hạn hẹp quá
  • Tôi cũng đã nghĩ đến chuyện này. Nếu thực sự không báo cáo mà quyết tâm nghịch phá thì kết quả sẽ thế nào? Có bị truy ra không? EA có sập trong vài tuần không?

• Trong bài có đoạn này:
  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.
  Có thể giải thích thêm một chút về phần này không? Tôi cứ nghĩ không thể dễ dàng đọc được các thông tin xác thực như vậy từ file nhị phân thực thi, và nếu file thực thi của game phải tự xác thực với máy chủ từ xa thì tôi cũng không rõ nhà phát triển nên làm gì khác

  • Thông tin xác thực được lưu dưới dạng chuỗi, nên nếu tìm trong file nhị phân các mẫu trông giống thông tin xác thực thì sẽ thấy chúng ở đâu đó
    Trong kiến trúc client-server, client luôn không đáng tin cậy. File thực thi không nên cần tự xác thực với máy chủ. File thực thi nên xác thực dưới danh nghĩa người dùng hoặc tài khoản bằng thông tin do người dùng cung cấp
    Với những thứ như telemetry, các endpoint kiểu này thường nhận dữ liệu không xác thực hoặc xác thực yếu, rồi thực hiện nhiều lớp kiểm tra để ngăn lạm dụng. Thường chúng cũng chỉ cho phép ghi/thêm dữ liệu
  • Tôi không hiểu vì sao lại giả định file nhị phân sẽ không dễ đọc. Trên một nền tảng không bị khóa, file nhị phân hoàn toàn đủ dễ đọc
    Bạn sẽ cần một hệ thống mã hóa file thực thi và để vùng bảo mật trong die CPU xử lý giải mã bằng khóa riêng, nhưng ngay cả vậy thì có lẽ chỉ là vấn đề thời gian trước khi ai đó delid con chip để lấy khóa
  • Nếu máy tính đọc được, và bạn có toàn quyền kiểm soát máy tính đó, thì bạn cũng đọc được. Có quyền truy cập vật lý là xong
    Ngay cả khi mã hóa và đưa khóa mã hóa vào HSM, việc đó trên một máy client bất kỳ có lẽ là không khả thi; hơn nữa đến một lúc nào đó game cũng phải giải mã chuỗi đó và đưa vào bộ nhớ. Và bộ nhớ đó có thể đọc được
  • Nếu chương trình có thể truy cập thông tin xác thực và chương trình đó chạy trên máy tính của tôi, thì dù có làm rối mã kiểu gì tôi cũng có thể truy cập thông tin xác thực đó
    Việc nhà phát triển game nên làm là đặt hệ thống tài khoản ở backend và để người chơi nhập thông tin xác thực của họ trong game. Khi đó game có thể tự định danh với máy chủ backend dưới danh nghĩa người chơi này
    Làm như vậy mới có thể quy các hành động ở backend về một người chơi cụ thể và có cơ sở tốt để đưa ra quyết định bảo mật
  • Tìm các thông tin xác thực như vậy trong file nhị phân thực thi thì khó nhưng không phải không thể. Phiền hơn việc trích chuỗi từ một file JavaScript đã minify, nhưng chắc chắn còn rất xa mới là bất khả thi
    Có các công cụ như IDA, nên cũng không phải là mò bằng mắt thường giữa mọi thứ trông giống chuỗi để tìm thông tin xác thực
    Vấn đề không hẳn nằm ở việc có thông tin xác thực được hardcode trong file nhị phân, mà ở chỗ thông tin xác thực đó có quyền đặc quyền

• Với tư cách kỹ sư ở một công ty kiểu này, đôi khi tôi tự hỏi cảm giác sẽ thế nào khi API nội bộ, các lỗi kỳ quặc và chuyện bẩn trong nhà bị phơi ra trong một báo cáo xâm nhập công khai
  Tuy nhiên trong trường hợp như thế này, khả năng một cá nhân duy nhất chịu trách nhiệm cho lỗ hổng là thấp. Có lẽ 5–6 đội sở hữu các phần khác nhau đã bị khai thác, và chính vì vậy exploit mới tồn tại ngay từ đầu. Đó là một hệ thống khổng lồ, phức tạp, nơi ai cũng chỉ hiểu phần nhỏ của mình

  • Nếu bạn có đầu tư cảm xúc, hoặc dù chỉ là tài chính, vào đội thì sẽ thấy tệ, nhưng khi tôi còn ở EA, họ gần như cố hết sức để khiến việc đầu tư cảm xúc trở nên khó khăn
    Ở một công ty cỡ EA, chuyện này gần như chắc chắn sẽ được dùng cho đấu đá nội bộ, và dù gây hại cho toàn công ty, người ta vẫn sẽ tận dụng nó để giành quyền kiểm soát lớn hơn đối với một công ty đã nhỏ đi
  • Ở những tập đoàn lớn như vậy, chẳng ai quan tâm đâu. Chỉ là công việc để nhận lương thôi
    Ai cũng là tài nguyên có thể thay thế, vậy sao phải đầu tư cảm xúc vào công việc
  • Là người từng làm, có lẽ cùng đội với đội vẫn đang duy trì đúng phần code này khoảng 10 năm trước, tôi đã lướt nhanh bài viết để kiểm tra xem có phải code mình viết hoặc phần mình từng động vào không
    Hồi đó tên đội là Nucleus, nên trong một phản hồi của bài viết, refType là NUCLEUS. Đội này xây dựng và duy trì các API backend cho quyền hạn, tài khoản và thanh toán
    Đó là kỳ thực tập mùa hè, và một năm sau tôi nhận lời mời từ đội đó rồi bắt đầu làm việc. Khi ấy tên đội đã đổi thành EADP và đang dần được sáp nhập với Origin. Tôi nhớ không rõ DP có phải là Data Platform hay không, nhưng vì vậy một trong các endpoint bắt đầu bằng dp.
    Lúc đó không có cơ sở dữ liệu GraphQL; tất cả là Enterprise Java, OCI, Spring, Hibernate, v.v., và trước khi tôi rời đi thì cũng có một phần Groovy/SpringBoot mới hơn. Nó chạy trên máy chủ trung tâm dữ liệu chứ không phải cloud
    Dù vậy tôi đã làm những việc thú vị, và tuy rời đi 2–3 năm sau một sự cố lớn, tôi đã học được rất nhiều về phát triển backend từ các kỹ sư giỏi
    Tôi hoàn toàn không biết đội hiện nay thế nào, kỹ sư là ai, hay chuyện gì đang xảy ra, nhưng thấy những việc như thế này thì thật đáng buồn. Hồi đó chúng tôi rất có ý thức về bảo mật, và cũng đã làm hệ thống phát hiện và xử lý các nỗ lực brute force trên trang đăng nhập
    Tôi không biết nó còn hoạt động hay đang chạy hay không, nhưng các bước kiểm tra/review bảo mật nhằm giảm khả năng bị xâm nhập và bề mặt tấn công từng là một phần công việc trong sprint
  • Đặc biệt sẽ khó chịu nếu tôi không làm ở bộ phận đó nên không có quyền kiểm soát, nhưng biết rằng mình có thể làm tốt hơn họ
  • Nếu đọc một bài như vậy trong khi biết chính mình đã triển khai API đó, chắc tôi sẽ thót tim

• Nếu bạn thấy bài này thú vị, có thể xem thêm nhiều nội dung tương tự trên các nền tảng bug bounty như Hacktivity của HackerOne: https://hackerone.com/hacktivity

  • Còn nhiều hơn ở đây: https://pentester.land/writeups/
    Được cập nhật vài tuần hoặc vài tháng một lần

• Có hướng dẫn best practice nào đó về cách thiết lập chương trình bug bounty không?

  • Tôi làm trong lĩnh vực này nên khó biết còn thiếu thông tin gì, nhưng với tôi thì việc này có vẻ khá đơn giản
    Chỉ cần đăng ở đâu đó trên website rằng mọi người được phép kiểm tra bảo mật kỹ thuật với điều kiện tuân theo quy trình công bố lỗ hổng có điều phối, rồi ghi rõ sẽ thưởng gì cho những lỗi nào trong phạm vi nào. Tất nhiên cần cụ thể hơn một chút so với một câu này
    Cũng nên ghi trước các ngoại lệ như nếu quá trẻ hoặc quá già thì không được trả tiền, hoặc nếu sinh ra ở một quốc gia “không đúng” và thuộc diện bị trừng phạt thì không được tham gia, để sau này khỏi mất lòng nhau
    Nếu có câu hỏi cụ thể, tôi có thể trả lời hoặc tìm tài liệu tham khảo tốt

• Nhìn vào đoạn này trong bài:
  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.
  Vậy là tác giả đã báo cáo việc này và không nhận được gì sao?

  • Nói là không nhận được gì thì không đúng. Luôn có khả năng bị đe dọa hành động pháp lý vì đã báo cáo lỗ hổng
  • Thật đáng thất vọng khi có quá nhiều công ty không cung cấp bug bounty. Những lỗ hổng tôi tìm được suốt nhiều năm cứ chất đống trong đầu
    Việc báo cáo có rủi ro pháp lý, và chuyện về mặt kỹ thuật công ty có thể kiện đến cùng cũng chẳng giúp ích gì. Đây là theo tiêu chuẩn EU/UK
  • Cứ thế này thì người ta sẽ đi vào những góc tối hơn của Internet và bán thông tin cho người trả giá cao nhất
  • Đúng vậy, là không nhận được gì