Java heeft ook kwetsbaarheden op de werkplek

De afgelopen weken is er veel aandacht geweest voor het vanaf internet misbruiken van kwetsbaarheden in de werkplek. Met name Adobe stond volop in de schijnwerpers: binnen een maand moesten ze in producten als Shockwave, Flash en Adobe Acrobat meerdere kwetsbaarheden verhelpen. Een pakket dat minder aandacht kreeg maar dit jaar ook al een paar keer ernstige noodpatches moest uitbrengen is de Java Virtual Machine. De hoogste tijd dus om te starten met updaten!

De Java Virtual Machine (JVM) is een software component dat op veel servers en werkplekken aanwezig is. De JVM software (waarbij die van leverancier Sun het meest wordt gebruikt) zorgt ervoor dat bepaalde programmacode platformonafhankelijk kan worden uitgevoerd. Een programmeur die een applicatie ontwikkelt en geen verschillende versies voor Linux, Windows, Unix en Mac wil ontwikkelen, kan ervoor kiezen om de software te ontwikkelen in Java. Elk OS waarvoor een JVM beschikbaar is, kan de software dan (in theorie) uitvoeren.

Doordat het voor beheerders vaak onduidelijk is welke Java versies goed met hun applicaties samenwerken, blijven werkplekken en servers vaak voorzien van de origineel met applicaties meegeleverde JVM's. Hier ontstaat op informatiebeveiligingsgebied vaak een spanningsveld. Voor een betrouwbare ict-dienstverlening is het immers belangrijk dat applicaties geen beveiligingsfouten bevatten. Aangezien alle software vroeg of laat met kwetsbaarheden te maken krijgt, is software die nooit van beveiligingsupdates wordt voorzien dus een bedreiging voor een betrouwbare bedrijfsvoering.

Client-side exploits

In de loop van 2008 heeft er in de hackerswereld een duidelijke verschuiving plaatsgevonden richting client-side exploits. Client-side exploits zijn programma's die beveiligingsfouten aan de kant van de gebruiker weten te misbruiken. Er is hier dus geen sprake van een hacker die verbinding maakt met een web of mailserver en daar op zoek gaat naar kwetsbaarheden. In plaats daarvan creëren hackers een kwaadaardige mail of website en halen ze gebruikers over om een mail te openen of een website te bezoeken. Een website bevat bijvoorbeeld een kwaadaardig Java component, dat actief wordt als een bezoeker verouderde (en kwetsbare) Java software op zijn of haar werkplek heeft staan. Via de kwetsbare Java software kan een hacker alles met de werkplek wat de gebruiker ook kan. Bevindt de werkplek zich in een bedrijfsnetwerk, dan kan de hacker dus zelfs met de rechten van de gebruiker het intranet of een financieel systeem benaderen.

Uit dit voorbeeld blijkt wel dat het updaten van software op de werkplek belangrijker wordt, naar mate dit soort aanvallen gebruikelijker wordt. Een toenemende dreiging betekent immers ook een toenemend risico. Het updaten van Java is echter door de vele versies en applicatieafhankelijkheden niet altijd eenvoudig. Het is dus hoog tijd voor een aantal tips om de introductie van een veilige Java versie eenvoudiger te maken.

Werken vanuit het risico

Het belangrijkste risico van een oude Java versie komt voort uit het feit dat Java is geïntegreerd in de webbrowser. Een werkplek kan best nog ergens een verouderde Java versie gebruiken, mits zeker is dat alleen business applicaties deze versie gebruiken en hij niet (bijvoorbeeld via de webbrowser) is aan te spreken door onvertrouwde content.

Tijdig testen

Als er voor applicaties een release planning is, is het verstandig om bij elke nieuwe release gelijk te verifiëren of er een nieuwe Java versie uit is. Indien deze beschikbaar is, kan het ontwikkelteam of de externe leverancier worden gevraagd om de compatibiliteit aan te geven. Ontbreekt deze nog, maar is een overgang op een nieuwe versie noodzakelijk, dan is het prettiger om dit issue tijdens een release te adresseren, dan op een losstaand moment. Het testen van de software kan dan gecombineerd worden, wat een resource- en dus kostenvoordeel met zich meebrengt.

Java-standaard bepalen

Alhoewel Java platformonanfhankelijk is, betekent dit niet dat de code altijd met alle JVM's werkt. Door zoveel mogelijk gebruik te maken van dezelfde JVM-hoofdversie (bijvoorbeeld Sun JRE 1.6.x_xx) hoeven er minder JVM-versies geïnstalleerd en onderhouden te worden.

Foutloze JVM’s koppelen

De webbrowser is een van de populairste programma's voor hackers om te misbruiken. Ze richten zich hierbij over het algemeen op de browser zelf of de invoegtoepassingen zoals Flash, Quicktime of Java. Er zijn speciale hacker toolkits die een website van tientallen exploits kunnen voorzien, waaronder Java-exploits. Dit kunnen speciale hack-websites zijn, maar ook de site van de winkel om de hoek, waaraan de hacker na een inbraak de exploits heeft toegevoegd. Een gebruiker die een besmette website bezoekt en een kwetsbare Java versie heeft, zal op zijn werkplek direct een trojan of virus geïnstalleerd krijgen.

Aanscherping van Sun

Omdat veel bedrijven nog oude Java software gebruiken, heeft Sun geprobeerd om de beveiliging van Java in combinatie met de webbrowser aan te scherpen. Browsers met een recente Java versie, zullen ook standaard deze recente versie gebruiken. Staat er dus een JRE 1.4.2_19 en een JRE 1.6.0_15 op de werkplek, dan start de browser versie 1.6.0_15. Omdat er echter applicaties zijn die via de browser werken maar alleen JRE 1.4.2_xx ondersteunen, heeft SUN een functie moeten maken die de browser ertoe dwingt een oudere Java versie te gebruiken. Deze functie (die met zogenoemde CLSID's werkt) is functioneel een uitkomst, maar voor hackers geldt natuurlijk hetzelfde. Als ze een grotere kans willen dat ze succesvol een kwetsbaarheid kunnen misbruiken (exploiten), dan forceren ze dit door het CLSID van de Java 1.4.2 of 1.5 familie op te geven dat hun kwaadaardige applet met de oude software wordt gestart.

In deze laatste randvoorwaarde zit ook direct een belangrijke beveiligingsmaatregel verborgen. Standaard blijven ook de oude geïnstalleerd JRE's gekoppeld aan de browser en kunnen ze met een CLSID worden aangeroepen. Gebruik je de oudere JRE's echter niet vanuit de browser, maar enkel op de werkplek zelf, dan kunnen de oude JRE's prima van Internet Explorer worden afgekoppeld. Op de Microsoft website is terug te vinden hoe dit in Internet Explorer geconfigureerd kan worden en ook het Java configuratie scherm biedt hiervoor mogelijkheden.

Maarten Hartsuijker is security consultant bij Classity