Blog

VULNERABILIDADES DE APLICACIONES WEB: EJECUCIÓN DESPUÉS DE UNA REDIRECCIÓN

01.01.2018 23:11
Esta vulnerabilidad y el ataque asociado a ella son más conocidos por su nombre en inglés: Execution After Redirect. Resultan de un error de comprensión por parte del desarrollador de la semántica de la redirección. Los programadores suelen asumir que la aplicación web se detendrá después de llamar a una función que realiza una redirección. Ciertos entornos de programación, sin embargo, no detienen la ejecución en una redireccionamiento y ejecutan todo el código que sigue a la redirección.
 
Veamos un ejemplo:
 
<?php
header('Location: https://geoestrategia.webnode.es');
//
$a=fopen('evidencia.txt', 'w');
fwrite($a,headers_sent());
fclose($a);
?>
 
Si el lector ejecuta el programa será redirigido a nuestra página web pero a la vez podrá ver que, en el directorio donde se encuentra el script, será creado el archivo evidencia.txt, prueba de que el código siguió ejecutándose.
 
Una forma muy simple de demostrar que la vulnerabilidad puede ser explotada es usar JavaScript para la redirección:
 
<?php
if (!$clave_correcta) {
    print "<script>RubicusFrontendIns.location = 'https://geoestrategia.webnode.es';</script>\n\n";
}
?>
<h1>Un intruso no deberia poder llegar hasta aca</h1>
<a href="https://geoestrategia.webnode.es/news/vulnerabilidades-de-aplicaciones-web-inyeccion-html/">Informacion exclusiva</a>
 
Si se desabilita la ejecución de JavaScript en el navegador y dado que el código continuará ejecutándose se tendrá acceso a un área restringida.
 
Para prevenir este ataque hay que asegurarse de que el código no continuará ejecutándose después de un redireccionamiento. En PHP en muchos casos esto se puede lograr con la función die(). A los programadores les recomendamos desarrollar siempre código simple. La innecesaria complejidad del código es el origen de muchos errores y vulnerabilidades.
 

VULNERABILIDADES DE APLICACIONES WEB: URL FUZZING

31.12.2017 21:19
El nombre en inglés de este ataque es de difícil traducción, pero podría definirse como detección por fuerza bruta de directorios y archivos no referenciados. El nombre alude al ataque, pero en última instancia su éxito final depende de una vulnerabilidad.
 
Suele creerse que si un directorio o archivo no puede ser llamado desde ningún enlace de ninguna página ni está mencionado o documentado en ningún lado, entonces está a salvo de miradas indiscretas y de ser el caso, tampoco puede ser ejecutado. Esto no es así. La "seguridad por oscuridad" (security by obscurity) por sí sola tiene un valor extremadamente escaso.
 
El ataque URL Fuzzing consiste en inyectar en la URL de base de un sitio una gran cantidad de nombres de directorios y archivos y esperar la respuesta para ver si los mismos existen.
 
Está claro entonces que impidiendo el listado de directorios y archivos no logramos ocultar los mismos y que si se quiere lograr que no sean accesibles deberán estar guardados en un directorio inaccesible para el usuario o deberán estar protegido con un nombre de usuario y contraseña.
 
Llevar a cabo este tipo de ataque es extremadamente sencillo aunque obviamente será más fácil detecar un archivo llamado about.html que uno llamado 77345bnmv447885.html. Si no se puede evitar que un archivo sea accesible al menos para algunos usuarios, sería conveniente que, además de ser protegido por una combinación de usuario/contraseña, tenga un nombre de ese tipo. El usuario y contraseña son suscetibles a un ataque de fuerza bruta. Siempre es bueno tener presente el concepto de defensa en profundidad o defensa en capas y ahí la seguridad por oscuridad puede tener algún valor.
 
Finalmente una forma menos drástica de este ataque el la "adivinación" de nombres de directorios y archivos, ingresándose los mismos en la barra de direcciones del navegador en forma manual. Un especialista experimentado e intuitivo podrá tener muy buenos resultados de esa forma.
 

REINO UNIDO: FINALIZÓ "EL AÑO DEL PODER NAVAL"

31.12.2017 21:15
A principios del 2017 el Ministro de defensa británico, Michael Fallon, proclamó altisonantemente que el 2017 sería el año del comienzo de una nueva era en el poder naval británico. Ya en ese momento dijimos que nos parecía una expresión de buenos deseos. El tiempo nos está dando la razón.
 
El portaaviones HMS Queen Elizabeth que fue aceptado y formalmente puesto en servicio en la Marina Real británica presentó su primer problema técnico apenas dos semanas más tarde. Una filtración a través de los sellos de los ejes de sus hélices obligará a realizar una millonaria reparación. Técnicamente el problema es algo normal y de poca gravedad pero el temor de muchos es que sea sólo el principio de una serie de dolores de cabeza. Habrá que esperar para saber si los temores son fundados o no.
 
Sin dudas la Royal Navy empieza el 2018 con preocupaciones mucho más graves. Los proyectos faraónicos y la paupérrima planificación de la Defensa británica hicieron estragos en los fondos británicos para la defensa. Recientemente dos dragaminas de la clase Hunt fueron formalmente retirados del servicio en una ceremonia en la que los medios británicos estuvieron ausentes porque no se les permitió asistir.
 
Las tratativas británicas con Brasil por la venta del portahelicópteros y buque de asalto anfibio HMS Ocean están muy avanzadas, al parecer casi finalizadas. Los siguientes en la lista podrían ser los buques de asalto anfibio HMS Albion y HMS Bulwark y dos fragatas Type 23. Chile y Brasil ya fueron notificados de que esos cuatro buques podrían quedar disponibles para la venta. En el 2023 los británicos podrían desprenderse de otras tres fragatas tipo 23.
 
Por otra parte con el regreso prematuro a la Base Naval del Portsmouth del destructor Type 45 HMS  Diamond, los seis destructores de esta clase se encuentran ahora en esa base. La ociosidad de estas naves debida a los conocidos problemas en su planta de poder alarma a los británicos. Recordemos que el hecho de que todos los tipo 45 estén en puerto al mismo tiempo no es novedoso, hay un antecedente. En julio del 2016 se dio una situación similar. La clases "Daring" terminó siendo tan problemática como costosa.
 
No todo fue malo, aún con su desperfecto técnico y su total falta de aviones el HMS Queen Elizabeth es un activo valioso. Otra buena noticia fue que la fragata tipo 23 HMS Argyll culminó con éxito las pruebas de lanzamiento del nuevo sistema de defensa antiaérea Sea Ceptor. Se realizaron dos series de ensayos y pruebas con una duración de aproximadamente dos semanas cada una.
 
Algunos verán el vaso medio lleno, otros medio vacío. No se trata de optimismo o pesimismo. La Royal Navy lucha por recuperar parte del poder perdido en las últimas décadas. Una planificación para la Defensa francamente inadecuada no le permite ponerse de pie.  
 
Artículo relacionado:
 

VULNERABILIDADES DE APLICACIONES WEB: INYECCIÓN DE CÓDIGO PHP EVALUADO DINÁMICAMENTE (II)

30.12.2017 15:43
Ya vimos la inyección de código evaluado dinámicamente y la inyección estática de código. Antes de seguir adelante, sin embargo, queremos insistir en que el uso de "eval()" no es el único punto posible de de inyección de código evaluado dinámicamente. Vimos, por ejemplo, que PHP permite diferentes formas de creación dinámica de funciones y que ese era otro punto posible de inyección.
 
El objetivo de esta serie de artículos sobre vulnerabilidades web es mostrar que hay más que un puñado de ellas y que incluso las más comunes pueden ser explotadas de formas a veces muy poco conocidas. No es nuestra intención enseñar a atacar, por eso a menudo nos reservamos algunos ejemplos de explotación poco convencionales.
 
En lo que a la inyección de código evaluado dinámicamente concierne, en general se cree que la única función que puede traer problemas es "eval()". No es así, damos otro ejemplo más que no agota ni remotamente todas las posibilidades.
 
La función de opción "assert()" verifica si la aserción es FALSE:
 
assert('is_numeric(a)');
 
En el caso de arriba el parámetro "a" siempre debería ser un número.
 
Si el parámetro es proporcionado como una cadena será evaluado como código PHP. Entonces el siguiente código, no frecuente pero posible, es vulnerable: 
 
<?php
$foobar = $_GET['code'];
assert($foobar);
?>
 
La siguiente es una de las inyecciones posibles:
 
https://127.0.0.1/inyecciones_codigo/assert/ejemplo.php?code=phpinfo()
 
Quien sólo quiere ilustrarse un poco sobre el tema podrá ignorar estos casos pero quienes se dediquen a programar, a verificar el código de forma estática o dinámica y quienes realicen pruebas de penetración deberían ser conscientes de estas posibilidades, por raras que sean. Los piratas informáticos suelen ser ingeniosos, creativos y perseverantes y no es que los estemos alabando.
 

VULNERABILIDADES DE APLICACIONES WEB: INYECCIÓN ESTÁTICA DE CÓDIGO.

30.12.2017 06:18
En el lenguaje PHP la sentencia "include" incluye y evalúa el archivo especificado.
 
En el manual de PHP leemos "Cuando un archivo es incluido, el intérprete abandona el modo PHP e ingresa al modo HTML al comienzo del archivo objetivo y se reanuda de nuevo al final. Por esta razón, cualquier código al interior del archivo objetivo que deba ser ejecutado como código PHP, tendrá que ser encerrado dentro de etiquetas válidas de comienzo y terminación de PHP."
 
https://php.net/manual/es/function.include.php
 
De lo expresado se desprende que si incluimos, por ejemplo, un archivo de texto y en el mismo hay código PHP encerrado entre etiquetas ("<?php ?>"), el mismo será ejecutado.
 
Veamos el siguiente ejemplo:
 
<?php
$mensajes = "mensajes.txt";
if ($_GET["accion"] == "escribir") {
$nombre = $_GET["nombre"];
$texto = $_GET["texto"];
$handle = fopen($mensajes, "a+");
fwrite($handle, "$nombre dice '$texto'<hr>\n");
fclose($handle);
echo "El mensaje ha sido guardado\n";
}
else if ($_GET["accion"] == "ver") {
include($mensajes);
}
?>
 
escribimos del siguiente modo:
 
https://127.0.0.1/inyeccion-estatica/ejemplo.php?accion=escribir&nombre=Juan&texto=<?php phpinfo() ?>
 
cuando ingresemos:
 
127.0.0.1/inyeccion-estatica/ejemplo.php?%20accion=ver
 
veremos los mensajes y se ejecutará la función de opción "phpinfo()" dejando ver información que no debería quedar a la vista de cualquiera.
 
Si bien el presente ejemplo parece resultar de un error muy grosero, en la práctica esta vulnerabilidad aparecerá en escenarios mucho más realistas. Además en la práctica aparecerán vulnerabilidades más groseras que la del ejemplo.
 
Artículo realcionado:
 

EMPRESAS POCO SERVICIALES IV - UN FINAL (MÁS O MENOS) ACEPTABLE

29.12.2017 16:12
Ayer Iberia cumplió con lo manifestado y por fin abonaron en la cuenta que aperturé el reembolso por un ticket de viaje  que mi madre no utilizó porque no se presentó en el aeropuerto  debido a que enfermó y tuvo que ser internada en el hospital; este trámite duró seis meses y al respecto les puedo comentar lo siguiente:
 
Si van a comprar un billete aéreo mediante una agencia de viajes, elijan una agencia confiable. En mi caso, mis próximas compras serán a través de las mismas líneas aéreas.
 
Asegúrense y pregunten el tipo de billete que les están vendiendo, en mi caso la agencia de viajes que elegí me dijo que el ticket que compré no era reembolsable, por lo tanto no tenía derecho a ningún reclamo; ante mis dudas llamé directamente al call center de la línea aérea y allí me información lo contrario.
 
Guarden los medios de pago, tickets o boletas, ya que ante un posible reclamo  ante instituciones de protección al consumidor, estos documentos son importantes.
 
Cualquier duda puede ser absuelta por el Call Center de las líneas aéreas, basta con darles el código de reserva.
 
Para acelerar cualquier tipo de reclamo, deben insistir mediante llamadas al Call Center, correos electrónicos o visitando las mismas líneas aéreas.
 
Finalmente, esto demanda uno que otro gasto adicional, gastos de llamadas telefónicas, inversión de tiempo y molestias en manifestar lo sucedido a uno y otro agente; pero la devolución es real, no en un 100% pero mejor perder un porcentaje que el total de un ticket aéreo.
 
Artículos relacionados:
 

VULNERABILIDADES DE APLICACIONES WEB: INYECCIÓN DE CÓDIGO PHP EVALUADO DINÁMICAMENTE

29.12.2017 08:56
Si bien la inyección de código evaluado dinámicamente no es exclusiva del lenguaje PHP, usaremos el mismo para explicarla y ejemplificarla. En otro artículo sobre el tema veremos una vulnerabilidad asociada a la presente, la INYECCIÓN ESTÁTICA DE CÓDIGO.
 
Damos un ejemplo de inyección de código evaluado dinámicamente:
 
<?php
$string = $_GET['nombre']; 
eval ( "echo ". $string .";" );
?>
 
Si se ingresa como dato un nombre de usuario el mismo será impreso en pantalla. Si en cambio en la barra de direcciones del navegador escribimos lo siguiente: 
 
https://127.0.0.1/inyeccion_de_codigo/vulnerable.php?nombre=phpinfo();
 
encontraremos un cúmulo de información que convendría que permaneciera sin descubrir.
 
La función "eval()" evalúa una cadena como código de PHP, en este caso la cadena (en realidad función de opción) "phpinfo()" que muestra información sobre la configuración de PHP y una gran cantidad de información sobre el servidor, el sistema operativo y otros.
 
Tal como lo expresa el propio manual de PHP "el constructor de lenguaje eval() es muy peligroso porque permite la ejecución de código de PHP arbitrario. Su uso está totalmente desaconsejado. Si se ha verificado cuidadosamente que no existe otra opción que usar este constructor, se ha de poner especial atención en no pasar ninguna información proporcionada por el usuario a esta función sin haberla validado apropiadamente con anterioridad."
 
 
Pero el uso de "eval()" no es el único punto posible de este tipo de inyección de código. Daremos otro ejemplo que no agota ni remotamente todas las posibilidades. PHP permite diferentes formas de creación dinámica de funciones, una de ellas es ésta:
 
<?php
$f_dinamica = $_GET['f_dinamica'];
$argumento = $_GET['argumento'];
$f_dinamica($argumento);
?>
 
Bastará con tipear en el navegador la siguiente URL
 
https://127.0.0.1/injecciones-codigo/fucion-dinamica.php?f_dinamica=system&argumento=comando
 
donde comando puede ser cualquier comando como ls (o dir). La inyección de código se habrá convertido en una Inyección de Comandos, una vulnerabilidad extremadamente peligrosa.
 

VULNERABILIDADES DE APLICACIONES WEB: ¿CUÁL ES EL ERROR EN ESTA APLICACIÓN? (II)

29.12.2017 07:17
Para los lectores que no se percataron de cuál es el error publicamos el archivo atras.php tal cual estaba:
 
<?php
$usuario = $_POST['usuario'];
$clave = $_POST['clave'];
if (($usuario = 'administrador') && ($clave = 'quieroentrar123')){
  header('Location: administrador.php');
}else{
  header('Location: adelante.php');
}
?>
 
lo que, cualquiera sea el nombre de usuario que se ingrese y cualquiera sea la clave que se ingrese llevará a administrador.php
 
<html>
<h1>Pagina del administrador</h1>
<p>Admin, su clave de acceso es "quieroentrar123"</p>
</html>
 
El archivo atras.php corregido es el siguiente:
 
<?php
$usuario = $_POST['usuario'];
$clave = $_POST['clave'];
if (($usuario == 'administrador') && ($clave == 'quieroentrar123')){
  header('Location: administrador.php');
}else{
  header('Location: adelante.php');
}
?>
 
El error - ya sea de tipeo, provocado por el cansancio, por una distracción o por simple apuro - consite en que en el primer caso se estaba asignando un valor a $usuario y $clave ('=') en lugar de comparar el valor ingresado con el del administrador ('=='). A esta vulnerabilidad se la denomina precisamente USO DE OPERADOR INCORRECTO.
 
Adicionalmente 'quieroentrar123' es una contraseña compuesta sólo por letras minúsculas y números, que figura en el programa, para el colmo sin codificar y que será la misma para cada instalación del producto. Además en determinadas circunstacias podría ser vista por un pirata informático. 
 
Artículo relacionado:
 

VULNERABILIDADES DE APLICACIONES WEB: ¿CUÁL ES EL ERROR EN ESTA APLICACIÓN?

28.12.2017 08:34
Veamos un ejemplo de otra vulnerabilidad web poco conocida: 
 
<html>
<h1>Aplicación con un error</h1>
<form action="atras.php" method="post">
    Usuario: <input type="text" name="usuario" value="">
    Clave: <input type="password" name="clave" value="">
    <input type="submit">
</form>
</html>
 
donde atras.php es:
 
<?php
$usuario = $_POST['usuario'];
$clave = $_POST['clave'];
if (($usuario = 'administrador') && ($clave = 'quieroentrar123')){
  header('Location: administrador.php');
}else{
  header('Location: adelante.php');
}
?>
 
Estamos dando un ejemplo extremadamente obvio que debería ser detectado en las primeras pruebas de la "aplicación", pero no siempre será así. Dejamos al lector la oportunidad de darse cuenta de cuál es el error y para quien no se percate, daremos la respuesta en el siguiente artículo sobre el tema. 
 
 

VULNERABILIDADES DE APLICACIONES WEB: MANIPULACIÓN DE PARÁMETROS

28.12.2017 07:26
El ataque de manipulación de parámetros se basa en la alteración de parámetros intercambiados entre el cliente y el servidor para modificar datos de la aplicación como credenciales de usuario y permisos, precio y cantidad de productos y otros. Por lo general, esta información se almacena en cookies, campos ocultos de formularios HTML o cadenas de consulta de URL.
 
Tomemos como ejemplo el siguiente código vulnerable:
 
<!DOCTYPE html>
<html>
<h1>COMPRE SU EXPRIMIDOR POR SÓLO $ 400,00.-</h1>
<body>
 
<form action="atras.php" method="post">
  First name: <input type="text" name="nombre" value=""><br>
  <input type="hidden" name="precio" value="400">
  <input type="submit" value="Enviar">
</form>
 
</body>
</html>
 
Nótese que el campo "hidden", que es el que enviará el precio, no puede ser visto por el usuario. Es un error relativamente común creer que porque no es visto no puede ser alterado, sin embargo el precio puede ser cambiado con total facilidad por el "comprador", sin necesidad de ningún programa especial. El lector podrá comprobarlo con el siguiente código para el archivo "atras.php".
 
<?php
echo '<pre>';
var_dump($_POST);
echo '</pre>';
?>
 
Para prevenir el cambio de precio, el mismo debe ser establecido del lado del servidor.
 
<< 119 | 120 | 121 | 122 | 123 >>

Etiquetas

  1. portaaviones
  2. Wehrmacht
  3. Luftwaffe
  4. Tempest
  5. blindados
  6. bombarderos
  7. artillería
  8. Brasil
  9. submarinos
  10. RAF
  11. patrulleros
  12. British Army
  13. ejercicios
  14. misiles y cohetes
  15. IMARA
  16. EA
  17. portahelicópteros
  18. clase Queen Elizabeth
  19. F-35
  20. avisos
  21. fragatas
  22. tipo 45
  23. destructores
  24. helicópteros
  25. FAA
  26. Orion P3
  27. COAN
  28. ARA
  29. Royal Navy
  30. Malvinas