Không có trình phát âm thanh bên dưới? Nghe trực tiếp trên Soundcloud.

CHÓ.  Trình quản lý mật khẩu bị bẻ khóa, lỗi đăng nhập và Nữ hoàng Elizabeth I đấu với Mary Queen of Scots… tất nhiên rồi!

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.  Wow!

Đầu lâu công nghệ thông tin thế kỷ 16 đáp ứng podcast An ninh khỏa thân, Douglas.

Tôi không thể chờ đợi!

CHÓ.  Rõ ràng là có… chúng ta sẽ sớm làm được điều đó.

Nhưng trước tiên, như mọi khi, Tuần này trong Lịch sử Công nghệ, vào ngày 28 tháng 1987 năm XNUMX, nhà cung cấp dịch vụ trực tuyến CompuServe đã phát hành một thứ nhỏ gọi là Định dạng trao đổi đồ họa, hoặc GIF [HARD G].

Nó được phát triển bởi Steve Wilhite quá cố, một kỹ sư tại CompuServe (nhân tiện, người đã thề thốt lên rằng nó được phát âm là “jif”) như một phương tiện để hỗ trợ hình ảnh màu trên băng thông hạn chế và dung lượng lưu trữ của các mạng máy tính đời đầu.

Phiên bản đầu tiên, GIF 87a, hỗ trợ tối đa 256 màu; nó nhanh chóng trở nên phổ biến nhờ khả năng hiển thị các hoạt ảnh đơn giản và sự hỗ trợ rộng rãi của nó trên các hệ thống máy tính khác nhau.

Cảm ơn, ông Wilhite.

VỊT.  Và nó để lại gì cho chúng ta, Douglas?

Hoạt ảnh trên web và tranh cãi về việc từ này được phát âm là “đồ họa” [HARD G] hay “giraffics” [SOFT G].

CHÓ.  Một cách chính xác. [LỪA ĐẢO]

VỊT.  Tôi không thể không gọi nó là “giff” [HARD G].

CHÓ.  Tương tự!

Hãy đóng dấu điều đó và chuyển sang câu chuyện thú vị của chúng ta…

…về Nữ hoàng Elizabeth I, Mary Queen of Scots, và một người đàn ông chơi cả hai bên giữa những kẻ lừa đảo ransomware và chủ nhân của anh ta, Paul.

Câu chuyện về ransomware: Cuộc tấn công MitM thực sự có một người đàn ông ở giữa

VỊT.  [CƯỜI] Hãy bắt đầu từ phần cuối của câu chuyện.

Về cơ bản, đó là một cuộc tấn công ransomware nhằm vào một công ty công nghệ ở Oxfordshire, Anh.

(Không phải công ty này… đó là một công ty ở Oxford, cách Abingdon-on-Thames, nơi đặt trụ sở của Sophos 15 km về phía thượng nguồn.)

Sau khi bị ransomware tấn công, như bạn có thể tưởng tượng, họ đã gặp phải yêu cầu trả Bitcoin để lấy lại dữ liệu của họ.

Và, giống như câu chuyện đó, chúng tôi đã có một vài tuần trước.

Tôi biết điều đó, để tránh ngôn ngữ phân biệt giới tính và để phản ánh thực tế rằng ngày nay không phải lúc nào cũng là con người (thường là máy tính ở giữa)…

…trên Naked Security, bây giờ tôi viết “Kẻ thao túng ở giữa.”

Nhưng đây thực sự là một người đàn ông ở giữa.

Nói một cách đơn giản, Doug, anh ấy đã xoay sở để bắt đầu gửi email cho chủ nhân của mình từ nhà, sử dụng một loại tài khoản email đánh máy giống như địa chỉ email của kẻ gian.

Anh ta đã chiếm quyền điều khiển chuỗi và thay đổi địa chỉ Bitcoin trong các dấu vết email lịch sử, vì anh ta có quyền truy cập vào tài khoản email của các giám đốc điều hành cấp cao…

…và về cơ bản anh ấy bắt đầu đàm phán với tư cách là người trung gian.

Vì vậy, bạn hãy tưởng tượng bây giờ anh ta đang đàm phán riêng với kẻ lừa đảo, và sau đó anh ta chuyển cuộc đàm phán đó cho chủ của mình.

Chúng tôi không biết liệu anh ta có hy vọng chạy trốn với tất cả số tiền thưởng và sau đó chỉ nói với chủ của mình, “Này, đoán xem, những kẻ lừa đảo đã lừa chúng tôi”, hay liệu anh ta muốn thương lượng với những kẻ lừa đảo về phía mình, và chủ nhân của anh ấy ở đầu bên kia.

Bởi vì anh ấy biết tất cả những điều đúng/sai nên nói để làm tăng thêm nỗi sợ hãi và khủng bố trong công ty.

Vì vậy, mục tiêu của anh ta về cơ bản là chiếm đoạt khoản thanh toán ransomware.

Chà, Doug, mọi chuyện diễn ra hơi suôn sẻ một chút bởi vì, không may cho anh ấy và may mắn cho chủ của anh ấy và cho cơ quan thực thi pháp luật, công ty đã quyết định không trả tiền.

CHÓ.  [CƯỜI] Hừm!

VỊT.  Vì vậy, không có Bitcoin để anh ta đánh cắp và sau đó bỏ chạy.

Ngoài ra, có vẻ như anh ta đã không che giấu dấu vết của mình tốt lắm, và việc anh ta truy cập bất hợp pháp vào nhật ký email sau đó đã bị lộ tẩy.

Anh ta rõ ràng biết rằng cảnh sát đang tiếp cận anh ta, bởi vì anh ta đã cố gắng xóa dữ liệu giả mạo khỏi máy tính và điện thoại của chính mình ở nhà.

Nhưng chúng đã bị tịch thu và dữ liệu đã được phục hồi.

Bằng cách nào đó, vụ án kéo dài năm năm, và cuối cùng, ngay khi anh ta chuẩn bị ra tòa, anh ta rõ ràng đã quyết định rằng mình thực sự không còn chân đứng và anh ta đã nhận tội.

Vì vậy, bạn đã có nó, Doug.

Một cuộc tấn công man-in-the-middle theo đúng nghĩa đen!

CHÓ.  OK, vậy là mọi chuyện ổn thỏa và tốt đẹp vào năm 2023…

…nhưng hãy đưa chúng tôi trở lại những năm 1580, Phao-lô.

Còn Mary, Nữ hoàng Scotland và Nữ hoàng Elizabeth I thì sao?

VỊT.  Chà, thành thật mà nói, tôi chỉ nghĩ rằng đó là một cách tuyệt vời để giải thích một cuộc tấn công trung gian bằng cách quay ngược lại những năm đó.

Bởi vì, nổi tiếng là Nữ hoàng Elizabeth và em họ Mary, Nữ hoàng Scotland là kẻ thù tôn giáo và chính trị.

Elizabeth là Nữ hoàng Anh; Mary là kẻ giả danh ngai vàng.

Vì vậy, Mary đã bị quản thúc tại gia một cách hiệu quả.

Mary đang sống trong một nơi xa hoa nào đó, nhưng bị giam trong một lâu đài, và thực sự đang âm mưu chống lại người anh họ của mình, nhưng họ không thể chứng minh điều đó.

Và Mary đang gửi và nhận các tin nhắn nhét trong các nắp thùng bia được chuyển đến lâu đài.

Rõ ràng, trong trường hợp này, người trung gian là một nhà cung cấp bia tuân thủ quy định, người này sẽ xóa các tin nhắn trước khi Mary nhận được chúng, để chúng có thể bị sao chép.

Và anh ấy sẽ chèn các tin nhắn thay thế, được mã hóa bằng mật mã của Mary, với những thay đổi tinh vi mà, nói một cách đại khái, cuối cùng đã thuyết phục Mary viết nhiều hơn những gì cô ấy có thể nên làm.

Vì vậy, cô ấy không chỉ tiết lộ tên của những kẻ chủ mưu khác, mà còn chỉ ra rằng cô ấy đã tán thành âm mưu ám sát Nữ hoàng Elizabeth.

Vào thời điểm đó, họ gặp nhiều khó khăn hơn… và nước Anh chắc chắn có án tử hình vào những ngày đó, và Mary đã bị xét xử và hành quyết.

Top 10 bản mã bị bẻ khóa từ lịch sử

CHÓ.  OK, vì vậy, đối với bất kỳ ai đang lắng nghe, phần giới thiệu thang máy cho podcast này là “Tin tức và lời khuyên về an ninh mạng và một chút lịch sử”.

Quay lại với người trung gian của chúng tôi trong thời đại ngày nay.

Chúng ta đã nói về một mối đe dọa nội bộ khác như thế này cách đây không lâu.

Vì vậy, sẽ rất thú vị để xem liệu đây có phải là một khuôn mẫu hay đây chỉ là một sự trùng hợp ngẫu nhiên.

Tuy nhiên, chúng tôi đã nói về một số điều bạn có thể làm để bảo vệ mình trước những kiểu tấn công này, vì vậy hãy nhanh chóng xem lại những điều đó một lần nữa.

Bắt đầu với: Phân chia và chinh phục, về cơ bản có nghĩa là, “Đừng trao cho một người trong công ty quyền truy cập tự do vào mọi thứ,” Paul.

VỊT.  Vâng.

CHÓ.  Và sau đó chúng tôi đã có: Giữ nhật ký bất biến, có vẻ như nó đã xảy ra trong trường hợp này, phải không?

VỊT.  Vâng.

Có vẻ như một yếu tố quan trọng của bằng chứng trong trường hợp này là việc anh ta đã đào sâu vào email của các giám đốc điều hành cấp cao và thay đổi chúng, và anh ta không thể che giấu điều đó.

Vì vậy, bạn hãy tưởng tượng, ngay cả khi không có bằng chứng khác, việc anh ta gửi email liên quan cụ thể đến các cuộc đàm phán về ransomware và địa chỉ Bitcoin sẽ cực kỳ đáng ngờ.

CHÓ.  Được rồi, cuối cùng: Luôn luôn đo lường, không bao giờ giả định.

VỊT.  Thật!

CHÓ.  Những người tốt cuối cùng đã thắng… phải mất XNUMX năm, nhưng chúng tôi đã làm được.

Hãy chuyển sang câu chuyện tiếp theo của chúng tôi.

Công ty bảo mật web tìm thấy lỗi đăng nhập trong bộ công cụ xây dựng ứng dụng.

Lỗi này được sửa nhanh chóng và minh bạch, vậy thì tốt quá… nhưng có một chút nhiều hơn cho câu chuyện, tất nhiên, Paul.

Bảo mật nghiêm trọng: Xác minh là rất quan trọng – kiểm tra lỗi đăng nhập OAUTH

VỊT.  Vâng.

Đây là một công ty phân tích bảo mật mã hóa web (tôi hy vọng tôi đã chọn đúng thuật ngữ ở đó) có tên là SALT và họ đã tìm thấy một lỗ hổng xác thực trong bộ công cụ xây dựng ứng dụng có tên là Expo.

Và, phù hộ cho trái tim của họ, Expo hỗ trợ một thứ gọi là OAUTH, Mở ủy quyền hệ thống.

Đó là loại hệ thống được sử dụng khi bạn truy cập một trang web đã quyết định, “Bạn biết không, chúng tôi không muốn gặp rắc rối khi cố gắng học cách bảo mật mật khẩu cho chính mình. Những gì chúng tôi sẽ làm là chúng tôi sẽ nói, 'Đăng nhập bằng Google, đăng nhập bằng Facebook',” đại loại như vậy.

Và ý tưởng là, nói một cách đơn giản, bạn liên hệ với Facebook, Google hoặc bất kỳ dịch vụ chính thống nào và bạn nói, “Này, tôi muốn cung cấp example.com được phép làm X.”

Vì vậy, Facebook, Google, hoặc bất cứ thứ gì, xác thực bạn và sau đó nói: “Được rồi, đây là một mã ma thuật mà bạn có thể cung cấp cho đầu bên kia với nội dung: 'Chúng tôi đã kiểm tra bạn; bạn đã xác thực với chúng tôi và đây là mã thông báo xác thực của bạn.”

Sau đó, đầu bên kia có thể kiểm tra độc lập với Facebook, Google hoặc bất kỳ thứ gì để đảm bảo rằng mã thông báo đó được phát hành thay mặt bạn.

Vì vậy, điều đó có nghĩa là bạn không bao giờ cần cung cấp bất kỳ mật khẩu nào cho trang web… nếu muốn, bạn có thể chọn Facebook hoặc Google để thực hiện phần xác thực thực tế cho mình.

Đó là một ý tưởng tuyệt vời nếu bạn là một trang web cửa hàng và bạn nghĩ, “Tôi sẽ không tạo ra mật mã của riêng mình.”

Vì vậy, đây không phải là lỗi trong OAUTH.

Nó chỉ là một sự giám sát; điều gì đó đã bị lãng quên trong quá trình triển khai quy trình OAUTH của Expo.

Và, nói một cách đại khái, Doug, nó diễn ra như thế này.

Mã Expo tạo một URL khổng lồ bao gồm tất cả các thông số cần thiết để xác thực với Facebook, sau đó quyết định nơi sẽ gửi mã thông báo truy cập ma thuật cuối cùng đó.

Do đó, về lý thuyết, nếu bạn đã tạo URL của riêng mình hoặc bạn có thể sửa đổi URL, thì bạn có thể thay đổi nơi gửi mã thông báo xác thực kỳ diệu này cuối cùng.

Nhưng bạn sẽ không thể đánh lừa người dùng vì một hộp thoại xuất hiện có nội dung: “Ứng dụng tại URL-here đang yêu cầu bạn đăng nhập vào tài khoản Facebook của bạn. Bạn có hoàn toàn tin tưởng điều này và muốn để nó làm như vậy? Có hay không?"

Tuy nhiên, khi đến thời điểm nhận mã ủy quyền từ Facebook, Google hoặc bất kỳ thứ gì và chuyển mã đó vào “URL trả về” này, mã Expo sẽ không kiểm tra xem bạn đã thực sự nhấp vào hay chưa. Yes trên hộp thoại phê duyệt.

Nếu bạn chủ động nhìn thấy hộp thoại và nhấp vào No, thì bạn sẽ ngăn cuộc tấn công xảy ra.

Nhưng, về cơ bản, điều này "mở không thành công".

Nếu bạn chưa bao giờ nhìn thấy đoạn hội thoại, vì vậy bạn thậm chí sẽ không biết rằng có thứ gì đó để nhấp và bạn không làm gì cả, và sau đó những kẻ tấn công chỉ cần tự kích hoạt lượt truy cập URL tiếp theo bằng nhiều JavaScript hơn…

…thì hệ thống sẽ hoạt động.

Và lý do nó hoạt động là vì “URL trả về” kỳ diệu, nơi gửi mã ủy quyền siêu bí mật, đã được đặt trong cookie web để Expo sử dụng sau này *trước khi bạn nhấp vào Yes trên hộp thoại*.

Về sau, sự tồn tại của cookie “URL quay lại” đó về cơ bản được coi là bằng chứng rằng bạn hẳn đã xem hộp thoại và bạn phải quyết định tiếp tục.

Trong khi, trên thực tế, đó không phải là trường hợp.

Vì vậy, đó là một cú trượt lớn giữa cốc và môi, Douglas.

CHÓ.  Được rồi, chúng tôi có một số mẹo, bắt đầu bằng: Khi báo cáo và tiết lộ lỗi này, đây là một trường hợp kinh điển.

Đây gần như chính xác là cách bạn nên làm, Paul.

Mọi thứ chỉ hoạt động bình thường, vì vậy đây là một ví dụ tuyệt vời về cách thực hiện điều này theo cách tốt nhất có thể.

VỊT.  Và đó là một trong những lý do chính tại sao tôi muốn viết nó lên Naked Security.

SALT, những người đã tìm ra lỗi…

..họ đã tìm thấy nó; họ tiết lộ nó một cách có trách nhiệm; họ đã làm việc với Expo, người đã sửa nó, theo đúng nghĩa đen trong vòng vài giờ.

Vì vậy, mặc dù đó là một lỗi, mặc dù đó là một lỗi mã hóa, nhưng nó đã dẫn đến việc SALT phải nói: “Bạn biết không, những người của Expo rất vui khi được làm việc cùng.”

Sau đó, SALT bắt đầu lấy CVE, và thay vì nói: “Này, lỗi đã được sửa rồi, vì vậy hai ngày sau chúng ta có thể PR rầm rộ về nó,” tuy nhiên, họ đã đặt ra một ngày trước ba tháng khi họ thực sự viết. lên những phát hiện của họ và viết lên báo cáo rất giáo dục của họ.

Thay vì vội vàng tung ra vì mục đích PR ngay lập tức, để phòng trường hợp bị phát hiện vào phút chót, họ không chỉ báo cáo việc này một cách có trách nhiệm để có thể khắc phục trước khi kẻ gian tìm ra (và không có bằng chứng nào cho thấy ai đó đã lạm dụng lỗ hổng này), họ còn sau đó đã dành một chút thời gian để Expo ra ngoài đó và giao tiếp với khách hàng của họ.

CHÓ.  Và sau đó, tất nhiên, chúng tôi đã nói một chút về điều này: Đảm bảo rằng các kiểm tra xác thực của bạn không thành công đã đóng.

Đảm bảo rằng nó không tiếp tục hoạt động nếu ai đó bỏ qua hoặc hủy bỏ nó.

Nhưng vấn đề lớn hơn ở đây là: Đừng bao giờ cho rằng mã phía máy khách của chính bạn sẽ kiểm soát quá trình xác minh.

VỊT.  Nếu bạn tuân theo quy trình chính xác của mã JavaScript do Expo cung cấp để đưa bạn qua quy trình OAUTH này, thì bạn sẽ ổn thôi.

Nhưng nếu bạn tránh mã của họ và thực sự chỉ kích hoạt các liên kết bằng JavaScript của riêng bạn, bao gồm cả việc bỏ qua hoặc hủy cửa sổ bật lên, thì bạn đã thắng.

Bỏ qua mã máy khách của bạn là điều đầu tiên mà kẻ tấn công sẽ nghĩ đến.

CHÓ.  Được rồi, cuối cùng nhưng không kém phần quan trọng: Đăng xuất khỏi tài khoản web khi bạn không tích cực sử dụng chúng.

Đó là lời khuyên tốt xung quanh.

VỊT.  Chúng tôi nói điều đó mọi lúc trên podcast Naked Security và chúng tôi đã nhiều năm.

3 bước đơn giản để an toàn trực tuyến

Đó là lời khuyên không phổ biến, vì nó khá bất tiện, giống như cách nói với mọi người, “Này, tại sao không đặt trình duyệt của bạn xóa tất cả cookie khi thoát?”

Nếu bạn nghĩ về nó, trong trường hợp cụ thể này… giả sử quá trình đăng nhập diễn ra thông qua tài khoản Facebook của bạn; OAUTH qua Facebook.

Nếu bạn đã đăng xuất khỏi Facebook, thì bất kể kẻ tấn công đã thử dùng thủ đoạn JavaScript nào (tắt cửa sổ bật lên Expo và tất cả nội dung đó), quy trình xác thực với Facebook sẽ không thành công vì Facebook sẽ nói: “Này, người này yêu cầu tôi xác thực chúng. Họ hiện không đăng nhập.”

Vì vậy, bạn sẽ luôn thấy thông tin đăng nhập Facebook bật lên vào thời điểm đó: “Bạn cần đăng nhập ngay bây giờ”.

Và điều đó sẽ làm mất đi sự khuất phục ngay lập tức.

CHÓ.  OK rất tốt.

Và câu chuyện cuối cùng trong ngày của chúng tôi: Đừng hoảng sợ, nhưng rõ ràng có một cách để bẻ khóa mật khẩu chính cho trình quản lý mật khẩu mã nguồn mở KeePass.

Nhưng, một lần nữa, đừng hoảng sợ, bởi vì đó là một phức tạp hơn nhiều hơn là nó có vẻ, Paul.

Bạn thực sự phải có quyền kiểm soát máy của ai đó.

Bảo mật nghiêm túc: “Bẻ khóa mật khẩu chính” KeePass đó và những gì chúng ta có thể học được từ nó

VỊT.  Bạn làm.

Nếu bạn muốn theo dõi điều này, thì đó là CVE-2023-32784.

Đó là một lỗi hấp dẫn, và tôi đã viết một loại magnum opus bài viết phong cách trên Naked Security về nó, có tựa đề: Đó là 'bẻ khóa mật khẩu chính' của KeePass và chúng ta có thể học được gì từ nó.

Vì vậy, tôi sẽ không làm hỏng bài viết đó, bao gồm cấp phát bộ nhớ kiểu C, cấp phát bộ nhớ kiểu ngôn ngữ kịch bản và cuối cùng là các chuỗi được quản lý C# hoặc .NET… cấp phát bộ nhớ được quản lý bởi hệ thống.

Tôi sẽ chỉ mô tả những gì nhà nghiên cứu trong trường hợp này đã phát hiện ra.

Những gì họ đã làm là… họ đã tìm kiếm mã KeePass và trong các kết xuất bộ nhớ KeePass, để tìm bằng chứng về việc tìm thấy mật khẩu chính trong bộ nhớ dễ dàng như thế nào, mặc dù chỉ là tạm thời.

Nếu nó ở đó vài phút, vài giờ hoặc vài ngày sau thì sao?

Điều gì sẽ xảy ra nếu mật khẩu chính vẫn nằm xung quanh, có thể trong tệp hoán đổi của bạn trên đĩa, ngay cả sau khi bạn đã khởi động lại máy tính của mình?

Vì vậy, tôi đã thiết lập KeePass và đặt cho mình một mật khẩu gồm 16 ký tự, toàn chữ hoa để có thể dễ dàng nhận ra nếu tôi tìm thấy nó trong bộ nhớ.

Và, kỳ lạ thay, tôi chưa bao giờ tìm thấy mật khẩu chính của mình nằm trong bộ nhớ: không phải dưới dạng một chuỗi ASCII; không phải là chuỗi Windows widechar (UTF-16)).

Tuyệt quá!

Nhưng điều mà nhà nghiên cứu này nhận thấy là khi bạn nhập mật khẩu của mình vào KeePass, nó sẽ hiển thị… Tôi sẽ gọi nó là “ký tự đốm màu Unicode”, chỉ để cho bạn thấy rằng, vâng, bạn đã nhấn một phím, và do đó để cho bạn thấy bạn đã nhập bao nhiêu ký tự.

Vì vậy, khi bạn nhập mật khẩu của mình, bạn sẽ thấy chuỗi blob [●], blob-blob [●●], blob-blob-blob [●●●] và trong trường hợp của tôi, mọi thứ lên tới 16 đốm màu.

Chà, những chuỗi blob đó dường như không phải là rủi ro bảo mật, vì vậy có lẽ chúng chỉ được để lại cho thời gian chạy .NET để quản lý dưới dạng “chuỗi được quản lý”, nơi chúng có thể nằm trong bộ nhớ sau đó…

…và không bị dọn dẹp bởi vì, “Này, chúng chỉ là những đốm màu.”

Hóa ra là nếu bạn thực hiện kết xuất bộ nhớ của KeePass, thứ cung cấp cho bạn dung lượng khổng lồ 250 MB, và bạn tìm kiếm các chuỗi như blob-blob, blob-blob-blob, v.v. (bất kỳ số lượng đốm màu nào), sẽ có một đoạn kết xuất bộ nhớ trong đó bạn sẽ thấy hai đốm màu, sau đó là ba đốm màu, rồi bốn đốm màu, rồi năm đốm màu… và trong trường hợp của tôi, tất cả lên đến 16 đốm màu.

Và sau đó, bạn sẽ nhận được bộ sưu tập ngẫu nhiên gồm “các ký tự đốm màu xảy ra do nhầm lẫn”, nếu bạn muốn.

Nói cách khác, chỉ tìm kiếm những chuỗi blob đó, mặc dù chúng không tiết lộ mật khẩu thực của bạn, sẽ tiết lộ độ dài mật khẩu của bạn.

Tuy nhiên, nó thậm chí còn thú vị hơn, bởi vì điều mà nhà nghiên cứu này băn khoăn là, “Điều gì sẽ xảy ra nếu dữ liệu gần các chuỗi đốm màu đó trong bộ nhớ bằng cách nào đó có thể được liên kết với các ký tự riêng lẻ mà bạn nhập vào mật khẩu?”

Vì vậy, điều gì sẽ xảy ra nếu bạn xem qua tệp kết xuất bộ nhớ và thay vì chỉ tìm kiếm hai đốm màu, ba đốm màu/bốn đốm màu, v.v.

…bạn tìm kiếm một chuỗi các đốm màu theo sau bởi một ký tự mà bạn nghĩ là có trong mật khẩu?

Vì vậy, trong trường hợp của tôi, tôi chỉ tìm kiếm các ký tự từ A đến Z, vì tôi biết đó là những gì có trong mật khẩu.

Tôi đang tìm kiếm bất kỳ chuỗi đốm màu nào, theo sau là một ký tự ASCII.

Đoán xem chuyện gì đã xảy ra, Doug?

Tôi nhận được hai đốm màu theo sau là ký tự thứ ba trong mật khẩu của mình; ba đốm màu theo sau là ký tự thứ tư trong mật khẩu của tôi; lên đến 15 đốm màu ngay sau ký tự thứ 16 trong mật khẩu của tôi.

CHÓ.  Vâng, đó là một hình ảnh hoang dã trong bài viết này!

Tôi đang làm theo… nó đang trở nên hơi kỹ thuật, và đột nhiên tôi chỉ thấy, “Chà! Trông giống như một mật khẩu vậy!”

VỊT.  Về cơ bản, các ký tự riêng lẻ trong mật khẩu của bạn được phân tán tự do trong bộ nhớ, nhưng những ký tự đại diện cho các ký tự ASCII thực sự là một phần của mật khẩu khi bạn nhập vào…

…giống như chúng được gắn cái chết phát quang vậy.

Vì vậy, những chuỗi đốm màu này vô tình hoạt động như một cơ chế gắn thẻ để gắn cờ các ký tự trong mật khẩu của bạn.

Và, thực sự, đạo đức của câu chuyện là mọi thứ có thể rò rỉ trong bộ nhớ theo những cách mà bạn đơn giản là không bao giờ ngờ tới, và ngay cả một người đánh giá mã có đầy đủ thông tin cũng có thể không nhận thấy.

Vì vậy, đây là một cuốn sách hấp dẫn và là một lời nhắc nhở tuyệt vời rằng việc viết mã an toàn có thể khó hơn bạn nghĩ rất nhiều.

Và thậm chí quan trọng hơn, việc xem xét, đảm bảo chất lượng và kiểm tra mã bảo mật có thể còn khó hơn…

…bởi vì bạn phải có mắt nhìn phía trước, phía sau và hai bên đầu, và bạn thực sự phải suy nghĩ như một kẻ tấn công và cố gắng tìm kiếm những bí mật bị rò rỉ ở mọi nơi bạn có thể.

CHÓ.  Ổn thỏa, kiểm tra xem nó ra, nó nằm trên makedsecurity.sophos.com.

Và, khi mặt trời bắt đầu lặn trong chương trình của chúng tôi, đã đến lúc nhận được phản hồi từ một trong những độc giả của chúng tôi.

Trên podcast trước (đây là một trong những bình luận yêu thích của tôi, Paul), người nghe Chang của Naked Security nhận xét:

Ở đó. Tôi đã làm xong. Sau gần hai năm say sưa nghe, tôi đã nghe xong tất cả các tập podcast của Naked Security. Tôi bị cuốn vào tất cả.

Tôi thích nó ngay từ đầu, bắt đầu với Chet Chat kéo dài; sau đó đến phi hành đoàn Vương quốc Anh; "Ôi không! Đó là Kim” là người tiếp theo; sau đó cuối cùng tôi cũng đến được “Tuần này trong Lịch sử Công nghệ” của ngày hôm nay.

Thật là một tiếng cười!

Cảm ơn bạn, Chang!

Tôi không thể tin rằng bạn đã xem tất cả các tập phim, nhưng tất cả chúng tôi (tôi hy vọng tôi không nói lung tung) đều đánh giá cao điều đó.

VỊT.  Thực sự rất nhiều, Doug!

Thật vui khi biết rằng không chỉ mọi người đang lắng nghe mà họ còn thấy podcast hữu ích và điều đó giúp họ tìm hiểu thêm về an ninh mạng cũng như nâng tầm trò chơi của họ, dù chỉ là một chút.

Bởi vì tôi nghĩ, như tôi đã nói nhiều lần trước đây, nếu tất cả chúng ta nâng cao trò chơi an ninh mạng của mình lên một chút, thì chúng ta sẽ làm được nhiều việc hơn để ngăn chặn kẻ gian hơn là nếu một hoặc hai công ty, một hoặc hai tổ chức, một hoặc hai cá nhân đã nỗ lực rất nhiều, nhưng những người còn lại thì tụt lại phía sau.

CHÓ.  Chính xác!

Vâng, cảm ơn bạn rất nhiều một lần nữa, Chang, vì đã gửi nó vào.

Chúng tôi thực sự đánh giá cao nó.

Và nếu bạn có một câu chuyện, nhận xét hoặc câu hỏi thú vị muốn gửi, chúng tôi 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]