ذخیره‌سازی ناامن داده: وقتی که اطلاعات حساس بصورت Clear-Text ذخیره می‌شوند.
وقتی اسم ذخیره‌سازی نا امن داده‌ها رو می‌شنویم، ناخودآگاه به این فکر می‌کنیم که ممکنه کسی به اطلاعات شخصی و حساب کاربری ما توی گوشیمون دسترسی پیدا کنه. خب قطعا این جالب نیست و با شنیدنش استرس می‌گیریم. این استرس رو دولوپرها هم زمانی که کدشون توسط ما Reverse میشه هم دارن. که اگه خوش‌شانس باشیم، می‌تونیم از توش Stringهایی رو پیدا کنیم که ممکنه برای اون کمپانی گرون تموم بشه (مثل کلید API، آدرس IP سرور، آدرس پنل مدیریتی تحت وب و ...)
همین مفهومی که الان فهمیدین، اسم یه آسیب‌پذیری هست به نام Insecure Data Storage، توی دستگاه‌هایی که هرروز با خودمون حمل می‌کنیم. از قضا این آسیب‌پذیری توی لیست 10 آسیب‌پذیری خطرناک متدولوژی OWASP هم هست. پس آسیب‌پذیری با اهمیتی هست و جا داره که توی محیط عملیاتی بیشتر بررسیش کنیم و یکی از بانتی‌هایی که من گرفتم رو باهم ببینیم.
قبل از این که شروع کنیم، باید اپلیکیشنی که روش می‌خوایم کار کنیم رو مشخص کنیم. توصیه‌ی اکید می‌کنم که از اپلیکیشن‌های ساده‌تر و یا اپلیکیشن‌هایی که دارای امتیاز کمتری هستند، شروع کنید که انگیزتون رو در حین فرآیند تست از دست ندید (اگه اول کار هستین). مثلا برای شروع، اپلیکیشن‌های جدیدی که تازه معروف شدن، انتخاب خوبی هستش و اغلب تو هر اپ استوری که جستجو کنید، میتونید اپلیکیشن هدف خاص خودتون رو پیدا کنید.
خب من روی اپلیکیشنی
مربوط به یکی از برنامه‌های بانتی پلتفرم HackerOne بود، تحلیل‌هام رو شروع کردم. نکته دیگه‌ای که برای کوتاه شدن این مقاله باید بگم اینه که ما به طور خاص دنبال کلید
API Key گوگل هستیم. وگرنه همه می‌دونیم که اپلیکیشن‌ها حاوی اطلاعاتی هستند که برای ما ارزشمندن و بررسی همه‌ی اون‌ها از حوصله‌ی این مقاله خارجه. حالا چرا google api key ؟ چوناستفاده از سرویس‌های گوگل در اپلیکیشن‌های مختلف خیلی متداوله و زیاد دیده میشه.. برای بررسی آسیب‌پذیری‌هایی از این نوع توصیه میشه تو گام اول فایل apk دانلود‌شده رو به وسیله Jadx باز کنیم. نکته خیلی مهمی که وجود داره، اینه که هم رشته‌های حیاتی و هم رشته‌های بی‌اهمیت، معمولا تو دو تا فایل ذخیره شدن. فایل strings.xml و فایل AndroidManifest.xml. تو عکس پایین فایل strings.xml رو می‌بینیم.
خب همون‌طور که مشاهده می‌کنید، کلید API گوگل پیدا شد. اما حالا ممکنه براتون سوال پیش بیاد که این کلید به چه دردی می‌خوره !
من برای چک کردن اینکه این کلید معتبر هست یا نه و اینکه چه کارهایی میشه با این API Key کرد، از ابزار KeyHacks استفاده کردم ( این ابزار رو میتونید از این لینک دانلود کنید). از این ابزار هم توی تست اپلیکیشن‌های موبایل میتونید استفاده کنید و هم توی تست وب اپلیکیشن‌ها. در نهایت به خروجی زیر رسیدم:
البته عبارتی که مشاهده می‌کنیم، Response مطلوب ما نیست و شاید فکر کنید به همین زودی به بن‌بست رسیدیم. به طور قطع محدودیتی که در این لایه وجود داره، به درخواست ارسالی ما به سرور مربوط میشه. یعنی محدودیتی که روی IP ما به وجود آوردن. خب تو این مرحله من با استفاده از headerهای مختلفی که وجود داشت، سعی کردم این محدودیت IP رو دور بزنم ولی موفق نبودم.
فکر دیگه ای که به نظرم رسید این بود که ممکنه نیاز به یکسری Headers در درخواست باشه و با اضافه کردنش بتونیم از این محدودیت بگذریم و سمت سرور احراز هویت بشیم. در این مرحله در کد جاوای دیکامپایل شده
غرق شدم و با دقت به دنبال رشته‌هایی که در ابتدا از عبارت X-something استفاده کردند، گشتم. همون‌طور که تو شکل زیر می‌بینید در نتیجه‌ی این بررسی، به جواب خوبی رسیدم.
با بررسی کد این اپلیکیشن، مطابق شکل بالا مشخص شد که دو header به نام‌های X-Android-Cert و X-Android-Package در همان درخواست ارسال می‌شوند. پس ما تونستیم تو این مرحله ساختار درخواست ارسالی به سمت سرور رو پیدا کنیم. الان تنها باید مقادیر این هدر ها رو بدرستی کنیم. در فیلد X-Android-Cert باید hash گواهینامه اپلیکیشن رو قرار بدیم. این مورد رو از کجا پیدا کنیم؟ کار سختی نیست، فقط باید محتوای فایل CERT.RSA در پوشه‌ی /META-INF رو مثل شکل زیر، به وسیله‌ی ابزار keytool استخراج کنید.
هدر دوم هم، همون‌طور که از اسمش مشخصه، package name اپلیکیشن رو باید وارد کنیم. یعنی قالبی مثل com.something.app که در فایل AndroidManifest.xml وجود داره.
بعد از ارسال دوباره درخواست با ساختار جدید، بلاخره response معتبر برام ارسال شد و از قضا پنل وبی بود که همه اطلاعات مربوط به session های کاربر توش ذخیره شده بود. در نهایت بعد از گزارش این آسیب پذیری موفق شدم 450 دلار بانتی بگیرم.
