Hur ofta kan ett program infektera ett annat? Låt oss räkna vägarna

LAS VEGAS – Det finns en anledning till att vi hänvisar till datavirus och enheter eller processer som “infekterade”. Tillbaka när virus var nya och program sammanställdes till COM-filer var det enkelt att infektera ett program. Viruset bifogade sin egen kod i slutet av målet och skrev över den allra första instruktionen med ett hopp till den koden. Den senaste instruktionen från viruset startade genomförandet av programmets vanliga funktioner – en mycket tidig form av processinjektion.

Black Hat Bug Art

Spola framåt till den moderna världen, och möjligheterna är mer komplexa och många. Vid Black Hat-konferensen här presenterade ett par forskare från SafeBreach, som avtalar för att bedöma och mildra säkerhetsrisker, en uttömmande undersökning av alla sätt som ett program kan injicera kod i ett annat. Deras session är inte förrän på torsdag, men vi kom ikapp med dem före informationssamtalet.

Medgrundare och CTO Itzik Kotler och VP för säkerhetsforskning Amit Klein gick ut med sitt team för att samla in, samla och visa alla möjliga sätt som en kodare för skadlig kod kan äventyra andra processer. Ursprungligen tänkte de att de skulle hitta sex eller sju, men de avvecklades med 20 variationer, kokade ner till ett dussin. I en nick till populärkulturen har presentationen undertexten “Gotta Catch Them All.”

Processinjektion för alla

Jag nämnde min tanke om gamla COM-programvirus till Kotler, och han var överens om att det var ett mycket tidigt exempel på processinjektion. “Det är viktigt att komma ihåg att COM-filer och DOS inte hade någon säkerhet”, sa han. “Idag måste Microsoft erbjuda säkerhet för alla.”

Kotler och Klein undersökte först alla tekniker som använts för att injicera kod i Windows-program och slängde dem som inte längre var livskraftiga och fann att de fortfarande hade mycket.

Jag kommer inte att gå i detalj om de faktiska teknikerna, förutom att nämna att tillsammans med denna samling skapade Kotler och Klein också en ny som de kallade Stack Bombi. Vid sin Black Hat-presentation släpper de ett verktyg som heter Pinjectra som implementerar var och en av de samlade teknikerna.

Vem behöver det?

Pinjectra är ett open source-verktyg, fritt tillgängligt för alla. Tekniskt kunniga konsumenter kan använda den för att testa förmågan hos en säkerhetssvit. Företagssäkerhetsteam kan göra detsamma med sitt slutpunktsskydd. Och naturligtvis kan kodare för skadlig kod studera koden för att få några nya idéer.

Jag frågade Kotler varför han hade lagt verktyget i skurkarna. “Jag har gjort offensiv säkerhet i 15 år. Jag tror att när vi inte publicerar saker betyder det inte att de dåliga killarna inte har det”, svarade han. “Det betyder bara att vi som samhälle inte tar itu med det. Att ignorera verkligheten fixar inte saker.”

Han noterade att verktyget Pinjectra inte har någon skadlig nyttolast. Om din säkerhet inte skyddar mot en viss attack ser du ett popup-meddelande som säger “Hello World”, inget mer. “Ja, det kan folk ändra på”, erkände han. “Men de kan ändra stort sett vad som helst till ondska.”

Varför fixade inte Microsoft det?

Jag frågade varför Microsoft inte bara kunde patcha operativsystemet för att förhindra dessa processinjektionsattacker. “Naturligtvis kan jag inte tala för dem, men dessa tekniker kan användas för legitima ändamål,” sa han. “De kan behövas för att stödja äldre applikationer. Vissa kan användas för felsökning. Ingenting i processinjektionen är i sig dåligt.”

Varför kan din säkerhetsprodukt göra vad Microsoft inte kan? “Du har ett val i din säkerhetsprodukt”, sa Kotler. “Du förstår dess begränsningar. Kanske vet du att det bryter med äldre program, så du förbjuder äldre program. Kanske är tekniken patenterad och inte tillgänglig för Microsoft.”

Det är uppenbart att processinjektion är kvar för att vi ska stanna, eftersom det hade både bra och dåliga användningsområden. Men var inte orolig. Om du har skyddat dina enheter med en kraftfull säkerhetssvit har du flera lager av skydd som ska hålla dig säker. Dessa inkluderar att förhindra nedladdning av den skadliga koden, känna igen och ta bort den efter nedladdning, upptäcka och förhindra dess skadliga beteende, skydda offrets process mot manipulation och mer. Ja, det finns många öppningar för attacker, men eftersom de är kända är försvar möjligt.

Relaterade Artiklar

Back to top button