Exploit ऑडिटिंग

इस ऑडिटिंग प्रक्रिया के बारे में बढ़िया लिंक। https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

अस्वीकरण जैसा कि पहले कहा गया है, यह हर एक्सप्लॉइट का पता नहीं लगाएगा, लेकिन यह कुछ विसंगतियों का पता लगाने में मदद कर सकता है यदि हमलावर ने सार्वजनिक एक्सप्लॉइट को संशोधित नहीं किया और/या अपने बाद सफाई नहीं की। अधिकांश हमलावर डिफ़ॉल्ट एक्सप्लॉइट का उपयोग करेंगे, और ये कुछ दस्तावेजी आर्टिफैक्ट हैं जो पीछे छोड़े जा सकते हैं। कमांड की यह सूची कई स्रोतों से ली गई है और यह बहुत गतिशील होगी क्योंकि अन्य वेरिएंट, वर्कअराउंड और नए विकास सामने आते हैं। हम इस पर भरोसा कर सकते हैं कि यह लगातार बदलता रहेगा क्योंकि अधिक संक्रमण होते हैं और बड़े नमूना सेट के साथ आगे की फोरेंसिक पूरी होती है।

पहले उन चीज़ों को देखें जो आपने नहीं कीं। यदि आप सामान्य रूप से अपने ADC पर बहुत कुछ नहीं करते हैं, तो ये बहुत शांत होने चाहिए, साथ ही, पिछली बार जब आप थे तब के हफ्तों, महीनों या वर्षों पुरानी प्रविष्टियाँ हो सकती हैं। इस ब्लॉग में भी यह एक बिल्ली-चूहे का खेल है। जैसा कि हम बताते हैं कि हमने क्या देखा है और हमलावरों को कैसे खोजा जाए, वे पहचान से बचने के लिए अपनी रणनीति बदलकर इस जानकारी का हमारे खिलाफ उपयोग कर रहे हैं।

Exploitation Check Quick Punch List v1

• 1. अपना लाइसेंस जांचें, मैंने कुछ के बारे में सुना है जिन्होंने अपने डिवाइस को रीबूट किया और वास्तव में उनका लाइसेंस समाप्त हो गया था।
• 2. एक सपोर्ट फ़ाइल प्राप्त करें अर्थात बैकअप सिस्टम -> डायग्नोस्टिक्स -> गेट सपोर्ट फ़ाइल और उस फ़ाइल को सेव करें।
• 3. नीचे दिए गए सभी कमांड NSCLI में हैं और यदि आप SSH करके बॉक्स में जाते हैं और Shell का उपयोग करते हैं तो आप Shell उपसर्ग हटा सकते हैं।
• 4. लॉग निष्कर्षों को सहसंबंधित करने में मदद के लिए बॉक्स पर तारीख जांचें
  • a. shell date
• 5. अपनी कॉन्फ़िगरेशन परिवर्तन तिथि जांचें
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. आपके netscaler.conf की तारीख क्या है?
    • ii. क्या वह सही दिखता है? अन्य स्थानों पर फ़ाइल लिंक देखें।
• 6. स्थानीय खाता पासवर्ड फ़ाइल जांचें
  • a. Shell ls -lh /etc/passwd
    • i. जांचें कि फ़ाइल कब संशोधित हुई। यदि एक्सप्लॉइट के बाद और यह आप नहीं थे, तो आपको जल्द से जल्द उस पासवर्ड को बदलने की आवश्यकता है।
    • ii. यदि कोई एक्सप्लॉइट पाया जाता है तो मैं nsroot या किसी भी स्थानीय खाते का पासवर्ड बदलने की सलाह देता हूं। कई मामलों में
  • b. Shell cat /etc/passwd
    • i. देखें कि इसमें कौन से खाते हैं।
    • ii. Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor डिफ़ॉल्ट हैं।
• 7. अपने लॉग जांचें
  • a. shell ls -lh /var/logfile
    • i. क्या फ़ाइलें वहां हैं? क्या वे वास्तव में छोटी हैं?
    • ii. https://support.citrix.com/article/CTX121898
• 8. बुरी फ़ाइल जांच
  • a. यदि इनमें से कोई भी फ़ाइल 8-9 से अधिक या कम वर्णों की है और एक यादृच्छिक फ़ाइल नाम है, तो यह एक अधिक उन्नत हमलावर का संकेत है जिसने स्टॉक एक्सप्लॉइट को बदल दिया। यदि आप यह देखते हैं, तो आपको अपने उपचार को तदनुसार समायोजित करने की आवश्यकता है। Pwnpzi1337.xml प्रोजेक्ट इंडिया एक्सप्लॉइट के लिए फ़ाइल का नाम है
  • b. shell ls /netscaler/portal/templates/*.xml
    • i. यहां कोई XML फ़ाइलें नहीं होनी चाहिए।
    • ii. यदि संक्रमित है तो यहां फ़ाइल की तारीखें देखें।
    • iii.shell ls -lh /netscaler/portal/templates/
  • c. shell ls /var/tmp/netscaler/portal/templates
    • i. यह निर्देशिका मौजूद नहीं होनी चाहिए।
    • ii. यदि संक्रमित है तो यहां फ़ाइल की तारीखें देखें।
    • iii.shell ls -lh /var/tmp/netscaler/portal/templates
  • d. shell ls /var/vpn/bookmark/*.xml
    • i. अक्सर मौजूद नहीं होता लेकिन इसमें XML फ़ाइलें भी नहीं होनी चाहिए।
    • ii. यदि संक्रमित है तो यहां फ़ाइल की तारीखें देखें।
    • iii.shell ls -lh /var/vpn/bookmark/
  • e. shell ls /tmp/.init
    • i. यह निर्देशिका मौजूद नहीं होनी चाहिए।
• 9. क्रॉन जॉब्स (स्थायित्व विधियां)
  • a. shell cat /etc/crontab
  • b. shell crontab -l -u nobody
• 10. क्रिप्टो जांच
  • a. shell top -n 10
    • i. NSPPE-xx (पैकेट इंजन) 100% या उसके करीब होना चाहिए, यदि कोई अन्य प्रक्रिया है तो आपका माइनिंग हो सकता है
• 11. PCAP
  • a. Shell find / -name "*.cap"
  • b. किसी भी आवारा कैप्चर फ़ाइल को खोजने में मदद करें जो ली गई हो सकती है।
  • c. यह एक अधिक उन्नत हमलावर का संकेत होगा जो स्निफिंग कर रहा हो सकता है।
• 12. शेल लॉग
  • a. shell cat /var/log/bash.log | grep nobody
    • i. nobody उपयोगकर्ता से उपयोगकर्ता पहुंच की तलाश करना।
  • b. shell gzcat /var/log/bash.*.gz | grep nobody
    • i. ज़िप किए गए लॉग में nobody उपयोगकर्ता से उपयोगकर्ता पहुंच की तलाश करना।
• 13. Apache लॉग जांच
  • a. shell "cat /var/log/httperror.log | grep -B2 -A5 Traceback"
  • b. shell "gzcat /var/log/httperror.log.*.gz | grep -B2 -A5 Traceback”
  • c. shell grep -iE 'POST.*.pl HTTP/1.1" 200 ' /var/log/httpaccess.log -A 1
  • d. shell grep -iE 'POST.*.pl HTTP/1.1" 200 143' /var/log/httpaccess.log -A 1
  • e. shell grep -iE 'GET.*.xml HTTP/1.1" 200' /var/log/httpaccess.log -B 1
  • f. shell grep -i '.pl HTTP/1.1" 200 143' /var/log/httpaccess.log | grep POST
    • i. ये सभी सिस्टम में .pl और .xml फ़ाइलों को अंदर या बाहर ले जाने से संबंधित विशिष्ट वस्तुओं की तलाश कर रहे हैं।
  • g. shell cat /var/log/httperror.log
    • i. यह फ़ाइल की कच्ची सामग्री को देख रहा है, कुल मिलाकर यह अन्य वस्तुओं की तलाश करने के लिए है जो अलग दिखती हैं।
• 14. स्थायी स्क्रिप्ट
  • a. shell ps -aux | grep python
  • b. shell ps -aux | grep perl
  • c. shell ps -auxd | grep nobody
    • i. ये दोनों रिवर्स शेल और अन्य कार्यों को चलाने के लिए स्क्रिप्ट का उपयोग करने के ज्ञात स्थायित्व तरीके हैं। आपको इस प्रक्रिया सूची में केवल grep कमांड देखना चाहिए।
    • ii.यह एक अन्य स्थायित्व विधि के कुछ निष्कर्षों पर जाता है। इस एक्सप्लॉइट ने Nobody उपयोगकर्ता द्वारा चलाई गई एक दुर्भावनापूर्ण प्रक्रिया का उपयोग किया। https://soolidsnake.github.io/2020/01/17/citrix_malware.html
• 15. पासवर्ड\खाता जांच
  • a. shell ls -l /etc/passwd
    • i. फ़ाइल की तारीख भी देखें कि क्या हाल ही में कुछ जोड़ा गया है।
  • b. shell cat /etc/passwd
    • i. कुछ संदिग्ध दिखता है, स्थानीय खाते?
• 16. TCP कनेक्शन जांचें
  • a. Shell netstat -natu
  • b. अपने VLAN में गैर-स्थानीय IP पतों की तलाश करें। आंतरिक IP की भी जांच की जानी चाहिए यदि कोई अन्य बॉक्स समझौता किया गया हो।
• 17. अपने प्रमाणीकरण प्रोफाइल जांचें
  • a. क्या वे TLS या SSL पर सेट थे और अब वे PlainText हैं?
    • i. मैंने कुछ ऑडिट और ऑनलाइन में बदले जाने देखे हैं।
    • ii. यह भी एक उन्नत हमलावर का संकेत है।
  • b. यह आपके कॉन्फ़िगरेशन ns.conf से संबंधित होगा कि क्या यह बदला गया था या नहीं, सौभाग्य से।
  • c. यदि यह पहले PlainText था, तो आपको जितनी जल्दी हो सके इसे TLS और SSL पर सेट करने पर काम करने की आवश्यकता है, भले ही आपको एक्सप्लॉइट के संकेत मिलें या नहीं।
• 18. अपने प्रमाणपत्र जांचें
  • a. ये SSL प्रमाणपत्र हैं जिन्हें आप विशेष रूप से पुनः कुंजीबद्ध करना चाह सकते हैं यदि आपके बॉक्स का शोषण किया गया है।
  • b. मैं सलाह देता हूं कि यदि आपके पास शोषण के कोई भी संकेत हैं, तो अपने SSL प्रमाणपत्रों को पुनः कुंजीबद्ध करें। कुछ बड़े परिनियोजनों के लिए आगे एक कठिन रास्ता हो सकता है क्योंकि उन अन्य स्थानों की संख्या जहां प्रमाणपत्र बंधा है और SSL प्रमाणपत्र परिवर्तन के संभावित आउटेज\व्यवधान हो सकते हैं।
  • c. मैंने कुछ ग्राहकों को पुनः कुंजीबद्ध नहीं करते देखा है क्योंकि उनके पास यह साबित करने के लिए अच्छे लॉग थे कि उन्होंने एक्सप्लॉइट करने के अलावा कुछ नहीं किया और सिस्टम कॉन्फ़िगरेशन में नहीं गए। अधिकांश ग्राहकों के पास केवल कुछ दिनों के
• 19. संभावित Tier 1 लक्ष्यों के लिए अपनी कॉन्फ़िगरेशन फ़ाइल जांचें
  • a. अपना ns.conf देखें और वह आपकी Tier 1 लक्ष्य सूची बनाएगा जो संभवतः डिवाइस के शोषण होने पर पहले एक्सेस की गई थी।

यदि शोषण किया गया

आपके खतरे के परिदृश्य के आधार पर आपको क्या करने की आवश्यकता है, यह हमेशा अलग-अलग होगा। यहां कुछ विचार दिए गए हैं जो मैं उन ग्राहकों को बता रहा हूं जिन्होंने निष्पादित एक्सप्लॉइट का सबूत पाया है।

आपके व्यवसाय को कौन से अनुपालन निकाय कवर करते हैं? फाइनेंस\बैंकिंग, SOX, PCI, HIPPA, राज्य/स्थानीय और सरकारी कानून।

यदि आप इनमें से किसी एक ढांचे के अंतर्गत हैं, तो आपको उन अनुपालन निकायों के लिए उन प्रक्रियाओं का पालन करने की आवश्यकता है। नैतिक विचार भी हैं जो आपके प्रमाणन और पेशेवर समूहों पर आधारित हैं जिनके पास घटना प्रतिक्रिया और प्रकटीकरण के लिए प्रावधान हैं।

यहां दो प्रसिद्ध घटना प्रतिक्रिया प्रक्रिया गाइड के लिंक दिए गए हैं https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

एक बात जो हम अब तक जानते हैं वह यह है कि लगभग 1-10-20 को पहला सार्वजनिक एक्सप्लॉइट जारी किया गया था और 9 तारीख को संक्रमण की कुछ रिपोर्टें हैं क्योंकि यह ठीक उसी समय सामने आया था। अधिकांश मामलों में जोखिम बहुत कम है यदि आपने इस महीने के बजाय 2020 से पहले अपने सिस्टम को पैच किया था।

CVE-2019-19781 अनुमानित जोखिम खतरा रैंप

December 17th-December 31st सबसे कम शोषण जोखिम January 1-8th कम शोषण जोखिम January 9th-13th – उच्च शोषण जोखिम January 14th- Present – सबसे अधिक शोषण जोखिम

यह आपके अगले कदमों की प्रक्रिया में शामिल होना चाहिए।

मुझे शोषण के निशान मिले हैं, अब क्या? यह अभी भी निर्भर करता है, एक बात जो अधिकांश Citrix ADC परिनियोजनों में कॉन्फ़िगर नहीं की जाती है, वह है अच्छी SNMP और SYSLOG लॉगिंग और उनके पास खोज, फ़िल्टर या सतर्क करने का अच्छा तरीका नहीं हो सकता है यदि आर्टिफैक्ट पाए जाते हैं। यदि आपके पास पूर्ण लॉगिंग है और आप आश्वस्त हैं कि उन्होंने कुछ नहीं किया, तो आप अपने जीवन के साथ आगे बढ़ सकते हैं। फिर यदि आपको कुछ मिला और आप आत्मविश्वास से उनकी दूरस्थ पहुंच को हटाने में सक्षम थे, तो आप आगे बढ़ सकते हैं।

लेकिन अधिकांश पाएंगे कि उन्हें कुछ निशान मिलेंगे और वे यह नहीं जोड़ पाएंगे कि क्या किया गया था और वे कहां गए होंगे और पता लगाने के बाद डिवाइस को रीसेट करना आसान हो सकता है।

मेरी अगली सलाह अगले 2 हफ्तों में बदल जाएगी।

नमूना घटना प्रतिक्रिया पथ

मैं कोई सही और पूर्ण उत्तर नहीं दे सकता जो हर किसी की स्थिति में फिट होगा, ये 1-19-20 तक मेरे विचार हैं और इसके बाद ये बदल सकते हैं क्योंकि मैं अगले कदमों के बारे में और सीखता हूं और इस भेद्यता से संबंधित रक्षा या हमले के पक्ष में चीजें जारी की जाती हैं। कोई सही उत्तर नहीं है, IT सुरक्षा अधिकांश भूमि की तरह एक भूमि है जो "यह निर्भर करता है" द्वारा शासित है। मैं अत्यधिक सलाह देता हूं कि यदि आपको उन 3 निर्देशिकाओं में केवल इन फ़ाइलों के अलावा कुछ और मिलता है, तो मैं बॉक्स को समझौता मानूंगा और अधिक सावधान मार्ग पर जाऊंगा। इनमें से कुछ में, मैं अधिक सावधान मार्ग अपनाने का सुझाव दे रहा हूं, खासकर जब यह पुष्टि करने के लिए कोई लॉगिंग नहीं है कि उन्होंने क्या किया या नहीं किया। आपको अपनी टीम के साथ काम करने की आवश्यकता है कि आपकी स्थिति के आधार पर कार्रवाई का सबसे अच्छा तरीका तय करें क्योंकि यह एक टीम खेल है। ऐसी चीजों को ठीक करने का हमेशा एक बेहतर तरीका हो सकता है, लेकिन डिवाइस पर और डिवाइस के आसपास (पहले स्तर के लक्ष्य) आपके पास सबूतों के आधार पर, आप अपने जोखिम को कम करके और वहां से आगे बढ़कर ठीक हो सकते हैं।

• शमन करें: यह वह जगह है जहां से आपको शुरू करना चाहिए चाहे कुछ भी हो। नए फर्मवेयर या रिस्पॉन्डर नीति के साथ।
• आपके ऑडिट के दौरान शोषण का पता चला।
  • अपनी घटना प्रतिक्रिया प्रक्रिया शुरू करें।
• अच्छी डिवाइस लॉगिंग के साथ
  • उन्नत हमलों या स्थायित्व के संकेत
    • नया बनाएं और माइग्रेट करें
  • उन्नत हमलों या स्थायित्व के कोई संकेत नहीं
    • उपचार करें और चालू रखें
• डिवाइस लॉगिंग के बिना
  • उन्नत हमलों या स्थायित्व के संकेत
    • नया बनाएं और माइग्रेट करें
    • फ़ैक्टरी रीसेट
  • उन्नत हमलों या स्थायित्व के कोई संकेत नहीं
    • नया बनाएं और माइग्रेट करें
    • फ़ैक्टरी रीसेट
• अच्छी पहले स्तर की लक्ष्य लॉगिंग के साथ
  • उन्नत हमलों या स्थायित्व के संकेत
    • नया बनाएं और माइग्रेट करें
    • फ़ैक्टरी रीसेट
  • उन्नत हमलों या स्थायित्व के कोई संकेत नहीं
    • उपचार करें और चालू रखें
• पहले स्तर की लक्ष्य लॉगिंग नहीं
  • उन्नत हमलों या स्थायित्व के संकेत
    • नया बनाएं और माइग्रेट करें
    • फ़ैक्टरी रीसेट
  • उन्नत हमलों या स्थायित्व के कोई संकेत नहीं
    • नया बनाएं और माइग्रेट करें
    • फ़ैक्टरी रीसेट

प्रतिक्रिया परिभाषा और विचार

• नया बनाएं और माइग्रेट करें – अपनी घटना प्रतिक्रिया प्रक्रिया शुरू करें, फिर आप इस प्रक्रिया को शुरू कर सकते हैं https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html। यह VPX और SDX ग्राहकों के लिए अपेक्षाकृत आसान है क्योंकि आभासी प्रकृति और कॉन्फ़िगरेशन प्लेटफॉर्म का लचीलापन। MPX माइग्रेशन एक अलग कहानी है क्योंकि फ़ैक्टरी रीसेट कैसे काम करता है और बेस इमेज को बनाए रखा जाता है, यदि यह एक उन्नत हमलावर था तो फर्मवेयर अपग्रेड और/या फ़ैक्टरी रीसेट के माध्यम से बने रहने का बहुत कम जोखिम हो सकता है। संभावना कम हो सकती है, लेकिन यह अभी भी संभव है (साइबर जगत में किसी भी चीज़ की तरह)।
• फ़ैक्टरी रीसेट – अपनी घटना प्रतिक्रिया प्रक्रिया शुरू करें और .xml फ़ाइलों और किसी भी अन्य पाई गई वस्तु को हटा दें और रीबूट करें और फिर से स्थायित्व की जांच करें। फिर फ़ैक्टरी रीसेट करने की प्रक्रिया शुरू करें। Citrix से स्क्रिप्ट प्राप्त की जा सकती हैं जो प्रक्रिया से गुजरेंगी। यह ऑपरेटिंग सिस्टम को फिर से लोड करने से पहले सिस्टम को निम्नतम स्तर तक मिटा देगा, लेकिन हर कोई अब तक अपने खतरे के परिदृश्य के आधार पर इस पद्धति पर भरोसा करेगा और अधिक चाह सकता है।
  • सबसे कठोर तरीका ड्राइव को फिर से लोड करने के लिए डिवाइस को RMA करना होगा और यह आपके जीवनचक्र, प्लेटफॉर्म और आपकी अतिरेक योजना के आधार पर अच्छा या बुरा विचार हो सकता है। मैं केवल तभी सुझाव दूंगा यदि आपने उन्नत तकनीकों का उपयोग देखा और उनकी तकनीकों के आधार पर पार्श्व आंदोलन की पुष्टि की है तो संभवतः इस मार्ग पर जाएं। मुझे पता है कि Citrix एक क्या-अगर विकल्पों पर काम कर रहा है और
• उपचार करें – घटना प्रतिक्रिया प्रक्रिया शुरू करें और .xml फ़ाइलों और किसी भी अन्य पाई गई वस्तु को हटा दें और रीबूट करें और फिर से स्थायित्व की जांच करें। यदि आपके पास अच्छे लॉग हैं तो आपको पता चल जाएगा कि कुछ किया गया था या नहीं, यदि नहीं, तो मैं आपके खतरे के परिदृश्य को देखूंगा और यदि आपके पास पहले स्तर के लक्ष्यों या किसी और चीज़ पर लॉगिंग है तो यह जानने के लिए कि क्या आपको इसे फ़ैक्टरी रीसेट करने और/या नया बनाने और माइग्रेट करने की आवश्यकता पर विचार करने की आवश्यकता है।

लॉगिंग स्तर

• अच्छी स्थानीय लॉगिंग
  • आप स्थानीय रूप से यह देखने के लिए सबसे अच्छी स्थिति में हैं कि क्या हुआ, यह जानने के लिए कि क्या पार्श्व आंदोलन का कोई प्रयास हुआ या क्या एक्सप्लॉइट अधिकांश की तरह ही चलाया गया था।
• अच्छी पहले स्तर की लक्ष्य लॉगिंग
  • आप यह देखने के लिए सबसे अच्छी स्थिति में हैं कि क्या पार्श्व आंदोलन हुआ या प्रयास भी किया गया। ये पहली चीजें होनी चाहिए जिन्हें लक्षित किया जा सकता है और यदि आपने सफल पार्श्व आंदोलन देखा तो आपको सबसे अधिक चिंतित होना चाहिए और अपने उपचार पथ पर अधिक सावधानी के साथ आगे बढ़ना चाहिए। यदि नहीं, तो आप खतरे के जोखिम को कम कर सकते हैं और केवल उपचार पथ अपना सकते हैं।
• कोई स्थानीय लॉगिंग नहीं
  • आप स्थानीय रूप से यह देखने के लिए सबसे खराब स्थिति में हैं कि क्या हुआ, यह जानने के लिए कि क्या पार्श्व आंदोलन का कोई प्रयास हुआ या क्या एक्सप्लॉइट अधिकांश की तरह ही चलाया गया था। आपको अपने उपचार पथ पर अधिक सावधानी के साथ आगे बढ़ना होगा।
• कोई पहले स्तर की लक्ष्य लॉगिंग नहीं
  • आप यह देखने के लिए सबसे खराब स्थिति में हैं कि पार्श्व आंदोलन हुआ या प्रयास भी किया गया। ये पहली चीजें होनी चाहिए जिन्हें लक्षित किया जा सकता है और यदि आपने सफल पार्श्व आंदोलन देखा तो आपको सबसे अधिक चिंतित होना चाहिए और अपने उपचार पथ पर अधिक सावधानी के साथ आगे बढ़ना चाहिए।

मुझे उम्मीद है कि लोग संक्रमण को हटा सकते हैं और इनमें से कुछ कदमों के बिना अपनी सामान्य गतिविधियों को फिर से शुरू करने के लिए पर्याप्त आश्वस्त महसूस करने के लिए पर्याप्त अच्छी लॉगिंग रखते हैं।

अन्य अच्छे अनुवर्ती कदम

दो मुख्य चीजें हैं जिन पर आपको निर्णय लेने की आवश्यकता है यदि शोषण का कोई निशान है।

• 1. NSROOT पासवर्ड बदलें
  • a. मैं इसे करने की सलाह देता हूं चाहे आपको कुछ भी मिले या आपके पास कौन से लॉग हों। NSROOT को PW परिवर्तनों के लिए रोटेशन में लाने का यह एक मौका है। ADC प्रबंधन को LDAP से बंधा होना चाहिए और NSROOT का उपयोग केवल आपात स्थिति में किया जाना चाहिए।
• 2. LDAP सेवा खाता (या अन्य प्रमाणीकरण सेवा) बदलें
  • a. इस पासवर्ड को बदलें और यदि संभव हो तो मैं किसी अन्य खाते में बदलने की सलाह देता हूं ताकि आपके पास अलग SID भी हो। यह एक निष्क्रिय परिवर्तन हो सकता है जिसे रोलआउट से पहले परीक्षण किए जाने पर किसी का ध्यान नहीं जाता।
• 3. SSL कुंजियाँ बदलें
  • a. अच्छी लॉगिंग
    • i. हो सकता है कि आप ठीक हैं यदि आप 100% सुनिश्चित हैं कि यह अच्छा है।
    • ii. मेरे मन में अभी भी एक हिस्सा है जो कहना चाहता है कि सब कुछ पुनः कुंजीबद्ध करें, लेकिन मुझे पता है कि एक बड़ी दुकान में यह कितना काम हो सकता है।
  • b. कोई लॉगिंग नहीं
    • i. मुझे लगता है कि आपको वहां सब कुछ पुनः कुंजीबद्ध करना होगा। PEM और PFX सुरक्षा है, लेकिन मैंने बहुत सारी जगहें देखी हैं जो उनके लिए बहुत सरल पासवर्ड का उपयोग करती हैं और ऑफ़लाइन ब्रूट फोर्स किया जा सकता है। चूंकि हम नहीं जानते, हमें कंपनी की रक्षा करने की आवश्यकता है।

पासवर्ड विचार

मैं सलाह देता हूं कि यदि सफल शोषण का कोई भी संकेत है तो बॉक्स पर अपने सभी स्थानीय खातों के पासवर्ड बदलें। आगे बढ़ें और इसे बदलें क्योंकि कई परिनियोजनों में यह मूल रूप से 4-7 साल पहले तैनात किए जाने के बाद कभी नहीं बदला गया हो सकता है। यदि आप कमांड लाइन एक्सेस और/या छेड़छाड़ के संकेत देखते हैं, तो आप संभवतः मान सकते हैं कि हमलावर Pre 11.0 फर्मवेयर पर पासवर्ड क्रैक करने में सक्षम था, यह AES256 था और बाद के बिल्ड में यह AES512 का उपयोग करता है जो क्रैकिंग के लिए भी संवेदनशील हो सकता है। सुनिश्चित करें कि यह सुरक्षित रूप से LDAP से बंधा है और आपके पास NSROOT लॉगिन के लिए अलर्ट सेट हैं।

LDAP विचार

यदि आपने शोषण के कुछ स्तर देखे हैं, तो मैं Citrix ADC कॉन्फ़िगरेशन के भीतर परिभाषित किसी भी सेवा खाते को भी बदलना सुनिश्चित करूंगा। सबसे आम LDAP\Kerberos बाइंड खाता है। किसी व्यक्ति के लिए Citrix ADC पर एक्सप्लॉइट चलाने का मतलब यह नहीं है कि वे डोमेन एडमिन हैं, लेकिन आपके नियंत्रण और लॉगिंग के आधार पर इसमें अधिक समय नहीं लग सकता है। यह एक बहुत ही आसान परिवर्तन है जो परीक्षण किए जाने पर उपयोगकर्ताओं के लिए सहज हो सकता है।

प्रमाणपत्र विचार

आपके ऑडिट में जो कुछ मिला, उसके आधार पर यह भी पता लगाने में मदद मिलेगी। यदि आपके पास अच्छी लॉगिंग थी और आप इस फ़ाइल तक पहुंच अनुरोध देख सकते हैं, तो आपको पुनः कुंजीबद्ध करना होगा। यदि आपके पास अच्छी लॉगिंग नहीं है, तो आपको भी पुनः कुंजीबद्ध करना चाहिए। यदि आपके पास वाइल्डकार्ड प्रमाणपत्र है, तो यह भी एक और बड़ी समस्या है और जितनी अधिक साइटें इससे बंधी हैं, आपका जोखिम और जोखिम उतना ही अधिक होगा। सबसे बुरी चीज जो हो सकती है वह यह है कि आप मान लें कि यह ठीक है और कोई आपके प्रमाणपत्र के साथ फ़िशिंग साइट स्थापित कर रहा है जिस पर आपका सारा प्रशिक्षण क्लिक को नहीं रोक पाएगा। यदि किसी के पास आपके प्रमाणपत्रों तक पहुंच है, तो यह बहुत बड़ी समस्या पैदा कर सकता है और मैं सावधानी के साथ आगे बढ़ने और पुनः कुंजीबद्ध करने का सुझाव दूंगा। वर्तमान प्रमाणपत्र की समाप्ति तिथि के आधार पर यह एक अच्छा समय हो सकता है। मैंने कुछ को इस प्रक्रिया में किसी अन्य प्रमाणपत्र रजिस्ट्रार पर स्विच करते देखा है, सिर्फ चीजों को बदलने के लिए, लेकिन उनके पास लॉग थे कि फ़ाइल तक पहुंच बनाई गई और डाउनलोड की गई, साथ ही अन्य उन्नत तकनीकों का पता चला।

श्रेय ###अंतिम लेकिन महत्वपूर्ण, उन कुछ लोगों को श्रेय जो इस मुद्दे पर इसके आगमन के बाद से काम कर रहे हैं। ऐसे और भी कई लोग हैं जो इस सूची में नहीं हैं क्योंकि वे पर्दे के पीछे हैं जिन्हें मैंने भी नहीं देखा है।

• Citrix टीम – जानकारी को बाहर लाने के साथ-साथ इन नए फर्मवेयर पर काम कर रही है। कोड परिवारों में अंतर के कारण उन्हें एक साथ 5 पैच पर काम करना पड़ रहा है, जो इसे और अधिक कठिन बनाता है।
• Daniel Weppeler @_DanielWe – प्रोब्स\हमलों का पता लगाने के लिए लॉगिंग रिस्पॉन्डर पॉलिसी
• Florian Roth @cyb3rops – शोषण पहचान के लिए Nessus YAR फ़ाइल
• CTP Anton van Pelt @AntonvanPelt & CTA Mads Petersen @mbp_netscaler & Jan Tytgat @jantytgat – CTP\CTA और Citrix टीमों के साथ कई मोर्चों पर काम करने का निरंतर प्रयास।
• KevTheHermit @KevTheHermit – CVE के ऊपर AWS इंस्टेंस पासवर्ड भेद्यता प्रकटीकरण
• Bad Packets Report @bad_packets – पूरी Bad Packets टीम https://badpackets.net
• Kevin Beaumont @GossiTheDog – समस्याओं का भारी प्रचार, साथ ही उनके हनीपॉट और उन्होंने जो देखा, उसके कुछ विवरण।
• Mpgn @mpgn_x64 – एक्सप्लॉइट और एक्सप्लॉइट की विविधताओं पर विवरण
• Nick Carr @ItsReallyNick – एक्सप्लॉइट पर विवरण और घटना प्रतिक्रिया युक्तियाँ।
• Digi Cat u/digicat – Reddit उपयोगकर्ता, अद्भुत चल रहा समाचार ब्लॉग।
• Ben Sadeghipour @NahamSec – DFIR YouTube वीडियो और अन्य योगदान
• SANs टीम – लेख और DFIR और डीप डाइव वीडियो
• Craig Dods @0xCraig – पासवर्ड निहितार्थ और अनुसंधान
• Manuel Kolloff @manuelkolloff – शोषण के बाद एक्सप्लॉइट वॉकथ्रू।
• FireEye और Mandiant टीम टीम हमारे सबसे शुरुआती डिटेक्शन कवरेज बनाने के लिए Rick Cole को धन्यवाद, और इस ब्लॉग के लिए इनपुट हेतु Mandiant घटना प्रतिक्रियाकर्ताओं की टीम—विशेष रूप से Austin Baker, Brandan Schondorfer और John Prieto—और उन सभी सलाहकारों को जो अपने ग्राहकों के वातावरण को इस भेद्यता से प्रतिक्रिया या सुरक्षित कर रहे हैं। हमारी Vulnerability Intelligence टीम से Nicholas Luedtke को भी धन्यवाद, इस ब्लॉग के प्रकटीकरण और टूलिंग समयरेखा को परिष्कृत करने में उनकी सहायता के लिए।