|
StackScrambler and the Tale of a Packet Parsing Bug |
Si vous voulez bloquer ce service sur vos fils RSS
Si vous voulez nous contacter ou nous proposer un fil RSS
Menu > Articles de la revue de presse : - l'ensemble [ tous | francophone] - par mots clé [ tous] - par site [ tous] - le tagwall [ voir] - Top bi-hebdo de la revue de presse [ Voir]
Présentation : A core feature of the BreakingPoint product line is the ability to perform any kind of layer 2-7 testing with a single hardware device. BreakingPoint's functionality is divided into 7 test components; these are Bit Blaster for layer 2 ethernet traffic, Routing Robot for layer 3 IP traffic, Session Sender for layer 4 TCP and UDP traffic, AppSim for layer 7 application traffic, Recreate for replaying any captured layer 2-7 traffic, Security for malicious traffic, and finally Stack Scrambler for malformed or fuzzed but benign traffic. My previous posts have predominantly focused on testing using the Security component for testing IPS. Today, I want to take a look at using Stack Scrambler to find bugs in software and devices that inspect packets. Stack Scrambler - Making Packet Omelettes Stack Scrambler is a component that performs stack integrity checking for the Ethernet, IP, TCP, UDP and other stacks of a DUT. It is analogous to the ISIC suite of utilities. During a test, Stack Scrambler sends a stream of mutated packets and includes an ICMP echo request every 100 packets. The ping packets are sent to determine the functional state of the target. When testing a DUT inline, the BreakingPoint box will send pings out on the client interface and receive them on the server interface. When testing a host in endpoint mode (we call this 'one arm' testing), if the target is functioning properly it will respond to our pings with ping response packets. In either mode, we check to make sure that the number of pings sent equals the number of pings received. After the configured test duration, 5 consecutive pings are sent as a final test of the target's functional state. A bug was reported by our excellent QA folks that the number of pings reported by the component did not match the number actually sent during a test. Troubleshooting this is easy - setup a packet capture, run the test, compare the report with what is seen on the wire. Packet Capturing with the BreakingPoint Elite The BreakingPoint Elite has a really cool feature the previous two products do not: a 2GB packet buffer. This packet buffer lets users export up to the last 2GB of the most recently-run test. The packet buffer on the Elite is handled by the FPGAs, which have their own memory for saving packets that are sent and received. This is one feature I am glad we have in the product, and I know that customers are going to get a ton of use from it. Before the Elite, doing packet captures either involved using an external host or using a private, development-only feature of our network processor. Having the packet buffer makes test setup much simpler and completely reliable. You don't have to worry about whether or not your external capture method can keep pace with 40Gbits/sec. [] Accessing the packet buffer in the UI [] Selecting ports and packet direction when exporting the packet buffer. Gathering Data on the Bug I setup a 10 minute test using Stack Scrambler, and left all other parameters at their default. After running the test, I exported a pcap file. In my testing, I did not use a DUT, but instead had the BreakingPoint box running in loopback between two interfaces. In this type of setup, the packets seen on Slot 1/Port 0 will be identical to those on Slot 1/Port 1, so I only exported the packet buffer for the client port. The report for this test run claims 2798 ping packets were sent. [] Wireshark display of the packets from Stack Scrambler I opened the 150k-packet capture file in Wireshark. Since this was a bug about the reported number of ICMP packets, I filtered the list on 'icmp' to get to a total of 1554 ICMP packets, so at this point I've already verified the reported bug. Visually picking out the diagnostic pings is pretty easy - they're a static size, have a static payload, a static ICMP ID field, and a sequential ICMP sequence number. The diagnostic pings also share source and destination IP addresses. In its default configuration, stack scrambler will send fuzzed pings in addition to the diagnostic pings, so I need to filter those out using 'icmp && ip.src==1.1.55.93'. Wireshark now shows 1404 diagnostic ping packets, definitely less than reported. It looks off by about a factor of 2, but not exactly. A quick check shows reported_pings = (diagnostic_pings - final_pings) * 2. Enter the PacketFu So a quick check of a single test shows that it looks like the stats are double counting all the diagnostic pings sent during the test, except the final burst of 5 consecutive pings. This sounds like a reasonable hypothesis. I wanted to run several tests and verify that the reported pings were always wrong as predicted by the formula above, but I wanted to automate the testing. Since Tod Beardsley wrote yet-another pcap library for ruby, I decided I'd put it to use here. I wrote a quick script that parsed the pcap file, counting ping packets if the ICMP ID matches Stack Scrambler's static value 0xDEAD. I really like blog posts with code examples, so here's a simplified version of what I came up with using PacketFu: require 'packetfu' filename = ARGV[0] || exit count = 0 a = PacketFu::Read.f2a(:file = filename) a.each do |p| pkt = PacketFu::Parse(p) if pkt.is_icmp? && pkt.payload[0,2]=="xdexad" count += 1 end end puts "#{count} pings" puts "buggy report should show #{(count-5)*2} packets" Did I mention PacketFu is pretty awesome? It's pretty awesome. So, I wrote a quick TCL script to have the Elite run several tests running for a randomized number of seconds, checking the reported pings for each test. The TCL code looks like this: $bps configure -name {TCL Scrambler Pcap} set ch [$bps getChassis] $ch unreservePort 1 0 $ch unreservePort 1 1 $ch unreservePort 1 2 $ch unreservePort 1 3 $ch reservePort 1 0 $ch reservePort 1 1 set ss [$bps createComponent stackscrambler eggs_benedict] $ss configure -duration.type seconds -duration.value [expr int((rand()*30)) + 1] $ss setDomain client 1 default $ss setDomain server 2 default $bps save -force $bps run set r [$ss result] set pingssent [$r get pingsSent] puts "$pingssent reported pings sent" $ch exportPacketTrace -file scrambler.zip 1 0 both A quick shell script gets the show on the road: for x in 0 1 2 3 4 5 6 7 8 9 ; do echo Iteration ${x} ./scrambler.tcl bpselite elmo elmo unzip scrambler.zip /dev/null mv Slot1Port0.pcap Slot1Port0Iteration${x}.pcap ./icmp.rb Slot1Port0Iteration${x}.pcap done Stack Scrambler Brings The Badness On the first test iteration, Stack Scrambler runs, and I export my pcap file. The ruby script crashes. Saywhat?! The second iteration runs, and that packet capture crashes the ruby script. Every packet capture crashes the ruby script. The crashes look like it's PacketFu. I modified my ruby script in a couple of ways. First, I wrap a ruby begin..rescue block around PacketFu's parse() call; secondly, I save off every packet that causes an exception. We'll come back to the PacketFu-Fail in a moment. After gathering stats from the 10 iterations of Stack Scrambler, I conclude that my hypothesis was correct. Looking at the code, I see that the diagnostic pings sent during the test are counted as both sent and received on both test interfaces, instead of being counted as sent on the client interface and received on the server interface. After a 2-line fix and a checkin, the Stack Scrambler ping reporting bug was fixed. PacketFail Ok, so back to PacketFu. I went and told TodB that his library was broken. I looked at the list of exception-causing packets. They appeared to have at least one thing in common: they were packets with an ethertype field of 0x0800, which is IPv4, but the IP version in the IP header was not 4. I mentioned this finding to Tod, and he's committed a fix to PacketFu to address the issue. Using Stack Scrambler and the BreakingPoint Elite might be a little overkill for testing a new packet parsing library written in ruby, but this example shows how easy it is to make assumptions when parsing network traffic. What if a similar bug existed in your IPS or router? Lately I've been writing a series of posts on the BreakingPoint TCL API. This is the first time I show examples of new API calls that have been added for the BreakingPoint Elite. Next time, I'll be discussing some of the updates in the new API, and how to take advantage of those updates to script testing with the BreakingPoint Elite. []
Les derniers articles du site "BreakingPoint Labs Blog" :
- Data Sheets Lie and How To Truly Measure the Performance and Security of a Network Device - Webcast and Research Paper Mobile Network Traffic Optimization - IPv6 Everywhere You Turn - Dig pcap File For Fun and Productivity - Resiliency. Don't Leave Home Without It - From the Floor at RSA 2010 Real-World Mobile Network Traffic Validation - Replace Vendor Assurances With Measurable Answers - Testing and Validation of Network Security Devices - Application Protocol Fuzzing - Proxies
Menu > Articles de la revue de presse : - l'ensemble [ tous | francophone] - par mots clé [ tous] - par site [ tous] - le tagwall [ voir] - Top bi-hebdo de la revue de presse [ Voir]
Si vous voulez bloquer ce service sur vos fils RSS :
- avec iptables "iptables -A INPUT -s 88.191.75.173 --dport 80 -j DROP"
- avec ipfw et wipfw "ipfw add deny from 88.191.75.173 to any 80"
- Nous contacter par mail
Mini-Tagwall des articles publiés sur SecuObs : | | | | sécurité, exploit, windows, attaque, outil, microsoft, réseau, audit, metasploit, vulnérabilité, système, virus, internet, usbsploit, données, source, linux, protocol, présentation, scanne, réseaux, scanner, bluetooth, conférence, reverse, shell, meterpreter, vista, rootkit, détection, mobile, security, malicieux, engineering, téléphone, paquet, trames, https, noyau, utilisant, intel, wishmaster, google, sysun, libre |
Mini-Tagwall de l'annuaire video : | | | | curit, security, biomet, metasploit, biometric, cking, password, windows, botnet, defcon, tutorial, crypt, xploit, exploit, lockpicking, linux, attack, wireshark, vmware, rootkit, conference, network, shmoocon, backtrack, virus, conficker, elcom, etter, elcomsoft, server, meterpreter, openvpn, ettercap, openbs, iphone, shell, openbsd, iptables, securitytube, deepsec, source, office, systm, openssh, radio |
Mini-Tagwall des articles de la revue de presse : | | | | security, microsoft, windows, hacker, attack, network, vulnerability, google, exploit, malware, internet, remote, iphone, server, inject, patch, apple, twitter, mobile, virus, ebook, facebook, vulnérabilité, crypt, source, linux, password, intel, research, virtual, phish, access, tutorial, trojan, social, privacy, firefox, adobe, overflow, office, cisco, conficker, botnet, pirate, sécurité |
Mini-Tagwall des Tweets de la revue Twitter : | | | | security, linux, botnet, attack, metasploit, cisco, defcon, phish, exploit, google, inject, server, firewall, network, twitter, vmware, windows, microsoft, compliance, vulnerability, python, engineering, source, kernel, crypt, social, overflow, nessus, crack, hacker, virus, iphone, patch, virtual, javascript, malware, conficker, pentest, research, email, password, adobe, apache, proxy, backtrack |
|
|
|
|
|