Uitgaande firewall, uitgaande firewall, had ik al gezegt dat je een uitgande firewall moet hebben?

Vooral dit stukje vind ik interessant:


Nu zeg ik niet dat je dynamic Libraries moet weghalen, zoals boven genoemd, maar de laatste opmerking over SELinux (en misschien ook andere distro's?) vind ik zeer interessant. Dan zou de Boolean deny_ptrace aangezet moeten worden. Dan zou deze inbraakmethode dus niet meer werken.

Op de website Fedora Project kom ik het volgende tegen:


Dus de opdracht in de terminal setsebool -P deny_ptrace 1 zet de Boolean aan, waardoor de aanval is te stoppen.
https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace

Let op! Dit alles is natuurlijk wel op eigen risico!

Ik heb de overtuiging dat het verspreiden van de gelekte informatie het fout gebruik niet doet afnemen. Maar als informatie die niet gelekt had mogen worden toch gelekt is is het een illusie te denken dat het stoppen van die een paar bronnen je problemen weg neemt. Als wikileaks of shadow server de informatie hebben zonder het te publiceren kunnen heel veel anderen er waarschijnlijk ook bij zonder dat jij dat weet.

Het uiteindelijke probleem is dat informatie die tegen jou ingezet kan worden in verkeerde handen is gekomen. Dat is onomkeerbaar en is al meerdere keren gebeurt. Zonder het lekken had je het probleem ook gehad maar had je het niet snel gemerkt. Veel van de problemen lijken ook te voorkomen met goede beveiliging. Dus waar heb je precies last van? Het gebrek aan beveiliging misschien?

De gelekte informatie bewijst herhaaldelijk dat het effectiever is om voor beveiliging te kiezen in plaats van hopen dat er achteraf een oplossing komt.

Echt, besef je wel wat je schrijft????

Klokkenluiders moeten offline en de makers/gebruikers van dit soort tools (die gevonden exploits onder de pet proberen te houden en gebruiken om de bevolking te bespioneren) noem jij een ander woord woor vrouwelijk geslachtsdeel???

Ik zou het willen omdraaien!

Het zijn onmisbare libraries, het is misschien wel zo dat de tool "simpelweg" niet werkt zonder een van hen, maar dat betekent niet zo veel als je niet simpelweg zo'n library kan verwijderen zonder je hele systeem onbruikbaar te maken.

Het gaat om respectievelijk het deflate-compressiealgoritme, POSIX-threading en de standaard C-library. De laatste twee zitten bij Debian in hetzelfde pakket (libc6) en je kan je systeem al niet starten zonder, alle beschikbare init-systemen zijn ervan afhankelijk. Van de eerste zijn systemd, apache2, ssh, python2/3, Xorg en nog veel meer afhankelijk, en niet te vergeten de package management tools.

Welk risico? ptrace is process tracing dat je gebruikt als je een applicatie wilt debuggen. Als je dat uitzet maakt dat weinig verschil voor functionaliteit. Ik zou het wel documenteren. Documenteren is sowieso noodzaak bij hardening.

"De Boolean" bestaat niet, bolean is de soortnaam van variabelen die je op true (1) of false (0) kan zetten. De variabele waar het om gaat is deny_ptrace.


Terecht, want shared libraries moet je niet weghalen, want dan werken waarschijnlijk meerdere applicaties niet meer. Onbegrijpelijk dat een researcher zoiets noemt. Als je de applicatie wilt uitzetten, schakel dan de applicatie (OpenSSH) zelf uit en rommel niet met gedeelde libraries. Waarschijnlijk zal vervangen van OpenSSH voor een alternatief beter zijn dan verwijderen of uitschakelen, want dan kan je niet meer op afstand toegang verkrijgen. Er zijn overigens ook andere oplossingen om toegang te verkrijgen, zoals remote access hardware modules die toestaan te werken alsof je ter plekke inlogt. Hardware en software alternatieven kunnen ook kwetsbaar zijn.

Je kunt dus beter je kop in het zand steken?

Dat is ook iedere keer gebeurt. Wikileaks heeft uitgebreid contact met Microsoft gehad over de Samba exploit.

Prachtig lek voor:
- al die iot apparatuur die nooit bijgewerkt worden.
- al die machines due iets specifieks draaien waardoor er niets veranderd mag worden.
Het bekende verhaal maar wie gaat het nu oplossen?

Dit zijn 2 applicaties waarbij 1 (BothanSpy) specifiek voor een windows implementatie is van ssh (xshell) dus, niks met IoT te maken.

De tweede is alleen voor actieve ssh-verbindingen. En er moet al op een andere manier toegang verkregen zijn tot het doel.
Waarbij er ook de toestemming moet zijn om zelf commando's uit te voeren. een IoT device gebruikt als het goed is niet een continue ssh verbinding en heeft dus ook hier niets mee te maken. Machines die niet mogen veranderen mogen ook niet aan het internet hangen! dus zouden ook 'veilig' moeten zijn. (of ze mogen wel veranderen en aan het internet met de veranderingen getest en continue verbeterd. of er is een ander systeem dat er tussen zit 'air-gaped'

En wie mag het oplossen? Ik stel voor dat water dat mag. (er is geen probleem geschetst door jouw, en in water lossen de meeste stoffen op). Als je jouw systeem wilt beveiligen zodat deze exploit niet kan werken is er al 1 oplossing. Syslinux installeren en de syslinux flag `deny_ptrace` op 1 zetten.

Printers gezien rond 2000 uitgerust met niet windows servers maar een ander OS. Routers gebruiken sinds jaar en dag dat andere dan windows OS, ver voor 2000 al. Laten we dat IOT pas begon in 2008 maar snel vergeten.

Al die routers printers lossen niet op als je ze uit het raam de gracht in gooit. Jammer dat is een te grote milieuvervuiling.
De eigenaren van die gadgets zullen ook klagen dat ze er voor betaald hebben en dat het hoort te werken.

Je andere oplossingen als niet aan het internet hangen (cloud service?) etc zijn vrij algemeen voor elk OS. Je moet zoiets gewoon in je informatieveiligheidsplan hebben staan. Dat staat onder druk want is een kostenpost brengt niets op.

Goh, dat had ik niet verwacht, dat de NSA in staat zou zijn om SSH credentials te stelen met hun malware. Indrukwekkend ;)

Zodoende wordt veiligheid op de infrastructuur nog steeds en veel meer een relatief begrip
en zodoende neemt dus het vertrouwen in de oplossingen van grote spelers,
die met deze drie-letter-diensten in bed (vaak ook moeten) liggen navenant af.

Vertrouwt u bij voorbeeld Azure of krijgt u nu al het zuur en benauwd wat er non-public kan gebeuren.

Er is geen trust voor mij op code die ik niet zelf heb geverifeerd of outsourced is
en niet gecheckt, geport en gefuzzed.

Even een voorbeeldje met javascript, iets dat eindeloze onveiligheid opleveren kan.
Een willekeurige website draait het volgende script: domein/js/menu/menu.js

Een DOM-XSS scan erop geeft: Number of sources found: 37 en Number of sinks found: 11

Een javascript unpacker prompt voorde volgende fouten: We hebben hier te maken met een" anti-evasion obfuscated adware script " met risico op fingerprinting misbruik. Is er same origin gewaarborgd, zijn er sri-hashes gegenereerd?

Dit dient daarom opgenomen worden met de ontwerpers van de gebruikte javascript obfuscator dienst op: http://javascript-source.com/ (opm. van mij luntrus)

Doordat we niet op elk moment, ook niet via oversight door luitjes met technische informatica expertise, kunnen zeggen - dit is redelijk veilige code is. en dat minder of helemaal niet..... (want garanties doen voor een systeem dat zo nooit naar het Internet had moeten ontsnappen kunnen we nooit)......zo lang blijven deze drie-letter-diensten heer en meester over ons.

Beseffen we dit wel heel goed, dames en heren met TIN-security als interesse????????

Dan is het dus erg goed dat er later proliferatie optreedt, anders zijn we allemaal al vogelvrij of liever gezegd vogelvoer Eerst voor cyberspooks en vervolgens voor cybercriminals.

Maak je borst maar nat, er komt nog veel meer via de pijplijn. We zullen meer toevloed van TinSec specialisten nodig hebben op GDI.Foundations bij voorbeeld. Kom op researchers met voldoende relevante kennis en het technische hart op de juiste plaats, maak het verschil voor ons en laat ons Nederlanders zich weer wat veiliger voelen online.
Zet op die wiite hoed en verdien je strik! Wacht in het andere geval op de uitnodiging om uw diensten aan te bieden aan een van deze verguisde drie-letter-woord-diensten.

luntrus

Vast wel, maar wat je nog niet gezegd hebt is hoe die uitgaande firewall precies moet helpen .

Er draait dus (na een exploit) een proces dat voldoende privileges heeft om data (credentials) uit andere processen te stelen.
Effectief gezien 'root' dus .

En het draait op een host die minimaal uitgaand SSH mag doen (anders zou er niks te stelen zijn) .

Stel jij je een uitgaande firewall voor op een host waar een exploit met root draait en dat zou een uitgaande firewall moeten tegenhouden ? Waarbij de uitgaande firewall minimaal uitgaand SSH doorlaat, aangezien die host dat doet ?

Of, stel je je een externe firewall voor waar de host-met-exploit wel doorheen mag SSH'en en waarbij de firewall toch het exfiltreren van de geoogste passwords moet tegenhouden ?
Je snap hopelijk dat het uploaden van de oogst op heel veel manieren kan (ssl naar een website, google docs, twitter posts, ssh/scp ) - en niet beperkt is tot upload naar 'ftp.cracked-hosts.cia.gov' ?

Ik zal niet zeggen dat een uitgaande firewall nutteloos is , maar als je zover bent dat een host die valide SSH mag doen volledig compromised is , is er geen simpele oplossing meer .

Dat is exact wat er gebeurde.

Microsoft werd gewaarschuwd over het issue, en bracht een patch uit.
Deze patch voor WannaCry was 1 maand voor WannaCry beschikbaar. De patch voor Petya was deels dezelfde.

De enigen die last hebben gehad van deze "ongein" zijn degenen die hun security patches niet tijdig installeren.

Zonder Wikileaks & Shadow Brokers was dit issue vandaag waarschijnlijk nog steeds niet opgelost.
Als iemand anders op dit SMBv1 lek was gestoten en een worm had gereleased, was de impact veel groter geweest want dan was er nog niemand die een patch had...