Всеки в мрежата ви би могъл да поеме контрол над Mac с включено споделяне на екрана (Screen Sharing). Всичко, което е било необходимо на атакуващия, е IP адресът на целевата машина. Проверката за влизане в системата е връщала стара стойност за успешна операция и машината е приемала това за вярно.

Споделянето на екрана е функция в macOS, която позволява на потребител от друг компютър да се свърже с вашия Mac, да вижда работния плот и да го контролира, сякаш седи точно пред него. По подразбиране тя е изключена и се активира от системните настройки (System Settings), когато искате да осъществите достъп до собствената си машина от друга стая или друг град. На 6 август Apple пусна macOS Tahoe 26.6.1, Sequoia 15.7.9 и Sonoma 14.8.9, за да отстрани уязвимост в тази услуга, проследявана като CVE-2026-65400. Услугата е можела да бъде подведена да третира връзката като успешна сесия, без изобщо да е извършено влизане.

Влизането в системата е предвидено да работи по следния начин: Когато се свързвате, вашият Mac трябва да е сигурен, че знаете паролата за акаунта, и проверява това чрез метод, наречен Secure Remote Password (SRP). Полезната част на SRP е, че самата парола никога не се предава по мрежата. Вместо това двете страни обменят поредица от математически стойности, които позволяват на всяка страна да докаже, че знае паролата, без да я изпраща. Този обмен протича чрез няколко последователни съобщения, като една от стъпките проверява дължината на входящото съобщение, преди да премине към следващата.

В уязвимите версии тази проверка на дължината е връщала стара стойност за успех, останала от предишна стъпка. Фоновата програма, която изпълнява услугата – screensharingd – е прочитала тази остаряла стойност „всичко е наред“ и е третирала връзката така, сякаш проверката на паролата вече е преминала успешно. Стъпката с паролата е била напълно прескачана. За това не е необходим акаунт на машината, нито парола, дори по-старата единична VNC парола, на която някои конфигурации все още разчитат.

Съществува и втори проблем, насложен над първия. След като връзката се осъществи по този начин, тя продължава да работи без никакво шифроване. Обикновено тази сесия се шифрова, така че някой по трасето да не може да я прочете. В този случай тя работи в чист текст, което означава, че трафикът е напълно отворен и некриптиран, освен че е неаутентифициран.

След като screensharingd повярва, че сте влезли в системата, той прехвърля работата с файлове на две отделни помощни програми, като разликата между тях определя докъде може да стигне атакуващият. Четенето се извършва чрез SSFileCopySender. Този помощник носи частно, подписано от Apple разрешение, наречено kTCCServiceSystemPolicyAllFiles. Това разрешение осигурява пълен достъп до диска (Full Disk Access) – най-високото файлово разрешение в macOS, и заобикаля директно TCC – частта от macOS, която обикновено показва прозорец с предупреждение „еди-кой си иска достъп до вашите файлове“ и чака да кликнете „Да“. Така атакуващият чете файлове с права на root (администраторския акаунт, който има достъп до всичко в системата), без TCC изобщо да изисква потвърждение.

Можете да видите това разрешение сами. Стартирането на съответната проверка на Mac отпечатва правата на помощната програма, където се вижда kTCCServiceSystemPolicyAllFiles. Точно това право позволява на файловия помощник да достигне до всеки файл на диска, след като компрометираното влизане му е осигурило достъп. С комбинирането на root права и пълен достъп до диска, атакуващият може да извлече всичко от машината – от запазени документи и конфигурационни файлове до SSH ключове и данни от браузъра.

Записването се извършва чрез втория помощник, SSFileCopyReceiver, при който ситуацията е различна. Той също работи като root, но не притежава такова разрешение и се намира в изолирана среда (sandbox), която блокира точно два пътя: директорията на crontab и /etc/crontab. Останалата част от местата, на които root може да записва, остават отворени, включително /etc, /Library/LaunchDaemons и /Library/Preferences.

Четенето и писането на файлове като root вече е сериозен проблем, но изследователите са стигнали и стъпка по-напред – до стартиране на собствени програми на машината. Един от начините е записване на файл в /Library/LaunchDaemons (папка, която macOS чете при стартиране), така че кодът на атакуващия да се изпълни при следващото рестартиране на компютъра. Друг начин е редактиране на конфигурационен файл на обвивката (shell), като например /etc/zshenv, който се изпълнява в момента, в който някой отвори Terminal. И двата метода работят на стандартен Mac с включена защита на системната цялост (SIP). Най-чистият път – root crontab – е този, който изолираната среда и SIP блокират заедно, така че той работи само на машини с изключен SIP. Защитата на системната цялост (SIP) е слой за сигурност в macOS, който пречи дори на root потребителя да прави промени в защитени части на системата.

Уязвимост като тази се нарича pre-auth (съкратено от pre-authentication / преди удостоверяване). Това означава, че грешката се задейства преди системата да е проверила кой сте, така че стандартните защити никога не се активират. Това е най-опасната категория уязвимости, тъй като няма акаунт, който да бъде заключен, няма лимит за грешни опити, който да бъде достигнат, и силата на паролата е без значение. Стъпката, която би трябвало да спре атакуващия, е точно тази, която се прескача.

Обичайните съвети за защита на отдалечения достъп не помагат тук по същата причина. Премахването на акаунтите, които имат право на отдалечен достъп, например, не предотвратява атаката.