Cisco en Fortinet brengen waarschuwingen uit voor NSA-exploits

Netwerkapparatuurbedrijven Cisco en Fortinet hebben waarschuwingen uitgebracht voor kwetsbaarheden die gebruikt worden in onlangs gepubliceerde exploits. Daarnaast bevestigden ex-NSA-medewerkers de echtheid van de exploits.

De Shadowbrokers, de groepering die verantwoordelijk is voor de publicatie, claimt dat de exploits afkomstig zijn van de Equation Group, die in verband staat met de Amerikaanse veiligheidsdienst NSA. Cisco en Fortinet hebben nu waarschuwingen uitgebracht voor de in de exploits gebruikte kwetsbaarheden in hun software. Bij Cisco gaat het om lekken in ASA-apparaten en Fortinet heeft een waarschuwing uitgebracht voor zijn FortiGate-firmware. Daarmee bevestigen de bedrijven de echtheid van de exploits, die eerder deze week al door onderzoekers op producten van de bedrijven waren getest. Bij publicatie door de Shadowbrokers was niet meteen duidelijk of de exploits echt waren.

Cisco zegt dat een van de twee gevonden lekken al in 2011 is opgelost. Daarbij gaat het om een lek dat voorkomt in ASA-producten met software versie 8.4(1) en lager. De kwetsbaarheid maakte het voor een lokale en geauthenticeerde aanvaller mogelijk om willekeurige code uit te voeren. Het andere lek, met kenmerk cve-2016-6366, is wel nieuw, zo waarschuwt Cisco. De kwetsbaarheid is aanwezig in het Simple Network Management-protocol van de ASA-software en treft ook PIX-firewalls. Het gaat om een buffer overflow, waardoor een aanvaller code kan uitvoeren en een systeem kan overnemen. Cisco heeft signatures uitgebracht waarmee dit gedetecteerd kan worden.

Het lek in de Fortinet-firmware betreft ook een buffer overflow. Door een speciaal http-verzoek te sturen, kan een aanvaller een apparaat met deze firmware overnemen. Fortinet stelt dat versie 5 van zijn firmware niet kwetsbaar is en dat het lek voorkomt in firmware met versie 4 en lager, die uitgekomen is vóór augustus 2012. In de bestanden van de Shadowbrokers zijn ook exploits voor Juniper-producten te vinden. Dat bedrijf heeft tot nu toe echter nog geen waarschuwing uitgebracht.

Ex-medewerkers van de TAO-afdeling van de NSA hebben aan The Washington Post bevestigd dat het inderdaad gaat om exploits van de NSA. "Van wat ik heb gezien, bestaat er geen twijfel dat de bestanden echt zijn", zo stelt een van hen tegenover de krant. Ook beveiligingsbedrijf Kaspersky toonde deze week aan dat er een duidelijke link is tussen de uitgelekte bestanden en de Equation Group. Deze was eerder al door het bedrijf in kaart gebracht.

De Shadowbrokers claimen 'nog betere' bestanden te veilen of te verkopen voor een bedrag van 1 miljoen bitcoin. Daarover zegt een beveiligingsonderzoeker tegen The Washington Post dat de veiling 'een grote grap is, die bedoeld is om af te leiden'. Hij voegt daaraan toe dat geldstromen via Bitcoin zo eenvoudig te volgen zijn dat het witwassen van een zodanig grote som 'waanzin' is. De NSA heeft nog geen reactie gegeven op het uitlekken van de bestanden.

Reacties (62)

Een blog over de betreffende Cisco ASA kwetsbaarheid: https://xorcatt.wordpress...ool-leak-extrabacon-demo/
Om de kwetsbaarheid uit te voeren heb je enkel SNMP read-access nodig en dient de SSH en/of telnet server bereikbaar te zijn. SNMP Read access kan al verkregen worden door bijvoorbeeld gebruik te maken van de standaard SNMP community "Public" welke zelden wordt gewijzigd.
Door het sturen van het SNMP commando wordt het "pass-disable" commando uitgevoerd waarna de aanvaller kan inloggen zonder wachtwoord. Hierdoor verkrijgt hij voledige controle over het apparaat.

Je hebt als netwerkbeheer al behoorlijk gefaald. Software uit 2011 en dan ook SSH en/of telnet open voor de wereld. Die laatste twee staan op een ASA standaard dicht namelijk.

En toch gebeurt het... helaas genoeg.
SNMP community-string public >> want het is makkelijk en tja het is 'maar' snmp
SSH 0.0.0.0 0.0.0.0 outside >> want ik moet er wel vanaf overal bij

En er zijn ook knuppels die gewoon geen enable password instellen, dus je fietst er zo in als je verbind met zo'n tool

Exploits zijn het gevolg van luie mensen die geen (diepgaande) kennis van zaken hebben

[Reactie gewijzigd door Barreljan op 18 augustus 2016 12:26]

Waarom mensen lui noemen? Je kunt als initiatiefnemer dan nooit meer een project beginnen omdat je moeilijk alles kan weten.

Genoeg "beheerders" bij kleine bedrijven die eigenlijk een andere functie hebben, maar IT erbij doen omdat ze weten hoe ze het moeten spellen.
Die zijn langzamerhand de afgelopen jaren overspoeld met steeds meer IT taken: ze moeten de desktops onderhouden, de server(s), het netwerk, de mailserver en oh ja, er was ook nog iets met een internet-toegang. Maar daar had een dozenschuiver toch al een firewall voor gezet, 5 jaar geleden, en die doet het toch nog prima?

Kleine bedrijven hebben meestal ook geen grote budgetten voor IT gerelateerde zaken, en beveiliging is dan ongeveer het laatste onderdeel waar men geld aan uit wil geven. Gevolg is dat bij inhuur van derden de nadruk meestal ligt op het functioneren van het netwerk, inhuur voor maatapplicaties, de website en/of de mailserver. De firewall(s) die er staan... ondergeschoven kindje!

En van beheerders van wie de bazen vinden dat IT maar een kostenpost is die zo klein mogelijk gehouden moet worden. Degelijk ontwerpen en configureren van je IT infrastructuur (netwerk is er een belangrijk onderdeel van) kost tijd, dus geld. Een "box uit de doos en in het rek" mentaliteit is daar vaak het gevolg van. En dat is... gevaarlijk.

Ja want het artikel lezen houden we hier bij Tweakers niet van he?

Cisco zegt dat een van de twee gevonden lekken al in 2011 is opgelost. ... Het andere lek, met kenmerk cve-2016-6366, is wel nieuw, zo waarschuwt Cisco.

Punt is, het (gratis) pakket bevat dus zowel oude als nieuwe exploits, en dan zal het betaalde pakket waarschijnlijk ook vooral nieuwe exploits bevatten.

---

De Shadowbrokers claimen 'nog betere' bestanden te veilen of te verkopen voor een bedrag van 1 miljoen bitcoin. Daarover zegt een beveiligingsonderzoeker tegen The Washington Post dat de veiling 'een grote grap is, die bedoeld is om af te leiden'. Hij voegt daaraan toe dat geldstromen via Bitcoin zo eenvoudig te volgen zijn dat het witwassen van een zodanig grote som 'waanzin' is.

Sorry maar waar is het bewijs? we hebben met zn alleen ook gewacht tot er bewijs was dat het echt was, laat deze 'beveiligingsonderzoeker' maar aantonen dat het niet echt is.

En wie zegt dat de aanval van buitenaf moet gebeuren... eerst gewoon een Windows PC (al dan niet in een managements VLAN) infecteren in het netwerk en dan kan je van daaruit gewoon extern afgeschermde devices aanvallen.

Maar nog steeds software uit 2011. Dat is wel zeker een probleem.

Ik vind het wel grappig dat men steeds spreekt over de Equation Group. Volgens mij bestaan die namelijk helemaal niet en is de Equation Group gewoon de NSA zelf.

De fabrikanten van netwerk apparatuur moeten hun producten veel beter beveiligen met digitale handtekeningen en fysieke read / write schakelaars zodat software zelf niet de firmware kan overschrijven tenzij een schakelaar (tijdelijk) wordt overgezet. Tevens moet de C software gebruik gaan maken van garbage collection.

[Reactie gewijzigd door ArtGod op 18 augustus 2016 11:12]

Ik denk dat iets als https://www.rust-lang.org/ eerder in dergelijke omgevingen tractie zal krijgen dan een GC.

Ik heb Rust een keer bekeken en er blijken twee soorten memory management in te zitten: handmatig met smart pointers en automatisch met garbage collection.

Smart pointers heb je in C++ ook en garbage collection kan ook met C / C++. Dus het nut van een nieuwe taal ontgaat mij.

[Reactie gewijzigd door ArtGod op 18 augustus 2016 12:52]

C++ smart pointers zijn niet hetzelfde en de ontwikkeling van de taal is gestart voordat het in C++ zat. Rust heeft geen garbage collection meer, wel nog optionele reference counting. De focus van de taal is steeds meer low-level geworden.

Ik wist het verschil en vooral de compile time checking is krachtig maar wezenlijk het enige verschil.

Ik zou liever zien dat men compile time smart pointers in C++ toevoegt dan weer een hele nieuwe taal moeten leren.

Ja, ik ben feitelijk niet meer van plan om veel nieuwe talen te leren die veel afwijken van C / C++ / C# / Java / Javascript (dus zeg maar C-achtige talen). Ik vind het vaak ook onnodig want je kan dezelfde concepten als in Rust ook in talen zoals C# / C++ / Java inbouwen.

Tevens moet de C software gebruik gaan maken van garbage collection.

C word juist vaak gebruikt omdat het geen garbage collection heeft.

Dat is ook vaak de bron van het kwaad.

Voor sommige dingen zoals het besturingssysteem kan je vaak geen garbage collection gebruiken, maar voor netwerk software zeker wel.

[Reactie gewijzigd door ArtGod op 18 augustus 2016 12:53]

Garbage collection is voor luie programmeurs die geen destructors willen schrijven en de boel achter hun kont aan op willen ruimen Dat de meeste moderne talen een GC hebben wil niet zeggen dat dit echt geweldig is en altijd optimaal werkt.

Hehehe, nee. Bij grote programma's geef je zoveel pointers door dat je op het laatst niet meer weet wie de 'delete' moet aanroepen en wanneer. Tuurlijk in een C programma van een paar honder regels kom ik er ook makkelijk uit, maar als je miljoenen regels code moet onderhouden die niet door jou geschreven zijn dan krijg je ongelukken. Laat computers doen waar ze goed in zijn en mensen waar zij goed in zijn.

Het is geweldig want het verhoogt de productiviteit van de ontwikkelaars en zorgt voor betrouwbaardere software.

[Reactie gewijzigd door ArtGod op 18 augustus 2016 18:24]

maar als je miljoenen regels code moet onderhouden die niet door jou geschreven zijn dan krijg je ongelukken

Dat is nou net het punt Als die mensen hun code ook niet netjes schrijven de boel achter hun kont opruimen dan krijg je problemen inderdaad.

Tuurlijk, ik ben het met je eens dat GC de productiviteit verhoogt hoor maar je hebt nog steeds kans op memory leaks en andere nare bugs. Door uitvoerig testen krijg je betrouwbaardere software

Wat jij als voorbeeld geeft zijn allemaal hard real time besturingen en die zijn juist niet geschikt voor GC. De rest wel en dat is veel, veel meer software.

Juist bij dat soort zaken zie ik wel bijvoorbeeld Rust lang populair worden. Omdat dit soort issue met betrekking tot overflow exploits gereduceerd kunnen worden. Bare metal, of met een kleine OS tussenlaag met Rust lang waar de memory leaks en overflows zwaar gereduceerd worden met veel moderne functionaliteiten. Het moet zich alleen eerst nog bewijzen voordat je het in een ziekenhuis gaat vinden. Maar betreffende netwerk apparatuur zou dat veel beter zijn.

fysieke read / write schakelaars

Die zullen dan dus altijd in 'write' staan, omdat de netwerkbeheerder bij problemen anders geen remote fix / update kan uitvoeren.

Tevens moet de C software gebruik gaan maken van garbage collection

En hoe helpt dat bij dit soort problemen?
Zaken als buffer overflows kunnen ook in een GC omgeving.
Groot probleem van GC is de latency problemen die het veroorzaakt en de veel grotere memory foot print. Beiden niet leuk in een realtime omgeving.

Stupiditeit met implementatie, zoals Twekzor schrijft 'Door het sturen van het SNMP commando wordt het "pass-disable" commando uitgevoerd waarna de aanvaller kan inloggen zonder wachtwoord' kan natuurlijk in iedere programeertaal...

edit: ontkenning toegevoegd aan eerste zin.

[Reactie gewijzigd door PPie op 18 augustus 2016 17:44]

Een voordeel van een taal met een GC ivm geheugengebruik is natuurlijk dat een hogere taal er vaak van uit mag gaan dat geheugen niet blijft staan waar het stond, en zo kan men geheugen fragmentatie automatisch vermijden. Dat is iets waar we in C en C++ vaak van die magazine allocators voor in elkaar moeten steken.

Ik zou eerder zeggen dat het hoge geheugengebruik van software die geschreven is in VM-talen ligt aan het manneke tussen de stoel en het scherm. Je kan bv. in C# heel precies de sizeof value-types (structs) en reference-types (classen) bepalen door te weten wat je doet. Dus je weet ook vrij goed hoe groot die dingen zullen zijn per stuk in het geheugen. Als je voorts goed gebruik maakt van dingen zoals using(o){} en op I/O objecten netjes wel die Close() methods uitvoert (wat ik vaak zag dat niet gebeurde), en als je er wat op let dat je die value types niet constant boxed en unboxed naar reference types in de body van loopjes, valt dat nog wel mee (met bv. C#).

Het probleem is dat veel .NET programmeurs hun kennis van zaken niet echt meevalt. Dat boekje waarin de basics van C# stonden hebben ze te vaak nauwelijks gelezen. En dan koden en copypasten ze maar wat tot het werkt. En dan maar de k,thx,done en shippit mentaliteit he. Testen da moet nie. Geheugengebruik is nie belangrijk. Azure zal het wel oplossen. En zo.

De programmeertaal en Microsoft's frameworks maken het wel allemaal prima mogelijk.

Mijn opmerking over het hoge geheugengebruik van een GC was meer bedoeld richting het inherente gebruik van een GC oplossing:
Volgens een referentie op de Wiki heb je tot 5 x zoveel geheugen nodig voor een goede performance:

In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower.

Dat is een reden dat Apple geen GC op iOS heeft en het heeft depricated voor macOS.
Volgens Linkje lijkt het een goede keuze. Daar wordt gesproken over 4 tot 8 maal zoveel RAM geheugen beschikbaar hebben dan nodig.
Nadeel van meer geheugen (dat alleen maar gebruikt wordt om een GC te laten performen), is dat het meer energie gebruikt, naast het hogere energieverbruik van de GC zelf ten opzichte van meer expliciet memory management.

Garbage collectors gaan niet goed samen met het werken met pointers. Vandaar dat C# zo'n unsafe{} blokken heeft. Daarmee werken is nu net wat je vaak in C doet en ook voor allerlei reden wil doen. Voorts gebruik je een lagere taal als C vaak voor bv. real-time en embedded, waar je heel veel controle wil over het moment waarop je process interrupted wordt en vooral wanneer niet. Garbage collectors leggen je process nogal vaak lam om eens eventjes naar garbage te gaan zoeken. Dat is niet echt ideaal wanneer het landingsgestel van het vliegtuig er uit moet of de airbag opgeblazen moet worden.

Ik vind het beter dat zij die een garbage collector nodig hebben ook een hogere programmeertaal en/of omgeving gebruiken. In D vind ik het bv. mooi opgelost.

In C++ heb ne met typen die RAII ondersteunen ook heel wat mogelijkheden vrij veel uit handen van de programmeur te halen. Bv. in Qt heb je QPointer, QScopedPointer en QSharedPointer die erg handig zijn om aggregatie, compositie en shared composities mee te bouwen die redelijk doen wat je verwacht.

Dat weet ik allemaal wel maar heel veel programma's die geen real time nodig hebben doen ook hun eigen geheugen management terwijl je dat veel beter door een garbage collector kan laten doen. Vaak zijn dit hele grote programma's waar het voor een mens heel moeilijk zo niet onmogelijk om bij te houden waar een pointer moet worden vrijgegeven. Je krijgt dan memory leaks, dangling pointers of use after free errors.

Waar real time niet nodig is daar vind ik dat C++ programma's gewoon GC moeten gebruiken.

Als je GC wil samen met wat we typisch met C++ doen, dan zou ik veel eerder gewoon naar D kijken. Garbage collectors met C++ combineren werkt helaas te vaak niet goed. Bv. de meeste libraries die je samen met C++ gebruikt zijn niet voorzien op Boehm. RAII concepten en van die dingen zoals smartpointers bv. dan weer wel. In C, wat vaak met bv. GLib gedaan wordt, heb je dan weer typisch reference counting voor bv. GObject en ook vele andere typen.

Bv. om die dangling pointers te vermijden (typisch bij een aggregatie relatie), heb je in Qt het type QPointer<T>. Voor een compositie relatie heb je er QScopedPointer<T>. Als je gelijkaardige dingen wil in C met GObject, heb je natuurlijk Vala als programmeertaal die GObject C code genereert waarbij de meeste geheugen-deallocatie-dingen met een soort van smartpointer opgelost worden (die je weak kan maken indien nodig).

1 miljoen btc's mixen met een bitmixer zou aardig wat problemen opleveren om die te volgen hoor. Doe je het daarna nog een keer dan is het helemaal hoofdpijn werk. Ok, ze zijn gemiddeld 500 tot 1000 btc's aan fees kwijt, maar geloof mij, "een grote grap" is het niet voor de digitale forensische onderzoeker.

Komen de ontvangers uit het Oosten of zo, wat wil je dan doen?

Russische staatshackers, ga die maar eens vervolgen >.<

Je bedoelt de overheid van VS. Even heel simpel gesteld dus momenteel de grootste terroristische organisatie die er bestaat en met ondermeer Stuxnet, Duqu, Flame veroorzaker. van schade die wereldwijd in de miljarden is gaan lopen ondertussen wijzend naar China en Rusland als de daders.

Sterker nog, het bevestigd dat de VS hiermee in feite een aanval heeft uitgevoerd op de infrastructuur in Iran en het (volgens de eigen definities van de VS) de oorlog heeft verklaard.

[Reactie gewijzigd door Anoniem: 14124 op 18 augustus 2016 14:05]

Je hebt nucleaire inspecties. Moeten we nu ook ICT inspecties uitvoeren bij landen?

De NSA ga die maar eens vervolgen >.<

Er gaan nu al geruchten dat het een interne NSA medewerker is die deze spullen heeft gelekt. Als reden wordt aangevoerd dat bepaalde folders en scripts nooit op een staging server worden geplaatst en daardoor ook niet 'gestolen' kunnen zijn.
Maar zoals altijd is het zeer moeilijk om te bepalen wat echt, nep, diplomatiek of contra-spionage is. Want stel dat het echt een intern lek is, waarom lek je dan spullen van >3jr oud?

Maar dat kan niet. Ze zeiden direct dat Rusland de schuldige was. En USA zou echt niet liegen tegen ons toch?

Het ligt nogal wat genuanceerder dan dat, het gaat hier over een internationale groep hackers die voor meerdere overheden tools maakt, die vervolgens over de hele wereld ingezet worden om elkaar te bespioneren etc.

Ze werken ook met de NSA, een aangezien die partij al vaker met dit soort zaken in het nieuws geweest is de laatste jaren pakt iedere nieuws site dit op als 'onderdeel van NSA' ofzo, maar dat is dus niet waar.

Het zijn echter ook geen 'Russische staatshackers', dat zijn mensen die de tools van deze groepering gebruiken.

1 miljoen btc's mixen met een bitmixer zou aardig wat problemen opleveren om die te volgen hoor. Doe je het daarna nog een keer dan is het helemaal hoofdpijn werk. Ok, ze zijn gemiddeld 500 tot 1000 btc's aan fees kwijt, maar geloof mij, "een grote grap" is het niet voor de digitale forensische onderzoeker.

Komen de ontvangers uit het Oosten of zo, wat wil je dan doen?

Ik ben niet zo thuis in die wereld, hoe werkt dat mixen dan? Ik snap het concept wel van dat je andere coins krijgt dan je origineel had, maar vervolgens heb je toch volstrekt willekeurige coins die potentieel ook gekoppeld zijn aan criminele transacties? Des te meer degenen die vervolgens jouw coins krijgen.

Een mixer werk als een grote zak met allemaal BTC munten. Je mag je eigen munten er bij gooien en dan voor het zelfde bedrag, min service kosten, weer munten terug pakken. En bij bitcoins kan je dan ook nog bepalen hoe je ze terug krijgt. Hoeveel wallets gebruik je, welk bedrag in welke wallet. Dus als bitcoins door zo'n mixer zijn geweest zijn ze nergens meer aan gelinkt.
Is net als jij bij een winkel wissel geld terug krijgt wat bij een bank overval is buitgemaakt. Aan jouw hebben ze weinig in dat geval, aangezien je negens van af wist. Alleen hier heb je dan een winkel die alleen wissel geld terug als dienst verkoopt. Maar je krijgt iig munten terug waar jij geen kennis van hebt hoe waar of wat de voorgeschiedenis is.

Ja tot zover snap ik het wel maar dan nog lijkt me dat link, uiteindelijk heb je toch gestolen/crimineel verkregen bitcoins in je handen en die historie is nog steeds te zien. Ook vraag ik me af of zo'n mixer niet aansprakelijk gesteld kan worden.

Daarnaast las ik dat je een uniek mixer id krijgt zodat je je eigen munten niet terugkrijgt. Dat lijkt me ook een probleem voor je anonimiteit want ergens is dan toch geregistreerd dat jouw id hangt aan vorige munten/transacties. Dus de volgende keer dat je dat id gebruikt (zelfs ver in de toekomst) en ondertussen die bitmixer server compromised is, dan kan je toch gepakt worden?

Ik neem aan dat dat unieke ID van de mixer voor éénmalig gebruik is. Zodat de mixer kan zorgen dat je niet direct je eigen munten terug krijgt. En ik neem aan dat de mix service aanbieders die gegevens vernietigen na de wissel. Anders maken zich wel een doelwit voor veel partijen.
Maar kom je een dag/week/maand/jaar later dan zou je in theorie prima je eigen munt terug kunnen krijgen van je vorige wissel. Alleen al omdat iemand anders die die BTC in handen heeft gekregen hem ook weer door de mixer haalt.
En als de mixer server gecompromitteerd is kan men natuurlijk altijd een mooie log bij houden die precies registreert naar welke wallets het geld van één wissel actie allemaal heen is gegaan. Daar heb je geen uniek ID wat langer dan 1 wissel handeling gebruikt word voor nodig. Inzage in de acties van de mixer is alles wat men moet weten.

Ik neem aan dat dat unieke ID van de mixer voor éénmalig gebruik is. Zodat de mixer kan zorgen dat je niet direct je eigen munten terug krijgt. En ik neem aan dat de mix service aanbieders die gegevens vernietigen na de wissel. Anders maken zich wel een doelwit voor veel partijen.

Dat zou ik ook denken. Maar op https://bitmixer.io/how.html staat het volgende:

All of this may seem super complicated, so let’s get down to the meat and bone of it. BitMixer has a huge reserve of Bitcoins already in its system. A user sends us their BTC and we cap it onto the end of our reserve chain. We then pay the amount of what was purchased from the beginning of our reserve.

This method of mixing means that you do not have to wait for other customers – coins already mixed are instantly available.

The problem with this is that the user’s coins may still be in our reserve. Meaning, on the second transaction, there could be a possibility of the user receiving the same BTC s/he had originally had. This is why we created a generator referred to as “bitcode.”

Using the BitMixer code means that a user’s previous coins will not be used in further mixing operations. Our problem is solved – every user continues to remain anonymous and private.

Het is niet heel duidelijk opgeschreven maar het lijkt er hier toch op dat je ook een volgende keer je eigen coins niet terug krijgt. Of lees ik dit nou verkeerd?

[Reactie gewijzigd door Argantonis op 20 augustus 2016 05:53]

Tja, en dan staat er dit weer bij the FAQ:
"What logs are kept?
Absolutely no logs or personally identifying information are kept regarding your use of the Bitmixer service. All logs are permanently removed from both our website database and from our Bitcoin wallet after your coins have been transferred out of our reserve. All forwarding entries are removed after 24 hours."

Maar over die bitcode zeggen ze verder niks, geen garanties en het zou niet de eerste keer zijn dat dergelijke sites gehack worden of zelf er mee vandoor gaan.

Het is wel van de zotte.

Onschendbaar waant de NSA zich. Ik vraag mij of er nog sancties zullen volgen.

Het zijn gewoon een zooitje criminelen van de eerste plank. Moet jij eens als burgertje de router van de buurman hacken. Dan ben je de sjaak als ze je pakken. Maar hun gaan maar door en onze regeringen heulen maar met ze verder. Zonder enige schaamte of verantwoordelijkheids gevoel.

Het zijn gewoon een zooitje criminelen van de eerste plank. Moet jij eens als burgertje de router van de buurman hacken. Dan ben je de sjaak als ze je pakken. Maar hun gaan maar door en onze regeringen heulen maar met ze verder. Zonder enige schaamte of verantwoordelijkheids gevoel.

Ik ben ook niet te spreken over de NSA maar het is natuurlijk wel iets anders of je daadwerkelijk hackt of er een tool voor schrijft. Omdat inbraak verboden is, is het nog niet verboden om een lockpickset te maken.

Eens, als ze die niet gebruiken maar denk je dat ze voor de lol die gemaakt hebben?

Eens, als ze die niet gebruiken maar denk je dat ze voor de lol die gemaakt hebben?

Dat denk ik niet, maar dat kan je wel van alles zeggen dan. In principe is de NSA onderdeel van de overheid daar dus criminelen in de letterlijke zin van het woord kunnen ze al niet zijn. Als zo'n agency het dan in zou zetten om criminelen te pakken zou het niet eens zo slecht zijn.

Helaas kennen we de NSA anders... maar ik vind dat we dát foute gedrag van ze moeten bestraffen, niet het maken van tools.

Dus als ik een tool schrijf om buurmans router te hacken dan mag het wel?

Ik geloof dat ik dan als burger net zo hard hang hoor.

Niet zolang jij die tool niet gebruikt met als doel om in te breken bij je buurman.

Als jij een virus schijft en dat virus op github zet: dat mag en wordt gedaan. Informatie over hoe je routers kan hacken wordt ook op publieke mailing lijsten geplaatst. Er worden ook publiek presentaties over gegeven.

Wat niet toegestaan is is de computervredebreuk zelf. Het onderzoek er naar is op zichzelf niet illegaal.

Maar daar gaat het niet over. We weten allemaal dat de NSA het wel doet en er gewoon mee wegkomt en onze regering van de gejatte informatie gebruik maakt.

Maar als jij het als simpele burger (of zoals Charles van de UK ons noemt "bloody people") doet, dan hang je gewoon. Zonder enige schaamte!

Een overheid die zich zelf niet aan haar eigen regels houdt is inderdaad een probleem.

We zien nb. ook zware inbreuken door rechercheurs in Benelux die dan ook nog eens niet aangekaard worden door Comité P en/of I. Dus veel goede hoop heb ik niet voor de West-Europese democratie.

Maarja, een empire in verval doet rare sprongen. De geschiedenis zal hard zijn.

Het Kaspersky-stuk zag ik op Twitter afgebrand worden omdat het zogenaamde bewijs een normale compileroptimalisatie zou zijn: https://news.ycombinator.com/item?id=12301406

"Netwerkapparatuurbedrijven Cisco en Fortinet hebben waarschuwingen uitgebracht voor kwetsbaarheden die gebruikt worden in onlangs gepubliceerde exploits."

Oh?! Dus nu het uitkomt dat ze jaren lang samengeheuld hebben met de NSA, brengt Cisco plotseling een 'waarschuwing' uit voor deze exploits?!

Ja, omdat de exploits openbaar zijn gemaakt, dus niet exclusief voor NSA toegankelijk.

"Ja, omdat de exploits openbaar zijn gemaakt, dus niet exclusief voor NSA toegankelijk."

Ja, dat begrijp ik. Maar als ze echt iets om hun klanten gaven, dan hadden ze meteen moeten zeggen "Sorry, maar we hebben een backdoor ingebouwd, zodat onze Amerikaanse NSA jullie allemaal kan bespioneren." Met zo'n bedrijf doe ik liever geen zaken.

Daarover zegt een beveiligingsonderzoeker tegen The Washington Post dat de veiling 'een grote grap is, die bedoeld is om af te leiden'.

Let even op: als een artikel verwijst naar een 'beveiligingsonderzoeker' moet je altijd zeer kritisch gaan lezen en je afvragen of er uberhaubt iets van klopt.
Beveiligingsonderzoekers zijn mensen die betaald worden om toffe cyberverhalen (voor hun bedrijf) te publiceren. Feitelijk zijn het marketeers.

Ik wil niet beweren dat alle security researchers onzin uitkramen, maar 99% doet dit wel. Het gaat hier om clickbait generen of naamsbekendheid. Deze 'onderzoeker' roept verderop in het artikel dat het heel makkelijk is om bitcoins te traceren, wat natuurlijk weer complete onzin is.

Ik ben totaal niet thuis in de Bitcoin-wereld, maar Bitcoin houdt toch alle transactiedata bij? Waarom zou het dan moeilijk zijn om Bitcoins te traceren?

Wanneer jij bitcoins op een exchange zet, deze in een grote wallet belanden en je uit een andere wallet in een andere coinsoort weer een (bijna) gelijk bedrag kan ophalen ben je de originele persoon al gauw kwijt. Er bestaan hele diensten om (vaak illegaal) verkregen bitcoins te anonimiseren.

De bestanden

*Disclaimer: deze link is natuurlijk bedoeld voor geïnteresseerde/netwerk beheerders die willen weten of hun Cisco/Fortinet hardware veilig is, en niet voor mensen met foute bedoelingen.

Ik vind het een onduidelijk artikel. Te lang, vreemde opbouw, weinig structuur, teveel onbekende afkortingen en hyperlinks. (niet elke tweaker is een netwerkspecialist.)