Fuzzing Techniques: অটোমেটেড ডেটা ইনপুটের মাধ্যমে সফটওয়্যারের লুকানো বাগ শনাক্তকরণ!

Fuzzing-এর ধারণাটি প্রথম প্রস্তাব করেন University of Wisconsin-এর প্রফেসর Barton Miller, ১৯৮৮ সালে। তিনি লক্ষ্য করেছিলেন যে UNIX ইউটিলিটিগুলোতে র‍্যান্ডম ক্যারেক্টার পাঠালে অনেক প্রোগ্রাম অপ্রত্যাশিতভাবে ক্র্যাশ করে। সেই থেকে Fuzzing একটি গবেষণাধর্মী প্রযুক্তি থেকে শিল্প-মান সিকিউরিটি টুলিং-এ পরিণত হয়েছে।

Fuzzing-এর মৌলিক নীতি হলো বিশৃঙ্খল ইনপুটের মাধ্যমে সিস্টেমকে এমন পরিস্থিতিতে ফেলা যা ডেভেলপার সম্ভবত পরীক্ষা করেননি। যখন একটি Parser, Network Protocol Handler, কিংবা File Format Reader অপ্রত্যাশিত ইনপুট পায়, তখন Memory Corruption, Buffer Overflow, Integer Overflow, কিংবা Logic Error-এর মতো সমস্যা সামনে আসে। এই ক্র্যাশ বা অস্বাভাবিক আচরণগুলোই সম্ভাব্য Exploitable Vulnerability-এর লক্ষণ।

একটি কার্যকর Fuzzer তিনটি মূল উপাদান নিয়ে গঠিত: ইনপুট জেনারেটর, যা টেস্ট কেস তৈরি করে; এক্সিকিউশন ইঞ্জিন, যা টার্গেট প্রোগ্রামে ইনপুট প্রয়োগ করে; এবং মনিটরিং সিস্টেম, যা ক্র্যাশ, হ্যাং কিংবা অস্বাভাবিক আচরণ শনাক্ত করে। আধুনিক Fuzzer-এ Code Coverage Tracking যুক্ত হওয়ায় টুলগুলো বুঝতে পারে কোন ইনপুটগুলো নতুন কোড পাথ ট্রিগার করছে এবং সেগুলোকে অগ্রাধিকার দেয়।

Fuzzing-কে মূলত তিনটি বিস্তৃত শ্রেণিতে ভাগ করা যায়। প্রথমটি Black-Box Fuzzing, যেখানে Fuzzer-এর কাছে টার্গেট প্রোগ্রামের অভ্যন্তরীণ গঠন সম্পর্কে কোনো তথ্য থাকে না। এটি দ্রুত প্রয়োগযোগ্য কিন্তু কোড কভারেজ কম থাকে। দ্বিতীয়টি White-Box Fuzzing, যেখানে সোর্স কোড বিশ্লেষণ করে Symbolic Execution-এর মাধ্যমে ইনপুট তৈরি করা হয়। Microsoft-এর SAGE Fuzzer এর একটি বিখ্যাত উদাহরণ।

তৃতীয় এবং বর্তমানে সবচেয়ে জনপ্রিয় পদ্ধতি হলো Grey-Box Fuzzing। এখানে Fuzzer প্রোগ্রামের ইনস্ট্রুমেন্টেশনের মাধ্যমে আংশিক তথ্য সংগ্রহ করে এবং Coverage-Guided Mutation প্রয়োগ করে। American Fuzzy Lop (AFL), AFL++, libFuzzer, এবং honggfuzz এই ক্যাটাগরির অন্তর্গত। এগুলো Genetic Algorithm-এর মতো কাজ করে—যেসব ইনপুট নতুন কোড পাথ আনলক করে, সেগুলো রেখে দেয় এবং তাদের উপর আরও মিউটেশন প্রয়োগ করে।

আরও কিছু বিশেষায়িত পদ্ধতি রয়েছে যেমন Mutation-Based Fuzzing, যেখানে বিদ্যমান বৈধ ইনপুট স্যাম্পল নিয়ে এলোমেলোভাবে বিট, বাইট, বা ফিল্ড পরিবর্তন করা হয়। Generation-Based Fuzzing-এ গ্রামার বা প্রোটোকল স্পেসিফিকেশন থেকে কাঠামোগত ইনপুট তৈরি করা হয়, যা জটিল ফরম্যাট যেমন PDF, JSON, বা HTTP-এর জন্য বিশেষভাবে কার্যকর। Protocol Fuzzing-এর জন্য Peach Fuzzer এবং boofuzz-এর মতো টুল ব্যবহৃত হয়।

বাস্তব জগতে Fuzzing করতে গেলে বেশ কিছু পরিণত টুলিং ইকোসিস্টেম পাওয়া যায়। AFL++ বর্তমানে সবচেয়ে সক্রিয়ভাবে রক্ষণাবেক্ষিত এবং উন্নত Coverage-Guided Fuzzer। এটি QEMU Mode সমর্থন করে, যার মানে সোর্স কোড ছাড়াই বাইনারি Fuzz করা যায়। AFL++ এ Custom Mutators, Persistent Mode, এবং Multi-Core Parallelism-এর মতো উন্নত ফিচার রয়েছে।

LibFuzzer হলো LLVM প্রকল্পের অংশ, যা In-Process Fuzzing প্রদান করে। এটি বিশেষভাবে লাইব্রেরি ফাংশন টেস্ট করার জন্য তৈরি, যেখানে একটি ছোট "Fuzz Target" ফাংশন লিখে লাইব্রেরির নির্দিষ্ট API পরীক্ষা করা যায়। Honggfuzz Google-এর তৈরি, যা Hardware Performance Counter ব্যবহার করে কভারেজ ট্র্যাক করে এবং Linux, macOS, Windows-এ চলে।

Network এবং Protocol Fuzzing-এর জন্য boofuzz (পূর্ববর্তী Sulley-এর উত্তরসূরী) এবং BooFuzz Framework ব্যবহৃত হয়। ICS এবং SCADA প্রোটোকলের জন্য Peach Fuzzer এক জনপ্রিয় বাণিজ্যিক সমাধান। Web Application Fuzzing-এ wfuzz, ffuf, এবং Burp Suite-এর Intruder মডিউল কার্যকর। API Fuzzing-এর জন্য RESTler এবং Schemathesis OpenAPI স্পেসিফিকেশন থেকে স্বয়ংক্রিয়ভাবে টেস্ট কেস তৈরি করতে পারে।

Kernel-Level Fuzzing-এর জন্য syzkaller অসাধারণ একটি টুল, যা Linux Kernel-এ হাজার হাজার বাগ আবিষ্কার করেছে। Browser Fuzzing-এর জন্য Domato (Google), Fuzzilli (JavaScript Engine), এবং Grizzly (Mozilla) উল্লেখযোগ্য।

Fuzzing-এর কার্যকারিতা প্রমাণে বাস্তব জীবনের অসংখ্য উদাহরণ রয়েছে। Heartbleed Vulnerability (CVE-2014-0160), যা OpenSSL-এর সবচেয়ে ভয়াবহ বাগগুলোর একটি, পরবর্তীতে Fuzzing-এর মাধ্যমে সহজেই শনাক্তযোগ্য বলে প্রমাণিত হয়। এই ঘটনার পর Google OSS-Fuzz প্রকল্প শুরু করে, যা ওপেন সোর্স প্রকল্পের জন্য বিনামূল্যে কন্টিনিউয়াস Fuzzing প্রদান করে।

OSS-Fuzz এখন পর্যন্ত ১,০০০-এর বেশি ওপেন সোর্স প্রজেক্টে ৪০,০০০-এর বেশি বাগ খুঁজে বের করেছে, যার মধ্যে ৮,০০০-এর অধিক সিকিউরিটি ভালনারেবিলিটি। FFmpeg, libcurl, ImageMagick, OpenSSL, SQLite-এর মতো গুরুত্বপূর্ণ লাইব্রেরিতে ক্রিটিক্যাল RCE বাগ এর মাধ্যমে আবিষ্কৃত হয়েছে।

Microsoft তাদের Windows কোডবেসে SAGE Fuzzer ব্যবহার করে এক দশকে শত শত মেমোরি সেফটি বাগ শনাক্ত করেছে, যার ফলে Patch Tuesday-এর অনেক প্যাচ আগেই ইস্যু করা সম্ভব হয়েছে। Android Open Source Project-এ Google নিয়মিত Fuzz Test চালায়, যার ফলে Stagefright Vulnerability-এর মতো ক্রিটিক্যাল বাগ শনাক্ত হয়েছিল।

Project Zero-এর গবেষক Tavis Ormandy Cloudflare-এর "Cloudbleed" বাগ আবিষ্কার করেছিলেন, যা একটি HTML Parser-এর Buffer Overflow ছিল। যদিও এটি ম্যানুয়াল রিসার্চের মাধ্যমে শনাক্ত হয়েছিল, পরবর্তী Fuzzing-এ একই ধরনের আরও অনেক বাগ ধরা পড়ে।

একটি কার্যকর Fuzzing Campaign পরিচালনার জন্য সুনির্দিষ্ট পদ্ধতি অনুসরণ করা জরুরি। প্রথম ধাপে Target Selection—কোন কম্পোনেন্ট, লাইব্রেরি বা ফাংশন Fuzz করা হবে তা নির্ধারণ করা। সাধারণত Parser, Decoder, Network Handler-এর মতো Attack Surface-এ থাকা কম্পোনেন্ট অগ্রাধিকার পায়।

দ্বিতীয় ধাপে Harness Development। একটি Fuzz Harness হলো ছোট একটি প্রোগ্রাম যা Fuzzer থেকে ইনপুট নিয়ে টার্গেট ফাংশনকে কল করে। ভালো Harness লেখা একটি শিল্প—এটি অবশ্যই দ্রুত হতে হবে, স্টেট রিসেট করতে হবে, এবং টার্গেটের রিয়েলিস্টিক ইউসেজ অনুকরণ করতে হবে।

তৃতীয় ধাপে Corpus Preparation। একটি ভালো Initial Corpus, অর্থাৎ বিভিন্ন ফরম্যাটের বৈধ স্যাম্পল ইনপুট, Fuzzer-কে দ্রুত গভীর কোড পাথে পৌঁছাতে সাহায্য করে। Dictionary File ব্যবহার করে নির্দিষ্ট কী-ওয়ার্ড বা ম্যাজিক বাইট সরবরাহ করা যায়, যা Structured ফরম্যাটে অত্যন্ত কার্যকর।

চতুর্থ ধাপে Instrumentation। AddressSanitizer (ASan), MemorySanitizer (MSan), UndefinedBehaviorSanitizer (UBSan), এবং ThreadSanitizer (TSan) Fuzzing-এর সাথে যুক্ত করলে মেমোরি বাগ, রেস কন্ডিশন, এবং আনডিফাইনড বিহেভিয়ার অনেক বেশি দৃশ্যমান হয়। সাধারণ ক্র্যাশের চেয়ে এই Sanitizer-গুলো অনেক সূক্ষ্ম বাগও ধরতে পারে।

পঞ্চম ধাপে Triage এবং Reproduction। Fuzzing চালানোর পর প্রাপ্ত ক্র্যাশগুলোকে শ্রেণিবিন্যাস করতে হয়—কোনগুলো Unique, কোনগুলো Duplicate, এবং কোনগুলো প্রকৃতপক্ষে Security Implication বহন করে। afl-tmin বা crashwalk-এর মতো টুল ক্র্যাশ মিনিমাইজেশন ও Triage-এ সহায়তা করে।

Modern Fuzzing-এ Symbolic Execution এবং Concolic Execution যুক্ত হয়ে Hybrid Fuzzing তৈরি হয়েছে। Driller এবং QSYM-এর মতো টুল AFL-এর সাথে Symbolic Execution মিশিয়ে এমন কঠিন কোড পাথে পৌঁছাতে পারে যেখানে শুধু Mutation-ভিত্তিক পদ্ধতি ব্যর্থ হয়।

Directed Greybox Fuzzing-এর মাধ্যমে কোডবেসের নির্দিষ্ট অংশকে টার্গেট করা যায়। AFLGo এবং Hawkeye-এর মতো টুল কোডবেসের সাম্প্রতিক পরিবর্তন বা সন্দেহজনক ফাংশনের দিকে Fuzzing প্রচেষ্টা কেন্দ্রীভূত করে।

Machine Learning-ভিত্তিক Fuzzing দ্রুত বিকাশ লাভ করছে। NEUZZ এবং MLFuzz Neural Network ব্যবহার করে প্রোগ্রাম বিহেভিয়ার শেখে এবং আরও কার্যকর ইনপুট তৈরি করে। Differential Fuzzing-এ একই ইনপুট দুটি ভিন্ন ইমপ্লিমেন্টেশনে পাঠিয়ে আউটপুটের পার্থক্য খুঁজে বের করা হয়, যা TLS Library-এর মতো প্রোটোকল ইমপ্লিমেন্টেশনে অসঙ্গতি শনাক্তে সহায়ক।

Snapshot Fuzzing হলো আরেকটি অত্যাধুনিক পদ্ধতি, যেখানে একটি প্রোগ্রামের কোনো নির্দিষ্ট অবস্থায় স্ন্যাপশট নিয়ে বারবার সেই অবস্থা থেকেই Fuzzing চালানো হয়। What the Fuzz (wtf) এবং Nyx এই কাজে ব্যবহৃত হয়, বিশেষত Kernel এবং Hypervisor Fuzzing-এ।

Fuzzing শুধুমাত্র Attack Tool নয়; এটি Secure Development Lifecycle-এর একটি গুরুত্বপূর্ণ অংশ। Continuous Integration (CI) পাইপলাইনে Fuzzing সংযুক্ত করার অভ্যাস সব আধুনিক সফটওয়্যার প্রতিষ্ঠানের গ্রহণ করা উচিত। ClusterFuzz এবং OSS-Fuzz-এর মতো প্ল্যাটফর্ম এই কাজ সহজ করে দিয়েছে।

ডেভেলপারদের উচিত প্রতিটি Parser, Deserializer এবং External Input Handler-এর জন্য Fuzz Harness তৈরি করা। Memory-Safe Language যেমন Rust ব্যবহার অনেক ধরনের মেমোরি বাগ মূল থেকেই বাদ দেয়, তবে Logic Bug এবং Resource Exhaustion বাগের বিরুদ্ধে Fuzzing এখনো প্রাসঙ্গিক।

Defensive Coding Practice হিসেবে Input Validation, Bounds Checking, এবং Defensive Allocation Strategy প্রয়োগ করা উচিত। Compiler Hardening Flag যেমন -fstack-protector, -D_FORTIFY_SOURCE=2, এবং Position Independent Executable (PIE) ব্যবহার করে Exploit Mitigation শক্তিশালী করা যায়।

Bug Bounty প্রোগ্রামের সাথে Fuzzing-এর সমন্বয় কার্যকর। বহিরাগত গবেষকরা যখন Fuzzing চালিয়ে বাগ রিপোর্ট করেন, প্রতিষ্ঠান দ্রুত সেগুলো প্যাচ করতে পারে। তবে সব Fuzzing Activity অবশ্যই অনুমোদিত স্কোপের মধ্যে থাকতে হবে—অননুমোদিত সিস্টেমে Fuzzing চালানো আইনত দণ্ডনীয়।

প্রতিষ্ঠানগুলোর উচিত Threat Modeling-এর সময় Fuzzability বিবেচনা করা। কোন কম্পোনেন্ট Untrusted Input গ্রহণ করছে তা চিহ্নিত করে সেগুলোকে অগ্রাধিকার ভিত্তিতে Fuzz করতে হবে। Coverage Metric নিয়মিত পর্যবেক্ষণ করা, Stagnation শনাক্ত করা, এবং প্রয়োজনে Harness ও Corpus উন্নত করা একটি চলমান প্রক্রিয়া।