Security Art Work

Como se vió en posts anteriores, SIP (Session Initiation Protocol) es un protocolo de control desarrollado por el IETF, basado en arquitectura cliente/servidor similar al HTTP, legible por humanos, con el que comparte muchos códigos de estado y sigue una estructura de petición-respuesta; estas peticiones son generadas por un cliente y enviadas a un servidor, que las procesa y devuelve la respuesta al cliente. El par petición-respuesta recibe el nombre de transacción. Al igual que el protocolo HTTP, SIP proporciona un conjunto de solicitudes y respuestas basadas en códigos.

El protocolo SIP define principalmente seis tipos de solicitudes:

[Read more…]

Que las nuevas tecnologías han cambiado la forma de cometer delitos es algo claro para cualquiera que trabaje, directa o indirectamente, en el ámbito de la seguridad de la información, y también en muchos casos también para aquellos que no trabajan en este ámbito: ataques de phishing, clonaciones de tarjetas, robos de móviles o portátiles, uso ilegítimo de redes WiFi…

En el Convenio de Ciberdelincuencia del Consejo de Europa (2001) se tipifican cuatro grandes tipos de delitos tecnológicos que posteriormente se han complementado con la contemplación del racismo, xenofobia, amenazas, calumnias… realizados a través de sistemas informáticos. Estos cuatro tipos son los siguientes:

— Delitos contra la confidencialidad, la integridad y la disponibilidad de los datos y sistemas informáticos.
— Delitos informáticos (falsificación, fraude…).
— Delitos relacionados con el contenido (como pornografía infantil).
— Delitos relacionados con infracciones de la propiedad intelectual y derechos afines

[Read more…]

Dentro de la serie sobre VoIP, como previo al material específicamente de seguridad, y una vez comentados los protocolos de señalización, entraremos brevemente en los protocolos de transporte. Éstos se encargan de asegurar que todos los datos hayan llegado intactos desde el origen al destino, cumpliendo con los requerimientos de calidad de servicio y ancho de banda adecuados.

Los paquetes de VoIP se encuentran en el protocolo RTP, el cual va encapsulado en paquetes UDP; no usa TCP porque éste es demasiado pesado para las aplicaciones de tiempo real. Puesto que el datagrama UDP no tiene control sobre el orden en el cual los paquetes son recibidos, o de cuanto tiempo requiere su transmisión, RTP resuelve este problema permitiendo que el receptor ponga los paquetes en el orden correcto y que no “espere” a los paquetes que se hayan perdido el camino o tarden mucho en ser recibidos. En la línea de lo comentado, a continuación podemos ver un esquema de la pila TCP/IP, en la cual observamos los distintos tipos de protocolos de transporte y su posición dentro de la pila.

Vamos a describir muy brevemente los protocolos de transporte más empleados para la integración de voz y datos: RTP y su protocolo de control RTCP, RTSP para sistemas de vídeo bajo demanda, y RSVP.

RTP (Real-time Transport Protocol) es un protocolo de nivel de aplicación utilizado para la transmisión de información en tiempo real (audio o vídeo), extremo a extremo sobre una red de paquetes. Fue publicado por primera vez como estándar en 1996 como RFC 1889, y actualizado posteriormente. Éste ofrece entrega de datos multicast para aplicaciones de streaming, videoconferencia, etc., siempre que la red proporcione los servicios. Es importante destacar en este caso que RTP no ofrece garantías sobre la calidad del servicio ni sobre el retraso de la entrega de datos, por lo que necesita el apoyo de capas más bajas que controlen la reserva de recursos (como por ejemplo el uso de RSVP que comentaremos al final).

RTP va de la mano de su protocolo de control, RTCP: RTP envía los datos y RTCP proporciona servicios de control y otras funcionalidades. Existe una variante llamada SRTP (Secure RTP) usada para aportar características de cifrado al canal RTP, pero en la que no entraremos aquí.

RTCP (RTP Control Protocol) se encarga de monitorizar la calidad del servicio y de proporcionar información acerca de los participantes en una sesión de intercambio de datos. El protocolo, definido en el RFC 3550, no está diseñado para soportar todas las necesidades de comunicación de una aplicación, sólo las más básicas. La principal función de RTCP es proporcionar una retroalimentación útil para mantener una calidad de distribución adecuada: los receptores de una sesión emplean RTCP para informar al emisor sobre la calidad de su recepción, incluyendo el número de paquetes perdidos, jitter (la variación en la latencia) y RTT (Round Trip Time, tiempo empleado por un paquete en realizar todo el circuito: llegar al receptor y volver de nuevo al emisor).

Los paquetes RTCP se envían de modo que el tráfico en la red no aumente linealmente con el número de agentes participantes en la sesión, ajustando el intervalo de envío de acuerdo al tráfico. Para ello, RTCP se encarga de transmitir periódicamente paquetes de control a todos los participantes de una sesión.

RTSP (Real-Time Streaming Protocol) es un protocolo a nivel de aplicación que optimiza el flujo de datos multimedia. En sintaxis y funcionamiento, es similar al protocolo HTTP, donde tanto el cliente y el servidor pueden hacer peticiones. No obstante, a diferencia de HTTP, el protocolo RTSP necesita mantener información de estado. Entre sus principales ventajas, podemos destacar que debido a sus similitudes con el HTTP, hace que sea adaptable a proxys y firewalls, y es compatible con el modo de difusión multicast, siendo capaz de enviar la información a un grupo de clientes en un solo paso. Además, es independiente de la capa de transporte usada: puede utilizar tanto TCP como UDP.

Por el contrario, como desventajas podemos destacar que depende de la congestión de red, por lo que la pérdida de paquetes durante la transmisión es imprevisible, y si se trabaja en modo unicast, necesita un ancho de banda importante.

Finalmente, y como se ha comentado anteriomente, debemos mencionar el protocolo RSVP (Resource ReSerVation Protocol), usado para manejar la calidad de servicio de la comunicación, ya que hay que tener en cuenta que los paquetes IP son de longitud variable y el tráfico de datos suele ser a ráfagas. El propósito de RSVP es eliminar aquellas situaciones en las que la voz se pierde porque tenemos una ráfaga de datos en la red. Para ello, éste solicita ancho de banda, divide los paquetes de datos grandes y da prioridad a los paquetes de voz cuando hay una congestión en un router. Si bien este protocolo ayudará considerablemente al tráfico multimedia por la red, hay que tener en cuenta que RSVP no garantiza una calidad de servicio como sucede en redes avanzadas como ATM, que proporcionan servicios de QoS (Quality of Service, calidad de servicio) de forma estándar.

Y esto es todo en referencia a los protocolos de transporte. En la siguiente entrada, entraremos en detalle en el protocolo SIP, visto en el anterior post, para acabar con los detalles de la captura de una conversación VoIP.

Ni que decir tiene que todos los que nos dedicamos al ámbito de la seguridad tenemos clara la respuesta a esta pregunta que de hecho, es retórica, por no decir estúpida (si ha respondido A en vez de B, antes de ofenderse siga leyendo por favor). Veamos otra pregunta: ¿de quién es culpa que determinadas personas en puestos de decisión en las organizaciones vean la seguridad como un gasto más que como una inversión, o al menos como una inversión aplazable hasta el infinito y más allá? Esta pregunta es igualmente retórica e igualmente estúpida, aunque no se me ofendan ahora los profesionales de la seguridad (o antes de hacerlo, lean…)

El problema es el siguiente: ¿por qué hablamos de inyección SQL, cuando no de SQL-Injection, en vez de hablar de obtener información de una base de datos a través de la Web? ¿Por qué hablamos de hacking ético o de auditorias de seguridad en vez de hablar de planes que permitan a las empresas seguir trabajando lo antes posible después de un incidente grave en su organización? ¿Que no es lo mismo? Disculpen pero sí, es lo mismito. Porque al final de lo que se trata es de mejorar la seguridad de las organizaciones, y es nuestra responsabilidad, y de nadie más, acercar estos conceptos al lenguaje de la humanidad; y éste no es C, ni scripting, ni usa NESSUS para detectar vulnerabilidades en nuestro lenguaje, ni Nagios.

¿Es responsabilidad del neófito en seguridad entender los beneficios de la seguridad de la información junto con toda la terminología técnica asociada? Obviamente no. Todos los tecnólogos tenemos una tendencia natural a utilizar un lenguaje que a nosotros nos puede parecer normal, siendo inexcusablemente erróneo para nuestro interlocutor, pero como me dijo el otro día un compañero, los tecnólogos hablamos español, los directivos griego y los financieros arameo, y esa es una difícil mezcla como para entendernos.

El hacking ético “mola mazo”, y prácticamente todo responsable TIC entiende el concepto, comparte la necesidad e incluso estaría encantado de abordar estas cuestiones mañana mismo (eso sí, en el mundo de Huxley, que por feliz, dispone de recursos infinitos, tanto humanos como económicos). Pero como en la mayoría de los casos los puestos de decisión no suelen coincidir en última instancia con los puestos TIC, es nuestra responsabilidad adaptar nuestro lenguaje y la definición de nuestros servicios profesionales al lenguaje de la persona que te escucha directa o indirectamente, sea este español, griego o arameo. Y si quién escucha no decide, tendrá que contarlo después a quien sí decide, por lo que estas segundas partes, aunque indirectamente, escuchan.

Para acabar, ¿quieren un ejemplo de abuso de lenguaje tecnológico no adecuado? Fácil, retrocedan esta entrada y vean cuantas veces he dicho “TIC” sin explicar qué leches es eso de “TIC”. Todos los que se han sorprendido y/o no han caído en la cuenta, es que necesitan revisar su lenguaje para acercarlo al del resto de personas que no saben (ni tienen por qué saber) que Internet está ubicado en ordenadores de todo el mundo que, en esencia, son como el que tienen en su casa para bucear por la propia red. Y por cierto, TIC significa “Tecnologías de la Información y las Comunicaciones”.

Saludos cordiales y, solo por contradecirme una vez más y parafraseando a otro compañero:

:wq!

[Como segunda entrada sobre VoIP, en este post vamos a describir los principales protocolos de señalización utilizados por VoIP, y en el siguiente entraremos en los protocolos de transporte. Estas tres entradas permitirán que los siguientes artículos, de carácter técnico, sean más accesible a aquellos no duchos en esta tecnología.]

En los últimos años, los protocolos de señalización para el servicio de transmisión de voz han experimentado una fuerte evolución, puesto que cada vez más, se están usando las redes de conmutación de paquetes para transportar tráfico de voz. Las necesidades de calidad de servicio hacen que sea necesaria una gestión de recursos que asegure la optimización de la capacidad de transporte de la voz extremo a extremo, para ello surgen los protocolos de la señalización.

Por señalización se entiende el conjunto de informaciones intercambiadas entre los dos extremos de la comunicación que permiten efectuar operaciones de:

• Supervisión (detección de condición o cambio de estado).
• Direccionamiento (negociación y establecimiento de llamada).
• Explotación (gestión y mantenimiento de la red).

Para cumplir los requerimientos de señalización existen principalmente tres protocolos: H.323, SIP y MGCP.

[Read more…]

Hace ya algún tiempo que nos encontramos en un tremendo boom de la virtualización de sistemas informáticos. Gran cantidad de empresas están migrando sus sistemas a entornos virtualizados seducidos por las grandes ventajas que aportan estos sistemas encuanto a comodidad y eficiencia.

La virtualización consiste en una capa software que corre en un sistema operativo anfitrión, y que proporciona una capa de abstracción con el hardware y con el sistema operativo que hay por debajo de dicho software. Dicha abstracción es realizada de tal manera que resulte transparente al software que se ejecuta por encima de ella, es decir, cuando instalemos un sistema operativo sobre dicha capa de abstracción, esté verá el mismo tipo de procesador, espacio de direcciones y demás características hardware que vería en una máquina física, permitiendo la ejecución sin necesidad de modificaciones del software.

Dado que multiples instancias pueden ser lanzadas, la capa de abstracción es la encargada de asignar los recursos a cada una de ellas (tiempo de CPU, memoria RAM, espacio en disco, etc), permitiendo un control centralizado de las mismas desde la máquina anfitrión. Otra de las principales ventajas que aporta esta nueva vertiente es la independencias del hardware y del sistema operativo anfitrión ya que, en caso de un fallo hardware del equipo, es posible trasladar la máquina virtual a una nueva máquina física, aunque el hardware y el sistema operativo instalado en dicha máquina sean completamente diferentes a los de la máquina original, simplemente con que dicha arquitectura sea soportada por el fabricante del sofware de virtualización.

Como podéis imaginar, la aplicación de las arquitecturas virtualizadas en los planes de contingencia de los sistemas de información es inmediata, ya que en caso de desastre, simplemente con tener hardware disponible (sin necesidad de que sea igual al original) y una copia de las máquinas virtuales es posible restaurar el funcionamiento en muy poco tiempo. Sin embargo, como suele pasar en la mayoría de los casos, ninguna solución es la panacea, sino que aporta unas ventajas y unas desventajas que hay que valorar.

Concretamente, el uso de entornos virtualizados tiene algunas implicaciones de seguridad que hay que tener muy en cuenta a la hora de diseñar este tipo de entornos, con el fin de poder controlar sus riesgos de seguridad intrínsecos y reducir dicho riesgo a un nivel residual asumible por la organización.

Pero eso será otro artículo.

Tras la introducción teórica del funcionamiento del proceso de autenticación, comentada la semana pasada (I y II), es hora de abordar la metodología utilizada por las herramientas de seguridad inalámbricas que permiten realizar ataques de diccionario a la PSK, aplicaciones como Airolib (de la suite Aircrack) o Cowpatty. Aunque en un inicio pensamos separar esta entrada en dos, hemos llegado a la conclusión de que no tiene sentido, y que aunque sea un poco largo, aquellos interesados lo agradecerán.

El estándar 802.11i, y en concreto WPA, conforma un protocolo de seguridad complejo y fiable, si es utilizado de la manera adecuada. No obstante, no esta exento de ser susceptible a ataques de diccionario y fuerza bruta. En este post se detalla de forma teórica el principal “Talón de Aquiles” que presenta este protocolo. Éste reside en el proceso de autenticación entre las estaciones de la red y el punto de acceso, el llamado saludo a cuatro vías o “4 way-handshake“; dicho proceso consta del intercambio de 4 paquetes para la gestión del acceso a la red. La brecha de seguridad a la que nos referimos, y que un atacante podría utilizar, se encuentra tanto en el segundo como en el cuarto paquete, ya que en ambos la estación transmite al AP el MIC o control de integridad, y el mensaje EAPoL en claro. (Recordad que el valor MIC conforma el resultado de aplicar el algoritmo de control de integridad “Michael” al mensaje EAPoL. Dicha función toma como entrada el paquete de datos mismo, las direcciones MAC origen/destino, y parte de la PTK; todo ello genera mediante la función de HASH HMAC_MD5 la cadena de control de integridad.)

[Read more…]

Aunque como dicen allá, muchos de ustedes ya lo sabrán, leo en Kriptópolis que se ha descubierto una vulnerabilidad crítica en el kernel de Linux, que permite a un usuario interno obtener privilegios de root; efectivamente, lo hemos probado y funciona. El código fuente del exploit puede encontrarse en Security Focus, así como versiones afectadas.

Afortunadamente, existe un parche oficial, del que ya se ha sacado una segunda versión.

Ya tienen trabajo para mañana. O para esta noche.