德国电子政府通信系统组件存在多个严重漏洞可导致政府交换数据泄露

G20峰会前夕，德国大力加强网络安保并设立了全天候指挥中心，而最近，SEC-Consult安全研究者发现，德国电子政府系统通讯库中的在线服务计算机接口OSCI (Online Services Computer Interface)存在多个严重漏洞，可导致政府交换数据被攻击泄露。以下是SEC-Consult的相关研究：

简要说明

OSCI接口用于德国各个公共政府机构之间的数据交换，其OSCI数据传输协议是德国电子政务信息系统的基础和强制性通信协议。现在，OSCI协议已广泛应用于德国各领域政务系统中，如人口登记、公共卫生和司法管理等。OSCI协议的设计应用基于在不受信网络中提供保密性、完整性、真实性和不可否认性的安全考虑，为电子政务打造一个安全、加密和合法的数据交换传输渠道。

该协议的一个常用实现就是“OSCI-Transport” Java库，它最早于2004年被开发，并由协议开发者进行维护。在我们最近的漏洞公告中，我们描述了如何对OSCI库进行了一些有效的攻击研究。经证明，攻击者可以利用OSCI库进行XXE注入攻击，并能获取到OSCI应用系统的相关内部文件数据信息。基于此，攻击者一旦获得了对通信信道访问控制权后，在某些特定条件下，还能对部分传输数据进行消息解密和伪造等严重操作。目前，我们还未针对OSCI作出一个完整的安全评估，但不能排除还存在其它漏洞的可能。

OSCI协议技术简要

为了更好地了解漏洞情况，在此对OSCI协议作一点简单的技术介绍。

OSCI协议(1.2版本)是基于XML的内容无关协议，其通信机制通常由一个中间件来操作控制。在通信开始时，发送者必须向这个中间件发送一个请求消息。在该消息到达接收方之前，存在以下两种应用场景：

中间件主动向OSCI服务器发送该消息(被动接收)

OSCI服务器连接到中间件进行消息获取(主动接收)

为了保护传输信息，OSCI协议定义了以下几种可选的安全机制：

有效负载(即消息实际内容)使用作者或发送者的私钥进行签名(即内容签名)，这确保了接收方可以验证消息的真实性

有效载荷使用最终接收者的公钥进行加密(即内容加密)，确保信息只能由实际接收方读取，而不能由中间件或其它第三方读取

使用发送方私钥签名的OSCI消息允许中间件或接收方对发送方进行身份验证，并确认传输消息和元数据没有被篡改

利用公钥加密的OSCI消息确保通信只能在发送方、中间件和接收方之间进行，不可由第三方攻击者读取掌握

测试设置

我们针对OSCI 1.6.1版本的Java库进行了安全测试，该库源代码可以点此下载。但该库中并不包含我们创建完整测试所需的完全代码(也不包括中间件代码)，我们因此采用编写虚拟代码的方式来对缺失组件进行模拟。最终，我们对库中一个经过轻微修改的被动接收者实例(de.osci.osci12.samples.PassiveRecipient)进行了攻击测试。

我们没有对完整的OSCI实际生产系统或应用程序进行测试，只是进行了一种简单的模拟性安全检查，因此，我们不能排除存在其它漏洞或攻击路径的可能。

所发现漏洞

从攻击者角度看，主要存在两种攻击方法：

对通信伙伴的攻击：攻击者尝试向通信伙伴发送可控制操作的OSCI消息，以便入侵对方

对通信的攻击：攻击者尝试对加密和签名OSCI消息进行解密攻击，以获得对这些消息的访问控制

SEC-Consult在OSCI协议库1.6.1版本发现了多个漏洞，并成功对至少一种通信场景进行了漏洞测试。鉴于这些漏洞将严重影响德国关键电子政务系统，所以我们在此就不公布具体漏洞利用代码，只对这些漏洞作出介绍。

对OSCI服务器的攻击

XXE漏洞–CVE-2017-10668

OSCI消息格式基于XML标准，具备外部实体包含包含功能，开启该功能的解析程序通常存在外部实体注入(XXE)漏洞。而OSCI库却明确启用该功能，因此容易受到此类漏洞攻击。这种攻击除了造成拒绝服务影响外，还可能让攻击者获取系统文件。然而，这种攻击与其它XXE攻击一样存在限制：如果文件包含特定字符(如&或不可打印字符)，攻击者将无法检索它们。

除了其他安全性影响(如拒绝服务)，此漏洞可能允许攻击者从系统中读取文件。 然而，与任何XXE漏洞一样有限制：如果文件包含一些XML特定禁止的字符(例如&，不可打印字符)，攻击者将无法检索获取它们。 该攻击正常进行时，攻击者无需获得对原始消息的访问控制，对于被动的OSCI接收方来说，攻击者只需通过网络即可对其形成访问或进一步攻击。

攻击测试时，我们使用了OSCI挑战/应答功能，该功能允许发件人在“ 挑战”元素中指定任意值，而收件人也必须在OSCI响应的Response元素中指定该值。最终，我们成功实施了这种XXE攻击，通过Challenge元素的设置在Response元素中获取到了一些引用数据(如本地文件)。 在被动接收源码中，我们发现攻击者可以向OSCI服务发送一个未加密签名消息，以从OSCI服务系统中读取任意文件。

Java反序列化漏洞

另外，由于OSCI中的XML解析器包含在一个Java反序列化集成工具中，这意味着XXE漏洞会被通过Java反序列化渠道被利用。如果OSCI应用程序存在：

从不可信来源中反序列化数据

存在漏洞的OSCI库恰好在应用程序的classpath路径中

那么攻击者可以通过向OSCI应用程序发送特定的序列化数据，触发Java反序列化漏洞来进行带外XXE攻击。

对OSCI消息进行攻击

我们通过建模，在通信信道被认为是不安全的前提下，假设了一种攻击者能够嗅探加密OSCI消息的场景。下图展示了我们这种攻击情形：

破解序列加密实现padding oracle攻击–CVE-2017-10668

我们首先要解决的是数据传输加密，OSCI支持以下几种加密：

3DES-CBC

AES-128-CBC

AES-192-CBC

AES-256-CBC

可以看出OSCI只支持CBC模式的数据块密码。当这种加密模式使用不当时，可能会发生几种方式的攻击(W3C已建议不再使用这些密码)。对CBC最直接的攻击是padding oracle攻击，成功的攻击利用将允许攻击者破解任何加密消息。

根据OSCI标准和库实现中存在的一种对解密失败的错误代码说明(此情况下表示填充无效)，我们可以实现一种简单的padding oracle攻击。

由于大约需要128个请求字符来解密一个字节，所以理论上，这种攻击被认为不可行，但我们经过优化，创建了一个运行更快的破解脚本：

它支持更多常见字节(如数字、字母或打印字符)。

它基于块结构来预测块内容(如块xmlns:ds =“http / /很可能在/www.w3.org/2000”之后)

在我们的实际测试设置中，可以在半小时内在本地机器上破解OSCI process Delivery消息：

绕过序列签名校验–CVE-2017-10669

OSCI使用XML签名来提供真实性。在过去，一般针对XML签名的攻击是XML签名包装攻击(XSW)。

为此，我们首先研究了XML内容哪些部分被签名，以及验证实际应用程序如何访问签名内容。如果接收方应用程序可能被已验证的XML消息的一部分欺骗，而其余部分也能正常被交换接收，则其存在XSW漏洞。OSCI库使用一个简单的解析器SAXParser，这也意味着很多解析逻辑由库自身来实现完成，虽然这能提供更多的灵活性和便利性，但也容易带来实现错误。

以下显示的是一个经过签名的OSCI序列图示：

soap:Envelope>

soap:Header>

osci:ControlBlock>...osci:ControlBlock>

osci:ClientSignature>

ds:Signature>

ds:Reference URI="#body">...ds:Reference>

ds:Signature>

osci:ClientSignature>

osci:DesiredLanguages />

osci:processDelivery />

osci:IntermediaryCertificates>...osci:IntermediaryCertificates>

osci:NonIntermediaryCertificates>...osci:NonIntermediaryCertificates>

osci:Header>

soap:Body Id="body">(original content here)soap:Body>

soap:envelope>

其消息头包含一个XML签名，即ds:Signature元素。ds:Reference元素的URI属性描述XML文档的哪些部分被签名。在该例中，它指在soap:Body内容中具有id“body”的元素。 为了实现SOAP内容体的伪造，我们需要使用两个SOAP内容体来创建一个请求，并要确保解析器会检查原始SOAP体签名，而实际上，原始SOAP体内容代码已被我们替换为另外一个被控制SOAP体。

该库说明OSCI程序存在以下一些不当的配置bug，我们能够利用这个bug来实施XML签名包装攻击(XSW)：

所有在SOAP标头之下除ClientSignature元素之外的全部元素都必须经过签名

SOAP Body自身也必须经过签名

该库应该检查文档最后Body Id的唯一性，但存在一个使此检查无效的bug。在实际应用中，这意味着最后一个元素给定的ID用于签名验证

为了作进一步处理，SOAP Body通常位于SOAP Envelope元素下方。 对于签名验证来说，SOAP Body主体可以在文档中的任何位置

漏洞影响

以上存在漏洞会对OSCI系统和用户产生严重安全影响，首先，OSCI本身安全机制存在安全缺陷漏洞，这些漏洞可导致攻击者实现对传输数据的拦截、篡改、破解和获取。另外，鉴于签名和加密机制是用户可选设置，一旦这些设置被用户处于真空状态，通信双方传输数据也将毫无安全保密可言。

OSCI是德联邦强制性政务系统标准，被广泛应用于各政务行业信息系统中。根据德国IT标准协调办公室(KoSIT)网站资料，我们初步确认这些漏洞将对多家政府机构信息系统造成影响。如：

公共卫生系统

国民状况登记系统

一些政府文件管理系统

人口登记系统

司法电子政务数据交换系统(现已升级到OSCI 2.0版本)

相关方反应

KoSIT根据我们提供的漏洞，已于2017年3月13日发布了新的OSCI库补丁;

KoSIT发布了包含有更安全加密算法的OSCI更新版本;

SEC Consult已联合德国信息安全相关机构对漏洞进行及时修补，并建议OSCI使用方确定漏洞并尽快更新软件。

来源：sec-consult，freebuf小编clouds编译