Logo Zephyrnet

S3 Ep65: Mã hóa chuỗi cung ứng, lỗ hổng NetUSB, hồi tưởng về Honda, cơ FTC [Podcast + Transcript]

Ngày:

NGHE NÈ

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.

Với Doug Aamoth và Paul Ducklin. Nhạc giới thiệu và kết thúc bởi Edith Mudge.

Bạn có thể lắng nghe chúng tôi trên Soundcloud, Podcast của Apple, Google Podcasts, Spotify, người may quần áo và bất cứ nơi nào tìm thấy podcast tốt. Hoặc chỉ cần thả URL của nguồn cấp dữ liệu RSS của chúng tôi vào podcatcher yêu thích của bạn.

ĐỌC BẢNG BIỂU


CHÓ AAMOTH. JavaScript, NetUSB, Log4Shell, FTC…

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

[CHẾ ĐỘ ÂM NHẠC]

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

Tôi là Paul; anh ấy là Doug…


VỊT VỊT PAUL. [LAUGHING] Tôi nghĩ bạn đã mắc sai lầm thực sự ở đó, phải không?


CHÓ. Tôi đã làm.


VỊT. Nó không thực sự là một trò đùa.


CHÓ. * Tôi * Doug… Tôi vẫn đang lái tự động, như mọi khi, trong phút đầu tiên của chương trình.


VỊT. Chà, chúng ta sẽ nói về rất nhiều lỗi phần mềm… rất dễ mắc phải loại lỗi đó.


CHÓ. Chúng ta có rất nhiều điều để nói, vì vậy chúng ta sẽ đi sâu vào nó.

Hôm nay chúng ta có một cái gì đó giống như một vòng tròn chớp nhoáng; rất nhiều câu chuyện để bao gồm.

Và như bạn đã biết, chúng tôi muốn bắt đầu chương trình với một Sự thật thú vị: nếu bạn mê tín về Thứ Sáu ngày XNUMX, bạn sẽ không đơn độc trừ khi bạn sống ở Hy Lạp, Tây Ban Nha hoặc Ý.

Hy Lạp và Tây Ban Nha coi Thứ Ba ngày XNUMX là ngày xui xẻo nhất; Người Ý cảnh giác với Friday the Seventeeth; và Paul, như bạn biết, chúng tôi sẽ gắn điều này trở lại Tuần này trong lịch sử công nghệ phân đoạn sau trong chương trình.


VỊT. Chứng sợ Triskaideka!


CHÓ. Tôi đã thấy nó được viết ở một vài chỗ, và tôi rất vui vì bạn đã nói nó thành tiếng vì bạn hầu như không thể đọc được nếu bạn chưa nghe nó trước đây…


VỊT. Τρισκαίδεκα… nó chỉ là từ Hy Lạp cổ đại cho 13, với từ chỉ sự sợ hãi.

Vì vậy, thực ra, đó là nỗi sợ hãi của mười ba, chứ không nhất thiết chỉ là Thứ Sáu ngày XNUMX, nhưng chúng đại loại là đi cùng nhau.


CHÓ. Một ngày mà những điều ma quái và kỳ quặc xảy ra.

Và nói về sự ma quái và kỳ quặc, câu chuyện của “nhà phát triển JavaScript” này thật hoang đường!


VỊT. Tôi không biết liệu nó có ma quái hay không, nhưng có, nó rất kỳ quặc. Có lẽ hơi buồn một chút.


CHÓ. Vậy điều gì đã xảy ra ở đây?


VỊT. Chà, đó là những gì bạn có thể gọi là một cuộc tấn công chuỗi cung ứng, nơi mọi người đưa mã được viết bằng JavaScript vào các dự án của họ - từ NPM hoặc GitHub, hoặc bất cứ nơi nào họ lấy nó, từ một mô-đun nguồn mở được sử dụng bởi vô số dự án khác nhau, được phát hành theo giấy phép Mã nguồn mở của MIT.

Vì vậy, bạn có thể tự do sử dụng nó, miễn là bạn không khẳng định nó là của mình - bạn thậm chí có thể sử dụng nó trong mã thương mại.

Và nhà phát triển của hai dự án như vậy, faker.js và color.js, đột nhiên quyết định rằng mình đã có đủ.

Anh ấy đã đưa ra một số dấu hiệu, vài năm trước, rằng anh ấy hơi mệt mỏi khi làm tất cả công việc này và không được trả lương…

… Như phim hoạt hình XKCD nổi tiếng, Doug.


CHÓ. [LỪA DỐI]


VỊT. “Mọi thứ được hỗ trợ bởi trụ cột chương trình nhỏ mỏng này, được duy trì không mệt mỏi bởi một số người ngẫu nhiên ở Nebraska kể từ năm 2003” - * đó * phim hoạt hình XKCD.


CHÓ. Vâng.


VỊT. Anh chàng này rõ ràng đã quyết định, "Chà, tôi đã có đủ."

Vì vậy, đối với faker.js, về cơ bản, anh ấy chỉ rút phích cắm về toàn bộ vấn đề - anh ấy đã xóa tất cả mã nguồn.

Anh ấy đã tạo, nếu bạn thích, phiên bản cuối cùng của dự án không có mã nguồn trong đó; nó có chú thích "Endgame"; và nó chỉ nói trong README, "Điều gì đã xảy ra với Aaron Schwartz?"

Anh ta là kẻ hacktivist nổi tiếng, người đã rất buồn khi tự sát sau khi bị bắt vì lấy đi cả đống hồ sơ - những bài báo học thuật mà anh ta cảm thấy không nên đặt sau bức tường lửa, nhưng luật lại cho rằng khác.

Vì vậy, đó là những gì anh ấy đã làm với faker.js này

Và mặc dù nó là một cái tên kỳ lạ cho chương trình, nhưng nó thực sự là một thứ rất hữu ích vì nó tạo ra dữ liệu giả cho bạn.

Bạn đã nói về điều đó trong một podcast gần đây, phải không, Doug?

Về tầm quan trọng của việc không sử dụng dữ liệu thực để bạn không gặp rắc rối về quyền riêng tư.

Chà, anh ấy đã rút phích cắm trên cái đó, vì vậy nếu bạn cập nhật lên phiên bản mới nhất, tất cả sẽ biến mất.

Bạn không cần phải cập nhật - về mặt pháp lý, bạn được phép tiếp tục sử dụng cái cũ hơn - nhưng rõ ràng, anh ấy đã quyết định đã đến lúc phải rời khỏi Dodge City.

Nhưng với màu sắc. đầu ra bảng điều khiển của bạn.

Bạn biết mọi người thích màu sắc như thế nào để làm nổi bật các từ như LỖI, CẢNH BÁO, bất cứ điều gì.

Nhưng nếu bạn tự động chấp nhận bản cập nhật này, như một phần của cái mà bạn có thể gọi là chuỗi cung ứng của mình, thì đột nhiên chương trình của bạn sẽ bị Từ chối dịch vụ vì nó sẽ đi vào vòng lặp này chạy từ giá trị ban đầu là 666…


CHÓ. [LỪA DỐI]


VỊT. … Tối đa, nhưng không bao gồm, giá trị JavaScript Infinity.

Vòng lặp này in ra “thử nghiệm, thử nghiệm, thử nghiệm, thử nghiệm, thử nghiệm” với toàn bộ lượng rác được thêm vào.

Bạn có thể nói rằng đó không phải là một việc rất tốt để làm, nhưng bạn không cần phải chấp nhận phiên bản mới và mã ở đó để bạn xem: nó không bị ẩn theo bất kỳ cách nào.

Đó là mã nguồn mở, bạn có thể vào và xem lại nó.

Dù sao, một số người đã bị tấn công và phải hoàn nguyên về phiên bản cũ, và điều này bắt đầu một chuỗi bình luận trên tài khoản GitHub của anh ấy.

Tôi tin rằng anh ấy đã bị khóa tài khoản GitHub của mình, có lẽ dễ hiểu, nhưng có hàng trăm bình luận trên đó.

Một số người nói: “Ừ, anh đi cùng em, anh bạn”; Tôi biết bạn đến từ đâu ", và những người khác nói," Bạn biết không? Có lẽ là một bước quá xa ”.


CHÓ. Hãy nghĩ xem có bao nhiêu gói phần mềm thương mại dựa trên những thứ như thế này…


VỊT. Bạn gần như đã nói Log4j ở đó, Doug.


CHÓ. [LAUGHS] Hãy nói về điều đó một chút sau.


VỊT. Chà, tôi tự hỏi liệu thời gian của việc này có lẽ không bị kết thúc bởi sự ồn ào về Log4j>

Có lẽ đó là những gì đã kích động chương này?

Bởi vì sự hiểu biết của tôi là anh ấy đã cố gắng thương mại hóa bộ công cụ faker.js, rất hữu ích; khá nhiều mã có thể tạo ra dữ liệu thực tế thuộc mọi loại.

Anh ấy đã thử thương mại hóa nó và tạo ra các dịch vụ trực tuyến mà những người muốn trả tiền có thể trả tiền cho anh ấy, nhưng có vẻ như điều đó không hiệu quả với anh ấy và vì vậy nó không thực sự bền vững.

Vì vậy, anh ta rút phích cắm trên cái đó.

Nhưng thật không may, anh ta đã đầu độc cái giếng ở dự án kia, và đó là nơi chúng ta đang đứng.


CHÓ. Tôi cho rằng điều này làm nảy sinh câu hỏi về ý tưởng về một Hóa đơn phần mềm của vật liệuhoặc danh sách thành phần, nếu bạn muốn, cho người tiêu dùng hoặc những người sẽ mua phần mềm của bạn…

… Để họ có thể xem nó có bao nhiêu thành phần nguồn mở hoặc mọi thứ đến từ đâu.


VỊT. Vâng, có lẽ đó là lớp lót bạc trong này.

Log4j không giải quyết được vấn đề cơ bản: tính năng đó đã được thêm vào Log4j, vào năm 2013 thì sao?

Và không ai để ý đến điều đó cho đến tận bây giờ, và sau đó khi họ nói, "Ôi trời ơi, sao bạn dám?"

Chà, bạn đã nhập mã vào phần mềm của mình cách đây nhiều năm mà không nhận thấy nó có vấn đề này và bạn đã không trả tiền cho nó; Có thể hơi quá khi cho rằng đó là lỗi của bất kỳ ai ngoài lỗi của bạn, bởi vì bạn đã hiểu ra.

Vì vậy, có lẽ lớp lót bạc là vậy, mặc dù bạn có thể nói rằng đó là một việc làm trẻ sơ sinh nhưng có lẽ nó sẽ giúp tất cả chúng ta chấp nhận, như bạn nói, Hóa đơn phần mềm của vật liệu - "thành phần được liệt kê".

Có lẽ đó là một ý kiến ​​hay.


CHÓ. Được rồi, rất nhiều cuộc thảo luận tốt ở đó.

Câu chuyện đó tên là Nhà phát triển JavaScript phá hủy các dự án của chính họ trong "bài học" chuỗi cung ứng tại nakedsecurity.sophos.com

Vì vậy, bạn có thể đến đó để đọc và kiểm tra.

Và bây giờ chúng ta sẽ nói về NetUSB.

Tôi nhớ cảm giác hồi hộp khi cắm trực tiếp máy in của mình vào bộ định tuyến tại nhà qua cổng USB, cách đây bao nhiêu năm và nói, “Chà, chúng tôi đã thành công! Công nghệ cuối cùng đã đạt đến đỉnh cao của nó! ”


VỊT. NetUSB là một sản phẩm mà bạn có thể cấp phép từ một công ty ở Đài Loan có tên là Kcodes.

Họ tuyên bố trong tài liệu tiếp thị của mình rằng hiện tại hơn 20% thiết bị mạng trên toàn thế giới đã nhúng mã Kcodes vào chúng, vì vậy có vẻ như họ đã khá thành công.

Và NetUSB, nếu bạn thích, là một công cụ ảo hóa USB chung.

Vì vậy, bạn không chỉ có thể cắm một ổ cứng tập trung hoặc NAS, hoặc một máy in như bạn đã làm.

NetUSB có thể xử lý những thứ khác như bộ chỉnh TV, thiết bị âm thanh, tất cả các loại nội dung, một cách tập trung.

Vì vậy, có một loại cáp USB ảo chạy qua mạng của bạn, giữa máy tính của bạn và (không may) một trình điều khiển hạt nhân đặc biệt trên bộ định tuyến của bạn…

… Một trình điều khiển hóa ra có một lỗi trong đó, về lý thuyết, có thể cho phép hầu hết mọi người chiếm quyền điều khiển bộ định tuyến của bạn.

Trời ơi.


CHÓ. Ôi trời, đúng vậy.


VỊT. Vì vậy, lỗi đó đã được tìm thấy bởi một nhà nghiên cứu tên là Max van Amerongen tại Sentinel One.

Rõ ràng, anh ấy đang xem xét việc tham gia cuộc thi hack Pwn2Own IoT cho năm 2021.

Anh ta thấy rằng Netgear có một thiết bị trong danh sách, vì vậy anh ta nghĩ, “Ồ, tôi đã xem xét những thiết bị đó trước đây; Để tôi xem."

Anh ấy phát hiện ra rằng có một trình điều khiển nhân đang lắng nghe trên cổng TCP 20005… con số đó có vẻ là tùy ý, vì vậy đó không phải là một chỉ báo đáng tin cậy cho thấy bạn gặp sự cố này, nhưng nó có thể là điểm khởi đầu nếu bạn biết cách quét cổng. .

Và Max hình dung, “Này, danh sách trình điều khiển hạt nhân trên tất cả các giao diện mạng - localhost, LAN và WAN? Nếu có một lỗ hổng trong đó, nó có thể bị khai thác từ xa. Đó là nơi tôi sẽ bắt đầu tập trung. ”

Và vì vậy anh ấy đã đào sâu vào mã ở đó.

Như bạn tưởng tượng, một thứ giống như NetUSB - nó sẽ có rất nhiều chức năng khác nhau mà nó hỗ trợ.

Nếu bạn nghĩ về HTTP, thì, đó là hàng tá lệnh: GET, POST, HEAD, OPTION… nhưng một cái gì đó giống như NetUSB, với hàng chục loại thiết bị khác nhau, với hàng chục tính năng khác nhau, có thể hỗ trợ hàng trăm lệnh khác nhau.

Và anh ấy thấy rằng lệnh 0x805F - tôi nghĩ đó chỉ là tùy ý, 32863…

Lệnh đó, khi nó xử lý dữ liệu sẽ được gửi cho nó, có một lỗi nhỏ khó chịu, Douglas, liên quan đến số 17.

Về cơ bản, lỗi diễn ra như thế này.

Khi bạn muốn chạy lệnh này - lệnh liên quan đến một tin nhắn; Tôi không biết lệnh làm gì, bởi vì thực sự đó là quá trình xử lý trước gây ra sự cố, không phải chính lệnh…

… Điều đầu tiên mà trình điều khiển hạt nhân làm là nói, “Được rồi, tôi sẽ cần một số dữ liệu từ bạn. Hãy cho tôi biết bạn sẽ gửi bao nhiêu dữ liệu, ”và nó chấp nhận một giá trị bốn byte. (Bạn có thể thấy điều này đang diễn ra…)

Sau đó, nó phân bổ nhiều bộ nhớ.

Bây giờ, điều đó nghe có vẻ tệ vì nó không kiểm tra độ dài.

Điều gì sẽ xảy ra nếu người đó nói, "Ồ, tôi muốn phân bổ ba GB RAM?" [CON GÁI]

Bạn hãy tưởng tượng, trên bộ định tuyến gia đình bình thường, nó sẽ không hoạt động và sẽ hỏng hóc một cách duyên dáng.

Vấn đề là, nếu bạn nói, "Tôi muốn 4GB trừ đi một byte", nói cách khác là FFFFFFFF ở hệ thập lục phân.

Sau đó, thay vì cố gắng phân bổ nhiều byte đó, điều này rõ ràng sẽ không hoạt động vì bộ định tuyến 32 bit sẽ không có 4GB RAM để giao cho bạn…

… Mã sẽ làm gì, nó sẽ nói, “Chà, tôi sẽ cấp phát bao nhiêu bộ nhớ tùy thích trong trường hợp bạn cần nhiều như vậy, ngay cả khi bạn không sử dụng nó. Và tôi cần thêm 17 byte để sử dụng tạm thời của riêng mình. ”

Vì vậy, nó sẽ cấp phát một số nguyên dương không dấu, rất lớn * cộng với 17 byte * bộ nhớ.

Điều này sẽ xảy ra xung quanh, lỗi thiên niên kỷ hoặc phong cách đồng hồ đo đường ô tô.

Và vì vậy, kẻ tấn công có thể nói, "Tôi muốn bạn phân bổ cho tôi 4GB-1 byte RAM và điều đó có nghĩa là tôi có thể gửi cho bạn bất kỳ tin nhắn nào có kích thước lên đến số lượng đó trong tương lai."

Nhưng hạt nhân sau đó sẽ cấp phát một bộ đệm chỉ 16 byte, vì sự cố tràn số nguyên.

Sau đó, hạt nhân sẽ nói, “Đúng vậy, hãy gửi cho tôi dữ liệu của bạn,” và bạn gửi nó bao nhiêu tùy ý…

Tất nhiên, nếu sau đó bạn gửi nó nhiều hơn 16 byte, mà vô tình là tất cả những gì nó được cấp phát, thì bạn đã bị tràn bộ đệm bên trong hạt nhân!

Cảm ơn vì đã đến; trò chơi kết thúc.


CHÓ. Được rồi, có vẻ như chúng ta cần đợi bản cập nhật chương trình cơ sở!


VỊT. Vâng, tin tốt là điều này đã được tiết lộ một cách có trách nhiệm.

Lý do mà nó chỉ được viết vào năm nay, mặc dù công việc đã được thực hiện trở lại vào giữa năm 2021, là điều này đã được tiết lộ một cách có trách nhiệm cho công ty sản xuất sản phẩm NetUSB, và sau đó cho tất cả các nhà cung cấp có thể cấp phép cho họ. Mỹ phẩm.

Vì vậy, tất cả họ đều nhận thức được rằng có lỗi này và họ cần phải sửa nó.

Vì vậy, nó đã được tiết lộ một cách có trách nhiệm và có sẵn các bản vá.

Vấn đề duy nhất là: làm thế nào để bạn nhận ra liệu bạn có dễ bị tổn thương hay không?

Như tôi đã đề cập trước đó, bạn có thể thử sử dụng một chương trình như Nmap hoặc một cái gì đó, một máy quét cổng và xem liệu bạn có mở cổng 20005 trên bộ định tuyến của mình hay không, đó sẽ là một gợi ý tốt rằng bạn có thể có thứ này, vì đó là cách nhà nghiên cứu đã tìm thấy nó ngay từ đầu.

Nhưng, tất nhiên, đó chỉ là một triệu chứng: cho dù bạn mở hay đóng cổng đó không có nghĩa là bạn có hay không có lỗi.

Vì vậy, nếu bạn có bộ định tuyến hỗ trợ tính năng NetUSB này, cho phép bạn cắm không chỉ máy in mà gần như bất kỳ thiết bị USB nào ở trung tâm, thì hãy truy cập trang web của nhà cung cấp bộ định tuyến và kiểm tra xem có bản cập nhật hay không.


CHÓ. Được rồi, và chúng tôi có một số lời khuyên khác có thể giúp chúng tôi giảm thiểu tình trạng xấu như vậy trong tương lai.


VỊT. Đúng vậy, lời khuyên khác mà chúng tôi đưa ra trong bài viết là không dành cho người dùng bộ định tuyến gia đình có thể gặp rủi ro, nơi mà thực sự tất cả những gì chúng ta có thể nói là, “Vá sớm, vá thường xuyên; kiểm tra xem liệu có sẵn bản vá hay không. ”

Chúng tôi đưa ra một số lời khuyên cho các lập trình viên: ba điều nhanh chóng.

Thứ nhất, không nghe trên tất cả các giao diện mạng theo mặc định, trừ khi bạn thực sự cần.

Thứ hai, luôn kiểm tra kết quả của số học số nguyên, đặc biệt khi nó liên quan đến cấp phát bộ nhớ.

Và mẹo thứ ba là kiểm tra dòng số nguyên, cũng như tràn số nguyên.

Nếu bạn tưởng tượng đang chạy ngược lại đồng hồ đo đường ô tô cũ, thì số trước 000000 là 999999, không phải -1, vì đồng hồ đo đường ô tô không thể làm số âm.

Đừng nghĩ, “Nhất định phải có 17 byte trống”, bởi vì có thể không có…

… Bạn nợ người dùng của mình để kiểm tra.


CHÓ. OK.

Bài báo là: Các bộ định tuyến gia đình có hỗ trợ NetUSB có thể có lỗ hổng hạt nhân nghiêm trọng, trên nakedsecurity.sophos.com

Bây giờ là lúc cho Tuần này trong lịch sử công nghệ!

Chúng tôi đã nói về thứ Sáu ngày XNUMX trước đó trong chương trình….


VỊT. Tôi rất băn khoăn về chuyện này, và tôi nghĩ rằng nó sẽ liên quan đến virus máy tính, Doug. [CON GÁI]

Đó là sự nghi ngờ của tôi…


CHÓ. Làm sao bạn biết? [CON GÁI]

Tuần này, vào thứ Sáu, ngày 13 tháng 1989 năm XNUMX, một ngày thứ Sáu, virus thứ mười ba đã lây nhiễm các máy tính trên khắp nước Anh.

Đây không phải là thứ sáu đầu tiên của vi rút thứ mười ba, và nó có thể là một biến thể của vi rút được gọi là Jerusalem trước đó, vốn là một loại vi rút bom hẹn giờ sẽ phát nổ bắt đầu từ thứ sáu ngày 1988 tháng 1989. Năm XNUMX, tức là Thứ Sáu ngày XNUMX gần đây nhất trước tháng XNUMX năm XNUMX.

Cả hai loại virus đều làm chậm máy, nhưng chỉ còn lại COMMAND.COM.

Và Paul, bạn có một số màu sắc tuyệt vời về tất cả những thứ này bởi vì bạn đã sống qua nó. "Bạn đã ở đó, anh bạn."


VỊT. Lịch sử lặp lại như thế nào!

Ngày nay chúng ta có thể rút ra rất nhiều bài học từ những ngày đó, nhưng bài học về COMMAND.COM khá thú vị.

Từ bộ nhớ, một trong những tệp lây nhiễm vi rút sớm nhất trong thế giới DOS - tôi nghĩ nó có thể là vi rút Lehigh từ Hoa Kỳ - điều đó rất rõ ràng, bởi vì khi nó lây nhiễm tệp COMMAND.COM, chỉ có một số biến thể của COMMAND.COM và một số người đã ghi nhớ kích thước của tệp đó.

Vì vậy, từ nhanh chóng được đưa ra xung quanh, “Này, việc kinh doanh vi rút này thật tầm thường để giải quyết. Tất cả những gì bạn phải làm là xem kích thước của COMMAND.COM, và nếu nó thay đổi, bạn đã có vi rút! ”

Và suy luận mà mọi người được mời đưa ra là: nếu nó * không * thay đổi, thì bạn * chưa * bị nhiễm vi-rút.

Vì vậy, những gì những người viết virus bắt đầu làm gần như ngay lập tức?


CHÓ. [LỪA DỐI]


VỊT. Họ đã lây nhiễm mọi tệp * ngoại trừ * cho COMMAND.COM, vì đó là tệp mà mọi người đang tập trung vào.

Nhưng nó cho thấy rằng đây là một thời đại khác… khi bạn có thể đặt tên cho một loại vi-rút theo tên cả một * thành phố *, với giả định rằng có rất ít vi-rút đến nỗi chúng có khả năng là một vi-rút khác từ cùng một nơi?


CHÓ. Đúng, thời gian luôn thay đổi, và không phải lúc nào cũng tốt hơn.

Nói về thời gian thay đổi, có vẻ như Honda đang có một khoảnh khắc Y2K nhỏ của riêng mình, hoặc họ đã vô tình tạo ra một thứ hoạt động như một cỗ máy thời gian.


VỊT. Yêu công việc của bạn ở đó, Doug - đó là một người rất giỏi.


CHÓ. Cảm ơn bạn!


VỊT.Tôi biết điều gì sẽ đến tiếp theo và tôi không đoán trước được điều đó.

Vâng, cỗ máy thời gian của Honda.

Nó chắc chắn Trở về quá khứ, phải không? Không Chuyển đến tương lai.

Rõ ràng, những người sở hữu ô tô Honda ở một độ tuổi nhất định - không phải xe mới, cũng không phải xe cũ; những chiếc xe dường như phải ở đâu đó khoảng một thập kỷ…

… Vào ngày đầu năm mới 2022, khi mọi người bắt đầu khởi động ô tô của mình, một lúc sau đồng hồ sẽ tự quay trở lại một nơi nào đó vào khoảng nửa đêm ngày 01 tháng 2002 năm XNUMX.

Và tôi không nên nói điều này, bởi vì đó là một việc làm tàn nhẫn, nhưng tôi sẽ nói rằng nếu bạn không thể nhớ năm 2002…


CHÓ. Ồ, không, không, không….


VỊT. Tôi có được phép làm điều đó không?


CHÓ. Không!


VỊT. Giả sử có một bài hát trên bảng xếp hạng với ca từ “La la la, la la la la-la, la la la la-la la-la”, của ngôi sao nhạc pop người Úc Kylie Minogue nhỏ bé - đó là cách trở lại xa chúng tôi đã đi.

Và không ai biết tại sao.

Dự đoán tốt nhất cho đến nay dường như là nó liên quan đến thứ được gọi là GPS rollover, giống như cách mà lỗi Thiên niên kỷ do những người đi đường gây ra, “Bạn biết không? Chúng tôi sẽ chỉ suy luận 19 và sẽ sử dụng hai chữ số cho năm. "

Tất nhiên, GPS được phát minh vào những năm 1970, và băng thông từ các vệ tinh ở xa này là rất, rất hạn chế.

Và họ đã tìm ra, những gì chúng tôi sẽ làm là chúng tôi sẽ chạy trong khoảng thời gian 1024 tuần thay vì hàng năm.

Vì vậy, có một "số tuần", và chỉ có 10 bit khả dụng cho số tuần.

Vì vậy, cứ sau 1024 tuần, các thiết bị GPS kiểu cũ quay trở lại thứ mà bạn có thể gọi là Ngày số không.

Tôi gọi chúng là “kiloweekaries”, và những kilowwekaries đó có từ năm 1980 đến 1999; 1999 đến 2019; và 2019 đến 2039.

Bây giờ, đã có một lần thiết lập lại kiloweekary khét tiếng vào ngày 06 tháng 2019 năm 1999, nơi những người có máy thu GPS cũ đang tự hỏi, "Liệu họ có quay trở lại năm XNUMX không?"

Một số đã làm, một số thì không.

Nhưng tất nhiên, giống như Millennium Bug, bạn không cần phải bị tấn công bởi nó * chỉ vào thời gian quay vòng chính xác *.

Như bạn còn nhớ, với lỗi Millennium, điều mà rất nhiều phần mềm đã làm là giả định bất cứ điều gì trước năm 50 thực sự chuyển sang thiên niên kỷ tiếp theo.

Do đó, 50 có nghĩa là 1950, nhưng 49 có nghĩa là 2049 - vì vậy bạn vẫn có một lỗi Thiên niên kỷ, nhưng bạn thay đổi nó một chút.


CHÓ. Hãy để cho các thế hệ tương lai sẽ giải quyết nó!


VỊT. Chắc chắn rồi.

Tất nhiên, bạn có thể làm điều đó với GPS rollover, và đó là điều mà rất nhiều phần mềm làm.

Làm thế nào để bạn biết ngày bắt đầu sử dụng? Chà, cách rõ ràng để làm điều đó là sử dụng thời gian, ngày hoặc năm mà bạn biên dịch phần mềm hiện đang chạy trên thiết bị GPS - bởi vì điều đó không bao giờ có thể quay ngược lại.

Và vì vậy bạn có thể thực hiện một phép so sánh, “Tôi không mong đợi phần mềm này sẽ xuất hiện trước đó, chẳng hạn như năm 2003. Vì vậy, nếu bao giờ tôi thấy một năm đó là trước năm 2003, tôi sẽ cho rằng mình đã hết phạm vi."

Và những gì bạn đang làm là bạn đang tính toán một số ngày, tuần, tháng, năm kể từ khi bắt đầu khoảng thời gian GPS 1024 tuần - khoảng 20 năm; 19 năm, bảy tháng rưỡi….

… Về cơ bản bạn đang mất vài ngày và bạn chuyển chúng sang cuối chu kỳ kiloweekary hiện tại.

Và gợi ý rằng đó có thể là những gì đã khiến Honda ở đây.

Lý do mà tôi đoán là trường hợp này là do một độc giả của The Register, một ấn phẩm CNTT nổi tiếng ở Anh, đã nhận xét ở đó rằng anh ta có một chiếc Honda CR-V bị ảnh hưởng bởi điều này, và mỗi khi anh ta khởi động xe của mình. , thời gian quay ngược trở lại ngày 01 tháng 2002 năm XNUMX, như thể đồng hồ không biết phải làm gì.

Vì vậy, việc chọn thời điểm bắt đầu của năm như một mặc định. (Nhưng tất nhiên, vì đồng hồ được cung cấp bởi GPS, bạn không thể đặt nó theo cách thủ công.)

Trong trường hợp này, có vẻ như nó biết thời gian chính xác là bao nhiêu, nhưng nó không biết năm đó là năm nào, vì vậy nó đoán, "Tôi sẽ bắt đầu lúc nửa đêm, nhiều hơn hoặc ít hơn, cộng hoặc trừ tôi nghĩ bạn đang ở múi giờ nào. "

Rõ ràng, anh chàng này đã phát hiện ra rằng GPS của anh ta nghĩ rằng đó là tháng 2002 năm 1024, gần chính xác là XNUMX tuần trước, đó là điều khiến anh ta nghĩ rằng điều này có mùi giống như GPS rollover.


CHÓ. Hấp dẫn.


VỊT. Và đó là suy đoán tốt nhất mà tôi có thể nghĩ ra về cách điều này xảy ra: đó là do lỗi của Millennium gây ra, nhưng có liên quan đến một hạn chế được tích hợp trong GPS, có thể hiểu được, vào những năm 1970, bởi vì mỗi bit đều có giá trị khi bạn phải đưa nó qua không gian một cách đáng tin cậy.

Vậy, ai biết chuyện gì đã xảy ra, Doug?

Nhưng đó là một dấu hiệu cho bất kỳ lập trình viên nào rằng, khi bạn đang viết mã ngày hôm nay và bạn nghĩ, “Cơ hội mà mã mà tôi đang tạo ra ngày hôm nay sẽ vẫn được sử dụng vào năm 2042 là gì?”…

… Câu trả lời là * có thể * không, nhưng rất * có thể * có thể.


CHÓ. Bạn không bao giờ biết!


VỊT. Và do đó, những quyết định bạn đưa ra ngày hôm nay thực sự có thể ảnh hưởng đến những người ở phía trước.


CHÓ. “Xin hãy nghĩ đến những đứa trẻ,” bạn biết tôi muốn nói gì không?


VỊT. Chính xác!

Như lỗi thiên niên kỷ đã chứng minh; như những lỗi như thế này chứng tỏ: 20 năm vừa là một khoảng thời gian rất dài nhưng cũng là một khoảng thời gian khá ngắn nếu nói về tuổi thọ của phần mềm máy tính.


CHÓ. Chắc chắn rồi.

Được rồi, đó là một câu chuyện hấp dẫn - chúng tôi đã có và một số nhận xét tốt đang diễn ra, vì vậy hãy đến và đọc tất cả về nó: Những chiếc xe Honda hồi tưởng về năm 2002 - "Không thể đưa bạn ra khỏi đầu tôi".

Và bây giờ tôi đã mắc phải con sâu tai đó….


VỊT. Bạn đã nói như thế! Tôi không nghĩ rằng tôi thực sự đã sử dụng những từ đó.

Tôi vừa nói, [SINGS, FADING OUT OUT OUT GRADUALLY] “La la la, la la la la-la / La la la, la la…”


CHÓ. Chúng tôi không muốn thất vọng ở đây, nhưng rất tiếc, chúng tôi không có lỗi của Apple…


VỊT. [ANXIOUS] Tôi tự truyền tai nhau!


CHÓ. Bạn đã lấy tai mình?

Chúng tôi không có câu chuyện lỗi nào của Apple trong tuần này, nhưng chúng tôi không thể đưa ra câu chuyện về Log4Shell.

Vì vậy, có lẽ đó là câu chuyện bong bóng Apple mới của chúng tôi - chúng tôi có một vài trong số đó.


VỊT. Tôi hy vọng rằng Log4j sẽ đánh bật bài hát đó ra khỏi đầu tôi bởi vì tôi thực sự cảm thấy khó chịu, Doug, và tôi thực sự không thể phàn nàn, đúng không?


CHÓ. Không, thưa ngài!


VỊT. Aaaargh.

Được rồi, vì vậy nó không hoàn toàn là Log4j một lần nữa, nhưng đó là một lời nhắc nhở quan trọng.

Như bạn đã biết từ podcast tuần trước, chúng ta đã nói về cách khu vực công Hoa Kỳ ra quyết định, “Đêm trước Giáng sinh: bạn sẽ hoàn thành việc này vào lúc đó. Đừng bỏ nó. Làm nó ngay hôm nay. Nó sẽ không biến mất theo cách riêng của nó. "

Chà, năm mới đến; đến với Ủy ban Thương mại Liên bang - FTC về cơ bản là tổ chức bảo vệ quyền lợi người tiêu dùng của Hoa Kỳ, và nó đã đưa ra một lời nhắc nhở khá thú vị, nhỏ gọn cho các doanh nghiệp hoạt động trong các khu vực pháp lý của Hoa Kỳ.

Ngay cả khi bạn là nạn nhân của tội phạm mạng, thì nếu bạn có thể ngăn chặn nó bằng cách vá lỗi, và điều hợp lý là bạn sẽ làm như vậy, bạn cũng có thể phải chịu trách nhiệm chính.

Họ đã khá mạnh mẽ trong những gì họ đã nói, và cảnh báo bao gồm những từ này, Doug: “FTC dự định sử dụng toàn quyền pháp lý của mình để theo đuổi các công ty không thực hiện các bước hợp lý để bảo vệ dữ liệu của người tiêu dùng khỏi bị lộ do Log4j hoặc các lỗ hổng tương tự đã biết trong tương lai.”


CHÓ. Whoa!


VỊT. Không phải chỉ có Naked Security mới nói “Vá sớm, vá thường xuyên”!

Đó là FTC nhắc nhở bạn rằng sự thông cảm chỉ đi xa đến mức này, và bạn có thể vừa là nạn nhân vừa là kẻ thực hiện tội phạm mạng vì cùng một lý do - tức là không có bản vá.

Nó cho phép kẻ gian xâm nhập và chúng tôi sẽ cảm thấy tiếc cho bạn vì điều đó.

Nhưng nếu nó cho phép kẻ gian vào nơi mà bạn có thể dự kiến ​​sẽ giữ chúng lại một cách hợp lý, bằng cách thực hiện các biện pháp phòng ngừa mà thực tế là mọi người khác đã từng làm, thì có thể bạn sẽ phải mang theo can thiệp cho một số điều đó.


CHÓ. Được rồi, vì vậy khi họ nói “Log4j hoặc các lỗ hổng tương tự đã biết trong tương lai”, không lâu sau đó, chúng tôi đã có một lỗ hổng tương tự với lỗi H2 này.


VỊT. Có, tương tự như Log4Shell một cách đáng ngạc nhiên.

Và, trên thực tế, được tìm thấy bởi các nhà nghiên cứu đang xem xét mã Java cho các loại lập trình tương tự dẫn đến lỗ hổng Log4Shell ngay từ đầu.

Lỗi này, CVE-2021-42392, được phát hiện bởi một công ty quản lý chuỗi cung ứng có tên là JFrog.

Họ quyết định, "Này, hãy xem qua tất cả mã Java có thể chứa cách sử dụng tương tự của thứ JNDI này" - cái này Đặt tên và giao diện thư mục Java hóa ra có thể bị lạm dụng trong lỗi Log4j.

Và nếu bạn nhớ JNDI, đó là điều bạn thực sự nói, “Này, tôi muốn bạn tra cứu dữ liệu này. Ồ, tôi chưa có dữ liệu, nhưng tôi sẽ gửi cho bạn một URL của một số dữ liệu; trên thực tế, tôi sẽ gửi cho bạn một URL của một chương trình: hãy chạy chương trình đó và xem điều đó cho bạn biết điều gì ”.

JFrog, tôi đoán, đã tự hỏi có bao nhiêu chương trình khác có các phần mã của chúng mà chức năng tra cứu tên JNDI này có thể được sử dụng và có lẽ bị lạm dụng.

Thật không may, họ rất nhanh chóng tìm thấy một trong một công cụ cơ sở dữ liệu Java SQL phổ biến có tên là H2.

Bây giờ, tôi phải thành thật mà nói, Doug, tôi chưa nghe nói về H2 trước đây.


CHÓ. Không có tôi cũng không.


VỊT. Tôi đã nghe nói về MySQL, PostgreSQL, SQLite, tất cả những thứ cơ sở dữ liệu No-SQL.

Nhưng tôi chưa bao giờ nghe nói về H2 vì cùng một lý do, tôi chưa bao giờ thực sự nghe nói về Log4j: toàn bộ yêu cầu nổi tiếng của nó là nó là một thứ đủ nhỏ gọn - không giống như MySQL hoặc Microsoft SQL, nơi bạn chạy lên một máy chủ và kết nối với nó - này, bạn có thể đưa nó vào ứng dụng của mình, có H2 như một phần của ứng dụng của bạn.


CHÓ. Ồ tuyệt!


VỊT. Đó là một trong những điều khác mà các ứng dụng mà bạn có thể đã cài đặt - chúng có thể đã kéo điều này vào, giống như các ứng dụng Java có thể đã kéo vào Log4j.

Tin xấu là lỗi này hoạt động gần giống hệt như lỗ hổng Log4Shell: bạn nhận được thứ JNDI này, và thay vì chỉ thực hiện tra cứu cục bộ, bạn nói, “Này, bạn biết gì không? Để tra cứu, đây là một URL; đi lấy tệp lớp Java này và chạy nó. "

Vì vậy, đó là cùng một chuỗi các sự kiện dẫn đến khả năng khai thác.

Đó là tin xấu.

Tin tốt là, theo như tôi có thể nói, cách thực tế duy nhất mà kẻ tấn công có thể khai thác điều này là nếu chúng có thể xâm nhập và sửa đổi tệp cấu hình cho thành phần H2 này trên một trong các máy tính trong mạng của bạn.

Nói cách khác, đó là một sự nâng cao đặc quyền hoặc một thủ thuật di chuyển bên hơn là thực thi mã từ xa.

Bởi vì mặc dù bạn có thể sử dụng nó để thực thi mã từ xa nếu lỗ hổng được mở, bạn phải có quyền truy cập cục bộ để mở toàn bộ cho truy cập từ xa, nếu bạn hiểu ý tôi.


CHÓ. Vâng.


VỊT. Nói cách khác, bạn phải đột nhập vào mạng để có thể đột nhập vào mạng.

Nhưng nó vẫn là thứ bạn muốn vá, bởi vì nó là một tính năng do nhầm lẫn, giống như vấn đề Log4Shell.

Vì vậy, nó vẫn là một lỗi với việc vá lỗi; nó không hoàn toàn là thảm họa tiềm năng thực thi mã từ xa mà chúng ta đã thấy với Log4Shell.


CHÓ. OK, chúng tôi có một số lời khuyên.

Nếu bạn biết mình đang có một ứng dụng đang chạy công cụ cơ sở dữ liệu H2, bạn có thể nâng cấp lên phiên bản 2.0.206; hoặc nếu bạn không chắc chắn, bạn có thể tìm kiếm các bản sao của mã H2 trên mạng của mình.


VỊT. Vâng, đó là một chút giống như vấn đề Log4j, phải không?

Khi mọi người dừng lại để nghĩ về nó, họ nhận ra rằng họ thực sự không biết họ có bao nhiêu ứng dụng trong Java để bắt đầu; và sau đó họ không biết có bao nhiêu trong số đó đã bao gồm Log4j.

Khi họ đi tìm kiếm, họ nhận thấy, "Golly, có rất nhiều ứng dụng Java hơn chúng tôi nghĩ, và rất nhiều trong số họ tình cờ có Log4j."

Tương tự với H2 này: nó có thể nằm trong một hành động ứng dụng mà bạn không hề nhận ra.


CHÓ. Lại có Hóa đơn vật liệu đó - chúng ta cần Hóa đơn vật liệu đó!


VỊT. Chính xác!

Vì vậy, giống như bạn đã làm với Log4j, nơi bạn đang tìm kiếm log4j DASH bất cứ thứ gì…

… Ở đây bạn có thể tìm các tệp có tên là jar h2 DASH STAR DOT - đó là Kho lưu trữ Java.

Khi các tệp đó xuất hiện, nếu bạn có, chúng có thể sẽ xuất hiện một cái gì đó như h2 DASH hai DOT không DOT một số hoặc jar DOT khác.

Và như bạn đã nói, Doug, những gì bạn đang tìm kiếm là 2.0.206 trở lên.


CHÓ. Được rồi, tất cả mọi người!

Cái đó được gọi là Lỗ hổng bảo mật giống Log4Shell được tìm thấy trong công cụ cơ sở dữ liệu Java SQL phổ biến H2, trên nakedsecurity.sophos.com.


VỊT. Và đừng lấy nó từ chúng tôi mà bạn phải nhảy vào nó. Lấy nó từ FTC!


CHÓ. Vâng, rất nghiêm trọng! [LỪA DỐI]


VỊT. Tôi không muốn nói rằng họ đang đe dọa mọi người, nhưng họ đang nói, "Nó quan trọng."


CHÓ. Họ đang "thúc giục mạnh mẽ".

Và bạn có thể đọc thêm về điều đó trên nakedsecurity.sophos.com: FTC đe dọa hành động pháp lý đối với Log4j chưa được vá và các nội dung thô tục khác.

Và khi chúng ta kết thúc chương trình, đã đến lúc Ồ! Không! trong tuần.

Người dùng Reddit LordDragon24Aug965, viết…


VỊT. Đó là toàn bộ tên?


CHÓ. Đó là toàn bộ tên, vâng.


VỊT. Làm lại lần nữa, tôi không hiểu hết…


CHÓ. ChúaRồng24 tháng 1965 năm XNUMX…


VỊT. [SARCASTIC] Đó sẽ không phải là sinh nhật của anh ấy, phải không?


CHÓ. Có thể là như vậy, bởi vì anh ấy bắt đầu bằng câu nói, “Quay lại những ngày xưa cũ…” [LAUGHTER]

Tôi là công nghệ hỗ trợ điện thoại duy nhất cho một trong những nhà sản xuất máy tính nhái phổ biến từng quảng cáo trên các tạp chí máy tính.

Chúng tôi đã bán 200 máy tính cho một công ty phần mềm và chiếc đầu tiên đến trực tiếp VP của công ty để kiểm tra trong khi chúng tôi xây dựng phần còn lại của đơn đặt hàng.

Người đại diện bán hàng đến với tôi trong sự hoảng loạn, nói với tôi rằng chiếc máy mà tôi đã kiểm tra trước khi rời khỏi cửa hàng, sẽ không bật.

Tôi gọi điện cho VP nói rằng không có đèn trên máy gì cả.

Tôi yêu cầu họ nhìn vào phía sau và xem chiếc quạt cấp điện - loại quạt duy nhất trong những ngày đó - có quay không.

Anh ấy bảo tôi chờ - anh ấy phải bật đèn lên.

Bạn sẽ không biết nó?

Anh đã cắm nó vào một ổ cắm đã được chuyển mạch.

Và Paul, tôi muốn biết liệu điều này có hợp lý với bạn hay không….

Nó kết thúc bằng câu, "Người đại diện bán hàng đã mua bữa trưa cho tôi để tiết kiệm tiền hoa hồng của anh ấy."

Bạn thậm chí có khái niệm về "ổ cắm được chuyển đổi" trong cổ của bạn trong rừng?


VỊT. Trên thực tế, tôi nghĩ rằng trong mọi quyền hạn mà tôi từng sống trong đời…

… Tôi chưa gặp hiện tượng ổ cắm * không chuyển mạch *.


CHÓ. Ồ, đúng rồi, phải!


VỊT. Vì lý do an toàn, tại sao không có công tắc, vì vậy bạn có thể tắt nó đi?

Nó đặc biệt phù hợp ở Vương quốc Anh, nơi chúng tôi sử dụng nguồn điện vòng - nếu một cửa hàng đang hoạt động, tất cả chúng đều hoạt động.

Vì vậy, chúng tôi có các cửa hàng, theo tôi hiểu, được chuyển đổi theo luật.

Điều kỳ lạ mà chúng tôi gặp phải - ở hai trong số các quốc gia tôi đã sống có quy định - tôi không nghĩ ở Mỹ bạn có quy định đó - đó là bạn không được phép bật công tắc đèn trong phòng tắm.


CHÓ. Hấp dẫn.


VỊT. Bạn phải có một công tắc đèn thường xuyên bên ngoài phòng tắm, hoặc - phổ biến nhất là ở Anh - bạn có một công tắc kéo ở nơi công tắc ở trên trần nhà và nó hoạt động bằng một sợi dây không dẫn điện.

Nhưng bạn không được phép sử dụng công tắc - hoặc ổ cắm - trong phòng tắm.


CHÓ. Hấp dẫn!

Chà, hôm nay tôi đã học được rất nhiều, vì vậy cảm ơn bạn đã khai sáng cho tôi về điều này và tất cả những điều khác mà chúng ta đã nói về.

Và nếu bạn có một Ồ! Không! bạn 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ể bình luận 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]


Source: https://nakedsecurity.sophos.com/2022/01/13/s3-ep65-supply-chain-conniption-netusb-hole-honda-flashback-ftc-muscle-podcast-transcript/

tại chỗ_img

Tin tức mới nhất

tại chỗ_img

Trò chuyện trực tiếp với chúng tôi (chat)

Chào bạn! Làm thế nào để tôi giúp bạn?