Encontraron código malicioso dentro de xploits alojados en GitHub

trojan linux

La manera en como introducir código malicioso continua evolucionando tomando los antiguos métodos y mejorando la forma en como engañar a las victimas

Tal parece que la idea del caballo de Troya sigue siendo bastante útil hoy en día y de una formas tan sutiles que muchos podemos pasar desapercibidas y es que hace poco investigadores de la Universidad de Leiden (Países Bajos) estudiaron el problema de publicar prototipos de exploits ficticios en GitHub.

La idea de utilizar estos para poder atacar a los usuarios curiosos que desean probar y conocer la forma en la que se pueden explotar algunas vulnerabilidades con las herramientas ofrecidas, hace que este tipo de situaciones sean las ideales para introducir código malicioso para atacar a los usuarios.

Se informa que en el estudio se analizaron un total de 47.313 repositorios de exploits, que cubren vulnerabilidades conocidas identificadas desde 2017 hasta 2021. Un análisis de exploits mostró que 4893 (10,3%) de ellos contienen código que realiza acciones maliciosas.

Es por ello que se recomienda a los usuarios que decidan utilizar exploits publicados que primero los examinen en busca de inserciones sospechosas y ejecuten exploits solo en máquinas virtuales aisladas del sistema principal.

La prueba de concepto (PoC) de exploits para vulnerabilidades conocidas se comparte ampliamente en la comunidad de seguridad. Ellos ayudan a los analistas de seguridad a aprender unos de otros y facilitan evaluaciones de seguridad y tareas de red teaming.

Durante los ultimos años, se ha vuelto bastante popular distribuir los PoC por ejemplo, a través de sitios web y plataformas, y también a través de repositorios de códigos públicos como GitHub. Sin embargo, los repositorios de códigos públicos no proporcionan cualquier garantía de que cualquier PoC dado proviene de una fuente confiable o incluso que simplemente hace exactamente lo que se supone debe de hacer.

En este trabajo investigamos PoC compartidos en GitHub para vulnerabilidades conocidas descubiertas en 2017–2021. Descubrimos que no todos los PoC son confiables.

Sobre el problema se han identificado dos categorías principales de exploits maliciosos: exploits que contienen código malicioso, por ejemplo, para dejar una puerta trasera en el sistema, descargar un troyano o conectar una máquina a una botnet y exploits que recopilan y envían información confidencial sobre el usuario.

Además, también se identificó una clase separada de exploits falsos inofensivos que no realizan acciones maliciosas, pero tampoco contienen la funcionalidad esperada, por ejemplo, diseñados para engañar o advertir a los usuarios que ejecutan código no verificado desde la red.

Algunas pruebas de concepto son falsos (es decir, en realidad no ofrecen funcionalidad PoC), o
incluso maliciosos: por ejemplo, intentan exfiltrar datos del sistema en el que se están ejecutando, o intentan instalar malware en ese sistema.

Para abordar este problema, hemos propuesto un enfoque para detectar si un PoC es malicioso. Nuestro enfoque se basa en detectar los síntomas que hemos observado en el conjunto de datos recopilados, por
ejemplo, llamadas a direcciones IP maliciosas, codificado de código, o binarios troyanizados incluidos.

Con este enfoque, hemos descubierto 4893 repositorios maliciosos de 47313
repositorios que se han descargado y comprobado (es decir, el 10,3% de los repositorios estudiados presentan codigo malicioso). Esta cifra muestra una prevalencia preocupante de peligrosos PoC maliciosos entre el código de explotación distribuido en GitHub.

Se utilizaron varios controles para detectar exploits maliciosos:

  • El código de explotación se analizó para detectar la presencia de direcciones IP públicas cableadas, después de lo cual las direcciones identificadas se verificaron adicionalmente en bases de datos con listas negras de hosts utilizados para controlar botnets y distribuir archivos maliciosos.
  • Los exploits proporcionados en forma compilada se han comprobado con el software antivirus.
  • Se detectó en el código la presencia de volcados hexadecimales atípicos o inserciones en formato base64, tras lo cual dichas inserciones fueron decodificadas y estudiadas.

Tambien se recomienda para aquellos usuarios que gustan por realizar las pruebas por su propia cuenta, tomen en primer plano fuentes como Exploit-DB, ya que estas intentan validar la efectividad y la legitimidad de los PoC. Ya que, por el contrario, el código público en las plataformas como GitHub no tienen el proceso de verificación de exploits.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles del estudio en el siguiente archivo, del cual te comparto su enlace.

from Linux Adictos https://ift.tt/J1FpEs8
via IFTTT

Linus Torvalds propone finalizar el soporte para i486 en el kernel de Linux

Linus Torvalds

Linus Benedict Torvalds es un ingeniero de software finlandés-estadounidense, ​ conocido por iniciar y mantener el desarrollo del kernel Linux,

Hace poco mientras se discutía las soluciones en los procesadores x86 que no admiten la instrucción «cmpxchg8b», Linus Torvalds afirmó que podría ser el momento de hacer que esta instrucción sea obligatoria para que el kernel se ejecute y elimine la compatibilidad con los procesadores i486 que no admiten «cmpxchg8b», en lugar estar de «tratando de emular el funcionamiento» de esta instrucción en procesadores que «ya nadie usa».

Actualmente, casi todas las distribuciones de Linux que continúan admitiendo sistemas x86 de 32 bits han cambiado a compilar el kernel con la opción X86_PAE, que requiere compatibilidad con «cmpxchg8b».

Según Linus, en términos de soporte en el kernel, los procesadores i486 han perdido relevancia, a pesar de que todavía se encuentran en la vida cotidiana. En cierto punto, los procesadores se convierten en piezas de museo, y para ellos es bastante posible arreglárselas con núcleos de «museo».

Cabe mencionar que en dado caso de proceder la eliminación del soporte para el i486 clásic, este no afectará a los procesadores Quark embebidos de Intel, que, aunque pertenecen a la clase i486, incluyen instrucciones adicionales típicas de la generación Pentium, entre ellas «cmpxchg8b».

Ademas de ello se menciona que lo mismo se aplica a los procesadores Vortex86DX. La compatibilidad con los procesadores i386 se eliminó en el kernel hace 10 años.

Tal vez deberíamos morder la bala y decir que solo admitimos x86-32 con ‘cmpxchg8b’ (es decir, Pentium y versiones posteriores).

Deshágase de todos los «emular atómicos de 64 bits con cli/sti, sabiendo que nadie tiene SMP en esas CPU de todos modos», e implemente una configuración genérica x86-32 xchg() usando ese bucle try_cmpxchg64.

Creo que la mayoría (¿todas?) de las distribuciones ya habilitan X86_PAE de todos modos, lo que hace que X86_CMPXCHG64 sea parte del requisito básico.

No es que esté convencido de que la mayoría de las distribuciones incluso hacen desarrollo de 32 bits en estos días.

Nos deshicimos de la compatibilidad con i386 en 2012. ¿Quizás es hora de eliminar la compatibilidad con i486 en 2022?

La finalización del soporte de i486 podría ser un hito a considerar, ya que desde no hace mucho diversas distribuciones de Linux, optaron por eliminar el soporte para procesadores de 32 bits, lo cual realmente no repercutió como muchos esperaban. Ya que como tal si, aún existen miles de usuarios que cuentan con ordenadores de bajos recursos, lo que convertía a Linux en una excelente opción para continuar dándoles un uso a estos, en especial en muchas zonas marginadas.

Y aunque se continuara dado el soporte para este tipo de equipos por parte de las principales distribuciones, los requisitos actuales de ellas, hacían que uso fue realmente imposible de realizar. Lo cierto es que aún hay algunas distribuciones que continúan dando el soporte para esta arquitectura y sobre todo que están optimizadas para el uso de equipos de bajos recursos.

Sobre el caso de la finalización del soporte, se menciona que los usuarios que tengan sistemas con procesadores i486 podrán utilizar las versiones LTS del kernel, las cuales se mantendrán por muchos años más.

Por otro lado, tambien vale la pena mencionar que el desarrollador del controlador Linux de código abierto para la GPU Apple AGX utilizada en los chips Apple M1 informó que superó con éxito el 99,3% de las pruebas del conjunto dEQP-GLES2, que verifica el nivel de soporte para la especificación OpenGL ES 2. En el trabajo se utilizaron dos componentes: un controlador DRM para el kernel de Linux, escrito en Rust, y un controlador Mesa escrito en C.

El desarrollo de controladores se complica por el hecho de que Apple M1 usa su propia GPU, diseñada por Apple, ejecuta firmware patentado y usa estructuras de datos compartidas bastante complejas. No hay documentación técnica para la GPU y el desarrollo de controladores independiente utiliza ingeniería inversa de controladores de macOS.

El controlador de código abierto desarrollado para Mesa se probó inicialmente en un entorno macOS hasta que se preparó el controlador DRM (Direct Rendering Manager) requerido para el kernel de Linux, lo que permitió que el controlador desarrollado para Mesa se usara en Linux.

Además del éxito actual al pasar las pruebas dEQP-GLES2, a fines de septiembre, el controlador de Linux para chips Apple M1 alcanzó un nivel adecuado para ejecutar una sesión de GNOME basada en Wayland y ejecutar el juego Neverball y YouTube en el navegador Firefox.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/2G91Qaf
via IFTTT

Caliptra, un proyecto para la construcción de chips IP confiables

Caliptra

Caliptra, es una especificación abierta para incorporar mecanismos de seguridad dentro de los chips

Hace poco Google, AMD, NVIDIA y Microsoft dieron a conocer mediante una publicación de blog, la noticia del proyecto en conjunto «Caliptra», con el cual han desarrollado un bloque de diseño de chip abierto (bloque IP) para incorporar herramientas en chips para crear componentes de hardware confiables (RoT, Root of Trust).

Caliptra es una unidad de hardware separada con su propia memoria, procesador e implementación de primitivas criptográficas, que proporciona verificación del proceso de arranque, el firmware utilizado y la configuración del dispositivo almacenada en la memoria no volátil.

Caliptra se puede utilizar para integrar en varios chips una unidad de hardware independiente que realiza comprobaciones de integridad y garantiza que el dispositivo utiliza firmware verificado y autorizado por el fabricante. Caliptra puede simplificar y unificar significativamente la integración de mecanismos de verificación criptográfica de hardware incorporados en CPU, GPU, SoC, ASIC, adaptadores de red, unidades SSD y otros equipos.

La implementación básica del bloque IP se basa en el procesador abierto RISC-V SWeRV EL2 y está equipado con 384 KB de RAM (128 KB DCCM, 128 KB ICCM0 y 128 KB SRAM) y 32 KB de ROM. Los algoritmos criptográficos admitidos incluyen SHA256, SHA384, SHA512 ECC Secp384r1, HMAC-DRBG, HMAC SHA384, AES256-ECB, AES256-CBC y AES256-GCM.

El proyecto Caliptra gira en torno al establecimiento de una raíz de confianza (RoT): construir capas de seguridad en el silicio para que los datos se cifren y no estén expuestos mientras viajan en los centros de datos o en la nube.

«El día de hoy marca un gran paso adelante en la colaboración de seguridad de toda la industria con el lanzamiento de las especificaciones de Caliptra 0.5 por parte de OCP y la disponibilidad de Caliptra 0.5 RTL a través de CHIPS Alliance. AMD seguirá siendo un participante activo en Caliptra y Open Compute Project. en apoyo de nuestros clientes y socios en todo el ecosistema». Mark Papermaster, CTO y vicepresidente ejecutivo de tecnología e ingeniería de AMD

«Los ecosistemas abiertos y los proyectos son fundamentales para el negocio de Google y lo han sido desde el primer día», dijo Partha Ranganathan, vicepresidente y miembro de ingeniería de Google Cloud y miembro de la junta de OCP. «Con Caliptra, estamos llevando la velocidad del desarrollo de código abierto a la seguridad de la infraestructura, lo que permite a la comunidad fortalecer colectivamente un sólido bloque de IP en el que todos podemos confiar en un conjunto diverso de ofertas de silicio». 

«Se necesita una mayor transparencia y consistencia en la seguridad del hardware de bajo nivel. Estamos abriendo Caliptra con nuestros socios para abordar estas necesidades». Mark Russinovich, director de tecnología y miembro técnico de Microsoft Azure.

Los medios de verificación criptográfica de integridad y autenticidad proporcionados por la plataforma protegerán los componentes de hardware de la introducción de cambios maliciosos en el firmware y asegurarán el proceso de carga y almacenamiento de la configuración para evitar que el sistema principal se vea comprometido como resultado de ataques a componentes de hardware o sustitución de cambios maliciosos en las cadenas de suministro de chips.

Caliptra también brinda la capacidad de autenticar actualizaciones de firmware y datos relacionados con la plataforma (RTU, Root of Trust for Update), detectar daños en el firmware y datos críticos (RTD, Root of Trust for Detection), restaurar firmware y datos dañados (RTRec, Root de Fideicomiso para la Recuperación).

Caliptra se está desarrollando sobre la plataforma del proyecto conjunto Open Comput , cuyo objetivo es desarrollar especificaciones abiertas para equipos para equipar centros de datos.

Las especificaciones relacionadas con Caliptra se distribuyen mediante el Acuerdo de Fundación Web Abierta (OWFa), diseñado para promover estándares abiertos (similar a una licencia de fuente abierta para especificaciones). El uso de OWFa hace posible crear sus propios productos e implementaciones derivadas basadas en la especificación sin deducir regalías y permite que cualquier organización participe en el desarrollo de la especificación.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/OUzsbBM
via IFTTT