دور زدن کلودفلر با Cloudflare

زمان مطالعه: 5 دقیقه

یکی از روش هایی که صاحبان سایتها از اون برای محافظت از سایتهاشون استفاده میکنن ، استفاده از CDNهایی مانند کلودفلر هستش. کلودفلر علاوه بر اینکه از لحاظ سرعت و کیفیت موجب بهبود در عملکرد سایت میشه، باعث ارتقاء امنیتی هم میشه. یکی از این موارد ، میشه به جلوگیری از حملات DDOS روی سایت اشاره کرد.

حالا یه تحقیقی منتشر شده که در اون، میشه با استفاده از مکانیسم های خود کلودفلر ، کلودفلر رو دور زد.

کلودفلر یکی از کمپانی های معروف امنیت سایبری هستش که خدمات محافظت از وب سایتها ،مانند WAF ، محافظت از DDOS و باتها رو ارائه میده. این امر از طریق شبکه ای از سرورهای reverse-proxy فراهم میشه که بین وب سرور مشتری (بهش سرور مبدا یا origin server میگن) و بازدید کننده سایت قرار میگیره و با تجزیه و تحلیل ترافیک، فعالیت های مخرب رو شناسایی میکنه. اگه بخوایین جزییاتی در خصوص نحوه کار کلودفلر بدست بیارید، میتونید مقاله ، “چطوری در سال 2023، Cloudflare دور بزنیم” رو مطالعه کنید.

از اونجاییکه مشتریای کلودفلر بطور بالقوه به این خدمات متکی هستن، مهمه که سرور مبدا رو از هرگونه دسترسی که از سرورهای reverse-proxy پیکربندی شده ،عبور نکردن ،محافظت کنن. مشتریان ممکنه با استفاده از مستندات کلودفلر، ناخواسته از مکانیسم هایی که مستعد اکسپلویت از طریق خود کلودفلر هست، استفده کنن.

این آسیب پذیری ها از زیرساخت مشترکی که برای همه tenantها در کلودفلر وجود داره ، چه قانونی چه مخرب، فراهم میشه و امکان دور زدن اقدامات امنیتی پیکربندی شده و هدف قراردادن سیستم مشتری رو میده.

 

 

محققا این آسیب پذیریها رو از طریق برنامه باگ بانتی کلودفلر در هکروان ،گزارش دادن. کلودفلر هم این گزارش رو بعنوان Informative طبقه بندی کرده و گزارش بسته. درنتیجه محققا گزارش رو عمومی کردن تا مشتریان بتونن پیکربندی های خودشون رو در برابر آسیب پذیری های زیر مورد ارزیابی قرار بدن و ایمن کنن.

 

 

بررسی کلی آسیب پذیری :

کلودفلر در مستنداتش مکانیسم های مختلفی رو برای جلوگیری از کشف و لوود بیش از حد سرور مبدا از طریق درخواستها در لایه های مختلف OSI ارائه میده. مکانیسم ها با درجات امنیتی مختلف ، متوسط یا زیاد، و چالش های فنی مرتبط با اونا طبقه بندی و توضیح داده شدن.

در طول آنالیز، محققین متوجه شدن که دو مکانیسم پیشنهادی ، رو این فرض استوار هستن که تمام ترافیک به سرور مبدا که از کلودفلر منشاء میگیره، قابل اعتماده در حالیکه اینطوری نیست. مهاجم میتونه پیلودهای مخرب خودش رو از طریق پلتفرم کلودفلر ارسال کنه و در نتیجه مکانیسم های امنیتی که مشتری برای محیط خودش پیکربندی کرده مانند WAF دور بزنه و بقولی از این اعتماد سوء استفاده کنه. تاثیر این دور زدن، بستگی به پیکربندی سرور مبدا داره.

نکته: برای سوء استفاده از هر دو مکانیسم امنیتی، نیاز به داشتن IP سرور مبدا هستش.

 

دور زدن مکانیسم Authenticated Origin Pulls :

مکانیسم Authenticated Origin Pulls ، یه مکانیسم امنیتی هستش که اطمینان میده درخواستهای HTTP(s) ، که به سرور مبدا ارسال میشه از کلودفلر هستش و از سمت مهاجم نیست.

هنگام استفاده از مکانیسم Authenticated Origin Pulls که روی لایه ی Transport پیاده سازی شده و در مستندات طبقه بندی بسیار امن رو داره، کلودفلر با استفاده از گواهی SSL/TLS درخواستهای HTTP(S) بین سرورهای reverse-proxy و سرور مبدا احرازهویت میکنه.

در مستندات zone setup هم اومده که مشتریها دو گزینه برای این منظور در دسترس دارن، یا باید از گواهی کلودفلر استفاده کنن یا از یه گواهی شخصی. نکته بعد ماجرا اینجاست که در مستندات به پیامدهای امنیتی مرتبط با این گزینه ها اشاره نشده.

 

 

با توجه به اینکه استفاده از گواهی شخصی ، فقط از طریق یه API ، قابل آپلود و استفاده هستش، مشتریان اغلب از گزینه ساده تر ،یعنی گواهی کلودفلر ، استفاده میکنن.

مشکل اینجاست که کلودفلر از یه گواهی مشترک برای همه مشتریا به جای استفاده از یه گواهی اختصاصی برای هر tenant استفاده میکنه، در نتیجه همه اتصالات با منشاء کلودفلر مجاز میشن و اون احرازهویته دور میخوره.

یه مهاجم میتونه یه دامنه شخصی با کلودفلر بالا بیاره و رکورد DNS A رو به IP قربانی ست کنه. بعدش مهاجم همه ویژگی های امنیتی برای اون دامنه رو غیر فعال میکنه و حمله خودش رو از طریق زیرساخت کلودفلر هدایت میکنه. این روش باعث میشه تا مهاجم بتونه ویژگی های امنیتی قربانی رو دور بزنه.

 

 

در حقیقت مهاجم میتونه از این روش و با یه اکانت کلودفلر رایگان، ترافیک مخرب رو به سایر کلاینتهای کلودفلر هدایت کنه یا برای حمله از زیرساخت کلودفلر استفاده کنه.

در حال حاضر تنها روش برای جلوگیری از این حمله، استفاده از گواهی های اختصاصی هستش.

 

دور زدن مکانیسم Allowlist Cloudflare IP addresses :

مکانیسم Allowlist Cloudflare IP addresses که روی لایه Network هستش و در مستندات با عنوان نسبتا ایمن (متوسط) طبقه بندی شده، اینجوریه که سرور مبدا هر اتصالی که خارج از محدوده آدرس IP کلودفلر باشه رو رد میکنه. برای تنظیم محدوده هم باید از فایل htaccess یا iptables استفاده کنید.

این مکانیسم هم ،مشکل مکانیسم امنیتی بالا رو داره، یعنی همه اتصالات با منشاء کلودفلر ، بدون در نظر گرفتن tenant ،مجاز هستن.

در این روش هم ، یه مهاجم میتونه یه دامنه شخصی با کلودفلر بالا بیاره و رکورد DNS A رو به IP قربانی ست کنه. بعدش مهاجم همه ویژگی های امنیتی برای اون دامنه رو غیر فعال میکنه و حمله خودش رو از طریق زیرساخت کلودفلر هدایت میکنه. این روش باعث میشه تا مهاجم بتونه ویژگی های امنیتی قربانی رو دور بزنه.

 

 

تنها روش حفاظتی در برابر این روش استفاده از Aegis هستش که آدرس های IP اختصاصی ،بجای محدوده آدرس IP مشترک ، ارائه میده که البته برای همه در دسترس نیست.

 

یه نمونه PoC :

محققا یه PoC هم در خصوص استفاده از این تکنیکها منتشر کردن و اومدن یه دامنه ، victim.test که دارای سرور مبدا ، IP:203.0.113.42 هست و از دو مکانیسم Authenticated Origin Pulls با گواهی کلودفلر و Allowlist Cloudflare IP addresses مطابق با مستندات کلودفلر، بالا آوردن و با استفاده از روش هایی که در بالا اشاره شد، اومدن WAF رو دور زدن.

مهاجم یه دامنه با عنوان attacker.test ،بدون هیچ WAFای ثبت میکنه و آدرس IP سرور مبدا victim.test رو ست میکنه. این به مهاجم این امکان رو میده که درخواستهاش رو از طریق attacker.test به IP:203.0.113.42 ارسال کنه ، که اگه این درخواستهارو از طریق victim.test ارسال کنه، مسدود میشه.

بطور خلاصه پیکربندی اکانت کلودفلر قربانی بصورت زیر هستش :

 

 

پیکربندی سرور مبدا قربانی هم بصورت زیر هستش :

 

 

پیکربندی اکانت کلودفلر مهاجم هم بصورت زیر هستش :

 

 

اگه یه ورودی مخرب به دامنه قربانی ارسال کنیم، WAF کلودفلر اونو مسدود میکنه :

 

 

اما اگه همون درخواست رو با استفاده از مکانیسمی که در بالا اشاره شد ارسال کنیم، میتونیم اونو دور بزنیم :

 

 

 

منبع