Android Security: অ্যান্ড্রয়েড স্মার্টফোনের ডেটা হ্যাকারদের হাত থেকে কতটা নিরাপদ?

Android-এর নিরাপত্তা মডেল মূলত Linux kernel-এর উপর তৈরি, যেখানে প্রতিটি অ্যাপ্লিকেশন একটি স্বতন্ত্র Linux user-এর মতো আচরণ করে। এই কাঠামোকে বলা হয় Application Sandboxing। প্রতিটি অ্যাপ তার নিজস্ব UID (User ID) নিয়ে চলে এবং অন্য অ্যাপের ডেটায় সরাসরি প্রবেশ করতে পারে না, যদি না সেই অ্যাপ স্পষ্টভাবে শেয়ারিং অনুমতি দেয়।

এর উপরে রয়েছে Android Runtime (ART) যা Dalvik Executable (DEX) bytecode চালায় এবং SELinux (Security-Enhanced Linux) যা Mandatory Access Control (MAC) প্রয়োগ করে। SELinux প্রতিটি প্রক্রিয়া এবং ফাইলকে label দেয় এবং নির্দিষ্ট policy অনুযায়ী access নিয়ন্ত্রণ করে। এর ফলে কোনো অ্যাপ যদি কোনোভাবে privilege escalation-এর চেষ্টা করে, তবুও SELinux তাকে সীমাবদ্ধ পরিধির মধ্যেই আটকে রাখে।

আরেকটি গুরুত্বপূর্ণ স্তর হলো Verified Boot এবং Hardware-backed Keystore। Verified Boot নিশ্চিত করে যে boot process-এর প্রতিটি পর্যায় cryptographically signed এবং tampered নয়। অন্যদিকে Hardware-backed Keystore Trusted Execution Environment (TEE) বা Secure Element-এ encryption key সংরক্ষণ করে, যা main OS compromise হলেও সরাসরি extract করা যায় না।

Android-এর Permission Model হলো ব্যবহারকারীর গোপনীয়তা রক্ষার প্রথম প্রাচীর। Android 6.0 (Marshmallow) থেকে শুরু করে runtime permission চালু হয়েছে, যেখানে সংবেদনশীল permission যেমন camera, location, contacts, SMS ইত্যাদির জন্য অ্যাপকে চলাকালীন সময়ে স্পষ্ট অনুমতি চাইতে হয়।

Permission মূলত তিনটি protection level-এ ভাগ করা হয়—Normal, Dangerous, এবং Signature। Normal permission যেমন INTERNET, ACCESS_NETWORK_STATE স্বয়ংক্রিয়ভাবে দেওয়া হয়। Dangerous permission যেমন READ_CONTACTS, ACCESS_FINE_LOCATION ব্যবহারকারীর সম্মতি লাগে। Signature permission শুধু একই developer signature-যুক্ত অ্যাপের মধ্যে শেয়ার করা যায়।

কিন্তু Permission Model-এর সবচেয়ে বড় চ্যালেঞ্জ হলো ব্যবহারকারীর সচেতনতা। বেশিরভাগ ব্যবহারকারী না পড়েই permission প্রদান করেন, এবং অনেক malicious app এই প্রবণতাকে exploit করে। উদাহরণস্বরূপ, একটি simple flashlight অ্যাপ যদি SMS এবং contact-এর permission চায়, এটি স্পষ্ট সন্দেহজনক, কিন্তু অনেকেই সেটা লক্ষ্য করেন না।

Android ডিভাইসে আক্রমণের প্রধান পথগুলো বুঝে নেওয়া গুরুত্বপূর্ণ। প্রথম এবং সবচেয়ে প্রচলিত হলো Malicious Application। আক্রমণকারীরা প্রায়শই জনপ্রিয় অ্যাপের ক্লোন বা trojanized version তৈরি করে third-party app store বা ফিশিং লিংকের মাধ্যমে বিতরণ করেন। এসব অ্যাপ ব্যাংকিং credentials, OTP, এবং ব্যক্তিগত ডেটা চুরি করে।

দ্বিতীয় বড় ভেক্টর হলো Phishing এবং Smishing। SMS বা WhatsApp-এর মাধ্যমে পাঠানো ভুয়া লিংক যা ব্যবহারকারীকে fake login page-এ নিয়ে যায়। বাংলাদেশের প্রেক্ষাপটে bKash, Nagad ইত্যাদি mobile financial service-কে কেন্দ্র করে এই ধরনের আক্রমণ ক্রমাগত বাড়ছে।

তৃতীয় ভেক্টর হলো Man-in-the-Middle (MITM) আক্রমণ। অনিরাপদ public Wi-Fi-এর মাধ্যমে আক্রমণকারীরা TLS strip করে ডেটা intercept করতে পারেন। যদিও আধুনিক অ্যাপগুলো Certificate Pinning ব্যবহার করে, তবু অনেক অ্যাপ এখনও এই সুরক্ষা প্রয়োগ করে না।

চতুর্থ এবং সবচেয়ে গুরুতর হলো OS-level Vulnerability। Android kernel বা system service-এ পাওয়া vulnerabilities যেমন Stagefright (CVE-2015-3864) প্রমাণ করেছে যে কেবল একটি malicious MMS দিয়েই remote code execution সম্ভব। অনেক পুরনো ডিভাইস security patch না পাওয়ায় এই ধরনের attack-এর প্রতি দুর্বল থাকে।

Android অ্যাপের নিরাপত্তা মূল্যায়নের জন্য reverse engineering একটি অপরিহার্য কৌশল। Android অ্যাপ APK ফাইল হিসেবে বিতরণ করা হয়, যা একটি ZIP archive। এর মধ্যে থাকে classes.dex (compiled bytecode), AndroidManifest.xml, resources, এবং native libraries।

Security researcher-রা সাধারণত apktool ব্যবহার করে APK decompile করেন, যা smali code (Dalvik bytecode-এর human-readable form) তৈরি করে। JADX বা JEB Decompiler দিয়ে এই bytecode আরও পাঠযোগ্য Java code-এ রূপান্তর করা যায়। এর মাধ্যমে অ্যাপের লজিক, hardcoded credentials, API endpoint, এবং সম্ভাব্য vulnerabilities বের করা সম্ভব হয়।

Dynamic analysis-এর জন্য Frida এবং Objection জনপ্রিয় টুল। Frida runtime-এ অ্যাপের method hook করতে পারে, যার মাধ্যমে SSL pinning bypass, root detection bypass, এবং in-memory data inspection সম্ভব হয়। এই টুলগুলো penetration testing-এ দক্ষতার সঙ্গে ব্যবহার করা security professional-দের জন্য গুরুত্বপূর্ণ দক্ষতা।

অনেক sensitive অ্যাপ যেমন banking, payment app—rooted device-এ চলতে অস্বীকার করে। এর কারণ হলো rooted device-এ system-level access থাকে, যা অ্যাপের নিরাপত্তা মডেলকে দুর্বল করে। সাধারণ root detection পদ্ধতিগুলো হলো:

প্রথমত, কোনো known root binary যেমন su, busybox বা Magisk-এর existence চেক করা। দ্বিতীয়ত, /system/app/Superuser.apk বা Magisk-related ফাইলের উপস্থিতি যাচাই। তৃতীয়ত, getprop ro.build.tags থেকে test-keys চেক করা, যা custom ROM নির্দেশ করে। চতুর্থত, SafetyNet Attestation API ব্যবহার করে Google-এর সার্ভার থেকে device integrity verify করা।

তবে আক্রমণকারীরা এসব detection নিয়মিত bypass করেন। Magisk Hide, Zygisk, এবং Shamiko-এর মতো টুল root signature লুকিয়ে রাখতে সক্ষম। উন্নত পদ্ধতিতে Frida দিয়ে detection method-গুলো hook করে সবসময় false রিটার্ন করানো হয়। এজন্য আধুনিক অ্যাপগুলো Play Integrity API এবং hardware-backed attestation-এর দিকে সরে যাচ্ছে।

২০২৩ সালে আবিষ্কৃত Anatsa banking trojan একটি উল্লেখযোগ্য উদাহরণ। এটি Google Play Store-এ legitimate PDF reader অ্যাপ হিসেবে বিতরণ করা হয়েছিল এবং পরবর্তীতে dropper হিসেবে কাজ করে ব্যাংকিং malware ডাউনলোড করত। এটি Accessibility Service abuse করে keystroke logging এবং overlay attack পরিচালনা করত, প্রায় ৫০,০০০ ডিভাইসে সংক্রমণ ছড়িয়েছিল।

আরেকটি বহুল আলোচিত ঘটনা হলো Pegasus spyware-এর Android variant। NSO Group-এর তৈরি এই spyware zero-click exploitation-এর মাধ্যমে সাংবাদিক, মানবাধিকার কর্মী এবং রাজনৈতিক ব্যক্তিদের ডিভাইস compromise করেছিল। এটি WhatsApp এবং অন্যান্য messaging app-এর vulnerabilities ব্যবহার করত এবং সম্পূর্ণ device-এর নিয়ন্ত্রণ নিতে পারত।

বাংলাদেশের প্রেক্ষাপটেও বেশ কয়েকটি malicious app-এর ঘটনা সামনে এসেছে যেগুলো জনপ্রিয় mobile financial service-এর নামে fake login screen দেখিয়ে PIN এবং OTP চুরি করত। এই ধরনের আক্রমণ social engineering এবং technical exploitation-এর সমন্বয়ে গঠিত।

Android Security নিশ্চিত করতে কয়েকটি স্তরে কাজ করতে হয়। প্রথমত, সাধারণ ব্যবহারকারীদের জন্য Google Play Protect সক্রিয় রাখা, শুধু Google Play Store থেকে অ্যাপ ইনস্টল করা, এবং নিয়মিত OS এবং অ্যাপ update রাখা অপরিহার্য। Sideloading এড়িয়ে চলা উচিত, বিশেষ করে অপরিচিত উৎস থেকে।

দ্বিতীয়ত, কর্পোরেট পরিবেশে Mobile Device Management (MDM) সমাধান যেমন Microsoft Intune, VMware Workspace ONE প্রয়োগ করা উচিত। এর মাধ্যমে device compliance check, remote wipe, এবং app whitelisting সম্ভব হয়। BYOD পরিবেশে work profile ব্যবহার করে personal এবং corporate data আলাদা রাখা ভালো।

তৃতীয়ত, developer-দের জন্য Android-এর built-in security feature যেমন EncryptedSharedPreferences, Android Keystore, এবং Network Security Configuration ব্যবহার করা উচিত। Sensitive data কখনো plain text-এ সংরক্ষণ করা উচিত নয়। API communication-এ Certificate Pinning এবং mutual TLS প্রয়োগ করা গুরুত্বপূর্ণ।

চতুর্থত, Production-এ debug মোড বন্ধ রাখা, ProGuard বা R8 দিয়ে code obfuscation করা, এবং anti-tampering checks প্রয়োগ করা উচিত। OWASP Mobile Application Security Verification Standard (MASVS) এবং Mobile Application Security Testing Guide (MASTG) অনুসরণ করে নিয়মিত security audit করা প্রয়োজন।

বড় প্রতিষ্ঠানগুলোর জন্য Android Security একটি comprehensive strategy দাবি করে। Zero Trust principle অনুসরণ করে প্রতিটি device-কে untrusted হিসেবে বিবেচনা করা এবং continuous verification প্রয়োগ করা উচিত। Android Enterprise enrollment-এর মাধ্যমে dedicated বা fully managed device deployment করা যায়, যেখানে IT team-এর সম্পূর্ণ নিয়ন্ত্রণ থাকে।

Mobile Threat Defense (MTD) সমাধান যেমন Lookout, Zimperium, বা Check Point Harmony Mobile real-time threat detection প্রদান করে। এরা network-based attack, malicious app, এবং OS vulnerability শনাক্ত করে। MTD সাধারণত MDM-এর সঙ্গে integrate হয়ে compromised device-এ স্বয়ংক্রিয় remediation চালু করে।

User awareness training-ও সমান গুরুত্বপূর্ণ। কর্মচারীদের phishing detection, password hygiene, এবং safe browsing practice সম্পর্কে নিয়মিত প্রশিক্ষণ দেওয়া উচিত। Incident response plan-এ mobile device compromise-এর জন্য specific playbook থাকতে হবে।