Кампанія Mozilla абвясціла аб завяршэнні незалежнага аўдыту кліенцкага ПЗ для падлучэння да сэрвісу Mozilla VPN. Падчас аўдыту быў выкананы аналіз адасобленага кліенцкага прыкладання, напісанага з выкарыстаннем бібліятэкі Qt і які пастаўляецца для Linux, macOS, Windows, Android і iOS. Працу Mozilla VPN забяспечвае больш за 400 сервераў шведскага VPN-правайдэра Mullvad, размешчаных у больш за 30 краінах. Падключэнне да VPN-сэрвісу робіцца пры дапамозе пратакола WireGuard.
Аўдыт выкананы кампаніяй Cure53, якая ў свой час праводзіла аўдыт праектаў NTPsec, SecureDrop, Cryptocat, F-Droid і Dovecot. Аўдыт закранаў праверку зыходных тэкстаў і ўключаў правядзенне тэстаў для выяўлення магчымых уразлівасцяў (пытанні, злучаныя з крыптаграфіяй не разглядаліся). У ходзе праверкі выяўлена 16 праблем з бяспекай, 8 з якіх мелі характар рэкамендацый, 5 прысвоены нізкі ўзровень небяспекі, дзвюм - сярэдні, а адной - высокі.
Пры гэтым толькі адна праблема са сярэднім узроўнем небяспекі была аднесеная да катэгорыі ўразлівасцяў, бо толькі яна была прыдатная для эксплуатацыі. Указаная праблема прыводзіла да ўцечкі звестак аб ужываннях VPN у кодзе для вызначэння captive portal з-за адпраўкі незашыфраваных прамых запытаў па HTTP, якія перадаюцца па-за VPN-тунэлем і што расчыняюць асноўны IP-адрас карыстача ў выпадку калі атакавалы можа кантраляваць транзітны трафік. Праблема вырашаецца адключэннем рэжыму вызначэння captive portal у наладах.
Другая праблема сярэдняга ўзроўня небяспекі злучана з адсутнасцю належнай чысткі нелікавых значэнняў у нумары порта, што дазваляе арганізаваць уцечку параметраў аўдэнтыфікацыі OAuth праз падмену нумара порта на радок выгляду.[электронная пошта абаронена]», што прывядзе да ўстаноўкі тэга[электронная пошта абаронена]/?code=…» alt=»»>, які звяртаецца да example.com замест 127.0.0.1.
Трэцяя праблема, пазначаная як небяспечная, дазваляе любому лакальнаму з дадаткам без аўтэнтыфікацыі звярнуцца да VPN-кліенту праз WebSocket, прывязаны да localhost. У якасці прыкладу паказана, як пры актыўным VPN-кліенце любы сайт мог арганізаваць стварэнне і адпраўку скрыншота праз генерацыю падзеі screen_capture. Праблема не аднесена да катэгорыі ўразлівасцяў, бо WebSocket выкарыстоўваўся толькі ва ўнутраных тэставых зборках і ўжыванне дадзенага канала сувязі толькі планавалася ў будучыні для арганізацыі ўзаемадзеяння з браузерным дадаткам.
Крыніца: opennet.ru