Ο ανοιχτός κώδικας για εμπορικό λογισμικό είναι πανταχού παρών, αλλά και ο κίνδυνος

Ο ανοιχτός κώδικας για εμπορικό λογισμικό είναι πανταχού παρών, αλλά και ο κίνδυνος

Dezember 17, 2022 0 Von admin

Όπως δείχνουν οι εισβολές SolarWinds και Log4j, τα τρωτά σημεία στο λογισμικό ανοιχτού κώδικα που χρησιμοποιείται στην ανάπτυξη εφαρμογών μπορούν να ανοίξουν πόρτες για τους εισβολείς με τεράστιες συνέπειες. Μια νέα μελέτη εξετάζει τις προσπάθειες της κοινότητας ανοιχτού κώδικα να «πιστοληπτικά» τον κίνδυνο.

Εγγραφή λειτουργιών προγραμματισμού σε φορητό υπολογιστή.  Επανάσταση της νέας τεχνολογίας.  Κοντινό πλάνο πηγαίου κώδικα.  Τάση για τα μεγάλα δεδομένα και το Διαδίκτυο των πραγμάτων.  Κωδικοποίηση χάκερ έννοια.  Κώδικας JavaScript στο πρόγραμμα επεξεργασίας κειμένου.
Εικόνα: Maciej905/Adobe Stock

Ήταν σχεδόν ακριβώς πριν από ένα χρόνο που οι ειδικοί βρήκαν την περιβόητη ευπάθεια του μηνύματος σφάλματος Log4Shell στη βιβλιοθήκη Java ανοιχτού κώδικα Apache Log4j 2. Η αδυναμία ήταν μόνο ένα πρόσφατο παράδειγμα backdoor σε λογισμικό ανοιχτού κώδικα για τους εισβολείς να κρυφτούν κακόβουλο κώδικα στον προγραμματιστή και στο τέλος -συστήματα χρηστών. Έκτοτε, έχουν γίνει δεκάδες εκατομμύρια απόπειρες συμβιβασμού του ελαττώματος Log4jShell.

ΒΛΕΠΩ: Ο ιρανικός κρατικός παράγοντας απειλών στοχεύει νέα θύματα σε εκστρατείες κυβερνοκατασκοπείας και κινητικής (TechRepublic)

Εάν οι ειδικοί προσδιορίσουν την παροχή λογισμικού ως βασική πρόκληση ασφαλείας για το 2023, το φαινόμενο Log4j — για να μην αναφέρουμε την πολύ πιο γνωστή εισβολή κακόβουλου λογισμικού Sunburst (που κοινώς αναφέρεται ως επίθεση SolarWinds) τον Δεκέμβριο του 2020 — ρίχνει φως στον τρόπο προστασίας της διαδικασίας θα μπορούσε να είναι δύσκολο: Ένας τεράστιος αριθμός εμπορικού λογισμικού δεν είναι γραμμένος εσωτερικά. Προέρχεται από την άγρια ​​δύση των πακέτων λογισμικού ελεύθερου και ανοιχτού κώδικα όπως το Log4j στο GitHub και αλλού.

Οι εξαρτήσεις λογισμικού ανοιχτού κώδικα έχουν εξαρτήσεις

Όπως ένας κηπουρός που προσπαθεί να αρπάξει μόνο ένα φυτό κισσού, ένας προγραμματιστής εφαρμογών που εισάγει κώδικα από το οικοσύστημα FOSS παίρνει συχνά περισσότερα από τον κωδικό που παζαρεύτηκε επειδή αυτά τα πακέτα εκτός τοιχογραφίας από αποθετήρια όπως το GitHub συχνά φέρνουν μαζί μεταβατικές εξαρτήσεις. Αυτές είναι οι δευτερεύουσες και τριτογενείς σχέσεις που έχει ένα πακέτο FOSS με άλλο ανοιχτό κώδικα, αποτελώντας ένα «κρυμμένο» ριζικό σύστημα λογισμικού άγνωστης προέλευσης, αόρατο στους προγραμματιστές, εγγενώς αναξιόπιστο και δυνητικά επικίνδυνο.

ΒΛΕΠΩ: Η ακατάλληλη χρήση των διαχειριστών κωδικών πρόσβασης αφήνει τους ανθρώπους ευάλωτους σε κλοπή ταυτότητας (TechRepublic)

Μια νέα μελέτη με τίτλο «Η διαχείριση της κατάστασης εξάρτησης» από το Endor Lab’s Station 9 αποκάλυψε ότι το 95% όλων των τρωτών σημείων βρίσκονται σε αυτά τα πακέτα ανοιχτού κώδικα που δεν επιλέγονται από τους προγραμματιστές, αλλά εμπλέκονται έμμεσα σε έργα.

«Με ορισμένα μέτρα, για κάθε εξάρτηση που φέρνει ένας προγραμματιστής σε ένα έργο λογισμικού, υπάρχουν, κατά μέσο όρο, 77 έως 78 μεταβατικές εξαρτήσεις», δήλωσε ο Varun Badhwar, συνιδρυτής και Διευθύνων Σύμβουλος της Endor Labs. «Επιπλέον, το 95% των τρωτών σημείων που βρέθηκαν είναι σε αυτές τις μεταβατικές εξαρτήσεις, τα πράγματα που συνοδεύουν τα πράγματα που φέρατε. Πρέπει να παρακολουθούμε όλα αυτά στο περιβάλλον μας και να κατανοήσουμε σε ποιες εφαρμογές χρησιμοποιούνται αυτά τα πακέτα».

Ο Henrik Plate, ερευνητής ασφάλειας στα εργαστήρια Endor, σημείωσε ότι η συγγραφή λογισμικού είναι πλέον σαν να συνθέτεις μια BMW.

«Παίρνετε διάφορα εξαρτήματα από κάπου αλλού και τα συναρμολογείτε», είπε ο Plate.

Ο Badhwar είπε ότι το 80% έως 90% του κώδικα σε μια τυπική σύγχρονη εφαρμογή είναι «κώδικας που δεν γράφουμε, είναι κώδικας που δανειζόμαστε και πραγματικά δεν ξέρουμε από ποιον τον δανειζόμαστε. Οι επιτιθέμενοι το έχουν καταλάβει αυτό. Το λογισμικό ανοιχτού κώδικα θα είναι θεμελιώδες για την ασφάλεια της εφοδιαστικής αλυσίδας λογισμικού, επομένως πρέπει να εκπαιδεύσουμε καλύτερα την αγορά για τα ζητήματα».

Επισήμανε ότι το πλαίσιο Λογισμικού Bill of Materials, αν και έχει σχεδιαστεί για να παρέχει ακριβείς πληροφορίες εξάρτησης, σπάνια το κάνει. Ειδικά δεν το κάνει για μεταβατικές εξαρτήσεις, δεδομένης της ακρίβειάς τους σε ένα επίπεδο εξάρτησης.

ΒΛΕΠΩ: Πώς η Microsoft θα δημοσιεύει πληροφορίες για τη συμμόρφωση με την εκτελεστική εντολή σχετικά με τη τιμολόγηση υλικού λογισμικού (TechRepublic)

Αναγνωρίζοντας τον επείγοντα χαρακτήρα του ζητήματος ασφάλειας FOSS, το Κογκρέσο εισήγαγε τον νόμο περί ασφαλούς λογισμικού ανοιχτού κώδικα τον Σεπτέμβριο του 2022. Το νομοσχέδιο προέτρεψε την CISA να «δημοσιεύσει δημοσίως ένα πλαίσιο, το οποίο ενσωματώνει κυβερνητικά, βιομηχανία και κοινοτικά πλαίσια λογισμικού ανοιχτού κώδικα και βέλτιστες πρακτικές, για την αξιολόγηση των κίνδυνος στοιχείων λογισμικού ανοιχτού κώδικα». Δεν έχει σημειωθεί καμία πρόοδος στο νομοσχέδιο από την κατάθεσή του.

Ποιο λογισμικό ανοιχτού κώδικα είναι κρίσιμο;

Οι ερευνητές του Log4j προσπάθησαν να καταλάβουν εάν υπάρχει συναίνεση σχετικά με τα πιο κρίσιμα πακέτα FOSS για εταιρικό λογισμικό. Αυτά είναι τα πακέτα που χρησιμοποιούνται περισσότερο από τους περισσότερους προγραμματιστές και μεταγενέστερους χρήστες, έχουν την ευρύτερη λειτουργικότητα και τη μεγαλύτερη πιθανή έκθεση μέσω εξαρτήσεων.

Για να γίνει αυτό, διερεύνησαν βαθμολογίες κρισιμότητας από τις δύο πιο δημοφιλείς κοινοτικές πρωτοβουλίες για τον εντοπισμό κρίσιμων έργων: το «Census II of Free and Open Source Software — Application Libraries» που υποστηρίζεται από το Linux Foundation και το έργο Criticality Score του Open Source Security Foundation.

«Θέλαμε να μάθουμε εάν αυτές οι προσεγγίσεις συγκλίνουν. Έτσι, αν συμφωνούν σε ό,τι είναι κρίσιμο και τι όχι», είπε ο Πλέιτ.

Δεν υπήρχε μεγάλη επικάλυψη στα σετ έργων Census II και OpenSSF Criticality Scores. Η μελέτη σημείωσε ότι ορισμένα πακέτα Census II προήλθαν από το ίδιο έργο και ότι 264 πακέτα που βασίζονται σε Java στην ομάδα του Census II προέρχονται από μόνο 169 διαφορετικά έργα (Εικόνα Α).

Εικόνα Α

Τα διαγράμματα Venn δείχνουν τη διασταύρωση διαφορετικών έργων GitHub του Census II και των κορυφαίων 200 έργων από το έργο Criticality Score.
Εικόνα: Endor Labs. Τα διαγράμματα Venn δείχνουν τη διασταύρωση διαφορετικών έργων GitHub του Census II και των κορυφαίων 200 έργων από το έργο Criticality Score.

Αυτό δεν ήταν έκπληξη για τον καθηγητή Justin Cappos στο NYU Tandon’s School of Engineering, έναν ειδικό σε θέματα ασφάλειας που εργάζεται στον χώρο ασφάλειας της αλυσίδας εφοδιασμού λογισμικού για περισσότερο από μια δεκαετία.

«Πραγματικά κάναμε τη δική μας ανάλυση για το ποια έργα ανοιχτού κώδικα είναι κρίσιμα και αποφασίσαμε να μην δημοσιεύσουμε τα δεδομένα, επειδή δεν μπορούσαμε να βρούμε μια αρκετά σταθερή μέτρηση για να μετρήσουμε την κρισιμότητα», είπε ο Cappos. «Είναι ένα δύσκολο πρόβλημα».

Η ομάδα Endor διαπίστωσε επίσης ότι:

  • Τα μισά από τα πιο συχνά χρησιμοποιούμενα πακέτα ανοιχτού κώδικα δεν ενημερώθηκαν φέτος και το 30% είχε την τελευταία του κυκλοφορία πριν από το 2018.
  • Υπάρχει πιθανότητα 32% η τελευταία έκδοση ενός πακέτου λογισμικού ανοιχτού κώδικα να έχει τρωτά σημεία.
  • Κατά την αναβάθμιση στην πιο πρόσφατη έκδοση ενός πακέτου, εξακολουθεί να υπάρχει πιθανότητα 32% να έχει γνωστά τρωτά σημεία.
  • Το 75% των πακέτων στο Census II έχουν βαθμολογία κρισιμότητας μικρότερη από 0,64 — δηλαδή σε κλίμακα από το μηδέν έως το ένα, με το μηδέν να είναι λιγότερο κρίσιμο.
  • Η χρήση μόνο μετρήσεων ασφαλείας κατά την ιεράρχηση προτεραιοτήτων μειώνει μόνο την πιθανότητα ευπάθειας κατά 20%.

Ανοιχτός κώδικας: Caveat emptor

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

«Χρειάστηκε περίπου 33.000 ώρες για να καταλάβει το DHS πού είχε πάει το Log4j και στη συνέχεια να το επανορθώσει», είπε. „Κάθε οργανισμός και προμηθευτής λογισμικού θα πρέπει να παρακολουθεί κάθε στοιχείο και εξάρτηση στο περιβάλλον του και αυτό ξεκινά με την παρακολούθηση για τη δημιουργία ενός αποθέματος σε επίπεδο λογισμικού του τι φέρνουν οι προγραμματιστές από το Διαδίκτυο.“

Η Plate είπε ότι η κρισιμότητα ποικίλλει και αυτή η αποφασιστικότητα δεν μπορεί να ανατεθεί σε εξωτερικούς συνεργάτες.

«Κάθε χρήστης έχει τις δικές του απαιτήσεις ασφαλείας», είπε. «Τελικά, οι οργανισμοί ανάπτυξης παραμένουν υπεύθυνοι για τις εμπορικές υπηρεσίες λογισμικού και τα προϊόντα που πωλούν, επομένως αυτοί είναι άλλοι λόγοι που δεν μπορούν απλώς να ανατεθούν σε εξωτερικούς συνεργάτες στην κοινότητα ανοιχτού κώδικα».