No pases el repositorio de código a producción en tu dispositivo ... o atente a las consecuencias

Preparando unas demostraciones para una charla sobre (IN)seguridad en Internet, decidí buscar dispositivos accesibles mediante TCP/IP que estuvieran colocados en edificios para, por ejemplo, controlar la luminosidad, temperatura, consumos eléctricos, etcétera y así ver cuántos de ellos mantienen sus datos de acceso con credenciales por defecto. Para ello decidí hacer un poco de hacking con buscadores y usar Shodan.

Figura 1: No pases el repositorio de código a producción

Para acotar la búsqueda, sólo busqué dispositivos en España en cuyo banner apareciera la palabra "planta", ya que de estar clasificados en un edificio por la planta donde están colocados, seguramente al configurar el equipamiento de control el operario habría introducido esa palabra dentro del dispositivo de control.

Bug 1: Data Leak en Banner

Como se ve en la imagen, la mayoría de estos dispositivos se encuentran en Barcelona y por el esquema de direccionamiento IP es muy probable que la mayoría de ellos estén colocados en la misma organización, ya que todos aparecen en la red 147.83.X.X.

Figura 2: Dispositivos con banner "planta" encontrados en España vía Shodan

Seleccionando el primer dispositivo se observa que éste dispone de un servidor web y nos muestra el siguiente formulario de acceso:

Figura 3: El portal web a un dispositivo conectado a Internet

Una opción que podría barajarse para intentar un posible acceso sería buscar el usuario y la contraseña por defecto de este tipo de dispositivos ya que es un error habitual no cambiar los datos de acceso por defecto, tal y como se explica en el artículo de las cámaras de seguridad.

Bug 2: Directory Listing

Pero en este caso, lo que vamos a comprobar es otro sencillo bug en los servidores web no fortificados. El listado de directorios. Al comprobar si se puede hacer un listing en el servidor web del dispositivo, la sorpresa es que sí es posible:

Figura 4: Directory Listing en el directorio de imágenes del servidor web del dispositivo

Aún más flagrante es el siguiente fallo, ya que como se puede ver en la imagen llama poderosamente la atención el directorio .svn, en el que se puede localizar dentro de él el fichero entries. En directorio suele ser utilizado para almacenar la información de las últimas actualizaciones que se desarrollan en proyectos donde se utiliza Subversión para la gestión del código.

Bug 3: Publicación de repositorio de código

La publicación en producción de los repositorios de código es un error común en muchos entornos en los que, o bien no hay entornos de desarrollo, pruebas y producción separados o en los que el paso a producción se hace de forma insegura. Es por eso que es muy común para los pentesters buscar y explotar estos bugs como explicaron en el blog de Eleven Paths con su herramienta de pentesting persistente Faast, o como se hace desde hace mucho tiempo con FOCA, que no solo busca estos repositorios sino que además tiene un plugin para interpretar el fichero .svn/entries.

Figura 5: Plugin de .svn/entries en FOCA

Como se observa en la imagen recortada del fichero .svn/entries, aparece quién es el proveedor que desarrolla este tipo de aplicaciones y dónde ubica su repositorio. En caso de poder tener acceso a su código, podría buscarse alguna vulnerabilidad en él y poder inferir quiénes son sus clientes con el mismo código afectado.

También observamos los ficheros (file) que han sido actualizados y el nombre de usuario y la fecha de acceso. Mirando la última fecha de acceso podemos ver que en este tipo de dispositivos el año es el mismo sobre el 2009-2010, lo que da una idea de la desactualización del firmware de todos ellos, lo que podría hacerlos vulnerables a los últimos grandes bugs como HeartBleed o Shellshock.

Figura 6: Fichero .svn/entries en el dispositivo encontrado

Podríamos acceder también al directorio .svn/text-base para ver si se guardan copias del fichero .htaccess o de cualquier otro que arroje información sobre usuarios, conexiones, etcétera. Y, como no, buscar la base de datos de ficheros Pristine donde estaría el código fuente completo de todos los ficheros del servidor.

Bug 4: Leak de network information

Además, en todos los dispositivos con este modelo concreto es posible realizar un listing de los directorios, lo que permite la extracción en una auditoría de seguridad de información más que relevante, aparte de poder acceder a varios de ellos con su nombre de usuario y contraseña por defecto.

Figura 7: Información de otros dispositivos y puertos en la red

Y utilizando el nombre del modelo para la búsqueda de este tipo de dispositivos en Shodan, incluso podríamos obtener información del direccionamiento interno de una organización con los números de puertos asociados:

Conclusión

Visto esto, el paso a producción de un dispositivo debería ser controlado por un equipo de QA que verifique que todo se está haciendo de formar segura y sin fugas de información. Sacar una imagen de dispositivo que después va a ser industrializada con estos errores garrafales demuestran muy poco interés y respeto por la seguridad de los clientes.

Autor: Amador Aparicio
Twitter: (@amadapa)