CONFIDENȚIALITATE
Cine poate citi pachetul?
SRTP transformă vocea sau imaginea într-un flux pe care un observator fără cheie nu îl poate citi.
CHEIE / CONȚINUT
INTELLIGENCE OBJECT / COMMS ASSURANCE
Criptat pentru cine?
Un apel poate păstra un lacăt pe pachete și totuși să ajungă la persoana greșită. Într-un studiu USENIX Security '26, 19 din 33 de servere media WebRTC au eșuat la autentificarea DTLS; în 9 cazuri, cercetătorii au recuperat media sau date protejate. [1]
FIELD PLATE / 01O cheie poate ajunge la persoana greșită.
A
Participant⌁
media criptatăM
Server media33implementări media-server testate
19au eșuat la autentificarea DTLS
9au permis recuperarea media sau a datelor protejate
01 / MECANISM
Comută singura verigă care schimbă rezultatul: verificarea identității. Restul scenei rămâne aceeași, tocmai ca diferența să fie vizibilă.
Verificarea identității
activăIdentitate verificată / media rămâne pe traseul așteptat
A
PARTICIPANTI
INTERMEDIAR / CERTIFICAT FALSM
SERVER MEDIACertificatul se potrivește.
Serverul compară identitatea prezentată cu cea așteptată. Orice intermediar cu alt certificat este oprit înainte ca cheia media să fie folosită.
Fără JavaScript, scena de mai jos arată cazul în care identitatea este verificată.
02 / DOUĂ ÎNTREBĂRI
Criptarea și autentificarea nu răspund la aceeași întrebare.
Confuzia apare când vedem lacătul și presupunem că am verificat și interlocutorul.
AUTENTICITATE
Cu cine ai negociat cheia?
DTLS trebuie să lege cheia de identitatea corectă. Dacă certificatul intermediarului este acceptat, criptarea poate continua cu adversarul deja instalat în conversație.
IDENTITATE / CHEIE
Când evaluezi un apel, întreabă cine a fost verificat înainte ca cheia să fie folosită.
03 / DOVEZI
19 este măsura eșecului. 9 este măsura impactului demonstrat.
Studiul nu transformă fiecare eroare de autentificare într-o interceptare completă. Separă testul care a eșuat de cazul în care media sau datele protejate au fost efectiv recuperate.
Cercetătorii au testat 33 de implementări media-server, folosite de 24 de furnizori. Browser-ele Chromium, Firefox și Safari nu au arătat același bypass direct de autentificare; problema a apărut la compoziția server-side a protocolului. [1]
Faptul că 19 teste au eșuat spune ceva despre identitate. Faptul că 9 au ajuns la media sau la date protejate spune ceva despre consecință. Cele două numere răspund la întrebări diferite.
SCARA DOVEZII
33
implementări testate
19
eșecuri de autentificare DTLS
9
recuperare media sau date protejate
DOCUMENTAT
Vulnerabilități și rezultate de testare raportate în lucrare
INFERENȚĂ
Un server media este o parte critică din garanția conversației
NECUNOSCUT
Dacă vreun serviciu de informații a folosit aceste căi
04 / CAZURI
Ce s-a văzut în implementări
Rândurile de mai jos pun testele istorice lângă remedierea anunțată de furnizori. O rezolvare într-un produs nu elimină riscul de design din toate produsele.
| Sistem | Observație | Media / date | Situație publică |
|---|---|---|---|
| Webex | Un certificat gol a fost acceptat; PoC-ul Cisco a primit audio dintr-o întâlnire proprie. | Audio recuperat în scenariul controlat | CVE-2025-20215 / remediat în cloud |
| Zoom | Clientul nu a cerut autentificarea necesară a clientului. | Bypass de autentificare cu severitate ridicată | Remediat / raportat prin programul de bug bounty |
| Discord | Două căi de bypass în testele din 2022 și 2024. | Impact raportat și confirmat de furnizor | Remediat / bounty |
| Steam | Server media care a continuat după bypass. | Media disponibilă cercetătorilor | Confirmat / remediat |
| Vonage | Certificatul clientului web nu era cerut sau verificat corect. | Media disponibilă cercetătorilor | Confirmat / remediat |
| RingCentral | Autentificarea clientului nu era cerută pe calea testată. | RTP disponibil după bypass | Confirmat / remediat |
| Teams | Certificat gol sau arbitrar acceptat pe handshake; nu s-a recuperat RTP. | Metadate RTCP în clar; media RTP nu a fost demonstrată | În afara programului de bounty / caz limitat |
| Browsere | Chromium, Firefox și Safari nu au prezentat bypass direct comparabil. | Niciun rezultat de media-server | Comparație de control |
Pentru detaliile fiecărui rând și nuanțele de divulgare, vezi lucrarea și advisory-ul Cisco. [2] [3]
05 / POZIȚIA NECESARĂ
Un număr de întâlnire nu este suficient.
Calea demonstrată cere o poziție de tip man-in-the-middle. Atacatorul trebuie să poată observa și modifica traficul dintre participant și infrastructura media.
Un străin cu doar un ID de întâlnire nu poate folosi această cale. Ea devine relevantă după ce cineva preia controlul asupra unei porțiuni din rețea.
DISTANȚĂ / FĂRĂ POZIȚIE
Străinul cu doar ID-ul întâlnirii
Poate încerca să intre în întâlnire prin căile normale ale serviciului. Nu are însă, doar din ID, poziția necesară pentru a intercala un handshake între participant și serverul media.
CAPABILITATE DEMONSTRATĂ: NU
LOCAL / ADIACENT
Router sau Wi-Fi compromis
Un dispozitiv compromis pe traseul local poate observa și modifica traficul. Advisory-ul Cisco descrie pentru Webex o condiție de rețea locală sau adiacentă, plus interceptarea traficului.
CAPABILITATE DEMONSTRATĂ: DA, ÎN CONDIȚII CONTROLATE
SEGMENT CONTROLAT
ISP sau segment monitorizat
Cine controlează un segment de rețea poate vedea mai mult trafic, în funcție de rutare și de felul în care participantul ajunge la serviciu. Studiul nu spune că această capacitate a fost folosită de un serviciu de informații.
INFERENȚĂ DE RISC: PLAUZIBILĂ / NEOBSERVATĂ
Pentru CVE-2025-20215, Cisco a spus că atacatorul trebuie să fie network-proximate, să intercepteze traficul și că PSIRT nu avea cunoștință de exploatare malițioasă. [3]
06 / LECTURĂ DE INTELLIGENCE
Ce merită întrebat înainte să numești o conversație sigură
Cercetarea ține separat protocolul, infrastructura și capacitatea adversarului.
PROTOCOL / INFRASTRUCTURĂ / CAPACITATE
Trei straturi păstrează evaluarea proporțională.
- Unde se termină media: la participanți sau la un server care negociază separat cu fiecare parte?
- Ce identitate verifică serverul înainte să accepte cheia?
- Ce se întâmplă când verificarea certificatului eșuează? Se blochează handshake-ul sau continuă sesiunea?
- Care este poziția de rețea necesară pentru a modifica acel handshake?
- Există un advisory primar și o remediere verificabilă?
Lucrarea susține o concluzie precisă: o parte critică din securitatea unui apel poate locui în serverul media, iar un defect de autentificare poate lăsa criptarea intactă în timp ce schimbă cine deține cheia. Nu știm dacă un serviciu de informații a folosit aceste căi.
Întrebarea de ținut minte: cine verifică identitatea înainte ca cheia să fie folosită?
07 / SURSE ȘI LIMITE
Citește sursele
Lucrarea este sursa centrală. Advisory-ul Cisco verifică un caz concret și remedierea. Documentația WebRTC explică diferența dintre criptarea media și autentificare.
Fiecare card spune ce susține sursa și unde se oprește.
01 / primary
Breaking and Entering: How Media Servers Compromise the Security of WebRTC
The 24-provider, 33-media-server study; 19 DTLS-layer client-authentication failures; nine affected implementations with demonstrated media or protected-data retrieval; the Webex proof of concept; vendor outcomes and the browser comparison.
Limită: The tests used controlled accounts and sessions. They show what an attacker can do from a required man-in-the-middle position; they do not establish widespread interception or use by an intelligence service.
Deschide sursa ↗02 / primary
Breaking and Entering: How Media Servers Compromise the Security of WebRTC, prepublication PDF
The call sequence, DTLS and SRTP relationship, test taxonomy, packet-level evidence, Webex packet flow, responsible-disclosure record and the artifact archive.
Limită: The PDF is the research record. It does not provide a live status page for every vendor or prove that a historical implementation remains exposed.
Deschide sursa ↗03 / primary
Cisco Webex App Vulnerability Could Allow Unauthenticated Join
CVE-2025-20215, the network-proximate prerequisite, the Webex remediation status and Cisco's statement that PSIRT was unaware of malicious use at publication.
Limită: A vendor advisory covers the affected product and its fix. It cannot establish whether an unrelated actor used the capability.
Deschide sursa ↗04 / secondary
Paper accepted at USENIX Security 2026
The public research context and the scale framing around providers, media servers and network interception.
Limită: This is a summary page. The peer-reviewed paper remains the authority for methods, counts and individual case details.
Deschide sursa ↗05 / primary
SRTP in WebRTC
The protocol distinction that WebRTC media uses SRTP and that DTLS-SRTP negotiates the keys used by the media channel.
Limită: Protocol documentation explains the intended mechanism. It does not certify that every server composition validates identities correctly.
Deschide sursa ↗06 / primary
Breaking and Entering: supplementary artifacts
The paper's released supporting material, including traces and artifacts associated with the study.
Limită: Artifacts make the research inspectable; they still represent controlled experiments rather than an operational threat-intelligence collection.
Deschide sursa ↗Stare editorială: actualizat la 14 august 2026. Lucrarea raportează testări istorice și remediere acolo unde furnizorii au confirmat-o; reanaliza este declanșată de o nouă versiune primară a cercetării, un advisory material nou sau o schimbare de statut la furnizor.