image

Onderzoekers willen malware met diversiteit bestrijden

woensdag 14 mei 2014, 16:19 door Redactie, 12 reacties

Door de natuur geïnspireerde onderzoekers willen malware bestrijden door meer diversiteit in het computerlandschap te creëren. Volgens de onderzoekers zorgen de huidige monoculturen ervoor dat aanvallers de omgeving van hun slachtoffers kunnen nabouwen om hun aanvallen te perfectioneren.

Een aanval werkt daarna ook tegen veel andere systemen, omdat veel computers en smartphones hetzelfde besturingssysteem draaien. Onderzoekers van de Universiteit van Californië hebben naar eigen zeggen naar de natuur gekeken om met een oplossing voor deze problematiek te komen.

De oplossing die de onderzoekers bedachten is om elk programma uniek te maken, aangezien dat ook tegen virussen in de natuur werkt. Door de pest stierven bijvoorbeeld veel mensen, maar niet iedereen, omdat mensen van elkaar verschillen. "Net als in de natuur is diversiteit een kracht", zegt informaticaprofessor Michael Franz.

Uniek

De onderzoekers ontwikkelden een mechanisme dat van elk programma voor iedere computergebruiker een unieke versie kan creëren. Dit zal geen einde aan alle infecties maken, maar voorkomt wel grootschalige infecties en de bijbehorende schade. Daarnaast zullen de kosten voor het uitvoeren van aanvallen toenemen en wordt het lastig om één specifiek persoon of individu aan te vallen. De kleine verschillen worden in de cloud aan de programmatuur toegevoegd.

Gebruikers downloaden de software via een app store, die steeds een nieuwe versie aanbiedt. De versies verschillen onderling, maar beschikken wel over exact dezelfde functionaliteit. Inmiddels zou er een volledig werkend prototype zijn ontwikkeld dat door een aantal instellingen wordt gebruikt. Uit de voorlopige resultaten blijkt dat de kosten van deze aanpak verrassend laag zijn. "Er zijn kosten, maar die zijn zo laag dat mensen dit zeker willen gebruiken", stelt Franz.

Reacties (12)
14-05-2014, 16:31 door Anoniem
Ik lees vooral "fingerprinting"

Of is privacy ondergeschikt aan security?
14-05-2014, 16:58 door Profeet - Bijgewerkt: 14-05-2014, 16:58
Ik vraag me wel af of dit geen nachtmerrie wordt voor de beheerders. Hebben al die verschillende versies dan ook hun eigen problemen? Die bij geen enkele andere gebruiker gerproduceerd kunnen worden? Dat wordt nog lachen dan... :).

Ik heb zelf geen ervaring met NVP (N version Programming) applicaties of systemen. Maar het klinkt mij als 2 apparte implementaties van dezelfde functionaliteit die door 2 (of X) verschillende teams wordt onderhouden. Hoe gaat dit met miljoenen versies? Is er iemand die nog kan achterhalen wat precies de verschilen en overeenkomsten zijn tussen deze versies? Of wordt het blind trail en error op miljoenen variaties?

Een snelle google leerde mij ook: http://www.hillside.net/plop/2009/papers/Process/N-Version%20Programming.pdf
The assumption is that when a latent fault activates in one version then the other versions of the system that do not contain the same fault. Research by Knight and Leveson [KL86][KL90] has shown that the assumption of independence between the faults produced by the different design teams does not hold.

Het schijnt dat verschillende programeurs dezelfde manieren en technieken toepassen ;)
14-05-2014, 17:37 door mcb
In our approach, on the other hand, subtly different versions of the same software are created automatically “in the cloud,” in a matter that is invisible to both the software developers and the end users. The magic of creating the different versions happens inside of the app store from which users download the software. When software is downloaded from our version of the app store, different users automatically get different, but functionally identical, versions.
Mag dit wel? In vele EULA's staat dat software modificatie en/of reverse engineering verboden is.

En als de software in een appstore wordt gewijzigd, hoe weet je dan of er niet mee is geknoeid? (anders dan de door hun bedachte methode).
Je kan immers nooit meer de hash van de download controleren.

En hoe zit het met de support van de ontwikkelaar?
Je werkt immers met een niet-originele versie.
14-05-2014, 23:04 door Binsbergen
Uiteindelijk zullen verschillende versies dezelfde code uitvoeren. Deze code blijft dan nog steeds de Target voor malware. Flauwekulartikel als je het mij vraagt.
15-05-2014, 08:51 door Anoniem
Door Anoniem: Ik lees vooral "fingerprinting"

Of is privacy ondergeschikt aan security?

Dat was het al vanaf het moment dat de eerste vinger werd gegeven...
15-05-2014, 09:32 door Anoniem
Dit is niet echt diversiteit die zoden aan de dijk zet, maar wel een hoop gedoe gaat opleveren. Patches werken niet meer, bijvoorbeeld. Debug dumps (zoals wel stilletjes teruggestuurd bij crashes) blijken onnavolgbaar geworden. Dat soort werk.

De grap is dat het best werkt voor virussen, en "polymorphism" bestaat dan ook al tientallen jaren in dat wereldje, met af en toe iemand die het wiel opnieuw uitvindt. Het werkt daar wel omdat ze zich verdedigen tegen detectie, waar een signatuur subtiel wijzigen ineens betekent dat'ie niet meer in de lange "zwarte lijst van slechtheid" in je virusscanner voorkomt.

Maar voor programmas? Die moeten zich verdedigen tegen misbruik van fouten in de eigen code, je weet wel, buffer overruns, injecties, remote code execution, of zoiets als heartbleed. Als je de code subtiel veranderd helpt dat niet zo erg. Wellicht dat ik heel erg achterloop en dat op mobiele platformen de virussen zich ondertussen ook als scanner gedragen om slachtofferprogrammas te vinden, en wellicht dat het dan helpt. Maar anderszins? Niet zo erg veel, nee.


Wat ik wel onder diversiteit versta is als niet 95%+ een enkel (notoir brak) en hetzelfde besturingssysteem op dezelfde architectuur gebruiken. Je zorgt dat er minstens twee, liefst wat meer besturingssystemen elk een redelijk vergelijkbaar marktaandeel hebben (elk minstens 1/(N+1)de deel, zeg), en dat dan weer elk op elk van liefst twee, liefst een paar meer verschillende architecturen met compleet andere instructiesets. Als je je programmas netjes opzet hoeft ontwikkelen voor zo'n verschillende bomenbos geen probleem te zijn, sterker, je krijgt er robuustere programmas door.

1GYYopciYLMZB1mUTgZta7WpgMa78Smwt3
15-05-2014, 10:06 door Anoniem
Deze technieken worden al tijden gebruikt door malware om op fingerprint gebaseerde anti-malware pakketten te foppen. De 'truuk' is dat het initiële pakket dat gedownload wordt hetzelfde kan zijn (de hash is dus hetzelfde), maar bij het daadwerkelijk installeren zijn er diverse alternatieven voor dezelfde code waar random tussen gekozen wordt. Omdat deze code uiteindelijk ook op assembler niveau verschilt maakt dit het lastig voor malware die ook op basis van fingerprinting werkt.

Dit zal echter maar tijdelijk helpen omdat meer en meer malware gebruik gaat maken van ROP aanvallen waartegen dit soort maatregelen ook niks gaat helpen. Je zal dan echt (hardwarematige) flow control moeten gaan inbouwen.
15-05-2014, 10:23 door Anoniem
Door Binsbergen: Uiteindelijk zullen verschillende versies dezelfde code uitvoeren. Deze code blijft dan nog steeds de Target voor malware. Flauwekulartikel als je het mij vraagt.
Op het niveau van de programmalogica zoals een programeur die in een hogere programmeertaal noteert zal niets aangepast worden door zo'n systeem. Maar op machinetaal-niveau verandert er kennelijk wel van alles. Misbruik van logicafouten in de programmatuur zal dus niet ondervangen kunnen worden, maar als malware die de werking van een app wil beïnvloeden niet meer kan herkennen waar die zichzelf moet injecteren in de machinecode omdat die op elke smartphone anders is, of als het effect ervan onvoorspelbaar wordt voor de malwareschrijver, dan kan dit wel degelijk een leuke bescherming vormen.

Bekijk het zo: polymorfe virussen maken virusscanners het leven zuur, maar als je polymorfe applicaties maakt dan maken die op hun beurt virussen het leven zuur.

Dit kan niet elke vorm van misbruik ondervangen, maar het kan potentieel wel een heel niveau waarop zwakheden kunnen worden misbruikt onaantrekkelijk te maken voor aanvallers. Dat lijkt me winst, als je alle deuren dicht wil zetten moet je tenslotte elke deur die open staat afzonderlijk sluiten.

Het idee dat diversiteit robuuster is is op zich niet nieuw. Op een ander niveau betekent het dat je beter kan standaardiseren op communicatieprotocollen, bericht- en bestandsformaten dan op specifieke software. Dat komt helaas lang niet altijd goed van de grond. Er zijn commerciële leveranciers die op supplier-lockin aansturen door bewust niet volledig compatibel te zijn met anderen; er zijn ontwikkelaars die alleen de inefficiëntie zien van het opnieuw ontwikkelen van iets dat al bestaat maar niet herkennen dat diversiteit in implementaties ook belangrijke voordelen biedt; en er zullen nog wel meer oorzaken aan te wijzen zijn. De aanpak die in dit artikel beschreven wordt probeert een deel van die diversiteit op een laagdrempelige manier mogelijk te maken. Ik weet niet of het succesvol zal zijn, maar de poging is zeker interessant.
15-05-2014, 10:49 door Anoniem
Het idee is wel goed. Door standaardisatie kunnen infecties op grote schaal voorkomen worden.

Ook al blijft de code van de software hetzelfde, op zijn hoogst andere method en class benamingen met polymorfism, met zoiets simpels als het Windows registry dat afwijkt werkt een groot deel van de standaard malware al niet meer. Met zoiets simpels als een systeem DLL met een andere naam kan ook veel gewonnen worden. Maar het blijft een kat en muis spel want die bestanden moeten dan weer ergens genoemd worden om ze uberhaupt nog door het systeem te laten vinden, en dat kan een malware weer opzoeken.

Maar als ik mij niet vergis zijn de virussen zoals die vroeger een executable infecteerde (door zichzelf te repliceren naar het einde van een bestand en te refereren in het begin van de executable) op hun retour.
15-05-2014, 12:18 door Anoniem
Correctie van mezelf hierboven
"Door standaardisatie kunnen infecties op grote schaal voorkomen worden."
Moet zijn:
"Door minder standaardisatie kunnen infecties op grote schaal voorkomen worden.
15-05-2014, 22:06 door Anoniem
Door Anoniem:
Door Binsbergen: Uiteindelijk zullen verschillende versies dezelfde code uitvoeren. Deze code blijft dan nog steeds de Target voor malware. Flauwekulartikel als je het mij vraagt.
Op het niveau van de programmalogica zoals een programeur die in een hogere programmeertaal noteert zal niets aangepast worden door zo'n systeem. Maar op machinetaal-niveau verandert er kennelijk wel van alles ...

Als er VS13 gebruikt wordt niet, dan is IL de tussenschakel. Tenzij er 100% assembly gebruikt wordt, maar dit is niet geschikt voor de wat grote en gecompliceerdere apps.
15-05-2014, 23:50 door Eric-Jan H te D
We hadden al zelf modificerende malware. Zelf modificerende gebruikersprogrammatuur lijkt me een logisch gevolg.

Shooting at a moving target.

Zelf denk ik dat veilig programmeren er niet eenvoudiger op wordt. De codebase wordt groter. En meer coderegels heeft als logisch gevolg meer fouten. En grotere complexiteit idem dito.

Daarnaast is de kans zeer wel aanwezig dat het werk van AV-programmatuur nagenoeg onmogelijk wordt, want het schimmige gedrag van malware kopiëren naar reguliere programmatuur zorgt ongetwijfeld voor een stortvloed aan false positives.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.