Consejos para quitar malware de WordPress

Consejos para quitar malware de WordPress

ByLuis

No es la primera vez que me toca buscar malware en algún WordPress, y la verdad, suele ser un dolor de cabeza. Básicamente usan dos funciones: eval y base64_decode. Con eval nos meterán el código malicioso, que estará codificado en base64 para evitar que lo encontremos fácilmente.

Si tenéis acceso al SSH del servidor, una llamada a find . -name '*.php' -exec grep -l 'base64' {} \; suele bastar para encontrar este tipo de llamadas, o buscar eval en vez de base64.

Desgraciadamente esto no siempre funciona, ya que la función eval puede estar codificada de la siguiente forma:

$foo = "b"."a"."s"."e"...;
$code = 'ev'.'al($a);';$s = create_function('$a',$code);

Otro punto a tener en cuenta es la posibilidad de que hayan modificado el código de nuestro WordPress, lo cual se puede solucionar reinstalando el WP desde el admin. Aunque también pueden haber modificado el wp-config.php e incluir un fichero php que aparenta ser de WP (normalmente metindo en la carpeta wp-includes) pero que no lo es. Por lo cual es recomendado comprobar el wp-config.php con cualquier versión en local.

A parte de todo esto, es importante el tema de los permisos de los ficheros, etc…

Actualización 29/05/2015: también es aconsejable buscar esta cadena \142\x61\163\145\66\x34\x5f\144\x65\143\x6f\144\145, ya que al hacer un echo nos devuelve la función base64_decode.

Actualización 02/07/2015: buscar también la cadena \x65\x76\x61\x6c, ya que devuelve la función eval.

|

NoSQL Databases and Security

ByLuis

NoSQL Databases and Security: Jeff Darcy writes about NoSQL systems’ security (actually the lack of): Most NoSQL stores have no concept of security. […] Mostly it falls into two categories: encryption and authentication/authorization (collectively “a …

Post original

XSS Rays: javascript que detecta vectores XSS

ByLuis

XSS Rays es un script que permite detectar vectores XSS en cualquier página web. Debemos instalar en un servidor web (puede ser en local) y añadir a nuestros marcadores o favoritos para poder ejecutarlo sobre cualquier página que visitemos.
Funciona para IE y FF, aunque puede funcionar en otros navegadores, además se pueden personalizar los vectores para cada navegador.
La ejecución es sencilla, accedes al marcador, empiezas el test y te va mostrando las incidencias que encuentra (si es que las hay).
XSS Rays
Vía / lajevardi

Clasificación de amenazas Web

ByLuis

Algo a tener en cuenta cuando realizamos una aplicación web son los ataques que podemos recibir, para así estar preparados contra ellos y tomar soluciones al respecto.
En Web Application Security Consortium han realizado un documento que pretende “desarrollar y promover una terminología estándar para la industria que describa estos aspectos. Desarrolladores de aplicaciones, profesionales de la seguridad, fabricantes de software y auditores, tendrán la capacidad de disponer de un lenguaje consistente para tratar los aspectos relacionados con la seguridad web“.
El documento, disponible en español, nos muestra los distintos tipos de ataques que nos podemos encontrar (autenticación, autorización, por parte del cliente, ejecución de comandos, revelación de información y ataques lógicos), y nos explica posibles soluciones y referencias para obtener más información.
Web Security Threat Classification (espa̱ol) РPDF

20 cosas para volver segura tu configuración de Apache

ByLuis

Os presento una lista que he encontrado de 20 cosas que se pueden hacer para volver más segura tu configuración de Apache:

  • Antes de nada, asegurate de que tienes instalados todos los parches de seguridad.
  • Oculta la versión de Apache y otra información sensible.
  • Asegúrate de que Apache se ejecuta con su usuario propio y su grupo de usuarios.
  • Los ficheros fuera del web root no deben ser accesibles.
  • Desactiva el listado de directorios.
  • Desactiva los server side includes.
  • Desactiva la ejecución de CGIs.
  • No permitir que Apache siga los symbolic links.
  • No permitas opciones de una única vez.
  • Desactiva el soporte a .htaccess.
  • Usa mod_security.
  • Desactiva módulos innecesarios.
  • Asegurate que solo el root tiene acceso al fichero de configuración de Apache y a los binarios.
  • Disminuye el valor del timeout.
  • Limita el tamaño de las requests.
  • Limita el tamaño del cuerpo de un XML.
  • Limita la concurrencia.
  • Restringe el acceso mediante IP.
  • Ajusta las opciones de KeepAlive.
  • Ejecuta Apache en un entorno Chroot.

20 ways to Secure your Apache Configuration

Proteger tu aplicación web

ByLuis

Interesantísimo artículo que nos guía a proteger nuestra aplicación web para evitar posibles ataques. Haciendo un corto resumen, separamos las distintas acciones que debemos seguir en:

  • Validar todas nuestras entradas (variables de sesión y formularios). Los datos deben ser lo que se esperan, y si se esperan desde POST, que no vengan desde GET.
  • Evitar el cross-site scripting (XSS) que es la introducción maliciosa de código mediante formularios que se ejecutará en nuestra aplicación.
  • Modificar el fichero de configuración php.ini para que no use super globals, para mostrar todos los errores y que estos se muestren por fichero.
  • Asegurar la conexión a la base de datos. Este método no lo conocía y la verdad es que me ha gustado bastante.
  • Bloquear IPs de hackers, ya sea mediante PHP o htaccess
  • Si el otro día hablábamos del LDAP, ahora nos hablan del LDAP injection, otra cosa que no sabía (no, si ya he dicho que es un buen artículo).
  • Evitar que Google proporcione datos que no queremos (Google Hacking), para ello lo mejor es usar el robots.txt.
  • Restringir el acceso mediante .htaccess

Protecting your Site

Vía / dzone

10 signos de una aplicación web insegura

ByLuis

Interesante lista de puntos que pueden evidenciar que nuestra aplicación web tiene problemas de seguridad:

Top 10 Signs You Have an Insecure Web App

Vía / dzone

Configura tu PHP de forma segura

ByLuis

PHP viene por defecto configurado para desarrollo, pero en producción hay opciones que no son recomendables sobre todo por temas de seguridad. Cambiad en el php.ini las siguientes opciones para mejorar la seguridad en tu entorno de producción:

  • Desactiva el acceso a ficheros remotos: las funciones fopen, file_get_contents, y include permiten el acceso a ficheros remotos (http://host/..), lo cual puede dar problema en temas de seguridad. Si necesitas acceder a ficheros remotos puedes usar fsockopen o funciones de CURL.
allow_url_fopen = Off
  • Register globals: aunque ahora viene por defecto desactivado, en versiones anteriores de PHP, los parámetros de entrada se registraban como variables globales.
register_globals = Off
  • Restringe a qué ficheros puede acceder PHP: normalmente PHP solo necesita acceder a ficheros situados en cierto path, por lo que para evitar que se acceda a otros paths, es conveniente restringir su acceso.
open_basedir = /www/ficheros
  • Modo seguro: PHP dispone de un modo seguro, en el que Apache solo puede acceder a ficheros de los que sea dueño, aunque nos puede dar problemas sobre todo cuando se trabaja en grupo, la tranquilidad que nos aporta pesa más que este inconveniente. Para ello usaremos una propiedad para que solo ejecute scripts que le pertenecen y otra permite acceso a los ficheros que pertenecen al grupo de Apache aun cual sea el dueño.
safe_mode = Off
safe_mode_gid = On
  • Acceso permitido a ficheros binarios: el modo seguro tampoco permite ejecutar ficheros binarios, pero se le puede indicar en que ruta si se pueden ejecutar.
safe_mode_exec_dir = /www/ejecutables
  • Acceso a variables de entorno: tampoco está permitido acceder a variables de entorno en el modo seguro, pero se puede inluir una lista (separada por comas) de prefijos que se permiten para estas variables.
safe_mode_allowed_env_vars = PHP_
  • Controlar límites: también es conveniente controlar ciertos límites, como el tiempo de ejecución, el de tamaño máximo subido y muchos otros.
max_execution_time = 30 ; Tiempo máximo de ejecución
max_input_time = 60 ; Tiempo máximo que trata la entrada
memory_limit = 16M ; Memoria máxima para la ejecución de un script
upload_max_filesize = 2M ; Tamaño máximo de un fichero para subir
post_max_size = 8M ; Tamaño máximo de un POST
  • Control de acceso a ficheros mediante Apache: aunque en este caso se debe configurar Apache, tampoco biene mal el contarlo. Se trata de evitar que Apache acceda a ficheros importantes, por ejemplo ficheros .inc, .sql.
<FilesMatch "\.(inc|.*sql)$">
Order allow,deny
Deny from all
</FilesMatch>
  • Evita el acceso a la shell: Taufpate nos recomienda también evitar que se intente acceder a la shell. Si tienes un server y das hosting tienes que tener cuidado con los usuarios que usan mambo, phpnuke, jooomla, etc.., sistemas que a diario reportan problemas de seguridad y nunca son actualizados por sus usuarios.
    • disable_functions = system, exec, shell_exec, passthru, pcntl_exec, putenv, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, popen, pclose, set_time_limit, ini_alter, virtual, openlog, escapeshellcmd, escapeshellarg, dl, curl_exec, parse_ini_file, show_source

Checklist for Securing PHP Configuration

Vía / dzone

Firefox depurará su código

ByLuis

firefox.pngMozilla pretende que las próximas versiones y funcionalidades que se incorporen a Firefox sean más seguras, para ello ha contratado a la anterior jefa de seguridad de Microsoft y ex-hacker. Según la nueva “Chief Security Something”.

Deseamos reducir el riesgo general de Firefox evaluando constantemente donde hay funcionalidad no aprovechada, desechando luego el código antiguo.

Mientras que las antiguas funcionalidades pretenden usarlas como extensiones y no como parte de código completo, también quieren aumentar la seguridad del navegador como integrando la nueva herramienta de anti-phishing de Firefox 2.0, y evitar que código maligno escriba en la memoria.

|

Evitar Cross-Site Request Forgeries en PHP

ByLuis

Siempre que hagamos una aplicación web, tenemos que tener muy encuenta las cuestiones de seguridad, sobre todo las formas más conocidas de ataque. Una de estas formas es Cross-Site Request Forgeries, que más o menos viene a decir Falsificación de Petición desde Otro Sitio (quizás la traducción no es exacta, pero creo que lo explica bien).

Este ataque se produce cuando a un usuario se le conceden permisos, confiando en él, pero no teniendo en cuenta que otra gente pueda aprovecharse de ello. Supongamos que tenemos una página de compra de artículos, cuya aplicación controla perfectamente los campos de entrada y que tiene una función que realiza la operación de compra de artículos.

Tenemos el formulario HTML:

<form action="compra.php" method="POST">
Artículo: <input type="text" name="articulo" />
Cantidad: <input type="text" name="Cantidad" />
<input type="submit" value="Comprar" />
</form>

El primer fallo que solemos cometer es leer las variables de entrada mediante $_REQUEST:

<?php
session_start();
if (isset($_REQUEST['articulo'] &&
isset($_REQUEST['cantidad'])) {
compra($_REQUEST['articulo'],
$_REQUEST['cantidad']);
}
?>

Una forma muy utilizada para realizar un ataque y que al autor del artículo le gusta mucho, es mediante el uso de una imagen:

<img src="http://ejemplo.org/compra.php?articulo=CAFETERA&cantidad=1000" alt="ads" />

Con esto conseguimos que el usuario que visita nuestra página tambien haga una petición a la página en cuestión sin que él lo sepa, claro, que esto solo funciona si el usuario a la vez tiene una sesión abierta en la página que se está atacando.

La solución es añadir una marca formada por un número “encriptado” y un tiempo para que tenga que renovarse esta marca. La marca se debe crear y pasar en el formulario por el que se envían los datos y a parte se debe controlar su existencia, si coincide y si no ha superado el timeout.

<?php
$marca = md5(uniqid(rand(), TRUE));
$_SESSION['marca'] = $token;
$_SESSION['tiempo_marca'] = time();
?>
<form action="compra.php" method="POST">
<input type="hidden" name="marca" value="<?php echo $marca; ?>" />
Artículo: <input type="text" name="articulo" />
Cantidad: <input type="text" name="Cantidad" />
<input type="submit" value="Comprar" />
</form>
<?php
if ($_POST['marca'] == $_SESSION['marca']) {
$diferencia_tiempo_marca = time() - $_SESSION['tiempo_marca'];
if ($diferencia_tiempo_marca <= 300) {
/* Menos de 5 minutos */
}
}
?>

Artículo original: Security Corner: Cross-Site Request Forgeries

Vía / backdraft