Default Passwords and What You Can Do About Them

This is a rather large security issue that has been (until lately) largely ignored and swept under the carpet. Many vendors have a dirty little secret: they ship software and hardware with default usernames and passwords, some of which they do not tell customers about. Once an attacker knows these default settings they can typically access the software remotely and gain administrative control. This can be extremely dangerous. Consider an attacker gaining access over your switch and routing infrastructure and forwarding traffic from the R&D department to another server. Alternatively, imagine the attacker taking over your remote access devices, such as ISDN routers, and then sniffing passwords as users access the corporate LAN.

"[Default passwords] are a huge problem because companies buy lots and
lots of hardware and software that they need to deploy quickly."

This is a huge problem because companies buy lots and lots of hardware and software that they need to deploy quickly. This often results in minimal configuration effort being made, and the default passwords are usually left in, due to carelessness, or for the simple fact that the people installing it don't know (hardware vendors like 3Com have placed backdoors in hardware so that they can help the customer recover):

"3Com is issuing a security advisory affecting select CoreBuilder LAN switches and SuperStack II Switch products. This is in response to the widespread distribution of special logins intended for service and recovery procedures issued only by 3Com's Customer Service Organization under conditions of extreme emergency, such as in the event of a customer losing passwords."

It then goes on to list several products and their username and password pairs (debug:synnet and tech:tech). These accounts have FULL administrative access, since they can reset the customer's password and so on. While it's very nice of 3Com to be thinking about helping customers, this is not the way to do it. It's like the car dealership putting a lock on the car where all you need to insert is a stiff piece of wire to open the door and start the car, thanks but no thanks. Another classic example is Microsoft's SQL server, the "SA" account's password is left blank. SA stands for Security Administrator, and it has quite a bit of access. Since most MS SQL databases are attached to networks and listening on port 1433, it is trivial for an attacker to attach to the database and do whatever they want to (from running system commands on the server via "xp_cmdshell" to wiping or stealing the contents of your database).

The reason this issue exists is that vendors want to make products easy to deploy, increase ease of use and decrease support costs. When shipping a software or hardware product that has passwords, the cheapest solution is to simply leave them blank or set them with a default password. Ideally, vendors would ship each piece of hardware with a different, hard to guess default password such as "2i3h2323ddf" and tell the customer what it is. Some vendors do this, but it is relatively rare. Ideally with hardware, the vendor should log in to the hardware, generate a random password and then assign it, and print out the password and ship it with the product. For software vendors this is a bit more difficult, as mass producing CD-ROMs is not feasible if every CD-ROM must be different. In a perfect world, software products would generate secure random passwords during install and notify the user. Unfortunately this would also increase support costs and user aggravation, so as with most security issues, ease of use beats out security.

So, these are the existing solutions:



Assign no password and make the user login and create a password. Maybe configure the product so that it does not function until a password is entered. This would be quite effective and would definitely encourage people to put a password in. It would also cause problems, though, when users plug it in and it doesn't work immediately.



Assign a default password and make the user login and change the password. Maybe configure the product so that it does not function until a password is entered. This would be quite effective and would definitely encourage people to put a password in. It would also cause problems, though, when users plug it in and it doesn't work immediately. This is no better then the no- password option since the default password will be widely published at some point. Many vendors opt for this solution, assigning a default password and (usually) telling the user to log in and change it.



Assign a random password and make the user login and change the password. Maybe configure the product so that it does not function until a password is entered. This would be quite effective and would definitely encourage people to put a password in. This would also cause a lot of grief to users, though, since they may lose the paper with the serial number. Some vendors that sell servers with the OS pre-loaded do this to the admin accountsa good idea. One variation would be to put the database online, so when you plug in the serial number, out pops the default password that was assigned. This assumes the serial number was stamped onto the product physically, and cannot be found via the network, etc. This would be a relatively safe option.



Use some other mechanism, such as a token. For a product such as a router, design the authentication to support tokens and preload the product and the token with the same "secret". To login, the user needs the token to create the response to a challenge. This would be expensive, and somewhat difficult for many users, but it would make breaking into the equipment via the network exceedingly difficult.

Ultimately, all these solutions require some degree of user education. You could solve the problem by using a technical solution such as tokens, but this would create other problems (what happens when you lose the token? what about distributed administration?), and is generally not feasible.

A company should have a policy for setting passwords and so on for hardware and software devices and packages that are being installed. The person or group responsible for the item should be given the task of assigning the password, keeping it recorded somewhere (preferably on a machine that is not networked) and generally taking care of the item (such as upgrades, configuration and so on). The password should be recorded, since people leave companies, get run over by trucks, forget things, and so on. Alternatively, if the device supports it, you should use token- or smartcard-based authentication systems. This way you can easily share the PIN number or password needed to access the smartcard or token, but by keeping the smartcard or token physically secure not have to worry as much about someone leaking the PIN number or password. Unfortunately, the vast majority of network- based equipment that can be remotely managed is done so via telnet, which means attackers can easily sniff passwords or hijack sessions.

Attackers can be expected to conduct sweeps of your network looking for devices that are remotely manageable, and then use automated tools to try to log into them using the default passwords. There are two primary methods. The first is to use a tool such as nmap to identify which hosts are up, identify the OS they are running (via TCP-IP fingerprinting), and then try the specific defaults for each device. The second is to simply pound on each device that has telnet open and try every default user and password (if they just wanted to target 3Com equipment, this would be about a dozen username and password pairs). Needless to say, they could very quickly go through your network and hijack any 3Com equipment that still has default passwords left in it. You can also be sure that products like CyberCop and Nessus will integrate these checks into new versions of their software (and of course the bad guys have access to these tools).

So what can you, as a network administrator, do? Well, for starters, check that all remotely manageable devices (routers, switches, servers, etc.) have strong passwords set. Also check the list of default passwords to see if you own any equipment or software listed on it, and also check with employees to see if they have such devices at home, and make sure the issue is made clear (you're not angry at your employees for not setting the password; you want to help themplaying the blame game is useless). Find out who is responsible for each item and make a list (this is a good idea in the long term when you have problems with them). Many IDS systems are easily extensible and you can add checks for the default usernames and passwords such as "PASSWORD" and "CHANGE_ON_INSTALL DBA + ". You should also firewall any access to these devices from the Internet, and if you must manage devices at a remote site, consider using VPN software to create a secure tunnel between your site and the remote one.

"Long term, I think the solution is to implement authentication
schemes that provide stronger control than simply usernames and
passwords."

Long term, I think the solution is to implement authentication schemes that provide stronger control than simply usernames and passwords. Already companies are deploying smartcards, tokens, biometric-based systems and so on. There are also much better mechanisms than telnet for logging into remote equipment. Ideally, support for SSH, Kerberos and other strong authentication systems should be built into products. When buying equipment, ask the vendor if they plan to support such things, and if not, why not. Cisco, for example, now has SSH on their 7200, 7500 and 12000 series equipment. This is a good startas a Cisco customer, you can exert some influence, and if enough customers demand SSH support on other Cisco products, chances are that it will happen.

SecurityPortal is the world's foremost on-line resource and services provider for companies and individuals concerned about protecting their information systems and networks.http://www.SecurityPortal.comThe Focal Point for Security on the Net (tm)