Στις 19 Ιουλίου 2019, η Capital One έλαβε το μήνυμα που φοβάται κάθε σύγχρονη εταιρεία - σημειώθηκε παραβίαση δεδομένων. Επηρέασε περισσότερους από 106 εκατομμύρια ανθρώπους. 140 αριθμοί κοινωνικής ασφάλισης ΗΠΑ, ένα εκατομμύριο καναδικοί αριθμοί κοινωνικής ασφάλισης. 000 τραπεζικοί λογαριασμοί. Δυσάρεστο, δεν συμφωνείτε;
Δυστυχώς, το hack δεν συνέβη στις 19 Ιουλίου. Όπως αποδεικνύεται, η Paige Thompson, a.k.a. Ασταθής, το διέπραξε μεταξύ 22 Μαρτίου και 23 Μαρτίου 2019. Αυτό είναι σχεδόν τέσσερις μήνες πριν. Στην πραγματικότητα, μόνο με τη βοήθεια εξωτερικών συμβούλων το Capital One μπόρεσε να ανακαλύψει ότι κάτι είχε συμβεί.
Ένας πρώην υπάλληλος της Amazon συνελήφθη και αντιμετωπίζει πρόστιμο 250 δολαρίων και πέντε χρόνια φυλάκιση... αλλά απομένει πολύς αρνητισμός. Γιατί; Διότι πολλές εταιρείες που έχουν υποφέρει από hacks προσπαθούν να αποποιηθούν την ευθύνη για την ενίσχυση της υποδομής και των εφαρμογών τους εν μέσω της αύξησης του εγκλήματος στον κυβερνοχώρο.
Τέλος πάντων, μπορείτε εύκολα να αναζητήσετε στο google αυτή την ιστορία. Δεν θα πάμε στο δράμα, αλλά θα μιλήσουμε τεχνικός πλευρά του θέματος.
Καταρχήν τι έγινε;
Το Capital One είχε περίπου 700 κουβάδες S3 σε λειτουργία, τους οποίους η Paige Thompson αντέγραψε και αφαίρεσε.
Δεύτερον, πρόκειται για άλλη μια περίπτωση εσφαλμένης διαμόρφωσης πολιτικής κάδου S3;
Οχι αυτή τη φορά. Εδώ απέκτησε πρόσβαση σε έναν διακομιστή με εσφαλμένα ρυθμισμένο τείχος προστασίας και πραγματοποίησε ολόκληρη τη λειτουργία από εκεί.
Περίμενε, πώς είναι δυνατόν;
Λοιπόν, ας ξεκινήσουμε με τη σύνδεση στον διακομιστή, αν και δεν έχουμε πολλές λεπτομέρειες. Μας είπαν μόνο ότι συνέβη μέσω ενός "εσφαλμένου τείχους προστασίας". Έτσι, κάτι τόσο απλό όπως εσφαλμένες ρυθμίσεις ομάδας ασφαλείας ή διαμόρφωση του τείχους προστασίας της εφαρμογής web (Imperva) ή του τείχους προστασίας δικτύου (iptables, ufw, shorewall, κ.λπ.). Το Capital One παραδέχτηκε μόνο την ενοχή του και είπε ότι είχε κλείσει την τρύπα.
Ο Stone είπε ότι το Capital One δεν παρατήρησε αρχικά την ευπάθεια του τείχους προστασίας, αλλά ενήργησε γρήγορα μόλις το αντιλήφθηκε. Σε αυτό βοήθησε σίγουρα το γεγονός ότι ο χάκερ φέρεται να άφησε βασικές πληροφορίες αναγνώρισης στο δημόσιο τομέα, είπε ο Stone.
Εάν αναρωτιέστε γιατί δεν εμβαθύνουμε σε αυτό το μέρος, καταλάβετε ότι λόγω περιορισμένων πληροφοριών μπορούμε μόνο να κάνουμε εικασίες. Αυτό δεν έχει νόημα, δεδομένου ότι το hack εξαρτιόταν από μια τρύπα που άφησε το Capital One. Και εκτός και αν μας πουν περισσότερα, θα αναφέρουμε απλώς όλους τους πιθανούς τρόπους με τους οποίους η Capital One άφησε ανοιχτό τον διακομιστή της σε συνδυασμό με όλους τους πιθανούς τρόπους με τους οποίους κάποιος θα μπορούσε να χρησιμοποιήσει μία από αυτές τις διαφορετικές επιλογές. Αυτά τα ελαττώματα και οι τεχνικές μπορεί να κυμαίνονται από ανόητες παραλείψεις έως απίστευτα πολύπλοκα μοτίβα. Δεδομένου του φάσματος των δυνατοτήτων, αυτό θα γίνει ένα μακρύ έπος χωρίς πραγματικό συμπέρασμα. Επομένως, ας εστιάσουμε στην ανάλυση του μέρους όπου έχουμε γεγονότα.
Έτσι, το πρώτο πακέτο είναι: να ξέρετε τι επιτρέπουν τα τείχη προστασίας σας.
Καθιερώστε μια πολιτική ή μια κατάλληλη διαδικασία για να διασφαλίσετε ότι θα ανοίξει ΜΟΝΟ ό,τι πρέπει να ανοίξει. Εάν χρησιμοποιείτε πόρους AWS, όπως Ομάδες Ασφαλείας ή Δίκτυα ACL, προφανώς η λίστα ελέγχου για έλεγχο μπορεί να είναι μεγάλη... αλλά όπως πολλοί πόροι δημιουργούνται αυτόματα (π.χ. CloudFormation), είναι επίσης δυνατό να αυτοματοποιηθεί ο έλεγχος τους. Είτε πρόκειται για ένα αυτοσχέδιο σενάριο που σαρώνει νέα αντικείμενα για ελαττώματα, είτε κάτι σαν έλεγχος ασφαλείας σε μια διαδικασία CI/CD... υπάρχουν πολλές εύκολες επιλογές για να το αποφύγετε.
Το «αστείο» μέρος της ιστορίας είναι ότι αν το Capital One είχε βουλώσει την τρύπα από την αρχή... δεν θα είχε συμβεί τίποτα. Και έτσι, ειλικρινά, είναι πάντα σοκαριστικό να βλέπεις πώς κάτι πραγματικά πολύ απλό γίνεται ο μόνος λόγος για να χακαριστεί μια εταιρεία. Ειδικά ένα τόσο μεγάλο όσο το Capital One.
Λοιπόν, χάκερ μέσα - τι έγινε μετά;
Λοιπόν, μετά το σπάσιμο σε ένα στιγμιότυπο EC2... πολλά μπορεί να πάνε στραβά. Πρακτικά περπατάς στην κόψη του μαχαιριού αν αφήσεις κάποιον να πάει τόσο μακριά. Πώς μπήκε όμως στους κάδους του S3; Για να το κατανοήσουμε αυτό, ας συζητήσουμε τους ρόλους του IAM.
Έτσι, ένας τρόπος πρόσβασης στις υπηρεσίες AWS είναι να είστε Χρήστης. Εντάξει, αυτό είναι αρκετά προφανές. Τι γίνεται όμως αν θέλετε να δώσετε σε άλλες υπηρεσίες AWS, όπως οι διακομιστές εφαρμογών σας, πρόσβαση στους κάδους S3 σας; Γι' αυτό χρησιμεύουν οι ρόλοι του IAM. Αποτελούνται από δύο συστατικά:
- Πολιτική εμπιστοσύνης - ποιες υπηρεσίες ή άτομα μπορούν να χρησιμοποιήσουν αυτόν τον ρόλο;
- Πολιτική αδειών - τι επιτρέπει αυτός ο ρόλος;
Για παράδειγμα, θέλετε να δημιουργήσετε έναν ρόλο IAM που θα επιτρέπει στις παρουσίες EC2 να έχουν πρόσβαση σε έναν κάδο S3: Πρώτον, ο ρόλος έχει οριστεί να έχει μια Πολιτική εμπιστοσύνης που το EC2 (όλη η υπηρεσία) ή συγκεκριμένες παρουσίες μπορούν να «αναλάβουν» τον ρόλο. Η αποδοχή ενός ρόλου σημαίνει ότι μπορούν να χρησιμοποιήσουν τα δικαιώματα του ρόλου για να εκτελέσουν ενέργειες. Δεύτερον, η Πολιτική Δικαιωμάτων επιτρέπει στην υπηρεσία/άτομο/πόρο που «ανέλαβε το ρόλο» να κάνει οτιδήποτε στο S3, είτε πρόκειται για πρόσβαση σε έναν συγκεκριμένο κάδο... είτε σε πάνω από 700, όπως στην περίπτωση του Capital One.
Μόλις είστε σε μια παρουσία EC2 με το ρόλο IAM, μπορείτε να αποκτήσετε διαπιστευτήρια με διάφορους τρόπους:
- Μπορείτε να ζητήσετε μεταδεδομένα παρουσίας στο
http://169.254.169.254/latest/meta-dataΜεταξύ άλλων, μπορείτε να βρείτε τον ρόλο IAM με οποιοδήποτε από τα κλειδιά πρόσβασης σε αυτήν τη διεύθυνση. Φυσικά, μόνο αν είστε σε μια περίπτωση.
- Χρησιμοποιήστε το AWS CLI...
Εάν είναι εγκατεστημένο το AWS CLI, φορτώνεται με διαπιστευτήρια από τους ρόλους IAM, εάν υπάρχουν. Το μόνο που μένει είναι να δουλέψουμε ΜΕΣΩ από την περίπτωση. Φυσικά, εάν η Πολιτική εμπιστοσύνης τους ήταν ανοιχτή, η Paige θα μπορούσε να κάνει τα πάντα απευθείας.
Έτσι, η ουσία των ρόλων IAM είναι ότι επιτρέπουν σε κάποιους πόρους να ενεργούν για λογαριασμό σας σε ΑΛΛΟΥΣ ΠΟΡΟΥΣ.
Τώρα που καταλαβαίνετε τους ρόλους του IAM, μπορούμε να μιλήσουμε για το τι έκανε η Paige Thompson:
- Απέκτησε πρόσβαση στον διακομιστή (περίπτωση EC2) μέσω μιας τρύπας στο τείχος προστασίας
Είτε επρόκειτο για ομάδες ασφαλείας/ACL είτε για τα δικά τους τείχη προστασίας εφαρμογών ιστού, η τρύπα ήταν πιθανώς πολύ εύκολο να συνδεθεί, όπως αναφέρεται στα επίσημα αρχεία.
- Μόλις μπήκε στον διακομιστή, μπόρεσε να συμπεριφέρεται "σαν" να ήταν η ίδια ο διακομιστής
- Εφόσον ο ρόλος του διακομιστή IAM επέτρεπε στο S3 πρόσβαση σε αυτούς τους 700+ κουβάδες, μπορούσε να έχει πρόσβαση σε αυτούς
Από εκείνη τη στιγμή, το μόνο που έπρεπε να κάνει ήταν να εκτελέσει την εντολή List Bucketsκαι μετά η εντολή Sync από το AWS CLI...
. Η πρόληψη τέτοιων ζημιών είναι ο λόγος που οι εταιρείες επενδύουν τόσα πολλά στην προστασία υποδομής cloud, σε DevOps και σε ειδικούς σε θέματα ασφάλειας. Και πόσο πολύτιμη και οικονομικά αποδοτική είναι η μετάβαση στο cloud; Τόσο πολύ που ακόμη και ενόψει ολοένα και περισσότερων προκλήσεων κυβερνοασφάλειας !
Ηθικό δίδαγμα της ιστορίας: ελέγξτε την ασφάλειά σας. Διεξαγωγή τακτικών ελέγχων. Σεβαστείτε την αρχή του ελάχιστου προνομίου για τις πολιτικές ασφαλείας.
( Μπορείτε να δείτε την πλήρη νομική έκθεση).
Πηγή: www.habr.com