Blog

VULNERABILIDADES DE APLICACIONES WEB: VERB TAMPERING

05.01.2018 21:08
Esta vulnerabilidad, supuestamente muy bien conocida pero que nadie se atreve a dejar de mencionar, permite eludir (hacer el "bypass" de) la necesidad de ingresar una combinación de usuario/contraseña pedidos por - por ejemplo - un archivo .htacces. En rigor la vulnerabilidad se origina en un error de configuaración, o en un concepto erróneo de cómo se manejan algunas restricciones.
 
Supongamos un servidor Apache con el siguiente archivo .htaccess:
 
AuthName "Restricted Area"
AuthType Basic
AuthUserFile /xampp/.htpasswd
<Limit GET>
require valid-user
</Limit>
 
El contenido del .htaccess de arriba implica que cuando se mande una solicitud de HTTP (HTTP request) con el verbo GET, será necesario autenticarse para acceder al archivo de destino. Lo que lamentablemente algunas personas ignoran es que el verdadero significado de <Limit GET> es que la autenticación será requerida SOLAMENTE cuando la solicitud sea enviada con el verbo GET. Si, por ejemplo, se envía la solicitud con el verbo POST, se accederá al archivo deseado sin necesidad de ingresar la combinación usuario/contraseña. El pirata informático simplemente interceptará el request (se puede usar algún otro método en lugar de la interceptación) y cambiará el verbo de la solicitud, burlando la necesidad de autenticarse. No tiene sentido entonces, al menos en este caso, usar el <Limit VERBO>, mucho menos con un solo verbo. 
 
Lo invitamos a hacernos llegar sus comentarios, dudas y/o inquietudes a nuestra dirección de contacto: luis_lavric@hotmail.com. ¡Muchas gracias! 
 

VULNERABILIDADES DE APLICACIONES WEB: FALTA DE NEUTRALIZACIÓN DE CRLF

04.01.2018 21:10
La inadecuada neutralización de las secuencias de caracteres que marcan el retorno de carro y el cambio de línea (en inglés "Carriage Return" y "Line Feed - CRLF) puede ser aprovechada para atacar aplicaciones web con diversas consecuencias.
 
Si una aplicación vulnerable acepta al final de alguno de sus registros datos ingresados por el usuario (o simplemente controlables por él) sin neutralizar CRLF, el atacante podría inyectar algo similar a esto:
 
Cualquier texto usual de registro+dato ingresado o controlable por el usuario<CR><LF>ERROR GRAVE: ES IMPOSIBLE GUARDAR INFORMACIÓN EN BASE DE DATOS
 
siendo "<CR><LF>ERROR .... DATOS" parte de lo ingresado por el usuario.
 
El ataque podría hacer perder muchísimo tiempo al administrador, que   trataría de entender por qué se generó la línea: 
 
ERROR GRAVE: ES IMPOSIBLE GUARDAR INFORMACIÓN EN BASE DE DATOS
 
La línea con el texto usual de registro estaría completa y la siguiente - aparentemente independiente de la misma - parecería una alerta muy seria generada por la aplicación. Mientras el administrador estaría ocupado analizando el mensaje, el atacante podría aprovechar su distracción haciendo algo más grave.  
 
Como enseñamos a defender, no a atacar, hemos dado un ejemplo bastante "benigno" de ataque, los hay mucho peores.
 
Una de las formas de prevenir la inyección de CRLF es la siguiente. Damos el ejemplo para el lenguaje PHP, el lector lo adaptará fácilmente al de su interés:
 
<?php
$registar = $_GET["registrar"];
$eliminar = array("\n", "\r","%0d", "%0D", "%0a", "%0A");
$listo = str_replace($eliminar, "", $registrar);
?>
 
Si agrega echo delante de $listo podrá ver el resultado. Los retornos de carro y los cambios de línea habrán sido eliminados.
 

LA EMPRESA: EL USO DE TELÉFONOS CELULARES PROVISTOS POR LA MISMA

04.01.2018 06:41
Hoy en día el uso de la tecnología mediante los celulares es muy común en la vida diaria, se cuenta con acceso a internet, uso del chat, aplicaciones, correo electrónico y mucho más;  por lo tanto muchas empresas ponen a disposición de sus empleados equipos modernos, de media o alta gama que faciliten la comunicación, el monitoreo y desenvolvimiento de labores.
 
Esto implica que la jornada de trabajo muchas veces no termina cuando uno se retira de la oficina, ya que al portar un  aparato celular otorgado por la empresa para trabajar y que es utilizado también en nuestra  vida privada estamos comprometidos a  contestar y resolver temas en fines de semana, días feriados o vacaciones, es decir se está dispuesto al trabajo durante los siete días de la semana.
 
Estos equipos modernos no sólo facilitan las comunicaciones a nivel laboral y particular, sino que permiten ver el  desarrollo de noticias de la localidad y del mundo.
 
Por otro lado también hay personas que utilizan estos smartphones  de manera adictiva durante la jornada de trabajo, causando distracción en el entorno por múltiples llamadas, por uso excesivo del chat, juegos y otros.
  
En la empresa alimenticia en la que trabajo, en las áreas de producción de alimentos y atención al cliente se adoptó como medida la prohibición del uso de celulares, ya que no es posible atender y hablar con clientes con un celular en la mano, igualmente es cuestión de salubridad.
 
La tecnología usada con buen criterio es de provecho. El abuso, tanto por parte de los usuarios como de las empresas, suele ser pernicioso. En el primer caso el uso de teléfonos móviles puede volverse adictivo y atentar contra un contacto humano cálido y genuino; en el segundo extiende - a veces abusivamente - nuestro horario de trabajo y nos insta a estar constantemente "de guardia".
 

GRAN BRETAÑA NO ESCARMIENTA Y AVANAZA CON EL REEMPLAZO DE LOS VANGUARD

03.01.2018 11:07
 
Por estas horas se hace más fuerte la versión de que Brasil finalmente habría adquirido el portahelicópteros británico HMS Ocean. El precio final sería de 84 millones de libras. Hace apenas tres años la nave fue sometida a tareas de reacondicionamiento y modernización por un monto de 65 millones de libras. Los británicos necesitan cubrir un tremendo déficit en las finanzas del sector de su Defensa. Si es que finalmente se confirman los datos de la transacción, la comparación del costo de la modernización del Ocean con del precio por el que se habría vendido habla por sí sola de la pésima planificación británica.
 
Los proyectos faraónicos están dejando a los británicos sin fondos y sin personal. Los portaaviones Clase Queen Elizabet son costosos y demandan muchos tripulantes, pero los británicos parecen no aprender o simplemente las cifras no les importan. Lockheed Martin acaba de adjudicarse un contrato para proporcionar la integración del "sistema de armas estratégicas" Trident II a bordo de los submarinos clase Columbia y Dreadnought de los Estados Unidos de América y del Reino Unido respectivamente. Los Dreadnought serán el reemplazo de los Vanguard de la Royal Navy. En otras palabras, el programa de los Dreadnought sigue adelante como si el dinero no fuera un problema.
 
Recientemente la Marina Real británcia retiró del servicio dos dragaminas de la clase Hunt. Ahora parece confirmarse la venta del Ocean a Brasil. 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. Con los seis destructores tipo 45 con problemas de propulsión y con el programa de las fragatas Type 26 retrasado es difícil asegurar que los portaaviones británicos tendrán una escolta adecuada
 
Dos portaaviones casi sin escolta y tres o cuatro SSBN no constituyen una marina de guerra equilibrada. Desde el punto de vista de la Defensa la planificación británica es francamente calamitosa. 
 

VULNERABILIDADES DE APLICACIONES WEB: DELIMITADORES DE PARÁMETROS - UN EJEMPLO DE ATAQUE INGENIOSO

03.01.2018 09:44
Supongamos el siguiente contenido del archivo usuarios.dat que contiene los datos de los usuarios registrados:
 
135409973|Juan|usuario| 
634147881|Marcos|administrador|
455255201|Ana|usuario|
 
El programa que guarda los datos crea un código único para cada usuario, a continuación escribe el delimitador "|", el nombre del usuario, el delimitador "|" y a menos que quien acaba de registrarse sea administrador al final agrega la palabra "usuario" y nuevamente el delimitador "|". El recién registrado no tendrá ningún permiso especial.
 
Ahora bien, si el programa analiza el archivo usuarios.dat de izquierda a derecha, cuenta los parámetros en base al delimitador y se detiene en el tercero entonces es posible crear un nuevo nombre de usuario como el siguiente:
 
Luis|administrador
 
que será guardado por el programa al final de usuarios.dat de la siguiente forma:
 
135409973|Juan|usuario| 
634147881|Marcos|administrador|
455255201|Ana|usuario|
542754992|Luis|administrador|usuario|
 
Como el programa detiene el análisis de los datos de cada usuario en el tercer delimitador, Luis tendrá privilegios de administrador.
 
¡CUIDADO! Basándonos en la presente técnica y combinándola con otra hemos logrado (CON EL EXPRESO PERMISO DE HACERLO) modificar nuestro puntaje en un juego en línea. El programdor y quien analice la seguridad de la aplicación no deberán subestimar la creatividad de los piratas informáticos. Quien escribe este artículo recomienda inisistenetemente coronar cualquier análisis estático y/o dinámico - cuya utilidad no niega - con un test de penetración. ¡No permitamos que el primero en hacerlo sea un hacker!
 

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

03.01.2018 08:21
La vulnerabilidad de la "aplicación" que habíamos presentado con el título "VULNERABILIDADES DE APLICACIONES WEB: ¿CUÁL ES EL ERROR EN ESTA APLICACIÓN? (III)" ( geoestrategia.webnode.es/news/vulnerabilidades-de-aplicaciones-web%3a-¿cual-es-el-error-en-esta-aplicacion-%28iii%29/ ) se hace evidente en el archivo cambio.php:
 
<html>
<h1>Aca se ingresa la nueva clave</h1>
<form action="guardar.php" method="post">
    Usuario: <input type="text" name="nombre" value="">
    Contrasena: <input type="password" name="nueva" value="">
    Confirmar ctsna.: <input type="password" name="reiterar" value=""> 
<input type="submit">
</form>
</html>
 
Se pide un nombre de usuario, pero no se verifica que se trate del mismo que se autenticó. El usuario Juan podría cambiar su contraseña o la de cualquier otra persona cuyo nombre de usuario conociera. Si el Juan conociera el nombre de usuario del administrador el ataque podría devenir en un escalamiento de priviliegios. 
 
La forma más simple de resolver el problema es solicitar el ingreso de la contraseña vieja y verificar que sea la correcta antes de cambiar la clave de acceso. Recordamos que el nombre de ususario y su contraseña nunca deben estar incrustados en el código (hardcoded) y muchísimo menos en texto plano. En el artículo anterior están así para facilitar el planteo del problema y su comprensión. Ante cualquier duda, inquietud y/o sugerencia invitamos a nuestros lectores a escribirnos a nuestra dirección de contacto: luis_lavric@hotmail.com.
 
Artículo relacionado:
 

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

02.01.2018 07:41
Presentamos el código de esta "aplicación". Para su más fácil comprensión lo hemos simplificado. Eso resultó en dos vulnerabilidades que no son las que pretendemos que el lector encuentre: el nombre de ususario y su contraseña están incrustados (hardcoded) en texto plano en un archivo .php. Hay otra vulnerabilidad, mucho más fácil de explotar y de consecuencias potencialmente muy graves. ¿Cuál es?
 
Éste es el archivo frente.php (también podría ser frente.html):
 
<html>
<h1>Ingrese para cambiar su clave de acceso</h1>
<form action="atras.php" method="post">
    Usuario: <input type="text" name="usuario" value="">
    Contrasena: <input type="password" name="clave" value="">
    <input type="submit">
</form>
</html>
 
siendo atras.php:
 
<?php
$usuario = $_POST['usuario'];
$clave = $_POST['clave'];
if (($usuario == 'Juan') && ($clave == 'CaTW7ro%53AX&117uS?tmPv')){
header('Location: cambio.php');
} else {
header('Location: frente.php');
}
?>
 
y cambio.php (podría ser cambio.html) es:
 
<html>
<h1>Ingrese la nueva clave</h1>
<form action="guardar.php" method="post">
    Usuario: <input type="text" name="nombre" value="">
    Contrasena: <input type="password" name="nueva" value="">
    Confirmar ctsna.: <input type="password" name="reiterar" value=""> 
<input type="submit">
</form>
</html>
 
y guardar.php es:
 
<?php
$nombre = $_POST['nombre'];
$nueva = $_POST['nueva'];
$reiterar = $_POST['reiterar'];
if ($nueva == $reiterar) {
echo "La contrasena de $nombre ha sido cambiada a $nueva exitosamente";
}
?>
 
La clave debería ser guardada en una base de datos y no ser mostrada en patalla pero quisimos que el lector pueda hace su propia prueba y ver el resultado. ¿Cuál es la vulnerabilidad de la "aplicación"? Publicaremos la respuesta a la brevedad. 
 

 

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:
 
<< 118 | 119 | 120 | 121 | 122 >>

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