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

Door , , 81 reacties
Submitter: ongekend41

Juniper, een maker van netwerkapparatuur, laat weten dat het 'ongeautoriseerde code' heeft ontdekt in zijn ScreenOS-software. Deze maakte het voor een aanvaller mogelijk om op afstand beheerderstoegang te verkrijgen op bepaalde apparaten en om vpn-verkeer te ontsleutelen.

JuniperJuniper meldt dat de kwetsbaarheden aan het licht zijn gekomen tijdens een interne code review van de ScreenOS-software, deze wordt gebruikt in NetScreen-apparaten die dienstdoen als firewall en vpn-verbindingen mogelijk maken. Het probleem wordt veroorzaakt door code waarvan het bedrijf niet kan aangeven waar deze vandaan komt. Dit is opmerkelijk, omdat deze code dus door een derde partij kan zijn toegevoegd aan de software. Onder andere de site CIO meldt dat het incident de sporen vertoont van een actie van een overheid.

De kwetsbaarheid, inmiddels ook bekend onder cve-2015-7755 en met een cvss-score van 9.8 uit 10, komt voor in versies 6.2.0r15 tot 6.2.0r18 en 6.3.0r12 tot 6.3.0r20. De eerste kwetsbare versie van de software is al in 2012 uitgekomen. Het wordt dan ook aangeraden zo snel mogelijk naar een van de veilige versies te updaten, die door het bedrijf zijn uitgebracht. Doordat veel bedrijven gebruikmaken van de producten van Juniper is de omvang van het incident groot.

Volgens Juniper zou het niet vast te stellen zijn of er daadwerkelijk van de kwetsbaarheden gebruik is gemaakt, omdat een ervaren aanvaller de mogelijkheid zou hebben gehad om logbestanden te verwijderen. De eerste kwetsbaarheid maakte het namelijk mogelijk om via ssh of telnet verbinding te maken met een van de kwetsbare NetScreen-apparaten en volledig beheer te verkrijgen. Ook het tweede lek, dat het mogelijk maakte vpn-verbindingen te ontsleutelen, zou zonder detectie gebruikt kunnen worden.

Moderatie-faq Wijzig weergave

Reacties (81)

DIt is enorm ernstig.
Hiermee staat de poort open, vrij letterlijk. Zo'n apparaat moet je juist beschermen, als daar een lek in zit dan ligt je netwerk tot op het bot open.

Als netwerkbeheerder kan de paniek haast niet groter worden, hier moet je nú iets aan doen. En dat komt dan vlak voor de kerst uit :( . In theorie geen probleem want in theorie heeft iedereen z'n spullen morgen gepatched. In de echte wereld wil de directeur kerst vieren met z'n familie en blijft al het werk liggen tot na de kerstvakantie, of de netwerkbeheerder mag in z'n eigen tijd het probleem oplossen.

De schade van dit probleem is gigantisch, dit grapje kost tientallen miljoenen, misschien wel honderden miljoenen en we zijn er nog niet van af, het zal nog wel een paar jaar door etteren. De ervaring leert dat de meeste apparaten nooit meer gepatched worden. Zelfs professionele netwerkapparatuur als deze wordt snel vergeten. Zolang het ding werkt kijkt niemand er naar om, ze weten niet eens dat ze een Juniper in huis hebben en het IT-nieuws volgens ze toch niet.

Dat is niet alleen schadelijk voor de kwetsbare netwerken maar de rest van de wereld heeft er oook last van. Niet alleen omdate de gekraakte netwerken gebruikt zullen worden om anderen te hacken en de DOSsen maar ook omdat "onze" gegevens worden verwerkt door die systemen, die liggen nu op straat.

Ik hoop dat de schrijvers van de ze backdoor trots op zichzelf zijn. Ze moeten wel heel belangrijk werk doen dat ze de privacy en de veiligheid van z'n beetje de hele wereldbevolking er voor opofferen. Hun land moet hier wel enorm veel voordeel bij hebben dat ze hun burgers en bedrijven met een zo'n enorme rekening opzadelen. Het voelt erg als zo'n gevalletje waar de opbrengsten bij een kleine groep terecht komt en de kosten worden betaald door de maatschappij.
Waarom kost dit honderden miljoenen? Gewoon patch draaien en klaar. Geen enkel bewijs dat het lek al ooit misbruikt is.

Dat het triest is dat dit soort lekken bestaan op dit niveau in spullen van juniper is een ander verhaal. Hilarisch bijna, tenzij je klant bent..
Waarom kost dit honderden miljoenen? Gewoon patch draaien en klaar. Geen enkel bewijs dat het lek al ooit misbruikt is.
Ik kan me niet voorstellen dat iemand de moeite heeft genomen om een dergelijke complexe backdoor te bouwen om er dan geen gebruik van te maken. Dat er geen bewijs van misbruik is zegt nog niet dat er geen misbruik is gemaakt.
Daarnaast moet de echt pijn nog komen. Dusver was het een geheime backdoor, nu we weten dat die backdoor bestaat zulllen krakers er misbruik van gaan maken. Dat verschijnsel zien we ook bij andere beveiligingsproblemen, zodra er een patch is wordt die geanalyseerd en gebruikt om ongepatchte systemen te kraken.

"Gewoon de patch draaien" is in principe genoeg maar iemand moet het wel doen. Gezien het aantal Juniper apparaten op deze wereld moet dat een kapitaal aan manuren kosten. Zeker omdat dit geen gewone patch is maar een panieksituatie waarin mensen uit bed zijn gebeld om te gaan patchen.
Dat het triest is dat dit soort lekken bestaan op dit niveau in spullen van juniper is een ander verhaal. Hilarisch bijna, tenzij je klant bent..
Her ergste is nog wel dat ze waarschijnlijk niet enige zijn. Juniper staat bij mij bekend als een nette leverancier die z'n zaakjes op orde heeft. Als een topper als Juniper al zo'n gat heeft doorgelaten dan zal het bij een hoop andere leveranciers ook wel mis zijn.
Zij die juniper producten gebruiken zijn meestal wel degelijk op de hoogte van het nieuws, krijgen mails van juniper enz... Dit is niet echt huis en tuin gebruik apparatuur. Een tweaker hier en daar buiten beschouwing gelaten

De meeste bedrijven heb service contracten voor dit soort gein en worden dus automatisch op de hoogte gebracht als het bedrijf dat winst tenminste

[Reactie gewijzigd door white modder op 18 december 2015 10:44]

De meeste bedrijven heb service contracten voor dit soort gein en worden dus automatisch op de hoogte gebracht als het bedrijf dat winst tenminste
Onderschat niet hoeveel bedrijfjes er zijn zonder professionele IT. Er zijn er heel wat die iets neer laten zetten en er verder niet naar omkijken tot het stuk gaat. Zelfs als er in eerste instantie een servicecontract was dan is het maar de vraag of het nog verlengd wordt. Zolang alles probleemloos werkt wil niemand betalen voor support.
Zelfs als die mails van Juniper ergens terecht komen waar ze worden gelezen dan is het nog maar de vraag of de administratief medewerker die ze moet behandelen snapt wat er in staat, wat de gevolgen (kunnen) zijn, wat er moet gebeuren en hoe je dat doet.
Die mensen maken zich ook geen zorgen om de oude patches die eerder dit soort zaken oplostten (iets met een openssl library etc.), dus deze zullen ze absoluut niet zo ernstig vinden als jij nu typt.

Ookal heb je kleine bedrijfsjes, je hardware meldt je toch wel aan om support te krijgen en eventueel licenties te downloaden. Dan krijg je automatisch ook de nieuwsbrieven. Wat je daar mee doet mag je zelf weten, maar als je ze niet leest en gewoon weggooit maak je je blijkbaar totaal nergens zorgen om en kan deze backdoor er ook nog wel bij.
Dat soort mensen moet ook maar eens nagaan waarom ze überhaupt een security device vooraan het netwerk zetten en niet gewoon rechtstreeks het internet op gaan.
Die mensen maken zich ook geen zorgen om de oude patches die eerder dit soort zaken oplostten (iets met een openssl library etc.), dus deze zullen ze absoluut niet zo ernstig vinden als jij nu typt.
Dat is precies mijn probleem. Het gaat er niet om of zij het erg vinden, het gaat er om dat ík het erg vind maar ik kan er niks aan doen. Zij veroorzaken overlast waar ze zelf misschien niks van merken maar ik merk het wel. Zij laten mijn gegevens uitlekken en hun gekraakte computers worden gebruikt om mijn systemen aan te vallen.
Jij (of: men) kan er wel iets aan doen. Ieder device dat door een kwaadwillend persoon gevonden en geinfiltreerd kan worden, kan dat ook door een goedwillend persoon. Gaat er om wie eerst is en vervolgens de achterdeur dicht doet.
Dat heet terughacken en dat is verboden in Nederland, dat is dus geen oplossing.
Inderdaad, simpel voorbeeld is hoeveel bedrijven wel niet mijn postcode weten, en wat ik gekocht heb. Die geef ik dan in goed vertrouwen aan een caissičre, terwijl hogerop dus de poorten openstaan. (Nu doe ik dat om deze reden al jaren niet, maar de gemiddelde mens...)
Juniper maakt hardware voor specifieke doeleinden, zeker de ScreenOS produkten, die zet je niet aan in een hoek waar je nooit meer naar kijkt. Daarbij krijgen grotere bedrijven vaak security informatie ook nog uit andere hoeken (van organisaties die deze zaken monitoren).

Groter probleem is dat niet elk bedrijf zomaar even kan updaten, daar zit een heel traject achter.
Ze doen wel codereviews, dus zo onprofessioneel zullen ze niet zijn.
Dat niemand wil betalen voor support is puur een aanname, veel bedrijven doen daar echt niet moeilijk over.

Je kan natuurlijk alles zwart wit gaan bekijken en denken dat dit niet mag voorkomen.
Echter is dat een droom voor een idealistische wereld.
Ze doen wel codereviews, dus zo onprofessioneel zullen ze niet zijn.
Met "professioneel" doelde ik niet op Juniper, die hebben het vast wel op orde. Ik dacht meer aan het verzekeringskantoor hier om de hoek waar drie 50+ers werken op computers met Windows Vista.
Dat niemand wil betalen voor support is puur een aanname, veel bedrijven doen daar echt niet moeilijk over.
Mijn eigen ervaring is dat ze best willen betalen, tot ze horen wat het kost om het goed te doen. Maar mijn ervaring is beperkt, ik heb de wijsheid niet in pacht.
Wil je beweren dat 50+ minder goed zijn?

"Ik dacht meer aan het verzekeringskantoor hier om de hoek waar drie 50+ers werken op computers met Windows Vista."

Dit is toch ook een onprofessioneel uitspraak.
Je onderschat ze behoorlijk, geloof me er zijn zat 50+ die ontzettend veel IT kennis hebben, die jongere generaties ver over treffen.
Wil je beweren dat 50+ minder goed zijn?
Dat is niet wat ik wilde zeggen maar ja, dat ook, gemiddeld genomen klopt dat wel.
"Ik dacht meer aan het verzekeringskantoor hier om de hoek waar drie 50+ers werken op computers met Windows Vista."

Dit is toch ook een onprofessioneel uitspraak.
Noem mij maar onprofessioneel maar wie nu nog op Windows Vista werkt heeft voor mij de schijn tegen.
Je onderschat ze behoorlijk, geloof me er zijn zat 50+ die ontzettend veel IT kennis hebben, die jongere generaties ver over treffen.
Die zijn er zeker, maar grosso modo valt het nogal tegen, maar daar wil ik het helemaal niet over hebben.

Het gaat er om dat ze werken op computers die er uit zien alsof ze al 10 jaar geen onderhoud hebben gehad en volgens mij zijn deze mensen best representatief voor de gemiddelde kantoorslaaf bij kleine bedrijfjes in Nederland. Ik weet niet hoe het met de rest van hun systemen staat maar het deel dat ik wel kan zien doet me vrezen voor het ergste.

Het is een verzekeringstoko, je zou denken dat die mensen het nut van preventie snappen. Misschien hebben ze gewoon een hele goede verzekering tegen IT-problemen :)

Maar ik zal direct toegeven dat ik daar geen bewijs voor heb, alleen mijn gevoel.
Misschien is dat wel het probleem, je gevoel zegt het maar dat betekend niet dat het zo is.
Even afzien van de leeftijdspecificatie, als we die (terecht) negeren, dan staat alsnog de rest van zijn punt; veel gebruikers zijn letterlijk niet verantwoordelijk genoeg, maar hebben wel een grote inspraak in de ict kosten (kleine en middelgrote bedrijven).
Veel ziggo zakelijk gebruikers hebben standaard een juniper router liggen tussen de modem en eigen router met een speciaal ziggo script. Wie garandeert ons dat ziggo deze boxen allemaal bij werkt ? Deze box is eigendom van ziggo en daar kan je als gebruiker ook niet op inloggen
omdat die dingen geen screenos draaien ;-). of toch niet bij mijn weten.

[Reactie gewijzigd door white modder op 18 december 2015 15:04]

Tja, ik weet het ook niet misschien handig als hier duidelijkheid over komt ?
ScreenOS draait alleen op de "netscreen" en "SSG" firewall appliances..
Alle Juniper routers draaien in principe JunOS, en een klein deel (zoals de ERX) op een variant van JunOS.

/M
Klopt, maar die van mij is nu meteen geupdated naar 6.3.0R21 :o

Moet zeggen dat ik laatst iets heel vreemds had wat nog nooit was voorgekomen, het DNS-ip address wat wordt meegestuurd met dhcp (in deze Juniper) was ineens verandert, en ik kon niets vinden in de logging. Wie weet hoe dit gebeurt is .......

Nou ja, we zien wel.
(moest even wachten met posten want mijn internet lag eruit :*) )
Ik ken een aantal grote bedrijven die geen Updates aanbrengen op zeer oude omgevingen omdat ze bang zijn dat het dan niet meer opstart.
Als dit dan niet in een outsource contract zit, gebeurt meestal al helemaal niets. Totdat ze ge-audit worden door een of andere regulator.
Een beetje gevoelig bedrijf heeft toch wel 2 firewalls van verschillende fabrikanten?

Op mijn laptop gebruikte ik eerst al pfsense in virtualbox met loopback adapter i.c.m. comodo firewall voor windows en dan deed ik vrij weinig boeiende zaken...
dus verwacht van bedrijven toch ook wel een beetje meer inzet als "kassie kopuh, aansluite en vergetuh"
Een beetje gevoelig bedrijf heeft toch wel 2 firewalls van verschillende fabrikanten?
Ik hoop dat je gelijk hebt maar ik geloof het niet, volgens mij is dat eerder de uitzondering dan de regel. Daarnaast zijn er 100 "ongevoelige" bedrijven voor ieder "gevoelig" bedrijf. Tegenwoordig heeft iedere buurtsuper wel een netwerkje waar je dit soort apparatuur kan aantreffen.
dus verwacht van bedrijven toch ook wel een beetje meer inzet als "kassie kopuh, aansluite en vergetuh"
Ik ben daar wat cynischer over, ik verwacht juist dat het wel zo gaat.
en ze dan liefst ook achter elkaar zetten en niet naast elkaar, want dan ben je dubbel zo kwetsbaar
Nou, je focust nu op hoe duur cq moeilijk het is om op te lossen.
Maar vraag je eens af wat er de laatste jaren gebeurd is. Juniper heeft een market share van ongeveer 30%. Dat betekent grofweg dat 30% van het netwerk verkeer in principe meegelezen kon worden door die overheid in kwestie
Houdt er wel rekening mee dat ScreenOS, waar dit in gevonden is, al jaren aan het migreren is naar Junos. Het wordt nog wel gebruikt maar hoofdzakelijk op oude meuk. Wil je nog een SSG of ISG kopen waar ScreenOS op draait dan moet je er snel bij zijn. In 2016 stoppen ze er mee: http://www.juniper.net/support/eol/ns_hw.html
Dat is niet alleen schadelijk voor de kwetsbare netwerken maar de rest van de wereld heeft er oook last van. Niet alleen omdate de gekraakte netwerken gebruikt zullen worden om anderen te hacken en de DOSsen maar ook omdat "onze" gegevens worden verwerkt door die systemen, die liggen nu op straat.
Ik wil de ernst van dit lek niet onderschatten, maar overdrijven is ook een kunst. Ik mag hopen dat er achter de juniper router ook nog beveiliging zit. Elke server en PC heefteen software firewall.gevoelige data mag , hoop ik, op een beveiligde manier zijn opgeslagen.
Ik mag hopen dat er achter de juniper router ook nog beveiliging zit. Elke server en PC heefteen software firewall.gevoelige data mag , hoop ik, op een beveiligde manier zijn opgeslagen.
Dat vind ik nogal naief. Veel te veel gevallen waarin dat niet waar is. Ook als het wel zo is dan is met alleen zo'n Juniper al genoeg ellende aan te richten. Encryptie op netwerkverkeer is nog steeds niet standaard en voor een DOS aanval heb je niet meer nodig dan toegang tot de router.
Geeft maar weer aan dat je met een VPN boer ook niet meer veilig zit, en dit ow zo makkelijk te kraken is.
Juniper is een hardware fabrikant die hardwarematig firewalls maakt en mede daarmee ook hardware levert die voor VPN's opzetten kan worden gebruikt......Juniper is geen VPN boer
Dat wordt ook niet door hem gezegd. Wat hij (denk ik) bedoelt is dat een VPN boer de systemen van dit bedrijf gebruikt en daardoor de klant van die VPN boer niet meer veilig is.
Waarom is dit off-topic ? Dit is namelijk helemaal waar. Er staart dat via remote management ingelogd kan worden en het apparaat dus feitelijk aanpasbaar wordt. Het decrypten van VPN verkeer is daar dan een mogelijke gevolg van. Als je remote toegang kan verkrijgen kan je misbruik maken van veel meer kwetsbaarheden. Zo zou je dus het "screened" netwerk kunnen afscannen waardoor je dus via de firewall kwetsbare systemen kan achterhalen in deze "beveiligde netwerken". Maar ook bv routing aanpassen waardoor je verkeerstromen kan manipuleren en god weet ik wat niet meer.
Geeft aan dat assumptie de moeder van alle fuckups is. Los van het feit dat een VPN boer hier los van staat, is security niet een automagisch iets. Hoe goed je security ook is, je bent zelf altijd eindverantwoordelijk.

Een voorbeeld is Azure AD RMS. Security is prachtig, maar het houdt geen fototoestel tegen :)
Ja maar dat is met elke beveiligingssoftware waar een lek/achterdeurtje in is gebouwd. Er is hier bewust met de implementatie van de VPN software geknoeid zodat VPN verbindingen ontsleuteld kunnen worden. Zelfde kan met alle andere softwarebeveiligingen gedaan worden.
Hoe krijg je zoiets in de sourcecode, ik neem aan dat ze met svn achtige oplossingen werken. Zeer ernstig lek, waar de documenten van Snowden ook al inzicht over gaven, al stond Juniper daar niet bij.
Hoe krijg je zoiets in de sourcecode, ik neem aan dat ze met svn achtige oplossingen werken. Zeer ernstig lek, waar de document van Snowden ook al inzicht over gaven, al stond Juniper daar niet bij.
Met genoeg geld, patriotisme en/of chantage vindt je altijd wel een programmeur die de code voor je toevoegt. De kunst is dan nog de code zo te schrijven dat je niet ziet dat het een backdoor is. Dat is een tak van programmeerkunst die wel "underhanded programming" genoemd wordt. Je schrijft code X doet (of lijkt te doen) maar in werkelijkheid gebeurt er Y. Er worden zelfs wedstrijden in gehouden, die zijn erg leuk als je een beetje kan programmeren. http://www.underhanded-c.org/
Begrijp waar je op doelt, maar dan kan je de programmeur wel achterhalen, de vraag is of ze dat hier ook kunnen.

Voordat je code de source in gaat, zou het toch moeten worden gereviewed door peers. Sterker nog, elk element van je software zou moeten worden getest in assurance testing (welk doel heeft dit stuk code).
Begrijp waar je op doelt, maar dan kan je de programmeur wel achterhalen, de vraag is of ze dat hier ook kunnen.
Nee, je kunt alleen achterhalen wie de code in deze repository heeft ingecheckt. Als je een beetje met branches werkt, of grote patches dan is het echt niet meer te achterhalen waar die code exact vandaan komt.
Voordat je code de source in gaat, zou het toch moeten worden gereviewed door peers. Sterker nog, elk element van je software zou moeten worden getest in assurance testing (welk doel heeft dit stuk code).
Een Peer review is zoiets als een spellingscontrole. Duidelijke stijlfouten vis je er nog wel uit, zaken als code coverage kun je wat makkelijker 'afdwingen', maar dan begint het toch wel op te houden.
Als een junior iets bouwt dat gereviewed wordt door een senior en hij/zij vindt wat, dan gebeurd het best nogal eens dat de senior dan 'even' de aanpassing doet. Zeker als je toch met 2 man achter een machine zat. Zo'n check-in is dus ideaal om 'een stukje code' mee te pakken dat er niet thuishoort.

Uiteindelijk komt het allemaal neer op 'vertrouwen'. De enige manier waarop je dit soort zaken 100% kunt uitsluiten is door reviews onafhankelijk te laten uitvoeren door personeel dat geen contact heeft met de originele developers. Praktisch dus een 'schadow'organisatie. Onbetaalbaar en bijna ondoenbaar, want hoe kom je aan reviewers met genoeg kennis die bereid zijn geen code te schrijven. Meestal krijg je dan dat het ene team het andere team controleert, maar ook dit zijn vaak controles, geen volwaardige onderzoeken!

Assurance testing is zo'n tekstboek begrip, leuk voor situaties waarbij geld geen enkele rol speelt (lucht & ruimtevaart), maar het gemiddelde (IT) bedrijf is blij ALS ze een fatsoenlijke testsuite hebben.
Dus jij denkt dat een bedrijfs als Juniper (security appliances) een tekstboek quality assurance er op na houd ?

Ik werk zelf bij een bedrijf waar dit aan de orde van de dag is, kan me niet voorstellen dat dit ons kan gebeuren.
Ik weet het niet, wat ik wel weet dat er genoeg bedrijven zijn waar we op 'vertrouwen' die de boel echt niet op dit niveau hebben of binnenkort krijgen. DigiNotar bijvoorbeeld.

Er zijn bedrijven die hun zaakjes tip top op orde hebben, maar dit is code uit 2012. Dat is in softwaretijd al best een flinke tijd.

Overigens moet je opletten wat je zegt, want je zegt 'kan me niet voorstellen dat dit ons kan gebeuren.' Juniper heeft ZELF dit lek gevonden, je zegt dus eigenlijk dat je zelf nooit lekken zou vinden in je eigen (oude) code. :+
In die zin is dit niet alleen negatief voor Juniper, ze hebben blijkbaar wel wat processen die (laat) dit soort problemen vinden, beter laat dan nooit.
Ik werk zelf bij een bedrijf waar dit aan de orde van de dag is, kan me niet voorstellen dat dit ons kan gebeuren.
Gezien het grote aantal fouten dat dagelijks in prominente softwarepakketten wordt gevonden kan ik niet anders dan concluderen dat het praktisch onmogelijk is om het goed te doen. Zelfs in de ruimtevaart, waar geld geen bezwaar is, is de software het meest kwetsbare punt. Als je dan ook nog te maken hebt met een slimme programmeur die z'n best doet om de backdoor te verbergen dan kan het heel moeilijk zijn om het gat te vinden.
Als je een beetje kan programmeren is er wel wat te verzinnen. Ik heb wel eens een beveiliging tegen "gratis dupliceren" gemaakt dmv het programma te laten crashen als het serienummer van de lokale harde schijf niet klopt. Was niet zo heel ingewikkeld, kwestie van een reeds voor iets anders gebruikte string bewust iets te lang te maken en daar het serienummer in te 'hardcoden' als controle door hier en daar een verdwaald opdrachtje ergens tussen te plaatsen. Het verstoppen van een popen() of system() call (*nix-stijl dan) ofzo die iets evils doet lijkt me niet veel complexer. Als je programma zelf maar genoeg permissies krijgt.
Het is niet onzichtbaar maar iemand die iets dergelijks wil vinden moet eerst de hele bak code doorgronden om aan te tonen welke statements er niet thuishoren in de code.
Ja dat klinkt leuk, maar een ander reviewed toch changes ? Gezien dit niet heel standaard software is en vrij specifiek door je collega erin is gestopt. Nu komen ze er ook bij een codereview achter, snap niet waarom dat toen niet is gezien.
Organisatorisch is dit inderdaad wel grotendeels te voorkomen, maar toch, een enkele programmeur met kwade bedoelingen die gewoon zijn mond houdt kan een eind komen. Voordeel is dat je als medewerker in een team ook de werkwijze van het geheel kan bekijken en een manier kan vinden om iets ongezien naar binnen te sluizen. Als zo iemand de controle-procedure zelf weet te manipuleren of na de controle er alsnog aan kan komen heb je de poppen aan het dansen.
Voordat je code de source in gaat, zou het toch moeten worden gereviewed door peers. Sterker nog, elk element van je software zou moeten worden getest in assurance testing (welk doel heeft dit stuk code).
Dat is dus de kunst van het underhanded programmeren. Het is als smokkelen, je moet de boel zo verstoppen en verpakken dat de controleurs het niet kunnen vinden.
Maar kan een aanvaller dan zelfs via SSH toegang tot de router krijgen als remote SSH helemaal dicht staat? Dus ook als SSH alleen voor het interne netwerk open staat?

Lijkt me niet, toch?
Natuurlijk wel, een backdoor implementeren op deze schaal zit wel iets geavanceerder in elkaar dan hopen op het feit dat iemand SSH op een externe interface open laat staan.

Daarnaast zal er ongetwijfeld een bepaald scenario uitgevoerd moeten worden om de backdoor open te krijgen. Er zal niet permanent een open poort op de externe interface aanwezig zijn.
Dat is inderdaad lelijk dan.
Ik beheer nog 3 junipers met ScreenOS, de rest zit op Junos.
Deze hebben echter versie 6.2.0.r5 dus zo te zien zijn deze niet kwetsbaar.
Wel als er nog een obscure "knock-knock" ingebouwd zit. "Hey, poort 22 wordt aangeklopt. Ik doe niet open" "oh, er wordt in een bepaald patroon vanaf hetzelfde ip-adres aangeklopt" "hello, open sesame".

https://en.wikipedia.org/wiki/Port_knocking
Nee in dit geval kon de aanvaleler er niet in als SSH/Telnet niet open stond:

CVE-2015-7755 (unauthorized access) Mitigation
Restricting management access (e.g. SSH) to only trusted management networks and hosts will help mitigate this issue.

Bron:
https://kb.juniper.net/In...t&id=JSA10713&actp=search
Tja, wie zet dat ook open voor untrusted networks.
Ernstig lek.

Dat de oorsprong van de code niet bekend is kan wijzen op verschillende mogelijke oorzaken:
- Slechte administratie van change logs e.d.
- Moedwillig injecteren van malifide code door partijen die toegang hadden tot de codebase.
- Slechte documentatie of werk door een partner welke code aanleverd voor de software.

Dat gezegd hebben; als je beveiligingssoftware wordt gekraakt of gehackt is het voor een buitenstaander de perfecte wiretap. Deze software heeft vaak een hogere prioriteit op het netwerk en moet als onderdeel van zijn functie in staat zijn om al het inkomende en uitgaande verkeer kunnen inzien. Als diezelfde software is aangetast kunnen buitenstaande partijen zo alles inzien, als het lek ernstig genoeg is kunnen ze ook alle pakketjes aanpassen en manipuleren.

Grappig genoeg heeft de Tech Snap aflevering van deze week juist dit onderdeel als onderwerp.
Of soms heb je van die domme situaties zoals bij m'n huidige werkgever:
  • Migratie van Visual Source Safe naar Team Foundation Server (zonder behoud van historiek/changesets)
  • Team Foundation Server naar een andere Team Foundation Server (zonder behoud van historiek/changesets)
Dit gaat over 15 jaar (spaghetti) code met 10-tallen ontwikkelaars die hier niet meer werken, dusja waarom zaken soms "raar" geďmplementeerd zijn is gewoon een raadsel :/

Dit valt uiteraard onder slechte administratie en beslissingen van hogerhand
Ik neem aan dat ze source control als git gebruiken. Ook al maakt iemand z'n code zo dat het lijkt alsof het geen backdoor is, dan nog kan je achterhalen wie de backdoor er in heeft gezet toch? Of hebben ze meteen even de repo herschreven en het bij iemand anders in de schoenen geschoven?
Dit is echt heel ernstig. Wie als provider Juniper high-end-netwerkapparatuur als Backbonerouter in gebruik heeft, moet jarenlang die Backdoor in de code hebben zitten. Dat betekent dus wel dat veel bedrijven en providers de eerst volgende uren en dagen bezig zullen zijn om de zaak dicht te gooien met een patch. Het NCSC is inmiddels op de hoogte gesteld.
Wie als provider Juniper high-end-netwerkapparatuur als Backbonerouter in gebruik heeft, moet jarenlang die Backdoor in de code hebben zitten.
Nope, het probleem zit alleen in ScreenOS. Dat draait op een bepaalde set oudere firewalls. Juniper heeft in 2004 de fabrikant Netscreen overgenomen. Dit omdat Netscreen een populaire serie firewalls had en Juniper dat nog niet in zijn portfolio had. Na de overname is Juniper redelijk vlot begonnen om de features van het OS dat door Netscreen gebruikt werd, ScreenOS, te porten naar het OS dat Juniper zelf gebruikt, Junos.

Helaas is dat porten nogal met horten en stoten gegaan. Daardoor was Junos op firewalls vaak instabieler dan ScreenOS en bleven veel klanten door draaien op ScreenOS. Gelukkig is de laatste jaren firewalling met Junos met stukken verbeterd en zal ScreenOS de komende vier jaar uitgefaseerd worden.
Wel interessant om te weten, ik vroeg een keer aan Juniper waarom ze de netscreens nog produceerde terwijl ze al jaren lang de SRX lijn voeren. Het antwoord daarop was "omdat overheden graag netscreen nog gebruiken". Samen met dit artikel wordt die opmerking ineens een stuk interessanter.
Hoezo wordt het interessanter? :)
Was je van plan de overheid te hacken? ;) Je weet nu immers dat ze onveilige apparatuur in huis hebben... :P

Of wilde je insinueren dat ze het gebruiken om op anderen te spioneren? ;)
Dat vind ik dan een beetje vergezocht, eigenlijk. :) Mensen moeten niet vergeten dat de overheid zelf ook veel infra heeft, die afhankelijk is van goede beveiliging. Die zijn net zo hard de dupe.
Veelal hebben juist overheden ook hele oude stukken infra liggen die nog speciale hardware nodig hebben. Om verschillende redenen. (Sommige banken ook, trouwens.) Dat er een lek gevonden wordt in iets dat de overheid graag gebruikt, zegt wat dat betreft helemaal niets natuurlijk.
Heel goed dat ze dit openbaar maken, ze gaan keihard met de billen bloot maar geven aan dat ze de privacy van klanten hoog in het vaandel hebben. Ben ik zeer benieuwd of hier een overheid (grote kans), bedrijf of hacker(groep) achter zit.
Mocht het bekend worden, dan zou het mooi zijn als ze dat ook openbaar maken...
Helemaal mee eens, uitstekend gereageerd door Juniper.
Ik blijf toch lievereen een kale Linux met openswan gebruiken: is veel goedkoper en doordat het opensource is, weet je toch wat beter wat je hebt. Daarmee kun je vast geen honderden parallelle VPN sessies onderhouden, maar dat hoef ik gelukkig ook niet.
Hmm, goedkoper OK, maar zeker ben je ook niet.

Is het al bekend of OpenSSL Heartbleed een intentionele bug was? Dat werd indertijd gesuggereerd, en alle reviewers hebben er jarenlang overheen gekeken.
Wat je ook gebruikt, het is nooit 100% veilig.
Overheid (en dan de Amerikaanse) maakt imho nog het meeste kans. Geloof dat er met Cisco zo ooit ook eens een incident is geweest waarbij de NSA backdoors had achtergelaten. Kwam naar boven in de tijd dat de Amerikaanse overheid zat te roepen dat volgens hen in Chinese apparatuur backdoors zouden zitten (wat nooit bewezen is).
Inderdaad, vroeg mijzelf ook al af wat de relatie met FEEDTHROUGH en andere NSA implants was. Tot op heden nooit bewezen, maar misschien is dit wel gerelateerd?!

Zie de voor meer info NSA Ant Catalog:
https://nsa.gov1.info/dni/nsa-ant-catalog/firewalls/
Overigens gaat dus over ALLE juniper firewall/vpn oplossingen die ScreenOS draaien niet alleen over Software firewall/vpn (zoals de titel doet vermoeden)
Heb zelf ook besloten de titel aan te passen, kon de nodige info er idd niet in kwijt
Jup, maar zoals de titel er origine stond zou je dat wel vermoeden. Ik vind je reactie vrij agressief over komen, maar wellicht Is dat het missen van de nuances via internet :)
Volgens mij gaat het hier over obsolete firewalls en VPN kit, maw het oude Netscreen spul en niks hiervan is vandaag de dag nog te koop. Het gaat dus niet om de huidige product set (ook niet om de oudere M/T/ERX series routers trouwens). Goed dat ze het toch melden. Geeft aan dat Juniper hier aandacht aan besteedt.
http://junipershop.eu/shop/ssg-series/ssg-5/

nog steeds te koop hoor :) nog los van hoeveel er wel niet in het veld staan
Die webshop in Eindhoven verkoopt nog wat oude voorraad. Zo zijn er duizenden winkeltjes. ;)
De Juniper corporate site vermeldt ze niet op de 'security products list': http://www.juniper.net/us/en/products-services/security/
Maar er staan er zeker nog veel in het veld - daar heb je gelijk in. Hopelijk hebben organisaties welke extra gevoelige informatie verwerken een fatsoenlijk upgrade proces... Up-to-date blijven is belangrijk.

Toevoeging: obsolesence voor de laatste SSG's is aangekondigd, maar formeel heb je gelijk (nog eventjes dan). :)
http://www.juniper.net/support/eol/ns_hw.html

[Reactie gewijzigd door JozB op 19 december 2015 19:15]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True