Tấn công Return-to-libc và Tràn bộ đệm (Buffer Overflow)
Một cuộc tấn công “return-to-libc” (hoặc ret2libc) thường bắt đầu bằng lỗi tràn bộ đệm (buffer overflow). Trong loại tấn công này, địa chỉ trả về của một hàm con trên stack sẽ bị thay thế bằng địa chỉ của một hàm đã có sẵn trong bộ nhớ thực thi của tiến trình. Kỹ thuật này thường nhằm mục đích vượt qua tính năng no-execute (NX) và cho phép kẻ tấn công thực thi mã độc.
Các hệ điều hành hỗ trợ tính năng stack không thực thi (non-executable stack) giúp bảo vệ khỏi việc thực thi mã sau khi khai thác lỗ hổng tràn bộ đệm. Tuy nhiên, tính năng này không ngăn được các cuộc tấn công ret2libc vì kiểu tấn công này chỉ sử dụng mã thực thi đã có sẵn trong hệ thống. Một kỹ thuật khác gọi là bảo vệ stack (stack-smashing protection) có thể giúp phát hiện sự hỏng hóc của stack, từ đó ngăn chặn hoặc làm khó quá trình khai thác mã độc.
Kỹ thuật ASCII Armoring để giảm thiểu tấn công ret2libc
Một kỹ thuật gọi là ASCII armoring có thể được sử dụng để giảm thiểu các cuộc tấn công ret2libc. Khi áp dụng kỹ thuật này, địa chỉ của các thư viện hệ thống (như libc) sẽ chứa một byte NULL (0x00) được chèn vào trong vùng đầu tiên của bộ nhớ (0x01010101 byte).
Đây thường là vài trang bộ nhớ, lớn hơn 16MB một chút và được gọi là vùng “giáp ASCII” (ASCII armor region) vì mọi địa chỉ trong vùng này đều chứa ít nhất một byte NULL. Khi triển khai kỹ thuật này, kẻ tấn công không thể sử dụng các hàm thao tác chuỗi như strcpy() để chèn các địa chỉ đó vào bộ nhớ, vì NULL byte sẽ cắt ngắn chuỗi.
Tuy nhiên, kỹ thuật này không bảo vệ hệ thống nếu kẻ tấn công có thể tràn NULL byte vào stack. Một cách tiếp cận hiệu quả hơn là ASLR – random hóa không gian địa chỉ (Address Space Layout Randomization), đặc biệt trên hệ thống 64-bit. Khi sử dụng ASLR, vị trí trong bộ nhớ của các hàm sẽ bị ngẫu nhiên hóa, khiến việc đoán địa chỉ trở nên khó khăn.
Tuy nhiên, trên hệ thống 32-bit, ASLR kém hiệu quả hơn vì chỉ có 16 bit để ngẫu nhiên hóa – kẻ tấn công có thể vượt qua bằng tấn công brute-force.
OWASP Top 10
OWASP (Open Web Application Security Project) là một tổ chức phi lợi nhuận dẫn đầu nhiều sáng kiến nhằm thúc đẩy an toàn cho ứng dụng và phần mềm. Họ công bố danh sách 10 lỗ hổng phổ biến nhất thường gặp trong ứng dụng tại:
🔗 https://owasp.org/www-project-top-ten/
Lỗ hổng bảo mật trong phần mềm mã nguồn mở
Việc cập nhật bản vá lỗ hổng bảo mật cho phần mềm thương mại và mã nguồn mở là quy trình thiết yếu với bất kỳ tổ chức nào. Các tổ chức thường sử dụng các công cụ sau để quản lý lỗ hổng hiệu quả:
🔍 Phần mềm quản lý và quét lỗ hổng:
- Qualys
- Nexpose
- Nessus
🔍 Công cụ phân tích thành phần phần mềm (Software Composition Analysis):
- BlackDuck Hub
- Synopsys Protecode (tên cũ: AppCheck)
- FlexNet Code Insight (tên cũ: Palamida)
- SourceClear
- WhiteSource
📰 Nguồn dữ liệu lỗ hổng bảo mật:
- Danh sách CVE của MITRE
- Cơ sở dữ liệu lỗ hổng quốc gia của NIST (NVD)
- VulnDB
- Recorded Future