Exploit Payloads

[Verwijderd]

Ik weet niet zeker of deze vragen hier zijn toegestaan, ze zijn uitsluitend voor nobele doeleinden, maar anders bij voorbaat excuses

Na herhaaldelijke aanvalleen op mijn webservertje en de nieuwberichten met betrekking tot de grote hoeveelheden 'gehackte' pc's die onderdeel zijn van botnet's e.d. ben ik wat geintereseerd geraakt in security en penetration testing. Ik dacht zelf altijd dat hackers toch vooral in hollywood bestonden, en dat je wel een hele domme admin moest zijn om je servers te laten hacken, maar mijn zoektocht heeft me wel een beetje tot inzicht gebracht.

Met name sites zoals milw0rm en metasploit hebben mij geschokt. Complete exploits die vaak alleen nog maar even gecompiled hoeven worden waarmee hele series aan recente security flaws kunnen worden exploited zijn gewoon voor iedereen beschikbaar. Ik ben nu enthousiast aan het proberen om zelf mijn eigen servers en daemons te hacken, om te kijken of het inderdaad zo gemakkelijk is. Maar tot nu toe is het nog niet echt gelukt. Ik denk dat het komt omdat ik wat verkeerd doe met de 'payload'.

Bijna alle exploits hebben een apparte char[] array voor de payload code. Deze code wordt uitgevoerd wanneer de exploit succesvol is. Nu heb ik mij zelf altijd uitsluitend met hogere orde programmeertalen bezig gehouden, dus van deze ruwe computer heb ik niet echt kaas gegeten, maar naar ik heb begrepen hoeft dit ook niet. Je kunt gewoon een universele payload code gebruiken.

Ik heb geprobeerd om in wat exploits van milw0rm de payload code te vervangen door een code die ik zelf gegenereerd had met de metasploit generator. De exploits compilen dan nog steeds, maar vaak werken ze niet. Ik snap nu niet goed hoe dit komt. Is een payload nu universele computer code of is het toch afhankelijk van de rest van de exploit? Ook snap ik niet waar de opties 'restricted characters' and 'payload encoder' voor zijn. In welke situaties wil je character restricten?

Ook staan er op de metasploit website payloads voor een hoop verschillende Operating Systems. Betekent dit dat als je bijvoorbeeld een apache exploit pakt, en je vervang de windows payload door een linux payload, dat je dan ineens ook linux ermee kunt hacken? Het lijkt me toch dat dit ook afhankelijk zou moeten zijn van de implementatie van apache in Linux en de bijkomende security flaws.

[soulrider]

die van Metasploit gebruiken vaak de Ms-payload-'sdk' of -'api', met verwijzigen naar Ms dus die kan je niet zo vaak copy-pasten in andere code.

je kan wel proberen payload-code te verstaan en dit aan te passen naar jouw exploit.

en ja voor een exploit moet je iets verder kijken dan je digitale neus lang is: juiste OS, deamon en versie spelen al een belangrijke rol. zulke aanvallen kunnen via statistieken gebeuren als '50% gebruikt nog IE6' of door auditing of social engineering van het doelwit.

stort je niet zomaar in de "exploit en payload"-wereld, maar lees je er eerst op in voordat je iemand anders rat binnenhaalt en je systemen voor hem open zet zonder dat je het weet/merkt.

'restricted characters' = characters waarvan je weet dat ze gefilterd worden en die dus nooit voorbij het script zouden geraken (of speciale tekens waar het proces of Os vreemd op gaan reageren)
exploits en payloads zijn vaak bedoelt om zo stil mogelijk binnen te geraken en niet mbv een koevoet een deur of raam te breken.

[ Voor 19% gewijzigd door soulrider op 01-05-2008 22:12 ]

[triet]

Verwijderd schreef op donderdag 01 mei 2008 @ 21:46:
Bijna alle exploits hebben een apparte char[] array voor de payload code. Deze code wordt uitgevoerd wanneer de exploit succesvol is. Nu heb ik mij zelf altijd uitsluitend met hogere orde programmeertalen bezig gehouden, dus van deze ruwe computer heb ik niet echt kaas gegeten, maar naar ik heb begrepen hoeft dit ook niet. Je kunt gewoon een universele payload code gebruiken.

Vrijwel alle exploits werken op basis van een zgn. 'buffer-overflow'. Het idee is dus dat je een bepaalde string naar een applicatie stuurt waarmee je een buffer + wat daarna komt overschrijft met je exploit code.

Voorbeeld applicatie:
* vraag naam gebruiker
* sla input op in buffer
* print naam gebruiker

Voorbeeld van hoe dit in het geheugen zou staan:

code:

<BUFFERBUFFERBUFFER><CODECODECODE>

Als je nu een naam van de gebruiker invoert die groter is dan de buffer dan overschrijf je dus de code die daarna komt. Dit is een zgm. buffer-overflow waarbij je het buffer overflowed hebt met "A"tjes:

code:

<GEBRUIKERNAAMAAAA><AAAAAAAAACODE>

Het idee is dus dat je de code van het programma overschrijft met je exploitcode. De truuk is alleen dat het programma op een bepaalde plaats in het programma is (bv. bij de 'print naam gebruiker' routine). Zolang je programma niet de exploit code uitvoert kun je wel een succesvolle buffer-overflow gevonden en gedaan hebben maar nog geen exploit-code uitgevoerd hebben.

Om dat goed voor elkaar te krijgen is meestal wat meer onderzoek nodig. Meestal is dat niet zo'n probleem omdat men gericht in sourcecode gaat zoeken naar mogelijke flaws en dus inzicht heeft in hoe alles in het geheugen staat. Iig te complex om hier even uit te leggen.

Ik heb geprobeerd om in wat exploits van milw0rm de payload code te vervangen door een code die ik zelf gegenereerd had met de metasploit generator. De exploits compilen dan nog steeds, maar vaak werken ze niet. Ik snap nu niet goed hoe dit komt. Is een payload nu universele computer code of is het toch afhankelijk van de rest van de exploit? Ook snap ik niet waar de opties 'restricted characters' and 'payload encoder' voor zijn. In welke situaties wil je character restricten?

Payload is inderdaad de daadwerkelijke computercode die iets doet zoals een extern programma downloaden en die uitvoeren, een shell starten, etc.

Restricted chars: omdat niet alle inputroutines alle input doorlaten. Stel dat jouw exploit code de code '<' bevat en het programma, voordat hij het opslaat in de door jou te exploiten buffer, die er nou niet uitfiltert: dan werkt jouw exploit code dus niet. Die payload encoder omzeilt dat dus.

Ook staan er op de metasploit website payloads voor een hoop verschillende Operating Systems. Betekent dit dat als je bijvoorbeeld een apache exploit pakt, en je vervang de windows payload door een linux payload, dat je dan ineens ook linux ermee kunt hacken? Het lijkt me toch dat dit ook afhankelijk zou moeten zijn van de implementatie van apache in Linux en de bijkomende security flaws.

Nee, omdat veel systeemarchitecturen van elkaar verschillen (andere libs, andere asmcode) kan het zo zijn dat 1 bepaald stukje software op Windows wel te hacken is maar op linux niet. Of op linux wel maar op FreeBSD niet. Ook praat je payload vaak met het OS (bv. 'download een programma' of 'start een shell') dus moet die payload ook direct afgestemd zijn op dat OS.

Dit is allemaal even simpel uitgelegd overigens :-)

Je kunt het beste een eigen programma compilen en die proberen te exploiten.
Voorbeeld (C):

code:

int main( int argc, char *argv[] )
{
  char buf[32];

  if ( argc > 0 ) strncpy( buf, argv[1], strlen(argv[1] );
  return 0;
}

Bovenstaand voorbeeld is onveilig omdat hij de lengte van argv[1] pakt ipv het targetbuffer. Je houdt dus geen rekening met hoe groot je targetbuffer is. Typisch voorbeeld dus.

[NMe]

Een topic als dit zit een beetje op het randje, vandaar dat ik er even een waarschuwing aan toevoeg. SanneV: de volgende keer dat je erover twijfelt of je topic zo goed staat, neem dan even contact op met de lokale modforce. Die kleine moeite kan jou en ons heel wat gezeur besparen.

[Verwijderd]

Ik ben blij dat het toch wat minder makkelijk is dan ik dacht Het komt er dus op neer dat de payload een stukje binary code is die, op het moment dat hij op een plek terecht komt die gereserveerd is voor 'uitvoerende code', gerunned wordt, en dan bepaalde instructies kan uitvoeren.

Maar nu vraag ik mij af, is het altijd zo dat als je iets buiten de buffer ruimte terecht komt (omdat het te lang is voor de buffer bijv), het automatisch wordt uitgevoerd? En mag deze payload dan zelf weer onbeperkt groot zijn, of moet je van te voren ook weer weten hoe groot deze ruimte (na de buffer) is, zodat de payload daar precies in past?

[Hydra]

Verwijderd schreef op vrijdag 02 mei 2008 @ 01:39:
Maar nu vraag ik mij af, is het altijd zo dat als je iets buiten de buffer ruimte terecht komt (omdat het te lang is voor de buffer bijv), het automatisch wordt uitgevoerd? En mag deze payload dan zelf weer onbeperkt groot zijn, of moet je van te voren ook weer weten hoe groot deze ruimte (na de buffer) is, zodat de payload daar precies in past?

Nou, als die buffer gevolgd wordt door nog meer variabelen, moet je ook die overschrijven om uiteindelijk in de code te komen die uitgevoerd wordt. Dus vaak wordt de buffer + nog een hoop ruimte erachter overschreven met rotzooi om uiteindelijk code te kunnen injecteren.

[RobIII]

Verwijderd schreef op vrijdag 02 mei 2008 @ 01:39:
Maar nu vraag ik mij af, is het altijd zo dat als je iets buiten de buffer ruimte terecht komt

Met de nadruk op als...

Verwijderd schreef op vrijdag 02 mei 2008 @ 01:39:
(omdat het te lang is voor de buffer bijv), het automatisch wordt uitgevoerd?

Nee; zoals ik al zei moet je uberhaupt eerst een buffer vinden die een buffer overflow 'toestaat' (en dus een bug in de software vinden, want buffers horen niet te overflowen ). En dan is het nog maar de vraag (maar je bent al een heel eind) of je zomaar code erachter kunt knallen die dan 'blind' uitgevoerd wordt. Er moet namelijk wel weer naar dat adres gesprongen worden waar de overschreven code staat; het kan dus zijn dat je je code (lees:payload) moet 'padden' met wat dummy data omdat de eerste zoveel bytes nooit aangeroepen (zullen) worden bijvoorbeeld (omdat deze bijvoorbeeld ook, zoals de poster hier boven mij correct opmerkt, ook data kunnen bevatten i.p.v. code).

Verwijderd schreef op vrijdag 02 mei 2008 @ 01:39:
En mag deze payload dan zelf weer onbeperkt groot zijn

Nee, want de kans bestaat dat je dan de hele deamon of whatever onderuit trekt en dat alles vastslaat; en dat wil je nou net niet bereiken. Je kunt echter wel je payload ergens 'apart' parkeren en met een enkele jmp instructie ofzo (die dus in het blok na je buffer wordt geplaatst) die payload aanroepen; zo voorkom je dat je 'teveel' code overschrijft.

Verwijderd schreef op vrijdag 02 mei 2008 @ 01:39:
of moet je van te voren ook weer weten hoe groot deze ruimte (na de buffer) is, zodat de payload daar precies in past?

Zoals ik zei; een enkele JMP instructie kost maar een paar bytes; als je die weet te plaatsen zonder het 'teveel stuk' te maken ben je een heel eind.

[ Voor 3% gewijzigd door RobIII op 02-05-2008 02:00 ]

[Soultaker]

Overigens zijn het inserten van code en het uitvoeren daarvan nog twee verschillende dingen. De standaard buffer overflow truc, die bijvoorbeeld voor de code die triet postte van toepassing is, is het overschrijven van de return pointer die op de stack gezet wordt bij het callen van de functie. Daarbij kun je gebruik maken van het feit dat de stack omlaag groeit.

Bijvoorbeeld bij de executie binnen main ziet de stack er zo uit:

    | ..... |
112 +-------+
    | argv  | 4 bytes
108 +-------+
    | argc  | 4 bytes
104 +-------+
    | retip | 4 bytes
100 +-------+
    | oldbp |
 96 +-------+
    |       |
    |  buf  | 32 bytes
    |       |
 64 +-------+
    | ..... |

"buf" begint op adres 64 en de return pointer staat op adres 100, dus als de buffer overflowt kun je die waarde overschrijven. Bij het returnen van de functie wordt dan naar een adres naar keuze van de attack gesprongen. De payload wordt dan simpelweg erachteraan gezet (die overschrijft nog meer van de stack) en het doel is dan om het beginadres van de payload op de plek van de return pointer te krijgen.

Probleem is wel dat dat een absoluut adres is, dus je moet precies weten hoe de addressering daar in elkaar zit. Dat is behoorlijk platform/compiler/etc. specifiek. Verder heb je je oude base pointer, argumenten en lokale variabalen sowieso ook geclobbert, dus het is goed mogelijk dat je het programma laat crashen (wat meestal niet wenselijk is voor de aanvaller, want je wil liever een open shell starten b.v.).

Verder is al direct duidelijk dat er diverse manieren zijn om deze vulnerability te voorkomen:
- Moderne besturingssystemen en processoren kunnen data pages als non-executable markeren, wat betekent dat je er wel code kunt neerzetten maar die niet kunt uitvoeren. Als de stack-non executable is dan wordt je exploit al een stuk lastiger.
- Als addressen gerandomized worden zoals b.v. OpenBSD doet met bepaalde libraries dan is het lastig te voorspellen waar je payload terecht komt en dus lastig om er naar te springen
- Et cetera.

Vandaar dus dat exploits vaak nogal specifiek voor bepaalde software, besturingssystemen of zelfs specifieke builds werken, en er behoorlijk wat inventiviteit bij komt krijgen om een kwetsbaarheid daadwerkelijk succesvol uit te buiten. De payload zelf is meestal het minst interessant.

[Creepy]

Op aanvraag van één van de BV mods staat dit topic nu ook in Beveiliging & Virussen d.m.v. een alias

[ Voor 3% gewijzigd door Creepy op 02-05-2008 23:15 ]

[eghie]

Zeg, quote eens relevante delen in plaats van anderhalve pagina als je toch maar 1 regel toevoegt
En in je code kun je buffer overflows afvangen door maximum lengtes te forceren.

[ Voor 88% gewijzigd door RobIII op 03-05-2008 15:18 ]