349 lines
20 KiB
Markdown
349 lines
20 KiB
Markdown
# 明阳研究院面试题
|
||
|
||
#### 1、怎么区分安全设备是不是误报
|
||
|
||
- 查看报警的具体信息，包括攻击类型、攻击源、攻击目标、使用的协议和端口等。
|
||
- 将报警信息与已知的威胁情报进行对比，看是否有匹配的已知攻击模式或恶意行为。
|
||
- 检查系统的日志和安全状态，看是否有异常的登录尝试、文件更改或其他异常行为。
|
||
- 确认安全设备配置：确保安全设备配置正确，没有设置过于敏感的规则。
|
||
- 复现测试：尝试复现报警条件，看是否能够稳定触发。
|
||
|
||
|
||
|
||
#### 2、如果存在挖矿，怎么进行研判
|
||
|
||
- 通过系统监控工具（如Windows的任务管理器、Linux的top或htop命令）来检查CPU使用率是否长时间异常高。
|
||
- 使用进程管理工具（如Windows的任务管理器、Linux的ps命令）检查是否存在可疑的进程。
|
||
- 使用网络连接监控工具（如netstat命令）检查服务器上异常的外部连接，特别是连接到已知挖矿池的端口。
|
||
- 查看任务的命令行参数，挖矿软件通常会有特定的命令行参数。
|
||
- 挖矿软件可能会修改系统配置，如启动项、计划任务等，以实现开机自启。
|
||
|
||
|
||
|
||
#### 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编码的数据包，对于这种数据包唯一的识别方法就是识别流量中的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 External Entity）漏洞发生在应用程序解析XML输入时，没有正确地限制外部实体的加载。攻击者可以利用这一点，通过构造恶意的XML内容，来访问服务器上的文件、执行远程服务的调用，甚至在服务器上执行远程代码。攻击者通常会在XML输入中插入或修改外部实体声明，尝试读取服务器上的文件内容或者执行其他系统命令。
|
||
|
||
2. **文件上传漏洞：** 文件上传漏洞是指应用程序允许用户上传文件，但在文件上传的处理过程中没有进行适当的验证或限制，导致攻击者可以上传可执行文件（如Webshell），进而控制服务器。 攻击者会尝试上传一个伪装成图片或其他非执行文件的可执行脚本文件，如果服务器没有进行有效的检查，这个脚本就有可能在服务器上执行。
|
||
|
||
|
||
|
||
#### 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地址加入黑名单，实时阻断来自该地址的流量。
|
||
|