OpenJS Foundations ділиться порадами з безпеки проєктів з відкритим вихідним кодом

Нещодавня спроба використання бекдору у пакеті XZ Utils може бути не поодиноким випадком кібератаки, про що свідчить схожа спроба fnfrb, перехоплена Фондом OpenJS (є домом для проєктів на JavaScript).

У чому справа

OpenJS Foundation отримала підозрілу серію електронних листів зі схожими повідомленнями, від різних авторів. Вони використовували електронні адреси, що асоціюються з GitHub.

Автори листів просили оновити один з популярних JavaScript-проєктів, але не вказували жодної конкретики. Вони хотіли, аби їх призначили новими супровідниками проєкту, незважаючи на те, що стосунку до нього вони не мали. Такий підхід дуже нагадує те, як «Jia Tan» позиціонували себе у бекдорі XZ/liblzma.

Подібні підозрілі схеми були виявлені в двох інших популярних JavaScript-проєктах, які не розміщуються на хостингу Фонду.

Тож команда OpenJS разом з OpenSSF вирішили нагадати про підозрілі патерни та кроки, що допоможуть захистити проєкт.

Підозрілі патерни в атаках на соціальну інженерію

• Переслідування мейнтейнера або його організації невідомими членами спільноти.
• Прохання про підвищення статусу мейнтейнера від нових осіб і схвалення від інших невідомих членів спільноти.
• PR, що містять блоби як артефакти. (Наприклад, бекдор XZ — це майстерно створений файл у складі тестового набору, який не доступний для читання людині).
• Навмисно заплутаний або складний для розуміння вихідний код.
• Поступова ескалація проблем з безпекою. (Наприклад, проблема XZ почалася з відносно нешкідливої заміни safe_fprintf() на fprintf() — вона була зроблена для того, аби перевірити, чи її хтось помітить).
• Відхилення від типових практик компіляції, збірки та розгортання проєктів, які можуть дозволити вставити зовнішнє шкідливе навантаження в блоби, архіви або інші бінарні артефакти.
• Хибне відчуття терміновості.

Кроки, які допоможуть захистити ваш проєкт з відкритим кодом

• Подумайте про дотримання стандартних галузевих практик безпеки, таких як OpenSSF Guides.
• Увімкніть двофакторну автентифікацію (2FA) або багатофакторну автентифікацію (MFA).
• Використовуйте безпечний менеджер паролів. Зберігайте коди відновлення в безпечному місці, бажано в автономному режимі.
• Не використовуйте повторно облікові дані/паролі в різних сервісах.
• Майте політику безпеки, що містить процес «узгодженого розкриття» для звітів.
• Використовуйте найкращі практики для злиття нового коду.
• Увімкніть захист гілок та підписані коміти.
• Якщо можливо, попросіть другого розробника провести перевірку коду перед злиттям.
• Впроваджуйте вимоги до читабельності, щоб гарантувати, що нові PR не є незрозумілими, а використання непрозорих двійкових файлів зведено до мінімуму.
• Обмежте права на публікацію npm.
• Якщо ви використовуєте репозиторій пакунків з відкритим кодом, подумайте про прийняття Principles for Package Repository Security.
• Перегляньте Avoiding social engineering and phishing attacks від CISA та/або What is ‘Social Engineering’ від ENISA.