极路由安全设计架构分析

0×00 前言

现代智能路由器是目前物联网发展链条上一个不可或缺的重要组成部分,搞清楚其架构设计对将来设计物联网有深远的影响,当然为更安全的设计物联网架构起到关键作用。本文将针对智能路由器的代表“极路由”的安全设计架构进行详细的分析。

现代智能路由器代表:极路由 HiWiFi OS,说它智能主要表现在可以通过手机App远程管理家中的路由器。

根据公开资料,可以大致了解HiWiFi 整个系统架构。

那么,我们需要分析目标:

由于连接公有云和手机App的都是HiWiFi路由器,所以对其固件的分析是非常有必要的。当然服务器端的OpenAPI&SDK也是研究的重点。

1. HiWiFi 路由固件ROM分析
2. HiWiFi OpenAPI &SDK服务器端分析
3. HiWiFi Android App 分析 (下期分解)

0×01 分析思路及实践

1. HiWiFi 路由固件ROM分析(Reverse Engineering ROM)

解压极路由固件

测试环境:Kali Linux binwalk、squashfs-tools

由于极路由固件是通过SSL直接推送给用户购买的路由器文件系统中,并且HiWiFi是运行在用户态的程序,SSH无法开启,所以,需要从其他渠道获得固件。

HiWiFi固件由于HiWiFi底层是开源的OpenWRT,所以到OpenWRT中文网去寻求资源,因为官方固件不开放下载。http://downloads.openwrt.org.cn/PandoraBox/HiWiFi_1S_HD/stable/

Binwalk 自动提取文件系统失败。

0x12314E        Squashfs filesystem, little endian, version 4.0, compression:lzma (non-standard type definition)

无法解开squashfs文件系统,因为不是标准的lzma压缩打包算法。

使用

hexdump -C install.img >you.out

先看看文件头描述。

没什么头绪,那就要看源代码了。

在没有源代码的情况下怎么办?使用通用解包工具尝试:

(1)tar xvf install.img    最终失败
(2)看到xz 算法。那么,可以使用squashfs工具试试。用squashfs-tools 中的
unsquashfs -f install.img (先安装apt-get install squashfs-tools)  成功。

可以说这是个设计缺陷,怎么可以使用通用工具解开文件系统。(kali 2.0 要自己编译安装squashfs-tools,还要添加lzma补丁等,有点麻烦。)

安全建议:自己开发一个压缩解压包的工具,哪怕在通用工具里加点salt,然后在配合RSA非对称秘钥解密验证。

进入系统 分析系统

安全小提示:进入/etc/shadow 找到root密码(Linux中的密码用两种加密算法加密:DES和MD5,查看你的/etc/shadow文件, 密码栏以$1$开头的是用MD5算法加密的。)

root:$1$IjJSZYnP$14XuZ/eoGldE8Qz2BXkyO.:15797:0:99999:7:::
daemon:*:0:0:99999:7:::
ftp:*:0:0:99999:7:::
network:*:0:0:99999:7:::
nobody:*:0:0:99999:7:::

我想骂人了,root的密码是admin

要想了解极路由是如何设计其系统的,可以查看其lua脚本,如果想更深入可使用IDA Pro反编译*.so动态链接库文件等系统文件。

为了更好的分析其系统架构,我使用virtualbox 搭建一个支持x86平台openWRT 通过文件对比,了解HiWiFi有哪些库 lua是厂商开发的,从分析Uhttpd可以看出,加入了json的解析,提高支持和云端还有手机App通讯的便捷性。

由于时间的关系,没做太多分析,大家可以尽情发挥。

但是又碰到了一个很难破解的问题,极路由厂商开发的lua文件被加密了。

我想到的方法就是动态调试HiWiFi OS,那么需要搭建可MIPS的虚拟环境(QEMU),然后使用IDA Pro去调试。这个下期再说。

2. HiWiFi  SDK OpenAPI分析

我想从两个方向下手分析

(1)手机App和 HiWiFi Cloud 之间的通讯
(2)HiWiFi 路由器和HiWiFi Cloud之间的通讯

(1)手机App和 HiWiFi Cloud 之间的通讯

测试环境:win7、Fiddler

通过Fiddler代理 抓手机App的包

发现手机App和HiWiFi cloud 通讯涉及到4个域名

https://app.hiwifi.com

https://m.hiwifi.com

https://openapi.hiwifi.com

https://client.openapi.hiwifi.com

前端使用nigix架构web服务器,后台使用php开发语言。数据库估计是NoSQL,前期为mysql。

百万用户使用SSL连接,还是能承受的起的(另外提醒一下:WVS扫描后发现SSL2.0版本太低,要换成 SSL3.0)。

我们就分析一个API。

POST https://app.hiwifi.com/mobile.php?m=yun&a=ExchangeDeviceInfo&ios_client_ver=504000602 HTTP/1.1
Host: app.hiwifi.com
Accept: */*
Client-type: ios
Proxy-Connection: keep-alive
App-src: hiwifi
Accept-Language: zh-Hans;q=1, en;q=0.9
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Client-ver: 504000602
User-Agent: HiWiFiKoala-REL/504000602 (iPhone; iOS 8.4.1; Scale/2.00)
Connection: keep-alive
Content-Length: 857
Cookie: __uuid=tjBy+FV/UaGolDRJHKvIAg==; TK=l6DSEEDWm4S17V-xgSv_qpIPxLInuE3AtW6FHPAJ3Q

rid=98150&source=%5B%0A%20%20%7B%0A%20%20%20%20%22device_name%22%20%3A%20%22L-106989-A%22%2C%0A%20%20%20%20%22device_mac%22%20%3A%20%228C705AC50CF4%22%0A%20%20%7D%2C%0A%20%20%7B%0A%20%20%20%20%22device_name%22%20%3A%20%22MiBOX1S-3196dc7cb902ca41%22%2C%0A%20%20%20%20%22device_mac%22%20%3A%20%22983B16E2E252%22%0A%20%20%7D%2C%0A%20%20%7B%0A%20%20%20%20%22device_name%22%20%3A%20%22lyyer-iPhone%22%2C%0A%20%20%20%20%22device_mac%22%20%3A%20%22A85B786254C0%22%0A%20%20%7D%2C%0A%20%20%7B%0A%20%20%20%20%22device_name%22%20%3A%20%22%E5%B0%8F%E7%B1%B3%E7%9B%92%E5%AD%903-%E9%87%8C%E5%B1%8B%22%2C%0A%20%20%20%20%22device_mac%22%20%3A%20%226CFAA74B34B6%22%0A%20%20%7D%2C%0A%20%20%7B%0A%20%20%20%20%22device_name%22%20%3A%20%22Xiaomeng%22%2C%0A%20%20%20%20%22device_mac%22%20%3A%20%220C74C2837241%22%0A%20%20%7D%0A%5D&token=l6DSEEDWm4S17V-xgSv_qpIPxLInuE3AtW6FHPAJ3Q

使用fiddler  文本向导 URLDecode  可以解析数据。哥,你也别太相信HTTPS,路由器传输的数据都在裸奔。

(2)HiWiFi 路由器和HiWiFi Cloud之间的通讯

这个要考虑一下了,HiWiFi路由器和HiWiFi之间的通讯,难道要跑到公网sniffer?NO。只有分析lua或者so源码了。但是目前源码大部分加密,还没有想好思路。

0×02 总结

HiWiFi系统总体来说安全设计考虑充分,本地文件系统使用加密存储,减少了逆向的可能。手机App和HiWiFi Cloud都是SSL通讯,增加了网络层面中间人攻击难度。当然有更多的安全设计(例如:token设计等),本文由于时间关系,就先分析到这。

时间: 2024-08-29 21:06:11

极路由安全设计架构分析的相关文章

极路由安全设计分析姐妹篇

开篇想说两件事情: 一.非常感谢Freebuf大牛们,在其提供的网站上找到了HiWiFi固件.其中9003版本squashfs文件系统上的lua代码没有经过预编译处理,这对我们基于源码分析极路由提供了可能.地址 二.经过修炼发现HiWiFi固件解压问题,其实可以使用Windows操作系统下面的开源软件7zip解压. 那么,本期的重点是分析HiWiFi lua源码安全设计部分. 0×01 分析思路 一.了解OpenWRT Web认证过程. 二.了解HiWiFi web认证过程和HiWiFi Clo

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,

秒杀系统架构分析与实战(参考、转载)

目录[-] 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一次性发送多个请求 6.3 多个账号,不同IP发送不同请求 7 高并发下的数据安全

【转载】秒杀系统架构分析与实战

本文转载自:http://my.oschina.net/xianggao/blog/524943 0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是100

二、OpenStack入门 之 架构分析

OpenStack入门 之 架构分析 写在前面 学习目标: 了解 OpenStack 各组件的逻辑关系: 了解 OpenStack 的各组件的通信和部署关系: 了解 OpenStack 的工作流程: 接下来我会掌握: OpenStack 组件间的逻辑关系: OpenStack 的API: OpenStack 组件间的通信关系: OpenStack 中几种不同的存储: OpenStack 工作流程: OpenStack 的部署架构: OpenStack 各组件之间的关系有:逻辑关系,通信关系,部署

电商商品秒杀系统架构分析与实战

网址:http://my.oschina.net/xianggao/blog/524943 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一

[转]秒杀系统架构分析与实战

转自:http://my.oschina.net/xianggao/blog/524943 目录[-] 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2

分布式MySQL数据库TDSQL架构分析

摘要:腾讯计费平台部为了解决基于内存的NoSQL解决方式HOLD平台在应对多种业务接入时的不足.结合团队在MySQL领域多年应用和优化经验,终于在MySQL存储引擎基础上,打造一套分布式SQL系统TDSQL.本文是对该系统架构分析. 腾讯计费平台部托管着公司90%以上的虚拟账户.如QB.Q点.包月服务.游戏的二级账户等,为了保证能顺畅支撑公司各大业务的实时在线交易.而且在各种灾难场景下数据是一致而且可用的,对系统的可用性.一致性切换要求很高,因此计费团队历来都很重视高一致性存储系统的建设. 到眼

【转载】Instagram架构分析笔记

原文地址:http://chengxu.org/p/401.html Instagram 架构分析笔记 全部 技术博客 Instagram团队上个月才迎来第 7 名员工,是的,7个人的团队.作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张.不得不说,这真他妈是个业界奇迹. 几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instance