OpenSSL हार्दिक भेद्यता संदर्भ

एक हमलावर क्या जान सकता है

TLS सर्वर की निजी कुंजी, TLS क्लाइंट की निजी कुंजी (यदि ग्राहक असुरक्षित है), कुकीज़, लॉगिन, पासवर्ड और सर्वर और उसके ग्राहकों के बीच किसी अन्य डेटा का आदान-प्रदान किया जाता है। इस मामले में, संचार चैनल को सुनने के लिए आवश्यक नहीं है, यह विशेष रूप से गठित पैकेट भेजने के लिए पर्याप्त है, और सर्वर लॉग में इसका पता नहीं लगाया जा सकता है।

भेद्यता दो-तरफा है: यदि संवेदनशील क्लाइंट हमलावर सर्वर से जुड़ता है, तो हमलावर क्लाइंट प्रक्रिया मेमोरी को पढ़ सकता है। कमजोर ग्राहकों का उदाहरण: मारियाडीबी, वेट, कर्ल, गिट, नेग्नेक्स (प्रॉक्सी मोड में)।

भेद्यता का परीक्षण कैसे करें

वेब सेवाएँ:
- filippo.io/Heartbleed ,
- www.ssllabs.com/ssltest ,
- rehmann.co/projects/heartbeat ,
- possible.lv/tools/hb
ग्राहक के लिए परीक्षण करें: revheartbleed.com
पायथन लिपि: gist.github.com/sh1n0b1/10100394 , gist.github.com/mitsuhiko/10130454
गो ऑन स्क्रिप्ट: github.com/titanous/heartbleeder
वेबसाइट सांख्यिकी: gist.github.com/dberkholz/10169691

कौन से सिस्टम हैं कमजोर?

- ओपनएसएसएल 1.0.1 - 1.0.1f, 1.0.2-बीटा 1 में कमजोरियां, ओपनएसएसएल 1.0.1 जीजी और 1.0.2-बीटा 2 ( सेकंड ) में भेद्यता तय की गई है।
- OpenVPN, विंडोज सहित - संस्करण I004 में तय ( डाउनलोड )
- कोई भी कार्यक्रम जो कि ओपनएसएसएल के एक असुरक्षित संस्करण से सांख्यिकीय रूप से जुड़ा हुआ है।
- तोर ( ब्लॉग )।

- डेबियन व्हीज़ी (स्थिर) - ओपनएसएसएल -2e + डिब्यू 7 में तय किया गया है और डायने -2 + डेब्यू 6 ( सुरक्षा )
- Ubuntu 12.04.4 LTS - ओपनएसएसएल 1.0.1-4ubuntu5.12 ( USN ) में तय किया गया
- CentOS 6.5 - खुलने के समय तय किया गया-1.0.1e-16.el6_5.7 (सेंटोस -घोषणा )
- Redhat 6.5 - खुलने में तय- 1.0.1e-16.el6_5.7 ( समाधान , इरेटा , बुगिला)
- फेडोरा 19 और 20 - खुलने में तय- 1.0.1e-37 ( घोषणा )
- Gentoo - खुलने में तय- 1.0.1g ( GLSA )
- स्लैकवेयर 14.0 और 14.1 - खुलने के समय नियत- 1.0.1g ( स्लैकवेयर-सुरक्षा )
- OpenSUSE 12.3 और 13.1 - खुलने में तय- 1.0.1e (ओपनस्यूज -सुरक्षा-घोषणा )
- FreeBSD 10.0 - 10.0-RELEASE-p1 ( सलाह ) में तय
- ओपनबीएसडी 5.3 और 5.4 ( पैच )
- नेटबीएसडी 5.0.2
- अमेज़ॅन - ओपनएसएसएल 1.0.1e-37.66 ( सुरक्षा-बुलेटिन ) में तय किया गया
- एंड्रॉइड 4.1.1 - भेद्यता के बिना अन्य संस्करण।

वे आमतौर पर कमजोर पुस्तकालय पर निर्भर करते हैं और उन्हें पुनः आरंभ करने की आवश्यकता होती है:
- वेब सर्वर: Nginx, Apache, मेल सर्वर: Postfix, Dovecot, Jabber और अन्य IM: eberberb,
- MySQL, अगर TLS को प्राधिकरण के लिए उपयोग किया जाता है और यह OpenSSL पर निर्भर करता है: CentOS, RedHat (रेमी सहित), पेरकोना सर्वर ( ब्लॉग ) पर।

जो कमजोर नहीं है

- विंडोज (कोई ओपनएसएसएल), मैकओएस (ओपनएसएसएल का पुराना संस्करण), फ़ायरफ़ॉक्स, थंडरबर्ड ( एनएसएस में चूक), क्रोम / क्रोमियम ( एनएसएस में चूक), एंड्रॉइड (दिल की धड़कन अक्षम है)।
- रूट और मध्यवर्ती प्रमाण पत्र, जिसके द्वारा टीएलएस सर्वर की कुंजी पर हस्ताक्षर किए जाते हैं (निजी कुंजी उन्हें सर्वर पर अनुपस्थित है)
- ओपनएसएसएच (केवल मुख्य पीढ़ी के लिए ओपनएसएसएल का उपयोग करता है)
- OpenVPN अगर यह स्थिर कुंजियों का उपयोग करता है (x509 नहीं) या यदि यह कॉन्फिग में "tls-Cort ta.key 1" फॉर्म की कुंजी का उपयोग करता है
- यूनिक्स की तरह ओएस को अपडेट वितरित करने के लिए एक विधि (सबसे अक्सर GnuPG का उपयोग हस्ताक्षर के लिए किया जाता है)।

सिस्टम को कैसे अपडेट करें

डेबियन, उबंटू

# aptitude update # aptitude -VR full-upgrade 

उसके बाद, टीएलएस का उपयोग करने वाली सेवाओं को पूरी तरह से पुनरारंभ करें। अपडेट इंस्टॉलर आपको स्वचालित रूप से पुनरारंभ करने के लिए संकेत देगा, या आप मैन्युअल रूप से कर सकते हैं:

 # service nginx restart # service apache2 restart 

सेवाओं की एक पूरी सूची जिसे फिर से शुरू करने की आवश्यकता है और कमजोर हो सकती है:

 # lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)'  # checkrestart 

यदि आप निश्चित नहीं हैं, तो सर्वर को पूरी तरह से रिबूट करना बेहतर है।
संस्करण की जाँच करें:

 # dpkg -l | grep -i openssl # aptitude changelog openssl 

सेंटोस, रेडहैट, फेडोरा

 # yum update 

उसके बाद, उदाहरण के लिए, टीएलएस का उपयोग करने वाली सेवाओं को पूरी तरह से पुनः आरंभ करें:

 # service nginx restart # service httpd restart 

सेवाओं की एक पूरी सूची जिसे फिर से शुरू करने की आवश्यकता है और कमजोर हो सकती है:

 # lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)'  # needs-restarting 

यदि आप निश्चित नहीं हैं, तो सर्वर को पूरी तरह से रिबूट करना बेहतर है।
संस्करण की जाँच करें:

 # yum list openssl # rpm -q --changelog openssl 

FreeBSD

 # freebsd-update fetch # freebsd-update install 

उसके बाद, उदाहरण के लिए, टीएलएस का उपयोग करने वाली सेवाओं को पूरी तरह से पुनः आरंभ करें:

 # service nginx restart # service apache22 restart 

यदि आप निश्चित नहीं हैं, तो सर्वर को पूरी तरह से रिबूट करना बेहतर है।
संस्करण की जाँच करें:

 # freebsd-version 

TLS कुंजियों को बदलना और पासवर्ड बदलना

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

- अगर क्लाइंट ब्राउजर ने बिना हैश + सॉल्ट के साइट पर पासवर्ड डाले हैं, लेकिन शुद्ध रूप में, तो इन पासवर्ड से भी समझौता किया जा सकता है।

भविष्य के लिए

- आपको यह सुनिश्चित करने की आवश्यकता है कि ब्राउज़र यह देखने के लिए जांच करता है कि क्या जिस साइट पर वह जा रहा है उसका प्रमाण पत्र निरस्त कर दिया गया है या नहीं।
फ़ायरफ़ॉक्स ओएससीपी को डिफ़ॉल्ट रूप से जांचता है, और हाल के संस्करण भी ओसीएसपी स्टेपलिंग का समर्थन करते हैं; मैक ओएस एक्स 10.7 (शेर) के साथ डिफ़ॉल्ट रूप से सफारी की जांच; Chrome डिफ़ॉल्ट रूप से चेक नहीं करता है (सेटिंग अनुभाग HTTPS / SSL में), OCSP स्टेपलिंग समर्थित नहीं है; Internet Explorer डिफ़ॉल्ट रूप से OSCP की जाँच करता है, लेकिन OCSP स्टेपलिंग का समर्थन नहीं करता है; ओपेरा डिफ़ॉल्ट रूप से OSCP की जाँच करता है; सफारी डिफ़ॉल्ट रूप से OSCP की जाँच नहीं करता है। विभिन्न ब्राउज़रों के लिए सेटिंग्स ।

- सर्वर पर, परफेक्ट फॉरवर्ड सीक्रेसी (PFS) को इनेबल करना वांछनीय है। इस मामले में, यहां तक ​​कि अगर निजी कुंजी से समझौता किया जाता है, तो भी हमलावर अतीत या भविष्य के खोए हुए ट्रैफ़िक को डिक्रिप्ट नहीं कर पाएगा। ऐसा करने के लिए, इलिप्टिक कर्व डिफी-हेलमैन एपेमेरल (ईसीडीएचई) या डिफी-हेलमैन एपेमेरल (डीएचई) को सक्षम करें। सर्वर सेटअप , परीक्षण ।