cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

AMA-CUCM Troubleshooting: Best Practices for Reading Trace Files

Collecting a packet capture from a Cisco IP Phone

141279
Views
65
Helpful
9
Comments

     

    Introduction.

     

    For troubleshooting purposes one may need to gather a packet (sniffer) capture from an IP Phone. There are many ways this can be accomplished.   This article describes how to collect the capture using the IP Phone's built in PC ports.  It can be enabled to copy all traffic entering into the SWITCH port, and send it to the PC port.  From there, the data can be captured using a packet capture utility.

     

    These instructions are relevant for Cisco IP Phone Models, 7941, 7942, 7961, 7962, 7965, 7970, 7975, 99xx, 89xx, and 699xx.

    For models 7940 and 7960, skip Step 2 since "Span to PC Port setting" is not required.

     

    1. Connect the Cisco IP Phone

     

    SnifferCapture.PNG

    There should be a PC connected to the back of the IP phone in the PC port, and the phone connected to the Switch.

     

    2. Enable the Span to PC port feature.

     

    From the IP phone configuration page, scroll down to the Protocol Specific Configuration section, and enable the "Span to PC Port" configuration option.   This will trigger a change to the phone's TFTP configuration file.   Save and reset the phone so it can retrieve the new configuration file.

    ScreenHunter_04 Jun. 21 07.17.jpgScreenHunter_02 Jun. 21 07.15.jpg

     

    Note

    7940 and 7960 Cisco IP Phones do not support the span to PC port feature, all data is automatically sent to the PC port.

     

    3. Capture the packets with wireshark.

     

    3a.  Starting the capture

         Open Wireshark and click on the first NIC to the left.

     

    ScreenHunter_12 Jun. 21 07.25.jpg

    This will open the capture interfaces dialog, were you can select the NIC connected to the back of the IP phone we will capture. Click on start to initiate the capture

    ScreenHunter_07 Jun. 21 07.20.jpg

    3b.  Reproduce the issue to be captured

    Traffic should start to scroll down on the window. Depending on the current PC activity it could be a lot of traffic. To filter down use the eth.addr filter with the MAC Address of the IP phone. The resulting traffic should show only traffic comming to and from the IP phone.

    ScreenHunter_11 Jun. 21 07.22.jpg

    3c. Stop the capture.

    ScreenHunter_13 Jun. 21 07.25.jpg

     

    3d.  Save the packet capture as a .pcap file.

    ScreenHunter_14 Jun. 21 07.25.jpg

    Comments
    Contributor

    Really good article. I wrote a tutorial on how this feature could be exploited to record phone calls that could be later be played back. This tutorial was sent to Cisco PSIRT prior to be released publically:

    http://www.og150.com/tutorials.php Download "Podo Attack" to see the end to end compromise.

    Thanks

    Darren

    Enthusiast

    Darren,

    I look through your article. This feature is recomended to be enabled for troubleshooting purposes. Also some forms or call recording on our UCCX suite use this feature. To protect from the type of Attack you are describing, we have ITL signed config files that are now standard on CUCM 8.X and higher versions. Also you could block the settings to prevent the user from deleting the CM ITL file on the phone.

    Anonymous
    Not applicable

    Agreed with Robert.  That is not an exploit, it's just enabling the feature as it was intended. 

    Administrator's could easily prevent this by locking settings access and/or enabling sRTP via CTL. 

    Contributor

    Hi guys. Robert, I wasn't aware of ITL signed config files that you said is standard on CUCM 8.x and higher - this, if properly implemented, would prevent the attack. In my document I talk about disabling user settings, so I was aware of that and it is covered in my doc. I agree this is NOT a zero day vulnerability. It does however exploit weak default settings (in some versions of CUCM), meaning that is a security risk. Agreed about blocking default settings (see above) but using sRTP (encrypted RTP right) would also prevent the playback - I wasn't aware sRTP was supported so that is a cool preventative measure :-)

     

    Thanks guys, I will update the doc to include your comments.

    Darren

    Beginner

    hi,

     

    I tried this method with cp-7942 but it only capture some skinny keepalive msg.

    telephony  ----> voip calls does't show any call flow with my captured packets.

     

    Any idea how to resolve this?

     

    Thanks.

    Cisco Employee

    This will work on the DX70/DX80's. Once you enable Span to PC port. Click save. Then click apply config. When you start the capture you should see the RTP and the H.264 during the call.

    Beginner

    I encountered the same problem with CP-7962 with latest firmware. Any idea to resolve it? I'm able to capture the packet for CP-6901 model. I have tried both the switch spanning and PC port spanning on CP-7962.

    Beginner

    Here's my 2 cents

    Make sure you use Straight-through cable to connect IP Phone & PC
    (IP phones don't support connection with cross-over cable)

    Congratulations for the article !

    I think you could publish one post about how to read and interpret the RTP signaling and audio packets on Wireshark.

    CreatePlease to create content
    Content for Community-Ad
    August's Community Spotlight Awards