Category Archive漏洞挖掘

微软三月份补丁中修复了两个Windows零日漏洞

微软在2019年3月补丁修补了64个漏洞,其中17个漏洞被评为严重。

本月,微软总公司修复了64个漏洞,其中17个被评为严重漏洞,包括其主要产品Windows操作系统中的两个零日漏洞。

第一个windows零日漏洞

第一个零日是谷歌上周公布的。 谷歌表示,这漏洞被滥用于攻击Windows7 32位操作系统的用户。

微软不仅发布了Windows7的补丁程序,而且发布了Windows Server2008系统的补丁程序,这些补丁程序也受到了这个问题的影响——名称为CVE-2019-0808。

根据谷歌上周发布的安全警报,攻击者利用Windows Zero-Day和Chrome Zero-Day逃离Chrome浏览器沙箱,在目标系统上执行恶意代码。

CVE-2019-0808在漏洞攻击链中的作用是,一旦Chrome Zero Day帮助攻击者逃离Chrome安全安全沙箱后,,攻击者就可以使用提升的管理权限执行恶意代码。谷歌也在同一时间发布了新的版本修复了此安全问题。

windows零日漏洞

此外,微软还修补了卡巴斯基研究人员发现的第二个零日,并追踪为CVE-2019-0797。 就像第一个零日漏洞相同,这个零日漏洞是一个特权提升(EoP)漏洞,可以让攻击者以管理员权限运行代码。

“当Win32K组件无法正确处理内存中的对象时,Windows中存在权限提升漏洞,”微软在一份安全公告中表示。 “成功利用此漏洞的攻击者可以在内核模式下运行任意代码。然后,攻击者可以安装程序、查看、更改或删除数据,或创建具有完全用户权限的新帐户。”

这个零日影响所有Windows版本,包括Windows 10操作系统,微软或卡巴斯基都没有透露有关利用这个零日攻击的任何细节。

其他修正 
除了两个零日之外,微软还修复了Windows DHCP客户端中的三个主要漏洞,这些漏洞可能允许远程攻击者接管易受攻击的计算机(CVE-2019-0697,CVE-2019-0698,CVE-2019-0726)。
操作系统制造商最近修补了很多DHCP安全漏洞,在过去的几个月里,几乎每个星期二发布的修补程序中都至少有一个漏洞。

最后但并非最不重要的是,微软还修正了一个补丁,为Windows部署服务(WDS)的错误,它最初修复去年。 此漏洞与Check Point报告的类似WDS漏洞不同。

有关本月修补程序修补的其他漏洞的更多信息,请参见下表:
标签 CVE ID CVE标题
服务堆栈更新 ADV990001 最新的服务堆栈更新
Adobe Flash Player ADV190008 2019年3月Adobe Flash安全更新
微软Windows ADV190009 SHA-2代码签名支持咨询
微软Windows ADV190010 关于跨多个用户共享单个用户帐户的最佳实践
活动目录 CVE-2019-0683 Active Directory特权提升漏洞
天蓝 CVE-2019-0816 Azure SSH密钥对安全功能绕过漏洞
IE浏览器 CVE-2019-0768 Internet Explorer安全功能绕过漏洞
IE浏览器 CVE-2019-0761 Internet Explorer安全功能绕过漏洞
IE浏览器 CVE-2019-0763 Internet Explorer内存损坏漏洞
Microsoft浏览器 CVE-2019-0780 Microsoft浏览器内存损坏漏洞
Microsoft浏览器 CVE-2019-0762 Microsoft浏览器安全功能绕过漏洞
Microsoft Edge CVE-2019-0612 Microsoft Edge Security功能绕过漏洞
Microsoft Edge CVE-2019-0678 Microsoft Edge特权提升漏洞
Microsoft Edge CVE-2019-0779 Microsoft Edge内存损坏漏洞
Microsoft图形组件 CVE-2019-0808 Win32k特权提升漏洞
Microsoft图形组件 CVE-2019-0774 Windows GDI信息泄露漏洞
Microsoft图形组件 CVE-2019-0797 Win32k特权提升漏洞
Microsoft图形组件 CVE-2019-0614 Windows GDI信息泄露漏洞
Microsoft JET数据库引擎 CVE-2019-0617 Jet数据库引擎远程执行代码漏洞
微软办公软件 CVE-2019-0748 Microsoft Office Access连接引擎远程执行代码漏洞
Microsoft Office SharePoint CVE-2019-0778 Microsoft Office SharePoint XSS漏洞
Microsoft脚本引擎 CVE-2019-0592 Chakra Scripting Engine内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0746 Chakra Scripting Engine内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0639 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0783 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0609 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0611 Chakra Scripting Engine内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0666 Windows VBScript引擎远程执行代码漏洞
Microsoft脚本引擎 CVE-2019-0769 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0665 Windows VBScript引擎远程执行代码漏洞
Microsoft脚本引擎 CVE-2019-0667 Windows VBScript引擎远程执行代码漏洞
Microsoft脚本引擎 CVE-2019-0680 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0773 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0770 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0771 脚本引擎内存损坏漏洞
Microsoft脚本引擎 CVE-2019-0772 Windows VBScript引擎远程执行代码漏洞
微软Windows CVE-2019-0603 Windows部署服务TFTP服务器远程执行代码漏洞
微软Windows CVE-2019-0754 Windows拒绝服务漏洞
微软Windows CVE-2019-0765 Comctl32远程执行代码漏洞
微软Windows CVE-2019-0766 Microsoft Windows特权提升漏洞
微软Windows CVE-2019-0784 Windows ActiveX远程执行代码漏洞
Microsoft XML CVE-2019-0756 MS XML远程执行代码漏洞
的NuGet CVE-2019-0757 NuGet包管理器篡改漏洞
Skype for Business CVE-2019-0798 Skype for Business和Lync欺骗漏洞
Team Foundation Server CVE-2019-0777 Team Foundation Server跨站点脚本编制漏洞
视觉工作室 CVE-2019-0809 Visual Studio远程执行代码漏洞
Windows DHCP客户端 CVE-2019-0726 Windows DHCP客户端远程执行代码漏洞
Windows DHCP客户端 CVE-2019-0697 Windows DHCP客户端远程执行代码漏洞
Windows DHCP客户端 CVE-2019-0698 Windows DHCP客户端远程执行代码漏洞
Windows Hyper-V CVE-2019-0695 Windows Hyper-V拒绝服务漏洞
Windows Hyper-V CVE-2019-0690 Windows Hyper-V拒绝服务漏洞
Windows Hyper-V CVE-2019-0701 Windows Hyper-V拒绝服务漏洞
Windows内核 CVE-2019-0702 Windows内核信息泄露漏洞
Windows内核 CVE-2019-0696 Windows内核特权提升漏洞
Windows内核 CVE-2019-0775 Windows内核信息泄露漏洞
Windows内核 CVE-2019-0755 Windows内核信息泄露漏洞
Windows内核 CVE-2019-0767 Windows内核信息泄露漏洞
Windows内核 CVE-2019-0782 Windows内核信息泄露漏洞
Windows内核模式驱动程序 CVE-2019-0776 Win32k信息泄露漏洞
Windows打印后台处理程序组件 CVE-2019-0759 Windows Print Spooler信息泄露漏洞
Windows SMB服务器 CVE-2019-0704 Windows SMB信息泄露漏洞
Windows SMB服务器 CVE-2019-0703 Windows SMB信息泄露漏洞
Windows SMB服务器 CVE-2019-0821 Windows SMB信息泄露漏洞
适用于Linux的Windows子系统 CVE-2019-0689 用于Linux特权提升漏洞的Windows子系统
适用于Linux的Windows子系统 CVE-2019-0682 用于Linux特权提升漏洞的Windows子系统
适用于Linux的Windows子系统 CVE-2019-0694 用于Linux特权提升漏洞的Windows子系统
适用于Linux的Windows子系统 CVE-2019-0693 用于Linux特权提升漏洞的Windows子系统
适用于Linux的Windows子系统 CVE-2019-0692 用于Linux特权提升漏洞的Wind

Microsoft的官方安全更新网站还提供了其他信息,用户可以根据需求查找产品的所需的更新和修补程序。

 

原文链接

所有英特尔处理器面临新的 Spoiler 攻击

去年全球多个行业都被名为幽灵和熔断的高危安全漏洞困扰,然而到现在为止幽灵和熔断漏洞还没有被修复。没修复的同时安全研究人员还在英特尔处理器中发现SPOILER新漏洞,这个漏洞与此前的幽灵熔断漏洞不同。值得注意的是幽灵和熔断漏洞除影响英特尔系列处理器外, ARM和AMD处理器也同样会受到这类漏洞影响。但这次被发现的新漏洞经验证后并不会影响ARM和AMD处理器, 也就是只有英特尔系列处理器才存在问题。

还是推测执行存在的问题:

现代处理器为提高效率都会使用推测执行自动预测和执行命令,但设计层面的漏洞则会让推测执行暴露隐患。SPOILER与去年被曝光的幽灵系列漏洞类似都是推测执行,不同的是这两类漏洞在工作方式上是完全不同的。因为幽灵和熔断漏洞都是现代处理器设计层面出现的缺陷,而SPOILER漏洞则纯粹是英特尔自身存在的弱点。SPOILER发生的根本原因是英特尔专有的内存子系统实现的地址推测存在弱点,这也是只影响英特尔的原因。

现有幽灵熔断缓解措施无法缓解SPOILER漏洞:

幽灵和熔断漏洞是处理器设计层面的问题因此无法通过软件解决,目前厂商提供的解决方案也只能进行缓解。缓解漏洞的措施会影响到处理器性能去年还引发不少争议,不过这类缓解措施也无法缓解SPOILER安全漏洞。研究人员表示这个漏洞涉及新颖的微架构泄露,通过干扰存储缓冲区后采用推测执行不需要任何特殊的权限。

英特尔将继续通过补丁进行缓解:

去年年底英特尔已确认这枚漏洞并向研究人员表示将发布补丁进行修复,但英特尔强调「应该能缓解」漏洞。至少到现在为止英特尔还未发布公开声明因此不确定该漏洞是否可以确定修复,否则也只能打补丁逐渐缓解。研究人员在接受采访时则是表示英特尔的答复非常狡猾,因为涉及内存子系统不能轻易通过微代码进行修复。显然如果通过微代码修复的话对处理器性能又会造成影响,到时候用户和云数据中心厂商估计又是哀嚎一片。

利用上相对来说也不是很容易:

据研究人员表示这枚漏洞想要利用的话需要先进行本地操作,也就是无法直接通过远程的方式直接进行触发。但攻击者可以通过恶意网页的JavaScript 脚本或者预先向用户植入恶意软件,然后再利用SPOILER安全漏洞。成功利用此漏洞可以从内存中窃取机密信息造成用户信息泄露,例如寄存在内存中的密码或者其他敏感信息。

 

原文链接

深入分析MicrosoftOutlook漏洞

Microsoft Outlook是Microsoft Office套件的组件之一,广泛用于发送和接收电子邮件,管理联系人,记录和跟踪日程安排以及执行其他任务。在Windows上运行的多个版本的Outlook中发现了堆崩溃漏洞,涵盖了从Outlook 2010到最新的Outlook 2019以及Office 365 ProPlus的所有32/64位版本的软件。该漏洞可能由格式错误的RWZ文件来触发。当Outlook收到恶意的RWZ文件内容时,它会分配太少的堆内存,并且缺少适当的边界检查,导致堆内存越界写入。

为重现此漏洞,我们需要运行Microsoft Outlook,然后单击“规则=>管理规则和警报=>选项=>导入规则”选择可触发Outlook崩溃的PoC文件。

以下是发生崩溃时,调用堆栈情况:

 

分析漏洞

正如我们从调用堆栈中看到的那样,当堆内存被释放时就发生程序崩溃了。由于我们现在无法确认堆释放时有什么问题,我们可以打开完整的堆内存页表来跟踪堆内存的数据变化。命令如下:

YOUR_WINDBG_INSATALL_LOCATION \ gfl​​ags.exe / p /enable outlook.exe / full

您可以看到以下返回的结果,表明它已成功执行。

完成此操作后,我们可以再次打开Outlook并选择PoC文件以在发生崩溃时监视新堆栈:

现在我们可以看到ECX指向的非0内存地址是不可读的,并且在将数据写入该内存地址时会发生异常。尝试将数据写入未分配(或释放)的内存地址的可能性很高。我们可以通过检查内存页面分配来验证这个预测,在那里我们可以看到内存仍然具有Reserve属性。

我们现在需要弄清楚程序为什么要将数据写入未使用的内存页面。通过静态分析,我们可以看到ECX的值来自EDI,并且EDI在调用MAPIAllocateBuffer之后被修改:

通过静态分析,我们了解到函数MAPIAllocateBuffer是RtlAllocateHeap的封装函数,它检查以确保请求的堆大小参数不大于0x7FFFFFF7。但是,在这种情况下,它不会检查0是否可以用作参数。并且因为实际分配的堆大小比请求的堆大小多8个字节,所以8个字节用0x0000000001000010填充。之后,MAPIAllocateBuffer在这8个字节后返回一个堆地址。因此,调用MAPIAllocateBuffer后的EDI值为8 +从RtlAllocateHeap接收的分配堆地址。

从上面的静态分析中,我们可以大致的预测在Reserve堆中写入数据的原因是由整型溢出引起的。结合调试,我们发现调用MAPIAllocateBuffer的堆大小参数为0.但是,由于MAPIAllocateBuffer请求分配大小为0 + 8 = 8的堆,因此RtlAllocateHeap不会返回错误并成功返回正确的堆地址。但是,MAPIAllocateBuffer使用这8个字节写入0x0000000001000010,然后向用户返回无效的内存地址。

接下来,我们需要弄清楚请求的堆大小的值变为0的原因,结合调试和静态分析,我们发现值0来自当前函数的参数:arg_4(eax = arg_4 * 4 + 4) 。但是,当调用当前函数时,arg_4的值并不是之前传入的参数值,这意味着此arg_4的值被修改了。通过分析我们可以看到值是在子函数sub_65F7DA中被修改的。

对子函数sub_65F7DA分析之后,我们发现它是另一个封装函数。函数是ReadFile ,说明arg_4的值实际上来自PoC文件。

调试显示arg_4读取的文件中的内容为0xFFFFFFFF,因此,由于整型溢出,传递的内存分配大小为0xFFFFFFFF * 4 + 4 = 0。但是,程序没有检查这一点,导致出现了越界写入行为。

检查PoC文件,可以看到0xFFFFFFFF值确实存在。

将其修改为0xAABBCCDD后执行调试,就可以验证溢出是由这4个字节造成的。

通过在Patch发布之后比较程序的汇编代码,我们可以看到现在已经添加了对所请求的分配堆大小的验证。请参见下面的截图:

因此修补程序至关重要,因为成功利用此漏洞的攻击者可以使用特制文件在当前用户的安全context中执行操作。

解决方法

建议存在漏洞的Microsoft Outlook版本的所有用户升级到最新的Outlook版本或立即更新最新的补丁。

 

 

原文链接

Ring Doorbell可以被黑客攻击并显示假图像

在最近推出的补丁中,Ring Doorbell已经修复了自己产品的安全风险 – 因为黑客可以利用此漏洞发起攻击,将假图像内容注入视频源。应该注意的是,虽然Ring会定期发布修复固件,但使用旧版Ring应用程序的客户仍然会面临这种风险。

在发布的一份报告中,BullGuard的Dojo研究人员说明有关该漏洞的详细信息。通过适当的技术手段,任何有权访问传入数据包的人都可以收听实时反馈,而实时反馈并未加强加密。

问题是Ring使用的解决方案没有引用强加密。有权访问目标Wi-Fi的黑客甚至可以在数据到达App之前将虚假内容注入到消息流中。例如,攻击者可以利用此漏洞并将篡改后的图像发送给房主,诱骗他解锁门。

当然,这不是我们第一次听说Ring设备中的安全漏洞。早些时候,有报道称Ring允许客户观看他们的员工视频。对于这个问题,该公司拒绝了媒体的评论请求,声称它不会在官方网站上曝光,并会使用其他安全措施来保护用户的数据安全。

漏洞挖掘之从无到有

作者为团队核心成员:小石

 

挖啊挖 没发现什么漏洞 挖不动啊 发现一处CORS也被限制死域名了

然后有一处api引起了我的注意 这个api是返回订单信息的

https://api.*******.com/api/order/getSellerOrder

有着不少的敏感信息 想着能不能获取到这个数据呢 明显的有CORS但是被限制死了域名

返回的是json格式数据也不是jsonp

那开发人员会不会有种习惯 设计api的时候提供json和jsonp两种格式 而jsonp的函数名变量名就是callback

加多个参数 callback=hijacking试试看

果真变成jsonp了

既然如此 那么别的敏感接口是否也存在这种问题?

测试后发现不存在 继续思考

想到前辈们说过的话 主站不行 可以尝试子域名 子域名防护或许没那么好

果真子域名站点全站均存在问题jsonp劫持并且CORS限制不严格

通过jsonp劫持 能劫持到许多订单信息 然而这个订单信息中有一些是没有直接作用的,比如订单id、用户id、下单时间之类的,暂且放一边不管。

继续挖

 

尝试花了1块钱 租了个号 发现查看上号解锁码的请求是酱紫的

https://aaaa.****.com/zzopen/gameAccount/findOrderAccountInfo?arg={“orderId”:”xx”,”uid”:”xx”}

测试了下此处存在越权 恰好越权所需的两个值可通过上面的jsonp劫持到

这样形成了一个jsonp劫持+越权的组合拳

然后因为使用这web业务的用户少..审核询问我是否可以影响到大量用户,那要大量用户就只能app了,就去看了下app,由于见识短浅没找到什么好的利用方法,仅找到一处url跳转。

app的伪协议是 aaaa://

在APP里面 通过伪协议唤醒APP并打开指定URL是这样的

aaaa://jump/core/web/jump?url=http://doamin.com

由于对url参数未做校验 导致可在APP内置浏览器内跳转到任意域

poc:

打开后唤醒了app并打开了百度

接着走..既然是交易网站 那自然就得多关注关注支付方面的问题了

浏览商品点击购买时 会弹出个二维码 提示用微信扫码下单

生成二维码的时候是这样一个请求 看到请求中传递了价格参数

果断修改成1试试看

扫描修改后的二维码惊讶的发现价格真的变了!!

但是人生就是这么大起大落 点击确认下单后就被打回了原形

之后又到处点啊点 发现了一处疑似是官方出售商品的区域

一个一个商品试啊试 发现这个1元体验4小时吃鸡

一样的是生成二维码扫码购买

这里有个num参数值为4 上面商品描述也是1元体验4小时

那这个4对应的估计就是租用时长 修改成24试试

扫码确认下单 发现价格依旧是1元 支付后发现到期时间就变成了24小时

可以畅玩吃鸡拉

在这个网页版上面 购买商品是通过

网页浏览选中商品 微信扫码购买 后端检测到用户下单网页跳转到等待支付页面 若支付成功再跳转到订单详情处

那在这个环节中 发现即使我未登录 也是可以浏览商品 依然是微信扫码购买

同样的下单后 也会跳转到等待支付处 但是这里已经从未登录状态自动变成了登录状态,后端帮助用户自动进入了登录状态

这种情况下可以通过欺骗用户下单来劫持用户的账号

_________________________________________

重明安全将保持积极分享的态度持续分享

_________________________________________