Blog

EL CUARTO SUBMARINO CLASE ASTUTE DE LA ROYAL NAVY COMPLETÓ SU PRIMERA INMERSIÓN

24.01.2018 13:14
 
El cuarto submarino de la clase Astute, el Audacious, completó su primera inmersión. La prueba tuvo lugar durante la semana pasada en la dársena de la empresa constructora, BAE Systems, en las instalaciones de la compañía en Barrow-in-Furness. La operación permitió probar muchos de los sistemas de a bordo y la seguridad y estabilidad de la nave. Está previsto que el submarino deje Barrow a fines de este año para iniciar las primeras pruebas en el mar. 
 
Está previsto que los submarinos de esta clase sean siete u ocho. Cuentan con propulsión nuclear y pueden dar la vuelta al mundo sumergidos, produciendo el oxígeno necesario para la tripulación a partir del agua del mar.
 
El reactor que lleva a bordo la clase Astute es el PWR2, diseñado para los submarinos clase Vanguard. El desplazamiento en inmersión de las unidades de la clase Vanguard es de 15.900 toneladas, contra las 7.400 de las naves clase Astute. Al parecer el uso del PWR2 contribuyó a reducir costos pero trajo algunos problemas. Por lo pronto la gran potencia del reactor no se traduce en una velocidad de avance proporcionalmente mayor.
 
Recordemos además que ya en marzo del 2008, el programa de la clase Astute estaba excedido de presupuesto en un 48 por ciento y con un retraso de 47 meses. En noviembre de 2009, debido a nuevos retrasos causados por una a serie de cuestiones técnicas y otras, las demoras llegaron a un total de 57 meses y a un costo 53 por ciento superior al presupuestado. 
 

VULNERABILIDADES DE APLICACIONES WEB: SUBIDA DE ARCHIVOS PELIGROSOS

24.01.2018 10:59
 
Cuando tenemos que habilitar la posibilidad de que un usuario suba archivos a un sitio web, debemos ser extremadamente cautelosos. El ejemplo utilizado con mayor frecuencia es el del abuso de la funcionalidad de subir imágenes. Veamos un caso extremdamente burdo:
 
<html>
    <body>
        <form method="post" action="" enctype="multipart/form-data" >
            <label for="file">Archivo:</label>
            <input type="file" name="archivo" id="file1" /> 
            <br />
            <input type="submit" name="submit" value="Enviar" />
        </form>
    </body>
</html>
<?php
if(isset($_POST['submit'])) {
    if ($_FILES["archivo"]["error"] > 0) {
        echo "Error: " . $_FILES["archivo"]["error"] . "<br />";
    } else {
        echo "Subido: " . $_FILES["archivo"]["name"] . "<br />";
        echo "Tipo: " . $_FILES["archivo"]["type"] . "<br />";
        echo "Tamaño: " . ($_FILES["archivo"]["size"] / 1024) . " Kb<br />";
        echo "Guardado en: " . $_FILES["archivo"]["tmp_name"] . "<br/>";
    }
}
 
$destino = "fotos/" . basename($_FILES['archivo']['name']);
 
if(move_uploaded_file($_FILES['archivo']['tmp_name'], $destino))
{
echo "La foto ha sido subida con éxito";
}
else
{
echo "Hubo un error al subir la foto.";
}
?>
 
Como vemos en el ejemplo de arriba, el archivo pasa desde un lugar de almacenamiento temporario a su destino definitivo sin el menor control del tipo de archivo que se subió. El pirata informático hubiera podido subir una puerta trasera programada en, por ejemplo, PHP sin ninguna dificultad. Otro error posible (y no muy raro de encontrar) es la validación sólo del lado del cliente con, por ejemplo, JavaSript. El pirata informático burlará esa validación con extrema facilidad. 
 
Hay otros problemas asociados a la subida de archivos. Un pirata informático podrá subir un archivo que realmente sea una imagen, pero que estará contaminada con código PHP u otro. Bastará que encuentre una vulnerabilidad de Inclusión Local de Archivo para que pueda ejecutar el código (ver: geoestrategia.webnode.es/news/vulnerabilidades-de-aplicaciones-web-escritura-de-archivos/ - la razón por la que el código se ejecutará será similar al caso de los archivos de texto en la Escritura de Archivos).
 
Un pirata informático también podrá nombrar un archivo .php como archivo de imagen y aprovechar alguna vulnerabilidad del sitio para renombrarlo con su tipo de archivo original.
 
Como se puede observar, cuando se habilita una funcionalidad de subida de archivos se debe tomar una serie de precauciones muy importantes. Lamentablemente los piratas informáticos tienen varias posibilidades para explotar cualquier error que se cometa en la implementación de esta funcionalidad. Aún cuando no hubiera ningún error en la subida de archivos propiamente dicha, otras vunerabilidades en la aplicación perimitirán subir y aprovechar archivos peligrosos. 
 

VULNERABILIDADES DE APLICACIONES WEB: ESCRITURA DE ARCHIVOS

23.01.2018 11:31
 
Ya vimos esta vulnerabilidad cuando escribimos sobre INYECCIÓN ESTÁTICA DE CÓDIGO (geoestrategia.webnode.es/news/vulnerabilidades-de-aplicaciones-web-inyeccion-estatica-de-codigo/) aunque la habíamos presentado como una forma de inyección de código PHP. A modo de repaso y con una variante que pretende llamar la atención de los desarrolldores para que no cometan un error que podría ser fatal, volvemos a tocar el tema.
 
El archivo "escribe.php" es el siguiente:
 
<!DOCTYPE html>
<html>
<head>
  <title>Vulnerabilidad de escritura de archivos</title>
</head>
 
<body>
    <p><form action="escribe.php" method="get">
    Texto que desea escribir :<input type="text" name="texto" value="">
    <input type="submit">
    </form>
    <br />
 
<?php 
error_reporting(0);
 
$archivo = 'escrito.txt'; $contenido = $_GET['texto'];
if
(!$handle = fopen($archivo, 'a')){
print
"No se puede abrir ($archivo)";
exit
; } $s=fwrite($handle, $contenido);
echo
"Número de caracteres escritos ".$s."<br>";
if 
($s>0){
echo
"Escribió exitosamente<br>"; }
else
{
echo
"No se pudo escribir";
 } 
?> 
 
<br /><br />
</body>
</html>
 
Escribamos lo siguiente en la barra del navegador:
 
https://127.0.0.1/escribir%20archivo/escribe.php?fw=<%3Fphp+phpinfo%28%29+%3F>
 
Nótese que estamos escribiendo código PHP a un archivo de texto. Sabemos que la sentencia "include" incluye y evalúa el archivo especificado. Lo que a veces se ignora que para que el código sea evaluado, no es necesario que el archivo incluido sea .php. De hecho el código PHP será ejecutado aunque el archivo "escrito.txt" ya contenga texto (veáse que hemos escrito el código, no lo hemos sobrescrito). 
 
Supongamos que el archivo atras.php es vulnerable a la Inclusión Local de Archivos: 
 
<?php
   if ( isset( $_GET['color'] ) ) {
      include( $_GET['color'] . '.txt' );
   }
?>
 
escribiendo lo siguiente en la barra de direcciones del navegador EL CÓDIGO PHP DE ARCHIVO DE TEXTO SERÁ EVALUADO, POR ENDE EJECUTADO:
 
https://127.0.0.1/lfi/atras.php?color=C:\xampp\htdocs\escribir%20archivo\escrito
 
proporcionando al pirata informático información de provecho para escalar su ataque.
 

LLUEVEN ALERTAS SOBRE EL ESTADO DE LA DEFENSA BRITÁNICA

22.01.2018 09:24
 
El estado de la Defensa británica se complica día a día. El portaaviones HMS Queen Elizabeth se prepara para lograr cierto grado de operatividad inicial pero muchos advierten sobre los riesgos que eso conlleva. Tanto el programa de los nuevos portaaviones de la Royal Navy (RN) como el de adquisición de los F-35 exceden lo inicialmente presupuestado, con los aviones constituyendo un problema adicional tras la caída de la libra frente al dolar después del Brexit británico.
 
La nueva clase de SSBN Dreadnought, la terminación de la retrasadísima Clase Astute que también excedió ampliamente el presupuesto inicial por no hablar del cronograma, la reparación de los destructoress Type 45, la construcción de las fragatas Type 26 y el programa de las fragatas Type 31, la programada adquisición de los P-8 Poseidon, etc., señalan un planificación terrible, si es que hubo alguna planficación seria. Ya se alzan las primeras voces alertando lo que venimos diciendo hace rato: que el Queen Elizabeth no cuenta con una escolta que pueda garantizar su despliegue en un conflicto mayor.
 
En ese contexto los números de las finanzas de la Defensa no cierran y el gobierno de Theresa May prepara nuevos recortes de personal y armamento: está considerando retrasar una modernización de tanques y vehículos blindados y reducir el número de los nuevos tanques ligeros Ajax (ya el sólo hecho de que se los denomine "tanques" es significativo). Londres considera fusionar unidades de los Royal Marines con tropas paracaidistas, reducir el número de marineros (que ya de por sí no alcanzan para tripular todos los buques de la Royal navy) y desprenderse de más naves "viejas", que son las pocas que demostraron valor operativo real. 
 
En el 2015 el Ministerio de Defensa dijo que recortaría su personal civil de 56,860 a 41,000 empleados para el 2020, pero por ahora esa cifra cayó sólo en 170 personas. Mientras tanto corren rumores de drásticas reducciones en el número de efectivos del British Army (Ejército Británico).
 
El panorama mundial es complejo: con las amenazas de Corea del Norte y el crecimiento militar chino, la región de Asia-Pacífico se convirtió en un hervidero y la Marina Real tiene dos fragatas tipo 23 comprometidas en mantener la presencia militar en la región. La RN también está comprometida en mantener su presencia en el Golfo Pérsico, principalmente con cazaminas, aunque en teoría también mantiene ahí un submarino de ataque en forma permanente.
 
Finalmente está la cuestión rusa y el resurgimiento del imperialismo de histórico de ese país. Los rusos están creando una fuerza expedicionaria poderosa y agresiva, están haciendo grandes avances en materia de guerra electrónica y en el campo de la ciberguerra, en cuestión de misiles de todo tipo y hasta en el campo de la robotización. Esa sea probablemente la mayor preocupación real de los británicos en general. El gobierno de Londres es acusado por muchos ciudadanos del Reino Unido de estar al servicio de los intereses que digitan la política estadounidense desde las sombras y no al servicio del pueblo británico.  
 
En este contexto se espera que hoy el Jefe del Estado Mayor General del Ejército Británico, el General Nick Carter, pida fondos de manera pública para poner al British Army en capacidad de hacer frente a la amenza rusa. Pedir puede pedirlos, el problema es que no hay de dónde sacarlos.
 

VULNERABILIDADES DE APLICACIONES WEB: DESCARGA ARBITRARIA DE ARCHIVOS

22.01.2018 07:59
 
Como la Descarga Arbitraria de Archivos permite a los piratas informáticos hacerse del código fuente de, por ejemplo, archivos.php, algunos consideran esta vulnerabilidad como un caso de Inclusión Local de Archivos mientras que otros la clasifican como un error de programación independiente de la misma.
 
Ilustremos con un ejemplo:
 
<?php
 
$archivo = $_GET['archivo'];
 
if (file_exists($archivo)) {
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="'.basename
 
($archivo).'"');
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . filesize($archivo));
    readfile($archivo);
    exit;
}
?>
 
Como el usuario puede elegir descargar cualquier archivo, el pirata informático puede hacerse de código fuente que le será muy útil para escalar su ataque.
 
https://127.0.0.1/directorio/descargas.php?archivo=principal.php
 
Damos un ejemplo MUY SIMPLE de cómo resolver la vulnerabilidad. Sugerimos al lector tomarlo como un mero bosquejo:
 
<?php
 
$archivo = $_GET['archivo'];
 
if (($archivo == 'uno.php') || ($archivo == 'dos.php')){
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="'.basename
 
($archivo).'"');
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . filesize($archivo));
    readfile($archivo);
    exit;
}
?>
 
Como se puede apreciar, hemos recurrido a una lista blanca. 
 

LA EMPRESA: LA COMUNICACIÓN CON EL EXTERIOR

19.01.2018 20:25
 
La comunicación que debe tener toda empresa con el exterior también es vital para su buen funcionamiento ya que el entorno crea una imagen que según sea el caso debemos conservar o mejorar. Este público externo está conformado por sus proveedores, vecinos, clientes, competencia, instituciones y todo aquel que se involucra con la firma de manera indirecta.
 
Una empresa con buena imagen no sólo da un buen nivel de aliento a sus empleados sino que mejora su relación con el exterior y acrecienta la confianza de sus proveedores y la sociedad en general.
 
Los cambios gerenciales y otras modificaciones no deben comunicarse sólo de manera interna sino que también es importante informarlos a los proveedores y otros involucrados. De no hacerlo se generaría cierta inestabilidad e incertidumbre.
 
Es importante que el entorno no sólo conozca a la empresa por los productos que ofrece, también debe conocer los valores del equipo que trabaja detrás y cómo influyen éstos en la sociedad. Mantener informado al entorno y darse a conocer también genera ganancia de tiempo y debe verse como una inversión que bien valen la pena.
 
Artículos relacionados:
 

VULNERABILIDADES DE APLICACIONES WEB: LA INCLUSIÓN LOCAL DE ARCHIVOS POR MEDIO DE COOKIES

19.01.2018 09:31
Algo que el desarrolllador podría no tener en cuenta es este caso un tanto especial de inclusión local de archivos, donde el nombre del archivo a incluir queda guardado en una cookie. Veamos el archivo "adelante.html", donde el usuario elige en qué idioma quiere manejarse dentro de la aplicación:
 
<html>
<form action="atras.php" method="get">
   <select name="idioma">
      <option value="castellano">Castellano</option>
      <option value="quechua">Quechua</option>
   </select>
   <input type="submit">
</form>
</html>
 
Siendo "atras.php" como sigue:
 
<?php
$idioma = $_GET['idioma'];
setcookie('idioma',$idioma,time() + (86400 * 7), "/", null, null, true);
header("location: final.php");
?>
 
El idioma elegido por el usuario se guarda como dato en una cookie y de acuerdo a él se incluirá castellano.php o quechua.php, como vemos en el archivo "final.php":
 
<?php
if ( isset( $_COOKIE['idioma'] ) ) {
   include( $_COOKIE['idioma'] . '.php' );
}
?>
 
Sin embargo si un pirata informático cliqueara en "Inspeccionar elemento" en "adelante.html" y cambiara "castellano" por "/subdirectorio/shell/" (suponiendo que en el directorio de estos archivos existiera "/subdirectorio/shell.php") y luego cliqueara en enviar, se ejecutaría el código de "shell.php".
 
 
El archivo "final.php" debió ser así:
 
<?php  
$idiomas = array('castellano', 'quechua');  
if(isset($_COOKIE['idioma']) and in_array($_COOKIE['idioma'], $idiomas)) {  
  include $idiomas[array_search($_COOKIE['idioma'], $idiomas)] . '.php';  
} else  
  die('No se ha especificado la página a mostrar o no existe en el servidor');  
?>
 
Además sugerimos no usar nombres tan obvios para las cookies y encriptar fuertemente sus valores.
 

VULNERABILIDADES DE APLICACIONES WEB: OTRO JUEGO DE VERANO (II - LA RESPUESTA)

18.01.2018 16:26
 
Damos la respuesta a nuestro juego de ayer:
 
El archivo adelante.html contiene un comentario sopechoso:
 
<!-- Cambiar primero acceso del tráfico invasivo previo luego desaparecerán los 1142 archivos excedentes alivianando las 102 sobrecargas semanales gastándose US$ 2454 menos cada mes ---- administrador -->
 
Para descubrir su significado debemos recurrir a nuestros conocimientos de esteganografía. Las técnicas de esteganografía nos permiten ocultar mensajes dentro de otros, de modo que no se perciba su existencia. En nuestro caso, si tomamos cada tercer carácter del texto obtendremos los siguiente:
 
miclaveess4ccis2bms$5nds-m, es decir:
 
mi clave es s4ccis2bms$5nds-m
 
Acá se nos presenta la primera dificultad. Vemos que en "atras.php" la contraseña está encriptada con un algoritmo sha512 y que si creamos el hash de "s4ccis2bms$5nds-m" con dicho algoritmo, el mismo no coincide con el hash de "atras.php". De hecho parte del hash ni siquiera aparece en la pantalla. No nos ahoguemos en un vaso de agua. Si copiamos de una sola vez el renglón inmediatamente por arriba del del hash, el del hash y el inmediatamente inferior y los pegamos en un editor de texto, el hash aprecerá completo.
 
Lo hacemos y no coincide con el que resulta de encriptar "s4ccis2bms$5nds-m".
 
¿Será que la palabra "administrador" es sólo parte de la firma y no del mensaje que contiene la contraseña? ¿Qué hay de los cuatro guiones que la preceden?  
 
Encriptamos "s4ccis2bms$5nds" y vemos que no coincide con el hash de "atrás.php". Volvemos a probar con "s4ccis2bms$5nds-" y ¡resuelto!
 
Estamos a su disposición en nuestra dirección de contacto: luis_lavric@hotmail.com.¡Gracias! 
 
Artículo relacionado:
 

VULNERABILIDADES DE APLICACIONES WEB: CÓMO DESHABILITAR "FUNCIONES PELIGROSAS" DE PHP

18.01.2018 13:19
 
En nuestro último artículo sobre inclusión local de archivos dijimos que además de las que ya habíamos mencionado había otras funciones vulnerables a este tipo de ataque. Veamos el siguiente archivo PHP:
 
<?php
highlight_file($_GET['file']);
?>
 
La función highlight_file no es de las más usuales. Imprime o devuelve una versión con la sintaxis remarcada del código contenido en el fichero dado por filename usando los colores definidos en el remarcador de sintaxis interno de PHP. (de php.net/manual/es/function.highlight-file.php)
 
Si se permite que el usuario ingrese como input cualquier nombre de archivo, estará en capacidad de llevar a cabo un ataque de inclusión local de archivos.
 
Es necesario preguntarse si realmente es necesario incluir esta función en una aplicación. Nos parece de mucha más utilidad para el desarrollador que para un usuario común, por lo que a nuestro entender no debería llegar al servidor comercial. Si es inevitable emplearla entonces debería ser usada así: 
 
<?php
highlight_file('archivo.php');
?>
 
El administrador del servidor web cuenta con la posibilidad de deshabilitar y ésta y otras funciones en el archivo php.ini, impidiendo su ejecución, pero deberá tener presente que el archivo que contenga la función deshabilitada no se ejecutará o su ejecución se detendrá y se mostrará un mensaje de error con una advertencia sobre la razón de la falta de ejecución.
 
Para deshabilitar funciones se abre php.ini y en 
 
disable_functions=
 
se agrega las funciones que se desea deshabilitar:
 
disable_functions=highlight_file,system
 
Como se ve, esta medida también es útil para prevenir la inyección de comandos.
 
Más que de funciones peligrosas de PHP habría que hablar del uso peligroso de algunas funciones.
 
Artículos relacionados:
 

 

LA EMPRESA: UN CASO CONCRETO DE CANALIZACIÓN DE QUEJAS

17.01.2018 20:30
 
Anteriormente hemos dicho que necesitamos de personal preparado o capacitado para resolver diferentes tipos de situaciones que se presentan en la actividad diaria de un negocio. Sobre esto les puedo comentar algunos procedimientos que establecimos como respuesta inmediata en la empresa en la que trabajo y alguna situación generada por esto:
 
Ante la insatisfacción por alguno de los productos que ofrecemos, los mismos se pueden cambiar, previa aprobación de control de calidad.
 
Si el cliente hace uso del Libro de Reclamaciones, se les responde vía notarial, manifestándole las disculpas del caso y se le envía un vale de cortesía.  De esta manera lo invitamos para que vuelva. Internamente se procede a averiguar el motivo que generó el reclamo a fin de corregir lo que haga falta.
 
Este hecho ocurrió hace un tiempo:
 
El área de caja recibió un reclamo debido a que un cliente solicitó pagar su cuenta mediante el uso de un POS. La cajera pasó la tarjeta hasta en dos ocasiones pero la misma no generaba cobro alguno, por lo que intentó una tercera vez y es cuando el POS funcionó. El cliente quedó con muchas dudas porque pensó que se le había cobrado dos veces más. Además perdió tiempo al resolver permanecer en el establecimiento para despejar sus dudas y efectuar el reclamo.
 
El cliente manifestó su molestia utilizando el libro de  reclamaciones ya que el inconveniente no pudo ser resuelto de manera inmediata.  Internamente, el área de Contabilidad pudo comprobar que sólo se le cobró una vez y después se procedió a enviar al cliente una carta de disculpas  y la explicación del caso, adjuntándose el movimiento de los cobros del día. Además se le hizo saber que la lentitud del sistema era por problemas técnicos  generados por el mismo operador de POS. A su vez nuestra empresa también hizo el reclamo a este operador.
 
Artículos relacionados:
 
<< 115 | 116 | 117 | 118 | 119 >>

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