30 marzo 2015

Estadísticas sobre incidentes de fuga de información

El portal Identity Theft Resource Center (algo así como el Centro de Recursos sobre Robo de Identidad) mantiene casi al dia informes referentes a incidentes sobre fuga de información ocurridos en Estados Unidos sobretodo.

Ya al finalizar el 2014, quedó disponible su informe anual en el que registraban todos los incidentes conocidos en los que se hubiera expuesto información referente a usuarios. En los informes además, y para cada incidente, se incluyen referencias sobre dónde se dio a conocer tal caso. La lista realiza el seguimiento de los incidentes en los cuales se ve comprometida información de números de la Seguridad Social, tarjetas de crédito, nombres de usuario, contraseñas y e-mails, así como información médica.

Como estadísticas, se concluye que en 2014 se registraron más de 85 millones de registros de información comprometidos llegando casi a los 800 incidentes.

Resumen de incidentes en 2014

Obviamente la lista del 2015 está todavía por completa, pero el informe se actualiza cada martes (por desgracia, cada semana algo es reportado) De momento llevamos en este 2015 más de 170 incidentes con más de 99 millones de registros comprometidos. La culpa de que esta cifra sea tan elevada se debe en su mayor medida al incidente ocurrido en Anthem (el cual os mencionamos en este Enlaces de la SECmana a principios de Febrero) con casi 80 millones de registros, y al que afectó a Premera Blue Cross con más de 11 millones. Estadística horrible en entorno médico.
En esta página aparece una función para recibir dichas actualizaciones del informe de 2015 a nuestra cuenta de correo personal y así estar al día de lo que vaya ocurriendo.

Página de actualización de incidentes en 2015


Leer más...

29 marzo 2015

Enlaces de la SECmana - 269

Leer más...

27 marzo 2015

Seguro que muchos de los lectores de este blog, teniendo en cuenta cuál es su público más habitual, ya habrán notado que el funcionamiento de GitHub esta mañana ha sido intermitente.

Como es habitual, este mal funcionamiento del servicio se debió a un nuevo ataque DDoS, como se puede comprobar en la página de estado de GitHub.

Siendo los ataques a GitHub tan habituales, ¿por qué prestarle atención a este en concreto? Porque, en primer lugar, según la información disponible, este parece tener un atacante identificado con bastante probabilidad: el Gran Firewall chino. Sin embargo, tampoco es el primer ataque conocido con este origen: recordemos que, a principios de enero, el Gran Firewall hizo que el nombre de dominio de webs censuradas como Facebook resolviese a la dirección IP de la organización ciberactivista francesa La Quadrature du Net, provocando un volumen de tráfico para el que no estaban preparados y que provocó una denegación de servicio.

¿Por qué sucedió esto? Entre las hipótesis más probables barajadas se encuentra la de que haya sido una acción intencionada del Gobierno chino para usar el Gran Firewall por el que pasa la conexión de todos sus ciudadanos para convertir a todos los que quisieran visitar Facebook en atacantes de La Quadrature du Net, una organización que defiende los derechos y libertades en Internet, claramente opuesta a la postura del Gobierno chino con respecto a Internet.

Otras hipótesis barajada es la de que no haya sido una orden que proviniese del Gobierno chino, sino que un empleado con acceso al Gran Firewall esté aprovechando su infraestructura para vender servicios de DDoS a terceras personas.

En cualquier caso, tampoco podemos asegurar que lo que haya pasado --y que es otra hipótesis que se ha planteado-- no sea simplemente que, cuando el Gran Firewall bloquea algún sitio --como Facebook, en este caso-- lo que haga sea que el dominio resuelva a cualquier dirección IP aleatoria y, en este caso, por azar, le ha tocado a una dirección IP de La Quadrature du Net (aunque, de ser esto lo que están haciendo, habría otros rangos de direcciones IP mejores para hacer esto).


No obstante, habiendo también precedentes de ataques con evidencias de proceder del Gran Firewall chino, ¿qué tiene de especial este ataque para que hayamos decidido hablar de él? Lo que hace este ataque interesante son tres motivos:
  • La forma en la que se ha llevado a cabo, que es ciertamente original e inusual y solo posible para alguien con acceso a una infraestructura que pueda interceptar las comunicaciones de millones de personas, como el Gran Firewall chino.
  • La respuesta de GitHub, que también ha sido original.
  • El atacante chino ha usado también usuarios extranjeros para llevar a cabo su ofensiva, poniendo en evidencia una vez más el diseño de Internet basado en la confianza y suposición de buena fe entre las partes y en cómo nos vemos afectados cuando un gran actor como es China traiciona ese principio de buena fe.

Cómo se ha llevado a cabo el ataque

Según las investigaciones de Insight-labs, el modo en el que fue lanzado el ataque fue «secuestrando» el código de tracking de Baidu. Como, sin duda, la mayoría de los lectores sabrán, Baidu es el buscador local chino que tiene prácticamente la hegemonía del mercado, sobre todo tras la retirada de Google al negarse a seguir colaborando con la censura tras recibir un ataque con origen en China. Al igual que Google tiene su servicio Analytics, Baidu tiene un servicio similar de tracking para analizar las visitas recibidas por las páginas web que decidan usar este servicio.


El atacante pudo interceptar las peticiones que solicitaban descargar el código de tracking de Baidu detectando las peticiones a http://hm.baidu.com/h.js para desviarlo a su propio código malicioso. En la siguiente captura, podemos ver a la izquierda el código de tracking actual de Baidu y a la derecha el código que se descargaba durante el ataque según Slashdot:


Si bien ambos códigos están ofuscados, se puede ver que son diferentes ya que el método de empaquetado es distinto y la longitud del código difiere bastante, siendo el código original mucho más largo.

Si desofuscamos el código y comparamos ambas versiones, teniendo de nuevo a la izquierda el código actual y legítimo de Baidu y a la derecha el código del ataque, vemos de nuevo que ambos códigos son totalmente distintos y que el código legítimo es mucho más largo:


Echando un vistazo al código se puede ver rápidamente que el de la izquierda sí tiene la apariencia de ser un código de tracking, mientras que el de la derecha lo único que hace es activar un temporizador que, cada dos segundos, lanza una petición para descargar el contenido de https://github.com/greatfire/ y https://github.com/cn-nytimes/.

Esto provoca que cada usuario que visite una página que use el código de tracking de Baidu esté cada dos segundos haciendo peticiones a GitHub y, de este modo, está participando sin darse cuenta en un ataque DDoS.

Nótese, además, que esta suplantación de código no solo afecta a ciudadanos chinos, sino también a cualquier ciudadano extranjero que intente descargar el código de Baidu, ya que, al estar Baidu alojado en China, su conexión pasaría del mismo modo por el Gran Firewall y se realizaría la suplantación de código igualmente, como le sucedió al investigador de Insight-labs.

Cómo mitigó GitHub el ataque

Si bien el ataque tiene una cierta originalidad --aunque no hubiese sido posible sin la gran cantidad de tráfico que se puede manipular teniendo acceso al Gran Firewall-- la respuesta de GitHub fue más original todavía, ya que el script malicioso no sólo envía una petición para descargar el contenido de https://github.com/greatfire/ y https://github.com/cn-nytimes/, sino que, debido a la forma en la que está programado, también intenta ejecutar ese código como si fuera JavaScript.

Como ese código que descargaba no era JavaScript, sino HTML, probablemente se generará un error en la consola del navegador y no pasará nada. ¿Cómo aprovechó esto GitHub? Reemplazó el código de las páginas atacadas para incluir en su lugar únicamente la siguiente instrucción JavaScript:
alert("WARNING: malicious javascript detected on this domain")
Como se puede ver en la siguiente captura de pantalla:

Y sirvió ese contenido con Content-Type application/javascript:


Así, reemplazado el contenido de esas direcciones por esa instrucción JavaScript y sirviéndolo con el Content-Type correspondiente, el contenido descargado sí se procesaba correctamente como JavaScript y lo que ejecutaba era la única sentencia que incluía, que lo que hacía era mostrar una advertencia al usuario:


Fuente: Insight-labs
De este modo, con esa advertencia se consiguen tres objetivos:
  • Advertir al visitante (y probablemente al dueño de la web cuando la visite) de que esa web incluye un script malicioso.
  • Retrasar el tiempo entre peticiones: ya que la función window.alert() es bloqueante, el resto del script no continuará hasta que el usuario haga clic en aceptar, por lo que se introduce un retraso en esa temporización de dos segundos.
  • Dar la opción al usuario de detener el ataque. Esta nueva variante del script (la versión troyanizada por GitHub de la versión troyanizada por el Gran Firewall del script de Baidu) estaría mostrando alertas con un intervalo de dos segundos, algo sin duda muy molesto para el usuario. La mayoría de navegadores modernos, para evitar la ejecución de scripts molestos, a partir de la segunda alerta dan al usuario la opción de abortar la ejecución del script:
  • Si el usuario, molesto, marca esa casilla antes de hacer clic en aceptar, se detendría el ataque. A base de provocarle una molestia, GitHub puede conseguir que el usuario colabore para detener el ataque.

Conclusión

Como era de esperar, ni en este caso ni en el de La Quadrature du Net hay información oficial ni ninguna explicación por parte de ningún responsable chino que pueda aclarar qué es lo que ha pasado, por lo que lo único con lo que nos podemos quedar es con conjeturas como estas, pero no podremos saber con certeza qué ha pasado.
Sin embargo, dos conclusiones como mínimo creo que se pueden extraer de todo esto:
  • La dependencia de la comunidad de software libre de un servicio centralizado como es GitHub. Si bien hay alternativas a GitHub de código abierto (GitHub no es código abierto), como GitLab, su hegemonía es indiscutible y, aunque esto puede ser un indicativo de la calidad de su servicio, queda en evidencia lo vulnerables que somos a las caídas del mismo, en las que parece que una parte de la actividad de desarrollo se detiene.
  • El diseño de Internet pertenece a otros tiempos y está basado en relaciones de confianza en las que se asume por adelantado la buena fe de todas las partes. Si bien algunos protocolos han ido añadiendo capas y remiendos de seguridad, la arquitectura de Internet todavía es vulnerable a la traición a la buena fe de alguna de las partes, sobre todo al más bajo nivel, como ya se ha demostrado en repetidas ocasiones.
Artículo cortesía de Jesús Perez
Leer más...

26 marzo 2015

Hasta la cocina de las gasolineras españolas

Muchas gasolineras utilizan túneles serie sobre Ethernet para poder enviar datos a un servidor y monitorizar el estado de los tanques de combustible: tipo de combustible almacenado, temperatura del combustible dentro del tanque, cantidad de combustible que queda, etc…

Figura 1. Tanques de combustible.

De esta forma, si el operario advierte que no queda combustible en los tanques, podría tener que cerrar la gasolinera y avisar a un camión para el llenado de los tanques. O, si la temperatura del tanque de combustible fuera elevada, podría considerarse como una situación de riesgo y tomar las medidas oportunas.

Más grave sería aún si el sistema de monitorización no disparase las alarmas oportunas en caso de detectar una temperatura extrema en los tanques, o de no informar cuando un tanque se queda sin combustible.

Para el envío de la información de los datos del estado de un tanque de combustible a un PC para su monitorización, se utilizan conversores de serie a Ethernet del tipo GC-NET2 32-DTE.

Figura 2. Conversor Serial - Ethernet.

El esquema de cómo implementar el túnel serie con el dispositivo anterior para la monitorización de los datos se muestra en la siguiente figura:

Figura 3. Esquema de conexión del conversor serie a Ethernet.

En este artículo se realizará una pequeña prueba de concepto para comprobar cuál es el nivel de seguridad de estos dispositivos.


Localización de conversores en gasolineras españolas.

El primer paso es localizar conversores accesibles desde Internet en las gasolineras de España. Algunos de ellos, para su configuración remota, utilizan el servicio de telnet. Haciendo un poco de hacking con buscadores, buscamos en Shodan conversores en gasolineras de España que usen el puerto 10001 TCP para su configuración:

Figura 4. Estado de un tanque de combustible de una gasolinera de Palencia.


Servidor telnet no securizado.

Una vez que ya tenemos un listado de gasolineras que usan este tipo de conversores para el envío de la información y su monitorización a través de un PC, el siguiente paso es detectar algún conversor con un servicio de telnet sin securizar. En la siguiente imagen se muestra uno de estos sistemas con un servidor telnet escuchando por el puerto 999 TCP.

Figura 5. Conversor con el servicio telnet corriendo en el puerto 9999.

Realizando una conexión desde un cliente telnet al puerto 9999 TCP, observamos cómo el dispositivo no solicita ningún dato de acceso. Directamente podemos acceder a su configuración permitiendo por completo la manipulación de los parámetros del sistema de adquisición y envío de la información de los tanques de combustible al PC de monitorización.



Figura 6. Conexión por telnet sin autenticación.

Comprobamos cómo el sistema no solicita ningún dato de acceso para la configuración  del conversor vía telnet. Una vez dentro de él se podrían deshabilitar todos los disparadores (triggers) que avisasen de situaciones anormales o peligrosas para no ser monitorizadas.


Más servicios no securizados.

Escogiendo la IP pública de la gasolinera tras la cual "se esconde" la red con IP privada y todos los dispositivos y PCs de monitorización, realizamos un escaneo de puertos con nmap para ver qué más servicios están activos detrás del router de una de las gasolineras:

Figura 7. Servicios accesibles desde la IP pública de la gasolinera.

Probando una conexión por HTTP al puerto 90, comprobamos que tenemos acceso a las cámaras IP instaladas en la gasolinera. Tampoco se requiere ningún tipo de autenticación para acceder al panel de monitorización de las cámaras IP:

Figura 8. Cámaras IP de la gasolinera.

Y es más, algunos de los servidores que monitoriza la información recogida por los conversores tiene instalado un Windows XP (sistema operativo sin soporte desde el 8 de abril de 2014) y con escritorio remoto abierto (puerto 3389 TCP), como se muestra en las siguientes figuras:


Figura 9. Servicio de escritorio remoto activo.


Figura 10. Acceso a través del escritorio remoto a un PC con Windows XP.

En este escenario, podrían probarse técnicas como las Sticky Keys para saltarse las aplicaciones de bloqueo del sistema y llegar al menú de impresoras y desde allí a la raíz del sistema de ficheros


Conclusión.

Con lo recogido anteriormente, sería muy fácil realizar un ataque dirigido a gasolineras para sabotear el sistema de monitorización y que éste ofreciese datos erróneos al operador de la gasolinera.
¿Qué pasaría si el operador pensando que ya no hay más combustible en los tanques cierra la gasolinera hasta que vengan los camiones de repostaje de combustible? ¿Qué ocurriría si la temperatura de los depósitos de combustible es elevada y el operario no se percata de esta situación? ¿Qué sucedería si de repente el sistema muestra que no queda más combustible en los tanques en plena hora punta de una operación salida o retorno? ¿Cuáles serían las pérdidas de las gasolineras?

Y lo más importante, ¿en qué grado afectaría a la seguridad de las personas?


PD: los resultados obtenidos en esta prueba de concepto ya han sido reportados.

Artículo por cortesía de: Amador Aparicio de la Fuente (@amadapa)

Leer más...

25 marzo 2015


Al igual que anunciamos el año pasado en este post, la empresa Tuenti cuenta con una competición online de registro público con el que se podrán demostrar las habilidades técnicas en diversos ámbitos de programación.

En este enlace tenéis los retos de las ediciones pasadas de los concursos para que os podáis hacer una idea de a lo que os podríais enfrentar.

El registro permanecerá abierto hasta el 4 de Mayo de 2015, y existen dos fases: la primera online y la segunda presencial. Hasta el momento hay casi 1100 usuarios registrados.

Página de registro para el 5º Tuenti Challenge


La primera fase comienza el 27 de Abril a las 13:37 y finalizarán el 4 de Mayo. De esta fase se seleccionará un top de 50 ganadores. De esos 50, los primeros 10 pasarán a la segunda fase presencial en las oficinas de Tuenti en Madrid.

Los premios consisten en un iPhone 6 para el ganador, un Oculus Rift para el 2º, un Acer Chromebook C720 para el tercero y Raspberry Pi 2 para el resto.

Los retos, al igual que ya se comentó el año pasado, no son únicamente de programación y algoritmia, si no que también cuentan con pruebas sobre seguridad.

Podréis estar al tanto de todas todas las novedades que vayan ocurriendo a través de la cuenta de Twitter del equipo de Engineering: @TuentiEng

Desde Security By Default, ¡os lo recomendamos!

[+] https://contest.tuenti.net/







Leer más...

23 marzo 2015

ARQ, copias de seguridad cifradas en la nube




Este es mi primer artículo en SBD y tengo que agradecérselo a Lorenzo Martínez. La semana pasada le consulté acerca de un software de backup que estaba probando y, tras revisarlo él y parecerle interesante, me ofreció escribir un artículo del mismo. Por supuesto, acepté encantado.

Siempre he estado concienciado con la seguridad y la privacidad, máxime cuando sigues blogs como éste, escuchas las continuas filtraciones de Edward Snowden o Wikileaks y ves de lo que son capaces de hacer agencias gubernamentales como la NSA (¡recomiendo el documental Citizenfour!).

No recuerdo dónde fue, si a través de un blog o un tweet, pero terminé en la web de un software llamado Arq (http://www.haystacksoftware.com/arq/), exclusivo para Mac OS X y que prometía hacer copias de seguridad cifradas en servicios online tales como Dropbox, Google Drive o AWS.

Cada vez se oferta más espacio de almacenamiento online, tanto gratuito como a un precio muy reducido. Aunque las copias de seguridad de Time Machine funcionan perfectamente, más de una vez había pensado en la posibilidad de tener copias adicionales  en la nube, pero desde luego que no estaba dispuesto a que el proveedor del servicio online tuviera acceso a las mismas. ¿Me ayudará Arq a conseguirlo? Vamos a verlo.

Instalación

El archivo que descargas de la web es un fichero .zip llamado Arq.zip. Una vez descomprimido encuentras la aplicación Arq.app. Como siempre, recomiendo copiar la aplicación a nuestra carpeta de Aplicaciones, aunque en este caso Arq se va a mover ella misma.

Abrimos la aplicación y el primer aviso que vemos es para ver si estamos realmente seguros de querer abrirla.

Tras aceptarlo, la aplicación se da cuenta de que no está en la carpeta de Aplicaciones y nos pide permiso para moverse automáticamente. Recomiendo hacerlo.

Configuración del destino de nuestras copias

Una vez movida la aplicación, ésta se abre preguntándonos por el servicio online que deseamos configurar para hacer nuestras copias.


La elección de servicios hay que reconocer que es muy amplia. Son los siguientes:
  • Google Drive
  • Dropbox
  • Amazon Glacier y S3
  • SFTP
  • GreenQloud
  • DreamHost DreamObjects
  • Google Cloud Storage
  • Other S3-compatible service
Vamos a probar la configuración de Dropbox. Los pasos son sencillos e intuitivos:

1.- Seleccionamos Dropbox como destino.


2.- Pulsamos sobre el botón de “Log Into Dropbox” para autenticarnos en el servicio y darle permisos a la aplicación para usarlo. Vemos que la autenticación es del propio Dropbox. Arq no conoce nuestra contraseña.



3.- Y ya tenemos configurada nuestra cuenta y casi lista para usar.


4.- Tras aceptar el mensaje, vemos otro muy útil en el que nos dice que usemos la Sincronización Selectiva de Dropbox para no sincronizar la carpeta en la que haremos nuestras copias. Recomiendo hacerlo no sólo en el equipo en el que tenemos Arq, sino en cualquier otro en el que tengamos esta cuenta de Dropbox sincronizada.


5.- Ahora elegimos si lo que queremos es hacer una copia o restaurar una existente.


6.- Tras seleccionar “Set Up Backups”, lo que se nos pide es la contraseña o llave maestra con la que cifraremos todo nuestro contenido. Es importante que ésta sea lo suficientemente larga para no poder ser obtenida mediante fuerza bruta. La contraseña es almacenada en el Llavero de Mac OS X por lo que podrá ser vista por cualquiera con acceso a él. Con esto quiero indicar que si seleccionamos una contraseña muy segura para las copias, pero tenemos por comodidad nuestro usuario del equipo sin contraseña, cualquier persona con acceso físico a nuestro equipo podría hacerse con la contraseña de cifrado de nuestras copias de seguridad.


7.- Ahora vemos un último recordatorio para tener a buen recaudo nuestra contraseña. Para ello siempre recomiendo un buen gestor de contraseñas como KeePass. Puedes ver un tutorial del mismo aquí.

Primera copia

Una vez configurado nuestro servicio para la copia, Arq nos muestra una ayuda contextual breve indicándonos:
  1. Por defecto Arq copia tu directorio home.
  2. De forma independiente al programa Arq, hay un agente en segundo plano que es el que se encarga de las copias aunque el programa esté cerrado.




Y ya tendríamos listo todo para la primera copia con las opciones por defecto:
  1. Haciendo copia de todo lo que haya en la home de nuestro usuario.
  2. Descartando ciertos directorios que la aplicación considera.
  3. La copia se hará cada hora.



Como posiblemente no nos interese hacer copia de todo nuestro usuario, vamos a ver cómo se especifican las carpetas que queremos copiar.

Configuración de la copia

Vamos a configurar qué y cuándo queremos copiar. Para seleccionar los directorios que queremos copiar pinchamos en el botón “Edit backup selections”.


Para este tutorial únicamente quiero copiar mi carpeta “Developer”. Es posible indicar carpetas o archivos que no queremos copiar. Dejo el “.DS_Store” que viene por defecto y pulso en “Ok”.


Vamos ahora a decirle la frecuencia con la que quiero hacer copias. Para ello nos vamos a la Preferencias (Menú Arq – Preferences)


Ahora, en el apartado de “Destinations” vemos nuestra cuenta de Dropbox. Pulsamos en el botón “Edit…” y aquí lo tenemos. Por defecto se hacen copias cada hora, pero yo voy a indicar que las haga una vez al día, por la noche. Pulso en “Save” y ya está todo listo.


Por no esperar hasta las 12 de la noche, fuerzo a que comience la copia, seleccionando en el menú “Backups” la opción de “Back Up Now”. La copia comienza y termina casi al instante (el directorio que he seleccionado apenas tiene datos).




Una vez terminada la copia, podemos ver tanto los archivos y carpetas que tenemos para copiar (en nuestro equipo) como los copiados (en Dropbox)


Restauración de archivos

Tras haber hecho la copia

Restaurar archivos es aún más sencillo que copiarlos. Nos vamos al día que queramos restaurar y seleccionamos el archivo/carpeta deseado.


Pinchamos en el botón “Restore…” y tras elegir si queremos sobrescribir los archivos existentes e introducir nuestra contraseña de usuario, tenemos los archivos restaurados.


En un equipo nuevo

Vamos a suponer que nuestro ordenador ha decidido morirse o simplemente queremos restaurar nuestras copias en otro ordenador. El proceso es bien sencillo:
  1. Configuramos como nueva la cuenta de Dropbox en la que tengamos la copia (de la misma forma que hicimos en el punto “Primera Copia”
  2. Una vez configurado Dropbox, el software identifica que hay una copia existente y lo muestra en el árbol de restaurar archivos  (“RESTORE FILES”). Nada más pinchemos en él, nos  preguntará por la contraseña con la que ciframos la información.
  3. Tras introducir la contraseña correcta, veremos nuestros archivos copiados.

Viendo los archivos en Dropbox

Si tenemos curiosidad por saber qué se ha copiado en nuestro destino no tenemos más que ir a verlo:
  • Tenemos una carpeta en la raíz llamada Aplicaciones
  • Si accedemos a ella vemos la siguiente estructura:



Preferencias

Vamos a echar un vistazo a las preferencias que podemos modificar de Arq:
  1. Destino: podemos configurar simultáneamente todos los destinos que queramos para nuestras copias.
  2. Red: nos permite controlar el ancho de banda usado para hacer las copias y las redes en las que confiamos para hacerlas.
  3. Email: podemos enviarnos un correo electrónico para verificar que ha ido todo bien.
  4. Avanzadas: por último, podemos indicar ciertos parámetros generales de la aplicación.

Aspectos técnicos

Respecto a cómo se hace la copia, lo que nos dice el fabricante es lo siguiente:
  • Las carpetas y ficheros a copiar son cifrados y comprimidos en tu equipo; luego se envían al destino.
  • Las copias son hechas en un formato abierto y documentado, similar a como lo hace “git”, usando el formato de Amazon S3.
  • Tiene una utilidad open-source (en github) para restaurar copias por lo que éstas siempre podrán ser restauradas aunque el software deje de existir.
  • Se guardan distintas versiones de archivos por lo que se puede recuperar la de un día en concreto.
  • No hay límite de tamaño de archivo.
  • No se borran automáticamente archivos antiguos.
  • Puedes copiar unidades de red o externas.
  • Se puede controlar el funcionamiento de Arq mediante línea de comandos.

Licencia

La aplicación no es gratuita pero tiene un periodo de 30 días de evaluación. El precio de una licencia para un equipo es de $40 aunque hay otras opciones. Puedes verlas en https://store.haystacksoftware.com/

Conclusión

Aunque el programa puede mejorar, sobre todo el interfaz, hace su cometido perfectamente. He probado a hacer una copia completa de mis archivos (unos 80 GB) y tras estar un par de días funcionando, ya están todos cifrados en la nube. Tras el periodo de prueba, compraré la licencia.

Artículo cortesía de Javier Arnáez (@j_arnaez)


Leer más...