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


TUCoPS :: Network Appliances :: bintec3.htm

BinTec X4000 Access Router locks up after nmap portscan



Vulnerability

    BinTec

Affected

    BinTec X4000 Access Router

Description

    Jan Muenther found  following.  BinTec  X4000 locks up  after nmap
    -sS  portscan.   The  BinTec  X4000  is a mid-sized multi-purpose,
    multi-protocol router meant  to fit the  needs of small  to medium
    companies.  Unfortunately, it has a bit of a problem.

    A simple nmap SYN scan (nmap  -sS) will cause the machine to  lock
    up completely.  It can neither be accessed through LAN nor through
    a  serial  connection  or  the  built  in,  LCD-display-based  MMI
    (man-machine-interface).  The only way of getting it back to  life
    is to pull the plug and put it back in.

    As far as we know,  every firmware version has the  vulnerability,
    though we only verified this with 5.1.6 Patch 10 of the  bootimage
    and logicware 1.05.  Jan used nmap 2.53.

    According  to  Stephan  Holtwisch  Bintec  has  some  other stupid
    "habits" as well.  If you send lots of small UDP packets over  the
    Link (a  customer did  this with  a stub  resolver), it constantly
    had 5-10 % packet loss.   You will find this kind of  behaviour in
    various Firmwares concerning NAT, IP Accounting etc.

    Further examination  of the  phenomenon at  BinTec has  shown that
    sending a SYN  flagged TCP packet  to port 1723  (pptp) will cause
    the  machine  to  behave  in  the  described way.  The pptp daemon
    should be activated only when the software license key is  entered
    and it can process incoming packets adequately.  However, it isnt.
    When the 'dormant' pptpd receives a SYN packet and cannot  process
    it, the  daemon claims  100% CPU  usage and  the machine locks up.
    This, of course, happens when  a SYN portscan against the  machine
    is issued and port  1723 gets hit -  you can also easily  check it
    with  'telnet  my.machines.ip  1723'  or  your  favourite   packet
    injector.

Solution

    Machines with activated additional VPN software license are  *NOT*
    affected, neither are machines which filter 1723/tcp.

    There  are  two  solutions:  One  of  them is less pricey than the
    other. If you wanted to buy the VPN software anyway, just go ahead
    and enter the key.

    If not, you should include a rule which drops 1723/tcp directed at
    all interfaces  of your  router (as  you should  do anyway  if you
    don't use it).


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