Hack-Faq

NsT (nst.void.ru), Forb

Хакер, номер #091, стр. 091-066-2

Q: Слил тут дамп одной MySQL'ной базы. Там есть таблица с именем users, а в ней - поле passwords. Открыв у себя полученное добро, я ринулся смотреть на данные, которые должны быть в поле passwords, но вместо ожидаемых хэшей я увидел там бинарный мусор. Как мне восстановить первозданные пароли в чистом тексте?

A: А то, что там бинарные данные, ты, наверно, определил из типа поля passwords (BLOB)? Если так, то только на первый взгляд может показаться, что это мусор. В случае, когда у тебя под рукой имеются исходники скрипта, можно поискать там слово ENCODE, которое должно присутствовать в SQL- запросе. Если такое слово нашлось, то ты на правильном пути. ENCODE — это функция MySQL, используемая для кодирования некой строки секретным ключом. Синтаксис ее таков: ENCODE(«password»,«ключ для кодирования»). Ключ, как правило, лежит в сценарии, формирующем базу.

Чтобы декодировать пароли, тебе потребуется загрузить данные в свою базу данных, а затем выполнить нехитрый SQL-запрос:

SELECT user, DECODE(passwords,«секретный ключ») from users into OUTFILE ‘newusers';

В итоге вся читабельная информация сдампится в локальный файл newusers.

A: Что такое рекурсивные DNS-запросы и как с их помощью можно вызвать отказ в обслуживании (DoS)?

Q: Чтобы разрешить эту проблему, необходимо немного углубиться в теорию. Различают два типа DNS-запросов: рекурсивные и итеративные. При рекурсивном запросе сервер имен должен найти информацию самостоятельно. То есть при получении рекурсивного запроса сервер имен при отсутствии у него ответа на запрос должен сам обратиться к помощи других серверов имен, например к корневым серверам (данный запрос будет итеративным). Они сами не дадут ответа, но зато направят тебя на другие DNS-серверы. Сервер имен будет проверять все предоставленные ему ссылки, пока не обнаружит необходимую информацию.

При итеративном запросе сервер имен должен сразу предоставить ответ, не обращаясь к другим DNS-серверам. Если этот сервер не может предоставить запрошенную информацию, то он возвратит ссылку на другой сервер имен, который, вероятно, может дать ответ на запрошенную информацию.

Как видно при рекурсивных запросах, все сложности, связанные с поиском ответа, ложатся на плечи DNS-сервера, и он вынужден сам обращаться с запросами на другие DNS-сервера и обрабатывать поступающую от них информацию. Таким образом, при большом количестве рекурсивных запросов к DNS-серверу возможно исчерпывание ресурсов сервера и отказ в обслуживании.

Однако более вероятными и опасными являются распределенные атаки с использованием DNS-серверов. Они с успехом могут применяться для распределенных DOS-атак, так как они работают с UDP-протоколом, и атакующему ничего не стоит подделать обратный IP-адрес. Отправка множества запросов на разные DNS-сервера с обратным адресом хоста-жертвы вызовет большой трафик от DNS-серверов к атакуемому хосту-жертве. Серверы, поддерживающие рекурсию для распределенных атак, более предпочтительны, так как от них будет больший коэффициент умножения, особенно при использовании EDNS (RFC 2671) запросов, когда коэффициент может достигать 60-ти и более.