Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/race-condition.md

18 KiB
Raw Blame History

Wedloop Toestand


Gebruik Trickest om maklik en outomatiseer werkstrome te bou wat aangedryf word deur die wêreld se mees gevorderde gemeenskapshulpmiddels.
Kry Toegang Vandag:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Leer AWS hakwerk van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

{% hint style="warning" %} Vir 'n dieper begrip van hierdie tegniek, kyk na die oorspronklike verslag by https://portswigger.net/research/smashing-the-state-machine {% endhint %}

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 vir Sinchronisering van Versoeke vind:

HTTP/2 Enkel-Pakket Aanval teenoor HTTP/1.1 Laaste-Byte Sinsronisering

  • HTTP/2: Ondersteun die stuur van twee versoeke oor 'n enkele TCP-koppeling, wat die impak van netwerkfluktuasie verminder. Tog, as gevolg van serverkant variasies, mag twee versoeke nie voldoende wees vir 'n konsekwente wedloop toestand uitbuiting nie.
  • HTTP/1.1 'Laaste-Byte Sync': Maak die vooraf stuur van die meeste dele van 20-30 versoeke moontlik, met die terughouding van 'n klein fragment, wat dan saam gestuur word, om gelyktydige aankoms by die bediener te bereik.

Voorbereiding vir Laaste-Byte Sync behels:

  1. Stuur koppe en liggaamdata minus die finale byte sonder om die stroom te beëindig.
  2. Pauzeer vir 100ms na die aanvanklike stuur.
  3. Deaktiveer TCP_NODELAY om Nagle se algoritme te gebruik vir die groepering van finale rame.
  4. Ping om die koppeling op te warm.

Die daaropvolgende stuur van terughou rame behoort in hul aankoms in 'n enkele pakket te resulteer, wat verifieer kan word via Wireshark. 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 versoeke anders roeteer, wat die tydsberekening beïnvloed. Voorsorgmaatreëls vir vooraf bedienerkant koppelingopwarming, deur onbeduidende versoeke, kan versoektydsberekening normaliseer.

Hantering van Sessie-Gebaseerde Sluiting

Raamwerke soos PHP se sessiehanterer serialize versoeke per sessie, wat moontlik kwesbaarhede kan verberg. Die gebruik van verskillende sessietokens vir elke versoek kan hierdie probleem omseil.

Oorkom van Tarief- of Hulpbronbeperkings

As koppelingopwarming nie effektief is nie, kan die opsetlike aktivering van webbedieners se tarief- of hulpbronbeperkingsvertragings deur 'n vloed van dummiversoeke die enkel-pakket aanval fasiliteer deur 'n bedienerside 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 in csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s en dan die examples/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:

passwords = wordlists.clipboard
for password in passwords:
engine.queue(target.req, password, gate='race1')

{% hint style="warning" %} As die web nie HTTP2 ondersteun nie (slegs HTTP1.1), gebruik Engine.THREADED of Engine.BURP in plaas van Engine.BURP2. {% endhint %}

  • Tubo Intruder - HTTP2 enkelpakket-aanval (Verskeie eindpunte): In geval jy 'n versoek na 1 eindpunt moet stuur en dan meerdere na ander eindpunte om die RCE te trigger, kan jy die race-single-packet-attack.py skrip verander met iets soos:
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2
)

# Hardcode the second request for the RC
confirmationReq = '''POST /confirm?token[]= HTTP/2
Host: 0a9c00370490e77e837419c4005900d0.web-security-academy.net
Cookie: phpsessionid=MpDEOYRvaNT1OAm0OtAsmLZ91iDfISLU
Content-Length: 0

'''

# For each attempt (20 in total) send 50 confirmation requests.
for attempt in range(20):
currentAttempt = str(attempt)
username = 'aUser' + currentAttempt

# queue a single registration request
engine.queue(target.req, username, gate=currentAttempt)

# queue 50 confirmation requests - note that this will probably sent in two separate packets
for i in range(50):
engine.queue(confirmationReq, gate=currentAttempt)

# send all the queued requests for this attempt
engine.openGate(currentAttempt)
  • Dit is ook beskikbaar in Herhaling via die nuwe 'Stuur groep in parallel' opsie in Burp Suite.
  • Vir limiet-oorskryding kan jy net 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 subtoestand-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.

Rou BF

Voor die vorige navorsing is hierdie payloads gebruik wat net probeer het om die pakkies so vinnig as moontlik te stuur om 'n RC te veroorsaak.

  • Herhaling: Kyk na die voorbeelde uit die vorige afdeling.
  • Indringer: Stuur die versoek na Indringer, stel die aantal drade in op 30 binne die Opsies-meny en, kies as payload Nul-payloads en genereer 30.
  • Turbo Indringer
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
pipeline=False
)
a = ['Session=<session_id_1>','Session=<session_id_2>','Session=<session_id_3>']
for i in range(len(a)):
engine.queue(target.req,a[i], gate='race1')
# open TCP connections and send partial requests
engine.start(timeout=10)
engine.openGate('race1')
engine.complete(timeout=60)

def handleResponse(req, interesting):
table.add(req)
  • Python - asyncio
import asyncio
import httpx

async def use_code(client):
resp = await client.post(f'http://victim.com', cookies={"session": "asdasdasd"}, data={"code": "123123123"})
return resp.text

async def main():
async with httpx.AsyncClient() as client:
tasks = []
for _ in range(20): #20 times
tasks.append(asyncio.ensure_future(use_code(client)))

# Get responses
results = await asyncio.gather(*tasks, return_exceptions=True)

# Print results
for r in results:
print(r)

# Async2sync sleep
await asyncio.sleep(0.5)
print(results)

asyncio.run(main())

RC Metodologie

Limiet-oorskryding / TOCTOU

Dit is die mees basiese tipe van 'n wedren-toestand 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 wedren-toestande behels dikwels die benutting van kort geleenthede om met versteekte of onbedoelde masjien subtoestande te interaksieer. Hier is hoe om hierdie benadering te volg:

  1. Identifiseer Potensiële Versteekte Subtoestande
  • Begin deur eindpunte te identifiseer wat kritieke data wysig of daarmee interaksieer, soos gebruikersprofiele of wagwoord-herstelprosesse. Fokus op:
  • Stoor: Gee voorkeur aan eindpunte wat bedienerkant persistente data manipuleer bo die 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 die wat nuwe data byvoeg.
  • Sleutel: Suksesvolle aanvalle behels gewoonlik operasies wat gesleutel is op dieselfde identifiseerder, bv., gebruikersnaam of herstelteken.
  1. Voer Aanvanklike Ondersoek uit
  • Toets die geïdentifiseerde eindpunte met wedren-toestandaanvalle en let op enige afwykings van verwagte uitkomste. Onverwagte reaksies of veranderinge in aansoekgedrag kan 'n kwesbaarheid aandui.
  1. 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:

  • Doen twee wagwoordhersteltekensversoeke op dieselfde tyd en vergelyk hulle. Overeenstemmende tekens dui op 'n fout in teken-generering.

Kyk na hierdie PortSwigger-lab om dit te probeer.

Gevallestudies van Versteekte Subtoestande

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 Koekegebaseer

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

Kyk na hierdie PortSwigger-lab om dit te probeer.

Versteekte Databasestatusse / Bevestigingsoorslaan

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

Omskep 2FA

Die volgende pseudokode is vatbaar vir 'n wedren-toestand omdat in 'n baie kort tydperk die 2FA nie afgedwing word terwyl die sessie geskep word:

session['userid'] = user.userid
if user.mfa_enabled:
session['enforce_mfa'] = True
# generate and send MFA code to user
# redirect browser to MFA code entry form

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 hê, wil jy dit toelaat?"

Race Voorwaarde in 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

Sodra jy 'n geldige RT verkry 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

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:


Gebruik Trickest om maklik werkstrome te bou en outomatiseer wat aangedryf word deur die wêreld se mees gevorderde gemeenskapsinstrumente.
Kry Vandag Toegang:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}