Iloo

https://iloo.wordpress.com

Archivos por Etiqueta: CentOS

PHP: error al subir archivos por FTP

php-logo

 

En este caso las características son las siguientes:

  • Servidor CenOS 6 (origen).
  • PHP 5.5.
  • iptables activado.

El script (resumido) que se esta usando para subir el archivo es:

$connection = ftp_connect($hostname, 21);
ftp_login($connection, $user, $password);
ftp_put($connection, $ftp_path, $local_file, FTP_ASCII);

El problema es que el script se detiene en la tercera linea, no se corta ni muestra un mensaje de error y por tanto no se sube el archivo ni termina de procesarse todo el código.

El primer paso seria desactivar iptables y verificar el código:

service iptables stop

Y ahora si, el script funciona perfectamente.

En este caso el problema esta en iptables, probamos que activando el modo pasivo para ftp de la siguiente manera:

modprobe ip_conntrack_ft

Y volver a verificar el script, si funciona entonces agregar el modulo cada vez que se inicie iptables, editar el siguiente archivo:

nano /etc/sysconfig/iptables-config

Y agregar el modulo propiamente dicho:

IPTABLES_MODULES="ip_conntrack_ftp"

Y reiniciar el servicio:

service iptables start

 

Ruby on Rails: RVM is not a function

Ruby_on_Rails_logo

Los detalles:

  • CentOS 6
  • RVM
  • Rails 1.9.3

Los pasos.

  1. Instalación RVM, todo correcto.
  2. Instalación ruby 1.9.3, todo correcto.

En la aplicación instalación de gemas y demás:

bundle install

Your Ruby version is 2.1.0, but your Gemfile specified 1.9.3

Cambiar la versión de ruby usada en rvm:

rvm use 1.9.3

RVM is not a function, selecting rubies with ‘rvm use …’ will not work.

La solución, cambiar la shell por defecto:

chsh -s /bin/bash usuario

CentOS: “daemonizar” scripts PHP

Un problema con el que estuve sufriendo peleando por un buen rato fue el de tener scripts PHP funcionando todo el tiempo.

El problema era que no se podía usar cronjobs, ya que los scripts funcionaban con gearman (del cual escribiré en otro post) y tenían que estar a la espera de ser invocados y realizar una determinada tarea, la cual tiene un tiempo variable y por tanto no se puede usar cron.

Las características debían ser de poder iniciar los scripts PHP y tenerlos como servicios o demonios, a demás de poder pararlos en cualquier momento, generalmente para hacer alguna modificación.

Después de buscar por un rato llegue con estas dos soluciones:

  1. Usar System_Daemon.
  2. Usar Supervisor.

Obviamente ninguna de las dos formas funciono, la verdad es que no pude instalar ninguno de ellos (por problemas de dependencias, alertas, etc). Entonces la solución sería hacer uno mismo el script, y aquí lo tenemos:

#!/bin/sh
# description: start php script

. /etc/rc.d/init.d/functions

pathworker=/home/user/public_html/script.php

start() {
        echo -n "Starting script"
        daemon php "$pathworker&"
}

stop() {
        echo -n "Stopping script"
        killproc php "$pathworker"
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        stop
        start
        ;;
    *)
        echo $"Usage: $prog {start|stop|restart}"
esac

Es claro que el script es bastante sencillo pero cumple con su función y eso es lo importante, supongamos que lo llamamos phpd, tiene que estar en /etc/init.d. Claro antes tiene que tener permisos de ejecución:

sudo chmod +x /etc/init.d/phpd

Para iniciar el demonio:

/etc/init.d/phpd start

Para pararlo:

/etc/init.d/phpd stop

Y eso sería prácticamente todo, ahora si se quiere daemonizar varios scripts PHP a la vez se puede modificar el script quedando de la siguiente manera:

#!/bin/sh
# description: start php script

. /etc/rc.d/init.d/functions

pathworker=/home/user/public_html/list

start() {
        echo -n "Starting script"
        daemon "$pathworker&"
}

stop() {
        echo -n "Stopping script"
        killproc php "$pathworker"
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        stop
        start
        ;;
    *)
        echo $"Usage: $prog {start|stop|restart}"
esac

Donde el archivo list contendría los scripts PHP que se desean daemonizar:

#!/bin/sh
php /home/user/public_html/script1.php &&
php /home/user/public_html/script2.php &&
php /home/user/public_html/script3.php;

Nota: al hacer esto hay un problema y es que no se pueden parar todos los demonios iniciados con el comando stop, si no que habría que hacerlo manualmente.

Web Applications Security: www.fps.gov.bo (2)

Ya hecho el análisis de la parte del diseño vayamos con el tema de desarrollo, más propiamente la parte de seguridad.
Inicialmente haciendo un análisis con wapiti obtenemos el siguiente informe:

1. La barra de color rojo indica que hay 2 vulnerabilidades de inyección sql ciega (blind SQL)

Recomendación: las entradas de información que el usuario introduce en la aplicación no deben ser directamente colocadas en sentencias SQL, antes tienen que ser filtradas para evitar ejecuciones malignas en la sentencia SQL.

2. La barra de color naranja indica que existen 7 vulnerabilidades de consumo de recursos, el atacante puede forzar al servidor a consumir muchos recursos y potencialmente provocar un fallo del servidor (Asymmetric resource consumption).

Recomendación: configurar adecuadamente el servidor para evitar el consumo de memoria o la caída del sistema.

Bien ahora vayamos a explotar vulnerabilidades de manera manual:

3. En el siguiente enlace podemos observar otra vulnerabilidad (SQL injection):

http://www.fps.gov.bo/marco_institucional/detalles.php?area=mision%27%20AND%20%271%27=%271

Recomendación: ver punto 1.

4. Revisando un poco el sitio nos encontramos con el siguiente enlace:

http://www.fps.gov.bo/funciones/gestor_descarga.php?dir=sis_gestion_ambiental&file=MANUAL%20DE%20GESTION%20AMBIENTAL.pdf

Es aquí donde hay un error crítico (al parecer el desarrollador no puso mucha dedicación en depurar los errores) el error es un Source Code Disclosure (mi vulnerabilidad favorita).

El error consiste principalmente en que el archivo gestor_descarga.php permite descargar cualquier archivo (incluyendo archivos del sistema).

Ahora lo que sigue es primero descargar el mismo archivo o el archivo index.php, esto para poder ver el archivo de configuración para el acceso a la base de datos, cuyo nombre es  dbconn.php

También se puede descargar el archivo passwd:

Recomendación: reescribir el archivo para no permitir descargar archivos que no se encuentren en un determinado directorio o tener un enlace directo al archivo que se quiere descargar, obviando por consiguiente el archivo encargado de las descargas..

5. Conexión remota a la base de datos, si bien esto puede ser muy útil para el administrador puede ser un punto crítico como en este caso, ya teniendo los datos de usuario y contraseña del servidor mysql podemos conectarnos con este:

Y realizar algunas consultas:

Recomendación: Realizar un mejor portal ya que este puede ser un punto de acceso al servidor (como en este caso) o restringir el acceso remoto a mysql, Un punto que esta fuera de la seguridad es el de la base de datos personalmente no soy un experto pero siempre se recomienda tener un campo de indexación (generalmente llamado id de tipo entero) para realizar búsquedas, ordenamientos, ya que por ejemplo en este caso de la tabla usuario pasar un parámetro entero es mejor que pasar el nombre de usuario, también el uso de la codificación (utf-8) de la base de datos ya que aparecen unos caracteres extraños XD.

Para concluir no importa cuan seguro este el servidor (en este caso CentOS 5), que el administrador del servidor lo controle constantemente y que tan preparado este este, en este caso no contó con que una aplicación pudiera ser un punto fuerte de inseguridad para su servidor, por tanto se tiene que poner mucha dedicación y esfuerzo no solo en el desarrollo de la aplicación si no también en la parte de pruebas de seguridad, ya que compromete información muy valiosa.