JavaScript vormt toenemend veiligheidsrisico

SPI Dynamics heeft een manier gevonden waarmee het mogelijk is om via JavaScript na te gaan of achter een IP-adres een webserver hangt en welke software daarop gedraaid wordt. In theorie zou het ook mogelijk moeten zijn om via ditzelfde stukje JavaScript lekken in de webservers uit te buiten door bepaalde commando's naar de server te sturen. Er wordt hierbij slechts gebruikgemaakt van JavaScript, wat betekent dat de techniek werkt in een groot aantal browsers en op verschillende besturingssystemen. Bij het scannen van de IP-adressen wordt geen misbruik gemaakt van lekken of bugs in browsers of in hun JavaScript-implementatie. Het maakt ook niet uit of een firewall aanwezig is, aangezien de browser daar toch al wel doorheen mag komen. Vooralsnog is dan ook de enige oplossing hiertegen het volledig uitschakelen van JavaScript-support in de browser. Dat zal echter als gevolg hebben dat een groot aantal sites niet meer volledig zal werken.

De werking van het script is eigenlijk vrij eenvoudig. Er wordt met behulp van JavaScript een Image-object aangemaakt. Het bronattribuut van deze afbeelding verwijst naar een van de ingegeven IP-adressen. Vervolgens wordt dit plaatje opgevraagd. Als er een reactie komt, bestaat er een host op het IP-adres en wordt doorgegaan met de volgende stap: ontdekken of het om een webserver gaat. Dit wordt gedaan door de host te vragen nogmaals te reageren. De output van deze request wordt in een verborgen iframe geladen. Als er output komt, wordt de volgende stap gezet: controleren om welke webserver het gaat. Dit wordt gedaan door na te gaan of een bepaalde afbeelding, uniek voor iedere webserver, aanwezig is op de server. Nu bekend is om welke software het gaat, kan eventueel een aanval gestart worden door bijvoorbeeld dynamisch html-formulieren op te bouwen en te versturen. Ook kan de gevonden informatie verstuurd worden naar de server van een kwaadwillende hacker.

Een proof-of-concept van deze JavaScript-functionaliteit kan gevonden worden op de site van SPI Dynamics, tezamen met een pdf'je met achtergrondinformatie. Het is de bedoeling dat tijdens de Black Hat-conferentie, die de komende dagen in in Las Vegas plaatsvindt, meer informatie gegeven zal worden over de techniek. Volgens Fyodor Vaskovich, auteur van de populaire Nmap-tool is het al jaren mogelijk dit soort kwaadaardige scripts te schrijven met behulp van JavaScript. Door bughunters werd echter voornamelijk gezocht naar flaws in de browsersoftware zelf, omdat hiermee sneller resultaat verkregen kon worden. Het voordeel van JavaScript-aanvallen is dat het moeilijk is ze op te lossen zonder webapplicaties kapot te maken. Daardoor zal een gevonden probleem op de lange termijn dus meer resultaat kunnen hebben. Dit zou dan ook wel kunnen betekenen dat malwareschrijvers hun aandacht gaan richten op JavaScript en meer kwaadaardige applicaties gaan ontwikkelen.

Reacties (46)

Vooralsnog is dan ook de enige oplossing hiertegen het volledig uitschakelen van JavaScript-support in de browser. Dat zal echter als gevolg hebben dat een groot aantal sites niet meer volledig zal werken.

Voor de firefox gebruikers: NoScript.

Hiermee kan je inderdaad al het Javascript uitschakelen, maar per (sub)domein ook toestaan! Dus je favoriete (vertrouwde) sites doen het nog gewoon .

Opera kan dit ook. De algemene instelling kan aangepast worden via F12 > vinkje Enable JavaScript. De voorkeur per site gaat via rechtsklik > Edit Site Preferences > tabje Scripting > vinkje Enable JavaScript.

Helemaal goud kerel! Superrrrr!

imho omslachtige "aanval".
Gelijkaardige info kan je zonder moeite dmv standaard port-scans en een beetje inventiviteit bekomen.
Of een webserver draait weeet je meestal al door port 80 te scannen, is die berikbaar, kan je een http request doen. En die afbeelding, specifiek voor elke webserver (ik neem aan dat het dan om de config pagina's gaat oid?) kan je manueel ook wel opvragen...
Lijkt me niet dat deze methode vaak gebruikt gaat worden.

Daarnaast zou het eigenlijk geen verschil mogen maken dat je weet dat er een webserver draait: die zou toch dicht moeten zitten

Als je bedenkt dat als je deze pagina laat openen door iemand die achter een firewall zit kan je op een makkelijke manier informatie verkrijgen over alle driaaiende webservers binnen een organisatie en deze zonder verdere controle naar buiten de organisatie verschepen.

Een bijzonder inventieve manier van 'phising' lijkt me...

is ook vrij gemakkelijk te blokken. Mijn browser heeft geen toegang tot het internet/intranet

Ik haal alles binnen via een SSH-tunnel naar een proxy via putty (in feite is putty het enige programma op mn pc dat mag communiceren met de buitenwereld).
Als ik zonder proxy probeer te surfen, gaat mn firewall moeilijk doen.
Dus ik kan ook niet in FF webbased management op een computer op het LAN doen, behalve als ik daarvoor expliciet toestemming geef in de firewall. En die (wbmgmnt) draait dan ook niet op poort 80, geloof me

Als ik helemaal paranoia doe kan ik ook dat weer via een SSH-tunnel laten verlopen (ssh-server op die betreffende server uiteraard), zodat ik die bijvoorbeeld op 127.0.0.1:16489 moet connecten.

Het verschil is dat dit script ook kan controleren of er servers op je LAN zijn die aan te vallen zijn. Een poort scan op port 80 zal alleen de httpserver die voor de buitenwereld bedoeld is tonen en die zal meestal als eerste (en beste) beveiligd zijn. Bovendien bevat deze server meestal alleen informatie die toch al voor de buitenwereld bedoeld was, terwijl op interne webservers juist vaak bedrijfscritische en geheime informatie voor meedewerkers staat.

*edit*
dubbelpost, sorry

Daarnaast doen ze er in het geval van Apache beter aan om gewoon de /icons/ directory op te vragen en de foutmelding te parsen. Meestal bevat die wel een melding als Apache/1.3.34 Server at tweakers.net Port 80. Terwijl dit tooltje eigenlijk alleen kan melden of het om apache of IIS gaat.

Ja, ik zie ook het nut niet van een dergelijk javascript.

Als je kwaad wil ga je zoeken naar een leuke bug en/of exploit voor bijvoorbeeld Apache;
http://secunia.com/search/?search=apache

Vervolgens zoek je met Google naar betreffende servers;
http://www.google.com/sea...=en&lr=&safe=off&filter=0

En rest laat zich raden....!

En ook dat kun je gewoon uitzetten, of custom 404 gebruiken..

Dit nieuws doet me een beetje denken aan het bericht over het Windows clipboard en javascript: http://www.nu.nl/news/583...egevens_van_klembord.html

Ik vraag me af of dit nu zo'n vaart loopt.

Ik vind de titel inderdaad ook wel heel erg tendentieus. Het veiligheidsrisico zit totaal niet in Javascript, maar in de configuratie van de webserver. Zolang die goed beveiligd is, lijkt mij dat het probleem niet bestaat. Om 't dan ook nog eens in de titel op Javascript te schuiven (terwijl hetzelfde vast ook mogelijk is met PHP, ASP.net, JSP, of welke andere willekeurige taal dan ook), vind ik gewoonweg slecht.

Ik zeg niet dat JS geen veiligheidsproblemen kan veroorzaken, maar dat is hier dus niet 't geval.

Het gaat hier niet om serverside talen, maar om de enige crossplatform client-side taal die door alle (populaire) browsers ondersteund wordt: JavaScript.

Ook dat boeit niet.. Yeah nu kun je je hack zowel vanaf Windwos als Linux beginnen.

Het concept wat hier getoont worden kan met ongeveer elke taal waarmee je TCP/IP tot je beschikking hebt..

Waar het wel omdraait is webserver config

Dat boet wel degelijk.

Aan de reacties te zien hebben veel mensen blijkbaar de impact hiervan niet door. Het gaat niet om het exploiten van de webserver zelf, maar dat dit vanaf de client computer gebeurt. Dit javascript is een soort trojan horse dat je binnenhaalt doordat je een willekeurige pagina bekijkt. Er wordt gebruik gemaakt van standaard javascript functionaliteit. Het is dus niet zomaar door een virusscanner, proxy of firewall te filteren zonder dat legitieme applicaties gemolt worden.

Je kunt een fatass firewall neerzetten tussen je intranet en het internet. Hierdoor vermoed je dat je simpele intranet server veilig is. Dit script maakt het mogelijk om ook op die servers bergen exploits los te laten. Hoe? Kijk maar eens in een willekeurig apache of iis accesslog om te zien wat voor creative querystrings er worden losgelaten.

kinda weird.
heb drie systemen in het netwerk hangen hier
192.168.1.1 is een router
192.168.1.2 is het systeem wat ik gebruik (draait atm apache)
192.168.1.3 is de pc van mijn vrouw. PC staat uit!

scannen op die drie ip's:
192.168.1.1: true, unknown web server
192.168.1.2: false
192.168.1.3: false
192.168.1.3: true, unknown web server
(false: geen host; true: wel een host)

't ding scant 192.168.1.3 blijkbaar meerdere keren ofzo
hoogst eigenaardig dat 'ie die pc aan vindt staan - is toch echt uit, ik kan 'm niet pingen (kan wel als 'ie aan staat)
edit: ok, dit is een 'known issue' en betreft alleen het laatste ip-adres wat 'ie scant.

ook eigenaardig dat 'ie de pc waarvandaan ik dit tik uit vindt staan. Nu zit er wel een deftige firewall op, dat kan uitmaken (al claimt het artikel van niet) Zou er soms een exploit zitten in dit proof of concept?

Overigens klopt de claim dat een firewall sowieso bypassed wordt niet. Je kunt best verkeer van local-ip naar local-ip verbieden (en alleen verkeer over de loopback toestaan)

Je hebt duidelijk over de known issues heengelezen.

jij hebt duidelijk over mijn post heengelezen - direct na gepost te hebben heb ik namelijk een wijziging aangebracht

Ik vraag me af waarom JavaScript nu ineens een toenemend veiligheidsrisico is. Deze techniek is volgens mij al minstens 5 jaar mogelijk. Op zich dus een betrekkelijk oude techniek.

Toch denk ik wel dat er wel degelijk een oplossing mogelijk is, door namelijk alle zaken die via JavaScript aan te maken zijn alleen naar de eigen server (weaar de JS vandaan komt) rechten te geven.

Dit betekent dat aangemaakte plaatjes alleen nog maar naar 1 site kan connecten (eventueel naar alle subdomeinen van een site), maar in elk geval niet naar willekeurige IP adressen.

Ik denk dat het duss ook hoognodig tijd wordt voor een agresievere sandbox benadering a la Java...

>Toch denk ik wel dat er wel degelijk een oplossing mogelijk is, door namelijk alle zaken die via JavaScript aan te maken zijn alleen naar de eigen server (weaar de JS vandaan komt) rechten te geven.

Dat is al zo voor zaken die echt wat kunnen, ik noem maar wat, externe scripts of Ajax requests. Het enige waar je dus wat mee kan is pure read operaties zoals img.src of iframe.location.

Hun stap 1 is dus wel interessant, maar aangezien ze zelf stap 2 aangeven (nu weten ze of ze een server kunnen aanvallen), vind ik het een beetje vaag worden, want a) Voor stap 2 is dus geen "hole" in JavaScript, b) Als die er is heb je stap 1 niet nodig maar doe je heb gewoon.

Kortom, leuke ontdekking, alleen is het verhaal dat er omheen is geplakt een broodje aap.

Gaap... Wat een Proof-of-Concept.. Heb hier in mijn netwerk een Apache webserver hangen.. die speciaal voor dat doel is bedacht.. maar de tool werkt niet eens

Daarnaast.. Dit is een typisch voorbeeld van oorzaak en gevolg door elkaar halen.. De oorzaak van de lekken liggen niet in javascript.. (dit grapje kun je met elke willekeurige taal met TCP / IP ) maar de webserver.

Als javascript de websever kan uitbuiten, dan ligt de fout bij de Webserver en niet bij javascript.

EDIT : Ik heb de scan ook nog even laten lopen of mijn listening IP (van Apache) en NB: op de server zelf.. niks aan het handje.)
Javascript verstuurd gewoon http headers en dergelijk, als de webserver daardoor foutjes gaat vertonen, fix de webserver..

Inkomend verkeer dat is bij voorbaat 100% verdacht.. Fix het OS en de apps..Want wat javascript kan.. kan ik met de hand ook...

Een 'zinvolle hack' zou kunnen zijn om een hardware firewall met webinterface open te zetten zodat je daarna alsnog vrije toegang hebt.

Duidelijk komkommernieuws.
Er kan een slotje op (of werkt dat hier niet)

Als (amateur-)webdevver die zich graag aan de HTML-standaard/aanbevemingen houdt, ben ik wel genoodzaakt om mijn flashanimaties via JS op te roepen, aangezien het OBJECT en EMBED-tag niet mooi samen willen werken... De enige oplossing zou zijn dat hierover in de aanbevelingen iets verschijnt en door de browsers wordt aanvaard, maar tot op dat ogenblik moet je werken met behulp van bvb SWFObject

euhm.. flash zelf hoort ook niet bij die standaarden!
Dan krijg je weer pagina's waarvan je de tekst niet kan kopieren etc.
Dus als je je aan de standaarden wilt houden, gebruik je ook geen flash!

Daarbij sta je versteld van het aantal mensen dat geen Flashsupport in hun browser hebben!

Wat een onzin zeg. Je kan je prima aan de standaarden houden en toch Flash gebruiken. Gebruik dan wel alleen Flash waar dat nut heeft en bied alternatieven. En ga geen hele website in Flash bouwen.

En wat is hier gevaarlijker aan dan aan pakweg netcraft?

Hoezo, "overbodig"? Ik stel gewoon het veiligheidsrisico van het lek in vraag, en geef zelfs een mooi alternatief dat ook voorbij firewalls gaat, zelfs werkt zonder javascript!
Vul maar eens een site in onder "What's that site running?" bij netcraft.com

En wat is hier gevaarlijker aan dan aan pakweg netcraft?

Dat een firewall/NAT router gepasseerd kan worden.

Het voordeel van JavaScript-aanvallen is dat het moeilijk is ze op te lossen zonder webapplicaties kapot te maken. Daardoor zal een gevonden probleem op de lange termijn dus meer resultaat kunnen hebben. Dit zou dan ook wel kunnen betekenen dat malwareschrijvers hun aandacht gaan richten op JavaScript en meer kwaadaardige applicaties gaan ontwikkelen.