Українське техношоу УТ-2 у свіжому випуску обговорює хвилю нових кібератак — від дивного шкідливого коду в науковому софті до небезпечної вразливості в ядрі Linux і болючого питання: чому Docker створює ілюзію безпеки, а не саму безпеку. На тлі історій про старі Windows, сучасні експлойти й практики захисту інфраструктури вимальовується тривожна картина: атаки стають дедалі більш таргетованими й витонченими, а наші звичні захисні рефлекси часто виявляються застарілими.
FAS16 і «невидимий» саботаж: коли malware не краде, а псує науку
Історія зі старим науковим софтом FAS16 виглядає як сценарій до технотрилера. Це не банальний троян, який шифрує файли й вимагає викуп, і не банальний кейлогер. Йдеться про шкідливе ПЗ, яке роками могло спотворювати результати наукових і технічних розрахунків — тих, що лягають в основу реальних фізичних об’єктів.
FAS16 — це старий пакет інструментів для математичних і фізичних симуляцій: обчислення масивів, моделювання процесів, розрахунки для інженерних задач. Програму використовували для симуляцій, на основі яких могли проєктуватися деталі, конструкції, вузли. І саме тут з’являється найнеприємніше: виявлено malware, який не просто жив поруч із цим софтом, а цілеспрямовано втручався в обчислення.
Шкідливий код підміняв одну з бібліотек Windows, через яку проходили розрахунки. Замість того, щоб змінювати сам FAS16 або масово заражати систему, malware працював точково: перехоплював виклики до бібліотеки, змінював логіку обчислень і повертав уже спотворені результати. Зовні все виглядало коректно: програма запускалася, дані оброблялися, файли зберігалися. Але всередині формули давали «трохи не ті» значення.
Це не випадковий баг і не халатність розробників. Це саме цілеспрямований науковий саботаж. Важливо, що шкідливе ПЗ не було частиною FAS16 як такого — воно активувалося лише за наявності конкретного ПЗ і конкретного середовища. Тобто хтось витратив чималі зусилля, щоб створити вузькоспеціалізований інструмент, який:
- не намагається заразити якомога більше машин;
- не цікавиться банківськими даними чи паролями;
- не демонструє себе користувачу.
Його єдина мета — зробити так, щоб розрахунки в певних сценаріях були неправильними.
Це радикально відрізняється від класичної картини кіберзлочинності, де мотив — гроші, дані або контроль над системою. Тут мотив — зіпсувати результат. Якщо такі симуляції використовувалися, наприклад, у проєктуванні складних фізичних систем, помилки могли проявлятися вже на етапі виробництва чи експлуатації: деталі виходять менш надійними, конструкції — менш стійкими, а причину роками шукають у «людському факторі» або «невдалому дизайні».
Ще один тривожний момент — час. FAS16 — софт «багатьох десятиліть тому», а вразливість помітили значно пізніше, коли старі системи вже давно вийшли з мейнстриму. Це означає, що подібні атаки можуть роками залишатися непоміченими, особливо якщо вони націлені на нішеві інструменти в науці, промисловості чи оборонці.
Вузькоспеціалізований malware: нова норма замість масових вірусів
Malware для FAS16 показує важливий тренд: атаки стають дедалі більш вузькоспеціалізованими. Це не «черв’як», який розповзається по всьому інтернету, а інструмент, який чекає дуже конкретних умов.
У цьому випадку шкідливий код:
- активується лише тоді, коли в системі присутній FAS16;
- не чіпає інші програми;
- працює через підміну однієї Windows-бібліотеки, а не через модифікацію десятків файлів.
Така стратегія має кілька переваг для атакувальника. По-перше, її важче виявити: антивіруси й системні адміністратори шукають аномалії у поведінці системи, підозрілі процеси, нетиповий мережевий трафік. Тут же все виглядає як звичайна робота старого наукового софту. По-друге, вузька спрямованість зменшує «шум» — випадкові зараження, які могли б привернути увагу.
Це вже не просто хакерство, а інструмент саботажу, який ближчий до кібертероризму або операцій спецслужб. Коли мета — не заробити, а зробити погано конкретному сектору, країні чи проєкту, подібні «тихі» атаки стають особливо привабливими. І саме тому їх так складно виявляти й розслідувати: немає очевидного фінансового сліду, немає вимог викупу, немає публічних заяв.
На цьому тлі стає зрозуміло, чому експерти говорять про «нову хвилю» кібератак, яку порівнюють із 1990-ми, коли одна за одною з’являлися вразливості типу buffer overflow. Тоді головною проблемою була технічна неграмотність у поводженні з пам’яттю. Сьогодні — складність і глибина стеку технологій, на якій будуються критичні системи, і поява інструментів (включно з AI), що полегшують пошук і експлуатацію таких нішевих дірок.
Дірка в ядрі Linux: 768 байт коду проти всієї моделі безпеки
Якщо історія з FAS16 — це про таргетований саботаж у науковому світі, то вразливість у ядрі Linux — про фундаментальну загрозу для величезної кількості сучасних серверів і контейнерних середовищ.
Йдеться про баг, пов’язаний із криптографічним модулем ядра та системним викликом splice. Комбінація цих механізмів дозволяла робити те, що в нормальній моделі безпеки вважається неможливим: підміняти вміст page cache — кешу сторінок пам’яті, де ядро тримає дані файлів, — не змінюючи самі файли на диску.
З точки зору користувача і файлової системи файл залишається незмінним. Але коли процес читає його, він отримує вже модифікований вміст із кешу. Для виконуваних файлів це означає, що можна змінити їхню поведінку «на льоту», не залишаючи слідів у вигляді змінених бінарників.
Експлойт, який демонструє цю вразливість, можна реалізувати у вигляді скрипта приблизно на 768 байт. Цього достатньо, щоб:
- знайти в page cache потрібний виконуваний файл, наприклад
su; - змінити в ньому кілька байтів — наприклад, у місці перевірки пароля чи прав доступу;
- отримати ескалацію привілеїв до root.
Ключова небезпека тут у тому, що класичні засоби контролю цілісності файлів (хеші, перевірка підписів, моніторинг змін на диску) не бачать нічого підозрілого. Файл на диску не змінюється. Змінюється лише його відображення в пам’яті, і це відбувається на рівні ядра.
Втім, є важливе обмеження: вразливість стосується лише систем, де завантажений оптимізаційний криптографічний модуль ядра. Без нього ланцюжок умов, необхідних для експлуатації, не складається. Це дає два практичні шляхи пом’якшення ризику:
- відключити відповідний криптомодуль, якщо він не критичний для навантаження;
- оновити ядро до версії, де баг уже виправлено.
Але сам факт існування такої дірки показує, наскільки крихкою може бути модель безпеки, коли вразливість з’являється не в прикладному коді, а в самому ядрі. І наскільки небезпечною стає ситуація, коли на одному ядрі крутиться безліч контейнерів, які адміністратори звикли вважати «ізольованими».
Docker як ілюзія безпеки: коли контейнер — це не стіна, а шторка
Контейнери за останнє десятиліття стали де-факто стандартом для розгортання сервісів. Docker, Kubernetes та інші інструменти створили відчуття, що кожен сервіс живе у своєму «маленькому світі», ізольованому від інших. Але технічно ця ізоляція базується на одному й тому ж ядрі Linux, яке спільне для всіх контейнерів на хості.
Вразливість із підміною page cache демонструє це особливо наочно. Якщо в ядрі є така дірка, то:
- код усередині контейнера може скористатися нею;
- експлойт працює на рівні ядра, а не user space;
- у результаті з контейнера можна отримати root-доступ до всієї хост-системи.
Тобто Docker не є повноцінним механізмом безпеки. Це зручний інструмент для ізоляції процесів, розгортання й масштабування, але не бар’єр, який можна вважати достатнім захистом від атак. Якщо адміністратор виходить із припущення «контейнер = sandbox», він уже програє.
На практиці це означає кілька речей.
По-перше, вразливості ядра — це не абстрактна проблема «десь там у Linux». Це безпосередній ризик для будь-якої контейнерної інфраструктури. Навіть якщо всі образи «чисті», а доступ до них обмежений, достатньо однієї вразливості в ядрі, щоб зламати всю машину.
По-друге, модель довіри до контейнерів має бути переглянута. Якщо в інфраструктурі є можливість запуску довільного коду в контейнері (наприклад, multi-tenant середовище, CI/CD для зовнішніх репозиторіїв, платформи на кшталт PaaS), то кожен такий контейнер потенційно може стати плацдармом для атаки на хост.
По-третє, безпека ядра й конфігурація модулів стають не менш важливими, ніж оновлення бібліотек у самих контейнерах. Вразливість із криптомодулем і splice — показовий приклад: її можна частково нейтралізувати, просто відключивши конкретний модуль, але для цього хтось має знати, що він взагалі завантажений і навіщо.
Docker і подібні технології часто сприймаються як «заміна» більш важких механізмів безпеки — окремих віртуальних машин, жорстких мережевих сегментацій, обмеженого доступу до продакшн-серверів. Але насправді вони мають доповнювати ці механізми, а не підміняти їх.
Jumpbox як мінімум здорового глузду: як захищають продакшн сьогодні
На тлі історій про таргетований саботаж і дірки в ядрі особливо актуальним стає питання: що реально роблять команди, щоб захистити продакшн-інфраструктуру?
Одна з практик, яка давно прижилася в серйозних компаніях, — використання jumpbox-серверів. Ідея проста: замість того, щоб відкривати SSH-доступ безпосередньо на всі продакшн-сервери, зовнішній доступ дозволяється лише на один або кілька спеціальних вузлів — jumpbox’и. Уже з них адміністратори підключаються до внутрішніх машин.
Це не панацея, але дає кілька важливих переваг.
По-перше, різко зменшується площа атаки. Замість десятків чи сотень серверів, які потенційно можуть бути доступні ззовні, є один вузол, який можна особливо ретельно захищати, моніторити й аудіювати.
По-друге, спрощується контроль доступу. На jumpbox можна накласти жорсткі політики: обов’язковий MFA, обмеження за IP, детальний логінг усіх сесій, інтеграцію з корпоративними системами ідентифікації. Внутрішні сервери при цьому можуть бути взагалі недоступні з інтернету.
По-третє, це дисциплінує процеси. Коли доступ до продакшну проходить через один вузол, легше впроваджувати правила: хто, коли і навіщо туди заходить, які саме дії дозволені, як відбувається ескалація прав у разі інциденту.
У світі, де з контейнера можна вийти в ядро, а з ядра — у весь хост, подібні базові практики стають не просто «enterprise-ритуалом», а необхідним мінімумом. Особливо якщо врахувати, що сучасні атаки часто комбінують кілька векторів: спочатку компрометація облікового запису, потім — використання вразливості в ядрі, далі — горизонтальний рух по інфраструктурі.
Jumpbox не врятує від усіх проблем, але він ускладнює життя атакувальнику й дає команді безпеки більше точок контролю та спостереження.
Висновок: безпека більше не про «патчі раз на квартал»
Історії про malware у FAS16, вразливість page cache у Linux і ілюзію безпеки Docker показують одну спільну рису сучасної кіберреальності: атаки стають глибшими, тихішими й більш таргетованими, а наші звичні уявлення про безпеку часто не встигають за ними.
Науковий саботаж через підміну Windows-бібліотеки в нішевому софті демонструє, що навіть інструменти для симуляцій можуть стати полем бою. Дірка в ядрі Linux, яку можна експлуатувати скриптом на 768 байт, нагадує, що фундаментальні компоненти системи — не менш вразливі, ніж веб-фреймворки. А Docker, який багато хто сприймає як «коробку з піском», насправді лише тонка шторка поверх спільного ядра.
У такій реальності безпека перестає бути набором чекбоксів на кшталт «оновили бібліотеки», «поставили антивірус», «запустили контейнери». Вона стає постійним процесом переосмислення: які саме припущення ми робимо про свою інфраструктуру, де насправді проходять межі довіри, що станеться, якщо один із шарів — ядро, криптомодуль, бібліотека — виявиться скомпрометованим.
І, можливо, головне — усвідомлення, що сьогоднішні атаки не обов’язково прагнуть бути помітними. Вони можуть роками тихо псувати розрахунки, непомітно змінювати байти в кеші й користуватися тим, що ми надто довго вважали деякі речі «достатньо безпечними за замовчуванням».
Джерело
Гейб радує Лінуса, GitHub губить ваш код, і чому RAG більше не потрібен. Все горить. mvc #27