dSploit: Pentesting & Hacking WiFi desde Android

dSploit es un aplicación de Android que reúne distintas herramientas para el análisis y pentesting de redes en una sola suite unificada. Permite realizar pruebas de seguridad de la red en la que se encuentra conectada el dispositivo móvil, lo que puede ayudar a hacer tests de seguridad en clientes que haya que auditar ad-hoc. Según la web de los creadores de la herramienta, esta aplicación ofrece el kit de herramientas más completo y avanzado para llevar a cabo este tipo de tareas, apoyándose en las características siguientes.

Figura 1: Comparativa de dSploit para Android con otras herramientas

En la imagen anterior, además de mostrar las características que ofrece la herramienta, hace una comparativa con algunas de las aplicaciones para Android más conocidas que realizan tareas similares, intentando recalcar su superioridad y complejidad. Por supuesto, no tiene porque ser la mejor, pero nos ha parecido más que interesante probarla y hablaros sobre ella.

Para poder instalar esta aplicación es necesario tener rooteado el sistema Android del terminal movil donde se vaya a instalar. Es posible que una vez terminado el proceso de instalación, la aplicación solicite la que se descargue también BusyBox. Por lo general, las distintas herramientas que se utilizan para rootear el movil o la ROM personalizadas ya incluyen BusyBox, sin embargo, podría darse el caso de que no esté instalada o que esta sea antigua.

Cuando a aplicación esté en el sistema opeartivo Android y se le haya dado permisos de superusuario, la pantalla principal que ofrece es una visualización con el mapeo de la red a la que estemos conectados, donde se listaran todos los dispositivos que hayan sido localizados. En esta pantalla se pueden realizar el listado de acciones que tiene que ver con el escaneo de redes WiFi y el cracking de claves conocidas de determinados tipos de puntos de acceso o routers.

Figura 2: Mapa de red creado por dSploit

También se puede observar en la parte superior derecha de esta pantalla el menú de botones que ofrece las opciones de lo que se puede hacer con la red:

- Especificar objetivos: La primera de estas opciones, representada con un signo ‘+’, permite especificar un objetivo concreto de forma manual a través de una dirección URL, introduciendo el nombre del host o la dirección IP que tenga configurada el equipo. 

- Nuevo escaneo de red: La segunda de ellas, representada con un par de flechas circulares, permite refrescar la lista de los equipos de la red, haciendo que se vuelva a realizar un mapeo completo de la red en busca de nuevos equipos conectados.

- Cambio de red WiFi y cracking: La tercera, que está representada con el símbolo de WiFi que utiliza comúnmente Android, permite cambiar de redes directamente desde la aplicación y, si fuera posible - en el caso de que uno de los routers fuera del tipo de los que la aplicación conoce el algoritmo de generación de claves por defecto que estos implementan -, el cracking de la clave de conexión. Esta acción solo tendrá un resultado positivo siempre y cuando la red WiFi conserve la contraseña por defecto.

- Menú de opciones: La cuarta y última de ellas, representada por tres cuadrados alineados verticalmente, en las que se puede encontrar las distintas opciones que ofrece la aplicación.

En cuanto se haya realizado el mapeo de la red y se encuentren los diversos dispositivos, presionando sobre ellos se pueden observar las distintas acciones que se pueden realizar para cada uno de ellos.

Figura 3: Acciones que pueden realizarse con dSploit en la red

En la imagen anterior se pueden observar todas las acciones que pueden realizarse, sin embargo, estas variaran dependiendo del tipo de dispositivo. Por ejemplo, en el caso de la primera acción de la lista (Router PWN), solo se puede realizar sobre AP al que se está conectado. Con esta opción es posible tomar el control del router utilizan el servicio que ofrece RouterPWN.

Al igual que hay acciones que se pueden realizar para un solo tipo de dispositivos, también hay elementos identificados en el mapeo que solo se pueden llevar un conjunto limitado de acciones, como es el caso del primero de ellos que se lista en el mapeo de la red. Este primer elemento representa a la totalidad de la red, el cual está representado por la NET_ID y la máscara de red, y solo permite llevar a cabo las acciones que se agrupan dentro de las herramientas de man in the middle. Estas acciones afectarán a todos los elementos detectados en el escaneo de la red.

El resto de los elementos que se encontraran en el mapeo son los distintos dispositivos que se encuentran conectados a la red, y se podrán llevar a cabo todas las acciones mostradas en la imagen, exceptuando la comentada anteriormente que solo aplica a los AP.

- Trace: La primera de esas opciones se encarga de identificar todos los saltos que se realizan para llegar al objetivo que fue seleccionado usando el conocido comando de red Trace.

- Escáner de puertos: Con el que se realiza un escaneo de tipo TCP SYN para obtener los puertos los puertos que el dispositivo tiene abierto.

Figura 4: Escaneo de puertos a un objetivo

. Inspector: S encargara de hacer un fingerprinting al dispositivo en busca de su sistema operativo y los servicios que pueda identificar.

Figura 5: Inspector de un equipo conectado a la red para hacer un fingerprinting

Para estos tres primeros casos, solo basta con seleccionar la acción, presionar el botón Start y esperar a que termine el proceso. Esto es así porque son funciones estancas que no necesitan mucho trabajo previo de campo para la configuración del entorno completo de pruebas.

- Búsqueda de vulnerabilidades y exploits: Para poder hacer uso de estas opciones es necesario haber realizado las tareas de escaneo de puertos y fingerprinting previamente, ya que la herramienta se basa en los resultados obtenidos en esos procesos para realizar la búsqueda de vulnerabilidades y de exploits en el S.O. y en los servicios detectados.

Para poder realizar la búsqueda de exploits en concreto, primero debe realizarse la búsqueda de vulnerabilidades y haberse encontrado alguna. Después ya se buscaran exploits relacionados con todas esas vulnerabilidades encontradas.

- Login Cracker: Se basa en los resultados obtenidos en el proceso de escaneo de puertos. Esta opción se encarga de intentar hacer un cracking del login de alguno de los servicios conocidos que se encuentran listados en la aplicación, especificando uno de los puertos de los que fueron encontrados, el juego de caracteres para la generación de contraseñas, el nombre de usuario de una lista que la aplicación ofrece, la longitud mínima y la longitud máxima de la contraseña a generarse.

Figura 6: Login Cracker en dSploit

De los requisitos antes mencionados habría que destacar que la aplicación permite agregar algún otro nombre de usuario que el usuario considere, sin embargo, solo se puede seleccionar uno a la hora de iniciar la aplicación. También permite especificar un conjunto personalizado de caracteres en caso de que se desee incluir alguno para la generación de las contraseñas. En cuanto a los caracteres mínimos y máximos, solo ofrecen un rango entre 1 y 6 caracteres.

- Sesiones: A partir de la release de finales de diciembre, esta herramienta está comenzando su integración con Metasploit, por lo que se ha añadido la opción de Sessions que permite manejar sesiones abiertas de MSF en un determinado host.

- MiTM:  Bajo esta opción se guardan todas las posibles formas de atacar conexiones en la red WiFi. Todas ellas se realizan en el protocolo IPv4 - habrá que esperar a una versión de Evil FOCA para Android -. Las acciones que se pueden hacer solo causan efecto sobre conexiones no cifradas. Las acciones de MiTM que posee esta herramienta pueden apreciarse en la siguiente imagen.

Figura 7: Acciones que se pueden hacer en ataques Man in the middle

Esta son la lista de herramientas que tiene introducidas dSploit en el equipo, y por lo que le hace tan poderoso y peligroso en un red WiFi en la que se conectan usuarios libremente cuando hace el ataque man in the middle entre la puerta de enlace y el objetivo seleccionado.

A) Sniffer simple: La herramienta redirecciona el tráfico del equipo seleccionado a través de ella a la vez que realiza la captura de éste y lo almacena en un archivo pcap que pueda ser analizado posteriormente en detalle por un poderoso WireShark. También arroja estadísticas de las direcciones IP detectadas junto con el ancho de banda que consumen y el total de bytes trasmitidos por cada una de ellas.

Figura 8: Sniffer simple

B) Snifffer de contraseñas: Realizará la misma acción que la anterior con la diferencia de que solo se ocupará y almacenará los datos relacionados a credenciales de autenticación de distintos protocolos, entre los que están aplicaciones que hagan uso de HTTP, FTP, IMAP, IMAPS, IRC, etcétera.

C) Sessión hijacker: dSploit captura las cookies de  sesión que circulan por la red, permitiendo secuestrar las sesiones activas. La aplicación lista todas las cookies capturadas una vez se inicie la acción y si se presiona sobre alguna de ellas permite realizar el secuestro de la sesión seleccionada.

Figura 9: Sesiones abiertas con cookies seguras o inseguras

Una vez pulsada una de estas sesiones capturadas se abrirá automáticamente dentro de la aplicación una vista de la web a través de la cual se puede navegar con la sesión seleccionada. El concepto es un hijacking de sesión clásico, pero con la facilidad que propuso Firesheep cuando se presentó oficialmente. Hoy en día existen multitud de herramientas automatizadas que hacen el Session Hijacking con la misma simpleza.

Figura 10: Sesión de Windows Técnico que iba por HTTPs secuestrada

D) Bloqueador de conexiones: la aplicación descarta todos los paquetes que recibe de la víctima, resultado esto en un bloqueo de la conexión del equipo sobre el cual estamos realizando el ataque.

E) Redirector: la herramienta redirige toda la navegación web de la víctima a una web que se le especifique sin importar la petición que se realice. Útil cuando se quiere lanzar un exploit de client-side para explotar un bug en el navegador sí o sí.

Figura 11: Opciones de redirección a una URL 

F)Reemplazar imágenes/vídeos: esta herramienta se encarga de sustituir todas las imágenes o vídeos que puedieran contener las páginas web consultadas. Se le debe especificar a la aplicación la imagen por la cual se deben sustituir las originales, ya sea a través de una dirección URL o mediante la selección de una imagen local del propio terminal móvil.

Figura 12: Artículo de Windows Técnico con las imágenes cambiadas por el mitm

Una vez aplicada esta acción, cada vez que se consulte una web no cifrada se sustituirán todas las imágenes que contenga la web, haciendo que la víctima cada vez que intente abrir una página con imágenes obtenga el siguiente resultado. Como puede observarse todas las imágenes de la web fueron sustituidas por una que se especificó a través de una dirección URL.

G)Inyector de scripts: la herramienta inyectara un código script en todas las páginas web visitadas por la víctima, haciendo que este se ejecute automáticamente antes de que el usuario pueda visualizar la web. Un ejemplo de ello podría ser un simple JavaScript con un alert (‘hola mundo maligno’) obteniendo el siguiente resultado.

Figura 13: Script inyectado en página web vista por la víctima

H) Filtro personalizado: la aplicación es capaz de reemplazar el texto de las web. Para ello se le debe especificar a la herramienta el texto que se desea buscar y el texto por el cual debe reemplazarlo.

Estas acciones de cambiar imágenes, texto, vídeos, código HTML o inyectar Scripts, fueron todas presentadas hace tiempo con The Middler, un framework para hacer justo esto, pero de forma masiva, pudiendo inyectar, entre otras cosas, el payload de BeeF Project y hacer así una JavaScript Botnet. Aquí tienes la presentación de la DefCON 17.

https://www.youtube.com/watch?v=Na7BpMnYH14

Figura 14: Conferencia sobre The Middler 2.0 en DefCON 17

- Packet forger: La última de las opciones que se pueden hacer sobre un objetivo - ya fuera del menú Man in the Midlle, es esta que permite crear y enviar un paquete personalizado al (ya sea TCP o UDP) objetivo seleccionado para poder hacer ataques personalizados cuando así se requiera.

Conclusiones

A groso modo estas son las acciones que se pueden realizar con esta herramienta. Como puede verse es una aplicación bastante potente y variada con la que se puede realizar distintos tipos de pruebas de la seguridad en redes desde un dispositivo móvil. Además, es una aplicación gratuita y de código abierto, lo que significa que es posible colaborar y seguir de cerca la evolución de esta herramienta a través de su página de Github.

La manera en cómo puedes colaborar reportando fallos, mejorando implementación del código de la aplicación, traduciendo la herramienta a idiomas no soportados o mejorando las traducciones ya realizadas, etc. Si estáis interesados en formar parte y colaborar con esta herramienta todo lo que necesitas saber lo puedes conseguir en la página web de dSploit.

Por otro lado, también la herramienta pone en manos de cualquiera un conjunto de potentes herramientas que se manejan de manera muy sencilla, así que ten cuidado si te conectas a una red WiFi pública, ya que puedes ver qué fácilmente te pueden hacer ataques que puedan dañarte.

Autor: Umberto Francesco Schiavo de Eleven Paths

Fuente: http://www.elladodelmal.com/2014/01/dsploit-pentesting-hacking-wifi-desde_18.html

Hackeando al vecino que me roba la WiFi

Buena entrada del maligno:

_________________________________________________________________________________

Hace unos meses, realizando pruebas de diferentes tipos de ataques sobre redes WiFi, dejé habilitada una red en casa con cifrado WEP, (eso sí, sin el SSID del operador con la contraseña por defecto predecible mediante las clásicas herramientas como Liberad a WiFi). Pasó el tiempo y dejé la red tal y como estaba, consciente evidentemente de que alguien podría querer invitarse algún día a la fiesta sin haber pagado la entrada, en cuyo caso ya mandaría yo a los de seguridad.

Pues bien, hace unos días, echando un vistazo a los Logs del servicio DHCP de mi router, cuál fue mi sorpresa al ver que además de la información de mis equipos, había una fila más con el nombre de host “Rober1”. En efecto, algún vecino estaba intentando utilizar mi red, y considerando que como poco había tenido que utilizar alguna herramienta para obtener la contraseña, podría tratarse de un vecino con conocimientos sobre hacking, aunque lo de poner su nombre en el hostname indicaba lo contrario (siempre y cuando no se tratara de un cebo). Por lo pronto, no conocía a ningún vecino llamado Rober o Roberto.

El primer impulso de cualquiera ante una situación así, podría ser el de cambiar el cifrado de la red a WPA2 con una clave robusta, y cortarle el grifo al vecino, pero los que nos dedicamos a esto de la seguridad, lo vemos como una excelente oportunidad para realizar una práctica con fuego real de hacking en redes de datos, al fin de todo, la red es mía y él es el intruso.

Como no disponía de mucho tiempo, pues esto me cogió justo antes de salir de casa a un compromiso ineludible, además de desconectar todos mis equipos de la red, y dejarle así todo el ancho de banda a “Rober1” para que se sintiese como en casa, mi primer paso fue poner rápidamente uno de mis equipos con Backtrack5, una antena WiFiy la suite Aircrack, a escuchar el tráfico de mi propia red en modo monitor. El objetivo era intentar obtener algún dato que me pudiese dar información acerca del vecino para conocer  sus intenciones, pues podría pretender simplemente utilizarme como ISP y ahorrarse la cuota mensual con esto de la crisis y los recortes, o “auditar” mis equipos, en cuyo caso debía prepararme para la batalla.

Al llegar a casa, y descifrar el tráfico capturado con airdecrypt, me dispuse a analizarlo utilizando en primer lugar la versión gratuita de la herramienta Network Miner, que corre en sistema operativo Windows y es muy útil a la hora de obtener una visión a alto nivel de una captura de tráfico. Una vez cargada la captura, Network Miner identifica todos los hosts presentes en ella, y reconstruye a partir del tráfico tramas, archivos, imágenes, mensajes de chat, credenciales y sesiones si se han capturado, peticiones DNS, parámetros GET.. Además proporciona información interesante sobre los equipos presentes en la captura, que por otra parte podría obtenerse con cualquier otro analizador de tráfico tipo Wireshark, pero facilita bastante la tarea.

Figura 1: Información del equipo presente en la captura con NetworkMiner

La primera lectura que podía realizar es que se trataba de un equipo con sistema operativo Windows, de nombre “Rober1”, que estaba utilizando mi red para navegar por Internet. Analizando las tramas y las conexiones establecidas, los sitios webs más visitados durante la sesión de navegación, que duró cerca de 20 minutos, eran los siguientes:

http://www.vanitatis.com
http://www.elpais.com/gente
http://devilwearszara.com
http://www.fotoplatino.com

En la siguiente imagen se pueden observar algunas de las imágenes descargadas durante la sesión de navegación:

Figura 2: Imágenes presentes en la captura analizada con NetworkMiner

Sin querer entrar en un debate y limitándome a relatar en este artículo cuáles fueron mis suposiciones y el proceso mental seguido, mi primera impresión fue que más que tratarse de un hacker, se trataba de o bien una hacker o bien la amiga, novia, madre, hermana o esposa de “Rober1”, pues eran todas páginas de  lo que yo considero “marujeo”, orientadas más a un público femenino.

Realizando un análisis más profundo con herramientas como CookieCadger o Wireshark, también di con información exacta del equipo que estaba utilizando para conectarse a Internet, identificando peticiones HTTP, correspondientes a la comprobación de actualizaciones disponibles para un Notebook Asus F50SL:

Figura 3: URL para comprobar las actualizaciones de Notebook Asus F50SL

El siguiente paso consistiría en intentar conseguir más información mediante un ataque man in the middle, para intentar obtener alguna credencial en algún sitio web donde tuviera que identificarse, pero para eso debería de estar en casa esperando justo en el momento en que mi vecino/a fuese a utilizar mi red para navegar. Para ello, utilicé Cain + Wireshark en entorno Windows, y también arpsoof en entorno Linux. Coincidimos un par de veces a la misma hora, pero resultó que en esas ocasiones el único tráfico que generaba mi vecino, era el correspondiente a visualizar vídeos en Youtube de bebés. Esto alimentó aún más mi sospecha de que se tratara de una mujer.

Por supuesto, en aquellas ocasiones en que coincidía conectado a la vez que mi vecino/a, antes de intentar un ataque MITM, me propuse escanear su máquina con nmap, pero los puertos estaban filtrados por el Firewall de Windows.

Seguía sin poder identificar al vecino, pues a pesar de tener acceso al tráfico que generaba, no existía ningún rastro de sitios donde se autenticara con credenciales. Ni correo, ni Facebook, ni nada en un principio. Los días fueron pasando, y cada vez era más difícil coincidir en horarios para realizar un MITM. Entre el trabajo y mi reciente estrenada paternidad, complicado cuadrar con el vecino/a.

Por otra parte, este tipo de ataque, no siempre funcionaba del todo bien, hecho que podía achacar también a la distancia del equipo a mi router, pero no penséis ni por un instante que lo iba a dejar así, ¡qué me estaba hackeando la WiFi!

Paralelamente a estos intentos, siempre mantenía mi equipo capturando tráfico WiFi en modo monitor, y analizaba las capturas, además de las que obtenía con Cain + Wireshark. En estas nuevas capturas, obtuve información interesante para el análisis.

Mi vecino/a se conectaba dos o tres veces al día, alrededor de 15 minutos cada sesión. Las páginas webs más visitadas seguían siendo de marujeo, como las comentadas en los párrafos anteriores, pero además habían accesos a las siguientes páginas:

http://elimperiodelaley.blogspot.com
http://quieroserjuez.blogspot.com
http://vidadeunaopositora.blogspot.com
http://sufridroaenejercicio.blogspot.com
http://quenovoyaserlasecretariadeunjuez.blogspot.com

Figura 4: Peticiones de DNS a blogs relacionados con oposiciones a judicatura

Analizando el nombre de los sitios web, así como el contenido que había en los mismos, me quedó claro que se trataba de una mujer, que estaba estudiando para oposiciones a judicatura. Es decir, que hablamos de una aspirante a juez robando WiFi. ¡Así va este país!. Por otro lado, entre todas estas sesiones de navegación, en las que los sitios webs visitados eran los mismos especificados hasta ahora, se colaban algunas sesiones cortas en la que los sitios visitados eran:

http://www.sport.es (Además leía la sección “El balón Rosa” ;) )
http://www.marca.com
http://tenerifedeportivo.com

Estas sesiones, en principio parecía que correspondían más a “Rober1”, leyendo periódicos deportivos y echando un vistazo a las novias y mujeres de los futbolistas. En una de estas sesiones, concretamente un domingo, Rober1 consultó también la página de Yelmo Cines, pero al final parece que no se decidió a ir, porque más tarde presuntamente su pareja se volvió a conectar a ver vídeos de bebés, y leer un poco de prensa rosa, supongo que para desconectar de las arduas sesiones de estudio para la oposición.

Por la información de la que disponía hasta el momento, se trataba de una pareja de vecinos que utilizaba mi red para conectarse a Internet y ahorrarse la tarifa del ISP, no de un hax0r con muchos conocimientos. Esto último me quedó más claro, cuando en una de las capturas recogidas escuchando en modo monitor, pude ver accesos a páginas de banca electrónica, algo que alguien con conocimientos de seguridad informática jamás haría desde una WiFi ajena.

Figura 5: Imágenes correspondientes a portal de banca electrónica

Afortunadamente para los vecinos, dieron con alguien que no tenía malas intenciones, y en esta ocasión, incluso de haberlas tenido, no podría haber hecho ningún destrozo, ya que al tratarse de tráfico SSL las credenciales no habrían sido capturadas sin romper el cifrado.

En este punto ya tenía claro el perfil de los “atacantes”, así como su nivel de conocimientos, pero aún no los había identificado. Los ataques man in the middle no funcionaban siempre, así que se me ocurrieron varias alternativas. La primera de ellas, enchufarles un troyano haciendo DNS spooffing con alguna de las direcciones de los sitios webs más visitados. Pero en lugar de eso, decidí implementar un esquema “machine in the middle”, colocando una máquina a modo de router, para asegurar que todo el tráfico que generaban pasaba por la misma.

Para ello, habilité una máquina virtual Backtrack, a modo de puente con dos interfaces de red. Una de ellas conectada a la red en cuestión, 192.186.1.0, y la otra en una nueva red 192.168.2.0, con la dirección IP 192.168.2.1. Además de eso, deshabilité el servidor DCHP del router al que se conectaban los vecinos, y arranqué un servidor DHCP en la máquina virtual, que repartiera direcciones en la nueva red, especificando como puerta de enlace la dirección de esta máquina en la nueva red, la 192.168.2.1. El tráfico generado era redirigido de una interfaz a otra, en aras de poder llevar el tráfico hacia y desde Internet a través del router principal.

Por otra parte, también arranqué la herramienta SSLstrip, redirigiendo el tráfico SSL al puerto 10.000, para poder así interceptar sesiones de autenticación en algún sitio web que permitiese obtener alguna información para identificar a los malhechores. En este script de shell se puede observar la configuración final.

Figura 6: Configuración que arranca el esquema bridge en el mitm

Con este nuevo esquema, los vecinos se conectaban a mi router vía WiFi, pero era la nueva máquina puente la que hacía de router para ellos, dándoles una nueva dirección IP en el rango 192.168.2.0 y ofreciéndoles salida a Internet. Bastaba con arrancar tcpdump, dsniff, y visualizar el log de sslstrip para poder controlar todo el tráfico generado por los vecinos.

El esquema no tardó en funcionar. La siguiente vez que se conectaron, todos los paquetes pasaban por la nueva máquina puente, y tras una o dos sesiones de navegación, el log de SSLstrip reveló su dirección de correo electrónico y su cuenta de Facebook:

Figura 7: Datos de cuenta Facebook capturados con SSLStrip

En este punto había completado mi análisis, y con un poco de Google Hacking a partir de su dirección de correo pude averiguar quiénes eran los vecinos, y confirmar que en efecto, se trataba de una pareja de abogados, ella estudiando para presentarse a una oposición de juez. Podría haberles hecho alguna trastada, como publicar algo en su muro, o cosas por el estilo, pero simplemente me limité a enviarles un correo informándoles de que estaba al corriente de lo que habían hecho, dándoles algunos detalles que les mostraran que efectivamente tenía conocimiento de sus sesiones de navegación, y advertirle de los peligros que corrían realizando este tipo de prácticas.

Me contestaron ofreciendo sus disculpas, comentándome que estaban avergonzados de su comportamiento y que no tenían mucha idea de lo que estaban haciendo, ya que fue “un amigo informático” el que les consiguió la conexión a Internet gratis.

Como ya todos sabemos, es impresionante toda la información que se puede obtener de una persona simplemente echando un vistazo a los sitios que visita en Internet, pero si además resulta que no sólo navega por páginas de información, sino que utiliza servicios de correo electrónico, redes sociales, o banca electrónica desde una conexión “robada”, el destrozo podría ser de dimensiones considerables.

Por motivos de protección de datos se ha sustituido el nombre real del equipo vecino por “Rober1”, pero el host original sigue la misma nomenclatura. Por otro lado quiero deciros que este artículo está hecho por si alguno de los lectores de este blog tiene una pareja de amigos que un día le piden que le robe la WiFi a algún vecino para conectarse gratis a Internet. Tened cuidado que, como decía Chema, la víctima del robo puede que también tenga también un amigo informático y les metas en un verdadero problema a tus amigos.

Deepak Daswani
(dipu.daswani@gmail.com)
(http://twitter.com/dipudaswani)

Fuente: http://www.elladodelmal.com/2013/04/hackeando-al-vecino-hax0r-que-me-roba_5.html

Un día de viaje: El blues (de la WiFi) del autobús

Muy buena entrada del maligno y sus colaboradores:

_______________________________________________________________________________

La disponibilidad de tecnologías WiFi “abiertas” cara al público que provén de Internet de forma gratuita, se ha convertido en una de las mayores facilidades que se le puede ofrecer a un usuario malintencionado para que lleve a cabo cualquier tipo de ataque sin dejar rastro de la identidad del mismo. Lugares como universidades, bibliotecas, restaurantes, bares, aeropuertos, etcétera, ofrecen conexión a los usuarios para que naveguen a sus anchas.

No hace mucho tiempo, volviendo en autobús de un viaje que tuve que realizar por motivos de trabajo, me dio por ojear el servicio WiFi que ofrecía la empresa para conectarse a Internet durante la duración del trayecto (que no era poco). Y como era de esperar existían multitud de direcciones IP (usuarios) que estaban utilizando dicho servicio.

Dejando de lado la multitud de ataques que se podrían realizar a los usuarios que están utilizando el servicio, ya que se supone que la WiFi precisamente se encuentra “abierta” para que todos los usuarios del autobús puedan conectarse y navegar sin ningún problema, decidí mirar qué “cacharro” era el que nos estaba ofreciendo el servicio y qué medidas de seguridad implementaba.

Figura 1: Portal del Router de Internet Móvil

Al primer intento de una de las contraseñas por defecto, ya me di cuenta que la respuesta se ofrecía por JavaScript y sin realizar ninguna petición a otra página, por lo que, la contraseña debería estar “incrustada” en el propio código de la página de acceso.

Figura 2: Alerta de contraseña incorrecta por Javascript

Con la ayuda de Firebug y un par de búsquedas vamos a intentar localizar la cadena exacta que nos interesa. Identificamos cómo existen varios tags “iframe” que están apuntando a distintos portales, los cuales pueden contener la cadena que estamos buscando. Entre ellos existe el fichero “/en/logo_idx.asp” que es el que contiene toda la parte de login.

Figura 3: Inclusión del iframe de autenticación

Cargamos el portal “/en/logo_idx.asp” dentro de nuestro navegador y visualizamos dónde se encuentra la cadena “Introduce tu contra..”, ya que se encontrará cerca de la zona del botón de submit, del que nos interesa saber qué función está realizando con la contraseña que introducimos nosotros en el “textbox”.

Figura 4: Función que se ejecuta cuando se envía la contraseña

Como se puede observar en la imagen anterior, al realizar el evento “onclick” del botón “Entrar” se está ejecutando a una función JavaScript llamada “LoginForm()”. Si buscamos dicha función en la pestaña de Scripts de Firebug, nos encontraremos con el siguiente código.

Figura 5: Contenido de la función JavaScript "LoginForm()"

Vemos que se está validando mediante la función “IF” el valor del elemento “password” con una variable llamada “admin_passwd”, la cual se encontrará inicializada en alguna parte del código. Mediante una simple búsqueda del nombre de la variable, damos con el valor que se inicializa la misma y con el correspondiente password del router.

Figura 6: Inicialización de la variable "admin_passwd"

A partir de aquí ya podemos acceder al portal del router y visualizar y/o modificar los parámetros de configuración.

Figura 7: Configuración Avanzada del Router Internet Móvil de Huawei

Y seguro que con toda esta información a muchos de vosotros se os ocurren muchos ataques man in the middle que se pueden realizar a los compañeros de viaje, pero ya bastante cansado es un viaje en autobús, como para que encima te roben la cuenta de Twitter, Tuenti o Facebook.

Figura 8: Usuarios conectados al servicio, potenciales víctimas

Como ya habréis leído y/o escuchado centenares de veces, la seguridad de las redes WiFi “abiertas” que ofrecen servicio a cualquier usuario sin ningún tipo de protección son de alto riesgo para los usuarios, pero quedan mucho más en entredicho si ni el propio fabricante del dispositivo utilizado para motarlas se preocupa de con qué grado de seguridad se están desarrollando sus dispositivos.

Un Saludo!! ;)

Autor: Daniel Romero, consultor de seguridad en Informática64

Fuente: http://www.elladodelmal.com/2011/12/un-dia-de-viaje-el-blues-de-la-wifi-del.html

Ver logs en tiempo real (espiar nuestras huellas)

Buenos días.

Hoy me encontraba realizando pruebas a un sistema donde casualmente por interfaz todo funcionaba muy bonito pero por debajo (log) mostraba diferentes errores.

La tarea a auditar estos aplicativos cuando no se tiene un patrón de reproducción se vuelve tediosa pues en este caso se tendría que realizar diferentes movimientos en el aplicativo e ir comparando contra el log. Cabe anotar que esto sucede muchas veces cuando el desarrollo es poco específico a la hora de escribir logs.

Partiendo de este punto tenemos dos problemas a atacar:

1. Tratar de reproducir el error a ciegas.

2. Comparar contra el log a ver cuando se reproduce.

Como sabemos ir mirando el log contra cualquier acción del sistema se vuelve una tarea laboriosa y quizás imposible pues un software normalmente esta compuesto de muchos módulos, así que vamos a ver una solución a este problema.

Que es un log?

Un fichero de log o registro es un archivo en el que se van anotando todos los sucesos que ocurren en determinado sistema, sirve como guía a la hora de fallar servicios o programas en un sistema.

Mostrar en pantalla los cambios de un fichero

Parar monitorear los logs en tiempo real recurrimos a una consola y un simple comando en nuestro sistema linux:

tail -f RUTA-AL-FICHERO

Ejemplo:

tail -f /var/www/apache2/logs/error_log

Con esto estaríamos verificando cada escritura de error en el log. 

Hasta aquí hemos ganado buen camino de la verificación pero dado que el aplicativo escriba mucha información esto hará mas difícil encontrar en que momento falla.

Para esta situación vamos a  usar la siguiente línea de comando:

tail -f RUTA-AL-FICHERO | grep "palabra clave a buscar el error"

Ejemplo:

tail -f /var/www/apache2/logs/error_log | Error

Con esto solo mostrara el momento en el que ha fallado y podremos disminuir el tiempo de estar mirando que esta escribiendo cuando pulsamos determinada acción.

Como lo hago en windows?

La opción mas rápida sería usar la versión tail para windows y también existe la versión grep pero existe una limitación y es que  no están en modo consola  haciendo mas difícil el uso integrado de dichas herramientas.

Para solucionar esto existe cygwin64 , y es exactamente igual la linea de comandos. Solo existe otra limitación donde se deben pegar los logs en un directorio con acceso a este.

Fuente:
http://andalinux.wordpress.com/2009/03/10/espiar-cambios-en-un-fichero-de-log/

Saludos jadcodianos.

Problemas al ingresar con un usuario al dominio de windows (AD)

Bueno días.

El día de hoy estaba auditando un sistema que se integra con el directorio activo de windows, lo primero es partir de la idea de crear un usuario en el dominio verificando que funciona con nuevos usuarios y los permisos establecido.

Se ha presentando un problema en el proceso donde al tratar de entrar al dominio este me devolve el siguiente problema : "You cannot log on because the logon method you are using is not allowed on this computer", dicho esto se deduce que la alerta es directamente de windows y no de la aplicación integrada.

Para organizar esto se debe hacer lo siguiente:

To Edit the Local Policy on a Windows(2000/XP/Vista)-Based Computer

1. Click Start, and then click Run.
2. In the Open box, type gpedit.msc, and then click OK.
3. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click User Rights Assignment.
4. In the right pane, double-click Allow log on locally.
5. Click Add User or Group, and then type User or Group then click OK.
   
   NOTE: If domain-level policy settings are defined, they may override this local policy setting.
6. Quit Group Policy Editor.
7. Restart the computer.

To Edit the Group Policy in a Domain

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point toPrograms, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console, right-click your domain, and then click Properties.
3. Click the Group Policy tab.
4. In the Group Policy Object Links box, click the group policy for which you want to apply this setting. Click Default Domain Policy.
5. Click Edit.
6. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click User Rights Assignment.
7. In the right pane, double-click Allow log on locally.
8. Click Add User or Group, and then type User or Group then click OK.
9. Close the Group Policy editor, and then click OK.

Troubleshooting

Group Policy changes are not immediately enforced. Group Policy background processing can take up to 5 minutes to be refreshed on domain controllers, and up to 120 minutes to be refreshed on client computers. To force background processing of Group Policy settings, use the Secedit.exe tool. To do this:

1. Click Start, and then click Run.
2. In the Open box, type cmd, and then click OK.
3. Type secedit /refreshpolicy user_policy, and then press ENTER.
4. Type secedit /refreshpolicy machine_policy, and then press ENTER.
5. Type exit, and then press ENTER to quit the command prompt.

Con esto ya funciona y podremos seguir a auditar la aplicación.

Saludos jadcodianos. 

Fuente: http://itshi-tech.blogspot.com/2010/02/you-cannot-log-on-because-logon-method.html