Perché ci sono così tanti server web che vengono sfruttati generando file offuscati?

Question

Perché ci sono così tanti server web che vengono sfruttati generando file offuscati?

#1 da (3 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (0 voti)

4

TL & DR

Come fanno quei file offuscati che molti utenti si lamentano di su questo sito SE su come ottenere sui loro sistemi? E dopo, ancora più interessante come vengono eseguiti? Questo è causato dal modo in cui funziona php? Oppure è un problema di configurazioni preinstallate che devono essere modificate per proteggere un sistema ¹?

Ho letto molte volte qui persone che si lamentano di alcuni file sul loro sistema, non sanno cosa fanno, da dove vengono né come sono arrivati lì.

In realtà non riesco nemmeno a capirlo, quindi come può essere? Questo è costituito dalla meccanica di PHP ²?

Ad esempio, ho impostato il mio webserver come fcgi-app, scritto in semplice C che sta comunicando su CGI con nginx.

Il daemon FCGI (con il quale viene invocato il webhost) si trova in un gruppo di utenti con permessi speciali per la lettura / scrittura dei percorsi in cui sono archiviati i file. Quindi, prima di tutto, quando un utente sta caricando qualcosa, la mia app sta analizzando esattamente l'intero pacchetto HTTP. Quindi non riesco davvero a capire come possa essere immagazzinato qualcosa che non voglio conservare lì. Ma ok, le probabilità sono alte Non so tutto (ovviamente non lo faccio) quindi supponiamo che qualcuno abbia creato un pacchetto HTTP con contenuti corporei maligni che passano attraverso il nginx, quindi è l'input della mia app. Questa app ora non si accorge che non è un $WhatEverUsersAreSupposedToUpLoad$ e mette anche questo file dannoso ora nel punto in cui si trovano tutti gli altri file. Con lo stesso accesso limitato a tutti gli altri file (chiamato solo questo gruppo di daemon può leggere / scrivere il file).

Quindi tutto quello che posso immaginare come si possa usare un simile file ora per sfruttare il mio sistema richiede un bug maggiore nella mia app FCGI che risulta in

1: Alcuni come consente a un utente Web di modificare i diritti di accesso dell'app stessa ai file in modo che sia eseguibile E in qualche modo lo esegue
2: consente alla mia app Web di accedere al file come previsto e in qualche modo utilizzare il contenuto per sfruttare l'app stessa

o

3: in qualche modo rende la mia app che analizza i suoi dati di input, fa eseguire il file analizzato nell'app stessa. (Dal momento che il codice eseguibile C deve essere compilato non riesco a immaginare nessuno scenario in cui ciò potrebbe accadere a patto che non si verifichi il passaggio di buffer)

come ho scritto tutti e 3 i punti ora devo ammettere che suonano senza senso ... Ma che altro?

Queste preoccupazioni non riguardano le loro applicazioni in sé, ma le configurazioni di un sistema operativo non funzionante e le app che hanno installato, ignorano qualsiasi misura fatta per il materiale da utilizzare, ma alcune funzionalità principali predefinite del sistema operativo sono sfruttabili se non disabilitate quelle configurazioni?!

Se è così dovrei essere anche interessato?

Tutto ciò che ho configurato è la disabilitazione dell'accesso root remoto e dell'accesso SSH limitato all'autenticazione della chiave.

installato:

postgresql (limitato agli accessi locali solo dal gruppo di utenti web demoni)
nginx (configurato per consentire a fcgi con la mia app come percorso di esecuzione)
installato l'ultimo file fcgi per freeBSD supportato da nginx.

In realtà non ho nemmeno php sul mio sistema.

Ma dal momento che non sono un addetto alla sicurezza (altrimenti probabilmente non lo chiederò a questo),

Non so se questa è la fonte, ed è l'ultima cosa che rimane che potrei immaginare di causare questa minaccia. Ci sono altri file preconfigurati in un'installazione naked che stanno provocando questo tipo di securitythreat da solo?

¹ _{Questo mi consente di ipotizzare che un'installazione del sistema operativo più recente sia da considerare sfruttabile?!}

² _{La mia ipotesi deriva dal fatto che questo reclamo ogni volta è legato a php}

php permissions webserver web-application exploit

posta Zaibis 02.03.2016 - 16:59

fonte

4 risposte

Leggi altre domande sui tag php permissions webserver web-application exploit

Prevenzione di reindirizzamenti e inoltro non convalidati Un attacco che non modifica lo stato del server può essere considerato un attacco CSRF?

score 3 · Answer 1

Quando ti cacci un po 'più a fondo in questi casi, noterai che queste vittime usano quasi sempre un sistema di gestione dei contenuti di terze parti scritto in PHP, come Wordpress o Joomla.

Ci sono alcuni problemi con questi:

Avevano molte vulnerabilità di sicurezza in passato.
Ci sono un sacco di plugin disponibili per loro di qualità variabile che hanno anche delle vulnerabilità.
Il caricamento dei file fa parte delle funzionalità di base di un CMS, quindi i bug relativi alla sicurezza che consentono di abusare di questa funzionalità non autenticati sono in realtà abbastanza ipotizzabili.
Le persone tendono a non aggiornare questi sistemi tutte le volte che dovrebbero, quindi le installazioni con vulnerabilità prive di patch rimarranno online.
Esiste un enorme numero di installazioni per queste, quindi possono essere facilmente individuate tramite i robot automatizzati.

Potresti domandarti perché ci sono così tanti problemi con le applicazioni PHP ? PHP è un linguaggio con diversi paradigmi che rende abbastanza facile per un programmatore inesperto scrivere applicazioni insicure piene di iniezioni XSS e SQL. Inoltre, i file PHP non devono essere compilati e di solito sono immediatamente accessibili da un URL. Un file .PHP su un server web può essere eseguito solo richiedendoli con un browser Web, quindi quando l'utente malintenzionato riesce a caricarne uno, ha già pwnato il server.

In qualità di programmatore C, questi problemi ti riguardano meno, ma hai un'intera serie di problemi diversi, ad esempio dovresti pensare ai buffer overflow ogni volta che scrivi dati su un char* o un altro tipo di array.

score 3 · Answer 2

How do those obfuscated files many users complain on this SE-site about get on their systems?

Una combinazione di:

accesso al server compromesso (di solito account FTP, spesso credenziali estratte da applicazioni FTP su desktop infetti da malware)
applicazioni comunemente installate, vulnerabili, spesso obsolete e mal scritte, in esecuzione con deboli autorizzazioni

sfruttato da script automatici.

The FCGI daemon (under which the webhost is invoked) is in a user group that has special permissions for reading/writing to the paths where files are stored

Bene, stai già facendo molto meglio di molti altri.

A my-cheap-crap-shared-php-host.com è molto più probabile vedere ogni cliente che ha un account utilizzato sia per caricare il contenuto del sito (di solito tramite FTP non protetto, gioia) che per il web server per eseguirlo. O forse il web server è un utente non privilegiato ma la umask si assicura che tutto sia scrivibile in tutto il mondo.

Di conseguenza qualsiasi vulnerabilità che permetta ad un file di essere caricato su un percorso esistente o su un file sensibile (e il ragazzo fa le tipiche app PHP ne ha una tonnellata) può scrivere codice PHP e quindi immediatamente scalare la scrittura del file in un arbitrario execute codice di vulnerabilità.

Non avere per distribuire PHP in questo modo, ma molti host lo fanno, perché l'alternativa è che ai loro clienti sarà insegnato come funziona il sistema utente / gruppo / permesso POSIX, e quel tipo di costo di supporto mangerà il tuo margine di guadagno abbastanza rapidamente quando pagherai un paio di dollari al mese.

La chiave del successo di PHP è che puoi facilmente distribuire un'applicazione facendo cadere un carico di file in una directory senza dover pensare troppo all'ambiente. Questa è anche la chiave per la caduta della sicurezza di PHP.

I can't imagine any scenario where this could happen as long I ensure no buffers will flow over

Assicurarti di non avere bug per la gestione del buffer quando scrivi in C non è un'impresa da poco! Le webapp fanno molta manipolazione delle stringhe e gli strumenti di stringa stdlib sono piuttosto deboli ...

score 1 · Answer 3

Se ti affidi a questi, sono abbastanza sicuro che troverai un modello: sono in esecuzione software CMS obsoleti o plug-in obsoleti per software CMS e sono su hosting condiviso o hanno impostato l'hosting condiviso per se stessi.

Si tratta di un'enorme generalizzazione, ma il software CMS obsoleto di solito può scrivere praticamente su qualsiasi cartella all'interno del webroot - spesso aveva bug relativi alle routine di installazione o alla generazione di miniature, che richiedevano entrambi la possibilità di scrivere sul filesystem e scambiavano sicurezza dell'utilizzo di una connessione distinta per la comodità di poter eseguire aggiornamenti dall'interno del software. Non è impossibile avere un sistema di installazione sicuro basato sul web, ma la maggior parte delle prime non lo erano.

Allo stesso modo, l'hosting condiviso può essere perfettamente sicuro, ma gli host di fascia bassa spesso sembrano tagliare gli angoli. Non segregano correttamente gli utenti, quindi una persona che esegue software obsoleto spesso porta a compromettere molti siti. Naturalmente, gli utenti non riescono a vedere alcun motivo per cui ciò sia accaduto: i loro siti sono sicuri, stanno semplicemente girando su server insicuri.

Il motivo per cui molti di questi script che usano PHP è un residuo dei due fattori precedenti: gli host di fascia bassa tendono ad offrire PHP piuttosto che Python / Ruby / etc, quindi puoi essere abbastanza sicuro che lo script verrà eseguito, e aumenta il sospetto quando un file PHP viene visualizzato in un CMS basato su PHP: è piuttosto ovvio in una cartella piena di file .rb, ad esempio.

L'offuscamento è generalmente solo per impedire un facile monitoraggio. È banale cercare i file contenenti eval , ma è più difficile cercare i file che contengono una stringa codificata in base64 e decodificata in lave , che viene quindi annullata ed eseguita utilizzando un'altra funzione vulnerabile. Alcuni dei metodi di codifica sono abbastanza ingegnosi però.

score 0 · Answer 4

Un'analisi banale delle statistiche suggerirebbe che PHP sia un disastro per la sicurezza. Tuttavia, scavare un po 'più a fondo e le ragioni diventano più chiare. E la maggior parte di loro non riguarda PHP.

PHP è ovunque . È facile configurare un ambiente di hosting condiviso a basso costo con PHP. La configurazione di un ambiente sicuro è un po 'più complessa. E questo spesso significa limitare ciò che l'utente può fare. E quelle chiamate di supporto in cui è necessario spiegare ai clienti che, no, la politica per impedire a PHP di caricare file ovunque nella root dei documenti è lì per un ottimo motivo, sono molto costosi. È probabile che guidi la maggior parte dei tuoi clienti verso un fornitore concorrente che non impone un vincolo di sicurezza di base.

Un ulteriore problema è la crescita delle soluzioni di pacchetti, spesso promosse come funzionalità dai provider: Installazione con un clic! Garantire che la libreria di pacchetti in offerta sia aggiornata (e funzioni ancora con l'installer) richiede molto tempo. Cercare di garantire che le applicazioni distribuite siano aggiornate con le patch è ancora peggio.

Nel caso del software installato dall'utente, la maggior parte non si preoccupa di valutare la qualità del prodotto oltre a scoprire con quanta facilità si possa raggiungere un obiettivo molto specifico.

Dal punto di vista dei clienti, la distribuzione del codice non è più difficile della distribuzione di contenuto statico.

È facile svilupparsi. Un programma mondiale Hello è una riga di codice. Non c'è una fase di costruzione separata, nessuna configurazione della tua applicazione. Funzionerà su piattaforme di diversi fornitori.

Con una barriera così bassa all'ingresso, chiunque abbia un computer può essere uno sviluppatore PHP. Ma c'è molto di più nell'ingegneria del software rispetto alla possibilità di scrivere righe di codice.

Quindi non sorprende che ci sia un sacco di software di bassa qualità scritto in PHP.

PHP ha pochi meccanismi intrinseci per limitare la sicurezza. Ma più di PERL o C. Java si spegne in una direzione completamente diversa in termini di sicurezza.

Un confronto dettagliato della sicurezza intrinseca richiederebbe molto più tempo di quanto lo spazio lo consenta. Basti dire che quando White Hat Security ha provato a confrontare la sicurezza delle applicazioni scritte in diverse lingue, gli errori che hanno trovato erano nel codice e non nella piattaforma.