Πώς οι χάκερς αναλαμβάνουν ιστοσελίδες με SQL Injection και DDoS
Ακόμα κι αν ακολουθήσατε χαλαρά τα γεγονότα των ομάδων χάκερ Anonymous και LulzSec, πιθανότατα έχετε ακούσει για ιστοσελίδες και υπηρεσίες που έχουν hacked, όπως και οι περίφημες hacks της Sony. Έχετε αναρωτηθεί ποτέ πώς το κάνουν?
Υπάρχουν διάφορα εργαλεία και τεχνικές που χρησιμοποιούν αυτές οι ομάδες και ενώ δεν προσπαθούμε να σας δώσουμε ένα εγχειρίδιο για να το κάνετε εσείς οι ίδιοι, είναι χρήσιμο να καταλάβετε τι συμβαίνει. Δύο από τις επιθέσεις που ακούτε συστηματικά σχετικά με αυτούς είναι οι "(Distributed) Denial of Service" (DDoS) και "SQL Injections" (SQLI). Δείτε πώς λειτουργούν.
Εικόνα από xkcd
Επίθεση άρνησης εξυπηρέτησης
Τι είναι αυτό?
Μια "άρνηση εξυπηρέτησης" (μερικές φορές αποκαλείται "κατανεμημένη άρνηση εξυπηρέτησης" ή DDoS) επιτίθεται όταν ένα σύστημα, στην περίπτωση αυτή ένας διακομιστής ιστού, λαμβάνει τόσες πολλές αιτήσεις ταυτόχρονα ότι οι πόροι του διακομιστή είναι υπερφορτωμένοι. και κλείνει. Ο στόχος και το αποτέλεσμα μιας επιτυχημένης επίθεσης DDoS είναι ότι οι ιστότοποι στο διακομιστή προορισμού δεν είναι διαθέσιμοι για να δικαιολογήσουν αιτήματα κυκλοφορίας.
Πώς λειτουργεί?
Το logistics μιας επίθεσης DDoS μπορεί να εξηγηθεί καλύτερα με ένα παράδειγμα.
Φανταστείτε ότι ένα εκατομμύριο άνθρωποι (οι επιτιθέμενοι) συγκεντρώνονται με στόχο να παρεμποδίσουν την επιχείρηση της Εταιρείας Χ, καταλαμβάνοντας το τηλεφωνικό τους κέντρο. Οι επιτιθέμενοι συντονίζονται έτσι ώστε την Τρίτη στις 9 π.μ. θα καλέσουν όλους τους τηλεφωνικούς αριθμούς της Εταιρείας Χ. Το πιο πιθανό είναι ότι το τηλεφωνικό σύστημα της εταιρείας X δεν θα είναι σε θέση να χειριστεί ταυτόχρονα ένα εκατομμύριο κλήσεις, έτσι ώστε όλες οι εισερχόμενες γραμμές να δεσμευτούν από τους εισβολείς. Το αποτέλεσμα είναι ότι οι νόμιμες κλήσεις πελατών (δηλ. Εκείνες που δεν είναι οι εισβολείς) δεν επιτυγχάνουν επειδή το τηλεφωνικό σύστημα είναι συνδεδεμένο χειριστεί τις κλήσεις από τους εισβολείς. Επομένως, στην ουσία, η Εταιρεία Χ ενδέχεται να χάσει τις δραστηριότητές της εξαιτίας των νόμιμων αιτημάτων που δεν μπορούν να περάσουν.
Μια επίθεση DDoS σε έναν διακομιστή ιστού λειτουργεί ακριβώς με τον ίδιο τρόπο. Επειδή δεν υπάρχει σχεδόν κανένας τρόπος να γνωρίζουμε ποια κίνηση προέρχεται από τα νόμιμα αιτήματα έναντι των εισβολέων έως ότου ο διακομιστής ιστού επεξεργάζεται την αίτηση, αυτός ο τύπος επίθεσης είναι συνήθως πολύ αποτελεσματικός.
Εκτελώντας την επίθεση
Λόγω της φύσης της επίθεσης DDoS "βίαιης δύναμης", πρέπει να έχετε πολλούς υπολογιστές συντονισμένους για να επιτεθείτε ταυτόχρονα. Επανεξετάζοντας το παράδειγμα του τηλεφωνικού μας κέντρου, αυτό θα απαιτούσε από όλους τους επιτιθέμενους να γνωρίζουν και να καλούν στις 9 π.μ. και να τηλεφωνούν εκείνη τη στιγμή. Αν και αυτή η αρχή σίγουρα θα λειτουργήσει όταν πρόκειται να επιτεθεί σε ένα web server, γίνεται πολύ πιο εύκολη όταν οι υπολογιστές zombie, αντί των πραγματικών επανδρωμένων υπολογιστών, χρησιμοποιούνται.
Όπως πιθανότατα γνωρίζετε, υπάρχουν πολλές παραλλαγές κακόβουλου λογισμικού και trojans, οι οποίες, κάποτε στο σύστημά σας, βρίσκονται αδρανείς και περιστασιακά "τηλέφωνο στο σπίτι" για οδηγίες. Μία από αυτές τις οδηγίες μπορεί να είναι, για παράδειγμα, η αποστολή επανειλημμένων αιτημάτων στον εξυπηρετητή ιστού της Εταιρείας X στις 9 π.μ. Έτσι, με μια μόνο ενημέρωση στην τοποθεσία του οικείου κακόβουλου λογισμικού, ένας μόνο εισβολέας μπορεί να συντονίσει άμεσα εκατοντάδες χιλιάδες υπολογιστές που έχουν υποστεί βλάβη για να εκτελέσουν μια μαζική επίθεση DDoS.
Η ομορφιά της χρήσης υπολογιστών ζόμπι δεν είναι μόνο στην αποτελεσματικότητά της, αλλά και στην ανωνυμία της δεδομένου ότι ο επιτιθέμενος δεν χρειάζεται πραγματικά να χρησιμοποιήσει τον υπολογιστή του καθόλου για να εκτελέσει την επίθεση.
SQL Attack Injection
Τι είναι αυτό?
Μια επίθεση "SQL injection" (SQLI) είναι μια εκμετάλλευση που εκμεταλλεύεται τις φτωχές τεχνικές ανάπτυξης ιστού και συνήθως συνδυάζεται με ελαττωματική ασφάλεια της βάσης δεδομένων. Το αποτέλεσμα μιας επιτυχημένης επίθεσης μπορεί να κυμαίνεται από την πλαστοπροσωπία ενός λογαριασμού χρήστη σε έναν πλήρη συμβιβασμό της αντίστοιχης βάσης δεδομένων ή διακομιστή. Σε αντίθεση με μια επίθεση DDoS, μια επίθεση SQLI είναι απολύτως και εύκολα αποτρέψιμη αν μια εφαρμογή web προγραμματιστεί κατάλληλα.
Εκτελώντας την επίθεση
Κάθε φορά που συνδέεστε σε έναν ιστότοπο και εισάγετε το όνομα χρήστη και τον κωδικό πρόσβασής σας, για να ελέγξετε τα διαπιστευτήριά σας, η εφαρμογή Ιστού ενδέχεται να εκτελέσει ένα ερώτημα όπως το εξής:
ΕΠΙΛΟΓΗ αναγνωριστικού χρήστη από χρήστες WHERE Όνομα χρήστη = "myuser" ΚΑΙ κωδικός πρόσβασης = "mypass";
Σημείωση: οι τιμές των συμβολοσειρών σε ένα ερώτημα SQL πρέπει να περικλείονται σε μοναδικά εισαγωγικά και γι 'αυτό εμφανίζονται γύρω από τις τιμές που έχουν εισαχθεί από το χρήστη.
Συνεπώς, ο συνδυασμός του ονόματος χρήστη (myuser) και του κωδικού πρόσβασης (mypass) που έχουν εισαχθεί πρέπει να ταιριάζει με μια καταχώρηση στον πίνακα Χρήστες, προκειμένου να γίνει επιστροφή ενός UserID. Εάν δεν υπάρχει αντιστοιχία, δεν επιστρέφεται κανένα αναγνωριστικό χρήστη έτσι τα διαπιστευτήρια σύνδεσης δεν είναι έγκυρα. Ενώ μια συγκεκριμένη εφαρμογή μπορεί να διαφέρει, οι μηχανικοί είναι αρκετά πρότυπο.
Τώρα λοιπόν ας δούμε ένα ερώτημα ελέγχου ταυτότητας προτύπου το οποίο μπορούμε να αντικαταστήσουμε τις τιμές που εισάγει ο χρήστης στη φόρμα ιστού:
SELECT UserID από χρήστες WHERE Όνομα χρήστη = "[χρήστη]" ΚΑΙ κωδικός πρόσβασης = "[pass]"
Με την πρώτη ματιά αυτό μπορεί να φαίνεται σαν ένα απλό και λογικό βήμα για την εύκολη επικύρωση των χρηστών, ωστόσο αν γίνει απλή υποκατάσταση των τιμών που έχουν εισαχθεί από το χρήστη σε αυτό το πρότυπο, είναι επιρρεπής σε μια επίθεση SQLI.
Για παράδειγμα, ας υποθέσουμε ότι το πεδίο "myuser" εισάγεται στο πεδίο ονόματος χρήστη και εισάγεται "wrongpass" στον κωδικό πρόσβασης. Χρησιμοποιώντας απλή υποκατάσταση στο ερώτημα πρότυπου, θα πάρουμε αυτό:
SELECT UserID από χρήστες WHERE Όνομα χρήστη = "myuser" - "AND Password =" errorpass "
Το κλειδί αυτής της δήλωσης είναι η συμπερίληψη των δύο παύσεων (-). Αυτό είναι το αρχικό σχόλιο σχόλιου για τις δηλώσεις SQL, επομένως οτιδήποτε εμφανίζεται μετά τις δύο παύλες (συμπεριλαμβανομένων) θα αγνοηθεί. Ουσιαστικά, το παραπάνω ερώτημα εκτελείται από τη βάση δεδομένων ως:
SELECT UserID από χρήστες WHERE Όνομα χρήστη = "myuser"
Η καταφανής παράλειψη εδώ είναι η έλλειψη ελέγχου του κωδικού πρόσβασης. Συμπεριλαμβάνοντας τις δύο παύλες ως μέρος του πεδίου χρήστη, παρακάμπτονταν πλήρως τη συνθήκη ελέγχου κωδικού πρόσβασης και μπόρεσαν να συνδεθούν ως "myuser" χωρίς να γνωρίζουν τον αντίστοιχο κωδικό πρόσβασης. Αυτή η πράξη χειρισμού του ερωτήματος για την παραγωγή ανεπιθύμητων αποτελεσμάτων είναι μια επίθεση SQL injection.
Τι ζημιά μπορεί να γίνει?
Μια επίθεση κατά της έγχυσης SQL προκαλείται από αμέλεια και ανεύθυνη κωδικοποίηση της εφαρμογής και είναι απολύτως προληπτική (που θα καλύψουμε σε μια στιγμή), ωστόσο η έκταση της βλάβης που μπορεί να γίνει εξαρτάται από τη ρύθμιση της βάσης δεδομένων. Για να μπορεί μια εφαρμογή web να επικοινωνεί με τη βάση δεδομένων της βάσης δεδομένων, η εφαρμογή πρέπει να παρέχει μια σύνδεση στη βάση δεδομένων (σημειώστε ότι αυτό είναι διαφορετικό από τη σύνδεση χρήστη με τον ιστότοπο). Ανάλογα με τα δικαιώματα που απαιτεί η εφαρμογή web, αυτός ο αντίστοιχος λογαριασμός βάσης δεδομένων μπορεί να απαιτήσει οτιδήποτε από την άδεια ανάγνωσης / εγγραφής σε υπάρχοντες πίνακες, μόνο σε πλήρη πρόσβαση σε βάση δεδομένων. Εάν αυτό δεν είναι σαφές τώρα, μερικά παραδείγματα θα πρέπει να βοηθήσουν στην παροχή κάποιας σαφήνειας.
Με βάση το παραπάνω παράδειγμα, μπορείτε να το δείτε με την είσοδο, για παράδειγμα, "youruser" - "," admin "-" ή οποιοδήποτε άλλο όνομα χρήστη, μπορούμε να συνδεθούμε άμεσα στον ιστότοπο με αυτόν τον χρήστη χωρίς να γνωρίζουμε τον κωδικό πρόσβασης. Μόλις βρεθούμε στο σύστημα, δεν γνωρίζουμε ότι δεν είμαστε στην πραγματικότητα ο χρήστης, οπότε έχουμε πλήρη πρόσβαση στον αντίστοιχο λογαριασμό. Τα δικαιώματα βάσης δεδομένων δεν θα παρέχουν ένα δίχτυ ασφαλείας γι 'αυτό, επειδή συνήθως ένας ιστότοπος πρέπει να έχει τουλάχιστον πρόσβαση ανάγνωσης / εγγραφής στην αντίστοιχη βάση δεδομένων του.
Τώρα ας υποθέσουμε ότι ο ιστότοπος έχει τον πλήρη έλεγχο της αντίστοιχης βάσης δεδομένων του, η οποία δίνει τη δυνατότητα διαγραφής αρχείων, προσθήκης / κατάργησης πινάκων, προσθήκης νέων λογαριασμών ασφαλείας κλπ. Είναι σημαντικό να σημειωθεί ότι ορισμένες εφαρμογές web θα μπορούσαν να χρειάζονται αυτό το είδος άδειας δεν είναι αυτόματα κακό πράγμα που δίνει τον πλήρη έλεγχο.
Για να δείξουμε λοιπόν τη ζημιά που μπορεί να γίνει σε αυτή την περίπτωση, θα χρησιμοποιήσουμε το παράδειγμα που παρέχεται στο παραπάνω κόμικ εισάγοντας το παρακάτω στο πεδίο ονόματος χρήστη: "Robert", Χρήστες DROP TABLE, - ". Μετά απλή υποκατάσταση το ερώτημα ελέγχου ταυτότητας γίνεται:
SELECT UserID από χρήστες WHERE UserName = "Robert"; ΠΙΝΑΚΑΣ ΠΤΗΣΕΩΝ Χρήστες - 'AND Password =' errorpass '
Σημείωση: το ερωτηματικό σε ερώτημα SQL χρησιμοποιείται για να δηλώσει το τέλος μιας συγκεκριμένης αναφοράς και την αρχή μιας νέας δήλωσης.
Που εκτελείται από τη βάση δεδομένων ως:
SELECT UserID από χρήστες WHERE Όνομα χρήστη = "Robert"ΠΙΝΑΚΑΣ DROP Χρήστες
Έτσι λοιπόν, χρησιμοποιήσαμε μια επίθεση SQLI για να διαγράψουμε ολόκληρο τον πίνακα χρηστών.
Φυσικά, πολύ χειρότερο μπορεί να γίνει γιατί, ανάλογα με τα επιτρεπόμενα δικαιώματα SQL, ο εισβολέας μπορεί να αλλάξει τιμές, να καταργήσει πίνακες (ή ολόκληρη την ίδια τη βάση δεδομένων) σε ένα αρχείο κειμένου, να δημιουργήσει νέους λογαριασμούς σύνδεσης ή ακόμα και να διαστρέψει ολόκληρη την εγκατάσταση της βάσης δεδομένων.
Αποτροπή επίθεσης SQL injection
Όπως αναφέραμε αρκετές φορές προηγουμένως, μια επίθεση SQL injection είναι εύκολο να αποφευχθεί. Ένας από τους βασικούς κανόνες της ανάπτυξης ιστοσελίδων είναι ότι ποτέ δεν εμπιστεύεστε τυφλά την είσοδο χρηστών όπως κάναμε όταν πραγματοποιήσαμε απλή υποκατάσταση στο ερώτημα πρότυπου παραπάνω.
Μια επίθεση SQLI μπορεί εύκολα να αποτραπεί από αυτό που ονομάζεται απολύμανση (ή διαφυγή) των εισροών σας. Η διαδικασία εξυγίανσης είναι στην πραγματικότητα αρκετά ασήμαντη, καθώς το μόνο που κάνει ουσιαστικά είναι να χειριστεί κάθε ενσωματωμένο μοναδικό απόσπασμα (') χαρακτήρες κατάλληλα έτσι ώστε να μην μπορεί να χρησιμοποιηθεί για πρόωρη τερματισμό μιας συμβολοσειράς μέσα σε μια δήλωση SQL.
Για παράδειγμα, αν θελήσατε να αναζητήσετε "O'neil" σε μια βάση δεδομένων, δεν θα μπορούσατε να χρησιμοποιήσετε απλή αντικατάσταση επειδή το μοναδικό απόσπασμα μετά το O θα προκαλούσε πρόωρο τερματισμό της συμβολοσειράς. Αντ 'αυτού καθαρίστε το χρησιμοποιώντας τον χαρακτήρα διαφυγής της αντίστοιχης βάσης δεδομένων. Ας υποθέσουμε ότι ο χαρακτήρας διαφυγής για ένα ενιαίο εισαγωγικό quote προφέρεται σε κάθε απόσπασμα με ένα σύμβολο \. Έτσι, το "O'neal" θα καθαριζόταν ως "O 'Neil".
Αυτή η απλή πράξη εξυγίανσης αποτρέπει αρκετά μια επίθεση SQLI. Για να το δείξουμε, ας επανεξετάσουμε τα προηγούμενα παραδείγματα μας και να δούμε τα ερωτήματα που προκύπτουν από την απολύμανση των εισροών του χρήστη.
myuser '-- / / errorpass:
ΕΠΙΛΟΓΗ αναγνωριστικού χρήστη από χρήστες WHERE Όνομα χρήστη = "myuser \" - 'AND Password = "errorpass"
Επειδή το μοναδικό απόσπασμα μετά από το myuser διαφεύγει (που σημαίνει ότι θεωρείται μέρος της τιμής στόχου), η βάση δεδομένων θα αναζητήσει κυριολεκτικά το UserName του "myuser" - ". Επιπλέον, επειδή οι παύλες περιλαμβάνονται στην τιμή συμβολοσειράς και όχι στην ίδια τη δήλωση SQL, θα θεωρηθούν μέρος της τιμής στόχου αντί να ερμηνευτούν ως σχόλιο SQL.
Ροβέρτος'; ΠΙΝΑΚΑΣ DROP Χρήστες;-- / / errorpass:
SELECT UserID από χρήστες WHERE Όνομα χρήστη = "Robert \"; ΠΙΝΑΚΑΣ ΠΤΗΣΕΩΝ Χρήστες - 'AND Password =' errorpass '
Απλώς διαφεύγοντας το μοναδικό απόσπασμα μετά από τον Robert, τόσο το ερωτηματικό όσο και οι παύλες περιλαμβάνονται μέσα στη συμβολοσειρά αναζήτησης UserName, έτσι ώστε η βάση δεδομένων θα αναζητήσει κυριολεκτικά "Robert", Χρήστες DROP TABLE, - " αντί να εκτελέσετε τον πίνακα διαγραφής.
Συνοψίζοντας
Ενώ οι επιθέσεις web εξελίσσονται και γίνονται πιο εξελιγμένες ή επικεντρώνονται σε διαφορετικό σημείο εισόδου, είναι σημαντικό να θυμόμαστε να προστατεύουμε από δοκιμασμένες και αληθινές επιθέσεις που έχουν εμπνευστεί από πολλά ελεύθερα διαθέσιμα "εργαλεία χάκερ" που έχουν σκοπό να τα εκμεταλλευτούν.
Ορισμένοι τύποι επιθέσεων, όπως το DDoS, δεν μπορούν εύκολα να αποφευχθούν, ενώ άλλοι, όπως το SQLI, μπορούν. Ωστόσο, η ζημιά που μπορεί να προκληθεί από αυτά τα είδη επιθέσεων μπορεί να κυμανθεί οπουδήποτε από μία ταλαιπωρία σε καταστροφική, ανάλογα με τις προφυλάξεις που λαμβάνονται.
