Vergiftiging de Bron

Dus hebben we gezien hoe een verscheidenheid aan technieken gebruiken om slechteriken Trojaans paard functionaliteit squeeze in onze systemen. Echter, misschien wel de meest zorgwekkende Trojaans paard vector is het invoegen kwaadaardige code in een software product voordat het is zelfs vrijgegeven. Aanvallers kunnen Trojanize programma's tijdens de ontwikkeling van de softwareleverancier en testprocessen. Stel dat een aanvaller huurt aan als een werknemer bij een grote software-ontwikkeling winkel of vrijwilligers om de code bij te dragen tot een open source software project. Het doel kan van alles zijn, een operating system, een veelgebruikt enterprise resource planning tool, of zelfs een zeer esoterische programma dat wordt gebruikt door banken om hun overdracht van fondsen te beheren zou allemaal sappige doelen. Als een ontwikkelaar of zelfs een tester, kan de aanvaller Plaats een relatief kleine achterdeur van minder dan 100KB code binnenkant van honderden megabytes van legitieme code. Dat is echt een naald in een hooiberg! Alle gebruikers aankoop van het product zou vervolgens ongewild te kopen van een paard van Troje en installeren op hun systemen. De gehele software product zelf wordt het paard van Troje, doet iets nuttigs (dat is waarom je kopen of downloaden), maar maskeren deze achterdeur.

Ken Thompson, merkte medeschepper UNIX-en C-programmeertaal goeroe, gesproken over het belang van de beheersing van de broncode en de mogelijkheid van het planten van backdoors in het in 1984 zijn beroemde paper getiteld "Reflecties over Vertrouwen Trust." In dat klassieke papier, Thompson beschreven wijziging van de broncode van een compiler, zodat het een achterpoortje ingebouwd in alle code die het samenstelt. De voorgenomen aanval was bijzonder verraderlijke, omdat zelfs een gloednieuwe compiler die is samengesteld met een Trojaans versie van de oude compiler zou de achterdeur in te hebben, ook. Deze laan van aanval is al lang een punt van zorg, en is een nog groter potentieel probleem vandaag.

Deze zorg is des te verontrustender dan de Trojaning van software distributie sites die we besproken hebben in het laatste deel. Wanneer een aanvaller een software-distributie site Trojanizes, de ontwikkelaars van de software op zijn minst een schone versie van de software die ze kunnen vergelijken op de list te detecteren. Backing-out problemen is relatief gemakkelijker na ontdekking, als een schone versie van de software kan worden geplaatst op de website voor de distributie. Aan de andere kant, als een aanvaller bedt een paard van Troje tijdens het proces van softwareontwikkeling, kan de verkoper niet eens een schoon exemplaar. Als de aanvallers zijn bijzonder slim, ze zullen een kleine, onopvallende backdoor vervlochten gedurende de normale code, waardoor uitroeiing uiterst moeilijk. De software-ontwikkelaar zou moeten enorme hoeveelheden van de code-scan om de integriteit van een hele product te waarborgen. Hoe groter het software product, des te moeilijker geworden opsporing en uitroeiing. Laten we eens analyseren waarom dit zo is.

Code complexiteit maakt Aanval Gemakkelijker

De meeste moderne software tools zijn enorm in omvang. Opsporen van bugs in de code, laat staan backdoors, is zeer moeilijk en kostbaar. Om Trojanize een software product, een boze medewerker heeft niet eens een hele achterdeur daadwerkelijk in het product te schrijven. In plaats daarvan zou de ontwikkelaar doelbewust kwaadaardige code schrijven die een exploiteerbaar lek bevat, zoals een buffer overflow, dat zou een aanvaller de overname van de machine. Effectief, zoals een doelbewuste fout werkt net als een achterdeur. Als de fout sluipt langs de software testing team, zou de ontwikkelaar de enige die weet over het gat in eerste instantie. Door gebruik te maken die fout, kan de ontwikkelaar controle op alle systemen met behulp van zijn of haar code.

Om een gevoel voor hoe gemakkelijk een dergelijke opzettelijke fout of zelfs een volledige Trojaans paard kan het verleden de ontwikkeling van software kwaliteit piepen processen, laten we eens kijken naar de kwaliteit track record van de informatietechnologie-industrie in de tijd. Kwaliteit van de software problemen hebben geteisterd ons voor decennia. Met de invoering van een hogere dichtheid chips, fiber-optische technologie, en betere harde schijven, hardware blijft om meer betrouwbare loop van de tijd. Software, aan de andere kant, blijven hardnekkig gebrekkig. Watts Humphrey, een goeroe software kwaliteit en onderzoeker aan de Carnegie Mellon University, heeft enquêtes naar het aantal fouten softwareontwikkelaars vaak te maken bij het schrijven van code. Diverse analyses is gebleken dat, gemiddeld, een typische ontwikkelaar introduceert per ongeluk tussen de 100 en 150 defecten per 1.000 regels code. Deze kwesties zijn geheel per ongeluk, maar een opzettelijke fout zou kunnen worden in zowel sloop.

Hoewel veel van deze fouten zijn eenvoudige syntactische problemen gemakkelijk ontdekt door een compiler, een groot deel van de resterende defecten vaak leiden tot gapende gaten in de beveiliging. In feite, in wezen een beveiligingsprobleem is eigenlijk gewoon de zeer gecontroleerde exploitatie van een bug van een aanvaller specifieke doel te bereiken. Als de aanvaller kan het programma niet op een manier die de voordelen van de aanvaller (door te crashen van het systeem, de toegang opleveren, of weergeven van vertrouwelijke informatie), de aanvaller wint. Het schatten van een zeer conservatief, als slechts een op de 10 van de defecten in de software is de veiligheid implicaties, die vertrekt tussen 10 en 15 beveiliging defecten per 1.000 regels code. Deze nummers gewoon niet erg bemoedigend.

Een complexe besturingssysteem zoals Microsoft Windows XP heeft ongeveer 45 miljoen regels code, en dit gigantische aantal is groeiende als nieuwe functies en patches worden vrijgegeven. Andere besturingssystemen en toepassingen hebben enorme bedragen van de code. Doen de vermenigvuldiging voor XP, kunnen er ongeveer 450.000 beveiligingsproblemen in Windows XP alleen. Zelfs als onze back-of-the-envelop berekening is te hoog met een factor van 100, die nog zou kunnen betekenen 4500 veiligheidsgaten. Ouch! Inderdaad, dezelfde dag dat Windows XP werd gelanceerd in oktober 2001, Microsoft maar liefst 18 megabyte van patches vrijgegeven voor.

Begrijp me niet verkeerd, ik hou van Windows XP. Het is veel betrouwbaarder en gemakkelijker te gebruiken dan de vorige versies van Windows. Het is zeker een stap in de juiste richting van deze perspectieven. Echter, dit is slechts een illustratie van het probleem de veiligheid die inherent zijn aan grote software projecten. Het is niet alleen een kwestie ofwel Microsoft; de gehele software-industrie is de invoering van grotere, meer complexe, ultra-feature-rijk (en soms beladen feature-) programma's met tonnen veiligheidsgaten. Tijdens de software-industrie, zien we heel vruchtbare bodem voor een aanvaller een subtiele Trojaans paard plant.

Test? Wat Test?

Ondanks deze beveiliging bugs, sommige mensen denken nog steeds dat het testproces ontwikkelaars in dienst van ons zal redden en Trojaanse paarden vinden, voordat de besmette producten in de schappen lag. Ik gebruikte om mijn bezorgdheid met dit argument en gerust te stellen. Het heeft mij geholpen beter slapen 's nachts. Maar er is een andere dimensie hier om in gedachten te houden te vernietigen uw goede nachtrust: paaseieren. Volgens The Easter Egg Archive ™, een paasei is gedefinieerd als:

Elke leuke nieuwtje dat makers verstopte zich in hun creaties. Ze kunnen in computer software, films, muziek, kunst, boeken, of zelfs je horloge. Er zijn duizenden van hen, en ze kunnen zeer onderhoudend zijn, als je weet waar te kijken.

Easter eggs zijn die onverwachte Goofy weinig "features" weg squirreled in uw software (of andere producten) die opduiken onder zeer bijzondere omstandigheden. Bijvoorbeeld, als u het programma uitvoert terwijl u de E, F en S-toetsen, misschien krijg je een beeld van dorky ontwikkelaar van het programma te zien. The Easter Egg Archive stelt een meester lijst van deze kleine pareltjes op www.eeggs.com, Met meer dan 2775 software paaseieren op plaat als van dit schrijven.

Wat doen paaseieren te maken hebben met Trojaanse paarden in de software? Heel veel, in feite. Een paasei is echt een vorm van een Trojaans paard, zij het een (meestal) een goedaardige. Echter, als software-ontwikkelaars kunnen een goedaardige stiekem paaseieren langs de software testen en kwaliteitsborging teams, is er geen twijfel in mijn hoofd dat ze op dezelfde manier zou een Trojaans paard of een opzettelijke buffer overflow pass ook. In feite, kan de aanvaller zelfs zetten de achterdeur binnen een paasei ingebed in het hoofdprogramma. Als de testen en kwaliteitsborging teams niet opmerken de Easter Egg of zelfs merken, maar laten we het door, ze waarschijnlijk niet zullen controleren voor dergelijke verborgen functionaliteit. Voor mij is het bestaan van de paaseieren blijkt heel duidelijk dat een kwaadwillende ontwikkelaar of tester kan vervelende verborgen functionaliteit zetten binnen van product code en krijgen via release van een product zonder te worden opgemerkt.

Om een gevoel te krijgen voor een paasei, laten we eens kijken naar een ingebed in een populair product, Microsoft Excel spreadsheet programma. Excel is heel beroemd om zijn Easter eggs. Een eerdere versie van het programma, Excel 97, bevatte ook een flight simulator spel. Een meer recente versie, Excel 2000, bevat een auto-rij-spel genaamd Dev Hunter.

Voor dit paasei om te werken, moet u beschikken over Excel 2000 (pre Service Release 1), Internet Explorer en DirectX geïnstalleerd op uw computer. U activeert de paas-ei en het spel spelen, moet u het volgende doen:

Start Excel 2000.
Onder het menu Bestand, kies Opslaan als webpagina.
Op de Save-interface, selecteert u Publiceren en klik vervolgens op het vak Interactiviteit toevoegen.
Klik op Publiceren om de daaruit voortvloeiende HTM pagina op uw harde schijf op te slaan.
Open vervolgens de HTM pagina die u zojuist hebt gemaakt met Internet Explorer. De lege spreadsheet zal verschijnen in het midden van uw Internet Explorer browser venster.
Hier is het moeilijke gedeelte. Scroll naar beneden tot 2000 rij, en schakel over naar kolom WC.
Kies nu het geheel van de rij 2000 door te klikken op het nummer 2000 aan de linkerkant van de rij.
Druk op de Tab-toets te maken WC de actieve kolom. Deze kolom is wit, terwijl de andere kolommen in de rij zal verduisterd worden.
Houd Shift + Ctrl + Alt en, tegelijkertijd, klikt u op de Microsoft Office-logo in de linkerbovenhoek van de spreadsheet.
In een seconde of twee, zal het spel draaien.
Gebruik de pijltjestoetsen om te rijden en sturen en de spatiebalk om te vuren. De O-toets druppels olie slicks te verwarren de andere auto's. Wanneer het donker wordt, kunt u gebruik maken van de H-toets om op uw koplampen.

Als het spel niet ingeroepen op uw systeem, is het waarschijnlijk omdat je Service Release 1 of een latere versie van Microsoft Excel is geïnstalleerd op uw machine, die niet onder de Easter Egg. Je zou kunnen jagen een eerdere versie van Microsoft Excel, of gewoon mijn woord te geloven.

Nu, let wel, deze "feature" is in een spreadsheet, een kantoor productiviteit programma. Afhankelijk van uw mentaliteit, is het misschien eigenzinnig en leuk. Maar hoe werkt zo'n ding voorbij de kwaliteit van de software-proces (met daarin onder meer code reviews) en test team? Misschien is de kwaliteitszorg en testen personeel merkte het niet. Of, misschien wel de kwaliteitsborging mensen en testers waren onder een hoedje met de ontwikkelaars om te zien dat het spel maar ik heb opgenomen in de productie vrijkomen. Hoe dan ook, ik ben bezig met het vooruitzicht van een Trojaans paard te hebben geplaatst in een vergelijkbare manier op andere leveranciers.

Nogmaals, ik ben niet de pik op alleen Microsoft hier. In feite, heeft Microsoft beter geworden de afgelopen paar jaar met betrekking tot deze bezorgdheid. Nieuwe service packs of hot fixes vaak en snel squash alle paaseieren opgenomen in eerdere versies. Microsoft's Trusted Computing-initiatief, hoewel vaak uitgelachen, begint wat fruit als minder en minder beveiligingslekken en paaseieren voorzien lijken te zijn binnenkort op de markt Microsoft-programma's. Maar ik zeg dit met grote aarzeling, als een ander groot gapend ei meer konden worden ontdekt elke dag. Toch onderstrepen dat dit niet is een Microsoft-only probleem, vele andere software-ontwikkeling winkels hebben paaseieren opgenomen in hun producten, met inbegrip van Apple Computer, Norton, Adobe, Quark, de open source Mozilla webbrowser en de Opera browser. De lijst gaat verder en verder, en is nader uitgewerkt voor de wereld te zien op www.eeggs.com.

De overgang naar International Development

Een laatste punt van zorg ten aanzien van kwaadaardige software ontwikkelaars en Trojaanse paarden wordt in verband gebracht met de code wordt ontwikkeld over de hele wereld. Software fabrikanten steeds meer rekenen op zeer verspreide teams over de hele planeet om code te maken. En waarom niet? Vanuit een economisch perspectief, een groot aantal landen hebben burgers met een top-notch software ontwikkeling vaardigheden en veel lagere arbeidskosten tarieven. Hoewel de economische zin, het paard van Troje beveiligingsprobleem weefgetouwen veel groter met dit type van software ontwikkeling.

Stel je koopt of een stukje software van leverancier X. Deze verkoper downloaden, op zijn beurt, om contracten met leveranciers Y en Z te ontwikkelen bepaalde delen van de code. Verkoper Z uitbesteedt verschillende subcomponenten van het werk in drie verschillende landen over de hele wereld. Tegen de tijd dat het product zit op uw harde schijf, duizenden handen verspreid over de hele planeet zou betrokken zijn geweest bij de ontwikkeling ervan. Sommige van die handen zouden kunnen hebben plantte een vervelende backdoor. Erger nog, dezelfde analyse geldt voor de back-end financiële systemen die worden gebruikt door uw bank en de database-programma's huisvesten van uw medisch dossier. Informatiebeveiliging wetten en productaansprakelijkheid regels verschillen aanzienlijk van land tot land, met vele naties niet hebben van zeer robuuste regelgeving op alle.

Deze bezorgdheid is niet geassocieerd met de moraal van de ontwikkelaars in verschillende landen. In plaats daarvan, de zorg heeft betrekking op het niveau van kwaliteitscontrole dat kan worden toegepast met een beperkte opdracht en regelgeving ondersteunende structuren. Ook de effecten die dezelfde economische ontwikkeling aan het rijden bent naar landen met minder dure ontwikkeling van personeel kan het probleem verergeren. Een aanvaller kan een ontwikkelaar het maken van $ 100 per week of maand omkoping in het zetten van een achterdeur in de code voor heel weinig geld. "Hier is 10 jaar salaris ... please change twee lijnen van de code voor mij", wellicht het enige dat het zou duren. We willen niet om hier te zijn xenofobe en voor de internationale ontwikkeling van software is een realiteit met een aanzienlijke voordelen in de huidige informatietechnologie bedrijf. We moeten echter ook erkennen dat het verhoogt wel de veiligheidsrisico's van een Trojaans paard of opzettelijke software gebreken.

Afweer tegen het vergiftigen van de Bron

Hoe kan je jezelf verdedigen van een Trojaans paard geplant door een medewerker van uw software ontwikkeling huis? Dit is een bijzonder moeilijke vraag, zoals u hebt weinig controle over de ontwikkeling van de overgrote meerderheid van de software op uw systemen. Toch zijn er dingen die we allemaal kunnen doen als een gemeenschap om deze situatie te verbeteren.

Ten eerste kunt u uw commerciële verkopers aan te moedigen om robuuste integriteit controles en testen kregen voor hun producten. Als ze niet, sloegen hen tot en dreigen met andere producten gebruiken. Ik bedoel niet om hen te slaan letterlijk. Ik wil niet aanzetten tot geweld, voor de goedheid bestwil. Door 'sloeg ze, "ik bedoel geef ze een harde tijd. Daag hen uit. Yell naar hen. Laat je de ontwikkeling van software leveranciers weten hoe belangrijk veilige code is aan uw activiteiten. Als de markt begint meer veilige code veeleisende, zullen we geleidelijk aan tippen start in die richting. Bovendien, als u veel gebruik van open source software, ondersteuning, dat de gemeenschap met uw tijd en moeite in het begrijpen van software fouten. Als u de vaardigheden, te helpen door de herziening van open source-code om te controleren of het veilig is.

Vervolgens, als je te kopen of te downloaden van nieuwe software, test het eerst of het geen voor de hand liggende mogelijkheid Trojaans paard bevat. Met een grondige software te testen en evaluatie in eigen huis, kun je gewoon een aantal Trojaanse paarden te vinden in uw producten, voordat iemand anders deze aankondigingen. Communiceer deze informatie naar de verkoper te helpen bij het oplossen van de kwestie.

Als uw organisatie ontwikkelt een code in huis, zorg ervoor dat uw software testing team is zich bewust van de problemen van de paaseieren, Trojaanse paarden, en opzettelijke fouten. Helaas zijn software testers vaak gezien als de zeer laagste niveau van belang in de ontwikkeling van software hiërarchie, krijgt meestal weinig respect, erkenning, of betalen. Toch, hun belang aan de veiligheid van onze producten staat voorop. Train deze mensen, zodat ze snel kunnen code die geen juiste look en rapporteren aan een passend beheer personeel ter plaatse. Beloon uw testers wanneer zij ernstige veiligheidsproblemen te vinden voordat u het schip software. Wees voorzichtig, dat wel. U wilt niet naar testers werken met ontwikkelaars om het spel van het systeem en planten bugs, zodat ze meer geld kan verdienen. Dat is alsof je een loterij waar mensen kunnen hun eigen print winnende loten. Zorgvuldig toezicht houden op eventuele bug beloningsprogramma's die u maakt voor dergelijke drogredenen.

Bovendien zorgen ervoor dat uw testers en ontwikkelaars kunnen melden zonder dat de veiligheid heeft betrekking op represailles van wanhopige managers probeert een software strikte deadline te halen. Afhankelijk van de grootte van uw organisatie en haar cultuur, zou je zelfs aan een anonieme tipline in te voeren voor uw ontwikkelaars voor deze problemen melden. Door deze broodnodige extra aandacht aan uw software testers, die je kan helpen bij problemen met squelch Trojaanse paarden alsmede verbetering van de algehele kwaliteit van uw producten.

Om deze denkrichting infuus in de hele cultuur van uw software development teams, overwegen transformeren uw test organisatie in een volwaardige kwaliteitszorg functie. De kwaliteitsborging organisatie moet worden gecharterd met software beveiliging verantwoordelijkheid als een facet van de kwaliteit. Bouw uw proces van kwaliteitszorg in de gehele cyclus van software ontwikkeling, met inbegrip van ontwerp, code reviews en testen. Je moet ook opleggen zorgvuldige controles op uw broncode, die ontwikkelaars in staat om te verifiëren voordat werken op elk modules. Alle wijzigingen worden bijgehouden en beoordeeld door een andere ontwikkelaar. Alleen met een grondige kwaliteitscontrole processen en source code control kunnen we de situatie als gevolg van onbetrouwbare bron code.

een artikel afkomstig van Greg McKlein