Jeg vil i dag springe beskrivelsen af TFTP server hacket over og koncentrere mig om det hack vi har brugt det meste af dagen på, da der her er tale om et ret komplet hack der fint demonstrere hvordan en pentester arbejder.
Der er tale om et eksternt angreb mod en virksomhed der faktisk havde ret godt styr på sikkerheden, næsten alle huller var lukkede og systemerne virket fuldt patchede. Det eneste der i første omgang gav en lille revne i forsvaret var en fuldt patched og firewall beskyttet windows 2003 server, der havde port 7510 åben ud mod internettet. Vi brugte Nmap til en portscanning med version, service og OS detect til at konstaterer at det var en windows 2003 og at der bag port 7510 kørte en Apache Tomcat 4.0.4 server der ved en HTTP request afslørede at den var en del at HP NNM suite (HP open view).
Ovenstående er relativt alvorligt idet en Open View server jo kender og bruges til at kontrollerer hele det interne net. Har man kontrol med en sådan server, har man kontrol med nettet.
Vi besluttede os til at gå efter de lavthængende frugter og se om vi kunne finde nogle sårbarheder i den lette del af feltet. De protokoller der er lettest af Fuzze, er de tekst baserede protokoller som HTTP, FTP, POP3 og den slags og da vi allerede vidste at vi kunne køre HTTP requests, var det selvfølge web server delen og HTTP vi i første omgang besluttede os at prøve.
En gennemlæsning af HTTP RFC’en, der jo er frit tilgængelig på nettet, viste os at denne protokol er relativt enkel og dermed let at fuzze.
En Fuzzer er et program man kan bruge til at finde bufferoverflows i programmer. Den virker ved at sende en masse forskellige datablocks til en server og de bedste af fuzzerne har standard templates til de kendteste protokoller som man kan redigerer i og bruge. Vi brugte fuzzeren Spike til at bombarderer vores Open View server med malformed HTTP requests på port 7510 og efter ganske få sekunder gik serveren ned med et brag. Vi havde med andre ord på under 20 minutter fundet et potentielt exploitable bufferoverflow i HP oven View, en proces man burde kunne forvente at HP selv kunne have gennemført og dermed fundet og rettet fejlen.
Efter at havde fundet overflowet i Open View’s måde at håndterer Host plysninger i en HTTP request gik vi over til at arbejde specifikt med host parameter for at identificerer præcist hvad vi kunne udnytte og hvordan. Til dette formål brugte vi et Python script og ikke Spike der jo er en bred Fuzzer. Efter en smule “try and Error” fandt vi ud af at der skulle 4000 bytes til at overflyde Host feltet i en HTTP request hvilket gav os en overskrivning af systemets Internal Structured Exception Handler (SEH), hviket igen oftest betyder remote code execution, der er det samme som Game over, you have been pwned.
Næste trind er at arbejde med de 4000 bytes hvorved vi fandt ud af, at overskrivning af SEH skete efter den 3381′ende byte. For at kunne tage kontrok med Extented Instruction Pointer er vi nødt til at kune eksekvere en POP POP RET commande (vi taler her om system kommandoet) og det opnås ved at finde en hukommelses adresse i en DLL hvor disse kommandoer eksekveres og så overskrive SEH med denne adresse. Ikke særlig svært, men så let skulle det ikke være.
Vi fandt hurtigt en brugbar DLL med en, tilsyneladende brugbar, hukommellsesadresse på POP POP RET kommandoerne. Hvad der skete da vi så overskrev SEH med adressen var, at to af de 8 bytes blev ændret. Dette virkede i første omgang som sort snak, men viste sig at skyldes, at systemet kun kunne håndterer hex værdier der resulterede i alphanumeriske værdier når de blev oversat. Dette problem betyder at vi kun har et begrændset antal hex værdier til vores rådighed, hvilket igen kun giver os to muligheder. Enten af finde adresser og koder, hvor hex værdierne ligger inden for det accepterede rum eller at encode tingene med en alphanumerisk encoder der bruger værdier inden for det accepterede rum. Begge dele giver store udfordringer.
Det lykkedes os af finde en anden adresse til POP POP RET kommandoerne der lå inden for det accepterede rum, men så begyndte problemerne for alvor. Den buffer vi havde til rådighed var på ca 300 bytes, hvilket er stort nok til et reverse shellcode exploit, men ikke stort nok til et encodet reverse shellcode exploit. What to do.
Ved en hel del try an error fandt vi ud af at man ved at skubbe 1500 bytes “tilfældig” koder, vi brugte breakpoints “CC”, ind efter HTTP requesten kunne skabe en buffer i hukommelsen på 1500 bytes. Problemet var så, at vi ikke umiddelbart kunne hoppe til denne nye større buffer. Løsningen på dette problem var at bruge egghunter koden, der er lille nok til at kunne være i den oprindelige 300 bytes buffer, selvom den er encodet.
Igen var vi nødt til at tænke “out of the box”, faktisk vil jeg påstå at det er nødtendigt at tænke ude af huset og jeg er ganske imponeret over den kreativitet Mati Aharoni, vores instruktør, her udviser.
Det viste sig at vi ikke kunne udnytte nogen af de ganske avancerede standard alphanumeriske encoders der findes i f.eks Metasploit framework. Vi brugte istedet en metode som Mati kalder “To carve the encoted Eggunter code to memory, 4 bits at the time” og jeg vil her forsøge at beskrive hvordan man gør.
Man tager Egghunter koden, der er repræsenteret som bites og som ser således ud:
“\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74\xef\xb8\x54\x30\x30\x57\x…….
og som indeholder flere koder der ligger uden for det tilladte alphanumeriske rum, koden eb giver f.eks. ruder symbolet, der jo ikke er alphanumerisk. herefter kigger man på koden 4 bit ad gangen stardende bagfra. Hvis de 4 bits ikke undeholder ulovlige hexværdier, skrives de direkte til hukommelsen (via system kommandoen push. Indeholder de ulovlige værdier, divideres hex værdien for de 4 bits med det tal hvis resultat ikke indeholder ulovlige værdier. Nogle gange skal hex værdien divideres med 2 andre angen 3, 4 eller 5. Når man har findet et resultat der ikke indeholder ulovlige hex værdier adderes dette tal i adress pointeren EAX det antal gange der er nødvendigt for at nå det korrekte resultat og skubbes til hukommelsen. Ovenstående gøres 4 bit af gangen indtil hele Egghunter koden er håndencoted og skubbet til hukommelsen.
Hermed er hacket faktisk færdigt og vi har fuld kontrol med maskinen. Når man eksekvere det færdige python script, med Open View processen fanget i Olly Debug så man kan følge med i hvad der sker step for step ser man et utroligt avanceret og elegant hack, der først overskriver SEH med en hukommelses adresse til en POP POP RET adresse der flytter os 4 bytes tilbage til den oprindelige retur adresse hvor vi har vores encoted egghunter kode liggende. Herefter ser man egghunteren decode sig selv 4 bit adgangen og starte med at bladre hukommelsen igennem nippel (4 bits) for nippel. Mens egghunteren køre kan man se processeren maxe helt ud indtil den finder vores shellcode der forbinder sig til vores angrebsmaskine.
Game Over
Ovenstående megede avancerede hack beskriver en ODay exploit som vil kunne overtage enhver HP Open View server. HP har fået melding om dette hack for over et halvt år siden men de overhovet ikke har reageret og slet ikke udsendt et patch selvom det burde være enkelt at saniterer inputtet. Ovenstående er også et godt eksempel på hvordan en hacker tænker og arbejder.
Der er ikke mere at komme efter
Da klokken var 1700 var vi alle så bombede at Mati valgde at demonstrere de sidste hacks så vi kunne se på dem når vi kommer hjem. Vi så hvordan man udnytter en sårbarhed i Java Script til at få brugeren til at installerer en “Update” til java der i virkeligheden er vores shell code og andre små julelege som jeg ikke vil spilde tid på.
