☰

如果我为 WSL 设置了一个弱密码，这有关系吗？

tag-icon • tag-icon security virtualization windows-subsystem-for-linux wsl2
如果我为 WSL 设置了一个弱密码，这有关系吗？

我有一台 Windows 操作系统，其中设置了 Windows Hello PIN 码用于登录。我还安装了带有 Ubuntu 20.04 LTS 的 WSL2。

我没有在 WSL 下运行 SSH 服务器。但是，Windows（WSL 也是如此）始终连接到互联网。

因此，如果 WSL 中没有运行 SSH，我为 WSL 实例设置一个弱登录密码是否重要？它会以任何方式损害我的安全吗？此外，WSL 密码的强度何时重要？

答案1

简短回答： （更新）在最近的 WSL 版本中，可以启用新的网络模式（但不是默认模式），这会增加从外部网络访问的风险。一般来说，存在中等暴露风险，但如果发生这种情况，结果可能是灾难性的。设置一个强密码。

更多详情：

只要你没有在 WSL 实例中运行任何暴露给外界的服务（例如sshd），那么就不会有太多机会有人使用弱密码访问你的 WSL 系统。

此外，即使您在 WSL2 中运行 SSH，它也运行在位于 Windows 网络后面的 NAT 虚拟 NIC 中。与 WSL1 不同，从网络直接访问 WSL2 中的服务并不容易。Windows 主机本身从 WSL2 的一项名为“本地主机转发”的功能中获得了一些额外的“魔力”，但这并不适用于网络上的其他计算机。

从 WSL 的角度来看本身，用户密码实际上几乎没有什么“保护作用”。例如

wsl ~ # Launches your default WSL instance with the default user, but no password
wsl ~ -u root # Launches into the default WSL instance as root, with no password needed

并且无论 WSL 用户（root 或其他）的权限如何，它们仍然仅限于你的视窗用户可以执行的操作。虽然 WSLroot没有获得 Windows“管理员”权限，但如果攻击者能够访问您的 Windows 帐户，他们仍然可以造成很大的损害。

无论如何，设置更强密码的原因有多种：

  1. 如果即使有人获得访问权限，后果仍然可能是灾难性的（请参阅下一部分）。

  2. 几乎没有坏处设置强密码。您不必输入密码即可登录。您可以输入密码sudo，但sudo如果您愿意，您可以为用户禁用密码。同样，它（实际上）在本地具有与wsl -u root无论如何相同的效果。不过，不一定受到推崇的，因为root用户可能会安装恶意软件之内WSL 实例（见下文）。

  3. 正如 LPChip 在评论中提到的那样，认为由于您关闭了所有外部服务所以您是安全的，这种想法是错误的，因为在遥远的将来，您可能会重新启用其中某项服务而无需重新考虑后果。

  4. 你甚至可能会做一些你思考是“安全的”，但在暴露外部服务时会产生意想不到的后果。例如，WSL 不支持 Systemd，但许多人试图通过一些“黑客”来使用 Systemd。这里的“黑客”一词没有任何评判性——我自己也做过；这只是一个使用很多（有意和无意的）副作用。

    例如，Systemd 默认启用的服务之一是 ssh。因此，即使您可能没有故意将 ssh（使用弱密码）暴露给外界，运行任何一个 Systemd 启用脚本都可能会在您不知情的情况下将其打开。

  5. 同样，未来的 Windows/WSL 版本也有可能改变其工作方式。例如，WSL 目前不支持 Systemd。但如果有一天，WSL 开始以某种方式支持 Systemd，那么它可能会产生与上述相同的效果。同样，如上所述，WSL2 无法轻松地从网络访问其中运行的服务，但微软将来也随时可以改变/改进这一点。

总的来说，众所周知，“安全”是一系列相关的（但有时是未知的）服务/事件/实践/等等。最好是冗余的，即使我们思考威胁较低，无论如何都要实施最佳做法（例如强密码）。

如果有人以您的用户身份登录 WSL 会有什么后果？

简而言之，如果不采取额外措施禁用 WSL 功能，如果有人做过获取 WSL 实例的远程访问权限：

  • 一般来说，一旦理论上的攻击者以您的用户身份访问您的 WSL 实例，他们就可以访问几乎任何以您的 Windows 用户权限运行的东西。

  • 他们会无限WSL 实例本身内的权限，因为它们可以运行wsl.exe -u root以启动具有完全 root 权限的新（嵌套）WSL 实例。

  • 虽然该根用户没有 Windows 管理员访问权限，但它可以将恶意软件/键盘记录器等安装到 WSL 实例中，从而允许其捕获在实例中输入的密码（及更多内容）。

  • WSL 用户和 root 用户都可以访问任何驱动器上 Windows 帐户可以访问的任何文档和数据，甚至（据我所知）驱动器级加密数据（例如 Bitlocker），因为这些数据在你登录时会被解锁视窗。

  • 当然，WSL 用户可以运行任何.exe不需要 UAC 提升的 Windows。例如，这包括powershell.exe。

  • 我有点确信攻击者可以访问在 Windows 下打开的 Outlook 中运行的电子邮件（甚至发送）——不是直接通过 Outlook GUI，而是通过脚本/API 访问 Outlook 实例。我相信这可以在没有额外身份验证的情况下完成。

  • 攻击者也极有可能通过 Selenium 等（即 ChromeDriver）编写您的 Web 浏览器脚本。这将包括能够访问您当前通过活动会话登录的网站上的任何信息。

请注意，理论上，可以通过关闭自动挂载（通过/etc/wsl.conf) of Windows drives, as thewsl.exe command (that lives on theC:` 驱动器）来缓解大部分（但不是全部）问题，然后 WSL 本身将无法访问。此外，WSL 用户将无法访问 Windows 驱动器上的文档和数据。

此外，您还可以使用它来禁用在 WSL 内运行 Windows 的/etc/wsl.conf功能。.exe

当然，这些特点是最大的两个优点WSL，因此禁用它们会对功能造成重大打击。

相关内容