Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2243857
  • 博文数量: 230
  • 博客积分: 9346
  • 博客等级: 中将
  • 技术积分: 3418
  • 用 户 组: 普通用户
  • 注册时间: 2006-01-26 01:58
文章分类

全部博文(230)

文章存档

2015年(30)

2014年(7)

2013年(12)

2012年(2)

2011年(3)

2010年(42)

2009年(9)

2008年(15)

2007年(74)

2006年(36)

分类:

2007-06-07 07:53:53

Linux 内核中 FTP 跟踪中的序列号处理漏洞
 
本文档的 Copyleft 归 yfydz 所有,使用 GPL 发布,可以自由拷贝,转载,转载时请保持文档的完整性,
严禁用于任何商业用途。
msn:

来源:http://yfydz.cublog.cn

1. 前言

在进行TCP多连接协议的跟踪时, 记录数据的序列号是重要的, 因为数据包可能因为丢失而重发, 如
果不记录特征数据点的序列号, 就可能出现重复定义期待子连接的情况而浪费资源。

Linux内核中对FTP跟踪处理中考虑了序列号问题,但有些问题,可使黑客通过打乱TCP数据包顺序使
跟踪失效,而跟踪失效可能会导致phrack63-0x13一文中的攻击生效。

以下Linux内核代码版本2.6.19.2。

2. FTP跟踪中的序列号处理
 

/* include/linux/netfilter/nf_conntrack_ftp.h */
#define NUM_SEQ_TO_REMEMBER 2
/* This structure exists only once per master */
// FTP主连接中记录相关信息的结构, 主要是记录期待的序列号

struct ip_ct_ftp_master {
 /* Valid seq positions for cmd matching after newline */
// 每个方向各保存2个序列号值, 可以容排序错误一次

 u_int32_t seq_aft_nl[IP_CT_DIR_MAX][NUM_SEQ_TO_REMEMBER];
 /* 0 means seq_match_aft_nl not set */
// 每个方向记录的序列号的数量

 int seq_aft_nl_num[IP_CT_DIR_MAX];
};

对于序列号处理定义了以下两个函数:
/* net/ipv4/netfilter/ip_conntrack_ftp.c */
/* Look up to see if we're just after a \n. */
// 这个函数判断当前数据包的序列号是否是正在期待的序列号, 如果不是则跳过内容解析操作

static int find_nl_seq(u32 seq, const struct ip_ct_ftp_master *info, int dir)
{
 unsigned int i;
// 循环次数为该方向上记录的序列号的的数量

 for (i = 0; i < info->seq_aft_nl_num[dir]; i++)
// 如果当前数据包的序列号和期待的序列号中的任一个相同返回1

  if (info->seq_aft_nl[dir][i] == seq)
   return 1;
// 否则返回0表示失败,失败后虽然不解析包内容了,但仍然会调用下面的函数来调整

// 期待的序列号

 return 0;
}
/* We don't update if it's older than what we have. */
// 这个函数更新主连接所期待的序列号, 更换最老的一个,但实际是失败的

// nl_seq是要期待的序列号

static void update_nl_seq(u32 nl_seq, struct ip_ct_ftp_master *info, int dir,
     struct sk_buff *skb)
{
 unsigned int i, oldest = NUM_SEQ_TO_REMEMBER;
 /* Look for oldest: if we find exact match, we're done. */
// 循环次数为该方向上记录的序列号的的数量

 for (i = 0; i < info->seq_aft_nl_num[dir]; i++) {
// 如果当前数据包的序列号和期待的序列号相同则不用更新

  if (info->seq_aft_nl[dir][i] == nl_seq)
   return;
// 这个比较条件有问题, 当info->seq_aft_nl_num[dir]达到最大值(2)后

// oldest将永远赋值为0, 也就是两边各发出2个包后oldest就不变了

  if (oldest == info->seq_aft_nl_num[dir]
// 这个比较条件也几乎没有意义, oldest最大也就是2, 而info->seq_aft_nl表示序列号几乎不可能

// 小于2, 只有初始情况info->seq_aft_nl[dir][i]还为0是才可能为真, 其他基本永远为假

      || before(info->seq_aft_nl[dir][i], oldest))
   oldest = i;
 }
// 调整期待的序列号

 if (info->seq_aft_nl_num[dir] < NUM_SEQ_TO_REMEMBER) {
  info->seq_aft_nl[dir][info->seq_aft_nl_num[dir]++] = nl_seq;
  ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb);
 } else if (oldest != NUM_SEQ_TO_REMEMBER) {
  info->seq_aft_nl[dir][oldest] = nl_seq;
  ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb);
 }
}


3. 漏洞描述

3.1 乱序包

从代码可知,如果数据包不是顺序发送的,而是乱序,而且错位到两个包,比如正常情况下依次发送
“PORT”(主动模式子连接端口信息)、“STOR”(上载)和“NOOP”(无操作)三个命令,但如果人为调
整发包的顺序,“STOR”,“NOOP”命令包先到防火墙,而“PORT”命令包最后到防火墙,这样由于
期待的序列号不对,防火墙就不解析PORT命令中的端口了,就不会建立期待的子连接,而这种乱序包
到目的服务器后服务器会自动排序而不会发生错误。注意, “PORT”,“STOR”,“NOOP”命令包
序列号都是正确的,只是到了数据链路层后特别改了发送顺序,使得“STOR”,“NOOP”包发到防火
墙,“PORT”后到防火墙。

防火墙不解析FTP命令中的子连接参数带来的问题在phrack63-0x13中进行了描述,本blog中也专门有
介绍(phrack63中关于穿透Linux防火墙的漏洞解决方法),最终可使外部访问FTP服务器的任意端口,
以前是通过不带“\r”的命令来使防火墙忽略解析,现在是通过乱序使其忽略解析,攻击方法重新说
明如下:
网络结构:
   Extranet         (conntrack ftp,irc)        Intranet
   hacker ----------------- FW --------------- FTP Server
FW上的规则是只允许外到内的目的FTP21端口,允许内到外的目的IRC6667端口。

hacker按前面所说的方法进行文件上载操作,逆序先发送STOR和NOOP命令后发PORT命令,PORT命令中
的端口指定为6667(26,11),由于PORT命令后到,防火墙不解析子连接,FTP服务器的子连接以源端口
20,目的端口6667连接hacker,由于目的端口是6667进行IRC协议解析,而且该连接防火墙会认为这
是主连接而进行IRC解析,文件是hacker自己准备上载的,在文件中包含表示IRC子连接的“DCC CHAT
”数据,定义子连接的端口,这样防火墙就会建立一个期待的子连接允许hacker连接到FTP服务器的
任意端口。

攻击的难点:难点在于合法包的乱序发送,因此不能用系统自带的TCP栈,可能需要自己从底层编写
连接处理,或者能对指定的数据延迟发送,或者利用ip_queue,将包传到用户空间,STOR,NOOP等包
可以直接回内核,PORT包就延迟一下才返回内核;其次要求防火墙上需要打开内到外的多连接协议的
端口作为跳板。

3.2 NAT变长包

在NAT环境下,如果地址端口差别较大,这样长度就会发生变化,而系统记录的是发生了变化的序列
号,而与后续包的序列号不匹配,因此,如果连续发送两个“PORT”命令,后面那个PORT命令就不会
被解析。

不过我还没想出如何利用这个漏洞,不过正常情况不会发生同时发送两个“PORT”命令的情况,而且
攻击服务器是进行目的NAT,修改目的地址而不是源地址,因此“PORT”命令长度不发生变化,因此
这个漏洞不会影响安全,如何利用此漏洞还要好好想想。
 
3.3 oldest错误

设置oldest的目的应该是打算能同时保留NUM_SEQ_TO_REMEMBER个包的序列号,新包的序列号更新最
老的序列号,可惜算法还是有问题,两个各发送2个包后就始终只更新数组位置[0]的序列号了,位置
[1]的序列号不变。
 
4. 解决方法

对于3.1,就是如何处理乱序数据包的问题,我想是在发现当前数据包序列号大于期待序列号时不应
该更新期待序列号,同时对大于等于期待序列号的数据包都要解析,当发现子连接特征或者是当前数
据包序列号等同期待序列号才更新当前期待序列号。
 
对于3.2,就是要保存的是原始的序列号而不是修改后的序列号,在NAT helper中的长度修改不反映
到要记录的序列号中。
 
5. 结论

现在Linux内核中的FTP跟踪序列号处理还是有一定问题的,还是可能会导致非法访问,不过攻击过程
相对比较复杂,因此发生的概率倒是很小,不过漏洞修改起来也不算很难。
 
本文的漏洞已经提交netfilter开发组,昨天刚提供了相关补丁,问题3.2已经通过不向NAT helper传递seq函数解决,但3.1还没有很完善解决,我已经提供了相关的解决方法。
 
阅读(2026) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~