WordPress: SQL Injection Bug en Scarcity Builder Plugin

Chema Alonzo

de www.elladodelmal.com 

Hace unas semanas, un joven investigador de seguridad venezolano llamado KelvinSecurity se puso en contacto conmigo para contarme que se había topado con un bug de SQL Injection en un plugin para WordPress llamado Scarcity Builder, que se utiliza para generar contadores de marketing en sitios web creados sobre WordPress con el objetivo de que generen presión en los visitantes para forzar una acción. Cosas de la gente de marketing, ya sabes.

Figura 1: Bug de SQL Injection en Scarcity Builder para WordPress

El caso es que el bug era un 0day porque incluso la web del propio fabricante era vulnerable a este fallo, así que decidimos ponernos en contacto con los desarrolladores y se abrió un ticket de soporte. La empresa que está detrás de él, llamada Digital KickStart, solucionó el fallo y respondió con una nueva actualización del mismo, tal y como puedes ver en la siguiente imagen.

Figura 2: Confirmación de que han solucionado el bug en la versión 2.2.10

Sin embargo, el bug, que es un SQL Injection de libro y que se encuentra fácilmente usando Havij o cualquier otro escanner de vulnerabilidades web, está aún por desgracia en muchas páginas web con WordPress, ya que la empresa no ha hecho un Security Advisory o similar.

Figura 3: Explotación del bug en un WordPress vulnerable con Havij

El SQL Injection se encuentra en concreto en: 

wp-content/plugins/scarcitybuilder/shortcode/index.php?edit=

Por supuesto, con un SQL Injection como esté, se puede extraer toda la información de WordPress, incluidos, usuarios, contraseñas e información confidencial que se encuentre guardada en la base de datos o accesible desde ella en el servidor.

Figura 4: Extracción de información con el bug en el plugin Scarcity Builder

El plugin no es demasiado común - seguramente porque es un plugin de pago - y solo aparecen algo más de 800 sitios indexados en Google que lo tengan funcionando, pero el bug es tan fácil de localizar y explotar de forma automatizada que espero que hagan un aviso directo a los clientes haciéndoles entender el riesgo de no actualizar a esta versión.

Figura 5: Número de WordPress con este plugin instalado, localizados vía Google

Si tienes WordPress con este plugin, actualízalo ya. Si tienes clientes con WordPress, avísales de este riesgo de seguridad para que tomen medidas urgentes y, a ser posible, que tengan procedimientos y herramientas para actualizar automáticamente los plugins. No olvides que tienes herramientas como WPHardening para fortificar WordPress, y que tú además puedes puedes fortificar WordPress con configuraciones más seguras.

Las 15 cosas más terroríficas de hackear (infografía)

Estamos en el inicio de Internet de las cosas (IoT), donde una multitud de dispositivos interconectados presentarán un paraíso para los hackers. Una nueva infografía en Web Hosting Buzz presenta algunos escenarios escalofriantes en los que un atacante podría comprometer las tecnologías actuales que transcienden al mundo físico con el consiguiente aumento del riesgo.

Las amenazas van desde el hacking de electrodomésticos, monitores para bebés o neveras inteligentes hasta habitaciones de hotel e incluso aeropuertos y reactores nucleares.

A principios de este año, hackers comprometieron 100.000 electrodomésticos inteligentes y los utilizaron para enviar 750.000 mensajes de spam.
En abril, una pareja de Estados Unidos se despertó con el sonido de un hombre gritando "wake up baby" a través de su monitor de bebé inalámbrico.
Este verano un consultor de seguridad usando sólo un iPad fue capaz de tomar el control de las luces, las temperaturas y las persianas de 200 habitaciones de un hotel en China.
Muchos cajeros automáticos en todo el mundo siguen utilizando el obsoleto Windows XP. 
En junio de dos escolares canadienses hackearon los cajeros automáticos de Montreal antes avisar del riesgo al banco.
Los automóviles de hoy en día contienen 50 o más unidades de control electrónico y los hackers pronto serán capaces de desbloquear y arrancar el vehículo mediante el envío de un sencillo SMS. Ya se ha demostrado que es posible hackear cualquiera de los equipos de baja potencia en un auto moderno en menos de 10 segundos.

Hasta aquí en Tester´s ya hemos demostrado que muchos de los gadgets que tenemos en casa hoy pueden ser comprometidos.
Por no hablar de que las consecuencias podrían ser aún más importantes si tenemos en cuenta las plantas de energía, los equipos médicos e incluso los aviones que están ahora conectados a Internet...

Esta es una infografía no para generar temor, si no para que los fabricantes tomen conciencia y dediquen sus recursos a mejorar la seguridad de los productos (vaya semana llevamos de reivindicaciones XD):

Fuente: The 15 most hackable and terrifying things (infographic)

Cómo saber dónde está alguien por un chat de WhatsApp

No conocía esta característica, pero parece bastante peligroso que una persona pueda saber por qué dirección IP otra persona está conectándose a WhatsApp. Viendo el interés que el mundo tiene en la seguridad de WhatsApp y su privacidad tanto en cómo espiar WhatsApp, esta es una característica peligrosa que atenta contra la privacidad de las personas, así que lo mejor es que la deshabilites.

El estudio de este fallo lo publicaron Luis Delgado y Ferran Pichel en Security By Default, no solo para aprovechar esta característica con el fin de localizar la dirección IP de una persona, sino como fallo de seguridad que provocaba una Denegación de Servicio en la app, además de poder generar un consumo no controlado de recursos.

El problema de se seguridad radica en que por defecto en las nuevas versiones de WhtasApp para Android - en iPhone aún no se ha introducido esa característica -, la aplicación muestra una imagen de previsualización de cualquier URL que ha sido enviada como mensaje de chat en WhatsApp.

Figura 1: Mensaje de WhatsApp con URL que muestra previsualización de imágenes

La funcionalidad de mostrar una previsualización en miniatura de una imagen de la dirección web compartida es muy común en cualquier red social en la que se permite hacer una publicación de URLs, como por ejemplo Facebook o Google+, y por eso deben haberla introducida. El detalle sin embargo es sutil, y cambia por completo el escenario, ya que en Facebook o Google+ la imagen es descargada desde la red social cuando es visualizada por un cliente, pero al hacer que esto sea por defecto en un cliente móvil los riesgos de seguridad son equivalentes a cuando se permite descargar una imagen remota por defecto en un correo electrónico - algo que por ejemplo Mail para iOS hacía mal y corrigió por motivos de seguridad y privacidad -.

Figura 2: Página PHP en servidor web con img a servidor web que controla los accesos a la imagen

Enviando por mensaje una URL de un sitio web que tenga una imagen que sea incluida desde un servidor web controlado, fuerza al cliente de WhatsApp para Android a hacer una petición al servidor web para descargarse la imagen. En esa petición se puede ver la dirección IP desde la que el cliente de WhatsApp para Android, es decir, el móvil de la persona que está detrás de un número de teléfono, se está conectando.

La ubicación geográfica de las direcciones IP no funciona extremadamente bien y puede que salgan cosas dispares a veces, pero puede suponer un riesgo para la privacidad de una persona en muchos casos en los que sí que se puede geo-posicionar más o menos correctamente dicha dirección IP.

Figura 3: El servidor web registra la dirección IP desde donde se está conectando el cliente de WhatsApp

Además de eso, en la petición va también el USER-AGENT de la petición, donde se dan muchos detalles del software que está corriendo tras un determinado número de teléfono, que en un esquema de ataque dirigido puede ser importante, sobre todo hoy en día que se conocen bugs para los terminales Android no actualizados. No hay que olvidar que los usuarios de terminales con Android, debido a la dispersión de hardware, son los que menos actualizados tienen el sistema operativo, así que son los más expuestos a exploits conocidos.

Figura 4: Distribución de versiones de Android ofrecidas por Google

Como curiosidad extra, si además se quiere, esta utilidad podría utilizarse para realizar ataques desde Internet a los servidores de una red interna, enviando una URL con una imagen que apunte a http://ServidorInterno/app.asp?1; shutdown --de forma similar a como contaba yo que por culpa de las opciones de carga de imagen en Mail para iOS el jefe se podría cargar la base de datos.

Si tienes WhatsApp para Android lo mejor es que desactives esta opción, que aporta más bien poco para tu seguridad y privacidad. Además, como precaución general procura no seguir enlaces que recibas por mensajes de WhatsApp, ya que aunque no se haga la carga automática de las imágenes, si haces clic en un enlace que recibes por WhatsApp y te lleva a un servidor web controlado, vas a hacer pública tu dirección IP, y sucederá lo mismo.

Figura 5: Ajustes de carga de imágenes en URLs en WhatsApp para Android

Como última recomendación, si quieres evitar problemas de privacidad extras, recuerda que en WhatsApp puedes quitar cosas como informar si estás online, la última vez que te conectaste, etcétera. Es decir, puedes poner un poco más de privacidad a su uso.

La RAE vilipendia a los hackers. Petición en Change.org para que la RAE cambie la definición de hacker.

Cuando oí que la Real Academia de la Lengua Española iba a incorporar el término de hacker en el diccionario me temí lo peor. Había ido en el pasado a consultar la definición del mismo en el Diccionario Panhispánico de Dudas y allí ya lo definía como "pirata informático". Las probabilidades de que lo cambiaran a la hora de incorporarlo al diccionario oficial de la RAE eran pocas, como al final sucedió. Y me apené.

Figura 1: La RAE vilipendia a los hackers

La criminalización del término hacker significa una condena social a un grupo de personas que gracias a su esfuerzo e investigación han conseguido llevar las tecnologías a niveles mucho más allá de los que sus propios creadores pensaron. Gracias a hackers se han conocido fallos en seguridad de sistemas que han sido corregidos sin que el investigador haya recibido más que un simple gracias, a veces incluso menos. Gracias a los hackers se ha podido transformar la manera en la que nos comunicamos y vivimos hoy en día por Internet.

Figura 2: Definición de hacker usada en la RAE

El definir a un hacker como un pirata informático, iguala el trabajo de un investigador que es capaz de encontrar un bug en el protocolo tan importante para nuestra sociedad como SSL con el de un cibercriminal que usa herramientas de terceros para engañar a sus víctimas y robarles. Iguala a un estafador por Internet que roba las cuentas con correos de phishing para lucrarse con el de una persona que es capaz de demostrar que los sistemas de seguridad de las aplicaciones que usamos todos los días no protegen correctamente la privacidad de usuarios.

Figura 3: Definición de pirata informático

Podrían haber elegido una definición más elaborada, con más explicaciones, con más matices si quieren sobre lo que significa ser un hacker, pero al final han igualado al que copia un software con copyright para venderlo en el mercado negro con aquel que dedica horas y horas a mejorar la seguridad de un software o una plataforma.

Hackers, Cibercriminarles o Hacktivistas catalogados de la misma forma, y por tanto igualados en la misma condición, como Piratas Informáticos, cuando ni tan siquiera comparten ideas. Tanta indignación a causado esto que se ha abierto una petición en Change.org para recoger firmas y que la RAE cambie la definición del término hacker en el diccionario.

Figura 4: Petición en Change.org

En el texto de la petición pone:

"Desde hace tiempo los hackers han sido investigadores que han ayudado al progreso de la sociedad tecnológica de nuestro tiempo. El utilizar la definición como "pirata informático" para la palabra hacker es una criminalización del término y una degradación a ciberdelincuente de un grupo de personas que gracias a su pasión por buscar los límites de las tecnologías han mejorado nuestro tiempo."

Un hacker no tiene que estar solamente acotado en el mundo de la tecnología, pero aceptando esa limitación en el concepto, yo me aventuraría con toda humildad a pedir que utilizaran alguna definición más elaborada. Alguna propuestas que le dejaría a la RAE:

- Hacker: Investigador/a que con pasión y habilidad es capaz de hacer cosas con las tecnologías más allá de las que los propios creadores pensaron. Que busca los límites a la tecnología con el fin de mejorarla.

No soy un experto en definiciones, pero tengo claro que los hackers que yo he conocido no encajan para nada en el perfil de pirata informático, y que los que encajan con esa definición están tan lejos de los hackers que es una ofensa haberlos catalogado de esa forma. Han mancillado el término hacker y me apena que haya sido de forma oficial.

Señor Arturo Pérez-Reverte, como declarado lector adicto de su obra que soy, y como gran tuitero que es usted, desde su sillón "T" de la Real Academia de la Lengua, le pido que nos ayude a cambiar esto. La seguridad de su cuenta Twitter ha estado siempre en manos de hackers, como Moxie Marlinkspike o Charlie Miller, reconocidos hackers y miembros del equipo de seguridad de Twitter.

Figura 5: Arturo Pérez-Reverte es titular del sillón "T" en la Real Academia de Lengua y reconocido "tuitero"

Por favor, señores de la Real Academia de la Lengua, no vilipendien ni degraden a piratas informáticos a un grupo de personas maravillosas que están mejorando la sociedad y las tecnologías que ustedes mismos utilizan.

Fuente

Android Lollipop incluye un «interruptor» que «mata» los móviles robados

El software cumpliría así con lo solicitado por la nueva normativa de California, Estados Unidos

 

Android- Bus Stop

Una nueva ley de California requiere que todos los teléfonos inteligentes tenga un botón, una especia de «interruptor» que permita desactivar el teléfono en caso de robo. Al parecer, Google ha introducido esta faceta en Android Lollipop.

Recode señala que Android Lollipop (significa piruleta en español) incluye una característica denominada «Factory Reset Protection» que puede pedir un código de seguridad para poder reestablecer valores.

Según explican desde Recode, esta función se combina con la posibilidad de bloquear el móvil a distancia, Android Device Manager, que fue presentada el año pasado por Google. Cuando se combinan ambas funciones se crea ese «interruptor» que vuelve obsoleto al móvil, ya que sería imposible de usar en caso de robo.

Las fuerzas de seguridad habían pedido este tipo de servicios para que la ola de robos de smartphones descendiera. Apple introdujo alguna de estas funciones hace algún tiempo, y desde entonces, el robo de iPhone se desplomó, según fuente policiales consultadas por The Verge. Con este tipo de funciones, le es mucho más difícil a un ladrón volver operativo un terminal, por lo que no se sale rentable.

Un interruptor de este tipo en Android mejoraría mucho la seguridad de los datos contenidos en los dispositivos. Lollipop también encriptará los datos del usuario por defecto.

Fuente

X-XSS-Protection HTTP Header y los filtros Anti-XSS

Cuando salió el filtro Anti-XSS en Internet Explorer 8 - el primer navegador de Internet que lo aplicó - se generó mucha polémica. El que un filtro del lado del cliente pudiera modificar el contenido que venía mostrado desde el servidor - pese incluso a que pudiera ser mediante un ataque de XSS Reflejado - levantó muchas opiniones a favor y en contra. De hecho, rápidamente los investigadores buscaron formas de saltarse el filtro e, incluso, de utilizar la manipulación del filtro para convertir páginas no vulnerables en páginas vulnerables.

Figura 1: Bugs de XSS Reflejados reportados a Apple

Hoy en día Google Chrome, Apple Safari e Internet Explorer lo implementan por defecto, pero queda en manos del usuario el poder deshabilitarlo en caso de así desearlo, sobre todo por si le da problemas al trabajar con alguna web que, más que probablemente, está mal diseñada. En un ataque de XSS, saltárselo siempre es un paso que hay que hacer, por lo que los bugs de estos filtros de seguridad se hacen también muy populares, como los casos que os he publicado por aquí en algunos artículos:

- El 0day para saltarse el Anti-XSS de Google Chrome que duró 24 horas.
- Unos trucos para pasar el filtro AntiXSS en Chrome y Safari
- Saltándose el filtro Anti XSS de Google Chrome 11

Por otro lado, al mismo tiempo que se da al usuario la posibilidad de controlar el filtro Anti-XSS, los servidores web también tienen un HTTP header que pueden enviar al navegador para habilitar o deshabilitar dicho filtro, en caso de que el usuario haya deshabilitado el filtro y el servidor web no quiera que así sea, o viceversa, es decir, en caso de que el filtro esté habilitado en el cliente y el servidor web desee que se deshabilite. Ese HTTP header es el X-XSS-Protection.

Figura 2: Filtro Anti XSS en Internet Explorer 8 modificando la web

Los HTTP headers que empiezan por X- son variables extendidas que no se encuentran dentro del estándar, pero que se pueden popularizar más o menos dependiendo de quién las utilice. De estos hay muchos, como el famoso X-Frame-Options para evitar ataques de Clickjacking, o como alguna que otra política de contenido que ya os contaré más adelante en algún post. En este caso, el HTTP header X-XSS-Protection se entendido tanto por Google Chrome, Apple Safaricomo por Internet Explorer desde la versión 8 hasta la actual y permite configurar el filtro Anti-XSS del navegador por medio de esta política.

Figura 3: Google Chrome permite deshabilitar el filtro Anti-XSS,
llamado XSS Auditor, por parámetros en el arranque de la aplicación

Cuando el valor del HTTP Header X-XSS-Protection de una web tiene un valor 1; mode=block, está forzando a que el filtro Anti-XSS esté habilitado en el navegador - incluso si el cliente lo ha deshabilitado -, mientras que si se configura con valor 0 se está deshailitando incluso si el cliente lo tuviera habilitado. Si no se pone el HTTP Header X-XSS-Protection con ningún valor, entonces es elección del cliente habilitar o deshabilitar el filtrado Anti-XSS, aunque por defecto casi todo el mundo lo tiene activo en Google Chrome, Apple Safari e Internet Explorer.

Figura 4: X-XSS-Protection:1 en un servidor de Google

Dicho esto, la recomendación de seguridad es forzar la activación del mismo, consiguiendo una mejor fortificación del entorno, ya que un ataque de XSS puede afectar a la seguridad de los clientes y por tanto a la seguridad del servidor web completo. Sin embargo, puede pasar que, como se ve en este caso de Facebook, temporalmente hayan forzado deshabilitarlo.

Figura 5: X-XSS-Protection 0 en un frontal de Facebook

Hacer esto tiene unos riesgos que se asumen por problemas de compatiblidad, pero que son un mal menor en un proceso de continuidad de negocio. Este HTTP Headerde X-XSS-Protection = 0 en Facebook está dejando sin protección Anti-XSS a los clientes de Google Chrome, Apple Safari e Internet Explorer que se conecten a estos frontales, por lo que se deben extremar la protección contra este tipo de ataques dificultándolos con algunas otras medidas, como las Content Security Policies, algo que Facebook sí que utiliza.

Fuente

POODLE o cómo un caniche mató a SSL

Poodle o Poodlebleed es una vulnerabilidad en el diseño de la versión 3.0 de SSL. Poodle es en realidad un acrónimo de Padding Oracle On Downgraded Legacy Encryption. La vulnerabilidad permite el descifrado de texto plano de conexiones seguras. El error fue descubierto por el equipo de seguridad de Google, concretamente por el investigador Bodo Möller en colaboración con Thai Duong y Krzysztof Kotowicz. Ver paper.

Y si no soportas TLS pues aguanta SSL...

Aunque SSL 3.0 tiene casi 15 años, muchos servidores y navegadores web siguen utilizando hoy en día. Cuando los navegadores web fallan al intentar usar una versión de SSL más reciente (es decir, TLS 1.0, 1.1 o 1.2), pueden recurrir a una conexión SSL 3.0. Aquí es donde comienza el problema.
Debido a que un atacante puede provocar fallos en la conexión, incluyendo el rechazo de conexiones TLS 1.0/1.1/1.2 , puede forzar el uso de SSL 3.0 y luego explotar el bug Poodle con el fin de descifrar el contenido transmitido de forma segura entre un servidor y un navegador.

Este ataque es similar al ataque BEAST y también permite extraer el texto plano por partes desde una conexión SSL, por lo general los datos de cookies. Pero a diferencia del ataque BEAST no requiere un control tan extensivo del formato del texto en claro y por lo tanto es más práctico.
Cómo muerde el CANICHE

Veamos cómo un atacante podría obtener un texto cifrado (normalmente una cookie de sesión) y ser capaz de descifrarlo mediante este ataque.

Por si alguien todavía no lo sabe, SSL utiliza o un cifrado stream RC4 o un cifrado de bloques en modo CBC. En este último caso a modo muy genérico podríamos decir que el texto en claro se divide en bloques de tamaño fijo (n bytes) que se cifran con la misma clave (simétrica) dando como resultado bloques cifrados con el mismo tamaño. Como hemos dicho, el tamaño de los bloques a cifrar a de ser fijo, por lo que a la hora de dividir el mensaje en claro casi siempre es necesario rellenar un bloque para que tenga la misma longitud: es lo que se conoce como esquema de relleno o padding.

Luego en modo Cipher-block chaining (CBC), se aplica una operación XOR a cada bloque de texto plano con el bloque cifrado anterior antes de ser cifrado: Pi = dK(Ci) ⊕ Ci-1. Además, para hacer cada mensaje único se utiliza asimismo un vector de inicialización (IV).

Consideremos la siguiente petición HTTP que mediante el uso 3DES es dividida en varios bloques de 8 bytes (la misma idea funciona con bloques de 16 bytes si se utiliza AES):

Como vez el último bloque tiene 7 bytes de padding (representados por "•"). Antes de enviarse se cifra con 3DES o AES en modo CBC y el receptor tendrá que descifrar la cadena utilizando el siguiente esquema:

El gran problema es que con CBC en SSLv3 no se especifica el contenido de los bytes de padding ni se comprueba la integridad del padding (MAC). Es decir, "•" podría ser cualquier cosa porque el receptor no puede comprobarlo. En el ejemplo sólo basta comprobar que el último byte, el que no es de padding, sea un 7. Evidentemente el atacante sólo podrá ver el texto cifrado pero puede aprovecharse de este fallo.

Para ello duplica la petición cifrada pero sobrescribe el último bloque y la envía al receptor hasta que éste no la rechaze, de forma similar a la que se hacía cuando preguntábamos al "oráculo" con BEAST (padding oracle). La respuesta del servidor la obtendremos muy rápido si tenemos en cuenta que sólo le hará falta enviar como mucho 256 peticiones (8 bytes = 2⁸ = 256 posibilidades). Después de eso, el atacante concluirá que DK(Ci)[15] ⊕ Cn-1[15]=15 y habrá obtenido el último byte de la cookie: Pi[15]=15 ⊕ Cn1[15] ⊕ Ci1[15].

A continuación para obtener el resto de bytes de la cookie el atacante simplemente tiene que aumentar la longitud de la URL y disminuir cualquier parte posterior al valor de la cookie para que se particione de la siguiente manera:

Como vez el valor de cada cookie es desplazado y basta repetir el proceso anterior para cada uno de sus bytes.

¿En verdad es tan peligroso este CANICHE?

Mientras que las recientes vulnerabilidades Heartbleed y Shellshock afectan a servidores, Poodle permite comprometer sólo a los clientes.
Esto requiere normalmente un exploit MiTM y que javascript esté habilitado en un navegador o que no haya algún programa que limite la ejecución de código javascript. Esto disminuye la peligrosidad global de este ataque que sin embargo debe suponer la "muerte" definitiva de SSL a favor de TLS.

¿Es mi servidor vulnerable?

Compruébalo tú mismo:

- https://www.tinfoilsecurity.com/poodle
- http://poodlebleed.com/

¿Y cómo me protejo del CANICHE?

Pues a nivel de navegador lo mejor es desactivar y olvidarse para siempre de SSLv3 o de los cifrados en modo CBC que utiliza. En Firefox puedes hacerlo entrando a la configuración (about:config) y poniendo a 1 security.tls.version.min o si usas Chrome puedes arrancarlo con el parámetro --ssl-version-min=tls1. Pero como puede darte problemas al intentar conectar con servidores que sólo usan protocolos de cifrado antiguos es recomendable el soporte TLS_FALLBACK_SCSV que impide el "downgrade" desde TLS a SSL.

Por otro lado si tienes un servidor y no temes dejar fuera a los infames usuarios que utilizan navegadores obsoletos puedes también desactivar SSL 3.0. Aquí puedes ver cómo hacerlo en apache o nginx.

Referencias:
 
- This POODLE Bites: Exploiting The SSL3.0 Fallback
- The Poodlebleed Bug
- POODLE attacks on SSLv3 (14 Oct 2014)
- Some POODLE notes
- Google Discloses Vulnerability In SSL Web Encryption Technology
- SSL is dead, long live TLS
- This POODLE bites: exploiting the SSL 3.0 fallback
- OpenSSL: SSLv3 POODLE Vulnerability Official Release


Fuente