|
Vulnerability ROUTERmate Affected Systems using Osicom ROUTERmate products: * ROUTERmate Plus T1 * ROUTERmate Plus 56K * ROUTER mate-EX MULTI-PROTOCOL EXECUTIVE ROUTER * ROUTER mate Plus - D&I INTEGRATED ROUTER AND T-1 DROP & INSERT CSU Description Following is based on Osicom Technologies ROUTERmate Security Advisory. Osicom Technologies makes remote access router products for 56K-T1 users. While evaluating these products Rootshell came across various flaws in the TCP/IP stack of these routers allowing remote users to gain access to and crash the ROUTERmate products. Here are the problems: * The TCP/IP stack deals with SYN packets incorrectly and allows a remote user to crash the unit in two ways. In each of these cases the router will reboot and then function normally unless hit with the attack again. 1) If a user port scans the router with any readily available port scanner the unit will crash. 2) If the router is hit with a flood of SYN packets the router crashes. Code to generate SYN packets can be found on the Rootshell website as "synk4.c" and "SYNpacket.tgz". * The TCP/IP stack can be crashed by exploiting the "off by one" IP header bug that recently affected Linux and Windows users. This attack is commonly know as "nestea.c" and can be found on on this site (see is Linux section IP fragment overlap #2). The ROUTERmate will also crash with the similar bugs "bonk.c" and "newtear.c" (see in NT section IP fragment overlap #2 and #3). After these attacks the router will reboot then function normally unless hit with the attack again. * The TCP/IP stack can be caused to completely freeze up requiring a reboot by the end user via the serial port console or by bouncing the units power source. "pmcrash.c" available on Rootshell crashes Livingston portmasters prior to ComOS 3.3.1 (they fixed this problem well over a year ago). This same problem is now in the ROUTERmate product, however the unit will not reboot on its own. On a local network the ROUTERmate crashed after running pmcrash for just a few seconds. pmcrash.c simply sends large amounts of fragmented ICMP traffic at the router. * The default SNMP configuration allows any remote user to change the configuration of leased lines, place circuits in loopback, and reboot the router. The ROUTERmate product ships with a default write community of "private". By using commonly available SNMP software such as the CMU SNMP packages a user can gain access to the following commands. The entire MIB file can be found on ftp.osicom.com. unitResetCommand <------ Anyone can reboot the product by default. localNIloop remoteNIloop lineLoop payloadLoop testPattern niClearTestCounter insertBitError interfaceLocalLoop interfaceRemoteLoopWithTestPattern interfaceTestPattern interfaceDiagClearCounters saveConfigToFlash niFormat niCoding niTiming niLineBuildOut esfDataLink remoteLoop esfCxrLoops bandwidthAlloc interfaceDataRate interfaceDataMode interfaceRmtLoopResponse clearCounters clientAutoLearn accessViaTelnet clientAddress Solution Since the ROUTERmate product does not support packet filters the only workaround at the moment is to disable the "Autolearn Clients" feature of the ROUTERmate. New firmware when available should be posted to: ftp://ftp.osicom.com/