Samba, nói một cách đơn giản, là một triển khai lại mã nguồn mở siêu hữu ích, cực kỳ phổ biến của các giao thức mạng được sử dụng trong Microsoft Windows và không thể đánh giá thấp tầm quan trọng lịch sử của nó trong liên mạng (kết nối hai loại mạng khác nhau).

Vào cuối những năm 1990, hệ thống mạng của Microsoft đã rũ bỏ bản chất mờ đục, độc quyền của nó và trở thành một tiêu chuẩn mở được gọi là CIFS, viết tắt của hệ thống tập tin internet phổ biến.

Nhưng không có gì là "phổ biến" hay "mở" về nó vào đầu những năm 1990, khi học giả người Úc Andrew Tridgell bắt đầu sửa chữa điều đó bằng cách triển khai một hệ thống tương thích cho phép anh ta kết nối máy tính Unix của mình với mạng Windows và ngược lại.

Trước đó, giao thức được gọi chính thức là SMB, viết tắt của khối tin nhắn máy chủ (một cái tên mà bạn vẫn nghe thấy thường xuyên hơn nhiều so với CIFS), vì vậy Tridge, tên thường gọi là Andrew Tridgell, đã gọi dự án của mình là “SMBserver” một cách dễ hiểu, bởi vì nó vốn là như vậy.

Nhưng một sản phẩm thương mại có tên đó đã tồn tại, vì vậy cần có một biệt danh mới.

Đó là khi dự án được gọi là Samba, một cái tên dễ nhớ thú vị xuất phát từ việc tìm kiếm từ điển các từ có dạng S?M?B?.

Trong thực tế, samba vẫn là từ đầu tiên ra khỏi cổng theo thứ tự bảng chữ cái trong dict tệp thường được tìm thấy trên máy tính Unix, theo sau là từ khá không phù hợp scramble và hoàn toàn không phù hợp scumbag:

Một số lỗi bạn mắc phải, nhưng một số lỗi bạn mắc phải

Qua nhiều năm, dự án Samba không chỉ giới thiệu và sửa các lỗi riêng của nó, như bất kỳ dự án phần mềm phức tạp nào thường làm, mà còn kế thừa các lỗi và thiếu sót trong giao thức cơ bản, do mục tiêu của nó luôn là hoạt động liền mạch với các mạng Windows.

(Đáng buồn thay, cái gọi là khả năng tương thích lỗi thường là một phần không thể tránh khỏi khi xây dựng một hệ thống mới hoạt động với một hệ thống hiện có.)

Cuối năm 2022, một trong những “lỗ hổng di truyền” đó đã được tìm thấy và báo cáo cho Microsoft, được cung cấp mã định danh CVE-2022-38023và được vá trong bản cập nhật Bản vá Thứ Ba tháng 2022 năm XNUMX.

Lỗi này có thể đã cho phép kẻ tấn công thay đổi nội dung của một số gói dữ liệu mạng mà không bị phát hiện, mặc dù đã sử dụng MAC mật mã (mã xác thực tin nhắn) nhằm ngăn chặn giả mạo và giả mạo.

Đáng chú ý, bằng cách thao túng dữ liệu tại thời điểm đăng nhập, tội phạm mạng xảo quyệt có thể thực hiện một cuộc tấn công nâng cao đặc quyền (EoP).

Về lý thuyết, ít nhất họ có thể lừa một máy chủ nghĩ rằng họ đã vượt qua "bạn có thông tin xác thực của Quản trị viên không?" kiểm tra, mặc dù họ không có những thông tin đăng nhập đó và dữ liệu giả mạo của họ đã không thể xác minh bằng mật mã.

Mật mã nhanh nhạy

Chúng tôi quyết định viết về lỗi khá bí ẩn này không phải vì chúng tôi nghĩ rằng bạn rất có thể bị nó khai thác (mặc dù khi nói đến an ninh mạng, chúng tôi có thái độ không bao giờ nói không bao giờ), nhưng bởi vì nó là một một lời nhắc nhở khác tại sao sự linh hoạt của mật mã là quan trọng.

Tập thể, chúng ta cần cả kỹ năng và ý chí để từ bỏ các thuật toán cũ mãi mãi ngay khi chúng được phát hiện là có thiếu sót, và không để chúng nằm đó vô thời hạn cho đến khi chúng trở thành vấn đề của người khác. (“Ai đó khác” đó có thể chính là chúng ta, mười năm sau.)

Đáng ngạc nhiên, lỗ hổng CVE-2022-38023 tồn tại ngay từ đầu vì cả Windows và Samba vẫn hỗ trợ kiểu bảo vệ toàn vẹn dựa trên thuật toán băm MD5 đã bị phản đối từ lâu.

Nói một cách đơn giản, xác thực mạng bằng phiên bản giao thức Kerberos của Microsoft vẫn cho phép dữ liệu được bảo vệ toàn vẹn (hoặc tổng kiểm tra, để sử dụng thuật ngữ biệt ngữ thông thường nhưng không chính xác hoàn toàn) bằng cách sử dụng mật mã thiếu sót.

Bạn không nên sử dụng MD5 nữa vì nó được coi là bị hỏng: kẻ tấn công kiên quyết có thể dễ dàng đưa ra hai đầu vào khác nhau có cùng hàm băm MD5.

Tuy nhiên, như bạn có thể đã biết, một trong những yêu cầu của bất kỳ hàm băm nào khẳng định chất lượng mật mã là điều này đơn giản là không thể thực hiện được.

Trong biệt ngữ, hai đầu vào có cùng hàm băm được gọi là va chạmvà không được cho là có bất kỳ thủ thuật hoặc phím tắt có lập trình nào để giúp bạn tìm thấy một cách nhanh chóng.

Không có cách nào để tìm ra một vụ va chạm tốt hơn là chúc may mắn đơn giản - thử đi thử lại với các tệp đầu vào luôn thay đổi cho đến khi bạn trúng số độc đắc.

Chi phí thực sự của một vụ va chạm

Giả sử một thuật toán đáng tin cậy, không có điểm yếu nào có thể khai thác, bạn sẽ mong đợi rằng một hàm băm với X bit đầu ra sẽ cần khoảng 2^X-1 cố gắng tìm đầu vào thứ hai xung đột với hàm băm của tệp hiện có.

Ngay cả khi tất cả những gì bạn muốn làm là tìm hai đầu vào bất kỳ (hai đầu vào tùy ý, bất kể nội dung, kích thước hoặc cấu trúc) tình cờ có cùng một hàm băm, thì bạn sẽ cần nhiều hơn 2 một chút.^{X / 2} cố gắng trước khi bạn va chạm.

Bất kỳ thuật toán băm nào có thể được “bẻ khóa” một cách đáng tin cậy nhanh hơn thuật toán đó đều không an toàn về mặt mật mã, bởi vì bạn đã chỉ ra rằng quy trình nội bộ của thuật toán băm nhỏ-cắt nhỏ-và-xáo trộn dữ liệu được đưa vào nó không tạo ra một kết quả giả ngẫu nhiên thực sự ở tất cả.

Lưu ý rằng bất kỳ quy trình bẻ khóa dựa trên cơ hội nào, ngay cả khi nó chỉ tăng tốc quá trình tạo va chạm một chút và do đó hiện không phải là rủi ro có thể khai thác trong đời thực, sẽ phá hủy niềm tin vào thuật toán mật mã cơ bản bằng cách làm suy yếu các tuyên bố về tính đúng đắn của mật mã .

Nếu có 2^X đầu ra hàm băm có thể khác nhau, bạn hy vọng sẽ đạt được cơ hội 50:50 để tìm thấy đầu vào có hàm băm cụ thể, được xác định trước sau khoảng một nửa số lần thử và 2^X/2 = 2^X-1. Việc tìm hai tệp bất kỳ xung đột sẽ dễ dàng hơn, bởi vì mỗi khi bạn thử nhập dữ liệu mới, bạn sẽ thắng nếu hàm băm mới của bạn xung đột với bất kì trong số các đầu vào trước đó mà bạn đã thử, bởi vì bất kỳ cặp đầu vào nào cũng được phép. Đối với xung đột của loại “bất kỳ hai tệp nào trong nhóm khổng lồ này sẽ làm được”, bạn đạt được cơ hội thành công 50:50 chỉ nhiều hơn một chút so với căn bậc hai của số lượng băm có thể có và √2^X = 2^{X / 2}. Vì vậy, đối với hàm băm 128 bit, chẳng hạn như MD5, trung bình bạn mong muốn băm khoảng 2¹²⁷ các khối để khớp với một giá trị đầu ra cụ thể và 2⁶⁴ các khối để tìm bất kỳ cặp đầu vào va chạm nào.

Xung đột MD5 nhanh được thực hiện dễ dàng

Khi điều đó xảy ra, bạn không thể dễ dàng tạo hai đầu vào giả ngẫu nhiên hoàn toàn khác nhau, không liên quan, có cùng hàm băm MD5.

Và bạn không thể dễ dàng quay ngược lại từ hàm băm MD5 để khám phá bất kỳ điều gì về đầu vào cụ thể đã tạo ra hàm băm đó, đây là một lời hứa mật mã khác mà hàm băm đáng tin cậy cần phải tuân thủ.

Nhưng nếu bạn bắt đầu với hai đầu vào giống hệt nhau và cẩn thận chèn một cặp khối "xây dựng xung đột" được tính toán có chủ ý vào cùng một điểm trong mỗi luồng đầu vào, bạn có thể tạo xung đột MD5 một cách đáng tin cậy trong vài giây, ngay cả trên một máy tính xách tay khiêm tốn.

Ví dụ: đây là một chương trình Lua mà chúng tôi đã viết có thể được chia thành ba phần riêng biệt một cách thuận tiện, mỗi phần dài 128 byte.

Có một tiền tố mã kết thúc bằng một dòng văn bản bắt đầu nhận xét Lua (chuỗi bắt đầu --[== ở dòng 8), sau đó có 128 byte văn bản chú thích có thể được thay thế bằng bất cứ thứ gì chúng ta thích, bởi vì nó bị bỏ qua khi tệp chạy (dòng 9 đến 11) và có một hậu tố mã 128 byte để đóng chú thích (các chuỗi bắt đầu --]== ở dòng 12) và kết thúc chương trình.

Ngay cả khi bạn không phải là lập trình viên, bạn có thể thấy rằng mã hoạt động đọc trong nội dung [dòng 14] của chính tệp mã nguồn (trong Lua, giá trị arg[0] trên dòng 5 là tên của tệp tập lệnh mà bạn hiện đang chạy), sau đó in nó ra dưới dạng kết xuất hex [dòng 15] , theo sau là mã băm MD5 [dòng 17]:

Chạy tệp về cơ bản là tự mô tả và làm cho ba khối 128 byte trở nên rõ ràng:

Sử dụng MD5 công cụ nghiên cứu gọi là md5_fastcoll, ban đầu được tạo ra bởi nhà toán học Marc Stevens Là một phần trong chương trình Thạc sĩ về mật mã học của anh ấy vào năm 2007, chúng tôi đã nhanh chóng tạo ra hai khối “xây dựng xung đột MD128” 5 byte mà chúng tôi đã sử dụng để thay thế văn bản nhận xét được hiển thị trong tệp ở trên.

Điều này đã tạo ra hai tệp mà cả hai vẫn hoạt động như trước đây vì các thay đổi được giới hạn trong nhận xét, điều này không ảnh hưởng đến mã thực thi trong cả hai tệp.

Nhưng chúng khác nhau rõ ràng ở một số byte và do đó sẽ có các giá trị băm hoàn toàn khác nhau, như đoạn mã sau khác biệt (biệt ngữ cho kết xuất của sự khác biệt được phát hiện) tiết lộ.

Chúng tôi đã chuyển đổi các khối tạo xung đột 128 byte, không có nghĩa là văn bản có thể in được, thành hệ thập lục phân cho rõ ràng:

Tuy nhiên, chạy cả hai cho thấy rõ ràng rằng chúng đại diện cho xung đột hàm băm, bởi vì chúng hóa ra có cùng đầu ra MD5:

Độ phức tạp va chạm được khám phá

MD5 là hàm băm 128 bit, như các chuỗi đầu ra ở trên đã làm rõ.

Vì vậy, như đã đề cập trước đây, chúng tôi dự kiến ​​sẽ cần khoảng 2^128/2Hoặc 2⁶⁴ cố gắng ở mức trung bình để tạo ra xung đột MD5 dưới bất kỳ hình thức nào.

Điều đó có nghĩa là xử lý tối thiểu khoảng 18 triệu khối băm MD5, bởi vì 2⁶⁴ = 18,446,744,073,709,551,616.

Với tốc độ băm MD5 cao nhất ước tính là khoảng 50,000,000 khối/giây trên máy tính xách tay của chúng tôi, điều đó có nghĩa là chúng tôi phải đợi hơn 10,000 năm và mặc dù những kẻ tấn công được tài trợ tốt có thể dễ dàng đạt tốc độ nhanh hơn thế từ 10,000 đến 100,000 lần, thậm chí chúng sẽ chờ đợi hàng tuần hoặc hàng tháng chỉ để một vụ va chạm ngẫu nhiên (và không nhất thiết hữu ích) xuất hiện.

Tuy nhiên, cặp tệp Lua hai mặt ở trên, có hàm băm MD5 giống hệt nhau mặc dù rõ ràng là không giống nhau, chúng tôi chỉ mất vài giây để chuẩn bị.

Thật vậy, việc tạo 10 xung đột khác nhau cho 10 tệp, sử dụng 10 tiền tố bắt đầu khác nhau mà chúng tôi tự chọn, đã mất: 14.9 giây, 4.7 giây, 2.6 giây, 2.1 giây, 10.5 giây, 2.4 giây, 2.0 giây, 0.14 giây, 8.4 giây, và 0.43 giây.

Rõ ràng, mật mã của MD5 hứa hẹn cung cấp cái được gọi là chống va chạm về cơ bản là bị phá vỡ…

…rõ ràng là theo hệ số ít nhất là 25 tỷ, dựa trên việc chia thời gian trung bình mà chúng tôi dự kiến ​​sẽ chờ để tìm ra một vụ va chạm (hàng nghìn năm, như ước tính ở trên) cho thời gian tồi tệ nhất mà chúng tôi thực sự đo được (14.9 giây) trong khi phát ra mười va chạm khác nhau chỉ cho bài viết này.

Lỗ hổng xác thực được giải thích

Nhưng còn việc sử dụng MD5 không an toàn trong CVE-2022-38023 thì sao?

Trong mã giả kiểu Lua, mã xác thực thư bị lỗi được sử dụng trong quá trình đăng nhập là tính toán như thế này:

Để giải thích: mã xác thực được sử dụng được tính toán bởi hmac.md5() gọi hàm ở dòng 15, sử dụng cái được gọi là hàm băm có khóa, trong trường hợp này là HMAC-MD5.

Tên HMAC là viết tắt của xây dựng mật mã để tạo mã xác thực tin nhắn dựa trên hàm bămvà hậu tố -MD5 biểu thị thuật toán băm mà nó đang sử dụng nội bộ.

HMAC sử dụng một khóa bí mật, kết hợp với hai lần gọi hàm băm cơ bản, thay vì chỉ một, để tạo mã xác thực thông báo của nó:

Khóa có một số bit của nó được lật trước và được thêm vào trước dữ liệu được cung cấp trước khi hàm băm đầu tiên bắt đầu.

Điều này làm giảm đáng kể khả năng kiểm soát mà những kẻ bẻ khóa mật mã có, khi chúng cố gắng gây ra xung đột hoặc hành vi không ngẫu nhiên khác trong quá trình băm, đối với trạng thái bên trong của hàm băm khi đạt đến byte đầu tiên của dữ liệu đầu vào.

Đáng chú ý, khóa bí mật ngăn những kẻ tấn công bắt đầu bằng tiền tố tin nhắn do chúng tự chọn, như chúng tôi đã làm trong phần twohash.lua ví dụ trên.

Sau đó, khi hàm băm đầu tiên được tính toán, khóa có một tập hợp bit khác được lật, được thêm vào trước giá trị hàm băm đầu tiên đó và dữ liệu đầu vào mới này được băm lần thứ hai.

Điều này cũng ngăn chặn những kẻ tấn công thao túng phần cuối cùng của phép tính HMAC, đáng chú ý là ngăn chặn chúng thêm một hậu tố do chính chúng lựa chọn vào giai đoạn cuối cùng của quá trình băm.

Thật vậy, mặc dù bạn hoàn toàn không nên sử dụng MD5, nhưng chúng tôi không biết về bất kỳ cuộc tấn công hiện tại nào có thể phá vỡ thuật toán khi nó được sử dụng ở dạng HMAC-MD5 với một khóa được chọn ngẫu nhiên.

Cái lỗ ở giữa

Do đó, lỗ hổng có thể khai thác trong mã giả ở trên không nằm ở một trong hai dòng mà hmac.md5() chức năng được sử dụng.

Thay vào đó, trung tâm của lỗi nằm ở dòng 11, nơi dữ liệu bạn muốn xác thực được nén thành một chuỗi có độ dài cố định…

.. bằng cách đẩy nó qua một lần gọi MD5 cũ đơn giản.

Nói cách khác, cho dù bạn chọn chức năng HMAC nào ở dòng 15 và cho dù bước cuối cùng đó có mạnh mẽ và chống va chạm đến mức nào, thì bạn vẫn có cơ hội gây ra xung đột hàm băm ở dòng 11.

Nói một cách đơn giản, nếu bạn biết dữ liệu được cho là sẽ đi vào chksum() chức năng được xác thực và bạn có thể sử dụng trình tạo xung đột để tìm một khối dữ liệu khác có cùng hàm băm MD5…

…dòng 11 có nghĩa là bạn sẽ kết thúc với chính xác cùng một giá trị đầu vào (biến signdat trong mã giả) được đẩy vào bước HMAC cuối cùng an toàn tùy thích.

Do đó, mặc dù cuối cùng bạn có thể đang sử dụng chức năng phân loại thông báo có khóa mạnh, tuy nhiên, bạn vẫn có thể đang xác thực hàm băm MD5 được lấy từ dữ liệu của kẻ mạo danh.

Ít hơn sẽ có nhiều hơn

Như điệu Samba bản tin an ninh mô tả ngắn gọn vấn đề:

Điểm yếu […] là tổng kiểm tra an toàn được tính như HMAC-MD5(MD5(DATA),KEY), có nghĩa là kẻ tấn công đang hoạt động biết dữ liệu văn bản gốc có thể tạo ra một lựa chọn khác DATA, với cùng tổng kiểm tra MD5 và thay thế nó vào luồng dữ liệu mà không bị phát hiện.

Trớ trêu thay, bỏ qua MD5(DATA) một phần của công thức HMAC ở trên, thoạt nhìn có vẻ như làm tăng quá trình “trộn” tổng thể, sẽ cải thiện khả năng chống va chạm.

Nếu không có quá trình nén MD5 ở giữa, bạn sẽ cần tìm xung đột trong chính HMAC-MD5, điều này có thể không khả thi vào năm 2023, ngay cả khi được chính phủ tài trợ gần như không giới hạn, ít nhất là không phải trong vòng đời của phiên mạng mà bạn đang thử Thoả thuận.

Điều gì đã lâu như vậy?

Đến bây giờ, có lẽ bạn đang tự hỏi, giống như chúng tôi, tại sao lỗi này vẫn chưa được phát hiện hoặc ít nhất là chưa được vá trong một thời gian dài như vậy.

Sau khi tất cả, RFC 6151, xuất hiện từ năm 2011 và có tiêu đề nghe có vẻ quan trọng Các cân nhắc về bảo mật được cập nhật cho các thuật toán MD5 Message-Digest và HMAC-MD5, khuyên như sau (nhấn mạnh của chúng tôi, hơn một thập kỷ sau):

Các cuộc tấn công vào HMAC-MD5 dường như không chỉ ra lỗ hổng thực tế khi được sử dụng làm mã xác thực tin nhắn. Do đó, có thể không cần phải loại bỏ HMAC-MD5 khỏi các giao thức hiện có. Tuy nhiên, vì MD5 không được sử dụng cho chữ ký số, cho một thiết kế giao thức mới, không nên bao gồm một ciphersuite với HMAC-MD5.

Tuy nhiên, có vẻ như do phần lớn các nền tảng máy chủ SMB gần đây đã tắt xác thực HMAC-MD5 khi người dùng cố gắng đăng nhập, nên các máy khách SMB vẫn hỗ trợ chế độ không an toàn này thường không bao giờ sử dụng nó (và dù sao cũng sẽ không thành công nếu họ đã thử).

Các khách hàng dường như được “bảo vệ” hoàn toàn và mã không an toàn dường như cũng vô hại, bởi vì xác thực yếu không cần thiết cũng như không được sử dụng.

Vì vậy, vấn đề tiềm ẩn đơn giản là không bao giờ nhận được sự quan tâm xứng đáng.

Thật không may, loại “bảo mật theo giả định” này sẽ thất bại hoàn toàn nếu bạn tình cờ gặp (hoặc bị thu hút bởi) một máy chủ chấp nhận sự không an toàn này chksum() thuật toán trong quá trình đăng nhập.

Loại “vấn đề hạ cấp” này không phải là mới: vào năm 2015, các nhà nghiên cứu đã nghĩ ra Freak và NHẬT KÝ các cuộc tấn công cố tình lừa các khách hàng của mạng sử dụng cái gọi là mật mã XUẤT KHẨU, là chế độ mã hóa bị làm yếu đi một cách có chủ ý mà chính phủ Hoa Kỳ đã nhấn mạnh một cách kỳ lạ theo luật vào thế kỷ trước.

Như chúng tôi đã viết hồi đó:

Độ dài khóa EXPORT được chọn là gần như có thể bẻ khóa được vào những năm 1990, nhưng chưa bao giờ được mở rộng để theo kịp những tiến bộ về tốc độ của bộ xử lý.

Đó là bởi vì mật mã xuất khẩu đã bị Hoa Kỳ từ bỏ vào khoảng năm 2000.

Ngay từ đầu, chúng đã là một ý tưởng ngớ ngẩn: Các công ty Mỹ chỉ nhập khẩu phần mềm mật mã không có hạn chế xuất khẩu và gây tổn hại cho ngành công nghiệp phần mềm của chính họ.

Tất nhiên, một khi các nhà làm luật nhượng bộ, các bộ mật mã XUẤT KHẨU trở nên thừa, vì vậy mọi người ngừng sử dụng chúng.

Đáng buồn thay, rất nhiều bộ công cụ mật mã, bao gồm OpenSSL và Microsoft's SChannel, đã giữ lại mã để hỗ trợ chúng, vì vậy bạn (hoặc đáng lo ngại hơn là những kẻ lừa đảo có đầy đủ thông tin) không ngừng sử dụng chúng.

Lần này, thủ phạm chính trong số các máy chủ vẫn sử dụng quy trình MD5-plus-HMAC-MD5 bị hỏng này dường như là phạm vi NetApp, trong đó một số sản phẩm dường như tiếp tục (hoặc đã làm cho đến gần đây) để dựa vào thuật toán rủi ro này.

Do đó, đôi khi bạn vẫn có thể trải qua quá trình đăng nhập mạng dễ bị tổn thương và gặp rủi ro từ CVE-2022-38023 mà có thể bạn không hề nhận ra.

Phải làm gì?

Lỗi này cuối cùng đã được xử lý, ít nhất là theo mặc định, trong bản phát hành Samba mới nhất.

Đơn giản chỉ cần đặt, Phiên bản Samba 4.17.5 bây giờ buộc hai tùy chọn reject md5 clients = yes và reject md5 servers = yes.

Điều này có nghĩa là bất kỳ thành phần mật mã nào trong các giao thức mạng SMB khác nhau có liên quan đến thuật toán MD5 (ngay cả khi chúng an toàn về mặt lý thuyết, như HMAC-MD5), đều được bị cấm theo mặc định.

Nếu thực sự cần, bạn có thể bật lại chúng để truy cập các máy chủ cụ thể trong mạng của mình.

Chỉ cần đảm bảo rằng, nếu bạn tạo ra các ngoại lệ mà các tiêu chuẩn internet đã chính thức khuyến nghị trong hơn một thập kỷ…

…rằng bạn đã đặt cho mình một ngày mà cuối cùng bạn sẽ loại bỏ vĩnh viễn các tùy chọn không mặc định đó!

Các cuộc tấn công bằng mật mã ngày càng trở nên thông minh hơn và nhanh hơn, vì vậy đừng bao giờ dựa vào các giao thức và thuật toán lỗi thời chỉ đơn giản là “không được sử dụng nữa”.

Loại bỏ chúng hoàn toàn khỏi mã của bạn, bởi vì nếu chúng hoàn toàn không có ở đó, bạn KHÔNG THỂ sử dụng chúng và bạn không thể bị lừa sử dụng chúng bởi một người nào đó đang cố dụ bạn vào tình trạng bất an.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• Platoblockchain. Web3 Metaverse Intelligence. Khuếch đại kiến ​​thức. Truy cập Tại đây.
• nguồn: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/