- Нападателите просто няма да отстъпят и да намерят нови гениални начини да проникнат в личното ни пространство.
- Експертите по сигурността разкриха друга уязвимост на GitLab, която се експлоатира активно в дивата природа.
- Това беше възможно, защото тази версия на GitLab CE всъщност позволява регистрация на потребител по подразбиране.
- Трети страни могат да злоупотребяват с функционалността за качване и дистанционно да изпълняват произволни команди на ОС.
Изглежда, че без значение до каква дължина компаниите са готови да осигурят своите продукти, нападателите винаги са една крачка напред и намират гениални начини да заобиколят всякаква защита.
В този постоянно променящ се онлайн свят защитата на вашите чувствителни данни става все по-голяма трудно и ние сме тук, за да ви разкажем за друга уязвимост, която активно се експлоатира дивото.
Друга уязвимост на 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 към момента на писане.
Въпреки това силно препоръчваме да внимавате, когато се занимавате с всичко, което включва, че сте онлайн, за да нямате неприятни преживявания.
Какво е вашето отношение към тази ситуация? Споделете вашето мнение с нас в секцията за коментари по-долу.