[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dailydave
Subject:    Re: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet
From:       Dave Aitel <dave.aitel () gmail ! com>
Date:       2011-01-17 2:51:50
Message-ID: AANLkTinG3hV8Twfw6QiGv39=1sH-_0vGQ8gN5M+rrV2z () mail ! gmail ! com
[Download RAW message or body]

That was an awesome display, but I am always reminded of this
fantastic discussion of Robert Frost's classic poem "Fire and Ice"
when involved in such things. Especially Dvonna's fantastic
contribution to the thread (see below)
http://oldpoetry.com/opoem/4158-Robert-Frost-Fire-And-Ice

"""
eclipse....?
> From guest Dvonna (contact)
Well.... When bella is bitten, Her life is being ended by the burn of
venom. Correct? If she stayed human, [chose jacob,] Then her life
would one day end in ice. Correct? So think about that. Bella wants
her life to end in fire. But if Edward were to leave her, [if she had
to perish twice] ice would also be great as in jacob would be her
second choice. Just because Edward is cold and hard, doesnt mean that
he is ice. And just because Jacob is warm... actually burning hot,
well that doesnt make him fire. This poem relates to eclipse because
its talking about the way of life that person would chose, and also
the second choice. You see?
"""
It's like you guys are doing an interpretive phenomenological analysis
of sending packets down the wire, or as Husserl would wish, making
science a "second order knowledge system, which depends ultimately on
first order personal experience". Honestly, which one of these tools
is Jacob, and which one is Edward? Cause I know which team I'm on! :>

-dave


On Sat, Jan 15, 2011 at 1:27 PM, Nelson Brito <nbrito@sekure.org> wrote:
> There we go, again. But that will be my last message on this thread.
> 
> Despite some of my fellows have been asking me to let it go, I cannot ignore some \
> misconceptions you are bringing to this thread. 
> T50 main goal is to show that we can do some type of performance metrics using an \
> regular (ordinary) Linux box and programming in user space. SmartBits, AFAIK, is a \
> great tool, but I've never used it. So I have no ambition of having T50 being \
> compared to SmartBits, neither of having such performance nor even its features. \
> T50 will use the NIC connected to the network you are testing, so I have no plans \
> to support multiple interfaces... Not yet! But people can find a way to do this, \
> right? =) 
> Let me address your points:
> 1. T50 has no measure mechanism and will not have, because there some limitations \
> we have to deal with, and these limitation directly impact the T50 performance. \
> You're probably aware of them, right? Why did you think T50 should play with \
> multiple interfaces? 
> PS: On the attacker machine any tool can report wrong statistics about packets per \
> second sent, because the Linux Kernel will silently drop the packets when a device \
> queue overflows (http://linux.die.net/man/2/sendto), This is due to ENOBUFS - this \
> error is not reported by Kernel, and sometimes the tool overflows the queue and \
> keeps increasing the packet count. What do you do in this case? What is your \
> analysis? Was the packet discarded by Kernel? Was the packet blocked by a Firewall, \
> IPS, Router, or Switch? To address this inconvenient fact the only thing that comes \
> from the top of my mind is using SELECT or PSELECT, but both of them can impact in \
> the performance. Please, don't even think of using SLEEP, USLEEP or NANOSLEEP. 
> 2. Everything you said sounds really smart, but you are missing two key points:
> a. T50 uses random values to fill protocols fields, and that is exactly what it \
> MUST do. b. According to the above statement, the checksum calculation, regarding \
> T50 concept, only makes sense if T50 applies two threads, and I have no plans to \
> add multi-thread capabilities to any public version of T50. 
> PS: MEMCPY is a pain in the ass, but it is addressed by the new version (5.3). The \
> sock buffer is already addressed by the same mechanism used by libnet_raw.c: \
> http://code.google.com/p/locust-security/source/browse/trunk/libs/libnet/src/libnet_raw.c?spec=svn370&r=370
>  
> 3. I am not denying anything, I just don't understand your comparison. T50 builds \
> its own packets, and never depends on a PCAP file. If you don't have a PCAP file, \
> TCPREPLAY is just useless, because it just doesn't generate anything. Am I wrong? \
> So let's get an example: a. You are about to test EIGRP in an internal network and \
> you need an EIGRP PCAP file, but you don't have it. What do you do? Will TCPREAPLY \
> generate an EIGRP PCAP spontaneously? b. You are about to test internal/external \
> WEB Servers and their capabilities to deal with TCP Options, and you just have a \
> regular TCP PCAP file (w/o TCP options). What do you do? Will TCPREAPLY generate a \
> TCP PCAP file with TCP options spontaneously? 
> c. You are about to test EIGRP in an internal network and you need a bogus EIGRP \
> PCAP file, and you only have a regular EIGRP PCAP file. What do you do? Will \
> TCPREPLAY make this regular EIGRP PCAP file a bogus EIGRP PCAP file? 
> 4. You are not missing anything on T50 code, you are missing HPING code and, maybe \
> its main purpose. Heck... You are also missing the video showing a quick comparison \
> with 'hping --flood' and 't50 --flood'. But here is a macro view of the \
> differences, so you won't need to go thru all HPING source code, and the hyperlink \
> to the video: http://www.4shared.com/file/tEnOjWb8/the_hangover.html
> http://securitytube.net/T50-in-Action-video.aspx
> 
> PS: Just to give you an idea about this approach:
> (I) Dell Latitude E6400 (Intel® Core™ 2 Duo P8400 @ 2.26 GHz + 4 GB RAM + Ubuntu \
> Desktop Linux 10.04 64-bit) EXAMPLE EXECUTION               PREVIOUS                \
> HELLO01 hello01         2.705625 sec
> hello02 2.575794 sec    105.04 %                105.04 %        (1.05 times)
> hello03 2.536282 sec    101.56 %                106.68 %        (1.07 times)
> hello04 0.077759 sec    3261.72 %               3479.50 %       (34.80 times)
> hello05 0.026442 sec    294.07 %                10232.30 %      (102.32 times)
> hello06 0.016134 sec    163.89 %                16769.71 %      (167.70 times)
> 
> (II) Dell Inspiron 910 (Intel® Atom™ N270 @ 1.60 GHz + 1 GB RAM + Ubuntu Desktop \
> Linux 10.04 32-bit) EXAMPLE EXECUTION               PREVIOUS                HELLO01
> hello01         6.839691 sec
> hello02 6.346019 sec    107.78 %                107.78 %        (1.08 times)
> hello03 6.283515 sec    100.99 %                108.85 %        (1.09 times)
> hello04 0.376603 sec    1668.47 %               1816.15 %       (18.16 times)
> hello05 0.206651 sec    182.24 %                3309.78 %       (33.10 times)
> hello06 0.138612 sec    149.09 %                4934.41 %       (49.34 times)
> 
> 5. That is great, one request less. About the "re-inventing a wheel", I am kind of \
> tired of hearing this... Imagine a world that is really happy with STROBE and \
> nobody developed NMap. I don't like this world. I have no ambition of saying T50 is \
> as innovating as NMap is, but it addresses my needs of having a tool to perform \
> some stress testing and that could be launched from my notebook... So I am not \
> spending my spare time with something useless, in opposite, I am doing something to \
> address my needs and sharing with the community. About T50 being inferior to \
> readily available ones, I have a video showing the opposite, can you show me any \
> evidence of your statement? Here is another evidence of my statement: \
> http://twitpic.com/2cu3ib/full. 
> From: Aaron [mailto:apconole@yahoo.com]
> Sent: Friday, January 14, 2011 2:01 PM
> To: Nelson Brito; dailydave@lists.immunitysec.com; bugtraq@securityfocus.com; \
>                 full-disclosure@lists.grok.org.uk
> Subject: Re: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet Injector \
> v2.45r-H2HC 
> This will be my last post on the thread. You can think I'm trying to troll you all \
> you want - doesn't mean that is my intent. 
> The goal, as I understand it, of T50 is to be a software based version of a \
> SmartBits tester, yes? You aim to saturate a network link with as much traffic as \
> possible, and that traffic needs to be predictable. In that case, you need to keep \
> a few important requirements in mind: 
> 1 - if we want to saturate multiple links simultaneously, having multiple contexts \
> of execution being able to feed multiple network devices would be a good thing(tm). \
> Additionally, you need a way to measure what's being done on the link - best way to \
> do that is with a second nic which is able to capture the packets. Preferably, this \
> is not just done with tcpdump/wireshark and manually trying to correlate. 
> 2 - You failed to understand what packet_mmap is, or what I meant by checksum \
> recalculation. Here's a quick logical proof: a - Time spent working on the packet \
> is time spent not transmitting b - Time spent not transmitting is time that the \
> network may have to absorb your attempt at saturation c - Time spent computing \
> checksums, rebuilding packets from the header, from the very beginning is time \
> spent working on the packet d - Time spent memcpy()'ing from userspace to kernel \
> space is additionally, time spent not transmitting e  - Using these mechanisms \
> (like the packet_mmap tx ring) reduces your latency for transmission and tries to \
> push the bottleneck as close to the hardware as possible. Your code makes at least \
> 2 memcpy()s. Additionally, you don't use the ethtool IOCTLs to try and increase the \
> actual nic buffers, which I think we can both agree is just a smart idea. 
> 3 - TCPREPLAY has far more advantage than T50; don't bother trying to deny it. It \
> floods a link just as well as T50, and since you control the pcap, you control the \
> packets transmitted - and can do anything with them, not just whatever options T50 \
> allows. Tcpreplay can also flood with the captured packet's MAC included, meaning \
> that if you do this to test your network, you can test your ability to detect which \
> macs/ports can be turned off/on to alleviate an internal attack. The fact that you \
> can even use real-world packet captures is just gravy. I can take emacs in hex mode \
> and stamp out a TCP-SYN. Heck, I can use a packet capture of HPING and have a \
> tcp-syn. Pcaps of interesting traffic are all over the internet, just use some \
> google-fu. Heck, I can get captures of 3gpp traffic searching google. You have any \
> SCTP generation? Any RRC or NBAP message flooding? When can I expect T50 to have \
> this functionality? tcpreplay has it, as long as I have the packets. 
> 4 - You still didn't explain how this isn't just hping --flood? I've gone through \
> the code - what am I missing? I'm curious - you just decided to attack me, and call \
> me stupid - I've refrained from juvenile responses. What am I missing? What power \
> do I get with this tool that I don't already have? 
> 5 - I'm not trying to have you give me, or anyone else credit - and nowhere in my \
> email did I say such. I, frankly, don't care who gets their name plastered on what \
> piece of if/then/else code; I do care to evaluate potentially better network \
> saturation solutions, since that's part and parcel of my day-to-day life at work \
> (network flood testing). I've used smartbits, tcpreplay, and tried using T50. It's \
> not even close to either of those tools in terms of features. It doesn't have any \
> clear advantage, either. I'm just trying to help you not spend your time \
> re-inventing a wheel that is inferior to readily available ones. You can take that \
> any way you want. 
> Regards,
> -Aaron
> 
> From: Nelson Brito <nbrito@sekure.org>
> To: Aaron <apconole@yahoo.com>; dailydave@lists.immunitysec.com; \
>                 bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
> Sent: Fri, January 14, 2011 9:10:15 AM
> Subject: RE: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet Injector \
> v2.45r-H2HC 
> I do appreciate any feedback, but I've been asking myself if you are really \
> seriously writing this or just making a joke with all the list members... Did you \
> bring the TCPREPLAY to this discussion??? I cannot imagine what kind of unsound \
> mind could bring this comparison. 
> Two main factors led me to write this message:
> 1. TCPREPLAY and T50 have different approaches for different goals. How could you \
> compare T50 to TCPREPLAY? T50 doesn't play with captured files (PCAP), in opposite \
> T50 does play with its own packets and can be used to feed TCPREPLAY. 2. Do you \
> really think packet_mmap could help any Stress Testing tool (Flooder and/or Packet \
> Injector) to get a better performance? Delta calculation with random packet field? \
> Come on... We are talking about different things here, aren't we? 
> And lastly, but not least, how could you pretend to do something to get a \
> high-performance fashion playing with multi-core (multi-thread) if you are still \
> limited by Kernel's network device queue??? Are you insane??? 
> Please, you don't have to answer any of my questions... Please, don't. It could be \
> much more embarrassing. 
> T50 plays in an user level, and this was explained during the H2HC 7th Edition. The \
> reason I did this is to show that cool things can be done in this space (user \
> space), with no Kernel patch or Kernel driver module. The concept is not new, and I \
> didn't say it is. IRC old-school (old is cool [?] =D) will remember all things I \
> did with this code. T50 is the very first public tool applying multi-protocol \
> injection using a single socket - AFAIK. That said, how you dare to compare T50 and \
> TCPREAPLY? I am not a TCPREPLAY expert, but I am not aware of any feature of \
> TCPREPLAY that makes it able to inject packet without a PCAP file. 
> I do refuse myself to enter in another battle, but do you really believe on what \
> you said? 
> I will not explain anything else to you, if you want to see the slide-desk, be my \
> guest: http://www.slideshare.net/nbrito01/the-hangover-a-modern-high-performance-approach-to-build-an-offensive-computing-tool
>  
> BTW, if you really think I have to give you any credit, please, give me evidences \
> of something I should give credit to you or to anybody else, a credit other than: \
> "you are an excellent and freaking great Internet troll". Otherwise, please, just \
> stop trolling me with all your frustration and find something really interesting to \
> do with your life... 
> Nelson Brito
> Security Researcher
> http://fnstenv.blogspot.com/
> 
> 
> From: Aaron [mailto:apconole@yahoo.com]
> Sent: Thursday, January 13, 2011 1:35 PM
> To: Nelson Brito; dailydave@lists.immunitysec.com; bugtraq@securityfocus.com; \
>                 full-disclosure@lists.grok.org.uk
> Subject: Re: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet Injector \
> v2.45r-H2HC 
> I don't see the "wow" factor from this tool? Perhaps I forgot to take my "super \
> l33t" pills, but I fail to see how this is different from something like tcpreplay, \
> which not only does any packet(s) desired, but can pull them from an existing \
> packet capture (and even edit those packets on the fly) allowing one to truly \
> customize the traffic as much as possible. Additionally, I looked at this tool \
> hoping for some "exciting" new code, but found nothing which people writing router \
> / gateway software haven't known for years. In fact, you didn't even do intelligent \
> checksum recalculation (ie: store a "base" checksum somewhere, and just do some \
> quick delta calculation on it), and you didn't take advantage of packet_mmap on \
> linux (zero copy seems like good juju for high-speed network transmission); HECK \
> you're running from a single context of execution, instead of trying to execute on \
> all available cores (which could add some scalability, depending on the \
> architecture). 
> I don't want to sound like I'm a total negative nancy - and certainly security is a \
> hobby domain, not my primary area of expertise, but you posted this to a publicly \
> available forum, so I suppose you were looking for some type of vetting, criticism, \
> and feedback. My feedback would be to contribute to tcpreplay. There's nothing that \
> your tool offers as an advantage (from a cursory glance, your tool appears to be \
> hping --flood) to any available options; there's nothing unique that I saw. 
> Additionally, my noscript caught a click-jacking attempt from your homepage when I \
> went to download the file. I might suggest a better file serving mechanism. 
> -Aaron
> ________________________________________
> From: Nelson Brito <nbrito@sekure.org>
> To: dailydave@lists.immunitysec.com; bugtraq@securityfocus.com; \
>                 full-disclosure@lists.grok.org.uk
> Sent: Tue, January 11, 2011 2:43:35 PM
> Subject: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet Injector \
> v2.45r-H2HC 
> T50 Sukhoi PAK FA Mixed Packet Injector (f.k.a. F22 Raptor) is a tool
> designed to perform "Stress Testing". It is a powerful and an unique packet
> injection tool, that is capable of:
> 1. Send sequentially (i.e., ALMOST on the same time) the following
> protocols:
> - ICMP: Internet Control Message Protocol
> - IGMP: Internet Group Management Protocol
> - TCP:  Transmission Control Protocol
> - UDP:  User Datagram Protocol
> 
> 2. Send an (quite) incredible amount of packets per second, making it a
> “second to none” tool:
> - More than 1,000,000 pps of SYN Flood (+50% of the network’s uplink) in
> a 1000BASE-T Network (Gigabit Ethernet).
> - More than 120,000 pps of SYN Flood (+60% of the network’s uplink) in a
> 100BASE-TX Network (Fast Ethernet).
> 
> 3. Perform “Stress Testing” on a variety of network infrastructure, network
> devices and security solutions in place.
> 
> 4. Simulate Denial-of-Service attacks, validating the Firewall rules and
> Intrusion Detection System/Intrusion Prevention System policies.
> 
> Further information can be found @ http://fnstenv.blogspot.com (demo video
> and source code).
> 
> PS: Yes, there are some "anti-kiddo" tricks, so, please, don't blame me for
> doing that...
> 
> The new version of the "T50 Sukhoi PAK FA Mixed Packet Injector" (v5.2-NG)
> will be unleashed on "WEB Security Forum" (http://websecforum.com.br/evento/
> / April 9th-10th 2011 / Săo Paulo, Brazil).
> 
> The next release will include:
> 1. New License: It is still not licensed under GPL or any other common
> Open-source license, but the source code will be available and the use of
> any piece of source code for any free or commercial software is denied.
> 
> 2. CIDR Support: Classless Inter-Domain Routing support for destination IP
> address, using a really tiny C algorithm. This would allow the "T50 Sukhoi
> PAK FA Mixed Packet Injector" to simulate DDoS in a laboratory environment.
> 
> 001 netmask = ~(0xffffffff>>cidr);
> 002 hostid = (int)(pow(2,(32-cidr))-2);
> 003 __1st_host = (ntohl(addr)&netmask)+1;
> 004 __lst_host = (ntohl(addr)&netmask)+hostid;
> 
> 3. TEN NEW Protocols: TEN (10) more protocols supported by "T50 Sukhoi PAK
> FA Mixed Packet Injector" (IGMPv3, EGP, DCCP, RSVP, RIPv1, RIPv2, GRE, ESP,
> AH and EIGRP).
> 
> 4. Exotic Protocols: Advanced options and protocol crafting for EIGRP and
> GRE were added, allowing users to make any combination while using those
> exotic protocols. By the way, EIGRP is a proprietary protocol developed by
> CISCO Systems, Inc.
> 
> 5. TCP Options Support: TCP Options (MSS, NOP, EOL, WSCALE, TSTAMP, T/TCP CC
> and SACK) are supported to improve the TCP protocol.
> 
> 6. DATA Payload Support: The data payload support is back, and it can be
> rand or user defined.
> 
> Best regards.
> 
> Nelson Brito
> Security Researcher
> http://fnstenv.blogspot.com/
> 
> 
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
> 
> 
> 
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
> 
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunityinc.com
https://lists.immunityinc.com/mailman/listinfo/dailydave


[prev in list] [next in list] [prev in thread] [next in thread]