公司数据通常是商业秘密。泄漏它们可能导致声誉受损，财务损失甚至破产。因此，对B2B产品的安全性要求必须很高。创建新产品-Corporate Mail Mail.ru-我们特别注意了其安全性问题。
Corporate Mail Mail.ru是熟悉的B2C邮件Mail.ru的本地版本。相比之下，它包含许多修改以便在新环境（客户电路）中工作。
为了使我们的客户对安全性充满信心，我们决定在将产品推向市场之前，对第三方公司进行审核，并修复所有发现的缺陷。为此，他们求助于信息安全领域最著名的公司之一-数字安全。
审计结果已削减。
uWSGI中的远程代码执行
有许多用于构建Python Web应用程序的框架。通常，Python Web服务器网关接口（WSGI）用于在Web应用程序和Web服务器之间进行通信。另外，使用WSGI可以实现中间件组件。
为了使Python Web应用程序与Web服务器（例如Apache或Nginx）之间的通信标准化，先开发了PEP 0333，然后开发了描述WSGI接口的PEP 3333。我们将不讨论WSGI的工作原理，而是向您介绍一种支持WSGI接口的流行服务器-uWSGI。
uWSGI服务器既可以在正常的Web服务器模式下工作，也可以在“ WSGI模式”下工作，并与另一个Web服务器（例如Nginx）交换数据。同时，Nginx使用同名的二进制协议uwsgi，由于其丰富的功能，对于网络犯罪分子来说很有趣。在分析解决方案的“内部”时，发现了一个uWSGI服务器，该产品的所有内部组件都可以访问该服务器。
问题在于uwsgi协议可以使用所谓的魔术变量，这些魔术变量允许您动态配置uWSGI服务器。在这些变量中，有
UWSGI_FILE一个允许您在变量中指定文件路径的情况下加载新的动态应用程序。事实证明，uWSGI服务器可以以这种方式处理不同的电路，例如section，fd，call，或最有趣的- exec。因此，您可以将变量作为值传递exec://<cmmand>执行任意bash命令。为了分析此问题，编写了一个漏洞利用程序，可在github上找到。
执行命令的查询示例。
仅当攻击者：
- 例如，已经在产品的内部网络上的组件之一已被破坏。这可能使他能够劫持新组件，访问新数据并继续进行攻击。
- 具有SSRF，可以通过TCP发送任意数据（例如使用
gopher://）。在这种情况下，攻击者可以访问产品内部。
值得注意的是，针对其他编程语言或框架的CGI接口的实现也容易受到攻击，例如，来自同一存储库的FastCGI漏洞利用。这并不是说这通常是一个漏洞，而是CGI服务器的功能，因此您需要尽可能地限制对此类服务器的访问。
绕过CSRF保护
随着浏览器中各种安全机制的引入，现代网络上的客户端攻击逐渐消失。这也适用于CSRF：浏览器已经实现了对SameSite cookie的支持，尽管如果配置不正确，仍然可能存在漏洞。此外，许多流行的框架允许开发人员轻松配置CSRF保护，但是一些错误或非严重漏洞可能导致CSRF攻击。在我们产品随附的日历应用程序中发现了此类错误。
该应用程序具有一个API，使您可以对用户的事件和日历执行操作，例如：编辑，查看或删除它们。要引用该对象，需要在URL路径中传递UID参数，该参数负责日历或事件的ID。看起来像这样：
example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?
默认情况下，UID是随机生成的，不会受到用户的影响。但是在该应用程序中，找到了两个用户可以在其中更改UID的位置。
第一种是以ICS格式（日历和事件的特殊格式）导入文件，它们具有由用户在导入时控制的特殊UID字段。在这种情况下，导入事件后，其UID将保持与文件中传输的相同。另外，此参数没有过滤。因此，用户可以创建具有任意UID的事件。
第二个是在编辑时更改UID日历的功能。这可以通过截取编辑日历的请求并简单地更改UID字段来完成。这里也没有过滤。
另一个重要功能：此API实现CSRF保护；为此，在GET参数中传递了一个特殊参数，该参数同时充当API密钥和CSRF令牌的角色。通过JavaScript将其添加到所有API请求。不好的做法是在GET参数中传递CSRF令牌，在这种情况下，令牌可能会通过引用，应用程序日志或浏览器历史记录泄漏。
全部放在一起。攻击者可以控制应用程序中的对象UID，并与其他用户共享对事件和日历的访问。在这种情况下，用户将看到相同的UID，并且当他们开始使用此类对象时，将使用攻击者控制的UID执行请求。使用此方法，攻击者可以制作具有以下UID的对象：
../../../AnyPathTo?anyparam=value&
现在，当用户对对象执行操作时，将生成一个请求：
example.com/api/event/../../../AnyPathTo?anyparam=value&/action
然后，还将向其中添加一个令牌，扮演CSRF令牌的角色：
example.com/api/event/../../../AnyPathTo?anyparam=value&/action&token=abcdef
最后，发出请求，浏览器将序列“
../”归一化，结果将请求发送到
example.com/AnyPathTo?anyparam=value&/action&token=abcdef
现在，攻击者可以迫使用户沿着带有任意参数和正确CSRF令牌的任意路径向应用程序发送请求。仍然需要了解我们可以执行哪些请求方法。
事实证明很简单：编辑时发送PUT，删除时删除，DELETE，查看时GET（使用POST创建，我们不能强迫受害者使用它）。通过使用DELETE，攻击者可以强制用户的浏览器执行从用户删除对象的请求。对于攻击者来说，另外一个好处是，当用户编辑对象时，将随请求正文一起发送PUT请求。编辑日历时，请求正文将包含JSON，其中包含当前日历的所有参数。也就是说，创建“恶意”日历的攻击者控制这些参数。如果攻击者成功地将编辑请求从“恶意”日历重定向到用户的私人日历，则“恶意”日历的所有属性都将应用于受害者用户日历的属性。这可以覆盖对日历的访问，因为它是JSON中指定的日历属性之一。
MITM攻击能力
入侵者渗透到公司的内部网络是一种危险情况，充满严重后果。因此，在产品审核期间，我们的任务之一是发现系统体系结构中的缺陷，这些缺陷可以帮助攻击者上移域或改善外部攻击。
该产品的主要功能之一是与Active Directory集成。它是通过LDAP进行身份验证并从Exchange服务器收集消息而实现的，在此示例中，我们将重点介绍ActiveSync。对于攻击者来说，这是一个非常有趣的目标，因为在连接过程中，用户帐户和密码在产品和Active Directory之间传递。通过获得对连接的访问权限，攻击者将能够劫持帐户，并且将更进一步地威胁域。
在内部解决方案和公司服务器中，TLS的错误使用或根本不存在通常会出现问题，而为服务实现TLS并不困难。这通常是由于以下事实：公司的内部网络被认为更安全，并且公司管理员没有花费时间来创建正确的PKI基础结构并为所有服务器颁发证书。
公司网络内部最常见的攻击是MITM。这种类型的攻击通常允许在公司的Active Directory中进行访问。同时，攻击者并非总是能够攻击公司网络内的服务器到服务器交互;大多数情况下，在渗透测试期间，他或他的模型落入没有Exchange服务器或域控制器的用户网络段中。另外，在我们的情况下，该产品未使用诸如NBNS，LLMNR，mDNS之类的广播名称解析协议，因此对这些协议的欺骗将无法实现MITM。因此，为了使解决方案与其他服务器之间成功实现MITM，攻击者必须能够访问安装了这些组件之一的网络。有时可以实现此目标-路由器或服务器容易受到攻击，最终允许您访问特定的网络。
在我们的案例中，在分析过程中，事实证明与Active Directory的集成容易受到MITM攻击。
当用户输入用户名和密码时，系统将两个LDAP请求发送到域控制器。第一个请求返回一个邮件地址列表，如果该列表中存在用户的登录名，则发送第二个请求，即简单LDAP身份验证。数据以明文形式传输，而不使用SSL / TLS，或者不使用LDAPS（基于SSL的LDAP）。这样，即使在发生被动MITM攻击的情况下，攻击者也可以获取产品中当前已授权的用户帐户。
第二个问题：使用ActiveSync协议连接到Exchange服务器以收集传入消息时，系统未验证服务器TLS证书的真实性。在这种情况下，攻击者可以实施主动MITM攻击，一旦收到连接，便可以提供自签名证书，建立连接并将数据代理到Exchange服务器。则MITM将是不可见的，并且攻击者可以获得以ActiveSync协议传输的用户凭据。
通过利用这些漏洞，攻击者从理论上可以获取用户帐户，然后在Active Directory域的攻击中使用它们。另外，应注意，正确使用TLS是实施解决方案的公司的必要任务。
结果
我们一直面临着黑客攻击，并且在如何应对这些攻击方面积累了丰富的经验。我们认为，我们放入客户范围内的产品应尽可能安全，包括基于独立检查的结果。企业邮件Mail.ru就是这样的产品。
我们面临着一项艰巨的任务：将具有许多微服务的大型代码库传输到客户的基础架构，以便邮件在大多数时间都能独立运行，而不会出现故障和管理员干预。
我们要求审核员最注意更改的授权（Corporate Mail使用客户的AD）和主邮件API-详细分析了这些组件的源代码。结果，发现的缺点主要与更改的网络拓扑和特定于本地解决方案的修改有关。
对于其余组件（日历，用于业务管理接口的Mail.ru），使用了灰箱模型：审计员以普通用户的特权与服务进行交互，但可以与正在运行的应用程序连接到容器，部分拥有API源代码，并可以与开发人员澄清详细信息。
审核对我们非常有用。我们发现某些组件中存在许多缺陷，我们迅速纠正了这些缺陷，以将安全的产品推向市场。同时，我们深信其他大多数组件都具有高度的安全性。我们计划定期进行此类审核-我们希望我们的产品始终处于最安全的国内解决方案之首，这不仅在我们看来，而且在独立审核员看来也是如此。
Corporate Mail的安全性是产品本身的安全性和客户基础结构的结合。也就是说，企业数据安全的责任在于我们，开发人员和客户自己。此外，我们还针对最佳实践制定了建议，以保护基础架构免受缺陷的侵害，并在安装产品时始终向客户提供建议。