Fecha: 19-02-10
Elio Rojano

Hace una semana Olle Johansson anunció un fallo de seguridad bastante interesante, pero no me atreví a escribir sobre él hasta que no lo hubiésemos probado y al fín lo hicimos, y los resultados son escalofriantes:

Imaginemos que utilizamos un terminal IP (o softphone) con una cuenta limitada a extensiones SIP, en principio sólo podríamos llamar a extensiones SIP, pero el bug explica cómo aprovechar una mala programacion del dialplan y poder llamar a donde queramos:

El fallo de seguridad ocurre principalmente si tenemos una línea como esta:

exten=>_X.,1,Dial(SIP/${EXTEN})

De manera que cualquier número que marquemos, intentará llamar por SIP:

Si marcamos 800, en el dialplan se ejecutará: exten=>800,1,Dial(SIP/800)
Si queremos llamar hacia el exterior, marcamos 952123456, y en el dialplan se ejecutará: exten=>952123456,1,Dial(SIP/952123456)

Claro, que si no tenemos una extensión SIP con ese número, no hará nada y colgará la llamada.
Pero como todos ‘deberíamos’ saber, el comodín punto ‘.’ admite cualquier cosa y tantas como queramos (símbolos, letras, etc) por lo que si en lugar de utilizar un terminal IP utilizamos un softphone, podríamos llamar a nombres o a cualquier cosa que podamos escribir:

Si marcamos 3pepota, en el dialplan se ejecutará:
exten=>3pepota,1,Dial(SIP/3pepota)

Tampoco llamará a nadie, ya que la extensión 3pepota no existe.

Más después del salto…

Leer más sobre: Asterisk | Programacion | Seguridad   
Fecha: 03-02-10
Elio Rojano

Un bug encontrado en el soporte de T.38 que trae de serie Asterisk 1.6 acelera la publicación de nuevas versiones de Asterisk 1.6.

El soporte de T.38 que trae Asterisk 1.6 no es precisamente un todo-terreno, de hecho la gran mayoría de las situaciones en las que más podemos pensar que nos interesa utilizar T.38 (para enviar y recibir faxes a través de VoIP) se convierte en toda una odisea si pensamos que con Asterisk 1.6 lo podemos hacer sin más.

Hace un par de días, Asterisk™ publicó una nota de seguridad que afirmaban haber encontrado un bug donde modificando el campo FaxDatagram en el SDP provocaba que Asterisk dejara de funcionar, algo que se solucionó con un parche que ya viene incluida en las nuevas versiones de Asterisk 1.6:

- Asterisk 1.6.0.22 (ChangeLog)

- Asterisk 1.6.1.14 (ChangeLog)

- Asterisk 1.6.2.2 (ChangeLog)

Por supuesto, Asterisk 1.4, al no soportar de serie este tipo de datos no es vulnerable y por lo tanto no ha requerido de actualización.

Para descargar: http://downloads.digium.com/pub/asterisk/

Comentarios desactivados
Leer más sobre: Asterisk | Seguridad   
Fecha: 16-11-09
Elio Rojano

Aquellos que no pudieron asistir a la interesantísima charla sobre seguridad en Asterisk de la que hablamos el otro día, la teneis disponible en vídeo:

Gracias a John Todd por el aviso.

Comentarios desactivados
Leer más sobre: Asterisk | Formacion | Seguridad | VoIP   
Fecha: 07-11-09
Elio Rojano

Seguridad SIPLa seguridad debe ser, sin duda, uno de los puntos más importantes para cualquier administrador de sistemas. No hay excusas válidas para dejar desatendida una vulnerabilidad y mucho menos, ciertas acciones como “seguridad por ocultación” demuestran diariamente que no debería existir.

En Sinologic hemos hablado en varias ocasiones sobre fallos de seguridad y las consecuencias tan catastróficas que pueden tener en los sistemas, por lo que ayer, cuando leí en el twitter de John Todd que el próximo Viernes día 13 de Noviembre se celebraría una conferencia sobre Seguridad para entornos con Asterisk ofrecida por un agente del FBI especializado en este tipo de delitos, un experto de VoIPSA y dos personas de Digium (Jared Smith y Tristan), pensé que podría ser interesante y muy didáctico.

Esta conferencia es gratuita y cualquiera puede asistir, tan solo hay que registrarse en esta web: https://www1.gotomeeting.com/register/828991377

Leer más sobre: Asterisk | Eventos | Seguridad   
Fecha: 14-10-09
Elio Rojano

Cuando este lunes leí en la web de Hispasec que Microsoft haría público este martes parches para solucionar nada más y nada menos que 13 fallos de seguridad, no sabía si reir o llorar. Al fin y al cabo todos somos humanos y no existe una aplicación absolutamente libre de errores, pero 13 fallos graves de seguridad en menos de un més, es para echarle de comer a parte y rezar por todas aquellas grandes empresas, industrias, centrales eléctricas, hospitales, y demás usuarios…

Esta mañana veo en la prensa nacional que no eran 13 fallos de seguridad, si no que son 34 fallos de seguridad (ejemplos) y por lo visto la mayoría bastante importantes.

Para colmo, uno de los Most Value Professionals que Microsoft tiene, Tom Keating, acaba de publicar en su web que uno de los parches que solucionan uno de esos fallos de seguridad, hace que el flamante Microsoft Office Communication Server 2007 (más conocido como OCS2007) deje de funcionar y aparezca como una versión de evaluación ya expirada y totalmente inoperativa.

coladorNo voy a entrar en la broma fácil, ni siquiera en avisar que si una empresa utilizase OCS e instalase uno de los 34 parches de seguridad acabaría sin comunicaciones en toda la empresa, tampoco voy a dar mi opinión sobre la gran irresponsabilidad que es mezclar la seguridad del sistema operativo con una aplicación aparentemente independiente pero que no lo es tanto.

Peor aun cuando vas a la web de Microsoft y en la sección “seguridad” lo que aparecen son tristes notas de prensa como esta:

Imagen 2

Haz clic en la imagen para ampliar

En fín, creo que la gente están tan acostumbradas a utilizar un software con más agujeros que un colador que apenas le dan importancia.

Más información:

http://blog.tmcnet.com/tom-keating/dont-install-or-youll-break-ocs2007

Comentarios desactivados
Leer más sobre: Seguridad | Software Libre | VoIP   
Fecha: 24-08-09
Elio Rojano

Hace varios meses Saúl Ibarra y Jon Bonilla propusieron una idea para un proyecto muy interesante:

Congelar una versión de Asterisk y aplicar los parches necesarios para conseguir una versión verdaderamente estable y lo más segura posible basándose en las características más comunes para un Asterisk que funcione como centralita de comunicaciones.

Quizá el debate en este sentido está servido, la versión de Asterisk que Saúl y Jon parchean está basado en Asterisk 1.4, actualmente la rama más peleada y conocida y por este motivo, esta versión pasó a llamarse Asterisk-ES-RSP (Rock Solid Patchset) y consiste en un Asterisk 1.4 con todo lo necesario que solucionan los bugs que se encuentren en las características más utilizadas como SIP, features, y DAHDI.

Nuestro compañero Odicha, una mente inquieta que empezó desarrollando algunos parches para completar el soporte de tarjetas RDSI Básicas (BRI) en Asterisk 1.4 y que hoy día es de los desarrolladores más activos de la comunidad Asterisk-ES participa también en este proyecto aportando su granito de arena para conseguir facilitar la vida a aquellos que trabajan con estas tarjetas BRI y desean utilizar DAHDI.

Otros como Javier Ximenez, desarrollando el soporte del cancelador de eco comercial SoftEco e integrándolo para simplificar el tiempo de instalación para los integradores.

Y muchas otras personas (como Silvia, Ramoncio, Ramses, y un largo etcétera) que, a través de sus pruebas, comentario y sobre todo tiempo, han venido colaborando para documentar, detectar y mejorar todo lo posible esta versión.

Cómo no, es mandatory decir que Asterisk-ES-RSP no es un fork ni tiene la intención de serlo, si no una versión de Asterisk a la que se le aplican las modificaciones para corregir los más pequeños errores que pueda tener sin añadir nuevas features que puedan provocar nuevos errores, Asterisk-ES-RSP no pertenece a ninguna empresa aunque muchas apoyan esta iniciativa, y está abierto a todo aquel que quiera participar mediante su lista de correos o su página web.

Después de 6 meses de continuo testeo, pruebas y conversión de parches es de recibo reconocer la buena labor que estas personas están desarrollando, no sólo para conseguir una versión optimizada y segura, si no además la brillante intención de ponerlo a disposición de todos aquellos que quieran probarlo y utilizarlo en entornos de producción.

Podría decir que actualmente Asterisk-ES-RSP es la versión de 1.4 más fiable que existe y la única que permite utilizar tarjetas RDSI Básicas basadas en el chipset HFC (Beronet, Digium, Junghanns, Billion, Openvox, etc) con DAHDI de una manera sencilla y sin líos de Kernel ni con el mISDN.

Si estás interesado en probarlo, tan solo debes seguir los siguientes pasos:
http://www.asterisk-es-rsp.org/doku.php/instalacion:instalacion_asterisk-es-rsp


Leer más sobre: Asterisk | Programacion | Seguridad | VoIP   
Fecha: 10-07-09
Elio Rojano

sshSi sois de los usuarios/administradores que utilizais SSH para conectaros con otros sistemas, os ocurrirá a menudo que ciertos sistemas al no escribir durante algún tiempo (1, 2, 5, 10, … minutos) la conexión se cae y hay que volver a conectar habiendo perdido la información que ha ocurrido desde que se desconectó hasta que se vuelva a conectar.

Este “truco” es ultra-conocido por cualquier administrador de sistemas, pero cuando llevo algún tiempo sin hacerlo, siempre se me olvida cómo era y me toca buscar de nuevo, así que escribiéndolo aquí, seguro que lo encuentro más fácilmente. ;)

La idea consiste en que el servidor obligue al cliente a enviar un paquete para mantener la conexión abierta (lo que se conoce normalmente como keep-alive -mantén-vivo-) y se configura en el servidor SSH al que nos conectemos modificando el archivo /etc/ssh/sshd_config y añadiéndole estas dos líneas a la configuración del demonio ssh:

KeepAlive yes
ClientAliveInterval 60

Con esto, tan solo nos queda reiniciar tranquilamente el demonio ssh y al conectar, ya podremos dejar la sessión abierta sin miedo a que nos desconecte.

Nada, un post rápido y sencillo, para mantener en la memoria más que otra cosa.

Leer más sobre: Linux | Seguridad   
Fecha: 09-03-09
Elio Rojano

modem_dotsEn VentureVoIP veo la presentación de otra herramienta de auditoría de seguridad VoIP llamada WarVOX. Esta herramienta permite explorar, clasificar y auditar sistemas de telefonía. WarVOX busca diréctamente el audio y lo muestra como si fuese un “editor de sonidos”. Una de las ventajas es que no tiene porqué utilizar ningún hardware de telefonía, lo único que necesita es una manera de hacer llamadas y así poder clasificar los números a testear en diferentes categorías: voz, faxes, módems, buzones de voz, menús IVR, tonos dtmf, etc…

Una herramienta bastante vistosa de la que se pueden coger bastantes buenas ideas.

Enlace: http://warvox.org

Comentarios desactivados
Leer más sobre: Seguridad | VoIP   
Fecha: 08-03-09
Elio Rojano

Vía Tom Keating, leo que UCSniff acaba de publicar su segunda release con unos añadidos bastante interesantes, entre los que se encuentra sniffing de vídeoconferencia en H.264, uno de los pocos sniffers que consiguen hacer tests de conversaciones no autorizadas y eavesdropping de vídeo.

Entre las características que apunta, las más interesantes son:

  • Allows targeting of VoIP Users based on Corporate Directory and/or extensions
  • Support for automatically recording private IP video conversations
  • Automatically re-creates and saves entire voice conversations to a single file that can be played back by media players
  • Support for G.722 and G.711 u-law compression codecs
  • Support for H.264 Video codec
  • Automated VLAN Hop and Discovery support
  • A UC Sniffer (VoIP and Video) combined with a MitM re-direction tool
  • Monitor Mode
  • Sniffs entire conversation if only one phone is in source VLAN

Las capturas son impresionantes: http://ucsniff.sourceforge.net/ss.html

UCSniff 2.0 es GPL y podeis descargarlo de su web:
http://ucsniff.sourceforge.net/

Comentarios desactivados
Leer más sobre: Seguridad | VoIP   
Fecha: 19-02-09
Elio Rojano

1997_phonefraudcvr_chYa lo decía un empresario bloguero de un proveedor VoIP, cuando escribió un artículo comentando que por tener un Asterisk antiguo y mal configurado, alguien había descubierto una vulnerabilidad y había aprovechado su infraestructura para hacer miles de llamadas internacionales (varios miles de euros) y en aquel entonces, quizá la ignorancia, la falta de seguridad o simplemente el azar le costó su buen dinerito.

Hace poco un amigo me lo comentaba también, parece ser que bastantes “phreakers” se están aprovechando de vulnerabilidades de cualquier sistema VoIP o de una mala configuración para enviar peticiones INVITE (SIP) y poder hacer llamadas a Cuba a costa de los dueños de este equipamiento. Claro, las llamadas deben pagarse y ver en una factura cientos o miles de llamadas a Cuba no es precisamente barato. No únicamente a Cuba, estos asaltantes aprovechan tu “libre disposición de tu sistema VoIP” para llamar a cualquier país, o incluso a números Premium (los _[89]0[3456]XXXXXX) cuyos beneficiarios son, casualmente, ellos mismos, o algún familiar.

Al cabo de un tiempo, empecé a ver en algunos logs de varios Asterisk, intentos de registro, paquetes INVITES que llegaban desde IPs procedentes de Taiwan, China, Ukrania, Rusia, … y claro, como era evidente, cualquier petición iba diréctamente a la “i” de invalid. :D pero me llamó la atención la “agresividad extrema” con la que intentan enviar paquetes INVITE en cuanto descubren un puerto 5060 UDP abierto.

Pero no es únicamente Asterisk, realmente cualquier sistema tiene sus vulnerabilidades e incluso en sistemas cerrados como Cisco, Nortel y Avaya. Ya aparecen comentarios de administradores de sistemas propietarios anunciando sus ataques a las vulnerabilidades aún no descubiertas ni parcheadas. Esto es algo que se veía venir cuando uno observa el ritmo en el que avanza la VoIP. La ventaja de Asterisk es que la vulnerabilidad generalmente se corrige a las pocas horas de ser descubiertas, mientras que otros sistemas esperan “al segundo -martes- de cada mes” para hacerla pública junto con la corrección, pero para entonces, la empresa ya está arruinada, así que ya lo sabeis… en caso de duda, siempre es más seguro apostar por el software libre. :P

Estos ataques no son fáciles de evitar, pero perfectamente posibles. ¿cómo?
- Estando al día en actualizaciones, vulnerabilidades y soluciones.
- Llevando un control exaustivo del sistema (versiones de paquetes, actualizando cada dos por tres)
- Observando los logs del sistema (comprobando los accesos y los intentos de ataques)
- Evitando utilizar puertos estándares (5060, 4569,  80, 22, etc…)
- Conociendo perféctamente el sistema por dentro
- Llevando un mantenimiento contínuo
- Una buena “educación” que nos enseñe a programar y configurar el sistema adecuadamente.

Ejemplo: De poco nos sirve tener en el contexto [general] del sip.conf el parámetro ‘context=default‘, si luego en el contexto [default] del extensions.conf tenemos algo como: include=>salientes
Estos fallos son de “tarjeta roja y expulsión“, pero por desgracia cada vez más frecuentes.

¿Soluciones a estos ataques?
- Un firewall, un mísero firewall puede librarnos de muchos problemas.
- Herramientas como el “archiconocido” PortSentry para evitar escaneos y ataques DoS
- Denegar peticiones al 5060/4569 UDP desde el exterior siempre que no tengamos usuarios SIP/IAX externos.
- Deshabilitar el “allowguest=yes” que traen algunos interfaces habilitado de serie. ¬¬ (estas cosas mosquean).
- DROPear cualquier paquete procedente de cualquier IP que no sea de nuestra red de confianza.
- Configurar el “realm”, “defaultuser” y el parámetro “secret” SIEMPRE.

y sobre todo… un poco de sentido común y seguridad a la hora de permitir llamadas salientes… que ningún usuario llama 400 veces a Cuba el mismo día… :)

Nada, que os sea útil este aviso. :)

Basado en: SnapVoIP

Leer más sobre: Empresas | Seguridad | VoIP