Ingeniería inversa de binarios

23 de febrero de 2010 Por

Aparte de la conocida seguridad por oscuridad, o la inseguridad de sentirse seguro, podemos hablar de la “seguridad por código binario”, y me explico. Hay muchos proyectos en los que todo es auditable, inspeccionado y revisado… excepto el código binario. Es muy habitual que éste se considere como algo seguro, inescrutable y secreto, ya que se considera que la ingeniería inversa es algo así como una tarea inabordable y de demasiada complejidad para ser llevada a cabo, si acaso por superexpertos.

Como ejemplo de este tipo, hoy en día existen numerosos binarios cerrados por diversas razones como DRM, licencias de producto, aplicaciones cliente servidor, o programación cerrada en sí misma. Ni que decir tiene que la mayor parte de ellos no son a día de hoy tan cerrados como a las empresas responsables de su desarrollo les gustaría. Para desmontar esa creencia de que la ingeniería inversa es para superdotados, en este post me gustaría repasar algunas de la herramientas existentes que permiten a no tan expertos el averiguar qué y cómo lo hacen los programas cerrados.

Primero de todo, no hay que olvidar que los binarios de hoy en día no son como los de antes; la complejidad del software es tal que siempre están compuestos por varios módulos y librerías dinámicas reutilizables, que son llamadas y compartidas por varios binarios a través de sus nombres de función. De esta manera es bastante sencillo identificar el funcionamiento de un binario a “alto nivel” y hacerse con la idea del programa grosso modo, sin que sea necesario analizar con detalle las instrucciones de ensamblador.

Una vez entrados en materia, pasemos a ver algunas herramientas que son útiles para averiguar qué esconde un determinado programa. Lo más sencillo que se me ocurre es la herramienta strings disponible en Linux, que como dice su nombre, al aplicarlo sobre un ejecutable muestra las cadenas del binario, en los que a veces nos encontramos con alguna sorpresa (usuarios, rutas, claves, direcciones IP, etc.):

# strings a.out

Si nuestro propósito es ver qué operaciones hace un programa a través de la red, la primera herramienta útil para averiguarlo puede ser un simple sniffer de red, de los que hay infinidad: tcpdump, wireshark, dsniff, etc.

Una herramienta curiosa para Windows que nos permite capturar tráfico cuando hay SSL interceptando la llamadas a la librería es Traceplus / Webdetective, de modo que si el binario intenta conectarse de manera cifrada para que no seamos capaces de ver el tráfico “va apañado”.

Dependiendo del tipo de binario también podemos hacer una traza de las llamadas que realiza al sistema operativo, viendo de esta manera qué fichero abre, que llamadas al sistema realiza, etc. En Linux destaca por su simplicidad strace, truss en Solaris, y Api monitor en Windows. Subiendo un poquito más de complejidad, es posible ver qué llamadas hace el binario a librerías con ltrace en Linux y con Blade Api Monitor en Windows.

En cuando a la inspección de binarios específicos de Windows (.NET y derivados), cabe destacar Reflector, un software gratuito que nos permite ver el código .net (y derivados). Por último, una técnica utilizada para desentrañar los secretos de un binario consiste en modificar y usar solo partes del programa, como llamadas a librerías. Tomando un ejemplo muy simple, si hemos descubierto el nombre de una llamada interesante como ObtainSecret();, una tarea sencilla puede ser generar un programa que realice una llamada a esa librería e imprimir en pantalla el resultado.

Y hasta aquí todas esta herramientas nos permiten ver el funcionamiento del software, sin saber ni una linea de ensamblador, viéndolo todo en alto nivel. Si queremos llegar mas lejos y tenemos conocimientos de ensamblador existen otras herramientas de depuración como IDA debugger, Ollydbg o SoftICE, mucho más especializadas y que probablemente aquellos de nuestros lectores que realicen desarrollo de sistemas o ingeniería inversa de manera habitual conocerán.

Como conclusión, si como parte de un proyecto vamos a proporcionar un binario “cerrado” a los clientes, hay que considerar todas las funciones que contenga como públicas y por lo tanto la fuerza del sistema no debe basarse en su integridad o seguridad, ya que como hemos visto con más o menos esfuerzo los funcionamientos de los binarios puede ser desvelados y modificados (el DRM tiene una curiosa historia de sistemas teóricamente inviolables que han sido rotos en cuestión de horas). Tal como si se tratara de javascript o flash, el hecho de que el códifo esté compilado en un .exe, elf o lo que sea, no lo hace impenetrable.

PD: Me tendrán que disculpar si no he puesto herramientas orientadas a Java, pero no estoy demasiado familiarizado con este lenguaje. No obstante, se trata de un lenguaje de programación complejo de alto nivel donde hay desensambladores, decompiladores, y muchas otras herramientas. Si lo desean, en los comentarios pueden aportar sus sugerencias.

(Imagen de http://www.everyjoe.com/thegadgetblog/files/2009/12/drm-locked-cd.jpg)

Clasificación de vulnerabilidades

19 de enero de 2010 Por

Está a punto de salir el nuevo “megaproyecto” web de la compañía y como desgraciadamente sucede en algunas ocasiones, los aspectos de seguridad no han sido revisados previamente a la puesta en producción. Para solventar esto, a última hora recae sobre el equipo de explotación la responsabilidad de auditar el sistema, detectar las posibles vulnerabilidades y decidir si se pueden arreglar, o si por el contrario son de tal magnitud que impiden la salida a producción del proyecto. La presión por parte de la organización en estos momentos es alta frente al equipo de explotación, por lo que las recomendaciones y decisiones que se tomen deben ser firmes y estar fuertemente razonadas.

El equipo técnico auditor mediante la utilización de ciertas herramientas automáticas y otras manuales entrega el informe, en el que aparecen tres vulnerabilidades de criticidad “grave”, cinco de criticidad “media” y tres de vulnerabilidad “baja”. ¿Qué hacemos ahora?

En primer lugar, cualquier responsable en esta situación lo primero que pide es que se solucionen todas las vulnerabilidades, y normalmente un alto numero de ellas son de resolución mas o menos sencilla: cambios en parámetros de la configuración, actualizaciones de versión en productos que no tienen interrelaciones, eliminado de ejemplos de configuración o funcionalidades innecesarias. Bien, con eso eliminamos una parte, pero en nuestro caso hipotético nos encontramos con que seguimos teniendo dos graves, tres medias y una baja. ¿Qué hacer en estos casos?

El siguiente paso es analizar la clasificación habitual de grave, media o baja, ya que es claramente insuficiente y dependerá mucho del proyecto y de la vulnerabilidad especifica. Por ejemplo, una vulnerabilidad grave que produzca una denegación de servicio, es realmente grave si se trata de un servicio en el que la disponibilidad sea un elemento indispensable, pero puede ser una vulnerabilidad aceptable en casos en los que una pérdida de servicio temporal es tolerable. Una vulnerabilidad de XSS puede ser perfectamente aceptable si afecta a una web estática, en la cual no se puedan robar ningún tipo de credenciales ni interactuar con la pagina, si bien hay que tener en cuenta que aquellos XSS que permiten modificar el resultado en el navegador haciendo parecer contenido licito puede llevar a malentendidos como los recientes de la pagina española de la Unión Europea (aunque no se pueda llegar a ella de manera directa sino a través de un enlace como si fuera phising).

En general hay que analizar con detalle como afecta cada una de las vulnerabilidades a las funcionalidades del servicio que se ofrece, y una vez hemos determinado cuantas vulnerabilidades tenemos y cuáles son sus implicaciones, si existe alguna especialmente grave, el siguiente paso no debería tener mucho misterio, aunque decisiones de ese tipo no siempre son fáciles de tomar ni dependen del personal técnico: o se arregla el problema, o no se sale a producción. Por suerte o por desgracia, en ocasiones existen criterios económicos y compromisos de otro tipo que deja poco margen de libertad, por lo que no queda otra que reducir al máximo la vulnerabilidad, trabajar para eliminarla lo antes posible, y rezar si es uno creyente.

Estas clasificaciones sobre las que he descrito de manera informal se encuentran estandarizadas y normalizadas por el FIRST; los detalles están en http://www.first.org/cvss/cvss-guide.html. Para acabar, me he permitido la libertad traducir las clasificaciones generales de vulnerabilidades:

Métrica Base

  • Vector de acceso (Access Vector (AV))
    • Local: vulnerabilidades sólo explotables desde el equipo local.
    • Red adyacente: Solo explotables desde la misma red (ataques de N2 por ejemplo).
    • Remoto: Accesibles desde cualquier acceso remoto de red.
  • Complejidad de acceso (Access Complexity (AC))
    • Alta: Complejidad en el ataque, combinación de ataques y de circustancias.
    • Media: Complejidad media para un grupo de usuario.
    • Baja: Configuracion y usuarios por defecto.
  • Autenticación: Describe si…
    • Múltiple: Si se requieren varias autenticaciones para poder explotar la vulnerabilidad.
    • Simple: Si sólo se requiere una autenticación para poder explotar la vulnerabilidad.
    • Ninguna: Si no se requiere autenticación para poder explotar la vulnerabilidad.
  • Impacto en la confidencialidad: Si se ve afectada la confidencialidad.
  • Impacto en la integridad: Si se ve afectada la integridad.
  • Impacto en la disponibilidad: Si se ve afectada la disponibilidad.

Métricas temporales

  • Explotabilidad: Si existen o no exploits disponibles.
  • Facilidad de corrección:Si es fácil de solucionar.
  • Fiabilidad del informe de vulnerabilidad: En ocasiones se anuncia la existencia de la vulnerabilidad pero no se confirman las fuentes.

Métricas de entorno

  • Daños colaterales: Posibilidades que se produzcan daños económicos o humanos por esta vulnerabilidad.
  • Distribución de equipos vulnerables: Si el número de equipos que tienen la vulnerabilidad es elevado o no.
  • Requisitos de seguridad: Si cumple con los requisitos de seguridad comprometidos por política.

Con esta clasificación el estándar define una serie de ponderaciones para obtener una puntuación exacta que resulta útil para comparar productos, organizaciones, auditorias, etc. Volviendo al origen de este artículo, una valoración global no creo que sea útil para evaluar y decidir si una vulnerabilidad te impide o no que un proyecto pase a producción, por lo que separar dicho valor agrupado mediante esta clasificación es una buena aproximación para analizar el detalle, y en base a éstos tomar las decisiones adecuadas.

En todo caso, lo que hay que tener claro es que antes de asumir el riesgo de tener una vulnerabilidad, por muy leve que sea, hay que conocer todos los detalles y tomar la decisión adecuada. Cosa que, como todos sabemos, no siempre es fácil.

Gestión de cortafuegos

30 de noviembre de 2009 Por

Uno de los problemas a los que nos enfrentamos en organizaciones con una complejidad de red media o alta es la gestión de los permisos que implican a elementos de comunicaciones (switches, cortafuegos, routers, etc.); me gustaría esbozar algunas de las cosas hay que tener en consideración para que la gestión sea posible.

Primero de todo, ante la solicitud de una petición de acceso desde un servidor a otro por parte de algún responsable técnico de algún proyecto TIC de la compañía, hay que tener en consideración dos tipos de aspectos bien diferenciados:

  • Aspectos funcionales: Si alguien solicita por ejemplo acceso al puerto de Oracle de un servidor de BBDD, lo primero que hay que evaluar es si desde el punto de vista de negocio, ese permiso debe de ser concedido. Este tipo de accesos deben ser validados por un responsable o autorizador funcional, que puede o no coincidir con el propietario del activo dentro de la organización. Es muy habitual que por agilidad en las gestiones, compañerismo mal entendido, o ausencia de procedimientos formales, este punto se pase por alto y se pase a los aspectos técnicos directamente, sin entrar a considerar la conveniencia de la solicitud desde el punto de vista del negocio.
  • Aspectos técnicos: Una vez la autorización funcional ha sido concedida, hay que revisar los aspectos técnicos de los permisos solicitados, para detectar sus implicaciones técnicas sobre otros servicios, el perímetro de la red, problemas de seguridad, etc. Algunas de las cuestiones son: ¿la red origen esta controlada por la organización, o es una dirección externa ajena sobre la que no tenemos información? ¿El protocolo utilizado para la conexión es seguro? ¿Va cifrado? ¿Implica este acceso abrir accesos con redes no confiables? ¿Afectan a la DMZ? ¿Es posible utilizar soluciones alternativas? En cualquier caso, la recomendación es que si el cambio es de cierta relevancia, tiene que haber una auditoria, tanto de caja blanca como de caja negra; esto debería ser obligatorio para cualquier acceso externo a la red corporativa, como por ejemplo el de un nuevo proveedor.

[Read more…]

Black Hat USA ’09

8 de octubre de 2009 Por

bhComo todos los veranos, este año se ha celebrado la Black Hat, un conjunto de conferencias donde se desvelan las ultimas tendencias en seguridad, cubriendo con detalle la parte técnica aunque también cada vez mas la parte organizativa y social. Aunque desgraciadamente no he podido asistir a estas charlas, tantos los papers comos los slides están disponibles en la web en la parte de archivos Blackhat.

Muchos equipos investigadores esperan a este evento para desvelar sus descubrimientos, por lo que creo que son de lectura obligatoria para aquellos que quieren ver por dónde van las ultimas tendencias y el “state of the art” en el mundo de la seguridad.

Tras echar un vistazo a las presentaciones, uno tiene la impresión que nada es seguro, ya sean teléfonos móviles, parquímetros, infraestructuras eléctricas, medidas antihacking, certificados SSL, la virtualización, la nube, o cualquier tipo de hardware que puedan imaginar. Los malos pueden incluso leer tu teclado desde el enchufe de tu ordenador, así que la única opción parece ser volver a las cuevas. En fin, que para cualquier “maldad” que puedan imaginar ya hay quien se dedica a aplicarla… y en estas charlas se pueden ver muchas de ellas.

[Read more…]

Enemigos de la seguridad perimetral

18 de junio de 2009 Por

fenceDespués de ver los enemigos de los parches, esta vez toca hablar de los enemigos de la seguridad perimetral. En principio, todo apunta a que esto debería de ser una tarea muy sencilla, basada en la regla “sólo se deben de habilitar los permisos que sean necesarios”. Sin embargo, con rascar un poco sobre la superficie, es habitual ver grandes errores en la configuración y problemas en la gestión perimetral de las organizaciónes. En esta entrada vamos a comentar los enemigos técnico, estructurales y organizativos que hacen que aparezcan problemas en la seguridad perimetral de las organizaciones. En otras palabras, cómo es posible que se llegue, sin darse cuenta, a situaciones en las que la arquitectura de la red, o la reglas y ACLs implantadas no son correctas desde el punto de vista de la seguridad.

— Las prisas. Este es un problema típico de la seguridad en todos los niveles, y por tanto, también de la seguridad perimetral, que produce situaciones como “Esto tiene que salir a producción ya”, “Tú abre los puertos para que funcione para ver si es eso y luego ya veremos”, “Tú dale usuario y contraseña de la VPN y luego lo gestionamos como toca”, etc.

Solución: Debe considerarse la parte de comunicaciones y seguridad perimetral como una parte de cualquier proyecto de implantación.

[Read more…]

Los enemigos de los parches

29 de mayo de 2009 Por

parchehuevoEl parcheado de los sistemas informáticos es una de las medidas mas importantes de seguridad que deben seguirse e implantarse en cualquier organización. Recientemente hemos podido ver como grandes organizaciones gubernamentales han sufrido incidentes de seguridad por propagación de gusanos, que podían haberse evitado en gran parte de una manera sencilla simplemente aplicando los parches. Si están pensando lo mismo que yo, se preguntarán cómo es posible que cualquier usuario domestico mantenga actualizado su equipo siempre que sale una vulnerabilidad y en estas organizaciones no apliquen el parcheado de manera correcta.

Francamente, no tengo la respuesta a la pregunta, pero en esta entrada pretendo hablar de cuáles son los problemas a los que los administradores TIC se deben enfrentar cuando tratan de implantar políticas de parcheado. A estos problemas los voy a llamar “Los enemigos de los parches”, que les detallo a continuación:

— Ausencia de política de parcheado. Si una organización no se plantea de manera consciente que debe actualizar sus sistemas, es muy posible que no se actualicen, o se actualicen sólo las cosas que sean automáticas. E incluso en este último caso, las actualizaciones automáticas si no se controlan pueden dar lugar a problemas de funcionamiento, compatibilidad y reinicios no programados.

Solución: Instáurese una política de parcheado y actualización de los sistemas, que contemple horarios, personal, procedimiento, y que como siempre deberá de venir aprobada por dirección.

— No disponer de herramienta de inventario. Obviamente, si no se sabe lo que se tiene es difícil mantenerlo actualizado.

Solución: Adquiera e instale un software de inventario automatizado, y no permita la instalación de nada que no se gestione con las actualizaciones automáticas del sistema (o que no venga autorizado por el Departamento de TI).

— No disponer de herramienta de alerta por parches. Los actualizadores automáticos, como los de Microsoft, cada vez están mas implantados, pero no cubren todo el software. En estos casos, ¿quién esta al tanto de que no aparezca una nueva vulnerabilidad en la BBDD Oracle o PostreSQL? ¿O en el plugin de foros instalado en el portal?

Solución: Debe enlazarse el inventario de software con las alertas de los fabricantes, si no es posible de una manera automática, de una manera manual.

— Software que no es base del sistema operativo. Todos los sistemas operativos disponen de un sistema de paquetes con los que es relativamente sencillo saber si hay actualizaciones, pero ¿qué pasa con otros productos instalados que no están en esa lista? ¿Alguien se preocupa por ellos?

Solución: Disponer de inventario automatizado de software, que incluya no sólo los paquetes del sistema, sino también otros paquetes adicionales. Asumo y reconozco que esto no siempre es sencillo, pero vale la pena hacer el esfuerzo; por ejemplo, piensen ustedes de como tener un inventario automatizado de BBDD Oracle en entorno Unix. Para entornos Microsoft, es especialmente recomendable utilizar WSUS (Windows Server Update Services), que facilita las actualizaciones distribuidas y la aplicación de políticas progresivas de instalación de parches.

— Productos de terceros incompatibles con los parches o sin soporte. Dicho de otra forma: tengo que poner el Service Pack 2 en un servidor Windows que tiene ademas una aplicación crítica del Call Center de la cual no tengo ni soporte ni el contacto de la empresa, y que si actualizo igual deja de funcionar. Cosas terribles como “Ese equipo no lo parchees que lleva el SCADA”.

Solución: Es necesario disponer de un contrato de soporte con todos los aplicativos que tenga, no sólo por los parches sino por cualquier problema que pueda tener; este aspecto debería contemplarse contractualmente y formalmente en el momento de la compra. Esto puede implicar que debido a una actualización se deba contratar los servicios de productos de terceros.

— Software hecho a medida. Este es un caso especial del anterior, pero que tiene más complejidad si cabe, ya que es relativamente sencillo contratar a una empresa para que te dé soporte de un producto comercial, pero es más complicado el disponer de soporte de desarrollos (si no se tienen en un primero momento).

Solución: Deben tenerse ese contacto, ya que si no es por el parcheado, en algún otro momento tambien lo necesitará. Esto obviamente tendrá un coste económico asociado, y debería contemplarse contractualmente y de manera formal en el momento de la compra.

— Ausencia de entornos de preproducción. Por muy inocuo que te diga el fabricante que es un parche, lo mejor es probarlo antes de implantarlo en producción. El problema es que en muchas ocasiones este entorno de preproducción ni esta, ni se le espera. Después de todo, ¿quién tiene un entorno de preproducción del servidor de Call Center? ¿Y del SCADA?

Solución: Para aquellas aplicaciones críticas de negocio, defina y adquiera un entorno de preproducción, o utilice para la aplicación de parches aquellos sistemas menos críticos cuyo entorno es similar.

— Equipos con escasa conectividad. Un problema frecuente a la hora de parchear son aquellos equipos que no disponen de una buena conectividad. Por ejemplo ¿cómo se parchean los equipos portátiles de los comerciales que solo se conectan por 3G y VPN? ¿O cómo se parchean los portátiles que nunca se usan porque están guardados siempre en un armario? ¿Y esos sistemas que carecen de salida a Internet?

Solución: La gestión de inventario y parches debe ser capaz de detectar equipos que no se hayan conectado y no estén actualizados, forzando la actualización, aunque sea acercándolos al servicio de soporte. Asimismo, en algunos casos puede ser necesario descargar los parches del fabricante desde una máquina con conectividad y aplicarlos manualmente.

— Islas o Reinos de Taifas. Todos conocemos algún caso: “las políticas de parches se aplican en todos los equipos, menos en los del departamento de I+D, que se lo gestionan ellos mismos por su idiosincrasia particular”.

Solución: Implántese la política de manera que cubra todos los casos y excepciones posibles, dado que no hay que olvidar que un equipo infectado en el departamento de I+D puede afectar a toda la organización, y eso no será “culpa” de I+D.

— Ausencia de administración centralizada. No va a ser posible gestionar los parches de equipos que no estén administrados de una manera centralizada. Esto parece de perogrullo, pero es uno de los principales problemas en entornos pequeños o medianos, o en organizaciones en las que tienen delegaciones pequeñas que son gestionadas de manera independiente por la ausencia de personal técnico especializado en cada una de ellas.

Solución: Deben implantarse herramientas de gestión centralizadas, inventario, distribución de software, acceso remoto, etc…

Estas y muchas otras cosas más deben de tenerse en cuenta cuando se implantan políticas de parcheado en las organizaciones, por lo que queda claro que, lejos de lo algunos puedan pensar no es una tarea estrictamente técnica, sino que viene apoyada por procedimientos, políticas y a veces, mucha mano izquierda.

(N.d.E.: La foto está sacada de Sociedadanonima.org, un extravagante blog donde estuve escribiendo un tiempo.)

Protección por HDD Password

22 de abril de 2009 Por

Desde hace un tiempo, es de notoria actualidad la problemática que supone la pérdida y robo de equipos portátiles, con los consiguientes problemas al respecto de la información corporativa albergada en ellos; hasta una organización como el FBI llega a perder más de un centenar y medio, y aun peor, el Departamento de Energia de EEUU cifra en aproximadamente 1,400 los portátiles perdidos durante 6 años. En base a esto, hoy vengo a comentarles una técnica de protección presente en muchos portátiles, pero desconocida, y destinada a proteger la información de sus discos duros.

Todos los discos duros (según el estándar ATA de la Wikipedia) disponen de un mecanismo de protección mediante contraseña, que bloquea el acceso al disco si éste no recibe la contraseña adecuada al arrancar. Dicha opción está disponible en la BIOS del ordenador, normalmente identificada como HDD Password.

La fuerza de este mecanismo reside en que el elemento que protege la información es el propio disco duro, por lo que no existe una manera de bypassear al propio disco; si es extraído del ordenador y conectado a otro ordenador no se consigue extraer la información, ya que la contraseña y la limitación de acceso residen en el propio disco. Desbloquear el disco sólo es posible ejecutando una instrucción con hardware especifico que borra todo el disco. Así pues, esta medida añade una protección adicional a la protección de lectura, haciendo inservible el equipo sin un cierto esfuerzo, lo que podría disuadir de su robo o al menos del acceso a información confidencial/corporativa por parte de terceros no autorizados.

Esta es una manera barata y sobre todo independiente del sistema operativo para bloquear el acceso a los discos, en aquellos portátiles que lo soportan. Pero, ¿es una manera infalible? Pues como se podrán imaginar, al final de la película la información está ahí y “sólo” hay una protección física/lógico (protegida por la lógica de los circuitos del disco) que la protege del acceso de “indeseables”. Una empresa de recuperación de discos accediendo directamente al soporte podría recuperar la información, y además existen en el mercado dispositivos y cables que dicen que son capaces de desbloquear el disco. Por lo tanto no debe considerarse una solución ni infalible ni definitiva, siempre peor que el uso de cualquier herramienta de cifrado de disco como puede ser Truecrypt (libre) (editado 29.12.16: el desarrollo de Truecypt se interrumpió en 2014 y no se mantiene. Se han descubierto diferentes problemas de seguridad por lo que su uso es desaconsejable. Se pueden encontrar algunas alternativas en la página siguiente: https://www.comparitech.com/blog/information-security/truecrypt-is-discoutinued-try-these-free-alternatives/) o Safeguard (comercial), pero que es un impedimento más para los amantes de lo ajeno.

Como curiosidad comentar que este mecanismo es usado por el modelo antiguo de la Xbox de Microsoft para proteger el acceso a disco por parte de cualquier ente extraño que no sean sus propios juegos, lo que hace que aunque el soporte de la videoconsola sea un disco duro IDE, no se pueda contar a un PC. Esto también impide que se pueda poner otro disco duro a la consola, ya que si ésta no detecta su disco “protegido”, no arranca, sirviendo de protección en los dos sentidos.

Por último, existe un nuevo estándar de cifrado de discos en los que son los propios discos quienes cifran, aunque no todos están de acuerdo en su utilidad. Como conclusión sobre el HDD Password podemos decir que obviamente es mejor que no poner nada, y que se trata de una medida a medio camino entre el uso del password de la BIOS (de inferior protección), y el cifrado de disco mediante software (de mejor protección).

(N.d.E.: Ya tienen la solución a la sopa de letras de la entrada anterior.)

Plan de continuidad de negocio

6 de abril de 2009 Por

La semana pasada cogí el autobús de línea para ir a visitar un cliente, vehículos que vienen equipados con diversos sistemas informáticos que generan o cancelan los billetes electrónicos. En concreto, este autobús tenía una canceladora automática de bonos de transporte y una impresora de los billetes individuales, pero sin embargo ninguno de los dos sistemas funcionaba, y estaban completamente “muertos”.

La empresa de transporte dispone de un plan para estas ocasiones, con el cual se asegura que las “cosas” sigan funcionando. En este caso, el conductor dispone de una troqueladora manual de bonos, y de un taco de billetes preimpresos, preparados para una situación como la que nos ocupaba. Esto implica que una caída total de los elementos informáticos no impide que se puedan cobrar los viajes del autobús.

Hay que admitir que a la vista de la situación, tampoco es que fuera todo sobre ruedas; al conductor se le veía bastante sofocado con el problema, y en cada parada le costaba algo más cobrar los tickets y cancelar los bonos, pero en fin, el “negocio” siguió funcionando. También hubo un momento en el que tuvo que revisar los números de los tickets y revisar la caja que tenia. Finalmente, probablemente a título personal y ante la presión, decidió optar por una estrategia más radical y no aceptar pasajeros nuevos. Esto puede considerarse como una opción válida, al encontrarse el sistema bajo mínimos, y teniendo en cuenta que aunque no abrir las puertas es una pérdida de nuevos clientes, el retraso que en cada parada se acumulaba incidía también en la calidad del servicio y la percepción por parte de los clientes “captados”.

Este sencillo ejemplo es una muestra de que mecanismos manuales como “los de siempre” pueden ser un plan B efectivo que supla la falta de disponibilidad temporal o fallos de las infraestructuras tecnológicas, aunque como sucedía en este caso el personal debe conocer los procedimientos, y estar formado en ellos. Cualquiera de nosotros puede observar cómo las cada día más fiables y sofisticadas tecnologías nos hacen también cada vez mas dependientes, lo cual no debe hacernos olvidar que prácticamente cualquier cosa en la vida puede fallar, algo que el responsable del negocio debe tener previsto y preparar a la organización para ello.

Por último, es obvio que yo era uno de los clientes “captados”, pero mientras el resto del autobús estaba bastante molesto con la situación, yo estaba disfrutando del viaje, analizando el incidente y la ejecución del plan de continuidad del autobús.

La medida más importante de seguridad

23 de diciembre de 2008 Por

Hace unos días en una reunión con la familia lejana, comenté que me dedicaba a temas de seguridad, y como suele ser habitual, los interesados tardaron poco en preguntar que les recomendaba para sus equipos caseros personales. Entonces tuve que ver cual era la medida de seguridad más importante que les iba a recomendar.

Dado que todos los presentes eran usuarios de Microsoft, lo primero que se me vino a la cabeza fue el “escudito” que Microsoft incluye en sus sistemas operativos de escritorio. Seguro que muchos de ustedes lo han visto alguna vez en la esquina derecha de la pantalla, y que de una manera semafórica le indica al usuario si su sistema es “seguro” (verde), “no es seguro del todo” (amarillo), o “no es seguro” (rojo). Hay que que reconocer que aunque sea una simplificación y las cosas no tiendan a ser tan simples, a un usuario doméstico puede ayudarle bastante. Las tres cosas que este sistema comprueba en un Windows XP son las siguientes:

– Firewall: Seguridad perimetral, si el sistema tiene activado el firewall y está protegido de ataques externos.

– Antivirus: En este caso, el sistema garantiza que existe un antivirus y que se encuentra actualizado, con lo que con suerte estamos protegidos frente a virus conocidos y software malicioso.

– Actualizaciones automáticas: Garantizan que el sistema esta actualizado, al menos el sistema operativo. Por desgracia no comprueba otras aplicaciones frecuentemente utilizadas, entre ellas navegadores y otras aplicaciones vulnerables a la asalvajada Internet, pero como suele decirse, más vale algo que nada. No obstante, no deja de ser curioso que Windows pueda “hablar” con los antivirus y comprobar su nivel de actualización, pero no sea capaz de comprobar el estado de actualización de programas populares de otros fabricantes (Apple, Adobe, Firefox, OpenOffice, etc.), algo que apunta más a cuestiones de protección de negocio que de dificultad técnica.

Por supuesto, todos estos controles y medidas son muy importantes, pero no considera la medida más importante de seguridad en —al menos— cualquier entorno doméstico, que es la que trasladé a mi audiencia: realizar copias de seguridad. Esto proteje los datos no sólo frente a amenazas cibernéticas, sino frente a desastres físicos, fallos manuales y muchas otras circunstancias indeseables. Excepto suplantación de identidad y robo de información, cualquier otro problema se soluciona con las copias de seguridad.

Estoy seguro de que a estas alturas, la mayor parte de ustedes están pensando en lo obvio que resulta lo que les estoy diciendo. Probablemente mi familia estaba pensando lo mismo. Sin embargo, también estoy seguro de que la mayor parte ustedes están pensando que no tienen copia de seguridad de sus equipos personales, o que ésta se remite a varios meses, siendo optimistas; es una tarea molesta, algo tediosa y no muy habitual para la gran mayoría de la gente. Pero es sin ningún género de duda la más importante.

Así que si tengo que dar una sola recomendación, esta es: ¡Copiad malditos! ¡Copiad!

Herramientas de acceso remoto por conexión inversa

3 de noviembre de 2008 Por

Dentro de las herramientas ciertamente peligrosas (aunque muy útiles en algunas ocasiones), durante estos últimos años se están popularizando las de acceso remoto a los PCs de escritorio, a pesar de que en realidad son muy antiguas y desde siempre han traido importantes problemas de seguridad, como por ejemplo, el Back Orifice (cuyo nombre estarán de acuerdo conmigo que es bastante descriptivo).

Las últimas versiones de estas herramientas que les comento están diseñadas para saltarse todas las políticas de seguridad perimetral implantadas en las organizaciones; por supuesto, el uso de dichas herramientas puede ser perfectamente lícito, pero puede también no serlo (y en ese caso, convertirse en un riesgo de seguridad) si no son controladas y validadas por la normativa de la organización.

La manera de funcionar de estas herramientas es mediante conexiones inversas, de modo que es el equipo interno a la organización el que inicia la conexión hacia el exterior, para luego pasar el control al sistema externo. La manera que tienen de realizar esto es iniciando la conexión, algo que suele estar más abierto o si quieren “permitido” en los cortafuegos. No obstante, en aquellos casos (debería ser en la mayoría) en que las conexiones estén cerradas y sólo se permita la conexión a navegación a través de un proxy, estos programas son capaces de utilizar una tunelización http, saltándose virtualmente cualquier protección perimetral.

Algunas de estas herramientas, que en algunos casos hemos tenido la ocasión de ver en pleno “uso y abuso”, son las siguientes:

– Webex: Esta herramienta es utilizada por muchos grandes proveedores de cabinas de disco, de BBDD, etc. Se utiliza mucho en grandes catástrofes en sistemas críticos, ya que permite al especialista que se conecte directamente para resolver la incidencia sin que medie una persona intermedia. En muchas organizaciones grandes con este tipo de equipamiento, y ante la aparición de problemas no siempre críticos, los administradores de estos equipos tienden a habilitan el acceso remoto al proveedor para que le arregle el problema, sin que este acceso se encuentre auditado, controlado y registrado en ningún sitio.

– Logmein: Esta herramienta, que recientemente se ha popularizado, hemos tenido la ocasión de verla instalada por algun usuario “espabilado” en su propio PC de oficina para conectarse en remoto (según él, para adelantar trabajo). Este servicio/herramienta tiene grandes funcionalidades, es sencilla de instalar, se pueden realizar conexiones bajo demanda (con lo que se puede uno conectar cuando quiera), pero tiene como riesgo adicional que la empresa que da el servicio también tendria la posibilidad teórica de conectarse.

– Zebedee server: Este aplicativo es un tunelizador de IP opensource, con capacidad de tunelizar por http, que permite el redireccionamiento de cualquier puerto, para que sea accesible desde el otro extremo, lo que lo hace prácticamente “a prueba” de cortafuegos.

Por supuesto, existen configuraciones de los proxys, y restricción en los permisos de instalación de software que pueden evitar este tipo de software malicioso, pero no siempre están presentes o se controlan correctamente, y este tipo de aplicaciones de acceso remoto es algo que hay que tener muy en cuenta. ¿Está usted seguro de quien tiene acceso remoto a su organización?