Que acabo de descubrir varios scripts automatizados est\u00e1n aprovechando autosave.js que es una funci\u00f3n com\u00fan 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\u00e1s de una soluci\u00f3n en el faq de seguridad [1] de WP vienen muy buenas sugerencias, pero antes que todo el que hacer en caso de estar \u00abjaqueado\u00bb [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 \u00fatiles y no cpanel tarde casi 6 horas en entender cual era el problema, anoche o el d\u00eda 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\u00edan empaquetarse los themes.<\/p>\n
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\u00f3n 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\u00f3n es index.html, index.php, etc.<\/p>\n
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\u00f3n 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.<\/p>\n
3) Una casi obvia, si no vamos a usar m\u00e1s que un theme, no tengamos instalados muchos, son mayores vectores de ataque.<\/p>\n
4) .htaccess aunque en cierta forma tambi\u00e9n vulnerable, puede ayudar a evitar varios problemas aqu\u00ed no puedo dar una receta m\u00e1gica puesto que cada host permite o niega cosas en sus configuraciones.<\/p>\n
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\u00f3n \u00abcomo encontrar cual cualquier cosa en linux\u00bb [5] excelente, igual necesitar\u00eda colocarles una de grep pero un ejemplo com\u00fan 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\u00fan de esconder un exploit o hack es escondi\u00e9ndolo en un base64 y luego un mont\u00f3n de caracteres raros que hasta no ser interpretados no son m\u00e1s que un wall text (medida que usan muchos programas privativos para \u00abproteger\u00bb su c\u00f3digo, por cierto).<\/p>\n
[1] http:\/\/codex.wordpress.org\/Security_FAQ
\n[2] http:\/\/codex.wordpress.org\/FAQ_My_site_was_hacked
\n[3] http:\/\/codex.wordpress.org\/Hardening_WordPress
\n[4] http:\/\/ocaoimh.ie\/exploit-scanner\/<\/p>\n","protected":false},"excerpt":{"rendered":"
Que acabo de descubrir varios scripts automatizados est\u00e1n aprovechando autosave.js que es una funci\u00f3n com\u00fan 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 … Sigue leyendo