挖不到洞真的是你的问题嘛

本文最后更新于:2021年8月19日 下午

事情是这样,在一次渗透项目中发现了目标 OA 的一个弱口令,登入系统后找到了一处上传点。但在上传木马 GetShell 的时候遇到了大坑,相同的操作、JDK 版本、burpsuite 甚至连 burp 配置都一样我和同事同时测试却是两个截然不同的结果(同事按照我的思路 getshell 了,我还在冷风中摇曳像只傻狗)遂记录下来。

因为是开源 OA 先从源码简单分析下漏洞原理

定位到编辑资料上传头像处

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
if (this.Fup.HasFile)
{
FileExtension[] fileEx = new FileExtension[]
{
FileExtension.GIF,
FileExtension.JPG,
FileExtension.PNG,
FileExtension.BMP
};
if (FileSystemManager.IsAllowedExtension(this.Fup, fileEx))
{
string userName = sys_UserInfo.UserName;
string text = base.Server.MapPath("~/Files/common/");
string text2 = userName + Path.GetExtension(this.Fup.FileName);
text += text2;
this.Fup.PostedFile.SaveAs(text);
sys_UserInfo.PerPic = text2;
this.Fup.Dispose();
}
}

判断文件合法性的方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public static bool IsAllowedExtension(FileUpload fileUpload_0, FileExtension[] fileEx)
{
int contentLength = fileUpload_0.PostedFile.ContentLength;
byte[] buffer = new byte[contentLength];
fileUpload_0.PostedFile.InputStream.Read(buffer, 0, contentLength);
MemoryStream memoryStream = new MemoryStream(buffer);
BinaryReader binaryReader = new BinaryReader(memoryStream);
string text = "";
try
{
text = binaryReader.ReadByte().ToString();
text += binaryReader.ReadByte().ToString();
}
catch
{
}
binaryReader.Close();
memoryStream.Close();
bool result;
for (int i = 0; i < fileEx.Length; i++)
{
FileExtension fileExtension = fileEx;
if (int.Parse(text) == (int)fileExtension)
{
result = true;
return result;
}
}
result = false;
return result;
}

其中 FileExtension 为枚举类型,白名单

1
2
3
4
5
6
7
public enum FileExtension
{
JPG = 255216,
GIF = 7173,
BMP = 6677,
PNG = 13780
}

取文件内容前两个字节的十进制依次和 FileExtension 里定义的枚举值作比较相同则上传文件。很经典的问题这里判断文件合法性的操作并没有判断文件后缀,而只看文件头。故我们可以制作上传图片马绕过或给木马加上图片的文件头:木马内容十六进制前两个字节添加任意一个枚举值。如 JPG 255216 换为十六进制就是FF D8,GIF 7173 转换为十六进制就是47 49
copy normal.jpg/b + shell.aspx/a shell.jpg
我一般习惯生成正常图片后缀的图片马,再使用 burp 抓包把图片后缀改为脚本后缀,免得遇到前端验证等的一些情况(别和我讲什么禁用 JS)

坑点就在改包的过程!下图是原始的包的文件名和文件内容的 HEX 形式
ce25cbf34495d2eccc602d35fad7c51.png
然后在 RAW 包选中 jpg,修改为 aspx 再次查看
c56fc525e7414444330ac0f8a0413cd.png
可以看到图片文件头的几个字节全都变为了ef bf bd(破案万岁),原来的白名单文件头没了故上传 GetShell 不成功。最后通过和同事控制变量法最终得出结论:我不适合挖洞电脑字符集可能有问题。关于这个 UTF-8 字符可以看这篇文章你应该记住的一个 UTF-8 字符「EF BF BD」

解决方法是直接在原始包的 HEX 选中指定字节进行编辑
image.png

所以条条道路通罗马,求知欲和细心是最重要的。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!