بعد از اینکه فهمیدیم SSRF چیه و چطوری میشه پیداش کرد، بریم ببینم چکارا میشه باهاش کرد و چطوری میشه اکسپلویتش کرد.
خب اول بگم اینکه چه کارایی میشه باهاش کرد واقعاً به این ربط داره که چه سرویس‌هایی روی شبکه پیدا می کنید. هرچی بیشتر باشن، دست و بالتون بازتره
سوال: SSRF پیدا کردم، بعدش چی؟
حالا وقتشه که اکسپلویتش کنیم. از این باگ میشه واسه کارای زیر استفاده کرد:
بریم سراغ اولی
اولین کاری که با 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 روی این سرور بسته است.
آمازون یه سرویسی داره به اسم 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/document
Private 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 SSRF نوعی از SSRF هان که توشون شما جواب یا error message از طرف سرور دریافت نمی کنید.
ادامه ...
