Зловмисники можуть віддалено виконувати команди ОС, використовуючи цю вразливість GitLab

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

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

Ще одна уразливість GitLab, яка активно експлуатується в дикій природі

За інформацією HN Security, на відкритому в Інтернеті сервері GitLab CE виявлено два підозрілі облікові записи користувачів з правами адміністратора.

Очевидно, ці два користувачі були зареєстровані з червня по липень 2021 року з випадковими іменами користувачів. Це стало можливим, оскільки ця версія GitLab CE за замовчуванням дозволяє реєструвати користувачів.

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

Щоб ускладнити ситуацію, адміністраторам не надсилається жодних повідомлень.

Одне із завантажених вкладень привернуло увагу експертів, тому вони створили власний сервер GitLab і насправді спробували відтворити те, що вони спостерігали в дикій природі.

Нещодавно випущений експлойт для CVE-2021-22205 зловживає функцією завантаження, щоб віддалено виконувати довільні команди ОС.

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

GitLab складається з кількох елементів, таких як Redis і Nginx. Той, який обробляє завантаження, називається gitlab-workhorse, який, у свою чергу, викликає ExifTool, перш ніж передавати остаточне вкладення в Rails.

Покопавшись глибше в журналах, ми виявили докази двох невдалих завантажень у журналах Workhorse.

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

echo 'user = User.find_by (ім'я користувача: "czxvcxbxcvbnvcxvbxv");user.admin="true";user.save!' | консоль gitlab-rails /usr/bin/echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmUh | base64 -d | /usr/bin/gitlab-rails консоль

Тож, по суті, те, що здавалося уразливістю ескалації привілеїв, насправді виявилося вразливістю RCE.

Як пояснили експерти з безпеки, весь процес експлуатації зводиться лише до двох запитів.

При встановленні GitLab за замовчуванням (до версії 13.10.2) не потрібно зловживати API, щоб знайти дійсний проект, не потрібно відкривати проблему, а головне не потрібно аутентифікувати.

Усі описані в статті вразливості (ExifTool, зловживання API, реєстрація користувача тощо) відсутні в останній версії GitLab CE на момент написання.

Однак ми настійно радимо бути обережними, коли маєте справу з будь-яким, що пов’язано з вашим перебуванням в Інтернеті, щоб у вас не було неприємних наслідків.

Як ви ставитеся до цієї ситуації? Поділіться з нами своєю думкою в розділі коментарів нижче.