Security in open source projects

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= %sn", 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