Slashdot Mirror
CERT Finds Routers Increasingly Being Cracked
alteran writes "CERT has released a paper (PDF) analyzing changes in DOS attack methods. The new twist-- crackers are increasing getting into routers rather then servers and home PCs. The volume of noise a router could generate absolutely dwarfs what a computer could do. And unlike compromised servers, compromised routers could actually screw up the infrastructure of the Internet, not just blast people with packets. Worst of all, router administators appear to be even sloppier than their server counterparts in securing their machines."
Tripwire makes Tripwire for Routers - Tripwire has been in the business of ensuring integrity for your systems for some time. Thet even make the Open-Source version of Tripwire for Servers, Web Pages (Apache) and have a Linux-capable Tripwire Manager (management system for reports) available as well. Definitely worthy of investigation.
P.S. - I don't work for Tripwire, but I do like their products. 8-)
All Ad hominem replies happily ignored as the sender shall be deemed to lack the faculties to comprehend the equation.
from the article:
Intruders had to work hard to deploy large DDoS attacks networks; much
work was done to avoid detection and compromise of deployed attack
networks and to provide for easier maintenance.
OK, here's the dumb question: Who is working so hard? Kids on IRC???
Companies don't hire enough smart people to admin their network. They think that the guy who knows how install Windows would be a good candidate for admining the network.
Most companies and people that run them don't understand what it takes to properly setup and maintain a network.
I think this will/is changing though. The company I work for now takes the network seriously after they narrowly avoided a catastrophic data loss about a month ago. Now that backup solution I was bitching that we needed, has been purchased.
LoRider
You don't need a service contract, you just need to have your router registered with them, and have a Cisco Connection Login. I've got a CCO login tied to a 1604, and I've downloaded/torn apart the code for a 12000GXR. No restrictions, they just don't want everyone on the damned planet with access to their firmware.
We don't actually administer our routers? Our company has some contract through UUnet and the router is actually property of UUnet we don't even have the password to get in and administer it. So if it's comprimised, the blame should be placed on UUnet even though the traffic will look like it's coming from our company.
Things you think are in the Constitution, but are not.
enable
password
config t
line vty 0 1
password 7 (insert password here}
^Z
wr mem
Oh yeah, real hard. 5 lines of commands is super difficult.
A large reason for all this security carelessness is that companies will hire the least expensive person "qualified" to do a job. Those qualifications generally being a buzzword or two on a resume. They will then load that person down with 5 to 10 times more work than he is even capable of, insuring that there is no chance that the slightest hint of security will find its way into the company. Again, the CIO will never catch any flack for this; his choices probably made the company's stock go up in the short term.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Read your /. manifesto. You aren't allowed to like anything that is:
* Packaged slickly
* Designed for ease of use by non-geeks
The volume of noise a router could generate absolutely dwarfs what a computer could do.
Of course, a router is a computer.
I guess this isn't surprising, since they've been targetting DSL and cable Windows boxes as platforms from which to launch DDoS attacks -- moving up to the routers is, I suppose, the next logical step.
SecurityFocus.com has an article by Kevin Poulsen which addresses the issue. He talked to Kevin Houle of CERT. Here's an excerpt:
Good mfences make good neighbors.
Is probably going to be piss poor devices for dsl/cable modem users. Cisco has had real trouble with some of their 6xx series dsl devices. Having 1 million poorly thought out (security wise) $100 devices on decent sized connections (cable/dsl) is probably just as dangerous as having 10000 poorly thought out 10k routers.
We have seen what code red and nimda did to cable modem segments. Cable is somewhat limited with a 2 megabit upstream limit per segment, so the real risk is just the segment blowing itself up, but enough devices on enough 2 megabit segments really starts to add up.
Cable companies need to realize: rushing out crappy cable boxes with insecurities (say to steal extra $$$ channels) is a threat only from smart hackers, and a potential loss of revenue (you don't know if they would buy those channels). Rushing out crappy cable/dsl modems can bring down segments, losing $40 a head across all those customers for that month (while my openbsd firewall was mildly annoyed, nimda brought down my mediaone segment for three full days+ = free month)
ostiguy
ostiguy
Aside from the problem of default and backdoor passwords, there are huge numbers of devices deployed with SNMP enabled and configured with RO/RW community strings as public/private.
Any day now some crew will start distributing 'rootkit' firmware versions of IOS with zombie functionality in the binary.
When there is a critical security hole in IOS, Cisco has been very good about releasing IOS revisions with the fix even to customers without any Cisco service contract.
I do not deploy Linux. Ever.
The NSA has been saying this for a while now.
CERT has been saying this for a while now
Most CCNA's know just enough to get RIP running - and security in cisco manuals doesnt go much beyond passwords and locking your telco closet. They do publish more extensive book son the subject - for a price of course.
Im all for this - hopefully itll force companies to pay more for qualified network engineers. As it stands right now theyre paid 35k their first year out - thats pathetic for the amount of training required to put together large secure networks.
So... how much do you think the number of attacks on routers went up because of this post on slashdot? heh. I think CERT might need to revise their numbers now.
Cheers,
-Alex
You don't need to have a hole in a router for it to be taken over. 90% (guestimate) of the routers of the world do ZERO logging. Which means that an attacker could sit there for hours on end doing a brute force password attack and no one would ever know.
Out of the last 6 companies where I have worked at in the past few years, 2 of them logged connects/logins/attempts. And I know of countless more that have no idea how to enable logging, nor what a syslog is.
So it's not necessary to have a hole in order to get enabled on a router, it just takes patience and a good brute force cracker with telnet capabilities.
The article seems to indicate the use of factory-installed passwords as the problem. There's nothing inherently more vulnerable about routers other than the fact that the people configuring them tend to think of them as peripherals (like a printer) rather than as computers.
That said, how often are Cisco routers vulnerable to this kind of attack? I've set up plenty of Cisco routers and if I'm not using a startup config borrowed from one of my other routers, I'm using the "setup" routine that prompts me for a password. Seems like most admins worthy of the title wouldn't use "password" as a password when prompted.
Though I guess they may be referring to the zillions of low-end Ciscos carelessly dropped into client-sites -- but those are supposed to be centrally managed, right?
Are there tools to detect changes made by crackers? One of my nightmares is a rooted zombie server that looks perfectly normal to me, but had several backdoors inserted...
An integrity checker such as Tripwire is what you want, and !Squalus pointed out that there is a version of Tripwire for routers.
The idea is this: generate secure hashes of all critical files, using a secure, one-way hashing algorithm such as SHA-1 or MD5. If those files are changed, hacked, or even damaged by hardware failures, comparing the old hashes will reveal that the files have been altered.
In practice, it's a little more complicated. Many files will change, or be changed, in the normal course of operations of a system. Imagine, for example, a clueless sysadmin who ran an integrity checker against all files on a system, and then freaked out because the log files had changed. So it is necessary to have clueful admins who will be able to understand which files are critical and can distinguish between proper, permitted changes and hacker intrusions.
As I'm sure you know, such clueful sysadmins are in short supply.
Another issue in some cases, like virus detection, is that the operating system itself must be trusted while the hashing is taking place. There are stealth viruses that can intercept reads to infected files, and make them appear clean. Or at least, there were, back in the days of DOS. In theory, the same thing could be accomplished by hacking a unix kernel.
For more information on secure hash algorithms, the best reference is Applied Cryptography, 2nd ed. by Bruce Schneier. I'm sure Tripwire has plenty of info on their web site, and a search for "integrity shell" or "secure one-way hashing" would, no doubt, turn up scads of resources and references.
Good mfences make good neighbors.
I would think that although major routers being hacked could stall the internet, the real threat STILL exists with computer viruses... at least the real threat economically...
:)
For one, a business can still operate if the network goes down.. that isnt THAT big an issue... ("Sorry fellows, we wont be sending you home just b/c are network is down"), but if the computers that are being operated/worked on could be sending out data and proprietary information... well..
Also, for home users... the kind who trust the benevolence of the economic cookie.. you know which ones: "Save my credit card information" on amazon/barnesandnobles checked, along with "Save login information in a cookie" always selected... all that has to be done is to buy up 5-6 items and send to dummy addresses (random ones) before the normal computer user REALLY cares about viruses.. which makes me ask--> why hasnt it happened before? Why hasnt a major virus (code red and nimda anyone?) made purchases after the computer has gone idle for K minutes using the cookies stored on there?
Anyways, I may be wrong..
everyone running a cisco router should do this.
Restrict access to the cisco vty to a list of known hosts. You can use ssh to get from anywhere to one of the permitted hosts, from there you can telnet to the router. If you have the rackspace available, drop an old 486 running *bsd/linux physically right next to each of your routers.
Add an acl to restrict access to the virtual terminals as follows:
access-list 2 remark vty access list
access-list 2 permit 192.168.0.0 0.0.0.255
access-list 2 permit 192.168.200.0 0.0.0.255
....etc....
access-list 2 deny any
line vty 0 4
access-class 2 in
As with any cisco ACL, be careful that you dont "cut off the branch you are sitting on". If you dont understand what the above ACL does, try it out on a test router before you install it on a router 5 timezones away.
S.E.S.S.D.E.N.E.E.NW from west end of hall of mists
first, we will assume that you have a cisco, IOS based. If you are using something else, there are other ways to secure your system. I place actual commands in "" quotes. Many of these commands are applicable for IOS based switches too.
t ml
m
Juniper, Unisphere, whatever, has similar precautions that you can take.
http://www.cisco.com/warp/public/707/
Common sense should apply. If you are an idiot, then there is no helping you, and please read no further. Just take your router offline so that you do not harm my network when the time comes for you...
Secure the console;
Turn HTTP servicing OFF!!!
If you use the internal web server to configure your router, you are probably not qualified to work on the thing period. There have been a string of exploits to the http server function, and if someone get's your browser history, you are screwed. Use telnet. Same thing for any cisco CBOS based router (DSL, cable, ISDN).
"no ip http server"
If you have a 12000 or some of the higher end routers, you can ssh to it. Lesser routers, such as anything less than a 7500 can only use telnet. This sucks, but it is what cisco offers. (if you have a PIX firewall, ssh is available from version 5+ or something similar). You can always use IPsec if you have the IOS for it.
Require local authentication to the console, add a 15 minute idle timeout, and other good stuff;
"line con 0"
"exec-timeout 15 0"
"logging synchronous"
"login local"
"transport input none"
Same thing for telnet sessions;
"line vty 0 4"
"exec-timeout 15 0"
"logging synchronous"
"login local"
"transport preferred none"
"transport input telnet"
Access list telnet access to special subnets! This is VERY VERY important;
Add "access-class 5 in" where you have the following access list on the router;
"access-list 5 remark VTY.ACCESS.CONTROL"
"access-list 5 remark 10.3.4.1/32"
"access-list 5 permit 10.3.4.1"
"access-list 5 remark 10.22.33.136/29"
"access-list 5 deny 10.22.33.128 0.0.0.7"
"access-list 5 permit 10.22.33.128 0.0.0.15"
Do not forget the aux port;
"line aux 0"
"login local"
"transport output none"
Authentication;
Use enable secret, NOT enable password!;
enable secret blah-blah-blah-md5-encrypted
Make at least one local user;
username bob password goldfish
Use TACACS+ if you can, and if you have multiple routers. Otherwise, just use a local login. Cisco lets you download TACACS+ if you know where to look;
http://www.cisco.com/warp/public/480/tacplus.sh
Encrypt your passwords too;
service password-encryption
Log stuff, and know when stuff happens;
Turn on logging;
"service timestamps debug datetime msec localtime show-timezone"
"service timestamps log datetime msec localtime show-timezone"
"logging buffered 32000 debugging"
Hate log messages on the console?
"no logging console"
Use "term mon" when telnetting to get live logging messages. Use "term no mon" to turn it off.
Synch to an NTP server so you know when stuff happens;
"ntp server 1.2.3.4 prefer"
Get NTP servers here;
http://www.eecis.udel.edu/~mills/ntp/servers.ht
Interfaces;
EVERY DAMN interface should have the following, unless you know better;
"no ip redirects"
"no ip directed-broadcast"
"no ip proxy-arp"
"no cdp enable"
Route RFC1918 traffic to null0. RFC1918 specifies that this traffic should not be routed. I do not know what NANOG's position on it is;
ip route 10.0.0.0 255.0.0.0 Null0
ip route 172.16.0.0 255.240.0.0 Null0
ip route 192.168.0.0 255.255.0.0 Null0
Turn CDP off, if you can. There is little reason to use it;
Turn it off, on ALL interfaces;
"no cdp run"
Turn it off on an individual interface;
"no cdp enable"
Damn, now wasn't that easy? No? Of course not! People who do networking get paid some serious cash, because it is serious business. Put a fool on the console and your business is going to take it in the ass! Way too many businesses let fools take care of their networking, or better yet have nobody do it at all.