Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –Deadglyph – Νέο κακόβουλο λογισμικό που χρησιμοποιείται σε κυβερνητικές επιθέσεις | – #1 Το Hacking σε... απλά ελληνικά –
Ένα νέο και εξελιγμένο κακόβουλο λογισμικό backdoor με την ονομασία “Deadglyph” χρησιμοποιήθηκε σε μια επίθεση κυβερνοκατασκοπείας εναντίον μιας κυβερνητικής υπηρεσίας στη Μέση Ανατολή.
Το κακόβουλο λογισμικό Deadglyph αποδίδεται στην APT Stealth Falcon (ή αλλιώς Project Raven ή FruityArmor), μια κρατικά χρηματοδοτούμενη ομάδα χάκερ από τα Ηνωμένα Αραβικά Εμιράτα (ΗΑΕ).
Η ομάδα hacking είναι γνωστή για τη στοχοποίηση ακτιβιστών, δημοσιογράφων και αντιφρονούντων εδώ και σχεδόν μια δεκαετία.
Σε μια νέα έκθεση που δημοσιεύθηκε στο συνέδριο κυβερνοασφάλειας LABScon, ο ερευνητής της ESET Filip Jurčacko μοιράζεται ανάλυση του νέου αρθρωτού κακόβουλου λογισμικού και του τρόπου με τον οποίο μολύνει συσκευές Windows.
Επιθέσεις Deadglyph
Η ESET δεν έχει εικόνα για τα μέσα της αρχικής μόλυνσης, αλλά υπάρχει η υποψία ότι χρησιμοποιείται ένα κακόβουλο εκτελέσιμο αρχείο, πιθανώς ένα πρόγραμμα εγκατάστασης.
Ωστόσο, η ESET απέκτησε τα περισσότερα από τα συστατικά της αλυσίδας μόλυνσης για να σχηματίσει μια εικόνα του τρόπου με τον οποίο το κακόβουλο λογισμικό λειτουργεί και προσπαθεί να αποφύγει την ανίχνευση.
Η αλυσίδα φόρτωσης του Deadglyph ξεκινά με έναν φορτωτή shellcode του μητρώου (DLL) που εξάγει κώδικα από το μητρώο των Windows για να φορτώσει το συστατικό Executor (x64), το οποίο με τη σειρά του φορτώνει το συστατικό Orchestrator (.NET).
Μόνο το αρχικό συστατικό υπάρχει στο δίσκο του μολυσμένου συστήματος ως αρχείο DLL, ελαχιστοποιώντας την πιθανότητα εντοπισμού.
Η ESET αναφέρει ότι ο φορτωτής θα φορτώσει τον shellcode από το μητρώο των Windows, το οποίο είναι κρυπτογραφημένο για να κάνει την ανάλυση πιο δύσκολη.
Καθώς το συστατικό DLL αποθηκεύεται στο σύστημα αρχείων, είναι πιο πιθανό να εντοπιστεί. Εξαιτίας αυτού, οι απειλητικοί φορείς χρησιμοποίησαν μια ομογλυφική επίθεση στον πόρο VERSIONINFO χρησιμοποιώντας διακριτούς ελληνικούς και κυριλλικούς χαρακτήρες Unicode για να μιμηθούν τις πληροφορίες της Microsoft και να εμφανιστούν ως νόμιμο αρχείο των Windows.
Το στοιχείο Executor φορτώνει κρυπτογραφημένες με AES διαμορφώσεις για την κερκόπορτα, αρχικοποιεί το .NET runtime στο σύστημα, φορτώνει το .NET τμήμα της κερκόπορτας και ενεργεί ως βιβλιοθήκη της.
Τέλος, το Orchestrator είναι υπεύθυνο για τις επικοινωνίες του διακομιστή εντολών και ελέγχου (C2), χρησιμοποιώντας δύο ενότητες για την εργασία αυτή, το ‘Timer’ και το ‘Network’.
Εάν η κερκόπορτα δεν καταφέρει να δημιουργήσει επικοινωνία με τον διακομιστή C2 μετά από ένα καθορισμένο χρονικό διάστημα, ενεργοποιεί έναν μηχανισμό αυτοαφαίρεσης για να αποτρέψει την ανάλυσή της από ερευνητές και ειδικούς σε θέματα κυβερνοασφάλειας.
Αρθρωτό κακόβουλο λογισμικό
Το κακόβουλο λογισμικό Deadglyph είναι αρθρωτό, δηλαδή θα κατεβάζει νέες ενότητες από το C2 που περιέχουν διαφορετικούς κωδικούς κελύφους για να εκτελεστούν από το στοιχείο Executor.
Η χρήση μιας σπονδυλωτής προσέγγισης επιτρέπει στους φορείς απειλών να δημιουργούν νέες ενότητες ανάλογα με τις ανάγκες για να προσαρμόζουν τις επιθέσεις, οι οποίες μπορούν στη συνέχεια να προωθηθούν στα θύματα για να εκτελέσουν πρόσθετες κακόβουλες λειτουργίες.
Αυτές οι ενότητες έχουν στη διάθεσή τους τα Windows και τα προσαρμοσμένα API του Executor, με το τελευταίο να προσφέρει 39 λειτουργίες που καθιστούν δυνατή την εκτέλεση λειτουργιών αρχείων, τη φόρτωση εκτελέσιμων αρχείων, την πρόσβαση σε Token Impersonation και την εκτέλεση κρυπτογράφησης και κατακερματισμού.
Η ESET πιστεύει ότι υπάρχουν εννέα έως δεκατέσσερις διαφορετικές ενότητες, αλλά μπόρεσε να αποκτήσει μόνο τρεις: έναν δημιουργό διεργασιών, έναν συλλέκτη πληροφοριών και έναν αναγνώστη αρχείων.
Ο συλλέκτης πληροφοριών χρησιμοποιεί ερωτήματα WMI για να τροφοδοτήσει τον Orchestrator με τις ακόλουθες πληροφορίες σχετικά με το παραβιασμένο σύστημα:
operating system
network adapters
installed software
drives
services
drivers
processes
users
environment variables
security software
Ο δημιουργός διεργασιών είναι ένα εργαλείο εκτέλεσης εντολών που εκτελεί καθορισμένες εντολές ως νέα διεργασία και δίνει το αποτέλεσμα στον Orchestrator.
Η μονάδα ανάγνωσης αρχείων διαβάζει το περιεχόμενο των αρχείων και το παραδίδει στον Orchestrator, ενώ δίνει επίσης στους χειριστές τη δυνατότητα να διαγράψουν το αρχείο μετά την ανάγνωση.
Παρόλο που η ESET κατάφερε να αποκαλύψει μόνο ένα μέρος των δυνατοτήτων του κακόβουλου λογισμικού, είναι σαφές ότι το Deadglyph του Stealth Falcon είναι μια τρομερή απειλή.
Χωρίς λεπτομερείς πληροφορίες σχετικά με την αρχική μόλυνση, η προσφορά συγκεκριμένων στρατηγικών άμυνας κατά του κακόβουλου λογισμικού είναι αδύνατη.
Προς το παρόν, οι αμυντικοί μπορούν να βασίζονται στις υπάρχουσες IoC που δημοσιεύονται στην έκθεση.
Η ομάδα hackers Evasive Gelsemium εντοπίστηκε σε επίθεση κατά της ασιατικής κυβέρνησης
Μια προηγμένη απειλή (APT) που εντοπίστηκε ως Gelsemium παρατηρήθηκε σε επιθέσεις με στόχο μια κυβέρνηση της Νοτιοανατολικής Ασίας που διήρκεσαν έξι μήνες μεταξύ 2022 και 2023.
Η Gelsemium είναι μια ομάδα κυβερνοκατασκοπείας που λειτουργεί από το 2014 και στοχεύει κυβερνήσεις, εκπαιδευτικούς φορείς και κατασκευαστές ηλεκτρονικών ειδών στην Ανατολική Ασία και τη Μέση Ανατολή.
Η έκθεση της ESET από το 2021 χαρακτηρίζει την ομάδα απειλών ως “αθόρυβη”, υπογραμμίζοντας την τεράστια τεχνική ικανότητα και τις γνώσεις προγραμματισμού που τη βοήθησαν να πετάξει κάτω από το ραντάρ για πολλά χρόνια.
Μια νέα έκθεση της Μονάδας 42 της Palo Alto Network αποκαλύπτει πώς μια νέα εκστρατεία της Gelsemium χρησιμοποιεί σπάνια παρατηρούμενα backdoors που συνδέονται με τους φορείς απειλής με μέτρια εμπιστοσύνη.
Πρόσφατες επιθέσεις της Gelsemium
Η αρχική παραβίαση των στόχων της Gelsemium επιτεύχθηκε μέσω της εγκατάστασης κελυφών ιστού, πιθανότατα μετά την εκμετάλλευση ευπαθειών σε διακομιστές που έχουν πρόσβαση στο διαδίκτυο.
Η Μονάδα 42 αναφέρει ότι είδε τα κελύφη ιστού “reGeorg”, “China Chopper” και “AspxSpy”, τα οποία είναι δημόσια διαθέσιμα και χρησιμοποιούνται από πολλές ομάδες απειλών, καθιστώντας την απόδοση δύσκολη.
Χρησιμοποιώντας αυτά τα κελύφη ιστού, το Gelsemium πραγματοποίησε βασική αναγνώριση δικτύου, μετακινήθηκε πλευρικά μέσω SMB και ανέκτησε πρόσθετα ωφέλιμα φορτία.
Αυτά τα πρόσθετα εργαλεία που βοηθούν στην πλευρική μετακίνηση, τη συλλογή δεδομένων και την κλιμάκωση προνομίων περιλαμβάνουν τα OwlProxy, SessionManager, Cobalt Strike, SpoolFool και EarthWorm.
Το Cobalt Strike είναι μια ευρέως χρησιμοποιούμενη σουίτα δοκιμών διείσδυσης, το EarthWorm είναι ένας δημόσια διαθέσιμος tunneler SOCKS και το SpoolFool είναι ένα τοπικό εργαλείο κλιμάκωσης προνομίων ανοικτού κώδικα, οπότε αυτά τα τρία δεν αφορούν ειδικά το Gelsemium.
Ωστόσο, το OwlProxy είναι ένα μοναδικό, προσαρμοσμένο εργαλείο HTTP proxy και backdoor της Μονάδας 42 αναφέρει ότι το Gelsemium το χρησιμοποίησε σε μια παλαιότερη επίθεση με στόχο την κυβέρνηση της Ταϊβάν.
Στην τελευταία εκστρατεία, ο δράστης της απειλής ανέπτυξε ένα εκτελέσιμο πρόγραμμα που αποθήκευσε ένα ενσωματωμένο DLL (wmipd.dll) στο δίσκο του παραβιασμένου συστήματος και δημιούργησε μια υπηρεσία που το εκτελεί.
Το DLL είναι μια παραλλαγή του OwlProxy, το οποίο δημιουργεί μια υπηρεσία HTTP που παρακολουθεί τις εισερχόμενες αιτήσεις για συγκεκριμένα μοτίβα URL που κρύβουν εντολές.
Οι ερευνητές λένε ότι τα προϊόντα ασφαλείας στο σύστημα-στόχο εμπόδισαν την εκτέλεση του OwlProxy, οπότε οι επιτιθέμενοι επέστρεψαν στη χρήση του EarthWorm.
Το δεύτερο προσαρμοσμένο εμφύτευμα που σχετίζεται με το Gelsemium είναι το SessionManager, μια κερκόπορτα IIS που η Kaspersky συνέδεσε με την ομάδα απειλών το περασμένο καλοκαίρι.
Το δείγμα της πρόσφατης επίθεσης παρακολουθούσε τις εισερχόμενες αιτήσεις HTTP, αναζητώντας ένα συγκεκριμένο πεδίο Cookie που μεταφέρει εντολές για εκτέλεση στον υπολογιστή.
Οι εντολές αυτές αφορούν τη μεταφόρτωση αρχείων στον ή από τον διακομιστή C2, την εκτέλεση εντολών, την εκκίνηση εφαρμογών ή τη διαμεσολάβηση για συνδέσεις σε πρόσθετα συστήματα.
Η λειτουργία μεσολάβησης στο πλαίσιο των OwlProxy και SessionManager δείχνει την πρόθεση των φορέων απειλής να χρησιμοποιήσουν τον παραβιασμένο διακομιστή ως πύλη για την επικοινωνία με άλλα συστήματα στο δίκτυο-στόχο.
Ήρθε η ώρα να προσπαθήσουμε να εκτελέσουμε 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… 😉
Με πολύτιμη εμπειρία στον κόσμο της κυβερνοασφάλειας συμβάλλει ενεργά στην κοινότητά μας με αναλύσεις ευπαθειών και οδηγούς.
Με τη συνεισφορά του, προσφέρει στην κοινότητα μας ένα πλούσιο φάσμα γνώσεων και δεξιοτήτων που ενισχύουν την ανάπτυξη και την ασφάλεια του ψηφιακού μας κόσμου.
Η ενημέρωση της Apple διορθώνει νέα zero-day που χρησιμοπούνται για iPhones hack
Η Apple κυκλοφόρησε επείγουσες ενημερώσεις ασφαλείας για να επιδιορθώσει ένα νέο κενό ασφαλείας μηδενικής ημέρας που αξιοποιείται σε επιθέσεις με στόχο χρήστες iPhone και iPad.
Η ευπάθεια (CVE-2023-42824) προκαλείται από μια αδυναμία που ανακαλύφθηκε στον πυρήνα XNU, η οποία επιτρέπει σε τοπικούς επιτιθέμενους να κλιμακώσουν τα προνόμιά τους σε iPhone και iPad που δεν έχουν επιδιορθωθεί.
Ενώ η Apple δήλωσε ότι αντιμετώπισε το ζήτημα ασφαλείας στο iOS 17.0.3 και στο iPadOS 17.0.3 με βελτιωμένους ελέγχους, δεν έχει αποκαλύψει ακόμη ποιος βρήκε και ανέφερε το ελάττωμα.
Ο κατάλογος των επηρεαζόμενων συσκευών είναι αρκετά εκτενής και περιλαμβάνει:
iPhone XS και νεότερα μοντέλα
iPad Pro 12,9 ιντσών 2ης γενιάς και μεταγενέστερα, iPad Pro 10,5 ιντσών, iPad Pro 11 ιντσών 1ης γενιάς και μεταγενέστερα, iPad Air 3ης γενιάς και μεταγενέστερα, iPad 6ης γενιάς και μεταγενέστερα και iPad mini 5ης γενιάς και μεταγενέστερα.
Η Apple αντιμετώπισε επίσης μια μηδενική ημέρα που εντοπίζεται ως CVE-2023-5217 και προκαλείται από μια αδυναμία υπερχείλισης buffer σωρού στην κωδικοποίηση VP8 της βιβλιοθήκης κωδικοποίησης βίντεο ανοικτού κώδικα libvpx, η οποία θα μπορούσε να επιτρέψει την εκτέλεση αυθαίρετου κώδικα μετά από επιτυχή εκμετάλλευση.
Το σφάλμα libvpx είχε επιδιορθωθεί προηγουμένως από την Google στο πρόγραμμα περιήγησης ιστού Chrome και από τη Microsoft στα προϊόντα Edge, Teams και Skype.
Το CVE-2023-5217 ανακαλύφθηκε από τον ερευνητή ασφαλείας Clément Lecigne, ο οποίος ανήκει στην Ομάδα Ανάλυσης Απειλών (TAG) της Google, μια ομάδα εμπειρογνωμόνων ασφαλείας που είναι γνωστή για τη συχνή εύρεση zero-days που χρησιμοποιούνται καταχρηστικά σε κυβερνητικά υποστηριζόμενες στοχευμένες επιθέσεις κατασκοπευτικού λογισμικού που στοχεύουν άτομα υψηλού κινδύνου.
17 zero-days που αξιοποιήθηκαν σε επιθέσεις, διορθώθηκαν φέτος
Το CVE-2023-42824 είναι η 17η ευπάθεια μηδενικής ημέρας που αξιοποιείται σε επιθέσεις και την οποία η Apple έχει διορθώσει από την αρχή του έτους.
Η Apple επιδιόρθωσε επίσης πρόσφατα τρία άλλα σφάλματα μηδενικής ημέρας (CVE-2023-41991, CVE-2023-41992 και CVE-2023-41993) που αναφέρθηκαν από ερευνητές των Citizen Lab και Google TAG και αξιοποιήθηκαν σε επιθέσεις spyware για την εγκατάσταση του spyware Predator της Cytrox.
Η Citizen Lab αποκάλυψε δύο άλλα zero-day (CVE-2023-41061 και CVE-2023-41064) -που διορθώθηκαν από την Apple τον περασμένο μήνα- και χρησιμοποιήθηκαν ως μέρος μιας αλυσίδας εκμετάλλευσης μηδενικού κλικ (που ονομάστηκε BLASTPASS) για να μολύνουν πλήρως επιδιορθωμένα iPhones με το spyware Pegasus της NSO Group.
Από τον Ιανουάριο του 2023, η Apple έχει αντιμετωπίσει συνολικά 17 zero-days που αξιοποιήθηκαν για να στοχεύσουν iPhones και Mac, μεταξύ των οποίων:
δύο zero-days (CVE-2023-37450 και CVE-2023-38606) τον Ιούλιο
τρία zero-days (CVE-2023-32434, CVE-2023-32435 και CVE-2023-32439) τον Ιούνιο
τρία ακόμη zero-days (CVE-2023-32409, CVE-2023-28204 και CVE-2023-32373) τον Μάιο
δύο zero-days (CVE-2023-28206 και CVE-2023-28205) τον Απρίλιο
και μια άλλη μηδενική ημέρα του WebKit (CVE-2023-23529) τον Φεβρουάριο
Η σημερινή έκδοση iOS 17.0.3 αντιμετωπίζει επίσης ένα γνωστό πρόβλημα που προκαλεί υπερθέρμανση των iPhones με iOS 17.0.2 και νεότερες εκδόσεις.
