Security Art Work

Como vimos en el anterior post, uno de los problemas de seguridad al que se enfrentan las redes VoIP actualmente, al igual que las redes de datos, es a lo que se conoce habitualmente como eavesdropping, es decir, escuchar secretamente los datos transmitidos entre dos o más puntos, sin ser participe directo de ello; en términos de VoIP, como eavesdropping podemos considerar la escucha, sin ser participe, de una conversación entre varias personas. Concretamente, debemos interceptar los mensajes de señalización y los streams de audio de la propia conversación.

Actualmente, muchas implantaciones de VoIP no están correctamente planificadas, y por tanto, comparten el mismo medio físico para transmitir voz y datos; no existe una red paralela independiente ni, en muchos casos, independencia lógica de redes basadas en Vlans, por lo que es habitual encontrar conectados a un mismo switch, tanto teléfonos IP, como equipos de usuarios.

Partiendo de esta premisa, y usando ARP spoofing o envenenamiento de la caché ARP como mecanismo para realizar un ataque man-in-the-middle, podemos capturar, analizar e incluso escuchar las conversaciones VoIP que se generan en nuestra red. En nuestro caso, para realizar el ataque de ARP spoofing, vamos a usar ettercap y Wireshark para realizar la captura de tráfico, el cual ya trae funcionalidad y filtros para redes VoIP.

Como se puede observar, el proceso es realtivamente sencillo; mientras tenemos en ejecución ettercap generando peticiones ARP falsas, lanzamos una instancia de wireshark, para realizar la captura. Una vez abierto, realizamos los siguientes pasos:

Seleccionamos los parámetros de captura de la aplicación; desde el menú “Capture” seleccionamos la interfaz a través de la cual vamos a capturar tráfico (podemos seleccionar filtros de captura). Una vez establecidos, pulsamos “Aceptar” para comenzar la captura.

Durante la captura, en pantalla observaremos una gráfica con estadísticas de los protocolos capturados:

Una vez tenemos capturados un número considerable de paquetes, paramos la captura, tras lo cual, podremos ver en la consola de wireshark, la lista de paquetes capturados. En nuestro caso:

Llegados a este punto, podemos realizar distintos tipos de análisis de nuestra red VoIP:

» Estadísticas del protocolo de señalización SIP; pulsando en el menú “Statistics -> SIP -> Create Stat“, donde podremos ver estadísticas de los distintos tipos de mensajes del protocolo:

» Estadísticas del protocolo de transporte RTP; seleccionamos uno de los paquetes RTP capturados y pulsamos en el menú “Statistics -> RTP -> RTP Streams“, donde podemos ver los flujos RTP capturados, jitter, códec usado…

No obstante, la opción más interesante la hemos dejamos para el final. Si pulsamos en el menú “Statistics -> VoIP Calls” podemos ver todas las llamadas capturadas:

Una vez tenemos la lista de capturas, podemos seleccionar una llamada cualquiera, y obtener datos más concretos, como puede ser el intercambio de mensajes de señalización SIP (Pulsando la opción Graph).

Y finalmente, reproducir la propia llamada capturada. Tras pulsar el botón “Player” en la pantalla anterior y ajustar el jitter, decodificamos el paquete, y podremos ver los distintos streams de audio, pudiendo reproducirlos de forma independiente o conjunta:

Soy de la sincera opinión de que las entidades bancarias tienen un verdadero compromiso con la seguridad, tanto a nivel técnico, organizativo, físico, como en cualquier otro ámbito que quieran imaginarse, y tengo la certeza de que invierten una cantidad de dinero nada despreciable para mantenerse a la altura que les corresponde, teniendo en cuenta lo que gestionan y lo que se juegan. Como diría aquel, más les vale. Pero, y aquí llega el esperado pero, este tipo de organizaciones, que aparte de una matriz central tienen una nada despreciable cantidad de sucursales (unas más, otras menos), son el ejemplo paradigmático de lo complicado que resulta aplicar políticas realmente seguras —y justificadamente restrictivas— a entornos “distribuidos”, y asegurar que éstas se cumplen siempre.

Digamos que tengo un amigo. Y digamos que por circunstancias que no vienen al caso, ayer éste necesitaba disponer de una copia de la escritura de su hipoteca. Puesto que trabaja, vamos a suponer, en el centro de Valencia, y pensando en evitar el desplazamiento a su oficina, llamó a su sucursal y preguntó si le podían enviar dicha documentación por fax o correo electrónico. La persona que le atendió, después de escuchar el problema, le indicó que podía enviarla por valija interna a una oficina próxima a su trabajo; eso parecía una solución razonable en ese momento, así que tras verificar telefónicamente el nombre y DNI, quedaron en eso.

Media hora después, recapacitando, mi amigo pensó que realmente, recibirla por fax en su empresa seguía siendo lo más cómodo, y que probablemente podían llevarse a cabo los necesarios controles para verificar su identidad, así que volvió a llamar, pero en este caso le atendió otra persona diferente. Tras explicarle brevemente la cuestión, acordaron dejar de lado la valija interna, y enviarla por fax, y así se hizo; diez minutos después la recibía en su oficina, en este caso sin haber sido verificada la identidad del llamante, es decir mi amigo.

Esto podría considerarse, desde el punto de vista más optimista, la escenificación de un ataque de Ingeniería Social, en el que fallan algunos mecanismos de control. En la primera llamada el atacante se identifica telefónicamente con dos datos básicos y no es posible verificar completamente su identidad, pero puesto que el medio final de entrega es completamente seguro, ya que recae en la verificación presencial y documental del DNI, eso no es necesario. En la segunda llamada el atacante, al explicar el problema, hace que el interlocutor compruebe que la documentación está efectivamente en la bandeja de la valija interna, el que asume que su compañero ha verificado previamente (y de modo exhaustivo) la identidad de mi amigo y procede a enviar la documentación por fax sin más que preguntar por el número destino.

En segundo lugar, tenemos un punto de vista algo menos optimista, que atribuye este problema a un “desliz”, un error humano, que de vez en cuando pasa, pero que no es sencillo reproducir “bajo demanda”. Y finalmente, llevando esto a sus últimas consecuencias, tenemos el punto de vista más pesimista, que es considerar ese como el procedimiento habitual.

Dejando al margen que la oficina le hizo un inmenso favor a mi amigo evitando ese desplazamiento, ¿qué opción creen ustedes que es la correcta?

La Guardia Civil, encargada del orden público y de la represión del delito, ha visto la necesidad de especializar a sus agentes para dar respuestas a la incipiente demanda social contra la delincuencia informática. Así, en 1996 se crea el Grupo de Delitos Informáticos, encuadrado en la Unidad Central Operativa de la Guardia Civil; este grupo inicial ha ido cambiando su denominación y ampliando su plantilla, pasando por Departamento de Delitos de Alta Tecnología (1999), Departamento de Delitos Telemáticos (2000), y finalmente, en 2003, Grupo de Delitos Telemáticos (GDT). Está compuesto por agentes especializados en la persecución de la delincuencia informática y los fraudes en el sector de las telecomunicaciones, cubriendo los cuatro delitos tipificados en el Convenio de Ciberdelincuencia del Consejo de Europa.

Desde finales del año 2002, desbordado el GDT por la enorme demanda (incremento de delitos tecnológicos, apoyos solicitados desde otras unidades…), se inició un proceso de descentralización de las investigaciones, formando el GDT a personal de las Unidades Orgánicas de la Policía Judicial (UOPJ) de cada una de las Comandancias de la geografía española, para constituir Equipos de Investigación Tecnológica (EDITE) provinciales capaces de llevar a cabo las investigaciones básicas en esta materia y de dar una adecuada respuesta al ciudadano en el lugar en que se produce el delito o se encuentra la víctima.

[Read more…]

Una vez descrito el funcionamiento básico del protocolo, y centrándonos en su seguridad, vamos a describir brevemente el funcionamiento de la autenticación SIP y un ataque de cracking de contraseñas.

Entrando ya de lleno en el campo de la seguridad, el protocolo SIP proporciona un mecanismo desafío-respuesta para realizar la autenticación, el cual esta basado en la autenticación HTTP. El esquema, conocido como Digest Authentication, evita el envío de la contraseña de los usuarios en texto plano puesto que hace uso de una función hash MD5 y de un secreto compartido por ambas partes: la contraseña.

Su funcionamiento es el siguiente: cuando un cliente intenta establecer una llamada con el servidor, éste responde con un mensaje que incluye un valor aleatorio (nonce) junto al dominio contra el que se va a autenticar (realm). Entonces, el cliente debe enviar una respuesta cifrada al servidor en un mensaje de tipo response, indicando el nonce, el realm junto con el nombre de usuario, el uri y la contraseña. Una vez recibidos estos datos, el servidor compara el valor de la respuesta del cliente con el resultado de cifrar él por su cuenta los mismos datos, con la contraseña que tiene del cliente.

[Read more…]

Hace unos meses, como parte del trabajo en seguridad que habitualmente realizamos, nos vimos en la obligación/necesidad de desarrollar el esquema gráfico que les muestro en la imagen inferior, cuya versión es la 1.0. Como pueden ver, en éste se relacionan entre ellos, de una manera temporal, y desde el punto de vista de la seguridad, la aparición de reglamentos y leyes, la creación de nuevos organismos y entidades, incidentes, amenazas de seguridad, y el surgimiento de avances tecnológicos. Sin duda faltará alguno, y quizá disientan en algún punto (¿Windows Vista, como amenaza o avance tecnológico?), pero lo considero una buena aproximación a la evolución del estado del arte en materia de seguridad. Tengan en cuenta, a la hora de estudiar el documento, que la escala temporal no es aritmética, y que a medida que nos movemos hacia el futuro, buena parte de los activos pasan de ser tangibles a intangibles por lo que las amenazas e incidentes varían.

Aunque en un principio pensé en incluir una marca de agua en el documento, no me gustaría que eso disuadiese a ninguno de ustedes de utilizar el documento en algún informe o presentación (por pretencioso que eso pueda sonar); de hecho, como verán las referencias a la fuente son suficientemente pequeñas para no resultar agresivas en un entorno corporativo “ajeno”. En cualquier caso, confío en que, teniendo en cuenta la licencia bajo la que se distribuye, si lo utilizan y lo modifican tendrán la cortesía de mencionar la fuente.

Por último, se agradecerán todas aquellas sugerencias y modificaciones que se les ocurran, y por mi parte, me comprometo a publicar de manera periódica (¿cada dos meses?) una actualización del documento, siempre que hayan habido cambios. Pueden descargarse el fichero, en formato PDF, de este enlace o pinchando en la imagen.

Actualización 06/03: El fichero (y parte de este post) ha cambiado ligeramente, incluyendo una leyenda con la versión y fecha del documento (1.0, 06/03/08).

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!