Ως μέρος των επαγγελματικών τους δραστηριοτήτων, οι προγραμματιστές, οι διεισδυτές και οι επαγγελματίες ασφάλειας πρέπει να αντιμετωπίσουν διαδικασίες όπως η Διαχείριση ευπάθειας (VM), η (Ασφαλής) SDLC.
Κάτω από αυτές τις φράσεις υπάρχουν διάφορα σύνολα πρακτικών και εργαλείων που χρησιμοποιούνται που είναι αλληλένδετα, αν και οι χρήστες τους διαφέρουν.
Η τεχνολογική πρόοδος δεν έχει φτάσει ακόμη στο σημείο όπου ένα εργαλείο μπορεί να αντικαταστήσει ένα άτομο για την ανάλυση της ασφάλειας της υποδομής και του λογισμικού.
Είναι ενδιαφέρον να κατανοήσουμε γιατί συμβαίνει αυτό και ποια προβλήματα πρέπει να αντιμετωπίσει κανείς.
Διαδικασίες
Η διαδικασία Διαχείρισης ευπάθειας έχει σχεδιαστεί για να παρακολουθεί συνεχώς την ασφάλεια της υποδομής και τη διαχείριση ενημερώσεων κώδικα.
Η διαδικασία Secure SDLC ("κύκλος ασφαλούς ανάπτυξης") έχει σχεδιαστεί για να διατηρεί την ασφάλεια της εφαρμογής κατά την ανάπτυξη και τη λειτουργία.
Ένα παρόμοιο μέρος αυτών των διαδικασιών είναι η διαδικασία αξιολόγησης ευπάθειας - αξιολόγηση τρωτότητας, σάρωση ευπάθειας.
Η κύρια διαφορά μεταξύ της σάρωσης εντός VM και SDLC είναι ότι στην πρώτη περίπτωση, ο στόχος είναι να βρεθούν γνωστά τρωτά σημεία σε λογισμικό τρίτων κατασκευαστών ή σε μια διαμόρφωση. Για παράδειγμα, μια παλιά έκδοση των Windows ή η προεπιλεγμένη συμβολοσειρά κοινότητας για το SNMP.
Στη δεύτερη περίπτωση, ο στόχος είναι να εντοπιστούν τρωτά σημεία όχι μόνο σε στοιχεία τρίτων (εξαρτήσεις), αλλά κυρίως στον κώδικα του νέου προϊόντος.
Αυτό οδηγεί σε διαφορές στα εργαλεία και τις προσεγγίσεις. Κατά τη γνώμη μου, το έργο της εύρεσης νέων τρωτών σημείων σε μια εφαρμογή είναι πολύ πιο ενδιαφέρον, αφού δεν αφορά το δακτυλικό αποτύπωμα έκδοσης, τη συλλογή banner, την ωμή δύναμη κωδικού πρόσβασης κ.λπ.
Η υψηλής ποιότητας αυτοματοποιημένη σάρωση των τρωτών σημείων της εφαρμογής απαιτεί αλγόριθμους που λαμβάνουν υπόψη τη σημασιολογία της εφαρμογής, τον σκοπό της και συγκεκριμένες απειλές.
Ο σαρωτής υποδομής μπορεί συχνά να αντικατασταθεί με χρονόμετρο, όπως το . Το θέμα είναι ότι καθαρά στατιστικά, μπορείς να θεωρείς ευάλωτη την υποδομή σου αν δεν την έχεις ενημερώσει ας πούμε για ένα μήνα.
Εργαλεία
Η σάρωση, καθώς και η ανάλυση ασφαλείας, μπορούν να εκτελεστούν ως μαύρο κουτί ή λευκό κουτί.
Black Box
Με τη σάρωση blackbox, το εργαλείο πρέπει να μπορεί να λειτουργεί με την υπηρεσία μέσω των ίδιων διεπαφών μέσω των οποίων οι χρήστες εργάζονται με αυτό.
Οι σαρωτές υποδομής (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose κ.λπ.) αναζητούν ανοιχτές θύρες δικτύου, συλλέγουν "banners", εντοπίζουν εγκατεστημένες εκδόσεις λογισμικού και αναζητούν τη βάση γνώσεων τους για πληροφορίες σχετικά με τρωτά σημεία σε αυτές τις εκδόσεις. Προσπαθούν επίσης να εντοπίσουν σφάλματα διαμόρφωσης, όπως προεπιλεγμένους κωδικούς πρόσβασης ή δημόσια πρόσβαση σε δεδομένα, αδύναμους κρυπτογράφησης SSL κ.λπ.
Οι σαρωτές διαδικτυακών εφαρμογών (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP κ.λπ.) μπορούν επίσης να ανιχνεύσουν γνωστά στοιχεία και τις εκδόσεις τους (π.χ. CMS, πλαίσια, βιβλιοθήκες JS). Τα κύρια βήματα ανίχνευσης είναι η ανίχνευση και η ασάφεια.
Κατά τη διάρκεια της ανίχνευσης, ο ανιχνευτής συλλέγει πληροφορίες σχετικά με τις υπάρχουσες διεπαφές εφαρμογών και τις παραμέτρους HTTP. Κατά τη διάρκεια του fuzzing, όλες οι ανιχνευόμενες παράμετροι αντικαθίστανται με μεταλλαγμένα ή δημιουργημένα δεδομένα προκειμένου να προκληθεί σφάλμα και να εντοπιστεί μια ευπάθεια.
Τέτοιοι σαρωτές εφαρμογών ανήκουν στις κατηγορίες DAST και IAST - αντίστοιχα Dynamic και Interactive Application Security Testing.
Ασπρο κουτί
Με τη σάρωση λευκού κουτιού, υπάρχουν περισσότερες διαφορές.
Ως μέρος της διαδικασίας VM, οι σαρωτές (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, κ.λπ.) έχουν συχνά πρόσβαση στα συστήματα εκτελώντας μια επαληθευμένη σάρωση. Έτσι, ο σαρωτής μπορεί να κατεβάσει τις εγκατεστημένες εκδόσεις πακέτων και τις παραμέτρους διαμόρφωσης απευθείας από το σύστημα, χωρίς να τις μαντέψει από banner υπηρεσιών δικτύου.
Η σάρωση είναι πιο ακριβής και πλήρης.
Αν μιλάμε για σάρωση whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs κ.λπ.) εφαρμογών, τότε συνήθως μιλάμε για ανάλυση στατικού κώδικα και τη χρήση των αντίστοιχων εργαλείων κλάσης SAST - Static Application Security Testing.
Προβλήματα
Υπάρχουν πολλά προβλήματα με τη σάρωση! Πρέπει να αντιμετωπίσω τα περισσότερα από αυτά προσωπικά ως μέρος της παροχής μιας υπηρεσίας για διαδικασίες σάρωσης κτιρίων και ασφαλούς ανάπτυξης, καθώς και κατά τη διεξαγωγή εργασιών ανάλυσης ασφάλειας.
Θα ξεχωρίσω 3 βασικές ομάδες προβλημάτων, που επιβεβαιώνονται και από συνομιλίες με μηχανικούς και επικεφαλής υπηρεσιών ασφάλειας πληροφοριών σε διάφορες εταιρείες.
Ζητήματα σάρωσης εφαρμογών Ιστού
- Δυσκολία υλοποίησης. Οι σαρωτές πρέπει να αναπτυχθούν, να διαμορφωθούν, να προσαρμοστούν για κάθε εφαρμογή, να εκχωρηθεί ένα δοκιμαστικό περιβάλλον για σαρώσεις και να εφαρμοστούν στη διαδικασία CI/CD προκειμένου να είναι αποτελεσματικοί. Διαφορετικά, θα είναι μια άχρηστη επίσημη διαδικασία, που θα εκδίδονται μόνο ψευδώς θετικά
- Διάρκεια σάρωσης. Οι σαρωτές, ακόμη και το 2019, κάνουν κακή δουλειά στην κατάργηση διπλότυπων διεπαφών και μπορούν να σαρώσουν χίλιες σελίδες με 10 παραμέτρους η καθεμία για μέρες, θεωρώντας τις διαφορετικές, αν και για αυτές ευθύνεται ο ίδιος κώδικας. Ταυτόχρονα, η απόφαση για ανάπτυξη στην παραγωγή εντός του κύκλου ανάπτυξης πρέπει να ληφθεί γρήγορα.
- Κακές συστάσεις. Οι σαρωτές δίνουν αρκετά γενικές συστάσεις και δεν είναι πάντα δυνατό για έναν προγραμματιστή να κατανοήσει γρήγορα από αυτούς πώς να μειώσει το επίπεδο κινδύνου και το πιο σημαντικό, αν πρέπει να γίνει τώρα ή δεν είναι ακόμα τρομακτικό
- Καταστροφικές επιπτώσεις στην εφαρμογή. Οι σαρωτές μπορούν εύκολα να εκτελέσουν μια επίθεση DoS σε μια εφαρμογή και μπορούν επίσης να δημιουργήσουν μεγάλο αριθμό οντοτήτων ή να αλλάξουν υπάρχουσες (για παράδειγμα, να δημιουργήσουν δεκάδες χιλιάδες σχόλια σε ένα ιστολόγιο), επομένως δεν πρέπει να εκτελείτε αλόγιστα μια σάρωση σε προϊόν.
- Κακή ποιότητα ανίχνευσης ευπάθειας. Οι σαρωτές χρησιμοποιούν συνήθως μια σταθερή σειρά ωφέλιμων φορτίων και μπορούν εύκολα να χάσουν μια ευπάθεια που δεν ταιριάζει στη γνωστή συμπεριφορά εφαρμογής τους.
- Ο σαρωτής δεν κατανοεί τις λειτουργίες της εφαρμογής. Οι ίδιοι οι σαρωτές δεν γνωρίζουν τι είναι η "τράπεζα Διαδικτύου", "πληρωμή", "σχόλιο". Για αυτούς, υπάρχουν μόνο σύνδεσμοι και παράμετροι, επομένως ένα τεράστιο στρώμα πιθανών ευπαθειών επιχειρηματικής λογικής παραμένει εντελώς ακάλυπτο, δεν θα μαντέψουν ότι θα κάνουν διπλή διαγραφή, δεν θα κοιτάξουν τα δεδομένα άλλων ατόμων με ταυτότητα ή θα ολοκληρώσουν το υπόλοιπο μέσω στρογγυλοποίησης
- Παρανόηση της σημασιολογίας της σελίδας από τον σαρωτή. Οι σαρωτές δεν μπορούν να διαβάσουν τις Συνήθεις Ερωτήσεις, δεν μπορούν να αναγνωρίσουν τα captchas, δεν θα μαντέψουν μόνοι τους πώς να εγγραφούν και στη συνέχεια να επανασυνδεθούν, ότι δεν μπορείτε να κάνετε κλικ στο "Αποσύνδεση" και πώς να υπογράψετε αιτήματα όταν αλλάζετε τιμές παραμέτρων. Ως αποτέλεσμα, το μεγαλύτερο μέρος της εφαρμογής μπορεί να παραμείνει καθόλου σαρωμένο.
Ζητήματα σάρωσης πηγαίου κώδικα
- Ψευδοθετικά. Η στατική ανάλυση είναι μια πολύπλοκη εργασία που περιλαμβάνει πολλούς συμβιβασμούς. Συχνά πρέπει να θυσιάσετε την ακρίβεια και ακόμη και οι ακριβοί εταιρικοί σαρωτές δίνουν έναν τεράστιο αριθμό ψευδών θετικών στοιχείων.
- Δυσκολία υλοποίησης. Για να αυξηθεί η ακρίβεια και η πληρότητα της στατικής ανάλυσης, είναι απαραίτητο να βελτιωθούν οι κανόνες σάρωσης και η σύνταξη αυτών των κανόνων μπορεί να είναι πολύ χρονοβόρα. Μερικές φορές είναι πιο εύκολο να βρείτε όλα τα σημεία στον κώδικα με κάποιο είδος σφάλματος και να τα διορθώσετε παρά να γράψετε έναν κανόνα για τον εντοπισμό τέτοιων περιπτώσεων.
- Έλλειψη υποστήριξης εξάρτησης. Τα μεγάλα έργα εξαρτώνται από μεγάλο αριθμό βιβλιοθηκών και πλαισίων που επεκτείνουν τις δυνατότητες της γλώσσας προγραμματισμού. Εάν δεν υπάρχουν πληροφορίες για επικίνδυνα μέρη ("βόθρες") σε αυτά τα πλαίσια στη βάση γνώσεων του σαρωτή, αυτό θα γίνει τυφλό σημείο και ο σαρωτής απλά δεν θα καταλάβει καν τον κώδικα.
- Διάρκεια σάρωσης. Η εύρεση τρωτών σημείων στον κώδικα είναι δύσκολη υπόθεση και από πλευράς αλγορίθμων. Επομένως, η διαδικασία μπορεί κάλλιστα να καθυστερήσει και να απαιτήσει σημαντικούς υπολογιστικούς πόρους.
- Χαμηλή κάλυψη. Παρά την κατανάλωση πόρων και τη διάρκεια σάρωσης, οι προγραμματιστές εργαλείων SAST εξακολουθούν να πρέπει να καταφεύγουν σε συμβιβασμούς και να αναλύουν όχι όλες τις καταστάσεις στις οποίες μπορεί να βρίσκεται ένα πρόγραμμα.
- Εύρεση αναπαραγωγιμότητας. Η κατάδειξη στη συγκεκριμένη γραμμή και στοίβα κλήσεων που οδηγεί σε μια ευπάθεια είναι εξαιρετική, αλλά στην πραγματικότητα, συχνά ο σαρωτής δεν παρέχει αρκετές πληροφορίες για να ελέγξει για εξωτερική ευπάθεια. Εξάλλου, το ελάττωμα μπορεί επίσης να βρίσκεται στον νεκρό κώδικα, ο οποίος είναι απρόσιτος για τον εισβολέα.
Θέματα σάρωσης υποδομής
- Ανεπαρκές απόθεμα. Σε μεγάλες υποδομές, ειδικά σε γεωγραφικά διαχωρισμένες, είναι συχνά το πιο δύσκολο πράγμα να καταλάβουμε ποιους κεντρικούς υπολογιστές να σαρώσετε. Με άλλα λόγια, το έργο της σάρωσης συνδέεται στενά με το έργο της διαχείρισης περιουσιακών στοιχείων.
- Κακή ιεράρχηση. Οι σαρωτές δικτύου παράγουν συχνά πολλά αποτελέσματα με ελαττώματα που δεν μπορούν να εκμεταλλευτούν στην πράξη, αλλά τυπικά το επίπεδο κινδύνου τους είναι υψηλό. Ο καταναλωτής λαμβάνει μια αναφορά που είναι δύσκολο να ερμηνευτεί και δεν είναι σαφές τι πρέπει να διορθωθεί πρώτα
- Κακές συστάσεις. Η βάση γνώσεων του σαρωτή περιέχει συχνά μόνο πολύ γενικές πληροφορίες σχετικά με την ευπάθεια και τον τρόπο επίλυσής της, επομένως οι διαχειριστές θα πρέπει να οπλιστούν με την Google. Η κατάσταση είναι ελαφρώς καλύτερη με τους σαρωτές whitebox, οι οποίοι μπορούν να εκδώσουν μια συγκεκριμένη εντολή για επιδιόρθωση
- Χειροποίητο. Οι υποδομές μπορεί να έχουν πολλούς κόμβους, πράγμα που σημαίνει ότι υπάρχουν δυνητικά πολλά ελαττώματα, οι αναφορές για τις οποίες πρέπει να αναλύονται και να αναλύονται χειροκίνητα σε κάθε επανάληψη
- Κακή κάλυψη. Η ποιότητα της σάρωσης υποδομής εξαρτάται άμεσα από το μέγεθος της βάσης γνώσεων σχετικά με τα τρωτά σημεία και τις εκδόσεις λογισμικού. Εν, , ακόμη και οι ηγέτες της αγοράς δεν έχουν μια ολοκληρωμένη βάση γνώσεων και υπάρχουν πολλές πληροφορίες στις βάσεις δεδομένων των δωρεάν λύσεων που δεν έχουν οι ηγέτες
- Προβλήματα με την επιδιόρθωση. Τις περισσότερες φορές, η επιδιόρθωση ευπάθειας υποδομής είναι η ενημέρωση ενός πακέτου ή η αλλαγή ενός αρχείου διαμόρφωσης. Το μεγάλο πρόβλημα εδώ είναι ότι το σύστημα, ειδικά το παλαιού τύπου, μπορεί να συμπεριφέρεται απρόβλεπτα ως αποτέλεσμα μιας ενημέρωσης. Στην πραγματικότητα, θα πρέπει να πραγματοποιήσετε δοκιμές ολοκλήρωσης σε μια ζωντανή υποδομή στην παραγωγή.
Προσεγγίσεις
Πώς μπορεί αυτό να είναι;
Θα αναφερθώ σε περισσότερες λεπτομέρειες σχετικά με παραδείγματα και πώς να αντιμετωπίσετε πολλά από αυτά τα προβλήματα στα ακόλουθα μέρη, αλλά προς το παρόν θα αναφέρω τους κύριους τομείς στους οποίους μπορείτε να εργαστείτε:
- Συνάθροιση διαφόρων εργαλείων σάρωσης. Με τη σωστή χρήση πολλαπλών σαρωτών, μπορεί να επιτευχθεί σημαντική αύξηση της βάσης γνώσεων και της ποιότητας της ανίχνευσης. Μπορείτε να βρείτε ακόμη περισσότερες ευπάθειες από το άθροισμα όλων των σαρωτών που εκτελούνται μεμονωμένα, ενώ μπορείτε να αξιολογήσετε με μεγαλύτερη ακρίβεια το επίπεδο κινδύνου και να κάνετε περισσότερες συστάσεις
- Ενσωμάτωση SAST και DAST. Είναι δυνατό να αυξήσετε την κάλυψη DAST και την ακρίβεια SAST με την κοινή χρήση πληροφοριών μεταξύ τους. Από την πηγή μπορείτε να λάβετε πληροφορίες για τις υπάρχουσες διαδρομές και με τη βοήθεια του DAST μπορείτε να ελέγξετε εάν η ευπάθεια είναι ορατή από έξω
- Machine Learning™. Το 2015 Ι (και ) σχετικά με τη χρήση στατιστικών για να δώσει στους σαρωτές τη διαίσθηση του χάκερ και να τους επιταχύνει. Αυτό είναι σίγουρα τροφή για την ανάπτυξη αυτοματοποιημένης ανάλυσης ασφάλειας στο μέλλον.
- Ενσωμάτωση IAST με autotests και OpenAPI. Εντός του αγωγού CI/CD, είναι δυνατή η δημιουργία μιας διαδικασίας σάρωσης που βασίζεται σε εργαλεία που λειτουργούν ως διακομιστής μεσολάβησης HTTP και λειτουργικές δοκιμές που λειτουργούν μέσω HTTP. Οι δοκιμές και οι συμβάσεις OpenAPI/Swagger θα δώσουν στον σαρωτή τις πληροφορίες που λείπουν σχετικά με τις ροές δεδομένων, θα καταστήσουν δυνατή τη σάρωση της εφαρμογής σε διάφορες καταστάσεις
- Σωστή διαμόρφωση. Για κάθε εφαρμογή και υποδομή, πρέπει να δημιουργήσετε ένα κατάλληλο προφίλ σάρωσης, λαμβάνοντας υπόψη τον αριθμό και τη φύση των διεπαφών, τις τεχνολογίες που χρησιμοποιούνται
- Προσαρμογή σαρωτή. Συχνά, μια εφαρμογή δεν μπορεί να σαρωθεί χωρίς τροποποίηση του σαρωτή. Ένα παράδειγμα είναι μια πύλη πληρωμής όπου κάθε αίτημα πρέπει να υπογράφεται. Χωρίς να γράψετε μια σύνδεση στο πρωτόκολλο πύλης, οι σαρωτές θα ραμφίζουν χωρίς σκέψη αιτήματα με λανθασμένη υπογραφή. Είναι επίσης απαραίτητο να γραφτούν εξειδικευμένοι σαρωτές για συγκεκριμένο τύπο ελαττωμάτων, όπως π.χ
- Διαχείριση κινδύνου. Η χρήση διάφορων σαρωτών και η ενοποίηση με εξωτερικά συστήματα, όπως η Διαχείριση Περιουσιακών Στοιχείων και η Διαχείριση Απειλών, θα επιτρέψει τη χρήση πολλαπλών παραμέτρων για την αξιολόγηση του επιπέδου κινδύνου, έτσι ώστε η διοίκηση να μπορεί να έχει μια επαρκή εικόνα της τρέχουσας κατάστασης ασφάλειας της ανάπτυξης ή της υποδομής.
Μείνετε συντονισμένοι και ας διακόψουμε τη σάρωση ευπάθειας!
Πηγή: www.habr.com