Security in open source projects

Security in open source projects

Security in open source projects

7c4b1ae16723b56facc7a8a8f95aa6ce?s=128

jmortegac

August 12, 2019
Tweet

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