Newsgroup: it.comp.sicurezza.varie
Titolo: Il BO ha un bug?! Il BO serve a prenderci per il BO?

Se si prova a chiedere net connections a un boserver installato su una
macchina non in rete, al boserverizzato appare il simpatico messaggio
'Boserve.exe ha causato un errore di protezione nel modulo.....'
Notizie sul fatto?
Ho scaricato l'ultima versione di BO dal sito home, e installandolo i
seguenti file risultano infettati da BackOrifice.Trojan (NAV aggiornato ad
una settimana fa):
BOCLIENT.EXE
BOCONFIG.EXE
BOGUI.EXE
BOSERVE.EXE e qui sono d'accordo anch'io :-)
Voi che dite? L'antivirus legge il codice BO e pensa sia un trojan, o i cari
amici cercano di installarci BO anche utilizzando solo il client?
Saluti,
Valerio

Valerio
ciaociao
x

amici cercano di installarci BO anche utilizzando solo il client?
La prima che hai detto. L'antivirus probabilmente individua codice
legato alla comunicazione cifrata su UDP, che e' un qualcosa che i
simpatyci autory del BO non potranno cambiare facilmente - e, come
e' logico, c'e' sia nel client che nel server.
Leonardo
".signature": bad command or file name

amici cercano di installarci BO anche utilizzando solo il client?




se per ora non in modo gravissimo (pero' ci sto lavorando).
quando ti è capitato questo piantamento del bogui?
ciao
x





E' capitato al mio collega di sperimentazioni. Stavo trafficando con
un aggeggio che usa pacchetti UDP, esattamente come il BO. Quando e'
contattato dal bogui, questo tonnaccio crede di parlare con un clone
di se stesso ed invia una serie di dati. Dal canto suo il bogui, per
ragioni note a lui solo, pensa di aver trovato un boserver, e riceve
i dati come se fossero roba sana boserverizzata (cosa che non e').
I risultati sono abbastanza tristi: il mio programma si inlooppa, ed
esce dalla grossa grisi solo perche' gli ho messo un timeout, mentre
l'altra macchina si "occupa o diventa instabile". Dopo un po', torna
alla normalita'. Almeno credo, non abbiamo fatto prove estensive. Se
ho la possibilita' voglio controllare cosa succede con Windows NT.
Se mai rendo pubblico il programma dovro' specificare nel disclaimer
che non e' compatibile con il BOGUI, e chi volesse usarlo lo fara' a
proprio rischio e pericolo.
Leonardo onesto. Un po' tanto stronzo, pero' onesto.


Se devo esserti sincero pure io sto lavorando con un aggeggio che lavora con
gli upd
e piu' precisamente una backdoor che sto facendo io.
 A me non da nessuno dei problemi che riporti tu.
 Addirittura il Bogui mi vede il server della MIA backdoor anche se non
interpreta i pacchetti
e sono riuscito a far sembrare un macchina boserverizzata tramite un
semplice
read.write winsock. ... quindi mi si doveva impiantare anche a me.. invece
nulla.
 Ho provato anche a boserverizzare la macchina dove avevo installato il mio
server per fare
una ulteriore verifica e anche in questo caso nonostante i ping doppi allo
stesso povero
bogui non e' successo niente.
 E' mia opinione che i bug del client BO e del suo server siano veramente
pochi e a tutt'oggi
devo ancora trovare qualcuno che me ne cita uno SERIO!

un aggeggio che usa pacchetti UDP, esattamente come il BO
Io ho invece un programmino (non fatto da me, ma da un amico americano) ke
se riceve un comando qualsiasi dal Bogui, lo inloopa VOLONTARIAMENTE.
E' carino davvero. Lasciandolo attivo, non hai idea di quanti "cacciatori di
boserve" ho crashato. ed io non ne risento, anzi so anke l'ip e la porta del
cacciatore.
Se ti interessa contattami in mail e te lo do. Solo a te pero'! :-p (ho già
la casella di posta ultra-trafficata, se me lo rikiedete in tanti mi
inkasinate ancora di piu'; semmai poi lo metto su qualke server a vs
disposizione)
ciaociao
x



e a tutt'oggi devo ancora trovare qualcuno che me ne cita uno SERIO!
Leonardo


X lo hai messo sul ns ftp ???
se si fuori il nome
Bacco.
-----------------------------------------------------


Non l'ho guardato il serve unix, pero' se ha le istruzioni che hai
riportato tu
almeno per quanto riguarda il get dei pacchetti dovrebbe incontrare errore
sia perche' ammezza pacchetti piu' grandi troncandoli a 1024 sia perche'
comunque mantiene nello stack alto il residuo del pacchetto troncato
(e comunque ricevuto) che va ad allocarsi a casaccio.
   bisogna vedere tutto il sorgente, da solo quel pezzetto si vede poco.
Cosi' come e' messo ... e' un bug , hai ragione ma vista la perizia dei
programmatori
penso che piu' aventi nel nativo si spieghi con qualche altra procedura ..
    Ora mi carico il client unix e poi ti so dire.

Leonardo Serni (
L.S...@agora.stm.it
) wrote:
[ snip ]
: Il buffer overflow, per esempio nel client Unix, e' abbastanza sottile
: e non tutti i pacchetti lo 'triggerano':
:       memset(buff, 0, BUFFSIZE);
:       fgets(buff, 1024, stdin);
:       if (buff[strlen(buff)-1] == '\n')
:         buff[strlen(buff)-1] = '\0';
: Questa sequenza di codice, se BUFFSIZE==1024, se il buffer NON termina
: con '\n', e se un altro paio di cose ];-), determina una operazione di
: stringa fuori range, con sovrascrittura semicasuale dello stack.
Scusa, che versione del client Unix hai ? Io ho sotto mano la 1.21, e
in effetti c'e' un buco clamoroso che comincia alla riga successiva a
quelle da te riportate ;)...e' quello a cui ti riferisci o c'e' qualcosa 
di piu' interessante ?
Ciao ciao
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

Se ti interessa contattami in mail e te lo do.
Mah, grazie... ma a me casomai servirebbe per Unix; e in un certo senso ce
l'ho gia'.


quelle da te riportate ;)
Ho, appunto, la 1.21 8-D
In effetti sono stato avaro nel quotare il buco (lo chiamiamo "1KK"? 8-D ).
Ora mi stavo domandando, se uno mettesse TRE " alle posizioni 1021, 1022, e
1023...
Leonardo "Doc Mengele"


L.S...@agora.stm.it
 (Leonardo Serni) writes:
   Probabilmente, per una curiosa coincidenza, i nostri due programmi inviano
   esattamente lo stesso tipo di pacchetti. Del resto, il numero di pacchetti
   di 1024 bytes inviabili e' limitato, quindi anche andando a caso...
Si`, sono solo 2^8192 circa 10^2466, credo molto piu` del numero di atomi
dell'universo...  


L.S...@agora.stm.it
 (Leonardo Serni) writes:


Ti dimentichi il fattore sfiga :-) ... comunque la classe di pacchetti letali
e' abbastanza vasta; generando i pacchetti completamente a caso c'e' circa il
tre per mille di probabilita' di azzeccarne uno... non prendo responsabilita'
per l'esattezza del calcolo 8-)
Leonardo


Leonardo Serni (
L.S...@agora.stm.it
) wrote:
: 
big...@fokhouse.tin.it
 (Andrea Foco) wrote:







Mah...temo di non aver capito: dalle mie prove risulta che il buffer overflow
e' comunque limitato. Non si possono scrivere piu' di 1024 caratteri, e 
comunque non si riesce a scrivere oltre buff.
(a proposito, a che serve 'char *d' ? Non viene mai usato...)
Un dubbio: pero' tutto cio' e' relativo allo 'stdin', che sotto Unix in genere
corrisponde alla tastiera ;), come si puo' sfruttarlo da remoto ?


Andrea Foco (
big...@fokhouse.tin.it
) wrote:
[ snip ]
: Mah...temo di non aver capito: dalle mie prove risulta che il buffer overflow
: e' comunque limitato. Non si possono scrivere piu' di 1024 caratteri, e 
: comunque non si riesce a scrivere oltre buff.
A parte le ...ahem... imprecisioni disseminate qui e la' ;), il comportamento
da me osservato e' relativo ad alcune variabili che sono inizializzate a zero,
per cui la routine (bacata!) di copia si ferma li'.
Questo puo' dipendere dal fatto che faccio le mie prove senza essere collegato
e senza dare un host.


comunque non si riesce a scrivere oltre buff.
Aspetta, stiamo parlando di due buffer overflows diversi. Quello che dici tu
(a cui si riferisce il codice) e' locale. Quello remoto e' di diversa natura
ed, ovviamente, non ne ho il sorgente (che e' del client Windows). Credo che
i due overflows pero' siano molto simili come impostazione.
Leonardo che rileggendo il thread si accorge di essere stato troppo oscuro


Leonardo Serni (
L.S...@agora.stm.it
) wrote:
[ snip ]
: Aspetta, stiamo parlando di due buffer overflows diversi. Quello che dici tu
: (a cui si riferisce il codice) e' locale. Quello remoto e' di diversa natura
: ed, ovviamente, non ne ho il sorgente (che e' del client Windows). Credo che
: i due overflows pero' siano molto simili come impostazione.
Ahhhh...adesso capisco.
: Leonardo che rileggendo il thread si accorge di essere stato troppo oscuro
8-)
