[LACNIC/Seguridad] Dudas ante servidor Apache/PHP comprometido

[Nicolás Ruiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hola Xavier:

Recién ahora me estoy poniendo al dia con lacnic-seguridad.

Xavier Garcia Usero wrote:
> On Sun, Oct 21, 2007 at 12:01:14AM -0300, Luis León Cárdenas Graide wrote:
>  
>> IMHO, el que tenga los mismos archivos abiertos no quiere decir que
>> herede los descriptores. Si se inyectó código, efectivamente puede
>> ejecutarse un shell (o comandos a ejecuar por el shell, como bien
>> dices, vía system), con los privilegios del demonio inyectado
>> (apache:apache, en este caso). Así, al levantar un nuevo proceso Perl,
>> éste corre como apache:apache y puede abrir los logs por su cuenta.
> 
> Pero, a mi entender abrir los logs de Apache no es una práctica habitual para un 'script kiddie'.
> En mi opinión su interés es conectar el bot a un servidor IRC y utilizarlo para
> su provecho.
> 
> Es lo que me parece raro del ataque y lo único que no me
> cuadra del todo debido a que el usuario 'apache' solo tiene derechos de
> lectura sobre esos ficheros: "644 root.root". A mi entender Apache hace
> un fork y un drop de los privilegios antes de atender las peticiones.

Efectivamente apache descarta privilegios antes de comenzar a atender
peticiones, pero mantiene los archivos (ficheros) abiertos. De "man fork":

*   The child inherits copies of the parent's set of open file descrip-
    tors.  Each file descriptor in the child refers to  the  same  open
    file description (see open(2)) as the corresponding file descriptor
    in the parent.  This means that the two descriptors share open file
    status flags, current file offset, and signal-driven I/O attributes
    (see the description of F_SETOWN and F_SETSIG in fcntl(2)).

Es decir, el proceso creado hereda la lista de descriptores de archivos
abiertos del padre, los logs de Apache en este caso. Según entiendo, si
los archivos fueron abierto para lectura/escritura, tanto el apache sin
privilegios como el proceso hijo todavia pueden hacerlo.

> 
> 
> 
>  
>> Por otra parte, para buscar en el log la posible intrusión, donde
>> quedan registradas las URLs de las queryes GET, dado que buscamos
>> inyecciones de código, buscaría por los caracteres de comilla simple
>> (') o doble (") en las URLS (o bien, sus respectivas codificaciones
>> hexagesimales vía %hh). Si tu aplicación no suele enviar parámetros
>> que contengan estos caracteres, podrías llegar "rápidamente" a las
>> URLs que provocaron la inyección (apostando a que hayan sido GET).
>>
>> ¿Sabes por cuál de todos tus scripts PHP entraron?
> 
> 
> Este es el principal problema.  Es una práctica habitual el enviar esos
> carácteres y URLs dentro de la 'querystring'. Todavía estoy analizando
> los logs y va a necesitar su tiempo encontrar el origen del ataque,
> en caso que se trate de una petición GET. Como comento, no seria de
> estrañar que se pudiera tratar de una petición POST, conociendo la
> aplicación. Por ejemplo, un ataque a xmlrcp...
> 
> Se podria utilizar mod_security o otro tipo de firewall de aplicación (o snort_inline) para
> evitar ese tipo de ataques pero no entró dentro de la política de empresa muy a mi pesar.
> 
> 
>> Por favor, no creas que intento hacer leña del árbol caído, pero yo me
>> replantearía el uso de PHP en un servidor de seguridad relevante. A
>> comienzos de este año renunció el responsable de seguridad del equipo
>> de desarrollo del PHP, hastiado por la nula consideración de ésta
>> durante el diseño e implementación del lenguaje.
> 
> He seguido con mucho interés y preocupación los comentarios de Stefan Esser sobre los
> problemas de seguridad de PHP y su relación con el equipo de desarrollo.
> He de decir también que comparto al 100% tu argumentación pero una
> empresa de desarrollo no puede cambiar de la noche al dia el lenguaje de
> programación utilizado.
> 
> Ante la necesidad de segui utilizando PHP, se pueden realizar ciertos 'workarrounds' como
> chroots por dominio virtual con fastcgi i PHP en modo cgi.
> 
> http://www.seaoffire.net/fcgi-faq.html
> 
> El diseño de red, políticas de firewall restrictivas tanto del tráfico
> de entrada como el tráfico de salida  y firewalls de aplicación también pueden ayudar.
> 
> 
> Como digo en el correo original, mi intención no es pedir información
> para asegurar un servicio web pobremente asegurado. Es mi trabajo y no
> el vuestro.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad

- --
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
- --
Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
nicolas en ula.ve       | Mérida - Venezuela
PGP Key fingerprint = CDA7 9892 50F7 22F8 E379  08DA 9A3B 194B D641 C6FF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQSeXmjsZS9ZBxv8RAlzzAJ9gmLWbivoPdG+tVmlxJQ2gpw1O3gCeNcuk
xomtejLffbeAg7P7wWssZhc=
=tZ1C
-----END PGP SIGNATURE-----