από SeerLight
Η κατασκευή οποιασδήποτε υπηρεσίας περιλαμβάνει απαραιτήτως συνεχή εργασία για την ασφάλεια. Η ασφάλεια είναι μια συνεχής διαδικασία που περιλαμβάνει συνεχή ανάλυση και βελτίωση της ασφάλειας των προϊόντων, παρακολούθηση ειδήσεων σχετικά με τρωτά σημεία και πολλά άλλα. Συμπεριλαμβανομένων των ελέγχων. Οι έλεγχοι πραγματοποιούνται τόσο εσωτερικά όσο και από εξωτερικούς εμπειρογνώμονες, οι οποίοι μπορούν να βοηθήσουν ριζικά στην ασφάλεια, επειδή δεν είναι βυθισμένοι στο έργο και έχουν ανοιχτό μυαλό.
Το άρθρο αφορά αυτήν την πιο ξεκάθαρη άποψη εξωτερικών ειδικών που βοήθησαν την ομάδα του Mail.ru Cloud Solutions (MCS) να δοκιμάσει την υπηρεσία cloud και σχετικά με το τι βρήκαν. Ως «εξωτερική δύναμη», η MCS επέλεξε την εταιρεία Digital Security, γνωστή για την υψηλή εξειδίκευσή της στους κύκλους ασφάλειας πληροφοριών. Και σε αυτό το άρθρο θα αναλύσουμε μερικά ενδιαφέροντα τρωτά σημεία που εντοπίστηκαν ως μέρος ενός εξωτερικού ελέγχου - έτσι ώστε να αποφύγετε την ίδια γκανιότα όταν δημιουργείτε τη δική σας υπηρεσία cloud.
Описание продукта
είναι μια πλατφόρμα για τη δημιουργία εικονικής υποδομής στο cloud. Περιλαμβάνει IaaS, PaaS και μια αγορά έτοιμων εικόνων εφαρμογών για προγραμματιστές. Λαμβάνοντας υπόψη την αρχιτεκτονική MCS, ήταν απαραίτητο να ελεγχθεί η ασφάλεια του προϊόντος στους ακόλουθους τομείς:
- προστασία της υποδομής του περιβάλλοντος εικονικοποίησης: hypervisors, δρομολόγηση, τείχη προστασίας.
- προστασία της εικονικής υποδομής των πελατών: απομόνωση μεταξύ τους, συμπεριλαμβανομένου δικτύου, ιδιωτικών δικτύων στο SDN.
- Το OpenStack και τα ανοιχτά του στοιχεία.
- S3 δικής μας σχεδίασης.
- IAM: έργα πολλαπλών ενοικιαστών με πρότυπο.
- Vision (computer vision): API και τρωτά σημεία κατά την εργασία με εικόνες.
- διεπαφή ιστού και κλασικές επιθέσεις ιστού.
- ευπάθειες των στοιχείων PaaS.
- API όλων των στοιχείων.
Ίσως αυτό είναι το μόνο που είναι απαραίτητο για την περαιτέρω ιστορία.
Τι είδους εργασίες έγιναν και γιατί χρειάστηκαν;
Ο έλεγχος ασφαλείας στοχεύει στον εντοπισμό τρωτών σημείων και σφαλμάτων διαμόρφωσης που θα μπορούσαν να οδηγήσουν σε διαρροή προσωπικών δεδομένων, τροποποίηση ευαίσθητων πληροφοριών ή διακοπή της διαθεσιμότητας της υπηρεσίας.
Κατά τη διάρκεια της εργασίας, η οποία διαρκεί κατά μέσο όρο 1-2 μήνες, οι ελεγκτές επαναλαμβάνουν τις ενέργειες πιθανών εισβολέων και αναζητούν τρωτά σημεία στα τμήματα του πελάτη και του διακομιστή της επιλεγμένης υπηρεσίας. Στο πλαίσιο του ελέγχου της πλατφόρμας cloud MCS, εντοπίστηκαν οι ακόλουθοι στόχοι:
- Ανάλυση ελέγχου ταυτότητας στην υπηρεσία. Τα τρωτά σημεία σε αυτό το στοιχείο θα βοηθούσαν στην άμεση είσοδο στους λογαριασμούς άλλων ατόμων.
- Μελέτη του προτύπου και ελέγχου πρόσβασης μεταξύ διαφορετικών λογαριασμών. Για έναν εισβολέα, η δυνατότητα να αποκτήσει πρόσβαση στην εικονική μηχανή κάποιου άλλου είναι ένας επιθυμητός στόχος.
- Ευπάθειες από την πλευρά του πελάτη. XSS/CSRF/CRLF/κ.λπ. Είναι δυνατή η επίθεση σε άλλους χρήστες μέσω κακόβουλων συνδέσμων;
- Ευπάθειες από την πλευρά του διακομιστή: RCE και όλα τα είδη εγχύσεων (SQL/XXE/SSRF και ούτω καθεξής). Τα τρωτά σημεία του διακομιστή είναι γενικά πιο δύσκολο να βρεθούν, αλλά οδηγούν σε συμβιβασμό πολλών χρηστών ταυτόχρονα.
- Ανάλυση της απομόνωσης τμήματος χρήστη σε επίπεδο δικτύου. Για έναν εισβολέα, η έλλειψη απομόνωσης αυξάνει σημαντικά την επιφάνεια επίθεσης εναντίον άλλων χρηστών.
- Επιχειρησιακή λογική ανάλυση. Είναι δυνατόν να εξαπατήσετε επιχειρήσεις και να δημιουργήσετε εικονικές μηχανές δωρεάν;
Σε αυτό το έργο, η εργασία πραγματοποιήθηκε σύμφωνα με το μοντέλο "Gray-box": οι ελεγκτές αλληλεπιδρούσαν με την υπηρεσία με τα προνόμια των απλών χρηστών, αλλά διέθεταν εν μέρει τον πηγαίο κώδικα του API και είχαν την ευκαιρία να διευκρινίσουν λεπτομέρειες με τους προγραμματιστές. Αυτό είναι συνήθως το πιο βολικό και ταυτόχρονα αρκετά ρεαλιστικό μοντέλο εργασίας: οι εσωτερικές πληροφορίες μπορούν ακόμα να συλλεχθούν από έναν εισβολέα, είναι μόνο θέμα χρόνου.
Βρέθηκαν τρωτά σημεία
Προτού ο ελεγκτής αρχίσει να στέλνει διάφορα ωφέλιμα φορτία (το ωφέλιμο φορτίο που χρησιμοποιείται για την εκτέλεση της επίθεσης) σε τυχαία μέρη, είναι απαραίτητο να κατανοήσει πώς λειτουργούν τα πράγματα και ποια λειτουργικότητα παρέχεται. Μπορεί να φαίνεται ότι αυτή είναι μια άχρηστη άσκηση, επειδή στα περισσότερα από τα μέρη που μελετήθηκαν δεν θα υπάρχουν τρωτά σημεία. Αλλά μόνο η κατανόηση της δομής της εφαρμογής και της λογικής της λειτουργίας της θα καταστήσει δυνατή την εύρεση των πιο περίπλοκων φορέων επίθεσης.
Είναι σημαντικό να βρείτε μέρη που φαίνονται ύποπτα ή είναι πολύ διαφορετικά από άλλα κατά κάποιο τρόπο. Και η πρώτη επικίνδυνη ευπάθεια βρέθηκε με αυτόν τον τρόπο.
IDOR
Οι ευπάθειες IDOR (Insecure Direct Object Reference) είναι μια από τις πιο κοινές ευπάθειες στην επιχειρηματική λογική, η οποία επιτρέπει στο ένα ή στο άλλο να αποκτήσει πρόσβαση σε αντικείμενα στα οποία η πρόσβαση στην πραγματικότητα δεν επιτρέπεται. Τα τρωτά σημεία IDOR δημιουργούν τη δυνατότητα απόκτησης πληροφοριών σχετικά με έναν χρήστη διαφορετικού βαθμού κρισιμότητας.
Μία από τις επιλογές IDOR είναι η εκτέλεση ενεργειών με αντικείμενα συστήματος (χρήστες, τραπεζικούς λογαριασμούς, είδη στο καλάθι αγορών) χειραγωγώντας τα αναγνωριστικά πρόσβασης σε αυτά τα αντικείμενα. Αυτό οδηγεί στις πιο απρόβλεπτες συνέπειες. Για παράδειγμα, η δυνατότητα αντικατάστασης του λογαριασμού του αποστολέα κεφαλαίων, μέσω του οποίου μπορείτε να τα κλέψετε από άλλους χρήστες.
Στην περίπτωση του MCS, οι ελεγκτές μόλις ανακάλυψαν μια ευπάθεια IDOR που σχετίζεται με μη ασφαλή αναγνωριστικά. Στον προσωπικό λογαριασμό του χρήστη, χρησιμοποιήθηκαν αναγνωριστικά UUID για την πρόσβαση σε αντικείμενα, τα οποία φαινόταν, όπως λένε οι ειδικοί ασφαλείας, εντυπωσιακά ανασφαλή (δηλαδή προστατευμένα από επιθέσεις ωμής βίας). Αλλά για ορισμένες οντότητες, ανακαλύφθηκε ότι χρησιμοποιούνται κανονικοί προβλέψιμοι αριθμοί για τη λήψη πληροφοριών σχετικά με τους χρήστες της εφαρμογής. Νομίζω ότι μπορείτε να μαντέψετε ότι ήταν δυνατό να αλλάξετε το αναγνωριστικό χρήστη κατά ένα, να στείλετε ξανά το αίτημα και έτσι να λάβετε πληροφορίες παρακάμπτοντας το ACL (λίστα ελέγχου πρόσβασης, κανόνες πρόσβασης δεδομένων για διεργασίες και χρήστες).
Παραχάραξη αιτημάτων από την πλευρά του διακομιστή (SSRF)
Το καλό με τα προϊόντα OpenSource είναι ότι διαθέτουν έναν τεράστιο αριθμό φόρουμ με λεπτομερείς τεχνικές περιγραφές των προβλημάτων που προκύπτουν και, αν είστε τυχεροί, περιγραφή της λύσης. Αλλά αυτό το νόμισμα έχει μια άλλη όψη: γνωστά τρωτά σημεία περιγράφονται επίσης λεπτομερώς. Για παράδειγμα, υπάρχουν υπέροχες περιγραφές τρωτών σημείων στο φόρουμ του OpenStack и , που για κάποιο λόγο κανείς δεν βιάζεται να διορθώσει.
Μια κοινή λειτουργία των εφαρμογών είναι η δυνατότητα του χρήστη να στέλνει έναν σύνδεσμο στον διακομιστή, στον οποίο ο διακομιστής κάνει κλικ (για παράδειγμα, για λήψη μιας εικόνας από μια καθορισμένη πηγή). Εάν τα εργαλεία ασφαλείας δεν φιλτράρουν τους ίδιους τους συνδέσμους ή τις απαντήσεις που επιστρέφονται από τον διακομιστή στους χρήστες, αυτή η λειτουργία μπορεί εύκολα να χρησιμοποιηθεί από τους εισβολείς.
Τα τρωτά σημεία SSRF μπορούν να προωθήσουν σημαντικά την ανάπτυξη μιας επίθεσης. Ένας εισβολέας μπορεί να πάρει:
- περιορισμένη πρόσβαση στο τοπικό δίκτυο που δέχεται επίθεση, για παράδειγμα, μόνο μέσω συγκεκριμένων τμημάτων δικτύου και χρησιμοποιώντας ένα συγκεκριμένο πρωτόκολλο·
- πλήρης πρόσβαση στο τοπικό δίκτυο, εάν είναι δυνατή η υποβάθμιση από το επίπεδο εφαρμογής στο επίπεδο μεταφοράς και, ως εκ τούτου, πλήρης διαχείριση φορτίου σε επίπεδο εφαρμογής.
- πρόσβαση για ανάγνωση τοπικών αρχείων στο διακομιστή (εάν υποστηρίζεται το σχήμα file:///).
- και πολλά άλλα.
Μια ευπάθεια SSRF είναι γνωστή εδώ και καιρό στο OpenStack, η οποία είναι «τυφλή» στη φύση: όταν επικοινωνείτε με τον διακομιστή, δεν λαμβάνετε απάντηση από αυτόν, αλλά λαμβάνετε διαφορετικούς τύπους σφαλμάτων/καθυστερήσεων, ανάλογα με το αποτέλεσμα του αιτήματος . Με βάση αυτό, μπορείτε να πραγματοποιήσετε σάρωση θυρών σε κεντρικούς υπολογιστές στο εσωτερικό δίκτυο, με όλες τις επακόλουθες συνέπειες που δεν πρέπει να υποτιμηθούν. Για παράδειγμα, ένα προϊόν μπορεί να έχει ένα back-office API που είναι προσβάσιμο μόνο από το εταιρικό δίκτυο. Με την τεκμηρίωση (μην ξεχνάτε τα άτομα με πληροφορίες), ένας εισβολέας μπορεί να χρησιμοποιήσει SSRF για πρόσβαση σε εσωτερικές μεθόδους. Για παράδειγμα, εάν μπορέσατε με κάποιο τρόπο να αποκτήσετε μια κατά προσέγγιση λίστα με χρήσιμες διευθύνσεις URL, τότε χρησιμοποιώντας το SSRF μπορείτε να τις διαβάσετε και να εκτελέσετε ένα αίτημα - σχετικά, να μεταφέρετε χρήματα από λογαριασμό σε λογαριασμό ή να αλλάξετε όρια.
Δεν είναι η πρώτη φορά που ανακαλύπτεται μια ευπάθεια SSRF στο OpenStack. Στο παρελθόν, ήταν δυνατή η λήψη εικόνων VM ISO από έναν άμεσο σύνδεσμο, κάτι που είχε επίσης παρόμοιες συνέπειες. Αυτή η δυνατότητα έχει πλέον αφαιρεθεί από το OpenStack. Προφανώς, η κοινότητα θεώρησε αυτή την απλούστερη και πιο αξιόπιστη λύση στο πρόβλημα.
Και σε δημόσια διαθέσιμη αναφορά από την υπηρεσία HackerOne (h1), η εκμετάλλευση ενός μη τυφλού SSRF με δυνατότητα ανάγνωσης μεταδεδομένων παρουσίας οδηγεί σε πρόσβαση Root σε ολόκληρη την υποδομή Shopify.
Στο MCS, τα τρωτά σημεία SSRF ανακαλύφθηκαν σε δύο σημεία με παρόμοια λειτουργικότητα, αλλά ήταν σχεδόν αδύνατο να εκμεταλλευτούν λόγω τείχους προστασίας και άλλων προστασιών. Με τον ένα ή τον άλλο τρόπο, η ομάδα MCS διόρθωσε αυτό το πρόβλημα ούτως ή άλλως, χωρίς να περιμένει την κοινότητα.
XSS αντί να φορτώνει κελύφη
Παρά τις εκατοντάδες μελέτες που γράφτηκαν, χρόνο με τον χρόνο η επίθεση XSS (cross-site scripting) εξακολουθεί να είναι η μεγαλύτερη ευπάθεια ιστού (ή ;).
Οι μεταφορτώσεις αρχείων είναι ένα αγαπημένο μέρος για κάθε ερευνητή ασφάλειας. Συχνά αποδεικνύεται ότι μπορείτε να φορτώσετε ένα αυθαίρετο σενάριο (asp/jsp/php) και να εκτελέσετε εντολές λειτουργικού συστήματος, με την ορολογία των pentesters - "load shell". Αλλά η δημοτικότητα τέτοιων τρωτών σημείων λειτουργεί και προς τις δύο κατευθύνσεις: απομνημονεύονται και αναπτύσσονται διορθωτικά μέτρα εναντίον τους, έτσι ώστε πρόσφατα η πιθανότητα «φόρτωσης ενός κελύφους» τείνει στο μηδέν.
Η επιθετική ομάδα (που εκπροσωπήθηκε από την Digital Security) ήταν τυχερή. Εντάξει, στο MCS στην πλευρά του διακομιστή ελέγχθηκαν τα περιεχόμενα των ληφθέντων αρχείων, επιτρέπονταν μόνο εικόνες. Αλλά το SVG είναι επίσης μια εικόνα. Πώς μπορούν οι εικόνες SVG να είναι επικίνδυνες; Επειδή μπορείτε να ενσωματώσετε αποσπάσματα JavaScript σε αυτά!
Αποδείχθηκε ότι τα ληφθέντα αρχεία είναι διαθέσιμα σε όλους τους χρήστες της υπηρεσίας MCS, πράγμα που σημαίνει ότι είναι δυνατή η επίθεση σε άλλους χρήστες του cloud, δηλαδή στους διαχειριστές.
Ένα παράδειγμα επίθεσης XSS σε μια φόρμα σύνδεσης ηλεκτρονικού ψαρέματος
Παραδείγματα εκμετάλλευσης επιθέσεων XSS:
- Γιατί να προσπαθήσετε να κλέψετε μια περίοδο λειτουργίας (ειδικά αφού τώρα τα cookie Μόνο HTTP είναι παντού, προστατευμένα από κλοπή χρησιμοποιώντας σενάρια js), εάν το φορτωμένο σενάριο μπορεί να έχει άμεση πρόσβαση στο API πόρων; Σε αυτήν την περίπτωση, το ωφέλιμο φορτίο μπορεί να χρησιμοποιήσει αιτήματα XHR για να αλλάξει τη διαμόρφωση του διακομιστή, για παράδειγμα, να προσθέσει το δημόσιο κλειδί SSH του εισβολέα και να αποκτήσει πρόσβαση SSH στον διακομιστή.
- Εάν η πολιτική CSP (πολιτική προστασίας περιεχομένου) απαγορεύει την εισαγωγή JavaScript, ένας εισβολέας μπορεί να τα βγάλει πέρα χωρίς αυτήν. Χρησιμοποιώντας καθαρό HTML, δημιουργήστε μια ψεύτικη φόρμα σύνδεσης για τον ιστότοπο και κλέψτε τον κωδικό πρόσβασης του διαχειριστή μέσω αυτού του προηγμένου ψαρέματος: η σελίδα phishing για τον χρήστη καταλήγει στην ίδια διεύθυνση URL και είναι πιο δύσκολο για τον χρήστη να την εντοπίσει.
- Τέλος, ο επιτιθέμενος μπορεί να κανονίσει — ορίστε Cookies μεγαλύτερα από 4 KB. Ο χρήστης χρειάζεται να ανοίξει τον σύνδεσμο μόνο μία φορά και ολόκληρος ο ιστότοπος γίνεται απρόσιτος έως ότου ο χρήστης σκεφτεί να καθαρίσει ειδικά το πρόγραμμα περιήγησης: στη συντριπτική πλειονότητα των περιπτώσεων, ο διακομιστής ιστού θα αρνηθεί να δεχτεί έναν τέτοιο πελάτη.
Ας δούμε ένα παράδειγμα άλλου εντοπισμένου XSS, αυτή τη φορά με ένα πιο έξυπνο exploit. Η υπηρεσία MCS σάς επιτρέπει να συνδυάσετε τις ρυθμίσεις του τείχους προστασίας σε ομάδες. Το όνομα της ομάδας ήταν το σημείο όπου εντοπίστηκε το XSS. Η ιδιαιτερότητά του ήταν ότι το διάνυσμα δεν ενεργοποιήθηκε αμέσως, όχι κατά την προβολή της λίστας κανόνων, αλλά κατά τη διαγραφή μιας ομάδας:
Δηλαδή, το σενάριο αποδείχθηκε το εξής: ένας εισβολέας δημιουργεί έναν κανόνα τείχους προστασίας με "φόρτωση" στο όνομα, ο διαχειριστής το παρατηρεί μετά από λίγο και ξεκινά τη διαδικασία διαγραφής. Και εδώ λειτουργεί το κακόβουλο JS.
Για τους προγραμματιστές MCS, για προστασία από το XSS σε εικόνες SVG που έχουν ληφθεί (εάν δεν μπορούν να εγκαταλειφθούν), η ομάδα Ψηφιακής Ασφάλειας συνέστησε:
- Τοποθετήστε τα αρχεία που ανεβάζουν οι χρήστες σε έναν ξεχωριστό τομέα που δεν έχει καμία σχέση με τα «cookies». Το σενάριο θα εκτελεστεί στο πλαίσιο διαφορετικού τομέα και δεν θα αποτελεί απειλή για το MCS.
- Στην απόκριση HTTP του διακομιστή, στείλτε την κεφαλίδα "Content-disposition: attachment". Στη συνέχεια, τα αρχεία θα ληφθούν από το πρόγραμμα περιήγησης και δεν θα εκτελεστούν.
Επιπλέον, υπάρχουν πλέον πολλοί τρόποι διαθέσιμοι στους προγραμματιστές για τον μετριασμό των κινδύνων εκμετάλλευσης του XSS:
- Χρησιμοποιώντας τη σημαία "Μόνο HTTP", μπορείτε να κάνετε τις κεφαλίδες "Cookies" περιόδου σύνδεσης μη προσβάσιμες σε κακόβουλο JavaScript.
- θα κάνει πολύ πιο δύσκολο για έναν εισβολέα να εκμεταλλευτεί το XSS.
- Οι σύγχρονες μηχανές προτύπων, όπως το Angular ή το React, καθαρίζουν αυτόματα τα δεδομένα χρήστη πριν τα εξάγουν στο πρόγραμμα περιήγησης του χρήστη.
Ευπάθειες ελέγχου ταυτότητας δύο παραγόντων
Για τη βελτίωση της ασφάλειας του λογαριασμού, συνιστάται πάντα στους χρήστες να ενεργοποιούν το 2FA (έλεγχος ταυτότητας δύο παραγόντων). Πράγματι, αυτός είναι ένας αποτελεσματικός τρόπος για να αποτρέψετε έναν εισβολέα από το να αποκτήσει πρόσβαση σε μια υπηρεσία, εάν τα διαπιστευτήρια του χρήστη έχουν παραβιαστεί.
Αλλά η χρήση ενός δεύτερου παράγοντα ελέγχου ταυτότητας εγγυάται πάντα την ασφάλεια του λογαριασμού; Υπάρχουν τα ακόλουθα ζητήματα ασφάλειας στην εφαρμογή του 2FA:
- Αναζήτηση ωμής βίας του κωδικού OTP (κωδικοί μίας χρήσης). Παρά την απλότητα λειτουργίας, λάθη όπως η έλλειψη προστασίας έναντι της ωμής βίας OTP συναντώνται επίσης από μεγάλες εταιρείες: , .
- Αδύναμος αλγόριθμος παραγωγής, για παράδειγμα η δυνατότητα πρόβλεψης του επόμενου κώδικα.
- Λογικά σφάλματα, όπως η δυνατότητα να ζητήσετε το OTP κάποιου άλλου στο τηλέφωνό σας, όπως αυτό από το Shopify.
Στην περίπτωση του MCS, το 2FA υλοποιείται βάσει του Google Authenticator και . Το ίδιο το πρωτόκολλο έχει ήδη δοκιμαστεί σε χρόνο, αλλά αξίζει να ελεγχθεί η εφαρμογή της επαλήθευσης κώδικα από την πλευρά της εφαρμογής.
Το MCS 2FA χρησιμοποιείται σε πολλά μέρη:
- Κατά τον έλεγχο ταυτότητας του χρήστη. Υπάρχει προστασία κατά της ωμής βίας: ο χρήστης έχει μόνο μερικές προσπάθειες να εισαγάγει έναν κωδικό πρόσβασης μίας χρήσης και, στη συνέχεια, η είσοδος μπλοκάρεται για λίγο. Αυτό αποκλείει τη δυνατότητα επιλογής ωμής βίας του OTP.
- Κατά τη δημιουργία εφεδρικών κωδικών εκτός σύνδεσης για την εκτέλεση 2FA, καθώς και την απενεργοποίησή του. Εδώ, δεν εφαρμόστηκε προστασία ωμής βίας, κάτι που επέτρεψε, εάν είχατε κωδικό πρόσβασης για τον λογαριασμό και μια ενεργή περίοδο λειτουργίας, να δημιουργήσετε εφεδρικούς κωδικούς ή να απενεργοποιήσετε πλήρως το 2FA.
Λαμβάνοντας υπόψη ότι οι εφεδρικοί κωδικοί βρίσκονταν στο ίδιο εύρος τιμών συμβολοσειράς με αυτούς που δημιουργήθηκαν από την εφαρμογή OTP, η πιθανότητα εύρεσης του κώδικα σε σύντομο χρονικό διάστημα ήταν πολύ μεγαλύτερη.
Η διαδικασία επιλογής ενός OTP για απενεργοποίηση του 2FA χρησιμοποιώντας το εργαλείο "Burp: Intruder".
Αποτέλεσμα
Συνολικά, το MCS φαίνεται να είναι ασφαλές ως προϊόν. Κατά τη διάρκεια του ελέγχου, η ομάδα διεκπεραίωσης δεν μπόρεσε να αποκτήσει πρόσβαση στα εικονικά μηχανήματα πελατών και στα δεδομένα τους και τα τρωτά σημεία που εντοπίστηκαν διορθώθηκαν γρήγορα από την ομάδα MCS.
Αλλά εδώ είναι σημαντικό να σημειωθεί ότι η ασφάλεια είναι μια συνεχής δουλειά. Οι υπηρεσίες δεν είναι στατικές, εξελίσσονται συνεχώς. Και είναι αδύνατο να αναπτυχθεί ένα προϊόν εντελώς χωρίς τρωτά σημεία. Μπορείτε όμως να τα βρείτε εγκαίρως και να ελαχιστοποιήσετε την πιθανότητα επανεμφάνισής τους.
Τώρα όλες οι αναφερόμενες ευπάθειες στο MCS έχουν ήδη επιδιορθωθεί. Και προκειμένου να περιοριστεί ο αριθμός των νέων στο ελάχιστο και να μειωθεί η διάρκεια ζωής τους, η ομάδα της πλατφόρμας συνεχίζει να κάνει τα εξής:
- διενεργούν τακτικά ελέγχους από εξωτερικές εταιρείες·
- υποστήριξη και ανάπτυξη συμμετοχής;
- ασχολούνται με την ασφάλεια. 🙂
Πηγή: www.habr.com