สรุปสั้น

บริษัทด้านความปลอดภัย TantoSec เผยแพร่ห่วงโซ่การโจมตีที่ใช้งานได้จริงต่อช่องโหว่ใน Telerik UI for ASP.NET AJAX ซึ่งเปิดให้ผู้โจมตีที่ไม่ต้องยืนยันตัวตนรันโค้ดบนเซิร์ฟเวอร์ที่โฮสต์แอปพลิเคชันที่มีช่องโหว่ได้ ตัวช่องโหว่ไม่ใช่ของใหม่ บริษัท Progress Software ปิดไปแล้วตั้งแต่เดือนกรกฎาคมด้วยเวอร์ชัน 2026.2.708 และการโจมตีต้องอาศัยการตั้งค่าที่ไม่ใช่ค่าเริ่มต้น สิ่งที่เปลี่ยนไปในวันที่ 7 กันยายนคือวิธีการและเครื่องมือถูกเปิดเผยออกมา ทำให้เส้นทางโจมตีที่สมบูรณ์ตกอยู่ในมือสาธารณะเป็นครั้งแรก

จุดเริ่มของห่วงโซ่คือ padding oracle (CVE-2026-13182) ซึ่งเกิดจากการที่คอนโทรล RadAsyncUpload เข้ารหัสสถานะฝั่งไคลเอนต์ด้วย AES-CBC โดยไม่มีการตรวจสอบความถูกต้องของข้อมูล เซิร์ฟเวอร์จึงตอบกลับต่างกันขึ้นอยู่กับว่าข้อมูลที่ถูกดัดแปลงมี padding ถูกต้องหรือเพียงแค่แปลงเป็น JSON ไม่ได้ ความต่างนั้นทำให้ผู้โจมตีถอดรหัสและปลอมค่าการตั้งค่าอัปโหลดที่ถูกเข้ารหัสไว้ได้โดยไม่ต้องรู้กุญแจเลย จากนั้นจึงระบุชนิด .NET ตามใจชอบซึ่งคอนโทรลจะแปลงกลับโดยไม่มีบัญชีขาว (CVE-2026-13181) แล้วนำไปสู่การโหลด DLL จากตำแหน่งที่ผู้โจมตีควบคุม

เงื่อนไขที่จำกัดขอบเขตความเสียหายคือเรื่องสำคัญที่ไม่ควรมองข้าม TantoSec ระบุเองว่าห่วงโซ่นี้มี “เงื่อนไขเบื้องต้นที่การติดตั้งแบบค่าเริ่มต้นไม่เข้าข่าย” เว็บไซต์ที่รันเวอร์ชันที่มีช่องโหว่แต่ไม่ครบเงื่อนไขทั้งสองข้อจะโจมตีผ่านเส้นทางนี้ไม่ได้ และจนถึงวันที่ 7 กันยายนยังไม่มีรายงานยืนยันว่าช่องโหว่ชุดปี 2569 ถูกใช้โจมตีจริง อีกทั้งยังไม่ปรากฏในรายการ Known Exploited Vulnerabilities ของ CISA

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 7 กันยายน 2569 ว่า บริษัท TantoSec ได้เผยแพร่ห่วงโซ่การโจมตีที่ทำงานได้จริงต่อช่องโหว่ใน Telerik UI for ASP.NET AJAX ซึ่งเปิดให้ผู้โจมตีที่ไม่ต้องยืนยันตัวตนรันโค้ดระยะไกลบนเซิร์ฟเวอร์ที่โฮสต์แอปพลิเคชันที่มีช่องโหว่ได้

ตัวช่องโหว่ถูกแก้ไปก่อนหน้านี้แล้ว โดย Progress Software ปล่อยตัวแก้ในเวอร์ชัน 2026.2.708 (2026 Q2 SP1) เมื่อวันที่ 8 กรกฎาคม และเผยแพร่ CVE พร้อมประกาศแจ้งเตือนเมื่อวันที่ 22 กรกฎาคม สิ่งที่เปลี่ยนไปในวันที่ 7 กันยายนคือการเปิดเผยวิธีการและเครื่องมือ โดยนาย Marcio Almeida จาก TantoSec อธิบายห่วงโซ่ทั้งหมดอย่างละเอียด พร้อมปล่อยเครื่องมือบรรทัดคำสั่งชื่อ telerik-rau-exploit และเพย์โหลด DLL แบบ mixed-mode สองตัว ตัวหนึ่งเขียนเว็บเชลล์ลงดิสก์ และอีกตัวทำงานอยู่ในหน่วยความจำทั้งหมด

ห่วงโซ่นี้กระทบคอนโทรลอัปโหลดไฟล์ RadAsyncUpload ในเวอร์ชัน 2010.1.309 ถึง 2026.2.519 ตามประกาศของ Progress ส่วนเวอร์ชัน 2026.2.708 เป็นต้นไปได้รับการแก้ไขแล้ว โดยช่องโหว่ที่รุนแรงที่สุดในชุดคือ CVE-2026-13181 ซึ่งเป็นข้อบกพร่องเรื่องการแปลงชนิดข้อมูลโดยไม่มีการป้องกัน ได้คะแนน CVSS 8.1 ระดับสูง ทั้งนี้คะแนนความซับซ้อนในการโจมตีระดับสูงสะท้อนเงื่อนไขการตั้งค่าที่ต้องครบก่อน ไม่ได้สะท้อนความยากของการโจมตีเมื่อเงื่อนไขครบแล้ว

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

เมื่อเงื่อนไขครบ ผลลัพธ์คือการรันโค้ดด้วยสิทธิ์ของ IIS application pool โดยการโจมตีไม่ได้เกิดขึ้นในพริบตา TantoSec ระบุว่าการรันจากต้นจนจบใช้คำร้องไปยัง oracle ราว 127,000 ครั้ง คิดเป็นเวลาราวหนึ่งชั่วโมงกับเป้าหมายในห้องทดลอง และนานกว่านั้นหากเซิร์ฟเวอร์มีการจำกัดอัตราคำร้อง นอกจากนี้หากแอปพลิเคชันซ่อนข้อความแสดงข้อผิดพลาดโดยละเอียดไว้ ผู้โจมตีก็ยังอ่าน oracle ได้ผ่านเวลาที่ใช้ตอบกลับ ซึ่งเป็นรูปแบบที่ถูกติดตามในชื่อ CVE-2026-13183

ในเรื่องการถูกโจมตีจริง ยังไม่มีรายงานยืนยันว่าช่องโหว่ชุดปี 2569 ถูกใช้โจมตีในโลกจริง และไม่มีตัวใดปรากฏในรายการ Known Exploited Vulnerabilities ของ CISA ณ วันที่ 7 กันยายน ขณะที่ผู้ให้บริการบริหารพื้นผิวการโจมตีรายหนึ่งคือ IONIX ระบุบนเว็บไซต์ของตัวเองว่ากำลัง “ติดตามความพยายามโจมตีที่ดำเนินอยู่” แต่ไม่ได้ให้วันที่ ปริมาณ หรือรายละเอียดใด ๆ และไม่ได้แยกแยะระหว่างการโจมตีจริงกับการสแกนอินเทอร์เน็ตตามปกติที่ยิงใส่ตัวจัดการนี้

สิ่งที่ทำให้เรื่องนี้ถูกจับตาคือประวัติของคอมโพเนนต์เอง ซึ่งเคยถูกโจมตีในโลกจริงมาแล้วหลายครั้งผ่านช่องโหว่รุ่นเก่า โดยเฉพาะ CVE-2019-18935 ซึ่งเป็นช่องโหว่ deserialization ในตัวจัดการเดียวกันเมื่อปี 2562 ที่ถูกนำไปต่อกับจุดอ่อนด้านการเข้ารหัสของปี 2560 แล้วถูกใช้โดยทั้งกลุ่มแรนซัมแวร์และกลุ่มที่รัฐหนุนหลัง รวมถึงในการเจาะหน่วยงานรัฐบาลกลางสหรัฐฯ เมื่อปี 2565 และยังพบการโจมตีอยู่จนถึงปี 2568

วิธีการโจมตี

ห่วงโซ่เริ่มจาก padding oracle ที่ถูกติดตามในชื่อ CVE-2026-13182 คอนโทรล RadAsyncUpload เข้ารหัสสถานะฝั่งไคลเอนต์ด้วย AES-CBC โดยไม่มีการตรวจสอบความถูกต้องของข้อมูลกำกับ เมื่อผู้โจมตีส่งข้อมูลที่ถูกดัดแปลงเข้าไป เซิร์ฟเวอร์จะตอบกลับแตกต่างกันระหว่างกรณีที่ไบต์ที่ถอดรหัสแล้วมี padding ถูกต้อง กับกรณีที่ padding ถูกแต่แปลงเป็น JSON ไม่ได้ ความต่างเพียงเท่านี้เพียงพอให้ค่อย ๆ ถอดรหัสข้อมูลออกมาได้ทีละไบต์โดยไม่ต้องรู้กุญแจ

ขั้นถัดมาคือการปลอมข้อมูล TantoSec สร้างเทคนิคที่อาศัยค่า seed ของการเข้ารหัสที่คอนโทรลใช้แบบตายตัว ทำให้ไม่เพียงถอดรหัสได้ แต่ยังสร้างค่าการตั้งค่าอัปโหลดที่เข้ารหัสไว้ขึ้นมาใหม่เองได้ด้วย เมื่อปลอมค่าได้แล้ว ผู้โจมตีจึงระบุชื่อชนิด .NET ตามที่ต้องการลงไป ซึ่งคอนโทรลจะแปลงชนิดนั้นโดยไม่มีบัญชีขาวคอยกรอง (CVE-2026-13181) แล้ว deserialize ออกมาเป็น gadget ที่โหลด DLL จากตำแหน่งที่ผู้โจมตีกำหนด

DLL ที่ถูกอัปโหลดเป็นแอสเซมบลีแบบ mixed-mode ซึ่งรันโค้ดเนทีฟทันทีที่ถูกโหลด นั่นคือจุดที่ได้การรันโค้ดบนเซิร์ฟเวอร์ด้วยสิทธิ์ของ IIS application pool ส่วนต้นทุนของการโจมตีคือจำนวนคำร้องมหาศาลที่ต้องยิงใส่ oracle ราว 127,000 ครั้ง ซึ่งแปลว่าการโจมตีนี้ทิ้งร่องรอยไว้ในปริมาณทราฟฟิกอย่างชัดเจน แม้จะไม่ทิ้งร่องรอยในล็อกข้อผิดพลาดก็ตาม

ยังมีอีกสองประเด็นที่ช่วยกำหนดขอบเขตของเรื่องนี้ ประเด็นแรกคือประกาศของ Progress เมื่อเดือนกรกฎาคมครอบคลุมห่วงโซ่การโจมตีสองชุดที่แยกจากกัน ชุดหนึ่งคือ RadAsyncUpload ที่ TantoSec อธิบาย และอีกชุดหนึ่งเป็นห่วงโซ่รันโค้ดระยะไกลในคอมโพเนนต์ RadPersistenceManager และ RadDockLayout (CVE-2026-13185, -13186 และ -13190) ซึ่งได้เครดิตให้นาย Markus Wulftange จาก CODE WHITE ร่วมกับ Progress และยังไม่มีการปล่อยชุดโจมตีสาธารณะออกมา ประเด็นที่สองคือภายในห่วงโซ่ RadAsyncUpload เอง ยังมีช่องโหว่ตัวที่สี่เรื่องกุญแจค่าเริ่มต้นที่คาดเดาได้ (CVE-2026-13184) ซึ่งใช้ได้เฉพาะกับโหมดการโจมตีทางเลือกที่การสาธิตครั้งนี้ไม่ได้ใช้

ผลกระทบ

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

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

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

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

คำแนะนำ

อัปเกรด Telerik UI for ASP.NET AJAX เป็นเวอร์ชัน 2026.2.708 (2026 Q2 SP1) หรือใหม่กว่า ซึ่งเปลี่ยนกลไก AES-CBC ที่มีปัญหาไปใช้การเข้ารหัสแบบมีการยืนยันความถูกต้อง และปิดห่วงโซ่ทั้งชุด โดย Progress ระบุว่านี่คือคำแนะนำอย่างเป็นทางการเพียงข้อเดียว พร้อมเตือนว่าการตั้งกุญแจให้แข็งแรงขึ้นไม่ช่วย เพราะ oracle ไม่ต้องใช้กุญแจอยู่แล้ว

สำหรับเว็บไซต์ที่ยังอัปเกรดทันทีไม่ได้ Progress ระบุมาตรการชั่วคราวไว้หลายข้อ ได้แก่ ตั้งค่า customErrors เป็น RemoteOnly หรือ On เพื่อบีบให้ผู้โจมตีต้องใช้รูปแบบที่อาศัยเวลาซึ่งช้ากว่ามาก ปิดตัวจัดการอัปโหลดทั้งหมดด้วยการตั้ง Telerik.Web.DisableAsyncUploadHandler เป็น true หากไม่ได้ใช้ RadAsyncUpload และนำกุญแจเข้ารหัสเฉพาะออกเพื่อให้คอนโทรลกลับไปใช้ machine key ของ ASP.NET ที่มีทั้ง AES และ HMAC หรือสร้าง machine key ที่แข็งแรงด้วยมือแทนการสร้างตอนรันไทม์

ในด้านการตรวจจับ ให้ล่าตามพฤติกรรมแทนการมองหาข้อความผิดพลาด เพราะ Progress เตือนว่าการโจมตีที่สำเร็จ “ไม่ทิ้งร่องรอยที่สังเกตได้ในล็อกข้อผิดพลาดมาตรฐานของ ASP.NET” สิ่งที่ควรเฝ้าคือโปรเซส w3wp.exe เรียก cmd.exe ไฟล์ .aspx ใหม่หรือที่ไม่คาดคิดโผล่ในเว็บรูต และไฟล์ DLL แบบ mixed-mode ที่ถูกเขียนลงในโฟลเดอร์ชั่วคราวของคอนโทรลอัปโหลดหรือใน App_Data

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

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

แหล่งอ้างอิง