Date:         Tue, 10 Apr 2001 14:56:55 -0600
From: "Head of Research Dept." <hrd@OTKO.KZ>
Subject:      X4000 DoS: Details and workaround
To: BUGTRAQ@SECURITYFOCUS.COM

System affected:
---------------
BinTec X4000 Router

All firmware versions [as far as I know, only verified with latest
release 5.1.6 Patch 10]

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


Description:
-----------

As mentioned before, under the given circumstances the X4000 will lock
up after sending a SYN portscan to it. 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:
--------

There are two solutions: One of them is less pricey than the other ;o))
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).


Vendor response:
---------------

Some might remember a little bitter notion with my first mailing.
However, the day after I posted to Bugtraq the development director
contacted me. He was very eager to help and asked for my config file
and a stack trace, which I send them as quick as possible. He reassured
me that the problem was taken seriously, but mentioned that they could
not reproduce the phenomenon, so they would take a look at my config and
see what might have caused it. All this was yesterday.

Today, the leading developer (I assume) for the X4000's firmware called
me and was able to present the above solution. He had tried to
reproduce the DoS on a machine with VPN license first and only after a
long night got the idea that the pptp daemon might be the culprit (I
_did_ pity him).


Comment:
-------

I hope you don't mind a personal comment. The sheer fact that I did not
get any response after first informing support staff of the issue
really upset me quite a bit. I really expected some reaction within
less than almost three weeks. Going public changed the response level
pretty quickly ;o) To be fair I have to state that all the staff I
talked to during the last few days were seeming absolutely competent
and very eager to help. Everyone involved stressed how sorry they were
about the delay and how unusual this was.

>From my personal experience I could only say this is probably true,
since we've been using other BinTec products for years and they
generally performed very well, especially compared with products of
another, erm, well-known vendor.

As for my statement about the recently introduced money back warranty,
I could only say that I now do believe this was launched under the
assumption of a totally stable platform. They surely didn't know the
vulnerabilty.

No, I was not bribed to say this ;o))















--
Radio HUNDERT,6 Medien GmbH Berlin
- EDV -
j.muenther@radio.hundert6.de