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Ó.  Vá lỗi, hack Reddit và những ngày đầu của máy tính.

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 Aamoth.

Anh ấy là Paul Ducklin.

Paul, bạn làm thế nào?

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

CHÓ.  Được rồi, tôi có một điều thú vị Tuần này trong Lịch sử Công nghệ phân khúc cho bạn ngày hôm nay.

Nếu đây là một nơi trên thế giới, thì đó sẽ là Rome, nơi mọi nền văn minh bắt đầu.

Sắp xếp.

Nó có thể tranh cãi.

Dù sao đi nữa…

VỊT.  Vâng, đó chắc chắn là tranh cãi! [CƯỜI]

CHÓ.  [CƯỜI] Tuần này, vào ngày 14 tháng 1946 năm XNUMX, ENIAC, hay Máy tính và Tích hợp Số Điện tử, đã được công bố.

Là một trong những máy tính đa năng điện tử sớm nhất, ENIAC lấp đầy toàn bộ căn phòng, nặng 30 tấn và chứa 18,000 ống chân không, 70,000 điện trở, 10,000 tụ điện và khoảng 5 triệu mối hàn bằng tay.

ENIAC được sử dụng cho nhiều tính toán khác nhau, bao gồm quỹ đạo đạn pháo, dự đoán thời tiết và nghiên cứu vũ khí nhiệt hạch.

Nó đã mở đường cho các máy tính điện tử khả thi về mặt thương mại, Paul.

VỊT.  Vâng, nó đã làm!

Tất nhiên, điều trớ trêu lớn nhất là người Anh chúng tôi đã đến đó trước, với pho tượng trong Thế chiến thứ hai, tại Bletchley Park.

Và sau đó, trước sự khôn ngoan đáng kinh ngạc của chính phủ, chúng tôi quyết định: [A] đập tất cả chúng thành từng mảnh nhỏ, [B] đốt tất cả tài liệu ([THIẾT LỆ] mặc dù một số còn sót lại), và [C] giữ nguyên sự thật rằng chúng tôi đã sử dụng các van nhiệt điện tử để xây dựng bí mật máy tính kỹ thuật số điện tử nhanh.

[TẠM DỪNG] Thật là một điều ngớ ngẩn để làm… [CƯỜI]

Colossus – máy tính kỹ thuật số điện tử đầu tiên

CHÓ.  [TUYỆT VỜI] Tại sao họ lại làm vậy?

VỊT.  [TRAGIC] Aaaaargh, tôi không biết.

Ở Mỹ, tôi tin rằng, vào thời điểm ENIAC, vẫn chưa rõ liệu rơle điện cơ hay van nhiệt điện tử (ống chân không) sẽ thắng thế, bởi vì ống chân không nhanh hơn hàng tỷ lần…

…nhưng chúng rất nóng, chúng sử dụng một lượng lớn năng lượng và chúng có xu hướng thổi ngẫu nhiên, khiến máy tính ngừng hoạt động, v.v., v.v.

Nhưng tôi nghĩ chính ENIAC cuối cùng đã định đoạt số phận của tất cả các máy tính cơ điện.

CHÓ.  Nói về những thứ đã tồn tại được một thời gian…

..Reddit nói rằng nó đã bị hack nhờ một phương pháp tinh vi Tấn công lừa đảo điều đó, hóa ra, không quá phức tạp.

Trớ trêu thay, đó có thể là lý do nó hoạt động rất tốt.

Reddit thừa nhận nó đã bị hack và đánh cắp dữ liệu, nói “Đừng hoảng sợ”

VỊT.  [CƯỜI] Tôi rất vui vì bạn đã nói điều đó chứ không phải tôi, Doug!

Nhưng, vâng, tôi nghĩ bạn đúng.

Tại sao rất nhiều giám đốc điều hành cấp cao viết thông báo vi phạm lại cảm thấy bắt buộc phải thêm từ “tinh vi” vào đó? [CƯỜI]

Toàn bộ vấn đề về các cuộc tấn công lừa đảo là chúng *không* tinh vi.

Chúng *không phải là* thứ gì đó có thể tự động gióng lên hồi chuông cảnh báo.

CHÓ.  Reddit nói:

Như trong hầu hết các chiến dịch lừa đảo, kẻ tấn công đã gửi lời nhắc nghe có vẻ hợp lý hướng nhân viên đến một trang web sao chép hành vi của cổng mạng nội bộ của chúng tôi nhằm đánh cắp thông tin đăng nhập và mã thông báo yếu tố thứ hai. Sau khi lấy thành công thông tin đăng nhập của một nhân viên, kẻ tấn công đã có quyền truy cập vào tài liệu nội bộ, mã…

Vì vậy, đó là nơi nó trở nên đơn giản: lừa một người nhấp vào liên kết, được đưa đến một trang giống như một trong các hệ thống của bạn và chuyển giao mã 2FA.

VỊT.  Và sau đó họ có thể nhảy vào, lấy đồ và ra ngoài.

Và như vậy, giống như trong Vi phạm LastPass và gần đây vi phạm GitHub, mã nguồn đã bị đánh cắp, cùng với một số nội dung khác.

Mặc dù đó là một dấu hiệu tốt, vì nội dung của Reddit đã bị đánh cắp chứ không phải nội dung của người dùng (vì vậy đó là vấn đề của họ để vật lộn, nếu bạn hiểu ý tôi)… chúng tôi biết rằng trong số những nội dung đó, ngay cả khi bạn chỉ nhận được mã nguồn, chưa nói đến tài liệu nội bộ, có thể có các gợi ý, tập lệnh, mã thông báo, tên máy chủ, điểm cuối API RESTy, v.v. mà kẻ tấn công có thể sử dụng sau này.

Nhưng có vẻ như bản thân dịch vụ Reddit, hay nói cách khác là cơ sở hạ tầng đằng sau dịch vụ, không bị ảnh hưởng trực tiếp bởi điều này.

Vì vậy, kẻ gian đã vào và lấy một số thứ rồi thoát ra chứ không có chuyện đột nhập vào mạng rồi lang thang khắp nơi.

CHÓ.  Reddit đưa ra ba lời khuyên, hai phần ba trong số đó chúng tôi đồng ý.

Chúng tôi đã nói vô số lần trong chương trình trước đây: Bảo vệ chống lừa đảo bằng cách sử dụng trình quản lý mật khẩu, bởi vì nó làm cho việc đặt đúng mật khẩu vào sai trang web trở nên khó khăn hơn.

Bật 2FA nếu bạn có thể, vì vậy bạn có một yếu tố xác thực thứ hai.

Điều này, mặc dù, là lên để tranh luận: Thay đổi mật khẩu của bạn hai tháng một lần.

Đó có thể là một cây cầu quá xa, Paul?

VỊT.  Vâng, Chester Wisniewski và tôi đã làm một Podcast (khi nào? 2012?), nơi chúng tôi phá vỡ huyền thoại đó.

Và NIST, Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ, đồng ý với chúng tôi.

Nó *là* một cây cầu quá xa, bởi vì nó thay đổi vì lợi ích của sự thay đổi.

Và tôi nghĩ rằng có một số vấn đề khi chỉ nói, "Cứ hai tháng một lần, tôi sẽ thay đổi mật khẩu của mình."

Đầu tiên, tại sao phải thay đổi mật khẩu của bạn nếu bạn thực sự không nghĩ rằng có bất kỳ lý do nào để thay đổi?

Bạn chỉ đang lãng phí thời gian của mình – bạn có thể dành thời gian đó để làm điều gì đó giúp cải thiện trực tiếp và thực sự an ninh mạng của mình.

Thứ hai, như Chester đã nói trong đó podcast cũ (mà chúng tôi đã đưa vào bài viết, vì vậy bạn có thể vào và nghe nó), “Nó khiến mọi người có thói quen xấu,” bởi vì bạn đang cố gắng lập trình thái độ của họ đối với mật khẩu thay vì chấp nhận ngẫu nhiên và entropy.

Và, thứ ba, tôi nghĩ nó khiến mọi người nghĩ, “Bạn biết không, tôi nên thay đổi mật khẩu của mình, nhưng dù sao thì tôi cũng sẽ thay đổi tất cả chúng sau sáu tuần nữa, vì vậy tôi sẽ để nó cho đến lúc đó.”

Tôi muốn có một cách tiếp cận nói rằng, "Khi bạn nghĩ rằng bạn cần thay đổi mật khẩu của mình, hãy *làm điều đó trong năm phút*."

ĐÁNH BẠI MẬT KHẨU MẬT KHẨU

Mặc dù chúng tôi đã ghi lại podcast này hơn một thập kỷ trước, nhưng lời khuyên trong đó vẫn còn phù hợp và đáng suy ngẫm cho đến ngày nay. Chúng ta vẫn chưa đạt được tương lai không cần mật khẩu, vì vậy lời khuyên về an ninh mạng liên quan đến mật khẩu sẽ có giá trị trong một thời gian dài. Nghe ở đây, hoặc nhấp qua để xem bảng điểm đầy đủ.

CHÓ.  Có một sự trớ trêu nhất định ở đây với việc khuyến nghị sử dụng trình quản lý mật khẩu…

…khi rõ ràng là nhân viên này sẽ không thể đăng nhập vào trang web giả mạo nếu họ đang sử dụng trình quản lý mật khẩu.

VỊT.  Vâng, bạn sẽ nghĩ như vậy, phải không?

Bởi vì nó sẽ đi, "Chưa bao giờ nghe nói về trang web, không thể làm điều đó, không có mật khẩu."

Và bạn sẽ nói, "Nhưng nó có vẻ rất đúng."

Máy tính: “Không, chưa bao giờ nghe nói về nó.”

CHÓ.  Và sau đó, khi bạn đã đăng nhập vào một trang web không có thật, 2FA sẽ không tốt nếu bạn chỉ nhập mã vào một biểu mẫu trên trang web không có thật và được gửi cho kẻ gian!

VỊT.  Nếu bạn định sử dụng 2FA như một cái cớ để bảo mật tùy tiện hơn, thì [A] đừng làm vậy hoặc [B] chọn một hệ thống xác thực hai yếu tố không chỉ dựa vào việc sao chép các chữ số từ tài khoản của bạn. điện thoại vào máy tính xách tay của bạn.

Sử dụng một hệ thống dựa trên mã thông báo như OAuth hoặc một cái gì đó tương tự, tinh vi hơn và hơi khó để kẻ lừa đảo lật đổ chỉ bằng cách yêu cầu bạn cho họ biết các chữ số ma thuật.

CHÓ.  Hãy tiếp tục chủ đề trớ trêu.

GnuTLS đã có một lỗ hổng thời gian trong mã được cho là ghi lại các lỗi tấn công theo thời gian.

Làm thế nào để bạn thích điều đó?

Bảo mật nghiêm túc: GnuTLS tuân theo OpenSSL, sửa lỗi tấn công theo thời gian

VỊT.  [CƯỜI] Họ đã kiểm tra xem có sự cố nào xảy ra trong quá trình thiết lập phiên RSA hay không bằng cách gọi biến này ok.

Nó TRUE nếu nó ổn, và nó là FALSE nếu không.

Và sau đó họ có mã này, "Nếu không ổn, hãy báo cáo, nếu người đó đã bật gỡ lỗi."

Bạn có thể thấy lập trình viên đã nghĩ về điều này (thậm chí còn có một bình luận)…

Nếu không có lỗi, thì hãy thực hiện một bài tập ghi nhật ký giả vờ không phải là ghi nhật ký, nhưng hãy thử và sử dụng chính xác lượng thời gian đó, hoàn toàn dư thừa.

Khác nếu có lỗi, hãy đi và thực sự ghi nhật ký.

Nhưng hóa ra là không có đủ sự tương đồng giữa việc thực hiện hai đường dẫn hoặc có thể phần ghi nhật ký thực tế đang diễn ra đã phản hồi trong một khoảng thời gian khác tùy thuộc vào loại lỗi mà bạn cố tình. khiêu khích.

Nó chỉ ra rằng bằng cách thực hiện một triệu hoặc nhiều bẫy có chủ ý, "Này, tôi muốn thiết lập một yêu cầu phiên", về cơ bản, bạn có thể tìm hiểu kỹ thiết lập phiên để lấy một khóa sẽ được sử dụng sau này cho các nội dung trong tương lai .

Và, về lý thuyết, điều đó có thể cho phép bạn giải mã các phiên.

CHÓ.  Và đó là nơi chúng ta có thuật ngữ “oracle bug” (viết thường oracle, đừng nhầm lẫn với công ty Oracle).

Bạn có thể nhìn thấy những thứ mà bạn không thể nhìn thấy, phải không?

VỊT.  Về cơ bản, bạn nhận được mã để trả lại cho bạn câu trả lời không trả lời trực tiếp câu hỏi, nhưng cung cấp cho bạn một số gợi ý về câu trả lời có thể là gì.

Bạn đang để quá trình mã hóa tiết lộ một chút về chính nó mỗi lần.

Và mặc dù nghe có vẻ như, “Ai có thể thực hiện thêm một triệu yêu cầu thiết lập phiên mà không bị phát hiện?”…

…tốt, trên các mạng hiện đại, một triệu gói mạng không thực sự nhiều như vậy, Doug.

Và, cuối cùng, bạn thực sự đã học được điều gì đó về đầu bên kia, bởi vì hành vi của nó không đủ nhất quán.

Thỉnh thoảng, nhà tiên tri đã cho đi một thứ mà lẽ ra nó phải giữ bí mật.

CHÓ.  Được rồi, chúng tôi có một số lời khuyên về cách cập nhật nếu bạn là người dùng GnuTLS, vì vậy bạn có thể đi đến bài viết để kiểm tra điều đó.

Hãy nói về “Happy Patch Tuesday”, mọi người.

Chúng tôi có rất nhiều lỗi từ Bản vá Thứ Ba của Microsoft, bao gồm ba ngày không.

Microsoft Patch Tuesday: 36 lỗi RCE, 3 zero-day, 75 CVE

VỊT.  Đúng vậy, Doug.

75 CVE, và như bạn nói, ba trong số đó là zero-day.

Nhưng chúng chỉ được đánh giá Quan trọng, Chứ không phải Quan trọng.

Trên thực tế, may mắn thay, các lỗi nghiêm trọng dường như đã được sửa một cách có trách nhiệm.

Vì vậy, không phải là đã có một khai thác sẵn có trong tự nhiên.

Tôi nghĩ điều quan trọng hơn trong danh sách 75 CVE này là gần một nửa trong số đó là thực thi mã từ xa lỗi.

Đó thường được coi là loại lỗi nghiêm trọng nhất cần lo lắng, bởi vì đó là cách kẻ gian xâm nhập ngay từ đầu.

Sau đó đến EoP (nâng cao đặc quyền), trong đó có một số lỗi, bao gồm một trong số chúng là lỗi XNUMX ngày... trong trình điều khiển Hệ thống tệp nhật ký chung của Windows

Tất nhiên, RCE, thực thi mã từ xa, thường được kết hợp bởi tội phạm mạng với sự gia tăng các lỗi đặc quyền.

Họ sử dụng cái đầu tiên để đột nhập mà không cần mật khẩu hoặc không cần xác thực.

Họ lấy mã cấy ghép, sau đó kích hoạt lỗi tăng đặc quyền, vì vậy họ không chỉ *vào* mà còn *lên*.

Và thông thường, họ kết thúc với tư cách là quản trị viên hệ thống (rất tệ, vì khi đó về cơ bản họ được tự do chuyển vùng mạng), hoặc cuối cùng họ có đặc quyền giống như hệ điều hành cục bộ… trên Windows, cái được gọi là tài khoản HỆ THỐNG (mà khá nhiều có nghĩa là họ có thể làm bất cứ điều gì trên máy tính đó).

CHÓ.  Có rất nhiều lỗi trong Bản vá Thứ Ba này đến nỗi nó buộc bạn phải dành một phần của bài viết này có tên là Security Bug Classes Explained...

…mà tôi cho là bắt buộc phải đọc nếu bạn mới tìm hiểu về an ninh mạng và muốn biết có những loại lỗi nào.

Vì vậy, chúng tôi đã nói về một RCE (thực thi mã từ xa) và chúng tôi đã nói về EoP (nâng cao đặc quyền).

Bạn tiếp theo giải thích những gì một Bị rò rỉ Là…

VỊT.  Thực sự.

Đặc biệt, giờ đây, rò rỉ bộ nhớ rõ ràng có thể rất tệ nếu thứ rò rỉ là mật khẩu hoặc toàn bộ nội dung của một tài liệu siêu bí mật.

Nhưng vấn đề là một số rò rỉ, đối với một người không quen thuộc với an ninh mạng, nghe có vẻ thực sự không quan trọng.

OK, vậy là bạn đã làm rò rỉ địa chỉ bộ nhớ nơi một trình điều khiển hạt nhân nào đó của DLL hoặc tương tự như vậy tình cờ được tải vào bộ nhớ?

Điều đó tồi tệ như thế nào?

Nhưng vấn đề là việc khai thác thực thi mã từ xa thường dễ dàng hơn nhiều nếu bạn biết chính xác vị trí chọc kim đan của mình trong bộ nhớ trên máy chủ cụ thể đó hoặc máy tính xách tay cụ thể đó.

Bởi vì hầu hết các hệ điều hành hiện đại đều sử dụng một thứ gọi là ASLR (ngẫu nhiên hóa bố trí không gian địa chỉ), nơi chúng cố tình tải các chương trình, tệp DLL, thư viện dùng chung, trình điều khiển nhân và nội dung tại các địa chỉ bộ nhớ được chọn ngẫu nhiên…

…để bố cục bộ nhớ của bạn trên máy tính thử nghiệm, nơi khai thác của bạn hoạt động hoàn hảo, sẽ không giống như của tôi.

Và sẽ khó hơn nhiều để khai thác hoạt động nói chung khi bạn tích hợp tính ngẫu nhiên này vào hệ thống so với khi bạn không có.

Vì vậy, có một số rò rỉ bộ nhớ nhỏ, trong đó bạn có thể chỉ rò rỉ tám byte bộ nhớ (hoặc thậm chí chỉ bốn byte nếu đó là hệ thống 32 bit) khi bạn cung cấp địa chỉ bộ nhớ.

Và đó là tất cả những gì kẻ lừa đảo cần để biến một khai thác có thể chỉ hoạt động, nếu họ thực sự may mắn, thành một khai thác mà họ có thể lạm dụng mọi lúc, một cách đáng tin cậy.

Vì vậy, hãy cẩn thận với rò rỉ!

CHÓ.  Xin vui lòng cho chúng tôi biết những gì một Bỏ qua có nghĩa là.

VỊT.  Nó sắp xếp có nghĩa là chính xác những gì nó nói.

Bạn đã có một biện pháp phòng ngừa bảo mật mà bạn mong đợi hệ điều hành hoặc phần mềm của bạn sẽ khởi động cùng.

Ví dụ: “Này, bạn có thực sự chắc chắn rằng bạn muốn mở tệp đính kèm tồi tệ này được gửi trong email từ một người mà bạn không biết không?”

Nếu những kẻ lừa đảo có thể tìm ra cách để thực hiện hành vi xấu đó nhưng bỏ qua kiểm tra bảo mật lẽ ra phải thực hiện và cho bạn cơ hội chiến đấu để trở thành người dùng có đầy đủ thông tin làm điều đúng đắn…

…tin tôi đi, họ sẽ lấy nó.

Vì vậy, bỏ qua bảo mật có thể khá khó khăn.

CHÓ.  Và sau đó dọc theo những dòng đó, chúng tôi đã nói về Giả mạo.

Trong câu chuyện Reddit, dụ ai đó đến một trang web trông giống như một trang web hợp pháp nhưng không phải – đó là một trang web giả mạo.

Và sau đó, cuối cùng, chúng ta có DoS, hoặc từ chối dịch vụ.

VỊT.  Vâng, đó là chính xác những gì nó nói.

Đó là nơi bạn ngăn thứ gì đó được cho là hoạt động trên máy tính của nạn nhân thực hiện công việc của nó.

Bạn đại loại nghĩ rằng, “Từ chối dịch vụ, nó nên nằm ở cuối danh sách các mối quan tâm, bởi vì ai thực sự quan tâm? Chúng tôi đã có tính năng tự động khởi động lại.”

Nhưng nếu kẻ lừa đảo có thể chọn đúng thời điểm để thực hiện việc đó (giả sử, 30 giây sau khi máy chủ của bạn bị sập cách đây hai phút vừa hoạt động trở lại), thì chúng thực sự có thể sử dụng lỗi từ chối dịch vụ một cách hiếm gặp một cách đáng ngạc nhiên để gây ra điều gì tương đương với sự cố mất điện liên tục đối với bạn.

Và bạn có thể tưởng tượng: [A] điều đó thực sự có thể khiến bạn phải trả giá nếu bạn dựa vào các dịch vụ trực tuyến của mình đang hoạt động và [B] nó có thể tạo ra một màn khói hấp dẫn cho những kẻ lừa đảo, bằng cách tạo ra sự gián đoạn này cho phép những kẻ lừa đảo xông vào một nơi nào đó khác.

CHÓ.  Và không hài lòng với cuộc vui, Apple đã đến để khắc phục một không ngày lỗi thực thi mã từ xa.

Apple sửa lỗi cấy ghép phần mềm gián điệp zero-day – vá ngay bây giờ!

VỊT.  Lỗi này, và tôi sẽ đọc CVE chỉ để tham khảo: đó là CVE-2023-23529...

…là lỗ hổng thực thi mã từ xa zero-day trong WebKit, mà tôi cho là một lỗ hổng và tôi nghĩ nhiều người khác suy luận có nghĩa là “Lỗi trình duyệt có thể được kích hoạt bởi mã được cung cấp từ xa.”

Và tất nhiên, đặc biệt là trong iPhone và iPad, như chúng ta đã nói nhiều lần, WebKit là mã bắt buộc cho mọi trình duyệt, ngay cả những trình duyệt không sử dụng WebKit trên các nền tảng khác.

Vì vậy, nó có vẻ giống như, “Chúng tôi phát hiện ra điều này vì có một số phần mềm gián điệp đang hoạt động,” hoặc, “Có một lỗi có thể được sử dụng để bẻ khóa điện thoại của bạn và loại bỏ tất cả các quy định nghiêm ngặt cho phép kẻ gian xâm nhập và để chúng đi lang thang xung quanh theo ý muốn.

Rõ ràng, trên điện thoại, đó là điều bạn chắc chắn không muốn.

CHÓ.  Được rồi, và về câu chuyện này, độc giả Peter của Naked Security viết:

Tôi cố gắng cập nhật ngay khi tôi thấy thông báo cập nhật của bạn trong hộp thư đến của mình. Mặc dù tôi biết rất ít hoặc không biết gì về các vấn đề kỹ thuật liên quan, nhưng tôi biết điều quan trọng là phải luôn cập nhật phần mềm và đó là lý do tại sao tôi chọn tùy chọn cập nhật phần mềm tự động trên tất cả các thiết bị của mình. Nhưng hiếm khi tôi nhận được cảnh báo phần mềm trên iPhone, iPad hoặc MacBook trước khi nhận được chúng từ Sophos.

Vì vậy, cảm ơn, các bạn!

Thật tuyệt!

VỊT.  Nó là!

Và tôi chỉ có thể trả lời bằng câu: “Rất vui được giúp đỡ.”

Tôi khá thích viết những bài báo đó, bởi vì tôi nghĩ rằng họ cung cấp một dịch vụ tốt.

Tốt hơn là nên biết và chuẩn bị sẵn sàng hơn là bị bất ngờ… đó là ý kiến ​​​​của tôi.

CHÓ.  Và không phải để trình bày quá nhiều về cách làm xúc xích ở đây, nhưng lý do Paul có thể cập nhật những bản cập nhật này của Apple nhanh như vậy là vì anh ấy có một chiếc còi báo động lớn màu đỏ trong phòng khách được kết nối qua cáp USB với máy tính của anh ấy và kiểm tra trang cập nhật bảo mật của Apple sáu giây một lần.

Vì vậy, nó bắt đầu bùng nổ ngay khi trang đó được cập nhật lần thứ hai, và sau đó anh ấy viết nó lên cho Naked Security.

VỊT.  [CƯỜI] Tôi nghĩ lý do có lẽ chỉ là tôi có xu hướng đi ngủ khá muộn.

CHÓ.  [CƯỜI] Chính xác, bạn không ngủ…

VỊT.  Bây giờ tôi lớn rồi, giờ ngủ cũng không cố định nữa.

Tôi có thể thức khuya như tôi muốn! [CƯỜI]

CHÓ.  Được rồi, cảm ơn, Peter, 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.

[CHẾ ĐỘ ÂM NHẠC]