Antigua vulnerabilidad UPnP de una nueva manera

Todo lo nuevo es un viejo bien olvidado (o mejor, un viejo muy bien olvidado). Por supuesto, es correcto monitorear nuevas vulnerabilidades, pero no debe olvidarse de las antiguas. Especialmente cuando el fabricante se permite "olvidarlos". Alguien debe recordar. De lo contrario, pisaremos el mismo rastrillo una y otra vez.

El artículo se centrará en uno antiguo, pero resultó que nunca ha perdido su relevancia hasta el día de hoy, el agujero UPnP.



PD: No llamaré al proveedor, él no es culpable de esto, pero por otro lado, existe una clara supervisión de las políticas de seguridad que, junto con la arquitectura de la red, hicieron posible explotar esta vulnerabilidad. Como siempre, las estrellas convergen. El proveedor instaló enrutadores en su red a clientes con los chips necesarios y lo conectó con una dirección IP externa. Sí, la mayoría de los puertos se filtraron, pero por alguna razón no 52869.

PPS Todos los eventos ocurrieron a finales de 2018. Los héroes son ficticios, y las coincidencias con personalidades reales son aleatorias.


La primera mención de la vulnerabilidad fue en 2014: tyk
Los intentos de contactar al fabricante no tuvieron mucho éxito y se publicó la vulnerabilidad. La única recomendación de contraataque fue:

"... restringir la interacción con el servicio ... Sólo los clientes y servidores que tienen una relación procesal legal ... deberían poder comunicarse con él".

Existe una falla en el servicio SOAP miniigd. El problema es procesar las solicitudes de NewInternalClient debido a la incapacidad de borrar los datos del usuario antes de realizar una llamada al sistema. Un atacante podría usar esta vulnerabilidad para ejecutar código con privilegios de root.

Es decir En todos los enrutadores con UPnP versión 1.0, puede ejecutar código remoto arbitrario.
Sin autorización De la raíz. Genial, verdad?

Cualquiera puede encontrar un complemento listo para metasplit en github, cuyo rendimiento fue probado por las sillas quemadas de nuestros ingenieros de servicio.
Fue inesperado y nada divertido.

Una breve cronología de los acontecimientos de ese día:

14:00 En el soporte técnico, los suscriptores comienzan a recibir llamadas a Internet que funciona mal.

• Síntomas en el lado del cliente: "funciona lentamente, después de un reinicio funciona bien por un tiempo, luego nuevamente lentamente".
• Síntomas por parte del equipo: un pequeño aumento en el tráfico y las cargas de CPU se cancelaron en la carga que genera el cliente.

Las aplicaciones individuales se registran para verificar la línea de administradores o la partida del instalador. No hay una plantilla común para la acción. Nada esta claro.

15:00 El número de aplicaciones comienza a exceder la temperatura promedio en el hospital y las aplicaciones individuales comienzan a esculpir en aplicaciones para más con el tipo de "Accidente". Las solicitudes se envían a los administradores superiores para verificar los segmentos de red.

15:20 Los administradores cierran los choques masivos, porque No hay problemas en la red, todas las solicitudes de los clientes desde diferentes puntos de conexión son únicas. (Por ejemplo: el conmutador está lleno de suscriptores activos, pero no funciona bien para uno). En este momento, caen las apelaciones y todo se calma. Alguien presta atención (finalmente) de que todas las aplicaciones por mal trabajo se realizaron con el mismo modelo de enrutador, todos juntos fingen que todo está bien.

15:30 Nuevamente la afluencia de solicitudes de suscriptores, nuevamente el registro de un accidente masivo y la transferencia a los administradores. En este momento, queda claro que algo está realmente mal y que hay que hacer algo (quien trabajó con el servicio al cliente entenderá lo difícil que a veces es hacerlo. Los clientes siempre mienten y, a veces, la primera línea es escalar aún más la tarea) .

15:35 El ingeniero de turno recibe una solicitud de un problema con el servicio al cliente. Obtiene una lista de todos los clientes, su tipo de conexión y modelo de dispositivo. Y entonces comienza un poco de magia.




15:40 El ingeniero ejecuta la lista de clientes a través de todos los diagnósticos, cada enrutador se verificó de acuerdo con todas las métricas estándar y ... no se encontró nada. Un enrutador es como un enrutador. Sí, la CPU ha aumentado, pero los indicadores no son críticos, pero vierte tráfico en alguna parte, lo que significa que funciona.

Sí, el servicio UPnP está girando en el puerto 52869. Sí, todavía hay un montón de puertos abiertos, abierto significa que son necesarios (lógica de hierro), y siempre estaba girando allí y no había problemas (un argumento más de lógica de hierro). El ssh directo a este modelo de enrutador no es posible (francamente, es posible, pero dentro de las políticas de la compañía y el busybox muy despojado, se desaconsejó tal paseo por los dispositivos del cliente). Todo se puso de pie nuevamente.

16:00 Solo ahora descubrimos que hay algunos problemas. El ingeniero de servicio informa a su supervisor, y el supervisor nos llama por teléfono sobre sus conjeturas sobre el puerto 52869 y le pide ayuda.

16:05 Entonces todo sucedió muy rápido. El mismo modelo de enrutador se incluye en el banco de pruebas, la dirección IP se toma del cliente problemático y se cuelga en la prueba. El wirehark está encendido. Esto es para atrapar solicitudes al dispositivo.

Para capturar las solicitudes del enrutador (en ese momento, el esquema general de cómo la interacción aún era desconocida), el cliente está aislado en el segmento de prueba y todo su tráfico se refleja en la máquina de prueba más cercana donde se eleva otro wirehark.

Esperamos más, miramos la pantalla.

Los hacks ya estaban atrapados de esta manera, de manera bastante eficiente y, por lo tanto, decidieron no cambiar los hábitos.

16:10 Mientras se agita Wirehark, en Google existe una vulnerabilidad CVE-2014-8361 sobre la cual se informa a los ingenieros. El ingeniero, sin escuchar, toma una decisión (y, en principio, lógica): el filtro de este puerto en la frontera. Apenas dicho que hecho.


16:25 Se nos dice que toda la mierda de remake Misha no funcionó. Y ya sabíamos que eso no funcionaría. En ese momento, ya habían tocado el enrutador de prueba, subieron el reverso a otro puerto y comenzaron a usarlo para el puerto DDOS-a hasta 1900 (!) Usando otra vulnerabilidad. Señor, qué cubo de basura con fugas


Lo más interesante es que las reglas del firewall en el dispositivo han sido cambiadas y nmap ahora no muestra puertos abiertos desde el exterior. Solo en un volcado de tráfico fue posible detectar solicitudes en estos puertos. Es decir un atacante después de piratear bloqueó el acceso al resto. No es un enfoque de alta tecnología, pero bravo de todos modos.

16:30 Una conferencia se reúne con las preguntas "quién tiene la culpa y qué hacer". Los puertos 1900 y 52869 quedaron prohibidos y se están intentando arreglar algo en dispositivos pirateados. Reiniciar: no ayudó, la idea de volver a flashear fue rechazada de inmediato. Sí, existe una función tan funcional que fue posible reorganizar el software de forma remota a través de TR069 con un botón en todos los dispositivos. Pero desde el dispositivo no era la primera frescura, pero el número de clientes era grande: un cierto porcentaje de dispositivos de ladrillo crearía problemas.

16:40 Para resumir: los dispositivos son pirateados, participan como mínimo en ddos ​​y transmiten algo en algún lugar del canal encriptado. (Todo en diferentes puertos). Entrar no es posible, el proveedor rechazó el acceso total a través de ssh al dispositivo y vio lo que era imposible llegar allí. La consola está protegida por contraseña.

En algún lugar cercano a las 17:00, se decidió coser el dispositivo como la forma más rápida. Después de flashear y reiniciar, todo volvió a la normalidad.

En lugar de totales

Desafortunadamente, no pudimos resolver completamente este problema.

Por "decidir" me refiero a obtener información completa de piratería y actualizar nuestras políticas para contrarrestar esto en el futuro. Sí, no todas las tareas se resuelven con éxito y como nos gustaría. Esto es normal Aunque insultante.

Si es bueno buscar en el shodan,
puedes encontrarte algo
para experimentos:
de una forma u otra
pero no te dije eso.