[Hackmeeting] [talk] un paio di proposte

Delete this message

Reply to this message
Autor: ginox
Data:  
A: hackmeeting
Assumpte: [Hackmeeting] [talk] un paio di proposte
il primo e' un gioco.

[pacioccare gli elfi]

L'idea e' quella di ripercorrere le tecniche per patchare un file in
formato elf che negli anni (quindi e' una cosa anche un po' retro e
storiografica volendo) virus writer, backdooratori di professione e
hobbisty hanno escogitato (tipo backdoor factory o quello che fa, o
meglio forse non fa, msfvenon con l'opzione -x e -k nella versione
framework, quella pro non so cosa faccia, per capirsi ). L'elenco non
so se completo di quello che io ho letto in giro si potrebbe fare per
celarsi all'interno di un file in formato elf,
ripreso da un libello molto figo uscito l'anno scorso, Linux binary
analysis

silvio cesare .text
reverse .text
.data infection
pt_note to pt_load

Poi c'e' il problema di come deviare il flusso di esecuzione sul codice
introdotto e tornare indietro

modificare l'entry point, plt, got .ctors, .dtors, altro

Poi se volete ci sarebbe la questione di come infettare un processo gia'
caricato in memoria.

Insomma queste cose qui

Tutta sta roba andrebbe fatta usando il linguaggio che volete,
aggeggiando un file elf, forkando o threaddando (o anche no se complica
troppo, pero' allora il codice deve fare cose che non implichino che poi
l'eseguibile originale non parta) e preservandone la funzionalita'. La
cosa sarebbe su piattaforme intel amiche a 64 bit. Quindi magari si
tratta di prendere cose che funzionavano sulle piattaforme a 32 bit e
rifarle funzionare per quelle a 64, oppure di mostrare come funziona il
codice di robe che gia' lo fanno, cmq l'analisi del codice e'
interessante, se non si limita a "ho trovato questo tool che lo lancio e
lui fa cose, pero' non so bene come".
Poi sabato sera, non troppo tardi che a me viene sonno, si vede che e'
venuto fuori, all'interno di una chiaccherata in cui si spiegano un po'
ste cose, i principi, il codice, che si e' riusciti a fare, cosa no, no
stress, no ansia da prestazione. Io mi accollo di guidare la discussione
e le spiegazioni teoriche per quanto mi riesce e di far vedere che ho
partorito. L'idea e' quella di capire meglio queste robe su linux, per
essere piu' consapevoli e credibili quando ne parliamo, perche' le
nostre analisi siano approfondite e quindi anche le nostre idee a
riguardo abbiano piu' peso.

per le stesse ragioni volevo proporre anche

[shellcosi senza pretese]

Questo invece mi e' venuto in mente guardando i programmi delle
convention super patinate tipo blackhat o simili.
In quella per l'appunto ti piazzano a margine cose cosi'
https://www.blackhat.com/us-16/training/the-shellcode-lab.html. Ora loro
saranno anche tecnicamente bravissimi, super professionali e sempre sul
pezzo per farsi dare migliaia di dollari per sta roba, pero'
restringendo l'argomento a linux su piattaforme intel amiche a 64
bit(perche' io di windows so' una sega) e tagliando un po' di roba, si
puo' fare anche noi in un paio d'ore, per avere una visione d'insieme di
che e' sta roba. Quindi volendo fare una cosa di base, ma su argomenti
forse avanzati (il forse e' d'obbligo), io proporrei questo

assembly intel a 64 bit risicato risicato per leggere e scrivere sti
robi
due esempi classici tcp shell bind e reverse shell in versione
artigianale
i problemi che sorgono e le cose di cui bisogna tenere conto (null free,
dove si mettono i parametri delle syscall,
dove le stringhe, e cose cosi')
intro ai cosi multi stage e egg hunting
usare quel che c'e': intro alla rop (return oriented programming)

L'idea e' sempre di fare qualcosa per le persone curiose, che di queste
cose sentono parlare, ma da
sole non ci si mettono, e afferrare i concetti pacioccando e giocando e
cazzeggiando tra di noi,
senza pretesa di professionalita' alcuna, e gettare le basi per
approfondire queste cose all'interno
della comunita' di hackmmeting. Quindi piu' rivolto a chi ne sa il
giusto, ma gli piacerebbe giocare,
piuttosto che a chi gia' ne mastica.

Se vi sembra una cosa utile, questo lo proporrerei per venerdi' al
mattino o non troppo tardi,
sempre perche' poi mi viene sonno.