[VOIPSEC] Actual Attacks

[Brian Rosen]

Oh please.
H.245 is riddled with parameters you can misuse, such as:
	networkAddress	CHOICE
	{
		q2931Address	Q2931Address,
		e164Address	IA5String(SIZE(1..128)) (FROM
("0123456789#*,")),
		localAreaAddress	TransportAddress,
		...
	},
Shove an IP address in an e164Address like 023013012167.  They even let you
use 128 characters when an e.164 is always l6 or less.

H222LogicalChannelParameters	::=SEQUENCE
{
	resourceID	INTEGER (0..65535),
	subChannelID	INTEGER (0..8191),
	pcr-pid	INTEGER (0..8191) OPTIONAL,
	programDescriptors	OCTET STRING OPTIONAL,
	streamDescriptors	OCTET STRING OPTIONAL,
	...
}
Have a nice program descriptor of "25.15.13.12" or even 024015013012 if you
are really paranoid.  

Session Description in CommunicationsMode

One of my favorites (not sure if this is really the one I saw a while back)
	requestTerminalCertificate 	SEQUENCE
	{
		terminalLabel	TerminalLabel OPTIONAL,
		certSelectionCriteria	CertSelectionCriteria OPTIONAL,
		sRandom	INTEGER (1..4294967295) OPTIONAL,
					-- this is the requester's challenge
		...
	},

You put your message in the "terminal label"
There is another one like it that has a long "challenge" string.
There is some beauty in using a security challenge as a container for
unapproved end to end communication.



Every firewall I know just grabs the ASN.1 descriptions for what legal
messages are.  If its allowed in the ASN.1, it's allowed.

There are dozens more.

H.323 is an incredibly "leaky" spec if you want to pass information in
signaling.

There are fewer tricks like that in, say Q931, but even there, I know
several that people have used to sneak data end to end.

and spare me the polemics of:
> in philosophy.  In the IETF, the network is a testbed.  In the ITU, the
> network and services provided by the network is a source of revenue.

Wanna plot the revenue of, say, ISUP vs TCP (or even SIP) over time?

I've worked in both arenas.  I'll take the IETF any day for quality of
protocols.  Every organization has its turkeys, and the IETF is getting so
big, the number of turkeys is increasing.  ITU has done good work, but its
track record in the last ten years or so is not so hot.   Some bright spots,
to be sure (some of the optical work comes to mind).  However, the real work
in user level services in telecom is at the IETF these days.  Get over it.


Brian


> -----Original Message-----
> From: Geoff Devine [mailto:gdevine at cedarpointcom.com]
> Sent: Tuesday, March 01, 2005 10:30 AM
> To: Brian Rosen; Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> 
> Brian Rosen writes:
> 
> > I don't agree with your analysis of vulnerabilities in protocol design:
> >> You have the IETF way where pretty much any message will get through
> the
> >> firewall.  You have the ITU way where only messages that conform to a
> >> known profile get through the firewall.
> 
> >That's simply untrue.  The specifications for each are about as exacting
> as
> >the other with respect to "legal" messages.  They have stylistic
> >differences, but in practice, the differences do not change the ability
> of a
> >firewall to detect a "good" from a "bad" PDU.  I don't see firewalls
> going
> >away, but I see them having less and less relevance to the actual
> threats.
> 
> 
> OK.  Here's a real-world example:
> 
> In SDP in a SIP Invite message, I can embed:
> X-HACKBYPASS:24.2.2.1
> 
> where 24.2.2.1 is my IP address.  The other endpoint can reject the Invite
> and bypass the service provider since they know my IP address.
> 
> A SIP Proxy built in the spirit of the IETF is required to pass through
> any SDP even if it doesn't understand it.  The ITU, where protocols are
> designed by service providers, wouldn't allow such a thing.  That's why
> 3GPP uses a Back2Back User Agent model of SIP.  You can enhance and
> profile an IETF protocol to give it the robustness of the typical ITU
> protocol but you certainly won't get there if you merely follow the
> normative requirements of the root RFC.  It all boils down to a difference
> in philosophy.  In the IETF, the network is a testbed.  In the ITU, the
> network and services provided by the network is a source of revenue.
> 
> Geoff
> 
> 
> 
> 
>