远程执行代码漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中,当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。 成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。不过我看了一下这个HTTP.SYS还发生过其他的远程代码执行漏洞,我还是表明它的漏洞编号吧。
使用发包工具构造http请求包检测 以fiddler工具为例,构造如下图的请求包:
本章从IIS的历史介绍简述IIS的特性演进和IIS的架构,目的是使读者对IIS有一个初步的认识。让读者了解IIS是什么,能做什么以及IIS的组成部分。
HTTP.sys是Microsoft Windows处理HTTP请求的内核驱动程序,为了优化IIS服务器性能,从IIS6.0引入,IIS服务进程依赖HTTP.sys。HTTP.sys远程代码执行漏洞实质是HTTP.sys的整数溢出漏洞
如果Web服务器操作系统是Windowsserver2003,则IIS6.0进程模型是asp.net的默认选择。其名称明确之处,该模型需要IIS6.0、然后,在windows2003的服务器上,仍然可以让asp.net遵守IIS5.0进程模型的规则。可以通过修改machine.config文件中的<processModel>节,显示的启用该模型。
1.先在tomcat下的conf下找到server.xml文件,用记事本打开后,首先对端口号进行修改,以前一直以为8080是默认的端口号,其实默认的端口号是80
http.sys 是一个位于Win2003和WinXP SP2中的 操作系统核心组件,能够让任何应用程序通过它提供的接口,以http协议进行信息通讯。 温馨提示:如果用户不慎删除了该驱动文件,不用担心,该驱动会在下次系统启动时重建。是一个删不掉的系统核心组件!实用程序结束该驱动,该驱动也会马上重新创建(只有粉碎文件才不能马上重建,但粉碎后,下次启动会重建)。 微软在Windows 2003 Server里引进了新的HTTP API和kernel mode driver Http.sys,目的是使基于Http服务的程序更有效率。这个改变的直接收益者就是IIS 6.0 和 asp.net. 其实在Windows XP安装SP2后,Http.sys已经出现在系统里了,但事实上,操作系统并没有真的使用这个内核级驱动,而XP上自带的IIS 5.1也没有使用HTTP API。 新的HTTP API里最核心的变化都封装在Http.sys这个kernel mode driver里了。在此之前,基于HTTP协议的程序都是在User mode下运行的,而且必须自己处理诸如软件中断、context switch、线程调度等等问题,并且往往无法自由接触系统资源。过去,HTTP服务器,如IIS, Apache等都是利用Winsock API来创建一个User mode下的network listener。Network listener通常独自(i.e.: per application or per thread basis)占用一个IP端口。通俗点说,就是在同一时间只有一个应用程序可以监听一个端口,这在有些时候是一个不太令人舒服的限制。 新的Http.sys带来的好处大致有如下一些: 1. 缓存 - 静态的内容现在被缓存于内核模式下,这使 服务响应速度更快 2. 记录 (Log)-IIS的log功能更快且标准化了 3. 带宽控制 - greater scalability control and throttling 4. 可靠性 - 所有的服务请求会在Http.sys里暂存入队列,而不是由服务程序本身来处理,这样,即使服务程序重启,尚未被处理的请求也不会丢失了 5. IP端口重用 - 现在,只要是通过Http.sys管理的端口(基本包括了那些著名的端口,比如80),都可以同时允许多个程序同时监听了。
其实这是一个之前的漏洞,只是当时编译了一下POC在渗透中利用,并没有写出来=-=。 这次就把POC和测试过程发送出来。据说以前有个作死的舍友安装win2008,在同一个局域网。嗯,蓝屏的,好喝的。 00x1 漏洞原理 首先介绍下HTTP.SYS:HTTP.SYS是微软从IIS6.0开始,为了在Windows平台上优化IIS服务器性能而引入的一个内核模式驱动程序。它为IIS及其他需要运用HTTP协议的微软服务器功能提供HTTP请求的接收与响应、快速缓存、提高性能、日志等功能服务。 更多关于HTTP.SYS的信
HTTP.SYS是Microsoft Windows处理HTTP请求的内核驱动程序,为了优化IIS服务器性能,从IIS6.0引入,IIS服务进程依赖HTTP.SYS。 HTTP.SYS远程代码执行漏洞实质是HTTP.SYS的整数溢出漏洞,当攻击者向受影响的Windows系统发送特殊设计的HTTP 请求,HTTP.sys 未正确分析时就会导致此漏洞,成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。 该漏洞主要存在Windows+IIS的环境下,任何安装了微软IIS 6.0以上的Windows Server 2008 R2/Server2012/Server 2012 R2以及Windows 7/8/8.1操作系统都受到这个漏洞的影响验证这个漏洞。
00x1 windows常见的用户 System 本地机器上拥有最高权限的用户 Administrator 基本是本地机器上拥有最高权限的用户了。 很多朋友一直不明白administrator和System的区别。 system是系统的权限,至少一些注册表的值administrator都读不了,而拥有system权限却可以做到。比如:Windows系统的账号信息,是存放在HKEY_LOCAL_MACHINE\\SAM里的,但是直接打开注册表想去修改却并不能打开它,哪怕你是管理员权限都不行。 因为为了
原文地址:WebListener server for ASP.NET Core By Tom Dykstra, Chris Ross WebListener是一个只能运行在Windows上的ASP.NET Core web服务器,基于Http.Sys内核模块驱动构建。在不借助IIS作为反向代理服务器的情况下,WebListener可以替代Kestrel用来与直接与互联网相连。实际上,WebListener不能和IIS或IIS Express一起使用,这是因为它与ASP.NET Core模块并不兼容。 尽管
在支持的平台上,您可以让IdentityServer使用Windows身份验证(例如,对Active Directory)对用户进行身份验证。 当您使用以下身份托管IdentityServer时,当前Windows身份验证可用: 使用Kestrel在使用IIS和IIS集成包的Windows上 使用HTTP.sys服务器在Windows上 在这两种情况下,通过使用方案“Windows”在HttpContext上使用ChallengeAsync API来触发Windows身份验证。 我们的快速启动用户界面中的帐
Http.sys是Microsoft Windows处理HTTP请求的内核驱动程序。HTTP.sys会错误解析某些特殊构造的HTTP请求,导致远程代码执行漏洞。成功利用此漏洞后,攻击者可在System帐户上下文中执行任意代码。由于此漏洞存在于内核驱动程序中,攻击者也可以远程导致操作系统蓝屏。此次受影响的系统中,Windows7、Windows8、WindowsServer 2008 R2和WindowsServer 2012所带的HTTP.sys驱动均存在一个远程代码执行漏洞,远程攻击者可以通过IIS7(或更高版本)服务将恶意的HTTP请求传递给HTTP.sys驱动,通过发送恶意的HTTP请求导致远程代码执行或操作系统蓝屏。
就在昨天一个大佬被提及面试腾讯的经历,嗯?也就那样吧,很基础。。。。。。。这就是大佬吧,膜拜大佬!然后我好奇的看了一下面试的一些问题,然后其中一个实战问题让我来了兴趣,问如果整站被web.config做了出站限制,在不更改web.config的情况下如何转发?唉,我知道,但是我就不说,我就是玩儿!
场景:内网渗透中,搭建隧道时,服务器仅允许指定的端口对外开放。利用端口复用可以将3389或22等端口转发到如80端口上,以便外部连接。
在2007年9月份,我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章,深入介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制,以及ASP.NET运行时管道对HTTP请求的处理流程: [原创]ASP.NET Process Model之一:IIS 和 ASP.NET ISAPI [原创]ASP.NET Process Model之二:ASP.NET Http Runtime Pipeline - Part I [原创]ASP.NET Process Model之二:ASP.N
我们先来看看IIS 5.x是如何处理基于ASP.NET资源(比如.aspx,.asmx等)请求的,整个过程基本上可以通过图1体现。
IIS 是 Internet Information Services 的缩写,意为互联网信息服务,是由微软公司提供的基于运行 Microsoft Windows 的互联网基本服务。最初是 Windows NT 版本的可选包,随后内置在 Windows 2000 、Windows XP Professional 和 Windows Server 2003 一起发行,但在 Windows XP Home 版本上并没有 IIS 。
2015 年 04 月 14 日,微软发布严重级别的安全公告 MS15-034,编号为 CVE-2015-1635,据称在 Http.sys 中的漏洞可能允许远程执行代码。
<综合评定利用难度>:困难,在无需授权的情况下可以导致远程服务器拒绝服务,但是要实现代码执行比较困难。 <综合评定威胁等级>:高危,在无需授权的情况下即可实现远程拒绝服务甚至可能可以导致远程代码执行。
在2007年9月份,我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章,深入介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制,以及ASP.NET运行时管道对HTTP请求的处理流程:
该端口复用的原理是使用Windows的远程管理服务WinRM,结合 HTTP.sys 驱动自带的端口复用功能,一起实现正向的端口复用后门。
说到端口复用,大部分人第一反应肯定是想到内核驱动,需要对网络接口进行一些高大上的操作才能实现。但只要合理利用操作系统提供的功能,就能以简单的方式实现这一目标,本文将公布一种基于内置系统服务的端口复用后门方法。
更新:似乎在https://piffd0s.medium.com/patch-diffing-cve-2022-21907-b739f4108eee对此漏洞进行了一些初步补丁分析,这似乎表明修补的功能是UlFastSendHttpResponse,UlpAllocateFastTracker UlpFastSendCompleteWorker,UlpFreeFastTracker,和UlAllocateFastTrackerToLookaside。他们还注意到,基于他们的分析a safe assumption may be that the vulnerable code path is hit first in UlFastSendHttpResponse and some of the fixup / mitigations were applied to memory chunks in the other functions。不过分析仍在进行中。
我查阅过不少Asp.Net的书籍,发现大多数作者都是站在一个比较高的层次上讲解Asp.Net。他们耐心、细致地告诉你如何一步步拖放控件、设置控件属性、编写CodeBehind代码,以实现某个特定的功能。
HTTP.SYS是TCP之上的一个网络驱动程序,因此,HTTP.SYS不再属于IIS(这里说的IIS都是IIS6.0+版本,下文如果不特殊指明,默认为IIS6.0+版本),它已经从IIS中独立了出来。 Http.Sys独立有以下几个优点:
如果我们只需要将ASP.NET CORE应用部署到Windows环境下,并且希望获得更好的性能,那么我们选择的服务器类型应该是HTTP.SYS。Windows环境下任何针对HTTP的网络监听器/服务器在性能上都无法与HTTP.SYS比肩。
开篇:ASP.Net是一项动态网页开发技术,在历史发展的长河中WebForm曾一时成为了ASP.Net的代名词,而ASP.Net MVC的出现让这项技术更加唤发朝气。但是,不管是ASP.Net WebForm还是ASP.Net MVC在请求处理机制上大部分都是相同的,只是在请求处理管道上的处理事件做了不同的操作,因此,本文标题不区分ASP.Net WebForm和ASP.Net MVC,但在后续的介绍中会区分开来介绍。此外,本文以IIS经典模式为主,不讨论集成模式(IIS7后加入了集成模式,不用加载外部的aspnet_isapi.dll组件)。
以下漏洞过于硬核又比较相对容易挖掘,毕竟我是实习两年半的低危文档工程师。(可能写的不太全)适合在渗透里面没有找到漏洞,以防尴尬。
作为ASP.NET CORE请求处理管道的“龙头”的服务器负责监听和接收请求并最终完成对请求的响应。它将原始的请求上下文描述为相应的特性(Feature),并以此将HttpContext上下文创建出来,中间件针对HttpContext上下文的所有操作将借助于这些特性转移到原始的请求上下文上。除了我们最常用的Kestrel服务器,ASP.NET CORE还提供了其他类型的服务器。
http.sys是一个位于Win2003和WinXP SP2中的操作系统核心组件,能够让任何应用程序通过它提供的接口,以http协议进行信息通讯。
HTTP 协议堆栈 (HTTP.sys) 中存在一个远程代码执行漏洞,当 HTTP.sys 错误地解析特制 HTTP 请求时,会导致该漏洞。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。
微软已经修补了一个标记为可蠕虫的严重漏洞,该漏洞被发现会影响最新的桌面和服务器 Windows 版本,包括 Windows 11 和 Windows Server 2022。
我收到错误” HTTP错误414。请求URL太长”。 从下面的文章中,我了解到这是由于查询字符串很长所致:
[2] 启动32位应用程序:默认值False,改为True, 否则安装一些32的组建或32位的php都会出错。
2.2、asp.net core web服务器HTTP.sys和Kestrel以及特点
原文地址:ASP.NET Core Module overview By Tom Dykstra, Rick Strahl, and Chris Ross ASP.NET Core模块(ANCM)让你能够在IIS之后运行ASP.NET Core应用,IIS和Kestrel各司其职,前者专于安全性,可管理性等方面,后者专于性能,我们从两种技术中都能获得益处。ANCM只和Kestrel协同工作,它不兼容于Weblistener。 支持的Windows版本: Windows 7和Windows Server 20
ASP.NET与IIS是紧密联系的,由于IIS6.0与IIS7.0的工作方式的不同,导致ASP.NET的工作原理也发生了相应的变化。 IIS6(IIS7的经典模式)与IIS7的集成模式的不同 IIS6
"跨平台"后的ASP.Net Core是如何接收并处理请求的呢? 它的运行和处理机制和之前有什么不同? 本章从"宏观"到"微观"地看一下它的结构以及不同时期都干了些什 本章主要内容如下: ASP.NE
win7安装iis服务 https://jingyan.baidu.com/article/219f4bf723bcb2de442d38ed.html
此版本依赖于 .NET Standard 2.0,可在支持 .NET Standard 2.0 的任何 .NET 版本上运行。这意味着 .NET Framework 4.6.1 以上版本和 .NET Core 2.1 以上版本。它构建在 ASP.NET Core 2.1 之上,并且已经过测试并可以在所有当前支持的 ASP.NET Core 版本上运行,最高可达 5.0。
这是对于服务器系统影响不小的安全漏洞,任何安装了微软IIS 6.0以上的Windows Server 2008 R2/Server 2012/Server 2012 R2以及Windows 7/8/8.1操作系统都受到这个漏洞的影响。
您试图在此 Web 服务器上访问的 Web 应用程序当前不可用。请点击 Web 浏览器中的“刷新”按钮重试您的请求。
"跨平台"后的ASP.Net Core是如何接收并处理请求的呢? 它的运行和处理机制和之前有什么不同? 本章从"宏观"到"微观"地看一下它的结构以及不同时期都干了些什么. ASP.NET Core
4月14日微软发布了一个针对IIS服务器的远程代码执行漏洞补丁,此漏洞危害非常大,远程执行代码漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中,当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。 成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码,若要利用此漏洞,攻击者必须将经特殊设计的 HTTP 请求发送到受影响的系统。 4月16日安恒立即启动了紧急预案,安全研究院团队对此漏洞进行了深入分析,并将研究成果输出到WAF团队,为避免用户在打微软补丁时对业务产生影响
在一般的网络环境中,尽可能避免网络攻击,都会通过防火墙将绝大部分的端口封掉,仅仅保留那些常用的网络服务所用的端口,或者为某一个类应用保留少量的端口。IIS 使用HTTP.SYS实现了对80端口的共享使
每当遇到http错误代码为400,代表客户端发起的请求不符合服务器对请求的某些限制,或者请求本身存在一定的错误。 使用Fiddler2 查看请求发现请求的长度超过了MaxRequestBytes的默认
由于是对内网直接进行大扫描,所以直接判断这不仅是一个 Web 服务器(多个),同时还运行着 FTP、数据库。
在基于TCP/IP协议簇的对等网络通信下,相互通信的应用程序运行各自的进程中,出于应用层的进程将数据局封装成数据报,并通过传输层的TCP或者UDP进行网络通信。而TCP和UPD则通过一个16bit的端口来识别不同的应用程序。
前几天有一个朋友在MSN上问我“ASP.NET 从最初的接收到Http request到最终生成Response的整个流程到底是怎样的?”我觉得这个问题涉及到IIS和ASP.NETASP.NET Runtime的处理模型的问题,并不是三言两语就能说清楚的,所以决定写这样一篇介绍IIS和ASP.NET Runtime Process Model的文章,谈谈我对此的一个粗浅的认识,如果有什么不对的地方,希望大家及时指正。 这篇文章大体分为两个部分,第一部分我将谈谈IIS的两个不同的版本—IIS 5.x 和 II
领取专属 10元无门槛券
手把手带您无忧上云