<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>Sipera Viper Labs: Generic Threats</title>
        <link>http://www.sipera.com/viper</link>
        <pubDate>Fri, 03 Sep 2010 01:46:52 -0500</pubDate>
        <lastBuildDate></lastBuildDate>
        <generator>ContentFeeder 2.0</generator>
        <item>
            <title>Unencrypted RTP vulnerable to capture and reconstruction</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=264</link>
            <description><![CDATA[Unencrypted RTP packets in IP-based communication can be captured to reconstruct the media (e.g., voice or video) compromising confidentiality of communication.]]></description>
        </item>
        <item>
            <title>RTCP may expose internal IP addresses and private user names across NAT device</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=265</link>
            <description><![CDATA[In the context of NAT devices, RTCP SDES packets may contain private information about usernames and internal IP addresses which may not be translated/hidden before packets travel to un-trusted zone through the NAT device.]]></description>
        </item>
        <item>
            <title>Weak SRTP encryption algorithm may be brute-forced to compromise confidentiality of communication</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=268</link>
            <description><![CDATA[Weak mandatory encryption algorithm for SRTP may be cracked using brute-force techniques.]]></description>
        </item>
        <item>
            <title>Traffic analysis of RTP source and destination IP addresses may reveal communication pattern</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=266</link>
            <description><![CDATA[Using source and destination information of RTP packets it may be possible to gather traffic communication patterns in an un-authorized way. This is especially important in highly sensitive communications infrastructures.]]></description>
        </item>
        <item>
            <title>Improper implementation of security mechanism for SRTP may compromise communication confidentiality</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=267</link>
            <description><![CDATA[SRTP key negotiation is performed with non-SRTP mechanism, If this key negotiation channel is not adequately secured; it may allow an attacker to eavesdrop on the SRTP media channel.]]></description>
        </item>
        <item>
            <title>RTP sequence number and timestamp can be guessed to inject media packets that may be accepted by receiver as legitimate</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=269</link>
            <description><![CDATA[Replay protection provided by RTP sequence numbers and timestamps is limited and an active attacker can replay captured packets by carefully changing the values.]]></description>
        </item>
        <item>
            <title>RTP packet receivers vulnerable to injected RTP packets with malicious payload types</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=270</link>
            <description><![CDATA[It is possible to inject specially crafted RTP messages with payload formats that are computationally more expensive to decode.]]></description>
        </item>
        <item>
            <title>RTP stream may contain active content which can potentially execute arbitrary operations on the receiver</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=271</link>
            <description><![CDATA[Active content (e.g., Java applet) can be included in RTP with MPEG-4 streams. Such active content has the potential to execute arbitrary operations on the receiving system.]]></description>
        </item>
        <item>
            <title>SIP compliant clients may be vulnerable to transport rollback vulnerability</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=178</link>
            <description><![CDATA[Provisions in SIP standard may allow an attacker to exploit a fully compliant SIP client and force it to use UDP instead of TLS transport and potentially opening up possibilities for sniffing and spoofing.]]></description>
        </item>
        <item>
            <title>Insufficient integrity checks on SIP digest authentication messages</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=179</link>
            <description><![CDATA[Some SIP servers may exclude the “qop” parameter from the 401/407 challenge message. This gives rise to the possibility of undetected message tampering resulting in sensitive SIP signaling data (e.g. originator identity) being changed by an attacker.]]></description>
        </item>
        <item>
            <title>Absence of server authentication during SIP digest authentication </title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=180</link>
            <description><![CDATA[Some SIP implementations may not enforce server authentication using cnonce parameter potentially allowing an attacker to impersonate the server. ]]></description>
        </item>
        <item>
            <title>Registrar honors replayed authentication parameters</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=181</link>
            <description><![CDATA[Some Registrar implementations may relax nonce changing requirement and accept stale nonce in digest authentication allowing an attacker to replay previously captured SIP REGISTER messages and maliciously alter the data associated with victim’s AOR.]]></description>
        </item>
        <item>
            <title>No cross-check performed between username of user requesting authentication and username used in credentials during SIP digest authentication</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=182</link>
            <description><![CDATA[Registrar SIP implementations may not enforce user names in To header and in Authorization header to be identical. This may allow an attacker to reuse sniffed Authorization header for someone other To header.]]></description>
        </item>
        <item>
            <title>Some implementations of SIP Proxy may honor replayed authentication credentials</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=183</link>
            <description><![CDATA[SIP proxy server implementations may accept replayed credentials in call setup requests potentially allowing an attacker to reuse credentials previously captured in the messages of choice.]]></description>
        </item>
        <item>
            <title>Presence Servers may be vulnerable to overloading of subscriptions by spoofing credentials</title>
            <link>http://www.sipera.com/index.php?action=resources,threat_advisory&tid=184</link>
            <description><![CDATA[An attacker can reuse previously sniffed credentials and change the From user name to create large number of subscriptions to overload Presence server.]]></description>
        </item>
    </channel>
</rss>
