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Ó.   Bán thân, tắt máy, Samba và GitHub.

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, hôm nay bạn thế nào?

VỊT.   Tôi rất khỏe, Douglas.

CHÓ.   Hãy để chúng tôi bắt đầu chương trình với Lịch sử công nghệ phân khúc – đây là một điều thú vị.

Tuần này, vào ngày 01 tháng 1982 năm 80286, bộ vi xử lý 16-bit Intel XNUMX đã được giới thiệu và tiếp tục trở thành trụ cột trong máy tính IBM PC/AT trong nhiều năm.

Thật thú vị, Intel không mong đợi 286 sẽ được sử dụng cho máy tính cá nhân và đã thiết kế một con chip dành cho các hệ thống đa nhiệm và nhiều người dùng.

VỊT.   Công dụng chính của nó, như bạn nói, là PC/AT, máy tính “Công nghệ tiên tiến” của IBM, về cơ bản được thiết kế để chạy DOS.

Mặc dù DOS bị giới hạn ở 1MB RAM (hoặc 640KB RAM và ROM còn lại), bạn có thể có thêm bộ nhớ và bạn có thể sử dụng nó cho những việc như…

…nhớ HIMEM.SYSvà bộ đệm RAM, tất cả những thứ đó?

Ngoại trừ điều đó vì Intel đã nghĩ đến vấn đề bảo mật, chúc phúc cho trái tim của họ, khi họ thiết kế 286…

…khi bạn đã chuyển từ chế độ mà nó chạy như 8086 sang chế độ siêu mạnh được gọi là “chế độ được bảo vệ”, *bạn không thể chuyển lại*.

Khi bạn chuyển sang chế độ cho phép bạn truy cập HIMEM hoặc của bạn RAMDISK, bạn đã bị mắc kẹt.

Bạn không thể quay lại và tiếp tục chạy DOS!

Và IBM thực sự đã gian lận PC của họ – bạn đã gửi lệnh đặc biệt này tới (tin hay không) bộ điều khiển bàn phím và về cơ bản bộ điều khiển bàn phím đã khởi động lại CPU.

Sau đó, khi CPU khởi động lại, BIOS cho biết, “Ồ, đó không phải là khởi động lại thực sự, đó là khởi động lại lén lút 'chuyển trái phép sang chế độ thực',” [CƯỜI] và nó quay trở lại nơi bạn đang ở trong DOS.

Vì vậy, vấn đề là, nó siêu kém hiệu quả.

Một điều khác với 286, mặc dù nó có thể truy cập tổng cộng 16 MB RAM, nhưng giống như 8086, nó chỉ có thể hoạt động trên tối đa 64 KB tại một thời điểm.

Vì vậy, giới hạn 64 kilobyte về cơ bản vẫn được nối vào DNA của bộ vi xử lý 286 đó.

Hóa ra nó thật hoành tráng và không cần thiết, phức tạp.

Thật đáng buồn, nó giống như một sản phẩm cực kỳ tuyệt vời, nhưng không thực sự phù hợp với nhu cầu của thị trường vào thời điểm đó.

CHÓ.   Nào, hãy bắt đầu với những câu chuyện đầu tiên của chúng ta.

Chúng tôi có một gói hai - đó là thời gian tội phạm.

Hãy nói về việc tắt máy và khóa máy, bắt đầu với việc FBI đóng máy Máy chủ ransomware Hive sau cùng.

Đó là tin tốt!

FBI cho biết các máy chủ ransomware Hive cuối cùng đã ngừng hoạt động

VỊT.   Có vẻ như vậy, phải không, Doug?

Mặc dù về cơ bản, chúng ta cần phải nói, như chúng ta vẫn luôn làm, rằng “tội phạm mạng ghê tởm khoảng không”.

Đáng buồn thay, các nhà khai thác khác xông vào khi một lô bị phá…

…hoặc nếu tất cả những gì xảy ra là máy chủ của họ bị gỡ xuống, và những người thực sự vận hành chúng không bị nhận dạng và bị bắt, thì điều thường xảy ra là họ chui đầu xuống lan can một lúc, rồi họ bật lên ở một nơi khác.

Đôi khi họ phát minh lại thương hiệu cũ, chỉ để coi thường thế giới.

Đôi khi họ sẽ trở lại với một cái tên mới.

Vì vậy, chuyện xảy ra với Hive – hóa ra FBI đã xâm nhập vào nhóm ransomware Hive, có lẽ bằng cách chiếm đoạt tài khoản của một số quản trị viên hệ thống và có vẻ như điều đó đã xảy ra vào giữa năm 2022.

Tuy nhiên, như chúng tôi đã nói trên podcast trước đây, với dark web, việc bạn có tài khoản của ai đó và bạn có thể đăng nhập bằng tài khoản của họ…

…bạn vẫn không thể tra cứu số IP của máy chủ mà bạn đang kết nối, vì dark web đang che giấu điều đó.

Vì vậy, có vẻ như trong phần đầu tiên của hoạt động này, FBI đã không thực sự xác định được vị trí của các máy chủ, mặc dù rõ ràng là họ có thể lấy được các khóa giải mã miễn phí cho khá nhiều người – tôi nghĩ là vài trăm nạn nhân.

Vì vậy, đó là một tin khá tốt!

Và sau đó, liệu đó có phải là một sai lầm trong hoạt động tình báo hay không, liệu họ chỉ gặp may mắn hay… chúng tôi không biết, nhưng có vẻ như cuối cùng họ đã tìm ra vị trí của các máy chủ và trò chơi lô tô!

Tắt!

CHÓ.   OK rất tốt.

Và sau đó là câu chuyện tội phạm thứ hai của chúng tôi.

Chúng tôi có một người Hà Lan nghi phạm bị bắt, bị buộc tội không chỉ vì hành vi trộm cắp dữ liệu cá nhân, mà còn [DOOM-LADEN VOICE] “siêu trộm cắp”, như bạn đã nói. Phao-lô:

Nghi phạm người Hà Lan bị nhốt vì cáo buộc siêu trộm dữ liệu cá nhân

VỊT.   Có!

Có vẻ như “công việc” của anh ấy là… anh ấy tìm dữ liệu, hoặc mua dữ liệu từ người khác, hoặc đột nhập vào các trang web và tự mình đánh cắp các đợt dữ liệu khổng lồ.

Sau đó, anh ta cắt nhỏ nó theo nhiều cách khác nhau và rao bán nó trên dark web.

Anh ta bị bắt vì công ty lo việc cấp phép truyền hình ở Áo (rất nhiều quốc gia châu Âu yêu cầu bạn phải có giấy phép để sở hữu và vận hành TV, về cơ bản là tài trợ cho truyền hình quốc gia)… những cơ sở dữ liệu đó gần như có mọi hộ gia đình, trừ một vài.

Các nhà chức trách Áo đã biết rằng có một cơ sở dữ liệu được rao bán trên dark web trông rất giống loại dữ liệu bạn sẽ nhận được – các trường và cách mọi thứ được định dạng… “Trông giống như của chúng tôi, trông giống như vậy Giấy phép truyền hình của Áo. Trời ơi!"

Vì vậy, họ đã làm một điều thực sự tuyệt vời, Doug.

Họ đã thực hiện một vụ mua lại bí mật, và trong quá trình đó, họ thực sự nắm được vị trí của người đó: “Có vẻ như người này có thể ở Amsterdam, Hà Lan.”

Và vì vậy họ đã liên lạc với những người bạn thân của họ trong cảnh sát Hà Lan, và người Hà Lan đã có thể nhận được trát tòa, tìm hiểu thêm, thực hiện một số cuộc đột kích và bắt giữ ai đó vì tội này.

Có lẽ bất thường, về cơ bản, họ có quyền từ tòa án để giữ anh chàng bí mật – tất cả đều là bí mật.

Anh ta vừa bị nhốt, không được tại ngoại – thực tế là họ vẫn còn vài tháng nữa, tôi nghĩ, họ có thể giữ anh ta.

Vì vậy, anh ấy sẽ không ra ngoài.

Tôi cho rằng họ lo lắng rằng [A] anh ấy có rất nhiều tiền điện tử nằm xung quanh, vì vậy anh ấy có thể sẽ làm kẻ chạy trốn, và [B] anh ấy có thể sẽ mách nước cho tất cả đồng bọn của mình trong thế giới ngầm.

Có vẻ như anh ta đã kiếm được rất nhiều tiền từ nó, bởi vì anh ta cũng bị buộc tội rửa tiền – cảnh sát Hà Lan tuyên bố có bằng chứng cho thấy cá nhân anh ta đã rút tiền mặt ở đâu đó trong khu vực trị giá nửa triệu euro tiền điện tử vào năm ngoái .

Vì vậy, có bạn!

Một lần nữa, có rất nhiều việc phải làm trong một cuộc điều tra.

CHÓ.   Vâng, thực sự.

OK, đây là câu cổ điển “Chúng tôi sẽ để mắt đến điều đó!” loại truyện.

Trong thời gian chờ đợi, chúng tôi gặp lỗi đăng nhập Samba nhắc nhở chúng tôi tại sao sự nhanh nhẹn về mật mã rất quan trọng:

Bảo mật nghiêm trọng: Lỗi đăng nhập Samba do tiền điện tử lỗi thời gây ra

VỊT.   Đó là một lời nhắc nhở rằng khi các bậc thầy về mật mã của thế giới nói, “Thuật toán XYZ không còn phù hợp với mục đích sử dụng nữa, vui lòng ngừng sử dụng nó”, và năm đó là – chúng ta có thể nói – giữa những năm 2000…

…nó rất đáng để lắng nghe!

Hãy chắc chắn rằng không có một số mã kế thừa kéo dài, bởi vì bạn nghĩ rằng, "Sẽ không có ai sử dụng nó."

Đây là quy trình đăng nhập trong mạng Microsoft Windows dựa trên thuật toán băm MD5.

Và vấn đề với thuật toán băm MD5 là quá dễ dàng để tạo hai tệp có hàm băm giống hệt nhau.

Điều đó không nên xảy ra!

Đối với tôi, để có được hai đầu vào riêng biệt có hàm băm giống hệt nhau, trên máy tính xách tay của tôi, tôi sẽ mất khoảng 10,000 năm…

CHÓ.   Khoảng! [CƯỜI]

VỊT.   Nhiều hơn hoặc ít hơn.

Tuy nhiên, chỉ riêng với bài viết đó, bằng cách sử dụng các công cụ do một nhà mật mã học người Hà Lan phát triển cho luận án Thạc sĩ của anh ấy vào năm 2007, tôi đã tạo *mười* tệp cặp băm MD5 xung đột…

…trong thời gian tối đa là 14 giây (đối với một trong số họ) và tối thiểu là dưới nửa giây.

Vì vậy, nhanh hơn hàng tỷ lần so với dự kiến.

Do đó, bạn có thể hoàn toàn chắc chắn rằng thuật toán băm MD5 *đơn giản là không đáp ứng được lời hứa của nó*.

Đó là cốt lõi của lỗi này.

Về cơ bản, ở giữa quá trình xác thực, có một phần nói rằng, “Bạn biết không, chúng tôi sẽ tạo mã thông báo xác thực siêu an toàn này từ dữ liệu do người dùng cung cấp và sử dụng khóa bí mật do người dùng cung cấp. Vì vậy, những gì chúng tôi sẽ làm là trước tiên chúng tôi sẽ thực hiện hàm băm MD5 của dữ liệu để làm cho dữ liệu đẹp và ngắn gọn, sau đó chúng tôi sẽ tạo mã xác thực *dựa trên hàm băm 128 bit đó.”

Về lý thuyết, nếu bạn là kẻ tấn công, bạn có thể tạo dữ liệu đầu vào thay thế *dữ liệu này sẽ tạo ra cùng hàm băm xác thực*.

Và điều đó có nghĩa là bạn có thể thuyết phục đầu bên kia, “Vâng, tôi *phải* biết khóa bí mật, nếu không thì làm sao tôi có thể tạo đúng mã xác thực được?”

Câu trả lời là: bạn ăn gian ở giữa quá trình, bằng cách cung cấp dữ liệu ngẫu nhiên xuất hiện cùng một hàm băm, đó là cơ sở của mã xác thực.

Thuật toán MD5 đã chết cách đây nhiều năm, nhưng nó vẫn tồn tại – và nó không nên tồn tại!

Vì vậy, việc sửa chữa là dễ dàng.

Samba chỉ nói, “Những gì chúng ta sẽ làm là, nếu bạn muốn sử dụng thuật toán cũ này, từ giờ trở đi, bạn sẽ phải nhảy qua các vòng để bật nó lên. Và nếu điều đó làm hỏng mọi thứ, và nếu đột nhiên bạn không thể đăng nhập vào mạng của chính mình vì bạn đang sử dụng bảo mật yếu mà không nhận ra điều đó… thì đó là cái giá mà tất cả chúng ta sẵn sàng trả.”

Và tôi đồng ý với điều đó.

CHÓ.   Được rồi, phiên bản 4.17.5 hiện áp dụng hai tùy chọn đó, vì vậy hãy ra ngoài đó và chọn tùy chọn đó nếu bạn chưa có.

Và cuối cùng, nhưng chắc chắn không kém phần quan trọng, chúng tôi đã có chứng chỉ ký mã bị đánh cắp từ GitHub.

Nhưng may mắn thay, có một lớp lót bạc ở đây:

Chứng chỉ ký mã GitHub bị đánh cắp (nhưng sẽ bị thu hồi trong tuần này)

VỊT.   Đã vài tháng xảy ra các vụ vi phạm đám mây và các cuộc tấn công chuỗi cung ứng tiềm ẩn.

CHÓ.   Nghiêm túc!

VỊT.   “Ôi trời, khóa ký bị đánh cắp”… GitHub nhận ra điều này đã xảy ra vào ngày 07 tháng 2022 năm XNUMX.

Bây giờ, ngả mũ trước họ, họ đã nhận ra ngay ngày hôm sau khi những kẻ lừa đảo đã đột nhập.

Vấn đề là họ đã không đi loanh quanh – có vẻ như khả năng truy cập của họ dựa trên thực tế là họ có thể tải xuống các kho GitHub riêng tư.

Đây không phải là hành vi vi phạm hệ thống GitHub, cơ sở hạ tầng GitHub hay cách GitHub lưu trữ tệp – chỉ là mã của GitHub trên GitHub… một số nội dung được cho là riêng tư đã bị tải xuống.

Và như chúng ta đã nói trước đây, vấn đề khi các kho lưu trữ mã nguồn được cho là riêng tư được tải xuống…

…vấn đề là, thường thì một cách đáng ngạc nhiên, những kho lưu trữ đó có thể chứa nội dung mà bạn không muốn công khai.

Ví dụ: mật khẩu cho các dịch vụ khác.

Và, quan trọng là, các phím ký mã – chiếc nhẫn ký tên của bạn, mà bạn sử dụng để đặt con dấu nhỏ của mình vào phần sáp của chương trình mà bạn thực sự xây dựng.

Ngay cả khi bạn là một dự án nguồn mở, bạn sẽ không đặt các khóa ký mã của mình vào phiên bản công khai của mã nguồn!

Vì vậy, đó là nỗi sợ hãi của GitHub: “Ôi trời. Chúng tôi đã tìm ra kẻ gian gần như ngay lập tức, nhưng chúng đã vào, chúng chộp lấy mã, chúng đi… do đó, thiệt hại đã xảy ra rồi.”

Họ đã mất khá nhiều thời gian, gần hai tháng, để tìm ra những gì họ có thể nói về điều này.

Hoặc ít nhất phải mất hai tháng cho đến khi họ nói bất cứ điều gì về nó.

Và có vẻ như những thứ duy nhất có thể ảnh hưởng đến những khách hàng đã bị đánh cắp thực sự là các khóa ký mã.

Chỉ có hai dự án bị ảnh hưởng.

Một là trình chỉnh sửa mã nguồn được gọi là “Atom”, Nguyên tử GitHub.

Điều đó về cơ bản đã được thay thế trong cuộc sống của hầu hết các nhà phát triển bởi Visual Studio Code [LAUGHS], vì vậy toàn bộ dự án đã ngừng hoạt động vào giữa năm 2022 và bản cập nhật bảo mật cuối cùng của nó là vào tháng 2022 năm XNUMX.

Vì vậy, có lẽ bạn không nên sử dụng Atom.

Và tin tốt là, vì họ sẽ không xây dựng nó nữa nên các chứng chỉ liên quan…

…hầu hết trong số họ đã hết hạn sử dụng.

Và cuối cùng, tôi nghĩ rằng GitHub đã phát hiện ra rằng chỉ có ba chứng chỉ bị đánh cắp thực sự vẫn còn hiệu lực, nói cách khác, những kẻ lừa đảo thực sự có thể sử dụng để ký bất kỳ thứ gì.

Và ba chứng chỉ đó đều được mã hóa.

Một trong số chúng đã hết hạn vào ngày 04 tháng 2023 năm XNUMX và có vẻ như kẻ gian không bẻ được mật khẩu đó, vì tôi không biết về bất kỳ phần mềm độc hại nào đã được ký với chứng chỉ đó trong khoảng trống giữa kẻ gian xâm nhập và chứng chỉ hết hạn một tháng sau.

Có một chứng chỉ thứ hai hết hạn vào ngày chúng tôi ghi podcast, Thứ Tư, ngày 01 tháng 2022 năm XNUMX; Tôi cũng không biết rằng người đó đã bị lạm dụng.

Ngoại lệ duy nhất trong tất cả những điều này là chứng chỉ ký mã, thật không may, không hết hạn cho đến năm 2027 và đó là để ký các chương trình của Apple.

Vì vậy, GitHub đã nói với Apple, “Hãy coi chừng bất kỳ thứ gì đi kèm được ký kết với điều đó.”

Và kể từ ngày 02 tháng 2022 năm XNUMX, tất cả các chứng chỉ ký mã đã bị đánh cắp (kể cả những chứng chỉ đã hết hạn) sẽ bị thu hồi.

Vì vậy, có vẻ như đây là một trường hợp “tất cả sẽ kết thúc tốt đẹp”.

Tất nhiên, có một tác dụng phụ nhỏ ở đây, đó là nếu bạn đang sử dụng GitHub Máy tính để bàn sản phẩm, hoặc nếu bạn vẫn đang sử dụng Nguyên tử trình chỉnh sửa, thì về cơ bản GitHub đang thu hồi các khóa ký *cho các ứng dụng của riêng họ*.

Trong trường hợp của GitHub Desktop, bạn nhất thiết phải nâng cấp, điều mà bạn vẫn nên làm.

Trớ trêu thay, vì Atom đã ngừng hoạt động… nếu bạn thực sự cần tiếp tục sử dụng nó, bạn thực sự phải hạ cấp một chút xuống phiên bản mới nhất của ứng dụng đã được ký bằng chứng chỉ sẽ không bị thu hồi.

Tôi có thể đã làm cho âm thanh đó phức tạp hơn thực tế…

…nhưng đó là một cái nhìn tồi tệ đối với GitHub, bởi vì chúng đã bị vi phạm.

Đó là một cái nhìn tồi tệ khác đối với GitHub có trong vụ vi phạm là chứng chỉ ký mã.

Nhưng đó là một cái nhìn tốt cho GitHub, bằng cách họ quản lý các chứng chỉ đó. hầu hết chúng đã không còn được sử dụng nữa.

Hai trong số ba điều có thể nguy hiểm sẽ hết hạn vào thời điểm bạn nghe podcast này và điều cuối cùng, theo cách nói của bạn, Doug, “họ đang thực sự để mắt đến.”

Ngoài ra, họ đã thu hồi tất cả các chứng chỉ, mặc dù thực tế là có hiệu ứng dây chuyền đối với mã của chính họ.

Vì vậy, về cơ bản, họ đang từ chối chứng chỉ của chính họ và một số chương trình đã ký của chính họ, vì lợi ích lớn hơn của tất cả.

Và tôi nghĩ điều đó thật tốt!

CHÓ.   Được rồi, GitHub làm tốt lắm.

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

Chà, nếu bạn còn nhớ từ tuần trước, chúng tôi đã cố gắng giúp độc giả Steven triển khai trình quản lý mật khẩu dựa trên khóa USB của riêng mình.

Dựa trên tình trạng khó khăn của mình, độc giả Paul hỏi:

Tại sao không lưu trữ mật khẩu của bạn trên thẻ nhớ USB có mã hóa phần cứng và bàn phím… trong trình quản lý mật khẩu di động chẳng hạn như KeePass? Không cần phải phát minh của riêng bạn, chỉ cần bỏ ra một vài đô la và giữ một bản sao lưu ở đâu đó, chẳng hạn như trong két sắt.

VỊT.   Không phải là một ý kiến ​​tồi đâu. Doug!

Tôi đã định mua và dùng thử một trong những ổ USB đặc biệt đó… bạn sẽ nhận được những ổ có kích thước bằng đĩa cứng (mặc dù ngày nay chúng thường có ổ SSD), nơi có nhiều chỗ cho bàn phím trên đầu ổ đĩa .

Nhưng bạn thậm chí còn nhận được các thanh USB và chúng thường có hai hàng năm phím hoặc hai hàng sáu phím cạnh nhau.

Nó không giống như những ổ USB thông thường, chẳng hạn như “Bao gồm phần mềm mã hóa miễn phí”, nằm trên thanh và sau đó bạn có thể cài đặt nó trên máy tính của mình.

Ý tưởng là nó giống như BitLocker hoặc FileVault hoặc LUKS, như chúng ta đã nói tuần trước.

Có một lớp mã hóa toàn bộ đĩa *bên trong vỏ ổ đĩa*, và ngay sau khi bạn rút phích cắm của nó, ngay cả khi bạn không ngắt kết nối đúng cách, nếu bạn chỉ cần rút nó ra khỏi máy tính…

…khi mất điện, chìa khóa sẽ bị xóa khỏi bộ nhớ và mọi thứ sẽ bị khóa lại.

Tôi đoán câu hỏi hóc búa là, “Chà, tại sao mọi người không sử dụng chúng làm chìa khóa USB, thay vì các thiết bị USB thông thường?”

Và có hai lý do: thứ nhất là nó rắc rối, và vấn đề khác là chúng đắt hơn nhiều so với các phím USB thông thường.

Vì vậy, tôi nghĩ, "Vâng, đó là một ý tưởng tuyệt vời."

Vấn đề là, bởi vì chúng không phải là sản phẩm chủ đạo nên tôi không có bất kỳ sản phẩm nào có thể giới thiệu – tôi chưa bao giờ thử một sản phẩm nào.

Và bạn không thể vào một cửa hàng PC bình thường và mua một cái.

Vì vậy, nếu bất kỳ người nghe nào có một thương hiệu, một loại hoặc một loại sản phẩm cụ thể mà họ sử dụng và thích…

…chúng tôi rất muốn nghe về nó, vì vậy hãy cho chúng tôi biết!

CHÓ.   OK, tuyệt vời.. Tôi thích một chút tìm nguồn cung ứng từ đám đông, mọi người giúp đỡ mọi người.

Cảm ơn bạn rất nhiều, Paul, 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, nhận xét về bất kỳ bài viết nào của chúng tôi hoặc liên hệ với 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]