ID |
Product |
Version |
Vulnerability |
CVE-2019-25023
|
Scytl Secure Vote (sVote)
|
2.1
|
X-Forwarded-For IP-Spoofing/Faking
|
Description
When forward-tracing the applicaton logic one can observe a lot of parameteres implementing the x-forwarded-for headers:
@NotNull @Header(PARAMETER_X_FORWARDED_FOR) String xForwardedFor,
---------------------
@NotNull @Header(PARAMETER_X_FORWARDED_FOR) String xForwardedFor,
This is passed to the following two function:
evoting-solution-master/source-code/online-voting-channel/ov-api-gateway/ag-wsrest/src/main/java/com/scytl/products/ov/ag/ui/ws/rs/proxy/XForwardedForFactoryImpl.java
@Override
public String newXForwardedFor(final HttpServletRequest request) {
String remoteAddresses = request.getHeader(HEADER);
if (remoteAddresses == null) {
remoteAddresses = request.getRemoteAddr();
}
String localAddress = request.getLocalAddr();
return remoteAddresses + ',' + localAddress;
}
As well as this one:
evoting-solution-master/source-code/online-voting-channel/ov-commons/ov-commonslib/src/main/java/com/scytl/products/ov/commons/util/HttpRequestService.java
public String getIpClientAddress(final HttpServletRequest request) {
String address = request.getRemoteAddr();
String xForwardedFor = request.getHeader(HTTP_HEADER_X_FORWARDED_FOR);
if (xForwardedFor != null && !xForwardedFor.isEmpty()) {
int index = xForwardedFor.indexOf(',');
if (index > 0) {
address = xForwardedFor.substring(0, index);
} else {
address = xForwardedFor;
}
}
return address;
}
For both the HttpServletRequest is used directly which includes the client-side "x-forwarded-for" header.
It can be manipulated by a client via, for example, an intercept proxy.
The application uses getIpClientAddress() like this:
// transaction id generation
transactionInfoProvider.generate(tenantId,
httpRequestService.getIpClientAddress(httpRequestService.getIpServer(request));
As well as the creation of the xForwardedFor variable like this:
String xForwardedFor = xForwardedForFactory.newXForwardedFor(request);
This newXForwardedFor variable is used all over the place and, for example, written to the internal SPLUNK logs of the application.
An attacker is able to disguise themselves in the logs by manipulating the x-forwarded-for header to a desired ip-address.
Timeline
Date |
Event |
February 10 2020
|
Submitted vulnerability to vendor
|
February 25 2020
|
Vendor moved communication to live PIT platform
|
February 25 2020
|
Submitted additional details/PoC in live PIT
|
March 05 2020
|
Vendor acknowledged the vulnerability
|
Credits
Name |
Team |
Anthony Schneiter
|
SUID
|
Jannis Kirschner
|
SUID
|