Een aanval op front-end-back-end-systemen waarmee we in kunnen spelen op verzoeken van derden

Onthuld details van een nieuwe aanval op sites die een front-end-back-end-model gebruiken, zoals sites die via netwerken voor inhoudslevering, load balancers of proxy's lopen. De aanval maakt het mogelijk om, door bepaalde verzoeken te verzenden, in te grijpen in de inhoud van andere verzoeken die in dezelfde thread tussen de frontend en de backend worden verwerkt. De voorgestelde methode werd met succes gebruikt om een ​​aanval te organiseren die het mogelijk maakte om de authenticatieparameters van gebruikers van de PayPal-service te onderscheppen, die onderzoekers ongeveer 40 dollar betaalde als onderdeel van een programma om te informeren over de aanwezigheid van niet-gepatchte kwetsbaarheden. De aanval is ook van toepassing op sites die gebruik maken van het Akamai-netwerk voor inhoudslevering.

De kern van het probleem is dat frontends en backends vaak verschillende niveaus van ondersteuning bieden voor het HTTP-protocol, maar tegelijkertijd verzoeken van verschillende gebruikers in een gemeenschappelijk kanaal inkapselen. Om de frontend-ontvangstverzoeken en de backend-verwerkingsverzoeken met elkaar te verbinden, wordt een langlevende TCP-verbinding tot stand gebracht, via welke gebruikersverzoeken worden verzonden, de een na de ander langs de keten verzonden, gescheiden door middel van het HTTP-protocol. Om verzoeken te scheiden, worden de headers "Content-Length" (bepaalt de totale grootte van de gegevens in het verzoek) en "Overdrachtscodering: chunked"(Hiermee kunt u gegevens in delen overbrengen, waarbij u blokken van verschillende groottes specificeert in het formaat "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Het probleem doet zich voor als de frontend alleen “Content-Length” ondersteunt, maar “Transfer-Encoding: chunked” negeert (Akamai CDN deed dit bijvoorbeeld) of omgekeerd. Als Transfer-Encoding: chunked aan beide kanten wordt ondersteund, kunnen de implementatiefuncties van HTTP-header-parsers worden gebruikt voor een aanval (bijvoorbeeld wanneer de front-end regels als 'Transfer-Encoding: xchunked', 'Transfer-Encoding: chunked' negeert ”, “Transfer-Encoding”:[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" of "Transfer-Encoding: chunked", en de backend verwerkt ze met succes).

In dit geval kan een aanvaller een verzoek verzenden dat zowel de headers "Content-Length" als "Transfer-Encoding: chunked" bevat, maar de grootte in "Content-Length" komt niet overeen met de grootte van de gesegmenteerde keten, die kleiner is dan de werkelijke waarde. Als de frontend het verzoek verwerkt en doorstuurt volgens "Content-Length" en de backend wacht tot het blok is voltooid op basis van "Transfer-Encoding: chunked", dan zal het einde van de gegevens op basis van "Transfer-Encoding: chunked" eerder worden bepaald en de resterende staart van het verzoek zal de aanvaller aan het begin van het volgende verzoek staan, d.w.z. de aanvaller kan willekeurige gegevens toevoegen aan het begin van het volgende verzoek van iemand anders.

Om het probleem in de gebruikte frontend-backend combinatie te achterhalen, kunt u via de frontend een verzoek als volgt sturen:

POST /over HTTP/1.1
Host: voorbeeld.com
Overdrachtscodering: chunked
Content-Length: 4

1
Z
Q

Het probleem doet zich voor als de backend het verzoek niet onmiddellijk verwerkt en wacht op de aankomst van het laatste nulgrensblok met gefragmenteerde gegevens. Voor een completere controle voorbereid een speciaal hulpprogramma dat ook mogelijke methoden test om de header “Transfer-Encoding: chunked” van de frontend te verbergen.

Het uitvoeren van een echte aanval hangt af van de mogelijkheden van de aangevallen site. Wanneer u bijvoorbeeld de Trello-webapplicatie aanvalt, kunt u het begin van het verzoek vervangen (vervang gegevens zoals "PUT /1/members/1234... x=x&csrf =1234&gebruikersnaam=testzzz&bio=cake”) en stuur een bericht met daarin het oorspronkelijke verzoek van een externe gebruiker en de daarin gespecificeerde authenticatiecookie. Bij een aanval op saas-app.com bleek het mogelijk om JavaScript-code in de response te vervangen door deze in één van de requestparameters te vervangen. Voor de aanval op redhat.com werd een interne handler gebruikt om door te verwijzen naar de website van de aanvaller (een verzoek in de vorm “POST /search?dest=../assets/idx?redir=//[e-mail beveiligd]/HTTP/1.1").

Door de methode voor netwerken voor het leveren van inhoud te gebruiken, werd het mogelijk om eenvoudig de gevraagde site te vervangen door de header “Host:” te vervangen. De aanval kan ook worden gebruikt om de inhoud van systemen voor het cachen van inhoud te vergiftigen en vertrouwelijke gegevens in de cache te extraheren. Het hoogtepunt van de methode was de organisatie van een aanval op PayPal, die het mogelijk maakte om wachtwoorden te onderscheppen die door gebruikers tijdens authenticatie waren verzonden (het iframe-verzoek werd aangepast om JavaScript uit te voeren in de context van de paypal.com/us/gifts-pagina, bijvoorbeeld waarop CSP (Content Security Policy) niet is toegepast).

Interessant genoeg was dat in 2005 wel het geval voorgesteld een in wezen vergelijkbare verzoek-spoofingtechniek waarmee u gegevens in caching-proxy's (Tomcat, squid, mod_proxy) kunt vervalsen of firewallblokkering kunt omzeilen door verschillende "GET"- of "POST"-verzoeken binnen één HTTP-sessie op te geven.

Bron: opennet.ru