Thick Client Penetration Testing
การทดสอบความปลอดภัยของแอปพลิเคชันเดสก์ท็อปและ Thick Client โดยผู้เชี่ยวชาญ
แอปพลิเคชัน Thick Client (Desktop Application ที่ทำงานบนเครื่องของผู้ใช้) ยังคงเป็นองค์ประกอบสำคัญในธนาคาร โรงพยาบาล และอุตสาหกรรมการผลิต ระบบเหล่านี้มักเชื่อมต่อโดยตรงกับฐานข้อมูลและระบบ Back-end สำคัญ ทำให้เป็นเป้าหมายที่มีค่าสูงสำหรับ Hacker
การทดสอบ Thick Client ผสมผสานการวิเคราะห์ Binary แบบ Static การวิเคราะห์แอปพลิเคชันขณะทำงานแบบ Dynamic และการตรวจสอบโปรโตคอลการสื่อสารที่แอปพลิเคชันใช้คุยกับบริการ Backend สภาพแวดล้อมที่พบบ่อย ได้แก่ .NET (WPF / WinForms), Java (Swing / JavaFX), Electron, แอปพลิเคชัน Native บน Windows / macOS / Linux และ Citrix-Published Desktop
การทดสอบ Thick Client ส่วนใหญ่มักพบความเสี่ยงสองกลุ่ม ได้แก่ ช่องโหว่บนเครื่องผู้ใช้ เช่น Data-at-Rest การจัดเก็บ Credential และเส้นทาง Privilege Escalation และช่องโหว่ระดับ Protocol ในการสื่อสารระหว่างแอปพลิเคชันกับ Server เช่น การยืนยันตัวตนและการกำหนดสิทธิ์ (Authentication & Authorisation) รวมถึง Replay Protection
ความเสี่ยงที่ต้องพิจารณา
สมมติฐานฝั่งเซิร์ฟเวอร์ถูกทดสอบในรูปแบบที่แตกต่างออกไปในบริบทนี้
Thick Client ส่ง Logic ไปยังเครื่องของผู้ใช้ สิ่งใดก็ตามที่ถูกสมมติว่าเป็น "พฤติกรรมไคลเอนต์ที่เชื่อถือได้" สามารถถูกแก้ไขได้โดย Hacker ที่สามารถรันโปรแกรม Debugger ของตนเองได้
โปรโตคอลเดิมมักยังคงถูกใช้งานอยู่
Backend ของ Thick Client มักทำงานบนโปรโตคอลรุ่นเก่า เช่น TCP แบบกำหนดเอง SOAP ที่เลิกใช้งานแล้ว และ Raw Socket Frame ซึ่งมีคุณลักษณะด้านความปลอดภัยที่ไม่เคยได้รับการตรวจสอบอย่างเป็นทางการ
สิ่งที่เราทดสอบ
การควบคุมในระดับแอปพลิเคชัน
- ช่องโหว่ใน Local Storage
- ช่องโหว่ในการยืนยันตัวตน
- การ Implement Cryptography ที่ไม่เหมาะสม
- Authorization ที่ไม่ถูกต้อง (การตรวจสอบที่ Server สามารถ Bypass จาก Client ได้)
- การเปิดเผย Sensitive Data ในหน่วยความจำหรือดิสก์
Runtime, Protocol และ Build
- ช่องโหว่ในโปรโตคอลการสื่อสาร
- การสื่อสารที่ไม่ปลอดภัย
- Security Misconfiguration (การตั้งค่าที่ไม่ปลอดภัย)
- ส่วนประกอบที่มีช่องโหว่ที่ทราบ (Known Vulnerable Components)
- การเปิดเผยต่อ Reverse Engineering
- การบันทึก Log ที่ไม่เพียงพอ
- ความสมบูรณ์ของ Update / Auto-Update
ช่องโหว่ที่เรามักพบจากการทดสอบในลักษณะนี้
ข้อมูลที่นำเสนอเป็นกลุ่มช่องโหว่ที่ที่ปรึกษาของเรามักพบจากการทดสอบในลักษณะเดียวกัน ความรุนแรงและความถี่จะแตกต่างกันตามสภาพแวดล้อมและระดับความพร้อมของแต่ละองค์กร
ตรรกะที่เชื่อใจฝั่ง Client
Authorisation บังคับใช้ที่ฝั่ง Client เท่านั้น การตรวจสอบค่าหรือสิทธิ์ที่ทำใน GUI แต่ไม่ทำที่ Server และฟีเจอร์ Admin ที่ซ่อนใน UI แต่เข้าถึงได้ผ่านข้อความ Protocol โดยตรง
Credentials และ Token ในขณะจัดเก็บ
Credentials ที่ Cache ในไฟล์ Local โดยไม่มีการป้องกัน Token ใน Registry และ Credentials ที่ฝังใน Binary สำหรับ Legacy Service Account
ช่องโหว่ในโปรโตคอล
Custom Protocol ที่ไม่มีการป้องกัน Integrity, การยืนยันตัวตนที่ยอมรับการ Replay, TLS เวอร์ชันล้าสมัยที่ยังยอมรับการเชื่อมต่อบน Management Channel
ความเสี่ยงใน Update Channel
Auto-Update ผ่าน HTTP โดยไม่ตรวจสอบ Signature, Update Server เข้าถึงได้โดยไม่ต้อง Authenticate และเปิดให้เกิด Downgrade Attack ได้
แนวทางการทำงานที่มีโครงสร้างชัดเจน ขับเคลื่อนด้วยข้อมูลเชิงลึกในทุกการทดสอบ
ทุกโครงการดำเนินตามแนวทางที่มีระเบียบวินัยเดียวกันผ่านแพลตฟอร์ม Velocity เพื่อให้คุณภาพ การติดตามตรวจสอบ และการรายงานมีมาตรฐานเดียวกันในทุกทีม
การกำหนดขอบเขต
กำหนดสินทรัพย์ สภาพแวดล้อม ข้อกำหนดในการทดสอบ และเกณฑ์การยอมรับร่วมกับผู้เกี่ยวข้องด้านเทคนิคและความปลอดภัย
การดำเนินการ
การทดสอบแบบ Manual และด้วยเครื่องมือโดยที่ปรึกษาที่ได้รับการรับรอง CREST พร้อมเก็บหลักฐานในทุกขั้นตอน
การตรวจสอบความถูกต้อง
ทุกการค้นพบจะถูกทำซ้ำ ประเมินระดับความเสี่ยงด้วย CVSS และยืนยันโดยที่ปรึกษาท่านที่สองก่อนรายงานผล
การรายงาน
รายงานที่ลงนามด้วยรหัส พร้อมการอ้างอิง Test Case การจัดระดับความรุนแรง ขั้นตอนการทำซ้ำ และแนวทางแก้ไข
สรุปผลและการทดสอบซ้ำ
การประชุมสรุปผลกับผู้เกี่ยวข้อง การช่วยจัดลำดับความสำคัญ และการทดสอบซ้ำหลังการแก้ไข
อ้างอิงมาตรฐานสากลที่ได้รับการยอมรับ
คำถามจากผู้สนใจใช้บริการ
ต้องการ Source Code หรือไม่? +
มีประโยชน์แต่ไม่จำเป็นเสมอไป การทดสอบ Thick Client โดยทั่วไปสามารถดำเนินการจาก Binary เพียงอย่างเดียว ผ่านการทำ Disassembly การ Debug และการวิเคราะห์ Protocol การเข้าถึง Source Code จะช่วยให้พบช่องโหว่ในกลุ่ม Static Code ได้เร็วขึ้น
ทดสอบบริการ Backend ด้วยหรือไม่? +
โดยปกติคือใช่ เพราะการทดสอบ Client โดยไม่ทดสอบสิ่งที่ Client สื่อสารด้วยจะมีคุณค่าจำกัด การทดสอบทั้งสองส่วนพร้อมกันคือมาตรฐาน
ทดสอบการป้องกันของท่านกับผู้เชี่ยวชาญด้านการรักษาความปลอดภัยเชิงรุก
ปรึกษาที่ปรึกษาที่ได้รับการรับรอง CREST เกี่ยวกับการทดสอบ Penetration Testing ครั้งถัดไปของท่าน