Programmers are also people who also make mistakes. It’s the first part of our talk with Daniil Svetlov at his radio show “Safe Environment” (or “Safe Wednesday” – kind of wordplay in Russian) recorded 29.03.2017. We were discussing why Software Vulnerabilities are everyone’s problem. Full video in Russian without subtitles is available here.

I added manually transcribed Russian/English subtitles to the video:

• Why vulnerabilities are dangerous for business and for ordinary people?
• How vulnerabilities appear in programs?
• How to write code safely?
• What motivates vulnerability researchers?
• Vulnerabilities as a first step in writing malicious software

We wanted to talk today about software vulnerabilities. Tell me, what is it all about, why are they dangerous for business, for ordinary people and what are the difficulties with their remediation.

Speaking about vulnerabilities, it’s probably worth to tell how they generally appear in programs.

Let’s say we have a company. This company is developing some software. Some programmers work in it. Programmers are also people who also make mistakes. And if some mistakes that are directly related to the functionality of this application, can be detected quite simply in the testing process…

Are you talking about functional testing?

Yes, it is about functional testing.

QA specialists can quickly find these vulnerabilities, or these problems, these bugs. Some problems can not be detected in such a simple way. For example, some problems related to security.

Why? Because the main task of the programmers: the program should work.

And the approach that you should think about security at the development appeared not so long time ago. After all, the Security Development Lifecycle, developed in Microsoft, is not in use everywhere. It is necessary to say directly. And even in large companies, where it is applied, we still see a flow of vulnerabilities that are constantly found in the software. Apparently it does not always work very well.

The programmer makes a mistake in the program. QA specialists do not find it. The product leaves the client. In some form it is used for some time while a researcher, an information security specialist, does not make a research of this product. Also he may find that some values of some parameter are not checked well enough. And by setting some other parameter values in this application, you can get some undeclared functionality. Sometimes very interesting functionality.

And all the time researchers find these problems, these bugs. In some cases, they report this to the developers. In some cases, they don’t.

If the bug is reported, the developers will release an update. They say yes, this is our problem, yes we confirm it. They release updates and tell users: “Upgrade to the new version, the new version is safe” Those who will not update, they will see that the number of these vulnerabilities in the software they use increases, increases, increases each year, each month.

There is an opinion that “I use Windows XP and Windows XP completely suits me.” Or some old version of Photoshop or an old web browser. It completely suits me, I do not want to switch to anything, I do not need any updates. This is a vicious approach. Because yes, maybe the functionality suits you, but the safety of such product becomes worse and worse with time.

Alexander, let’s talk about the economic component of this whole process. After all, as I understand errors in software, they are taken not only because programmers make mistakes. After all, most likely the programmer has a manager who says to him: “Write it faster, we need to add the feature as quickly as possible, by Monday, and no matter how safely you realize it”. Because in fact in order to write a more secure code you need to have the programmer is perhaps more qualified, he may need to write more code, right?

It’s absolutely true, there are even practices how to write code safely.

It is necessary to use vulnerability scanners that are looking for vulnerabilities in the source code. This is a fairly common thing. It is integrated into the IDE and every time you compile the code it shows you that there are some vulnerabilities that can be exploited.

Illustration from PT AI SSDL Edition. Product Brief

There must be some kind of review code. A security specialist should have access to the code to look and say: “Comrade programmer, it may be a vulnerability here, it can be exploited so-and-so.” Well, programmers are learning in the process and next time do not make such errors.

But it certainly makes the development process itself more complex, more expensive, makes it slower. Therefore, there should be some kind of healthy balance.

So, on it will be hard to use it with scrum and agile you want to say?

No, it can be used with both scrum and agile pretty well. But doing it well is expensive and difficult. As always.

Well, look, we get a product that is very quickly programmed, given to the client, the client uses it. And now you say there is a certain security researcher who starts this research. What motivates him in general, why does he sit down and starts checking a specific program for security?

Well, the motivation can be very different. Starting from just curiosity. And for many people, it’s just a job. They do this either on a contract basis, or simply the company orders an audit of its own code. To see how dangerous or safe is to use this application. That is, the motivation of a particular person can be completely different.

If we look at who commits, who adds vulnerabilities to the CVE database, they are very different people. But it is possible, of course, that there is a fairly large part of people who do this for some criminal purposes, but as a rule we do not know about them and do not see them.

We see in some vulnerability database people who decided to report that they found a vulnerability. They revealed some details about this vulnerability. After they reported this to the vendor, the developer had time to fix this vulnerability.

And those who, roughly speaking, black hats, they quite possibly trade exploits for this vulnerability. They use it for themselves and it is used on the black market. And then only, during the analyzing of some malware, researchers may find out what vulnerability been used and only then vulnerability becomes public. Sometimes it happens like this.

So, in fact, this vulnerability, let’s say, is the first step in writing malicious software, malware, and exploits. This is actually a program that exploits this vulnerability and allows you to achieve some goals that are not correct for the system.

Yes, it’s absolutely true. Vulnerability is the root of everything, as I say. Well, every cook praises his own broth. It’s clear that I’m dealing with vulnerability management and vulnerability assessment of the infrastructure, so I think this is the most important.

But really, if, there are some Capture The Flag hacking competitions, they are usually held on a specially vulnerable infrastructure. Try to conduct it on an infrastructure where all the software is completely updated and uses the latest versions. And it uses not some kind of self-written applications with vulnerabilities added, but the usual ones from the real life. It’s clear that this will not be so spectacular at all.

Maybe even not so effective.

Yes, and it will be simply too expensive:no one will demonstrate 0day vulnerability in order to win in some kind of competition.