"FBI betaalde voor backdoor in OpenBSD"
Volgens een e-mail die op dit moment rondgaat heeft de FBI sommige opensource-ontwikkelaars betaald om meerdere backdoors in de OpenBSD IPSEC stack aan te brengen. Het voorval zou rond 2000 en 2001 hebben gespeeld. Dat meldt Theo de Raadt, oprichter en leider van het OpenBSD Project, dat als één van de veiligste besturingssystemen op het moment wordt gezien.
De Raadt laat weten dat de IPSEC stack inmiddels in tal van andere projecten en producten aanwezig is. "De afgelopen tien jaar is de IPSEC code regelmatig veranderd en aangepast, dus het is onduidelijk in hoeverre deze beschuldigingen waar zijn." De e-mail waarin de beschuldigingen staan zijn afkomstig van iemand waar De Raadt al bijna tien jaar niet meer mee heeft gesproken. "Ik weiger om onderdeel van deze samenzwering te worden en ik zal niet met Gregory Perry hierover praten."
Dat is ook de reden waarom De Raadt de e-mail van Perry openbaart. "Zodat degenen die de code gebruiken het op deze problemen kunnen auditen. Dat degenen die boos zijn over dit verhaal actie kunnen ondernemen. En als het niet waar is, degenen die beschuldigd worden zichzelf kunnen verdedigen."
De Zuid-Afrikaanse leider van OpenBSD erkent dat het niet echt ethisch is om een privébericht te openbaren, maar dat dit niet in verhouding staat tot de "grote ethiek" van een overheid die bedrijven betaalt die weer opensource-ontwikkelaars betalen om backdoors aan te brengen.
FBI
In zijn mail laat Perry weten dat zijn NDA met de FBI onlangs verliep en hij nu vrij over het onderwerp kan spreken. "Ik wil je laat weten dat de FBI verschillende backdoors en side channel key leaking mechanismen in de OCF heeft aangebracht, met als doel het monitoren van het site naar site VPN systeem, geïmplementeerd door de EOUSA."
Perry merkt verder op dat de backdoors waarschijnlijk ook de reden zijn dat OpenBSD de financiering door DARPA verloor, omdat ze dan zeker waren ontdekt. Vanwege de backdoors zou de FBI de laatste tijd actief het gebruik van OpenBSD voor VPN en firewall implementaties in gevirtualiseerde omgevingen aanmoedigen.
Reacties (43)
15-12-2010, 10:08 door
Prlzwitsnovski
Volgens een andere email die rond gaat krijgen we allemaal veel geld van bill gates...
Lekker veilig openBSD. Vandaar dat de Amerikaanse ooverheid openBSD zo aan het pushen is geweest.
15-12-2010, 10:28 door
[Account Verwijderd]
[Verwijderd]
15-12-2010, 10:45 door
Martijn2
Door Anoniem: En maar volhouden dat er niks in M$ zit... Yeah, sure...
Jammer genoeg kan je ervan uit gaan dat in alle Amerikaanse producten wel wat zit (Windows, OS X).Dat er in MS producten niets zou zitten wordt hiermee ook wel erg onwaarschijnlijk. Probleem is nu wel welke producten nog wel veilig zijn voor nieuwsgierige overheden, kan ik Mac en Linux e.d. uberhaupt nog wel vertrouwen? En als de broncode opensource is faalt toch wel het geroemde standpunt dat iedereen het kan nakijken, blijkbaar gebeurd dat dus niet.
Wat ik me nu meer afvraag is hoe vaak dergelijke praktijken wel niet voorkomen.
Want is beetje naïef om te denken dat dit enkel bij openbsd is gebeurd.
En het blijkt dat de opensource developers/bedrijven erg kwetsbaar zijn en voorzien moeten zijn van ene sterke ruggengraat. Anders gaat het principe mank.
Veel van onze routers en tal van embedded apparaten kunnen de sjaak zijn.
Moeten maar even de code audit afwachten, voordat we dwaze dingen doen/zeggen...
Want is beetje naïef om te denken dat dit enkel bij openbsd is gebeurd.
En het blijkt dat de opensource developers/bedrijven erg kwetsbaar zijn en voorzien moeten zijn van ene sterke ruggengraat. Anders gaat het principe mank.
Veel van onze routers en tal van embedded apparaten kunnen de sjaak zijn.
Moeten maar even de code audit afwachten, voordat we dwaze dingen doen/zeggen...
Door Martijn2:
Net zoals dat bij producten van het Chinese Hauwei backdoors zitten ingebouwd?Door Anoniem: En maar volhouden dat er niks in M$ zit... Yeah, sure...
Jammer genoeg kan je ervan uit gaan dat in alle Amerikaanse producten wel wat zit (Windows, OS X). /aluhoedje
Volgens Wikipedia (http://nl.wikipedia.org/wiki/IPsec) zou je bij IPcec de CIA moeten controleren wat staat voor Confidentiality – Integrity – Authentication. Maar is de CIA (Central Intelligence Agency) geen broertje van de FBI? ;-)
En volgens de engelse Wikipedia (http://en.wikipedia.org/wiki/IPsec) heeft de NSA zich er ook mee bemoeid:
IPsec is a successor of the ISO standard Network Layer Security Protocol (NLSP). NLSP was based on the SP3 protocol that was published by NIST, but designed by the Secure Data Network System project of the National Security Agency (NSA).
Soort van 3 eenheid net als in de bijbel, en daar geloven we ook in.
En volgens de engelse Wikipedia (http://en.wikipedia.org/wiki/IPsec) heeft de NSA zich er ook mee bemoeid:
IPsec is a successor of the ISO standard Network Layer Security Protocol (NLSP). NLSP was based on the SP3 protocol that was published by NIST, but designed by the Secure Data Network System project of the National Security Agency (NSA).
Soort van 3 eenheid net als in de bijbel, en daar geloven we ook in.
Open source wordt toch door iedereen 'gecontroleerd'. Weg stelling. Sterker nog. Ik denk dat Microsoft minder gevoelig is voor geld van de overheid, aangezien zij miljarden dollars verdienen met de verkoop van Windows, dus is het veel minder aantrekkelijk om een beetje geld of wat extra contracten binnen te slepen.
OpenBSD is toch open source? Laat ze dan maar aanwijzen waar die backdoors zitten. Volgens mij is dit FUD (fear, uncertainty, doubt).
15-12-2010, 11:40 door
Syzygy
Anti Virussoftware bedrijven die zelf virussen schrijven.
VPN's met backdoors.
Het gaat goed met de Security binnen ICT wat is er nog WEL te vertrouwen ?
VPN's met backdoors.
Het gaat goed met de Security binnen ICT wat is er nog WEL te vertrouwen ?
mmmm, ik heb rond de 30 VPN tunnels wereldwijd opgebouwd met OpenBSD machines....daar wordt ik ff HELEMAAL niet blij van....2000/2001 is wel een tijd geleden...vraag me af of het nu dan nog wel werkt ?
15-12-2010, 12:04 door
SirDice
Waarom heb ik het donkerbruine vermoeden dat dit fake is?
15-12-2010, 12:06 door
DarkieDuck
Geloof er weinig van , scott ontkent iig :P
Maar even afwachten wat er naar buiten komt
Maar even afwachten wat er naar buiten komt
"/aluhoedje"
Het is wel grappig hoe vaak mensen aluhoedjes slepen bij feitelijke informatie waar ze kennelijk niet van op de hoogte zijn. Ik hoop dat we nu niet naar niburu worden doorgestuurd ;)
Cisco's Backdoor For Hackers
http://www.forbes.com/2010/02/03/hackers-networking-equipment-technology-security-cisco.html
U.S. enables Chinese hacking of Google: Gmail Law Enforcement Backdoor
http://edition.cnn.com/2010/OPINION/01/23/schneier.google.hacking/
Hushmail warns users over law enforcement backdoor
http://www.theregister.co.uk/2007/11/20/hushmail_update/
Het is wel grappig hoe vaak mensen aluhoedjes slepen bij feitelijke informatie waar ze kennelijk niet van op de hoogte zijn. Ik hoop dat we nu niet naar niburu worden doorgestuurd ;)
Cisco's Backdoor For Hackers
http://www.forbes.com/2010/02/03/hackers-networking-equipment-technology-security-cisco.html
U.S. enables Chinese hacking of Google: Gmail Law Enforcement Backdoor
http://edition.cnn.com/2010/OPINION/01/23/schneier.google.hacking/
Hushmail warns users over law enforcement backdoor
http://www.theregister.co.uk/2007/11/20/hushmail_update/
15-12-2010, 12:15 door
SirDice
Door Anoniem: Cisco's Backdoor For Hackers
http://www.forbes.com/2010/02/03/hackers-networking-equipment-technology-security-cisco.html
Dat is geen backdoor maar een volledig gedocumenteerde feature die lawful interception mogelijk maakt. Wat overigens door de ETSI is aangezwengeld.http://www.forbes.com/2010/02/03/hackers-networking-equipment-technology-security-cisco.html
http://en.wikipedia.org/wiki/Lawful_interception
15-12-2010, 12:23 door
N4ppy
Kan FUD zijn.Maar kan ook zijn dat het er in zit. Het is open source maar dat wil nog niet zeggen dat het dan ook veel bekeken wordt.
Als ik buurman een stuk sourcecode geef dan begrijpt hij er geen snars van. En als ik eerlijk ben is ondanks dat ik code bouw IPSEC, encrypty ook niet mijn kopje thee.
Ik denk als je goed gaat kijken dat er maar weinig mensen zijn die dit door en door begrijpen. Als een groot deel daarvan in de zak van zitten dan blijven er maar weinig over voor een onafhankelijke review.
Iemand hier die helemaal los is en de wiskundige kennis heeft en coding skilz om de boel te reviewen?
Als ik buurman een stuk sourcecode geef dan begrijpt hij er geen snars van. En als ik eerlijk ben is ondanks dat ik code bouw IPSEC, encrypty ook niet mijn kopje thee.
Ik denk als je goed gaat kijken dat er maar weinig mensen zijn die dit door en door begrijpen. Als een groot deel daarvan in de zak van zitten dan blijven er maar weinig over voor een onafhankelijke review.
Iemand hier die helemaal los is en de wiskundige kennis heeft en coding skilz om de boel te reviewen?
15-12-2010, 12:24 door
Wim ten Brink
OpenBSD is een open-source project dus het verbaast mij dat niemand deze backdoors heeft ontdekt en dus heeft dichtgespijkerd. IPSEC is daarnaast een open standaard dus iedereen zou deze ook moeten kunnen analyseren op mogelijke protocol-lekken. Het verschil tussen FreeBSD en OpenBSD is bovendien dat je in OpenBSD geen closed-source onderdelen zult tegenkomen als onderdeel van het systeem, zoals device drivers en kernel code. Ook worden er vrijwel geen Non-Disclosure-Agreements gesloten om bepaalde device drivers mee te beschermen. Het is zo'n beetje het meest open besturings-systeem. Dat er dus backdoors in kunnen zitten vind ik dan ook twijfelachtig, omdat ik dan zou verwachten dat deze dan snel gevonden zouden worden.
Het kan wel waar zijn dat er ontwikkelaars zijn betaald voor dergelijke backdoors. Want het betekent niet dat ze er ook in zitten. Om die reden is dit bericht dan ook vrijgegeven zodat een audit op de IPSEC code gedaan kan worden op zoek naar die lekken. Ze moeten dan wel erg knap weggewerkt zijn om zo lang onopgemerkt te blijven.
Mogelijk dat die email juist het tegenovergestelde doel moet hebben: gebruikers wegjagen van het OpenBSD systeem naar andere besturings-systemen die wel kwetsbaarder zijn en die minder open zijn. Want ook andere besturings-systemen kunnen de nodige backdoors hebben.
Het kan wel waar zijn dat er ontwikkelaars zijn betaald voor dergelijke backdoors. Want het betekent niet dat ze er ook in zitten. Om die reden is dit bericht dan ook vrijgegeven zodat een audit op de IPSEC code gedaan kan worden op zoek naar die lekken. Ze moeten dan wel erg knap weggewerkt zijn om zo lang onopgemerkt te blijven.
Mogelijk dat die email juist het tegenovergestelde doel moet hebben: gebruikers wegjagen van het OpenBSD systeem naar andere besturings-systemen die wel kwetsbaarder zijn en die minder open zijn. Want ook andere besturings-systemen kunnen de nodige backdoors hebben.
15-12-2010, 12:50 door
ej__
Door DarkieDuck: Geloof er weinig van , scott ontkent iig :P
Maar even afwachten wat er naar buiten komt
Maar even afwachten wat er naar buiten komt
Is wellicht een andere Scott: http://www.itworld.com/open-source/130820/openbsdfbi-allegations-denied-named-participant
15-12-2010, 13:22 door
SirDice
Door WorkshopAlex: OpenBSD is een open-source project dus het verbaast mij dat niemand deze backdoors heeft ontdekt en dus heeft dichtgespijkerd. IPSEC is daarnaast een open standaard dus iedereen zou deze ook moeten kunnen analyseren op mogelijke protocol-lekken. Het verschil tussen FreeBSD en OpenBSD is bovendien dat je in OpenBSD geen closed-source onderdelen zult tegenkomen als onderdeel van het systeem, zoals device drivers en kernel code. Ook worden er vrijwel geen Non-Disclosure-Agreements gesloten om bepaalde device drivers mee te beschermen. Het is zo'n beetje het meest open besturings-systeem. Dat er dus backdoors in kunnen zitten vind ik dan ook twijfelachtig, omdat ik dan zou verwachten dat deze dan snel gevonden zouden worden.
Op zich valide maar de praktijk heeft al meerdere malen laten zien dat dat niet altijd opgaat. Wat dacht je van bijv. een bug in readdir()/seekdir() die er al 25 jaar in zat? Of een dikke bug in de Linux kernel die 7 jaar onopgemerkt bleef?Nu snap ik ook waarom we geen Chinese hardware meer mogen kopen. Dackdoor van de FBI in BSD en andere software raakt dan in conflict met de Chinese backdoor.
En dat is allemaal de schuld van wikileaks
En dat is allemaal de schuld van wikileaks
Een 'back door' hoeft niet zo duidelijk te zijn als if(FBI_CODE) {print(key);}
Als je het slim aanpakt laat je de VPN af en toe wat bits van de key lekken, dat kan op heel veel manieren zonder dat dat overduidelijk in de code zit.
Piet
Als je het slim aanpakt laat je de VPN af en toe wat bits van de key lekken, dat kan op heel veel manieren zonder dat dat overduidelijk in de code zit.
Piet
Door WorkshopAlex: Mogelijk dat die email juist het tegenovergestelde doel moet hebben: gebruikers wegjagen van het OpenBSD systeem naar andere besturings-systemen die wel kwetsbaarder zijn en die minder open zijn. Want ook andere besturings-systemen kunnen de nodige backdoors hebben.
Past wel in de strategie van de Amerikanen.3 punten
1 Boehoe, nee echt, valt open source ook niet te vertrouwen? Verstoppen ze echt wormen in de Apple? Kom op, datamining is een industrie, industriele spionage ga zo maar door. Het is simpelweg te winstgevend.
2. De vertaling van het artikel is weer eens cru, let op deze zin:
My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF, for the express
purpose of monitoring the site to site VPN encryption system
implemented by EOUSA, the parent organization to the FBI.
EOUSA = district of attorney, de wettelijke hand boven de organisatie. Het bananenrepubliekje aan de andere kant doet het juist goed, in nedeland levert dit soort interdepartementele spionage papierwerk op waar je niet goed van word.
3. Dan schrijf je toch lekker je eigen encryptie protocol, en anders moet je er maar niet vanuit gaan dat andermans werk zonder eigenbelang is.
1 Boehoe, nee echt, valt open source ook niet te vertrouwen? Verstoppen ze echt wormen in de Apple? Kom op, datamining is een industrie, industriele spionage ga zo maar door. Het is simpelweg te winstgevend.
2. De vertaling van het artikel is weer eens cru, let op deze zin:
My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF, for the express
purpose of monitoring the site to site VPN encryption system
implemented by EOUSA, the parent organization to the FBI.
EOUSA = district of attorney, de wettelijke hand boven de organisatie. Het bananenrepubliekje aan de andere kant doet het juist goed, in nedeland levert dit soort interdepartementele spionage papierwerk op waar je niet goed van word.
3. Dan schrijf je toch lekker je eigen encryptie protocol, en anders moet je er maar niet vanuit gaan dat andermans werk zonder eigenbelang is.
15-12-2010, 14:35 door
N4ppy
@WorkshopAlex iedereen kan dat. Nou ik niet en mijn buren ook niet. En hier bij ons op de zaak ook niemand.
Ik denk dat een hand vol mensen en de wiskundige kennis heeft om het te doorgronden en ook nog de coding skilz heeft on de code goed te auditen.
Kun jij het?
Ik denk dat een hand vol mensen en de wiskundige kennis heeft om het te doorgronden en ook nog de coding skilz heeft on de code goed te auditen.
Kun jij het?
15-12-2010, 15:46 door
Wim ten Brink
Door N4ppy: @WorkshopAlex iedereen kan dat. Nou ik niet en mijn buren ook niet. En hier bij ons op de zaak ook niemand.
Ik denk dat een hand vol mensen en de wiskundige kennis heeft om het te doorgronden en ook nog de coding skilz heeft on de code goed te auditen.
Kun jij het?
Ik werk als software-engineer en heb regelmatig te maken gehad met dit soort software en code, dus Ja. :-) Of in ieder geval, ik zou er slim genoeg voor moeten zijn om het te kunnen, hoewel mijn vaardigheden op dit gebiel al weer een beetje roestig zijn...Ik denk dat een hand vol mensen en de wiskundige kennis heeft om het te doorgronden en ook nog de coding skilz heeft on de code goed te auditen.
Kun jij het?
Maar stel dat 0,01% van alle OpenBSD gebruikers de sourcecode analyseren en in staat zijn om dergelijke lekken te ontdekken, dan zou 1 op de 10.000 gebruikers dus een kans hebben om dit lek te ontdekken. Dan zijn er of erg weinig gebruikers die OpenBSD gebruiken of het lek is behoorlijk goed verstopt. We praten hier over open-source dus obfuscatie in de code is zinloos. Dat zou zelfs op moeten vallen. Dus wat is er aan de hand dat dit lek niet is ontdekt, als het er al is?
Door WorkshopAlex:
Maar stel dat 0,01% van alle OpenBSD gebruikers de sourcecode analyseren en in staat zijn om dergelijke lekken te ontdekken, dan zou 1 op de 10.000 gebruikers dus een kans hebben om dit lek te ontdekken. Dan zijn er of erg weinig gebruikers die OpenBSD gebruiken of het lek is behoorlijk goed verstopt. We praten hier over open-source dus obfuscatie in de code is zinloos. Dat zou zelfs op moeten vallen. Dus wat is er aan de hand dat dit lek niet is ontdekt, als het er al is?
Door N4ppy: @WorkshopAlex iedereen kan dat. Nou ik niet en mijn buren ook niet. En hier bij ons op de zaak ook niemand.
Ik denk dat een hand vol mensen en de wiskundige kennis heeft om het te doorgronden en ook nog de coding skilz heeft on de code goed te auditen.
Kun jij het?
Ik werk als software-engineer en heb regelmatig te maken gehad met dit soort software en code, dus Ja. :-) Of in ieder geval, ik zou er slim genoeg voor moeten zijn om het te kunnen, hoewel mijn vaardigheden op dit gebiel al weer een beetje roestig zijn...Ik denk dat een hand vol mensen en de wiskundige kennis heeft om het te doorgronden en ook nog de coding skilz heeft on de code goed te auditen.
Kun jij het?
Maar stel dat 0,01% van alle OpenBSD gebruikers de sourcecode analyseren en in staat zijn om dergelijke lekken te ontdekken, dan zou 1 op de 10.000 gebruikers dus een kans hebben om dit lek te ontdekken. Dan zijn er of erg weinig gebruikers die OpenBSD gebruiken of het lek is behoorlijk goed verstopt. We praten hier over open-source dus obfuscatie in de code is zinloos. Dat zou zelfs op moeten vallen. Dus wat is er aan de hand dat dit lek niet is ontdekt, als het er al is?
Code begrijpen is minder moeilijk dan code schrijven. Het is alleen veel werk.Ik ben geen programmeur maar heb wel voldoende kennis om code te lezen en doe dat wel eens. En als ik dan een foutje vind geef ik dit aan de maker want zelf oplossen ben ik dan weer te dom voor.
Lesje neem eens de broncode van een internetpagina en begin te lezen. Dit valt best mee ook als je totaal geen verstand van programmeren hebt. Je zal vast niet alles snappen maar de basis is er wel uit te halen.
15-12-2010, 16:22 door
SirDice
Het feit dat iedereen de mogelijkheid heeft om de code te lezen betekend nog niet dat iemand dat ook daadwerkelijk doet.
Vergelijk het met iemand die op straat wordt aangevallen. De meeste omstanders denken allemaal hetzelfde: iemand anders zal het wel melden. Als iedereen dat doet meldt dus niemand iets.
Bugs worden meestal per ongeluk gevonden. Zeker de obscure bugs. Indien er, in dit geval, heel subtiel enkele bits van de sleutel wordt gelekt zonder dat het protocol zelf er onder lijdt zal niemand het opvallen. Tenzij je er specifiek naar gaat zoeken. Reken er maar op dat dat nu gebeurd.
Vergelijk het met iemand die op straat wordt aangevallen. De meeste omstanders denken allemaal hetzelfde: iemand anders zal het wel melden. Als iedereen dat doet meldt dus niemand iets.
Bugs worden meestal per ongeluk gevonden. Zeker de obscure bugs. Indien er, in dit geval, heel subtiel enkele bits van de sleutel wordt gelekt zonder dat het protocol zelf er onder lijdt zal niemand het opvallen. Tenzij je er specifiek naar gaat zoeken. Reken er maar op dat dat nu gebeurd.
/*
Sterker nog. Ik denk dat Microsoft minder gevoelig is voor geld van de overheid, aangezien zij miljarden dollars verdienen met de verkoop van Windows, dus is het veel minder aantrekkelijk om een beetje geld of wat extra contracten binnen te slepen.
*/
Denk je nu echt dat HET software bedrijf voor de pc's in de amerikaanse overheid niet in gaat op.............
Van wel planeet kom je?
Sterker nog. Ik denk dat Microsoft minder gevoelig is voor geld van de overheid, aangezien zij miljarden dollars verdienen met de verkoop van Windows, dus is het veel minder aantrekkelijk om een beetje geld of wat extra contracten binnen te slepen.
*/
Denk je nu echt dat HET software bedrijf voor de pc's in de amerikaanse overheid niet in gaat op.............
Van wel planeet kom je?
15-12-2010, 17:16 door
Wim ten Brink
Door SirDice: Het feit dat iedereen de mogelijkheid heeft om de code te lezen betekend nog niet dat iemand dat ook daadwerkelijk doet.
Klopt, maar er zijn altijd mensen die dat wel doen! Als 1 op de 100 gebruikers van OpenBSD programmeer-ervaring heeft en 1 op de 100 van die programmeurs ook de code gaat doorspitten dan heb je dus 100 paar ogen bij 1 miljoen gebruikers. Dat is niet veel, maar je zou verwachten dat die wel een goede kans moeten hebben om een lek te vinden.Is het de complexiteit van de code, misschien? Maar open-source is juist bedoeld om juist redelijk eenvoudig te zijn, mede omdat er zoveel mensen met de code moeten kunnen werken. Als niemand de code kan ontcijferen dan heeft open-source ook weinig zin.
Gaat het om de zware encryptie-functies? Moet je daar op letten om een dergelijk lek te vinden? Als het lek in de encryptie zit, dan werkt deze ook niet goed. Je zou met een ander stuk code die dezelfde encryptie uitvoert dan ook verschillen moeten opmerken. Het klinkt cryptisch maar zo'n functie, daar gaat iets in en er komt iets uit. Als daar niet uit komt wat je verwacht, dan is er iets mis.
Worden er bits van de sleutel gelekt? Waar worden ze dan naartoe gelekt? Het moet toch ergens naar toe gaan waar men dan weer toegang toe kan krijgen.
In ieder geval, de auditers zijn nu wakker geschud. We zullen zien wat dit oplevert en als er daadwerkelijk een lek is ingebouwd dan ben ik benieuwd hoe ze dat hebben kunnen doen onder de ogen van zoveel andere gebruikers...
15-12-2010, 17:48 door
SirDice
Door Anoniem: Lesje neem eens de broncode van een internetpagina en begin te lezen. Dit valt best mee ook als je totaal geen verstand van programmeren hebt. Je zal vast niet alles snappen maar de basis is er wel uit te halen.
HTML is geen programmeertaal.
15-12-2010, 17:57 door
SirDice
Door WorkshopAlex:
Ik vermoed dat het er nog veel minder zijn. Zo blijkt bijv. 70% van de code-kloppers van de Linux kernel gewoon betaalde programmeurs te zijn. De rest is een handje vol mensen die regelmatig iets doet en een enkeling die zo af en toe iets toevoegt/oplost. Verreweg de meeste zullen nooit naar de code kijken, laat staan dat ze de code ook begrijpen.Door SirDice: Het feit dat iedereen de mogelijkheid heeft om de code te lezen betekend nog niet dat iemand dat ook daadwerkelijk doet.
Klopt, maar er zijn altijd mensen die dat wel doen! Als 1 op de 100 gebruikers van OpenBSD programmeer-ervaring heeft en 1 op de 100 van die programmeurs ook de code gaat doorspitten dan heb je dus 100 paar ogen bij 1 miljoen gebruikers. Dat is niet veel, maar je zou verwachten dat die wel een goede kans moeten hebben om een lek te vinden.Is het de complexiteit van de code, misschien? Maar open-source is juist bedoeld om juist redelijk eenvoudig te zijn, mede omdat er zoveel mensen met de code moeten kunnen werken. Als niemand de code kan ontcijferen dan heeft open-source ook weinig zin.
Het aantal mensen die daadwerkelijk de code leest en begrijpt valt vies tegen. Gaat het om de zware encryptie-functies? Moet je daar op letten om een dergelijk lek te vinden?
Geen idee maar dat wordt wel gesuggereerd.Als het lek in de encryptie zit, dan werkt deze ook niet goed. Je zou met een ander stuk code die dezelfde encryptie uitvoert dan ook verschillen moeten opmerken.
Zolang die twee verschillende implementaties zonder problemen met elkaar kan werken zal het niemand opvallen. Hoe je dat precies zou moeten doen weet ik ook niet maar ik kan me er wel wat bij voorstellen.Worden er bits van de sleutel gelekt? Waar worden ze dan naartoe gelekt? Het moet toch ergens naar toe gaan waar men dan weer toegang toe kan krijgen.
Het lekken hoeft niet direct te betekenen dat het ergens heen gestuurd wordt. Kijk bijvoorbeeld naar hoe WEP is gekraakt. Dat lekt ook delen van de sleutel. Mede daardoor kun je nu eenvoudig die encryptie breken.ik heb het vermoeden dat veel systemen binnen tor op openbsd draaien.
en wie wikileaks zegt zegt tor.
geen systeem ontworpen met een zo strenge programmeerstructuur en reviews.
verstoppen in geheugen en met ander programma eruit halen valt 100% op.
en wat is er beter dan mensen uit een veilige omgeving jagen?
als het werkelijk lek was dan hadden we duizenden politieke moorden moeten zien.
en dan, hoe veel moeite is het om te zien of iemand heb gerommeld?
er is source code control, dus telkens kleine wijzigingen.
en hoe ver moet je terug gaan?
daarbij, het is al eens geherprogrammeerd.
vraag is op welk punt in de tijd iets erin verstopt moet zijn.
en trouwens, ipsec is een een bijmekaar geraapt shit protocol met vele leveranciers, dat is het grootste probleem.
openvpn zou optie zijn als je wilt.
zou me niet verbazen als het in een volgende hackaton onder de loupe genomen wordt.
leutah.
en wie wikileaks zegt zegt tor.
geen systeem ontworpen met een zo strenge programmeerstructuur en reviews.
verstoppen in geheugen en met ander programma eruit halen valt 100% op.
en wat is er beter dan mensen uit een veilige omgeving jagen?
als het werkelijk lek was dan hadden we duizenden politieke moorden moeten zien.
en dan, hoe veel moeite is het om te zien of iemand heb gerommeld?
er is source code control, dus telkens kleine wijzigingen.
en hoe ver moet je terug gaan?
daarbij, het is al eens geherprogrammeerd.
vraag is op welk punt in de tijd iets erin verstopt moet zijn.
en trouwens, ipsec is een een bijmekaar geraapt shit protocol met vele leveranciers, dat is het grootste probleem.
openvpn zou optie zijn als je wilt.
zou me niet verbazen als het in een volgende hackaton onder de loupe genomen wordt.
leutah.
15-12-2010, 22:20 door
Wim ten Brink
Er wordt gesproken over een backdoor maar daar moet je wel toegang toe krijgen. En omdat de FBI graag toegang op afstand wil hebben, betekent dit dus dat er ergens een backdoor moet zitten naar het Internet. Maar ook voor een locaal systeem is een backdoor zinloos als deze naar een doodlopende gang gaat. Wat kun je dan doen?
Als ik moet gaan speculeren over hoe deze backdoor werkt over IPSEC dan vermoed ik dat er wat code tussen moet zitten die voor een buffer overflow of vergelijkbare aanval kan zorgen. Dan heb je bijvoorbeeld een buffer waar normaal 12 tekens in gaan, maar je verstuurt er 16 waardoor er een blokje geheugen wordt overschreven. Dat moet dan weer een backdoor openen, een stukje code dat normaal gewoon dode code zou zijn en nergens anders door wordt aangeroepen.
De deur mag dan goed verborgen zitten, maar het is hol achter die deur, dus zoek je of er ergens een holle klank klinkt als je tegen muren aan bonkt.
Met een open-source project kun je precies hetzelfde doen. Je analyseert de code en al vind je de plek van het lek niet, je vindt mogelijk wel een ander stukje code dat eigenlijk niets lijkt te doen. Die pas je aan of vul je op en je backdoor is niet meer toegankelijk.
Als programmeur kijk ik vaak code na om te zien of alles nog wel gebruikt wordt. Dode code kan weg en er zijn veel mogelijkheden om dergelijke dode code te detecteren.
Het kan natuurlijk ook anders. Er kan een lek in zitten maar de code die de rest moet activeren moet eerst via de backdoor worden geladen. Dan zou het een heel klein beetje code moeten zijn, maar moet de FBI ook een boel code naar het systeem versturen met daarin de code die ze willen uitvoeren. Dat is vaak precisie-werk en niet altijd even eenvoudig. Het probleem is namelijk dat het niet mag opvallen. Het zou mogelijk zijn, maar het zou de mogelijkheden van de FBI ook aardig beperken. Een grotere backdoor biedt meer mogelijkheden maar zal snel opgemerkt kunnen worden.
Dus hoe klein is die backdoor uiteindelijk? Wat kan het? Of horen we alleen spookverhalen?
Als ik moet gaan speculeren over hoe deze backdoor werkt over IPSEC dan vermoed ik dat er wat code tussen moet zitten die voor een buffer overflow of vergelijkbare aanval kan zorgen. Dan heb je bijvoorbeeld een buffer waar normaal 12 tekens in gaan, maar je verstuurt er 16 waardoor er een blokje geheugen wordt overschreven. Dat moet dan weer een backdoor openen, een stukje code dat normaal gewoon dode code zou zijn en nergens anders door wordt aangeroepen.
De deur mag dan goed verborgen zitten, maar het is hol achter die deur, dus zoek je of er ergens een holle klank klinkt als je tegen muren aan bonkt.
Met een open-source project kun je precies hetzelfde doen. Je analyseert de code en al vind je de plek van het lek niet, je vindt mogelijk wel een ander stukje code dat eigenlijk niets lijkt te doen. Die pas je aan of vul je op en je backdoor is niet meer toegankelijk.
Als programmeur kijk ik vaak code na om te zien of alles nog wel gebruikt wordt. Dode code kan weg en er zijn veel mogelijkheden om dergelijke dode code te detecteren.
Het kan natuurlijk ook anders. Er kan een lek in zitten maar de code die de rest moet activeren moet eerst via de backdoor worden geladen. Dan zou het een heel klein beetje code moeten zijn, maar moet de FBI ook een boel code naar het systeem versturen met daarin de code die ze willen uitvoeren. Dat is vaak precisie-werk en niet altijd even eenvoudig. Het probleem is namelijk dat het niet mag opvallen. Het zou mogelijk zijn, maar het zou de mogelijkheden van de FBI ook aardig beperken. Een grotere backdoor biedt meer mogelijkheden maar zal snel opgemerkt kunnen worden.
Dus hoe klein is die backdoor uiteindelijk? Wat kan het? Of horen we alleen spookverhalen?
15-12-2010, 23:28 door
[Account Verwijderd]
[Verwijderd]
16-12-2010, 12:59 door
ej__
Sowieso is de geloofwaardigheid laag omdat aan de ontwikkelaars uit en in de VS de eis gesteld wordt en is dat ze niet met crypto bezig mogen zijn.
Dubieus dus.
O, het is een misvatting te denken dat er een achterdeur in de software zit, er wordt gehint op fouten die het mogelijk maken om de berichten mee te lezen, om de encryptie makkelijk(er) te kunnen kraken door bijvoorbeeld timing fouten.
Dubieus dus.
O, het is een misvatting te denken dat er een achterdeur in de software zit, er wordt gehint op fouten die het mogelijk maken om de berichten mee te lezen, om de encryptie makkelijk(er) te kunnen kraken door bijvoorbeeld timing fouten.
16-12-2010, 14:11 door
N4ppy
@workshopalex.
dus jij begrijp alles van rfc 4301, 4306 etc
(hahaha http://tools.ietf.org/html/rfc2119 wat betekend "MUST", "SHOULD" etc je moet al eerst op taalles voordat je rfc's uberhaubt kunt lezen ;)
wat betreft het remote inbreken, dat zal waarschijnlijk niet nodig zijn. Ik ga ervan uit dat FBI wel toegang heeft om het verkeer af te luisteren maar dat ze ook graag willen weten wat er in die ruis gebeurt die voorbij komt.
Dan wordt het al een stuk eenvoudiger. Backdoor is mischien een verkeerde keuze. Het zal hun eerder om key leak gaan dan hoef je mischien maar een klein foutje in de code te stoppen.
dus jij begrijp alles van rfc 4301, 4306 etc
(hahaha http://tools.ietf.org/html/rfc2119 wat betekend "MUST", "SHOULD" etc je moet al eerst op taalles voordat je rfc's uberhaubt kunt lezen ;)
wat betreft het remote inbreken, dat zal waarschijnlijk niet nodig zijn. Ik ga ervan uit dat FBI wel toegang heeft om het verkeer af te luisteren maar dat ze ook graag willen weten wat er in die ruis gebeurt die voorbij komt.
Dan wordt het al een stuk eenvoudiger. Backdoor is mischien een verkeerde keuze. Het zal hun eerder om key leak gaan dan hoef je mischien maar een klein foutje in de code te stoppen.
16-12-2010, 15:01 door
Wim ten Brink
Door N4ppy: @workshopalex.
dus jij begrijp alles van rfc 4301, 4306 etc
Niet alles, maar ik heb de nodige studieboeken over deze protocollen op mijn boekenplank liggen, ter referentie. Heb vooral veel moeten doen met ASN.1 om te communiceren met een speciale telefoon-centrale. Ook het nodige moeten doen qua encryptie om te communiceren met Smartcard-readers. En ik moet ook nog ergens een stevige Encryptie-bible hebben liggen, die ik maar voor 25% heb doorgelezen.dus jij begrijp alles van rfc 4301, 4306 etc
Je hebt gelijk, het is zware kost om te lezen. Maar je hoeft niet alles te begrijpen om het een en ander te kunnen volgen. Er zijn veel mensen die iedere dag weer code schrijven om met XML en/of HTML om te gaan, maar die in werkelijkheid maar zo'n 10% van de complete functionaliteit gebruiken. Simpelweh omdat je van de meeste technieken meestal maar een klein deel werkelijk gebruikt en daarbij af en toe wat extra's bij nodig hebt.
16-12-2010, 15:53 door
SirDice
Door WorkshopAlex: En ik moet ook nog ergens een stevige Encryptie-bible hebben liggen, die ik maar voor 25% heb doorgelezen.
"Applied Cryptography" toevallig? Zware kost inderdaad.
17-12-2010, 14:55 door
Dev_Null
Reken er maar op dat ALLE BELANGRIJKE CORETECHNOLOGIES in de ICT gebackdoord zijn.
Dan zit je pas veilig met het kunnen en willen afdekken van je security risicos :-)
Dan zit je pas veilig met het kunnen en willen afdekken van je security risicos :-)
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?