Newsgroup: it.comp.sicurezza.varie
Titolo: New Entry..

Salve a tutti,
Ultimamente hanno "bucato" una macchia Linux che ci fungeva da server
web per le demo su internet..
Premesso che la macchina e' stata installata circa un anno fa e che da
allora non aveva mai presentato
problemi di sicurezza (probabilmente per il semplice fatto che chi
l'aveva bucata se ne era rimasto quatto quatto a farsi gli affari suoi
;O).
Sono inoltre conscio dell'amministrazione da ANIMALI che vi e' stata
applicata (non ho "istituzionalmente parlando" il compito di
amministrare la sicurezza ma solo di installare e programmare).
Tale compito spettava ai nostri benemeriti del "CED" (che capiscono solo
quando gli parli "in modalita' M$ finestre").
Fattosta' che recentemente vengo chiamato di corsa al CED perche' la
macchina "spara" pacchetti a destra e a manca saturando tutta la banda
disponibile verso l'esterno.
Dopo averla staccata dalla rete mi consentono di curiosare un po' per
vedere di cosa si trattava:
A quanto pare qualcuno ha bucato Apache, guadagnato un accesso come root
e con esso, dopo aver buttato giu' tutti gli altri servizi (meno
oracle.. chissa' perche') compilato una serie di files *.c.
Tali files hanno dei nomi piuttosto espliciti come "libinvisible.c" e
"adore.c".
Dopo avergli dato un'occhiata e fatto una veloce ricerca ho dedotto che
mi trovavo di fronte ad un modulo del kernel che occulta la presenza di
processi in background e che "non pago di cio'" apre pure una backdoor
sulla macchina stessa.. =:-O
Nei vari log e .history ovviamente NON c e' traccia di nulla..
..se non fosse che a suo tempo avevo installato (chiamatela scaramazia)
"portsentry" (non in maniera proattiva comunque) e quindi sul file
"messages" mi ritrovo tutti i santi giorni due o tre tentativi di port
scanning con tanto di IP sorgente data e ora del tentativo.
Fatta questa luuuuunga premessa (ok ok buonanotte.. ;O) volevo chiedere
ai lorsignori:
1- potete darmi altre informazioni su questo (come dire.. "benemerito")
modulo adore.o?
2- si puo' sperare di saperne di piu' sull'attaccante?
3- e' ragionevole ipotizzare che l'attaccante sia lo stesso dei port
scanning?
4- e se si, come mai non ha cancellato anche le warning di portsentry da
messages?
Grazie a tutti per l'ascolto!
By MCM.


che potrebbero non c'entrare na mazza con l' "attacco" da te rilevato...
ma cmq, mettiamoci pure questo, dentro il CALDERONE :-)

 modulo adore.o?
e' un modulo che viene usato per modificare l'output di parecchi programmi
senza modificare i programmi stessi ma intercettando le chiamate di
sistema che fanno,e' usato in parecchi rootkit (non so se anche da qualche
worm ...).In pratica ti modifica l'output di un "ls -l" senza toccare il
binario di ls ma intercettando le chiamate che fa .
PS :essendo anche cancellata la history a me sa di rootkit piu che di worm
... scarica chrootkit (per curiosita mica per altro ,prima o poi quella
macchina la devi spianare ...)
-- 
          "chown linux:users /world"
"E se i filosofi a cena mangiassero colle mani ?"

 "benemerito") modulo adore.o?
E' questo?
http://www.digitaloffense.net/worms/adore/lib_hack_hellno/wipe-
1.00/adore/
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 macchina la devi spianare ...)
Mmmmh... Giorni fa, per un quiz proposto da un sito, ho analizzato una 
variante dello Slapper e tra le funzionalita' di "infezione" c'era
quella di
uploadare due file .c (worm + backdoor stupida) compilarli e lanciarli.
Non mi stupirei che tra le funzionalita' ci sia quella di uploadare e
caricare un modulo per schiavizzare ulteriormente la macchina ( un
modulo che wrappa le syscall non sono tante righe di codice (vabbeh ci
vogliono gli header del
kernel sulla macchina)^__^ )
Ciao!
-- 
gen. Trimack aka gen. Puzzerstoven 
Per favore non mandatemi allegati in Word o PowerPoint.
Si veda 
http://www.fsf.org/philosophy/no-word-attachments.it.html
 
IAFo #196 -- Linux Registered User #274161

 caricare un modulo per schiavizzare ulteriormente la macchina
si,certo,mi faceva pensare piu a un rootkit il fatto che fosse stata
toccata la history della bash,un worm non avrebbe ragione di farlo,solo
che in effetti lui dice solo "nella history non c'e' traccia" non che e'
stata modificata ...


 ma cmq, mettiamoci pure questo, dentro il CALDERONE :-)
Si, infatti l'avevo intuito..
Cmq, correggetemi se sbaglio, ma non e' che un port scanning puo' essere
considerato di per se un reato?
voglio dire: e come se qualcuno tentasse di sbirciare attraverso la
serratura della porta di casa.. non e' violazione della privacy?
Ciao e grazie della risposta
By MCM.

 macchina la devi spianare ...)
Questo e' poco ma sicuro! :O)
Ciao e grazie By MCM.


se cosi' fosse, sai quanti testimoni di geova ci sarebbero in galera... ?
;-)
Scherzi a parte, per il momento il portscanning non configura un reato,
perche' il tuo paragone corrisponde al "bussare alla porta", piu' che allo
"sbirciare attraverso la serratura".

 kernel sulla macchina)^__^ )
Sigh.. hai perfettamente ragione!!!!
Dovevo disinstallarle con tutto l'ambiente di compilazione...
e magari fare un kernel monolitico senza supporto per i moduli prima..
;O)
Che vuoi farci.. la mia esperienza sul "campo di battaglia" non era (e
non e' ancora) un gran che.. :O(
Ciao e grazie anche a te!
By MCM.

 "sbirciare attraverso la serratura".
Ok, ho capito.. pazienza..
Cmq, nessuno mi vieta una bella "iptables -A INPUT -s [IP sbirciatore]
-j drop" automatica ogni volta che portsentry scopre un TCP SYN scan..
giusto? ;O)
Ciao by MCM.


giusto !
Danny che il firewall... somatizza ;-)

 1.00/adore/
Purtroppo no ho la possibilita' di vedere la macchina adesso (e' chiusa
a chiave nel CED con il cavo di rete staccato) pero' mi pare proprio di
si!
Ciao By MCM.

 Danny che il firewall... somatizza ;-)
hehehe! :O)
By MCM.

 differenza tra una ps -fe ed i pid che trovo in /proc.. giusto?
in generale no,nello specifico non so [1]. Scarica kstat da 
www.s0ftpj.org
,scansiona la memoria alla ricerca di moduli caricati anche se nascosti,e'
fatto apposta ... oltretutto mi sembra che nella documentazione nel
tarball ci sia un esempio proprio su adore o comunque uno simile ...
[1] dipende ... ps attinge informazioni da /proc,se e' compromesso solo il
binario di ps il tuo paragone ha senso,quando hai a che fare con un lkm
non hai questa garanzia,anzi ... non so adore che combina,cerca
informazioni in giro.


 differenza tra una ps -fe ed i pid che trovo in /proc.. giusto?
Con un rootkit installato, se e' fatto bene, direi di no...
C'e' questa possibilita':
scriverti un modulo che scorre e analizza la lista doppia concatenata 
che il kernel usa per memorizzare i processi (
www.phrack.org
) fa un dump
da qualche parte (per esempio un device a caratteri che poi vai a
leggere)
C'e' anche la possibilta' di mascherare anche parti di quella lista...
(un recente numero di BFI proponeva di far comparire un processo
 solo prima della chiamata allo scheduler e di nasconderlo subito dopo)
In questo caso, penso IMHO e sottolineo IMHO (non ho analizzato quel
codice alla grande), l'unica alternativa e' il controllo dei 
puntatori alle funzioni che implementano le syscall (in un kernel
"rootkittato" sono per forza diverse): mi pare che alcuni anti-rootkit
lo
facciano... ma mi pare che si possa aggirare anche quel controllo ^__^
Ciao!
Trimack, che caXXo ho mangiato stamattina? scrivo peggio di un
bambino...


 dei server e, soprattutto, tenere agiornate le macchine.
Si.. lo so.. pero' con la "struttura" attuale (con questo mi riferisco
alla mentalita' e al "management" della ditta) cio' non mi e'
consentito.. in altre parole, dell'immagine pubblica se ne fregano..
contano solo le fatture.. :-/
Tornando al discorso, la porta web e la porta tarantella (per chi lo
conosce) dovevano restare aperte.. e da esse non potevo sapere se si
verificavano degli scan (essendo occupate..) percio' ho messo portsentry
in attesa su una porta molto gradita ai rompiscatole (ftp) in modo da
rendermi conto di come andavano (piu' o meno) le cose.
Un' altra cosetta che mi e' venuta in mente ora.. avrei potuto
modificare i sorgenti della bash e del syslogd per scrivere una copia
dei log dove mi pare a me, senza passare dal file di configurazione e
soprattutto, crittografandole..
..cmq, ormai e' tardi.. non so neanche se me lo faranno rimettere in
piedi quel server.. :( 
..e anche se fosse, con la gestione attuale, non penso che durerebbe
moltissimo.
Ciao!
By MCM.

 informazioni in giro.
Mi piacerebbe studiarmelo un po' meglio infatti.. e se ne avro' il tempo
lo faro', perche' ormai mi ha incuriosito ;O)
Ciao by MCM.

 serratura della porta di casa.. non e' violazione della privacy?
Assolutamente no.
La privacy riguarda tutti quei i dati che possono identificare un
individuo (persona fisica).
-- 
HappyCactus - Linux User #209744 - LFS User #6046 - >>> SMSPM1050 <<<
              YAGF Member Group >>> 
www.google.com
 <<<
Ci sono 10 categorie di persone al mondo: quelle che capiscono
il sistema binario e quelle che non lo capiscono.

bambino...
Ma no!.. che dici.. il senso si capiva ;O)
Ciao!
By MCM.

 giusto? ;O)
Certo, ma non e' una bella idea.
HappyCactus che nmap -sS -e eth0 -S 193.205.245.66 <tuoip>


 No.
Per una risposta ancor meno "secca" mi sono beccato un cazziatone
(per lo piu' ingiustificato, IMHO) su it.diritto.internet.
Fabio

, Fabio Panigatti
wrote:

E' bello vedere come questo thread rischi di riaprirsi a cadenza
periodica: sarà forse perchè la giurisprudenza in merito è praticamente
inesistente?
-- 
Roberto Tagliaferri<-> r.tagliaferri@(forse)
tosnet.it
	Sentito da una programmatrice:
	"Ma vi capita mai nella vita reale, tipo mentre
	rifate il letto di dire 'Ho sbagliato, pigio ctrl-Z'?"

 praticamente inesistente?
C'e' un solo caso noto (AFAIK), la cui interpretazione, peraltro, porta
a pensare che non ci sia stata aluna fattispece penale, ma non mi hanno
dato conferma di cio'. Il fatto che i thread si riaprano periodicamente
penso che sia fisiologico, in usenet. I motivi per cui poi sfocia in un
guazzabuglio penso che siano da cercare sia nella mancanza di una ampia
e consolidata giurisprudenza sia in una componente semantica, per cui i
giuristi non riescono a recepire cosa sia un portscaning e i tecnici si
trovano poco preparati di fronte alle sottigliezze dell'interpretazione
e della descrizione giuridica dei fatti. Il tutto condito con un po' di
disinteresse dei primi, un po' di propensione al flame e quella dose di
visceralita' tipica di coloro che ogni di' vedono apparire finestre dai
colori sgargianti del tipo "Alert!! Il tuo pc e' sotto attacco da parte
di PIM-ROUTERS.MCAST: premi dei tasti a caso per scovare et punire quei
gaglioffi usando la nostra tecnologia hackersnuker-o-matic (patented)".
Fabio

 giusto? ;O)
Occhio...
Adesso con nmap e' possibile falsificare il "mittente" del portscan,
quindi si lascerebbe aperta la strada a Denial of Service vari ed
eventuali utilizzando regole di quel tipo.
Meglio un log.
-- 
   => Don't Let Your Fears Stand in The Way of Your Dreams !!! <=
   URL: 
http://www.delymyth.net/
 ~ E-Mail: 
DEly...@despammed.com
            => ICQ#: 8761263 - MSN: 
dely...@msn.com
 <=
          => FREE! Hardware Anti-Virus!!! - /dev/brain <=

 HappyCactus che nmap -sS -e eth0 -S 193.205.245.66 <tuoip>
Urka!
Avete ragione! :.(..
Ma.. un attimo, se il suo indirizzo e' spoofato non dovrebbe accorgersi 
il kernel?..
(ok, sono un novizio della sicurezza, si era capito..)
Qualcuno pou' mostrarmi la luce? ;O)
ciao By MCM.

 accorgersi il kernel?..
E come potrebbe? la destination come la source e' validissima. Non si
tratta di un martian, si badi bene, lo sarebbe se avessi specificato il
tuo ip, o un ip non valido, come source...


 tuo ip, o un ip non valido, come source...
Mumble mumble.. Dunque, vediamo..
Lui imposta un source address diveso dal suo sapendo che poi deve per 
forza "intercettare" i pacchetti che sarebbero indirizzati a tale host. 
(fin qui tutto ok).
Il simpatico pacchetto se ne va quindi a fare un bel giretto turistico 
dei router finche' non giunge alla mia macchina.. (ok anche qui)
Quest' ultima, da "brava bambina", rispone con il famoso ACK 
all'indirizzo sorgente in esso contenuto (senza sapere che non e' quello 
di partenza..).
A questo punto ho bisogno di un chiarimento:
Domanda 1: Come fa il pacchetto a raggiungare il tipo, dato che l'ip non 
e' il suo? Insomma, il pacchetto potrebbe prendere strade che non lo 
condurranno mai dal chiamante..
Domanda 2: e se il vero host riceve un ACK senza prima aver spedito un 
SYN.. che dici, pensa di essere stato spoofato?
(Mi sa che e' ora di una bella ripassatina al "Tanembaum" :O)
Ciao by MCM.

 (Mi sa che e' ora di una bella ripassatina al "Tanembaum" :O)
Se e' per quello, anche per me, ma fi qui le tue deduzioni mi paiono
corrette.


 condurranno mai dal chiamante..
non c'e' bisogno che le risposte arrivino a chi fa la scansione ...
fai prima a guardarci da solo tanto non e' complicato :-)
http://insecure.org/nmap/idlescan.html


 
http://insecure.org/nmap/idlescan.html
Grazie mille del link!!! :)
Se ho ben capito, tutto comincia dallo zombie che per primo riceve un 
SYN|ACK senza aver spedito un SYN..
Quindi teoricamente potrei evitare ad un mio host di fare da zombie 
ignorando semplicemente quei pacchetti..
Ma non potrei certo evitare che lo faccia qualcun'altro.. :(
D'altra parte, neanche implementare dei generatori di IPID meno 
"indovinabili" preclude il fatto che gli altri possano diventare 
comunque zombie.. :(
Morale, tocca rassegnarsi ad essere analizzati.. :(
By MCM.

Morale, tocca rassegnarsi ad essere analizzati.. :(
Non e' detto. Supponiamo che 
evil.hacker.org
 utilizzi 
hapless.victim.com
come idlescan verso di me.
Mi invia quindi un pacchetto SYN con indirizzo 
hapless.victim.com
, ed io
potrei rispondere SYN|ACK oppure RST.
Diciamo che la mia porta X e' chiusa; quindi io dovrei rispondere usando
RST.
Ma diciamo che la mia porta X e' chiusa: quindi, cosa cappero c'incastra
che qualcuno mi mandi un SYN? E se mi manda un SYN illecito, io mi sento
moralmente autorizzato a rispondere come meglio ritengo opportuno.
Quindi, se la porta e' APERTA, rispondo con SYN|ACK.
Se pero' la porta e' CHIUSA, rispondo con SYN|ACK.
O distinguile, vai, che ce famo du' ghigni.
Se poi 
hapless.victim.com
 stava DAVVERO cercando LUI di connettersi, per
forza di cose rispondera' al mio SYN|ACK, per completare il 3-way HS. In
quel momento, e solo allora, gli spediro' un RST nelle gengive.
Sostanzialmente potrei combinare un packet filter, che faccia sparire (a
livello di host retrostante) i pacchetti SYN verso le porte proebite, ad
esempio arimbarzandoli contro una interfaccia virtuale creata ad hoc. Su
quella interfaccia si mette in ascolto un ghiavolo basato su libpcapn, e
quando riceve un SYN, lui falsifica un SYN|ACK credibile; e se arriva un
ACK da uno degli indirizzi che l'hanno SYNato, risponde RST - e marca la
macchina come "Non Zombi, Pero' Fava... O Scanner In Prima Persona". Per
ovvie ragioni, se non arriva *nulla*, sono di fronte a un half-open o ad
un qualcosa di simile, insomma, la macchina originante e' cattiva, e non
semplicemente shtùpida.
Se invece riceve un RST al SYN|ACK, la macchina e' classificata "Zombi",
ma me lo segno lo stesso, casomai fosse invece un catìvo che preferisce,
non scioccamente, farsi passare per stupido anziche' per cattivo. Ma per
ora diciamo che e' una zombi.
Ancora non sapro' chi e' che l'ha zombata - pero' chiunque sia vede, con
nmap, *TUTTE LE PORTE APERTE*, al che:
a) E' un kiddie con EEG piatto: si frega le mani, e dice "Badali', tutto
   aperto e squadernato", e mi netbussa sulla porta 20034
	#include "sudari/pietoso.h"
b) E' uno con attivita' cerebrale registrabile: capisce che qualcosa, da
   qualche parte, non e' andata per i'vverso, e se non e' scemo scemo si
   rende conto che le risposte "Tutto chiuso!" o "Tutto aperto!" sono in
   sostanza equivalenti.
Viceversa, il pulàster che mi si collega alla porta 6669, ricevendone un
RST, si sgancia subito - e lo strato soprastante continua a dire che non
c'e' connessione.
Oppure, posso mandargli un SYN|ACK _invalido_... tanto per uno zombi non
cambia nulla, e se e' uno catìvo, equivale a un connect scan, insomma si
deve rendere visibile. Pero', col valido posso distinguere se e' zombi o
no; insomma, dipende quanto voglio essere d'aiuto a chi sbaglia :-)
--- 
IMHO, IMHO, fortissimamente IMHO. Pomodori e gatti morti --> /dev/null
--- 
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

nmap -sS, una volta ricevuro un synack, manda un reset.
Ah, vero, quindi non distinguo uno zombi da un nmappatore.
Salvo che -sS manda un RST anche in risposta a un SYN|ACK legittimo da
una porta realmente aperta.
Leonardo
-- 
Questo messaggio e' NAGWARE. Per disattivare frecciatine, giochi
di parole, volgarita' gratuite ed inviti a rileggersi i messaggi
gia' passati e/o consultare 
http://groups.google.com
, effettuare
un versamento di 25 euro come tariffa di registrazione helpdesk.

 Leonardo
Mitico! Quanto mi piacciono questi "brain storming"!! ;-)
Cmq, mi garba da paura l'idea di far credere che TUTTE le porte sono 
aperte! :-D..
Ciao bella gente!
MCM.

Una bella estensione per il target REJECT come la vedi? :)
Stavo pensando ad un programmino che ascoltava la roba in ingresso e poteva
passarla a vari "handler" a seconda di cosa c'era nel file .conf.
Non ricordo dov'e' che l'ho visto.
Leonardo guasi guasi


 Non ricordo dov'e' che l'ho visto.
Prova a cercare iplogd su google <g>


 Ah, vero, ...
Non vorrei essere eccessivamente pignolo :-) ma non e' nmap 
che resetta il synack, bensi' il kernel dell'host all'ip di
destinazione.
Fabio 

 Morale, tocca rassegnarsi ad essere analizzati.. :(
a meno di sputare in faccia alle rfc temo di si.


tcp/ip del tuo sistema operativo ...
linux, su debian non ha particolari problemi:
mood:~# hping localhost -r -c 5
HPING localhost (lo 127.0.0.1): NO FLAGS are set, 40 headers + 0 data
bytes
len=40 ip=127.0.0.1 flags=RA DF seq=0 ttl=255 id=0 win=0 rtt=0.5 ms
len=40 ip=127.0.0.1 flags=RA DF seq=1 ttl=255 id=+0 win=0 rtt=0.4 ms
len=40 ip=127.0.0.1 flags=RA DF seq=2 ttl=255 id=+0 win=0 rtt=0.4 ms
len=40 ip=127.0.0.1 flags=RA DF seq=3 ttl=255 id=+0 win=0 rtt=0.4 ms
len=40 ip=127.0.0.1 flags=RA DF seq=4 ttl=255 id=+0 win=0 rtt=0.4 ms
mood:~# nmap -P0 -vvv -sI localhost 
www.microsoft.com
Starting nmap V. 2.54BETA31 ( 
www.insecure.org/nmap/
 )
Host 
www.us.microsoft.com
 (207.46.249.190) appears to be up ... good.
Idlescan zombie localhost (127.0.0.1) port 80 cannot be used because
IPID sequencability class is: All zeros.  Try another proxy.
QUITTING!
kernel 2.4
-- 
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

> Ah, vero, ...

/me imbarazzato


 non e' che una scansione sia sta gran tragedia eh :-) 
Scherzi?.. Meno cose scoprono e meglio e'!..
D'altronde lo dice anche il dentista della pubblicita': <<Prevenire e' 
meglio che curare..>> :)
By MCM.

 Leonardo guasi guasi
/me che sarebbe ora!
Ciao Francesco.
-- 
<*> bash$ man -h  per il pinguino che non deve chiedere mai. <*>  
<*> lynx file:/usr/doc/*                                     <*>
<*> SMSPM 1701                                               <*>

 !(actually our OS kernel does this for us).
Mmmavafff... a suo tempo c'ho perso un ora, tra lettura dei sorgenti [1]
e l'inventarmi un modo per dimostrare al solito idio^Wesperto che era il
kernel a resettare i synack e non nmap [2]. 
Fabio che alla fine era un banale RTFM
[1] per me tra c e cuneiforme l'unica differenza che salta all'occhio e'
    che il secondo normalmente e' su pietra, ma alla fine m'era sembrato
    che le cose stessero cosi'.
[2] demo fallita in partenza: "Bene, cominciamo"... clickete... click...
    "arp -s ip <ip> <MAC>" " Che cosa hai fatto?" (me spiega a lui) "Be'
    ma cosa c'entra arp? Non stavamo mica parlando di tcp/ip?" "E allora
    mi dicevi che quest'estate tu andrai in messico, giusto?" (alzandomi
    e invitandolo a prendere un caffe', molto lontano dai server).

 l'inizio e la fine delle connessioni.
Le scansioni -sS (default nmap) vengono eseguite in modalita' raw,
senza intervento del kernel per generare e leggere i pacchetti. Se
nmap rispondesse verrebbero emessi due rst: uno dallo stack che si
trova un synack diretto ad una porta che non e' in syn-sent, e uno
da nmap in modalita' raw. Diverso e' quando si usa -sT, con cui il
traffico viene generato usando lo stack tcp/ip della macchina, con
porte in syn-sent, ecc. Se usato in questa modalita', nmap imposta 
il socket lingering a zero, cosi' che al termine dell'handshake la
chiusura del socket da parte di nmap provochi l'emisisone d'un RST
per risparmiare tempo e banda. Qui, forse, si potrebbe anche dire,
in una qualche accezione, che e' nmap a emettere il rst, ma e' una 
situazione diversa, in cui e' il kernel a gestire il traffico tcp:
d fatto nmap non fa altro che chiudere il socket.
Fabio che tra le righe...

