GitHub recientemente concedió 18.000 dólares a un investigador alemán (Markus Fenske aka @iblue) después encontrar y reportar un error en la plataforma de GitHub Enterprise, la consola de gestión, que podría haber resultado en la ejecución remota de código (RCE). La compañía corrigió la vulnerabilidad a finales de enero, pero las noticias de la falla no salieron a la superficie hasta esta semana cuando GitHub y Markus Fenske, un investigador de seguridad alemán independiente lo han revelado.





GitHub Enterprise es una versión local de GitHub.com que se puede utilizar para implementar un servicio GitHub en la red local de su organización. La vulnerabilidad es una combinación de dos errores,.

Un problema se deriva del hecho de que se estaba utilizando un valor estático para firmar criptográficamente el secreto de sesión de Ruby on Rails para la consola. Se supone que el valor secreto es un valor generado aleatoriamente por máquina usado para firmar la cookie, no un valor estático.

GitHub reconoció el martes que el secreto estático sólo se supone que se utilizará para pruebas y desarrollo, pero "un cambio no relacionado de permisos de archivo impidió que el secreto de sesión (y aleatoriamente generado) se utilizara".

"Para propósitos de prueba lo reemplazaron con un valor estático y olvidaron cambiarlo de nuevo", dijo Fenske. En el entorno de producción, había un mecanismo que debería haberlo reemplazado con un valor aleatorio. Pero no funcionó."

Aunque GitHub no debería haber estado usando un secreto estático para firmar cookies que contienen datos de sesión, el otro problema, dice Fenske, es que los datos de sesión podrían ser serializados con Marshal. Marshal, una biblioteca que convierte colecciones de objetos Ruby en una secuencia de bytes, tiene un método, .load, que puede devolver el resultado de los datos convertidos serializados.

Como señala Fenske, la documentación en torno a Marshal.load dice que "nunca transmita datos no confiables (incluyendo la entrada suministrada por el usuario) a este método", pero eso es lo que GitHub estaba haciendo.

Al conocer el secreto, un atacante podría haber construido una cookie, deserializada por Marshal.load, y engañar GitHub con la ejecución de cualquier código que quisiera.

"Debido a que el secreto es conocido, se puede crear una firma válida y pasar datos arbitrarios a Marshal.load, lo que conduce a la ejecución remota de código", dijo Fenske.

Dijo que estaba inspirado para empujar a GitHub Enterprise después de tropezar con un blogpost por el hacker taiwanés Orange Tsai sobre una inyección de SQL que encontró en la plataforma.

• http://blog.orange.tw/2017/01/bug-bounty-github-enterprise-sql-injection.html

"Alrededor de dos minutos después de descodificar la fuente y abrir el primer archivo (config.ru) de la primera aplicación (la interfaz de gestión), me di cuenta de la vulnerabilidad", dijo Fenske.

GitHub arregló la vulnerabilidad el 31 de enero cuando eliminó GitHub Enterprise 2.8.7. Ahora, el servicio predeterminado es un secreto de sesión generado al azar si no se encuentra el secreto de sesión configurado inicialmente.

Fue un cambio bastante rápido para la empresa; El parche llegó sólo cinco días después de que Fenske informó sobre el problema y se ganó 10.000 dólares, la recompensa más alta que la compañía da a través de su programa de recompensas de errores (Bug Bountys), y un lugar en su Salón de la Fama.

• https://github.com/blog/2332-bug-bounty-third-anniversary-wrap-up

"Trabajar con GitHub es realmente agradable", dijo Fenske, "Para una empresa tan grande, su velocidad es increíble".

• https://bounty.github.com/researchers/iblue.html

El investigador no tenía ni idea cuando presentó el error, sin embargo, que la empresa estaba en medio de un periodo de recompensa promocional de errores. La compañía anunció la promoción, que se extendió de enero a febrero, para celebrar el tercer aniversario de su programa de recompensas de errores con HackerOne.

Después de enviar un borrador de su revelación a la compañía esta semana, Fenske descubrió que su error era lo suficientemente grave como para obtener una recompensa adicional de $ 8.000 y el segundo lugar en el concurso.





"Estaba escribiendo mi artículo y envié a GitHub un borrador para verlo, y la respuesta llegó en cuestión de minutos, diciéndome que puedo publicar lo que me gusta y que me dieron más dinero", dijo, "no sabía nada Que concurso extra y fue muy agradablemente sorprendido. "

El fallo de Fenske fue uno de los tres GitHub arreglados en su producto Enterprise para calificar para dinero adicional de recompensas de bugs. La compañía también corrigió dos errores de bypass de autenticación SAML en el servicio.

Fenske dijo que la última versión de GitHub Enterprise usa un secreto que tiene 16 bytes aleatorios escritos en hexadecimal.

"Rápidamente calculé que el cracking tomará unos 469142742208 gigayears en una instancia de 8 GPU (para comparación: The Sun desaparecerá en 7.7 gigayears). Creo que es seguro ahora.

Fuente:
https://threatpost.com/github-code-execution-bug-fetches-18000-bounty/124378/