Lỗ hổng (an toàn máy tính)

Lỗ hổng () là những sai sót hoặc điểm yếu trong thiết kế, triển khai hoặc quản lý của một hệ thống, có thể bị tác nhân độc hại khai thác để xâm phạm tính bảo mật của hệ thống.

Dù quản trị viên hệ thống có nỗ lực đến đâu nhằm đạt được sự chính xác tuyệt đối, hầu như mọi phần cứng và phần mềm đều chứa lỗi khiến hệ thống không hoạt động như mong đợi. Nếu lỗi đó có thể cho phép kẻ tấn công làm ảnh hưởng đến tính bảo mật, tính toàn vẹn hoặc tính khả dụng của tài nguyên hệ thống, thì lỗi đó được xem là một lỗ hổng. Những thói quen phát triển phần mềm không an toàn cũng như các yếu tố thiết kế như độ phức tạp có thể làm gia tăng số lượng và mức độ nghiêm trọng của các lỗ hổng.

Quản lý lỗ hổng là một quy trình bao gồm việc xác định các hệ thống, ưu tiên những hệ thống quan trọng nhất, quét để phát hiện lỗ hổng và thực hiện các biện pháp nhằm bảo vệ hệ thống. Quản lý lỗ hổng thường bao gồm kết hợp các hành động như khắc phục, giảm thiểu rủi ro và chấp nhận rủi ro.

Mức độ nghiêm trọng của các lỗ hổng có thể được chấm điểm theo Hệ thống Chấm điểm Lỗ hổng Chung (CVSS) và được đưa vào các cơ sở dữ liệu lỗ hổng, chẳng hạn như cơ sở dữ liệu Common Vulnerabilities and Exposures (CVE). Tính đến tháng 11 năm 2024, đã có hơn 240.000 lỗ hổng được ghi nhận trong cơ sở dữ liệu CVE.

Lỗ hổng xuất hiện ngay từ khi được đưa vào phần mềm hoặc phần cứng. Nó trở nên có thể khai thác khi hệ thống chứa lỗ hổng đó đang hoạt động. Việc phát hiện lỗ hổng có thể đến từ quản trị viên, nhà cung cấp hoặc một bên thứ ba. Khi lỗ hổng được công khai (dù thông qua bản vá hay cách khác), nguy cơ bị tấn công thường tăng lên vì kẻ xấu có thể lợi dụng thông tin này để nhắm vào các hệ thống chưa được cập nhật. Một lỗ hổng sẽ chấm dứt khi hệ thống được vá hoặc bị ngừng sử dụng.

== Nguyên nhân ==
Dù quản trị viên hệ thống có nỗ lực đến đâu, hầu như mọi phần cứng và phần mềm đều tồn tại lỗi. Nếu lỗi đó gây ra rủi ro bảo mật, nó sẽ được gọi là lỗ hổng. Các bản vá phần mềm thường được phát hành để khắc phục các lỗ hổng đã được phát hiện, nhưng các lỗ hổng zero-day vẫn có nguy cơ bị khai thác. Mức độ lỗ hổng có thể bị khai thác bởi các tác nhân độc hại là khác nhau, và rủi ro thực tế phụ thuộc vào bản chất của lỗ hổng cũng như giá trị của hệ thống liên quan. Mặc dù một số lỗ hổng chỉ có thể được khai thác để thực hiện các cuộc tấn công từ chối dịch vụ, nhưng những lỗ hổng nguy hiểm hơn cho phép kẻ tấn công thực hiện chèn mã độc mà người dùng không hề hay biết. Chỉ một số ít lỗ hổng cho phép leo thang đặc quyền, thường là điều kiện cần cho các cuộc tấn công nghiêm trọng hơn. Nếu không có lỗ hổng, một mã khai thác thường sẽ không thể xâm nhập vào hệ thống. Phần mềm độc hại cũng có thể được cài đặt trực tiếp mà không cần đến mã khai thác, thông qua kỹ thuật xã hội hoặc do an ninh vật lý kém, chẳng hạn như để cửa phòng máy chủ không khóa.

=== Yếu tố thiết kế ===
Lỗ hổng có thể trở nên nghiêm trọng hơn do các yếu tố thiết kế kém, chẳng hạn như:

- Độ phức tạp: Các hệ thống lớn và phức tạp làm tăng khả năng tồn tại các lỗi và điểm truy cập không mong muốn.
- Tính phổ biến: Việc sử dụng mã nguồn, phần mềm, hệ điều hành hoặc phần cứng phổ biến và quen thuộc làm tăng khả năng kẻ tấn công đã có hoặc có thể dễ dàng tìm ra kiến thức và công cụ để khai thác lỗ hổng. Tuy nhiên, việc sử dụng phần mềm phổ biến, đặc biệt là phần mềm miễn phí và mã nguồn mở, cũng đem lại lợi thế là thường nhận được các bản vá bảo mật nhanh chóng và đáng tin cậy hơn.
- Khả năng kết nối: Bất kỳ hệ thống nào kết nối với Internet đều có thể bị truy cập và xâm nhập. Ngắt kết nối khỏi Internet có thể là một biện pháp cực kỳ hiệu quả để ngăn chặn tấn công, nhưng không phải lúc nào cũng khả thi.
- Phần mềm và phần cứng lỗi thời: Các hệ thống cũ có nguy cơ bị tấn công cao hơn do đặc điểm của chúng. Quản trị viên nên cân nhắc nâng cấp các hệ thống này, dù điều đó có thể khó khăn do chi phí cao và yêu cầu ngừng hoạt động trong quá trình chuyển đổi.

=== Yếu tố phát triển ===
Một số thói quen trong quá trình phát triển phần mềm có thể làm tăng nguy cơ xuất hiện lỗ hổng trong mã nguồn. Thiếu kiến thức về lập trình an toàn hoặc bị áp lực phải ra mắt tính năng nhanh có thể khiến những lỗ hổng đáng lẽ có thể tránh được lại xuất hiện trong phiên bản chính thức – đặc biệt khi bảo mật không phải là ưu tiên trong văn hóa công ty. Điều này dễ dẫn đến các lỗ hổng ngoài ý muốn. Hệ thống càng phức tạp thì lỗ hổng càng dễ bị bỏ sót. Một số lỗ hổng không phải do vô tình, mà được cài cắm có chủ đích – có thể xuất phát từ nhiều lý do, chẳng hạn như việc nhân viên bất mãn bán quyền truy cập cho tội phạm mạng, hoặc các chiến dịch tinh vi do nhà nước hậu thuẫn nhằm cài lỗ hổng vào phần mềm.

Các thực tiễn phát triển phần mềm không đảm bảo có thể làm gia tăng khả năng xuất hiện lỗ hổng trong mã nguồn. Việc thiếu kiến thức chuyên môn hoặc đào tạo bài bản về phát triển phần mềm an toàn, áp lực thời gian trong quá trình triển khai, hoặc sự phức tạp quá mức của hệ thống đều có thể tạo điều kiện cho các lỗ hổng bảo mật phát sinh và bị bỏ sót. Những yếu tố này càng trở nên trầm trọng hơn khi bảo mật không được xem là ưu tiên trong văn hóa tổ chức. Bên cạnh đó, quy trình đánh giá mã nguồn không đầy đủ cũng có thể dẫn đến việc bỏ qua các lỗi nghiêm trọng; tuy nhiên, việc ứng dụng các công cụ phân tích mã tĩnh trong quá trình đánh giá mã có thể hỗ trợ phát hiện một số lỗ hổng tiềm ẩn.

DevOps, một quy trình phát triển nhấn mạnh việc tự động hóa kiểm thử và triển khai nhằm tăng tốc độ ra mắt tính năng mới – thường đòi hỏi nhiều lập trình viên được cấp quyền thay đổi cấu hình hệ thống. Điều này có thể dẫn đến việc các lỗ hổng bị đưa vào hệ thống, dù là vô tình hay cố ý. Việc tách biệt các thành phần phụ thuộc, thường là một phần trong quy trình DevOps, giúp thu hẹp "bề mặt tấn công" bằng cách chỉ giữ lại những gì thật sự cần thiết. Nếu sử dụng phần mềm dạng dịch vụ thay vì hạ tầng phần cứng và phần mềm riêng của tổ chức, thì tổ chức sẽ phụ thuộc vào nhà cung cấp dịch vụ đám mây trong việc ngăn chặn các lỗ hổng bảo mật.

== Lỗ hổng theo thành phần ==
=== Phần cứng ===
Các lỗi bảo mật có chủ đích có thể được cài cắm trong hoặc sau quá trình sản xuất, khiến vi mạch tích hợp không hoạt động đúng như mong đợi trong một số điều kiện cụ thể. Việc kiểm tra lỗi bảo mật trên phần cứng là một thách thức lớn do thời gian hạn chế và độ phức tạp của các chip hiện đại trong thế kỷ 21. Bên cạnh đó, quá trình toàn cầu hóa trong thiết kế và sản xuất cũng làm gia tăng nguy cơ các lỗi này bị cố ý đưa vào bởi các tác nhân độc hại.

=== Hệ điều hành ===
Mặc dù các lỗ hổng của hệ điều hành có thể khác nhau tùy theo hệ điều hành được sử dụng, một vấn đề phổ biến là các lỗi leo thang đặc quyền, cho phép kẻ tấn công chiếm quyền truy cập cao hơn mức được phép. Các (họ) hệ điều hành mã nguồn mở như Linux và Android có mã nguồn công khai và cho phép bất kỳ ai đóng góp, điều này có thể tạo điều kiện cho việc cài cắm lỗ hổng. Tuy nhiên, những lỗ hổng tương tự cũng tồn tại ở các hệ điều hành mã nguồn đóng như Microsoft Windows và hệ điều hành Apple. Tất cả các nhà cung cấp hệ điều hành uy tín đều phát hành các bản vá bảo mật định kỳ.

=== Ứng dụng khách–chủ ===
Ứng dụng khách – chủ được cài đặt trực tiếp trên máy tính của người dùng cuối và thường được cập nhật ít thường xuyên hơn so với các ứng dụng web. Khác với ứng dụng web, chúng tương tác trực tiếp với hệ điều hành của người dùng. Một số lỗ hổng phổ biến trong các ứng dụng này bao gồm:
- Dữ liệu không được mã hóa, dù được lưu trữ lâu dài hay truyền qua mạng, đều tương đối dễ bị kẻ tấn công đánh cắp.
- Chiếm quyền tiến trình (process hijacking) xảy ra khi kẻ tấn công kiểm soát một tiến trình đang chạy trên máy tính.

=== Ứng dụng web ===
Ứng dụng web được sử dụng rộng rãi trên nhiều trang web. Do bản chất kém an toàn hơn so với các loại ứng dụng khác, chúng là một trong những nguyên nhân hàng đầu gây ra rò rỉ dữ liệu và các sự cố bảo mật khác. Chúng có thể bao gồm các lỗ hổng như:
- Lỗi xác thực và phân quyền cho phép kẻ tấn công truy cập vào dữ liệu lẽ ra chỉ dành cho người dùng đáng tin cậy.
- Lỗ hổng logic nghiệp vụ: xảy ra khi lập trình viên không lường trước được các trường hợp bất ngờ phát sinh trong logic xử lý nghiệp vụ.

Các hình thức tấn công thường được sử dụng để khai thác lỗ hổng trong ứng dụng web bao gồm:
- Cross-site scripting (XSS): cho phép kẻ tấn công chèn và thực thi mã độc JavaScript khi đầu vào không được kiểm soát chặt chẽ. Có hai dạng chính là XSS lưu trữ (mã độc được lưu lại và kích hoạt khi người dùng truy cập) và XSS phản chiếu (mã độc được chèn thông qua liên kết và thực thi ngay). Ngoài ra, còn có XSS thông qua thao tác với DOM.
- SQL injection và các biến thể tương tự: cho phép kẻ tấn công thao túng truy vấn cơ sở dữ liệu để truy cập, sửa đổi hoặc đánh cắp thông tin.
- Command injection: xảy ra khi kẻ tấn công chèn mã độc vào dữ liệu đầu vào hoặc quá trình xử lý, từ đó có thể chiếm quyền điều khiển máy chủ nếu thành công.
- Cross-site request forgery (CSRF): đánh lừa trình duyệt người dùng để gửi các yêu cầu trái phép đến máy chủ, chẳng hạn như thay đổi mật khẩu hoặc thông tin tài khoản.
- Server-side request forgery (SSRF): tương tự như CSRF nhưng yêu cầu được gửi từ phía máy chủ, thường nhằm truy cập vào các hệ thống nội bộ mà người dùng bên ngoài không thể chạm tới.
- Lỗi logic nghiệp vụ: xảy ra khi lập trình viên không lường trước các tình huống bất thường trong quy trình xử lý nghiệp vụ, dẫn đến hành vi sai lệch mà kẻ tấn công có thể lợi dụng.

== Quản lý ==
Hiện có rất ít bằng chứng về mức độ hiệu quả và hiệu quả chi phí của các biện pháp phòng chống tấn công mạng khác nhau. Mặc dù việc ước lượng rủi ro của một cuộc tấn công không hề đơn giản, nhưng có thể xem xét thời gian trung bình để bị xâm nhập (mean time to breach) và chi phí thiệt hại ước tính để xác định mức độ ưu tiên trong việc khắc phục hoặc giảm thiểu một lỗ hổng đã phát hiện, cũng như đánh giá liệu việc xử lý đó có hiệu quả về mặt chi phí hay không. Mặc dù việc chú trọng đến bảo mật có thể giúp giảm nguy cơ bị tấn công, nhưng không thể đạt được mức an toàn tuyệt đối đối với một hệ thống phức tạp. Nhiều biện pháp bảo mật cũng đi kèm với chi phí cao hoặc làm giảm trải nghiệm sử dụng đến mức không chấp nhận được. Ví dụ, việc giảm độ phức tạp và số lượng chức năng của hệ thống là một cách hiệu quả để thu hẹp bề mặt tấn công.

=== Khắc phục ===
Khắc phục là quá trình sửa chữa các lỗ hổng, chẳng hạn như bằng cách tải và cài đặt bản vá phần mềm. Các công cụ quét lỗ hổng thường không thể phát hiện các lỗ hổng zero-day, nhưng lại hiệu quả hơn trong việc tìm ra các lỗ hổng đã biết dựa trên cơ sở dữ liệu. Những hệ thống này có thể phát hiện một số lỗ hổng đã biết và đề xuất cách khắc phục, chẳng hạn như áp dụng bản vá. Tuy nhiên, các công cụ này cũng có những hạn chế, bao gồm cả việc đưa ra cảnh báo sai (false positives).

Lỗ hổng chỉ có thể bị khai thác khi chúng đang hoạt động, tức là khi phần mềm chứa lỗ hổng đó đang chạy trên hệ thống. Trước khi đoạn mã chứa lỗ hổng được cấu hình để chạy trên hệ thống, nó được xem như một thành phần mang lỗ hổng. Các lỗ hổng tiềm ẩn có khả năng hoạt động, nhưng hiện chưa được kích hoạt. Phần mềm chứa lỗ hổng tiềm ẩn hoặc lỗ hổng dạng "mang" đôi khi có thể được gỡ bỏ hoặc vô hiệu hóa, từ đó loại bỏ rủi ro. Trong khi đó, các lỗ hổng đang hoạt động, nếu được phân biệt rõ với các loại còn lại, có thể được ưu tiên vá trước.

Giảm thiểu lỗ hổng là các biện pháp không khắc phục hoàn toàn lỗ hổng, nhưng làm cho việc khai thác trở nên khó khăn hơn hoặc giảm thiểu hậu quả nếu bị tấn công. Một chiến lược phổ biến là thu hẹp bề mặt tấn công, đặc biệt đối với các phần của hệ thống có quyền truy cập root (hoặc quyền quản trị), và ngăn chặn khả năng khai thác để leo thang đặc quyền. Nếu bản vá cho phần mềm bên thứ ba chưa có sẵn, có khả năng phải tạm thời vô hiệu hóa phần mềm đó để giảm rủi ro.

=== Kiểm thử ===
Kiểm thử xâm nhập (penetration test) là quá trình cố gắng xâm nhập vào hệ thống thông qua các lỗ hổng khai thác nhằm kiểm tra xem hệ thống có điểm yếu bảo mật hay không. Tuy nhiên, nếu một bài kiểm thử xâm nhập thất bại không nhất thiết có nghĩa là hệ thống an toàn tuyệt đối. Một số bài kiểm thử có thể được thực hiện bằng phần mềm tự động, sử dụng các mã khai thác có sẵn để kiểm tra các lỗ hổng đã biết. Những bài kiểm thử khác được tiến hành bởi các chuyên gia an ninh có kỹ năng như hacker mũ trắng. Nhiều công ty lựa chọn thuê ngoài dịch vụ này vì chúng mô phỏng tốt kịch bản tấn công từ bên ngoài.

== Chu trình lỗ hổng ==
Chu trình của lỗ hổng bắt đầu khi lỗ hổng được đưa vào phần cứng hoặc phần mềm. Việc phát hiện lỗ hổng có thể do chính nhà cung cấp phần mềm thực hiện, hoặc do một bên thứ ba. Trong trường hợp do bên thứ ba phát hiện, hành động được coi là đạo đức nhất là thông báo ngay cho nhà cung cấp để họ có thể khắc phục kịp thời. Các cơ quan chính phủ hoặc tình báo có thể mua các lỗ hổng chưa được công bố rộng rãi và sử dụng chúng cho các mục đích tấn công, tích trữ để dùng sau, hoặc thông báo cho nhà cung cấp phần mềm. Tính đến năm 2013, liên minh Ngũ Nhãn (gồm Hoa Kỳ, Vương quốc Anh, Canada, Úc và New Zealand) chiếm phần lớn thị phần mua bán lỗ hổng bảo mật. Các bên mua đáng kể khác bao gồm Nga, Ấn Độ, Brasil, Malaysia, Singapore, Triều Tiên và Iran. Các tổ chức tội phạm có tổ chức cũng tham gia mua lỗ hổng, mặc dù họ thường ưa chuộng các bộ công cụ khai thác hơn.

Ngay cả những lỗ hổng đã được công khai hoặc đã có bản vá cũng thường vẫn có thể bị khai thác trong một khoảng thời gian dài. Các bản vá bảo mật có thể mất hàng tháng để phát triển, hoặc thậm chí có thể là không bao giờ. Một bản vá có thể gây ảnh hưởng tiêu cực đến chức năng của phần mềm, và người dùng có thể cần kiểm thử bản vá để đảm bảo phần mềm vẫn hoạt động bình thường và tương thích. Các tổ chức lớn có thể không xác định và vá được toàn bộ các thành phần phụ thuộc, trong khi các doanh nghiệp nhỏ và người dùng cá nhân lại thường không cài đặt các bản vá. Nghiên cứu cho thấy nguy cơ bị tấn công mạng tăng lên nếu lỗ hổng được công khai hoặc khi bản vá được phát hành. Tội phạm mạng có thể phân tích ngược bản vá để tìm ra lỗ hổng gốc và phát triển mã khai thác, thường nhanh hơn tốc độ người dùng cài đặt bản vá.

Lỗ hổng trở nên lỗi thời khi phần mềm hoặc các phiên bản dễ bị tấn công không còn được sử dụng. Tuy nhiên, quá trình này có thể kéo dài khá lâu; đặc biệt, phần mềm công nghiệp thường rất khó thay thế, ngay cả khi nhà sản xuất đã ngừng hỗ trợ.

== Đánh giá, công bố và kiểm kê ==
=== Đánh giá ===
Một thang điểm phổ biến được sử dụng để đánh giá mức độ nghiêm trọng của lỗ hổng là hệ thống mã nguồn mở có tên Common Vulnerability Scoring System (CVSS). CVSS đánh giá khả năng khai thác lỗ hổng và mức độ ảnh hưởng đến tính bảo mật, tính sẵn sàng và tính toàn vẹn của dữ liệu. Hệ thống này cũng xem xét cách thức lỗ hổng có thể bị khai thác và mức độ phức tạp của việc thực hiện một cuộc tấn công. Ngoài ra, CVSS tính đến quyền truy cập cần thiết để khai thác lỗ hổng và liệu việc khai thác có thể xảy ra mà không cần sự tương tác từ người dùng hay không. Tất cả các yếu tố này đều được đưa vào để tính điểm tổng thể.

=== Công bố ===
Người phát hiện ra một lỗ hổng có thể công bố nó ngay lập tức (công bố toàn phần) hoặc chờ đến khi có bản vá rồi mới công bố (công bố có trách nhiệm hoặc công bố phối hợp). Cách tiếp cận công bố toàn phần được đánh giá cao về tính minh bạch, nhưng nhược điểm là nguy cơ bị tấn công có thể tăng lên nếu lỗ hổng được công khai mà chưa có bản vá. Một số nhà cung cấp phần mềm có chính sách thưởng phát hiện lỗi (bug bounty) bằng việc trả tiền cho những người báo cáo lỗ hổng bảo mật cho họ. Không phải công ty nào cũng phản ứng tích cực trước việc công bố lỗ hổng, vì điều này có thể kéo theo trách nhiệm pháp lý và gia tăng gánh nặng vận hành. Hiện tại, không có luật nào bắt buộc phải công bố lỗ hổng bảo mật. Nếu một lỗ hổng được phát hiện bởi bên thứ ba nhưng không được tiết lộ cho nhà cung cấp hoặc công chúng, thì đó được gọi là lỗ hổng zero-day. Đây thường được xem là loại lỗ hổng nguy hiểm nhất vì gần như không có biện pháp phòng vệ nào tồn tại vào thời điểm đó. 

=== Kiểm kê ===
Bộ dữ liệu lỗ hổng được sử dụng phổ biến nhất là Common Vulnerabilities and Exposures (CVE), do Mitre Corporation quản lý. Tính đến tháng 11 năm 2024, cơ sở dữ liệu Common Vulnerabilities and Exposures (CVE) đã có hơn 240.000 mục. Thông tin này được chia sẻ với các cơ sở dữ liệu khác, bao gồm National Vulnerability Database (NVD) của Hoa Kỳ, nơi mỗi lỗ hổng được gán điểm rủi ro bằng cách sử dụng Common Vulnerability Scoring System (CVSS), Common Platform Enumeration (CPE) và Common Weakness Enumeration (CWE). CVE và các cơ sở dữ liệu tương tự thường không theo dõi các lỗ hổng trong các sản phẩm phần mềm dạng dịch vụ. Việc gửi thông tin lỗ hổng lên CVE là hoàn toàn tự nguyện đối với các công ty phát hiện ra lỗ hổng đó.

== Trách nhiệm pháp lý ==
Nhà cung cấp phần mềm thường không phải chịu trách nhiệm pháp lý về thiệt hại nếu một lỗ hổng bị khai thác trong một cuộc tấn công, điều này tạo ra động lực để họ phát triển phần mềm với chi phí thấp hơn nhưng kém an toàn hơn. Một số công ty chịu sự điều chỉnh của các đạo luật như PCI, HIPAA và Sarbanes-Oxley, vốn đặt ra các yêu cầu pháp lý cụ thể đối với việc quản lý lỗ hổng bảo mật.