Nguồn mở: hiểm họa tiềm tàng trong ứng dụng doanh nghiệp

Việc đóng cửa thư mục tra cứu những lỗ hổng nguồn mở hồi đầu tháng 4/2016 chính thức đặt ra thách thức bảo mật cho các nhà phát triển phần mềm quen dùng lại phần lớn mã nguồn có sẵn miễn phí…

OSVDB (Open Sourced Vulnerability Database) là nguồn cung cấp miễn phí bản vá những lỗ hổng đã biết dành cho các nhà phát triển phần mềm. Không có nguồn này thì vẫn còn các nguồn khác. Nhưng việc đóng cửa OSVDB nêu lên một trong những vấn đề trong cách sử dụng nguồn mở, đặc biệt trong việc phát triển ứng dụng doanh nghiệp: thường sau khi được tích hợp vào ứng dụng, nó hầu như không hề được cập nhật để sửa chữa các lỗ hổng phát hiện sau đó.

Hay nói cách khác, OSVDB đóng cửa đã đặt ra một (hay thậm chí rất nhiều) thách thức bảo mật mới và khó khăn hơn cho ứng dụng doanh nghiệp được phát triển từ nguồn mở.

Đây là vấn đề lớn. Mark Curphey, Giám đốc điều hành SourceClear, một công ty non trẻ tập trung vào việc bảo mật phần mềm nguồn mở, cho rằng “hầu hết mọi người dùng nguồn mở, có thể lên đến 99%, chỉ có 1% code là tự viết”.

Thực sự có lẽ chỉ khoảng 75%, nhưng như thế vẫn đáng kể, theo Mike Pittenger, Phó chủ tịch chiến lược cho Black Duck, hãng cung cấp dịch vụ giúp vá tự động các lỗ hổng nguồn mở cho khách hàng.

Các công ty khác cung cấp dịch vụ tương tự, như WhiteSource, thì dùng thông tin của OSVDB cho mục đích thương mại. Hãng này dò tìm ra các thành phần nguồn mở trong các ứng dụng của khách hàng và cảnh báo khi có đoạn code “dễ tổn thương” được thêm vào dự án phần mềm đang triển khai hoặc khi có các lỗ hổng mới ảnh hưởng đến phần mềm hiện có của khách hàng.

Yêu cầu cấp thiết phát triển phần mềm nhanh chóng dẫn đến việc sử dụng phổ biến nguồn mở. Nó có sẵn, thường là miễn phí và được cả cộng đồng tham gia chỉnh sửa. Nhưng sự gấp rút đó có thể dẫn đến việc các phiên bản của phần mềm nguồn mở được sử dụng không có hồ sơ đầy đủ, khiến cho các chuyên gia bảo mật phải mò mẫm tìm hiểu các ứng dụng trong công ty của mình có lỗ hổng nào hay không.

Trừ khi các nhà phát triển tự giác ghi lại nguồn mở mà họ sử dụng, còn không việc tập hợp thông tin sau đó nói chung phụ thuộc vào “bộ nhớ của nhóm phát triển”.

Hacker nhận thức rõ việc này. Chúng có thể theo dõi GitHub để xem ai đóng góp mã nguồn gì và mã nguồn của ai có vấn đề. Sau đó, chúng lần theo những người quan tâm mã nguồn đó để tìm hiểu những dự án họ đang làm việc, hy vọng họ sẽ sử dụng một số mã nguồn có lỗ hổng đã tìm thấy trên GitHub.

Gần đây, một coder (lập trình viên) JavaScript bực mình do việc tranh chấp tên gọi một trong những gói phần mềm của mình đã trả đũa bằng cách gỡ bõ những mã nguồn mở đóng góp khỏi một thư viện dùng chung, làm ảnh hưởng đến rất nhiều nhà phát triển dựa trên chúng. Do nhiều người phản đối, ban quản trị thư viện đã đi ngược lại mong muốn của coder và tái đăng 11 dòng mã mà nếu thiếu sẽ gây rất nhiều phiền toái.

Vấn đề được giải quyết, ít nhất là trong trường hợp này. Nhưng vấn đề tiềm ẩn – thói quen dùng lại mã nguồn mở trong phần mềm mới – vẫn còn.

Không chỉ nguồn mở

Vấn đề mở rộng sang phần mềm thương mại, và các hãng phần mềm buộc phải tuân theo một chuẩn mực cao. Họ phải công khai những nguồn mở trong phần mềm của mình, giám sát chúng và phát hành bản vá lỗi khi lỗ hổng mới được phát hiện.

Việc giám sát chuỗi cung ứng phần mềm trong các ứng dụng phức tạp là rất quan trọng. Mới tháng trước các nhà nghiên cứu tìm thấy hơn 1.400 lỗ hổng trong một tủ y tế nối mạng do phần mềm của bên thứ ba trong gói giải pháp bao gồm Microsoft Windows XP, Symantec pcAnywhere và SAP Crystal Reports 8.5.

Do sự việc quan trọng nên cuối tháng này Cơ quan quản lý Thực phẩm và Dược của Mỹ (FDA) sẽ bắt đầu xem xét dự thảo về các quy định cho thiết bị y tế và cách thức đối phó với những lỗ hổng phần mềm sau khi các thiết bị y tế xuất xưởng.

Vấn đề bảo mật mã nguồn có thể mở rộng sang các thiết bị mạng. Nổi cộm như vụ Juniper công bố thiết bị NetScreen của hãng bị tấn công cửa hậu (backdoor) và bị chèn mã trái phép vào hệ điều hành hồi tháng 12 năm rồi. Lý do vẫn còn là một bí ẩn – ít nhất là với công chúng. Thoạt nhìn có vẻ như ai đó đã cố tình cài đặt “cửa hậu” để tùy ý khai thác, nhưng các lỗ hổng cũng có thể là kết quả của việc viết code kém, quy trình kiểm soát chất lượng không tốt hoặc dấu lỗi.

Theo Curphey, để điều tra cần phải xem xét cái gọi là đặc tính di truyền của code – xuất xứ của code và người viết nó – nhằm xác định cách thức xảy ra và liệu các đặc tính di truyền này có tạo thêm mối đe dọa khác hay không. “Đó có thể là một nhà phát triển bất hảo. Nếu vậy, nhà phát triển đó còn nhúng tay vào những thứ gì khác?”.

Đó là một trong những vấn đề cơ bản của bảo mật phần mềm, nhưng việc vá lỗi thường bị bỏ qua hoặc trì hoãn cho đến lúc thuận tiện hơn. Vậy là tạo cơ hội cho tin tặc, chúng cũng nhận thức được khuynh hướng này của những người quản trị mạng, theo John Pironti, chủ tịch của IP Architects.

Trong trường hợp NetScreen của Juniper, có khả năng nhiều khách hàng sử dụng thiết bị đã không cài đặt các bản vá lỗi một thời gian dài.

Có những bước cần làm để giảm nguy cơ:

Doanh nghiệp cần phải thiết lập và duy trì liên tục các chương trình nâng cấp và vá lỗi phần mềm. “Hôm nay nó tốt, nhưng ngày mai có thể khác”.

Và khi mua các ứng dụng doanh nghiệp nên tra hỏi các nhà phát triển về việc bảo mật trong quy trình của họ, cách họ sàng lọc mã nguồn và chương trình vá lỗi sản phẩm khi đã trao cho khách hàng. “Chúng ta cần phải nâng cao sự kỳ vọng đối với các nhà cung cấp phần mềm”, Pironti nói.

Thanh Phong – nguồn Infoworld
(theo PCWorld VN)

FPT Aptech – Hệ Thống Đào Tạo Lập Trình Viên Quốc Tế