Artículos de investigaciónExplotaciónHacking HardwareHacktivismoPruebas de concepto

#0Day – ¡Señor tíñame el sombrero! RFI por SSH

#Disclaimer

Vuelvo a publicar el post, dado que pasadas 2 semanas no tenemos respuesta alguna. Un gesto poco de agradecer por parte de HackerOne y de Ubiquiti, el fallo de la libreria ha sido arreglado. Pero gracias a que yo se lo comuniqué, no por que ubiquiti hiciera algo en 3 meses, pero en 2 días, el dev de la librería lo arregló.

 #AntesDeEntrarEnMateria

Lo que vengo a contar mas que una entrada típica, es mas bien una experiencia personal con un BugBounty de HackerOne (con la empresa de Ubiquiti). Nuestra relación iba de maravilla, prueba de ello es que toda la reputación adquirida ha sido gracias a los fallos que los hemos enviado a lo largo de 4 meses. (Podéis consultar el perfil aquí https://hackerone.com/r4s_team)

Hago las cuentas públicas por que de hecho ya lo son ( o lo serán cuando HackerOne libere la cantidad del bounty pagado). 

También cabe destacar que aún hay pendiente de que arreglen 4 fallos más enviados (al momento de escribir este artículo).

De hecho nuestra relación iba extraordinariamente bien, no podíamos enviar mas fallos de tantos que teníamos e incluso rebajaron su política para todo HackerOne, ante el aviso de que teníamos un RCE sin credenciales para uno de sus productos.

Pero como en toda relación, las cosas se tuercen, y mas cuando hay dinero de por medio. De acuerdo a su página de Bounty, dice que su máximo de pago es 25K por un RCE

Hay antecedentes de que han pagado 18.000 $ por uno similar (https://hackerone.com/reports/73480).  De hecho, no es el primer RCE que los enviamos, en su día decidieron pagar 2K y reclamamos al ver la diferencia de precio con el anterior mencionado. Ellos respondieron que era por que el nuestro requería de credenciales, y es entendible… ¿Pero teníamos que intentarlo no?

 

Tras darle muchas vueltas y horas de laboratorio, surgió. El RCE sin credenciales. A la vez que se encontraron 3 posibles de vectores de ataque mas.

  1. Cross-Site Scripting
  2. Flood Attack
  3. Stealing a Camera ( como las pelis, dejar las cámaras congeladas o peor aun, poner la foto que quieras o parar de que graben)
  4. Remote Code Execution (RCE) without AUTH

Su respuesta fue rápida, todos eran duplicados menos el RCE, y fue marcado como triage con la siguiente respuesta

A qui se puede ver donde aceptan y dicen que cuentan como el reporte original el RCE

Después de insistir las dos últimas semanas (casi un mes después) nos contestan con lo siguiente

 

#ReleaseTheKraken

Básicamente casi todos los dispositivos de Ubiquiti disponen de un servicio de discovery (para detectar nuevos dispositivos).

Se le hizo un reverseado completo al protocolo (java ofuscado), para así poder replicar los paquetes, para estar en disposición de poder crear una cámara o modificar una actual (ya que no verifica las firmas del ssh al que se conecta aunque se hayan cambiado).

Me creé un falso servidor ssh, donde recibía todas las claves y las daba por buenas (pudiendo sacar sin credenciales los credenciales de las cámaras). Pero para no quedarnos ahí, me fijé en que al conectarse a mi falso servidor ssh, se descargaba por scp la miniatura de la foto de la cámara.

 scp -f -q -p -r '/tmp/snap_av.jpg'`

 

Revisándome el protocolo SCP, pude replicar un servicio SCP falso para hacer pruebas (fue muy útil la web de oracle https://web.archive.org/web/20170215184048/https://blogs.oracle.com/janp/entry/how_the_scp_protocol_works) , como la web está caída os lo enlazo a web.archive.

Por cierto, la librería de SCP que utilizan en su software, usa -r (por lo que se podría copiar la foto, y además mas archivos)

Pero el verdadero problema que hay aquí, es que si se sirve un archivo (por el falso servicio SCP) al más típico LFI (/../../../../../bin/ubnt.updater.exe) se podría sobreescribir cualquier archivo del sistema, y sobretodo el propio ejecutable que es llamado por el software para actualizarse (como SYSTEM por cierto, ya que se ve que es necesario que se ejecute así un sistema de grabación de cámaras).

Con ese reemplazo el updater sería falso, y solo quedaría esperar para BOOM! (como vimos en otro fallo enviado previamente enviado – https://hackerone.com/bugs?subject=user&report_id=216206). Lo sé no podéis acceder a los links, por que son privados, pasaros por aquí en 90 días y serán públicos 🙂

En teoría un cliente SCP no debería dejar de bajarte un archivo que no solicitas, como pude comprobar con el putty y con el scp de ubuntu.

Básicamente el resumen del ataque es el siguiente

El servicio de discovery falso recibe una petición de si soy una cámara por parte del servidor —> Se responde a la petición diciendo que por supuesto que si —> Mi servicio crea una cámara y le dice ¡mi ssh está aquí! —> El server se conecta a mi ssh y se baja la captura por scp –> Un momento esta captura no me vale, da igual, grabo un log (regalito en el updater) –> Estoy muy viejo, voy a actualizarme  –> ¡¡¡ BOOM !!!

#POC

Os dejo aquí el vídeo original para que podáis ver la prueba de concepto, como en otro bug anterior se hizo la explotación completa por medio del updater. Al final falsificamos el RCE, para tardar menos, pero no es relevante para una explotación real, ya que ellos estaban al corriente de que ese programa se ejecuta como System cuando hay una actualización. Por lo que os quedará raro para la POC, pero ya os digo que no es relevante, quedaros con que esperando un tiempo, el servidor llamaría al programa sobrescrito como SYSTEM.

#EsfuerzoRequerido

  • Reverseado completo de un protocolo propietario (Discovery)
  • Creación de un servidor falso SSH
  • Creación de un falso servicio SCP
  • Muchísimas horas de ensayo / error
  • Horas extra-laborales y robadas al tiempo con mi preciosa mujer

* Todo esto suponiendo que supieras lo que querías hacer y fueras a tiro hecho

 

#TimeLine

  • Día 2 de Mayo, se envía el fallo
  • Día 3 de Mayo, se acepta y se marca en triage
  • Día 16 de Mayo, preguntamos que tal van (sin respuesta)
  • Día 24 de Mayo, preguntamos que tal van otra vez  (sin respuesta)
  • Día 31 de Mayo, preguntamos que tal van otra vez también  (sin respuesta)
  • Día 7 de Junio, preguntamos que tal van ya un poco cansados (conservando los modales a duras penas)
  • Día 8 de Junio, obtenemos el duplicado del RCE (WTF!)
    • Bounty 0 €
  • Día 9 de Junio, Nos quejamos y conseguimos un bounty de 2500 $
    • Nos volvemos a quejar, por que creemos que no han entendido nada de como funciona el fallo y dicen que van a revisar el caso
  • Día 16 de Julio, Contestamos que si han llegado a algún acuerdo.
  • Día 18 de Julio, Obtenemos respuesta de que consideran que esta bien como está
  • Hoy liberamos el fallo que según ellos estaba duplicado desde hace mas de un mes de nuestro envío

 

Pues eso, siento haberme desahogado aquí, pero espero haberos enseñado que puede haber LFI hasta en una conexión SSH (scp). Cuanto menos creo que es curiosa la forma de explotarla, y ya que no vamos a cobrar lo estipulado en el acuerdo inicial, pues tampoco les debo ningún respeto.  No publico el exploit con el cual puedes dejar sin grabaciones, o ejecutar código como system en una empresa con cámaras ubiquiti, por que no ganaría nada, ya me he desahogado con este post, ya que lo que ha ocurrido me parece simplemente repugnante.

Un saludo, y sed …. “buenos”

5 comentarios en “#0Day – ¡Señor tíñame el sombrero! RFI por SSH

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Los datos introducidos se guardarán en nuestra base de datos como parte del comentario publicado, como se indica en la política de privacidad.