Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Code execution?
06-07-2021, 13:54 door Anoniem, 34 reacties
Wat betekent: Beperk de mogelijkheden van code execution?
En hoe beschermt dit mij tegen ransomware?
En hoe beschermt dit mij tegen ransomware?
Reacties (34)
06-07-2021, 14:24 door
MathFox
Door Anoniem: Wat betekent: Beperk de mogelijkheden van code execution?
En hoe beschermt dit mij tegen ransomware?
Wat is de context van deze vraag? Wil je concreet advies over het "hardenen" van Linux, gaat het om bescherming van een bedrijfsnetwerk of is dit een schoolopdracht?En hoe beschermt dit mij tegen ransomware?
Code execution betekend dat een potentiele aanvaller commando's kan uitvoeren met jouw rechten op het systeem en in theorie zijn rechten kunnen verhogen naar ROOT of SYSTEM (hoogste rechten). Dat is zeer ernstig.
Als je de mogelijkheden van code execution niet beperkt, kan iedere code ongehinderd aan het werk op jouw computer. Dat is wel makkelijk, maar niet veilig. Ransomware wil files op je computer versleutelen, en dat wordt uitgevoerd (execution) door een versleutelingsprogramma (code). Dat wil je uiteraard niet.
Als je OS nu zo is ontworpen dat het code pas laat uitvoeren nadat het om je wachtwoord (als user, of als root) heeft gevraagd, kan je zelf steeds bepalen of dat programma echt moet worden uitgevoerd.
Ransomware wil onopgemerkt blijven, dus zal het niet vragen om je wachtwoord, je bent dan direct gealarmeerd.
Een vorm van bescherming tegen ransomware is dus dat jouw OS aan jou vraagt om je wachtwoord bij code execution: "programma XX wil code uitvoeren, wat is je wachtwoord?"
De gelabelde code van het OS (de kernel) heeft standaard toestemming (vastgelegd in een tabel) om code uit te voeren, anders moet je voortdurend je wachtwoord intikken, dat is onwerkzaam.
Als je OS nu zo is ontworpen dat het code pas laat uitvoeren nadat het om je wachtwoord (als user, of als root) heeft gevraagd, kan je zelf steeds bepalen of dat programma echt moet worden uitgevoerd.
Ransomware wil onopgemerkt blijven, dus zal het niet vragen om je wachtwoord, je bent dan direct gealarmeerd.
Een vorm van bescherming tegen ransomware is dus dat jouw OS aan jou vraagt om je wachtwoord bij code execution: "programma XX wil code uitvoeren, wat is je wachtwoord?"
De gelabelde code van het OS (de kernel) heeft standaard toestemming (vastgelegd in een tabel) om code uit te voeren, anders moet je voortdurend je wachtwoord intikken, dat is onwerkzaam.
Door Anoniem: Wat betekent: Beperk de mogelijkheden van code execution?
En hoe beschermt dit mij tegen ransomware?
En hoe beschermt dit mij tegen ransomware?
Ransom ware op Linux of Windows?
Je stelt een vraag die te algemeen is. Ik adviseer lees eerst een aantal boeken over cybersecurity.
Als je zelf de antwoorden niet kunt vinden ben je ook niet in staat om jezelf te beschermen. Dus dan blijf jij overgeleverd aan criminele kl**tzakjes.
Ik heb meer context nodig, maar ik ga de vertaal slag proberen te maken voor je:
- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
22-07-2021, 13:50 door
Erik van Straten
Door Anoniem: Wat betekent: Beperk de mogelijkheden van code execution?
"Code execution" is het uitvoeren van voorgeschreven opdrachten. Voorbeelden, als ik schrijf: "neem een bak koffie" of "wacht tot je een ons weegt" en jij doet dat.Wat bedoel je trouwens? En/of:
1) Undesirable en/of malicious code execution (in de zin van het uitvoeren van ongewenste en/of kwaadaardige code). Voorbeelden: uitvoeren van Javascript vanaf een third party analytics website die alles registreert wat jij doet op een website, of het uitvoeren van een kwaadaardige macro in een MS Word document;
2) Execution of legitimate code for undesirable en/of malicious intent (uitvoeren van legitieme code voor een ongewenst en/of kwaadaardig doel). Voorbeelden: een app die jouw locatiegegevens aan bijv. de app-maker doorgeeft terwijl dat helemaal niet nodig is voor de beloofde functionaliteit, of het gebruik van bitlocker om jouw systeem te versleutelen door een cybercrimineel die vervolgens losgeld eist voor het vrijgeven van de sleutel.
22-07-2021, 14:28 door
walmare
Door Anoniem: Ik heb meer context nodig, maar ik ga de vertaal slag proberen te maken voor je:
- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
De initiele problemen ontstaan meestal in de user env . Daarom is het (onder linux) handig als je eigen $HOME en /tmp gemount zijn met de noexec flag.- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
Door walmare:
De initiele problemen ontstaan meestal in de user env . Daarom is het (onder linux) handig als je eigen $HOME en /tmp gemount zijn met de noexec flag.
Alleen jammer dat dit niets helpt tegen uitvoeren van "scripts" door middel van een reeds geinstalleerde interpreterDe initiele problemen ontstaan meestal in de user env . Daarom is het (onder linux) handig als je eigen $HOME en /tmp gemount zijn met de noexec flag.
op het systeem (bijv Perl, Python, PHP etc).
Ook jammer dat dit gebonden is aan mountpoints, ipv dat je ergens een padnamenlijst kunt opgeven waarvoor dit
actief is. Het is vaak onpraktisch om alles waar je niet wilt dat er code staat apart te gaan mounten.
Door walmare:
Dan download je veel gebruikte apps als discord, spotify of bezoek je perongelijk een leuke website, en dan word er als nog een malicieuze dependancie geinstalleerd of css/js code gedraait. IT kan niet "compleet veilig" het kan wel moeilijker gemaakt worden voor ze.Door Anoniem: Ik heb meer context nodig, maar ik ga de vertaal slag proberen te maken voor je:
- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
De initiele problemen ontstaan meestal in de user env . Daarom is het (onder linux) handig als je eigen $HOME en /tmp gemount zijn met de noexec flag.- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
Wat als je een HTML pagina voorgeschoteld krijgt met een out of bound kwetsbaarheid die code execution mogelijk maakt en je browser is daar nog niet voor gepatched en geupdate? Kun je je niet tegen beschermen lijkt me.
Door Anoniem: Wat als je een HTML pagina voorgeschoteld krijgt met een out of bound kwetsbaarheid die code execution mogelijk maakt en je browser is daar nog niet voor gepatched en geupdate? Kun je je niet tegen beschermen lijkt me.
Daar zijn apparmor, appvm, firejail of de sandbox voor uitgevonden. Volgens het principe van isolatie van processen.
Door Anoniem: Wat als je een HTML pagina voorgeschoteld krijgt met een out of bound kwetsbaarheid die code execution mogelijk maakt en je browser is daar nog niet voor gepatched en geupdate? Kun je je niet tegen beschermen lijkt me.
wel met https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-security-enhanced_linux-securing_programs_using_sandbox
Door Anoniem:
Dat kan niet want daar heb je geen rechten voor als normale of systeem gebruiker. Je kan de malware wel downloadenDoor walmare:
Dan download je veel gebruikte apps als discord, spotify of bezoek je perongelijk een leuke website, en dan word er als nog een malicieuze dependancie geinstalleerd of css/js code gedraait. IT kan niet "compleet veilig" het kan wel moeilijker gemaakt worden voor ze.Door Anoniem: Ik heb meer context nodig, maar ik ga de vertaal slag proberen te maken voor je:
- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
De initiele problemen ontstaan meestal in de user env . Daarom is het (onder linux) handig als je eigen $HOME en /tmp gemount zijn met de noexec flag.- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
maar niet executeren want onder Linux komt alles readonly binnen. Er zal dus ook actie moeten worden ondernomen om de malware execute rechten te geven. Dan nog kan deze niet worden uitgevoerd omdat $HOME en /tmp met noexe flag zijn gemount. Voor een script geldt dat de interpreter moet worden aangeroepen buiten de $HOME maar een gedownload bestand kan niet worden uitgevoerd, dus ook geen script. Daarnaast kan je nog veel met SELinux doen om de execute rechten verder te beperken.
Gebruikers die alleen webbased werken kan je ook nog een readonly home geven. Daarnaast stop je de browser in een aparte container. Die container moet je dus automatisch fixen zo snel er een nieuwe fix beschikbaar is. Daar hoef je geen OTAP straat voor in te richten :)
Door walmare:
maar niet executeren want onder Linux komt alles readonly binnen. Er zal dus ook actie moeten worden ondernomen om de malware execute rechten te geven. Dan nog kan deze niet worden uitgevoerd omdat $HOME en /tmp met noexe flag zijn gemount. Voor een script geldt dat de interpreter moet worden aangeroepen buiten de $HOME maar een gedownload bestand kan niet worden uitgevoerd, dus ook geen script. Daarnaast kan je nog veel met SELinux doen om de execute rechten verder te beperken.
Gebruikers die alleen webbased werken kan je ook nog een readonly home geven. Daarnaast stop je de browser in een aparte container. Die container moet je dus automatisch fixen zo snel er een nieuwe fix beschikbaar is. Daar hoef je geen OTAP straat voor in te richten :)
Door Anoniem:
Dat kan niet want daar heb je geen rechten voor als normale of systeem gebruiker. Je kan de malware wel downloadenDoor walmare:
Dan download je veel gebruikte apps als discord, spotify of bezoek je perongelijk een leuke website, en dan word er als nog een malicieuze dependancie geinstalleerd of css/js code gedraait. IT kan niet "compleet veilig" het kan wel moeilijker gemaakt worden voor ze.Door Anoniem: Ik heb meer context nodig, maar ik ga de vertaal slag proberen te maken voor je:
- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
De initiele problemen ontstaan meestal in de user env . Daarom is het (onder linux) handig als je eigen $HOME en /tmp gemount zijn met de noexec flag.- Code execution betekend "simpelweg" dat een potentiele aanvaller code kan uitvoeren op een systeem of applicatie omdat deze kwetsbaar is tot een CE kwetsbaarheid.
Zodoende kan de aanvaller mogelijk code en commando's uitvoeren en dus mogelijk toegang verkrijgen tot een applicatie of geheel systeem. De impact is echter puur "case by case, app by app". RCE (remote code execution) is hetzelfde maar dan niet lokaal op een systeem, maar vanuit een netwerk perspectief. Bijvoorbeeld door het sturen van speciaal geprepareerde netwerk packets.
(Meestal komt dit voor als een applicatie of service nooit geupdate word en kwetsbaar raakt voor zware "RCE kwetsbaarheden en dus mogelijk Exploits" of wanneer een applicatie of service haar "user input" niet genoeg valideert of filtert, denk bijvoorbeeld aan SQLi.)
Hoe beschermt dit mij tegen Ransomware? <- Oke wacht ho boem stop. Ik vermoed dat je een stukje cognitiviteit mist op dit gebied. (Ik noem je zeker niet dom of iets in die trant, maar het klinkt alsof je er geen ervaring mee hebt).
Je moet veel doen om Ransomware "voor" te zijn of tegen te houden. Denk aan back-ups, updates, AV, user awareness and training jada jada. Maar ik denk dat je hetvolgende scenario zoekt:
Web applicatie (of andere remote applicatie) is niet up to date en bevat een RCE kwetsbaarheid -> hacker scanned netwerk en ziet de RCE kwetsbare applicatie -> hacker zoekt exploitcode/poc -> breekt in op de applicatie/server > probeert met andere hack truukjes zijn rechten te verhogen op het lokale systeem of de rest van het netwerk -> Met genoeg rechten kan de malicieuze hacker nu ransomware over het hele netwerk uitrollen. Denk bij genoeg rechten aan locale administrator rechten, domain administrator rechten etc.
maar niet executeren want onder Linux komt alles readonly binnen. Er zal dus ook actie moeten worden ondernomen om de malware execute rechten te geven. Dan nog kan deze niet worden uitgevoerd omdat $HOME en /tmp met noexe flag zijn gemount. Voor een script geldt dat de interpreter moet worden aangeroepen buiten de $HOME maar een gedownload bestand kan niet worden uitgevoerd, dus ook geen script. Daarnaast kan je nog veel met SELinux doen om de execute rechten verder te beperken.
Gebruikers die alleen webbased werken kan je ook nog een readonly home geven. Daarnaast stop je de browser in een aparte container. Die container moet je dus automatisch fixen zo snel er een nieuwe fix beschikbaar is. Daar hoef je geen OTAP straat voor in te richten :)
Dat is helemaal tof, alleen schets ik toch het voorbeeld van "normaal gebruik" waarin een eigenaar een applicatie installeerd en dus onbedoeld malware mee installeert.
Daarbij kan je je browser wel in een selinux docker redhat binnelandsezaken wannabe environment runnen, maar dan toch kan de browser gepowned worden en kunnen sessies en wachtwoorden vergaart worden (met bijvoorbeeld een lekke website en iframing, xss, zeroclick exploits jada jada). Dat is grappig, want iedereen gebruikt tegenwoordig o365 met domein rechten :). Maar tuurlijk! Je perkt wel het een en ander in, zoals je eigen tijd.
(Ik ben het met je eens, maar de baten zijn te laag voor de kosten en handen die je er aan moet besteden. Daarbij ben je toch niet 100% onhackbaar.
Heb jij wel eens op een linux server/machine DoT en DNSSEC gezien in een bedrijfs omgeving? Ik in iedergeval niet. Dit gepaart met geautomatiseerde updates met update -y dist/full upgrade -y kan toch echt lijden tot het installeren van unsigned kernels en andere meuk. Maar gelukkig is dat maar een full system compromise, en dan nog te spreken over PEGASUS streken lol.)
Wapenen tegen statelijke actoren, pro black hat penetratie testers met grote budgetten etc is toch niet te doen. Als ze genoeg geld aan je willen besteden dan winnen ze. Komen ze niet binnen? Dan schoppen ze je admin wel in elkaar of framen ze hem de moeder in...
Door Anoniem: Wat betekent: Beperk de mogelijkheden van code execution?
En hoe beschermt dit mij tegen ransomware?
En hoe beschermt dit mij tegen ransomware?
Het komt door dat half Nederlands, half Engels. Vertaal de gehele zin naar het Nederlands. Dan krijg je "beperk de mogelijkheden tot het uitvoeren van programmacode". Dan is het meteen intuïtief duidelijk wat er wordt bedoeld (malware en ransomware bestaan ook uit programmacode).
25-07-2021, 08:58 door
karma4
Door Toje Fos:
Het komt door dat half Nederlands, half Engels. Vertaal de gehele zin naar het Nederlands. Dan krijg je "beperk de mogelijkheden tot het uitvoeren van programmacode". Dan is het meteen intuïtief duidelijk wat er wordt bedoeld (malware en ransomware bestaan ook uit programmacode).
Goed antwoord, Het geeft meteen een nieuw probleem aan, wat is programmacode? Door Anoniem: Wat betekent: Beperk de mogelijkheden van code execution?
En hoe beschermt dit mij tegen ransomware?
En hoe beschermt dit mij tegen ransomware?
Het komt door dat half Nederlands, half Engels. Vertaal de gehele zin naar het Nederlands. Dan krijg je "beperk de mogelijkheden tot het uitvoeren van programmacode". Dan is het meteen intuïtief duidelijk wat er wordt bedoeld (malware en ransomware bestaan ook uit programmacode).
In de begintijd van de ICT (jaren 80) was er het dogma dat source code statisch is en eerst gecompileerd moet worden apart statisch gelinked aan beschikbare routines zodat je "het programma" krijgt. Die tijd is voorbij en achterhaald.
SQL (Sequel / Structured Query Language) is een voorbeeld van interactief (JIT) gedrag SQL code injection is al tijden het grootste probleem met kwetsbaarheden via internet.
Code injection gaat voor elke moderne taal op als potentiele dreiging PHP HTML XML het maakt weinig uit.
De vele processen op de tegenwoordige machines communiceren onderling via dat soort talen.
Wat rest is de normale aanpak.
- segmentatie netwerk en via heldere autorisatie regels
- beperkte set van enkele benodigde processen
- eenvoudig snel kunnen heropbouwen van complete omgevingen (DIR)
Het is de CIA met een V van verifiable dan wel BIV met een C controleerbaar. De Bio geeft een goed overzicht.
25-07-2021, 09:06 door
karma4
Door walmare:
Dat kan niet want daar heb je geen rechten voor als normale of systeem gebruiker. Je kan de malware wel downloaden
maar niet executeren want onder Linux komt alles readonly binnen. Er zal dus ook actie moeten worden ondernomen om de malware execute rechten te geven. .....
Die beperkte wereld is al lang verleden tijd. Ik nog nooit SQL door selinux afgehandeld zien worden, toch is dat de topper in code injection. Een stukje verder met een DBMS en je krijgt de modules in de database te pakken, denk eens aan python.Dat kan niet want daar heb je geen rechten voor als normale of systeem gebruiker. Je kan de malware wel downloaden
maar niet executeren want onder Linux komt alles readonly binnen. Er zal dus ook actie moeten worden ondernomen om de malware execute rechten te geven. .....
Heb je de rechten van het DBMS dan zijn alle relevante informatie eenvoudig te verkrijgen. De nosql databases en andere zijn de notoire massale datalekken. Wil je de DBMS rechten het systeem onderuit halen dan zal dat ook wel lukken. DMBS rechten lopen niet als gewone gebruiker. Vaak zeer hoge systeemrechten wegens de eenvoud.
Door karma4:
In de begintijd van de ICT (jaren 80) was er het dogma dat source code statisch is en eerst gecompileerd moet worden apart statisch gelinked aan beschikbare routines zodat je "het programma" krijgt. Die tijd is voorbij en achterhaald.
Door Toje Fos:
Het komt door dat half Nederlands, half Engels. Vertaal de gehele zin naar het Nederlands. Dan krijg je "beperk de mogelijkheden tot het uitvoeren van programmacode". Dan is het meteen intuïtief duidelijk wat er wordt bedoeld (malware en ransomware bestaan ook uit programmacode).
Goed antwoord, Het geeft meteen een nieuw probleem aan, wat is programmacode? Door Anoniem: Wat betekent: Beperk de mogelijkheden van code execution?
En hoe beschermt dit mij tegen ransomware?
En hoe beschermt dit mij tegen ransomware?
Het komt door dat half Nederlands, half Engels. Vertaal de gehele zin naar het Nederlands. Dan krijg je "beperk de mogelijkheden tot het uitvoeren van programmacode". Dan is het meteen intuïtief duidelijk wat er wordt bedoeld (malware en ransomware bestaan ook uit programmacode).
In de begintijd van de ICT (jaren 80) was er het dogma dat source code statisch is en eerst gecompileerd moet worden apart statisch gelinked aan beschikbare routines zodat je "het programma" krijgt. Die tijd is voorbij en achterhaald.
Waar, echter dat gaat niet op voor systeemsoftware (zoals het besturingssysteem).
Door karma4: SQL (Sequel / Structured Query Language) is een voorbeeld van interactief (JIT) gedrag SQL code injection is al tijden het grootste probleem met kwetsbaarheden via internet.
Code injection gaat voor elke moderne taal op als potentiele dreiging PHP HTML XML het maakt weinig uit.
De vele processen op de tegenwoordige machines communiceren onderling via dat soort talen.
Code injection gaat voor elke moderne taal op als potentiele dreiging PHP HTML XML het maakt weinig uit.
De vele processen op de tegenwoordige machines communiceren onderling via dat soort talen.
Dat is ook waar, echter dat soort software draait - als het goed is - binnen de grenzen van een sandbox of met beperkte rechten en heeft geen mogelijkheden om daaruit te breken. Mits de onderliggende systeemsoftware afdoende robuust en veilig is natuurlijk. Zoniet, dan volgt een uitbraak naar het niveau van de systeemsoftware, waardoor je volledige controle over het systeem krijgt, met alle consequenties van dien.
Door Toje Fos: Waar, echter dat gaat niet op voor systeemsoftware (zoals het besturingssysteem).
Voor de beschikbaarheid van een dienst maakt het weinig uit waar het in de keten mis gaat.Deze week was door een foutje (en bedankt) bij Akamai de halve wereld op internet niet meer beschikbaar.
Lastiger wordt het systeemsotware te definieren. Wifi? IO-driver USb? DBMS? Een gekopieerde functie librarie? R python? Wordpress plug in? Browser? Oj je beperkt het tot iets onwerkbaars of je krijgt het geheel.
Leef je uit met: https://public.cyber.mil/stigs/downloads/ en https://www.stigviewer.com/stig/application_security_and_development/
Dat is ook waar, echter dat soort software draait - als het goed is - binnen de grenzen van een sandbox of met beperkte rechten en heeft geen mogelijkheden om daaruit te breken. Mits de onderliggende systeemsoftware afdoende robuust en veilig is natuurlijk. Zoniet, dan volgt een uitbraak naar het niveau van de systeemsoftware, waardoor je volledige controle over het systeem krijgt, met alle consequenties van dien.
Nog steeds (zie de links) verwijder services die niet nodig zijn etc. Let op met die aanbevelingen, wat daar genoemd wordt als een applicatie die aan sessiebeheer moet doen valt vanuit een ander standpunt onder systeemsoftware. Apache Tomcat en meer van dat soort technische tools zit in de keten van het informatieysteem maar ik zie het echt niet als iets voor UX applicatiebouwer. Daar gaat het zo vaak fout dat er niets aan gebeurt. De onderliggende sandbox gaat gewoon mee onderuit zeker in het geval met admins die alles met alle rechten doen.Door walmare:
Dat kan niet want daar heb je geen rechten voor als normale of systeem gebruiker. Je kan de malware wel downloaden
maar niet executeren want onder Linux komt alles readonly binnen. Er zal dus ook actie moeten worden ondernomen om de malware execute rechten te geven. Dan nog kan deze niet worden uitgevoerd omdat $HOME en /tmp met noexe flag zijn gemount. Voor een script geldt dat de interpreter moet worden aangeroepen buiten de $HOME maar een gedownload bestand kan niet worden uitgevoerd, dus ook geen script.
Dat klopt niet hoor! Als je he voor elkaar kunt krijgend at een gebruiker een script download en dan ook dat de interpreterDat kan niet want daar heb je geen rechten voor als normale of systeem gebruiker. Je kan de malware wel downloaden
maar niet executeren want onder Linux komt alles readonly binnen. Er zal dus ook actie moeten worden ondernomen om de malware execute rechten te geven. Dan nog kan deze niet worden uitgevoerd omdat $HOME en /tmp met noexe flag zijn gemount. Voor een script geldt dat de interpreter moet worden aangeroepen buiten de $HOME maar een gedownload bestand kan niet worden uitgevoerd, dus ook geen script.
voor dergelijke scripts wordt aangeroepen met de naam als parameter, dan werkt dat gewoon ook als je script geen
execute permissie heeft.
Wat niet werkt is een script wat begint met "#!/usr/bin/perl -w" aanroepen door alleen de naam van het script maar wat
wel werkt is een script trojan.pl downloaden en dan "perl trojan.pl" aanroepen. Dat werkt als trojan.pl "niet executable" is.
(perl is hier maar een voorbeeld, er zijn talloze andere script interpreters)
Die "no execute" beveiliging is dus maar een lapmiddel met beperkt effect.
Door karma4: Goed antwoord, Het geeft meteen een nieuw probleem aan, wat is programmacode?
In de begintijd van de ICT (jaren 80) was er het dogma dat source code statisch is en eerst gecompileerd moet worden apart statisch gelinked aan beschikbare routines zodat je "het programma" krijgt. Die tijd is voorbij en achterhaald.
De jaren '80 waren niet de begintijd van ICT, dat bestond al decennia, al werd de term ICT pas later geïntroduceerd.In de begintijd van de ICT (jaren 80) was er het dogma dat source code statisch is en eerst gecompileerd moet worden apart statisch gelinked aan beschikbare routines zodat je "het programma" krijgt. Die tijd is voorbij en achterhaald.
Toen ik in de jaren '80 in een mainframeomgeving ging werken als computerprogrammeur:
• gebruikten we meerdere geïnterpreteerde talen: CLIST, REXX, JCL (Job Control Language);
• maakten we in talen als COBOL, PL/1 en Assembler dynamisch gelinkte software: hoofd- en subprogramma's werden apart gecompileerd/geassembleerd en op runtime dynamisch gelinkt;
• hadden we geen enkele moeite met de definitie van programmacode: een computerprogramma is een verzameling instructies voor de computer om een taak uit te voeren, of het nou broncode, objectcode, een executable is (dat zijn verschillende vormen van het programma, en die kan je allemaal met de term programmacode aanduiden) en of er nou een compiler en linker of een interpreter nodig zijn om het uitgevoerd te krijgen.
Het dogma dat het gecompileerd en statisch gelinkt moest zijn bestond helemaal niet, dus dat maakt van de vraag wat programmacode is geen nieuw probleem, en zoals ik al aangaf was het helemaal geen probleem. Volgens mij is het dat nog steeds niet.
Door karma4: Die beperkte wereld is al lang verleden tijd. Ik nog nooit SQL door selinux afgehandeld zien worden, toch is dat de topper in code injection.
SELinux is een implementatie van Linux Security Modules, een framework om acces-control van kernel-objecten te regelen. SQL-queries zijn communicatie tussen twee userland-programma's, het DMBS en de client die er verbinding mee maakt. Ik ben zeker geen SELinux-expert, maar ik vind het op basis hiervan niet direct logisch dat SQL-queries inhoudelijk beoordelen binnen de scope van dat framework zou moeten vallen.En waar men niet genoeg weet om prepared statements en stored procedures toe te passen, zou men daar wel genoeg weten om SELinux toe te passen als het daarmee te regelen was?
25-07-2021, 15:19 door
Erik van Straten
Door Toje Fos: [...] Mits de onderliggende systeemsoftware afdoende robuust en veilig is natuurlijk. Zoniet, dan volgt een uitbraak naar het niveau van de systeemsoftware, waardoor je volledige controle over het systeem krijgt, met alle consequenties van dien.
Stel jij woont in de UK, hebt een wapenvergunning en hebt een vuurwapen gekocht bij Guntraders. Dan ligt nu op straat van jou (uit https://www.theregister.com/2021/07/23/guntrader_hacked_111k_users_sql_database/):[...]
- Latitude and longitude data
- First name and last name
- Police force that issued an RFD's certificate
- Phone numbers
- Fax numbers
- bcrypt-hashed passwords
- Postcode
- Postal addresses
- User's IP addresses
Logs of payments were also included, with Coalfire's Barratt explaining that while no credit card numbers were included, something that looks like a SHA-256 hashed string was included in the payment data tables. [...]
(als het bij dat laatste daadwerkelijk om hashes van creditcardnummers + CCV gaat, zijn die waarschijnlijk te reversen).- Latitude and longitude data
- First name and last name
- Police force that issued an RFD's certificate
- Phone numbers
- Fax numbers
- bcrypt-hashed passwords
- Postcode
- Postal addresses
- User's IP addresses
Logs of payments were also included, with Coalfire's Barratt explaining that while no credit card numbers were included, something that looks like a SHA-256 hashed string was included in the payment data tables. [...]
Als Guntraders een briljant dichtgetimmerd Linux systeem gebruikt, dat zelf niet gecompromitteerd is (of lijkt) bij deze aanval, dan is er dus volgens jou niets aan de hand en hoef jij je persoonlijk nergens zorgen om te maken.
Welk deel van het woord INFORMATIEBEVEILIGING begrijp jij niet?
25-07-2021, 16:34 door
karma4
Door Anoniem: De jaren '80 waren niet de begintijd van ICT, dat bestond al decennia, al werd de term ICT pas later geïntroduceerd.
Het was al wat ouder, E.Dijkstra Algol PDP7 gebruik ponskaarten ringkernen Unix (1960) waen ouder. Met de 4040 6502 werd het pas betaalbaar, mainframes IBM de overheersende invulling. Toen ik in de jaren '80 in een mainframeomgeving ging werken als computerprogrammeur:
Leuk, echt de begintijd overgang VS1 MVS de 8 inch floppen nog gezien? " en op runtime dynamisch gelinkt;"Die overgang was echt iets laten daarna had je nog de LE overgang. Met een lockin op procedures was de dynamische lnk niet vanzelfsprekend. De overgang van assembler naar cobol was voor sommigen al lastig.
kan je allemaal met de term programmacode aanduiden) en of er nou een compiler en linker of een interpreter nodig zijn om het uitgevoerd te krijgen.
Rexx werd niet gecompileerd dat gaf naast wat ander talen (JCL) flinke uitdagingen.Je omschrijving van een programmeertaal gaat uit van een statisch iets. Rexx kent de interpret functie waarmee je taal van buiten kan laten komen zoals SQL met websites. Het maakt het dynamisch, code injection is daarbij een aandachtspunt.
Mainframe Assembler kent de ex opdracht (opcode 44) mainframe. Code onder je handen dynamisch veranderen.
Iets wat je dynamisch kan aanpassen valt mij niet onder een duidelijke definitie.
Een terugkoppellus in een ML aanpak lijkt me ook lastig te definiëren. Als je gegevens de bron zijn om van te leren dan is dat wat je uit productie haalt als informatie ineens broncode.
Door karma4:
Goed. Met dit, en alles wat je verder in deze reactie schrijft, bevestig je wat ik tegen je eerdere reactie inbracht: niet alleen gecompileerde talen, niet alleen statisch gelinkt, en dus niet het dogma dat je noemde. Zoals je reageert lijkt het wel alsof je zelf niet meer weet dat je dat geschreven had. Je kan het hierboven teruglezen.Door Anoniem: De jaren '80 waren niet de begintijd van ICT, dat bestond al decennia, al werd de term ICT pas later geïntroduceerd.
Het was al wat ouder, E.Dijkstra Algol PDP7 gebruik ponskaarten ringkernen Unix (1960) waen ouder. Met de 4040 6502 werd het pas betaalbaar, mainframes IBM de overheersende invulling.
25-07-2021, 16:43 door
karma4
Door Anoniem: ... En waar men niet genoeg weet om prepared statements en stored procedures toe te passen, zou men daar wel genoeg weten om SELinux toe te passen als het daarmee te regelen was?
Je geeft exact aan waar het gat in de informatiebeveiliging zo vaak ontstaat. De gangbare driehoek:
=I= Infrastructuur mensen: wij zetten een veilig systeem naar onze inzichten neer.
... Manager, mooi dan hoeven andere daar geen aandacht meer aan te besteden.
=A= Applicatie bouwers (UX): wij krijgen een system met allerleis tools voor een fraai te bouwen presentatie naar de afnemers / gebruikers. Het invullen van een veilig controleerbaar iets is iets voor anderen.
=C= De tools DBMS even er snel bijzetten want de manager eist dat en andere zorgen wel dat het veilig is.
Een driehoek waar je niet alles tegelijkertijd goed kan doen. De CIA zal geen invulling krijgen.
Ik heb een alternatieve invulling van de 3 letters gegeven, het komt zo te zien goed uit.
Hackers krijgen de kans omdat de C ontbreekt.
25-07-2021, 21:38 door
walmare
Door Erik van Straten:
Als Guntraders een briljant dichtgetimmerd Linux systeem gebruikt, dat zelf niet gecompromitteerd is (of lijkt) bij deze aanval, dan is er dus volgens jou niets aan de hand en hoef jij je persoonlijk nergens zorgen om te maken.
Welk deel van het woord INFORMATIEBEVEILIGING begrijp jij niet?
Niets aan de hand? Dat zegt hij helemaal niet. Lezen blijkt zo moeilijk als het over iemands favoriete systeem gaat.Door Toje Fos: [...] Mits de onderliggende systeemsoftware afdoende robuust en veilig is natuurlijk. Zoniet, dan volgt een uitbraak naar het niveau van de systeemsoftware, waardoor je volledige controle over het systeem krijgt, met alle consequenties van dien.
Stel jij woont in de UK, hebt een wapenvergunning en hebt een vuurwapen gekocht bij Guntraders. Dan ligt nu op straat van jou (uit https://www.theregister.com/2021/07/23/guntrader_hacked_111k_users_sql_database/):[...]
- Latitude and longitude data
- First name and last name
- Police force that issued an RFD's certificate
- Phone numbers
- Fax numbers
- bcrypt-hashed passwords
- Postcode
- Postal addresses
- User's IP addresses
Logs of payments were also included, with Coalfire's Barratt explaining that while no credit card numbers were included, something that looks like a SHA-256 hashed string was included in the payment data tables. [...]
(als het bij dat laatste daadwerkelijk om hashes van creditcardnummers + CCV gaat, zijn die waarschijnlijk te reversen).- Latitude and longitude data
- First name and last name
- Police force that issued an RFD's certificate
- Phone numbers
- Fax numbers
- bcrypt-hashed passwords
- Postcode
- Postal addresses
- User's IP addresses
Logs of payments were also included, with Coalfire's Barratt explaining that while no credit card numbers were included, something that looks like a SHA-256 hashed string was included in the payment data tables. [...]
Als Guntraders een briljant dichtgetimmerd Linux systeem gebruikt, dat zelf niet gecompromitteerd is (of lijkt) bij deze aanval, dan is er dus volgens jou niets aan de hand en hoef jij je persoonlijk nergens zorgen om te maken.
Welk deel van het woord INFORMATIEBEVEILIGING begrijp jij niet?
Hij zegt dat als het onderliggende systeem niet afdoende robuust is, er een uitbraak naar het niveau van de systeemsoftware volgt, waardoor hackers volledige controle over het systeem krijgen en alles dus kunnen versleutelen incl de backup hetgeen wij bijna dagelijks op security.nl kunnen lezen.
Dan ben je dus alles kwijt en kan je alles opnieuw gaan installeren. Dat is toch van aan andere orde dan bv een backup terugzetten van een applicatie.
Vreemd dat er nog steeds schepen rondvaren zonder compartimenten. 1 gaatje en het hele boeltje zinkt. Waarschijnlijk wilt men deze dure schepen niet in 1 keer afschrijven. Dan loop je risico en wordt er meestal losgeld betaald, waardoor de premie weer omhoog moet en wij er weer voor opdraaien en het oligopolie gewoon verder kan gaan met het door de strot duwen van deze ongein.
Door karma4:
De gangbare driehoek: [samengevat: I van Infrastructuur, A van Applicatiebouwers, C van Tools(???)]
Een driehoek waar je niet alles tegelijkertijd goed kan doen. De CIA zal geen invulling krijgen.
Ik heb een alternatieve invulling van de 3 letters gegeven, het komt zo te zien goed uit.
Hackers krijgen de kans omdat de C ontbreekt.
Wat daar ontbreekt is de M van Management dat zorgt dat alle verantwoordelijkheden belegd zijn en in de gaten houdt dat alle noodzakelijke taken ook werkelijk uitgevoerd worden. Dat los je niet op met SELinux. Daar heb je trouwens nog een S van Security administrators voor nodig met grondige kennis van zaken, en die moeten onafhankelijk van applicatiebouwers en infrastructuurmensen zijn. Een goede DBA is ook niet te versmaden trouwens als je je zaken goed dicht wilt timmeren. Je driehoek groeit uit tot minimaal een zeshoek.Door Anoniem: ... En waar men niet genoeg weet om prepared statements en stored procedures toe te passen, zou men daar wel genoeg weten om SELinux toe te passen als het daarmee te regelen was?
Je geeft exact aan waar het gat in de informatiebeveiliging zo vaak ontstaat. De gangbare driehoek: [samengevat: I van Infrastructuur, A van Applicatiebouwers, C van Tools(???)]
Een driehoek waar je niet alles tegelijkertijd goed kan doen. De CIA zal geen invulling krijgen.
Ik heb een alternatieve invulling van de 3 letters gegeven, het komt zo te zien goed uit.
Hackers krijgen de kans omdat de C ontbreekt.
Over SELinux schreef je:
Door karma4: Ik nog nooit SQL door selinux afgehandeld zien worden, toch is dat de topper in code injection.
Ik antwoordde:Door Anoniem: SELinux is een implementatie van Linux Security Modules, een framework om acces-control van kernel-objecten te regelen. SQL-queries zijn communicatie tussen twee userland-programma's, het DMBS en de client die er verbinding mee maakt. Ik ben zeker geen SELinux-expert, maar ik vind het op basis hiervan niet direct logisch dat SQL-queries inhoudelijk beoordelen binnen de scope van dat framework zou moeten vallen.
Ik heb inmiddels in de PostgreSQL-documentatie[1] gelezen dat SELinux een interface voor applicaties heeft, zodat die er ook van gebruik kunnen maken. Als het gebruikte DBMS het ondersteunt kunnen database-objecten dus inderdaad met SELinux beveiligd worden.Ik zie in de referentie-pagina[2] overigens niets staan dat code injection afvangt. Wat ik daar ook niet uit haal is hoe toegang tot data op basis van inhoud kan worden beveiligd. Hoe regel je dat de klant van de webwinkel alleen haar eigen bestellingen kan opvragen? Hoe regel je dat de bankrekeninghouder alleen zijn eigen rekeningen kan inzien?
In SEPostgreSQL zal je dus nog steeds met stored procedures, prepared statements en de applicatiecode van waaruit de database wordt benaderd zelf moeten werken om dat te voorkomen. SELinux is daar in ieder geval bij SEPostgreSQL geen alternatief voor.
Wist jij dat SELinux een interface voor applicaties heeft? Waarom meldde je dat dan niet even toen je merkte dat ik dat niet wist?
En nog een vraag: ken jij een DBMS dat wél via SELinux code injection kan voorkomen? Of klopt mijn sterke vermoeden dat stored procedures en prepared statements hoe dan ook nodig blijven om het goed dicht te timmeren?
[1] https://wiki.postgresql.org/wiki/SEPostgreSQL_Introduction
[2] https://wiki.postgresql.org/wiki/SEPostgreSQL_References
Door Anoniem:
Wat daar ontbreekt is de M van Management dat zorgt dat alle verantwoordelijkheden belegd zijn en in de gaten houdt ..... . Daar heb je trouwens nog een S van Security administrators voor nodig met grondige kennis van zaken, en die moeten onafhankelijk van applicatiebouwers en infrastructuurmensen zijn.
In management theorie is dit gangbaar: https://nl.wikipedia.org/wiki/Duivelsdriehoek. Je hebt gelijk er zijn vele varianten van te maken maar met SM als afkorting er bij zie ik ook wel waarde.Wat daar ontbreekt is de M van Management dat zorgt dat alle verantwoordelijkheden belegd zijn en in de gaten houdt ..... . Daar heb je trouwens nog een S van Security administrators voor nodig met grondige kennis van zaken, en die moeten onafhankelijk van applicatiebouwers en infrastructuurmensen zijn.
Ik heb inmiddels in de PostgreSQL-documentatie[1] gelezen dat SELinux een interface voor applicaties heeft, zodat die er ook van gebruik kunnen maken. Als het gebruikte DBMS het ondersteunt kunnen database-objecten dus inderdaad met SELinux beveiligd worden.
Code injection voor SQL zal selinux niet afvangen. De sql interpreter en executie zit in Postgres. Met code injection kan je ook nog een de webserver of andere component (xml parsers) denken. De hele beveiliging moet op dat niveau expliciet geregeld worden aan de server kant van de App. Je moet zien te vermijden dat een gevoelige database aan internet hangt. Dat betekent een extra parser en sessie manager die je er tussen zet. zo'n beetje als een DMZ inrichten. Kjjk naar je links en zie de plaats en het belang van IPC.
Dat van een securitycontext in een DBMS is vrij klassiek. Daar hoort de vraag bij wie wanneer waarom ( de autorisatiematrix). Stored procedures zijn een vorm van segmentatie als je SQL verbied en enkel SP's als api expliciet toestaat dan zal code injectie heel lastig worden.
Door karma4: Daar zit een spraakverwarring, het DBMS systeem postgres wordt door linux als "de applicatie" gezien. Voor de bouwers van de UX en de app is postgres echter infrastructuur.
Hier gaat het erom dat de bouwers van het DBMS snappen wat ze maken. Je zou postgres door selinux kunnen inkapselen zodat het minder makkelijk naar buiten kan. Dat houdt in: postgres wel onder root draaien maar toch nergens bij iets kunnen wat selinux verbiedt.
Dat slaat nergens op. Het betekent dat PostgreSQL zonder als root te draaien gebruik kan maken van de interface die SELinux voor applicaties aanbiedt. En er IS een versie die dat doet. Code injection voor SQL zal selinux niet afvangen.
Waarom plaatste je dan in godsnaam deze opmerking: Ik nog nooit SQL door selinux afgehandeld zien worden, toch is dat de topper in code injection.
Dat klinkt alsof WEL verwacht dat dat gedaan wordt. En nu begin je aan mij uit te leggen wat ik zelf al de hele tijd concludeerde. Ben je er wel helemaal bij met je hoofd? Je dwarrelt alle kanten op.Door Erik van Straten:
Reguleer de verkoop van munitie, dan is het probleem van vuurwapens grotendeels de wereld uit.
Door Toje Fos: [...] Stel jij woont in de UK, hebt een wapenvergunning en hebt een vuurwapen gekocht bij Guntraders.
Reguleer de verkoop van munitie, dan is het probleem van vuurwapens grotendeels de wereld uit.
Door Erik van Straten:
Welk deel van het woord INFORMATIEBEVEILIGING begrijp jij niet?
Door Toje Fos: [...] Mits de onderliggende systeemsoftware afdoende robuust en veilig is natuurlijk. Zoniet, dan volgt een uitbraak naar het niveau van de systeemsoftware, waardoor je volledige controle over het systeem krijgt, met alle consequenties van dien.
...Welk deel van het woord INFORMATIEBEVEILIGING begrijp jij niet?
Ik weet niet waar je het over hebt. Dat je met een Trabant meer problemen kan verwachten dan met een dure Mercedes is toch evident. En dat je met een Mercedes nog steeds niet zonder gevolgen tegen een muur kan rijden ook.
Door karma4:
Deze week was door een foutje (en bedankt) bij Akamai de halve wereld op internet niet meer beschikbaar.
Lastiger wordt het systeemsotware te definieren. Wifi? IO-driver USb? DBMS? Een gekopieerde functie librarie? R python? Wordpress plug in? Browser? Oj je beperkt het tot iets onwerkbaars of je krijgt het geheel.
Leef je uit met: https://public.cyber.mil/stigs/downloads/ en https://www.stigviewer.com/stig/application_security_and_development/
Door Toje Fos: Waar, echter dat gaat niet op voor systeemsoftware (zoals het besturingssysteem).
Voor de beschikbaarheid van een dienst maakt het weinig uit waar het in de keten mis gaat.Deze week was door een foutje (en bedankt) bij Akamai de halve wereld op internet niet meer beschikbaar.
Lastiger wordt het systeemsotware te definieren. Wifi? IO-driver USb? DBMS? Een gekopieerde functie librarie? R python? Wordpress plug in? Browser? Oj je beperkt het tot iets onwerkbaars of je krijgt het geheel.
Leef je uit met: https://public.cyber.mil/stigs/downloads/ en https://www.stigviewer.com/stig/application_security_and_development/
Geweldig (zo'n open deur intrappen) maar jouw uitspraak gaat nog steeds niet op voor systeemsoftware.
Door karma4:
Nog steeds (zie de links) verwijder services die niet nodig zijn etc. Let op met die aanbevelingen, wat daar genoemd wordt als een applicatie die aan sessiebeheer moet doen valt vanuit een ander standpunt onder systeemsoftware. Apache Tomcat en meer van dat soort technische tools zit in de keten van het informatieysteem maar ik zie het echt niet als iets voor UX applicatiebouwer. Daar gaat het zo vaak fout dat er niets aan gebeurt. De onderliggende sandbox gaat gewoon mee onderuit zeker in het geval met admins die alles met alle rechten doen.
Dat is ook waar, echter dat soort software draait - als het goed is - binnen de grenzen van een sandbox of met beperkte rechten en heeft geen mogelijkheden om daaruit te breken. Mits de onderliggende systeemsoftware afdoende robuust en veilig is natuurlijk. Zoniet, dan volgt een uitbraak naar het niveau van de systeemsoftware, waardoor je volledige controle over het systeem krijgt, met alle consequenties van dien.
Nog steeds (zie de links) verwijder services die niet nodig zijn etc. Let op met die aanbevelingen, wat daar genoemd wordt als een applicatie die aan sessiebeheer moet doen valt vanuit een ander standpunt onder systeemsoftware. Apache Tomcat en meer van dat soort technische tools zit in de keten van het informatieysteem maar ik zie het echt niet als iets voor UX applicatiebouwer. Daar gaat het zo vaak fout dat er niets aan gebeurt. De onderliggende sandbox gaat gewoon mee onderuit zeker in het geval met admins die alles met alle rechten doen.
Hier staat volgens mij niets zinvols.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
