

Buenas, cómo va?
En esta ocasión voy a mostrarles una de las formas existentes de "hacking" conocida como SQLi o Inyección de SQL.
Para los que no están familiarizados, SQL es un lenguaje de consultas a bases de datos.
Con dicho lenguaje podemos realizar múltiples acciones.
Primero unos conceptos básicos (Si no querés o no te interesa esta parte apretá ctrl + f y buscá el segundo resultado que diga "ataques"
)
Supongamos que tenemos la siguiente tabla:
En esta tabla tenemos 3 campos:
Cada tabla tiene que tener sí o sí una clave única identificadora, llamada Id
Entonces tenemos:
· id_usuario que es de tipo entero
· nombre_usuario que es de tipo varchar de 25 caracteres (admite tanto números como caracteres)
· password_usuario que es igual a la anterior.
Conociendo estos datos podemos empezar a manipular el contenido de esa tabla.
Para que nos muestre todos los registros que tiene esa tabla basta con hacer la siguiente consulta SQL:
Nos devolvería todos los registros que contiene la tabla.
En este caso tiene 2 usuarios:
(Aclaro que las contraseñas generalmente se encriptan para tener mayor seguridad, más adelante voy a hablar de eso)
El (*) de la consulta indica que estamos pidiendo los datos que tienen todos los campos.
Si quisiéramos sólo el nombre de usuario la consulta sería esta:
Y nos devolvería esto:
Así como podemos consultar los datos que están dentro de la tabla, también podemos hacer altas, bajas y modificaciones.
Voy a explicar solo una de ellas para que no se extienda demasiado el post.
Supongamos que queremos cambiar la clave de "pepe"
Lo que hacemos es:
Y si consultamos nuevamente los registros de la tabla nos devuelve la clave de "pepe" actualizada.
Bueno, una vez que tenemos los conceptos básicos pasamos a lo que nos interesa.
Cabe destacar que no todas las páginas son vulnerables a este tipo de ataques.
Lo que vamos a hacer para ver si es vulnerable o no, es lo siguiente:
Tenemos que usar Dorks, que son palabras claves dentro de una url en las cuales podremos inyectar nuestro código SQL.
Entonces vamos a google y buscamos por ejemplo cualquiera de estas:
En esta ocasión voy a mostrarles una de las formas existentes de "hacking" conocida como SQLi o Inyección de SQL.

Para los que no están familiarizados, SQL es un lenguaje de consultas a bases de datos.
Con dicho lenguaje podemos realizar múltiples acciones.

Primero unos conceptos básicos (Si no querés o no te interesa esta parte apretá ctrl + f y buscá el segundo resultado que diga "ataques"

)
Supongamos que tenemos la siguiente tabla:

En esta tabla tenemos 3 campos:
Cada tabla tiene que tener sí o sí una clave única identificadora, llamada Id
Entonces tenemos:
· id_usuario que es de tipo entero
· nombre_usuario que es de tipo varchar de 25 caracteres (admite tanto números como caracteres)
· password_usuario que es igual a la anterior.
Conociendo estos datos podemos empezar a manipular el contenido de esa tabla.
Para que nos muestre todos los registros que tiene esa tabla basta con hacer la siguiente consulta SQL:
SELECT * FROM usuarios
Nos devolvería todos los registros que contiene la tabla.
En este caso tiene 2 usuarios:

(Aclaro que las contraseñas generalmente se encriptan para tener mayor seguridad, más adelante voy a hablar de eso)
El (*) de la consulta indica que estamos pidiendo los datos que tienen todos los campos.
Si quisiéramos sólo el nombre de usuario la consulta sería esta:
SELECT nombre_usuario FROM usuarios
Y nos devolvería esto:


Así como podemos consultar los datos que están dentro de la tabla, también podemos hacer altas, bajas y modificaciones.
Voy a explicar solo una de ellas para que no se extienda demasiado el post.
Supongamos que queremos cambiar la clave de "pepe"
Lo que hacemos es:
UPDATE usuarios SET password_usuario = "123pepe" WHERE id_usuario = 1
Y si consultamos nuevamente los registros de la tabla nos devuelve la clave de "pepe" actualizada.


Bueno, una vez que tenemos los conceptos básicos pasamos a lo que nos interesa.
Cabe destacar que no todas las páginas son vulnerables a este tipo de ataques.
Lo que vamos a hacer para ver si es vulnerable o no, es lo siguiente:
Tenemos que usar Dorks, que son palabras claves dentro de una url en las cuales podremos inyectar nuestro código SQL.
Entonces vamos a google y buscamos por ejemplo cualquiera de estas:
inurl: noticia.php?id=
inurl: novedades.php?id=
inurl: info.php?id=
inurl: fotos.php?id=
inurl: pagina.php?id=
Cuando nos aparezcan los resultados, elegimos una cualquiera y la abrimos.

En mi caso elegí esta:

Con esto ya tenemos una posible página vulnerable.
Lo siguiente es cerciorarme si es realmente vulnerable o no.
Acá empieza la parte divertida
Lo primero que debemos hacer es borrar lo que esta después de "id=" y provocar un error en la base de datos.
Cómo provocamos el error? Fácil: luego del "=" ponemos caracteres no válidos como comillas, números negativos, etc. y vemos lo que pasa.
Colocamos por ejemplo una comilla, le damos enter y nos devuelve:
Perfecto, conseguimos generar un error en la base de datos!
Ahora probaremos si realmente es vulnerable o no a SQLi. Para ello, después del "id=" colocaremos lo siguiente:
En este caso sigue dando error:
Lo que sigue ahora es empezar a agregar números hasta que desaparezca el error.
Entonces la inyección nos debería quedar así:
Y así sucesivamente hasta que no nos de error.
En este ejemplo me con poner hasta 4 me alcanzó, pero puede pasar que tengan que probar tantas veces que se cansen y busquen otro objetivo.
En lugar del error, me apareció esto:
Ese 4 y ese 2, son números de tablas, y nos indica que efectivamente la página es vulnerable a SQLi.
Ahora elegimos uno de los 2 números, por ejemplo el 4, porque pintó ?)
Vamos a usar ese 4 para que nos muestre en su lugar los nombres de las tablas.
El paso siguiente es adicionar después del último número de la url este código:
Y además reemplazar el número 4 por "table_name" (Sin las comillas)
Nos quedaría así la dirección:
Le damos enter, y podemos obeservar que en lugar del número 4 nos aparecen nombres de distintas tablas, en mi caso:
(Son muchas y no tiene sentido que las muestre todas, con estas sirven como ejemplo)
Miramos todos los nombres de las tablas, hasta que encontremos alguna que creamos que nos puede servir, por ejemplo la tabla "users"
Ahora tenemos que convertir el nombre de la tabla a ASCII, para eso vamos a San Google, y buscamos un conversor online, o si te da paja acá te dejo uno
La conversión para "users" es:
Le sacamos los espacios y entre cada número le ponemos una coma:
Volvemos a nuestra url y cambiamos "table_name" por "group_concat(column_name)" (SIN LAS COMILLAS!!) e "information_schema.tables" por "information_schema.columns+where+table_name=char(117,115,101,114,115)--"
Le damos enter y tan tan tan... ?)
Nos muestra los nombres de las columnas de la tabla "users"
Miramos bien qué campos nos sirven (username,user_password) y lo inyectamos de la siguiente manera:
Cambiamos "group_concat(column_name)" por "concat(username,0x3a,user_password)"
Concat es para concatenar y el 0x3a es para que el usuario y la contraseña estén separados pos dos puntos ":" (usuario:contraseña)
Borramos desde "information_schema.columns" para adelante y dejamos el "+from+"
Después de ese "from", ingresamos el nombre de la tabla ("users"
y nos debería quedar algo así:
Por lo que podemos ver, hay 3 usuarios (Acuérdense, a la izquierda de los dos puntos el nombre de usuario y a la derecha la contraseña) :
Como les mencionaba al principio del post, las contraseñas para tener un grado más de seguridad se encriptan. Hay varios métodos, el más conocido es el de MD5.
Pueden buscar un decriptador en google, o usar este que les dejo por acá .
YYYYYYYYYY listo, ya tienen los nombres de usuarios y contraseñas para acceder y hacer las consultas o ABM (Altas, bajas, modificaciones) que quieran.
Hasta acá llegó el paso a paso. Queda por cuenta de ustedes lo que hacen con estos datos.
En muchos países puede considerarse un delito acceder y modificar datos ajenos, así que no me hago responsable por el uso o mal que le den a este post.
Como yapa, si sos administrador/diseñador de una o varias páginas/aplicaciones web, te doy unos tips para evitar este tipo de ataques.
Sólo los voy a nombrar, entiendo que si están en tema o bien ya lo saben o pueden buscar más info en Google.
· Limitar los permisos del usuario a nivel de base de datos. (Esto es por ejemplo para el usuario pepe, que solo pueda hacer consultas del tipo select, y ninguna de ABM, o que tenga tablas bloqueadas)
· No dar información extra intruso sacando de la pantalla los errores de la base de datos.
· Es clave "escapar" las comillas o caracteres "raros" con "msqli_real_scape_string" si usamos MySQL, "pg_scape_string" en caso de usar PostgreSQL o addslashes si usamos otro SGBD.
· También podemos utilizar "htmlentities" para convertir los textos en entidades html, como una barrera más para nuestra seguridad.
· Como medida extra además se podrían usar expresiones regulares para evitar la inserción de ciertas palabras (SELECT, DROP, UNION, etc.), pero si el producto está orientado a un público de habla inglesa puede resultar poco práctico.
Eso fue todo, sigamos haciendo inteligencia colectiva!!!
Si te gustó, te resultó interesante o no leíste un carajo ?) dejame un comentario abajo y decime qué te pareció.
Lo siguiente es cerciorarme si es realmente vulnerable o no.

Acá empieza la parte divertida

Lo primero que debemos hacer es borrar lo que esta después de "id=" y provocar un error en la base de datos.
Cómo provocamos el error? Fácil: luego del "=" ponemos caracteres no válidos como comillas, números negativos, etc. y vemos lo que pasa.
Colocamos por ejemplo una comilla, le damos enter y nos devuelve:

Query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"' at line 1

Perfecto, conseguimos generar un error en la base de datos!
Ahora probaremos si realmente es vulnerable o no a SQLi. Para ello, después del "id=" colocaremos lo siguiente:
-1+UNION+SELECT+1,2--
En este caso sigue dando error:


Lo que sigue ahora es empezar a agregar números hasta que desaparezca el error.
Entonces la inyección nos debería quedar así:
-1+UNION+SELECT+1,2,3--
-1+UNION+SELECT+1,2,3,4--
-1+UNION+SELECT+1,2,3,4,5--
Y así sucesivamente hasta que no nos de error.
En este ejemplo me con poner hasta 4 me alcanzó, pero puede pasar que tengan que probar tantas veces que se cansen y busquen otro objetivo.
En lugar del error, me apareció esto:

Ese 4 y ese 2, son números de tablas, y nos indica que efectivamente la página es vulnerable a SQLi.

Ahora elegimos uno de los 2 números, por ejemplo el 4, porque pintó ?)
Vamos a usar ese 4 para que nos muestre en su lugar los nombres de las tablas.
El paso siguiente es adicionar después del último número de la url este código:
+from+information_schema.tables--
Y además reemplazar el número 4 por "table_name" (Sin las comillas)
Nos quedaría así la dirección:
www.blablabla.com/news.php?id=-1+UNION+SELECT+1,2,3,table_name+from+information_schema.tables--
Le damos enter, y podemos obeservar que en lugar del número 4 nos aparecen nombres de distintas tablas, en mi caso:


(Son muchas y no tiene sentido que las muestre todas, con estas sirven como ejemplo)
Miramos todos los nombres de las tablas, hasta que encontremos alguna que creamos que nos puede servir, por ejemplo la tabla "users"

Ahora tenemos que convertir el nombre de la tabla a ASCII, para eso vamos a San Google, y buscamos un conversor online, o si te da paja acá te dejo uno
La conversión para "users" es:
"117 115 101 114 115"
Le sacamos los espacios y entre cada número le ponemos una coma:
"117,115,101,114,115"

Volvemos a nuestra url y cambiamos "table_name" por "group_concat(column_name)" (SIN LAS COMILLAS!!) e "information_schema.tables" por "information_schema.columns+where+table_name=char(117,115,101,114,115)--"
Le damos enter y tan tan tan... ?)

Nos muestra los nombres de las columnas de la tabla "users"

Miramos bien qué campos nos sirven (username,user_password) y lo inyectamos de la siguiente manera:
Cambiamos "group_concat(column_name)" por "concat(username,0x3a,user_password)"
Concat es para concatenar y el 0x3a es para que el usuario y la contraseña estén separados pos dos puntos ":" (usuario:contraseña)
Borramos desde "information_schema.columns" para adelante y dejamos el "+from+"
Después de ese "from", ingresamos el nombre de la tabla ("users"

y nos debería quedar algo así:


Por lo que podemos ver, hay 3 usuarios (Acuérdense, a la izquierda de los dos puntos el nombre de usuario y a la derecha la contraseña) :
dexmod:a0dbde9503e13437db0f854b0b72a73b
admin:63a9f0ea7bb98050796b649e85481845
miladro:122f961db675f6a45b998594471a990b

Como les mencionaba al principio del post, las contraseñas para tener un grado más de seguridad se encriptan. Hay varios métodos, el más conocido es el de MD5.
Pueden buscar un decriptador en google, o usar este que les dejo por acá .
YYYYYYYYYY listo, ya tienen los nombres de usuarios y contraseñas para acceder y hacer las consultas o ABM (Altas, bajas, modificaciones) que quieran.


Hasta acá llegó el paso a paso. Queda por cuenta de ustedes lo que hacen con estos datos.

En muchos países puede considerarse un delito acceder y modificar datos ajenos, así que no me hago responsable por el uso o mal que le den a este post.

Como yapa, si sos administrador/diseñador de una o varias páginas/aplicaciones web, te doy unos tips para evitar este tipo de ataques.
Sólo los voy a nombrar, entiendo que si están en tema o bien ya lo saben o pueden buscar más info en Google.

· Limitar los permisos del usuario a nivel de base de datos. (Esto es por ejemplo para el usuario pepe, que solo pueda hacer consultas del tipo select, y ninguna de ABM, o que tenga tablas bloqueadas)

· No dar información extra intruso sacando de la pantalla los errores de la base de datos.

· Es clave "escapar" las comillas o caracteres "raros" con "msqli_real_scape_string" si usamos MySQL, "pg_scape_string" en caso de usar PostgreSQL o addslashes si usamos otro SGBD.

· También podemos utilizar "htmlentities" para convertir los textos en entidades html, como una barrera más para nuestra seguridad.

· Como medida extra además se podrían usar expresiones regulares para evitar la inserción de ciertas palabras (SELECT, DROP, UNION, etc.), pero si el producto está orientado a un público de habla inglesa puede resultar poco práctico.

Eso fue todo, sigamos haciendo inteligencia colectiva!!!
Si te gustó, te resultó interesante o no leíste un carajo ?) dejame un comentario abajo y decime qué te pareció.

Gracias por pasar!