Hack - c99shell.php

[edotrek]

Un paio di giorni fa ho notato uno strano movimento su un forum di cui sono admin... una veloce loggata all'ftp e noto questo strano file nella root e in /forum/ ... a quanto ho capito sfrutta una vulnerabilità nell'upload delle immagini di php.. contemporaneamente ho trovato un utente con ip e mail russa :thumbdown ... ho eliminato i due file c99shell.php e ripristinato alcuni .php mancanti del vbulletin... dopo 2 giorni ho trovato in homepage un redirect a un sito russo :look: eliminato anche quella merda, e adesso nel giro di 2 ore ho altri 2 utenti con mail e ip russo registrati -.-
Ho abilitato la conferma della registrazione al forum per email e l'abilitazione manuale, per arginare un po' la cosa ma sono un po' nel panico per fermare sto assedio... qualche consiglio? mi rivolgo specialmente a wayne / jarsil che magari ci sono già passati... :bow:

[Xangar]

disattiva l'upload di immagini finche non esce un qualche fix

[edotrek]

disattiva l'upload di immagini finche non esce un qualche fix

si ho fatto anche quello, mi son dimenticato di dirlo

[Xangar]

ma è il forum di thedeep ? :look:
ocio che quelli sniffano le password se non vengono criptate dal server....

[Xangar]

alura... se è un host aruba ti segnalo un link con la soluzione... in ogni caso se non è un host aruba puoi trovare comunque una soluzione simile

http://forum.mamboserver.com/showthread.php?t=78972

[edotrek]

ma è il forum di thedeep ? :look:
ocio che quelli sniffano le password se non vengono criptate dal server....

si è quello :look:

le pass degli utenti sono criptate da vbulletin non dovrebbero essere un problema... le pass dei database purtroppo no, sono in chiaro nei file di config di forum e dkp.. ci stiamo muovendo per cambiarle con quelli di aruba, ma vorrei evitare che ce le inculassero di nuovo appena cambiata... oltretutto non so se con quello script hanno accesso full all'ftp, credo possano solo cancellare e uppare file, non scaricare quello che gli pare... almeno spero...

[edotrek]

alura... se è un host aruba ti segnalo un link con la soluzione... in ogni caso se non è un host aruba puoi trovare comunque una soluzione simile

http://forum.mamboserver.com/showthread.php?t=78972

giro subito il link a deep, grazie :) purtroppo è un periodo sfigatissimo, lui è senza adsl, è più ferrato di me a fare queste cose ^^

[Jarsil]

Che versione di vB usate? Avete la manutenzione annuale con la Jelsoft?

[edotrek]

Che versione di vB usate? Avete la manutenzione annuale con la Jelsoft?

3.5.4, abbiamo la licenza annuale.. dici di provare a sentire l'help desk?

[Jarsil]

Scrivi sul loro forum, è probabile che gli sia stato già segnalato...

[San Vegeta]

cmq se sfruttano una vulnerabilità simile accade che si appropriano di privilegi di root o molto vicini a quelli di root, si creano un account con gli stessi privilegi, e tramite tale account fanno tutto il resto.
Ergo, eliminare lo script che ha fatto il danno non risolve il problema

[Xangar]

Da quel che ho capito leggendo i vari forum, non è una vulnerabilità del vBullettin ma è una vulnerabilità dei server php dove con questo file si attiva una backdoor php. L'emergenza sembra essere nata in questi ultimissimi giorni partendo proprio dalla Russia, e non è altro che un trojan che usa l'upload immagini come mezzo ma arriva direttamente al server

[edotrek]

Infatti io avevo un vecchio script di upload immagini senza tanti controlli (neanche uno a dirla tutta :| ) era un rimasuglio delle firme di daoc che non pensavo potesse causare tutti sti problemi :|
Mi interesserebbe capire se si sono appropriati dell'accesso ftp o meno =/

[Jarsil]

Infatti io avevo un vecchio script di upload immagini senza tanti controlli (neanche uno a dirla tutta :| ) era un rimasuglio delle firme di daoc che non pensavo potesse causare tutti sti problemi :|
Mi interesserebbe capire se si sono appropriati dell'accesso ftp o meno =/

Se vuoi posso aiutarti a capirlo in qualche modo, per quanto non sia un assoluto esperto di sicurezza informatica, dato che non è del tutto il mio campo.

Comunque la possibilità di fare danni con la funzione di upload via php c'è sempre stata, l'importante è che (e questo puoi verificarlo):

- l'utente che fa girare apache non abbia alcun privilegio al di fuori della htdocs del server
- l'utente che fa girare l'ftp segua lo stesso criterio
- non ci sia alcun bit setuid root settato nelle applicazioni che girano attraverso il server web.

Queste sono le 3 principali regole da tenere presenti per evitare di poter sfruttare delle funzionalità.

Dopodiché se hanno potuto effettuare l'accesso a mysql dalla riga di comando, vuol dire che ne hanno avuto la possibilità per uno o entrambi di questi motivi:

1) l'eseguibile di mysql è accessibile a un utente non-root (GROSSA FALLA QUESTA, controlla!!!)
2) in virtù del problema precedente relativo al server web, o grazie a un rootkit fatto passare attraverso l'upload, sono riusciti a gestire un utente root con accesso a mysql.

controlla, attraverso l'output del comando lastlog (usi linux, VERO? :D ), gli ip di TUTTI gli utenti che hanno effettuato connessioni, tenendo a mente questo:

- Se il comando lastlog lanciato come root ti dà errore, se fottuto con un rootkit che cancella il comando o lo rende ineseguibile - ne so qualcosa, pd e pm... m'è successo.
- Se il lastlog non ti restituisce ip diversi da quelli abituali di connessione, non sei ancora al sicuro, vuol dire solo che non sono entrati attraverso ssh o telnet sulla macchina, ma possono aver fatto l'accesso mediante cgi se han bucato per bene apache.


Ah (edit per aggiungere)...

Se per colmo di sfiga - ci son passato - qualcuno ti fotte la pwd di root e te la cambia con un rootkit, ci sono modi per riprendersela e kickarli fuori. In caso ti dovesse succedere, fammi un colpo di PM sul forum o su msn, tanto ce l'hai mi pare :)

[edotrek]

Se vuoi posso aiutarti a capirlo in qualche modo, per quanto non sia un assoluto esperto di sicurezza informatica, dato che non è del tutto il mio campo.

Comunque la possibilità di fare danni con la funzione di upload via php c'è sempre stata, l'importante è che (e questo puoi verificarlo):

- l'utente che fa girare apache non abbia alcun privilegio al di fuori della htdocs del server
- l'utente che fa girare l'ftp segua lo stesso criterio
- non ci sia alcun bit setuid root settato nelle applicazioni che girano attraverso il server web.

Queste sono le 3 principali regole da tenere presenti per evitare di poter sfruttare delle funzionalità.

Dopodiché se hanno potuto effettuare l'accesso a mysql dalla riga di comando, vuol dire che ne hanno avuto la possibilità per uno o entrambi di questi motivi:

1) l'eseguibile di mysql è accessibile a un utente non-root (GROSSA FALLA QUESTA, controlla!!!)
2) in virtù del problema precedente relativo al server web, o grazie a un rootkit fatto passare attraverso l'upload, sono riusciti a gestire un utente root con accesso a mysql.

controlla, attraverso l'output del comando lastlog (usi linux, VERO? :D ), gli ip di TUTTI gli utenti che hanno effettuato connessioni, tenendo a mente questo:

- Se il comando lastlog lanciato come root ti dà errore, se fottuto con un rootkit che cancella il comando o lo rende ineseguibile - ne so qualcosa, pd e pm... m'è successo.
- Se il lastlog non ti restituisce ip diversi da quelli abituali di connessione, non sei ancora al sicuro, vuol dire solo che non sono entrati attraverso ssh o telnet sulla macchina, ma possono aver fatto l'accesso mediante cgi se han bucato per bene apache.


Ah (edit per aggiungere)...

Se per colmo di sfiga - ci son passato - qualcuno ti fotte la pwd di root e te la cambia con un rootkit, ci sono modi per riprendersela e kickarli fuori. In caso ti dovesse succedere, fammi un colpo di PM sul forum o su msn, tanto ce l'hai mi pare :)


Questo mi torna utile per il serverino linux che ho installato in ufficio (con solo server ftp al momento), ti ringrazio :D

Per quanto riguarda il forum, è hostato su server linux di aruba per cui credo che almeno queste 2:

- l'utente che fa girare apache non abbia alcun privilegio al di fuori della
htdocs del server
- l'utente che fa girare l'ftp segua lo stesso criterio

siano a posto... vediamo come passa il weekend, se lunedì ci sono novità ti chiamo su msn, grazie della disponibilità :D

[San Vegeta]

se un attaccante ottiene i privilegi di root può tranquillamente cancellare o modificare i log senza che compaiano dati sulle modifiche. Esistono delle semplicissime funzioni di sistema che modificano questi dati (che altrimenti sono gestiti solo dal sistema operativo) e avendo i privilegi di root possono fare un programmino che le usa.
L'unico modo certo per loggare qualcosa sotto attacco è poter redirigere i log o il flusso di dati su una stampante, perchè i fogli non li cancelli

[Jarsil]

se un attaccante ottiene i privilegi di root può tranquillamente cancellare o modificare i log senza che compaiano dati sulle modifiche. Esistono delle semplicissime funzioni di sistema che modificano questi dati (che altrimenti sono gestiti solo dal sistema operativo) e avendo i privilegi di root possono fare un programmino che le usa.
L'unico modo certo per loggare qualcosa sotto attacco è poter redirigere i log o il flusso di dati su una stampante, perchè i fogli non li cancelli

lastlog non visualizza i log della macchina ma gli ultimi accessi effettuati dagli utenti, e non viene salvato in un file di testo.. modificarlo significa, nel 99% dei casi dei rootkit che vanno in giro sto periodo, sostituirlo con un eseguibile fasullo che non fa affatto la chiamata ai log, oppure causa un overflow e ti risponde con la classica "Broken Pipe"...