Archief
- De topics van lang geleden
Exploit Materie
02-04-2007, 11:18 door Anoniem, 15 reacties
Hoi allemaal!,
Ik had een vraagje als dat zou mogen over exploits. Met betrekking tot
toegang van een shell. Hoe een exploit is opgebouwd begrijp ik nu wel
onderhand. Maar blijf haken bij een punt als je een maal toegang hebt
wat dan de relatie is tussens de shell en de uitgevoerde exploit.
Als voorbeeld sendto() wanneer de payload is uitgevoerd op de computer
en die terug geeft met recvfrom() dat je toegang hebt tot de shell. Geeft
recvfrom alleen de reply terug en is de verbinding verbroken. Dit terwijl die
bv aangeeft dat er een syn-sent is verstuurd en syn-recvied terug is
gestuurd en de verbinding established is.
Hoe kan je dan de verbinding openhouden zodat je comando's kan uitvoeren van de shell?
Ik had een vraagje als dat zou mogen over exploits. Met betrekking tot
toegang van een shell. Hoe een exploit is opgebouwd begrijp ik nu wel
onderhand. Maar blijf haken bij een punt als je een maal toegang hebt
wat dan de relatie is tussens de shell en de uitgevoerde exploit.
Als voorbeeld sendto() wanneer de payload is uitgevoerd op de computer
en die terug geeft met recvfrom() dat je toegang hebt tot de shell. Geeft
recvfrom alleen de reply terug en is de verbinding verbroken. Dit terwijl die
bv aangeeft dat er een syn-sent is verstuurd en syn-recvied terug is
gestuurd en de verbinding established is.
Hoe kan je dan de verbinding openhouden zodat je comando's kan uitvoeren van de shell?
Reacties (15)
02-04-2007, 16:48 door
pikah
Wat je met een exploit doet is het veranderen van het
programma, naar een programma dat jij hebt gemaakt (in de
shellcode).
In plaats van het normale programma zal het nieuwe programma
draaien. Jij bent al verbonden met de host, dus je hoeft
niet opnieuw een handshake te maken. Verder is het mogelijk
om in de shellcode gewoon een nieuwe poort te openen en erop
te luisteren.
Veel exploits zijn dan gewoon 'telnet-servers' die wachten
tot jij verbinding maakt.
Wat jij wil is een shell die je rechtstreeks kan benaderen. Je moet dan in je exploit shellcode gebruiken die execve() uitvoert en dan bv /bin/sh of /bin/bash
programma, naar een programma dat jij hebt gemaakt (in de
shellcode).
In plaats van het normale programma zal het nieuwe programma
draaien. Jij bent al verbonden met de host, dus je hoeft
niet opnieuw een handshake te maken. Verder is het mogelijk
om in de shellcode gewoon een nieuwe poort te openen en erop
te luisteren.
Veel exploits zijn dan gewoon 'telnet-servers' die wachten
tot jij verbinding maakt.
Wat jij wil is een shell die je rechtstreeks kan benaderen. Je moet dan in je exploit shellcode gebruiken die execve() uitvoert en dan bv /bin/sh of /bin/bash
Veel exploits zijn dan gewoon 'telnet-servers' die wachten
tot jij verbinding maakt.
tot jij verbinding maakt.
Ah ok thanks! Nu weet ik meer in welke richting moet denken :D
03-04-2007, 10:36 door
SirDice
Of een "reverse telnet" waarbij het slachtoffer een
connectie teug naar jou maakt.
connectie teug naar jou maakt.
03-04-2007, 12:36 door
pikah
Yep: connectback shell noemen ze dat.
Yep: connectback shell noemen ze dat.
Cool! Heb je dan al gelijk root rechten eigenlijk ?
03-04-2007, 17:11 door
SirDice
Door Solid
Afhankelijk van het account waar de service op draait waar je je shellcode op uitvoert. Niet elke service draait als root, een overflow op die service zal dan ook geen root opleveren maar bijv. www. Je zult dan nog een local exploit moeten uitvoeren om root rechten te krijgen (privilege elevation).Yep: connectback shell noemen ze dat.
Cool! Heb je dan al gelijk root rechten eigenlijk ?Afhankelijk van het account waar de service op draait waar
je je shellcode op uitvoert.
je je shellcode op uitvoert.
Dus dan zou je ook bij wijze als je root bent die shell een referse telnet
connectie kunnen laten uitvoeren?
04-04-2007, 08:53 door
pikah
Het apparaat waar je de shellcode op uitvoert zal een
verbinding maken met een server die jij aangeeft in je
shellcode. Op basis hiervan zal het apparaat een shell laden
die jij kan aanspreken vanaf jou luisterende socket.
Op basis van de gebruiker die de shellcode uitvoert (dus de
eigenaar van het proces waarin jij je shellcode injecteerd)
zul je die rechten ook in je shell ontvangen.
Als je dus een SSH daemon inject, zul je
hoogstwaarschijnlijk root-rechten krijgen. Apache, meestal
apache-rechten etc.
verbinding maken met een server die jij aangeeft in je
shellcode. Op basis hiervan zal het apparaat een shell laden
die jij kan aanspreken vanaf jou luisterende socket.
Op basis van de gebruiker die de shellcode uitvoert (dus de
eigenaar van het proces waarin jij je shellcode injecteerd)
zul je die rechten ook in je shell ontvangen.
Als je dus een SSH daemon inject, zul je
hoogstwaarschijnlijk root-rechten krijgen. Apache, meestal
apache-rechten etc.
Dus schematischisch zou het programma dan zo uitzien ?
1. shellcode
2. struct ip
3. struct tcp
4. sockaddr_in
5. socket ( voor verbinding)
6. sendto
7. recvfrom
8. socket ( voor listening)
9. start telnet (of iets dergelijks ) voor inkomende verbinding.
1. shellcode
2. struct ip
3. struct tcp
4. sockaddr_in
5. socket ( voor verbinding)
6. sendto
7. recvfrom
8. socket ( voor listening)
9. start telnet (of iets dergelijks ) voor inkomende verbinding.
04-04-2007, 10:12 door
SirDice
Door Solid
referse telnet connectie kunnen laten uitvoeren?
Daar hoef je geen root voor te zijn om dat te kunnen doen.Afhankelijk van het account waar de service op draait
waar je je shellcode op uitvoert.
Dus dan zou je ook bij wijze als je root bent die shell eenwaar je je shellcode op uitvoert.
referse telnet connectie kunnen laten uitvoeren?
04-04-2007, 11:25 door
pikah
Door Solid
Dus schematischisch zou het programma dan zo uitzien ?
1. shellcode
2. struct ip
3. struct tcp
4. sockaddr_in
5. socket ( voor verbinding)
6. sendto
7. recvfrom
8. socket ( voor listening)
9. start telnet (of iets dergelijks ) voor inkomende verbinding.
Dus schematischisch zou het programma dan zo uitzien ?
1. shellcode
2. struct ip
3. struct tcp
4. sockaddr_in
5. socket ( voor verbinding)
6. sendto
7. recvfrom
8. socket ( voor listening)
9. start telnet (of iets dergelijks ) voor inkomende verbinding.
Je haalt dingen door elkaar. De overflow is meestal de data
binnen het TCP/UDP pakketje, omdat je meestal een service
exploit en niet het protocol zelf.
Het erbij halen van de ip en tcp header is dus irrelevant
naar mijn mening.
Daar hoef je geen root voor te zijn om dat te kunnen doen.
Sweet!
Je haalt dingen door elkaar. De overflow is meestal de data
binnen het TCP/UDP pakketje, omdat je meestal een service
exploit en niet het protocol zelf.
Het erbij halen van de ip en tcp header is dus irrelevant
naar mijn mening.
binnen het TCP/UDP pakketje, omdat je meestal een service
exploit en niet het protocol zelf.
Het erbij halen van de ip en tcp header is dus irrelevant
naar mijn mening.
Ah ok dat dacht ik in het begin namelijk gezien de payload.
Dat je de payload moest toevoegen aan het protocol. Omdat het
uitgepakt werd in de socket.
Dus dan zou het programma er zo uitzien ?
1. shellcode
2. struct tcp
3. data + tcp
4. sock addr_in
5. socket ( voor verbinding)
6. sendto(data)
7. recvfrom()
8 socket ( voor listening )
9 start telnet ( voor incomende verbinding )
04-04-2007, 12:32 door
pikah
Voor het luisteren zou ik zelf gewoon netcat gebruiken. Dus
ik zou dat niet zelf helemaal gaan programmeren. Dit is
nergens voor nodig.
ik zou dat niet zelf helemaal gaan programmeren. Dit is
nergens voor nodig.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
