El día de hoy voy a tratar de dar un punto de vista a una de las noticias más comentadas de la semana pasada como fué los más de
300.000 sitios vulnerables por un fallo de seguridad en un Plugins de
WordPress.
 |
| Figura 1: Que pasa cuando las funcionalidades som más complejas que los modelos de Seguridad |
La situación para llegar a este punto es más compleja y hasta quizás más profunda de analizar, pero voy a tratar de hacer un resúmen no solo de lo que pasó, sino también como podemos estar un poco más alerta.
A fines del mes de Junio, el equipo de investigadores de
Sucuri, descubre y publica un fallo de seguridad, en la que afectar a un Plugin de WordPress llamado
WP Statistics en su versión 12.0.8
Al parecer, según la publicación escrita por Sucuri, es posible llevar adelante un ataque por medio de una vulnerabilidad
SQL Injection en uno de los parámetros no controlado por el desarrollador del Plugin.
Como siempre, hay que reconocer el excelente trabajo de Sucuri, al informar y alertar sobre los posibles problemas a quienes están a cargo del desarrollo de éste Plugin, ya que corresponde sin duda una gran responsabilidad.
Para hacer un poco de memoria, afortunadamente, hoy contamos con bases de datos de vulnerabilidades como
WPScan Vulnerability Database donde podemos encontrar estos datos:
 |
| Figura 2: WPScan Vulnerability Database |
Estos datos tienen que ser una fuente importante al momento de decidir si un Plugin va a pertenecer o no a un Proyecto de WordPress.
Otra fuente importante es el archivo
ChangeLog que incorpora el Plugin de forma obligatoria, donde allí es posible seguir la evolución el proyecto y algunos detalles más.
Con esto no vamos a decir que WP Statistics no es un buen Plugin, sino que el analista o la persona que está a cargo de llevar adelante la implementación de WordPress tiene que conocer estos datos y el antecedente de cada componente dentro del proyecto.
Ésto es algo implícito que se sabe al momento de instalar WordPress o cualquier CMS como Joomla!, Drupal, PrestaShop, etc, donde por ninguna razón se garantiza la seguridad del proyecto.
Otro punto que se descuida son las actualizaciones, o lo que se vió en muchos casos luego de esta noticia, es que en muchos proyecto se desactivó el plugin para dejar de trackear la información pero dejaron el directorio del Plugin sobre el servidor, que a nivel técnico es posible seguir comprometiendo.
¿Esto se podría haber evitado?
Puede que si o puede que no, la realidad es que hoy fue un Plugin muy popular donde era de esperar que el impacto sea muy grande, mañana el problema puede estar en otro Plugin, en una librería o incluso sobre el mismo core de WordPress.
Lo más importante que tenemos que entender es que las funcionalidades no tiene que ser más complejas o sobrepasar las medidas de seguridad, de lo contrario no estaremos haciendo un buen trabajo al mantener la seguridad de WordPress.
En el ecosistema de WordPress es muy importante estar dispuesto a mantener una actualización en cada uno de los componentes importantes. WordPress es un gran proyecto que mantiene a sus usuarios acostumbrados a publicar varias actualizaciones por cada versión.
Si a priori sabemos que los componentes a lo largo del tiempo se van a actualizar, lo mejor que podemos hacer es redactar y poner en práctica como es la forma que vamos a actuar al momento que esto ocurra, cuáles van a ser los procedimientos que se van a ejecutar cuando ocurra X o Y evento.
De esta manera, cuando ocurra este tipo de publicaciones, rápidamente vamos a saber como actuar, e independientemente del valor de proyectos comprometidos, vamos a saber como actuar en el momento indicado.
Para conocer como adoptar nuevos hábitos de seguridad y poder llevar a otro nivel la fortificación de sus proyectos en WordPress, junto a los chicos de la editorial
0xWORD publicamos "
Máxima Seguridad en WordPress".
 |
| Figura 3: Máxima Seguridad en WordPress |
Saludos!
