Pwn2OwnAustin2021CiscoRV34xRCE漏洞链复现

　　漏洞分析CVE-2022-20705 Improper Session Management VulnerabilityCVE-2022-20707 Command Injection参考链接前言
　　这个RCE漏洞利用链的实现是由几个逻辑洞的结合而导致的，这几天我花了一些时间复现了一遍，在此记录一下。固件解压
　　我下载的是 RV345 v1.0.03.24，从官网下载到压缩包解压之后可以看到它的 rootfs 是 ubi 格式的 img。之前我都是使用 kali里的 binwalk 对其进行解压可以直接得到解压之后的文件系统。但是由于前几天我的虚拟机坏了，不得不进行重装，但是我还没有装 kali。故找了一下提取 ubi 格式的方式。在 github 上有一个项目：https://github.com/nlitsme/ubidump，通过里面的 ubidump.py 可以很轻松地提取出 ubi 格式的文件。命令如下：python3 ubidump.py -s . 0.ubi 漏洞分析CVE-2022-20705 Improper Session Management Vulnerability
　　CVE-2022-20705 Improper Session Management Vulnerability，是由于 nginx 的配置不当导致的。nginx 的配置文件是 /etc/nginx/nginx.conf，如下user www-data; worker_processes  4;error_log /dev/null;events {     worker_connections  1024; }http { 	access_log off; 	#error_log /var/log/nginx/error.log  error;	upstream jsonrpc { 		server 127.0.0.1:9000; 	}	upstream rest { 		server 127.0.0.1:8008; 	}	# For websocket proxy server 	include /var/nginx/conf.d/proxy.websocket.conf; 	include /var/nginx/sites-enabled/*; }
　　可以发现它又加载了: /var/nginx/conf.d/proxy.websocket.conf 和 /var/nginx/sites-enabled/ ，但是固件解压出来的 rootfs 里的 var 目录有些问题，所以笔者只能根据别人的文章找一下漏洞发生的配置文件。结合 rest.url.conf 和 proxy.conf 来看。location /api/ {         proxy_pass http://rest;         include /var/nginx/conf.d/proxy.conf; }location /api/operations/ciscosb-file:file-copy { 	proxy_pass http://rest; 	include /var/nginx/conf.d/proxy.conf; 	proxy_read_timeout 3600; 	proxy_send_timeout 3600; }location /api/operations/ciscosb-file:form-file-upload { 	set $deny 1; 	if ($http_authorization != ＂＂) { 		set $deny ＂0＂; 	}	if ($deny = ＂1＂) { 		return 403; 	}	upload_pass /form-file-upload; 	upload_store /tmp/upload; 	upload_store_access user:rw group:rw all:rw; 	upload_set_form_field $upload_field_name.name ＂$upload_file_name＂; 	upload_set_form_field $upload_field_name.content_type ＂$upload_content_type＂; 	upload_set_form_field $upload_field_name.path ＂$upload_tmp_path＂; 	upload_aggregate_form_field ＂$upload_field_name.md5＂ ＂$upload_file_md5＂; 	upload_aggregate_form_field ＂$upload_field_name.size＂ ＂$upload_file_size＂; 	upload_pass_form_field ＂^.*#34;; 	upload_cleanup 400 404 499 500-505; 	upload_resumable on; }location /restconf/ {         proxy_pass http://rest;         include /var/nginx/conf.d/proxy.conf; }location /restconf/operations/ciscosb-file:file-copy {         proxy_pass http://rest;         include /var/nginx/conf.d/proxy.conf;         proxy_read_timeout 3600;         proxy_send_timeout 3600; }proxy_http_version 1.1; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Authorization $http_authorization; proxy_set_header Accept-Encoding ＂＂; proxy_set_header Connection ＂＂; proxy_ssl_session_reuse off; server_name_in_redirect off;
　　如果我们请求中 Authorization 不为空，此时 set $deny ＂0＂，就可以向下调用 upload 模块。它会在调用 /form-file-upload前，把文件上传到 /tmp/upload 下。并且由于没有设置 level，它的存储格式类似 /tmp/upload/0000000001。至此我们可以实现任意文件上传至 /tmp/upload。
　　我们接着向下分析，可以在 rootfs/etc/nginx/conf.d 下找到 web.upload.conf 如下：location /form-file-upload { 	include uwsgi_params; 	proxy_buffering off; 	uwsgi_modifier1 9; 	uwsgi_pass 127.0.0.1:9003; 	uwsgi_read_timeout 3600; 	uwsgi_send_timeout 3600; }location /upload { 	set $deny 1;        if (-f /tmp/websession/token/$cookie_sessionid) {                 set $deny ＂0＂;         }        if ($deny = ＂1＂) {                 return 403;         }	upload_pass /form-file-upload; 	upload_store /tmp/upload; 	upload_store_access user:rw group:rw all:rw; 	upload_set_form_field $upload_field_name.name ＂$upload_file_name＂; 	upload_set_form_field $upload_field_name.content_type ＂$upload_content_type＂; 	upload_set_form_field $upload_field_name.path ＂$upload_tmp_path＂; 	upload_aggregate_form_field ＂$upload_field_name.md5＂ ＂$upload_file_md5＂; 	upload_aggregate_form_field ＂$upload_field_name.size＂ ＂$upload_file_size＂; 	upload_pass_form_field ＂^.*#34;; 	upload_cleanup 400 404 499 500-505; 	upload_resumable on; }
　　我们可以发现其对 /upload 进行了 $cookie_sessionid 的检验，但是并没有对 /form-file-upload 进行检验。我们看一下 /form-file-upload 的后端处理程序。启动脚本 (uwsgi-launcher) 如下：#!/bin/sh /etc/rc.commonexport UWSGI_PLUGIN_DIR=/usr/lib/uwsgi/pluginsstart() {         uwsgi -m --ini /etc/uwsgi/jsonrpc.ini &         uwsgi -m --ini /etc/uwsgi/blockpage.ini &         uwsgi -m --ini /etc/uwsgi/upload.ini & }stop() {         killall -9 uwsgi }
　　我们再去找一下 /etc/uwsgi/upload.ini[uwsgi] plugins = cgi workers = 1 master = 1 uid = www-data gid = www-data socket=127.0.0.1:9003 buffer-size=4096 cgi = /www/cgi-bin/upload.cgi cgi-allowed-ext = .cgi cgi-allowed-ext = .pl cgi-timeout = 300 ignore-sigpipe = true
　　从上述文件中我们可以知道 /form-file-upload 它对应的后端处理程序是 /www/cgi-bin/upload.cgi。因此我们可以无条件访问 upload.cgi。
　　同时上述配置文件中我们可以看到检查了 /tmp/websession/token/$cookie_sessionid 文件是否存在。但是存在缺陷，就是这里的 $cookie_sessionid 是用户在 http 请求中传进去的一个值，它并没有检查是否存在 ../../ ，也就是说我们可以通过跨目录来导致授权绕过。如：我们可以传递 ../../../etc/firmware_version。
　　同时也可以看到在 upload.cgi 里对 sessionid= 进行了检查，限制了它的字符，但是并没有考虑到传多个 sessionid= 的情况。因为这里的 sessionid= 是遍历 HTTP_COOKIE 并且取出它最后一个 sessionid= 作为实际的 sessionid= 使用，所以我们可以传两个 **sessionid=**。前一个用来绕过 web.upload.conf 里的判断，后一个当作正常的数据用来通过 upload.cgi 的判断。这样也可以实现无条件访问 upload.cgi。
　　我们接着看 upload.cgi
　　传入适当的参数可以使得我们有能力任意文件移动到 /tmp/www 下，通过这两个漏洞我们也可以伪造出一个 session。CVE-2022-20707 Command Injection
　　我们继续查看 upload.cgi。
　　这个漏洞可以使得任意命令执行。参考链接https://bestwing.me/Pwning%20a%20Cisco%20RV340%20%20%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90%EF%BC%88CVE-2022-20705%20%E5%92%8C%20CVE-2022-20707.htmlhttps://blog.relyze.com/2022/04/pwning-cisco-rv340-with-4-bug-chain.htmlhttps://paper.seebug.org/1890/https://onekey.com/blog/advisory-cisco-rv34x-authentication-bypass-remote-command-execution/https://nosec.org/home/detail/4985.html
　　from https://www.secpulse.com/archives/197154.html