[AOH 028] 1小时->极速挖掘特斯拉Roadster开源项目漏洞

一、前言

下午看到新闻，特斯拉现已“完全开源”其初代 Roadster 跑车的设计和工程，并发布了所有人都可以访问的研发文件。

发布了一个新的访问路径，接下来快速测试可能存在的安全问题。

二、梳理端点

访问路径后，得到如下页面:

大致梳理下对外暴露的路径，主要有如下：

• https://service.tesla.com/docs/Public/Roadster/Original/1.2.5/tabmenuframebc75.html

• https://service.tesla.com/docs/Public/Roadster/TheoryOp/1.2.5/tabmenuframe.php-ID=DO.html

• https://service.tesla.com/docs/Public/Roadster/Toolbox_Articles/Roadster_Issue_Articles.pdf

• https://service.tesla.com/docs/Roadster/Owner/Roadster_2008_Owners_Manual.pdf

上述路径访问后会下载静态文件，看起来没啥好测的，不要慌，魔鬼藏在细节里，这里面有很多信息和细节可以深入与挖掘。

三、测试路径穿越

由于是黑盒测试，我们不妨猜测下，当我们访问路径：https://service.tesla.com/docs/Roadster/Owner/Roadster_2008_Owners_Manual.pdf

后端的逻辑会是如下：

1. 路径 /docs/Roadster/Owner/ 会在路由层命中后端的一个文件下载函数

2. 路径 Roadster_2008_Owners_Manual.pdf 是这个函数的参

3. 函数会从参数取值(source), 然后读取文件(sink), 并返回

那么，如果上述的猜测成立，可以尝试fuzz最后一段路径，也就是文件名这个部分，构造:

%2f%2f等穿越利用，看是否存在一些有趣的回显。

当然，也可以猜测 /docs/ 路径会在路由层命中文件函数， Roadster/Owner/Roadster_2008_Owners_Manual.pdf是参，都是可以的，毕竟是黑盒，可以发散测试。

四、测试SSRF、RCE

上面，我猜测的是下载的文件和service.tesla.com在同一主机的情况，现在很多文件和站点都是分离的，那么后端会不会获取文件参后拼接到存储桶的请求路径中，进行远程文件请求后返回文件的数据呢？

不妨猜测后端逻辑如下：

1. 路径 /docs/Roadster/Owner/ 会在路由层命中后端的一个文件下载函数

2. 路径 Roadster_2008_Owners_Manual.pdf 是这个函数的参

3. 函数会从参数取值(source)， 然后构造出远程文件路径，例如"http://teslafile.com/{Roadster_2008_Owners_Manual.pdf}", 并发起远程文件请求(sink)，返回文件数据

如果你是这么思考，那么这儿可以测试的payload如下:

@youroob.server.com/xxx.pdf
'|sleep 5
`|sleep 5

五、测试XSS

可控输入点不多，但路径回显到了cookie头，可以深入分析下， JS是否有调用的情况，当然这儿做了url编码不太好利用：

六、测试信息泄露-1

泄露了报错信息: nginx + php

七、测试信息泄露-2

看到上面有1.2.5的两个链接，去掉后面的部分，访问：

https://service.tesla.com/docs/Public/Roadster/Original/1.2.5/

这儿枚举下版本号：

• GET /docs/Public/Roadster/Original/§1§.§2§.§5§/main1.html HTTP/1.1

• GET /docs/Public/Roadster/TheoryOp/§1§.§2§.§5§/main1.html HTTP/1.1

看是否泄露了非预期的版本:

八、测试HTTrack是否泄露敏感文件

从第七点出发，我们随便点击几个页面，看到HTML下：

很好，可以知道tesla的开发人员使用httrack工具下载内部站点为静态文件后，部署在这个路径上。

那么httrack下载站点时，是否留下一些敏感的配置或者文件呢, 本地安装并下载:

apt install httrack -y
httrack "https://service.tesla.com/docs/Public/Roadster/Original/1.2.5/main1.html" -O ./cache/ -v

有一个叫做hts的文件和文件目录看起来是httrack生成的，尝试构造访问，未成功~

但是基于这个方法，完整的把站点下载到了本地, LOL~

九、尝试接管roadster.docksal

进入到下载好的目录中，使用grep查找下有哪些url路径，看到有意思的事情,：

泄露了 http://roadster.docksal/1.2.5/xxx.php 类似的路径，基于此可以总结出规律，即:

• https://service.tesla.com/docs/Public/Roadster/Original/1.2.5/ ==  http://roadster.docksal/1.2.5/

可以知道http://roadster.docksal/1.2.5/就是tesla内部托管文档的平台。

思考roadster.docksal能否被接管，可以的话，用户访问tesla文档，加载html或者交互时的数据就可以被接管者窃取到。

查询roadster.docksal的whois并不存在~，u1s1看起来也不像个正常的域名

十、尝试下载docksal配置

由于不熟悉docksal，于是google，在这个页面: https://docs.docksal.io/core/system-vhost-proxy/ 学习了下:

官方注解:

Docksal 有一个内置的反向代理容器，增加了对运行多个项目或使用多个（任意域）的支持。默认情况下，容器绑定到 192.168.64.100:80 并根据主机名路由 Web 请求。系统会为您的主机和项目容器自动配置 *.docksal 域的 DNS 解析。

可以这么理解，即 roadster.docksal 是配置在 docksal平台上的一个虚拟域名，在docksal平台可以解析。

这儿可以衍生出多个测试思路，并且一旦成立都是高危甚至严重级别的漏洞：

• 部署一个docksal 容器是否可以越权访问到tesla的roadster.docksal

• 部署docksal容器时，是否有固定的配置或者模板保存了敏感数据，这些配置可以被访问到

第一点就不测试了，太硬了~

继续跟进第二点，在github上找到了一个docksal项目：https://github.com/docksal/boilerplate-nodejs

可以看到有一个 .docksal 目录，目录下有docksal.env ，docksal.yml等文件，一看就是好东西, 那么按照这个思路，tesla部署roadster.docksal应该也会有一个.docksal的目录，尝试构造路径访问：

• Original/1.2.5/.docksal/docksal.env   ==  http://roadster.docksal/1.2.5/.docksal/docksal.env

• Original/1.2.5/.docksal/docksal.yml   ==  http://roadster.docksal/1.2.5/.docksal/docksal.yml

• Original/.docksal/docksal.env   ==  http://roadster.docksal/.docksal/docksal.envl

• Original/.docksal/docksal.yml ==  http://roadster.docksal/.docksal/docksal.yml

被nginx 403 了~， 不是404 ，就这样吧，收工！

原文始发于微信公众号（Art Of Hunting）：[AOH 028] 1小时->极速挖掘特斯拉Roadster开源项目漏洞