cisco-talos/mutiny-fuzzerनेटवर्क प्रोटोकॉल फ़ज़र जो PCAP ट्रैफ़िक को एक म्यूटेशनल इंजन (Radamsa) के माध्यम से फिर से चलाता है ताकि अनुकूलन योग्य संदेश प्रोसेसर और मॉनिटर के माध्यम से लक्ष्य होस्ट में तेज़ी से कमज़ोरियाँ खोजने के लिए।
ब्लॉग पोस्ट यहाँ है:
इस यूट्यूब वीडियो डेमो के लिंक:
फ़ज़िंग अभियानों/फीडबैक/हार्नेस के लिए अधिक सुविधाओं के लिए:
म्यूटिनी फ़ज़िंग फ्रेमवर्क एक नेटवर्क फ़ज़र है जो म्यूटेशनल फ़ज़र के माध्यम से PCAP को रीप्ले करके काम करता है। लक्ष्य यथासंभव शीघ्र नेटवर्क फ़ज़िंग शुरू करना है, भले ही इसमें गहनता की कमी हो।
म्यूटिनी के लिए सामान्य वर्कफ़्लो एक वैध ट्रैफ़िक नमूना लेना है, जैसे ब्राउज़र अनुरोध, और इसे एक प्रीप स्क्रिप्ट में डालकर .fuzzer फ़ाइल उत्पन्न करना है। फिर, म्यूटिनी को इस .fuzzer फ़ाइल के साथ चलाकर लक्ष्य होस्ट के विरुद्ध ट्रैफ़िक उत्पन्न किया जा सकता है, जिसमें उपयोगकर्ता जिस पैकेट को चाहे उसे म्यूटेट कर सकता है।
ऐसे एक्सटेंशन हैं जो म्यूटिनी के व्यवहार को बदलने की अनुमति देते हैं, जिसमें इनपुट/आउटपुट के आधार पर संदेश बदलना, नेटवर्क त्रुटियों पर म्यूटिनी की प्रतिक्रिया बदलना, और एक अलग थ्रेड में लक्ष्य की निगरानी करना शामिल है।
म्यूटिनी म्यूटेशन करने के लिए Radamsa का उपयोग करता है।
Decept Proxy एक बहुउद्देश्यीय नेटवर्क प्रॉक्सी है जो अन्य सुविधाओं के अलावा एक प्लेनटेक्स्ट या TLS TCP/UDP/डोमेन सॉकेट कनेक्शन से प्लेनटेक्स्ट या TLS TCP/UDP/डोमेन सॉकेट कनेक्शन तक ट्रैफ़िक अग्रेषित कर सकता है। यह म्यूटिनी के लिए एक अच्छा साथी बनाता है, क्योंकि यह सीधे .fuzzer फ़ाइलें उत्पन्न कर सकता है, विशेष रूप से TLS कनेक्शन को फ़ज़ करते समय सहायक, और म्यूटिनी को TLS होस्ट के साथ संवाद करने की अनुमति देता है।
sample_apps फ़ज़र के साथ किए जा सकने वाले कुछ कार्यों का एक बुनियादी विचार देते हैं, जिसमें परीक्षण करने के लिए कुछ अलग-अलग एप्लिकेशन/क्लाइंट शामिल हैं।
जेम्स स्पाडारो ([email protected]) और लिलिथ वायट ([email protected]) द्वारा लिखित
सुनिश्चित करें कि python और scapy इंस्टॉल हैं।
Radamsa को अनटार करें और make करें (आपको make install करने की आवश्यकता नहीं है, जब तक आप इसे /usr/bin में नहीं चाहते - यह स्थानीय Radamsa का उपयोग करेगा) यदि आपने इसे बदला है तो mutiny.py में Radamsa के पथ को अपडेट करें।
pcap को एक फ़ोल्डर में सेव करें। <XYZ>.pcap पर mutiny_prep.py चलाएँ (यदि कोई हो तो वैकल्पिक रूप से कस्टम प्रोसेसर का निर्देशिका भी पास करें, नीचे और अधिक)। प्रश्नों के उत्तर दें, और pcap के समान फ़ोल्डर में <XYZ>.fuzzer फ़ाइल प्राप्त करें।
mutiny.py <XYZ>.fuzzer <targetIP> चलाएँ। यह फ़ज़िंग शुरू करेगा। लॉग उसी फ़ोल्डर में, निर्देशिका <XYZ>_logs/<time_of_session>/<seed_number> के अंतर्गत सहेजे जाएँगे।
.fuzzer फ़ाइलें मानव-पठनीय और टिप्पणी की गई हैं। वे प्रति-फ़ज़र-फ़ाइल आधार पर विभिन्न विकल्पों को बदलने की अनुमति देती हैं, जिसमें यह भी शामिल है कि कौन सा संदेश या संदेश भाग फ़ज़ किए गए हैं।
.fuzzer फ़ाइल के अंदर संदेश सामग्री होती है। ये केवल वे पंक्तियाँ हैं जो 'inbound' या 'outbound' से शुरू होती हैं, जो संदेश की दिशा दर्शाती हैं। वे Python स्ट्रिंग प्रारूप में हैं, जिसमें गैर-मुद्रण योग्य वर्णों के लिए '\xYY' का उपयोग किया जाता है। ये 'mutiny_prep.py' और Decept द्वारा स्वतः उत्पन्न होते हैं, लेकिन कभी-कभी मैन्युअल रूप से संशोधित करने की आवश्यकता होती है।
यदि किसी संदेश में 'outbound' के बाद 'fuzz' कीवर्ड है, तो यह इंगित करता है कि इसे Radamsa के माध्यम से फ़ज़ किया जाना है। एक दिए गए संदेश में पंक्ति निरंतरता हो सकती है, बस एक नई पंक्ति पर उद्धरणों में अधिक संदेश डेटा डालकर। इस स्थिति में, यह दूसरी पंक्ति पहली के साथ विलय हो जाएगी।
वैकल्पिक रूप से, 'sub' कीवर्ड का उपयोग एक उप-घटक को इंगित करने के लिए किया जा सकता है। यह संदेश के एक अलग घटक को निर्दिष्ट करने की अनुमति देता है, ताकि केवल कुछ भागों को फ़ज़ किया जा सके और मैसेज प्रोसेसर के भीतर सुविधा के लिए।
यहाँ एक उदाहरण संदेश डेटा का मनमाना सेट है:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
इससे म्यूटिनी say hi and fuzz this but not this(0xdeadbeef) प्रसारित करेगा। 0xdeadbeef 4 हेक्स बाइट्स के रूप में प्रेषित किया जाएगा। and fuzz this फ़ज़िंग के लिए Radamsa को पास किया जाएगा, लेकिन say hi और but not this(0xdeadbeef) को अछूता छोड़ दिया जाएगा।
म्यूटिनी 'inbound' पंक्ति के कारण उपरोक्त एकल संदेश प्रेषित करने के बाद सर्वर से प्रतिक्रिया की प्रतीक्षा करेगा। सर्वर की अपेक्षित प्रतिक्रिया this is the server's expected response है। म्यूटिनी इस डेटा के साथ बहुत कुछ नहीं करेगा, सिवाय यह देखने के कि सर्वर ने वास्तव में जो भेजा वह इस स्ट्रिंग से मेल खाता है या नहीं। यदि कोई क्रैश होता है, तो म्यूटिनी सर्वर से अपेक्षित आउटपुट और सर्वर ने वास्तव में जो उत्तर दिया, दोनों को लॉग करेगा।
mutiny_classes/ में मैसेज प्रोसेसर, मॉनिटर और एक्सेप्शन प्रोसेसर के लिए बेस क्लासेज हैं। इनमें से किसी भी फ़ाइल को .fuzzer के समान फ़ोल्डर (डिफ़ॉल्ट रूप से) या एक अलग उपफ़ोल्डर में कॉपी किया जा सकता है जिसे .fuzzer फ़ाइल के भीतर 'processor_dir' के रूप में निर्दिष्ट किया गया है।
ये तीन क्लासेज सर्वर प्रतिक्रियाओं को संग्रहीत करने और आउटगोइंग संदेशों को बदलने, एक अलग थ्रेड पर लक्ष्य की निगरानी करने, और म्यूटिनी द्वारा अपवादों को संभालने के तरीके को बदलने की अनुमति देते हैं।
मैसेज प्रोसेसर विभिन्न कॉलबैक को परिभाषित करता है जो फ़ज़िंग रन के दौरान कॉल किए जाते हैं। इन कॉलबैक के भीतर, कोई भी Python कोड चलाया जा सकता है। उपाख्यानात्मक रूप से, इनका उपयोग मुख्य रूप से तीन तरीकों से किया जाता है।
सबसे आम तब होता है जब सर्वर टोकन भेजता है जिन्हें भविष्य के आउटगोइंग संदेशों में जोड़ने की आवश्यकता होती है। उदाहरण के लिए, यदि म्यूटिनी का पहला संदेश लॉग इन करता है, और सर्वर एक सत्र ID के साथ प्रतिक्रिया करता है, तो postReceiveProcess() कॉलबैक का उपयोग उस सत्र ID को संग्रहीत करने के लिए किया जा सकता है। फिर, preSendProcess() में, आउटगोइंग डेटा को उस सत्र ID के साथ ठीक किया जा सकता है। इसका एक उदाहरण sample_apps/session_server में है।
मैसेज प्रोसेसर का एक अन्य सामान्य उपयोग फ़ज़ किए गए संदेश को सीमित या बदलना है। उदाहरण के लिए, यदि सर्वर हमेशा 1000 बाइट्स से बड़े संदेशों को छोड़ देता है, तो कोई बड़ा संदेश भेजना उचित नहीं हो सकता है। preSendProcess() का उपयोग फ़ज़िंग के बाद लेकिन भेजने से पहले संदेशों को छोटा करने या अपवाद उठाने के लिए किया जा सकता है।
अपवाद उठाना उस अंतिम तरीके को सामने लाता है जिसमें मैसेज प्रोसेसर का सामान्यतः उपयोग किया जाता है। एक कॉलबैक के भीतर, mutiny_classes/mutiny_exceptions.py में परिभाषित कोई भी कस्टम अपवाद उठाया जा सकता है। कई अपवाद हैं, सभी टिप्पणी किए गए हैं, जो म्यूटिनी से विभिन्न व्यवहार उत्पन्न करेंगे। इनमें आम तौर पर लॉगिंग, पुनः प्रयास, या वर्तमान रन को रद्द करना शामिल है।
मॉनिटर में एक monitorTarget() फ़ंक्शन है जो मुख्य म्यूटिनी फ़ज़र से एक अलग थ्रेड पर चलाया जाता है। उद्देश्य एक लंबे समय तक चलने वाली प्रक्रिया को लागू करने की अनुमति देना है जो किसी होस्ट की किसी तरह से निगरानी कर सके। यह कुछ भी हो सकता है जो Python में किया जा सकता है, जैसे लक्ष्य पर चल रहे मॉनिटर डेमॉन के साथ संवाद करना, एक लंबी फ़ाइल पढ़ना, या यहाँ तक कि फ़ज़िंग सत्र की आवश्यकताओं के आधार पर बार-बार होस्ट को पिंग करना।
यदि मॉनिटर कोई क्रैश पहचानता है, तो वह किसी भी समय signalMain() कॉल कर सकता है। यह मुख्य म्यूटिनी थ्रेड को संकेत देगा कि क्रैश हुआ है, और यह क्रैश को लॉग करेगा। इस फ़ंक्शन को सामान्यतः एक अनंत लूप में संचालित होना चाहिए, क्योंकि वापस लौटने से थ्रेड समाप्त हो जाएगा, और इसे पुनः प्रारंभ नहीं किया जाएगा।
एक्सेप्शन प्रोसेसर यह निर्धारित करता है कि फ़ज़ सत्र के दौरान म्यूटिनी को किसी दिए गए अपवाद के साथ क्या करना चाहिए। सबसे सामान्य अर्थ में, processException() फ़ंक्शन Python और OS-स्तरीय अपवादों को यथासंभव म्यूटिनी त्रुटि हैंडलिंग क्रियाओं में अनुवाद करेगा।
उदाहरण के लिए, यदि म्यूटिनी को 'Connection Refused' मिलता है, तो डिफ़ॉल्ट प्रतिक्रिया यह मान लेना है कि लक्ष्य सर्वर अपरिवर्तनीय रूप से मर गया है, इसलिए म्यूटिनी पिछले रन को लॉग करेगा और रुक जाएगा। यह अधिकांश मामलों में सच है, लेकिन इस व्यवहार को आवश्यकतानुसार mutiny_classes/mutiny_exceptions.py में किसी भी अपवाद में बदला जा सकता है, जिससे क्रैश डिटेक्शन और त्रुटि सुधार को अनुकूलित किया जा सकता है।