Subject: [Megaco] how to identify a "malicious ServiceChange"?

From: "Perz, Gernot" <[email-masked]>
Date: Thu, 5 Jun 2008 15:05:56 +0200

Hello, 

I've recently discusssed the following problem:

In a softswitch environment where an MGC is controlling a big trunking
Gateway, a single ServiceChange looking harmless as the following:

!/1 [192.168.5.210]:2944  T=14905015 
    { C=- { SC=ROOT 
              { SV { MT=Restart , 
                     RE="901 Cold Boot" ,
                     20080503T09011001
                   }
               }
           }
    }

could have disastrous effects if it is sent by the GW (or an attacker
simulating the GW) maliciously. The MGC would assume that all the trunks
went down and have/had to be re-established. As a result of this
Servicechange a lot of Controller-side objects would be logically
released by the MGC, resulting in loss of calls, enforced recoveries on
the MG, etc.

The discussion arose out of the assumption of a misbehaving MG sending
this ServiceChange in a loop (f. I. due to SW problem), but we ended at
the conclusion that even the very first "malicious ServiceChange" could
be "deadly".

Question:
=========

Is there some recommended strategy to detect this sort of "malicious
ServiceChange" on the MGC, like some plausibility check against "normal
MEGACO communication traffic" of the same GW?

F. I., usually one wouldn't assume that this ServiceChange would
plausibly occur mixed into fast sequences of NOTIFYs and transaction
replies from the GW. You would rather expect to observe some
communication problems to the GW before this sort of ServiceChange
occurs.

With kind regards and thanks in advance!

Gernot Perz

_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 5 Jun 2008 15:44:12 +0200

There are multiple countermeasures here, like
- H.248 entity authentication
- H.248 message encryption
- H.248 message policing

Guess you know H.Sup7, which is providing some guidelines on each topic.
ITU-T H.Sup7 (ex H.248.CtrlAssoc) "Gateway Control Protocol: Establishment Procedures for the H.248 MGC-MG Control Association" 
http://www.itu.int/md/T05-SG16-080422-TD-PLEN-0480/en

See e.g.
§ 5.6.4	Security: Authentication	
§ 12 		H.248 Control Association: policing of incoming H.248 messages

Masquerading may be addressed by encryption, incorrect SW implementation may demand for message policing. § 12/H.Sup7 is indicating many message policing options, but of course not exhaustive, just looking at the simple policy conditions. Underlying assumption are correct H.248 implementations.
If you are faced with incorrect SW implementations, you may need additional, DPI type message polcing conditions ("Deep H.248 Message Inspection") IMO.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Perz, Gernot
> Sent: Donnerstag, 5. Juni 2008 15:06
> To: [email-masked]
> Subject: [Megaco] how to identify a "malicious ServiceChange"?
> 
> Hello, 
> 
> In a softswitch environment where an MGC is controlling a big 
> trunking Gateway, a single ServiceChange looking harmless as 
> the following:
> 
> could have disastrous effects if it is sent by the GW (or an 
> attacker simulating the GW) maliciously. The MGC would assume 
> that all the trunks went down and have/had to be 
> re-established. As a result of this Servicechange a lot of 
> Controller-side objects would be logically released by the 
> MGC, resulting in loss of calls, enforced recoveries on the MG, etc.
> 
> The discussion arose out of the assumption of a misbehaving 
> MG sending this ServiceChange in a loop (f. I. due to SW 
> problem), but we ended at the conclusion that even the very 
> first "malicious ServiceChange" could be "deadly".
> 
> Question:
> =========
> 
> Is there some recommended strategy to detect this sort of 
> "malicious ServiceChange" on the MGC, like some plausibility 
> check against "normal MEGACO communication traffic" of the same GW?
> 
> F. I., usually one wouldn't assume that this ServiceChange 
> would plausibly occur mixed into fast sequences of NOTIFYs 
> and transaction replies from the GW. You would rather expect 
> to observe some communication problems to the GW before this 
> sort of ServiceChange occurs.
>