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

Xavier Garcia Usero xavier en hades.udg.es
Dom Oct 21 10:05:51 BRST 2007


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.



 
> 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.


-- 
Xavier Garcia Usero aka msk

Associació d'Estudiants d'Informàtica de Girona
http://hades.udg.edu/~xavier/
Unix i seguretat a la xarxa


pgp key ID: 0xD94E70A1
http://pgp.mit.edu/

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: no disponible
Type: application/pgp-signature
Size: 186 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20071021/722da6cf/attachment.sig>


Más información sobre la lista de distribución Seguridad