API9:2019 Improper Assets Management

Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors)	Αδυναμία Ασφαλείας (Security Weakness)	Επιπτώσεις (Impacts)
Εξαρτώνται από το API : Εκμεταλλευσιμότητα 3	Επικράτηση (Prevalence) 3 : Ανιχνευσιμότητα 2	Τεχνικές Επιπτώσεις 2 : Εξαρτώνται από την Επιχείρηση
Οι παλιές εκδόσεις ενός API μένουν συνήθως ανενημέρωτες από ενημερώσεις ασφαλείας (unpatched) και έτσι αποτελούν έναν εύκολο τρόπο για την παραβίαση συστημάτων χωρίς να χρειάζεται ο εισβολέας να αντιμετωπίσει μηχανισμούς ασφαλείας τελευταίας τεχνολογίας, οι οποίοι μπορεί να υπάρχουν αλλά να προστατεύουν μόνο τις νέες εκδόσεις ενός API.	Η μη ενημερωμένη τεκμηρίωση (documentation) ενός API καθιστά πιο δύσκολη την εύρεση ή/και τη διόρθωση ευπαθειών. Η έλλειψη μεθοδικής καταγραφής των πληροφοριακών στοιχείων (assets inventory) και η έλλειψη στρατηγικών απόσυρσης (retire strategies) οδηγούν στο να τρέχουν ανενημέρωτα (unpatched) συστήματα, με αποτέλεσμα τη διαρροή ευαίσθητων δεδομένων. Είναι σύνηθες να βρίσκουμε άσκοπα εκτεθειμένους κεντρικούς υπολογιστές API λόγω των σύγχρονων concepts όπως τα microservices, τα οποία καθιστούν τις εφαρμογές ανεξάρτητες και εύκολες στην ανάπτυξη (π.χ. υπολογιστικό νέφος (cloud), k8s).	Οι εισβολείς ενδέχεται να αποκτήσουν πρόσβαση σε ευαίσθητα δεδομένα ή ακόμη και πάρουν τον έλεγχο του διακομιστή μέσω παλιών, μη ενημερωμένων εκδόσεων API που συνδέονται στην ίδια βάση δεδομένων.

Πότε το API είναι ευάλωτο

Το API ίσως είναι ευάλωτο όταν:

Ο σκοπός ενός κεντρικού υπολογιστή API είναι ασαφής και δεν υπάρχουν σαφείς απαντήσεις στις ακόλουθες ερωτήσεις:
Σε ποιο περιβάλλον εκτελείται το API (π.χ. παραγωγή (production), σταδιοποίηση (staging), δοκιμή (test), ανάπτυξη (development));
Ποιος πρέπει να έχει δικτυακή πρόσβαση στο API (π.χ. δημόσια πρόσβαση, εσωτερική πρόσβαση, πρόσβαση σε συνεργάτες);
Ποια έκδοση API εκτελείται;
Ποια δεδομένα συλλέγονται και επεξεργάζονται από το API (π.χ. Προσωπικά αναγνωρίσιμα στοιχεία (PII));
Ποια είναι η ροή των δεδομένων;
Δεν υπάρχει τεκμηρίωση (documentation) ή η υπάρχουσα τεκμηρίωση δεν έχει ενημερωθεί.
Δεν υπάρχει σχέδιο απόσυρσης (retirement plan) για κάθε έκδοση API.
Δεν υπάρχει αρχείο καταγραφής όλων των hosts (hosts inventory) ή αν υπάρχει δεν είναι ενημερωμένο.
Το αρχείο καταγραφής ολοκληρωμένων υπηρεσιών (integrated services inventory), είτε της εταιρίας που φτιάχνει το API (first-party), είτε τρίτων μελών (third-party), λείπει ή είναι παλιό.
Εκτελούνται παλιές ή προηγούμενες εκδόσεις του API χωρίς ενημέρωση.

Παραδείγματα Σεναρίων Επίθεσης

Σενάριο Επίθεσης #1

Μετά τον επανασχεδιασμό των εφαρμογών της, μια τοπική υπηρεσία αναζήτησης άφησε μια παλιά έκδοση API (api.someservice.com/v1) σε λειτουργία, απροστάτευτη και με πρόσβαση στη βάση δεδομένων των χρηστών. Ένας εισβολέας, ενώ στόχευε μία από τις πιο πρόσφατες εφαρμογές που κυκλοφόρησαν, βρήκε τη διεύθυνση API (api.someservice.com/v2). Η αντικατάσταση του «v2» με το «v1» στη διεύθυνση URL έδωσε στον εισβολέα πρόσβαση στο παλιό, μη προστατευμένο API, εκθέτοντας τα προσωπικά στοιχεία ταυτοποίησης (PII) περισσότερων από 100 εκατομμυρίων χρηστών.

Σενάριο Επίθεσης #2

Ένα κοινωνικό δίκτυο εφάρμοσε έναν μηχανισμό περιορισμού ρυθμού (rate limiting) που εμποδίζει τους εισβολείς να χρησιμοποιούν επιθέσεις ωμής βίας (brute force attacks) για να μαντέψουν τα διακριτικά επαναφοράς κωδικών πρόσβασης. Αυτός ο μηχανισμός δεν εφαρμόστηκε ως μέρος του ίδιου του κώδικα API, αλλά σε ένα ξεχωριστό στοιχείο (component) μεταξύ του πελάτη και του επίσημου API («www.socialnetwork.com»). Ένας ερευνητής βρήκε έναν δεύτερο κεντρικό υπολογιστή («www.mbasic.beta.socialnetwork.com») που εκτελεί το ίδιο API, συμπεριλαμβανομένου του μηχανισμού επαναφοράς κωδικού πρόσβασης, αλλά χωρίς μηχανισμό περιορισμού ρυθμού. Ο ερευνητής μπόρεσε να επαναφέρει τον κωδικό πρόσβασης οποιουδήποτε χρήστη χρησιμοποιώντας μια απλή επίθεση ωμής βίας για να μαντέψει το διακριτικό των 6 ψηφίων.

Τρόπος Πρόληψης

Καταγράψτε όλους τους υπολογιστές (hosts) που φιλοξενούν API. Καταγράψτε τα περιβάλλοντα που τρέχουν τα API (production, staging, test, development). Επίσης καταγράψτε ποιος θα πρέπει να έχει πρόσβαση σε αυτά (ανοιχτά σε όλους, εσωτερική πρόσβαση, πρόσβαση σε συνεργάτες) καθώς και την έκδοση τους.
Καταγράψτε τις ολοκληρωμένες υπηρεσίες (integrated services) δηλαδή τις εξωτερικές υπηρεσίες που χρησιμοποιούν το API. Τεκμηριώστε σημαντικές πτυχές τους όπως ο ρόλος τους στο σύστημα, ποια δεδομένα ανταλλάσσονται (ροή δεδομένων) και η ευαισθησία τους.
Τεκμηριώστε όλες τις πτυχές του API σας, όπως τον έλεγχο ταυτότητας, τα σφάλματα, τις ανακατευθύνσεις, τον περιορισμό ρυθμού, την πολιτική και τα τελικά σημεία κοινής χρήσης πόρων μεταξύ προέλευσης (CORS), συμπεριλαμβανομένων των παραμέτρων, των αιτημάτων και των απαντήσεών τους.
Δημιουργήστε τεκμηρίωση αυτόματα υιοθετώντας ανοιχτά πρότυπα (open standards). Συμπεριλάβετε την αυτόματη δημιουργία τεκμηρίωσης στο σύστημα CI/CD σας.
Παραχωρήστε πρόσβαση στην τεκμηρίωση API σε όσους είναι εξουσιοδοτημένοι να χρησιμοποιούν το API.
Χρησιμοποιήστε εξωτερικά μέτρα προστασίας, όπως τείχη προστασίας ασφαλείας API για όλες τις εκτεθειμένες εκδόσεις των API σας και όχι μόνο για την τρέχουσα έκδοση παραγωγής.
Αποφύγετε τη χρήση δεδομένων παραγωγής σε μη παραγωγικές διανομές (deployments) του API. Εάν αυτό είναι αναπόφευκτο, αυτά τα τελικά σημεία προορισμού θα πρέπει να τυγχάνουν της ίδιας μεταχείρισης ασφαλείας με αυτά της παραγωγής.
Όταν νεότερες εκδόσεις των API περιλαμβάνουν βελτιώσεις ασφαλείας, πραγματοποιήστε ανάλυση κινδύνου για να αποφασίσετε για τις ενέργειες μετριασμού που απαιτούνται για τις παλαιότερες εκδόσεις: για παράδειγμα, εάν είναι δυνατή η υποστήριξη των βελτιώσεων χωρίς να διαταραχθεί η συμβατότητα API ή εάν πρέπει να αφαιρέσετε τις παλαιότερες εκδόσεις γρήγορα και να αναγκάσετε όλους τους χρήστες / εφαρμογές-πελάτες να μετακινηθούν στην πιο πρόσφατη έκδοση.