Τις περισσότερες φορές που συναντάμε εφαρμογή η οποία χρειάζεται να επικοινωνήσει με DC μέσω ldap (389 tcp) τότε το προτιμότερο είναι να χρησιμοποιήσουμε το secure ldap ή ldap ssl ώστε να προστεθεί ένα παραπάνω layer που θα παρέχει encryption άρα και ασφάλεια στην επικοινωνία. Το ldap είναι όπως φαίνεται και από τα παραπάνω clear text protocol άρα αν έχετε στήσει το νέο σας proxy, web service etc το οποίο χρησιμοποιεί ldap για να κάνει authenticate τους χρήστες είναι σίγουρο πως αν κάποιος κάνει trace στο ενδιάμεσο τότε έχει πολλούς κωδικούς να μαζέψει.

Κάτι ακόμα που συναντάω συχνά είναι πως όταν υπάρχει απαίτηση να δοθεί στην εφαρμογή username/password για τα ldap queries δίνεται εύκολα Domain Admin account, φανταστείτε λοιπόν πως όταν το Admin account κάνει authentication, simple bind όπως λέγεται στο ldap protocol, τα username/password θα ταξιδέψουν από την μία μεριά στην άλλη σε μορφή clear text.

Για να φτάσω στο προκείμενο, βρίσκομαι μια μέρα σε πελάτη όπου υπάρχει εγκατεστημένο web service (όχι Microsoft) το οποίο χρησιμοποιεί secure ldap για να πιστοποιήσει τους χρήστες που κάνουν login. Για την υλοποίηση του secure ldap χρησιμοποιείται certificate όπως και στην περίπτωση του https. Τα πιστοποιητικά όμως ξέρετε έχουν την κακή συνήθεια να λήγουν και να μας κάνουν τη ζωή δύσκολη. Εμείς βέβαια ως ανώτερα όντα δεν ασχολούμαστε με αυτά παρά μόνο αφού λήξουν! Έτσι λοιπόν στο συγκεκριμένο πελάτη έληξε το πιστοποιητικό και παύει να λειτουργεί ο μηχανισμός authentication με αποτέλεσμα το portal για τους εξωτερικούς συνεργάτες να μην λειτουργεί πλέον.

Χαμός! Επιπλέον οι διαχειριστές, έχοντας “πλήρη” γνώση της υποδομής αποφασίζουν μέσα σε όλα να αλλάξουν και τον κωδικό του χρήστη που χρησιμοποιείται για τα ldap queries. O κωδικός άλλαξε για το χρήστη στο AD και ενημερώθηκε αντίστοιχα στο web service του portal μέσω κάποιας web φόρμας.

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

How to enable LDAP over SSL with a third-party certification authority

Εγκαθίσταται λοιπόν στον DC και οι διαχειριστές περιμένουν να επιστρέψουν στις δουλειές τους για ακόμα 1 χρόνο μέχρι να λήξει κι αυτό, όμως αναπάντεχα κάτι συνεχίζει να μην πηγαίνει καλά και το authentication των χρηστών συνεχίζει να αποτυγχάνει!

Μιλώντας με ανθρώπους που γνωρίζουν το web service το πρόβλημα δείχνει να προέρχεται από την εφαρμογή που περιέργως έχει κρατήσει τον παλιό κωδικό παρόλο που έχουν ενημερωθεί όλα τα απαραίτητα config files με τον νέο κωδικό.  Δυστυχώς τον παλιό κωδικό δεν τον θυμάται κανείς οπότε κι εδώ φτάνουμε σε αδιέξοδο!

Εδώ λοιπόν αναλαμβάνω δράση και γνωρίζοντας πως το πιστοποιητικό είναι exportable το εξάγω μαζί με το Private Key και κάνω decrypt όπως φαίνεται παρακάτω.

Εδώ φαίνονται τα SSL commands που χρησιμοποιούνται για την επίτευξη της κρυπτογράφησης Client Hello, Server Hello, Certificate κ.ο.κ. Επίσης έπειτα βλέπουμε το κομμάτι Application Data όπου εκεί στην ουσία είναι τα κρυπτογραφημένα δεδομένα.

Ο Server αποστέλλει το certificate

Ενώ εδώ φαίνεται το “follow tcp stream” της επικοινωνίας όπου στην ουσία όλα είναι encrypted, εκτός των SSL commands που φαίνονται στην κορυφή.

Για να λύσω το πρόβλημα κάνω τα εξής, μετατρέπω το certificate από μορφή .pfx σε αρχείο τύπου .pem. Αυτό επιτυγχάνεται με το Openssl for Windows όπου εκτελούμε την εντολή

openssl pkcs12 -in c:\temp\ldaps.pfx -out c:\temp\ldaps.pem -nodes –nocerts όπου in είναι το πιστοποιητικό που έχουμε και αντίστοιχα out είναι αυτό που θα παραχθεί.

Η όλη διαδικασία γίνεται επειδή στο pfx υπάρχει το Private Key αλλά είναι κλειδωμένο το αρχείο με κωδικό ενώ το pem έχει το Private Key χωρίς να έχει κάποιο κωδικό το αρχείο. To Wireshark δεν μπορεί να διαβάσει pfx αλλά pem αρχεία. Οπότε λοιπόν αφού πάρουμε το pem file πάμε στο Wireshark –> Edit –> Preferences –> Protocols –> SSL και προσθέτουμε τα παρακάτω

Εδώ λέμε πως θα προσπαθήσει να κάνει decrypt για όλες τις IPs (είναι το πιο ασφαλές), στην tcp port 636, αυτό που θα κάνει decrypt είναι ldap και τέλος που βρίσκεται το certificate. * Προσοχή στο τα διαχωριστικά είναι κόμματα (,)

Εκεί λοιπόν που πριν δεν μπορούσαμε να διαβάσουμε τίποτα τώρα είναι

Προσέξτε ότι εκτός από το SSL Handshake έχουμε το ldap command bind (ldap authentication), οπότε αν πάμε στα περιεχόμενα του bindrequest

Όπου το password φαίνεται πως είναι το “P@ssw0rd”.

Για να επιστρέψω πίσω στο αρχικό πρόβλημα όντως η εφαρμογή είχε “κολλήσει” με τον παλιό κωδικό που τον βρήκαμε έτσι και κάναμε εκ νέου password reset στο χρήστη στο AD και έτσι λύθηκε το πρόβλημα. Δεν απαντήθηκε βέβαια για ποιο λόγο είχε κολλήσει η εφαρμογή αλλά τουλάχιστον το σύστημα ήταν πάλι παραγωγικό και υπήρχε άνετος χρόνος για διερεύνηση. Βέβαια ο ενθουσιασμός των διαχειριστών ήταν τεράστιος και σε αυτό συνέβαλλε η εύρεση του κρυπτογραφημένου κωδικού, κάτι που γενικά συναρπάζει τον κόσμο.

Κλείνοντας να αναφέρω πως και τον Netmon μπορεί να κάνει SSL Decrypt με τη χρήση του NMDecrypt (http://nmdecrypt.codeplex.com/releases/view/61943) και μάλιστα κάνοντας απ’ ευθείας χρήση του pfx file γνωρίζοντας βέβαια τον κωδικό. Το αρνητικό είναι πως δεν είναι real-time αλλά χρειάζεται η κίνηση να είναι αποθηκευμένη σε .cap εκ των προτέρων.