بررسی آسیب پذیری اپلیکیشن موبایل – بررسی لاگ برای داده های حساس

در پست قبل به نخستین مبحث در مورد بررسی ذخیره سازی داده های حساس پرداخته شد. حال در این پست به سرفصل MSTG-STORAGE-3 در خصوص بررسی لاگ اپلیکیشن های موبایل و به دست آوردن اطلاعات حساس برنامه در آنها نگاهی انداخت.

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

Log Class

Logger Class

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

۱- تحلیل ایستا

بررسی سورس کد برنامه برای مکانیسم های لاگ از طریق جستجو با عبارت‌های زیر انجام می‌گیرد:

توابع و کلاس ها:

android.util.Log

Log.d | Log.e | Log.i | Log.v | Log.w | Log.wtf

Logger

کلید واژه‌ها و خروجی سیستم:

System.out.print | System.err.print

logfile

logging

logs

برای نسخه تجاری می‌توان از ابزارهایی شبیه ProGuard جهت حذف کدهای لاگ و مبهم سازی کدها استفاده نمود تا کلاسها، متدها، لاگ‌های مرتبط با کد و فیلدهای بدون استفاده را حذف نماید. جهت اطمینان از پاک شدن خروجی کلاس android.util.Log، تنظیمات فایل پیکربندی (proguard-project.txt) را برای مقادیر زیر برررسی نمایید.

assumenosideeffects class android.util.Log
{
  public static boolean isLoggable(java.lang.String, int);
  public static int v(...);
  public static int i(...);
  public static int w(...);
  public static int d(...);
  public static int e(...);
  public static int wtf(...);
}

توجه کنید مثال بالا فقط تضمین می‌کند که فراخوانی‌ها برای متدهایLog class’  حذف خواهد شد. اگر string ی که در زمان اجرا ساخته شود،  کدی که string را می‌‌سازد ممکن است در بایت کد باقی بماند. برای مثال کد زیر جهت ساخت یک قطعه کد لاگ به کار می‌رود:

Log.v("Private key [byte format]: " + key);

کد لاگ زیر در زمان اجرا به صورت زیر ساخته خواهد شد:

Log.v(new StringBuilder("Private key [byte format]: ").append(key.toString()).toString());

ProGuard حذف فراخوانهای متد Log.v  را تضمین می‌کند. حذف مابقی کدها نیز وابسته به پیچیدگی کد و نسخه مورد استفاده ProGuard  دارد. این یک ریسک امنیتی است چون string بدون استفاده تبدیل به داده‌های متنی در حافظه میشود که می‌تواند از طریق دیباگر یا dump حافظه قابل دسترس باشد. متاسفانه راهکارهای خوبی برای این موضوع وجود ندارد و انتخاب‌های کمی در دسترس می‌باشد. یک راهکار پیاده سازی مکانیزم لاگ گیری شخصی سازی شده است و تنظیمات ProGuard را به نحوی تنظیم نمایید که این لاگ‌های را نادیده بگیرد:

SecureLog.v("Private key [byte format]: ", key);

۲- تحلیل دینامیک

همه‌ی تابع‌های موبایل حداقل یک بار در برنامه مورد تست بررسی کنید و مسیر داده‌ای برنامه‌ها را شناسایی کنید و فایل‌های لاگ )/data/data/<package-name>( را جستجو کنید. لاگ‌های برنامه را بررسی کنید تا مشخص شود آیا داده‌های لاگ تولید شده است یا خیر، برخی برنامه‌‌های موبایل لاگ‌ها را در مسیر داده های خود ذخیره کرده‌اند.

برخی برنامه‌ نویسها هنوز از System.out.println  یا  printStackTrace را به جای کلاس‌های لاگ مناسب استفاده می‌کنند. بنابراین استراتژی تست شما باید شامل همه‌ی خروجی‌های تولید شده مربوط به شروع و اجرا و بستن برنامه باشد. جهت تعیین اینکه چه داده‌هایی به وسیله‌ی System.out.println  یا  printStackTrace تولید می‌شود، می‌توانید از logcat استفاده کنید. شما می توانید Logcat را باadb  اجرا کنید تا خروجی لاگ را ذخیره کنید.

$ adb logcat > logcat.log

با دستور زیر می توانید خروجی لاگ برنامه مورد نظر را فقط با وارد کردن نام پکیج مشخص کنید.

$ adb logcat | FINDSTR "<package-name>"

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

منابع

راهنمای امنیتی تست موبایل OWASP.