Reportando vulnerabilidades

en proyectos Open Source

Santos Gallegos - [email protected]
@stsewd

$ WHOAMI

Web developer
Ethical hacker
@stsewd - https://stsewd.dev/

Contribuyendo a proyectos open source

Código
Documentación
Traducciones
Reportando bugs

Contribuyendo a proyectos open source

Reportando

vulnerabilidades

Seguridad en

proyectos

Open source

https://snyk.io/reports/open-source-security/

Seguridad en proyectos Open source

Vectores de ataque

Acceso no autorizado al repositorio
Acceso no autorizado a la cuenta de un maintainer
Código malicioso en un pull request
Supply chain attacks

Seguridad en proyectos Open source

Vulnerabilidades introducidas de manera no intencionada

Hoy vamos a enfocarnos en bugs que se introducen de manera no intencionada, y que pueden llevar a una vulnerabilidad que podría comprometer la integridad, confidencialidad, o disponibilidad de un sistema. Esto puede ser por desconocimiento, o por descuido. Errores pasan. Somos errores, todos cometemos humanos. Los otros tipos vulnerabilidades también se pueden reportar, y seguir el mismo proceso, en realidad, gran parte del proceso que vamos a ver se puede aplicar a proyectos que no son open source. Y para poder seguir presumiendo de la seguridad de los proyectos open source, es importante que ayudemos encontrando, reportando y arreglando vulnerabilidades. Incluso antes de que sean publicadas en un nuevo release, haciendo review de los parches. Entre más ojos mejor, la prevención es importante, y hasta el uso de herramientas como fuzzers, scanners, y linters.

Ejemplo 🐞

Vulnerabilidades introducidas de manera no intencionada


            import subprocess

            def clone(repo, destination):
                # Código vulnerable a code injection.
                subprocess.run(["git", "clone", repo, destination])

            # Esto no funciona
            clone("; touch /tmp/pwn;", "...")

            # Esto si!
            clone("--upload-pack=touch /tmp/pwn", "file:///foo")

Ejemplo 🐞

Vulnerabilidades introducidas de manera no intencionada


            import subprocess

            def clone(repo, destination):
                subprocess.run(["git", "clone", "--", repo, destination])

            # Esto no funciona
            clone("; touch /tmp/pwn;", "...")

            # Esto tampoco!
            clone("--upload-pack=touch /tmp/pwn", "file:///foo")

https://github.com/gitpython-developers/GitPython/pull/1518

Reportando

vulnerabilidades

Confidencialidad

Mantener la confidencialidad durante todo el proceso es importante

Confidencialidad

Lo que no debemos hacer

Contarle a todo el mundo
Publicarlo en redes sociales como LinkedIn o Twitter
Crear un issue o PR en el repositorio

Verificación

Asegúrate que la vulnerabilidad sea real

Verificación

Asegúrate de usar la última version o una versión soportada
Lee la documentación del proyecto
Reproduce la vulnerabilidad en un entorno aislado
Asegúrate que el origen de la vulnerabilidad sea el proyecto que vas a reportar

Puede que la vulnerabilidad ya esté arreglada en la rama master o main del proyecto. La última versión disponible en repositorios como npm, pypi, etc, puede que no sea la última versión proyecto, revisa el lugar donde está alojado el código, como GitHub o GitLab. Lee la documentación del proyecto, puede que este caso ya esté documentado o tenga una explicación, o advertencia sobre su uso. Asegúrate que lo puedes reproducir en un entorno aislado, y que no sea un problema de tu entorno. Aunque puede que sea válido si el bug solo se puede reproducir en ciertas condiciones. Asegúrate que el origen del bug sea en el proyecto donde lo vas a reportar, y no en una dependencia. Otra vez, puede que sea válido si el bug solo se puede reproducir en ciertas condiciones.

Ejemplo 🐛

Vulnerabilidades bajo ciertas circunstancias


          urlpatterns = [
              # Vulnerable a cache poisoning bajo ciertas circunstancias.
              re_path(
                  r"^account/security-log/",
                  UserSecurityLog.as_view(),
                  name="user_security_log",
              )
          ]

Cloudflare only caches based on file extension and not by MIME type. The Cloudflare CDN does not cache HTML by default.

https://developers.cloudflare.com/cache/concepts/default-cache-behavior/#default-cached-file-extensions

Este es un ejemplo de un proyecto hecho en Django, Lo que esto hace es que mapea la ruta /account/security-log/ a una vista, esto lo hace usando una expresión regular. Este código es vulnerable a cache poisoning bajo ciertas circunstancias. Qué pasaría si le agregamos un CDN como Cloudflare, para mejorar el performance de nuestro sitio web, cachear contenido estático, como imágenes, css, js. CF es muy bueno en ello. Esto es extraído de la documentación de CF. Nos dice que por defecto aplica el cache por extensión de archivo, (entre ellas js, css, imágenes, etc), y también nos dice que no aplica el cache a HTML por defecto. Lo cual es genial! No queremos que todo el mundo vea el contenido de la página de otros usuarios.

Ejemplo 🐛

Vulnerabilidades bajo ciertas circunstancias


          urlpatterns = [
              # Vulnerable a cache poisoning bajo ciertas circunstancias.
              re_path(
                  r"^account/security-log/",
                  UserSecurityLog.as_view(),
                  name="user_security_log",
              )
          ]

Cloudflare only caches based on file extension and not by MIME type. The Cloudflare CDN does not cache HTML by default.

https://developers.cloudflare.com/cache/concepts/default-cache-behavior/#default-cached-file-extensions

Ejemplo 🐛

Vulnerabilidades bajo ciertas circunstancias


          urlpatterns = [
              # Vulnerable a cache poisoning bajo ciertas circunstancias.
              re_path(
                  r"^account/security-log/",
                  UserSecurityLog.as_view(),
                  name="user_security_log",
              )
          ]


          $ curl -I https://example.com/account/security-log/
          HTTP/2 200
          cf-cache-status: DYNAMIC

          $ curl -I https://example.com/account/security-log/foo/bar/
          HTTP/2 200
          cf-cache-status: DYNAMIC

          $ curl https://example.com/account/security-log/foo/bar.js
          HTTP/2 200
          cf-cache-status: MISS

          $ curl https://example.com/account/security-log/foo/bar.js
          HTTP/2 200
          cf-cache-status: HIT

Lo que nos lleva a la vulnerabilidad. Aquí vemos un request normal a la página, CF nos retorna este header indicando el estado del cache para esta página. En este caso nos dice DYNAMIC, que significa que el cache no aplica a esta página. Aquí vemos que si le agregamos cualquier cosa a la URL, el servidor nos retorna la página, este es debido a que en la expresión regular no estamos validando el final de la URL, toda URL que empiece con /account/security-log/ va a ser mapeada a la vista. Pero aún vemos que la página no está siendo cacheada. Gracias a que CF no aplica el cache a HTML por defecto. Pero que pasa si le agregamos .js al final de la URL? CF va a aplicar el cache, ya que la URL termina en una extensión de archivo que CF aplica el cache. En este caso tenemos MISS que significa que el cache aplica a esta página, pero no fue encontrado, pero la siguiente vez que hagamos el request, el contenido de la página va a ser servido desde el cache, y no desde el servidor. Con esto podemos hacer que un usuario logeado ingrese a esta URL, y su contenido sea agregado al cache de CF, luego de que el usuario ingrese a la página, el atacante ingresa a la página, y el contenido de la página del usuario logeado es servido desde el cache de CF.

Ejemplo 🐛

Cache poisoning

Ejemplo 🐛

Vulnerabilidades bajo ciertas circunstancias


          urlpatterns = [
              # Vulnerable a cache poisoning bajo ciertas circunstancias.
              re_path(
                  r"^account/security-log/$",
                  UserSecurityLog.as_view(),
                  name="user_security_log",
              )
          ]


          $ curl -I https://example.com/account/security-log/
          HTTP/2 200
          cf-cache-status: DYNAMIC

          $ curl -I https://example.com/account/security-log/foo/bar/
          HTTP/2 404
          cf-cache-status: DYNAMIC

          $ curl https://example.com/account/security-log/foo/bar.js
          HTTP/2 404
          cf-cache-status: DYNAMIC

https://github.com/readthedocs/readthedocs.org/security/advisories/GHSA-7fcx-wwr3-99jv

Política de seguridad

Contacto

Busca la política de seguridad, contacto, o medio adecuado para reportar la vulnerabilidad

Política / Contacto

Repositorio del proyecto

SECURITY.md
SECURITY.txt
README.md

Política / Contacto

Documentación o web principal

Realiza una búsqueda: security
https://github.com/.well-known/security.txt

Política de seguridad

¡Léela!

`404`

`Contacto Not Found`

Pregunta por el contacto en el repositorio

Issue tracker
Lista de correos

¡Recuerda no incluir detalles de la vulnerabilidad!

Busca un email de algún maintainer

Documentación
Historial de commits

Asegúrate de que es la persona correcta antes de incluir detalles de la vulnerabilidad.

Reporte

Al final de la búsqueda, deberíamos tener un email o plataforma donde reportar la vulnerabilidad de manera confidencial.

Reporte

Incluye la mayor cantidad de información posible

Líneas de código afectadas o vulnerables
Proof of Concept (PoC)
Impacto
Sugerencias de como arreglar el bug

Reporte

Recuerda...

Confidencialidad
Sé paciente y amable, los maintainers son voluntarios
Como todo tipo de contribución, reportar una vulnerabilidad es una contribución voluntaria*

Cuando hayas enviado el reporte, puede que tengas una respuesta en un par de días en el mejor caso. Recuerda no publicar nada hasta que la vulnerabilidad haya sido mitigada y publicada. Recuerda, que al menos que el proyecto sea de alguna compañía, los maintainers son voluntarios, nadie les paga por mantener el proyecto. Sé paciente y amable, puede que la persona de contacto no esté familiarizada con el proceso de reportar bugs de seguridad (en su mayoría son developers), así que trata de no usar jerga de seguridad, y explica todo lo mejor posible. Trata de hacer la vida de los maintainers lo más fácil posible. Ahora, ahí puse un asterisco, y es que si hay proyectos open source que ofrecen recompensas, usualmente son de empresas, pero también hay proyectos que no son parte de una empresa y ofrecen recompensas, como el programa Internet Bug Bounty. https://hackerone.com/ibb. Ahí están proyectos como Django, Ruby, Node.

Confirmación y

Mitigación

Una vez que la vulnerabilidad haya sido confirmada, el siguiente paso es arreglarla.

`404`

`Confirmación Not Found`

Puedes hacer tu reporte público luego de 90 días, es el estándar de la industria.

Divulgación

Pública

Los maintainers tienen la opción de reservar un CVE para la vulnerabilidad si lo consideran necesario.

Está bien pedir o recordar a los maintainers que te acrediten por reportar la vulnerabilidad.

Verificación

re-verificación

Asegúrate que la vulnerabilidad haya sido arreglada

Plataformas

Existen varias plataformas que son muy útiles parar las personas que reportan vulnerabilidades, y para los maintainers.

Plataformas

Snyk - https://snyk.io/
huntr.dev - https://huntr.dev/
GitHub Advisories - https://docs.github.com/code-security
hackerone - https://hackerone.com/

Snyk te ayuda a contactar a los maintainers, a verificar la vulnerabilidad, y dan seguimiento a esta. huntr.dev fue adquirida por una compañía, y ahora solo aceptan reportes de vulnerabilidades en proyectos relacionados con AI. Lo interesante de esta plataforma es que podías obtener recompensas por reportar vulnerabilidades, y estas eran incluso repartidas con la persona que arregló la vulnerabilidad. GitHub Advisories es una plataforma de GitHub para reportar vulnerabilidades en proyectos open source. Es muy completa, y su integración con el repositorio es muy buena. hackerone es usualmente usada por compañías, pero también he visto un par de proyectos open source como Django que la usan. Todas estas plataformas facilitan la obtención de un CVE. Si el proyecto no tiene una política de seguridad, puedes sugerirle al proyecto una, o si no usa una de estas plataformas, puedes sugerirle al proyecto que las use.

GitHub Advisories

Reportes, clasificación
Discusiones privadas
Versiones afectadas
CWE, CVSS, CVE
PRs privadas
Crédito a todos los involucrados

GitHub advisories

Demo

Encontrando

Vulnerabilidades

Encontrando vulnerabilidades

EXPLORA Y LEE CÓDIGO

Encontrando vulnerabilidades

Empieza por proyectos que uses o te interesen
Familiarízate con el código del proyecto
Lee las vulnerabilidades reportadas anteriormente
Chequea vulnerabilidades similares en/de otros proyectos
Lee sobre las vulnerabilidades más comunes en el lenguaje o tecnologías usadas en el proyecto

Encontrando vulnerabilidades

Top 10 OWASP
https://owasp.org/Top10/
Portswigger academy
https://portswigger.net/web-security
Bandit
https://bandit.readthedocs.io/en/latest/
CodeQL
https://codeql.github.com/

Encontrando vulnerabilidades

Revisa todos los entry points que reciban input de usuarios
Busca llamadas a funciones peligrosas
- exec, eval, system, shell_exec, etc
- regex, format
- open, read, write, etc
- mark_safe, format_html, etc
grep es tu mejor amigo

Ejemplo 🐜

Llamada a función peligrosa


            import re

            def contains(word, text):
                return bool(re.search(word, text, re.IGNORECASE))

            # Retorna True
            contains("hola", "Hola mundo")
            contains("HolA", "Hola mundo")

            # La función tarda mucho tiempo en ejecutarse.
            contains("(a|a)*b", "Holaaaaaaaaaaaaaaaaaaaaaaaaa mundo")

Ejemplo 🐜

Llamada a función peligrosa


            def contains(word, text):
                return word.lower() in text.lower()

            # Retorna True
            contains("hola", "Hola mundo")
            contains("HolA", "Hola mundo")

            # Retorna False
            contains("(a|a)*b", "Holaaaaaaaaaaaaaaaaaaaaaaaaa mundo")

https://github.com/advisories/GHSA-wj85-w4f4-xh8h

¡Tú también puedes hacerlo!

Hagamos los proyectos open source más seguros juntos

Referencias y recursos adicionales

Coordinated vulnerability disclosure for open source projects
https://github.blog/2022-02-09-coordinated-vulnerability-disclosure-cvd-open-source-projects/
OWASP's vulnerability disclosure cheat sheet
https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html