标注的博客| 安全研究| 渗透测试| APT

首页

ssh蜜键

作者 olanna 时间 2020-03-16
all

~/.ssh/授权密钥

command="/usr/local/bin/honeykey [email protected]",restrict ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhOeMjLnm/G+HEwAkF5QVeqtu53NjtdUINrUtkjg2xOfycK7vo5fS3Uk46UjaY3JzRnXAsIhAUM4FRSA6TUY+1FqpEI5NXFtFF0jwaPre9P7Elx4d0QOliUaHcixrQhzGwIfhiyyVqQSWZ2i0LR2bB07hClr6buj0UH60bg0VeNIs7ZnardkFXQ53PUa64m15SxJgh0GcM5LFGYT2eCPT+7FYT4h6lUdxYfHHM0TIFY+Cp/d3pHeev8ieC1/xtVSgGYbj0DkI78w/e9wzO1Hc6HLM9WSlxxWaivrjokGtrKSmQfcaJtETExTWY9aLxKy4Nafqc71bVX7URVrB6iakD [email protected]

/usr/local/bin/蜜键

#!/bin/sh logger "Honey key used - ${1}"

蜜罐和金丝雀在过去一年左右的时间里呈上升趋势,至少在我消费的InfoSec媒体中是如此。我有一些Cowrie蜜罐的经验(https://github.com/kulinacs/Cowrie-ATT a CK)将蜜罐活动映射到ATT&CK技术,在现场运行期间,我注意到专用蜜罐有一个相对较大的缺点。

对于专用蜜罐,您必须运行专用蜜罐。

任何查看用户历史记录、SSH已知主机、传出连接等的攻击者都可能在合法用户和蜜罐之间看不到任何活动。有了这个,我想找到低投资的“蜂蜜”机会,可以提醒攻击者在合法基础设施上的活动。

SSH密钥作为用户身份验证的一种加密形式,经常被吹捧为“更安全”的身份验证方式。如果SSH密钥对您来说是新的,那么Arch wiki提供了相当全面的文档。

HoneyKeys背后的思想与Honeywords类似,Honeywords是一个不久前发布的概念,旨在帮助识别试图使用在漏洞中收集的数据来获得对用户帐户的未经授权的访问。在我们的例子中,攻击者试图使用蜜糖密钥进行身份验证,该操作将被记录(或由防御者选择的另一个操作),并发出使用该密钥的警报。

幸运的是,authorized_keys格式允许一个很少使用的options字段,这对本次尝试有很大帮助。

蜂蜜键可以非常容易地实现。defender只需向授权密钥文件中添加一个附加密钥,该文件包含指向所需“报警”和“限制”选项的命令选项。

~/.ssh/授权密钥

command="/usr/local/bin/honeykey [email protected]",restrict ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhOeMjLnm/G+HEwAkF5QVeqtu53NjtdUINrUtkjg2xOfycK7vo5fS3Uk46UjaY3JzRnXAsIhAUM4FRSA6TUY+1FqpEI5NXFtFF0jwaPre9P7Elx4d0QOliUaHcixrQhzGwIfhiyyVqQSWZ2i0LR2bB07hClr6buj0UH60bg0VeNIs7ZnardkFXQ53PUa64m15SxJgh0GcM5LFGYT2eCPT+7FYT4h6lUdxYfHHM0TIFY+Cp/d3pHeev8ieC1/xtVSgGYbj0DkI78w/e9wzO1Hc6HLM9WSlxxWaivrjokGtrKSmQfcaJtETExTWY9aLxKy4Nafqc71bVX7URVrB6iakD [email protected]

restrict选项是一种未来证明(根据文档)的方法,用于禁用其他功能,如端口转发、pty分配等,阻止任何攻击者使用密钥进行旋转或任何其他恶意活动。command选项强制指定的命令在使用此密钥时运行,从而阻止攻击者在计算机上获得命令执行。再加上日志脚本,ElastAlert可以通过查询日志消息来检测攻击,从而将其输入到Elasticsearch中。

restrict command

/usr/local/bin/蜜键

#!/bin/sh logger "Honey key used - ${1}"

许多公司集中管理用户密钥,以避免将相同的授权密钥文件复制到每台计算机。这可以通过AuthorizedKeysCommand指令得到很好的支持,在FreeIPA的情况下,该指令使用sss_ssh_authorizedkeys查找存储在FreeIPA中的密钥。

authorized_keys AuthorizedKeysCommand sss_ssh_authorizedkeys

幸运的是,此命令遵循与授权密钥文件相同的格式,而蜜密钥可以以相同的方式实现

authorized_keys

我不知道这在生产中有多实际。密钥可以很容易地随机分布在用户的主目录中,多个密钥在FreeIPA这样的解决方案(甚至更基层的解决方案,如直接在LDAP中的密钥)中非常容易管理,并且可以通过与现有的日志解决方案(如Splunk或Elasticsearch)的集成轻松地完成检测。

也就是说,我总是对一个似乎太好而不真实的解决方案持谨慎态度。在互联网上搜索类似的解决方案并没有找到任何结果,这让我想知道为什么没有其他人这么做。也许它没有被证明有用,或者这个解决方案有一些我没有发现的内在缺陷。不管是哪种情况,我认为这是一个好主意,我想听听其他人的意见。

处理外部来源的评论。

这有什么用?它似乎不符合任何威胁模型。

这是一个非常公平的观点,而且很可能是针对所部署的环境的。在我的脑海中,我可以看到未加密的蜂蜜私钥散落在用户主目录中,可能有一个名字表明权限跨越安全边界,比如id_jumphost。在使用jumphost限制对另一个网络的访问的环境中,这可能足以使攻击者尝试密钥。在更一般的情况下,我认为这更像是旋转攻击者的陷阱。

id_jumphost

我们能用ssh-vvv看看发生了什么吗?

当然可以:https://gist.github.com/kulinacs/3264e36e0a768b49668d1f8ef129bda

我不认为command+restrict真的用于安全审计/日志记录。。。

我并不反对这不是为了安全审计/日志记录,但我不确定是否有足够的怀疑(队列openssh开发人员告诉我我错了)。sshd(8)手册页给出了如下示例

restrict,command=“uptime”ssh rsa AAAA1C8…[email protected]

restrict,command="uptime" ssh-rsa AAAA1C8...32Tv== [email protected]

对我来说,这说明这被认为是一项安全功能。密钥的任何所有者都可以运行正常运行时间,但不能运行其他任何内容。当然,很少使用的特性的手册页中的例子不应该被视为安全性的确认,但我认为它倾向于这不是一个可怕的想法。不过,还需要做更多的测试。

这似乎打破了AAA链,虽然攻击者只被授权使用日志脚本,但他们仍然经过身份验证,这会带来安全隐患。

不幸的是真的。如果有一种方法可以使特定密钥的身份验证失败,但仍然是日志,那将是非常好的。建议查看到期时间,并从选项中查看它们是否以静默方式失败或是否带有智能日志消息。

expiry-time from

这将“您无权访问此系统”转换为“您有权访问此系统,但您只能运行此日志脚本”,在我看来,这似乎是所有渗透技巧的基础。

不过,AFAIK也同意,用户没有能力输入脚本。这大大减少了攻击面。它们发送的命令被替换,环境变量被忽略,并且不能设置额外的转发。甚至连一个pty都没有分配。经过更严格的测试,在我看来这是相当安全的。