مروری بر حملات برنامه های اندروید

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

معرفی برنامه های اندروید

مدل سازی تهدید برای برنامه های موبایل

مرور اجمالی بر ده آسیب پذیری برتر موبایل طبق OWASP

مقدمه ای بر ابزارهای خودکار برای ارزیابی برنامه های اندروید

مروری بر حملات برنامه های اندروید

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

معرفی برنامه های اندروید

مروری بر حملات برنامه های اندروید

برنامه های اندروید بر اساس نحوه توسعه آنها به سه نوع تقسیم می شوند:

برنامه های مبتنی بر وب

برنامه های بومی (native)

برنامه های ترکیبی (hybrid)

برنامه های مبتنی بر وب

یک برنامه وب تلفن‌همراه، برنامه ای است که با تکنولوژی های وب مانند JavaScript یا HTML5 برای ارائه تعامل، هدایت یا قابلیت سفارشی سازی توسعه یافته است. برنامه های مبتنی بر وب در یک مرورگر وب دستگاه تلفن همراه اجرا می شوند و با درخواست صفحات وب از سرور ارائه می شوند.

مروری بر حملات برنامه های اندروید

برنامه های بومی

مروری بر حملات برنامه های اندروید

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

برنامه های ترکیبی

مروری بر حملات برنامه های اندروید

برنامه های ترکیبی سعی می کنند از هر دو برنامه های بومی و برنامه های وب استفاده کنند، برروی دستگاه مانند یک برنامه بومی اجرا می شوند و با تکنولوژی های وب (HTML5، CSS و جاوا اسکریپت) نوشته می شوند. برنامه های ترکیبی در یک قالب بومی اجرا می شود و موتور مرورگر دستگاه (و نه مرورگر) را برای استفاده از HTML و پردازش جاوااسکریپت به صورت محلی استفاده می کنند. لایه انتزاعی وب به بومی اجازه دسترسی به قابلیت های دستگاه را می دهد که در برنامه های تلفن همراه وب مانند شتاب سنج، دوربین و حافظه محلی قابل دسترسی نیست. معمولا این نوع برنامه ها با استفاده از چارچوب هایی نظیر PhoneGap، React Native و غیره توسعه داده می شوند. با این حال، سازمان هایی که قالب خود را ایجاد می کنند، غیر معمول نیستند.

درک سطح حمله برنامه

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

معماری برنامه تلفن همراه

مروری بر حملات برنامه های اندروید

توصیه می شود که در هنگام توسعه نرم افزار، فرآیند SDLC امن را دنبال کنید. بسیاری از سازمان ها این روش از SDLC را برای اجرای امنیت در هر مرحله از فرآیند چرخه حیات تولید نرم افزار در نظر می گیرند.
چرخه حیات تولید نرم افزار امن (SDLC)یک روش برای کمک به سازمان ها برای ایجاد امنیت در محصولات خود، از ابتدای فرآیند تولید می باشد. پیاده سازی SDLC با کاهش تلاش هایی که در حل مسائل در طول دوره های تعمیر و نگهداری انجام می شود، بهره وری را افزایش می دهد.
همانطوریکه می توانیم در نمودار زیر از سند فرآیند SDLC از Microsoft مشاهده کنیم، هر مرحله از SDLC شامل حداقل یک فعالیت امنیتی است که در تأمین امنیت برنامه کمک می کند. هر سازمان در تعبیه امنیت در SDLC و همچنین هدف آن متفاوت است. با این حال، موارد زیر می تواند شروع خوبی برای سازمان هایی باشد که می‌خواهند این روش را در نظر بگیرند:

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

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

تحلیل پویا:   تحلیل پویا در مرحله تأیید فرآیند SDLC انجام می شود. تحلیل پویا یک روش برای پیدا کردن مسائل در برنامه ی در حال اجرا می باشد که می تواند به سازمان ها در شناخت وضعیت امنیتی برنامه های خود قبل از استقرار کمک کند.

مروری بر حملات برنامه های اندروید

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

داده های مانای برنامه: با معرفی برنامه های تلفن همراه، مفهوم ذخیره داده ها در سمت مشتری به طور گسترده فراگیر شده است. بسیاری از برنامه های تلفن همراه اطلاعات حساس را در دستگاه بدون رمزنگاری ذخیره می‌کنند. این یکی از مشکلات عمده برنامه های موبایل است. این داده ها می توانند حساس، محرمانه و خصوصی باشند. داده هایی که برروی دستگاه قرار می گیرند می توانند از طریق روش های مختلف مورد سوء استفاده قرار گیرند. مهاجم دارای دسترسی فیزیکی به دستگاه می تواند بدون هیچ کاری به این اطلاعات دسترسی داشته باشد. یک برنامه مخرب ممکن است در صورتی که دستگاه rooted/jailbroken باشد، به این داده‌ها دسترسی پیدا کند. مهم این است که اطمینان حاصل کنید که برنامه ها اطلاعات شخصی حساس مانند نام کاربری، گذرواژه، نشانگر تأیید هویت، شماره کارت اعتباری و امثالهم را در دستگاه ذخیره نمی‌کنند. اگر نتوان از انجام آن اجتناب کرد، لازم است آن را رمزگذاری نموده و از کنترل مهاجم دور نگه داریم.

داده های در حال انتقال برنامه:برنامه های موبایل که با backend ارتباط برقرار می‌کنند، با احتمال بالایی در معرض حملاتی هستند که داده های در حال انتقال را هدف قرار می دهند. به طور معمول کاربران نهایی به شبکه های عمومی موجود در کافی شاپ ها و فرودگاه ها می‌پیوندندکه ممکن است مهاجم بتواند از طریق ابزارهایی مانند پروکسی burp، پروکسی MITM، پروکسی SSL MitM و امثال آنها استراق سمع کند. با معرفی برنامه های تلفن هوشمند، بهره برداری از چنین حملاتی بسیار آسان می شود زیرا تلفن های همراه هر جا که می‌رویم ما را دنبال می‌کنند.

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

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

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

تهدیدها در پشت صحنه

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

احراز هویت و کنترل دسترسی:هنگام ایجاد API backend ها، ایجاد یک مکانیزم احراز هویت سفارشی رایج است. بنابراین ممکن است آسیب پذیری های مرتبط با احراز هویت یا کنترل دسترسی وجود داشته باشد.

 

مدیریت نشست:مدیریت session در سیستم عامل های تلفن همراه معمولا با استفاده از یک شناسه احراز هویت (authentication) انجام می شود. هنگامی که کاربر برای اولین بار وارد سیستم می شود ، به او یک توکن احراز هویت داده می شود که برای ادامه‌ی session استفاده می‌شود. اگر این نشانگر احراز هویت تا زمان از بین رفتن نشست به درستی محافظت نشود، ممکن است منجر به حمله گردد. از بین بردن نشست کاربر در سمت سرویس گیرنده، نه در سرور، مشکل دیگری است که در برنامه های تلفن همراه دیده می‌شود.

اعتبارسنجی ورودی: اعتبارسنجی ورودی یک مسئله شناخته شده و رایج است که در برنامه ها مشاهده می کنیم. اگر هیچ کنترلی برروی اعتبار ورودی اجرا نشود، ممکن است آسیب پذیری‌های SQL injection، Command Injection و Cross Site Scripting وجود داشته باشند.

اداره‌ی خطا نامناسب:خطاها برای مهاجمان جذاب هستند. اگراداره‌ی خطا به درستی انجام نشود و API خطاهای پایگاه داده / سرور را بطور خاص برای درخواست ایجاد شده بفرستد، می‌توان حملات را با استفاده از آن خطاها انجام داد.

رمزنگاری ضعیف:رمزنگاری قسمت دیگری است که توسعه دهندگان در هنگام توسعه خود مرتکب اشتباه می‌شوند. اگر چه هر پلتفرمی از پیاده سازی مناسبی برای امن سازی داده‌ها به صورت رمزنگاری شده پشتیبانی می کند، مدیریت کلید یک مسئله مهم در سمت مشتری است. به طور مشابه، ذخیره سازی داده ها در backend نیاز به ذخیره سازی امن دارد.

حمله به پایگاه داده: مهاجمان ممکن است مستقیما دسترسی غیرمجاز به پایگاه داده داشته باشند. برای مثال اگر کنسول پایگاه داده مانند phpMyAdmin، با اعتبار قوی امن نشده باشد ممکن است مهاجم دسترسی غیرمجاز به آن پیدا کند. یک مثال دیگر می‌تواند دسترسی به کنسول MongoDB غیرقابل اعتبار باشد؛ زیرا نصب MongoDB بطور پیش فرض نیازی به احراز هویت برای دسترسی به کنسول خود ندارد.

دستورالعمل هایی برای تست و نگهداری برنامه های تلفن همراه

سازمان های متعددی هستند که دستورالعمل هایی را برای تست و امن سازی برنامه های تلفن همراه ارائه می دهند. رایج ترین آنها عبارتند از OWASP Mobile Top10 و Veracode Mobile App Top10 . علاوه بر این، دستورالعمل هایی از خود گوگل نیز درباره نحوه محافظت از برنامه های اندروید با نشان دادن نمونه هایی از آنچه انجام نمی شود، وجود دارد. داشتن اطلاعات در مورد این دستورالعمل ها مهم است تا بدانید چه چیزی در طول آزمون نفوذ باید جستجو شود.
حال نگاه کوتاهی به آسیب پذیری های OWASP Mobile Top10 خواهیم داشت.

خطرات موبایل در OWASP Top10

نمودار زیر خطرات موبایل در OWASP Top10 را نشان می دهد که فهرستی از ده آسیب پذیری اصلی برنامه های تلفن همراه را ارائه می دهد.

مروری بر حملات برنامه های اندروید

در زیر 10 آسیب پذیری برتر بیان شده و ما نگاهی عمیق تر به هر یک از این آسیب پذیری ها در بخش های زیر خواهیم داشت.

M1: ضعف کنترل های سمت سرور

M2: ذخیره ناامن داده ها

M3: حفاظت ناکافی لایه انتقال

M4: نشتی ناخواسته داده ها

M5: احراز هویت و کنترل دسترسی نامناسب

M6: رمزنگاری شکسته

M7: تزریق سمت مشتری

M8: تصمیمات امنیتی توسط ورودی‌های نامطمئن

M9: اداره کردن نامناسب نشست کاربر

M10: فقدان محافظهای باینری

M1: ضعف کنترل های سمت سرور

کنترل های ضعیف سرور به مساله حملات برروی backend نرم افزار می پردازند. اکثر برنامه ها امروزی از اتصال به اینترنت استفاده می کنند و با استفاده از API های REST یا SOAP با سرورهای backend ارتباط برقرار می‌کنند. اصول امنیتی مرتبط با وب سرورها و برنامه های کاربردی وب یکسان است، چرا که صرفا frontend برنامه (از نوع موبایل) فرق می کند و backend همچنان یکسان است. مسیرهای معمول حمله عبارتند از: شناسایی نقاط ورود در API های عرضه شده و فازی کردن آن ها برای آسیب پذیری های مختلف، بهره برداری از سرورهای بد پیکربندی شده و غیره. تقریبا تمام آسیب پذیری های OWASP top 10 به این بخش اعمال می شود.

M2: ذخیره ناامن داده ها

توسعه دهندگان فرض می کنند که اطلاعات ذخیره شده در یک سیستم فایل دستگاه توسط مهاجمان قابل دسترسی نیست. با این فرض، توسعه دهندگان اغلب داده های حساس مانند نامهای کاربری، توکن‌های احراز هویت، گذرواژه ها، PINها و اطلاعات شخصی مانند DOB و آدرسها را در یک سیستم فایل دستگاه با استفاده از مفاهیمی مانند تنظیمات مشترک یا پایگاه های SQLite ذخیره می‌کنند. چندین روش برای دسترسی به این داده ها که به صورت محلی بر روی یک دستگاه ذخیره می شوند وجود دارد. از جمله تکنیک های رایج، root کردن به دستگاه و دسترسی به داده ها، استفاده از حملات مبتنی بر پشتیبان و غیره است.

M3: حفاظت ناکافی لایه انتقال

همانطوریکه می توان در نمودار قبلی مشاهده کرد، حفاظت نامناسب از لایه انتقال در رتبه 3 قرار دارد. همانند برنامه های کاربردی وب، برنامه های موبایل ممکن است اطلاعات حساس را از طریق شبکه های ناامن انتقال دهند که این امر ممکن است به حملات جدی منجر شود. این مساله در کافی شاپ ها و فرودگاه ها برای دسترسی به Wi-Fi های رایگان بسیار رایج است که در آن مهاجمان مخرب می‌توانند حملات MITM را برای سرقت اطلاعات حساس از کاربران در شبکه انجام دهند.
هنگام انجام تست نفوذ برروی برنامه های تلفن همراه، ممکن است سناریوهایی وجود داشته باشد که در آن برنامه اسناد یا توکن های نشست کاربر را بر روی شبکه انتقال دهد. بنابراین، همیشه یک ایده خوب تجزیه و تحلیل ترافیک برنامه است تا ببینید که آیا اطلاعات حساس در شبکه انتقال می یابد یا خیر. یک سناریوی مهم دیگر وجود دارد که اکثر برنامه ها نسبت به آن آسیب پذیر هستند. اگر یک برنامه در حال انجام احراز هویت در HTTPS و ارسال کوکی های احراز هویت از طریق HTTP باشد، این برنامه آسیب پذیر است زیرا مهاجم به راحتی می تواند کوکی های احراز هویت را از طریق HTTP منتقل کند و این کوکی ها به عنوان نام کاربری و رمز عبور برای ورود به برنامه کاربردی است. همچنین عدم تأیید گواهی‌نامه و مذاکره با handshake ضعیف، مشکلات رایج در امنیت لایه انتقال است.

M4: نشتی ناخواسته داده ها

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

نشتی ارائه دهندگان محتوا

کپی / پاک کردن حافظه بافر

ثبت نام

ذخیره URL

اشیاء کوکی مرورگر

تجزیه و تحلیل داده های ارسال شده به اشخاص ثالث

M5: احراز هویت و کنترل دسترسی نامناسب

برنامه های موبایل و همچنین دستگاه ها، فاکتورهای قابلیت استفاده متفاوتی از آنچه که در برنامه های وب سنتی و لپ‌تاپ ها وجود دارد، دارند. به دلیل فاکتور فرم ورودی دستگاه تلفن همراه، اغلب لازم است که PIN ها و گذرواژه های کوتاه داشته باشید. الزامات به علت الزامات دسترسی پذیری، نیازمندیهای احراز هویت برای برنامه های تلفن همراه می تواند کاملا متفاوت از طرح های احراز هویت وب سنتی باشد. چنانچه هیچ کنترلی برای جلوگیری از چنین حملاتی اعمال نشود، برای یک حمله کننده بسیار آسان خواهد بود تا این PIN های کوتاه را از طریق brute force در برنامه پیدا کند. می توانیم برنامه های با کنترل دسترسی ضعیف را، با تلاش برای بدست آوردن دسترسی بیشتر به توابع برنامه توسط ایجاد درخواست های مخرب و ارسال آن به سرور و بررسی اینکه آیا این درخواست‌ها پاسخ داده می‌شوند یا نه، تست کنیم.

M6: رمزنگاری شکسته

حملات رمزنگاری زمانی رخ می دهند که توسعه دهنده برنامه می خواهد از رمزگذاری در برنامه خود استفاده کند. رمزنگاری شکسته در برنامه های اندروید می تواند به دلایل مختلف روی دهد. دو دلیل عمده در پروژه OWASP Mobile Top 10 ذکر شده است:

استفاده از یک الگوریتم ضعیف برای رمزگذاری / رمزگشایی:  شامل استفاده از الگوریتم هایی با نقاط ضعف قابل توجه است. در غیر این صورت برای مقاصد امنیتی مدرن مانند DES و DES3 کافی نیست

استفاده از یک الگوریتم رمزنگاری قوی اما اجرای آن به روش ناامن: شامل ذخیره کلید در فایل های پایگاه داده محلی، hardcoding کلید در منبع و غیره.

M7: تزریق سمت مشتری

تزریق سمت مشتری موجب اجرای کد مخرب در دستگاه تلفن همراه از طریق برنامه موبایل می شود. این کد مخرب معمولا به صورتی از اطلاعات ارائه می شود که عامل تهدید به برنامه های تلفن همراه از طریق روشهای مختلف وارد می‌کند. در زیر برخی از نمونه هایی از حملات تزریق سمت مشتری در برنامه های اندروید آورده شده است:

تزریق در WebViews

تزریق سنتی SQL در دستورات خام SQL با استفاده از پایگاه داده SQLite

تزریق SQL در ارائه دهندگان محتوا

پیمایش مسیر در ارائه دهندگان محتوا

M8: تصمیمات امنیتی توسط ورودی‌های نامطمئن

وسعه دهندگان همیشه باید فرض کنند که ورودی های بد فرم می‌تواند توسط افراد غیر مجاز برای سوء استفاده از توابع حساس برنامه وارد شود. به طور خاص در اندروید، مهاجم می تواند تماس ها (تماس های IPC یا سرویس های وب) را متوقف کند و از پارامترهای حساس استفاده کند. پیاده سازی ضعیف این قابلیت ها منجر به رفتار نادرست برنامه می شود و حتی می تواند مجوز های سطح بالاتری را به مهاجم اعطاء کند. یک مثال می‌تواند درخواست فعالیتهای حساس با اهداف ناهنجار باشد.

M9: اداره کردن نامناسب نشست کاربر

برنامه های موبایل از پروتکل هایی مانند SOAP یا REST برای اتصال به سرویس‌ها استفاده می کنند که stateless هستند. هنگامی که یک برنامه سرویس گیرنده تلفن همراه با این پروتکل ها استفاده می شود، مشتریان پس از احراز هویت یک توکن از سرور دریافت می کنند. توکن تولید شده توسط سرور در session کاربر استفاده می شود. OWASP's Improper Session Handling درباره حمله و تأمین امنیت این session ها است. یک مشکل رایج که اغلب در برنامه های تلفن همراه مشاهده می شود، توکن نامعتبر در سمت مشتری و نه در سمت سرور است. توکن دریافت شده توسط برنامه معمولا با استفاده از تنظیمات مشترک یا پایگاه داده SQLite در سیستم فایل مشتری قرار می گیرد. یک کاربر مخرب که دسترسی به این توکن ها داشته باشد، تازمانیکه توکن در سمت سرور نامعتبر نشده باشد، می تواند از آنها استفاده کند. دیگر سناریوهای ممکن عبارتست از مدت زمان اعتبار session، ایجاد توکن ضعیف و توکن منقضی شده.

M10: فقدان محافظهای دودویی

مهندسی معکوس یکی از شایع ترین مشکلات موجود در اکثر برنامه های اندروید است. یکی از اولین گام های مهاجم هنگامی که یک برنامه باینری را دریافت می کند،decompile یا disassemble کردن آن است. این امر به مهاجم اجازه می دهد تا موارد پنهان hardcoded را مشاهده کند، آسیب پذیری ها را پیدا نموده و حتی عملکرد برنامه را با بسته بندی دوباره برنامه های disassemble شده تغییر دهد. اگرچه obfuscate کردن کد منبع کار سختی نیست، اما به نظر نمی‌رسد اکثریت برنامه‌ها این کار را انجام دهند. هنگامی که کد obfuscate نیست، تنها نیاز مهاجمین یک ابزار خوب مانند apktool یا dex2jar برای انجام کار است. برخی از برنامه ها دستگاه های root شده را بررسی می کنند که می‌توان این بررسی ها را از طریق معکوس کردن برنامه یا با دستکاری جریان برنامه با اتصال به آن دور زد.

ابزارهای خودکارسازی

ابزارهای خودکارسازی اغلب در مدت زمان انجام تست نفوذ صرفه جویی می کنند. در زیر برخی از رایج ترین ابزارهای خودکار که برای ارزیابی برنامه های اندروید در دسترس هستند، آورده شده است:

Drozer و Quark دو ابزار مختلف هستند که ممکن است در زمان ارزیابی برنامه Android شما مفید باشند.




شرکت مهندس پیشگان آزمون افزار یاس، ابزارهای پیشرفته زیر را در حوزه تست نفوذ اندروید ارائه می دهد:

Jtest

Checkmarx

WebInspect


نویسنده : شرکت مهندس پیشگان آزمون افزار یاس


مراجع

[1]-Hacking Android, by By Srinivasa Rao Kotipalli and Mohammed A. Imran, 2016

نوشتن دیدگاه

تصویر امنیتی
تصویر امنیتی جدید