Με αυτή την εντολή κάνετε εγκατάσταση το πρόγραμμα μέσω του GitHub.
Πάμε τώρα να μπούμε στον φάκελο που είναι το πρόγραμμα μας. Για να το κάνουμε αυτό πληκτρολογούμε “cd AdvPhishing/”
cd AdvPhishing/
Μπήκαμε στον φάκελο. Τώρα θα τρέξουμε μία άλλη εντολή η οποία θα δώσει δικαιώματα στο πρόγραμμα μας. Η εντολή αυτή είναι η παρακάτω
chmod 777 *
Από εδώ και στο εξής έμειναν μόνο άλλες δύο εντολές να τρέξουμε. Μπορείτε να τις δείτε παρακάτω.
./Linux-Setup.sh
./AdvPhishing.sh
Είμαστε σχεδόν έτοιμοι. Το μόνο που πρέπει να κάνουμε είναι να συνδεθούμε με το Ngrok. Το Ngrok θα μας βοηθήσει στο να κάνει την ιστοσελίδα που θα δημιουργηθεί, να μην φαίνεται μόνο στο δικό μας δίκτυο. Θα καταλάβετε παρακάτω.
Μετά την εντολή “./AdvPhishing.sh” Θα σας ζητηθεί να συνδεθείτε με το Ngrok. Αφου φτίαξετε λογαριασμό εκεί με μία απλή εγγραφή δωρεάν, στο Dashboard σας αν κάνετε λίγο σκρολ θα σας έχει μία εντολή. Κάπως έτσι
./ngrok authtoken "Το authtoken σας"
Αφού το κάνετε Copy Paste, θα σας εμφανίσει μία ολόκληρη λίστα από social media όπως Instagram, Facebook, TikTok, ακόμα και Paypal ή WordPress.
Στην προκειμένη περίπτωση θα επιλέξουμε το Instagram το οποίο είναι ο αριθμός “3”
Πατάμε Enter. Μετά μας εμφανίζει αν θέλουμε να κάνουμε Modify το URL, αλλά εγώ συγκεκριμένα πάτησα “No”
Να το Ngrok που είπαμε πρίν. Όταν λοιπόν στείλουμε το Link που θα μας δώσει στο θύμα και εκείνος το πατήσει, θα τον οδηγίσει κατευθείαν στο Instagram Login. Ας δούμε μία επίθεση στην δικιά μου συσκευή.
Δημιουργήθηκε λοιπόν ένας Κλόνος του Instagram Login. Πάμε να δούμε τι κάνουμε με αυτό; όταν το θύμα πληκτρολογήσει τα στοιχεία σύνδεσής του, αυτομάτως θα έρθουν σε εμάς αφού αυτός πατήσει το κουμπί “Log in”.
Πάμε να δούμε
Username: greekhacking.gr
Password: mata12345678
Πάμε στο πρόγραμμα μας τώρα να δούμε τα αποτελέσματα
Μας έχουν σταλθεί ακριβώς τα στοιχεία. Να προσθέσω ότι αν το όνομα ή ο κωδικός ήταν γραμμένος στα ελληνικά, θα το εμφάνιζε και πάλι. Ενώ στο Setoolkit δεν το εμφανίζει εκτός αν έχουν κάνει κάποια ενημέρωση και δεν το γνωρίζω.
Δεν φέρω καμία ευθύνη για το πως θα χρησιμοποιήσετε το εργαλείο που σας ανέφερα.
Ο Αλέξανδρος είναι ο ιδρυτής του hacks.gr και η κινητήρια δύναμη πίσω από το όραμά μας.
Με πολυετή εμπειρία στον κόσμο του hacking, έχει διαμορφώσει μια κοινότητα που είναι πηγή έμπνευσης και μάθησης για όλους.
Με τον προσωπικό του χαρακτήρα και την τεχνογνωσία του, έχει δημιουργήσει έναν χώρο όπου οι λάτρεις του hacking μπορούν να συναντιούνται, να μοιράζονται γνώσεις και να εξελίσσονται.
Το JoomScan είναι ένα εργαλείο ασφαλείας που χρησιμοποιείται για τον έλεγχο ευπάθειών σε ιστότοπους που χρησιμοποιούν το σύστημα διαχείρισης περιεχομένου (CMS) Joomla. Αναζητά πιθανές αδυναμίες ασφαλείας στον κώδικα του Joomla CMS και στις επεκτάσεις που χρησιμοποιούνται σε αυτόν..
Το joomscan ελέγχει για τα παρακάτω και όχι μόνο:
Ευπάθειες στην εγκατάσταση: Ελέγχει αν η εγκατάσταση του Joomla είναι ευπαθής σε επιθέσεις
Αδυναμίες ασφαλείας στις επεκτάσεις: Ελέγχει τις επεκτάσεις (plugins, components, modules) που χρησιμοποιούνται στον ιστότοπο Joomla για τυχόν ευπάθειες ασφαλείας.
Ευπάθειες SQL Injection: Ελέγχει τον κώδικα του Joomla για ευπάθειες που μπορεί να επιτρέπουν επιθέσεις SQL injection.
Ευπάθειες XSS (Cross-Site Scripting): Ελέγχει για πιθανές ευπάθειες που επιτρέπουν τις επιθέσεις Cross-Site Scripting, οι οποίες μπορούν να παρακάμψουν την ασφάλεια του ιστότοπου.
Ελέγχος αρχείων και καταλόγων: Ελέγχει τον τρόπο πρόσβασης σε αρχεία και καταλόγους στον ιστότοπο, προκειμένου να ανιχνεύσει πιθανές αδυναμίες ασφαλείας.
Αναγνώριση της έκδοσης Joomla: Βοηθά στον προσδιορισμό της έκδοσης του Joomla που χρησιμοποιείται, καθώς αυτό μπορεί να είναι κρίσιμο για την ασφάλεια.
Ακολουθήστε τα παρακάτω βήματα για να εγκαταστήσετε το JoomScan:
1) Πριν εγκαταστήσετε το JoomScan, βεβαιωθείτε ότι έχετε εγκαταστήσει την Perl, την cURL και την libwww-perl.
Αν δεν τις έχετε εγκαταστήσει ήδη, μπορείτε να το κάνετε με τις παρακάτω εντολές: sudo apt-get update sudo apt-get install perl curl libwww-perl
2)Κατεβάστε το JoomScan από το GitHub. Μπορείτε να το κάνετε με την εντολή git: git clone https://github.com/rezasp/joomscan.git
3)Μετάβαση στον κατάλογο του JoomScan: cd joomscan
4)Εκτέλεση του JoomScan:
Τώρα που βρίσκεστε στον κατάλογο του JoomScan, μπορείτε να το εκτελέσετε με την ακόλουθη εντολή:
perl joomscan.pl -u <URL-ιστότοπου>
Αντικαταστήστε <URL-ιστότοπου> με το URL του ιστότοπου Joomla που θέλετε να σαρώσετε.
Το JoomScan θα αρχίσει να σαρώνει τον ιστότοπο και θα παράγει αναφορές σχετικά με τυχόν ευπάθειες ασφαλείας που εντοπίστηκαν.
Ο Αλέξανδρος είναι ο ιδρυτής του hacks.gr και η κινητήρια δύναμη πίσω από το όραμά μας. Με πολυετή εμπειρία στον κόσμο του hacking, έχει διαμορφώσει μια κοινότητα που είναι πηγή έμπνευσης και μάθησης για όλους. Με τον προσωπικό του χαρακτήρα και την τεχνογνωσία του, έχει δημιουργήσει έναν χώρο όπου οι λάτρεις του hacking μπορούν να συναντιούνται, να μοιράζονται γνώσεις και να εξελίσσονται.
Χάκερς τροποποιούν τις σελίδες 404 των ηλεκτρονικών καταστημάτων για να κλέψουν πιστωτικές κάρτες
Μια νέα μορφή επίθεσης κατά των καρτών της Magecart, καταλαμβάνει τις σελίδες σφαλμάτων 404 των ιστότοπων των διαδικτυακών πωλητών, κρύβοντας κακόβουλο κώδικα για να κλέψει τα στοιχεία των πιστωτικών καρτών των πελατών.
Η τεχνική αυτή είναι μία από τις τρεις παραλλαγές που παρατηρήθηκαν από ερευνητές της Akamai Security Intelligence Group, με τις άλλες δύο να κρύβουν τον κώδικα στο χαρακτηριστικό “onerror” της ετικέτας HTML και σε ένα δυαδικό αρχείο εικόνας για να φαίνεται ως το απόσπασμα κώδικα Meta Pixel.
Η Akamai αναφέρει ότι η επίθεση επικεντρώνεται σε ιστότοπους Magento και WooCommerce, με ορισμένα θύματα να συνδέονται με γνωστούς οργανισμούς στους τομείς των τροφίμων και του λιανικού εμπορίου.
Χειραγώγηση σελίδων 404
Όλοι οι ιστότοποι διαθέτουν σελίδες σφάλματος 404, οι οποίες εμφανίζονται στους επισκέπτες όταν έχουν πρόσβαση σε μια ιστοσελίδα που δεν υπάρχει, έχει μετακινηθεί ή έχει έναν νεκρό/σπασμένο σύνδεσμο.
Οι δράστες του Magecart αξιοποιούν την προεπιλεγμένη σελίδα “404 Not Found” για να κρύψουν και να φορτώσουν τον κακόβουλο κώδικα κλοπής καρτών, κάτι που δεν έχει παρατηρηθεί ξανά σε προηγούμενες εκστρατείες.
Ο φορτωτής skimmer είτε μεταμφιέζεται ως ένα απόσπασμα κώδικα Meta Pixel είτε κρύβεται μέσα σε τυχαία inline scripts που υπάρχουν ήδη στην παραβιασμένη ιστοσελίδα πληρωμής.
Ο φορτωτής ξεκινά ένα αίτημα λήψης σε μια σχετική διαδρομή με όνομα “icons”, αλλά καθώς αυτή η διαδρομή δεν υπάρχει στον ιστότοπο, το αίτημα καταλήγει σε σφάλμα “404 Not Found”.
Οι ερευνητές της Akamai υπέθεσαν αρχικά ότι το skimmer δεν ήταν πλέον ενεργό ή ότι η ομάδα Magecart είχε κάνει κάποιο λάθος στη διαμόρφωση. Ωστόσο, κατά την προσεκτικότερη εξέταση, διαπίστωσαν ότι ο φορτωτής περιείχε μια ταυτοποίηση κανονικής έκφρασης που αναζητούσε μια συγκεκριμένη συμβολοσειρά στην επιστρεφόμενη HTML της σελίδας 404.
Κατά τον εντοπισμό της συμβολοσειράς στη σελίδα, η Akamai βρήκε μια συνυφασμένη συμβολοσειρά κωδικοποιημένη με base64, κρυμμένη σε ένα σχόλιο. Η αποκωδικοποίηση αυτής της συμβολοσειράς αποκάλυψε το JavaScript skimmer, το οποίο κρύβεται σε όλες τις σελίδες 404.
Επειδή η αίτηση γίνεται σε μια διαδρομή πρώτου μέρους, τα περισσότερα εργαλεία ασφαλείας που παρακολουθούν ύποπτα αιτήματα δικτύου στη σελίδα πληρωμής θα το παραβλέψουν.
Κλέβοντας τα δεδομένα
Ο κώδικας skimmer εμφανίζει μια ψεύτικη φόρμα την οποία οι επισκέπτες του ιστότοπου αναμένεται να συμπληρώσουν με ευαίσθητα στοιχεία, όπως τον αριθμό της πιστωτικής τους κάρτας, την ημερομηνία λήξης και τον κωδικό ασφαλείας.
Μόλις τα δεδομένα αυτά εισαχθούν στην ψεύτικη φόρμα, το θύμα λαμβάνει ένα ψεύτικο σφάλμα “session timeout”.
Στο παρασκήνιο, όλες οι πληροφορίες κωδικοποιούνται με base64 και αποστέλλονται στον επιτιθέμενο μέσω μιας διεύθυνσης URL αίτησης εικόνας που φέρει τη συμβολοσειρά ως παράμετρο ερώτησης.
Αυτή η προσέγγιση βοηθά στην αποφυγή εντοπισμού από εργαλεία παρακολούθησης της κυκλοφορίας δικτύου, καθώς η αίτηση μοιάζει με ένα καλοήθες συμβάν ανάκτησης εικόνας. Ωστόσο, η αποκωδικοποίηση της συμβολοσειράς base64 αποκαλύπτει προσωπικές πληροφορίες και πληροφορίες πιστωτικής κάρτας.
Η περίπτωση της χειραγώγησης των σελίδων 404 αναδεικνύει τις εξελισσόμενες τακτικές και την ευελιξία των φορέων του Magecart, οι οποίοι συνεχώς δυσκολεύουν τους webmaster να εντοπίσουν τον κακόβουλο κώδικά τους σε παραβιασμένους ιστότοπους και να τον αποκαταστήσουν.
Ήρθε η ώρα να προσπαθήσουμε να εκτελέσουμε buffer overflow (με ανακατεύθυνση) σε ένα λειτουργικό σύστημα Windows 11. Για να δούμε πόσο εύκολο είναι να το κάνεις αυτό… 😎
Θα ακολουθήσουμε την ίδια μέθοδο όπως στο Part ΙΙ.
Ας ξεκινήσουμε με τον πηγαίο κώδικα του μικρού μας προγράμματος επίδειξης, του bufferoverflow.c:
Για όσους θέλουν να αντιγράψουν τον κώδικα, για να γράψουν τα δικά τους παραδείγματα – tests, Ορίστε:
#include<iostream>#include<string>#pragma warning(disable : 4996) //_CRT_SECURE_NO_WARNINGS#pragma runtime_checks("", off)#pragma optimize("", off)
using namespace std;
bool checkProductKey(char*userKey){char key[12];strcpy(key, userKey);
bool n =(strcmp(userKey,"123-456")==0);return n;}intmain(int argc,char* argv[]){char key[255];if(argc !=2){
cout <<"Enter product key >";
cin >> key;}elsestrcpy(key, argv[1]);
bool iAllow =checkProductKey(key);if(!iAllow){
cout <<"Wrong key!\n";return-1;}
cout <<"Welcome to the DEMO SA Application.\n";
cout <<"(c) 2023 all rights reserved.\n";return0;}
Δεν θα μπω στον κόπο να εξηγήσω τι κάνει το παραπάνω πρόγραμμα μιας και ο κώδικας του είναι πολύ προφανής. Πρόκειται για πρόγραμμα σε C, που τρέχει από τη γραμμή εντολών των Windows Powershell .
Παρακάτω βλέπετε την εκτέλεση του προγράμματος με διάφορες παραμέτρους :
Ένα από τα πιο σημαντικά σημεία για να δουλέψετε το bof είναι να επιλέξετε τις σωστές παραμέτρους compiler & linker.
Χρησιμοποιώ ένα console project σε C++ στο Visual Studio 2022 και αλλάζω ορισμένες προεπιλεγμένες παραμέτρους όπως υποδεικνύουν οι παρακάτω εικόνες.
Σημειώστε ότι ορισμένες παραμέτρους τις έχω ήδη ρυθμίσει από τον πηγαίο κώδικα, χρησιμοποιώντας οδηγίες pragma, αλλά για λόγους σαφήνειας θα επαναλάβω όλη τη διαδικασία εδώ:
1. Απενεργοποιήστε το επίπεδο προειδοποίησης (όχι απολύτως απαραίτητο αλλά χρήσιμο για αυτό το μικρό πρόγραμμα για να αποφύγετε κάποια ενοχλητικά μηνύματα)
2. Απενεργοποιήστε τους ελέγχους κύκλου ζωής ανάπτυξης ασφαλούς κώδικα – SDL=Security Development Lifecycle.
Δεν θέλω ο Optimizer να αλλάξει τίποτα στον κώδικά μου… (και στις δύο παραπάνω περιπτώσεις)
1. Ορίζω τα runtime checks στο default
2. Απενεργοποιώ κάθε security check
1. Απενεργοποιώ το ASLR (Address Space Layout Randomization)
2. Απενεργοποιώ το DEP (Data Execution Prevention), για να μπορώ να εκτελέσω κώδικα στο τμήμα μνήμης του STACK.Αυτό είναι απαραίτητο μόνο εάν θα ήθελα να εκτελέσω έναν shell στo Stack, αλλά δεν είναι απαραίτητο εάν εκτελέσω ένα Buffer Overflow με και απλώς αντικαταστήσω τη διεύθυνση RET για να ανακατευθύνω το πρόγραμμά μου σε διαφορετική θέση στον ίδιο κώδικα (τμήμα) –όπως έκανα στο μέρος II σε ένα BOX Linux.
Για να συνοψίσω όλες τις επιλογές που έθεσα για τη μεταγλώττιση του προγράμματός μου: /JMC /permissive- /ifcOutput "Debug\" /GS- /analyze- /W0 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"Debug\vc143.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /MDd /FC /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\BufferOverflow.pch" /diagnostics:column
Ήρθε λοιπόν η ώρα να ξεκινήσω τις δοκιμές μου και να ελέγξω τη συμπεριφορά του προγράμματος. Θα κάνω δύο τύπους δοκιμών:
Στην πρώτη μου δοκιμή θα περάσω μια μεγάλη συμβολοσειρά ως παράμετρο, μεγαλύτερη από αυτή που ορίζεται στη γραμμή 9 (του πηγαίου κώδικα).
Στο δεύτερο τεστ θα περάσω μια σύντομη συμβολοσειρά ως παράμετρο, προκειμένου να ελέγξω την κανονική λειτουργία του προγράμματος.
Επιπλέον θα βάλω κάποια breakpoints και θα ελέγξω την κατάσταση της μνήμης και κάποιες σημαντικές σημαίες (flags).
Για την 1η δοκιμή μου (την υπερχείλιση) έβαλα αυτό το όρισμα γραμμής εντολών στο πρόγραμμα εντοπισμού σφαλμάτων:
Η γνωστή συμβολοσειρά (που χρησιμοποιείται σε δοκιμές bof) ενός μοτίβου 4 bytes (το μέγεθος μιας διεύθυνσης μνήμης σε συστήματα 32 bit): AAAABBBBCCCCDDDDEEEE.
Για το δεύτερο τεστ μου (το κανονικό!) εισάγω απλώς αυτό:
Μόλις 10 “Α”.
Ας δούμε τώρα τι θα συμβεί όταν εκτελέσω τις δοκιμές μου, μελετώντας τις παρακάτω εικόνες:
Έβαλα ένα σημείο διακοπής (breakpoint) στη γραμμή 24, εκεί που καλείται η συνάρτηση checkProductKey.
Επιπλέον, έχω ενεργοποιήσει τρία σημαντικά Windows για να έχω όσο το δυνατόν περισσότερες πληροφορίες. Σημαντική σημείωση : Για να δείτε και να επιλέξετε τις παρακάτω επιλογές, το πρόγραμμα πρέπει να εκτελείται και να διακοπεί κάποιο breakpoint – διαφορετικά αυτές οι επιλογές δεν είναι ορατές).
Το Disassembly window (επιλέγοντας: Debug | Windows | Disassebly).
Το Memory window (επιλέγοντας: Debug | Windows | Memory | Memory 1)
Το Registers window (επιλέγοντας: Debug | Windows | Registers)
Ενώ η εκτέλεση έχει σταματήσει στο συγκεκριμένο σημείο διακοπής (στη γραμμή 24) επιλέγω το παράθυρο Disassembly:
[Κύρια εικόνα] : Όπως μπορούμε να δούμε την κλήση checkProductKey που βρίσκεται στη διεύθυνση μνήμης: 0x00414215 (θυμηθείτε: οι διευθύνσεις δίνονται σε δεκαεξαδική μορφή).
Συμβουλή: βλέπετε το textbox πάνω από το disassembly window – εκεί που λέει “Address: main(int, char * *)”: Εδώ μπορούμε να εισάγουμε για να δούμε τον κώδικα της κύριας συνάρτησης ή μπορούμε να δώσουμε οποιαδήποτε άλλη function, όπως η checkProductKey.
Το ίδιο ισχύει και για το παράθυρο μνήμης (Memory window), εγώ το χρησιμοποιώ για να εισάγω διευθύνσεις μνήμης.
Συνεχίζω την εκτέλεση μέχρι το τελευταίο breakpoint, μέσα στη συνάρτηση checkProductKey , ακριβώς πριν η συνάρτηση επιστρέψει στον καλούντα της (στη γραμμή 12) παρακάτω:
Παραπάνω, βλέπω την κλασική δομή Stack.
Εάν ελέγξετε το παράθυρο Registers θα δείτε επίσης ότι ο Base Pointer βρίσκεται στη διεύθυνση 0x0019FD8C όπως φαίνεται στην εικόνα.
Αμέσως μετά τον Base Pointer βρίσκεται η Διεύθυνση RET. Αυτός είναι ο στόχος μου!
Συνεχίζοντας την εκτέλεση λαμβάνω ένα σφάλμα παραβίασης πρόσβασης :
Αν υποθέσουμε ότι διαβάσατε τα Parts IΙ και IIΙ, είναι πλέον εύκολο να καταλάβετε γιατί: Όταν τελειώσει ο έλεγχος της συνάρτησης ProductKey, ο EIP λαμβάνει τη διεύθυνση RET (που έχει γεμίσει με “E” – 45 το οποίο είναι ο 16δικός κωδικός ascii του “E”) και προσπαθεί να επιστρέψει σε αυτήν τη διεύθυνση, την 0x45.45.45.45. Ωστόσο, αυτή η διεύθυνση δεν υπάρχει, εξ ου και το μήνυμα λάθους “Access violation reading location 0x45454545”.
Για λόγους σαφήνειας, επιτρέψτε μου να σας υπενθυμίσω ξανά κάποια πράγματα που συζητήσαμε στο Μέρος ΙΙ:
Το παρακάτω είναι μια σχηματική αναπαράσταση αυτού που βλέπουμε στη Στοίβα μας ενώ εκτελείται η συνάρτηση checkProductKey :
Εισάγοντας μια πολύ μεγάλη συμβολοσειρά που περνάει ως παράμετρος η συνάρτησή μας, υπερκαλύπτει και αντικαθιστά και τις διευθύνσεις: EBP και RET!
Κοιτάξτε τώρα, πώς φαίνεται η ίδια δομή κατά την εκτέλεση της 2ης δοκιμής μας: Η κανονική: “AAAAAAAAAA”
Εδώ, τα πράγματα είναι πιο ξεκάθαρα: Αφού τελειώσει η συνάρτηση, θα επιστρέψει στη διεύθυνση καλούντος της, όπως υποδεικνύουν οι διευθύνσεις RET είναι: 0x00414221 (θυμηθείτε ότι ακολουθείται το μοντέλο little endian – διαβάζουμε από τη μνήμη με αντίστροφη σειρά).
Μπορείτε να διασταυρώσετε με το [Main Image] για να ελέγξετε την ακριβή διεύθυνση (το 0x00414221 ) που θα πάει η λειτουργικότητα του προγράμματός μας.
Αυτό σημαίνει επίσης (όπως είπαμε ήδη στα τρία προηγούμενα Parts των άρθρων μας), ότι ο EIP θα είναι 0x00414221.
Ή, με άλλα λόγια EIP = RET Address (at lines 12 & 13 above) είναι αυτό που ονομάζουμε Function Epilogue.
Μέχρι στιγμής όλα καλά: Γνωρίζουμε την ακριβή συμβολοσειρά που θα μπορεί να αντικαταστήσει τη διεύθυνση RET. Αυτή είναι η “AAAABBBBCCCCDDDDEEEE”
Τώρα αυτό που πρέπει να κάνουμε είναι να αντικαταστήσουμε το EEEE με μια υπάρχουσα διεύθυνση για να ανακατευθύνουμε το πρόγραμμα για να παρακάμψουμε τον έλεγχο ProductKey.
Μπορούμε να βρούμε αυτή τη διεύθυνση διαβάζοντας τον disassembly κώδικα: Βρισκόταν μερικές διευθύνσεις κάτω (δεν φαίνεται στην εικόνα) της [Κύριας Εικόνας]. Εκεί που εμφανίζουμε τα μηνύματα καλωσορίσματος.
Είναι ακριβώς εδώ:
Αυτή είναι η διεύθυνση που ψάχνουμε: 0x41424D !!
Είμαστε έτοιμοι,… σχεδόν!!
Όπως γνωρίζουμε, βρισκόμαστε σε λειτουργία εντοπισμού σφαλμάτων (debug mode). Η πραγματική διεύθυνση του προγράμματος όταν εκτελείται σε release mode είναι συνήθως μια ελαφρώς διαφορετική διεύθυνση…
Αυτό που χρειαζόμαστε στην πραγματικότητα είναι την διεύθυνση σε release mode. Για αυτόν τον λόγο δημιουργούμε το τελικό εκτελέσιμο αρχείο σε release mode:
Προσοχή στην παγίδα: Όταν αλλάζετε το πρόγραμμα από Debug σε Release mode, όλες οι παράμετροι compiler & linker επαναφέρονται στις προεπιλεγμένες τους τιμές { 👿 👿 }, επομένως πρέπει να τις επαναφέρετε ακολουθώντας τις ρυθμίσεις που έκανα στην αρχή του άρθρου.
Τέλος, δημιούργησα ένα εκτελέσιμο αρχείο που είναι πολύ μικρότερο από αυτό που είχα με τις πληροφορίες εντοπισμού σφαλμάτων.
Αλλά πώς στο καλό, μπορώ να βρώ αυτήν τη διεύθυνση τώρα, με δεδομένο ότι δεν μπορώ πια να ψάξω σε debug mode, μέσω του Visual Studio;
Χμ… εδώ χρειάζεται λίγο Reversing ακόμα… και για αυτό το λόγο θα χρησιμοποιήσω ένα παλιό εργαλείο που ονομάζεται: Olly Debugger v.1.1 . Φυσικά μπορείτε να χρησιμοποιήσετε όσες άλλες επιλογές θέλετε, πολλές από αυτές χρησιμοποιούνται για τον εντοπισμό σφαλμάτων / αποσυναρμολόγηση ενός εκτελέσιμου αρχείου, όπως x32dbg , IDA κ.λπ…
Εκτελώντας το τελικό εκτελέσιμο αρχείο στο Olly, μπορώ εύκολα να εντοπίσω τη διεύθυνση της συνάρτησης checkProductKey :
Όπως μπορείτε να δείτε παραπάνω, έχω αναδημιουργήσει το ίδιο περιβάλλον που είχα στη λειτουργία εντοπισμού σφαλμάτων του Visual Studio.
Όπως μπορείτε επίσης να δείτε (στο κάτω δεξιό μέρος – στο τμήμα της μνήμης), η διεύθυνση υπερχείλισης είναι λίγο… μεταγενέστερη σε σχέση με τη λειτουργία εντοπισμού σφαλμάτων. Το EBP συμπληρώνεται με 66.66.66.66 (“f”) ενώ εισάγω τη συμβολοσειρά “aaaaabbbbccddddeeeeeffff”. Αυτό σημαίνει ότι η διεύθυνση RET είναι αμέσως μετά το EBP, δηλαδή εδώ: aaaaabbbbccddddeeeeffffXXXX
Το ερώτημα τώρα είναι: Πού είναι η διεύθυνση που εμφανίζουμε τα μηνύματα καλωσορίσματος;
Αυτή είναι η διεύθυνση που πρέπει να βάλουμε στη θέση του XXXX παραπάνω για να αναγκάσουμε το πρόγραμμα να παρακάμψει όλους τους ελέγχους ProductKey.
Λοιπόν, δεν είναι τόσο δύσκολο να το βρείτε χρησιμοποιώντας τον Olly:
Ο μαγικός αριθμός είναι: 0x0040138B
Τώρα, ας δημιουργήσουμε το exploit μας σε ένα αρχείο χρησιμοποιώντας έναν Επεξεργαστή HEX. Αυτό είναι το εύκολο μέρος:
Θυμηθείτε, εισάγουμε το aaaaabbbbccccdddeeeeeffff 8B134000 . Θυμηθείτε τη διεύθυνση με αντίστροφη σειρά ανά byte: 8B.13.40.00 είναι η διεύθυνση διεύθυνση στόχος μας: 00.40.13.8B
και αποθηκεύω το αρχείο με το όνομα args στο δίσκο.
Λοιπόν… Ας το δοκιμάσουμε τώρα, για να δούμε τι έχουμε καταφέρει μέχρι τώρα:
Bingo! Καταφέραμε μια επιτυχημένη παράκαμψη των μέτρων ασφαλείας του προγράμματος με ανακατεύθυνση υπερχείλισης buffer!
Όπως μπορείτε να δείτε παρακάτω, η εκμετάλλευσή της αδυναμίας λειτουργεί επίσης και χωρίς να περάσω αναγκαστικά τα ορίσματα από την γραμμή εντολών. Χρησιμοποιώ την ανακατεύθυνση,…
Επίλογος
Αυτό είναι το τέλος της στοιχειώδους σειράς άρθρων μου σχετικά με τον τρόπο εκτέλεσης υπερχείλισης buffer και δοκιμής των αποτελεσμάτων και αποφυγής ορισμένων παγίδων.
Αυτό που θα ήθελα να δείξω στην πραγματικότητα, ΔΕΝ είναι μόνο πώς να κάνω το πραγματικό bof. Πιστεύω ότι αυτό που μετράει δεν είναι μόνο ο προορισμός αλλά το ίδιο το ταξίδι.
Η εμπειρία, τα εργαλεία, οι συμβουλές, τα κόλπα και οι παγίδες που αντιμετωπίζετε κατά τη διάρκεια του ταξιδιού, είναι ο πραγματικός στόχος.
Και αυτό δεν ισχύει μόνο για ένα ταπεινό Buffer Overflow… 😉
Με πολύτιμη εμπειρία στον κόσμο της κυβερνοασφάλειας συμβάλλει ενεργά στην κοινότητά μας με αναλύσεις ευπαθειών και οδηγούς.
Με τη συνεισφορά του, προσφέρει στην κοινότητα μας ένα πλούσιο φάσμα γνώσεων και δεξιοτήτων που ενισχύουν την ανάπτυξη και την ασφάλεια του ψηφιακού μας κόσμου.
Hey 😊 kudos my man
BONJOUR M.
its not giving me the right url only 82.ngrok.com and its not working