[Guia] Vulnerabilidades a nivel web

Iniciado por BigBear, 7 Octubre 2011, 01:28 AM

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

BigBear

[Guia] Vulnerabilidades a nivel web

[Titulo] : Vulnerabilidades a nivel web
[Autor] : Doddy Hackman


[Temario]

--===================================--

0x01 : Introduccion
0x02 : SQLI
0x03 : Blind SQLI
0x04 : HTML Injection
0x05 : XSS
0x06 : RFI
0x07 : LFI
0x08 : Remote code Execution
0x09 : Full Path Discloure
0x10 : Full Source Discloure
0x11 : PHP Injections

--===================================--


0x01 : Introduccion


Hola a todos.

Eh empezado a hacer esta simple guia donde detallo de forma minima las vulnerabilidades mas comunes
a nivel web , en cada vulnerabilidad solo explicare como se produce y como arreglarlo , pero
no voy a ampliar demasiado en tecnias de cada una
Cualquier error en la guia deben decirmelo para aprender de mis errores


0x02 : SQLI

Las injecciones SQL son una de las vulnerabilidades mas usadas debido a que es una de las faciles de explotar cuando estas
son encontradas.
La injecciones SQL se producen cuando se incluye en una sentencia SQL una variable que no esta filtrada , entonces
mediante la variable mal filtrada vamos a poder codigo que nos puedan ayudar
a sacar columnas , extraer tablas y columnas , datos y todo eso.........

Un ejemplo de este tipo de vulnerabilidad


<title>LABS SQL INYECTION</title>

<STYLE type="text/css">

body {
background-color: #000000;
color:orange;
font-family:
Courier New;
cursor:crosshair;
font-size: small;
}
</style>

<center><h1><font color=green>LABS SQL INYECTION</font></h1><br><br><br>

<?php 

$host 
'localhost';
$user 'root';
$datos 'users';

$conexion mysql_connect($host$user);
mysql_select_db($datos,$conexion); 



if (isset(
$_GET['id'])) {
$id $_GET['id'];
}

if(empty(
$id)){
$id "1";
}

$sql mysql_query("SELECT * FROM `hackers` WHERE id=".$id) or die (mysql_error());

$resultado mysql_fetch_row($sql); 

echo 
"<h3><b>id: </font>".$resultado[0]."<br>";
echo 
"user: </font>".$resultado[1]."<br>";
echo 
"pass: </font>".$resultado[2]."</b></h3><br>"

mysql_close($conexion); 

?>



Como ven , la funcion mysql_query() usa un sentencia que posee la variable $id , como la variable
$id no esta filtrada o protegida , se puede insertar codigo de la siguiente manera


http://127.0.0.1/sql.php?id= ¿AQUI?


A partir del id podemos poner el codigo para ver si es vulnerable o no porque id es la variable mal
filtrada

Para saber si es vulnerable podemos poner un ' en el contenido de id

Si el resultado de la pagina es algo como mysql error bla bla

Es porque es vulnerable

Una forma de protegerse de este ataque es verificar que $id sea un numero y no codigo raro para modificar
la sentencia SQL




if (!is_numeric($_GET['id'])) {
echo "no me jodas !!!<br>";
exit(1);
}



Como vemos usamos is_numeric para la verificacion , pero usamos este para verificar que si $id no es un numero , este  nos avise y
nos diga no me jodas !!!

0x03 : Blind SQLI

Las Blind SQLI vienen de la misma vulnerabilidad que las SQLI , pero en este caso el admin
usa @ en las funciones para la conexion con la DB o error_reporting en 0 para que
no tire errores. Un grave error pues asi esta provocando las conocidas Blind SQLI

Un ejemplo de pagina vulnerable seria este


<title>LABS SQL INYECTION</title>

<STYLE type="text/css">

body {
background-color: #000000;
color:orange;
font-family:
Courier New;
cursor:crosshair;
font-size: small;
}
</style>

<center><h1><font color=green>LABS SQL INYECTION</font></h1><br><br><br>

<?php 

$host 
'localhost';
$user 'root';
$datos 'hackman';

$conexion mysql_connect($host$user,"123");
mysql_select_db($datos,$conexion); 



if (isset(
$_GET['id'])) {
$id $_GET['id'];
}

if(empty(
$id)){
$id "1";
}

$sql = @mysql_query("SELECT * FROM `hackers` WHERE id=".$id);

$resultado = @mysql_fetch_row($sql); 

echo 
"<h3><b>id: </font>".$resultado[0]."<br>";
echo 
"user: </font>".$resultado[1]."<br>";
echo 
"pass: </font>".$resultado[2]."</b></h3><br>"

mysql_close($conexion); 

?>



como ven usamos @ para evitar errores las funciones mysql_query() y mysql_fetch_row()

Entonces para comprobar que si la pagina es vulnerable a Blind SQLI podemos poner asi en
la parte de id


http://127.0.0.1/sql.php?id=1+and+1=1



http://127.0.0.1/sql.php?id=1+and+1=0


Si en el primer link devuelve un resultado positivo y en el segundo negativo (no muestra nada)

Una forma de arreglar esta vulnerabilidad seria la  misma que la de SQLI




if (!is_numeric($_GET['id'])) {
echo "no me jodas !!!<br>";
exit(1);
}




0x04 : HTML Injection


Las HTML Injection son conocidas como las vulnerabilidades mas idiotas y faciles de hacer , pero
, ¿los que dicen eso saben como se produce y como se arregla ? ,de ese estoy seguro que no .

Esta vulnerabilidad se produce normalmente en los libros de visitas cuando se deja un comentario y
se lo muestra en pantalla

Un ejemplo seria este




<?php 

echo "

<form action='' method=POST>
<input type=text name=mensaje>
<input type=submit value=Mostrar>
</form>

"
;

if (isset(
$_POST['mensaje'])) {
echo 
$_POST['mensaje'];
}

?>




Si queremos probar si la pagina padece de esta vulnerabilidad solo tendriamos que poner algo de
codigo html

Si ponemos "<h1>hola</h1>" y se muestra como tal es porque es vulnerable

La forma de protegerse es facil solo filtras las variables para protegerse

Para hacer esto podemos usar htmlentities() o htmlspecialchars() , usen la que quieran pues las
dos protegen



<?php 

echo "

<form action='' method=POST>
<input type=text name=mensaje>
<input type=submit value=Mostrar>
</form>

"
;

if (isset(
$_POST['mensaje'])) {

echo 
htmlentites($_POST['mensaje']);
}

?>




0x05 : XSS

Bueno , XSS es una vulnerabilidad conocida y util a la hora de robar cookies , la vulnerabilidad se
produce cuando se muestra una variable mal filtrada



<?php 

echo "

<form action='' method=GET>
<input type=text name=msg>
<input type=submit value=Mostrar>
</form>

"
;

if (isset(
$_GET['msg'])) {

echo 
$_GET['msg'];
}

?>




Para ver si es vulnerable podemos ejecutar el siguiente link con el siguiente codigo


<script>alert("hola");</script>



http://127.0.0.1/xss.php?msg=<script>alert("hola");</script>


Como ven la variable msg es enviada por metodo GET  , la variable no es protegida y es
mostrada tal cual

Una forma de reparar es usar como htmlentities() o htmlspecialchars()


<?php 

echo "

<form action='' method=GET>
<input type=text name=msg>
<input type=submit value=Mostrar>
</form>

"
;

if (isset(
$_GET['msg'])) {

echo 
htmlspecialchars($_GET['msg']);
}

?>



0x06 : RFI

Bueno , el viejo RFI , esta vulnerablidad es muy conocida , se trata de un mal uso de la funcion
include() y una mala configuracion de la variable allow_url_include estando On en php.ini

Un ejemplo seria este



<?php 

if (isset($_GET['car'])) {
include(
$_GET['car']);
}

?>



Como ven , si queremos saber si la  pagina es vulnerable a RFI  podemos hacer asi


http://127.0.0.1/rfi.php?car=http://www.google.com.ar


Y si la pagina muestra la pagina de google es porque la pagina es vulnerable a RFI

Una forma de protegerse RFi seria usando un control en la variable "car" de la siguiente forma



if (isset($_GET['car'])) {

if ($_GET['car'] == "veo") {
include("veo.php");
}

elseif($_GET['car'] == "noveo") {
include("noveo.php");
}
else {
echo "no intentes cosas raras xDDD";
}
}



0x07 : LFI

Bueno , el conocido LFI ,es parecido a RFI , pero este solo ejecuta archivos a nivel local y no remoto como RFI

Un ejemplo de pagina vulnerable seria asi


<?php 

if (isset($_GET['car'])) {
include(
$_GET['car']);
}

?>



Para saber si es vulnerable podemos cargar la variable car con un '  de la siguiente manera


http://127.0.0.1/lfi.php?car='


Y si nos devuelve algo asi


Warning: include(') [function.include]: failed to open stream: No such file or directory in C:\xampp\htdocs\666.php on line 4


Es porque es vulnerable xDDD

Para protegernos de esta vulnerabilidad seria de la misma forma que RFI




if (isset($_GET['car'])) {

if ($_GET['car'] == "veo") {
include("veo.php");
}

elseif($_GET['car'] == "noveo") {
include("noveo.php");
}
else {
echo "no intentes cosas raras xDDD";
}
}



0x08 : Remote code Execution

Esta vulnerabilidad no es muy conocida , se trata de poder ejecutar comandos en la maquina atacada
sin necesidad de crear una shell.

Entonces un ejemplo de pagina vulnerable seria esta.


<?php

echo "

<form action='' method=POST
<input type=text name=cmd>
<input type=submit value=mandar>
</form>

"
;

if (isset(
$_POST['cmd'])) {
system("ping ".$_POST['cmd']);
}



?>



Como ven la pagina hace un comando ping con system() a la ip marcada por ustedes

Entonces que pasa si ponemos una ip cualquiera

Pues nada solo hace un ping a la ip que pusieron

Entonces si ponemos esto


ip && ver


El servidor nos devolveria el resultado de el comando ping con un extra xDDD
Pues si estamos viendo la version del SO
Entonces la explicacion es simple solo ponemos && para agregar un comando siempre cuando la ip
que pusieron anteriormente era  real y el ping se mostro correctamente

Entonces si queremos arreglar esta vulnerabilidad tenemos que reemplazar toda cosa rara en la variable
de "cmd"

Quedando el codigo de la siguiente manera


<?php

echo "

<form action='' method=POST
<input type=text name=cmd>
<input type=submit value=mandar>
</form>

"
;

if (isset(
$_POST['cmd'])) {

$cmd $_POST['cmd'];

$cmd str_replace("&&"""$cmd);
$cmd str_replace(";"""$cmd);
$cmd str_replace("-"""$cmd);
$cmd str_replace("?"""$cmd);
$cmd str_replace("||"""$cmd);
$cmd str_replace("|"""$cmd);
$cmd stripslashes($cmd);

system("ping ".$cmd);

}



?>



0x09 : Full Path Discloure

Esta vulnerabilidad se produce cuando se produce un error , tanto como un error en el resultado de la funcion que estamos
usando como la sintasis usada en la misma

Un ejemplo seria este


<?php
if (isset("no se nada de php")) {

}
?>



Que feo programo xDDD

Entonces el error que nos devuelve seria este


Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in C:\xampp\htdocs\666.php on line 2


Como vemos nos devuelve el directorio actual donde se ejecuta el archivo php , esto es lo que se llama
full path discloure

Esta vulnerabilidad tambien aparece en SQL y LFI , cuando poniamos la comilla ' el resultado de include() y mysql_query()
En el caso del segundo era una full path discloure ademas de estar indicando que la pagina realmente era vulnerable a SQL
En el caso del primero tambien se debia al mal uso de la funcion include() devolviendonos un error con un full path
discloure

0x10 : Full Source Discloure

Bueno , esta vulnerabilidad nos permite descargar archivos de un servidor web debido a que no
filtra las variables

Un ejemplo seria este



if (isset($_GET['down'])) {
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachment; filename=".basename($_GET['down']));
readfile($_GET['down']);
}


Entonces si ponemos la ruta que queremos en la variable "down" estamos hecho.
Un ejemplo de uso seria este


http://127.0.0.1/down.php?down=c:/secretos.txt


Y con eso descargariamos el archivo secreto si es que existe xDDD

Entonces una forma de evitar esta vulnerabilidad seria usando una DB , que contenga una tabla
con los links de descarga , entonces una vez que se detecte la variable down se verificaria que fuera
un numero de lo contrario chau xDDD

0x11 : PHP Injections

Bueno , la php injections suelen suceder cuando usa la funcion eval().
La funcion eval() nos permite ejecutar codigo php

Un ejemplo de esta vulnerabildad seria este


<?php

if (isset($_GET['te'])) {
eval(
$_GET['te']);
}

?>



Como ven , es un caso muy raro y especial en cierto sentido xDDD

Entonces si ejecutamos este link


http://127.0.0.1/php?te=echo "hola mundo";


Si vemos en la pantalla , este link nos devuelve hola mundo , creo que es obvio que es vulnerable

Una forma de protegerse seria no usar eval()

--========--
¿ The End ?
--========--