Luego de haber resuelto un problema con el encargado de CFT Lota Arauco, y luego de que éste me comentara que alguien quería lucrar con la información que yo publicaba en mi blog, he decidido hacer publico el nombre y el correo de la persona. Anoche recibí un correo con una amenaza de dicho personaje, para que retirara esa información de mi blog. Quiero compartir el correo con ustedes:

Buenas Fernando:

Te comunico que nuestra empresa se dedica a revisar webs de todo el mundo para ofrecer soluciones informaticas ya sea gratis o de pago. Solicito que en tu web te dirijas a mi persona con respeto y no con esa ironia, nombrandome como personaje. Para evitar problemas legales o de otro tipo, te solicito explicitamente que retires mi correo electronico y mi nombre de tu blog. Ya que mi correo electronico es propiedad privada, y no puede andar publicado en webs.

Sin nada mas que decir, espero que quites mi NOMBRE y CORREO ELECTRONICO de tu blog.

Saludos.

–
Joan Calderón.
Cisco CCNA Certified
Cisco CCNP Certified
Cisco Ethical Hacker
Certificado Desarrollador 5 estrellas DCE Microsoft.
C.E.O
[Q]Quanticc

Lo encuentro insolito. Esto me recuerdo a la propuesta de Ley de mordaza digital que están promoviendo algunos senadores en Chile.

Compartir/Guardar

trickle is a portable lightweight userspace bandwidth shaper. It can run in collaborative mode (together with trickled) or in stand alone mode.

Con esta herramienta podemos limitar la velocidad de subida y bajada de cualquier aplicación. Como dice en la descripción, puede trabajar “solo” y tambien como demonio. Si ejecutamos el demonio, todas las aplicaciones que se corran usando trickle (sin especificar subida ni bajada) correrán con el límite señalado. Por ejemplo, si corremos el demonio con los parametros:

trickled -d 150 -u 20
Establecemos que la velocidad de bajada y subida será de 150 y 20 Kb/s, respectivamente. Desde ahora, todas las aplicaciones corridas con trickle tendran esa configuración, por ejemplo:

trickle axel http://domain.com/download.tbz2
Limitará la bajada a 150kb/s.

Podemos pasarle parametros a trickle directamente, por ejemplo trickle -d 100 -u 100 wget http://domain.com/file.tbz2, de esta forma se limitara a wget solo descargar a 100kb/s.

Aunque wget tiene la opción –limit-rate que nos permite limitar el RATE, y –max-speed que nos permite limitar la máxima velocidad en axel, trickle nos puede servir para limitar el ancho de banda de cualquier aplicación.

Compartir/Guardar

Los datos que podemos ver son el rut de la persona, fecha de nacimiento, nombre completo, dirección, celular, nombre del “apoderado”, numero de telefono del apoderado, rut del apoderado, dirección del apoderado, entre otros.

Esto es un atentado contra la privacidad de las personas.

EDITADO (26 de Agosto):

El archivo que contenia la informacion personal de todos los alumnos, y ademas informacion de todos los estudios y carreras, tanto como horarios, horas asistidas, etc correspondia a un “dump” de una base de datos ubicado en:
http://cftlotarauco.cl/cas/devel/database/old_migracion/registro_data_dump_explotacion.sql
El cual ya ha sido removido.
Yo no accedí a ningun sistema de información, simplemente a una URL publica, sin ningún tipo de restricción ni protección.

Me contactó el responsable actual del sitio web y me explicó que estos registros pertenecian a una base de datos antigua (hace un par de años) explicado la negligencia que cometió el encargado anterior y comentarme que lo había solucionado. Tambien me contó que una persona había intentado lucrar con la información de mi blog y que gracias a ello se dió cuenta que había información sensible expuesta en el sitio web.

Me parece increible que exista gente que quiera lucrar con el trabajo de otros, este personaje, quien buscaba el lucro mediante mi post, se llama Joan Calderon y su correo electrónico es joan.calderon@quanti.cc

Compartir/Guardar

Por lo general son descuidados y permiten la inyección de código html o javascript en los campos “buscar” de los buscadores de cada sitio. Por ejemplo en el sitio web del Grupo Santander:

Si inyectamos código HTML y JavaScript para desplegar una alerta, como <script>alert(/it sucks/)</script> o similar, veremos como el navegador interpretará el código.

En este caso no existe el riesgo del robo de identidad pero si existe la posibilidad de realizar phishing usando la confianza del dominio “Santander.com“

Compartir/Guardar

Para variar, el bug se encuentra en el buscador, donde nos da la autoridad para inyectar código html y código javascript para ser ejecutado en el navegador del cliente:

La vulnerabilidad fue alertada vía twitter, ya que no logré encontrar en ese entonces una dirección de correo.

Esta vulnerabilidad fue descubierta el 5 de Agosto y no descarto que alguien la haya encontrado antes.

La URL vulnerables es:

http://pcfactory.cl/?buscar=\%22%3Etoe%3Cscript%3Ealert%28document.cookie%29%3C/script%3E

No está demas decir que los alcances de ésta vulnerabilidad no afectarian a la tienda en si, sólo a sus usuarios ya que podría ser usada para robo y suplantación de identidad (mediante las cookies de un usuario logeado) y ademas podría ser usado para ejecutar código arbitrario y redireccionar a los visitantes a algun sitio maligno.

Compartir/Guardar

el sitio de sym es vulnerable a todo a proposito y les encuentro razón mi casa tiene las puertas abiertas pero si robas pagas.

En fín … Unos dias despues, se contacto conmigo Rodolfo Berrios, diseñador y encargado del sitio web, consultandome por las vulnerabilidades encontradas. Cuando intenté reproducir la vulnerabilidad XSS me encontré con la sorpresa de que ya estaba corregida! Sin embargo, no se corrigió del todo, ya que si bien no me dejaba inyectar código JavaScript, si me dejaba inyectar html

Esto pasa al no controlar los parametros pasados por GET, en este caso los parametros de busqueda, un usuario al buscar algo puede escribir codigo html arbitrario.

La URL vulnerable es:

http://www.sym.cl/busqueda/?palabras=%22%3Eb+<aca codigo html>

El problema ya está reportado y se está esperando una solución.

Compartir/Guardar

mii-tool – view, manipulate media-independent interface status
ethtool – Display or change ethernet card settings

Para modificar la velocidad de transferencia de las tarjetas usamos el siguiente comando:

ethtool eth1 speed 1000 duplex full

Para dejarla a 1Gbps full duplex. Podemos setear la tarjeta a 10, 100 o 1000mbps según su capacidad, tambien decirle si es half o full duplex, activar y desactivar la autonegociación, modiicar el tamaño de los Jumbo Frames, etc.

Para conocer la configuración actual de la tarjeta de red sólo debemos ejecutar ethtool y especificarle el dispositivo:

Compartir/Guardar

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

Con du podemos saber el uso de disco de nuestro sistema y con un pequeño script en bash podemos mejorar la salida de este comando.

ssh 10.0.0.56 -p5022 "df -hPl"|awk -F ' ' '{print $1,$4,$6,$5}' |egrep -v "Avail|Dispo|Use|Use"

Esto nos devuelve en 4 columnas el dispositivo, espacio disponible, punto de montaje y porcentaje usado.

Algo similar a:

/dev/mapper/VolGroup_25980-LogVol1 3.5G / 75%
/dev/sda1 80M /boot 16%
none 16G /dev/shm 0%
/dev/mapper/VolGroup_25980-LogVolHome 30G /home 69%
/dev/mapper/VolGroup_25980-LogVol2 4.6G /tmp 1%
/dev/mapper/VolGroup_25980-LogVol5 6.6G /usr 29%
/dev/mapper/VolGroup_25980-LogVol4 14G /var 87%
/dev/mapper/VolGroup_25980-mysql 7.0G /var/lib/mysql 63%

Mi idea es trabajar con threshold (umbral) y gatillar eventos según el umbral alcanzado. Por ejemplo, con un threshold del 80% asociado al porcentaje utilizado, que envie emails de “advertencias” y con el 90% notificaciones de “criticidad del sistema de archivos”. Lo que querìa lograr era que todos los dias se monitoreen los sistemas de archivos, generando reportes diarios de los sistemas criticos y, semanalmente, un reporte general, donde me muestre detalladamente los “normales”, “advertencias” y los “criticos”. La salida esperada es algo asi:

[+] Server: x.x.x.x (x.hostname)
[-] [Dev:/dev/hda2] [Mount:/] [Free:4.2G] [Used:5%]

[-] [Dev:/dev/hda1] [Mount:/boot] [Free:83M] [Used:11%]

[-] [Dev:/dev/hda3] [Mount:/home] [Free:3.6G] [Used:19%]

[-] [Dev:/dev/hda6] [Mount:/tmp] [Free:1.7G] [Used:1%]

[-] [Dev:/dev/hda5] [Mount:/usr] [Free:8.6G] [Used:3%]

[-] [Dev:/dev/hda7] [Mount:/var] [Free:12G] [Used:21%]

No critical filesystems

[...] cuando no hay sistemas de archivos criticos y,

[+] Server: y.y.y.y (y.hostname)
[-] [Dev:/dev/mapper/VolGroup00-LogVol00] [Mount:/] [Free:16G] [Used:14%]

[-] [Dev:/dev/sda1] [Mount:/boot] [Free:80M] [Used:15%]

[-] [Dev:/dev/shm] [Mount:/dev/shm] [Free:2.0G] [Used:0%]

[-] [Dev:/dev/mapper/VolGroup00-LogVol02] [Mount:/var] [Free:7.4G] [Used:74%]

[-] [Dev:/dev/mapper/VolGroup00-LogVol03] [Mount:/backup] [Free:13G] [Used:66%]

[-] [Dev:/dev/mapper/VolGroup00-LogVol04] [Mount:/home] [Free:6.6G] [Used:93%] [***CRITICAL***]

[-] [Dev:/dev/mapper/VolGroup00-LogVol05] [Mount:/usr/local] [Free:7.3G] [Used:89%] [***WARNING***]

cuando hay criticos y cuando hay emergencias, es decir, cuando se alcanza el umbral del 90% y 80%, respectivamente.

El script que hice es el siguiente:

#/bin/bash -e
warning_threshold="80%"
critical_threshold="90%"

warnings=0;
critical=0;
for host in $(grep -v ^# ips.txt);
do
	critical_count=0;
	hostname=$(echo -n $host|cut -f1 -d ":")
        ip=$(echo -n $host|cut -f2 -d ":")
        port=$(echo -n $host|cut -f3 -d ":")
	echo "\n[+] Server: $ip ($hostname)"
	filesystems=$(ssh $ip -p$port "df -Phl"|egrep -v 'Avail|Dispo|tmpfs|udev|Uso|Use'|awk -F ' ' '{print $6}');
	for FS in $filesystems;
	do
		alert="";
		temp=$(ssh $ip -p$port "df -hPl $FS"|awk -F ' ' '{print $1,$4,$6,$5}' |egrep -v 'Avail|Dispo|Uso|Use');
		dev=$(echo $temp |cut -f1 -d " ");
		mountpoint=$(echo $temp |cut -f3 -d " ");
		size=$(echo $temp |cut -f2 -d " ");
		used=$(echo $temp |cut -f4 -d " ");
		_wthreshold=$(echo -n $warning_threshold |sed 's/%//g');
		_cthreshold=$(echo -n $critical_threshold |sed 's/%//g');
		_used=$(echo -n $used |sed 's/%//g');
		case "$1" in
			weekly)
				if [ $_used -gt $_wthreshold ]; then
                                        alert="[***WARNING***]"; warning=$(expr $warning + 1);
                                fi
				if [ $_used -gt $_cthreshold ]; then
					alert="[***CRITICAL***]"; critical=$(expr $critical + 1);
				fi
				echo "[-] [Dev:$dev] [Mount:$mountpoint] [Free:$size] [Used:$used] $alert";
				echo "";
			;;
			daily)
                                if [ $_used -gt $_cthreshold ]; then
                                        alert="[***CRITICAL***]";
					critical_count=$(expr $critical_count + 1);
                                	echo "[-] [Dev:$dev] [Mount:$mountpoint] [Free:$size] [Used:$used] $alert";
					echo "";
				fi
			;;
		esac
	done
	if [ $critical_count -eq 0 ]; then
		echo "No critical filesystems"
		critical_count=0;
	fi
done
if [ "$1" = "weekly" ]; then
	echo "________________"
	echo "Warnings: $warning\t|";
	echo "Criticals: $critical\t|";
fi

Para que el script funcione, es necesario que en la misma ruta donde se encuentra, exista el archivo ips.txt que debe tener, bajo la sintaxis hostname:ip:port, la información para que el script se conecté por ssh a las máquinas. Para que sea más dinámico y no requiera la intervención de un humano, la máquina donde se ejecutará el script debe tener una llave privada cuya llave publica esté repartida en los servidores que se desean monitorear.
El script necesita un argumento para funcionar, puede ser “weekly” o “daily”, segun se necesite. Con daily el script genera reportes donde mostrará solamente los criticos, mientras que con weekly hará un reporte general.

En el cron tengo agregado que todos los dias a las 9AM, haga un reporte diario y todos los lunes a las 8AM uno general (weekly) y los envie por correo a los responsables.

8 * * 1 cd /root/du_alert; sh alert.sh weekly |mail -s “Weekly Disk Usage Status” encargado@dominio.cl — -F “System Administrator”
0 9 * * * cd /root/du_alert; sh alert.sh daily |mail -s “Daily Disk Usage Status” encargado@dominio.cl — -F “System Administrator”

Compartir/Guardar

La URL vulnerable es http://tvndeportes.cl/intersitial/index.html?link=, a “link” podemos asignarle cualquier URL y el navegador será redireccionado a esa URL. Por ejemplo:

http://tvndeportes.cl/intersitial/index.html?link=http://sitio.webmaligno.com/pics/pics.exe

Quizá este método solo nos permita redireccionar a un usuario y nada mas, pero con un poco de imaginación y trabajo, perfectamente ese usuario podría ser engañado por email para ingresar a un sitio confiable de TVN y redirigirlo a un sitio de streaming falso, donde le haga aceptar la descarga de un archivo (troyano) para que pueda ver el video. Aprovechandose de todo esto del mundial, la locura por ver los partidos en alta definicion, perfectamente un atacante podría insitar a un usuario a descargar un programa para poder ver el partido, desde el sitio de tvn, en alta definición y gratis, obviamente “ese” programa sería un virus o algo similar.

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

Generalmente los criterios para asignar accesos a los distintos sistemas es los mismos, existen las que son aleatorias con y sin patrones, las típicas “dos letras iniciales del apellido seguido del año de nacimiento”, etc. Quizá el problema no está en asignarles claves por defecto fáciles a los usuarios, sino en los mismos usuarios que no las cambian o bien tardan una eternidad en ingresar por primera vez al sistema. Por esto mismo, pienso que la seguridad de los sistemas no debe depende de los usuarios, debe depender del sistema, a menos que tengamos muy acotado el tipo de usuarios que tendrá el sistema.
En este post hablaré sobre los tipicos accesos a universidades, cuentas de correo de empresas, cuentas de servidores ftp, ssh, web, etc.

En primer lugar, pienso que, el hecho de querer facilitarle las cosas al usuario final asignandole una password que sea “recordable”, es riesgoso. El hecho de que una password siga un patrón quiere decir que es altamente descifrable o descubrible por un atacante. Como patrónoes entendemos password como:

• usuarioYYYY: donde YYYY puede ser el año de nacimiento, el año que la persona ingreso a la institución u otra cosa que tenga relación.
• Primeros o últimos 3 o 4 digitos del rut: Por ejemplo si el rut de una persona es 6.714.870-9, la clave podría ser 6714 o bien 8709
• Nombre de usuario: aunque no lo crean, es muy comun tambien que se asigne como contraseña lo mismo que le entregan como nombre de usuario
• Juego con las iniciales de los nombres y/o apellidos y año de nacimiento o año de ingreso: Por ejemplo, para Juan Perez, una posible password sería jperez2009, juanp2009, jp2010, etc.

Quiza lo que acaban de leer pareciera ser algo muy estúpico o algo demasiado básico, pero es increible que suceda. Hace un par de semanas publiqué dos ejemplos muy claros al respecto, lo pueden ver en:

La poca importancia de la seguridad en la Universidad Mayor
Seguridad en accesos de ex alumnos del Instituto Profesional CIISA

El hecho de saber un patrón de asignaciones de contraseñas por defecto de una empresa o alguna institución les abre una puerta trasera enorme y, a mi criterio, es una vulnerabilidad que debe ser considerada critica si se desea proteger el robo de información y la privacidad de la institución y de los mismos usuarios.

La contraseña de un usuario puede comprometer el acceso a otros usuarios, por ejemplo si mi password por defecto corresponde a la primera inicial de mi nombre, seguido de mi apellido, luego un guión bajo (_) y finalmente mi año de nacimiento y es interceptada por algun atacante, sea como sea, independiente de que esa persona haya querido atacarme a mi o independiende de que si yo tengo informacion privada o si me interesa la seguridad o no, estoy dando el paso para que esa pesona pueda adivinar contraseñas de las demas personas.

Un caso muy comun es el hecho que cuando una persona ingresa a trabajar a una empresa generalmente le preparan un computador con todo listo, su cuenta de correo lista, configurada y lista para usarse por lo que el usuario jamás tendrá curiosidad de cambiarla, asi mismo todos o la gran mayoría de la empresa. Una persona sin muchos conocimientos podría probar el mismo patrón de contraseñas para ingresar como su compañero de trabajo, luego que ingresa al correo de esa persona exitosamente, lo gracioso sería intentar ingresar a otras cuentas por ejemplo al sistema de tickets u otros sistemas con el que podríamos hacer más daño. Según mi punto de vista, las contraseñas por defecto deberían ser por defecto aleatorias y obligar a que el usuario se loguee apenas es creada la cuenta y cuando ingrese por primera vez obligarlo a cambiar la contraseña.

Los desarrolladores o administradores pueden quejarse con la típica frase “es que son sistemas que acceder desde la red interna, desde la lan solamente”, pero la verdad es que uno nunca sabe desde que lado esta el atacante.

Aunque no lo crean, muchas veces esas mismas empresas que le asignan esas contraseñas por defecto a sus empleados, lo hacen tambien con sus clientes. Por ejemplo, una empresa de hosting o diseño web, en ambos casos, cuando le quieren dar acceso a ftp o bien acceso a algun sistema para que hagan el “testing”, cumplen el mismo patron, si no es “123456″ es, por lo general, el nombre del cliente. Puedo entender que es engorroso asignar contraseñas tan dificiles de recrodad a los clientes para que hagan simplemente un checkeo de una aplicación, pero aveces la seguridad requiere de un poco de esfuerzo.

Compartir/Guardar

Estimado Fernando:

Me dirijo a usted como representante de la Empresa E-Sign, en mi calidad de Gerente de Operaciones,  para comentarle algunos de los alcances que ha tenido para nosotros el  reporte de vulnerabilidad XSS que usted ha publicado a fines de la semana pasada.  Con su información hemos verificado los errores reportados, y nuestros programadores se encuentran trabajando en la revisión y corrección de otros posibles problemas. Específicamente, aquellos relacionados con el “contacto.php” se corrigieron el 30 de Abril en la tarde.

Le agradecería que, en el caso de detectar una nueva vulnerabilidad o la posibilidad de ella en nuestro sitio, lo informe directamente a mi correo particular o telefónicamente a la empresa. Asimismo, le solicitamos que nos dé un  espacio de tiempo suficiente para corregir el problema, antes de publicarlo en internet.

Finalmente, a nombre de E-Sign, quisiéramos agradecerle su nota y enfatizar que tomaremos todas las medidas necesarias para evitar que este tipo de problemas vuelvan a ocurrir.

Creo que es una buena respuesta y es la forma en que deberían actuar las empresas cuando se les informa sobre algún fallo, bug o vulnerabilidad que los afecta.
Podemos ver que el enlace vulnerable: https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E ya no se ve afectado.

Compartir/Guardar

La idea de un sitio con certificado SSL es que toda la información viaje cifrada, pero la gente de E-Sign al parecer no piensan eso. Al menos dos formularios del sitio envían la información sin cifrar, entonces ¿Para qué usan el certificado SSL?

Quizá no es tan crítico, ya que se trata del formulario de contacto y el buscador, pero ya que ellos obligan al usuario a confiar de ellos aun cuando los formularios no se envian de forma segura, nosotros aprovecharemos de generar otro tipo de trafico de manera insegura, por ejemplo insertando un formulario falso o un sitio externo mediante XSS.

¿A qué me refiero con esto? Sencillo, cuando estás navegando en un sitio seguro y en él, existe información que viaja de manera no-segura (sin cifrar), el navegador nos alerta y nos pregunta si queremos continuar.

En cierta forma, E-Sign está obligando al usuario a confiar en ellos y para proceder, el usuario tendrá que poner aceptar. Si ellos lo hacen, ¿por qué nosotros no?

Nos aprovechamos de una vulnerabilidad XSS que presentan algunos links, por ejemplo link de “Contacto”:

https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E

Mediante XSS podriamos perfectamente modificar el formulario, agregar y quitar campos y redireccionar la informción hacia otro sitio o bien colocar un iframe externo que nos permita insertar un formulario arbitrario para capturar información que necesitamos.

Con un poco de ingenieria social y un poco del arte del engaño, seguramente podemos explotar aun mas esta vulnerabilidad. Muchas veces la vulnerabilidad va más alla de si misma, depende mucho del sitio sobre el cual se intenta explotar, en este caso, es mucho mas grave que en el caso del post anterior.

Lo que encuentro más problematico, es que una empresa de seguridad, quienes ofrecen un servicio Anti Phishing, tengan este tipo de vulnerabilidades, le resta demasiada credibilidad a la empresa, lamentablemente las personas que contratan estos servicios generalmente no saben mucho del tema y creen que estaran en buenas manos y muchas veces estan cometiendo un error entregando su seguridad a las personas equivocadas.

Como de costumbre, intenté contactarme con los encargados mediante el formulario de contacto del sitio pero no he obtenido ningun tipo de respuesta.

ACTUALIZACIóN – 3/Mayo/2010: La empresa se ha contactado conmigo via email. Más información acá.

Compartir/Guardar

Lo más comun, y que me da muca risa y aveces rabia, y me desespera un poco, es ver como los usuarios avanzan lentamente, directorio por directorio, hasta llegar a la destino final. Por ejemplo:

$ cd /
$ cd home
$ cd usuario
$ cd public_html
$ cd includes

En lugar de ejecutar directamente
$ cd /home/usuario/public_html/includes

Y peor aun, hay veces que el usuario es inseguro y prefiere verificar si lo hizo bien y termina su caminata por los directorios haciendo un “pwd”:

$ cd /
$ cd home
$ cd usuario
$ cd public_html
$ cd includes
$ pwd
/home/usuario/public_html/includes
$

Hay algo que me desespera aun mas, es cuando el usuario tiene la necesidad de listar el contenido de CADA directorio:

$ cd /
$ ls -l
$ cd home
$ ls -l
$ cd usuario
$ ls -l
$ cd public_html
$ ls -l
$ cd includes
$ pwd
/home/usuario/public_html/includes
$ ls -l

Para los que no saben, para esto existe un truco (tip!), no digo que se aprendan los directorios de memoria, pero pueden ejecutar todo en una sola linea, por ejemplo, cuando escriben / pueden presionar tabular dos veces y automaticamente aparecerá el listado de archivos y directorios dentro de /. Asi mismo, si escriben /home/ y dos veces tabular, veran todo el contenido de /home, sin tener que ejecutar cd /home, presionar enter y luego un ls.

Otra cosa que es muy comun, aunque no lo crean, es encontrar las passwords de las bases de datos, especialmente de MySQL. La gente está acostumbrada a ejecutar el comando mysql para conectarse a la base de datos pasandole como parametro el usuario y la password

$ mysql -uproduccion -p4gSg4ws -hlocalhost mydatabase
mysql>

Tambien usan esta misma tecnica para generar los típicos respaldos usando mysqldump.

$ mysqldump -uproduccion -p4gSg4ws -hlocalhost mydatabase >>mydatabase.sql

Obviamente esto es un problema de seguridad, ya sea porque no se educó bien al usuario o simplemente porque no existen medidas de seguridad dentro del contexto donde se está ejecutando este tipo de comandos.

Tambien es muy usual encontrar a usuarios que intentan pasarle la password de root al comando “su”, ejecutando comandos tipo:

$ su - 354dr2

Pensando que 354dr2 es la password de root, al igual que

$ sudo su - password_del_usuario

Pensando que de esa forma no le pedirá el password. Lo que no sabe el usuario es que todo lo que ejecuta esta siendo logueado y que está comprometiendo la seguridad del servidor.

El .bash_history o historial de comandos bash, muestra mucho como trabajan los usuarios, qué hacen y de qué forma lo hacen, de esta forma es posible obtener información sobre algun sistema o servicio que esté corriendo en el servidor, por ejemplo si entramos a la mala a un servidor y queremos buscar información privada o información que nos interese, podemos ver el historial de los usuarios para saber qué hacen, por donde se mueven y seguir sus pasos.

Un dia me tocó ver que un usuario tenia un script “escondido” que se conectaba vía llave pública a 4 o 5 servidores (incluyendo uno fuera de la red), obviamente, la llave privada estaba en el servidor donde yo estabam por lo que pude acceder a todas sus cuentas en los otros servidores.

Compartir/Guardar