Liras en la red: Explanation of CVE-2017-8464

[0x01].Introduction

[0x02].lnk file format parsing

[0x03]. Patch comparison

[0x04]. Vulnerability analysis

[0x05]. About detection

[0x06].Other

[0x01].Introduction

In June 2017, Microsoft's patch day announced two 0day vulnerabilities in the wild, CVE-2017-8464 (LNK vulnerability) and CVE-2017-8543 (vulnerability in Search service). This article will briefly analyze the causes and related uses of the LNK vulnerability.

For more information, please see:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8464
http://www.securityfocus.com/bid/98818

Vulnerability affected version:

Microsoft Windows 10 3
Microsoft Windows 7 1
Microsoft Windows 8 1
Microsoft Windows 8.1 2
Microsoft Windows Server 2008 2
Microsoft Windows Server 2012 2
Microsoft Windows Server 2016

[0x02].lnk file format parsing

Lnk file is a relatively simple file format, but because the operation involves shell programming, COM related and other WINDOWS foundation, it is not very easy to fully understand the relevant information. It's not as clear and easy to parse as a complex PE file. A typical lnk file format is as follows:

              **********************.lnk file format ******************

              +---------------------------+
              | lnk file header |
              +---------------------------+ >------.
              | Shell Item Id List | |
              +---------------------------+ |
              | File location info | |
              +---------------------------+ |
              | Description string | |
              +---------------------------+ ---
              Relative path string | Not all of these sections must exist. If they exist, they should be arranged in this order.
              +---------------------------+ ---
              | Working directory string | |
              +---------------------------+ |
              | Command line string | |
              +---------------------------+ |
              | Icon filename string | |
              +---------------------------+ >------.
              | Extra stuff |
              +---------------------------+

The location related to this vulnerability is 1) Shell Item Id List , 2) Extra stuff. For a more detailed introduction to the LNK file format, please refer to this or this links.

Some security companies mentioned that this vulnerability is very similar to the CVE-2010-2568 used by Stuxnet. In fact, there are some truths, all related to the use of the control panel shortcut CPL loading, but there are a certain difference.

The main factor is still in the Shell Item Id List section, which describes the path portion of the shortcut. For example, if I have a c:\a\b\c\x.jpg file, then after creating a shortcut for this file, a shell Item ID list structure will be generated.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000040 4B 01 14 00 K
00000050 1F 50 E0 4F D0 20 EA 3A 69 10 A2 D8 08 00 2B 30 P郞??i (20) +0
00000060 30 9D 19 00 2F 43 3A 5C 00 00 00 00 00 00 00 00 0 /C:\
00000070 00 00 00 00 00 00 00 00 00 00 00 00 44 00 31 00 00 D 1
00000080 00 00 00 E7 4A 01 73 10 00 61 00 34 00 09 00 04 鏙 s a 4
00000090 00 EF BE E7 4A 01 73 E7 4A 01 73 2E 00 00 00 7A 锞鏙 s鏙 s. z
000000A0 65 01 00 00 00 4F 02 00 00 00 00 00 00 00 00 00 00 e O
000000B0 00 00 00 00 00 DB B6 E5 00 61 00 00 00 10 00 44 鄱?a D
000000C0 00 31 00 00 00 00 00 E7 4A 01 73 10 00 62 00 34 1 鏙 s b 4
000000D0 00 09 00 04 00 EF BE E7 4A 01 73 E7 4A 01 73 2E 锞鏙 s鏙 s.
000000E0 00 00 00 D3 65 01 00 00 00 20 01 00 00 00 00 00 觘
000000F0 00 00 00 00 00 00 00 00 00 00 69 96 E5 00 62 00 00 i栧 b
00000100 00 10 00 44 00 31 00 00 00 00 00 E7 4A C3 73 10 D 1 鏙胹
00000110 00 63 00 34 00 09 00 04 00 EF BE E7 4A 01 73 E7 c 4 锞鏙 s?
00000120 4A C3 73 2E 00 00 00 E9 65 01 00 00 00 1F 00 00 J胹.
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC BF 2D 炜-
00000140 01 63 00 00 00 10 00 50 00 32 00 AE 3D 04 00 9F c P 2 ? ?
00000150 2F 00 80 20 00 78 2E 4A 50 47 00 3C 00 09 00 04 / € x.JPG <
00000160 00 EF BE E7 4A C1 73 E7 4A C1 73 2E 00 00 00 F2 velvet velvet.
00000170 65 01 00 00 00 64 00 00 00 00 00 00 00 00 00 00 00 e d
00000180 00 00 00 00 00 00 00 00 00

This part can be expressed as a structure

Struct ShellItem{
DWORD size;
SHITEMID item[1]; //The surface here is a variable section, which can grow with the increase of the directory.
}

Typedef struct _SHITEMID
      {
        Unsigned short int cb; //the length of this section
        Unsigned char abID[0]; //Define a mutable structure
      }SHITEMID, *LPSHITEMID;

Generally speaking, SHITEMID[0] represents my computer.

\x14\x00 (here is the length)
\x1F (type)
\x50 (unknown)
\xE0\x4F\xD0\x20\xEA\x3A\x69\x10\xA2\xD8\x08\x00\x2B\x30\x30\x9D(GUID)

The above GUID conversion is HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}, you can query on your own computer.

The default upper directory of the shortcut is started from here. According to this structure, you can find the corresponding \a, \b, \c, x.jpg. SHITEMID[1], SHITEMID[2], SHITEMID[3], SHITEMID[4] structure information

Then, the shortcut for the control panel will be different, SHITEMID[0] - corresponding to my computer information,

SHITEMID[1] - Corresponds to the GUID information of the control panel, usually \x19\x00\x2F\x43\x3A\x5C\x00\x00\x00\x00\x00\x00
SHITEMID[2] - Corresponding to the specific control panel cpl program information, the standard control panel shortcut will add its own path information to the extra stuff structure.

For example, if you create a shortcut to Auto Play in the control panel, you can view the information of Extra data. You can see a GUID. You can find out which cpl function program is corresponding to the query. Auto Play:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\
{9C60DE1E-E5FC-40f4-A487-460851A8D915}

According to the previous experience of analyzing CVE-2010-2568, the SHITEMID[1] of the vulnerability fills the GUID information of the control panel {21EC2020-3AEA-1069-A2DD-08002B30309D} SHITEMID[2] adds the corresponding cpl program path. According to the analysis of CVE-2017-8464, simply adding the path information of the cpl program will not trigger the vulnerability, and a special Extra data message must be constructed.

[0x03]. Patch comparison

   Analysis platform: win7 x86
   File: shell32.dll (pre-patch: 6.1.7601.1892, post-patch: 6.1.7600.23806)

Through path diff, you can see that Microsoft has patched a lot of places this time. According to the last experience, it is natural to query the CPL_LoadCPLModule function to be called.

...
CAutoComplete::_OnSearchComplete(SearchResults *,_DPA *)                                                      738F086E CAutoComplete::_OnSearchComplete(SearchResults *,_DPA *)
Kfapi::CFolderRedirector::Redirect(_GUID const &,HWND__ *,ulong,ushort const *,_GUID const *,uint,ushort * *) 73B61419 kfapi::CFolderRedirector::Redirect(_GUID const &,HWND__ *,ulong,ushort Const *, _GUID const *, uint, ushort * *)
CopyStreamToFile(IStream *, ushort const *, unsigned __int64)                                                 73B16E33 CopyStreamToFile(IStream *, ushort const *, unsigned __int64)
CControlPanelFolder::_GetPidlFromAppletId(ushort const *,_ITEMID_CHILD * *)                                   73AF300B CControlPanelFolder::_GetPidlFromAppletId(ushort const *,_ITEMID_CHILD * *)
CAutoComplete::_AppendNext(int)                                                                               73AA4538 CAutoComplete::_AppendNext(int)
CAutoComplete::_AppendPrevious(int)                                                                           73AA460E CAutoComplete::_AppendPrevious(int)
CGrep::_InitializeChunkBuffer(void)                                                                           73B9066F CGrep::_InitializeChunkBuffer(void)
...

Among them, the patch code of CControlPanelFolder::_GetPidlFromAppletId(ushort const *, _ITEMID_CHILD * *) is related to the CPL_LoadCPLModule function. A very important point is here:

  If ( SHExpandEnvironmentStringsW(&Start, &v17, 260) )
        {
          If ( CControlPanelFolder::_IsRegisteredCPLApplet(v11, &v17) ) // --- Added a checksum
          {
            V12 = 0;
            V7 = CPL_LoadCPLModule(&v17, 0);
            If ( v7 )
            {
              V13 = 0;
              Do
              {
                V8 = (struct _DSA *)*((_DWORD *)v7 + 135);
                If ( v6 >= *(_DWORD *)v8 )
                  Break;
                V9 = DSA_GetItemPtr(v8, v6);
                If ( v9 )
                {
                  V12 = IDControlCreate(
         ...
        }

At this point, we already know that the key is how to trigger the path of this vulnerability, call CPL_LoadCPLModule, because if there is no problem there, then Microsoft will not use _IsRegisteredCPLApplet Filter because CVE-2010-2568 is also patched with this mechanism.

[0x04]. Vulnerability analysis

All the way back we can get a trigger path:

CControlPanelFolder::ParseDisplayName (The specific reference to CControlPanelFolder::ParseDisplayName cannot be seen in IDA)
--> CControlPanelFolder::_GetPidlFromAppletId
-->CPL_LoadCPLModule

Therefore, the call to CControlPanelFolder::ParseDisplayName should be implemented through a dynamic object virtual table function call. Setting breakpoints in CControlPanelFolder::ParseDisplayName, arbitrarily open the file directory where .lnk exists, it is difficult to get a trigger. Note that the usual lnk file is missing some information or the corresponding field is incorrect.

Using the sample of CVE-2010-2568 for testing, this breakpoint cannot be triggered. But when I printed the execution path letter, I saw some notable places, and the call will be executed according to the previous vulnerability.

_DecodeSpecialFolder. But this function is not actually executed completely.

46 101 [ 2] SHLWAPI!SHReadDataBlockList
    3 0 [ 3] SHLWAPI!__security_check_cookie eax = 0
   48 104 [ 2] SHLWAPI!SHReadDataBlockList eax = 0
  119 3446 [ 1] SHELL32!CShellLink::_LoadFromStream
   16 0 [ 2] SHELL32!CShellLink::_DecodeSpecialFolder
   11 0 [ 3] SHLWAPI!SHFindDataBlock eax = 0
   22 11 [ 2] SHELL32!CShellLink::_DecodeSpecialFolder
   11 0 [ 3] SHLWAPI!SHFindDataBlock eax = 0
   27 22 [ 2] SHELL32!CShellLink::_DecodeSpecialFolder
    5 0 [ 3] SHELL32!SHFree
    8 0 [ 3] ole32!CoTaskMemFree
    7 0 [ 4] ole32!CRetailMalloc_Free eax = 76b076bc
   10 7 [ 3] ole32!CoTaskMemFree eax = 76b076bc
   33 44 [ 2] SHELL32!CShellLink::_DecodeSpecialFolder
    3 0 [ 3] SHELL32!__security_check_cookie eax = 76b076bc



void __thiscall CShellLink::_DecodeSpecialFolder(CShellLink *this)
{
  CShellLink *v1; // esi@1
  int v2; // eax@1
  int v3; // edi@1
  signed int v4; // eax@3
  signed int v5; // eax@5
  int v6; // ecx@5
  char *v7; // edi@7
  unsigned int v8; // ebx@7
  int i; // eax@7
  bool v10; // zf@9
  const ITEMIDLIST *v11; // eax@13
  ITEMIDLIST *v12; // ebx@14
  ITEMIDLIST *v13; // edi@15
  int v14; // eax@15
  int v15; // esi@15
  int v16; // eax@15
  int v17; // eax@20
  int v18; // edi@20
  const struct _ITEMIDLIST_RELATIVE *pidl; // [sp+Ch] [bp-Ch]@7
  ITEMIDLIST *pidla; // [sp+Ch] [bp-Ch]@13
  LPITEMIDLIST v21; // [sp+10h] [bp-8h]@1

  v21 = 0;
  v1 = this;
  v2 = SHFindDataBlock(*((_DWORD *)this + 57), 0xA000000B); 
  v3 = v2;
  
  if ( v2 )  //If the search is successful, then it will continue, otherwise release ILFree (pidla);)
  {
    if ( !CShellLink::_ShouldDecodeSpecialFolder(v1, (const struct _GUID *)(v2 + 8)) )
      goto LABEL_19;
    v4 = 0x4000;
    if ( *((_DWORD *)v1 + 65) & 0x400000 )
      v4 = 20480;
    v5 = SHGetKnownFolderIDList(v3 + 8, v4, 0, &v21);
    v6 = *(_DWORD *)(v3 + 24);
  }
  else
  {
    v17 = SHFindDataBlock(*((_DWORD *)v1 + 57), 0xA0000005);
    v18 = v17;
    if ( !v17 )
      goto LABEL_19;
    v21 = SHCloneSpecialIDList(0, *(_DWORD *)(v17 + 8), 0);
    v6 = *(_DWORD *)(v18 + 12);
    v5 = v21 != 0 ? 0 : -2147024882;
  }

Obviously, SHFindDataBlock is a failure, because the DataBlock she is searching for is missing. See the LNK file manual to see that the Extra Data structure is mentioned. It involves a lot of structure and its signature information, showing that the parameter when called above is its signature information, 0xA0000005, 0xA000000B

 ConsoleDataBlock - 0xA0000002
 ConsoleFEDataBlock - 0xA0000004
 EnvironmentVariableDataBlock - 0xA0000001
 IconEnvironmentDataBlock - 0xA0000007
 PropertyStoreDataBlock - 0xA0000009
 SpecialFolderDataBlock - 0xA0000005 (parameters mentioned in the function above)
 KnownFolderDataBlock - 0xA000000B (parameters mentioned in the function above)

Therefore, based on the CVE-2010-2568 sample, you can add an ExtraData data, and then add the SpecialFolderDataBlock and the KnownFolderDataBlock experiments. Specific format:

   Struct KnownFolderDataBlock{
    DWORD BlockSize;
DWORD BlockSignature;
CHAR GUID[16];
DWORD offset;
   }

   
   KnownFolderDataBlock:
   \x1C\x00\x00\x00\x0B\x00\x00\xA0\x19\x27\x6D\x74\x59\x74\x6A\x2D\x63\x1A\x9D\x7f\x63\x24\x8C\x6D\x00 \x00x00\x03

The GUID in the middle specifically points to the special file ID. It does not seem to be clear in the document. Only some GUIDs that exist already exist, and the test is repeated. There is no success (if there is a friend who has successfully tested, please also give pointers).

The structure of the SpecialFolderDataBlock is relatively simple:

   Struct SpecialFolderDataBlock{
    DWORD BlockSize;
DWORD BlockSignature;
DWORD ID;
DWORD offset;
   }


   Add these data: \x10\x00\x00\x00\x05\x00\x00\xA0\x03\x00\x00\x00\x28\x00\x00\x00\x00\x00

   Note that 0x28 inside is offset according to the manual.

A 32-bit, unsigned integer that specifies the location of the ItemID of the first child
Segment of the IDList specified by SpecialFolderID. This value is the offset, in bytes, into the

Link target IDList.

   Here I calculate the difference between SHITEMID[2] - SHITEMID[0].

   This way, you can see the call stackl where the .lnk file is loaded.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000080 00 00 00 6A 00 00 00 00 00 00 05 01 05 01 46 00 j F
00000090 3A 00 5C 00 2E 00 5C 00 2E 00 5C 00 2E 00 5C 00:... \ \ \ \
000000A0 2E 00 5C 00 2E 00 74 00 65 00 73 00 74 00 2E 00. \. T e s t.
000000B0 63 00 70 00 6C 00 00 00 c p l

The final loading situation: SHExpandEnvironmentStringsW will get the system directory and the following directory spliced into a system path SHELL32!CControlPanelFolder::_GetPidlFromAppletId+0x160:

75ec3da3 50 push eax
0:017> db eax
0583cde4 43 00 3a 00 5c 00 57 00-69 00 6e 00 64 00 6f 00 C.:.\.W.i.n.d.o.
0583cdf4 77 00 73 00 5c 00 73 00-79 00 73 00 74 00 65 00 w.s. \. S.y.s.t.e.
0583ce04 6d 00 33 00 32 00 5c 00-2e 00 74 00 65 00 73 00 m.3.2.\...t.e.s.
0583ce14 74 00 2e 00 63 00 70 00-6c 00 2c 00 00 00 15 09 t...c.p.l.,.....
0583ce24 38 ce 83 05 18 6f a0 76-d8 ed 15 09 70 f4 c6 75 8....o.v....p..u
0583ce34 53 00 6f 00 66 00 74 00-77 00 61 00 72 00 65 00 S.o.f.t.w.a.r.e.
0583ce44 5c 00 4d 00 69 00 63 00-72 00 6f 00 73 00 6f 00 \.M.i.c.r.o.s.o.
0583ce54 66 00 74 00 5c 00 57 00-69 00 6e 00 64 00 6f 00 f.t.\.W.i.n.d.o.

0:013> kv
ChildEBP RetAddr  Args to Child              
0499d114 75ec3f52 08ec3a48 0499d21c 75c70180 SHELL32!CControlPanelFolder::_GetPidlFromAppletId+0x181 (FPO: [Non-Fpo])
0499d140 75c5799b 08cabc38 00000000 08d5a800 SHELL32!CControlPanelFolder::ParseDisplayName+0x49 (FPO: [Non-Fpo])
0499d1c4 75c5f0af 090ddaac 00000000 08d5a800 SHELL32!CRegFolder::ParseDisplayName+0x93 (FPO: [Non-Fpo])
0499d238 75c606cd 090de3dc 00347098 75c7a660 SHELL32!ReparseRelativeIDList+0x137 (FPO: [Non-Fpo])
0499d27c 75c60715 00000000 00347070 08ead300 SHELL32!TranslateAliasWithEvent+0xa6 (FPO: [Non-Fpo])
0499d294 75c2e84e 00347070 08ead300 05c06258 SHELL32!TranslateAlias+0x15 (FPO: [Non-Fpo])
0499d2c0 75c2e5e3 00000000 00000000 05d5e0c8 SHELL32!CShellLink::_DecodeSpecialFolder+0xf9 (FPO: [Non-Fpo])
0499e584 75beca18 08f4c6d8 00000000 00000000 SHELL32!CShellLink::_LoadFromStream+0x39f (FPO: [Non-Fpo])
0499e7b4 75bec987 0499e840 00000000 0499e7f0 SHELL32!CShellLink::_LoadFromFile+0x90 (FPO: [Non-Fpo])
0499e7c4 75bec8dc 05d5e0dc 0499e840 00000000 SHELL32!CShellLink::Load+0x32 (FPO: [Non-Fpo])
0499e7f0 75bec933 05d5e0d0 0499e840 00000000 SHELL32!InitializeFileHandlerWithFile+0x6a (FPO: [Non-Fpo])
0499ea4c 75c38be0 00000000 0499eaa0 00000002 SHELL32!CFileSysItemString::HandlerCreateInstance+0x168 (FPO: [Non-Fpo])
0499eb04 75c42626 00000000 00000000 00000000 SHELL32!CFileSysItemString::LoadHandler+0x16b (FPO: [Non-Fpo])
0499efb4 75c42674 00000000 00000001 0499f00c SHELL32!CFSFolder::_BindHandler+0x1d1 (FPO: [Non-Fpo])
0499efd4 75bf9aa6 09058198 00000000 00000001 SHELL32!CFSFolder::GetUIObjectOf+0x21 (FPO: [Non-Fpo])
0499f490 75c3128d 09058180 05b4c0b8 05b4c0b8 SHELL32!CFSFolder::_GetPerceivedType+0x60 (FPO: [Non-Fpo])
0499f4b0 75c371fd 00000000 05b4c0b8 05b4c0b8 SHELL32!CFSFolder::_GetInnateDetailsFromHelper+0x47 (FPO: [Non-Fpo])
0499f4e0 75c31398 00000000 05b4c0b8 75c632ac SHELL32!CFSFolder::_GetInnateDetailsWithHandlerExceptions+0x61 (FPO: [Non-Fpo])
0499f4fc 75c3134c 05b4c0b8 75c632ac 0499f578 SHELL32!CFSFolder::_GetInnateDetails+0x18 (FPO: [Non-Fpo])
0499f538 75c312e9 05b4c0b8 75c632ac 0499f578 SHELL32!CFSFolder::_GetInnateDetailsAsVariant+0x41 (FPO: [Non-Fpo])
0499f580 75c0e197 09058198 05b4c0b8 75c632ac SHELL32!CFSFolder::GetDetailsEx+0x40 (FPO: [Non-Fpo])
0499f5b0 75c0ed8d 09058198 05b4c0b8 09056584 SHELL32!GetPerceivedType+0x44 (FPO: [Non-Fpo])
0499f5f8 75c0dc3a 0499f61c 08d6d4e0 09056584 SHELL32!GetFolderTypeFromItems+0xd8 (FPO: [Non-Fpo])
0499f63c 75c0d99c 08d6d4e0 09056584 09058198 SHELL32!CEnumTask::_CalculateFolderType+0x2f (FPO: [Non-Fpo])
0499f698 75c09e63 09058198 0499f6f0 0499f6ec SHELL32!CEnumTask::_IncrFillEnumToView+0x192 (FPO: [Non-Fpo])
0499f6f8 75c09fcd 09058198 00000001 755f81eb SHELL32!CEnumTask::_IncrEnumFolder+0x2b5 (FPO: [Non-Fpo])
0499f73c 75c38226 09056550 01000000 80000000 SHELL32!CEnumTask::InternalResumeRT+0x325 (FPO: [Non-Fpo])
0499f75c 75c761fb 09056564 7fffffff 05cb7708 SHELL32!CRunnableTask::Run+0xce (FPO: [Non-Fpo])
0499f778 75c78a8b 0499f7b4 00000000 090b62d8 SHELL32!CShellTask::TT_Run+0x167 (FPO: [Non-Fpo])
0499f7c0 75c78bbf 0499f7d8 7753b2b1 05cb7708 SHELL32!CShellTaskThread::ThreadProc+0xa3 (FPO: [Non-Fpo])
0499f7c8 7753b2b1 05cb7708 03de89a8 0499f84c SHELL32!CShellTaskThread::s_ThreadProc+0x1b (FPO: [Non-Fpo])
0499f7d8 773dd7c4 090b62d8 7322bf39 03de89a8 SHLWAPI!ExecuteWorkItemThreadProc+0xe (FPO: [Non-Fpo])

Microsoft's repair method is to judge in _IsRegisteredCPLApplet, the incoming DLL path to be loaded and the default existing .cpl path match, if the input path does not exist in the whitelist, then return False, no DLLs are loaded.

For the patch function: He wants to determine if it exists in a list. Get the first element first, then compare them in order: 76f136bb ff30 push dword ptr [eax] ds:0023:067f1170=038bf1a0

0:002> db 038bf1a0
038bf1a0 43 00 3a 00 5c 00 50 00-52 00 4f 00 47 00 52 00 C.:.\.P.R.O.G.R.
038bf1b0 41 00 7e 00 31 00 5c 00-4d 00 49 00 46 00 35 00 A.~.1.\.M.I.F.5.
038bf1c0 42 00 41 00 7e 00 31 00-5c 00 4f 00 66 00 66 00 B.A.~.1.\.O.f.f.
038bf1d0 69 00 63 00 65 00 31 00-34 00 5c 00 4d 00 4c 00 i.c.e.1.4.\.M.L.
038bf1e0 43 00 46 00 47 00 33 00-32 00 2e 00 43 00 50 00 C.F.G.3.2...C.P.
038bf1f0 4c 00 00 00 00 00 05 10-66 a6 ec 53 ff ff 00 8c L.......f..S....
038bf200 57 00 69 00 6e 00 64 00-6f 00 77 00 73 00 20 00 W.i.n.d.o.w.s.
038bf210 77 00 69 00 6c 00 6c 00-20 00 69 00 6e 00 73 00 w.i.l.l. .i.n.s.

Second cycle
0:002> db 0692e7d0
0692e7d0 43 00 3a 00 5c 00 57 00-69 00 6e 00 64 00 6f 00 C.:.\.W.i.n.d.o.
0692e7e0 77 00 73 00 5c 00 73 00-79 00 73 00 74 00 65 00 w.s.\.s.y.s.t.e.
0692e7f0 6d 00 33 00 32 00 5c 00-77 00 73 00 63 00 75 00 m.3.2.\.w.s.c.u.
0692e800 69 00 2e 00 63 00 70 00-6c 00 00 00 6c 00 00 00 i...c.p.l...l...
0692e810 33 f7 4b 53 01 00 00 80-14 00 4c 00 45 00 33 00 3.KS...L.E.3.
0692e820 43 00 42 00 46 00 39 00-32 00 41 00 33 00 34 00 C.B.F.9.2.A.3.4.
0692e830 36 00 46 00 33 00 34 00-30 00 42 00 31 00 39 00 6.F.3.4.0.B.1.9.
0692e840 31 00 35 00 38 00 43 00-32 00 35 00 42 00 43 00 1.5.8.C.2.5.B.C.
the third time:
0:002> db poi(eax)
0384a9c0 43 00 3a 00 5c 00 57 00-69 00 6e 00 64 00 6f 00 C.:.\.W.i.n.d.o.
0384a9d0 77 00 73 00 5c 00 73 00-79 00 73 00 74 00 65 00 w.s.\.s.y.s.t.e.
0384a9e0 6d 00 33 00 32 00 5c 00-46 00 6c 00 61 00 73 00 m.3.2.\.F.l.a.s.
0384a9f0 68 00 50 00 6c 00 61 00-79 00 65 00 72 00 43 00 h.P.l.a.y.e.r.C.
0384aa00 50 00 4c 00 41 00 70 00-70 00 2e 00 63 00 70 00 P.L.A.p.p...c.p.
0384aa10 6c 00 00 00 00 00 6e 00-ea 57 13 53 73 00 00 80 l.....n..W.Ss...
0384aa20 32 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 2...............
0384aa30 01 00 00 00 00 00 00 00-a0 71 60 06 e8 95 a5 76 .........q`....v

This way, even if you try to load the path, it will be rejected because it is no longer in the whitelist.

[0x05]. About detection

In order to detect this vulnerability generically, it needs to be an unconventional format detection for the shell item id list.

SHITEMID[0] = \x1F\x50\xE0\x4F\xD0\x20\xEA\x3A\x69\x10\xA2\xD8\x08\x00\x2B\x30\x9D
    SHITEMID[1] = \x2E\x1E\x20\x20\xEC\x21\xEA\x3A\x69\x10\xA2\xDD\x08\x00\x2B\x30\x30\x9D

In addition, for ExtraDtat:

ExtraData.BlockSize = 0x00000010
ExtraData.BlockSignature = 0xA0000005

The detection logic is as follows:

If(SHITEMID[0] == "\x1f \x50 ..." & SHITEMID[1] = "\x2e \x1f ...")
{
If(SHITEMID[2] in (".\\" || ".dll"))
{
If(ExtraData.BlockSize = 0x00000010 && ExtraData.BlockSignature = 0xA0000005)
{
Alert("Found CVE-2017-8464 Vulnerability\n");
}
}
}

[0x06].Other

Limited to the lack of understanding of KnownFolderDataBlock and a more in-depth analysis of related calls, it is not certain whether the KnownFolderDataBlock must be associated with this vulnerability, but apparently Microsoft. The way to fix this vulnerability is based on whitelist filtering. Even if the KnownFolderDataBlock can be triggered, it will not load successfully.

[references]

[MS-SHLLINK]-160714.pdf
Https://msdn.microsoft.com/en-us/library/dd891343.aspx

Liras en la red

Redes Sociales

martes, 4 de diciembre de 2018

Explanation of CVE-2017-8464

table of Contents

[0x01].Introduction

[0x02].lnk file format parsing

[0x03]. Patch comparison

[0x04]. Vulnerability analysis

[0x05]. About detection

[0x06].Other

[0x01].Introduction

[0x02].lnk file format parsing

[0x03]. Patch comparison

[0x04]. Vulnerability analysis

[0x05]. About detection

[0x06].Other

[references]

1 comentario: