Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

NSA plaatst sysadmin- en beveiligingstools op GitHub

Door , 84 reacties

De Amerikaanse NSA heeft een verzameling tools online gezet die naar eigen zeggen door de organisatie zelf zijn ontwikkeld. Dit doet de NSA in het kader van het zogenaamde Technology Transfer Program, waarmee onder meer commerciŽle ontwikkeling mogelijk moet zijn.

NSADoor het publiceren van de broncode hoopt de NSA dat de software wordt gebruikt en aangepast, waardoor weer voordelen moeten ontstaan voor de Amerikaanse overheid. De tools zijn onderverdeeld in software van de NSA en van de Information Assurance-afdeling. De GitHub-pagina van de NSA noemt momenteel ongeveer dertig tools voor verschillende toepassingen.

Zo is er bijvoorbeeld de zogenaamde GoSecure-software te vinden, waarmee het mogelijk is een vpn-server op te zetten op een Raspberry Pi 3. Die vervult de rol van de client, terwijl de server zelf kan draaien op een ander systeem. Daarnaast zijn er tools voor het in de gaten houden van digitale Windows-certificaten, een framework voor software defined radio en voor het analyseren van code.

De NSA heeft al eerder bijgedragen aan open software, bijvoorbeeld door de ontwikkeling van SELinux en Accumulo en NiFi voor Apache. SELinux maakt bijvoorbeeld onderdeel uit van verschillende Linux-distributies en laat gebruikers toegangsmachtigingen instellen aan de hand van mandatory access controls.

Sander van Voorst

Nieuwsredacteur

Reacties (84)

Wijzig sortering
Misschien ook wel handig om even te linken naar de betreffende repo's: NSA en Information Assurance by NSA.
Als:
- broncode volledig in te zien is, Ťn
- de ontwikkelaar bepaalde delen van deze broncode niet begrijpt (dus ondanks dat het gewoon in te zien is), die code bevatten die mogelijk
- schade, direct dan wel indirect, kunnen toebrengen aan het systeem waarop deze broncode gedraaid wordt,

Dan is het geen kwestie van gebrekkige transparantie vanuit de NSA, maar onkunde/gebrek aan kennis van de ontwikkelaar.

Als:
- De broncode niet (volledig) in te zien is door derden,
dan is er geen sprake van open source.

Het bericht geeft aan dat er sprake is van open source; de broncode is dus volledig in te zien. Beweren dat de NSA dan alsnog bepaalde zaken heeft 'ingebouwd' die ongemerkt schade kunnen toebrengen (of dat zich nu uit in het versturen van informatie uit het systeem waarop de software gedraaid wordt naar een externe partij, of het onbruikbraak maken van het systeem zelf, doet er niet toe; schade is schade), is hysterisch (ondanks het verleden van de NSA).

[Reactie gewijzigd door 8x4 op 19 juni 2017 13:52]

Ik verwijs hier graag naar de wedstrijd voor ogenschijnlijk onschuldige code die dat toch niet is: http://www.underhanded-c.org (erg leuk en interessant)

Alle grappen daargelaten is deze software van de NSA waarschijnlijk uiteindelijk wel (mogelijk) veilig te gebruiken omdat er zo veel ogen naar zullen kijken dat alle eventuele problemen zouden worden opgepikt. Dat is het mooie van open source.

[Reactie gewijzigd door Jeroen op 20 juni 2017 20:31]

Ga daar nou niet vanuit. Opensource is niet de heilige graal in infosec. Genoeg FOSS software, zelfs in hele grote projecten, waar pas na jaren een bijzonder gevaarlijke bug wordt gevonden. Shellshock, poodle, heartbleed, noem het maar op.

Dus dat een eventuele backdoor "zo gevonden is", ALS die in deze tools zouden zitten, is gewoon absoluut niet waar.
Opensource software is op geen enkele wijze per definitie veiliger dan software met gesloten bron, beiden kunnen van zeer onveilig tot zeer veilig variŽren. De open bron is voornamelijk boeiend om het te kunnen delen of verder op te ontwikkelen, voor de veiligheid stelt het lang niet altijd iets voor.
Een bekend idee in de infosec wereld is dat de bron totaal geen vereiste is bij het zoeken van lekken, het is eerder een soort bonus die misschien van pas komt: maar zelfs dan kijkt men er liever pas nŠ het eerste onderzoek naar; en dus eerst naar de gecompileerde software.

[Reactie gewijzigd door WhatsappHack op 19 juni 2017 15:15]

Ga daar nou niet vanuit. Opensource is niet de heilige graal in infosec. Genoeg FOSS software, zelfs in hele grote projecten, waar pas na jaren een bijzonder gevaarlijke bug wordt gevonden. Shellshock, poodle, heartbleed, noem het maar op.
Open source* is inderdaad niet het eindpunt voor veiligheid, maar het begin. Ik denk dat de stelling beter omgedraaid werkt: "Closed source* is een ramp voor infosec."
Zonder open source is het in ieder geval niet veilig. Althans, zo zal je het moeten behandelen zonder bewijs voor het tegendeel.
Een bekend idee in de infosec wereld is dat de bron totaal geen vereiste is bij het zoeken van lekken, het is eerder een soort bonus die misschien van pas komt: maar zelfs dan kijkt men er liever pas nŠ het eerste onderzoek naar; en dus eerst naar de gecompileerde software.
Dat klopt wel zo'n beetje maar het is niet het hele verhaal. Ik ga er van uit dat jij dit eigenlijk wel weet, maar je post kan gelezen worden als dat open source geen enkele rol speelt als het op veiligheid aankomt. Een positie die ik helaas vaker tegen kom bij mensen die niet zo diep in de materie zitten. Vandaar dat ik hier even inhaak.

Twee punten.
Ten eerste kan het zoeken naar individuele lekken inderdaad ook zonder de source, er is zelfs prachtige software om daar bij te helpen, maar het zoeken naar fouten is maar een klein deel van beveiliging.

Als beveiliger ben ik nauwelijks geÔnteresseerd in het absoluut aantal lekken en gaten (het is toch nooit nul), maar meer in de algehele structuur van het programma en de werkwijze van de programmeur.
Een goed opgezet programma met een paar kleine foutjes is eenvoudig te verbeteren. Een slecht opgezet programma kun je niet redden door gaten dicht te blijven stoppen.

Simpel voorbeeld, vroeger deden bouwden we SQL-queries door zelf strings aan elkaar te plakken, tegenwoordig gebruiken we parameterized queries. Als ik tegenwoordig iemand stringetjes zie plakken dan beschouw ik die code als minder veilig, zelfs als ik geen concreet gat kan vinden. Als de programmeur moet zorgen dat alle randgevallen zijn gequoot en/of geŽscapet weet ik dat het nooit goed komt.


Ten tweede is broncode van groot belang bij het verbeteren van de veiligheid. Alle software bevat gaten en vroeg of laat kom je die tegen. Met de broncode er bij is het veel makkelijker om uit te vinden wat er precies fout gaat en wat je kan doen om het probleem te verhelpen of in ieder geval te vermijden. Als je IT-afdeling goed genoeg is en de belangen groot genoeg zijn dan kun je de programmatuur zelf verbeteren. Niet dat iemand zelfs z'n eigen Office365 gaat compilen maar een bug in een Wordpress-module fixen is heel realistisch, al is het maar provisorisch.

Voor mij is inzage in de broncode dus een belangrijke factor bij het beoordelen van software. Niet de enige factor en ook niet de bepalende factor, maar wel een belangrijke factor.

* Ik kies hier even voor een ruime definitie van "open" en "closed" source. Ik bedoel dat jij, de klant, de source mag zien en veranderen. Het doet er even niet toe of de rest van de wereld dat ook mag of niet.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*