Antes de empezar, decir que existe una forma más sencilla con iPhoneTracker, pero esta aplicación no ofrece todo el detalle, solo pinta una retícula con determinados puntos en el mapa.

Yo lo hice con mi MacBook, y ya tenía las herramientas instaladas. De modo que si alguno ya tiene un Mac, lo tiene más fácil, para los que estáis en plantaformas windows, os tocará consguir: Python, y SQLite3, como mínimo para acceder a los datos, si queréis hacer algo más, cualquier plataforma de desarrollo .Net o Java que tenga conector a SQLite os servirá, yo usé PHP, ya que lo tenía en el MacBook todo funcionando.

Lo segundo que necesitamos es localizar la copia de seguridad que almacena iTunes cuando sincronizamos, es importante que no esté encriptada, por cierto es una buena forma de proteger que se pueda acceder a los datos que se almacenan en el teléfono:

En Mac se guardan en /Users/TUNOMBREDEUSUARIO/Library/Application Support/MobileSync/Backup
En Windows \Documents and Settings\TUNOMBREDEUSUARIO\Application Data\Apple Computer\MobileSync\Backup\

Cuando accedéis a estas rutas, es probable que encontréis de una a varias carpetas, cada una corresponde con una copia de seguridad, ordenar por fecha y tomaremos como referencia, la más reciente.

Una vez dentro veremos que, casí, todos los ficheros tiene un nombre… raro, es el nombre con el que se guarda los ficheros que se copian en el backup, es la forma de proteger que tiene iTunes nuestros datos. También veréis algunos ficheros que tienen un nombre más familiar. Nos centramos en dos, Manifest.mbdb y Manifest.mbdx. Estos dos archivos contienen el detalle de todo lo copiado, y nos ayudarán a localizar “consolidated.db” en la lista de archivos indescifrable que teníamos al entrar en el directorio de nuestro backup.

Acceder a estos archivos es una tarea un tanto complicada, tendremos que parsearlo. Yo me ayude de un script en Python que encontré en internet. Me lo copie al directorio de la copia, y lo ejecuté con el siguiente comando “python Nombredelarchivo.py > miBackup.txt” es necesario redirigirlo a la salida de un fichero de texto para luego localizarlo.

Abrimos el fichero de texto miBackup.txt, con un editor de texto en el que nos sintamos comodo (textedit o block de notas) y buscamos el “consolidated.db” , y a la izquierda nos pone, entre parentesis el nombre del fichero en un formato hexadecimal. Buscamos ese fichero y lo copiamos a otro directorio con el nombre “consolidated.db”. Ojo no hacerlo sobre el directorio del backup que luego podemos liarla.

Ya tenemos lo más difícil. Desde el terminal nos vamos al directorio en el que copiamos el archivo y abrimos el archivo con SQLite3: en el pront del terminal ponemos “sqlite3 consolidated.db” y nos mostrorá el pront de SQLite3. Bien, ahora solo nos queda ejecutar la consulta, un poco de SQL, escbimos esta sentencia “SELECT datetime(Timestamp+978307141, ‘unixepoch’, ‘localtime’) as fecha, Latitude, Longitude FROM CellLocation;”

Al pulsar intro empezará a darnos todas las coordenadas, por lo que puedes probar en el GoogleMaps a poner la latitud y la longitud y te las pintará en el mapa.

Para salir de SQLite .quit o .exit en su pront, y volveréis al pront del terminal.

Aquí podréis comprobar lo que explicaba en mi post anterior, con un mismo timestamp, aparecen varias latidues y longitudes. Podréis observar saltos en el tiempo muy espaciados, incluso en algunos casos un día. Esto es debido a que solo recoge la información de las antenas que están a su alrededor cuando ha notado grandes desplazamientos y está parado. En mi fichero, en los viajes que he realizado no me ha recogido toda la ruta, solo determinados puntos intermedios.

Espero que os ayude a quienes tenéis la curiosidad de que es lo que guarda el iPhone o el iPad cuando nos movemos, podéis probar a ver que es lo que tiene la tabla WifiLocation, que como comentaba en mi anterior post, también guarda las latitudes y longitudes de las WIFI que nuestro dispositivo detecta a su paso.

Si después de esto, sigues necesitando tener la tranquilidad de que tus movimientos no pueden seguirse, dos consejos:
- Cifra la copia de seguridad que hace iTunes (revisa la configuración de la copia)
- O si tienes el JailBreak, busca en Cydia Untrackerd, que borra lo almacenado en el archivo “consolidated.db”

Si has actualizado tu iPhone/iPad, a la versión 4.3.3 del iOS ya no podrás acceder a estos datos, ya que con la actualización que Apple sacó a toda prisa, se borran las tablas que almacenaban toda información relacionada con la localización.

Lo primero que hice fue probar la aplicación que rápidamente apareción en internet, iPhoneTracker, pero la información que esta ofrece es muy genérica, y solo muestra algunos puntos para no penalizar el rendimiento.

Como no me quedaba tranquilo, me puse a investigar. Lo primero averiguar como localizar el fichero consolidated.db en la copia de seguridad. Una vez localizado abrirlo con SQLLite3 y consultar. Aquí empieza lo interesante.

Una tabla llamada CellLocation y otra llamada WifiLocation. Cómo!!! No solo guarda la posición de las antenas de telefonía a las que accede el teléfono, también a las wifi que encuentra allí por donde pasa. Lo primero, mis manos se han ido a la cabeza.

Vamos a ver que es lo que tienen. Y en la tabla WifiLocation, guarda aquellas MAC ADDRESS de los routers que localiza a su paso por la calle, y guarda la Latitud y Longitud del punto de acceso. En la tabla de CellLocation, almacena, Latitud y Longitud de todas las antenas que en un determinado momento a conseguido recopilar en la zona en la que nos hemos movido.

Interesante información, el motivo por el cual existe este fichero, aún se desconoce, existen todo tipo de rumores. Desde su uso para iAds (motor publicitario de Apple que ya causo su revuelo), hasta un posible bug aún por determinar.

El caso es que tanto revuelo me había causado ya cierto pánico, y como ya estaba investigando, he seguido. Monto un php que me permita consultar la información, de momento el CellLocation, lanzamos una consulta, pintamos resultado en pantalla, y analizamos.

Lo primero que descubro, es que con un mismo timestamp (mismo momento de tiempo) existen varios registros con distintas latitudes y longitudes. Curioso, ¿no? Pruebo al azar y descubro que sí, que acierta bastante en las zonas, pero es difícil sacar una conclusión, de que es lo que estaba haciendo un preciso momento como no me sometan a un interrogatorio. Vale, ya me quedo más tranquilo, es más en muchos casos he podido observar como por haber pasado por una calle concreta, me marca una zona muy amplia, incluso en algunos casos, he visto como llegaba a ampliar el rádio de acción en 60, 80 y 100 km, y todo porque en algún momento a tomado como valida la señal de alguna antena.

Para muestra dejo esta captura. Solo yo, y a quien me pregunte, sabre que hacía en ese momento de un día de diciembre del 2010. Insisto es con el mismo timestamp, es decir, son las posiciones de las antenas que guardo con la misma marca de tiempo. Creo que solo se puede sacar una conclusión, que estuve en esa zona tan amplia, nadie sabra haciendo el qué.

Después de investigar un rato, me quedo más tranquilo. Existen opciones con las que evitar y/o mitigar este problema, pero lo dejo para otro momento.

Todo esto sucedía hasta la aparición de la versión 4.3.3 del iOS. Apple se ha dado prisa en implementar una funcionalidad que elimina los datos, por lo menos al hacer la copia de seguridad.

Revisando las noticias de seguridad de lo último días, se me acumulan, me encuentro con un nuevo atque masivo a los blogs y sites que funcionana con WordPress, por suerte los blogs que gestiono/colaboro como Maverit.com y Gallardeo.com y este en el que escribo están exentos por el momento del ataque pero no puedo bajar la guardia, ya sabemos como se las gasta la (in)seguridad del mudo tecnológico.

Más información en http://blog.sucuri.net/2010/05/new-attack-today-against-wordpress.html

Esto puede resultar útil cuando no tenemos control sobre el servidor donde alojamos nuestras páginas y queremos hacer una sección privada donde todo el contenido que aparezca en un directorio concreto esté bajo validación de usuarios.

En este tutorial, se mostrarán dos formas de hacerlo con la autenticación de formularios mediante la configuración de los usuarios en el web.config y consulta de usuarios en una base de datos.

Esta autenticación se basa en las cookies de navegador para determinar la identidad de un usuario. Una vez activada en un directorio, no podemos acceder al contenido del directorio salvo que dispongamos de la autenticación adecuada almacenada en una cookie.

2.- ¿Qué necesitamos?

Para activar la autenticación de formularios básica en una aplicación, realizaremos los siguientes pasos:

• Configurar el modo de autenticación modificando la sección authentication en el web.cofig de la aplicación.
• Denegar el acceso a los usuarios anónimos en uno o más directorios de la aplicación, mediante la modificación de la sección authorization en los archivos web.config de los directorios privados
• Creara una página de registro con un formulario que permita la identificación de usuarios.
• Para la validación contra la base de datos, necesitaremos un servidor de base de datos en el que configuraremos una tabla de usuarios y un procedimiento almacenado.

Para empezar vamos a crear un directorio, PRIVADO, y dentro de este una página default que nos muestre un “HOLA MUNDO PRIVADO” para validar que vemos el directorio en nuestra web.

3.- Modificando el web.config.

Con el directorio privado que hemos creado, y desde el cual podremos colgar todas nuestras herramientas administrativas del site, como el acceso a descargas o imágenes personales, tenemos que realizar una serie de modificaciones en el web.config

En este tutorial no nos vamos a parar en explicar al detalle todas las opciones que se puede usar para la crear un acceso privado, solo nos ocuparemos de las opciones que vamos a usar.

El fichero web.config se encuentra localizado en el directorio raíz de la aplicación web con la que estamos trabajado. Al abrirlo veremos que dentro de la etiqueta system.web se encuentran diferentes opciones, las que ocuparan nuestra atención son las entradas authentication y authorization, ya que son en las que realizaremos las modificaciones.

En el caso de que no exista este archivo web.config podremos crearlo, pero siempre en el raíz de la aplicación.

3.1.- authentication

El archivo web.config contendrá el siguiente código:

Como se puede observar, y parece obvio, el modo de autenticación de nuestro directorio será mediante un formulario, quedando esto reflejado en la propiedad mode=”Forms”

Dentro de la sección forms se definen el funcionamiento de nuestro formulario:

• name: el nombre de la cookie de navegador que contiene la entrada de autenticación. Si no especificamos uno se llamará .ASPXAUTH
  Recomendamos que si usamos varias aplicaciones en nuestro servidor web se especifique un nombre por aplicación.
• loginUrl: indicaremos la página a la que se dirigirá al usuario, de modo automático, cuando se precise su identificación. Si no especificamos una página, por defecto se redirige a login.aspx situada en el raíz de la aplicación web.
• timeout: es el tiempo, en minutos, que la cookie tiene validez, siendo de 30 minutos el valor por defecto.
• protection: especifica la forma en que se protegen los datos de la cookie. Los valores son All, None, Encryption y Validation, siendo All el valor que se toma por defecto.
  Por omisión las cookies sé encriptan con DES o TripleDES, dependiendo de la capacidad del servidor.

El elemento credentials nos servirá para configurar los usuarios que tendrán acceso a nuestro directorio privado. Esto es útil si no tenemos un listado largo de usuarios y que no queremos o nos es necesario realizar labores de mantenimiento sobre estos.

Este elemento es bastante simple de entender ya que se creará una entrada por cada uno de los usuarios que tendrán acceso a las aplicaciones o elementos descargables que tengamos en nuestra zona privada. En estos configuraremos el nombre de usuario y la password.

Si deseamos disponer de una mayor seguridad, por si algún curioso lograra acceder al servidor y ver las password podríamos encriptarlos utilizando los algoritmos hash SHA1 y MD5, para ello tendríamos que cambiar el valor de passwordFormat por SHA1 o MD5. Pero la forma de encriptar este password y acceder a ellas lo trataremos en otra ocasión.

4.- Configurando el directorio.

Bien, ya tenemos listo el sistema de autenticación, hemos creado el directorio que deseamos hacer privado y preparada una página que nos servirá de bienvenida a la zona privada.

Ahora solo nos falta hacer que este sea privado. Para ello será necesario crear un fichero web.config en el raíz de nuestro directorio privado. En este web.config configuraremos la sección authorization, donde denegaremos el acceso a los usuarios anónimos.

El contenido del web.config será el siguiente.

Dentro de la sección authorization, se permite las siguientes entradas:

• deny para denegar usuarios
• allow para permitir el acceso a usuarios.

Ambas entradas tienen la propiedad users donde podemos especificar:

• ? todos los usuarios anónimos.
• * todos los usuarios, tanto anónimos como autenticados.
• Lista usuarios, se permite especificar un listado de usuarios separados por comas, que tendrán permitido o denegado el acceso según donde se especifique

5.- La página de Login.

Bien ya está todo listo, hemos configurado el directorio, le hemos dado las indicaciones a la aplicación para que nos autentique a los usuarios, hemos definido la autorización del directorio, pero no falta hacer logo, ya que sin esto no veremos nunca ese HOLA MUNDO PRIVADO que hemos preparado.

Pues manos a la obra. Tenemos que crear un formulario web, pero no voy a explicar como hacerlo, se supone que esto ya sabemos hacerlo, pero si no tenemos ganas de golpear teclas, descarga aquí el zip con todo el código.

Este formulario web tendrá los siguientes elementos:

• Una caja de textos, con su correspondiente título donde pidamos el nombre de usuario.
• Una caja de texto, y su titulo, donde pidamos la password, esta tendrá la propiedad textmode=Password.
• Un checbox, con su titulo para que el usuario marque que le recuerde la password en el futuro.
• Un boto de enviar, y opcional otro de borrar.
• Una etiqueta para mostrar errores.

Opcionalmente podemos insertar el objeto que nos valide que el usuario a insertado los datos de forma correcta en el formulario.

Ya hemos creado, pintado y dado color a nuestra pantalla de login. Todo al gusto, no me meto.

Como apuntaba al principio de este tutorial, la intención era enseñar dos métodos de validación, una por la configuración de usuarios en el web.config y otra mediante consultas a base de datos.

5.1.- Usuarios en web.config.

Ya se ha explicado donde y como se configurar, si no lo tienes claro pincha aquí. Y ahora tenemos que hacer que cuando el usuario pulse el botón enviar se nos valide y de acceso a este al directorio o nos deniegue el acceso en caso de error.

Para eso incluiremos el siguiente código en el fichero VB de nuestro formulario:

Con IsValid comprobamos si el formulario está correcto, esto era opcional.

En la siguiente validación empieza lo duro, ya que con el método Autenticate de la clase FormsAuthentication, hacemos que se localice en el web.config el nombre de usuario y la contraseña introducidas. Devolverá un true o false si lo encuentra o no en la sección credentials.

En el caso de que la respuesta sea errónea, pintamos el correspondiente mensaje de error en la etiqueta reservada para esto.

Si hemos acertado con el usuario y la contraseña entra en juego el método RedirectFromLoginPage, al que le pasamos el usuario y el valor del check para que en el futuro nos pregunte o no por nuestra identificación. Este nos devolverá a la url que hemos intentado acceder dentro de nuestro directorio privado antes de que se nos mostrara la página de login.

5.2.- Usuarios en base de datos.

Ya hemos vista la forma simple de hacer login con nuestros usuarios en el web.config. Ahora lo podemos complicar un poco más utilizando la base de datos, si es que tenemos disposición de hacerlo.

Supongamos que tenemos un SQL Server instalado y que tenemos acceso a el. Tendremos que configurar una tabla, donde tengamos un campo login y otro password como mínimo, el resto de campos a elección. No explicaremos como crear la tabla y el procedimiento almacenado, que reservado para otro tutorial. Si queréis evitar crearlo manualmente, pincha aquí y dentro del zip encontrarás el Script SQL que genera la tabla con esta información mínima y un procedimiento almacenado para buscar el usuario.

Vamos a usar la mismas página aspx que en el ejemplo anterior, pero en esta ocasión añadimos un botón más que nos servirá para llamar a una función diferente.

En esta ocasión necesitaremos importar las siguientes clases para el manejo de base de datos:

Imports System.data
Imports System.Data.SqlClient

Tras pulsar el botón de validar en la Base de datos, se ejecutará el siguiente código:

Como se puede observar este código es similar al anterior. IsValid nos valida el que el formulario sea correcto

En la siguiente comprobación se hace una llamada a la función, que tendremos que incluir, para realizar la validación contra la base de datos.

La función queda como sigue, se ha de prestar atención a los comentarios para comprender que hace el código:

Sin entrar en detalles de manejo de base de datos, la función prepara el acceso a la base de datos, y el uso del procedimiento almacenado, le asigna los valores nombre de usuario y contraseña a los parámetros del procedimiento y lo ejecuta.

El procedimiento almacenado se encarga de localizar en la tabla en nombre de usuario, y comprobar la password, en caso de ser correctos devuelve el ID correspondiente en la tabla al registro. Este procedimiento controla dos posibles errores, es simple, si no localiza el nombre de usuario devolverá el error -1 y si encuentra el nombre de usuario pero la contraseña no coincide devuelve un -2.

Esta misma función toma como valor el resultado del procedimiento almacenado por lo que al evaluarla desde la pulsación del botón, solamente en caso de que el resultado sea mayor a 0 se redirigirá al usuario a la página o directorio que solicitó, de igual modo que sucedía con la validación del usuario configurado en el web.config, mediante el método RedirectFromLoginPage, que espera recibir nuevamente el nombre de usuario y y el resultado del check que nos evitará la inserción de estos datos en el futuro mediante el control de la cookie.

6.- La prueba.

Si todo está bien y se han seguido los pasos indicados, nuestro directorio estará protegido contra usuarios anónimos. De modo que si llamamos al directorio privado desde le navegador, http://miservidor/privado nos responderá la página de login que indicamos en el web.config, y tras identificarnos correctamente accederemos a la página que habíamos solicitado dentro del directorio privado.

Con esto ya se puede configurar diferentes herramientas administrativas que gestionen el site, o un lugar donde guardes tus fotos personales y que solo quieres que algunos tenga acceso.

7.- Notas.

En la validación por base de datos, no se ha mencionado ya que ase asume que sabemos acceder a base de datos, pero es necesario configurar en el web.config del raíz de la aplicación la cadena de conexión a la base de datos. Esta cadena de conexión es usada en la línea

conMyData = New SqlConnection(ConfigurationSettings.AppSettings(“nevaCnnString”))

¿Cómo decidirse entre configurar los usuarios en el Web.config o en la base de datos? Todo dependerá del número de usuarios que se tiene previsto mantener, si queremos mantener de 3 a 10 usuarios, nos decantaremos por la solución web.config, pero si el número es mayor y encima se permitirá el crecimiento de usuarios la mejor solución es la base de datos

Dicho así puede resultar una tarea complicada, conocer todo el software que tienen instalados cada uno de los equipos informáticos que componen el parque tecnológico de una empresa es tarea altamente compleja, pero existen soluciones que nos lo recopilan y que los responsables de instalaciones tendrían que conocer, instalar y usar, siempre desde el apoyo de las correspondientes políticas.

Es responsabilidad de aquellos que tienen la gorra de seguridad conocer los listados de software y versiones que dichas aplicaciones generan, ya que es la única forma de prevenir problemas de seguridad por la aparición de un bug en una o varias de las aplicaciones que los usuarios (compañeros de trabajo) tiene instalada en sus máquinas.

Con este listado, solo nos falta estar al tanto de las correcciones que los distintos fabricantes de software publican e informan de las correcciones. Recorrer una a una las distintas páginas de los fabricantes puede ser un suplicio, pero existen webs que ya hacen este trabajo por nosotros.

Una de las listas que más me gusta y que suelo vigilar con asiduidad es la newsletter de Sans, en donde encontramos largos listados de actualizaciones y noticias de bugs en prácticamente todo el software existente.

Hace tiempo que acudo a charlas sobre seguridad en el desarrollo y siempre acudo con una gran ilusión, hoy es el día me van a enseñar como desarrollar de una forma segura, y según me siento y empiezan las charlas todo promete hasta el momento en el que el ponente cae en el mismo error que los anteriores, voy a enseñaros lo que es un SQLInjection, lo que es un XSS, que son las principales vulnerabilidades existentes en las aplicaciones web. Incluso los más “cultos” en esto de la tecnología se atreven a decir que entorno o leguaje es más seguro, todo depende de quien les pague la nomina.

Todos estos ponente son unos grandes profesionales en el terreno, peor caen una y otra vez en el mismo error, enseñar lo mal que se hacen algunos desarrollos, pero ninguno se preocupa en decir que guías mínimas han de seguirse en función de la plataforma en la que se esta trabajando.

Para no caer en el mismo error que que muchos grandes profesionales, os dejo este link a la MSDN dónde se pueden encontrar mucha información, guías y consejos, así como código de lo que sería el desarrollo seguro. Y para dar pie a las buenas prácticas este otro link a los fundamentos de Aplicaciones Web Seguras.

Desde aquí lanzo una pregunta ¿Alguna empresa de desarrollo incorpora en su kit de bienvenida la guía de desarrollo seguro cuando contrata a un nuevo desarrollador?

Las noticas que se pudieron ver en televisión y en leer en los medios on-line nos mostraban una imagen donde los principales candidatos al gobierno habían sido colocados en la web de un tercer partido político, una imagen burlona que no hacía más que reflejar como había sido burlada la seguridad de la web en cuestión.

Hablamos de política, dónde se suponen las mejores inversiones en tecnología y seguridad por lo que concierne a la seguridad de la información, una política que ha sido agredida por la acción de quien se ha preocupado en dedicar un rato en encontrar el error, dejando así al descubierto la calidad de los proyectos de desarrollo.

Como se ha dicho ya en otras ocasiones, el eslabón más débil es el desarrollo por lo que se ha de tomar conciencia en formar e informar a nuestros equipos, meter el miedo a nuestros mayores para que nos apoyen y nos den el dinero suficiente para invertir en que estas cosas no sucedan, , rompiendo así los mitos que comentaba en la entrada El Eslabón más Débil.

• Tengo un firewall que me protege.
• Estoy usando SSL en mis aplicaciones web.
• Mis servidores están actualizados hasta el último parche.
• Nadie puede ver mis bases de datos.
• Hace 6 meses pasamos la auditoría de seguridad, ¿para que más?

Bien, como decía esto son algunos tópicos que hacen crear una falsa sensación de seguridad, el eslabón más débil se puede romper. Analicemos la situación:

• Tengo un Firewall: si necesito un firewall es por que tengo conexión a internet o por que quiero proteger ciertos segmentos de mi red. Hasta aquí está todo correcto, le pongo, lo configuro, contrato a un administrador de Firewall, y ya estoy seguro. Pero claro, que mi red ha de tener tráfico que permita la comunicación, por lo que ciertos puertos han de estar abiertos, a saber, puerto 80 para el tráfico web, puerto 25 y 110 para el mail, ya tengo las puertas abierta al público, eso sin contar con otros protocolos de comunicación.
• SSL: que mejor forma de proteger los datos de mis aplicaciones que viajar cifrados, así un men in the middle no puede lograr leer y modificar los datos. Ya tengo que añadir otro puerto más, 443, a abrir en mi firewall, y cuando los datos llegan a la aplicación se descifran y viajan entre servidores descifrados, del servidor de aplicaciones al servidor de base de datos, y ¿estoy seguro que los datos no incluyen ataques de SQL Injection o XSS?
• Los Parches: cuento con mis sistemas operativos y servidores web, aplicaciones y bbdd correctamente parcheados, pero que es lo que ha sucedido al aplicar el parche, me ha actualizado alguna de mis políticas de seguridad, cómo he aplicado estos parches, cuento con un entorno idéntico al de producción en el que hacer pruebas y validar antes de confiar. Y los parches no protegen las aplicaciones propias que se desarrollan por la necesidad de mi negocio, quién me protege estas, un parche puede dejar al descubierto una debilidad de mi aplicación, que tendré que corregir lo más rápido posible.
• Ver mi base de datos: mi base de datos está correctamente aislada por el firewall y parcheada, ya nadie puede acceder. Realmente para poder afirmar esto, se tendría que cortar hasta el acceso de las aplicaciones a los datos, en ese caso, ¿para qué tener una base de datos y una aplicación si no puedo acceder a los datos? Cualquier vulnerabilidad en mi aplicación permitirá múltiples opciones de acceso a un atacante mediante técnicas de SQLInjection.
• Pasamos la auditoría: sí, la auditoría la pasamos hace 6 meses, un mes, 15 días ¿qué más da cuando se pasó?. Nuestro negocio sigue avanzando, sigue creciendo y se siguen haciendo cambios. La simple aplicación de un parche o de una actualización de nuestras aplicaciones hacen que la auditoría que pasmos ayer la tengamos que volver a revisar y mantener los checks de las listas de validación.

Y, cuándo estoy seguro de que estoy seguro. Es una pregunta que, por lo menos yo, no me arriesgo a afirmar que estoy siempre seguro. La verdadera seguridad es no bajar la guardia, estar siempre pendiente de las actualizaciones, vigilar constantemente los análisis de tráfico, aplicar herramientas que me ayuden a detectar intrusiones y errores, hacer continuas pruebas a todos mis sistemas, sobre todo a las aplicaciones que genero, mantener el nivel de formación en todos los integrantes de una organización. Si bajo la guardia un solo segundo y me creo que estoy seguro, he roto el eslabón más débil de la cadena que me proteje.

Tampoco nos podemos volver locos aplicando seguridad, y el gasto ha de estar equilibrado a la necesidad real, he aquí el existo del gobierno que se ha de realizar.

El titular decía “Intrusión en laboratorio nuclear norteamericano”, el resumen de la noticia venía a ser que en el ORNL (Laboratorio Nacional de Oak Ridge,Tennessee USA) venía siendo objetivo principal de phising entre los años 1990 y 2004. Cartorce años, en los que han recibido diferentes miembros de muy distintos cargos, correos basados en algo tan antiguo como el engaño para obtener las claves de acceso a los sistemas. Lo sorprendente de todo, es que algunos empleados cayeron en la trampa y facilitaron claves, lo que no dice la noticia es el daño que esto ha ocasionado.

Al margen de políticas, ya que parece que el ataque está organizado desde China, esta noticia refleja la realidad en la seguridad de la información. Y es que se puede diseñar, construir y configurar el mejor de los sistemas de seguridad, blindar todo, peo al final la parte humana es la que determina el nivel de seguridad máximo que un dato puede tener.

Es aquí donde entra la cultura de la seguridad de la información. En los últimos años se ha visto incrementada la conciencia por “proteger el dato”, y en esto la banca tiene mucho que ver, por que cuando vemos en peligro nuestros ingresos nos preocupamos. Pero en los entornos empresariales es dónde la cosa es mucho más compleja.

Son muchas las ocasiones en las que se detectan errores en los sistemas, errores producidos por las prisas, la falta de conocimiento, o la falta de prioridad a la seguridad de la información, esta se deja siempre para el final. Cuando se cierra un desarrollo y se detecta un error de seguridad, se suele escuchar como el equipo de desarrollo dice “pero los usuarios que van a utilizar esta aplicación no son técnicos, simplemente son usuarios, solo van a insertar los datos que la aplicación les pide, y hacer todas estas validaciones de los datos supone mucho más trabajo, y total para 10 usuarios…”, es algo que he escuchado a lo largo de muchos años, y es que a nadie nos gusta que nos critiquen nuestro trabajo, y se suele acompañar con un “… eso nunca nos va a suceder a nosotros…”

Es un gran error no plantearse quién es nuestro usuario, que hace en su trabajo, a dónde va con el portátil, cuanta información somos capaces de sacarle si le damos confianza, esa parte de la ingeniería social, que nadie desarrolla en un proyecto y que puede evitar muchos sustos, si se plantean desde el punto de vista de los riesgos y la importancia que tienen los datos que van a ser utilizados por la aplicación para el usuario y la compañía.

Esta falta de cultura por proteger la información, en parte motivada por la velocidad a la que se demandan los desarrollos, hacen que ataques como el comentado prosperen. Confiar que la aplicación solo la va a utilizar el usuario, y que va hacer un buen uso es un error de la “NO CULTURA DE LA SEGURIDAD”, y no de lo robusto que sea o no un sistema.

Esta cultura de la seguridad no es algo que tenga que aprender, comprender y aplicar solo desde los técnicos de la información, todos tenemos un dato que a otros pueden interesar, ese post-it con la contraseña de acceso al banco, el último plan de ventas para el próximo año encima de la mesa que puede leer la señora de la limpieza por las noches y fotocopiar para vendérselo a nuestro competidor…

Al final, la cadena siempre se rompe por eslabón más débil.

También es cierto que cada día somos más los que nos preocupamos por el medio ambiente. El problema del cambio climático aparece como unas 30 veces por día en los distintos medios de comunicación, conversaciones con amigos o de trabajo. Aprovechando la fuerte repercusión que esto está teniendo en la sociedad, y dado que todos queremos disfrutar de la tierra, podemos utilizarlo como excusa, para aplicar ciertas medidas Ecológicas que refuerzan nuestra política de seguridad.

Algunas políticas de seguridad de la información ecológicas, pueden ser:
- Ordenadores apagados fuera del horario de trabajo. Es que les cuesta arrancar por las mañanas. Por la lucha ecológica, diremos que los ordenadores encendidos consumen mucha energía de una forma innecesaria, y por mucho que le cueste arrancar todos los servicios y aplicaciones al comienzo de la jornada, no va a consumir más potencia de la que ya consume.
- Sesiones bloqueadas y pantallas apagadas: los usuarios tendrán configurado su puesto para que a los 5 minutos de inactividad, la cuenta quede bloqueada, a los 7 minutos el monitor se desconecta, a los 15 el monitor en modo suspendido, y a los 20 minutos, el ordenador entra en modo suspendido. De modo que si nos vamos a tomar un café, a una reunión, o nos vamos a comer, al regresar el ordenador habrá ahorrado una cantidad de energía con respecto tenerlo encendido con la cuenta bloqueada.
- Mesas limpias y destrucción del papel: ¿cuántos de nosotros acumulamos papeles, papeles y más papeles en nuestras mesas? ¿Somos conscientes de la importancia de la información existente en el papel? No imprimir aquello que no sea importante, contribuiremos a talar menos árboles. Si no nos queda otra que imprimirlo, cuándo terminemos de usarlos los guardamos en los cajones en carpetas para que quede ordenado, o la correspondiente bandeja. El proceso de reciclaje cuesta mucho menos si el papel ha sido previamente triturado, por lo que estaremos contribuyendo a reducir el consumo energético en las plantas de reciclaje, trituremos aquellos documentos que no nos sirven en lugar de hacer una bola para hacer canasta en la papelera. Por otro lado contribuiremos a una mejor imagen de nuestra compañía

Estas políticas, evidentemente no tendrían que ser publicadas en la política de seguridad de la información, tendrían que hacerse bajo el marco de Seguridad y Medio Ambiente, incluso es más fácil convencer al nuestros jefes por el tema ecológico que por el tema de la seguridad de la información.

Seguridad, cuando hablamos de Seguridad en el marco de las TI perseguimos el objetivo de proteger la información. Da igual el entorno en el que nos movamos en el momento que generamos un puñado de bits y estos son almacenados de una u otra forma en un dispositivo cualquiera, es en el momento de grabar cuando ya empieza a ser un puñado de bits que nos preocupa, si no por qué lo hemos guardado.

Desde el punto de vista de la seguridad la información la vamos protegiendo por capas, un firewall, un ids, un honey pot, otro firewal, otro ids, un antivirus, otro firewal, … un monton de tamagochis hasta que la cadena se rompe, y siempre rompe. Un buen día me llega un mail “Te quiero mucho…”, que bien alguien que me quiere… y voy y lo abro, al día siguiente mi plan de ventas para los próximos seis meses está en manos de mi competidor y yo arruinado.

Podemos poner muchas medidas técnicas, iremos hablando de ellas en los próximos días, pero nunca podemos bajar la guardía. El espionaje industrial, las mafias … se han aliado con las tecnologías y ahora es mucho mas rentable tener en nomina a unos cuantos piratas que se dedican al intrusismo y robo antes que tener a unos matones que intimiden, secuestren y maten. Imaginemos la fantástica película “El Padrino” con TI de por medio, la cabeza de caballo nunca hubiera aparecido en la cama, simplemente un buen día toda tu información, tus datos, todo lo que has construido en tu vida, ha desaparecido, te han borrado tu identidad y ya no eres nadie, nadie te conoce.

Que es lo que está ocurriendo en realidad en el mundo, atrás quedaron los días en los que aparecían un montón de virus . Pero esto no significa que ya no existan virus tan buenos o que los antivirus son la mejor medida de protección. Significa que el “lado del mal” avanza mucho más rápido que el “lado del bien” su unión para hacer daño les está llevando a conseguir mucho más, mientras que la ambición del lado del bien no nos esta llevando por el buen camino. El lado del mal está bien organizado, tienen infinitos ordenadores zoombis sin que nadie se de cuenta, los controlan y usan según sus necesidades.

La seguridad absoluta es imposible alcanzarla, al menos en este momento, pero si que nos queda la opción de reducir al máximo el peligro y el efecto de exposición.

Solo nos queda la unión, que haga la fuerza. Transmitir el conocimiento de cada uno, aprender de los demás y enseñar lo que hemos aprendido.

Microsoft también publicará una nueva versión de la herramienta Microsoft Windows Malicious Software Removal Tool (Herramienta de eliminación de software malintencionado).

Al mismo tiempo Microsoft ha lavado la cara de su página de actualizaciones, con la que ofrece ahora más detalles sobre las actualizaciones publicadas. Ahora se agrupan los boletines por criticidad y detalla qué componente del sistema operativo se ve afectado. También han añadido una extensa tabla que incluye distintas versiones de los módulos afectados y el impacto de la
vulnerabilidad en ellos según incluso versión y plataforma.

Ahora podremos, por ejemplo, con esta información que una de las vulnerabilidades críticas que serán parcheadas afecta a Internet Explorer y otra a Outlook Express y Windows Mail (cliente de correo de Windows Vista).

Más información sobre las actualizaciones en:

http://www.microsoft.com/spain/technet/security/Bulletin/ms07-may.mspx

El lanzamiento de esta tercera entrega estaba prevista para mediados del 2007, pero Microsoft dedica más esfuerzos a corregir los problemas que Windows Vista tiene por lo que es de esperar que se lancen de forma conjunta dos paquetes de actualización para cada uno de los sistemas operativos.

Esta persona estaba completamente sorprendida porque analizando los mails, el jamás había enviado ninguno de esos correos, y cual fue su sorpresa cuando intenta enviar un mail a algunos de sus clientes, y estos fueron clasificados como spam en el buzón del destinatario.

Qué estaba pasando, se preguntaba preocupado por que su trabajo se empezaba a ver afectado, cada vez dependemos más del correo electrónico, y de que su ordenador este plenamente operativo. Asustado llamó a su equipo técnico y analizaron su portátil, para llegar a la conclusión de que había sido infectado por algún maligno virus que tomo pleno control de su máquina y sin que el se diera ni cuenta enviaba mails spam a diestro y siniestro. Claro, por eso tenía los problemas que tenía estos últimos días de conexión a Internet, exclamo.

Esto que puede parecer algo hipotético de ocurrir ocurre más de lo que parece. La infección del virus, convirtió su ordenador en un ordenador zombi que estaba enviado spam con la configuración de su cuenta de correo, y el sin saberlo.

Es importante disponer de soluciones que eviten que se nos instalen este tipo de programas. Pero es un error pensar que tener un antivirus es suficiente, necesitamos que esté actualizado, y nos tenemos que preocupar de tenerle siempre activo, vigilemos su actividad.

Pero hemos de tener una serie de cuidados al igual que hacemos con otras cosas, coche, casa,.. Es importante conocer dónde están los logs del sistema operativo y que es lo que estos nos dicen, los logs de las aplicaciones que utilizamos, aunque lamentablemente no todas dejan un log de funcionamientos anómalos y actividad, pero en el caso de un antivirus si no tiene esta función descartémoslo.

También es importante aprender unas normas básicas que permitan controlar los envíos masivos de correos. Por ejemplo, si tenemos nuestra libreta de contactos en el Outlook, abramos una cuenta en hotmail, yahoo, gmail … (dónde sea) y añadámosla a la libreta de direcciones. Periódicamente vigilemos la actividad de esta cuenta y algún día descubriremos que algo nos puede estar pasando.

Como decía, somos felices y pensamos en nuestra gran fortaleza como indestructible. Pero resulta que, por poner un ejemplo, la gran mayoría de las instalaciones utilizan Internet Explorer sobre un sistema operativo llamado Windows XP o Vista, por no nombrar versiones muy antiguas que podrían causar daños mayores. Tanto este software, como cualquier otro software que sea utilizado en nuestros sistemas por no focalizar el post en uno solo, ha sido desarrollado por un equipo de personas y, por culpa de una casuística no contemplada, se produce un mal comportamiento en el resto del Sistema Operativo, y desde ese momento la máquina puede quedar a merced de quien sepa explotarla.

Cuando esto sucede, nuestra felicidad se termino y nuestra fortaleza se vio derrumbada por la rendija más pequeña. Nos podemos fijar en la última actualización de Microsoft sobre Internet Explorer, MS-027, dónde las 5 vulnerabilidades detectadas, que mientras no se actualice, abrirán una puerta al atacante permitiéndole hacer lo que le de la gana en nuestra máquina, y desde aquí acceso total a toda nuestra información.

Insistir que no pretendo criticar a Microsoft, es solo un ejemplo de lo que ocurre en el mundo del desarrollo. Los plazos, los costes, los recursos, la falta de definición… son factores que hacen mermar la calidad de la fabricación de un software y que hacen que tengamos que sufrir actualizaciones, que son necesarias realizar.

Pero el problema se acentúa más cuando decidimos realizar el desarrollo desde nuestra empresa, liderando el proyecto por los técnicos que hemos contratado y sacando a concurso el proyecto entre varias empresas de desarrollo. Se ha de vigilar la seguridad, establecer un periodo de garantía al desarrollo entregado y establecer un segundo periodo de actualización frente a errores de seguridad, al tiempo que exigimos a nuestros proveedores que cumplan con un desarrollo seguro contemplado en los LSA que les obligue al cumplimiento del mismo. Esto no nos evitará incidentes de seguridad ya que siempre puede existir algún factor que haga que nuestro sistema se vea vulnerado, pero si que los mitigará y reducirá las perdidas que un agujero de puede ocasionarnos.

En esta ocasión y como reza el título del post, se trata de la actualización de Mayo 2007 que Microsoft lanza en este mes:

• Boletín MS07-023: Crítica (Excel)
• Boletín MS07-024: Crítica (Word)
• Boletín MS07-025: Crítica (Microsoft Office)
• Boletín MS07-026: Crítica (Microsoft Exchange)
• Boletín MS07-027: Crítica (Internet Explorer)
• Boletín MS07-028: Crítica (CAPICOM)
• Boletín MS07-029: Crítica (interfaz RPC del DNS)

Entre todas estas actualizaciones, destacar la MS07-27 referente a una actualización acumulativa para Internet Explorer en sus versiones 5.01, 6 y 7. Los problemas que se corrigen en esta ocasión son:

• Primero: un problema en la forma en la que Internet Explorer instancia objetos COM que no fueron diseñados para ser instanciados desde este. Un atacante puede aprovechar esto para ejecutar código arbitrario en la máquina de la víctima si esta visita una página web maliciosa especialmente construida a tal efecto.
• Segundo: se debe a la forma en la que Internet Explorer accede a objetos cuando no han sido aún inicializados o han sido borrados. Un atacante puede explotar esto construyendo una página web maliciosa que, una vez visitada por la víctima, pudiera provocar la ejecución de código arbitrario en el sistema de la misma.
• Tercera: se debe a la forma en la que Internet Explorer trata un método de propiedad. Se podría crear una página maliciosa que, una vez visitada por la víctima, consiguiéramos provocar la ejecución de código arbitrario en el sistema de la misma.
• Cuarta: es una serie de problemas de Internet Explorer a la hora de acceder a memoria sin inicializar en ciertas situaciones. Con un ataque se puede crear una página maliciosa que, una vez visitada por la víctima, provocará la ejecución de código arbitrario en el sistema de la misma.
• Quinta: también se ha corregido un problema en un componente de servicio de medios que no era soportado por Internet Explorer. Un atacante puede crear una página maliciosa que, una vez visitada por la víctima, provocará la ejecución de código arbitrario en el sistema de la misma.

La recomendación que puedo hacer, es la de actualizar puntualmente con los parches oficiales publicados por el fabricante de Software, que en esta ocasión es Microsoft, con el único objetivo de poder mantener asegurada una máquina y la información que en esta guardamos.

En los entornos empresariales, esto puede suponer un problema, pero en el mercado existen soluciones que permiten controlar la distribución de las actualizaciones del software después de una correcta comprobación por parte del departamento de Sistemas. Si la compañía no cuenta con tiempo, dinero y recursos para realizarlo de está forma, confié en el fabricante y actualice, no tiene por que suceder nada en el sistema ya que todas estas actualizaciones pasan férreas pruebas de calidad para evitar romper algo que funciona.