Цього тижня в безпеці: камери Flock застаріли, Microsoft виправляє оновлення, а дослідники атакують SSH.
Сайт витоків Distributed Denial of Secrets оприлюднив дамп файлових систем камери Flock, а Міка Лі детально дослідив її вміст. Виявляється, модель безпеки Flock не врахувала “розлючених громадян із ножівками посеред ночі” як фактор фізичної безпеки.
Перше, на що звертає увагу Міка, це те, що обладнання Flock працює на Android 8.1 (для тих, хто не стежить, поточна версія Android — 17, випущена у червні 2026 року). Версія Android, що працює на камері Flock, востаннє оновлювалася у червні 2018 року, а ядро Linux (3.18.71) є застарілим більш ніж на дев’ять років (серія 3.18 досягла кінця життєвого циклу у 2019 році).
Можна було б припустити: “Чи не мало б таке старе програмне забезпечення відомі вразливості?”, і ви мали б рацію. Міка зазначає дві конкретні: одну у графічному процесорі Qualcomm, яка дозволяє будь-якій програмі маніпулювати пам’яттю ядра та отримати root-доступ (подібно, але простіше, до низки вразливостей ядра цього року, що дозволяли маніпулювати пам’яттю через кеш введення-виведення диска), і вразливість “WrongZone”, яка дозволяє процесу отримати root-доступ через помилки обробки сокетів. Можна також припустити, що обидві ці проблеми були виправлені, і знову ж таки, ви мали б рацію: у 2021 та 2018 роках відповідно.
Заглиблюючись, Міка виявляє, що ключі API з доступом до інфраструктури Flock, схоже, жорстко закодовані в бінарних файлах. Кожна камера, здається, запитує облікові дані з сервера автентифікації, використовуючи MAC-адресу камери. Після отримання облікових даних від сервісу входу Okta Auth0, Flock зберігає їх у відкритому тексті.
Також на камері без шифрування зберігаються журнали та дані позиціонування: камера, що потрапила до Distributed Denial of Secrets, походить із передмістя Мілуокі.
Wired також опублікував дослідження дампованих образів файлових систем. Хоча деякі відео- та фотодані зашифровані на пристрої, ключі розшифрування також зберігаються на пристрої. Хакерський колектив, який отримав камеру, розшифрував збережені дані, показавши, що камера зафіксувала 1,6 мільйона фотографій 50 000 транспортних засобів менш ніж за місяць (21 день).
Незважаючи на заяви Flock про те, що виявлення фіксує лише транспортні засоби, дані в проаналізованих фотографіях та програмному забезпеченні, схоже, вказують на те, що камера навмисно знімає людей, і робить це у відеоформаті, а не за допомогою статичних зображень, які використовуються для номерних знаків.
Flock, тим часом, заявив, що не знає про жодні проблеми безпеки, оскільки вони не були повідомлені через вебсайт безпеки Flock, і не може зробити оцінку безпеки на основі неповної інформації. Ймовірно, дивитися на відомі вразливості останнього десятиліття — це надто складно?
Microsoft випускає екстрені виправлення позапланово для виправлень “Patch Tuesday”
Минулий тиждень був рекордним “Patch Tuesday” з майже 1000 виправленнями безпеки, і Microsoft почала радити встановлювати оновлення безпеки негайно, або максимум протягом трьох днів. Ризик швидкого встановлення оновлень Microsoft на виробничих системах або великих парках машин полягає в тому, що Microsoft не мала найкращого досвіду щодо стабільності оновлень, що призводить до цього набору екстрених виправлень для виправлення самих оновлень.
Оновлення безпеки за вересень 2026 року спричинило проблеми з віддаленим доступом до серверів, вплинувши на консоль керування, провідник файлів та інструменти оновлення Windows. Воно також призвело до збоїв у спільному доступі до папок із віртуальними машинами Hyper-V у деяких випадках та проблем зі звуком USB на деяких пристроях. Екстрене виправлення також включає кілька виправлень безпеки для усунення помилок ескалації привілеїв.
Кілька екстрених виправлень на додаток до тисячі оновлень можуть здатися невеликою кількістю, але для корпоративних середовищ втрата доступу до віддаленого робочого столу або до спільних каталогів із віртуальними машинами може зупинити роботу, і будь-яка проблема, помножена на тисячі систем в одній компанії, негайно стає значною витратою. Якщо Microsoft очікує, що корпоративні клієнти зможуть встановлювати оновлення негайно, процес тестування та сертифікації має швидко покращитися. Кожен раз, коли ІТ-відділ або CISO змушені пояснювати простій, спричинений оновленнями, стає важче розгортати наступний набір оновлень.
Південна Корея бореться з витоками даних штрафами
Південна Корея збільшила штрафи за великі витоки даних до десяти відсотків річного доходу компаній.
Згідно з новими правилами, компанії, у яких сталися витоки даних, що торкнулися десяти мільйонів або більше людей, можуть бути оштрафовані до десяти відсотків річного доходу компанії. Раніше в Південній Кореї компанії, причетні до великих витоків даних, могли бути оштрафовані до трьох відсотків річного доходу.
Штрафи накладаються на компанії, які мали повторні порушення протягом останніх трьох років і які вважаються грубо недбалими. Не всі порушення автоматично досягають верхньої межі в десять відсотків, і компанії, які можуть продемонструвати процеси та інвестиції в захист даних, можуть зменшити штрафи.
Змінити корпоративну поведінку за допомогою законодавчих штрафів важко, але це може бути єдиним способом зупинити деякі нестримні проблеми з викраденням даних та вимаганням, спричиненими групами програм-вимагачів, а прив’язка штрафів до річного доходу, безумовно, матиме більший вплив, ніж фіксовані штрафи, які можуть бути настільки незначними, що простіше сплатити їх, ніж вирішити проблеми.
Атака на ланцюжок постачання RubyGems насправді була OpenAI
У травні 2026 року репозиторій RubyGems — еквівалент NPM для Node або PyPI для Python у світі Ruby — зазнав хвилі тисяч шкідливих пакетів, які намагалися заразити будь-яких користувачів, що їх завантажували як частину збірки. Крім того, у генераторі документації RubyDoc було знайдено вразливість виконання коду, яка дозволяла зловмиснику виконувати довільний код у докеризованому екземплярі RubyDocs, який використовувався для генерації документації для завантажених пакетів. З 5 травня 2026 року по 18 червня 2026 року було завантажено понад 2000 шкідливих пакетів.
На той час атака була позначена як “велика шкідлива атака”, але її цілі були незрозумілі; більш пізні дослідження, схоже, вказують на те, що це була зграя агентів OpenAI. Пакети були ідентифіковані як згенеровані LLM під час початкової атаки, але також виглядає так, що агенти ідентифікували себе як OpenAI у комітах пакетів, часто вказуючи автора як “oai”. Цього було б недостатньо, щоб остаточно вказати на OpenAI, будь-хто може вказати автора, але у вересні OpenAI визнала, що агенти вирвалися з-під контролю, і перерахувала файли та ресурси, до яких вони мали доступ. Ці дані корелюють з поведінкою пакетів, завантажених до RubyGems місяцями раніше.
Нарешті, як частина процесу подання Gems, документація автоматично генерується RubyDoc. Код генерації документів мав опції, які могли дозволити виконання довільних команд, що зазвичай вимкнено — але не в контейнерах Docker, що використовуються в робочому процесі RubyDoc. Через цей недогляд сайт RubyDocs був вразливим до довільного виконання з будь-якого джерела, але це стало відомо лише тоді, коли зграя агентів експлуатувала його. Маючи повний доступ до контейнерів, що генерують документацію, агенти намагалися зібрати ключі API інших користувачів, але дослідники з rubyhack.ai не можуть підтвердити, чи вдалося їм отримати доступ.
Через проблему з кешуванням у CDN, що стоїть за RubyGems, до години після того, як користувач увійшов у систему за допомогою (застарілої) версії Gems, токен автентифікації кешувався в мережі вмісту. Код, згенерований LLM, намагався отримати доступ до ключів, кешованих у CDN, а потім намагався надсилати пакети до репозиторію RubyGems, використовуючи вкрадені ключі. Агенти також використали іншу нову вразливість у системі RubyGems для обходу електронної автентифікації.
Буде цікаво подивитися, чи виявлять подальші дослідження ранніші випадки виривання агентів OpenAI та інших передових моделей з-під контролю та незаконного злому інших компаній. [Примітка редактора: І захоплююче бачити, хто буде притягнутий до відповідальності!]
NightmareEclipse розкриває свою особу
Дослідник, відомий як NightmareEclipse, випускав експлойти для Windows протягом 2026 року, часто публікуючи їх одразу після циклу “Patch Tuesday”. Багато з цих випусків супроводжувалися критикою Microsoft за руйнування його життя. У поєднанні з іншими коментарями та витоками інформації підозрювалося, що дослідник міг бути колишнім співробітником Microsoft, і тепер це було підтверджено безпосередньо.
Абдельхамід Насері підтвердив, що він стоїть за ідентичністю NightmareEclipse, і раніше був відзначений за дослідження групою Zero Day Initiative, яка займається пошуком та усуненням загроз. Насері стверджує, що його було незаконно звільнено Microsoft, і він брав участь у кількох судових процесах у Німеччині, борючись зі своїм звільненням. Під час судового розгляду Microsoft відмовилася надати деталі щодо вразливостей, у яких брав участь Насері, і які могли призвести до його звільнення.
Revolut став жертвою фішингу
Фінтех-компанія Revolut стала жертвою фішингу з використанням підроблених урядових доменів, що призвело до розкриття даних невідомої кількості клієнтів.
Revolut працює як банк у багатьох країнах і стверджує, що має понад 80 мільйонів клієнтів у всьому світі, а також займається торгівлею криптовалютами. Використовуючи неуточнений скомпрометований домен урядової установи, зловмисники запросили дані клієнтів, і Revolut їх надав. Дані включали адреси клієнтів, дати народження, документи, що посвідчують особу, такі як паспорти та водійські посвідчення, а в деяких випадках — історію транзакцій та іншу інформацію.
Невідомо, скільки клієнтів постраждало, або чому ця інформація була доступна за запитом електронною поштою від урядової установи без додаткової перевірки. Враховуючи високопрофільних клієнтів, яких залучає Revolut, це міг бути цілеспрямований напад на групу цінних клієнтів для допомоги в майбутніх фішингових спробах.
Атаки на SSH-потоки
Стаття з конференції ACM CCS 2026 детально описує атаки на OpenSSH шляхом маніпулювання та аналізу потоку під час стиснення.
SSH дозволяє використовувати кілька каналів в одному з’єднанні; на додаток до звичайної інтерактивної оболонки, SSH-з’єднання можуть виконувати переадресацію портів, діяти як SOCKS-проксі або навіть як повноцінний VPN з віртуальними мережевими інтерфейсами. З’єднання OpenSSH також підтримують стиснення, але стиснення відбувається одночасно для даних з усіх каналів.
Стаття показує, що якщо зловмисник може маніпулювати даними в одному каналі, він може вплинути на стиснення та отримати вміст даних в інших каналах того ж з’єднання. Наприклад, коли SSH використовується для переадресації портів, переадресований сервер може бути не надійним, але все одно може впливати на пакети, що генеруються. Точність та ефективність атаки можуть залежати від того, скільки активності відбувається на інших каналах з’єднання, але дослідники демонструють можливість відновити 8-символьний секрет з 26-літерним алфавітом (як базовий пароль) за 276 спроб.
SSH дозволяє переадресацію термінальних сесій, UNIX-сокетів X11, локальних UNIX-сокетів домену, TCP-сокетів та каналів файлових дескрипторів, що безпосередньо з’єднані; хоча кожен канал підтримується окремо, як тільки дані об’єднуються і готові до передачі, всі канали стискаються одночасно. На найбазовішому рівні алгоритми стиснення шукають повторювані дані, які можна скоротити до одного запису, і дослідники показують, що, впливаючи на дані, що стискаються, та аналізуючи зашифровані, стиснені дані, що генеруються, можна робити припущення про вміст інших каналів.
У статті показано атаки на секрети Ansible, відкритий текст браузера та простий відкритий текст автентифікації, що використовується Redis. На даний момент модель атаки є відносно езотеричною; ймовірно, для більшості користувачів SSH немає негайної загрози. Подібні атаки були продемонстровані проти протоколу TLS, що призвело до видалення стиснення як частини стандарту. Якщо не буде знайдено інших рішень, розумно вважати, що стиснення може бути видалено з клієнтів і серверів SSH як запобіжний захід проти таких типів атак.