我正在使用一个软件来处理用户计算机上Windows客户端二进制文件中的所有权限。该软件使用sa帐户连接到后端数据库。sa密码存储在客户端的配置文件中,但客户端显然必须在与数据库进行身份验证之前对其进行解密。
我已经能够以各种方式恢复sa密码,包括使用调试器、搜索内存转储和直接使用WinHex搜索内存。我很好奇是否有一些工具或恶意软件会使这个漏洞更容易被利用。在客户端进程活动的整个时间,密码作为MSSQL连接字符串存储在内存中。
是否有已知的恶意软件可以搜索内存以利用这种漏洞?是否有用户可以自动下载的工具,或者是否需要相当数量的技术知识才能利用这些工具?
发布于 2015-11-30 21:49:48
攻击者常用内存嗅探恶意软件从POS系统中刮取帐号。大多数RAM刮板是由可配置的regexp驱动的,攻击者在其中搜索另一个进程的内存以获取帐户号的模式。
攻击者完全可以配置正在搜索的模式。没有什么能阻止这样的软件被重新配置,以搜索另一个应用程序的内存,寻找诸如"Provider=“、"UID=”、"PWD=“之类的字符串,或者数据库配置字符串中可能存在的其他数据。
是否有任何攻击者在现实生活中这样做是一个问题,法医调查人员(或攻击者)。
发布于 2015-11-30 20:39:33
您已经演示了使用Server身份验证的缺点之一,而不是Windows身份验证。这就是为什么微软建议使用Windows身份验证,除非您有充分的理由不这样做。这里是对每一个优点和缺点的描述。值得注意的是:
加密的Server身份验证登录密码,必须在连接时通过网络传递。一些自动连接的应用程序将在客户端存储密码。这些是额外的攻击点。
这里是微软的另一篇文章,它讨论了如何为实体框架保护Server连接字符串,但即使不使用EF,也适用相同的规则。此语句重申了建议始终使用Windows身份验证的原因:
请注意,登录信息和密码可能在内存转储中可见。当在连接字符串中提供数据源登录和密码信息时,这些信息将保存在内存中,直到垃圾回收回收资源为止。这使得无法确定密码字符串何时不在内存中。如果应用程序崩溃,内存转储文件可能包含敏感的安全信息,运行应用程序的用户和任何对计算机具有管理权限的用户都可以查看内存转储文件。使用Windows身份验证连接到Microsoft。
至于现有的恶意软件应用程序是否利用了这一点?当然,我们知道它们可以存在,而你自己已经证明了这一点。所有所需的是,应用程序要以足够的权限运行,才能查看存储密码的另一个应用程序的内存。最棘手的部分是,您可能需要知道内存是如何布局的,以便利用这一点。换句话说,您可能需要先知道应用程序是如何工作的,然后再围绕它构建内存嗅探器。也许有一般的关键字你可以搜索,但这需要相当多的运气。就像在海底搜寻丢失的船只,而这些船只可能仍然有一些宝藏;在某种程度上,它的成本/报酬并不值得。
尽管如此,如果您知道某个特定(流行的)应用程序存在此类安全漏洞,您可以尝试设计针对该应用程序的恶意软件,然后针对该应用程序的用户试图说服他们在同一台计算机上安装您的恶意软件。
发布于 2015-12-10 16:22:48
所提供的答案都是有用的,但实际上没有一种工具能让我快速、自动地做到这一点。我自己写了一篇文章,用可配置的设置快速扫描Windows进程的内存。如果这个项目对其他人有用的话,这里有一个关于Github的项目:
https://security.stackexchange.com/questions/106840
复制相似问题