Default Passwords and What You Can Do About Them
Many machines and devices on your LAN might still have their default passwords enabled--a decidedly high risk intrusion opportunity. What can you do about it?
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):
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).
|"In a perfect world, software products would generate secure random passwords during install and notify the user."|
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.