Come faccio a sapere se un file di immagine corrotto viene utilizzato per la scrematura della carta di credito?


17

Sto lavorando con un sito che credo sia stato violato per raccogliere i dati della carta di credito dei clienti, ma non posso esserne certo.

Non ho trovato alcun codice sospetto nei luoghi comuni che ho visto suggerito in diversi articoli.

Ho fatto trovare un sospetto "rotto" file di immagine in:

/skin/adminhtml/default/default/images/db-tab-bottom-right-bg_bg.gif

Ho cambiato l'estensione del file e l'ho aperta, ma è solo un muro di testo crittografato con JPEG-1.1sparsi.

Come posso sapere se il sito è compromesso?

Ho confermato che la patch è stata applicata, ma l'hack potrebbe essersi verificato prima della patch.

EDIT: la versione interessata è 1.7.0.2

Risposte:


21

Per la risposta specifica alla tua domanda, vedi /magento//a/72700/361

sfondo

In primo luogo, non esiste un exploit specifico : al momento ci sono una serie di articoli che fanno il giro che hanno frainteso e frainteso l'articolo di origine.

L' articolo originale diceva semplicemente (e sto parafrasando),

Se un hacker fosse in grado di accedere ai tuoi file Magento, potrebbe acquisire informazioni dai tuoi clienti

La parte chiave è l'hacker che deve effettivamente accedere al tuo server e modificare i file.


Non fatevi prendere dal panico ... questo non è niente di specifico per Magento

In termini di acquisizione di informazioni, non c'è nulla di specifico in Magento di qualsiasi altro sito Web / piattaforma. Se un hacker ottiene l'accesso ai tuoi file, è effettivamente finito il gioco: sarebbero in grado di catturare qualsiasi informazione desiderassero.

Il meglio che puoi fare (e, in definitiva, il minimo che dovresti fare) è mantenere una buona politica di sicurezza che aderisca agli standard di sicurezza PCI del settore dei processi di pagamento, puoi trovare l'elenco qui, https://www.pcisecuritystandards.org /documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf


Rafforza il tuo negozio

Puoi davvero bloccare le sfaccettature del tuo negozio che riducono notevolmente l'area di attacco superficiale per un hacker, o almeno, rallentano i suoi progressi se riescono a entrare /

Blocca le autorizzazioni

È possibile limitare le autorizzazioni sulla radice del documento per consentire la scrittura solo nelle directory essenziali ( /vare /media)

Questo è ciò che facciamo di default su MageStack ,

echo -n "Fixing ownership"
chown -R $SSH_USER:$WEB_GROUP $INSTALL_PATH && echo " ... OK" || echo " ... ERROR"
INSTALL_PATH="/path/to/public_html"
chmod 750 $INSTALL_PATH
find $INSTALL_PATH -type d ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing file permissions"
find $INSTALL_PATH -type f ! -perm 740 -exec chmod 740 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing cron permissions"
find $INSTALL_PATH/*/cron.sh -type f ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var file permissions"
chmod -R 760 $INSTALL_PATH/*/media $INSTALL_PATH/*/var && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var directory permissions"
find $INSTALL_PATH/*/media $INSTALL_PATH/*/var -type d ! -perm 770 -exec chmod 770 {} \; && echo " ... OK" || echo " ... ERROR"

Adatta INSTALL_PATH,SSH_USER,WEB_GROUPin base alle tue esigenze. Ciò che è importante è che il tuo SSH_USERnon è lo stesso utente che PHP utilizza per il processo del server Web, altrimenti, in sostanza, forniresti l'accesso completo in scrittura al server Web (mitigando eventuali vantaggi).

Blocca l'accesso amministratore / downloader

Su MageStack, lo imposteresti ___general/x.conf

set $magestack_protect_admin true;
set $magestack_protect_downloader true;

Su Nginx, potresti usare questo,

location ~* ^/(index.php/)?admin{
  satisfy any;

  allow x.x.x.x;

  auth_basic "Login";
  auth_basic_user_file /microcloud/data/domains/x/domains/x/___general/.htpasswd;

  deny all;

  location ~* \.(php) {
    include fastcgi_params;
  }
  try_files $uri $uri/ /admin/index.php ;
}

C'è un po 'più di documentazione su come preparare un .htpasswdfile qui

Avvolgere il cron.shprocesso

Ho incontrato altri provider di hosting che utilizzano macchine dedicate per l'utilizzo di cron / admin, il che significa che la modifica del cron.shfile consentirebbe l'esecuzione di codice in remoto su cron / admin senza la necessità di accedervi. Concludere il processo con l'utente giusto in una fakechroot può andare oltre per bloccare il processo.

C'è troppo codice per me per spedire, ma c'è uno script qui . È specifico per MageStack, ma potrebbe essere adattato per l'uso su configurazioni server meno eleganti :)

Audit, audit, audit

Linux è fantastico in termini di accesso e sfruttamento che ti darà una visione completa di ciò che il tuo server sta facendo.

Una fantastica funzionalità di MageStack è lo strumento di controllo che registra tutti i tipi di accesso e persino le modifiche ai file su base giornaliera. Puoi trovare i registri qui,

/microcloud/logs_ro
|-dh[0-9]+
|---access-YYYY-MM-DD.log.gz
|---backup-YYYY-MM-DD.log.gz
|---magescan-YYYY-MM-DD.log.gz
|---php-differential-YYYY-MM-DD.log.gz
|-acc[0-9]+
|---access-YYYY-MM-DD.log.gz

Se non stai usando MageStack, puoi replicare un po 'di questo con il tuo provider di hosting abbastanza facilmente, rsyncessendo lo strumento più semplice per farlo.

Per esempio. Se i backup sono disponibili localmente, è possibile effettuare le seguenti operazioni. Ciò eseguirà il confronto a secco tra due directory e produrrà un elenco di patch diff.

rsync -na /path/to/public_html/ /path/to/backup/public_html/ > change.log
grep -E '\.php$' change.log | while read FILE; do
  diff -wp /path/to/public_html/$FILE /path/to/backup/public_html/$FILE >> php-differential.log
done

Le modifiche a PHP sono così rare che è possibile programmare l'esecuzione quotidiana (o più volte al giorno) e avvisare via e-mail in caso di modifica del file PHP.


In sintesi

  • Utilizza il controllo versione, è più facile tenere traccia delle modifiche
  • Il solo possesso di un certificato SSL non è sufficiente per rendere sicuro il tuo sito
  • Non aspettare di essere violato per considerare la sicurezza
  • Solo perché reindirizzi al tuo provider di gateway di pagamento (anziché acquisire informazioni) - ciò non significa che puoi evitare la conformità PCI, devi comunque conformarti
  • Sii proattivo, sicuro e accurato: controlla il codice del modulo prima di installarlo, controlla i file PHP quotidianamente, controlla i registri, controlla l'accesso FTP / SSH, cambia le password regolarmente

I tuoi clienti si fidano enormemente di te quando passano sopra tutte le loro informazioni private - e se tradisci quella fiducia non gestendo un'azienda sicura, perderai le loro abitudini e tutte le abitudini future.

Le indagini forensi PCI sono incredibilmente costose, richiedono molto tempo e alla fine rischiano la tua capacità di poter riprendere i pagamenti con carta. Non lasciarti mai mettere in quella posizione!


Ottieni patch

Ci sono state recentemente una serie di patch rilasciate da Magento che risolvevano buchi, inclusi alcuni che consentivano l'esecuzione di codice in modalità remota. Puoi scaricarli qui, https://www.magentocommerce.com/products/downloads/magento/

Ma questi nuovi articoli non si riferiscono a un nuovo exploit, stanno semplicemente affermando come gli hacker stanno sfruttando exploit storici (o qualsiasi altro vettore di attacco) per essere in grado di acquisire informazioni sui titolari di carta.


fonti


4
Grazie! Questo è un fantastico writeup e molte informazioni molto utili.
Piotr Kaminski,

9

Sto aggiungendo un'altra risposta solo perché il mio altro non ha effettivamente risposto alla domanda - e certamente non deve essere più!

Come posso verificare se un'immagine contiene informazioni CC

Alla fine, non puoi. A volte ci sono indicatori che lo fanno risaltare,

Per esempio.

  • File di grandi dimensioni
  • Presenza di testo semplice nel file
  • Intestazioni dell'immagine errate

Ma può essere particolarmente difficile digerire il contenuto dei file binari per determinare il contenuto se il contenuto non è semplicemente in testo semplice.

L'exploit più comune che ho visto non comporta la scrittura di dati di testo normale in un file con .jpg|png|gif|etcestensione, di solito comporta un qualche tipo di codifica / crittografia per offuscare i dati (ad es. base64O mcryptecc.). Ciò significa che un grep semplice non funzionerà.

Potresti (e questo non è affatto esaustivo) ...

Trova file di dimensioni eccessive

find \
/path/to/public_html/skin \
/path/to/public_html/media \
-type f -size +20M 2>/dev/null

Trova i file corrispondenti a CC regex

grep -lE '([0-9]+\-){3}[0-9]{4}|[0-9]{16}' \
/path/to/public_html/skin \
/path/to/public_html/media 2>/dev/null

Controlla se i file di immagine sono validi

find \
/path/to/public_html/skin \
/path/to/public_html/media -type f \
-regextype posix-egrep -regex '.*\.(jpg|gif|png|jpeg)' |\
xargs identify 1>/dev/null

O

find \
/path/to/public_html/skin \
 -name '*' -exec file {} \; | grep -v -o -P '^.+: \w+ image'

Come posso controllare i file PHP nella mia installazione per vedere se è stato modificato

Il modo più semplice per confrontare i file di installazione sarebbe quello di diff il core rispetto a una copia pulita. Questo non tiene conto dei file dei temi, ma è molto utile per controllare alcune migliaia di file durante l'installazione.

Il processo è davvero semplice,

Per esempio. Per Magento versione 1.7.0.2

wget sys.sonassi.com/mage-install.sh -O mage-install.sh
bash mage-install.sh -d -r 1.7.0.2
tar xvfz latest-magento.tar.gz
diff -w --brief -r magento-ce-*/app/code/core app/code/core
diff -w --brief -r magento-ce-*/lib lib

Tieni presente che le versioni precedenti di Magento non sono (fastidiosamente) corrette, quindi fare una differenza di base comporterà la visualizzazione delle modifiche. Per evitare ciò, applicare le patch alla fonte pulita appena scaricata, quindi diff di nuovo dopo.


2
Date entrambe le vostre risposte, questa sembra correlare meglio alla domanda.
pspahn,

Ben, ho premuto Invio prima di poter completare la mia giustificazione per la modifica che ho suggerito ... non una cosa importante, solo che PCI è uno standard del settore e non un regolamento o una legge approvata da un ente governativo, almeno non negli Stati Uniti: en.wikipedia.org/wiki/…
Bryan 'BJ' Hoffpauir Jr.

1
Stavo solo usando "regolamentazione" nel contesto di essere intercambiabile con "regola" (non legge)
Ben Lessani - Sonassi

Apprezzo la distinzione e potrebbe essere più basata sulla localizzazione di quanto pensassi inizialmente. Secondo mio padre l'avvocato e mia sorella il preside della facoltà di legge (odio litigare con loro come si potrebbe immaginare) qui negli Stati Uniti anche la parola regola ha un significato specifico quando è preceduta da un modificatore specifico, come Industry Rule come in questo case vs Agency Rule (dove un'agenzia governativa come l'EPA può emettere requisiti dettagliati che sono legalmente vincolanti come una legge ma non approvati come regolamento dal nostro Senato o Camera dei deputati). Non voglio essere pedante, solo condividere :)
Bryan 'BJ' Hoffpauir Jr.

3

Ottimo post, ma purtroppo non tutte le cose sono uguali.

Autorizzazioni per i file

Quando l'hosting condiviso è diventato popolare, è stato ritenuto più importante che alle persone non fosse consentito visualizzare il contenuto di altri sullo stesso server. Fino all'avvento delle carceri di FreeBSD, ciò significava:

  • conchiglie ristrette
  • / home come root: root 700
  • Account utente con umask 007.
  • UID che cambia il software server web
  • E l'UID in cui è cambiato, è il proprietario di quell'account.

Ciò ha consentito la modifica dei (allora) file HTML da parte del proprietario dell'account, mentre allo stesso tempo sia il processo del server web che il proprietario dell'account non avevano accesso ad altri sullo stesso computer.

Ciò non è cambiato molto e i pacchetti software personalizzati per l'hosting condiviso (CPanel, DirectAdmin, Plex) utilizzano tutti questi principi. Ciò significa che il punto di ingresso principale (server web e / o interprete di script) può scrivere su qualsiasi file nell'account, rendendo inutili le autorizzazioni per i file.

Nessun CC da rubare se non lo hai

Informare il proprio fornitore di servizi di pagamento CC se i dati CC vengono effettivamente inviati al server e, in tal caso, se vengono inviati non crittografati non crittografati. JavaScript è piuttosto potente in questi giorni e ci sono fornitori di servizi di pagamento là fuori, che utilizzano il motore JavScript del cliente per crittografare le informazioni sensibili prima della trasmissione al server. Mentre può essere possibile per questo raccoglitore di informazioni ottenere la chiave di sessione e i dati crittografati (e quindi essere in grado di decrittografarli), è meno interessante per il raccoglitore in quanto i dati raccolti sono più grandi e l'IA del bot molto più complessa .

Rilevazione delle modifiche

Oltre 15 anni di unix e mi fa ancora sorridere in modo nostalgico quando vedo le reincarnazioni di TripWire . Provalo anche per questo. Confrontando con una buona versione nota, un po 'meno, in quanto non tiene conto delle aggiunte e fornisce nuovamente un buon strumento qui, poiché le modifiche al sito locale sono più frequenti delle installazioni incontaminate.

The Downloader

Spostare il downloeader all'esterno della radice del documento è altrettanto semplice quanto installare una forma di autenticazione HTTP. Quindi rimetterlo solo quando lo si utilizza. Se ciò non è pratico, preferisco bloccarlo in base all'indirizzo remoto piuttosto che a un altro livello utente / password, in particolare quelli che inviano le password in testo semplice.

WAF e alternative

Un Web Application Firewall può prevenire molti problemi, già nella fase di scansione di un attacco. Sfortunatamente, si tratta di scatole nere costose, ma esistono alcune alternative:

  1. Quello che era il compagno di Tripwire in quel momento - Snort - è proprio lì con i WAF commerciali. Ha una ripida curva di apprendimento, ma è in grado di rilevare abbastanza bene le anomalie e i noti schemi negativi.
  2. Naxsi per nginx e mod_security per Apache negano le richieste che contengono firme di attacco note. Naxsi è un po 'più generico e nega il servizio per "cose ​​che non dovrebbero appartenere qui", come l'oscuro SQL - in contrasto con parte di un noto bit di SQL.
  3. Fail2ban / sshguard si trova tra i due precedenti. Possono gestire diversi tipi di log e avere azioni personalizzabili. L'aspetto negativo è che funzionano dopo il fatto. Le linee logiche in genere colpiscono il registro dopo che un'azione è stata completata e per di più gli strumenti hanno una soglia per combattere i falsi positivi. Questo può essere sufficiente per consentire all'attaccante di ottenere l'accesso, se ha ottenuto informazioni accurate nelle fasi precedenti.

Penso che abbiamo coperto un sacco di cose, ma lasciami finire con il mio petpeeve:


Smettere di usare FTP


Là. L'ho detto. Ed eccoti qui: https://wiki.filezilla-project.org/Howto


1

Non c'è nulla di certo su questo nuovo hack, Ben Marks ha pubblicato ieri che stanno indagando sul problema e c'è anche questo articolo.

L'approccio migliore che puoi provare è accedere tramite SSH ed eseguire una ricerca all'interno di tutti i file che hai per una determinata stringa, qualcosa come

find . | xargs grep 'db-tab-bottom-right-bg_bg.gif' -sl

dalla cartella principale di Magento e se ottieni una corrispondenza, controlla manualmente il file per vedere cosa sta succedendo. Lo stesso con altre stringhe come "END PUBLIC KEY" per esempio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.