El rincón de Zerial

Informática, GNU/Linux, Seguridad, Hacking, Programación, Ocio

Mostrar menú Ocultar menú

CategoríaSeguridad

Temas relacionados con seguridad informatica.

Validar correctamente la subida de un archivo con php

junio 4, 2009 /

Cuando nos enfrentamos a esta situación se nos viene a la cabeza distintas formas de querer validar un fichero, según sea la necesidad; por tamaño, extension, etc.
Lo que voy a explicar es como realizar la una validación correcta y eficiente del tipo de archivo que se está subiendo y aprovecho de explicar tambien la importancia de realizar bien esta validación.

Antes que todo, hay que tener en claro como funciona esto de la subida de archivos y tener en mente que la validación se puede y debe hacerse a nivel de cliente y a nivel de servidor. Muchas veces me he enfrentado a situaciones donde el desarrollador solo hace la validación a nivel de cliente, en javascript. Por ejemplo, así:

  1. <script>
  2. function validar(archivo){
  3.    var b = archivo.split(‘.’);
  4.    if(b[b.length-1] == ‘txt’)
  5.       return true;
  6.    else{
  7.       alert(‘Error: El archivo debe ser .txt’);
  8.       return false;
  9.    }
  10. }</script>

Si llamamos a esa función pasando como parámetro archivo.txt no mostrara ningún error, de lo contrario, si pasamos otro argumento como pelicula.avi devolverá error y no nos dejará continuar.
Este tipo de validación es el menos eficiente, ya que realizar una petición por POST sin pasar por el formulario es algo muy simple, basta con tener las herramientas necesarias como por ejemplo curl.
Hay que dejar en claro que el hecho de validar un formulario unicamente en javascript es una gran irresponsabilidad, ya sea la validación de unos simples datos como los típicos nombres, apellidos, email hasta la subida de archivos. El realizar una validación por javascript nos entrega una capa más de seguridad, pero no la única.

Seguir leyendo

TryWho y el susto de los Chilenos

junio 1, 2009 /

Hace días que vengo leyendo tweets, informaciones en blogs y sitios de noticias sobre el nuevo sistema de lucro mediante la información pública y privada de las personas. Lo que más me llama la atención es la poca información (por no decir ignorancia) de la gente que se asombró con esto, siendo que son ellos mismos quienes no se encargan de proteger su información, como lo expliqué en un post anterior.

Estoy trabajando en un artículo dónde demostraré muchas falencias en los sitemas de información en Chile, no queria quedarme sin dar mi opinion respecto a lo que se habla, mucho menos ahora que tambien se esta hablando de una posible modificacion en alguna ley de protección de datos.

Links relacionados:

Información sensible expuesta publicamente en la UCV

mayo 28, 2009 /

Al igual que en el post anterior, que hablaba sobre la vulnerabilidad en uno de los sitios de la Universidad de Chile, esta vez es el turno de la Universidad Catolica de Valparaiso (UCV), especificamente el campus virtual.

Al parecer el sitio estaba en mantenimiento ya que me encontre con varios mensajes que del tipo “Este sitio esta en mantencion“, pero esto no es excusa. Dejar un directorio que contiene informacion sensible de clientes, empleados, empresa, alumnos, etc no puede estar publicado en internet con permisos de listar directorio habilitado. Existen varias formas de proteger el contenido de un directorio desde la configuracion del fichero .htaccess hasta algo tan simple como el crear un index.php|html|htm vacios, sin dejar de lado que se puede hacer agregado reglas de acceso a la configuracion del dominio.

Bueno, encontré un directorio con información sensible de alumnos de esa Universidad, quizas la informacion es un poco antigua pero que importa eso si ni el nombre ni el rut de las personas cambia. Intenté comunicar con la webmaster del sitio pero no obtuve respuesta.

En este caso, se han expuesto en internet datos de aproximadamente 2000 alumnos.


Informacion hecha publica por la UCV

Informacion hecha publica por la UCV

En esa imagen podemos ver un poco de la informacion que aparece en el directorio vulnerable. Es un fichero separado por gatos (###) donde podemos ver que lo mas interesante son las columnas 3, 4, 5 y 6 que corresponden al rut, nombre completo de la persona, nombre de usuario y password respectivamente.

Seguir leyendo

Vulnerabilidad en un sitio de la Universidad de Chile

mayo 26, 2009 /

Se trata del sitio de la biblioteca virtual de la Facultad de Economia y Negocios (FEN) de la Universidad de Chile. Hace un par de dias descubri una vulnerabilidad del tipo path disclosure en https://bibliodoc.fen.uchile.cl.

La forma de explotar este fallo era iniciar sesion con cualquier usuario y buscar algun documento, cuando acercabamos el mouse hacia el link podiamos ver:

uchile-path

Si modificabamos ese link, remplazando documento para descargar.pdf por alguna ruta a un archivo de sistema, podremos descargarlo. Por ejemplo

uchile-path1

Con ../../../../ nos aseguramos retroceder lo suficiente para llegar a la raiz y con /etc/passwd le decimos al script download.php que nos entregue el fichero passwd, que guarda la informacion de usuarios de sistema. Obteniendo lo siguiente:

uchile-path2

Dias despues de explotar y confirmar esta vulnerabilidad, me di el trabajo de comunicarles a los de soporte de ese sitio sobre este fallo obteniendo una respuesta en poco tiempo. Estaban muy agradecidos por haberles comunicado el problema. En unos minutos me agrego a gtalk/jabber el desarrollador del portal y me hizo unas preguntas, para saber como habia logrado explotar esa vulnerabilidad y en que consistia y, luego de haberle respondido algunas preguntas y haberlo ayudado, rapidamente solucionó el problema.

Las vulnerabilidades de tipo file/path disclosure son aquellas donde de alguna u otra forma podemos acceder a archivos del sistema que estan fuera del path de la web, como en este caso, por ejemplo si la web hubiese estado en /var/www/bibliodoc, mediante este bug pudimos acceder a un archivo ubicado en /etc/ que, claramente, esta fuera del directorio.

Local root exploit en kernel 2.6.x (hasta la 2.6.29)

mayo 17, 2009 /

El Viernes pasado se anunciaron, en la lista de seguridad de debian, actualizaciones para el kernel, que solucionaba varias vulnerabilidades.

CVE-2009-0028

    Chris Evans discovered a situation in which a child process can
    send an arbitrary signal to its parent.

CVE-2009-0834

    Roland McGrath discovered an issue on amd64 kernels that allows
    local users to circumvent system call audit configurations which
    filter based on the syscall numbers or argument details.

CVE-2009-0835

    Roland McGrath discovered an issue on amd64 kernels with
    CONFIG_SECCOMP enabled. By making a specially crafted syscall,
    local users can bypass access restrictions.

CVE-2009-0859

    Jiri Olsa discovered that a local user can cause a denial of
    service (system hang) using a SHM_INFO shmctl call on kernels
    compiled with CONFIG_SHMEM disabled. This issue does not affect
    prebuilt Debian kernels.

CVE-2009-1046

    Mikulas Patocka reported an issue in the console subsystem that
    allows a local user to cause memory corruption by selecting a
    small number of 3-byte UTF-8 characters.

CVE-2009-1072

    Igor Zhbanov reported that nfsd was not properly dropping
    CAP_MKNOD, allowing users to create device nodes on file systems
    exported with root_squash.

CVE-2009-1184

    Dan Carpenter reported a coding issue in the selinux subsystem
    that allows local users to bypass certain networking checks when
    running with compat_net=1.

CVE-2009-1192

    Shaohua Li reported an issue in the AGP subsystem they may allow
    local users to read sensitive kernel memory due to a leak of
    uninitialized memory.

CVE-2009-1242

    Benjamin Gilbert reported a local denial of service vulnerability
    in the KVM VMX implementation that allows local users to trigger
    an oops.

CVE-2009-1265

    Thomas Pollet reported an overflow in the af_rose implementation
    that allows remote attackers to retrieve uninitialized kernel
    memory that may contain sensitive data.

CVE-2009-1337

    Oleg Nesterov discovered an issue in the exit_notify function that
    allows local users to send an arbitrary signal to a process by
    running a program that modifies the exit_signal field and then
    uses an exec system call to launch a setuid application.

CVE-2009-1338

    Daniel Hokka Zakrisson discovered that a kill(-1) is permitted to
    reach processes outside of the current process namespace.

CVE-2009-1439

    Pavan Naregundi reported an issue in the CIFS filesystem code that
    allows remote users to overwrite memory via a long
    nativeFileSystem field in a Tree Connect response during mount.

Se publicaron dos exploits para explotar vulnerabildades de escalacion de provilegios local. Estos exploits se aprovechan de la funcion ptrace_attach() para ejecutar un codigo arbitrario que nos permita ejecutar una shell del tipo /bin/sh como root.
El primer exploit es el shoryuken, lo probé en distintas versiones del kernel de debian y archlinux, pudiendo ser explotada solo la version 2.6.26-1-686 de Debian 5.0, de forma aleatoria, es decir, hay veces que ejecuto el exploit y funciona y otras veces no. El segundo script fue probado por su autor en la version del kernel 2.6.29rc1 de Gentoo.
Estos exploits funcionan bajo situaciones especificas y no todos los sistemas son vulnerables.

La importancia de la seguridad de la información

mayo 10, 2009 /

La importancia que tiene la seguridad de la información y el poder que implica manejar información es un tema muy delicado que no está en el conocimiento de muchos. En el contexto de internet, muchos usuarios no le dan mayor importancia a su información que publican en la red y de qué forma lo hacen y más aún, muchos no diferencian lo privado de lo público, no por que no quieran o por que no saben como diferenciar una cosa de la otra, simplemente es por ignorancia. Para mucha gente es normal pertenecer en redes sociales y publicar su vida, mientras más conocidos sean y más amigos tengan en esa red social más importante se creen y es esta “vulnerabilidad” la que se está explotando: La ingenuidad y/o ignorancia del usuario. Por otro lado están las empresas, quienes son las encargadas de manejar la información privada y/o pública que los usuarios les confían, por ejemplo en el caso de un concurso, típicamente los datos que piden son nombre, apellido, ciudad, rut/dni, etc. Personalmente me pregunto ¿Para qué quieren mi rut/dni en un concurso, si con mi teléfono es suficiente para que me puedan ubicar? La respuesta es simple, todos esos datos van a una base de datos que puede ser vendida o usada para enviar publicidad no deseada, más conocido como spam. Estoy seguro que a nadie nos gustaria que esto fuese realidad, pero lo es. Por más que la empresa nos intente explicar por medio de “letra chica” o “términos y condiciones” que el uso de nuestra información está fuera de peligro y que serán usados sólo para tal y tal fin. Pues eso es mentira. He tenido experiencias y tengo las pruebas necesarias que eso no ocurre, ni si quiera las entidades del gobierno son capaces de cumplir con algo tan básico como es la protección de la información privada y, de hecho, ni si quiera los mismos usuarios son capaces de proteger su información.

En Chile, la falta a la protección de datos es algo que se da demasiado seguido, ya sea por empresas privadas o publicas (estatales o gubernamentales).

Hace un tiempo se publicó una base de datos con la información de más de 5 millones de chilenos y posteriormente, se publicó un buscador que nos permitia encontrar los datos de cualquier persona. Existen entidades encargadas de proteger esa información, en este caso es el sitio web de el Servicio Electoral (Servel), de donde fue obtenida la información. Poco tiempo despues de ésta publicación, realizamos una prueba de concepto programando un algoritmo capáz de obtener los datos desde ese sitio nuevamente, lo que tuvo un resultado positivo para nosotros. Pudimos obtener más de 4 millones de datos sobre los chilenos. En este intento, el sitio web del servel se cayó dos veces, estando el sitio abajo mas de 12 horas, cada véz que se cayó. Al entrar al sitio se podia ver un mensaje de que el espacio en disco estába lleno debido a los logs, esto quiere decir que cuando reactivaron el sitio, los encargados del sitio debieron haber vaciado ese directorio de logs y obviamente no se dieron el trabajo de analizarlo sino hasta el tercer intento que fue cuando decidieron colocar un captcha y, aunque el captcha es “basico”, no gastariamos tiempo en programar un algoritmo que lo rompa si nustra misión ya cumplió su objetivo. Una véz realizado este experimento procedimos a eliminar toda la información que descargamos.

Seguir leyendo

Antiguas entradas Nuevas entradas

© 2024 El rincón de Zerial

Tema por Anders Norén — Subir ↑