At Wordfence our business is to secure over 4 million WordPress websites and keep them secure. My background is in network operations, and then I transitioned into software development because my ops role was at a scale where I found myself writing a lot of code. This led me to founding startups, and ultimately into starting the cybersecurity business that is Wordfence. But I’ve maintained that ops perspective, and when I think about securing a network, I tend to think of ports.
You can find a rather exhaustive list of TCP and UDP ports on Wikipedia, but for the sake of this discussion let’s focus on a few of the most popular ports:
20 and 21 – FTP
22 – SSH
23 – (Just kidding. You better not be running Telnet)
25 – Email via SMTP
53 – DNS
80 – Unencrypted Web
110 – POP3 (for older email clients)
443 – Web encrypted via TLS
445 – Active Directory or SMB sharing
993 – IMAP (for email clients)
3306 – MySQL
6378 – Redis
11211 – Memcached
If you run your eye down this list, you’ll notice something interesting. The options available to you for services to run on most of these ports are quite limited. Some of them are specific to a single application, like Redis. Others, like SMTP, provide a limited number of applications, either proprietary or open-source. In both cases, you can change the configuration of the application, but it’s rare to write a custom application on one of those ports. Except port 443.
In the case of port 443 and port 80, you have a limited range of web servers listening on those ports, but users are writing a huge range of bespoke applications on port 443, and have a massive selection of applications that they can host on that port. Everything from WordPress to Drupal to Joomla, and more. There are huge lists of Content Management Systems.
Not only do you have a wide range of off-the-shelf web applications that you can run on port 443 or (if you’re silly) port 80, but you also have a range of languages they might be coded in, or in which you can code your own web application. Keep in mind that the web server, in this case, is much like an SSH or IMAP server in that it is listening on the port and handling connections, but the difference is that it is handing off execution to these languages, their various development frameworks, and ultimately the application that a developer has written to handle the incoming request.
With SSH, SMTP, FTP, IMAP, MySQL, Redis and most other services, the process listening on the port is the process that handles the request. With web ports, the process listening on the port delegates the incoming connection to another application, usually written in another language, running at the application layer, that is part of the extremely large and diverse ecosystem of web applications.
This concept in itself – that the applications listening on the web ports are extremely diverse and either home-made or selected from a large and diverse ecosystem – presents unique security challenges. In the case of, say, Redis, you might worry about running a secure version of Redis and making sure it is not misconfigured. In the case of a web server, you may have 50 application instances written in two languages from five different vendors all on the same port, which all need to be correctly configured, have their patch levels maintained, and be written using secure coding practices.
As if that doesn’t make the web ports challenging enough, they are also, for the most part, public. Putting aside internal websites for the moment, perhaps the majority of websites derive their value from making services available to users on the Internet by being public-facing. If you consider the list of ports I have above, or in the Wikipedia article I linked to, many of those ports are only open on internal networks or have access to them controlled if they are external. Web ports for public websites, by their very nature, must be publicly accessible for them to be useful. There are certain public services like SMTP or DNS, but as I mentioned above, the server that is listening on the port is the server handling the request in these cases.
A further challenge when securing websites is that often the monetary and data assets available to an attacker when compromising a website are greater than the assets they may gain compromising a corporate network. You see this with high volume e-commerce websites where a small business is processing a large number of web-based e-commerce transactions below $100. If the attacker compromises their corporate network via leaked AWS credentials, they may gain access to the company bank account and company intellectual property, encrypt the company’s data using ransomware, or perhaps even obtain customer PII. But by compromising the e-commerce website, they can gain access to credit card numbers in-flight, which are far more tradeable, and where the sum of available credit among all cards is greater than all the assets of the small business, including the amount of ransom that business might be able to pay.
Let’s not discount breaches like the 2017 Equifax breach that compromised 163 million American, British and Canadian citizen’s records. That was extremely valuable to the attackers. But targets like this are rare, and the Web presents a target-rich environment. Which is the third point I’d like to make in this post. While an organization may run a handful of services on other ports, many companies – with hosting providers in particular – run a large number of web applications. And an individual or company is far more likely to have a service running on a web port than any other port. Many of us have websites, but how many of us run our own DNS, SMTP, Redis, or another service listening on a port other than 80 or 443? Most of us who run websites also run MySQL on port 3306, but that port should not be publicly accessible if configured correctly.
That port 443 security is different has become clear to us at Wordfence over the years as we have tracked and cataloged a huge number of malware variants, web vulnerabilities, and a wide range of tactics, techniques, and procedures (TTP) that attackers targeting web applications use. Most of these have no relationship with the web server listening on port 443, and nearly all of them have a close relationship with the web application that the web server hands off control to once communication is established.
My hope with this post has been to catalyze a different way of thinking about port 443 and that other insecure port (80) we all hopefully don’t use. Port 443 is not just another service. It is, in fact, the gateway to a whole new universe of programming languages, dev frameworks, and web applications.
In the majority of cases, the gateway to that new universe is publicly accessible.
Once an attacker passes through that gateway, a useful way to think about the web applications hosted on the server is that each application is its own service that needs to have its patch level maintained, needs to be configured correctly, and should be removed if it is not in use to reduce the available attack surface.
If you are a web developer you may already think this way, and if anything, you may be guilty of neglecting services on ports other than port 80 or 443. If you are an operations engineer, or an analyst working in a SOC protecting an enterprise network, you may be guilty of thinking about port 443 as just another port you need to secure.
Think of port 443 as a gateway to a new universe that has no access control, with HTTPS providing easy standardized access, and with a wide range of diverse services running on the other side, that provide an attacker with a target and asset-rich environment.
—
Footnote: We will be exhibiting at Black Hat in Las Vegas this year at booth 2514 between the main entrance and Innovation City. Our entire team of over 30 people will be there. We’ll have awesome swag, as always. Come and say hi! Our team will also be attending DEF CON immediately after Black Hat.
Written by Mark Maunder – Founder and CEO of Wordfence.
In August 2021, ZDI announced Pwn2Own Austin 2021, a security contest focusing on phones, printers, NAS devices and smart speakers, among other things. The Pwn2Own contest encourages security researchers to demonstrate remote zero-day exploits against a list of specified devices. If successful, the researchers are rewarded with a cash prize, and the leveraged vulnerabilities are responsibly disclosed to the respective vendors so they can improve the security of their products.
After reviewing the list of devices, we decided to target the Cisco RV340 router and the Lexmark MC3224i printer, and we managed to identify several vulnerabilities in both of them. Fortunately, we were luckier than last year and were able to participate in the contest for the first time. By successfully exploiting both devices, we won $20,000 USD, which CrowdStrike donated to several charitable organizations chosen by our researchers.
In this blog post, we outline the vulnerabilities we discovered and used to compromise the Lexmark printer.
Overview
Product
Lexmark MC3224
Affected Firmware Versions (without claim for completeness)
Step #1: Increasing Attack Surface via Authentication Reset
Before we could start our analysis, we first had to obtain a copy of the firmware. It quickly turned out that the firmware is shipped as an .fls file in a custom binary format containing encrypted data. Luckily, a detailed writeup on the encryption scheme had been published in September 2020. While the writeup did not include code or cryptographic keys, it was elaborate enough that we were able to quickly reproduce it and write our own decrypter. With our firmware decryption tool at hand, we were finally able to peek into the firmware.
It was assumed that the printer would be in a default configuration during the contest and that the setup wizard on the printer had been completed. Thus, we expected the administrator password to be set to an unknown value. In this state, unauthenticated users can still trigger a vast amount of actions through the web interface. One of these is Sanitize all information on nonvolatile memory. It can be found under Settings -> Device -> Maintenance. There are several options to choose from when performing that action:
[x] Sanitize all information on nonvolatile memory
(x) Start initial setup wizard
( ) Leave printer offline
[x] Erase all printer and network settings
[x] Erase all shortcuts and shortcut settings
[Start] [Reset]
If the checkboxes are ticked as shown, the process can be initiated through the Start button. The printer’s non-volatile memory will be cleared and a reboot is initiated. This process takes approximately two minutes. Afterward, unauthenticated users can access all functions through the web interface.
Step #2: Shell Command Injection
After resetting the nvram as outlined in the previous section, the CGI script https://target/cgi-bin/sniffcapture_post becomes accessible without authentication. It was previously discovered by browsing the decrypted firmware and is located in the directory /usr/share/web/cgi-bin.
At the beginning of the script, the supplied POST body is stored in the variable data. Afterward, several other variables such as interface, dest, path and filter are extracted and populated from that data by using sed:
read data
remove=${data/*-r*/1}
if [ "x${remove}" != "x1" ]; then
remove=0
fi
interface=$(echo ${data} | sed -n 's|^.*-i[[:space:]]\([^[:space:]]\+\).*$|\1|p')
dest=$(echo ${data} | sed -n 's|^.*-f[[:space:]]\([^[:space:]]\+\).*$|\1|p')
path=$(echo ${data} | sed -n 's|^.*-f[[:space:]]\([^[:space:]]\+\).*$|\1|p')
method="startSniffer"
auto=0
if [ "x${dest}" = "x/dev/null" ]; then
method="stopSniffer"
elif [ "x${dest}" = "x/usr/bin" ]; then
auto=1
fi
filter=$(echo ${data} | sed -n 's|^.*-F[[:space:]]\+\(["]\)\(.*\)\1.*$|\2|p')
args="-i ${interface} -f ${dest}/sniff_control.pcap"
The variable filter is determined by a quoted string following the value -F specified in the POST body. As shown below, it is later embedded into the args variable in case it has been specified along with an interface:
fmt=""
args=""
if [ ${remove} -ne 0 ]; then
fmt="${fmt}b"
args="${args} remove 1"
fi
if [ -n "${interface}" ]; then
fmt="${fmt}s"
args="${args} interface ${interface}"
if [ -n "${filter}" ]; then
fmt="${fmt}s"
args="${args} filter \"${filter}\""
fi
if [ ${auto} -ne 0 ]; then
fmt="${fmt}b"
args="${args} auto 1"
else
fmt="${fmt}s"
args="${args} dest ${dest}"
fi
fi
[...]
At the end of the script, the resulting args value is used in an eval statement:
[...]
resp=""
if [ -n "${fmt}" ]; then
resp=$(eval rob call system.sniffer ${method} "{${fmt}}" ${args:1} 2>/dev/null)
submitted=1
[...]
By controlling the filter variable, attackers are therefore able to inject further shell commands and gain access to the printer as uid=985(httpd), which is the user that the web server is executed as.
Step #3: Privilege Escalation
The printer ships a custom root-owned SUID binary called collect-selogs-wrapper:
# ls -la usr/bin/collect-selogs-wrapper
-rwsr-xr-x. 1 root root 7324 Jun 14 15:46 usr/bin/collect-selogs-wrapper
In its main() function, the effective user ID (0) is retrieved and the process’s real user ID is set to that value. Afterward, the shell script /usr/bin/collect-selogs.sh is executed:
Effectively, the shell script is executed as root with UID=EUID, and therefore the shell does not drop privileges. Furthermore, argv[] of the SUID binary is passed to the shell script. As the environment variables are also retained across the execv() call, an attacker is able to specify a malicious $PATH value. Any command inside the shell script that is not referenced by its absolute path can thereby be detoured by the attacker.
The first opportunity for such an attack is the invocation of systemd-cat inside sd_journal_print():
# cat usr/bin/collect-selogs.sh
#!/bin/sh
# Collects fwdebug from the current state plus the last 3 fwdebug files from
# previous auto-collections. The collected files will be archived and compressed
# to the requested output directory or to the standard output if the output
# directory is not specified.
sd_journal_print() {
systemd-cat -t collect-selogs echo "$@"
}
sd_journal_print "Start! params: '$@'"
[...]
The /dev/shm directory can be used to prepare a malicious version of systemd-cat:
This script remounts /dev/shm with the suid flag so that SUID binaries can be executed from it. It then copies the system’s Python interpreter to the same directory and enables the SUID bit on it. The malicious systemd-cat copy can be executed as root by invoking the setuid collect-setlogs-wrapper binary like this:
The $PATH environment variable is prepended with the /dev/shm directory that hosts the malicious systemd-cat copy. After executing the command, a root-owned SUID-enabled copy of the Python interpreter is located in /dev/shm:
root@ET788C773C9E20:~# ls -la /dev/shm
drwxrwxrwt 2 root root 100 Oct 29 09:33 .
drwxr-xr-x 13 root root 5160 Oct 29 09:31 ..
-rwsr-sr-x 1 root httpd 8256 Oct 29 09:33 python3
-rw------- 1 nobody nogroup 16 Oct 29 09:31 sem.netapps.rawprint
-rwxr-xr-x 1 httpd httpd 96 Oct 29 09:33 systemd-cat
The idea behind this technique is to establish a simple way of escalating privileges without having to exploit the initial collect_selogs_wrapper SUID again. We did not use the Bash binary for this, as the version shipped with the printer seems to ignore the -p flag when running with UID!=EUID.
Exploit
An exploit combining the three vulnerabilities to gain unauthenticated code execution as root has been implemented as a Python script. First, the exploit tries to determine whether the printer has a login password set (i.e., setup wizard has been completed) or it is password-less (i.e., authentication reset already executed earlier or setup wizard not yet completed). Depending on the result, it decides whether the non-volatile memory reset is required.
If the non-volatile memory reset is triggered, the exploit waits for the printer to finish rebooting. Afterward, it continues with the shell command injection step and escalation of privileges. The privileged access is then used to start an OpenSSH daemon on the printer. To finish, the exploit establishes an interactive SSH session with the printer and hands control over to the user. An example run of the exploit in a testing environment follows:
In this blog, we described a number of vulnerabilities that can be exploited from the local network to bypass authentication, execute arbitrary shell commands, and elevate privileges on a Lexmark MC3224i printer. The research started as an experiment after the announcement of the Pwn2Own Austin 2021. The team enjoyed the challenge, as well as participating in Pwn2Own for the first time, and we welcome your feedback. We’d also like to invite you to read about the other device we successfully targeted during Pwn2Own Austin 2021, the Cisco RV340 router.
In this report, we highlight the notable email threats of 2021, including over 33.6 million high-risk email threats (representing a 101% increase from 2020’s numbers) that we’ve detected using the Trend Micro Cloud App Security platform.
Email is an integral cog in the digital transformation machine. This was especially true in 2021, when organizations found themselves trying to keep business operations afloat in the middle of a pandemic that has forever changed how people work. At a time when the workplace had already largely shifted from offices to homes, malicious actors continued to favor email as a low-effort yet high-impact attack vector to disseminate malware.
Email is not only popular among cybercriminals for its simplicity but also for its efficacy. In fact, 74.1% of the total threats blocked by Trend Micro in 2021 are email threats. Meanwhile, the 2021 Internet Crime Report by the FBI’s Internet Crime Complaint Center (IC3) states that there was “an unprecedented increase in cyberattacks and malicious cyber activity” last year, with business email compromise (BEC) being among the top incidents.
In this report, we discuss the notable email threats of 2021 based on the data that we’ve gathered using the Trend Micro™ Cloud App Security™, a security solution that supplements the preexisting security features in email and collaboration platforms.
Malware detections surge as attacks become more elaborate, targeted
The Trend Micro Cloud App Security solution detected and thwarted a total of 3,315,539 total malware files in 2021. More urgently, this number represents an increase of a whopping 196% from 2020’s numbers. There were also huge spikes in both known and unknown malware detections in 2021 at 133.8% and 221%, respectively.
Cybercriminals worked overtime to attach malware in malicious emails in 2021 using advanced tactics and social engineering lures. In January, we saw how Emotet sent spam emails that used hexadecimal and octal representations of IP addresses for detection evasion in its delivery of malware such as TrickBot and Cobalt Strike.
In May last year, we reported on Panda Stealer, an information stealer that targets cryptocurrency wallets and credentials via spam emails. We also shared an update on APT-C-36 (aka Blind Eagle), an advanced persistent threat (APT) group targeting South American entities using a spam campaign that used fraudulent emails impersonating Colombia’s national directorate of taxes and customs and even fake infidelity email lures.
QAKBOT operators also resumed their spam campaign in late 2021 after an almost three-month hiatus and abused hijacked email threads to lead victims to both QAKBOT and the SquirrelWaffle malware loader.
Meanwhile, ransomware detections continued to decline in 2021, a consistent trend that we have been seeing in previous years. Last year, the Trend Micro Cloud App Security solution detected and blocked 101,215 ransomware files — a 43.4% decrease compared to 2020’s detections.
The reason behind this continuing decline is possibly two-fold: One, unlike legacy ransomware that focuses on the quantity of victims, modern ransomware focuses on waging highly targeted and planned attacks to yield bigger profits. Since today’s ransomware actors no longer abide by the spray-and-pray ransomware model, the number of attacks are no longer as massive as the number that we witnessed in ransomware’s early days. We identified the other reason in our year-end roundup report: That is, it’s possible that ransomware detections are down because our cybersecurity solutions continue to block an increasing number of ransomware affiliate tools each year, including TrickBot and BazarLoader. This could have prevented ransomware attacks from being successfully executed on victim environments.
Known, unknown, and overall credential phishing attacks rose in 2021
Based on Trend Micro Cloud App Security data, 6,299,883 credential phishing attacks were detected and blocked in 2021, which accounts for a 15.2% overall increase. Similar to last year, the number of known credential phishing attacks is greater than the unknown ones. However, this year, the percentage of increase is at a staggering 72.8%.
When comparing 2020 and 2021’s numbers, we saw an 8.4% increase in the number of detections for known credential phishing links, while a 30% growth is observed in the number of detections for unknown credential phishing links.
Abnormal Security noted the increase in overall credential phishing attacks in one 2021 report and stated that credential phishing is attributed to 73% of all advanced threats that they’ve analyzed.
We have also documented the rise in credential phishing attacks from previous years. In fact, in the first half of 2019, the Trend Micro Cloud App Security solution detected and blocked 2.4 million credential phishing attacks alone.
BEC’s small numbers bring big business losses
The Trend Micro Cloud App Security solution intercepted a total of 283,859 BEC attacks in 2021. Compared with 2020’s BEC detections, this number represents a 10.61% decrease. Interestingly, there is an 82.7% increase in this year’s BEC attacks that were detected using Writing Style DNA, while there is a 38.59% decrease in attacks that have been blocked using the antispam engine.
Overall, BEC numbers have consistently been on a downward trend since 2020. But the reduction in BEC victims doesn’t equate to a dip in cybercriminal profits. According to the FBI’s IC3, BEC accounted for US$2.4 billion in adjusted losses for both businesses and consumers in 2021. According to the same organization, BEC losses have reached over US$43 billion between June 2016 and December 2021 for both domestic and international incidents.
We have also observed how BEC actors continuously tweak their tactics for ill gain. In August last year, our telemetry showed a gradual increase in BEC detections. Upon investigation, we discovered that instead of impersonating company executives and upper management personnel, this BEC-related email campaign impersonated and targeted ordinary employees for money transfers and bank payroll account changes.
Covid-19 lures, cybercriminal campaigns behind massive jump in phishing numbers
The Trend Micro Cloud App Security solution data shows that a total of 16,451,166 phishing attacks were detected and blocked in 2021. This is a 137.6% growth from 2020’s phishing numbers.
In contrast to last year’s numbers, we saw a significant jump in phishing attacks detected via spam count this year — a whopping 596% increase, to be specific. Meanwhile, we observed a notable 15.26% increase in credential phishing count compared to last year.
These high numbers reflect organizations’ sentiments about phishing attacks. According to a survey in an Osterman Research report titled “How to Reduce the Risk of Phishing and Ransomware,” organizations were “concerned” or “extremely concerned” about phishing attempts making their way to end users and employees failing to spot phishing and social engineering attacks before accessing a link or attachment.
While they kicked off majority of Covid-19-related phishing emails and sites in 2020, cybercriminals still exploited the global pandemic for financial gain. Last year, Mexico-based medical laboratory El Chopo shared that a fraudulent website that looked identical to the company’s had been launched. On that website, users could schedule a vaccination appointment after paying MXN2,700 (approximately US$130). To make the fake website appear credible, the malicious actors behind it added fake contact information such as email addresses and social media pages that victims can use for inquiries.
Early last year, we reported on a wave of phishing emails that pretended to be coming from national postal systems. This campaign attempted to steal credit card numbers from 26 countries. We also investigated a spear-phishing campaign that used Pegasus spyware-related emails to lead victims into downloading a file stealer. This campaign targeted high-ranking political leaders, activists, and journalists in 11 countries.
Protect emails, endpoints, and cloud-based services and apps from attacks with Trend Micro Cloud App Security
Organizations should consider a comprehensive multilayered security solution such as Trend Micro Cloud App Security. It supplements the preexisting security features in email and collaboration platforms like Microsoft 365 and Google Workspace (formerly known as G Suite) by using machine learning (ML) to analyze and detect any suspicious content in the message body and attachments of an email. It also acts as a second layer of protection after emails and files have passed through Microsoft 365 or Gmail’s built-in security.
Trend Micro Cloud App Security uses technologies such as sandbox malware analysis, document exploit detection, and file, email, and web reputation technologies to detect malware hidden in Microsoft 365 or PDF documents. It provides data loss prevention (DLP) and advanced malware protection for Box, Dropbox, Google Drive, SharePoint Online, OneDrive for Business, and Salesforce while also enabling consistent DLP policies across multiple cloud-based applications. It also offers seamless integration with an organization’s existing cloud setup, preserving full user and administrator functionality, providing direct cloud-to-cloud integration through vendor APIs, and minimizing the need for additional resources by assessing threat risks before sandbox malware analysis.
Trend Micro Cloud App Security stands on the cutting edge of email and software-as-a-service (SaaS) security, offering ML-powered features that combat two of the primary email-based threats: BEC and credential phishing. Writing Style DNA can help determine if an email is legitimate by using ML to check a user’s writing style based on past emails and then comparing suspicious emails against it. Computer vision, on the other hand, combines image analysis and ML to check branded elements, login forms, and other site content. It then pools this information with site reputation elements and optical character recognition (OCR) to check for fake and malicious sites — all while reducing instances of false positives to detect credential phishing email.
This security solution also comes with an option to rescan historical URLs in users’ email metadata and perform continued remediation (automatically taking configured actions or restoring quarantined messages) using newer patterns updated by Web Reputation Services.
This is a significant option since users’ email metadata might include undetected suspicious or dangerous URLs that have only recently been discovered. The examination of such metadata is thus an important part of forensic investigations that help determine if your email service has been affected by attacks. This solution also officially supports the Time-of-Click Protection feature to protect Exchange Online users against potential risks when they access URLs in incoming email messages.
Trend Micro Cloud App Security also comes with the advanced and extended security capabilities of Trend Micro XDR, providing investigation, detection, and response across your endpoints, email, and servers.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA), along with the Coast Guard Cyber Command (CGCYBER), on Thursday released a joint advisory warning of continued attempts on the part of threat actors to exploit the Log4Shell flaw in VMware Horizon servers to breach target networks.
“Since December 2021, multiple threat actor groups have exploited Log4Shell on unpatched, public-facing VMware Horizon and [Unified Access Gateway] servers,” the agencies said. “As part of this exploitation, suspected APT actors implanted loader malware on compromised systems with embedded executables enabling remote command-and-control (C2).”
In one instance, the adversary is said to have been able to move laterally inside the victim network, obtain access to a disaster recovery network, and collect and exfiltrate sensitive law enforcement data.
Log4Shell, tracked as CVE-2021-44228 (CVSS score: 10.0), is a remote code execution vulnerability affecting the Apache Log4j logging library that’s used by a wide range of consumers and enterprise services, websites, applications, and other products.
Successful exploitation of the flaw could enable an attacker to send a specially-crafted command to an affected system, enabling the actors to execute malicious code and seize control of the target.
Based on information gathered as part of two incident response engagements, the agencies said that the attackers weaponized the exploit to drop rogue payloads, including PowerShell scripts and a remote access tool dubbed “hmsvc.exe” that’s equipped with capabilities to log keystrokes and deploy additional malware.
“The malware can function as a C2 tunneling proxy, allowing a remote operator to pivot to other systems and move further into a network,” the agencies noted, adding it also offers a “graphical user interface (GUI) access over a target Windows system’s desktop.”
The PowerShell scripts, observed in the production environment of a second organization, facilitated lateral movement, enabling the APT actors to implant loader malware containing executables that include the ability to remotely monitor a system’s desktop, gain reverse shell access, exfiltrate data, and upload and execute next-stage binaries.
Furthermore, the adversarial collective leveraged CVE-2022-22954, a remote code execution vulnerability in VMware Workspace ONE Access and Identity Manager that came to light in April 2022, to deliver the Dingo J-spy web shell.
Ongoing Log4Shell-related activity even after more than six months suggests that the flaw is of high interest to attackers, including state-sponsored advanced persistent threat (APT) actors, who have opportunistically targeted unpatched servers to gain an initial foothold for follow-on activity.
According to cybersecurity company ExtraHop, Log4j vulnerabilities have been subjected to relentless scanning attempts, with financial and healthcare sectors emerging as an outsized market for potential attacks.
“Log4j is here to stay, we will see attackers leveraging it again and again,” IBM-owned Randori said in an April 2022 report. “Log4j buried deep into layers and layers of shared third-party code, leading us to the conclusion that we’ll see instances of the Log4j vulnerability being exploited in services used by organizations that use a lot of open source.”
Security researchers found that Adobe Acrobat is trying to block security software from having visibility into the PDF files it opens, creating a security risk for the users.
Adobe’s product is checking if components from 30 security products are loaded into its processes and likely blocks them, essentially denying them from monitoring for malicious activity.
Flagging incompatible AVs
For a security tool to work, it needs visibility into all processes on the system, which is achieved by injecting dynamic-link libraries (DLLs) into software products launching on the machine.
PDF files have been abused in the past to execute malware on the system. One method is to add a command in the ‘OpenAction’ section of document to run PowerShell commands for malicious activity, explain the researchers at cybersecurity company Minerva Labs.
“Since March of 2022 we’ve seen a gradual uptick in Adobe Acrobat Reader processes attempting to query which security product DLLs are loaded into it by acquiring a handle of the DLL” – Minerva Labs
According to a report this week, the list has grown to include 30 DLLs from security products of various vendors. Among the more popular ones with consumers are Bitdefender, Avast, Trend Micro, Symantec, Malwarebytes, ESET, Kaspersky, F-Secure, Sophos, Emsisoft.
Querying the system is done with ‘libcef.dll’, a Chromium Embedded Framework (CEF) Dynamic Link Library used by a wide variety of programs.
While the Chromium DLL comes with a short list of components to be blacklisted because they cause conflicts, vendors using it can make modifications and add any DLL they want.
Chromium’s list of hardcoded DLLs, source: Minerva Labs
The researchers explain that “libcef.dll is loaded by two Adobe processes: AcroCEF.exe and RdrCEF.exe” so both products are checking the system for components of the same security products.
Looking closer at what happens with the DLLs injected into Adobe processes, Minerva Labs found that Adobe checks if the bBlockDllInjection value under the registry key ‘SOFTWARE\Adobe\Adobe Acrobat\DC\DLLInjection\’ is set to 1. If so, it will prevent antivirus software’s DLLs from being injected into processes.
It is worth noting that the registry key’s value when Adobe Reader runs for the first time is ‘0’ and that it can be modified at any time.
“With the registry key name dBlockDllInjection, and looking at the cef documentation, we can assume that the the blacklisted DLLs are designated to be unloaded” – Minerva Labs
According to Minerva Labs researcher Natalie Zargarov, the default value for the registry key is set to ‘1’ – indicating active blocking. This setting may depend on the operating system or the Adobe Acrobat version installed, as well as other variables on the system.
In a post on Citrix forums on March 28, a user complaining about Sophos AV errors due to having an Adobe product installed said that the company “suggested to disable DLL-injection for Acrobat and Reader.
Adobe responding to Citrix user experiencing errors on machine with Sophos AV
Working on the problem
Replying to BleepingComputer, Adobe confirmed that users have reported experiencing issue due to DLL components from some security products being incompatible with Adobe Acrobat’s usage of the CEF library.
“We are aware of reports that some DLLs from security tools are incompatible with Adobe Acrobat’s usage of CEF, a Chromium based engine with a restricted sandbox design, and may cause stability issues” – Adobe
The company added that it is currently working with these vendors to address the problem and “to ensure proper functionality with Acrobat’s CEF sandbox design going forward.”
Minerva Labs researchers argue that Adobe chose a solution that solves compatibility problems but introduces a real attack risk by preventing security software from protecting the system.
BleepingComputer has contacted Adobe with further questions to explain the conditions the DLL blocking occurs and will update the article once we have the information.
A webmail application enables organizations to host a centralized, browser-based email client for their members. Typically, users log into the webmail server with their email credentials, then the webmail server acts as a proxy to the organization’s email server and allows authenticated users to view and send emails.
With so much trust being placed into webmail servers, they naturally become a highly interesting target for attackers. If a sophisticated adversary could compromise a webmail server, they can intercept every sent and received email, access password-reset links, and sensitive documents, impersonate personnel and steal all credentials of users logging into the webmail service.
This blog post discusses a vulnerability that the Sonar R&D team discovered in Horde Webmail. The vulnerability allows an attacker to fully take over an instance as soon as a victim opens an email the attacker sent. At the time of writing, no official patch is available.
Impact
The discovered code vulnerability (CVE-2022-30287) allows an authenticated user of a Horde instance to execute arbitrary code on the underlying server.
The vulnerability can be exploited with a single GET request which can be triggered via Cross-Site-Request-Forgery. For this, an attacker can craft a malicious email and include an external image that when rendered exploits the vulnerability without further interaction of a victim: the only requirement is to have a victim open the malicious email.
The vulnerability exists in the default configuration and can be exploited with no knowledge of a targeted Horde instance. We confirmed that it exists in the latest version. The vendor has not released a patch at the time of writing.
Another side-effect of this vulnerability is that the clear-text credentials of the victim triggering the exploit are leaked to the attacker. The adversary could then use them to gain access to even more services of an organization. This is demonstrated in our video:
In the following sections, we go into detail about the root cause of this vulnerability and how attackers could exploit it.
Background – Horde Address Book configuration
Horde Webmail allows users to manage contacts. From the web interface, they can add, delete and search contacts. Administrators can configure where these contacts should be stored and create multiple address books, each backed by a different backend server and protocol.
The following snippet is an excerpt from the default address book configuration file and shows the default configuration for an LDAP backend:
As can be seen, this LDAP configuration is added to an array of available address book backends stored in the $cfgSources array. The configuration itself is a key/value array containing entries used to configure the LDAP driver.
CVE-2022-30287 – Lack of type checking in Factory class
When a user interacts with an endpoint related to contacts, they are expected to send a string identifying the address book they want to use. Horde then fetches the corresponding configuration from the $cfgSources array and manages the connection to the address book backend.
The following code snippet demonstrates typical usage of this pattern:
The code snippet above shows how the parameter $source is received and passed to the create() method of the Turba_Factory_Driver. Turba is the name of the address book component of Horde.
Things start to become interesting when looking at the create() method:
turba/lib/Factory/Driver.php
51 public function create($name, $name2 = '', $cfgSources = array())
52 {
53 // …
57 if (is_array($name)) {
58 ksort($name);
59 $key = md5(serialize($name));
60 $srcName = $name2;
61 $srcConfig = $name;
62 } else {
63 $key = $name;
64 $srcName = $name;
65 if (empty($cfgSources[$name])) {
66 throw new Turba_Exception(sprintf(_("The address book \"%s\" does not exist."), $name));
67 }
68 $srcConfig = $cfgSources[$name];
69 }
On line 57, the type of the $name parameter is checked. This parameter corresponds to the previously shown $source parameter. If it is an array, it is used directly as a config by setting it to $srcConfig variable. If it is a string, the global $cfgSources is accessed with it and the corresponding configuration is fetched.
This behavior is interesting to an attacker as Horde expects a well-behaved user to send a string, which then leads to a trusted configuration being used. However, there is no type checking in place which could stop an attacker from sending an array as a parameter and supplying an entirely controlled configuration.
Some lines of code later, the create() method dynamically instantiates a driver class using values from the attacker-controlled array:
With this level of control, an attacker can choose to instantiate an arbitrary address book driver and has full control over the parameters passed to it, such as for example the host, username, password, file paths etc.
Instantiating a driver that enables an attacker to execute arbitrary code
The next step for an attacker would be to inject a driver configuration that enables them to execute arbitrary code on the Horde instance they are targeting.
We discovered that Horde supports connecting to an IMSP server, which uses a protocol that was drafted in 1995 but never finalized as it was superseded by the ACAP protocol. When connecting to this server, Horde fetches various entries. Some of these entries are interpreted as PHP serialized objects and are then unserialized.
The following code excerpt from the _read() method of the IMSP driver class shows how the existence of a __members entry is checked. If it exists, it is deserialized:
turba/lib/Driver/Imsp.php
223 if (!empty($temp['__members'])) {
224 $tmembers = @unserialize($temp['__members']);
225 }
By default, Horde blocks any images in HTML emails that don’t have a data: URI. An attacker can bypass this restriction by using the HTML tags <picture> and <source>. A <picture> tag allows developers to specify multiple image sources that are loaded depending on the dimensions of the user visiting the site. The following example bypasses the blocking of external images:
At the time of writing, no official patch is available. As Horde seems to be no longer actively maintained, we recommend considering alternative webmail solutions.
Timeline
Date
Action
2022-02-02
We report the issue to the vendor and inform about our 90 disclosure policy
2022-02-17
We ask for a status update.
2022-03-02
Horde releases a fix for a different issue we reported previously and acknowledge this report.
2022-05-03
We inform the vendor that the 90-day disclosure deadline has passed
Summary
In this blog post, we described a vulnerability that allows an attacker to take over a Horde webmail instance simply by sending an email to a victim and having the victim read the email.
The vulnerability occurs in PHP code, which is typically using dynamic types. In this case, a security-sensitive branch was entered if a user-controlled variable was of the type array. We highly discourage developers from making security decisions based on the type of a variable, as it is often easy to miss language-specific quirks.
Pharmaceutical giant Novartis says no sensitive data was compromised in a recent cyberattack by the Industrial Spy data-extortion gang.
Industrial Spy is a hacking group that runs an extortion marketplace where they sell data stolen from compromised organizations.
Yesterday, the hacking group began selling data allegedly stolen from Novartis on their Tor extortion marketplace for $500,000 in bitcoins.
The threat actors claim that the data is related to RNA and DNA-based drug technology and tests from Novartis and were stolen “directly from the laboratory environment of the manufacturing plant.”
Novartis data sold on the Industrial Spy extortion marketplace Source: BleepingComputer
The data being sold consists of 7.7 MB of PDF files, which all have a timestamp of 2/25/2022 04:26, likely when the data was stolen.
As the amount of data for sale is minimal, it is not clear if this is all the threat actors stole or if they have further data to sell later.
BleepingComputer emailed Novartis to confirm the attack and theft of data and received the following statement.
“Novartis is aware of this matter. We have thoroughly investigated it and we can confirm that no sensitive data has been compromised. We take data privacy and security very seriously and have implemented industry standard measures in response to these kind of threats to ensure the safety of our data.” – Novartis.
Novartis declined to answer any further questions about the breach, when it occurred, and how the threat actors gained access to their data.
Industrial Spy is also known to use ransomware in attacks, but there is no evidence that devices were encrypted during the Novartis incident.
Microsoft has released optional cumulative update previews for Windows 10 versions 20H2, 21H1, and 21H2, fixing slow file copying and applications crashing due to Direct3D issues.
Today’s KB5014023 update is part of Microsoft’s scheduled May 2022 monthly “C” updates which allow Windows customers to test bug fixes and performance improvements before the general release on June 15 during Patch Tuesday.
Unlike regular Patch Tuesday cumulative updates, these scheduled non-security preview updates are optional.
To install KB5014023, you have to go to Settings > Windows Update and manually ‘Check for updates.’ Because they’re optional updates, Windows will not install them until you click the ‘Download now’ button.
You can also manually download and install the KB5014023 cumulative update preview from the Microsoft Update Catalog.
Today’s optional update fixes several issues that might trigger various problems or cause some Windows applications to crash.
This cumulative update fixes a known issue affecting specific GPUs that could “cause apps to close unexpectedly or cause intermittent issues that affect some apps that use Direct3D 9.”
Microsoft also fixed an issue that might cause file copying to be slower and one more that would prevent BitLocker from encrypting when using the silent encryption option.
KB5014023 addresses other known issues impacting Windows systems in use 24/7, leading to a memory leak and causing the deduplication driver to deplete all physical memory and cause the machine to stop responding.
Last but not least, after applying today’s preview update, Windows systems will no longer stop responding when users sign out when Microsoft OneDrive is in use.
What’s new in today’s Windows update preview
After installing the KB5014023 non-security cumulative update preview, Windows 10 21H2 will have the build number changed to 19044.1741.
Addresses an issue that causes a yellow exclamation point to display in Device Manager. This occurs when a Bluetooth remote device advertises the Advanced Audio Distribution Profile (A2DP) source (SRC).
Addresses a rare issue that prevents Microsoft Excel or Microsoft Outlook from opening.
Addresses a known issue that might prevent recovery discs (CD or DVD) from starting if you created them using the Backup and Restore (Windows 7) app in Control Panel. This issue occurs after installing Windows updates released January 11, 2022 or later.
On Monday May 30, 2022, Microsoft issued CVE-2022-30190 regarding the Microsoft Support Diagnostic Tool (MSDT) in Windows vulnerability.
A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.
Workarounds
To disable the MSDT URL Protocol
Disabling MSDT URL protocol prevents troubleshooters being launched as links including links throughout the operating system. Troubleshooters can still be accessed using the Get Help application and in system settings as other or additional troubleshooters. Follow these steps to disable:
Run Command Prompt as Administrator.
To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename“
Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.
How to undo the workaround
Run Command Prompt as Administrator.
To restore the registry key, execute the command “reg import filename”
Microsoft Defender Detections & Protections
Customers with Microsoft Defender Antivirus should turn-on cloud-delivered protection and automatic sample submission. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
Customers of Microsoft Defender for Endpoint can enable attack surface reduction rule “BlockOfficeCreateProcessRule” that blocks Office apps from creating child processes. Creating malicious child processes is a common malware strategy. For more information see Attack surface reduction rules overview.
Microsoft Defender Antivirus provides detections and protections for possible vulnerability exploitation under the following signatures using detection build 1.367.719.0 or newer:
Behavior:Win32/MesdettyLaunch.A!blk (terminates the process that launched msdt command line)
Microsoft Defender for Endpoint provides customers detections and alerts. The following alert title in the Microsoft 365 Defender portal can indicate threat activity on your network:
Suspicious behavior by an Office application
Suspicious behavior by Msdt.exe
FAQ
Q: Does Protected View and Application Guard for Office provide protection from this vulnerability?
A: If the calling application is a Microsoft Office application, by default, Microsoft Office opens documents from the internet in Protected View or Application Guard for Office, both of which prevent the current attack.
Microsoft uncovered high-severity vulnerabilities in a mobile framework owned by mce Systems and used by multiple large mobile service providers in pre-installed Android System apps that potentially exposed users to remote (albeit complex) or local attacks. The vulnerabilities, which affected apps with millions of downloads, have been fixed by all involved parties. Coupled with the extensive system privileges that pre-installed apps have, these vulnerabilities could have been attack vectors for attackers to access system configuration and sensitive information.
As it is with many of pre-installed or default applications that most Android devices come with these days, some of the affected apps cannot be fully uninstalled or disabled without gaining root access to the device. We worked with mce Systems, the developer of the framework, and the affected mobile service providers to solve these issues. We commend the quick and professional resolution from the mce Systems engineering teams, as well as the relevant providers in fixing each of these issues, ensuring that users can continue using such a crucial framework.
Collaboration among security researchers, software vendors, and the security community is important to continuously improve defenses for the larger ecosystem. As the threat and computing landscape continues to evolve, vulnerability discoveries, coordinated response, and other forms of threat intelligence sharing are paramount to protecting customers against present and future threats, regardless of the platform or device they are using.
Uncovering the vulnerabilities
Our research on the framework vulnerabilities began while trying to better understand how a pre-installed System application could affect the overall security of mobile devices. We discovered that the framework, which is used by numerous apps, had a “BROWSABLE” service activity that an attacker could remotely invoke to exploit several vulnerabilities that could allow adversaries to implant a persistent backdoor or take substantial control over the device.
The framework seemed to be designed to offer self-diagnostic mechanisms to identify and resolve issues impacting the Android device, indicating its permissions were inherently broad with access to valuable resources. For example, the framework was authorized to access system resources and perform system-related tasks, like adjusting the device’s audio, camera, power, and storage controls. Moreover, we found that the framework was being used by default system applications to leverage its self-diagnostic capabilities, demonstrating that the affiliated apps also included extensive device privileges that could be exploited via the vulnerable framework.
According to mce Systems, some of these vulnerabilities also affected other apps on both Android and iOS devices. Moreover, the vulnerable framework and affiliated apps were found on devices from large international mobile service providers. mce Systems, which offers “Mobile Device Lifecycle and Automation Technologies,” also permitted providers to customize and brand their respective mobile apps and frameworks. Pre-installed frameworks and mobile apps such as mce Systems’ are beneficial to users and providers in areas like simplifying the device activation process, troubleshooting device issues, and optimizing performance. However, their extensive control over the device to deliver these kinds of services could also make them an attractive target for attackers.
Our analysis further found that the apps were embedded in the devices’ system image, suggesting that they were default applications installed by phone providers. All of the apps are available on the Google Play Store where they go through Google Play Protect’s automatic safety checks, but these checks previously did not scan for these types of issues. As part of our effort to help ensure broad protection against these issues, we shared our research with Google, and Google Play Protect now identifies these types of vulnerabilities.
We initially discovered the vulnerabilities in September 2021 and shared our findings with mce Systems and affected mobile service providers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). We worked closely with mce Systems’ security and engineering teams to mitigate these vulnerabilities, which included mce Systems sending an urgent framework update to the impacted providers and releasing fixes for the issues. At the time of publication, there have been no reported signs of these vulnerabilities being exploited in the wild.
The high-severity vulnerabilities, which have a Common Vulnerability Scoring System (CVSS) score of 7.0-8.9, are now identified as CVE-2021-42598, CVE-2021-42599, CVE-2021-42600, and CVE-2021-42601. We want to thank mce Systems’ engineering teams for collaborating quickly and efficiently in resolving these issues as well as to AT&T for proactively working with Microsoft to ensure customers can safely continue to use the framework.
Several other mobile service providers were found using the vulnerable framework with their respective apps, suggesting that there could be additional providers still undiscovered that may be impacted. The affected providers linked below have made updated app versions available to users before this disclosure, ensuring devices can be protected before these vulnerabilities could be exploited. We encourage these providers’ customers to update to the latest versions of these apps from the Google Play store, which include but are not limited to: com.telus.checkup, com.att.dh, com.fivemobile.myaccount, com.freedom.mlp,uat, and com.ca.bell.contenttransfer.
Additionally, the package com.mce.mceiotraceagent might be installed by several mobile phone repair shops. Mobile users are advised to look for that app name and remove it from their phone, if found.
Analyzing apps that use the mce framework
App manifest and permissions
When analyzing an Android application, the first thing that comes to mind is checking its manifest, maintained under the AndroidManifest.xml file. The manifest describes the application itself and its components, such as the following:
Permissions (for example, camera access, internet access, and others)
Activities and how they respond to Intents sent to them
Content providers
Receivers and the kind of content they expect to receive
Services
Checking the manifest of an app affiliated with mce Systems’ framework shed light on some of its features and capabilities but did not immediately indicate that any vulnerabilities or security issues were present. Therefore, further research into the app’s functionality was needed by understanding its permissions.
Analysis of the app’s permissions on the mobile device revealed authorizations that could lead to powerful access and capabilities for an attacker. Those permissions included control over the following:
Networking: access the internet, modify Wi-Fi state, network state, NFC, and Bluetooth
File access: read and write to the external storage
Peripherals: access the camera, record audio, get fingerprint information, and get the device’s physical location
Private information: read phone numbers, account information, and contacts
Management: install apps and modify device settings
With access to these valuable resources, the app could be abused by an attacker to implant a persistent backdoor on the device.
BROWSABLE activities
The “Activities” section of the app’s manifest detailed that the Intent-filter element included activities with a “BROWSABLE” category. While most Intents do not require a category, category strings detail the components that should handle the Intent. In particular, the BROWSABLE category allows the target Activity to be triggered from a web browser to display data referenced by a link, like an image. BROWSABLE activities appeal to attackers as the latter can exploit them via malicious web pages and other Intent-based attacks.
Figure 1: BROWSABLE Activity with the “mcedigital://” scheme
The Intent-filter element in the manifest dictates how the Activity can be triggered. In the app’s case, the Activity could be triggered by simply clicking a link with the “mcedigital://” scheme. This would start the com.mce.sdk.AppActivity Activity with an Intent with arbitrary data (besides the scheme).
Digging deeper: Reviewing the mce framework’s main functionality
We reviewed the effects of triggering the com.mce.sdk.AppActivity. Also known as appActivity, this Activity refers to the different functionalities provided by the app. AppActivity extends Activity and therefore has an onCreate method, which traditionally handles the creating Intent.
AppActivity
Here’s a brief description of AppActivity:
AppActivity has a member called “webView” and type “JarvisWebView,” a specialized class that extends WebView.
Upon creation, AppActivity has some optional display choices from the Intent (if they exist) and then loads a predefined web page to the WebView. That predefined page can get arbitrary query parameters from the Intent’s data; that is, everything after a “\?” will be added to the web page.
A JavaScript Interface is a conspicuous target to look for security issues, as it uses a JavaScript Bridge to allow invoking specific methods inside an Android app. In the case of JarvisJSInterface, three methods are exported:
init(String): takes a string that will be used as a JavaScript callback method; in our case, it will always be window.AndroidCallback
windowClose(): runs a callback registered by the Android app
request(String): sends a service request from the JavaScript client to the server (Android app)
The request method is by far the most interesting, as it performs the following:
Interprets the given string as a JSON object
Extracts the following pieces from the JSON object:
Context: a random GUID generated by the client, used to link requests and responses
Service: the service we are about to call to
Command: an integer
Data: optional parameters sent to the service call
Invokes the method serviceCall, which finds the registered service, gets the method based on the command number, and eventually invokes that method using Java reflection
Figure 2: Service::callServiceMethod
The serviceCall is a powerful method, as it allows the WebView to invoke “services” freely. But what are these services, exactly?
Services offered by the mce framework
After we examined the services offered by this framework per the app manifest, we then obtained a list of services that practically give the WebView complete control over the device. The most notable services include:
Audio: access and manipulate volume levels, as well as play a tone with a given duration and frequency
Camera: take a silent snapshot
Connectivity: control and obtain valuable information from NFC, Wi-Fi, and Bluetooth
Device: includes various device controlling mechanisms like battery drainage, performing a factory reset, and obtaining information on apps, addresses, sensor data, and much more
Discovery: set the device to discoverable
Location: obtain the location in various modes and set the location state
PackageManager: acquire package info and silently install a new app
Power: obtain charging state
Sensor: acquire sensor data such as barometer data, light data, proximity data, and whether fingerprinting is working
Storage: obtain content such as documents, media, images, and videos
These services inherit from a base class named “Service” and implement two methods:
setServiceName: for service identification purposes
setServiceMethodMap: for setting up the mapping between the command integer and the method name, argument names, and argument types
For example, here is the Camera service setting its methods:
Method 0 is “getCameraList” and expects no arguments.
Method 1 is “captureStillImageNoPreview” and expects one String argument.
Figure 3: The Camera service setting its methods
Vulnerability findings
Based on our analysis of the mce framework, we discovered several vulnerabilities. It should be noted that while mobile service providers can customize their apps respective to mce framework so as not to be identical, the vulnerabilities we discovered can all be exploited in the same manner—by injecting code into the web view. Nonetheless, as their apps and framework customization use different configurations and versions, not all providers are necessarily vulnerable to all the discovered vulnerabilities.
We found a command-injection vulnerability, tracked as CVE-2021-42599, in the Device service mentioned in the previous section. This service offers rich functionality, including the capability to stop activities of a given package. The client fully controls the argument “value,” and simply runs the following command:
am force-stop "value"
Since the argument is not sanitized, an attacker could add backticks or quotation marks to run arbitrary code, like the following:
am force-stop "a"; command-to-run; echo "a"
Figure 4: Command injection proof-of-concept (POC) exploit code implemented in the Device service
According to mce Systems, they have since removed the functionality behind this vulnerability and it is no longer present in more advanced framework versions.
Exploitation by JavaScript injection with PiTM in certain apps
The services offered by the mce framework further indicated that the following vulnerability resided in the logic of the JavaScript client for apps that are configured to enable plaintext communications such as the app that we initially analyzed. Interestingly, the code for the client is a heavily-obfuscated dynamic JavaScript code that is implemented over several files, mainly bundle.js. Due to the blind trust between the JavaScript client and the JarvisJSInterface server, an attacker who could inject JavaScript contents into the WebView would inherit the permissions that the app already has.
We conceived two injection strategies most likely to be leveraged by attackers:
Affect the JavaScript client behavior by supplying specific GET parameters from the BROWSABLE Intent.
Trigger an app with the BROWSABLE Intent to become a person-in-the-middle (PiTM) and view the device’s entire traffic. Inject JavaScript code if the client ever tries to fetch external content and interpret it as a script or HTML.
Once we reverse-engineered the client’s obfuscated code, we discovered that it could not inject JavaScript from the GET parameters. The only capability permitted was to affect some of the client’s self-tests upon initialization, such as a battery-draining test or a Wi-Fi connectivity test. However, the WebView-fetched plaintext pages that we discovered could be injected into with a PiTM attack.
Our proof-of-concept (POC) exploit code was therefore:
Perform a PiTM for the target device and lure the user into clicking a link with the “mcesystems://” schema.
Inject JavaScript into one of the plaintext page responses that does the following:
Hijack the JavaScript interface by calling init with our callback method
Use the JavaScript interface request method to get servicing
Send the data to our server for information gathering using XHR (XMLHttpRequest)
Figure 5: Injecting a similar JavaScript code to the WebView could allow an attacker to call arbitrary services and methods
Local elevation of privilege with deserialization followed by injection (CVE-2021-42601)
Some of the apps we analyzed did not pull plaintext pages. Thus, we looked for a local elevation of privilege vulnerability, allowing a malicious app to gain the system apps’ privileges, tracked as CVE-2021-42601.
In the apps mentioned above, we discovered that the main Activity attempted to handle a deep link (a link that launches an app instead of a browser on click) with Google Firebase. Interestingly, this deep-link handling tried to deserialize a structure called PendingDynamicLinkData (representing a link) from an Intent Extra byte array with the key com.google.firebase.dynamiclinks.DYNAMIC_LINK_DATA. This structure was used later by the mce framework to generate various JSON Objects that might contain data from a categoryId query parameter in the original link, and eventually ended up in the member mFlowSDKInput to be injected into the JarvisWebView instance in an unsafe way:
Figure 6: Unsanitized JavaScript loading allowed arbitrary code injection to the WebView
Since the categoryId query parameter might contain apostrophes, one could inject arbitrary JavaScript code into the WebView. We decided to inject a code that would reach out to a server and load a second-stage code, which was the exact one we used for our PiTM scenario.
Figure 7: Local injection POC exploit
Software design against JavaScript injection vulnerabilities
We worked closely with the mce Systems engineering team and discovered that the reason for unsafe loadUrl invocations with JavaScript injections was that the framework used an asynchronous model of operation. When the JavaScript client performs a request, it expects to be notified later when there are results. Since Android JavaScript Bridge only allows primitive types to be sent (for example, Strings), the mce framework notified the JavaScript client by injecting JavaScript with potentially unsafe arguments (the results themselves).
We offered mce Systems a slightly different software design that prevents unsafe JavaScript injection. The description of the flow of information in our proposal is as follows:
The JavaScript client invokes the request method on the Android JavaScript Bridge, supplying the request itself along with a request ID.
The Java server performs the request and stores the result in a cache. The said cache then maps request IDs to results.
The Java server notifies the client by carefully injecting the JavaScript loadUrl(“javascript:window.onMceResult(<requestID>);”) into the WebView. Note that the only non-constant string is the request ID, which can easily be sanitized. This method “wakes the client up”
The JavaScript client implementation of onMceResult invokes the Android JavaScript Bridge with the method String fetchResult(String requestId). Note that this method returns a string (which contains the result).
This way, the JavaScript client does not need to poll for asynchronous results while data is safely transferred between the client and the server.
Interestingly, Google AndroidX offers a very similar API: webMessageListener. While the said API works quite similarly to our suggestion, it only supports Android versions greater than Lollipop. Thus, the new mce framework now checks the Android version and uses this new Google API if supported or our offered solution for older devices.
The above is just one example of our collaboration to help secure our cross-platform ecosystem. According to mce Systems, all of our reported vulnerabilities were addressed.
Improving security for all through threat intelligence sharing and research-driven protections
Microsoft strives to continuously improve security by collaborating with customers, partners, and industry experts. Responding to the evolving threat landscape requires us to expand our capabilities into other devices and non-Windows platforms in addition to further coordinating research and threat intelligence sharing among the larger security community. This case highlighted the need for expert, cross-industry collaboration to effectively mitigate issues.
Moreover, collaborative research such as this informs our seamless protection capabilities across platforms. For example, intelligence from this analysis helped us ensure that Microsoft Defender Vulnerability Management can identify and remediate devices that have these vulnerabilities, providing security operations teams with comprehensive visibility into their organizational exposure and enabling them to reduce the attack surface. In addition, while we’re not aware of any active exploitation of these mobile vulnerabilities in the wild, Microsoft Defender for Endpoint’s mobile threat defense capabilities significantly improve security on mobile devices by detecting potential exploits, malware, and post-exploitation activity.
We will continue to work with the security community to share intelligence about threats and build better protection for all. Microsoft security researchers continually work to discover new vulnerabilities and threats, turning a variety of wide-reaching issues into tangible results and improved solutions that protect users and organizations across platforms every single day. Similarly inquisitive individuals are encouraged to check opportunities to join the Microsoft research team here: https://careers.microsoft.com/.
Jonathan Bar Or, Sang Shin Jung, Michael Peck, Joe Mansour, and Apurva Kumar Microsoft 365 Defender Research Team
