Logo Zephyrnet

Trí thông minh dữ liệu tạo

IOT

Tuần này về bảo mật: Forksquatting, RustDesk và M&Ms

Được xuất bản lại bởi Plato
Được xuất bản lại bởi Plato

Ngày:

Lượt xem: 129

Github đang vật lộn để theo kịp một chiến dịch phần mềm độc hại là một bước tiến mới trong việc đánh máy. Cách chơi rất đơn giản: Sao chép các kho lưu trữ phổ biến, thêm phần mềm độc hại và quảng cáo các bản phân nhánh như bản gốc. Một số nhà phát triển nhầm các nhánh này với các dự án thực và vô tình chạy phần mềm độc hại. Lựa chọn đặt tên hiển nhiên là forksquatting, nhưng các nhà nghiên cứu tại apiiro đã chọn cái tên an toàn hơn là “Repo Confusion”.

Chiến dịch này được tự động hóa và GitHub nhận thức được điều đó, phần lớn các kho lưu trữ độc hại này sẽ bị xóa ngay lập tức. Vì lý do nào đó, thuật toán GitHub không nắm bắt được tất cả các kho lưu trữ mới. Chiến dịch hiện tại dường như đã xuất bản hàng triệu bản fork, sử dụng mã từ hơn 100,000 dự án hợp pháp. Có vẻ như nhóm tấn công ngồi xổm đang bắt đầu tồn tại.

Chứng chỉ RustDesk và Odd

Phần mềm truy cập từ xa RustDesk rất thú vị vì nó là nguồn mở, cho phép tự lưu trữ và được viết bằng Rust. Tôi đã khám phá RustDesk như một công việc cần làm trong một thời gian dài, nhưng vừa mới diễn ra một chút kịch tính đáng lo ngại. Một người dùng đã chỉ ra vào tháng 11 rằng chứng chỉ gốc thử nghiệm đã được cài đặt như một phần của quá trình cài đặt RustDesk. Chứng chỉ gốc đó được tự ký bằng SHA1. Cũng có lo ngại rằng các tệp nhị phân RustDesk được ký bằng một chứng chỉ khác.

Đã có những sự kiện mới kể từ đó. Đầu tiên, đã có một chủ đề Tin tức về hacker về vấn đề này vào đầu tháng này. Ngày hôm sau, CVE-2024-25140 đã được đăng ký với NIST, xếp hạng CVE 9.8 CVSS điên rồ. Hãy bỏ qua một số FUD và nói về những gì đang thực sự diễn ra.

Đầu tiên, chứng chỉ gốc phải được ký bằng hàm băm an toàn hơn SHA1. Nhưng không phải vì lý do bạn nghĩ, và trong trường hợp này nó không thành vấn đề. Chứng chỉ gốc được tự ký theo định nghĩa và lý do duy nhất chúng được ký là vì các chứng chỉ này phải được ký để hợp lệ. Chứng chỉ con không được bảo vệ bằng chữ ký gốc. Chức năng quan trọng phụ thuộc vào chữ ký gốc đó là khả năng đưa ra yêu cầu thu hồi. Điều đó sẽ thực sự tồi tệ đối với một trong những chứng chỉ gốc được tin cậy rộng rãi và hoàn toàn không phải là vấn đề đối với chứng chỉ không đáng tin cậy như chứng chỉ này.

Tiếp theo, RustDesk có chứng chỉ hợp lệ, được ký cho các tệp thực thi. Chứng chỉ gốc tự ký hoàn toàn dành cho việc ký trình điều khiển hạt nhân, yêu cầu chứng chỉ Xác thực mở rộng (EV). Có một chút lo lắng là yêu cầu này có thể dễ dàng bị bỏ qua bằng cách cài đặt chứng chỉ gốc trong quá trình cài đặt ứng dụng, nhưng đó là trên Microsoft chứ không phải RustDesk.

Mối quan tâm cuối cùng ở đây là chứng chỉ này đang được cài đặt dưới dạng Cơ quan cấp chứng chỉ (CA) trên toàn hệ thống. Đó là yếu tố đáng lo ngại nhất của câu chuyện này, nhưng các chứng chỉ có một trường chỉ định Cách sử dụng khóa (KU) và Cách sử dụng khóa mở rộng (EKU). RustDesk CA hoàn toàn dành cho việc ký mã. Điều này không cho phép RustDesk hoặc bất kỳ ai sở hữu khóa này phá vỡ TLS hoặc các trang web giả mạo. Nó cho phép ký mã, đây có thể là một mối lo ngại chính đáng, nhưng không phải là tình huống cháy nổ đầu tiên mà nó xuất hiện.

RustDesk đã lấy khóa này khỏi bản cài đặt của họ, điều này vô tình làm vô hiệu hóa trình điều khiển hiển thị ảo. Đó là chức năng yêu cầu trình điều khiển hạt nhân đã được ký. Tin tức mới nhất là các nhà phát triển RustDesk đang nhận được một số hỗ trợ và đang theo đuổi chứng chỉ ký mã EV và dự kiến ​​​​quá trình đó sẽ hoàn tất sau khoảng một tháng. Và CVE đó, đạt mức độ nghiêm trọng 9.8? Có vẻ như hoàn toàn không có thật.

Thành viên cuối cùng SQL SQL

Plugin WordPress Thành viên cuối cùng đã được cập nhật để phát hành 2.8.3, sửa lỗi tiêm SQL có thể truy cập được với tư cách là người dùng chưa được xác thực. Dựa trên sự khác biệt cập nhật, vấn đề chính có lẽ đã bị bỏ lỡ prepare() trên dòng 704. Ồ, và rõ ràng là nó đang được thăm dò và có khả năng bị khai thác ngoài tự nhiên, vì vậy hãy vá lỗi.

Đây có lẽ là thời điểm tốt để trò chuyện về lý do tại sao có quá nhiều cuộc tấn công SQL SQL trong WordPress. Đầu tiên, việc chèn SQL là khi dữ liệu do người dùng cung cấp được hiểu là một phần của lệnh SQL để thực thi. Điều đó được thực hiện bằng cách bao gồm một nhân vật bất ngờ. Ví dụ: dấu chấm phẩy cho biết sự kết thúc của câu lệnh và có thể được sử dụng để bắt đầu câu lệnh tiếp theo. Vì vậy, khi một chương trình đơn giản mong đợi một con số, đầu vào của 15; DROP TABLE Students sẽ đáp ứng một câu lệnh SQL và đưa vào câu lệnh thứ hai để thực thi trên cơ sở dữ liệu.

Nói rộng ra, có hai cách tiếp cận để ngăn chặn việc tiêm SQL: làm sạch đầu vào và các câu lệnh được chuẩn bị sẵn. Và cả hai đều tốt! Đầu tiên, vệ sinh đầu vào của người dùng. Đảm bảo số nguyên đó thực sự là số nguyên và chỉ là số nguyên. Loại bỏ dấu ngoặc kép, dấu chấm phẩy và các ký tự có khả năng gây nguy hiểm khác.

Cách tiếp cận thứ hai là sử dụng các câu lệnh đã chuẩn bị sẵn. Điều này tách lệnh SQL khỏi dữ liệu theo cách cơ bản. Nó giống như $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); để gửi các lệnh SQL. Sau đó nó được theo sau bởi $database->bind_param("si", $name, $age); để thiết lập các giá trị sẽ được sử dụng. Và cuối cùng là một $database->execute(); thực sự chạy truy vấn. Không thể tiêm vì có sự phân tách chặt chẽ giữa mã và giá trị.

Bây giờ chúng ta đến với WordPress, nơi có riêng wpdb lớp cho các cuộc gọi cơ sở dữ liệu. Điều đó bao gồm một chức năng hữu ích, wpdb::prepare() trông gần giống như một tuyên bố được chuẩn bị sẵn như được hiển thị ở trên.

$wpdb->prepare( "u.user_registered BETWEEN %s AND %s", $from_date, $to_date );

Ngoại trừ việc nó không hề như vậy. Các prepare() chức năng thực hiện nghiêm ngặt việc vượt qua quá trình vệ sinh và sprintf() sự thay thế giá trị. Các prepare() hàm không thực sự tạo ra một câu lệnh cơ sở dữ liệu đã chuẩn bị sẵn. WordPress không cung cấp cách thực sự sử dụng các câu lệnh đã chuẩn bị sẵn. Thiếu một trong những mô hình cơ bản giúp các nhà phát triển không gặp rắc rối với việc chèn SQL.

M&M đang theo dõi

Tôi có một sở thích nào đó. Tôi thấy thú vị khi phát hiện ra các máy hoạt động sai và cố gắng tìm hiểu hệ điều hành nào đang chạy bên dưới GUI sáng bóng. Thiết bị nhúng kỳ lạ nhất mà tôi tìm thấy là một máy quét trang chạy bản sao Windows đầy đủ. Máy quét giá trong cửa hàng lớn ở địa phương của bạn có thể chỉ chạy Windows CE. Các trung tâm thông tin giải trí ở ghế sau máy bay chạy một hệ điều hành Linux thực sự cũ kỹ. Và có vẻ như các máy bán hàng tự động M&M ở Đại học Waterloo đang chạy Windows với ứng dụng Invenda.Vending.FacialRecognition.App.exe.

Chúng tôi biết điều đó vì [SquidKid47] đã phát hiện một ngoại lệ phần mềm không xác định trên màn hình hiển thị của máy bán hàng tự động và chia sẻ nó trên reddit. MỘT báo trường đã đăng lại câu chuyện (pdf) và xác định rằng máy bán hàng tự động sử dụng camera và tính năng nhận diện khuôn mặt là sự kết hợp giữa cảm biến chuyển động thông minh và trình phát hiện nhân khẩu học cho quảng cáo được nhắm mục tiêu. Có, những máy bán hàng tự động này phục vụ các quảng cáo được nhắm mục tiêu. Ít nhất họ đã làm. Những máy bán hàng tự động này có đã gặp Waterloo của họ tại Đại học Waterloo, và trường hiện đã chính thức yêu cầu loại bỏ họ.

Bit và byte

Rung chuông cửa cho Pwn: Thì ra là thế một số chuông cửa thông minh không thông minh đến thế. Không có gì đáng ngạc nhiên khi có một quy trình để đặt lại chuông cửa thông minh, liên kết nó với một tài khoản khác. Điều khá ngạc nhiên là quá trình này dễ dàng như việc giữ nút chuông cửa lớn trong 8 giây. Ít nhất, chủ sở hữu hợp pháp sẽ nhận được email về sự thay đổi.

Tính không an toàn của máy in không có gì mới, nhưng tính bảo mật của máy in 3D vẫn còn là một ý tưởng nhỏ. Điều đó có thể đang thay đổi, bây giờ tệp tương đương với tệp “greetings.txt” đã bị loại bỏ trên một loạt máy in Anycubic. Rõ ràng Anycubic sử dụng máy chủ MQTT thực sự không có đủ quyền kiểm soát truy cập.

Lại là lúc đó, khi bản sửa lỗi lỗ hổng đã được phát hành cho GitLab, và đã đến lúc cập nhật. Nổi bật lần này là lỗ hổng Cross Site Scripting (XSS) khi truy cập trang hồ sơ của người dùng. Tôi để nó như một bài tập cho người đọc, tạo mã mẫu sao chép “samy là anh hùng của tôi” vào trang hồ sơ của mỗi khách truy cập.

Và cuối cùng, trong phần trớ trêu, Avast bị phạt vì đã sử dụng plugin bảo mật của trình duyệt làm nền tảng để thu thập và bán dữ liệu người dùng. Điều này xảy ra từ năm 2014 đến năm 2020, sử dụng nền tảng Jumpshot để bán dữ liệu thực tế. Dữ liệu được ẩn danh trên danh nghĩa, nhưng số lượng và chi tiết thông tin có sẵn hơi đáng kinh ngạc. Điều đáng nói là Jumpshot không còn nữa và Avast hiện thuộc sở hữu của một công ty khác. Hy vọng không thu thập thông tin người dùng.

tại chỗ_img

Tin tức mới nhất

tại chỗ_img

Bản quyền @ 2024 Plato Technologies Inc.