Entradas etiquetadas como ‘hack’

Máquina expendedora

Al margen de lo que es el mundo del hacking informático, se viene desarrollando hace ya mucho tiempo una especie de variante más lúdica (y no por ello menos ilegal) que se refiere a la explotación de trucos que poseen determinados aparatos electrónicos. Y cuando me refiero a estos aparatos no pretendo hablar de videoconsolas o maquinitas similares, sino de elementos más callejeros como pueden ser una máquina de Coca-Cola, un ascensor o un surtidor de gasolina.

¿Se puede hackear un ascensor? Pozí. ¿Y con qué fin? Poyaloverás.

Todo tramánculo que disponga de circuitos electrónicos es fácilmente hackeable, y no porque se puedan explotar bugs o fallos en la programación del mismo, que también, sino porque las técnicas que se utilizan muchas veces se refieren a trucos o accesos directos que utilizan los fabricantes para testear o comprobar la máquina o para recibir determinada información de la misma. Por ejemplo, las máquinas de vending, que podemos encontrar hoy día casi en cualquier esquina (refrescos, sándwiches, café, chucherías varias, etcétera), tienen una serie de “comandos ocultos” que sólo conocen los empleados que las manejan y que permiten visualizar en sus diminutas pantallas de leds información tal como el número de unidades vendidas, los errores generados o el dinero recaudado. Estas técnicas se van poco a poco difundiendo y al final los diseñadores tienen que cambiar la máquina y hacerla menos accesible al gran público.

Pero como el movimiento se demuestra andando, vamos a ver algunos ejemplos prácticos en formato videotubo que ponen de manifiesto lo tonta que es la supuestamente alta tecnología y lo listo que puede llegar a ser el ser humano. También es posible que alguno de los siguientes vídeos sean montajes, pero se ha intentado seleccionar los más representativos y los que más credibilidad pueden proporcionar.

DISCLAIMER: Algunas de las siguientes situaciones que visualizaremos representan acciones claramente delictivas. Hombre, robar una Pepsi de un máquina puede hacer un montonazo de gracia, pero es robar y punto pelota. teknoPLOF! no se hace responsable de los comentarios ni de las actuaciones aparecidas en los vídeos, sólo hace de mero intermediario entre la información que está ahí y sus lectores.

EJEMPLO 1. El ascensor. El truco consiste en llegar de un piso a otro sin que el aparato pare en ninguna otra altura intermedia aunque alguien haya pulsado el botón desde fuera. Se realiza pulsando (y manteniendo) el botón de cerrado de puertas y el piso en cuestión. Existen otras variantes como la de pulsar el botón de cerrado de puertas y el piso al que vas durante unos segundos y luego soltar. En el ascensor de mi casa no hay botón de cerrado de puertas, sólo de apertura, pero vive Dios que me haría tanta falta como el comer, que parece que todo Dios sale de casa cuando yo le doy al botón de llamada.

EJEMPLO 2. La máquina de refrescos. Este me encanta porque actúa sobre las nuevas máquinas de refrescos que están empezándose a ver cada vez más, esas que tiene una especie de montacargas interno que sube a por la lata (o botella) y la trae hasta el agujero de salida. Consiste en (como apreciarás en el vídeo) introducir la mano para evitar que el refresco salga de la máquina. Después de un par de intentos la máquina detecta algún fallo al no poder expender la botella y te devuelve el dinero. La segunda vez dejas caer las dos botellas. Conclusión: dos Coca-Colas al precio de una.

EJEMPLO 3. Las monedas de una máquina de Coca-Cola. Esto ya es un robo prácticamente a mano armada. Dudo mucho que funcione o siga funcionando, pero todavía quedan máquinas de estas (un poco antiguas) por muchos rincones. El truco se basa en la pulsación de un código de botones (4 – 3 – 2 – 1 – 1 – 2 – 3 – 1 - 1) para terminar pulsando el retorno de moneda (manteniéndolo). Nótese cómo al principio se pulsa el mismo botón de retorno de moneda para comprobar que no hay dinero introducido.

EJEMPLO 4. El surtidor de gasolina. Este truco parece servir para obtener gasolina gratis en un surtidor de esos que tienen que activarte remotamente para poder repostar. Se basa en una combinación de bombeos cortos y largos (3 cortos – 2 largos – 1 corto – 2 largos – 3 cortos) con el gatillo de la manguera. ¡Y a echar!

EJEMPLO 5. La máquina de chicles. Sí, sí, la de toda la vida de meter la moneda y girar la manivela. Ahora también se lleva mucho este sistema en otro tipo de máquinas que expenden bolas para niños con un regalito mierdoso en su interior que no vale lo que cuesta y que hace que el niño acabe jugando más con la bola del envoltorio que con el contenido. El hack consiste en utilizar una moneda de inferior tamaño (y valor, por supuesto) para, forrándola con papel, engañar a la máquina haciendo que piense que el tamaño y grosor son los correctos. Todo un éxito de un cerebro adolescente. Si es que no tendrán otra cosa en que pensar, jesusmariayjosé.

EJEMPLO 6. La máquina de chucherías. ¡Patatas gratis! Un truco parecido al ya comentado de la máquina de refrescos. Básicamente consiste en engañar a la máquina expendedora, haciendo que crea que no ha caído el snack en cuestión, al cerrar el portón inferior en el momento preciso para, posteriormente, presionar el botón de retorno de moneda y obtener el dinero y las golosinas por la cara; sin desembolsar un mísero euro, vaya.

En fin, en el tubo podréis encontrar multitud de ejemplos más de cómo hackear prácticamente todo, desde semáforos a cerraduras de coche, pasando por todo tipo de máquinas y maquinitas electrónicas. Esto sólo ha sido un somero ejemplo de algunas técnicas más o menos elaboradas que nunca hay que poner en práctica por ser claramente delictivas. Digo, ¿no?

Y si la electrónica falla, siempre quedan las técnicas de baja tecnología como la que utiliza el elemento subversivo del siguiente vídeo. Eso sí, hay que tener el brazo largo y muy delgado.

Lo más importante es ir siempre con mucho cuidado, y no vayáis a enseñarle estos vídeos a vuestra hija o sobrinita, no le vaya a pasar esto:

Angelitos… Lo que no se les ocurra.

Inyección SQL

El hacking ya no es lo que era en los noventa. Antes, la seguridad era mínima y los administradores de sistemas eran los mismos chupatintas que lo mismo te configuraban un proxy que te atendían en la ventanilla. Los sistemas operativos tenían más agujeros que un queso de esos con agujeros y, para más inri, las actualizaciones brillaban por su ausencia

Casi nadie tenía Internet, y los cuatro frikis que compramos un módem por aquello de chatear, nos las vimos y nos las deseamos para configurarlo y conectarlo a la Red, cortando la línea de teléfono a tus padres durante tardes interminables y escurriendo el bulto cuando llegaba la factura de Telefónica. Eso sí, la sensación de satisfacción que se te quedaba en el cuerpo cuando conseguías desenmarañar aquel entramado de siglas era indescriptible.

Nos cobraban 5.000 pesetas mensuales por la conexión, teléfono a parte, y existía algo que se llamaba Infovía y que muchos de los que lean esto ni sabrán lo que fue. Pululaban todavía las BBS, el chat se hacía desde un cliente de IRC y las páginas web daban verdadera pena.

Aparecieron los e-zines (fanzines digitales) y corrían de mail en mail como antaño sus hermanos mayores de papel de mano en mano. Descubrí SET antes de que fuera SET, cuando se llamaba Saqueadores a secas. Descubrí también 7a69, Raza Mexicana, Raregazz y otros de los que no recuerdo el nombre. Había uno muy divertido que no tenía como tema principal el hacking ni la informática (y que tampoco me acuerdo cómo se llamaba) que enseñaba desde cómo fabricar una bomba a las mejores maneras para asesinar a un gato. Aquella época era así; el destape digital.

Y entones fue cuando me empecé a aficionar al hacking, al cracking, al phreaking y al virii, que eran los cuatro pilares básicos que todo buen conocedor del underground informático debía manejar, o al menos alguno de ellos pero en plan gurú, si no eras directamente un lammer o un puto newbie.

La filosofía de los hackers de aquella época se ha perdido. El objetivo claro que se perseguía entonces era la superación personal y el ansia por adquirir los conocimientos que permitieran dominar aquella nueva tecnología que tanto futuro parecía tener. Hoy los buenos hackers son putas al servicio de gobiernos o de empresas de seguridad. Alguno de los de antes quedará por ahí, seguro, pero el espíritu ya no es el mismo, se ha desinflado.

El hacking, además, se ha vuelto complicado y peligroso. Hoy los administradores de sistemas han pasado de la ESO (algunos), los sistemas operativos son muchísimo más seguros y los usuarios están mucho más concienciados del concepto de seguridad (más o menos). Los bugs o agujeros de seguridad se resuelven y parchean en horas, y cualquier software se actualiza de manera automática prácticamente a diario.

Sin embargo, de vez en cuando, siguen apareciendo técnicas novedosas que producen un revolvimiento de tripas en el underground informático y una sudoración fría en los lobbys económicos y políticos del sistema. Algo así como un resurgir del lodo, descuellando por unos instantes. Por supuesto, al descubridor de tal o cual vulnerabilidad se le eleva a los altares del movimiento subterráneo y se le santifica a lo Kevin Mitnick.

En los últimos años a mí se me han puesto los pelos de punta en tres de ocasiones: una con la aparición del ataque NetBIOS, otra con la aparición del XSS y otra con la aparición de las inyecciones SQL. Y a estas últimas nos vamos a referir en continuación. ¿Por qué? Por nada en especial.

Para los neófitos: SQL es un lenguaje estructurado que se utiliza para realizar consultas contra bases de datos, ya sean consultas de actualización, de selección o de eliminación.

Las bases de datos cada vez son más importantes en nuestra vida. Todo está ordenado y clasificado en determinado campo de determinado registro de determinada tabla de determinada base de datos. Y, claro, en Internet, que es un espejo casi en tiempo real del mundo no digital, las bases de datos crecen como champiñones a diestro y siniestro. Cualquier página web que visitemos dispondrá de un foro, de una agenda de eventos, de un registro de usuarios, de un catálogo de productos, etcétera. Pues bien, todo eso, y mucho más, necesita de una base de datos para poder funcionar.

Una inyección SQL no es otra cosa que un ataque, debido a una vulnerabilidad corregible, a la base de datos de una aplicación en el nivel de validación. Para que me entienda todo el mundo, el nivel de validación se refiere a esos cuadraditos de texto donde yo escribo mi nombre de usuario y mi contraseña cuando accedo a una web en la que estoy registrado. En esos mismos cuadraditos dispongo yo de la posibilidad de escribir código SQL que la base de datos que haya detrás se trague e interprete y provocar un auténtico desastre.

Vamos a ver un ejemplo práctico. Imaginemos la típica página de validación, donde me piden mi nombre y mi contraseña, para entrar a comprar a una tienda virtual en la que estoy registrado. Cuando yo escribo el nombre, la contraseña y pulso el botón de aceptar, el software comprueba que los datos sean correctos. Para ello realiza un consulta a la base de datos en SQL que puede ser algo como lo siguiente:

"SELECT * FROM TablaUsuarios WHERE Nombre = '" + NombreUsuario + "' AND Contrasena = '" + ContrasenaUsuario + "';"
 

Esto selecciona (SELECT) todos (*) los registros de (FROM) la tabla TablaUsuarios donde (WHERE) el campo Nombre sea igual (=) a la variable NombreUsuario (su valor se asigna de lo que nosotros hallamos escrito) y (AND) el campo Contrasena sea igual a la variable ContrasenaUsuario. Si yo escribo “Jonathan” y “Tambor1900″ respectivamente en el campo de texto para nombre y contraseña, el resultado de la cadena anterior sería el siguiente:

"SELECT * FROM TablaUsuarios WHERE Nombre = 'Jonathan' AND Contrasena = 'Tambor1900';"
 

Ahora viene la magia. En el campo de texto para el nombre, en lugar de un nombre, voy a escribir esto: ' OR '1'='1

Y en el campo para la contraseña lo mismo, mismito. La cadena SQL que se envía a la base de datos quedaría así:

"SELECT * FROM TablaUsuarios WHERE Nombre = '' OR '1'='1' AND Contrasena = '' OR '1'='1';"
 

Es decir, selecciona todos los registros de la tabla TablaUsuarios donde el campo Nombre sea igual a nada o 1 sea igual a 1 y el campo Contrasena sea igual a nada o 1 igual a 1. ¡Abracadabra! Es posible que no exista un nombre o una contraseña vacía, pero siempre 1 va a ser igual a 1, por lo tanto, hasta la cocina del sitio web como si fuéramos un usuario correctamente registrado.

Vamos a hacer más pupita. Vamos a escribir en el campo del nombre lo mismo que antes y en el de la contraseña lo que esto: '; DROP TABLE TablaUsuarios

Con lo que la cadena final queda así:

"SELECT * FROM TablaUsuarios WHERE Nombre = '' OR '1'='1' AND Contrasena = ''; DROP TABLE TablaUsuarios;"
 

Las sentencias SQL siempre terminan en punto y coma (;) y pueden separarse entre sí por el mismo signo de puntuación. En el anterior ejemplo, comprobaría correctamente que 1 es igual a 1, como hemos comentado antes, para, después, cargarse sin miramientos la tabla TablaUsuarios (DROP TABLE TablaUsuarios).

Evidentemente el daño puede ser mayor que borrar una tabla (suponemos que el administrador tiene copias de seguridad), ya que podemos hacernos con todos los datos sensibles y privados de los usuarios del sitio, hacer compras en su nombre, acceder a sus cuentas bancarias y mil miles de cosas más.

Muchos habrán pensado ya a estas alturas que para inyectar este tipo de códigos SQL es necesario conocer el nombre de las variables (NombreUsuario y ContrasenaUsuario) y el nombre de la tabla (TablaUsuario) que el programador ha utilizado. Y efectivamente así es. Pero para conseguir estos datos podemos recurrir a la técnica de hacer “cascar” la consulta y que produzca un error. Por ejemplo, si en el nombre de usuario escribimos dos comillas simples ('') y en la contraseña cualquier cosa, la cadena SQL resultante sería la siguiente:

"SELECT * FROM TablaUsuarios WHERE Nombre = ''' AND Contrasena = 'Tambor1900';"
 

Aquí hay más comillas de las que el intérprete SQL de la base de datos puede reconocer, y esto devolvería un error de acceso a la base de datos. Dependiendo de qué servidor web aloje esta página y cómo esté configurado, es más que posible que dicho error aparezca en pantalla (en formato HTML) especificando concretamente dónde y por qué se ha producido, y describiéndonos a las mil maravillas la cadena de conexión y todas sus variables, nombres de campos y tablas. Un placer. Gracias mil.

Una vez expuesta la vulnerabilidad y cómo explotarla, es de caballeros explicar también cómo corregir este defecto. He de decir que muchísimas páginas web en Internet no tienen este tema solucionado; allá ellos. Sólo es necesario visitar sitios web y probar (a base de comillas aquí, comillas allí) hasta que encontremos uno vulnerable. Ya digo que los hay por doquier.

Existen varios métodos para solucionar este problema, pero el más sencillo y eficaz es el que consiste en evitar la introducción de comillas simples en las cajas de texto sustituyéndolas por espacios, por ejemplo. He aquí una forma de hacerlo en VBScript en una página ASP:

CadenaSQL = "SELECT * FROM TablaUsuarios WHERE Nombre = '" & Replace(NombreUsuario, "'", " ") & "' AND Contrasena='" & Replace(ContrasenaUsuario, "'", " ") & "'"
 

O en JavaScript en una página PHP:

CadenaSQL = SELECT * FROM TablaUsuarios WHERE Nombre = '" & NombreUsuario.replace( "'", " "); & "' AND Contrasena='" & ContrasenaUsuario.replace("'", " "); & "'"
 

Otro factor importante en cuanto a la seguridad es limitar al máximo los permisos del usuario que ejecuta estas sentencias para evitar posibles problemas. Por ejemplo utilizando un usuario distinto para las sentencias SELECT, DELETE o UPDATE y asegurándonos de que cada ejecución de una sentencia ejecute una sentencia del tipo permitido.

Una solución definitiva sería trabajar con procedimientos almacenados. El modo en el que se pasan los parámetros a los procedimientos almacenados evita que la inyección SQL pueda ser usada. También deberíamos validar los datos que introduce el usuario teniendo en cuenta, por ejemplo, la longitud de los campos y el tipo de datos aceptados. Si programamos en ASP.NET, además, utilizaremos siempre que sea posible las clases de System.Web.Security.FormsAuthentication para que los usuarios entren en nuestras aplicaciones web.

Es tan jugoso explotar una vulnerabilidad como conseguir eliminarla. Los hackers del pasado son los expertos en seguridad del presente. Pero, por favor, no se me vendan a las multinacionales, que no queda muy underground que digamos.