آسیب پذیری Http Request Smuggling چیست ؟

آسیب پذیری Http Request Smuggling چیست ؟

با یکی دیگر از مقالات تیم بلک سکوریتی خدمت شما هستیم. در این پست آموزشی قراره در مورد آسیب‌پذیری Http Request Smuggling بپردازیم و با هم بررسی کنیم که این آسیب‌ پذیری چگونه رخ می‌دهد.

HTTP request smuggling چیست ؟

وبسایت‌هایی که از دو سرور به عنوان سرور اصلی (Back-End) و سرور load balancer یا Reverse Proxy تحت عنوان (Front-End) استفاده می‌کنند مستعد این آسیب‌پذیری هستند.قاچاق درخواست یا request Smuggling این امکان را به هکر می‌دهد تا بتواند درخواست مخرب خود را بدون بحث User Interaction (تعامل کاربر) انجام دهد و آسیب‌پذیری‌های سامانه که گاها به صورت Self نیز هستند را به صورت Non-Self به صورت حجیم اکسپلویت کند.از سوی دیگر ممکن است این اجازه را به هکر برای خواندن فایل‌های مهم سروری که معمولا با ارور 403 مواجه می‌شویم بدهد.

این آسیب‌پذیری بر روی HTTP version 1 کشف شده است اما ممکن است در سامانه‌هایی که از HTTP Version 2 نیز استفاده می‌کنند؛ با توجه به معماری سرور Back-End نیز آسیب‌پذیر باشند.

قاچاق درخواست HTTP برای اولین بار در سال 2005 مستند شد و توسط تحقیقات گسترده PortSwigger در مورد این موضوع دوباره محبوب شد.

در حمله HTTP Request Smuggling چه اتفاقی می افتد ؟

همانطور که بالا گفتم بعضی از سامانه‌ها از یک سرور Front-end به عنوان load balancer یا Reverse Proxy استفاده می‌کنند که این سرور وظیفه ارسال درخواست‌ها را به سرور(ها) Back-End دارد.

وقتی سرور Front درخواست‌های HTTP را به یک سرور بک‌اند ارسال می‌کند، معمولاً چندین درخواست را از طریق یک اتصال شبکه بک‌اند ارسال می‌کند، زیرا این کار بسیار کارآمدتر ست. درخواست‌های HTTP یکی پس از دیگری ارسال می‌شوند و سرور دریافت‌کننده (بک‌اند ) باید تعیین کند که یک درخواست کجا تمام می‌شود و درخواست بعدی شروع می‌شود.

در این شرایط بسیار مهم است که سرور فرانت‌اند و بک‌اند در مورد استفاده از Transfer_Encoding و Content-Lengh با هم هماهنگ باشند تا تفسیر‌های متفاوتی از درخواست‌های ارسالی نداشته باشند که باعث ایجاد آسیب‌پذیری شود.

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

آسیب‌پذیری‌های HTTP request smuggling چگونه ایجاد می‌شوند ؟

بیشترین علت این آسیب‌پذیری پیکربندی نادرست استفاده از هدر Content-Length و  Transfer-Encoding در HTTP 1 می‌باشد. Content-Length طول Body را بر حسب بایت بررسی می‌کند. برای نمونه :

POST /search HTTP/1.1
Host: normal-website.com 
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

Transfer-Encoding بادی را بر اساس Chunked ها بررسی می‌کند که Chunked ها با رسیدن به 0 خاتمه می‌یابند.

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

بسیاری از تسترهای امنیتی به دو دلیل نمی‌دانند که Chunked Encoding  را می‌توان در درخواست‌های HTTP استفاده کرد:

• Burp Suite به‌طور خودکار کدهای Chunked را باز می‌کند تا پیام‌ها را برای مشاهده و ویرایش آسان‌تر کند.
• مرورگرها معمولاً از Chunked Encoding در درخواست ها استفاده نمی کنند و معمولاً فقط در پاسخ های سرور دیده می شود.

در ادامه..

پروتکل HTTP 1  از دو روش  Content-Lenght و Transfer-Encoding برای بررسی طول Body استفاده می‌کند. ممکن است یک درخواست از دو روش برای بررسی طول بادی استفاده کند که اینجا برای رفع ابهام زادیی باید Content-Lenght نادیده گرفته شود. این روش زمانی که از یک سرور استفاده می‌کنیم ممکن است مفید باشد اما نه برای  استفاده از چند سرورمتصل بهم.

در این شرایط مشکلات به دو علت ممکن است ایجاد شود:

• برخی از سرورها از هدر Transfer-Encoding در درخواست ها پشتیبانی نمی کنند.
• برخی از سرورهایی که از هدر Transfer-Encoding پشتیبانی می کنند، میتوان وادار شد که اگر هدر به نحوی مبهم باشد، آن را پردازش نکنند.

اگر سرور فرانت و بک‌اند در رابطه با هدر Transfer-Encoding رفتار متفاوتی داشته باشند این امر ممکن است باعث اختلاف در مرز درخواست‌ها (نقطه پایان درخواست و شروع درخواست جدید) شود که منجر به آسیب‌پذیری‌های اسماگلینگ می‌شود.

وب‌سایت‌هایی که از HTTP/2 End To End استفاده می‌کنند، ذاتاً از درخواست Smuggling مصون هستند.
از آنجایی که مشخصات HTTP/2 یک مکانیسم منفرد و قوی را برای تعیین طول یک درخواست معرفی می کند، هیچ راهی برای مهاجم وجود ندارد که ابهام مورد نیاز را معرفی کند.

با این حال، بسیاری از وب‌سایت‌ها یک سرور فرانت HTTP/2 دارند، اما ممکن است که سرور بک‌اند از HTTP/1 استفاده کند
که این موضوع باعث می‌شود سرور فرانت عملیات HTTP downgrading  را برای ترجمه درخواست خود انجام دهد که احتمال حملات Advance HTTP Request Smuggling را درپی دارد.

 

نحوه انجام یک حمله HTTP Request Smuggling

حمله کلاسیک اسمالگینگ به این گونه است که از Content-Length و Transfer-Encoding به طور همزمان در درخواست HTTP/1 خود استفاده کنیم که سرور فرانت و بک اند تفاسیر متفاوتی را از درخواست ما داشته باشند. روش انجام کار و اکسپلویت به نحوه رفتار سرورها بستگی دارد که ممکن است به شکل‌های زیر باشد.

1. CL.TE: سرور front-end از هدر Content-Length و سرور Back-end از هدر Transfer-Encoding استفاده می کند.
2. TE.CL: سرور front-end از هدر Transfer-Encoding و سرور back-end از هدر Content-Length استفاده می کند.
3. TE.TE: سرورهای front-end و back-end هر دو از هدر Transfer-Encoding پشتیبانی می کنند، اما می توان یکی از سرورها را با مبهم کردن هدر به نحوی وادار کرد که آن را پردازش نکند.

نکته :

این تکنیک ها فقط با استفاده از درخواست های HTTP/1 امکان پذیر است. مرورگرها و سایر کلاینت‌ها، از جمله Burp، به‌طور پیش‌فرض از HTTP/2 برای برقراری ارتباط با سرورهایی استفاده می‌کنند در نتیجه، هنگام آزمایش سایت‌هایی با پشتیبانی HTTP/2، باید پروتکل‌ها را به صورت دستی به HTTP/1  در Burp Repeater تغییر دهید. می توانید این کار را از قسمت Request features در پنل Inspector انجام دهید.

آسیب‌پذیری CL.TE

در ریکوئست زیر سرور فرانت درخواست را بر اساس Content-Length بررسی می‌کند و سرور بک‌اند درخواست را بر اساس Transfer-Encoding بررسی می‌کند؛ ما می‌توانیم یک حمله Smuggling ساده درخواست HTTP را به شرح زیر انجام دهیم :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

در ریکوئست بالا، سرور فرانت بر اساس هدر Content-Length پردازش می‌کند و تعیین می‌کند که بدنه درخواست 13 بایت، تا پایان SMUGGLED باشد. سپس این درخواست به سرور back-end ارسال می شود.

سرور بک‌اند بر اساس هدر Transfer-Encoding پردازش می‌کند، و بنابراین با بدنه درخواست مانند
استفاده از chunked encoding رفتار می‌کند. اولین قطعه(chunked) را پردازش می کند که به صفر برسد و بنابراین صفر را به عنوان پایان درخواست تلقی می کند؛ و بایت‌های زیر صفر، پردازش نشده باقی می‌مانند و سرور بک‌اند با آن‌ها به عنوان شروع درخواست بعدی برخورد می‌کند.

آسیب‌پذیری TE.CL

در اینجا سرور Front از هدر Transfer-Encoding و سرور Back-End از هدر Content-Length استفاده می کند. ما می‌توانیم یک HTTP Request Smuggling  از این نوع را به شرح زیر انجام دهیم :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8

SMUGGLED

0

توجه داشته باشید
برای ارسال این درخواست با استفاده از Burp Repeater، ابتدا باید به منوی Repeater رفته و مطمئن شوید که تیک گزینه “Update Content-Length” را برداشته‌اید.

باید در انتهای درخواست از  \r\n\r\n به عنوان 0 آخر استغاده کنید.

سرور فرانت هدر Transfer-Encoding را پردازش می کند، و بنابراین با بدنه پیام مانند استفاده از chunked encoding برخورد می کند.
اولین قطعه (Chunked) را که گفته می شود 8 بایت طول دارد و تا ابتدای خط زیر SMUGGLED پردازش می کند.سرور قطعه دوم را پردازش می کند که طول آن صفر است و بنابراین به عنوان پایان درخواست تلقی می شود. این درخواست به سرور back-end ارسال می شود.

• سرور بک‌اند هدر Content-Length را پردازش می‌کند و تعیین می‌کند که بدنه درخواست 3 بایت، تا ابتدای خط زیر 8 باشد.بایت‌های زیر، که با SMUGGLED شروع می‌شوند، پردازش نشده باقی می‌مانند و سرور بک‌اند با آن‌ها به عنوان شروع درخواست بعدی برخورد می‌کند.

رفتار TE.TE : obfuscating the TE header

در اینجا سرورهای front-end و back-end هر دو از هدر Transfer-Encoding پشتیبانی می کنند، اما می توان یکی از سرورها را وادار کرد که با مبهم کردن هدر به نحوی، آن را پردازش نکند.

راه های بالقوه بی پایانی برای مبهم کردن هدر Transfer-Encoding وجود دارد. مثلا:

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked

Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding : chunked

هر یک از این تکنیک ها شامل یک انحراف ظریف از مشخصات HTTP است.کد دنیای واقعی که مشخصات پروتکل را پیاده‌سازی می‌کند
به ندرت به آن با دقت مطلق پایبند است، و معمولاً برای پیاده‌سازی‌های مختلف، تغییرات متفاوتی از مشخصات را تحمل می‌کنند.برای کشف یک آسیب‌پذیری TE.TE، لازم است تغییراتی از هدر Transfer-Encoding پیدا شود به طوری که فقط یکی از سرورهای فرانت یا بک‌اند آن را پردازش کند، در حالی که سرور دیگر آن را نادیده می‌گیرد.

• بسته به اینکه سرور فرانت‌اند یا بک‌اند باشد که می‌توان هدر مبهم(obfuscated) Transfer-Encoding را پردازش نکند، باقی‌مانده حمله به همان شکل آسیب‌پذیری‌های CL.TE یا TE.CL خواهد بود. قبلا شرح داده شده است.

چگونه از آسیب پذیری های HTTP Request Smuggling جلوگیری کنیم ؟

آسیب‌پذیری‌‌های Request Smuggling در شرایطی ایجاد می‌شوند که سرور فرانت‌اند و سرور بک‌اند
از مکانیزم‌های مختلفی (Content-Length و Transfer-Encoding) برای تعیین مرزهای بین درخواست‌ها استفاده می‌کنند.این آسیب‌پذیری به علت اختلاف بررسی درخواست‌ها بین سرور فرانت و بک‌اند بر اساس Transfer-Encoding و یا Content-Length است. همانطور صحبت کردیم در HTTP/2 هم ممکن است اگر سرور بک‌اند از HTTP/1 پشتیبانی کند آسیب‌پذیر باشد.

برای جلوگیری از این آسیب‌پذیری اقدامات زیر توصیه می‌شود :

• از HTTP/2 end to end استفاده کنید و در صورت امکان، downgrading HTTP را غیرفعال کنید. HTTP/2 از یک مکانیسم قوی برای تعیین طول درخواست‌ها استفاده می‌کند و وقتی از end to end استفاده می‌شود، ذاتاً در برابر اسماگلینگ محافظت می‌شود. اگر نمی‌توانید از downgrading HTTP اجتناب کنید، مطمئن شوید که درخواست بازنویسی شده را بر اساس مشخصات HTTP/1.1 تأیید می‌کنید. به عنوان مثال، درخواست هایی که حاوی خطوط جدید در هدرها، دو نقطه در header name ها و space در روش درخواست هستند را رد کنید.
• سرور front درخواست‌های مبهم(ambiguous) را normalize کند و سرور Back-End درخواست‌های مبهم(ambiguous) را رد کند و اتصال TCP در این فرآیند بسته شود.
• هرگز تصور نکنید که درخواست ها Body ندارند. این علت اساسی، آسیب‌پذیری‌های CL.0 و client-side desync است.
• اگر server-level exceptions هنگام رسیدگی به درخواست‌ها فعال شوند، به‌طور پیش‌فرض از اتصال صرف‌نظر شود.
• اگر ترافیک را از طریق یک forward proxy هدایت می‌کنید، مطمئن شوید که upstream HTTP/2 در صورت امکان فعال است.

در این مقاله سعی کردیم به معرفی آسیب‌پذیری request Smuggling بپردازیم؛
در مقالات بعدی حتما به روش شناسایی و اکسپلویت این آسیب‌پذیری خواهیم پرداخت. در صورتی که قصد مطالعه بیشتر دارید از طریق لینک مقاله منبع به وبسایت portswigger مراجعه کنید. منابع استفاده شده در این مقاله.

Security Operations Center یا SOC چیست ؟ کلیک کنید !