https://virgool.io/feed/@mousavinasr همونطور که یاد می گیرم می نویسم، ساده. fa 2026-06-17 02:40:20 https://files.virgool.io/upload/users/53740/avatar/tyZRQi.png?height=120&width=120 https://virgool.io/@mousavinasr https://virgool.io/@mousavinasr/%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%AD%D8%A7%D9%81%D8%B8%D9%87-%D8%A8%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-volatility-gv61vwe7pu7g تحلیل حافظه که تو این نوشته، منظورم Memory Forensics هست، یکی از پیشرفته ترین و سخت ترین قسمت های تحلیل امنیت و فارنسیکه چون واقعاْ نیاز به دانش های متفاوت از جمله امنیت، شبکه و ساختار سیستم و حافظه داره. تو این نوشته تصمیم گرفتم یه مقدار در مورد تحلیل حافظه و ابزار خیلی قوی و جالب Volatility بنویسم. البته که این تحلیل خیلی مقدماتیه و تحلیل های خیلی پیشرفته تری میشه باهاش انجام داد.تحلیل حافظه چیه؟واسه اینکه بفهمیم چه اتفاقاتی برای یه سیستم آلوده به بدافزار در یک زمان خاص افتاده، یا واسه پیدا کردن یک سری ادله امنیتی و بررسی یه سری وقایع خاص که خیلی وقتا لاگی ازشون نمونده و خیلی موارد دیگه نیازه تا روی حافظه موقت (Volatile) تحلیل صورت بگیره تا ببنیم چیا توش هست. در کل حافظه، خیلی چیز جالبیه، می شه توش چیزایی پیدا کرد که هیچ جای دیگه نمیشه پیدا کرد.ابزار Volatility چیه؟یه فریم ورک متن باز جالب که واسه تحلیل حافظه نوشته شده. این ابزار را با استفاده از پایتون نوشتن و کلی ماژول خیلی خوب واسه کارای تحلیل حافظه داره.این ابزار را می تونید از لینک زیر دانلود کنید. https://github.com/volatilityfoundation/volatility واسه اینکه باهاش کار کنید خودش یه سری image هم واسه نمونه گذاشته که ما هم تو این نوشته از یکیشون به اسم Cridex استفاده می کنیم و تحلیل حافظه انجام میدیم.این نمونه ها را میشه از اینجا دانلود کرد. https://github.com/volatilityfoundation/volatility/wiki/Memory-Samplesتحلیل بدافزار Cridexاولین کاری که با یه image توی تحلیل باید انجام بدیم اینه که ببینیم مربوط به چه سیستمیه و اطلاعات کلی ازش بدست بیاریم.ابزار Volatility یه پلاگین به اسم imageinfo داره که میشه باهاش این اطلاعات را در آورد. با f- هم بهش میگیم از چه dumpی این اطلاعات را میخوایمvolatility -f cridex.vmem imageinfoبعد از اجرای دستور بالا نتیجه اش اینطوری میشهimageinfoاز نتیجه بالا معلوم شد که سیستم یه WinXPSP2x86 است. خب حالا می تونیم از پروفایل سیستم عامل مربوط به این سیستم استفاده کنیم و شروع کنیم به تحلیل اون سیستم. واسه این کار از Profile=WinXPSP2x86-- استفاده کنیم و بهش بگیم که سیستم عاملش WinXPSP2x86 حالا بریم سراغ اینکه ببینیم چه پراسس هایی اون موقعی که از دامپ (dump) گرفتن داشتن اجرا میشدن. واسه این کار میشه از پلاگین pslist استفاده کرد.volatility -f cridex.vmem --profile=WinXPSP2x86 pslistنتیجه اجرای دستور بالا اینطوری میشهاجرای pslistالبته بجای pslist میشه از pstree هم استفاده کرد. که نتیجه اش اینطوری میشهنتیجه pstreeتو لیست بالا یه پراسس به اسم reader_sl.exe هست که یه مقدار عجیب به نظر میرسه. PPID اش هم ۱۴۸۴ که همون PID مربوط explorer.exe است. قبل از اینکه بریم سراغ تحلیل عمیق تر این دو تا پراسس میشه از پلاگین خیلی مفید psxview هم استفاده کرد. این پلاگین لیست پراسس هایی که حین اجرا مخفی شدن را هم نشون میده.اجرای psxviewخب با توجه به اینکه دو تا ستون pslist و psscan مقدار False نداریم، این نشون میده پراسس مخفی نداریم.برگردیم به تحلیل قبلیمون. بعد از اینکه پراسس های در حال اجرا را دیدیم، خوبه که بریم سراغ کانکشن های در حال اجرا و سوکت های باز روی اون سیستم. واسه این کار میشه از سه تا پلاگین زیر استفاده کردconnscannetscansocketsپلاگین connscan یه اسکنر که واسه نمایش کانکشن های TCP استفاده می شه. بعد اجراش روی image نتیجه اش اینطوری میشه:اجرای connscanپلاگین sockets واسه نمایش سوکت های باز استفاده می شه. بعد اجراش روی image نتیجه اش اینطوری میشه:اجرای socketپلاگین netscan هم که توی این مثال نمیشه استفاده اش کرد برای نمایش کانکشن ها و سوکت های باز سیستم عامل های vista و بعد از اون استفاده میشهبا یه نگاه به خروجی پلاگین connscan میشه فهمید، ۲ تا کانکشن از نوع TCP هست که از پراسس شماره ۱۴۸۴ داره ازشون استفاده می کنه که خب این PID متعلق به explorer.exe است. از بین این دوتا کانکشن یکیشون هنوز بازه. چطور فهمیدیم؟ از خروجی پلاگین sockets. اونی که روی پورت ۱۰۳۸ است هنوز توی لیست sockets هست و با ۴۱.۱۶۸.۵.۱۴۰ روی پورت ۸۰۸۰ ارتباط می زنه.واسه اینکه بفهمیم اون موقع چه دستوراتی زده شده میشه از سه تا پلاگین زیر استفاده کرد.cmdscanconsolescmdlineدوتا پلاگین اول یعنی cmdscan که تاریخچه دستورات زده شده را از طریق اسکن کردن واسه _COMMAND_HISTORY میکشه بیرون و consoles که همین کار را با اسکن کردن واسه _CONSOLE_INFORMATION می کنه خروجی نشون نداشتن. ولی cmdline که آرگومان های خط فرمان پراسس ها رو نشون میده، خروجی زیر را نشون داد.خروجی cmdlineالان مسیر کامل پراسس هایی که از طریق پراسس های ۱۴۸۴ و ۱۶۴۰ اجرا شدن را داریم. ۱۶۴۰ هم مربوط به همون reader_sl.exe است. توی خروجی cmdline وقتی نگاه می کنیم (مسیرش را ببینید) میبینیم این پراسس که بوسیله explorer.exe ران شده بوده، قرار بوده یه adobe reader ساده باشه ولی الان داره به بیرون کانکشن میزنه و یه سری کارا می کنه.از اونجایی که این پراسس داره مشکوک میزنه بهتره ازش یه خروجی اجرایی (exe) بگیریم و بعد بریم واسه تحلیل بیشترش با استفاده از پلاگین های procdump و memdump .خروجی procdumpبا p- شماره پراسس (PID) و با dump-dir-- هم مسیر خروجی را بهش میدیم. با پلاگین procdump خروجی exe را میگیریم با memdump هم یه دامپ قابل آدرس دهی از مموری میگیره خروجی memdumpو بعدش میشه با دستور strings شروع به تحلیل این دامپ و بررسی ارتباطش با پراسس شماره ۱۴۶۰. خروجی Stringsتو این خروجی قشنگ میشه دید که این پراسس داره با متد POST یه سری دیتا به ۴۱.۱۶۸.۵.۱۴۰ میفرسته که این یعنی احتمالاْ داره Data Exfilteration انجام میده.بیشتر که این فایل دامپ را بررسی می کنیم و میریم پایین تر به یه سری دیتاهای جالب می رسیم.خروجی Stringsبا این داده هایی که از خروجی Strings گرفتیم معلوم شد با لیستی از دامین های بانک ها توش هست که خب بیشتر به این مشکوک میشیم که یه بدافزار باشه. واسه مطمئن تر شدن، میتونیم فایل exe که خروجی گرفتیم را به یه سری sandbox مثل virustotal و HybridAnalysis بدیم ببینیم نتیجه اش چی میشه. البته میشه آنالیز Static هم کرد و دید پشت فایل exe چه کدهایی هست ولی فعلاْ همون راه sandbox را میریم.خروجی VirusTotalخروجی HybridAnalysisخروجی HybridAnalysisاز خروجی های بالا هم مشخص شد که این فایل به عنوان به تروجان توی این Sandbox ها شناخته شد. بنابراین با توجه به این خروجی ها و تحلیل های بالا، سیستمی که این image از حافظه اش گرفته شده آلوده به بدافزاره. البته بیشتر از این هم میشه تحلیل کرد و IOC برای این بدافزار و عملکردش درآورد که برای مراکز عملیات امنیت و SIEM ها بسیار مفید باشه.منبع:https://medium.com/@zemelusa/first-steps-to-volatile-memory-analysis-dcbd4d2d56a1 Mohammad Reza Mousavinasr Mohammad Reza Mousavinasr Fri, 03 Apr 2020 20:18:48 +0430 https://virgool.io/@mousavinasr/%D8%B4%DA%A9%D8%A7%D8%B1-%D8%AA%D9%87%D8%AF%DB%8C%D8%AF-%D8%AF%D9%88%D8%B1-%D8%B2%D8%AF%D9%86-%D9%BE%D8%A7%D9%88%D8%B1%D8%B4%D9%90%D9%84-power-shell-hwnlfrxtqfpz توانایی دور زدن کنترل های پاورشِل یه مقوله مهم در دنیای امنیت به حساب میاد. این اتفاق می تونه یک تهدید جدی برای سیستم باشه، چون از این طریق کاربر می تونه کارها و خرابکارهای مختلفی روی سیستم انجام بده. این دست اتفاقات را می توان با یک سری تنظیمات و فعال کردن یک سری بخش ها در سیستم های ویندوزی و در نهایت با پیگیری یک سری Event ID مثل Event ID 4688 در اکثر مواقع پیدا و از اونها جلوگیری کرد.نکات شناساییدر اینگونه تهدیدات در نظر گرفتن ۲ اتفاق می تونه بسیار کمک کننده باشه:اول: Execution Policy Bypassسیاست های اجرایی که تنظیم می شوند می تونه توسط هرکسی که قصد خرابکاری داشته باشه دور بخوره. واسه چک کردن این اتفاق می تونیم روی موارد ذیل توی لاگ هامون تمرکز کنیم:ExecutionPolicy bypass and/orEp bypass or –Exec bypassExecutionPolicy unrestrictedدوم: Profile Bypassپروفایلی که برای تنظیم پاور شل ست شده تا وقتی که هر نشست (session) لانچ شد اونو کنترل کنه هم قابل دور خوردن هست. برای این قسمت هم می تونیم روی مورد ذیل توی لاگ هامون تمرکز کنیم:noprofile or -nopدستوراتدستورات زیر معمولاْ توی این نوع رخدادهای خرابکارانه هست که می تونه توی فرم های مختلف باشه:powershell.exe -executionpolicy bypass –noprofile –windowstyle hidden –file malicious.ps1powershell.exe -NonInteractive -WindowStyle Hidden -Ep bypass –nop –File “malicious.ps1"powershell.exe –e ZQBjAGgAbwAgACcAWQBvAHUAIABhAHIAZQAgAHAAdwBuAGUAZAAhACcA == (encoded)شکار تهدید با Splunkدر ادامه چندتا ایده برای شکار رفتار مشکوک پاور شل از لاگ ها با استفاده از اسپلانک که یک ابزار بسیار معروف و قوی توی تحلیل امنیتی و شکار تهدید به شمار میاد آورده شده. البته درسته که این مثال ها برای اسپلانک زده شده اما می توان با گرفتن ایده و منطق این مثال ها توی بقیه سیستم های مدیریت لاگ هم اونها را پیاده سازی کرد.Security Log (4688) - Look for ‘Execution Policy bypass’ and ‘No Profile’ executions.تو این قسمت ایده اینه که دنبال دور خوردن (bypass) های اجرایی باشیم. البته می تونه بهم ریخته یا همون obfuscate شده باشه که باز هم می شه با یه سری odd character و ticks پیداشون کرد:index=windows source=&quotWinEventLog:Security&quot (EventCode=4688) (powershell* AND -executionpolicy) OR (powershell* AND -ep) OR (powershell* AND bypass) OR (powershell* AND -noprofile) OR (powershell* AND -nop) NOT (“*\\some_expected_thing*”) | eval Message=split(Message,&quot.&quot) | eval Short_Message=mvindex(Message,0) | table _time, host, Account_Name, Process_Command_Line, New_Process_Name, New_Process_ID, Creator_Process_ID, Short_MessageSecurity Log (4688) - Look for Execution Policy bypass and No Profile executions – less noisyاین هم مثل بالایی عمل می کنه با این تفاوت که یه سری از اسم های بالایی حذف شدن و خب موارد تابلوتر را پیدا می کنه:index=windows source=&quotWinEventLog:Security&quot (EventCode=4688) (powershell* AND -ep) OR (powershell* AND -nop) NOT (“*\\some_expected_thing*”) | eval Message=split(Message,&quot.&quot) | eval Short_Message=mvindex(Message,0) | table _time, host, Account_Name, Process_Command_Line, New_Process_Name, New_Process_ID, Creator_Process_ID, Short_MessagePowerShell Operational Log (4100) - Look for Execution Policy bypass and No Profile executions – less noisyتوی این مثال تقریباْ کار قبلی را با استفاده از Event ID 4100 انجام میدیم:index=powershell source=&quotWinEventLog:Microsoft-Windows-PowerShell/Operational&quot (EventCode=4100) (-ep AND bypass) OR (-exp AND bypass) OR (-exec AND bypass) OR (&quot-nop&quot) NOT (*something_normal*) | table host, ComputerName, User, Host_Version, PS_Version, Host_Application PowerShell Operational Log (4104) PS v4-5- Look for PowerShell modules greater than 1000 characters.ایده این مثال برای وقتی که یکسری ماژول برای فیلتر کردن ماژول هایی که می دونیم درست کار می کنند فعال می شوند :index=powershell source=&quotWinEventLog:Microsoft-Windows-PowerShell/Operational&quot EventCode=4104 NOT (&quot*Program Files\\SplunkUniversalForwarder\\etc\\apps*&quot OR &quot*SplunkUniversalForwarder\\bin\\splunk-powershell-common.ps1*&quot OR &quot*var\\log\\splunk\\splunk-powershell*&quot ) | eval Cmd_Length=len(Message) | where Cmd_Length > 1000 | table _time, host, Cmd_Length, MessageSecurity Log (4688) - Look for PowerShell using a large amount of odd characters (ticks ‘ and Percent %)ایده این مثال برای وقتیه که از تیک یا یه سری کاراکتر خاص استفاده می شه. این کاراکترها معمولاْ توی obfuscate مورد استفاده قرار می گیرند.index=windows LogName=&quotSecurity&quot EventCode=4688 NOT (&quot*some_expected_thing*&quot) | eval Orig_Command=Process_Command_Line | eval Clean_Command_Line = Process_Command_Line | eval Obfuscations=Process_Command_Line | rex field = Obfuscations mode = sed &quots/[a-zA-Z0-9]//g&quot | rex field=Clean_Command_Line mode=sed &quots/[']//g&quot | eval Tick_Count = mvcount(split(Obfuscations,&quot'&quot))-1 | eval Pct_Count = mvcount(split(Obfuscations,&quot%&quot))-1 | table _time host, Orig_Command, Clean_Command_Line, Obfuscations, Tick_Count, Pct_Count | where Tick_Count > 2Windows PowerShell Log (400) PS v2-5 - Look for PowerShell using a large amount of odd characters (e.g. ticks‘ and Percent %)ایده این مثال هم برای وقتیه که از تیک یا یه سری کاراکتر خاص استفاده می شه. همونطور که توی قبلی گفتم این کاراکترها معمولاْ توی obfuscate مورد استفاده قرار می گیرند. توی این مثال این کار را با Event ID 400 انجام میدیم:index=powershell LogName=&quotWindows Powershell&quot EventCode=400 (Net.WebClient) | eval MessageA=split(Message,&quotDetails:&quot) | Eval Short_Message=mvindex(MessageA,1) | eval Clean_Host_Application=Host_Application | eval Obfuscations=Host_Application | rex field=Obfuscations mode=sed &quots/[a-zA-Z0-9]//g&quot | rex field=Clean_Host_Application mode=sed &quots/[']//g&quot | eval Tick_Count = mvcount(split(Obfuscations,&quot'&quot))-1 | eval Pct_Count = mvcount(split(Obfuscations,&quot%&quot))-1 | table _time, host, ComputerName, Host_Application, Clean_Host_Application, Obfuscations, Tick_Count, Pct_Count | where Tick_Count > 2البته لازم به ذکر که نسخه های مختلف پاورشل مثل ۱، ۲ و ۳ با ۴ و ۵ یه مقداری متفاوت هستند و یه نکته دیگه اینکه برای این که بتونیم لاگ های این اتفاقاتی که برای پاورشل (Powershell) می افته را درست و درمون بگیریم یه سری تنظیمات نیازه که توی پست بعدی (که انشاالله تو همین نزدیکیا باشه، نریم واسه شیش ماه دیگه) به اونها هم اشاره می کنم. Mohammad Reza Mousavinasr Mohammad Reza Mousavinasr Sat, 21 Mar 2020 04:46:45 +0430 https://virgool.io/@mousavinasr/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-ssrf-%DB%8C%D8%A7-%D9%87%D9%85%D9%88%D9%86-exploit-%DA%A9%D8%B1%D8%AF%D9%86%D8%B4-fhbzby9sneqc بعد از اینکه فهمیدیم SSRF چیه و چطوری میشه پیداش کرد، بریم ببینم چکارا میشه باهاش کرد و چطوری میشه اکسپلویتش کرد.خب اول بگم اینکه چه کارایی میشه باهاش کرد واقعاً به این ربط داره که چه سرویس‌هایی روی شبکه پیدا می کنید. هرچی بیشتر باشن، دست و بالتون بازترهسوال: SSRF پیدا کردم، بعدش چی؟حالا وقتشه که اکسپلویتش کنیم. از این باگ میشه واسه کارای زیر استفاده کرد:اسکن شبکه واسه پیدا کردن هاست هاپورت اسکن سیستم های داخل شبکه و پیدا کردن سرویس های داخلیجمع کردن دیتاهای مفید که بعضی جاها بهشون میگن meta dataدور زدن کنترل دسترسی ها یا همون access controlپیدا کردن داده های مهمو حتی اجرا کردن کد روی سیستم هابریم سراغ اولیاسکن کردن شبکهاولین کاری که با SSRF میشه کرد اینه که بفهمیم چه سیستم های دیگه ای روی شبکه هستند. خب چطوری این کارو انجام بدیم؟ میایم یکسری رنج IP به اون سیستمی که میدونیم آسیب پذیره میدیم که درخواست بده، بعد جواب های دریافتی را بررسی می کنیم ببینم چی گفته. مثلاً یه درخواست اینطوری می فرستیم.https://public.example.com/upload_profile_from_url.php?url=10.0.0.1سرور اینطوری جواب میدهError: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2یه درخواست دیگه این بار واسه یه IP دیگه میدیم. مثلاًhttps://public.example.com/upload_profile_from_url.php?url=10.0.0.2سرور این بار اینطوری جواب میده:Error: cannot upload image: Connection Failedاز این جوابا راحت میتونیم بفهمیم که 10.0.0.1 یه سیستم valid توی شبکه است ولی 10.0.0.2 نیست.اسکن پورت و پیدا کردن سرویس هااز SSRF میشه واسه اسکن پورت های سیستم های توی شبکه و درآوردن سرویس های اونها هم استفاده کرد. پورت های باز نشون های خوبی واسه سرویس های در حال اجرا روی سیستم اند و همونطور که میدونید سرویس ها پورت های پیش فرضی دارن که روی اونها اجرا میشن و خب از طریق اسکن پورت ها می تونیم بفهمیم چه سرویس هایی دارن اجرا میشن و از اونها واسه کارای خودمون کمک بگیریم. چطوری میشه این کارو کرد؟ دقیقاً مثل همون کاری که واسه پیدا کردن سیستم های مختلف روی شبکه کردیم (همون اسکن شبکه) فقط با این تفاوت که اینجا شماره پورت ها را عوض می کنیم و جواب برگشتی از سرور را بررسی می کنیم.مثلاً یه درخواست روی پورت 80 یه سرور داخلی می فرستیم و به طور مثال سرور اینطوری جواب میده :Error: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2حالا پورت را عوض می کنیم و میذاریم 11. سرور اینطوری جواب میده:Error: cannot upload image: Connection Failedبازم مثل حالت قبلی اینجا هم معلومه که پورت 80 بازه ولی پورت 11 روی این سرور بسته است.آمازون و API های Metadataآمازون یه سرویسی داره به اسم Amazon EC2 که به بیزنس ها این امکان را میده که برنامه های خودشون را روی public cloud اجرا کنند. یه سرویسی داره داخل خودش به اسم “Instance Metadata”. این سرویس به نمونه های EC2 این امکان را میده که به API ای دسترسی پیدا کنند که اطلاعاتی در مورد خود نمونه (instance) یه سری اطلاعات بهشون میده (روی آدرس 169.254.169.254). حالا یه نمونه مشابه از این API روی Google Cloud هم وجود داره. این API ها به صورت پیش فرض واسه هرکسی قابل دسترسی اند مگر اینکه به صورت مشخص توسط مدیر شبکه بلاک شده باشند یا از غیرقابل دسترس شده باشند. اطلاعاتی که این سرویس ها لو میدن، بعضی وقتا خیلی حساسه و میتونه کاری کنه که با SSRF لو برن و حتی منجر به RCE بشه.اگر یه شرکت زیرساخت خودش را روی Amzon EC2 هاست کرده باشه، میشه با استفاده از endpoint ها از طریق آدرس زیر، کلی نمونه metadata در مورد هاست بدست آورد.http://169.254.169.254/latest/meta-data/Endpoint ها (سیستم های نهایی :/ ) اطلاعات مختلفی مثل API Keyها، AWS S3 توکن ها و پسوردها را می تونن لو بدن. چند از مفیدترین ها که همون اول باید برید سراغشون اینان:http://169.254.169.254/latest/meta-data/این لینک لیست metadata های موجود که میشه queryشون کرد را بر می گردونhttp://169.254.169.254/latest/meta-data/local-hostname/این لینک hostname های داخلی که توسط host استفاده شدن را برمی گردونهhttp://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAMEاعتبارات امنیتی یا همون security credential اون نقش ها را برمی گردونهhttp://169.254.169.254/latest/dynamic/instance-identity/documentPrivate IP نمونه فعلی را برمی گردونهhttp://169.254.169.254/latest/user-data/داده های کاربر را روی نمونه فعلی برمی گردونهتوی این لینک https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html میتونید دایکیومنت کاملشون که Amazon درست کرده را ببینید.گوگل - Google Cloud Metadataاگر شرکت واسه کارش از Google Cloud استفاده کرده باشه، میشه Metadata های API نمونه Google را بدست بیارید. گوگل یه سری معیارهای امنیتی اضافه واسه API هاش پیاده سازی کرده. واسه همین یه سری چیزها واسه بدست آورده دیتاها نیاز هست. مثلاً واسه Query کردن Metadata ی APIv1 گوگل نیاز به هدر خاصی داره:“Metadata-Flavor: Google” or “X-Google-Metadata-Request: True”اما خب این مکانیسم امنیتی خیلی راحت قابل دورزدنه چون که اکثر endpoint هایی که از طریق APIv1 قابل دسترسی اند از طریق APIv1beta1 هم قابل دسترسی اند و خب واسه APIv1beta1 این هدر نیاز نیست. بعضی از مفیدترین هاشون که همون اول باید رفت سراغشون عبارتند از:http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/tokenکه توکن دسترسی (access token) اکانت پیش فرض روی نمونه را برمی گردونه.http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keyکلید عمومی های عمومی SSH که میتونه با اون به بقیه نمونه های در این پروژه متصل بشه را برمی گردونه.آمازون و گوگل تنها وب سرویس هایی نیستند که API های metadata را در اختیار میذارن ولی خب مسلماً بزرگترین شرکت هایی هستن که این سرویس را ارائه میدن و خب خیلی از شرکت ها ممکنه روی این پلتفرم ها رفته باشند.از اون چیزایی که تا الان بدست آوردیم استفاده کنیم.حالا بعد از اینکه شبکه را اسکن کردیم و فهمیدیم چه سرویس هایی دارن اجرا میشن و metadata های درست و درمون پیدا کردیم باید بریم سراغ اصلی ترین کارها:دور زدن کنترل دسترسی ها:بعضی از سرویس های داخلی ممکنه کنترل دسترسیشون فقط بر مبنای IP یا هدرهای سیستم های داخلی باشه و خب اگر بتونیم از طریق یه سیستم داخلی که trust هم هست درخواست هامون را بدیم این احتمال وجود داره که به یه سری امکانات خاص و حساس دسترسی پیدا کنیم.لو رفتن اطلاعات حساس و مورد اعتماداگر بتونیم با استفاده از SSRF اعتبارات (credential) را پیدا کنیم، میتونیم از این credential ها استفاده کنیم و به اطلاعات محافظت شده ای روی شبکه برسیم. به طور مثال اگر تونستیم کلیدهای AWS S3 پیدا کنیم میشه چک کردکه به S3 bucket های خصوصی شرکت هم دسترسی داریم یا نه. (اینو خودمم تست نکردم هنوز چون نمیدونستم چیه :)) )اجرا کردن کد:میشه از این اطلاعاتی که تا الان بدست اومده استفاده کرد و SSRF را تبدیل به RCE کرد. به طور مثال، اگر credential های admin را که می تونه سطح دسترسی بالاتری بهمون بده را پیدا کنیم، اونوقت شاید بشه حتی shell آپلود کنیم. یا مثلا اگر پنل غیرامن ادمین را پیدا کردیم میشه چک کرد دید اجازه اجرای اسکریپ میده یا نه؟ و حتی بهتر شاید بشه با root لاگین کرد.نوع Blindشون (Blind SSRF)همونطور که قبلاً گفتم Blind SSRF نوعی از SSRF هان که توشون شما جواب یا error message از طرف سرور دریافت نمی کنید.ادامه ... Mohammad Reza Mousavinasr Mohammad Reza Mousavinasr Fri, 26 Jul 2019 18:14:15 +0430 https://virgool.io/@mousavinasr/%D9%85%D9%82%D8%AF%D9%85%D9%87%D8%A7%DB%8C-%D8%A8%D8%B1-ssrf-eucoqkmjjqzh سلام، SSRF یکی از باگ‌هایی است که این روزها یقه خیلی از سایت های بزرگ را می گیره. هرچند جدید نیست ولی خب هست دیگه. مشکل از اونجا نشأت می گیره که کنترل منابع خارجی که سایت از اونها استفاده می کنه خوب انجام نمیشه. در ادامه یکم در مورد این باگ، نحوه پیدا کردنش و اینکه چطوری میشه از طریق اون به داخل شبکه Pivot شد، می نویسم.چیه این SSRF ؟این SSRF مخفف Server Side Request Forgery هست و به نفوذگر اجازه ارسال درخواست های با امضاهای جعلی به سمت یه سرور آسیب پذیر میده و خب چون اون سرور آسیب پذیره این درخواست ها معتبر شناخته میشن و به عنوان یه نود معتبر توی شبکه معرفی میشه. از این طریق کنترل های فایروال دور خورده و نفوذگر به سرویس های داخل شبکه دست پیدا می کنه.تصور کنید یه وب سرور عمومی توی شبکه یه شرکت به آدرس زیر هست:public.example.comاین آدرس یه سرویس پراکسی را توی public.example.com/proxy هاست می کنه که صفحات وبی که در پارامتر url مشخص شدند را پردازش و به کاربر نمایش میده. تصور کنید کاربر درخواست زیر را میدهhttps://public.example.com/proxy?url=google.comاون وب اپلیکشن، صفحه گوگل را نمایش میدهحالا تصور کنید admin_panel.example.com یه سرور داخلیه که یه پنل مخفی ادمین را هاست می کنه. واسه اینکه مطمئن بشن فقط کارمندا می تونن به این صفحه دسترسی داشته باشند، Access control طوری تنظیم شده که از بیرون و عملاً اینترنت کسی به اون دسترسی نداشته باشه و فقط کسایی به اون دسترسی پیدا کنن که یه IP معتبر داخلی داشته باشن (مثلاً یکی از workstation های کارمندا). حالا اگه یه کاربر تقاضای زیر را بده چی میشه؟https://public.example.com/proxy?url=admin_panel.example.comاگر مکانسیم کنترل SSRF نداشته باشند، خب چون درخواست از Public.examaple.com میاد و یک ماشین معتبر داخل شبکه هست، صفحه کنترل پنل ادمین به کاربر نمایش داده میشه. درواقع درخواست های نامعتبر که در حالت عادی توسط فایروال بلاک می شدند، الان دارن اجرا می شن! این به این دلیل که اون محافظتی که روی شبکه DMZ یا همون Perimeter برای کنترل بین سرورهایی مثل وب سرور و ماشین های داخلیمون ست شده، بین ماشین های روی شبکه Trusted مون (مثلاً بین public.example.com و admin_panel.example.com ) وجود نداره. حالا با استفاده از این وضعیت، یه نفوذگر می تونه هر نوع درخواست که دلش بخواد را روی شبکه ارسال کنه و بسته به اینکه اون سروره چه دسترسی‌هایی داره، یه نفوذگر می تونه فایل‌های حساس داخل شبکه را بخونه یا مثلاً API های داخلی را صدا بزنه و یا مثل این حالتی که توضیح دادم به کنترل پنل های مخفی مدیرا دست پیدا کنه.جالب شد، نه؟!خب 2 نوع SSRF داریم: به اولی میگن Regular SSRF یا همون SSRF معمولی و دومی هم مثل خیلی از باگ های دیگه Blind SSRF. مکانیسم‌های پشت هردوی این نوع آسیب‌پذیری یه چیزه و عملاً اعتماد بین ماشین های روی یک شبکه را مورد هدف قرار میدن و exploit می کنن. تنها تفاوتی که بین این دوتا هست اینه که توی Blind نفوذگر بازخوردی از سمت سرور به وسیله درخواست های HTTP یا error message ها دریافت نمی کنه (مثل اون بالا که نفوذگر صفحه وب درخواستیش را می دید). هرچند این موضوع کمی استخراج داده‌ها و exploit کردن شبکه را سخت تر می کنه اما با این حال خیلی برای یک نفوذگر با ارزشه. چطوری SSRF پیدا کنیم؟بهترین راه پیدا کردن این نوع آسیب پذیری‌ها اینه که به صورت دستی code review کنیم و ببینیم تمامی ورودی های URL درست و درمون اعتبارسنجی میشن یا نه؟ ولی خب مشخصه که همیشه نمیتونیم این کار را کنیم و دسترسی کامل به کد نداریم، بنابراین باید تمرکز را گذاشت روی ویژگی هایی که قیافه‌اشون به SSRF می خوره.همونطور که گفتم، SSRF وقتی اتفاق می افته که یه سرور به منابع خارجی نیاز داشته باشه. به طور مثال، بعضی وقتا یک وب اپلیکشن نیاز داره تا از روی URL یه عکس، thumbnail (همون عکس کوچولوها) درست کنه یا مثلاً نیاز داره تا از روی یه ویدیوئه سایت دیگه یه Screen shot داشته باشه (مثلاً youtube.com یا aparat.com). اگر سرور دسترسی به منابع داخلیشو درست محدود نکرده باشه، SSRF اتفاق می افته.فک کنیم صفحه زیر که روی public.example.com هست به کاربرا اجازه بده تا عکسشونو از طریق اینترنت آپلود کنند https://public.example.com/upload_profile_from_url.php?url=www.google.com/test.jpegواسه اینکه بخواد test.jpeg را پردازش کنه اول باید بره سراغ محتویات google.com و اونها را بخونه. اگر سرور تفاوتی بین منابع داخلی و خارجیش قائل نشده باشه، یه نفوذگر به راحتی می تونه درخواست زیر را بده: https://public.example.com/upload_profile_from_url.php?url=localhost/password_file.txtو خب همونطور که از اسم فایله معلومه می تونه کاری کنه که وب سرور فایل محتویات پسوردها را بهش نشون بده.ویژگی هایی که معمولاً نسبت به SSRF آسیب‌پذیر هستند عبارتند از: webhook ها، فایل آپلودها بوسیله URL، پردازشگرهای اسناد و تصاویر، link expansion ها و سرویس های پراکسی! در واقع همه این ویژگی ها نیاز دارن تا منابع خارجی را دیده و پردازش کنن. تست کردن SSRF معمولاً با آماده کردن ورودی URL با یه آدرس داخلی شروع میشه. حالا بسته به config شبکه ممکنه نیاز باشه چندین سرور مختلف تست بشن. مثلاً آدرس های زیر همون اول تست میشن: 127.0.0.0/8192.168.0.0/1610.0.0.0/8یا مثلا میشه از این لینک بقیه آدرس‌ها استفاده کرد. توی مواقع SSRF عادی بررسی کنید ببینید سرور اطلاعاتی را به شما برمی گردونه که اطلاعاتی از شبکه داخلی را نمایش بده؟ اون پاسخه که میگیرید حاوی بنر سرویس‌های داخلی یا محتویات HTML یه صفحه داخلی هست یا نه؟برای مثال وقتی درخواست زیر را میدیم https://public.example.com/upload_profile_from_url.php?url=127.0.0.1:22سرور این جواب را میده؟ Error: cannot upload image: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4توی مواقعی که Blind SSRF تست می کنیم، بررسی کنید ببینید تفاوتی بین رفتار سرور به پورت های معمول باز و بسته هست یا نه؟ (مثلاً پورت 80 و 443 معمولاً بازن درحالی که 11 بسته است). خصوصاً به Response Time و HTTP Response Code ها دقت کنید.به طور مثال، نتیجه درخواست زیر یه Status Code 200 هست که خب میدونم 200 یعنی اوکی: https://public.example.com/webhook?url=127.0.0.1:80درحالی که Status Codeی که از درخواست زیر می گیریم 500 هست و خب 500 هم یعنی Internal Server Error: https://public.example.com/webhook?url=127.0.0.1:11وقتی این رفتار را از سرور می بینیم می تونیم بگیم که SSRF وجود داره و عملاً پورت 80 بازه و 11 بسته روی اون سرور بسته است.توی این لینک هم می تونید پورت ها و سرویس هایی که بهشون نسبت داده شدند را ببینید.مثال از هکر 1توی این لینک می تونید یه SSRF باحال که اردیبهشت 97 از Shopify گرفته شده و 25000 دلار بانتی گرفته را ببینیدhttps://hackerone.com/reports/341876بعدیتوی مقاله بعدی سعی می کنم در مورد انواع SSRF و کارهایی که میشه با اون روی یه شبکه انجام بدید، صحبت کنم. Mohammad Reza Mousavinasr Mohammad Reza Mousavinasr Fri, 21 Jun 2019 18:07:48 +0430