Аналіз безпеки: небезпеки використання зовнішніх скриптів у вашій системі

Коли ви щодня працюєте з кодом, дуже легко зосередитися лише на тому, щоб він «працював», і забути щось ключове: Що відбувається, коли ваш застосунок починає взаємодіяти з кодом, який ви не контролюєте?Сторонні скрипти, зовнішні бібліотеки, реклама, віджети аналітики, інтеграції постачальників… все це зручно для розробника, але також відкриває шлях до деяких найнебезпечніших та найважчих для виявлення атак.

Щойно ви дозволяєте зовнішньому скрипту виконуватися у вашому браузері або на вашій системі, ви покладаєте величезну довіру на код, який ви не писали. І зловмисники це знають. Шкідливі скрипти та атаки без файлів стали одними з найпопулярніших векторів викрасти дані, завантажити шкідливе програмне забезпечення в пам'ять або проникнути у вашу інфраструктуру з мінімальними слідами на диску чи «підозрілими» вкладеннями. Глибоке розуміння цих ризиків є важливим, якщо ви хочете, щоб ваші програми та системи були чимось більшим, ніж просто легкою мішенню.

Що саме таке зовнішній скрипт (і чому він такий чутливий)?

По суті, сценарій – це фрагмент коду, інтерпретований іншою програмою: браузер, інтерпретатор PowerShell, рушій VBScript, інтерпретатор Python тощо. На відміну від скомпільованого виконуваного файлу, скрипт зазвичай є звичайним текстом (хоча часто заплутаний свідомо) та виконується на льоту з інтерпретатора, який вже присутній у системі.

Коли ми говоримо про зовнішні скрипти в контексті безпеки, ми маємо на увазі переважно два сценарії: код, що походить з Інтернету (JavaScript, скрипти, вбудовані в PDF-файли, макроси Office, HTA тощо) та скриптовий код, який виконується в самій системі (PowerShell, bash, VBScript, Python тощо), керовані користувачем, іншою програмою або через експлойт.

Краса (і проблема) цих сценаріїв полягає в тому, що Вони покладаються на цілком легальні інструментиВаш браузер має запускати JavaScript; Windows містить PowerShell та WMI; багато компаній автоматизують адміністрування за допомогою скриптів. Зловмиснику просто потрібно проникнути в цей робочий процес і повторно використати ті ж можливості, які використовуєте ви, але для набагато менш благородних цілей.

Пов'язана стаття:

FileFort Backup, створюйте резервні копії всіх документів, фотографій та музичних папок на FTP-сервері

Зламані легітимні сайти: найпідступніша сторона проблеми

Одним із найнебезпечніших векторів атаки сьогодні є використання шкідливі скрипти, вбудовані в цілком законні вебсайти чия безпека була порушена. Користувач заходить на сторінку свого улюбленого ЗМІ, банку чи новинного веб-сайту і, не з його вини, його браузер отримує та виконує код, введений третьою стороною.

Цей код зазвичай йде завуальований та добре замаскований серед легітимних бібліотек, реклами чи сторонніх віджетів. У багатьох випадках це частина набори експлойтів (Neutrino, Angler свого часу та інші сучасніші), здатні автоматично виявляти вразливості в браузері, плагінах (Flash, Java, PDF) або навіть в операційній системі та допоміжних програмах.

Коли відбувається правильне поєднання порушення безпеки та дозволів, скрипт завантажує та виконує корисне навантаженняПрограми-вимагачі, трояни, боти, майнери криптовалюти або будь-яке інше шкідливе програмне забезпечення, яке зацікавить зловмисника. Все це може статися без натискання користувачем чогось особливо незвичайногоокрім простого завантаження сторінки з банером або скомпрометованим скриптом.

Шкідлива реклама: реклама як троянський кінь

Кампанії маловія Вони є досить яскравим прикладом зловживання зовнішніми скриптами. Зловмиснику не потрібно безпосередньо зламувати великий вебсайт: достатньо впроваджувати шкідливу рекламу в рекламну мережу який використовує цей веб-сайт. Ці оголошення містять скрипти, які перенаправляють на сторінки з експлойт-кітами або виконують код безпосередньо у браузері.

Були випадки у провідних міжнародних місцях, де Вставлена ​​реклама виконувала експлойти, такі як Angler або Neutrino.У деяких випадках простого кліку на банер було достатньо для того, щоб зловмисник отримав контроль над пристроєм, особливо якщо користувач переглядав веб-сторінки за допомогою старіших версій плагінів або самого браузера.

Проблема тут полягає в транзитивній довірі: головний сайт делегує сторонні скрипти та контент (рекламні мережі, постачальники аналітики, соціальні віджети), які завантажуються в тому ж контексті безпеки, що й решта сторінки. Якщо одне з цих посилань ламається, зловмисник може впровадити все, що забажає, з тими ж привілеями, що й легітимний код.

Клієнтські скрипти: потужність та поверхня атаки

Клієнтське програмування — JavaScript, TypeScript, HTML5, CSS та інші веб-мови — є двигуном сучасного Інтернету. Завдяки йому ми маємо динамічні форми, SPA-простори, інтерактивні карти, панелі інструментів у режимі реального часу тощо. Але вся ця потужність має один нюанс: цей код працює в браузері кожного користувача, повністю видимий і змінюваний.

Це означає, що будь-який клієнтський скрипт пряма мішень для нападникаВи можете його перевіряти, здійснювати зворотне проектування, маніпулювати ним під час виконання, перехоплювати виклики API або навіть впроваджувати власний код, використовуючи вразливості XSS, CSRF або погані реалізації CORS та CSP.

Типові проблеми, пов'язані з незахищеними клієнтськими скриптами, включають: Міжсайтовий сценарій (XSS)Підробка міжсайтових запитів (CSRF), розкриття токенів та конфіденційних даних на фронтенді, ін'єкції коду через DOM та пряме маніпулювання станом програми з консолі браузера.

XSS: Коли ваш власний фронтенд обертається проти вас

Міжсайтовий скриптинг продовжує очолювати список веб-вразливостей. Концепція проста: Зловмисник отримує можливість від програми доставити контрольований ним скрипт іншим користувачам.Цей скрипт працює у браузері жертв з тими ж правами доступу, що й код легітимного вебсайту.

Типовими векторами є поля коментарів, профілі користувачів, параметри в URL-адресах або будь-які дані, які програма відображає без очищення та без належного кодуванняЯкщо цей вивід вставляється в HTML як такий, або, що ще гірше, в атрибути, такі як onclick або за innerHTML «Зловмисник може непомітно вставити мітку». <script> або більш складне корисне навантаження.

Маючи XSS у руках, зловмисник може красти файли cookie та токени сесії, імітувати дії від імені користувача, розгортати фішингові форми, що імітують ваш інтерфейс, змінювати те, що бачить користувач, або навіть ланцюгово перенаправляти атаки на серверну частину, якщо постраждалий користувач є адміністратором.

Скрипти в Office, PDF-файлах та інших документах

Зовнішні скрипти не просто надходять через браузери. Зловмисники використовують це вже багато років. макроси та механізми сценаріїв у документах Office, PDF-файлах та інших, здавалося б, нешкідливих форматахЕлектронний лист із вкладенням, яке «потрібно відкрити», залишається дуже вигідною можливістю.

У випадку з Office класичний метод – це документ із завуальованим макросом VBA та ризиками, також пов’язаними з Офісні скриптиМакрос запускається, коли користувач вмикає активний вміст і зазвичай викликає Скрипти PowerShell, WScript, HTA або інші системні компоненти щоб завантажити та запустити шкідливе корисне навантаження в пам'ять. Багато сімейств програм-вимагачів проникли в систему таким чином.

З іншого боку, PDF-файли можуть містити Вбудований JavaScript які виконують певні програми для читання. Якщо програма для читання або плагін браузера має вразливості, цей скрипт може використати їх для виконання коду. Знову ж таки, файл .exe не потрібен; все робиться за допомогою скриптів та експлойтів у вже встановлених компонентах.

PowerShell, bash та компанія: скрипти в системі без дотику до диска

У системному середовищі такі мови програмування, як PowerShell, VBScript, bash, Python або Perl, є надзвичайно потужними інструментами адміністрування. Саме тому, Розширені групи загроз та безфайлове шкідливе програмне забезпечення їх люблятьЗамість того, щоб скидати виконуваний файл, вони просто вводять або завантажують скрипт, який повністю виконується в пам'яті.

PowerShell — це хрестоматійний приклад. Він використовується щодня для автоматизації ІТ-задач, а також для завантажувати шкідливі DLL-файли в пам'ять, витягувати облікові дані, переміщатися по мережі або зв'язуватися із зашифрованим C2Все це досягається за допомогою лише стандартних, часто обфускованих функцій, і без залишення на диску жодного явного шкідливого програмного забезпечення, яке може підписати традиційний антивірус.

Те саме стосується скриптів bash або Python у середовищах Linux та AppleScript на macOS. Проста команда, скопійована з форуму, або скрипт, завантажений з ненадійного репозиторію, може працювати у вашій системі. набагато більше, ніж здається, від відкриття задніх дверей до зміни критично важливих налаштувань.

Безфайлові атаки та обхід класичного антивірусного програмного забезпечення

Ключовою перевагою для зловмисника є те, що скрипти дозволяють йому запускати атаки. практично без запису чогось на дискЕксплойт потрапляє через Інтернет, електронну пошту або RDP, виконує команду PowerShell або JavaScript, яка завантажує додатковий код безпосередньо в пам'ять, вставляє його в легітимний процес, і все. Після перезапуску більшість слідів зникають.

Згідно з дослідженнями останніх років, До 40% спостережуваних атак зараз є "безфайловими" або переважно заснованими на скриптах.Шкідливе корисне навантаження знаходиться в пам'яті, використовує процеси, підписані Microsoft або іншими постачальниками, та покладається на легітимні інструменти, такі як mshta.exe, wscript.exe, powershell.exe, rundll32.exe тощо.

У цьому сценарії продукти, які майже виключно залежать від підписи файлів на диску Вони грають у невигідному становищі; варто переглянути такі порівняння, як Порівняння безпеки Захисника Windows зрозуміти обмеження та альтернативи. Виявлення залежить від евристичних методів та поведінкового аналізу: підозрілі рядки команд, виклики інтерпретаторів із завуальованими параметрами, дивні мережеві з'єднання, використання конфіденційних API тощо.

Надмірні дозволи та погана конфігурація: найкращий друг шкідливого скрипта

Один аспект, який часто недооцінюють, – це вплив облікові записи з надмірними привілеямиУ багатьох середовищах Windows більшість користувачів все ще працюють як локальні адміністратори або з контролем облікових записів користувачів (UAC) на смішно низьких рівнях. Якщо шкідливий скрипт запускається з цими обліковими даними, він має повну свободу дій для встановлення драйверів, служб, зміни реєстру або вимикання елементів керування безпекою.

Щось таке просте, як Налаштування UAC на середньому/високому рівні та робота з обліковими записами без прав адміністратора Для щоденних завдань це значно зменшить вплив багатьох скриптів. Навіть якщо скрипт запуститься, його здатність завдавати шкоди значно обмежена, якщо він не може легко підвищити привілеї.

Те саме стосується серверів, контейнерів та хмарних середовищ: запуск таких сервісів, як rootНадання дозволів на запис там, де вони недоречні, або спільне використання ключів і токенів між середовищами відкриває величезне поле для... будь-який скомпрометований скрипт може змінювати напрямок далеко за межами його початкового обсягу.

Основні небезпеки використання зовнішніх скриптів у вашій системі

Все вищезазначене призводить до низки цілком конкретних ризиків, коли ваш застосунок або інфраструктура залежить від зовнішніх скриптів:

• Виконання довільного коду (RCE): За допомогою XSS, макросів, скриптів PowerShell, HTA або експлойтів у програмах для читання та браузерах зловмисник може виконувати команди з привілеями користувача або навіть системи.
• Крадіжка даних та облікових даних: Скрипти у браузері можуть зчитувати файли cookie, localStorage та відповіді API; системні скрипти можуть збирати паролі, токени, ключі API, конфіденційні файли та передавати їх на віддалений сервер. Щоб перевірити наявність витоків облікового запису, доцільно Перевірте, чи не було витоку інформації з ваших облікових записів після підозри.
• Викрадення сеансу та ідентифікації: Добре встановлений XSS або скомпрометований сторонній скрипт може викрасти токени сесії, JWT та файли cookie. незахищений або навіть перехоплювати облікові дані у підроблених формах.
• Бічний рух та наполегливість: Після потрапляння в мережу, адміністративні скрипти (PowerShell, WMI, bash) дозволяють досліджувати мережу, поширювати її на інші машини, встановлювати бекдори та підтримувати постійний доступ. Перегляньте посібники для управління постійними загрозами допомагає пом'якшити ці сценарії.
• Майнінг криптовалюти та зловживання ресурсами: Шкідливі скрипти на веб-сайтах або впроваджені розширення можуть використовувати процесор і графічний процесор ваших користувачів або ваших серверів для майнінгу без вашої згоди, знижуючи продуктивність і скорочуючи термін служби обладнання.
• Пошкодження веб-сайту та маніпулювання контентом: XSS, скомпрометовані плагіни або змінені зовнішні скрипти можуть змінити те, що бачить користувач, вставляти рекламу, фішинг або шахрайський контент на ваш власний сайт.
• Ухилення від контролю та складний судово-медичний аналіз: Оскільки атаки на основі скриптів виконуються в пам'яті та використовують легітимні інструменти, вони залишають менше чітких слідів на диску та в журналах, що ускладнює їх виявлення та аналіз у майбутньому.

Найкращі практики безпечної роботи із зовнішніми скриптами

Йдеться не про демонізацію всіх зовнішніх сценаріїв, бо реальність така, що Більшість сучасних програм покладаються на нихМета полягає в мінімізації неявної довіри та впровадженні розумного контролю в усіх критичних точках.

Пов'язана стаття:

Як забезпечити безпеку Windows 11: поради та професійні налаштування

1. Посилити фронтенд та контролювати виконання

На стороні клієнта метою є мінімізація шкоди, яку може завдати шкідливий скрипт, чи то ваш власний, чи від третьої сторони:

• Перевіряє та дезінфікує вхідні дані на клієнті та сервері. Фільтри на стороні клієнта покращують взаємодію з користувачем, але справжня безпека знаходиться на сервері. Незважаючи на це, фільтрація, де це можливо, допомагає зменшити ризики багатьох тривіальних XSS та векторів ін'єкцій.
• Використовуйте екранування та завжди кодуйте вивід. Будь-які дані користувача, які ви відображаєте в HTML, повинні бути належним чином екрановані. Уникайте створення HTML через innerHTML з необробленими струнами.
• Уникайте онлайн-скриптів. Не розміщуйте JavaScript безпосередньо в атрибутах або блоках HTML <script> Вбудовуйте файли, якщо можливо. Використовуйте зовнішні файли та скористайтеся перевагами суворішої політики безпеки контенту.
• Впровадити гідний CSP. Визначити політику безпеки контенту, яка обмежує, звідки можна завантажувати скрипти, забороняє eval і блок inline-script крім випадків суворої необхідності.
• Використовуйте безпечні файли cookie з HttpOnly та SameSite. Для сеансів позначте файли cookie як Secure, HttpOnly y SameSite=Lax o Strict щоб захистити їх від XSS та CSRF.
• Застосуйте заголовки безпеки. HSTS, X-Content-Type-Options, X-Frame-Options та подібні інструменти допомагають закрити прості двері, які експлуатують багато атак на основі скриптів.

2. Покращує керування скриптами на стороні клієнта

Окрім логіки програми, необхідно контролювати залежності інтерфейсу:

• Мінімізуйте кількість сторонніх скриптів. Кожен додатковий віджет, CDN або SDK – це нова поверхня для атаки. Завантажуйте їх, лише якщо вони дійсно необхідні.
• Встановіть версії та використовуйте цілісність підресурсів (SRI). Під час завантаження скриптів з CDN використовуйте атрибути integrity y crossorigin щоб переконатися, що вміст не було змінено.
• Підтримуйте бібліотеки та фреймворки в актуальному стані. Багато XSS та подібних вразливостей виправлено в новіших версіях React, Angular, Vue, jQuery тощо. Використання старіших версій залишає відомі вразливості відкритими.
• Регулярно перевіряйте свої розширення та плагіни. Як у корпоративних браузерах, так і на серверах (плагіни CMS) він видаляє все, що не є важливим, і відстежує сповіщення безпеки.

3. Забезпечити використання скриптів у системі (PowerShell, bash…)

У сфері операційної системи ключовим є застосовувати принцип найменших привілеїв та контролювати поведінку:

• Це обмежує, хто що може виконувати. Сегментуйте користувачів відповідно до їхніх потреб: ті, кому скрипти потрібні щодня, ті, кому лише зрідка, і ті, кому ніколи. Блокуйте непотрібні інтерпретатори в профілях, які їх не потребують.
• Обмежує PowerShell та інші інтерпретатори. Використовуйте політику виконання, AppLocker або еквівалентні альтернативи, щоб дозволити лише підписані скрипти або скрипти, розташовані в контрольованих шляхах.
• Вимкнути макроси за замовчуванням. Їх слід увімкнути лише для тих користувачів і документів, які цього потребують, і бажано підписати цифровим підписом.
• Не працюйте з обліковими записами адміністраторів, якщо в цьому немає крайньої необхідності. Виконуйте щоденні завдання зі стандартними обліковими записами та резервуйте привілейовані облікові дані для певних, контрольованих завдань.
• Відстежує підозрілі команди. Послідовності PowerShell з рядками Base64, завантаження з незвичайних доменів, виконання mshta, wscript o rundll32 Аномальні явища є явними ознаками того, що щось не так.

4. Захист конфіденційних даних на клієнті та сервері

Оскільки скрипти – це засіб, дані – приз. Зробіть це складним:

• Уникайте розкриття токенів та ключів на фронтенді. Не ховайте секрети в JavaScript, глобальних змінних або статичному коді. Все на стороні клієнта видно.
• Правильно шифруйте та використовуйте надійні ключі. Для даних під час передачі використовуйте добре налаштований TLS; для даних у стані спокою використовуйте поточні алгоритми та режими (AES-GCM, Argon2/bcrypt для паролів тощо).
• Правильно використовуйте автентифікацію на основі токенів. JWT та подібні протоколи повинні бути підписані безпечними ключами, мати розумні терміни дії та не використовувати незахищені алгоритми. Завжди використовуйте HTTPS.
• Покладайтеся на криптографію білого ящика або обфускацію лише як додатковий рівень. Обфускація скриптів ускладнює зворотне проектування, але вона не замінює безпечного дизайну.

5. Інструменти підтримки: не намагайтеся побачити все «на око»

З огляду на обсяг коду та скриптів, які обробляє будь-яка сучасна система, спроба переглянути все вручну нереалістична. Розумний підхід полягає в тому, інтегрувати інструменти безпеки в цикл розробки та експлуатації:

• Статичні аналізатори (SAST) та захисний пух. ESLint з плагінами безпеки, Semgrep тощо може виявляти небезпечні шаблони, такі як використання eval, небезпечне об'єднання HTML або команд оболонки.
• Сканери вразливостей та SCA. Вони аналізують ваші залежності (як фронтенд, так і бекенд) на наявність бібліотек з відомими CVE та рекомендують безпечні версії.
• WAF та моніторинг дорожнього руху. Гарний брандмауер веб-застосунків може блокувати типові спроби XSS та ін'єкцій на льоту, а також дати вам змогу бачити незвичайні закономірності; його варто доповнити… користувацькі правила у брандмауері.
• Інструменти для гартування та рашпіль. Самозахист під час виконання, обфускація, моніторинг втручання та цілісності додають рівні захисту до клієнтських програм із високим рівнем захисту.
• Зручні для розробників платформи безпеки. Сучасні рішення інтегрують SAST, SCA, секретне сканування та конфігурацію CI/CD, пропонуючи раннє виявлення та часто автоматичне виправлення вразливостей, пов'язаних зі скриптами та залежностями.

Організаційні зміни: безпека скриптів не лише для «айтішників»

Незалежно від того, наскільки відшліфований ваш код, якщо організація продовжує відкривати вкладення без роздумів або запускати кожен скрипт, який надходить електронною поштою, ви завжди будете гасити пожежі. Це важливо. навчати користувачів та команди Щодо конкретних ризиків скриптів:

• Періодичне навчання. Що люди знають, як розпізнавати підозрілі електронні листи, неочікувані макроси, дивні спливаючі вікна та «чарівні» скрипти форуму.
• Чіткі правила використання. Що можна встановити, звідки завантажувати скрипти, як керуються макроси, хто може використовувати інтерактивний PowerShell тощо.
• Сегментація мережі та пристроїв. Якщо скрипту вдається скомпрометувати комп'ютер, цей комп'ютер не повинен мати прямого підключення до всієї внутрішньої мережі.
• Цілодобовий моніторинг та реагування. Чим швидше ви виявите шкідливий скрипт під час його виконання, тим менше часу у нього буде на переміщення, шифрування або вилучення даних.

Коротше кажучи, зовнішні скрипти є потужним і абсолютно необхідним інструментом у сучасній розробці, але вони також є привілейованою точкою входу для зловмисників, особливо в поєднанні зі скомпрометованими легітимними веб-сайтами, шкідливою рекламою та погано налаштованими середовищами.

Пов'язана стаття:

OSX Mavericks не дозволяє встановити певну програму на вашому Mac, дізнайтеся, як це зробити

Зменшення дозволів, контроль завантаженого коду, моніторинг поведінки та підтримка всього цього за допомогою інструментів безпеки та процесів, інтегрованих у цикл розробки. Це визначає різницю між інфраструктурою, яка «працює», та тією, яка може продовжувати функціонувати, навіть коли хтось намагається її зламати. Поділіться інформацією, і інші користувачі дізнаються про цю тему