4G无线网络协同及组网关键技术探讨

移位运算符

左移运算<<：左移后右边位补 0

右移运算>>：右移后左边位补原最左位值(可能是0，可能是1)

右移运算>>>：右移后左边位补 0

• 对于左移运算符<<没有悬念右侧填个零无论正负数相当于整个数乘以2。
• 而右移运算符就有分歧了，分别是左侧补0>>>和左侧补原始位>>，如果是正数没争议左侧都是补0，达到除以2的效果;如果是负数的话左侧补0>>>那么数值的正负会发生改变，会从一个负数变成一个相对较大的正数。而如果是左侧补原始位(负数补1)>>那么整个数还是负数，也就是相当于除以2的效果。

下面这张图可以很好的帮助你理解负数的移位运算符：
 

PrivescCheck是是著名PowerUp的一种更新和扩展版本,可以针对Windows系统的提权枚举脚本，该脚本能够枚举出目标Windows系统中常见的Windows错误安全配置。如果你曾经在Windows 7或Windows Server 2008 R2上运行过此脚本，则可能会注意到重复出现奇怪的结果，可能会像我一样认为它是一个误报，但其实它是一个漏洞。

从今年年初开始，我开始研究特权升级枚举脚本：PrivescCheck，使用此脚本，我只是希望能够快速枚举由系统配置错误引起的潜在漏洞，但实际上却产生了一些意外的结果，比如它使我能够在Windows 7 / Server 2008R2中找到很多零日漏洞!

假设一台Windows设备打了完整的补丁，可能导致本地特权升级的主要安全问题之一是服务配置错误。如果普通用户能够修改现有服务，则就可以在本地/网络服务甚至本地系统的上下文中执行任意代码。以下就是一些最常见的漏洞：

1. 服务控制管理器(SCM)：可以通过SCM向低特权用户授予服务的特定权限。例如，普通用户可以通过命令sc.exe start wuauserv启动Windows更新服务，这要感谢SERVICE_START权限，这是一个非常常见的场景。但是，如果该用户具有SERVICE_CHANGE_CONFIG，则他/她将能够更改该服务的行为并使其运行任意可执行文件。

2.二进制权限：典型的Windows服务通常具有一个与其关联的命令行。如果你可以修改相应的可执行文件或者如果你在父文件夹中具有写入权限，那么你基本上可以在该服务的安全上下文中执行所需的任何操作。

3.未引用的路径：此问题与Windows解析命令行的方式有关。比如带有以下命令行的虚拟服务：C:ApplicationsCustom service service.exe /v。此命令行不明确，因此Windows将首先尝试以Service service.exe作为第一个参数，/ v作为第二个参数执行C:ApplicationsCustom.exe。如果一个普通用户在C:Applications中有写权限，那么就可以通过复制一个恶意的可执行文件到C:ApplicationsCustom.exe来劫持服务。这就是为什么路径应该总是用引号括起来，特别是当它们包含空格的时候："C:ApplicationsCustom Serviceservice.exe" /v。

4.虚拟DLL劫持和可写的%PATH%文件夹：即使在Windows的默认安装中，某些内置服务也会尝试加载不存在的DLL。这本身不是一个漏洞，但如果在%PATH%环境变量中列出的文件夹中有一个可以被普通用户写入，那么这些服务就可能被劫持。

这些潜在的安全问题中的每一个都已经在PowerUp中进行了相应的检查，但是在另一种情况下，可能会发生配置错误：注册表。通常，在创建服务时，可以通过使用内置命令sc.exe作为管理员调用服务控制管理器来进行。这将在HKLM SYSTEM CurrentControlSet Services中创建一个带有服务名称的子项，并将所有设置(命令行、用户等)保存在该子项中。因此，如果这些设置由SCM管理，则默认情况下它们应该是安全的。

检查注册表权限

PowerUp的核心函数之一是Get-ModifiablePath。这个函数的基本思想是提供一种通用的方法来检查当前用户是否可以以任何方式修改文件或文件夹(例如:AppendData/AddSubdirectory)。它通过解析目标对象的ACL，然后将其与通过它所属的所有组授予当前用户帐户的权限进行比较来实现。虽然这一原则最初是针对文件和文件夹实现的，但注册表项也是安全对象。因此，可以实现一个类似的函数来检查当前用户是否有对注册表项的写权限。这正是我所做的，因此我添加了一个新的核心函数：Get-ModifiableRegistryPath。

然后，实现对与Windows服务相对应的可修改注册表项的检查就像在路径Registry :: HKLM SYSTEM CurrentControlSet Services上调用Get-ChildItem PowerShell命令一样容易。结果可以简单地通过管道传递到新的Get-ModifiableRegistryPath命令，仅此而已。

当我需要实现一个新的检查时，我使用Windows 10设备，并且我也使用同一台设备进行初始测试，以查看是否一切都如预期的那样工作。当代码稳定后，我将测试扩展到其他几个Windows vm上，以确保它仍与PowerShell v2兼容，并且仍然可以在较老的系统上运行。我最常用于此目的的操作系统是Windows 7，Windows 2008 R2和Windows Server 2012 R2。

当我在Windows 10的默认安装上运行更新的脚本时，它没有返回任何内容，这是我期望的结果。我在Windows 7上运行了它，看到的结果如下：

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!