Дела поточные

То, что "материальную часть" надо изучать, ни у кого не вызывает сомнений. Другое дело, каким образом. К сожалению, большинство книг и публикаций предлагают лишь совершенно банальную информацию, и так лежащую на поверхности. Однако современное ПО уже достигло такого уровня сложности, что даже самый незначительный нюанс способен привести к существенным последствиям. В первую очередь это касается недокументированных или недостаточно документированных возможностей, которые остаются неизвестными многим пользователям, но вполне могут быть взяты на вооружение злоумышленниками.

Потоки, рассматривающиеся в данной статье, относятся к файловой системе NTFS и представляют собой "альтернативные" данные, которые специальным образом могут быть ассоциированы с существующим файлом. Отсюда и их более полное и точное название -- Alternative Data Streams, или ADS. Учитывая, что эта функциональность изначально присутствовала в NTFS и, соответственно, Windows NT, многие пользователи наверняка в той или иной степени с ней знакомы. Одно из наиболее очевидных проявлений -- специальная вкладка в окне свойств файла, где можно ввести название, имя автора, комментарии и пр. Несложно убедиться, что эта возможность присутствует исключительно на разделах NTFS. Впрочем, неосведомленный пользователь никоим образом не догадается, что это реализуется посредством такой "хитрой" технологии, как ADS, поэтому давайте разберемся с ней подробнее.

Для работы с альтернативными потоками используется достаточно простой синтаксис:

<file name>:<stream name>

По сути, "основное" содержимое файла также является потоком, но неименованным, что и позволяет обращаться к нему только по имени файла (на самом деле ко всем потокам неявно добавляется суффикс :$DATA). Потоки могут ассоциироваться с любыми файлами и даже каталогами, однако мы ограничимся лишь самыми элементарными экспериментами. Необходимо создать временную папку с произвольным именем, в ней -- пустой файл test.txt, затем открыть консольное окно и перебраться на подготовленный "полигон".

Команда dir выдаст вполне предсказуемый результат:

F:\test>dir

Volume in drive F is System

Volume Serial Number is A00A-8F10

Directory of F:\test

31.10.2002 16:27 <DIR> .

31.10.2002 16:27 <DIR> ..

31.10.2002 16:27 0 test.txt

1 File(s) 0 bytes

2 Dir(s) 2 031 284 224 bytes free

Пока ничего необычного. Теперь, собственно, к делу. Хотя создавать потоки можно различными способами, мы остановимся на наиболее простом и достаточно очевидном (при условии знания синтаксиса обращения к ADS):

F:\test>echo Привет > test.txt:stream1

F:\test>echo Hello > test.txt:stream2

В общем-то, на этом эксперимент можно считать завершившимся и вполне успешным, поскольку мы действительно создали у файла test.txt два дополнительных потока с именами stream1 и stream2 и даже поместили туда кое-какую текстовую информацию. Убедиться в этом также довольно несложно:

F:\test>more < test.txt

F:\test>more < test.txt:stream1

Привет

F:\test>more < test.txt:stream2

Hello

В этом месте вполне справедливо задаться вопросом, а где же зарыта та собака, из-за которой загорелся весь сыр-бор? Действительно, пока что все происходит именно так, как и обещано, и подвоха, в общем-то, не видно. Однако нужно учитывать, что мы сами создали альтернативные потоки, выбрали им имена и пр., т. е. мы заранее знали о них все. А если бы это пришлось проделать вслепую? Попробуем.

F:\test>dir

Volume in drive F is System

Volume Serial Number is A00A-8F10

Directory of F:\test

31.10.2002 16:27 <DIR> .

31.10.2002 16:27 <DIR> ..

31.10.2002 16:33 0 test.txt

1 File(s) 0 bytes

2 Dir(s) 2 031 255 552 bytes free

Теперь затронутая проблема начинает приобретать некие очертания. Оказывается, ADS не так-то просто обнаружить. Ни dir, ни Windows Explorer, ни многие другие команды и программы не помогут. Парадоксально, но даже стандартные утилиты из состава Windows ведут себя с потоками отнюдь не однозначно. К примеру, зачем бы мудрить с more и переадресацией ввода/вывода, если есть type? Да затем, что:

F:\test>type test.txt:stream1

The filename, directory name, or volume label syntax is incorrect.

Причем все подобные нюансы можно выявить исключительно опытным путем, проведя специальный эксперимент. Используются ли в системе альтернативные потоки и для каких целей, будут ли они корректно учитываться и обслуживаться различными программами (резервирования и пр.) -- рядовому пользователю неведомо. Чтобы понять глубину этих проблем, можно привести тот факт, что в 2001 г. вдруг (напомним, что технология существует с момента появления Windows NT) обнаружилось, что практически все наиболее популярные утилиты гарантированного удаления информации оставляют данные ADS в неприкосновенности. Даже сама Microsoft признает, что альтернативные потоки данных вполне могут оказаться причиной "перерасхода" дискового пространства, однако как это выяснить наверняка и как с этим бороться -- ни слова.

CrucialADS -- потоки не останутся незамеченными

Впрочем, совершенно понятно, что данная технология внедрена в NTFS неспроста. Считается, что появление ADS обусловлено необходимостью обеспечения "мирного сосуществования" в рамках одной сети платформ PC и Mac. Дело в том, что "яблочные" файлы состоят из двух потоков (в оригинале -- forks), один из которых хранит собственно содержимое, а второй -- вспомогательную информацию вроде типа файла, пиктограммы и пр. Благодаря ADS они совершенно корректно могут копироваться на и с NTFS-разделов, скажем, на файл-сервере под управлением Windows NT/2000. Бесспорно -- цель благая.

Но Microsoft не была бы сама собой, если бы ограничилась решением подобных узких проблем. Естественно, в ADS заложено гораздо больше возможностей, которые в совокупности способны превратить файловую систему в некий аналог базы данных. Скажем, уже упоминавшиеся расширенные свойства файлов (при условии, конечно, их аккуратного заполнения) позволяют организовать унифицированное хранилище разнородных документов и осуществлять в нем быстрый поиск с помощью стандартной службы индексирования (при наличии соответствующих фильтров). Этот же подход реализуется и в некоторых серверных продуктах Microsoft.

С другой стороны, наличие не слишком афишируемых функций априори означает, что рано или поздно кто-то попытается применить их в неблаговидных целях. ADS не исключение. За последние полтора-два года поступало несколько сообщений о появлении вирусов, использующих для своей деятельности альтернативные потоки данных (обычно в их названии присутствует слово stream). Справедливости ради следует сказать, что ни один из них не представлял серьезной угрозы, скорее это были "лабораторные образцы", действующие достаточно откровенно и примитивно. Скажем, один из них попросту замещал собой зараженный файл, одновременно копируя его содержимое в ADS. При этом его смогут обнаружить любые антивирусные средства.

Естественно, более хитроумные программы могли бы поступать наоборот, однако в таком случае они должны специально запускаться каким-либо способом -- ассоциировать выполнение потока и основной программы невозможно. Впрочем, все это верно лишь до обнаружения соответствующей лазейки в многочисленных механизмах ОС. Кроме того, даже в нынешнем виде ADS могут воспользоваться "троянцы", которым нередко достаточно запуститься (любым из известных способов) лишь один раз, -- именно для того, чтобы спрятаться от сканирующего ПО.

Для примера попробуем проверить созданный нами test.txt с помощью Norton Antivirus. Он отрапортует только об одном проверенном файле. Если же в явном виде указать test.txt:stream1, то число исследованных файлов сократится до 0. Можно провести даже более убедительный эксперимент -- скопировать в альтернативный поток тело стандартного тестового вируса EICAR. Результат не изменится, Norton Antivirus просто не работает с ADS. То же самое относится и к подавляющему большинству других антивирусных средств -- их разработчики считают подобную угрозу несущественной.

Вполне возможно, что пока по этому поводу действительно переживать не стоит, однако, безусловно, ситуацию стоит контролировать, во всяком случае -- освоить методики поиска и удаления альтернативных потоков (создавать их мы уже научились), а также обзавестись необходимым для этого инструментарием.

С поиском дело обстоит относительно благополучно, поскольку, как уже говорилось, проблематика ADS не нова и специалисты успели уделить ей определенное внимание, в том числе -- создать соответствующие утилиты. Вряд ли вызовет удивление тот факт, что одна из первых принадлежит перу Марка Руссиновича. Она сканирует указанные файлы (при этом умеет рекурсивно обходить вложенные каталоги) и выдает размеры всех обнаруженных альтернативных потоков.

Немногим отличается sdir -- она не поддерживает рекурсивный обход папок, зато суммирует размеры обнаруженных ADS. Программа lads совмещает возможности обеих и потому, вероятно, наиболее удобна. А crucialADS даже обеспечивает кое-какой GUI, правда, категориями, меньшими логического диска, не оперирует. Одним словом, выбрать есть из чего.

Несколько сложнее обстоит дело с удалением ADS. А все потому, что напрямую удалить альтернативный поток невозможно, поэтому приходится искать "обходные пути". Скажем, самое простое -- переместить необходимый файл с NTFS на FAT-раздел (и, при необходимости, обратно). Можно также воспользоваться теми утилитами, что не понимают ADS. Для текстовых данных вполне подойдет type:

F:\test>type test.txt > test.bat

F:\test>del test.txt

F:\test>ren test.bat test.txt

Для двоичных обычно рекомендуется утилита cat, которая входит в состав Windows 2000 Resource Kit, однако отдельно не распространяется. Естественно, проделать такие же операции с каталогами (как говорилось выше, ADS могут присоединяться и к ним) уже не получится. Существует также более универсальный пакет ads_cat (посвященный ему сайт, кажется, приказал долго жить, загрузить же архив можно по адресу packetstorm.decepticons.org/NT/), куда, кроме одноименной утилиты, входят ads_cp, ads_extract и ads_rm. Последняя -- именно для удаления, правда, в Windows XP она работает несколько странно, лишь обнуляя потоки. Поэтому по-настоящему эффективные решения сегодня придется создавать самостоятельно, например с помощью различных скриптовых средств, благо примеры имеются (вот один из наиболее хитроумных).

Як RPA-платформа допомогла SkyUр автоматизувати оплату рахунків