SDK Spoofing و راه‌های مقابله با آن در Open-Source SDK و Closed-Source SDK
SDK Spoofing یکی از مهمترین انواع تقلب‌های موبایلی است و این سوال که چگونه Open-Source SDKها خود را در برابر این نوع از تقلب ایمن می‌کنند برای فعالین صنعت تبلیغات موبایلی بسیار حائز اهمیت است. در این مقاله کوتاه، ما در مورد چگونگی حفظ امنیت داده‌ها در Open-Source SDKها صحبت میکنیم و مقایسه کوتاهی بین Closed-Source SDKها و Open-Source SDKها از لحاظ امنیت اطلاعات و امکان جلوگیری از تقلب خواهیم داشت.
اگر نمی‌دانید SDK Spoofing چیست، در ادامه سعی کرده‌ایم این مفهوم را به صورت مفصل توضیح دهیم.
شبکه‌های تبلیغاتی که از این نوع تقلب استفاده می‌کنند معمولا یک بد افزار (اپلیکیشن دیگری که روی موبایل تعداد زیادی از کاربرها نصب شده است) دارند و هنگامی که یک اپلیکیشن خاص تبلیغات گسترده‌ای را برای مدتی نسبتا طولانی انجام می‌دهد بدافزار موجود در موبایل‌های مختلف شروع می‌کند به دنبال کردن اطلاعاتی که از طریق اپلیکیشن (و Tracker داخل آن) به سرورهای Tracker ارسال می‌شوند. تا پس از مدتی بتوانند این داده‌ها را رمز گشایی کنند و پس از آن سعی کنند با تولید داده‌های جعلی و ارسال آن به Tracker هدف کاری کنند که اعداد نصب یا هر Event دیگری که برایشان سود دارد را افزایش دهند.
اگر این فرایند به درستی انجام شود، برای شبکه متقلب این امکان ایجاد می‌شود که تعداد نامحدودی از تقلب (که معمولا شبیه‌سازی یک رفتار خاص کاربر هستند) را به آمار واقعی اضافه کنند، بدون آنکه برنامه واقعی روی گوشی موردنظر وجود داشته باشد.
امروزه کلاهبرداران می‌توانند شناسه دستگاه واقعی را شناسایی نمایند، این بدان معناست که اگر شما از کد رمزنگاری شبکه Tracker (Cryptograph Signature) استفاده نکنید شبکه متقلب می‌تواند داده‌های جعلی را جایگزین داده واقعی کند. متخصصین امنیت ادجاست در مقاله خود بیشتر در مورد این ایده صحبت می‌کنند.
ادجاست (Adjust) اعتقاد دارد مشتریانش شایسته این هستند که بدانند در اپلیکیشن‌شان چه می‌گذرد. همچنین استفاده از Open-Source SDK این امکان را فراهم می‌کند که در پایدارترین حالت ممکن بتواند با ارائه داده‌های مطمئن به تیم‌های مارکتینگ به بیشترین تعداد مشتریان خدمات ارائه دهد و از هدر رفتن بودجه تبلیغات جلوگیری کند. در ادامه به تعدادی از دلایلی اشاره میکنیم که چرا SDKهای Open-Source بر SDKهای Close-Source اولویت دارد.
چگونه SDK Adjust ایمن است؟
به منظور دنبال نمودن (Track) با استفاده از Adjust. هر مشتری با پیاده‌سازی و تنظیم SDK در برنامه خود شروع به کار می‌کند. اما برای محافظت از مشتری‌های خود در مقابل کلاهبرداری. به مشتریان این امکان را می‌دهیم.تا یک کتابخانه جداگانه را ایجاد نموده و آن را به SDK متصل کنند. بدون این کتابخانه، SDK امن نیست و ما داده‌های آنها را نمی‌پذیریم.
این کتابخانه یک امضای رمزنگاری (Cryptographic Signature) را ایجاد می‌کند که با هر بار درخواست و هر ارسال داده، به SDK ادجاست پیوست می‌شود. این نوع پیشگیری از تقلب بهترین مورد پیشگیری در برابر همه روش‌های شناخته شده‌ی جعل داده و حمله‌های تقلب است و توسط تیم متخصصان امنیتی ما به طور مداوم به روز می‌شود. هر کتابخانه دارای واحد متفاوتی است، به این معنی که اگر طی یک اتفاق به یک اپلیکیشن حمله شود و قصد اخلال و ایجاد تقلب وجود داشته باشد، بار دیگر همان روش حمله روی هیچ برنامه دیگری در جهان کار نمی‌کند. علاوه براین، کتابخانه توسط تیم امنیتی ما به طور مداوم به روز می‌شود، به این معنی که هرگونه تلاش جدید برای شکستن امنیت و ایجاد اختلال به سرعت ناکارآمد می‌شود.
کتابخانه با استفاده از الگوریتم‌های تولید داده‌های تصادفی تهیه شده و سپس در یک فرآیند ویژه تدوین می‌شود که به این معناست که یک مهاجم نمی‌تواند با استفاده از مهندسی معکوس کتابخانه را تولید کند.
آیا SDKهای Closed-Source ایمن هستند؟
بیشتر SDKهای اختصاصی دیگر منبع بسته (Closed-Source SDK) هستند و عملکردشان و اطلاعات رد و بدل شده را برای اپلیکیشنی که از این نوع از Trackerها استفاده می‌کنند مشخص نمی‌کنند. آیا این باعث می‌شود امنیت بیشتری پیدا کند؟
پاسخ به این ادعا “نه” است.
در طول تحقیق ما در مورد جعل SDK ، ما SDKهای منبع بسته (Closed-Source SDK) را در بازار بررسی کردیم تا بدانیم که بدون امضای رمزنگاری (Cryptographic Signature) چقدر امن هستند. متأسفانه، ما متوجه شدیم که در هر مورد، عملکردی که آنها برای امضای (Sign) درخواست داده‌های خود استفاده می‌کردند، به راحتی قابل استخراج است و شکستن این کدها توسط انسان به راحتی قابل اجرا است که باعث می‌شود که اینکار (استخراج داده‌ها توسط هر فردی) بسیار آسان باشد.
در حقیقت، برای برخی از SDKها برای کارشناسان ما فقط چند دقیقه طول کشید تا بتوانند تابع امضای (Signing Function) را بیابند و Decode کنند و دسترسی خرابکاری در SDK را بدست آورند – به این معنی که در طی چند لحظه،SDK کاملاً بی‌حفاظ شده بود. این امر دارای پیامدهای بسیار جدی است، زیرا وقتی مهاجمی در یک لحظه این کار را انجام می‌دهد، می‌توانند از Signature استفاده کنند تا داده‌های جعلی را به صورت کاملاً واقعی جایگزین داده واقعی کنند و کاری کنند که این داده واقعی به نظر برسد.
به طور خلاصه، یک مهاجم می‌تواند به راحتی همه راه حل‌های منبع بسته (Closed-Source) موجود را فریب دهد.
کتابخانه‌های (Library) معمول که مشتریان به SDK خود اضافه می‌کنند نمی‌تواند تمامی کارکردهای (Function) یک Attribution SDK را پوشش دهد. بلکه تنها مجموعه محدودی از Functionهای مقابله با کلاهبرداری( بالاخص SDK Spoofing را شامل می‌شوند. این بدان معنی است که ما می‌توانیم از طریق روش‌های ادجاست این کتابخانه‌ها را ایمن‌تر بنویسیم، بهتر به به‌روزرسانی کنیم و پردازش موثرتری انجام دهیم.
در حالی که ما نمی‌توانیم تمام روش‌های مورد استفاده برای تأمین امنیت کتابخانه را به دلایل امنیتی فاش کنیم، این افتخار ما است که مشتری‌ها را با یکی از کارشناسان امنیت سایبری خود مرتبط میکنیم تا برای ایشان رفع ابهام نماییم.
و در انتها این گفته را باور نکنید که Open-Source SDK ایمن نیست. نمی‌تواند ایمن باشد و این ادعا که Closed-Source SDK نمی‌تواند جعل شود و همواره ایمن است.
ترجمه از بلاگ ادجاست
لینک ” https://www.adjust.com/blog/sdk-spoofing-open-source-vs-closed-source/
نوشته شده توسط لیلا مهربخش
