S3 Ep108: Bạn đã giấu BA TỶ đô la trong một hộp bỏng ngô?

Nhấp và kéo vào các sóng âm thanh bên dưới để chuyển đến bất kỳ điểm nào. Bạn cũng có thể nghe trực tiếp trên Soundcloud.

CHÓ.  Lừa đảo Twitter, Patch Tuesday, và bọn tội phạm hack.

Tất cả những điều đó và hơn thế nữa trên podcast Naked Security.

[CHẾ ĐỘ ÂM NHẠC]

Chào mừng mọi người đến với podcast.

Tôi là Doug.

Anh ấy là Paul Ducklin.

Paul, hôm nay bạn thế nào?

---

VỊT.  Tốt lắm, Doug.

Ở Anh, chúng tôi không có nguyệt thực, nhưng tôi đã nhìn thoáng qua mặt trăng tròn *tròn* qua một lỗ nhỏ trên các đám mây, lỗ hổng duy nhất trong toàn bộ lớp mây vào thời điểm tôi đi ra ngoài để có một cái nhìn!

Nhưng chúng tôi không có mặt trăng màu cam như các bạn đã làm ở Massachusetts.

---

CHÓ.  Hãy để chúng tôi bắt đầu chương trình với Tuần này trong Lịch sử Công nghệ… điều này quay trở lại.

Tuần này, vào ngày 08 tháng 1895 năm XNUMX, giáo sư vật lý người Đức Wilhelm Röntgen tình cờ phát hiện ra một dạng bức xạ chưa được khám phá khiến ông gọi bức xạ nói trên đơn giản là “X”.

Như trong X-quang.

Còn về điều đó thì sao… việc tình cờ phát hiện ra tia X?

---

VỊT.  Khá tuyệt.

Tôi nhớ mẹ tôi đã nói với tôi: vào những năm 1950 (chắc ở Hoa Kỳ cũng vậy), rõ ràng, trong các cửa hàng giày…

---

CHÓ.  [Biết ĐIỀU GÌ SẮP TỚI] Vâng! [CƯỜI]

---

VỊT.  Mọi người sẽ đưa con cái của họ vào… bạn sẽ đứng trong chiếc máy này, đi giày vào và thay vì chỉ nói: “Đi lại xem, chúng có chật không? Chúng có bị véo không?”, bạn đứng trong một chiếc máy X-quang, về cơ bản nó chỉ tắm cho bạn trong bức xạ tia X và chụp một bức ảnh trực tiếp và nói, “Ồ vâng, chúng có kích thước phù hợp.”

---

CHÓ.  Vâng, thời gian đơn giản hơn. Một chút nguy hiểm, nhưng…

---

VỊT.  MỘT CHÚT NGUY HIỂM?

Bạn có thể tưởng tượng những người làm việc trong các cửa hàng giày?

Chắc hẳn họ đã tắm trong tia X mọi lúc.

---

CHÓ.  Hoàn toàn… tốt, hôm nay chúng ta an toàn hơn một chút.

Và về chủ đề an toàn, Thứ Ba đầu tiên của tháng là Thứ Ba Bản vá của Microsoft.

So chúng ta đã học được gì Bản vá này vào Thứ Ba tại đây vào tháng 2022 năm XNUMX?

Đổi trả cố định 0 ngày (cuối cùng) - cộng với 4 bản vá thứ Ba hoàn toàn mới 0 ngày!

---

VỊT.  Chà, điều cực kỳ thú vị, Doug, là về mặt kỹ thuật, Bản vá Thứ Ba đã sửa không phải một, không phải hai, không phải ba… mà là *bốn* số không ngày.

Nhưng trên thực tế, các bản vá mà bạn có thể nhận được cho các sản phẩm của Microsoft vào thứ Ba đã sửa lỗi *sáu* XNUMX ngày.

Hãy nhớ lại những lỗi zero-day của Exchange nổi tiếng là không được vá Bản vá Thứ Ba tuần trước: CVE-2002-41040 và CVE-2022-41082, cái được gọi là ProxyKhông Vỏ?

S3 Ep102.5: Lỗi trao đổi “ProxyNotShell” - một chuyên gia nói [Âm thanh + Văn bản]

Chà, những cái đó đã được sửa, nhưng về cơ bản là một “bên lề” riêng biệt cho Bản vá thứ Ba: Exchange tháng 2022 năm XNUMX SU, hoặc Bản cập nhật phần mềm, chỉ nói rằng:

Bản cập nhật phần mềm Exchange tháng 2022 năm 29 chứa các bản sửa lỗi cho lỗ hổng zero-day được báo cáo công khai vào ngày 2022 tháng XNUMX năm XNUMX.

Tất cả những gì bạn phải làm là nâng cấp Exchange.

Chà, cảm ơn Microsoft… Tôi nghĩ rằng chúng tôi biết rằng đó là những gì chúng tôi sẽ phải làm khi các bản vá lỗi cuối cùng đã xuất hiện!

Vì vậy, chúng * đã * hết và có hai ngày không cố định, nhưng chúng không phải là những cái mới và về mặt kỹ thuật, chúng không nằm trong phần “Bản vá thứ ba”.

Ở đó, chúng tôi có bốn ngày không cố định khác.

Và nếu bạn tin vào việc ưu tiên các bản vá, thì rõ ràng đó là những thứ bạn muốn giải quyết trước tiên, bởi vì ai đó đã biết cách làm những điều tồi tệ với chúng.

Những phạm vi đó từ bỏ qua bảo mật, đến hai lần nâng cao đặc quyền và một lần thực thi mã từ xa.

Nhưng có nhiều hơn tổng cộng 60 bản vá lỗivà nếu bạn nhìn vào danh sách tổng thể các sản phẩm và cấu phần Windows bị ảnh hưởng, thì sẽ có một danh sách khổng lồ, như thường lệ, bao gồm mọi thành phần/sản phẩm Windows mà bạn đã nghe nói đến và nhiều sản phẩm mà bạn có thể chưa biết.

Microsoft vá 62 lỗ hổng bảo mật, bao gồm Kerberos, Mark of the Web và Exchange… loại

Vì vậy, như mọi khi: Đừng trì hoãn/Hãy làm ngay hôm nay, Douglas!

---

CHÓ.  Rất tốt.

Bây giờ chúng ta hãy nói về một sự chậm trễ…

Bạn có một câu chuyện rất thú vị về Chợ ma túy Con đường tơ lụa, và một lời nhắc nhở rằng tội phạm ăn cắp của bọn tội phạm vẫn là một tội ác, ngay cả khi bạn thực sự bị bắt sau đó mười năm.

Hacker thị trường ma túy Silk Road nhận tội, đối mặt 20 năm tù

---

VỊT.  Vâng, ngay cả những người còn khá mới đối với an ninh mạng hoặc truy cập trực tuyến có thể đã nghe nói về “Con đường tơ lụa”, có lẽ là thị trường dark web nổi tiếng, lâu đời, phổ biến và được sử dụng rộng rãi đầu tiên, nơi về cơ bản mọi thứ đều diễn ra.

Vì vậy, tất cả đã bùng cháy vào năm 2013.

Bởi vì người sáng lập, ban đầu chỉ được biết đến với cái tên Cướp biển đáng sợ Roberts, nhưng cuối cùng được tiết lộ là Ross Ulbricht… an ninh hoạt động kém của anh ấy đủ để ràng buộc các hoạt động với anh ấy.

Người sáng lập Con đường tơ lụa Ross Ulbricht nhận được chung thân mà không cần ân xá

Không chỉ bảo mật hoạt động của anh ấy không tốt lắm, có vẻ như vào cuối năm 2012, họ đã mắc phải (bạn có tin được không, Doug?) Một lỗi xử lý thanh toán tiền điện tử…

---

CHÓ.  [GASPS TRONG MOCK HORROR]

---

VỊT.  … thuộc loại mà chúng tôi đã thấy lặp đi lặp lại nhiều lần kể từ đó, loại hình này không hoàn toàn thực hiện kế toán ghi sổ kép phù hợp, trong đó đối với mỗi khoản nợ, có một khoản tín dụng tương ứng và ngược lại.

Và kẻ tấn công này đã phát hiện ra, nếu bạn bỏ một số tiền vào tài khoản của mình và sau đó nhanh chóng thanh toán số tiền đó cho các tài khoản khác, thì bạn thực sự có thể thanh toán gấp năm lần (hoặc thậm chí nhiều hơn) cùng một số bitcoin trước khi hệ thống nhận ra rằng khoản ghi nợ đầu tiên đã biến mất xuyên qua.

Vì vậy, về cơ bản, bạn có thể bỏ vào một số tiền và sau đó chỉ cần rút đi rút lại nhiều lần và nhận được một khoản tiền lớn hơn…

…và sau đó bạn có thể quay trở lại cái mà bạn có thể gọi là “vòng vắt sữa tiền điện tử”.

Và người ta ước tính… các nhà điều tra không chắc chắn rằng anh ấy đã bắt đầu với khoảng 200 đến 2000 bitcoin của riêng mình (cho dù anh ấy đã mua hay khai thác chúng, chúng tôi không biết), và anh ấy đã rất, rất nhanh chóng biến chúng thành, chờ đã, Doug: 50,0000 bitcoin!

---

CHÓ.  Wow!

---

VỊT.  Hơn 50,000 bitcoin, chỉ vậy thôi.

Và sau đó, rõ ràng là biết rằng ai đó sẽ chú ý, anh ta đã bỏ chạy trong khi dẫn trước 50,000 bitcoin…

…mỗi chiếc trị giá 12 đô la đáng kinh ngạc, tăng từ phần nhỏ của một xu chỉ vài năm trước. [CƯỜI]

Vì vậy, anh ta đã kiếm được 600,000 đô la, chỉ như vậy thôi, Doug.

[TẠM DỪNG KỊCH]

Chín năm sau…

[CON GÁI]

…gần *chính xác* chín năm sau, khi anh ta bị bắt và nhà của anh ta bị khám xét theo lệnh, cảnh sát đã lục soát và tìm thấy một đống chăn trong tủ của anh ta, bên dưới có giấu một hộp bỏng ngô.

Nơi kỳ lạ để giữ bỏng ngô của bạn.

Bên trong đó là một loại ví lạnh được vi tính hóa.

Bên trong đó là một tỷ lệ lớn bitcoin đã nói!

Vào thời điểm anh ta bị bắt, bitcoin có giá khoảng 65,535 USD (hoặc 2¹⁶-1) mỗi cái.

Họ đã tăng lên hơn một nghìn lần trong thời gian tạm thời.

Vì vậy, vào thời điểm đó, nó là vụ phá sản tiền điện tử lớn nhất từ ​​​​trước đến nay!

Chín năm sau, rõ ràng là không thể vứt bỏ những món lợi bất chính của mình, có lẽ sợ rằng dù có cố nhét chúng vào một cái cốc, mọi ngón tay cũng sẽ chỉ về phía mình…

…anh ấy đã có tất cả số bitcoin trị giá 3 tỷ đô la này đã nằm trong hộp bỏng ngô trong chín năm!

---

CHÓ.  Trời ơi.

---

VỊT.  Vì vậy, sau nhiều năm ngồi trên kho báu đáng sợ này, tự hỏi liệu mình có bị bắt hay không, giờ đây anh ấy lại tự hỏi: “Tôi sẽ phải ngồi tù bao lâu?”

Và mức án tối đa cho tội danh mà anh ta phải đối mặt?

20 năm, Doug.

---

CHÓ.  Một câu chuyện thú vị khác đang diễn ra ngay bây giờ. Nếu bạn đã sử dụng Twitter gần đây, bạn sẽ biết rằng có rất nhiều hoạt động. để nói điều đó một cách ngoại giao ...

---

VỊT.  [MẠO HÌNH BOB DYLAN CHẤT LƯỢNG THẤP ĐẾN TRUNG BÌNH] Chà, thời thế, chúng đang thay đổi.

---

CHÓ.  …bao gồm tại một thời điểm ý tưởng tính phí 20 đô la cho một tấm séc xanh đã được xác minh, tất nhiên, điều này gần như ngay lập tức nhắc nhở một số lừa đảo.

Lừa đảo qua email Twitter Blue Badge - Đừng để lọt chúng!

---

VỊT.  Đó chỉ là một lời nhắc nhở, Doug, rằng bất cứ khi nào có thứ gì đó thu hút được nhiều sự quan tâm, những kẻ lừa đảo chắc chắn sẽ theo dõi.

Và tiền đề của việc này là, “Này, tại sao không vào sớm? Nếu bạn đã có một dấu màu xanh, hãy đoán xem? Bạn sẽ không phải trả 19.99 đô la một tháng nếu đăng ký trước. Chúng tôi sẽ để bạn giữ nó.”

Chúng tôi biết rằng đó không phải là ý tưởng của Elon Musk, như anh ấy đã nói, nhưng đó là điều mà nhiều doanh nghiệp làm, phải không?

Rất nhiều công ty sẽ cung cấp cho bạn một số lợi ích nếu bạn ở lại với dịch vụ.

Vì vậy, nó không hoàn toàn khó tin.

Như bạn nói… bạn đã cho nó cái gì?

B-trừ, phải không?

---

CHÓ.  Tôi cho điểm B-trừ email đầu tiên… bạn có thể bị lừa nếu đọc nhanh, nhưng có một số vấn đề về ngữ pháp; những thứ không cảm thấy đúng.

Và sau đó khi bạn nhấp qua, tôi sẽ trừ C cho các trang đích.

Điều đó thậm chí còn khó khăn hơn.

---

VỊT.  Đó là một nơi nào đó giữa 5/10 và 6/10?

---

CHÓ.  Vâng, hãy nói điều đó.

Và chúng tôi có một số lời khuyên, để ngay cả khi đó là một trò lừa đảo hạng A, thì điều đó cũng không thành vấn đề vì bạn sẽ có thể ngăn chặn nó!

Bắt đầu với yêu thích cá nhân của tôi: Sử dụng trình quản lý mật khẩu.

Trình quản lý mật khẩu giải quyết được rất nhiều vấn đề liên quan đến lừa đảo.

---

VỊT.  Nó làm.

Trình quản lý mật khẩu không có bất kỳ trí thông minh giống con người nào có thể bị đánh lừa bởi thực tế là hình ảnh đẹp là đúng, hoặc logo hoàn hảo hoặc biểu mẫu web ở đúng vị trí trên màn hình với cùng một phông chữ , vì vậy bạn nhận ra nó.

Tất cả những gì nó biết là: “Chưa bao giờ nghe nói về trang web này trước đây.”

---

CHÓ.  Và dĩ nhiên, bật 2FA nếu bạn có thể.

Luôn thêm yếu tố xác thực thứ hai nếu có thể.

---

VỊT.  Tất nhiên, điều đó không nhất thiết bảo vệ bạn khỏi chính bạn.

Nếu bạn truy cập một trang web giả mạo và bạn đã quyết định, “Này, nó hoàn hảo đến từng pixel, nó phải là hàng thật”, và bạn quyết tâm đăng nhập, đồng thời bạn đã nhập tên người dùng và mật khẩu của mình, và sau đó nó yêu cầu bạn thực hiện quy trình 2FA…

…bạn rất có khả năng làm điều đó.

Tuy nhiên, nó cho bạn một chút thời gian để thực hiện “Dừng lại. Nghĩ. Liên kết." và tự nhủ: “Đợi đã, mình đang làm gì ở đây?”

Vì vậy, theo một cách nào đó, một chút chậm trễ mà 2FA mang lại thực sự có thể không chỉ gây ra rất ít rắc rối mà còn là một cách thực sự cải thiện quy trình làm việc an ninh mạng của bạn… nghiêm túc hơn một chút.

Vì vậy, tôi không thấy nhược điểm là gì, thực sự.

---

CHÓ.  Và tất nhiên, một chiến lược khác mà nhiều người khó tuân theo, nhưng lại rất hiệu quả, đó là tránh các liên kết đăng nhập và các nút hành động trong email.

Vì vậy, nếu bạn nhận được một email, đừng chỉ nhấp vào nút… hãy truy cập vào chính trang web đó và bạn sẽ có thể nhanh chóng biết được email đó có hợp pháp hay không.

---

VỊT.  Về cơ bản, nếu bạn không thể hoàn toàn tin tưởng vào thư từ ban đầu, thì bạn không thể dựa vào bất kỳ chi tiết nào trong đó, cho dù đó là liên kết bạn sẽ nhấp vào, số điện thoại bạn sẽ gọi, địa chỉ email bạn sẽ gửi. Bạn sẽ liên hệ với họ trên , tài khoản Instagram mà bạn sẽ gửi tin nhắn trực tiếp tới, bất kể đó là tài khoản gì.

Đừng sử dụng những gì có trong email… hãy tự tìm đường đến đó và bạn sẽ dễ dàng gặp phải rất nhiều trò lừa đảo kiểu này.

---

CHÓ.  Và cuối cùng, cuối cùng nhưng không kém phần quan trọng… điều này là lẽ thường tình, nhưng không phải vậy: Đừng bao giờ hỏi người gửi một tin nhắn không chắc chắn xem chúng có hợp pháp hay không.

Đừng trả lời và nói, “Này, bạn có thực sự là Twitter không?”

---

VỊT.  Vâng, bạn hoàn toàn đúng.

Bởi vì lời khuyên trước đây của tôi, “Đừng dựa vào thông tin trong email”, chẳng hạn như đừng gọi vào số điện thoại của họ… một số người bị dụ đi, “Tôi sẽ gọi vào số điện thoại đó và xem nó có thực sự không. là họ. [IRONIC] Bởi vì, rõ ràng, nếu đầu bếp trả lời, họ sẽ đưa ra tên thật của mình.

---

CHÓ.  Như chúng ta luôn nói: Nếu nghi ngờ / Đừng đưa ra.

Và đây là một câu chuyện cảnh báo tốt, câu chuyện tiếp theo: khi quét an ninh, là những công cụ bảo mật hợp pháp, tiết lộ nhiều hơn họ nên, điều gì xảy ra sau đó?

Công cụ quét URL công khai - khi bảo mật dẫn đến mất an toàn

---

VỊT.  Đây là một nhà nghiên cứu nổi tiếng tên là Fabian Bräunlein ở Đức… chúng tôi đã giới thiệu anh ấy một vài lần trước đây.

Anh ấy trở lại với một báo cáo chi tiết có tựa đề urlscan.io's SOAR spot: các công cụ bảo mật trò chuyện làm rò rỉ dữ liệu riêng tư.

Và trong trường hợp này, đó là urlscan.io, một trang web mà bạn có thể sử dụng miễn phí (hoặc dưới dạng dịch vụ trả phí), nơi bạn có thể gửi URL, tên miền hoặc số IP hoặc bất kỳ thứ gì và bạn có thể tra cứu, “Cộng đồng biết gì về điều này?”

Và nó sẽ tiết lộ URL đầy đủ mà những người khác đã hỏi.

Và đây không chỉ là những thứ mà mọi người sao chép và dán theo lựa chọn của riêng họ.

Ví dụ, đôi khi, email của họ có thể đang đi qua một công cụ lọc của bên thứ ba, công cụ này tự trích xuất các URL, gọi về nhà urlscan.io, thực hiện tìm kiếm, nhận kết quả và sử dụng kết quả đó để quyết định nên gửi thư rác, chặn thư rác hay chuyển qua thư.

Và điều đó có nghĩa là đôi khi, nếu URL bao gồm dữ liệu bí mật hoặc bán bí mật, thông tin nhận dạng cá nhân, thì những người khác tình cờ tìm kiếm đúng tên miền trong một khoảng thời gian ngắn sau đó sẽ thấy tất cả các URL được tìm kiếm, bao gồm cả những thứ có thể có trong URL.

Bạn biết đấy, như blahblah?username=doug&passwordresetcode= theo sau là một chuỗi ký tự thập lục phân dài, v.v.

Và Bräunlein đã đưa ra một danh sách hấp dẫn về các loại URL, đặc biệt là những URL có thể xuất hiện trong email, có thể thường xuyên được gửi cho bên thứ ba để lọc và sau đó được lập chỉ mục để tìm kiếm.

Các loại email mà anh ấy cho rằng chắc chắn có thể khai thác bao gồm, nhưng không giới hạn ở: liên kết tạo tài khoản; liên kết chuyển phát quà tặng Amazon; khóa API; Yêu cầu ký kết DocuSign; chuyển tập tin dropbox; theo dõi gói; đặt lại mật khẩu; hóa đơn PayPal; chia sẻ tài liệu Google Drive; Lời mời SharePoint; và các liên kết hủy đăng ký bản tin.

Không chỉ tay vào SharePoint, Google Drive, PayPal, v.v.

Đó chỉ là những ví dụ về các URL mà anh ấy đã tìm thấy có khả năng bị khai thác theo cách này.

---

CHÓ.  Chúng tôi có một số lời khuyên ở cuối bài viết đó, tóm lại là: hãy đọc báo cáo của Bräunlein; đọc urlscan.iobài đăng trên blog của ; thực hiện đánh giá mã của riêng bạn; nếu bạn có mã thực hiện tra cứu bảo mật trực tuyến; tìm hiểu những tính năng bảo mật nào tồn tại để gửi trực tuyến; và quan trọng là tìm hiểu cách báo cáo dữ liệu giả mạo cho một dịch vụ trực tuyến nếu bạn nhìn thấy nó.

Tôi nhận thấy có ba… loại vôi?

Những bài thơ nhỏ rất sáng tạo ở cuối bài viết này…

---

VỊT.  [MOCK HORROR] Không, chúng không phải là những con bọ chanh! Limericks có cấu trúc năm dòng rất trang trọng…

---

CHÓ.  [CƯA] Tôi rất xin lỗi. Đúng!

---

VỊT.  …cho cả nhịp và vần.

Rất có cấu trúc, Doug!

---

CHÓ.  Tôi rất xin lỗi, rất đúng. [CƯỜI]

---

VỊT.  Đây chỉ là dogerel. [CƯỜI]

Một lần nữa: Nếu nghi ngờ / Đừng đưa ra.

Và nếu bạn đang thu thập dữ liệu: Nếu nó không được trong / Dính thẳng vào thùng.

Và nếu bạn đang viết mã gọi các API công khai có thể tiết lộ dữ liệu khách hàng: Đừng bao giờ làm người dùng của bạn khóc/Bằng cách bạn gọi API.

---

CHÓ.  [CƯỜI] Đó là một cái mới đối với tôi, và tôi rất thích cái đó!

Và cuối cùng, nhưng chắc chắn không kém phần quan trọng trong danh sách của chúng tôi ở đây, chúng tôi đã nói chuyện hàng tuần về lỗi bảo mật OpenSSL này.

Câu hỏi lớn bây giờ là, “Làm thế nào bạn có thể nói cần sửa cái gì?”

Câu chuyện cập nhật bảo mật OpenSSL - làm thế nào bạn có thể cho biết những gì cần sửa chữa?

---

VỊT.  Thật vậy, Doug, làm cách nào để chúng tôi biết chúng tôi có phiên bản OpenSSL nào?

Và rõ ràng, trên Linux, bạn chỉ cần mở một dấu nhắc lệnh và gõ openssl version, và nó cho bạn biết phiên bản mà bạn có.

Nhưng OpenSSL là một thư viện lập trình và không có quy tắc nào nói rằng phần mềm không được có phiên bản riêng.

Bản phân phối của bạn có thể sử dụng OpenSSL 3.0, nhưng vẫn có ứng dụng cho biết: “Ồ, không, chúng tôi chưa nâng cấp lên phiên bản mới. Chúng tôi thích OpenSSL 1.1.1 hơn, vì nó vẫn được hỗ trợ và trong trường hợp bạn không có nó, chúng tôi sẽ mang đến phiên bản của riêng mình.”

Và thật không may, giống như trong trường hợp Log4Shell khét tiếng đó, bạn phải đi tìm cả ba? 12? 154? biết bao nhiêu địa điểm trên mạng của bạn, nơi bạn có thể có chương trình Log4J đã lỗi thời.

Tương tự cho OpenSSL.

Về lý thuyết, các công cụ XDR hoặc EDR có thể cho bạn biết, nhưng một số sẽ không hỗ trợ điều này và nhiều công cụ sẽ không khuyến khích: thực sự chạy chương trình để tìm hiểu xem đó là phiên bản nào.

Bởi vì, xét cho cùng, nếu đó là lỗi hoặc sai, và bạn thực sự phải chạy chương trình để nó báo cáo phiên bản của chính nó…

…cảm giác đó giống như đặt xe trước ngựa, phải không?

Vì vậy, chúng tôi đã xuất bản một bài báo dành cho những trường hợp đặc biệt mà bạn thực sự muốn tải DLL hoặc thư viện dùng chung và bạn thực sự muốn gọi thư viện của riêng mình TellMeThyVersion() mã phần mềm.

Nói cách khác, bạn đủ tin tưởng vào chương trình để tải vào bộ nhớ, thực thi nó và chạy một số thành phần của nó.

Chúng tôi chỉ cho bạn cách thực hiện điều đó để bạn có thể hoàn toàn chắc chắn rằng mọi tệp OpenSSL bên ngoài mà bạn có trên mạng của mình đều được cập nhật.

Bởi vì mặc dù điều này đã bị hạ cấp từ CRITICAL xuống CAO, nhưng nó vẫn là một lỗi mà bạn cần và muốn sửa!

---

CHÓ.  Về chủ đề mức độ nghiêm trọng của lỗi này, chúng tôi đã nhận được một câu hỏi thú vị từ người đọc bảo mật khỏa thân Svet, người viết, một phần:

Làm thế nào mà một lỗi cực kỳ phức tạp để khai thác và chỉ có thể được sử dụng cho các cuộc tấn công từ chối dịch vụ, lại tiếp tục được phân loại là CAO?

---

VỊT.  Vâng, tôi nghĩ anh ấy đã nói điều gì đó về, “Ồ, nhóm OpenSL chưa nghe nói về CVSS sao?”, đó là một tiêu chuẩn của chính phủ Hoa Kỳ, nếu bạn thích, để mã hóa mức độ rủi ro và phức tạp của lỗi theo cách có thể được lọc tự động bởi tập lệnh.

Vì vậy, nếu nó có điểm CVSS thấp (là Hệ thống chấm điểm dễ bị tổn thương phổ biến), tại sao mọi người lại hào hứng với nó?

Tại sao phải CAO?

Và vì vậy câu trả lời của tôi là, “Tại sao *không nên* nó ở mức CAO?”

Đó là một lỗi trong công cụ mật mã; nó có thể làm hỏng một chương trình, chẳng hạn như chương trình đang cố tải bản cập nhật… vì vậy nó sẽ gặp sự cố hết lần này đến lần khác, điều này không chỉ đơn thuần là từ chối dịch vụ, bởi vì nó thực sự ngăn cản bạn thực hiện bảo mật đúng cách.

Có một yếu tố bỏ qua bảo mật.

Và tôi nghĩ phần khác của câu trả lời là, khi nói đến việc các lỗ hổng bị biến thành khai thác: “Đừng bao giờ nói không bao giờ!”

Khi bạn có thứ gì đó giống như tràn bộ đệm ngăn xếp, nơi bạn có thể thao tác với các biến khác trên ngăn xếp, có thể bao gồm cả địa chỉ bộ nhớ, thì luôn có khả năng ai đó có thể tìm ra cách khai thác khả thi.

Và vấn đề, Doug, là một khi họ đã tìm ra nó, thì việc tìm ra nó có phức tạp đến đâu không quan trọng…

…một khi bạn biết cách khai thác nó, *bất kỳ ai* cũng có thể làm được, bởi vì bạn có thể bán cho họ mã để làm như vậy.

Tôi nghĩ bạn biết tôi sẽ nói gì: “Không phải là tôi cảm thấy mạnh mẽ về điều đó.”

[CON GÁI]

Một lần nữa, nó lại là một trong những thứ “nếu có thì chết tiệt, nếu không thì chết tiệt”.

---

CHÓ.  Rất tốt, Cảm ơn bạn rất nhiều, Svet, đã viết nhận xét đó và gửi nó.

Nếu bạn có một câu chuyện, nhận xét hoặc câu hỏi thú vị mà bạn muốn gửi, chúng tôi rất muốn đọc nó trên podcast.

Bạn có thể gửi email tới tips@sophos.com, bạn có thể nhận xét về bất kỳ bài viết nào của chúng tôi hoặc bạn có thể đánh giá chúng tôi trên mạng xã hội: @nakedsecurity.

Đó là chương trình của chúng tôi cho ngày hôm nay; cảm ơn rất nhiều vì đã lắng nghe

Đối với Paul Ducklin, tôi là Doug Aamoth, sẽ nhắc bạn cho đến lần sau hãy…

---

CẢ HAI.  Giữ an toàn!