webramp-M3.txt

`Date: Thu, 21 Jan 1999 01:18:50 -0800  
From: John Stanley <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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.  
  
--  
<[email protected]> Kragen Sitaker <http://www.pobox.com/~kragen/>  
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. -- [email protected]  
  
`