Remote Code Execution (RCE) vẫn luôn là chủ đề nóng của các anh em trong ngành bảo mật. Từ trải nghiệm cá nhân, mình cũng muốn “góp vui” chia sẻ 1 chút để những ai đang bắt đầu tìm hiểu về RCE sẽ có được cái nhìn đúng đắn. Trong bài viết này, mình sẽ nói về:

• Khái niệm, cơ chế
• Kỹ thuật khai thác Remote Code Execution
• Chiến lược phòng thủ

Mời anh em cùng đi vào tìm hiểu!

Remote Code Execution (RCE)?

Remote Code Execution (RCE) là lỗ hổng bảo mật cho phép kẻ tấn công thực thi mã độc từ xa trên máy chủ hoặc ứng dụng. Nói dễ hiểu là, nếu hệ thống của anh em có lỗ hổng, attacker có thể đi lại, thực hiện hành động trong hệ thống mà không cần phải có mặt trực tiếp – như cài đặt phần mềm độc hại, khai thác dữ liệu nhạy cảm hay chiếm quyền điều khiển toàn bộ hệ thống.

RCE là nguyên nhân của nhiều vụ tấn công toàn cầu như WannaCry, NotPetya và các cuộc tấn công liên quan đến Log4Shell.

Có thể bạn quan tâm: Leo thang đặc quyền Linux

Lỗ hổng remote code execution hoạt động như thế nào?

Quy trình tấn công remote code execution

Anh em hãy hình dung như sau: attacker bắt đầu với reconnaissance (khảo sát toàn bộ bề mặt tấn công) để tìm ra các điểm yếu như API không được bảo vệ, các trường input không kiểm tra kỹ càng, hay các dịch vụ xử lý dữ liệu không an toàn. Quá trình này thường bao gồm:

• Input Validation Failure: Ứng dụng không “làm sạch” dữ liệu đầu vào (lack of input validation) cho phép attacker chèn các lệnh độc hại.
• Deserialization Vulnerability: Khi một ứng dụng deserialize dữ liệu mà không xác thực, attacker có thể gửi payload được cấu trúc độc hại, ví dụ như sử dụng công cụ Ysoserial để tạo payload cho Java hoặc PHP.
• Buffer Overflow & Memory Corruption: Ở các ứng dụng viết bằng C/C++, nếu không kiểm soát đúng cách kích thước buffer, attacker có thể ghi đè vùng nhớ (buffer overflow) và sau đó sử dụng kỹ thuật Return Oriented Programming (ROP) để vượt qua các biện pháp bảo vệ như DEP (Data Execution Prevention) và ASLR (Address Space Layout Randomization).

Các hình thức RCE phổ biến hiện nay

• Client-side RCE: Tấn công thông qua ứng dụng phía client, thường gặp trong các trình duyệt hoặc ứng dụng desktop, nơi lỗi xảy ra khi người dùng tương tác.
• Server-side RCE: Phổ biến nhất trong các ứng dụng web, khi lỗi nằm ở phía máy chủ xử lý request từ người dùng.
• Dependency Exploitation: Ví dụ như lỗ hổng Log4Shell trong thư viện Log4j, khi một thư viện bên thứ ba bị khai thác, hậu quả có thể lan rộng đến hàng nghìn hệ thống.

Bài viết liên quan: SQL Injection testing

4 phương thức khai thác RCE phổ biến nhất hiện nay

Các phương pháp khai thác Remote Code Execution phổ biến hiện nay có thể kể đến như:

Mình từng sử dụng Metasploit để khai thác một lỗ hổng RCE trên môi trường lab. Payload reverse shell được tạo ra chỉ trong vài giây, cho thấy sự “điều khiển từ xa” thực sự có thể xảy ra nếu không có các biện pháp bảo vệ phù hợp.

Kỹ thuật thực tế và công cụ để tấn công RCE

Tạo payload độc hại:

• Payload tùy chỉnh: Tùy vào mục tiêu (Linux hay Windows), payload có thể được cấu hình để mở reverse shell, tăng quyền truy cập hoặc cài đặt malware.
• Công cụ:
  • Metasploit: Framework hỗ trợ khai thác RCE từ nhiều lỗ hổng khác nhau.
  • Burp Suite: Dùng để kiểm tra và chặn dữ liệu, phát hiện các lỗi injection trong các ứng dụng web.
  • SQLMap: Khi SQL injection dẫn đến RCE, công cụ này có thể tự động hóa việc khai thác.
  • Ysoserial: Đặc biệt hữu ích cho việc tạo payload trong các cuộc tấn công deserialization.

Bypass các biện pháp phòng thủ:

• Bypass WAF và Security Filters: Sử dụng kỹ thuật obfuscation và mã hóa payload để “xuyên” qua các hệ thống bảo vệ như WAF.
• Tinh chỉnh payload:Qua nhiều vòng thử nghiệm, attacker có thể điều chỉnh payload sao cho giảm thiểu khả năng bị phát hiện bởi các hệ thống giám sát.

Chiến lược phòng thủ để giảm thiểu rủi ro bị RCE

Các cụ thường có câu “Phòng thủ tốt hơn chữa bệnh”, việc phòng ngừa và vá lỗ hổng kịp thời chắc chắn rất quan trọng. Chúng ta không thể chờ đến khi hacker thâm nhập vào hệ thống mới xử lý thì có thể đã có thiệt hại xảy ra rồi.

Kiểm tra đầu vào thật chặt chẽ

• Input Validation:Sử dụng whitelist để chỉ cho phép dữ liệu hợp lệ, đồng thời lọc bỏ các ký tự đặc biệt có khả năng được lợi dụng cho injection.
• Security Libraries:Áp dụng các thư viện đã được chứng thực cho quá trình serialize và deserialize, giảm thiểu nguy cơ bị khai thác.

Bảo vệ bộ nhớ và ứng dụng

• Áp dụng DEP, ASLR:Những biện pháp này giúp bảo vệ bộ nhớ, làm giảm nguy cơ buffer overflow và memory corruption.
• Static & Dynamic Analysis:Sử dụng công cụ phân tích tĩnh (static code analysis) và phân tích động (dynamic analysis) để phát hiện sớm các lỗi bảo mật trong code.

Quản lý cập nhật và vá lỗi

• Patch Management:Đảm bảo hệ thống, ứng dụng và các thư viện được cập nhật phiên bản mới nhất để vá các lỗ hổng đã được phát hiện.
• Regular Pen Testing:Thực hiện kiểm thử bảo mật định kỳ giúp phát hiện các lỗ hổng mới và đánh giá hiệu quả của các biện pháp phòng thủ.

Giám sát và phản ứng nhanh

• Tích hợp SIEM & SOAR:Thiết lập hệ thống giám sát log liên tục và tự động phản ứng khi phát hiện các chỉ số bất thường liên quan đến RCE.
• Behavioral Analytics:Phân tích hành vi người dùng và lưu lượng mạng để nhận diện sớm các mẫu tấn công bất thường.

Không có giải pháp nào tuyệt đối, chỉ có sự chủ động và linh hoạt mới giúp chúng ta chống lại kẻ xâm nhập. Hãy luôn cập nhật kiến thức, kiểm tra bảo mật và chuẩn bị sẵn sàng các biện pháp phản ứng khi hệ thống có dấu hiệu bất thường.

Những case study Remote Code Execution kinh điển

Log4Shell

Bối cảnh

• Lỗ hổng: Vào cuối năm 2021, lỗ hổng trong thư viện Log4j – thường được gọi là Log4Shell – đã bùng nổ trong cộng đồng bảo mật. Đây là lỗi trong cách thư viện này xử lý việc log dữ liệu, cho phép kẻ tấn công chèn mã độc vào các bản log hợp pháp.
• Phạm vi ảnh hưởng: Do Log4j được sử dụng rộng rãi trong hàng ngàn ứng dụng và hệ thống, lỗ hổng này đã mở ra cánh cửa cho attacker thực thi mã từ xa trên hàng nghìn hệ thống. Hậu quả của vụ tấn công là một làn sóng cảnh báo toàn cầu, buộc các tổ chức phải khẩn trương vá lỗi và kiểm tra lại phụ thuộc bên thứ ba.

Hậu quả

• Tác động: Vụ Log4Shell đã khiến các tổ chức, từ các doanh nghiệp nhỏ đến các cơ quan chính phủ, phải chịu sự gián đoạn đáng kể. Nhiều hệ thống bị tấn công và dữ liệu nhạy cảm bị đánh cắp, gây tổn thất về tài chính và uy tín.
• Áp lực vá lỗi: Vì tính phổ biến của Log4j, các bản vá lỗi phải được triển khai nhanh chóng trên toàn cầu, và quá trình vá lỗi trở nên cực kỳ phức tạp khi phải kiểm tra tính tương thích của các ứng dụng sử dụng thư viện này.

Bài học rút ra

• Quản lý phụ thuộc: Vụ Log4Shell nhấn mạnh tầm quan trọng của việc kiểm soát và quản lý các phụ thuộc bên thứ ba. Trong quá trình làm việc, mình luôn khuyên rằng hãy duy trì danh mục phụ thuộc được cập nhật và đánh giá rủi ro định kỳ.
• Theo dõi threat intelligence: Cập nhật thông tin từ các nguồn threat intelligence là bước không thể thiếu để nhận diện sớm các lỗ hổng mới. Log4Shell là một minh chứng sống cho việc thông tin kịp thời có thể cứu sống một hệ thống.

Mình cho rằng nếu một thứ được cài đặt trong hệ thống mà bạn không thể kiểm soát hoàn toàn, đó luôn là một điểm yếu tiềm tàng.” Vụ Log4Shell là minh chứng rằng sự chủ động trong quản lý phụ thuộc và cập nhật bảo mật chính là chìa khóa để giảm thiểu rủi ro.

EternalBlue & WannaCry

Bối cảnh

• Lỗ hổng: EternalBlue là một lỗ hổng nghiêm trọng trong giao thức SMB (Server Message Block) của Windows, được cho là đã bị khai thác bởi nhóm tấn công quốc gia (có liên quan đến NSA). Lỗ hổng này đã được sử dụng trong vụ tấn công WannaCry vào năm 2017 – một đợt tấn công lan truyền cực nhanh trên toàn cầu.
• Phạm vi ảnh hưởng: WannaCry đã tấn công hàng triệu máy tính trên toàn thế giới, gây ra sự gián đoạn nghiêm trọng trong nhiều lĩnh vực, từ y tế đến kinh doanh. Các máy tính bị nhiễm ransomware đã bị khóa và đòi tiền chuộc, khiến hàng nghìn tổ chức gánh chịu tổn thất về tài chính và uy tín.

Hậu quả

• Thiệt hại kinh tế: WannaCry đã gây ra thiệt hại hàng tỷ đô la trên toàn cầu, với hàng triệu máy tính bị ảnh hưởng và gián đoạn hoạt động kinh doanh nghiêm trọng.
• Lan truyền nhanh chóng: Sự lan truyền của WannaCry cho thấy một lỗ hổng trong giao thức SMB có thể nhanh chóng tấn công một cách tự động trên toàn hệ thống mạng, đặc biệt là khi các máy tính không được vá lỗi kịp thời.

Bài học rút ra

• Bảo vệ bộ nhớ và vá lỗi định kỳ: Vụ tấn công EternalBlue nhấn mạnh tầm quan trọng của việc áp dụng các biện pháp bảo vệ bộ nhớ (như DEP, ASLR) và việc vá lỗi định kỳ cho hệ thống. Để bảo vệ hệ thống, mình luôn nhấn mạnh việc cập nhật các bản vá lỗi càng sớm càng tốt.
• Tầm quan trọng của patch management: Một hệ thống không được cập nhật đúng hạn là miếng mồi ngon cho các cuộc tấn công. WannaCry đã chứng minh rằng một lỗ hổng nhỏ có thể dẫn đến hậu quả lớn nếu không có quy trình vá lỗi hiệu quả.

Việc duy trì một quy trình quản lý cập nhật chặt chẽ chính là lớp phòng thủ đầu tiên chống lại các cuộc tấn công tự động và lan rộng.

Kết luận

2 case study Log4Shell và EternalBlue & WannaCry đều minh họa cho mức độ nguy hiểm của lỗ hổng RCE và tầm quan trọng của việc quản lý phụ thuộc cũng như vá lỗi kịp thời. Qua đó, chúng ta càng phải quan tâm tới:

• Quản lý các phụ thuộc bên thứ ba và theo dõi threat intelligence là bước không thể thiếu.
• Việc vá lỗi định kỳ và áp dụng các biện pháp bảo vệ bộ nhớ là cần thiết để ngăn chặn tấn công lan rộng.
• Sự chủ động và liên tục cập nhật kiến thức là chìa khóa để bảo vệ hệ thống trong môi trường an ninh mạng đầy biến động.

Hy vọng những chia sẻ này sẽ giúp anh em có thêm động lực và kiến thức để đối phó với các mối đe dọa RCE. Nếu anh em có thắc mắc hoặc kinh nghiệm nào muốn trao đổi, đừng ngần ngại chia sẻ nhé!

Mời bạn đọc thêm các bài viết trong series về Remote Execution của tôi:

• .NET and visual studio remote code execution vulnerability
• Azure identity SDK remote code execution vulnerability
• Android kernel remote code execution vulnerability
• Apache log4j 1.2 jmsappender remote code execution
• Bash remote code execution vulnerability