|
 | 作者: group [group]
 论坛用户 |
登录 |
| 该文从被扫描，到扫描的纪录分析，判断扫描工具、目的 最终没有得出准确的结论 我大致的看了一下，初学者也适合看，同时还可以练一练英文：D # # SCAN OF THE WEEK #0 - 21-27 May # # Weekly contest to see who can determine which tool # was used for this scan. All signatures were captured # with snort (http://www.snort.org). # # The following signatures are from the wild. # Can you name the tool? # # Anything on the 172.16.1.x network are the good guys. # Anything else are the bad guys. :) Recently my network received an unusual scan, deciphering it has proven difficult. With some outstanding help from the security community, here is my best guess at what the scan is. THE SCAN -------- On 20 May, one of my systems received a unique scan from three systems. The three systems are: jive.rahul.net (192.160.13.4) bug.rahul.net (192.160.13.7) foxtrot.rahul.net (192.160.13.6) The scan signature is exactly the same from all three systems, they scanned ports 1-1024 (see signature below). Of these three systems, one is not active (jive.rahul.net) so we know for certain that at least one system was spoofed. The other two systems (bug and foxtrot) are up. This was confirmed both by hping and by the system owner, Rahul Dhesi <dhesi@rahul.net> However, I do not know if the two live systems were spoofed or not. --- snort snort --- 05/20-17:06:45.061034 192.160.13.4:31337 -> 172.16.1.101:1 TCP TTL:44 TOS:0x10 ID:242 ***FRP** Seq: 0xA1D95 Ack: 0x53 Win: 0x400 . . . 05/20-17:06:58.685879 192.160.13.4:31337 -> 172.16.1.101:1024 TCP TTL:44 TOS:0x10 ID:242 ***FRP** Seq: 0xA1D95 Ack: 0x53 Win: 0x400 --- snip snip --- THE TOOL -------- These packets were crafted by a tool, they were not created by a standard IP stack. We can determine this based on the following: 1. The Seq, Ack, and IP ID numbers are the same for all 1024 packets. An IP stack would have increasing numbers for all three. 2. Note the TCP flags, FIN, RST, and PSH. No standard IP stack would produce such a packet, nor would any IP stack respond with such a packet. Many people commented that this was Back Orrifice because the 31337 port, but that is not the case. First, BO uses UDP by default. Also, Dildog had this to say about the scan: "A bo2k scanner would never come -from- port 31337. Something might scan -you- for sockets listening on 31337, but not the other way around. Regardless, this would have been BO, not BO2K, since BO2K doesn't have a default port. This just looks like a regular port scan to me with a fixed local port." So, this scan was most likely done by a scanner that creates its own packets, but which one? Not nmap: Nmap does not have a FRP flag option. Nor does it use constant Seq, Ack, and IP ID numbers. Not hping: Hping can set most of the functionality of this scan, but it CANNOT set the Seq or Ack number. The best guess we have among the security community is these signatures were created by Libnet, some one has created their own packets. Why Libnet? To qoute Simple Nomad (and Aaron Campbell) "I thought these values looked familar. Took me a bit, but check out the sample programs that come with Libnet. In there you will find id 242, seq a1d95, ack 53, and a ttl of 48. Looks like someone was playing around trying to write a scanner of sorts using the Libnet sample progs as a starting point, and scanned you. So check every machine 4 hops away...." NOTE: I tried the traceroute 4 hops out, it was a router, most likely not our suspect :( So, based on what we know, our best guess is that Libnet was used to create these packets. PURPOSE OF THE SCAN ------------------- This is the most confusing part, the TCP Flags FRP do not generate a response, from open or closed ports. This has been tested on a variety of systems by a several people, inlcuding Max Vision, Dennis Ducamp, and myself. So why run a scan when you won't get any results? I do not know. Maybe someone was testing their coding or scanning skills. Perhaps they were trying "man-in-the-middle" scan techniques. We may never know :( K2 from ADM CREW has an interesting theory "Well, not really, what if your not using the TCP/IP stack of the OS but rather something like libpcap backdoor and are looking for weirdo options ( this will enable you to communicate through onto a firewall'd system )... he dose use libnet to communicate with it so it lead's me to believe that he wants to have a sub-carrier connection that is not normally valid. Source port significance is a really good way to authenticate to a backdoor (ip independent), and can be detected by the trojan early (able to bypass system logging). Exactally, libpcap based backdoor with a libnet based client to pipe i/o to the backdoor... I dont know why they would scan all the ports other then to assume that the backdoor on the host may modulate the port it's listening on... also, a system like this could listen on a port already allocated by the system like even if telnetd is running... you can still contact your backdoor on port 23 because your connect to that port is not valid to anything that the system would have there (your basically going up your libpcap stack insted of the OS), this also helps get past any host firewall." A comment from the system owner Rahul Dhesi, who has been extremely helpful with this analysis. "Hi, I don't see any obvious signs of a break-in on bug.rahul.net or foxtrot.rahul.net. Also, they are running different OSs: foxtrot is SunOS 4.1.3_U1, while bug is FreeBSD 3.4-STABLE. It seems doubtful to me that somebody would break into two machines running different OSs at around the same time. if somebody really broke into one of them, he would likely attack other machines on the network running the same OS. So I'm guessing that all packets were spoofed." Side note, FRP packets are not entered in the state table for FW-1 firewall. Even though the packet may be accepted and logged, the packet would not enter the FW-1 state table. ADDENDUM -------- If you have any comments or words of wisdom you would like to add, please email me at Lance Spitzner <lance@spitzner.net>. Also, I have posted the raw data (tcpdump/snort binary format>. You can download it at http://www.enteract.com/~lspitz/scan.gz Thanks to the following people for their help and ideas: Nelson Murilo <nelson@pangeia.com.br> Bill Pennington <billp@rocketcash.com> Aaron Campbell <aaron@cs.dal.ca> Denis Ducamp <Denis.Ducamp@hsc.fr> Simple Nomad <thegnome@nmrc.org> K2 ADM CREW ... and the many others who sent their ideas |
| 地主 发表时间: 03/17 01:37 |
 | 回复: danjames [danjames]  论坛用户 |
登录 |
|
看起来真生涩，我正在翻译，头好大！ 大伙稍等就能看到中文版的了，至于词不达意，我就不管了：） 谁让偶英文差呢！ |
| B1层 发表时间: 03/19 16:11 |
| 回复: danjames [danjames] 论坛用户 |
登录 |
|
本周扫描 5月21日�D�D27日 本周论辩可以了解此次扫描决定使用哪几个工具。所有的数据都被Snort捕获了。 (http://www.snort.org) 下面的签名来自wild 你能指出要使用的工具吗？ 任何可以在172.16.1.x上使用的工具都是好东东，反之则不是我们需要的。 最近我的网络接受了一次不寻常的扫描，看起来解释很困难。从一些安全小组获得了一些有效的帮助，这里是我对这次扫描最准确的解释了。 扫描 5月20日，我的一个系统承受着来自三个系统的独特扫描 jive.rahul.net (192.160.13.4) bug.rahul.net (192.160.13.7) foxtrot.rahul.net (192.160.13.6) 来自全部三个系统的扫描信号是同样严密的，他们扫描了端口1至1024。三个系统中，一个 (jive.rahul.net)不是有效的。所以我们确切的知道至少一个是欺骗。另两个系统 (bug and foxtrot) 在运作着 。这些都被Hping和系统管理员Rahul Dhesi <dhesi@rahul.net>所证实。然而，我还是不知道这两个运作着的系统是欺骗主机或者不是。 --- snort snort --- 05/20-17:06:45.061034 192.160.13.4:31337 -> 172.16.1.101:1 TCP TTL:44 TOS:0x10 ID:242 ***FRP** Seq: 0xA1D95 Ack: 0x53 Win: 0x400 05/20-17:06:58.685879 192.160.13.4:31337 -> 172.16.1.101:1024 TCP TTL:44 TOS:0x10 ID:242 ***FRP** Seq: 0xA1D95 Ack: 0x53 Win: 0x400 --- snip snip --- 工具 这些信息包是由一个工具制作而成的，他们不是由一个标准的IP堆栈生成的。我们可以从以下的资料确定。 1、 1024个信息包中所有的Seq，Ack和ip身份号码是一样的。IP堆栈数应该是呈递增的。 2、 记录TCP标记，FIN，RST，和PSH。没有哪个标准IP堆栈可以生产出这样的一个包，也没有那个IP堆栈可以回复出这样一个包。 很多人断定是Back Orrifice是因为31337端口，但是那不是重点。第一，BO默认使用UDP（用户数据报协议）同时，Dildog关于SCAN也有以下的说法： “一个BO2K 的扫描器从来不来自31337端口。一些可能扫描到你的如：在套接层监听31337端口，但是没有其它可能接近的办法了。不注意，那是有可能中BO，但不是BO2K，因为BO2K没有默认端口。这对我来说看起来更象是一个固定本地端口的正规扫描报告。” 所以，这个扫描看起来更象由一个扫描器用他自己生成的信息包来完成的。但是哪个工具呢？ 不是Nmap: Nmap没有最后进程报告标记选择项。也不用常量的Seq, Ack, 和 IP身份号码。 不是Hping: Hping可以设置几乎所有的功能性扫描选项，但是他不能设置 Seq和Ack数字。 我们得自于安全小组的最好的推测是这些信号来自于Libnet，一些可以生成他们自己的信息包。为什么是Libnet？To qoute Simple Nomad (and Aaron Campbell) 我想这些数值看起来很相似。给我一个Bit，然后用Libnet的标本程序来检查。你可以发现id 242，seq， a1d值95，ack值53，还有 ttl 值48。看起来象某些人用Libnet取样试图写出一种分类扫描器，所以扫描你。所以检查所有机器的4个远端网段。 注意：我试着用traceroute 这4个网段。是个路由器，看起来不象我们的疑犯。 所以，从我们所知道的来看，最好的推测是Libnet被用来生成这些信息包。 扫描的目的 这是最容易糊涂的部分，传输控制协议标志的最后进程报告中，从开放或者关闭得端口中没有产生一个响应。这些是几个朋友（Max Vision，Dennis Ducamp和我自己 ）在不同的系统上测试的。当你不能得出什么结果的时候为什么要运行一个扫描器？我也不知道。也许，他们可以测试一下他们的代码和扫描能力。也许他们正在令人厌倦的扫描技术提高期。我们不可能知道。 K2从ADM团队得出一个有趣的原理。 “不是真的，倘若你不使用系统TCP/IP堆栈而宁愿用一些类似于libpcap backdoor和去寻找哪些稀奇古怪的选项（这些将授权他们通过防火墙系统）…他没有用Libnet和用他通信，这让我相信他想要建立一个sub-carrier连接，那不是正常有效的。源端口有效性是真正的鉴别是否后门的好途径（独立IP），还可以及早发现木马（能远程登录）。 严格来说，libpcap是以libnet基础客户端基于后门的…我不知道为什么他们会扫描所有的端口然后设想后门已经在主机上把端口调整成监听状态了。同样，系统喜欢把某些端口设置成监听状态，甚至telnet也开着，你甚至可以通过23端口连接你的后门，因为连接那个端口不是对任何都有效的，因为系统也在那儿呢。（你主要的进行libpcap系统堆栈溢出）这些，也可以帮助你通过一些主机防火墙。” 来自系统所有者Rahul Dhesi对这次分析非常有帮助的建议 “hi，我就不说哪些显而易见的从bug.rahul.net和foxtrot.rahul.net捕捉到的信息，同样，他们运行了不同的系统： foxtrot的是SunOS 4.1.3_U1, bug 是FreeBSD 3.4-STABLE。对我来说如果说某些家伙同时进入了这两台运行不同系统的机器，那是值得怀疑的。如果他们真的进入了两台其中一个，他很可能象进攻其它机器那样，在网络上运行这相同的系统。所以我猜测这两个信息包都是欺骗包。” 旁注：FRP信息包没有进入FW1防火墙状态表中，尽管这些信息包被接受并且可以登录，信息包没有进入FW1状态表。 附录 如果你有什么好的解释或者看法想加进来，请……… 后面哪些费话我就不管了，肯定有错，谁让我英文菜呢：） 大伙多多包涵：） |
| B2层 发表时间: 03/19 16:56 |
 | 回复: jpcc [jpcc] 论坛用户 |
登录 |
|
厉害！！！ E文一级棒呀！！！！！ 什么时候有空教教我呀！ |
| B3层 发表时间: 03/22 05:11 |
| 回复: danjames [danjames] 论坛用户 |
登录 |
|
其实我英文也菜，不过大伙读个大体意思吧：） |
| B4层 发表时间: 03/22 10:52 |
| 回复: maomao417 [maomao417] 论坛用户 |
登录 |
|
嘿嘿 翻译的就是好~ E文好差哈~ |
| B5层 发表时间: 03/22 12:53 |
|
20CN网络安全小组版权所有
Copyright © 2000-2010 20CN Security Group. All Rights Reserved.
论坛程序编写：NetDemon
粤ICP备05087286号
论坛: 菜鸟乐园 标题: 扫描报告分析实例（这可不是简单的分析哦）