NodeJS component express-fileupload nổi tiếng với hơn 7 triệu lượt tải về từ npm registry – đang có một lỗ hổng Prototype Pollution nghiêm trọng. Ở mức tối thiểu, lỗ hổng này cho phép những kẻ tấn công chơi đùa với các ứng dụng NodeJS của bạn và gây ra một loạt lỗi HTTP 500 (chẳng hạn như tấn công từ chối dịch vụ – Denial of Service). Các tấn công nâng cao hơn nhắm vào khả năng thay thế template của lỗ hổng, cho phép hacker thực thi mã nguồn từ xa trên một thiết bị dễ bị tấn công.

Component express-fileupload là một lựa chọn khá phổ biến của các lập trình viên vì nó cung cấp nhiều tùy chọn khi upload file và có thể dễ dàng tích hợp vào ứng dụng. Nếu bạn đang sử dụng phiên bản express-fileupload dễ bị tấn công, bạn nên biết về những rủi ro bảo mật mà nó có thể gây ra.

Lỗ hổng bảo mật (CVE-2020-7699) được nhà nghiên cứu bảo mật của Posix phát hiện ra vào cuối tháng 7/2020, bạn có thể xem thêm chi tiết về nó trong bài đăng trên blog của ông.

Vấn đề của lỗ hổng bảo mật Prototype Pollution

Hacker rất hứng thú với lỗ hổng Prototype Pollution vì tính linh hoạt của chúng, cho phép thay đổi mọi đối tượng và thuộc tính của một ứng dụng JavaScript chỉ với một lý do duy nhất: lỗi thiết kế cố hữu trong ngôn ngữ lập trình này.

JavaScript là một ngôn ngữ lập trình dựa trên nguyên mẫu (prototyping language), chú trọng khả năng sửa đổi template cơ bản – cơ sở của tất cả các đối tượng và thuộc tính. Trước đây, các lỗ hổng Prototype Pollution trong mã nguồn JavaScript được sử dụng tại client-side context đã đặt ra những vấn đề về bảo mật. Tuy nhiên, sự tấn công thường kết thúc khi trình duyệt của người dùng cuối gặp sự cố hoặc ứng dụng hoạt động không đúng ở máy khách, hay nói cách khác là tác động xấu đã bị kiềm chế.

Nhưng kể từ khi kiến trúc serverless (không máy chủ) ra đời, cùng với các ứng dụng được tạo ra từ NodeJS, ngôn ngữ JavaScript đã được sử dụng để xây dựng hàng nghìn ứng dụng backend. Điều này gây ra rủi ro bảo mật cao hơn, đặc biệt là khi các tổ chức không cập nhật các lỗ hổng NodeJS mới nhất và tìm cách vá lỗi.

“Mức độ nghiêm trọng của các lỗ hổng Prototype Pollution phụ thuộc vào nơi component này được sử dụng. Nếu được sử dụng như một phần của front-end JavaScript, các lỗ hổng này về cơ bản sẽ dẫn đến Cross-Site Scripting (XSS), còn khi được sử dụng trong ứng dụng backend NodeJS, chúng gần như tương đương với Remote Code Execution (RCE).”

Garrett Calpouzos, Trưởng nhóm Nghiên cứ Bảo mật tại Sonatype

Với các lỗ hổng Prototype Pollution như thế này, tất cả những gì cần thiết là một yêu cầu HTTP duy nhất để hacker có được quyền truy cập shell và thực hiện từ xa các lệnh trên máy chủ chạy express-fileupload cùng với các thư viện mã nguồn mở khác (như EJS).

Sonatype khắc phục vấn đề này như thế nào?

Nhóm Nghiên cứu Bảo mật của Sonatype đã nghiên cứu sâu về lỗ hổng này, và nhận thấy rằng lời khuyên chính thức từ NVD là không chính xác, bởi vì mặc dù các cuộc thảo luận công khai trên các diễn đàn đều cho rằng phiên bản 1.1.8 đã được sửa, nhưng đó chỉ là sửa một phần.

Trong bản cập nhật sửa lỗi 1.1.8, mặc dù các giá trị JSON tải lên có chứa ‘__proto__’ được coi là không hợp lệ và bị lọc đi, nhưng một biến thể khác của tấn công vẫn chưa được xem xét.

Theo như một người dùng đã chỉ ra trên GitHub, hacker có thể chỉ cần sử dụng 'constructor.prototype' – trái ngược với '__proto__' để có thể thông qua bước kiểm tra này và thực hiện tấn công Prototype Pollution vào các đối tượng.

Nhận thấy điều này, các nhà phát triển đã nhanh chóng ngừng sử dụng phiên bản 1.1.8, thay vào đó là phiên bản 1.1.9 khắc phục được lỗi nói trên:

Xem thêm trên GitHub

Hơn nữa, ngoài '__proto__' và 'constructor', từ phiên bản 1.1.10 trở lên, một số biện pháp bảo vệ mới đã được thêm vào trong các mảng để ngăn chặn việc sửa đổi các phương thức và thuộc tính đối tượng:

Tóm lại

Khả năng sửa lỗi và vá lỗ hổng nhanh chóng của nhóm phát triển express-fileupload rất đáng khen ngợi, tuy nhiên thành phần dễ bị tấn công này đã có hơn 7 triệu lượt tải xuống và khả năng cao là đã có mặt trong những phần mềm của bạn. Mục đích của bài viết này nhằm giúp làm rõ hiểu lầm rằng bản 1.1.8 đã được sửa lỗi và an toàn. Nếu bạn đang sử dụng phiên bản này, hãy nâng cấp lên phiên bản 1.1.10 hoặc cao hơn để cập nhật bản sửa lỗi hoàn chỉnh cho lỗ hổng này.

Với hàng nghìn lỗ hổng được báo cáo hàng năm trong các component mã nguồn mở, việc theo dõi thủ công từng cách tấn công là gần như không thể. Các tổ chức DevOps-native với khả năng triển khai liên tục các bản phát hành phần mềm có lợi thế tự động hóa cao, cho phép họ đi trước một bước so với các mục đích xấu. Khách hàng của Sonatype Nexus đã được thông báo về CVE-2020-7699 chỉ trong vòng vài giờ sau khi lỗ hổng được phát hiện ra và nhóm phát triển của Sonatype cũng ngay lập tức nhận được những hướng dẫn về cách khắc phục rủi ro.

Nếu bạn không phải là một khách hàng của Sonatype và muốn tìm hiểu xem mã nguồn của mình có dễ bị tấn công hay không, bạn có thể sử dụng Trình quét lỗi hổng bảo mật Nexus miễn phí (Sonatype’s free Nexus Vulnerability Scanner) để phát hiện lỗ hổng nhanh chóng. Ngoài ra, bạn cũng có thể truy cập trang Nexus Intelligence Insights để tìm hiểu sâu hơn về các vấn đề bảo mật khác.

Nguồn: Sonatype Blog