施耐德充电桩漏洞挖掘之旅

大家好,我是BaCde,今天来说一说2020年底针对施耐德充电桩的漏洞挖掘过程。此次挖掘最终实现了通过远程无需用户交互场景下实现Root权限shell获取(一键远程Rootshell获取)。官方已经于今年7月份公布漏洞补丁以及相应的CVE编号。

0x01 为什么选择施耐德?

作为车联网安全研究来说,充电桩作为车联网必要组成部分,具备实际的研究价值与意义。而面临如此多的品牌,选择哪个目标作为研究对象是面临的第一个问题。为了能够更快的实现我选择了几个衡量指标,包括官方有响应中心、固件可下载、市面上可以买到、互联网上有暴露的目标。分别对应合法性、静态分析、动态测试、漏洞可产生实际的影响。

根据指标通过网络上去收集信息,最终将目标锁定在施耐德。同时,施耐德也在CVE官方的CNA列表中,报送的漏洞可以获得CVE编号。

0x02 目标设定

确定了要研究的对象,接下来就要确定一下我们要实现什么样的效果。这可以使得在分析过程中保持聚焦,不偏离方向。目标设定如下:

  1. 远程获取设备Root权限
  2. 无需登录,无需交互

根据上述设定最直接的方式就是寻找远程命令执行漏洞,即要RCE类型漏洞。

0x03 信息收集

一切准备就绪,开始我们的漏洞挖掘之旅。

阅读全文 »

如何高效使用RapidDNS

大家好,我是BaCde。沉默了了有一段时间,最近一直在边开发边思考网站的发展。思考了很多,所以网站和公众号的更新就慢下来了。后续会多发一些跟网络安全相关的一些内容。

今天来分享点关于RapidDNS使用的小技巧。

Linux 命令快速查询

将以下命令加入到 bash_profile文件中。

rapiddns(){
	curl -s "https://rapiddns.io/subdomain/$1?full=1" \
	| grep -oP '_blank">\K[^<]*' \
	| grep -v http \
	| sort -u 
}

然后后面就可以使用rapiddns命令直接查询结果。

rapiddns tesla.com

浏览器搜索引擎快速查询

阅读全文 »

Cyber Apocalypse 2021 Web Artillery WriteUP

大家好,我是BaCde,上周临时组队参与了HackTheBox组织的Cyber Apocalyps 2021的CTF比赛。今天主要写一下Web的Artillery,这是一道3星题(最难为4星),这是一道关于XXE利用的题,做出来的人相对很少,也花了不少时间,有些收获,这里写出来与大家分享。本文不介绍基础知识,如果要学习基础可以查看后面的推荐文章。

收集信息

此次的CTF题大部分都提供源代码,并提供有Dockerfile文件,可通过docker build构建并运行。通过源码可知源代码为Java语言。openjdk 1.8.181版本,Web Server为Tomcat10。

阅读全文 »

我是如何低成本建立RapidDNS.io网站的

大家好!我是BaCde,2020年3月我着手开发RapidDNS这个网站,并于2020年4月1日正式上线。

RapidDNS.io是一个在线域名查询和IP反向查询的网站。有超过25亿条记录,支持5种(A,AAAA,CNAME,MX,CERT)数据类型。到目前为止,网站全球Alexa排名15万左右并累计提供超过1亿次查询。现每月网站流量超过1TB。除此之外网站也被加入到Amass,OneForAll,theHarvester,Sudomy,subfinder,ksubdomain等众多知名开源项目中。

接下来我就跟大家分享建设这个网站的过程。

产生想法

2020年在做子域名收集的开发时,想起了Rapid7的DNS数据。经过对其进行分析后,确认是我需要的内容。于是便有了做一个在线的网站的想法,即方便自己同时又可以方便其他有需要的人。

有了这个想法后就开始计划目标,确定只做子域名查询和IP地址反查。其实在开发时,想自己跑数据,但是资源有限。就决定先以Rapid7的DNS数据来尝试。后续也可根据具体情况在增加功能。

面临的问题

开始实现之前要考虑如何以最低的成本实现最好的效果。最好的效果即在多人同时访问时保证查询速度和系统稳定。因为这将直接决定采用什么样的架构来实现。

先来分析下建设网站需要的东西。包括一个域名和至少一台服务器,用来存放web和数据。数据存储的空间至少要300gb,cpu至少双核,内存至少4g。这是没有增量和保存历史记录的情况。到各家云厂商,idc机房,根据这个配置对比了其价格,最低的服务器成本也要5000块一年(仅是数据存储)。

因为打算做免费网站,这样的成本超出了我的预期,而且也可能性能不够。对于这个数据,国外已经有几篇数据运用的文章。其实现的思路有:1. 采用aws的Athena实现,2. 开源的DNSGrep,包括RapidDNS上线后采用mongodb实现的开源项目等。因为大多数围绕的是子域名查询,没有IP地址反查功能。而且Athena将随着用户数量增加,其费用也将非常恐怖,更适合自用。说了这么多,主要的问题说白了就是穷。

另外一个省钱的思路就是从已有资源来想办法,这时想到了跟随我多年联想的笔记本电脑,它已经吃灰好久了,这是一个可利用的资源。这样只需要再买一个web服务器就可以了。根据之前调查的价格,这样的服务器一年大概需要不到2000块。

但是这就产生了另外一个问题,家里的网络是光纤,没有固定ip地址,而且之前测试发现外网ip是无法直接访问的,映射端口是不行的。做端口转发?这个的性能没测试过,无法保证,也不打算采用。当然这里我想到了一个解决办法,在下面的内容中会讲到。

解决方案

经过上面的考虑,最终我采用下面的结构。后来经过线上的运行情况,稳定性和查询速度还在接受的范围内。后续也可以增加worker和消息队列来支持其他方式的数据增加。

本地服务器就是我的一台笔记本电脑,其配置是3代i7,8G内存。1.2TB的固态硬盘(1TB+250TB两块组成)。数据存储与查询使用的是elasticsearch,前面加了一层nginx,并配置了认证。

外部服务器是一台云主机,配置好为双核4G内存。包括nginx反向代理和Flask做的web查询界面。 外面又加了一层CDN。上面没有公网IP的问题,取了个巧,因为现在家里的网络都支持IPv6,所以外部服务器直接使用IPv6地址直连家里的笔记本电脑。

这里说点额外的,对于IPv6地址是可以直接连接的,不需要做映射。一般我们家里的电脑会分配多个IPv6地址,有至少一个临时(temporary,我们连接其他电脑时使用)的地址和secured的。一般我们可以设置一个固定的即可。这里大家还是注意点,避免泄漏IPv6地址。之前看一篇公众号文章,发现对目标的IPv4地址打码了,却没有对IPv6地址打码,这个挺危险的。

以上这套结构的成本为域名450元,cdn服务器免费的,服务器每月费用20美元(差不多140元),电费每月大概60元。前期投入买了一块三星的SSD,成本1000元。截止目前为止,共投入450+2400+1000=3850元。后续维持现状基本是服务器加域名成本,一年2850元。

编码

需要的一些基础知识:

  1. html+javascript+css基础
  2. python+flask基础
  3. elasticsearch基础

其实想好了方案,而且本身也不复杂,具体编码就相对简单了许多。比如查询界面的开发,我直接找了一套现成的模版,改改样式就可以了。后端flask边看文档边开发就可以了,没啥好说的。唯一要说一下的是这里flask使用了协程,其查询效果好了很多。当然后面跟insight-labs的A牛沟通过可以换bjoern,据说效果很好,不过这个我没测试,感兴趣的可以试试看,看完也可以分享出来让我学习学习。

主要的还是在Elasticsearch这里,这里选择他主要因为我比较熟悉,而且有IP字段类型,做IP段查询时非常方便。这里换乘其他的如mongodb、mysql等也可以。mysql使用myisam,加上Partition问题也不大,Insight-labs的QQ群数据查询就是成功案例。大家可以选择自己擅长的。

后来有朋友过来交流查询速度问题,说他那边的查询速度没我的快。其实主要我这边做了一些优化处理。我在导入数据时,对域名处理,将根域名单独存放一个字段,剩下的部分单独放一个字段。因为不需要模糊匹配,查询速度就会非常快,同时存储空间也可以节省几十G。当然,这牺牲掉了模糊搜索的功能。具体字段可以看下图:

创建mapping:

{
  "mappings": {
    "domain": {
      "properties": {
        "name": {
          "type": "text"

        },
        "type": {
          "type": "keyword"

        },
        "value": {
          "type": "ip"

        },
        "domain": {
          "type": "keyword"

        }
      }
    }
  }
}

最关键的其实是导入程序,也是投入时间最多的,因为数据量比较多。单纯使用bulk速度很慢。使用SSD速度会提高几倍。但是依然达不到预期,因为会出现es内存耗尽,队列太多等各种异常,比如导入到8亿多数据时报错。也尝试通过迭代的方式来实现高性能文件读取,但是最后主要的根源还是在es和字符串的处理上。最后采用多进程方式。elasticsearch设置不刷新,0副本,并调整es的queue,线程,最大内存等参数。这个需要根据自己机器配置去进行调整。通过实际使用一天导入大概10亿条记录,当然还是有优化空间的。

修改index设置的方法:

{
  "index": {
    "refresh_interval": -1,
    "number_of_replicas": 0
  }
}

导入完成后在修改回去即可。

以上elasticsearch使用的是6.7.1版本。其他版本可能会有差异,根据实际情况调整即可。

总结

其实总体来说,本文技术上没啥复杂度,实现起来也相对简单。我觉得有点像以前革命时期八路军的风格(完了往自己脸上贴金了,勿喷),在有限的条件下来尽可能实现自己想要的效果。

希望本文对你有所帮助,对于上述内容有任何疑问,可以给我发送消息一起交流。

最后,RapidDNS已经一周年,这一年家人和同事的支持,同学的帮助,以及国内外朋友的称赞和鼓励,才让我坚持维护着网站运行。感谢在网站运行中大家提来的建议和反馈!感谢所有使用RapidDNS的人!感谢你们让RapidDNS更好。
所以,RapidDNS现有查询功能将一直免费开放下去,同时新的一年我也会增加新的功能,也欢迎大家发来你们的建议和想法。

大家也可以关注公众账号,获取最新的网站功能、使用技巧等内容。

阅读全文 »

RapidDNS网站在SRC漏洞挖掘中的一个思路

大家好,我是BaCde。今天给大家分享一下我这个月提交鹅厂漏洞的一个挖掘思路。

首先说一下结果,一个SQL注入(可报错回显)、弱口令(审核后发现是域名解析IP错误)和一个有限的SSRF漏洞。

当然今天我要说的不是直接查询子域名,那就没必要写这篇文章了。

像鹅厂这样规模的企业,其资产数量众多。同样的,其盯着他的大佬们也非常多。而目前收集信息的方法大多数都差不多。本身厂商自己也会对其进行监控、检测。基本上很多被筛选了很多遍。那应该如何去挖掘呢?其中一种思路就是找到别人未发现的一些资产,这将增加挖掘的概率。

RapidDNS网站在2020年12月的时候增加了5000万的HTTPS证书数据。暂时还没有对证书查询独立(将在新上线的版本独立查询)。

阅读全文 »

RapidDNS.IO 网站应用实例

大家好,我是BaCde。公众号开通了2个月,一直没发内容。本来计划写写网站建设思路,今天先写一篇网站的使用分享。

网站自发布以来,一直没有什么说明和教程。因为它的功能非常单一,不需要做太多介绍。但是呢,有一些小细节和场景,我觉得可以分享下。

首先,网站基础功能可以查询网站子域名,根据IP地址或IP段查询绑定的域名信息,这里支持IPv6的地址和地址段。目前最大支持显示1万条(大多数情况下足够了)。其中查询结果页面中有导出csv的功能,可以导出全部结果。其实不导出,查询全部结果只需要加入参数?full=1即可。目前大多数开源工具采集时采用也是这样的方式。

下面来说下实际应用场景。

信息收集

在收集ASN信息时,可以根据反向IP段查询,迅速确定筛选出目标的资产。

比如下图中搜索到的腾讯结果中,有很多ip段时属于腾讯云服务的机器,这些IP对我们挖掘漏洞来说,意义不大。但是可能又会存在夹杂在其中的个别目标。这时候就可以使用Reverse IP功能进行查询,然后筛选出目标或者筛选IP段。

下面随便挑了一个(58.87.64.0/18)查询结果来展示下,发现大多数不是腾讯的域名,则可以跳过,或者从中筛选出腾讯的。

溯源定位

这里主要说两个场景,第一个就是扫到某个IP存在漏洞,想知道哪个厂商的,第二个就是对于攻击IP地址是属于哪个机构的。这是两个非常常见的需求。

这里一种方法是直接查询IP地址,那么,当ip地址查不到时怎么办呢?

今天就在微信群里遇到一个例子。有人在日志中发现了360某团队的一个dnslog的地址,但是打开其域名时一个空白地址。这里我通过获取到解析的IP地址,查询C段,然后很快速的发现了dnslog平台的登录地址,根据版权信息确认是360的。

其发现的地址形如:xxx.b.nslog.0kee.360.cn。访问nslog.0kee.360.cn为空白,其解析的IP地址为123.59.211.124。通过RapidDNS来查询C段,查询链接:https://rapiddns.io/sameip/123.59.211.124/24#result。

在结果中可以发现一个0kdns.net的域名,访问后就是dnslog平台登录地址。

好了,以上就是我经常使用到的方法,跟大家分享出来。另外,网站由于网络原因,可能会不太稳定。有问题大家可即时反馈,看到后我会第一时间来解决。

扫描篇下方二维码可关注公众号

阅读全文 »

SourceMapX——批量扫描并恢复sourcemap的源代码文件

SourceMapX是一个批量扫描并恢复sourcemap的源代码文件的脚本。

项目地址:
https://github.com/insightglacier/SourceMapX

安装

该脚本主要由unwebpack-sourcemap项目修改而来,使用Python3编写,需要安装 BeautifulSoup4 and requests.可以使用 pip3 install -r requirements.txt命令进行安装。主要是修改为批量检测并下载,可用于SRC的漏洞挖掘。

阅读全文 »

Hacking all the cars之Tesla API分析与利用(下)

该系列文章将通过逆向的方式分析Tesla远程api,并自己编写代码实现远程控制Tesla汽车。该篇文章为第二篇,将主要讲解websocket抓包分析与编程实现对Tesla的远程控制。如果你还没看第一篇,请先查看第一篇内容Hacking All The Cars - Tesla 远程API分析与利用(上)

0x00 Websocket通信分析

Tesla的召唤功能除自动召唤外,还支持手动的前进与后退功能。要想手机APP可以使用召唤功能,需要先在车机中开启召唤功能。

在测试时,建议寻找一块比较大的空地,然后设置抓包,使用手机APP进行操作。通过burpsuite抓到的数据包可知,召唤功能主要通过websocket来实现。但是分析过程中可以发现,burpsuite只显示了连接地址和发送的数据内容,并没有显示其请求的头,所以,当直接去连接时会返回401错误。

在这个时候就需要还一个工具了,本文选择使用charles。这个工具针对websocket的支持非常友好,不仅可以看到请求头,还针对发送与接收以不同的颜色区分显示出来,十分方便分析。

阅读全文 »

Hacking All The Cars之Tesla API分析与利用(上)

该系列文章将通过逆向的方式分析Tesla远程api,并自己编写代码实现远程控制Tesla汽车。

0x00 简介

Tesla自身的app具备控车的一些功能,如解锁、温度控制、充电、行车轨迹、召唤功能等。那么可能有朋友要问了,分析app自己实现的意义是什么呢?为什么不用官方提供的app呢?而且Github也有大量开源项目。

最开始我也有同样的疑问,但是,当我去尝试了解后,发现分析api,自己可以拓展多种玩法:

  1. 挖掘潜在的隐藏功能。在漏洞挖掘过程中,总会有一些未在界面显示,被开发者隐藏起来的一些功能。这些功能一旦被我们发现,对漏洞挖掘或者实现额外的功能都有帮助。

  2. 实现批量控车功能。官方的APP同时只能控制一台汽车,无法控制多台。我们熟悉API后,我们则可以实现批量控制汽车,实现速度与激情中的控车场景,这想想都觉得很酷;

  3. 熟悉Tesla业务流程,可以深入去挖掘漏洞;

  4. 尽管目前网络上有很多Tesla的API代码或库,但是其他的车还没有。我们以Tesla为典型例子,可以将其思路和方法拓展到其他同类的汽车厂商中;

  5. 个性化定制,通过API可以按照自己习惯定制流程,控制更加灵活。还可以拓展功能,如雨天自动关闭天窗,根据情况自动制热/冷却等。甚至可以做成一个商业产品;

  6. 通过api调用,配合代理跳板实现隐藏自身,同时不会暴漏自己的imei、设备等,减少APP信息收集导致的隐私泄漏。

  7. 记录下所有关于车的数据,进行数据分析。

阅读全文 »

物联网安全之MQTT渗透实战

上一篇 物联网安全之MQTT协议安全 主要介绍了MQTT安全的一些基础知识。今天将在上一篇基础上来说说实战中MQTT的利用。

在整个物联网或车联网架构中,MQTT的部分通常应用在移动端、管理端、Web端、设备端。而MQTT协议中的三种角色是发布者(PUBLISHER)、订阅者(SUBCRIBER)、代理(BROKER)。发布者(PUBLISHER)和订阅者(SUBCRIBER)通过代理(BROKER)来发布和订阅消息。这两个角色在实际场景中主要应用是移动端、Web端、设备端;代理(BROKER)一般是服务器,可以由activemq、hivemq、emqx等许多软件来搭建。在开发过程中,不同的设备,技术特点也有所不同。其使用的协议除了mqtt外,Web端通常使用websocket的方式来进行收发消息。

mqtt应用场景
EMQ X Broker 场景

0x00 获取MQTT认证信息

目前对于MQTT的开发中的安全还尚未受到广泛关注,这使得有多种方式在移动端、Web端、设备端获取到MQTT的认证与连接信息。通过获取的信息来进一步实现越权访问、发布恶意内容等攻击。

阅读全文 »