Top 10 Security Misconceptions in Software Engineering

BY MARKUS SPRUNCK

Software security was always one of my second most important topic, but I had to change my mind. And this after more than 20 years in software development in different roles as software developer, manager and IT architect.

Last year I attended a penetration-testing training, and it was just mind-blowing to see how easy it had been to hack a small web software with modern tools. It is one thing to know vulnerabilities in theory, but it is a completely new experience to use state of the art penetration testing tools.

The following article describes the most important misconceptions of software developers concerning security. It is a very personal list, but I discussed it with many other IT specialists and it should be more or less representative. Please feel free to give me a comment about your experience and ranking.

We Developers Know the Important Vulnerabilities

Just do a short self assessment...

Are you sure that you know all the vulnerabilities in the current OWASP Top 10 list by heart?

Your answer is:

A) No, just proceed reading

B) Yes, this is good, but there are many other vulnerabilities that are not in the short list. Additionally this list is just about web applications - in the mobile area and/or IoT there are many other possible security issues. Nevertheless, you should also spend more time with security

Check the total numbers of new vulnerabilities per year ...

Comparing just the last four years shows that there are many new vulnerabilities, so we have a moving target when we learn about security. There is an important statement from the OWASP team: "Change has accelerated over the last four years", see [OWASP-TOP-10]

...and spend some time with your technology stack

Know the technology behind a possible target application. It is a good idea to search for weaknesses in a Cybersecurity Vulnerabilities and Exposures (CVE) Database. I'm sure you will find many issues you never heard of in your life - at least this happened to me.

Hackers Have to be Highly Skilled

Even script kiddies can be dangerous with the right tools...

…you may start with nikto to determine the server type

„[…] performs comprehensive tests against web servers for multiple items, including over 6700 potentially dangerous files/CGIs, checks for outdated versions of over 1250 servers, and version specific problems on over 270 servers.“ [NIKTO]

…or searchsploit to find vulnerabilities in an exploit database

searchsploit 'apple macOS 10.13' -w

..or you may follow link from searchsploit for more details

website is like Stackoverflow for hackers [EXPLOIT-DB]

…or use hydra to crack the password based on lists

hydra -t 4 -f -l admin -P top-pw-cracking-list.txt localhost -s 8080 http-form-post "/marathon/secured/j_security_check:j_username=^USER^&j_password=^PASS^:Wrong"

…here you find some user name and password lists for hydra

… for web applications zap is the right tool to to find first vulnerabilities

… now with the SQL Injection vulnerability, we may use sqlmap to get credit card data:

sqlmap --flush-session -u http://localhost:8080/marathon/showResults.page?marathon=2

sqlmap -u http://localhost:8080/marathon/showResults.page?marathon=2 -D PUBLIC --tables —columns

sqlmap -u http://localhost:8080/marathon/showResults.page?marathon=2 —sql-shell

Just Web Applications Need High Security

…start with dataflow and do a taint analysis

In the following code (see Figure 11) the variable value is tainted by the untrusted source request parameter. In line 9 also message has been tainted after concatenating the variable value. In this case the servlet response is the sink for the vulnerability.

… don’t stop thinking in the web frontend

Data in all files, tables, messages, etc. can be tainted. Reporting and/or backend systems which read from the tainted data sources could also be attacked.

Quite often the use of unchecked input has no effect in the frontend system. In many cases just the backend-systems are affected, because here no security audit happens and the developers are not aware that they may handle tainted data.

Not Relevant for Mainframe

Weaknesses...

1. Legacy COBOL and/or PL1 code is not prepared for modern attacks

2. Don’t forget that also on mainframe a heap overflow works properly

3. Modern Frameworks and Java may run on mainframe with all known problems

4. Quite often the technical users have extensive user rights

5. Tainted data can harm secondary open systems (backend systems)

Although the mainframe is not always the direct target of an attack, the mainframe will spread the disease.

No Additional API Security is Needed with SSL

… never blindly trust what comes encrypted

The ZAP may automatically create an SSL certificate for each host you access, signed by ZAP’s own Certificate Authority (CA) certificate. Your web request can contain manipulated data, even if the transport path is "secured".

System Patches are Always Up-to-date

…is our change management process fast enough?

Investigations show that after disclosure of zero-day vulnerabilities, the volume of attacks exploiting them increases by up to 5 orders of magnitude. So, you have to react very fast, because hackers are also very fast to use new exploits. Quite often the release management processes for frameworks and application servers update just within weeks not hours.

Code Analysis Tools Report Most Issues

Strengths...

1. Scales well - can be run on lots of source code and can be run repeatedly

2. Useful for things that such tools can automatically find with high confidence

3. Output is good for developers

Weaknesses...

1. Many types of security vulnerabilities are very difficult to find automatically

2. High numbers of false positives

3. Frequently can't find configuration issues, since they are not represented in the code

4. Difficult to 'prove' that an identified security issue is an actual vulnerability

5. Many of these tools have difficulty analyzing code that can't be compiled

Find more OWASP Wiki „Source Code Analysis Tools“ [see SAST] including a list of tools with short description.

Penetration Testing Proves Security

None of the techniques are 100% bulletproof...

The following testing techniques that can be employed when building a testing program:

1. Manual Inspections & Reviews

2. Threat Modeling

3. Code Review

4. Penetration Testing

„Penetration testing is a technique commonly practiced by computer security specialists, but its power

is limited when it comes to software.” [McGraw]

Tools Prevent From Attacks

Maybe you know the following joke:

"What's the difference between a physician, a surgeon, and a pathologist?

The physician knows everything and can do nothing.

The surgeon knows nothing and can do everything.

The pathologist knows everything and can do everything, but always too late."

...the same is true with monitoring

Most tools are just to late, even in the case immediate automated defence measures can be triggered.

Don't get me wrong. There is nothing like 100% secure infrastructure and software, so we need security information and event management (SIEM) solutions to do the last line of defence.

Yes, there are high sophisticated tools for security monitoring, advanced threat detection, forensics and incident response and a wide range of security analytics use cases. Some of these tools can even trigger counter actions and support the security analyst in and excellent way.

Specialists Ensure the Security your this Enterprise

There are some security specialists, but they don’t work in every project and seldom see the code. It’s your job as software developer, IT architect or manager to foster secure software development.

Conclusion

• All the 10 misconceptions reasonable and important - there is just one which is not really true. Hackers have to be highly skilled, but just to get away with it

• Software developers and IT architects need awareness of possible security issues. We are the first line of defence

References

[OWASP-TOP-10] https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

[CVE DETAILS] Common Vulnerabilities and Exposures; https://www.cvedetails.com/browse-by-date.php

[EXPLOIT-DB] https://www.exploit-db.com

[SEC-LISTS] https://github.com/danielmiessler/SecLists/tree/master/Passwords

[SAST] https://www.owasp.org/index.php/Source_Code_Analysis_Tools

[NIKTO] https://en.wikipedia.org/wiki/Nikto_Web_Scanner

[Bilge and Dumitras] Leyla Bilge and Tudor Dumitras; Before We Knew It: An Empirical Study of Zero-Day Attacks In The Real World; October 16–18, 2012, Raleigh, North Carolina, USA; http://users.ece.cmu.edu/~tdumitra/public_documents/bilge12_zero_day.pdf

[OWASP ZAP] https://github.com/zaproxy/zaproxy/releases/download/2.6.0/ZAPGettingStartedGuide-2.6.pdf

[McGraw] Gary McGraw, Beyond the Badness-ometer; http://www.drdobbs.com/security/beyond-the-badness-ometer/189500001