Aggregator

周六黄历

这一年半的文章合集；感谢"形意门传人"师傅的投稿

Jessica Scherlag discusses the importance of social media platforms, her unconventional career path, and the benefits of pushing past your comfort zone.

人是网络世界中最大的BUG……

让虚拟世界不再虚拟

1.热点事件：《美国政府分享疑似Conti组织嫌疑人的照片》；2.能源行业：《乌克兰国有核电运营商声称遭到俄罗斯黑客攻击》；3.高级威胁：《Lazarus APT组织近期不断攻击加密货币行业》

React 是一个由 Facebook 开源的、可以在任意平台上构建 UI 的 JavaScript 库。在 React 中，一个常见的 Pattern 是使用 useEffect 搭配 useState 发送请求、将状态从 API（React 外部）同步到 React 内部、用于渲染 UI，这篇文章恰恰在向你介绍为什么你不应该直接这么做。

通过Java AgentNoFile方式植入的内存马，整个过程中不会有文件在磁盘上落地，而且不会在JVM中新增类，甚至连方法也不会增加。它就像inline hook一样无色无味。

​2021年，FBI网络犯罪投诉中心（IC3）陆续收到847,376份投诉，潜在损失超过69亿美元。我们灵魂翻译了FBI《网络犯罪报告2021》报告的主要威胁部分，以便更好了解不断变化的网络犯罪趋势。

我眼中的红队

碎语闲谈，作为一名多年的十八线红队选手一直想写一篇文章来总结下“我眼中的红队”，之前写过一点，因文笔拙劣遂删除，起本文重写。

什么是红队

现如今是数字化时代，万物联网创造了一个新的空间，即网络空间，网络空间的安全也上升到了国家安全层面，并且网络已经成为国家继海、陆、空、天之后的第五大主权领域空间。

正是如此，网络空间也就如传统领域空间一样，需要通过演习对抗的模式，提升网络安全防御能力，以攻促防，知攻善防。

攻防双方在演习中通常称之为红队（Red Team）和蓝队（Blue Team），红队（Red Team）即攻击方，穷尽方法攻击以达到获取演习靶标权限的目的。

红队攻击流程

红队的攻击流程大致分为4个步骤，分别是制定战术、外网打点、内网横向、结果报告。

制定战术：根据演习规则及目标结合自身优点制定攻击战术，以保证演习过程不盲目、不混乱，有条不紊的完成演习；

外网打点：通过漏洞、供应链、社工、近源等手段对目标暴露面进行攻击，以此打开进入目标内网的入口；

内网横向：通过信息收集、分析、关联，结合相关漏洞及密码对内网可达网段机器进行横向攻击，以此发现更多脆弱点或接近内网的演习靶标；

结果报告：将红队攻击过程、所涉技术手段、攻击痕迹等信息进行整理，形成文档提交至演习平台，并且便于后续复盘。

红队成员结构

通常在攻防演习中，主办方都是要求现场红队成员有三位，按照我的理解这三位应该是：队长、渗透师、横向师。

队长：技术综合能力较强，具备较好的团队协作、组织、应变、沟通能力，能有条理的安排演习任务，并且在演习结果上报后有争议时与裁判进行沟通；

渗透师：前渗透能力较强，也就是侧重于信息收集、Web漏洞黑盒挖掘及代码审计能力，在拿到目标信息后能够快速的找到脆弱资产，撕开暴露面入口以供后渗透；

横向师：后渗透能力较强，也就是侧重于木马免杀、权限维持及漏洞利用能力，当具有暴露面入口时能够通过它对内网进行持续性的脆弱点发现。

当然，目标往往是美好的，现实却是残酷的，在演习中真正的红队成员都应该具备这三种能力，才能应对这万变的局面。

红队基础设施

红队的基础设施，我将其分为三大块：人员、武器库、漏洞库。

人员：万事皆以人为本，红队的基础设施也离不开人，优秀的伙伴可以让你在演习过程中更舒心，而人员通常是最难解决的，大部分都是通过外部招聘的形式引入技术人才，或培养初入职场的学生；

武器库：武器库在我的理解中，就是一切皆自动化或自主化，信息收集、邮件钓鱼、木马免杀的自动化，以及C2、Webshell管理工具的自主化，这都是最基础的一些；

漏洞库：漏洞库即0day、1day这些漏洞的利用，例如SQL注入不应只是注入，而是要结合SQL注入直接获取目标站点权限，无论你是结合SQL注入获取密码再进入后台进行文件上传获取权限，还是SQL注入直接堆叠执行命令获取权限，简而言之，漏洞只是开始，通过漏洞获取权限才是漏洞库所需要的，这也是大家通常所说的漏洞武器化。

红队结果复盘

在进行一场演习之后，红队应结合演习结果进行复盘，主要围绕这几个方面：演习结果的总结、红队成员的分工、演习过程的问题。

演习结果的总结：对演习上报的结果进行总结，梳理出攻击技术及相关路径；

红队成员的分工：明确每个成员的分工，并且结合成果来看分工的落实程度；

演习过程的问题：总结演习过程中发现的问题，找出问题产生的原因，有解决方案的提出解决方案，没有的就复盘会上进行交流。

Hi, this is my fifth time speaking at Black Hat USA and DEFCON. You can get the slide copy and video there:

• Let’s Dance in the Cache - Destabilizing Hash Table on Microsoft IIS (slides)
• Let’s Dance in the Cache - Destabilizing Hash Table on Microsoft IIS (video - TBD)

As the most fundamental Data Structure in Computer Science, Hash Table is extensively used in Computer Infrastructures, such as Operating Systems, Programming Languages, Databases, and Web Servers. Also, because of its importance, Microsoft has designed its own Hash Table algorithm from a very early stage, and applied it heavily to its web server, IIS.

Since IIS does not release its source code, I guess the algorithm implementation details should be an unexplored area to discover bugs. Therefore, this research mainly focuses on the Hash Table implementation and its usage. We also look into the Cache mechanism because most of the Hash Table usages in IIS are Cache-Related!

Because most of the details are in the slides, please forgive me this time for this brief write-ups instead of a full blog.

• CVE-2022-22025 - Microsoft IIS Hash-Flooding DoS
• CVE-2022-22040 - Microsoft IIS Cache Poisoning Attack
• CVE-2022-30209 - Microsoft IIS Authentication Bypass

P.S. All vulnerabilities addressed in this blog have been reported responsibly to Microsoft and patched in July 2022.

1. IIS Hash-Flooding DoS

It’s hard to imagine that we can still see such a classic Algorithmic Complexity Attack as Hash-Flooding Attack in IIS in 2022. Although Microsoft has configured a thread deleting outdated records every 30 seconds to mitigate the attack, we still found a key-splitting bug in the implementation to amplify our power by over 10 times to defeat the guardian by zero hashes. Through this bug we can make a default installed IIS Server unresponsive with about 30 connections per second!

Because this bug also qualifies for the Windows Insider Preview Bounty Program, we also rewarded $30,000 for this DoS. This is the maximum bounty for the category of Denial-of-Service!

You can check the full demo video here:

2. IIS Cache Poisoning Attack

Compared with other marvelous Cache Poisoning research, this one is relatively plain. The bug is found in the component of Output Caching, the module responsible for caching dynamic responses to reduce expensive database or filesystem access on web stacks.

Output Caching uses a bad Query String parser that only takes the first occurrence as the Cache-Key when Query String keys are duplicated. This behavior is actually not a problem independently. However, it’s a trouble in the view of the whole architecture with the backend, ASP.NET. The backend concatenates the value of all repeated keys together, which leads to an inconsistency between parser behaviors. Therefore, a classic HTTP Parameter Pollution can make IIS cache the wrong result!

3. IIS Authentication Bypass

This may be the most interesting bug of this talk. LKRHash is a Hash Table algorithm designed and patented by Microsoft in 1997. It’s based on Linear Hashing and created by Paul Larson of Microsoft Research, Murali Krishnan and George Reilly of the IIS team.

LKRHash aims to build a scalable and high-concurrent Hash Table under the multithreading and multi-core environment. The creators put a lot of effort into making this implementation portable, flexible and customizable to adapt to multiple products across Microsoft. An application can define its own Table-Related functions, such as the Hash Function, the Key Extracting Function, or the Key Comparing Function. This kind of extensibility creates a bunch of opportunities for vulnerability mining. So, under this context, we cares more about the relationship between the records, the keys, and the functions.

CLKRHashTable::CLKRHashTable( this, "TOKEN_CACHE", // An identifier for debugging pfnExtractKey, // Extract key from record pfnCalcKeyHash, // Calculate hash signature of key pfnEqualKeys, // Compare two keys pfnAddRefRecord, // AddRef in FindKey, etc 4.0, // Bound on the average chain length. 1, // Initial size of hash table. 0, // Number of subordinate hash tables. 0 // Allow multiple identical keys? );

Because “Logon” is an expensive operation, to improve the performance, IIS cached all tokens for password-based authentications, such as Basic Authentication by default, and the bug we found this time is located in the logic of the key-comparing function when a collision occurs.

If a login attempt whose hash hits a key that is already in the cache, LKRHash enters the application-specific pfnEqualKeys function to determine whether the key is correct or not. The application-specific logic of TokenCacheModule is as follows:

As the logic compares several parts to make the decision, it’s weird why IIS compares the username twice.

I guess the original intent was to compare the password. However, the developer copy-and-pasted the code but forgot to replace the variable name. That leads to that an attacker can reuse another user’s logged-in token with random passwords.

To build the smallest PoC to test your own, you can create a testing account and configure the Basic Authentication on your IIS.

# add a test account, please ensure to remove that after testing > net user orange test-for-CVE-2022-30209-auth-bypass /add # the source of login is not important, this can be done outside IIS. > curl -I -su 'orange:test-for-CVE-2022-30209-auth-bypass' 'http://<iis>/protected/' | findstr HTTP HTTP/1.1 200 OK

Under the attacker’s terminal:

# script for sanity check > type test.py def HashString(password): j = 0 for c in map(ord, password): j = c + (101*j)&0xffffffff return j assert HashString('test-for-CVE-2022-30209-auth-bypass') == HashString('ZeeiJT') # before the successful login > curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP HTTP/1.1 401 Unauthorized # after the successful login > curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP HTTP/1.1 200 OK

As you can see, the attacker can log into the user orange with another password whose hash is the same as the original one.

However, it’s not easy to collide the hash. The probability of each attempt is only worth 1/2^32 because the hash is a 32-Bit Integer, and the attacker has no way to know the hash of existing cache keys. It’s a ridiculous number to make exploiting this bug like playing a lottery. The only pro is that the attempt costs nothing, and you have unlimited tries!

To make this bug more practical, we proposed several ways to win the lottery, such as:

1. Increase the odds of the collision - LKRHash combined LCGs to scramble the result to make the hash more random. However, we can lower the key space because the LCG is not one-to-one mapping under the 32-Bit Integer. There must be results that will never appear so that we can pre-compute a dictionary that excludes the password whose hash is not in the results and increase the success rate by 13% at least!
2. Regain the initiative - By understanding the root cause, we brainstorm several use cases that can cache the token in memory forever and no longer wait for user interaction, such as the IIS feature Connect As or leveraging software design patterns.

We have also proved this attack works naturally on Microsoft Exchange Server. By leveraging the default activated Exchange Active Monitoring service, we can enter HealthMailbox’s mailbox without passwords! This authentication-less account hijacking is useful for further exploitations such as phishing or chaining another post-auth RCE together!

Timeline

• Mar 16, 2022 - We reported the IIS Cache Poisoning to Microsoft through the MSRC portal.
• Apr 09, 2022 - We reported the IIS Hash-Flooding DoS to Microsoft through the MSRC portal.
• Apr 10, 2022 - We reported the IIS Authentication Bypass to Microsoft through the MSRC portal.
• Jul 12, 2022 - Microsoft fixed everything at July’s Patch Tuesday.

Planning a multi-factor authentication (MFA) rollout? Take a look at the six lessons we learned when we deployed Akamai MFA.

我刚提的新杀软啊！

安全市场的机遇很多，当前市场不大以及增速不大的原因还是因为没有向外拓展更广泛的市场空间，大家都拥挤在传统的狭小赛道当中，没有在新的领域去突破创新，更没有认真思考如何让安全融入业务、成为业务、让安全创造价值。

背景在 全流量入侵检测系统的性能分析 中提到"包解析需要高性能"这个需求场景，和 pf_ring、dpdk

Disclaimer: Nothing in this blog is related to the author’s day-to-day work. The content is neither affiliated nor sponsored by any companies.

摸鱼打了个DASCTF July，主要看了看Web和Misc题目，大部分是结束后边做边写的，写得还是挺详细的吧，当然也少不了走弯路的地方。

通常情况下获得Java Webshell碰到数字杀毒的场景居多，在这个环境中经常会遇到无法执行命令或命令被拦截的情况，很多小伙伴遇到这个问题就劝退了，我猜测是有一套进程链的检测方式导致了命令无法执行.....................

前言传输协议工作流程实例演示本地远程本地远程加密算法解密算法即时验证本地验证远程验证生成服务端分享和导入总结

“看见”的能力始终伴随着“不看见”的能力，正如“太极”的两部分。什么是看见？看见一片大海、一片星空、一片沙漠，是看见吗？正是由于有选择的不看见的能力，忽略过滤排除筛选，去除大量无效信息，才能拨云...