今天我写点NTFS的交换数据流以及其带来的安全问题（Alternate Data Stream/ADS）
=========================================================================================================================================================================
1.什么是ADS？
要了解什么是ADS我们必须先了解一点关于NTFS的知识，文件在NTFS 和FAT中的结构的区别 
Microsoft于90年代初期引入了一种称为“数据流”的概念，从而使NTFS可以作为Macintosh客户端访问文件服务器的文件系统。因为Mac OS 是利用Mac的分层式文件系统（HFS)上所谓的资源分支数据流，用于存放图标等应用程序的元数据。NTFS和FAT的差别就是FAT由一个数据流构成，而NTFS可以在一个文件内存里面存储多个数据流。
在windows协议MS-FSA中ADS的定义：
一个被命名的数据流是一个文件或者目录的一部分，它们可以独立于默认数据流被单独的打开。许多数据流的操作之影响数据流并不影响其他数据流，文件和目录
======================================================================================================================================================================
2.Stream的特性
在windows协议MS-FSCC中对NTFS stream的介绍：
所有的文件在NTFS中至少包含一个主数据流，一个文件NTFS中真正的文件名称格式是：
<文件名>:<流名>:<流种类>
默认的数据流没有名字，如果我们创建一个文件sample.txt实际在NTFS中全名是sample.txt::$DATA
不过不一样的是，如果我们创建一个文件夹，它并没有默认的数据流（Data Stream），不过它有一个默认的目录流（Default Directory Stream)是$INDEX_ALLOCATION默认的流名是I30，所以如果我们创建了一个文件夹sample，它的全名是sample:I30:$INDEX_ALLOCATION
=========================================================================================================================================================================
3.利用Stream特性隐藏文件
在CMD下输入以下代码来测试
echo test1 > test1.txt //将test1写入test1.txt中
echo test2 > test2.txt //将test2写入test2.txt中
type test2.txt > test1.txt:test2.txt //将test2.txt内容写入1.txt的ADS 1.txt:2.txt中
del test2.txt //删除test2.txt
type test1.txt //内容显示为test1
type test2.txt //已经删除了这个文件所以找不到内容
type test1.txt:test2.txt //内容显示为test2
这里我们可以清楚的看见，test2.txt中的test2已经被写入了test1.txt的流中了。
同理，我们可以把任意格式文件写入任意文件的流中，同时可以正常打开执行。
例如～将恶意VBS写入txt中之类～
========================================================================================================================================================================
4.stream特性引来的其他安全问题
这个话题有个前辈总结的不错：
::$DATA请求泄露
MicrosoftIIS 3.0/4.0 ::$DATA请求泄露ASP源代码漏洞（MS98-003）CVE-1999-0278这是一个很古老的漏洞，早期版本的IIS在处理文件请求时会先判断文件扩展名是否在可执行文件扩展名列表中，如果在，则执行并返回结果，如果不在，则直接返回文件内容。NTFS文件系统支持 在文件中包含额外的数据流。$DATA是在NTFS文件系统中存储数据流的属性。当我们对一个在NTFS分区中的ASP文件发出包含$DATA请 求，IIS会检查最后一个“.”后面的扩展名，因为多了“::$DATA”，结果IIS不认为这是一个ASP文件，而文件系统可以识别该请求，于是ASP 的源代码被返回。在高版本的IIS以及其他的Web Server中测试没有发现该问题
隐藏webshell
这种利用思路最早由80sec提出，很好的利用了ADS的隐蔽性。由于目前的webshell检测程序都还没能考虑到ADS层面的检测，所以，这是种隐藏web后门的很好的方式。来看一个很简单的demo：在test.php中添加<?phpinclude(“1.php:.jpg”); ?>，在1.php:.jpg中写入后门代码。访问test.php时，后门代码能成功解析。
Bypass HTTP Basic Authentication
对于IIS6.0+PHP、IIS7.5+asp、IIS7.5+php环境下，如果某目录通过HTTP Basic来认证，假设其目录下有index.php文件，我们可以通过构造如下方式来绕过认证直接访问其目录下的文件。/admin::$INDEX_ALLOCATION/index.php/admin:$i30:$INDEX_ALLOCATION/index.aspBypass黑名单验证上传对于windows环境的服务器，上传1.asp:.jpg类型的文件，当文件传到服务端时，windows会将该文件识别成ADS，从而认为其宿主文件名为1.asp而将.jpg识别为流名。在测试过程中（测试环境中WEB Server为IIS、Apache、Nginx）无论如何构造都无法访问可以解析的文件。前面我们提到，对于1.asp:.jpg这类ADS，其完整的全称为1.asp:.jpg:$DATA，stream name可以省略但stream type是不能省略且不能自定义的。我们在测试中发现，当上传1.php::$DATA时（文件内容为phpinfo），在存储时会出现逻辑问题，导致生成非空的1.php文件，当中的内容为1.php::$DATA的内容且可以正常在webserver下解析。该逻辑问题与语言无关与web server无关，也就是说上传1.asp::$DATA也会生成非空的1.asp文件，1.jsp::$DATA同样。另外，当1.php::$INDEX_ALLOCATION或1.php:$I30:$INDEX_ALLOCATION时，存储时逻辑同样会出现问题，会把该文件误认为是文件夹，从而建立一个1.php的空文件夹。（注：directory流默认stream name为$I30）Windows还有个特性，就是当文件夹名或文件名末尾的任意个数的空格或点，在存储时都会自动去除，所以当上传1.php::$DATA………….或1.php::$INDEX_ALLOCATION……………此类文件同样会造成上述的存储时的逻辑错误。在MySQL UDF提权中的利用MySQL5.1及其之后的版本，使用UDF提权时，指定UDF必须导出在MySQL目录下的libplugin下才有用，而非完全版的Mysql默认安装后没有plugin这个目录，且在MySQL中没有可创建文件夹的函数。（通常很多时候在webshell中也无权限建立该目录），可用如下的SQL建立文件夹select‘xxx’ into outfile ‘c:\test::$INDEX_ALLOCALTION\’；同样由于windows在处理时会把c:test::$INDEX_ALLOCALTION当做ADS处理，从而生成一个test文件夹
这里的总结原文来自：http://www.xcl0ud.net/?p=9
==========================================================================================================================================================================
5.ADS的黑历史
国内最早的关于ADS利用的文献我找到的是lu0（驱动之家创始人）在2001年的时候写的，而国外文献我找到的最早的是在2002年，我想说十几年过去了，关于ADS特性引发的漏洞由IIS 4.0到5.0到6.0到7.5多多少少都有，所以我认为NTFS的这个特性非常值得深入研究。没准以后在别的地方还能挖掘出一些价值
=========================================================================================================================================================================
Thanks for read this article。