Github está luchando por mantenerse al día una campaña de malware que es un nuevo giro en la typosquatting. El juego es sencillo: clonar repositorios populares, agregar malware y anunciar las bifurcaciones como originales. Algunos desarrolladores confunden las bifurcaciones con proyectos reales y ejecutan el malware sin querer. La elección de nombre obvia es forksquatting, pero la Los investigadores de apiiro eligieron el nombre más seguro de “Repo Confusion”.

La campaña está automatizada y GitHub lo sabe, y la gran mayoría de estos repositorios maliciosos se eliminan de inmediato. Por alguna razón, el algoritmo de GitHub no captura todos los repositorios nuevos. La campaña actual parece publicar millones de bifurcaciones, utilizando código de más de 100,000 proyectos legítimos. Está empezando a parecer que la familia de ataques de okupaciones llegó para quedarse.

RustDesk y certificados impares

El software de acceso remoto RustDesk es interesante porque es de código abierto, permite el autohospedaje y está escrito en Rust. He estado explorando RustDesk como una tarea pendiente durante mucho tiempo, pero acaba de terminar un poco de drama preocupante. Un usuario señaló en noviembre que Se instaló un certificado raíz de prueba como parte de la instalación de RustDesk.. Ese certificado raíz está autofirmado con SHA1. También existe la preocupación de que los binarios de RustDesk estén firmados con un certificado diferente.

Desde entonces ha habido nuevos acontecimientos. Primero, hubo un hilo de noticias de hackers sobre el tema a principios de este mes. El día siguiente, CVE-2024-25140 estaba registrado en NIST, con un increíble CVE 9.8 CVSS. Dejemos un poco de FUD y hablemos de lo que realmente está pasando.

En primer lugar, los certificados raíz deberían firmarse con una función hash más segura que SHA1. Pero no por el motivo que crees, y en este caso no importa. Los certificados raíz están autofirmados por definición y la única razón por la que están firmados es porque estos certificados deben estar firmados para que sean válidos. Los certificados secundarios no están protegidos por la firma del raíz. La función importante que depende de esa firma raíz es la capacidad de emitir una solicitud de revocación. Eso sería realmente malo para uno de los certificados raíz más confiables y no sería un problema en absoluto para un certificado que no es de confianza como este.

A continuación, RustDesk tiene un certificado válido y firmado para los ejecutables. El certificado raíz autofirmado es estrictamente para firmar un controlador del kernel, que requiere un certificado de validación extendida (EV). Es un poco desconcertante que este requisito pueda eludirse tan fácilmente instalando un certificado raíz durante la instalación de la aplicación, pero eso es en Microsoft, no en RustDesk.

La última preocupación aquí es que este certificado se está instalando como una Autoridad de certificación (CA) en todo el sistema. Ese es el elemento más preocupante de esta saga, pero los certificados tienen un campo que especifica su uso de clave (KU) y uso de clave extendido (EKU). RustDesk CA es estrictamente para firma de código. Esto no permite que RustDesk ni nadie en posesión de esta clave rompa TLS o falsifique sitios web. Permite la firma de código, lo que podría ser una preocupación válida, pero no es la situación complicada que parece a primera vista.

RustDesk extrajo esta clave de su instalación, lo que desactiva el controlador de pantalla virtual. Esa era la funcionalidad que requería un controlador de kernel firmado. La última noticia es que los desarrolladores de RustDesk están recibiendo ayuda y están buscando un certificado de firma de código EV, y esperan finalizar ese proceso en aproximadamente un mes. ¿Y ese CVE, con una puntuación de gravedad de 9.8? Parece completamente falso.

Inyección SQL de miembro definitivo

El complemento Ultimate Member de WordPress se ha actualizado a la versión 2.8.3. arreglando una falla de inyección SQL que era accesible como usuario no autenticado. Basado en la diferencia de actualización, la cuestión clave es probablemente que se haya pasado por alto prepare() en la línea 704. Ah, y aparentemente está siendo investigado y potencialmente explotado en la naturaleza, así que parchee.

Probablemente este sea un buen momento para charlar sobre por qué hay tantos ataques de inyección SQL en WordPress. En primer lugar, la inyección SQL se produce cuando los datos proporcionados por el usuario se interpretan como parte del comando SQL a ejecutar. Eso se hace incluyendo un personaje inesperado. Por ejemplo, un punto y coma indica el final de una declaración y puede usarse para comenzar la siguiente. Entonces, cuando un programa ingenuo espera un número, una entrada de 15; DROP TABLE Students satisfará una declaración SQL e inyectará una segunda declaración para ser ejecutada en la base de datos.

En términos generales, existen dos enfoques para prevenir la inyección de SQL: desinfección de entradas y declaraciones preparadas. ¡Y ambos también son buenos! Primero, desinfecte la entrada del usuario. Asegúrese de que el número entero sea en realidad un número entero y solo un número entero. Elimine las comillas, el punto y coma y otros caracteres potencialmente peligrosos.

El segundo enfoque es utilizar declaraciones preparadas. Esto separa el comando SQL de los datos de forma fundamental. es algo como $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); para enviar los comandos SQL. Luego es seguido por $database->bind_param("si", $name, $age); para establecer los valores que se utilizarán. Y finalmente un $database->execute(); realmente ejecuta la consulta. No es posible la inyección debido a la estricta separación entre el código y los valores.

Ahora llegamos a WordPress, que tiene su propio wpdb clase para llamadas a bases de datos. Eso incluye una función útil, wpdb::prepare() eso parece casi una declaración preparada como se muestra arriba.

$wpdb->prepare( "u.user_registered BETWEEN %s AND %s", $from_date, $to_date );

Excepto que no lo es en absoluto. El prepare() La función hace estrictamente un pase de higienización, y un sprintf() sustitución de valores. El prepare() La función en realidad no produce una declaración de base de datos preparada. WordPress no proporciona una forma de utilizar declaraciones preparadas. Falta uno de los paradigmas básicos para evitar que los desarrolladores se metan en problemas con las inyecciones de SQL.

Los M&M están mirando

Tengo algo así como un hobby. Me resulta divertido detectar máquinas que se portan mal y tratar de descubrir qué sistema operativo se ejecuta debajo de la brillante GUI. El dispositivo integrado más extraño que he encontrado es un escáner de páginas que ejecuta una copia completa de Windows. Es posible que los escáneres de precios de su gran tienda local simplemente ejecuten Windows CE. Los centros de información y entretenimiento en los respaldos de los asientos del avión ejecutan un Linux realmente antiguo. Y aparentemente las máquinas expendedoras de M&M en la Universidad de Waterloo funcionan Windows con la aplicación Invenda.Vending.FacialRecognition.App.exe.

Lo sabemos porque [SquidKid47] detectó una excepción de software desconocida en la pantalla de la máquina expendedora y la compartió en reddit. A El periódico escolar recogió la historia. (pdf) y determinó que la máquina expendedora utiliza una cámara y detección facial como una combinación de sensor de movimiento inteligente y detector demográfico para publicidad dirigida. Sí, estas máquinas expendedoras ofrecen anuncios dirigidos. Al menos lo hicieron. Estas máquinas expendedoras tienen conoció su Waterloo en la Universidad de Waterloo, y la escuela ahora solicita formalmente su eliminación.

Bits y Bytes

Toca el timbre a Pwn: Resulta que Algunos timbres inteligentes no son tan inteligentes. No es de extrañar que exista un proceso para restablecer un timbre inteligente y asociarlo a otra cuenta. Es bastante sorprendente que este proceso sea tan sencillo como mantener pulsado el botón grande del timbre durante 8 segundos. Como mínimo, el legítimo propietario recibirá un correo electrónico informándole del cambio.

La inseguridad de las impresoras no es nada nuevo, pero la seguridad de las impresoras 3D sigue siendo una idea de nicho. Eso puede estar cambiando, ahora que Se ha eliminado el equivalente a un archivo "greetings.txt". en un montón de impresoras Anycubic. Aparentemente Anycubic usa un servidor MQTT que realmente no tiene suficientes controles de acceso.

Es ese momento otra vez, cuando Se ha publicado una solución de vulnerabilidad para GitLab., y es hora de actualizar. Lo más destacado esta vez es una falla de Cross Site Scripting (XSS) al visitar la página de perfil de un usuario. Lo dejo como ejercicio para el lector, producir un código de muestra que copie "samy es mi héroe" en la página de perfil de cada visitante.

Y finalmente, en el departamento de ironía, Avast ha sido multado por utilizar un complemento de privacidad del navegador como plataforma para recopilar y vender datos del usuario. Esto sucedió entre 2014 y 2020, utilizando la plataforma Jumpshot para la venta real de datos. Los datos fueron nominalmente anonimizados, pero la cantidad y el detalle de la información disponible es un poco asombroso. Vale la pena señalar que Jumpshot ya no existe y Avast ahora es propiedad de otra empresa. Con suerte, sin recopilar información del usuario.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://hackaday.com/2024/03/01/this-week-in-security-forksquatting-rustdesk-and-mms/