Why Should Every Programmer Think about Security

13 abril 2018
Dmitry Andrianov
Why Should Every Programmer Think about Security
Dmitry Andrianov, a Senior Software Architect at DataArt, highlights the threats posed by hasty launching of new products in the market. He also tells us about ridiculous missteps made by developers that can jeopardize any system, as well as why manufacturers install Wi-Fi modules in electric kettles.

Neglected Risks

One of the most serious challenges faced in IT these days is an obvious fact that a lot of developers are not sufficiently educated in the field of information security.

This relates not to the deep and professional but rather to the most basic knowledge.

Let’s say programmers have a task to create a cool piece of software and execute it.

At the same time they can easily overlook possible attack vectors in their code – they simply are not able to understand how their code paves the way for potential threats.

The basic explanation of this dire situation lies in the area of the general professional culture.

One of the key principles of security is that protection cannot be “nailed” to a ready product, thus making the product secure. For example, it is totally unacceptable to knowingly make a system vulnerable and insecure just because this is an internal system that is expected to be available only on the Intranet (where no significant threats will be posed to the system).

In reality, there also can be internal hackers. And secondly, it is highly probable that one day access to this system will be required from the outside.

As soon as this system has been deployed in the public Internet, it immediately gets vulnerable to serious threats.

Isaak Asimov devised the three laws of robotics, the first of which reads as follows:

“A robot may not injure a human being or, through inaction, allow a human being to come to harm”.

At the same time, he contradicted himself in his novel, "The Naked Sun", where he wrote about imperfection of those laws. They cannot prevent unintended harm – if one robot prepares poison and puts it in a certain place (without a felonious intent), and another robot just brings a glass of poisoned drink to its master (without knowing that it is poisoned), together they commit a murder. Despite the fact that each of them is strictly prohibited from committing crimes against human beings.

“I suppose that was managed by having one robot poison an arrow without knowing it was using poison, and having a second robot hand the poisoned arrow … without its knowing that the arrow was poisoned.”

A classic example of such a duel situation in IT is deploying an insufficiently protected service to the public Internet.

The developer who has written this service understands that the service is protected rather primitively. But they also know that it is an internal service and it will be used in a safe network, so it will remain inaccessible from the outside of the local network.

Let’s assume that the developer has failed to share information regarding possible security vulnerabilities of the service with anyone else, and after a while a new person is assigned to a task of further developing and maintaining the service. Next, the company that owns the service starts outsourcing some development tasks, and now outside developers get access to the system.

At this moment, the server is probed by hundreds of scripts that are looking for system’s vulnerabilities. Brute-force selection of passwords is one of the threats. Most likely, passwords used for a small internal service are very simple, test accounts probably remain intact, and no security guard patches have been installed on the SSH server for the last two years.    

Who is the primary culprit in this case?

Common sense tells us that first of all, we should blame the person who exposed the service to the public Internet – they had failed to provide proper protection to the system.

Though this person might not have known that there was an admin account with an extremely simple password (test) or that the developer left a diagnostics page on a specific URL that was not protected by a password. If the first developer had not skimped on security and had ensured maximum protection of the system, subsequent security issues could have been avoided.

For this reason, we need to take care of system’s security from the first day of development of the system (the so called security in depth approach).

Few think of such things, usually programmers don't see "security implications" of their work. Not because they are silly or lazy, many of them just have never had to deal with security issues.

Let’s assume that a junior developer has written some part of the program, polished and tested it for two days. Now they are certain it’s perfect. On the other hand, a senior developer only needs to look at this code to see a bug. A senior developer does not have to test or check anything – they can just tell on the spot under which condition the system will break.

The “neural network” of a skilled developer is much better trained in the domain area and they can easily discern and predict system behavior patterns (immediately, without a second thought).

At the same time, the same skilled developer might completely overlook a tremendous security hole that they have just created.

Their “neural network” is highly trained, but it is trained on issues other than those related to security, so they simply fail to see a big threat to it.

If someone would drop a hint about the threat, they would quickly understand everything. However, frequently they miss the vulnerability if they are completely on their own.

There is a separate discipline called Threat Modeling that helps identify potential threats and the most likely attack vectors. It also determines the value of assets that are at risk of being lost as a result of those attacks. It can be taught not only in close relation to IT – however, programmers (no doubt) are required to gain conceptual understanding of its basic methodologies (that surely constitute an indispensable part of the most basic knowledge in IT).

It is also absolutely necessary that developers know typical vulnerabilities. They need to be aware of possible errors, and how other people can take advantage of those errors to crack systems.

I assume that most of the developers know what buffer overflow is and why, when writing in the C language, we should not use standard library functions that write data to a buffer without limiting its length. The answer is simple: in a service with open registration, some user can try to create a name whose length will overrun the buffer's boundary. As a result, the processor might be forced to carry out their commands, not yours.

This case seems to be worn to the bone – the problem has been known for decades.

Nonetheless, these days you can easily find a fresh open-source project on GitHub with the first line that will write an unlimited text to a fixed-size buffer where out-of-control application data (data provided by users) is used as input.

It seems to me that the industry has already lost hope that developers will learn to provide effective protection against buffer overflow. Therefore the main direction in dealing with this problem these days is to make it simply impossible – hardware protection against execution of code from stack or built-in protection against accessing or overwriting data in any part of memory in high-level languages.

Although the C language is steadily losing its popularity, it is still widely used and almost uncontested when it comes to built-in devices and IoT since nothing else will work on a weak processor.

In Java, such a weak spot as buffer overflow is nonexistent. But whatever language you use, it is actually possible to find a trivial weakness in it. It might be a server that returns a file from the upload-catalogue with a name where it is possible to append ../../.. to the file name and, thus, go beyond the upload-catalogue’s boundaries.

Similar problems have been seen for many years so we might suggest that in 2018 there should not be any application that will allow these tricks to be pulled off. But, in fact they still keep being “successfully” pulled off.

For this reason, I think that security training is of great importance for developers. First of all, developers should be told about the most common cracking techniques. Only when they have gained this vital knowledge, they will able to discern security vulnerabilities in their code.

Dangerous Connections

Internet of Things (IoT) is a very general term. It can be applied to any network of devices connected to each other. In any case, we often speak about IoT this way, although in real life all those smart sensors and devices that we buy and install in our houses are connected to a cloud infrastructure (not actually to each other) where they send their reports and from where they receive commands.

If smart devices installed in your house are made by different manufacturers, it is most likely that they send information from your house to their respective (manufacture related) clouds. So a smart house can send a lot of information to different addresses (let’s say to 4 of them). And, you probably do not even worry what data is sent and to whom (you can read a brilliant article on this topic at Gizmodo).

Nobody worries because people don't usually put much value on data transmitted by smart devices. Who cares about the humidity level in your bedroom, scale on your teapot, the water temperature that you prefer in your bath, or time when you turn on/off lights in your living room. However, the latter, at least, can tell any interested person (someone who might be not trustworthy) when you are expected to be absent from home.

Let’s say it becomes dark at six o'clock in the evening, and the light is usually turned on at seven. It is quite easy to conclude that there is a high probability that you will not arrive home until seven.

Recently there was a “fat” scandal with vibrators that could be remotely operated (the purpose is not quite entirely clear) through an iOS application. Users discovered that remote-controlled application was recording sound files and stored them on their phones. Some feared recordings of their sessions were sent to the servers through the Internet-connected and Bluetooth-enabled applications. Despite being actually of low value, such revelations of their private life could seriously offend users.

The analysis of information obtained from various devices installed in your house can give almost the full picture of your everyday life, your habits and preferences. I don't really believe that all home devices need to have an Internet connection. In any case, for example, I don't want my gas boiler to be able to ignite on having received an external command from a cloud.

Ready to Work, Defense, and Standards

It would be great if a smart bulb that you have just bought would integrate smoothly into your smart house.

But in real life there is a high probability that this bulb implements manufacturer-specific standards protected by patents and can work only with its own application. So you would need to install a dozen of applications to control bulbs of different manufacturers.

Apple, Google, Amazon make commendable efforts to introduce a standard smart home API compatible with any device, so that a single application (let’s say, any of Amazon’s applications) could monitor and operate all devices in your house, understand their types, and successfully act as an interface between the end user and a cloud.

In IoT, the aspiration to bring the latest (no doubt absolutely ingenious) device to the market as soon as possible is especially evident.

The question of standards goes therefore into shadows (it is at least of secondary importance) – the mere fact that an application can somehow control the device is enough for the producer to be totally happy. Later the application might be extended with some new functionality (for example, integration with Amazon Alexa to add voice control to it). But this is rather an example of afterthought.

It would be much more simple to implement standards from the very beginning. But the question is whether manufacturers are really interested in it.

Perhaps, some vendors in fact want their devices to send data to their own clouds where they have access to the data and are able to analyze it (to better understand consumer behavior from a marketing perspective or for any other reason).

For example, if a company is a supplier of thermostats, they might be very interested in gathering statistics about when customers switch on/off their devices, what temperature is considered to be optimum by the customers, etc.  

Based on these statistics, the company will get a comprehensive picture of client preferences depending on the region and identify the main user types (there will be rather few of them).

Then the company can offer various pre-installed device presets (tailored to individual’s specific needs and habits) with self-explanatory names: office employee, freelancer, etc.  

As a result, customers will be able to save their time and, probably, their money (if, for example, a preset is offered along with a special electricity tariff plan) by just selecting the user group which they belong.

Weak Link

These days producers of household appliances tend to connect all of their new devices to the Internet. I was very surprised to learn that an ESP32 microcontroller (there are also earlier versions including ESP8266) costs less than a dollar. It is positioned in the market as a system on chip with integrated Wi-Fi – basically, it is a tiny processor with built-in memory and Wi-Fi module. It only costs a penny and is big as a penny! How can a producer of microwave ovens resists the temptation to “stick” it into their products! And how many opportunities it opens for irons!

It is unlikely that producers pursue any definite, immediate purpose but rather test the waters.

It is worth recalling a story of how the Apple watch was created. I am almost sure that in first release of the device nobody exactly knew which of its features would hit the target. Apple “shot” in all possible directions: identification, contactless payments, sport features, etc. (anything that can go through people’s minds).

By the time of the third release, Apple had probably gathered some statistics on device usage and gained better understanding of users’ preferences. Therefore, the presentation of the third model of Apple watch looked more like a presentation of a sport accessory than of anything else.    

I think that producers of household appliances follow this well-trodden path to better tune into users’ specific preferences.    

Why on earth does a washing machine need to be connected to the Internet!

I see only one plausible explanation for that: it will be able to diagnose itself on its own and report in advance its potential malfunction to the customer service. It, perhaps, might prove useful.

But the producer will certainly tell you about one million of other undoubtedly indispensable functions that you will enjoy if your washing machine is connected to the Internet. Of course, you will be able to start it remotely from your smartphone (welcome to just another application!).

Why do I see the steadily growth of adoption of connected (without need) devices as a looming problem?

A coffee machine can also connect to the Internet to learn the latest prices of coffee or exchange rates. And, though it would rather not reveal many of its owner’s secrets, it might pose another problem: any chain is as strong as its weakest link.

I mean, if your coffee machine will be cracked, all of your other 25 connected (and unhackable) household appliances will be instantly in serious jeopardy.  

If someone has managed to crack any of your smart devices connected to your house network, it would not be an exaggeration to claim that they have in fact broken into your house, more likely with ill intentions, where they can inflict lots of damage.

A similar situation occurred with an electric kettle. Its producer used a chip with an embedded Wi-Fi module that used TELNET default password. After connecting to the kettle, Wi-Fi key could be obtained easily by running just two commands.    

Basically, the more connected devices you have in your house, the more attack vectors exist (the attack surface is made larger – every point of network interaction is a part of the attack surface).

For example, a device has a mechanism for automatic migration of configuration data. If this device breaks down and is replaced with a new one, all local environment data (keys, passwords) will automatically be migrated to the newly installed device, thus, saving you trouble of configuring it from scratch.

But, if security flaws are found in the migration mechanism, then someone who is walking past your house can trick the device into transmitting sensitive configuration data also to them.  

The problem is that an average user, as a rule, doesn't know what their device is capable of.

Your device might have only one control button and perform only simple actions, so common sense tells you that the device poses rather no threats.

But let’s assume that this device accepts commands via Bluetooth and its diagnostic mode is not disabled…

The question is whether we can always trust security testing of household appliances performed by their manufactures. And can we be 100% certain that this testing has actually been performed?


Smart refrigerators are unlikely to “enslave” us in the nearest future (although I cannot vouch for coffee machines). But any of us can easily lose all passwords through the courtesy of the most primitive sensor installed in their apartment. In parallel with the security problems, we can face another type of problems (that are not absolutely identical to security ones) - your privacy can be at risk.

Smart houses continuously observe and monitor their owners, as a matter of fact, gathering data is one of the major responsibilities of smart devices. If this data ends up in the wrong hands, benign observation automatically turns into espionage (with possible far-reaching implications for the house owner).