hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth για Εκμετάλλευση Λογαριασμού

Μάθετε το χάκινγκ στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

• Αν θέλετε να δείτε την εταιρεία σας διαφημισμένη στο HackTricks ή να κατεβάσετε το HackTricks σε PDF ελέγξτε τα ΣΧΕΔΙΑ ΣΥΝΔΡΟΜΗΣ!
• Αποκτήστε το επίσημο PEASS & HackTricks swag
• Ανακαλύψτε την Οικογένεια PEASS, τη συλλογή μας από αποκλειστικά NFTs
• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα τηλεγραφήματος ή ακολουθήστε μας στο Twitter 🐦 @carlospolopm.
• Μοιραστείτε τα χάκινγκ κόλπα σας υποβάλλοντας PRs στα HackTricks και HackTricks Cloud αποθετήρια του github.

{% embed url="https://websec.nl/" %}

Βασικές Πληροφορίες

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

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

Είναι σημαντικό να κατανοήσετε τα ακόλουθα στοιχεία εντός του πλαισίου OAuth 2.0:

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

Ροή

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

1. Μεταβαίνετε στο https://example.com και επιλέγετε το κουμπί "Ενσωμάτωση με τα Κοινωνικά Δίκτυα".
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. Ακολουθώντας την έγκρισή σας, τα Κοινωνικά Δίκτυα στέλνουν μια απάντηση στο 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 στα Κοινωνικά Δίκτυα για πρόσβαση

Ευπάθειες

Ανοιχτή redirect_uri

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

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

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

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

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

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

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

CSRF - Ανακατεύθυνση του παραμέτρου κατάστασης

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

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

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

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

Πριν από την Κατάληψη Λογαριασμού

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

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

Αποκάλυψη Μυστικών

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

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

Βίαιη Δοκιμή Κλειδιού Πελάτη

Μπορείτε να δοκιμάσετε βίαια το κλειδί πελάτη ενός παροχέα υπηρεσιών με τον πάροχο ταυτότητας προκειμένου να προσπαθήσετε να κλέψετε λογαριασμούς.
Το αίτημα για 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)

Αφού ο πελάτης έχει τον κώδικα και την κατάσταση, αν αυτά αντανακλώνται μέσα στον Κεφαλίδα Αναφορέα (Referer header) όταν περιηγείται σε διαφορετική σελίδα, τότε είναι ευάλωτο.

Πρόσβαση Κλειδιού Πρόσβασης Αποθηκευμένου στο Ιστορικό του Προγράμματος Περιήγησης

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

Κωδικός Εξουσιοδότησης που Διαρκεί για Πάντα

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

Κωδικός Εξουσιοδότησης/Ανανέωσης που δεν συνδέεται με τον πελάτη

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

Ευτυχισμένες Διαδρομές, XSS, Iframes & Αποστολή Μηνυμάτων για τη Διαρροή κωδικού & κατάστασης

Ελέγξτε αυτήν την ανάρτηση

AWS Cognito

Σε αυτήν την αναφορά ευρήματος ανταμοιβής ευρήματος σφαλμάτων: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ μπορείτε να δείτε ότι το διακριτικό που δίνει πίσω το 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"
}
]
}

Κατάχρηση των τεκμηρίων άλλων εφαρμογών

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

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

{% hint style="danger" %} Συνεπώς, αν ο επιτιθέμενος καταφέρει να κάνει τον χρήστη να δώσει πρόσβαση στη δική του εφαρμογή OAuth, θα μπορέσει να αναλάβει τον έλεγχο του λογαριασμού του θύματος σε εφαρμογές που αναμένουν ένα token και δεν ελέγχουν αν το token χορηγήθηκε στο αναγνωριστικό της εφαρμογής τους. {% endhint %}

Δύο συνδέσμοι & cookie

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

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

Παράμετροι SSRFs

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

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

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

• Η Δυναμική Εγγραφή Πελάτη συνήθως αντιστοιχίζεται στο /register και δέχεται λεπτομέρειες όπως client_name, client_secret, redirect_uris, και διευθύνσεις URL για λογότυπα ή 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 μπορεί να ενεργοποιηθεί με την εγγραφή ενός νέου πελάτη με κακόβουλες διευθύνσεις URL σε παραμέτρους όπως logo_uri, jwks_uri, ή sector_identifier_uri.
• Ενώ η άμεση εκμετάλλευση μέσω του request_uris μπορεί να αντιμετωπιστεί με ελέγχους λευκής λίστας, η παροχή ενός προ-εγγεγραμμένου, ελεγχόμενου από τον επιτιθέμενο request_uri μπορεί να διευκολύνει το SSRF κατά τη διάρκεια της φάσης εξουσιοδότησης.