Juniper schrapt elementen van zijn ScreenOS-software die lekken vertoonden

Fabrikant van netwerkapparatuur Juniper gaat de random number generators in ScreenOS 6.3 vervangen door andere software. De bestaande technologieën Dual_EC en Ansi X9.31 bleken afgelopen december zeer kwetsbaar te zijn voor aanvallen van buitenaf.

Het Amerikaanse Juniper maakt het nieuws bekend via een blogpost. De twee software-elementen worden vervangen door dezelfde random number generator die Juniper nu al inzet bij Junos OS, een ander besturingssysteem voor de netwerkapparatuur van het bedrijf. Dat wil niet zeggen dat de huidige versies van ScreenOS en de twee onderdelen in kwestie op dit moment nog kwetsbaar zijn; Juniper heeft direct na publicatie van de kwetsbaarheden de nodige updates gepubliceerd. Desalniettemin stapt het bedrijf af van de code. In de eerste helft van 2016 moet deze update plaatsvinden.

Op 18 december 2015 maakte Juniper bekend dat het 'ongeautoriseerde code' in de twee software-elementen van zijn ScreenOS had ontdekt. Deze code maakte het mogelijk voor een aanvaller om op afstand vpn-verkeer te ontsleutelen en beheerderstoegang te verkrijgen op bepaalde apparaten van Juniper. Het bedrijf gaf toen aan niet te weten waar de code vandaan komt. De kwetsbare software zou sinds 2012 aanwezig zijn op netwerkapparatuur van het bedrijf, maar inzicht in hoeveel de backdoors in de praktijk gebruikt zijn, is er niet.

Hoewel de code sporen zou vertonen van een overheidsactie, is het ook niet duidelijk welke partij er precies achter zit. Juniper zou wel de interesse van de inlichtingendiensten NSA en GCHQ hebben vanwege de verspreiding van Juniper-apparaten over heel de wereld en de hoeveelheid ssl vpn-diensten die het bedrijf levert. Direct bewijs dat de inlichtingendiensten achter de backdoors zitten, is er echter niet.

Reacties (49)

[Anoniem: 85014]

Dit soort fratsen wordt de laatste tijd door een aantal technologie bedrijven aangewend om mensen niet meer van thuis uit te laten werken. Dus doordat oa. de NSA/GCHQ denkt dit allemaal maar te mogen: op korte termijn meer files, meer uitstoot van wagens en minder thuiswerk. Pas op langere termijn zullen de Cisco en Junipers overal gewoon uitgefaseerd worden.

Bedrijven hebben geheimen, en die bewaken deze d.m.v. een VPN zodat mensen van thuis relatief veilig uit met die geheimen kunnen blijven werken. CTO en CSO's nemen het zekere voor het onzekere en zeggen tegen alle werknemers: kom maar terug hier werken en sluiten alle remote-werk mogelijkheden gewoon uit.

Moest men het zo uitleggen (zoals het dus eigenlijk gaande is), dan denk ik heel wat onschuldige burgers er schoon genoeg van hebben van die geheime diensten en hun spelletjes.

[Anoniem: 145867]

Kijk dat de backdoors in Amerikaanse netwerk apparatuur zitten maakt voor Amerikaanse bedrijven zelf niet zoveel uit. Economisch gezien.

Maar hoe zit het met de EU? Weten wij zeker dat Amerika geen intellectuele geheimen steelt van Europese bedrijven? We zijn wel bondgenoten... maar ik vertrouw die Amerikanen van geen meter.

Moeten we maar gewoon over gaan op Routers met volledig opensource software? Massaal?

[Cerberus_tm]

Dat lijkt me een heel goed plan, sowieso zoveel mogelijk open source voor onze overheden in elk geval. Maar Microsoft is in Europa keihard aan het tegenlobbyen bij overheden die dat willen doen...

[OddesE]

Het probleem met Open Source is dat de software per definitie gratis is. Wat we nodig hebben is een commerciële Open Source licentie.

En voordat je gaat roepen dat het niet per se free as in free beer is; dat is het wel. De licentie bepalingen maken het onmogelijk om voor de software geld te vragen. Dat kan alleen voor bandbreedte, support e.d.

* OddesE heeft de juridische mogelijkheden uitgebreid onderzocht

[Cerberus_tm]

Open en gratis lijkt me juist de perfecte combinatie voor de software die onze overheid gebruikt, als de software maar voldoet. En voor heel veel dingen denk ik dat er zulke software bestaat. De gemeente kan prima Libre Office gebruiken en op Linux werken. In noodgevallen kunnen uitzonderingen gemaakt worden, maar in principe moet dit geen probleem zijn. En als de overheid nieuwe systemen/programma's altijd voor Linux laat ontwerpen, geven ze ook een mooie impuls aan de Linux-wereld.

[Vale vista]

Gaan we nu dan ookons eigen OS bouwen, net als noord korea?

[Cerberus_tm]

Haha, tja, dat lijkt me niet echt nodig, aangezien we dus Linux hebben. Maar als de overheid b.v. een nieuw administratiesysteem voor Linux laat ontwerpen, geeft dit een impuls aan de Linux-wereld. Andere overheden overal ter wereld zouden dat dan ook gratis kunnen gebruiken. En er komt veel nieuwe code en expertise beschikbaar voor het programmeren op Linux.

[SA007]

"Open source" heeft geen zak te maken met "gratis".

Open source houdt in dat je de source kan krijgen als je het product hebt, gratis houdt in dat je iets kan krijgen zonder betaling.

Er is niks wat een bedrijf weerhoudt om een pakket tegen betaling aan te bieden wat open source is. En ook niks wat zegt dat er geen gratis pakket kan zijn zonder open source.

Je vergist je met de GPL, daarin wordt gezegd dat je alleen geld mag vragen voor support/distibutie/etc.
Alleen de GPL is een een van vele open source licenties, er zijn er genoeg die het prima toestaan geld voor producten te vragen.

[MGutker]

Fout! Open source houd in dat de source code voor iedereen besschikbaar is, ook voor mensen die het product niet gebruiken of hebben. Zoals hierboven al aangegeven mogen producten onder de standaard open-source licentie niet worden verkocht, op wat voor manier dan ook.

[BoringDay]

Alsof dat zal helpen?
Deze bug werd ook maar puur per toeval gevonden, je hebt niks aan de broncode als je de achterliggende gedachte van het architectuur niet kent. Laat het maar mooi aan de specialisten over.

[Anoniem: 145867]

Dus waarom dan geen distro voor je router? Zoals Linux? Oh en mensen die Linux distro's onderhouden zijn dus volgens jou ook geen specialisten. Dus alleen closed source is specialistisch?

En is het wel een bug? Of een feature.

[BoringDay]

Wat heeft dat nu met linux te maken? bepaalde software is dusdanig specifiek dat wij als eindgebruiker echt niet zomaar even voor de hobby kunnen uitpluizen als het open source is.

[Reactie gewijzigd door BoringDay op 26 juli 2024 22:38]

[Anoniem: 145867]

Dat klopt. Maar het is wel een stuk makkelijker voor ons Europeanen om zaken veilig te stellen door zelf instituten in te schakelen die de source controleren welke hier vandaan komen. Zonder te vertrouwen op closed source uit de USA.
Ik probeer een parallel te trekken. Natuurlijk heeft het 1 op 1 niet iets met Linux te maken. Maar hopelijk begrijp je wel wat ik bedoel. Of niet?

[Rembert]

Clinton heeft in '93 al opdracht gegeven om de Japanse 0-emission ontwikkelingen in Japan af te luisteren (middels Echelon) en de info door te sluizen naar GM, Ford en Chrysler.

In 1970 gaf Burke (werkend onder Nixon) aan dat economic intelligence noodzakelijk is voor national security.

Verder zouden Volkswagen ingenieurs stelselmatig te zijn afgeluisterd ten behoeve van GM. Het Franse Thompson zou een 1.4 miljard dollar deal over radar levering aan Brazilië hebben verloren aan het Amerikaanse Raytheon na vermeende spionage. Idem een 1 miljard order voor Airbus die uiteindelijk naar Boeing en McDonnell Douglas ging. Maar dit is nooit bewezen.

De opmerking van Burke geeft natuurlijk geen vertrouwen.

[mgizmo]

Dat staat haaks op de beweging van hybrid cloud.

[Anoniem: 706843]

Wie dit hieronder leest, moet toch op zijn minst erkennen dat er mogelijk meer aan de hand is. Vraag is natuurlijk, wat precies?

http://www.wired.com/2016/01/new-discovery-around-juniper-backdoor-raises-more-questions-about-the-company/

[wica]

Idd, Dual_EC is in 2008/2009 in NetScreen terecht gekomen, terwijl dit al in 2007 bewezen was niet veilig te zijn.
Vind het nog een vreemd iets van Juniper.

[Jerie]

De nonce die standaard op 20 staat verandert naar 32, terwijl er maar maximaal 30 gebruikt wordt.

“The more output you see [from the generator], the better [it is to crack the encryption],” Checkoway says. “Anything you see over 30 bytes is very helpful. Anything you see less than 30 bytes makes the attack exponentially harder. So seeing 20 bytes makes the attack basically infeasible. Seeing 28 bytes makes it doable, but it takes an amount of time, maybe hours. Seeing 32 bytes makes it take fractions of a second.”

Juniper could have chosen a nonce size anywhere between 8 bytes and 256 bytes, and Checkoway notes that previous research has shown that the most common value used by developers is 20 bytes. The use of 32 bytes, therefore, is curious. “Twenty bytes, as far as I know, is just fine [for security]. And 32 bytes would be just fine as well—if that random number generator didn’t have a backdoor,” he says.

The security community and the public are still baffled about Juniper's choices.
Juniper’s decision to increase the nonce to 32 bytes is also perplexing because Dual_EC, by nature, produces just 30 bytes of output at a time, according to Checkoway. To obtain enough output for the 32-byte nonce Juniper wanted for its encryption scheme, it had the Dual_EC generate output twice to produce 60 bytes. Checkoway says it then used only 2 bytes from that second generation and discarded the rest.

[Jerrythafast]

Pure speculatie natuurlijk, maar: 32 (decimaal) is gelijk aan 0x20 (hexadecimaal). Het zou in theorie dus een catastrofaal foutje kunnen zijn...

[gjmi]

Niet alleen in theorie, ik dat soort fouten al te vaak gezien. Hoewel niet zo schadelijk als hier.

[Anoniem: 85014]

Vooral omdat men in 2007 al had aangetoond dat alles meer dan 30-1 bytes het kraken in een fractie van een second mogelijk maakt, en dat ze dan toch precies naar 32 bytes gaan (voor geen enkele reden): geen twijfel mogelijk. Dit is opzettelijk gedaan.

[kosz]

Het 'lek' van de SSH/telnet toegang is wel heel erg triest en het meest makkelijke te misbruiken, als je die services open hebt staan toegankelijk vanaf internet kan je zo met een random username en het gelekte password inloggen met admin rechten.
In je logfile staat alleen dat user 'system' heeft ingelogd, wat natuurlijk makkelijk te verwijderen is.

[Jerie]

Dat lek is gedicht.

In je logfile staat alleen dat user 'system' heeft ingelogd, wat natuurlijk makkelijk te verwijderen is.

Dat hangt er van af. Wanneer je naar een externe syslogd logt, niet. Je kunt ze zelfs 'gewoon ergens' heen sturen (port 514 UDP) en een bridge die pakketjes laten opvangen, welke die vervolgens logt. Dan heb je in ieder geval de eerste keer dat je systeem is gehackt deze informatie (daarna kan men immers ook aan de gang met de manier waarop je externe logs verstuurt).

[OddesE]

Tja maar als je dat allemaal weet kun je beter gewoon het gat dichten

[eheijnen]

Hier nog een artikel over dit probleem:
https://boingboing.net/20...s-products-are-still.html

[wizzkizz]

Juniper zou wel de interesse van de inlichtingendiensten NSA en GCHQ hebben vanwege de verspreiding van Juniper-apparaten over heel de wereld en de hoeveelheid ssl vpn-diensten die het bedrijf levert.

Juniper heeft dus de interesse van álle (overheids)diensten uit elk land die zich bezig houden met het verzamelen van inlichtingen.

[Jerie]

Die quote slaat op het gelinkte artikel. Daar kun je lezen dat uit interne, uitgelekte documenten blijkt dat [...]. Andere inlichtingendiensten hebben voor zover wij weten geen expliciete interesse.

“We intend to make these changes in a subsequent ScreenOS software release, which will be made available in the first half of 2016.”

Overigens is eerste helft van 2016 erg vaag. Waarom zo traag?

[Reactie gewijzigd door Jerie op 26 juli 2024 22:38]

[Anoniem: 85014]

Men zal een aantal maanden nodig hebben om een nieuwe backdoor voor Juniper te verzinnen die anderen niet meteen ontdekken ...

In om het even welk bedrijf zou ik al die Junipers er uit gooien. Voor mij is het duidelijk dat deze backdoors opzettelijk door het bedrijf zelf geïntroduceerd zijn. En dus is het hele bedrijf en haar hele portfolio nu verbrand (= niemand zou ooit nog één product van hen mogen kopen). Oa. de link die MacUsers eerder postte legt dat haarfijn uit.

[Blokker_1999]

Voor mij is niet duidelijk dat deze door het bedrijf zelf zijn geïntroduceerd. Het hoeft slechts een enkeling te zijn die daarvoor gezorgd heeft (of een kleine groep mensen). Eerst ervoor zorgen dat een slecht ontworpen PRNG word opgenomen waarna je een bug introduceert die de goede PRNG zijn output laat overslaan.

Het feit dat men in December zelf naar buiten is gekomen met deze informatie toont aan dat het bedrijf zelf ook verbaasd was van deze ontdekking, anders hadden ze het evenzeer voor zichzelf kunnen houden.

[Anoniem: 85014]

Maar ze hadden al tot versie 6.2.0 als PRNG ANSI X9.31 geïmplementeerd en hebben pas daarna de PRNG Dual_EC, waarvan al sinds 2007 geweten was dat hij kwetsbaar is, toegevoegd in 6.2.0. Blijkt dat die ANSI X9.31 ook nog eens niet actief was? Dus enkel de kwetsbare Dual_C werkte. Plus dat men precies dat heeft gedaan, wat men in een cryptoconference in 2007 al afraadde voor Dual_EC: nl. die nonce value niet groter dan 20 te maken. Terwijl die standaard helemaal geen 32 heeft.

Waar Juniper verbaast over was was dat er extra code is toegevoegd geweest (oa. die SSH lek). Maar die extra code maakte gebruik van de kwetsbaarheden in Dual_EC. Daarover was men bij Juniper niet verbaast en pas nu besluit men die code eruit te gooien.

Juniper wist dus van de kwetsbaarheden in hun gebruik van Dual_EC maar was enkel verbaast van de toegevoegde code. Voor dat laatste denk ik aan een agent van één of andere geheime dienst die zichzelf in dienst heeft laten nemen om die code toe te voegen, of zo. Voor dat eerste denk ik aan opzettlijkheid van het bedrijf.

De kwetsbaarheden van Dual_EC zijn trouwens ook nog eens extra tijdens de Snowden onthullingen in licht gekomen. Bedrijven die het gebruiken in producten waar beveiliging een hoofdfunctie is, zouden zowizo verbrand moeten zijn.

[Blokker_1999]

En dan infiltreer je in de firma, werk je je in een positie waarin je dit soort aanpassingen kunt voorstellen en zeg je: ik heb een goed idee hoe we volgens mij het product nog veiliger kunnen maken. Als je het dan goed uitgelegd en verkocht krijgt dan kan je het implementeren ondanks dat de huidige implementatie al goed is.

Niet vergeten dat ze zelf aangeven dat het originele doel was dat de Dual_EC in combinatie met ANSI X9.31 moest werken maar dat door een "bug" de output van die laatste genegeerd werd en dus enkel de onbetrouwbare output van Dual_EC werd gebruikt.

[Anoniem: 85014]

Dan is het management van Juniper nog steeds verantwoordelijk: zij horen onafhankelijke code en architectuur reviews te organizeren.

In vrijwel ieder bedrijf waar ik voor geprogrammeerd heb is er sprake van code reviews. Maar misschien ben ik speciaal en is Juniper de norm in 'veilige' software?

Voor mij kan er op het niveau waarvoor Juniper verkoopt in géén geval zonder code review gewerkt worden. Niet één enkele lijn code mag maar ongereviewed blijven. Zelfs grondige en zeer zeer strenge reviews. Programmeurs die dat niet leuk vinden moeten maar elders een job zoeken. Pruts bedrijfjes genoeg.

Maar ik verwijt het het management van Juniper dat dit soort bugs geïntroduceerd geraken: Het gaat over een cruciaal onderdeel van beveiligingssoftware (het gebruik van de PNRG). Dat review je. Grondig.

[Anoniem: 145867]

Zulk soort geheimen moet je ook met zo weinig mogelijk mensen delen. Net zoals het VW schandaal wisten niet heeel veel mensen die bij Volkswagen werken hier van af.
Hoe minder hoe beter. Kan het ook niet zo snel uitlekken.

[Blokker_1999]

Als je de basis van je beveiliging moet gaan herontwerpen dan doe je dat niet op 1 dag. Dan moet je er tijd in steken om het uit te tekenen, te implementeren en te testen om zeker te zijn dat je voor geen grotere problemen zorgt.

[Jerie]

6 maanden? Terwijl men flink in de buidel tast voor ondersteuning voor zo'n produkt? Terwijl er een bekende remote vulnerability in je software zit wil jij alles grondig gaan testen? Leer je prioriteiten stellen. Zo snel mogelijk uitbrengen. Regressies is jammer, dat is collateral damage. Het feit dat ze niet hard rennen wekt een zekere suggestie.

[Precision]

[...] Dat wil niet zeggen dat de huidige versies van ScreenOS en de twee onderdelen in kwestie op dit moment nog kwetsbaar zijn; Juniper heeft direct na publicatie van de kwetsbaarheden de nodige updates gepubliceerd. Desalniettemin stapt het bedrijf af van de code. In de eerste helft van 2016 moet deze update plaatsvinden. [...]

[Reactie gewijzigd door Precision op 26 juli 2024 22:38]

[GreatDictator]

Natuurlijk, maar NSA/GCHQ zijn wel het meest capabel.

[erwinb]

Ik heb ooit een nieuwe srx gekocht voor mijn thuis netwerkje. Nu wel spijt van.
Koop je een duur security device voor thuis, dan blijkt het weer niet goed. Kan ik net zo goed de firewall gebruiken in mijn asus acces point.

[kosz]

De SRX draait op Junos niet op screenOS...

[Blokker_1999]

Als iemand er in geslaagd is om in het ene een backdoor te krijgen, denk je dan echt dat het andere nog vertrouwd kan worden?

[Anoniem: 85014]

Precies. Wat hier gebeurd is is te vergelijken met een architect die je huis ontwerpt met een opzettelijke constructiefout waardoor je kinderen in gevaar zijn voor instortingsgevaar.

Die informatie over de nonce value is voor mij doorslaggevend: Het management van dat bedrijf heeft waarschijnlijk haar programmeurs gevraagd het product (wat er één is waarbij netwerbeveiliging een absolute hoofdfunctie is) haar beveiliging opzettelijk te verzwakken. Daardoor liggen nu vele bedrijven hun geheimen op straat. Het is m.a.w. zoals een opzettelijke constructiefout waardoor je kinderen in gevaar zijn. Juniper is verbrand. Remove them all.

[Alex)]

Het kan ook zo zijn dat de desbetreffende programmeur niet op de hoogte was van de kwetsbaarheid en juist dacht "een langere nonce is veiliger, want voor wachtwoorden geldt dat tenslotte ook."

Als een code reviewer het ook niet doorheeft en de uitleg van de ontwikkelaar accepteert is het volkomen begrijpbaar dat deze kwetsbaarheid in de code is gekomen.

"Schrijf nooit aan kwade opzet toe wat afdoende verklaard kan worden door domheid."

[JozB]

Dit lijkt me niet aannemelijk... Waarom zou je eerst een backdoor (mee helpen) inbouwen om vervolgens met de billen bloot te gaan tenoverstaande van de hele ICT-wereld?
Volgens mij horen de Juniper producten nu wellicht juist tot de veiligste die je kunt kopen: als dit klopt, is het oudere ScreenOS gefixt, JunOS in detail doorgelicht (en goed bevonden). Het lijkt me aannemelijk dat ze dit niet nog eens door willen maken, en dus alert zullen blijven en nog stringenter zullen gaan werken.

[Zer0]

Dus is geen enkele beveiligingsoplossing niet betrouwbaar. Immers, als het gelukt is bij Juniper een gat te creeren, dan kan dat ook bij andere fabrikanten gebeurt zijn.
Ook Open Source is niet betrouwbaar gezien de recent gevonden bugs in diverse software die er al jaren in bleken te zitten.

[Blokker_1999]

Dat wil ik niet zeggen. Maar in dit geval weten we dat 1 product van dit bedrijf een backdoor bevat. Kan je dan nog echt zeker zijn dat er in hun andere producten geen backdoors verwerkt zitten?

Het kan bij andere fabrikanten ook gebeurd zijn, maar dan moeten we daar wel eerst bewijzen van vinden en niet zomaar anderen gaan beschuldigen.

Het enige veilige netwerk is het netwerk dat niet bestaat.

[Kabouterplop01]

een srx draait junos en geen screenos

[erwinb]

En je moet er dan maar alle vertrouwen in hebben dat daar geen 'fouten' in zitten.
Mijn vertrouwen, en daar gaat bij een firewall om, is weg.
Bij een firewall is functie en eigenschappen 50% van de waarde, de rest is vertrouwen wat je wil.

[Kabouterplop01]

Maar wat ga je dan doen? Hoe weet je van welk willekeurig device wat je dan ook aanschaft, of dat 100% betrouwbaar is? Geen enkele. Tenzij je zelf tot en met hardware de kennis en apparatuur hebt om alle facetten te kunnen testen.
Als zelfs Juniper het niet weet. (Althans zeggen ze)
Het lijkt me dat zo'n bedrijf al z'n software op orde heeft en van alles nog de originele software heeft in een subversion systeem. (Met uiteraard de changelog van de diffs en wie die changes gemaakt hebben)

[Anoniem: 85014]

Normaal is het git de dag van vandaag. Bij Subversion zou men op de SVN server kunnen inbreken en op die manier anonniem code toe voegen. Dat kan bij git niet.

Eigenlijk zouden alle bedrijven anno 2016 zo wel moeten beginnen overschakelen naar bv. git of reeds lang overgeschakeld zijn.

Ik zit nu (helaas) bij een ClearCase gebruiker. Oh mijn god hoe slecht is dat :-). Goed ja, heb ondertussen cleartool een beetje van buiten geleerd zodat ik toch maar niet met die dwaze IBM userinterfaces moet werken. Maar bv. gewoon al het concept van een commit bestaat er niet. Alles is file per file (branches bv. ook: nl het verschil tussen branch type en branch). Dus wijzigingen die in meerdere files gebeuren bij elkaar houden: nope, can't do. Waanzin. Te weten dat ze bij bv. ASML daar ook mee werken. Waanzin. Pure waanzin.

[Reactie gewijzigd door Anoniem: 85014 op 26 juli 2024 22:38]