Inicio > FileSystem, Hacking, Programacion, Services - Software > Bind a puertos reservados utilizando usuarios sin privilegios de Root

Bind a puertos reservados utilizando usuarios sin privilegios de Root


Una de las tareas mas comunes de un administrador de sistemas consiste principalmente en la correcta configuración y arranque de diversos servicios tales como servidores web, servidores de correo, servidores DNS, etc. En todos los casos, alguien consciente de que la seguridad en los servicios expuestos al publico tendrá como referencia determinadas políticas de seguridad entre las cuales, sin lugar a dudas, se debe incluir la ejecución de dichos servicios con un usuario con privilegios limitados, es decir, el usuario ROOT no debería iniciar servicios como Apache o SendMail, ya que si existe algún problema con dichos servicios, como por ejemplo una vulnerabilidad que le permita al atacante acceder de forma remota (como por ejemplo el aprovechamiento de una vulnerabilidad de Buffer Overflow) este automáticamente tendrá privilegios de ROOT sobre el sistema, no hace falta indicar las nefastas consecuencias que conllevan incidencias como estas.

Aunque dicha política de seguridad sea casi como una ley (divina?) “No arrancaras servicios expuestos al publico utilizando para ello el usuario ROOT” existe un inconveniente que es intrínseco al diseño original de como funcionan los sistemas operativos basados en UNIX y consiste en que todos los puertos privilegiados (menores a 1024) solamente pueden ser enlazados (binding) por el usuario ROOT, servicios comunes como Servidor SSH, Servidor web, Servidor de Correo, Finger, Servidor DNS, etc. frecuentemente se ejecutan en puertos menores a 1024, para tratar con este tipo de situaciones, se cuentan con algunas alternativas ante estas situaciones, las que mas destacan son:

- Crear un entorno CHRooted

- Utilizar el comando SUDO y editar el fichero de sudoers correspondiente

- Utilizar herramientas que permitan abrir un puerto privilegiado utilizando permisos de ROOT y posteriormente remover dichos permisos del proceso principal.

La primera alternativa en muchos casos es difícil de mantener, ya que se debe realizar un estudio detallado sobre cuales ejecutables tendrá disponible el usuario enjaulado, es una tarea con un nivel de dificultad considerable y las implicaciones de seguridad que trae consigo un entorno CHRooted mal configurado pueden ser desastrosas, por otro lado el uso del comando “SUDO” permite a un usuario con permisos limitados realizar determinadas acciones como ROOT, este enfoque resulta practico en muchos casos, no obstante el proceso ejecutado con este comando permanecerá cargado en memoria hasta su terminación con los privilegios que se han asignado por medio del comando “SUDO” por lo tanto también trae consigo implicaciones en términos de seguridad. Finalmente la ultima opción (que será el enfoque de esta entrada) consiste en utilizar herramientas que permitan ejecutar el proceso que abra los puertos privilegiados (como un servidor web como apache que puede abrir los puertos 80 y 443) y una vez abiertos, remueva automáticamente cualquier privilegio de ROOT que pueda estar asignado al proceso en ejecución.

Las herramientas que actualmente se enfocan en permitir que una aplicación pueda abrir un puerto reservado (inferior a 1024) utilizan uno de dos mecanismos, en primer lugar pueden utilizar la característica de “capabilities” incluida en Linux y que permite declarar determinados permisos a una aplicación concreta, una aplicación que utilizan este mecanismo es setcap, por otro lado también se puede utilizar la variable LD_PRELOAD que permite sobreescribir las invocaciones a la llamada del sistema bind las herramientas authbind y privbind utilizan este método para permitir que una aplicación determinada pueda abrir puertos reservados y este será el mecanismo explicado en esta entrada dado que es el mejor en terminos funcionales y de seguridad.

authbind

Authbind es una herramienta sencilla y flexible que permite abrir puertos reservados sin que el usuario que ejecuta el proceso tenga privilegios de ROOT. Para conseguir esto, authbind utiliza la funcionalidad de LD_PRELOAD incluida en las distribuciones Linux actuales, la cual permite a un programa (incluyendo sus correspondientes sub procesos) abrir puertos inferiores a 1024, los cuales son reservados para servicios tan importantes como servidores web, servidores de correo, servidores DNS, servidores SSH, servidores FTP, etc.

El mecanismo empleado por authbind es sencillo, consiste básicamente en cargar y utilizar la variable LD_PRELOAD para sobre escribir la llamada al sistema bind la cual se encarga de asignar un espacio de memoria compartido con otros procesos remotos llamados habitualmente “clientes”, este espacio de memoria es referenciado por un número único que es habitualmente llamado “puerto”. Cuando se invoca a authbind este ejecutará la llamada del sistema bind sobreescrita por la utilidad, esto en el caso de que el usuario no tenga el uid 0 (es decir no es ROOT) authbind intentará invocar la función auxiliar setuid-root e intentará abrir el puerto privilegiado, en el caso de que el usuario tenga el uid igual a 0 (es decir, es root) o el puerto que se intenta abrir es mayor a 1024, authbind no necesitará invocar a la función de bind sobreescrita, en su lugar invoca a la función bind original para que esta reserve el espacio de memoria compartido solicitado (para que abra el puerto).

Instalación y funcionamiento de authbind

En primer termino para instalar authbind, se puede ejecutar el comando apt-get correspondiente o compilar e instalar desde código fuente, en el primer caso solamente basta con ejecutar el comando “apt-get install authbind” en el segundo caso es necesario descargar el código fuente de authbind desde: http://www.chiark.greenend.org.uk/ucgi/~ijackson/cvsweb/authbind/ y posteriormente realizar el procedimiento de compilación, construcción e instalación estándar en programas escritos en C (make && make install)

Una vez instalado el programa es necesario comprender como es el mecanismo de control de acceso que utiliza authbind para poder abrir puertos restringidos.

  1. Authbind primero busca el fichero /etc/authbind/byport/port donde “port” es simplemente el número de puerto que authbind permitirá abrir por medio de la función de bind sobreescrita, en el caso de que dicho fichero sea accesible, el acceso es autorizado y authbind procederá a abrir dicho puerto.
  2. En el caso de que el fichero anterior no exista o no sea accesible por el usuario que esta ejecutando authbind la herramienta intentará validar el fichero /etc/authbind/byaddr/addr:port donde “addr” y “port” son la dirección de la maquina y el puerto que tienen autorización para abrir el puerto.
  3. Finalmente, si ninguno de los dos ficheros anteriores ha podido ser validado correctamente, authbind realiza un ultimo intento en buscar el fichero /etc/authbind/byuid/uid donde uid indica el identificador único de usuario, si este fichero es encontrado, se garantiza el acceso y authbind procede a abrir el puerto solicitado, sin embargo en el caso de que no sea localizado dicho puerto, automáticamente se lanzará un error de “Operación No Permitida”

Dada la explicación anterior, se cuenta ya con un conocimiento detallado del funcionamiento de authbind ahora se indican las opciones incluidas en esta herramienta que son dos:

  1. –deep: La herramienta por defecto solamente afecta al programa que recibe como argumento, no obstante con esta opción, authbind incluirá en su ejecución todos los programas que se puedan invocar de forma directa o indirecta pro el programa especificado, lo que quiere decir que si el programa invocado, utiliza otro programa que requiera abrir un puerto inferior a 1024, authbind realizará el mismo procedimiento de control de acceso anteriormente descrito y así para todos y cada uno de los programas que se invoquen de forma directa o indirecta por el programa.
  2. –depth niveles: Como se ha explicado, la opción anterior afecta a todos los programas invocados de forma directa o indirecta por el programa pasado como argumento a authbind no obstante, con esta opción se puede controlar y limitar este comportamiento, indicando el numero de niveles de profundidad (programas tratados por authbind) que podrán pasar por el control de acceso de la herramienta en el caso de que intenten abrir un puerto reservado. El valor por defecto de esta opción es “1” y es el valor que se aplica siempre a menos que la opción “–deep” sea indicada de forma explicita.

Para centrar estos conceptos, en un ejemplo practico, se procede a iniciar un servidor web Apache, el cual intentará abrir los puertos 80 (HTTP) y 443 (HTTPS). Como se ha indicado anteriormente, el primer paso es establecer el control de acceso creando los ficheros correspondientes a estos dos puertos en las ubicaciones adecuadas, para esto se pueden ejecutar los siguientes comandos (evidentemente estos comandos solo pueden ser ejecutados como ROOT, de otro modo cualquier usuario podría “darse permisos” sin conocimiento del administrador, al momento de instalar authbind, la herramienta establece los permisos adecuados al directorio /etc/authbind para que no pueda ser accedido por cualquier usuario):

touch /etc/authbind/byport/80chmod 500 /etc/authbind/byport/80

chown adastra /etc/authbind/byport/80

touch /etc/authbind/byport/443

chmod 500 /etc/authbind/byport/443

chown adastra /etc/authbind/byport/443

Una vez creados y establecidos los permisos adecuados para que el usuario “adastra” pueda acceder a dichos ficheros, se puede ejecutar el comando de arranque del servidor web apache de la siguiente forma:

authbind –deep /opt/apache2/apachectl start

Con esto es suficiente para iniciar el servidor apache desde la cuenta de usuario “adastra” la cual tiene privilegios limitados.

Privbind

Se trata de una herramienta que tiene un mecanismo similar al que utiliza authbind para permitir a una aplicación determinada abrir puertos reservados utilizando la variable LD_PRELOAD que permite sobreescribir las invocaciones que se lleven a cabo contra la función del sistema bind de esta forma, cuando un comando intenta invocar a la función bind para abrir un puerto privilegiado, privbind intercepta la llamada y la envía a un proceso que tiene privilegios de root, dicho proceso intenta abrir el puerto solicitado y posteriormente envía el resultado de la invocación (el File Descriptor) al proceso padre y continua con la ejecución normalmente. Este mecanismo es el modelo estándar de “fork + exec” que consiste en realizar una “bifurcación” del proceso principal a otro proceso dependiente para realizar cualquier tipo de operación que no puede (o no debe) realizarse desde el proceso principal y una vez esta operación sea finalizada, el control de la ejecución del programa es retomada por el proceso principal, tomando como insumo los resultados que ha dado la ejecución del proceso hijo. Se trata de un mecanismo sencillo no obstante muy efectivo que permite ejecutar operaciones desde un proceso hijo que el proceso padre por si solo no tendría permitido realizar, es así como solamente se le permite a un programa determinado abrir algún puerto menor o igual a 1024.

El proceso de instalación consiste en compilar, construir e instalar todo desde código fuente, se trata de un programa escrito en C, por lo tanto este proceso es muy sencillo (./configure && make && make install)

Una vez instalado es posible comenzar a utilizarlo, las opciones disponibles en dicho comando son:

-u: Opción obligatoria que indica bajo cual UID de usuario ejecutar la aplicación que es especificada por parámetro, puede indicarse el valor numérico o directamente el nombre del usuario y en ningún caso puede ser un usuario con privilegios de ROOT.

-g: Indica el GID del usuario que se ha indicado en la opción -u, en el caso de que no es especifique de forma explicita, se toma el grupo por defecto del usuario.

-n: Esta opción es importante ya que determina el numero de veces que se permitirá invocar a la función del sistema bind desde privbind, esto quiere decir que cuando este número de invocaciones es alcanzado el proceso hijo de privbind (el que se encarga de invocar la función bind) automáticamente finaliza su ejecución dejando activo solamente al proceso padre. Por defecto, si no se especifica esta opción de forma explicita

-l: Indica la ruta donde se encuentra ubicada la librería LD_PRELOAD en el caso de que no se encuentre localizada en las librerías compartidas del sistema.

Estas son todas las opciones que se incluyen en esta herramienta, ahora bien, para probarlo puede ser útil iniciar un servidor web como Apache utilizando un usuario sin privilegios, este servidor web intentará abrir los puertos 80 y 443, en este caso el comando que se ejecuta es el siguiente:

>privbind -u 1000 -g 1000 -n 2 /opt/apache2/bin/apachectl start

Se han especificado las opciones -u y -g que como ya se ha comentado anteriormente indican el uid del usuario que estará asociado al proceso padre y el grupo de dicho usuario respectivamente. Por otro lado también se controla el numero de invocaciones máximo que se podrán llevar a cabo contra la función del sistema bind, en este caso el valor de 2 es suficiente (ya que se deben abrir solamente dos puertos) finalmente se encuentra el comando que inicia el servidor web. Cabe anotar que este comando debe ser ejecutado por el usuario ROOT, la razón de esto es que el proceso principal debe tener los privilegios del usuario especificado en la opción -u pero el proceso hijo que será el encargado de realizar las invocaciones a la función bind debe tener privilegios de ROOT.

setuid feature

Esta característica es muy popular en sistemas operativos basados en unix y esta directamente relacionada con los permisos que tiene un fichero o directorio, en el caso de un fichero binario, si el bit setuid esta activo, cuando el fichero sea ejecutado por un usuario, el proceso tendrá los mismos privilegios que el propietario del fichero que esta siendo ejecutado, por lo tanto si el propietario de dicho binario es ROOT el proceso tendrá los mismos privilegios y podrá realizar cualquier tipo de acción administrativa sobre el sistema. Esta característica es también conocida por tener implicaciones de seguridad importantes y es recomendable no utilizarla, dado que es un modelo de “todo o nada” es decir, si el bit setuid esta definido para un fichero ejecutable, el proceso creado por la ejecución de dicho fichero tendrá todos los privilegios que tiene el propietario del fichero, si no esta establecido, evidentemente el proceso solo tendrá los privilegios del usuario que le ha invocado, por este motivo es un mecanismo de “todos” los privilegios o “ninguno”, no obstante se intentará indicar su uso en las siguientes lineas.

Para saber si una aplicación tiene activado el bit de setuid, basta con utilizar el comando “ls” para listar los permisos de cada fichero y/o directorio

>ls -l /usr/bin/passwd -rwsr-xr-x 1 root root 43280 feb 15 2011 /usr/bin/passwd

Como puede apreciarse, los permisos de la aplicación passwd son: “-rwsr-xr-x” la “s” indica que el setuid esta establecido para dicha aplicación, desde el momento que un usuario con privilegios limitados utiliza el comando passwd, el proceso generado tiene, efectivamente los mismos privilegios que el propietario del fichero binario, que como puede verse en este caso es ROOT.

Esta característica puede ser activada fácilmente utilizando el comando chmod el cual permite cambiar los permisos que tiene asociados un fichero o directorio, no obstante este comando debe ser ejecutado como ROOT en el caso de ficheros binarios cuyo propietario es ROOT algo que es común en el caso de servidores web y aplicaciones relacionadas. Para cambiar el bit correspondiente al setuid basta con ejecutar el comando

>chown root:root <FICHERO_EJECUTABLE>>chmod 4777 <FICHERO_EJECUTABLE>

En las lineas anteriores se ha indicado en primera instancia que el fichero ejecutable es propiedad del usuario ROOT y posteriormente se ha establecido el setuid del fichero binario, de este modo aun cuando se ejecute con un usuario distinto a ROOT el proceso tendrá privilegios de ROOT.

NOTA:

Aunque el enfoque de esta entrada es el uso del bit setuid, existen otros dos valores de permisos que vale la pena mencionar aquí, los permisos adicionales que pueden establecerse a un fichero o directorio (aparte de los permisos estándar de lectura, escritura y ejecución) son:

setuid Indica que el proceso generado por el ejecutable tendrá los mismos permisos que el propietario del fichero

segid Indica que el proceso generado por el ejecutable tendrá los mismos permisos que el grupo del propietario del fichero

Sticky bit Antiguamente era definido para disparar un proceso adicional que se “pegará” en la memoria una vez finalizará su ejecución, actualmente esta funcionalidad esta obsoleta y ahora se utiliza con frecuencia para suprimir privilegios de borrado de ficheros que pertenecen a otros usuarios en el directorio donde se tiene permiso de escritura.

Ahora bien, por defecto estas características se encuentran desactivadas por defecto en la mayoría de distribuciones basadas en UNIX modernas, como es el caso de muchas distribuciones de Linux (como por ejemplo Ubuntu y Debian) sin embargo para “activar” esta característica basta con ejecutar la función setuid desde un programa simple escrito en C. Por ejemplo para iniciar el servicio de Apache se siguen las siguientes instrucciones

  1. Compilar y ejecutar el siguiente programa
    #include <stdio.h>#include <stdlib.h>

    #include <sys/types.h>

    #include <unistd.h>

    int main()

    {

    setuid( 0 );

    system( “/opt/apache2/bin/apachectl start” );

    return 0;

    }

    Compilar con “gcc” y posteriormente establecer el SETUID en dicho binario (todo utilizando el usuario ROOT).

    >gcc apachesuid.c -o apachesuid>chown root:root apachesuid

    >chmod 4777 apachesuid

  2. Desde la cuenta de un usuario con privilegios limitados ejecutar el comando “apachesuid” (que será el encargado de ejecutar el servidor web)
    >./apachesuid


    Con el comando anterior, será suficiente para activar el SETUID en una distribución Linux moderna, sin embargo, lo anterior solamente es demostrativo, no se recomienda hacerlo desde un entorno en producción.

Como nota final, se recomienda utilizar herramientas como authbind o privbind en lugar de características como SETUID en ficheros ejecutables dado que se trata de soluciones mucho más limpias y mejor implementadas desde el punto de vista de la seguridad.

  1. octubre 14, 2011 en 9:04 am

    Oye y si habres bind9 en un puerto alto con privilegios limitados y por iptables redireccionas los puertos 53 tcp y udp a ese puerto ¿no funcionria?

    • octubre 14, 2011 en 9:48 am

      Lo que dices es perfectamente valido y el funcionamiento no se verá afectado con el uso de iptables, de hecho es la solución que con mayor frecuencia se suele emplear, sin embargo es necesario recordar que los puertos que van del 1025 al 49151 no son estándar, pero la IANA (Internet Assigned Numbers Authority) se encarga de asignarlos a distintas aplicaciones que los necesitan, mientras que el resto de los puertos hasta el 65536 que son los llamados efímeros, se utilizan por clientes de servicios de forma dinámica y se utilizan y reutilizan de forma “aleatoria”, por esta razón es importante tener presente que puerto utilizar, ya que pueden existir conflictos (aunque la probabilidad de que esto ocurra sea realmente baja).
      El hecho de que exista un puerto para cada servicio y estos puertos sean reservados es una regla estándar que es mejor seguir para evitar contratiempos, por esa razón el uso de estas herramientas puede ayudar a evitarlos antes de que ocurran, aunque como he dicho anteriormente la probabilidad es realmente muy muy baja, aun así el uso de estas herramientas es muy sencillo, y valía la pena explicar su funcionamiento.

      Gracias por el comentario, ha sido útil para aclarar conceptos y explicar otras soluciones existentes a los lectores.

      Un Saludo.

  2. ernesto antonio
    febrero 11, 2012 en 12:37 pm

    Hola adastra, ando nuevamente por aca intentando configurar mi tor como relay para ver si me acepta la conexion a la red tor puesto que como te habia comentado estoy en un pais con muchas restricciones, te doy una de ellas “facebook”, estoy realizando las configuraciones dentro de una maquina virtual con la distribucion BT5-R1, nose que opines sobre esto, puesto que el usuario por defecto que ejecuta el sistema operatvo es root, estaba consultando en la wiki de BT como crear un usuario sin privilegios de root y me encontre con este articulo: http://www.backtrack-linux.org/forums/showthread.php?t=1741, lo malo es que al empezar con el primer comando no me da :/
    root@bt:~# cp .config/menus/applications-kmenuedit.menu /etc/skel/.config/menus/
    por lo que entiendo en este comando es que esta intentando copiar el menu, pero este es el de un entorno kde, de ante mano gracias!

    Saludos! por cierto muy bien explicado todo el contenido en este articulo.

  3. febrero 11, 2012 en 2:36 pm

    Hola ernesto,
    En principio no es nada recomendable iniciar TOR con un usuario con privilegios de root, lo que puedes (deberías) hacer, es simplemente crear un nuevo usuario utilizando los comandos estándar de Linux, (los cuales evidentemente son independientes de la distribución que utilices) puedes hacerlo desde consola con comandos como adduser (crear el usuario) addgroup (crear un nuevo grupo) chmod y chroot (para establecer permisos sobre ficheros) en cualquier caso, también lo puedes hacer desde “System -> Administration -> users and groups” desde ahí también puedes crear usuarios y grupos, luego, puedes seguir los pasos de esta publicación para arrancar el relay de TOR usando los puertos 80 y 443.
    Para saber como gestionar usuarios en Linux:

    http://linux.about.com/od/commands/l/blcmdl8_adduser.htm

    http://www.linux-party.com/TutorialLinux/linux_files/linux5.html

    http://www.cyberciti.biz/faq/howto-linux-add-user-to-group/

    Por otro lado, backtrack esta muy bien para hacer pruebas de penetración en redes locales ya que cuenta con muchísimas herramientas preconfiguradas, pero para trabajar con TOR y especialmente con Relays, tendrás que crearte un usuario y sin privilegios y trabajar con él. Personalmente prefiero utilizar Debian (aunque BT esta basado en Debian) ya que puedes configurar con mayor “libertad” todas tus herramientas y utilidades, (sin trabajar con los valores por defecto).
    Un Saludo y gracias por leer.

  4. ernesto antonio
    febrero 19, 2012 en 6:08 am

    Hola adastra ando por aca nuevamente, espero no te moleste tantas preguntas, mira desde backtrack 5 cree un usuario asi:

    Listo el grupo del admin:

    grep admin /etc/group

    me sale algo como esto:

    admin:x:111:

    Ahora sigo con la creacion del usuario:

    adduser –gid 111 ernesto

    Luego me pide la clave para el nuevo usuario, una vez creado, salgo de la session de root e inicio con el usuario ernesto.

    Luego me voy al directorio /etc/authbind/byport/

    Creo los archivos 80 y 443, por supuesto para crearlos debo hacer uso del comando:
    “sudo touch archivo”, puesto que ernesto hace parte del grupo de administradores, pero no es root, si estaria bien esta parte asi?.
    Luego le asigno permisos de lectura y ejecucion y la gran duda es: yo a estos dos arhcivos les asigno como propietario el usuario root?

    Saludos Adastra, gracias por la colaboracion he estado aprendiendo mucho con este material que has publicado.

    • febrero 19, 2012 en 12:15 pm

      Asignales como propietario el usuario “ernesto”.
      Un Saludo.

  5. ernesto antonio
    febrero 22, 2012 en 4:09 am

    Hola adastra, he optado por realizar la instalacion de una maquina virtual con debian 6.0.4(squeeze) para continuar con la practica.

    Realice la instalacion de authbind

    apt-get install authbind

    Luego instale el servidor apache

    apt-get install apache2

    Cree los archivos 80, 443:

    ernesto@debian:/$ ls -l /etc/authbind/byport/
    total 0
    -r-x—— 1 ernesto root 0 Feb 21 08:17 443
    -r-x—— 1 ernesto root 0 Feb 21 08:15 80

    para ejecutar el servidor apache utilice este comando:

    ernesto@debian:/$ authbind -deep /usr/sbin/apachectl start

    Ya que segun veo tu archivo apachectl esta en otro directorio “/opt/apache2/apachectl”. Al lanzar el comando me sale el siguiente error:

    apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
    (13)Permission denied: make_sock: could not bind to address [::]:80
    (13)Permission denied: make_sock: could not bind to address 0.0.0.0:80
    no listening sockets available, shutting down
    Unable to open logs
    Action ‘start’ failed.
    The Apache error log may have more information.

    Liste mi archivo hosts para intentar arreglar el FQDN

    root@debian:/# cat /etc/hosts
    127.0.0.1 localhost
    127.0.1.1 debian

    # The following lines are desirable for IPv6 capable hosts
    ::1 ip6-localhost ip6-loopback
    fe00::0 ip6-localnet
    ff00::0 ip6-mcastprefix
    ff02::1 ip6-allnodes
    ff02::2 ip6-allrouters

    Reemplace el valor “localhost” con la ip 127.0.0.1 por el valor “debian.localhost”, pero no soluciono el problema :/ .

    Saludos Adastra!

    • febrero 22, 2012 en 8:50 am

      El “error”:
      “apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName”
      Indica que te hace falta declarar la directiva “ServerName” en el fichero de configuración de Apache (por defecto conf/httpd.conf). El valor de dicha directiva debe coincidir con el valor que esta definido en el fichero /etc/hosts
      Por otro lado, te hace falta establecer correctamente los permisos sobre el puerto 80 y 443.

      touch /etc/authbind/byport/80
      chmod 500 /etc/authbind/byport/80
      chown ernesto /etc/authbind/byport/80
      touch /etc/authbind/byport/443
      chmod 500 /etc/authbind/byport/443
      chown ernesto /etc/authbind/byport/443

  6. ernesto antonio
    febrero 23, 2012 en 1:12 am

    Hola adastra, gracias por la ayuda nuevamente, te queria listar mis archivos de configuracion para ver donde puede estar el error:

    Archivo hosts:

    ernesto@debian:~$ cat /etc/hosts
    127.0.0.1 localhost
    127.0.1.1 debian

    # The following lines are desirable for IPv6 capable hosts
    ::1 ip6-localhost ip6-loopback
    fe00::0 ip6-localnet
    ff00::0 ip6-mcastprefix
    ff02::1 ip6-allnodes
    ff02::2 ip6-allrouters

    Archivo httpd.conf, lo encontre en la ruta : /etc/apache2/httpd.conf y estaba vacio y lo unico que hice fue agregarle la directiva ServerName.

    ernesto@debian:~$ cat /etc/apache2/httpd.conf
    ServerName 127.0.0.1:80

    Pero sigo con el error:

    ernesto@debian:~$ authbind –deep /usr/sbin/apachectl start
    (13)Permission denied: make_sock: could not bind to address [::]:80
    (13)Permission denied: apache2: could not open error log file /var/log/apache2/error.log.
    Unable to open logs
    Action ‘start’ failed.
    The Apache error log may have more information.

    Intento consultar el log de error pero al parecer como estoy ejecutando el comando como ernesto el cual no tiene privilegios, entonces no escribe nada en el log.

    Saludos!

    • febrero 23, 2012 en 8:53 am

      Si el fichero httpd.conf que has encontrado se encuentra vacio, ese no es el fichero que esta utilizando tu servidor cuando arranca.
      Consejo:
      Descarga, descomprime e instala la ultima versión de Apache en un directorio que controles.

  7. (.S)
    enero 25, 2013 en 1:22 pm

    Gracias por la info, siempre esta genial. Una pregunta… si el servicio trae un usuario por defecto como por ejemplo oracle, y a este le dejamos /bin/false como shell en caso de que nos exploten el servicio, ¿¿es posible hacerse con root??

  8. (.S)
    enero 25, 2013 en 1:34 pm

    Perdona por comentar en una entrada tan antigua. Una pregunta… si un servicio viene con un usuario por defecto como oracle… si le asigno una shell /bin/false e inicio el servicio como root, ¿¿seria posible al explotarlo hacerse con una shell y elevar a root aunque ps me muestre como usuario el de oracle??

    Saludos.

    • enero 25, 2013 en 6:16 pm

      El hecho de que un atacante no tenga una shell en el sistema objetivo, no significa que no pueda ejecutar comandos por otros medios. Todo depende del vector de ataque.

  1. julio 12, 2012 en 5:01 pm

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.119 seguidores

A %d blogueros les gusta esto: