Xin chào mọi người, hôm nay KenDzz giới thiệu đến mọi người 1 lỗ hổng cực kỳ nghiêm trọng được phát sinh từ một thư viện Java
{tocify}$title={Mục lục}
 |
| Lỗ hổng bảo mật Log4j là gì? Mức độ nguy hiểm và cách khắc phục - KenDzz |
Log4j là gì?
Log4J là một thư viện Java được sử dụng rộng rãi để ghi lại các thông báo lỗi trong các ứng dụng. Nó được sử dụng trong các ứng dụng phần mềm doanh nghiệp, bao gồm các ứng dụng tùy chỉnh do các doanh nghiệp phát triển nội bộ và tạo thành một phần của nhiều dịch vụ điện toán đám mây.
Log4j được sử dụng ở đâu?
Thư viện Log4j 2 được sử dụng trong phần mềm Java doanh nghiệp và theo NCSC của Vương quốc Anh, được bao gồm trong các khuôn khổ Apache như Apache Struts2, Apache Solr, Apache Druid, Apache Flink và Apache Swift.
Những ứng dụng nào bị ảnh hưởng bởi lỗ hổng Log4j?
Vì Log4j được sử dụng rộng rãi nên lỗ hổng bảo mật có thể ảnh hưởng đến rất nhiều phần mềm và dịch vụ từ nhiều nhà cung cấp lớn. Theo NCSC, một ứng dụng dễ bị tấn công “nếu nó sử dụng thông tin đầu vào của người dùng không đáng tin cậy và chuyển nó đến phiên bản dễ bị tấn công của thư viện ghi nhật ký Log4j.”
Lỗ hổng Log4j đang được khai thác rộng rãi như thế nào?
Các chuyên gia bảo mật đã cảnh báo rằng có hàng trăm nghìn nỗ lực của tin tặc nhằm tìm ra các thiết bị dễ bị tấn công; hơn 40 phần trăm mạng công ty đã được nhắm mục tiêu theo một công ty bảo mật.
Mức độ nguy hiểm của Log4j
Log4j, được xây dựng trên một ngôn ngữ mã hóa phổ biến, Java, được sử dụng rộng rãi trong các phần mềm và ứng dụng khác được sử dụng trên toàn thế giới. Lỗ hổng này trong Log4j ước tính có mặt trên 100 triệu phiên bản trên toàn cầu. Lỗ hổng bảo mật này và các cuộc tấn công liên quan chống lại nó đang được coi là Log4Shell trong cộng đồng an ninh mạng.
Lỗ hổng này, còn được cộng đồng bảo mật gọi là lỗ hổng bảo mật, được xếp hạng 10 trên 10 trên Hệ thống chấm điểm lỗ hổng phổ biến, hoặc CVSS, do tác động tiềm ẩn mà nó có thể gây ra nếu bị kẻ tấn công tận dụng. Chi tiết về lỗ hổng bảo mật có thể được tìm thấy trong Cơ sở dữ liệu về lỗ hổng bảo mật quốc gia (NVD) với tiêu đề CVE-2021-44228.
 |
| Lỗ hổng bảo mật Log4j là gì? Mức độ nguy hiểm và cách khắc phục - KenDzz |
Kể từ ngày 14 tháng 12, các nhà nghiên cứu phát hiện ra rằng bản sửa lỗi được phát triển cho CVE-2021-44228 chưa hoàn thiện và nhà cung cấp, Apache, đã phát hành một bản sửa lỗi mới. Vào ngày 17 tháng 12, hai vấn đề mới đã được xác nhận và ngày hôm sau, Apache đã phát hành một bản sửa lỗi khác. Chúng tôi hy vọng chu kỳ sửa chữa lỗ hổng bảo mật này sẽ tiếp tục khi những kẻ tấn công và các nhà nghiên cứu tiếp tục tập trung vào Log4j.
Để đơn giản hóa mọi thứ, danh sách các lỗ hổng bảo mật hiện tại và các bản sửa lỗi được đề xuất được liệt kê ở đây:
- CVE-2021-44228 (Điểm CVSS: 10.0) - Một lỗ hổng thực thi mã từ xa ảnh hưởng đến các phiên bản Log4j từ 2.0-beta9 đến 2.14.1 (Đã sửa trong phiên bản 2.15.0)
- CVE-2021-45046 (Điểm CVSS: 9.0) - Rò rỉ thông tin và lỗ hổng thực thi mã từ xa ảnh hưởng đến các phiên bản Log4j từ 2.0-beta9 đến 2.15.0, ngoại trừ 2.12.2 (Đã sửa trong phiên bản 2.16.0)
- CVE-2021-45105 (Điểm CVSS: 7,5) - Lỗ hổng từ chối dịch vụ ảnh hưởng đến các phiên bản Log4j từ 2.0-beta9 đến 2.16.0 (Đã sửa trong phiên bản 2.17.0)
- CVE-2021-4104 (Điểm CVSS: 8.1) - Một lỗ hổng giải mã không đáng tin cậy ảnh hưởng đến Log4j phiên bản 1.2 (Không có bản sửa lỗi; Nâng cấp lên phiên bản 2.17.0)
- CVE-2021-44832 (Điểm CVSS: 6,6) - Lỗ hổng thực thi mã từ xa ảnh hưởng đến các phiên bản Log4j2 từ 2.0-beta7 đến 2.17.0, ngoại trừ các bản sửa lỗi bảo mật cho 2.3.2 và 2.12.4. (Đã sửa lỗi bằng cách nâng cấp lên 2.3.2 (đối với Java 6), 2.12.4 (đối với Java 7) hoặc 2.17.1 (đối với Java 8 trở lên).
Xin lưu ý rằng tất cả các phiên bản 1.x của Log4j đều được coi là “End of Life”, có nghĩa là chúng không còn được Apache hỗ trợ nữa. Mặc dù các lỗ hổng bảo mật (CVE) được liệt kê ở trên đều được liên kết trực tiếp với Log4Shell, nhưng có một số lỗ hổng đã biết khác trong phiên bản 1.x của Log4j có thể khiến người dùng dễ bị tấn công. Chính vì lý do này mà chúng tôi khuyên tất cả người dùng Log4j cập nhật lên phiên bản 2.x mới nhất có sẵn ngay lập tức.
Khi lỗ hổng ban đầu được công khai, nó được mô tả là zero-day (hoặc 0day), có nghĩa là nó đã được nhắm mục tiêu và có khả năng bị hành động trước khi các nhà phát triển phần mềm biết rằng nó tồn tại. Nói cách khác, các nhà phát triển không có ngày nào để thực hiện sửa chữa lỗ hổng bảo mật trước khi nó có thể được sử dụng trong một cuộc tấn công.
Do sự phổ biến rộng rãi của Log4j, tác động lớn của một cuộc tấn công chống lại nó và bằng chứng cho thấy các tác nhân độc hại đang tích cực nhắm mục tiêu vào các tổ chức có phiên bản Log4j dễ bị tấn công, CIS khuyến khích tất cả các tổ chức giảm thiểu rủi ro càng sớm càng tốt. Trang này nhằm giúp tất cả các tổ chức, bất kể mức độ thành thạo về kỹ thuật, tìm kiếm các nguồn lực để giảm thiểu rủi ro liên quan đến Log4j.
Các bản vá bảo mật có sẵn và CIS khuyến khích tất cả các tổ chức triển khai các bản cập nhật này càng nhanh càng tốt. Ngoài ra, bất kỳ tổ chức nào phụ thuộc vào các nhà cung cấp bên ngoài cho các dịch vụ có thể sử dụng Log4j nên làm việc với các nhà cung cấp đó để đảm bảo các mối quan hệ bên thứ ba này không khiến họ gặp rủi ro không đáng có.
Điều quan trọng cần lưu ý là chỉ cập nhật Log4j có thể không giải quyết được sự cố nếu tổ chức đã bị xâm phạm. Nói cách khác, việc cập nhật lên phiên bản mới nhất của bất kỳ phần mềm nào sẽ không xóa các quyền truy cập mà đối thủ có được hoặc các khả năng độc hại bổ sung bị mất trong môi trường nạn nhân. Do đó, CIS khuyến nghị cảnh giác trong việc điều tra hoạt động trong môi trường của bạn, tìm kiếm bằng chứng về việc truy cập trái phép và hành động theo các phương pháp ứng phó sự cố tốt nhất để giảm phơi nhiễm. Chính phủ Tiểu bang, Địa phương, Bộ lạc và Lãnh thổ (SLTT) và các tổ chức liên kết, bao gồm cả các tổ chức Bầu cử, có thể liên hệ với CIS SOC để được hỗ trợ nếu bạn cho rằng mình bị ảnh hưởng hoặc bị xâm phạm.
Các tổ chức bảo mật tập trung vào mối đe dọa đã quan sát thấy các tác nhân nhà nước bắt đầu tận dụng lỗ hổng trong các cuộc tấn công mới. CIS khuyến nghị nâng cao cảnh giác trong việc giám sát mạng lưới các hành vi bất thường và đưa ra các hành động ứng phó ngay lập tức nếu cần.
Ủy ban Thương mại Liên bang (FTC) gần đây đã cảnh báo các công ty Hoa Kỳ dưới quyền của nó nhằm khắc phục các lỗ hổng Log4Shell và rằng họ có ý định sử dụng các cơ quan pháp lý đầy đủ của ủy ban để theo đuổi các tổ chức không làm giảm mức độ phơi nhiễm của người tiêu dùng với những lỗ hổng này.
Ủy ban Thương mại Liên bang (FTC) gần đây đã cảnh báo các công ty Hoa Kỳ dưới quyền của nó nhằm khắc phục các lỗ hổng Log4Shell và rằng họ có ý định sử dụng các cơ quan pháp lý đầy đủ của ủy ban để theo đuổi các tổ chức không làm giảm mức độ phơi nhiễm của người tiêu dùng với những lỗ hổng này.
Cách khắc phục lỗ hổng Log4j
Theo lời khuyên của Apache, khuyến nghị cập nhật lên phiên bản mới nhất của Log4j ngay lập tức.
Hoặc có thể làm cách thủ công như sau:
LƯU Ý: Có bằng chứng chắc chắn rằng các giải pháp thay thế không hiệu quả. Vì vậy, chúng tôi khuyến khích mọi người cập nhật phiên bản mới nhất từ Apache.
Đối với các phiên bản Log4j>=2.10, hãy đặt thuộc tính hệ thống log4j2.formatMsgNoLookups thành true trên cả các thành phần phía máy khách và phía máy chủ.
Điều này có thể được thực hiện theo nhiều cách:
- Thêm -Dlog4j2.formatMsgNoLookups=true vào các tập lệnh khởi động của các chương trình Java; hoặc
- Đặt biến môi trường sau: LOG4J_FORMAT_MSG_NO_LOOKUPS="true"
Đối với các phiên bản Log4j từ 2.0-beta9 đến 2.10.0, hãy xóa lớp JndiLookup khỏi đường dẫn khóa. Ví dụ:
- zip -q -d log4j-core - *. jar
- org / apache / logging / log4j / core / lookup / JndiLookup.class
Ngoài ra, họ đề xuất các hành động sau:
- Cô lập các hệ thống thành các DMZ hoặc VLAN bị hạn chế của riêng chúng
- Chặn tất cả các kết nối mạng đi từ máy chủ hoặc giới hạn các kết nối mạng đi đối với các máy chủ và cổng mạng đáng tin cậy
- Bật bất kỳ điểm cuối hoặc chữ ký bảo mật mạng nào để khai thác Log4j
- Giám sát chặt chẽ mạng và máy chủ để tìm hành vi đáng ngờ hoặc không mong muốn
TrustedSec khuyến nghị thêm kiểm tra và đánh giá “sau khi TẤT CẢ các bước giảm thiểu ở trên đã được hoàn thành để đảm bảo rằng các lỗ hổng bảo mật không còn tồn tại”.
Nguồn: cisecurity.org