我为 WSL 设置弱密码有影响吗？

Question

我有一个 Windows 操作系统，并设置了用于登录的 Windows Hello PIN。我还使用 Ubuntu 20.04 LTS 安装了 WSL2。

我不在 WSL 下运行 SSH 服务器。但是，Windows（以及 WSL）始终连接到互联网。

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

Answer 1

简短的回答： 暴露风险相当低，但如果发生的话将是灾难性的。无论如何，请设置一个强密码。

更多详情：

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

此外，即使您在 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 或其他）的权限如何，它们仍然仅限于您的Windows用户可以执行的操作。虽然 WSLroot无法获得 Windows“管理员”权限，但如果攻击者有权访问您的 Windows 帐户，他们仍然可能造成很多损害。

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

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

2. 设置强密码实际上没有任何缺点。您无需输入即可登录。您可以键入，但如果您愿意，sudo也可以禁用用户的密码。sudo同样，它（实际上）在本地具有与无论如何相同的效果wsl -u root。不过，不一定推荐，因为root用户可以在WSL 实例中安装恶意软件（见下文）。

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

4. 甚至有可能您可能会做一些您认为“安全”的事情，从而在暴露外部服务时产生意想不到的后果。例如，WSL 不支持 Systemd，但许多人尝试通过一些“hacks”来使用 Systemd。这里的“黑客”这个词没有任何判断力——我自己就这么做过；这只是一个很好的例子，说明有很多（有意的和无意的）副作用。

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

5. 同样，未来的 Windows/WSL 版本始终有可能改变事物的工作方式。例如，WSL 目前不支持 Systemd。但如果有一天，WSL 开始支持 Systemd（以某种方式），那么它可能会产生与上述相同的效果。同样，如前所述，WSL2 并不能让从网络访问其中运行的服务变得容易，但 Microsoft 将来也可以随时更改/改进这一点。

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

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

简而言之，如果不采取额外措施禁用 WSL 功能，如果有人远程访问您的 WSL 实例，那将是灾难性的：

• 一般来说，一旦理论上的攻击者能够以您的用户身份访问您的 WSL 实例，他们就可以访问以您的 Windows 用户权限运行的几乎所有内容。

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

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

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

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

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

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

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

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

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