NASA.GOV на коленях Леонид «R0id» Стройков Хакер, номер #096, стр. 096-072-3 Прорыв по флангу Самый удобный способ чтения файлов при возможности просмотра содержимого директорий – это инклуд. На удаленный инклуд рассчитывать не приходилось, а вот локальный я решил поискать. Еще просматривая насовские поддомены, на некоторых сайтах я заметил наличие перл-скриптов. При удачном раскладе, грамотном подходе и определенной степени криворукости веб-программистов из NASA шансы на успешный исход резко возрастали. Поэтому я вновь обратился к своему любимому поисковику (Гуглу) и вбил следующий запрос: «inurl:nasa.gov filetype:dat». Я надеялся, что найдется хотя бы один скрипт, инклудящий файл с расширением dat. Гугл вернул мне результат, и я начал вглядываться в линки. Первым на глаза попалась ссылка вида: http://ats.gsfc.nasa.gov/ats3/jumpspace/printjumpspace.asp?iscompare=true&autoprint=true&prnFile=Edit_Spacecraft.dat Но, во-первых, скрипт был написан на ASP, а во-вторых, он жестко фильтровал все входящие данные. Просмотрев еще с десяток урл, я уже собирался перевести идею в разряд безнадежных, когда заметил такой линк: www.espo.nasa.gov/ave-polar/schedule_viewer.cgi?pic=02_07_daily_schedule.dat Дрожащими от волнения руками я заменил значение параметра pic: http://www.espo.nasa.gov/ave-polar/schedule_viewer.cgi?pic=../../../../../../../../etc/passwd После обновления страницы я увидел не пустой экран и не редирект на страницу ошибок, а содержимое файла passwd. В течение минуты я пребывал в состоянии шока. Затем быстро осмотрел сайт www.espo.nasa.gov и обнаружил, что он находится на одном сервере с http://cloud1.arc.nasa.gov, который тоже содержит бажный скрипт: http://cloud1.arc.nasa.gov/intex-b/schedule_viewerDC8.cgi?pic=../../../../../../../../proc/version Таким образом, я получил информацию об ОС, стоящей на сервере: Linux version 2.6.16.21-0.13-default (geeko@buildhost)(gcc version 4.1.0(SUSE Linux))# 1 Mon Jul 17 17:22:44 UTC 2006 Я тут же залез в админку, которую нашел еще до обнаружения инклуда, и выбрал оттуда путь к одному из файлов. Но при попытке прочитать содержимое этого файла бажный скрипт выдал чистый лист. Оказалось, что админка и уязвимый перл-скрипт находятся на разных серверах :(. То есть я опять лишался возможности чтения файлов на сервере, хостящем основной домен www.nasa.gov. Такого облома я никак не ожидал. Расстроенный, я выключил ноутбук и лег спать. Облом или удача Проснулся я от звона будильника. Глянув на часы, тут же сел за стол, придвинув ноут, - пора было продолжать взлом. Раз уж мне удалось устроить чтение директорий на одном сервере, а файлов - на другом, то, следовательно, стоило прощупать обе машины. Но, зайдя по ссылке http://cloud1.arc.nasa.gov/intex-b/schedule_viewerDC8.cgi?pic=../../../../../../../../etc/hosts, я вдруг обнаружил, что баг был закрыт! Аналогичный результат выдал запрос http://www.espo.nasa.gov/ave-polar/schedule_viewer.cgi?pic=../../../../../../../../etc/hosts. Админ пропатчил скрипт. Уязвимости больше не существовало. Минуты две я думал о смысле жизни, после чего, собравшись с мыслями, загрузил админку. На мое удивление она по-прежнему работала. Так как все пути мне отрезали, я решил детально изучить содержимое директорий при помощи админки на сервере, хостящем www.nasa.gov. Сначала я просмотрел каталог /home. В нем находились две директории: etouch и rlancaster. Первая ссылалась на /u01/home/etouch, а для просмотра второй не хватало прав. Как выяснилось позже, в /u01/webData лежали все сайты, находящиеся на сервере (полный листинг смотри на DVD). Там были и www.nasa.gov, и два десятка других ресурсов. Я спокойно мог просматривать содержимое почти всех каталогов, включая www.nasa.gov. Но этого было мало. Мне хотелось слить документы, лежащие за пределами веб-директорий. Но пока такой возможности я не имел. Спустя время, я заметил, что в каталоге, где располагается админка, присутствует набор различных перл-скриптов. Большая часть из них не работала, но один привлек мое внимание. Это был скрипт cpputFiles.cgi. При обращении к нему требовалось ввести какое-то слово, по-видимому, выполняющее функцию пароля. Все данные передавались post-методом. Попробовав пару стандартных пассов, я ничего не добился. А при подстановке символа одинарной кавычки, скрипт возвращал чистый лист. Это обстоятельство заинтересовало меня, и я заполнил форму таким образом: |