Security in open source projects

Security in open source projects

Transcript

1. FROSCON 2019 SECURITY TRACK Security in open source projects José Manuel Ortega @jmortegac
2. @jmortegac jmortega.github.io about.me/jmortegac
3. CONFERENCES http://jmortega.github.io/
4. CONFERENCES
5. AGENDA
6. AGENDA
7. AGENDA • Security in open source projects • Vulnerabilities in dependencies • Detecting vulnerabilities in code base • Improving security in open source
8. AGENDA Functionality vs security • Security is always a secondary concern • Primary goal of software is to provide some functionality or services • Managing associated risks to software we are developing is a derived/ secondary concern
9. AGENDA Functionality vs security Functionality is about what software should do, security is (also) about what it should not do
10. AGENDA Functionality vs security
11. Coding Flaws • flaws that can be understood looking at the program itself. ◦ confusing two program variables and errors in the program logic • problems in the interaction with the underlying platform or other systems and services ◦ buffer overflows in C(++) code ◦ integer overflows in most programming languages ◦ SQL injection, XSS, CSRF in web-applications
12. • Buffer overflow • Use-after-free • Stack corruption Memory vulnerabilities
13. Buffer overflow // A C program to demonstrate buffer overflow #include <stdio.h> #include <string.h> #include <stdlib.h> int main(int argc, char *argv[]) { // Reserve 5 byte of buffer plus the terminating NULL. // should allocate 8 bytes = 2 double words, // To overflow, need more than 8 bytes... char buffer[5]; // copy the user input to mybuffer, without any // bound checking a secure version is srtcpy_s() strcpy(buffer, argv[1]); printf("buffer content= %s\n", buffer); return 0; }
14. Buffer overflow
15. Know your dependencies • What open source components you are using? • What versions you are currently running, and where? • How these components can be updated, where do you get the update, what do you need to do to install them?
16. AGENDA PACKAGE REPOSITORIES
17. Third-party libraries
18. Third-party libraries Reusable Components = Reusable Vulnerabilities • Attackers are increasingly targeting popular libraries and 3rd party components • Up to 90% of the attack surface of an application may be due to 3rd party code
19. AGENDA DEPENDENCIES
20. AGENDA DEPENDENCIES
21. AGENDA OWASP DEPENDENCY-CHECK
22. AGENDA DEPENDENCY-CHECK
23. AGENDA SNYK
24. AGENDA SNYK
25. Services
26. Services
27. Services
28. Services
29. Package vulnerabilities
30. NPM Package vulnerabilities
31. NPM Package vulnerabilities
32. SQL inyection vulnerabilities
33. Detecting security vulnerabilities
34. Malicious Python packages
35. SAST vs DAST How you can detect security vulnerabilities?
36. STATIC
37. FIND SECURITY BUGS
38. SONARQUBE
39. SONARQUBE
40. SONARQUBE
41. Static Application Security Testing (SAST)
42. Static Application Security Testing (SAST)
43. Security Dashboard GitLab
44. NodeJsScan
45. NodeJsScan
46. NodeJsScan
47. Bandit
48. Bandit
49. Bandit SELECT %s FROM derp;” % var “SELECT thing FROM ” + tab “SELECT ” + val + ” FROM ” + tab + … “SELECT {} FROM derp;”.format(var)
50. Dynamic Application Security Testing (DAST)
51. DYNAMIC
52. AGENDA OWASP ZAP
53. Dynamic Application Security Testing (DAST)
54. AGENDA SQL INYECTION
55. AGENDA SQL INYECTION
56. AGENDA SQL INYECTION
57. Open Source Security What can we do to improve the security of Open Source Software? • We can do all the same things as we do when building commercial software • The big difference is that we have to do it collaboratively.
58. Propietary vs OS vulnerabilities
59. Open Source Security OSS is not more or less secure, but it is different • Typically there are many more people contributing • Sometimes there is a culture of “code is more important than specification” • There may be less market pressure to put security first
60. Open Source Security Security is a process, not a product
61. Software Development Life Cycle
62. Software Development Life Cycle
63. Core Infrastructure Initiative
64. Core Infrastructure Initiative https://bestpractices.coreinfrastructure.org/en/projects/1/0#security
65. Core Infrastructure Initiative https://bestpractices.coreinfrastructure.org/en/projects/1/0#security
66. Core Infrastructure Initiative https://github.com/coreinfrastructure/best-practices-badge/blob/master /doc/security.md
67. Open Source Security
68. AGENDA GITHUB ALERTS
69. Secrets searching on github ◦ Credentials(Cryptographic keys, BBDD credentials, API tokens (AWS), SSH keys) ◦ Infrastructure(Services configuration (DHCP, SMTP, etc),IPs and internal URLs) ◦ Code(Commits, History, Comments, Dependencies, Vulnerabilities)
70. Secrets searching on github • Private keys (id_rsa, id_dsa, *.pfx) • History files (.bash_history and similar) - these often have passwords which were mistyped • Log files (/var/log/*) - again, they often have details you might forget to look for in .htaccess, .htpasswd - Apache directory specific configuration files • web.config - IIS directory specific config file • wp-config.php - Wordpress config
71. Secrets searching on github
72. Secrets searching on github
73. Secrets searching on github
74. Remove sensitive data
75. Remove sensitive data
76. CONCLUSIONS • Open source maintainers ◦ Practice secure code review ◦ Regularly audit your code base for vulnerabilities ◦ Define a process for communication of responsible disclosures
77. CONCLUSIONS • Open source developers ◦ Follow responsible disclosure policies if you are reporting a security vulnerability ◦ Subscribe to the security communication channels of your open source dependencies
78. CONCLUSIONS • Security is a very important aspect of software development. • Measures can be taken to integrate it in the Software Development Life Cycle. • It is possible to effectively integrate security into agile development as well
79. CONCLUSIONS