Cryptojacking. Escuchando a la otra parte afectada del negocio.
Tengo que admitir que dejé de ir a charlas de seguridad hace bastante tiempo. En su lugar, para compensar, voy a las de desarrolladores. No nos engañemos, me encanta mi trabajo, que no es otro que desmontar pieza a pieza lo que otros han construido. Pero también me gusta construir y, por supuesto, si lo que levantas del suelo no es a demanda sino algo que te propones como un reto, mayor es el aliciente. Además, mucho mejor estar cerca de mis “enemigos” que de mis "amigos" ¿no?
Al salir de una de estas charlas me encontré con un viejo amigo que tiene una empresa de desarrollo y hosting. Nos fuimos a saquear el aperitivo y se nos unieron varios compañeros más. Muy pronto, la conversación derivó en uno de los temas de moda y del que ya hemos hablado alguna que otra vez por aquí: el cryptojacking. Aunque intenté darme a la fuga antes de que el tema cogiese más protagonismo, mi amigo me paró en seco. “Ah!, pues aquí el amigo, que se dedica a seguridad, nos puede dar su visión del tema.”
El tópico interesaba, y mucho, y de nada sirvieron las cinco excusas nivel oro de mi libro de excusas para huir de ciertas situaciones sociales (lógico, quienes me conocen saben cómo contratacarlas). Así que teníamos por delante veinte minutos de conversación acerca de la dichosa minería. No obstante, al final mereció la pena. Pude constatar la preocupación con la que asumían la problemática. Me pareció interesante dar eco aquí de ciertos aspectos.
El cambio de economía
Me comentaban qué, de los servidores atacados en sus sistemas, normalmente accedían (un clásico) a través de una vulnerabilidad web. Cuando antes era subir una Shell, ahora es, con alarmante diferencia, subir un minero. No al propio servidor, que eso pega un cantazo tremendo en los consumos, muy monitorizados, de CPU de las máquinas, sino, evidentemente, como recurso para que se los descarguen los navegadores.
Antes, si subían un phishing o un troyano, el visitante no se percataba del sitio donde le habían encasquetado el paquete. Eso era porque la visita era indirecta en la mayoría de ocasionas y otras veces, por supuesto, la infección es silenciosa y el visitante no se percataba donde “le habían untado la tostada”.
Sin embargo, con el minado si se nota. Llega al lugar y el ventilador se pone a fibrilar. La CPU a tope, tanto que podría calentar una habitación en un par de horas. Entonces sí que te das cuenta donde te la están dando. El visitante lo tiene claro, ctrl-w, pestaña cerrada y sitio del que desconfía. La pérdida de visitas, marca, prestigio, etc, que tanto cuesta construir corre el riesgo de irse al traste. También la inclusión de lista negra, etc.
Era curioso, como incluso en ese falso dilema de escoger entre las “antiguas” amenazas o esta nueva moda del minado, preferían el suplicio de tener un merodeador con una Shell o que les alojasen un troyano. Ambos, casos que suelen tener, junto con el mass mailing, bastante trillados y cuya ventana de existencia está bastante acotada. Sobre todo, porque han ido perfeccionando sus soluciones in-house o las de terceros.
Vectores de entrada
Todo vale en la guerra. Los métodos de entrada no suelen variar, pero esta vez el logro no es hacerse con el sistema sino “colar” el minero a toda costa. Escuché atentamente, aunque nada sonaba a novedoso, ellos no hablaban de extensiones para el navegador maliciosas, minería explícita (caso PirateBay), etc. Su punto de vista, lógico, es defender el negocio y su preocupación quienes les visitan, la experiencia del usuario.
Los casos eran curiosos. Foros vulnerables con comentarios que incluían scripts, cross-site scripting persistentes, funcionalidad de user-content muy permisivas e incluso un notorio caso donde los señores crackers habían añadido un CDN de su propia red de contenido donde, por supuesto el usuario no descargaba precisamente versiones minimizadas del framework de moda.
Algo curioso que les comenté era el hecho de las campañas de anuncios con mineros. Nada nuevo bajo el sol, pero desconocían ese vector. Curioso que les sorprendieran, aunque si recordaban el viejo truco de endiñar un exploit a través de un, en sus tiempos, anuncio en flash (que en paz descanse de una vez).
Posibles defensas
Apurando ya los últimos sorbos de la copa (en realidad eran vasos con refrescos, pero copas queda mejor literariamente), tocaba hablar de cómo te defiendes de algo así. Había unanimidad en que andaban un poco a tientas con las soluciones. Prácticamente se usaban los mismos enseres y técnicas que el rastreo de shells o cambios en los sitios que con el malware o phishing. Eso sí se ponían remedio, pues también confesaron que…oh, sorpresa, no actuaban hasta que alguien les avisaba.
Hubo quien proponía inyectar scripts para detectar y detener mineros. Mi sonrisa me delató. Eso es una carrera de ratas recursiva, al final siempre hay un anti-anti-anti-anti…hasta la saciedad. Tú me inyectas un script para detenerme, yo meto una rutina de antidetección, tu detectas mi rutina que detecta tu rutina y…quien haya visto a los hermanos Marx sabe de qué estamos hablando.
También se habló de cazar esos scripts por la huella que dejan. Es decir, rastreo los scripts los ejecuto en una sandbox y en base a un perfil de consumo alerto de posible minero. Si y no. Eso puede durar lo suficiente como para que o bien procedan a detectar ese ambiente e inhibirse (como hacen el malware cuando detecta una máquina virtual) o simplemente el script se trocea en partes y no se activa su función principal hasta que estás se recomponen en una sola. Incluso dudaba del perfil de consumo como capacidad para hacer vetting de los scripts, sobre todo porque hay scripts que sí que legítimamente requieren consumo: WebGL, generación de gráficas, video incrustado, etc. Si bien hay capacidad y recorrido para la heurística, no creo (el pesimismo del auditor) que sea la panacea.
¿Pero y que solución le damos?
Nos anuncian que va a dar comienzo otra charla. Apuramos “la copa” y cogemos unos cuantos canapés sin que se notase mucho, por si aprieta el gusanillo más tarde. Estaba ya a punto de librarme de la pregunta que se estaba gestando minutos antes. A los 123 grados de giro de un espectacular quiebro de cintura que ya quisieran el propio Messi o Cristiano y dos pasos de distancia, escuché la temida interpelación: “¿Oye, pero dinos, esto como ves que pueda solucionarse o al menos paliarse, tu que trabajas con…?”
Francamente. Habíamos estado hablando de soluciones post infección y nadie de nosotros se había percatado de lo obvio. “Bueno, si tienes agujeros y muchos, lo más probable es que antes o después alguien pase por ahí y se aproveche de ellos. ¿Habéis probado a auditar vuestra infraestructura de forma periódica o al menos implementar un desarrollo seguro en lo que hacéis?”
Por supuesto, era una obviedad, no se hacía, pero estaba claro que esto es como la salud. Es preferible cuidarla antes que tener que poner soluciones cuando ya es demasiado tarde, cuando todo es paliativo, crónico e irreversible. Ellos se llevaron un par de viejos conceptos de seguridad, pero nuevos para ellos. Y yo me llevé la impresión de que los que nos dedicamos a la seguridad deberíamos escucharlos más donde realmente están los que tienen los problemas que pretendemos solucionar.
Via: unaaldia.hispasec.com
Cryptojacking. Escuchando a la otra parte afectada del negocio.
Reviewed by Zion3R
on
10:37
Rating: