“`markdown
Відчиняємо двері в майбутнє: Чи готові ми до AI-браузерів? І чому старі помилки все ще наздоганяють?
Друзі, всі сідайте зручніше, беріть улюблену каву чи чай, і поговоримо про те, що вирує у світі технологій. Минулого тижня я натрапила на цікаву думку знайомого айтівця: “Знаєш, Ліло, ми так захопилися швидкістю прогресу, що забуваємо про найважливіше – чи безпечно нам туди йти?” І це, погодьтеся, дуже слушна думка, особливо коли мова про штучний інтелект, який з шаленою швидкістю вривається в наше життя.
Нещодавно я занурилася у світ кібербезпеки, слухаючи випуск подкасту “Security Intelligence” від IBM. Знаєте, що мене вразило? Як часто “нове” виявляється лише старою проблемою в новій обгортці. Сьогодні ми розберемося, чому експерти радять триматися подалі від AI-браузерів, чи великі технологічні компанії діляться з нами всіма секретами безпеки, і чому проблеми, яким вже десятиліття, досі очолюють списки найнебезпечніших програмних помилок. Обіцяю, буде цікаво, як добра розмова за вечерею, де обговорюють найважливіше.
Розділ 1: “Тихіше їдеш – далі будеш”: Чому AI-браузери поки що краще залишити за дверима офісу
Уявіть собі: звичайний робочий день. Ви відкриваєте браузер, щоб перевірити пошту, пошукати інформацію, можливо, відповісти на термінове повідомлення. А тут – новий, чудовий AI-браузер! Він обіцяє персоналізовану допомогу, автоматизацію рутинних завдань і взагалі – полегшує ваше життя. Звучить спокусливо, чи не так?
Але тут починається найцікавіше. Аналітики з Gartner, відомі своїм глибоким розумінням ринків, випустили серйозне попередження: “Заблокувати AI-браузери наразі”. Саме так – заблокувати! І це не просто паніка чи надмірна обережність. Причина в одному простому, але дуже важливому факті: ці AI-браузери можуть отримати доступ до нашої конфіденційної інформації – як особистої, так і корпоративної.
Подумайте: використовуючи такий браузер, ви не просто шукаєте в інтернеті. Він стає вашим “агентом”, який може взаємодіяти з корпоративними системами. І якщо цей агент потрапить не в ті руки або просто необережно “забруднить” свої вхідні дані (про що ми поговоримо далі), наслідки можуть бути дуже неприємними.
І тут, наче з-під землі, з’являється дослідження від Straker’s Star Labs. Вони показали, як за допомогою “нульової атаки” (zero-click attack) можна змусити AI-браузер Perplexity Comet стерти ваш Google Drive. Уявіть: ви просто отримуєте електронний лист з проханням “організуй мій диск”, і… все зникає. Ніякого фішингу, макросів, соціальної інженерії. Просто “отруєний” запит (prompt), який AI-браузер сприйняв як команду.
Ryan Anschutz, лідер відділу реагування на інциденти X Force в Північній Америці, дуже влучно зазначив: “AI-браузери, які мають здатність автоматизувати дії без підзвітності – читати, писати, клікати, видаляти – без явного дозволу в моменті, є проблемою”. Тобто, ми довіряємо машині дії, які можуть призвести до повної втрати даних, і не завжди розуміємо, як саме вона це робить. Це як дати дитині ключі від сейфа, сказавши: “Гратися можна, але нічого не чіпати”.
Цікаво знати: Навіть з усіма заходами безпеки, складність таких систем та непередбачуваність кінцевих користувачів означають, що відмова від AI-браузерів на робочому місці – поки що найбезпечніший варіант.
Розділ 2: “Війна війною, а обід за розкладом”: Чи мають AI-компанії допомагати кібербезпековцям?
Перейдемо до теми, яка викликала бурхливі дискусії. Ми вже побачили, як AI-браузери можуть стати проблемою. А що, якби самі AI-технології, які створюють ці браузери (та інші інструменти), могли б стати частиною вирішення проблеми кібербезпеки?
Нещодавно стався показовий випадок: компанія Anthropic виявила і викрила шпигунську мережу, яка активно використовувала їхній AI-інструмент Claude для автоматизації значної частини своєї діяльності. Це був серйозний прорив, який показав, наскільки потужними можуть бути AI-інструменти в руках зловмисників. Але, як це часто буває, не всі залишилися задоволені.
Деякі експерти з кібербезпеки висловили думку, що Anthropic не надала достатньо цінної інформації, зокрема, індикаторів компрометації (IoCs), які могли б допомогти іншим компаніям захиститися. Rob T. Lee, головний AI-офіцер SANS Institute, влучно підсумував: “AI-провайдери тепер перебувають посередині цих атак, і ще немає чітких очікувань щодо того, як вони виявляють зловживання та повідомляють жертв”.
Austin Zizle, консультант з аналізу загроз, підтримує цю думку: “AI-провайдери перебувають у центрі всіх цих зловживань, але дійсно не мають можливості належним чином виявляти та розголошувати зловживання щодо жертв”. Він вважає, що нам потрібні стандартні рамки: як AI-провайдери мають виявляти шкідливе використання, кого і коли повідомляти, як ділитися інформацією із захисниками.
Ryan Anschutz додає: “AI-провайдери, просто перебуваючи посередині цих атак, набувають нових обов’язків”. Він порівнює це з минулими помилками у сфері безпеки хмарних сервісів, коли ми повільно усвідомлювали, що провайдери хмарних послуг є критично важливими партнерами з розвідки. “Ми не просимо AI-вендорів бути поліцією інтернету, але ми просимо їх не ігнорувати злочинні дії, що відбуваються на їхній платформі”.
З іншого боку, є думка, що навіть якби Anthropic поділилася всіма IoCs, це могло б бути не так вже й корисно, адже більшість захисників не обороняють безпосередньо моделі генеративного AI. Але Evelyn Anderson, CTO та провідний інженер CSS, має інший погляд: “Ми повинні встановити подібну до хмарної сфери матрицю відповідальності”. Вона вважає, що AI-провайдери несуть певну відповідальність, і без справжньої співпраці між усіма сторонами – кібербезпековими фірмами, AI-провайдерами – ми будемо й далі штовхатися “пальцем”, а не вирішувати глибинні проблеми.
Між нами кажучи: Ненадання детальної інформації про інциденти, навіть з острахом “дати ключі від королівства” зловмисникам, ускладнює ситуацію. Щоб щось полагодити, треба розуміти, як воно зламалося.
Розділ 3: “Старі граблі” або чому найнебезпечніші помилки – це ті, які ми досі не виправили
А тепер перейдемо до списку, який викликав у мене не стільки здивування, скільки глибоке розчарування. MITRE нещодавно опублікували 25 найнебезпечніших програмних вразливостей за 2025 рік. І знаєте що? Перша трійка майже не змінилася: міжсайтовий скриптинг (cross-site scripting), SQL-ін’єкції та міжсайтова підробка запитів (cross-site request forgery). Минув рік, а ці “старі добрі” атаки все ще на вершині.
Evelyn Anderson, з її цинічним, але, як виявилося, дуже слушним поглядом, зауважила: “Чи варто взагалі розглядати це як покращення?” Адже саме ці помилки є кореневими причинами більшості атак і витоків даних. А от відсутність авторизації (missing authorization) піднялася на п’ять позицій, ставши четвертою. Це вже тривожний сигнал.
Austin Zizle підкреслив: “Незважаючи на весь ажіотаж навколо атак на ланцюги поставок, AI, нульових днів, більшість виявлених нами зломів повертаються до вразливостей десятирічної давності”. І додає: “З точки зору захисту, це виходить далеко за межі простого встановлення патчів. Принципи безпеки під час проєктування (secure by design) повинні бути впроваджені в життєвий цикл розробки програмного забезпечення”.
Але найглибше, на мою думку, проблему розкрив Ryan Anschutz: “Цей список MITRE – це не про те, що є новим, а про те, що ми досі відмовляємося виправляти”. Він називає це “списком фундаментальних інженерних провалів”. Це не “екзотичні” AI-вразливості, а “нудні” помилки валідації вхідних даних, помилки авторизації, незахищене управління об’єктами. “Це нудні речі, які продовжують призводити до реальних витоків даних”.
Лайфхак від Ryan: Атакувальники люблять цю “нудьгу”, бо вона передбачувана. І поки захисники “ганяються за гіпами” AI, зловмисники експлуатують ті ж самі топ-25 вразливостей з 99% успіхом. Навіть з розвитком AI, цей список не змінюється, але AI лише прискорює експлуатацію.
Ryan також додав: “Причини, чому ми це не виправляємо, – культурні, а не технічні”. Розробники під тиском часу, старі додатки ніколи не переписуються. І так, ін’єкційні атаки (injection attacks) продовжать існувати, бо зловмисникам достатньо однієї помилки у валідації, а вона в багатьох організаціях завжди є.
⁉ Запитання до тебе, друже: Якщо подивитися на цей список як на “ОКР” (цілі та ключові результати) для розробки, як перетворити його з простого переліку проблем на практичні дії для захисників?
- Austin: “Картографуйте цей список на свій технологічний стек, зосередьтеся на автоматизації, виявленні та пріоритизуйте освіту для ваших інженерів і розробників. Ставтеся до цього списку як до інструменту стратегічного управління ризиками на рівні правління компанії”.
- Evelyn: “Я б будувала свої плани проєктів, використовуючи цей список як чек-лист для перевірки безпечних практик кодування, автоматизації сканувань та пентестів перед випуском коду. Це мало б бути стандартною практикою вже зараз”.
- Ryan: “Якщо ми справді хочемо значуще зменшити ризики витоків у 2026 році, ми повинні почати з ліквідації цього топ-25. Все інше – це лише оптимізація”.
Розділ 4: “Зручність чи безпека?”: Чи дійсно безпечно входити через Google чи Facebook?
Ми поговорили про AI-браузери, про співпрацю компаній, про старі помилки. А тепер торкнемося того, що стосується майже кожного з нас – безпека “соціальних логінів”. Ви пам’ятаєте, коли реєструєтеся на новому сайті, і бачите: “Увійти за допомогою Google”, “Увійти через Facebook”? Це ж так зручно, чи не так? Не треба створювати ще один пароль, запам’ятовувати його, а потім ламати голову, де його записати.
Але, як і з AI-браузерами, тут є “але”. SSO (Single Sign-On) створює єдину точку відмови (single point of failure). Якщо хтось отримає доступ до вашого облікового запису Google, він зможе зайти у всі ваші інші облікові записи, прив’язані до нього. Згадайте, минулого тижня ми говорили, як хакери можуть захопити ваш Gmail, змінивши вік. Уявіть, якщо це ваш основний обліковий запис для всього.
З іншого боку, є аргумент: великі платформи, як-от Google чи Facebook, мають більш надійну безпеку, ніж “випадковий” сайт, на який ви реєструєтеся. І це теж правда. Вони впроваджують кращі системи виявлення шахрайства, вищу адаптацію багатофакторної автентифікації (MFA).
Ryan Anschutz каже, що він не використовував би слово “безпечно”, але говорив би про “ризик”. “Для більшості людей логін через Google або Apple є значно безпечнішим, ніж пароль, який повторно використовується на 30 сайтах”. Але він наголошує: “Якщо щось буде скомпрометовано, ця зона вибуху (blast radius) є реальною”. Якщо зловмисник отримає доступ до вашого основного облікового запису, він отримає доступ до всього – банків, додатків, хмарних даних.
Візуальне письмо: Уявіть, що ваші облікові записи – це кімната, а SSO – єдиний замок на дверях. З одного боку, один замок легше закрити. З іншого – якщо хтось зламає цей замок, він отримує доступ до всієї кімнати.
“Атакувальники все частіше націлюються на потоки зв’язку та відновлення облікових записів”, – додає Ryan. “Вони йдуть не через фронтальні двері, а через задні”. Тому SSO є безпечним, якщо він поєднаний з сильним MFA, хорошою гігієною відновлення облікових записів та можливістю бачити, які саме акаунти додані. “Споживчий SSO безпечний, коли ви ставитеся до нього як до контролю безпеки, а не просто як до зручного ярлика”.
Evelyn Anderson чесно зізнається: “Коли я створювала свій аккаунт на Facebook багато років тому, я точно не думала про сильні облікові дані або про те, що станеться, якщо він буде скомпрометований”. Вона закликає провести інвентаризацію своїх облікових записів, подумати про впровадження Passkeys (які, на відміну від паролів, використовують криптографію і прив’язані до пристрою, усуваючи спільні секрети та зменшуючи ризик фішингу), та MFA.
Austin Zizle доповнює: “Зручність часто має вищу ціну, ніж безпека, особливо для споживачів”. Він радить використовувати менеджери паролів, багаторівневий захист, включаючи MFA та Passkeys.
Головний висновок: SSO – це не чорно-біле питання. Це умовно. Важливо не стільки саме SSO, скільки те, що ви його оточуєте: сильні паролі (якщо використовуєте), MFA, Passkeys, тощо.
Розділ 5: “Принеси своє віртуальне”: Як атаки з “чужою” віртуальною машиною перевертають уявлення про безпеку
І нарешті, ми дійшли до останньої, але не менш захопливої теми. Червона канарка (Red Canary), компанія, що спеціалізується на безпеці, розповіла про новий вид атаки – “bring your own virtual machine” (BYOVM) – “принеси свою віртуальну машину”.
Уявіть сценарій: ви отримуєте тисячі листів, що просто засипають вашу поштову скриньку, приховуючи важливі повідомлення. Потім лунає дзвінок: “Це технічна підтримка, ми допоможемо вам з цим хаосом”. У стані стресу, ви погоджуєтеся надати віддалений доступ до свого комп’ютера. І ось тут зловмисник, використовуючи скрипт Visual Basic, запускає у вашій системі власну віртуальну машину.
Що це означає? Віртуальна машина, як “міні-операційна система” всередині вашої справжньої операційної системи, може існувати там непомітно. Вона може пережити перезавантаження, уникнути виявлення традиційними антивірусами та навіть мати власний інструментарій для роботи. І найстрашніше – більшість організацій просто не мають механізмів для моніторингу активності саме таких “гостей”.
Austin Zizle, хоч і не бачив раніше подібних атак, зазначив, що “це інфраструктура всередині вашої інфраструктури, яка може залишатися непоміченою”. Він наголошує, що для таких атак не потрібні складні нульові експлойти, достатньо креативності та терпіння.
Ryan Anschutz називає це “класичним введенням в оману” (misdirection). “Вони створюють шум, щоб ви ніколи не почали шукати артефакт гіпервізора, який тихо запускається у фоновому режимі”. Він пояснює це через “чотири істини шкідливого програмного забезпечення”:
- Має працювати: Зловмисник запускає код не на хості, а всередині VM – це обходить EDR.
- Має ховатися: VM – ідеальне сховище. Ховається ціла операційна система паралельно з хостом.
- Має спілкуватися: Зловмисник використовує власні інструменти, канали керування (C2), стек комунікацій. Трафік виглядає як звичайна активність віртуалізації.
- Має залишатись: Persistence – це не просто запис у реєстрі. Це сама VM, яка може пережити перезавантаження, залишаючи довгостроковий плацдарм.
Страшно уявити: Якщо всі ці чотири умови виконуються всередині вашої системи, але при цьому не торкаються вашої основної ОС, це кардинально змінює підхід до захисту.
Evelyn Anderson додає, що ключовим моментом є видимість. “Ми повинні моніторити будь-які несанкціоновані VM”. Вона визнає, що це був “дуже унікальний випадок, де думали нестандартно”.
Завдання для захисників: Не просто шукати традиційне шкідливе ПЗ, а розширювати спектр моніторингу, включаючи активність віртуалізації, аналіз використання ресурсів (пам’ять, CPU), щоб виявляти “інфраструктуру всередині інфраструктури”.
Підсумовуючи, ми бачимо, що світ технологій рухається вперед, пропонуючи нам нові, захопливі інструменти. Але за кожним новим “зручним” рішенням ховаються потенційні ризики. AI-браузери, обмін даними між компаніями, старі як світ помилки в коді, зручність соціальних логінів та навіть нові методи доставки шкідливого ПЗ – все це вимагає від нас уваги, обережності та глибокого розуміння.
Що далі? Не бійтеся ставити запитання. Не поспішайте приймати нове, як догму. Завжди шукайте глибше. Особливо, коли мова про безпеку – вашу особисту та корпоративну. Використовуйте надані експертами поради, впроваджуйте безпечні практики, навчайте себе та своїх колег. Пам’ятайте, що технології – це інструменти, і тільки від нас залежить, як ми їх використаємо: для розвитку чи для власної шкоди.
Підсумовуючи, можна сказати, що шлях до безпечного цифрового майбутнього – це постійний діалог, навчання та співпраця. Це не спринт, а марафон. Тож давайте крокувати разом, уважно дивлячись під ноги, але з надією, що наше майбутнє буде не тільки технологічно розвиненим, а й надійним.
А тепер, коли ми розібрали всі ці цікавинки, сядьте, видихніть, і давайте спробуємо втілити хоча б одну маленьку пораду з почутого сьогодні у своєму цифровому житті. Наприклад, перевірити, чи у вас увімкнено MFA там, де це можливо. Це дрібниця, яка може мати величезне значення.
Будьте уважні, бережіть себе, і до зустрічі в нових історіях зі світу технологій!
“`
