As a followup to last week’s post on automated protocol analysis, [Tod Beardsley] has written up how to start analyzing a protocol manually. He walks through several examples to show how to pull out the interesting bits in binary protocols. His first step was sending 10 identical select statements and capturing the outbound packets. He used the Ruby library PacketFu to help with the identification. It compared the ten packets and highlighted one byte that was incrementing by four with each packet, probably a counter. Looking at the response indicated a few other bytes that were also incrementing at the same rate, but at different values. Running the same query on two different days turned up what could be a timestamp. Using two different queries helped identify which byte was responsible for the statement length. While you may not find yourself buried in HEX on a daily basis, the post provides good coverage of how to think critically about it.
[I)ruid] from BreakingPoint Labs has been doing quite a bit of protocol reverse engineering as part of his work. He put together a post covering some of the tools that have been useful for this task. Text-based protocols have a lot of human readable characters that can help you identify fields. Binary protocols don’t have this luxury though. He recommends the Protocol Informatics Project for tackling these situations. It applies bioinformatics algorithms to network traffic. You give it a packet dump of the protocol and it compares them to find similarities the same way genetic sequences are compared. It can be confused by protocols that waste a lot of space, but it’s still a very clever approach to reversing.
We’ve been tracking Metasploit commits since Matasano’s premature publication of [Dan Kaminsky]’s DNS cache poisoning flaw on Monday knowing full well that a functional exploit would be coming soon. Only two hours ago [HD Moore] and [I)ruid] added a module to the Metasploit Project that will let anyone test the vulnerability (with comment: “ZOMG. What is this? >:-)“). [HD] told Threat Level that it doesn’t work yet for domains that are already cached by the DNS server, but it will automatically wait for the cached entry to expire and then complete the attack. You can read more about the bailiwicked_host.rb module in CAU’s advisory. For a more detailed description of how the attack works, see this mirror of Matason’s post. You can check if the DNS server you are using is vulnerable by using the tool on [Dan]’s site.