ท่ามกลางการเติบโตของ AI ในด้านความปลอดภัย ทีมงานของเราได้พัฒนา GitHub Security Lab Taskflow Agent เพื่อให้นักวิจัยสามารถสร้างระบบอัตโนมัติ จัดการชุดคำสั่ง (prompt) และแชร์เวิร์กโฟลว์ที่มีประสิทธิภาพได้อย่างง่ายดาย โดยในโพสต์นี้ ผมจะแชร์วิธีสร้าง auditing taskflows เพื่อค้นหาช่องโหว่ในแอปพลิเคชัน Android

แม้โมเดลรุ่นใหม่จะเข้าใจโค้ดได้ดีขึ้น แต่การใช้ custom taskflow prompts ช่วยให้นักวิจัยแนะนำโมเดลได้ตรงจุด โดยแบ่งการวิจัยเป็นขั้นตอนย่อยๆ ซึ่งช่วยให้ LLM ค้นหาช่องโหว่ที่ซับซ้อนได้รวดเร็วขึ้น หรือค้นพบจุดที่โมเดลอาจมองข้ามไปหากตรวจสอบเพียงผิวเผิน

จากการใช้งาน taskflows เหล่านี้ ผมได้รายงานช่องโหว่ในแอป Android ไปแล้วกว่า 20 รายการ คุณสามารถตรวจสอบรายละเอียดได้ที่ advisories page เพื่อดูข้อมูลช่องโหว่ใหม่ๆ หรืออ่านตัวอย่างช่องโหว่ที่มีผลกระทบสูงซึ่งพบโดยเครื่องมือนี้ได้ที่ด้านล่าง

วิธีรัน taskflows บนโปรเจกต์ของคุณเอง

หากคุณต้องการเริ่มใช้งานทันที taskflows เหล่านี้เป็นโอเพนซอร์สและรันได้ง่าย โดยมีข้อกำหนดว่าต้องมีสิทธิการใช้งาน GitHub Copilot และการใช้โมเดลระดับพรีเมียมอาจมีการเรียกใช้เครื่องมือบ่อยครั้ง ซึ่งส่งผลต่อการใช้โทเค็น (tokens) จำนวนมาก

1. ไปที่ที่เก็บข้อมูล seclab-taskflows และเริ่ม codespace
2. รอสักครู่เพื่อให้ระบบเริ่มต้นทำงาน
3. ใน terminal ให้รันคำสั่ง ./scripts/audit/run_mobile.sh myorg/myrepo

กระบวนการนี้อาจใช้เวลา 1-2 ชั่วโมงสำหรับที่เก็บข้อมูลขนาดกลาง เมื่อเสร็จสิ้นระบบจะเปิด SQLite viewer ให้คุณตรวจสอบตาราง “audit_results” และมองหาแถวที่มีเครื่องหมายถูกในคอลัมน์ “has_vulnerability”

การสร้าง audit taskflows ที่เจาะจงเป้าหมายสำหรับแอป Android เพื่อนร่วมงานของผม Peter และ Mo เคยเขียน blog post เกี่ยวกับ audit taskflows ของพวกเขาไว้ แม้จะใช้งานได้ดีอยู่แล้ว แต่แอป Android มีลักษณะเฉพาะที่ต้องให้ความสำคัญเป็นพิเศษ เราจึงต้องปรับจูนการทำงานเพิ่มเติม

ขั้นแรก ผมได้เพิ่ม taskflow gather_mobile_entry_point_info.yaml เพื่อคัดแยก entry points หรือจุดที่ข้อมูลจากผู้โจมตีอาจไหลเข้าสู่ระบบ โดยแยกแยะระหว่างโมบายและส่วนอื่น ช่วยให้ AI เข้าใจพื้นผิวการโจมตี (attack surface) ได้ถูกต้องแม้ในโปรเจกต์ที่มีแอปหลายประเภทผสมกัน

ขั้นต่อมา ผมได้แก้ไข classify_application_local.yaml โดยระบุรายการช่องโหว่ยอดนิยมและสั่งให้ LLM พิจารณาในบริบทของแต่ละ entry point เนื่องจากช่องโหว่บนมือถือมีความเฉพาะตัวและ LLM มีลักษณะแบบ non-deterministic เราจึงต้องกำกับให้ตรวจสอบคลาสช่องโหว่ที่จำเป็น เช่น confused deputy หรือ insecure broadcasts เมื่อพบ entry point ที่อิงตาม intent

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

สองตัวอย่างของช่องโหว่ที่พบโดย taskflows

นี่คือตัวอย่างช่องโหว่จริงที่เราพบและได้รับการเปิดเผยแล้ว จากทั้งหมด 24 รายการที่รายงานไปจนถึงปัจจุบัน

การสะกดรอยตามผู้ใช้ผ่าน OsmAnd

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

ช่องโหว่เกิดขึ้นเมื่อแอปอนุญาตให้รับ intent extras เช่น settings_version หรือ silent_import เพื่อนำเข้าการตั้งค่าโดยไม่มีการแจ้งเตือนหรือยืนยันจากผู้ใช้ เนื่องจาก Android ไม่มีกลไกจำกัดการกำหนด extras จากภายนอก แอปอันตรายจึงสามารถส่ง intent พร้อม extras เพื่อเปลี่ยนการตั้งค่าแอป OsmAnd ได้ทันที

private void handleOsmAndSettingsImport(Uri intentUri, String fileName, Bundle extras) { 
    fileName = fileName.replace(ZIP_EXT, ""); 
    if (extras != null && CollectionUtils.containsAny(extras.keySet(), 
            SETTINGS_VERSION_KEY, SETTINGS_LATEST_CHANGES_KEY)) { 
        int version = extras.getInt(SETTINGS_VERSION_KEY, -1); 
        String latestChanges = extras.getString(SETTINGS_LATEST_CHANGES_KEY); 
        boolean replace = extras.getBoolean(REPLACE_KEY);              // ← attacker-controlled 
        boolean silentImport = extras.getBoolean(SILENT_IMPORT_KEY);   // ← attacker-controlled 
        ArrayList<String> exportTypeKeys = 
            extras.getStringArrayList(EXPORT_TYPE_LIST_KEY);           // ← attacker-controlled 
        List<ExportType> exportTypes = null; 
        if (exportTypeKeys != null) {
            exportTypes = ExportType.valuesOf(exportTypeKeys); 
        } 
        handleOsmAndSettingsImport(intentUri, fileName, exportTypes, 
            replace, silentImport, latestChanges, version); 
    } else { 
        handleOsmAndSettingsImport(intentUri, fileName, 
            null, false, false, null, -1);                             // safe defaults 
    } 
}

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

# [TILE #1]  14:23:07  z=15 x=9649 y=12320 
#   ├── center: 40.70979, -73.98743 
#   └── 🗺️  https://www.openstreetmap.org/#map=15/40.70979/-73.98743

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

[ROUTE #1] 07:02:47  vehicle=car  waypoints=2 
  ├── path: /osrm/car/-122.084,37.4219983;-122.32450103759766,37.99944305419922 
  ├── 📍 ORIGIN:      37.421998, -122.084000 
  │      https://www.openstreetmap.org/#map=15/37.42200/-122.08400 
  ├── 🏁 DESTINATION: 37.999443, -122.324501 
  │      https://www.openstreetmap.org/#map=15/37.99944/-122.32450

การยึดบัญชี Wikipedia ผ่าน deeplink

ตัวอย่างที่สองคือแอป Wikipedia ซึ่งมีบั๊กในตัวประมวลผลชื่อโฮสต์ (hostname parser) ของ deeplink wikipedia:// ทำให้ผู้โจมตีสามารถโหลด URL ภายนอกที่ตนเองควบคุมได้ใน WebView ของแอป

    private fun handleIntent(intent: Intent) { 
        if (Intent.ACTION_VIEW == intent.action && intent.data != null) { 
            intent.data?.let { 
                if (it.authority.orEmpty().endsWith(WikiSite.BASE_DOMAIN)) { 
                    val uri = Uri.parse(it.toString().replace("wikipedia://", WikiSite.DEFAULT_SCHEME + "://")) 
                    startActivity(Intent(this, PageActivity::class.java) 
                            .setAction(Intent.ACTION_VIEW) 
                            .setData(uri))
                }
            }
        }
    }

นอกจากนี้ยังมีช่องโหว่ในการตรวจสอบคุกกี้ที่ยอมให้โดเมนที่ลงท้ายด้วย wikipedia.org (เช่น evil-wikipedia.org) เข้าถึงคุกกี้ได้ เมื่อรวมทั้งสองจุดเข้าด้วยกัน ผู้โจมตีสามารถสร้างลิงก์หลอกลวงเพื่อขโมย session token ของผู้ใช้ และยึดบัญชี Wikimedia ทั้งหมด (รวมถึงทุกภาษาของ Wikipedia และโครงการอื่น) ได้อย่างสมบูรณ์

LLM เก่งในการหาช่องโหว่แต่ยังมีปัญหาในการประเมินความรุนแรง

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

อีกอุปสรรคคือการมองข้ามปัจจัยบรรเทาผลกระทบ (mitigation factors) เช่น path traversal ในหน่วยความจำภายนอกที่อาจไม่มีผลรุนแรง วิธีแก้ปัจจุบันคือการสั่งให้ LLM สร้าง "การพิสูจน์แนวคิด (PoC)" หรือใช้เครื่องมือ debugger ร่วมด้วย เพื่อลดจำนวนผลบวกปลอม (false positives)

LLM กับความรู้ด้าน API ที่ยอดเยี่ยม

สิ่งที่น่าประทับใจคือ LLM มีความเข้าใจลึกซึ้งเกี่ยวกับความปลอดภัยของ API ในภาษาต่างๆ แม้จะไม่มีซอร์สโค้ดของภาษานั้นๆ เช่น การแยกแยะความปลอดภัยระหว่าง path.Clean และ filepath.Clean ในภาษา Go รายงานการพิสูจน์แนวคิดที่ AI สร้างขึ้นแทบไม่ต้องแก้ไขเลย ซึ่งสะท้อนถึงฐานข้อมูลด้านความปลอดภัยที่แข็งแกร่ง

หมายเหตุเกี่ยวกับผลลัพธ์

เราพบช่องโหว่รวม 24 จุด ซึ่งครอบคลุมตั้งแต่ path traversal ไปจนถึงระดับวิกฤตอย่าง cross app scripting ใน WebView โดยประเภทของช่องโหว่สอดคล้องกับสิ่งที่นักวิจัยคาดการณ์ไว้ในระบบนิเวศของ Android

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

บทสรุป

ความปลอดภัยควรเป็นหัวใจสำคัญของผู้ดูแลโอเพนซอร์สทุกคน และ AI จะเป็นเครื่องมือที่ขาดไม่ได้ เครื่องมือ seclab-taskflow-agent พร้อมให้คุณใช้งานและร่วมพัฒนา เพื่อก้าวสู่ยุคการรักษาความปลอดภัยที่ขับเคลื่อนด้วย AI อย่างเต็มตัวตั้งแต่วันนี้