Manufacturers: don't hard-code passwords into your devices.

The US Department of Homeland Security is warning of critical vulnerabilities in a computerized control system that attackers could exploit to sabotage or steal sensitive data from operators of the solar arrays that generate electricity in homes and businesses.

The advisory is based on a report published last month that disclosed SQL injection vulnerabilities, passwords stored in plain text, hard-coded passwords, and other defects that left the devices open to tampering. According to researchers Roberto Paleari and Ivan Speziale, the vulnerable management server is incorporated into a photovoltaic products from several manufacturers. Paleari told Ars the flaws were uncovered after Speziale purchased a Schneider Electric Ezylog device for his home that used firmware version number 2.0.2736_schel_2.2.6b.

"All the firmware versions we analyzed have been found to be affected by these issues," the researchers wrote. "The software running on the affected devices is vulnerable to multiple security issues that allow unauthenticated remote attackers to gain administrative access and execute arbitrary commands."

The researchers said they released the report two weeks after sending at least two e-mails to the manufacturer and receiving no reply. Representatives from the four companies mentioned above didn't respond to e-mails requesting comment for this article.

Among the most serious vulnerabilities are bugs that make possible SQL injection attacks, which allow hackers to pass commands to a MySQL database connected to a Web interface. "Thus, attackers can easily leverage this issue to access the content of the SQL table that contains all valid username/password combinations (passwords are in plain text)," wrote the researchers.

The researchers also uncovered several pre-configured passwords, including the string "36e44c9b64," that are hard-coded into the server's PHP file. Typing one of these strings into the password field of the server's login panel will grant access regardless of the corresponding username that's entered. These passwords can't be changed or removed.

Justin W. Clarke, an expert in the security of industrial control systems, told Ars the vulnerable devices are used to manage small to mid-sized photovoltaic installations used in homes and businesses. In addition to providing monitoring capabilities, the devices can also allow users to control the solar equipment.

"If there's solar on a site that has a large-scale control system this is going to be sitting pretty close," said Clarke, who is a researcher with Cylance, a firm specializing in security of industrial systems. "So if this were at a factory and there were bigger control systems, I would not be surprised to see this in a position where you could exploit this device and then gain access to a protected control network."

Other vulnerabilities include command injection and broken session enforcement. The researchers included the following snippet of code, which they said allows an attacker to list the directory contents of a vulnerable machine:

"As the POST parameter is used to build a command-line argument without being sanitized before [submission], attackers can leverage termination characters (e.g., '&') to execute arbitrary commands (e.g., "dir")," the researchers wrote.

As Ars has reported previously, the SCADA (supervisory control and data acquisition) systems that manage much of the nation's critical infrastructure are littered with similarly serious security bugs that have come to be called "forever day" vulnerabilities because their manufacturers have no intention of fixing them.

Last week's report came the same week that Defense Secretary Leon Panetta said the US power grid, transportation system, financial networks, and government all faced serious threats from foreign hackers. He identified possible adversaries as China, Russia, Iran, and militant groups.

"An aggressor nation or extremist group could use these kinds of cyber tools to gain control of critical switches," The New York Timesquoted Panetta as saying. "They could derail passenger trains, or even more dangerous, derail passenger trains loaded with lethal chemicals. They could contaminate the water supply in major cities, or shut down the power grid across large parts of the country."

Brotherhood of Steel didn't have to fight that big battle for Helios One. They could have just hacked their way in.

Seriously, this is just the tip of the iceberg. Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 years and still there are multiple vulnerabilities found every month. So what chance do small software vendors have, and even worse what chance do the embedded device vendors have? Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

if there are silly simple exploits such as hardcoded login info and SQL injections, there are many many more esoteric ones such as buffer overflows. They are not going to be fixed for decades to come.

Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 30 years and still there are multiple vulnerabilities found every month.

Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

if there are silly simple exploits such as hardcoded login info and SQL injections, there are many many more esoteric ones such as buffer overflows. They are not going to be fixed for decades to come.

While it's true that the little guys are more likely to have security issues, plain text or hard coded passwords are just carelessness and outright incompetence. I doubt these kinds of situations will ever be "fixed."

Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 30 years and still there are multiple vulnerabilities found every month.

Face, meet palm. How is it that so many programmers are still unaware of basic security practices?

Because the systems weren't intended for use outside a closed network.

What you don't seem to acknowledge is that good security is a nightmare for troubleshooting remotely. Having a static password means that when someone calls up your company, you can actually do something for them without having them rattle off their passwords. On the other hand, as a security vulnerability it's not much of a concern since anyone who wanted to exploit it would (presumably) need physical access to the machine.

Indeed, many embedded systems (especially SNMP systems) have certain passwords that can't be used remotely. If you want to enter the static superuser password, you need to have physical access to the machine.

And, of course, most mission critical embedded systems don't have passwords at all. The avionics on your plane or the controls in your nuclear plants certainly don't. Because they don't need them. You'd need to very purposeful (and idiotically) connect those to an open Internet connection to exploit this 'security vulnerability'.

Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

if there are silly simple exploits such as hardcoded login info and SQL injections, there are many many more esoteric ones such as buffer overflows. They are not going to be fixed for decades to come.

While it's true that the little guys are more likely to have security issues, plain text or hard coded passwords are just carelessness and outright incompetence. I doubt these kinds of situations will ever be "fixed."

I can see this as the reason:Device Version1.1. Company network guy sets the passwords2. Company user has problem and calls manufacturer.3. Manufacturer asks for password to troubleshoot.4. Company user has to put in a ticket support to get password, or can not remember.... meanwhile yells at manufacturer to fix.*this repeats for manufacturer many times per day.

Device Version 2Manufacturer learns lesson and hard codes a password so he can solve customer issue.*cheers*

Seriously, this is just the tip of the iceberg. Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 years and still there are multiple vulnerabilities found every month. So what chance do small software vendors have, and even worse what chance do the embedded device vendors have? Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

I would check your facts. One of the devices is from Schneider Electric, which is no small company by any definition of the phrase. They're one of the biggest electrical component suppliers in the world. Granted, I don't know how big their software team is, but they're not a small company. Biggest example: they own APC, the big UPS manufacturers.

Brotherhood of Steel didn't have to fight that big battle for Helios One. They could have just hacked their way in.

Seriously, this is just the tip of the iceberg. Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 years and still there are multiple vulnerabilities found every month. So what chance do small software vendors have, and even worse what chance do the embedded device vendors have? Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

if there are silly simple exploits such as hardcoded login info and SQL injections, there are many many more esoteric ones such as buffer overflows. They are not going to be fixed for decades to come.

If you want maximum security while still being connected then every piece of software needs to be designed for security first. Major OS vendors do not do this, they use 3rd libraries because the work load of doing everything from scratch is so high.

Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

if there are silly simple exploits such as hardcoded login info and SQL injections, there are many many more esoteric ones such as buffer overflows. They are not going to be fixed for decades to come.

While it's true that the little guys are more likely to have security issues, plain text or hard coded passwords are just carelessness and outright incompetence. I doubt these kinds of situations will ever be "fixed."

I can see this as the reason:Device Version1.1. Company network guy sets the passwords2. Company user has problem and calls manufacturer.3. Manufacturer asks for password to troubleshoot.4. Company user has to put in a ticket support to get password, or can not remember.... meanwhile yells at manufacturer to fix.*this repeats for manufacturer many times per day.

Device Version 2Manufacturer learns lesson and hard codes a password so he can solve customer issue.*cheers*

Device Version 3

1. Company network guy sets the passwords2. Company user has problem and calls manufacturer.3. Manufacturer says RTFM.4. TFM tells user to disconnect from the network, press the hardware reset button, and then set the password.5. Problem fixed, no future calls happen.

Ah, Panetta trying to gain power through scare tactics, probably learned from Richard Clarke. Here is some information on how difficult it is to derail a train, using explosives not the spooooky iiiinnnnternet.

Seriously, this is just the tip of the iceberg. Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 years and still there are multiple vulnerabilities found every month. So what chance do small software vendors have, and even worse what chance do the embedded device vendors have? Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

I would check your facts. One of the devices is from Schneider Electric, which is no small company by any definition of the phrase. They're one of the biggest electrical component suppliers in the world. Granted, I don't know how big their software team is, but they're not a small company. Biggest example: they own APC, the big UPS manufacturers.

Check what facts? Show me where my references to small vendors directly implied Schneider?

With all the forms of VPNs available now, people need to get better at partitioning their networks so that only certain devices can communicate with them, and then lock those devices down as much as you can, then you don't have to worry too much about everything behind them, just about what is in front of them.

It's not hard, it's fairly easy. People just need to hire the kind of people who understand that and allow them to setup the network in that fashion.

Up until recently, everything was "off the Internet" by default. Someone had to actively 'add the Internet' to these infrastructure communications.

And now it's coming back to bite them in the ass. They may have saved some money on the transport, but the security risks may well outweigh those savings. And when things get really insecure, they'll have to pay even more money to take things back off the Internet.

There is a place for both public and private networks. Important infrastructure should not be exposed to public hazards. (Especially when 'the public' includes foreign enemies.)

Seriously, this is just the tip of the iceberg. Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 years and still there are multiple vulnerabilities found every month. So what chance do small software vendors have, and even worse what chance do the embedded device vendors have? Their one EE with some knowledge of C or C++ wrote the firmware. The end user plugs that device straight into the Internet, and you got a ticking timebomb waiting to happen.

I would check your facts. One of the devices is from Schneider Electric, which is no small company by any definition of the phrase. They're one of the biggest electrical component suppliers in the world. Granted, I don't know how big their software team is, but they're not a small company. Biggest example: they own APC, the big UPS manufacturers.

Check what facts? Show me where my references to small vendors directly implied Schneider?

You just wanted to "correct" someone today. Fucking Internets....

No, I had just assumed that by small vendors, you were referring to all the vendors mentioned in the article. If that wasn't your intention, then I mistook your original post. Sorry about that.

I'm actually shocked that manufacturers still insist on setting up hardcoded PLAINTEXT passwords with no other two-factor auth required. How difficult would it be to give the CSRs a string generating program that performs a one-time auth of the system? Its still really insecure, but not as bad as this.

The hard coded password is a back door. I guess I need to repeat my gate control story. Being a hardcore geek, I insisted on having all documents for an electronic gate that I had a contractor install. Haking the controller, I found the gate installer give themselves a code to open the gate. It is the same code for all their customers. The same code used for years. Thus one can assume if you see their sticker by the gate and you have the code, you can open the gate, provided the owner didn't delete the back door account.

Train tracks have a 900 MHz radio controlled switching scheme. I'm not into it, but the rail fans have the scheme decoded. SCADA can also have wireless control.

Face, meet palm. How is it that so many programmers are still unaware of basic security practices?

It's rarely if ever covered in school.

I do agree. Whenever I think web security I always think of regex. Fortunately for me when I was in college a couple years back there was a class dedicated to fundamental web security and we had to write so much regex that it is now very easy for me to read and write complex regex. I still use it on a daily basis today believe it or not. You would think that given how much cyber-crime has exploded in the last decade alone that security would be just as a top priority as creating an application's basic functionality. It should be second nature for a programmer/developer to validate data, ESPECIALLY where user(s) can enter data and that data be used by the application. I have heard however of other developers/programmers not understanding how such exploits work that they basically don't know how to prevent such exploits. It is quite disturbing IMO. Also IMO, you have to think like a hacker to prevent a hacker.

"The researchers also uncovered several pre-configured passwords, including the string "XXXXXXXXXX," that are hard-coded into the server's PHP file."

Was it really necessary to publish the actual string?? Is the purpose of this article to sound the alarm or to help people hack these systems?

"The researchers said they released the report two weeks after sending at least two e-mails to the manufacturer and receiving no reply. Representatives from the four companies mentioned above didn't respond to e-mails requesting comment for this article."

This is nothing new to the tech world. This is how you force such a company's hand. They were warned in advance, nothing happened. By publishing the information that will force them to act or risk a very negative and potentially worse backlash. I see nothing wrong here and many shouldn't either. Heck, I hope people actually learn from this by seeing how exploits work so simple mistakes such as this are limited if not eliminated.

Major OS vendors with focus on security, can't find and eliminate all software vulnerabilities. They've been at it full-steam for 10 30 years and still there are multiple vulnerabilities found every month.

Try 30...

Windows XP is more than 10 years old by now.

Not really. No one took security seriously until about 2000 or 2001.

LOL? I'm sure Theo de Raadt and the rest of the OpenBSD project would take offense. They've been hard at work since '96.

Why would you need special hardware for the management server for solar panels?

Note that green pork is tea bagger speak for government money spent on alternative energy products.

All solar cells need a controller of some sort. This is especially true if battery charging is involved. You may route some power to the battery and the rest to the grid. More advanced systems have solat trackers to raise the efficiency. With multiple solar panels, you will monitor their current individually to see if the cell array is healthy.

There is a certain irony that the biggest alternative energy proponent is the DoD, even if a big raison detre is that they exist to project power in the Middle East. The DoD needs silent power for remote outposts that are off the grid. The DoD wants to conserve oil so that they can fly their planes. While the tea baggers don't believe in global climate change, the DoD takes it as fact and plans (war games) accordingly. Yet the tea baggers are uber proponents of the DoD. Yhen again, logic and the tea baggers is mutually exclusive.

I wonder if there is a list, maybe not definitive, of these SCADA systems that are vulnerable. I imagine that would cause a number of manufacturers to come out red-faced and attempt to fix their stuff. But more often than not, these systems are not supposed to be connected to the open Internet in the first place.....

Why would you need special hardware for the management server for solar panels?

Note that green pork is tea bagger speak for government money spent on alternative energy products.

All solar cells need a controller of some sort. This is especially true if battery charging is involved. You may route some power to the battery and the rest to the grid. More advanced systems have solat trackers to raise the efficiency. With multiple solar panels, you will monitor their current individually to see if the cell array is healthy.

There is a certain irony that the biggest alternative energy proponent is the DoD, even if a big raison detre is that they exist to project power in the Middle East. The DoD needs silent power for remote outposts that are off the grid. The DoD wants to conserve oil so that they can fly their planes. While the tea baggers don't believe in global climate change, the DoD takes it as fact and plans (war games) accordingly. Yet the tea baggers are uber proponents of the DoD. Yhen again, logic and the tea baggers is mutually exclusive.

I'm not trying to take part in round 9000 of a political debate. I take it for granted that in whatever broad category the government spends money, no matter how necessary some spending in that category may be, some non-trivial amount of that money will go for boondoggles.

So, from this article (following the links didn't enlighten me much) it sounds like these vulnerable products are basically servers. I grant that special software may be needed to control solar arrays, but why does it need specialized server? Thus my suspicion that this category of products is a boondoggle.

Why would you need special hardware for the management server for solar panels?

Note that green pork is tea bagger speak for government money spent on alternative energy products.

All solar cells need a controller of some sort. This is especially true if battery charging is involved. You may route some power to the battery and the rest to the grid. More advanced systems have solat trackers to raise the efficiency. With multiple solar panels, you will monitor their current individually to see if the cell array is healthy.

There is a certain irony that the biggest alternative energy proponent is the DoD, even if a big raison detre is that they exist to project power in the Middle East. The DoD needs silent power for remote outposts that are off the grid. The DoD wants to conserve oil so that they can fly their planes. While the tea baggers don't believe in global climate change, the DoD takes it as fact and plans (war games) accordingly. Yet the tea baggers are uber proponents of the DoD. Yhen again, logic and the tea baggers is mutually exclusive.

I'm not trying to take part in round 9000 of a political debate. I take it for granted that in whatever broad category the government spends money, no matter how necessary some spending in that category may be, some non-trivial amount of that money will go for boondoggles.

So, from this article (following the links didn't enlighten me much) it sounds like these vulnerable products are basically servers. I grant that special software may be needed to control solar arrays, but why does it need a specialized server? Thus my suspicion that this category of products is a boondoggle.

I feel like the same people who decry the security measures put in at airports are overly alarmist about this kind of security threat. It's good that people are researching this, and hopefully the various manufacturers will move towards eliminating some of these threats, but it's hard for me to see this quite as seriously as the article, and many of the posters are portraying it.

I think that the majority of these type of devices are not exposed directly to the internet. And, as another poster noticed, a lot of these devices, even if they were totally compromised, aren't going to lead to much harm.