En julio, el investigador de seguridad Vladimir Smitka decidió verificar en Internet la presencia de carpetas abiertas .git después de una auditoría similar realizada recientemente para dominios de Internet checos y eslovacos.

Como dice el refrán: "nunca sucedió, y aquí está de nuevo". Permítanme recordarles, hace 9 años, exactamente la misma historia con el segmento ruso de Internet afectado por el síndrome abierto .svn . Los siguientes son los resultados del trabajo minucioso de un investigador checo, herramientas y métodos.

Razones para la vulnerabilidad

Un atacante puede extraer mucha información crítica para la seguridad del sitio desde el directorio .git . Así es como se ve un árbol de proyecto típico.

 ├── HEAD ├── branches ├── config ├── description ├── hooks │ ├── pre-commit.sample │ ├── pre-push.sample │ └── ... ├── info │ └── exclude ├── objects │ ├── info │ └── pack └── refs ├── heads └── tags 

Las contraseñas y las claves de acceso a varias API, bases de datos y servicios en la nube se pueden almacenar allí.

A menudo, como debería ser, un intento de abrir la carpeta .git arroja un error HTTP 403, pero la razón es solo la falta de index.html / index.php y los derechos para indexar automáticamente la carpeta, mientras que los archivos individuales todavía están disponibles . Para asegurarse de que el sitio no sea vulnerable, debe abrir la página de /.git/HEAD .

Este archivo contiene un enlace a la rama actual del proyecto.

 $ cat .git/HEAD ref: refs/heads/master 

Incluso si la indexación automática de directorios está deshabilitada, puede restaurar fácilmente toda la carpeta .git descargando archivos individuales y determinando las dependencias por el procesador de expresiones regulares, porque la estructura .git está claramente definida. También hay una herramienta especial: GitTools , que realiza automáticamente todas las acciones necesarias.

Medios de producción

A pesar de la complejidad y la ambición de la tarea, los costos en términos de dinero fueron modestos. Para todo, sobre todo, se necesitaron 250 dólares estadounidenses.

Servidor

Smithka alquiló para el proyecto 18 VPS y 4 servidores físicos. Según él, su elección no recayó en AWS por la razón de que el costo total del servicio, teniendo en cuenta los enormes volúmenes de tráfico esperados, el espacio significativo en disco y las altas cargas de CPU, no se pudo calcular fácilmente. El precio del VPS alquilado se fijó de antemano.

Listado de dominios

La lista se basa en los registros de texto del proyecto OpenData Rapid7 en JSON .

 { "$id": "https://opendata.rapid7.com/sonar.fdns_v2/", "type": "object", "definitions": {}, "$schema": "http://json-schema.org/draft-07/schema#", "additionalProperties": false, "properties": { "timestamp": { "$id": "/properties/timestamp", "type": "string", "description": "The time when this response was received in seconds since the epoch" }, "name": { "$id": "/properties/name", "type": "string", "description": "The record name" }, "type": { "$id": "/properties/type", "type": "string", "description": "The record type" }, "value": { "$id": "/properties/value", "type": "string", "description": "The response received for a record of the given name and type" } } } 

Después de algunos filtros de TLD y dominios de segundo nivel, la lista todavía tenía más de 230 millones de entradas .

A continuación, la base de datos se dividió en bloques de 2 millones de registros y la carga se distribuyó en varios servidores utilizando una aplicación PHP.

Software

Python colgó de las bibliotecas asyncio asyncio con aiohttp como caballo de batalla . El intento de utilizar Requests y Urllib3 para estos propósitos no tuvo éxito, de los cuales el primero podría ser adecuado, pero el investigador no descubrió los tiempos de espera en la documentación. El segundo no hizo frente a la redirección de dominio, y debido a esto muy pronto agotó la memoria en los servidores.

Para identificar la plataforma y el perfil de los sitios vulnerables, Smitha utilizó la utilidad WAD , basada en la base de datos Wappalyzer , una extensión para el navegador web que le permite determinar las tecnologías utilizadas en la página.

Utilidades de línea de comandos simples como GNU Parallels también se utilizaron para acelerar el tiempo de ejecución del controlador y evitar que el script se detenga debido a una congelación.

 cat sites.txt | parallel --bar --tmpdir ./wad --files wad -u {} -f csv 

Resultados

La exploración duró 2 semanas, como resultado, el investigador:

• descubrió 390 mil sitios web vulnerables;
• recolectó 290 mil direcciones de correo electrónico;
• notificó a 90 mil destinatarios de la vulnerabilidad encontrada.

En respuesta a sus esfuerzos, Smithka recibió:

• 18 mil errores de entrega de mensajes;
  
  • alrededor de 2000 cartas de agradecimiento;
  • 30 falsas alarmas con sistemas honeypot;
  • 1 amenaza de llamar a la policía canadiense;

El lenguaje de programación más popular resultó ser PHP . Sin embargo, si normaliza el resultado a la participación relativa de un PL en particular, entonces PHP da paso al liderazgo de Python y Node.js. Sin embargo, no está claro qué tan confiables pueden ser tales estadísticas para determinar la participación de mercado de un lenguaje de programación dado.

Apache está en la parte superior de la lista de popularidad de servidores web, con Nginx en segundo lugar y el clon chino Nginx Tengine de repente en tercer lugar.

El sistema operativo más popular fue Ubuntu , luego Debian y CentOS en tercer lugar.

La nominación de CMS casi resultó ser un teatro de un solo actor, y este actor es WordPress con el 85% de todas las plataformas encontradas.

Que sigue

Reparar una vulnerabilidad es fácil.

.htaccess

 RewriteRule "(^|/)\.(?!well-known\/)" - [F] 

.nginx

 location ~ /\.(?!well-known\/) { deny all; } 

apache22.conf

 <Directory ~ "/\.(?!well-known\/)"> Order deny,allow Deny from all </Directory> 

apache24.conf

 <Directory ~ "/\.(?!well-known\/)"> Require all denied </Directory> 

Caddyfile

 status 403 /blockdot rewrite { r /\.(?!well-known\/) to /blockdot }