Bug bounty rèn luyện kỹ năng bảo mật của nhà nghiên cứu như thế nào

Trong khuôn khổ Tháng Nâng cao Nhận thức An ninh mạng, GitHub đã vinh danh @r31n – một trong những nhà nghiên cứu nổi bật của chương trình GitHub Security Bug Bounty. Người này được biết đến nhờ nhiều phát hiện có tác động lớn trên GitHub Enterprise Server.

Bài phỏng vấn không chỉ kể câu chuyện cá nhân mà còn vạch ra một bức tranh rõ nét về cách cộng đồng bảo mật đang thay đổi dưới ảnh hưởng của AI, và vì sao chất lượng báo cáo vẫn quan trọng hơn số lượng.

Minh họa chương trình săn lỗ hổng của GitHub

Vì sao GitHub là mục tiêu hấp dẫn với người săn lỗ hổng?

Theo @r31n, điều khiến GitHub trở thành chương trình được nhiều nhà nghiên cứu quay lại chính là diện tấn công khổng lồ. Nền tảng này lớn, phức tạp và liên tục thay đổi khi tính năng mới được phát hành.

• Môi trường đa dạng về sản phẩm, công nghệ và kiến trúc
• Cấu trúc phần thưởng cạnh tranh
• Đội ngũ GitHub hợp tác chặt chẽ với các nhà nghiên cứu
• Cơ hội học hỏi liên tục vì "mục tiêu không bao giờ thực sự hoàn thiện"

Đối với độc giả Việt Nam đang tìm cách bước vào lĩnh vực bảo mật, đây là gợi ý đáng cân nhắc: chọn một nền tảng lớn, phổ biến và có chương trình bug bounty minh bạch để rèn luyện thay vì chạy theo các mục tiêu nhỏ lẻ.

Chuỗi khai thác – niềm đam mê thực sự

Thay vì gắn bó với một nhóm lỗ hổng cố định, @r31n đặc biệt hứng thú với exploit chain – những trường hợp vài lỗi tưởng như vô hại khi kết hợp lại tạo thành mối nguy nghiêm trọng.

Một ví dụ điển hình là open redirect. Đứng riêng lẻ, mức ảnh hưởng có thể hạn chế. Nhưng nếu tồn tại một SSRF trên miền được whitelist và hệ thống lại theo dõi chuyển hướng, open redirect bỗng trở thành mắt xích quan trọng trong chuỗi tấn công lớn hơn.

"Phần tôi thích nhất trong nghiên cứu lỗ hổng có lẽ là tìm ra những mối liên kết đó – nhìn vào hai hoặc ba lỗi riêng biệt và nhận ra chúng có thể được kết hợp theo cách không ai lường trước. Việc này cần kiến thức kỹ thuật, nhưng cũng cần khá nhiều sáng tạo."

Tư duy quan trọng hơn công cụ

@r31n cho biết bản thân thiên về điều tra thủ công và các script nhỏ, chuyên biệt thay vì những bộ công cụ tự động hóa cồng kềnh. Nguyên tắc là chỉ tự động hóa khi nhận thấy mình lặp lại một tác vụ cụ thể.

Điều đáng chú ý là AI đã ảnh hưởng đến cách làm việc của nhà nghiên cứu này nhiều hơn bất kỳ công cụ bảo mật đơn lẻ nào. Tuy nhiên, theo anh, tư duy vẫn quan trọng hơn công cụ:

• Có thể rất giỏi một công cụ nhưng vẫn bỏ lỡ lỗi thú vị vì chỉ nhìn mục tiêu qua lăng kính của công cụ đó
• Phụ thuộc quá nhiều vào công cụ đôi khi làm hẹp cách suy nghĩ
• Công cụ thay đổi, kỹ thuật thay đổi, nhưng tính tò mò và sự kiên trì thường bền vững hơn

Từ "tính năng thú vị" đến phát hiện được xác nhận

Cách tiếp cận của @r31n bắt đầu bằng việc lập bản đồ ứng dụng và hiểu cách các thành phần liên kết với nhau. Anh dành nhiều thời gian hơn cho các chức năng phức tạp, tích hợp, ranh giới tin cậy và những điểm hành xử khác thường.

Sau đó, thay vì bắt đầu từ một nhóm lỗ hổng cụ thể, anh tư duy theo cặp source – sink:

• Source: điểm dữ liệu do kẻ tấn công kiểm soát xâm nhập ứng dụng (tham số request, tệp tải lên, đầu vào API, dữ liệu từ dịch vụ khác)
• Sink: thao tác nhạy cảm tiêu thụ dữ liệu đó (gửi request mạng, truy cập tệp, thực thi tiến trình, truy vấn cơ sở dữ liệu, quyết định phân quyền)

Phần thú vị nằm ở việc truy vết đường đi giữa hai điểm: dữ liệu được biến đổi, kiểm tra hay vượt qua ranh giới tin cậy như thế nào, và các biện pháp kiểm soát có đủ chặt trước khi dữ liệu chạm tới sink hay không.

"Tôi coi một phát hiện là đã được xác nhận khi hiểu rõ đường tấn công, tạo được PoC hoạt động và giải thích được tác động thực tế."

AI: chất xúc tác, không phải người thay thế

@r31n sử dụng AI khá nhiều, chủ yếu như một chất xúc tác giúp tăng tốc công việc:

• Điều hướng mã nguồn xa lạ
• Tìm các điểm gọi hàm
• Truy vết dữ liệu xuyên suốt codebase
• Viết script PoC sau khi đã xác định lỗ hổng

Song anh nhấn mạnh một nghịch lý thú vị: AI càng hữu ích khi bản thân bạn hiểu vấn đề càng rõ. Câu hỏi chung chung kiểu "ứng dụng này có lỗ hổng không?" thường không mang lại kết quả tốt. Thay vào đó, cần cung cấp ngữ cảnh phù hợp, giải thích những gì đã biết và đặt câu hỏi hẹp.

Anh cũng cảnh báo không bao giờ coi kết luận của AI là sự thật: ảo giác, dương tính giả, giả định sai và câu trả lời tự tin nhưng sai đều phổ biến. Mọi thứ vẫn phải được xác minh thủ công.

Bảo mật trong kỷ nguyên AI

Dùng AI có trách nhiệm trong bug bounty

Lời khuyên của @r31n rất rõ ràng: dùng AI để nâng cao chất lượng nghiên cứu, không phải để phó thác trách nhiệm.

• Nếu AI nói tìm thấy lỗ hổng, điều đó không có nghĩa bạn đã tìm ra lỗ hổng thật
• Phải tự tái hiện được lỗi
• Phải hiểu chính xác ranh giới bảo mật nào bị xâm phạm và tác động thực tế là gì
• Lý tưởng nhất là hiểu vấn đề đủ sâu để viết báo cáo mà không cần AI
• Xây dựng PoC rõ ràng để đội ngũ bảo mật có thể làm theo

Theo anh, AI đã hạ thấp rào cản gia nhập lĩnh vực nghiên cứu bảo mật – điều này tốt ở nhiều khía cạnh. Nhưng mặt trái là số lượng báo cáo chưa được xác minh mà các đội ngũ phải xử lý cũng tăng vọt.

"AI nên giúp nghiên cứu tốt hơn, chứ không chỉ tạo ra nhiều báo cáo hơn."

Kiểm thử tính năng AI: ranh giới không nằm ở mô hình

Khi ngành công nghệ tung ra ngày càng nhiều tính năng tích hợp AI, @r31n cho rằng cách kiểm thử cần thay đổi. Kẻ tấn công có thể tác động đến thành phần ra quyết định mang tính xác suất thông qua dữ liệu, chỉ dẫn hoặc ngữ cảnh mà mô hình nhận được.

Tuy nhiên, việc khiến mô hình nói hay làm điều bất ngờ chưa phải phần thú vị nhất. Câu hỏi quan trọng hơn là sự tác động đó cho phép kẻ tấn công đạt được gì: truy cập thứ lẽ ra không được phép, hay khiến hệ thống hành động với đặc quyền mà kẻ tấn công không có.

Vì thế, các rào chắn ở cấp độ mô hình không bao giờ nên là ranh giới bảo mật duy nhất. Vẫn cần những kiểm soát tất định xung quanh mô hình: phân quyền đúng, quyền truy cập tối thiểu, cô lập và kiểm tra dữ liệu.

"Mô hình thì mới, nhưng nhiều sink nguy hiểm thì không hề mới."

Đầu ra của mô hình vẫn phải được coi là dữ liệu không đáng tin cậy. Nếu nó chảy vào trình duyệt, truy vấn cơ sở dữ liệu, lệnh shell hay request mạng mà thiếu kiểm soát, các lỗ hổng quen thuộc vẫn xuất hiện: XSS, SQL injection, command injection, SSRF...

Lời khuyên cho người mới bắt đầu

Khi được hỏi điều gì mình ước biết sớm hơn, @r31n trả lời ngắn gọn: học hệ thống, đừng học danh sách kiểm tra.

• Thay vì sưu tầm danh sách kỹ thuật, payload và công cụ rồi thử lần lượt, hãy hiểu hệ thống vận hành ra sao
• Nắm logic nội tại, luồng dữ liệu, quan hệ tin cậy, các giả định
• Đừng mặc định thứ gì đó an toàn chỉ vì nó trông an toàn
• Nhiều nghiên cứu thú vị bắt đầu bằng câu hỏi "Tại sao thứ này lại hoạt động theo cách này?" thay vì "Nên thử payload nào tiếp theo?"

Để có báo cáo hợp lệ đầu tiên, anh khuyên chọn một chương trình và một mục tiêu duy nhất, gắn bó với nó trong thời gian dài. Việc liên tục nhảy giữa các mục tiêu khiến khó xây dựng mô hình tư duy thực sự về bất kỳ hệ thống nào.

Các bước nên làm:

1. Sử dụng ứng dụng như người dùng thật
2. Khám phá những luồng kỳ lạ
3. Thử nghiệm với các vai trò và cấp quyền khác nhau
4. Đọc tài liệu, quan sát request/response, xem xét API
5. Tận dụng lab, khóa học, write-up công khai và báo cáo đã công bố

Hai sai lầm phổ biến được anh chỉ ra là phụ thuộc công cụ quá sớm và bỏ cuộc vì các bài kiểm tra hiển nhiên không tìm thấy gì.

Ngoài màn hình: đạp xe leo đèo và nghiên cứu lỗ hổng có gì giống nhau?

Khi không săn lỗ hổng, @r31n dành thời gian cho thể thao sức bền, chủ yếu là đạp xe đường trường, đặc biệt ở vùng núi. Anh thích thử thách thể chất của những chặng leo dài.

Và anh nhận ra một điểm tương đồng thú vị giữa leo đèo và nghiên cứu lỗ hổng:

"Bạn có thể bỏ ra rất nhiều công sức mà chẳng thấy tiến bộ bao nhiêu. Đôi khi bạn không biết việc mình đang làm có dẫn đến đâu không. Bạn chỉ tiếp tục. Và thỉnh thoảng, nó được đền đáp."

Độc giả quan tâm có thể theo dõi @r31n trên HackerOne. Còn nếu bài viết này truyền cảm hứng cho bạn bắt đầu săn lỗ hổng, GitHub khuyến khích gửi phát hiện qua nền tảng HackerOne của mình.