Η Google παρουσίασε το πλαίσιο SLSA (Supply-chain Levels for Software Artifacts), το οποίο συνοψίζει την υπάρχουσα εμπειρία στην προστασία της υποδομής ανάπτυξης από επιθέσεις που πραγματοποιούνται στο στάδιο της σύνταξης κώδικα, της δοκιμής, της συναρμολόγησης και της διανομής ενός προϊόντος.
Οι διαδικασίες ανάπτυξης γίνονται όλο και πιο περίπλοκες και εξαρτώνται από εργαλεία τρίτων, γεγονός που δημιουργεί ευνοϊκές συνθήκες για την προώθηση επιθέσεων που δεν σχετίζονται με τον εντοπισμό και την εκμετάλλευση τρωτών σημείων στο τελικό προϊόν, αλλά με τον κίνδυνο της ίδιας της διαδικασίας ανάπτυξης (επιθέσεις εφοδιαστικής αλυσίδας, που συνήθως στοχεύουν εισαγωγή κακόβουλων αλλαγών στη διαδικασία εγγραφής κώδικα, αντικατάστασης κατανεμημένων στοιχείων και εξαρτήσεων).
Το πλαίσιο λαμβάνει υπόψη 8 τύπους επιθέσεων που σχετίζονται με την απειλή πραγματοποίησης κακόβουλων αλλαγών στο στάδιο ανάπτυξης κώδικα, συναρμολόγησης, δοκιμής και διανομής του προϊόντος.
- Α. Συμπεριλαμβανομένων αλλαγών στον πηγαίο κώδικα που περιέχουν backdoors ή κρυφά σφάλματα που οδηγούν σε ευπάθειες.
Παράδειγμα επίθεσης: "Hypocrite Commits" - μια προσπάθεια προώθησης ενημερώσεων κώδικα με τρωτά σημεία στον πυρήνα του Linux.
Προτεινόμενη μέθοδος ασφαλείας: ανεξάρτητος έλεγχος κάθε αλλαγής από δύο προγραμματιστές.
- Β. Συμβιβασμός της πλατφόρμας ελέγχου πηγαίου κώδικα.
Παράδειγμα επίθεσης: ένεση κακόβουλων δεσμεύσεων με backdoor στο αποθετήριο Git ενός έργου PHP μετά τη διαρροή κωδικών πρόσβασης προγραμματιστή.
Προτεινόμενη μέθοδος προστασίας: Αυξημένη ασφάλεια της πλατφόρμας διαχείρισης κώδικα (στην περίπτωση της PHP, η επίθεση πραγματοποιήθηκε μέσω μιας ελάχιστα χρησιμοποιούμενης διεπαφής HTTPS, η οποία επέτρεπε την αποστολή αλλαγών κατά τη σύνδεση χρησιμοποιώντας έναν κωδικό πρόσβασης χωρίς έλεγχο του κλειδιού SSH, παρά το το γεγονός ότι το αναξιόπιστο MD5 χρησιμοποιήθηκε για κατακερματισμό κωδικών πρόσβασης).
- Γ. Πραγματοποίηση αλλαγών στο στάδιο της μεταφοράς κώδικα στο build ή στο σύστημα συνεχούς ενοποίησης (κατασκευάζεται κώδικας που δεν ταιριάζει με τον κώδικα από το αποθετήριο).
Παράδειγμα επίθεσης: Εισαγωγή backdoor στο Webmin κάνοντας αλλαγές στην υποδομή κατασκευής, με αποτέλεσμα τη χρήση αρχείων κώδικα που διαφέρουν από τα αρχεία του αποθετηρίου.
Προτεινόμενη μέθοδος προστασίας: Έλεγχος ακεραιότητας και αναγνώριση της προέλευσης του κώδικα στον διακομιστή συγκρότησης.
- Δ. Συμβιβασμός της πλατφόρμας συναρμολόγησης.
Παράδειγμα επίθεσης: η επίθεση SolarWinds, κατά την οποία εξασφαλίστηκε η εγκατάσταση μιας κερκόπορτας στο προϊόν SolarWinds Orion κατά το στάδιο της συναρμολόγησης.
Προτεινόμενη μέθοδος προστασίας: εφαρμογή προηγμένων μέτρων ασφαλείας για την πλατφόρμα συναρμολόγησης.
- Ε. Προώθηση κακόβουλου κώδικα μέσω εξαρτήσεων χαμηλής ποιότητας.
Ένα παράδειγμα επίθεσης: η εισαγωγή μιας κερκόπορτας στη δημοφιλή βιβλιοθήκη ροής συμβάντων προσθέτοντας μια αβλαβή εξάρτηση και στη συνέχεια συμπεριλαμβανομένου κακόβουλου κώδικα σε μια από τις ενημερώσεις αυτής της εξάρτησης (η κακόβουλη αλλαγή δεν αντικατοπτρίστηκε στο αποθετήριο git, αλλά υπάρχει μόνο στην τελική συσκευασία MNP).
Προτεινόμενη μέθοδος προστασίας: εφαρμόστε αναδρομικά τις απαιτήσεις SLSA σε όλες τις εξαρτήσεις (στην περίπτωση ροής συμβάντων, ο έλεγχος θα αποκάλυπτε τη συναρμολόγηση κώδικα που δεν αντιστοιχεί στα περιεχόμενα του κύριου αποθετηρίου Git).
- ΣΤ. Μεταφόρτωση αντικειμένων που δεν δημιουργήθηκαν στο σύστημα CI/CD.
Παράδειγμα επίθεσης: προσθήκη κακόβουλου κώδικα στο σενάριο CodeCov, το οποίο επέτρεπε στους εισβολείς να εξάγουν πληροφορίες αποθηκευμένες σε περιβάλλοντα συστήματος συνεχούς ενοποίησης πελατών.
Προτεινόμενη μέθοδος προστασίας: έλεγχος της προέλευσης και της ακεραιότητας των τεχνουργημάτων (στην περίπτωση του CodeCov, θα μπορούσε να αποκαλυφθεί ότι το σενάριο του Bash Uploader που αποστέλλεται από τον ιστότοπο codecov.io δεν αντιστοιχεί στον κώδικα από το αποθετήριο του έργου).
- Ζ. Συμβιβασμός του αποθετηρίου πακέτων.
Παράδειγμα επίθεσης: Οι ερευνητές μπόρεσαν να αναπτύξουν καθρέφτες ορισμένων δημοφιλών αποθετηρίων πακέτων για να διανείμουν κακόβουλα πακέτα μέσω αυτών.
Προτεινόμενη μέθοδος προστασίας: Επαλήθευση ότι τα κατανεμημένα τεχνουργήματα έχουν μεταγλωττιστεί από τους δηλωμένους πηγαίους κώδικες.
- Η. Μπέρδευε τον χρήστη να εγκαταστήσει λάθος πακέτο.
Παράδειγμα επίθεσης: χρήση typosquatting (NPM, RubyGems, PyPI) για την τοποθέτηση πακέτων σε αποθετήρια που είναι παρόμοια γραπτά με δημοφιλείς εφαρμογές (για παράδειγμα, coffe-script αντί για coffee-script).
Για τον αποκλεισμό των επισημασμένων απειλών, το SLSA προσφέρει ένα σύνολο συστάσεων, καθώς και εργαλεία για την αυτοματοποίηση της δημιουργίας μεταδεδομένων ελέγχου. Το SLSA συνοψίζει τις κοινές μεθόδους επίθεσης και εισάγει την έννοια των επιπέδων ασφαλείας. Κάθε επίπεδο επιβάλλει ορισμένες απαιτήσεις υποδομής για τη διασφάλιση της ακεραιότητας των αντικειμένων που χρησιμοποιούνται στην ανάπτυξη. Όσο υψηλότερο είναι το υποστηριζόμενο επίπεδο SLSA, τόσο περισσότερες προστασίες εφαρμόζονται και τόσο καλύτερα προστατεύεται η υποδομή από κοινές επιθέσεις.
- Το SLSA 1 απαιτεί η διαδικασία δημιουργίας να είναι πλήρως αυτοματοποιημένη και να δημιουργεί μεταδεδομένα ("προέλευση") σχετικά με τον τρόπο κατασκευής των τεχνουργημάτων, συμπεριλαμβανομένων πληροφοριών σχετικά με τις πηγές, τις εξαρτήσεις και τη διαδικασία κατασκευής (παρέχεται ένα παράδειγμα δημιουργίας μεταδεδομένων για έλεγχο για το GitHub Actions). Το SLSA 1 δεν περιλαμβάνει στοιχεία προστασίας από κακόβουλες τροποποιήσεις, αλλά απλώς προσδιορίζει τον κώδικα και παρέχει μεταδεδομένα για διαχείριση ευπάθειας και ανάλυση κινδύνου.
- SLSA 2 - επεκτείνει το πρώτο επίπεδο απαιτώντας τη χρήση υπηρεσιών ελέγχου έκδοσης και συναρμολόγησης που δημιουργούν επικυρωμένα μεταδεδομένα. Η χρήση του SLSA 2 σάς επιτρέπει να εντοπίσετε την προέλευση του κώδικα και αποτρέπει τις μη εξουσιοδοτημένες αλλαγές στον κώδικα στην περίπτωση αξιόπιστων υπηρεσιών κατασκευής.
- SLSA 3 - επιβεβαιώνει ότι ο πηγαίος κώδικας και η πλατφόρμα κατασκευής πληρούν τις απαιτήσεις προτύπων που εγγυώνται τη δυνατότητα ελέγχου του κώδικα και τη διασφάλιση της ακεραιότητας των μεταδεδομένων που παρέχονται. Υποτίθεται ότι οι ελεγκτές μπορούν να πιστοποιήσουν τις πλατφόρμες σύμφωνα με τις απαιτήσεις των προτύπων.
- Το SLSA 4 είναι το υψηλότερο επίπεδο, συμπληρώνοντας τα προηγούμενα επίπεδα με τις ακόλουθες απαιτήσεις:
- Υποχρεωτική αναθεώρηση όλων των αλλαγών από δύο διαφορετικούς προγραμματιστές.
- Όλα τα βήματα κατασκευής, ο κώδικας και οι εξαρτήσεις πρέπει να δηλωθούν πλήρως, όλες οι εξαρτήσεις πρέπει να εξαχθούν και να επαληθευτούν ξεχωριστά και η διαδικασία δημιουργίας πρέπει να εκτελείται εκτός σύνδεσης.
- Η χρήση μιας επαναλαμβανόμενης διαδικασίας κατασκευής σάς επιτρέπει να επαναλάβετε τη διαδικασία κατασκευής μόνοι σας και να βεβαιωθείτε ότι το εκτελέσιμο έχει δημιουργηθεί από τον πηγαίο κώδικα που παρέχεται.
Πηγή: opennet.ru