29 jun 2016

#HSTS. ¿Qué es y cómo lo implanto en mi empresa? Parte 1

Buenas a todos, en el post de hoy me gustaría hablaros de HSTS (HTTP Strict Transport Security), la especificación de la RFC 6797 motivada por el Force HTTPS, que fue publicada el 19 de noviembre de 2012, y que aunque ya lleva más de 3 años entre nosotros, en las empresas es un gran desconocido y es un "must" en los informes de auditoría de hacking ético web que sale casi siempre, como el típico banner del servidor expuesto, o las vulnerabilidades de CSRF.

Tal y como explicó hace un par de años David Cantón en el blog de Incibe:
HSTS define el mecanismo, o procedimiento que deben seguir tanto el servidor, como el navegador web (o más genéricamente un "User Agent") para que interactúen de forma más segura, usando exclusivamente comunicaciones seguras, como HTTPS gracias al uso de protocolos de transporte seguros como son TLS/SSL. Esta especificación sería una alternativa al uso de otros protocolos de transmisión de información como SPDY, el cual por definición utiliza comunicaciones siempre cifradas. 
El soporte de esta especificación por parte de los servidores y navegadores web conlleva una considerable mejora en la seguridad y privacidad de las comunicaciones de los usuarios. En este artículo describiremos brevemente tanto el objetivo de la especificación como su funcionamiento. 
Como define su especificación, el objetivo de HSTS es la mejora de la seguridad en las comunicaciones web centrándose en tres tipos de amenazas o ataques:
  • Ataques de red pasivos, aquellos en los que un atacante está escuchando todo el tráfico, como por ejemplo en una red WiFi, con el objetivo de obtener información de comunicaciones no cifradas, llegando en algunos casos a poder robar información sensible como la sesión de los usuarios.
  • Ataques de red activos, en los que los atacantes actúan sobre la propia red inyectando datos, suplantando elementos de la red, redirigiendo los comunicaciones, …
  • Errores cometidos por los desarrolladores del sitio web, como el uso de conexiones no seguras para descargar elementos como recursos de la web (CSS, JavaScript,…) o el envío de datos.
En resumidas cuentas, lo que permite HSTS es informar al navegador que las conexiones al sitio deben utilizar SSL o TLS, definiendo el modo en que deben actuar navegador y servidor, Para reaizar esta información e indicar al navegador que esta especificación se encuentra soportada, se hace uso de un campo en la cabecera de respuesta (Strict-Transport-Security).

A continuación os comparto una imagen publicada por el departamento de defensa de Australia, explicando el proceso de comunicación con HSTS:



Los principales navegadores del mercado la incorporaron rápidamente:
  • Google Chrome: admitido desde la versión 4.0.211.0.21.
  • Firefox: admitido desde Firefox 4 y en la 17 proporciona ya una lista de sitios web que soportan HSTS.
  • Opera: admitido desde la versión 12.
Por lo que resuelto el problema del lado del cliente, ahora el problema proviene de las aplicaciones y los servicios ofertados por las empresas. Que en muchas ocasiones, por grandes que sean los proveedores, es sorprendente ver lo difícil que es para ellos realizar un cambio de estas características.

¿Qué pueden hacer nuestras empresas para comenzar a soportar HSTS?

La verdad que no es un cambio complejo, ni que requiera abrir un proyecto muy grande. Aunque seguro que en algunas empresas es un quebradero de cabeza por problemas de redirecciones...

En el caso de Apache, se puede agregar al archivo .htaccess la siguiente línea
Header always set Strict-Transport-Security "max-age=10886400; includeSubDomains"
En el caso de IIS, se puede agregar el siguiente código en el web.config del site:
<system.webServer><httpProtocol><customHeaders><add name="Strict-Transport-Security" value="max-age=10886400"/></customHeaders></httpProtocol></system.webServer>
En el caso de nginx, se puede agregar la siguiente línea de código en el fichero nginx.conf:
add_header Strict-Transport-Security "max-age=10886400; includeSubDomains";
En PHP podríamos agregar un código como el siguiente (via Wikipedia):

$use_sts = true;

// iis sets HTTPS to 'off' for non-SSL requests
if ($use_sts && isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off') {
    header('Strict-Transport-Security: max-age=10886400; includeSubDomains; preload');
} elseif ($use_sts) {
    header('Location: https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'], true, 301);
    // we are in cleartext at the moment, prevent further execution and output
    die();
}

Siempre se trata como podéis ver de añadir el parámetro max-age, indicando el tiempo de duración en segundos de la comunicación HTTPS de navegador con servidor. 

Esto es todo por hoy, pronto publicaremos la segunda parte del artículo con nuevas medidas de defensa HSTS, y potenciales ataques.

Saludos!

27 jun 2016

Weeman: Un nuevo framework para el phishing

Las pruebas de concienciación sobre una organización son muy importantes. Sabemos que de nada vale disponer de los mejores sistemas de seguridad, los mejores antivirus, los mejores IDS o IPS, si luego un empleado de cualquier departamento cae en un simple phishing. Ya lo vimos con los ataques SAPPO. Las organizaciones necesitan disponer de una política de seguridad que sea propuesta y aceptada desde la dirección hacia los empleados. En esta política deben aparecer los roles y los responsables de la protección de los diferentes activos clasificados de la organización. Es una forma de hacer ver a los empleados, de diferentes niveles, que la información que ellos manejan día a día es importante para la organización. En muchas ocasiones olvidamos que el activo más importante que hay que proteger es la información. Llegamos a la conclusión de que la seguridad no existiría, si no hubiera que proteger dicho activo. 


Dicho todo esto, hay que tener claro que la concienciación dentro de una organización y la formación, a diferente nivel, de los empleados para hacerles ver qué cosas pueden suceder y cómo se pueden prevenir ciertas amenazas es realmente importante. Hoy en día, muchas organizaciones se han dado cuenta de esto. Por esta razón, realizan simulaciones de APT contra empleados o conjuntos de muestra de la organización. En este conjunto se suelen coger diferentes cargos de dirección, responsables de áreas, gente de IT, incluso, ¿Por qué no? Gente de la parte de seguridad.

Sin una política de seguridad, concienciación, formación y conocimiento no existirá una base lo suficientemente fuerte en una organización para que sus activos estén dentro del riesgo asumible por una empresa. Si nos fijamos en el modelo defensa en profundidad, precisamente su base es esto:


Quizá una de las herramientas de ingeniería social más famosas es SET, Social Engineering Toolkit, pero hoy hablaremos de Weeman, un nuevo framework que promete bastante en el uso de herramientas orientadas al phishing. La posibilidad de enviar emails falsos, de clonar sitios web y poder controlar las redirecciones, una vez introducidas las credenciales, son características mínimas que se piden a un framework orientado a esto. Lógicamente la intención del autor de la herramienta es la de que su framework se pueda utilizar en simulaciones de APT o pruebas de concienciación en las organizaciones y no para delinquir. 

Weeman: Un vistazo

Weeman presenta un entorno de consola con interacción mediante comandos. Escrito en Python, permite que los usuarios puedan escribir sus propios módulos de manera sencilla. Todo se encuentra en la doc del proyecto en Github

Las opciones que Weeman presenta son las que se pueden visualizar en la imagen. Los comandos pueden recordar a los de entornos como Metasploit o Powershell Empire. Para extender la funcionalidad y ejecutar módulos se dispone del comando framework. Este comando sitúa al usuario en otro contexto dónde se podrán ejecutar pequeñas herramientas que pueden ser necesarias, como por ejemplo un whois, un módulo que extrae los enlaces de un sitio web, o simplemente saber si una máquina se encuentra levantada o no. A día de hoy, Weeman no dispone de una gran cantidad de módulos, pero lo cierto es que promete. 


Con la opción show se pueden visualizar las diferentes opciones que se pueden utilizar a la hora de realizar la copia del sitio web y puesta en marcha del sitio fake. A continuación se enumeran las opciones que se pueden configurar:

- Action_URL. El método que se utilizará, por ejemplo POST.
- Clear. Permite limpiar la pantalla.
- HTML_File. El recurso HTML si se tuviera una copia ya realizada o customizada. En este punto se podría utilizar recursos generados, por ejemplo, con el Social Engineering Toolkit. 
- URL. Este recurso es necesario de settear. En este caso se indica la dirección URL que se quiere clonar. 
- Banner. Se puede configurar el tipo de banner que se quiere mostrar.
- External_js. Se puede configurar un recurso JS externo. Esto podría ayudar al pentester a la hora de realizar una petición a otro servidor, por ejemplo, en los ataques client-side o watering hole. 
- Port. Se puede configurar el puerto dónde se levantará el servidor, por defecto es el 8080.
- User_Agent. Se puede modificar el User Agent en el caso de que algún plugin tenga que realizar peticiones.

PoC: Clonando y levantando un sitio falso

En esta prueba de concepto se utilizarán 3 sitios de interés. El primero será Gmail, el segundo Outlook y el tercero Shodan. Para indicar el sitio que se quiere clonar se deberá utilizar set url https://gmail.com, y en el caso de Outlook y Shodan sus respectivas direcciones URL. 


Como se puede visualizar en la imagen se ha levantado un servidor web en el puerto 8080, ya que se dejó por defecto. Weeman se encarga de modificar el HTML con lo necesario para capturar las credenciales y realizar la redirección. Lo llamativo es que en su Github indican que el framework intenta loguear al usuario víctima en el sitio original. En las pruebas que llevé a cabo con esta herramienta esto no se logró. En la siguiente imagen se puede visualizar como el sitio web falso es un clon del original. 

Al introducir las credenciales del usuario la herramienta Weeman irá mostrando, tal y como hace por ejemplo SET, las credenciales. 


En el caso de Outlook y Shodan la configuración sería idéntica. Con la instrucción set url [dirección URL] cambiaríamos el sitio web a clonar y ejecutaríamos. En el caso de Outlook tan sencillo como set url https://outlook.com, pero en el caso de Shodan, el login no está en el sitio web principal por lo que sería set url https://account.shodan.io o set url https://account.shodan.io/login. El resultado es una página clonada, exactamente idéntica a la original. 


Al introducir el usuario y contraseña en el sitio web, Weeman lo muestra rápidamente, tal y como se puede visualizar en la imagen. También se puede visualizar como después de obtener las credenciales se lleva a cabo la redirección.


¿Cómo llega un usuario a un phishing? Las empresas deben ser conscientes que existen múltiples vías:

- Algunos usuarios piensan que navegando no se puede caer en un phishing, lo cual es un error. Existen sitios web por Internet que son phishing que se encuentran ahí. La capacidad de utilizar dominios “semejantes” a los de verdad o qué podrían encajar con la marca, proveedor o servicio que se suplanta es un caramelo para los phishers. En Pastebin se puede encontrar un listado de dominios que son phishing y echando un vistazo rápido se puede ver que los dominios son similares a sus marcas.


- Recepción de emails de dudosos remitentes. Es un clásico, quizá el más conocido el SPAM Phishing. No hay que dejar de lado el Spear Phishing, con el que mediante detalles como el nombre de la víctima, datos personales de la víctima, etcétera, se intenta crear confianza en dicho email. Un banco, una operadora, un proveedor nunca pedirá a un usuario que envíe sus credenciales a través de un email. 
- Enlaces en foros o redes sociales. Este es un mecanismo que ha ido evolucionando. Antiguamente, los usuarios de Internet podían caer en un phishing a través del clic sobre un enlace en un foro. Hoy día también, pero la cosa ha ido evolucionado y nos los encontraremos en redes sociales. Un ejemplo utilizado sería Twitter y sus enlaces acortados, ¿A dónde nos llevan?

Para finalizar os dejamos un par de artículos dónde se ve la importancia de tener conciencia de esto. En el primer artículo se ve como los dispositivos móviles han sido, y siguen siéndolo, un caramelito para el phishing. El segundo artículo habla de cómo el culpable del Celebgate llevó a cabo el robo de cuentas de las famosas de Hollywood. Un sencillo phishing de iCloud y el acceso al backup de los iPhone en bandeja. La conclusión es sencilla, la base del modelo en profundidad es una política de seguridad, concienciación, formación y conocimiento. Sin esto, de nada valdrá tener el mejor hardware o software en seguridad.

24 jun 2016

ImageMagick: Peligro de ejecución remota en Internet

Hace un mes y medio salió la primera de un conjunto de vulnerabilidades que afectan a ImageMagick. Dicho así, puede  no decirnos mucho, pero ImageMagick es una de las aplicaciones más utilizadas para la conversión y recorte de imágenes en los servidores de Internet. ImageMagick permite la manipulación y procesado de imágenes en cualquier sitio web. Por defecto, viene instalado en sistemas como Ubuntu, o incluso Kali Linux. 

Múltiples vulnerabilidades han afectado al software. Una de las vulnerabilidades descubiertas puede hacer que se pueda ejecutar código remoto. ¿Cómo? Al enviar una imagen al servidor, y éste vaya a procesarla o convertirla, un error en dicho proceso provoca que se ejecute el código embebido en el fichero. De este modo, se estima que miles de servidores expuestos en Internet son vulnerables a día de hoy. Además, según se indica en Internet el exploit para esta vulnerabilidad está siendo utilizado por algunos usuarios de manera pública, por lo que el riesgo es muy grande. El CVSS de dicha vulnerabilidad es de 10, ya que permite la ejecución de código remoto, sin necesidad de ninguna condición más. A continuación se enumeran las vulnerabilidades:

  • CVE-2016-3714. No se filtran caracteres correctamente y potencialmente se puede ejecutar código remoto.
  • CVE-2016-3715. Permite borrar archivos en el contexto del servidor.
  • CVE-2016-3716. Permite mover archivos.. 
  • CVE-2016-3717. Permite la lectura de ficheros locales. 
  • CVE-2016-3718. Este es un SSRF, con el que se pueden realizar peticiones HTTP o FTP.

El peligro real

¿Es realmente peligroso? ImageMagick dispone de diversos forks y una serie de plugins, por lo que a priori no se puede saber el número de servidores en Internet que pueden ser vulnerables a esto. Se estima que el número de servidores bastante alto, ya que el software es muy utilizado por los desarrolladores y administradores. La recomendación es clara: hay que actualizar en cuanto se pueda y no esperar más, ya que el nivel de exposición es muy alto. 

Para que la ejecución remota tenga éxito se necesita, en primer lugar, subir un archivo a un servidor. Este solicitará dicha imagen y al procesarla y disponer de una versión vulnerable de ImageMagick podría ocurrir algo no deseado por parte del propietario del servidor. Una ejecución de código remoto es la vulnerabilidad más crítica que se puede tener, ya que afecta a confidencialidad, integridad y disponibilidad. Es cierto, que la criticidad dependerá de los permisos del usuario con los que ImageMagick se ejecute. Sea como sea, en el mejor caso desde el punto de vista del hardening, solo se podría ejecutar acciones no privilegiadas, que no es poco. En el peor de los casos, se puede disponer de un usuario con el mayor privilegio. Además, siempre está la opción de la escalada de privilegios. 

PoC: Ejemplificando la vulnerabilidad

En esta prueba de concepto vamos a utilizar el software ImageMagick disponible, entre otros, en Kali Linux. En primer lugar, crearemos un archivo denominado poc.jpg y en su interior meteremos el código malicioso del tipo:

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg"|ls "-la)'
pop graphic-context

Si nos fijamos en la línea fill ‘url(https://example.com/image.jpg”|ls “-la)’ encontramos la inyección del comando y su potencial ejecución. 


Cuando ImageMagick procesa el fichero creado, en este caso p.jpg se provoca la ejecución de comandos, en este caso se ejecuta la instrucción ls –la. Al igual que se ejecuta un listado de directorios se podría ejecutar código arbitrario, o no tan arbitrario, como por ejemplo una shell o una Meterpreter. 

Con el módulo generate_payload_base64 se genera un texto en base64 que representa un binario encodeado. En este ejemplo utilizaremos una Meterpreter en base64. El módulo se queda a la espera con el handler preparado para recibir las conexiones. Es una de las formas similares a la explotación de un Command Injection.  


El fichero JPG tendrá el campo fill con este estilo. El esquema es el siguiente:
  • En primer lugar se vuelca en base64 a un fichero dentro del contexto del servidor, echo [shellcode base64] > /tmp/text
  • Después, se debe volcar a binario utilizando el base64 –d, cat /tmp/text | base64 –d > /tmp/binary2.
  • Ejecutar, revisar permisos y si no hay utilizar chmod. 

Al ejecutar el fichero en el servidor dónde está ImageMagick se produce la “magia”. Obtenemos una sesión de Meterpreter. 


El peligro está ahí fuera. Los administradores se enfrentan a una amenaza, la cual debe ser parcheada rápidamente. Ya hay exploits públicos que, como está prueba de concepto, se aprovecha de lo que está expuesto y es vulnerable. 

20 jun 2016

Robo de credenciales con Fake AP. Parte 1

En el post de hoy me gustaría hablaros de la aplicación Easy-creds, un interesante script para integrar herramientas como SSLstrip,  ettercap y Metasploit para interceptar credenciales, muy útil para temas de auditoría de redes wireless y pruebas de ingeniería social con Fake Ap. 

Su funcionamiento es bastante sencillo ya que automatiza todo el proceso, aunque requiere tener instalados varios componentes. 

Lo primero que haremos será descargarla del siguiente enlace:


Mi recomendación es que la ejecutéis sobre Kali, puesto que ya trae preinstaladas casi todas las herramientas necesarias para su funcionamiento.

Una vez descargada,  descomprimimos el archivo y lanzaremos el instalador. Nos encontraremos con el siguiente menú:



En este caso seleccionaremos la primera opción, y nos instalará los componentes que nos falten.


Finalizada la instalación, iniciaremos el programa. Nos encontraremos con el menú anterior, donde podremos con la opción 1 configurar los módulos que falten. Las siguientes opciones (2 y 3) se centran en los distintos ataques, la opción 4 en la recuperación de datos y la opción 5 y q en el cierre de la aplicación.

Nosotros nos centraremos en la opción 3, para montar un Fake Ap en procesos de auditoría de ingeniería social.

Para ver el funcionamiento de la aplicación os dejo a continuación un video publicado en Youtube por "Negative", explicando el funcionamiento de la misma:



En el próximo post vamos a ver algunos ejemplos de pruebas que podríamos hacer con esta herramienta, con el fin de robar credenciales en procesos de hacking ético de ingeniería social, de forma sencilla.

Este ataque lo podríamos hacer también de forma automatizada con algún dispositivo como la famosa Piña. De la cual os dejo un link a la Pineapple University:



Aunque de forma más casera, si disponemos de una Raspberry Pi, podríamos instalarlo con una versión ligera de Linux.

Saludos!

19 jun 2016

Informe Flu - 258


Buenas a todos, como cada semana os dejamos con nuestros enlaces de la semana:
 
Lunes 13 de Mayo
Miércoles 15 de Mayo
Jueves 16 de Mayo

Saludos!

    16 jun 2016

    La casa de cristal: Seguridad en las nuevas tecnologías #Reportaje @Cuatro

    Hace unos meses unas compañeras periodistas me estuvieron preguntando acerca de algunos temas sobre seguridad en dispositivos móviles y redes WiFi. La verdad que fue una grabación rápida y divertida. El reportaje que ellas estaban preparando era más grande de lo que pensé y han tocado muchos temas interesantes. IoT, hacking de coches, monitorización de aviones, tráfico, pantallas de taxis, hackeos de WiFi, procesamiento de datos al conectarnos a redes WiFi abiertas (típica, "chiringuito's wifi"). Os quiero dejar el vídeo del reportaje, si tenéis una hora echarle un ojo. Participan grandes compañeros del sector, que aportan su conocimiento. Enhorabuena a Noemí Redondo y al equipo de Cuatro.

    15 jun 2016

    #Encuesta - El Bitcoin repunta en el último año

    Buenas a todos, en el post de hoy me gustaría compartir con todos vosotros 2 interesantes estadísticas sobre el Bitcoin que me parecen muy significativas, con el fin de generar debate e intentar determinar entre todos el trasfondo que ha conllevado a tal hecho.

    La primera de ellas se corresponde con el precio del Bitcoin, el cual hace 1 año exacto, se situaba en $229. Desde ese momento hasta la actualidad ha sufrido distintos cambios, casi siempre al alza, hasta alcanzar en la actualidad la friolera de $578:


    Por otro lado, la segunda de las gráficas que quería compartir con vosotros se corresponde con el nº de transacciones realizadas con Bitcoins, las cuales, aún siendo más inestables, presentan también un interesante patrón de subida, pasando de las 100.512 transacciones que teníamos hace exactamente 1 año, frente a las 232.568 que tenemos en la actualidad



    Se puede ver claramente a nivel estadístico un incremento del doble tanto en el precio del Bitcoin, como en el nº de transacciones, pero... ¿tiene alguna relación? ¿qué opináis?

    Podéis enviarnos vuestras opiniones a info@flu-project.com, o comentarlas en el propio post. Y próximamente unificaremos vuestras ideas y las publicaremos en un nuevo artículo.

    Saludos!



    10 jun 2016

    Tunelizando conexiones y saltando entre máquinas

    El concepto de tunelizar y saltar entre máquinas puede parecer, en algunas ocasiones complejo. Esto no es así, tal y como se verá en este artículo. Además, proporciona cierto anonimato, lo cual podría ser utilizado por un atacante para preservar su dirección IP. El concepto de pivoting entre máquinas también viene asociado a esto y es que si proponemos un escenario de pentesting en el que:
    • Máquina A no tiene conectividad con la máquina C. Hay un firewall que nos bloquea.
    • Máquina B si tiene conectividad con la máquina C.
    • Entonces, si logramos acceso a la máquina B, podremos utilizarla para desde la máquina A pasar por la máquina B y lograr conectividad con la C.
    El siguiente esquema presenta el escenario anterior. Por alguna razón no tenemos conectividad con la máquina que queremos auditar / atacar, pero encontramos una máquina que tiene permiso para conectar con el objetivo. Utilizaremos una forma de pivotar nuestras peticiones. 


    ¿Cómo logro acceso a la máquina pivote?

    Esto es un debate siempre en los cursos, hay muchas formas, y es que habrá que auditarla y conseguir acceso a esa máquina. Generalmente, mediante el aprovechamiento de una vulnerabilidad en la máquina intermedia utilizando algún exploit. Existen otras formas menos directas como es el robo de alguna credencial de dicha máquina o, incluso, la realización de fuerza bruta en busca de alguna debilidad. Sea como sea partimos de que tenemos control sobre dicha máquina. 

    Utilizaremos conexiones SSH para acceder a la máquina con las siguientes opciones:
    • El parámetro –N. Le decimos a la máquina remota que no ejecute ningún comando a través de la sesión abierta de SSH. 
    • El parámetro –f. Deja la conexión SSH en background una vez nos autenticamos. 
    • El parámetro –D. Crea un túnel para realizar port-forwarding. Este es el parámetro dónde se está creando el servidor SOCKS. El puerto que se queda abierto en nuestra máquina es el que se indica con el parámetro –D, por ejemplo utilizaremos 1080. Todo lo que enviemos desde nuestra máquina al puerto 1080 será redirigido hacia el túnel SOCKS que estamos creando. 
    Preparando el pivote

    La instrucción que se ejecuta es ssh –NfD [puerto a la escucha en local] [user ssh]@[ip]. Como se puede ver en la imagen, la dirección IP del primer pivote acaba X.X.9.95. Este es un detalle para más adelante.


    Tras autenticarnos tenemos la conexión y el túnel montado entre nuestro puerto 1080 y l máquina remota. Utilizaremos proxychains para pasar por la máquina intermedia. Editando el fichero de configuración que se encuentra en /etc/proxychains.conf tenemos que tener en cuenta la dirección IP a la que enviar el tráfico, en este caso será nuestro propio localhost y el puerto a la escucha, en este caso el 1080. Hay que recalcar que este tipo de acciones se pueden hacer con pivotes, por ejemplo, obtenidos con Metasploit y aprovecharnos del potencial de un Meterpreter a través de varios saltos, pero eso será cuestión de otro artículo.


    En la imagen anterior se ve la configuración de proxychains. La que ahora mismo está preparada es la del puerto 1080. Utilizaremos proxychains para sacar el tráfico por la conexión. La sintaxis es sencilla en un terminal podemos escribir proxychains [nombre programa] y  la aplicación sacará su tráfico por el túnel montado. Para  hacer un ejemplo rápido ejecutamos en Kali proxychains iceweasel. Al navegar a un sitio de consulta de dirección IP pública veremos que acaba en 9.95, por lo que es la dirección IP de la máquina pivote. 


    Si desde Iceweasel intentamos abrir una conexión HTTP con otra máquina y en esa máquina tenemos acceso podríamos ver con tcpdump una captura de red y ver la dirección IP origen. El resultado es igual, la dirección IP origen es la que acaba en 9.95, por lo que volvemos a ver que el receptor de las peticiones ve como emisor a otra dirección IP. De este modo, el caso del bloqueo del firewall quedaría resuelto, si la dirección IP acabada en 9.95 tiene permiso. 



    Metiendo más saltos: Chain++

    Meter más máquinas en la conexión es sencillo con proxychains. Simplemente tenemos que añadir al fichero de proxychains.conf una nueva dirección IP, la cual seguirá siendo nuestro localhost de nuevo, y un nuevo puerto. Es importante que los puertos no coincidan, por lo que ahora utilizaremos el 1081. 


    Abriendo una conexión SSH entre la máquina pivote 1 y pivote 2, será proxychains el que hará que el tráfico pase primero al privote 1, luego al pivote 2 y posteriormente llegue al destino. En la siguiente imagen se puede ver un ejemplo claro y sencillo de ello. Utilizando el programa curl pedimos el recurso al dominio ip.appspot.com, el cual sencillamente te da la dirección IP que ha ce la solicitud. Cuando hacemos la petición sin proxychains vemos que nos proporcionan una dirección IP X.X.9.148, mientras que cuando utilizamos proxychains obtenemos una dirección IP X.X.6.9, la cual no es la que teníamos antes (que se quedó siendo el primer pivote). Ahora en el destino obtenemos que el tráfico viene de la dirección IP del segundo pivote. 


    Como se ha podido ver es fácil encadenar máquinas y pivotes para sacar tráfico de forma anónima o utilizar las cadenas para bypassear mecanismos de seguridad en una auditoría. Esto se puede juntar con Metasploit y obtener un gran potencial de la mano de un Meterpreter en una post-explotación, pero como dije anteriormente: queda para otro artículo.

    9 jun 2016

    Hackeando un coche muy Outlander a través de la WiFi... y Off Alarm!

    La noticia ha corrido como la pólvora. ¿El problema real? Quizá no sea lo conseguido, si no lo sencillo que puede parecer algunos cómo se ha conseguido. Os dejo el video, ¿Qué opináis? ¿Pueden venir muchos más como éste?


    Hay un punto de acceso WiFi en el vehículo. Éste permite conectar las funciones del coche, por lo que desde allí se puede acceder a algunas características del vehículo. Tenemos que estar en el rango WiFi para comunicarnos con el vehículo y sus funciones.

    PSK - SSID?

    La clave PSK de la WiFi se encuentra escrita en el manual del propietario del vehículo. El formato es sencillo y corto, según han comprobado se puede crackear con 4GPU en menos de 4 días. Se podría crackear antes con mayor potencial de crackeo (sumando GPUs).


    El punto de acceso tiene un SSID único. Tiene un formato REMOTEnnaaaa, dónde n son números y a son minúsculas. Se puede buscar en wigle.net y geolocalizar de forma sencilla este modelo de coche. Como ejemplo, los investigadores publicaron esta imagen.


    Los investigadores estudiaron los mensajes que se enviaban desde la App oficial. Después de estudiar el protocolo hicieron sus propios payloads para interactuar con el vehículo. Por ejemplo, para deshabilitar la alarma del vehículo.


    8 jun 2016

    Vigilancia Digital, ¿una moda pasajera, o el arma para quitar la venda de los ojos?

    Muy buenas a todos, a lo largo de los años el mundo de la ciberseguridad ha ido adquiriendo un importante peso en las compañías de todo el mundo. Desde los años 60-70, cuando los primeros malware comenzaron a presentar al mundo los estragos que podrían causar en un sistema infectado, hasta las últimas vulnerabilidades descubiertas en estos años como heartbleed (2014) o shellshock (2014), han ayudado a que numerosas compañías que no invertían ni un euro en seguridad más allá de los ya integrados entre la sociedad, software antivirus, comiencen a comprender que la seguridad no es un destino, sino un camino -un proceso-. Un proceso que no está basado en una moda pasajera. Es un proceso que tiene una gran complejidad, y un difícil ROI. El pan de cada día de muchos directores de seguridad se basa en hacer ver al comité de dirección de sus respectivas compañías el por qué se debe invertir en seguridad, cuando su retorno de inversión no es algo tan palpable como pueda ser la adquisición de una impresora, o de un router wireless. Si nunca ocurre nada en una compañía, el comité puede pensar que su seguridad es adecuada, aunque la realidad sea la contraria, y si por el contrario ocurre un incidente, quizás sea tarde, y sea un desastre difícilmente salvable. A lo largo de los años he visto en numerosas ocasiones estos dos puntos de vista, así como muchos otros que en próximos artículos me gustaría seguir compartiendo con vosotros. Pero esta no es la batalla que quería presentaros hoy. Hoy quería hablaros de Vigilancia Digital, y su importancia en el ROI de la ciberseguridad. 

    La vigilancia digital, como su nombre indica, se basa en la vigilancia del mundo digital, es decir, en la monitorización de los sucesos que ocurren en el mundo de los 0s y los 1s, tanto en la red de redes, Internet, como dentro de nuestro perímetro de seguridad. Hay muchas empresas que, ajenas a la realidad, solo monitorizan su perímetro de red, es decir, disponen de distintos sistemas como por ejemplo IDS, SIEM, sondas, etc. para determinar si existe una amenaza interna como por ejemplo un malware, que haya infectado un equipo corporativo y se encuentre enviando spam indiscriminadamente. Pero sin embargo, cierran los ojos ante lo que ocurre fuera de las barreras de seguridad de su organismo, que es uno de los focos principales de problemas tras los insiders.

    Internet es muy grande, y no se pueden poner puertas al campo, en eso estaremos todos de acuerdo. Y buscar potenciales amenazas que puedan afectar a nuestra organización en Internet cual Sherlock Holmes buscando una aguja en un pajar puede resultar casi de ciencia ficción. Pero la realidad es otra, los seres humanos somos seres que nos solemos regir por la repetición, repetimos nuestros pasos, repetimos nuestros caminos y repetimos nuestros comportamientos prácticamente sin pensarlo, somos seres automáticos. Esto quiere decir que presentamos patrones similares y predecibles. Solemos utilizar las mismas redes sociales de forma constante, compartimos datos en los mismos foros, en los mismos blocs de notas virtuales (o páginas de pastes), chateamos a través de las mismas plataformas, y un largo etcétera. Como veis, el campo se va acotando, y aunque el terreno de juego aún es grande, la vigilancia digital es una ciencia que nos ayudará a rastrear este terreno de una forma viable. Un claro ejemplo son las identidades falsas que muchos creamos para evitar que nos identifiquen en determinado foro, o en determinada red social. Pero al final, sin darnos cuenta y por mera costumbre, repetimos esos nicknames o nombres y apellidos ficticios, dejando un patron rastreable.

    ¿Y cómo se aplica esto de la Vigilancia Digital? Pongamos algunos ejemplos; a los responsables de seguridad patrimonial podría preocuparles que alguno de sus empleados pueda sufrir un incidente, y por ello puede interesarles monitorizar en redes sociales posibles zonas "peligrosas" antes de enviar a uno de sus trabajadores a determinado lugar, a los responsables de seguridad lógica puede que les interese que alguien pueda estar organizando una denegación de servicio en algún foro, red social, irc, telegram, etc. o un ataque coordinado, al departamento de prevención del fraude puede que le interese que alguien esté comerciando de forma ilícita en foros de TOR con productos sustraídos ilegalmente de la empresa (virtuales o físicos), y un largo etcétera. Todo esto es rastreable en un servicio de vigilancia digital, nadie dice que sea fácil, y es un campo poblado de falsos positivos, pero la Vigilancia Digital, ejecutada a través de OSINT, con buenas tecnologías y sobretodo buenos analistas, puede dar inesperadas alegrías a una empresa.

    Sin embargo, hay una gran cantidad de compañías que viven con una venda en los ojos, y no hay nada peor que quien no quiere ver. Por suerte no es algo extendido, pero si quien está a los mandos del aparato no quiere ver la realidad, y no muestra interés por tener emails y credenciales de sus empleados en los últimos volcados de Adobe (https://lastpass.com/adobe/), de LinkedIn (http://pastebin.com/qkykpGxU), o incluso bases de datos volcadas sin querer por sus equipos de desarrollo cuando consultaban una duda en un foro de developers (                    ), que probablemente cuenten con credenciales que coincidan con las contraseñas que utilizan en sus emails corporativos, en ese usuario de dominio que por política "cómoda" de la empresa, nunca se obliga a cambiar a los empleados, "para que no se quejen mucho", porque total se la apuntan en un post-it "que esconden bajo el teclado", o que utiliza cierta aplicación de la empresa, que aunque es crítica se encuentra accesible por Internet sin necesidad de VPN "para favorecer la movilidad" y el BYOD, o incluso que coincide con ese CMS (sustituyan estas letras por Wordpress, Joomla, Drupal, Liferay, Prestashop, etc. etc.) que se utiliza como core del sitio web y de la intranet corporativa.

    La Vigilancia Digital es una moda, pero no es pasajera. Llegó hace varios años para quedarse y quitar la venda de los creyentes, de los que escuchan y de los que saben que tras la barrera de sus caros firewalls "hay algo más". En realidad desde que comenzó a extenderse la realización de auditorías de hacking ético, era habitual con herramientas como maltego, dnsenum, anubis, foca, etc. revisar posibles fugas de información existentes en Internet, sencillas eso sí, como pueda ser un email filtrado, pero ya era algo que se trabajaba. Hoy en día, con las capacidades de procesamiento y de almacenamiento que nos dan entornos big data, nosql y clusters avanzados, tenemos la posibilidad de extraer, descargar y almacenar cantidades ingentes de datos de redes sociales, foros, redes p2p, tor, ... y procesarlas en nuestro sistema mediante avanzados algoritmos para extraer la aguja de ese pajar, que nos ayude a determinar porque una contraseña de nuestros empleados ha acabado en Paste Guru (http://pasteguru.com), o porqué determinado documento "se ha escapado de nuestra política de marcado", "nuestro DLP", y ha acabado en Dropbox... 

    Cómo muchos sabéis, llevo algunos años evangelizando sobre los beneficios de la Vigilancia Digital, pero con este post no quiero vender ningún producto, lo que pretendo es hacer ver a quién tiene poder de decisión sobre seguridad en las empresas, a que sepan que en Internet acaban centenares de datos de nuestras empresas, aún sin querer, y si no hacemos nada para remediarlo, se pueden convertir en una pelota muy grande que algún día aplaste nuestro negocio.

    Saludos!