399 lines
24 KiB
Markdown
399 lines
24 KiB
Markdown
|
# 明阳研究院面试题
|
|||
|
|
|
|||
|
|
#### 1、怎么区分安全设备是不是误报
|
|||
|
|
|
|||
|
|
**以下几个方面进行判断：**
|
|||
|
|
|
|||
|
|
1. 报警信息的详细程度：
|
|||
|
|
- 查看报警的具体信息，包括攻击类型、攻击源、攻击目标、使用的协议和端口等。如果信息非常模糊或者缺乏具体的攻击细节，可能需要进一步核实。
|
|||
|
|
2. 报警源的可靠性：
|
|||
|
|
- 评估报警来源的可靠性。一些知名的安全设备或服务提供商通常会有较为严格的报警生成机制，误报率相对较低。
|
|||
|
|
3. 报警的频率：
|
|||
|
|
- 如果同一类型的报警频繁发生，需要检查是否为误报。但也可能是受到了持续攻击，需要结合实际情况判断。
|
|||
|
|
4. 与已知威胁情报对比：
|
|||
|
|
- 将报警信息与已知的威胁情报进行对比，看是否有匹配的已知攻击模式或恶意行为。
|
|||
|
|
5. 系统的安全状态：
|
|||
|
|
- 检查系统的日志和安全状态，看是否有异常的登录尝试、文件更改或其他异常行为。
|
|||
|
|
6. 实地调查：
|
|||
|
|
- 对报警涉及的系统和网络进行实地调查，包括检查系统日志、网络流量分析等。
|
|||
|
|
7. 规则和签名更新：
|
|||
|
|
- 确保安全设备中的规则和签名是最新的。过时的规则可能导致误报。
|
|||
|
|
8. 专家分析：
|
|||
|
|
- 如果无法自行判断，可以求助于安全专家或第三方安全服务提供商进行分析。
|
|||
|
|
|
|||
|
|
**以下是一些具体的步骤：**
|
|||
|
|
|
|||
|
|
- 确认安全设备配置：确保安全设备配置正确，没有设置过于敏感的规则。
|
|||
|
|
- 查看日志：检查系统日志，确认是否有与报警相关的可疑活动。
|
|||
|
|
- 复现测试：尝试复现报警条件，看是否能够稳定触发。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 2、如果存在挖矿，怎么进行研判
|
|||
|
|
|
|||
|
|
1. **监控系统资源使用情况**：
|
|||
|
|
- CPU使用率：挖矿软件通常会占用大量的CPU资源。可以通过系统监控工具（如Windows的任务管理器、Linux的top或htop命令）来检查CPU使用率是否长时间异常高。
|
|||
|
|
- 内存使用情况：虽然挖矿主要依赖CPU或GPU，但也可能伴随较高的内存使用。
|
|||
|
|
- 网络流量：挖矿程序可能会产生异常的网络流量，尤其是与已知挖矿池的通信。
|
|||
|
|
2. **检查进程和任务**：
|
|||
|
|
- 使用进程管理工具（如Windows的任务管理器、Linux的ps命令）检查是否存在可疑的进程。
|
|||
|
|
- 查看任务的命令行参数，挖矿软件通常会有特定的命令行参数。
|
|||
|
|
3. **分析网络连接**：
|
|||
|
|
- 使用网络连接监控工具（如netstat命令）检查服务器上异常的外部连接，特别是连接到已知挖矿池的端口。
|
|||
|
|
- 检查防火墙规则和出入流量记录，看是否有异常的对外连接。
|
|||
|
|
4. **日志审计**：
|
|||
|
|
- 审计系统日志，查找异常的登录行为、系统文件修改等。
|
|||
|
|
- 安全日志中可能记录了挖矿软件的安装和运行痕迹。
|
|||
|
|
5. **使用专门的检测工具**：
|
|||
|
|
- 安装安全软件或使用专门的挖矿检测工具来扫描系统。
|
|||
|
|
- 有些安全厂商提供了免费的在线扫描服务，可以帮助检测系统是否感染了挖矿恶意软件。
|
|||
|
|
6. **系统行为分析**：
|
|||
|
|
- 分析系统的行为是否与往常不同，比如系统运行缓慢、响应时间长等。
|
|||
|
|
- 挖矿软件可能会修改系统配置，如启动项、计划任务等，以实现开机自启。
|
|||
|
|
7. **与正常运行时的基线对比**：
|
|||
|
|
- 建立服务器正常运行时的资源使用基线，任何与基线明显偏离的行为都值得进一步调查。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 3、哥斯拉webshell流量特征
|
|||
|
|
|
|||
|
|
1. **WebShell上传特征**
|
|||
|
|
|
|||
|
|
- 先看JAVA的，主要原理和冰蝎的差不多。关键在于加密、类加载和反射，可以提取关键操作的代码作为静态检测的特征，如：
|
|||
|
|
AES加/解密：javax.crypto.Cipher.getInstance(“AES”)
|
|||
|
|
类加载：ClassLoader
|
|||
|
|
反射：Class.forName
|
|||
|
|
- C#的webshell核心在于使用Assembly来动态解析执行已编译的DLL二进制文件，以及流量加密。使用Assembly的特征为System.Reflection.Assembly，实现加/解密：System.Security.Cryptography.RijndaelManaged()
|
|||
|
|
- PHP没有沿用AES加密的流量，而是通过异或实现自定义的加密，并且直接使用eval函数进行代码执行。
|
|||
|
|
|
|||
|
|
2. **WebShell通信特征**
|
|||
|
|
|
|||
|
|
- User-Agent (弱特征)
|
|||
|
|
|
|||
|
|
> 哥斯拉客户端使用JAVA语言编写，在默认的情况下，如果不修改User-Agent，User-Agent会类似于Java/1.8.0_121（具体什么版本取决于JDK环境版本）。但是哥斯拉支持自定义HTTP头部，这个默认特征是可以很容易去除的。
|
|||
|
|
|
|||
|
|
- Accept（弱特征）
|
|||
|
|
|
|||
|
|
> 哥斯拉的作者应该还没有意识到，在请求包的Cookie中有一个非常致命的特征，最后的分号。标准的HTTP请求中最后一个Cookie的值是不应该出现;的，这个可以作为现阶段的一个辅助识别特征。后面如果作者意识到这个问题的话应该会发布新版本修复这个问题。
|
|||
|
|
|
|||
|
|
- 请求体特征 (较强特征)
|
|||
|
|
|
|||
|
|
> 因为无法准确识别加密的请求体，所以只能采用比较宽泛的匹配条件去匹配请求体特征，宽泛的匹配思路其实就是基于区别大部分正常的数据包，加密数据包自身体现的特征。这种宽泛的匹配在一些情况下可能会带来误报，因此有时候难以作为一种非常有效的检测手法。
|
|||
|
|
>
|
|||
|
|
> 哥斯拉支持对加密的数据进行base64编码以及原始的加密raw两种形式的通讯数据，对于请求体的检测也要考虑两种情况。
|
|||
|
|
>
|
|||
|
|
> 首先看一下base64编码的数据包，对于这种数据包唯一的识别方法就是识别流量中的base64编码。当然不能仅仅去识别数据包中存在base64编码就拦截，因为很多应用正常的参数也会采用base64编码加密。哥斯拉在进行初始化时会产生一个比较大的数据包，后面进行命令执行等操作时产生的base64数据包会比较比较小。在长度上做一个匹配条件在一定程度上也可以降低误报率。
|
|||
|
|
>
|
|||
|
|
>
|
|||
|
|
> 对于原始加密raw请求体，没想到比较好的方法，目前只想到到了匹配较多的不可见字符的思路。同样的，这种检测方法也会产生误报，像一些对传输安全要求比较高的金融机构，不少应用也会实现一些加密的通讯流量。需要注意的是，在匹配不可见字符时，需要排除文件上传，也就是multipart/form-data数据包，因为文件上传的流量也会包含大量的不可见字符。
|
|||
|
|
|
|||
|
|
- 响应体特征 (强特征)
|
|||
|
|
|
|||
|
|
> 和请求体一样，请求响应体也分两个格式，base64编码的和原始加密raw数据。如果请求体采用base64编码，响应体返回的也是base64编码的数据。在使用base64编码时，响应体会出现一个很明显的固定特征。这个特征是客户端和服务端编写的时候引入的。
|
|||
|
|
>
|
|||
|
|
> 从代码可以看到会把一个32位的md5字符串按照一半拆分，分别放在base64编码的数据的前后两部分。整个响应包的结构体征为：md5前十六位+base64+md5后十六位。
|
|||
|
|
>
|
|||
|
|
> 从响应数据包可以明显看到这个特征，检测时匹配这个特征可以达到比较高的检出率，同时也只可以结合前面的一些弱特征进行检查，进一步提高检出率。因为md5的字符集范围在只落在0123456789ABCDEF范围内，因此很容易去匹配，正则匹配类似于(?i:[0-9A-F]{16})[\w+/]{4,}=?=?(?i:[0-9A-F]{16})。需要注意的是md5需要同时匹配字母大小写两种情况，因为在JAVA版webshell响应中为大写字母，在PHP版中为小写字母。
|
|||
|
|
>
|
|||
|
|
> 但是比较遗憾的是对于原始加密数据的raw形式响应包并没有比较好的检测思路，只能和请求体检测一样，匹配不可见字符。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 4、常见中间件
|
|||
|
|
|
|||
|
|
IIS:
|
|||
|
|
|
|||
|
|
> IIS6.0 PUT漏洞 IIS6.0 远程代码执行漏洞 IIS6.0 解析漏洞 IIS启用.net 短文件名漏洞 IIS7.0/7.5 解析漏洞
|
|||
|
|
|
|||
|
|
Apache:
|
|||
|
|
|
|||
|
|
> 未知扩展名解析漏洞 配合错误导致的解析漏洞、目录遍历
|
|||
|
|
|
|||
|
|
Nginx：
|
|||
|
|
|
|||
|
|
> 配置错误导致的解析漏洞、目录遍历
|
|||
|
|
|
|||
|
|
Tomcat:
|
|||
|
|
|
|||
|
|
> 配置错误导致的任意代码执行、任意文件写入漏洞 弱口令+管理后台war包部署getshell manager/html 管理后台弱口令爆破
|
|||
|
|
|
|||
|
|
JBoss:
|
|||
|
|
|
|||
|
|
> 5.x/6.x反序列化漏洞（CVE-2017-12149） JMXInvokerServlet反序列化 EJBInvokerServlet反序列化 JMX Console未授权访问 弱口令+管理后台war包部署getshell
|
|||
|
|
|
|||
|
|
WebLogic:
|
|||
|
|
|
|||
|
|
> XMLDecoder 反序列化漏洞（CVE-2017-10271 & CVE-2017-3506） wls9_async_response,wls-wsat 反序列化远程代码执行漏洞（CVE-2019-2725） WLS Core Components 反序列化命令执行漏洞（CVE-2018-2628） 弱口令+管理后台war包部署getshell
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 5、SQL注入分类
|
|||
|
|
|
|||
|
|
> [SQL 注入详解：原理、危害与防范措施_sql注入 原理、风险及预防-CSDN博客](https://blog.csdn.net/2301_77163982/article/details/143780864)
|
|||
|
|
|
|||
|
|
1. **基于错误的信息泄露**
|
|||
|
|
|
|||
|
|
> 攻击者通过触发数据库错误，分析错误消息来推断数据库结构，进而构建更复杂的攻击。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
SELECT * FROM users WHERE username = 'admin' AND password = 'wrong_password';
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
2. **联合查询注入**
|
|||
|
|
|
|||
|
|
> 攻击者利用UNION操作符将额外的查询附加到原查询上，以获取额外的信息。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
SELECT * FROM users WHERE username = 'admin' UNION SELECT * FROM sensitive_data;
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
3. **盲注**
|
|||
|
|
|
|||
|
|
- 基于布尔响应的盲注
|
|||
|
|
|
|||
|
|
> 攻击者通过发送不同的查询并观察应用程序的响应来推断数据库内容。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
SELECT * FROM users WHERE username = 'admin' AND password = 'password' AND '1'='1';
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- 基于时间延迟的盲注
|
|||
|
|
|
|||
|
|
> 攻击者通过在查询中引入时间延迟来判断数据库的响应时间，从而推断数据库内容。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
SELECT * FROM users WHERE username = 'admin' AND password = 'password' AND SLEEP(5);
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
4. **基于带外的注入**
|
|||
|
|
|
|||
|
|
> 攻击者利用数据库的功能，如HTTP请求或文件写入，将数据发送到外部服务器，从而泄露信息。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
SELECT * FROM users WHERE username = 'admin' AND password = 'password' INTO OUTFILE '/tmp/data.txt';
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 6、XSS分类
|
|||
|
|
|
|||
|
|
> [XSS 的三种类型及区别_xss三种类型的区别-CSDN博客](https://blog.csdn.net/m0_57836225/article/details/142833490)
|
|||
|
|
|
|||
|
|
1. **反射型 XSS（非持久型 / 参数型）**
|
|||
|
|
|
|||
|
|
- 定义：反射型 XSS 也被称为非持久型或参数型跨站脚本攻击。其恶意代码并没有保存在目标网站，而是通过诱导用户点击一个包含恶意链接的 URL 来实施攻击。
|
|||
|
|
- 案例：
|
|||
|
|
- 发送一个恶意链接给别人，当别人点击该链接访问目标网站时，会出现弹窗。例如：“我这边有这样的一个链接，把这个链接发给别人，别人访问一下就会有一个弹窗。
|
|||
|
|
- 在网页上输入一段 JS 脚本代码并提交，会有一个弹窗，但这一次执行完后就没有了。例如：“我们在这边输入一个随便输入一个东西，然后输入一段JS 脚本，提交哎它会有一个弹窗，这一次执行完后就没有了，所以也叫做非持久型。
|
|||
|
|
- 处理方式：由后端进行处理。
|
|||
|
|
- 恶意代码存储位置：恶意代码存在 URL 里。
|
|||
|
|
|
|||
|
|
2. **存储型 XSS（持久型）**
|
|||
|
|
|
|||
|
|
- 定义：存储型 XSS 也被称为持久型跨站脚本攻击。其恶意代码会存储在目标网站的服务器端，比如数据库或特定的文件中。
|
|||
|
|
|
|||
|
|
- 案例：在留言区输入恶意代码，这些代码会存储在服务器端的文档（如 message.txt）中。当有人访问该页面时，就会加载恶意代码并执行弹窗。
|
|||
|
|
|
|||
|
|
例如：在我们的一个留言区留言，它会存在我们的一个服务器端，在我这里呢就是写了一个文档，它这边会存在这个 message.txt 里面，只要有人访问到了这样的一个页面的时候，它就会加载我们的恶意恶意代码，就会执行这样的一个弹窗，所以它是一个持久型的。
|
|||
|
|
|
|||
|
|
- 处理方式：由后端进行处理。
|
|||
|
|
|
|||
|
|
- 恶意代码存储位置：存在服务器端。
|
|||
|
|
|
|||
|
|
3. **DOM 型 XSS**
|
|||
|
|
|
|||
|
|
- 定义：DOM 型 XSS 是通过修改网页的 DOM 节点形成的 XSS 攻击。所有的处理都是通过前端来进行的，前端可以直接修改 DOM 节点。
|
|||
|
|
- 案例：在输入框中输入 “AAA” 和一段 JavaScript 脚本代码并提交，不会出现弹窗。而要在 URL 上输入回车才能触发弹窗。例如：“我们在这边输入一个 AAA，他就是一个 name AAA，在这里同样的输入一串 JavaScript 脚本代码提交诶，发现它并不会给我们进行一个弹窗，而我们的 DOM 型它是要在这边，在 URL 上输入回车，它就能够进行一个弹窗。”
|
|||
|
|
- 处理方式：由前端浏览器完成。
|
|||
|
|
- 恶意代码存储位置和执行位置：取出和执行恶意代码都是由前端的浏览器完成的，属于前端 JavaScript 自身的安全漏洞。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 7、反射性XSS与存储型XSS区别
|
|||
|
|
|
|||
|
|
- 处理位置：
|
|||
|
|
- 反射型和存储型 XSS 的恶意代码是经过后端脚本语言处理的，由后端进行处理。
|
|||
|
|
- DOM 型 XSS 是通过前端浏览器进行处理的。
|
|||
|
|
- 恶意代码存储位置：
|
|||
|
|
- 反射型 XSS 的恶意代码存在 URL 里。
|
|||
|
|
- 存储型 XSS 的恶意代码存在服务器端。
|
|||
|
|
- DOM 型 XSS 的取出和执行恶意代码都是由前端的浏览器完成的。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 8、管理员登录界面容易有有哪些漏洞
|
|||
|
|
|
|||
|
|
在后台登录管理界面中存在的一些常见漏洞包括：
|
|||
|
|
|
|||
|
|
1. 弱密码：管理员账户使用弱密码，如简单的数字、字母组合或者常见的密码，容易被猜解或破解。
|
|||
|
|
2. SQL注入：如果登录界面没有对用户输入进行严格的验证和过滤，攻击者可以通过构造恶意的SQL语句来绕过认证，直接登录到后台。
|
|||
|
|
3. XSS攻击：如果登录界面没有对用户输入进行适当的过滤和转义，攻击者可以在登录表单中注入恶意脚本，当管理员登录时执行该脚本，从而窃取管理员的登录凭证。
|
|||
|
|
4. CSRF攻击：如果登录界面没有使用合适的防跨站请求伪造（CSRF）机制，攻击者可以伪造一个恶意网页，诱使管理员点击其中的链接或按钮，以执行未经授权的操作，如修改管理员密码。
|
|||
|
|
5. 不安全的会话管理：后台登录界面没有适当地管理会话，如未设置合理的会话超时时间、未使用HTTPS等，可能导致会话劫持或会话固定等攻击手段。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 9、是否熟悉天眼
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 10、熟悉那些态感设备
|
|||
|
|
|
|||
|
|
- **入侵检测/防御系统（IDS/IPS）**：用于监控和分析网络流量，以识别和阻止潜在的攻击。
|
|||
|
|
- **SIEM系统**：它能够帮助安全团队收集、监控和分析来自多个源的安全事件，以提供实时的威胁检测。
|
|||
|
|
- **安全运营中心（SOC）平台**：通过整合各种安全工具，提供对网络安全的全面监控。
|
|||
|
|
- **端点检测与响应（EDR）工具**：专注于端点保护，能够检测并响应高级威胁。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 11、了解Javaweb吗？
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 12、攻击告警如何判断是否为真实有效攻击事件
|
|||
|
|
|
|||
|
|
1. **告警信息收集**：
|
|||
|
|
- 收集告警日志、系统日志、网络流量数据等相关信息。
|
|||
|
|
- 确定告警的类型（如DDoS攻击、SQL注入、病毒感染等）。
|
|||
|
|
2. **初步分析**：
|
|||
|
|
- 分析告警的来源、目标和时间等信息。
|
|||
|
|
- 检查是否存在已知的误报模式。
|
|||
|
|
3. **确认攻击模式**：
|
|||
|
|
- 对比已知的攻击模式，确认告警是否与已知攻击特征相匹配。
|
|||
|
|
- 分析攻击的频率、规模和特征，是否符合恶意攻击的行为模式。
|
|||
|
|
4. **影响评估**：
|
|||
|
|
- 判断告警事件是否对系统正常运行造成了影响。
|
|||
|
|
- 评估潜在的损害程度，如数据泄露、服务中断等。
|
|||
|
|
5. **工具辅助分析**：
|
|||
|
|
- 使用入侵检测系统（IDS）、安全信息和事件管理（SIEM）等安全工具进行辅助分析。
|
|||
|
|
- 运用反病毒软件、威胁情报平台来验证告警的真实性。
|
|||
|
|
6. **实时监控**：
|
|||
|
|
- 对告警相关的系统和网络进行实时监控，观察攻击行为是否持续或变化。
|
|||
|
|
- 分析攻击者的行为轨迹，如攻击是否尝试在不同点突破防线。
|
|||
|
|
7. **交叉验证**：
|
|||
|
|
- 与其他安全设备或系统的日志进行交叉验证，查看是否存在一致性。
|
|||
|
|
- 参考同行业内其他组织是否报告了类似攻击。
|
|||
|
|
8. **人工审核**：
|
|||
|
|
- 由专业的安全分析师对告警进行人工审核。
|
|||
|
|
- 结合专业知识判断告警的真实性。
|
|||
|
|
9. **应急响应**：
|
|||
|
|
- 如确认攻击事件为真实，应立即启动应急响应计划。
|
|||
|
|
- 进行隔离、止损、恢复等操作，并保留证据。
|
|||
|
|
10. **后续跟踪**：
|
|||
|
|
- 对攻击事件进行复盘，分析攻击成功的原因。
|
|||
|
|
- 根据攻击类型和特征，更新防御策略和安全策略。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 13、Log4j rce漏洞有了解过？
|
|||
|
|
|
|||
|
|
> [log4j2 远程代码执行漏洞复现（CVE-2021-44228）_log4j命令执行流量特征-CSDN博客](https://blog.csdn.net/Myon5/article/details/136548391)
|
|||
|
|
|
|||
|
|
- JNDI 是 Java Naming and Directory Interface 的缩写，是 Java 中用于访问各种命名和目录服务的API（应用程序编程接口） 。JNDI 提供了一种标准的方式来访问各种命名和目录服务，从指定的远程服务器获取并加载对象，其中常用的协议包括 RMI（远程方法调用）和 LDAP（轻量目录访问协议）。
|
|||
|
|
|
|||
|
|
- log4j2 在日志输出中，未对字符合法性进行严格的限制，执行了 JNDI 协议加载的远程恶意脚本，从而造成RCE。
|
|||
|
|
|
|||
|
|
- 受影响版本范围：2.0 ≤ Apache Log4j2 < 2.15.0-rc2
|
|||
|
|
|
|||
|
|
- **log4j2 漏洞流量特征：**
|
|||
|
|
|
|||
|
|
（1）恶意请求中包含 JNDI 协议地址：
|
|||
|
|
|
|||
|
|
> 攻击者通常会在 HTTP 请求或其他网络流量中插入包含 JNDI 协议地址的字符串，如"ldap://"、"rmi://"等。这些字符串会被log4j2解析为 JNDI 查找，从而导致远程代码执行。
|
|||
|
|
|
|||
|
|
（2）日志记录消息中包含可执行代码：
|
|||
|
|
|
|||
|
|
> 攻击者构造的恶意日志记录消息可能包含可执行的Java代码，如 JNDI 注入 payload 。这些代码会被 log4j2 解析和执行，从而触发远程代码执行漏洞。
|
|||
|
|
|
|||
|
|
（3）异常堆栈中出现与 JNDI 相关的类或方法：
|
|||
|
|
|
|||
|
|
> 在应用程序的异常堆栈中，可能会出现与JNDI相关的类或方法，如javax.naming.directory.InitialDirContext 等。这表明攻击者已经成功地利用了 log4j2 漏洞，执行了远程代码并导致异常。
|
|||
|
|
|
|||
|
|
|
|||
|
|
（4）大量的异常日志记录：
|
|||
|
|
|
|||
|
|
> 攻击者可能会尝试多次利用 log4j2 漏洞，因此在日志中可能会出现大量的异常日志记录。这些异常日志记录通常会包含与 JNDI 相关的内容，如 JNDI 协议地址或异常堆栈信息。
|
|||
|
|
|
|||
|
|
- **log4j2 漏洞防御措施**
|
|||
|
|
|
|||
|
|
（1）设置 log4j2.formatMsgNoLookups=True：
|
|||
|
|
|
|||
|
|
> 这个设置将禁用 log4j2 中的消息查找（Lookups），这样可以防止恶意代码利用 JNDI 注入漏洞。通过设置此选项，log4j2 将不会解析消息中的变量或执行 JNDI 查找。
|
|||
|
|
|
|||
|
|
|
|||
|
|
（2）对包含特定字符串的请求进行拦截：
|
|||
|
|
|
|||
|
|
> 监测应用程序的日志，如果发现其中包含"jndi:ldap://"、"jndi:rmi://"等可疑字符串，可以使用WAF（Web应用程序防火墙）或 IDS（入侵检测系统）等工具来拦截这些请求，从而阻止潜在的攻击。
|
|||
|
|
|
|||
|
|
|
|||
|
|
（3）对系统进行合理配置，限制对外访问：
|
|||
|
|
|
|||
|
|
> 配置网络防火墙，限制系统对外部网络的访问，并阻止不必要的业务访问外网。
|
|||
|
|
|
|||
|
|
|
|||
|
|
（4）升级 log4j2 组件到新的安全版本：
|
|||
|
|
|
|||
|
|
> 及时升级 log4j2 到最新的安全版本，以修复已知的漏洞并增强系统的安全性。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 14、XXE漏洞和文件上传漏洞
|
|||
|
|
|
|||
|
|
1. **XXE**
|
|||
|
|
|
|||
|
|
- XXE 攻击是利用 XML 解析器在处理外部实体引用时的安全漏洞。攻击者可以通过多种方式将恶意构造的 XML 文件注入服务器。
|
|||
|
|
|
|||
|
|
- 其一，通过用户输入点。比如在表单提交中，如果 Web 应用程序有接受用户输入并以 XML 格式处理的表单，攻击者就能在表单字段中输入恶意的 XML 内容。又或者在文件上传功能中，若应用程序允许用户上传 XML 文件，攻击者上传包含恶意外部实体引用的 XML 文件，就可能导致服务器在解析时出现安全问题。
|
|||
|
|
|
|||
|
|
其二，参数注入也是一种途径。无论是 URL 参数还是 POST 请求参数，如果服务器端在处理时涉及到 XML 解析且没有进行充分的输入验证，攻击者就可以注入恶意 XML。
|
|||
|
|
|
|||
|
|
其三，在第三方接口集成的情况下，如果 Web 应用与其他系统通过 XML 进行数据交换，一旦第三方系统被攻击，攻击者就能构造恶意 XML 消息并发送给目标服务器。
|
|||
|
|
|
|||
|
|
其四，利用漏洞进行间接注入。例如服务器端请求伪造（SSRF）漏洞，攻击者可利用该漏洞让服务器发起请求到内部的 XML 服务，并在请求中注入恶意 XML。或者在数据库注入的情况下，如果数据库中存储了 XML 数据，攻击者通过 SQL 注入等漏洞修改数据库中的 XML 内容，当服务器读取和处理这些 XML 数据时，就可能触发 XXE 攻击。
|
|||
|
|
|
|||
|
|
2. **文件上传漏洞**
|
|||
|
|
|
|||
|
|
- 由于 Web 应用程序在处理用户上传的文件时，没有进行充分的安全检查和过滤，导致恶意用户可以上传恶意文件。比如可执行文件、脚本文件等，一旦这些文件被服务器执行，就会造成服务器被攻击、数据泄露等严重后果。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 15、文件上传漏洞%00截断前提是什么
|
|||
|
|
|
|||
|
|
“%00截断”是一种利用文件上传漏洞的技术，其中“%00”是ASCII码中NULL字符（值为0）的十六进制表示。在某些情况下，攻击者可以通过在文件名或文件内容中插入%00来截断字符串，这可能会导致程序错误地处理文件，比如将一个恶意文件当作合法文件处理。
|
|||
|
|
|
|||
|
|
“前提是什么”这个问题是在询问使用%00截断技术成功利用文件上传漏洞需要满足的条件或前提。这些前提可能包括：
|
|||
|
|
|
|||
|
|
1. 应用程序没有正确处理文件名或文件内容中的NULL字符。
|
|||
|
|
2. 应用程序没有实施足够的文件类型检查和验证。
|
|||
|
|
3. 应用程序没有实施适当的文件上传大小限制。
|
|||
|
|
4. 服务器配置允许执行上传的文件。
|
|||
|
|
5. PHP版本小于5.3.4：在这些版本的PHP中，`magic_quotes_gpc` 是默认开启的，它会在文件名中的某些字符前自动添加反斜杠进行转义。但是，如果上传的文件名包含 `%00`，它会在转义之前截断字符串。
|
|||
|
|
|
|||
|
|
要防止 `%00` 截断攻击，可以采取以下措施：
|
|||
|
|
|
|||
|
|
- 过滤和验证：对上传的文件名进行严格的过滤和验证，移除或拒绝包含空字符的文件名。
|
|||
|
|
- 使用安全的函数：使用内置的安全函数来处理文件上传，这些函数通常会处理特殊字符，防止截断攻击。
|
|||
|
|
- 更新和打补丁：确保服务器和应用程序的版本是最新的，及时修复已知的安全漏洞。
|
|||
|
|
- 权限控制：确保上传的文件不能被当作脚本执行，可以通过配置文件权限和服务器设置来实现。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 16、如何通过态感设备可快速定位攻击地址
|
|||
|
|
|
|||
|
|
- 使用SIEM（安全信息和事件管理）系统：SIEM系统能够聚合和分析来自多个源的安全相关数据，帮助快速识别攻击源。
|
|||
|
|
- 进行流量分析：
|
|||
|
|
- NetFlow分析：通过分析NetFlow数据，可以识别异常流量的来源。
|
|||
|
|
- 全流量捕获：使用工具如Wireshark进行深入的数据包分析。
|
|||
|
|
- 执行逆向追踪：
|
|||
|
|
- 反向DNS查询：通过IP地址进行反向DNS查询，获取与之关联的域名信息。
|
|||
|
|
- Whois查询：查询IP地址的注册信息，包括注册商、注册人、联系邮箱等。
|
|||
|
|
- 利用威胁情报平台：这些平台提供了关于已知攻击者的信息，包括他们的IP地址、域名、使用的工具等。
|
|||
|
|
- 实时监控与阻断：
|
|||
|
|
- 设置阈值告警：对于异常流量或行为设置阈值，一旦触发告警即可采取行动。
|
|||
|
|
- 动态黑名单：将识别出的恶意IP地址加入黑名单，实时阻断来自该地址的流量。
|
|||
|
|
|