فرآیند RFI اجازه می دهد تا کد های دلخواه بر روی چارچوب پلتفرم برنامه ی وب ما باشد .
درسته این نوع حملات از نظر متودولوژی کمی (البته در ایران!) قدیمی و خز! به حساب آمده و مهاجمان (بازهم ایرانی!) آسیب پذیری هایی که در آن شگرفی جدید بعمل آید رو بیشتر به میل خود ترجیح خواهند داد ؛ اما با همه ی این تواصیف بیش از 77% از صفحات وب (بخش داینامیک) را PHP شامل میشود و آسیب پذیری هایی از این قبیل به وفور یافت خواهد شد (این جمله یک امر بدیهی بود ! همون وراجی!)
بحث ما در مورد چگونگی اکسپلویت شدن یک آسیب پذیری RFI یا LFI نیست ؛ بلکه در مورد جلوگیری از آنچه میتواند جلوی مهاجم در برابر حملاتی از این نوع را شامل باشد است .
از جمله رویکردهای جدیدی از این نوع حملات :
- طرح های جدید حمله از نوع اکسپلویت شدن با استفاده از PHP Streams
- اثبات چگونگی الحاق حملات LFI به اسناد PDF
- حملات چندگانه و تزریق داده های مخرب با رویکردی جدید به فایل های تصویری برای جلوگیری از تشخیص ابزارهای Anti-Malware
- استفاده از حملات دیگری غیر از فراخوانی Shell Script ها در Host های مختلف
بررسی اکسپلویت شدن آسیب پذیری RFI در TimThumb وردپرس
- Host به picasa.com.moveissantafe.com محدود شده که باید برای دور خوردن آن picasa.com را بعنوان Host مورد نظر برای حملات تغییر داد.
- با یک مشخصه GIF شروع میشود.
- یک فیلتر امنیتی جهت معتبر بودن تصویر تعبیه شده که با افزودن ملاک های PHP (رمزنگاری شده) میتوان آن را رد نمود.
- اجرای کد ها توسط پارامترهایی در PHP با نام LOL & OSC کنترل شده که آنها را هم میتوان بایپس کرد.
نمونه ی اکسپلویت این آسیب پذیری را شاهد هستیم :
و این یک نمونه ی کلی از طرح رد شدن از فیلترها بود ..
راه های دسترسی به Stream های مختلف :
- http:// https:// : HTTP URLs
- ftp:// ftps:// : FTP URLs
- data:// : Data
- file:// : local filesystem
سناریو های مورد استفاده مهاجم در بایپس فیلترها :
- اجرای phpinfo() به مشکل میخورد بنابراین >> base64(“<?php phpinfo()?>”)=”PD9waHAgcGhwaW5mbygpPz4=”
- اجرا در قالب داده >> “data://text/
plain;base64,PD9waHAgcGhwaW5mbygpPz4=
“
چرا یک مهاجم از PHP Streams در حملاتش استفاده میکند؟
- فیلترهای بسیاری در پروتکل های مختلف جلوی اکسپلویت شدن آسیب پذیری را خواهد گرفت
- حمله بصورت مخفیانه و نادید گرفته شدن از دید WAF و AVs (مانند compressed, base64)
- کد مخرب باید بصورت Local باشد ، چرا ؟ چون RFI بصورت پیشفرض در سرور غیر فعال است !
بنابراین اگر خواستار تغییر حمله بصورت Local باشیم ، در نهایت به این مشکل برخواهیم خورد که allow_url_include = off میباشد و از طریق URL نمیتوان چیزی را فراخوانی نمود !
در اینجا بکمک ویرایش درخواست های HTTP میتوانیم آنرا هم دور زنیم :
Authorization: Basic base64(user:pass)= Authorization: Basic base64(<?php phpinfo()?>:123456) = Authorization:Basic PD9waHAgcGhwaW5mbygpPz46MTIzNTY=)
و در نهایت به لاگ دسترسی پیدا خواهیم کرد :
اگر خواستار حمله بصورت ویرایش یک فایل تصویری باشیم باید سناریوهایی برای دور زدن ابزار های تشخیص کد را بررسی و آنالایز نماییم :
- هدف : بارگزاری یک تصویر که آسیب پذیری LFI را فراهم خواهد نمود.
- ویژگی های ظاهری تصویر نباید تغییر کنند.
- آنتی ویروس ها نباید آنرا بعنوان کد مخرب تشخیص دهند.
روش اول :
- استفاده از قالب تصویری jpg
- ویرایش مشخصه ی EXIF در تصویر
متوجه شناسایی فقط 3 آنتی ویروس میشویم !
تست روی 2 مشخصه دیگر منجر به دور خوردن 2 آنتی ویروس دیگر شد !
به بررسی موضوع میپردازیم :
- آنتی ویروس Clam توانست تشخیص PHP.Hide را برای این تصویر بدست آورد >> 1:0:0:ffd8ffe0?0104a464946{-4000}3c3f706870(0d|20|0a)
- 3c3f706870 هکس کد <?php میباشد.
بایپسش آسونه !!! :
<?Php !!
و ClamAV ابزار مخرب را تشخیص نخواهد داد !
در واقع آنتی ویروس ها بدنبال Content و کدهای مخرب (که Parser آنها را شناسایی خواهد نمود) در فایلها هستند.
خب ، بعد از ارتکاب این عمل ؛ یک غسل بعمل آورده تا از تمامی گناهان صغیره و کبیره پاکسازی حاصل شود ، سپس به اجرای تمامی کامند هایی که عشق آدم میکشه میپردازیم ..
پوزش بخاطر زیادی مطالب و خستگی چشم شما بیننده ی عزیز ..
پانویس 1 : ان شاالله به زودی زود حرف داخل پرانتز پست قبلی را اوکی خواهم نمود !
پانویس 2 : ان شالله اکسپلویتینگ هم یک کاریش میکنیم ..
موفق و پیروز باشید ..