Que acabo de descubrir varios scripts automatizados están aprovechando autosave.js que es una función común a las ultimas versiones de WP expone el path en el servidor donde alojamos nuestro blog, esto por si solo no es tan delicado, pero dice bastante de nuestro blog, para empezar que tema usamos y que path, dependiendo del host hay más de una solución en el faq de seguridad [1] de WP vienen muy buenas sugerencias, pero antes que todo el que hacer en caso de estar «jaqueado» [2], pero en el hardening WP [3] vienen unas cuantas mejores, en otro host donde no tengo shell y tuve que descargar todo el sitio para revisarlo y probar con grep y herramientas útiles y no cpanel tarde casi 6 horas en entender cual era el problema, anoche o el día de hoy en el otro lado del mundo me llevo 15 minutos descubrir el problema provisto de bash, find, grep y xargs, entonces dependiendo de como tengan su blog un par de recomendaciones, ya que he visto aumentar estos ataques automatizados y espero agregar una propuesta de como pienso que deberían empaquetarse los themes.
1) Rapida en el directorio de archivos de su theme hay un index.php si este es llamado directamente por su path va a marcar error (en hosts de producción pudiera no exponer tantos datos, pero comunmente necesitamos de estos errores para encontrar problemas y luego no sabemos / queremos ocultarlos) entonces por el como esta implementado php y la mayoria de los webservers podemos crear un index.html vacio (touch index.html) si alguien llega a ese directorio no vera nada, ya que normalment el orden de presentación es index.html, index.php, etc.
2) Otra, si tienen claro los permisos en *nix hasta con su cliente ftp pueden asegurar sus directorios, en el ejemplo anterior donde no tenia acceso shell, la solución fue el theme ponerlo en solo lectura (444) claro que eso rompe el bonito editor de themes de WP, pero evita defaces a las 2am tiempo del pacifico que lo levantan a uno a las 7am de un domingo con el sitio del cliente suspendido.
3) Una casi obvia, si no vamos a usar más que un theme, no tengamos instalados muchos, son mayores vectores de ataque.
4) .htaccess aunque en cierta forma también vulnerable, puede ayudar a evitar varios problemas aquí no puedo dar una receta mágica puesto que cada host permite o niega cosas en sus configuraciones.
En todo caso, estoy pensando en ver la posibilidad de usar algo similiar a diffmon modificado o el plugin de exploit scanner [4], va una de pilón «como encontrar cual cualquier cosa en linux» [5] excelente, igual necesitaría colocarles una de grep pero un ejemplo común vale la pena grep base64 *.php -r (buscar base64 en todos los .php en todos los directorios, de manera recursiva) hay funciones que usan base64 pero una forma común de esconder un exploit o hack es escondiéndolo en un base64 y luego un montón de caracteres raros que hasta no ser interpretados no son más que un wall text (medida que usan muchos programas privativos para «proteger» su código, por cierto).
[1] http://codex.wordpress.org/Security_FAQ
[2] http://codex.wordpress.org/FAQ_My_site_was_hacked
[3] http://codex.wordpress.org/Hardening_WordPress
[4] http://ocaoimh.ie/exploit-scanner/
