martes, 31 de enero de 2012

Smartphone, el mío es tan pilo que se gasta mi saldo...

Bienvenidos una vez mas a mi blog, en esta ocasion les traigo un tema del cual soy protagonista!!!

Hace unas semanas en vista de que mi nuevo móvil me permitía “muchas” cosas en comparación con el anterior, no dude en tomarme un tiempo y guardar las cuentas de correo, twitter, msn, etc; eso si teniendo cuidado de no guardar passwords (cosa que no debe hacerse, sin embargo con frecuencia vemos muchos por ahí lo hacen).
Durante la mañana entré a gmail, twitter, msn y antes de salir de la oficina como buen usuario sin plan de datos cerré todas cuentas, aplicaciones y me desconecte del acceso wifi.

Pero valla sorpresa me llevé cuando al llegar a casa e intentar realizar una llamada respondió el típico mensaje “su saldo esta vencido recuerde bla bla bla...”

Como pueden ver todo mi saldo se había consumido y en efecto no dudaba que todo se había ido en consumo de internet, ¿Cómo lo supe?, sencillo había en la parte superior de mi C3 la típica E que mostraba el acceso a internet a través de mi operador celular.



 “que mal, seguro olvide cerrar alguna aplicación” cosa que verifique enseguida pero no, todas las cuentas estaban cerradas, así como las aplicaciones...
...enseguida se me activo la paranoia ya que lo único que había hecho era acceder a las cuentas de correo e instalar unas dos o tres aplicaciones desde la tienda de NOKIA, así que llame al operador celular para pedir información del consumo de mi saldo, la respuesta como esperaba fue "señor rodallega, su saldo fue consumido por acceso a internet" pero eso ya lo sabía, así que se me ocurrió decirle a mi tan amable operadora ¿habrá alguna forma de que me den un extracto del consumo o información del destino del trafico que se está generando? ose por realizar esta pregunta ya que en realidad necesitaba saber que fue lo que consumió mi saldo, sin embargo la respuesta esta vez fue: "no señor esa información no la tenemos, pero si gusta puede ir personalmente a alguna sucursal en la cual le van a configurar su equipo para que no acceda a internet", bueno una vez más sin información y mejor no comento la posible solución que me dio la chica, a decir verdad a veces es mejor no discutir con estas chicas...

En estas condiciones decidí quitar todas las aplicaciones recientes de las cuales sospechaba, pero no, el consumo persistía, así que no me quedo de otra que mirar que pasaba con mi equipo por mi cuenta, de modo que no siendo más conecte mi móvil a la wifi y aquí comienza lo poco que hice…

…con acceso a internet desde mi móvil a través de la red wifi, tome mi PC me conecte a la misma red y abrí el tan útil cain & Abel, de inmediato con el sniffer activado realice la identificación de equipos usando el ARP-Scan




con el equipo identificado pero sin lograr capturar el trafico de este procedí a realizar un ARP-Spoofing o como lo llaman en esta herramienta ARP-Poisoning, esto con el fin de que el trafico pasara por mi PC, para los que quieren buscar un poco mas un ataque tipo "hombre en medio" o "man in the middle



una vez hecho esto pude capturar el tráfico desde el analizador de protocolos elite wireshark



en esta captura todo el trafico iba hacia un único destino, pero como pueden observar el trafico iba cifrado, en este punto me asuste ya que no había nada activo que generar trafico alguno...
...mas asustado que cualquiera, en la mente dije “miércoles, mínimo le instale algún bicho raro con alguna de esas aplicaciones“ como dije anteriormente todo el trafico iba cifrado, dirigido hacia el puerto 443 de la IP 66.54.67.75 siendo estas las únicas pistas que podrían brindarme algo de información y en un caso extremo tratar de jugar con el trafico https.
Con la IP de destino, me dirigí a whatismyip con el fin de obtener más información del destino del tráfico



La información obtenida en esta página me tranquilizo, debido a que como pueden ver el destino es uno de los tantos servidores de NOKIA; de modo que hasta este punto parte del enigma estaba descifrado, y lo único que quedaba era identificar cual aplicación era la que estaba conectándose a internet sin pedir autorización ni notificar.

Volví a mi móvil me desconecte del wifi y como era de esperar apareció de nuevo el acceso a internet a través de mi operador, así que mirando en las aplicaciones que restaban (las otras las había desinstalado) pude ver que la aplicación de correo tenia configuradas 2 cuentas una de hotmail y otra de gmail (ninguna con acceso automático) de modo que al ser una aplicación propia de NOKIA hacia parte de las candidatas y en efecto una vez elimine las cuentas pocos segundos después desapareció ese icono que me había a atormentado todo el día.

Como se puede ver no importa qué tipo de herramientas uses, lo que importa es como y para que, en este caso para verificar el destino del tráfico de mi móvil y no para molestar o tratar de acceder a informacion privada de otros.


Gracias por su tiempo una vez mas
Carlos Andrés Rodallega Obando
@crodallega

PD: Mirando por ahí en la web, se que más de uno ha tenido este problema espero y esto le sirva de algo

martes, 24 de enero de 2012

cafe internet, ¿tu ingresas informacion critica en estos sitios?

Bienvenidos una vez más a mi blog...

En esta ocasión el tema es algo muy de la vida diaria, en el cual la mayoría a pesar que sabe el riesgo que se tiene la negligencia supera todas las barreras.

La verdad me inspiro el hecho que cuando iba de regreso a casa el viernes en la noche, alguien en el bus le decía a su compañero  de asiento "ahora que lleguemos, va al internet de la esquina y consulta el saldo a ver si ya le pagaron"...
…esta escena me puso a pensar y dije ¡vaya aun hay gente que consulta sus cuentas bancarias desde cualquier sitio!, entonces decidí ¿por qué no gastar 30 minutos en un café-internet y generar algo de contenido?



Así que diseñe la estrategia y con la ayuda de mi amigo sebas llevamos a cabo el siguiente plan.
Con unas monedas que tenía en el bolsillo le dije a sebas que fuera a un café internet cercano,   mientras yo conectado a internet desde mi portátil en un lugar no muy alejado del mismo esperaba su inicio de sesión ya fuera en msn o en facebook, una vez inició sesión teniendo en cuenta que  ya antes había estudiado el objetivo en cuestión sabía que este no tenía un cableado estructurado sino que todo aquí era wifi…
… no siendo mas y  con el fin de hacer la cosas lo más sencillas y directas posible, así como  para evitarme configurar un re-direccionamiento de puertos o configurar una DMZ en el router, aprovechamos los privilegios del sistema en cuestión y sebas saco la contraseña de la red wifi almacenada en el equipo (sin ningún tipo de herramienta)


de inmediato me la envió por el MSN que por cierto bien infectado que estaba (mmm que mal por ellos, si tienes un negocio de estos debes velar que el cliente esté satisfecho)


Aquí vale la pena aclarar que en el caso en que no se hubiese podido sacar la contraseña de esta forma este hecho no habría sido tan difícil de obtener debido a que como pueden observar el cifrado en este caso era WEP (mas mal aun, gracias a los ISP y sus excelentes técnicos),  bueno pero en este caso este no era el objetivo final así que me conecte y una vez se tuvo acceso a la red simplemente era crear los ejecutables para un acceso remoto no tan dañino (no quería instalar nada) pero que me permitiera demostrar cómo y lo fácil que alguien con malas intensiones podría actuar para obtener la información critica de otras personas, por esto simplemente elegí usar meterpreter cuyas funcionalidades me permitían recrear el escenario en curso, así que usando msfpayload cree el ejecutable .exe


 y por si las moscas un visual basic script


los cuales los en codee usando el tan popular shikata_ga_nai con el fin de evadir el antivirus de nuestro objetivo, hecho esto como estaba dentro de la misma red del objetivo simplemente copie mis archivos magicos al directorio de publicación e inicie el servicio web

root@bt:#cp /root/meter* /var/www
root@bt:#/etc/init.d/apache start

de inmediato le envié la URL a mi compa y a través del navegador una vez desactivado el antivirus descargo el ejecutable sin problemas (el .vbs era para el caso en que el AV hubiese puesto problema)




 
en este punto lance el handler 


y le di la señal a sebas que corriera el ejecutable el cual una vez trasmitió lo necesario, abrió la tan esperada sesión de meterpreter.




En este punto solo quedaba sacar la evidencia para lo cual tome un screenshot del escritorio del equipo comprometido desde el equipo atacante 


cuyo resultado vemos a continuación (miren que la calidad de la imagen no es la misma, ya que debe ser pequeña para la trasmisión)


una vez hecho esto procedí a lanzar el key_logger 



y como necesitábamos generar información este abrió un blog de notas y digito algunas cosas,  una vez hecho esto simple mente fue hacer el volcado de lo que había capturado el key-logger




como se puede ver escribió cuenta bancaria número 112365478996.12239824,  lo cual se puede verificar con la imagen del screenshot del blog de notas




ya para terminar con este entretenido escenario, simplemente obtuve a través de la sesión de meterpreter un intérprete de comandos, con del cual obtuve información de la configuración de red del sistema


y porque no un listado de los archivos del directorio en el cual me encontraba, en el cual se pudo encontrar la hoja de vida de 4 personas, 1 en formato pdf y 3 en .doc, mostrándome una vez mas lo descuidada que es la gente con su información personal (¿como dejan en un PC publico esta información?, ya tengo el toque paranoico, lo sé), adicional a esto encontramos una que otra foto, así como nuestro ejecutable y algunas hojas de cálculo que por sus nombres parecían cronogramas de trabajo. 




En este punto con la evidencia obtenida solo fue enviar los screenshot que había tomado Sebastián y eliminarlos junto con el ejecutable, ya que la intención era netamente didáctica y debíamos dejar las cosas como las encontramos.
Como pueden ver en realidad lo que hicimos fue algo supremamente sencillo, todo lo contrario al post anterior en el cual se usaron varias herramientas y  técnicas que pueden ser no tan usables para cualquier persona. 

Ahora, si fue tan fácil esto, ¿se imaginan la cantidad de personas que hacen esto a diario? y además ¿se imaginan lo que se puede hacer con herramientas especialmente desarrolladas para espiar?...
…los dejo con la inquietud, no siendo más espero y este post haya sido de su agrado y hasta una próxima entrada.


Carlos Andrés Rodallega Obando
PD: gracias al viejo sebas por su colaboración!!!


lunes, 16 de enero de 2012

Hackademic.rtb2 un solucionario with nails

En vista que en varias ocasiones me han preguntado cual es mi blog y cosas por el estilo, he decidido iniciar con este, asi que sean todos bienvenidos y espero sea de agrado para ustedes.

Para iniciar me he inclinado por un solucionario que realice de el entorno publicado en sec-track por 4v4t4r hackademic.rtb2, asi que no siendo mas iniciamos...

Una vez ha iniciado los entonos target y atacante iniciamos realizando un típico barrido de pings root@bt:~/hackademic2# nmap -sP 192.168.209.1-255


Donde se identifican 3 host activos (pueden haber mas) de los cuales descartamos los 2 últimos debido a que el de IP .131 es nuestra maquina atacante y el .254 es la interface que configura vmware cuando usamos el modo solo host, haciendo uso de la misma herramienta (nmap) y con base en la información recolectada realizamos un escaneo de puertos a partir del cual tenemos 2 puertos activos 1 abierto y 1 filtrado.


Mirando los resultados que nos da nuestra herramienta tenemos el puerto 80 abierto y en vista que es un servicio de http ingresamos a través de nuestro navegador web.


Como podemos ver nos presenta una página de inicio de sesión la cual al ingresar cualquier parámetro (no valida al parecer) "procesa" la información y muestra que las credenciales no son correctas.



La verdad inicialmente aquí fue donde me quede varado (después de probar varias cosas con el phpMyAdmin que narro más adelante) pues a mi parecer y según la información que nos muestra la interface inicial una vez lograra saltar el logueo se iba quitar el filtrado del puerto.

Aquí les comento que probé con técnicas de SQL-Injection, LDAP-Injection y hasta X-Path-Injection (con esto solucionan el reto de dragonjar para principiantes) en realidad en este punto me sentí bastante frustrado, al punto que descargue por 2da vez la imagen del reto.
De la misma manera con el fin de recolectar más información mientras a la par probaba con las técnicas antes mencionadas corrí nuestro escáner de vulnerabilidades para aplicaciones Web nikto cuyo resultado fue el siguiente
root@bt:/pentest/web/nikto# ./nikto.pl -h 192.168.209.128 -Cgidirs all -mutate 1 -mutate 2 -mutate 3 -mutate 4
- Mutate is deprecated, use -Plugins instead
- Nikto v2.1.4
---------------------------------------------------------------------------
+ Target IP: 192.168.209.128
+ Target Hostname: 192.168.209.128
+ Target Port: 80
+ Using Mutation: Enumerate user names via cgiwrap (/cgi-bin/cgiwrap/~user type requests)
+ Start Time: 2011-12-16 22:40:25
---------------------------------------------------------------------------
+ Server: Apache/2.2.14 (Ubuntu)
+ Retrieved x-powered-by header: PHP/5.3.2-1ubuntu4.7
+ Apache/2.2.14 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.
+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.
+ OSVDB-12184: /index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-3092: /phpmyadmin/: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 6448 items checked: 1 error(s) and 7 item(s) reported on remote host
+ End Time: 2011-12-16 22:41:20 (55 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

A partir del cual ya teniamos un poco más de información de nuestro objetivo en este caso le di importancia al phpMyAdmin, pero para poder realizar cualquier acción y establecer si este es un posible punto de intrusión era necesario recolectar algo más de información por lo cual y con el fin de automatizar las cosas procedí cual principiante (muchas veces he pasado cosas por alto por pensar que eran demasiado obvias), así que tomando la ruta completa del phpMyAdmin procedí a realizar una enumeración con dirbuster y uno de sus tantos diccionarios.


Como podemos ver no solo me obtuvieron los directorios y archivos que estaban a su nivel sino que también se logro enumerar los de la raíz como lo es check.php; en este punto me incline por la URL http://192.168.209.128/phpmyadmin/Documentation.html la cual nos revela información del phpMyAdmin que está en la maquina objetivo en este caso 3.3.2


Teniendo información detallada del phpMyAdmin realice la búsqueda de varios exploits iniciando por metasploit, cuyo exploit no aplicaba para la versión de nuestro objetivo


De inmediato el paso a seguir fue buscar en la base de datos de exploitdb (actualizada claro está) donde se encontraron varias opciones de las cuales se seleccionaron los que correspondían a la versión de phpMyAdmin en este caso tenemos 17510.py & 17514.php


Los cuales fallaron y como lo dijo @nonroot en su solucionario del presente entorno, lo más probable es que fue debido a que estos requerían de un directorio especifico con permisos de escritura.


En este punto ya lo único que faltaba por descartar era el puerto 666 cuyo estado es filtrado una vez más volviendo al punto en el cual me quede prácticamente varado, pues no sabía cómo acceder al puerto filtrado (quizá como su estado lo indicaba, había algún tipo de filtrado que permitía solo recibir peticiones de cierto tipo o desde un determinado origen) así que envié peticiones al mismo de diversas formas, pero ni su estado ni la respuesta del mismo cambiaba.
En el momento en que @nonroot publico su solucionario pude verificar que el procedimiento que llevaba era el adecuado, así que de inmediato verifique el paso a seguir y me di cuenta que el escaneo SYN que había hecho previamente sobre el puerto era el adecuado (había visto el video que publico en dragonjar mi amigo Javier Gaviria) sin embargo no sabía que se debía realizar el escaneo SYN sobre todos los puertos; así que procedí a ejecutar el escaneo de la siguiente manera (la verdad me toco hacerlo 2 veces para que el puerto cambiara su estado, ¿por qué?, ¿sería por eso que no abrió cuando hice el escaneo SYN inicial?)


Como se puede ver una vez el puerto cambió de estado, se procedió a verificar que Servicio era el que gestionaba este puerto.
De inmediato se accedió a través del navegador web Firefox, el cual nos presento una aplicación en joomla como nos lo mostraba el logo de la URL, así como la información del mismo en el footer en este caso joomla 1.5


Sin embargo era necesario realizar la respectiva verificación accediendo al código fuente de la página, en el cual se encontró la misma información más detallada.


Al identificar la versión del joomla sonreí debido a que hace un tiempo a través de una vulnerabilidad en el modulo para restablecer las contraseñas de una versión de joomla similar logre cambiar la contraseña del administrador, y acceder de manera satisfactoria, de modo que en esta ocasión al verificar las URL /administrator y /configuration me desinflo ya que no se podía iniciar sesión a través de estas. Siguiendo de la misma forma que en el puerto 80 ejecutamos nuestro scanner de vulnerabilidades nikto sobre el mismo host pero en el puerto 666


No siendo mas probé de nuevo con los exploits que se había probado para el phpMyAdmin ya que este también correspondía a la misma versión 3.3.2 pero como con el anterior los exploits no funcionaron, de esta forma no quedaba más que analizar la aplicación basada en joomla buscando alguna vulnerabilidad en alguno de sus componentes, buscando en exploitdb filtrando por el nombre Joomla encontramos 861 exploits potenciales
root@bt:/pentest/exploits/exploitdb# ./searchsploit joomla | grep -c Joomla
861
Sin embargo no todos aplican para la versión objetivo, así que filtrando se obtuvieron menos opciones de las cuales se procedió a probar los exploits genéricos (sin componentes).


(Si es de utilidad para alguien ahí esta seleccionado el exploit para cambiar el password que mencione antes)
Después de modificar y lanzar varios exploits como el del tiny sin éxito, no quedaba más que verificar los componentes de la aplicación y buscar información de fallos y exploits para estos. Explorando la aplicación se encontraron los componentes (como la idea es hacer todo casi a mano lo hago recorriendo la aplicación y mirando en la URL)
detectando com_user


detectando com_abc

detectando com_mailto

Buscando en la base de datos de exploitdb encontramos que con el filtro mailto no aparecen exploits, con user aparecen varios pero ninguno para el componente com_user y el único encontrado y potencial es el del com_abc


Al lanzar el exploit este nos retorna el volcado de usuarios y passwords del sistema, sin embargo al mirar con detalle podemos verificar que este lo que realiza es un SQL-injection, el cual podemos usar para obtener información adicional (modificándolo).


Una vez tenemos el volcado procedemos a mirar el resultado desde nuestro navegador web usando en mi caso la URL http://192.168.209.128:666/index.php?option=com_abc&view=abc&letter=AS§ionid=-null+union+select+1,concat%280x3a,username,0x3a,password,0x3a%29+from+jos_users--


En este punto vamos volver a una injection básica para desde aquí iniciar como si fuese cualquier otra appWeb.


Verificamos el usuario de acceso a la DB (un fallo garrafal)


Verificamos la versión del MySQL


Intentamos leer el archivo /etc/passwd con la URL http://192.168.209.128:666/index.php?option=com_abc&view=abc&letter=AS§ionid=-null+union+select+1,load_file%28%27/etc/passwd%27%29--

El reto nos dice que debemos leer el archivo key.txt del directorio de root, así que de inmediato tratamos de acceder a él a través de esta página, sin embargo no fue posible, así que la única opción por el momento era ser un poco mas intrusivos de modo que usando el mismo load_file trataremos de leer los archivos de configuración de joomla teniendo en cuenta la estructura de directorios de ubuntu que es el sistema en cuestión (Existen diversas formas y herramientas que permiten esto, pero en este caso lo encontramos en el reporte del nikto y al verificar la versión de MySQL).
El paso a seguir en este punto es intentar leer el archivo /var/www/index.php


Como la lectura fue exitosa solo quedaba leer el archivo de configuración para extraer el nombre de usuario y contraseña de conexión a la base de datos


Como podemos observar tenemos el nombre de usuario root y el password yUtJklM97W
Accedemos a través de nuestro navegador web


Y exploramos la base de datos de joomla, donde podemos ir directamente a la tabla de usuarios jos_users, en la cual podemos editar y de la misma forma agregar o eliminar usuarios como vemos en la imagen a continuación.


Lo anterior se puede decir que es el santo grial para algún chico con ganas de darse golpes de pecho modificando un sitio web y poner su nombre en el mismo, algo como lo que hice a nuestro entorno y que se nuestra en la imagen a continuación en la cual edite el contenido inicial desde la tabla jos_content.


Aunque lo que quiero en lugar de modificar la aplicación es insertar código php para que sea interpretado y ejecutar comandos desde la aplicación Web

Sin embargo nuestra prueba de concepto falla, debido a que todo este contenido se va en un echo y no alcanza a ser interpretado, así que no queda de otra más que aprovechar los privilegios que se tienen y tratar de exportar con outfile en el directorio de publicación de apache, así que probamos con una consulta simple que exporta a un archivo de nombre salida2.txt


Cuyo resultado se pudo accesar través de la URL http://192.168.209.128:666/salida2.txt

De la misma forma creamos un archivo php para verificar si los archivos que se crean tienen permisos de ejecución


Verificamos en la url http://192.168.209.128:666/info.php


Y como el resultado es satisfactorio solo creamos nuestro intérprete de comandos de la misma forma


A la cual accedemos de mediante la URL http://192.168.209.128:666/interprete.php?cmd=pwd


De esta manera verificamos el usuario actual


Procedemos a subir una webshell(my conocida) usando el comando wget


Accedemos a nuestra webshell
Y a parte de navegar entre los directorios, ejecutar comandos, etc; tratamos conectamos usando la shell inversa


Sin embargo no fue posible establecer la conexión debido a que esta presentaba un error de lectura y escritura, así que lo único que quedaba era recurrir a una de las shell inversas en php que encontramos en la parte de backdoors de backtrack, de manera que la subimos en el servidor y la ejecutamos desde el navegador de a través de su URL correspondiente
Para esta conexión era necesario poner en escucha el puerto configurado en la Shell en este caso haciendo uso de la navaja suiza netcat


Una vez tenemos la conexión verificamos el usuario de la misma asi como la ubicación y lo que en este punto más nos interesa información detallada del sistema.


Con base en esta información buscamos un exploit para escalar privilegios de forma local y lo subimos al servidor, esta parte me falto documentarla pero les comento que exploit cuyo nombre en los directorios de exploitdb es 14814.c, con el cual se logro de manera satisfactoria elevar privilegios en el sistema y de esta forma leer al archivo Key.txt


Este archivo contiene un texto que es una codificación en base64 de un gran tamaño, así que lo copiamos en el directorio /var/www y desde la maquina atacante lo descargamos


Como ya se dijo este es una codificación en base 64 la cual decodificamos de la siguiente manera


Como se puede observar al inicio del texto tenemos que este es un archivo .png motivo por el cual volvemos a decodificar pero exportando todo a un archivo que llamare imagen.png
root@bt:~/hackademic2#base64 –d key.txt >>imagen.png
La imagen resultado de la decodificación se presenta a continuación.


Espero y les haya gustado a pesar que se usaron los mismos fallos que uso @nonroot en su solucionario, sin embargo la idea a parte de presentar la solución detallada de este escenario, era realizar las cosas de la manera más manual posible (with nails) ya que existen múltiples herramientas que permiten agilizar las cosas, pero cuando se está arrancando ayudan mas este tipo de guías.

Saludos a todos y gracias por el tiempo que le dedicaron a esta lectura
Att: @crodallega (R0gu3r comunidad DragonJAR)

PD: Gracias a D7n0 porque me motivo a escribir esta guía y me iba a dar el espacio en su blog pero ahora está un poco corto de tiempo y claro a nonroot que me desvaro (la verdad el hecho de que es muy facil kedarse en un punto eso es lo que no me gusta de los CFT)!!!