'Bijna 200.000 systemen zijn nog steeds kwetsbaar voor Heartbleed-lek'

Volgens informatie van zoekmachine Shodan zijn er nog steeds 199.500 kwetsbare hosts op het internet te vinden als gevolg van het Heartbleed-lek in OpenSSL. Het bestaan van de kwetsbaarheid kwam in april 2014 aan het licht.

Shodan heeft een Heartbleed-rapport gepubliceerd, waarin de cijfers naar voren komen. Het blijkt dat de meeste hosts in de Verenigde Staten aanwezig zijn, met ongeveer 42.000 kwetsbare installaties. Op de tweede en derde plek staan respectievelijk Zuid-Korea en China, gevolgd door Duitsland en Frankrijk. Nederland of België komen niet in de top tien voor. De kwetsbare hosts draaien in veel gevallen Apache of Nginx.

Een maand nadat Heartbleed in het nieuws was gekomen, was het aantal kwetsbare hosts gedaald van 615.000 naar 318.000, zo bleek uit onderzoek van Robert Graham. Dit aantal lijkt sindsdien niet meer sterk te zijn gedaald, uitgaande van de juistheid van de gegevens. Heartbleed, ook wel bekend als CVE-2014-0160, was voor zijn ontdekking ongeveer twee jaar aanwezig in OpenSSL en maakte het mogelijk om het geheugen van een webserver uit te lezen. Daardoor was het bijvoorbeeld mogelijk om privésleutels te achterhalen.

De ernst van de kwetsbaarheid was zeer groot, omdat deze gevolgen had voor veel aan het internet verbonden apparaten en omdat deze vrij eenvoudig te gebruiken was. De kwetsbaarheid was in de code terechtgekomen doordat een ontwikkelaar vergat een variabele te valideren en doordat deze niet werd opgemerkt tijdens de controle.

Reacties (74)

[Rubixd]

Hoe kan je erachter komen of jou site deze lek niet/wel heeft? Heeft de hoster deze informatie?

[CAPSLOCK2000]

Hoe kan je erachter komen of jou site deze lek niet/wel heeft? Heeft de hoster deze informatie?

De beste site om je site te laten beoordelen op dit lek en groot aantal andere SSL-problemen is via de website van SSLlabs: https://www.ssllabs.com/ssltest

In mijn werk verwachten we dat onze partners een A scoren op die website, niet alleen op het moment dat we het contract sluiten maar gedurende de hele periode.

[xoniq]

Ik probeer altijd zsm te anticiperen op exploits. Zoals heartbleed, poodle etc. Proberen m'n VPS'en op een A+ te houden.

[totaalgeenhard]

https://pentest-tools.com...penssl-heartbleed-scanner

ps: als je hoster niet gepatched is dan heb je een structureel probleem.
Veel Linux hosters gebruiken b.v. CentOS (gratis RedHat ES versie) en alleen End-off-live versies zijn niet gepatched.

Met andere woorden, deze security probleem is het minste waar je je dan zorgen over hoeft te maken.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[killercow]

Eh?
Wat een onzin. Dit probleem is wel degelijk een groot probleem, niet alleen is je SSL lek als je site hier positief op test, maar ook is met wat moeite het geheugen van de server uitleesbaar. Dan is het dus niet alleen communicatie tussen de clients en de server die potentieel inzichtelijk zijn, maar alles wat in het geheugen zit (waaronder de private key, maar ook wachtwoorden van je database of users etc)

Ja, als je ssl lek is zijn er vast nog meer dingen lek aan je server, maar dit lek is gemakkelijk en remote exploitable, en geeft inzicht in ontzettend veel van je geheugen waar andere issues wellicht niet eens remote exploitable zijn.

[totaalgeenhard]

Zie reacties van anderen op je reactie.

Maar DEZE remote exploit is helemaal niet interessant.

Als je weet dat bepaalde hoster om wat voor reden dan ook iets niet gepatched heeft (of kan patchen) dan is dat voor bepaalde mensen aanleiding om kleine hosting account te nemen die ze betalen met anonieme creditcard.

Omdat de kans dat je daar lokaal root zult halen (ook al hebben ze geen shell access) veel groter is dan bij een partij die wel gepatched heeft.

Bij veel partijen kun je geen portscan meer doen, omdat je dan meteen een IP block/reject hebt. Maar met deze simpele scan kun je wel weten dat een partij zaken niet voor elkaar heeft. En de kans dat je bij een scan op SSL (een enkele port, met een enkele foutmelding) geblokkeerd zal worden is vrij klein.

Voordat ik reacties krijg over "niet kunnen patchen" op elke besturingssysteem heb je afhankelijkheden (depencies) SSL library vervangen gaat niet zomaar.
Als update proces van leverancier er niet meer in voorziet (b.v. EoL) moet je het handmatig doen. En daar zit precies het probleem. Als je X aantal servers hebt ga je dat niet zomaar even met de hand doen even los of hoster daar wel de kennis voor in huis heeft.

Overigens vermoed ik zelf dat meeste problemen te vinden is bij budget hosters.
Maar e.a. grote partij die er tussen zit zal me ook niets verbazen.

[hackerhater]

Als buget host zorg ik juist dat ik mooi bij blijf met de OS-versies en patches.
Stuk minder werk zo

[totaalgeenhard]

Als je een enkele server hebt....

Stel je huurt een paar servers en je bent afhankelijk van je leverancier....

Maar inderdaad als je vandaag CentOs 7 ergens opzet zit je tot June 30, 2024 goed. En tegen die tijd zijn is je hardware (hopelijk) afgeschreven.

[hackerhater]

Wij huren de fysieke servers.
Vanaf de OS-stack zijn wij er verantwoordelijk voor en we zetten er dan in-support software op met zo min mogelijke afwijkingen.
Juist om er zo min mogelijk werk aan te hebben.

We hebben een paar CentOS 6 en een paar CentOS 7 servers en die van 6 staan op de planning om geüpgraded te worden naar 7.

[totaalgeenhard]

Je zult ze maar met CentOs 3 of 4 gehuurd hebben destijds.

Even een tip upgrade script van centos 6 naar 7 werkt niet, zie ook expliciete waarschuwing op centos site.

[hackerhater]

"Upgrade" als in verplaats de klanten naar een nieuwe machine en dan reinstall

[totaalgeenhard]

Sommige hebben die luxe niet

Ik neem het overigens niet op voor die partijen.

Als je niet in redelijke termijn een patch kunt toepassen zit er iets structureels fout.

[Verwijderd]

Ja, als je ssl lek is zijn er vast nog meer dingen lek aan je server,

Ik denk dat je hier iets te gemakkelijk aan voorbij gaat. Je legt de nadruk heel erg op heartbleed in je reactie, maar als ze er nog vatbaar voor zijn is dat indicatief aan een slecht updatebeleid in zijn algemeenheid en daarmee weet jij niet waar ze wel tegen gepatcht zijn.
Heartbleed is niet de enige exploitable bug die aan het licht is gekomen in de afgelopen jaren namelijk.

[killercow]

Klopt, het is niet de enige, en ook wellicht niet de ernstigste, maar wel een die ontzettend makkelijk remote te scannen en uit te buiten valt.

Met andere woorden, deze security probleem is het minste waar je je dan zorgen over hoeft te maken.

Dat is gewoon niet handig om te roepen. Het zal best dat je mysql ook lek is, of je kernel lokaal te exploiten valt, maar dat is beide veelal lastiger te exploiten dan naar gelieve het geheugen van je server uitlezen met een simpel scriptje.

[supersnathan94]

Heartbleed an sich is dan ook niet het probleem.

Waar hij op doelt is dat je met de gegevens uit de memorydump veel ernsitgere problemen gaat krijgen omdat passwords van encypted containers en databases vaak ook in memory worden geladen voordat er authenticatie plaats kan vinden.

Daarnaat is de kans dus vrij groot dat als een simpele patch als dit niet is uitgevoerd alle achterliggende systemen waarschijnlijk ook zo lek als een mandje zijn. Zo bevat een memorydump van veel backend applicaties al belangrijke gegevens omtrent wachtwoorden. En waarschijnlijk ook persoonlijke gegevens van klanten.

[R4gnax]

Het argument van totaalgeenhard is dat servers die geen patch tegen Heartbleed hebben, ook geen patches tegen 'tig andere exploiteerbare vulnerabilities hebben die het mogelijk heel wat makkelijker mogelijk maken om op servers in te breken en gewoon direct aan die data te kunnen komen, zonder in het geheugen rond te gaan prikken.

En het klopt dus ook gewoon dat dat een vee------l groter en meer direct probleem is dan Heartbleed.

[Reactie gewijzigd door R4gnax op 23 juli 2024 03:54]

[Patriot]

Eh? Wat een onzin. Dit probleem is wel degelijk een groot probleem,

Als je dat uit zijn post haalde dan heb je toch behoorlijk verkeerd gelezen.

[CAPSLOCK2000]

weg

verkeerd lezen doe ik zelf blijkbaar ook. @Patriot

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:54]

[Patriot]

Ik moest het ook twee keer lezen maar het staat er wel, de toon impliceerde misschien iets anders maar totaalgeenhard heeft het bij het juiste eind.

Euh, mis ik nou iets, dat is toch precies wat ik zeg?

[Zoop]

Punt is puur dat als de server nu nog gevoelig is voor de heartbleed bug (iets wat met een fatsoenlijk update beleid al lang opgelost hoort te zijn) er ongetwijfeld meer mis is met die server, en dan is de heartbleed exploit het minste van de problemen, heel de server is compromised.

[Evdpol]

site ondersteund niet eens ipv6

[Mel33]

Met Chrome heb je een plugin

[beerse]

Misschien moeten in dit soort gevallen man en paard genoemd worden: Benoem de machines en de bijgaande instanties. Dan kan er gericht actie worden ondernomen:

• Daar waar het om bedrijven en instanties gaat, de organisaties noemen zodat ze kunnen worden ontweken
• Daar waar het om hardware gaat die als huisvlijt aan internet gekoppeld zijn kan ze worden losgekoppeld.

[totaalgeenhard]

In Nederland is het een pogingsdelict indien je machines gaat af scannen, daar kan je een kwart van straf voor daadwerkelijk inbreken voor krijgen.

Verder kun je niet iets publiceren wat je niet zeker weet, het kan net zo goed een honeypot zijn of express misleidende informatie verstrekken om footprinting te misleiden.

Bovendien welk probleem heb jij (of ik) met of door een " Heartbleed-lek" systeem?

[Milosonator]

Iemand kan de private key van de server compromitteren, waardoor communicatie tussen mij en een andere partij vervalst of afgeluisterd kan worden.

[totaalgeenhard]

En dat kan nu niet?

Mensen vertrouw niet blind op SSL.

[Verwijderd]

Je kan nergens blind op vertrouwen, inclusief je eigen werk, maar om daar nou direct weer een known exploit mee weg te nuanceren vind ik wel een beetje next level apart.

[CAPSLOCK2000]

En dat kan nu niet?

Mensen vertrouw niet blind op SSL.

Welke beveiligingsmaatregelen kunnen we wel blind vertrouwen?

Volgens mij niet één, niks is namelijk perfect. Veiligheid bereik je door middelen een maatregelen te combineren tot je het juiste niveau haalt voor jouw situatie.
SSL is een belangrijk middel, ook al is het niet perfect. Heartbleed is meer dan een gebrek in SSL, het opent nieuwe deuren die er voorheen niet waren. Je kunt misschien* wel zeggen dat je zonder SSL beter af bent dan met heartbleed-SSL.

* misschien, het ligt nogal aan de omstandigheden

[totaalgeenhard]

Als je Trump bij CIA ziet slijmen en letterlijk zegt "Ik ga jullie teveel support geven, zoveel dat jullie zeggen niet zoveel"

Dan begrijp ik eruit dat hij Amerikaanse inlichtingendiensten dermate gaat pushen dat ze ethische normen en waarden gaan overschrijden (zover dat ze dat al niet doen.)

Uit Cables blijkt al dat hele overheid zeer economisch gericht is en inlichtingen al werden gebruikt voor economische belangen.

Derhalve ga ik er vanuit, dat indien iets ECHT belangrijk is, je beter fysiek met iemand kunt afspreken in een ruimte waar afdoende omgevingsgeluid is en niemand een telefoon bij zich heeft.

Alles wat je met een computer doet waarop een OS staat dat je niet zelf gemaakt hebt kun je niet vertrouwen.

SSL is leuk en aardig, maar meeste CA zitten in Amerika. En zolang je geen clientside certificaat gebruikt die je verkregen hebt op een (fysieke) key-signing party weet je niet met wie/wat je van doen hebt.

Even los van het feit dat we niet weten hoever NSA is met quantum computing. Want dan maakt het niet uit welke hedendaagse algoritme we gebruiken.

https://www.thesslstore.c...-quantum-computing-risks/

Dus blind vertrouwen.... niets.
Ik meen in Art of War de zin staat "Een geheim die je met een ander deelde is geen geheim meer"

ps: mbt elke vulnerability. Zorg er voor dat je niet interessant genoeg bent dat mensen tijd en energie gaan steken om aan je data te komen.
Indien je wel interessant genoeg is, zullen ze fysiek altijd bij je systemen kunnen komen.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[CAPSLOCK2000]

Derhalve ga ik er vanuit, dat indien iets ECHT belangrijk is, je beter fysiek met iemand kunt afspreken in een ruimte waar afdoende omgevingsgeluid is en niemand een telefoon bij zich heeft.

Als het om staatsgeheimen gaat lijkt me dat een redelijke aanpak. Als ik een pizza wil bestellen niet.

Maar, is het absoluut gegarandeerd veilig? Nee. Er kunnen ook microfoons in de kamer hangen. Absolute veiligheid bestaat niet, maar dat is geen reden om dan maar niks aan veiligheid te doen.

Alles wat je met een computer doet waarop een OS staat dat je niet zelf gemaakt hebt kun je niet vertrouwen.

En jij vertrouwt de hardware als je het silicium niet zelf uit de grond hebt gehaald?

SSL is leuk en aardig, maar meeste CA zitten in Amerika. En zolang je geen clientside certificaat gebruikt die je verkregen hebt op een (fysieke) key-signing party weet je niet met wie/wat je van doen hebt.

Dat maakt mij niet uit, als de pizza niet lekker is dan bestel ik volgende keer wel bij aan ander. Het maakt mij niet uit hoe die pizzaboer bij de kamer van koophandel staat geregistreerd.

Dus blind vertrouwen.... niets.

Maar, maar, maar... je schreef eerder dat je geen gebruik mag maken van SSL omdat je het niet blind kan vertrouwen. Als er niets is dat je blind kan vertrouwen dan is de enige logische conclusie dat je geen enkele beveiliging kan toepassen.

Beveiliging is een combinatie van middelen. SSL is een belangrijk middel. Dat het niet perfect is is nog geen reden om het niet te gebruiken.

ps: mbt elke vulnerability. Zorg er voor dat je niet interessant genoeg bent dat mensen tijd en energie gaan steken om aan je data te komen.

Niet interessant zijn is niet echt een realistische keuze, er is altijd iemand nog minder interessant. En wat moeten de mensen dan doen die wel interessant genoeg zijn?

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:54]

[totaalgeenhard]

Maar wegfilteren van geluiden is best moeilijk tot onmogelijk.
Als je in een disco zit kan je bekende nummers wegfilteren maar dan moet spraakgeluid hard genoeg zijn. Als er veel mensen praten zal het ook lastig tot onmogelijk zijn omdat je stem van de mensen die je wilt afluisteren moet kunnen isoleren. Verder als ze hand voor hun mond hebben kan je ook liplezen vergeten.

Indien je een ruimte veilig wil hebben kan je een sweep bestellen, maar dat zal je niet beschermen tegen "van ECK" methode en richt microfoons. Daarom altijd hand voor de mond en voldoende omgevingsgeluid.

En jij vertrouwt de hardware als je het silicium niet zelf uit de grond hebt gehaald?

Och, mijn bijdrages op het Internet zijn dermate onschuldig dat ik niet zelf hoef te scheppen.

Maar, maar, maar... je schreef eerder dat je geen gebruik mag maken van SSL omdat je het niet blind kan vertrouwen. Als er niets is dat je blind kan vertrouwen dan is de enige logische conclusie dat je geen enkele beveiliging kan toepassen.

Beveiliging is een combinatie van middelen. SSL is een belangrijk middel. Dat het niet perfect is is nog geen reden om het niet te gebruiken.

Maar om het als VEILIG te verkopen is een fout.
Grootste risico die mensen lopen is er van uit gaan dat iets veilig is omdat ze SSL gebruiken, omdat ze een VIRUSSCANNER hebben etc... dat maakt mensen onachtzaam en daarmee juist gevoelig.

Mijn doel is dat mensen nadenken over onderliggende processen, niets meer en niets minder en als iemand weet dat je niet blind kunt vertrouwne op DNSSEC/SSL/VIRUSSCANNER etc.. dan zullen ze bewust er gebruik van maken en in het achterhoofd bijblijven dat het ook fout kan gaan. Indien er dan iets raars gebeurd (zoals laatst dat me S7 EDGE 's nachts uitzichzelf rebootte) valt het meteen op.

En wat moeten de mensen dan doen die
wel interessant genoeg zijn?

Die zullen wel de middelen hebben om een consultant aan te trekken

Als iemand in quote 500 staat en geen kluis heeft...

[CAPSLOCK2000]

Maar wegfilteren van geluiden is best moeilijk tot onmogelijk.
Als je in een disco zit kan je bekende nummers wegfilteren maar dan moet spraakgeluid hard genoeg zijn. Als er veel mensen praten zal het ook lastig tot onmogelijk zijn omdat je stem van de mensen die je wilt afluisteren moet kunnen isoleren. Verder als ze hand voor hun mond hebben kan je ook liplezen vergeten.

Juist, voortaan gaat het kabinet naar de disco om te vergaderen.

Maar om het als VEILIG te verkopen is een fout.
Grootste risico die mensen lopen is er van uit gaan dat iets veilig is omdat ze SSL gebruiken, omdat ze een VIRUSSCANNER hebben etc... dat maakt mensen onachtzaam en daarmee juist gevoelig.

Het is wel veilig. Nergens in de wereld geloven mensen in absolute veiligheid. Iedereen weet dat niks ooit 100% veilig is. Natuurlijk, er is wel eens een idioot dat niet beseft maar de meeste mensen snappen echt wel hoe het zit. Ze kunnen het risico misschien niet goed inschatten maar mensen weten wel dat veiligheid niet absoluut is. Niemand die gelooft dat het onmogelijk is om een ongeluk te krijgen met een veilige auto.

SSL is net zo veilig als andere dingen die we in ons leven "veilig" noemen. Zeggen dat SSL niet veilig is omdat het onder bepaalde omstandigheden niet afdoende is doet meer kwaad dan goed. Als je een beter systeem hebt om het te vervangen dan hoor ik het graag, ik zou het graag vervangen, maar ik zou niet weten wat er beter is en realistisch uitvoerbaar.

Die zullen wel de middelen hebben om een consultant aan te trekken

Wat moet die consultant dan zeggen? Sluit uw webshop maar?

[totaalgeenhard]

Mensen die in de IT en met name ITsec weten dat.

Doorsnee webshop eigenaar niet.


Ps: als ik oplossingen heb zal ik dat commercieel exploiteren.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[CAPSLOCK2000]

Doorsnee webshop eigenaar niet.

Dus, wat moet de doorsnee webshop eigenaar nu doen? Geen SSL gebruiken?

Je hebt technisch gezien helemaal gelijk dat je niet blind op één techniek moet vertrouwen maar je geeft nu het signaal af dat je SSL helemaal niet moet gebruiken.

[totaalgeenhard]

Zie mijn antwoord op clientside certificate.

Dus niet alleen server maar ook client autheticeren.

Maar je hebt altijd zoiets als gebruikers gemak en risico.

Bij kleine transacties en onbelangrijke sites voldoet het. Bij RDW (destijds) moest client zich ook authenticeren.

Ik gebruik een bepaalde leverancier die two factor authentication gebruikt + clientside certificate + IP filter... dat is overkill.

[Ventieldopje]

Je hebt zelf de keus om ergens in te vertrouwen of niet, want dat is alles wat een CA is, een vertrouwenspartij die hun vertrouwen verkoopt dmv. een stempeltje op je certificaat.

Vertrouw jij dus geen CA in een bepaald land, dan zoek je er een binnen Europa. Als nood aan de man is dan zul je hier ook meer CA's gaan vinden. Voor nu is er volgens mij geen enkele reden om de respectabele CA's die toevallig in Amerika zitten te gaan wantrouwen.

[totaalgeenhard]

Er was er eentje in Nederland

Die wereldwijd beroemd is geworden.

Certificaten hebben een waarde die ze garanderen, dus in economisch handelsverkeer. Ik weet niet van een zaak waarbij een CA daadwerkelijk aan hun garantie is gehouden en hebben moeten uitkeren.

Aan de ene kant is dat een goed teken, immers ze hebben geen zaak rond kunnen krijgen aan de andere kant is dat een slecht tegen, om dezelfde reden.

Dus voor huis/tuin/keuken en klein zakelijk verkeer is huidige PKI goed genoeg en de risico's voor meeste mensen/bedrijven te overzien.

Echter indien je leven er van afhankelijk is omdat je b.v. dissident or journalist bent in minder fris regime, dan zou ik er niet op vertrouwen. En daar zijn genoeg voorbeelden van.

Tegen o.a. staats-actoren is SSL niet bestand. En juist niet indien je van een CA afhankelijk bent.

Waarom een bedrijf die een onderdeel in Amerika heeft (dus niet persé hoofdkantoor) te wantrouwen?

Patriot act.

Met betrekking root CA's welke belemmering is er root CA te worden voor NSA of een andere "fake" bedrijfje ?

Met clienside certificates voorkom je dus dat als serverside certificaat vervangen is, dat je er "per ongeluk" bij komt. Immers je zult foutmeldingen zien en certificaat moeten verwijderen.

[Ventieldopje]

"Echter indien je leven er van afhankelijk is omdat je b.v. dissident or journalist bent in minder fris regime, dan zou ik er niet op vertrouwen. En daar zijn genoeg voorbeelden van."

In dat geval kun je beter gebruik maken van andere protocollen zoals GPG

[CAPSLOCK2000]

Met clienside certificates voorkom je dus dat als serverside certificaat vervangen is, dat je er "per ongeluk" bij komt. Immers je zult foutmeldingen zien en certificaat moeten verwijderen.

Wat bedoel je met een "clienside certificate" (en dan bedoel ik uiteraard niet de typo).

Als het je gaat om (client) authenticatie met behulp van certificaten dan gaat dat je niet beschermen tegen een server certificaat dat is verandert, dat is niet anders dan aanmelden met een username/wachtwoord.
Je browser zou je er op kunnen wijzen dat het server certificaat is verandert maar dat heeft helemaal niks met certificaten voor de client te maken.
Of begrijp ik het nu zo verkeerd?

[totaalgeenhard]

Je hebt serverside certificaten waar iedereen het vaak over heeft als ze het over https hebben, maar je hebt ook clientside certificaten die gesignd zijn en die je importeert in je browser.

https://www.w3.org/DesignIssues/Security-ClientCerts.html

Jaren geleden zag ik bij een garage dat ze voor RDW clientside certificate gebruikten.

Het is een extra laag.

http://docs.aws.amazon.co...e-ssl-authentication.html


Als certificaat op server zou veranderen werkt je clientside certificate niet meer.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[CAPSLOCK2000]

Als certificaat op server zou veranderen werkt je clientside certificate niet meer.

Dat klopt niet, zo werkt het niet. Met een client-certificaat kun je het certificaat van de server niet controleren. Net zo min als je met een username/wachtwoord kan controleren of het server-certificaat is verandert, er is gewoon geen relatie tussen een client-certificaat en een server-certificaat.

Als client kun je wel bijhouden welk certificaat de server gebruikt maar daar heb je zelf geen client-certificaat voor nodig. (Je hebt wel een root-certificaat nodig om de correctheid van het server-certificaat te controleren, maar dat is iets anders dan een client-certificaat).

[totaalgeenhard]

Misschien dat je hiermee uit de voeten kunt.

https://jamielinux.com/do...-client-certificates.html

Wat ik schreef klopt. Als je server side certificaat aanpast zal client side certificaat gewoon niet gaan werken.

Zoek ook eens op private ca server client certificate.

Dan kan je iets op zetten wat geheel onafhankelijk van derden en het internet.

[CAPSLOCK2000]

Misschien dat je hiermee uit de voeten kunt.

https://jamielinux.com/do...-client-certificates.html

Dat zie ik niet. Kun je aanwijzen waar in dat document staat hoe je het server certificaat kan controleren met het client-certificaat?

Volgens mij weet ik heel aardig hoe het werkt. Ik kan me natuurlijk vergissen maar dan hoop ik dat je duidelijk kan uitleggen waar ik fout zit.

Wat ik schreef klopt. Als je server side certificaat aanpast zal client side certificaat gewoon niet gaan werken.

Volgens mij klopt dat echt niet, ik kan het alleen niet bewijzen.
Geef een handleiding? (die eerste link is dat niet)
Onderbouw het wiskundig?
Link naar wikipedia?
Voorbeeld van een OpenSSL commando?

Dan kan je iets op zetten wat geheel onafhankelijk van derden en het internet.

Dat klopt, maar ook in dat geval gaat een client-certificaat je niet helpen om aan te tonen dat het cert van de server is verandert.
Daar heb je een CA-certificaat voor nodig (aka root-certificate), al dan niet aangevuld met intermediate-certificates. Dat is iets anders dan een client-certificaat.

Ik vind het een beetje vervelend om het volgende argument te maken, maar ik kan je ongelijk niet bewijzen: ik run meerdere kleinschalige CA's en werk dagelijks met client-certificaten.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:54]

[totaalgeenhard]

Probeer het.

Vervang daarna certificaat van server en tracht login en vice versa.

Ik denk dat je te moeilijk denkt. Het is vrij logisch.

(Als server root-CA is voor de client certificate... is niet zo complex om door te redeneren?)

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[CAPSLOCK2000]

Probeer het.
Vervang daarna certificaat van server en tracht login en vice versa.

Nee, sorry, maar ik hoef het niet te proberen want ik doe dit regelmatig, dat is mijn werk. Als gebruikers niet meer zouden kunnen inloggen als ik een certificaat verving dan had ik het wel geweten, dan zou hier de telefoon roodgloeiend staan.

Ik moet nu toch even vragen: heb je praktijk ervaring met dit soort systemen?

Ik denk dat je te moeilijk denkt. Het is vrij logisch.

Waarom heb je dan niet op mijn vragen gereageerd?+

• Geef een handleiding? (die eerste link is dat niet)
• Onderbouw het wiskundig?
• Link naar wikipedia?
• Voorbeeld van een OpenSSL commando?

(Als server root-CA is voor de client certificate... is niet zo complex om door te redeneren?)

Doe me een lol en redeneer het even voor mij door, ik kan het niet. Het gaat al fout als je de server de "root-CA" noemt, dat is die server namelijk niet. (In theorie zou het wel kunnen maar dat is vast niet wat je hier bedoelt en in ieder geval niet hoe het in praktijk op internet gebruikt wordt).

[totaalgeenhard]

Ja, veel, vooral vorige eeuw/begin deze eeuw, denk top 10 en overheid. Tegenwoordig client side alleen met specifieke leveranciers.

Ik weet niet hoelang je meeloopt. Maar in mijn tijd maakte (hackte) we alles gewoon zelf.

Howto was generatie daarna en tegenwoordig moet het allemaal GUI based zijn

Vraag je als client CSR gesigned word door server, wat er gebeurd indien je certificaat tegen die server zult gebruiken en wat gebeurd er als private key van de server weg is/vervangen.... denk niet moeilijk, ik kan me niet voorstellen dat je het niet weet/ziet.

mbt: root-ca belangrijke infrastructuur hangt niet aan het internet, deze kan keten niet (direct) controleren.

Hier een link:

For excessively paranoid client authentication.

https://gist.github.com/mtigas/952344

Test het en laat me weten of je het nu wel snapt.
Indien je twijfelt even server private key hernoemen en nieuwe server certificaat genereren en vervangen en zie dat het werkt.

Om dat door te trekken naar praktijk. Als een derde partij een MitM doet en daarbij een ANDERE certificaat gebruikt kan je client niet authenticeren met diens certificaat en daarbij heb je complete keten afgedekt.

TTP= Third Trusted Party en men gebruikt nu enkelzijdig certificaat authenticatie, gebaseerd dat TTP niet vervalst zal worden, of een andere TTP die ook door je browser geaccepteerd werd/word een certificaat server kan/zal uitgeven. Immers hoeveel mensen valideren certificaten zelf en bij elke sessie? In wat ik je probeer uit te leggen werkt het twee kanten op.
En je hebt gelijk met google zag ik dat er heel weinig te vinden is over dit specifieke onderwerp, maar het is al heel lang common business. (tenminste overheid/financial/insurance etc..)

Ik weet niet of je weet wat een "signing party" is.
Maar bij grote instellingen/bedrijven komen mensen die elkaar kennen en van elkaar weten welke rol ze hebben, fysiek signed en dan pas stop je het resultaat op een FIPS-140 device omdat je weet dat er niet van buiten uit keten kan worden gemanipuleerd.

ps: Ik probeer je niet te "bashen" maar ik ga er vanuit dat sommige dingen vanzelfsprekend zijn. Gezien je affiniteit met het onderwerp.
Vroeger zou men je allang RTFM geantwoord hebben of voor dit consult hebben laten betalen

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[CAPSLOCK2000]

Vraag je als client CSR gesigned word door server, wat er gebeurd

Waarom zou je client-certificaat door de server worden gesigned?
Dat doet de CA, niet de server.

indien je certificaat tegen die server zult gebruiken en wat gebeurd er als private key van de server weg is/vervangen....

Dan mag je gewoon naar binnen.
Nouja, als de private key helemaal weg is dan kun je uberhaupt geen verbinding maken, maar dat gaat al fout voor er iets gecontroleerd kan worden, dat heeft eigenlijk niks met SSL te maken. Laten we dus maar even uit gaan van het geval waarin het certificaat is vervangen door een aanvaller.

De client meldt zich bij de server en controleert of de server een geldig SSL-cert heeft. Geldig betekent in deze dat het getekend is door een vertrouwd CA. Dat hoeft niet dezelfde CA te zijn als voorheen, ieder CA die de client vertrouwt is goed*.
Je client kan ook nog controleren of het exact hetzelfde certificaat is als voorheen of niet, al is dat geen standaard functionaliteit.
Als er iets niet in orde is dan stopt het hier. Let op: het client certificaat is nog niet gebruikt.

Dan is het de beurt aan de server. De vraagt de client om zich te authenticeren met een certificaat. Dat doet de client met een client-certificaat. De server moet nu beslissen of dat certificaat in orde is of niet. Let op: de server beslist hier of de client door mag, niet de client.

Je kan nog wat extra's doen zoals een specifieke fingerprint of CN verlangen maar daarbij spelen client certificaten geen rol.

Als je denkt dat het anders werkt dan wil ik OpenSSL commando's zien of wiskunde.

denk niet moeilijk, ik kan me niet voorstellen dat je het niet weet/ziet.

Ik weet wat je wil horen maar het is niet zo.

mbt: root-ca belangrijke infrastructuur hangt niet aan het internet, deze kan keten niet (direct) controleren.

Je hebt toch echt een kopie van de root-certificaten nodig. Je moet ergens beginnen met vertrouwen. Ok, je kan ook 1 op 1 relaties leggen maar dan heb je het niet meer over een root-ca.

Hier een link:
https://gist.github.com/mtigas/952344
Test het en laat me weten of je het nu wel snapt.

Ik zie nog steeds niet waar je een client certificaat gebruikt om de server te controleren en waar de client zou weigeren als de server opeens een ander (geldig) certificaat heeft gekregen.

Je geeft hier wat commando's om certificaten aan te maken, niet om ze te controleren.

Server-certificaten controleer je aan de hand van een root-certificaat en eventueel wat intermediates.

Indien je twijfelt even server private key hernoemen en nieuwe server certificaat genereren en vervangen en zie dat het werkt.


* er zijn aanvullende maatregelen zoals DANE en DNS CAA maar die zijn hier buiten scope

[totaalgeenhard]

Waarom zou je client-certificaat door de server worden gesigned?
Dat doet de CA, niet de server.

Als je een gesloten keten wilt hebben waar je op kunt bouwen doe je dat wel op die manier.

Je hoeft geen TTP te gebruiken. Je kunt wel voor serverside TTP gebruiken.

Ik zie nog steeds niet waar je een client certificaat gebruikt om de server te controleren en waar de client zou weigeren als de server opeens een ander (geldig) certificaat heeft gekregen.

Probeer het eens op een test back en je zult zien.. overtuig jezelf...

Even een algemene advies, als je iets wilt leren, zet dan even je hersenen/verstand uit, want anders zul je telkens met wat je denkt te weten redeneren en leer je niets. Probeer dat maar eens als je weer eens in een boek/cursus materiaal zit te lezen.
Als je dat niet doet zul je met beperkte kennis en ervaring redeneren en dan zul je het nooit zien /leren.

Ik zou niet weten wat ik verder kan schrijven om dit stukje kennis/ervaringsoverdracht te voltooien.

Dus doe beiden een plezier breng het in de praktijk en bevestig dat het werkt en na verloop van tijd zul je het ook gaan begrijpen.

[CAPSLOCK2000]

Dus doe beiden een plezier breng het in de praktijk en bevestig dat het werkt en na verloop van tijd zul je het ook gaan begrijpen.

Voor de meelezers: ik heb het geprobeerd en het klopt niet.

Hoe dan ook, geloof ons niet op ons woord maar zoek het zelf uit. Om met de Piratenpartij te spreken: Informeer jezelf!

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:54]

[totaalgeenhard]

Hold your horses.

Als je client certificate gebruikt tegen de server die hem geïssued and gesigned heeft, en vervolgens die private key kan vervangen en nog steeds kunt authenticeren en in je browser niets opmerkt, heb je waarschijnlijk accept ANY /invalid in je configuratie staan.

Of je hebt een de grootste lek van de eeuw gevonden.... maar ik gok op het eerste. RTM en zoek uit waar je fout zit.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[Milosonator]

Het zou altijd kunnen gebeuren, maar nu is er een werkende, bekende manier om een aanval op te zetten, die makkelijk met een update tegengegaan kan worden. Dat is op zijn minst bijzonder roekeloos te noemen.

[wica]

In Nederland is het een pogingsdelict indien je machines gaat af scannen, daar kan je een kwart van straf voor daadwerkelijk inbreken voor krijgen.

Heb je hier een url van? Ben namelijk zeer nieuwsgierig of ik wat scripts moet uitzetten/aanpassen.

[totaalgeenhard]

http://www.iusmentis.com/beveiliging/hacken/portscans/
http://www.wetboek-online...0van%20Strafrecht/45.html

Overigens heb ik het niet hiervan.

Ik zat begin van deze eeuw in overheidscommissies mbt "Alarmering en incident response" en "Cybercrime".

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[donny007]

Wat ik uit die links opmaak is dat het oogmerk waarmee de poortscan wordt uitgevoerd een grote rol speelt in de (mate van) strafbaarheid.

Dat is ook logisch, anders zouden een hoop internet research projecten niet kunnen bestaan.

[totaalgeenhard]

Een rechter zal niet de technische kennis in huis hebben om daar over te oordelen en afgaan op OvJ.

https://www.security.nl/p...+in+Nederland+illegaal%3F

Arnoud Engelfriet, zit ook hier op Tweakers.

[donny007]

Een rechter zal niet de technische kennis in huis hebben om daar over te oordelen en afgaan op OvJ.

Om over het oogmerk te oordelen heeft de rechter niet veel technische kennis nodig. Het is aan de verdediging om de rechter te informeren en deze te overtuigen.

https://www.security.nl/p...+in+Nederland+illegaal%3F

Arnoud Engelfriet, zit ook hier op Tweakers.

Ook hier gaat het weer om het oogmerk waarmee de tools voorhanden zijn en/of worden ingezet.

Daarnaast is het binnendringen van een computersystemen niet het exclusieve gebruiksdoel van een poortscanning tool.

[totaalgeenhard]

Ik weet niet hoeveel cybercrime rechtzaken zelf hebt gezien, maar wat je op TV ziet in series zo gaat het er niet aan toe. En als je de pech hebt dat OvJ wel technisch weet waar het overgaat en dat goed kan verwoorden heb je gewoon pech ongeacht wat verdediging in te brengen heeft.

Ik raad je aan om een schroevendraaier in je deur van je auto neer te leggen en een koevoet in je achterbak.

De volgende keer dat je auto zal worden doorzocht zal je er vanzelf achter komen wat ik bedoel

[donny007]

Ik raad je aan om een schroevendraaier in je deur van je auto neer te leggen en een koevoet in je achterbak.

De volgende keer dat je auto zal worden doorzocht zal je er vanzelf achter komen wat ik bedoel

Ook in dit scenario zal er gekeken worden naar feiten en omstandigheden

Als dit gereedschap 's nachts bij iemand wordt aangetroffen in een personenauto wordt daar anders naar gekeken dan bij een verwarmingsmonteur die dit in z'n bus heeft liggen.

[totaalgeenhard]

Welke kleur haar heb je?

Een verwarmingsmonteur zal in een busje met meer gereedschap rijden. Als hij alleen die twee dingen in personenauto heeft, heeft hij e.a. te beantwoorden.

Is er een kraak geweest in de buurt geweest dan is meteem verdachte.

[wica]

dank voor de url's.

Gelukkig zijn mijn scripts enkel gemaakt om informatie te verzamelen en aan de betreffende abuse-mailbox van het IP blok te mailen.

Maar vind dit soort wetgevingen wel ver gaan.

[totaalgeenhard]

Het zijn er VEEL meer dan dat.

Elke oudere Linux/*BSD based embedded systeem, routers, modems, oude android toestellen etc...

En die zullen nooit allemaal gepatched gaan worden.


ps: Over variable fouten gesproken click eens op die pagina op de CVE link

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:54]

[elmuerte]

ps: Over variable fouten gesproken click eens op die pagina op de CVE link

Dan krijg ik

Error
Please login to use search filters.

Wat is daar mis mee?

[Dreamvoid]

Er zijn er natuurlijk nog veel meer, maar veel kwetsbare routers/switches zitten er achter een firewall of NAT in een lokaal netwerk. Dat betekent niet dat ze geen probleem zijn, want heb je een besmette Android/iOS telefoon die eventjes op een lokaal netwerk inlogt, dan wordt die router ook zo een zombie.

[slotjejunior]

Heeft iemand tips om van shodan.io af te komen?

[wica]

Je systeem goed beveiligen en up to date houden.
Maar wat shodan kan, kan iedereen.

[qless]

Tuurlijk, shoot the messenger....

[donny007]

Heeft iemand tips om van shodan.io af te komen?

Je firewall goed configureren. IOT apparatuur (en ander connected spul) hoort niet benaderbaar te zijn vanaf het internet.

Wil je toch op afstand bij je NAS of IP-camera's kunnen? Maak dan gebruik van een VPN tunnel.

[Reactie gewijzigd door donny007 op 23 juli 2024 03:54]

[Verwijderd]

Dus ze zijn kwetsbaar maar worden desondanks niet gehackt? Wat is er dan nog meer mis met die systemen?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:54]

[Pietervs]

Dus ze zijn kwetsbaar maar worden desondanks niet gehackt?
Dus ze zijn kwetsbaar maar worden zijn desondanks nog niet gehackt?

FTFY

[.je]

Helaas ben je bij mobiele technologie zo ontzettend afhankelijk van de leverancier en het updaten van hun ROM.

Zo zou je bijvoorbeeld deze applicatie op een android kunnen proberen.

Mijn geluk is dat OnePlus daar nog vrij vaak updates voor vrijgeeft. Helaas is dat volledig fabrikant en/of leverancier afhankelijk.

[Verwijderd]

In het artikel staat dat het lek er zo'n 2 jaar in heeft gezeten, en er nu nog steeds zo'n 200000 servers niet gepatched zijn.

Wat ik me daarbij afvraag is hoeveel servers er een nog veel oudere versie van OpenSSL draaien waar Heartbleed nog niet in zat, maar wel andere kwetsbaarheden.

[jurroen]

Of hoeveel servers er andere kwetsbaarheden hebben, die niets met 'Heartbleed' te maken hebben. Zoals Shellshock, om maar iets te noemen. Maak een anoniem account aan, betaal met bitcoin of een creditcard van een ander (ofwel een 'gehackte'), et voila, root toegang.

Een van de vele mogelijke scenario's. Tijd dat beheerders hun zaken op orde stellen.

[mutley69]

Zo heeft een bepaald groot copier fabrikant na 3 jaar! nog altijd geen patch voor de P00dle-bug - en https - met wat recente cyphers - nooit van gehoord mijnheer... En dan staan we stom dat er IoT-malwares opduiken die printers, webcams, routers e.a. misbruiken - maar dankzij de neo-liberale doctrines dat de markt alles oplost - hebben we geen oplossingen. Nl. De staat moet verplichten om x-jaar updates te leveren!