Estrenamos nueva sección #MundoHacker, donde trataremos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital. En estas entradas pondré ejemplos prácticos y sencillos, por lo que para aquellos que os dediquéis a la seguridad informática seguramente sea un simple repaso, y para aquellos que no tenéis ni idea de seguridad, vendrán genial para que conozcáis este ecosistema dentro de la informática que es realmente interesante.
Índice de contenido
Un poco de números
La semana pasada Imperva (consultoría de seguridad) sacaba a la luz un estudio en donde se habían monitorizado buena parte de los foros de hackers, con el fin de encontrar los métodos más usados (y por tanto más hablados).
La respuesta es clara: Inyecciones a SQL y ataques de denegación de servicio (DDos), con un 19% cada uno.
La primera busca conseguir información sensible de la base de datos, mientra que la segunda, es por lo general usada para revindicar por grupos hacktivistas, o bien para camuflar otro ataque contra los datos alojados en el servicio, colocación de malware,…
Pese al peligro que encierran estos ataques (en el primero la información de tus usuarios, o el registro que sea se ve comprometido, y en el segundo deja fuera de juego el servicio), se calcula que menos de un 5% del presupesto para TI está destinado a la seguridad de los servicios de la empresa, por lo que es bastante común encontrarte como desarrollador en una compañía que depende básicamente de servidores poco o nada seguros.
Automatizando los procesos de hackeo
Hasta ahora, el perfil de un hacker era por lo general el de un usuario con conocimientos amplios en lenguaje informático, motivado por fines morales (recordemos que únicamente deberíamos hackear un servicio con idea de demostrar su vulnerabilidad) o malignos (lo que está ocurriendo básicamente en Rusia :)). Pero lo cierto que este perfil se está difuminando con el tiempo, en tanto en cuanto aparecen programas que automatizan las largas cadenas de código para atacar otros servicios (me recuerda un poco el paso del Bloc de Notas al Dreamweaber), no siendo estrictamente necesario saberse toda y cada una de las funciones, abaratando los costes y el tiempo, y centrándose en lo que en verdad interesa.
De ahí que aparezcan herramientas como Havij, para automatizar los ataques SQL, o Foca de nuestro compañero de Informática 64 Chema.
SQL injection
Bajo este nombre, se esconden mil y un maneras que buscan a grandes rasgos acceder a una base de datos mediante PHP (o el lenguaje elegido), y una vez dentro, sacar/modificar/borrar los datos.
Para ello, se tiende a buscarle las cosquillas a cualquier pestaña de consulta (por ejemplo, un formulario de contacto), y se escribe código PHP en su defecto.
Por poner un ejemplo sencillo, imaginemos una BBDD con una tupla ID=’1′ y NAME=’pedro’, de la que conocemos su nombre «Names».
Suponiendo que no haya seguridad alguna, podríamos escribir directamente en la pestaña donde te pide la ID lo siguiente:
1′; DROP TABLE `Names`;’
Con esto igualaríamos ID a 1 (algo seguramente válido), y de paso borramos la tabla.
‘ UNION SELECT * FROM `Names` WHERE `id` = ‘1
Gracias a esto obtendríamos los datos de uno de los usuarios (el número 1 en la tabla).
Por supuesto este tipo de ataques tan sencillos ya están contemplados en los servicios MySQL, Oracle y compañía, teniendo que desactivarlos para permitir que puedan llegar a usarse, pero lo cierto es que a poco que se tome un poco más de tiempo (por ejemplo sacando los nombres de la tabla y de la BBDD mediante ataque a los metadatos), estas protecciones son insuficientes.
Imaginemos la misma tabla, con un selector (un buscador por ejemplo) donde podamos elegir que datos queremos mostrar según la elección del usuario. Una entrada posible podría ser del tipo:
‘ Or 1=1 —
Suponiendo que estamos ante una sentencia select:
SELECT * FROM Names WHERE id=» + id
Obtendríamos un select con una puerta abierta siempre (ya que o se cumple lo primero, que seguramente falle, o se cumple lo segundo, esto es, 1=1, que siempre se cumple), por lo que la entrada no daría error, y de paso nos cargamos el resto de código con el doble guión.
Otros ataques comunes son a los metadatos:
‘ UNION SELECT id, name,», 0,» FROM sysobjects
WHERE xtype=’U’ —
‘ UNION SELECT 0, name, », 0,» FROM syscolumns
WHERE id=[X] —
Con estas dos sentencias, nos devolverían el nombre de la tabla y las ids de los usuarios (pudiendo luego obtener el nombre o todo aquello que estuviese guardado para cada uno) todo lo que los privilegios del usuario con el que nos hemos conectado a la BBDD nos permitiese.
Cómo protegernos
Existen ciertos principios a considerar para proteger nuestras aplicaciones de un SQL Injection:
- No confiar en la entrada del usuario: Los principales ataques de SQL se producen en la entrada de un formulario, por tanto no permitir caracteres especiales (las comas, el punto y coma, guiones dobles,…), procedimientos del sistema («sys», «xp_»,…) son algunas de los principios que tenemos que tener en cuenta.
- No utilizar sentencias SQL construidas dinámicamente: Es una de las puertas de entrada más comunes de un ataque de SQL, ya que como vimos en el último ejemplo, permite incluir una función lógica que se cumpla en todos los casos (y por tanto no de error). Siempre que se pueda, es mejor utilizar sentencias almacenadas.
- No utilizar cuentas con privilegios administrativos: En todos los servicios de servidor podemos definir varios usuarios, aunque no es raro usar el administrador para hacer las consultas. Lo suyo sería que cada usuario pudiera acceder únicamente a las tablas y los datos que le pertenecen, y no a todos.
- No proporcionar mayor información de la necesaria: Los mensajes de Error ofrecen una ayuda útil para los hackers, ya que por lo general informan más de la cuenta. Controlarlos mediante excepciones es un buen hábito a seguir.
________
Realizar este tipo de artículos me lleva varias horas, y en algunos casos, gastos extra que habitualmente suplo de mi bolsillo, o gracias a esa comunidad de patronos que me apoyan realizando donaciones puntuales o periódicas.
Si le gustaría ver más de estos tutoriales y análisis por aquí. Si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
Trackbacks / Pingbacks