🐔 “Ký sự NCSC” là chuyên mục bài viết về thời gian mình thực tập tại Trung tâm Giám sát An toàn Không gian mạng Quốc gia (National Cyber Security Center), thuộc Cục An toàn Thông tin, Bộ Thông tin và Truyền thông. Nghe tên Trung tâm thì khủng thế thôi, còn mình thì… gà, đến để “cục tác lá chanh”, học từ những bài học đơn giản nhất.
Trong chuyên mục này, mình sẽ chia sẻ những nhiệm vụ và bài tập mình đã trải qua, cũng như một vài kỷ niệm vui vẻ hay ho trong thời gian ở Trung tâm.
Năm bảy tuổi, bắt được ve sầu, cứ tưởng có cả mùa hè trong tay. Năm 20 reproduce được cái bug, cứ ngỡ sắp đi P2O**.
dieulink
(Trích từ “Phân tích Bản vá tháng 11 của Microsoft Exchange”, ZeptoTeam, NCSC Blog)
Tôi không được khủng như chị @dieulink, song cái làm được nho nhỏ của tôi vẫn cứ cho tôi cái cảm giác giống chị. “Du hạc” Sing về, tạt qua NCSC cho anh em tí bakkwa* để giới thiệu mùi vị đất nước sư tử biển, lỡ ngồi cười nhiều quá nên anh sếp tưởng tôi bị rảnh, giao cho đi verify bug.
Thực tế làm security không màu mè như trên mạng đâu em! Nó chỉ “sqlmap -u” xong cái URL ra là “xiên” được cái web đúng không? Làm thật khác thế nhiều em ạ.
Anh tôi cười ha hả. Giây phút đó tôi bất giác nhận ra, mình còn “cùi bắp” hơn cả thành phần được cho là đáy của thế giới các hacker – những script kiddies. Có công cụ sẵn rồi mà tôi còn chưa làm sao cho nó chạy được. Exploit bằng tay thì ra lỗ hổng, exploit bằng tool thì… chẳng thấy gì.
※ Vì lí do bảo mật, trong bài viết này, tôi xin không nói cụ thể về target của mình. Tôi vẫn sẽ đưa các ví dụ minh hoạ để bạn đọc có thể hiểu những ý tưởng được trình bày.
Hai kiểu tìm bug
Trước khi vào việc chính, tôi xin giải thích vài thứ để bạn hiểu. Nếu như bạn được giao đi tìm bug vào một ngày đẹp trời, nó sẽ rơi vào một trong hai trường hợp:
- Bạn trực tiếp đi “xiên” người ta. Thường sẽ test theo kiểu black box testing. Bạn sẽ cần được sự cho phép để kiểm thử trên những đối tượng này. Hoặc không… Nhưng tôi không chịu trách nhiệm về những gì xảy ra sau đó nhé.
- Bạn phải xây dựng lại cái bug của họ trên máy bạn (reproduce) và tự “xiên” mình để kiểm chứng. Cái này đòi hỏi bạn phải setup môi trường và cài cắm lâu hơn chút, nhưng đỡ đi những vấn đề pháp lý trách nhiệm rắc rối. Lỡ có hỏng hay tệ hơn là tan tành thì đó là… máy của bạn, chứ không phải ai khác.
Tôi được anh chị giao target luôn từ đầu nên bài tập của tôi rơi vào trường hợp thứ nhất.
Verify bug là làm cái gì?
Vì câu chuyện của những bé intern là chúng tôi “gà” (chưa phải là các chiến thần Threat Hunter hay Security Researcher), nên thứ lỗ hổng chúng tôi đi tìm đã có ít nhiều thông tin về nó.
Ở trường hợp của tôi, tôi được gửi một tài liệu là output của một công cụ scan lỗ hổng. Việc của tôi là đi kiểm tra xem đống bug mà công cụ ấy tìm ra có thật là bug hay không.
Vậy kiểm là kiểm thế nào?
- Thử lại bằng tay payload của công cụ. Đây là bước dễ nhất, mặc dù như tôi được yêu cầu thì làm như thế này là chưa đủ. Nếu như có đúng là bug thật (payload khai thác thành công) thì điều này cũng chỉ mới minh chứng là “có thể nó tồn tại” mà thôi, chứ chưa thuyết phục được ai.
- Test thêm và khai thác sâu hơn. Dạo chơi vòng vòng, recon thêm chút xíu. Gom nhóm những endpoint có cùng lỗ hổng giống nhau test cho tiện. Tiến hành khai thác từ một lỗ hổng để có thêm nhiều thông tin hữu dụng hơn, ví dụ nếu SQL injection thành công thì hãy thử làm cho thông tin của toàn bộ database xuất hiện.
- Làm PoC. Con người thì không thích nhận là mình bị ngớ ngẩn (trích lời bác Yuval Noah Harari, cuốn “21 bài học cho thế kỷ 21“), nên trên cương vị là một pentester, bạn sẽ phải khiến cho họ không cãi chày cãi cối được mới thôi. Bạn cần thu thập và cho thấy bằng chứng về những gì bạn đã khai thác được trên mỗi lỗ hổng. Ví dụ, với XSS, bạn cần tấn công deface thay vì chỉ hiện mỗi cái dialog
alert(1). - Viết báo cáo. Làm security thì báo cáo là “nessessary evil” rồi. Với bài tập này anh chị không yêu cầu tôi phức tạp gì, chỉ cần đưa thông tin endpoint cùng PoC, mấy cái ảnh chụp màn hình là được. Trên thực tế tôi thấy người ta sẽ còn phải giải thích thêm một chút (con bug này là gì, ảnh hưởng ra sao…). Lúc đầu tôi cũng sợ thiếu này thiếu kia nên tôi viết rõ chi tiết, xong lại được bảo tối giản đi.
Như thế nào thì được chấp nhận là một PoC?
Đây là câu hỏi khiến tôi suy nghĩ khá nhiều khi làm cái task này. Tôi nhận ra là nếu như cái payload của bạn khai thác được lỗ hổng, nhưng cái khai thác ấy chưa đủ độ “nguy hiểm” thì hầu như không được tính là PoC. Tôi thấy người người nhà nhà tham gia bug bounty, không ít thì nhiều cũng có người bị từ chối bounty vì PoC “cùi bắp”.
Dưới đây là vài bug mà tôi đã verify cùng với PoC được yêu cầu tương ứng:
- SQL injection: Tuỳ vào việc cơ sở dữ liệu có thể bị tấn công kiểu gì. Ưu tiên dump được toàn bộ thông tin của database.
- XSS: Thực hiện tấn công deface. Chèn cái ảnh ngầu lòi (hoặc vô tri) nào đó vào giao diện.
- Clickjacking: Viết một file html mà mở nó thì ta thực hiện được clickjack.
- Information disclosure: Chụp ảnh màn hình, moi thêm cái này cái kia càng nhiều thông tin càng tốt.
Nghệ thuật dùng công cụ
Nếu như phải nói mình ở đâu trong cái meme này thì có lẽ tôi sẽ là:
Với nhiệm vụ lần này, tôi cần dùng sqlmap để dump được cơ sở dữ liệu của mục tiêu được giao. Tôi chưa dùng cái tool này bao giờ nên cũng khá bỡ ngỡ. Nhận thức được sự yếu kém đó, tôi đọc nát cả cái wiki của sqlmap, cộng thêm việc “bái sư” các chiến thần bảo mật trên YouTube. Mãi tôi vẫn không làm được: Tôi khai thác bằng tay thì chứng minh được là có bug, nhưng chạy sqlmap thì công cụ cứ báo “not injectable”!
Vấn đề nằm ở chỗ đống tutorial, cái nào cũng giống cái nào: Họ chỉ demo các target vô cùng đơn giản và cơ bản (read: DVWA), chỉ cần chạy sqlmap với rất ít tham số là ra. Cứ sqlmap, rồi -u (đưa URL) rồi -p (đưa tham số nghi là inject được) là mọi thứ chạy ầm ầm. Tôi chưa bao giờ thấy mình muốn đập đầu vào tường đến thế.
Trong cái đầu bù tóc rối và suýt khóc toáng (vì bị một người anh cà khịa!), anh sếp tôi lại nhảy vào cứu và giảng bài cho tôi. (Ai đọc blog tôi lâu lâu rồi thì đã quá quen anh là ai.)
1 – sqlmap vỡ lòng
Câu chuyện dùng công cụ cũng khá giống với bài toán sử dụng AI bây giờ: Bạn có đủ trình để khai thác được hết tiềm năng của nó? Tôi đã viết về điều này rồi, nhưng giờ tôi sẽ nói lại: Dùng công cụ mà không dùng được thì “tiên trách kỷ, hậu… vẫn trách kỷ”. Tại mình gà thôi các bạn ơi.
Mấu chốt vấn đề của tôi nằm ở hai chỗ:
- Thứ nhất, tôi đang chỉ nhìn thấy công cụ báo kết quả mà không hiểu nó chạy cái gì để mà sửa đổi yêu cầu cho phù hợp.
- Thứ hai, tôi đang cho nó quá ít thông tin để có thể thực hiện tấn công.
Giải quyết từng thứ một nhé.
Với vấn đề thứ nhất, tôi cần lựa chọn option -v hay —-verbose của sqlmap để thấy được ở mỗi bước nó đang làm cái gì, gửi đi request như thế nào và phản hồi trả về ra sao. Mặc định mức verbose là 1, mức thấp nhất, tức là tôi chả thấy gì ngoài kết quả cuối cùng. Đặt -v 3 là đủ sẽ xem được payload mà nó gửi đi.
Với vấn đề thứ hai, tôi đã có payload khai thác bằng thủ công trong tay, và hoá ra là tôi chưa định hình cho công cụ khai thác theo hướng mà tôi muốn. Dựa trên payload của mình, câu chuyện còn lại của tôi là tìm kiếm các options phù hợp để bảo công cụ làm theo. Câu lệnh cuối của tôi dài gấp ba câu lệnh đầu:
python sqlmap.py -u "<https://example.com/*/something-something>" --skip-urlencode --technique=E
--level 5 --risk 3 --dbms=mysql --tamper=space2comment -v 3 --dump-all*: custom injection marker. Đặt vào nơi mà bạn muốn payload được inject vào.—-skip-urlencode: Thông tin này tôi có từ khai thác thủ công. Các ký tự sẽ bị URL encode bởi trình duyệt, phải bỏ qua cái này để request của tôi không bị “xịt keo”.--technique=E: Con target của tôi khai thác được với kiểu injection error-based.—level+—risk: Mức độ test và payload tương ứng sqlmap gửi đi. Tăng cái này lên thấy bảo cũng nguy hiểm, vì tăng rủi ro bị phát hiện. Nhưng target của tôi có vẻ khá dễ tính…--dbms=mysql: Tôi đấm đá bằng tay thì biết được là MySQL.tamper=space2comment: Thay thế dấu cách bằng comment /**/ để bypass việc ký tự dấu cách bị escape. Cái này cũng là cái có được từ khai thác thủ công.-v: Lựa chọn mức độ verbose tương ứng để xem chi tiết công cụ đang làm gì (3 là đủ để xem payload). Như tôi đã nói ở trên.--dump-all: Dump toàn bộ thông tin của database. Con này của tôi có database siêu to khổng lồ, tôi dump xong mất một buổi chiều.
2 – Kết hợp giữa các công cụ
Tôi nhìn đống output trên terminal mà chẳng thấy mình nguy hiểm hay ngầu lòi như mấy tên hacker trên phim. Ừ thì chữ cũng xanh đỏ tím vàng đấy, cũng chạy roèn roẹt luôn đấy, nhưng ta nói nó nhức cái mắt cái đầu các bạn ơi. Người ngoại đạo chắc sẽ thấy ghê gớm, còn tôi, ngồi trong phòng toàn cao thủ, tôi thấy mình quê độ.
Anh tôi chỉ cho việc đưa request của sqlmap qua proxy của Burp Suite với option:
proxy=http://127.0.0.1:8080
Vì trên mặc định, khi mở Burp Proxy và vào mục cài đặt, bạn sẽ thấy nó luôn “lắng nghe” (listening) ở địa chỉ này. 127.0.0.1 là IP trỏ tới localhost, tức chính cái máy của bạn. Port 8080 là port mặc định cho web server. Thêm nốt option này vào câu lệnh phía trên tới sqlmap, và bạn đã bước đầu kết hợp được hai công cụ này.
Sau vụ verify bug này tôi hiểu được thế nào nghĩa là ngầu thực sự.
Tôi càng ngày càng có cảm giác chuyên mục bài viết security này là việc chứng minh bản thân mình “cùi bắp” đến thế nào giữa cộng đồng bảo mật (!). Chỉ còn mỗi bản tính mặt dày cùng với một ảo tưởng rằng có ai đó sẽ cảm thấy bài của tôi hữu ích là điều khiến cho tôi dám viết tiếp… Mong là ngày nào đó tôi nhìn lại và sẽ thấy mình đã đi xa, chứ không phải dậm chân tại chỗ 🫢
Giải thích từ ngữ
Bài này tôi viết cũng kha khá từ chuyên môn, ai làm bảo mật thì chắc cũng biết hết rồi. Tôi giải thích ra đây cho các bạn nào chưa hiểu:
- Endpoint: Điểm cuối của một kết nối mạng, nơi mà dữ liệu được gửi đến hoặc nhận từ. Trong ngữ cảnh của mạng máy tính thì là các máy nút, còn trong ngữ cảnh bảo mật web thì có thể hiểu là mấy cái URL.
- Script kiddies: Những người sử dụng các công cụ và scripts có sẵn để tấn công mà không hiểu rõ cách chúng hoạt động.
- Recon: Viết tắt của reconnaissance, nghĩa là quá trình thu thập thông tin về mục tiêu trước khi tiến hành một cuộc tấn công.
- Payload: Phần dữ liệu được gửi đi để khai thác lỗ hổng bảo mật.
- Deface: Tấn công làm thay đổi giao diện hoặc nội dung của một trang web.
- Reproduce: Tái tạo lại một lỗi hoặc lỗ hổng để kiểm chứng và nghiên cứu.
- Dump: Trích xuất toàn bộ nội dung của một cơ sở dữ liệu để phân tích và khai thác.
- DVWA: Viết tắt của Damn Vulnerable Web Application, là một ứng dụng web được thiết kế để kiểm thử các lỗ hổng bảo mật và nâng cao kỹ năng pentesting.
- PoC: Proof of Concept, nghĩa là bằng chứng khái niệm. Một PoC hiệu quả sẽ cung cấp đủ bằng chứng để người khác có thể thấy rõ ràng là lỗ hổng tồn tại và có thể bị khai thác.
Happy verifying! Giờ thì tôi đi xem Olympics Paris đây các bạn ạ.
*Nhục can (肉乾, Bakkwa, ròu gān), nghĩa đen là “thịt khô” là một món thịt sấy khô ở dạng lát mỏng có vị ngọt và mặn trong ẩm thực Trung Quốc, gần giống như món khô bò. Nó được sử dụng trong các tiệc cưới cổ truyền Trung Hoa hay các bữa yến tiệc mang yếu tố nghi lễ tôn giáo. Trong các thời điểm khác nó cũng được dùng như món ăn vặt hay món ăn kèm trong bữa chính. Nhục can thường được đóng gói hay chứa trong các bọc màu đỏ – màu mang ý nghĩa tốt lành trong văn hóa Á Đông.
Đi Singapore mua món này làm quà là chuẩn bài các bạn nhé – tôi mua của nhà Bee Chang Hiang nổi tiếng.
**P2O, viết tắt của Pwn2Own, là một cuộc thi nổi tiếng nơi các hacker khai thác lỗ hổng bảo mật để chiếm quyền điều khiển các thiết bị hoặc phần mềm và nhận giải thưởng. Cuộc thi này được tổ chức hàng năm tại nhiều địa điểm khác nhau trên thế giới, thường là trong khuôn khổ các hội nghị bảo mật lớn như CanSecWest ở Vancouver, Canada, hoặc PacSec ở Tokyo, Nhật Bản.