Нещодавно Наталі Сільванович з команди Google Project Zero опублікувала пост, де пояснила деталі двох знайдених вразливостей в програмі для відеодзвінків Zoom. Компанію було ще раніше повідомлено. Вона дала детальний аналіз вразливостей, які полягали в переповненні буфера та витоку інформації; обидва виправлені 24 листопада 2021 року. Перша вразливість торкнулася як клієнтів Zoom, так і серверів MMR, а друга могла використовуватися зловмисниками лише на серверах MMR.
У контексті вона згадала про атаку нульовогу кліку в клієнті Windows Zoom, яка була продемонстрована на торішньому Pwn2Own і показала фахівцям, що у Zoom дійсно є можливість повної віддаленої атаки. Уразливостям було присвоєно відповідні ідентифікації CVE-2021-34423 і CVE-2021-34424.
Фахівець каже, що вона не робила жодних попередніх спроб протестувати Zoom, оскільки вважала, що його зламуватимуть менше в порівнянні з іншим подібним програмним забезпеченням. Вона пояснила, що в більшості типів такого програмного забезпечення користувач лише повинен прийняти дзвінок або відхилити його, тоді як у Zoom дзвінки плануються заздалегідь і приєднатися до них можна за допомогою електронного запрошення.
Тож вона продовжила думку, що у випадку з Zoom, користувачу потрібно зробити кілька кліків, щоб запустити потенційну атаку. Але минулорічний Pwn2Own довів протилежне.
Після Pwn2Own Сільванович вирішила придивитися до Zoom. У дописі, опублікованому командою Google Project Zero, вона дала огляд поверхні атаки Zoom, детально розповіла про суть вразливостей і додала можливі варіанти рішення для такого програмного забезпечення, як Zoom щодо того як покращити безпеку своїх користувачів.
Масштаб поверхні атаки
Фахівець переглянула поверхню атаки Zoom з точки зору використання її клієнтом. Основною особливістю програмного забезпечення є багатокористувацькі конференц-дзвінки, які називаються зустрічами, що дозволяють користувачам мати кілька послуг, як-от спільний доступ до екрана, текстові повідомлення під час розмови, відео та аудіо. Крім того, Zoom надає можливість встановити повнофункціональні клієнти, які можна використовувати на різних платформах, таких як iPhone, Android, Linux, Mac і Windows.
Окрім клієнта, який можна встановити, користувачі можуть приєднуватися до зустрічей через посилання браузера, але у них буде менше доступного функціоналу. Найостанніший варіант, доступний для користувачів, щоб приєднатися до зустрічі в Zoom, — це набрати номер телефону, вказаний у запрошенні, і слухати лише аудіо зустрічі.
Також користувачі можуть використовувати Zoom Contacts, які дозволяють спілкуватися окремо за допомогою повідомлень або відео. Тут ви можете просто почати дзвінок, і інша особа може прийняти його або відхилити. Дослідник назвав цю конкретну частину інтерфейсу клієнта поверхнею атаки нульового кліку Zoom. Але це не означає, що зловмисник не може просто запросити свою жертву приєднатися до зустрічі, навіть якщо для цього потрібно буде продовжити жертву, щоб зробити кілька кліків.
Небезпека може бути не стільки для окремих користувачів, скільки для публічних зустрічей в Zoom або вебінарів, платної функції в Zoom, коли велика група невідомих учасників приєднується до односторонньої відеоконференції. Оскільки відкритий характер цих функцій дозволяє зловмиснику приєднуватися без будь-яких обмежень, в основному ми маємо на увазі ідентифікацію будь-кого конкретного відвідувача, Zoom можна розглядати як “Землю Обіцянок”, до прикладу фішерів. Але не тільки безпосередньо клієнти Сільванович каже, а й дані, передані через зустріч, також можуть бути під загрозою, тому що під час зустрічі наскрізне шифрування вимикається за замовчуванням.
Огляд функції обміну повідомленнями в Zoom
Спочатку Сільванович почала роботу з дослідження поверхні атаки нульового кліку. Тут, провівши деякі технічні спостереження, вона не виявила жодних слідів вразливостей. Потім вона вирішила спостерегти, як Zoom використовує дані, надані через XMPP, відкритий протокол зв’язку, розроблений для обміну миттєвими повідомленнями (IM), інформації про присутність та підтримку списку контактів.
У Zoom він використовується здебільшого для спілкування між клієнтами Zoom за межами зустрічей, наприклад для обміну повідомлень і створення каналів, а також для сигналізації (налаштування виклику), коли контакт із Zoom запрошує інший контакт Zoom на зустріч.
Витративши деякий час на аналіз шляхів коду, фахівець тут також не виявила жодних помилок. Вона зауважує, що даний факт сам собою цікавий, оскільки Тійс Алкемаде і Даан Кеупер опублікували звіт, в якому описували вразливість знайдену там, де вона її особисто не знайшла. Слід зазначити, що дослідження було зосереджено виключно на клієнтському програмному забезпеченні Zoom, оскільки інші методи приєднання викликів працюють із наявними функціями пристрою.
Обробка RTP в Zoom
Наступне, на що звернула увагу Сільванович, це те, як клієнти Zoom обробляють аудіо- та відеоконтент. Як зазвичай і у всіх інших системах відеоконференцій, Zoom використовує транспортний протокол реального часу (RTP) для передачі цих даних. І під час дослідження в цій області вона помітила, що і сервер MMR, і клієнти Zoom обробляють велику кількість пакетів, які здається не належать ні до RTP, ні до XMPP. І саме тут вона наткнулася на вищезгадані вразливості.
Хоча дослідниці не вдалося повністю провести експлойт з використанням вразливостей, вона все ж змогла використати їх у інші неповні способи експлуатації. На її ж думку справжні зловмисники скористалися б вразливістю в повній мірі. Говорячи про Zoom RTP Processing, спеціалістка привітала включення ASLR в процес Zoom MMR і сказала, що для Zoom важливо продовжувати покращувати надійність коду MMR.
Висновки
Наприкінці Сільванович назвала кілька факторів, які, на її думку, значною мірою винуваті виявленим помилкам. І саме ці фактори зазвичай створюють проблеми у всіх програмах для відеоконференцій, як-от Zoom. Перше, на що вона звертає увагу, це великий обсяг коду в програмному забезпеченні. Було кілька частин коду, функціональність яких важко визначити. Багато класів, які можна було б десеріалізувати, здавалося, не використовуються взагалі. Великий обсяг коду ускладнює аналіз програмного забезпечення дослідниками безпеки і в той же час збільшує поверхню атаки, в якій код потенційно може містити вразливості.
Інша річ, що створює труднощі, – це використання багатьох власних форматів і протоколів. Вона пояснює, що іноді досліднику доводиться створювати інструменти для маніпулювання конкретними інтерфейсами програмного забезпечення, але з запатентованими речами при проведенні маніпуляцій потрібно більше часу, ніж потрібно. Не кажучи вже про 1500 доларів США вартості ліцензії; обидва фактори означають, що програмне забезпечення не так часто досліджують, як це повинно бути.
Закритий характер програмного забезпечення Zoom також ускладнює роботу дослідників безпеки. Багато систем відеоконференцій використовують програмне забезпечення з відкритим кодом, WebRTC або PJSIP. Звісно, вони не позбавлені проблем, але, принаймні, аналізувати їх набагато простіше.
Але все-таки найбільшою проблемою на думку фахівця була відсутність ASLR на сервері Zoom MMR. Вона пояснює, що річ є , мабуть, найважливішою в усуненні та запобіганні експлуатації пошкодження пам’яті, особливо коли інші засоби захисту залежать від цього на певному рівні. І в переважній більшості програм його не слід було б відключати, як це зараз видно з поточної спостережуваної ситуації. Звичайно, додає вона, постачальники використовують заходи безпеки, передбачені платформами, для яких вони пишуть програмне забезпечення.
Але були ідеї зменшити сприйнятливість програмного забезпечення до вразливостей, пов’язаних із пошкодженням пам’яті, шляхом вибору мов, безпечних для пам’яті, та впровадженням покращених засобів відновлення пам’яті. Тим не менш, вона вважає, що все програмне забезпечення, написане для платформ, які підтримують ASLR, повинно мати його (та інші основні засоби відновлення пам’яті) увімкненим.
