Thế giới an ninh đã nín thở tập thể vào đầu tuần này vì thông báo về lỗ hổng OpenSSL lớn. Hóa ra đó là hai vấn đề riêng biệt, cả hai đều liên quan đến xử lý punycode và chúng đã bị hạ cấp xuống mức độ nghiêm trọng thay vì nghiêm trọng. Nhân tiện, Punycode là hệ thống sử dụng các ký tự Unicode không phải ASCII trong tên miền. Lỗ hổng đầu tiên, CVE-2022-3602, là một lỗi tràn bộ đệm ghi bốn byte tùy ý vào ngăn xếp. Đáng chú ý, mã dễ bị tấn công chỉ được chạy sau khi chuỗi chứng chỉ được xác minh. Chứng chỉ độc hại cần được Tổ chức phát hành chứng chỉ ký đúng cách hoặc được tin cậy theo cách thủ công mà không có chữ ký hợp lệ.
A vài nguồn có làm việc chi tiết của lỗ hổng này. Đó là lỗi từng lỗi một trong một vòng lặp, trong đó độ dài bộ đệm được kiểm tra sớm hơn trong vòng lặp hơn là biến độ dài được tăng lên. Do trượt logic, vòng lặp có thể chạy quá nhiều lần. Vòng lặp đó xử lý các ký tự Unicode, được mã hóa ở cuối chuỗi punycode và đưa chúng vào vị trí thích hợp, kết quả là trượt phần còn lại của chuỗi qua một byte trong bộ nhớ. Nếu tổng độ dài đầu ra là 513 ký tự thì đó là lỗi tràn ký tự. Một ký tự Unicode chiếm bốn byte, do đó, có bốn byte tràn của bạn.
Bây giờ, cách quản lý phần tràn này có thể khai thác được phụ thuộc vào những gì có trong bốn byte đó. Khi các nhà nghiên cứu Datadog kiểm tra lỗ hổng trên Linux, họ nhận thấy rằng về cơ bản mỗi tệp nhị phân được biên dịch đều có một phần bộ nhớ trống 4 byte ở đây, chỉ được khởi tạo sau khi bị tràn. Nói cách khác, trên các mã nhị phân đó, lỗ hổng này hoàn toàn lành tính. Trên Windows, phần bộ nhớ đó được trình biên dịch xử lý khác nhau do các cách tối ưu hóa khác nhau. Ở đây, nó chứa một chồng chim hoàng yến. Đó là một giá trị đặc biệt tồn tại giữa vùng đệm cuối cùng trên ngăn xếp, với con trỏ và giá trị trả về. Khi kết thúc một hàm bằng cách sử dụng một ngăn xếp canary, giá trị được xác thực trước khi quay trở lại hàm mẹ và các quá trình sẽ bị lỗi nếu nó bị giả mạo. Ý tưởng là tràn bộ đệm ghi đè địa chỉ trả về sẽ không thể dự đoán giá trị canary và chim hoàng yến có xu hướng cố ý bao gồm các byte đầu cuối như 0x00 để khiến việc khai thác thậm chí còn khó khăn hơn. Lưu ý rằng các tệp nhị phân Linux cũng sử dụng các mã lệnh ngăn xếp, điều này sẽ ngăn chặn việc khai thác, nhưng do bố cục bộ nhớ và độ dài tràn giới hạn, chúng không bao giờ được sửa đổi.
Sự cố thứ hai đã được khắc phục là CVE-2022-3786 và Checkpoint Security đã giải thích vấn đề này. Trong trường hợp Punycode được theo sau bởi một dấu chấm, dấu chấm đó được nối vào cuối chuỗi đầu ra, có khả năng ở phía sau phần cuối của bộ đệm. Nó là nghịch đảo của lỗ hổng trước đó. Ở đây độ dài của phần tràn gần như là tùy ý, nhưng giá trị bị khóa chỉ với biểu tượng dấu chấm. Do đó, đây hoàn toàn là một sự cố Từ chối Dịch vụ.
Rất may, bầu trời không sụp đổ với những lỗ hổng này, nhưng vẫn có thể xảy ra những trường hợp không lường trước được khi OpenSSL không được biên dịch với mã lệnh ngăn xếp hoặc sự cố có thể được sử dụng như một phần của chuỗi khai thác phức tạp hơn, vì vậy hãy đảm bảo lấy bản vá được cập nhật hoặc báo cáo lại nếu bạn đang chạy thư viện dễ bị tấn công, phiên bản 3.0.0-3.0.6.
Các nhà nghiên cứu an ninh quay sang mặt tối?
Định luật về tiêu đề của Betteridge chắc chắn được áp dụng ở đây. Câu chuyện này thật kỳ quặc, vì ai đó đã thực hiện một cuộc tấn công ransomware, đó cũng là phần mềm phản đối, và cũng tuyên bố là công việc của một số nhà nghiên cứu bảo mật đáng chú ý. Vậy, liệu Bleeping Computer có thực sự đứng sau chiến dịch ransomware này cũng phản đối việc phương Tây thiếu hỗ trợ Ukraine? Ồ, có rất nhiều thứ để giải nén ở đây.
Đầu tiên, nó dường như thậm chí không phải là ransomware, vì không có cách nào để mua khóa giải mã. Vì vậy, đúng hơn đó là một cái gạt nước. Tên được sử dụng trong ghi chú gạt nước là "Azov", một trung đoàn lực lượng đặc biệt ở Ukraine với quá khứ kỳ quặc mới là Đức Quốc xã, tình cờ sử dụng các bài hùng biện của Nga về cuộc chiến của họ ở đó. Sau đó, ghi chú tuyên bố là từ băm nhỏvà liệt kê một số xử lý Twitter của nhà nghiên cứu bảo mật. Sau đó, đề cập đến Crimea và phàn nàn về việc không đủ sự giúp đỡ cho Ukraine. j Có một thông điệp cụ thể cho người dân Hoa Kỳ, kêu gọi tổng thống Biden, kêu gọi cách mạng và sau đó bỏ khẩu hiệu "Giữ cho nước Mỹ vĩ đại". Sau đó, một tin nhắn gửi đến Đức, chạy qua Google Dịch một cách hữu ích cho chúng tôi: “Bạn! Một người đàn ông đến từ Đức, đi ra!
Nhưng đó là một thảm họa mà Biden đã mang lại cho họ. Thật tuyệt làm sao khi Merkel ở đó? ” Và sau đó kỳ lạ hơn nữa, ghi chú kết thúc với hashtag “#TaiwanIsChina”, có vẻ như là một khẩu hiệu của bài hùng biện được ĐCSTQ bảo trợ xung quanh Đài Loan.
Thật khó để tìm ra chính xác những gì xảy ra với chiến dịch này. Rõ ràng đó không phải là những gì nó tuyên bố. Một hacker thân Nga hay chống Nga đang cố gắng nâng cao sự ủng hộ? Một cái gì đó hoàn toàn khác, sử dụng địa chính trị để che đậy? Tất cả các sự lây nhiễm dường như là kết quả của SmokeLoader, một trong những mạng botnet phần mềm độc hại như một dịch vụ. Trả một số tiền, đẩy tải trọng của bạn đến các máy trên mạng botnet. Chỉ xin nhắc lại, nếu bạn hoặc ai đó bạn biết bị ảnh hưởng bởi một trong những chiến dịch này, các văn phòng thực thi pháp luật sẽ muốn ghi lại điều đó. Để xác định vị trí và truy tố tội phạm đứng sau các doanh nghiệp này, họ cần một số trường hợp cụ thể để bắt đầu. Và có vẻ như tội phạm ransomware sẽ không bao giờ bị bắt, họ bị nhận dạng và bị bắt.
Project Zero chống lại việc gọi nó là XML4Shell
[Felix Wilhelm] tìm thấy một vấn đề Javavà với niềm vui chung của chúng tôi, anh ấy không cảm thấy cần thiết phải đặt biệt danh "4shell" cho nó. Câu chuyện này bắt đầu với SAML, Ngôn ngữ đánh dấu xác nhận bảo mật, giao thức dựa trên XML hỗ trợ phần lớn khả năng hỗ trợ đăng nhập một lần của web. Bạn muốn truy cập trang web X, Nhà cung cấp dịch vụ (SP) và sử dụng tài khoản của mình từ trang web Y, Nhà cung cấp danh tính (IdP) của bạn. SP tạo một yêu cầu SAML, ở dạng tài liệu XML và trình duyệt của bạn gửi tài liệu đó đến IdP. IdP xác nhận rằng bạn có tài khoản ở đó và gửi lại chữ ký XML thông qua trình duyệt. Vì đây là một vấn đề tiềm ẩn rõ ràng đối với trình duyệt của người dùng là trình xử lý dữ liệu đăng nhập, bản thân dữ liệu được xác minh như một phần của chữ ký. Toàn bộ quá trình phức tạp và một trong những điều phức tạp là một chữ ký có thể bao gồm các tham chiếu đến các chữ ký khác. Trước khi chữ ký được xác minh hoàn toàn, tài liệu XML đã ký có thể cần trải qua một số bước chuyển đổi và ngôn ngữ Chuyển đổi ngôn ngữ biểu định kiểu eXtensible (XSLT) được hỗ trợ. Vâng, đó là một ngôn ngữ hoàn chỉnh ngay trong các đối tượng SAML của bạn. Và nếu mã thực hiện xác minh không bật secureValidation, mã được biên dịch thành mã Java để tăng hiệu suất.
Một phần của quá trình biên dịch này là chuyển đổi các giá trị trong đầu vào XSLT thành nhóm hằng số Java. Nhóm đó có kích thước hạn chế và quá trình biên dịch không thực hiện chính xác việc kiểm tra giới hạn. Điều gì xảy ra khi bạn viết quá cuối hồ bơi? Dữ liệu đó được hiểu là các trường lớp - các trường giống như định nghĩa phương thức. Thực hiện công việc để tạo các giá trị hợp lệ cho ba trường mà phần tràn này sẽ che khuất và bạn có khả năng chạy bytecode tùy ý. Điều này hoạt động cho bất kỳ ứng dụng Java nào xử lý chữ ký XML - về lý thuyết. Cảnh báo lớn là secureValidation tắt tất cả các phép biến đổi XSLT, nhưng điều đó chỉ được bật theo mặc định trong JDK 17.
urlscan.io Nắm giữ Bí mật
Dịch vụ được cung cấp bởi urlscan.io thực sự khá hữu ích. Cung cấp cho nó một liên kết web và nó sẽ tải nó, xem trước trang cho bạn và đưa ra một số thống kê về nó. Ai đó gửi một liên kết lạ và bạn không muốn mở nó trên máy của mình? Đây là giải pháp của bạn. Điều duy nhất cần lưu ý là trừ khi bạn đánh dấu rõ ràng quá trình quét là riêng tư, liên kết và kết quả có thể xem công khai. Github đã bị một chút vào năm ngoái, vô tình làm rò rỉ tên kho lưu trữ riêng tư cho dịch vụ. Điều này khiến [FABIAN BRÄUNLEIN] ngạc nhiên, có các dịch vụ khác mắc lỗi tương tự? Đúng. Có các liên kết đến tài liệu Google riêng tư, khóa API, lời mời Sharepoint và Zoom, v.v. Rõ ràng một số dịch vụ bảo mật tự động đẩy các liên kết đến dịch vụ mà không có bất kỳ sự tương tác nào của người dùng và không sử dụng API đúng cách. Rất tiếc.
