Date: Thu, 21 Jan 1999 01:18:50 -0800 From: John Stanley To: BUGTRAQ@netspace.org Subject: WebRamp M3 remote network access bug I have not seen this problem mentioned on this list. I defer to the moderator's memory and hope this is valuable information... The WebRamp M3 is a small SOHO router with 4 10baseT ports on the local side and three serial ports on the remote side. It acts as the net gateway and makes dial-up PPP connections automatically when necessary. It also has NAT functions, so you can use a non-routable local network address and still communicate worldwide. It monitors the load through the first modem and will make a second dialup connection if the load is higher than a configurable value. It will make a third connection if the first two are reaching capacity. It will not split one connection across two modems, however, so when you ftp the latest source from somewhere, you are stuck with single-modem speeds. You can define what they call a "visible computer", which is simply a default local IP address to which the M3 will pass all otherwise unknown packets from the outside. Unless you configure the M3 otherwise, smtp, nfsd, routed, etc connections from the outside go to the visible computer. You can also disable visible computer. The M3 has a rather cryptic command language that can be accessed via a command serial port or via a telnet connection. It also has a web-based admin capability. All in all, it is a rather nice little box, EXCEPT... I had a visible computer enabled so I could track where outside packets were coming from. I started doing this because the M3 has a problem determining activity. It is supposed to time out after a set time if there is no activity, but it counts the reception of any packet from the outside as activity, even if the packet is never sent to the local side of the net. I wanted to see where the activity was coming from[%]. Then I turned "visible computer" off. To test that it was really off, I tried telnetting into my network from outside. I expected a timeout. I was surprised to see the WebRamp M3 answer the telnet request with a login prompt. Part of the "visible computer" configuration web page is a check-box that determines if outside telnet packets are to be redirected to the M3. This box was not checked. Just to be sure, I sent the unchecked configuration back to the M3. I did this MANY times, just to be sure. There was nothing I could do to stop the M3 from answering telnet requests >from outside except to turn "visible computer" back on with a non-existant local IP address as the destination. (Using an active local IP address would mean the local system would get the telnet request, as well as any connections to nfsd or mountd or SMTP...) The customer support[*] at RampNet has continued to tell me that this is simply a configuration error on my part, that I am confused by the check boxes in the web form, and that the web browser is caching pages. "This is not a bug." The customer support[*] person asked me to send her my remote IP address and admin password for the box so she could log into the box and examine my configuration. I tried explaining that dialup IP means I can get a different IP address every time the M3 dials in, that my M3 was not dialed in so there was no IP address for it at the current time, and that sending passwords over the net in the clear wasn't a bright idea. ("Here's the IP address of my computer, and the root password is..."). Finally, the customer support[*] person sent me a series of commands to send to the M3 over the command serial port that would set my configuration properly. I sent the commands, and, of course, the M3 still accepted my remote telnet request and allowed me to log in. WebRamp/RampNet customer support[*] has had sufficient time to respond to the problem, and frankly, I am tired of being told that I am too stupid to configure their hardware properly. This is the same answer I got when I reported that they were counting packets that were being thrown away as valid activity and keeping the dialup connection up longer than it should be. ("Just shut if off when you are done." The fact that they are selling a box that allows automatic, unattended dialup-on-demand must have slipped their minds.) IF YOU ARE USING THIS BOX, you should test it for this problem. All you need to do to see if your M3 has this problem is to try telnetting to it >from a system on a remote network. The telnet packets must come to the M3 via the modem; the M3 will always accept telnet connections coming from the local network. If you see the prompt "WebRamp login: " your M3 is letting anyone in the world connect to it. Work down the web admin pages through Advanced/Applications/Visible Computer and make sure you have not checked the "Divert" options, unless you really want your M3 talking to the world (and vice versa.) If you are using this box, and you see this bug, and you have NOT changed the admin password from the default, DO SO IMMEDIATELY. If you aren't using this box now, don't. [*] ROTFL [%] A PowWow user had registered the dialup port IP address, and the PowWow client for a user in Alaska was trying to locate his "buddy" on my system -- several times a minute for hours at a stretch. I've also seen Windows networking name service packets leaking through the terminal server, as well as cracker port scanning attempts. ---------------------------------------------------------------------------- Date: Wed, 3 Feb 1999 09:19:50 -0800 From: Robert Ward To: BUGTRAQ@netspace.org Subject: WebRamp M3 Perceived Bug In response to John Stanley's posting on January 21, 1999. 1) The perceived problem is that upon manualling disabling the diversion of incoming telnet requests to the webramp, and not setting up a Visible Computer, or telnet Local Server, telnet traffic continues to divert to the Webramp. This is largely due to the Webramp's logic. Upon receiving incoming traffic on port 23 the WebRamp checks it's divert port options, notices that telnet diversion is off, then looks for a visible computer or local server to pass the traffic to. Failing this the WebRamp then defaults back to diverting the port 23 traffic to itself. We designed this box with being able to access the CLI or HTTP interface >from the WAN in mind. This feature allows for remote management and trouble shooting of the WebRamp, and has proved to be an essential tool to our support department. If security is a concern change the Administrative password on your WebRamp, and do so frequently. The Divert Port options were never intended to be a security feature, rather they are there so that you can bypass the webramps built in telnetd and httpd and pass packets to your in-house server. 2) This is true for every M3/M3t/M3i/300 user who is not using Visible Computers or telnet Local Servers. I would approximate this number to be in the 90% or higher range. The number of customers who have actively tried to disable incoming telnet sessions that we are aware of is much lower than 1%. 3) There are workarounds readily available. The easiest way to prevent unwanted access to your WebRamp is to change the Admin Password, and as with all things security related, change it often. To completely block telnet access (so that the session can't even be initiated) from the WAN you have two options. Method 1: Enable a Visible Computer for each active modem port and pointing to IP addresses that are not being used in your LAN (e.g. 192.168.1.254 is a good place to start as DHCP is not likely to ever pass it out), and uncheck both of the divert incoming boxes. Method 2: Enable a Local Server of the Telnet and Web type and point them to an IP address that is not in use on your network. Then telnet into the webramp and use the divertport to disable all incoming diversions. This will only work for modem 1. If you are using 2 or more modems use method one. 4) Last but not least, engineering has agreed to incorporate a change in the M3 families code to mimic the 310. This would allow the user to simply check one box to disallow WAN access to the httpd and telnetd processes. Since there are workarounds available, and useability/functionality is not impaired, this is considered to be a priority 4 and may be incorporated in the next point release. Robert Ward Senior Customer Support Engineer Ramp Networks ---------------------------------------------------------------------------- Date: Thu, 4 Feb 1999 13:26:06 -0800 From: John Stanley To: BUGTRAQ@netspace.org Subject: Re: WebRamp M3 Perceived Bug Regarding the subject, am I to assume that since this is only a "perceived" bug, your supervisor of customer service was fibbing to me when he admitted on the phone that this was, indeed, a problem that needed to be fixed? He hasn't called me back like he promised he was going to, nor has he sent me email like he promised he would. Since he's gone mute, are you the official Rampnet spokesman now? On Wed, 3 Feb 1999, Robert Ward wrote: > 1) The perceived problem is that upon manualling disabling the diversion of > incoming telnet requests to the webramp, and not setting up a Visible > Computer, or telnet Local Server, telnet traffic continues to divert to the > Webramp. This is not a "perceived" problem, it actually happens. I would echo your words "manually disabling the diversion of incoming telnet requests to the webramp". When I disable something, it is not supposed to happen. However... > This is largely due to the Webramp's logic. Upon receiving incoming traffic > on port 23 the WebRamp checks it's divert port options, notices that telnet > diversion is off, then looks for a visible computer or local server to pass > the traffic to. Failing this the WebRamp then defaults back to diverting > the port 23 traffic to itself. In other words, the M3 says "the user has told me not to divert port 23 traffic to myself, but I know better than he does where it should go, and he couldn't possibly want anything as important as a telnet connection on port 23 to be ignored. I'll go ahead and make the connection anyway." > We designed this box with being able to access the CLI or HTTP interface > from the WAN in mind. This feature allows for remote management and trouble > shooting of the WebRamp, and has proved to be an essential tool to our > support department. This is a straw man. The complaint is not that you have a way of allowing this remote access to take place, it is that the remote connection WILL be allowed even when you tell the M3 NOT TO ALLOW IT. If there are people who will tell your customer service people their admin passwords and IP addresses via email (as your customer service person wanted me to do), that's their problem. That your box continues to offer a login prompt to anyone who happens by after being told NOT TO, that's the problem. > If security is a concern change the Administrative > password on your WebRamp, and do so frequently. Security says you do not allow connections to services you do not want active, not that you just put a password on them. Security says that you do not give out information about your systems that doesn't need to be known, such as "Hi! I'm an M3 and I'm ready to let you log in, even though you might not be able to." In case you aren't aware of this, there are DoS attacks that don't require passwords, just a connection. I haven't tried any of them against the M3, but given the attitude expressed by Rampnet about this problem, I wouldn't doubt that you can shut an M3 off remotely. I wouldn't doubt that there is a stack smashing expoit of some kind, or who knows what else. And when these show up, they will be branded "perceived" problems and assigned a "level 4 priority". I wouldn't doubt that we will learn as time goes by that there is a backdoor that customer service uses to get into an M3 when the user forgets his admin password. If the ability for Rampnet customer service to connect via the WAN is so critical, it is almost a certainty. Cisco, as I recall, had this problem. The difference is that Cisco did something about it. > I would approximate this number to be in > the 90% or higher range. The number of customers who have actively tried to > disable incoming telnet sessions that we are aware of is much lower than 1%. "It isn't a security problem because very few people see it as one." Remember, this M3 is aimed at a non-technical audience, intended for use by people who are setting up a small office network connection to an ISP using a modem. Most people won't think to try telnetting into their own network, assuming that the boxes that disable diversion mean what they say, or from pure ignorance. _I_ didn't even realize it was happening until I disabled the visible computer and wanted to make sure it really was disabled. > 3) There are workarounds readily available. Yes, I had to waste an evening looking for one. I wouldn't call them "readily" available, however. YOUR technical support people denied that it was happening. Then they told me the commands to use to "fix" the problem, which were actually the commands that caused the problem to appear in the first place. > To completely block telnet access (so that the session can't even be > initiated) from the WAN you have two options. > > Method 1: Enable a Visible Computer for each active modem port and pointing > to IP addresses that are not being used in your LAN (e.g. 192.168.1.254 is a > good place to start as DHCP is not likely to ever pass it out), and uncheck > both of the divert incoming boxes. This is the solution I told you about. Thanks for putting your official stamp of approval on it. Your example address is a bit poor, since 254 is a common address for gateways, and in my case isn't even on my network. > 4) Last but not least, engineering has agreed to incorporate a change in > the M3 families code to mimic the 310. How nice. I suppose a change that results in the M3 ignoring telnet connections when it is told not to divert telnet connections to itself was too much like an admission of a mistake. > This would allow the user to simply > check one box to disallow WAN access to the httpd and telnetd processes. There is already a checkbox that is supposed to do this, at least for telnet. > Since there are workarounds available, and useability/functionality is not > impaired, this is considered to be a priority 4 and may be incorporated in > the next point release. I'm sure I'll rush right out and buy the next "point release". Has anyone else noticed that Rampnet does not provide free fixes, you have to pay for every update to your firmware? Has anyone else noticed that companies like Lantronix provide lots of free support and upgrades to firmware? Now tell me how you are dealing with the problem of counting every packet that comes in the modem as "activity" when it comes to timing out the connection. This IS a usability issue, since your failure to disconnect when there is no activity can lead to excess use charges and, in some cases, inability to connect due to overuse. (Yes, one of the places I can dialup has a quota, and you don't get on after you use more than X hours in a month.) Why do you count a packet from, say, aPowWow client, that comes in the modem and is promptly thrown away BY THE M3 itself, as valid activity on the modem line? Why do you count leaking net-bios packets that have no destination as valid traffic? Right after I reported this problem, I got a few pieces of mail about it. One was from someone who said "yeah, Rampnet support isn't very good." Two were from people telling me this wasn't a problem, both of whom it turned out were Rampnet dealers with a vested interest in protecting the product. One was from the supervisor of customer support wanting to talk to me on the phone. We talked about the problem, which he admitted was a problem, and he promised me all sorts of status reports. I've not heard from him since. Every company is a good company when there is no problem. How they react to problems is how you sort them out. ---------------------------------------------------------------------------- Date: Thu, 4 Feb 1999 19:59:12 -0500 From: Kragen Sitaker To: BUGTRAQ@netspace.org Subject: Re: WebRamp M3 Perceived Bug On Wed, 3 Feb 1999, Robert Ward wrote: > We designed this box with being able to access the CLI or HTTP interface > from the WAN in mind. This feature allows for remote management and trouble > shooting of the WebRamp, and has proved to be an essential tool to our > support department. If security is a concern change the Administrative > password on your WebRamp, and do so frequently. IMHO, when you ship someone a preconfigured machine of some kind, and they don't express any particular interest or knowledge about the possibilities of that machine being controlled remotely, the default should be for that machine not to be controllable remotely -- not for anyone in the world to be able to control that machine remotely. > 2) This is true for every M3/M3t/M3i/300 user who is not using Visible > Computers or telnet Local Servers. I would approximate this number to be in > the 90% or higher range. The number of customers who have actively tried to > disable incoming telnet sessions that we are aware of is much lower than 1%. This is probably a good rule of thumb. 99% or more of the people out there won't even think about security. It's a betrayal, a fraud, an injustice to put backdoors into your products by default, then give people the ability to turn them off -- knowing that more than 99% of them will never use it. Imagine getting a new car. Like more than 99% of car owners, you don't read the owner's manual. After six months, the car's brakes stop working in traffic; it kills your wife and kids, along with the occupants of several dozen other cars of the same model in that city block. You call the manufacturer to complain. "Didn't you read the manual?" they say. "On page 66, it explains that the car is rigged to disable the brakes when it receives a particular radio signal, but you can turn it off with a switch inside the glove compartment. It's not our fault if terrorists use this feature to blow up buildings, and if you didn't bother to read the manual. We put it in to help our mechanics when the brake pedals get stuck." > 3) There are workarounds readily available. . . . which, as you point out, more than 99% of your customers don't even know about, and therefore more than 99% of your customers are wide open. I hope you get your irresponsible sorry asses hauled into court for this, you pathetic slimeballs. -- Kragen Sitaker Computers are the tools of the devil. It is as simple as that. There is no monotheism strong enough that it cannot be shaken by Unix or any Microsoft product. The devil is real. He lives inside C programs. -- philg@mit.edu