مهاجمان با سوءاستفاده از یک آسیب‌پذیری تزریق SQL در یک اپلیکیشن وب، کد جاوا را از طریق JDBC به داخل پایگاه‌داده Oracle وارد و کامپایل کرده و از طریق موتور دیتابیس فرمان‌های سیستم‌عامل را اجرا کردند تا به سطح دسترسی SYSTEM در سرور ویندوزی برسند.

شرح حمله

شرکت امنیتی Huntress پس از کشف رخدادهای سرقت اعتبار در تاریخ 27 ژوئیه 2026، زنجیرهٔ نفوذ را بررسی کرد. مهاجمان از یک فیلد تکمیل خودکار (autocomplete) در رابط وب استفاده کردند که ورودی را بدون اعتبارسنجی از طریق اتصال JDBC به دیتابیس می‌فرستاد. حسابی که اپلیکیشن با آن به دیتابیس متصل می‌شد، مجوز ایجاد اشیاء جاوا در اسکیمای دیتابیس را داشت و بدین‌صورت امکان سوءاستفاده فراهم شد.

نحوۀ سوءاستفاده

با دستور CREATE JAVA SOURCE، می‌توان کد جاوا را به دیتابیس داد تا کامپایل و به‌عنوان شیء اسکیمایی ذخیره شود. مهاجمان کلاس‌هایی ایجاد کردند که از Runtime.exec برای اجرای فرمان‌های سیستمی استفاده می‌کردند؛ نمونه‌ای که Huntress مشاهده کرد، فراخوانی cmd.exe و گزارش خروجی whoami به‌عنوان SYSTEM بود.

چرا دیتابیس نقش سکوی حمله را ایفا کرد

شی جاوا در داخل دیتابیس یک فایل اجرایی روی دیسک نیست و محصولات معمول EDR معمولاً به فضای داخلی Oracle دسترسی مستقیم ندارند. بنابراین دیتابیس به‌جای تنها منبع داده، به یک نقطهٔ اجرای کد تبدیل شد و می‌تواند مبنای ارتقاء دسترسی و حرکت جانبی در شبکه باشد.

جزئیات ابزار khunt

Huntress بستهٔ پس از بهره‌برداری را "khunt" نامیده است؛ این بسته شامل شش شیء جاوا و چند wrapper از نوع khunt_* برای PL/SQL است. اجزای کلیدی گزارش‌شده:

  • KhuntCmd — بارگذاری cmd.exe و اجرای فرمان‌های سیستم.
  • KhuntHash — خواندن نام‌های کاربری و هش‌های رمز عبور از جداول داخلی Oracle و نوشتن آن‌ها به فایل.
  • KhuntFS و KhuntFS2 — فهرست، خواندن، جستجو و اندازه‌گیری فایل‌ها.
  • KhuntT — بررسی در دسترس‌بودن ابزارها.
  • KhuntUnzip — باز کردن آرشیوها.

پس از اجرای فرمان‌ها، مهاجمان با PowerShell و reg.exe هیوهای رجیستری SYSTEM و SECURITY را به مسیر F:\Oracle کپی کردند، خروجی tasklist /svc را در فایل khunttasks.txt ذخیره نمودند و با esentutl.exe فایل‌های مربوط به SAM و SECURITY را آماده‌سازی کردند. Huntress گزارش می‌کند که این فایل‌ها محلی‌سازی شده‌اند اما تأیید خروجی‌برداری کامل آنها را ارائه نکرده است. تراکنش‌ها تا نشانی 178.162.151[.]229 ردیابی شده‌اند.

پیشینهٔ تکنیک

اجرای جاوا داخل Oracle برای انجام فرمان‌های سیستمی دست‌کم دو دهه سابقه دارد؛ نمونه‌هایی مانند raptor_oraexec.sql از سال 2006 نشان می‌دهند معماری پایه‌ای مشابه khunt قبلاً وجود داشته است. با این حال، نمونه‌های مستندسازی‌شده از کاربرد واقعی در حملات مستقیم نسبتاً نادر بودند و مورد حاضر نمونه‌ای روشن از استفادهٔ عملی این تکنیک در طبیعت است.

شاخص‌های تشخیصی و روش‌های جستجو

برای کشف وجود khunt یا موارد مشابه در Oracle، موارد زیر مفید است. توجه داشته باشید که این شاخص‌ها مختص khunt هستند و لزوماً همهٔ نمونه‌های مشابه را نشان نمی‌دهند:

  • جستجو برای اشیائی که نامشان با Khunt شروع می‌شود: Khunt*.
  • بررسی لاگ‌های SQL و Audit برای الگوهای KHUNT% یا فراخوانی CREATE JAVA SOURCE.
  • ردیابی فراخوانی‌های ساخت اشیاء جاوا و پروسیجرهای مرتبط.
  • پیگیری فعالیت‌های نوشتن فایل در مسیرهای غیرمعمول مانند F:\Oracle.
  • مسدودسازی یا مانیتور آدرس IP مهاجم 178.162.151[.]229 در فایروال و لاگ‌های وب.

نمونهٔ پرس‌وجوهای تشخیصی

  • جستجوی اشیاء مشکوک: 
    SELECT owner, object_name, object_type FROM dba_objects WHERE object_name LIKE 'KHUNT%';
  • بررسی لاگ‌های Audit برای ایجاد اشیاء جاوا: 
    SELECT username, timestamp, sql_text FROM dba_audit_trail WHERE sql_text LIKE '%CREATE JAVA SOURCE%';
  • بررسی فعالیت‌های نوشتن فایل غیرمعمول (بسته به تنظیمات سیستم و لاگ‌های میزبان): نمونهٔ جستجوی لاگ عامل یا مسیر فایل‌های خروجی.

اقدامات فوری و توصیه‌ها

دو اقدام اساسی برای کاهش ریسک: رفع نقص برنامه و محدودسازی مجوزهای حساب‌های زیرساختی. توصیه‌های عملی:

  • اصلاح اپلیکیشن: استفاده از پرس‌وجوهای پارامتری (prepared statements) و اعتبارسنجی سمت سرور برای جلوگیری از تزریق SQL.
  • اصل حداقل امتیاز: حساب JDBC اپلیکیشن نباید مجوز CREATE JAVA SOURCE یا مجوزهای اجرای پروسیجر را داشته باشد؛ دسترسی را به حداقل‌های لازم محدود کنید.
  • در صورتی که قابلیت اجرای جاوا در دیتابیس مورد نیاز نیست، آن را غیرفعال یا محدود کنید.
  • فعال‌سازی و بازبینی لاگ‌های Audit برای رویدادهای مرتبط با ایجاد و اجرای کد جاوا.
  • استقرار ابزارهای مانیتورینگ ویژهٔ دیتابیس یا راهکارهایی مانند Oracle Audit Vault برای بازرسی درون‌ساختار دیتابیس؛ چون EDRهای معمول ممکن است فعالیت داخلی دیتابیس را نادیده بگیرند.
  • بازبینی دوره‌ای دسترسی‌ها و حذف مجوزهای غیرضروری از حساب‌ها و رول‌ها.
  • برگزاری آموزش‌های امنیتی برای تیم توسعه دربارهٔ جلوگیری از ارسال ورودی‌های اعتبارسنجی‌نشده و انجام تست‌های امنیتی (SAST/DAST) پیش از انتشار.

جمع‌بندی

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

منابع: گزارش Huntress و مستندات Oracle دربارهٔ مدیریت کد جاوا در دیتابیس. برای مرجع عمومی دربارهٔ تزریق SQL به صفحهٔ ویکی‌پدیا مراجعه کنید.