Se necesita muy poco para hacer que su sitio sea vulnerable al ataque y, en el peor de los casos, incluso al servidor en el que reside. Esto es lo que sucedió con uno de los grupos editoriales sicilianos más grandes, gerente de un servidor que, como señalo en este artículo, es muy vulnerable.Posibles sitios que podrían estar involucrados en un ataque real?
¡más de 151!Me aseguré de corregir el error en los servidores del editor antes de publicar este artículo.
Hoy, 05 de junio, el proveedor gracias ;-)1 de junio de 22:00
Se inicia en una charla donde cierto Francesco[nombre ficticio], sin tener nada que hacer, me da los delitos, mostrándome tu sitio. Bueno, abro mi crédito Notrace.it, para más información sobre el dominio. Es administrado por el famoso editor siciliano. Veo que montadBlog 1.4.El sitio de Francesco
1 de junio de 23:00
voy a la cama [Pretend este punto no existe, pero debo añadir que era]2 de junio de 10:00
Se vuelve a una vulnerabilidad descubierta por mí en dBlog en agosto de 04 para ingresar a la administración del blog de Francesco. Busco el exploit en la carpeta cart D: Progettihacking Cartella, ábralo y ejecútelo.Abro el exploitEjecutar el exploit2 de junio, a las 10:05
Ingresé a la administración desde el blog. Lejos de las acciones lamelares / defacere, solo echo un vistazo. Ver la función "Subir".
El administrador del blog
3 de junio, a las 9.00 pmPienso en el blog de ... Francesco, regreso a la administración y miro la sección "Subir". Quiero intentar cargar un script ASP para tomar el control del servidor
[umm ... No tenía nada que hacer]
. Al ingresar la carga, veo que no hay limitaciones para los archivos que se cargarán.Seleccioné el exploitcontrollo.asp[¡qué nombre tan sugestivo!]
de mi PC. Hago clic en Cargar. El archivo está cargado.Sube el archivo cargado Exploit controllo.asp3 de junio de 21:15
entro //www.sitodifrancesco.it/public/controllo.asp.
¡Bingo!
Ninguna limitación de IIS puede ejecutarse libremente entre los archivos del servidor. Hard Disco duro del servidor3 de junio, 9:18 pmIntento buscar en los sitios web alojados por el servidor en la carpetaC: inetpub
, pero nada. Me da un destello de genialidad:
tratar de ver si hay unidad D:. La unidad existe y está la pomposa carpetasitiweb.[Te dejo adivinar qué contiene]Unidad D:3 de junio, 9:19 pmHaz clic en la carpetasitiweb
. Todos los sitios que residen en el servidor se me muestran libremente. Los sitios deberían ser más o menos 151, como lo muestra el número de subcarpetas (una subcarpeta = un sitio).
Sitios web alojados por el servidor3 de junio, 9:21 pmIntento ver si tengo acceso libre a los diversos sitios. Lo intento con la primera carpeta. IIS me permite ingresar fácilmente. Así que trato de escribir un archivo (páginamessage.htm
).
puedo crear un archivo en el servidor3 de junio de 21:23Después de dos minutos vacilante, el mensaje sobrio "File
escribió" me informa de que el archivo fue creado. Ir a la dirección del sitio y /message.htm
, de hecho esto existe.El archivo creado en el servidor3 de junio de 21:25luego borrar el archivo creado, y mi herramienta, recordando "controllo.asp? Action = toolcancella" Mi
herramienta ya no existe en el servidor 3 de junio de
, 21:30contacto con el editor, lo que indica que se puso a prueba el '(in) seguridad de sus servidores y diciéndoles que se han dejado intacto el registro, con el fin de comprender el modo de ataque utilizado. Mientras tanto, Francesco se convierte en "bueno".Como entendiste, no hice ningún daño. Pero pienso en unDefacer
: podría superar las protecciones, cargar un archivo ASP que reemplace todas las páginas de inicio o eliminar todo.
Este "paso a paso" no quiere ser una incitación a hacer daño, sino que solo quiere señalar cómo una aplicación web mal escrita puede facilitar el ataque a un sitio web (podría publicar mensajes en el blog) y también tomar control total del servidor.Lo que es imperdonable es la falta de limitaciones por parte de IIS (que ha sido mal configurado) y la presencia de permisos de escritura / modificación / eliminación en todas partes.