- เมื่อแตกไฟล์เฟิร์มแวร์ออกมา ก็สามารถตรวจสอบโครงสร้างภายในอุปกรณ์ได้อย่างง่ายดาย และ Rodecaster Duo มี SSH เปิดอยู่โดยค่าเริ่มต้น
- แพ็กเกจอัปเดตอยู่ในรูปแบบ gzipped tarball และในอุปกรณ์มี พาร์ทิชันสองชุด ที่ใช้บูตไปอีกฝั่งเมื่อเกิดความเสียหาย รวมถึงมีเชลล์สคริปต์สำหรับอัปเดตอยู่ด้วย
- เฟิร์มแวร์ที่รับเข้ามา ไม่มีการตรวจสอบลายเซ็น และยืนยันได้ว่ามีการเปิด SSH จริงผ่านการเชื่อมต่อ Ethernet โดยตั้งค่าให้ อนุญาตเฉพาะการยืนยันตัวตนด้วย pubkey
- บน Windows มีการจับขั้นตอนอัปเดตผ่าน USB และพบว่าการเข้าสู่โหมดอัปเดตและการแฟลชทำผ่าน คำสั่ง ASCII ตัวเดียว คือ
MและUจากนั้นคัดลอกarchive.tar.gzและarchive.md5แล้วรีบูตเพื่อขึ้นเฟิร์มแวร์ใหม่ - บน macOS สามารถสร้าง เฟิร์มแวร์แบบกำหนดเอง เพื่อเปิดการยืนยันตัวตนด้วยรหัสผ่านของ SSH และเพิ่มกุญแจสาธารณะ ทำให้เชื่อมต่อได้จริง แต่สุดท้ายก็ยังไม่ทราบเหตุผลที่เปิด SSH และใส่คีย์มาให้โดยค่าเริ่มต้น
การอัปเดตเฟิร์มแวร์และการเปิดใช้ SSH โดยค่าเริ่มต้น
- Rodecaster Duo ทำให้ตรวจสอบไฟล์ที่ส่งเข้าอุปกรณ์ระหว่างกระบวนการอัปเดตเฟิร์มแวร์ได้ง่าย และพบว่ามี SSH เปิดใช้งานอยู่ ตั้งแต่ค่าเริ่มต้น
- บน macOS มีการติดตามกิจกรรมของดิสก์เพื่อค้นหาตำแหน่งจัดเก็บเฟิร์มแวร์ และพบว่าเฟิร์มแวร์อยู่ในรูปแบบ gzipped tarball ธรรมดา
- บนอุปกรณ์ที่ลองอัปเดต ฟังก์ชันเขียน USB disk ถูกปิดใช้งานอยู่ ทำให้การอัปเดตครั้งนั้นล้มเหลว
- ภายในอุปกรณ์มีไบนารีที่ใช้รันงานและเชลล์สคริปต์สำหรับอัปเดต และบนดิสก์มี พาร์ทิชันสองชุด เพื่อให้บูตไปอีกฝั่งได้หากฝั่งหนึ่งเสียหาย
- เฟิร์มแวร์ที่รับเข้ามา ไม่มีการตรวจสอบลายเซ็น
- เมื่อลองต่อสาย Ethernet เพื่อตรวจสอบ ก็พบว่า SSH เปิดอยู่จริง และตั้งค่าให้ อนุญาตเฉพาะการยืนยันตัวตนด้วย pubkey
- พบ SSH key ที่ถูกเพิ่มมาโดยค่าเริ่มต้น 2 ชุด
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
ขั้นตอนการอัปเดตและเฟิร์มแวร์แบบกำหนดเอง
- บน Windows มีการใช้ Wireshark และ USBPcap จับทราฟฟิกการอัปเดต เพื่อดูขั้นตอนควบคุมที่แอป RODECaster ส่งไปยังอุปกรณ์
- มีทั้ง'คำสั่ง M' สำหรับให้อุปกรณ์เข้าสู่โหมดอัปเดต และ 'คำสั่ง U' สำหรับเริ่มอัปเดต
- ทั้งสองคำสั่งถูกส่งเป็น อักขระ ASCII ตัวเดียว ผ่าน HID report 1
- โครงสร้างการอัปเดตจริงนั้นเรียบง่าย
- หลังส่งคำสั่ง
Mก็จะคัดลอกarchive.tar.gzและarchive.md5ไปยังดิสก์ที่แสดงขึ้นมาใหม่ archive.md5คือค่า md5sum ของอาร์ไคฟ์- จากนั้น unmount ดิสก์แล้วส่งคำสั่ง
Uเพื่อเริ่มแฟลช หลังจากนั้นอุปกรณ์จะรีบูตและขึ้นเฟิร์มแวร์ใหม่
- หลังส่งคำสั่ง
- บน macOS มีการใช้คอนเทนเนอร์ เพื่อสร้าง เฟิร์มแวร์แบบกำหนดเอง ที่เปิด การยืนยันตัวตนด้วยรหัสผ่านของ SSH และเพิ่มกุญแจสาธารณะของตนเองลงใน authorized keys
- ตัวอย่างฟังก์ชันขั้นต่ำที่จำเป็นสำหรับการแฟลชดูได้ที่นี่
- หลังรันสคริปต์เพื่อแฟลชแล้ว ก็สามารถเชื่อมต่ออุปกรณ์ผ่าน SSH ได้
- อุปกรณ์นี้สามารถแฟลชเฟิร์มแวร์ได้ง่ายมาก และยังคงไม่ทราบเหตุผลว่าทำไมจึงเปิด SSH และใส่คีย์มาให้โดยค่าเริ่มต้น
- ประเด็นนี้ถูกส่งเป็นทิกเก็ตไปยัง RODE แต่ไม่ได้รับคำตอบ
- หลังจากนี้จะคอยติดตามต่อไปว่ามีการเปลี่ยนแปลงในอัปเดตเฟิร์มแวร์ครั้งถัดไปหรือไม่
1 ความคิดเห็น
ความเห็นจาก Hacker News
การเปิดการตรวจสอบไว้เป็นค่าเริ่มต้นนั้นไม่เป็นไร แต่คนที่ซื้อฮาร์ดแวร์ไปควรมีสิทธิ์เอา อำนาจควบคุมของเจ้าของ กลับมาได้ ไม่ว่าจะด้วยการลงทะเบียนคีย์ของตัวเอง เปลี่ยนจัมเปอร์ หรือกดปุ่มตอนบูต
ในความเป็นจริงมีแค่บางรุ่นของ Chromebook กับอุปกรณ์เครือข่ายไม่กี่ตัวที่ทำแบบนี้ พอพูดถึงความปลอดภัยของเฟิร์มแวร์ทีไรก็เลยกลายเป็นการเถียงกันระหว่าง "ล็อกให้แน่น" กับ "เปิดให้หมด" แล้วโครงสร้างที่ให้ผู้ใช้ซึ่งเป็นคนจ่ายเงินตัดสินใจเองกลับหายไป
การที่ Rode แจกจ่ายแบบ tarball + hash ถือว่าดีมาก และต่อให้ภายหน้าจะทำให้เข้มงวดขึ้น ก็หวังว่าจะยังเป็นแบบที่ฉันสามารถลงสิ่งที่ต้องการบนอุปกรณ์ที่ฉันเป็นเจ้าของได้
อยากให้อุปกรณ์ที่เปิดแบบนี้มีมากขึ้น และหวังว่า Rode จะไม่เห็นเรื่องนี้แล้วไปล็อกการอัปเกรดเฟิร์มแวร์เสียก่อน
ได้โปรดอย่าเปลี่ยนมัน
เป็นเครื่องพิมพ์ราวปี 2009 และการจะอัปเกรด RAM เป็น 256MB จำเป็นต้องอัปเดตเฟิร์มแวร์ โดยแค่ส่ง tarball ไปที่เครื่องพิมพ์ผ่าน FTP ทางเครือข่ายก็พอ
ฉันใช้ FileZilla ส่งเข้าไป มันทำงานอยู่สองสามนาทีแล้วอัปเดตเสร็จทันที หลังจากนั้นก็รู้สึกว่าไม่มีเหตุผลเลยที่การอัปเดตเฟิร์มแวร์ต้องซับซ้อนกว่านี้
ต่อให้มี checksum เพื่อความปลอดภัยก็ตาม ก็น่าจะให้แค่อัปโหลด blob ผ่าน FTP, SCP หรือ SFTP แล้วจบได้
ควรต้องเข้าอะไรทำนอง DFU mode ก่อน ไม่อย่างนั้นอะไรก็ตามที่เข้าถึง USB ได้อาจยัดเฟิร์มแวร์ผิด ๆ เข้าไปจนทำให้อุปกรณ์กลายเป็นที่ทับกระดาษได้
ถ้าย้อนกลับไปเมื่อ 10 หรือ 20 ปีก่อน ฟังก์ชันแบบนี้น่าจะถูกทำบน SoC ขนาดเล็กแบบ 16 บิตหรือ 32 บิต พร้อม RTOS อย่าง VxWorks มากกว่า
และเพราะมันมีตัวควบคุมทางกายภาพเยอะพอสมควร ขั้นต่อไปจะเอาไปทำเป็นเครื่องเกมก็ดูเป็นธรรมชาติอยู่เหมือนกัน
แถมยังมีพอร์ต 1GbE สองพอร์ตที่แต่ละพอร์ตคุยกับคนละส่วนของเครื่อง
แต่ในโลกโปรออดิโอ การจัดวางแบบนี้ไม่ได้แปลกมากนัก ถึงจะดูน่าทึ่งเมื่อวางอยู่บนโต๊ะที่บ้าน แต่ในวงการถือว่าค่อนข้างธรรมดา
ถ้าวันหนึ่งได้ root shell หรือทำมันพังจนบูตไม่ขึ้น เรื่องนั้นอาจจะสนุกกว่าอีก
ในแง่ต้นทุนและความเข้ากันได้ก็ยากที่จะชนะ Linux
ปกติข้างล่างจะเป็น Linux ขนาดเล็กที่รันบน ARM SoC และบางครั้ง vendor BSP ก็หลุดออกมาพร้อมกับ sshd ที่เปิดทิ้งไว้
มันดูจะไม่ใช่ความจงใจร้าย ๆ เท่าไร แต่คล้ายกับว่าในฝั่งออดิโอไม่มีใครรับผิดชอบ rootfs อย่างจริงจังมากกว่า
ประเด็นสำคัญคือมันเปิดรับอยู่แค่บนเครือข่ายฝั่ง USB หรือเปิดบน LAN จริงด้วย
แบบแรกแค่น่ารำคาญ แต่แบบหลังน่ากังวลจริง ๆ
ตรงข้ามกับ Android ที่มีการแยกประเภทอิมเมจเริ่มต้นอย่าง eng / userdebug / user ทำให้เพียงเลือกค่าเริ่มต้นที่เตรียมไว้ให้เหมาะ ก็เลี่ยงความพลาดแบบนี้ได้ง่ายกว่า
ตอนใช้บางฟีเจอร์มันจะเชื่อมต่อ Wi‑Fi ด้วย แต่ฉันยังไม่ได้ตรวจว่าฝั่งอินเทอร์เฟซนั้นเปิดไว้ด้วยหรือเปล่า
แค่โยนให้เอเจนต์ ไม่กี่นาทีก็ได้แนวทางในการส่องเฟิร์มแวร์และแก้ไขอุปกรณ์แล้ว
ถ้าเป็นปีก่อน เรื่องแบบนี้อย่างน้อยก็คงต้องเป็นแฮ็กเกอร์ระดับ Hotz หรือไม่ก็คนที่พร้อมนั่งขุดอยู่นานมาก
เป็นความจริงที่ LLM ทำให้การวิเคราะห์ การดีบัก และการหาทางอ้อมง่ายขึ้นมาก แต่ระดับการป้องกันของอุปกรณ์นี้ต่ำมากจนแค่คนที่มีทักษะระดับกลาง มีแรงจูงใจ และมีเวลา ก็ทำได้อยู่แล้ว
ไม่มีทั้งเฟิร์มแวร์เข้ารหัส ไม่มีการตรวจลายเซ็น แถมยังมี SSH access ในตัว
ในทางกลับกัน PS3 hypervisor ที่ George Hotz เจาะนั้นถูกออกแบบมาแข็งแกร่งกว่ามากในมุมของผู้โจมตี และ exploit จริงยังต้องใช้ FPGA เพื่อทำ voltage glitching ด้วย
การโจมตีแบบนั้น LLM อาจช่วยได้บ้าง แต่เพราะไม่มี feedback loop แบบสมบูรณ์ จึงยังต้องพึ่งแรงงานคนอย่างมาก
https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
ถ้าไม่ได้ติดตั้ง Wireshark ไว้ มันก็อาจช่วยประหยัดเวลาได้บ้าง แต่ก็มีความเสี่ยงเรื่องหลอนข้อมูลอยู่เล็กน้อย
นอกนั้นก็แค่แก้
~root/.ssh/authorized_keysกับ/etc/shadowใน tarball เฟิร์มแวร์ภายใน Docker แล้วใช้สคริปต์ Python ง่าย ๆ ส่งข้อความ HID ที่เกี่ยวข้องและคัดลอก tarball ที่แก้แล้วไปยังโวลุมที่อุปกรณ์เปิดให้เห็นเหมือนไดรฟ์ USBดังนั้นนี่ไม่ใช่งานที่ต้องใช้แฮ็กเกอร์บ้าพลังอะไร แค่มีพื้นฐาน Linux sysadmin และเขียนโปรแกรมเล็ก ๆ ที่ใช้ไลบรารี USB HID ได้ก็พอ
เพียงแต่ตอนแรกฉันก็สงสัยอยู่ว่าทำไมถึงติดตั้งแพ็กเกจ
whoisในคอนเทนเนอร์ Ubuntu ก่อนจะนึกได้ว่าในสาย Debian นั้น mkpasswd ถูกใส่มาในนั้นด้วยเหตุผลทางประวัติศาสตร์อีกอย่าง ถ้า
sshd_configของอุปกรณ์ยังเป็นค่าเริ่มต้นเดิมPermitRootLoginก็น่าจะทำให้การล็อกอิน root ด้วยรหัสผ่านใช้ไม่ได้ตั้งแต่แรกแล้วhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
หลอก Credo 50 ให้เป็น IQ250 ได้ เพราะข้างในแทบจะเหมือนกัน
การขุดคุ้ยมันก็สนุกอยู่หรอก แต่พออายุมากขึ้นก็เริ่มยากที่จะจับเฟิร์มแวร์ blob สุ่ม ๆ มานั่งอยู่กับมัน 16 ชั่วโมง
และการจัดการอุปกรณ์ที่เปิด SSH ไว้ก็ไม่ได้ต้องใช้ทักษะพิเศษอะไรด้วย
โดยเฉพาะช่วงที่พูดถึงว่าอยากเล่นเกมและใช้ Discord อยู่ในห้องเดียวกับแฟน โดยให้ต่างคนต่างต่อไมค์เข้าคอมของตัวเองแต่ใช้งานแบบ ไม่มี echo
ให้ทั้งคู่เข้าคอล Discord เดียวกัน แต่รวมไมค์ทั้งสองเข้าที่อินพุตของคอมเครื่องหนึ่ง แล้วอีกคนปิดไมค์ไว้ในไคลเอนต์และรับแค่ออดิโออย่างเดียวก็พอ
เพราะการมิกซ์เกิดขึ้นในเครื่องท้องถิ่น จึงไม่เกิดเอคโค่
มันง่ายมากจนแทบอยากบอกให้ส่งอีเมลมาถามเพิ่มได้เลย
ค่าหน่วงอยู่ราว 40ms และถ้าผ่าน Wi‑Fi ก็ประมาณ 50~60ms
ให้รันมิกเซอร์บนพีซีเครื่องหนึ่ง รับไมค์ในเครื่องเป็นช่องอินพุตหนึ่ง ส่วนอีกพีซีก็กระจายไมค์ของตัวเองเข้ามาเป็นช่อง 2 ของมิกเซอร์ ก็แก้ได้คล้าย ๆ กัน
จะเปิดเพลงบนพีซีเครื่องหลักก็ได้ และตัวมิกเซอร์หรือ broadcaster ก็สร้าง local sink ได้
สุดท้ายก็มิกซ์ทุกอย่างในมิกเซอร์แล้วส่ง main out ไปที่ Discord ส่วนมอนิเตอร์ไลน์ก็ปล่อยออดิโอจาก Discord แล้วรีเลย์กลับไปยังอีกพีซีเพื่อใช้ฟังแบบเรียลไทม์
แน่นอนว่าฉันอาจเข้าใจสถานการณ์ผิดก็ได้
ฉันไม่ค่อยรู้จัก Zola เลยไม่แน่ใจว่านี่เป็นเทมเพลตที่ใช้กันทั่วไปหรือทำเอง แต่หน้าตาดูดีมาก
ก็เลยชอบบังคับใช้สิ่งอย่าง signed image
สำหรับอินเทอร์เฟซแบบนี้กลับรู้สึกว่าอยากให้มันเปิดไว้มากกว่าไม่ใช่หรือ
แถวนี้เราก็พูดอะไรที่เกือบจะเป็นภาษาอังกฤษกันอยู่แล้ว น่าจะสื่อสารกันได้