Hi, I am Trung (xikhud). Last month, I joined Qrious Secure team as a new member, and my first target was to find and reproduce the security bugs that @bienpnn used at the Pwn2Own Vancouver 2023 to escape the VirtualBox VM.
Since VirtualBox is an open-source software, I can just download the source code from their homepage. The version of VirtualBox at the time of the Pwn2Own competition was 7.0.6.
Exploring VirtualBox
Building VirtualBox
The very first thing I did is to build the VirtualBox and to have a debugging environment. VirtualBox’s developers have published a very detail guide to build it. My setup is below:
Host: Windows 10
Guest: Windows 10. VirtualBox will be built on this machine.
Guest 2 (the guest inside the VirtualBox VM): LUbuntu 18.04.3
If you are new to VirtualBox exploitation, you may wonder why I need to install a nested VM. The reason is that VirtualBox contains both kernel mode and user mode components, so I have to install it inside a VM to debug its kernel things.
The official building guide offers using VS2010 or VS2019 to build VirtualBox, but you have to use VS2019 to build the version 7.0.6.
You can use any other operating system for Guest 2. I choose LUbuntu because it is lightweight. (I have a potato computer lol).
Learning VirtualBox source code
VirtualBox source code is large, I can’t just read all of them in a short amount of time. Instead, I find blog posts about pwning VirtualBox on Google and read them. These posts not only show how to exploit VirtualBox but also describe how VirtualBox works, its architecture and stuff like that. These are the very good write-ups that I also recommend you to read if you want to start learning VirtualBox exploitation:
The simple rule I learned is that when the guest wants to emulate a device, it send a request to the host’s kernel drivers (R0) first. The host’s kernel have two choices:
It can handle that request
Or it can return
VINF_XXX_R3_YYYY_ZZZZ
. This value means that it doesn’t want to handle the request and the request will be handled by the host’s user mode components (R3).
The source code for R0 and R3 is usually in the same file, the only different thing is the preprocessors.
#define IN_RING3
corresponds to R3 components
#define IN_RING0
corresponds to R0 components
#define IN_RC
: I don’t know what this is, maybe someone knows can tell me …
For example, let’s look at the code in the
DevTpm.cpp
file:
In the image above, when the R0 component receives this request, it will pass to R3 component. The return code (
rc
) is
VINF_IOM_R3_MMIO_WRITE
. According to the source code comment, it is “Reason for leaving RZ: MMIO write”. There are other similar values:
VINF_IOM_R3_MMIO_READ
,
VINF_IOM_R3_IOPORT_WRITE
,
VINF_IOM_R3_IOPORT_READ
, …
If you want to know more detail about VirtualBox architechture, I suggest you to read the slide by Chen Nan. You can also watch his video here.
After having a basic understanding about VirtualBox, the next thing I did is to find some attack vectors. Usually, with VirtualBox, the attack scenario will be an untrusted code running within the guest machine. It will communicate with the host to compromise it. There are two methods a guest OS can talk to the host:
Using memory mapped I/O
Using port I/O
These are usually the entry points of an attack, so I look at them first when auditing.
The memory mapped region can be created by these functions:
PDMDevHlpMmioCreateAndMap
PDMDevHlpMmioCreateExAndMap
...
The IO port can be created by:
PDMDevHlpIoPortCreateFlagsAndMap
PDMDevHlpPCIIORegionCreateIo
PDMDevHlpPCIIORegionCreateMmio2Ex
...
With memory mapped, we can use the
mov
or similar instructions to communicate with the host. Meanwhile, we use
in
,
out
instruction when we work with IO port.
Now I have more understanding about VirtualBox, I can start to look for bugs now. To reduce the time, @bienpnn gave me 2 hints:
The OOB write bug is in the TPM components
The OOB read bug is in the VGA components
Knowing that, I open the source code and read files in
src/VBox/Devices/Security
and
src/VBox/Devices/Graphics
folders.
The OOB write bug
At Pwn2Own, the TPM 2.0 is enabled. It is required to run Windows 11 inside VirtualBox. You will have to enable it manually in the VirtualBox GUI, if you don’t, then the exploit here won’t work.
The TPM module is initialized by the two functions
You can see that there is a branch of code that does a
memcpy
into the
u64
, which is a stack variable of
tpmMmioRead
function. To be able to reach this branch,
uReg
,
bLoc
and
pThis->enmState
must have appropriate values. But don’t worry because we can control all of them, we can also control
pThis->offCmdResp
and
pThis->abCmdResp
. There is no check to make sure
cb <= sizeof(uint64_t)
, so maybe there is a stack buffer overflow here? Now I have to find a way to make
cb
larger than
sizeof(uint64_t)
(8). I google and found that some AVX-512 instructions can read up to 512 bits (64 bytes) memory. Since my CPU doesn’t support AVX-512, I try AVX2 instead:
__m256 z = _mm256_load_ps((const float*)off);
Indeed, it works!
cb
is now
0x20
and I can overwrite 0x18 bytes after
u64
variable. But the is a problem:
u64
is behind the return address of
VBoxDDR0!tpmMmioRead
. Let’s look at the stack when RIP is at the very first instruction of
, but the function only allocate 0x48 bytes for the stack. Clearly,
pu64
is outside of the stack frame range. So in which function stack frame does this variable belong to? Well, it is right next to the return address, so it is in the shadow space. Turned out that, the shadow space is used to make debugging easier. But we are using the “Release” build, so it will use the shadow space as if it is a normal space. We can overwrite 0x18 bytes after the
u64
variable. Unfortunately, there is no data after
u64
so we can’t do anything. I’m stuck now. Maybe if my CPU supports AVX-512, I can do something? Until now, @bienpnn told me that there is an instruction which can read up to 512 bytes. It is
fxrstor
, which is used to restore x87 FPU, MMX, XMM, and MXCSR state. Knowing this, I tried this code:
_fxrstor64((void*)off);
And then, VirtualBox.exe crashed! That’s good. But wait, why does it crash without first hitting the breakpoint at
VBoxDDR0!tpmMmioRead
? Turned out that all the request with
cb >= 0x80
will be handled by R3 code. This is the comment in
src\VBox\VMM\VMMAll\IOMAllMmioNew.cpp
:
/*
* If someone is doing FXSAVE, FXRSTOR, XSAVE, XRSTOR or other stuff dealing with
* large amounts of data, just go to ring-3 where we don't need to deal with partial
* successes. No chance any of these will be problematic read-modify-write stuff.
*
* Also drop back if the ring-0 registration entry isn't actually used.
*/
Let’s trigger this bug again. But this time we will set a breakpoint at
VBoxDD!tpmMmioRead
instead. And now I can see a stack buffer overflow.
Really nice. Now we have RIP controlled, but don’t know where to jump. We need a leak.
The OOB read bug
The OOB read bug is inside
VGA
module. There are a lot of files belong to this module, but I choose to read
DevVGA.cpp
first, since the name looks like the main file of VGA module. I look at the 2 construction functions to see which IO port or memory mapped is used. I found that the
vgaMmioRead
will handle the MMIO request, it will then call
vga_mem_readb
. And inside this function, I found the code below (we can control
*(uint32_t *)(pThisCC->svga.pbVgaFrameBufferR3 + sizeof(uint32_t) * addr) // note that the type of pThisCC->svga.pbVgaFrameBufferR3 is uint8_t[]
he code checks if
addr < VMSVGA_VGA_FB_BACKUP_SIZE
, but actually uses
4 * addr
for indexing. It means that we have an OOB read here. Untill now, I thought that it will be easy because with a leak and a stack buffer overflow, I would easily do a ROP chain. But I regret soon when I see that the heap layout is not static, it changes everytime I open a new VirtualBox process. The reason for this is because VirtualBox is a very complex software, so heap allocations are made everywhere, which changes the shape of the heap.
Exploitation
Now I need a reliable way to have a leak. For this, I will use heap spraying technique. So my plan is to poison the heap with a lot of objects that I control, and (hopefully) some of the objects will be right behind the
pbVgaFrameBufferR3
buffer so that I can use the OOB read to leak information. sauercl0ud team had already written a nice blog post about exploiting VirtualBox. Inside the post, they sprayed the heap with
HGCMMsgCall
objects, I will just use
HGCMMsgCall
too, because why not 😀 ?
What is HGCM?
HGCM is an abbreviation for “Host/Guest Communication Manager”. This is the module used for communication between the host and the guest. For example, they need to talk to each other in order to implement the “Shared Clipboard”, “Shared Folder”, “Drag and drop” services.
Here’s how it works. The guest inside VirtualBox will have to install additional drivers, a.k.a the guest additions. When the guest wants to use one of the service above, it will send a message to the host through IO port, the message is represented by the
void spray()
{
int rc;
for (int i = 0; i < 64; ++i)
{
int32_t clientId;
rc = hgcm_connect("VBoxGuestPropSvc", &clientId);
for (int j = 0; j < 16 - 1; ++j)
{
char pattern[0x70];
char out[2];
rc = wait_prop(clientId, pattern, strlen(pattern) + 1, out, sizeof(out)); // call VBoxGuestPropSvc HGCM service, this will allocate a HGCMMsgCall
}
}
}
After some observation, I realize that the
vtable
is usually
0x7F??????AD90
. Only the
?
part is randomized, I will use this information to identify a
HGCMMsgCall
on the heap. My approach is simple: I just keep reading a qword (8 bytes) each time, called
X
. I will then check if
(X & 0xFFFF) == 0xAD90
and
(X >> 40) == 0x7F
. If this is true, we likely to reach a
HGCMMsgCall
, and X is the
vtable
pointer. To leak heap address, I will do like this (this idea is also taken from Sauercl0ud blog):
Find a
HGCMMsgCall
on the heap. Let’s call this object
A
and let’s call
a
the offset from the
pbVgaFrameBufferR3
buffer to this object.
Find another
HGCMMsgCall
.
B
and
b
are the same as above, and
b > a
.
If
A->m_pNext - B->m_pPrev == b - a
, then it’s likely that
A->m_pNext
is the address of
B
. It means that
A->m_pNext - b
is the address of
pbVgaFrameBufferR3
buffer.
Actually I don’t need a heap leak to make a ROP chain, only a DLL leak is enough. But I want to show you this method so that you can make a longer ROP chain in case you need it.
Now I have enough information to write an exploit.
Testing out the exploitation idea
I implement the idea above, and run the exploit for 20 times and not a single time success. That’s 0% of success rate, very bad. Most of the time, VirtualBox just crashes. I attached a debugger and ran the exploit again, the crash happened when trying to read an address that had not been mapped. Turned out that I could read up to
0x180000
bytes (1.5MB) after the
pbVgaFrameBufferR3
buffer, but most of the time there is only about ~
0xC0000
bytes that had been mapped. Another crash I found is when the exploit was trying to read an address inside a guard page. Another problem I had is that the exploit run really slow, because the OOB bug only lets me read 1 byte at a time. I need to improve the speed of the exploit as well.
Parsing heap header to avoid unmmaped pages and increase speed
Until now, I have a new idea: parsing the heap chunk headers on the heap to gain more information. First thing I want to do is to read some information about a chunk, for example, the size of the chunk, is it freed or in used? If I can do this, maybe I will be able to skip some unnecessary chunks. To make this idea come true, I have to learn some Windows heap internal. I recommend you to read these:
? I don’t know a good way to decode it, so I just run VirtualBox multiple times and observe that most of the time chunk
A
is in used. So if any other chunk has the LSB bit of
Flags
equals to the LSB bit of
A->Flags
, then it is also in used and vice versa. With this informaton, I can walk the heap easily, the algorithm looks like this:
uint32_t curOffset = 0x80000;
while (curOffset < 0x200000) { // 0x200000 is the maximum we can touch
HEAP_ENTRY hE;
readHeapEntry(curOffset, &hE);
if (isInUsed(&hE))
findSprayedObjects(curOffset, &hE);
curOffset += ((hE.Size ^ KeyToDecodeSize) << 4); // 1 block is 16 bytes
}
Now my exploit runs a lot faster, also the success rate is increased a little. But sometime the exploit still crashed VirtualBox. I attach Windbg and see that it was trying to access a guard page, and this guard page is inside an in-used chunk. After a few days of researching, I finally knew that chunk was a
Heap fragmentation is a state in which available memory is broken into small, noncontiguous blocks. When a heap is fragmented, memory allocation can fail even when the total available memory in the heap is enough to satisfy a request, because no single block of memory is large enough. The low-fragmentation heap (LFH) helps to reduce heap fragmentation. The LFH is not a separate heap. Instead, it is a policy that applications can enable for their heaps. When the LFH is enabled, the system allocates memory in certain predetermined sizes
When an application makes more than 17 allocations of the same size, the LFH will be turned on (for that size only). We spray a lot of objects (more than 17), so they will all be served by the LFH. Basically this is how LFH works:
A big chunk will be allocated, this is a
UserBlocks
struct. A
UserBlocks
contains some metadata and a lot of small chunks.
Any heap allocation after that will return a (freed) small chunk in the
is also a regullar chunk, so it is in the “user data” part of another
HEAP_ENTRY
.
Signature
is always
0xF0E0D0C0
, so we can easily find it in the heap.
GuardPagePresent
: if this is non zero, the
UserBlocks
has a page guard at the end, so we can skip
0x1000
bytes at the end, preventing crashes.
BusyBitmap
contains the address of
BitmapData
. This can be used as a reliable way to leak heap address too
Knowing that all the
HGCMMsgCall
sprayed by us will be served by LFH, I will only find them in a
UserBlocks
. This makes the exploit run a lot of faster than the first exploit I made.
More success rate, more speed
I also noted that each time I want to send a HGCM message, I have to create a
HGCMClient
. Since there are many
HGCMClient
s being allocated when spraying, I also look for their
vtable
pointer.
One more thing is that every chunk address will have to be the multiple of
0x10
, so I only read qwords at these locations to find
vtable
. This will also increase the speed of my exploit.
Conclusion
I would like to give a special thanks to my mentor @bienpnn, who was actively helping me throughout the project. This is my first time exploiting a real Windows software so it is really fun. After this project, I learned more about Windows heap internal, how a hypervisor works, how to debug Windows kernel and a ton of other knowledge. I hope this post can help you if you are about to target VirtualBox, and see you in another blog post!
And @herrcore (Thanks for his suggestion in private chat)
2. Code analysis
I received a suspicious Dll that needs to be analyzed. This Dll is packed. After unpacking it and throwing the Dll into IDA, IDA successfully analyzed it with over 7000 functions (including API/library function calls). Upon quickly examining at the Strings tab, I came across numerous strings in the following format:
Based on the information provided, I believe these strings have definitely been encrypted. Going through the code snippet using an arbitrary string, I found the corresponding assembly code and pseudocode as follows (function and variable names have been changed accordingly):
With the image above, it is easy to see:
The
<mark><strong>EAX</strong> </mark>
register will hold the address of the encrypted string.
The
<mark><strong>EDX</strong> </mark>
register will hold the address of the string after decryption.
After going around various functions and thinking about how to code, I started feeling increasingly discouraged. Moreover, when examining the cross-references to the
<mark>mw_decrypt_str_wrap </mark>
function, I noticed that it was called over 4000 times to decrypt strings… WTF 😐
3. Use dumpulator
As shown in the above image, there are too many function calls to the decryption function. Moreover, rewriting this decryption function would be time-consuming and require code debugging for verification. I think I need to find a way to emulate this function to perform the decryption step and retrieve the decrypted string. Several solutions came to mind, and I also asked my brother, who suggested using x or y solutions. After some trial and error, I decided to try using dumpulator. To be able to use dumpulator, we first need to create a minidump file of this DLL (dump when halted at DllEntryPoint). After obtaining the dump file, I tested the following code snippet:
I’ve really enjoyed reversing cheap/weird IoT devices in my free time. In early May of 2022, I went on an Amazon/AliExpress shopping spree and purchased ~15 cheap IoT devices. Among them was this mini portable router by GL.iNET.
GL.iNET is a leading developer of OpenWrt Wi-Fi and IoT network solutions and to my knowledge is a Chinese company based out in Hong Kong & USA. They offer a wide variety of products, and the company’s official website is www.gl-inet.com. The GL-MT300N-V2 firmware version I dove into was
V3.212
released on April 29th, 2022 for the Mango model. The goodcloud remote cloud management gateway was
Version 1.00.220412.00
.
This blog will be separated into two sections. The first half contains software vulnerabilities, this includes the local web application and the remote cloud peripherals. The second mainly consists of an attempted hardware teardown.
I like to give credit where credit is due. The GL.iNET team was really awesome to work & communicate with. They genuinely care about the security posture of their products. So I'd like to give some quick praise for being an awesome vendor that kept me in the loop throughout the patching/disclosure process.
In terms of overall timeline/transparency, I started testing on-and-off between
May 2nd 2022
to
June 15th 2022
. After reporting the initial command injection vulnerability GL.iNET asked if I were interested in monetary compensation to find additional bugs. We ultimately agreed to public disclosure & the release of this blog in exchange for continued testing. As a result, I was given safe passage and continued to act in good faith. Lastly, the GL.iNet also shipped me their (GL-AX1800 / Flint) for additional testing. GL.iNet does nothave a BBP or VDP program, I asked, and was given permission to perform the tests I did. In other words, think twice before poking at their infrastructure and being a nuisance.
Having vulnerabilities reported should never be seen as a defeat or failure. Development and security are intertwined in a never ending cycle. There will always be vulnerabilities in all products that take risks on creativity, innovation, and change - the essence of pioneering.
Vulnerabilities List
A total of 6 vulnerabilities were identified in GL.iNet routers and IoT cloud gateway peripheral web applications:
1. OS command injection on router & cloud gateway (CVE-2022-31898)
2. Arbitrary file read on router via cloud gateway (CVE-2022-42055)
3. PII data leakage via user enumeration leading to account takeover
4. Account takeover via stored cross-site scripting (CVE-2022-42054)
5. Account takeover via weak password requirements & lack of rate limiting
6. Password policy bypass leading to single character passwords
Web Application
OS Command Injection
The MT300N-V2 portable router is affected by an OS Command Injection vulnerability that allows authenticated attackers to run arbitrary commands on the affected system as the application’s user. This vulnerability exists within the local web interface and remote cloud interface. This vulnerability stems from improper validation of input passed through the ping (
ping_addr
) and traceroute (
trace_addr
) parameters. The vulnerability affects ALL GL.iNET product’s firmware
CVE ID: CVE-2022-31898
Access Vector: Remote/Adjacent
Security Risk: High
Vulnerability: CWE-78
CVSS Base Score: 8.4
CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
I’ll run through the entire discovery process. There exists a file on disk
/www/src/router/router.js
which essentially manages the application panels. Think of it as the endpoint reference in charge of calling different features and functionality. As seen below, the path parameter points to the endpoint containing the router feature’s location on disk. When the endpoint such as
/attools
is fetched its respective
.js
,
.html
, and
.css
files are loaded onto the page.
Through this endpoint, I quickly discovered that a lot of these panels were not actually accessible through the web UI’s sidebar seen below.
However, the functionality of these endpoints existed and were properly configured & referenced. Visually speaking, within the application they don’t have a sidebar «button» or action that can redirect us to it.
Here is a full list of endpoints that can not be accessed through web UI actions.
I should mention that some of these endpoints do become available after connecting modems, and other peripheral devices to the router. See the documentation for more details https://docs.gl-inet.com/.
As seen above, there exists a
ping
endpoint. From experience, these are always interesting. This endpoint has the ability to perform typical
ping
and
traceroute
commands. Let’s quickly confirm that these files exist,
/ping
actions get called as defined within the
router.js
file.
root@GL-MT300N-V2:/www/src/temple/ping# pwd && ls /www/src/temple/ping index.CSS index.html index.js
The expected usage and output can be seen below.
What’s OS Command Injection? OS command injection is a fairly common vulnerability seen in such endpoints. Its typically exploited by using command operators (
|
,
&&
,
;
, etc,) that would allow you to execute multiple commands in succession, regardless of whether each previous command succeeds.
Looking back at the ping portal, the UI (frontend) sanitizes the user-provided input against the following regex which is a very common implementation for validating IPv4 addresses.
Therefore,
;
isn’t an expected IPv4 schema character so when the
pingIP()
check is performed, and any invalid characters will fail the request.
And we’re presented with the following error message.
We need to feed malicious content into the parameter
pingValue
. If we do this successfully and don’t fail the check, our request will be sent to the web server where the server application act upon the input.
To circumvent the input sanitization on the front-end we will send our post request to the webserver directly using Burp Suite. This way we can simply modify the POST request without the front-end sanitization being forced. As mentioned above, using the
;
command separator we should be able to achieve command injection through the
Cool, but this attack scenario kinda sucks… we need to be authenticated, on the same network, etc, etc. One of the main reasons I think this is a cool find, and why it’s not simply a local attack vector is that we can configure our device with the vendor’s IoT cloud gateway! This cloud gateway allows us to deploy and manage our connected IoT gateways remotely.
I’ve discovered that there are roughly
~30000
devices configured this way. One of the features of this cloud management portal is the ability to access your device’s admin panel remotely through a public-facing endpoint. Such can be seen below.
As you may have guessed, command injection could be performed from this endpoint as well.
In theory, any attacker with the ability to hijack goodcloud.xyz user sessions or compromise a user account (both achieved in this blog) could potentially leverage this attack vector to gain a foothold on a network compromise.
Additional things you can do:
Scan internal network:
GET /cgi-bin/api/repeater/scan
Obtain WiFi password of joined SSID's
GET /cgi-bin/api/repeater/manager/list
Obtain WiFi password of routers SSID's
GET /cgi-bin/api/ap/info
Disclosure Timeline
May 2, 2022: Initial discovery May 2, 2020: Vendor contacted May 3, 2022: Vulnerability reported to the vendor May 10, 2022: Vulnerability confirmed by the vendor July 6, 2022: CVE reserved July 7, 2022: Follow up with the vendor October 13, 2022: Fixed in firmware 3.215
Arbitrary File Read
The MT300N-V2 portable router, configured along sides the vendor’s cloud management gateway (goodcloud.xyz) is vulnerable to Arbitrary File Read. The remote cloud gateway is intended to facilitate remote device access and management. This vulnerability exists within the cloud manager web interface and is only a feature available to enterprise users. The device editing interface tools harbors the
ping
and
traceroute
functionality which is vulnerable to a broken type of command injection whose behavior is limited to performing arbitrary file reads. Successful exploitation of this vulnerability will allow an attacker to access sensitive files and data on the router. It is possible to read any arbitrary files on the file system, including application source code, configuration, and other critical system files.
Vulnerability Details
CVE ID: CVE-2022-42055
Access Vector: Remote
Security Risk: Medium
Vulnerability: CWE-23 & CWE-25
CVSS Base Score: 6.5
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Enterprise users will have the
TOOLS
menu when editing their devices as seen below.
The
ping_addr
and
trace_addr
both allow you to read any file on disk when prepending
;/bin/sh
to the file you want to read.
I’m not sure why this happens. I have not been able to get regular command injection due to the way its calling
ping
and
traceroute
within busybox from what I assume is data passing through something similar to a ngrok tunnel. I can’t use funky delimiters or common escapes to simply comment out the rest of the operation. Anyhow, valid payloads would look like the following:
on my router and I’m going to read it from the cloud gateway. I could just as easily read the
passwd
and
shadow
files. Successfully cracking them offline would allow me access to both the cloud ssh terminal, and the login UI.
Funny enough, this action can then be seen getting processed by the logs on the cloud gateway. So definitely not «OPSEC» friendly.
Disclosure Timeline
May 25, 2022: Initial discovery May 25, 2022: Vendor contacted & vulnerability reported May 26, 2022: Vendor confirms vulnerability July 7, 2022: Follow up with the vendor October 13, 2022: Fixed in firmware 3.215
PII Data Leakage & User Enumeration
The MT300N-V2 portable router has the ability to be configured along sides the vendor’s cloud management gateway (goodcloud.xyz) which allows for remote access and management. This vulnerability exists within the cloud manager web interface through the device-sharing endpoint
cloud-api/cloud/user/get-user?nameoremail=
GET request. Successful enumeration of a user will result in that user’s PII information being disclosed. At its core, this is a funky IDOR. The vulnerability affected the goodcloud.xyz prior to May, 12th 2022.
Vulnerability Details
CVE ID: N/A
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-200 & CWE-203
CVSS Base Score: 6.5
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
I identified roughly
~30,000
users which were enumerated via their username or email address. Successful enumeration compromises the confidentiality of the user. This vulnerability returns sensitive information that could be leveraged by a sophisticated, and motivated attacker to compromise the user’s account credentials.
This attack is performed after creating a regular
goodcloud.xyz
cloud gateway account and linking your GL.iNet device. In the image below we see that our device can be shared with another registered user.
The request and response for sharing a device with another user are seen below.
Performing this
get-user
request against an existing user will disclosure the following account information:
- company name
- account creation time
- credential's salt (string+MD5)
- account email
- account user ID
- last login time
- nickname
- password hash (MD5)
- phone number
- password salt (MD5)
- secret key
- security value (boolean)
- status value (boolean)
- account last updated time
- application user id
- username
The password appears to be MD5 HMAC but the actual formatting/order is unknown, and not something I deem necessary to figure out. That being said, given all the information retrieved from the disclosure I believe the chances of finding the right combination to be fairly high. Below is an example of how it could be retrieved.
Additionally, I discovered no rate-limiting mechanisms in place for sharing devices. Therefore, it’s relatively easy to enumerate a good majority of valid application users using Burp Suite intruder.
Another observation I made, which was not confirmed with the vendor (so is purely speculation) I noticed that not every user had a
secret
value associated with their account. I suspect that perhaps this secret code is actually leveraged for the 2FA QR code creation mechanism. The syntax would resemble something like this:
The GL.iNET team was extremely quick to remediate this issue. Less than 12h after reporting it a fix was applied as seen below.
Disclosure Timeline
May 11, 2022: Initial discovery May 11, 2022: Vendor contacted & vulnerability reported May 11, 2022: Vendor confirms vulnerability May 12, 2022: Vendor patched the vulnerability
Stored Cross-Site Scripting
The MT300N-V2 portable router has the ability to join itself to the remote cloud management configuration gateway (goodcloud.xyz) which allows for remote management of linked IoT devices. There exist multiple user input fields that do not properly sanitize user-supplied input. As a result, the application is vulnerable to stored cross-site scripting attacks. If this attack is leveraged against an enterprise account through the
Sub Account
invitation it can lead to the account takeover of the joined accounts.
Vulnerability Details
CVE ID: CVE-2022-42054
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-79
CVSS Base Score: 8.7
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:H
We’ll find the vulnerable inputs field in the «Group Lists» panel, in which a user can modify and create as many groups as they want.
The vulnerable fields are
Company
and
Description
. The payloads I used as a proof of concept are the following:
<img src=x onerror=confirm(document.cookie)>
or
<img src=x onerror=alert(document.cookie)>
Once the group is saved anytime the user either logs in or switches regions (Asia Pacific, America, Europe), logs in, or switched organication the XSS will trigger as seen below.
Can this be used maliciously? Unfortunately not with regular user accounts. With enterprise accounts yes, as we’ll see later. Here’s why. Realistically the only way to leverage this would be to share a device with a malicious named
company
and
description
fields with another user.
Even with the patch for the PII and User Enumeration vulnerability above, it is still possible to enumerate
userID
‘s which is exactly what we need to send a shared device invitation to users. Below is an example request.
An attacker with a regular user account would create a group with a
. Then invite a victim to that group. When the victim would login the attacker would able to steal their sessions. Unfortunately with a regular user account, this isn’t possible.
If we share the device from
boschko
(attacker) to
boschko1
(victim). Here’s how the chain would go. After
boschko
creates the malicious group and sends an invitation to
boschko1
he’s done. The victim
boschko1
would login and receive the invite from
boschko
as seen below.
However, when we sign-out and back into
boschko1
no XSS triggered, why? It’s because there is a difference between being a member of a shared group (a group shared by another user with you) and being the owner (you made the group shared and created) as can be seen below.
As seen above, a user of a shared group won’t have the malicious fields of the group translated to their «frontend».
HOWEVER! If you have a business/enterprise account or are logged in as a business/enterprise user you can leverage this stored XSS to hijack user sessions! All thanks to features only available to business users :).
Business features provide the ability to add «Sub Accounts». You can think of this as having the ability to enroll staff/employees into your management console/organization. If a user accepts our
subAccount
invitation they become a staff/employee inside of our «organization». In doing so, we’ll have the ability to steal their fresh session cookies after they login because they’d become owners of the malicious group by association.
Let’s take this one step at a time. The Subscription Account panel looks like this.
I’m sure you can make out its general functionality. After inviting a user via their email address they will receive the following email.
I’ll try and break this down as clearly as I can.
User A (attacker) is
boschko
in red highlights.
User B (victim) is
boschko1
in green highlights.
Step 1: Create a malicious company as
boschko
with XSS company name and description
Step 2: Invite
boschko1
to the malicious company as
boschko
Step 3: Get boschko1 cookies and use them to log in as him
Below is the user info of
boschko
who owns the company/organization
test
. He also owns the «Group List»
happy company
the group which is part of the
test
organization.
boschko1
has been sent an invitation email from
boschko
,
boschko1
has accepted and has been enrolled into
boschko
‘s
test
organization.
boschko1
has been given the
Deployment Operator
level access over the organization.
Logged into
boschko1
the user would see the following two «workspaces», his personal
boschko1 (mine)
and the one he has been invited to
test
.
When
boschko1
is signed into his own team/organization
boschko1 (mine)
, if devices are shared with him nothing bad happens.
When
boschko1
signes into the
test
organization that
boschko
owns by
Switch Teams
the malicious
company
and
description
are properly referenced/called upon when
listQuery
action.
The stored XSS in the malicious
test
company,
company
and
description
fields (members of the
happy company
Group List) gets trigger when
boschko1
is signed into
boschko
organization
test
.
From our malicious
boschko
user, we will create a group with the following malicious
We can leverage the following website since we’re too lazy to spin up a digital ocean droplet. With this webhook in hand, we’re ready to steal the cookies of
boschko1
.
Above,
boschko
has stored the malicious javascript within his
company
and
description
fields simply log
boschko1
into the
test
organization owned by
boschko
and receive the cookies via the webhook.
As seen below, we get a bunch of requests made containing the session cookies of
boschko1
.
Using the stolen
boschko1
session cookies the account can be hijacked.
The GL.iNET team remediated the issue by July 15 with some pretty solid/standard filtering.
I attempted a handful of bypasses with U+FF1C and U+FF1E, some more funky keyword filtering, substrings, array methods, etc, and had no success bypassing the patch.
Disclosure Timeline
May 12, 2022: Initial discovery May 12, 2022: Vendor contacted & vulnerability reported May 13, 2022: Vendor confirms vulnerability May 19, 2022: Contact vendor about enterprise user impact July 7, 2022: Follow up with the vendor July 15, 2022: Vendor patched the vulnerability
Weak Password Requirements & No Rate Limiting
The MT300N-V2 portable router has the ability to join itself to the remote cloud management configuration gateway with its accounts created through goodcloud.xyz which allows for remote management of linked IoT devices. The login for goodcloud.xyz was observed to have no rate limiting. Additionally, user passwords only require a minimum of 6 characters and no special characters/password policy. This makes it extremely simple for an attacker to brute force user accounts leading to account takeover.
Vulnerability Details
CVE ID: N/A
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-521
CVSS Base Score: 9.3
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
As seen below when users create their cloud gateway
goodcloud.xyz
accounts they’re only required to have a password ≥6 with no capitalization, or special characters being required or enforced.
Additionally, due to having no rate limiting on login attempts by using Burp Suite intruder it’s trivial to spray users or brute force user accounts.
Below is an example of successfully obtaining the password for a sprayed user.
In total, I was able to recover the passwords of
33
application users. I never tested these credentials to log into the UI for obvious ethical reasons. All the data was reported back to the GL.iNET team.
Disclosure Timeline
May 18, 2022: Initial discovery May 24, 2022: Vendor contacted & vulnerability reported May 24, 2022: Vendor confirms vulnerability June 7, 2022: Vendor implements rate-limiting, patching the vulnerability
Password Policy Bypass
The MT300N-V2 portable router has the ability to join itself to the remote cloud management configuration gateway (goodcloud.xyz) which allows for remote management of linked IoT devices. For these cloud gateway accounts, while password complexity requirements were implemented in the original signup page, these were not added to the password reset page. The current lack of rate limiting this severely impacts the security posture of the affected users.
Vulnerability Details
CVE ID: N/A
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-521
CVSS Base Score: 6.7
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
The reset password policy isn’t consistent with the registration and change password policy. As a result, it’s possible to bypass the 6-character password requirements to a single character. In general, the application should validate that the password contains alphanumeric characters and special characters with a minimum length of around eight. Additionally, I feel like it’s best practice not to allow users to set the previously used password as the new password.
As seen below, through the UI the password change has checks on the client side to ensure the password policy is respected.
In Burp Suite we can intercept the request and manually set it to a single character.
The request above is submitting successfully, and the new password for the
boschko
user has been set to
1
. The request below is the login request, as you can see it was successful.
Disclosure Timeline
May 26, 2022: Initial discovery May 26, 2022: Vendor contacted & vulnerability reported May 26, 2022: Vendor confirms vulnerability July 7, 2022: Follow up with the vendor July 15, 2022: Vulnerability has been patched
Additional Interesting Finds
I made a few interesting discoveries that I don’t consider vulnerabilities.
Before we jump into this one we have to quickly talk about ACL configuration. Basically, for
rpc
having appropriate access control over the invocations the application can make is very important. These methods should be strictly controlled. For more information on this refer to the Ubus-Wiki.
Once we’ve installed OpenWrt as seen above, the application will generate the list of
rpc
invocation methods for OpenWrt which is defined within the ACL configuration file
Not being a subject matter expert, I would however say that the above methods are well-defined. Methods in the file namespace aren’t simply «allow all» —
( "file": [ "*" ] )
if it were the case, then this would be an actual vulnerability.
rpcd
has also a defined user in
/etc/config/rpcd
that we can use for the management interface. This user is used to execute code through a large number of
rpcd
exposed methods.
With this information in hand, we should be able to login with these credentials. As a result, we will obtain a large number of methods that can be called, and get the
ubus_rpc_session
.
As seen in the following image this
ubus_rpc_session
value is used to call other methods defined in ACL config files.
Now we might look at the image above and think we have RCE of sorts. However, for some weird reason
/etc/passwd
is actually defined with valid read primitives within the
luci-base.json
ACL config file.
As seen below attempting to read any other files will result in a failed operation.
I simply found this interesting hence why I am writing about it.
Hardware Teardown
Let’s actually start the intended project! The GL-MT300N router looks like this:
It’s nothing fancy, the device has a USB port, 2 ethernet ports (LAN & WAN), a reset button, and a mode switch. Let’s break it open and see what hardware we have on hand.
Immediately there are some interesting components. There looks to be a system on a chip (SoC), SPI flash, and some SD RAM. There is also a serial port and what looks like could potentially be JTAG, and almost definitely UART.
In terms of chipsets, there is a MediaTek MT7628NN chip which is described as being a «router on a chip» the datasheet shows it is basically the CPU and it supports the requirements for the entry-level AP/router.
Looking at the diagram of the chip there is communication for UART, SPI, and I2C which are required to transfer data. This also confirms that this chip has a serial console that can be used for debugging. If this is still enabled this could allow us to access the box while it’s running and potentially obtain a shell on the system.
The second chip is the Macronix MX25L12835F SPI (serial flash chip) this is what attacked for most of the reversing process to obtain the application’s firmware. This is because the serial flash usually contains the configuration settings, file systems, and is generally the storage for devices lacking peripherals would be stored. And looking around on the board there is no other «storage device».
The third, and last chip is the Etron Technology EM68C16CWQG-25H which is the ram used by the device when it is running.
Connecting to UART
Let’s quickly go over what’s UART. UART is used to send and receive data from devices over a serial connection. This is done for purposes such as updating firmware manually, debugging, or interfacing with the underlying system (kind of like opening a new terminal in Ubuntu). UART works by communicating through two wires, a transmitter wire (TX) and a receiver wire (RX) to talk to the micro-controller or system on a chip (basically the brains of the device) directly.
The receiver and transmitter marked RX and TX respectively, need to connect to a second respective UART device’s TX and RX in order to establish a communication. I’m lucky enough to have received my Flipper Zero so I’ll be using it for this!
If you would like more in-depth information on UART see my blog on hacking a fertility sperm tester. We’ll connect our Flipper Zero to the router UART connection as seen below.
The result will be a little something like this.
Since I’m a Mac user connecting to my Flipper Zero via USB will «mount» or make the device accessible at
/dev/cu.usbmodemflip*
so if I want to connect to it all I need to do is run the command below.
Once I’ve ran the screen command, and the router is powered on, ill start seeing serial output confirming that I’ve properly connected to UART.
As you can see, I’ve obtained a root shell. Unprotected root access via the UART is technically a vulnerability CWE-306. Connecting to the UART port drops you directly to a root shell, and exposes an unauthenticated Das U-Boot BIOS shell. This isn’t something you see too often, UART is commonly tied down. However, «exploitation» requires physical access, the device needs to be opened, and wires connecting to pads RX, TX, and GND on the main logic board. GL.iNET knows about this, and to my knowledge doesn’t plan on patching it. This is understandable as there’s no «real» impact.
I’ll go on a «quick» rant about why unprotected UART CVEs are silly. The attack requires physical access to the device. So, an attacker has to be on-site, most likely inside a locked room where networking equipment is located, and is probably monitored by CCTV… The attacker must also attach an additional USB-to-UART component to the device’s PCB in order to gain console access. Since physically dismantling the device is required to fulfill the attack, I genuinely don’t consider this oversight from the manufacturer a serious vulnerability. Obviously, it’s not great, but realistically these types of things are at the vendor’s discretion. Moreover, even when protections are in place to disable the UART console and/or have the wide debug pads removed from the PCB there are many tricks one can use to navigate around those mechanisms.
Although personally, I believe it’s simply best practice for a hardware manufacturer to disable hardware debugging interfaces in the final product of any commercial device. Not doing so isn’t worthy of a CVE.
Getting back on track. Hypothetically if we were in a situation where we couldn’t get access to a shell from UART we’d likely be able to get one from U-Boot. There are actually a lot of different ways to get an application shell from here. Two of those techniques were covered in my blog Thanks Fo’ Nut’in — Hacking YO’s Male Fertility Sperm Test so I won’t be covering them here.
Leveraging the SPI Flash
Even though the serial console is enabled, if it weren’t, and we had no success getting a shell from U-Boot, our next avenue of attack might be to extract the firmware from the SPI flash chip.
The goal is simple, read the firmware from the chip. There are a few options like using clips universal bus interface device, unsoldering the chip from the board and connecting it to a specialized EPROM read/write device or attaching it to a Protoboard. I like the first option and using SOIC8 clips over hook clips.
At a minimum, we’ll need a hardware tool that can interact with at least an SPI interface. I’m a big fan of the Attify Badge as it’s very efficient and supports many interfaces like SPI, UART, JTAG, I2C, GPIO, and others. But you could other devices like a professional EPROM programmer, a Bus Pirate, beaglebone, Raspberry Pi, etc,.
Below is the pinout found on the datasheet for our Macronix MX25L12835F flash.
All you need to do is make the proper connections from the chip to the Attify badge. I’ve made mine according to the diagram below.
OK. I spent a solid two nights trying to dump the firmware without success. I’ve tried the Bus Pirate, Shikra, Attify, and a beaglebone black but nothing seems to work. Flashrom appears to be unable to read the data or even identify the chip, which is really weird. I’ve confirmed the pinouts are correct from the datasheet, and as seen below, flashrom supports this chip.
Attempting to dump the firmware results in the following.
So what’s going on? I’m not an EE so I had to do a lot of reading & talking to extremely patient people. Ultimately, I suspect this is happening because there is already a contention for the SPI bus (the MediaTek MT7628NN chip), and due to the nature of what we’re attempting to do, the router is receiving two masters connections and ours is not taking precedence. Currently, the MCU on the board is the master of the SPI chip, that’s the one where all the communication is going to and from. I wasn’t able to find a way to intercept, short, or stop that communication to make our Attify badge the master. In theory, a trick to get around this would be by holding down a reset button while reading the flash and just hoping to get lucky (I did this for ~2h and had no luck). Since our Attify badge would already be powered on, it could «IN THEORY» take precedence. This could, again «in theory» stop the chip from mastering to the MCU. But I haven’t been able to do so properly. I’ve spent ~8 hours on this, tying out multiple different hardware (PI, beaglebone, Attify, BusPirate) without success. I also suspect that being on a MacBook Pro with funky USB adapters could be making my situation worse.
Okay, we’re left with no other option than to go «off-chip». As previously mentioned, there are multiple ways to dump the contents of flash memory. Let’s try desoldering the component from the board, and use a chip reprogrammer to read off the contents.
My setup is extremely cheap setup is very sub-optimal. I don’t own a fixed «hot air station» or PDC mount. I’m just using a loose heat gun.
Our goal is to apply enough heat so that the solder joints melt. We need to extracted the chip with tweezers without damaging components. Easier said then done with my shitty station. differential heating on the board can be an issue. When a jet of hot air is applied to a PCB at room temperature, most of the heat is diffused to the colder spots, making the heating of the region of interest poor. To work around this you might think that increasing the heat will solve all of our issues. However, simply increasing the temperature is dangerous and not advisable.
When a component is put under increased thermal stress the temperature gradient increases along the board. The temperature difference on the board will produce thermal expansion in different areas, producing mechanical stress that may damage the board, break, and shift components. Not good. My setup is prone to this type of error because I don’t have a mounting jig for the heat gun that can control distance. I don’t have any high-temperature tape I can apply to the surrounding components so that they don’t get affected by my shaky hand controlling the heat source.
Regardless, for most small components, a preheating temperature of 250º C should be enough.
After a few minutes, I was able to get the chip off. However, there is a tiny shielded inductor or resistor that was affected by the heat which shifted when I removed the SPI with the tweezers. I wasn’t able to get this component back on the board. Fuck. I’m not an EE so I don’t fully understand the impact and consequences this has.
Let’s mount the SPI onto a SOP8 socket which we’ll then connect to our reprogrammer. Below is the orientation of the memory in the adapter.
This is, once again, quite a shitty reprogrammer. I actually had to disable driver signing to get the USB connection recognized after manually installing the shady driver. We’ll go ahead and configure our chip options knowing our SPI is Macronix MX25L12835F.
However, this also failed/couldn’t do any reads. I spend another ~5 hours debugging this. I thought it was the SOP socket clip so I soldered it onto a board and relayed the links to the reprogrammer but the results were the same.
After a while, I went ahead and re-soldered it to the main router PCB, and the device was fully bricked. To be quite honest, I’m not sure what I did wrong/at which step I made the mistake.
They say that failure is another stepping stone to greatness, but given that the entire reason for this purchase was to try out some new hardware hacking methodologies…. this was very bittersweet.
I remembered the squashfs information displayed in the UART log information. So, if we really wanted to reverse the firmware it’s still impossible. You can grab the unsigned firmware from the vendor’s site vendors here. Below are the steps you’d follow if you had successfully extracted the firmware to get to the filesystem.
So let’s check if they have any hardcoded credentials.
Luckily, they don’t.
The last thing I observed was that in the UBI reader there is an extra data block at the end of the image and somewhere in between that in theory could allow us to read code.
This purchase was supposed to be hardware hacking focused & I failed my personal objectives. To compensate I’ll share some closing thoughts with you.
In case you were wondering «how can the vendor prevent basic IoT hardware vulnerabilities? And is it worth it?». The answer is yes, and yes. This blog is long enough so I’ll keep it short.
Think of it this way. Having an extra layer of protection or some baseline obfuscation in the event that developers make mistakes is a good idea and something that should be planned for. The way I see it, if the JTAG, UART, or ICSP connector weren’t immediately apparent, this would’ve slowed me down and perhaps eventually demotivate me to push on.
The beautiful part is that hardware obfuscation is easy to introduce at the earliest stages of product development. Unlike software controls, which are implemented at later stages of the project and left out due to lack of time. There exist many different hardware controls which are all relatively easy to implement.
Since the hardware hacking portion of this blog wasn’t a great success I might as well share some thoughts & ideas on remediation & how to make IoT hardware more secure.
1. Removing the PCB silkscreen. Marks, logos, symbols, etc, have to go. There’s no real reason to draw up the entire board, especially if it’s in production.
2. Hide the traces! It’s too simple to follow the solder mask (the light green parts on this PCB) What’s the point of making them so obvious?
3. Hardware-level tamper protection. It’s possible to set hardware and even software fuses to prevent readout (bear in mind that both can be bypassed in many cases).
4. Remove test pins and probe pads and other debugging connections. Realistically speaking if the product malfunctions and a firmware update won’t fix it, the manufacturer likely won’t send someone onsite to debug /fix it. 99% of the time they’re simply going to send you a new one. So why have debug interfaces enabled/on production devices?
5. If you’re using vias as test points (because they make using a multimeter or a scope probe much easier, and are typically used by embedded passive components) it would be wise to use buried or blind vias. The cost of adding additional PCB layers is cheap if you don’t already have enough to do this.
6. Remove all chipset markings! It’s seriously so much harder & time-consuming to identify a chip with no markings.
7. Why not use tamper-proof cases, sensors (photodiode detectors), or one-way screws. Again some of these are not difficult to drill bypass. However, you’re testing the motivation of the attacker. Only really motivated reverse engineers would bother opening devices in the dark.
If you’re interested, here are some solid publications regarding hardware obfuscation I’d recommend the following papers:
I hope you liked the blog post. Follow me on twitter I sometimes post interesting stuff there too. This was a lot of fun! Personally, I’d strongly recommend going on Amazon, Alibaba, or Aliexpress and buying a bunch of odd or common IoT devices and tearing them down. You never know what you will find 🙂
Windows ZIP extraction bug (CVE-2022-41049) lets attackers craft ZIP files, which evade warnings on attempts to execute packaged files, even if ZIP file was downloaded from the Internet.
In October 2022, I’ve come across a tweet from 5th July, from @wdormann, who reported a discovery of a new method for bypassing MOTW, using a flaw in how Windows handles file extraction from ZIP files.
Will Dormann @wdormann The ISO in question here takes advantage of several default behaviors: 1) MotW doesn’t get applied to ISO contents 2) Hidden files aren’t displayed 3) .LNK file extensions are always hidden, regardless of the Explorer preference to hide known file extensions.
So if it were a ZIP instead of ISO, would MotW be fine? Not really. Even though Windows tries to apply MotW to extracted ZIP contents, it’s really quite bad at it. Without trying too hard, here I’ve got a ZIP file where the contents retain NO protection from Mark of the Web.
This sounded to me like a nice challenge to freshen up my rusty RE skills. The bug was also a 0-day, at the time. It has already been reported to Microsoft, without a fix deployed for more than 90 days.
What I always find the most interesting about vulnerability research write-ups is the process on how one found the bug, what tools were used and what approach was taken. I wanted this post to be like this.
Now that the vulnerability has been fixed, I can freely publish the details.
Background
What I found out, based on public information about the bug and demo videos, was that Windows, somehow, does not append MOTW to files extracted from ZIP files.
Mark-of-the-web is really another file attached as an Alternate Data Stream (ADS), named
Zone.Identifier
, and it is only available on NTFS filesystems. The ADS file always contains the same content:
[ZoneTransfer]
ZoneId=3
For example, when you download a ZIP file
file.zip
, from the Internet, the browser will automatically add
file.zip:Zone.Identifier
ADS to it, with the above contents, to indicate that the file has been downloaded from the Internet and that Windows needs to warn the user of any risks involving this file’s execution.
This is what happens when you try to execute an executable like a JScript file, through double-clicking, stored in a ZIP file, with MOTW attached.
Clearly the user would think twice before opening it when such popup shows up. This is not the case, though, for specially crafted ZIP files bypassing that feature.
Let’s find the cause of the bug.
Identifying the culprit
What I knew already from my observation is that the bug was triggered when
explorer.exe
process handles the extraction of ZIP files. I figured the process must be using some internal Windows library for handling ZIP files unpacking and I was not mistaken.
ProcessHacker revealed
zipfldr.dll
module loaded within Explorer process and it looked like a good starting point. I booted up IDA with conveniently provided symbols from Microsoft, to look around.
ExtractFromZipToFile
function immediately caught my attention. I created a sample ZIP file with a packaged JScript file, for testing, which had a single instruction:
WScript.Echo("YOU GOT HACKED!!1");
I then added a MOTW ADS file with Notepad and filled it with MOTW contents, mentioned above:
notepad file.zip:Zone.Identifier
I loaded up
x64dbg
debugger, attached it to
explorer.exe
and set up a breakpoint on
ExtractFromZipToFile
. When I double-clicked the JS file, the breakpoint triggered and I could confirm I’m on the right path.
CheckUnZippedFile
One of the function calls I noticed nearby, revealed an interesting pattern in IDA. Right after the file is extracted and specific conditions are meet,
CheckUnZippedFile
function is called, followed by a call to
_OpenExplorerTempFile
, which opens the extracted file.
Having a hunch that
CheckUnZippedFile
is the function responsible for adding MOTW to extracted file, I nopped its call and found that I stopped getting the MOTW warning popup, when I tried executing a JScript file from within the ZIP.
It was clear to me that if I managed to manipulate the execution flow in such a way that the branch, executing this function is skipped, I will be able to achieve the desired effect of bypassing the creation of MOTW on extracted files. I looked into the function to investigate further.
I noticed that
CheckUnZippedFile
tries to combine the TEMP folder path with the zipped file filename, extracted from the ZIP file, and when this function fails, the function quits, skipping the creation of MOTW file.
Considering that I controlled the filename of the extracted ZIP file, I could possibly manipulate its content to trigger
PathCombineW
to fail and as a result achieve my goal.
PathCombineW
turned out to be a wrapper around
PathCchCombineExW
function with output buffer size limit set to fixed value of
260
bytes. I thought that if I managed to create a really long filename or use some special characters, which would be ignored by the function handling the file extraction, but would trigger the length check in
CheckUnZippedFile
to fail, it could work.
I opened 010 Editor, which I highly recommend for any kind of hex editing work, and opened my sample ZIP file with a built-in ZIP template.
I spent few hours testing with different filename lengths, with different special characters, just to see if the extraction function would behave in erratic way. Unfortunately I found out that there was another path length check, called prior to the one I’ve been investigating. It triggered much earlier and prevented me from exploiting this one specific check. I had to start over and consider this path a dead end.
I looked if there are any controllable branching conditions, that would result in not triggering the call to
CheckUnZippedFile
at all, but none of them seemed to be dependent on any of the internal ZIP file parameters. I considered looking deeper into
CheckUnZippedFile
function and found out that when
PathCombineW
call succeeds, it creates a
CAttachmentServices
COM objects, which has its three methods called:
CAttachmentServices::SetReferrer(unsigned short const * __ptr64)
CAttachmentServices::SetSource(unsigned short const * __ptr64)
CAttachmentServices::SaveWithUI(struct HWND__ * __ptr64)
realized I am about to go deep down a rabbit hole and I may spend there much longer than a hobby project like that should require. I had to get a public exploit sample to speed things up.
I managed to copy over all relevant ZIP file parameters from the obtained exploit sample into my test sample and I confirmed that MOTW was gone, when I extracted the sample JScript file.
I decided to dig deeper into
SaveWithUI
COM method to find the exact place where creation of
error, when using the exploit sample and succeeded when using the original, untampered test sample.
It looked like the majority of parameters were constant, as you can see on the screenshot above. The only place where I’d expect anything dynamic was in the structure of
ObjectAttributes
parameter. After closer inspection and half an hour of closely comparing the contents of the parameter structures from two calls, I concluded that both failing and succeeding calls use exactly the same parameters.
This led me to realize that something had to be happening prior to the creation of the ADS file, which I did not account for. There was no better way to figure that out than to use Process Monitor, which honestly I should’ve used long before I even opened IDA 😛.
Backtracking
I set up my filters to only list file operations related to files extracted to TEMP directory, starting with
Temp
prefix.
The test sample clearly succeeded in creating the
Zone.Identifier
ADS file:
While the exploit sample failed:
Through comparison of these two listings, I could not clearly see any drastic differences. I exported the results as text files and compared them in a text editor. That’s when I could finally spot it.
Prior to creating
Zone.Identifier
ADS file, the call to
SetBasicInformationFile
was made with
FileAttributes
set to
RN
.
I looked up what was that
R
attribute, which apparently is not set for the file when extracting from the original test sample and then…
Facepalm
The
R
file attribute stands for
read-only
. The file stored in a ZIP file has the read-only attribute set, which is set also on the file extracted from the ZIP. Obviously when Windows tries to attach the
Zone.Identifier
ADS, to it, it fails, because the file has a read-only attribute and any write operation on it will fail with
ACCESS_DENIED
error.
It doesn’t even seem to be a bug, since everything is working as expected 😛. The file attributes in a ZIP file are set in
ExternalAttributes
parameter of the
ZIPDIRENTRY
structure and its value corresponds to the ones, which carried over from MS-DOS times, as stated in ZIP file format documentation I found online.
4.4.15 external file attributes: (4 bytes)
The mapping of the external attributes is
host-system dependent (see 'version made by'). For
MS-DOS, the low order byte is the MS-DOS directory
attribute byte. If input came from standard input, this
field is set to zero.
4.4.2 version made by (2 bytes)
4.4.2.1 The upper byte indicates the compatibility of the file
attribute information. If the external file attributes
are compatible with MS-DOS and can be read by PKZIP for
DOS version 2.04g then this value will be zero. If these
attributes are not compatible, then this value will
identify the host system on which the attributes are
compatible. Software can use this information to determine
the line record format for text files etc.
4.4.2.2 The current mappings are:
0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
1 - Amiga 2 - OpenVMS
3 - UNIX 4 - VM/CMS
5 - Atari ST 6 - OS/2 H.P.F.S.
7 - Macintosh 8 - Z-System
9 - CP/M 10 - Windows NTFS
11 - MVS (OS/390 - Z/OS) 12 - VSE
13 - Acorn Risc 14 - VFAT
15 - alternate MVS 16 - BeOS
17 - Tandem 18 - OS/400
19 - OS X (Darwin) 20 thru 255 - unused
4.4.2.3 The lower byte indicates the ZIP specification version
(the version of this document) supported by the software
used to encode the file. The value/10 indicates the major
version number, and the value mod 10 is the minor version
number.
Changing the value of external attributes to anything with the lowest bit set e.g.
0x21
or
0x01
, would effectively make the file read-only with Windows being unable to create MOTW for it, after extraction.
Conclusion
I honestly expected the bug to be much more complicated and I definitely shot myself in the foot, getting too excited to start up IDA, instead of running Process Monitor first. I started with IDA first as I didn’t have an exploit sample in the beginning and I was hoping to find the bug, through code analysis. Bottom line, I managed to learn something new about Windows internals and how extraction of ZIP files is handled.
As a bonus, Mitja Kolsek from 0patch asked me to confirm if their patch worked and I was happy to confirm that it did!
The patch was clean and reliable as seen in the screenshot from a debugger:
I’ve been also able to have a nice chat with Will Dormann, who initially discovered this bug, and his story on how he found it is hilarious:
I merely wanted to demonstrate how an exploit in a ZIP was safer (by way of prompting the user) than that *same* exploit in an ISO. So how did I make the ZIP? I:
1) Dragged the files out of the mounted ISO
2) Zipped them. That's it. The ZIP contents behaved the same as the ISO.
Every mounted ISO image is listing all files in read-only mode. Drag & dropping files from read-only partition, to a different one, preserves the read-only attribute set for created files. This is how Will managed to unknowingly trigger the bug.
Will also made me realize that 7zip extractor, even though having announced they began to add MOTW to every file extracted from MOTW marked archive, does not add MOTW by default and this feature has to be enabled manually.
I mentioned it as it may explain why MOTW is not always considered a valid security boundary. Vulnerabilities related to it may be given low priority and be even ignored by Microsoft for 90 days.
I haven’t yet analyzed how the patch made by Microsoft works, but do let me know if you did and I will gladly update this post with additional information.
When it comes to vulnerabilities in WebViews, we often overlook the incorrect implementation of
WebResourceResponse
which is a WebView class that allows an Android app to emulate the server by returning a response (including a status code, content type, content encoding, headers and the response body) from the app’s code itself without making any actual requests to the server. At the end of the article, we’ll show how we exploited a vulnerability related to this in Amazon apps.
Do you want to check your mobile apps for such types of vulnerabilities? Oversecured mobile apps scanner provides an automatic solution that helps to detect vulnerabilities in Android and iOS mobile apps. You can integrate Oversecured into your development process and check every new line of your code to ensure your users are always protected.
Start securing your apps by starting a free 2-week trial from Quick Start, or you can book a call with our team or contact us to explore more.
What is
WebResourceResponse
?
The WebView class in Android is used for displaying web content within an app, and provides extensive capabilities for manipulating requests and responses. It is a fancy web browser that allows developers, among other things, to bypass standard browser security. Any misuse of these features by a malicious actor can lead to vulnerabilities in mobile apps.
One of these features is that a WebView allows you to intercept app requests and return arbitrary content, which is implemented via the
WebResourceResponse
class.
Let’s look at a typical example of a
WebResourceResponse
implementation:
WebView webView = findViewById(R.id.webView);
webView.setWebViewClient(new WebViewClient() {
public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
Uri uri = request.getUrl();
if (uri.getPath().startsWith("/local_cache/")) {
File cacheFile = new File(getCacheDir(), uri.getLastPathSegment());
if (cacheFile.exists()) {
InputStream inputStream;
try {
inputStream = new FileInputStream(cacheFile);
} catch (IOException e) {
return null;
}
Map<String, String> headers = new HashMap<>();
headers.put("Access-Control-Allow-Origin", "*");
return new WebResourceResponse("text/html", "utf-8", 200, "OK", headers, inputStream);
}
}
return super.shouldInterceptRequest(view, request);
}
});
As you can see in the code above, if the request URI matches a given pattern, then the response is returned from the app resources or local files. The problem arises when an attacker can manipulate the path of the returned file and, through XHR requests, gain access to arbitrary files.
Therefore, if an attacker discovers a simple XSS or the ability to open arbitrary links inside the Android app, they can use that to leak sensitive user data – which can also include the access token, leading to a full account takeover.
Proof of Concept for an attack
If you already have the ability to execute arbitrary JavaScript code inside a vulnerable WebView, and assuming there is some sensitive data in
/data/data/com.victim/shared_prefs/auth.xml
, then the Proof of Concept for the attack will look like this:
However, policies like CORS still work inside a WebView. Therefore, if
Access-Control-Allow-Origin: *
is not specified in the headers, then requests to the current domain will not be allowed. In our example, this restriction will not affect the exploitation of path traversal, because
any.domain
can be replaced with the current scheme + host + port.
An overview of the vulnerability in Amazon’s apps
We scanned the Amazon Shopping and Amazon India Online Shopping apps and found two vulnerabilities. They were chained to access arbitrary files owned by Amazon apps and then reported to the Amazon VRP on December 21st, 2019. The issues were confirmed fixed by Amazon on April 6th, 2020.
The first was opening arbitrary URLs within the WebView through the
, which is a user-friendly interface. It allows the app to safely process data from resources, assets or a predefined directory.
It could be challenging to keep track of security, especially in large projects. You can use Oversecured vulnerability scanner since it tracks all known security issues on Android and iOS including all the vectors mentioned above. To begin testing your apps, use Quick Start, book a call or contact us.
![[Case study] Decrypt strings using Dumpulator](https://i0.wp.com/movaxbx.ru/wp-content/uploads/2023/05/Screenshot-2023-05-29-at-03.40.01.png?resize=2000%2C922&ssl=1)
