Java después de veinte años

Libro Java El año pasado Java cumplía 20 años. Por ese motivo se publicaba Java at 20: How it changed programming forever donde se hace un resumen de sus ventajas más notables.

Según el autor, su principal fortaleza consistiría en ser una herramienta para tener el trabajo hecho:

But Java’s core strength was that it was built to be a practical tool for getting work done. It popularized good ideas from earlier languages by repackaging them in a format that was familiar to the average C coder, though (unlike C++ and Objective-C) Java was not a strict superset of C. Indeed it was precisely this willingness to not only add but also remove features that made Java so much simpler and easier to learn than other object-oriented C descendants.

Habla sobre el problema de los ‘applets’ (casi en fase de certificación oficial de su muerte, en estos momentos):

The irony is that applets never worked very well. They were completely isolated from the content on the page, unable to read or write HTML as JavaScript eventually could. Security constraints prevented applets from interacting with the local file system and third-party network servers. These restrictions made applets suitable for little more than simple games and animations.

Por completar, traigo un elogio del Java hecho por un desarrollador de Python que se autocalifica como converso: Why Java? Tales from a Python Convert que destaca la máquina virtual, las bibliotecas, la robustez de los tipos de datos y la concurrencia. También habla de las construcciones más modernas. Nos ha recordado aquella serie de la que hablábamos en Motivos por los que debería gustarnos Java donde se daba un buen repaso a las principales características de Java.

Explicación de los principales algoritmos de minería de datos

Puente colgante Antes del ‘big data’ se hablaba de minería de datos (‘data mining’) como precursora (y con intersección no vacía) me resultó interesante Top 10 data mining algorithms in plain English donde justamente describen eso: los algoritmos de minería de datos más importantes descritos de una forma más o menos sencilla.

Puede ser de interés para alguien que quiera tener una idea de las posibilidades, o como recordatorio para los que ya las hayan olvidado. De paso, aprendemos un poco de terminología general.

Es difícil identificar los correos de phishing correctamente

Phishing El phishing es una técnica que utilizan los estafadores para robar información personal: se envía un correo electrónico que parece provenir de alguna entidad en la que confiamos y que nos invita a pinchar en un enlace. En el sitio de destino (que no es el que se supone que debería) se nos solicitan datos que confiadamente proporcionaremos.

Sobre este tema, tengo un par de teorías:

  • Los sitios de redes sociales han destruido cualquier tipo de posibilidad de que sigamos sosteniendo ante los usuarios aquello de que no pinchen en los mensajes de correos. Sistemáticamente recibimos mensajes invitándonos a realizar acciones, y pichar enlaces; como usuarios es lo habitual. Eso hará difícil frenar a los de marquetin de nuestra empresa para tratar de hacer cosas parecidas.
  • Para la mayoría de usuarios no es necesario hacer grandes montajes ni sitios que se parezcan mucho a los legítimos: hemos visto frecuentemente burdas páginas de solicitud de credenciales construidas con formularios de Google Docs (y otros sitios) sin ningún tipo de personalización, lo que parece indicar que muchos usuarios no son nada precavidos (por decirlo suavemente).

En Can you correctly identify phishing emails? nons hablan sobre un experimento de Intel que mostraba diez mensajes de correo y preguntaba a los usuarios cuáles eran legítimos y cuáles no:

An Intel Security quiz presented ten emails and asked respondents to identify which of the emails were phishing attempts designed to steal personal information and which were legitimate.

El resultado es bastante decepcionante porque sólo un 3% de los que respondieron fueron capaces de identificar correctamente todos los mensajes y el 80% de los que respondieron identificaron incorrectamente al menos uno de los correos de phishing como válido.

Habría que añadir que eso no es un problema en sí mismo, porque además de pinchar tenemos que seguir engañados a la hora de proporcionar nuestros datos y allí todavía podemos estar atentos. Aunque es cierto que en algunos casos, el hecho de pinchar en el enlace ya podría tener consecuencias desagradables:

In some cases, just clicking the link provided in the email will automatically download malware onto the user’s device. Once the malware is installed, hackers can easily steal the victim’s information without their knowledge.

Hay que estar atentos.

.es, la web anticuada

Respuesta servidor Una de las formas que tenemos hoy en día de averiguar como es el mundo es preguntando a la web. Se trata de desargar y analizar la información (meta-información) disponible en internet que nos puede dar pistas sobre las organizaciones en distintos ámbitos. De ello hablábamos el otro día en Alguien puede estar tratando de conocerte mejor pero hemos hablado más veces antes: demoscopía.

Hoy vamos a hablar un poquito de los servidores web en los dominios .es. En Análisis de servidores web en dominios “.es” (I) Luis Martín lanzaba un análisis a los servidores web de los dominios .es para determinar qué servidores se estaban utilizando, versiones, sistemas operativos y esas cosas. La conclusión es que el servidor mayoritario es Apache, seguido del IIS. En ambos casos, versiones no muy recientes:

Apaches con más de un año de antigüedad: 109715. Apaches con menos de un año de antigüedad: 37714.

Y también:

8799 dominios usarian IIS actualizados. 105926 usan IIS antiguos y potencialmente vulnerables.

Naturalmente, dada la naturaleza de estos datos esto no significa que todos sean vulnerables (incluso podrían estar proporcionandodatos falsos). Pero muy buena impresión no da.

El análisis continuaba con Análisis de servidores web en dominios “.es” (II), donde se analizan los lenguajes y sistemas de gestión de contenidos utilizados en estas páginas web. Los más populares parecen ser PHP y ASP.NET.

Nuevamente no parece que la actualización sea una de las prioridades de la web española.

Insisto, no hay que tomar como palabra de ley estos datos, pero a mi me dejan un poco preocupado, la verdad:

Hemos de tener en cuenta que este estudio ha sido realizado de manera muy superficial, cuidando hasta el extremo el potencial impacto y siendo lo menos agresivos posible. Toda la información obtenida está “ahí fuera” sin necesidad de “rascar”, disponible para todo el mundo incluidos aquellos sin buenas intenciones. Seguramente un enfoque más profundo (sin necesidad de ser agresivo) proporcionaría mucha más información del estado actual de servicios Joomla!, WordPress, IIS o Apache.

DevOps y seguridad

Libros de seguridad En Building Security Into DevOps: Security Integration Points hay una introducción al tema, que podemos completar con Putting Security Into DevOps.

Se hace un análisis inicial de esta forma de enfrentarse a los proyectos para después pasar a comentar las implicaciones y consecuencias desde el punto de vista de la seguridad (diseño/arquitectura, despliegue, modelo de amenazas, automatización, pruebas …). Y también las herramientas de seguridad como son el análisis estático, dinámico, fuzzing, revisión de código…

Control de versiones desde Python

Pantalla y fichas Aunque el sistema de filtros que introdujimos en Añadiendo filtros de correo a mi sistema con sievelib ha seguido evolucionando con varias características hoy quería traer aquí una que me preocupaba un poco: si vamos añadiendo reglas es bastante probable que en algún momento nos equivoquemos y añadamos alguna errónea. Como además estamos utilizando un sistema que controla los filtros también podría ocurrir que una actualización sobre-escriba las reglas que hayamos creado. La solución adoptada era guardar la historia de los cambios. Pero queríamos ir un poco más allá: ¿tendría sentido gestionar el histórico con un sistema de control de versiones? ¿Sería posible hacerlo?

Buscando encontramos GitPython que nos proporcionaba una interfaz adecuada para lo que estábamos plateando. El código completo en su estado actual se puede ver en addToSieve.py y nos vamos a dedicar a su parte final. Aviso: el resto del código no está muy bien organizado pero funciona razonablemente bien en mi día a día.

Hay que declarar el módulo:

from git import Repo

Al final, cuando ya hemos actualizado las reglas las pasamos al sistema de control de versiones. Instanciamos un repositorio con nuestro directorio de copias de seguridad. repoDir es una cadena de texto que contiene el directorio de trabajo (en mi caso es ~/Documents/config donde guardo varias configuraciones con control de versiones).

	repo = Repo(repoDir)
	index = repo.index

Elegimos el fichero de reglas que acabamos de grabar, lo almacenamos en el fichero que estamos utilizando (en mi caso se llama sogo.sieve, añadimos todos los ficheros del directorio al repositorio y hacemos el commit (con el nombre y la fecha como mensaje):

	
	sieveFile=c.getscript('sogo')
	file=open(repoDir+repoFile,'w')
	file.write(sieveFile)
	file.close()
	index.add(['*'])
	index.commit(name+'sogo')

Finalmente borraremos del servidor algunos filtros almacenados, dejando los últimos cinco nada más. No se hace el push dentro del programa para evitar el tener que teclear otra contraseña y no parece necesario.

Buscando otros proyectos he visto que en history.py hacen algo parecido en un programa de gestión de contraseñas que estoy probando, passpie.

Programando discos SSDs

Viejo disco duro Tenemos un poco descuidada la parte de programación de esta bitácora. Espero poner algo de código en los próximos días pero eso cuesta más tiempo y no es algo que fluya libremente en estos tiempos.

El caso es que lei la primera parte de Coding for SSDs – Part 1: Introduction and Table of Contents y me resultó interesante. La guardé, en parte para ponerla aquí, y en parte para leer el resto de capítulos (aquí estoy reconociendo que sólo he leído el primero). La programación a bajo nivel no es lo mío, pero siempre es bueno tener una idea sobre estas cosas.

Un fallo viejo en máquinas virtuales

Bicho Los fallos que viven y sobreviven a múltiples actualizaciones y cambios terminarán teniendo su propia categoría por aquí. No hace mucho leíamos 11-year-old VM escape bug opens host machines to compromise y lo traemos aquí a título de inventario.

“The VENOM vulnerability has existed since 2004, when the virtual Floppy Disk Controller was first added to the QEMU codebase,” the researchers shared. If you’re wondering why it is still added to new virtual machines by default, it’s because it’s still occasionally used in a number of situations.

No hay mucho más que decir. Siguiendo la moda, el fallo tiene su propia página web: VENOM.

Alguien puede estar tratando de conocerte mejor

Faro vigilando... Si tenemos acceso al registro de actividad de un servidor cualquiera podemos ver todo tipo de intentos de obtención de información; muchas veces se trata de simples troyanos de máquinas infectadas por ahí que simplemente tratan de propargarse y otras de intentos dirigidos (seguramente más raros en servidores ‘caseros’).

En Who’s Scanning Your Network? (A: Everyone) hablaban del tema entrevistando a Zakir Durumeric y Michael D. Bailey que son investigadores de la Universidad de Michigan y que, entre otros proyectos, mantienen el Internet-Wide Scan Data Repository que es un archivo público de datos recolectados mediante escaneos de la parte pública de internet. La respuesta es, como decíamos arriba, que mucha gente nos está vigilando y tratando de obtener información.

Con estos datos son capaces de detectar servidores y servicios vulnerables (e incluso avisarles en situaciones de crisis como el reciente Heartbleed del que hablamos en su momento en [Heartbleed, código y memoria](http://fernand0.github.io/Heartbleed-Y-Certificados/].

Pero no sólo eso, sino también tener cierta capacidad predictiva, com dice Durumeric en:

So, if you can watch, for example, how an organization runs their Web server, how they respond to certificate revocation, or how fast they patch — that actually tells you something about the security posture of the organization, and you can start to build models of risk profiles of those organizations. It moves away from this sort of patch-and-break or patch-and-pray game we’ve been playing.

Por supuesto, no hay que olvidar que esto mismo lo pueden hacer los ‘malos’, vigilando nuestra ‘meta’-información pueden ser capaces de encontrar nuestros puntos débiles y los mejores momentos para atacar (como en las películas ‘clásicas’ de ladrones de bancos, que el atacante aprende los protocolos y momentos adecuados para actuar).

Dicen muchas más cosas interesantes pero nos recuerdan que la seguridad no sólo es algo tecnológico, sino que también tiene que ver con nuestros procesos y forma de actuar. Y que aunque esa información no sea pública tal vez sea posible deducirla.

Claves falsas para despistar al atacante

Escondido Tengo la teoría de que una forma de acabar con el spam sería atacar los recursos de los ‘malos’: si todos respondiéramos no podrían desarrollar correctamente su labor. Tanto es así que a veces, cuando recibo algún correo de Phishing lo relleno con datos falsos con la idea de que tratarán de utilizarlos y consumo, en pequeña medida, sus recursos.

Por eso me hizo gracia leer The best way to protect your passwords may be creating fake ones donde explican una propuesta experimental para asegurar las contraseñas almacenadas con un gestor la creación de algunas nuevas (y falsas) que harían perder el tiempo a un hipotético atacante.

Además, como el almacenamiento de contraseñas estaría cifrado, el gestor genera un fichero de contraseñas de aspecto razonable para cada posible clave de descifrado que un atacante pueda probar (por fuerza bruta) así que ralentizaríamos todavía más sus ataques.