สรุปสั้น
ทีมวิจัยจาก Jakkaru เปิดเผยช่องโหว่ร้ายแรงในแพลตฟอร์มคลาวด์ iSolarCloud ของบริษัท Sungrow ผู้ผลิตอินเวอร์เตอร์พลังงานแสงอาทิตย์รายใหญ่ของโลก ช่องโหว่นี้เป็นความผิดพลาดเชิงตรรกะ (business logic) ในขั้นตอนล็อกอิน เมื่อส่งค่าหนึ่งในฟิลด์ login_type ระบบจะยืนยันตัวตนบัญชีที่ระบุในคำขอโดยไม่สนใจฟิลด์รหัสผ่านเลย ผู้ที่รู้อีเมลของเป้าหมายจึงเข้าบัญชีนั้นได้โดยไม่ต้องรู้รหัสผ่าน และระบบไม่ส่งอีเมลหรือการแจ้งเตือนใด ๆ เมื่อมีการล็อกอินด้วยวิธีนี้
ความรุนแรงอยู่ที่บัญชีลูกค้าทั่วไปและบัญชีผู้ดูแลระบบใช้สภาพแวดล้อมจัดการเดียวกัน บัญชีแอดมินที่ถูกยึดสามารถดูและแก้ไขข้อมูลโรงไฟฟ้า สั่งหยุดหรือเริ่มอินเวอร์เตอร์และระบบแบตเตอรี่ เข้าถึงข้อมูลองค์กรและผู้ใช้ที่ลงทะเบียน และติดตั้งเฟิร์มแวร์กำหนดเองบนอุปกรณ์ที่เชื่อมต่อคลาวด์ในภูมิภาคนั้นได้ Sungrow ออก hotfix ภายใน 1 วันหลังได้รับแจ้ง และเริ่มทบทวนหาต้นเหตุกับจุดอ่อนที่เกี่ยวข้อง แต่รายงานสาธารณะไม่ได้ระบุเลข CVE รายการเฟิร์มแวร์ที่ได้รับผลกระทบ หรือเวอร์ชันแพตช์สำหรับลูกค้า
รายละเอียดข่าว
เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 8 ตุลาคม 2569 อ้างงานวิจัยของ Jakkaru ว่าช่องโหว่ในขั้นตอนล็อกอินของ iSolarCloud อาจเปิดทางให้ผู้โจมตีเข้าสู่แพลตฟอร์มจัดการโดยไม่มีรหัสผ่านที่ถูกต้อง iSolarCloud เป็นบริการคลาวด์ที่ผู้ใช้และผู้ดูแลระบบใช้เข้าถึงและควบคุมโรงไฟฟ้าพลังงานแสงอาทิตย์ อินเวอร์เตอร์ และระบบกักเก็บพลังงานจากระยะไกล ช่องโหว่จึงสร้างความเสี่ยงให้ลูกค้าและผู้ประกอบการพลังงานในยุโรป จีน ออสเตรเลีย และภูมิภาคอื่น
Sungrow ระบุว่าบริษัทติดตั้งอุปกรณ์แปลงกำลังไฟฟ้า (power electronic converter) ไปแล้วกว่า 870 กิกะวัตต์ทั่วโลก ณ เดือนมิถุนายน 2568 ขณะที่ Jakkaru ประเมินในภายหลังว่าตัวเลขเกิน 1,000 กิกะวัตต์แล้ว ด้วยฐานลูกค้าขนาดนี้ ปัญหาความปลอดภัยของคลาวด์จึงกระทบมากกว่าบ้านหรือธุรกิจที่ติดโซลาร์เพียงแห่งเดียว
Jakkaru ระบุว่ารายงานช่องโหว่ไปยังทีม PSIRT (Product Security Incident Response Team) ของ Sungrow ทันทีที่พบ และอธิบายการตอบสนองของบริษัทว่าเป็นไปในทางบวก ข่าวนี้ต่อจากปัญหาความปลอดภัยของอินเวอร์เตอร์ที่มีการรายงานมาก่อน เช่น งานวิจัย SUN:DOWN ที่พบช่องโหว่ 46 รายการในอินเวอร์เตอร์ของผู้ผลิตรายใหญ่หลายราย โดยฝั่ง Sungrow พบจุดอ่อนเกี่ยวกับดองเกิลสื่อสาร การอ้างอิงออบเจกต์โดยตรงแบบไม่ปลอดภัย (IDOR) และ credential ที่ฝังตายตัว รวมถึงมีรายงานอุปกรณ์โซลาร์หลายหมื่นเครื่องที่เปิดสู่อินเทอร์เน็ตโดยตรง
รายละเอียดช่องโหว่
iSolarCloud ป้องกันการทดสอบด้วยการเข้ารหัสคำขอ REST API ลงลายเซ็นคำขอ (request signature) และใช้ header กำหนดเอง กลไกเหล่านี้ทำให้การวิเคราะห์ยากขึ้น แต่ไม่ได้แก้ปัญหาที่อยู่ในตรรกะการล็อกอิน ระหว่างตรวจสอบ ทีม Jakkaru พบว่าฟิลด์ login_type ในคำขอล็อกอิน เมื่อตั้งเป็นค่าเฉพาะค่าหนึ่ง จะทำให้ระบบยืนยันตัวตนบัญชีที่ระบุในคำขอโดยข้ามการตรวจรหัสผ่าน ผู้โจมตีจึงต้องรู้เพียงอีเมลของบัญชีเป้าหมาย ซึ่งในบริบทของผู้ติดตั้งและผู้ดูแลโรงไฟฟ้ามักหาได้ไม่ยาก
ปัญหาซ้ำเติมด้วยการที่ระบบไม่ส่งการแจ้งเตือนการล็อกอินเมื่อใช้วิธีนี้ ผู้บุกรุกจึงอยู่ในบัญชีได้โดยเจ้าของไม่รู้ตัว แล้วใช้ฟีเจอร์กู้คืนบัญชีเพื่อยึดสิทธิ์ควบคุมระยะยาว และเนื่องจากบัญชีลูกค้าและบัญชีแอดมินอยู่ในสภาพแวดล้อมจัดการเดียวกัน ความเสี่ยงจึงขยายไปถึงการยกระดับสิทธิ์ หากบัญชีแอดมินถูกยึด ผู้บุกรุกจะควบคุมโรงไฟฟ้าทั้งหมดที่ผูกกับคลาวด์ภูมิภาคนั้นได้ในวงกว้าง ตั้งแต่การดูและแก้ไขข้อมูลโรงไฟฟ้า การหยุดหรือเริ่มอินเวอร์เตอร์และแบตเตอรี่ การเข้าถึงข้อมูลองค์กรและผู้ใช้ ไปจนถึงการติดตั้งเฟิร์มแวร์กำหนดเอง
รายงานสาธารณะไม่ได้เปิดเผยค่า login_type ที่ใช้ ไม่มีเลข CVE ไม่มีคะแนน CVSS และไม่ระบุว่าช่องโหว่มีอยู่นานเท่าใดก่อนถูกแก้ หรือมีหลักฐานการใช้งานจริงหรือไม่ ข้อมูลส่วนนี้จึงยังมีน้อยมาก
ผลกระทบ
ผลกระทบไม่จำกัดแค่การขโมยข้อมูล เฟิร์มแวร์ที่เป็นอันตรายสามารถเปลี่ยนพฤติกรรมของอุปกรณ์ได้ และการสั่งปิดหรือเปลี่ยนค่าอินเวอร์เตอร์จำนวนมากพร้อมกันอาจทำให้กำลังผลิตไฟฟ้าจากแสงอาทิตย์หายไปในคราวเดียว ซึ่งเป็นความกังวลที่เพิ่มขึ้นเมื่ออินเวอร์เตอร์กลายเป็นส่วนสำคัญของระบบพลังงานระดับประเทศ ช่องโหว่ในคลาวด์จัดการกลางยังอันตรายกว่าช่องโหว่ในอุปกรณ์ทีละเครื่อง เพราะจุดเดียวเปิดทางไปยังอุปกรณ์จำนวนมหาศาลโดยไม่ต้องเจาะทีละไซต์
แม้ Sungrow จะแก้ไขเร็ว แต่การไม่มีเลข CVE และไม่บอกว่ามีการใช้ช่องโหว่ก่อนแพตช์หรือไม่ ทำให้เจ้าของโรงไฟฟ้าประเมินได้ยากว่าบัญชีของตนเคยถูกเข้าถึงหรือเปล่า โดยเฉพาะเมื่อระบบไม่เคยส่งการแจ้งเตือนการล็อกอินแบบนี้ตั้งแต่แรก
คำแนะนำ
- ผู้ใช้และผู้ดูแลโรงไฟฟ้าที่ใช้ iSolarCloud ตรวจให้แน่ใจว่าบัญชีและอุปกรณ์ที่เชื่อมต่ออัปเดตครบ เปลี่ยนรหัสผ่าน และเปิด MFA หากมีให้ใช้
- ทบทวนรายชื่อผู้ใช้และผู้ดูแลในบัญชี ลบผู้ติดตั้งเก่าหรือบุคคลภายนอกที่ไม่จำเป็นต้องเข้าถึงแล้ว และตรวจการตั้งค่ากู้คืนบัญชี (อีเมล/เบอร์โทร) ว่ายังเป็นของเจ้าของจริง
- ตรวจประวัติการเปลี่ยนแปลงในแพลตฟอร์ม เช่น การหยุดอินเวอร์เตอร์ การเปลี่ยนค่า หรือการอัปเดตเฟิร์มแวร์ที่ไม่ได้สั่งเอง และสอบถาม Sungrow ถึงล็อกการเข้าถึงย้อนหลังหากสงสัย
- จำกัดสิทธิ์บนคลาวด์ให้เหลือเฉพาะฟังก์ชันที่จำเป็น และแยกบัญชีแอดมินออกจากการใช้งานประจำวัน
- ไม่เปิดหน้าจัดการอินเวอร์เตอร์ dashboard เกตเวย์ หรือ data logger สู่อินเทอร์เน็ตโดยตรง และแยกเครือข่ายอุปกรณ์พลังงานออกจากเครือข่ายสำนักงาน
- ผู้ประกอบการพลังงานที่ใช้อินเวอร์เตอร์จำนวนมากควรรวมแพลตฟอร์มคลาวด์ของผู้ผลิตไว้ในการประเมินความเสี่ยงซัพพลายเชน และพิจารณาโหมดควบคุมในพื้นที่ (local control) สำหรับการสั่งงานสำคัญ