Article

SAP Penetration Test – Abuso delle transazioni

27-03-2014

Dati i rischi sempre maggiori derivanti dai Cyber-attacks e dalle frodi informatiche, da diversi anni una delle attività più frequentemente richiesta dai Clienti Quantum Leap riguarda i SAP Penetration Test. L’ecosistema SAP è costituito da un insieme di software progettati per aiutare l’azienda a governare e gestire i processi aziendali, da quelli più semplici a quelli che coinvolgono flussi di denaro, per questo motivo, l’impatto derivante da un attacco su questi sistemi, in genere ha forti ripercussioni sia dal punto di vista del business che dal punto di vista economico. Sono noti vari problemi di sicurezza relativi ai prodotti SAP e alle relative interfacce di amministrazione(1,2,3,4), tuttavia sono meno noti i problemi di sicurezza che derivano dall’abuso delle funzionalità offerte da un sistema SAP accessibile da un agente di minaccia.

Nel post viene descritta una delle tecniche utilizzate durante un SAP Penetration Test per compromettere la sicurezza di un sistema UNIX che ospita SAP, utilizzando le transazioni messe a disposizione da SAP stesso. Sarà mostrato come è possibile ottenere una shell sul sistema UNIX che ospita SAP, mediante l’upload di una chiave pubblica SSH nella home directory dell’utente con cui viene eseguito il processo SAP.

SCENARIO DI ATTACCO

L’articolo SAP Penetration Test  si focalizza sulle fasi seguenti all’identificazione\acquisizione di credenziali d’accesso valide al sistema SAP, dunque lo scenario d’attacco attuabile tramite la tecnica descritta nell’articolo si applica se sussistono le seguenti condizioni e pre-requisiti:

  • Il sistema UNIX offre le funzionalità di login via SSH;
  • Il demone SSH è configurato per consentire l’accesso utilizzando lo schema di autenticazione basato sullo scambio di chiavi pubbliche. Questa modalità è attiva di default su OpenSSH e comunemente non viene disabilitata, anche se per accedere ai sistemi vengono utilizzate solo il nome utente e la password;
  • Il sistema SAP non riesce a comunicare con i sistemi controllati dall’agente di minaccia;
  • Si dispone di un accesso regolare alla sola componente Applicativa (accessibile ad esempio mediante SAP-GUI e WEB GUI) ospitata sul sistema target;
  • L’utenza utlizzata per l’accesso all’applicazione dispone dei privilegi sufficienti necessari all’esecuzione delle transazioni SM69 e XSDA_TOOLS.

 

GENERAZIONE DELLE CHIAVI SSH

La prima operazione da effettuare affinché sia possibile portare a termine l’attacco, è quella di creare una coppia di chiavi SSH. Questa coppia di chiavi, dopo aver abusato delle funzionalità di SAP,  consentirà di accedere al sistema tramite una shell interattiva.

Su Linux è possibile generare la chiave utilizzando il seguente comando:

$ ssh-keygen -t rsa -b 2048 -C “most_cool_pentester” -f sapkey

Questo comando genera 2 file contenenti l’uno la chiave SSH privata (file sapkey) e l’altro la chiave pubblica SSH (file sapkey.pub).

Per generare la coppia di chiavi SSH da Windows è possibile utilizzare il tool PUTTYGEN seguendo le indicazioni riportate all’indirizzo http://katsande.com/using-puttygen-to-generate-ssh-private-public-keys.

OPERAZIONE FILE-UPLOAD

Per quanto possano essere utili e comode, le funzionalità di file-upload, comunemente presenti ed offerte da una moltitudine di applicazioni, spesso possono essere utilizzate in maniera maliziosa durante un SAP Penetration Test, al fine di scrivere un file arbitrario sul sistema target. Il solo fatto che sia possibile effettuare la scrittura di un file sul filesystem da remoto dovrebbe di per se turbare gli amministratori di sistema, ma solitamente le cose più banali sono anche quelle più sottovalutate. Non tutti sanno che SAP offre la funzionalità di file-upload attraverso la transazione denominata XSDA_TOOLS.

Innanzi tutto bisogna verificare, tramite la transazione SM69 (preposta all’esecuzione di comandi CLI sul sistema operativo), se sia già presente un file authorized_keys nella directory “/home/vittima/.ssh/”.  Nel caso fosse già presente bisognerà effettuare l’upload della chiave pubblica avendo cura di non cancellare eventuali altre chiavi presenti all’interno del file. Di seguito viene mostrata l’invocazione della transazione SM69. Bisogna creare un nuovo comando utilizzando l’apposita funzione “Creare”.

SAP Penetration Test – SM69

Una volta invocata la creazione del comando all’interno della transazione SM69 sarà mostrata la seguente schermata dove è possibile visualizzare tutte le impostazioni specifiche per il comando. Nella figura è mostrato l’esempio di creazione del comando ZTEST che invocherà il comando di sistema “ls”, corredato dai relativi parametri.

SAP Penetration Test – SM69

Qualora non fosse presente la directory /home/vittima/.ssh/, occorre creare la directory sempre utilizzando la transazione SM69. Dopo aver creato la directory è  possibile copiare il file contenente la chiave pubblica (file sapkey.pub) all’interno della directory /home/vittima/.ssh. È possibile eseguire questa operazione utilizzando la transazione XSDA_TOOLS, designata per l’upload dei file sul sistema operativo. Ecco come procedere. La transazione XSDA_TOOLS deve essere invocata compilando i campi della form così come segue:

– Tipo oggetto: DXPROJECT
– Tipo progr.: BAPI
– Program: CREATE
– Selezionare il tasto COPIARE (Ctrl+F5)

Apparirà la schermata nella quale saranno presenti 3 sezioni “Sorgente”, “Destinazione” e “Copiare senza/con conversione”. Nella sezione Sorgente selezionare “Presentation server” e ricercare il file sapkey.pub residente sul nostro client. Nella sezione Destinazione valorizzare il paramentro “Tipo file” con la selezione “P Nome fisico del file”. Sempre nella sezione Destinazione va indicato il percorso dove sarà scritto il nostro file, valorizziamo quindi il campo “Nome file” con il percorso assoluto “/home/vittima/.ssh/autorized_keys”. A questo punto possiano effettuare l’upload del file eseguendo l’operazione, che copiera’ il contenuto del file sapkey.pub all’interno del file /home/vittima/.ssh/autorized_keys

SCENARIO DI ATTACCO

Continuando la sessione di X-Windows Penetration Test, passiamo ora attivamente alla descrizione della fase di attacco e compromissione del sistema. Per fare ciò sono necessarie prima di tutto alcune considerazioni, che determineranno la scelta della corretta modalità operativa. In prima istanza bisogna considerare la visibilità tra l’host da cui ha origine d’attacco ed il sistema attaccato: se l’host da cui ha origine l’attacco è raggiungibile dall’host vittima dell’attacco, è possibile inviare dei comandi per ottenere un accesso interattivo (bindshell\reverseshell). In secondo luogo va considerato se il server X-Windows attaccato è utilizzato da qualcuno nel corso del X-Windows Penetration Test:  va ricordato che tutto ciò che eseguiremo sulla console remota sarà visibile e modificabile da un eventuale utente collegato ed operativo localmente, contrariamente, sul sistema da cui hanno origine gli attacchi non avremo visibilità di ciò che realmente viene eseguito sul server X. A tal proposito è consigliato eseguire periodicamente degli screen-shot con il comando xwd, così come abbiamo visto in precedenza, al fine verificare il corretto andamento delle operazioni. Un ulteriore considerazione da effettuare nel corso di un X-Windows Penetration Test riguarda gli altri servizi esposti dall’host attaccato: se l’host attaccato espone il servizio SSH, si può inserire una chiave SSH pubblica all’interno del file authorized_keys dell’utente, possibilmente con privilegi amministrativi, per compromettere il sistema ed ottenere un accesso remoto. Un ultima considerazione può essere effettuata sui tools disponibili all’interno del sistema attaccato: nel caso si voglia procedere nello scenario d’attacco con l’accesso remoto tramite reverse shell, è necessario che l’host vittima dell’attacco disponga, ad esempio, del comando netcat “nc”.

SAP Penetration Test – XSDA_TOOLS

Al termine dell’upload, affinchè sia possibile accedere alla macchina è necessario modificare i permessi di lettura e scrittura del file e della directory in maniera da consentire il login tramite SSH. I permessi devono essere quindi impostati come segue:

$ chmod 700 /home/vittima/.ssh
$ chmod 600 /home/vittima/.ssh/authorized_keys
$ chown vittima authorized_keys
$ chgrp vittima authorized_keys

Come avrete intuito questa operazione sarà nuovamente eseguita tramite la transazione SM69. Per concludere è possibile verificare la corretta impostazione dei permessi e l’effettiva presenza della chiave pubblica SSH.

SAP Penetration Test – SM69

Accesso al sistema

Dopo aver effettuato le operazioni sopra illustrate è possibile accedere ai sistemi oggetto del SAP Penetration Test nel seguente modo:

$ ssh -i sapkey vittima@10.10.10.23
Last login: Fri Nov 9 12:11:11 2012 from 10.5.5.1

TARGET:vittima 52> uname -a
Linux TARGET 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8 21:37:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
TARGET:vittima 53> id
uid=3201(vittima) gid=200(sapsys) groups=200(sapsys),502(sapinst)

DEMO

Autori

ASapGuy e Agostino Parentela

L'hai trovato interessante?