OAuth to Account takeover

Reading time: 18 minutes

Basic Information

Το OAuth προσφέρει διάφορες εκδόσεις, με θεμελιώδεις πληροφορίες διαθέσιμες στην OAuth 2.0 documentation. Αυτή η συζήτηση επικεντρώνεται κυρίως στον ευρέως χρησιμοποιούμενο OAuth 2.0 authorization code grant type, παρέχοντας ένα πλαίσιο εξουσιοδότησης που επιτρέπει σε μια εφαρμογή να έχει πρόσβαση ή να εκτελεί ενέργειες στον λογαριασμό ενός χρήστη σε άλλη εφαρμογή (τον εξουσιοδοτημένο διακομιστή).

Σκεφτείτε μια υποθετική ιστοσελίδα https://example.com, σχεδιασμένη να παρουσιάζει όλες τις αναρτήσεις σας στα κοινωνικά δίκτυα, συμπεριλαμβανομένων των ιδιωτικών. Για να το επιτύχει αυτό, χρησιμοποιείται το OAuth 2.0. https://example.com θα ζητήσει την άδειά σας να έχει πρόσβαση στις αναρτήσεις σας στα κοινωνικά δίκτυα. Ως αποτέλεσμα, θα εμφανιστεί μια οθόνη συγκατάθεσης στο https://socialmedia.com, περιγράφοντας τις άδειες που ζητούνται και τον προγραμματιστή που υποβάλλει το αίτημα. Μετά την εξουσιοδότησή σας, το https://example.com αποκτά τη δυνατότητα να έχει πρόσβαση στις αναρτήσεις σας εκ μέρους σας.

Είναι σημαντικό να κατανοήσετε τα παρακάτω στοιχεία μέσα στο πλαίσιο του OAuth 2.0:

• resource owner: Εσείς, ως χρήστης/οντότητα, εξουσιοδοτείτε την πρόσβαση στους πόρους σας, όπως οι αναρτήσεις του λογαριασμού σας στα κοινωνικά δίκτυα.
• resource server: Ο διακομιστής που διαχειρίζεται τις αυθεντικοποιημένες αιτήσεις αφού η εφαρμογή έχει εξασφαλίσει ένα access token εκ μέρους του resource owner, π.χ., https://socialmedia.com.
• client application: Η εφαρμογή που ζητά εξουσιοδότηση από τον resource owner, όπως https://example.com.
• authorization server: Ο διακομιστής που εκδίδει access tokens στην client application μετά την επιτυχή αυθεντικοποίηση του resource owner και την εξασφάλιση εξουσιοδότησης, π.χ., https://socialmedia.com.
• client_id: Ένας δημόσιος, μοναδικός αναγνωριστικός αριθμός για την εφαρμογή.
• client_secret: Ένα εμπιστευτικό κλειδί, γνωστό μόνο στην εφαρμογή και τον εξουσιοδοτημένο διακομιστή, που χρησιμοποιείται για τη δημιουργία access_tokens.
• response_type: Μια τιμή που καθορίζει τον τύπο του αιτούμενου token, όπως code.
• scope: Το επίπεδο πρόσβασης που ζητά η client application από τον resource owner.
• redirect_uri: Η διεύθυνση URL στην οποία ανακατευθύνεται ο χρήστης μετά την εξουσιοδότηση. Αυτό συνήθως πρέπει να ευθυγραμμίζεται με την προεγγεγραμμένη διεύθυνση URL ανακατεύθυνσης.
• state: Ένα παράμετρος για τη διατήρηση δεδομένων κατά την ανακατεύθυνση του χρήστη προς και από τον εξουσιοδοτημένο διακομιστή. Η μοναδικότητά του είναι κρίσιμη για να λειτουργεί ως μηχανισμός προστασίας CSRF.
• grant_type: Ένα παράμετρος που υποδεικνύει τον τύπο χορήγησης και τον τύπο του token που θα επιστραφεί.
• code: Ο κωδικός εξουσιοδότησης από τον authorization server, που χρησιμοποιείται σε συνδυασμό με client_id και client_secret από την client application για να αποκτήσει ένα access_token.
• access_token: Το token που χρησιμοποιεί η client application για αιτήσεις API εκ μέρους του resource owner.
• refresh_token: Επιτρέπει στην εφαρμογή να αποκτήσει ένα νέο access_token χωρίς να ζητήσει ξανά από τον χρήστη.

Flow

Η πραγματική ροή OAuth προχωρά ως εξής:

1. Πλοηγείστε στο https://example.com και επιλέξτε το κουμπί “Integrate with Social Media”.
2. Ο ιστότοπος στέλνει στη συνέχεια ένα αίτημα στο https://socialmedia.com ζητώντας την εξουσιοδότησή σας να επιτρέψετε στην εφαρμογή του https://example.com να έχει πρόσβαση στις αναρτήσεις σας. Το αίτημα διαρθρώνεται ως:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Στη συνέχεια, σας παρουσιάζεται μια σελίδα συγκατάθεσης.
4. Μετά την έγκρισή σας, το Social Media στέλνει μια απάντηση στο redirect_uri με τις παραμέτρους code και state:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com χρησιμοποιεί αυτό το code, μαζί με το client_id και το client_secret, για να κάνει ένα αίτημα από τον διακομιστή για να αποκτήσει ένα access_token εκ μέρους σας, επιτρέποντας την πρόσβαση στις άδειες που έχετε συμφωνήσει:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Τέλος, η διαδικασία ολοκληρώνεται καθώς το https://example.com χρησιμοποιεί το access_token σας για να κάνει μια κλήση API στο Social Media για πρόσβαση

Ευπάθειες

Ανοιχτό redirect_uri

Το redirect_uri είναι κρίσιμο για την ασφάλεια στις υλοποιήσεις OAuth και OpenID, καθώς καθορίζει πού αποστέλλονται ευαίσθητα δεδομένα, όπως οι κωδικοί εξουσιοδότησης, μετά την εξουσιοδότηση. Εάν είναι κακώς ρυθμισμένο, μπορεί να επιτρέψει στους επιτιθέμενους να ανακατευθύνουν αυτά τα αιτήματα σε κακόβουλους διακομιστές, διευκολύνοντας την κατάληψη λογαριασμού.

Οι τεχνικές εκμετάλλευσης ποικίλλουν ανάλογα με τη λογική επικύρωσης του διακομιστή εξουσιοδότησης. Μπορεί να κυμαίνονται από αυστηρή αντιστοίχιση διαδρομών έως αποδοχή οποιασδήποτε διεύθυνσης URL εντός του καθορισμένου τομέα ή υποκαταλόγου. Κοινές μέθοδοι εκμετάλλευσης περιλαμβάνουν ανοιχτές ανακατευθύνσεις, διαδρομές διαδρομής, εκμετάλλευση αδύναμων regex και HTML injection για κλοπή διακριτικών.

Εκτός από το redirect_uri, άλλες παράμετροι OAuth και OpenID όπως client_uri, policy_uri, tos_uri και initiate_login_uri είναι επίσης ευάλωτες σε επιθέσεις ανακατεύθυνσης. Αυτές οι παράμετροι είναι προαιρετικές και η υποστήριξή τους ποικίλλει μεταξύ των διακομιστών.

Για εκείνους που στοχεύουν σε έναν διακομιστή OpenID, το endpoint ανακάλυψης (**.well-known/openid-configuration**) συχνά παραθέτει πολύτιμες λεπτομέρειες ρύθμισης όπως registration_endpoint, request_uri_parameter_supported και "require_request_uri_registration. Αυτές οι λεπτομέρειες μπορούν να βοηθήσουν στην αναγνώριση του endpoint εγγραφής και άλλων λεπτομερειών ρύθμισης του διακομιστή.

XSS στην υλοποίηση ανακατεύθυνσης

Όπως αναφέρεται σε αυτή την αναφορά bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, μπορεί να είναι δυνατόν ότι το URL ανακατεύθυνσης αντικατοπτρίζεται στην απόκριση του διακομιστή μετά την αυθεντικοποίηση του χρήστη, είναι ευάλωτο σε XSS. Πιθανό payload για δοκιμή:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Improper handling of state parameter

Στις υλοποιήσεις OAuth, η κακή χρήση ή η παράλειψη της state παραμέτρου μπορεί να αυξήσει σημαντικά τον κίνδυνο επιθέσεων Cross-Site Request Forgery (CSRF). Αυτή η ευπάθεια προκύπτει όταν η state παράμετρος είναι είτε μη χρησιμοποιούμενη, χρησιμοποιούμενη ως στατική τιμή, ή μη σωστά επικυρωμένη ή συσχετισμένη με τη συνεδρία του χρήστη κατά την είσοδο, επιτρέποντας στους επιτιθέμενους να παρακάμψουν τις προστασίες CSRF.

Οι επιτιθέμενοι μπορούν να εκμεταλλευτούν αυτό το γεγονός παρεμβαίνοντας στη διαδικασία εξουσιοδότησης για να συνδέσουν τον λογαριασμό τους με τον λογαριασμό ενός θύματος, οδηγώντας σε πιθανές καταλήψεις λογαριασμών κάνοντάς τον χρήστη να συνδεθεί με μια σχεδόν ολοκληρωμένη ροή oauth που ανήκει στον επιτιθέμενο. Αυτό είναι ιδιαίτερα κρίσιμο σε εφαρμογές όπου το OAuth χρησιμοποιείται για σκοπούς αυθεντικοποίησης.

Πραγματικά παραδείγματα αυτής της ευπάθειας έχουν καταγραφεί σε διάφορες CTF προκλήσεις και πλατφόρμες hacking, αναδεικνύοντας τις πρακτικές της επιπτώσεις. Το ζήτημα επεκτείνεται επίσης σε ενσωματώσεις με τρίτες υπηρεσίες όπως Slack, Stripe, και PayPal, όπου οι επιτιθέμενοι μπορούν να ανακατευθύνουν ειδοποιήσεις ή πληρωμές στους λογαριασμούς τους.

Η σωστή διαχείριση και επικύρωση της state παραμέτρου είναι κρίσιμη για την προστασία από CSRF και την ασφάλιση της ροής OAuth.

Pre Account Takeover

1. Χωρίς Επικύρωση Email κατά τη Δημιουργία Λογαριασμού: Οι επιτιθέμενοι μπορούν προληπτικά να δημιουργήσουν έναν λογαριασμό χρησιμοποιώντας το email του θύματος. Εάν το θύμα αργότερα χρησιμοποιήσει μια τρίτη υπηρεσία για είσοδο, η εφαρμογή μπορεί ακούσια να συνδέσει αυτόν τον τρίτο λογαριασμό με τον προδημιουργημένο λογαριασμό του επιτιθέμενου, οδηγώντας σε μη εξουσιοδοτημένη πρόσβαση.
2. Εκμετάλλευση Χαλαρής Επικύρωσης Email OAuth: Οι επιτιθέμενοι μπορεί να εκμεταλλευτούν υπηρεσίες OAuth που δεν επικυρώνουν τα emails, εγγραφόμενοι με την υπηρεσία τους και στη συνέχεια αλλάζοντας το email του λογαριασμού στο email του θύματος. Αυτή η μέθοδος κινδυνεύει επίσης με μη εξουσιοδοτημένη πρόσβαση στον λογαριασμό, παρόμοια με το πρώτο σενάριο αλλά μέσω διαφορετικού επιθετικού διαύλου.

Disclosure of Secrets

Η αναγνώριση και η προστασία των μυστικών παραμέτρων OAuth είναι κρίσιμη. Ενώ η client_id μπορεί να αποκαλυφθεί με ασφάλεια, η αποκάλυψη της client_secret ενέχει σημαντικούς κινδύνους. Εάν η client_secret παραβιαστεί, οι επιτιθέμενοι μπορούν να εκμεταλλευτούν την ταυτότητα και την εμπιστοσύνη της εφαρμογής για να κλέψουν τα access_tokens χρηστών και ιδιωτικές πληροφορίες.

Μια κοινή ευπάθεια προκύπτει όταν οι εφαρμογές χειρίζονται κατά λάθος την ανταλλαγή του code εξουσιοδότησης για ένα access_token στην πλευρά του πελάτη αντί για την πλευρά του διακομιστή. Αυτό το λάθος οδηγεί στην έκθεση της client_secret, επιτρέποντας στους επιτιθέμενους να δημιουργούν access_tokens υπό την κάλυψη της εφαρμογής. Επιπλέον, μέσω κοινωνικής μηχανικής, οι επιτιθέμενοι θα μπορούσαν να κλιμακώσουν τα προνόμια προσθέτοντας επιπλέον πεδία στην εξουσιοδότηση OAuth, εκμεταλλευόμενοι περαιτέρω την εμπιστοσύνη της εφαρμογής.

Client Secret Bruteforce

Μπορείτε να προσπαθήσετε να bruteforce την client_secret ενός παρόχου υπηρεσιών με τον πάροχο ταυτότητας προκειμένου να προσπαθήσετε να κλέψετε λογαριασμούς.
Το αίτημα για BF μπορεί να μοιάζει με:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

Μόλις ο πελάτης έχει τον κωδικό και την κατάσταση, αν είναι αντανάκλαση μέσα στην κεφαλίδα Referer όταν περιηγείται σε μια διαφορετική σελίδα, τότε είναι ευάλωτος.

Access Token Stored in Browser History

Πηγαίνετε στο ιστορικό του προγράμματος περιήγησης και ελέγξτε αν το access token είναι αποθηκευμένο εκεί.

Everlasting Authorization Code

Ο κωδικός εξουσιοδότησης θα πρέπει να ζει μόνο για κάποιο χρονικό διάστημα για να περιορίσει το χρονικό παράθυρο όπου ένας επιτιθέμενος μπορεί να τον κλέψει και να τον χρησιμοποιήσει.

Authorization/Refresh Token not bound to client

Αν μπορείτε να αποκτήσετε τον κωδικό εξουσιοδότησης και να τον χρησιμοποιήσετε με έναν διαφορετικό πελάτη τότε μπορείτε να αναλάβετε άλλους λογαριασμούς.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Δείτε αυτή την ανάρτηση

AWS Cognito

Σε αυτή την αναφορά bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ μπορείτε να δείτε ότι το token που επιστρέφει ο AWS Cognito στον χρήστη μπορεί να έχει αρκετές άδειες για να αντικαταστήσει τα δεδομένα του χρήστη. Επομένως, αν μπορείτε να αλλάξετε το email του χρήστη για ένα διαφορετικό email χρήστη, μπορεί να είστε σε θέση να αναλάβετε άλλους λογαριασμούς.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Για περισσότερες λεπτομέρειες σχετικά με το πώς να εκμεταλλευτείτε το AWS cognito, ελέγξτε:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Εκμετάλλευση άλλων tokens εφαρμογών

Όπως αναφέρεται σε αυτή τη γραφή, οι ροές OAuth που αναμένουν να λάβουν το token (και όχι έναν κωδικό) θα μπορούσαν να είναι ευάλωτες αν δεν ελέγχουν ότι το token ανήκει στην εφαρμογή.

Αυτό συμβαίνει επειδή ένας επιτιθέμενος θα μπορούσε να δημιουργήσει μια εφαρμογή που υποστηρίζει OAuth και να συνδεθεί με το Facebook (για παράδειγμα) στην δική του εφαρμογή. Στη συνέχεια, μόλις ένα θύμα συνδεθεί με το Facebook στην εφαρμογή του επιτιθέμενου, ο επιτιθέμενος θα μπορούσε να αποκτήσει το OAuth token του χρήστη που δόθηκε στην εφαρμογή του και να το χρησιμοποιήσει για να συνδεθεί στην εφαρμογή OAuth του θύματος χρησιμοποιώντας το token του χρήστη του θύματος.

Δύο σύνδεσμοι & cookie

Σύμφωνα με αυτή τη γραφή, ήταν δυνατό να κάνετε ένα θύμα να ανοίξει μια σελίδα με ένα returnUrl που δείχνει στον διακομιστή του επιτιθέμενου. Αυτή η πληροφορία θα αποθηκευόταν σε ένα cookie (RU) και σε ένα μετέπειτα βήμα το prompt θα ρωτούσε τον χρήστη αν θέλει να δώσει πρόσβαση σε αυτόν τον διακομιστή του επιτιθέμενου.

Για να παρακαμφθεί αυτό το prompt, ήταν δυνατό να ανοίξει μια καρτέλα για να ξεκινήσει τη ροή Oauth που θα ρύθμιζε αυτό το cookie RU χρησιμοποιώντας το returnUrl, να κλείσει την καρτέλα πριν εμφανιστεί το prompt και να ανοίξει μια νέα καρτέλα χωρίς αυτή την τιμή. Στη συνέχεια, το prompt δεν θα ενημερώσει για τον διακομιστή του επιτιθέμενου, αλλά το cookie θα ρυθμιστεί σε αυτόν, έτσι το token θα σταλεί στον διακομιστή του επιτιθέμενου κατά την ανακατεύθυνση.

Παράκαμψη αλληλεπίδρασης prompt

Όπως εξηγείται σε αυτό το βίντεο, ορισμένες υλοποιήσεις OAuth επιτρέπουν να υποδεικνύεται η παράμετρος prompt GET ως None (&prompt=none) για να αποτραπεί η ερώτηση στους χρήστες να επιβεβαιώσουν την παραχωρηθείσα πρόσβαση σε ένα prompt στο διαδίκτυο αν είναι ήδη συνδεδεμένοι στην πλατφόρμα.

response_mode

Όπως εξηγείται σε αυτό το βίντεο, μπορεί να είναι δυνατό να υποδειχθεί η παράμετρος response_mode για να δηλώσετε πού θέλετε να παρασχεθεί ο κωδικός στην τελική διεύθυνση URL:

• response_mode=query -> Ο κωδικός παρέχεται μέσα σε μια παράμετρο GET: ?code=2397rf3gu93f
• response_mode=fragment -> Ο κωδικός παρέχεται μέσα στην παράμετρο τμήματος της διεύθυνσης URL #code=2397rf3gu93f
• response_mode=form_post -> Ο κωδικός παρέχεται μέσα σε μια φόρμα POST με μια είσοδο που ονομάζεται code και την τιμή
• response_mode=web_message -> Ο κωδικός αποστέλλεται σε ένα μήνυμα post: window.opener.postMessage({"code": "asdasdasd...

Ροή OAuth ROPC - Παράκαμψη 2 FA

Σύμφωνα με αυτή την ανάρτηση στο blog, αυτή είναι μια ροή OAuth που επιτρέπει τη σύνδεση στο OAuth μέσω όνομα χρήστη και κωδικού πρόσβασης. Αν κατά τη διάρκεια αυτής της απλής ροής επιστραφεί ένα token με πρόσβαση σε όλες τις ενέργειες που μπορεί να εκτελέσει ο χρήστης, τότε είναι δυνατό να παρακαμφθεί η 2FA χρησιμοποιώντας αυτό το token.

ATO σε ιστοσελίδα που ανακατευθύνει με βάση το open redirect στον παραπομπέα

Αυτή η ανάρτηση στο blog σχολιάζει πώς ήταν δυνατό να εκμεταλλευτείτε ένα open redirect στην τιμή από τον παραπομπέα για να εκμεταλλευτείτε το OAuth για ATO. Η επίθεση ήταν:

1. Το θύμα αποκτά πρόσβαση στην ιστοσελίδα του επιτιθέμενου
2. Το θύμα ανοίγει τον κακόβουλο σύνδεσμο και ένας opener ξεκινά τη ροή Google OAuth με response_type=id_token,code&prompt=none ως πρόσθετες παραμέτρους χρησιμοποιώντας ως παραπομπέα την ιστοσελίδα του επιτιθέμενου.
3. Στον opener, αφού ο πάροχος εξουσιοδοτήσει το θύμα, το στέλνει πίσω στην τιμή της παραμέτρου redirect_uri (ιστοσελίδα θύματος) με κωδικό 30X που διατηρεί ακόμα την ιστοσελίδα του επιτιθέμενου στον παραπομπέα.
4. Η ιστοσελίδα του θύματος ενεργοποιεί το open redirect με βάση τον παραπομπέα ανακατευθύνοντας τον χρήστη του θύματος στην ιστοσελίδα του επιτιθέμενου, καθώς το respose_type ήταν id_token,code, ο κωδικός θα σταλεί πίσω στον επιτιθέμενο στο τμήμα της διεύθυνσης URL επιτρέποντάς του να αναλάβει τον λογαριασμό του χρήστη μέσω Google στην ιστοσελίδα του θύματος.

Παράμετροι SSRFs

Ελέγξτε αυτή την έρευνα Για περισσότερες λεπτομέρειες σχετικά με αυτή την τεχνική.

Η Δυναμική Εγγραφή Πελάτη στο OAuth λειτουργεί ως λιγότερο προφανής αλλά κρίσιμος παράγοντας για ευπάθειες ασφαλείας, ειδικότερα για επιθέσεις Server-Side Request Forgery (SSRF). Αυτό το endpoint επιτρέπει στους διακομιστές OAuth να λαμβάνουν λεπτομέρειες σχετικά με τις εφαρμογές πελατών, συμπεριλαμβανομένων ευαίσθητων URLs που θα μπορούσαν να εκμεταλλευτούν.

Κύρια Σημεία:

• Η Δυναμική Εγγραφή Πελάτη συχνά αντιστοιχεί στο /register και δέχεται λεπτομέρειες όπως client_name, client_secret, redirect_uris, και URLs για λογότυπα ή JSON Web Key Sets (JWKs) μέσω αιτημάτων POST.
• Αυτή η δυνατότητα συμμορφώνεται με τις προδιαγραφές που καθορίζονται στο RFC7591 και OpenID Connect Registration 1.0, οι οποίες περιλαμβάνουν παραμέτρους που ενδέχεται να είναι ευάλωτες σε SSRF.
• Η διαδικασία εγγραφής μπορεί ακούσια να εκθέσει τους διακομιστές σε SSRF με διάφορους τρόπους:
• logo_uri: Ένα URL για το λογότυπο της εφαρμογής πελάτη που μπορεί να ανακτηθεί από τον διακομιστή, προκαλώντας SSRF ή οδηγώντας σε XSS αν το URL δεν διαχειριστεί σωστά.
• jwks_uri: Ένα URL στο έγγραφο JWK του πελάτη, το οποίο αν κατασκευαστεί κακόβουλα, μπορεί να προκαλέσει στον διακομιστή να κάνει εξωτερικά αιτήματα σε έναν διακομιστή ελεγχόμενο από τον επιτιθέμενο.
• sector_identifier_uri: Αναφέρεται σε έναν πίνακα JSON των redirect_uris, τον οποίο ο διακομιστής μπορεί να ανακτήσει, δημιουργώντας μια ευκαιρία SSRF.
• request_uris: Λίστα επιτρεπόμενων URI αιτημάτων για τον πελάτη, που μπορεί να εκμεταλλευτεί αν ο διακομιστής ανακτήσει αυτά τα URI στην αρχή της διαδικασίας εξουσιοδότησης.

Στρατηγική Εκμετάλλευσης:

• Το SSRF μπορεί να ενεργοποιηθεί καταχωρώντας έναν νέο πελάτη με κακόβουλα URLs σε παραμέτρους όπως logo_uri, jwks_uri, ή sector_identifier_uri.
• Ενώ η άμεση εκμετάλλευση μέσω request_uris μπορεί να μετριαστεί από ελέγχους whitelist, η παροχή ενός προεγγεγραμμένου, ελεγχόμενου από τον επιτιθέμενο request_uri μπορεί να διευκολύνει το SSRF κατά τη διάρκεια της φάσης εξουσιοδότησης.

Συνθήκες Αγώνα Παρόχων OAuth

Αν η πλατφόρμα που δοκιμάζετε είναι πάροχος OAuth διαβάστε αυτό για να δοκιμάσετε πιθανές Συνθήκες Αγώνα.

Επίθεση Mutable Claims

Στο OAuth, το πεδίο sub προσδιορίζει μοναδικά έναν χρήστη, αλλά η μορφή του διαφέρει ανάλογα με τον Διακομιστή Εξουσιοδότησης. Για να τυποποιήσουν την αναγνώριση χρηστών, ορισμένοι πελάτες χρησιμοποιούν email ή χειριστές χρηστών. Ωστόσο, αυτό είναι επικίνδυνο επειδή:

• Ορισμένοι Διακομιστές Εξουσιοδότησης δεν διασφαλίζουν ότι αυτές οι ιδιότητες (όπως το email) παραμένουν αμετάβλητες.
• Σε ορισμένες υλοποιήσεις—όπως το "Σύνδεση με Microsoft"—ο πελάτης βασίζεται στο πεδίο email, το οποίο είναι ελεγχόμενο από τον χρήστη στο Entra ID και δεν επαληθεύεται.
• Ένας επιτιθέμενος μπορεί να εκμεταλλευτεί αυτό δημιουργώντας τη δική του οργάνωση Azure AD (π.χ. doyensectestorg) και χρησιμοποιώντας την για να πραγματοποιήσει μια σύνδεση Microsoft.
• Παρόλο που το Object ID (αποθηκευμένο στο sub) είναι αμετάβλητο και ασφαλές, η εξάρτηση από ένα μεταβλητό πεδίο email μπορεί να επιτρέψει μια ανάληψη λογαριασμού (για παράδειγμα, η κατάληψη ενός λογαριασμού όπως το victim@gmail.com).

Επίθεση Client Confusion

Σε μια Επίθεση Client Confusion, μια εφαρμογή που χρησιμοποιεί τη Ροή OAuth Implicit αποτυγχάνει να επαληθεύσει ότι το τελικό access token έχει παραχθεί ειδικά για το δικό της Client ID. Ένας επιτιθέμενος δημιουργεί μια δημόσια ιστοσελίδα που χρησιμοποιεί τη Ροή OAuth Implicit της Google, εξαπατώντας χιλιάδες χρήστες να συνδεθούν και έτσι συλλέγοντας access tokens που προορίζονται για την ιστοσελίδα του επιτιθέμενου. Αν αυτοί οι χρήστες έχουν επίσης λογαριασμούς σε άλλη ευάλωτη ιστοσελίδα που δεν επαληθεύει το Client ID του token, ο επιτιθέμενος μπορεί να επαναχρησιμοποιήσει τα συλλεγμένα tokens για να προσποιηθεί τους θύματα και να αναλάβει τους λογαριασμούς τους.

Επίθεση Scope Upgrade

Ο τύπος Authorization Code Grant περιλαμβάνει ασφαλή επικοινωνία server-to-server για τη μετάδοση δεδομένων χρηστών. Ωστόσο, αν ο Authorization Server εμπιστεύεται έμμεσα μια παράμετρο scope στην Αίτηση Access Token (μια παράμετρο που δεν ορίζεται στο RFC), μια κακόβουλη εφαρμογή θα μπορούσε να αναβαθμίσει τα προνόμια ενός κωδικού εξουσιοδότησης ζητώντας ένα υψηλότερο scope. Αφού παραχθεί το Access Token, ο Resource Server πρέπει να το επαληθεύσει: για τα JWT tokens, αυτό περιλαμβάνει τον έλεγχο της υπογραφής JWT και την εξαγωγή δεδομένων όπως client_id και scope, ενώ για τα tokens τυχαίων συμβολοσειρών, ο διακομιστής πρέπει να ρωτήσει τον Authorization Server για να ανακτήσει τις λεπτομέρειες του token.

Hijacking Σχεδίου Ανακατεύθυνσης

Σε υλοποιήσεις OAuth για κινητά, οι εφαρμογές χρησιμοποιούν προσαρμοσμένα URI schemes για να λαμβάνουν ανακατευθύνσεις με Κωδικούς Εξουσιοδότησης. Ωστόσο, επειδή πολλές εφαρμογές μπορούν να καταχωρήσουν το ίδιο scheme σε μια συσκευή, η υπόθεση ότι μόνο ο νόμιμος πελάτης ελέγχει το URI ανακατεύθυνσης παραβιάζεται. Στο Android, για παράδειγμα, ένα Intent URI όπως com.example.app:// oauth συλλαμβάνεται με βάση το scheme και τις προαιρετικές φίλτρα που ορίζονται στο intent-filter μιας εφαρμογής. Δεδομένου ότι η επίλυση προθέσεων του Android μπορεί να είναι ευρεία—ειδικά αν μόνο το scheme καθορίζεται—ένας επιτιθέμενος μπορεί να καταχωρήσει μια κακόβουλη εφαρμογή με ένα προσεκτικά κατασκευασμένο intent filter για να ανακατευθύνει τον κωδικό εξουσιοδότησης. Αυτό μπορεί να επιτρέψει μια ανάληψη λογαριασμού είτε μέσω αλληλεπίδρασης χρήστη (όταν πολλές εφαρμογές είναι επιλέξιμες να χειριστούν την πρόθεση) είτε μέσω τεχνικών παράκαμψης που εκμεταλλεύονται υπερβολικά συγκεκριμένα φίλτρα, όπως περιγράφεται από το διάγραμμα ροής αξιολόγησης του Ostorlab.

Αναφορές

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html