http://www.secuobs.com Observatoire de la securite Internet fr webmaster@secuobs.com 2010-07-31 22:22:23 - Packetstan : Is it a problem if an Intrusion Protection System IPS does not validate TCP checksums If you aren't familiar with the concept of TCP checksums, they're used as a means to ensure that data in the TCP header and TCP payload has not gotten corrupted in transit This is done by taking the one's complement of all 16-bit fields of the TCP header and payload layers and some select fields from the IP header, adding them up, and placing the value in the checksum field of the TCP header A receiving host performs this same calculation If the value that the receiving host calculates matches the one found in the delivered TCP header checksum, the packet is accepted If there is a mismatch, the packet is silently dropped Now, it might be tempting for an IPS solution to skip this validation process to save some time I used to think that the only harm that could come from this was a false positive For instance, let's say that someone sent a TCP segment with an invalid TCP checksum that contains malicious content EVILSTUFF covered by a rule or signature The IPS would alert, but the end host would drop the packet That's annoying but not harmful But, after some consideration, there are some ruses we can use for evasions What if we can fool the IPS into resetting a session by sending a TCP reset with a bad checksum and then sending segments with malicious content In this case, the IPS prematurely terminates the session with the bad reset, but the receiving host keeps the session open to receive the malicious data Let's take a look at how this can be done I'll use Snort to demonstrate the concept by using a default configuration that validates TCP checksums and later one that disables TCP checksum validation I've crafted a session and emulated the client-side of the conversation using Scapy Here is the tcpdump output of the client's part of the session Assume that we have a Snort rule that looks for the content of EVILSTUFF in the payload Segments 1 and 2 are part of the three-way handshake that establishes the session Segment 3 is a bogus reset segment since it has an invalid checksum Segment 4 sends contains half of the malicious content and segment 5 contains the other half When the malicious content is split into two separate segments, the IPS is forced to reassemble the content Finally, we send a valid reset in segment 6 Let's run Snort using the pcap named badchksum-rstpcap that captured both sides of the session created from the Scapy script First, let's use the following configuration that defaults to performing TCP checksums This pertinent portion of the configuration simply uses the default stream5 configuration and contains a single Snort rule that looks for the uricontent of EVILSTUFF in an established session going to destination port 80 This configuration is stored in a file named normalconf Next, we'll run it using the following configuration The only difference is that I've added a configuration option to disable TCP checksum validation This configuration is stored in a file named turnoff-checksumsconf This first run using the default configuration of checksum validation generates an alert snort A console q K none c normalconf r badchksum-rstpcap 07 04-21 56 59145909 1 123435 0 EVILSTUFF Priority 0 TCP 1921681100 18484 - 1921681199 80 However, the second run fails to alert using the configuration where TCP checksum validation has been disabled snort A console q K none c turnoff-checksumsconf r badchksum-rstpcap This demonstrates that it is fairly easy to evade an IPS that fails to perform TCP checksum validation There are several more tricks that can cause IPS evasions when TCP checksums are not validated I'll demonstrate one or more in upcoming posts If you're interested in learning packet crafting such as the session I created for this experiment, I'm teaching a one-day SANS Scapy course at SANS Network Security at 2010 in Las Vegas in September I still have no students signed up for the course and I'm getting desperate I've got 6 copies of the book I co-authored with Stephen Northcutt Network Intrusion Detection An Analyst's Handbook sitting in a box in my basement gathering cricket legs If you are one of the first six students to sign up and actually show up, I'll give you one of these copies free cricket legs and all And, I'll even sign it for you if you'd like if you feel it won't devalue it Just tweet me - judy_novak - to let me know you've signed up http://www.secuobs.com/revue/news/245684.shtmlhttp://www.secuobs.com/revue/news/245684.shtml Secuobs.com : 2010-07-15 01:21:06 - Packetstan - Back in my Sourcefire days, I did a lot of research on TCP timestamp behavior In a nutshell, TCP timestamps can be included as a TCP option to specify the sending host's timestamp and echo the most recently received timestamp from the other side of the connection The notion of time or timestamp is not the typical one since it denotes, for most operating systems except OpenBSD, a representation of the uptime of the host since the last reboot My interest was understanding how general and operating-specific timestamp behavior might evade notice by an intrusion detection or prevention system In general, a host that receives a TCP segment with a TCP timestamp must compare the current timestamp in the segment with what it considers the previous timestamp If the timestamp is equal or greater than the previous one, it is acceptable Otherwise, the segment should not be acknowledged There are many different nuances involved in this process including how to deal with out-of-order segments If you'd like to read way more than you'd ever consider interesting about all the nuances of TCP timestamps, take a look at the paper that Steve Sturges and I wrote Target-Based TCP Timestamp Stream Reassembly I discovered some very unusual behavior with Linux 24 kernels where a timestamp of one less than the previous one was actually accepted Not only that, when the acknowledgement of that segment was returned,the echoed timestamp was one more than it should have been I've crafted the client side of the conversation using my favorite tool Scapy and am displaying the tcpdump output from some sessions Speaking of Scapy Warning Shameless Marketing I'm teaching a SANS class Power Packet Crafting Using Scapy at SANS Network Security 2010 in Las Vegas on September 26 Contrary to the popular belief - what your learn and craft in Vegas, doesn't have to stay in Vegas I've currently got 0, count 'em - 0, students signed up and I'm feeling awfully unloved and lonely So, please consider attending this course, since this is probably my last shot at teaching it unless the numbers improve I know, I know it's awfully unbecoming to have to beg and grovel, but it's all I have left End Shameless Marketing Take a look first at how a receiving Windows Vista host IP 101353 properly handles an old timestamp Record 1 I craft the client SYN to have an initial timestamp value of 100 Record 2 The server responds and echoes the client's timestamp value of 100 after it's own timestamp value Record 4 I send the data GET indexhtml in relative bytes 1 17 with a good timestamp value of 100 Record 5 The server acknowledges the data with ack 17 and echoes the good timestamp value of 100 Record 6 I attempt to send the rest of the HTTP GET request of HTTP 10 r n r n in relative bytes 17 29 with a one-less-than-acceptable timestamp value of 99 Record 7 The server predictably issues a duplicate acknowledgement with ack 17 indicating it did not accept the previous segment It echoes the rejected timestamp value of 99 Now, take a look at how a receiving Linux 26 kernel host IP 101335 improperly handles an old timestamp The session is identical to the Windows Vista one until Record 7 Record 7 The Linux server erroneously accepts the one-less-than-acceptable timestamp value of 99 and acknowledges the data sent in Record 6 with ack 29 As well, it echoes a timestamp value of 100 instead of 99 You're probably thinking to yourself Who cares - no wonder no one wants to attend your Scapy class - you're long-winded and tiresome and you probably went to band camp as a kid Wait a second, though What if an IDS IPS is not aware of this bizarre behavior Say, for instance, that GET EVILSTUFF in a payload represents suprisingly enough - something malicious And, say you have a rule that looks for this content in a URL Further, suppose we divide this into two segments in our crafted session and place GET EVIL in one segment with a timestamp of 100 and STUFF HTTP 10 r n r n in the next segment with a timestamp of 99 This forces the IDS IPS to reassemble the two segments Now, if the receiver is a Linux host, it will accept this content and perhaps something evil will happen If you have a TCP timestamp-aware IDS IPS, it is possible that it will discard the segment with a timestamp of 99 After all - it is invalid However, if you have a target-based IDS IPS such as Snort, it can be configured to use a stream5 reassembly policy of linux for host 101335 and it will alert on the rule Once again, this demonstrates the merits of having an IDS IPS, such as Snort, that is aware of operating system specific behaviors and is adept at handling them And again, this demonstrates what a complex protocol TCP is, the nuances for receiving host and IDS IPS interpretation, the the wealth of possibilities for TCP evasions http://www.secuobs.com/revue/news/240659.shtmlhttp://www.secuobs.com/revue/news/240659.shtml Secuobs.com : 2010-07-10 06:02:49 - Packetstan - Introduction In part 1 of this series evaluating the FaceTime protocol, we established that the FaceTime network traffic exchange looks like this Unknown TCP protocol starts the conversation TCP 5223 Unknown UDP traffic between the iPhone and two hosts with similar IP addresses UDP 16385 and UDP 16386 Certificate validation through an Akamai server HTTP HTTPS request to an Apple server STUN traffic for NAT traversal SIP traffic for call setup, negotiation and authentication UDP stream data for video audio RTP streaming H264 with AAC audio In part 2 we looked at the SIP and RTP traffic in more depth, identifying what I believe is a proprietary authentication protocol in the SIP MESSAGE verb and H264 and AAC audio data in an RTP stream, extracting that data with videosnarf Jason Ostrom, one of the authors of videosnarf has even indicated that they plan to work on getting video extraction working so we can record and play-back FaceTime calls In this installment of the series we ll look at the unknown protocol that starts the FaceTime conversation over TCP 5223 Traffic Analysis Wireshark does a great job evaluating a packet capture and applying heuristics or standard port designations when applying packet dissectors Sadly, the FaceTime traffic over TCP 5223 is not interpreted any further than the TCP layer, as shown below due to some lost traffic during my 888-Facetime packet capture, I ve switched to a different capture which was more complete 888-facetime-tcp5442-wireshark-default We ll have to apply our own creativity to evaluate this traffic further First, Wireshark s wonderful TCP stream reassembly feature gives us the ability to view the TCP exchange in a hexadecimal view, with the option to save the data in binary format Raw , ASCII, hex-dump or even C Arrays great for taking data and dumping it into a C tool for manipulation, or otherwise modifying it to work with Python or other popular languages 888-facetime-tcp5442-stream-reassembly Although obviously a binary protocol eg non-ASCII based we can see plaintext strings that look similar to certificate content This is a common characteristic of SSL-based protocols, though Wireshark wasn t able to identify this automatically Fortunately, Wireshark is also an extremely flexible tool with a little know-how Using the Analyze Decode As feature, we can tell Wireshark to treat this traffic as SSL-encrypted to gather a bit more information from the protocol First, select one of the packets of the exchange that you want to decode using an alternate protocol and click Analyze Decode As From the Wireshark Decode As menu, select the Transport tab Specify that both ports should be decoded as SSL, as shown below 888-facetime-wireshark-tcp5442-decode-as-dialog Clicking Apply will cause Wireshark to reload the capture data, applying the SSL decoder to the specified port pair, as shown 888-facetime-wireshark-tcp5442-ssl-decode One of the great features of the Wireshark SSL dissector is that it will do stream reassembly for us, giving us the option to extract data even if it is transmitted across multiple TCP segments For example, in the screen-shot above I ve selected the certificate information, highlighting the bytes in the hex view below For any highlighted data in Wireshark, we can export it to a binary file by selecting File Export Selected Packet Bytes In the Export Raw Data dialog, save the data with the filename extension der to allow Windows to open it as a certificate 888-facetime-wireshark-tcp5442-export-selected-packet-bytes-cert1 Double-clicking on the file with the der or cer extension will open the certificate viewer We can navigate the certificate details to gather some additional information about the server service 888-facetime-tcp5442-cert-general 888-facetime-tcp5442-cert-detail-keyusage 888-facetime-tcp5442-cert-detail-eku-client server_auth A few points of interest from this certificate Issued to courierpushapplecom by Entrust on April 13, 2010 Key use is for Digital Signatures and Key Encipherment eg key encryption Enhanced Key Usage indicates that it is valid for Server and Client authentication eg mutual authentication Other certificates are also delivered through this exchange, including the root certificate for Entrust A Gentle Tap Curiosity getting the better of me, I decided to give the Apple server at 17149376 a gentle tap to find out more about the authentication requirements here One of my favorite tools is openssl , the binary that ships with the OpenSSL suite We can use this tool to connect to SSL services, extracting debug information as shown openssl s_client -msg -connect 17149376 5223 grep -v CONNECTED 00000003 SSL 20 length 008c , CLIENT-HELLO TLS 10 Handshake length 0007 , Certificate TLS 10 Handshake length 0086 , ClientKeyExchange TLS 10 ChangeCipherSpec length 0001 TLS 10 Handshake length 0010 , Finished is from my system to the Apple server, is from the Apple server to my client First, my system attempts to do a SSL 20 negotiation sending a CLIENT-HELLO message Apple s server responds with a TLS 10 ServerHello response, followed by the certificate information such as we saw earlier Following this delivery, Apple s server sends a CertificateRequest to my client My client sends an empty certificate response as indicated with a length of 7 bytes and tries to complete the ClientKeyExchange without the use a client-side certificate The Apple server rejects this with a fatal handshake_failure and terminates the connection From this exchange we can see that this TLS protocol uses mutual certificate authentication a certificate on the Apple server from Entrust and a certificate on the iPhone to complete the exchange This is interesting since Apple has stated that FaceTime will be an open protocol, but will apparently require a client-side certificate to connect to the Apple server, which gives them a grant deny option for all connections on a per-device basis Steve Papa Esteban is no dummy here s looking at you, Android users Client-Side Certificate Returning to the Wireshark capture decoding SSL traffic over TCP 5223, we can extract the client certificate sent from the iPhone to the Apple server using the technique detailed above 888-facetime-tcp5442-cert-client-issuer 888-facetime-tcp5442-cert-client-subject 888-facetime-tcp5442-cert-client-keyusage More interesting observations are now possible The iPhone client certificate is issued by the Apple iPhone Device CA The iPhone client certificate common name CN is a GUID, likely generated at the factory Key constraints are for authenticating the iPhone as a device entity Key usage is similar to the Apple Server certificate, intended for digital signatures and key encipherment I Probably Should Have Started Here I probably should have started here, but it would have been much less fun The Apple well-known TCP and UDP ports list used by Apple products indicates that TCP 5223 is used for XMPP over SSL XMPP is the Extensible Messaging and Presence Protocol, the formal name for Jabber Apple indicates that TCP 5223 is used for authentication in unencrypted Jabber conversations, as well as for authentication and data exchange for SSL-protected Jabber sessions From this analysis, we can determine that FaceTime uses XMPP to authenticate and establish a connection to an Apple Jabber server Although I don t have a packet capture for the remote session, I imagine that some kind of GSM message is sent from the initiating device to the responding device to have both devices join the Jabber server, authenticate and exchange data that initiates the FaceTime conversation including the subsequent SIP exchange Due to the use of certificate-based mutual authentication, it s unlikely that anyone will be sufficiently reproducing the FaceTime protocol on another device without Apple s assistance for certificate issuance Evil Thinking For Future Evil I ll leave you with a final thought to consider for future evildoing The private portion of the certificate used for XMPP authentication by the iPhone is stored on the iPhone device unless the iPhone uses a TPM, it is probably stored somewhere on the file system If you were to jailbreak your iPhone 4g and extract that certificate, you could likely use a standard Jabber client to connect to the Apple Jabber server and monitor the activity there, including the connections on who is joining and leaving the network Maybe even setup a Jabber Bot and automate your evil manipulation of Apple s server There s someone knocking very loudly at my door, so that s it for me today Next time we ll catch up on the HTTPS traffic and more FaceTime analysis fun -Josh http://www.secuobs.com/revue/news/239349.shtmlhttp://www.secuobs.com/revue/news/239349.shtml Secuobs.com : 2010-07-08 08:34:52 - Packetstan - Introduction In part 1 of this series we looked at the protocols involved in a Facetime call The basic outline of the Facetime network exchange is as follows Unknown TCP protocol starts the conversation TCP 5223 Unknown UDP traffic between the iPhone and two hosts with similar IP addresses UDP 59007 Certificate validation through an Akamai server HTTP HTTPS request to an Apple server STUN traffic for NAT traversal SIP traffic for call setup and negotiation UDP stream data for video audio In this installmemt of the series we'll look at the last two components SIP and the UDP stream information Examining SIP SIP is the Session Initiation Protocol, used for controlling the setup and establishment of audio and video calls over TCP or UDP As a text-based protocol, it looks a lot like HTTP verbs like INVITE and BYE and numeric response codes , with a little SMTP love thrown in there as well IMAGE Wireshark does a great job of identifying SIP traffic, even on non-standard ports While SIP is typically done over port 5060 or 5061 for SIP over TLS , Facetime is using UDP 16402 Wireshark gives us a summary of SIP activity in the packet capture by selecting the Telephony SIP option, as shown Of interesting note here is the lack of the SIP request method REGISTER, which would be used with digest authentication to authenticate the device This isn't a statement of vulnerability, but it indicates that Apple is not using the standard SIP authentication method, instead relying on an alternate exchange to authenticate the devices Also interesting here is the use of the SIP MESSAGE verb According to RFC3428, the MESSAGE verb is used for instant messaging as part of the SIP exchange Otherwise, the SIP exchange is straightforward, as follows INVITE from the initiator to the responder ACK from the responder Several MESSAGE frames back and forth After a few minutes the duration of the video call , a BYE from the responder to terminate the session The SIP exchange is shown in Wireshark packet list form below IMAGE A few IP addresses worth clarifying here 1710928227 The remote iPhone from Apple's 888-Facetime service 172160114 My iPhone's IP address on my open WiFi network 689119102 My NAT address from my ISP, previously negotiated with STUN In the packet list we see that Apple is using user address port for the SIP address URI Looking at the detail of the INVITE frame we can gather additional detail First we'll look at the message header content content has been omitted to protect the privacy of the remote caller IMAGE More interesting stuff here The Display component in the To and From fields reveals the cell phone number of both parties In the first To field shown, my cell phone number is listed 4015242911 followed by an unknown 570 This is interesting since the 888-Facetime caller's phone number was blocked from my phone display, but accessible to me from a packet capture The User-Agent of the 888-Facetime caller is Viceroy 14 GK , which is similar to the User-Agent used by the iChat video client Viceroy 13 , or 12 in older iChat clients Looking at the message body detail reveals more details about the session IMAGE The message body details the Session Description Protocol SDP content, including the SDP session owner as GKVoiceChatService which is documented in Apple's iPhone SDK We can also see the Real Time Control Protocol RTCP negotiated for UDP 16402, as well as multiple negotiated media attributes, essentially reduced to AAC for audio and X-H264 for video Later in the SIP exchange, we see several of the MESSAGE verbs Although intended for use in instant messaging applications, the MESSAGE verb is used by Facetime to exchange arbitrary data between the two iPhone devices The MESSAGE verb payload data repeats the User-Agent Viceroy 14 GK information, then includes the message Content-Type application ske , similar to a HTTP exchange Following this tag we have a Content-Length tag and SKESeq 1 0 for the first of the 4 MESSAGE verbs Each subsequent MESSAGE verb also includes this content, changing the numeric identifier 1 for the successive packets eg SKESeq 2 0 , SKESeq 3 0 and SKESeq 4 0 We can apply the display filter sipRequest-Line contains MESSAGE to focus the Wireshark display on these MESSAGE frames, as shown below IMAGE A quick Google search doesn't turn up anything about the SKE protocol, though I'll speculate here that it is some kind of authentication negotiation mechanism A summary of the 4 payloads following the SKESeq header is as follows SKESeq 1 A large-ish payload commonly around 785 bytes which appears to include certificate-looking information SKESeq 2 Always 4 bytes of payload 61 f4 27 9f in one capture SKESeq 3 A consistent payload length of 170 bytes, no significant ASCII strings SKESeq 4 Always 4 bytes of payload 53 a0 8e a3 in one capture This data requires further analysis, possibly representing a proprietary authentication protocol used by Facetime through SIP MESSAGE verbs I'll devote further analysis to a later article so we can move on to the good stuff Data Streams Following the SIP exchange we see a RTP exchange over UDP 16402 with a reflexive source port To evaluate this stream we'll turn to the videosnarf tool by Arjun Sambamoorthy and Jason Ostrom Videosnarf and the parent tool ucsniff are really impressive, and Jason and Arjun are really cool guys as well Videosnarf can read from a libpcap file, but the current version of the tool does not properly accommodate wireless packet capture link types other than native 80211 eg it cannot interpret PPI or Radiotap headers , with the following error videosnarf -i 4g-inbound-888FACETIME-session-1pcap Starting videosnarf 063 Starting to snarf the media packets Please wait while decoding pcap file - Invalid IP header length 0 bytes - Invalid IP header length 0 bytes omitted - No RTP media stream found Snarfing Completed My packet capture uses the PPI header, so I added support to handle this link type with videosnarf Download and apply the patch as shown against videosnarf 063, future versions will hopefully integrate this functionality and not require patching cd videosnarf-063 wget -q http wwwwillhackforsushicom code videosnarf-wifi-ppiheaderdiff patch -p1 patching file src videosnarfc patching file src videosnarfh configure make make install Once videosnarf includes the ability to read from wireless packet captures with the PPI header, we can run it against the packet capture again videosnarf -i 4g-inbound-888FACETIME-session-1pcap Starting videosnarf 063 Starting to snarf the media packets Please wait while decoding pcap file - Invalid IP header length 16 bytes omitted Protocol Unsupported - Invalid IP header length 16 bytes - Invalid IP header length 16 bytes Stream saved to file H264-media-1264 Stream saved to file H264-media-2264 Stream saved to file H264-media-3264 Stream saved to file H264-media-4264 Number of streams found are 4 Snarfing Completed ls -l H264-media- -rw-r--r-- 1 root root  413160 Jul  5 18 24 H264-media-1264 -rw-r--r-- 1 root root  272459 Jul  5 18 24 H264-media-2264 -rw-r--r-- 1 root root 3765017 Jul  5 18 24 H264-media-3264 -rw-r--r-- 1 root root 1761492 Jul  5 18 24 H264-media-4264 Videosnarf was able to extract four H264 data streams, saving them to files We can quickly evaluate the contents of the files to determine if the content itself is encrypted using the ent tool ent H264-media-3264 Entropy 4509034 bits per byte Optimum compression would reduce the size of this 3765017 byte file by 43 percent Chi square distribution for 3765017 samples is 29883052755, and randomly would exceed this value 001 percent of the times Arithmetic mean value of data bytes is 558586 1275 random Monte Carlo value for Pi is 3626079279 error 1542 percent Serial correlation coefficient is 0622531 totally uncorrelated 00 Ent applies several tests to evaluate the entropy and randomness of a given file In this example, entropy is fairly low at 45 bits per byte Compare this to a data stream collected from the Linux dev urandom device dd if dev urandom of rand bs 4096 count 1000 1000 0 records in 1000 0 records out 4096000 bytes 41 MB copied, 164117 s, 25 MB s ent rand Entropy 7999961 bits per byte Optimum compression would reduce the size of this 4096000 byte file by 0 percent Chi square distribution for 4096000 samples is 22401, and randomly would exceed this value 9000 percent of the times Arithmetic mean value of data bytes is 1275652 1275 random Monte Carlo value for Pi is 3142760882 error 004 percent Serial correlation coefficient is 0000133 totally uncorrelated 00 Or an encrypted file of all 0's dd if dev zero of zero bs 4096 count 1000 1000 0 records in 1000 0 records out 4096000 bytes 41 MB copied, 00211891 s, 193 MB s openssl enc -aes-128-cfb -in zero -out zeroenc enter aes-128-cfb encryption password Verifying - enter aes-128-cfb encryption password ent zeroenc Entropy 7999947 bits per byte Optimum compression would reduce the size of this 4096016 byte file by 0 percent Chi square distribution for 4096016 samples is 30032, and randomly would exceed this value 500 percent of the times Arithmetic mean value of data bytes is 1274714 1275 random Monte Carlo value for Pi is 3137092793 error 014 percent Serial correlation coefficient is 0000067 totally uncorrelated 00 Clearly the output from the Facetime video stream as extracted by videosnarf is not encrypted Sadly, it does not appear that the extracted data is viable to play with mplayer mplayer H264-media-3264 -fps 17 MPlayer 10rc2-432 C 2000-2007 MPlayer Team CPU Intel R Core TM 2 Duo CPU L7100 120GHz Family 6, Model 15, Step ping 11 CPUflags MMX 1 MMX2 1 3DNow 0 3DNow2 0 SSE 1 SSE2 1 Compiled with runtime CPU detection mplayer could not connect to socket mplayer No such file or directory Failed to open LIRC support You will not be able to use your remote control Playing H264-media-3264 H264-ES file format detected xscreensaver_disable Could not find XScreenSaver window Opening video decoder ffmpeg FFmpeg's libavcodec codec family Selected video codec ffh264 vfm ffmpeg FFmpeg H264 Audio no sound FPS forced to be 17000 ftime 0059 Starting playback h264 0x896a290 illegal POC type 5 h264 0x896a290 sps_id out of range h264 0x896a290 sps_id out of range omitted h264 0x896a290 decode_slice_header error h264 0x896a290 concealing 12 DC, 12 AC, 12 MV errors MPlayer interrupted by signal 11 in module decode_video - MPlayer crashed by bad usage of CPU FPU RAM Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly Details in DOCS HTML en bugreports_whathtml bugreports_crash - MPlayer crashed This shouldn't happen It appears the reconstructed file is close to a H264 file, but has some errors preventing it from being played back This is still positive from an attack perspective though, since we know the content is not encrypted hopefully the videosnarf developers will release an updated version soon that can address any problems with reconstructing and saving the H264 stream Summary Let's summarize what we learned today While Facetime uses SIP, it does not use the standard authentication mechanisms Phone number information is disclosed in the SIP exchange, even if it is blocked on the phone itself Facetime uses the SIP MESSAGE verb for passing arbitrary data between iPhone devices involved in a Facetime call This could be a proprietary authentication mechanism Videosnarf with a minor patch can extract video and audio stream data The video and audio content of a Facetime conversation are NOT encrypted, leaving them susceptible to eavesdropping attacks if the underlying WLAN infrastructure is weak or otherwise compromised Mplayer is unable to play back this stream data today hopefully fixes can be applied by the videosnarf team to resolve this in the future Next time we'll spend some time looking at the initial TCP exchange between the iPhone 4g and the authorization process that initiates the connection Comments and questions are welcome, thanks -Josh http://www.secuobs.com/revue/news/238592.shtmlhttp://www.secuobs.com/revue/news/238592.shtml Secuobs.com : 2010-07-07 07:21:13 - Packetstan - Facetime Introduction With the iPhone 4g, video chat through Facetime is a reality in a mobile device As a frequent traveler, I use Skype on my laptop or netbook to stay in touch with family and friends, but it usually requires some planning and coordination With Facetime, we can initiate a voice call over the cellular network, then switch to video on demand, when WiFi service is also available which hopefully not be a requirement in the future As a packet junkie, I find the concept of Facetime very interesting The intended usage for Facetime, as described by Esteban, is for a user to place a call over the cellular network with the freedom to switch to video, then back and forth as desired Focusing on the network protocol components, there are several interesting challenges Device capabilities negotiation and call setup over WiFi Video content streaming between devices Authorization to accept the video stream by recipient NAT traversal for users behind a WiFi NAT interface Binding between GSM and WiFi traffic to mitigate spoofing attacks Knowing this, a lot of interesting questions come to mind How is the management and streaming traffic protected How is the call authorized by the end-user What can we deduce by sniffing the WiFi-side of a Facetime transaction In this multi-part series, we'll look at how the Facetime protocol works, answering these and other questions while looking at tools and techniques for network protocol analysis It's my hope that you'll learn about the Facetime protocol by reading this series, and furthermore, be able to apply these techniques to other protocols as well High-Level Assessment To assess the protocol, I've taken several packet captures from my unencrypted wireless network, c alling 888-Facetime Apple's service for customers to try out Facetime and a colleague at the SANS Institute Most of the analysis will be on the call to 888-Facetime, though I'll introduce other packet captures as needed The Facetime call with 888-Facetime was initiated by Apple's representative, which I'll herein refer to as an inbound session, due to the differences in Facetime calls in the role of initiator or responder The details of my iPhone 4g are as follows iOS Version 40 8A293 IP Ad dress 5c 59 48 02 8a 65 MAC Address 172160114 My AP was running in 80211b mode for simplifying the packet capture process , also acting as a NAT at 1721601 Loading up the packet capture in Wireshark, I applied a display filter to include traffic only from or to my address ipaddr eq 172160114 Using Wireshark's Protoco l Hierarchy summary Statistics Protocol Hierarchy , we can get a quick look at all the protocols in this 28,034 packet capture file, as shown Besides the low-layer protocols, we can see different activity here UDP DNS traffic to be expected Session Traversal Utilities for NAT STUN Session Initiation Protocol SIP Lots of unrecognized UDP data packets HTTP traffic transmitting XML data HTTPS traffic Unrecognized TCP traffic ICMP Wireshark doesn't give us the option to sort this traffic view by time, but we can switch to the Conversations view Statistics Conversations to view time-relative data by protocol, as shown TCP first, then UDP We can see a few nodes are involved here Address Name Note 1714936103 No DNS Name Apple, Inc system in the 17 8 netblock 7221522443 initessapplecomedgesuitenet An Akamai server, a239da1akamainet 199752190 crlverisignnet Verisign's CRL server 17155414 No DNS Name Apple, Inc system in the 17 8 netblock 171555251 No DNS Name Apple, Inc system in the 17 8 netblock 171555252 No DNS Name Apple, Inc system in the 17 8 netblock 681052811 cdns1coxnet My ISP's DNS server 1710928227 No DNS Name Apple, Inc system in the 17 8 netblock Using the timing and address information, we can construct a timeline of what happens in this session Step Nodes Description 1 172160114 - 1714936103 The iPhone 4g initiates a TCP session to the remote host over TCP 5223 Wireshark does not have a dissector for this protocol, though it believes the port number is associated with the HP Virtual Group protocol 2 172160114 - 171555251 Several UDP connections from the iPhone 4g to Apple's server over UDP 59007 3 172160114 - 171555252 More UDP traffic to a host with the next 4th octet over UDP 59007 4 172160114 - 7221522443 HTTP traffic to the Akamai server over XML, retrieving certificate information from Apple's servers 5 172160114 - 17155414 HTTPS traffic to an Apple server 6 172160114 - 1710928227 UDP STUN traffic to an Apple server for NAT traversal 7 1710928227 - 172160114 UDP SIP traffic from Apple revealing phone numbers, among other details 8 17155514 - 172160114 UDP traffic over port 16402 making up the majority of the packet capture data, this is likely the video stream information which continues until a SIP BYE message is observed Summary Based on this analysis we can determine several critical pieces of how Facetime works Unknown TCP protocol starts the conversation, likely initiated following an event that starts on the GSM network Unknown UDP traffic between two hosts with similar IP addresses Certificate validation through an Akamai server, followed by an HTTPS request to an Apple server STUN traffic for NAT traversal SIP traffic for call setup and negotiation UDP stream data for video audio In the next part of this series,we'll spend some more time look at the SIP and video audio streaming traffic and look at some tools we can use to extract that data Stay tuned -Josh http://www.secuobs.com/revue/news/238249.shtmlhttp://www.secuobs.com/revue/news/238249.shtml Secuobs.com : 2010-06-26 00:10:53 - Packetstan - It's ironic that I'm writing about fitting in since I never have in my entire life And while I've been a social misfit, I'm now talking about misfit crafted packets specifically TCP This pertains to packets that you craft and that you may observe entering a network near and dear to you There are certain basic characteristics or behaviors that are expected of well-formed TCP packets And, that is what this blog is about First things first let's say you want to craft a well-formed SYN packet The best model for emulation is the SYN of the operating system that you're attempting to emulate the range of source ports it tends to use, the TCP window size, the IP TTL, IP identification number, IP flags, etc as well as a randomized 32-bit sequence number Those fields and value are pretty obvious and well covered in literature so I won't bother to discuss them, but some crafters I've seen forget about the TCP options Every packet with the SYN flag set either a SYN or SYN ACK packet should have the Maximum Segment Size set Sure, it's possible to craft a SYN or SYN ACK without the MSS option and have the receiver accept it, but it stands out to the trained eye or astute filters looking at the session or traffic in aggregate If you want to remain stealthy, you'll include the MSS option There needs to be a value associated with it and that is typically 1460 for an Ethernet network If you ever see a packet flying by on your network that has a SYN flag set and does not have a TCP options Maximum Segment Size MSS you can be fairly certain that it was crafted And, if it was crafted it probably is for some nefarious purposes There are other TCP options too that can be included, but most current well-known TCP IP stacks list the MSS as the first of the TCP options in the TCP header However, Solaris stacks do not follow this convention and may present some false positives if you include this check How would you find SYN packets with no MSS flag It's not that easy using some of the common tools Snort cannot discover this with its rule language since it doesn't permit you to examine the TCP header options and the offset keyword pertains to the payload portion of the packet not the TCP header Tcpdump is not much help unless you assume that the MSS option must be the first It has a value of 0x02 and it must be found in the 20th byte offset of the TCP header of any SYN segment The tcpdump filter to discover such a segment would be tcp 13 2 0 and tcp 12 16 5 or tcp 12 16 5 and tcp 20 02 'tcp 13 2 0' looks for the SYN flag set 'tcp 12 16 5' looks for a TCP header length of 5 This is fairly convoluted because the value for the TCP header length is found in the high-order nibble so we must first divide by 16 to make it more logical at least for me Now, a TCP header length of 5 32-bit words means a conventional 20-byte TCP header with no options There can still be TCP options, yet no MSS The rest of the and clause examines that by finding TCP options where the TCP header length is greater than 5, and assumes that the MSS value appears first in the 20th byte offset of the TCP header with a value of 02 Wireshark is the best tool for finding such traffic using its display filter of tcpoptionsmss tcpflagssyn 1 That finds any packet where the TCP options MSS flag is NOT set, but the segment has the SYN flag set As you can see in the Wireshark capture that follows, the displayed segment was a SYN flag and TCP options of SACK permitted , Timestamps , and Window scale , yet no MSS Once the MSS is set on the SYN or SYN ACK, it should not appear in any other segment This is true of two other TCP options the window scale, and the Selective Acknowledgment acceptable If any of these three options appears on a non-SYN segment, it is surely crafted Again, Wireshark can expose these bogus packets using a display filter of tcpflagssyn 0 tcpoptionsmss tcpoptionswscale tcpoptionssack The following Wireshark capture displays some of nmap OS fingerprinting packets that are exposed with the above display filter The specific packet that is displayed has the FIN, PUSH, and URG flags set along with the window scale, MSS, and timestamp set Another unusual condition that may be a reflection of a crafted packet or a poorly written TCP IP stack is where a client SYN packet has a non-zero acknowledgement value After all, the client has received nothing to acknowledge The tcpdump filter to discover such packets is tcp 13 2 and tcp 8 4 0 The following Wireshark display filter exposes these packets tcpflagssyn 1 tcpflagsack 0 tcp 8 4 0 The nmap OS fingerprinting scan creates some of segment with these characteristics as shown in the following Wireshark output When I've crafted packets, it is typically in a research environment and I'm not worried about the traffic being uncovered As I've mentioned before, I use Scapy to craft my packets and the easiest way to close a session is to use a one packet reset However, if I were trying to fit in, I'd go through the trouble of crafting the 4-way graceful FIN close so as not to attract notice That's about it for fitting in http://www.secuobs.com/revue/news/235213.shtmlhttp://www.secuobs.com/revue/news/235213.shtml Secuobs.com : 2010-06-25 02:30:28 - Packetstan - Ladies and Gentlemen, welcome to Packetstan To begin, let me explain the origin of our sites name A few years ago I was at a client trying to explain how an ISP in Pakistan took down most of YouTube Every time I mentioned the country of Pakistan, I would mispronounce it as Packetstan At the end of the meeting, I ran out and registered the domain The goals of this blog is to have a public outlet to publish research, reviews and analysis as they relate to packets I have enlisted a few of my friends and Gurus to share their packet kung fu with the community This site is about fun, exploration, and learning We will be publishing Packet captures Packet analysis Tools Reviews of tools Tutorials Book paper reviews Rants - On Monday, June 14, 2010, we will be releasing Packetrix, a Linux distro dedicated to packet exploration We will of course be announcing it here, and on Twitter If you have any ideas for content, please let us know Thanks http://www.secuobs.com/revue/news/234881.shtmlhttp://www.secuobs.com/revue/news/234881.shtml Secuobs.com : 2010-06-25 02:30:28 - Packetstan - Recently, I've been on a campaign to make people aware of TCP evasions of IDS IPS solutions Suppose that you could find a way to make an IDS IPS believe that a TCP session has closed when it really hasn't After you dupe the IDS IPS into no longer tracking the session, you send your exploit and it goes undetected Sound difficult Well, it really is not There are a lot of nuances when dealing with a protocol as complex as TCP And, many of these nuances are different interpretations made by different OS software For instance, if you have wholly overlapping TCP seqments where both segments begin on the same sequence number and end on identical sequence numbers, but the payload is different which segment does the destination OS favor and just as important - does the IDS IPS make the same choice I've got an interesting issue I found when doing research at Sourcefire years ago This is a nuance that may not occur with all operating systems, but occurs when Linux runs on the destination host And, it involves a RESET that appears to close the session, but really doesn't First let's take a look at some tcpdump output where I'm crafting the client side of the connection using a wonderful packet crafting tool called Scapy that uses the Python interpreter The packets I crafted are in yellow I'll cover how I crafted the session using Scapy in an upcoming blog The three-way handshake starts on packet 1 where I craft the SYN The server responds with the conventional SYN ACK in packet 2 And, then in packet 3, I accidentally ACK the server with a value one more than the expected value It isn't obvious, but the relative value ack 2 in tcpdump parlance should have been ack 1 if I got it right Now, here's where the bizarre stuff happens In packet 4, the server resets the connection because of the invalid ack number Fair enough But, in packet 5, I send 10 bytes of data GET EVIL and I assign a correct acknowledgement number as tcpdump indicates with ack 1 Now look at the server's response in packet 6 It acknowledges the 10 bytes of data How is that possible - didn't it reset the connection And, in packet 7, I send more data and the server acknowledges this in packet 8 1 101378204 10134580 Flags S , seq 10, win 8192 2 10134580 101378204 Flags S , seq 3506022755, ack 11, win 5840, options mss 1460 3 101378204 10134580 Flags , ack 2, win 8192 4 10134580 101378204 Flags R , seq 3506022757, win 0 5 101378204 10134580 Flags P , seq 1 10, ack 1, win 8192 GET EVIL 6 10134580 101378204 Flags , ack 10, win 5840 7 101378204 10134580 Flags P , seq 10 51, ack 1, win 8192 STUFF HTTP 11 r nHost wwwwhatevercom r n r n 8 10134580 101378204 Flags , ack 51, win 5840 9 101378204 10134580 Flags R , seq 51, ack 1, win 8192 You're probably thinking what's going on Before I explain what I believe occurred, let's look at the implications of what just happened You'd think that when an IDS IPS saw the reset, it would stop tracking the session And, let's say that the string EVILSTUFF represents, well - evil stuff It's in two separate segments requiring reassembly so it's fairly safe to say most IDS IPS solutions would miss this Okay, as for the explanation My thought is that the server considered the third packet with the bad acknowledgement number a foreign or rogue segment It did not consider it a valid segment of the forming session establishment If that doesn't make sense, what happens if you try to send a PUSH packet with data to a session that hasn't been established The server resets it And, I believe that since this was not yet an established session, the server considered the segment with an invalid ACK number as foreign to any session it knew This highlights a couple of things First, it's not hard to cause TCP evasions for an IDS IPS And second, there are issues that affect specific operating systems only Servers on other operating systems than Linux that receive the bad client acknowledgement number may continue to send the SYN ACK until a valid one arrives It is extremely difficult for an IDS IPS solution to have knowledge of all these OS-specific TCP issues and deal with them properly And, that is why TCP evasions are possible http://www.secuobs.com/revue/news/234880.shtmlhttp://www.secuobs.com/revue/news/234880.shtml Secuobs.com : 2010-06-25 02:30:28 - Packetstan - As promised, here is the Scapy code Let me be perfectly transparent by saying that I have several reasons for my posts on this blog First, I think Scapy is amazing and I want to encourage you to use it Second, I've created a SANS course for Scapy that I'm trying to market I taught it this past Sunday at the Baltimore SANSFIRE with a handful of students and unless I do a better job of marketing the course, it will be dead by the end of the year I'd hate for that to happen since I put a lot of work into it and it's really a fun course The next time I'm teaching is in Las Vegas in September for SANS Network Security 2010 http wwwsansorg network-security2010 descriptionphp tid 3712 Okay - enough pimping, now to the good stuff ----------------------------------------------------------------------------------------------- usr bin python from scapyall import import random pay1 GET EVIL pay2 STUFF HTTP 11 r nHost sender r n r n sp randomrandint 1024,65535 ip IP src 1921681104 , dst 1921681103 SYN TCP sport sp, dport 80, flags S , seq 10 SYNACK sr1 ip SYN my_ack SYNACKseq 1 bad_ack my_ack 1 next_seq SYNseq 1 ACK TCP ack bad_ack, sport sp, dport 80, flags A , seq next_seq send ip ACK PUSH TCP ack my_ack, seq next_seq, sport sp, dport 80, flags PA send ip PUSH pay1 next_seq ACKseq len pay1 PUSH TCP ack my_ack, seq next_seq, sport sp, dport 80, flags PA send ip PUSH pay2 next_seq PUSHseq len pay2 RST TCP ack my_ack, seq next_seq, sport sp, dport 80, flags RA send ip RST ------------------------------------------------------------------------------------------ I'm going to explain the code and not the Scapy format since you can learn that from online documentation or come to my course - Scapy modules are imported with from scapyall import - Next, I import random to randomize the source port I do this because if you manage to create a connection, but do something wrong and want to start another session, you won't be caught in some wait state for the bad session to time out - I assume there is some kind of content rule for EVILSTUFF I separate these into two segment to force TCP reassembly so the IDS IPS doesn't alert because the content is contained in a single segment - I randomize the source port with a value of 1024-65535 - I create an IP header - the IP addresses are different than the ones in the previous post, but you can change them for your source and destination IP's - I create a TCP header for the SYN segment next with the randomized source port, a destination port of 80, the SYN flag set, and a too-low but identifying Initial Sequence Number of 10 -The next statement is the trickiest The right side uses Scapy's sr1 command to send a packet and match and return the response I've assembled my IP header followed by my TCP header ip SYN and send it with the sr1 command I've told Scapy to store the returned packet in a variable named SYNACK This is one of the most amazing things Scapy does - it is able to return and store the server's SYN ACK No command line tool I know of can do this - Next I extract the server's sequence number and add 1 to it and call it my_ack This is the valid acknowledgment number But, I don't use this right away - I now define bad_ack as the real acknowledgment number 1 so it's not the next expected one - I increment the client's sequence number to account for the sequence number consumed by the SYN - I define my TCP acknowledgment header using the bad acknowledgment number - I send the segment with the bad acknowledgment number - Now I create a TCP header for the PUSH segment, but it has the valid acknowledgment number - Next, I send the PUSH segment that has the first payload - I compute the next TCP sequence number as the current sequence number the number of bytes in the first payload - I create a new TCP PUSH header with the updated TCP sequence number - Now, I send the PUSH segment with the second part of the payload - I compute the next TCP sequence number for the reset - Then I create a reset TCP header - Finally, I close the session by sending the reset packet One final detail Scapy creates raw sockets that have an unfortunate side effect of causing the sending host's TCP IP stack to attempt to reset the connection since we circumvent it It knows nothing about the SYN we sent out so when the SYN ACK, or for that matter, any packet is returned from the server your host's TCP IP stack will attempt to reset it We can suppress these resets using iptables iptables -A OUTPUT -p tcp -s 1921681104 -d 1921681103 --tcp-flags RST, RST --destination-port 80 -j DROP My destination host had a Linux 26 kernel and manifested the behavior I showed in the previous post Execute the above Python Scapy program and capture the traffic using tcpdump and you should see what I saw Happy crafting http://www.secuobs.com/revue/news/234879.shtmlhttp://www.secuobs.com/revue/news/234879.shtml