Στον συναρπαστικό κόσμο της ψηφιακής εποχής μας, η ασφάλεια των υπολογιστικών συστημάτων αποτελεί καίρια πρόκληση. Μια από τις πιο σοβαρές απειλές που κυνηγούν την ασφάλεια των δικτύων και των συσκευών είναι η επίθεση RCE (Remote Code Execution). Σε αυτό το άρθρο, θα ρίξουμε μια ματιά στη φύση της επίθεσης RCE και τους διάφορους τρόπους με τους οποίους μπορεί να χρησιμοποιηθεί.
Τι Είναι η Επίθεση RCE;
Η επίθεση RCE (Remote Code Execution) αναφέρεται στην ευκαιρία του επιτιθέμενου να εκτελέσει κώδικα σε απομακρυσμένο υπολογιστή ή συσκευή, χωρίς την έγκριση ή την αντίληψη του νόμιμου χρήστη. Αυτό σημαίνει ότι ο επιτιθέμενος αποκτά απόλυτο έλεγχο στον στόχο του, ανοίγοντας την πόρτα για πολλούς επικίνδυνους σκοπούς.
Πού Χρησιμοποιείται η Επίθεση RCE;
Οι επιθέσεις RCE μπορούν να εμφανιστούν σε πολλούς τομείς, επηρεάζοντας τόσο τον ατομικό όσο και τον επιχειρηματικό ψηφιακό χώρο:
Κρατικά και Κυβερνητικά Συστήματα: Κυβερνήσεις και κράτη μπορούν να χρησιμοποιήσουν την RCE για να εισέλθουν σε απομακρυσμένους υπολογιστές ή συστήματα για σκοπούς κατασκοπίας, παρακολούθησης ή κυβερνητικού χειρισμού.
Κλοπή Δεδομένων: Κακόβουλοι εισβολείς μπορούν να αξιοποιήσουν την RCE για να προσπελάσουν ευαίσθητα δεδομένα, όπως προσωπικές πληροφορίες, επιχειρηματικά μυστικά και πιστωτικές πληροφορίες.
Διασπορά Κακόβουλου Λογισμικού: Οι επιθέσεις RCE μπορούν να χρησιμοποιηθούν για τη διάδοση κακόβουλου λογισμικού, όπως ιοί και malware, σε μεγάλη κλίμακα.
Απορρόφηση Υπολογιστικών Πόρων: Οι εισβολείς μπορούν να χρησιμοποιήσουν RCE για να εξαντλήσουν τους πόρους ενός συστήματος, καθιστώντας το ανίκανο να λειτουργήσει ή να ανταποκριθεί.
Επιθέσεις DDoS: Οι επιθέσεις RCE μπορούν να χρησιμοποιηθούν ως μέρος της προετοιμασίας και της διεξαγωγής επιθέσεων DDoS (Distributed Denial of Service). Σε αυτές τις επιθέσεις, οι επιτιθέμενοι χρησιμοποιούν RCE για να ανακτήσουν τον έλεγχο των συσκευών ή των υπολογιστών που στη συνέχεια χρησιμοποιούν για να προβούν σε συντονισμένες επιθέσεις DDoS, κατακλύζοντας στόχους με αιτήσεις και απενεργοποιώντας τους.
Πώς Προστατεύουμε τον Εαυτό μας από την Επίθεση RCE;
Η προστασία από τις επιθέσεις RCE απαιτεί συνεχή προσοχή και προληπτικά μέτρα. Εδώ είναι μερικές βασικές συμβουλές για να προστατευτείτε:
Ενημερώστε το Λογισμικό σας: Ενημερώστε συστηματικά το λογισμικό σας, συμπεριλαμβανομένου του λειτουργικού συστήματος, των εφαρμογών και του αντικακοπτή. Οι ενημερώσεις συνήθως περιλαμβάνουν διορθώσεις ευπαθειών που μπορούν να εκμεταλλευτούν οι επιτιθέμενοι.
Προστασία Κωδικών και Προνομίων: Χρησιμοποιήστε δυνατούς κωδικούς πρόσβασης και περιορίστε τις προνομίες που δίνετε στους λογαριασμούς σας. Εφαρμόστε αρχές αρχής λιγότερων προνομίων (Least Privilege) για να περιορίσετε τον έλεγχο που έχουν οι χρήστες.
Χρήση Φιλτράρισματος και Ανίχνευσης: Εγκαταστήστε λύσεις φιλτραρίσματος και ανίχνευσης εισβολών για να εντοπίζετε και να προλαμβάνετε ανομαλίες στην κίνηση του δικτύου και των συστημάτων.
Εκπαίδευση του Προσωπικού: Εκπαιδεύστε το προσωπικό σας σχετικά με τις απειλές και τις βασικές ασφαλείς πρακτικές, ώστε να αναγνωρίζουν και να αντιδρούν σε πιθανές επιθέσεις.
Εφαρμογή Κρυπτογραφίας: Χρησιμοποιήστε ισχυρές κρυπτογραφικές μεθόδους για την προστασία των επικοινωνιών σας και των δεδομένων σας.
Στενός Έλεγχος των Εισόδων: Εφαρμόστε αυστηρό έλεγχο των εισόδων στο δίκτυο και τους διακομιστές σας, ώστε να αποτρέψετε τις ανεπιθύμητες προσπάθειες εισβολής.
Η προστασία από τις επιθέσεις RCE απαιτεί συνεχή παρακολούθηση, εκπαίδευση και εφαρμογή των προληπτικών μέτρων. Επίσης, αξίζει να λαμβάνετε υπόψη ότι η ασφάλεια είναι ένας διαρκώς εξελισσόμενος τομέας, και οι επιθέσεις RCE μπορεί να γίνουν πιο εξειδικευμένες και εκσυγχρονισμένες με την πάροδο του χρόνου.
Τέλος, η συνεργασία με αξιόπιστους ειδικούς ασφαλείας πληροφοριών (SOC) και η διατήρηση ενός ενεργού σχεδίου αντίδρασης σε περίπτωση επίθεσης είναι ζωτικής σημασίας για την αντιμετώπιση των απειλών της επίθεσης RCE. Με συνεχή επιτήρηση και ενημέρωση, μπορείτε να είστε προετοιμασμένοι και να προστατεύσετε αποτελεσματικά τον ψηφιακό σας χώρο από αυτήν την αόρατη, αλλά θανάσιμη απειλή.
Το Metasploit είναι ένα από τα πιο ισχυρά και δημοφιλή εργαλεία στον κόσμο της κυβερνοασφάλειας. Πρόκειται για ένα πλαίσιο ασφαλείας που χρησιμοποιείται για τη δοκιμή ασφάλειας συστημάτων και εφαρμογών. Αναπτύχθηκε αρχικά από την Rapid7 και τώρα είναι διαθέσιμο ως ανοικτού κώδικα λογισμικό.
Το Metasploit επιτρέπει στους ερευνητές ασφάλειας, τους επαγγελματίες κυβερνοασφάλειας και ακόμη και τους επιτιθέμενους να εκμεταλλευτούν ασφαλιστικές ελλείψεις σε συστήματα και εφαρμογές. Με τη χρήση του Metasploit, μπορείτε να ελέγξετε την ασφάλεια του συστήματός σας, να εντοπίσετε τυχόν ευπάθειες και να αναπτύξετε εκμεταλλευτικές επιθέσεις για να τις επιλύσετε προτού κακόβουλοι επιτιθέμενοι τις εκμεταλλευτούν.
Η χρήση του Metasploit περιλαμβάνει τα ακόλουθα βήματα:
Επιλογή Στόχου: Αρχικά, πρέπει να επιλέξετε τον στόχο που θέλετε να δοκιμάσετε ή να ελέγξετε την ασφάλειά του. Αυτό μπορεί να είναι ένας διακομιστής, μια εφαρμογή ή ακόμη και ένας υπολογιστής.
Σάρωση: Το Metasploit μπορεί να εκτελέσει σάρωση του στόχου για ευπάθειες και ανοιχτές πόρτες. Αυτό βοηθάει στην εντοπισμό πιθανών ευκαιριών για επίθεση.
Επίθεση: Με βάση τις ευπάθειες που ανακαλύψατε, μπορείτε να χρησιμοποιήσετε το Metasploit για να εκτελέσετε επιθέσεις. Αυτές μπορεί να είναι εκμεταλλευτικές επιθέσεις, όπως εισβολές σε αυτό το σύστημα ή την εφαρμογή.
Αξιολόγηση: Μετά την επίθεση, αξιολογείτε την αποτελεσματικότητα της και τυχόν πληροφορίες που αποκτήσατε.
Αναφορά: Το Metasploit παρέχει εκτενείς αναφορές και καταγραφές των επιθέσεών σας, κάτι που είναι σημαντικό για την κυβερνοασφάλεια και την επίλυση τυχόν ευπαθειών.
Το Metasploit είναι ένα εξαιρετικά χρήσιμο εργαλείο για τη δοκιμή ασφάλειας και την προστασία των συστημάτων από κυβερνοεπιθέσεις. Ωστόσο, πρέπει να χρησιμοποιείται με προσοχή, καθώς η ανοικτή χρήση του χωρίς την ανάλογη εξουσιοδότηση είναι παράνομη.
Για να χρησιμοποιήσετε το Metasploit με ασφάλεια και νοηματική ευθύνη, είναι σημαντικό να έχετε την άδεια και την εξουσιοδότηση για να δοκιμάσετε την ασφάλεια των συστημάτων ή των εφαρμογών που ανήκουν σε εσάς ή σε εκείνους που έχετε τη συγκατάθεσή τους. Πάντα πρέπει να τηρείτε τους νόμους περί κυβερνοασφάλειας και ιδιωτικότητας.
Εν κατακλείδι, το Metasploit είναι ένα εξαιρετικά ισχυρό εργαλείο για την ανίχνευση ευπαθειών και τη δοκιμή ασφάλειας. Ωστόσο, πρέπει να χρησιμοποιείται με προσοχή, ευθύνη και σεβασμό προς τους νόμους και την ιδιωτικότητα των άλλων. Με την κατάλληλη εκπαίδευση και τον ηθικό προσανατολισμό, μπορεί να συμβάλει στην ενίσχυση της κυβερνοασφάλειας και την προστασία από δυνητικούς κινδύνους στον ψηφιακό κόσμο.
Εκατομμύρια επιθέσεις ανά τον κόσμο, γίνονται καθημερινά από κακόβουλους «χάκερ» οι οποίοι θέλουν να υποκλέψουν προσωπικά δεδομένα από χρήστες.
Τις περισσότερες φορές πιστεύουμε πως αν η συσκευή μας είναι ασφαλής, τότε είμαστε και εμείς. Ωστόσο αυτό δεν ισχύει, διότι το μεγαλύτερο θύμα δεν είναι ένα σύστημα, αλλά ο άνθρωπος.
Γιατί όμως είναι ο άνθρωπος και τι κινήσεις μπορούμε να κάνουμε για να είμαστε έστω και λίγο ασφαλής;
Ας μιλήσουμε λοιπόν για τις επιθέσεις «ψαρέματος» γνωστές και ως phishing.
ΤΙ ΕΙΝΑΙ ΤΟ PHISHING?
Η μέθοδος phishing είναι αρκετά γνωστή και χρησιμοποιείται πολύ συχνά από τους «χάκερ». Σίγουρα θα σας έχει σταλεί μήνυμα στο κινητό σας τηλέφωνο από την δήθεν Εθνική Τράπεζα, από το δήθεν ταχυδρομείο για να παραλάβετε το δέμα σας, και άλλα πολλά.
Ο σκοπός λοιπόν του επιτιθέμενου είναι να σας προσελκύσει να πατήσετε τον σύνδεσμο, έτσι ώστε να ανακατευθυνθείτε σε μία σελίδα ΚΛΩΝΟ της ανάλογης official ιστοσελίδας που έχει χρησιμοποιήσει ο χάκερ, να βάλετε τα στοιχεία σας και να προσπαθήσει να πάρει πρόσβαση στους λογαριασμούς σας.
Επίσης ο επιτιθέμενος έχει την δυνατότητα, να σας επισυνάψει ένα αρχείο στέλνοντας στο email σας με το οποίο θα μπορεί να πάρει απομακρυσμένη μη εξουσιοδοτημένη πρόσβαση στην συσκευή σας. Αφού λοιπόν εσύ ανοίξεις το αρχείο, ξεκινάει και το «παιχνίδι» του χάκερ. Παίρνοντας πρόσβαση στην συσκευή σου θα μπορεί με λίγες απλές εντολές να κάνει κάποια βασικά πράγματα όπως: Να ανοίξει την κάμερα σου live, να ηχογραφήσει από το μικρόφωνο, να κατεβάσει αρχεία στην δική του συσκευή και με την ησυχία του μετά να κάτσει να τα επεξεργαστεί ή να «ανεβάσει» αρχεία στην δική σου συσκευή και άλλα πολλά και διάφορα.
ΠΩΣ ΜΠΟΡΩ ΝΑ ΠΡΟΣΤΑΤΕΥΤΩ;
Δεν μπορούμε να εγγυηθούμε πως υπάρχει 100% ασφάλεια για κανέναν λόγο. Το πιο δυνατό σύστημα να έχεις και ο πιο έξυπνος άνθρωπος να είσαι, πάντα θα υπάρξει αυτό το κενό ασφαλείας. Είτε στο σύστημα σου, είτε από την απροσεξία σου.
Όμως, μπορούμε να κάνουμε κάποιες ενέργειες έτσι ώστε να αποφύγουμε κάθε είδους επίθεση phishing. Δεν ανοίγουμε ποτέ συνδέσμους από email, sms τα οποία μας φαίνονται άγνωστα ή περίεργα. Πάντα ελέγχουμε το link να δούμε αν είναι official και από εκεί κρίνουμε αν θα το ανοίξουμε ή όχι.
Δεν ανοίγουμε αρχεία για κανέναν λόγο τύπου (Αφαιρέθηκαν από τον λογαριασμό σας 1.000 ευρώ, κάνε κλικ στο PDF αρχείο για να δεις αναλυτικά) κ.τ.λ.
Μπορεί επίσης κάποιος να παριστάνει κάποιον φίλο σας. Η καλύτερη λύση εκεί ποιά είναι λοιπόν; Όχι πάντως να του στείλετε μήνυμα, αλλά να τον πάρετε κλήση και να τον ρωτήσετε αν ο ίδιος σας έστειλε το αρχείο. Διότι μπορεί ο κακόβουλος χάκερ να έχει φτιάξει ένα παρόμοιο email (ελέγχουμε πολύ καλά τα email) ή να έχει εισβάλει στον λογαριασμό του φίλου σας και να σας στέλνει διάφορα.
ΒΟΗΘΑΕΙ ΤΟ ΝΑ ΕΧΩ ANTIVIRUS ΑΝ ΤΥΧΩΝ ΑΝΟΙΞΩ ΚΑΚΟΒΟΥΛΟ ΑΡΧΕΙΟ;
Εννοείται βοηθάει αλλά όχι σε όλες τις περιπτώσεις. Διότι πλέον υπάρχουν αρκετά προγράμματα τα οποία περνάνε εύκολα το firewall, είτε το ακυρώνουν τελείως με την έναρξη τους.
ΠΩΣ ΜΠΟΡΩ ΝΑ ΔΩ ΑΝ ΕΝΑΣ ΣΥΝΔΕΣΜΟΣ ΕΙΝΑΙ ΚΑΚΟΒΟΥΛΟΣ;
Λοιπόν. Εδώ γίνονται λίγο περίεργα τα πράγματα. Έχουμε ακούσει αρκετές φορές την καραμέλα «Μην βάζετε τα στοιχεία σας στους συνδέσμους». Ωστόσο λίγοι έχουν μιλήσει για το cookie stealing. Τα cookies ουσιαστικά περιέχουν κάποιες πληροφορίες σχετικά με τις συνδέσεις σου και κάποιες άλλες πληροφορίες πάνω στο browser. Δεν θα αναλύσουμε σε αυτό το άρθρο τι είναι ακριβώς αλλά καλό θα ήταν αν σας φαίνεται άγνωστος αυτός που σας στέλνει το μήνυμα να μην το ανοίγεται διότι έστω και με ένα άνοιγμα μπορεί να γίνει υποκλοπή των cookies και να πάρουν πληροφορίες από το Browser σας. (Αν γνωρίζεις κάτι παραπάνω από υπολογιστές και θες να ανοίξεις σύνδεσμο, σου προτείνουμε το burpsuite).
Αν βλέπετε «περίεργη» την διεύθυνση URL , τότε κάτι πάει λάθος. Π.χ πες ότι ο επιτιθέμενος θέλει να σε πείσει ότι είναι από την Εθνική. (Το official site της εθνικής είναι www.nbg.gr) ο επιτιθέμενος λοιπόν μπορεί να έχει τον σύνδεσμο ως εξής “www.nbgg.com.gr”. Μπορείτε να διακρίνετε και μόνοι σας τις διαφορές.
Για το κλείσιμο θα θέλαμε να σας ενημερώσουμε πως δεν είστε μόνοι σας, την έχουμε πατήσει και εμείς όπως και όλοι. Όπως είπαμε και πριν, ο πιο έξυπνος άνθρωπος να είσαι ή ο καλύτερος προγραμματιστής ή ακόμα και χάκερ, υπάρχει περίπτωση να πέσεις στην παγίδα.
Η WordPress κυκλοφόρησε αυτήν την εβδομάδα μια ενημέρωση ασφαλείας προκειμένου να διορθώσει μια ευπάθεια εκτέλεσης κώδικα απομακρυσμένου (RCE).
Χρησιμοποιώντας σε συνδυασμό με ένα άλλο ελάττωμα, οι χάκερ θα μπορούσαν να εκτελέσουν αυθαίρετο κώδικα PHP σε έναν ιστότοπο του WordPress και καθώς σχεδόν το μισό διαδίκτυο θεωρείται ότι τρέχει σε WordPress, η επιφάνεια επίθεσης είναι αρκετά ευρεία.
Στην ανακοίνωσή της, η WordPress σημειώνει ότι το σφάλμα RCE δεν είναι απευθείας εκτελέσιμο στον πυρήνα, αλλά που, σε συνδυασμό με ορισμένα πρόσθετα, ενδέχεται να συνιστά υψηλό κίνδυνο.
Το σφάλμα RCE επιδιορθώθηκε στην έκδοση WordPress 6.4.2. Συνιστάται στους ιδιοκτήτες και τους διαχειριστές ιστότοπων να ενημερώσουν στην επιδιορθωμένη έκδοση του CMS το συντομότερο δυνατό.
“Ενώ οι περισσότεροι ιστότοποι θα πρέπει να ενημερωθούν αυτόματα στο WordPress 6.4.2, συνιστούμε ιδιαίτερα τον χειροκίνητο έλεγχο του ιστότοπό σας για να εξασφαλίσετε ότι έχει γίνει η ενημέρωση”, σημειώνει η Wordfence.
Κυβερνοεπίθεση Στο Δικαστικό Σύστημα της Ελβετίας: Πιθανή Επίθεση Ransomware
Ένα δικαστικό σύστημα στην Ελβετία ανακοίνωσε την Τρίτη ότι έχει πληγεί από μια κυβερνοεπίθεση.
Το δικαστήριο, που βρίσκεται στη γερμανόφωνη περιοχή του Μαρτς στην κεντρική Ελβετία, εξυπηρετεί περίπου 45.000 άτομα.
Αν και η φύση της επίθεσης δεν έχει αποκαλυφθεί πλήρως, μια περιορισμένη περιγραφή στην ιστοσελίδα του δικαστηρίου υποδεικνύει ότι πιθανότατα πρόκειται για μια επίθεση ransomware. “Κλείσαμε προσωρινά ολόκληρο το πληροφορικό σύστημα για να προστατέψουμε τα δεδομένα. Προς το παρόν, δεν υπάρχει σαφής χρονικός ορίζοντας για την επαναφορά του, αλλά η διαδικασία μπορεί να διαρκέσει αρκετές ημέρες”, αναφέρει η ιστοσελίδα.
Οι τηλεφωνικές γραμμές του δικαστηρίου είναι προσωρινά εκτός λειτουργίας, αλλά προγραμματισμένες ακροάσεις αναμένεται να πραγματοποιηθούν σύμφωνα με το πρόγραμμα.
Αυτή η κυβερνοεπίθεση ακολουθεί μια παρόμοια επίθεση ransomware στη δημοτική διοίκηση του Zollikofen, προαστίου της Βέρνης, τον Νοέμβριο.
Σύμφωνα με την ελβετική εφημερίδα Inside IT, οι επιτιθέμενοι κρυπτογράφησαν τα δεδομένα διαχείρισης κατά τη διάρκεια της επίθεσης, με τις αρχές να αποσυνδέουν τα δίκτυα ως προληπτικό μέτρο.
Η κυβερνοεπίθεση μπορεί να έχει σοβαρές συνέπειες στη λειτουργία του δικαστικού συστήματος. Η διακοπή της πρόσβασης σε σημαντικά δεδομένα και αρχεία μπορεί να απειλήσει την ακεραιότητα των πληροφοριών και να δυσκολέψει την απονομή δικαιοσύνης. Αυτό μπορεί να οδηγήσει σε καθυστερήσεις ή ακόμη και ακυρώσεις δικαστικών διαδικασιών, με σοβαρές επιπτώσεις για τη δικαιοσύνη και την εμπιστοσύνη του κοινού.
Επιπλέον, μια κυβερνοεπίθεση μπορεί να προκαλέσει τη διαρροή ευαίσθητων πληροφοριών, θέτοντας σε κίνδυνο την ιδιωτικότητα και την ασφάλεια των ατόμων που συμμετέχουν σε δικαστικές διαδικασίες, με σοβαρές επιπτώσεις για τους ενδιαφερόμενους.
Στις μέρες μας πολλοί άνθρωποι συνήθισαν πλέον να έχουν ένα προσωπικό τους Email για να μιλάνε με δικά τ ους πρόσωπα ακόμα και για να έχουν κάποια μέσα κοινωνικά δικτύωσης σκεφτήκατε ποτέ όμως ότι αυτό μπορεί να γίνει και ένα ολοζώντανο σενάριο Ηλεκτρονικής παραβίασης; Όχι φυσικά. Οπότε ας πάμε να το αναλύσουμε όσο ποιο πολύ μπορούμε.
Τι είναι ένα Email Spoofing? Ορισμός : Email spoofing είναι η δημιουργία των μηνυμάτων ηλεκτρονικού ταχυδρομείου με πλαστή διεύθυνση αποστολέα.
Ουσιαστικά οι spammers ηλεκτρονικού ταχυδρομείου που χρησιμοποιούν Email Spoofing για να ξεγελάσουν τα θύματά τους ώστε να πιστέψουν ότι ο αποστολέας είναι κάποιος, ο οποίος δεν είναι στην ουσία . Ένα παράδειγμα θα ήταν αν κάποιος στείλει ένα μια επίσημη φόρμα στο θύμα τους, ισχυρίζοντας ότι είναι από το Facebook, με σκοπό την κλοπή και παραπλάνηση του ατόμου.
Πόσα άτομα πέφτουν στην απάτη αυτή καθημερινά?
Μπορώ να σας πω ότι μέσα από την πείρα χρόνων που έχω τα άτομα τα οποία έχουν πέσει θύμα σε αυτές τις επιθέσεις ξεπερνάνε τις χιλιάδες σε παγκόσμια εμβέλεια καθημερινός.
Για ποιους λόγους χρησιμοποιείτε το Email Spoofing?
1. Για να τους κάνετε να τρέξουν κάποιο κακόβουλο λογισμικό δικό σας ( Στην περίπτωση μου έκανα τα θύματα να τρέχουν Meterpreters ) 2. Να κάνουν επίσκεψη σε μία σελίδα που θέλετε εσείς ( Λογικά για τα Views Per Click η για να προσαρμόσετε κάποιο Cookie Stealer / Session Hijack ) 3. Να πληροφορήσετε το θύμα σας με εσφαλμένες πληροφορίες ( Π.Χ ότι κάποιος γνωστός τους απεβίωσε για δικούς σας λόγους πάντα ) 4. Ηλεκτρονικό Ψάρεμα / Υποκλοπές
Το Email spoofing είναι ένας ισχυρός σύμμαχος, αν χρησιμοποιηθεί σωστά μπορείτε να χειραγωγήσετε όποιον θέλετε.
Αυτά είναι τα 4 βασικά στοιχεία που αποτελούν την δομή του Email Spoofing.
Ας ξεκινήσουμε λοιπόν στην σύνθεση του.
Η γλώσσα PhP είναι μια πολύ δυνατή γλώσσα μέσω αυτής μπορούμε να δημιουργήσουμε έναν απλό τύπου Email Spoofing σε php και να το ανεβάσουμε σε κάποια σελίδα δικιά μας,το θέμα μας εδώ είναι ότι κάθε πράγμα που θα αποστείλουμε μέσω του Script θα πάει κατευθείαν στο Spam Folder λόγο του ότι το gmail έχει παραμέτρους για τέτοια Script και τα φιλτράρει οπότε θα βρούμε μια μέθοδο προσπέλασης ας αρχίσουμε λοιπόν.
Θα πρέπει να κάνουμε έναν λογαριασμό αρχικά στο ManDrill από εδώ
https://mailchimp.com/
Προτού πάω παρακάτω θα πω τι είναι το ManDrill.Tο ManDrill είναι ένα Web Based Email Spooder που μας επιτρέπει να αποστείλουμε Email χωρίς το φίλτρο να καταλάβει ότι είναι κακόβουλο το Script με αποτέλεσμα να πάει κατευθείαν στο inbox του προορισμό που ορίσαμε. Ας συνεχίσουμε λοιπόν.
Μόλις κάνετε τον λογαριασμό θα πάτε στην μπάρα πάνω στην αριστερή πλευρά σας και θα επιλέξετε την επιλογή “OutBound” και θα πατήσετε “Compose Message” για όσους δεν κατάλαβαν που πρέπει να πάτε παραθέτω και μία εικόνα
Αμέσως μετά θα σας λέει να συμπληρώσετε στοιχεία αποστολέα και email ακόμα και το μήνυμα θα σας εξηγήσω τι βάζετε ακριβώς. – Από Email / From Email : Η διεύθυνση ηλεκτρονικού ταχυδρομείου που θέλετε να εμφανίζεται από όπου προήλθε το email π.χ μπορείτε να βάλετε από της αστυνομίας η από όποιον οργανισμό θέλετε. – Για Email / Τo Email : η διεύθυνση ηλεκτρονικού ταχυδρομείου που θέλετε το μήνυμα σύνθεσής σας που πρόκειται να παραδοθεί π.χ στον φίλο σας. – Θέμα / Subject : Εδώ βάζετε καθαρά το Θέμα που θα έχει το μήνυμα π.χ ” Facebook Support ” – Και το μεγάλο λευκό κείμενο : Είναι για να κάνετε σύνταξη του μηνύματος που θέλετε να στείλετε στο θύμα σας.
Παραθέτω μια εικόνα για το πως είναι.
Το ποιο σημαντικό κομμάτι είναι να κάνετε το Email σας να είναι πραγματικό οπότε μην ξεχάσετε να εφαρμόσετε και μερικά HTML Elements τι εννοώ με αυτό; Μπορείτε να πλαστογραφήσετε ένα ολόκληρο μήνυμα που σας στείλανε και να το βάλετε στην φόρμα σας κανονικό περιεχόμενο με αλλαγμένους τους σύνδεσμους.
Παραθέτω μια εικόνα.
Μόλις τα έχετε όλα έτοιμα πατήστε ” Send / Αποστολή ”
Το μήνυμα θα έρθει στο θύμα μας μέσα σε μερικά λεπτά και θα είναι στο Inbox του.
Παραθέτω εικόνα του τελικού προϊόντος.
Τελευταίο και καλύτερο από όλα το ManDrill έχει την δυνατότητα να ξέρει πότε ο χρήστης έκανε κλίκ στο Email που το στείλαμε! Οπότε θα είστε ενημερωμένη πάντα αν το έλαβε και αν το διάβασε και δεν έπεσε θύμα.
Το συγκεκριμένο άρθρο είναι το πρώτο μέρος μιας σειράς που θα περιγράψει την αδυναμία Buffer Overflow. Σε αυτό το πρώτο μέρος, θα δώσουμε την απαιτούμενη (στοιχειώδη) γνώση ή σε απλά Ελληνικά: “το απαιτούμενο background”, που χρειάζεται σε κάποιον, ώστε να μπορέσει κατανοήσει τον βαθύτερο λόγο που μπορεί να συμβεί μια τέτοια επίθεση, ώστε να μπορέσει να εφαρμόσει μέτρα (ακόμα και ο ίδιος) μήπως και καταφέρει να μειώσει την πιθανότητα υλοποίησης αυτής της απειλής.
Κάθε εφαρμογή που τρέχουμε στον υπολογιστή μας όσο απλή ή σύνθετη κι αν είναι γράφτηκε από κάποιον προγραμματιστή. Οι αρχές εκτέλεσης ενός προγράμματος είτε πρόκειται για το ίδιο το λειτουργικό σύστημα είτε για ένα ταπεινό πρόγραμμα πρόσθεσης δύο αριθμών είναι παρόμοιες ή σχεδόν παρόμοιες.
Πρώτα απ’ όλα έχουμε το πρόγραμμα που φτιάχνει ο προγραμματιστής το οποίο αποτελείται από εντολές κατανοητές μόνο από ανθρώπους και ονομάζεται πηγαίος κώδικας ή απλά κώδικας. Αυτός ο κώδικας λοιπόν περνάει από μια ειδική επεξεργασία από άλλα προγράμματα που ονομάζονται μεταφραστές (compilers) ή διερμηνευτές (interpreters) για να μεταφραστεί σε κάτι που είναι κατανοητό μόνο (μόνο; Χμ, τέλος πάντων) από τον επεξεργαστή του υπολογιστή μας.
Θα μας πείτε τώρα ποια η διαφορά ενός compiler από έναν interpreter. Χμ, αρκετά μεγάλη: Οι compilers μεταφράζουν όλο τον πηγαίο κώδικα και παράγουν ένα νέο πρόγραμμα που ονομάζεται εκτελέσιμο (το γνωστό exe ή com). Το εκτελέσιμο αρχείο αποτελείται από εντολές μηχανής (όπως λέγονται) και που αντιστοιχούν σε αυτές που γράφτηκαν στον πηγαίο κώδικα. Είναι αυτό το αρχείο που όταν εκτελεστεί θα υλοποιήσει τις εντολές του αντίστοιχου πηγαίου του κώδικα. Μεταγλωττιστές χρησιμοποιούνται συνήθως για να μεταφράσουν κώδικα σε γλώσσες όπως οι C, C++, Pascal, κλπ.
Οι διερμηνευτές (interpreters) από την άλλη, μεταφράζουν τον πηγαίο κώδικα εντολή-εντολή: Τον διαβάζουν στην μνήμη και τον εκτελούν (συνήθως) γραμμή – γραμμή. Δεν παράγουν (…πάντα) κάποιο εκτελέσιμο αρχείο, αφού ο ίδιος ο πηγαίος κώδικας μεταφράζεται και εκτελείτε εκείνη την χρονική στιγμή που διαβάζεται. Διερμηνευτές υπάρχουν για τις γνωστές γλώσσες ανάπτυξης web εφαρμογών όπως η PHP και η ASP.
Η κάθε μια προσέγγιση φυσικά έχει τα καλά της και τα κακά της: Συνήθως τα προγράμματα που έχουν προέλθει από κάποιον compiler είναι πολύ πιο γρήγορα και απαλλαγμένα από συντακτικά λάθη που μπορεί να έκανε ο προγραμματιστής όταν τα έφτιαχνε. Αυτό το τελευταίο ισχύει διότι η συντακτικός έλεγχος γίνεται όταν παράγεται το εκτελέσιμο και αν βρεθεί λάθος, εκτελέσιμο δεν έχει! 😉 Επίσης το εκτελέσιμο είναι (λέμε τώρα…!! πολύ δύσκολο να διαβαστεί από κάποιον τρίτο ο οποίος θα προσπαθήσει (για οποιονδήποτε λόγο) να «κλέψει» τον κώδικα που έγραψε ο προγραμματιστής. Από την άλλη μεριά τα προγράμματα που περνάνε από διερμηνευτές είναι πολύ πιο εύκολα στην συντήρηση, αφού δεν απαιτείται η διαδικασία του compilation (όπως λέγεται) ούτε και απαιτείται κάποιο ξεχωριστό εκτελέσιμο. Για μικρές αλλαγές στον κώδικα είναι ιδανικά και γρήγορα!
Υπάρχει όμως και μια τρίτη κατηγορία που βρίσκεται κάπου στη μέση. Πρόκειται για τις λεγόμενες εικονικές μηχανές (Virtual Machines – όχι δεν εννοούμε το VMWare ή το Virtual Box, μην το μπερδέψετε!) που παράγουν ένα ψευτο-εκτελέσιμο κώδικα (intermediate code), ο οποίος απαιτεί την ύπαρξη μιας «εικονικής μηχανής» για να τρέξει. Τέτοιες προσεγγίσεις έχουν φτιαχτεί για τις γλώσσες Java και για το γνωστό και μη εξαιρετέο Microsoft .Net. Βέβαια μη νομίζετε ότι αυτή η ιστορία είναι και τόσο πολύ καινούρια! Την 10ετία του 1980 υπήρχε το περίφημο P-System της Pascal, και είχαν φτιαχτεί γι’ αυτό ουκ-ολίγες εφαρμογές! Τα πλεονεκτήματα της virtual machine είναι η φορητότητα, η ασφάλεια κλπ. Για την ταχύτητα θα έλεγε κανείς ότι σίγουρα είναι καλύτερα από τον interpreter αλλά ίσως λίγο χειρότερα από τον compiler.
Ας έρθουμε όμως στην εκτέλεση του προγράμματος, που είναι και αυτό που μας ενδιαφέρει. Θα ασχοληθούμε με την εκτέλεση ενός προγράμματος που έχει μεταγλωττιστεί από κάποιον compiler χωρίς αυτό να σημαίνει ότι οι υπόλοιπες προσεγγίσεις (interpreters και virtual machines) διαφέρουν πολύ σε υλοποίηση. Να πούμε οτι σε αυτό το άρθρο (τουλάχιστον) για αναφερθούμε για λόγους απλότητας σε υλοποιήσεις που βασίζονται στους επεξεργαστές της Intel (AMD και συμβατούς) και σε αρχιτεκτονική 32-bit.
Κάθε πρόγραμμα που εκτελείται στην μνήμη του υπολογιστή μας χρησιμοποιεί τρία βασικά μέρη της μνήμης RAM:
Το μέρος του Κώδικα (code section).
Το μέρος των Δεδομένων (data section).
Το μέρος της Στοίβας (stack).
Πριν αναλύσουμε ένα-ένα τα μέρη αυτά θα θέλαμε να σας πούμε λίγα λόγια για την μνήμη. Η μνήμη του υπολογιστή είναι σαν τις κλειδοθήκες στην reception ενός ξενοδοχείου. Οι κλειδοθήκες λοιπόν, έχουν απ’ έξω γραμμένο ένα αριθμό που είναι ο αριθμός δωματίου και μέσα περιέχουν (ή δεν περιέχουν) το κλειδί. Έτσι ακριβώς λειτουργεί και η μνήμη του υπολογιστή μας: Περιέχει εκατομμύρια κουτάκια με νούμερα τα οποία νούμερα τα ονομάζουμε διευθύνσεις και μέσα σε αυτές φυλάσσονται τα δεδομένα μας. Κάθε κουτάκι μπορεί να δεχτεί συγκεκριμένου μεγέθους δεδομένα. Αν τα δεδομένα που θέλουμε να αποθηκεύσουμε στην μνήμη είναι πολλά (που σχεδόν πάντα είναι) τότε μοιράζονται σε πολλά κουτάκια. Όπως θα φαντάζεστε, πάρα πολλά κουτάκια παραμένουν άδεια διότι απλά δεν έχουν τοποθετηθεί ακόμα μέσα τους δεδομένα. Αυτό όμως δεν σημαίνει ότι δεν έχουν και διεύθυνση! Κρατήστε αυτές τις πληροφορίες διότι θα μας χρειαστούν παρακάτω.
Μέρος του Κώδικα (code section)
Σε αυτό το κομμάτι της μνήμης αποθηκεύονται όλες οι εντολές του προγράμματός μας. Κατά την διάρκεια εκτέλεσης του προγράμματος κανένα πρόγραμμα δεν μπορεί να γράψει δεδομένα σε αυτό το μέρος. Είναι μόνο για διάβασμα (Read Only).
Για παράδειγμα, όλες οι εντολές μηχανής που αντιστοιχούν στο παρακάτω κομμάτι πηγαίου κώδικα (σε γλώσσα C στο παράδειγμα μας) θα τοποθετηθούν στην μνήμη στο Code Section:
/* Θέσε τα στοιχεία της 1ης διαγώνιου ενός πίνακα 100×100 με 1, και τα υπόλοιπα με 0 */
for (i = 0; i < 100; i++)
for (j = 0; j < 100; j++)
if (i<>j)
a[i][j] = 0
else
a[i][j] = 1;
Τα σχόλια /*…*/ φυσικά δεν περιλαμβάνονται στον εκτελέσιμο κώδικα, δηλαδή δεν θα μεταφραστούν σε κώδικα μηχανής αφού αφορούν μόνο αυτόν που διαβάζει το πρόγραμμα και όχι τον επεξεργαστή που το εκτελεί.
Μέρος των Δεδομένων (data section)
Στο μέρος αυτό τοποθετούνται όλες οι καθολικές μεταβλητές (global variables) του προγράμματος μας. Καθολικές μεταβλητές είναι εκείνες που είναι προσβάσιμες από όλες τις συναρτήσεις (functions) και τα υποπρογράμματα (procedures) του τρέχοντος προγράμματος. Εδώ, μπορεί να γράψει και φυσικά να διαβάσει δεδομένα το πρόγραμμα μας (non Read-Only). Για παράδειγμα, οι παρακάτω μεταβλητές i, j και a θα τοποθετηθούν στο data section:
int i;
int j=0;
int a[100][100];
Μέρος της Στοίβας (stack)
Όλες οι τοπικές μεταβλητές, δηλαδή αυτές που δηλώνονται στις συναρτήσεις ή στα υπο-προγράμματα καθώς επίσης και κάποιες διευθύνσεις μνήμης που χρησιμοποιεί το πρόγραμμα μας καταχωρούνται στην λεγόμενη στοίβα. Το μέρος αυτό της μνήμης αποτελεί στην πραγματικότητα μια δομή δεδομένων τύπου στοίβας. Για να γίνει κατανοητή η δομή αυτή θα αναφέρουμε το κλασικό παράδειγμα με τα πιάτα: Σκεφτείτε ότι πρέπει να πλύνουμε 10 πιάτα. Καθώς τα πλένουμε ένα-ένα τα τοποθετούμε σε μια στοίβα, το ένα επάνω στο άλλο. Μόλις τελειώσουμε και θέλουμε να τα σκουπίσουμε (λέμε τώρα…!) τότε θα πάρουμε πρώτα εκείνο που μπήκε τελευταίο στην στοίβα. Η μέθοδος αυτή που χρησιμοποιούμε την στοίβα ονομάζεται Last In First Out (LIFO) και πρόκειται για μια πολύ συνηθισμένη “κατάσταση” στον προγραμματισμό (και όχι μόνο – απ’ όσο είδαμε και στο παράδειγμα μας…). Το κύριο χαρακτηριστικό της είναι πως το στοιχείο που μπαίνει τελευταίο, βγαίνει πρώτο.
Να πούμε οτι σε αυτό το μέρος της μνήμης επιτρέπεται το γράψιμο, δηλαδή είναι κι αυτό (όπως και το data segment) Writable. Αντί για… πιάτα όμως, το πρόγραμμα μας τοποθετεί εδώ της μεταβλητές που χρησιμοποιούμε στις συναρτήσεις του προγράμματος μας. Βέβαια, πρέπει να έχει ένα τρόπο να γνωρίζει ποια μεταβλητή είναι η τελευταία στην στοίβα, αυτή δηλαδή που θα ληφθεί πρώτη, όταν χρειαστεί. Για να το γνωρίζει αυτό, χρησιμοποιεί έναν από τους λεγόμενους δείκτες. Σκεφτείτε τους δείκτες σαν θέσεις μνήμης αλλά μέσα στον επεξεργαστή: άμεσα και γρήγορα προσβάσιμους. Ο δείκτης που χρησιμοποιείται για να ξέρουμε ποιο είναι το τελευταίο στοιχείο (μεταβλητή) της στοίβας ονομάζεται Δείκτης Στοίβας (extended stack pointer – ESP ή σκέτο SP). Στην πραγματικότητα ο ESP κρατάει την διεύθυνση της μεταβλητής που βρίσκεται κάθε στιγμή στην κορυφή της στοίβας.
Στην στοίβα μπορούμε να βάζουμε (push) ή να παίρνουμε (pop) στοιχεία κατά βούληση. Είναι πολύ σημαντικό να γνωρίζετε δυο μικρά μυστικά:
Εξ’ αιτίας της αρχιτεκτονικής του 32μπιτου επεξεργαστή της Intel (ή των συμβατών με αυτόν όπως o AMD), οι μεταβλητές που καταχωρούνται αποτελούνται από μέρη των 4ων ψηφίων ή αλλιώς των 4ων bytes. Γιατί; Διότι το bus είναι 32 bits (binary digits). Στα 32 bits χωράνε 4 bytes αφού το 1 byte = 8 bits, 4 x 8 = 32bits.
Η στοίβα αυξάνεται προς τα κάτω. Δηλαδή ξεκινάει από ψηλές διευθύνσεις στην μνήμη και όσο βάζουμε στοιχεία αυτή “μεγαλώνει” τόσο “κατεβαίνει” προς τα κάτω. Δείτε για παράδειγμα το εξής:
Έστω οτι ο καταχωρητής SP = 256. Δείχνει, δηλαδή, στο κουτάκι 256 στην μνήμη. Αν δώσουμε την εντολή “push 34” (βάλε στο stack το 34) τότε ο ΕSP αυτόματα θα μειωθεί κατά 4 και θα γίνει 252 και στο κουτάκι 256 θα μπει ο αριθμός 34.
Έχουμε λοιπόν:
PUSH 34
Διεύθυνση
Τιμή
256
34
252
248
…
ESP=256
Αν μετά δώσουμε την εντολή:
PUSH 50
θα έχουμε:
Διεύθυνση
Τιμή
256
34
252
50
248
…
ESP=248
Για να πάρει το πρόγραμμα μας από το stack, θα δώσει την εντολή:
POP Χ
Αυτό σημαίνει οτι ο επεξεργαστής θα πάρει από το STACK την πρώτη τμή και θα την απονείμει στην μεταβλητή Χ και αμέσως μετά ο ESP θα γίνει 252 και η μεταβλητή Χ θα έχει την τιμή 34.
Εδώ, να αναφέρουμε ένα μικρό μυστικό. Αν θέλαμε να πάρουμε από το STACK την τιμή 50 και όχι την 34 τότε θα έπρεπε να δώσουμε δύο φορές POP αφού δεν έχουμε κατευθείαν πρόσβαση στο 50. Δηλαδή:
POP Χ
POP Χ Εδώ, το Χ θα έχει την τιμή 50 και ο ESP=248.
Πως εκτελούνται οι εντολές (instructions)
Για να καταλάβουμε αυτή την λειτουργία πρέπει πρώτα να μιλήσουμε για ένα καταχωρητή: Τον EIP (Extended Instruction Pointer ή απλά Instruction Pointer). Οι καταχωρητές είναι ακριβώς όπως και οι δείκτες που αναφέραμε πιο πάνω: Είναι θέσεις μνήμης μέσα στον επεξεργαστή και χρησιμοποιούνται από αυτόν για να εκτελεί της εντολές των προγραμμάτων μας. Αυτός ο καταχωρητής χρησιμοποιείται για να “κρατάει” πάντα την διεύθυνση που βρίσκεται η επόμενη προς εκτέλεση εντολή του προγράμματος μας. Για να εκτελέσει ο επεξεργαστής μια εντολή, διαβάζει από τον EIP την διεύθυνση της, πάει σε αυτήν την διεύθυνση και διαβάζει την εντολή, την εκτελεί και καταχωρεί στον EIP την επόμενη προς εκτέλεση εντολή, κοκ. Πώς όμως ο επεξεργαστής μας θα βρει ποια είναι η επόμενη προς εκτέλεση εντολή ώστε να την καταχωρήσει στον EIP; Χμ… εδώ πρέπει να διακρίνουμε δυο περιπτώσεις:
Η επόμενη εντολή προς εκτέλεση βρίσκεται αμέσως μετά την προηγούμενη.
Να έχουμε μια περίπτωση jump δηλαδή να υπάρχει (για παράδειγμα) μια συνάρτηση που καλείται προς σε ένα άλλο σημείο του προγράμματος και θα πρέπει ο επεξεργαστής μας να “πηδήσει” σε εκείνο το σημείο, ή αλλιώς σε εκείνη την διεύθυνση της μνήμης και να εκτελέσει τις εντολές εκεί.
Στην περίπτωση 1 τα πράγματα είναι απλά: Η διεύθυνση υπολογίζεται ως εξής: προσθέτουμε στον EIP το μήκοςτης τρέχουσας εντολής που εκτελέστηκε. Το αποτέλεσμα μιας τέτοιας πράξης θα είναι η διεύθυνση της αμέσως επόμενης εντολής. Για να το καταλάβετε αυτό, δείτε το εξής μικρό πρόγραμμα δύο εντολών:
100 push EDX 101 mov ESP 0
Η εντολή στην διεύθυνση 100 βάζει στο stack την τιμή του καταχωρητή EDX (αυτός είναι ένας καταχωρητής γενικής χρήσης – τον έχουμε σαν… πρόχειρο). Η εντολή στην διεύθυνση 101 δίνει στο δείκτη ESP την τιμή 0. Όταν ο επεξεργαστής μας εκτελεί την εντολή στην διεύθυνση 100 τότε θα “σκεφτεί” τα εξής:
Είναι κάποιο jump; Όχι, άρα υπολογίζω το μέγεθος της εντολής στην διεύθυνση 100 που έχω. Έστω οτι είναι 1 byte. Άρα η επόμενη εντολή προς εκτέλεση πρέπει να βρίσκεται στην διεύθυνση 100 + 1 = 101. Άρα βάζω στον EIP το 101.
Απ’ ότι καταλάβατε εδώ, κάθε εντολή – instruction (push, mov κλπ) καταλαμβάνει μνήμη και άρα έχει και κάποιο μέγεθος. Όλες οι εντολές δεν έχουν το ίδιο μέγεθος. Άλλες μπορεί να είναι 1 byte άλλες 2 άλλα 4 κοκ.
Υπάρχει βέβαια και η πιο σύνθετη περίπτωση: Η περίπτωση JUMP, δηλαδή η περίπτωση που το πρόγραμμα μας συνεχίζεται σε μια άλλη διεύθυνση πολύ πιο… “μακρινή” από την αμέσως επόμενη στη σειρά. Αυτό μπορεί να συμβεί (όπως είπαμε) όταν το πρόγραμμα καλεί μια συνάρτηση ή ένα άλλο υποπρόγραμμα. Στην πράξη γίνεται το εξής: Πριν εκτελεστεί η εντολή JUMP ο επεξεργαστής μας κρατάει την αμέσως επόμενη εντολή (αυτή που θα βρίσκεται μετά το jump) και την τοποθετεί σε ένα καταχωρητή γενικής χρήσης, ας πούμε τον EDX. Αμέσως μετά πάει στην διεύθυνση που του λέει το JUMP (Π.χ. JUMP 35456) και εκτελεί τις εντολές που βρίσκονται εκεί μία προς μία, μέχρι να συναντήσει το τέλος της συνάρτησης (που ορίζεται με μια εντολή RET, δηλαδή return), τότε απλά γράφει στο EIP το περιεχόμενο που είχε καταχωρήσει στον EDX. Κατά συνέπεια το πρόγραμμα συνεχίζει από την επόμενη εντολή που είχε σταματήσει για κάνει το jump. Η διαδικασία του JUMP υλοποιείται από το πρόγραμμα με την χρήση 2 εντολών: της CALL και της RET. H CALL μεταφέρει την λειτουργικότητα του προγράμματος σε μια άλλη (μακρινή) διεύθυνση και η RET δηλώνει το τέλος της σειράς των εντολών που βρίσκονται σε αυτήν την άλλη διεύθυνση ώστε να ξέρει πότε να σταματήσει (ή όπως λέμε να επιστρέψει) ο επεξεργαστής από την εκτέλεση των εντολών σε αυτή την περιοχή της μνήμης.
Δείκτης Βάσης – base pointer (EBP)
Κάθε φορά που εφαρμόζεται ένα jump είπαμε οτι ο επεξεργαστής πάει να εκτελέσει ένα σύνολο εντολών (instructions) σε μια άλλη θέση μνήμης (μέχρι να συναντήσει ένα RET). Αυτό το σύνολο εντολών όπως είπαμε, ονομάζεται συνάρτηση (function) ή διαδικασία (procedure). Κάθε συνάρτηση (ή διαδικασία) έχει το δικό της stack το οποίο ονομάζεται stack frame. Ένα stack frame είναι μια στοίβα στην οποία θα καταχωρηθούν μεταβλητές και διευθύνσεις που αφορούν μόνο στην τρέχουσα συνάρτηση που εκτελείται. Κάθε διεύθυνση μέσα στο συγκεκριμένο stack είναι μια σχετική διεύθυνση σε σχέση με μια βάση. Η βάση αυτή είναι ο base pointer. Όλες λοιπόν οι αναφορές στις διευθύνσεις του stack γίνονται με βάση τον τρέχοντα δείκτη βάσης (base pointer).
Στην πράξη γίνεται το εξής: Πριν καλέσουμε μια συνάρτηση βάζουμε στο EBP τον τρέχον ESP. Από εκεί και μετά κάθε φορά που θέλουμε να αναφερθούμε σε μια διεύθυνση στο stack θα το κάνουμε με βάση τον EBP που στην ουσία είναι η αρχή του stack πριν την κλήση της συνάρτησης. Για να το καταλάβετε δείτε το εξής παράδειγμα:
Στο παρακάτω stack έχουμε ebp=256 και esp=256:
Διεύθυνση
Τιμή
256
34
252
248
…
Έστω οτι καλούμε μια συνάρτηση η οποία βάζει στο stack τον αριθμό 89. Θα έχουμε:
Διεύθυνση
Τιμή
256
34
252
89
248
…
Όπου ebp=256 και esp=252.
Η χρήση του ebp μας βολεύει πολύ όταν θέλουμε να αναφερθούμε στις τιμές του stack της συγκεκριμένης συνάρτησης. Δηλαδή, η μεταβλητή που βρίσκεται στη θέση (ebp 256) είναι η πρώτη μεταβλητή που καταχώρησε στο stack η συνάρτηση μας.
Όταν τελειώσει αυτή η συνάρτηση το έργο της (με ένα RET), τότε ο EBP θα επανέλθει στον προηγούμενο EBP ο οποίος είχε φυλαχτεί σε κάποιον καταχωρητή πριν την κλήση της συνάρτησης.
Συμπεράσματα
Δώσαμε μια βασική περιγραφή για το πώς λειτουργεί εσωτερικά ένα πρόγραμμα. Οι γνώσεις που αποκομίσατε από το συγκεκριμένο άρθρο θεωρούνται στοιχειώδεις γνώσεις για ένα reverser ή για κάποιον που θέλει να καταλάβει έννοιες και να μπορέσει να διαβάσει άρθρα λίγο πιο προχωρημένα όπως αυτά που «μιλάνε» για buffer overflow.
Θα πρέπει, αν θέλετε να καταλάβετε καλά ένα Stack Buffer Overflow Attack, θα πρέπει να δώσετε βάση και να μπορείτε να εξηγήσετε τα εξής:
Τι είναι ο Instruction Pointer (EIP).
Τι είναι το Stack.
Τι είναι ο Stack Pointer (ESP).
Πώς συνδέονται τα παραπάνω μεταξύ τους.
Στα επόμενα άρθρα αυτής της οικογένειας θα δούμε λίγο πιο… core πράγματα! Προς το παρόν, σκεφτείτε το εξής:
Τι θα συμβεί αν καταφέρουμε με κάποιο τρόπο να ελέγξουμε τον Instruction Pointer (EIP);! 😎
A buffer overflow (bof), or buffer overrun, is an anomaly whereby a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations (Wikipedia).
Θα αναλύσουμε σε αυτό το άρθρο αυτή την πολύ παλιά ευπάθεια λογισμικού και θα δούμε αν αυτή εξακολουθεί να μετράει…
Από το πρώτο άρθρο του Aleph One (Elias Levy) το 1996, “Smashing The Stack For Fun And Profit“, έχουν περάσει πάνω από 25 χρόνια. Η απάντηση στην ερώτηση “Είναι αυτή η ευπάθεια ακόμα ενεργή;” είναι ένα μεγάλο: ΝΑΙ!
Αλλά πράγματι, σήμερα, με τα σύγχρονα περιβάλλοντα & γλώσσες ανάπτυξης λογισμικού (.Net, J2EE, RoR, κλπ) δεν είναι τόσο εύκολο να πραγματοποιηθεί μια τέτοια επίθεση, αλλά… οι εφαρμογές που δημιουργήθηκαν σε περισσότερο low level γλώσσες προγραμματισμού που είναι ευάλωτες στην buffer overflow (όπως η C ή η C++) εξακολουθούν να υπάρχουν, και είναι πολλές: Web servers, Λειτουργικά Συστήματα, DBMSs και γενικά, σχεδόν σε όλα όσα βάζουμε να “τρέχουν” οι “ασφαλείς” εφαρμογές μας…
Σε αυτή τη σειρά άρθρων θα προσπαθήσω να εξηγήσω στους νεοεισερχόμενους πώς μπορεί να γίνει μια τέτοια επίθεση σε σύγχρονα περιβάλλοντα και Λειτουργικά Συστήματα.
Δεδομένου ότι η συγκεκριμένη επίθεση έχει να κάνει με την αρχιτεκτονική της μνήμης, την αρχιτεκτονική των λειτουργικών συστημάτων και τις συγκεκριμένες υλοποιήσεις μεταγλωττιστών, υπάρχουν αρκετές παραδοχές που πρέπει να κάνουμε.
Θα συζητήσουμε αυτές τις υποθέσεις για κάθε αρχιτεκτονική που επιλέγουμε.
Ας ξεκινήσουμε το ταξίδι μας με Linux…
0x1. Linux 64bit σε εφαρμογή 64bit
Ας δημιουργήσουμε τη δοκιμαστική μας εφαρμογή σε γλώσσα C για να ολοκληρώσουμε τη δοκιμή.
Ο πηγαίος κώδικας είναι ο εξής:
Αυτό το πολύ απλό πρόγραμμα επίδειξης, αυτό που κάνει είναι να λάβει ένα κλειδί προϊόντος ως είσοδο και αν το κλειδί προϊόντος είναι σωστό θα συνεχίσει στην κύρια ροή, διαφορετικά παράγει ένα σφάλμα και εξέρχεται.
Η είσοδος μπορεί να δοθεί από όρισμα της γραμμής εντολών ή (αν δεν δοθούν ορίσματα) θα ζητήσει από τον χρήστη να το εισάγει.
Για να μπορέσουμε να πραγματοποιήσουμε μια επιτυχημένη επίθεση, κάνουμε κάποιες παραδοχές χρησιμοποιώντας συγκεκριμένες σημαίες (flags) του μεταγλωττιστή.
Μεταγλωττίζω το πρόγραμμα ως εξής:
-m64: δημιουργία ενός εκτελέσιμου αρχείου σε αρχιτεκτονική 64bit (για να είμαι ειλικρινής, θα μπορούσα να το παραλείψω στο συγκεκριμένο σύστημα, αφού χρησιμοποιείται ως προεπιλογή).
-g: για την παραγωγή ειδικών μεταδεδομένων για τον αποσφαλματωτή (debugger – που θα χρησιμοποιήσουμε αργότερα)
-fno-stack-protector: κατά την εκτέλεση του προγράμματος δεν θα πραγματοποιείται έλεγχος στοίβας μνήμης (no stack protection).
-z execstack: επιτρέπει την εκτέλεση κώδικα σε τμήμα στοίβας (στη μνήμη).
-o demo: όνομα του τελικού εκτελέσιμου αρχείου θα είναι demo.
Το συγκεκριμένο παράδειγμα έχει υλοποιηθεί στο KALI Linux 2022.4:
Επιπλέον, είναι πολύ σημαντικό να απενεργοποιήσετε την προστασία ASLR (Address Space Layout Randomization).
Για να το κάνετε αυτό, στο kali απλά εισάγετε την εντολή ως root:
Και… btw, αν θέλετε να ελέγξετε, ποια είναι η τρέχουσα κατάσταση του ASLR, εισάγετε αυτό:
$ sudo cat /proc/sys/kernel/randomize_va_space
Στην παρακάτω εικόνα βλέπουμε μια κανονική εκτέλεση του μικρού μου προγράμματος επίδειξης.
Όπως μπορείτε να δείτε, υπάρχουν δύο (τουλάχιστον!!) κύρια τρωτά σημεία στο πρόγραμμα: Είναι όπου χρησιμοποιείται η ευάλωτη συνάρτηση strcpy και ας το δούμε αυτό στην πράξη:
O παραπάνω είναι ένας σχετικά εύκολος ο τρόπος για να ελέγξουμε αν το πρόγραμμά μας είναι ευάλωτο σε μια επίθεση buffer overflow: Δίνουμε ένα πολύ μεγάλο αλφαριθμητικό και στη συνέχεια ελέγχουμε την απόκριση του προγράμματος. Αν λάβουμε ένα ‘segmentation fault’ τότε είναι πιθανό να έχουμε μια ευπάθεια bof (buffer overflow)…
0x1.0x1. Η προσέγγιση ROP
Σύμφωνα με τη Wikipedia: Return-oriented programming (ROP) is a computer security exploit technique that allows an attacker to execute code in the presence of security defenses such as executable space protection and code signing.
Ο κύριος στόχος μας εδώ είναι να εκμεταλλευτούμε την ευπάθεια ενός προγράμματος προκειμένου να ανακατευθύνουμε τη ροή του προγράμματος εκεί που μας αρέσει (και εκεί που μπορούμε, βεβαίως βεβαίως)…
Ας εξετάσουμε τη συμπεριφορά του προγράμματος χρησιμοποιώντας τον αποσφαλματωτή gdb.
Βάζουμε ένα σημείο διακοπής (break point) στη γραμμή 7, αμέσως μετά την strcpy, μέσα στη συνάρτηση checkProductKey.
Εκτελούμε την εφαρμογή μέσα στον αποσφαλματωτή ( απλά πληκτρολογούμε dbg ./demo ) περνώντας ένα κανονικό αλφαριθμητικό, προκειμένου να ελέγξουμε πού βρίσκεται η διεύθυνση RET (περισσότερα γι’ αυτό παρακάτω). Έτσι θα έχουμε:
Ας συζητήσουμε μερικά πραγματάκια εδώ…
Η παραπάνω εικόνα χωρίζεται σε 2 κονσόλες:
Η αριστερή κονσόλα είναι ο disassembled κώδικας του προγράμματος που λαμβάνω μετά την τοποθέτηση του σημείου διακοπής στη γραμμή 7 (break 7) και την εισαγωγή disassemble /s main. Η παράμετρος “/s” δίνει εντολή στον αποσφαλματωτή να παράγει τον disassembled κώδικα μαζί με τον αντίστοιχο πηγαίο κώδικα C (thanks to the flag -g στη φάση της μεταγλώττισης).
Η δεξιά κονσόλα είναι η κονσόλα εκτέλεσης στην οποία δουλεύουμε δοκιμάζοντας το πρόγραμμα μας.
Σημειώστε επίσης το εξής σημαντικό: οι διευθύνσεις μνήμης (που ορίζονται με μπλε χρώμα) είναι ίδιες και στις δύο εικόνες. Αυτό είναι πολύ δύσκολο να συμβεί σε πραγματικές καταστάσεις, επειδή αυτές οι διευθύνσεις μπορεί να μην είναι πάντα οι ίδιες κάθε φορά που εκτελούμε το πρόγραμμα. Αυτό συμβαίνει εξαιτίας του ASLR, και γι’ αυτό το λόγο το απενεργοποιούμε, παραπάνω, αλλιώς μπορεί να καταλήξουμε να κυνηγάμε… φαντάσματα, πιστέψτε με! — burned-burned-burned!!
Όπως μπορείτε να δείτε στα ΠΡΑΣΙΝΑ ΚΟΥΤΙΑ τρέχουμε το πρόγραμμα στον αποσφαλματωτή περνώντας 10 “Α” ως όρισμα: run AAAAAAAAAA
Αυτό αποθηκεύεται στη στοίβα (stack – μην μου πείτε οτι δεν το ξέρετε – see part I) καθώς καλείται η συνάρτηση checkProductKey αφού περνάει ως όρισμα στη συνάρτηση.
Μπορούμε να δούμε τη στοίβα στη μνήμη εισάγοντας την εντολή x/24xg $rsp στον αποσφαλματωτή. Αυτή η εντολή δίνει εντολή στον αποσφαλματωτή να εμφανίσει σε δεκαεξαδική μορφή “x”, τις επόμενες 24 θέσεις μνήμης σε γιγαντιαία (“g”) μορφή 8-bytes.
Το $rsp είναι το γνωστό Stack Pointer (το παλιό ESP στα 32bit συστήματα – see again part I) όπου στην περίπτωσή μας δείχνει τις μεταβλητές που πέρασαν ως ορίσματα μέσα στη συνάρτησή μας.
Τα “AAAAAAAAAA” αναπαρίστανται εδώ σε δεκαεξαδική μορφή (“x”) από τον αριθμό “41” που είναι η ASCII δεκαεξαδική αναπαράσταση του γράμματος “A”.
Επίσης, σημειώστε ότι τα 10 “Α” αποθηκεύονται στη θέση μνήμης με αντίστροφη σειρά, καθώς πρόκειται για την αρχιτεκτονική little endian.
Έτσι, η πραγματική συμβολοσειρά που διατηρείται στη στοίβα (στη μνήμη) είναι η “41.41.41.41.41.41.41.41.41.41.00” (έβαλα το “.” για να είναι πιο ευανάγνωστο).
Σημειώστε ότι το “00” είναι ο μηδενικός χαρακτήρας που δηλώνει τον τερματισμό της συμβολοσειράς. Να θυμάστε αυτό το “00” επειδή παίζει σημαντικό ρόλο (ως εμπόδιο) στην ανάπτυξη exploits γενικότερα, και ειδικά στη δημιουργία shellcode (ή bytecode) (περισσότερα για αυτό στο part III). Το βασικό σημείο που πρέπει να γνωρίζετε εδώ είναι το εξής: Η ανάγνωση (ή μερικές φορές η εκτέλεση) μιας σειράς θέσεων μνήμης διακόπτεται όταν το σύστημα συναντήσει ένα byte 00.
Επικεντρωθείτε τώρα στα κόκκινα κουτάκια της εικόνας μας και θυμηθείτε πού βρισκόμαστε: Βρισκόμαστε μέσα στη συνάρτηση checkProductKey.
Όταν η συνάρτηση τελειώσει, η λειτουργικότητα του προγράμματος πρέπει να επιστρέψει στο σημείο που κλήθηκε. Για να είμαστε πιο συγκεκριμένοι: πρέπει να επιστρέψει στη διεύθυνση του καλούντα.
Προκειμένου το σύστημα να θυμάται αυτή τη διεύθυνση, την αποθηκεύει σε μια συγκεκριμένη θέση μνήμης μέσα στο buffer της τρέχουσας συνάρτησης. Ονομάζουμε αυτή τη διεύθυνση: διεύθυνση RET (RETurn). Είναι μια από τις πιο σημαντικές διευθύνσεις των επιθέσεων buffer overflow και θεωρείται το “ιερό δισκοπότηρο” κάθε εκμετάλλευσης μιας αδυναμίας buffer overflow.
Όπως μπορείτε να δείτε στο κόκκινο πλαίσιο στη δεξιά κονσόλα, η διεύθυνση RET αποθηκεύεται στο τέλος του buffer, μετά τη διεύθυνση του αλφαριθμητικού εισόδου μας “AAAAAAAAAA” και κάποιες άλλες διευθύνσεις (όπως ο Base Pointer, κάποιες μεταβλητές περιβάλλοντος κ.λπ. που είναι σημαντικές… αλλά όχι τόσο σημαντικές για την ώρα).
Όπως μπορείτε να φανταστείτε αν εισάγουμε ένα πολύ μεγάλο αλφαριθμητικό εισόδου, μεγαλύτερο από αυτό που έχει κρατήσει το πρόγραμμα μας (στην περίπτωσή μας είναι 12 – λόγω της char key[12]; στη γραμμή 5) τότε αυτό θα γράψουμε από πάνω από όλες τις διευθύνσεις που ακολουθούν αυτή τη μεταβλητή, συμπεριλαμβανομένης της διεύθυνσης RET. Αυτό είναι πολύ σημαντικό και πολύ δύσκολο!
και αυτός είναι ο λόγος:
Έστω οτι δώσουμε αυτό σαν input: “AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA”.
To buffer μας μπορεί να χωρέσει μόνο τους πρώτους 12 χαρακτήρες (ή bytes στην αρχιτεκτονική i386), συμπεριλαμβανομένου του χαρακτήρα τερματισμού, δηλαδή του “00”. Τι γίνεται λοιπόν με τους υπόλοιπους χαρακτήρες; Μα, θα αντικαταστήσουν τις γειτονικές διευθύνσεις μνήμης… συμπεριλαμβανομένης της διεύθυνσης που βρίσκεται το RET .
Έτσι, η διεύθυνση RET θα γεμίσει με “A”, άρα “AAAAAAAA” ή “4141414141414141”.
Σημειώστε ότι επίτηδες επέλεξα 8 bytes για να δηλώσω τη διεύθυνση σε συστήματα 64bit.
Γενικά, θα πρέπει να γνωρίζετε ότι στα 64bit συστήματα (σε αντίθεση με τα 32bit συστήματα που είδαμε σαν θεωρία στο Part I) έχουμε τις εξής διαφορές:
Οι καταχωρητές γενικού σκοπού έχουν επεκταθεί σε 64-bit. Έτσι έχουμε τώρα τους RAX, RBX, RCX, RDX, RSI και RDI.
Ο Instruction Pointer, ο Base Pointer και ο Stack Pointer έχουν επίσης επεκταθεί σε 64-bit ως RIP, RBP και RSP αντίστοιχα.
Έχουν παρασχεθεί οι πρόσθετοι καταχωρητές: R8 έως R15.
Οι pointers έχουν μήκος 8-bytes.
Τα push/pop στο STACK έχουν μήκος 8-bytes.
To μέγιστο μέγεθος μιας επιτρεπτής διεύθυνσης είναι: 0x00007FFFFFFFFFFFFFFF (περισσότερα σχετικά με αυτό θα πούμε λίγο αργότερα).
Δείτε τώρα τη διεύθυνση RET σε συνδυασμό με μια άλλη πολύ σημαντική διεύθυνση, η οποία είναι αποθηκευμένη στη μνήμη του επεξεργαστή: Ο Instruction Pointer ή $RIP. Αυτή η διεύθυνση έχει πάντα τη διεύθυνση της επόμενης εντολής που θα εκτελέσει το πρόγραμμα. Έτσι, όταν φτάσουμε στο τέλος της συνάρτησης μας, εκτελείται η εντολή $RIP = RET. Έτσι, η λειτουργικότητα του προγράμματος θα επιστρέψει στον καλούντα, αφού η διεύθυνση RET διατηρεί τη διεύθυνση του καλούντος, και για να είμαστε πιο συγκεκριμένοι διατηρεί τη διεύθυνση της επόμενης εντολής από αυτή που κλήθηκε τη συνάρτηση.
Έτσι, στο παραπάνω θεωρητικό μας παράδειγμα η διεύθυνση RET θα γεμίσει με “4141414141414141”, δηλαδή το πρόγραμμα, στο τέλος της συνάρτησης checkProductKey θα προσπαθήσει να μεταβεί στη διεύθυνση 0x4141414141414141.
Αλλά μια τέτοια διεύθυνση δεν υπάρχει στο πλαίσιο του προγράμματός μας, οπότε λαμβάνουμε το γνωστό σφάλμα: segmentation fault
Έχοντας κατά νου τις παραπάνω γνώσεις ας προσπαθήσουμε να εκμεταλλευτούμε το πρόγραμμά μας.
Εξετάζοντας τη δομή $rsp στο αρχικό μας παράδειγμα (στην παραπάνω εικόνα) μπορούμε να δούμε ότι χρειαζόμαστε 3 x 8 bytes προκειμένου να ικανοποιήσουμε τη διεύθυνση RET.
Ας το αποδείξουμε αυτό με το ακόλουθο παράδειγμα:
Όπως μπορείτε να δείτε, εισάγουμε 24 x “A” = “AAAAAAAAAAAAAAAAAAAAAAAA” και τα 8 “B” “BBBBBBBB” αντικαθιστούν τη διεύθυνση RET.
Το πρόγραμμα κατέρρευσε… Αυτό που θα θέλαμε να κάνουμε στην πραγματικότητα είναι να αντικαταστήσουμε την $RIP με μια άκυρη διεύθυνση. Αλλά, στην πραγματικότητα δεν ελέγχουμε καθόλου την $RIP. Έχουμε έλεγχο μόνο στην RET όπως ήδη βλέπετε.
Για την ενημέρωσή σας πρέπει να το ξέρετε αυτό: Το μέγιστο μέγεθος διεύθυνσης που μπορούμε να χειριστούμε στην αρχιτεκτονική 64bit είναι 0x00007FFFFFFFFFFFFFFF. Αυτό που κάναμε μέχρι εδώ, είναι ότι γράψαμε επάνω στην $RIP, μέσω της RET, τη μη κανονική διεύθυνση 0x4242424242424242, η οποία προκαλεί τον επεξεργαστή να εγείρει μια εξαίρεση.
[Αν έχετε μπερδευτεί λίγο με τις 64μπιτες διευθύνσεις, μπορείτε να διαβάσετε περισσότερα για αυτή την αρχιτεκτονική των 64bit εδώ.]
Οπότε, ο στόχος ήταν να βρούμε το offset με το οποίο θα αντικαταστήσουμε την RET και κατά συνέπεια την $RIP με μια κανονική (υπαρκτή) διεύθυνση.
Για το λόγο αυτό χρησιμοποιώ ένα κυκλικό μοτίβο (ας πούμε “AAAAAABBBB” κλπ) και το δοκιμάζω μέχρι να καταλήξω στην απαραίτητη διεύθυνση (και ναι, ξέρω ότι υπάρχουν και άλλες δημοσιευμένοι μέθοδοι που υπολογίζουν διαφορετικά το απαιτούμενο offset, αλλά αυτή που παρουσίασα εδώ επίσης λειτουργεί… οπότε… ΟΚ! 😎 ).
Έτσι, θα πάω να αντικαταστήσω το “BBBBBBBBBB” με μια υπάρχουσα διεύθυνση του υπάρχοντος πηγαίου κώδικα (Code Segment) προκειμένου να παρακάμψω τους ελέγχους που γίνονται στον κώδικα για το σωστό κλειδί.
Αυτή η διεύθυνση είναι η ακόλουθη:
Σε αυτό το σημείο έχουν περάσει όλοι οι έλεγχοι σχετικά με το κλειδί προϊόντος, και αυτό είναι που ονομάζω ROP (βλ. τον τίτλο της παραγράφου).
Πρέπει να αντικαταστήσω το “B” με αυτή τη διεύθυνση: 0x0000555555555261
Αλλά πρέπει να περάσω την τιμή της ως bytes… και όχι ως συμβολοσειρά! Πώς να το κάνω αυτό;
Υπάρχουν διάφοροι τρόποι για να περάσετε αυτό το αλφαριθμητικό ως “bytes” στον αποσφαλματωτή:
Θα επιλέξω τον πιο γρήγορο… ρίξτε μια ματιά εδώ:
Ας εξετάσουμε λίγο την επίθεση “string” :
Εδώ χρησιμοποιώ λίγο την python v.2 (και στην v.3 λειτουργεί επίσης αν βάλω την εκτύπωση συμβολοσειράς σε παρενθέσεις: “(” και “)” ) : python2 -c ‘print “1”*24 + “\x55\x55\x55\x55\x55\x52\x61″[::-1]’
Αντί να γράψω μια εξήγηση σε κείμενο εδώ θα δείξω την εικόνα του αποτελέσματος όταν το εκτελώ στη γραμμή εντολών:
Όπως μπορείτε να δείτε, περνάω τα παραπάνω αποτελέσματα, ως όρισμα γραμμής εντολών στο dbg χρησιμοποιώντας τον συμβολισμό run $( <SYSTEM_COMMAND> ).
Αυτός είναι ένας εύκολος τρόπος για να περάσετε τη συμβολοσειρά της γραμμής εντολών ως bytes σε ένα πρόγραμμα.
Το πρόγραμμα “σκάει” (με segmentation fault), αλλά στο τέλος, έκανα μια επιτυχημένη ανακατεύθυνση, όπως μπορείτε να δείτε το μήνυμα ‘Welcome’ (στο πράσινο πλαίσιο παραπάνω). Έτσι, παρακάμπτω τον μηχανισμό ελέγχου!!
Σημειώστε επίσης, τον τρόπο με τον οποίο περνάω τη διεύθυνση στόχου, με αντίστροφη σειρά: ο συμβολισμός [::-1] της python απλά έβαλε τη δεκαεξαδική συμβολοσειρά αντίστροφα.
Έτσι, το “55.55.55.55.55.52.61” θα μπει στα string arguments ως “61.52.55.55.55.55.55.55” (θυμηθείτε την αρχιτεκτονική little endian που ανέφερα παραπάνω).
Σημαντική σημείωση: το “555555555261” τοποθετείται στη μνήμη με αντίστροφη σειρά ανά ζεύγος: το “55.55.55.55.55.52.61” θα τοποθετηθεί στη μνήμη ως “61.52.55.55.55.55.55“.
Και γενικά, κάθε διεύθυνση μνήμης που θα διαβάσουμε, είναι μια σειρά από ζεύγη – ή μια σειρά από 1 byte (8bits, από το 0 έως το 255 – ή αλλιώς 2^8=256 πιθανές διαφορετικές τιμές). “Historically, the byte was the number of bits used to encode a single character of text in a computer and for this reason it is the smallest addressable unit of memory in many computer architectures.” (wikipedia)
Το ίδιο ισχύει και για τα i386 64-bit Windows 10 αλλά και στο i386 64-bit Kali Linux.
Επιπλέον, ο συμβολισμός ‘\x’ υποδηλώνει ότι μιλάω στο πρόγραμμα όχι σε δεκαδικό αλλά σε δεκαεξαδικό σύστημα.
Το κάνω αυτό επειδή ο αποσφαλματωτής εμφανίζει τις διευθύνσεις μνήμης σε δεκαεξαδική σημειογραφία.
Αν αναρωτιέστε γιατί ο αποσφαλματωτής προτιμά τη δεκαεξαδική σημειογραφία, θα έλεγα το εξής:
Η δεκαδική αναπαράσταση της δεκαεξαδικής διεύθυνσης 555555555261 είναι αυτός ο αριθμός: 93824992236129. Λοιπόν, φαίνεται σαν έναν τηλεφωνικό αριθμό, ε;! 😆
Έτσι… δεν είναι τόσο εύκολο για τον άνθρωπο να αντιμετωπίσει τόσο μεγάλους αριθμούς μήκους. Η δεκαεξαδική σημειογραφία είναι πιο εύχρηστη και συνεπώς διαχειρίσιμη. Αυτός είναι ο λόγος για τον οποίο έχει υιοθετηθεί από (σχεδόν) όλα τα προγράμματα εντοπισμού σφαλμάτων στον κόσμο για την αναπαράσταση διευθύνσεων η 16δική αναπαράσταση.
Μέχρι στιγμής, λοιπόν, έχω εκτελέσει, στην ουσία, ένα “goto” (θυμάστε στη BASIC την εντολή goto😉 ή ένα JUMP (assembly-wise) με τη χρήση του debugger.
Αυτό που χρειάζομαι τώρα είναι να κάνω το ίδιο στο τελικό εκτελέσιμο από τη γραμμή εντολών σε μια κονσόλα, και ΟΧΙ με τη χρήση του dbg.
Λοιπόν, η απάντηση φαίνεται αρκετά απλή: Απλά το τρέχω από τη γραμμή εντολών αυτό:
Όπως μπορείτε να δείτε, ανοίγω την οθόνη καλωσορίσματος χωρίς να πληκτρολογήσω κανένα κλειδί προϊόντος και μόλις δημιούργησα την πρώτη μου εκμετάλλευση buffer overflow… 😎
Σημειώστε ότι τα αποτελέσματα στην παραπάνω εικόνα δεν είναι πάντα τόσο προφανή, ειδικά όταν πειράζουμε τις διευθύνσεις μνήμης και τη στοίβα απευθείας. Αρκετές φορές αυτό που βλέπω στον αποσφαλματωτή δεν είναι ακριβώς το ίδιο με αυτό που βλέπω όταν εκτελώ το πρόγραμμα απευθείας από τη γραμμή εντολών και αυτό είναι πολύ συνηθισμένο όταν πρέπει να αναφερθώ σε διευθύνσεις στη στοίβα (και όχι στο τμήμα κώδικα όπως έκανα εδώ).
Τέτοιο παράδειγμα θα δούμε στο Μέρος ΙΙI αυτής της σειράς άρθρων, όταν θα δείξω πώς να βάλω ένα “shell” στη στοίβα και πώς να το εκτελέσω. Επιπλέον στο Μέρος ΙΙI θα δούμε τι είναι το bytecode, πώς θα δημιουργήσουμε ή θα βρούμε κάποιους έτοιμα byte-codes και πώς θα τα ελέγξουμε. Θα δούμε, οτι σε τέτοιες περιπτώσεις ότι τα αποτελέσματα μπορεί να μην είναι τόσο ντετερμινιστικά όσο θα περιμέναμε…
Η παραβίαση των δεδομένων του National Student Clearinghouse επηρεάζει 890 σχολεία
Η αμερικανική μη κερδοσκοπική εκπαιδευτική εταιρεία National Student Clearinghouse αποκάλυψε παραβίαση δεδομένων που επηρεάζει 890 σχολεία που χρησιμοποιούν τις υπηρεσίες της σε όλες τις Ηνωμένες Πολιτείες.
Σε επιστολή κοινοποίησης παραβίασης που κατατέθηκε στο Γραφείο του Γενικού Εισαγγελέα της Καλιφόρνια, το Clearinghouse ανέφερε ότι οι επιτιθέμενοι απέκτησαν πρόσβαση στον διακομιστή MOVEit managed file transfer (MFT) στις 30 Μαΐου και έκλεψαν αρχεία που περιείχαν ευρύ φάσμα προσωπικών πληροφοριών.
“Στις 31 Μαΐου 2023, το Clearinghouse ενημερώθηκε από τον τρίτο πάροχο λογισμικού μας, την Progress Software, για ένα ζήτημα κυβερνοασφάλειας που αφορούσε τη λύση MOVEit Transfer του παρόχου”, ανέφερε το Clearinghouse.
“Αφού πληροφορηθήκαμε το ζήτημα, ξεκινήσαμε αμέσως έρευνα με την υποστήριξη κορυφαίων εμπειρογνωμόνων στον τομέα της κυβερνοασφάλειας. Συντονιστήκαμε επίσης με τις αρχές επιβολής του νόμου”.
Οι πληροφορίες προσωπικής ταυτοποίησης (PII) που περιέχονται στα κλεμμένα έγγραφα περιλαμβάνουν ονόματα, ημερομηνίες γέννησης, στοιχεία επικοινωνίας, αριθμούς κοινωνικής ασφάλισης, αριθμούς φοιτητικής ταυτότητας και ορισμένα αρχεία που σχετίζονται με το σχολείο (π.χ. αρχεία εγγραφών, αρχεία πτυχίων και δεδομένα σε επίπεδο μαθημάτων).
Σύμφωνα με τις επιστολές κοινοποίησης της παραβίασης δεδομένων, τα δεδομένα που εκτέθηκαν κατά την επίθεση ποικίλλουν για κάθε επηρεαζόμενο άτομο. Ο πλήρης κατάλογος των εκπαιδευτικών οργανισμών που επηρεάστηκαν από αυτή τη μαζική παραβίαση δεδομένων μπορεί να βρεθεί εδώ.
Το Clearinghouse παρέχει εκπαιδευτικές υπηρεσίες αναφοράς, ανταλλαγής δεδομένων, επαλήθευσης και έρευνας σε περίπου 22.000 γυμνάσια και περίπου 3.600 κολέγια και πανεπιστήμια.
Ο οργανισμός αναφέρει ότι οι συμμετέχοντες σε αυτόν εγγράφουν περίπου το 97% των φοιτητών σε δημόσια και ιδιωτικά ιδρύματα.
Η ομάδα Clop ransomware πίσω από τις επιθέσεις MoveIT
Η ομάδα ransomware Clop είναι υπεύθυνη για τις εκτεταμένες επιθέσεις κλοπής δεδομένων που ξεκίνησαν στις 27 Μαΐου, αξιοποιώντας ένα κενό ασφαλείας μηδενικής ημέρας στην πλατφόρμα ασφαλούς μεταφοράς αρχείων MOVEit Transfer.
Από τις 15 Ιουνίου, οι εγκληματίες του κυβερνοχώρου άρχισαν να εκβιάζουν τους οργανισμούς που έπεσαν θύματα των επιθέσεων, εκθέτοντας τα ονόματά τους στον ιστότοπο διαρροής δεδομένων της ομάδας στο dark web.
Οι συνέπειες αυτών των επιθέσεων αναμένεται να επηρεάσουν εκατοντάδες οργανισμούς παγκοσμίως, ενώ πολλοί έχουν ήδη ειδοποιήσει τους πελάτες που έχουν πληγεί τους τελευταίους τέσσερις μήνες.
Παρά την ευρεία δεξαμενή δυνητικών θυμάτων, οι εκτιμήσεις της Coveware δείχνουν ότι μόνο ένας περιορισμένος αριθμός είναι πιθανό να υποκύψει στις απαιτήσεις λύτρων της Clop. Παρ’ όλα αυτά, η συμμορία κυβερνοεγκλήματος αναμένεται να εισπράξει περίπου 75-100 εκατομμύρια δολάρια σε πληρωμές λόγω των υψηλών αιτημάτων λύτρων.
Αναφορές έχουν επίσης αποκαλύψει ότι πολλές ομοσπονδιακές υπηρεσίες των ΗΠΑ και δύο φορείς του Υπουργείου Ενέργειας των ΗΠΑ (DOE) έχουν πέσει θύματα αυτών των επιθέσεων κλοπής δεδομένων και εκβιασμού.
Θρίαμβος για τη BlackBerry: Ανακοινώνει Απροσδόκητα Κέρδη Χάρη στη Ζήτηση για Κυβερνοασφάλεια
Η καναδική εταιρεία BlackBerry (BB.TO) ανακοίνωσε μια απροσδόκητη τριμηνιαία κερδοφορία την Τετάρτη, υποστηριζόμενη από την ανθεκτική ζήτηση για υπηρεσίες κυβερνοασφάλειας μπροστά σε αυξανόμενους διαδικτυακούς κινδύνους.
Παρόλο που οι δαπάνες στην πληροφορική έχουν μειωθεί τον τελευταίο χρόνο, οι δαπάνες που σχετίζονται με την κυβερνοασφάλεια παραμένουν σταθερές, καθώς επιχειρήσεις και κυβερνήσεις βιάζονται να ενισχύσουν τα συστήματά τους εναντίον χάκερ.
Τους τελευταίους μήνες, γίγαντες των καζίνο, όπως η MGM Resorts International (MGM.N) και η Caesars Entertainment (CZR.O), αντιμετώπισαν μεγάλες παραβιάσεις δεδομένων, αναγκάζοντας τις επιχειρήσεις να δώσουν προτεραιότητα στην κυβερνοασφάλεια.
Στις αρχές αυτού του μήνα, η BlackBerry εγκατέλειψε τα σχέδια για δημόσια προσφορά της επιχείρησης του Διαδικτύου των Πραγμάτων (IoT), αλλά παραμένει αναμένεται να διαχωρίσει τις επιχειρήσεις IoT και κυβερνοασφάλειας σε πλήρως αυτόνομες ενότητες.
“Έχει ξεκινήσει ο πλήρης διαχωρισμός και σημαντική αύξηση του μεγέθους των επιχειρήσεών μας, και αναμένουμε να μειώσουμε περαιτέρω τη χρήση των ρευστών μας κατά το τέταρτο τρίμηνο,” δήλωσε ο διευθύνων σύμβουλος John Giamatteo.
Η BlackBerry προτίθεται επίσης να απλοποιήσει την εταιρική δομή της, ώστε κάθε επιχειρηματική μονάδα να λειτουργεί ανεξάρτητα και με κέρδος και θετικό ρευστό.
Η BlackBerry αναμένει έσοδα στο τέταρτο τρίμηνο στο εύρος των 150 εκατομμυρίων δολαρίων έως 159 εκατομμύρια δολάρια.
Η εταιρεία, με έδρα της στο Waterloo του Καναδά, ανακοίνωσε προσαρμοσμένα καθαρά κέρδη 1 σεντ ανά μετοχή στο τέλος του τριμήνου που λήγει στις 30 Νοεμβρίου, σε σύγκριση με απώλεια 5 σεντ ανά μετοχή πριν έναν χρόνο.
Τα έσοδα του τρίτου τριμήνου αυξήθηκαν στα 175 εκατομμύρια δολάρια από 169 εκατομμύρια δολάρια. Οι αναλυτές, κατά μέσο όρο, προέβλεπαν έσοδα 173,5 εκατομμυρίων δολαρίων, σύμφωνα με δεδομένα της LSEG.
Οι μετοχές της εταιρείας στο Χρηματιστήριο ΗΠΑ μειώθηκαν κατά 4% στις επεκτατικές συναλλαγές.
Η Kyivstar Ανακτά τις Υπηρεσίες μετά από Κυβερνοεπίθεση: Οι Συνέπειες και Η Αποκατάσταση
Το μεγαλύτερο κινητό πάροχο υπηρεσιών τηλεφωνίας της Ουκρανίας, η Kyivstar, ανακοίνωσε την Τετάρτη ότι έχει αποκαταστήσει όλες τις υπηρεσίες της εντός και εκτός της χώρας, μια εβδομάδα μετά από μια μαζική κυβερνοεπίθεση που προκάλεσε ζημιές στην υποδομή των πληροφορικών και επηρέασε τα συστήματα συναγερμού αεροπορικών επιδρομών σε μερικά μέρη της χώρας.
Οι υπηρεσίες της εταιρείας, η οποία έχει περισσότερους από το μισό πληθυσμό της Ουκρανίας ως συνδρομητές κινητής τηλεφωνίας, είχαν απενεργοποιηθεί όταν οι χάκερ χρησιμοποίησαν τον λογαριασμό ενός υπαλλήλου για να πραγματοποιήσουν την επίθεση.
“Έχουμε αποκαταστήσει όλες τις υπηρεσίες 100% σε όλη την Ουκρανία, καθώς και στο εξωτερικό… Όλες οι υπηρεσίες της Kyivstar λειτουργούν χωρίς περιορισμούς,” δήλωσε ο διευθύνων σύμβουλος Oleksandr Komarov σε τηλεοπτικά σχόλια.
Μια ομάδα με το όνομα Solntsepyok, που πιστεύεται από την υπηρεσία ασφαλείας SBU της Ουκρανίας ότι συνδέεται με τη ρωσική στρατιωτική πληροφορία, ανέλαβε την ευθύνη για την επίθεση, ευχαριστώντας τους “ανήσυχους συναδέλφους” στη Kyivstar.
Η SBU έχει ανοίξει ποινική υπόθεση.
Ο Komarov είπε ότι η Kyivstar, η οποία ανήκει στην Veon (VON.AS), μια κινητή τηλεπικοινωνιακή εταιρεία με καταγραφείσα έδρα στο Άμστερνταμ, συνεργάζεται με την SBU στην εξέλιξη της έρευνας.
“Έχουμε βγάλει συμπεράσματα, και αρκετά θεμελιώδη. Πιστεύω ότι θα ισχύσουν όχι μόνο για την Kyivstar, αλλά και για πολλές εταιρείες,” πρόσθεσε.
Η κινητή internet, η φωνή και οι υπηρεσίες SMS αποκαταστάθηκαν πρώτες, αν και υπήρχαν ακόμα κάποιες τεχνικές δυσκολίες, συμπεριλαμβανομένης της Τετάρτης, όταν η φωνητική επικοινωνία επηρεάστηκε σε αρκετές περιοχές.
Οι υπηρεσίες λειτουργούν τώρα κανονικά, δήλωσε η εταιρεία σε ξεχωριστή ανακοίνωση στην πλατφόρμα κοινωνικής δικτύωσης X.
Δεν ήταν σαφές πώς οι χάκερ απέκτησαν πρόσβαση στον λογαριασμό του υπαλλήλου, δήλωσε προηγουμένως η Kyivstar, αλλά τα προσωπικά δεδομένα δεν παραβιάστηκαν.
Σοκαριστική Διαρροή: Περισσότερα από 1,3 Εκατομμύρια Αρχεία της Insomniac Games Διέρρευσαν
Περισσότερα από 1,3 εκατομμύρια αρχεία της Insomniac Games, η οποία ανήκει στη Sony (6758.T), συμπεριλαμβανομένων σχεδίων παιχνιδιών, προϋπολογισμών και πληροφοριών για ένα προσεχές παιχνίδι “Wolverine”, διέρρευσαν στο διαδίκτυο από την ομάδα Rhysida ransomware, όπως ανέφερε την Τρίτη η Bloomberg News.
Τα αρχεία δείχνουν ότι η ιαπωνική εταιρεία σχεδιάζει να κυκλοφορήσει αρκετά παιχνίδια εμπνευσμένα από τον κόσμο των Marvel την επόμενη δεκαετία, συμπεριλαμβανομένων του “Spider-Man 3” και εκείνων που βασίζονται σε Venom και X-Men, σύμφωνα με την αναφορά.
Το συμφωνητικό άδειας χρήσης μεταξύ της Insomniac και της Marvel φτάνει τα 621 εκατομμύρια δολάρια για την ανάπτυξη και την προώθηση των παιχνιδιών X-Men έως το 2035, πρόσθεσε η αναφορά.
Η Sony δεν ανταποκρίθηκε σε αίτημα σχολίου από το Reuters.
Η Rhysida ανακοίνωσε τη διαρροή στις 12 Δεκεμβρίου, λέγοντας ότι θα δημοπρατούσε τα δεδομένα για περίπου 2 εκατομμύρια δολάρια σε bitcoin, αλλά αργότερα δημοσίευσε τα δεδομένα την Τρίτη, σύμφωνα με την αναφορά.
Η διαρροή αποτελεί το τελευταίο περιστατικό στη βιομηχανία των παιχνιδιών, μετά τη διαρροή νωρίτερα εικόνων από το “Grand Theft Auto VI” της Take-Two Interactive Software (TTWO.O) πέρυσι, σε ό,τι αποτελεί μία από τις μεγαλύτερες διαρροές παιχνιδιών όλων των εποχών.