Sansec บริษัทด้านความปลอดภัย E-Commerce จากเนเธอร์แลนด์ เปิดเผยช่องโหว่ Zero-Day ที่ตั้งชื่อว่า StyleSmuggler ใน Magento Open Source และ Adobe Commerce ซึ่งกำลังถูกผู้ไม่ประสงค์ดีนำไปใช้โจมตีจริงเพื่อยึดควบคุมร้านค้าออนไลน์แบบเต็มรูปแบบโดยไม่ต้อง Login หรือ Authentication ใดๆ Sansec ตัดสินใจเปิดเผยข้อมูลตั้งแต่วันที่ 5 กันยายน 2569 ก่อนที่การวิเคราะห์ทางเทคนิคจะเสร็จสมบูรณ์ โดยระบุเหตุผลว่า "stores are being compromised right now" เนื่องจากพบว่าการโจมตีจริงเริ่มขึ้นตั้งแต่วันก่อนหน้า และ ณ วันที่เผยแพร่บทความนี้ Adobe ยังไม่ออก Advisory, กำหนดหมายเลข CVE หรือเผยแพร่ Patch/Workaround อย่างเป็นทางการแต่อย่างใด
รายละเอียดช่องโหว่
ขอบเขตผลกระทบที่กว้างขวางผิดปกติ
StyleSmuggler กระทบทุกเวอร์ชันปัจจุบันของ Magento และ Adobe Commerce รวมถึงเวอร์ชันล่าสุด 2.4.9 และไม่ต้องอาศัยการยืนยันตัวตนใดๆ ในการโจมตี Sansec สามารถทำซ้ำ Attack Chain แบบไม่ต้อง Authenticate ได้บนการติดตั้งสะอาดของ Magento Open Source ทั้งเวอร์ชัน 2.4.7, 2.4.8 และ 2.4.9 ยืนยันว่าปัญหานี้ไม่ได้ผูกติดกับ Build เก่าที่ล้าสมัยเพียงอย่างเดียว และที่น่ากังวลยิ่งกว่าคือเหยื่อรายแรกที่พบเป็นร้านค้าที่รันเวอร์ชัน 2.4.6-p15 พร้อม Security Patch ของเดือนกรกฎาคมและสิงหาคม 2026 ครบถ้วนแล้ว แสดงว่าร้านค้าที่แพตช์ตามปกติก็ยังคงถูกโจมตีได้ง่ายไม่ต่างจากร้านที่ไม่ได้ดูแล
กลไกการโจมตี 2 ขั้นตอน
การโจมตีอาศัยระบบ Template Rendering และ Email ของ Magento เอง แทนที่จะเป็นช่องทาง Injection ที่ชัดเจนแบบเดียว
ขั้นตอนที่ 1 — การฝังโค้ด: ผู้โจมตีฝังโค้ด PHP อันตรายลงในไฟล์ที่ Magento เขียนขึ้นเองตามการทำงานปกติ เช่น รายงาน Payment Failure โดยอาศัยการปรับแต่งค่า "styles" ภายใน GraphQL Request เพื่อหลบเลี่ยงการกรอง Input ที่มีอยู่เดิม จากการวิเคราะห์อิสระของบริษัท Hosting ชื่อ Disrex Group ซึ่งดูแลร้านค้าที่ถูกบุกรุก 2 แห่ง พบว่า Directive ที่สร้างขึ้นเป็นพิเศษภายในข้อความที่ฝังไว้จะบังคับให้ Class ต่างๆ ของ Magento ทำงานเป็นลูกโซ่ จนกระทั่งรันโค้ดที่ปกติควรทำงานผ่าน Command-line Dependency-injection Compiler เท่านั้น รวมถึงการอ่านไฟล์ Log ที่ถูกวางยาพิษไว้ด้วย
ขั้นตอนที่ 2 — การกระตุ้นให้ทำงาน: Sansec พบว่า StyleSmuggler จงใจกระตุ้นให้ Magento ส่งอีเมล "Payment Transaction Failed Reminder" ตามการทำงานปกติของระบบ และโค้ดอันตรายจะทำงานทันทีที่ Magento Render ข้อความนี้ภายในระบบ ซึ่งหมายความว่าไม่มีใครจำเป็นต้องเปิดหรือแม้แต่ได้รับอีเมลนั้นเลยการโจมตีก็สำเร็จแล้ว
ลักษณะของ Malware ที่ติดตั้ง
เมื่อโค้ดทำงานสำเร็จ Dropper แบบ PHP จะวนตรวจสอบฟังก์ชัน PHP 6 ตัวจนกว่าจะพบตัวที่สามารถสร้าง Process ได้ จากนั้นจะดาวน์โหลดและเปิดใช้งาน Implant ที่ฝังตัวถาวร Disrex อธิบายว่า Malware นี้เป็น Rust Binary ขนาดเล็กแบบ Static-linked ราว 1.9 MB ที่ Compile ไว้สำหรับทั้งสถาปัตยกรรม x86-64 และ ARM64 โดยปลอมตัวเป็น Linux Kernel Thread ชื่อ "[kworker/u:8:0]" และRestart ทุก 5 นาทีผ่าน Cron Entry ที่เขียนตรงลง Crontab Spool File เพื่อไม่ทิ้ง Log ของระบบตามปกติ
เทคนิคหลบเลี่ยงการตรวจจับขั้นสูง
การตรวจจับการติดเชื้อทำได้ยากกว่าที่คิด เนื่องจาก Malware มีการหลบเลี่ยงการตรวจสอบแบบพื้นฐานอย่างจงใจ Kernel Worker Thread ตัวจริงจะถูกเป็นเจ้าของโดย Root และไม่ใช้หน่วยความจำแบบ Resident ดังนั้น Process "[kworker]" ใดๆ ที่รันภายใต้บัญชีผู้ใช้ของเว็บไซต์เองและมีการใช้หน่วยความจำจริงถือเป็นสัญญาณอันตราย นอกจากนี้ Disrex ยังพบว่าBinary ที่รันอยู่ในหน่วยความจำบางครั้งแตกต่างจากไฟล์ที่อยู่บน Disk หมายความว่าทีมป้องกันควร Hash ทั้งไฟล์และ Process ที่กำลังทำงานอยู่เพื่อตรวจสอบให้ครบถ้วน
บนร้านค้าที่ถูกบุกรุกแห่งหนึ่ง พบว่า Implant ไม่มีการเชื่อมต่อ Internet ขาออกเลย แต่กลับเปิด 28 Connection พร้อมกันไปยัง Redis Instance ของร้านเอง เพื่ออ่านข้อมูล Session ของ Magento แบบ Real-time ทำให้ปฏิบัติการเกือบมองไม่เห็นสำหรับเครื่องมือ Network-based Monitoring ทั่วไป
ตำแหน่งไฟล์ที่ควรตรวจสอบ
แนวทางตรวจจับที่ Sansec เผยแพร่แนะนำให้ค้นหา Marker String ในโฟลเดอร์ var/report ของ Magento แต่ Disrex พบว่าร้านค้าที่ถูกบุกรุกทั้ง 2 แห่งที่ตนดูแลถูกฝังโค้ดผ่านไฟล์ var/log/system.log แทน ผู้ดูแลระบบจึงจำเป็นต้องตรวจสอบทั้งสองตำแหน่งไฟล์ ไม่ใช่เพียงตำแหน่งใดตำแหน่งหนึ่ง
ผลกระทบที่อาจเกิดขึ้น
- ช่องโหว่นี้ไม่ต้องอาศัยการยืนยันตัวตนใดๆ และกระทบร้านค้าออนไลน์ทุกเวอร์ชันแม้จะแพตช์ Security Update ครบถ้วนแล้วก็ตาม ทำให้ร้านค้าทุกแห่งที่ใช้ Magento หรือ Adobe Commerce มีความเสี่ยงเท่าเทียมกัน ไม่ว่าจะดูแลระบบดีเพียงใด
- การตรวจจับทำได้ยากเป็นพิเศษ เนื่องจาก Malware ปลอมตัวเป็น Kernel Process และในบางกรณีไม่มี Traffic ขาออกเลย ทำให้เครื่องมือ Network Monitoring แบบดั้งเดิมตรวจจับไม่ได้ ต้องอาศัยการตรวจสอบเชิงลึกถึงระดับ Process และ Memory
- เนื่องจากยังไม่มี Patch อย่างเป็นทางการจาก Adobe ร้านค้าที่ได้รับผลกระทบต้องพึ่งพามาตรการชั่วคราวเท่านั้น ทำให้มีความเสี่ยงต่อเนื่องยาวนานกว่าปกติจนกว่าจะมีการแก้ไขอย่างเป็นทางการเผยแพร่ออกมา
- ร้านค้าที่ถูกยึดควบคุมอาจสูญเสียข้อมูล Session ลูกค้า ข้อมูลการชำระเงิน หรือถูกใช้เป็นฐานสำหรับโจมตีระบบอื่นต่อไป เนื่องจาก Implant สามารถเข้าถึงข้อมูล Session แบบ Real-time ผ่าน Redis ได้โดยตรง
สิ่งที่องค์กรควรทำ
- ปิดใช้งาน GraphQL ชั่วคราวสำหรับร้านค้าที่ไม่ได้พึ่งพา Headless Commerce หรือ Progressive Web App Storefront เนื่องจาก Theme แบบ Classic และ Hyvä โดยทั่วไปไม่จำเป็นต้องใช้ GraphQL และการปิดใช้งานช่วยตัดช่องทางการโจมตีหลักได้ทันที
- ตรวจสอบทั้งไฟล์ var/report และ var/log/system.log อย่างละเอียด เนื่องจากพบว่าบางร้านค้าถูกฝังโค้ดผ่าน system.log แทนที่จะเป็น var/report ตามคำแนะนำเดิมของ Sansec เพียงอย่างเดียว
- พิจารณาปิดใช้งานฟังก์ชัน proc_open ของ PHP และ Mount โฟลเดอร์ Temporary Directory ด้วย noexec เพื่อสกัดกั้น Dropper ไม่ให้สามารถรัน Payload ได้ แม้จะยังไม่เข้าใจ Exploit Chain อย่างครบถ้วนก็ตาม เนื่องจากมาตรการระดับ Server นี้ไม่ต้องพึ่งพาความเข้าใจในรายละเอียดของช่องโหว่
- ติดตาม Unofficial Patch จาก Disrex, ProxiBlue หรือ Graycore ไว้เป็นมาตรการเสริมชั่วคราว แต่ควรตระหนักว่าเป็นเพียงมาตรการ Hardening ไม่ใช่การแก้ไขที่แท้จริง และให้เตรียมพร้อมติดตั้ง Patch อย่างเป็นทางการทันทีที่ Adobe เผยแพร่ออกมา
แนวทางลดความเสี่ยงระยะยาว
1. จัดทำกระบวนการตรวจสอบ Process และ Binary Hash บน Production Server อย่างสม่ำเสมอ
เนื่องจากเทคนิคการปลอมตัวเป็น Kernel Process ที่พบในเหตุการณ์นี้อาจถูกนำไปใช้ในการโจมตีอื่นในอนาคต การมีกระบวนการ Baseline และเปรียบเทียบ Process ที่ทำงานอยู่อย่างสม่ำเสมอช่วยตรวจจับความผิดปกติได้เร็วขึ้น
2. ทบทวนสถาปัตยกรรมความปลอดภัยของ E-Commerce Platform ให้มีการแบ่งแยกสิทธิ์และ Network Segmentation ที่ชัดเจน
โดยเฉพาะการจำกัดสิทธิ์การเข้าถึง Redis หรือฐานข้อมูล Session อื่นให้เฉพาะ Process ที่จำเป็นเท่านั้น เพื่อลดผลกระทบหาก Web Application ถูกบุกรุกสำเร็จ
3. พิจารณาใช้ Web Application Firewall (WAF) ที่สามารถตรวจสอบ GraphQL Request อย่างละเอียด
เนื่องจาก StyleSmuggler อาศัยการปรับแต่งค่าใน GraphQL Request เป็นช่องทางหลัก WAF ที่เข้าใจโครงสร้าง GraphQL อย่างลึกซึ้งอาจช่วยตรวจจับ Pattern การโจมตีลักษณะนี้ได้ดีกว่า WAF ทั่วไป
4. สร้างความสัมพันธ์กับผู้ให้บริการ Hosting หรือ Security Vendor ที่เชี่ยวชาญด้าน E-Commerce Platform โดยเฉพาะ
เนื่องจากกรณีนี้แสดงให้เห็นว่าการวิเคราะห์อิสระจากบริษัท Hosting อย่าง Disrex สามารถค้นพบรายละเอียดเพิ่มเติมที่ Vendor หลักยังไม่ครอบคลุม การมีพันธมิตรที่เชี่ยวชาญเฉพาะทางช่วยให้องค์กรได้รับข้อมูลและมาตรการป้องกันที่ครบถ้วนกว่า
วิเคราะห์ในมุมมองจาก TXEC
กรณี StyleSmuggler เป็นตัวอย่างที่ชัดเจนของความเสี่ยงที่ TXEC ให้ความสำคัญมาโดยตลอดเกี่ยวกับช่องว่างระหว่างการค้นพบช่องโหว่ Zero-Day กับการเผยแพร่ Patch อย่างเป็นทางการ โดยเฉพาะเมื่อ Vendor หลักอย่าง Adobe ยังไม่มี Advisory หรือ CVE ออกมาให้ยึดถือ องค์กรจึงต้องพึ่งพามาตรการชั่วคราวจากชุมชน Security ภายนอกแทน ซึ่งแม้จะมีประโยชน์แต่ก็ไม่ควรถูกมองว่าเป็นการแก้ไขที่สมบูรณ์
TXEC มองว่าประเด็นที่น่ากังวลที่สุดในกรณีนี้คือข้อเท็จจริงที่ว่าร้านค้าที่แพตช์ Security Update ครบถ้วนตามปกติก็ยังคงถูกโจมตีได้ง่ายเช่นเดียวกับร้านที่ไม่ได้ดูแล ซึ่งท้าทายสมมติฐานทั่วไปที่ว่าการแพตช์สม่ำเสมอเพียงพอต่อการป้องกัน Zero-Day ลักษณะนี้ องค์กรที่ดำเนินธุรกิจ E-Commerce บน Magento หรือ Adobe Commerce ควรพิจารณามาตรการป้องกันระดับ Server ที่ไม่ต้องพึ่งพาความเข้าใจในรายละเอียดของช่องโหว่เฉพาะเจาะจง เช่น การปิด proc_open และ noexec บน Temporary Directory ควบคู่ไปกับการติดตามสถานการณ์อย่างใกล้ชิดจนกว่า Adobe จะเผยแพร่การแก้ไขอย่างเป็นทางการ
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, Sansec, Disrex Group ]