โปรแกรมดักจับข้อมูล WebRTC ที่หลบเลี่ยงการควบคุมและขโมยข้อมูลในอีคอมเมิร์ซ

อินฟอร์เมเทค ดิจิตอล » Recursos » โปรแกรมดักจับข้อมูล WebRTC ที่หลบเลี่ยงการควบคุมและขโมยข้อมูลในอีคอมเมิร์ซ

มัลแวร์ ประเภทใหม่ที่ใช้เทคโนโลยี WebRTC กำลัง พลิกโฉม ความปลอดภัยของ แพลตฟอร์มอีคอมเมิร์ซ มัลแวร์นี้สามารถขโมยข้อมูลการชำระเงินได้โดยตรงจากเบราว์เซอร์ของลูกค้า และดึงข้อมูลนั้นออกมาจากเว็บไซต์โดยใช้ช่องทางข้อมูล WebRTC ซึ่งเป็นการหลีกเลี่ยงกลไกต่างๆ เช่น Content Security Policy (CSP) หรือ WAF แบบดั้งเดิมที่ตรวจสอบเฉพาะการรับส่งข้อมูล HTTP เท่านั้นได้อย่างแนบเนียน

วิธีการนี้ไม่เพียงแต่ชาญฉลาดเท่านั้น แต่ยังใช้ประโยชน์จากช่องโหว่ที่สำคัญ เช่นPolyShell ใน Magento และ Adobe Commerceซึ่งอนุญาตให้ผู้โจมตีที่ไม่ได้รับอนุญาตอัปโหลดโค้ดที่เป็นอันตรายและเรียกใช้บนเซิร์ฟเวอร์ได้ ผลลัพธ์ที่ได้คือการผสมผสานที่อันตรายอย่างยิ่ง: การเข้าถึงระบบได้ง่าย การแทรกสคริปต์อย่างเงียบ ๆ ในขั้นตอนการชำระเงิน และการขโมยข้อมูลบัตรเครดิตโดยใช้ WebRTC DTLS ผ่าน UDP ซึ่งแทบมองไม่เห็นโดยระบบป้องกันส่วนใหญ่ในปัจจุบัน

ใครอยู่เบื้องหลังการค้นพบนี้ และทำไมมันถึงสำคัญมาก?

Sansecบริษัทด้านความปลอดภัยทางไซเบอร์ที่เชี่ยวชาญด้านการปกป้องแพลตฟอร์มอีคอมเมิร์ซ ได้ค้นพบมัลแวร์ประเภท WebRTC skimmer ตัวใหม่นี้ งานของพวกเขาเน้นการวิเคราะห์เหตุการณ์มัลแวร์ในร้านค้าออนไลน์ การค้นหาการแทรกโค้ด มัลแวร์ขโมยข้อมูลการชำระเงิน และช่องโหว่ รวมถึงการให้ข้อมูลข่าวกรองภัยคุกคามที่มุ่งเน้นไปที่อีคอมเมิร์ซ

ความสำคัญของคดีนี้อยู่ที่ข้อเท็จจริงที่ว่านี่เป็นกรณีแรกที่มีการบันทึกไว้ว่ามีการใช้ WebRTC DataChannels เพื่อขโมยข้อมูลบัตรเครดิตในสภาพแวดล้อมอีคอมเมิร์ซ ก่อนหน้านี้ กลุ่มประเภท Magecart อาศัยการร้องขอ HTTP แบบดั้งเดิม บีคอนรูปภาพ หรือในกรณีที่ซับซ้อนกว่านั้นคือ WebSockets การก้าวกระโดดครั้งนี้เป็นการเปลี่ยนแปลงครั้งสำคัญอย่างแท้จริง

บริษัท Sansec ไม่ได้ค้นพบเรื่องนี้โดยบังเอิญในห้องทดลองที่โดดเดี่ยว แต่ค้นพบในระหว่างการตรวจสอบเหตุการณ์จริงที่เกิดขึ้นในบริษัทขนาดใหญ่หลายแห่ง บริษัทที่ได้รับผลกระทบ ได้แก่บริษัทผลิตรถยนต์ที่มีมูลค่ามากกว่า 100.000 พันล้านดอลลาร์เครือซูเปอร์มาร์เก็ตที่ติดอันดับ 10 บริษัทชั้นนำของโลก และบริษัทอื่นๆ ที่มีมูลค่าหลายพันล้านดอลลาร์ กล่าวอีกนัยหนึ่งคือ ผู้โจมตีได้พัฒนาเทคนิคของตนเพื่อมุ่งเป้าไปที่เหยื่อที่มีมูลค่าสูงที่สุดโดยตรง

ภายในระยะเวลาเพียงสองเดือน นักวิจัยสามารถระบุเครื่องมือขโมยข้อมูลบัตรเครดิตในองค์กรระดับนี้ได้ถึงห้าแห่ง ซึ่งเป็นการตอกย้ำแนวคิดที่ว่านี่ไม่ใช่การทดลองเพียงครั้งเดียวแต่เป็นแนวโน้มที่ชัดเจนไปสู่เทคนิคที่ซับซ้อนขึ้นซึ่งตรวจสอบได้ยากขึ้นด้วยเครื่องมือทั่วไป

วิธีการทำงานของ Skimmer: WebRTC DataChannels เปรียบเสมือนทางด่วนลับ

ในการโจมตีแบบขโมยข้อมูลบัตรเครดิตแบบดั้งเดิมส่วนใหญ่ รูปแบบการโจมตีค่อนข้างเป็นที่รู้จักกันดี กล่าวคือ ผู้โจมตีใช้ประโยชน์จากการตั้งค่าที่ไม่ถูกต้อง ปลั๊กอินที่มีช่องโหว่ หรือสคริปต์ของบุคคลที่สามที่ถูกบุกรุกเพื่อแทรกโค้ดที่ดักจับข้อมูลจากแบบฟอร์มการชำระเงินและส่งไปยังภายนอก โดยปกติผ่านคำขอ HTTP POST ไปยังเซิร์ฟเวอร์ที่อยู่ภายใต้การควบคุมของพวกเขา

ทราฟฟิกประเภทนี้ แม้จะน่ารำคาญ แต่โดยปกติแล้วสามารถตรวจจับได้โดยใช้ WAF, กฎ IDS/IPS, การตรวจสอบแพ็กเก็ตเชิงลึก หรือ CSP ที่ปรับแต่งมาอย่างดี แต่เมื่อจู่ๆ JavaScript ปรากฏขึ้นมาพยายามส่งข้อมูลบัตรไปยังโดเมนแปลกๆ ผ่าน HTTP สัญญาณเตือนภัยก็จะดังขึ้น ปัญหาคือ มัลแวร์ขโมยข้อมูลบัตรตัวใหม่นี้ตัดสินใจเปลี่ยนช่องทางการสื่อสารไปโดยสิ้นเชิง

แทนที่จะใช้ HTTP หรือ WebSockets มัลแวร์จะสร้างRTCPeerConnectionเพื่อสร้าง WebRTC DataChannelระหว่างเบราว์เซอร์ของเหยื่อและโครงสร้างพื้นฐานของผู้โจมตี ข้อมูลจะถูกส่งเป็นดาตาแกรมผ่าน UDP และเข้ารหัสด้วย DTLS (Datagram TLS) สำหรับเครื่องมือรักษาความปลอดภัยหลายๆ ตัว ข้อมูลนี้ก็แทบจะไม่ต่างอะไรจากสัญญาณรบกวนในเครือข่ายที่เข้ารหัสไว้ ซึ่งยากต่อการตีความหรือกรองโดยเฉพาะ

ด้วยวิธีนี้ โปรแกรมดักข้อมูลบัตรสามารถรับเพย์โหลดที่เป็นอันตรายผ่านช่องทาง WebRTC ได้โดยตรง (จึงหลีกเลี่ยงการโหลดสคริปต์ที่น่าสงสัยผ่าน HTTP) และส่งข้อมูลบัตรที่ดักจับได้ระหว่างการชำระเงินผ่านช่องทางเดียวกันได้ทั้งหมด โดยไม่ก่อให้เกิดร่องรอยการรับส่งข้อมูลเว็บตามปกติที่นักวิเคราะห์จะมองหาเมื่อตรวจสอบบันทึกเซิร์ฟเวอร์ พร็อกซี หรือไฟร์วอลล์

เปรียบเทียบได้กับการเฝ้าดูประตูหน้าบ้านด้วยกล้องวงจรปิดและสัญญาณเตือนภัย ในขณะที่ผู้บุกรุกเข้าและออกอย่างใจเย็นผ่านทางหน้าต่างด้านข้าง ระบบรักษาความปลอดภัยที่เน้นเฉพาะการรับส่งข้อมูล HTTP/HTTPS นั้นขาดความสามารถในการมองเห็นการเชื่อมต่อแบบเข้ารหัสจุดต่อจุดเหล่านี้อย่างแท้จริงเว้นแต่จะมีการใช้งานเครื่องมือวิเคราะห์ WebRTC เฉพาะทางหรือระบบตรวจสอบพฤติกรรมเบราว์เซอร์

นโยบายความปลอดภัยของเนื้อหา (Content Security Policy): ปกป้องอะไรบ้าง และมีข้อจำกัดอะไรบ้างเมื่อใช้กับ WebRTC

นโยบายความปลอดภัยของเนื้อหา (Content Security Policy หรือ CSP)ได้กลายเป็นองค์ประกอบสำคัญในการรักษาความปลอดภัยของเว็บแอปพลิเคชันสมัยใหม่ โดยหลักแล้ว CSP ช่วยให้คุณกำหนดจากฝั่งเซิร์ฟเวอร์ได้ว่าเบราว์เซอร์สามารถเชื่อมต่อกับโดเมนใดได้บ้าง และทรัพยากรใดบ้าง (สคริปต์ รูปภาพ ฟอนต์ ฯลฯ) ที่ได้รับอนุญาต

คำสั่งต่างๆ เช่นconnect-src, script-src และ img-srcช่วยจำกัดการร้องขอขาออกและการโหลดโค้ดจากแหล่งที่ไม่น่าเชื่อถือ เมื่อใช้งานอย่างถูกต้อง CSP จะช่วยลดผลกระทบจากการโจมตีด้วยการแทรกสคริปต์และการขโมยข้อมูลผ่าน HTTP หรือ WebSockets ได้อย่างมาก โดยมีเงื่อนไขว่าต้องกำหนดค่าอย่างเข้มงวดและไม่มีการใช้สัญลักษณ์ตัวแทนมากเกินไป

จุดอ่อนสำคัญเกิดขึ้นเมื่อมีการใช้งาน WebRTC มาตรฐานปัจจุบันขาดคำสั่ง CSP ที่ได้รับการยอมรับอย่างกว้างขวางในการควบคุม RTCPeerConnectionและ DataChannels ในทางปฏิบัติ แม้ว่าจะมีผู้กำหนดนโยบายที่เข้มงวดมากสำหรับการเชื่อมต่อ HTTP แล้วก็ตาม โค้ดที่เป็นอันตรายก็ยังสามารถสร้างการเชื่อมต่อแบบ peer-to-peer กับเซิร์ฟเวอร์ของผู้โจมตีและส่งข้อมูลที่เข้ารหัสผ่านการเชื่อมต่อดังกล่าวได้

Chrome มีคำสั่ง CSP ที่อยู่ระหว่างการทดลองซึ่งมุ่งเป้าไปที่ WebRTC แต่การใช้งานยังคงมีจำกัดและไม่ได้เป็นส่วนหนึ่งของมาตรการรักษาความปลอดภัยมาตรฐานสำหรับเว็บไซต์ส่วนใหญ่ นี่จึงเป็นช่องโหว่ที่ชัดเจน: การรักษาความปลอดภัยที่อาศัย CSP เพียงอย่างเดียวให้ความรู้สึกปลอดภัยที่ผิดพลาด ซึ่งไม่สะท้อนความเป็นจริงเมื่อสคริปต์สามารถสร้างการเชื่อมต่อ WebRTC โดยตรงได้

กล่าวโดยสรุป ร้านค้าออนไลน์จำนวนมากที่เชื่อว่าตนมีนโยบายที่ "รัดกุม" เพราะบล็อกโดเมนภายนอกทั้งหมด ยกเว้นโดเมนที่อนุญาตไว้เพียงไม่กี่โดเมน ก็ยังคงปล่อยให้ข้อมูลของลูกค้าตกอยู่ในความเสี่ยงจากมิจฉาชีพประเภทนี้ที่ทำงานผ่านช่องทางที่ไม่ครอบคลุมโดยกฎเกณฑ์ปกติ

มัลแวร์ใช้ประโยชน์จาก CSP nonce ในการปลอมตัวได้อย่างไร

นักพัฒนาบางรายก้าวไปอีกขั้นโดยใช้ค่า nonce ในส่วนหัวของ CSPวิธีนี้เกี่ยวข้องกับการกำหนดค่าสุ่ม (nonce) ให้กับการโหลดแต่ละหน้า และเพิ่มค่า nonce นั้นลงในนโยบาย CSP และสคริปต์ที่ถูกต้องในเอกสาร เพื่อให้เฉพาะสคริปต์ที่มีค่า nonce นั้นเท่านั้นที่จะถูกเรียกใช้งาน

ตามทฤษฎีแล้ว วิธีนี้ทำให้ผู้โจมตีแทรกสคริปต์ภายนอกเข้าไปในหน้าเว็บได้ยาก เนื่องจากสคริปต์ดังกล่าวจะไม่มีค่า nonce ที่ถูกต้อง และเบราว์เซอร์จะบล็อกมัน อย่างไรก็ตาม เครื่องมือขโมยข้อมูล WebRTC ที่ถูกค้นพบได้แสดงให้เห็นว่า ค่าnonce นี้สามารถถูกขโมยหรือนำกลับมาใช้ใหม่ได้จากภายในเบราว์เซอร์เอง

มัลแวร์จะวิเคราะห์โค้ดของหน้าเว็บ ค้นหาสคริปต์ที่ถูกต้องซึ่งมีค่า nonce อยู่ และคัดลอกค่า nonce นั้นไปใช้ในบล็อกโค้ดของตนเอง ด้วยวิธีนี้ สคริปต์ที่เป็นอันตรายจะแสดงตัวต่อเบราว์เซอร์ด้วย "ข้อมูลประจำตัว" เดียวกันกับสคริปต์ที่ได้รับอนุญาต

เมื่อเกิดเหตุการณ์เช่นนี้ เครื่องมือตรวจสอบและนโยบายของเว็บไซต์เองจะไม่สามารถแยกแยะระหว่างโค้ดที่ถูกต้องและโค้ดที่ถูกแทรกเข้ามาได้เนื่องจากทั้งสองอย่างดูเหมือนจะตรงตามข้อกำหนดด้านความปลอดภัยเดียวกัน เมื่อผ่านการกรองนี้ไปแล้ว โปรแกรมดักข้อมูลก็เพียงแค่เริ่มต้นใช้งาน RTCPeerConnection เปิด DataChannel และเริ่มแลกเปลี่ยนข้อมูลที่เข้ารหัสโดยไม่ก่อให้เกิดความสงสัยใดๆ

ปัญหาสำคัญคือ โซลูชันด้านความปลอดภัยเครือข่ายส่วนใหญ่เน้นการตรวจสอบ HTTP และอย่างมากก็ WebSockets เท่านั้น แต่โปรแกรมดักข้อมูลนี้ข้ามขั้นตอนเหล่านั้นไปโดยสิ้นเชิง ส่งผลให้ไม่มีคำขอ HTTP ที่ผิดปกติอย่างชัดเจนซึ่งจะบ่งชี้ถึงการโจรกรรมทำให้การรับมือกับเหตุการณ์และการตรวจสอบทางนิติวิทยาศาสตร์ในภายหลังมีความซับซ้อนมากขึ้น

PolyShell ใน Magento และ Adobe Commerce: ประตูสู่ตลาดที่สมบูรณ์แบบ

การตั้งค่าทั้งหมดนี้จะไม่เกิดประโยชน์มากนักหากผู้โจมตีไม่มีวิธีที่มีประสิทธิภาพในการแทรกโค้ดของตนเข้าไปในร้านค้า นั่นคือจุดที่PolyShell เข้ามา มีบทบาท ซึ่งเป็นช่องโหว่ที่สำคัญใน Magento Open Source และ Adobe Commerceที่กลายเป็นจุดเข้าหลักสำหรับเครื่องมือดักจับข้อมูล WebRTC นี้

PolyShell อนุญาตให้ผู้โจมตีที่ไม่ได้รับอนุญาตอัปโหลดไฟล์ที่อาจเรียกใช้งานได้ไปยังพาธเซิร์ฟเวอร์ที่ระบุ โดยเฉพาะอย่างยิ่งหากการกำหนดค่าไดเร็กทอรีสื่อไม่ได้รับการรักษาความปลอดภัยอย่างเหมาะสม จากการอัปโหลดนี้ ผู้โจมตีสามารถติดตั้งเว็บเชลล์ แบ็กดอร์ และสคริปต์ทุกประเภทที่ออกแบบมาเพื่อเรียกใช้โค้ดตามอำเภอใจได้

สัญญาณแรกของการโจมตีอย่างแพร่หลายเริ่มขึ้นเมื่อวันที่ 19 มีนาคม 2026เมื่อตรวจพบการสแกนอัตโนมัติจำนวนมากจากที่อยู่ IP มากกว่า 50 แห่ง การสแกนเหล่านี้มุ่งเป้าไปที่ระบบ Magento และ Adobe Commerce ที่มีช่องโหว่ PolyShell โดยเฉพาะ

ข้อมูลที่รวบรวมโดยนักวิจัยบ่งชี้ว่าร้านค้าที่ระบุว่ามีความเสี่ยงประมาณ 56,7%ถูกโจมตีอย่างรวดเร็วมาก เปอร์เซ็นต์ที่สูงมากนี้แสดงให้เห็นถึงขอบเขตที่ผู้โจมตีใช้ช่องโหว่โดยอัตโนมัติและเปลี่ยนให้เป็นการปฏิบัติการขนาดใหญ่

เมื่อการเรียกใช้โค้ดสำเร็จแล้ว อาชญากรจะแทรกสคริปต์ขโมยข้อมูลบัตรเข้าไปในระบบชำระเงิน ทำให้โค้ดทำงานโดยอัตโนมัติเมื่อลูกค้าป้อนข้อมูลการชำระเงิน จากนั้น การเก็บรวบรวมและดึงข้อมูลบัตรผ่าน WebRTC จะยังคงทำงานต่อไปจนกว่าจะตรวจพบการละเมิดและระบบได้รับการทำความสะอาดอย่างสมบูรณ์

วิวัฒนาการของ Magecart และก้าวสำคัญสู่ WebRTC

เป็นเวลาหลายปีแล้วที่กลุ่มแฮ็กเกอร์และแคมเปญต่างๆ ที่มุ่งเป้าไปที่การขโมยข้อมูลการชำระเงินจากร้านค้าออนไลน์ถูกจัดกลุ่มไว้ภายใต้ ชื่อMagecartนี่ไม่ใช่กลุ่มเดียว แต่เป็นหมวดหมู่ของกลยุทธ์และเครื่องมือที่พัฒนาควบคู่ไปกับมาตรการรักษาความปลอดภัยของอุตสาหกรรมนี้

ในยุคแรก ๆ โปรแกรมดักข้อมูลบัตรเครดิตจะส่งคำขอ HTTP ไปยังโดเมนที่ผู้โจมตีควบคุมอยู่หากบริษัทติดตั้ง WAF หรือตรวจสอบบันทึกการเข้าถึง รูปแบบเหล่านี้ก็สามารถระบุได้ค่อนข้างง่าย ซึ่งกระตุ้นให้เหล่าอาชญากรแสวงหาทางเลือกที่แนบเนียนกว่าเดิม

จากนั้นก็มีเทคโนโลยีอิมเมจบีคอน เกิดขึ้น โดยข้อมูลที่ถูกขโมยจะถูกฝังไว้ในพารามิเตอร์การอัปโหลดภาพที่ดูเหมือนไม่มีพิษภัย (เช่น ไฟล์ GIF) แม้ว่าเทคนิคนี้จะแนบเนียนกว่า แต่ก็สามารถตรวจจับได้ด้วยกฎที่เหมาะสมและการวิเคราะห์การรับส่งข้อมูลขาออก

ต่อมา กลุ่มบางกลุ่มเริ่มใช้WebSockets เพื่อรักษาช่องทางการสื่อสารอย่างต่อเนื่องระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ควบคุมและสั่งการ วิธีนี้ทำให้การตรวจจับด้วยเครื่องมือที่เน้นการรับส่งข้อมูล HTTP แบบดั้งเดิมมีความซับซ้อนยิ่งขึ้น แม้ว่าจะยังคงมองเห็นได้สำหรับผู้ที่ตรวจสอบส่วนหัวและปลายทางของการเชื่อมต่อเหล่านั้นก็ตาม

การเปลี่ยนมาใช้ WebRTC DataChannels ในปัจจุบันนั้น แท้จริงแล้วเป็นการตอบสนองที่สมเหตุสมผลต่อการแข่งขันด้านเทคโนโลยีนี้โดยการใช้มาตรฐานที่ออกแบบมาสำหรับการโทรผ่านวิดีโอ การแชท หรือการสตรีมแบบเรียลไทม์ ผู้โจมตีสามารถพรางตัวอยู่เบื้องหลังการไหลของข้อมูลที่เข้ารหัสและกระจายศูนย์ ซึ่งไม่ได้รับการตรวจสอบอย่างเข้มงวดในสภาพแวดล้อมขององค์กรเสมอไป

เครื่องอ่านข้อมูลแบบดั้งเดิมเทียบกับเครื่องอ่านข้อมูลแบบ WebRTC

เมื่อเปรียบเทียบเครื่องมือดักข้อมูลบัตรเครดิตแบบคลาสสิกกับวิธีการ WebRTC แบบใหม่นี้ ความแตกต่างหลักอย่างหนึ่งคือช่องทางที่ใช้ในการดึงข้อมูลแบบแรกใช้ HTTP/HTTPS หรือ WebSockets ในขณะที่แบบหลังใช้ UDP ที่เข้ารหัสด้วย DTLS ผ่าน DataChannels

ความแตกต่างที่สำคัญอีกประการหนึ่งเกี่ยวข้องกับความสามารถในการมองเห็นของเครื่องมือรักษาความปลอดภัยโดยปกติแล้วไฟร์วอลล์แอปพลิเคชันเว็บ (WAF) รีเวิร์สพร็อกซี หรือแม้แต่ระบบตรวจจับการบุกรุกเครือข่าย มักจะมีความสามารถในการแยกแยะและบันทึกการรับส่งข้อมูล HTTP ที่เป็นอันตรายได้ดี แต่ไม่สามารถตรวจสอบเนื้อหาของช่อง WebRTC ที่เข้ารหัสได้

ความแตกต่างที่สำคัญประการที่สามอยู่ที่บทบาทของ CSP ในสถานการณ์แบบดั้งเดิม นโยบายความปลอดภัยของเนื้อหาที่ออกแบบมาอย่างดีสามารถบล็อกการไหลของข้อมูลที่ผิดกฎหมายได้มากมายโดยการจำกัดการเชื่อมต่อกับโดเมนที่ไม่รู้จัก อย่างไรก็ตาม ในกรณีของ WebRTC นั้นCSP มาตรฐานไม่ได้ควบคุมการสร้าง RTCPeerConnectionsทำให้ผู้โจรกรรมข้อมูลสามารถหลีกเลี่ยงอุปสรรคนี้ได้ง่ายดาย

สุดท้ายนี้ ยังมีประเด็นเรื่องความพร้อมด้านการป้องกัน: ทีมรักษาความปลอดภัยและผู้ให้บริการโซลูชันได้ใช้เวลาหลายปีในการปรับปรุงลายเซ็น กฎ และกลไกในการตรวจจับการรับส่งข้อมูล HTTP ที่ผิดปกติ แต่ความเชี่ยวชาญในระดับเดียวกันในการรับมือกับการใช้ WebRTC ในทางที่ผิดในสภาพแวดล้อมอีคอมเมิร์ซยังคงขาดอยู่ ความไม่สมดุลของเวลาในปัจจุบันจึงเอื้อประโยชน์ให้กับผู้โจมตี

มาตรการป้องกันการสแกนข้อมูลด้วย WebRTC

จากสถานการณ์เช่นนี้ หลายคนอาจคิดว่าแทบจะทำอะไรไม่ได้เลย แต่ความจริงแล้วไม่ใช่เช่นนั้นเสมอไป มีหลายขั้นตอนที่เมื่อนำมารวมกันแล้ว จะช่วยลดโอกาสที่อุปกรณ์ดักข้อมูลประเภทนี้จะถูกติดตั้งและซ่อนตัวอยู่ในร้านค้าออนไลน์ของคุณได้อย่างมีนัยสำคัญ

1. รีบติดตั้งแพทช์ Magento และ Adobe Commerce โดยเร็วที่สุด

ขั้นตอนแรกคือการแก้ไขปัญหาที่ต้นเหตุ นั่นคือช่องโหว่ในการเข้าถึงระบบ หากธุรกิจของคุณใช้Magento Open Source หรือ Adobe Commerceจำเป็นอย่างยิ่งที่จะต้องตรวจสอบเวอร์ชันปัจจุบันและติดตั้งแพทช์ที่แก้ไขช่องโหว่ PolyShell ทันทีที่พร้อมใช้งานสำหรับสภาพแวดล้อมการใช้งานจริง

รายงานระบุว่า กว่าครึ่งหนึ่งของระบบที่มีช่องโหว่ที่ตรวจพบ—โดยเฉพาะอย่างยิ่ง56,7% ของร้านค้าออนไลน์ —ถูกโจมตีภายในระยะเวลาอันสั้น การใช้เวอร์ชันเก่าหรือการเลื่อนการอัปเดตแพทช์ออกไปนั้น เปรียบเสมือนการเล่นเกมเสี่ยงตายกับข้อมูลของลูกค้าอย่างแท้จริง

2. ตรวจสอบความถูกต้องของสคริปต์

เนื่องจากมัลแวร์ประเภท Skimmer มักถูกแทรกเข้าไปในสคริปต์การชำระเงิน วิธีป้องกันที่มีประสิทธิภาพที่สุดวิธีหนึ่งคือการติดตั้งเครื่องมือตรวจสอบความสมบูรณ์ของ JavaScriptโซลูชันต่างๆ เช่นที่ผู้ให้บริการด้านความปลอดภัยของอีคอมเมิร์ซนำเสนอ สามารถตรวจจับการเปลี่ยนแปลงโค้ดที่ไม่ได้รับอนุญาตได้

แพลตฟอร์มเหล่านี้จะเปรียบเทียบสถานะปัจจุบันของไฟล์ของคุณกับเวอร์ชันอ้างอิง และแจ้งเตือนคุณหากพบบล็อกใหม่ บล็อกที่ถูกเข้ารหัส หรือบล็อกที่ถูกเปลี่ยนเส้นทาง แม้ว่าจะไม่มีเครื่องมือใดที่สมบูรณ์แบบ แต่การตรวจสอบประเภทนี้จะช่วยลดระยะเวลาที่โปรแกรมขโมยข้อมูลสามารถทำงานได้โดยไม่ถูกตรวจพบได้อย่างมาก

3. ศึกษาการใช้งานคำสั่ง CSP ที่มุ่งเน้นไปที่ WebRTC

แม้ว่าจะยังอยู่ในช่วงทดลอง แต่เบราว์เซอร์บางตัว เช่น Chrome ก็รองรับคำสั่ง CSP เฉพาะสำหรับ WebRTCแล้ว หากกลุ่มเป้าหมายของคุณใช้เบราว์เซอร์รุ่นใหม่เป็นหลัก และคุณมีความเข้าใจในเทคโนโลยีเป็นอย่างดี การสำรวจตัวเลือกเหล่านี้อาจคุ้มค่า

อย่างไรก็ตาม การไว้วางใจในฟีเจอร์ที่ยังไม่ได้รับการกำหนดมาตรฐานหรือยังไม่ได้รับการสนับสนุนอย่างสม่ำเสมอถือเป็นเรื่องที่ไม่ฉลาด ในอุดมคติแล้ว ควรพิจารณาว่าเป็นเพียงชั้นป้องกันเพิ่มเติมไม่ใช่ชั้นป้องกันเดียว ควรใช้ร่วมกับการแก้ไขข้อบกพร่องอย่างเข้มงวด การวิเคราะห์สคริปต์ และการจัดการการพึ่งพาที่ดี

4. ตรวจสอบและลดการใช้สคริปต์จากภายนอก

สคริปต์ภายนอกทุกตัวที่คุณโหลดเข้าไปในร้านค้าของคุณล้วนเป็นจุดอ่อนที่อาจถูกโจมตีได้ วิดเจ็ตบริการลูกค้า เครื่องมือวิเคราะห์ แพลตฟอร์มโฆษณา หรือไลบรารีของบุคคลที่สาม อาจกลายเป็นช่องทางในการแทรกโค้ดที่เป็นอันตราย หากผู้ให้บริการรายใดรายหนึ่งเหล่านี้ถูกโจมตี

มาตรการที่เหมาะสมคือการตรวจสอบอย่างสม่ำเสมอ (เช่น ทุกสามเดือน) ของสคริปต์ทั้งหมดที่โหลดบนหน้าเว็บที่สำคัญ เช่น หน้าชำระเงิน และลบสคริปต์ที่ไม่จำเป็นออก การมีส่วนประกอบที่ต้องพึ่งพาน้อยลงหมายถึงพื้นที่เสี่ยงต่อการถูกโจมตีน้อยลง

5. ตรวจสอบการทำงานของแบบฟอร์มการชำระเงินแบบเรียลไทม์

นอกเหนือจากการตรวจสอบโค้ดขณะที่ไม่ได้ใช้งานแล้วการตรวจสอบว่าแบบฟอร์มการชำระเงินทำงานอย่างไรขณะรันไทม์ นั้นมีประโยชน์มาก ซึ่งรวมถึงการบันทึกว่าพยายามส่งข้อมูลไปยังโดเมนใดบ้าง มีการเปิดการเชื่อมต่อที่ไม่คาดคิดหรือไม่ หรือมีการเริ่มต้น RTCPeerConnections โดยไม่มีเหตุผลทางฟังก์ชันหรือไม่

ผู้ให้บริการเว็บโฮสติ้งและระบบรักษาความปลอดภัยบางรายมีฟีเจอร์วิเคราะห์พฤติกรรมแบบเรียลไทม์สำหรับแบบฟอร์มที่สำคัญ เมื่อตรวจพบความพยายามในการส่งข้อมูลออกไปยังโดเมนที่ไม่ได้รับอนุญาต หรือการใช้ช่องทางการสื่อสารที่ผิดปกติ ระบบสามารถยุติการใช้งานที่น่าสงสัย บล็อก IP และแจ้งเตือนทีมรักษาความปลอดภัยได้ทันที

ข้อผิดพลาดทั่วไปที่เปิดโอกาสให้เกิดความผิดพลาด

ในทางปฏิบัติ เหตุการณ์ที่เกี่ยวข้องกับอุปกรณ์ขโมยข้อมูลบัตรเครดิตประเภทนี้จำนวนมาก มักมีปัญหาที่เกิดขึ้นซ้ำๆ กันในองค์กรที่ได้รับผลกระทบ การมุ่งเน้นไปที่ปัญหาเหล่านี้จะช่วยหลีกเลี่ยงการตกอยู่ในกับดักเดียวกัน

1. การเชื่อใจผู้ให้บริการคลาวด์ (CSP) ที่เข้มงวดมากเกินไปโดยไม่ไตร่ตรอง

การตั้งค่า CSP ที่เข้มงวดเป็นความคิดที่ดี แต่ไม่ใช่ทางออกวิเศษหรือวิธีแก้ปัญหาที่สมบูรณ์แบบข้อเท็จจริงที่ว่า CSP เวอร์ชันมาตรฐานไม่ได้ควบคุม RTCPeerConnection หมายความว่าผู้โจมตียังคงสามารถดึงข้อมูลผ่าน WebRTC ได้แม้ว่าจะบล็อกการเชื่อมต่อ HTTP ที่ไม่ได้รับอนุญาตทั้งหมดแล้วก็ตาม

ดังนั้น การคิดว่า "เนื่องจากฉันมี CSP อยู่แล้ว ฉันจึงได้รับการปกป้องจากทุกสิ่งที่ผ่านเบราว์เซอร์" จึงเป็นความเข้าใจผิด หากไม่มีแนวทางแบบหลายชั้นที่รวมถึง WAF การตรวจสอบสคริปต์ การตรวจสอบบันทึก และการตรวจสอบความปลอดภัยเป็นประจำ นโยบายเนื้อหาเพียงอย่างเดียวจะไม่สามารถรับมือกับเทคนิคต่างๆ เช่นที่เรากำลังพูดถึงได้

2. การชะลอการแก้ไขช่องโหว่ที่ทราบแล้ว

อีกหนึ่งข้อผิดพลาดที่พบบ่อยคือการไม่อัปเดตอย่างรวดเร็วเมื่อพบช่องโหว่ร้ายแรงที่มีการโจมตีสาธารณะ PolyShell เป็นตัวอย่างที่ชัดเจนว่าช่องโหว่ที่รู้จักกันดีและมีข้อมูลโดยละเอียดนั้นถูกโจมตีอย่างแพร่หลายได้อย่างไร เมื่อองค์กรตอบสนองช้า

เมื่อช่องโหว่ถูกระบุไว้ในแคตตาล็อก เช่น ช่องโหว่ที่ถูกใช้ประโยชน์แล้ว (KEV) ของ CISA ลำดับความสำคัญในการแก้ไขควรเพิ่มสูงขึ้นอย่างมาก การรักษาสภาพแวดล้อมการผลิตไว้บนเวอร์ชันที่ล้าสมัยหรือไม่ทำการแก้ไขด่วนในกรณีเหล่านี้ ถือเป็นการยอมรับความเสี่ยงที่สูงมากโดยรู้ตัว

3. การพึ่งพาการตรวจสอบเครือข่ายเพียงอย่างเดียว

โครงสร้างพื้นฐานหลายแห่งมีระบบที่มีประสิทธิภาพสูงสำหรับการตรวจสอบการรับส่งข้อมูล HTTP, HTTPS และ TCPแต่มีความสามารถในการตรวจสอบการสื่อสารที่เข้ารหัสแบบ UDP น้อยมาก เช่นที่ใช้โดย WebRTC สิ่งนี้ทำให้เกิดความรู้สึกว่าควบคุมสถานการณ์ได้ผิดพลาด: แดชบอร์ดแสดงทุกอย่างเป็นสีเขียว ในขณะที่ผู้ลักลอบขโมยข้อมูลยังคงสื่อสารผ่านช่องทางอื่นได้อย่างสบายใจ

วิธีแก้ปัญหานี้เกี่ยวข้องกับการเสริมการตรวจสอบเครือข่ายแบบดั้งเดิมด้วยการตรวจสอบความสมบูรณ์ของโค้ดและการวิเคราะห์พฤติกรรมฝั่งไคลเอ็นต์กล่าวอีกนัยหนึ่ง จำเป็นต้องตรวจสอบไม่เพียงแต่สิ่งที่ถูกส่งผ่านเครือข่ายเท่านั้น แต่ยังต้องตรวจสอบด้วยว่าโค้ด JavaScript ที่ทำงานในเบราว์เซอร์กำลังทำอะไรและมีปฏิสัมพันธ์กับ API ต่างๆ เช่น WebRTC อย่างไร

สิ่งที่เรารู้แน่ชัดและสิ่งที่เรายังไม่ทราบแน่ชัดคืออะไร

ข้อมูลที่เปิดเผยต่อสาธารณะเกี่ยวกับเครื่องมือขโมยข้อมูลบัตรเครดิตและแคมเปญที่เกี่ยวข้อง ช่วยให้เราสามารถแยกแยะระหว่างข้อเท็จจริงที่ได้รับการยืนยันแล้วและแง่มุมต่างๆ ที่ยังคงอยู่ในพื้นที่สีเทาของการคาดเดาอย่างสมเหตุสมผลได้

ผลการตรวจสอบที่ได้รับการยืนยันแล้ว ได้แก่ การค้นพบโปรแกรมขโมยข้อมูล WebRTC ที่ใช้งานได้จริงในร้านค้าออนไลน์ของผู้ผลิตรถยนต์รายใหญ่การเริ่มต้นการโจมตี PolyShell ในวงกว้างเมื่อวันที่ 19 มีนาคม 2026 และตัวเลขโดยประมาณ 56,7% ของร้านค้าออนไลน์ที่เสี่ยงต่อการถูกโจมตี นอกจากนี้ยังแสดงให้เห็นว่า WebRTC DataChannels ไม่เข้าขอบเขตของคำสั่ง CSP มาตรฐานอีกด้วย

ในส่วนของข้อมูลที่ยังไม่ได้รับการยืนยัน แต่มีความเป็นไปได้ คือตัวตนของบริษัทหลักๆ ที่ได้รับผลกระทบทั้งหมดเนื่องจากยังไม่มีการเปิดเผยชื่อต่อสาธารณะ นอกจากนี้ยังไม่ชัดเจนว่าการใช้ WebRTC เป็นช่องทางในการขโมยข้อมูลนั้นแพร่หลายมากขึ้นหรือไม่ หรือว่าในขณะนี้จำกัดอยู่เฉพาะกลุ่มที่มีความสามารถทางเทคนิคสูงเท่านั้น

ในทำนองเดียวกัน รายละเอียดปลีกย่อยของการโจมตี โมดูลเสริมที่มัลแวร์นี้อาจมี และระดับการบูรณาการกับส่วนประกอบอื่นๆ ในห่วงโซ่การโจมตี ยังไม่เป็นที่เข้าใจอย่างถ่องแท้ เป็นที่คาดการณ์ได้ว่าผู้ให้บริการโซลูชันด้านความปลอดภัย เช่น ผู้ที่เชี่ยวชาญด้าน WordPress หรือ Magento กำลังทำงานเพื่อปรับปรุงเครื่องมือตรวจจับของตนสำหรับรูปแบบเฉพาะนี้

คำถามที่พบบ่อยเกี่ยวกับ WebRTC e-commerce skimmers

การเกิดขึ้นของภัยคุกคามประเภทนี้ก่อให้เกิดคำถามมากมายในหมู่ผู้ดูแลร้านค้าออนไลน์และผู้เชี่ยวชาญด้านความปลอดภัย คำถามบางข้อถูกถามซ้ำแล้วซ้ำอีก ดังนั้นจึงควรตอบคำถามเหล่านั้นโดยตรง

ฉันจะรู้ได้อย่างไรว่าร้านค้าของฉันติดตั้งอุปกรณ์ดักข้อมูลบัตรเครดิตหรือไม่?

แนวทางที่มีประสิทธิภาพที่สุดคือการใช้เครื่องมือที่สามารถสแกนโค้ดของเว็บไซต์ของคุณเพื่อหารูปแบบที่น่าสงสัย สคริปต์ที่ซ่อนเร้น การอ้างอิงถึงโดเมนที่เป็นอันตราย หรือการเปลี่ยนแปลงที่ไม่ได้รับอนุญาตในกระบวนการชำระเงิน

หากผู้ให้บริการโฮสติ้งของคุณมีบริการรักษาความปลอดภัยแบบครบวงจร ควรทำการสแกนแบบเต็มรูปแบบโดยเร็วที่สุด ในกรณีของ PolyShell โดยเฉพาะ คุณควรตรวจสอบให้แน่ใจว่า Magento หรือ Adobe Commerce ของคุณได้รับการอัปเดตด้วยแพตช์ที่แก้ไขช่องโหว่แล้ว และตรวจสอบไดเร็กทอรีสื่อของคุณเพื่อหาไฟล์ที่ผิดปกติหรือไฟล์ที่ไม่ควรมีอยู่

ทำไม WebRTC ถึงถูกนำไปใช้ในทางที่ผิดได้ ทั้งๆ ที่มันเป็นมาตรฐานที่ถูกต้องตามกฎหมาย?

WebRTC ถูกออกแบบมาเพื่อเปิดใช้งานการสื่อสารแบบเรียลไทม์ระหว่างเบราว์เซอร์เช่น การโทรผ่านวิดีโอ การแชร์หน้าจอ การสนทนาด้วยเสียง และการถ่ายโอนไฟล์ ปัญหาคือ ช่องทางการสื่อสารที่มีความยืดหยุ่นเพียงพอใดๆ ก็สามารถนำไปใช้ในวัตถุประสงค์ที่ไม่ได้ตั้งใจไว้แต่แรกได้เช่นกัน

ในกรณีนี้ มาตรฐานไม่ได้รวมกลไกการบูรณาการที่แข็งแกร่งกับ CSP ไว้โดยค่าเริ่มต้น ทำให้เกิดช่องโหว่ด้านความปลอดภัยที่ผู้โจมตีใช้ประโยชน์ นี่ไม่ใช่ข้อบกพร่องเฉพาะเจาะจง แต่เป็นข้อจำกัดด้านการออกแบบและการขาดการควบคุมเสริมในแอปพลิเคชันเว็บจำนวนมากที่ใช้—หรือไม่ได้ใช้—WebRTC

ระบบตรวจสอบเครือข่ายแบบดั้งเดิมสามารถตรวจจับการโจมตีนี้ได้หรือไม่?

ด้วยเครื่องมือแบบดั้งเดิมการตรวจจับเนื้อหาของการสื่อสาร WebRTC นั้นไม่ใช่เรื่องง่ายเนื่องจากข้อมูลจะถูกส่งผ่านการเข้ารหัส DTLS บนโปรโตคอล UDP WAF ที่ตรวจสอบเฉพาะ HTTP/HTTPS จะไม่เห็นการเปลี่ยนแปลงที่เกิดขึ้นบนการ์ดเครือข่าย เช่นเดียวกับไฟร์วอลล์แบบดั้งเดิมที่แทบจะไม่สามารถตรวจจับการรับส่งข้อมูล UDP ที่เข้ารหัสได้หากไม่มีบริบทเพิ่มเติม

เพื่อให้มีตัวเลือกการตรวจจับที่แท้จริง จำเป็นต้องผสานรวมการวิเคราะห์ความสมบูรณ์ของโค้ด JavaScript กฎพฤติกรรมที่ระบุการใช้งาน RTCPeerConnection ที่น่าสงสัย และในบางกรณี โซลูชันการตรวจสอบการรับส่งข้อมูลที่เข้ารหัสขั้นสูง ซึ่งอย่างน้อยที่สุดจะช่วยให้สามารถใช้กฎตามรูปแบบการเชื่อมต่อ ปลายทาง และปริมาณได้

ปัญหานี้เกิดขึ้นเฉพาะกับ Magento หรือส่งผลกระทบต่อ WordPress และ CMS อื่นๆ ด้วยหรือไม่?

ช่องโหว่ที่ถูกเปิดเผยต่อสาธารณะนั้นมีความเชื่อมโยงอย่างใกล้ชิดกับPolyShell ใน Magento และ Adobe Commerceแต่เทคนิคการดึงข้อมูลผ่าน WebRTC นั้นไม่ได้จำกัดอยู่เฉพาะแพลตฟอร์มเหล่านี้เท่านั้น ระบบใดๆ ที่อนุญาตให้มีการแทรกสคริปต์ในหน้าชำระเงิน—รวมถึง WordPress ที่ใช้ WooCommerce หรือแพลตฟอร์ม CMS อื่นๆ—อาจเสี่ยงต่อการโจมตีแบบเดียวกันหากมีการใช้ช่องโหว่อื่น

กล่าวอีกนัยหนึ่ง สิ่งที่เฉพาะเจาะจงในกรณีนี้คือการใช้ PolyShell เพื่อเข้าถึงระบบ แต่การใช้ WebRTC DataChannels เป็นช่องทางในการขโมยข้อมูลนั้นสามารถนำไปใช้ได้ในทุกสภาพแวดล้อมที่สามารถเรียกใช้โค้ด JavaScript ในเบราว์เซอร์ของลูกค้าในระหว่างกระบวนการชำระเงินได้

จากที่กล่าวมาข้างต้น เห็นได้ชัดว่ากลยุทธ์การขโมยข้อมูลบัตรเครดิตในอีคอมเมิร์ซได้ก้าวหน้าไปอย่างมาก โดยใช้ WebRTC เป็นช่องทางในการขโมยข้อมูล โดยใช้ประโยชน์จากช่องโหว่ที่สำคัญ เช่น PolyShell และช่องโหว่ในมาตรฐานต่างๆ เช่น CSP องค์กรที่บริหารจัดการร้านค้าออนไลน์ไม่สามารถตรวจสอบการรับส่งข้อมูล HTTP และพึ่งพาการป้องกันเพียงชั้นเดียวได้อีกต่อไป พวกเขาต้องแก้ไขช่องโหว่อย่างรวดเร็ว ลดพื้นที่การโจมตี ตรวจสอบความสมบูรณ์ของสคริปต์ และให้ความสนใจกับพฤติกรรมที่แท้จริงของโค้ดในเบราว์เซอร์ หากพวกเขาไม่ต้องการให้ข้อมูลการชำระเงินของลูกค้าถูกรั่วไหลผ่าน "หน้าต่างด้านข้าง" ที่แทบไม่มีใครให้ความสนใจมาก่อนจนถึงตอนนี้