普通情况

name: poc-yaml-test-upload-cve-xxx-xxxx
manual: true
transport: http
set:
	s1: randomInt(1000000000, 9000000000)
	s2: randomLowercase(20)
	rBoundary: randomLowercase(8)
rules:
	r0:
		request:
			cache: true
			method: POST
			path: /UploadFileData?action=upload_file&foldername=%2e%2e%2f&filename={{s2}}.jsp
			body: "\
				------WebKitFormBoundary{{rBoundary}}\r\n\
				Content-Disposition: form-data; name=\"myFile\"; filename=\"test.jpg\"\r\n\
				\r\n\
				<% out.println(\"{{s1}}\"); new java.io.File(application.getRealPath(request.getServletPath())).delete();%>\r\n\
				------WebKitFormBoundary{{rBoundary}}--\r\n\
				"
			headers:
				Content-Type: multipart/form-data; boundary=----WebKitFormBoundary{{rboundary}}
		expression: response.status == 200 && response.body.bcontains(b"showSucceedMsg")
	r1:
		request:
			cache: true
			method: GET
			path: /xxxPath/{{s2}}.jsp
		expression: response.status == 200 && response.body.bcontains(bytes(string(s1)))
expression: r0() && r1()
detail:
	author: chaitin
	links:
		- http://example.com

这里给出一个对于file-upload漏洞的范例,也许不同漏洞的文件上传之间互有差异,但是大体上我们需要符合以下几点规则

一般来说文件上传类型的poc会有核心的两个rule,一个负责文件上传,一个负责读取所上传的文件。也许某些poc只有上传的逻辑,但是无关紧要,我们只要对照着去分析poc中给出的内容即可,按需去判断这些rule能不能成为漏洞判断的标准
  • 在关于文件上传的rule中
    1. 如果需要boundary,那么我们需要对这个boundary内容使用set进行随机化处理
    2. 对于上传的文件名称,我们分以下几种情况进行讨论
      • 能自定义上传文件名称时,必须随机化产生文件名称,之后再进行上传处理
      • 如果上传的文件名称由系统产生,且生成的文件名称为随机值时,如果response中存在相关文件的名称,那么我们可以在output中提取出文件名称并进行使用
      • 如果上传的文件名称由系统产生,且生成的文件就是系统本身的文件,即产生了文件覆盖的现象,那么无论如何,我们都不要尝试去上传对应的文件,那么这个时候我们就需要找到另外的方法去验证漏洞的存在与否
    3. 对于上传的文件的文件内容,我们有以下几点的规定
      • 对于上传内容,必须进行随机化处理,在set中声明随机的内容
      • 对于上传内容,可以的话推荐编码处理后再进行匹配,但是不做强求
      • 如果上传的文件格式对于目标web系统是能够执行的,那么我们一定要添加删除的逻辑(比如php的unlink或者java的java.io.File)
    4. 对于header中的内容,必须和上传的文件内容相匹配,这个需要具体参考上传的文件内容
    5. 对于expression中的内容,这里不做强制规定,但是仍要有以下的限制
      • 需要符合response的状态
      • 不强求匹配response中的内容,但是可以添加一些正确且通用的逻辑
  • 验证上传的rule中
    1. 需要符合目标系统去访问产生的对应文件
    2. 大部分情况下我们都要尝试去匹配之前我们产生的随机值内容,这里需要注意在expression中使用相应的函数时,需要参考文档正确处理类型,防止出现无法匹配的现象
除去上边这些内容,我们同时需要保证全部的expression连起来时规则是相对较强,是不容易在一些特殊的系统上产生误报的

特殊情况

上面这些说明了常见情况下的上传脚本文件的验证方式,如果依据上述内容排查下来,仍然不符合需求的话,这里提出几个常见的问题:

  • 对于文件上传漏洞,如果实在难以找到无害化上传的方法,应该如何去进行判断poc是否可行?
    • 对于这个问题,如果仍然希望写出无害化的poc,那么我们可以抛去原理验证的方式,尝试去找一些一定只有存在漏洞的版本才能出现的信息,通过匹配这些内容,来侧方位地验证漏洞的存在
但是寻常情况下比较不推荐使用该方法进行验证
  • 如果上传的文件内容是二进制文件,比如zip,暂时没有办法实现上述所说的随机化内容,应该如何处理?

    • 这种情况下现阶段的情况下不是很推荐再去编写yaml poc进行验证,可以等待使用go poc完成随机化的处理
  • 如果是使用系统命令创建的文件,首先尽量不要创建脚本类型的文件,尽量是一个txt文件;其次,不要再多发一个包进行文件的删除,因为这一般就会使用rm命令,这个命令在目标系统上执行是非常危险的行为,所以宁愿留一个文件,也不要执行相关的命令

模板

文件上传