Недавно прочитал интересное исследование от CoreSecurity, касательно уязвимостей веб-серверов Nginx, Cherokke и Mongoose на win системах.

Суть в том, что для обратной совместимости с DOS все файлы на виндах имеют альтернативные имена.

Имя составляется так:  <Первые 6 букв реального имени файла>~1.<Первые три буквы расширения файла>

Для файла C:\foobarfoo.barfoo короткое имя будет C:\foobar~1.bar

Если же короткие имена совпадают для разных файлов, то идентификаторы увеличиваются ~2, ~3 и т.д. от самого старого к самому новому файлу.

Сама уязвимость состоит в том, что через короткие имена можно просматривать содержимое скриптов и системных файлов. Мне это сразу напомнило недавние изыскания с MySQL.

В общем рекомендую ознакомиться с этим исследованиям и намотать этот метод на ус.

Я же немного продолжу изыскания на счет коротких имен и совместимости Win машин…

Первое, что я захотел проверить был MSDN :) Порой там находятся потрясающие вещи, особенно если найти не фильтруемое исключения или еще чего-нибудь редкое.

Очень понравился пример оттуда:

Но интересным стало максимальное значение итератора ~N, который я решил проверить, создав 9 директорий testfl-long-name[1-9]. Удивление настигло, когда оказалось, что итератор ходит только до ~4, остальные значения не приводят к сопоставлению короткому имени длинного.

Воспользовавшись могучей командной утилитой dir выявил вот такое “соответствие”:

 TESTFL~1     testfl-long-name1
 TESTFL~2     testfl-long-name2
 TESTFL~3     testfl-long-name3
 TESTFL~4     testfl-long-name4
 TE78A0~1     testfl-long-name5
 TE78B0~1     testfl-long-name6
 TE78C0~1     testfl-long-name7
 TE78D0~1     testfl-long-name8
 TE78E0~1     testfl-long-name9

Порыв гугл, нашлась интересная утилита, в документации к которой значилось следующее:

        Longname         Windows 95/98/ME  Windows NT4/2K/XP
       ----------------------------------------------------------
        mylongname1          MYLONG~1          MYLONG~1
        mylongname2          MYLONG~2          MYLONG~2
        mylongname3          MYLONG~3          MYLONG~3
        mylongname4          MYLONG~4          MYLONG~4
        mylongname5          MYLONG~5          MYA476~1
        mylongname6          MYLONG~6          MYA486~1
        mylongname7          MYLONG~7          MYA496~1
        mylongname8          MYLONG~8          MYA4A6~1
        mylongname9          MYLONG~9          MYA4B6~1

И там же было предположение, на тему происхождения этих 4 хексовых символов, которое мне очень понравилось:

The hexadecimal value is probably a hash value for the string to
supposedly shorten the filename matching operation which could be
very time consuming. Microsoft programmers chose to keep the first
four match done numerically for the sake of compatibility to the
Win9X systems. What they failed to realize is that they allowed
only the first four such names for compatibility.

Мысль пошла в сторону получения явного представления этой функции.

1. Чтобы отмести параноидальные идеи по-поводу возможной рандомизации в этом значении, я повторил эксперимент, с именем “mylongname”. Мои хэши оказались в точности такие же, какие были у авторов xxcopy. Что успокоило.

2. Проверил, что короткие имена припысываются к файлу в момент его создания и не обновляются по ходу изменения других файлов в ФС. Для этого удалил первые 4 “без хэшовые” файлы (~1 ~2 ~3 ~4) – “хэшованные” короткие имена остались как были. Это тоже успокоило.

3. Удостоверился, что описания хэш-функции не найти так просто в википедии:

Beginning with Windows 2000, if at least 4 files or folders already exist with the same initial 6 characters in their short names, the stripped LFN is instead truncated to the first 2 letters of the basename (or 1 if the basename has only 1 letter), followed by 4 hexadecimal digits derived from an undocumented hash of the filename, followed by a tilde, followed by a single digit, followed by a period “.”, followed by the first 3 characters of the extension.

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

5. Понял, что не хочу тратить время на это занятие и забил ;)

На всякий случай проверил апач для в случае с короткими именами, содержащими хэш и удостоверился, что он нормально их разбирает и никаких уязвимостей там нет.

Готов пообсуждать вопрос о том, обязан ли разработчик проверять- исправлять такие вот “ошибки” в своем коде или это чисто “уязвимость веб-сервера” ;)