Archives 2021

Repasamos cuáles son los errores más frecuentes que cometen los usuarios relacionados con la práctica de realizar backup de su información.

Una introducción a los riesgos y amenazas a las que están expuestas las empresas financieras y los pasos que pueden tomar para contrarrestarlas.

Las empresas que operan en la industria de servicios financieros no están ajenas al hecho de que con frecuencia son blancos de diversas formas de delitos financieros y fraude. Sin embargo, el escenario ha ido cambiado con el paso del tiempo y los actores maliciosos han adaptado sus tácticas para adaptarse mejor al mundo digital. Los ciberdelincuentes ahora utilizan diferentes modalidades de fraude y extorsión, además de atacar directamente a las empresas para llenarse los bolsillos.

Se puede tomar dimensión de la gravedad que representa la amenaza del ciberdelito para las empresas si consideramos el costo que tiene una brecha de datos en este sector. Según datos de la última edición del informe anual que realiza IBM titulado Cost of a Data Breach Report, el costo promedio de una brecha de datos en el sector de servicios financieros fue de $5.85 millones de dólares en 2020, una cifra superior a la de $3.86 millones de dólares que manifestaron los encuestados del resto de los sectores económicos.

Es más, el sector financiero sigue siendo un blanco atractivo para los actores maliciosos, especialmente dada la cantidad y el tipo de información que recolectan de sus clientes. En caso de existir una filtración exitosa, los datos pueden ser utilizados por los atacantes para cometer fraude a través del robo de identidad o para ser comercializados en mercados de la Dark Web, lo que podría provocar un daño a la reputación para la entidad que fue comprometida y también daños financieros y a la reputación para los clientes afectados.

Según la edición 2020 del informe Data Breach Investigation Report que realizó Verizon, se estima que el 63% de los ataques que apuntan a las instituciones financieras son efectuados por actores externos motivados por la ganancia económica. En estos casos, las organizaciones pueden esperar que los cibercriminales lleven adelante ataques de credential stuffing, ataques de ingeniería social, fraude, ataques de denegación de servicio distribuido (DDoS) y de malware.

La pandemia del COVID-19 ha exacerbado los riesgos, especialmente porque muchas compañías fueron forzadas a pasar del trabajo presencial al teletrabajo, una movida que presenta su propio combo de desafíos. Dado que este cambio fue tan repentino muchas compañías probablemente no tuvieron suficiente tiempo para instituir políticas de ciberseguridad que puedan afrontar los probables puntos débiles que tendrán los empleados por estar trabajando repentinamente desde casa.

Hay una clara necesidad de las organizaciones para mejorar sus medidas de seguridad para mitigar las chances de ser víctimas de los ataques dirigidos hacia ellas. De hecho, una reciente encuesta de ESET a 10.000 consumidores y líderes de negocios en varias partes del mundo reveló que 45% de las empresas han experimentado una brecha de seguridad.

El aspecto humano en la seguridad

Los empleados son la base de sus organizaciones, sin dudas. Sin embargo, como dice el viejo adagio “errar es humano”. El informe de IBM encontró que el factor humano es una de las tres principales causas de las filtraciones de datos, siendo un factor determinante en el 23% de las brechas.

Los errores cometidos por los empleados pueden adoptar una variedad de formas: por ejemplo, pueden ser víctimas de phishing o ataques de ingeniería social más dirigidos, o pueden configurar mal un sistema. Los dos primeros errores son particularmente amenazantes si consideramos el desplazamiento hacia el trabajo remoto impulsado por la pandemia. Dado que las empresas no estaban preparadas para la transición rápida e inesperada, en lugar de poder implementar un plan bien pensado, muchas se vieron obligadas a actuar de manera apresurada, lo que provocó que los trabajadores remotos recién incorporados no recibieran ninguna capacitación adicional en ciberseguridad.

Los atacantes podrían utilizar uno de los delitos en línea más dañinos desde el punto de vista financiero: la estafa conocida como Business Email Compromise (BEC). En este tipo de ataque, el ciberdelincuente apunta a su víctima comunicándose desde una cuenta de correo electrónico comprometida perteneciente a un miembro de la empresa (generalmente de mayor jerarquía) o a un miembro de una empresa con la cual se tiene una alianza comercial, solicitándoles que realicen una tarea legítima, como comprar y enviar artículos o transferir pagos. Sin embargo, en lugar de proporcionar datos de una dirección o cuenta bancaria legítima, el estafador agrega la suya propia, robando el dinero a la compañía. Alternativamente, las organizaciones apuntadas pueden recibir un correo electrónico fraudulento que contiene un enlace o un archivo adjunto que oculta malware, que en caso de ser descargado infectará la computadora e incluso puede llegar a extenderse por la red.

Para mitigar las posibilidades de que ocurra cualquiera de estos escenarios, las empresas deben proporcionar una formación adecuada en ciberseguridad a sus empleados. Los programas de capacitación para enseñar a los empleados cómo detectar correos de phishing u otro tipo de ataque que utilice la ingeniería social deben realizarse de forma rutinaria. Además, una buena medida sería proporcionar periódicamente a los trabajadores consejos para el trabajo remoto seguro y protegido, así como orientación sobre cómo comunicarse utilizando herramientas de videoconferencia teniendo en cuenta la seguridad, o cómo proteger el acceso remoto a los sistemas de la empresa de una manera segura.

Al tomar las medidas necesarias, la empresa podrá protegerse a sí misma de sufrir daños monetarios o a la reputación en el futuro. Un beneficio adicional es que estas prácticas de ciberseguridad resultarán útiles mucho después de que haya pasado la pandemia, ya que no todas las empresas están ansiosas por volver a trabajar desde la oficina.

El factor técnico

Si bien educar a los empleados es un aspecto importante para impulsar las prácticas de ciberseguridad, es solo una pieza de un rompecabezas más grande. La mayor parte de la defensa contra las ciberamenazas debe recaer sobre las soluciones técnicas implementadas a lo largo de toda la infraestructura del negocio. Aunque algunos pueden cuestionar la necesidad de invertir sumas considerables, siempre es preferible esperar lo mejor, pero planificar lo peor. Según la encuesta de ESET, el 28% de las empresas no están invirtiendo activamente en nuevas tecnologías para ayudar a proteger las finanzas o al menos no saben si lo están haciendo.

Toda empresa, sin importar su tamaño, debe tener un plan de continuidad del negocio en caso de que ocurra un ciberataque. Un plan adecuado siempre debe incluir copias de seguridad de los datos y, si el presupuesto lo permite, un backup de toda la infraestructura. Estas copias de seguridad  pueden resultar útiles, especialmente si se produce un ataque de ransomware. Sin embargo, para que las copias de seguridad sean eficaces, deben actualizarse periódicamente y evaluarse con frecuencia para garantizar que funcionan correctamente.

Lectura recomendada: Tipos de backup y los errores más comunes a la hora de realizarlo

Todos los sistemas operativos y software deben ser actualizados y parcheados periódicamente. Si contrata a un profesional o tiene un departamento dedicado a la seguridad de la información, lo más probable es que ellos mismos administren estas actualizaciones o configuren sus sistemas de manera que se actualicen automáticamente a la última versión disponible. Lo mismo debe hacerse si sus sistemas son administrados por terceras partes. La importancia de este paso no debe subestimarse, sobre todo si recordamos lo que ocurrió en 2017 gracias al infame ransomware WannaCry, que se propagó a través de máquinas sin parchear.

Los ataques de DDoS que tienen como objetivo interrumpir la capacidad de proporcionar servicios de las víctimas son otra de las amenazas con la que pueden tener que enfrentarse las empresas. Si una empresa se convierte en víctima de un ataque DDoS, sus sistemas se inundarán de solicitudes que superarán la capacidad de dar respuesta a los sitios web y los desconectará. Esto podría traducirse fácilmente en cientos de miles de dólares en ingresos perdidos para el negocio apuntado por los atacantes. Para reducir las posibilidades de que eso suceda, las empresas deben adquirir servicios de mitigación de DDoS, así como utilizar un proveedor de Internet que tenga suficiente ancho de banda, equipo y habilidades para manejar tales ataques y reducir la afluencia de tráfico malicioso.

En resumen

Mientras las organizaciones financieras sigan siendo blancos lucrativos para la mayoría de los cibercriminales, deberán continuar trabajando en mejorar sus defensas para mitigar la posibilidad de ser víctimas de las mayorías de las amenazas. Sin embargo, para construir mecanismos de defensas lo suficientemente fuertes las empresas necesitan tener un enfoque holístico y balanceado, que consiste en invertir tanto en capacitación para empleados como en soluciones tecnológicas adecuadas y planes de continuidad de negocios.

Fuente: www.welivesecurity.com

OpenSSL han publicado un parche para dos fallos de seguridad graves en su software que podían aprovecharse para realizar ataques de denegación de servicio (DoS) y eludir la verificación de certificados.

OpenSSL es un proyecto de software libre basado en SSLeay, desarrollado por Eric Young y Tim Hudson. Consiste en un robusto paquete de herramientas de administración y bibliotecas relacionadas con la criptografía, que suministran funciones criptográficas a otros paquetes como OpenSSH y navegadores web.

Identificados como CVE-2021-3449 y CVE-2021-3450, ambas vulnerabilidades han sido parcheadas en una actualización (versión OpenSSL 1.1.1k) publicada el jueves. Mientras que CVE-2021-3449 afecta a todas las versiones de OpenSSL 1.1.1, CVE-2021-3450 afecta a las versiones de OpenSSL 1.1.1h y posteriores.

Según un aviso publicado por OpenSSL, CVE-2021-3449 se refiere a una posible vulnerabilidad de denegación de servicio (DoS) debida a la desreferenciación de punteros NULL que puede hacer que un servidor TLS de OpenSSL se cuelgue, si, en el curso de la renegociación, el cliente transmite un mensaje «ClientHello» malicioso durante el «handshake» entre el servidor y un usuario. El problema se introdujo como parte de los cambios que se remontan a enero de 2018.

CVE-2021-3450, por su parte, se refiere a un «flag» X509_V_FLAG_X509_STRICT que permite realizar comprobaciones de seguridad adicionales de los certificados presentes en una cadena de certificados. Aunque esta bandera no está activada por defecto, un error en la implementación hacía que OpenSSL no comprobara que «los certificados no CA no deben poder emitir otros certificados», lo que daba lugar a un bypass de certificados.

Como resultado, el fallo impedía que las aplicaciones rechazaran los certificados TLS que no estuvieran firmados digitalmente por una autoridad de certificación (CA) de confianza del navegador.

Aunque ninguno de los dos problemas afecta a OpenSSL 1.0.2, también hay que tener en cuenta que la versión está fuera de soporte desde el 1 de enero de 2020 y ya no recibe actualizaciones. Se recomienda a las aplicaciones que dependen de una versión vulnerable de OpenSSL que apliquen los parches para mitigar el riesgo asociado a los fallos.

Más información:

https://thehackernews.com/2021/03/openssl-releases-patches-for-2-high.html

https://www.openssl.org/news/vulnerabilities.html

Fuente: Hispasec.com

Fuente: www.somoslibres.org

Este domingo 28 de marzo, hackers lograron acceder al repositorio Git interno del lenguaje de programación PHP y lograron añadir una puerta trasera al código fuente del mismo. Estamos hablando del lenguaje del lado del servidor más usado en toda la web y que se calcula está en uso en el 79.1% de todos los sitios web.

Como explican en las listas de correo de PHP, el ataque insertó dos cambios maliciosos en el repositorio php-src, y aunque aún se desconoce la causa y hay una investigación en marcha, todo apunta a que el servidor oficial git.php.net fue comprometido.

Aunque el ataque fue detectado rápido, es una enorme advertencia

El mecanismo de puerta trasera fue detectado por primera vez por Michael Voříšek, un ingeniero de software de República Checa. Si este código malicioso hubiera llegado a producción, podría permitir a los hackers ejecutar sus propios comandos PHP maliciosos en los servidores de las víctimas.

Algunos expertos creen que es posible que los atacantes querían ser descubiertos, o que se trataba de un cazador de bugs por los «mensajes» que dejó en el código. Lo que pasa es que para poder desencadenar la ejecución del código malicioso, el atacante tenía que enviar una petición HTTP a un servidor vulnerable con un user agent que comenzara con la cadena «zerodium».

Zerodium es una plataforma famosa de ciberseguridad especializada en la adquisición y venta de exploits zero day. Zerodium ha declarado ya que no tiene nada que ver con esto, por lo que se piensa que quien sea que hackeó el código no buscaba ser nada sutil, pero no se saben sus intenciones.

Además de esto, los atacantes añadieron un mensaje en uno de los parámetros de la función que ejecuta: “REMOVETHIS: sold to zerodium, mid 2017«. Claramente se busca implicar o hacer referencia a la empresa en esto, pero nadie sabe si se vendió algo a Zerodium en 2017 ni mucho menos qué fue.

En los chats de PHP en Stack Overflow hay muchas conjeturas. Algunos creen que podría haber sido un «pobre intento» de hacking de sombrero blanco, mientras que otros incluso apuntan a un «skript-kiddie completamente inepto».

PHP mudado a GitHub

Mientras la investigación continua y se está realizando una revisión más minuciosa del código fuente de PHP, se ha decidido que el mantenimiento de una infraestructura Git propia es un riesgo de seguridad innecesario y por lo tanto el servidor git.php.net se va a descontinuar.

A partir de ahora los repositorios en GitHub que antes eran solo mirrors, pasarán a ser los principales, por lo que los cambios deberán enviarse directamente a GitHub en lugar de a git.php.net.

El código malicioso que se añadió al código fuente se hizo a través de las cuentas de dos de los miembros del equipo core de PHP, Rasmus Lerdorf and Nikita Popov, pero ya ambos expresaron no estar involucrados. Además, el equipo usa autenticación de doble factor para sus cuentas, por eso creen que se trató de un fallo crucial en el servidor Git principal en lugar de la violación de alguna cuenta individual.

Aunque el incidente fue resuelto rápidamente, en la práctica hubiese afectado a una pequeña porción de los sistemas que usan servidores PHP, puesto que suele ser usual que la mayoría se tarden mucho tiempo en actualizar a la última versión.

Esto es otro problema que viene plagando a la web hace tiempo, el cómo un enorme porcentaje de las webs en Internet usan una versión de PHP que no tiene soporte, y aunque ha mejorado en los últimos años, todavía casi el 40% de todas las webs que usan PHP usan una versión antigua y sin soporte.

Fuente: www.genbeta.com

Nuevo capítulo en la historia que esta semana ha removido las aguas de la supuesta comunidad del Software Libre y que tal y como está el panorama, no parece que vaya a dar mucho más de sí. Porque Stallman está sentenciado y la Free Software Foundation (FSF) también. Esta es mi opinión y, por si a alguien se le nubla la vista, este es, como el anterior, un artículo de opinión…, pero con mucha información.

Recapitulando: la noticia de la vuelta de Richard Stallman a la Junta Directiva de la FSF ha generado una serie de reacciones a lo largo y ancho del mundo del código abierto que resumí de manera escueta en el artículo -también de opinión- No hay perdón para Richard Stallman, en el que me centré en el fondo del asunto, que no es otro que la censura ideológica más inclemente por parte de quienes se rclaman defensores de la libertad.

Mi postura el respecto creo que quedó patente en el artículo citado, así que no me voy a repetir, pero sí me voy a disculpar por seguir machacando un poco más con el tema.

Pero he aquí un dato incuestionable: cuando todos están contra ti, no hay nada que hacer. Y por todos, me refiero a todos los que importan; porque las dos mil y pico personas que firmaron el comunicado a favor de Stallman son solo eso, personas independientes que no importan nada en el cuadro que se está dibujando, y en el que las grandes organizaciones tienen la última palabra. El comunicado de repulsa a Stallman también lo han firmado mas de 2.500 personas, pero los apoyos que cuentan son los de compañías como Mozilla o SUSE, de organizaciones como GNOME Foundation o Creative Commons… y así hasta una cincuentena y subiendo.

La última en sumarse al linchamiento ha sido el gran referente del código abierto, Red Hat, y lo ha hecho sin medias tintas, anunciando que «suspenderemos de inmediato todos los fondos que Red Hat destina a la FSF y a cualquier evento organizado por la FSF. Además, muchos colaboradores de Red Hat nos han dicho que ya no planean participar en eventos dirigidos o respaldados por la FSF, y nosotros los respaldamos».

Red Hat hace mención también a otro comunicado que lanzó la FSF y que recogía a su vez la postura del proyecto KDE, que -al menos por ahora- no se ha sumado a la petición de cancelación de Stallman, pero que pide una reestructuración en el modelo de gobernanza de la organización para hacerlo más «democrático», por resumirlo de algún modo. Petición extendida en otros grupos que la FSF ha dicho que llevará a cabo y que contempla procesos de elección más transparentes.

Sin embargo, Red Hat no confía en que la FSF cumpla con su palabra, pues ya les pidieron lo mismo en 2019, cuando estalló el escándalo que terminó con la renuncia de Richard Stallman a su puesto en la organización. Lo curioso del caso es que la demanda de Red Hat es «la transición hacia una membresía de junta más diversa e inclusiva», y esto lo exige una compañía cuya junta directiva está compuesta por 21 miembros entre los que solo hay dos mujeres y un hombre de ascendencia india. El resto son hombres blancos.

La observación que hago es triste, pero obligada dada la tesitura sobre la que gira todo este lío. Claro que también conviene remarcar que Red Hat es una empresa y la FSF una organización sin ánimo de lucro, que además depende de los fondos que la anterior y muchas otras destinan a su mantenimiento.

Pero no solo organizaciones externas se han posicionado en contra de la FSF y la posibilidad de que Stallman recupere un puesto en la junta. La misma Free Software Foundation Europe ha publicado un comunicado rechazando la máxima, pero añadiendo un factor al que hice mención en mi artículo del otro día y que creo que es, como mínimo, de decencia humana: «Desaprobamos este paso, que llegó sin ningún mensaje de remordimiento o voluntad de cambiar», indican.

Como se suele decir, el pescado está vendido y difícilmente Stallman pueda retomar su posición sin llevarse por delante a la FSF al completo. Al mismo tiempo, la FSF lo tiene complicado para salir de una pieza si se mantiene firme, y de lo contrario demostrará ser solo un títere en manos de los que subvencionan su existencia. Luego Stallman está sentenciado, pero la Free Software Foundation también lo está, repito.

A falta de que la FSF lance un comunicado oficial y final (y ya veremos el proyecto GNU, porque numerosas partes están incluso amenazando con repudiar licencias como la GPL), no hay mucho más que hablar. Quizás y solo quizás, si todas esas personas que se han afanado en firmar a favor de Stallman, empezasen a rascarse el bolsillo y hacer donaciones, el proyecto podría conservar su dignidad y mantenerse a flote sin la participación de las compañías que ahora lo sustentan.

Siendo realistas, no va a pasar… y el mundo va a seguir girando.

Fuente: www.muylinux.com

Se conoce por email spoofing a la suplantación de la identidad a través del correo utilizando una dirección de remitente fraudulenta. Una técnica común en ataques de phishing y spam.

Email spoofing es una técnica que utilizan los atacantes para ocultar la verdadera dirección del remitente en un correo malicioso y sustituirla por una legítima suplantando la identidad de una empresa o un usuario al utilizar un dominio auténtico. Los atacantes suelen utilizar esta técnica en campañas de phishing o spam maliciosas para mejorar su eficacia al evadir controles antispam y hacer que los correos tengan una apariencia más creible.

Pero para comprender cómo funciona el email spoofing es importante dar un paso hacia atrás para entender los mecanismos involucrados en las comunicaciones.

Comunicaciones en el envío de correos electrónicos

Los sistemas que gestionan el envio y recepción de correos utilizan tres protocolos principales: en el envío se utiliza el protocolo SMTP (Simple Mail Transfer Protocol), y para la recepción se implementan los protocolos IMAP o POP, dependiendo del servidor que se use.

El protocolo SMTP se basa en transacciones entre remitente y receptor, emitiendo secuencias de comandos y suministrando los datos necesarios ordenados mediante un protocolo de control de transmisión de conexión (TCP). Una de estas transacciones cuenta con tres secuencias de comando/respuesta: La dirección de retorno o emisor (MAIL), la dirección del destinatario (RCPT) y el contenido del mensaje (DATA).

Estos datos generalmente son completados de manera automática por el servidor de nuestro proveedor de correo, en donde todos los usuarios cuentan con autenticación previa, con lo cual el protocolo no exige ningún tipo de verificación de identidad en su uso. Si bien hay algunos proveedores de correo como Gmail u Outlook que no permiten suplantar la identidad de correos dentro de su dominio, la mayoría de direcciones existentes pueden llegar a ser víctimas de este ataque.

• El creador de un canal podrá iniciar un chat de audio y conversará con el resto a través de esta forma. Actualmente, la función solo está disponible para la versión beta de Android.
• Otra función de Telegram que llega a WhatsApp: los audios se podrán reproducir a mayor velocidad.

Aunque Linux es considerado como un sistema seguro porque lo es, debido a su diseño y a las características que se han ido incorporando a lo largo del tiempo, siempre se puede hacer más, especialmente en el desarrollo directo del kernel Linux, en el que los esfuerzos suelen derivarse a otras áreas.

Así, The Linux Foundation ha anunciado que Google financiará el trabajo a tiempo completo de dos desarrolladores que se centrarán en la seguridad del núcleo; dos mantenedores del kernel Linux con años de experiencia a sus espaldas y que ahora enfocarán toso sus esfuerzos en detectar y corregir las fallas de seguridad que se encuentren.

Teniendo a Google por un lado y a dos desarrolladores por el otro, puede parecer una iniciativa irrisoria, pero la compañía espera que otras organizaciones se animen a hacer lo mismo en con el objetivo de corregir de una vez por todas una larga lista de problemas que ya se sabe que están ahí. La opinión de Google es que apuntar al kernel tendrá un impacto más amplio en la seguridad subyacente de ecosistema de software que se basa en este.

La tarea de uno de estos desarrolladores consistirá en «corregir todos los errores encontrados con los compiladores de Clang / LLVM mientras se trabaja en el establecimiento de sistemas de integración continua para respaldar el trabajo en curso. Una vez que estos objetivos estén bien establecidos, el plan es comenzar a agregar funciones y pulir el kernel utilizando estas tecnologías de compilación».

El segundo mantenedor se dedica ya a «eliminar varias clases de desbordamientos de búfer mediante la transformación de todas las instancias de matrices de un elemento y de longitud cero en miembros de matriz flexible, que es el mecanismo preferido y menos propenso a errores para declarar tales tipos de longitud variable», así como «se está enfocando activamente en corregir errores antes de que lleguen a la línea principal, mientras que también desarrolla de manera proactiva mecanismos de defensa que eliminan clases enteras de vulnerabilidades».

¿Y todo lo demás? Por el modelo colaborativo de desarrollo que emplea Linux, son muchos los ojos que detectan problemas y alertan de ellos, y los encargados de solucionarlos suelen ser los responsables del área en cuestión, pero hay ciertas partes del kernel que son más susceptivas a acumular más errores y menos atención, como las descritas, por lo que es ahí donde se están centrando los esfuerzos ahora.

De momento parece que todo marcha bien, pero porque haya poco que arreglar, sino por todo lo contrario. En The Register han entrevistado a este par de desarrolladores y el titular lo dice todo: «Estamos encontrando errores mucho más rápido de lo que podemos solucionarlos», lo cual no es negativo per se, pero sí indica que la labor que han comenzado no es de las que se terminan pronto.

Hace tiempo además que en The Linux Foundation se están preocupando por mejorar la seguridad no solo del kernel, sino de los componentes de código abierto más populares. En este caso, lo harán en colaboración con Google, que al menos por ahora sigue teniendo en Linux el motor de todos sus grandes proyectos.

¿Y qué dice Linus Torvalds de todo esto? Nada. El jefe se está controlando todo lo que puede, desde que la presión de los nuevos inquisidores de Internet se le echase al cuello por su «comportamiento tóxico» y nos ha dejado sin las declaraciones sin filtro de antaño, como aquella en la que hablaba del circo de la seguridad y de «la gente de OpenBSD masturbándose como monos porque no hay nada más importante que la seguridad».

Con todo, Torvalds se refería a que todos los errores importan, sean relativos a la seguridad o a cualquier otro aspecto. Y algo de razón no le faltaba, como señalaba tiempo después su compañero de batalla Greg Kroah-Hartman en relación a los procedimientos de seguridad aplicados a Linux. No obstante, nunca está de más fijarse en todo lo que se pueda.

Fuente: www.muylinux.com

SystemRescue 8 ya está entre nosotros para ofrecernos versiones más recientes de las herramientas de rescate de sistemas y recuperación de datos que suministra. Si el nombre resulta familiar, es debido a que anteriormente se llamaba casi igual: SystemRescueCd. Eso sí, el ligero cambio de nombre no ha alterado el concepto manejado por la distribución.

SystemRescue es una vieja conocida de los círculos de Linux y por aquellos especializados en sistemas de recuperación. En la versión 8 de esta distribución nos encontramos con el entorno de escritorio Xfce 4.16, el cual puede ir mejor sobre aquellas gráficas que no cuentan con un buen soporte de aceleración por hardware. También destaca la presencia del kernel Linux 5.10 LTS y la sustitución de exfat-utils por exfatprogs para mejorar el soporte del sistema de ficheros exFAT, el cual empezó a llegar de forma oficial a partir de la versión 5.7 del kernel.

Tras exponer las características básicas del sistema, ahora vamos a mencionar el otro aspecto más interesante de SystemRescue: las herramientas. Aquí nos encontramos, siguiendo la lista de cambios, con Parted 3.4, GParted 1.2, btrfs-progs 5.10.1, xfsprogs 5.10.0, e2fsprogs 1.46.2, nwipe 0.30, Dislocker 0.7.3, FSArchiver 0.8.6, exfatprogs 1.1 y memtest86+ 5.01. Obviamente, también tiene soporte para NTFS con ntfs-3g y es capaz de trabajar el sistema de ficheros FAT32, que a día de hoy sigue estando muy presente sobre todo en pendrives con poca capacidad de almacenamiento.

SystemRescue 8 cuenta con otras novedades como Paperkey, una herramienta Open Source para línea de comandos que permite la exportación de claves GnuPG a papel. La implementación de Python del sistema ha sido actualizada a la versión 3.9.2 y se ha incorporado el paquete python-pip para facilitar la instalación de programas escritos con dicho lenguaje y ejecutables con el intérprete oficial.

SystemRescue es una distribución basada en Arch Linux, heredando de esta características como el gestor de paquetes Pacman, uno de los preferidos de los usuarios de GNU/Linux. Los que estén interesados en SystemRescue 8 pueden descargar el sistema para x86 de 32 o 64 bits desde la correspondiente página en la web del proyecto, además de consultar las listas de cambios y de paquetes.

Fuente: www.muylinux.com

Por segunda vez en lo que va de marzo y cuarta vez en 2021, Google lanza parche para reparar una vulnerabilidad zero-day que está siendo utilizada por atacantes de manera activa.

A comienzos de marzo Google lanzaba la versión 89.0.4389.72 de Google Chrome y hace apenas unos días lanzó la versión 89.0.4389.90 para la versión de escritorio para Windows, Linux y Mac. En esta última, la compañía repara una nueva vulnerabilidad zero-day, registrada como CVE-2021-21193, y según informa, está al tanto de la existencia de un exploit que está siendo utilizado de manera activa.

En la pasada actualización de principios de mes Google reparaba 47 vulnerabilidades, entre ellas la CVE-2021-21166, mientras que en esta actualización repara solo cinco vulnerabilidades.

En el caso de la zero-day reparada en esta última actualización, la misma fue catalogada como de alta severidad y se trata de una vulnerabilidad del tipo “use after free” en el motor de renderizado de código abierto conocido como Blink.

Si bien al igual que en la actualización anterior, la compañía no dio mayores detalles sobre el fallo ni sobre los ataques hasta una mayor adopción de la actualización, según CWE, este tipo de vulnerabilidades puede tener varias consecuencias, como la ejecución de código de manera arbitraria. En este caso, en equipos que utilicen una versión desactualizada del navegador.

Como decíamos al inicio, se trata de la segunda vulnerabilidad zero-day bajo activa explotación que Google repara en su navegador Chrome en lo que va de este mes. Además, es la cuarta zero-day en lo que va de 2021, a lo que se suman las cinco reparadas entre octubre y noviembre de 2020, también bajo activa explotación.

Para los que aún no lo hicieron, recomendamos actualizar Google Chrome a la última versión lo antes posible.

Fuente: www.welivesecurity.com