An ninh sản phẩm, Các công ty và Cộng đồng săn lỗi, hành động của chúng ta ( Hackers )
Loạt bài này gồm 3 phần, phần đầu mình nói về xu hướng chung của an ninh sản phẩm ( Product Security ), Phần 2 nói về làm thế nào để một công ty tiếp cận tốt nhất với Security, phần cuối mình sẽ dành thời gian nói về cách chúng ta, những Hacker đã làm trong ngành này nhiều năm và những bạn trẻ mới tập tễnh bước chân vào trường đại học với ước mở trở thành Hacker chuyên nghiệp làm thế nào để thích nghi với xu hướng mới này.
Phần 1: Xu hướng chung của làm an ninh sản phẩm:
Chịu trách nhiệm cho Shopee Product Security có bao nhiêu người?
Câu trả lời là 3 người, và trách nhiệm chính đó thuộc về 1 bạn Việt Nam có thâm niên 10 năm trong nghề Bug Bounty Hunter.
Trong một thảo luận nội bộ mới đây, bạn ấy viết ( mình xin để nguyên văn có dùng * để che đi đối tượng được nhắc đến ) :
“Doing security by bug-by-bug combat, is the very out-of-date way of doing security. Here is an example: * and their security team, spent years (00s and early 10s) trying to kill all security vulnerabilities, with bug-by-bug combat strategy. And we are all old enough to remember how bad * security. But last recent years, they changed their strategy, they put more resources on finding innovative ways to eliminate entire bug classes, reducing attack vectors, mitigate weaknesses. And by now, their products are much much more secure.”
Mình không hoàn toàn đồng ý với lí do rằng các công ty lớn đang đổi chiến lược của họ, tuy nhiên cá nhân mình đồng ý với xu hướng bạn ấy nói, cách đây 15 năm, các công ty lớn hầu như không có chương trình trả thưởng như hiện nay, bug của họ nhận được sẽ thông qua 4 nguồn chính: từ nội bộ công ty kiểm tra, từ người dùng report lên, các hacker report một cách miễn phí và tự nguyện cho họ , và một số hình thức trả thưởng như ZDI ( họ duy trì hoạt động bằng cách nhận bug từ Hacker mũ trắng, sau đó viết signature cho bug này rồi bán lại cho các sản phẩm Firewall, AV để nhận diện). Và hiện nay, cái mà chúng ta nhìn thấy là các công ty lớn đưa ra các chương trình trả thưởng cho bug cực kì hấp dẫn, có khi lên tới 250k USD như đối với HyperV của Microsoft, đặc biệt là sự xuất hiện của HackerOne, như là thiên đường của hacker mũ trắng gần như thay đổi hoàn toàn cuộc chơi của dân săn bug chuyên nghiệp. Việc đó sẽ dẫn tới sự thay đổi trong cách tiếp cận đối với các công ty, thay vì xử lí từng bug riêng lẻ thì họ tập trung nhân lực vào làm những việc sau:
1. Xử lí toàn bộ bug class: ví dụ để xử lí SQL Injection thông qua Framework bắt buộc lập trình viên phải gọi hàm nhận dữ liệu vào của Framework thay vì gọi trực tiếp và phải kiếm đủ mọi cách lọc.
2. Giảm các hướng tấn công
Thông qua Giảm thiểu quyền lực ( least privilege ) , Tách rời quyền lực ( privilege separation )
Ví dụ:
* Như Microsoft đưa Font Parsing từ Kernel ra User mode để giảm nguy hại của việc chạy Parse font ở kernel, rất nhiều bug được tìm thấy ở tính năng này dẫn tới Kernel bị thao túng.
* Thời gian đầu của trình duyệt , chỉ cần hack được tiến trình Parse HTML của trình duyệt là Hacker nắm toàn quyền điều khiển máy của nạn nhân, sau này các công ty trình duyệt đều tách ra làm nhiều tiến trình để thực thi các tác vụ khác nhau, những việc như nhận và parse HTML,CSS, Javascript sẽ do một process với ít quyền hơn thực hiện, còn những thao tác trên network, disk sẽ do process với nhiều quyền lực hơn.
* Chrome thậm chí còn chặn luôn mọi sự tương tác giữa trình duyệt của họ và Win32K kernel module của Windows vì đó là con đường bị khai thác vô số lần bởi Hackers.
3. Loại bỏ các điểm yếu: Nếu các bạn chơi CTF từ những ngày đầu, hoặc bắt đầu chập chững làm những bài exploit đơn giản sẽ thấy cần phải tắt DEP, ASLR, Stack Canary… Đó chính là những thứ giải pháp chung chung để tăng giá cần bỏ ra bởi Hacker để có thể compromise được mục tiêu, những ngày đầu với một lỗi Buffer Overflow đơn giản, Hacker cần trỏ EIP về địa chỉ vùng nhớ có chứa đoạn mã máy tính của anh ta và làm được mọi việc anh ta muốn trên máy nạn nhân. Còn ngay lúc này, 2020, một lỗi Buffer Overflow là hoàn toàn vô dụng với sự bảo vệ của Stack Canary, mà thậm chí là nếu Hacker có thể điều khiển được EIP cũng không có nghĩa kết thúc, với việc Apple đưa PAC vào IPhone năm ngoái, Hacker gần như không thể đổi được dòng thực thi của chương trình đi đâu cả, cái giá để “Full Compromise” một chiếc Iphone là rất rất cao, khoảng 2 triệu đô ngoài public còn ước tính trên chợ đen phải gấp vài lần như vậy, nhưng dĩ nhiên là vẫn có một số người làm được việc đó, việc này cho thấy phần nào đó bị khai thác là gần như không thể tránh khỏi khi làm phần mềm, vậy vấn đề là làm sao tăng cái giá của việc khai thác lên cao nhất có thể thay vì cố gắng tìm và vá sạch toàn bộ bug.
Mặt khác cũng phải thấy rằng họ đầu tư rất nhiều vào đội ngũ kĩ sư An Ninh:
1. Thông qua việc sử dụng một nguồn nhân lực lớn tập trung vào việc xây dựng các hệ thống Fuzzer năng suất cao, Ở Google họ có LibFuzzer, CloudFuzzer và nếu chịu khó theo dõi bug tracking của Chrome sẽ thấy nó hiệu quả như thế nào, cũng như trong Microsoft có nhắc đến việc họ Fuzz DHCP với 200k Iters/sec và tìm ra 2 lỗ hổng cực kì nguy hiểm mới vá gần đây như chúng ta đều biết. Còn đối với Linux kernel, nếu nghe qua syzkaller thì cũng biết nhờ công cụ này mà vài trăm bug đã được vá, thậm chí có những bug chỉ vì chậm cập nhật trên Android mà bị Hacker khai thác hàng tháng trời ngoài xã hội.
2. Song song với Fuzzing, việc Github mua lại Semmle vốn là một công cụ để tìm ra bug thông qua việc phân tích source code, khi đó các kĩ sư an ninh chỉ cần viết ra những đoạn code để tìm ra bug ( thay vì phải dò bằng tay như trước đây ), dùng những đoạn code này để dò tự động trên nhiều sản phẩm khác nhau, để tránh lập trình viên mắc lỗi cũ liên tục, để giảm thiểu quá trình kiểm thử bằng tay của các kĩ sư an ninh ( tìm bug ), và công cụ này được đón nhận, sử dụng rộng rãi không chỉ ở Google, Microsoft,Apple mà còn ở các tập đoàn thuộc lĩnh vực khác như Nasa, Nasdaq…..
Các bạn có thể bảo là trên đây toàn bộ đều liên quan tới Binary Software là chính, còn Web Software thì sao? Dưới góc độ của một người săn lỗi nhìn từ bên ngoài Shopee gần như rất hiếm khi mắc những lỗ hổng Security cơ bản như SQL Injection hay XSS…. , với xuất thân từ dân Bug Bounty Hunter chuyên nghiệp ở mảng Binary là chính, team mình dần chuyển sang làm việc trên những sản phẩm thiên về Web Application hơn, tuy nhiên mindset về an ninh sản phẩm vẫn là rút ra từ những kinh nghiệm có sẵn qua qúa trình làm việc với các công ty lớn trên nhiều năm trời, từ đó rút ra những bài học về cách tiếp cận phía trên là hoàn toàn hiệu quả cho một công ty thiên về E-Commerce.
Hết phần 1.
