OWASP_logoΣυνεχίζοντας τον κύκλο άρθρων σχετικά με την ασφάλεια σε δικτυακά περιβάλλοντα σε συνεργασία με τον Παναγιώτη Καλαντζή στο άρθρο αυτό εξετάζουμε την πέμπτη συνηθέστερη αδυναμία, την κακή παραμετροποίηση των θεμάτων ασφάλειας της διαδικτυακής.

Οι καλοσχεδιασμένες διαδικτυακές εφαρμογές στις μέρες μας παρουσιάζονται στους χρήστες τους ως απλές, πολύ απλές παρότι στο υπόβαθρο επιτελούν ιδιαίτερα πολύπλοκες διαδικασίες. Ακολούθως, αποτελούνται από πολλά αρθρώματα (modules) καθένα από τα οποία απαιτεί και τις αντίστοιχες ρυθμίσεις ασφαλείας. Επιπλέον, η διαρκής «επανα-εφεύρεση του τροχού» από τους σχεδιαστές και μηχανικούς της εφαρμογής διόλου αποδοτική δεν μπορεί να θεωρηθεί, η χρήση των πλαισίων (frameworks) ταχείας ανάπτυξης είναι εκτός από συνήθης τακτική και προτεινόμενη. Ωστόσο, τα πλαίσια αυτά για να μπορούν να αντιμετωπίσουν και υποστηρίξουν πολλές διαφορετικές εφαρμογές με πλήρως διαφορετικό αντικείμενο, είναι γενικευμένα και έχουν διάφορα χαρακτηριστικά όπως λ.χ. προκαθορισμένους λογαριασμούς χρηστών για την εκκίνηση/επίδειξη του συστήματος και μεθόδους αποσφαλμάτωσης (debugging) που εκθέτουν εκμεταλλεύσιμες πληροφορίες όσο το σύστημα είναι σε κατάσταση δοκιμών (beta version).

Έτσι ο επιτιθέμενος έχει πιθανώς πρόσβαση σε προκαθορισμένους λογαριασμούς χρηστών, μη χρησιμοποιούμενες σελίδες σφάλματα που δεν έχουν διορθωθεί αλλά είναι ευρέως γνωστά, μη προστατευμένα αρχεία και καταλόγους που του επιτρέπουν μη διαπιστευμένη πρόσβαση στο σύστημα ή πολύτιμη πληροφορία για να την αποκτήσει. Για την διαπίστωση της ύπαρξης θέματος ασφάλειας λόγω κακής παραμετροποίησης της εφαρμογής συνήθως εξετάζονται τα εξής:

  1. Αν η έκδοση του λογισμικού της εφαρμογής είναι ενημερωμένη, συμπεριλαμβάνοντας το λειτουργικό σύστημα, τον διαδικτυακό εξυπηρετητή, τη βάση διαχείρισης δεδομένων και τις χρησιμοποιούμενες βιβλιοθήκες,
  2. Αν είναι εγκατεστημένα στην εφαρμογή χαρακτηριστικά που δεν είναι αναγκαία και είναι πιθανώς θέματα ασφάλειας, λ.χ. ports, services, σελίδες, λογαριασμοί, δικαιώματα κλπ,
  3. Αν είναι ενεργοποιημένοι οι προκαθορισμένοι λογαριασμοί με τα ευρέως γνωστά συνθηματικά τους,
  4. Αν εκτίθεται εκμεταλλεύσιμη πληροφορία κατά την αναφορά προβλημάτων,
  5. Αν είναι οι ρυθμίσεις ασφάλειας των πλαισίων ανάπτυξης και των βιβλιοθηκών που χρησιμοποιούνται από την εφαρμογή σε κατάσταση «διάθεσης στους χρήστες» ή δοκιμαστική.

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

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

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

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

Τα συνήθη αποτελέσματα της εκμετάλλευσης της αδυναμίας αυτής είναι πως ο επιτιθέμενος μπορεί να καταλάβει την εφαρμογή!

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

Για την αντιμετώπιση της εν λόγω αδυναμίας, η λύση απαιτεί τουλάχιστον όλα τα εξής:

  1. Προσδιορισμός διαδικασίας ενδυνάμωσης των ρυθμίσεων ασφάλειας εκδόσεων «προς τους χρήστες» της εφαρμογής,
  2. Οργανωμένη μεθοδολογία εντοπισμού ενημερώσεων των υποσυστημάτων της εφαρμογής,
  3. Χρήση ασφαλούς αρχιτεκτονικής της εφαρμογής που προσφέρει διαχωρισμό σε θέματα ασφάλειας μεταξύ των υποσυστημάτων της εφαρμογής,
  4. Εκτέλεση περιοδικών ελέγχων για τον εντοπισμό επισφαλών ρυθμίσεων.

Στο επόμενο άρθρο θα δούμε την αδυναμία που προκαλείται από την επισφαλή άμεση αναφορά σε οντότητες της εφαρμογής (Insecure Direct Object References).

Επικοινωνήστε μαζί μας για να συζητήσουμε πώς μπορεί το διαδικτυακού λογισμικό σας να γίνει ασφαλέστερο προστατεύοντας την επιχείρησή και τους πελάτες σας.

Share This: