Làm thế nào để hack được hệ thống tracking bug của Google để đổi lấy $15,600 tiền thưởng

Bạn đã từng nghe đến Google Issue Tracker chưa? Nếu không phải là nhân viên Google hay developer từng report bugs trong các công cụ của Google gần đây thì có thể bạn sẽ chưa nghe đến. Thực ra tôi cũng vậy cho đến khi phát hiện các báo cáo lõ hổng xảy ra khi mở 1 thread mới, kèm theo các email notifications thông thường.

Vì vậy, tôi đã ngay lặp tức phá nó.

Vậy chính xác thì website này là gì? Theo documentation, Issue Tracker (được gọi nội bộ là Buganizer System) là 1 công cụ được sử dụng in-house tại Google để theo dõi các requests về bugs và tính năng trong quá trình phát triển product. Google cũng công bố rộng rãi Issue Tracker để cộng đồng và partner sử dụng khi muốn phối hợp với các teams của Google trong những dự án đặc biệt.
Nói cách khác, khi ai đó có vấn đề với 1 sản phẩm Google, thì vấn đề sẽ xuất hiện trên tracker issue. Chúng ta, những users bên ngoài chỉ có thể thấy được 1 phần của tảng băng trôi: 1 tập nhỏ các categories được chấp thuận trước và các vấn đề được người của Google thêm vào tài khoản bên ngoài, như các báo cáo về lỗ hổng bảo mật. Nhưng có bao nhiêu thông tin được che giấu dưới tảng băng đó?

Bằng cách quan sát các IDs số được chỉ định trong các public threads mới nhất, chúng ta có thể dễ dàng ước lượng được mức độ mà công cụ này được sử dụng nội bộ. Có khoảng 2000-3000 issues mỗi giờ được mở trong giờ làm việc tại Mountain View, và chỉ 0,1% trong số đó là public. Dường như lỗ hổng dữ liệu trong hệ thống này sẽ gây ảnh hưởng lớn, vậy nên cứ phá nó thôi!

Nỗ lực #1: Tạo 1 Google account dành cho nhân viên

Điều đầu tiên mà tôi phát hiện khi khám phá issue tracker là khả năng tham gia vào các cuộc thảo luận bằng cách gửi emails đến 1 địa chỉ cụ thể như là:

buganizer-system+ componentID + issueID @google.com

(trong này componentID là số thể hiện 1 category và issueID là 1 unique identifier cho thread mà bạn đang làm việc)

Cái này làm tôi nhớ đến phát hiện gần đây gọi là Ticket Trick, cho phép hackers xâm nhập vào hệ thống chat của các tổ chức thông qua dạng email system tương tư. Vì đây là địa chỉ email @google.com , tôi đã cố gắng đăng nhập vào Slack team của Google đang sử dụng email này và trang xác nhận mà tôi có trông khá triển vọng:

Nhưng mà không có email của Slack hiển thị lên.

Điều tuyệt vời tiếp theo mà tôi có thể nghĩ đến là việc có 1 account Google với địa chỉ email chính là @google.com sẽ đem đến vài quyền lợi đặc biệt trên Buganizer. Bạn sẽ không được phép đăng kí 1 account như vậy ngoài Google:

Tuy nhiên, tôi nhận ra 1 method để vượt qua bước lọc này: Nếu đăng kí với địa chỉ email giả bất kì, nhưng không thể xác nhận tài khoản bằng cách click vào link nhận từ email, tôi được phép thay đổi email address không giới hạn. Sử dụng method này giúp tôi thay đổi email của 1 Google account hoàn toàn mới thành [email protected] .

Ngay sau đó, tôi nhận được email xác thực như 1 tin nhắn trên trang issue tương ứng:ge:

Tốt, tôi đã click vào link confirmation, đăng nhập vào Issue Tracker và…

Tôi được điều hướng đến trang login liên kết. Nhưng mà thông tin Google account của tôi lại không hoạt động được ở đó. Haizz.

Tuy nhiên, account này mang đến nhiều quyền lợi ở những nơi khác trên Internet, bao gồm khả năng hitch a ride (hình như miễn phí?), như vậy đây vẫn là 1 vấn đề bảo mật chào đón các users có ý đồ xấu.

Accepted: 11 hours | Bounty: $3,133.7 | Priority: P1

Nỗ lực #2: Nhận thông báo về các tickets nội bộ

Một tính năng khác của Issue Tracker thu hút sự chú ý của tôi khi đang làm quen với UI là khả năng đánh sao các items. Đánh giá 1 issue đồng nghĩa là bạn đang quan tâm đến vấn đề đang được thảo luận và bạn muốn nhận email notifications khi ai đó comment.

Tính năng đặc biệt thiếu đi các lỗi khi cố gắng sử dụng tính năng này trên các vấn đề mà tôi đã không thể tiếp cận được. Các quy tắc kiểm soát quyền truy cập dường như không bao giờ được áp dụng cho endpoint này, nên tôi đã đăng nhập vào account thứ 2 của mình và cố gắng đánh dấu sao lên 1 báo cáo lổ hổng từ account chính bằng cách thay thế Issue ID trong request. Sau đó, tôi thấy message này, đồng nghĩa là action của mình đã thành công.

1 PERSON HAS STARRED THIS ISSUE.

Có phải rất dễ dàng để do thám các lổ hỗng mở của Google không? Tôi nhanh chóng dăng 1 comment vào vấn đề để xác định xem thử liệu tài khoản tấn công hư cấu của mình có được thông báo không.

Nhưng 1 lần nữa, không có email nào hiện lên hết.

Vì vài lý do nào đó không nhớ rõ nữa, tôi đã quyết định thực hiện vài testing khác. Vì vậy, tôi đã có 1 issue ID mới, và ngoại suy hàng ngàn IDs trùng khớp với các issues mới nhất trong database. Sau đó tôi đánh sao hết tất cả.

Trong vòng vài phút, inbox của tôi trở thành như này:

Khi xem xét kĩ hơn, thực ra không có gì quá thú vị diễn ra trong những threads đó. Rõ ràng là tôi chỉ có thể “rình” được những đoạn trò chuyện liên quan đến dịch thuật, nơi mà mọi người sẽ tranh luận những cách truyền tải ý nghĩa của 1 câu nói theo nhiều ngôn ngữ khác nhau 1 cách tốt nhất.

Tôi thậm chí còn cân nhắc không report lỗi này, hy vọng sẽ tìm được cách để tăng mức độ nghiêm trọng lên. Cuối cùng tôi nhận ra team bảo mật của Google có thể sẽ hứng thú với việc tìm ra các methods & biến số then chốt có thể xảy ra nên là tôi cứ gửi thông tin chi tiết.

Accepted: 5 hours | Bounty: $5,000 | Priority: P0

Nỗ lực #3: Game over

Khi bạn xem xét Issue Tracker trên vai trò là 1 user bên ngoài, hầu hết tính năng của nó đã bị loại đi, nên bạn sẽ bị giới hạn nhiều quyền lợi. Nếu muốn thấy được những điều thú vị mà các nhân viên Google có thể làm được, bạn có thể tìm các API endpoints trong các files Javascript. Một vài function bị vô hiệu hoàn toàn, trong khi 1 số khác bị dấu trong interface.

Khi thiết kế bản giới hạn của hệ thống, 1 ai đó tốt bụng sẽ để lại trong 1 method để chúng ta remove bản thân khỏi danh sách CCs, trong trường hợp chúng ta không còn hứng thú với 1 issue hoặc không muốn nhận emails về nó nữa. Có thể làm được điều này bằng cách gửi 1 request POST như thế này:
POST/action/issues/bulk_editHTTP/1.1

  • {*

“issueIds”:[

67111111,

67111112

],

“actions”:[

{

“fieldName”:“ccs”,

value":"[email protected]”,

“actionType”:“REMOVE”

}

]

}

Tuy nhiên, tôi nhận ra vài chuyện vô ý dẫn đến 1 vấn đề lớn:

  1. Quyền tiếp cận không phù hợp: Không có quy trình kiểm tra rõ ràng khi user hiện tại thực sự tiếp cận được vào các vấn đề chuyên biệt trong issueIds trước khi nỗ lực thực hiện action được cho trước.
  2. Thất bại lặng im : Nếu bạn cung cấp 1 địa chỉ email không có trong danh sách CCs, endpoint sẽ trả lại 1 message nói rằng email đã được remove thành công.
  3. Chi tiết vấn đề trong response: Nếu không có lỗi xảy ra trong quá trình action, 1 phần khác của system sẽ giả định rằng user đã có quyền lợi phù hợp. Vì vậy, chi tiết về vấn đề ID sẽ được trả lại trong HTTP response body.

Hiện tôi có thể xem thông tin chi tiết về mọi vấn đề trong database bằng cách thay thế issueIds trong request ở trên. Chính xác!

Tôi chỉ cố gắng xem 1 vài IDs liên tiếp, sau đó tự tấn công chính mình từ 1 account không liên quan để xác nhận mức độ nghiêm trọng của vấn đề này.

Đúng vậy, tôi có thể xem hết chi tiết các báo cáo lổ hỗng, kèm theo tất cả những thứ khác được host trên Buganizer.

Tệ hơn là, tôi có thể xâm nhập dữ liệu về rất nhiều tickets trong 1 request đơn, vì thế việc điều chỉnh tất cả các hoạt động nội bộ theo thời gian thực có lẽ đã không kích hoạt bất kì rate limiters nào.

Tôi đã nhanh chóng gửi chi tiết những gì mình khai thác được đến Google và đội ngũ bảo mật của họ đã phải vô hiệu endpoint bị ảnh hưởng 1 giờ sau đó. Response time thật ấn tượng!

Accepted: 1 hour | Bounty: $7,500 | Priority: P0

Khi tôi bắt đầu quá trình tìm kiếm lỗ hổng thông tin này, tôi nghiễm nhiên cho rằng nó sẽ trở thành Chén Thánh của Google bugs, vì nó tiết lộ thông tin về tất cả các bug khác (như HackerOne đã trả tối thiểu $10,000 cho vấn đề tương tự).

Nhưng tôi đã nhanh chóng nhận ra ảnh hưởng sẽ rất hạn chế vì tất cả các lổ hổng nguy hiểm đều bị vô hiệu trong 1 giờ đổ lại.

Tất nhiên tôi rất vui với số tiền kiếm được, hy vọng sẽ tìm được bugs trong các product khác của Google.

Nguồn: TopDev via medium.freecodecamp.org