[VOIPSEC] Actual Attacks

[Brian Rosen]

Simon

I was replying to a message that claimed ITU specs were designed better than
IETF specs, and specifically, that it was trivial to send information, such
as an actual IP address, using the signaling between end points which the
service provider is unaware of, using SIP, but not with ITU protocols.  The
specific example given was:
X-HACKBYPASS:24.2.2.1

The examples I gave were messages I believe most firewalls, SBCs and other
H.323 elements would ignore if passed between two consenting end points.
You can take OpenH323 and use it to do that.  Even in the cases
where the current code rejects a message, the code could easily be changed
to accept it.  As long as the carrier's network elements don't reject the
message, you can misuse the protocol to pass information end to end.
The firewalls, SBCs and gateways don't know that you are misusing the
syntax.  They only can check if it's legal syntax. 

What you need to do is to see if your firewalls and SBCs would not permit
these messages to pass.  I believe all of them will allow at least a subset
of these through.

As for mudslinging, please see the original message from Geoff, but I'll
refrain from further comment on that aspect.

Brian




> -----Original Message-----
> From: Simon Horne [mailto:security at isvo.net]
> Sent: Tuesday, March 01, 2005 10:07 PM
> To: Brian Rosen; 'Geoff Devine'; Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> 
> 
> I'd decided to check some of these issue out against the openH323 source
> to
> see their security risk.
> 
> At 12:37 AM 2/03/2005, Brian Rosen wrote:
> >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.
> 
> This is used when opening T.120 data channels. It instructs the other
> endpoint to create a listener. OpenH323 does not support the e164Address
> (only localAreaAddress) Send this it will be ignored.
> 
> 
> >H222LogicalChannelParameters    ::=SEQUENCE
> >{
> >         resourceID      INTEGER (0..65535),
> >         subChannelID    INTEGER (0..8191),
> >         pcr-pid INTEGER (0..8191) OPTIONAL,
> >         programDescriptors      OCTET STRING OPTIONAL,
> >         streamDescriptors       OCTET STRING OPTIONAL,
> >         ...
> >}
> 
> This one is Multiplex Video capability (designed for MPEG 2). For OpenH323
> it is unsupported and if received the call is automatically rejected.
> 
> 
> >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.
> 
> This is used for Conference request and the terminalLabel is optional
> OpenH323 supports it structure it but it is not Implemented. The message
> is
> Ignored.
> 
> 
> >There are dozens more.
> 
> Oh Please do send more I like to check these thing out for my own piece
> of mind.
> 
> >H.323 is an incredibly "leaky" spec if you want to pass information in
> >signaling.
> 
> Yes it has a lot of Overhead support but I would not call it leaky. A lot
> of the items are optional and its up to the developer whether to include
> them or not (that's its design). If the developer decides to include a
> feature without putting in the associated necessary security precautions
> then the problem is not the standard but the developers. Yes there is a
> lot
> of places where malicious messages can be inserted but for a good
> implementation most of them would be ignored.
> 
> >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.
> 
> The choice of which standard to use is a personal choice. I myself like
> ITU
> (obviously) but in a lot of areas there is great IETF stuff and in a lot
> of
> situations they reference each other.  The best example is RTP & SRTP
> which
> is IETF but is are implemented in ITU.There are other standards which have
> great features are well  IEEE for example.  But it really depends on the
> part of the world you are in too, for most of the guys here it's IETF but
> for others its ITU. For example 3G phones in my area use ITU H.324M which
> utilizes H.245 call signalling so for inter operable development into the
> area I'd be silly not to stick to the compatible VOIP Standard.
> 
> Brian please keep the mud slinging off the list. The best way is to share
> our experiences and knowledge for the benefit of all.
> 
> Simon
> 
>