Un vistazo a lo de blogsperu.com

Nadie que cuente con al menos un computador conectado a Internet está libre de ser víctima de un incidente de seguridad, eso porque la seguridad absoluta no existe ya que esta debe entenderse como un proceso en constante evolución y no como un estado resultante de algún producto que ofrezca algún vendedor. Ante un incidente de seguridad como el ocurrido a blogsperu.com uno tiene dos alternativas : colocar nuevamente sus sistemas en un estado operativo o paralizar los mismos para hacer una investigación profunda de lo ocurrido. La opción a elegir depende de las necesidades de cada sistema y en el caso de blogsperu.com probablemente el mejor camino a elegir fue el de restablecer el servicio cuanto antes.






Se pierde entonces la posibilidad de hacer un análisis profundo de lo ocurrido - según recomendaría un especialista en análisis forense (prefiero este término porque es más fácil de traducir que "computer forensics" ) .

Aún así y sin tener acceso al servidor que aloja la página de blogsperu.com podemos obtener alguna información interesante alrededor de lo ocurrido:

¿Que servidor web emplea blogsperu.com?

Esto es muy simple de averiguar ,

C:\telnet www.blogsperu.com 80


HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Thu, 12 Jan 2006 08:13:46 GMT
Content-Type: text/html
Content-Length: 87

The parameter is incorrect.


Connection to host lost.

Internet Information Server 5.0 (IIS5) nos indica un servidor Windows 2000 (IIS6 para un Windows 2003) , además de esto hemos visto scripts .asp en la página de blogsperu.com. Incluso mientras revisaban el servidor de ayer recibí una página de error donde se indicaba la ruta hacia un archivo clsdatos.inc el mismo que revelaba datos como :

'************* Modex All Pages ***********************
dim Conn
dim sConnection
Set Conn = Server.CreateObject("ADODB.Connection")
sConnection = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & Server.MapPath("\xxxxxx\db\wlzma.mdb") & ";Persist Security Info=False"
sConnection = "Provider=MSDASQL.1;Persist Security Info=False;User ID=xxxxx;Data Source=xxxxxxxxx"
'********************************************************

(en negrita/bold la información ha sido eliminada al publicar este artículo pero está visible en el archivo original)

Esto me termina de confirmar que se trata de un servidor Windows/IIS

¿Quién es el proveedor de blogsperu.com?

Esto también es simple de determinar gracias a netcraft.com donde podemos determinar la información del proveedor de hosting lo cual nos informa acerca de ReadyHosting.com. Probablemente al revisar la página de este proveedor pueda obtenerse información acerca de los distintos planes de servicio y los programas/scripts que provee : Un atacante decidido emplearía cualquier medio que tenga a mano para tomar control de un servidor así que si no puedes entrar por el sistema operativo lo haces a través de alguna de las aplicaciones instaladas en el servidor.

Pero finalmente fue un script kiddie

Hasta ahora hemos obtenido bastante información acerca del servidor que aloja blogsperu.com y eso sin emplear ningún scanner de vulnerabilidades, ni siquiera se han escaneado puertos lo cual podría bajo algunas interpretaciones considerarse una falta a la Ley de Delitos Informáticos. Todo esto se basa en información públicamente disponible.

El script kiddie es un buen punto de partida. Los términos "HACKED BY LORD" y "Turkish Hacker" son más que suficientes para que Google devuelva varias páginas victimas de un defacement por parte de este individuo lo cual además de justificar el por qué lo denomino "script kiddie" también indica que no se trató de un ataque dirigido a blogsperu.com.

Averiguar cuál es la actividad que ha tenido este individuo tampoco es difícil si recurrimos a un archivo de defacements como www.zone-h.org , aplicando los filtros adecuados llegamos a un listado de todas las páginas víctimas de un defacement por parte de este individuo. Mirando el mirror de los defacements vemos una página similar a la que apareció en blogsperu.com y en la primera página del listado solo tenemos sevidores Windows 2003 , en la segunda página solo tenemos servidores Windows 2000. Si vemos la segunda página - porque solo lista servidores Windows 2000 al igual que blogsperu.com - nos encontramos con un listado de páginas sin relación entre ellas hasta que empezamos a resolver la dirección IP de algunas de ellas y encontramos que la mayoría de ellas (no revisé todas) tienen como dirección IP 65.163.26.171 y si resuelven la dirección IP de blogsperu.com van a llegar a la misma dirección IP. Esto es lo que se denomina un mass defacement aunque la definición puede abarcar más de una IP dentro de un mismo ataque.

Es así que el proveedor de hosting mantiene en un mismo servidor (la misma IP) bajo Windows 2000/IIS5 todas las páginas listadas y seguramente muchas más que fueron víctimas simultáneas de este script kiddie. Esto además podría indicar que se atacó alguna deficiencia a nivel del sistema operativo / servidor web (afectó a todas las páginas web allí alojadas) y no se trató de alguna deficiencia en alguno de los scripts o programas que de manera particular emplea blogsperu.com (el alcance habría sido mucho más limitado). Esto por supuesto no evita la necesidad de revisar el contenido del sitio web de blogsperu.com por si el atacante haya instalado scripts que le permitan seguir teniendo el control del servidor : básicamente la posibilidad de acceder a la línea de comandos del servidor de manera externa. (De ser posible haría una búsqueda de todos los archivos nuevos y/o modificados en la fecha del ataque )

Por lo tanto y en contra de cualquier teoría acerca de una conspiración contra blogsperu.com se trata una oportunidad aprovechada por algún script kiddie armado de algún script conseguido en alguna lista "full-disclosure".

¿Se puede culpar al proveedor por "negligencia" ?

Eso depende mucho del método empleado para vulnerar la seguridad del servidor. Si fue una vulnerabilidad antigua para la que se conoce desde hace mucho tiempo atrás un método correctivo ("parche" u otros ) la respuesta es sí y probablemente sea momento para buscar un nuevo proveedor de hosting. Si fue una vulnerabilidad reciente donde no hace mucho que se dispone de un método correctivo puede quedar la duda de si el atacante aprovechó la "ventana de oportunidad" ofrecida. ("Ventana de oportunidad" es el periodo que transcurre desde que se conoce un exploit para una vulnerabilidad hasta el momento que se aplican los métodos correctivos para contrarrestar el mismo). Y si finalmente se trató de un 0-day exploit no debería culparse al mismo.

Una reflexión final

La "seguridad absoluta" no existe - aún cuando algunos nos la quieran vender - por lo que la pregunta principal que uno debe hacerse no es ¿qué hacer para que no nos ataquen? . Lo que uno debe preguntarse es ¿qué hacer cuando me ataquen? ... eso me hace recordar que hace tiempo que no paso los archivos de backup desde el servidor a mi PC ...