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