Dank voor de melding + links! NOBUS is dus net zoiets is als "wie een kuil graaft voor een ander..."

@Erik van Straten: Daar gaat het wel op lijken. Een backdoor die behooorlijk hard terugschopt in ieder geval...

En


Suggestief hoor: wie graaft de kuil en het schopt terug naar wie dan?

Eerst maar eens kijken hoe de code in de software is gekomen. Het lijkt op een supplychain attack wanneer je bijvoorbeeld op twitter @beaker volgt.

De kuil is als volgt :

Een (P)RNG genaamd Dual-EC DRBG is als optie in de standaarden gekomen. Deze RNG heeft als eigenschap dat als je bepaalde tevoren gekozen parameters gebruikt, de output (voor degene die de parameters samengesteld heeft) herleidbaar is.

Deze RNG was al lang verdacht, en blijkt inderdaad door de NSA het standaard proces in gemanouvreerd te zijn.

Het "Nobody But Us" deel is dat allleen degene die de parameters samengesteld heeft die decryptie kan doen.

De kuil is dus een (wegens deel van een standaard) gereedstaande backdoor , gegraven door de NSA/"Amerika" .

Het "zelf invallen" lijkt te zijn dat de parameters die gebruikt worden (Juniper had niet de NIST/NSA versies gebruikt) aangepast waren door een derde partij - waarmee opeeens allerlei ook Amerikaanse/overheids belangen die beschermd zouden moeten zijn door een VPN afluisterbaar waren - dat is het invallen.

Oftewel - het gebruikt van de RNG met de _mogelijkheid_ van een backdoor was Juniper's keuze/gevolg van volgen van een gemanipuleerde standaard , waarin een 'perfecte' backdoor mogelijk was.
Dat de mogelijke backdoor erin geactiveerd werd ten behoeve van iemand (anders) is daar het gevolg van.

De SSH backdoor is veel simpeler en botter .

De manier waarop de code aangepast is tov van wat Juniper schreef is ook interessant, maar de mogelijkheid om een "ideaal passief 'alleen door ons tapbaar vpn' te hebben" is omdat die mogelijkheid als overheidsbackdoor gebouwd was.

Waar de "Juniper-gate affaire" veel op lijkt is dit:
de NSA ontwikkelde ooit een backdoor die van een bepaald "backdoor-slot" was voorzien. Van deze backdoor had alleen de NSA de sleutel om van de backdoor gebruik te kunnen maken om in het geheim VPN internetverkeer te bespioneren.

Echter dit voorbeeld toont dat het backdoorslot door een aanvaller vrij gemakkelijk kon worden aangepast.
Zo kon dus de backdoor die de NSA had ontwikkeld om anderen te bespieden in handen vallen van een mogelijke aanvaller, die dankbaar van de backdoortechniek van de NSA gebruik kon maken om daarmee nu juist bijv. de Amerikaanse overheid te kunnen bespieden. Het was simpel een kwestie van een ander slot in de backdoor aanbrengen.

Dus de spionage val die ooit (door de NSA) werd opgezet, lijkt nu opeens tegen hen te zijn gebruikt.

Hier is het spreekwoord van toepassing: "wie een kuil graaft voor een ander valt er zelf in".
De uitleg van dit spreekwoord vind je hier:
https://onzetaal.nl/taaladvies/advies/wie-een-kuil-graaft-voor-een-ander
Een spreekwoord met bijbelse roots dus. Een boek dat werkelijk het nodige respect verdient,
ook al wordt er soms misbruik van gemaakt door mensen die zaken uit zijn verband trekken.

Dit roept tevens vragen op of het roepen van "God bless America" enige zin heeft
https://en.wikipedia.org/wiki/God_Bless_America
als de Amerikaanse overheid zich op dit punt niet aan het Woord van de Almachtige weet te houden...

Vandaag op tweakers.net:
http://tweakers.net/nieuws/106980/juniper-gebruikt-door-nsa-verzwakt-algoritme-voor-encryptie.html

Als je de moeite had genomen het artikel op Tweakers te lezen en de discussie daaronder te volgen had je deze opmerking niet op deze wijze gemaakt.

Het is bekend van wie de backdoor is.
Het is alleen niet bekend wie o.a. de twee q-waarden heeft aangepast.

En als je het hele verhaal leest, dus niet alleen tweeakters, maar ook bijvoorbeeld darkreading, The register, of , doe eens gek HD Moore, dan is wellicht de encryptie verzwakt, naar dat is niet de backdoor die gevonden is in de code.

Nu zijn er onderzoekers die melden dat er helemaal geen backdoor is in de code... (Kuch,.. Prutsers)

Het punt is, ja, dual_ec heeft een zwakheid, en ja, een van de 2! Backdoors maakt hier gebruik van, maar: indien de mitigerende code bij juniper voor screenOS niet slecht was geschreven, had dit geen ene moer uitgemaakt. Door een bug viel deze backdoor op, zonder die bug had die backdoor niet gewerkt.

Vraag is dus: wie heeft deze code geschreven en ook nog even een vpn backdoor erbij gezet. (Hint: het ontwikkelteam van screenOS zit in China).

Tot uw dienst, en ja daar lijkt het wel op Erik.

Maar Juniper heeft in het verleden het bedrijf Netscreen Technologies overgenomen.
Zo te zien ooit opgericht door enkele chinezen: https://en.wikipedia.org/wiki/NetScreen_Technologies
Dus zoals Rarsus ook al hint:

USA... China... Dan heb je het wel ergens over. Een pot verwijt de ketel -geval? Zou me niets verbazen.
Maar misschien is er zelfs sprake van (omdat de backdoorsleutel immers tweemaal gewijzigd lijkt te zijn):
"Twee honden vechten om een been, en de derde loopt er mee heen?..." ;-)
Of zou de derde wijziging eveneens een actie zijn van de chinezen "to confuse the Americans"?
Het blijft toch wat speculeren hoe nu precies de vork in de steel zit.

Maar één ding is wel duidelijk: backdoors inbouwen in dit soort apparaten kan men maar beter laten. Vind je ook niet?
Vroeg of laat wordt het ontdekt, en dat kan grote gevolgen hebben.
Vertrouwen komt te voet, en gaat te paard,
en vertrouwen is het belangrijkste ding om goed samen te kunnen werken. Zonder vertrouwen wordt het een puinhoop.

T.S.

Update 24 dec. van Adam Langley's weblog verwijst naar een technnische analyse
van Ralf-Philipp Weinmann over de "backdoored-backdoor":

https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/

T.S.

Een heel andere richitng.
http://www.theregister.co.uk/2015/12/21/security_code_to_backdoor_juniper_firewalls_revealed_in_firmware/ het zelfde in (via die rpw link):
https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor

Zo'n debug print string wijst naar een heel andere mogelijkheid. Dat is het ontwikkel/bouw process zelf.
Voor testen tuning optimailatie kan ik me goed voorstellen dat het betreffenden team de mogelijkheid nodig heeft om snel automatisch at andere instellingen moet kunnen doen. En zie daar komt de backdoor vraag (intern) naar de bouw/codeurs. Die zal ingewilligd worden wegens gebrek aan alternatieven. .
Alleen die versie wil je nooit echt uitleveren, De aanpassing moet nog ongedaan gemaakt worden.

Dat zou geen probleem hoeven te zijn als er voor de test/validatie aparte omgevingen (versies/releases) zijn.
Verdiep je dan eens in LCM releasemanagemetn en versionmanagement. In de praktijk implementeerd men een paar tools waar de verkoper die woorden heeft gebruikt. Het doel en welke problemen er opgelost zouden moeten worden wordt genegeerd. Gevolg een houtje touwtje aanpak.

Vragen:
1/ hoeveel ICT-ers kennen de situatie waar testtools en definieve op te leveren producten als apate straten worden herkend met voldoende onderlinge samenhang?
2/ En dan ook de vraag wele versie is via releasemanagement van elk onderdeel in de productie actief?
3/ Als je 2/ oppakt wat voor ongeautoriseerde code kom je dan tegen / ben je tegen gekomen?

Followup van prof. Matthew Green met uitstekende uitleg waarin de bevinding van Willem Pinckaers (genoemd achter "Update" bovenin de pagina van Ralf-Philipp Weinmann) is meegenomen: http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html.

Bron: http://www.theregister.co.uk/2015/12/23/juniper_analysis/ ("Juniper's VPN security hole is proof that govt backdoors are bonkers
If you let in the Feds, you'll let in anyone")

Uit het artikel van Matthew Green maak ik op dat er al een backdoor in de VPN code van Juniper zat [1]. Deze is door onbekenden gewijzigd waardoor die onbekenden i.p.v. de oorspronkelijke "achterdeurgangers" geen VPN sessies meer konden kraken, maar nu die onbekenden wel. De "fix" van Juniper lijkt eruit te bestaat dat zij de oude backdoor weer in ere heeft hersteld...

[1] https://www.security.nl/posting/455508/Britse+geheime+dienst+zocht+naar+lekken+in+Juniper-firewalls suggereert dat de NSA van niets wist. Maar als je zo'n backdoor kent, ga je die niet zomaar delen, ook niet met de GCHQ. Zoeken naar achterdeuren is natuurlijk een prima "alibi" als je al een sleutel hebt. Maat het zou ook zomaar kunnen dat enkele medewerkers van Juniper zelf zo'n backdoor kennen met het idee die beschikbaar te kunnen stellen zodra nodig geacht, of op verzoek van bevriende geheime diensten opgeslagen VPN sessies te kunnen kraken (zonder de sleutel zelf prijs te geven).

Kortom, er was een stiekeme cylinder aanwezig waarvan een onbekende partij de sleutel had. Die cylinder is door een andere onbekende partij vervangen in 2012 - kennelijk zonder dat iemand dat doorhad (of durfde aan te kaarten, bijv. i.v.m. gezichtsverlies). De oude cylinder is nu weer teruggezet. Probleem opgelost?

Veilige kerstdagen gewenst!

Ik ken ook argumenten om debug-level code juist te laten zitten:

1) Als er bij een klant onverwachte problemen optreden, kun je door iets als "loglevel=debug" in te stellen wellicht de oorzaak van de problemen achterhalen. Omdat het volgende punt dan ook kan optreden, is het belangrijk om met elk mogelijk loglevel relevante tests uit te voeren.

2) Het schrappen van (debug) code in uit te leveren productiesoftware kan tot gevolg hebben dat die productiesoftware anders werkt dan verwacht, bijvoorbeeld doordat de geheugenindeling wijzigt (waardoor bugs, die eerder niet aan het licht kwamen, dat nu wel doen) of door andere bugs die optreden zodra delen van code verwijderd wordt. Voorbeeld: toekennen van een andere waarde aan een productiecodevariabele in een debugsectie:

Als DEBUG true is, zal de while loop 7x worden doorlopen. Denkbaar is dat dit met testen niet wordt ontdekt. Zodra DEBUG false is, zal de while loop ineens 8x worden doorlopen, waarmee de code anders werkt dan tijdens testen. Je kunt niet uitsluiten dat zoiets tot security vulnerabilities leidt.

3) Het is belangrijk dat testen plaatsvindt onder zo realistisch mogelijke omstandigheden (denk aan VW sjoemelsoftware). Als het voor testen belangrijk is om debug-level output te kunnen produceren, zal die code erin moeten blijven zitten tijdens testen.

4) Sowieso als je na testen code wijzigt, zal deze een andere hash opleveren, en code signing heeft dan niet zoveel zin. D.w.z. als, na security-tests, andere code wordt opgeleverd, is het voor aanvallers eenvoudiger om meer te wijzigen dan bedoeld door de producent en goedgekeurd door de tester.

De ssh/telnet backdoor is absoluut geen debug print string .

Het is een hardcoded password, wat _eruit ziet_ als een debug print string.
Zodat iemand die de binary bekijkt op zoek naar leesbare tekst het niet als een mogelijk password herkent .
Het zou interessant zijn om de source te zien. Mogelijk is daar met een snelle blik ook niet meteen iets verdachts te herkennen aan het backdoor password - waar een andere string er misschien meer uit springt.

(het is vaak al erg interessant om bijvoorbeeld met 'strings' te kijken wat er uit een binary komt , als je geen verdere informatie hebt over mogelijke config/commandline opties, functies e.d. . ).

shortcut passwords voor testgebruik zijn, als ze eens achterblijven, de gebruikelijke programmeurs keuzes :
test / test1234, debug, tester, qwerty123 etc .

Vraagje:
1. betekent dit dat https eigenlijk veiliger is dan vpn?
2. of kun je ook https over vpn doen, en hebben ze dan niks aan zo'n backdoor?

Nee. Bovendien is het appels met peren vergelijken, meestal gaat het om verschillende gebruiksdoelen.

Als de https server niet gebackdoored of op andere wijze gecompromitteerd is, en je heel zeker weet dat je met die betreffende server communiceert, zou dat kunnen helpen.

Maar met zo'n backdoor in een firewall kan een aanvaller heel simpel een "Let's Encrypt" (of ander "Domain Validated") certificaat voor een server achter die firewall aanvragen, en is het de vraag of jij doorhebt dat jouw https sessie onveilig is door een MITM aanval in diezelfde backdoored firewall.

Nou ja, ik drukte mij misschien wat te simpel uit.
Even wat uitvoeriger nu waar ik aan dacht.

Ik stel me bijvoorbeeld de volgende situatie voor:


Hier kan "netwerkdata (unencrypted)" via een backdoor van ScreenOS box A of B worden bespioneerd door derden.

Maar als je nu geen unencrypted netwerkdata, maar encrypted netwerkdata door de VPN-tunnel heen stuurt, dan is de data in de VPN-internettunnel dus met twee verschillende sleutels versleuteld.
Om de data in te kunnen zien, zul je nu naast de VPN encryptie ook nog een tweede encryptie moeten verwijderen.
Alleen moet de ontvanger wel op een veilige manier op de hoogte worden gebracht van de sleutel van de tweede encryptie,
zodat aan de ontvangstkant de tweede versleuteling gedecrypt kan worden. Bijv. d.m.v. asymmetrische encryptie (https).

Dus als je er voor zorgt dat in het schema "netwerkdata (unencrypted)" nu encrypted wordt aangeboden i.p.v. unencrypted
(bijvoorbeeld m.b.v. een vorm van asymmetrische encryptie zoals een https verbinding tussen zender en ontvanger)
dan helpt zo'n backdoor niet veel meer. Alleen zijn denk ik bij gebruik van https de IP-adressen van zender en ontvanger te zien. Maar niet de inhoud van de message.

Je hebt wel gelijk dat je bij https moet letten op MITM met valse certificaten.
Maar daar moet je altijd al op letten met https. Niets nieuws. Certificate pinning en HSTS kan daarbij helpen.
Maar je kan ook andere manieren voor die tweede encryptie verzinnen.
Als je maar veilig laat weten hoe de onvanger het moet decrypten.

Hoe kijk jij er nu tegenaan Erik? Zullen we iets dergelijks in de toekomst steeds vaker zien?

Klopt. Tunnels in tunnels zijn mogelijk, maar zoals ik al aangaf (en jij bevestigt) heeft een aanvaller wel een voordeel met een MITM positie.

In dit kader: begin deze maand was er het bericht dat de regering van Kazakhstan vanaf 1 januari alle https verbindingen wil kunnen MITM-en (zie o.a. https://www.security.nl/posting/453638/Kazakhstan+eist+aftap+gebruiker). Om foutmeldingen te vermijden zul je een overheids-rootcertificaat moeten installeren.

Daarover vond ook op de Cryptography maillist een discussie plaats, aangezwengeld door Phillip Hallam-Baker (https://en.wikipedia.org/wiki/Phillip_Hallam-Baker). Viktor Dukhovni (RFC7435, bijdragen aan o.a. Postfix en OpenSSL) vertaalde de Kazakhstaanse tekst naar het Engels in http://www.metzdowd.com/pipermail/cryptography/2015-December/027409.html.

Later in die thread schreef Phillip Hallam-Baker in http://www.metzdowd.com/pipermail/cryptography/2015-December/027432.html: Nu hebben gewone burgers daar niets aan als ze Facebook o.i.d. bezoeken, maar het is natuurlijk wel iets waar journalisten en mensenrechtenactivisten, maar ook spionnen, (cyber-) criminelen en terroristen gebruik van kunnen maken (m.a.w. een goed voorbeeld van zinloze (mass-) surveillance waarbij je degenen waar je echt naar op zoek bent, niet te pakken krijgt).

Ja, tenzij je TOR o.i.d. gebruikt (dan kun je het afzender IP-adres verhullen). De meeste browsers sturen tegenwoordig ook -onversleuteld- de domainname van de server mee (SNI = Server Name Indication), en als de server niet een heel generiek wildcard certificaat terugstuurt, weet je vaak ook welke server precies bezocht wordt).

Ik zou niet weten waar je op moet letten. En Let's Encrypt certificaten zijn wel nieuw: als je MITM toegang hebt tussen een domein (bijv. middels zo'n backdoored Juniper firewall) en de servers van Let's Encrypt, kun je eenvoudig een Let's Encrypt certificaat verkrijgen en vervolgens inzetten. Ook DNSSEC/DANE gaan je niet helpen. Hoe wil jij dat nieuwe certificaat onderscheiden van een legitiem verkregen Let's Encrypt (of ander DV) certificaat?

HSTS niet (de nieuwe verbinding verloopt ook via TLS). Certificate pinning mogelijk wel - mits je dat ingeschakeld hebt en het domein eerder hebt bezocht. Je zult dan een waarschuwing krijgen dat het om een ander certificaat gaat (of andere public key bij public key pinning) - dat er verder legitiem uitziet. Stel je surft naar https://webmail.xs4all.nl/ en krijgt ineens een ander DV wildcard certificaat voorgeschoteld. Wat doe je dan? Geen webmail checken dan maar?

Ik vind het wel heel lastig dat je dit soort apparatuur kennelijk niet kunt vertrouwen. Ik kan me voorstellen dat organisaties, die serieus iets te verbergen hebben (zoals defensie, hoogwaardige trade secrets), aanvullende maatregelen nemen om dit soort risico's te mitigeren. Je kunt dan denken aan:
- Dubbele tunnels (VPN endpoints van verschillende merken);
- Een firewall tussen VPN endpoint en internet, in elk geval om te monitoren, maar bijv. ook om slechts specifieke IP-adressen toegang te geven tot specifieke poorten achter die firewall of technieken als port-knocking te gebruiken;
- Een "listen-only" monitor tussen firewall en internet om verkeer met onverwachte IP-adressen te kunnen detecteren (als aanvallers ook toegang hebben tot een IP-adres waarmee regelmatig verkeer wordt uitgewiseld, zoals voor updates, heb je een uitdaging - vooral als dat verkeer standaard ook versleuteld is).

Duidelijk is dat een enkel device (ook indien dubbel uitgevoerd) tussen LAN en internet, qua security, een single point of failure is. Maar ook dat als je, gezien vanaf internet, eerst een firewall van merk X en vervolgens een Juniper VPN endpoint tegenkomt, "ergens onderweg" afgevangen VPN verkeer waarschijnlijk ontsleuteld kan worden.

Dat is een aanname van je. Als je diep in de techniek zit wil je wel eens andere keuzes maken. Ik geloof dat ik lang geleden ook zo'n keuze van debugstring eens gemaakt hebt. Weinig inspanning om in te bouwen en er uit te halen.
De hele onderbouwing,. heplen van collegaes etc is uit ervaring niet fantasie. Net zo min als de problematiek rond het releasemanagement waar een oorzaak moet liggen.
Die simple passwords is alleen voor het normale bekende testwerk met de gebruikelijke benadering, niet voor het ingewikkeldere verhaal met technische randvoorwaarden.

Bij gebrek aan meer informatie omtrent de Juniper backdoor buiten wat nu bekend is zijn dat allemaal aannames.
Mijn statement wat _typische_ programmeurskeuzes zijn tijdens ontwikkel/test/buildfase is geen aanname maar iets wat iedereen gewoon kan weten - en doet, voor degenen die ook echt in de techniek zitten.

De keuze om als fixed password een string te nemen die _eruit ziet_ als debug string - nogmaals : het IS geen debugstring is iets wat een bijzonder creatieve redenering vereist om daar een alternatieve verklaring zonder malicious intent voor te verzinnen.
De hoeveelheid werk om een fixed password check optie in de code toe te voegen is gelijk ongeacht de gekozen password string.


*Dat* in een bepaalde ontwikkelfase versies met bewuste shortcuts in delen van code geschreven worden klopt inderdaad.
(/* stub */ int function check_credentials (int input) {return true;} ) .
Net als test-friendly versies ,stand-alone builds of noem maar op.

Maar een heel botte bypass van alle authenticatie in de firmware verwacht je in vroege fase van ontwikkeling, op moment dat je alle geplande authenticatie features nog mist, en zelfs nog geen config files kunt lezen.
De authenticatie bypass zelf is duidelijk bot en simpel - met alleen een typisch gekozen password wat (nu) opvalt als gekozen om vooral niet op te vallen in een binary .
In een ingewikkelde fase met veel randvoorwaarden verwacht je geen bypass meer van belangrijke (en normale) codepaden [namelijk de normale authenticatie logica] - een ingewikkeld password met een simpele check buiten de normale authenticatie flow voegt daar niks aan toe.

Ongetwijfeld zijn er nu veel mensen aan het uitzoeken wanneer, hoe en door wie de code is toegevoegd die deze functie tot en met de release implementeerde - en met welke intentie .
Hopelijk horen we er ooit nog eens een resultaat van.

Maar nogmaals - gegeven hoe de login backdoor erin zat zie ik geen geloofwaardig verhaal van 'vergeten test/debug feature' - en nog minder voor een onschuldige verklaring voor de VPN gewijzigde sleutel voor de afluisterbare sleutelgenerator.

Dat eerste zijn we het over eens. Met het tweede. ook gij gat voor het gemak in aannames mee.

Wat je gemist hebt en niet op reageert is het rigide release-management version management (volledige controle) of het ongecontroleerde gedoe (eg devops) waarijb de quick wins en time to market de drijfveren zijn. Dat zijn algememe aandachtspunten die overal geldig zijn. Als dat er uit komt ... Meestal blijft het dan gewoon stil, niemand geeft het toe.

Ik heb weinig gezegd over release management omdat dat pas echt pure speculatie is, met wat we nu weten.
Ja - een goed release management is belangrijk. Net als een goed development proces, goede beveiliging van de ontwikkelomgeving, een goed personeelsbeleid en nog zo'n serie open deuren.
Je kunt postuleren dat een probleem als bij Juniper _per definitie_ een indicatie is van slecht release management .
"met goed releasemanagement had het niet kunnen gebeuren" .

Dat vind ik niet - ook in een situatie met heel goed release management kun je een diep doorgedrongen aanvaller of groep van aanvallers postuleren die een backdoor tot en met release mee sturen door de code .
Een malicious insider kan best een malicious code reviewer of tester of release manager als partner hebben. En bij een grondige externe penetratie kan een derde partij wellicht zowel source als test/release signoff manipuleren .

Zouden we enige informatie hebben over het ontwikkelproces bij Juniper kun je enigszins gefundeerd gaan speculeren over wat er (allemaal) gefaald moet hebben om deze backdoors te introduceren.
Wat het een hack van een enkele ontwikkelmachine en te laks test/review/release proces ? Was het een enkele insider, in opdracht, voor eigen doeleinden, of een verzameling insiders in een verder heel goed ingericht proces ? Was het een super-hack van een hele serie van systemen waardoor de backdoors een wellicht heel goed test/release management proces konden doorlopen (denk aan Thompson, 'Reflections on Trusting Trust' - wie heeft een proces die _dat_ zou onderscheppen ) ?
Daar hebben we allemaal 0,0 informatie over .

Alleen over de backdoor zelf analyseer ik dat die veel meer lijkt op een backdoor die verstopt moest worden dan een vergeten weg te halen stukje steigerwerk van een ontwikkel/test proces.