Seguridad en WordPress

Tras el ataque sufrido en Lobosoft me he visto obligado a adelantar un poco la dedicación al blog (que tenía pensado incrementar, como ya dije, hacia mediados de junio), llevar a cabo una limpieza del mismo y actualizar, ya no la versión del mismo pero sí algunos plugins que podrían estar en el origen del ataque (fallo por mi parte al utilizar demasiados, aunque alguna de la funcionalidad extendidad del blog está basada, mucho me temo, en ellos).

El script que “me colaron” básicamente se encarga de permitir al atacante subir un archivo a la web con lo cual, dicho pronto y claro, la seguridad completa del sitio queda claramente comprometida. He estado buscando en Internet y parece que es un script genérico que ha sido instalado en numerosos servidores, sobre todo tipo de CMS y foros (y otras aplicaciones web), por lo que en sí no es más que una herramienta más que utilizar para atacar el sitio o usarlo como plataforma para fines oscuros y perversos. ;)

Uno de los blogs que he encontrado con el problema en cuestión es Brian's World, que muestra el código en cuestión. En mi caso no habían llegado ni tan siquiera a inyectarlo en uno de los archivos de Wordpress, sino que se encontraba replicado en varios archivos PHP con nombre similares (con un prefijo añadido) a los contenidos en un par de plugins y en el tema de Wordpress que da estilo al blog.
Dejo por aquí una extensa lista de referencias a la seguridad en Wordpress (algunas aplicables a otros CMS) que nunca está de más tener en cuenta. E incluso así, a pesar de lo que afirme nuestro amigo GigA, me temo que nada es demasiado seguro.

Feliz lectura.

Para saber más:

En castellano.

• Consejos para tener un WordPress seguro.
  
  
  
  • Crear una instalación de WordPress segura.
  
  
  • Mod-Security y WordPress: Defensa en profundidad.
  
  
  
  


• Cinco consejos de seguridad para WordPress.


• WordPress Security Cheat Sheet 1.0 (en español).


• ¿Cómo proteger tus blogs Wordpress de los hackers?


• Proteger el archivo wp-config.php.


• Cómo incrementar la seguridad de una web creada con Wordpress.


• 10 pasos para proteger tu panel de administrador.


• Reubicar wp-content y wp-config.php con Wordpress 2.6.


• (In)seguridad en WordPress, por Stefan Esser.

En inglés.

• Wordpress Security Whitepaper.


• Wordpress Security Tips and Hacks.


• WordPress Security – A Comprehensive Guide.


• 11 Best ways to improve WordPress Security.


• WordPress Security, Upgrades and Backups.


• 16 Excellent Wordpress Security Plugins To Secure Your Blog.


• Don’t Get Hacked: WordPress Security Tips.

Más allá de WordPress.

• .Htaccess rewrites, Mod_Rewrite Tricks and Tips.


• Web Site Test Tools and Site Management Tools.

La imagen que ilustra la entrada, que me ha encantado, es de Antivirus WordPress.

Primeros pasos con Reflexil (2)

En la entrada anterior veíamos cómo era posible utilizar Reflexil como plugin de Reflector para modificar el valor de una variable, en concreto la que comprobaba nuestra aplicación de ejemplo para permitir el acceso del usuario a la misma. Hoy veremos cómo es posible incluir código propio en un ensamblado .NET para modificar el funcionamiento de la aplicación (inyección de código).

Deseamos que, cuando el usuario haya accedido al programa “crackeado” este realice una serie de acciones; en el ejemplo consistirá únicamente en mostrar un mensaje en pantalla pero podría tratarse de cualquier tipo de comportamiento inesperado. Para ello, creamos una DLL que contiene el siguiente código, la compilamos y la llevamos a la carpeta donde tenemos nuestra aplicación “ContaConta”.

[csharp]
namespace EjemploReflexil
{
public class Sorpresa
{
public static void Infectar()
{
MessageBox.Show("¡Pardillo!", "Sorpresa",
MessageBoxButtons.AbortRetryIgnore,
MessageBoxIcon.Exclamation);
}
}
}
[/csharp]

Partiremos del ejecutable que obtuvimos en la entrada anterior tras sustituir el valor de la contraseña por una cadena vacía (ContaConta.Patched.exe), incluyéndolo en Reflector. El usuario ahora espera utilizar el programa modificado para no tener que introducir contraseña alguna. Cuando el usuario introduce la palabra esperada (ninguna en este caso), la aplicación ejecuta un método que muestra un mensaje de bienvenida. Vamos a insertar una llamada a nuestro método Infectar() de la clase Sorpresa justo cuando esto ocurra.

Lo primero que debemos hacer es incluir una referencia a nuestro ensamblado (Sorpresa.dll).

Damos simplemente el nombre del ensamblado que, recordemos, se encuentra en la misma carpeta que nuestra aplicación:

Reflexil nos avisa de que los cambios que realizamos sobre el código no son visibles de inmediato en las ventanas de Reflector, así que debemos salvar los cambios y proceder a recargar la DLL. Podemos hacerlo desde el menú contextual o en las opciones que habrán aparecido en la zona de trabajo del plugin.

Tras recargar la DLL vemos que el ensamblado aparece ahora referenciado:

Abrimos el código del método Hola(System.String) para proceder a incluir en él la llamada a Sorpresa.Infectar(). Nos situamos sobre la primera instrucción y seleccionamos la opción de crear una nueva operación. Será una llamada (MSIL call) al método que deseamos, de modo que configuramos en el cuadro de diálogo el tipo de operación y de operando.

Seleccionamos, dentro del ensamblado Sorpresa, el método que deseamos llamar

y guardamos los cambios indicando que inserte la operación antes de la que teníamos seleccionada para que esta nueva sea la primera que se ejecute. Ahora guardamos los cambios y ejecutamos la aplicación con el nuevo parche.

Tras pulsar cualquier botón terminaría la ejecución del código inyectado, por lo que la aplicación prosigue con la del código preexistente:

En próximas entradas veremos cómo podemos reemplazar por completo el código fuente de una determinada clase del ensamblado directamente en C# o Visual Basic.NET mediante la opción “Replace all with code...”

Primeros pasos con Reflexil (1)

Una de las ventajas de los compiladores que generan código intermedio es que las aplicaciones resultantes (ejecutables y librerías dinámicas) pueden desensamblarse con facilidad, reconstruyendo el código en su lenguaje original. Con .NET Framework esto es posible, incluso, obteniendo el código fuente descompilado al cualquier lenguaje de la CLI (Common Language Infrastructure), como bien sabréis, así que realizar un ejercicio de ingeniería inversa sobre sus ensamblados es algo, a priori (y sin ofuscador mediante), bastante ilustrativo.

Utilizando una de las herramientas que no puede faltar en la particular mochila virtual de cualquier desarrollador .NET, Reflector, es posible no solo descompilar el ensamblado sino incluso reconstruir un proyecto de Visual Studio que permita editarlo y volver a reconstruirlo. Sin embargo, podemos llegar más allá. Es posible, además, editar desde el propio Reflector un determinado ensamblado y modificar su funcionalidad utilizando el plugin Reflexil. Desarrollado por Sébastien Lebreton, se trata de un proyecto de código abierto que podemos incluir como dentro de los add-in de Reflector para extender su funcionalidad permitiéndonos alterar la funcionalidad de un determinado componente de la correspondiente aplicación ya sea inyectando código (en MSIL, C# o Visual Basic.NET) o modificando alguna de sus propiedades. He estado “jugando” un poco con el plugin y me ha gustado tanto que he decidido traerlo al blog aunque sea, de momento, con una introducción muy básica a algunas de las características que podemos encontrar en él.

Partimos de una aplicación realmente básica que simula un formulario de autenticación de usuarios que permitiría acceder a la misma. En nuestro ejemplo simplemente mostrará un mensaje indicando si el usuario introdujo la contraseña correcta o no. El sistema de protección es realmente rudimentario pero nos servirá a título de ejemplo para comenzar a familiarizarnos con Reflexil.

Si no lo hemos hecho antes, deberíamos bajarnos la última versión del plugin de su página oficial e instalarlo (simplemente descomprimirlo y agregarlo a Reflector a través de su menú View->Add-Ins).

Agregamos el ejecutable (o DLL) que deseamos analizar y modificar; en nuestro caso, ContaConta.exe. Si activamos el plugin (Tools->Reflexil vx.y ) veremos cómo, al acceder a un determinado método, campo o propiedad, aparecen diversas opciones que permiten modificar su tipo, los argumentos recibidos e, incluso, su comportamiento.

Por ejemplo, nuestra aplicación comprobaba simplemente si el usuario introducía el texto necesario para permitirle el paso. Una posible modificación sería eliminar esta palabra de paso. Si nos fijamos en las instrucciones en IL del método que se encarga de hacer la comprobación (el propio delegado que se suscribe al evento del clic de ratón sobre el botón Acceder) veremos que comienza situando en la pila de evaluación una referencia al objeto System.String que contiene la cadena a comparar (operación ldstr) para, a continuación, recuperar el valor que contiene el cuadro de texto donde el usuario introduce la contraseña y realizar una comparación entre ambas. Vamos a editar la cadena para sustituirla por una vacía. Para ello, accedemos al menú contextual de la primera instrucción pulsando de ella con el botón derecho del ratón y accedemos a la opción Edit. Veremos un pequeño cuadro de diálogo desde el que es posible editar el tipo de operación a realizar así como los argumentos con los que es llamada. Borramos de aquí el texto del argumento y aceptamos.

Tras ver cómo ha sido eliminado el valor del parámetro en la lista de argumentos, si queremos comprobar que el cambio ha tenido éxito debemos guardar el ensamblado. Para ello, en el árbol de ensamblados de Reflector pulsamos con el botón derecho sobre ContaConta para acceder al menú Reflexil->Save As… y le dejamos el valor predeterminado (ContaConta.Patched.exe).

Si ejecutamos ahora la aplicación y pulsamos simplemente en el botón de acceso veremos cómo nos deja pasar.

En la siguiente entrada veremos cómo inyectar código propio en un ensamblado .NET existente.

Creando una llave USB "casera" mediante código

Imaginemos que deseamos crear un sistema de seguridad para nuestro software basado en la comprobación de una llave hardware. Tradicionalmente, encontramos soluciones como el uso de disquetes con ciertas peculiaridades que impedían su grabación “normal”, por ejemplo mediante la inclusión en el mismo de sectores defectuosos o alterados que eran corregidos en la copia del disco, por lo que las copias eran inservibles para validar el software, evitando así (se supone) la duplicación no legal de estas aplicaciones. También se usaban llaves de encriptación, habitualmente conectadas al puerto serie, y últimamente es habitual el uso de llaves USB programables (del tipo de las llaves HASP) con este fin. Sin embargo, son dispositivos que tienen un precio si no elevado, sí al menos importante, y si lo que deseamos es proteger una aplicación cuyo coste no es demasiado elevado, puede costarnos, como suele decirse, más el collar que el perro. En la entrada de hoy quería usar un ejemplo, que se presenta únicamente (y el que avisa no es traidor) con fines didácticos y no como una solución real de seguridad, explicando cómo implantar la seguridad en el software basada en el uso de dispositivos USB de uso común, como un pendrive o memoria USB.

En la entrada de hoy crearemos un sistema de seguridad frente a la copia de nuestro software usando unidades de disco USB. Desarrollaremos una aplicación que sólo se ejecutará en presencia de una memoria USB que suministremos con el software. Podría servir incluso para distribuir la propia aplicación, y su capacidad no tiene por qué ser elevada.

Para conseguirlo, simplemente debemos obtener el número de serie del dispositivo (no el número de serie del volumen, que podemos obtener ejecutando el antiguo comando de MS-DOS vol sobre la unidad en cuestión, sino el número de serie físico), y con este número de serie convenientemente encriptado y almacenado en un archivo de configuración, llevar a cabo la comprobación en el inicio de la aplicación, o cuando deseemos comprobar si se trata de un software legalmente distribuido. El código para conseguirlo esto es sencillo. Imaginemos una aplicación de consola que verifica si tenemos conectado un determinado dispositivo USB. El código podría quedar como sigue:

[csharp]
class Program
{
static void Main(string[] args)
{
if (CheckUSB.CheckUSBKey())
Console.WriteLine("Llave USB detectada. Acceso permitido.");
else
Console.WriteLine("No se ha detectado la llave USB. Por favor, insértela y ejecute nuevamente la aplicación.");

Console.ReadLine();
}
}
[/csharp]

La comprobación viene dada por un método estático, CheckUSBKey, que devuelve un valor booleano tras comprobar el número de serie que hayamos especificado. Por simplicidad en el ejemplo, este valor es recuperado dentro del propio método.

[csharp]
static bool CheckUSBKey()
{
/* Este debería ser el valor adecuado del número de serie de nuestro dispositivo USB.
* Podríamos obtenerlo usando el método GetSerialNumber("letra_de_unidad") de la clase USBDrives,
* en el ensamblado USBSN.
*/
string _usbKeyAllowed = MiClaseConfiguracion.ObtenerNumeroSerieKEY() // un string con el número de serie que deseamos comprobar;
bool detected = false;

USBDrives usbDrive = new USBDrives();
string[] drives = Environment.GetLogicalDrives();

// Obtiene los nombres de los dispositivos, eliminando la \ de directorio
foreach (string strDrive in drives)
if (String.Equals(_usbKeyAllowed, usbDrive.GetSerialNumber(strDrive.Replace("\\", ""))))
detected = true;

return detected;
}
[/csharp]

Como vemos, simplemente recuperamos todas las unidades lógicas del equipo (entre las que se encuentran discos duros, unidades de disquete, CD o DVD, así como los discos USB que haya conectados en ese momento en el equipo. Para cada uno de ellos, comprueba si el número de serie devuelto es igual al del la llave USB que hemos utilizado, y que deberemos distribuir junto al programa. Hace uso de una clase, USBDrives, del espacio de nombres Lobosoft.Utilities.Disks, que viene incluido en el ensamblado adjunto, y que puede ser usado libremente. De momento incluye un único método, GetSerialNumber(string letra_unidad), que recibe una letra de unidad (vale tanto la letra en sí, por ejemplo "D", como el nombre de unidad, es decir, la letra seguida por dos puntos, "D:"), y devuelve una cadena de caracteres con el número de serie de esa unidad, si lo tiene, o la cadena vacía en caso contrario. En una próxima entrada veremos cómo funciona internamente esta clase.

La DLL de utilidad puede descargarse aquí:

Llave USB

Cómo saber si me han ELIMINADO del Messenger

Una de las páginas más visitadas de Lobosoft es la referente a la entrada sobre si nos tienen bloqueados o no en el Messenger. En ella, advierto sobre el peligro de usar páginas y programas en los que debemos introducir nuestro nombre de usuario y contraseña de MSN/Passport, como firma y rubrica de nuestro pacto con el diablo. Nos dirán quiénes nos tienen bloqueados, pero se quedarán con nuestro acceso a MSN.

Dado que se trata de una consulta tan recurrente, veremos hoy cómo comprobar si nos han ELIMINADO de Messenger (no sirve para ver si nos tienen bloqueados puntualmente, pero sí para ver si nos han borrado del mismo). Para ello no necesitaremos ningún programa, aparte del propio Messenger, claro está.

Accedemos al menú Opciones, y dentro del mismo a la pestaña Privacidad. En la misma podemos ver una lista de nuestros contactos y agregarlos a la lista de bloqueados, o restablecerlos como contactos deseados. Esta función es la misma que la de bloquear un contacto desde la lista de contactos que presenta Messenger en su uso cotidiano, aquella desde la que seleccionamos las personas con las que deseamos hablar.

 

Bien, dentro de esta pestaña hay una opción etiquetada como "¿Qué usuarios me agregaron a sus listas de contactos?". Si pulsamos en el botón Ver, aparecerá una lista de todos aquellos usuarios que nos tienen agregados como contactos suyos.

 

Es decir, estarán tanto aquellos usuarios que nos agregaron en su día, y nosotros aceptamos como contactos, como aquellos otros que agregamos por nuestra parte, y aceptaron nuestra solicitud.

Si el contacto que buscamos no aparece en la lista (y estuvo algún día) querrá decir que nos ha ELIMINADO de sus contactos de Messenger.

Fácil, sencillo, y sin dar nuestra cuenta a nadie.

Cómo saber si me tienen bloqueado en el Messenger…

"La ingeniería social es la práctica de obtener información confidencial a través de la manipulación de usuarios legítimos. Un ingeniero social usará comúnmente el teléfono o Internet para engañar a la gente y llevarla a revelar información sensible, o bien a violar las políticas de seguridad típicas. Con este método, los ingenieros sociales aprovechan la tendencia natural de la gente a confiar en su palabra, antes que aprovechar agujeros de seguridad en los sistemas informáticos. Generalmente se está de acuerdo en que los usuarios son el eslabón débil en seguridad; éste es el principio por el que se rige la ingeniería social."

(Fuente: Wikipedia)

Dadme vuestra dirección y contraseña de Messenger, y os diré quién os tiene bloqueados. Así rezan decenas de servicios en la web, tanto en páginas como aplicaciones de escritorio, que prometen proporcionarnos la información necesaria para discernir cuáles de nuestros contactos merecen nuestra amistad o no, en función de si han cometido la desfachatez de bloquearnos en un determinado momento. Y, en nuestro afán de controlar si nos controlan, no tenemos el menor reparo en proporcionar información tan sensible como nuestra contraseña de Messenger (que es la de Microsoft Passport, y puede brindar acceso a nuestro espacio personal, a nuestra cuenta de correo, a nuestros documentos en Office Live, así como a muchos otros servicios).

Lo peor es que la gente sigue cayendo ante este tipo de acciones regalando, por así decirlo, sus contraseñas. Hoy podemos perder nuestra cuenta de correo, y mañana podría ser el dinero de nuestra cuenta ante un ataque de phishing. Acciones que en el cine pueden parecernos risibles (como ya hablaba anteriormente frente al trato que en el cine se da a la Informática y a los informáticos) palidecen ante las que se llevan a cabo en la vida real, por estos excesos de confianza. Cuidado, por tanto, ante estos falsos profetas y, sobre todo, ante nosotros mismos. Somos, sin lugar a dudas, nuestro peor enemigo.

Actualizo 03/06/2008:

Incluyo entrada en el blog sobre cómo saber si nos han ELIMINADO del Messenger.

OpenID en ASP.NET

Elegir el método de autenticación y autorización de los usuarios de una aplicación y, más concretamente, de una aplicación web que permanece expuesta a la inclemencia de Internet, es siempre un factor determinante en la seguridad de los sistemas informáticos. En la plataforma .Net de Microsoft, los métodos de autenticación para una aplicación ASP.Net dependerán de los que proporciona el servidor web IIS, permitiendo por tanto tres tipos de autenticación: básica, implícita y Windows; podrá estar basada en formularios (usando cookies); o, por último, podremos hacer uso del servicio de Microsoft Passport.

Por otro lado, ASP.NET proporciona básicamente dos tipos de autorización: basada en la autorización de URL, que proporciona acceso a secciones el sitio web para una determinada identidad o mediante la comprobación de listas de control de acceso (ACLs) o permisos sobre recursos para determinar si el usuario autenticado puede tener acceso a los mismos (gestión de roles).

Toda esta gestión se configura mediante el archivo de configuración de la aplicación (usuamente, el web.config). Hasta aquí, simplemente hemos expuesto unas nociones sobre seguridad en una aplicación web ASP.Net.

Hace un par de meses conocí el proyecto OpenID, un estándar que brinda un sistema descentrado de identificación, permitiendo, para aquellos sitios web que le ofrezcan soporte, el acceso de los usuarios sin necesidad de crear una cuenta específica para el mismo. Simplemente necesitarán un proveedor de identidad (IdP). Dicho en pocas palabras y con un ejemplo de la vida real: Yahoo, que acaba de adoptar el estándar como proveedor de cuentas (OpenID 2.0), ha ganado casi 250 millones de usuarios potenciales. Es más, otro de los grandes de la informática, Google, comienza a flirtear con OpenID, permitiendo usarlo como sistema de identificación en los comentarios a las entradas de los blogs de Blogger. Y MediaWiki (el software que se encuentra tras la archiconocida Wikipedia), Wordpress o Drupal ya incorporan, o están en fase de hacerlo, ésta tecnología.

¿Y Microsoft, que pinta en todo esto? Bueno, de momento sigue haciendo la guerra por su cuenta con el lanzamiento de Windows CardSpace, un gestor de cuentas de identidad, incorporado “de serie” en el .Net Framework 3.5. Podemos encontrar en SandBox una página de ejemplo sobre el uso de esta tecnología.

Así las cosas, y visto que OpenID es un estándar dispuesto a quedarse, ¿cómo llevarlo a nuestras aplicaciones ASP.NET?

A grandes rasgos, el funcionamiento de OpenID es el siguiente: el usuario crea un identificador en un servidor que verifique OpenID, y el proveedor de identidad confirmará entonces la identificación del usuario a los sitios que soporten este sistema.
El usuario obtiene, tras este registro, una simple URL (o más concretamente un XRI) que puede usar para identificarse. Es más, si posee una página web puede incluir unas etiquetas “META” en la misma, y usar su propio dominio como código de identificación.

Con OpenID nos encontramos, por tanto, ante una arquitectura Single Sign-On que no especifica el mecanismo de autenticación, por lo que la seguridad de la conexión dependerá de la confianza del cliente en el proveedor de identidad. Según sea la implementación de éste se ofrecerá una autenticación más o menos fuerte, y una mayor seguridad en el sistema.

Así, si queremos que nuestra aplicación web sea compatible con el nuevo estándar, la implementación irá a cargo de las librerías (de código abierto, como el resto del proyecto) que proporciona el sitio web oficial de OpenID.
En concreto, las existentes hasta el momento para .Net se encuentran en C#, y son:

.net OpenID
NerdBank ASP.NET OpenID control
ExtremeSwank OpenID Consumer

Una implementación sencilla del acceso a un proveedor de identidad consiste, básicamente, en solicitar al usuario su identificador y requerir al proveedor de identidad los datos necesarios. En el proveedor, el usuario gestionará si quiere proporcionar a nuestra aplicación sus datos siempre, o sólo en esa ocasión. Los datos que nos proporcionará el usuario dependerán de su elección, siendo obligatorio proporcionar su e-mail y su nombre, y opcional el resto de información de su perfil. A continuación se puede ver el esquema de identificación que sigue OpenID.

Y, por último, muestro en unas pocas capturas el funcionamiento de una página de acceso a la que he incorporado identificación mediante OpenID.

En primer lugar, el usuario accede a nuestra aplicación web, y solicitamos su identificador.

A continuación, se realiza la petición de autenticación ante el proveedor de identificación:

Cuando el usuario se autentica, el Proveedor de Identidad le solicita que indique la información que desea transmitirnos. Obligatoriamente deberá indicar su nombre y e-mail, y opcionalmente otra información de su perfil. Además, podrá denegar el envío, o permitirlo una vez o siempre.

Por último, la información es devuelta a la aplicación, que puede leerla en los parámetros de la URL.

Y, para todo ello, el código es tan simple como esto:

Referencias:

• Web oficial del proyecto.


• Wikipedia - OpenID.


• OpenID.es