Ikasten.IO

Transmission, torrents, OSX y malware KeRanger

Cuando necesito descargar torrents, uso Transmission en Linux y uTorrent en OSX. No es que uTorrent esté libre de pecado (Spigot -PUP-, EpicScale -mining de bitcoin no deseado, y demás basura), pero la semana pasada (4 de marzo) Transmission para OSX llevaba de regalo KeRanger, ransomware. Sí, malware que cifra el contenido de tu disco duro y te pide un rescate – pagado en bitcoin, por supuesto- para obtener la clave que lo descifra. Parece ser el primer caso de ransomware dirigido específicamente a usuarios de OSX. Fue la gente de Palo Alto Networks fueron los primeros en dar el aviso, indicando que la web de Transmission había sido comprometida, dejando un fichero de instalación .dmg(la versión 2.90 de Transmission) infectado con KeRanger. Lo «bonito» del asunto es que esta versión de KeRanger había sido firmada con un certificado válido de desarrollador de aplicaciones para OSX, saltándose el control básico de Apple Gatekeeper que impide a un usuario básico instalar una aplicación que no venga firmada (se salta abriendo el binario con el menú contextual mientras pulsas Control, pero es una primera barrera de seguridad). Si el usuario instaló la versión infectada de Transmission, esta ejecutará una versión incrustada de KeRanger, esperará 3 días (suele ser habitual esperar a ejecutar el castigo, para ocultar al usuario el origen de la infección) y se comunicará con un servidor C&C (Command & Control) sobre la red Tor. A partir de ahí, cifrado del disco y petición de rescate (400 dólares).

Apple ha actuado rápido. Lo primero, invalidar el certificado con el que se firmó la aplicación en cuestión. Lo segundo, añadir una regla a XProtect, el sistema de lista negra que usa OSX por defecto. Puedes consultar los bichos que pululan por Internet en este fichero de tu OSX: /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist. ¿El primero de la lista? Nuestro amigo KeRanger:

El análisis técnico del bicho en la página de Palo Alto Networks merece mucho la pena. Verás que el desarrollador está preparando funciones específicas para buscar y cifrar backups de Time Machine (qué angelito…). Verás también que usa tanto cifrado asimétrico (RSA) para cifrar un número elegido al azar junto a un IV dependiente del contenido del fichero, con lo que formará la clave que usará para cifrar el contenido del fichero usando cifrado simétrico (AES).

El 5 de marzo la gente de Transmission eliminó el ejecutable infectado de su web. Apple también ha hecho su trabajo. Pero el secuestro de webs para implantar malware parece que está de moda. Hace un par de semanas fue el turno de Linux Mint. Esta semana ha caído Transmission. ¿Quién será el siguiente?

Formateo y validación de objetos JSON

En esta ocasión, aprovechando que esta semana se estudia el formato JSON en una de mis clases, os quería recomendar un par de utilidades que utilizo a menudo: la herramienta jq y el plugin JSONView.

jq es una utilidad de la línea de comandos disponible para Linux, OS X y Windows que permite validar y visualizar de forma muy agradable objetos JSON. La mejor forma de apreciar el uso de jq es por medio de un ejemplo. En la siguiente figura, muestro un objeto JSON en la terminal sin usar jq. A continuación lo vuelvo a mostrar, esta vez filtrándolo con jq. Mucho mejor, ¿no?

jq también detecta objetos JSON inválidos, marcando dónde se encuentra el error:

JSONView es similar a jq, pero funciona como plugin o extensión, tanto de Google Chrome como de Mozilla Firefox. Veamos un ejemplo con el resultado de una llamada al API de OpenWeatherMap.

Sin usar JSONView:

Con la extensión JSONView instalada:

Sí, representan exactamente el mismo resultado. Pero uno es legible por humanos y el otro no 🙂

¿Conocíais estas utilidades? ¿Qué extensiones usáis en vuestros desarrollos? (HTML5, JS, PHP, whatever…)

Demasiadas conexiones a MySQL desde R

Estoy desarrollando una nueva aplicación en R+Shiny. Entre otras cosas, el servidor Shiny necesita acceder a los datos de una BBDD en MySQL. Tengo código en R que accede a MySQL sin problemas, abre y cierra las conexiones bien, sin leaks por dejar conexiones abiertas. Bueno, eso es lo que creía… cuando por alguna razón la aplicación fallaba, podían darse casos en los que alguna conexión se quedaba abierta. Por una o dos, no pasaba «nada». Pero probando y probando, llegué a este error:

«cannot allocate a new connection — maximum of 16 connections already opened»

Vaya… el primer problema es: ¿cómo desconecto las conexiones abiertas? La respuesta a esto en la lista de distribución de R:

 cons <- dbListConnections(MySQL()) 
 for(con in cons) 
  dbDisconnect(con)

Y ahora, ¿cómo evitar el error? Lo ideal sería establecer una especie de conexión singleton que se reutilizara desde todo el código. La respuesta a esto, en StackOverflow (cómo no ;-))

library(RMySQL)
getConnection <- function(group) {
  if (!exists('.connection', where=.GlobalEnv)) {
    .connection <<- dbConnect(MySQL(), group=group)
  } else if (class(try(dbGetQuery(.connection, "SELECT 1"))) == "try-error") {
    dbDisconnect(.connection)
    .connection <<- dbConnect(MySQL(), group=group)
  }
  return(.connection)
}

Este código comprueba si existe una conexión en el entorno global. Si no existe, la crea y la devuelve. Si existe, comprueba que se pueda usar. Si no se puede usar, desconecta y vuelve a crear la conexión, para devolverla. Es decir, funciona como una caché (o puede verse también como un objeto singleton de tipo connection). Podríamos ignorar el parámetro group de la función getConnection y en su lugar, usar:

 dbConnect(MySQL(), user=login, password=pass, db=database, host=host)

allí donde fuera necesario.

De DiarioLinux.com a Ikasten.io

Llevo mucho tiempo intentando escribir este post. Incluso creo que lo llegué a hacer, pero perdí el fichero donde lo guardaba. No recuerdo si lo hice en un documento de Google Drive, en Keep, en un fichero de texto plano, en un borrador de post, en un mensaje de correo a mí mismo… o si lo soñé, que también puede ser. El mero hecho de perderlo o de no saber a ciencia cierta si lo llegué a crear, me da que pensar. Vivimos una época en la que las conversaciones se llevan a cabo en redes sociales (Facebook, Twitter) y programas de mensajería instantánea (WhatsApp, Telegram). Todo es rápido, al momento, todo se consume de manera inmediata. No queda tiempo para sentarse a reflexionar y menos para escribir posts largos.

Antes no era así. Recuerdo una época en la que escribía largos mensajes varias veces a la semana. Eran posts con enjundia, donde compartía conocimiento práctico que había probado con calma. Eran posts sobre temas relacionados con Linux y el software libre. Era lo que me movía. Era un bonito «trabajo», que me llevó de 2001 a 2014. En los últimos dos años (2014-2015) dejé de escribir en el blog. Sucumbí a las redes sociales. En especial, a Twitter. Sucumbí al software privativo, en especial al sistema OSX.

Abandoné DiarioLinux, pero no abandoné Linux. Sigo usándolo, pero no en el escritorio. Me cansé de pelear con drivers, configuraciones, aplicaciones y entornos. Quería seguir trabajando con un sistema Unix. Pero también quería las últimas aplicaciones. Y sucumbí a la manzana. Es curioso, esa historia de la manzana ya ocurrió hace miles de años 😉

La cuestión es que tengo ganas de tomarme las cosas con más calma. Y de escribir de forma más pausada y pensada de lo que escribo en Twitter. ¿Quiere esto decir que dejaré de tuitear? No, seguiré haciéndolo, aunque probablemente bajando la frecuencia. Sigo creyendo que Twitter aporta mucha información de calidad (aparte de montañas de ruido). Gran parte de esta información la tengo marcada con un «favorito» (ahora, con un corazón, cursi, rojo). Hasta ahora, marcaba así los tuits en los que me interesaba profundizar. «Cuando tenga tiempo». «Este enlace quiero leerlo con calma». Autoengaños. Ahí siguen, marcados pero sin leer. Como los cientos de libros técnicos en formato digital que acumulo (casi 300, y subiendo) para leer algún día (será imposible hacerlo).

Así que toca simplificar. No preocuparse tanto por acumular, sino por soltar lastre. No preocuparse tanto por las novedades, sino por profundizar en alguna de ellas o en alguna de las que, en su día, fue novedad marcada como «favorita» e interesante, pero de la que nunca más supe. Eso es lo que pretendo hacer, pararme a inspeccionar con más detalle aquellos temas que piquen mi curiosidad. Temas técnicos en su mayor parte, pero también sobre docencia, idiomas, running, series, cine o libros. Como veis, temas que no estarán ceñidos sólo a Linux o al Software Libre. Temas, en general, sobre los que querría aprender más. De ahí el cierre de DiarioLinux y el comienzo de este nuevo blog, Ikasten.io /Aprendiendo/.

Espero que estas reflexiones no se queden sólo en eso o que, al menos, pasen a formar parte de una buena colección de posts al respecto 🙂

PD: DiarioLinux.com cerrará, pero no se perderá el contenido. Todos los posts, comentarios e imágenes adjuntas han sido copiadas a ikasten.io dentro del subdominio diariolinux.ikasten.io. Por el momento, diariolinux.com estará unos meses redirigiendo el tráfico (con cabeceras 301 Redirect). En 2017 cerrará definitivamente.

¿Usas código de StackOverflow? Debes citar la fuente

Leí la noticia en Slashdot hace unos días. La gente de StackExchange (SE, madre nodriza de otras tantas, donde destaca StackOverflow.com) quería discutir con la comunidad un cambio en la licencia de uso de los trozos de código de esta web. La cuestión es que la nueva licencia, que entraría en vigor el 1 de marzo de 2016, proponía que:

Las aportaciones que no fueran de código y estuvieran disponibles en alguna de las webs de la red StackExchange seguirían gobernadas por los términos de la licencia CC-BY-SA
Las aportaciones de código estarían gobernadas por los términos de la licencia MIT (sin necesidad de tener que incluir todos los términos de la licencia en tu proyecto, basta con atribuir el origen.

Realmente esto sólo cambia con respecto a la licencia anterior de la red SE en que antes la atribución era bajo petición del usuario creador de dicho código (poseedor del copyright de dicho código) o de SE en representación o en nombre de dicho usuario.

Se lió una buena discusión con estos términos. Hay cientos de comentarios al respecto, muchos de ellos en contra de esta decisión.

Llevo tiempo usando StackOverflow, tanto de forma profesional como programador, analista de datos, para mis clases de docencia e incluso como elemento de investigación. En mi faceta de programador, siempre que recojo algún trozo de código de SO intento incluir una referencia al post original a través de un comentario en el código. No sólo por cortesía, que también, sino sobre todo porque me interesa documentar las fuentes en las que me baso a la hora de programar. Si he tenido que acudir a SO a buscar esta solución, seguro que en el futuro alguien que lea mi código (yo mismo, probablemente) tendrá la misma duda y querrá saber más al respecto, o simplemente, ese trozo de código le puede parecer interesante y puede querer seguir profundizando en el tema. El enlace al post original en SO seguro que le/nos ayuda.

Con respecto a la docencia, atribuir el origen del código es lo mínimo que deberíamos hacer los profesores. Y predicar al alumnado con el ejemplo: al César lo que es del César, give credit where credit is due. Aprender a citar correctamente cuesta, y pequeños gestos como éste no cuestan nada y van formando al alumno.

En definitiva, yo estoy a favor de tener que citar la fuente de los trozos de código que obtengamos de la red SE. De hecho, como he indicado, es algo que nos beneficia a todos.

Sin embargo, la gran discusión suscitada ha hecho que la gente de SE haya decidido, a fecha de 15 de enero de 2016, aplazar la decisión.