[VOIPSEC] Actual Attacks

[Simon Horne]

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