Chỉ cần trích xuất chứng chỉ (certificate) từ bộ nhớ flash của robot hút bụi Shark RV2320EDUS, bạn có thể thực thi các lệnh root trên máy hút bụi Shark của người khác trong cùng khu vực AWS: xem camera, điều khiển robot, đọc bản đồ ngôi nhà và lấy mật khẩu Wi-Fi dưới dạng văn bản thuần túy (plaintext).
Một nhà nghiên cứu với biệt danh tokay0 đã công bố phương pháp này trực tuyến vào thứ Hai, sau khi thử nghiệm trên chính những chiếc máy hút bụi mà anh tự mua. Vào thời điểm đó, lỗ hổng này vẫn chưa được vá.
Anh cho biết SharkNinja, công ty đứng sau các thương hiệu gia dụng Shark và Ninja, đã nhận được báo cáo của anh từ tháng 3.
Chính sách (policy) đi kèm với chứng chỉ đó chưa bao giờ được giới hạn phạm vi cho thiết bị sở hữu nó. Khi trình chứng chỉ này cho cloud broker của Shark, broker sẽ chấp nhận bất kỳ dữ liệu nào bạn gửi (publish) tới bất kỳ thiết bị nào mà nó quản lý.
Không cần lỗi memory corruption, không cần leo thang đặc quyền (privilege escalation), cũng không có mật khẩu nào để đoán. Lệnh được thực thi nằm trong một trường thông thường của device shadow — một tài liệu trạng thái cho từng thiết bị mà AWS lưu trữ trên đám mây.
Sử dụng chứng chỉ từ một chiếc RV2320EDUS, nhà nghiên cứu đã đăng ký (subscribe) vào $aws/things/# và theo dõi lưu lượng truy cập qua broker, từ đó thu thập các số sê-ri thiết bị. Việc gửi lệnh (publishing) cũng hoạt động tương tự. Device shadow chứa một trường Exec_Command mà tiến trình quản lý appd sẽ đọc và chuyển cho một hàm có tên execute_command, hàm này sẽ thực thi bất kỳ thứ gì dưới 1.000 byte thông qua popen.
Chỉ cần gửi một bản cập nhật shadow chứa trường đó tới topic của một thiết bị. Nếu thiết bị đó triển khai trình xử lý lệnh, nó sẽ thực thi lệnh ngay lập tức.
Anh đã chứng minh khả năng tấn công chéo giữa các model bằng cách thiết lập một reverse shell trên chiếc AV1102ARUS (được mua riêng để làm mục tiêu), sau đó sử dụng shell đó để lấy nguồn cấp dữ liệu trực tiếp từ camera của robot khi nó đang di chuyển.
Việc lấy chứng chỉ chỉ cần một chiếc tua vít. Bo mạch chính để lộ các chân UART, bảng điều khiển U-Boot không yêu cầu mật khẩu, và tham số init=/bin/sh trong các đối số khởi động sẽ đưa bạn vào một root shell. Tại đây, key và certificate của từng thiết bị được lưu trữ trong thư mục /mnt/res/vapp/certs/ dưới dạng các tệp thông thường.
Các chứng chỉ được ghim vào khu vực AWS của chúng. Một khóa lấy được ở một khu vực chỉ có thể tiếp cận các thiết bị trong khu vực đó. Để tiếp cận khu vực khác, cần có một chứng chỉ khác được cấp tại đó với cùng một chính sách bị lỗi tương tự.
Amazon có tính năng kiểm tra kiểm toán cho cấu trúc chính sách chính xác này. Device Defender, dịch vụ kiểm tra IoT fleet của AWS, sẽ gắn cờ các chính sách thiết bị cấp quyền publish hoặc subscribe trên $aws/things/* thay vì giới hạn topic cho thiết bị đang kết nối bằng ${iot:Connection.Thing.ThingName}.
Lỗi này xuất hiện dưới mã IOT_POLICY_OVERLY_PERMISSIVE_CHECK và AWS xếp hạng nó ở mức critical (nghiêm trọng). Trong tài liệu của mình, AWS cảnh báo rằng một chứng chỉ bị xâm nhập mang chính sách như vậy cho phép kẻ tấn công "đọc hoặc sửa đổi shadows, jobs, hoặc job executions cho tất cả các thiết bị của bạn."
Không phải mọi chứng chỉ đều là chìa khóa vạn năng. Một chiếc máy hút bụi có chứng chỉ mang chính sách bị lỗi sẽ trở thành "chìa khóa" của kẻ tấn công. Tuy nhiên, bất kỳ máy hút bụi nào chạy Exec_Command đều là "mục tiêu", bất kể chứng chỉ của chính nó có được giới hạn đúng cách hay không. Model AV1102ARUS là một mục tiêu chứ không phải chìa khóa: chứng chỉ của nó đã được giới hạn đúng cách và không thể wildcard-subscribe. Firmware của nó mới hơn vài năm.
Nhà nghiên cứu cho rằng đây là một bản sửa lỗi về việc cấp quyền (provisioning fix) nhưng chưa bao giờ tiếp cận được các chứng chỉ của đội ngũ thiết bị cũ. Đó là lý do tại sao shell chéo model hoạt động thành công.
Tiêu đề bài đăng của anh đề cập đến con số hàng triệu. Con số anh đã xác minh thực tế thì hẹp hơn. Theo dõi một khu vực AWS trong 24 giờ, tokay0 đã đếm được 1.517.605 số sê-ri Shark duy nhất, trong đó 673.816 (khoảng 44%) đã phát ra Exec_Response, điều mà anh coi là xác nhận rằng thiết bị có chạy trình xử lý lệnh. Đây là những thiết bị được quan sát thấy có phản hồi, không phải thiết bị đã bị kiểm tra hay xâm nhập, và anh cho biết con số thực tế có thể cao hơn.
Bốn tháng và vẫn đang tiếp tục
Theo lời kể của tokay0, anh đã liên hệ với SharkNinja vào ngày 1 tháng 3 và gửi chi tiết vào ngày 11 tháng 3. Công ty xác nhận đã nhận vào ngày hôm sau, thông báo vào ngày 27 tháng 4 rằng báo cáo đang được xem xét, và vào ngày 3 tháng 7 nói rằng sẽ gửi ngày hoàn tất xác nhận trước thứ Sáu, ngày 10 tháng 7. Tuy nhiên, không có email nào được gửi đến.
Anh đã công bố lỗ hổng vào ngày 13 tháng 7. Anh cho biết nhà cung cấp đã hạ thấp mức độ nghiêm trọng và đặt câu hỏi liệu "một mã CVE có phù hợp hay không."
Về các báo cáo IoT, chính sách tiết lộ lỗ hổng của SharkNinja cam kết công ty sẽ "cung cấp các bản cập nhật thường xuyên cho đến khi lỗ hổng được khắc phục." Chính sách tương tự cũng yêu cầu các nhà nghiên cứu giữ im lặng cho đến khi công ty xác nhận đã vá lỗi hoặc cho phép tiết lộ bằng văn bản.
Tính đến thứ Năm, SharkNinja vẫn chưa công bố bất kỳ thông tin nào về lỗi này. Hiện tại cũng chưa có mã CVE nào được chỉ định.
Giải pháp nằm ở phía máy chủ
Bản sửa lỗi này không phải do người dùng cài đặt. Nó nằm trong tài khoản AWS của SharkNinja, không phải trong firmware của robot. Theo hướng dẫn của AWS, một chính sách không tuân thủ sẽ được thay thế bằng cách đẩy một phiên bản có phạm vi giới hạn thông qua CreatePolicyVersion với cờ setAsDefault, giúp phiên bản đó có hiệu lực cho mọi chứng chỉ đang sử dụng chính sách đó.
Quá trình này không yêu cầu triển khai firmware mới. Việc cấp lại các chứng chỉ đúng cách, như tokay0 đã đề xuất vào tháng 3, là công việc dài hơi hơn sau đó.
Cho đến khi SharkNinja thực hiện một trong hai biện pháp trên, cách giảm thiểu rủi ro duy nhất cho chủ sở hữu là ngắt kết nối máy hút bụi khỏi Wi-Fi. Điều này sẽ chấm dứt khả năng điều khiển qua ứng dụng, lập lịch và xem bản đồ, biến sản phẩm trở lại thành một chiếc máy hút bụi thông thường.
tokay0 đã giữ lại các tập lệnh (script) của mình trong khi lỗ hổng vẫn còn tồn tại. Anh cũng chưa kiểm tra các dòng sản phẩm kết nối khác của SharkNinja như vỉ nướng thông minh hay thiết bị đo nhiệt độ thịt không dây, những thứ mà anh cho rằng có khả năng cũng đang gặp lỗ hổng tương tự.
