Race Condition
Gebruik Trickest om maklik werkstrome te bou en te outomatiseer wat aangedryf word deur die wêreld se mees gevorderde gemeenskapshulpmiddels. Kry Vandaag Toegang:
Vir 'n dieper begrip van hierdie tegniek, kyk na die oorspronklike verslag by https://portswigger.net/research/smashing-the-state-machine
Verbetering van Wedloop Toestand Aanvalle
Die grootste struikelblok om voordeel te trek uit wedloop toestande is om seker te maak dat meervoudige versoek op dieselfde tyd hanteer word, met baie min verskil in hul verwerkingstye—ideaal gesproke, minder as 1ms.
Hier kan jy 'n paar tegnieke vind vir Sinchronisering van Versoeke:
HTTP/2 Enkel-Pakket Aanval teenoor HTTP/1.1 Laaste-Byte Sinchronisering
HTTP/2: Ondersteun die stuur van twee versoeke oor 'n enkele TCP-koppeling, wat die impak van netwerkfluktuerings verminder. Tog, as gevolg van serverkant variasies, mag twee versoeke nie voldoende wees vir 'n konsekwente wedloop toestand aanval nie.
HTTP/1.1 'Laaste-Byte Sinchronisering': Maak dit moontlik om die vooraf stuur van die meeste dele van 20-30 versoeke, met die terughouding van 'n klein fragment, wat dan saam gestuur word, om gelyktydige aankoms by die bediener te bereik.
Voorbereiding vir Laaste-Byte Sinchronisering behels:
Stuur koppe en liggaamdata minus die finale byte sonder om die stroom te beëindig.
Pauzeer vir 100ms na die aanvanklike stuur.
Deaktiveer TCP_NODELAY om Nagle se algoritme te gebruik vir die groepering van finale rame.
Ping om die koppeling op te warm.
Die daaropvolgende stuur van terughou rame behoort in hul aankoms in 'n enkele pakket te resulteer, wat deur Wireshark geverifieer kan word. Hierdie metode is nie van toepassing op statiese lêers wat nie tipies betrokke is by RC aanvalle nie.
Aanpassing aan Bedienerargitektuur
Die begrip van die teiken se argitektuur is krities. Front-end bedieners mag versoek anders roeteer, wat die tydsberekening beïnvloed. Voorskot bedienerkant koppeling opwarming, deur onbeduidende versoeke, mag versoektydsberekening normaliseer.
Hantering van Sessie-Gebaseerde Sluiting
Raamwerke soos PHP se sessiehanterer serializeer versoeke per sessie, wat moontlik kwesbaarhede kan verberg. Die gebruik van verskillende sessietokens vir elke versoek kan hierdie probleem omseil.
Oorkom van Tempo- of Hulpbron Beperkings
As koppeling opwarming nie effektief is nie, kan die opsetlike aktivering van webbedieners se tempo- of hulpbronbeperkingsvertragings deur 'n vloed van dummieversoeke die enkel-pakket aanval fasiliteer deur 'n bedienerskant vertraging te veroorsaak wat bevorderlik is vir wedloop toestande.
Aanval Voorbeelde
Tubo Intruder - HTTP2 enkel-pakket aanval (1 eindpunt): Jy kan die versoek na Turbo intruder stuur (
Uitbreidings
->Turbo Intruder
->Stuur na Turbo Intruder
), jy kan in die versoek die waarde wat jy wil kragtig afdwing vir%s
soos incsrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s
en dan dieexamples/race-single-packer-attack.py
van die keuslys kies:
As jy van plan is om verskillende waardes te stuur, kan jy die kode wysig met hierdie een wat 'n woordelys van die knipbord gebruik:
As die web nie HTTP2 ondersteun nie (slegs HTTP1.1) gebruik Engine.THREADED
of Engine.BURP
in plaas van Engine.BURP2
.
Tubo Intruder - HTTP2 enkelpakket-aanval (Verskeie eindpunte): Indien jy 'n versoek na 1 eindpunt moet stuur en dan meerdere na ander eindpunte om die RCE te aktiveer, kan jy die
race-single-packet-attack.py
skrips verander met iets soos:
Dit is ook beskikbaar in Herhaling via die nuwe 'Stuur groep in parallel' opsie in Burp Suite.
Vir limiet-oorskryding kan jy net die dieselfde versoek 50 keer in die groep byvoeg.
Vir verbindingsopwarming kan jy aan die begin van die groep 'n paar versoeke byvoeg na 'n nie-statische deel van die webbediener.
Vir die vertraging van die proses tussen die verwerking van een versoek en 'n ander in 2 substaat-stappe, kan jy ekstra versoeke tussen beide versoeke byvoeg.
Vir 'n multi-eindpunt RC kan jy begin om die versoek wat na die verborge toestand gaan te stuur en dan 50 versoeke net daarna wat die verborge toestand benut.
Geoutomatiseerde Python-skrip: Die doel van hierdie skrip is om die e-pos van 'n gebruiker te verander terwyl dit voortdurend geverifieer word totdat die verifikasietoken van die nuwe e-pos na die laaste e-pos arriveer (dit is omdat in die kode 'n RC gesien is waar dit moontlik was om 'n e-pos te wysig maar die verifikasie na die ou een gestuur is omdat die veranderlike wat die e-pos aandui reeds met die eerste een gevul was). Wanneer die woord "objetivo" in die ontvangs e-posse gevind word, weet ons dat ons die verifikasietoken van die veranderde e-pos ontvang het en beëindig ons die aanval.
Roue BF
Voor die vorige navorsing was hierdie enkele lading wat gebruik is, wat net probeer het om die pakkies so vinnig as moontlik te stuur om 'n RC te veroorsaak.
Herhaler: Kyk na die voorbeelde uit die vorige afdeling.
Indringer: Stuur die versoek na Indringer, stel die aantal drade in op 30 binne die Opsies-menu, kies as lading Nul ladinge en genereer 30.
Turbo Indringer
Python - asyncio
RC Metodologie
Limiet-oorskryding / TOCTOU
Dit is die mees basiese tipe van 'n wedloopvoorwaarde waar kwesbaarhede voorkom op plekke wat die aantal kere wat jy 'n aksie kan uitvoer, beperk. Soos om dieselfde afslagkode verskeie kere in 'n aanlynwinkel te gebruik. 'n Baie maklike voorbeeld kan gevind word in hierdie verslag of in hierdie fout.
Daar is baie variasies van hierdie soort aanval, insluitend:
Die inwisseling van 'n geskenkkaart verskeie kere
Die beoordeling van 'n produk verskeie kere
Die onttrekking of oordrag van kontant bo jou rekeningsaldo
Die hergebruik van 'n enkele CAPTCHA-oplossing
Die omseil van 'n anti-brute-krag limiet
Versteekte subtoestande
Die uitbuiting van komplekse wedloopvoorwaardes behels dikwels die benutting van kort geleenthede om met versteekte of onbedoelde masjien subtoestande te interaksieer. Hier is hoe om hierdie benadering te volg:
Identifiseer Potensiële Versteekte Subtoestande
Begin deur eindpunte te identifiseer wat kritieke data wysig of daarmee interaksieer, soos gebruikersprofiele of wagwoordherstelprosesse. Fokus op:
Stoor: Gee voorkeur aan eindpunte wat bedienerkant volgehoue data manipuleer bo diegene wat data aan die kliëntkant hanteer.
Aksie: Soek na operasies wat bestaande data verander, wat meer geneig is om uitbuitbare toestande te skep in vergelyking met diegene wat nuwe data byvoeg.
Sleuteling: Suksesvolle aanvalle behels gewoonlik operasies wat gesleutel is op dieselfde identifiseerder, bv. gebruikersnaam of herstelteken.
Voer Aanvanklike Ondersoek uit
Toets die geïdentifiseerde eindpunte met wedloopvoorwaarde aanvalle en let op vir enige afwykings van verwagte uitkomste. Onverwagte reaksies of veranderinge in aansoekgedrag kan 'n kwesbaarheid aandui.
Wys die Kwesbaarheid
Beperk die aanval tot die minimale aantal versoek wat nodig is om die kwesbaarheid uit te buit, dikwels net twee. Hierdie stap mag verskeie pogings of outomatisering vereis as gevolg van die presiese tydsberekening wat betrokke is.
Tydsensitiewe Aanvalle
Presisie in die tydsberekening van versoek kan kwesbaarhede aan die lig bring, veral wanneer voorspelbare metodes soos tydstempels gebruik word vir sekuriteitstokens. Byvoorbeeld, die generering van wagwoordhersteltekens gebaseer op tydstempels kan identiese tekens vir gelyktydige versoek toelaat.
Om Uit te Buit:
Gebruik presiese tydsberekening, soos 'n enkele pakketaanval, om gelyktydige wagwoordherstelversoeke te maak. Identiese tekens dui op 'n kwesbaarheid.
Voorbeeld:
Vra twee wagwoordhersteltekens op dieselfde tyd aan en vergelyk hulle. Overeenstemmende tekens dui op 'n fout in teken generering.
Kyk na hierdie PortSwigger-lab om dit te probeer.
Versteekte subtoestande gevallestudies
Betaal & voeg 'n Item by
Kyk na hierdie PortSwigger-lab om te sien hoe om te betaal in 'n winkel en 'n ekstra item by te voeg wat jy nie vir hoef te betaal nie.
Bevestig ander e-posse
Die idee is om 'n e-posadres te verifieer en dit terselfdertyd na 'n ander een te verander om uit te vind of die platform die nuwe een verifieer.
Verander e-pos na 2 e-posadresse op koekie-gebaseerde wyse
Volgens hierdie navorsing was Gitlab vatbaar vir 'n oorneem op hierdie manier omdat dit moontlik die e-posverifikasietoken van een e-pos na die ander e-pos kan stuur.
Kyk na hierdie PortSwigger-lab om dit te probeer.
Versteekte Databasis toestande / Bevestiging omseil
As 2 verskillende skrywes gebruik word om inligting binne 'n databasis by te voeg, is daar 'n klein tydperk waarin slegs die eerste data in die databasis geskryf is. Byvoorbeeld, wanneer 'n gebruiker geskep word, kan die gebruikersnaam en wagwoord geskryf word en dan die teken om die nuutgeskepte rekening te bevestig. Dit beteken dat vir 'n kort tydperk die teken om 'n rekening te bevestig nul is.
Daarom kan die registreer van 'n rekening en die stuur van verskeie versoek met 'n leë teken (teken=
of teken[]=
of enige ander variasie) om die rekening onmiddellik te bevestig, dit moontlik maak om 'n rekening te bevestig waar jy nie die e-pos beheer nie.
Kyk na hierdie PortSwigger-lab om dit te probeer.
Omseil 2FA
Die volgende pseudokode is vatbaar vir 'n wedloopvoorwaarde omdat in 'n baie kort tydperk die 2FA nie afgedwing word terwyl die sessie geskep word:
OAuth2 ewige volharding
Daar is verskeie OAuth-verskaffers. Hierdie dienste sal jou toelaat om 'n aansoek te skep en gebruikers te verifieer wat deur die verskaffer geregistreer is. Om dit te doen, sal die kliënt jou aansoek moet **toelaat om toegang te verkry tot sommige van hul data binne die OAuth-verskaffer. Dus, tot dusver net 'n gewone aanmelding met google/linkedin/github... waar jy geprompt word met 'n bladsy wat sê: "Aansoek <InsertCoolName> wil toegang tot jou inligting verkry, wil jy dit toelaat?"
Race Voorwaarde in authorization_code
authorization_code
Die probleem ontstaan wanneer jy dit aanvaar en outomaties 'n authorization_code
na die skadelike aansoek stuur. Dan misbruik hierdie aansoek 'n Race Voorwaarde in die OAuth-diensverskaffer om meer as een AT/RT (Authentication Token/Refresh Token) van die authorization_code
vir jou rekening te genereer. Basies, dit sal misbruik maak van die feit dat jy die aansoek toegelaat het om toegang tot jou data te verkry om verskeie rekeninge te skep. Dan, as jy ophou om die aansoek toe te laat om toegang tot jou data te verkry, sal een paar AT/RT verwyder word, maar die ander een sal steeds geldig wees.
Race Voorwaarde in Refresh Token
Refresh Token
Sodra jy 'n geldige RT het, kan jy probeer om dit te misbruik om verskeie AT/RT te genereer en selfs as die gebruiker die toestemmings kanselleer vir die skadelike aansoek om toegang tot sy data te verkry, sal verskeie RTs steeds geldig wees.
RC in WebSockets
In WS_RaceCondition_PoC kan jy 'n PoC in Java vind om websocket-boodskappe in parallel te stuur om ook Race Voorwaardes in WebSockets te misbruik.
Verwysings
Gebruik Trickest om maklik werkstrome te bou en te outomatiseer wat aangedryf word deur die wêreld se mees gevorderde gemeenskapsinstrumente. Kry Vandag Toegang:
Last updated