реліз системи керування web-контентом . Випуск примітний завершенням з реалізації перевірки оновлень та доповнень по цифровому підпису.
Досі при встановленні оновлень у WordPress основним фактором забезпечення безпеки була довіра до інфраструктури та серверів WordPress (після завантаження здійснювалася звіряння хешу без верифікації джерела). У разі компрометації серверів проекту атакуючі мали змогу підмінити оновлення та поширити шкідливий код серед сайтів на базі WordPress, які використовують систему автоматичного встановлення оновлень. Відповідно до раніше довірчої моделі доставки, на стороні користувачів подібна заміна залишилася б непоміченою.
З урахуванням того, що за проект w3techs платформа WordPress використовується на 33.8% сайтів в мережі, інцидент прийняв би масштаб катастрофи. При цьому небезпека компрометації інфраструктури була не гіпотетичною, а цілком реальною. Наприклад, кілька років тому один із дослідників безпеки вразливість, яка дозволяла атакуючому виконати свій код за сервера api.wordpress.org.
У разі застосування цифрових підписів отримання контролю над сервером поширення оновлень не призведе до компрометації користувачів систем, так як для проведення атаки додатково знадобиться отримати закритий ключ, що зберігається окремо, за допомогою якого здійснюється підпис оновлень.
Впровадженню перевірки джерела оновлень цифрового підпису заважало те, що підтримка необхідних криптографічних алгоритмів з'явилася в штатному постачанні PHP відносно недавно. Потрібні криптографічні алгоритми з'явилися завдяки інтеграції бібліотеки до основного складу . Але як версія PHP, що мінімально підтримується в WordPress випуск 5.2.4 (починаючи з WordPress 5.2 - 5.6.20). Увімкнення підтримки цифрових підписів призвело б до суттєвого підвищення вимог до мінімально підтримуваної версії PHP або додавання зовнішньої залежності, на що не могли піти розробники з урахуванням поширеності версій PHP у системах хостингу.
Виходом стала і включення до складу WordPress 5.2 компактного варіанта Libsodium , в якому PHP реалізовано мінімальний набір алгоритмів для перевірки цифрових підписів. Реалізація залишає бажати кращого щодо продуктивності, але повністю вирішує проблему із сумісністю, а також дозволяє розробникам плагінів розпочати впровадження сучасних криптографічних алгоритмів.
Для формування цифрових підписів задіяно алгоритм , Розроблений за участю Деніеля Бернштейна (Daniel J. Bernstein). Цифровий підпис формується для значення хеш SHA384, обчисленого від вмісту архіву з оновленням. Ed25519 має більш високий рівень безпеки, ніж ECDSA і DSA, і демонструє дуже високу швидкість верифікації та створення підписів. Стійкість до злому для Ed25519 становить близько 2^128 (в середньому для атаки на Ed25519 потрібно здійснити 2^140 бітових операцій), що відповідає стійкості таких алгоритмів, як NIST P-256 і RSA з розміром ключа в 3000 біт або 128-біт шифрування. Ed25519 також не схильний до проблем з колізіями в хешах, не чутливий до атак через аналіз осідання даних в кеші (cache-timing) та атак по сторонніх каналах.
У випуску WordPress 5.2 перевірка цифрового підпису поки що охоплює лише основні оновлення платформи і не призводить за замовчуванням до блокування оновлення, а лише інформує користувача про проблему. Блокування за замовчуванням вирішено не включати відразу через необхідність повної перевірки та обходу . У майбутньому перевірку щодо цифрового підпису також планується додати для версифікації джерела встановлення тем оформлення та плагінів (виробники зможуть підписувати релізи своїм ключем).
Крім підтримки цифрових підписів у WordPress 5.2 можна відзначити такі зміни:
- У розділ «Site Health» додані дві нові сторінки для налагодження типових проблем з налаштуванням, а також надана форма, через яку розробники можуть залишати налагоджувальну інформацію адміністраторам сайту;
- Додано реалізацію «білого екрану смерті», що виводиться у разі фатальних проблем і допомагає адміністратору самостійно виправити проблеми, пов'язані з плагінами або темами, перейшовши в спеціальний режим відновлення після збою;
- Реалізовано систему перевірки сумісності з плагінами, що автоматично перевіряє можливість використання плагіна в поточній конфігурації з урахуванням застосовуваної версії PHP. Якщо для роботи плагіна потрібна новіша версія PHP, система автоматично заблокує включення даного плагіна;
- Додано підтримку включення модулів з JavaScript-кодом з використанням и ;
- Додано новий шаблон privacy-policy.php, що дозволяє налаштувати вміст сторінки з умовами дотримання конфіденційності;
- Для оформлення доданий обробник wp_body_open hook, що дозволяє вставити код відразу після тега body;
- Вимоги до мінімальної версії PHP піднято до 5.6.20, у плагінах та темах оформлення з'явилася можливість використання просторів імен та анонімних функцій;
- Додано 13 нових піктограм.
Додатково можна згадати критичної вразливості у WordPress-плагіні (CVE-2019-11185). Вразливість дозволяє виконувати довільний PHP-код на сервері. Плагін використовується на більш ніж 27 тисячах сайтів для організації інтерактивного чату з відвідувачем, у тому числі на сайтах таких компаній, як IKEA, Adobe, Huawei, PayPal, Tele2 та McDonald's (Live Chat часто використовується для реалізації настирливих чатів на сайтах компаній з пропозицією поспілкуватися із співробітником).
Проблема проявляється в коді завантаження файлів на сервер і дозволяє обійти перевірку допустимих типів файлів і завантажити сервер PHP-скрипт, після чого виконати його прямим зверненням через web. Цікаво, що минулого року в Live Chat вже була виявлена схожа вразливість (CVE-2018-12426), що дозволяла завантажити PHP-код під виглядом зображення, вказавши інший тип контенту в полі Content-type. У рамках виправлення проблеми були додані додаткові перевірки за білими списками та MIME-типом вмісту. Як виявилося, ці перевірки реалізовані некоректно і їх легко можна обійти.
Зокрема, пряме завантаження файлів з розширенням .php заборонено, але в чорний список не було додано розширення .phtml, на багатьох серверах пов'язане з інтерпретатором PHP. Білий список допускає лише завантаження зображень, але обійти його можна за допомогою подвійного розширення, наприклад, «.gif.phtml». Для обходу перевірки MIME-типу на початку файлу, до відкриття тега з кодом PHP, достатньо було вказати рядок GIF89a.
Джерело: opennet.ru