[pyar] Backdoor en el paquete ssh-decorator

Andres Riancho andres.riancho en gmail.com
Jue Mayo 24 12:05:54 -03 2018


Les dejo algunos comentarios sobre este tema!

Primero que nada, un poco de analisis de lo que paso: Alguien subio a
pypi una version modificada de ssh-decorator, que obtenia las
credenciales y las enviaba a un sitio controlado por el atacante.

Como puede haber pasado esto (en orden de probabilidades)?
 * El developer original del paquete cayó en un ataque de phishing
 * El developer original del paquete re-utiliza contraseñas entre
multiples servicios. Uno de esos servicios fue comprometido, de ahi
sacaron su contraseña y la probaron en pypi.
 * El developer original del paquete divulgó de alguna manera sus
credenciales: las almacenó en un repositorio de github, archivo de
texto donde lo vio un compañero de trabajo, etc.
 * El developer original del paquete fue victima de un ataque
especifico a su maquina, la cual fue comprometida y de allí robaron
sus credenciales de pypi
 * (muy poco probable) Atacante comprometió pypi (no las creds del
developer) y subió directamente un paquete modificado

Pypi no ayuda mucho a mitigar estos ataques, ya que no requiere 2FA
para el login, y ni siquiera tiene la opcion de habilitarlo en caso de
que así lo querramos.

Pypi / pip no tienen un sistema de firma digital para los paquetes que
un developer sube.

Entonces, cualquiera con las credenciales de pypi de otra persona
puede subir una nueva version del paquete. No hace falta 2FA, no hace
falta clave GPG, etc.

pipenv tiene una funcionalidad de chequear paquetes que tienen
vulnerabilidades conocidas. Es bueno, pero no alcanza. Ejemplo:
 * Dia 0: Atacante sube ssh-decorator modificado a pypi
 * Dia 235: Alguien se da cuenta del backdoor
 * Dia 236: Alguien agrega ssh-decorator version x.y.z a la
"blacklist" de pipenv

Resultado si solo utilizamos pipenv como proteccion: 236 dias de
ssh-decorator backdooreado.

En el hilo de conversacion alguien menciono que iba a migrar sus
requirements.txt para apuntar a github.com. Suponiendo que todo lo que
esta en requirements.txt esta en github.com, creo que existe una
ganancia de seguridad, pero la misma no es grande:
 * Si te bajas el paquete de github, evitas pypi. Antes un atacante
podia obtener credenciales de github, o pypi para poner un backdoor en
un paquete. Tenia dos potenciales objetivos. Ahora tiene solo uno:
github.
 * Si el developer tiene un poco de entrenamiento de seguridad,
posiblemente habilitó 2FA en github. Eso lo protege frente a ataques
de phishing. No puede hacer eso en pypi.
 * Si el atacante obtiene credenciales de github para un developer de
una libreria, puede agregar codigo a la misma unicamente despues de
agregar a la cuenta una nueva clave de SSH. Si no me equivoco cuando
esto pasa se le manda un email al developer, que deberia alertarlo de
el problema. Si aun asi no se da cuenta, el atacante puede agregar
codigo, pero va a quedar un commit con mensaje: "Adding backdoor" :-)
el cual deberia ser facil de encontrar

Soluciones?

 * Requerir 2FA para todos los developers que suben paquetes a pypi:
vamos... son todos developers, saben lo que es, lo han utilizado
antes, implementarlo es cuestion de 2 o 3 días de trabajo duro.

 * Requerir a todos los developers que suben paquetes a pypi que
firmen digitalmente sus paquetes. Esto es simple de hacer para el
developer, pero armar toda la arquitectura para poder firmar los
paquetes y que pip luego verifique la firma... es dificil. Este paso
se debe implementar luego de 2FA, ya que vamos a necesitar 2FA para
verificar la identidad del developer en caso de que pierda su clave
para firmar.

2018-05-24 11:43 GMT-03:00 Federico Apelhanz <elmaildejapel en gmail.com>:
> pipenv quise decir, podes hacer pipenv check y te dice los paquetes
> inseguros que tenes, te dejo la charla (alrededor del minuto 25 demuestra lo
> que digo):
>
> https://www.youtube.com/watch?v=GBQAKldqgZs
>
> El 24 de mayo de 2018, 11:25, Facundo Batista <facundobatista en gmail.com>
> escribió:
>>
>> El 24 de mayo de 2018, 11:20, Federico Apelhanz
>> <elmaildejapel en gmail.com> escribió:
>> > *creo* que pyenv soluciona el tema de la seguridad (raro que todavía no
>> > se
>> > hablo al respecto en esta lista)
>>
>> ¿En qué sentido soluciona "el tema de la seguridad"?
>>
>> ¿Tenés algún link que hable de esto?
>>
>> Gracias! Saludos,
>>
>> --
>> .    Facundo
>>
>> Blog: http://www.taniquetil.com.ar/plog/
>> PyAr: http://www.python.org/ar/
>> Twitter: @facundobatista
>> _______________________________________________
>> Lista de Correo de PyAr - Python Argentina - pyar en python.org.ar
>> Sitio web: http://www.python.org.ar/
>>
>> Para administrar la lista (o desuscribirse) entrar a
>> http://listas.python.org.ar/listinfo/pyar
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>
>
>
> _______________________________________________
> Lista de Correo de PyAr - Python Argentina - pyar en python.org.ar
> Sitio web: http://www.python.org.ar/
>
> Para administrar la lista (o desuscribirse) entrar a
> http://listas.python.org.ar/listinfo/pyar
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar



-- 
Andrés Riancho
Project Leader at w3af - http://w3af.org/
Web Application Attack and Audit Framework
Twitter: @w3af
GPG: 0x93C344F3


Más información sobre la lista de distribución pyar