محافظت از شبکه در برابر حملات جعل dns. DNS Poisoning یا DNS Spoofing چیست؟ گذشته و حال جعل

جعل IDN تولید نام‌های دامنه «مشابه» با دامنه انتخابی است که معمولاً برای وادار کردن کاربر به دنبال کردن پیوندی به منبع مهاجم استفاده می‌شود. در مرحله بعد، بیایید به یک گزینه حمله خاص تر نگاه کنیم.

بیایید تصور کنیم که شرکت مورد حمله مالک دامنه Organization.org است و در داخل این شرکت از منبع داخلی portal.organization.org استفاده می شود. هدف مهاجم این است که اعتبار کاربر را به دست آورد و برای انجام این کار، پیوندی را از طریق ایمیل یا پیام رسان مورد استفاده شرکت ارسال می کند.

پس از دریافت چنین پیامی، احتمال زیادی وجود دارد که متوجه نشوید که پیوند به جایی اشتباه هدایت می شود. پس از کلیک بر روی لینک، یک لاگین/رمز عبور درخواست می شود و قربانی با تصور اینکه در یک منبع داخلی است، داده های خود را وارد می کند. حساب. شانس مهاجم به ویژه اگر قبلاً به محیط نفوذ کرده باشد، سیستم هر کارمندی را به خطر بیندازد و اکنون برای امتیازات مدیر سیستم مبارزه کند، زیاد است.

در اینجا غیرممکن است که به "ضد خطا" مطلق دست پیدا کنید، اما می توانید سعی کنید این حمله را در مرحله حل نام از طریق یک درخواست DNS رهگیری کنید.

برای محافظت، ما باید به‌طور متوالی نام‌هایی را که در درخواست‌های DNS رهگیری شده مشاهده می‌شوند، به خاطر بسپاریم. این شرکت از منابع داخلی خود استفاده می کند، به این معنی که ما به سرعت آن را در یک درخواست به portal.organization.org پیدا خواهیم کرد. به محض اینکه با نامی «مشابه» با نام قبلی مواجه شدیم، می‌توانیم پاسخ DNS را با بازگرداندن خطا به جای آدرس IP مهاجم جایگزین کنیم.
چه الگوریتم هایی می تواند برای تعیین "شباهت" وجود داشته باشد؟

  • UTS39 Confusable Detection (http://www.unicode.org/reports/tr39/#Confusable_Detection) یونیکد نه تنها یک جدول نماد ارزشمند است، بلکه مجموعه ای از استانداردها و توصیه ها نیز هست. UTS39 یک الگوریتم عادی سازی رشته یونیکد را تعریف می کند، که در آن رشته هایی که از نظر همگلیف متفاوت هستند (به عنوان مثال، روسی "a" و لاتین "a") به یک شکل کاهش می یابد.
  • کلماتی که با ترتیب مجدد حروف داخلی متفاوت هستند. اشتباه گرفتن organisation.org و orgainzation.org بسیار آسان است
  • جایگزینی دامنه سطح اول. سطح اول نام معمولاً معنایی ندارد و یک کارمند شرکت که "سازمان" را می بیند می تواند تفاوت در .org یا .net را نادیده بگیرد، اگرچه استثنائاتی در اینجا امکان پذیر است.
به احتمال زیاد، سرور شرکتی متصل نخواهد شد، که به احتمال زیاد یک استاندارد برای میزبان ها یا ارائه دهندگان وب است، اما مایکروسافت سرور dnsبه دلیل استفاده گسترده از دایرکتوری فعال. و اولین مشکلی که هنگام نوشتن فیلتر برای سرور DNS مایکروسافت با آن مواجه شدم این بود که نتوانستم یک API برای فیلتر کردن درخواست‌های DNS پیدا کنم. این مشکل را می توان به روش های مختلف حل کرد، من تزریق dll و یک قلاب IAT را برای سوکت api انتخاب کردم.

برای درک روش، دانش فرمت PE ضروری خواهد بود؛ برای مثال، می توانید جزئیات بیشتری را بخوانید. فایل اجرایی از هدرها، جدولی از بخش ها و خود بخش ها تشکیل شده است. خود بخش ها بلوکی از داده ها هستند که بوت لودر باید در یک آدرس نسبی در حافظه نگاشت (آدرس مجازی نسبی - RVA) و تمام منابع، کد و سایر داده ها در داخل بخش ها قرار می گیرند. همچنین در داخل هدر پیوندهایی (RVA) به تعدادی از جداول لازم برای کارکرد برنامه وجود دارد؛ برای اهداف این مقاله، دو جدول مهم هستند - جدول واردات و جدول صادرات. جدول واردات حاوی لیستی از توابع است که برای کارکرد برنامه ضروری هستند، اما در فایل های دیگر قرار دارند. جدول صادرات یک جدول "به عقب" است که حاوی لیستی از توابع است که از آن فایل صادر می شود، یا در مورد صادرات، نام فایل و نام تابع برای رفع وابستگی.

ما تزریق dll را بدون CreateRemoteThread خسته کننده انجام خواهیم داد. من تصمیم گرفتم از ارسال صادرات PE استفاده کنم - این یک تکنیک شناخته شده است که برای بارگیری در فرآیند مورد نظر، یک dll در فهرست با فایل exe با نامی برابر با نام هر dll از واردات ایجاد می شود. جدول فایل exe (نکته اصلی این است که از HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs استفاده نکنید). در dll ایجاد شده، جدول صادرات از dll هدف کپی می شود، اما به جای اشاره گر به کد تابع صادر شده، باید RVA را در یک رشته رو به جلو مانند "endpoint!sendto" بنویسید. خود سرور dns مایکروسافت به عنوان یک سرویس HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS پیاده سازی شده است که در %systemroot%\system32\dns.exe قرار دارد.

الگوریتم تزریق نهایی به سرور dnsبه این صورت خواهد بود:

  • یک دایرکتوری %systemroot%\system32\dnsflt ایجاد کنید (هر دایرکتوری دیگری امکان پذیر است، نیازی به یافتن دایرکتوری در system32 نیست).
  • %systemroot%\system32\dnsapi.dll را در آنجا کپی کنید - این dll است که dns.exe چیزی را از آن وارد می کند، می توانید هر "dll ناشناخته" دیگری را انتخاب کنید.
  • dll کپی شده را به endpoint.dll تغییر نام دهید - ما از این نام در خط جلو استفاده خواهیم کرد.
  • dll تزریق شده خود را می گیریم و جدول صادرات صحیح را به آن اضافه می کنیم، dll خود را در %systemroot%\system32\dnsflt کپی می کنیم.
  • در کلید رجیستری HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS آدرس باینری جدید را در ImagePath %systemroot%\system32\dnsflt\dns.exe تغییر دهید.
  • ایجاد یک پیوند نمادین از %systemroot%\system32\dnsflt\dns.exe به %systemroot%\system32\dns.exe
چرا مرحله آخر؟ واقعیت این است که ویندوز دارای فایروال داخلی است و به طور پیش فرض، در سرور ویندوزفقط برنامه %systemroot%\system32\dns.exe حق گوش دادن به پورت 53 را دارد. اگر سعی کنید آن را از دایرکتوری دیگری اجرا کنید، حق دسترسی به شبکه نخواهید داشت. اصلا چرا کپی کردم؟ به منظور به حداقل رساندن تاثیر بر روی کل سیستم و لمس نکردن dnsapi.dll اصلی. به نظر می رسد که اگر می دانید چگونه یک پیوند نمادین به یک برنامه ایجاد کنید، می توانید حقوق شبکه آن را بدست آورید. به‌طور پیش‌فرض، فقط مدیران حق ایجاد پیوندهای نمادین را دارند، اما بسیار شگفت‌آور است که با دادن حق ایجاد پیوندهای نمادین به کاربر، این فرصت را به او می‌دهید که فایروال داخلی را دور بزند.

پس از بارگیری در فرآیند از DllMain، می توانید یک موضوع ایجاد کنید و یک رهگیری راه اندازی کنید. در بسیار مورد سادهسرویس dns ما آدرس IP نام را با ارسال یک بسته UDP از پورت 53 از طریق تابع sendto از ws2_32.dll به مشتری می گوید. این استاندارد پیشنهاد می‌کند که اگر پاسخ بسیار بزرگ باشد، می‌توان از پورت TCP 53 استفاده کرد و بدیهی است که رهگیری sendto در این مورد بی‌فایده خواهد بود. با این حال، می توان با tcp به روشی مشابه رسیدگی کرد، اگرچه کار فشرده تر است. در حال حاضر، من ساده ترین مورد را با UDP به شما می گویم. بنابراین می دانیم که کد موجود در dns.exe تابع sendto را از ws2_32.dll وارد می کند و از آن برای پاسخ به درخواست DNS استفاده می کند. همچنین توابع بسیار زیادی برای رهگیری وجود دارد راه های مختلف، کلاسیک عبارت است از splicing، زمانی که اولین دستورالعمل sendto با jmp در تابع آن جایگزین می شود و پس از تکمیل آن، انتقالی به دستورالعمل های sendto ذخیره شده قبلی و سپس داخل تابع sendto انجام می شود. Splicing کار خواهد کرد حتی اگر GetProcAddress برای فراخوانی sendto به جای یک جدول import استفاده شود، اما اگر از جدول import استفاده شود، استفاده از قلاب IAT به جای اتصال آسان تر است. برای انجام این کار، باید جدول واردات را در تصویر دانلود شده dns.exe پیدا کنید. خود جدول ساختاری تا حدودی گیج کننده دارد و برای جزئیات باید به توضیحات فرمت PE بروید.

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

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

Int sendto(_In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int flags, _In_ const struct sockaddr *to, _In_ int tolen);
اگر s یک سوکت در پورت 53 باشد، نشانگر buf حاوی یک پاسخ dns با اندازه len خواهد بود. خود قالب در RFC1035 توضیح داده شده است، من به طور خلاصه توضیح خواهم داد که برای رسیدن به داده های مورد علاقه چه کاری باید انجام شود.

ساختار پیام در استاندارد به شرح زیر است:

در عنوان از اطلاعات لازم: نوع پیام، کد خطا و تعداد عناصر در بخش ها. خود هدر به شکل زیر است:

ساختار DNS_HEADER ( شناسه uint16_t؛ // شماره شناسایی uint8_t rd: 1؛ // بازگشت مورد نظر uint8_t tc: 1؛ // پیام کوتاه شده uint8_t aa: 1؛ // پاسخ معتبر uint8_t کد باز: 4؛ // هدف از پیام qr: uint8_t 1؛ // query/response flag uint8_t rcode: 4؛ // کد پاسخ uint8_t cd: 1؛ // بررسی غیرفعال شدن آگهی uint8_t: 1؛ // داده های احراز هویت شده uint8_t z: 1؛ // z آن رزرو شده uint8_t ra: 1 ؛ // بازگشتی موجود uint16_t q_count؛ // تعداد ورودی‌های سؤال uint16_t ans_count؛ // تعداد ورودی‌های پاسخ uint16_t auth_count؛ // تعداد ورودی‌های مرجع uint16_t add_count؛ // تعداد ورودی‌های منبع );
برای رسیدن به پاسخ، بخش سؤال باید جدا شود. خود بخش شامل تعداد بلوک های مشخص شده در هدر (q_count) است. هر بلوک از یک نام، نوع و کلاس درخواست تشکیل شده است. نام به صورت دنباله ای از رشته ها کدگذاری می شود که هر کدام با یک بایت با طول رشته شروع می شود. در انتها یک رشته با طول صفر وجود دارد. به عنوان مثال، نام homedomain2008.ru به شکل زیر خواهد بود:

بخش Answers مشابه به نظر می رسد: بلوک شامل نام، نوع، کلاس، ttl و داده های اضافی است. آدرس IP در افزودنی موجود خواهد بود. داده ها. مشکل دیگری هنگام تجزیه نام ایجاد می شود. ظاهراً برای کاهش اندازه پیام، به جای طول برچسب، می توانید پیوندی به ناحیه داده دیگری پیدا کنید. به صورت زیر کدگذاری می شود: اگر 2 بیت مهم طول برابر با 11 باشد، بایت بعدی و همچنین کم اهمیت ترین بیت های طول باید به عنوان یک افست در بایت نسبت به ابتدای بایت تفسیر شوند. پیام تجزیه بیشتر نام باید با عبور از این افست انجام شود.

بنابراین، ما API مورد نیاز را رهگیری کرده‌ایم، پاسخ DNS را تجزیه کرده‌ایم، اکنون باید تصمیم بگیریم: این پاسخ را بیشتر رد کنیم یا یک خطا را برگردانیم. برای هر نامی که هنوز در پایگاه داده وجود ندارد، باید از پاسخ بررسی کنید که آیا "مشکوک" است یا خیر.
ما نام هایی را که نتیجه عملکرد اسکلت از استاندارد فنی یونیکد tr39 با نتیجه هر یک از نام های پایگاه داده مطابقت داشته باشد، یا نام هایی که با نام های موجود در پایگاه داده با ترتیب مجدد حروف داخلی متفاوت است، "مشکوک" در نظر می گیریم. . برای اجرای چک ها 2 جدول ذخیره می کنیم. اولی شامل نتایج اسکلتی برای همه نام‌ها از پایگاه داده است، در جدول دوم ردیف‌هایی را که از ردیف‌های پایگاه داده به دست آمده‌اند، با حذف اولین و آخرین کاراکتر از هر برچسب به جز سطح اول، و سپس مرتب‌سازی باقی‌مانده‌ها می‌نویسیم. کاراکترهای هر برچسب حال اگر نام جدیدی در یکی از دو جدول قرار گیرد آن را مشکوک می دانیم.

هدف از تابع اسکلت تعیین شباهت دو رشته است؛ برای این کار، کاراکترها برای هر رشته نرمال می شوند. به عنوان مثال، Xlœ به Xloe تبدیل می شود و بنابراین، با مقایسه نتیجه تابع، می توانید شباهت رشته های یونیکد را تعیین کنید.

نمونه ای از اجرای موارد فوق را می توان در github یافت.
بدیهی است که راه حل ذکر شده در عمل نمی تواند حفاظت عادی را ارائه دهد، زیرا علاوه بر مشکلات فنی جزئی در مورد رهگیری، مشکل بزرگتری در تشخیص نام های "مشابه" وجود دارد. رسیدگی به این موارد خوب خواهد بود:

  • ترکیبی از جایگشت ها و هموگلیف ها.
  • افزودن/جایگزین کردن کاراکترها توسط اسکلت در نظر گرفته نشده است.
  • UTS tr39 به اسکلت محدود نمی شود؛ همچنین می توانید ترکیب مجموعه کاراکترها را در یک برچسب محدود کنید.
  • نقطه ژاپنی با عرض کامل و دیگر جداکننده برچسب.
  • و همچنین چیزهای شگفت انگیزی مانند

جعل یک روش نسبتا جالب حمله است که بسیاری از متخصصان امنیت سایبری از آن غفلت می کنند. اما بیهوده، بسیار بیهوده. از این مقاله خواهید فهمید که چقدر این دنیای متنوع می تواند فریبنده باشد. چشم هایت را باور نکن!

هشدار

تمام اطلاعات فقط برای مقاصد اطلاعاتی ارائه شده است. نه سردبیران و نه نویسنده مسئولیتی در قبال آسیب احتمالی ناشی از مطالب این مقاله ندارند.

مقدمه

من اغلب از همکارانم می شنوم که جعل به عنوان یک بردار حمله حتی نباید در نظر گرفته شود. با این حال، من می توانم به شما اطمینان دهم که اگر روش های جعل به دقت فکر شده باشد، می توان از آنها برای موارد بسیار بسیار زیادی استفاده کرد. علاوه بر این، مقیاس و نتایج چنین حملاتی گاهی فاجعه بار است. از این گذشته ، با یک بار فریب دادن چشمان شما ، بیشتر شما را فریب خواهم داد. مهمترین استدلال در حمایت از این واقعیت که حملات جعلی یک خطر واقعی است این است که حتی یک فرد، از جمله متخصصان، از آنها مصون نیستند. در اینجا باید توجه داشت که جعل به خودی خود چیزی به دست نمی آورد: برای انجام یک حمله هکری واقعی، باید از پس بهره برداری استفاده کنید. در بیشتر موارد، اهداف پس از بهره برداری، تصاحب استاندارد، افزایش امتیاز، توزیع انبوه است. بد افزارو در نتیجه سرقت اطلاعات شخصی و کلیدهای دیجیتال سیستم های بانکی همراه با پولشویی بیشتر. در این مقاله، اولاً، می‌خواهم در مورد اینکه چه روش‌های کلاهبرداری به طور کلی وجود دارد، صحبت کنم، و ثانیاً، در مورد برخی از رویکردهای مدرن با جزئیات به شما بگویم. طبیعتاً تمام اطلاعات فقط به این منظور در اختیار شما قرار می گیرد که به شما کمک کند از این نوع حملات محافظت کنید.

گذشته و حال جعل

در ابتدا، اصطلاح "جعل" به عنوان یک اصطلاح امنیتی شبکه مورد استفاده قرار گرفت که به معنای جعل موفقیت آمیز داده های خاص به منظور دسترسی غیرمجاز به یک منبع شبکه خاص است. با گذشت زمان، استفاده از این اصطلاح در سایر حوزه‌های امنیت اطلاعات آغاز شد، اگرچه امروزه اکثر متخصصان به اصطلاح قدیمی مدرسه همچنان از کلمه "جعل" فقط برای روشن کردن نوع حملات شبکه استفاده می‌کنند.

اولین کلون های IDN

حمله با استفاده از هوموگرافی IDN برای اولین بار در سال 2001 توسط Evgeniy Gabrilovich و Alex Gontmakher از موسسه فناوری Technion در اسرائیل توصیف شد. اولین مورد شناخته شده از حمله موفقیت آمیز با استفاده از این روش در سال 2005 در کنفرانس هکر ShmooCon عمومی شد. هکرها موفق شدند دامنه جعلی paypal.com (xn--pypal-4ve.com در Punycode) را ثبت کنند که اولین حرف a سیریلیک است. با تشکر از انتشار در Slashdot.org، توجه عمومی به این مشکل جلب شد، پس از آن هم مرورگرها و هم مدیران بسیاری از دامنه ها سطح بالااقدامات متقابل را توسعه و اجرا کرد.

بنابراین، زمانی که شبکه در مراحل ابتدایی خود بود، بیشتر تلاش برنامه نویسان و توسعه دهندگان عمدتاً معطوف به بهینه سازی الگوریتم های عملکرد پروتکل های شبکه بود. امنیت به اندازه امروز حیاتی نبود و همانطور که اغلب اتفاق می افتد، توجه بسیار کمی به آن می شد. در نتیجه، با خطاهای پیش پا افتاده و اساسی در پروتکل های شبکه مواجه می شویم که با وجود انواع وصله ها، امروزه همچنان وجود دارند (زیرا هیچ وصله ای نمی تواند یک خطای پروتکل منطقی را وصله کند). این نیاز به تغییرات کلی دارد که شبکه در شکل فعلی خود به سادگی نمی تواند دوام بیاورد. به عنوان مثال، در مقاله "حمله به DNS: دیروز، امروز، فردا" (][ #5 2012) من در مورد آسیب پذیری های اساسی فاجعه بار در سیستم های DNS صحبت کردم - استفاده از UDP (که برخلاف TCP/IP، ناامن است زیرا مکانیزم داخلی برای جلوگیری از جعل ندارد) و حافظه پنهان محلی.

بردارها

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

  • جعل TCP/IP و UDP - حملات در سطح حمل و نقل. به دلیل خطاهای اساسی در اجرای پروتکل های انتقال TCP و UDP، انواع حملات زیر امکان پذیر است:
    • جعل IP - ایده جایگزینی آدرس IP با تغییر مقدار فیلد منبع در بدنه بسته IP است. برای جعل آدرس مهاجم، به عنوان مثال، به منظور ایجاد یک بسته پاسخ به آدرس مورد نظر استفاده می شود.
    • جعل ARP یک تکنیک حمله در شبکه های اترنت است که به شما امکان می دهد ترافیک بین هاست ها را رهگیری کنید. بر اساس استفاده از پروتکل ARP؛
    • DNS Cache Poisoning - مسمومیت کش DNS سرور.
    • جعل NetBIOS/NBNS بر اساس ویژگی های حل نام ماشین های محلی در شبکه های مایکروسافت است.
  • جعل ارجاع دهنده - جایگزینی ارجاع دهنده.
  • مسمومیت شبکه های اشتراک گذاری فایل - فیشینگ در شبکه های اشتراک گذاری فایل.
  • جعل شناسه تماس گیرنده - جایگزینی شماره تلفن تماس گیرنده در شبکه های VoIP
  • جعل آدرس ایمیل - جایگزینی آدرس ایمیلفرستنده.
  • جعل GPS - جایگزینی بسته های ماهواره ای به منظور گیج کردن دستگاه GPS.
  • جعل پست صوتی - جایگزینی اعداد پست صوتیبه منظور فیشینگ رمزهای عبور قربانی.
  • جعل اس ام اس یک روش جعل است که بر اساس جایگزینی شماره فرستنده یک پیام کوتاه است.
  • آخرین تحولات در زمینه جعل

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

    فلمر و جعل مفتضح گواهینامه های مایکروسافت

    مشاوره امنیتی مایکروسافت (2718704) - گواهی‌های دیجیتال غیرمجاز می‌توانند به جعل اجازه دهند. کافی نکته جالبدر نسخه هایی از ربات جاسوسی پر سر و صدا Flamer پیدا شد: بر اساس نتایج مهندسی معکوس اجزای این بدافزار، بخشی از کد کشف شد که مسئول انجام حملات جعل مانند فیشینگ بود. این ربات با تقلید از ارائه گواهینامه های اصلی از شرکت های بزرگ، یک حمله MITM را انجام داد که هدف آن رهگیری اطلاعات شخصی کاربران بود. شبکه شرکتیبا ارسال بعدی به سرور توسعه دهندگان. این حادثه جعل، مشاوره امنیتی #2718704 را با درجه شدت بالا دریافت کرد.

    جعل در سیستم عامل 1. جعل پسوند - جعل پسوند فایل

    تکنیکی که به لطف پیشرفت های یک محقق چینی در این زمینه به چشم آمد امنیت اطلاعاتژیتائو ژو. ماهیت این تکنیک استفاده از کاراکتر کنترلی 0x202E (RLO) در نام فایل است که به شما امکان می دهد ترتیب کاراکترها را هنگام نمایش نام فایل در آن تغییر دهید. Windows Explorer(explorer.exe). در اینجا مثالی از استفاده از این تکنیک ساده آورده شده است:

    موسیقی فوق العاده آپلود شده تا ساعت 15.SCR

    فایل 3pm.SCR چیزی نیست جز یک فایل اجرایی که توابع خاصی را پیاده سازی می کند (یک برنامه تروجان - یادداشت ویرایشگر). اگر نویسه کنترلی 0x202E را در ابتدای نام فایل "3pm.SRC" وارد کنید (شکل 1 را ببینید)، ترتیب کاراکترها برعکس می شود و نام فایل به طور متفاوتی در Windows Explorer نمایش داده می شود:

    موسیقی فوق العاده بارگذاری شده توسط RCS.mp3

    برای تغییر نماد فایل، باید از هر ویرایشگر منبع (Restorator، Resource Hacker) استفاده کنید. این تکنیک برای یک کاربر بی دقت طراحی شده است که می تواند این فایل را با یک آهنگ اشتباه گرفته و با دوبار کلیک آن را باز کند و در نتیجه یک برنامه مخرب راه اندازی شود. متأسفانه، این تکنیک در برنامه های مشابه Explorer که از Unicode پشتیبانی می کنند، کار نمی کند. در زیر کد سی شارپ وجود دارد که نام فایل را با اضافه کردن کاراکتر کنترلی 0x202E تغییر می‌دهد:

    Public Sub U_202E(فایل به عنوان رشته، پسوند به عنوان رشته) Dim d به عنوان عدد صحیح = فایل. طول - 4 Dim u به عنوان Char = ChrW(823) Dim t به عنوان Char() = extension.ToCharArray() Array.Reverse(t) Dim dest As String = file.Substring(0, d) & u & New String(t) & file.Substring(d) System.IO.File.Move(file, dest) End Sub

    2. نام فایل جعل - شبیه سازی نام فایل

    این تکنیک توسط محقق ژاپنی یوسوکه هاسگاوا در کنفرانس Security-Momiji ارائه شد. این مبتنی بر استفاده از کاراکترهای با طول صفر است (کاراکترهای ZERO WIDTH)، که به هیچ وجه بر نمایش نام فایل تأثیر نمی گذارد (شکل 2 را ببینید). در زیر تمام شخصیت های این دسته را مشاهده می کنید:

    U+200B (ZERO WIDTH SPACE) - U+200C (ZERO WIDTH NON-JOINER) - U+200D (ZERO WIDTH Joiner) - U+FEFF ( صفر عرض بدون فاصله) - U+202A (از چپ به راست جاسازی)

    علاوه بر این، امکان استفاده از رمزگذاری UTF برای جعل نام فایل های موجود وجود دارد. این تکنیک اغلب توسط بدافزارهای مدرن استفاده می شود. من با نمونه هایی از بدافزار مواجه شدم که این نوع حمله را انجام می دادند. برای مثال، بدافزار TrojanDropper:Win32/Vundo.L (که برای فیشینگ سایت‌های vk.com، vkontakte.ru، *odnoklassniki.ru استفاده می‌شود) دقیقاً از این تکنیک استفاده می‌کند.


    فایل %SystemRoot%\system32\drivers\etc\hosts در فایل hosts "clone" با کاراکتر "o" UTF (0x043E) کپی شد و پس از آن نسخه اصلی فایل میزبانیک صفت داده شد فایل مخفیو مطالب آن با افزودن مطالب زیر بازنویسی شد:

    92.38.66.111 odnoklassniki.ru 92.38.66.111 vk.com 92.38.66.111 vkontakte.ru


    جعل مرورگر وب 1. نوار وضعیت / جعل پیوند

    اصل این حمله این است که به صورت پویا آدرس یک پیوند ابرمتن را جعل کند ( ). به عنوان مثال، قربانی نشانگر ماوس را روی یک پیوند می‌برد و پس از آن نوار وضعیت مرورگر آدرسی را که پیوند به آن منتهی می‌شود نمایش می‌دهد. پس از کلیک بر روی پیوند، کد جاوا اسکریپت فریبنده جایگزین آدرس انتقال در پویا می شود. محققی که من می شناسم، که با نام مستعار iamjuza شناخته می شود، در حال مطالعه و توسعه یک PoC برای استفاده از این تکنیک در عمل بود، اما پیشرفت های او جهانی نبود و فقط روی مرورگرهای خاص کار می کرد. پس از انجام یک مطالعه مشابه، من به نتایج بهتری دست یافتم و توانستم به عملکرد جهانی این تکنیک spoofer برای همه موتورهای مرورگر دست یابم. Proof-of-Concept منتشر شده در 1337day.com. پیاده سازی فنی به صورت زیر است:

    روش this.href=" :