SSH được bật sẵn mặc định trên giao diện âm thanh

 (hhh.hn)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi giải nén tệp firmware, có thể dễ dàng xem cấu trúc bên trong thiết bị, và Rodecaster Duo có SSH mở sẵn theo mặc định
  • Gói cập nhật có dạng gzipped tarball, và trong thiết bị có hai phân vùng để khởi động sang bên còn lại khi một bên bị hỏng, cùng với các shell script dùng cho cập nhật
  • Firmware được nạp vào không có kiểm tra chữ ký, kết nối SSH thực tế được xác nhận qua Ethernet, và thiết bị ở trạng thái chỉ cho phép xác thực pubkey
  • Trên Windows, việc bắt luồng cập nhật USB cho thấy quá trình vào chế độ cập nhật và thực hiện flashing được thực hiện bằng các lệnh ASCII đơn là M và U; sau khi sao chép archive.tar.gz và archive.md5, thiết bị khởi động lại để lên firmware mới
  • Trên macOS, bằng firmware tùy biến có thể bật xác thực SSH bằng mật khẩu và thêm khóa công khai để đăng nhập thực tế; lý do SSH mặc định được bật và kèm theo khóa mặc định cuối cùng vẫn chưa được làm rõ

Cập nhật firmware và việc SSH được bật mặc định

  • Rodecaster Duo cho phép xem khá dễ các tệp được truyền tới thiết bị trong quá trình cập nhật firmware, và SSH được bật ở trạng thái mặc định
    • Trên macOS, bằng cách theo dõi hoạt động đĩa đã tìm ra vị trí lưu firmware, và firmware có dạng gzipped tarball đơn giản
    • Trên thiết bị đã thử cập nhật, chức năng ghi vào đĩa USB bị vô hiệu hóa nên lần cập nhật đó thất bại
  • Bên trong thiết bị có các binary thực thi và shell script dùng cho cập nhật, và trên đĩa có hai phân vùng để nếu một bên bị hỏng thì sẽ khởi động sang bên còn lại
    • Firmware được nạp vào không có kiểm tra chữ ký
    • Kết quả kiểm tra bằng cách cắm cáp Ethernet cho thấy SSH thực sự đang mở, và ở trạng thái chỉ cho phép xác thực pubkey
  • Đã xác nhận có hai khóa SSH được thêm sẵn theo mặc định
    • ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCX/bCFTDgViuPvdFL/VMMVRrw9b5S8HcDQk17qoCEYwmI+IIG8rEAsLiaeCOwyhf9IN+8/LRaN0Z5ZfU3WMbmsKEg8zd1Yvqq74nFbhO47vbtzmCi9S4ucIKkBEVOyvyN5lt9hWf5t5nZSmlfldZK3Pem5y8wHM5A+K/gSnzp4gwQ1QYfFb068uQ+ciIdOhb8SkUs8CwzotglIbp19I6ZmXmsNj/TmpbUf5rMfUAf1gysZ5j1UdRWrvWVh5daqvZRsBBPbXEeJfDU3Nr3HR14XYt9mgexrz/5oyKSj/lQYLmh9cDfsxvkGNIQ8fF9l+n2L1KZM4lLgiGk4KFBjQHaIBZx9OebCiiZCO4NTJUBDk9a+SZpiDiipADV07s7vTInYyFA6GrmKtnq3M6upT4WJBvVuL/BMnK5yY1RZtoqox2/pcCg2rH5S1GIy0v0HFJisl7kWInlaG2mdsaCx19wAjCFe/qT9LyxjQ6+0rArI55/JJFDkNeMjrewRQwNdASjCox8vqXCBfjvsR9qv70/ywcymgsnLAnq2LuYg5FYwMMDYOvVnhACC+BYTdNDTn5oeMIjQCUenY/DPCHpJkf4YOf3YCMUTEU9tExhtwW/X+m21hS3+STLtTfqbUeg9CeuPQZgfl9vc65n3tMxAdlEGEDoTaNMAgr2TzJv92Ka9iQ==
    • ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaNyzPfIcEeQsfzyQs/wyX6mX52kiS+4eNHfCaxFlgj

Luồng cập nhật và firmware tùy biến

  • Trên Windows, bằng Wireshark và USBPcap đã bắt lưu lượng cập nhật để kiểm tra luồng điều khiển mà ứng dụng RODECaster App gửi tới thiết bị
    • Có 'lệnh M' để đưa thiết bị vào chế độ cập nhật và 'lệnh U' để thực thi cập nhật
    • Cả hai lệnh đều là một ký tự ASCII đơn được gửi qua HID report 1
  • Cấu trúc cập nhật thực tế khá đơn giản
    • Sau khi gửi lệnh M, sao chép archive.tar.gz và archive.md5 vào đĩa mới được hiển thị
    • archive.md5 là giá trị md5sum của archive
    • Sau đó unmount đĩa và gửi lệnh U thì quá trình flashing bắt đầu, rồi thiết bị khởi động lại và lên firmware mới
  • Trên macOS, bằng container đã tạo firmware tùy biến để bật xác thực SSH bằng mật khẩu và thêm khóa công khai của mình vào authorized keys
    • Có thể xem ví dụ tối thiểu về các hàm cần cho việc flashing tại đây
    • Sau khi chạy script để flash, có thể kết nối SSH tới thiết bị
  • Thiết bị này cho phép flash firmware rất dễ dàng, nhưng lý do SSH mặc định được bật và có kèm khóa mặc định vẫn chưa được xác định
    • Vấn đề này đã được gửi cho RODE qua ticket nhưng không nhận được phản hồi
    • Sẽ tiếp tục theo dõi xem các bản cập nhật firmware sau này có thay đổi gì hay không

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News
  • Điều luôn khiến tôi bực bội trong các câu chuyện kiểu này là firmware có chữ ký và firmware mở vốn không phải là hai khái niệm đối lập
    Bật xác minh theo mặc định thì cũng ổn, nhưng người đã mua phần cứng phải có thể giành lại quyền kiểm soát của chủ sở hữu bằng cách đăng ký khóa riêng của mình, đổi jumper, hoặc nhấn nút khi khởi động
    Trên thực tế chỉ có một số Chromebook và thiết bị mạng làm được như vậy, nên cứ hễ nói đến bảo mật firmware là lại biến thành cuộc chiến giữa “khóa chặt mọi thứ” và “mở toang hoàn toàn”, còn cấu trúc để chính người dùng đã trả tiền quyết định thì biến mất
    Việc Rode phân phối theo kiểu tarball + hash là rất tốt, và kể cả sau này họ có siết chặt hơn thì tôi vẫn hy vọng đó là cách cho phép tôi nạp thứ mình muốn lên thiết bị tôi đang sở hữu
  • Tôi thực sự thích việc image firmware chỉ đơn giản là tarball + hash
    Giá mà có nhiều thiết bị mở theo kiểu này hơn, và mong là Rode đừng nhìn thấy chuyện này rồi khóa luôn việc nâng cấp firmware
    • Nếu có ai bên Rode đọc được điều này, thì chính những điểm như vậy khiến tôi muốn mua thiết bị của họ
      Mong là đừng thay đổi
    • Vài năm trước tôi phải cập nhật firmware cho một máy in HP, và thật bất ngờ là cách làm cực kỳ đơn giản nên tôi rất thích
      Đó là mẫu máy in khoảng năm 2009, và để nâng RAM lên 256MB thì cần cập nhật firmware; chỉ việc gửi tarball vào máy in qua mạng bằng FTP
      Tôi dùng FileZilla để đẩy lên, nó chạy vài phút là cập nhật xong, và từ đó tôi cứ nghĩ chẳng có lý do gì để cập nhật firmware phải phức tạp hơn thế
      Vì lý do bảo mật thì có thể kiểm tra checksum, nhưng sẽ rất hay nếu chỉ cần tải một blob lên bằng FTP, SCP hay SFTP là xong
    • Dù vậy tôi vẫn nghĩ chỉ nên kích hoạt lệnh cập nhật bằng kiểu đầu vào như nút vật lý
      Phải bắt buộc vào một dạng DFU mode thì mới được, nếu không thì bất cứ thứ gì có quyền truy cập USB cũng có thể đẩy firmware lỗi vào và biến thiết bị thành cục gạch
    • Cá nhân tôi không muốn audio interface của mình chạy SSH, rồi lại có cấu trúc để ai đó có thể thêm tùy ý authorized key vào đó
  • Sẽ thú vị hơn nếu tiêu đề là Audio interface của tôi là một máy tính Linux 64-bit
    Nếu là 10 hay 20 năm trước thì loại chức năng này có lẽ sẽ được triển khai trên một SoC 16-bit hoặc 32-bit nhỏ với RTOS như VxWorks
    Vì có rất nhiều điều khiển vật lý, nên bước tiếp theo trông cũng khá tự nhiên là biến nó thành máy chơi game
    • Audio interface của tôi thực ra cũng là một máy tính Linux, và bên trong thực sự có FPGA được lập trình tại chỗ
      Thậm chí còn có hai cổng 1GbE và mỗi cổng giao tiếp với một phần khác nhau của máy
      Nhưng kiểu cấu hình này không quá lạ trong thế giới audio chuyên nghiệp, nên nếu để trên bàn làm việc ở nhà thì có thể gây ấn tượng, còn trong ngành thì khá bình thường
      Có lẽ sau này khi tôi lấy được root shell hoặc làm nó thành cục gạch thì câu chuyện sẽ còn vui hơn
    • Cả video dongle của bạn cũng có thể là một máy tính Unix: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • Bây giờ vẫn có áp lực về RAM/storage, nhưng giá chip đã quá rẻ
      Xét về chi phí và tính tương thích thì cũng khó mà đánh bại được Linux
  • Khi thiết bị bắt đầu có DSP đúng nghĩa thì cấu trúc kiểu này khá phổ biến
    Bên dưới thường là một Linux tối giản chạy trên ARM SoC, và BSP của nhà cung cấp đôi khi vô tình xuất xưởng với sshd đang bật
    Điều này gần với việc không có ai bên audio thực sự chịu trách nhiệm cho rootfs hơn là ác ý
    Điểm mấu chốt là nó chỉ mở trên mạng phía USB hay còn mở cả trên LAN thực sự
    Trường hợp đầu chỉ là phiền phức, còn trường hợp sau thì đáng lo thật
    • Đáng tiếc là mặc định của Linux không thực sự phù hợp cho việc sản xuất hàng loạt loại thiết bị này
      So với thế thì Android có các loại image mặc định như eng / userdebug / user, nên chỉ cần chọn đúng cấu hình có sẵn là dễ tránh những sai lầm như vậy hơn
    • Cái này thực sự cũng đang lắng nghe trên LAN
      Tôi chưa kiểm tra được là khi dùng một số tính năng nhất định nó có kết nối Wi‑Fi, và interface đó có mở hay không
  • Giờ vẫn thấy ngạc nhiên vì có cảm giác ai cũng mang theo một AI-hacker trong túi
    Chỉ cần ném cho agent là trong vài phút nó sẽ xem xét firmware và đưa ra hướng tiếp cận để chỉnh sửa thiết bị
    Mới năm ngoái thôi, việc này còn là thứ ít nhất phải do một hacker cỡ Hotz làm, hoặc một người cực kỳ kiên trì đào sâu rất lâu mới làm nổi
    • Điều đó hoàn toàn không đúng
      Đúng là LLM đã khiến việc phân tích, debug và tìm cách vượt qua dễ hơn rất nhiều, nhưng thiết bị này được bảo vệ quá sơ sài nên chỉ cần kỹ năng tầm trung, có động lực và bỏ thời gian là đủ làm được
      Không có firmware mã hóa, không có kiểm tra chữ ký, thậm chí còn có cả SSH access tích hợp sẵn
      Trong khi đó hypervisor của PS3 mà George Hotz từng phá thì được thiết kế chắc chắn hơn rất nhiều từ góc nhìn của kẻ tấn công, và exploit thực tế còn cần đến voltage glitching bằng FPGA
      Kiểu tấn công như vậy LLM có thể hỗ trợ, nhưng vì không có vòng phản hồi hoàn chỉnh nên vẫn cần rất nhiều công sức thủ công
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • Đọc bài thì có vẻ Claude Code thực chất chỉ được dùng như Wireshark và Google thay thế để giải thích lưu lượng USB HID và tìm tài liệu giao thức
      Nếu bạn chưa cài Wireshark thì nó có thể giúp tiết kiệm chút thời gian, nhưng cũng có chút rủi ro ảo giác
      Ngoài ra thì chỉ là sửa ~root/.ssh/authorized_keys và /etc/shadow trong tarball firmware bên trong Docker, gửi các thông điệp HID liên quan, rồi dùng một script Python đơn giản để chép tarball đã sửa vào volume mà thiết bị phơi ra như một USB drive
      Vì vậy đây không phải việc cần một hacker điên rồ nào cả; chỉ cần có nền tảng Linux sysadmin cơ bản và có thể ghép một thư viện USB HID với một chương trình nhỏ là đủ
      Tuy nhiên lúc đầu tôi cũng hơi ngạc nhiên vì sao lại cài gói whois trong container Ubuntu, nhưng rồi hiểu ra là trên họ Debian, vì lý do lịch sử mà mkpasswd nằm trong đó
      Ngoài ra, nếu sshd_config của thiết bị vẫn để mặc định thì rất có thể đăng nhập root bằng mật khẩu vốn dĩ đã không hoạt động vì PermitRootLogin
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • Tôi cũng đã dùng AI để bật SSH trên một Phase One digital back mình có, và với một chiếc khác thì reverse engineer firmware để vá cho nó nhận diện thành model khác
      Tôi đã lừa Credo 50 thành IQ250, nhưng bên trong thì về cơ bản là giống nhau
    • Trước đây phải lục tung packet capture và đủ loại dữ liệu trong nhiều giờ, còn giờ không cần tiêu tốn khoảng thời gian đó nữa là điều rất tuyệt
      Đào sâu thì vẫn vui, nhưng càng có tuổi càng khó dành 16 tiếng liền để vật lộn với một firmware blob ngẫu nhiên
    • Trong đa số trường hợp LLM không làm được tới mức đó
      Hơn nữa, xử lý một thiết bị có mở SSH vốn cũng chẳng đòi hỏi kỹ năng gì đặc biệt
  • Tôi cũng gặp cùng vấn đề, nên rất tò mò tác giả đã giải quyết chuyện này thế nào
    Đặc biệt là phần muốn vừa chơi game vừa dùng Discord trong cùng một phòng, trong khi tôi và bạn gái mỗi người cắm mic vào máy riêng của mình mà vẫn dùng được không có echo
    • Rodecaster có thể kết nối với hai máy tính
      Chỉ cần cả hai cùng vào một cuộc gọi Discord, nhưng gộp hai micro lại rồi gửi vào đầu vào của một máy, còn người kia thì tắt tiếng micro và chỉ nhận âm thanh từ client
      Vì việc mixing diễn ra cục bộ nên sẽ không tạo echo
      Đơn giản đến mức tôi gần như muốn bảo cứ email cho tôi nếu cần hỏi thêm
    • Gần đây tôi đã vibe coding sơ một jack mixer bằng Rust, có thể nhận audio qua LAN rồi xuất lại
      Độ trễ khoảng 40ms, còn nếu đi qua Wi‑Fi thì khoảng 50~60ms
      Có thể chạy mixer trên một PC và nhận micro cục bộ làm một kênh đầu vào, còn PC kia thì phát micro của nó để đưa vào kênh 2 của mixer, là cũng giải quyết được tương tự
      Trên PC cục bộ còn có thể phát nhạc, và mixer hoặc broadcaster có thể tạo sink cục bộ
      Cuối cùng trộn tất cả trong mixer, gửi main out sang Discord, còn đường monitor thì phát audio Discord rồi relay ngược sang PC kia để nghe theo thời gian thực
    • Tôi cũng tự hỏi liệu đây có phải vấn đề mà một headset có micro boom định hướng là giải quyết được không
      Tất nhiên có thể là tôi đang hiểu sai tình huống
  • Bài viết hay và domain cũng rất đẹp
    Tôi không rành Zola, nên không biết đây là template phổ biến hay tùy biến, nhưng nhìn rất ổn
  • Có vẻ nhiều vendor xem security gần như đồng nghĩa với chống sao chép
    Nên họ mới ép buộc những thứ như signed image
  • Tôi thắc mắc tại sao mục tiêu lại là disclosure
    Với loại interface này thì tôi lại nghĩ tốt hơn là cứ để nó mở
    • Đó không hẳn là mục tiêu, và tôi cũng hy vọng RODE sẽ tiếp tục để nó mở
  • Mọi người bên Rode ở Úc có vẻ khá dễ trao đổi, nên nếu có gì cần báo thì chắc cứ gọi điện thẳng cũng được
    Ở đó họ gần như nói tiếng Anh luôn, nên chắc vẫn hiểu nhau