Visualizando los datos de localización que Apple graba de ti en tu iPhone

Parece que la gente anda un poco escamada con Apple por el hecho de que se tenían callada una funcionalidad especial de los iPhone. Resulta que en los iPhone hay un ficherito (Library/Caches/locationd/consolidated.db) que guarda todo el historial de tus movimientos siempre y cuando tengas los servicios de GPS y localización activados.

Dos desarrolladores, Alasdair Allan y Peter Warden descubrieron este hecho por casualidad. Estaban realizando varios proyectos de visualización de datos, por ejemplo para The Guardian mostrando los niveles de radiación en la central de Fukushima y se les ocurrió que sería interesante el mostrar datos de dispositivos móviles. Fue así como llegaron al dispositivo en cuestión.

A los malos les gusta Java

Los que llevamos ya algún tiempo en esto nos acordamos de la época en la que Java no existía en los ordenadores personales. Era la época en la que en los foros se comentaba: "Para que Java triunfe tiene que ir incluido en el sistema operativo", o "Para que java triunfe el JRE tiene que poder descargarse rápidamente".

En mi opinión Java nunca ha triunfado realmente en el escritorio. Son pocas las aplicaciones de usuario basadas en Java, aunque lo cierto es que ahora mismo son pocas las aplicaciones de escritorio basadas en cualquier lenguaje. Quizás la aplicación que más haya contribuido a la instalación de Java haya sido JDownloader, al menos en España segurísimo. Bueno, y de los Applets ya mejor ni hablamos, y eso que en 2008 parecía que podían volver, y en 2007 ThinkFree daba caña, pero nada amigos, kk de la vaca, como Java FX.

Documentos sobre seguridad de Microsoft

A todos los que os interese el tema de la seguridad quizás os interese saber que desde Noviembre, Microsoft ha comenzado a publicar una serie de documentos de referencia relacionados con la seguridad en entornos web.

Estos documentos describen diferentes vulnerabilidades e intentan presentarlas de forma que puedan ser comprendidos por personas situadas en diferentes puestos de trabajo: desde el tomador de decisiones al tester pasando por arquitectos y desarrolladores. En el momento de la publicación de este post hay tres documentos disponibles:

El servidor más seguro del mundo está en Los Alpes

O eso dice su dueño. Le llaman el Fort Knox Suizo y se encuentra emplazado en lo que antaño era un refugio nuclear en el los Alpes suizos.

El centro de datos está formado por dos bunkers independientes situados bajo tierra, en el corazón de la montaña, y unidos por un túnel subterráneo de 10 kilómetros de largo. La compañía que diseñó el refugio de datos ha aprovechado además los recursos de la montaña y la peculiar situación para refrigerar los servidores de manera natural. Así, todo el sistema de refrigerado se abastece de agua que proviene de un lago glaciar subterráneo.

El lugar para emplazar el refugio quizás no esté tan pensado, ya que como comentan en Wired, que publicó este mes un reportaje sobre tan peculiar lugar, en el valle cercano a la montaña se encuentra la mayor concentración de billonarios de todo el planeta, y aquí estoy especulando, quizás guarden más que datos en sus cajas acorazadas.

El refugio que tuvo un coste de construcción de alrededor de los 30 millones de euros, contiene lo último de lo último en cuanto a seguridad, reconocimiento facial, plásticos anti-bala, filtros de aire militares capaces de filtrar impurezas atómicas y químicas, hotel de emergencia y cámaras acorazadas cortesía de bancos suizos. Y por supuesto su funcionalidad más deseada es la que proviene de su uso original, puede sobrevivir a un ataque nuclear.





Si queréis conocer más sobre esta bestia de la seguridad os recomiendo ver el artículo de wired.

Gráfica del fraude de tarjetas de crédito este año en USA

En Bank Info Security han publicado una gráfica muy interesante sobre los fraudes más importantes que se han llevado a cabo durante lo que va de año dentro de los Estados Unidos.

Para nosotros, en Europa, no es demasiado relevante pero si pasáis el ratón por la gráfica podréis ver la descripción de todos estos casos y se puede apreciar que es algo que nos puede pasar a cualquier de nosotros en cualquier lugar. ¡Da miedo!

Como exponer 100.000 passwords de tus clientes y quedarte tan ancho

Ayer, Abe Voelker hacía públicos varios fallos de seguridad muy graves en las web Progress Software (los que compraron IONA en el 2008). Se trata de fallos muy básicos que exponena públicamente los datos personales, incluyendo las contraseñas, de más de 96.000 clientes. Casi nada.

No voy a entrar en detalle en como acceder a esos datos, ya que todo está explicado en el blog de Abe, y el que quiera puede probar. Pero si os paráis a leer en detalle el artículo, veréis que son realmente conceptos tan simples que uno se pregunta si ha habido algún tipo de revisión de código. Me imagino que los programadores serían inexpertos, más razón para revisar el código. Si ese era el caso es una gran falta de responsabilidad del responsable del proyecto. Si ha sido por desidia, la responsabilidad es doble, del autor y de su superior.


El primero de los ataques, porque vaya es que no sé ni si se pueden definir como ataques, es el acceder a una URL de mantenimiento de perfil, que no se encuentran protegidas. Si ahí pones el nombre del usuario de cualquier persona que haya solicitado alguna mejora en el software de Progress, verás todos sus datos.

La contraseña aparece con asteriscos, pero que no os engañe, es simplemente el campo HTML, si vamos al código fuente el password está en texto plano.

El segundo ataque ya no funcionaba a la hora de escribir esto. Quizás hayan borrado el CGI, o quizás sea simplemente un error tipográfico y se pueda todavía acceder a la información, lo cierto es que no lo he intentado. Pero era más de lo mismo salvo que se exponía toda la información en texto plano en formato XML. Alguno podrá decir, "pero es que hay que conocer los login de todos los usuarios". Nada demasiado complicado cuando tienes una People Community Search. Cualquiera podría hacer un bucle y conseguir las contraseñas de todo el mundo.

Otra curiosidad es que parece ser que las únicas contraseñas que estaban en texto plano eran las de sus usuarios y clientes. Las contraseñas de sus empleados estaban encriptadas, eso sí en SHA1 sin salt. Bueno, pero algo es algo si lo comparamos con la información de los clientes. Supongo que les costaba mucho el reutilizar el código.

El otro día casualmente comentaba con un cliente lo importante que es no utilizar las mismas contraseñas en los diferentes servicios. El me comentaba que siempre utilizaba la misma, y tampoco veía demasiado peligro en ello. Puede que no, a mi tampoco me importa demasiado que me hackeen mi cuenta de Facebook. Pero si ya entran en mi cuenta de Paypal, entonces sí que me puede hacer más pupa :-)

Sobre captchas, tickets y conciertos

Han pasado casi cinco meses desde mi último post, y la verdad es que hoy me he pasado por el blog y me he sorprendido al ver 990 lectores por Feedburner. Evidentemente, la mayoría de estos lectores son como yo, no leen los feeds a los que están suscritos, pero vaya que me ha hecho pensar "pero que coño estoy haciendo que estoy abandonando este blog en el que tanto trabajo he puesto". Así que he hecho el propósito de poco a poco ir retomando la actividad. A ver cuanto dura :)

Y empiezo con un tema que hace tiempo que había visto y me había entusiasmado. Últimamente no sé que pasa pero me he vuelto un apasionado de todo lo relativo a los cibercrímenes. Así que quizás tenga nueva temática para el blog. Este tema lo recordé gracias a un gran y muy educativo artículo de José Manuel Alarcón llamado reCaptcha, mucho más de lo que ves a simple vista, y en el que explica muy detalladamente como funcionan los Captchas y por qué hay tanta gente deseando romperlos. Si sois de los que piensan que son simplemente dos palabrejas que hay que meter de vez en cuando para ver si somos robots o no, echarle un vistazo porque veréis que hay mucho más.

La verdad es que a mi lo que más me gusta es la parte oscura :-) Pero voy al tema. Creo que todavía estaba en Irlanda cuando leyendo el Metro había visto que habían detenido a una banda que se dedicaba a saltarse Captchas para comprar tickets de conciertos. Recuerdo que me sorprendió porque me pareció la caña. Pues bien, hace tan sólo unos días leía que ese caso será definitivamente juzgado en Marzo, ya que hasta ahora se encontraba en un laberinto legal, pero definitivamente una juez de Nueva Jersey ha decidido proceder al juicio donde se busca condenar a esta banda por fraude electrónico y diversos abusos contra una ley de Anti Hacking o algo así :)

Podéis ver la historia completa en Wired que a mi me ha parecido apasionante. Nada más y nada menos que 25 millones de dólares en beneficios ha hecho esta gente, en siete años de nada. Para ello contrataban bloques de IPs y varias redes de ordenadores remotos que lanzaban contra webs como Ticketmaster en los momentos en los que comenzaban las subastas más interesantes, haciéndose con grandes cantidades de tickets. Algunos datos del juicio son impresionantes. Por ejemplo en el 2006 consiguieron comprar 882 de los 1000 tickets disponibles para la Rose Bowl (título de futbol americano universitario) o en 2007 que compraron 1924 tickets para los playoffs de los Yankees.

Pero lo mejor fue cuando Ticketmaster se dio cuenta de que algo no iba bien y cambió el algoritmo a utilizar Re-Captcha. Entonces la banda decidió crear bots para descargarse todos los captchas, que están identificados por ids, y creó una enorme base de datos de cientos de miles de Captchas asociados con sus respectivas ids. Bueno, ya sabéis para que sirven estos trabajos que se anuncian por correo "Trabaja desde casa. Gran sueldo. No se requieren ningunos estudios!", o quizás simplemente contrataran personas al kilo para leer captchas. También parece que configuraron su red de bots para que cometieran fallos a posta para evitar ser cazados por los filtros anti-fraude de las casas de tickets.

Pero la red iba todavía más allá. Ellos ya no eran ni siquiera los que vendían los tickets. Ejercían de intermediario. Había una red completa de brokers de tickets, usease reventas, que les proporcionaban sus datos y su tarjeta de crédito a la red, y la banda lanzaba sus ordenadores garantizándoles la compra, entiendo que por su correspondiente márgen. La leche, vamos.

No sé si vosotros os podíais imaginar que los Captchas daban para tanto pero a mi todo esto me parece de película :-)

OWASP Podcasts y entrevista el manager de desarrollo seguro de Paypal

De OWASP ya he escrito en otras ocasiones. Es una asociación para la promoción de la seguridad en la red que no conocía, y con la que tuve contacto por primera vez en Irlanda, aunque tienen también su capítulo en España.

Una de las cosas que empezaron a finales del año pasado y que han desarrollado bastante este año es la publicación de un Podcast sobre seguridad bastante imprescindible para el que le interese estos temas. A mi personalmente muchos de los temas ahí ya se me quedan un poco grandes, sin embargo sí que me llamó un poco más la atención un podcast de hace unas semanas en el que hacían una entrevista a Andy Steingruebl (PayPal Secure Development Manager).

En el Podcast Andy comanta su experiencia en Paypal y realiza una serie de recomendaciones. He recogido unas cuantas notas del podcast que tenía pendientes de publicar y que pongo a continuación:

• CSRF y Cross-site Scripting son los problemas más grandes en la actualidad. Cosas como SQL Injection todavía están muy presentes pero existe más educación sobre ellas y las soluciones son mucho más conocidas.
• Una vez establecidos unos protocolos de acción y una buena metodología de trabajo los costes de hacer desarrollo de software seguro e inseguro no se diferencian tanto. Hay montones de librerías y utilidades disponibles en la red. El coste está más en conseguir la disciplina y la mentalidad en una organización para que se apliquen prácticas de desarrollo seguras.
• Aplicar técnicas de desarrollo seguro en metodologías ágiles es más complicado ya que se centran siempre en pequeñas ventañas de funcionalidades. Es posible, pero es más complicado que con metodologías adhoc.
  
  (sinceramente, aquí no le vi sentido a esto. Estoy bastante en desacuerdo. Me imagino que el problema es más de adaptar una gran empresa como Paypal y todos sus planes que tienen que realizar para auditorías de seguridad a las metodologías ágiles que otra cosa.)
• No reinventar la rueda. Reutilizar frameworks de seguridad.
• Aunque los IDEs incluyen herramientas de análisis estático todavía hay mercado para esas herramientas. Hay muchas compañías pagando por herramientas específicas para el análisis estático de código.
• Alguién sugería la necesidad de 150.000 profesionales del software. Andy se muestra en desacuerdo y opta más por la formación y aprendizaje como la solución. Educar a los desarrolladores e incluso incluir nociones de seguridad en la formación universitaria. Los desarrolladores no necesitan ser expertos en seguridad, pero sí que deberían tener conocimientos básicos sobre los ataques más comunes y sus soluciones, así como conocimientos de que herramientas y librerías utilizar para prevenir estos ataques.
• PCI no es una mala certificación ya que al menos fuerza a las personas a tomar algunas medidas de seguridad. Aún así, eso debería salir directamente de las empresas y no ser medidas encaminadas únicamente a pasar la auditoría.

Volviendo al tema del agilismo, el podcast en sí está bien pero la parte de que las metodologías ágiles hacían más difícil el desarrollo seguro no tiene ni pies ni cabeza.

Google publica un libro para desarrolladores sobre seguridad en navegadores web

Últimamente Google ha estado cogiendo algo de mala fama por reusar contenido libre, atacar todos los frentes posibles, pero no devolver nada a la comunidad. Pues bueno me entero via ReadWriteWeb de que acaban de publicar un libro titulado Browser Security Handbook bajo licencia Creative Commons 3.0.

El autor del libro es Michael Zalewski y su contenido está principalmente orientado hacia desarrolladores web. El libro consta de tres partes, la primera comenta los fundamentos de los navegadores web en cuanto a gestión de URLs, soporte de JavaScript, CSS, ett. La segunda parte trata sobre la seguridad en los navegadores web y procede a comentar diferentes mecanismos y los compara para diferentes navegadores; por último, la tercera parte comenta algunos sistemas experimentales de seguridad y características especificas de algunos navegadores web como Internet Explorer o Mozilla.

Parece un libro a tener en cuenta. Si os interesa el tema, y no lo habéis hecho ya, pasaros también por mis posts sobre OWASP que contienen entradas con información similar.

Un par de presentaciones sobre seguridad

Hace unos días OWASP y del evento que habían hecho en Dublín.

Pues bien, uno de mis actuales compañeros de trabajo, David Rook, que casualmente era una de las personas que exponía en dichas presentaciones ha sido lo suficientemente avispado como para localizar mi blog. Por supuesto, le llamo la atención que su nombre apareciese en una de las entradas, y presto se apresuró a traducirlo.

Después de comprobar que no decía nada malo de él, algo que es importante jejeje, ha sido tan amable de dejarme voluntariamente las transparencias de las charlas para que las subiera aquí por si a alguien le interesa. He creado un grupo en google para subir los ficheros. Aquí os los dejo:

Cross Site Request Forgery Javascript Malware de Eoin Keary.
I'm a developer get me out of here – Application Security and PCI DSS por David Rook.

Edit: Si no os funcionan los enlaces, simplemente entrad en el grupo y los podréis descargar.

Gracias a David por los ficheros.

OWASP su API de seguridad ESAPI y tarjetas de crédito

A principios de este mes hablaba sobre OWASP y la charla que iban a hacer en Dublin. El pasado Martes pude ir a la charla y la verdad es que fue bastante interesante.

En la primera, Eoin Keary de Ernst & Young habló sobre ESAPI, una librería Java llena de utilidades relacionadas con la seguridad en las aplicaciones web y que está avalada por OWASP. Echándole un vistazo a su javadoc, se pueden contrar clases realmente interesantes como sus HttpUtilities que define montones de métodos para realizar acciones como encriptar cookies, encriptar query strings, codificar las URLs de manera segura, etc. Otras clases como Encryptor o Randomizer se apoyan sobre JCE para facilitar el encriptar, desencriptar o generar semillas seguras. En fin, hay un montón de clases así que echarles un vistazo vosotros mismos o pasaros por la página del proyecto en Google code donde hay documentación y alguna presentación.

Respecto a si utilizar la librería o no, a pesar de que el autor recomendaba el usarla a toda costa, yo sería más partidario de reutilizar métodos, ya que al final, ya existen librerías muy establecidas como Acegi que se integran muy bien con los servidores web y servidores de aplicaciones disponibles ahora mismo, así que desde mi opinión el ignorar esto sería un poco un paso atrás. Pero ESAPI sí que me parece un lugar muy bueno para obtener patrones, código de ejemplo o simplemente métodos de utilidad para mejorar la seguridad de nuestras aplicaciones. Así que habrá que aprovechar que es Open Source.

La segunda charla fue la de David Rook, que trabaja en mi empresa actual, y que fue realmente buena. David hablaba de PCI (Payments Card Industry) y de si el tener las certificaciones que las empresas que trabajan en el mundo de las compras con tarjeta de crédito necesitan cumplir implican que esas empresas son seguras. Es decir, ¿son equivalentes el pasar una certificación de seguridad y el ser seguro?

David expuso claramente sus puntos de vista, y con los que estoy totalmente de acuerdo, y que vienen claramente a decir que no, es decir, el que te firmen un papel conforme cumples unas reglas generales bastante básicas no implica que seas una empresa segura. Para ello puso varios ejemplos de empresas que habían pasado las certificaciones exigidas por la PCI y que sin embargo habían sufrido graves ataques de seguridad.

Fue especialmente interesante el caso de TJ Maxx en el que aunque VISA sabía que esta empresa no podría cumplir los requisitos exigidos por la PCI, le dio una próloga para seguir operando hasta el 2008 ya qu eel volumen de transacciones de estos grandes almacenes significaban muchísimo dinero, y al final hicieron la vista gorda. Aún así, a pesar de perder 100 millones de tarjetas de crédito (que no está nada mal) resulta que las acciones de la compañía han seguido subiendo sin problemas, lo que genera las cuestiones de ¿Realmente nos importa al usuario de a pie este tipo de brechas de seguridad? ¿Volveríamos a comprar en una tienda a la que le roban nuestro número de tarjeta de crédito? ¿Cambiaríamos nuestra visa por una mastercard si nos pasa esto? Todas son preguntas realmente interesantes y que generaron un buen debate en las preguntas y respuestas.

Pues nada, recomendar a todo el mundo que lee esto que se pase por la web de OWASP porque realmente tienen contenido muy interesante. Por cierto, que los libros que publican se pueden descargar gratuitamente desde Lulu. Los podéis encontrar este enlace.

OWASP Top 10 2007 y reuniones en Dublin

Uno de mis nuevos compañeros de trabajo es contribuidor de OWASP, que es una comunidad abierta centrada en el estudio de la seguridad en el software. Su página web está llena de contenidos super interesantes, y entre las cosas que han venido haciendo estos años está la publicación de un informe con las 10 amenazas más importantes para las aplicaciones web.

La última versión del informe es la del año pasado: OWASP Top 10 2007 (PDF). Aunque muchos estaréis familiarizados con las diferentes amenazas, no está nunca demás el repasarse el documento de unas treinta y pico páginas y de lectura bastante amena. Resumiendo, las amenazas son:

1. Cross Site Scripting (XSS)


2. Injection flaws


3. Malicious File Execution


4. Insecure Direct Object Reference


5. Cross-Site Request Forgery


6. Information Leakage and improper Error Handling


7. Broken Authentication and Session Management


8. Insecure Cryptographic Storage


9. Insecure Communications


10. Failure to Restrict URL access

El informe explica cada una de estas amenazas, a que se deben, y ofrece consejos para corregir estos errores y defenderse de ataques potenciales en diferentes lenguajes.

Por otra parte, la gente de OWASP en Irlanda realiza eventualmente algunas reuniones en el edificio de Ernst & Young en Harcourt Street (en frente al Odeon), por si alguien se anima a pasarse por ahí. La próxima, si no me equivoco es el 21 de Abril. Y yo me intentaré pasar por ahí.

Transparencia ante ataques de seguridad

Ayer se me ocurrió entrar en el blog de la compañía con la que recientemente he contratado un servidor virtual. Esto de los blogs está ya tan extendido que en muchas compañías ya es práctica habitual. Nada más entrar me topo con esto:

A very important update for everyone! It appears that earlier today a third party gained access to our mywebpayment.com billing system. Upon determining that there might be a security breach we immediately terminated the access to everyone by disabling the billing website. At this time we’re still uncertain as to the total scope of the data they accessed. We are going to be as transparent as possible about what happened, what our plans are to correct it, and also how we plan to make sure that this never happens again.

Ups. Nudo en la garganta. La nota sigue:

To start with it appears that the breach was made through some malware/spyware installed on an employee’s office computer. His username and password for the billing system were stored in a document unencrypted on his computer. This information was used to access parts of our billing system that, in retrospect, should have been protected better.

Esos programas que nos descargamos por ahí...

We are certain that credit card numbers were not exposed, however we do know that a limited number of email addresses and plain text passwords were exposed. We highly recommend that if your PayPal password was the same as your Spry password that you immediately change it. While no paypal passwords are ever provided to us, it is likely that many users have chosen the same password for their paypal account and their account at Spry...

Vale. Yo he pagado con Paypal y mi password es diferente, así que aparentemente estoy a salvo, o eso espero.

El caso es que me ha llamado la atención que el ataque haya sido expuesto de forma tan abierta. Por mi parte un diez para ellos por hacer públicos este tipo de ataques, ya que a fin de cuentas seguro que nos ibamos a enterar por otros medios. Siempre es mejor ir con la verdad por delante. De este modo futuros clientes saben que en caso de haber algún problema se sabrá por el blog de la empresa. Ahora bien, tirón de orejas porque el blog no ha sustituido al email, al menos que yo sepa, y no me ha llegado ningún tipo de notificación al correo electrónico.

Quizás es que quieren aumentar las visitas de su blog :)

Sobre feeds y la protección de contenidos

Hoy, no recuerdo bien como he llegado a un producto que me ha llamado la atención. Se trata de Attributor un producto que rastrea Internet buscando violaciones de contenido, es decir, sitios que agregan directamente tus feeds buscando sacar un beneficio monetario, personas que copian tus artículos y los publican como si los hubieran hecho ellos, videos o imágenes utilizados sin permiso, y todo este tipo de cosas.

Evidentemente todos queremos proteger nuestros contenidos, especialmente si nos ha costado bastante trabajo el generarlos. Por cierto, que esto me recuerda una anécdota en la que un amigo me alertó de que alguien había publicado un artículo en la revista de una empresa bastante importante muy parecido a un artículo que publicamos yo y Alberto hace ya demasiado tiempo (por cierto, fenomenal cambio de look en jh, pero es una pena que mucho del contenido antiguo se haya perdido). Investigando un poco me encontré que esta persona había copiado y pegado literalmente partes del artículo montando un collage al que le había puesto su nombre.

Pereo en fin, eso es otra historia. El caso es que al leer en este producto que Reuters parece que lo va a utilizar me ha recordado lo sensibles que son estas compañías con sus servicios y las oportunidades de negocio que pueden surgir en torno a ello.

Más concretamente, en las últimas semanas he comprobado en mi propia piel las pocas facilidades que te ofrecen estas compañías a la hora de proporcionarte acceso al contenido que generan. Uno que es inocente al principio piensa, "nada, acceso por RSS y listo". Pues no. Cualquier cosa menos soluciones sencillas: autenticación, bloqueo de IPs que puedan acceder al contenido, construcción de proxies para desplegar el contenido utilizando un API propietaria que prevenga el convertirse en hub de la información de estas compañías.

Más o menos eso ha sido con lo que me he encontrado estas últimas semanas, y la verdad es que parece que hay por ahí un hueco en el mercado, o al menos dentro de los feeds para mercados financieros en los que es realmente importante el ser el primero en obtener la información para obtener una ventaja competitiva. La mayor parte de servidores de feeds disponibles del mercado parten de un supuesto "optimista" que es que "todo el contenido es público", así que podría haber por ahí un hueco para un servidor seguro, con encriptación, certificados, firmas, autenticación, APIs, bloqueos, etc. Me da la impresiónás de alguna compañía estaría seguramente interesada, tanto proveedores de noticias como clientes de estos proveedores.

Ahí queda la idea por si alguien se anima :-) , aunque quizás ya conozcáis algún producto similar....