Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Reacties (9)
thx, gelijk effe mijn JDK geupdated. was nog bij 8 u 77. Gelijk auto update controle op dagelijks gezet. :o
24-03-2016, 18:09 door
Erik van Straten
Hmm, uit https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2016-0275+1.00+Kwetsbaarheid+in+Oracle+Java+SE+verholpen.html:
Ik hoop dat NCSC haar beoordeling heroverweegt (en nee, ik heb ze niet getipt, met mijn mail over een fout in de versie 1.0 van de PDF in https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html is nog niets gedaan - daardoor neemt mijn motivatie af).
[...]
Beschrijving
- CVE-2016-0636
Er bevindt zich een kwetsbaarheid in Java SE die het voor een kwaadwillende mogelijk maakt om code uit te voeren onder de rechten van het Java-proces. Een gebruiker moet verleid worden om een malafide Java-applet of Java-webstart-applicatie te starten en het Java-proces moet het uitvoeren van onvertrouwde code toestaan, wat niet de standaard instelling is.
[...]
Ik vermoed dat NCSC http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0636-2949497.html verkeerd heeft geïnterpreteerd: Beschrijving
- CVE-2016-0636
Er bevindt zich een kwetsbaarheid in Java SE die het voor een kwaadwillende mogelijk maakt om code uit te voeren onder de rechten van het Java-proces. Een gebruiker moet verleid worden om een malafide Java-applet of Java-webstart-applicatie te starten en het Java-proces moet het uitvoeren van onvertrouwde code toestaan, wat niet de standaard instelling is.
[...]
[...]
Notes:
This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.
[...]
Ik zie hier, en ook elders in de laatste pagina, nergens dat de default instelling zou zijn om geen untrusted code van internet te laden. Sterker, uit ervaring weet ik dat dit juist wel de standaard instelling is, en dat de Java plug-in's by default in web browsers worden geregistreerd tijdens installatie.Notes:
This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.
[...]
Ik hoop dat NCSC haar beoordeling heroverweegt (en nee, ik heb ze niet getipt, met mijn mail over een fout in de versie 1.0 van de PDF in https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html is nog niets gedaan - daardoor neemt mijn motivatie af).
Ik probeer hem te updaten maar hij zegt dat het programma er niet op staat. Ik geloof dat ik hem 2 jaar geleden al eraf
gemikt heb.
gemikt heb.
24-03-2016, 21:08 door
[Account Verwijderd]
[Verwijderd]
25-03-2016, 07:58 door
Erik van Straten
34-03-2016, 21:08 door Muria: Volgens mij verwart gij untrusted Java applet code met plug-in code (?)
Het gaat nl. over untrusted Java applet code en de default instelling hiervoor dat untrusted (unsigned) applets (die typisch van internet komen) niet zomaar worden uitgevoerd.
Ik snap jouw redenering, maar vrees dat ik gelijk heb - niet alleen vanwege de, door Oracle toegekende, CVSS Base score van 9.3, maar ook door het volgende.Het gaat nl. over untrusted Java applet code en de default instelling hiervoor dat untrusted (unsigned) applets (die typisch van internet komen) niet zomaar worden uitgevoerd.
De (terechte) verwarring ontstaat doordat softwareleveranciers en vooral certificaatboeren je willen doen geloven dat een digitale handtekening automatisch betekent dat het ondertekende object betrouwbaar (trusted) is.
Op z'n minst hoort hierbij: dat hangt ervan af...
De vragen die je je bij een digitaal ondertekend object tenminste moet stellen, zijn:
1) Wie heeft ondertekend?
2) Wanneer is ondertekend, en hoe zeker weet ik dat?
3) Vertrouwde IK die partij - op het moment van ondertekenen?
4) Hoe groot is de kans dat een derde deze (geldige) handtekening heeft kunnen zetten (bijv. door het ongeautoriseerde bezit van een kopie van de private key, of door ongeautoriseerd misbruik te kunnen maken van het signeerproces van de door jou wel vertrouwde partij)?
5) Kan het om een vervalste handtekening gaan, bijv. eentje waarbij gebruik gemaakt is door zwakke/gekraakte encryptie die nog door het verificatieproces wordt geaccepteerd, of die misbruik maakt van bugs in dat verificatieproces?
Terzijde: een mooi voorbeeld van 1), welliswaar geen Java applet of war file, zie je in https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29. Daarin heeft een Roemeense mailserver, niet van Google/GMail, de body en enkele headers van een mail, schijnbaar afkomstig van een afzender @gmail.com, digitaal ondertekend. Maakt dat deze mail betrouwbaar?
Terug naar de Java patch: in de tweede quote in mijn vorige bijdrage schrijft Oracle:
untrusted code (e.g., code that comes from the internet)
Daaruit maak ik op dat je, in dit geval, het woord "untrusted" moet lezen zoals het in woordenboeken omschreven wordt (dus ongeacht of er sprake is van een digitale handtekening).Nb. juist omdat de default instelling van Java webbrowser plug-ins is dat uitsluitend digitaal gesigneerde applets worden geaccepteerd, zal elke -enigzins intelligente- cybercrimineel of ethical hacker, uitluitend digitaal ondertekende exploit-applets naar jouw webbrowser sturen.
Wanneer snappen softwareleveranciers nou eens dat het zetten van (digitale) handtekeningen niet voorbehouden is aan betrouwbare mensen? Dat zou ongetwijfeld helpen om vergissingen als van NCSC te voorkomen.
Door Erik van Straten:
De (terechte) verwarring ontstaat doordat softwareleveranciers en vooral certificaatboeren je willen doen geloven dat een digitale handtekening automatisch betekent dat het ondertekende object betrouwbaar (trusted) is.
Op z'n minst hoort hierbij: dat hangt ervan af...
De vragen die je je bij een digitaal ondertekend object tenminste moet stellen, zijn:
1) Wie heeft ondertekend?
2) Wanneer is ondertekend, en hoe zeker weet ik dat?
3) Vertrouwde IK die partij - op het moment van ondertekenen?
4) Hoe groot is de kans dat een derde deze (geldige) handtekening heeft kunnen zetten (bijv. door het ongeautoriseerde bezit van een kopie van de private key, of door ongeautoriseerd misbruik te kunnen maken van het signeerproces van de door jou wel vertrouwde partij)?
5) Kan het om een vervalste handtekening gaan, bijv. eentje waarbij gebruik gemaakt is door zwakke/gekraakte encryptie die nog door het verificatieproces wordt geaccepteerd, of die misbruik maakt van bugs in dat verificatieproces?
Terug naar de Java patch: in de tweede quote in mijn vorige bijdrage schrijft Oracle:
Nb. juist omdat de default instelling van Java webbrowser plug-ins is dat uitsluitend digitaal gesigneerde applets worden geaccepteerd, zal elke -enigzins intelligente- cybercrimineel of ethical hacker, uitluitend digitaal ondertekende exploit-applets naar jouw webbrowser sturen.
Wanneer snappen softwareleveranciers nou eens dat het zetten van (digitale) handtekeningen niet voorbehouden is aan betrouwbare mensen? Dat zou ongetwijfeld helpen om vergissingen als van NCSC te voorkomen.
34-03-2016, 21:08 door Muria: Volgens mij verwart gij untrusted Java applet code met plug-in code (?)
Het gaat nl. over untrusted Java applet code en de default instelling hiervoor dat untrusted (unsigned) applets (die typisch van internet komen) niet zomaar worden uitgevoerd.
Ik snap jouw redenering, maar vrees dat ik gelijk heb - niet alleen vanwege de, door Oracle toegekende, CVSS Base score van 9.3, maar ook door het volgende.Het gaat nl. over untrusted Java applet code en de default instelling hiervoor dat untrusted (unsigned) applets (die typisch van internet komen) niet zomaar worden uitgevoerd.
De (terechte) verwarring ontstaat doordat softwareleveranciers en vooral certificaatboeren je willen doen geloven dat een digitale handtekening automatisch betekent dat het ondertekende object betrouwbaar (trusted) is.
Op z'n minst hoort hierbij: dat hangt ervan af...
De vragen die je je bij een digitaal ondertekend object tenminste moet stellen, zijn:
1) Wie heeft ondertekend?
2) Wanneer is ondertekend, en hoe zeker weet ik dat?
3) Vertrouwde IK die partij - op het moment van ondertekenen?
4) Hoe groot is de kans dat een derde deze (geldige) handtekening heeft kunnen zetten (bijv. door het ongeautoriseerde bezit van een kopie van de private key, of door ongeautoriseerd misbruik te kunnen maken van het signeerproces van de door jou wel vertrouwde partij)?
5) Kan het om een vervalste handtekening gaan, bijv. eentje waarbij gebruik gemaakt is door zwakke/gekraakte encryptie die nog door het verificatieproces wordt geaccepteerd, of die misbruik maakt van bugs in dat verificatieproces?
Terzijde: een mooi voorbeeld van 1), welliswaar geen Java applet of war file, zie je in https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29. Daarin heeft een Roemeense mailserver, niet van Google/GMail, de body en enkele headers van een mail, schijnbaar afkomstig van een afzender @gmail.com, digitaal ondertekend. Maakt dat deze mail betrouwbaar?
Terug naar de Java patch: in de tweede quote in mijn vorige bijdrage schrijft Oracle:
untrusted code (e.g., code that comes from the internet)
Daaruit maak ik op dat je, in dit geval, het woord "untrusted" moet lezen zoals het in woordenboeken omschreven wordt (dus ongeacht of er sprake is van een digitale handtekening).Nb. juist omdat de default instelling van Java webbrowser plug-ins is dat uitsluitend digitaal gesigneerde applets worden geaccepteerd, zal elke -enigzins intelligente- cybercrimineel of ethical hacker, uitluitend digitaal ondertekende exploit-applets naar jouw webbrowser sturen.
Wanneer snappen softwareleveranciers nou eens dat het zetten van (digitale) handtekeningen niet voorbehouden is aan betrouwbare mensen? Dat zou ongetwijfeld helpen om vergissingen als van NCSC te voorkomen.
Mooie en goede uiteenzetting van het geheel. Ik denk ook dat untrusted gelezen moet worden zoals het woordenboek inderdaad en niet untrusted als in niet digitaal ondertekend.
06-04-2016, 10:19 door
[Account Verwijderd]
[Verwijderd]
06-04-2016, 11:33 door
Erik van Straten
Ha Muria, ik reageer even alleen op jouw tweede punt, het eerste komen we niet uit vrees is.
1) De aanvallers vragen een erkend code signing certificaat aan. Daarbij kunnen zij de "identiteit van de entiteit" (CN oftewel Common Name) als volgt kiezen (tussen bakhaken verwijs ik naar concrete voorbeelden, links onderaan deze bijdrage):
1A) Een willekeurige, nog niet bestaande, bedrijfsnaam. Niets belet hen dit te doen, zie punt 1 in mijn vorige bijdrage;
1B) Een naam die lijkt op die van een bestaand bedrijf;
1C) Een exacte kopie van de naam van een bestaand bedrijf (onterecht uitgegeven certificaat) [1];
1D) Schijnbaar complete onzin, om de gebruiker te verleiden het betreffende bestand te vertrouwen op basis van de informatie in het certificaat [2].
2) De aanvallers stelen een een kopie van een private key gebruikt voor code-signing. Daarmee kunnen ze code signeren namens de entiteit (lees: het bedrijf). Desgewenst zoek ik URL's voor je, dit komt regelmatig voor.
3) De aanvallers verkrijgen toegang tot een "build straat" (onderdeel van de ontwikkelomgeving waar uiteindelijk code signing plaatsvindt, waarbij de private key veilig kan zijn opgeslagen in een HSM = Hardware Security Module) [3].
4) De aanvallers genereren een feitelijk ongeldig certificaat, dat door bugs (of export code leed) onterecht als geldig wordt geaccepteerd [4].
[1] https://www.security.nl/posting/444059/Symantec+geeft+onterecht+Google+SSL-certificaat+uit)
[2] http://www.benedelman.org/news/020305-1.html; hierin beschrijft Ben Edelman hoe Verisign een code-signing certificaat heeft uitgegegen voor een entiteit (bedrijf) genaamd CLICK YES TO CONTINUE
[3] https://www.security.nl/posting/38210/Hackers+signeren+malware+met+Adobe+certificaat (zie ook: https://www.security.nl/posting/38235/gevolgen+revoken+Adobe+certificaat).
[4] https://www.security.nl/posting/27076/Adobe+zero-day+gebruikt+valse+Microsoft+certificaten
06-04-2016, 10:19 door Muria:
Je kan - als cybercrimineel - weliswaar zelf ondertekenen maar dan staat er - meen ik - Publisher: Unknown bij, in de melding naar de gebruiker.
Dat is onjuist. Er is digitaal gesigneerde malware in omloop. Daarbij worden in elk geval de volgende 4 scenario's gebruikt:Door Erik van Straten: Nb. juist omdat de default instelling van Java webbrowser plug-ins is dat uitsluitend digitaal gesigneerde applets worden geaccepteerd, zal elke -enigzins intelligente- cybercrimineel of ethical hacker, uitluitend digitaal ondertekende exploit-applets naar jouw webbrowser sturen.
Wanneer snappen softwareleveranciers nou eens dat het zetten van (digitale) handtekeningen niet voorbehouden is aan betrouwbare mensen? Dat zou ongetwijfeld helpen om vergissingen als van NCSC te voorkomen.
Wanneer snappen softwareleveranciers nou eens dat het zetten van (digitale) handtekeningen niet voorbehouden is aan betrouwbare mensen? Dat zou ongetwijfeld helpen om vergissingen als van NCSC te voorkomen.
Je kan - als cybercrimineel - weliswaar zelf ondertekenen maar dan staat er - meen ik - Publisher: Unknown bij, in de melding naar de gebruiker.
1) De aanvallers vragen een erkend code signing certificaat aan. Daarbij kunnen zij de "identiteit van de entiteit" (CN oftewel Common Name) als volgt kiezen (tussen bakhaken verwijs ik naar concrete voorbeelden, links onderaan deze bijdrage):
1A) Een willekeurige, nog niet bestaande, bedrijfsnaam. Niets belet hen dit te doen, zie punt 1 in mijn vorige bijdrage;
1B) Een naam die lijkt op die van een bestaand bedrijf;
1C) Een exacte kopie van de naam van een bestaand bedrijf (onterecht uitgegeven certificaat) [1];
1D) Schijnbaar complete onzin, om de gebruiker te verleiden het betreffende bestand te vertrouwen op basis van de informatie in het certificaat [2].
2) De aanvallers stelen een een kopie van een private key gebruikt voor code-signing. Daarmee kunnen ze code signeren namens de entiteit (lees: het bedrijf). Desgewenst zoek ik URL's voor je, dit komt regelmatig voor.
3) De aanvallers verkrijgen toegang tot een "build straat" (onderdeel van de ontwikkelomgeving waar uiteindelijk code signing plaatsvindt, waarbij de private key veilig kan zijn opgeslagen in een HSM = Hardware Security Module) [3].
4) De aanvallers genereren een feitelijk ongeldig certificaat, dat door bugs (of export code leed) onterecht als geldig wordt geaccepteerd [4].
[1] https://www.security.nl/posting/444059/Symantec+geeft+onterecht+Google+SSL-certificaat+uit)
[2] http://www.benedelman.org/news/020305-1.html; hierin beschrijft Ben Edelman hoe Verisign een code-signing certificaat heeft uitgegegen voor een entiteit (bedrijf) genaamd CLICK YES TO CONTINUE
[3] https://www.security.nl/posting/38210/Hackers+signeren+malware+met+Adobe+certificaat (zie ook: https://www.security.nl/posting/38235/gevolgen+revoken+Adobe+certificaat).
[4] https://www.security.nl/posting/27076/Adobe+zero-day+gebruikt+valse+Microsoft+certificaten
06-04-2016, 14:34 door
[Account Verwijderd]
[Verwijderd]
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
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.
