Certificate Pinning บน Android Non-root — แนวทางและข้อจำกัดในการทดสอบ
Certificate pinning อาจทำให้แอปไม่ยอมรับ certificate ของ proxy แม้จะตั้งค่าการเชื่อมต่อเพื่อทดสอบแล้ว OWASP MASTG อธิบายว่าการจัดการ pinning ขึ้นกับ API, framework และ library ที่แอปใช้ เครื่องมือสำเร็จรูปจึงไม่ได้ครอบคลุมทุกแอป.[1]
บทความนี้เป็นแนวทางวางแผนทดสอบสำหรับแอปที่ได้รับอนุญาต ไม่ใช่ผลทดลองกับ APK ใดโดยเฉพาะ และไม่รับรองว่าจะใช้ได้กับทุก build หรือ Android ทุกเวอร์ชัน
Non-root ต่างจากการทดสอบบนเครื่อง Root อย่างไร
OWASP แยกกรณีอุปกรณ์ root ที่ใช้ frida-server ออกจากกรณี non-root ซึ่งอาจต้องใช้แนวทาง repackaging ตัวแอป จึงไม่ควรคัดลอกคำสั่งจากขั้นตอน rooted device แล้วคาดหวังผลเดียวกันบนเครื่อง non-root.[1]
Frida Gadget เป็น shared library ที่โหลดเข้าโปรแกรมเพื่อทำ instrumentation เมื่อ injected mode ไม่เหมาะสม การเพิ่ม Gadget จึงเป็นการเปลี่ยนแปลงตัวโปรแกรมหรือ library ไม่ใช่การติดตั้ง root ให้เครื่อง.[2]
เลือกแนวทางให้ตรงกับสิ่งที่ต้องการพิสูจน์
| แนวทาง | เหมาะกับสถานการณ์ | ข้อควรระวัง |
|---|---|---|
| ขอ test build จากทีมพัฒนา | ต้องการตรวจ API และ business logic โดยลดอุปสรรคด้านเครื่องมือ | ระบุความต่างจาก release build ในรายงาน |
| Static patch / repackage | ต้องตรวจ pinning logic ในแอปที่ได้รับอนุญาตให้แก้ไข | เก็บ diff และบันทึกว่าได้เปลี่ยน trust behavior จุดใด |
| Instrumentation ด้วย Gadget | ต้องสังเกตพฤติกรรมขณะทำงานในสภาพแวดล้อมที่ใช้ injected mode ไม่เหมาะ | ตรวจ ABI, library และการเริ่มทำงานให้ตรงกับ build |
ตารางนี้เป็นคำแนะนำในการวาง scope ของบทความ ไม่ใช่ข้อกำหนดของ OWASP การ patch แบบ static และการจัดการ custom pinning มีอธิบายใน MASTG ส่วนวิธีโหลด Gadget ให้อ้างอิงเอกสาร Frida โดยตรง.[1][2]
ขั้นตอนทำงานที่ตรวจสอบย้อนกลับได้
- ยืนยันขอบเขตและสิทธิทดสอบ — ระบุแอป, build, backend, บัญชีทดสอบ และสิทธิในการแก้ไข/ลงนาม APK
- เก็บ baseline — บันทึกพฤติกรรมของ build เดิมก่อนแก้ รวมถึง error และ flow ที่ทำให้สื่อสารไม่สำเร็จ อย่าเหมารวมทุก TLS error ว่าเป็น pinning
- ตรวจ implementation — ดูว่า trust decision อยู่ใน framework มาตรฐานหรือ native/custom library เพราะอาจต้องใช้วิธีต่างกัน ตามข้อจำกัดที่ MASTG ระบุ.[1]
- ทำการเปลี่ยนแปลงให้น้อยและบันทึก diff — Apktool รองรับการถอด resources/DEX เพื่อวิเคราะห์และประกอบ APK กลับ แต่ความสำเร็จของการ build ไม่ได้พิสูจน์ว่า runtime behavior ยังเหมือนเดิม.[3]
- ลงนามและตรวจ signature ของ APK ทดสอบ — Android Developers ระบุว่าการเปลี่ยน APK หลังลงนามทำให้ signature ใช้ไม่ได้ และหากใช้ zipalign ต้องทำก่อนลงนาม.[4]
- เปรียบเทียบผลกับ baseline — เก็บหลักฐานว่าทำ flow เดิมได้หรือไม่ เห็น request ใด และได้แก้พฤติกรรมส่วนใดของแอปไปบ้าง
สิ่งที่ไม่ควรสรุปจากการ Bypass ได้
- เห็น traffic หลังแก้ APK ไม่ได้แปลว่าแอปเดิมยอมรับ certificate ของผู้โจมตี
- ติดตั้ง APK ทดสอบไม่ได้ ไม่ได้พิสูจน์ว่า pinning แข็งแรง อาจติดข้อจำกัดด้านการลงนามหรือ packaging
- เครื่องมือสำเร็จรูปใช้ไม่ได้ ไม่ใช่ผล PASS ของการควบคุม ต้องแยกกรณีทดสอบไม่สำเร็จออกจากการยืนยันความปลอดภัย
- ตรวจ backend ผ่าน proxy ได้ ไม่ได้หมายความว่าได้ทดสอบ mobile storage, authentication และ authorization ครบแล้ว
หัวข้อนี้เป็นหลักการตีความหลักฐานของบทความ ควรระบุผลเป็น “ตรวจพบ”, “ไม่พบในขอบเขตที่ทดสอบ” หรือ “ทดสอบไม่ได้เพราะข้อจำกัด” ให้สอดคล้องกับการทดลองจริง
หลักฐานที่ควรส่งมอบ
เก็บ build identifier, hash ของไฟล์ที่ใช้, รุ่น Android, สถานะ root/non-root, diff ของการแก้ไข และลำดับการทดสอบ ปกปิด token และข้อมูลส่วนบุคคลในภาพหรือ traffic ที่แนบรายงาน หลังจบทดสอบให้นำ test build และ test certificate ออกจากอุปกรณ์ตามข้อตกลง
อ่านต่อ: การวิเคราะห์ SMALI · บริการ Mobile Application Pentest
Sources
[1] https://mas.owasp.org/MASTG/techniques/android/MASTG-TECH-0012 [2] https://frida.re/docs/gadget [3] https://apktool.org [4] https://developer.android.com/tools/apksigner