Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Network Appliances :: bintec1.htm

Bintec Router Firmware (CLID) BOSS V4.9 Release 1 and earlier (at lea incoming call problems



Vulnerability

    Bintec Router Firmware (CLID)

Affected

    Bintec Router Firmware (CLID) BOSS V4.9 Release 1 and earlier (at least)

Description

    Pascal   Gienger   found   following.     Non-interpretation    of
    "international"  or  "national"  incoming  call  setup  leads to a
    security  problem  when  you  accept  connections  based  on their
    incoming call number.  Bintec  is a manufacturer of routers  whose
    market share is  growing steadily.   So the following  information
    should be of  general interest.   Bintec Routers are  shipped with
    the BOSS Operating system, current release is V4.9, Rel.3.  Bricks
    do support besides PPP links  also raw IP encapsulation over  HDLC
    frames  (ISDN  Line).   In  the  latter  case,  WAN  partner   are
    distinguished based upon their incoming call number (CLID), so you
    must  "trust"  your  telephone  company  for  issuing  the   right
    information.  People may set their own "outgoing" number, but only
    the ones marked as "screened" by the telco are looked at.

    In Germany, you have to dial  an "0" to exit your local  area, and
    "00" to access international calls.  These zeros, however, do  not
    belong to  the real  telephone number,  they are  not passed along
    with the ISDN call request.  So a call from +41 1 1234567 (0041  1
    1234567) is  passed as  "4111234567".   A call  from 0411  1234567
    (national  call  from  city  zone   "4111")  is  also  passed   as
    "4111234567".  You  have to set  this "4111234567" as  an incoming
    number in the  brick setup because  otherwise the Brick  would not
    recognize the  call.   The only  difference is  a flag  which says
    whether the call is  an international one or  not.  BOSS does  not
    distinguish these two,  leaving this security  hole open.   If you
    know the number of a WAN partner abroad which number has less than
    9 digits, you can search the  local zone in Germany and trying  to
    get there the appropriate number  to access the router.   Might be
    complicated, but  if you  know that  there is  sensitive stuff  to
    get...

Solution

    There is  a security  mechanism available  for all  BinTec Routers
    that can be  used to verify  if the "Calling  Party Number" of  an
    incoming call was modified by the calling party.The  SETUP-message
    of  an  incoming  call  at  an ISDN-interface contains a parameter
    field called "Screening Indicator".  This Screening Indicator  can
    not be set  by the originiating  user, but it  is modified by  the
    first exchange at the call  originator side.  Possible values  for
    the  screening  indicator  are  (refer  to  ITU  Q.931 or ETSI 300
    102-1):

        - "user-provided - not screened"
        - "user_failed provided - verified and passed"
        - "user_failed provided - verified and failed"
        - "network provided"

    From firmware revision BOSS V4.8 Release 1, the user could  select
    if the screening  indicator is verified  and specify the  expected
    value.    This can  be done  for every  indiviual number,  and  is
    selected   by   modification   of   the   SNMP  configurationtable
    "dialtable".  Unfortuantely there  are many smaller PABX  (private
    branch exchange) used by our  customers, that do not pass  through
    the  value  of  the  screening  indicator without modification, so
    Bintec decided, not to verify  all numbers by default.   For users
    of  raw  IP  connections,  it  is  recommended verification of the
    screening indicator.  But this  still leaves the hole of  the same
    incoming  number  of  possible  international  and  national calls
    open....  The screening was only one thing. The other thing is the
    same incoming number for (e.g.) +41 1 1234567 and +49 411 1234567,
    resulting  both  in  4111234567.   The  "numbering  type" field is
    not  looked  at.   "Numbering  plan"  should  always  be  ISDN for
    non-modem connections...


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH