Investigating A Security Hole Is...Cracking?

crbee asks: "The other day, I was attempting to view a friend's Web site. After having no luck with www.domain.com, I decided to check domain.com, to my surprise I found a completely unauthenticated session to their ISDN router allowing me to administer and reconfigure it. I then launched a telnet session to the IP address and again got full access, this time with more features. To clarify my findings and to establish the severity of the problem, I telneted to one or two other IP addresses within the same range of the UK based ISP, only to find another customer of the same ISP with an open router. In the spirit of goodwill, I notified the ISP immediately. The response seemed to assume I had been portscanning their customers and I was asked to desist." Why is it that companies always react in the wrong way when someone with security knowledge is trying to help them? Should we start leaving security holes wide open for the skr1pt k1dz or should ISPs lay off of the boilerplate warnings, read the e-mails sent in by helpful hackers, and apply a modicum of common sense when responding back? A cracker most certainly isn't going to mail ISPs telling them about open routers, so why treat the people who do report them with open contempt?

"The ISP's response to my kindness is not really the issue here. They have since mailed me a slightly more grateful response, and even fixed the affected customers' routers. However, it did start a rather interesting debate on a UK industry list about the technical legalities of my actions... OK, I know, and most people saw it was obvious, that my actions were purely innocent and and my response was good practice. However, according to some arguments, technically, the fact that I launched a telnet session to the router, no matter what my intentions were, I was in breach of the Computer Misuse Act (UK). What's the general opinion of Slashdot on this?"

Comments

Makes a difference how you say it

[bug-eyed monster]

I usually play dumb when I report these problem. It's all a question of how you word your notice, try to sound as non-threatening as possible. Don't say: "your routers are open and I can telnet to any node on your network, you should close this up before somebody cracks you!" Instead say something like: "Um, I was trying to get to my friends web-site, and I forgot to type in 'www' before 'domain.com', and I got these weird text that I've pasted at the end of this email. Like, I think your computer's broken. Can you fix it please?" Just report the symptoms and let them figure it out.

Put it another way, it's like when you're having lunch with someone, and they get spinach stuck in their teeth. Unless you're very familiar with them, you don't just point and say: "Bud, you have spinach on your teeth, and also I've notice you don't chew your food enough." You just ignore it or try to make them aware of the problem in a more diplomatic way.

Put it yet another way, let's say you leave your apartment door unlocked and a distracted visitor or neighbour walks in by mistake. You expect them to walk out as soon as they find their mistake, and at most put a note on the door apologizing for their intrusion. You don't expect them to come in and find you in your bedroom and tell you "hey pal you better lock your door, look how easy it was for me to get in!"

Well, it may be stupid....but....

[Chanc_Gorkon]

May be they had a reason for having it the way they do. Also, if you assume you KNOW IT ALL....you are probably mistaken. I will be the first to admit I don't know it all. Would you? I really HATE when someone calls in and tries to tell me what is wrong with my systems. It drives me crazy, especially when they call to tell me something is down (and I am working on it and here). The outsider assume's that they may know why something is the way it is. I get someone caling in that thinks they know everything trying to tell me what's wrong and it ends up being THEIR misconfiguration that causes what they see. Just because you think you know something (and what caused it) is wrong doesn't mean there is! There's more behind the scene that you may not know. They may have been in the process of installing a new router and were in the process of configuring it for the first time(make a change, put it in service to test, take it out....it's up so short of time when your doing this, it's not a security problem). Now this may not have been the case, but it could have been which may have caused that curt message. I, personally, think it's impolite to do something such as this especially if it's NOT your system. Now if you know someone on the other end (sounds like the person in question didn't, except for the friend's website), you could send a e-mail to the person you know. Remember, what you think may be going on may not be going on.

Re:Well, it may be stupid....but....

[raju1kabir]

May be they had a reason for having it the way they do.
. . .
Just because you think you know something (and what caused it) is wrong doesn't mean there is! There's more behind the scene that you may not know. They may have been in the process of installing a new router and were in the process of configuring it for the first time(make a change, put it in service to test, take it out....it's up so short of time when your doing this, it's not a security problem).

It sure is a security problem. The fact that he connected and had full access demonstrates that. He could have inserted rules that would have created a backdoor for him in the future. If that's how you run things, remind me not to hire you.

When you're delivering internet-connected equipment for installation at a customer site, you first connect it in an isolated network, then set up access control and passwords, THEN send it to the site.

As for the matter at hand, there is a big difference between poking around through random strangers' networks hunting for holes, and taking a closer look at a friend's network because you think there might be a problem she should know about. This clearly looks like a case of the latter. Fortunately it would be quite difficult to bring prosecution in most jurisdictions because the prosecutor would not have the support of the victim. It's like trying to prosecute someone for breaking and entering after they're observed climbing through a window - when it's later discovered that the window belonged to their mother's house and they climbed in because they saw a fire in the kitchen.

Re:The telnet was wrong

[Manic Miner]

I can see your point of view, however... From my position as a Sysadmin, a full report of a problem with my systems is much more appreciated (and much more likely to be acted on) than the usual - "your computers are broken"!

I've had all the extreems from "your f*~#ing website is broken - fix it" to "your machine alice appears to be version x of bob which is insecure, you can crack it be doing the following..."

Of the two, I ignored and was pissed off by the first, the second was useful and clear, and I reacted quickly, and thanked the person who made the bug report afterward (having checked the machine for hacks first ;)

It's difficult to know where to draw the line, if someone told me my router was wide open, I'd still assume someone might have broken into it, so the extra telnet wouldn't really make a difference. But the extra information would be useful in solving the problem / believing the person who was submitting the problem.

Re:Security

[Robert S Gormley]

Telstra Big Pond Direct is guilty of this on their "managed routers" - which basically means if you get a router from them (as I did, when I set up my 128K ISDN service, a Cisco 760 series), it has SNMP enabled, with the default community name, so anyone worldwide can snmpwalk your router and find its full config. I tried suggesting to them that they at least make the community name the customers personal ID, but they didn't like it... "Administrative nightmare"... as opposed to security nightmare?

Well, that's another case near and dear to me

[merlyn]

Sounds like parallel elements to my ongoing legal case where I was trying to determine the extent of potential leakage for my client at the time, Intel.