Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #96, ДЕКАБРЬ 2006 г.

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-методом. Попробовав пару стандартных пассов, я ничего не добился. А при подстановке символа одинарной кавычки, скрипт возвращал чистый лист. Это обстоятельство заинтересовало меня, и я заполнил форму таким образом:

Назад на стр. 096-072-2  Содержание  Вперед на стр. 096-072-4