Logo Zephyrnet

S3 Tập 126: Cái giá của thời trang nhanh (và tính năng leo thang) [Audio + Text]

Ngày:

GIÁ CỦA THỜI TRANG NHANH

Mười ba may mắn! Giá của thời trang nhanh. firefox nhất định. tính năng creep thất bại trong bản vá thứ ba.

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

Với Paul Ducklin và Chester Wisniewski. Nhạc intro và outro của 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Ế ĐỘ ÂM NHẠC]

VỊT.  Chào mọi người.

Chào mừng bạn đến với podcast Sophos Naked Security.

Như bạn có thể nghe, tôi là Vịt; Tôi không phải Doug (Doug đang đi nghỉ).

Vì vậy, tôi lại được tham gia cùng với người bạn và đồng nghiệp Chester Wisniewski của mình.

Chào mừng trở lại, Chester.

Thật tuyệt vời khi có bạn!


CHET.  Cảm ơn, Vịt.

Tôi chỉ đang nghĩ… thực ra, tôi đang nhìn vào màn hình của mình khi bạn đang giới thiệu podcast và nhận ra rằng hôm nay là kỷ niệm 13 năm ngày tôi bắt đầu podcast ChetChat, trước khi nó ngừng hoạt động và cuối cùng trở thành podcast này.

Vì vậy, bạn và tôi đã ở đây trong 13 năm!


VỊT.  13 may mắn nhỉ?


CHET.  Có!


VỊT.  Chà, thời gian trôi nhanh biết bao khi bạn vui vẻ.


CHET.  Vâng, và nó *rất* vui.

Và tôi cảm thấy thực sự vinh dự khi được ngồi vào ghế của Andy Greenberg.

Bạn đã thực sự đẩy mạnh trò chơi kể từ lần cuối tôi tham gia podcast [CƯỜI].


VỊT.  [CƯỜI] Nói chuyện cùng anh ấy là một người rất thú vị.

Tôi không biết liệu bạn đã đọc cuốn sách mà chúng tôi giới thiệu trên podcast với anh ấy chưa: Dấu vết trong bóng tối?

Tracers in the Dark: Cuộc săn lùng toàn cầu các lãnh chúa tội phạm của tiền điện tử


CHET.  Hoàn toàn có, có.


VỊT.  Đó chỉ là một câu chuyện hấp dẫn, được kể rất hay.


CHET.  Vâng, ý tôi là, đó chắc chắn là cuốn sách hay nhất về chủ đề này mà tôi đã đọc…

…có lẽ kể từ Countdown to Zero Day, và đó là một lời khen khá cao từ tôi.


VỊT.  Chester, chúng ta hãy bắt đầu với chủ đề đầu tiên của chúng ta ngày hôm nay, đó là… Tôi sẽ chỉ đọc tiêu đề của bài báo trên Naked Security: Ứng dụng mua sắm SHEIN trở nên lừa đảo, lấy dữ liệu giá và URL từ khay nhớ tạm của bạn.

Xin nhắc lại rằng ngay cả những ứng dụng không hoàn toàn độc hại cũng có thể thực hiện hành vi nguy hiểm thu thập dữ liệu vốn là một ý tưởng hay vào thời điểm đó…

…nhưng họ vui vẻ thì không nên có.

Ứng dụng mua sắm SHEIN trở nên lừa đảo, lấy dữ liệu giá và URL từ khay nhớ tạm của bạn


CHET.  Có – bất cứ thứ gì chạm vào khay nhớ tạm của tôi ngay lập tức làm rung lên trong đầu tôi tất cả các loại hồi chuông cảnh báo về những điều khủng khiếp mà tôi đang tưởng tượng rằng chúng đang làm.

Và nó đặt ra một câu hỏi, nếu tôi là một nhà phát triển, ngay cả khi tôi đang làm điều gì đó vô tội… mà tôi đoán chúng ta sẽ hiểu điều đó trong giây lát.

Thật khó để nói những gì họ đang cố gắng làm là ngây thơ như thế nào.


VỊT.  Chính xác.


CHET.  Khi bạn xin phép kiểu đó, tất cả các loại chuông cảnh báo sẽ vang lên trong đầu tôi.

Nó giống như trên điện thoại Android, trong một thời gian dài, để sử dụng Bluetooth để tìm thiết bị IoT, quyền bạn cần là “Truy cập thiết bị ở gần”, yêu cầu có Bluetooth.

Và bạn nhận được cảnh báo lông lá này trên màn hình, "Điều này muốn biết vị trí của bạn."

Và bạn sẽ hỏi, “Tại sao bóng đèn thông minh này cần biết vị trí của tôi?”

Khi bạn nói rằng bạn đang truy cập khay nhớ tạm của tôi, tâm trí tôi sẽ nghĩ: “Tại sao ứng dụng này lại cố lấy cắp mật khẩu của tôi?”

Có lẽ đó là điều mà chúng ta nên làm rõ cho mọi người…

…bởi vì tôi nghĩ khi bạn nói, “Đưa nội dung của khay nhớ tạm vào ứng dụng”, sẽ có lúc *bạn* đang làm việc đó (bạn có thể chọn sao chép mật khẩu của mình hoặc có thể là mã hai yếu tố SMS đó từ Tin nhắn app rồi dán vào ứng dụng mà bạn đang xác thực)…


VỊT.  Vâng.


CHET.  Đó *không phải* những gì chúng ta đang nói đến khi nói về sự cho phép này, phải không?

Quyền này là bản thân ứng dụng chỉ xem nội dung khay nhớ tạm hiện có của bạn bất kỳ lúc nào nó chọn…

…không phải khi bạn đang tích cực tương tác với ứng dụng và nhấn lâu và nói, “Dán”.


VỊT.  Chính xác.

Về cơ bản, nó đang dán khi bạn không có ý định đó.

Cho dù dữ liệu mà bạn đã chọn sao chép vào khay nhớ tạm có vô hại đến đâu, thì thực sự không nên để một ứng dụng ngẫu nhiên nào đó quyết định, “Này, tôi sẽ dán nó vì tôi cảm thấy thích. ”

Và điều đặc biệt đáng lo ngại là về cơ bản, nó đã dán nó vào một yêu cầu web mà nó đã gửi tới một số API tiếp thị RESTful tại trụ sở chính!


CHET.  Đó thậm chí không phải là một hành vi mong đợi, phải không, Vịt?

Ý tôi là, nếu tôi đang sử dụng ứng dụng ngân hàng của mình và nó yêu cầu mã từ tin nhắn văn bản…

…Tôi có thể thấy nó sẽ yêu cầu ứng dụng tin nhắn văn bản sao chép nó vào khay nhớ tạm và tự động dán nó vào như thế nào để làm cho quy trình đó trở nên đơn giản.

Nhưng tôi sẽ không bao giờ mong đợi bất cứ thứ gì từ khay nhớ tạm của mình sẽ xuất hiện trong một ứng dụng thời trang!

Chà, đừng sử dụng ứng dụng nếu bạn không cần chúng.

Đó là, tôi nghĩ, một vấn đề lớn ở đây.

Tôi thấy liên tục, khi tôi truy cập bất kỳ loại trang web mua sắm nào, tôi nhận được một số cửa sổ bật lên kinh hoàng trong Firefox trên điện thoại của mình với nội dung: “Tôi có muốn cài đặt ứng dụng không? Tại sao tôi không truy cập trang web thông qua ứng dụng? Tôi có thích sử dụng ứng dụng hơn không?”

Và câu trả lời là KHÔNG, KHÔNG và KHÔNG, bởi vì đây là điều xảy ra khi bạn có mã không đáng tin cậy.

Tôi không thể tin vào mã chỉ vì Google nói nó ổn.

Chúng tôi biết rằng Google không có bất kỳ ứng dụng sàng lọc con người thực tế nào… Google đang được điều hành bởi một số quái vật Google Chat-GPT hoặc thứ gì đó tương tự.

Vì vậy, mọi thứ chỉ được sàng lọc theo bất kỳ cách nào mà Google thấy phù hợp để sàng lọc chúng và sau đó chúng sẽ xuất hiện trong Cửa hàng Play.

Vì vậy, tôi chỉ không thích bất kỳ mã đó.

Ý tôi là, có những ứng dụng tôi phải tải trên thiết bị của mình hoặc những thứ mà tôi cảm thấy tin tưởng hơn dựa trên nhà xuất bản…

…nhưng nói chung, chỉ cần vào trang web!


VỊT.  Bất cứ ai nghe podcast Naked Security đều biết, kể từ khi chúng ta nói về những thứ như trình duyệt zero-day, các nhà sản xuất trình duyệt đã nỗ lực như thế nào để tìm và loại bỏ lỗi khỏi mã của họ.


CHET.  Và mọi người cũng có thể nhớ rằng ngày nay bạn cũng có thể làm cho hầu hết mọi trang web hoạt động giống như một ứng dụng.

Có những gì được gọi là Ứng dụng web lũy tiến hoặc PWA.


VỊT.  Chester, chúng ta hãy chuyển sang câu chuyện tiếp theo của tuần trước, một câu chuyện mà tôi nghĩ là thú vị.

Tôi viết cái này chỉ vì tôi thích con số, và có một số vấn đề thú vị trong đó, đó là: Phiên bản Firefox 111 đã sửa 11 lỗ hổng CVE, nhưng không có 1 lỗ hổng nào.

(Và đó là lời bào chữa của tôi cho việc tiêu đề có chữ số 1 lặp lại sáu lần.) [CƯỜI]

Firefox 111 vá 11 lỗ hổng, nhưng không có lỗ hổng nào trong số đó…


CHET.  [CƯA] Tôi là một người hâm mộ Firefox và thật tuyệt khi thấy rằng không có gì được phát hiện đang bị khai thác tích cực.

Nhưng phần tốt nhất về điều này là chúng bao gồm những vấn đề về an toàn bộ nhớ đã được phát hiện một cách phòng ngừa, phải không?

Họ không ghi nhận chúng cho một người hoặc bên ngoài đã phát hiện ra điều gì đó và báo cáo điều đó cho họ.

Họ chỉ đang tích cực tìm kiếm và cho chúng tôi biết rằng họ đang giải quyết các vấn đề về an toàn bộ nhớ…

… mà tôi nghĩ là thực sự tốt.


VỊT.  Điều tôi thích ở Mozilla là cứ bốn tuần một lần, khi họ thực hiện cập nhật lớn, họ sẽ loại bỏ tất cả các lỗi an toàn bộ nhớ, đặt chúng vào một giỏ nhỏ và nói, “Bạn biết gì không? Chúng tôi đã không thực sự cố gắng tìm hiểu xem những thứ này có thể bị khai thác hay không, nhưng chúng tôi vẫn sẽ cung cấp cho chúng một số CVE…

…và thừa nhận rằng mặc dù những điều này có thể không thực sự bị khai thác, nhưng cũng đáng để giả định rằng nếu ai đó đủ cố gắng, hoặc có ý chí, hoặc có tiền đằng sau họ, hoặc chỉ muốn đủ để làm như vậy (và có những người trong tất cả những điều đó danh mục), bạn phải giả định rằng họ sẽ tìm cách khai thác một trong những thứ này theo cách gây bất lợi cho bạn.”

Và bạn đã có một câu chuyện nhỏ về thứ gì đó mà bạn thích, từ Firefox hoặc Mozilla, ổn định…


CHET.  Chắc chắn rồi - tôi chỉ đang nghĩ về điều đó.

Chúng tôi đã nói chuyện, trước podcast, về một dự án có tên là Servo mà Firefox (hoặc Mozilla Foundation, cuối cùng) đã tạo ra.

Và, như bạn nói, đó là một công cụ kết xuất công cụ trình duyệt (hiện tại công cụ trong Mozilla Firefox có tên là Gecko)… ý tưởng là viết công cụ kết xuất hoàn toàn bằng Rust, và trên thực tế, đây là nguồn cảm hứng để tạo ra ngôn ngữ lập trình Rust.

Điểm quan trọng ở đây là Rust là một ngôn ngữ an toàn cho bộ nhớ.

Bạn không thể mắc lỗi đang được sửa trong các CVE này.

Vì vậy, trong một thế giới mơ ước, bạn sẽ làm blog cập nhật Firefox này mà không có CVE an toàn bộ nhớ.

Và tôi rất phấn khích khi thấy một số khoản tài trợ đã được chuyển đến Quỹ Linux để tiếp tục phát triển Servo.

Có thể trong tương lai, đó sẽ là một công cụ Firefox mới giúp chúng ta an toàn hơn nữa?


VỊT.  Có!

Hãy nói rõ ràng – chỉ vì bạn viết mã bằng Rust không làm cho nó đúng và nó không làm cho mã miễn nhiễm với các lỗ hổng.

Nhưng, như bạn nói, có đủ loại vấn đề, đặc biệt liên quan đến quản lý bộ nhớ, như bạn nói, khó thực hiện hơn rất nhiều.

Và trong mã được viết tốt, ngay cả tại thời điểm biên dịch, trình biên dịch sẽ có thể thấy rằng “điều này không đúng”.

Và nếu điều đó có thể được thực hiện tự động, không có tất cả chi phí mà bạn cần trong một ngôn ngữ kịch bản thực hiện một số việc như thu gom rác, để bạn vẫn có được hiệu suất tốt, điều đó sẽ rất thú vị.

Tôi chỉ tự hỏi nó sẽ mất bao lâu?


CHET.  Có vẻ như họ đang cắn từng miếng nhỏ.

Mục tiêu đầu tiên là làm cho kết xuất CSS2 hoạt động, và giống như bạn phải xem mỗi thứ như một khối công việc nhỏ, và tách nó ra khỏi sự quái dị khổng lồ là một công cụ kết xuất hiện đại… và cắn một miếng nhỏ.

Và tài trợ cho những dự án đó thực sự quan trọng, phải không?

Rất nhiều thứ nhúng công cụ trình duyệt; rất nhiều sản phẩm dựa trên công cụ Gecko, cũng như Blink của Google và Webkit của Apple.

Và do đó, cạnh tranh hơn, hiệu suất cao hơn, an toàn bộ nhớ hơn...tất cả đều tốt!


VỊT.  Vì vậy, chúng ta hãy chuyển sang chủ đề cuối cùng của tuần, mà tôi đoán là câu chuyện lớn…

…nhưng điều thú vị về nó, như những câu chuyện lớn, là mặc dù nó có một số lỗi hấp dẫn trong đó, và mặc dù cả hai lỗi mà chúng ta có thể sẽ nói đến đều là zero-day về mặt kỹ thuật, nhưng chúng không phải là thảm họa .

Chúng chỉ là một lời nhắc nhở tốt về loại vấn đề mà lỗi có thể gây ra.

Và chủ đề đó, tất nhiên, là Patch Tuesday.

Microsoft sửa hai lỗi 0 ngày vào Bản vá Thứ Ba – cập nhật ngay bây giờ!


CHET.  Chà, tôi sẽ gây tranh cãi và nói về đánh dấu trang web lỗi đầu tiên.


VỊT.  [CƯỜI] Cái tên nghe hấp dẫn quá phải không?

Tất cả chúng ta đều biết đó là “Internet Zones”, giống như Internet Explorer ngày xưa.

Nhưng “Mark of the Web”… nghe có vẻ hoành tráng hơn, thú vị hơn và quan trọng hơn nhiều!


CHET.  Chà, đối với bạn, những người quản trị Internet Explorer (IE), bạn có thể nhớ rằng bạn có thể đặt cái này ở Vùng tin cậy; trong Vùng Intranet; khác trong Vùng Internet.

Chúng ta đang nói về cài đặt đó.

Nhưng điều đó không chỉ tồn tại trong Internet Explorer, nó còn được quan sát bởi nhiều quy trình khác của Microsoft, để đưa ra nguồn gốc xuất xứ của một tệp…

…về khái niệm rằng các tệp bên ngoài nguy hiểm hơn nhiều so với các tệp bên trong.

Và vì vậy, chính tiền đề này tôi không đồng ý.

Tôi nghĩ đó là một điều ngu ngốc!

Tất cả các tệp đều nguy hiểm!

Không quan trọng bạn tìm thấy chúng ở đâu: trong bãi đậu xe trên một ổ đĩa ngón tay cái; trên mạng LAN; hoặc trên một trang web.

Tại sao chúng ta không đối xử với tất cả bọn họ như thể họ không đáng tin cậy, và không làm những điều tồi tệ?


VỊT.  Tôi nghĩ rằng tôi có thể thấy Microsoft đến từ đâu ở đây và tôi biết rằng Apple cũng có một thứ tương tự… bạn tải xuống một tệp, bạn để nó nằm trong một thư mục ở đâu đó và sau đó ba tuần bạn quay lại với nó.

Nhưng tôi nghĩ rằng tôi có xu hướng đồng ý với bạn rằng khi bạn bắt đầu, “Ồ, tệp đó đến từ bên trong tường lửa, vì vậy nó phải được tin cậy”…

…đó là một lần nữa “nội thất mềm dai” lỗi thời!


CHET.  Vâng.

Vì vậy, đó là lý do tại sao những loại lỗi cho phép bạn bỏ qua Mark of the Web lại có vấn đề, phải không?

Nhiều quản trị viên sẽ có chính sách nhóm có nội dung: “Microsoft Office không thể thực thi macro trên các tệp có Mark of the Web, nhưng không có Mark of the Web, chúng tôi cho phép bạn chạy macro, vì bộ phận tài chính sử dụng chúng trong bảng tính Excel và tất cả các nhà quản lý phải truy cập chúng.”

Loại tình huống này… thật không may, nó phụ thuộc vào việc biết rằng tệp đó là từ bên trong hay bên ngoài.

Và vì vậy tôi đoán những gì tôi đang hướng tới, những gì tôi đang phàn nàn, là: lỗ hổng này cho phép mọi người gửi cho bạn các tệp từ bên ngoài và không đánh dấu chúng như thể chúng đến từ bên ngoài.

Và bởi vì điều này có thể xảy ra, và nó đã xảy ra, và bởi vì có những cách khác mà điều này cũng có thể xảy ra, mà bạn vui lòng chỉ ra trong bài viết Bảo mật Trần trụi của mình…

…điều đó có nghĩa là chính sách của bạn phải là: nếu bạn cho rằng macro có thể nguy hiểm, thì bạn nên chặn chúng hoặc buộc lời nhắc bật chúng, *bất kể chúng bắt nguồn từ đâu*.

Bạn không nên có một chính sách phân biệt giữa bên trong và bên ngoài, bởi vì nó chỉ khiến bạn có nguy cơ bị bỏ qua.


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

Tôi đoán điểm mấu chốt ở đây là mặc dù bỏ qua “nhãn hiệu” Mark of the Web này (nhãn Vùng Internet trên một tệp)… mặc dù đó là thứ rõ ràng hữu ích đối với kẻ gian, bởi vì chúng biết một số người dựa vào, *nó loại thất bại mà bạn cần phải lên kế hoạch*.

Tôi có ý tưởng về Mark of the Web và tôi không nghĩ đó là một ý kiến ​​tồi.

Tôi sẽ không sử dụng nó như một công cụ phân biệt đối xử an ninh mạng quan trọng hoặc quan trọng.


CHET.  Chà, và để nhắc nhở các quản trị viên CNTT…

…cách tốt nhất để giải quyết vấn đề này không phải là nhìn vào Mark of the Web.

Cách tiếp cận tốt nhất là ký tên vào các macro nội bộ của bạn để bạn biết nên tin tưởng cái nào và chặn tất cả phần còn lại của chúng.


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

Tại sao bạn không cho phép những thứ mà bạn biết là mình thực sự cần, và rằng bạn có lý do chính đáng để tin tưởng…

…và như bạn nói, không cho phép mọi thứ khác?

Tôi cho rằng một câu trả lời là, “Khó hơn một chút”, phải không?

Nó không hoàn toàn thuận tiện…


CHET.  Chà, điều này dẫn đến một lỗ hổng khác, cho phép bọn tội phạm khai thác Microsoft Outlook theo cách có thể cho phép…

…Tôi đoán, một cuộc tấn công mạo danh?

Đó có phải là cách bạn đề cập đến nó không, Vịt?


VỊT.  Tôi coi đây là một kiểu tấn công Kẻ thao túng ở giữa (MitM).

Thuật ngữ mà tôi thường nghe được sử dụng và Microsoft sử dụng… họ gọi nó là tấn công tiếp sức, về cơ bản, bạn lừa ai đó xác thực với *bạn*, trong khi *bạn* xác thực thay mặt họ, với tư cách là họ, ở hậu trường, với máy chủ thực.

Đó là mánh khóe - về cơ bản, bạn sẽ thuyết phục được ai đó, mà không nhận ra, nói: “Này, tôi cần đăng nhập vào máy chủ này mà tôi chưa từng nghe đến trước đây. Thật là một ý tưởng hay! Hãy để tôi gửi cho họ một hàm băm mật khẩu của tôi!

Điều gì có thể đi sai?

Khá nhiều…


CHET.  Đó là một ví dụ tuyệt vời khác về chính sách hạn chế so với chính sách dễ dãi, phải không?

Nếu tường lửa của bạn không được định cấu hình để cho phép lưu lượng truy cập SMB (khối thông báo máy chủ) gửi đi, thì bạn sẽ không gặp rủi ro từ lỗ hổng này.

Không phải là bạn không nên vá nó… bạn vẫn nên vá nó, bởi vì máy tính ở rất nhiều nơi xảy ra đủ loại sự cố mạng kỳ quặc.

Tuy nhiên, ý tưởng là nếu chính sách của bạn là "Chặn mọi thứ và chỉ cho phép những điều lẽ ra phải xảy ra", thì bạn sẽ ít gặp rủi ro hơn trong trường hợp này so với khi chính sách cho phép và bạn đang nói: "Chúng tôi sẽ cho phép mọi thứ, ngoại trừ những thứ mà chúng tôi đã xác định là xấu.”

Bởi vì khi một zero-day xuất hiện, không ai xác định nó là xấu.

Đó là lý do tại sao đó là một ngày không!


VỊT.  Chính xác.

Tại sao bạn lại muốn mọi người đăng nhập vào các máy chủ bên ngoài ngẫu nhiên?

Ngay cả khi họ không ác ý, tại sao bạn lại muốn họ trải qua một loại xác thực kiểu công ty, với thông tin đăng nhập công ty của họ, tới một số máy chủ không thuộc về bạn?

Phải nói rằng, Chester, tôi đoán nếu bạn đang nghĩ về "trung tâm mềm dẻo", có một cách mà những kẻ lừa đảo đã ở trong mạng của bạn và có một chút chỗ đứng, có thể sử dụng điều này bên trong mạng …

…bằng cách thiết lập một máy chủ tệp lừa đảo và lừa bạn kết nối với máy chủ đó.


CHET.  [CƯỜI] Đó có phải là BYOD không?

Mang theo bộ chứa Docker của riêng bạn?


VỊT.  [CƯỜI] Chà, tôi thực sự không nên cười ở đó, nhưng đó là một điều khá phổ biến với những kẻ lừa đảo ngày nay, phải không?

Nếu họ muốn tránh bị phát hiện những thứ như phần mềm độc hại, thì họ sẽ sử dụng cái mà chúng tôi gọi là kỹ thuật “sống xa xứ” và chỉ mượn các công cụ mà bạn đã cài đặt sẵn…

…như curl, bash, PowerShell và các lệnh hoàn toàn có ở mọi nơi.

Mặt khác, nếu có thể, họ sẽ kích hoạt một VM [máy ảo]…

…nếu bằng cách nào đó, họ có quyền truy cập vào cụm máy ảo của bạn và họ có thể thiết lập một máy ảo trông có vẻ bình thường, thì họ sẽ chạy phần mềm độc hại bên trong máy ảo đó.

Hoặc bộ chứa docker của chúng sẽ được định cấu hình hoàn toàn khác với bất kỳ thứ gì khác mà bạn có.

Vì vậy, vâng, tôi đoán bạn đúng: đó là cách mà bạn có thể khai thác điều này trong nội bộ.

Nhưng tôi nghĩ đó là một lỗi hấp dẫn, bởi vì thông thường khi mọi người nghĩ về các cuộc tấn công bằng email, họ thường nghĩ: “Tôi nhận được email, nhưng để bị pwned, tôi phải mở tệp đính kèm hoặc nhấp vào liên kết”.

Nhưng cái này, tôi tin rằng, có thể kích hoạt trong khi Outlook đang chuẩn bị email, thậm chí trước khi nó hiển thị nó cho bạn!

Đó là khá khó chịu, phải không?


CHET.  Vâng.

Tôi nghĩ thời của những loại lỗi này đã không còn nữa khi chúng tôi loại bỏ các plugin JavaScript và ActiveX trong ứng dụng email của mình.


VỊT.  Tôi nghĩ bạn sẽ nói "Flash" một lúc ở đó, Chester. [CƯỜI]


CHET.  [LỪA DỐI]

Chà, đối với các nhà phát triển, điều quan trọng cần nhớ là những loại lỗi này là do lỗi tính năng.

Ý tôi là, lý do email trở nên an toàn hơn là do chúng tôi đã thực sự loại bỏ các tính năng, phải không?


VỊT.  Chính xác.


CHET.  Chúng tôi đã loại bỏ ActiveX và JavaScript, và tất cả những thứ này…

…và sau đó cái nút này được kích hoạt bởi âm thanh “đã nhận được email mới” là một biến có thể được gửi bởi người gửi email.

Tôi không biết ai, ở hành tinh nào đã nghĩ, “Nghe có vẻ là một tính năng hay.”


VỊT.  Bằng chứng về khái niệm mà tôi đã thấy cho điều này, được sản xuất bởi (tôi nghĩ) một công ty thử nghiệm thâm nhập… đó là cách họ đã làm.

Vì vậy, có vẻ như những kẻ lừa đảo đang khai thác điều này, đó là cách mà *họ* đã làm.

Nhưng rõ ràng đó không phải là tính năng duy nhất có thể bị lạm dụng.

Tôi hiểu rằng nếu bạn có thể nói, “Đây là tên tệp mà tôi muốn bạn sử dụng”, thì tên tệp đó, rõ ràng là…

…à, bạn có thể đặt một đường dẫn UNC vào đó, phải không?

\SOMEBODY.ELSES.SERVER.NAME… và nó sẽ được Outlook truy cập.

Vì vậy, bạn nói đúng: nó thực sự nghe có vẻ giống tính năng đáng sợ.

Và, như tôi đã nói, tôi tự hỏi có bao nhiêu tính năng bị bỏ lỡ khác có thể áp dụng cho điều này và liệu những tính năng đó có được vá không?

Microsoft hơi kín tiếng về tất cả các chi tiết, có lẽ vì thứ này đã được khai thác trong tự nhiên.


CHET.  Tôi có thể giải quyết vấn đề này trong một từ.

Mut. [Ứng dụng email chỉ có chế độ văn bản lịch sử.]


VỊT.  Vâng, Mút!

Du, thông, mailx, mail…

…mèo lưới, Chester!


CHET.  Bạn đã quên con mèo.


VỊT.  Tôi đang nghĩ đến netcat, nơi bạn thực sự đang nói chuyện tương tác với máy chủ thư ở đầu bên kia.


CHET.  [CƯỜI] Bạn chỉ có thể nhận email khi đang ngồi trên bàn phím.


VỊT.  Nếu bạn vá lỗi, hãy hy vọng rằng nó thực sự xử lý tất cả các vị trí trong Outlook nơi tệp có thể được truy cập và tệp đó tình cờ nằm ​​trên một máy chủ từ xa…

…vì vậy Outlook nói, “Này, tại sao tôi không thử đăng nhập vào máy chủ cho bạn?”

Bây giờ, Chester, khi chúng ta thảo luận vấn đề này trước podcast, bạn đã có một quan sát thú vị rằng bạn rất ngạc nhiên khi lỗi này xuất hiện tràn lan, bởi vì rất nhiều ISP chặn cổng SMB 445, phải không?

Không phải vì lỗi xác thực này, mà vì đó từng là một trong những cách chính mà sâu mạng lây lan…

…và mọi người đã phát ngán với chúng từ 10, 15, 20 năm trước đến nỗi các ISP trên toàn thế giới chỉ nói: “Không. Không thể làm được. Nếu bạn muốn bỏ chặn cổng 445, bạn phải nhảy qua các vòng hoặc trả thêm tiền cho chúng tôi.”

Và hầu hết mọi người không bận tâm.

Vì vậy, bạn có thể được bảo vệ chống lại điều này một cách tình cờ, chứ không phải do thiết kế.

Bạn có đồng ý với điều đó?


CHET.  Vâng, tôi nghĩ rằng nó có khả năng.

Hầu hết các ISP trên thế giới đều chặn nó.

Ý tôi là, bạn có thể tưởng tượng trong Windows XP, nhiều năm trước, có bao nhiêu máy tính truy cập internet, không có mật khẩu, ngồi trực tiếp trên các kết nối Internet của họ với chia sẻ C$ bị lộ.

Chúng tôi thậm chí không nói về khai thác ở đây.

Chúng tôi chỉ nói về những người có ADMI|N$ và C$ tung bay trong gió!


VỊT.  Nếu đó là cách bạn được bảo vệ (nghĩa là nó không hoạt động vì ISP của bạn không cho phép nó hoạt động)…

…đừng lấy đó làm cái cớ để không áp dụng bản vá, phải không?


CHET.  Phải, chắc chắn rồi.

Bạn không muốn những nỗ lực thậm chí xảy ra, chứ đừng nói đến việc chúng thành công.

Hầu hết chúng ta đang đi du lịch xung quanh, phải không?

Tôi sử dụng máy tính xách tay của mình tại quán cà phê; và sau đó tôi sử dụng máy tính xách tay tại nhà hàng; và sau đó tôi sử dụng máy tính xách tay ở sân bay.

Ai biết những gì họ đang chặn?

Tôi không thể dựa vào việc cổng 445 bị chặn…


VỊT.  Chester, tôi nghĩ chúng ta nên dừng lại ở đó, vì tôi quan tâm đến thời gian.

Vì vậy, cảm ơn bạn rất nhiều vì đã bước lên micrô trong thời gian ngắn.

Bạn sẽ trở lại vào tuần tới?

Bạn là, phải không?


CHET.  Tôi chắc chắn có kế hoạch vào tuần tới, trừ khi có những trường hợp không lường trước được.


VỊT.  Tuyệt vời!

Tất cả những gì còn lại là để chúng tôi nói, như chúng tôi thường làm…


CHET.  Cho đến thời gian tiếp theo, giữ an toàn.

[CHẾ ĐỘ ÂM NHẠC]


tại chỗ_img

Tin tức mới nhất

tại chỗ_img