I.T. ΑΝΗΣΥΧΙΕΣ

Τι συμβαίνει στην περίπτωση που οι υπολογιστές μας θα πέσουν θύματα κάποιοι οργανωμένου δικτύου botnet?

Στην ουσία εξαρτόμαστε από τα όρια της φαντασίας του εκάστοτε διαχειριστή-εγκληματία του Command & Control Server. Οι συνήθεις δραστηριότητες τους περιλαμβάνουν κλοπή τραπεζικών λογαριασμών, cookies, κωδικών mail, ftp, social networks etc. Στις τελευταίες εκδόσεις έχουμε δει επίσης την προσθήκη του πολύ γνωστού VNC για “ζωντανή” σύνδεση με το θύμα!

Ας πάρουμε το ενδεχόμενο όμως πως θέλουμε να πάψουμε την εγκληματική λειτουργία του δικτύου που περιγράφεται στην παραπάνω εικόνα. Τα πράγματα είναι απλά, ξεκινάμε πιάνοντας τους “κακούς” στην αριστερή μεριά και συνεχίζουμε τερματίζοντας τη λειτουργία του Control Server που βρίσκεται στην κορυφή. Αυτό μπορεί να συμβεί είτε τερματίζοντας το C&C είτε, όπως γίνεται πολλές φορές καταργώντας τα DNS Records που οδηγούν σε αυτόν. Έτσι αφήνουμε όλο το δίκτυο ακέφαλο, θα μου πείτε δε γιατρεύουμε τους ασθενείς δηλαδή τα θύματα αλλά ο κόσμος είναι σκληρός και δεν μπορούμε να τους σώσουμε όλους, τουλάχιστον δεν κινδυνεύουν από επιπλέον ζημιά.

Καλά μέχρι εδώ αλλά τι σχέση έχουν όσα περιγράφονται με την 8η Μαρτίου; Συνδέονται γιατί στη 8/3/2012 θα κλείσει μια σειρά από servers που αποτελούν κομμάτι ενός νέου εναλλακτικού είδους Botnet.

Ας περάσουμε στο πρακτικό κομμάτι να δούμε τι ακριβώς κάνει ένα από τα malware variants μόλις εκτελεσθεί σε κάποιο υπολογιστή-θύμα.

Εκτελώντας λοιπόν το εν λόγω malware παρακολουθούμε με τον γνωστό “Process Monitor” και στο “Process Tree” βλέπουμε το process 04e53b… (md5 hash) το οποίο με τη σειρά του εκτελεί τα γνωστά iexplore.exe & ipconfig.exe.

Στη συνέχεια βλέπουμε το iexplore.exe να εκτελεί το Operation RegSetValue στο Registry key “HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{2563F443-38A2-4EDE-B59E-E9D925208AC9}\NameServer”

κι αν πάμε στα ενδότερα αυτής της διαδικασίας τότε θα δούμε πως γράφει στο registry τα παρακάτω.

Στην ουσία πρόκειται για λεπτή χειρουργική επέμβαση στο θύμα αλλάζοντας απλά τους DNS Servers που χρησιμοποιούνται από το σύστημα. Φανταστικό θα μπορούσε να πει κανείς! Όντως, πρόκειται για τρομερά ευρηματικό τρόπο παραπλάνησης των θυμάτων. Στην ουσία για όποιο dns query εκτελεστεί μετά την “μικρή” αυτή αλλαγή οι εγκληματίες έχουν τον πλήρη έλεγχο της απάντησης. Το θέμα είναι πως για τα περισσότερα sites θα μας δώσουν τις σωστές IPs εκτός από αυτά που τους ενδιαφέρουν οπότε εκεί μας κατευθύνουν σε δικούς τους servers σωστά διαμορφωμένους ώστε να μας αποσπάσουν όποια πληροφορία έχουν ως απώτερο σκοπό. Αντιλαμβάνεστε λοιπόν τη δύναμη που αποκτούν μόνο και μόνο με τον έλεγχο των DNS ερωτημάτων του θύματος. Με βάση τα παραπάνω γίνεται κατανοητό πως επιλέχτηκε ως όνομα του malware το DnsChanger!

Για να επανέλθουμε στον αρχικό τίτλο, πως συνδέονται τα παραπάνω με την 8η Μαρτίου; Το FBI που έχει εμπλακεί στην υπόθεση μετά τις συλλήψεις των υπευθύνων το Νοέμβριο του 2011 (6 άτομα στην Εσθονία) θα πάψει τους παράνομους DNS Servers στην παραπάνω ημερομηνία οπότε όσα θύματα είναι ακόμα ρυθμισμένα με αυτούς πιθανότατα θα βρεθούν εκτός internet.

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

Τέλος το DnsChanger έχει λειτουργίες για static & dynamic IPs και το επίσης κορυφαίο είναι πως είχαν κυκλοφορήσει εκδόσεις όπου είχαν τη δυνατότητα να αλλάζουν το network configuration σε πολλούς ADSL Routers! Πως γινόταν αυτό; με μια λίστα από τα default username/passwords για αρκετούς routers της αγοράς οπότε έκανε τις απαραίτητες αλλαγές στο παρασκήνιο στη ρυθμισμένη ως default gateway IP.

http://www.fbi.gov/newyork/press-releases/2011/manhattan-u.s.-attorney-charges-seven-individuals-for-engineering-sophisticated-internet-fraud-scheme-that-infected-millions-of-computers-worldwide-and-manipulated-internet-advertising-business  (Προσέξτε τα στατιστικά στοιχεία)

http://www.fbi.gov/news/stories/2011/november/malware_110911/DNS-changer-malware.pdf

http://www.dcwg.org/index.html

Το τελευταίο διάστημα βλέπω έντονη κίνηση από irc bots τα οποία καταλήγουν να γίνονται αυτοματοποιημένα spam bots. Δεν γνωρίζω αν βλέπουμε πάλι κάποιο μεγάλο δίκτυο τύπου Rustock (http://www.microsoft.com/security/sir/story/default.aspx#!rustock) αλλά σίγουρα έχει κάνει αισθητή την παρουσία του.

Έχουμε και λέμε λοιπόν, το δείγμα μας όπως θα δείτε έχει χαμηλό δείκτη “προστασίας” . Βέβαια αυτό συμβαίνει γιατί συνεχώς τις τελευταίες ημέρες αλλάζουν τον κώδικα ώστε να προσπερνούν ανενόχλητα από τα AVs έστω και προσωρινά.

Ας περάσουμε στην εκτέλεση του να δούμε πως συμπεριφέρεται το διαβολάκι μας!

1. Dns query για το xxxxx.ka3k.com όπου βρίσκεται ο IRC Server μας

2. Σύνδεση με user/pass και κατευθείαν εντολές

Όπως βλέπετε μας κατευθύνει να κατεβάσουμε το “ngui.exe” και να το αποθηκεύσουμε ως “ngdhd.exe” Η όλη διαδικασία γίνεται αυτοματοποιημένα και χωρίς την όποια διένεξη μας βέβαια.

Μόλις κατέβει το αρχείο μας εκτελείται άμεσα και βέβαια όπως κάθε malware που σέβεται τον εαυτό του φροντίζει την εκτέλεσή του σε κάθε system startup. Αυτό επιτυγχάνεται με τον παρακάτω τρόπο

Δημιουργεί κάτω από το C:\Recycler (Recycle Bin Windows XP), ένα subfolder με κάτι που μοιάζει με SID αλλά δεν είναι, προσέξτε το R-1-5-21! λάθος γιατί τα Security Identifiers (http://support.microsoft.com/kb/243330) ξεκινούν με “S” κι όχι με “R”, παραπλανητική τεχνική. Επίσης τοποθετεί στον ίδιο φάκελο το ecleaner.exe και τέλος κάνει την απαραίτητη εγγραφή στο registry στο παρακάτω κλειδί (http://technet.microsoft.com/en-us/library/cc957402.aspx)

Στη συνέχεια λοιπόν το αρχείο που κατέβηκε το “ngdhd.exe” κάνει unpack τον κώδικα του στο Twswsp.exe

και βέβαια με τη σειρά του κάνει τις ανάλογες registry ρυθμίσεις για να εξασφαλίσει την αυτόματη εκτέλεση σε κάθε επανεκκίνηση.

Όσον αφορά το αρχείο ngui.exe στο virustotal.com έχουμε τα παρακάτω αποτελέσματα

Μέχρι εδώ λοιπόν έχουμε 2 νέα αρχεία το ecleaner.exe (μόνο clean δεν κάνει!) & το twswsp.exe τα οποία εκτελούνται σε κάθε εκκίνηση. Το 2ο αρχείο φαίνεται πως είναι το πρόγραμμα επικοινωνίας με το C&C Server για περαιτέρω εντολές.

Στη συνέχεια αρχίζει το κέφι αφού κατεβαίνουν ακόμα μερικά εκτελέσιμα τα οποία τελικά πιάνουν αμέσως δουλειά και επικοινωνούν με άλλο web server όπου κατεβάζουν τα παρακάτω:

Το όνομα του Web Directory /spm/ μάλλον προδίδει το σκοπό ύπαρξης του (spam). Εδώ στην ουσία αντλεί σε κρυπτογραφημένη μορφή email accounts για την αποστολή των mails.

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

Να συμπληρώσω πως ένα από τα executables που κατεβαίνει έχει anti-debugging μηχανισμό, δηλαδή μόλις βρει ανοιχτά processes από γνωστά tools όπως procmon, ollydbg, wireshartk etc τα κλείνει αμέσως.

Τέλος για να πάρουμε μια καλή ιδέα για την διάσταση και τη διασπορά αυτών των ενεργειών παραθέτω την παρακάτω εικόνα:

Εδώ απεικονίζονται οι 4 βασικοί servers και ο ρόλος τους. 2 Web Servers από τους οποίους κατεβαίνουν τα malware και 2 IRC C&C Servers.

Καλή συνέχεια σε όλους, πάω να διαγράψω ακόμα μερικά mails από το Junk Folder μου!

Πελάτης χρησιμοποιεί για anti-spam λύση τις λίστες που διαθέτει δωρεάν η www.spamhaus.org, η συγκεκριμένη υπηρεσία προσφέρεται δωρεάν και λειτουργεί με τη χρήση dns queries. Έχει ρυθμιστεί λοιπόν ο Exchange σύμφωνα με τις οδηγίες που δίνονται στο προηγούμενο site αλλά τον τελευταίο καιρό χωρίς να αλλάξει κάτι (όπως πάντα) οι χρήστες έχουν αρχίσει να λαμβάνουν μεγάλο αριθμό από spam mails, οπότε αφού βλέπουμε πως ο Exchange δείχνει σωστά ρυθμισμένος ρίχνουμε μια επί πλέον ματιά.

Η υπηρεσία λοιπόν λειτουργεί ως εξής, ο mail server όταν δέχεται εισερχόμενη αλληλογραφία ελέγχει την IP (π.χ. 192.168.0.1) του αποστολέα κάνοντας το query 1.0.168.192.zen.spamhous.org. Έτσι σε όποιον dns και να γίνει το ερώτημα τελικά θα πρέπει να πάρει τη σωστή απάντηση μιας και το domain είναι το zen.spamhous.org. Τώρα αναλόγως την απάντηση ο mail server καταλαβαίνει αν πρόκειται για spam sender ή όχι.

Οπότε 1ο βήμα ήταν να δούμε αν ο Exchange όντως κάνει αυτό που πρέπει δηλαδή να στέλνει τα ερωτήματα, ένα network trace μας δίνει την απάντηση

Παραπάνω φαίνεται η ερώτηση για την IP 116.71.33.70 (θυμίζει ptr record αλλά δεν είναι)

Κι εδώ φαίνεται η απάντηση για την ερώτηση, “No such name” με βάση τις οδηγίες από το spamhaus η IP είναι εντάξει και μπορεί να προχωρήσει η smtp επικοινωνία.

Προσέξτε στο σετ ερώτησης-απάντησης πως υπάρχει το Transaction ID, κάτι πολύ χρήσιμο γιατί δε σημαίνει πάντα πως η απάντηση για το dns query είναι πάντα το αμέσως επόμενο πακέτο, οπότε μπορούμε να ψάξουμε με το Transaction ID που είναι κοινό.

Κλείνοντας την παραπάνω παρένθεση φαίνεται λοιπόν πως ο Exchange όντως κάνει τις ερωτήσεις που πρέπει και παίρνει απαντήσεις χωρίς πρόβλημα από κάποια ενδιάμεση συσκευή ή κάτι άλλο περίεργο. Το επόμενο βήμα ήταν να βρω κάποια spammer IP και να δοκιμάσουμε κατευθείαν, χρησιμοποιώντας λοιπόν το http://spam-ip.com/list-1.html διαλέγω την “hausernamef6 70.77.56.209 toddbutler1128@aol.com.

Οπότε κάνω το dns query στον DNS που χρησιμοποιεί ο πελάτης (8.8.8.8)

C:\>nslookup 209.56.77.70.zen.spamhaus.org 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

*** google-public-dns-a.google.com can't find 209.56.77.70.zen.spamhaus.org: Non-existent domain

Όντως ο συγκεκριμένος DNS επιστρέφει τη γνωστή απάντηση που δηλώνει πως η εγγραφή είναι καθαρή.

Υποψιασμένος κάνω το ίδιο ερώτημα σε κάποιον άλλον DNS

C:\>nslookup 209.56.77.70.zen.spamhaus.org 194.30.220.110
Server:  ns0.hol.gr
Address:  194.30.220.110

Non-authoritative answer:
Name:    209.56.77.70.zen.spamhaus.org
Address:  127.0.0.11

Όπως βλέπετε λοιπόν η απάντηση που επιστρέφει δηλώνει πως η IP ανήκει σε κάποιον spammer (περισσότερα εδώ http://www.spamhaus.org/faq/answers.lasso?section=DNSBL Usage#252)

Τι συνέβη λοιπόν; Η Google άλλαξε το configuration στους Public DNS και προφανώς δε δίνει απαντήσεις για τα συγκεκριμένα domain. Υποψιάζομαι πως έγινε γιατί οι public DNS προορίζονται για απλό web browsing και όχι χρήση τέτοιων υπηρεσιών που βομβαρδίζουν κυριολεκτικά τους DNS συνεχώς με dns queries.

Τις περισσότερες φορές που συναντάμε εφαρμογή η οποία χρειάζεται να επικοινωνήσει με 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 εκ των προτέρων.

Βρέθηκα πρόσφατα σε μια εγκατάσταση στην οποία η παλιά υποδομή Standard ISA 2006 αντικαταστάθηκε από Forefront TMG Enterprise Array. Κατά τη διάρκεια των δοκιμών παρουσιάστηκαν προβλήματα στην επικοινωνία του smtp server στη DMZ (exchange) και του εσωτερικού mail server οπότε μου ζητήθηκε να ρίξω μια ματιά.

Η εγκατάσταση είχε ως εξής:

Η εξωτερική αλληλογραφία κατέληγε στον Edge και αυτός έπειτα έκανε relay στον Hub-Transport. Από την μεριά του TMG κάναμε publishing την smtp υπηρεσία (tcp port 25) του hub προς τον edge. Στην ουσία αυτό που γίνεται είναι πως στην εξωτερική κάρτα του TMG ενεργοποιείται listener στην 25 tcp port που δρομολογεί ότι κίνηση εμφανιστεί στον εσωτερικό αφού βέβαια την ελέγξει.

Πίσω στο πρόβλημα, μόλις τοποθετήθηκε ο TMG τότε στον Edge εμφανιζόταν μήνυμα λάθους πως δεν μπορούσε να δρομολογήσει τα μηνύματα και αυτά παρέμεναν στη λεγόμενη “ουρά”. Σαν πρώτο βήμα πήραμε network trace από τον Hub.

H επικοινωνία φιλτραρισμένη με την εντολή smtp, όπως βλέπετε είναι πολύ σύντομη! Οι 2 servers 10.101.0.26 (hub-transport) & 192.168.167.5 (edge) συνδέονται και σχεδόν αμέσως ο edge κλείνει το κανάλι.

Δεν πρέπει βέβαια να ξεχνάμε πως αυτό που βλέπουμε είναι η επικοινωνία μεταξύ εσωτερικού interface TMG & Hub. Αυτό γιατί το firewall engine δεν μεταβιβάζει τις εντολές που δέχεται στο εξωτερικό interface αλλά τις ελέγχει-φιλτράρει και έπειτα ανοίγει 2ο κανάλι επικοινωνίας στο εσωτερικό interface και περνάει όποιες θεωρεί ασφαλείς.

Τo tcp stream της προηγούμενης επικοινωνίας έχει ως εξής:

Μπλε: Hub-transport

Κόκκινο: Edge, TMG

Μέχρι εδώ είναι προφανές πως για κάποιο λόγο (ακόμα δεν ξέρουμε) ο TMG αποφάσισε να διακόψει την επικοινωνία στέλνοντας την εντολή QUIT.

Επόμενο βήμα, ανάλογο trace στον Edge.

Εδώ τα πράγματα αρχίζουν να ξεκαθαρίζουν, παρατηρήστε τα frames 127-128 όπου πλέον ο Edge στέλνει κάποια εντολή (X-AnonymousTLS) και ο TMG απαντά Invalid command. Αναλυτικότερα:

Μπλε: Hub-transport, TMG

Κόκκινο: Edge

Φαίνεται λοιπόν πως ο Edge κάνει χρήση της εντολής “X-AnonymousTLS” και ο TMG απαντάει “421 5.5.1 Invalid command”. Βλέπετε λοιπόν πως ο TMG όντως ελέγχει τις εντολές που περνάνε στο application layer και επεμβαίνει όπου χρειαστεί.

Τώρα για την επίλυση του συγκεκριμένου προβλήματος χρειάστηκε να επέμβουμε στο SMTP Filter που βρίσκεται με τα υπόλοιπα application filters

Οπότε οι ιδιότητες του φίλτρου είναι όπως αναμένεται

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

Μπορεί να φαίνεται δύσκολο σε κάποια σημεία το troubleshooting αλλά για να επιτευχθεί πρέπει να έχουμε κατανοήσει πως ακριβώς λειτουργούν τα application layer firewalls (το λέει και ο τίτλος τους αλήθεια) σε αντίθεση με τα Stateful Firewalls που στην ουσία επιτρέπουν ή όχι συγκεκριμένες πόρτες αγνοώντας και χωρίς να επεμβαίνουν στα δεδομένα της επικοινωνίας. Τα statefull firewalls δεν ελέγχουν καν αν τα δεδομένα που διακινούνται έχουν σχέση με το πρωτόκολλο π.χ. tcp port 80 –> http.

Το rimecud είναι ένα αρκετά γνωστό malware-bot το οποίο διεκδικεί και την πρωτιά για το 2010!  http://www.microsoft.com/security/sir/story/default.aspx#section_3_1

Πριν ξεκινήσω ας δούμε τι λέει το www.virustotal.com σχετικά με τα executables που κατέβηκαν.

Τι να πω; τα νούμερα μιλάνε από μόνα τους! Βλέπετε πόσο χαμηλά είναι το ποσοστά εντοπισμού από τα Antivirus ~15%

Οπότε ας πάρουμε μια καλή ιδέα από τα πλούσια ταλέντα του συγκεκριμένου malware. Καταρχάς περιέχει ρουτίνα ώστε όταν εκτελείται να τερματίζει οποιοδήποτε monitor tool τύπου process monitor, wireshark, process explorer etc. Πρόκειται για πολύ δημοφιλή τεχνική που χρησιμοποιείται αρκετά ώστε να δυσκολέψει την ανάλυση.

Εκτελώντας λοιπόν το malware συμβαίνουν τα εξής:

1. DNS query για το όνομα ms.mobilerequests.com, ακούγεται πραγματικό/νόμιμο αλλά δεν είναι!
2. To συγκεκριμένο bot ανήκει στην κατηγορία mariposa ή butterfly ή rimecud και χρησιμοποιεί σε αντίθεση με άλλα udp πρωτόκολλο για την επικοινωνία με τον C&C Server
3. Εδώ βλέπουμε πως γίνεται reverse lookup για την IP του bot ώστε να μάθει το fully qualified domain name και κατ’ επέκταση τον ISP. Θα καταλάβετε παρακάτω το λόγο.
4. Ακολουθεί πάλι επικοινωνία με τα “κεντρικά” για επιπλέον εντολές!
5. Στα επόμενα βήματα πραγματοποιείται download διαφόρων αρχείων τα οποία μην σας ξεγελάει η κατάληξη πρόκειται για executables.
6. Ενδεικτικά δείτε το 2ο file dateonewo.ol μέσα από hex editor όπου προδίδεται και η ταυτότητά του
7. Εδώ πλέον κατεβαίνει το serv.exe όπου είναι και η κύρια εφαρμογή που εκτελείται στο εξής και γι’ αυτό μάλλον έχει και το ευφάνταστο όνομα serv –> server.

Συνεχίζοντας …

1. Συνδέεται στους smtp του hotmail  και για κάποιο λόγο δεν προσπαθεί να στείλει κάποιο “ωφέλιμο” mail.
2. Σε αυτό το σημείο συνδέεται σε web service και ζητάει το /spm/s_get_host.php?ver=522 και η επικοινωνία είναι

GET /spm/s_get_host.php?ver=522 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; VS2)
Host: 91.200.242.230
Accept: */*
Connection: Close

HTTP/1.0 200 OK
Content-Type: text/html; charset=ISO-8859-1
Connection: close

athedsl-132631.home.otenet.gr

Αυτό στην ουσία που ζητήσαμε είναι να μάθουμε το hostname μας όπως έχει καταγραφεί στους C&C.

Στο 3ο βήμα βλέπουμε πως εκτελεί dns query αλλά για mx record, δηλαδή προσπαθεί να βρει τον mail exchanger του ISP μου. Αυτό συνδέεται με το βήμα 3 στην προηγούμενη παράγραφο όπου εκτέλεσε reverse lookup για να μάθει τον fqdn μου άρα και τον πάροχο που ανήκω. Οπότε βλέπουμε να προσπαθεί απεγνωσμένα να εντοπίσει τον smtp server του ISP ρωτώντας διάφορους DNS serves.

Γιατί θέλει τον mx server? Η απάντηση προφανής, spam και ακολουθεί:

Η smtp επικοινωνία (μπλε smtp server, κόκκινο bot)

SMTP spam

220 speedy.otenet.gr ESMTP Sun, 5 Dec 2010 12:20:26 +0200

HELO athedsl-132631.home.otenet.gr

250 speedy.otenet.gr Hello athedsl-132631.home.otenet.gr [85.75.93.182], pleased to meet you

MAIL FROM:<ann_hvoz@msn.com>

550 5.7.1 Rejected: 85.75.93.182 listed as spam source at http://www.spamhaus.org/

Βέβαια τα πολυτάλαντο bot δεν σταματά εδώ κι έτσι ταυτόχρονα προσπαθεί να στρατολογήσει και άλλα bots

Αυτό που φαίνεται παραπάνω είναι προσπάθειες σύνδεσης στην 445/tcp (smb) διαφόρων IPs οπότε όποια βρεθεί και δεν έχει τα απαραίτητα updates να έλθει αμέσως στις υπηρεσίες μας!

Συνοψίζοντας

Πρόκειται για botnet με ποικίλα χαρακτηριστικά, να σημειώσω εδώ πως τα περισσότερα από τα εκτελέσιμα που κατέβηκαν είναι επιπλέον trojan ή εφαρμογές τύπου fake AV, fake antispam etc.

Επίσης για να μη νομίζετε πως οι web servers που κρατούν τα συγκεκριμένα αρχεία είναι μέρος του κυκλώματος δείτε το παρακάτω:

Άλλος ένας από τους πολλούς web servers όπου εν αγνοία των υπευθύνων μοιράζει malware.

Τέλος σε όλη την επικοινωνία εμφανιζόταν παντού η πληροφορία PASS laorosr όπως φαίνεται και παρακάτω.

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

Έχουμε το παρακάτω σενάριο:
Χρήστης με Office 2007 προσπαθεί να ανοίξει excel files από κάποιο unc path (smb network share, \\server1). Τα .xlsx ανοίγουν χωρίς πρόβλημα ενώ τα .xls χρειάζονται περίπου 1 λεπτό από ίδιο πάντα share.

Eύλογο το συμπέρασμα πως πάλι εμείς στην Microsoft κάτι έχουμε αλλάξει στο Office 2007 και δημιουργεί αυτά τα προβλήματα. Στην προηγούμενη πρόταση δεν είμαι αρνητικός, συμβαίνουν κι αυτά απλά μένει να αποδειχθεί κιόλας.

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

Δυσκολάκι

Ο τίτλος έχει να κάνει καθαρά με τη λειτουργία του πρωτοκόλλου SMB το οποίο είναι σχετικά περίπλοκο ώστε να καταφέρει να κάνει ότι κάνει για εμάς. Μου στέλνουν λοιπόν τα 2 network traces, ένα για κάθε περίπτωση (προβληματική & ΟΚ) οπότε για να διερευνήσω το πρόβλημα έκανα τα εξής βήματα:

1. Απομονώνω το tcp connection που χρησιμοποιήθηκε για την μεταφορά του .xls & .xlsx αρχείου σε κάθε ένα από τα traces και αποθηκεύω σε νέο αρχείο. Αυτό γίνεται αναζητώντας στη στήλη Info το αρχείο που μεταφέρθηκε (test_MS.xls & test_MS.xlsx) και επιλέγοντας right click –> follow tcp stream. Μετά αποθηκεύω μόνο τα displayed packets.

2. Ανοίγουμε τα 2 νέα πλέον traces με το wireshark και χρησιμοποιούμε display filter “smb2” . Αυτό το κάνουμε γιατί θέλουμε να επικεντρωθούμε στα smb commands που χρησιμοποιηθήκαν. SMB2 είναι η νέα έκδοση του smb και χρησιμοποιείται μεταξύ νεοτέρων λειτουργικών.

3. Έπειτα επιλέγουμε

File –> Print (ναι print!) και επιλέγουμε όπως φαίνεται στην εικόνα, output to txt file και μόνο “Packet Summary Line”

Έτσι καταλήγουμε σε txt file όπου εκεί κράτησα τις στήλες Source, Destination & Info. Οπότε πλέον ανοίγουμε τα 2 txt files και συγκρίνουμε με κάποιο notepad compare tool.

Αυτό που φαίνεται στην παρακάτω εικόνα είναι η σύγκριση μεταξύ των 2 trace files. Είναι δύσκολο να μην προσέξουμε ότι κάτι συμβαίνει στη δεξιά μεριά όπου προβάλλεται η προβληματική λειτουργία.

Υπάρχει μεγάλος αριθμός από Lock Request File: & Lock Response. Ανατρέχοντας στο documentation βρίσκω πως αυτό που βλέπω είναι OPLOCK_Break Notification όπου έτσι ο server ενημερώνει τον client ότι δεν μπορεί να “κλειδώσει” το αρχείο.

Έχουμε να κάνουμε με κάτι που συμβαίνει στο server και δημιουργεί προβλήματα στην πρόσβαση των .xls αρχείων. Το πρώτο πράγμα που πήγε το μυαλό μου, τυχαίο; ήταν το Antivirus και βέβαια όταν ο πελάτης έκανε exclude τα *.xls από το AV η καθυστέρηση εξαφανίστηκε.

Βέβαια αυτό δεν είναι λύση αλλά workaround γιατί έτσι δημιουργούμε άλλα κενά ασφαλείας, όπως καταλαβαίνετε.

Όπως είπα και παραπάνω το SMB είναι πολύπλοκο πρωτόκολλο με την έννοια ότι περιέχει μεγάλο πλήθος από εντολές και λειτουργίες. Σε όσες περιπτώσεις έχει χρειαστεί να γίνει troubleshoot το smb τότε ανατρέχω στο επίσημο documentation http://msdn.microsoft.com/en-us/library/cc216517(PROT.10).aspx. Μπορείτε να κάνετε download τα 2 files από τις παρκάτω διευθύνσεις:

• Windows Communication Protocols (MCPP) download package

• Windows Server Protocols (WSPP) download package

Στα pdf που θα βρείτε υπάρχει περιγραφή για κάθε λειτουργία των windows protocols. Είναι κάτι σαν Windows RFCs!

Με την παραπάνω περιγραφή ήθελα να παρουσιάσω εναλλακτικό τρόπο σύγκρισης 2 network traces.

Έτσι θα ονομάζεται πλέον ο νέος PDF viewer/reader της Adobe . (http://www.adobe.com/products/reader.html).

Τι νέο έρχεται να προσθέσει, μα βεβαίως ασφάλεια!

Το portable document format χρησιμοποιείται ευρέως για την ανταλλαγή κειμένων μέσω internet οπότε η μεγάλη του δημοτικότητα δεν πέρασε απαρατήρητη από τους κυβερνό-εγκληματίες. H Adobe με την τελευταία έκδοση προσπαθεί να βάλει τέλος σε όλες τις αδυναμίες που έχουν εμφανιστεί τον τελευταίο καιρό όπου μέσω pdf files υπήρχαν οι προυποθέσεις για την εκτέλεση shellcodes.

Αυτό επιτυγχάνεται μέσω της ενσωματωμένης λειτουργίας protected mode ανάλογης με αυτήν που έχουμε ήδη στον Internet Explorer. Με τη χρήση του protected mode δεν επιτρέπεται καμία ενέργεια εκτός του reader. (εγγραφή στο file system, εκτέλεση κώδικα κλπ).

Για δεύτερη συνεχή χρονιά συμμετείχα στην καταπληκτική προσπάθεια που γίνεται από την ομάδα του autoexec.gr. Φέτος είχα την τιμή και τη χαρά να μιλήσω για 2 διαφορετικά θέματα που με απασχολούν ιδιαίτερα.

Προσωπικά θεωρώ πως το επίπεδο διοργάνωσης κινήθηκε σε πολύ υψηλά επίπεδα και αν αναλογιστεί κανείς το γεγονός πως η οργανωτική επιτροπή είναι άνθρωποι (κοινοί θνητοί ) που αφιερώνουν μεγάλο κομμάτι του προσωπικού τους χρόνου τότε νομίζω πως ένα event με ~350 συμμετάσχοντες αντικατοπτρίζει το πάθος και την αφοσίωση που έδειξαν! Έτσι καταλήξαμε να έχουμε πολλαπλά παράλληλα sessions με πολύ αξιόλογα θέματα και ομιλητές. Για τα ελληνικά δεδομένα αποτελεί ορόσημο το γεγονός ότι μαζευτήκαμε όλοι εκεί το Σαββατοκύριακο, αφήνοντας πίσω ελεύθερο χρόνο, οικογένειες, παιδιά κοκ, ώστε να μοιραστούμε εμπειρίες, γνώσεις αλλά και πολύ γέλιο!

Από την μεριά μου αισθάνομαι ιδιαίτερα χαρούμενος που μπόρεσα να μοιραστώ μαζί με την κοινότητα τις “I.T. Ανησυχίες” μου. Ήταν μοναδική εμπειρία να μοιραστώ τις αναζητήσεις μου με σκοπό να αποκτήσουμε όλοι καλύτερη άποψη για το πως εκτυλίσσεται το έγκλημα στο διαδίκτυο.

Τέλος όσον αφορά την παρουσίαση για το Active Directory ελπίζω όσους διέκοψα απότομα να κατάλαβαν πως αυτό έγινε στα πλαίσια του να κερδίσουμε όσο το δυνατόν περισσότερο χρόνο για γνώση.

Υ.Σ. Μην ξεχάσω όπως υποσχέθηκα εδώ θα βρείτε και τις παρουσιάσεις μου σε μορφή pdf!

Καλό διάβασμα   IT_PRO

Μόλις έχω ελέγξει το replication σε περιβάλλον AD με 450+ Domain Controllers όπου υπάρχουν μικροπροβλήματα λόγω γραμμών σε κάποια υποκαταστήματα. Εμφανίζεται λοιπόν κάποιος developer ο οποίος παραπονιέται ότι κάνοντας το ίδιο ldap query σε 2 διαφορετικούς DCs παίρνει διαφορετική απάντηση! Δε λέω ακούγεται ενδιαφέρον αλλά σιγά μην ισχύει κάτι τέτοιο.

Ευθύς αμέσως ελέγχω το replication στους 2 ύποπτους DCs με την εντολή

repadmin /replsum <server name>

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

Για να βγάλουμε μια άκρη ρωτάω να μάθω τι είναι αυτό που ζητάει μέσω του ldap query και παίρνει διαφορετικές απαντήσεις. Η απάντηση πως ψάχνει για το group membership ενός χρήστη και από τον dcA βλέπει 6 groups ενώ από τον dcB μόνο 1.

Προσπαθώντας να διαπιστώσω τα παραπάνω δίνω την εντολή

dsquery * –s dcA “cn=user,ou=somewhere,dc=root,dc=gr” –attr memberOf

dsquery * –s dcB “cn=user,ou=somewhere,dc=root,dc=gr” –attr memberOf

Στην ουσία με τις παραπάνω εντολές εκτελώ ldap query όπου ζητάω από τους DC/ldap servers να μου επιστρέψουν την τιμή του attribute memberOf όπου κρατείται το group membership για το χρήστη. Προσέξτε τη χρήση των Distinguished Names όπου είναι ο default τρόπος στις εντολές dsquery, dsget dsmod etc. Παρόμοια εντολή είναι η

dsget user –s dcA “cn=user,ou=somewhere,dc=root,dc=gr” –memberOf

Σε όλες τις περιπτώσεις η απάντηση είναι ίδια (6 groups) για τους DCs που το custom utility αποτυγχάνει να πάρει κοινά αποτελέσματα. Οπότε στην επιμονή του τελευταίου δε βλέπω άλλη λύση από το να ζητήσω το tool που χρησιμοποιεί ώστε να το διερευνήσω από πρώτο χέρι.

Εκτελώ λοιπόν το utility και παράλληλα κάνω network trace ώστε να δω τα ldap queries που πραγματοποιούνται. Το πρωτόκολλο ldap αν δεν χρησιμοποιεί ssl (ldaps –> port 636) είναι clear text και μπορούμε να δούμε τα περιεχόμενα χωρίς δυσκολία κάνοντας χρήση του display fitler tcp.port==389.

Μέσω του custom ldap tool ζητάω το group membership του εν λόγω χρήστη από τους 2 DCs και όντως παίρνω διαφορετικά αποτελέσματα!

Μη έχοντας πειστεί θεωρώ πως η απάντηση έρχεται σωστή από τους DCs αλλά για κάποιο λόγο το ldap tool δεν το εμφανίζει. Οπότε γρήγορα ελέγχω το μέγεθος της τελικής απάντησης στις 2 ερωτήσεις.

Εδώ με περιμένει η πρώτη έκπληξη όπως φαίνεται και παρακάτω:

Από τον 1ο DC η απάντηση έχει μέγεθος 1004bytes, ενώ από τον 2ο

η απάντηση έχει μέγεθος 446bytes!!

Πολύ περίεργα πράγματα οπότε πηγαίνω να ελέγξω τα περιεχόμενα των 2 συγκεκριμένων πακέτων (packet details). Εδώ με περιμένει η δεύτερη έκπληξη:

Ο 1ος DC επιστρέφει 6 groups (memberOf) ενώ αντίθετα ο 2ος

μόνο 1!!
Τελικά υπάρχουν φαντάσματα δεν μπορεί να εξηγηθεί αλλιώς! Ο developer του ldap tool έχει δίκιο.

Υπάρχει BUG στο Active Directory!!!

Αποκαλυπτήρια

Όντας δύσπιστος συνεχίζω τη διερεύνηση του όλου ldap query που έγινε από το tool, το οποίο εκτελεί τα βήματα ως εξής:

Βλέπω λοιπόν μέσω του network trace πως εκτελεί μια σειρά από βήματα – ldap queries.

Αρχικά δέχεται το username (samAccountName) ως input και αναζητά με αυτό το cn (canonicalName) του χρήστη. Δηλαδή δίνουμε user01 και ψάχνει για το cn π.χ. Γεώργιου Δ. Κωσταντίνα.

Περίεργο που ο προγραμματιστής αποφάσισε να το χειριστεί έτσι αλλά ας πάμε παρακάτω να δούμε τι συμβαίνει.

Ως απάντηση λοιπόν, λαμβάνει το ονοματεπώνυμο του χρήστη (xxxxxx Δ. Κωνσταντίνα) οπότε το ldap tool συνεχίζει αναζητώντας το group membership του χρήστη με αυτό το ονοματεπώνυμο (CN).

Το cn αποστέλλεται στους 2 διαφορετικούς DCs και περιμένει να δει το attribute memberOf (group membership).

Aυτό που συμβαίνει είναι πως υπάρχει συνωνυμία, υπάρχουν δηλαδή 2 “xxxxxx Δ. Κωνσταντίνα” και οι 2 αυτοί χρήστες δεν ανήκουν στα ίδια groups

Αυτό φαίνεται ξεκάθαρα από το Distinguished Name των 2 users που ναι μεν έχουν το ίδιο όνομα CN αλλά πρόκειται για διαφορετικούς οπότε και ανήκουν σε άλλα OUs.

CN=user01,OU=Users,OU=GrandsUsers,OU=InteractiveUsers,OU=AllUsers,DC=axyz,DC=root,DC=abc12,DC=gr

CN=user01,OU=TemporaryUsersPool,OU=GrandsUsers,OU=InteractiveUsers,OU=AllUsers,DC=axyz,DC=root,DC=abc12,DC=gr

Το παραπάνω επιβεβαιώθηκε επίσης και μέσα από την κονσόλα “Active Directory Users & Computers”

Κλείνοντας..

Φάνηκε λοιπόν πως ο σχεδιασμός της εφαρμογής οδήγησε σε εσφαλμένα συμπεράσματα βασιζόμενοι στη λογική ότι η εφαρμογή (ldap query tool) είναι καθ’ όλα σωστή και σίγουρα το πρόβλημα εντοπίζεται στην μεριά του Active Directory. Το πρόβλημα θα είχε αποφευχθεί αν είχαν επιλεχθεί αντί του CN το Distinguished Name (cn=user01,ou=…,dc=..) ή το samAccountName.

Τέλος για να δώσω ένα αντίστοιχο παράδειγμα σε όσους πιθανόν μπέρδεψα, το παραπάνω είναι σαν να παίρναμε τηλέφωνο στις πληροφορίες καταλόγου και να ζητούσαμε το τηλέφωνου του “Παπαδόπουλου Κώστα” χωρίς να δίναμε καμία επιπλέον πληροφορία (διεύθυνση, τκ, επάγγελμα κλπ)!

Πόσα διαφορετικά αποτελέσματα θα μαζεύαμε; Έτσι ακριβώς λειτουργούν οι κατάλογοι είτε είναι τηλεφωνικοί είτε ldap.

Πόσες και πόσες φορές δεν ενοχλούμαστε και έχουμε την αίσθηση πως το δίκτυο “σέρνεται” στο πάτωμα. Μιλώντας βέβαια με τους διαχειριστές του δικτύου (δικτυάδες) μας διαβεβαιώνουν πως υπάρχει αρκετό bandwidth και τίποτα περίεργο δεν έχει συμβεί-αλλάξει! Οπότε για άλλη μια φορά συνεχίζουμε το software troubleshooting που τελικά μπορεί να μας οδηγήσει να πειράξουμε κάτι που όντως δεν έχει πρόβλημα.

Το θέμα τελικά είναι αν υπάρχει δυνατότητα να κάνουμε μια διερεύνηση μόνοι ώστε να καταλήξουμε πόσο τελικά είναι το διαθέσιμο bandwidth σε κάθε περίπτωση.

Το πιο γρήγορο που θα έκαναν οι περισσότεροι είναι κάποιο ping (icmp echo request – echo reply) και με βάση το χρόνο απόκρισης να βγάλουν κάποιο συμπέρασμα. Τι γίνεται όμως αν υπάρχει firewall ενδιάμεσα που μπλοκάρει icmp ή αν εγώ θέλω να μάθω το διαθέσιμο εύρος για την εφαρμογή μου, πχ web service –> tcp port 80. Το τελευταίο είναι πολύ σημαντικό γιατί σε περιπτώσεις που χρησιμοποιείται κάποιο Quality of Service (QoS) τότε σίγουρα δεν επαρκεί το ping ή κάτι παρόμοιο.

Ενημερωτικά με το QoS, σε network devices, επιτυγχάνουμε προτεραιότητα σε συγκριμένες tcp πόρτες κι έτσι πρακτικά δεν μοιράζονται όλες οι εφαρμογές (tcp ports) το ίδιο bandwidth. Οπότε τι να το κάνω αν υπάρχει γραμμή 2Mbps αλλά λόγω QoS τελικά o Secure Web Server (tcp port 443) λειτουργεί τελικά με bandwidth 256kbps! 

Επίσης ας μην παραβλέπουμε το γεγονός πως μπορεί να μιλάμε για παράδειγμα για γραμμή 2Mbps αλλά το τελικό bandwidth που έχει στη διάθεσή της η υπηρεσία μας να είναι κατά πολύ μικρότερο εξαιτίας των υπολοίπων εφαρμογών-χρηστών που λειτουργούν ταυτόχρονα.

Πάμε στο πρακτικό κομμάτι όμως.

Για να βρούμε το χρόνο απόκρισης και το τελικό bandwidth πρέπει να λάβουμε υπόψη μας τα εξής:

ICMP (ping)

Στην περίπτωση του ping το μόνο δεδομένο που έχουμε είναι χρόνος απόκρισης και δεν μπορούμε να βγάλουμε κανένα συμπέρασμα για πρόβλημα σε κάποια από τις δύο μεριές εκτός από την ταχύτητα της γραμμής.

TCP Connection (3 way handshake)

Αναλύοντας το 3-way tcp connection βγάζουμε πολύ πιο ενδιαφέροντα συμπεράσματα.

Στην ανταλλαγή των 3 πρώτων frames (3 way handshake) δεν συμμετέχουν οι εφαρμογές client/server αλλά μόνο ο tcp/ip driver του λειτουργικού. Επίσης τα data που μεταδίδονται είναι ελάχιστα 70-80 bytes οπότε ο χρόνος μεταξύ του 1ου και 2ου πακέτου εδώ είναι “καθαρή” διαθέσιμη ταχύτητα. Προσοχή χρειάζεται μόνο η πλευρά από την οποία μετράμε, δηλαδή αν έχουμε εγκαταστήσει το network tracing tool στον client τότε μας ενδιαφέρει ο χρόνος 1-2, στην αντίθετη περίπτωση όμως που μετράμε από την μεριά του Server (εγκαθιστούμε εκεί το tool) τότε μας ενδιαφέρει ο χρόνος 2-3.

Μεταξύ 3 και 4 φαίνεται ο χρόνος που πλέον χρειάζεται η client εφαρμογή π.χ. Internet Explorer για να κάνει το request, οπότε μεγάλος χρόνος εδώ δείχνει πρόβλημα στην client εφαρμογή.

Τέλος ο χρόνος μεταξύ 4 – 5 δείχνει το χρόνο απόκρισης της server εφαρμογής όπου εδώ μπορούμε να δούμε αν υπάρχουν καθυστερήσεις-προβλήματα στο server software. Βέβαια στα 4-5 πρέπει να λάβουμε υπόψη μας το μέγεθος τους γιατί πιθανότατα θα είναι μεγαλύτερο από τα 1,2,3 λόγω ότι μεταφέρονται δεδομένα πλέον.

DIY

Για να βρούμε το διαθέσιμο bandwidth δεν έχουμε παρά να εγκαταστήσουμε το αντίστοιχο network trace tool (netmon, wireshark etc) και να ρυθμίσουμε: 

Network monitor 3.4

To Add a Column with the Time Delta

1. Right-click the table header row in the Frame Summary window.
2. Select Choose Columns.
3. Select Time Delta in the Disabled Columns box, and click Add to move it to the Enabled Columns box.
4. Click OK.

Wireshark

Baseline!

Τέλος για να υπάρχει baseline ώστε να μπορούμε να κάνουμε συγκρίσεις άμεσα στο μέλλον έκανα δοκιμές με καταγραφή χρόνων χρησιμοποιώντας network emulator όπου όριζα διαφορετικές ταχύτητες κάθε φορά. Τα αποτελέσματα φαίνονται στον παρακάτω πίνακα για ταχύτητες 32kbps –> 4Mbps.

(Σημ: Ο πιο περίεργος, μη αναμενόμενος χρόνος, είναι στο 1Mbps!)

Οπότε την επόμενη φορά που θα κάνουμε ping ή network trace αποκτούμε άμεση αντίληψη του bandwidth!

Trace file που χρησιμοποιήθηκε για τις μετρήσεις: Bandwidth meter.pcap

Ξαφνικά βλέπεις στο mailbox πως έχεις μήνυμα από κάποιο φίλο σου στο Facebook όπως το παρακάτω:

Το μήνυμα είναι πραγματικό και ήρθε από φίλο που προφανώς είχε πολύ εύκολο κωδικό στο facebook με αποτέλεσμα να μπορέσει κάποιος άλλος να ελέγχει παράλληλα το λογαριασμό του.

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

Κάνοντας κλικ ανακατευθυνόμαστε μέσω του facebook στο παρακάτω site

www(dot)XXXkewopobemil(dot)blogspot(dot)com

το οποίο με τη σειρά του μέσα στο source code της σελίδας περιέχει το συγκεκριμένο javascript μέσω του οποίου μπορούμε να κρύβουμε urls

location.href='http://'+'\u0077\u0077\u0077\u002e'+'\u0066\u0072\u0065\u0065\u002d'+'XXXXX'+unescape('%XX%XX%XX%XX%XX')+'\u006f\u0061\u006c\u0062'+'\u0075\u006d\u0073\u002e\u006f\u0072'+unescape('%67')+''

Αυτό που βλέπετε εδώ είναι μίγμα από ASCII χαρακτήρες π.χ. \u0077 = w ταυτόχρονα με την μέθοδο unescape της Javascript όπου επιτρέπει να γίνονται encode urls και χρησιμοποιείται σε μεγάλο βαθμό για να ξεγελάει browsers. AV etc.

Στην ουσία επανακατευθυνόμαστε στο site www(dot)XXX-XXXX-fotoalbums(dot)org(slash)2(slash)index(dot)html 

όπου μας περιμένει επιτέλους η έκπληξη

Εδώ κάνοντας κλικ στο link κατεβάζει το αρχείο

  το οποίο δείχνει να μην είναι τίποτα παραπάνω από μια φώτο. Βέβαια κάνοντας διπλό κλικ τελικά αυτό είναι εκτελέσιμο (.exe) και όχι jpg αρχείο ή κάτι παρόμοιο.

Οπότε έχουμε την παρακάτω σειρά από γεγονότα που συμβαίνουν

Μια φώτο κενή αλλά ένδειξη πως εγκαταστάθηκε επιτυχώς το Security Tool. Ευτυχώς σωθήκαμε!

Αυτό ως σωστό security tool ξεκινά έλεγχο και βρίσκει πως είμαστε infected

Tέλος μας προτείνει να καθαρίσουμε τον βρωμερό μας Η/Υ από όλα τα malware/virus που βρήκε

Έχουμε 2 επιλογές όπως φαίνεται και παραπάνω “Remove all threats now” ή “Continue unprotected”

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

όπου μας ζητάει να κάνουμε activate το προϊόν, επιλέγοντας την πρώτη επιλογή φτάνουμε στο ζουμί!!!

Εδώ πλέον πρέπει να δώσουμε τα στοιχεία μας ώστε να ξεμπερδεύουμε από το κακό που μας βρήκε.

Αυτό που συμβαίνει πλέον είναι πως ο υπολογιστής μας μέσω internet ανεβάζει ότι στοιχεία δώσουμε και κατεβάζει ενδιαφέροντα software.

Απλά πράγματα!

Τώρα θα μου πείτε μα καλά δεν το πιάνουν τα Antivirus; με ένα απλό τεστ που έκανα στο virustotal.com (online multiple AV scanner)

Όπως βλέπετε μόνο 10 από τα 42 το εντοπίζουν προς το παρόν!

Αφορμή για το παρόν άρθρο αποτελεί η συζήτηση που είχα πρόσφατα με διαχειριστές δικτύου σχετικά με την μετάβαση ενός πολύ μεγάλου δικτύου (400+ καταστήματα πανελλαδικά) σε νέα δικτυακή υποδομή και χρήση encryprion.

Kαθ’ όλη τη διάρκεια της συζήτησης επιώθηκε λοιπόν πως θα χρησιμοποιηθεί IPSEC encryption όπου χρειαστεί για λόγους ασφαλείας.

Διαισθάνθηκα πως δεν υπήρχει ιδιαίτερη γνώση για το όλο θέμα οπότε έκανα την ερώτηση για το είδος του IPSEC που θα χρησιμποιηθεί, δηλαδή αν θα είναι ESP ή Authenication Headers. Η απάντηση ήταν “έχει κάποια σημασία; νομίζω πως το default είναι ESP”

Οκ, η απάντηση σωστή μεν αλλά έδειξε άγνοια!

Χωρίς να μπω σε πολύ θεωρία το IPSEC έχει 2 λειτουργίες

• Authentication Headers όπου δεν γίνεται encrypt τίποτα αλλά χρησιμοιποιεί έξτρα headers για integrity & authenticity
• ESP όπου χρησιμοπείται για authenticity, integrity, and confidentiality. Όπου confidentiality σημαίνει encryption.

Για του λόγου το αληθές έκανα δοκιμή με GPO IPSEC & Authentication Headers σε Windows 2003 AD με Windows XP client.

Εδώ φαίνεται ping request (ICMP) χωρίς έξτρα headers.

Reply χωρίς επιπλέον headers, η IPSEC πολιτική δεν έχει εφαρμοστεί.

Εφαρμόζουμε λοιπόν την πολιτκή και

Προσέξτε το επιπλέον header (IPSEC Authentication Headers)

Πάμε τώρα να δούμε τη διαδικασία http authentication σε κάποιο web server, με τη χρήση IPSEC.

Ζητάμε τη default σελίδα. GET / HTTP/1.1

Και η απάντηση είναι πως ο server απαιτεί authentication, HTTP/1.1 401 Unauthorized

Εδώ λοιπόν δίνουμε username/password, χρησιμοποιώντας πάντα IPSEC!

Φαίνεται λοιπόν πως η χρήση AH δεν περιλαμβάνει κανένα απολύτως encryption, αντιθέτως στη χρήση ESP θα είχαμε encryption στα περιεχόμενα του πακέτου οπότε τίποτα από τα παραπάνω δε θα ήταν εμφανή!

Συνάδελφος μου περιγράφει το εξής σενάριο όπου clients συνδέονται σε εσωτερικό web site μέσω https/ssl connection και για κάποιο λόγο παρατηρείται καθυστέρηση-πάγωμα στο φόρτωμα της σελίδας. Το site χρησιμοποιεί Verisign Certificate.

Μη έχοντας κάποιο network trace απαντώ πως είτε οφείλεται σε θέμα της εφαρμογής είτε στον ενδιάμεσο χρόνο της αναμονής ο client προσπαθεί κάτι να κάνει και αποτυγχάνει. Όλα αυτά βέβαια είναι φιλολογίες οπότε με την πρώτη ευκαιρία κάνουμε network trace για να δούμε καλύτερα τι γίνεται. Οπότε με την πρώτη ευκαιρία παίρνουμε network trace και το αναλύουμε.

Όταν ξεκινάμε να κάνουμε network trace για troubleshooting λόγους προτείνεται να μη φιλτράρουμε τίποτα με capture filters γιατί έτσι μπορεί να αποκλείσουμε πληροφορίες που θα φανούν χρήσιμες. Αφού λοιπόν πάρουμε το trace file εφαρμόζουμε display filters ώστε να δούμε καλύτερα το πρόβλημα.
Στο trace file εφαρμόζω display filter (tcp.port==443) για να δούμε αρχικά τι συμβαίνει στην SSL επικοινωνία.

Αν παρατηρήσετε τις στήλες "Time" & “Delta Time” η συγκεκριμένη σύνδεση ξεκινά στις 16:28:25.841 αλλά φαίνεται πως κάποια στιγμή( frames 179 & 346) υπάρχει κενό περίπου 45'' (delta time χρόνος μεταξύ των 2 πακέτων που απεικονίζονται). Μέχρι εδώ δεν έχει βρεθεί λύση αλλά βλέπουμε το πρόβλημα μπροστά μας.

Επόμενη λογική κίνηση είναι να καθαρίσουμε τα όποια display filter ώστε να δούμε τι υπάρχει ενδιάμεσα.

Αυτό που εμφανίζεται αμέσως είναι επικοινωνία του client με τον DNS ζητώντας την IP για το crl.verisign.com

Χμμ ενδιαφέρον και μοιάζει σχετικό, μιας και το certificate του https server είναι από τη Verisign. Στο frame 175 έρχεται η απάντηση από το DNS Server με την αντίστοιχη IP 199.7.51.190.
Στο επόμενο frame βλέπουμε τον client να ξεκινά το γνωστό 3-way TCP handshake (SYN, SYN-ACK, ACK) προς την IP που μόλις έλαβε από τον DNS Server. Φαίνεται λοιπόν ο client να στέλνει το πρώτο βήμα με το flag SYN enabled.
Στη συνέχεια πως δεν φαίνεται να έρχεται η απάντηση SYN-ACK πίσω στα επόμενα frames, αλλά αντιθέτως εμφανίζεται εκ νέου προσπάθεια σύνδεσης με νέο TCP Packet με SYN Flag. Αφnύ συνεχισθεί η προσπάθεια για 6 φορές με ενδιάμεσα διαστήματα των 3’’ & 6’’ ο client επιστρέφει πίσω στην αρχική επικοινωνία. Να σημειώσω εδώ πως τα 3 & 6 δευτερόλεπτα είναι default συμπεριφορά για tcp connections.

Αυτό που παρατηρείται είναι default συμπεριφορά του Internet Explorer όπου όταν συνδέεται σε https site προσπαθεί να κατεβάσει την CRL ώστε να ελέγξει αν το συγκεκριμένο certificate έχει γίνει revoke από την αρχή έκδοσης, στην προκειμένη περίπτωση Verisign.

Έτσι λοιπόν στην περίπτωσή μας ο browser προσπαθεί συνδεθεί στο crl.verisign.com και αποτυγχάνει μιας και δεν υπάρχει δικαίωμα πρόσβασης στο συγκεκριμένο site λόγω firewall κλπ.

¨Ένα πολύ πρακτικό χαρακτηριστικό που ήρθε με τα Windows 2008 είναι η δυνατότητα επιλογής σε κάποιο αντικείμενο του Active Directory η αποφυγή διαγραφής του από λάθος ή με άλλο τρόπο.

Έτσι λοιπόν κατά τη δημιουργία ενός OU για παράδειγμα ερχόμαστε αντιμέτωποι με την παρακάτω οθόνη:

Όπως φαίνεται είναι προεπιλεγμένη η επιλογή “Protect container from accidental deletion”. Οπότε αν οποιαδήποτε στιγμή αργότερα αποφασίσουμε πως θέλουμε να το διαγράψουμε

Θα λάβουμε το μήνυμα ότι δεν έχουμε τα απαραίτητα δικαιώματα για τη συγκεκριμένη ενέργεια.

Αυτό το χαρακτηριστικό όπως καταλαβαίνετε μπορεί να μας σώσει από πολλές περίεργες περιπτώσεις όπου κατά λάθος διαγράφηκε ένα ολόκληρο OU με users/computer κλπ.

Τι συμβαίνει όμως στην περίπτωση που θέλουμε όντως να το διαγράψουμε; Αν ανοίξουμε τις ιδιότητες του αντικειμένου δεν θα βρούμε κάτι που να απενεργοποιεί την προστασία.

Για να μπορέσουμε να απενεργοποιήσουμε την προστασία πρέπει να επιλέξουμε από τα μενού της κονσόλας View –> Advanced Features

Έτσι αν επιστρέψουμε πίσω στα properties του αντικειμένου και πάμε στο TAB “Object” θα βρούμε το ζητούμενο checkbox.

Πλέον έχουμε τη δυνατότητα να αφαιρέσουμε την ασφάλεια και να διαγράψουμε το αντικείμενο.

Το συγκεκριμένο checkbox εμφανίζεται μόνο σε κονσόλες του “Active Directory Users & Computers” που είναι εγκατεστημένες σε εκδόσεις Windows Vista και μεταγενέστερες. Τι γίνεται λοιπόν αν θέλουμε να απενεργοποιήσουμε την παραπάνω ρύθμιση χωρίς να έχουμε πρόσβαση στη νεότερη κονσόλα;

Η απάντηση κρύβεται πίσω από τον τρόπο με τον οποίο λειτουργεί η αποτροπή διαγραφής. Έτσι όταν είναι επιλεγμένο το checkbox αυτό που συμβαίνει είναι ότι δημιουργείται μια επιπλέον “Access Control List” στο αντικείμενο που αποτρέπει (Deny) τη διαγραφή του αντικειμένου.

Με το τελευταίο είναι ξεκάθαρο επίσης πως μπορούμε να ενεργοποιήσουμε αυτό το νέο χαρακτηριστικό και σε περιβάλλοντα Active Directory που βασίζονται σε λειτουργικά έως και Windows 2003 απλά δημιουργώντας την παραπάνω ACL στα OUs/objects που μας ενδιαφέρει να μη χάσουμε από λανθασμένη ενέργεια. Βέβαια πάλι χρειαζόμαστε το “View –> Advanced Features” ώστε να εμφανίζεται το Security TAB με τις διαθέσιμες ACLs.