gteissier/cve-2016-6271ZRTP मैन-इन-द-मिडल (man-in-the-middle) हमले के लिए अवधारणा का प्रमाण
CVE-2016-6271 का प्रभाव libbzrtp पर पड़ता है, जो कि Belledonne Communications द्वारा विकसित एक ZRTP लाइब्रेरी है।
यह लाइब्रेरी अंतिम-उपयोगकर्ता अनुप्रयोगों में एम्बेडेड होती है, उदाहरण के लिए linphone, जो Play store पर Android ऐप के रूप में उपलब्ध है। वर्तमान संस्करण 3.2.7 में एम्बेडेड libbzrtp का संस्करण CVE-2016-6271 के प्रति असुरक्षित नहीं होना चाहिए।
cd vulnerable-bzrtp && docker build -t vulnerable-bzrtp .
cd mitm-bzrtp && docker build -t mitm-bzrtp .
docker-compose -f cve-2016-6271.yaml up
ZRTP वॉयस ओवर IP कॉल को सुरक्षित करने का एक समाधान है।
निम्नलिखित IETF rfc6189 से एक उद्धरण है:
ZRTP एक कुंजी समझौता प्रोटोकॉल है जो कॉल सेटअप के दौरान मीडिया पथ में डिफी-हेलमैन कुंजी विनिमय करता है और इसे उसी पोर्ट पर ले जाया जाता है जिस पोर्ट पर रियल-टाइम ट्रांसपोर्ट प्रोटोकॉल (RTP) [RFC3550] मीडिया स्ट्रीम स्थापित की गई है, जो सिग्नलिंग प्रोटोकॉल जैसे सेशन इनिशिएशन प्रोटोकॉल (SIP) [RFC3261] का उपयोग करके स्थापित की गई है। यह एक साझा रहस्य उत्पन्न करता है, जिसका उपयोग फिर सिक्योर RTP (SRTP) [RFC3711] सत्र के लिए कुंजी और साल्ट उत्पन्न करने के लिए किया जाता है। ZRTP [PGPfone] से विचार उधार लेता है। ZRTP का एक संदर्भ कार्यान्वयन [Zfone] में उपलब्ध है।
ZRTP प्रोटोकॉल में कुछ अच्छी क्रिप्टोग्राफिक विशेषताएँ हैं जो मीडिया सत्र एन्क्रिप्शन के कई अन्य दृष्टिकोणों में नहीं पाई जाती हैं। यद्यपि यह एक पब्लिक की एल्गोरिदम का उपयोग करता है, यह पब्लिक की इंफ्रास्ट्रक्चर (PKI) पर निर्भर नहीं करता है। वास्तव में, यह स्थायी पब्लिक की का बिल्कुल भी उपयोग नहीं करता है। यह हैश प्रतिबद्धता के साथ एफेमेरल डिफी-हेलमैन (DH) का उपयोग करता है और उपयोगकर्ताओं को फोन पर पढ़ने और मौखिक रूप से तुलना करने के लिए एक छोटी प्रमाणीकरण स्ट्रिंग (SAS) प्रदर्शित करके मैन-इन-द-मिडल (MiTM) हमलों का पता लगाने की अनुमति देता है।
संक्षेप में:
एक असुरक्षित ZRTP एजेंट को एक एकल C फ़ाइल से संकलित किया गया है:
ctx = bzrtp_createBzrtpContext(self_ssrc);
assert(ctx != NULL);
ret = bzrtp_setCallbacks(ctx, &bzrtp_callbacks);
assert(ret == 0);
bzrtp_initBzrtpContext(ctx);
bzrtp_setClientData(ctx, self_ssrc, ctx);
ret = bzrtp_startChannelEngine(ctx, self_ssrc);
assert(ret == 0);
for (now = 0; now += 50;) {
usleep(500000);
ret = recv(sd, buffer, sizeof(buffer), MSG_DONTWAIT);
if (ret > 0) {
received = ret;
bzrtp_processMessage(ctx, self_ssrc, buffer, received);
}
bzrtp_iterate(ctx, self_ssrc, now);
}
इसका आनंद लेने के लिए, cd vulnerable-bzrtp && docker build -t vulnerable-bzrtp . का उपयोग करके डॉकर इमेज बनाएँ। सावधान रहें कि Dockerfile start.sh को एंट्रीपॉइंट के रूप में परिभाषित करता है, जो मैलोरी के माध्यम से रूटिंग सेट करता है - इस पर बाद में अधिक जानकारी।
30 मार्च 2016 को Belledone Communications को सूचित किया गया, इस भेद्यता को इस कमिट के साथ तुरंत ठीक कर दिया गया था।
ZRTP DHPart1 और DHPart2 नामक दो संदेशों में डिफी-हेलमैन करता है। बॉब उस DHPart2 संदेश को प्रतिबद्ध करता है जो वह एलिस का DHPart1 प्राप्त करने के बाद भेजेगा।
| Commit (Bob's ZID, options, hash value) F5 |
|<--------------------------------------------------|
| F6 DHPart1 (pvr, shared secret hashes) |
|-------------------------------------------------->|
| DHPart2 (pvi, shared secret hashes) F7 |
|<--------------------------------------------------|
bzrtp में खोजी गई भेद्यता हैश-प्रतिबद्धता सत्यापन की अनुपस्थिति है, जो एक हमलावर को दिलचस्प गुणों वाले pvi को जाली बनाने की गुंजाइश छोड़ती है।
यह प्रूफ ऑफ कॉन्सेप्ट rfc6189 में वर्णित कमजोरी को लागू करता है:
DH एक्सचेंज में हैश प्रतिबद्धता का उपयोग हमलावर को अपने हमले में सही शॉर्ट ऑथेंटिकेशन स्ट्रिंग (SAS) (धारा 7) उत्पन्न करने के लिए केवल एक अनुमान तक सीमित रखता है, जिसका अर्थ है कि SAS काफी छोटा हो सकता है। एक 16-बिट SAS, उदाहरण के लिए, हमलावर को पकड़े जाने की 65536 में से केवल एक संभावना प्रदान करता है। इस हैश प्रतिबद्धता सुविधा के बिना, एक MiTM हमलावर अपने स्वयं के दो DH सार्वजनिक मानों को अपने MiTM हमले के लिए चुनने से पहले दोनों पक्षों से pvi और pvr सार्वजनिक मान प्राप्त कर लेगा। वह फिर उस जानकारी का उपयोग दोनों पक्षों के लिए कई परीक्षण DH गणनाएँ शीघ्रता से करने के लिए कर सकता है जब तक कि उसे मेल खाने वाला SAS न मिल जाए। इस जन्मदिन हमले की लागत बढ़ाने के लिए, SAS को बहुत लंबा होना होगा। शॉर्ट ऑथेंटिकेशन स्ट्रिंग को लॉन्ग ऑथेंटिकेशन स्ट्रिंग बनना होगा, जो उपयोगकर्ता के लिए अस्वीकार्य होगा। हैश प्रतिबद्धता इस हमले को रोकती है, जिससे MiTM को दोनों पक्षों में से किसी भी पक्ष के सार्वजनिक मानों को जानने से पहले अपने स्वयं के दो DH सार्वजनिक मानों को चुनने के लिए मजबूर होना पड़ता है।
मैलोरी के सक्रिय हमलावर होने के साथ, उपरोक्त DH एक्सचेंज इस प्रकार हो जाता है:
Bob Mallory Alice
| | Commit (Alice's ZID...) |
| |<------------------------|
| Commit (Alice's ZID...) | |
|<------------------------| |
| | |
| DHPart1 (pvr...) | |
|------------------------>| |
| | DHPart1 (pvr'...) |
| |------------------------>|
| | DHPart2 (pvi...) |
| |<------------------------|
| * SAS(Mallory, Alice) is known at this time * |
| * now find a pvi' such as SAS(Bob, Mallory) * |
| * equals SAS(Mallory, Alice) * |
| DHPart2(pvi'...) | |
|<------------------------| |
| * SAS(Mallory, Bob) = SAS(Alice, Mallory) * |
| * Both parties will confirm they share the same * |
| * SAS value * |
| * Note that SRTP material (Alice, Mallory) will * |
| * not match SRTP material (Mallory, Bob) * |
| * However, Mallory will be able to handle SRTP * |
| * flows from both Bob and Alice, giving * |
| * interception and tampering capabilities. * |
यह Python3 और asyncio पर बनाया गया है। रॉ IP पैकेट को PF_PACKET सॉकेट का उपयोग करके कैप्चर किया जाता है, केवल IPv4 फ्रेम पर सुनने के लिए। Scapy रॉ फ्रेम को विघटित करने में मदद करता है। यह ZRTP पैकेट का विश्लेषण करता है और उन्हें पुनर्लेखित करता है, विशेष रूप से, यह HMAC प्रमाणीकरण टैग की पुनर्गणना करता है।
SAS ब्रूटफोर्सर C आधारित है और इनपुट के रूप में लेता है:
Hello of responder || Commit || DHPart1DHPart1 में प्रतिसादकर्ता द्वारा भेजा गया सार्वजनिक मानcd mitm-bzrtp && docker build -t mitm-bzrtp . && cd .. का उपयोग करके डॉकर इमेज बनाएँ।
मैन-इन-द-मिडल को इसकी सहायता से सेट किया जाएगा:
एलिस और बॉब मैलोरी के माध्यम से आदान-प्रदान करेंगे, जो अवसरवादी रूप से मैन-इन-द-मिडल हमला करता है।
यह विभिन्न svi का परीक्षण करने और यह जाँचने पर निर्भर करता है कि व्युत्पन्न SAS पहले से प्राप्त SAS से मेल खाता है या नहीं। सभी भयानक विवरण ब्रूटफोर्स स्रोत में पाए जा सकते हैं।
ZRTP संदेशों को पुनरावृत्त हैश की उलटी श्रृंखला का उपयोग कुंजी के रूप में करके प्रमाणित किया जाता है। यदि मैलोरी द्वारा DHPart2 को उड़ान में संशोधित किया जाता है, तो एलिस मैलोरी के विकृत DHPart2 को प्रामाणिक नहीं मानेगी, क्योंकि गणना किया गया HMAC प्राप्त HMAC से मेल नहीं खाएगा। इस जाँच को पास करने के लिए, मैलोरी को पुनरावृत्त हैश की पूरी श्रृंखला का उपयोग करना होगा, और उसे इस श्रृंखला का उपयोग करके सभी भेजे गए संदेशों पर हस्ताक्षर करना होगा।