Skadelig kode funnet inne i xploits hostet på GitHub

linux trojan

Måten som ondsinnet kode introduseres på, fortsetter å utvikle seg ved å ta de gamle metodene og forbedre måten ofrene blir lurt på.

Det synes som ideen om trojanske hester er fortsatt ganske nyttig i dag og på så subtile måter at mange av oss kan gå ubemerket hen og nylig forskere fra University of Leiden (Nederland) studerte problemet med å publisere fiktive utnyttelsesprototyper på GitHub.

Ideen om bruke disse for å kunne angripe nysgjerrige brukere som ønsker å teste og lære hvordan noen sårbarheter kan utnyttes med verktøyene som tilbys, gjør denne typen situasjoner ideell for å introdusere ondsinnet kode for å angripe brukere.

Det er rapportert at i studien Totalt 47.313 XNUMX utnyttelseslagre ble analysert, som dekker kjente sårbarheter identifisert fra 2017 til 2021. Utnyttelsesanalyse viste at 4893 10,3 (XNUMX %) av dem inneholder kode som utfører ondsinnede handlinger.

Det er derfor brukere som bestemmer seg for å bruke publiserte utnyttelser, anbefales å undersøke dem først leter etter mistenkelige innlegg og kjører utnyttelser bare på virtuelle maskiner isolert fra hovedsystemet.

Proof of concept (PoC)-utnyttelser for kjente sårbarheter er mye delt i sikkerhetsfellesskapet. De hjelper sikkerhetsanalytikere med å lære av hverandre og legger til rette for sikkerhetsvurderinger og nettverkssamarbeid.

I løpet av de siste årene har det blitt ganske populært å distribuere PoC-er for eksempel gjennom nettsteder og plattformer, og også gjennom offentlige kodelagre som GitHub. Offentlige kodelagre gir imidlertid ingen garanti for at en gitt PoC kommer fra en pålitelig kilde eller til og med at den rett og slett gjør akkurat det den skal gjøre.

I denne artikkelen undersøker vi delte PoC-er på GitHub for kjente sårbarheter oppdaget i 2017–2021. Vi oppdaget at ikke alle PoC-er er pålitelige.

Om problemet to hovedkategorier av ondsinnede utnyttelser er identifisert: Utnyttelser som inneholder ondsinnet kode, for eksempel for å bakdøre systemet, laste ned en trojaner eller koble en maskin til et botnett, og utnyttelser som samler inn og sender sensitiv informasjon om brukeren.

Videre Det ble også identifisert en egen klasse med ufarlige falske bedrifter som ikke utfører ondsinnede handlinger, men de inneholder heller ikke den forventede funksjonaliteten, for eksempel designet for å lure eller advare brukere som kjører ubekreftet kode fra nettverket.

Noen proof of concept er falske (dvs. de tilbyr faktisk ikke PoC-funksjonalitet), eller
selv ondsinnet: for eksempel prøver de å eksfiltrere data fra systemet de kjører på, eller prøver å installere skadelig programvare på det systemet.

For å løse dette problemet har vi foreslått en tilnærming for å oppdage om en PoC er skadelig. Vår tilnærming er basert på å oppdage symptomene som vi har observert i det innsamlede datasettet, for
for eksempel anrop til ondsinnede IP-adresser, kryptert kode eller inkluderte trojaniserte binærfiler.

Ved å bruke denne tilnærmingen har vi oppdaget 4893 ondsinnede depoter av 47313
depoter som er lastet ned og verifisert (det vil si at 10,3 % av de studerte lagrene inneholder skadelig kode). Denne figuren viser en bekymringsfull utbredelse av farlige ondsinnede PoC-er blant utnyttelseskoden distribuert på GitHub.

Ulike kontroller ble brukt for å oppdage ondsinnede utnyttelser:

  • Utnyttelseskoden ble analysert for tilstedeværelsen av kablede offentlige IP-adresser, hvoretter de identifiserte adressene ble ytterligere verifisert mot svartelistede databaser med verter som ble brukt til å kontrollere botnett og distribuere ondsinnede filer.
  • Utnyttelsene levert i kompilert form er sjekket med antivirusprogramvare.
  • Tilstedeværelsen av atypiske heksadesimale dumps eller innsettinger i base64-format ble oppdaget i koden, hvoretter nevnte innsettinger ble dekodet og studert.

Det anbefales også for de brukere som liker å utføre testene på egenhånd, å ta kilder som Exploit-DB i forgrunnen, siden disse prøver å validere effektiviteten og legitimiteten til PoC-er. Siden, tvert imot, den offentlige koden på plattformer som GitHub ikke har utnyttelsesverifiseringsprosessen.

Endelig hvis du er interessert i å vite mer om det, kan du se detaljene i studien i følgende fil, hvorfra du Jeg deler linken din.


Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: AB Internet Networks 2008 SL
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.