В Vesta Control Panel (http://vestacp.com), web-панели управления сервером хостинга, распространяемой (https://github.com/serghey-rodin/vesta) под лицензией GPLv3, выявлена (https://blog.tarq.io/vestacp-root-privilege-escalation/) критическая уязвимость, позволяющая поднять свои привилегии в системе. Суть уязвимости в том, что связанные с аутентификацией настройки передаются http-серверу nginx через включение файла директивой "include" в nginx.conf.
Файл с дополнительными настройками сохраняется в каталогах пользователей (/home/{user}/web/{domain}/stats/auth.conf) с правами непривилегированного пользователя хостинга, но при перезапуске nginx обрабатывает настройки с правами root. Пользователь хостинга может подменить содержимое auth.conf и получить доступ к содержимому любых системных файлов, в том числе узнать содержимое /etc/shadow.
Например, пользователь может записать в файл
client_body_temp_path /etc/shadow;
location /vstats/steal {
alias / ;
}Первая стока позволит при перезапуске nginx сменить владельца для /etc/shadow на пользователя nginx. А вторая строка позволит получить содержимое /etc/shadow при открытии в браузере страницы "http://test.com/vstats/steal/etc/shadow".
Также возможно перезаписать содержимое любых системных файлов и получить привилегии root без необходимости подбора пароля по хэшу. Например, указав
client_body_temp_path /etc/profile.d/vim.sh;
location /evil {
error_log /etc/profile.d/vim.sh;
}можно записать данные в файл /etc/profile.d/vim.sh отправить ошибочный запрос к сайту.
URL: https://blog.tarq.io/vestacp-root-privilege-escalation/
Новость: https://www.opennet.ru/opennews/art.shtml?num=47503
Ух ты, как раз искал подобный интерфейс
Веб-макака и эникейщик?
Эникейщик и админ локалхоста. Хотя, если успешно пройду собеседование, то стану инженером технической поддержки!
А в чем проблемы? Запусти nginx под рутом, укажи / ФС как / сервера и включи DirIndex. Интересно же что у тебя в /etc/shadow.
> А в чем проблемы? Запусти nginx под рутом, укажи / ФС как
> / сервера и включи DirIndex. Интересно же что у тебя в
> /etc/shadow.Жги, кульхацкep!
root:$6$OdsJxgN8$2hcptDn0GYgpAHDQzhp0i7qMwNTE5YRX.UHauP2OUHvXs3FAOR1A6WluRx6ukE3a.0AazDsynZUJqQZ9lwMkr0:16480:0:99999:7:::
daemon:*:16480:0:99999:7:::
bin:*:16480:0:99999:7:::
sys:*:16480:0:99999:7:::
sync:*:16480:0:99999:7:::
games:*:16480:0:99999:7:::
man:*:16480:0:99999:7:::
lp:*:16480:0:99999:7:::
mail:*:16480:0:99999:7:::
uucp:*:16480:0:99999:7:::
proxy:*:16480:0:99999:7:::
www-data:*:16480:0:99999:7:::
backup:*:16480:0:99999:7:::
messagebus:*:16480:0:99999:7:::
mysql:!:16491:0:99999:7:::
colord:*:16480:0:99999:7:::
lightdm:*:16480:0:99999:7:::
geoclue:*:16491:0:99999:7:::
dnsmasq:*:16494:0:99999:7:::
pavel:$6$Y9qsycbT$cvDuXake4D9SIp1P7wJ8Qa5fqypxGSqAseHjp2d.ijIYksaPAMprlq1G0Iorv8vo8KiBsqFTtOIKP6hOLr9Ig.:17475:0:99999:7:::
nobody:*:16480:0:99999:7:::
debian-tor:*:16712:0:99999:7:::
ntp:*:16736:0:99999:7:::
sshd:*:16851:0:99999:7:::
uuidd:*:16865:0:99999:7:::
mongodb:*:17101:0:99999:7:::
libvirt-qemu:!:17224::::::
statd:*:17298:0:99999:7:::
uml-net:*:17369:0:99999:7:::
Там какой-то взрыв мозга от их подхода к безопасности, давно я такой беспечности не видел.Бегло глянул на код и сразу ещё одну дыру нашёл.
https://github.com/serghey-rodin/vesta/blob/master/web/login...
exec(VESTA_CMD ."v-check-user-password ".$v_user." ".$v_password." ".escapeshellarg($_SERVER['REMOTE_ADDR']), $output, $return_var);
где
$v_user = escapeshellarg($_POST['user']), но $v_password выставляется без экранирования из $_POST['password'].и так везде через exec-и с прямой подстановкой из $_POST всё делается.
кто не понял, вводите в форме аутентификации вместо пароля ";код" и запускайте на сервере что душе угодно.
Хреновый с тебя безопасник. $v_password - это путь до временного файла, в который уже записан сам пароль, и на этот путь повлиять нельзя, всё нормально тут (ну, кроме названия переменной)
> Хреновый с тебя безопасник. $v_password - это путь до временного файла, вЭто они уже поправили :-)
Было
if (isset($_POST['user']) && isset($_POST['password'])) {
$v_user = escapeshellarg($_POST['user']);
$v_password = escapeshellarg($_POST['password']);
...
https://github.com/serghey-rodin/vesta/commit/1a7612cc66f0e0...
$v_password = exec('mktemp -p /tmp');Мощную ты там уязвимость нашел, мой юный хакир
Нормальный подход к безопасности. За все время существования проекта уязвимостей самой панели было очень мало. Обращения были по взломам через кривые сайты и различные плагины.
Не помню обращений чтобы взломали саму панель или через неё.
> Нормальный подход к безопасности.Так их!
"imperio наносит ответный удар"!
Я всегда говорил, что все эти панели до добра не доведут. Консолька наше всё!
Почитай про уязвимости в ssh, консольщик.
И кто же это минус за ssh поставил? Он наверное им тоже не пользуется для подключения и затем управления сервером.
Веб-макаки, сэр!
Макаки те, кто бездумно повторяет за другими. Ты, например. Занятно, что в мире макак системы управления могут иметь только консольный интерфейс. Видимо проблема сводится всё же не к макакам, а к малолетним идиотам.
>Консолька наше всё!Ну да, такой широкий простор для идотских опечаток, приводящих в серьёзным последствиям, не обеспечит никакая панель. А уж сколько можно запомнить различных ключей к специфическим утилитам... Ах-х-х... Пойду зазубрю парочку манов. Это так возбуждает.
cmdname --help набрать очень сложно, ага
Совсем не сложно. Но зачем?
Не помнишь к чему это консольничество привело в случае с GitLab? К удалению БД в 300 гиг!
ню-ню ... а тач чтобы в конец заё**ый админ в "оснастке управления" да хоть тем же мыссымсыквылем не на ту кнопку ляпнул - такого конечно не бывает? Ясно-понято ...
:)
> ню-ню ... а тач чтобы в конец заё**ый админ в "оснастке управления"
> да хоть тем же мыссымсыквылем не на ту кнопку ляпнул -
> такого конечно не бывает? Ясно-понято ...
> :)Бывает всякое. Но в гую интерфейсе начудить значительно сложнее, лет через 10 поймешь.
Ну так похмелиться надо перед тем, как садиться за консольку, чтобы руки не тряслись.
> Ну так похмелиться надо перед тем, как садиться за консольку, чтобы руки
> не тряслись.Начальник твой одобряет это твое поведение?
> Я всегда говорил, что все эти панели до добра не доведут. Консолька наше всё!и прикованный к ней раб, 24/7 исполняющий команды примерно полутысчонки юзеров shared-hosting (для которых эти панели и предназначены) на предмет чего-нибудь вроде "нарисуй мне alias отсюда туда" или "поменяй дефолтную кодировку". Заодно расплачиваясь своей шкурой, если что сделал не так - по своей ошибке, или вредный юзер развел.
жаль, что в наши дни уже нет gpl-рабов (ну то есть бесплатных и с открытыми исходниками), а коммерческие, как обычно, криворукие, дорого, да еще и сдаются в лиз, а не покупаются пожизненно и с гарантией.
Ты загибаешь палку. Если на то пошло, можно написать утилиты автоматизации для типовых задач.Я и не про детскую песочницу(хостинги) говорю.
> Я и не про детскую песочницу(хостинги) говорю.лично я в недетской песочнице спокойно дам разработчику возможность править конфиги - самая серьезная диверсия, которую он может совершить, это стереть/изгадить собственную разработку, доступ к которой у него по определению есть. (правда, ему придется придумать, зачем оно ему надо, уж не ради конфигурирования авторизации точно) Да и конфиг будет, скорее всего, от веб-сервера, в котором кроме него никто не живет, поскольку это либо виртуалка, либо контейнер, какой дятел в недетской будет мешать разные проекты в один сервер?
"панели" нужны именно для old-style хостингов, когда эти "разработчики" во-первых, из разных недружественных контор, во-вторых, работают не из защищенного периметра офиса, а хз откуда, соответственно, пароли и логины еще и без конца утекают вообще левым кульхацкерам.
Ну и когда настройками вместо разработчика вообще рулит владелец сайта, далекий от всего этого - ему сказали куда нажать, он примерно туда и нажал.
Бесплатный != свободный.
Гугли Shellshock (Bashdoor)
> распространяемой под лицензией GPLv3Куча дыр, кривизна - но лицензия .. лицензия. Всем быстро ставить!
как будто коммерческие панели прямые и без дырок...зато лицензии у них - как надо лицензии.
"да, у вас пожизенная неограниченная лицензия на cpanel. Но нам что-то надоело держать целый один ржавый ящик в дальнем углу датацентра, на котором крутился сервер лицензирования, который она проверяет онлайн - так мы его завтра выключим, кто не спрятался - мы не виноваты. Надо было вовремя апгрейдиться на новую херовую версию нашего чудесного багнутого продукта - и нам плевать, что он у вас в миллионе мест вручную подпилен и подперт кривыми подпорочками, чтобы хоть как-то держать нагрузку, и интегрирован в биллинг и кучу внутренних систем, да и пользователи при апгрейде на совершенно другой look&feel разбегутся пачками, а старый в новую версию просто так не воткнешь"у других решений (для _крупных_ заметь, заказчиков) - все еще хуже.
и ты с этим ничего сделать не можешь - только жалобно упрашивать "ну может хоть не завтра, а послезавтра?"
Оно ещё и на php.
Блин, это наверное самая смешная уязвимость за этот год.
Мне казалось, что понимание того, что нельзя делать include клиентского конфига в основной, должно приходить в голову любого, кто хочет сделать аналог .htacces в nginx. Может не сразу, а через целых две минуты, ну максимум пять. И даже если найдется альтернативно одаренный админ, то после озвучивания этой "гениальной" мысли коллегам, они наставят его на путь истинный. Кто же знал, что альтернативно одаренные просто кучкуются и пишут панели управления хостингом.
Так-то можно, только клиентский конфиг должен генерироваться из возможных тщательно продуманных вариантов по белому списку, а не из пользовательского ввода.
И, конечно, не лежать в пользовательском каталоге с uid пользователя :-)
Скажу по секрету, даже если он будет принадлежать root, пользователь может его легко изменить. Если конечно не использовался sticky bit, но о нем почему-то мало кто из админов знает/помнит.
Разработчики решили замолчать это событие.Примечательно что в оригинальной новости написано, что автор связывался с ними в марте по этому вопросу и в итоге тишина.
Никто с нами не связывался по этому поводу. Про уязвимость сообщили совсем недавно. Передано разработчикам.
Проблема касается только связки nginx + php-fpm
Смотрите чтобы chown для auth.conf был root:root
> Проблема касается только связки nginx + php-fpm
> Смотрите чтобы chown для auth.conf был root:rootchown root:root нужен не только на файл auth.conf и даже не только на директорию stats, но и для всех директорий в цепочке, иначе, если одна из директорий принадлежит пользователю, он может её переименовать/удалить и создать новую со своим содержимым.
Лучше пока изменить chown для папки stats