So last month it was made public that there is a sophisticated new piece of malware that targets a vulnerability in Siemen's SCADA system, used in the command-and-control software installed in the manufacturing plants and critical infrastructures around the world.
A hard-coded default password has existed since before 2008 that was made known in their public forums years ago. Malware authors have constructed a way to use this to their advantage to write hostile code that could infiltrate manufacturing systems to steal secrets from manufacturing plants and other industrial facilities in a sophisticated method of corporate espionage.
This is a very interesting way to weaponize such a vulnerability to covertly exploit Siemen SCADA systems. What's worse is that Siemen's has recommended NOT to change the default password as it may break the software, and impact critical operations tied to the system. Talk about being put in a hard place.
You may not realize it, but a recent security patch (MS10-046) by Microsoft is at the heart of this. A Windows shell vulnerability in .lnk shortcuts is how this was originally found. And this was how this attack originally manifested itself. According to some research at Symantec, this was originally targeted at industrial systems in Iran. Unfortunately, like most pieces of malware, it quickly went out of scope of the original attack and started affecting other systems.
The interesting part of this story for me is how a basic and fundamental piece of secure coding principles and practices was breached here. The fact that the SCADA system uses a hard-coded static password to connect to the MS-SQL database exposes the system to huge risk. And should NEVER have been acceptable. If you ignore how the payload was delivered in .lnk shortcuts, consider how easy it is for any sort of code, or simple human interaction, to gain access to this critical database. This is something we should all reflect on. Static passwords are ALWAYS a bad idea. Both for LOB software. And for logging into your servers and workstations.
At Scorpion Software, we look at the architecture of our software much differently. During threat modeling of AuthAnvil, it was clear to us that static hard-coded passwords are NOT a good idea. To communicate with MS-SQL we use Windows authentication to log into the database from the AuthAnvil web service. And the account we use to do that is a restricted account using least-privilege we create during installation, with the password stored securely using the Windows Data Protection API. The password itself is randomly created during install using the strongest possible password using the password policies of your domain controller. So it isn't known by anyone, and can only be accessed through our restricted account itself.
The result? You don't have to worry about this type of attack vector in AuthAnvil. There are no hard-coded passwords.
What else can we learn from this experience? Where else could we have hard-coded default passwords we should be aware of? Some places to consider include:
- Your network based printers and photocopiers
- Your wireless access points
- Your managed switches
- Your routers and firewalls
- Your PBX system
- Your cable or DSL modem
- Network-based appliances (antispam, proxy servers etc)
- etc, etc
What should you do if they DO have default passwords. Change them! And then add them to your password change management document to properly document and protect them. If you have a password management system, consider adding them in there. Don't have one? Consider storing them securely in your PSA system, or grabbing something like Thycotic's Secret Server and start. There will always be places where you will need static passwords. Places where strong authentication solutions like AuthAnvil just won't fit. In those cases, use a password management system that aligns better with your workflow. You can always protect their system with an AuthAnvil passcode. Secret Server itself can be protected with built in support for AuthAnvil. And systems like ConnectWise and Autotask have built in support for AuthAnvil authentication too.
Still have concerns? Feel free to contact us and we would be happy to discuss best practices on password management.
