Security Art Work

Habitualmente, todos los profesionales que nos dedicamos en mayor o menor medida a la seguridad nos vemos en la necesidad de gestionar incidentes de seguridad; para ello, nuestra mayor fuente de información suelen ser los registros o logs de los sistemas implicados, tanto a nivel de comunicaciones (routers, cortafuegos, IDS, etc) como a nivel de sistema (Unix, Windows, Linux, etc.) y de aplicación (servidor web, servidor de correo, etc.). Desgraciadamente, es habitual que cuando el potencial cliente ha contactado con nosotros, su personal técnico, siempre con buena intención, haya realizado acciones que invalidan parcial o incluso totalmente los registros y con ello cualquier vía de investigación: formateo de servidores, borrado de logs, limpieza manual de entradas, etc. Como es natural, esto limita sensiblemente la información del incidente que se puede obtener, por lo que es imprescindible que no se lleven a cabo acciones que puedan modificar “la escena del crimen”, casi de la misma manera que puede verse en una película policíaca. No obstante, dejemos eso para una entrada sobre análisis forense y pasemos al análisis de los registros.

A la hora de analizar estos logs nos encontramos principalmente dos problemas. El primero es su fiabilidad ya que ante un sistema comprometido, es inevitable preguntarse: ¿cómo de fiables son nuestros registros?, puesto que probablemente hayan sido alterados o borrados. El segundo problema tiene mucho que ver con la correlación temporal de la información contenida en los registros implicados en el incidente, generando preguntas del tipo: ¿las fechas de los diferentes sistemas se encuentran sincronizadas? ¿Qué sucedió antes y qué después? ¿De qué volumen de logs del incidente dispongo? ¿Hasta cuándo puedo retroceder?

Para el primero de los problemas la opción más habitual es contar con un sistema syslog que reciba los registros de los diferentes sistemas y dispositivos de red distribuidos por la organización, ubicado en un servidor que haya sido convenientemente securizado, limitando el número de servicios que ofrece y controles de acceso, entre otros. Esto permite tener la relativa seguridad de que la información que estamos manejando en la gestión de incidente es veraz. Además, tener los registros duplicados en el sistema de origen y en el servidor syslog permite a posteriori comparar ambos, y detectar así posibles modificaciones que proporcionen información sobre el atacante. Aunque este tipo de configuraciones son relativamente comunes en entornos donde hay mayoría de sistemas Unix/Linux, es raro encontrarlas en entornos Wintel, aunque las ventajas son similares.

En relación con la correlación de registros en el análisis del incidente, es vital que podamos determinar el orden de los acontecimientos, razón por la que el objetivo de control 10.10 Monitorización de la norma ISO 27001 requiere la existencia de un servidor NTP de sincronización que asegure que las fechas de los registros guardan un orden real; de lo contrario, en un entorno que los sistemas y dispositivos de red están no sincronizados en un rango de unos pocos minutos, la reconstrucción puede ser para volverse loco. También para este aspecto un sistema syslog es muy útil, ya que ordena de manera automática los mensajes recibidos de los distintos agentes.

Si no se dispone de un servidor syslog (o éste se limita a recibir la información de los dispositivos de red, dejando fuera los sistemas) y el volumen de información es reducido, la correlación de eventos se puede llevar a cabo de forma manual, aunque lo habitual es usar herramientas de correlacion de logs o alertas que nos permitan obtener información concreta en el menor tiempo posible, aspecto crítico en la gestión de incidentes. Esto no evitará que tengamos que revisar los logs con más detalle posteriormente, ya que aparte de obtener información adicional podría ser necesario presentar una denuncia antes las autorizades competentes, pero sí que facilita y acelera la puesta en marcha de las acciones necesarias para reducir el impacto del incidente en los primeros momentos. Con sistemas automatizados de detección, correlación y alerta, sería posible según los patrones configurados y por lo tanto, potencialmente detectables, anticiparnos al incidente; por ejemplo, pensemos en un ataque externo ocasionado por un nuevo gusano, cuyos patrones de conducta están reportados y de los que existen reglas para detectarlo o filtrarlo en nuestros sistemas (IDS/IPS).

Una visión global de estos aspectos es la que proporciona el proyecto Dshield junto con el Internet Storm Center de Sans Institute. A través de este proyecto, es posible enviar los logs de nuestros sistemas para detectar patrones globales de ataques futuros, formando de este modo un sistema de detección de intrusos distribuido a nivel global, que categoriza las amenazas en 4 niveles: verde, amarillo, naranja y rojo, dependiendo de su impacto potencial. Para evitar proporcionar información sensible al proyecto, como podrían ser las direcciones IP que están siendo atacadas, lo cual podría ocasionar posibles pérdidas para las empresas objetivos del ataque (daño a la imagen corporativa, desconfianza de clientes, etc), dependiendo del tipo de sistema, es posible enmascarar dichas direcciones, de forma que se puede ocultar total o parcialmente la dirección IP. El proyecto dispone de un gran listado de sistemas que soportan el envío de logs al sistema de correlación de forma más o menos automatizada, entre los cuales podemos encontrar dispositivos de grandes fabricantes como Cisco o CheckPoint. Una vez analizados y correlados los logs recibidos, es posible obtener las alertas generadas por el Storm Center, como por ejemplo un listado de direcciones IP potencialmente atacantes, para filtrarlas en nuestros sistemas.

Para finalizar, debemos tener en cuenta que ni el proyecto Dshield, ni el ISC de Sans, ni una correcta gestión de registros garantizan la protección de nuestra red, pero sí que constituyen mecanismos adicionales de reducción de riesgos. Y ya saben que todo suma.

(Entrada elaborada conjuntamente con Manuel Benet)

Hace algunos días mientras un amigo y compañero de trabajo revisaba el estándar ISO27002, se dio cuenta y comentó un detalle que cuanto menos nos pareció a todos curioso. El apartado “i” del control 9.2.1 sobre Emplazamiento y protección de equipos, dice:

Como habréis pensado el comentario vino a raíz de esa última palabra: “emanación”, la cual nos hizo pensar en si realmente la habían utilizado de forma correcta bajo el contexto en el que estábamos hablando. Dándole vueltas alguien recordó que había leído algo sobre la posibilidad de la captación de datos mediante el análisis de señales por emanación electromagnética, un fenómeno que desde luego parece más bien sacado de una serie de ciencia ficción, pero que no está para nada desencaminado de la realidad. Hoy vamos a hablar de los ataques TEMPEST.

[Read more…]

(Aprovechando que estamos en Fallas, hoy les traemos una entrada sobre seguridad en Fallas, con su toque lúdico-festivo)

Hace unos años durante una de las “Mascletàs” que se producen todos los días del mes de fallas a las 14h en la plaza del ayuntamiento de Valencia, unos delincuentes atracaron un banco cercano a la misma plaza, utilizando obviamente el ruido y las vibraciones producidos por la mascletà para camuflar el ruido producido por la alarma del banco (hay una leyenda urbana que dice que las oficinas bancarias de la zona desactivan sus alarmas durante la mascletà) y sus propias armas.

Es poco probable que exista una alarma, sonora o silenciosa, que sea capaz de diferenciar entre una mascletà y un tiroteo; las alarmas de vibración quedan inutilizadas por las explosiones pirotécnicas y dado el gentío que se aglutina en la zona es fácil escabullirse entre la gente y pasar desapercibido.

Aunque las entidades bancarias hayan incluido mecanismos para dificultar los atracos, como cajas con apertura retardada y cajeros blindados, es imposible que se pudiera evitar un robo como ese; estoy convencido que las entidades bancarias simplemente confían en la estadísticas… y en cerrar a las 13h durante la “semana fallera” :-) para evitar los robos.

Otra de las cosas que trae el mes de fallas a Valencia son las calles cortadas pero cortadas de verdad; no es que alguien ponga una valla amarilla a la entrada de la calle, no. Es que además de las vallas amarillas, la calle tiene en el medio un monumento fallero, un escenario para las verbenas, dos churrerías y un casal fallero, así como varias decenas o centenas de vecinos disfrutando, cada uno a su manera, de la falla y de la fiesta.

[Read more…]

Como ya hemos comentado en anteriores entradas, el pasado 18 de febrero S2 Grupo estuvo presente en el 1er Encuentro Internacional CIIP para la Ciberseguridad y Protección de Infraestructuras Críticas, organizado por el CNPIC, Centro Nacional para la Protección de las Infraestructuras Críticas.

Como parte de la agenda participé en el Taller “Gestión de Incidentes y Sistemas de detección preventiva / alerta temprana”, orientado a la implantación de las medidas de detección y alerta de incidentes, que permitan monitorizar toda aquella actividad TIC ilícita que pueda suponer un riesgo para las infraestructuras críticas. Al respecto, he de expresar mi descontento con la manera en que se enfocó el taller, compartido por la mayoría de presentes, ya que consistió principalmente en la presentación de un producto comercial, algo para lo cual existen lugares y oportunidades mejores. Esto provocó que el contenido “útil” del taller fuese muy inferior al de otros talleres.

En cualquier caso, uno de los aspectos más interesantes del taller residió en el análisis de la capacidad de las organizaciones para establecer un sistema o motor de correlación que permita aplicar una lógica avanzada a los flujos de información que tienen como origen los agentes de monitorización desplegados. En algunas ocasiones una entidad puede implantar sistemas de monitorización de intrusos, agentes de control de la disponibilidad de los servicios TIC o incluso herramientas de detección de vulnerabilidades, pero, ¿cómo poder obtener información que aporte un mayor valor de los datos cruzados de las diferentes sondas? Aquí es donde entra en acción el motor de correlación. Imaginemos una situación donde un agente de control de autenticación a nivel del SO detecta un acceso de un usuario A, pero no tenemos constancia de que el sistema de control de accesos físico o de acceso por red privada virtual haya detectado una entrada de A o una conexión remota. En este momento el motor de correlación podría deducir que existe, un robo o cesión de las credenciales de acceso al sistema o que simplemente el usuario A no ha pasado por el control de acceso físico, lo ha burlado.

Situaciones como la anterior otorgan un gran potencial a la correlación de eventos; tan sólo hay que identificar que agentes se tienen desplegados y echarle un poco de imaginación para establecer las reglas de correlación que deseemos. Por último, qué duda cabe que la información procesada por el motor de correlación debe tener como output un sistema de alertas capaz de trazar en todo momento el estado de la incidencia, permitiendo consultar toda aquella información aportada por las sondas de seguridad y que permita al gestor de incidentes aplicar las medias de actuación pertinentes.

(Para empezar la semana de Fallas, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, en la que introduce dos posibles alternativas al control del flujo de la información en una organización)

Uno de los problemas con los que se encuentran hoy en día las organizaciones es el control de la información en todo el ciclo de vida de ésta. Como es natural una organización suele disponer de más de un sistema que alberga información, además de los propios puestos de usuario, los dispositivos móviles y la posibilidad de extraer la información por medios electrónicos; así la información puede ir cambiando de entorno y modificándose, dejando ‘huella’ en varios entornos, resultando al final muy difícil concretar dónde esta residiendo la información realmente y, aspecto mas critico, quien esta siendo capaz de verla. ¿Por qué sucede esto? Básicamente porque los métodos de control de acceso a la información son barreras individuales que residen en cada uno de los sistemas en los que la información está dispersa, y no se trata por tanto de una barrera global que valide si tenemos o no tenemos acceso a ésta.

De hecho lo que realmente está sucediendo en la mayoría de organizaciones es lo siguiente: se dispone de N fuentes de información, las cuales utilizan los usuarios para 2 acciones básicamente: mantener esa información actuando sobre ella (operatoria diaria) y extraer esa información, interpretarla y enriquecerla con información de otras fuentes (información de ‘negocio’). La primera parte del uso de la información estará controlada en más o menos medida, pero es menos importante que la segunda pues requiere de un conocimiento de la acción ejecutada. Sin embargo el segundo tipo de información ha sido elaborada y refinada, y aunque sea menos particular es más precisa sobre el negocio y por lo tanto mas ‘preciada’. Esa segunda información sufre un ciclo de vida mas extenso pero a su vez se le “mima” más y se pretende que menos personal tenga acceso. El problema reside en que ese acceso esta gobernado por varios sistemas de control de acceso NO sincronizados (léase directorios departamentales, equipos de los usuarios, correo electrónico, etc.), sino dependientes del sistema de información, por lo que en muchas de las ocasiones nos podemos encontrar personal autorizado a información privilegiada sin razón alguna.

[Read more…]

En esta entrada quiero refrescar la memoria a todos nuestros lectores acerca de las políticas de acceso más comunes en el área de la informática: Mandatory Acces Control (MAC) y Discretionary Acces Control (DAC). Asimismo, y si el tiempo me lo permite, me gustaría aprovechar para iniciar una serie de entradas acerca de SELinux.

Pero vayamos a la cuestión: ¿qué es el MAC, DAC y cuales son sus diferencias?

Discretionary Acces Control es una forma de acceso a recursos basada en los propietarios y grupos a los que pertenece un objeto. Se dice que es discrecional en el sentido de que un sujeto puede transmitir sus permisos a otro sujeto. La mayoría de sistemas Linux ahora mismo usan este tipo de acceso, estando los permisos orquestados por grupos y usuarios, pudiendo un usuario normal cambiar los permisos de los archivos que posee con el comando chmod.

Mandatory Acces Control en cambio se basa en políticas. Existen un conjunto de reglas de autorización (políticas) las cuales determinan si una operación sobre un objeto realizada por un sujeto esta o no permitida basándose en los atributos de ambos. En este caso, el Mandatory refleja el hecho de que las políticas están centralizadas y no pueden ser sobrescritas por un sujeto.

[Read more…]

En esta ocasión, el artículo sobre el TOP 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como XSS, cuyas siglas en inglés se traducen como Cross Site Scripting. Por si alguien se lo está preguntando, la X es realmente una cruz y de ahí lo de Cross, ya que tuvieron que buscarle unas siglas que no pudieran confundir con CSS, Cascade Style Sheet. La nomenclatura es la misma que en Xing, la red social de profesionales, por lo que si alguna vez hay que pronunciarlo: será mejor hacerlo como crossing.

Pero dejemos las siglas para otro post y centrémonos en el XSS. Esta vulnerabilidad ha estado presente en las tres clasificaciones de OWASP. En el 2004 se consideró la cuarta vulnerabilidad más encontrada, en 2007 se posicionó en la primera posición de esta clasificación y en esta nueva versión del 2010 continúa en la parte alta ocupando la segunda posición, únicamente superada por la Inyección, que ya vimos en el anterior post de la serie.

Las vulnerabilidades de XSS son explotadas cuando una aplicación obtiene datos de cualquier fuente y los envía al navegador del usuario sin realizar una validación previa de los datos. Este tipo de vulnerabilidades permiten a un atacante ejecutar código arbitrario en el navegador del usuario permitiendo el robo de sesiones, defacement de páginas web (¿se acuerdan de Mr. Bean en la página de la presidencia de turno del Gobierno?), o incluir código malicioso de páginas no confiables por el usuario en otras que sí lo son.

Existen tres situaciones en las que nos podemos encontrar ante una aplicación vulnerable a ataques XSS:

• Utilizando los parámetros que se envían a través de una URL,
• utilizando información almacenada en el back end de datos del servidor y
• utilizando el propio objeto DOM que representa la página web que se está visualizando.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de XSS a través de una URL. Sea una aplicación que dispone de un frontal web en el que se muestra un formulario. Al seleccionar el usuario una determinada categoría, pulsa el botón de buscar y le aparece el conjunto de artículos que contiene dicha categoría. Al pulsar sobre “Seleccionar”, se envía una petición al servidor del tipo:

Una vez recibida en el servidor, obtiene el listado de artículos y devuelve la información, así como el identificador de la categoría que quedará almacenado en un input oculto para su posterior utilización de la forma:

<input type='hidden' name='category' id='category' value='<%=request.getParameter(“id”)'/>

Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que no se retornará ningún artículo de la categoría pero le permitiese, por ejemplo, recuperar la cookie de sesión del usuario y realizar cualquier acción que considere oportuna:

Para que esta vulnerabilidad sea efectiva y el usuario pueda ser atacado es necesario engañarlo, por ejemplo a través de un correo en el que se solicita que pulse un determinado enlace que visualmente apunta a una página “segura” en la que se ofuscan los parámetros que pueden ocasionar la vulnerabilidad. Si no conocían esta vulnerabilidad, es posible que a partir de hoy le tengan tanto respeto como yo a los acortadores de URL tipo http://bit.ly/9Uc1S4 o http://tinyurl.com/382hyoz, pero esto ya lo trataremos en otro post.

Del mismo modo, es posible mostrar un ejemplo de vulnerabilidad de XSS basada en el árbol DOM que representa la página web que está visualizando el usuario. Sea una aplicación que permite la selección de lenguaje a través de un parámetro con el siguiente aspecto:

Seleccione su idioma:

<select>
   <script>
	document.write(“<option value=1></option>”);
	document.write(“<option value=2>”+
		document.location.href.substring(document.location.href.indexOf(“lang=”)+8
		+”</option>”);
	document.write(“<option value=3>English</option>”);
   </script>
</select>

Al seleccionar se envía una petición al servidor del tipo:

Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que no se realizase un cambio en el lenguaje de la interfaz pero le permitiese, de nuevo, recuperar la cookie de sesión del usuario y realizar cualquier acción que considere oportuna:

Sin aprovechar ningún problema de validación en el servidor que recibe la petición ésta se transforma en un alert con la cookie del usuario en pantalla.

Por último, es posible aprovechar vulnerabilidades XSS permanentes procedentes del back end de datos del servidor de la aplicación, siendo esto posible si un mal diseño ha permitido a un usuario incorporar estos valores a través de la propia aplicación o mediante la explotación de alguna vulnerabilidad, por ejemplo las de inyección explicadas en el post anterior de la serie. De nuevo utilizamos el mismo ejemplo que desea obtener el listado de artículos de una categoría y las representa en una tabla con id, nombre y precio con una petición del tipo:

Supongamos que la tabla la compone directamente el back end del servidor en Java de la forma:

List<article> articles = proxyCategory.getArticles(id);
StringBuffer sbItem = new StringBuffer(“<table>”);
for (Article article : articles) {
	sbItem.append(“<tr><td>”).
	.append(article.getId())
	.append(“</td><td>”).
	.append(article.getDescription())
	.append(“</td><td>”)
	.append(article.getPrice())
	.append(“</td></tr>”);
} 
sbItem.append(“</table>”)

Si la información almacenada en el back end ha sido comprometida, será posible que en el campo descripción, suponiendo que éste sea el único campo de tipo alfanumérico, se puedan incorporar datos maliciosos que puedan ocasionar una pérdida de información en la interfaz del cliente, de la misma forma explicada en los anteriores ejemplos. Para que esta vulnerabilidad sea efectiva y el usuario pueda ser atacado ya no es necesario engañarlo sino que la propia infraestructura del servidor al que se conecta es la que ha sido comprometida.

Al igual que en la entrada anterior, hemos realizado la muestra de vulnerabilidades a través de peticiones GET, siendo extensible a las peticiones POST sin que los ejemplos se vean alterados. Del mismo modo, estas vulnerabilidades son independientes del lenguaje utilizado en el servidor.

Aunque la primera manera de protegerse pueda considerarse eliminar por completo el uso de javascript en la página con plugins del tipo NoScript, siempre existirán páginas en las que confiaremos y para las que habilitaremos el uso de esta tecnología. Es por tanto necesario, desde el punto de vista del programador, incorporar los controles necesarios en la programación del servidor para mitigar y eliminar este tipo de vulnerabilidades. El resto de aspectos son similares a los que comentamos la última vez: es fundamental sanear las entradas: si el valor esperado es un número, que sólo pueda ser tratado un número, si es una cadena de texto, se deben validar que los caracteres incluidos sólo puedan contener caracteres válidos. En caso de que la aplicación desarrollada deba permitir el uso de caracteres especiales, se deberá tratar con especial atención esta información y garantizar que la información que se está tratando es adecuada antes de aceptar los datos.

Y hasta aquí todo lo referente a ataques de XSS, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

En esta entrada me gustaría repasar algunas aproximaciones al respecto del concepto de Trusted Computing, y como lo lógico es empezar con la definición, por Computación Confiable nos solemos referir a sistemas completos e integrados hardware+software, en los que todo lo que se ejecuta se encuentra bajo el control del sistema y hay muy poca flexibilidad para la ejecución de otras cosas; enseguida veremos algunos ejemplos. Así pues, podría decirse que disponemos de una caja “blindada” que no puede en teoría ser manipulada ni por software ni por hardware, de modo que sólo realizará las funciones para las que esta diseñada siguiendo las directrices marcadas por el fabricante, sin que pueda ser manipulada o alterada.

Para evitar dichas manipulaciones el propio fabricante intenta proteger el sistema para que incluso el “propietario” del hardware (en el sentido de dueño del hierro) pueda utilizarlo para lo que guste. Este tipo de protecciones se usan de manera habitual para proporcionar contenidos con restricciones de uso (DRM), aplicar comisiones a los productos software, sistemas incopiables, etc. En algunos casos, los motivos aducidos serán razonables y en mi opinión otras veces abusos, la pregunta es: ¿Obedece el ordenador a su dueño? ¿U obedece a otra organizacion como Microsoft, Apple , Sony, Nokia, etc.? ¿Somos propietarios de nuestro propio hardware? ¿Quién manda en nuestra propia casa?

Algunos de nuestros lectores estarán ya pensando que que no son usuarios de este tipo de sistemas, pero la realidad es que existen muchos dispositivos de uso cotidiano que se han diseñado con esa filosofía. Vamos a ver algunos aparatos que, en muchos casos sin ninguna razón coherente, hacen “lo que ellos quieren” y no lo que quiere el dueño del “aparato”; son nuestros, pero no del todo, ya que obedecen a sus fabricantes (y a menudo en un sentido literal si existe algún tipo de conexión remota a los dispositivos).

Empecemos por las consolas de videojuegos. En todos los casos estos dispositivos están diseñados para poder ejecutar sólo un software determinado firmado digitalmente, lo que les protege de ejecutar copias de juegos, pero también impide la ejecución de software propio como Linux, o juegos sin pagar comisión. Como veremos, Internet es muy amplia y este tipo de protecciones no suelen durar demasiado tiempo, a pesar del tiempo y recursos utilizados por los fabricantes para diseñarlas (también es cierto que las modificaciones no llegan al gran público, por lo que el objetivo que se persigue con la protección se alcanza). Veamos:

• Xbox: Estos sistemas han sido vulnerados tanto por software mediante el uso de exploits, como por hacks hardware (los famosos modchips).
• Playstation 2: También reventado por hardware mediante modchips.
• Playstation 3: Les ha costado pero tras 3 años, parece que ya ha sido vulnerada.
• Wii: Vulnerado tanto por software como por hardware.
• PSP: Vulnerado tanto por software como por hardware (pandora battery).

En estos casos podríamos comentar que al desproteger el aparato se puede usar para ejecutar copias de juego, algo de moralidad cuestionable, pero también te permite ejecutar tus propios programas “hechos en casa” (homebrew) lo cual parece razonable en un aparato que has pagado y que no entra en conflicto con los intereses del fabricante que te lo vendió. Al respecto, hay ya varias sentencias que determinan la legalidad de estas modificaciones por hardware [ElPaís.com, sentencia completa en Bufet Almeida]aludiendo precisamente a la posibilidad de ejecutar programas como Linux.

En segundo lugar, están los teléfonos móviles, que cada vez son más inteligentes. En este caso, solo aplicaciones firmadas y que hayan pagado la correspondiente licencia pueden ejecutarse en estos dispositivos. En teoría, ademas se revisa que estas aplicaciones no sean dañinas para la estabilidad del teléfono, o incluso para la estabilidad de las redes de telefonía móvil (seguridad por lo tanto bastante cuestionable, si no es por la propia seguridad del protocolo, sino por el acceso a uno de los extremos). Las principales plataformas han sido manipuladas, como se muestra a continuación.

• Symbian: Solo el código firmado se puede ejecutar, si bien han aparecido diversos métodos para saltarse esas limitaciones.
• Iphone: Solo el codigo firmado y descargado de la Apple Store se puede ejecutar, también son ampliamente conocidas los hacks para poder ejecutar cualquier aplicación.
• Android: Incluso los moviles con Android por defecto no te dejan ser root (hay que hacer algunas triquiñuelas para serlo).

Por último, en la categoría de “Otros” existen multitud de dispositivos que entran dentro de este tipo de hardware. Veamos los ejemplos más relevantes:

• Ipad: Tal como lo describe la Free Software Fundation es un gran paso atrás en la historia de la computación ya que sólo permite ejecutar el código autorizado por Apple, siendo además difícil incluso acceder a los contenidos archivados en el propio aparato.
• Subsistema de video de ordenadores HDMI: Los cables HDMI de los equipos informáticos o televisiones disponen de sus protocolos de DRM, con lo que pueden establecer la resolución de la imagen dependiendo de las características del otro lado, o incluso no sacar señal si así lo deciden. Conecten un cable HDMI a su portátil, prueben a reproducir diversos contenidos con DRM y verán la pesadilla.
• Routers, dispositivos domesticos (NAS): numerosos aparatos domésticos están diseñados para que nadie pueda modificar, mejorar o tener pleno control de los aparatos.
• SmartCards, tarjetas de crédito EMV (tarjetas chip), DNI digital: Estos dispositivos aprovechan las funcionalidades de un pequeño sistema informático incrustado en la tarjeta, que tiene su procesador y su memoria, y que es muy robusto tanto desde el punto de vista del software como desde el punto de vista del hardware; al respecto, son sistemas muy difícilmente atacables en comparación con el resto de dispositivos comentados, lo que permite que la tarjeta proteja la clave privada con un PIN, y de ninguna manera la extraiga sino que solo opere con ella en su interior. Podríamos decir que se trata de un sistema confiable y que debe de ser así por la propia funcionalidad que el aparato ofrece, que protege al usuario ante un tercero que robe el propio aparato, y en principio no está a las ordenes de ninguna otra organización. En general estos sistemas no son vulnerados, quizá porque aun no están suficientemente extendidos. Debe destacarse que otros sistemas basados en tarjetas inteligentes como las de suscripciones de TV de pago si que han sido vulnerados, por lo que no seria de extrañar que también aparecieran exploits para estos sistemas.
• Decodificadores de televisión de pago: Normalmente los decodificadores incluyen una tarjeta criptográfica (que en sí mismo es un dispositivo de Computación confiable), que es el que se encarga de recibir las claves de los contenidos desde el proveedor y decodificar o no los contenidos. Al ser tarjetas criptográficas, no son fácilmente atacables debido a que además protegen un activo muy valorado economicamente. A pesar de ello, estos sistemas han sido vulnerados en repetidas ocasiones, pero en la actualidad los sistemas actuales de TV de pago están protegidos por un sistema denominado Nagra3 que parece que es resistente a los ataques.
• Trusted Platform Modules: Los equipos TPM son equipos PC que han sido adaptados para que funcionen de manera “Trusted” (Confiable/Controlada), integran procesadores criptográficos y dan una solución global (cifrado de disco, hardware, etc.). Con estos equipos se pueden diseñar sistemas que sólo ejecuten tu versión de Linux y los paquetes determinados, así como otros sistemas operativos. La solución en principio se ha diseñado para que sea robusta, sin embargo ha sido recientemente vulnerada. En torno a estos sistemas TPM y sobre todo para módulos criptográficos, en los que se quiere certificar su robustez desde el punto de vista lógico pero también desde el punto de vista fisico, existen certificaciones como FIPS que se centran en ello, como por ejemplo este pendrive.

Por último, y como precursor de todos estos artilugios, me gustaría comentar el artilugio de la edad media (popular tras la pelicula del código Davinci) Criptex, un aparato capaz de almacenar un pergamino, pero con vinagre de manera que si no introduces el código correcto destruye el pergamino. Para que vean que la idea de tener una máquina que tome sus propias decisiones en contra de quien la posee viene de muy lejos.

Todos los sistemas comentado se encuentran con los siguientes problemas:

• El software es atacable: Mediante todos los métodos que se os ocurran (exploits, overflows, etc.).
• El hardware es atacable: Se puede modificar el hardware añadiendo circuiteria (los famosos modchips que les comentaba). En el caso de las tarjetas las cosas se complican, aunque existen diversos ataques basados en modificar el voltaje, medir consumos para realizar ingeniería inversa, técnicas con microscopios electrónicos, limpiar con ácido los circuitos y otros muchos métodos de los cuales no soy ningún experto.

Como hemos podido ver, todos los intentos por parte de la industria de disponer de sistemas que no obedezcan al usuario en algún momento han fracasado, por lo que hemos de plantearnos varias cosas (aspectos que también y con mayor interés deberían plantearse los fabricantes de estos dispositivos),

• Primero, desde el punto de vista de la ingeniería, ingeniería del software y evolución técnica de la sociedad no debemos permitir que se impongan limitaciones artificiales sobre el software que se puede ejecutar en cada aparato. Sin duda alguna si el software y el hardware no hubieran funcionado como sistemas interoperables, la sociedad no habría avanzado todo lo que ha avanzado; es necesario por tanto impedir que los sistemas en su conjunto estén controlados por corporaciones.
• Desde el punto de vista de los usuarios, a nivel empresarial debemos de estar atentos a las limitaciones impuestas a nuestros aparatos/sistemas, cuáles son razonables y cuáles son excesivas.
• Desde el punto de vista de los desarrolladores de soluciones tecnológicas de este tipo, visto lo visto, hay que tener en cuenta que tarde o temprano si hay suficiente interés este tipo de sistemas serán vulnerados, y se debe de estar preparado para ese momento.

Este post me gustaría dedicarlo a Alan Turing (23 Junio 1912 – 7 Junio 1954) por inventar una máquina de propósito general, y al mismo tiempo no dedicarlo al resto de la industria por desear hacer todo lo contrario.

(N.d.E. Nada más volver del pasado verano hicimos una analogía entre la función de la norma ISO 27001 en seguridad de la información y el cinturón de seguridad en seguridad del automóvil. En ella “prometíamos” hacer un repaso a los “anclajes” de ISO 27001, en especial al Anexo A de ISO 27002. Recuperamos dicha serie con esta primera entrada de Antonio Huerta, que habla del Dominio de Control 8: Seguridad relacionada con Recursos Humanos)

Estimados lectores, muy frecuentemente el primer pensamiento por parte de las empresas a la hora de afrontar la seguridad viene marcado por fuertes inversiones, como pueden ser costosas soluciones en infraestructura de red (IDS, Firewall), la compra de antivirus centralizados, suites de ServiceDesk, o laboriosos proyectos de consultoría. Si bien acometer dichas proyectos o compras de este tipo es un requisito para la consecución de cierto grado de seguridad empresarial, no resulta ser la panacea a la totalidad de los problemas de seguridad.

Cuántas veces han visto ustedes o incluso han empleado en presentaciones la frase: la cadena es tan fuerte como su eslabón más débil. Todos a estas alturas sabemos cuál es el activo que genera mayor riesgos a una empresa y que a menudo no contemplamos en nuestros análisis de riesgos: el empleado. De poco sirve que tengamos las medidas más sofisticadas, si mediante un simple correo electrónico cualquier empleado puede enviar informes clínicos a cualquier persona, no es consciente del problema de tirar los curricula de los candidatos descartados a un contenedor de basura cualquiera o se instala un programa P2P y comparte por descuido el contenido total del equipo. Dejando de lado problemas más graves que involucran a personal responsable o con privilegios de administración a los equipos.

[Read more…]