Привет с RSDN! ;)

Инъекция действительно есть, информация о ней отправлена judge'у, в паблике ее не будет. Искренне желаю, чтобы на этой скуле все и закончилось и, чтобы на хэши пароли перевели как можно быстрее.

Имена баз в БД, в подтверждение существования скули:

distribution
h_sql
h_ss

master
model
msdb
tempdb

Mamut,

Вот тут не вполне соглашусь. С помощью скули можно вытянуть базу да, но это только пол-дела. Судя по шифротексту, который показывал judge, энтропия там приличная, это явно не самопальная штука на ксоре. Имея возможность менять свой пароль и получать его зашифрованное значение из базы, можно попытаться сделать known-plaintext (если пароли шифруются неприсоленными), но например с AES'ом - это дохлый номер. Проще попытаться сбрутить в надежде, что ключ не слишком длинный.

Для компрометации паролей нужна вторая уязвимость на чтение файлов (видимо web.config) с веб-сервера. Скуля тут не поможет, т.к. ей если и получится прочитать файлы (я не пробовал) с помощью чего-то типа:

CREATE TABLE mydata (line varchar(8000));
BULK INSERT mydata FROM ‘c:boot.ini’;

то, как бы web.config тут на другом сервере. Чтобы читать файлы веб-сервера нужен инклуд (LFI), который еще постараться сделать на ASP.NET надо, либо уязвимость лежащая ниже уровня веб-приложения (типа padding oracle, но конкретно ему sql.ru наверняка не подвержен, ибо патч вышел в 2010 году).

Куда проще угнать пароли, подсунув judge'у ту ксску, которая сисерфом сделает тебя админом на форуме и потом посмотреть пароли из админки (если ее функционал это позволяет). Или ждать одей в виндовой инфраструктуре и тупо надломить сервер в нужный момент. Но конкретно эта скуля - мало что дает в плане получения паролей.

С присоленным хэшем оно конечно надежнее (особенно, если значение соли будет недоступно с сервера БД), но скорее уже перестраховка, чем необходимая мера в данном конкретном случае с этой уязвимостью.