Es más común de lo que piensan que los usuarios suban archivos “basura” a servidores en producción/explotación. Muchas veces son distintos usuarios los que tienen acceso al directorio público de un sitio web, ya sea todos accediendo desde el mismo usuario o cada uno con su usuario.
El problema es cuando no tenemos control sobre las cosas que se suben a producción, por ejemplo como administrador de sistemas a muchos nos ha tocado que debemos crear cuentas de usuario ftp con acceso a subdirectorios de un sitio web, uno intenta aplicar todas las medidas de seguridad posible y hacer cumplir todos los procedimientos necesarios, como por ejemplo que un “usuario normal” no puede subir archivos a produccion vía FTP sin que sean correctamente validados ni filtrados, sin embargo, a ellos no le sirve. Otro ejemplo es cuando los desarrolladores tienen que subir desarrollos nuevos o actualizaciones, ya sea mediante un control de versiones o suciamente directamente desde ftp o ssh, nunca se controla qué tipo de archivos están subiendo, exponiendo nuestros servicios y servidores.

Hace un año aproximadamente, cuando trabajaba de administrador de sistemas, intenté implantar un procedimiento de pasos a producción en el cual se pudiese revisar los archivos de cada control de cambio, simplemente para revisar que no se estén subiendo archivos sensibles como el típico respaldo de la base de datos, respaldos de código fuente, etc. Pero no funcionó ya que decian que lo único que hacia era “entorpecer el proceso”.

Cuento esta historia a modo de introducción para lo que van a leer más abajo; les mostraré los errores más comunes al momento de desarrollar y poner en internet un nuevo sitio o aplicación web.

El primer error que les voy a mostrar, es cuando se suben archivos de “respaldo” con la extensión modificada sin que el motor http sepa si debe interpretarlo o no, por lo tanto muestra el código fuente. Dentro de lo más típico es renombrar archivos antes de modificarlos y dejarlos como por ejemplo usuarios.phpOLD, usuarios.php.old, usuarios.php_, etc. Con este ejemplo, podemos ver que renombraron el archivo Reserva.php a Reserva.php__, y si ingresamos y vemos el código fuente, podemos ver el php sin interpretar:

URL https://www.campamentosdeingles.es/Reserva.php__

Otros casos reales:

• Wissnet: https://wissnet.com.ar/moregroupware/modules/webmail2/inc/webmail2_settings_editaccount.php__
• Gruenes Presse: https://www.gruenes-presseportal.de/index.php__
• Cencosud Chile: https://www.cencosudshopping.cl/portalnunoa/components/com_mirador/views/mirador/tmpl/default.php__

Hay que tener mucho cuidado con este punto, ya que muchas veces son archivos de configuración como conex.php, db.php u otro que revelan usuarios y passwords de bases de datos, ftp, etc.

El segundo error es cuando suben archivos comprimidos o empaquetados. Lo descargamos, desempaquetamos y listo, tenemos el código fuente. Por ejemplo lo que sucede con el sitio https://www.emc.mil.cl/ que nos permite descargar el sistema de captcha que utilizan mediante www.emc.mil.cl/sgs_1022/captcha/captcha.zip.

El tercer error son los archivos logs . Yo puedo entender a quienes suben logs para que otros los descarguen y luego se les olvide eliminarlos, o bien que respalden logs para descargarlos con posterioridad, pero no entiendo a quienes configuran Apache para que almacene los logs dentro del directorio público y sin las medidas de seguridad necesarias. Los logs divulgan información sensible como direcciones IP, directorios, nombres de usuarios, etc. Dentro de los logs públicos más comunes estan el del WS_FTP y los logs del apache.
Un ejemplo del log de transacciones WS_FTP lo pueden ver en el siguiente link https://www.biogoldsa.cl/pdf/WS_FTP.LOG:

Un ejemplo de un log de Apache lo pueden ver en https://www.gescomltda.cl/intranet/logs/access.log:

Otros ejemplos:

• https://www.mmaya.gob.bo/webpncc/biblio/WS_FTP.LOG
• https://entidades.sicoes.gob.bo/lib/WS_FTP.LOG
• https://tecsa.cl/swf/_notes/WS_FTP.LOG
• https://www.facilito.cl/web2/publicidad/basura/WS_FTP.LOG
• https://puracarne.cl/rticket/config.log
• https://www.cde.cl/webServices/sqlnet.log

Aunque no es muy común, tambien nos encontramos con servidores que publican logs de transacciones de Transbank o Webpay, como por ejemplo lo que sucede con el sitio de Swift.cl:

El cuarto y último error son los famosos dump de bases de datos. ¿Quien no ha hecho un mysqldump , pg_dump o lo que sea y ha subido el archivo a un servidor? El problema es cuando se nos olvida eliminarlo y queda accesible para cualquier persona. Aunque no lo parezca, es muy común. Preguntele a la gente de Nescafé que publican bajo elmonentofeliz.cl la base de datos de todos los concursantes

El archivo elmoment_feliz.sql tiene 7,3Mb de información con registros de la base de datos del portal web. Otros ejemplos:

• https://www.circulomayor.cl/wp-content/backup-db/1312804068_-_circulomayor.sql
• https://www.mmaya.gob.bo/separatas/concurso.sql

Como solución a mi problema como adminsitrador de sistemas y encargado de seguridad, la única opción que me dejaron los usuarios fue que yo periódicamente realizara busquedas de archivos comprometedores como *.sql, *.bak, *.old, *.php__, etc y los moviera fuera del directorio público.