Hoofdcategorieën
Device Settings

JavaScript vormt toenemend veiligheidsrisico

Door Harm Hilvers, zaterdag 29 juli 2006 13:58
Bron: SPI Dynamics, views: 21.443

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.

Poortscannen met JavaScript

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.

Volgende 16:24 Aanwijzingen voor toekomstige Google-diensten gevonden
Vorige 13:38 Opnieuw vliegt een Dell-laptop spontaan in brand
Advertentie

Reacties

«  1  2  3  »

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

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.

En wat is hier gevaarlijker aan dan aan pakweg netcraft?
Dat een firewall/NAT router gepasseerd kan worden.

Ik zie ook de grote dreiging niet zo. Dus dan weten ze dat je een webserver draait.... met de info die ook onder het gemiddelde open dirretje staat. En de oplossing lijkt me nou ook niet zo heel erg moeilijk.
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.
Dus plaatje weg, 'lek' weg.

Ik vind de term veiligheids risico ook een beetje overdreven of op z'n minst misplaatst..

Mij bekruipt eerder het gevoel van "works as designed". De mogelijkheid om afbeeldingen op te vragen lijkt me toch wel handige functionaliteit voor een webserver. Dat beheerders plaatjes e.d. van de fabrikant erop laten staan (IIS/Apache), lijkt me meer luiheid van de administrator en ik zie er ook geen echt probleem in.

Ik snap dan ook niet helemaal wat dit nu precies met javascript te maken heeft?

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 ;)

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.

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

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....!

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.

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 :P

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

Is dit de rede waarom het menu op tweakers.net het niet meer doet ? Error: Object Expected

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 :).

Helemaal goud kerel! Superrrrr!

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.

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.

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.

dit is toch compleet niet boeiend? voor wie is dit een gevaar? 't enige dat ze hier aantonen is dat dat wat al zo ontiegelijk lang kan (zolang als 't web oud is), gedaan kan worden in javascript in plaats van een binary... wat is in hemelsnaam 't verschil in gevaar?
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 16:24 Aanwijzingen voor toekomstige Google-diensten gevonden
Vorige 13:38 Opnieuw vliegt een Dell-laptop spontaan in brand
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011