با وجود تمام شایعاتی که پیرامون سرویس جدید  JSON-RPC غیرقابل اعتبار در Localhost  که توسط Tavis Ormandy ساخته شده بود وجود دارد، اولین چیزی که به نظر هدف این حملات می‌رسد، کاربرانی است که حساب ارز دیج...

با وجود تمام شایعاتی که پیرامون سرویس جدید  JSON-RPC غیرقابل اعتبار در Localhost  که توسط Tavis Ormandy ساخته شده بود وجود دارد، اولین چیزی که به نظر هدف این حملات می‌رسد، کاربرانی است که حساب ارز دیجیتال اتریوم در اختیار دارند.

اکثر مشتریان اتریوم یک سرویس JSON-RPC را بر روی پورت ۸۵۴۵ در localhost اجرا می‌کنند، اما از آنجایی که این سرویس در localhost است، به دلیل وجود SOP ما نمی‌توانیم به طور مستقیم از مرورگر کاربر به منابع دسترسی پیدا کنیم.
این مسئله با استفاده از تخریب هدر CORS در کیف پول الکترونیکی الکتروم انجام شده تا بتواند کنترل کیف پول را از طریق JSON-RPC به دست آورد.

JSON-RPC به تنهایی از امنیت بالایی برخوردار است. اما cpacia در حساب گیت هاب موضوعی را توضیح داد که نظر بسیاری را در این مورد جلب می‌کند. او گفته:

غیرفعال کردن CORS هنوز هم کاربر را در خطر حمله دی ان اس قرار می‌دهد. در این مورد باید به نوعی احراز هویت انجام شود.

در مورد دی ان اس ریبایندینگ زیاد شنیده‌ایم، اما اطلاعات زیادی از آن در دست نداریم. آیا از آنجایی که JSON-RPC Geth احراز هویت نشده است، ممکن است در برابر حملات دی ان اس آسیب پذیر نیز باشد؟

تمام مقالات دی ان اس ریبایندینگ عمدتا بسیار قدیمی بودند. همچنین در مورد آن در انجمن سوال پرسیده شد و یکی از کاربران به نام لوک یانگ اطلاعات مفیدی در این زمینه ارائه کرد.

با این حال می‌توان شروع به نوشتن کد کرد. پایتون یک کتابخانه عالی به نام dnslib دارد که اکثر موارد را در زمینه دی ان اس به دست می‌دهد. دامنه‌ای ثبت کردیم و پس از آن با رکوردهایی که آدرس سرور را تعیین می‌کرد توانستیم نیم سرورها را مشخص کنیم.

ما قصد داشتیم ببینیم که مرورگرهای مختلف چگونه با TTL های پایین رفتار می‌کنند، بنابراین سرور DNS باTTL کمتر از ۰٫۵ در فایرفاکس، کروم و سافاری در ۶۰ ثانیه پاسخ DNS را ذخیره کردند.

به نظر می‌رسد که ۶۰ ثانیه زمان زیادی نباشد و اکثرا کاربران را می‌توان تا این محدوده زمانی در وب‌سایت نگه داشت. حال به سراغ تست‌های بیشتر می‌رویم.

ما Geth را با پرچم –rpc اجرا کردیم:

geth-rpc -testnet

حالا زمان برای کد زنی جاوا اسکریپت بود و به نظر می‌رسد که این بخش سخت‌ترین مرحله کار باشد. یک توسعه دهنده وب خوب هم نمی‌تواند به راحتی تمامی کدهای جاوا اسکریپت را دنبال کند. با هک انجام شده تقریبا ۳ ساعت بعد موفق به انجام کار شدیم.

راه حل، استفاده از آی فریم ها بود. سرور آپاچی را روی پورت‌های ۸۵۴۵ و۸۰ تنظیم کردیم و برای هر پورت یک هاست مجازی تعریف شد. حال با استفاده از آی فریم می‌توان ۸۵۴۵ را به صورت فریم مخفی شده اجرا کرد و از طریق آن کد مخرب را به کار انداخت.

مسئله دیگر، مشکل سیستم چند کاربره بود، اگر چندین کاربر هم‌زمان به دامنه من مراجعه کردند، چه؟ سرور دی ان اس دچار مشکل می‌شد،زیرا ما از یک سیستم مبتنی بر شمارنده استفاده کردیم و هیچ راهی برای تفکیک بین درخواست‌های کاربران وجود نداشت. این مساله تا زمانیکه به یاد ساب دامین ها افتادم مشکل ساز بود.

برای حل این مساله می‌توان هر آی فریم را در یک ساب دامین باز کرد. به مثال زیر توجه کنید.

فرض کنید که دامنه من attacker.com است و IP سرور من ۸۷٫۸۷٫۸۷٫۸۷ است. روال به این صورت خواهد بود:

  • کاربر، مرورگر خود را باز می‌کند.
  • اول، درخواست DNS برای attacker.com به سرور من ارسال می‌شود و با IP واقعی ۸۷٫۸۷٫۸۷٫۸۷ پاسخ می‌دهد
  • بعد، attacker.com به مرورگر کاربر بارگذاری می‌شود و سپس یک آی فریم مخفی را با یک ساب دامین تصادفی randomrsub.attacker.com:8545 ایجاد می‌کند و آن را به بدنه اضافه می‌کند
  • اکنون یک درخواست DNS به سرور من برای subdomain randomrsub.attacker.com ارسال می‌شود و سرور DNS دوباره با IP واقعی ۸۷٫۸۷٫۸۷٫۸۷ پاسخ می‌دهد. اما این بار، از آنجایی که در پورت ۸۵۴۵ است، آپاچی با یک میزبان مجازی متفاوت پاسخ می‌دهد که شروع مجدد DNS را آغاز می‌کند.
  • جاوا اسکریپت در randomrashub.attacker.com:8545 منتظر ۶۰ ثانیه می‌شود و سپس XmlHttpRequest را به randomrr.attacker.com:8545/test می‌فرستد.
  • از آنجا که حافظه پنهان DNS منقضی شده است، مرورگر دوباره DNS را حذف می‌کند. این بار، سرور من با یک IP از ۱۲۷٫۰٫۰٫۱ پاسخ می‌دهد.
  • در حال حاضر درخواست به جای ۱۲۷٫۰٫۰٫۱:۸۵۴۵/test به جای سرور من ارسال شده است، و از آنجا که تحت originrr.attacker.com:8545 است، ما قادر به خواندن پاسخ هستیم.
  • از آنجایی که ما هر وقت یک subdomain تصادفی ایجاد می‌کنیم می‌توانیم حتی کاربران چندگانه را نیز جایگزین کنیم،بنابراین subdomain می‌تواند رفتار کاربر و توکن دریافتی از آن‌ها را نیز بررسی کند.

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

این روند اساسا می‌تواند با XSS ذخیره شده نیز مورد سوء استفاده قرار گیرد. فقط یک اسکریپت src به فایل js که دارای آی فریم است تعیین کنید.تمام!

بنابراین اکنون می‌توانیم پاسخ‌هایی از سرویس JSON-RPC را بخوانیم، به این معنی که می‌توانیم آدرس اتریوم آن‌ها و میزان سرمایه اتر به دست آوریم. حتی اگر حساب خود را قفل کرده باشند. API JSON-RPC دارای روش بسیار خوبی است که به نام eth_sendTransaction شناخته می‌شود که عمدتا برای فرستادن اتریوم از حساب کاربر مورد استفاده قرار می‌گیرد.
به وب‌سایت http://rebinddns.ml مراجعه کنید. اگر بیش از ۶۰ ثانیه در وب‌سایت بمانید و با Geth JSON-RPC کار کنید، هشداری را مشاهده خواهید کرد که حاوی آدرس اتریم و میزان موجودی آن است.

منبع : منبع