ExploitExploit (del inglés to exploit, explotar, aprovechar) es el nombre con el que se identifica un programa informático malicioso, o parte del programa, que trata de forzar alguna deficiencia o vulnerabilidad de otro programa (llamadas bugs). El fin puede ser la destrucción o inhabilitación del sistema atacado, aunque normalmente se trata de violar las medidas de seguridad para poder acceder al mismo de forma no autorizada y emplearlo en beneficio propio o como origen de otros ataques a terceros.
Un "exploit" es usado normalmente para explotar una vulnerabilidad en un sistema y acceder a él, lo que es llamado como "rootear".
Los exploits se pueden caracterizar según las categorías de vulnerabilidades utilizadas:
• Vulnerabilidades de desbordamiento de buffer.
• Vulnerabilidades de condición de carrera (race condition).
• Vulnerabilidades de error de formato de cadena (format string bugs).
• Vulnerabilidades de Cross Site Scripting (XSS).
• Vulnerabilidades de Inyección SQL.
• Vulnerabilidades de Inyección de Caracteres (CRLF).
• Vulnerabilidades de denegación del servicio
• Vulnerabilidades de Inyección múltiple HTML (Multiple HTML Injection).
• Vulnerabilidades de ventanas enganosas o mixtificación de ventanas (Window Spoofing).
Desbordamiento de búferEn seguridad informática y programación, un desbordamiento de buffer (del inglés buffer overflow o buffer overrun) es un error de software que se produce cuando se copia una cantidad de datos sobre un área que no es lo suficientemente grande para contenerlos, sobrescribiendo de esta manera otras zonas de memoria. Como consecuencia, se producirá una excepción del acceso a memoria seguido de la terminación del programa o, si se trata de un usuario obrando con malas intenciones, la vulnerabilidad de la seguridad.
En algunas ocasiones eso puede suponer la posibilidad de alterar el flujo del programa pudiendo hacer que éste realice operaciones no previstas. Esto es posible dado que en las arquitecturas comunes de computadoras, la memoria no tiene separación entre la dedicada a datos y a programa.
Si el programa que tiene el error en cuestión tiene privilegios especiales se convierte además en un fallo de seguridad. El código copiado especialmente preparado para obtener los privilegios del programa atacado se llama shellcode.
Descripción técnica
Un desbordamiento de buffer ocurre cuando los datos que se escriben en un buffer corrompen aquellos datos en direcciones de memoria adyacentes a los destinados para el buffer, debido a una falta de validación de los datos de entrada. Esto se da comúnmente al copiar cadenas de caracteres de un buffer a otro.
Condición de carrera
En electrónica y en programación concurrente, se conoce como condición de carrera (en inglés race condition), aunque sería mejor hablar de estado de carrera (como en "estado de espera"), al error que se produce en programas o circuitos lógicos cuando no han sido diseñados adecuadamente para su ejecución simultánea con otros.
Un ejemplo típico es el interbloqueo que se produce cuando dos procesos están esperando a que el otro realice una acción. Como los dos están esperando, ninguno llega a realizar la acción que el otro espera.
Este tipo de errores de programación pueden ser aprovechados por exploits locales para vulnerar los sistemas.
XSSXSS es un ataque basado en la explotación de vulnerabilidades del sistema de validación de HTML incrustado. Su nombre, del inglés "Cross Site Scripting", y renombrado XSS para que no sea confundido con las hojas de estilo en cascada (CSS), originalmente abarcaba cualquier ataque que permitiera ejecutar código de "scripting", como VBScript o javascript, en el contexto de otro dominio. Recientemente se acostumbra a llamar a los ataques de XSS "HTML Injection", sin embargo el término correcto es XSS. Estos errores se pueden encontrar en cualquier aplicación HTML, no se limita a sitios web, ya que puede haber aplicaciones locales vulnerables a XSS, o incluso el navegador en sí. El problema está en que normalmente no se validan correctamente los datos de entrada que son usados en cierta aplicación. Esta vulnerabilidad puede estar presente de forma directa (foros, mensajes de error, comentarios) o indirecta (redirecciones, framesets). Cada una se trata de forma diferente.
Directa: Este tipo de XSS es el que normalmente es censurado; así que es muy poco común que puedas usar tags como <script> o <iframe>
Indirecta: Esta es un tipo de vulnerabilidad, muy común y muy poco explotada. Consiste en modificar valores que la aplicación web utiliza para pasar variables entre dos páginas, sin usar sesiones.
IndirectaSucede cuando hay un mensaje o una ruta en la URL del navegador o en una cookie. Para saber el contenido de una cookie, sin usar ningún tipo de iecv o addin para tu navegador, puedes usar el siguiente script de jasildbg. Sólo colócalo en la barra de direcciones, y presiona Enter.
javascript:for(var g in document.cookie.split(';'))void(prompt("Valor de cookie "+document.cookie.split(';')[g].split('=')[0],document.cookie.split(';')[g].split('=')[1]));alert("Cookies:\n"+document.cookie.replace(/;/,"\r\n"));
Una vez dentro se puede modificar la cookie a tu antojo. Si pones cancelar la cookie se borrará.
¿Qué podemos ver con este ejemplo? Que podemos meter comandos javascript solo modificando una URL.
Usando FrameSets
Regresemos al ejemplo del frameset, que según la página que coloques te crea un frame a esa página. ¿Qué pasara si pones en esa URL?
javascript:while(1)alert("Te estoy inundando de mensajes!");
Y el enlace lo pone un intruso hacia un foro. Un navegador incauto, va a verlo y dirá, bueno, es del mismo dominio, no puede ser nada malo.. y de resultado tendrá un loop infinito.
Hasta ahí llegan los newbies. Pero vamos a ponernos en la piel de un experto. Se trata de colocar un script que tome tu cookie, y mande un mp al administrador, o incluso, que borre todos los mensajes de un foro.
El robo de cookies es lo más básico, y tiene como objetivo robar la cookie. ¿Y eso de qué sirve? Tengo el PHPSESSID, y si el usuario cierra sesión no sirve de nada.
Cierto, pero con el uso de la librería cURL un usuario malintencionado, podría al recibir tu cookie, entrar a la página, y dejarla en caché, para que el atacante cuando quiera, pueda entrar como tú, sin siquiera necesitar tu contraseña.
Otro uso común para estas vulnerabilidades es lograr hacer phishing; o colocar un exploit.
Quiere ello decir que tú ves la barra de direcciones, y ves que estás en una página, pero realmente estás en otra. Introduces tu contraseña y la fastidiaste.
Lo peor son los sitios de descarga, que colocan en la misma URL el sitio de objetivo. Esas páginas web son vulnerables a ataques XSS indirectos. O sea que un intruso puede colocar una imagen con enlace al sitio malicioso, y se ejecuta, sin que el usuario lo sepa.
Mensaje personalizado
La técnica sólo funciona con imágenes:
error.php?error=Usuario%20Invalido
Esa página es vulnerable a XSS indirecto.
Un <script> que cree otra sesión bajo otro usuario y tu sesión actual la mande al atacante (lo explicado de cURL más arriba), puede causar estragos.
Este código (muy peligroso) borra todo el contenido de la página en cuestión, y escribe otra cosa:
<script>
document.documentElement.innerHTML="NADA";
</script>
DirectaFunciona localizando puntos débiles en la programación de los filtros. Así que si, por ejemplo, logran quitar los <iframe>, <script>, el atacante siempre puede poner un <div> malicioso, o incluso un <u> o <s>. Tags que casi siempre están permitidos.
Ejemplos de Scripts donde no son comunes de encontrar
<BR SIZE="&{alert('XSS')}">
<FK STYLE="behavior: url(
http://yoursite/xss.htc);">
<DIV STYLE="background-image: url(javascript:alert('XSS'))">
Usar estilos es increíblemente fácil, y lo malo es que muchos filtros son vulnerables. Se puede crear un DIV con background-image: url(javascript:eval(this.fu)) como estilo y añadir al DIV un campo llamado fu que contenga el código a ejecutar, como por ejemplo alert('Hola'):
<div fu="alert('Hola');" STYLE="background-image: url(javascript:eval(this.fu))">
AjaxÉste es un tipo de XSS no tan conocido, pero peligroso. Se basa en usar cualquier tipo de vulnerabilidad para introducir un objeto XMLHTTP y usarlo para enviar contenido POST, GET, sin conocimiento del usuario.
El siguiente script de ejemplo obtiene el valor de las cabeceras de autenticación de un sistema basado en Autenticación Básica (Basic Auth). Sólo falta decodificarlo, pero es más fácil mandarlo codificado al registro de contraseñas. La codificación es base64.
Script para obtener credenciales en tipo BASIC
Esta tecnica también es llamada XST Cross Site Tracing XST
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
// para firefox, es: var xmlhttp = new XMLHttpRequest();
xmlhttp.open("TRACE","./",false);
xmlhttp.send(null);
str1=xmlhttp.responseText;
splitString = str1.split("Authorization: Basic ");
str2=splitString[1];
str3=str2.match(/.*/)[0];
alert(str3);
Por cuestiones de seguridad.. Firefox y IExplorer 6.2+ no permiten usar el metodo TRACE.
log.php para registrar cookies
<?php
$archivo = fopen('log2.htm','a');
$cookie = $_GET['c'];
$usuario = $_GET['id'];
$ip = getenv ('REMOTE_ADDR');
$re = $HTTPREFERRER;
$fecha=date("j F, Y, g:i a");
fwrite($archivo, '<hr>USUARIO Y PASSWORD: '.htmlentities(base64_decode($usuario)));
fwrite($archivo, '<br>Cookie: '.htmlentities($cookie).'<br>Pagina: '.htmlentities($re));
fwrite($archivo, '<br> IP: ' .$ip. '<br> Fecha y Hora: ' .$fecha. '</hr>');
fclose($archivo);
?>
Inyección SQLInyección SQL es una vulnerabilidad informática en el nivel de la validación de las entradas a la base de datos de una aplicación. El origen es el filtrado incorrecto de las variables utilizadas en las partes del programa con código SQL. Es, de hecho, un error de una clase más general de vulnerabilidades que puede ocurrir en cualquier lenguaje de programación o de script que esté incrustado dentro de otro.
Una inyección SQL sucede cuando se inserta o "inyecta" un código SQL "invasor" dentro de otro código SQL para alterar su funcionamiento normal, y hacer que se ejecute maliciosamente el código "invasor" en la base de datos.
La inyección SQL es un problema de seguridad informática que debe ser tomado en cuenta por el programador para prevenirlo. Un programa hecho con descuido, displicencia, o con ignorancia sobre el problema, podrá ser vulnerable y la seguridad del sistema puede quedar ciertamente comprometida. Esto puede suceder tanto en programas corriendo en computadores de escritorio, como en páginas Web, ya que éstas pueden funcionar mediante programas ejecutándose en el servidor que las aloja.
La vulnerabilidad puede ocurrir cuando un programa "arma" descuidadamente una sentencia SQL, con parámetros dados por el usuario, para luego hacer una consulta a una base de datos. Dentro de los parámetros dados por el usuario podría venir el código SQL inyectado.
Al ejecutarse esa consulta por la base de datos, el código SQL inyectado también se ejecutará y podría hacer un sinnúmero de cosas, como insertar registros, modificar o eliminar datos, autorizar accesos e, incluso, ejecutar código malicioso en el computador.
Asumiendo que el siguiente código está en una aplicación web y que existe un parámetro "nombreUsuario" que contiene el nombre de usuario que nosotros le demos, la inyección SQL es posible:
consulta := "SELECT * FROM usuarios WHERE nombre = '"
+ nombreUsuario + "';"
Si el usuario escribe su nombre, digamos "Alicia", nada anormal sucedería, la aplicación generaría una sentencia SQL similar a la siguiente, que es perfectamente correcta, en donde se seleccionaría al usuario "Alicia":
SELECT * FROM usuarios WHERE nombre = '
Alicia';
Pero si un usuario malintencionado escribe como nombre de usuario: "
Alicia';
DROP TABLE usuarios; SELECT * FROM datos WHERE nombre LIKE '%", se generaría la siguiente consulta SQL, (el color verde es lo que pretende el programador, el azul es el dato, y el rojo, el código SQL inyectado):
SELECT * FROM usuarios WHERE nombre = '
Alicia';
DROP TABLE usuarios;
SELECT * FROM datos WHERE nombre LIKE '%';
La base de datos ejecutaría la consulta en orden, seleccionaría el usuario 'Alicia', borraría la tabla 'usuarios' y seleccionaría datos que quizá no están disponibles para los usuarios web comunes. En resumen, cualquier dato de la base de datos está disponible para ser leído o modificado por un usuario malintencionado.
Nótese por qué se llama "Inyección" SQL. Si observamos el código malicioso, de color rojo, vemos que está en el medio del código bueno, el verde. El código rojo ha sido "inyectado" dentro del verde.
CRLFEn informática, CRLF se refiere a la combinación de dos códigos de control: CR (retorno de carro) y LF (salto de línea), uno detrás del otro; normalmente con el objetivo de crear una nueva línea.
Historia
El origen del par CR-LF está en las máquinas de escribir, en donde, al acabar de escribir una línea, hacen falta dos movimientos para pasar a la siguiente:
El retorno de carro (CR), que consiste en empujar el carro (el cilindro horizontal donde se apoya el papel) hacia la izquierda.
El salto de línea (LF), que consiste en girar el carro un poco para que el papel se desplace una línea.
Estas dos acciones se hacen seguidas mediante una sola palanca.
Las máquinas de escribir eléctricas cambiaron esta palanca por una tecla que hace las dos funciones, a la que llamaron sólo "Return" y etiquetaron con ↵. Los primeros teclados de ordenador también incluyeron esta tecla, y actualmente está en todos los teclados.
Por analogía con la máquina de escribir, se creyó que en informática también iba bien representar una nueva línea mediante CRLF, aunque más adelante se comprobó que era mejor simplificarlo. Véase nueva línea para más detalles.
Usos
Hoy en día, los sistemas operativos DOS y Microsoft Windows siguen usando CRLF como marcador de nueva línea, mientras que el resto usan códigos más simples.
Algunos de los primeros protocolos de red, que transmitían principalmente texto, establecieron que el terminador de línea debía ser CRLF y no otro. Son ejemplos HTTP, FTP, IRC, o SMTP, que marca el final del mensaje mediante CRLF . CRLF
Representación
'CRLF es simplemente CR seguido de LF, por tanto su codificación es en hexadecimal 0D 0A, o 13 10 en decimal.
Hay que destacar que esto son dos códigos, y los programas que usan CRLF han de tener un comportamiento definido respecto a qué pasa cuando se usa sólo un CR o sólo un LF. Por ejemplo, el protocolo HTTP define que cada línea de la cabecera ha de acabar en CRLF, pero que ni CR ni LF pueden aparecer entre medio cuando se pide una URI.
Ataque de denegación de servicioEn seguridad informática, un ataque de denegación de servicio, también llamado ataque DoS (de las siglas en inglés Denial of Service), es un ataque a un sistema de ordenadores o red que causa que un servicio o recurso sea inaccesible a los usuarios legítimos. Normalmente provoca la pérdida de la conectividad de la red por el consumo del ancho de banda de la red de la víctima o sobrecarga de los recursos computacionales del sistema de la víctima.
Se genera mediante la saturación de los puertos con flujo de información, haciendo que el servidor se sobrecargue y no pueda seguir prestando servicios, por eso se le dice "denegación", pues hace que el servidor no de abasto a la cantidad de usuarios. Esta técnica es usada por los llamados crackers para dejar fuera de servicio a servidores objetivo.
El llamado DDoS (siglas en inglés de Distributed Denial of Service, denegación de servicio distribuida) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos. El invasor consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen del flood o saturación de información, pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido sofisticándose hasta el punto de otorgar poder de causar daños serios a personas con escaso conocimiento técnico.
En ocasiones, esta herramienta ha sido utilizada como un notable método para comprobar la capacidad de tráfico que un ordenador puede soportar sin volverse inestable y perjudicar los servicios que desempeña. Un administrador de redes puede así conocer la capacidad real de cada máquina.
Métodos de ataque
Un ataque de "Denegación de servicio" previene el uso legítimo de los usuarios al usar un servicio de red. El ataque se puede dar de muchas formas, como por ejemplo:
Inundación SYN (SYN Floods)
La inundación SYN envía un flujo de paquetes TCP/SYN, muchas veces con la dirección de origen falsificada. Cada uno de los paquetes recibidos es tratado por el destino como una petición de conexión, causando que el servidor intente establecer una conexión al responder con un paquete TCP/SYN-ACK y esperando el paquete de respuesta TCP/ACK (Parte del proceso de establecimiento de conexión TCP de 3 vías). Sin embargo, debido a que la dirección de origen es falsa o la dirección IP real no ha solicitado la conexión, nunca llega la respuesta. Estas conexiones a medias consumen recursos en el servidor y limitan el número de conexiones que se pueden hacer, reduciendo la disponibilidad del servidor para responder peticiones legítimas de conexión.
Ataque LAND (LAND attack)
Un ataque LAND se realiza al enviar un paquete TCP/SYN falsificado con la dirección del servidor objetivo como si fuera la dirección origen y la dirección destino a la vez. Esto causa que el servidor se responda a sí mismo continuamente y al final falle.
Inundación ICMP (ICMP floods)
Es una técnica DoS que pretender agota el ancho de banda de la víctima. Consiste en enviar de forma continuada un número elevado de paquetes ICMP echo request (ping) de tamaño considerable a la víctima, de forma que esta ha de responder con paquetes ICMP echo reply (pong) lo que supone una sobrecarga tanto en la red como en el sistema de la víctima. Dependiendo de la relación entre capacidad de procesamiento de la víctima y atacante, el grado de sobrecarga varía, es decir, si un atacante tiene una capacidad mucho mayor, la víctima no puede manejar el tráfico generado.
Existe una variante denominada smurf que amplifica considerablemente los efectos de un ataque ICMP. En el smurf el atacante dirige paquetes ICMP echo request a una dirección IP de broadcast10.
Existen tres partes en un ataque smurf: El atacante, el intermediario y la víctima (comprobaremos que el intermediario también puede ser víctima).
Cuando el atacante genera el paquete ICMP echo request, este es dirigido a una dirección IP de broadcast, pero la dirección origen del paquete IP la cambia por la dirección de la víctima (IP spoofing), de manera que todas las máquinas intermediarias (máquinas pertenecientes a la red donde se envió el paquete) responden con ICMP echo reply a la víctima. Como se dijo anteriormente, los intermediarios también sufren los mismos problemas que las propias víctimas.
Inundación UDP (UDP floods)
Básicamente este ataque consiste en generar grandes cantidades de paquetes UDP contra la víctima elegida. Debido a la naturaleza sin conexión del protocolo UDP, este tipo de ataques suele venir acompañado de IP spoofing6.
Es usual dirigir este ataque contra máquinas que ejecutan el servicio echo8 de forma que se generan mensajes echo de un elevado tamaño.
Teardrop attack
Inundaciones a nivel de aplicación
Nukes
Sacado de WikipediaComentarios...dudas..... Acudir a donde el doctor GOOGLE
Aportes para complementar este manual...bienvenidos sean.
He copilado este manual con informacion extraida de Wikipedia.
Autor