Dropbox: Sincronización de archivos fácil y… ¿segura?

2 de julio de 2010 Por

Hace algunos meses oí hablar de Dropbox, un servicio de respaldo de archivos de seguridad basado en web. El servicio se basa en la posibilidad de acceder a un directorio de archivos (MyDropbox), con capacidad desde 2GB (gratuito) hasta 100GB ($19.99 al mes) desde cualquier equipo con sólo instalar el cliente de Dropbox. Por tanto, permite sincronizar archivos automáticamente entre múltiples equipos, por ejemplo el PC de sobremesa, el portátil o el iPhone, de forma realmente fácil. Tan sólo dejando caer un archivo en MyDropbox desde uno de los equipos con el cliente instalado se sincroniza automáticamente en la nube o disco virtual y en el resto de equipos.

Los usuarios de la aplicación pueden acceder a una cuenta de administración para compartir directorios a determinados usuarios, subir ficheros, restaurar versiones anteriores o recuperar archivos borrados. Tiene por tanto soporte para historial de revisiones, de forma que los archivos borrados de la carpeta de Dropbox pueden ser recuperados desde cualquiera de los equipos. También existe la funcionalidad de conocer la historia de un archivo en el que se esté trabajando, permitiendo que una persona pueda editar y cargar los archivos sin peligro de que se puedan perder las versiones previas. El historial de los archivos está limitado a un período de 30 días, aunque en la versión de pago que ofrece el historial ilimitado; el historial utiliza la tecnología de delta encoding.

Una primera aplicación que puede venir a la mente consiste en la simplicidad de sincronizar los archivos de trabajo en la oficina con el portátil personal. Ahí es donde empieza a ser algo serio en relación a la seguridad en empresas. Indagando acerca de la seguridad de Dropbox, los datos se transfieren a los servidores de Dropbox mediante SSL y antes de almacenarlo en sus servidores, se cifra mediante AES-256. Sin embargo, desde la parte de cliente, es una vía de salida de información confidencial al exterior de las empresas, inutilizando las configuraciones de firewalls y exponiendo datos sin control. En mi opinión, aplicaciones como éstas deben incluirse en el grupo de aplicaciones restringidas.

Si el análisis lo hacemos desde el punto de vista de la sincronización de archivos personales fuera del ámbito profesional, sin utilizar la herramienta para manejar información corporativa, también genera ciertas dudas, ya que existen directorios de contenido compartido, pudiendo acceder a información contenida en el mismo y en sus subniveles. Además, una de las opciones de compartición de archivos o directorios consiste en que Dropbox envía una URL de acceso al recurso vía email, sin necesidad siquiera de autenticación en una cuenta de Dropbox, por lo que otro puede acceder al recurso con sólo acceder a la URL adecuada.

Debo confesar que la idea de Dropbox como servicio me parece muy útil, pero creo que a día de hoy tiene mucho que mejorar en relación a seguridad y privacidad. Cabría estudiar si, utilizada junto a herramientas como TrueCrypt, podríamos confiar en su uso. También he leído que se está desarrollando una versión que pueda ser utilizada en las empresas, lo que confirmaría la aceptación del hecho que su utilización con la versión actual no debe ser muy adecuada. La proliferación de este tipo de aplicaciones está haciendo el trabajo aún más difícil al sector de la seguridad, ya que incluye una tarea importante, el control de la instalación de aplicaciones restringidas, no sólo en asegurar que los usuarios no instalan y utilizan las conocidas, sino en permanecer alerta ante nuevas aplicaciones que no cumplan los requisitos de seguridad.

Medidas de seguridad por Geolocalizacion de dirección IP

1 de julio de 2010 Por

Aprovechando que se acerca el periodo estival en el cual es posible que decidamos realizar algún viaje, me gustaría comentar ciertas medidas de protección implantadas en diversos sistemas de login relacionados con la ubicación geográfica del usuario. Para empezar, comentar que existen BBDD de IPs que las relacionan con su posición física, de manera que puedes consultar dónde esta ubicada una dirección IP con bastante precisión, hasta el punto de que en el mejor de los casos es posible acertar con la población en la que te encuentras; en el peor de los casos, el acierto se limita al país.

Esto es aprovechado hoy en día por cada vez mas aplicaciones, como por ejemplo para ofrecer servicios específicos para la población en que te encuentras. Por ejemplo en mi caso Google hace publicidad ofreciéndome comercios y servicios por ejemplo de la ciudad de Valencia. Esta información se viene utilizando también de manera habitual para orientar, limitar y prohibir el acceso a los contenidos en función de la ubicación física de la persona. Un ejemplo de ello son las cadenas de televisión que emiten video por Internet, limitando dichos contenidos al país en el que tienen licencias para emitir ciertos contenidos (por ejemplo, eventos deportivos concretos). En España esto es utilizado por La Sexta o Telecinco en sus emisiones de TV Online, ya que no tienen licencias de emisión universales. Por supuesto, estas técnicas le quitan universalidad a Internet, pero eso un tema para otro día. Siguiendo con las prohibiciones (que es casi el uso más habitual), existen BBDD de direcciones IP para poder limitar por países enteros; en http://ip.ludost.net/ tenemos herramientas que permiten incorporar estos límites de países a las ACLs de Apache o iptables, lo que puede ser util si queremos interaccionar solo con un país. Como aspecto positivo, también se utiliza para mejorar la seguridad, en módulos de login o transacciones de compras, siendo una medida habitual en los módulos anti-fraude.

No obstante, como todas las tecnologías están sujetas a imprecisiones y problemas. Por ejemplo, pueden fallar si estás dentro de una WAN de tu organización y los proxys se encuentran en una ubicación remota, ya que los contenidos a los que podrás tener acceso no son aquellos que por tu geolocalización deberías tener. Esto pasa con proveedores de Internet globales como AOL, o por ejemplo, en multinacionales en las que la salida a Internet pueda estar centralizada en una ubicación, a pesar de disponer de sedes repartidas por todo el globo (por ejemplo, la salida a Internet de Ford Motor Company puede estar en Estados Unidos, aunque disponga de fábricas por todo el mundo). Otro punto de fallo es la navegación por dispositivos móviles, ya que también está sujeta a cómo tu operador gestione el tráfico a Internet, o cuando hagas roaming, si estas en modo WiFi, conexiones por satélite, etc. Por último, los proxys de navegación como el diseñado por Opera para acelerar las conexiones a Internet, sufren este problema que pueden resultar en quebraderos y falsos positivos con las consiguientes inconveniencias para los usuarios.

A pesar de todo, el aspecto más positivo de este tipo de información es su utilización para evitar el fraude, de una manera muy sencilla. Por ejemplo, es posible comparar si la ubicación habitual de nuestro cliente y su ubicación actual son cercanas o han variado en miles de km, podemos ver si existen accesos simultáneos a servicios desde ubicaciones separadas miles de km, o analizar si el histórico de conexiones de nuestro cliente cumple cierto patrón. Esto genera contramedidas que ya han sido aplicadas por algunos proveedores de servicios. Por ejemplo, si Facebook detecta que alguien se está conectando desde una ubicación remota desde el móvil, puede cortar el acceso solicitando una conexión desde el PC habitual, o solicitar una serie de datos adicionales (fecha de nacimiento y otras) para su verificación. Por otra parte, Paypal, uno de los mayores objetivos de fraude, si detecta compras desde ubicaciones no habituales del usuario y con entrega en éstas, puede decidir bloquear la cuenta (a quien le pasó esto aún no se si ha podido restablecer la cuenta).

Todas estas medidas están diseñadas para proteger al usuario ante los problemas de fraude, normalmente cuando hay transacciones bancarias, compras de productos, u otros temas sensibles. Desgraciadamente, como todo, tienen su parte de molestia, ya que es probable que si se encuentra en Shangai de vacaciones, puede resultar que su banco no le quiera, Facebook no se fíe de usted y no pueda realizar compras mediante Paypal. En ese caso, lo mejor es dejar el portátil o Smartphone y disfrutar de las vacaciones. La tecnología seguirá ahí a su vuelta.

IDS en el cortafuegos

29 de junio de 2010 Por

A la hora de hablar de detección de intrusos, un modelo dentro de los NIDS que no es muy habitual es la detección en el cortafuegos (o en los cortafuegos) corporativo; digo que no es muy habitual -al menos por mi experiencia- y no sé muy bien por qué, ya que bajo mi punto de vista se trata de algo bastante sencillo de implantar en la mayor parte de firewalls, con un mantenimiento simple y, sobre todo, con una tasa muy baja de falsos positivos. Además, creo que le ahorraría bastante trabajo a los sistemas de detección ubicados en las redes internas, algo que en el caso de seguridad pasiva (IDS) se traduce directamente en un ahorro de costes en el personal dedicado a revisar las alertas de un SNORT o similar.

Un cortafuegos suele manejarse muy bien con las cabeceras de los paquetes y menos bien (o simplemente, muy mal) con los campos de datos; así, para hablar de detección en el cortafuegos, podemos centrarnos en los ataques -o en las anomalías, por no hablar aún de ataques- de dichas cabeceras. ¿Y qué información hay en los campos de cabecera de protocolos como TCP o IP? Direcciones origen y destino, puertos origen y destino, información del protocolo, bits URG, FIN, etc. Un montón de información que, correctamente analizada, permitirá bloquear tráficos anómalos que tratan de entrar en nuestra red y nos proporcionará información útil de eventos cuanto menos sospechosos.

Para empezar, lo obvio: de una determinada zona de red -interna o externa- no puede llegar tráfico con dirección origen otra zona de red. Así, si nuestra red de usuarios tiene un direccionamiento 192.168.1.0/24, desde esa red no debería llegar nunca un paquete con origen en otro direccionamiento -al menos, en condiciones normales-, por lo que podemos definir reglas que acoten qué direcciones origen pueden provenir de cada zona de red. Y seguimos con más cosas obvias: hay puertos que deben estar filtrados sí o sí (o casi sí), y cualquier actividad con destino dichos puertos puede ser a priori considerada sospechosa. ¿Quién utiliza hoy en día el protocolo UUCP? ¿Y gopher? ¿Alguien conoce algún uso lícito y habitual de chargen? ¿Y de finger? Si en mi cortafuegos veo tráfico hacia esos puertos, lo más probable es que me encuentre ante un ataque -típicamente un barrido de puertos, un information gathering o incluso malware-, por lo que me va a interesar bloquear y registrar este tráfico. Algunos puertos interesantes para enterarnos de estas acciones -sin menoscabo, por supuesto, de que todo lo no explícitamente autorizado esté cortado en nuestro firewall- pueden ser discard, daytime, chargen, gopher, finger, pop2, biff, r-* o uucp, por citar sólo unos cuantos. En el caso de puertos utilizados por malware, algunos muy conocidos son 12345 (NetBus) o 31337 (BackOrifice), y de la misma forma podemos bloquearlos y registrar su uso con cualquier cortafuegos (ejemplo para ipf, Solaris 10):


block in log quick on hme0 from any to any port = 31337
block in log quick on hme0 from any to any port = 12345
block in log quick on hme0 from any to any port = 70
block in log quick on hme0 from any to any port = 79
block in log quick on hme0 from any to any port = 540
...

Más cosas a considerar; en el RFC 3330 se definen unos rangos de direcciones IP “especiales” -no asignadas, privadas, bucle local…-, direcciones que no deben encontrarse en determinadas patas de nuestro cortafuegos; así, por ejemplo, en la pata de conexión con Internet nunca deberemos ver tráfico -salvo configuraciones excepcionales- que provenga de estas direcciones, y si lo vemos, al menos deberemos prestarle atención:


block in log quick on hme0 from 192.168.0.0/16 to any
block in log quick on hme0 from 0.0.0.0/8 to any
block in log quick on hme0 from 172.16.0.0/12 to any
block in log quick on hme0 from 198.18.0.0/15 to any
...

Seguimos: violaciones de protocolo o uso de protocolos fuera de lo habitual. Por definición de los protocolos TCP e IP, existen ciertas combinaciones de bits que no pueden encontrarse, en situación normal, en las cabeceras de los paquetes; así, no es correcto que un paquete TCP tenga activos los bits FIN y SYN de forma simultánea, ya que eso violaría el protocolo (estaríamos solicitando un inicio de conexión y a la vez un cierre, algo no coherente), ni tampoco está aceptado que una trama IP tenga activos al mismo tiempo los bits DF (Don’t Fragment) y MF (More Fragments). Si vemos tráfico con estas violaciones, se trata de una anomalía -lo de antes, por no llamarle ataque directamente- que nos interesa conocer, ya que los ataques de fragmentación IP o los barridos de puertos en base a violaciones del protocolo TCP son el pan nuestro de cada día (una herramienta como nmap implementa diferentes técnicas de este tipo). Adicionalmente, podemos encontrarnos tramas válidas según protocolo pero no habituales, y que por lo tanto puede ser necesario registrar. Algunas reglas más para ipf (podemos encontrar auténticos recopilatorios en Internet, y escoger las que más nos interesen):


block in log proto tcp all with short
block in log quick on hme0 all with opt lsrr
block in log quick on hme0 all with opt ssrr
block in log quick on hme0 proto tcp all flags FUP
block in log quick on hme0 proto tcp all flags FUP/FUP
block in log quick on hme0 proto tcp all flags /FSRPAU
block in log quick on hme0 proto tcp all flags FSRPAU
block in log quick on hme0 proto tcp all flags SF/SFRA
block in log quick on hme0 proto tcp all flags /SFRA
block in log quick on hme0 proto tcp all flags F/SFRA
block in log quick on hme0 proto tcp all flags U/SFRAU
block in log quick on hme0 proto tcp all flags P
block in log quick on hme0 proto tcp all flags FUP/WEUAPRSF
block in log quick on hme0 proto tcp all flags WEUAPRSF/WEUAPRSF
block in log quick on hme0 proto tcp all flags SRAFU/WEUAPRSF
block in log quick on hme0 proto tcp all flags /WEUAPRSF
block in log quick on hme0 proto tcp all flags SR/SR
block in log quick on hme0 proto tcp all flags SF/SF
block in log quick on hme0 proto tcp all flags /S

Con estas líneas y algunas más tenemos de forma sencilla un mini sistema de detección de intrusos implantado en nuestro firewall ipf (en todos los cortafuegos habituales podemos hacer cosas parecidas), sistema que obviamente puede ser mejorado por todas partes pero que, de momento, será capaz de alertarnos ante tráficos sospechosos; las líneas anteriores, aparte de bloquear el tráfico, generarán un log en tiempo real (man ipmon), log que puede ser tratado con cualquier script para integrarlo en nuestro esquema de detección de intrusos global, que más allá del NIDS habitual debería recoger y procesar los registros todos los sistemas de detección que tengamos implantados, tanto a nivel de host como a nivel de red, para proporcionar información correlada en base a todos los datos de los diferentes IDS. Esto, por supuesto, sin entrar en técnicas que ya se alejan de lo que sería un NIDS en el cortafuegos, como utilizar return-rst en nuestro ipf para “contaminar” los resultados del atacante (útil frente a barridos de puertos) o ejecutar ciertas órdenes del sistema ante tráficos anómalos detectados, que ya es material para otro post :)

Seguridad sectorial (VIII): espectáculos de masas

27 de junio de 2010 Por

Sin duda este fin de semana, en el que los amantes del deporte -ente los que no me incluyo- están disfrutando de los mundiales de Sudáfrica y de campeonato de Fórmula I en Valencia, es un momento inmejorable para aportar un nuevo post a la serie sobre seguridad sectorial, en este caso para hablar de los aspectos de seguridad en espectáculos de masas: competiciones deportivas, conciertos, actos políticos o sindicales, concentraciones de todo tipo…

Como en cualquier libro sobre seguridad podemos ver, toda actividad que implica grandes concentraciones de personas tiene implícitas amenazas como las avalanchas, el vandalismo, las agresiones o el terrorismo, por citar unas cuentas; sin duda la última de ellas, el terrorismo, es la más preocupante tanto para los organizadores como para la sociedad en general, ya que la simple amenaza puede causar un grave daño reputacional y cuantiosas pérdidas económicas -imaginemos un estadio que hay que “vaciar” en pleno partido por una amenaza de bomba-, por no hablar de los casos en los que la amenaza se materializa, añadiendo a los problemas anteriores daños materiales y contra la integridad física de las personas. Por ello, cualquier acto con una gran afluencia de personas debe disponer obligatoriamente de determinadas medidas de seguridad, que pueden ir desde el control de acceso -técnico o humano- a los recintos hasta un número concreto de vigilantes o policías; esto es especialmente necesario en aquellos actos en los que la amenaza pueda ser mayor, como los mítines políticos, eventos con una elevada concentración de personalidades o encuentros deportivos de los denominados “de alto riesgo”.

Por fortuna, a pesar de ser la de mayor impacto, el terrorismo no es la amenaza más probable en las concentraciones de masas. Las minorías extremistas o enfervorizadas suelen ser, más allá del terrorismo, el caldo de cultivo ideal para materializar otras amenazas propias de las grandes concentraciones, como las agresiones o el vandalismo; esto es especialmente frecuente en los encuentros deportivos -fútbol sobre todo-, en los que los grupos “ultra” deben ser controlados no sólo durante el encuentro, sino también antes y después de éste para evitar enfrentamientos con otros hinchas. También la actividad de estas minorías puede ser el origen de avalanchas humanas, aunque esta última amenaza puede ser causada de forma fortuita, simplemente por el elevado movimiento de personas en un determinado lugar (todos recordamos los problemas de seguridad que año tras año se producen en la peregrinación musulmana a La Meca).

Para evitar estos -y otros- problemas, en todas las actividades que implican una gran concentración de personas debe disponer, como hemos dicho, de personal de seguridad pública y privada y de medios técnicos suficientes para prevenir y detectar cualquier amenaza, así como para minimizar el impacto en caso de que ésta se materialice (vías de evacuación, Plan Integral de Seguridad, planes de emergencia…). Los organizadores del evento tienen una serie de obligaciones bien definidas desde el punto de vista de seguridad, que en caso de no ser cumplidas pueden acarrear sanciones más o menos duras (tema por otra parte muy discutible, ya que en ocasiones hay casos claros de incumplimiento y las sanciones aplicables son irrisorias).

Para hacernos una idea de la importancia de la seguridad en este tipo de eventos, simplemente unos datos que leía en el número de este mes de Security Management, la revista de ASIS, relativos al mundial de fútbol de Sudáfrica: SAPS (South African Police Service) ha renovado buena parte de su equipamiento de cara a la celebración del evento, incluyendo desde helicópteros a cañones de agua, ha reforzado su personal con 55.000 nuevos oficiales, y 8.500 policías del cuerpo han realizado un curso ad hoc de un año de duración en Francia, cuya Gendarmería tiene experiencia en la seguridad de estos eventos desde el mundial celebrado en 1998 en el país galo. Todo esto son simples números, sin hablar de las medidas organizativas o técnicas implantadas para el evento: perímetros de seguridad alrededor de los estadios, protección especial de altos cargos, control de acceso al país con conexión directa a bases de datos de INTERPOL, etc. Como vemos, desde el punto de vista de seguridad, la celebración de un mundial es mucho más compleja de lo que nos parece a los simples espectadores (y eso sin profundizar en protección de la información, que evidentemente también requieren estos eventos).

Nuevo canal de comunicación de alertas sobre fraude online

24 de junio de 2010 Por

Como todos ustedes saben, día a día se suceden las alertas sobre fraude en la red, comúnmente conocido por su término inglés phishing. Para evitar que los atacantes tengan éxito es crucial, además del sentido común al navegar por la red de redes, la rápida detección de las páginas fraudulentas, para que estas puedan ser reportadas a las autoridades competentes y bloqueadas lo antes posible.

En este sentido la NFCTA (National Cyber-Forensics and Training Alliance), junto con otras organizaciones estadounidenses y empresas dedicadas al comercio electrónico como Accuity, eBay o Pay-Pal, y con el soporte tecnológico de Microsoft, han desarrollado un canal de comunicación llamado Internet Fraud Alert, con el que pretenden mitigar los efectos de las estafas bancarias y robos de identidad.

Pero, ¿en qué consiste Internet Fraud Alert?

Internet Fraud Alert es un nuevo sistema de comunicación directo y centralizado entre todas las entidades u organismos implicados en los casos de fraude en la red, incluyendo a los investigadores que descubren credenciales o números de tarjeta de crédito robadas, las entidades (ya sean bancarias o de otro tipo) con que se pueden usar las credenciales robadas, y otras entidades como proveedores de servicio y gobiernos, entre otros. También cabe destacar que este grupo no es cerrado, y las empresas y entidades interesadas e involucradas en la investigación del fraude online pueden solicitar su adhesión a Internet Fraud Alert rellenando el formulario existente en su web.

Con este canal se pretende reducir el tiempo necesario para encontrar el origen de la estafa e intentar reducir dentro de lo posible los usuarios afectados y las pérdidas económicas que puedan ocasionar. Según el Anti-Phishing Working Group, en 2009 se reportaron más de 410.000 alertas por phishing, y el número de entidades explotado por los atacantes crece de forma continuada.

Como no podría ser de otra manera, desde Security Art Work apoyamos este tipo de iniciativas que contribuyen a lograr un Internet más seguro y a mejorar la imagen de la Red como medio para realizar compras y transacciones bancarias, dos elementos que todavía generan desconfianza entre el grueso de la población.

Vía: Genbeta
Nota de prensa original: Microsoft

Nueva encuesta: En estos tiempos de crisis, ¿Cuánto inviertes en seguridad?

23 de junio de 2010 Por

Los resultados de la encuesta ¿Que consideras más adecuado para tu/una organización, la certificación en ISO 27001 o en ISO 20000? que hemos tenido hasta hoy mismo han sido bastante dispares, ya que ninguna de las opciones destaca claramente por encima de las demás. Parece ganar por “una cabeza” la certificación ISO 27001 (31% de los votos), continuando con un empate técnico entre la certificación ISO 20000 y la opción de no certificar pero implantar antes una gestión en base a ITIL que un SGSI (20% de los votos cada una). En cuarto lugar se sitúa la opción de no certificar, pero implantar primero un SGSI y luego una gestión en base a ITIL (15% de los votos). Por último, un 14% de los votos no se deciden por ninguna de las anteriores opciones.

Sin olvidar el limitado número de votos (aunque, todo sea dicho, es mayor que la población en las que las grandes corporaciones de productos cosméticos fundamentan la mayoría de los resultados de las cremas que anuncian en televisión), los resultados parecen indicar que un SGSI se percibe como potencialmente más certificable, o directamente más relacionado con un “sello” ISO 27001, mientras que la gestión en base a ITIL se mantiene más “independiente” de la certificación, quizá por la menor difusión y conocimiento que hay de ISO 20000 frente a ISO 27001. Aunque esto está cambiando poco a poco, concuerda con la experiencia de S2 Grupo, en la que (en términos generales) el cliente nos plantea en primer lugar la implantación y certificación de su organización en base a la norma ISO 27001, para entrar a valorar posteriormente la gestión en base a ITIL, con o sin certificación.

Dicho esto, les dejo con una nueva encuesta, propuesta por Toni Villalón. Esperamos sus respuestas.

[poll id=”20″]

Conferencias sobre ingeniería de software avanzada

22 de junio de 2010 Por

logoFastFixRecientemente, S2 Grupo, ha conseguido un proyecto del 7º Programa Marco, sección TIC, de la Comisión Europea. La primera reunión de trabajo del consorcio va a tener lugar esta misma semana en Valencia.

El viernes, día 25 de junio, se va a celebrar una sesión abierta del proyecto, en el que se impartirán tres conferencias sobre tres temas muy interesantes en el ámbito de la ingeniería de software:

“Intention-Based Integration of Software Engineering Tools”
Prof. Walid Maalej, Technische Universität München

INTI, a novel, intention-based integration approach. An intention is a mental state that underpins the user’s actions during the work. Intentions “sessionize”the work and facilitate the management and switching of context. Intentions also group and describe related changes that are made in different tools. We introduce a reference framework for the realization of such intention-based integration. The framework automatically links related pieces of information by observing the user’s interactions with the tools. It handles the heterogeneity of the tools and information by using Semantic Web technologies

[Read more…]

Evasión en IDS (I)

21 de junio de 2010 Por

Empezando con esta, y durante una serie de entradas, vamos a tratar una de las herramientas de seguridad más empleadas: la detección de intrusos a nivel de red (IDS en adelante), y cómo posibles atacantes pueden intentar eludir dicha herramienta. Como ya probablemente sepan, y como hemos visto en anteriores entradas, los IDS consisten en simples sniffers que leen todo el tráfico que circula por una red, lo tratan y lo analizan sobre un conjunto de reglas buscando posibles patrones de ataques en el tráfico escuchado.

Seguro que muchos de ustedes estarán pensando que existen también los IDS a nivel de red que actúan por comportamientos anómalos del tráfico de red. Es cierto, existen como tal pero dichos IDS sólo suelen ser eficaces para puertas traseras, gusanos de rápida propagación (fast spreading worms) y ataques de denegación de servicio; para el resto de ataques no suelen dar un buen resultado. Es por ello que las siguientes entradas se centrarán únicamente sobre la evasión en IDS a nivel de red que empleen un motor de reglas para la detección de posibles ataques.

Antes de explicar las distintas formas de poder evadir un IDS, hagamos una breve introducción al funcionamiento básico de un IDS, ya que aunque no todos los IDS funcionan exactamente igual pero siguen el siguiente patrón:

1. Un sniffer lee todo el tráfico mediante una interfaz en modo promiscuo conectada a una interfaz espejo de un switch, un router, un hub, etc. En el caso de dispositivos empotrados, directamente se emplea la propia interfaz espejo.

2. Unos preprocesadores tratan los datos leídos por el sniffer, con el objeto de que sean procesados de una forma más rápida por el motor de reglas. Tienen además otras funciones, entre ellas intentar evitar que un atacante pueda eludir el motor de reglas, aspecto que se verá más adelante.

3. Un motor de reglas y un conjunto de reglas. A partir de los paquetes tratados por los preprocesadores, el motor de reglas pasa el paquete tratado por cada una de las reglas, buscando un patrón de ataque que coincida con una de éstas. Si encuentra que alguna coincide, realiza la operación indicada por la regla, normalmente considerar que se trata de un ataque (accept) o rechazar el paquete (drop, pass, reject…). En caso de tratarse de un ataque se notifica a los postprocesadores.

4. Los postprocesadores son los encargados de tratar el ataque, ya sea notificando del ataque vía correo electrónico, almacenando el ataque en texto plano o en una base de datos, bloqueando el ataque (por lo que el IDS pasaría a ser un sistema de prevención de intrusos IPS), etc.

Una vez se ha explicado el funcionamiento sencillo de un IDS a nivel de red, vamos a explicar de forma breve los posibles vectores de ataque que permiten evadir estos sistemas. Principalmente existen cuatro vectores de ataque y un quinto, que pese a no ser un vector de ataque hay que tenerlo presenta ya que se trata de una limitación de los IDS:

1. Evasión mediante paquetes fragmentados en los preprocesadores. Existen dos posibles evasiones en este vector de ataque.

2. Codificación empleada en el ataque. No todos los IDS soportan el mismo tipo de codificación, que si soporta el servicio atacado.

3. Gusanos polimórficos y metamórficos (polymorphic and metamorphic worms).

4. Tratamiento de los datos de entrada (parseo) incorrecto por parte de los preprocesadores, que pueden dar lugar a denegación del servicio y por tanto la anulación del IDS.

5. Cifrado de las comunicaciones. Pese a que no se trata de un vector de ataque, hay que tenerlo en cuenta. Como resulta natural, si una comunicación entre un atacante y un servidor victima va cifrada, el IDS no puede reconocer ningún patrón de ataque. De hecho, el motivo por el cual las comunicaciones van cifradas es para que ningún elemento intermediario pueda entender los datos entre ambos.

Sí es cierto que algunos IDS lo que emplean es un certificado intermedio: el atacante al conectarse con el servidor mediante protocolo seguro, realmente lo que hace es conectarse al certificado del IDS, y el IDS a su vez, conectarse con el servicio solicitado por el atacante, es decir, un man in the middle (MITM). Por lo que el IDS es capaz de analizar el tráfico. Pero, ¿qué ocurre si es justamente el IDS el servidor atacado? Pues que el atacante podría leer el tráfico cifrado. Teniendo en cuenta que para ello el IDS tendría que tener una conexión con la red analizada, algo que no es aconsejable.

En las próximas entradas explicaré con ejemplos reales el funcionamiento de estos vectores de ataque y como algunos sistemas actuales son vulnerables a dichos ataques. Manténganse a la escucha.

Éramos pocos y llegó el “Kindle DX”

18 de junio de 2010 Por

No malinterpreten el título de este post. A diferencia de algunos “elementos” del mercado no estoy, ni mucho menos, en contra de los libros electrónicos y menos del dispositivo de Amazon. Todo lo contrario, fui de los primeros en adquirir uno. Invertir en un libro electrónico es invertir en salud y si no lo creen ustedes no duden en preguntarle a mi espalda. Tengo muchas ganas de que mis hijas puedan ir al colegio con una mochila en la que lo más pesado sea su bocadillo o su zumo, aunque creo que tendré que esperar a que estén en la Universidad a juzgar por la reacción que las editoriales españolas están teniendo en esta materia. En mi modesta opinión es una vergüenza, pero es lo que tenemos.

Mostrada mi postura claramente a favor de semejante utensilio del siglo XXI he de hacer una puntualización a mi apoyo. Un apoyo, por tanto, condicional, con alguna fisura fruto de la falta de previsión de los fabricantes o de los ingenieros que lo diseñaron y que se está resolviendo con las últimas versiones del software que se están publicando (versión 2.5.2).
No sé si ustedes se han parado a pensar en el impacto que sobre la sociedad van a tener, o están teniendo ya, los libros electrónicos. Creo que va a ser una revolución a corto plazo equivalente a la de la fotografía digital. El impacto en todos los ámbitos de la sociedad ya se está empezando a notar. Hasta hace no mucho los libros electrónicos eran unas maquinitas con una utilidad incuestionable para los devoradores de novelas, libros de bolsillo, ensayos y demás piezas literarias.

Los que queríamos el libro electrónico como dispositivo simultáneamente de ocio y negocio le encontrábamos algunas pegas, sobre todo por lo relacionado con el tamaño y la calidad de visualización de documentos en tamaño A4, fundamentalmente documentos en formato pdf. Pero los libros electrónicos de 10 pulgadas ya han irrumpido en nuestras vidas y con ellos llegó un nuevo capítulo de preocupación para los que nos dedicamos a la seguridad.

¿Por qué a los señores de Amazon no se les ocurrió inicialmente dotar de algún mecanismo mínimo de seguridad al Kindle DX? Si de verdad se postula este dispositivo para llevar una versión digital del Quijote o el último documento de auditoría de seguridad entregado por nuestro equipo externo de consultores ¿no creen ustedes que debería haberse pensado desde el principio en algún mecanismo de seguridad que garantizase la confidencialidad de la información contenida en el mismo? ¿Qué pasa si al director de RRHH de una gran empresa le roban su Kindle con una versión de la aplicación inferior a la 2.5.2 donde, con el fin de aprovechar los ratos muertos del aeropuerto, había guardado el borrador del ERE que se está diseñando o la lista de los empleados que van a ser despedidos durante este ejercicio? Amazon lo ha intentado resolver hace poco tiempo con su nueva versión de la aplicación pero, ¿qué está ocurriendo con el resto de libros electrónicos?

Pero aquí no termina la historia. Como ustedes supongo sabrán Kindle hace uso de una maravillosa red global, Whispernet, mediante la cual estos dispositivos están permanentemente conectados. Esto tiene en si mismo utilidades incuestionables de las cuales hago uso con cierta frecuencia, como por ejemplo “comprar” libros en el portal de Amazon con un solo click y con una seguridad cuestionable, pero también nos permite recibir en nuestro dispositivo correos electrónicos a través de una cuenta gratuita que se nos proporciona con la compra del dispositivo. La seguridad que nos propone Amazon para que los correos sean lícitos es la de dar de alta listas blancas de remitentes de correo. ¿Creen ustedes que es esto suficiente? La respuesta es evidente: NO y si no miren ustedes la figura adjunta que muestra una utilidad mediante la cual enviar correos haciendo uso de una cuenta falsa. Además, la estructura de la cuenta de los clientes es una estructura estándar y por tanto fácilmente deducible en un gran número de casos. El envío de correos electrónicos a esa cuenta tiene muchísima utilidad y un pequeño coste asociado. El problema radica en la falta de seguridad de este mecanismo. A priori cualquiera, con ciertos conocimientos perfectamente alcanzables, te puede enviar un documento que como por arte de magia aparece en tu kindle. Esto quiere decir que en “mi” dispositivo puede aparecer un documento “incómodo” sin haberlo cargado yo y sin tener posibilidad de saber quién lo ha introducido en el sistema. ¡¡Vaya!! Esto puede tener algunas utilidades curiosas más allá incluso del coste asociado que lleva, simplemente hace falta dejar volar un poco la imaginación, ¿no creen?

Al margen de este “pequeño” detalle otra cuestión a tener muy en cuenta por la propia existencia de esa “conexión global” es la seguridad de la conexión inalámbrica en si misma o la capacidad que tiene el propio Amazon de acceder a todos los dispositivos del mundo y, por ejemplo, eliminar un determinado documento o actualizar el firmware en remoto como ya ha ocurrido.

En fin, creo que a pesar de que el Kindle DX es un magnífico instrumento lleno de posibilidades, también creo que en las versiones actuales del dispositivo debemos de llevar bastante cuidado con el uso que del mismo hacemos sobre todo cuando de trabajo se trata. Mientras tanto suplicaremos para que los ingenieros que desarrollan aplicaciones o productos en la era digital se acostumbren, de una vez por todas, a hacer desde el principio un catálogo de “CASOS DE ABUSO” en paralelo al maravilloso catálogo de “CASOS DE USO” que seguro ya hacen. ¿Por qué no se dedican a pensar brevemente en cómo se pueden “mal usar” los dispositivos que diseñan? O mejor aún ¿Por qué no contratan empresas especializadas (dicho sea de paso, como S2 Grupo :), repletas de profesionales que dedican su inteligencia y su tiempo a pensar precisamente en esto?
Disfruten señores de sus libros electrónicos pero, por favor, con “sentido común”

SELinux II: Práctica

16 de junio de 2010 Por

Bueno, lo prometido es deuda, y aunque debería de pagar intereses por el tiempo transcurrido, vamos a pasar de la teoría de SElinux a la práctica.

Lo primero antes de trabajar con SElinux, es asegurarse de que lo tenemos habilitado, de que esta configurado en el modo adecuado y de la política de que tenemos. Para todo ello, en un sistema Red Hat, inspeccionamos el fichero /etc/sysconfig/selinux

jvela@centos:~$ less /etc/sysconfig/selinux
SELINUX=enforcing 
SELINUXTYPE=targeted

[Read more…]