ORM Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
U ovom postu objašnjeno je kako je moguće učiniti Django ORM ranjivim koristeći, na primer, kod kao što je:
Obratite pažnju kako se svi request.data (koji će biti json) direktno prosleđuju da filtriraju objekte iz baze podataka. Napadač bi mogao poslati neočekivane filtre kako bi iscurilo više podataka nego što se očekuje.
Primeri:
Login: U jednostavnom prijavljivanju pokušajte da iscurite lozinke korisnika registrovanih unutar njega.
Moguće je izvršiti brute-force napad na lozinku dok ne dođe do curenja.
Relacijsko filtriranje: Moguće je preći kroz relacije kako bi se došlo do informacija iz kolona za koje se nije ni očekivalo da će biti korišćene u operaciji. Na primer, ako je moguće doći do članaka koje je kreirao korisnik sa ovim relacijama: Article(created_by
) -[1..1]-> Author (user
) -[1..1]-> User(password
).
Moguće je pronaći lozinku svih korisnika koji su kreirali članak
Filtriranje više prema više: U prethodnom primeru nismo mogli pronaći lozinke korisnika koji nisu kreirali članak. Međutim, prateći druge odnose, to je moguće. Na primer: Article(created_by
) -[1..1]-> Author(departments
) -[0..*]-> Department(employees
) -[0..*]-> Author(user
) -[1..1]-> User(password
).
U ovom slučaju možemo pronaći sve korisnike u odeljenjima korisnika koji su kreirali članke i zatim otkriti njihove lozinke (u prethodnom json-u samo otkrivamo korisnička imena, ali je moguće otkriti i lozinke).
Zloupotreba Django Group i Permission mnogu-na-mnogu odnosa sa korisnicima: Štaviše, AbstractUser model se koristi za generisanje korisnika u Django-u i po defaultu ovaj model ima neke mnogu-na-mnogu odnose sa Permission i Group tabelama. Što je u suštini podrazumevani način da se pristupi drugim korisnicima iz jednog korisnika ako su u istoј grupi ili dele istu dozvolu.
Obiđi filter restrikcije: Isti blog post je predložio da se obiđu neka filtriranja kao što je articles = Article.objects.filter(is_secret=False, **request.data)
. Moguće je izvući članke koji imaju is_secret=True jer možemo da se vratimo iz veze u tabelu Article i da procurimo tajne članke iz ne-tajnih članaka jer su rezultati spojeni i is_secret polje se proverava u ne-tajnom članku dok se podaci procuruju iz tajnog članka.
Zloupotreba odnosa može omogućiti zaobilaženje čak i filtera koji su namenjeni zaštiti prikazanih podataka.
Greška/Na osnovu vremena putem ReDoS: U prethodnim primerima se očekivalo da će biti različitih odgovora ako filtriranje funkcioniše ili ne, kako bi se to koristilo kao orakl. Ali može biti moguće da se neka akcija izvrši u bazi podataka i da je odgovor uvek isti. U ovom scenariju može biti moguće izazvati grešku u bazi podataka kako bi se dobio novi orakl.
From te same post regarding this vector:
SQLite: Nema regexp operator po defaultu (zahteva učitavanje treće strane ekstenzije)
PostgreSQL: Nema podrazumevani regex timeout i manje je podložan backtrackingu
MariaDB: Nema regex timeout
The following are tricks extracted from this post.
Full find control:
It's possible to see that the whole javascript body is passed to prisma to perform queries.
In the example from the original post, this would check all the posts createdBy someone (each post is created by someone) returning also the user info of that someone (username, password...)
Следећи упит бира све објаве које је креирао неко са лозинком и враћа лозинку:
Potpuna kontrola where klauzule:
Pogledajmo ovo gde napadač može kontrolisati where
klauzulu:
Moguće je direktno filtrirati lozinku korisnika kao:
Korišćenjem operacija kao što je startsWith
moguće je otkriti informacije.
Zaobilaženje filtriranja u mnogim-relacijama:
Moguće je otkriti neobjavljene članke vraćanjem na mnoge-na-mnoge odnose između Category
-[*..*]-> Article
:
Takođe je moguće leak-ovati sve korisnike zloupotrebom nekih loop back many-to-many odnosa:
Greške/Upitnici sa vremenskim odlaganjem: U originalnom postu možete pročitati veoma opsežan skup testova koji su izvedeni kako bi se pronašao optimalni payload za curenje informacija sa payload-om zasnovanim na vremenu. Ovo je:
Gde je {CONTAINS_LIST}
lista sa 1000 stringova kako bi se osiguralo da odgovor bude odložen kada se pronađe ispravna leak.
Ove trikove su pronašli u ovom postu.
Napomena da Ransack 4.0.0.0 sada zahteva korišćenje eksplicitne dozvoljene liste za pretražive atribute i asocijacije.
Vulnerable example:
Napomena kako će upit biti definisan parametrima koje šalje napadač. Bilo je moguće, na primer, izvršiti brute-force napad na reset token sa:
By brute-forcing and potentially relationships it was possible to leak more data from a database.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)