Tuesday, August 14, 2018

Windows Exploitation Tricks: Exploiting Arbitrary Object Directory Creation for Local Elevation of Privilege

Posted by James Forshaw, Project Zero

And we’re back again for anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r blog in my series on Windows Exploitation tricks. This time I’ll detail how I was able to exploit Issue 1550 which results in an arbitrary object directory being created by using a useful behavior of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 CSRSS privileged process. Once again by detailing how I’d exploit a particular vulnerability I hope that readers get a better understanding of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 complexity of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Windows operating system as well as giving Microsoft information on non-memory corruption exploitation techniques so that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y can mitigate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m in some way.

Quick Overview of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vulnerability

Object Manager directories are unrelated to normal file directories. The directories are created and manipulated using a separate set of system calls such as NtCreateDirectoryObject racá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than NtCreateFile. Even though cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y’re not file directories cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y’re vulnerable to many of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same classes of issues as you’d find on a file system including privileged creation and symbolic link planting attacks.

Issue 1550 is a vulnerability that allows cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 creation of a directory inside a user-controllable location while running as SYSTEM. The root of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug is in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 creation of Desktop Bridge applications. The AppInfo service, which is responsible for creating cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 new application, calls cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 undocumented API CreateAppContainerToken to do some internal housekeeping. Unfortunately this API creates object directories under cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user’s AppContainerNamedObjects object directory to support redirecting BaseNamedObjects and RPC endpoints by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 OS.

As cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 API is called without impersonating cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user (it’s normally called in CreateProcess where it typically isn’t as big an issue) cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 object directories are created with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 identity of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 service, which is SYSTEM. As cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user can write arbitrary objects to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir AppContainerNamedObjects directory cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y could drop an object manager symbolic link and redirect cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 directory creation to almost anywhere in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 object manager namespace. As a bonus cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 directory is created with an explicit security descriptor which allows cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user full access, this will become very important for exploitation.

One difficulty in exploiting this vulnerability is that if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 object directory isn’t created under AppContainerNamedObjects because we’ve redirected its location cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 underlying NtCreateLowBoxToken system call which performs cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 token creation and captures a handle to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 directory as part of its operation will fail. The directory will be created but almost immediately deleted again. This behavior is actually due to an earlier issue I reported which changes cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 system call’s behavior. This is still exploitable by opening a handle to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 created directory before it’s deleted, and in practice it seems winning this race is reliable as long as your system has multiple processors (which is basically any modern system). With an open handle cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 directory is kept alive as long as needed for exploitation.

This is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 point where cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 original PoC I sent to MSRC stopped, all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 PoC did was create an arbitrary object directory. You can find this PoC attached to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 initial bug report in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issue tracker. Now let’s get into how we might exploit this vulnerability to go from a normal user account to a privileged SYSTEM account.

Exploitation

The main problem for exploitation is finding a location in which we can create an object directory which can cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n be leveraged to elevate our privileges. This turns out to be harder than you might think. While almost all Windows applications use object directories under cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hood, such as BaseNamedObjects, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 applications typically interact with existing directories which cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability can’t be used to modify.

An object directory that would be interesting to abuse is KnownDlls (which I mentioned briefly in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous blog in this series). This object directory contains a list of named image section objects, of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 form NAME.DLL. When an application calls LoadLibrary on a DLL inside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SYSTEM32 directory cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 loader first checks if an existing image section is present inside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 KnownDlls object directory, if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 section exists cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n that will be loaded instead of creating a new section object.


KnownDlls is restricted to only being writable by administrators (not strictly true as we’ll see) because if you could drop an arbitrary section object inside this directory you could force a system service to load cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 named DLL, for example using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Diagnostics Hub service I described in my last blog post, and it would map cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 section, not cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 file on disk. However cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability can’t be used to modify cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 KnownDlls object directory ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than adding a new child directory which doesn’t help in exploitation. Maybe we can target KnownDlls indirectly by abusing ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r functionality which our vulnerability can be used with?

Whenever I do research into particular areas of a product I will always note down interesting or unexpected behavior. One example of interesting behavior I discovered when I was researching Windows symbolic links. The Win32 APIs support a function called DefineDosDevice, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 purpose of this API is to allow a user to define a new DOS drive letter. The API takes three parameters, a set of flags, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 drive prefix (e.g. X:) to create and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 target device to map that drive to. The API’s primary use is in things like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 CMD SUBST command.

On modern versions of Windows this API creates an object manager symbolic link inside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user’s own DOS device object directory, a location which can be written to by a normal low privileged user account. However if you look at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 implementation of DefineDosDevice you’ll find that it’s not implemented in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 caller’s process. Instead cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 implementation calls an RPC method inside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 current session’s CSRSS service, specifically cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 method BaseSrvDefineDosDevice inside BASESRV.DLL. The main reason for calling into a privileged service is it allows a user to create a permanent symbolic link which doesn’t get deleted when all handles to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 symbolic link object are closed. Normally to create a permanent named kernel object you need cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SeCreatePermanentPrivilege privilege, however a normal user does not have that privilege. On cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r hand CSRSS does, so by calling into that service we can create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 permanent symbolic link.

The ability to create a permanent symbolic link is certainly interesting, but if we were limited to only creating drive letters in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user’s DOS devices directory it wouldn’t be especially useful. I also noticed that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 implementation never verified that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 lpDeviceName parameter is a drive letter. For example you could specify a name of “GLOBALROOT\RPC Control\ABC” and it would actually create a symbolic link outside of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user’s DosDevices directory, specifically in this case cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 path “\RPC Control\ABC”. This is because cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 implementation prepends cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 DosDevice prefix “\??” to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 device name and passes it to NtCreateSymbolicLink. The kernel would follow cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 full path, finding GLOBALROOT which is a special symbolic link to return to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 root and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n follow cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 path to creating cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 arbitrary object. It was unclear if this was intentional behavior so I looked in more depth at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 implementation in CSRSS, which is shown in abbreviated form below.

NTSTATUS BaseSrvDefineDosDevice(DWORD dwFlags,
                               LPCWSTR lpDeviceName,
                               LPCWSTR lpTargetPath) {
   WCHAR device_name[];
   snwprintf_s(device_name, L"\\??\\%s", lpDeviceName);
   UNICODE_STRING device_name_ustr;
   OBJECT_ATTRIBUTES objattr;
   RtlInitUnicodeString(&device_name_ustr, device_name);
   InitializeObjectAttributes(&objattr, &device_name_ustr,
                              OBJ_CASE_INSENSITIVE);

   BOOLEAN enable_impersonation = TRUE;
   CsrImpersonateClient();
   HANDLE handle;
   NTSTATUS status = NtOpenSymbolicLinkObject(&handle, DELETE, &objattr);①
   CsrRevertToSelf();

   if (NT_SUCCESS(status)) {
       BOOLEAN is_global = FALSE;

       // Check if we opened a global symbolic link.
       IsGlobalSymbolicLink(handle, &is_global); ②
       if (is_global) {
           enable_impersonation = FALSE; ③
           snwprintf_s(device_name, L"\\GLOBAL??\\%s", lpDeviceName);
           RtlInitUnicodeString(&device_name_ustr, device_name);
       }

       // Delete cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 existing symbolic link.
       NtMakeTemporaryObject(handle);
       NtClose(handle);
   }

   if (enable_impersonation) { ④
       CsrRevertToSelf();
   }

   // Create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 symbolic link.
   UNICODE_STRING target_name_ustr;
   RtlInitUnicodeString(&target_name_ustr, lpTargetPath);

   status = NtCreateSymbolicLinkObject(&handle, MAXIMUM_ALLOWED,
                               objattr, target_name_ustr); ⑤

   if (enable_impersonation) { ⑥
       CsrRevertToSelf();
   }
   if (NT_SUCCESS(status)) {
       status = NtMakePermanentObject(handle); ⑦
       NtClose(handle);
   }
   return status;
}

We can see cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first thing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 code does is build cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 device name path cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n try and open cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 symbolic link object for DELETE access . This is because cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 API supports redefining an existing symbolic link, so it must first try to delete cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old link. If we follow cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 default path where cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 link doesn’t exist we’ll see cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 code impersonates cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 caller (cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 low privileged user in this case) cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n creates cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 symbolic link object ⑤, reverts cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 impersonation ⑥ and makes cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 object permanent ⑦ before returning cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 status of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 operation. Nothing too surprising, we can understand why we can create arbitrary symbolic links because all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 code does is prefix cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 passed device name with “\??”. As cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 code impersonates cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 caller when doing any significant operation we can only create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 link in a location that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user could already write to.

What’s more interesting is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 middle conditional, where cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 target symbolic link is opened for DELETE access, which is needed to call NtMakeTemporaryObject. The opened handle is passed to anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r function ②, IsGlobalSymbolicLink, and based on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 result of that function a flag disabling impersonation is set and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 device name is recreated again with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 global DOS device location \GLOBAL?? as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 prefix ③. What is IsGlobalSymbolicLink doing? Again we can just RE cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 function and check.

void IsGlobalSymbolicLink(HANDLE handle, BOOLEAN* is_global) {
   BYTE buffer[0x1000];
   NtQueryObject(handle, ObjectNameInformation, buffer, sizeof(buffer));
   UNICODE_STRING prefix;
   RtlInitUnicodeString(&prefix, L"\\GLOBAL??\\");
   // Check if object name starts with \GLOBAL??
   *is_global = RtlPrefixUnicodeString(&prefix, (PUNICODE_STRING)buffer);
}

The code checks if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 opened object’s name starts with \GLOBAL??\. If so it sets cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 is_global flag to TRUE. This results in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 flag enabling impersonation being cleared and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 device name being rewritten. What this means is that if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 caller has DELETE access to a symbolic link inside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 global DOS device directory cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 symbolic link will be recreated without any impersonation, which means it will be created as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SYSTEM user. This in itself doesn’t sound especially interesting as by default only an administrator could open one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 global symbolic links for DELETE access. However, what if we could create a child directory underneath cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 global DOS device directory which could be written to by a low privileged user? Any symbolic link in that directory could be opened for DELETE access as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 low privileged user could specify any access cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y liked, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 code would flag cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 link as being global, when in fact that’s not really cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 case, disable impersonation and recreate it as SYSTEM. And guess what, we have a vulnerability which would allow us to create an arbitrary object directory under cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 global DOS device directory.

Again this might not be very exploitable if it wasn’t for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 rewriting of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 path. We can abuse cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 fact that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 path “\??\ABC” isn’t cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same as “\GLOBAL??\ABC” to construct a mechanism to create an arbitrary symbolic link anywhere in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 object manager namespace as SYSTEM. How does this help us? If you write a symbolic link to KnownDlls cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n it will be followed by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 kernel when opening a section requested by DLL loader. Therefore even though we can’t directly create a new section object inside KnownDlls, we can create a symbolic link which points outside that directory to a place that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 low-privileged user can create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 section object. We can now abuse cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hijack to load an arbitrary DLL into memory inside a privileged process and privilege elevation is achieved.

Pulling this all togecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r we can exploit our vulnerability using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following steps:

  1. Use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability to create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 directory “\GLOBAL??\KnownDlls”
  2. Create a symbolic link inside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 new directory with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 name of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 DLL to hijack, such as TAPI32.DLL. The target of this link doesn’t matter.
  3. Inside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user’s DOS device directory create a new symbolic link called “GLOBALROOT” pointing to “\GLOBAL??”. This will override cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 real GLOBALROOT symbolic link object when a caller accesses it via cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user’s DOS device directory.
  4. Call DefineDosDevice specifying a device name of “GLOBALROOT\KnownDlls\TAPI32.DLL” and a target path of a location that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user can create section objects inside. This will result in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following operations:
    1. CSRSS opens cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 symbolic link “\??\GLOBALROOT\KnownDlls\TAPI32.DLL” which results in opening “\GLOBAL??\KnownDlls\TAPI32.DLL”. As this is controlled by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 open succeeds, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 link is considered global which disables impersonation.
    2. CSRSS rewrites cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 path to “\GLOBAL??\GLOBALROOT\KnownDlls\TAPI32.DLL” cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n calls NtCreateSymbolicLinkObject without impersonation. This results in following cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 real GLOBALROOT link, which results in creating cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 symbolic link “\KnownDlls\TAPI32.DLL” with an arbitrary target path.
  5. Create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 image section object at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 target location for an arbitrary DLL, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n force it to be loaded into a privileged service such as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Diagnostics Hub by getting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 service to call LoadLibrary with a path to TAPI32.DLL.
  6. Privilege escalation is achieved.

Abusing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 DefineDosDevice API actually has a second use, it’s an Administrator to Protected Process Light (PPL) bypass. PPL processes still use KnownDlls, so if you can add a new entry you can inject code into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 protected process. To prevent that attack vector Windows marks cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 KnownDlls directory with a Process Trust Label which blocks all but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 highest level level PPL process from writing to it, as shown below.


How does our exploit work cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n? CSRSS actually runs as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 highest level PPL so is allowed to write to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 KnownDlls directory. Once cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 impersonation is dropped cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 identity of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 process is used which will allow full access.

If you want to test this exploit I’ve attached cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 new PoC to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issue tracker here.

Wrapping Up

You might wonder at this point if I reported cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 behavior of DefineDosDevice to MSRC? I didn’t, mainly because it’s not in itself a vulnerability. Even in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 case of Administrator to PPL, MSRC do not consider that a serviceable security boundary (example). Of course cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Windows developers might choose to try and change this behavior in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 future, assuming it doesn’t cause a major regression in compatibility. This function has been around since cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 early days of Windows and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 current behavior since at least Windows XP so cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re’s probably something which relies on it. By describing this exploit in detail, I want to give MS as much information as necessary to address cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 exploitation technique in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 future.

I did report cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability to MSRC and it was fixed in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 June 2018 patches. How did Microsoft fix cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability? The developers added a new API, CreateAppContainerTokenForUser which impersonates cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 token during creation of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 new AppContainer token. By impersonating during token creation cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 code ensures that all objects are created only with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 privileges of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user. As it’s a new API existing code would have to be changed to use it, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365refore cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re’s a chance you could still find code which uses cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old CreateAppContainerToken in a vulnerable pattern.

Exploiting vulnerabilities on any platform sometimes requires pretty in-depth knowledge about how different components interact. In this case while cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 initial vulnerability was clearly a security issue, it’s not clear how you could proceed to full exploitation. It’s always worth keeping a log of interesting behavior which you encounter during reverse engineering as even if something is not a security bug itself, it might be useful to exploit anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r vulnerability.

Thursday, August 2, 2018

Adventures in vulnerability reporting

Posted by Natalie Silvanovich, Project Zero

At Project Zero, we spend a lot of time reporting security bugs to vendors. Most of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 time, this is a fairly straightforward process, but we occasionally encounter challenges getting information about vulnerabilities into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hands of vendors. Since it is important to user security that software vendors fix reported vulnerabilities in a timely matter, and vendors need to actually receive cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 report for this to happen, we have decided to share some of our experiences. We hope to show that good practices by software vendors can avoid delays in vulnerability reporting.

Effective Vulnerability Reporting Processes
There are several aspects of a bug reporting process that make reporting vulnerabilities easier from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug reporter’s perspective. To start off, it’s important for a bug reporting process to be easy to find and use. We sometimes have difficulty figuring out how to report a vulnerability in a piece of software if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability reporting process is not documented on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 project or vendor’s website, or if outdated material is not removed and instructions for reporting vulnerabilities are inconsistent. This can lead to delays in reporting. Effective vulnerability reporting processes are clearly documented, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 documentation is easy to find.

We also appreciate when cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 process for reporting a vulnerability is short and straightforward. Occasionally, we report dozens of vulnerabilities in a vendor’s products, and it is helpful when reporting does not require a lot of clicks and reading. Reporting processes that use email or bug trackers are usually cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 easiest, though webforms can be easy if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are not excessively long. While Project Zero will always report a vulnerability, even if reporting it is very time consuming, this is not necessarily cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 case for ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r bug reporters. Long bug reporting processes can cause bug reporters to report bugs more slowly, spend less time working on a piece of software or even give up on reporting a bug. The easier a bug reporting process is, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 more likely it is that someone will go through with it.

It’s also important for bug reporting processes to be well-tested. While cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 majority we encounter are, we’ve occasionally had bug reporting email addresses bounce, webforms reject necessary information (like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reporter’s name) and security issues go unnoticed in bug trackers for months despite following cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 documented process. Vendors with good processes usually test that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir process and any systems it involves works correctly on a regular basis.

Mandatory legal agreements in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reporting process are anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r problem that we encounter every so often. If a legal agreement contains language about disclosure or any ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r subject we don’t feel comfortable entering an agreement about on behalf of our company, deciding whecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r to enter cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 agreement can require a lengthy discussion, delaying cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug report. While legal agreements are sometimes necessary for rewards programs and code contributions, good vulnerability reporting processes allow bug reporters to report bugs without cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m.

It is also helpful when vendors confirm that vulnerability reports have been received in a timely manner. Since bug reports can get lost for a number of reasons, including bugs in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reporting interface and human error, it is a good idea to let reporters know that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir report has been received, even if it won’t be processed right away. This lets cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reporter know that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y’ve reported cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug correctly, and don’t need to spend any more time reporting it, and makes it more likely that bug reporters will reach out if a bug report gets lost, as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y will be expecting a confirmation.

Finally, even if good practices are followed in creating cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug reporting process, it is still possible that a bug reporting process has problems, so it is very helpful if vendors provide a way to give feedback on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 process. It’s very rare for vendors to intentionally make bug reporting difficult, but unexpected problems happen fairly frequently, so it is good to provide a way bug reporters can reach out for help as a last resort if a reporting a bug fails for any reason.

Examples
One example of a bug we had difficulty reporting due to a vendor not following cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 practices described above is CVE-2018-10751.  CVE-2018-10751 is a remote memory corruption vulnerability in OMACP affecting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Samsung S7 Edge. The issue can be triggered by sending a single SMS to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 target device, and does not require any user interaction. The payload can be sent from an app on an Android device without root access or any special equipment. It is similar to CVE-2016-7990, which is described in detail here.

Samsung’s Vulnerability Reporting Process
CVE-2018-10751 is a serious vulnerability, and I wanted to report it immediately. I started off by reading Samsung Mobile’s Security Reporting page. This page has a button to create a bug report.


Pressing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 button led to a sign-up page. I didn’t have a Samsung account, so I tried to sign up. Unfortunately, it led to this page:


Not speaking Korean, I wasn’t sure what to do here. I eventually went back to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous page and tried cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ‘Sign-in’ button.

This brought me to an English sign-up page, which cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n brought me to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 account creation page. According to this page, I had to read and agree to some terms. Clicking cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 links led to over twenty separate agreements, most of which had nothing to do with vulnerability reporting.
https://account.samsung.com Accessed February 22, 2018

That’s a lot of text to read and review. Let’s just say I skimmed a bit. Once I clicked ‘Agree’, I was taken to a page where I could enter account information. The page required my birthdate and zip code, which I wasn’t thrilled to have to provide to report a vulnerability, but I wanted to get cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issue reported, so I entered cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. Finally, my account was created! I logged in, hoping to start reporting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug, only to be greeted with more conditions.

https://account.samsung.com Accessed February 22, 2018

These ones were in Korean, and I couldn’t figure out how to change cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 language. Eventually, I just selected confirm. Finally, I got to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 form where I could report bugs!


I filled out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability information, and scrolled down, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re was one more set of terms to agree to:

These terms included:

- You MUST hold off disclosing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability in reasonable time, and you MUST get Samsung’s  consent or inform Samsung about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 date before disclosing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability.
- In some cases, Samsung may request not to disclose cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability at all.

I was not able to submit this form without agreeing to allow Samsung some level of control over disclosure of reported vulnerability. I looked around Samsung’s security page to see if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y provided an email address I could report cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issue to, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y did not provide one. I was not comfortable reporting this bug through cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mechanisms Samsung provides for vulnerability reporting on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir website.

Problems with Vulnerability Reporting Processes

I encountered several problems while trying to report cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 above vulnerability—most of which have been since resolved by Samsung.

To start off, Samsung’s bug reporting process did not seem adequately tested. The many times that Korean text showed up while attempting to report this vulnerability suggests that it was not tested in English. As described above, is important for vendors to test vulnerability reporting processes, including for internationalization issues. The workflow is also excessively long, and requires cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reporter to agree to a very large number of agreements, many of which have nothing to do with vulnerability reports. I suspect that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 people testing this interface might have already had accounts, and not seen how long cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 process is for someone who just wants to report a bug.

This isn’t an uncommon problem. The Android security reporting template requires creating a GMail account, which can require clicking through many screens and verification via SMS in some circumstances. As a result of our feedback, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Android Security team has improved cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 documentation that vulnerability reports can be filed via email (security@android.com), although using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 web form is still required to participate in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Android Security rewards program.

Anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r problem was that in order to report a bug, a reporter had to agree to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 terms of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 rewards program. This is an issue that Project Zero has been seeing increasingly often. When software vendors start rewards programs, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y often remove existing mechanisms for reporting vulnerabilities, leaving bug reporters with no way to report vulnerabilities without entering into agreements.

This also occurred when Tavis Ormandy attempted to report cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability he reluctantly dubbed CloudBleed. Cloudflare’s vulnerability reporting process is tied to its rewards program with HackerOne, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is no clear way to report a vulnerability without creating a HackerOne account in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir Vulnerability Disclosure Policy. The policy even states “We agree with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir disclosure philosophy, and if you do too, please submit your vulnerability reports here” without providing an alternative for vulnerability reporters who don’t agree or don’t want to participate in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 program for whatever reason. In Project Zero’s case, our disclosure deadline is 90 days meanwhile HackerOne’s deadline is 180 days. This vulnerability was also very urgent as it was actively leaking user data onto cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet, and we didn’t want to delay reporting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issue while we read through HackerOne’s terms to determine whecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y were compatible with our disclosure policy.

We find that vendors generally don’t intend to prevent bug reports from anyone who won’t agree to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir disclosure rules, but this was cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 end result of Samsung and Cloudflare replacing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir bug reporting process with a rewards program.

The specific terms of Samsung’s agreement were also fairly vague. In particular, it wasn’t clear what cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 consequences of breaking cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 terms would be. For example:

- You MUST hold off disclosing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability in reasonable time, and you MUST get Samsung’s  consent or inform Samsung about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 date before disclosing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability.

Does this mean that if someone discloses a vulnerability without permission, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are not eligible for a reward? Does it mean that if someone discloses cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability without permission, Samsung can take legal action against cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m? While requiring that bug reporters not disclose vulnerabilities to receive rewards is a policy with debatable benefit, I would have been much more comfortable agreeing to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se terms if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y had spelled out that violating cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m would simply mean I would not receive a reward, as opposed to ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r legal consequences.
Overall, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issues of poorly tested bug reporting interfaces and requiring legal agreements to report vulnerabilities have come up multiple times, and led to delays of Project Zero reporting vulnerabilities. We recommend that vendors test cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir vulnerability reporting interfaces from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 perspective of someone who’s never reported a bug from outside of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir corporate network, and make sure to do localized testing. It is also important to allow bug reports without requiring cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reporter to enter into excessive legal agreements.

While only accepting vulnerability reports via web forms can reduce cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 number of invalid reports, which is a major challenge for teams accepting vulnerability reports, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y can also be unreliable and prevent vulnerability reporting in situations that were not expected by those designing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m, unless cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are very well tested. Having an alternate email address that vulnerability reporters can use to report bugs if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y encounter problems is a good way to prevent this type of problem.

Reporting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Bug
I eventually contacted some members of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Knox security team at Samsung that I had worked with on previous bugs and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y recommended reporting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issue to mobile.security@samsung.com. This email is not documented on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Samsung website, except for a single blog post from 2015.

The difficulty I encountered reporting this serious vulnerability delayed my report one week. It might have caused a longer delay if I did not have contacts at Samsung who could help.

Samsung started rolling out updates for CVE-2018-10751 (Samsung’s identifier SVE-2018-11463) in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir April maintenance release.

Samsung has updated cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir account creation page so that it always displays English text if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 language is set to English. Also, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vulnerability report form can now be submitted without agreeing to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 terms for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Samsung’s rewards program, though cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 user still has to agree to two ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r agreements. They have also updated cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir bug reporting page to provide an email address as well as a webform. We appreciate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 changes cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y have made to make reporting vulnerabilities in Samsung products easier for everyone.

Conclusion
Project Zero has occasionally had difficulty reporting vulnerabilities, leading to delays in reporting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug. Usually, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se are due to problems in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reporting process that were not intended or expected by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vendor. A difficult vulnerability reporting process can have a negative impact on user security due to delays in vulnerability reports, lost vulnerability reports and even bug reporters choosing not to report a vulnerability. We appreciate when vendors do cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following to make cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir bug reporting processes easier for bug reporters:

  • Vendors should regularly test cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir vulnerability reporting interfaces in all supported languages
  • Vendors should streamline cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir vulnerability reporting processing as much as possible, and remove excessive clicks and legal agreements
  • Vendors should regularly solicit feedback on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir vulnerability reporting mechanisms from vulnerability reporters and people cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y think are likely to report vulnerabilities