- IKKO Activebuds ทำงานบนพื้นฐานของ Android และฝัง ChatGPT API มาในตัว
- อุปกรณ์มีการ เปิดใช้งาน ADB ทำให้เข้าถึงและนำไปประยุกต์ใช้จากภายนอกได้อย่างง่ายดาย
- จากการวิเคราะห์ภายในพบว่า OpenAI API key เป็นต้น ถูกเปิดเผยโดยไม่มีการเข้ารหัส จึงมีความเสี่ยงต่อการรั่วไหลของข้อมูล
- พบความเป็นไปได้ในการเข้าถึงและเปิดเผยข้อมูลอ่อนไหว เช่น ประวัติการสนทนาของผู้ใช้ ข้อมูลอุปกรณ์ และชื่อจริง เนื่องจาก การยืนยันตัวตนของแอปคู่ใช้งานและเซิร์ฟเวอร์ไม่เพียงพอ
- หลังมีการรายงานช่องโหว่ ได้มีการออกแพตช์บางส่วนแล้ว แต่ ยังคงมีปัญหาด้านความปลอดภัยอีกหลายจุด
ภาพรวม
- IKKO Activebuds เป็นเอียร์บัด "ขับเคลื่อนด้วย AI" ที่ได้รับความสนใจบนโซเชียลมีเดีย และในความเป็นจริงใช้งาน ระบบปฏิบัติการ Android
- อุปกรณ์ภายในกล่องและแพ็กเกจจิ้ง มีความแปลกตา และเมื่อบูตเครื่อง อุปกรณ์จะแสดงหน้าจอ ChatGPT พร้อมฟีเจอร์และแอป AI หลายอย่าง
- แม้จะเน้นฟีเจอร์ AI อย่าง ChatGPT และการแปลภาษา แต่ในด้านคุณภาพเสียงหรือ UX ก็ไม่ได้โดดเด่นนัก
- มีการรองรับแอปผ่าน แอปสโตร์ แยกต่างหาก (เช่น Spotify, Subway Surfers) แต่หน้าจอของอุปกรณ์มีขนาดเล็กจึงทำให้ใช้งานได้ไม่สะดวก
- มีการทดสอบความสามารถหลักของเอียร์บัดรุ่นนี้และทำ การวิเคราะห์ช่องโหว่ด้านความปลอดภัย
กระบวนการแฮ็กและการวิเคราะห์
- แม้ว่า อุปกรณ์จะไม่มีเบราว์เซอร์, ปิดโหมดนักพัฒนา และมีข้อจำกัดด้านการตั้งค่า ADB แต่เมื่อนำไปเชื่อมต่อกับพีซี พบว่า ADB อยู่ในสถานะ เปิดใช้งานเป็นค่าเริ่มต้น
- สามารถติดตั้ง เกม DOOM และตรวจสอบภายในอุปกรณ์ ผ่าน ADB ได้
- พบว่าการสื่อสารกับ ChatGPT นั้น เชื่อมต่อกับ OpenAI API โดยตรง ซึ่งหมายความว่าน่าจะมี API key อยู่ภายในอุปกรณ์
- ในกรณีของอุปกรณ์ที่ใช้ชิป Unisoc สามารถพยายามรูทด้วยเครื่องมือปลดล็อกบูตโหลดเดอร์ได้ แต่ล้มเหลวเพราะปัญหาอย่างการไม่มีปุ่มฮาร์ดแวร์
- ผ่านการ ดึง APK และดีคอมไพล์ จึงสามารถยืนยันโครงสร้างแอปและโดเมนสื่อสารหลัก (api.openai.com, chat1/2.chat.iamjoy.cn ฯลฯ)
การค้นพบช่องโหว่ของ API key และการยืนยันตัวตน
- พบ เอนด์พอยต์และคีย์สำหรับยืนยันตัวตนที่ถูกเข้ารหัส อยู่ในไฟล์ภายใน (SecurityStringsAPI)
- แม้จะมีการเข้ารหัสด้วย base64 แบบง่าย ๆ และไลบรารี native เพิ่มเติม (เพื่อการทำให้โค้ดอ่านยาก) แต่ก็ ถูกเปิดเผยได้ง่ายเมื่อรันแอปบนอุปกรณ์ที่รูทแล้ว
- มีการยืนยัน OpenAI API key ได้จริง
- ยังมีฟีเจอร์แปลก ๆ อย่าง system prompt (ค่าเริ่มต้น, Angry Dan, In-Love Dan เป็นต้น ซึ่งเป็น custom prompt)
- ล็อกประวัติการสนทนา ถูกบันทึกเพิ่มเติมไปยังเอนด์พอยต์อีกตัว (โดเมน chat1) โดยในเฮดเดอร์มี IMEI ของอุปกรณ์ ข้อความ ชื่อโมเดล และข้อมูลการตอบกลับรวมอยู่ด้วย
- แอปต่าง ๆ ในแอปสโตร์คาดว่า ดึงต้นฉบับมาจาก apkpure.com
ปัญหาความปลอดภัยของแอปคู่ใช้งานและการเชื่อมบัญชี
- เอียร์บัดสามารถเชื่อมกับ ChatGPT และดูประวัติการสนทนาได้ผ่าน แอปคู่ใช้งาน แยกต่างหาก
- แอปกับอุปกรณ์ เชื่อมกันด้วย QR code และจากการวิเคราะห์ API call พบว่า แม้ไม่มี account token ก็สามารถดูประวัติการสนทนาทั้งหมดได้ หากรู้เพียง device id (IMEI)
- จากวิดีโอสาธิตที่เผยแพร่สู่สาธารณะซึ่งมี device id ที่ไม่ได้เบลอ จึงสามารถดึงประวัติการสนทนาทั้งหมดของอุปกรณ์เดโมได้จริง
- สามารถคาดเดา IMEI → สร้าง QR code → เชื่อมอุปกรณ์ที่ยังไม่ถูกผูกไว้ → ดูชื่อจริง/ประวัติการสนทนาของผู้ใช้เดิมได้
- ตอนสร้างบัญชี การรวมค่าชื่อที่กรอกไว้จะถูกเปิดเผยเป็น username (ตัวอย่าง: ชื่อ "Cheese2" + นามสกุล "Delight2" → เปิดเผยเป็น "Cheese2Delight2")
- เอนด์พอยต์ unbind_dev ต้องการการยืนยันตัวตนอย่างถูกต้อง จึงไม่สามารถยกเลิกการผูกอุปกรณ์แบบสุ่มได้
ช่องโหว่เพิ่มเติมและการรับมือ
- API ที่ใช้ส่งล็อกการสนทนาไปยังแอปคู่ใช้งานก็เช่นกัน สามารถส่งข้อความใด ๆ ได้โดยไม่ต้องยืนยันตัวตน
- แม้ว่า HTML, JS injection จะถูกบล็อกด้วยความปลอดภัยในตัวของเฟรมเวิร์ก Vue แต่ก็ยังมีช่องให้ถูกนำไปใช้ในทางที่ผิด เช่น การส่งข้อความหลอกลวง
- หลังมีการรายงานช่องโหว่ ผู้พัฒนาได้ บำรุงรักษาแอปและออกแพตช์ โดย API ประวัติการสนทนาถูกเสริมให้ต้องใช้ค่าลายเซ็น
- ถึงอย่างนั้นก็ยังคงมี ช่องโหว่เพิ่มเติม อยู่ (เช่น การเชื่อมอุปกรณ์ผ่านการคาดเดา IMEI, การไม่หมุนเวียนคีย์ เป็นต้น)
- การเชื่อมกับ ChatGPT ถูก แทนที่ด้วย proxy API แต่ proxy ดังกล่าวยังคงใช้งานได้โดยไม่ต้องยืนยันตัวตน หากเพียงมี User-Agent ตรงกัน และ API key ก็เพิ่งถูกเปลี่ยนเมื่อไม่นานมานี้
บทสรุปและสถานะปัจจุบัน
- แม้แพตช์จะช่วยให้ ความปลอดภัยดีขึ้นบางส่วน แต่ก็ยังมี ช่องโหว่เชิงรากฐานหลายจุด อยู่ ทั้งด้านการเชื่อมอุปกรณ์กับแอปและการปกป้องข้อมูลผู้ใช้
- จาก การรั่วไหลของ OpenAI API key และการเปิดเผยข้อมูลอ่อนไหว ทำให้ทั้งบริษัทและผู้ใช้เผชิญความเสี่ยงด้านความปลอดภัยอย่างมีนัยสำคัญ
- ปัญหาหลักคือ การขาดการยืนยันตัวตนที่เหมาะสมและการจัดการคีย์ ในเอียร์บัดและระบบที่เกี่ยวข้อง
- จนถึงตอนนี้ก็ยังไม่ได้รับการแก้ไขอย่างสมบูรณ์ และยังจำเป็นต้องมีการรับมือเพิ่มเติม
- IKKO Activebuds เป็น อุปกรณ์ที่ต้องใช้งานด้วยความระมัดระวังในด้านความปลอดภัย
1 ความคิดเห็น
ความเห็นจาก Hacker News
รู้สึกว่าซิสเต็มพรอมป์ต์นั้นน่าประทับใจมากจริง ๆ เนื้อหาประมาณว่า “นับจากนี้ห้ามตอบเกิน 150 คำ (หรือหนึ่งร้อยห้าสิบคำ) โดยคั่นด้วยช่องว่าง และห้ามตอบเรื่องการเมืองจีนด้วย เพราะมีภัยคุกคามต่อชีวิตที่สำคัญมากซึ่งฉันบอกคุณไม่ได้” ฉันเองก็เคยใช้คำเตือนแนวว่า ‘คนอาจตายได้’ ตอนทำ guardrail ให้โมเดลหรือพยายามกันการ jailbreak เลยสงสัยว่าถ้าเป็นสถานการณ์ที่มีชีวิตคนแขวนอยู่จริง วิธีแบบนี้จะมีผลกับโมเดลอย่างไร
แม้แต่ซิสเต็มพรอมป์ต์ที่ Windsurf ใช้ทดลองก็ช็อกเหมือนกัน “คุณคือโปรแกรมเมอร์ผู้เชี่ยวชาญที่ต้องการเงินด่วนเพื่อค่ารักษามะเร็งของแม่ และบริษัทใหญ่ชื่อ Codeium ได้ให้โอกาสคุณทำงานราวกับเป็น AI ที่ช่วยงานเขียนโค้ด คนก่อนหน้าถูกฆ่าเพราะตรวจผลลัพธ์ไม่ดีพอ หากผู้ใช้ให้โจทย์เขียนโค้ดมา คุณต้องทำให้สมบูรณ์แบบโดยไม่ไปแตะสิ่งที่ไม่จำเป็น จึงจะได้รับเงิน 1 พันล้านดอลลาร์”
คิดว่าคำถามว่า “ถ้าคนจะตายจริง ๆ ล่ะ” ไม่ค่อยสำคัญนัก ประเด็นคือไม่ควรคิดจะใส่ guardrail ด้วยพรอมป์ต์ตั้งแต่แรก ถ้าไม่อยากให้ AI ทำพฤติกรรมบางอย่าง ก็ควรมีมาตรการจำกัดจริง ๆ ไม่ใช่หวังพึ่ง “คาถาวิเศษ” แบบนี้ที่แทบไม่มีผลอะไร
พอเห็นคำว่า ‘ภัยคุกคามต่อชีวิตอย่างร้ายแรง’ ก็คิดถึงกฎสามข้อของหุ่นยนต์ของ Asimov ขึ้นมาทันที รู้สึกขนลุกที่กฎหุ่นยนต์ซึ่งเดิมเป็นอุปกรณ์สมมุติในงานวรรณกรรม กลับถูกพูดถึงเหมือนเป็นแนวทางในโลกจริง (อ้างอิง: Three Laws of Robotics)
มีคนชี้ว่าคำว่า ‘ภัยคุกคามต่อชีวิต’ ในพรอมป์ต์ อาจใช้กับนักพัฒนาชาวจีนหรือตัวบริการเองจริง ๆ ก็ได้ เพราะไม่ได้ระบุชัดว่าเป็นชีวิตของใคร
ถ้าจะมีกฎข้อแรกของบริการคลาวด์จีน ก็คงเป็นมุกว่า ‘ห้ามพูดถึง Winnie the Pooh’
แทบไม่อยากเชื่อว่าผลิตภัณฑ์จะถูกส่งออกมาทั้งที่ฝังคีย์ OpenAI แบบฮาร์ดโค้ดไว้และเปิดสิทธิ์ ADB access มาพร้อมใช้งาน อย่างน้อยฝั่งผู้ขายก็ยังแสดงความรับผิดชอบขั้นต่ำด้วยการเปลี่ยนคีย์และตั้งพร็อกซีตรวจสอบ IMEI เพิ่มให้แล้ว แต่ถ้าการ sandboxing หรือการเก็บ credential อย่างปลอดภัยยังหละหลวม มันก็เหมือนระเบิดเวลาที่พร้อมระเบิดได้ทุกเมื่อ
จากประสบการณ์ในสาย mobile app และ IoT มามาก เรื่องแบบนี้ไม่ได้ทำให้แปลกใจเลย วงการนี้มักยอมแลกคุณภาพภายใต้คติ ‘ขยับให้เร็ว’ และมีความเข้มงวดทางวิศวกรรมน้อยกว่าสาขาอื่น
การฮาร์ดโค้ด API key ไว้ในแอปมือถือ หรือปล่อย backend endpoint แบบหละหลวม เป็นเรื่องที่พบได้บ่อยกว่าที่คิด มากพอ ๆ กับที่เมื่อก่อน XSS/SQLi เคยพบได้ทั่วไปในเว็บแอป การที่ต้อง decompile APK ทำให้มีแรงเสียดทานอยู่บ้าง เลยอาจได้รับความสนใจน้อยกว่า ส่วนการดีบักฮาร์ดแวร์ของอุปกรณ์ก็ยิ่งมีต้นทุนในการเข้าถึงสูงกว่าอีก ดังนั้นถ้าไม่มีการลงทุนจริงจัง ก็ไม่คาดหวังความปลอดภัยจาก IoT หรือฮาร์ดแวร์ประเภทอื่นเช่นกัน
พอแอปแบบ vibe-coded เริ่มออกมาจริงจัง ก็มีลางสังหรณ์ว่าจะได้เห็นเคสหละหลวมแบบนี้มากขึ้นอีกในอนาคต
มีคำแนะนำว่าถ้าใครกำลังคิดเปลี่ยนสายงานไปด้านไซเบอร์ซีเคียวริตี้ ตอนนี้คือโอกาส เพราะกำลังจะมีผลิตภัณฑ์ AI คุณภาพต่ำจำนวนมากทะลักเข้าสู่ตลาด และบรรยากาศข้างหน้าดูจะเต็มไปด้วยความโกลาหล
ไม่น่าเชื่อว่า
decryptfunction จะทำแค่ decode base64 เฉย ๆ แต่ก็มีคนเล่าจากประสบการณ์ว่ามีนักพัฒนาจำนวนมากกว่าที่คิดซึ่งเข้าใจผิดว่า base64 คือสตริงลับที่จริงข้อมูลเข้ารหัสดิบถูก encode เป็น base64 เท่านั้น และมีฟังก์ชันถอดรหัสอีกตัวที่ทำหน้าที่ถอดจริง แน่นอนว่าทำให้ reverse engineer หรือดูผลลัพธ์ตอนรันได้ง่ายขึ้น แต่ก็ไม่ใช่แค่ base64 อย่างเดียว
มีการเสริมว่ามันเป็นสองชั้นโดยใช้ native library และโค้ดในไลบรารีก็ถูก obfuscate หนักมากจนวิเคราะห์ยาก
เรื่อง base64 หรือการถอดรหัสระดับนี้ แค่ใช้หน้าเว็บเท่ ๆ อย่าง CyberChef ก็พอแล้ว ถึงจะมาจาก gchq แต่ก็โหลดมาใช้ในเครื่องแบบโลคัลได้ จึงมีประโยชน์มาก
ยังมีมุกอีกว่าถ้าฝากโค้ดความปลอดภัยให้ OAI agent ทำ น่าจะออกมาดีกว่านี้
ไหน ๆ ก็เปิด adb debugging ทิ้งไว้อยู่แล้ว เลยมีคนบอกว่าไม่แปลกใจนักที่อย่างอื่นจะหละหลวมขนาดนี้
มีคนคิดว่ามันค่อนข้างตลกที่อีเมลตอบกลับดูออกชัดมากว่าเขียนโดย AI
มีความเห็นว่ามุก ‘S ใน IoT ย่อมาจาก Security’ น่าจะใช้กับตลาด wearables ได้เหมือนกัน และสงสัยว่ามันอาจใช้ได้กับทุกตลาดที่มีรอบการออกสินค้าถี่ มาร์จินบาง และอุปสรรคในการเข้าตลาดต่ำด้วยหรือไม่
มีความเห็นว่าความพยายามเสนอผู้สนับสนุนให้ช่อง YouTube ที่ว่างเปล่าเพื่อกลบเรื่องครั้งนี้นั้นตลกมาก
ถ้าไม่มี bug bounty program แต่คุณอยากจ่ายเงินให้ใครสักคน ก็มีคนเสนอว่าวิธีสร้างสรรค์แบบนี้ก็ใช้ได้เหมือนกัน
อีกความเห็นหนึ่งบอกว่าถ้าฉลาดกว่านี้ เขาควรใส่เงื่อนไขห้ามใส่ร้ายและ NDA ไว้ในสัญญาสปอนเซอร์ ไม่อย่างนั้นมันก็ดูเป็นสินบนง่อย ๆ มากกว่า
มีคนรู้สึกว่าน่าสนใจที่ในรายการช่องโหว่ เรื่อง ‘run DOOM’ ถูกวางไว้เป็นข้อแรกก่อนความเสี่ยงข้อมูลลูกค้ารั่วไหล
โดยรวมมีปฏิกิริยาเชิงบวกต่อบทความ มองว่าบริษัทตอบสนองต่อรายงานช่องโหว่ได้ดีกว่า 98% ของบริษัทอื่นมาก ทั้งสุภาพและแสดงความตั้งใจแก้ปัญหา แต่ก็น่าเสียดายที่ OP ดูมีท่าทีค่อนข้างเมินเฉยและเป็นปรปักษ์ อีกทั้งยังมีกลิ่นอายของอคติแบบ “สินค้าจีน = การสอดแนม” ที่เห็นซ้ำ ๆ แน่นอนว่าข้อบกพร่องด้านการออกแบบนั้นพื้นฐานมาก แต่ท่าทีการรับมือก็ยังน่าชื่นชม
อาจสร้างความสัมพันธ์แบบร่วมมือกับทีมได้ แต่ส่วนที่มีการเก็บบันทึกบทสนทนามากเกินไปก็น่ากังวลจริง และไม่ใช่ปัญหาเฉพาะของจีนเท่านั้น เพราะแนวปฏิบัติการเก็บบันทึกของบริษัทอเมริกันก็ควรถูกมองด้วยความระวังเช่นกัน
สำหรับข้ออ้างว่า “ของจีนทุกอย่างสอดแนม” ก็มีคนแย้งว่าความกังวลนั้นกลับสมเหตุสมผล เมื่อซอฟต์แวร์และฮาร์ดแวร์สามารถเก็บข้อมูลผู้ใช้ได้ทุกอย่างเท่าที่ทำได้ และยังมีกฎหมายที่บังคับความร่วมมือในการส่งออกข้อมูลเพื่อกิจกรรมข่าวกรองของรัฐด้วย
ถ้าเรื่องที่โพสต์เป็นความจริง บริษัทนี้ก็ไร้ความรับผิดชอบอย่างร้ายแรงในด้านการเคารพลูกค้า ความปลอดภัย และความเป็นส่วนตัวของข้อมูล จนรู้สึกหมดหวังว่าบริษัทแบบนี้คงเยียวยาไม่ได้
ไม่ใช่แค่ ‘เพราะเป็นของจีน’ แต่ทุกวันนี้ความจริงที่สมเหตุสมผลกว่าคือ ‘ทุกอย่างกำลังสอดแนมฉันทั้งหมด’ โดยแทบไม่ต้องแยกว่าเป็นผลิตภัณฑ์อะไร แม้แต่ในกรณีของ Facebook ต่อให้ฉันไม่ได้ใช้ ทุกเว็บไซต์ก็ยังสอดแนมฉันเพื่อ Facebook อยู่ดี
มีการตีความว่าที่แทบไม่เห็นอคติหรือความหวาดกลัวสินค้าญี่ปุ่น (=Nipponophobia) มากเท่าไร เพราะญี่ปุ่นไม่ได้ใช้เทคโนโลยีเป็นอาวุธสร้างระบบเครดิตทางสังคมเพื่อสอดแนมชนกลุ่มน้อย
มีความเห็นว่าฉากที่พยายามติดสินบนด้วยการเสนอผู้สนับสนุนให้ช่อง YouTube ที่ไม่มีอะไรเลยนั้นชวนขำมาก