Очередной безбашенной ночью задумал распотрошить некий сайтик ( назовём его zalupa.com ). В процессе выяснилось, что сайт самописный и так просто сдаваться не хочет. Однако в движке Zalupa.ru всё же нашелся уязвимый параметр, позволяющий проводить sql инъекции. Благодаря ей было выявлено, что: Версия БД mysql 4.2-log (?ld=-1+union+select+1,2,version(),4/*) Скрипт работал с БД от имени пользователя chelsi Права пользователя в БД выставлены грамотно и не позволяли просматривать другие базы. Была возможность читать файлы, и включены magic_quotes Стоял никсовый сервер, это видно из версии mysql. По стандартным путям файл конфигурации web сервера найти не удалось. Попытка определения полного пути до сайта, так же не увенчалась успехом. Но гениальные мысли бывают. Немного подумав, пришла в голову шальная мысль – «А что если прочитать файл таблицы mysql.user физически?». База mysql хранилась по дефолтовому пути в /var/lib/mysql/, в чем можно было убедиться, прочитав passwd. Получился запрос: union+select+1,2, LOAD_FILE(0x2F7661722F6C69622F6D7973716C2F6D7973716C2F757365722E6D7964),4/* Таким макаром был прочтен файл с данными таблицы mysql.user (/var/lib/mysql/mysql/user.myd) и вытащен хеш пароля пользователей БД и пароль root-а, (который как ни странно, был легко сбручен). Удаленно подключится к БД не давала огненная стена, зато был найден phpmyadmin, с помощью него стало возможно более подробно взглянуть на базу. В ней нужного не оказалось. Для получения мирового господства оставалось не много, получить доступ…SSH… Т.к. у нас нет полного пути до веб директории - пришлось идти другим путем. В конфигах sshd демона /etc/ssh/sshd_config нашлись строки, разрешающие аутентификацию по ключам: RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys Далее взглянув еще раз в файлик /etc/passwd увидел в нем строчку: mysql :*:777:777:Mysqld server:/usr/local/mysql/:/bin/bash что давало надежду получить возможность выполнения команд c привелегиями в системе пользователся mysql. Сгенерировав с помощью putty пару ключей ( публичный и приватный ) и выполнив нехитрый запрос в phpmyadmin: select “ssh-rsa AAAAB3NzaC1...бла.бла.бла...kEi/eF9btr7yc= rsa-key-200807023” into outfile ‘/usr/local/mysql/.ssh/authorized_keys’. Увидел, что phpMyAdmin, как послушная гимназистка, выполнил без ошибки этот запрос. Заюзав putty с ключами, я без проблем подключился к серверу, в ответ получил приглашение bash оболочки. Вот и «солнце» вышло. P.S. Требует наличия прописанного шелла юзверу mysql, что бывает очень редко. Параметры sshd не всегда позволяют подключения по ключам. Ну и остальные мелочи )) By f1rebl00d//
Мало материала для статьи, но момент про ключи путти интересный. Ничего особенного, если проявить фантазию, если есть доступ на запись, а интересен момент тем, что наши супер хекеры Ачата обычного такого не пишут, только лишь обсасываются старые темы с инжекшенами, никакого творчества. Вообще не факт что те кто пишут про пхп-инжекшен, знают что такое путти и как ею пользоваться Короче, за содержательность 3, за подход 5. Перенесено в Уязвимости
оригинальная конечно идея ключи создать ) но чето сомнения как ты каталог '.sshd' сделал? и почему именно .sshd раскажи по подробнее то
Сенкс, чуть ошибся в пути (в ригинале подправил, лишняя буква `D`) ‘/usr/local/mysql/.sshD/authorized_keys’. mysql не создает папки, но гдето в среднем количестве nix систем у юзвера каталог .ssh существует по умолчанию, мож админы так создают юзверей =)
очень странно, не разу не видел чтоб такое делали, это замечал конечно под апача если делают к примеру в скриптах чтоб был конект для чеголибо по ssh то и папку создают, а вот mysql шоб мистика наверно?
встречал системы, где прописан шел и у юзвера есть папка .ssh Мож под ним логинились, хотя онаб не содавалась, хм.... Для тестов пару сервов находил, в которых норм заливался файл authorized_keys в ето папку На домашнем серве всегда приходилось создавать ее.
ну наконец-то хотя бы один человек в своей хек-стори вспомнил про возможность чтения файла таблицы. и большой max_allowed_packet для лоад_файла (хотя в данном случае загружался файл таблицы user, здесь и дефолтного значения хватило).
кстати обсуждали уже зачем юзеру mysql шел тут https://bugzilla.redhat.com/show_bug.cgi?id=176389 там один тоже предположил аналогичный метод взлома, но сочли что проблема надуманная в итоге. в общем юзаем selinux, чтоб меньше проблем было.
тут вот что еще непонятное оказалось http://dev.mysql.com/doc/refman/5.0/en/select.html это с 3 версии mysql уже так. потом ssh: http://www.openssh.com/cgi-bin/cvsweb/src/usr.bin/ssh/auth.c?rev=1.28 это с 2001 года минимум тоесть mysql создает с маской 0666 файл а ssh ну по моим тестам не позволяет иметь права на запись ни group ни other. и в результате: /var/log/secure
ShAnKaR прав, ми тож ща проверил, не канает =( хотя были такие случаи получения доступа. уже точн не помню, что за ось была и версии ядра и демонов.
Статья хорошая.. и способ неплох. Вот только странный серв какой-то - mysql не имеет доступа к mysql.user, а load_file() разрешен - извратство какое-то....
