ownCloud owncloud/android before 2.20 has Incorrect Access Control for physically proximate attackers.

![Open-source secure file sync, share and content collaboration with ownCloud](https://owncloud.com/wp-content/uploads/2020/06/oc-logo-1c-1.svg "Open-source secure file sync, share and content collaboration with ownCloud")

*   Product
*   Community
*   Partners
*   News
    **news***   Insights & Updates
        *   ownCloud News
    *   Forum
        *   ownCloud Central
    *   Events
        *   Upcoming Events
    *   Social Media
        *   Facebook
        *   Twitter
        *   LinkedIn
    
    **Latest Posts**
    
    ![](https://owncloud.com/wp-content/uploads/2022/03/john-schnobrich-FlPc9_VocJ4-unsplash.jpg)
    
    For the past years we have been working on a new project called "Infinite Scale". For this …
    
    Read more
    
    ![](https://owncloud.com/wp-content/uploads/2020/08/ownCloud-Trademark.png)
    
    Manuela Urban (COO, Sovereign Cloud Stack) explains how Sovereign Cloud Stack, federated cloud technology built with Open …
    
    Read more
    
*   Pricing

*   Risk: low
*   CVSS v3 Base Score: 5.3
*   CVSS v3 Vector: AV:P/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N
*   CWE ID: CWE-284
*   CWE Name: CWE-284: Improper Access Control
*   CVE: CVE-2022-25338

**Description**

An attacker with physical access to the device could bypass the app lock of the ownCloud Android App.

**Affected**

*   ownCloud Android app < 2.20

**Action taken**

Properly implement the lock screen

CVE-2022-25338: ownCloud Android App lock bypass - ownCloud

Inappropriate implementation in Full Screen Mode in Google Chrome on Android prior to 98.0.4758.80 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.

About Monorail User Guide Release Notes Feedback on Monorail Terms Privacy

CVE-2022-0455: 1270593 - chromium - An open-source project to help move the web forward.

CVE-2022-28378: cms/CHANGELOG.md at develop · craftcms/cms

An Out of Bounds read may potentially occur while processing an IBSS beacon, in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music

CVE-2021-35117: March 2022 Security Bulletin | Qualcomm

In miniadb, there is a possible way to get read/write access to recovery system properties due to an insecure default value. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-201308542

_Published February 22, 2022_

This Android Security Release Notes contains details of security vulnerabilities affecting Android devices which are addressed as part of Android 12L. Android 12L devices with a security patch level of 2022-03-01 or later are protected against these issues (Android 12L, as released on AOSP, will have a default security patch level of 2022-03-01). To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues prior to publication. Source code patches for these issues will be released to the Android Open Source Project (AOSP) repository as part of the Android 12L release.

The severity assessment of issues in these release notes are based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

We have had no reports of active customer exploitation or abuse of these newly reported issues. Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Announcements**

*   The issues described in this document are addressed as part of Android 12L. This information is provided for reference and transparency.
*   We would like to acknowledge and thank the security research community for their continued contributions towards securing the Android ecosystem.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**Android 12L vulnerability details**

The sections below provide details for security vulnerabilities fixed as part of Android 12L. Vulnerabilities are grouped under the component that they affect and include details such as the CVE, associated references, type of vulnerability, and severity.

**Framework**

   

CVE

References

Type

Severity

CVE-2021-39749

A-205996115

EoP

High

CVE-2021-39743

A-201534884

EoP

Moderate

CVE-2021-39746

A-194696395

EoP

Moderate

CVE-2021-39750

A-206474016

EoP

Moderate

CVE-2021-39752

A-202756848

EoP

Moderate

CVE-2021-39758

A-205130886

EoP

Moderate

CVE-2022-20002

A-198657657

EoP

Moderate

CVE-2021-39744

A-192369136

ID

Moderate

CVE-2021-39745

A-206127671

ID

Moderate

CVE-2021-39747

A-208268457

ID

Moderate

CVE-2021-39748

A-203777141

ID

Moderate

CVE-2021-39751

A-172838801

ID

Moderate

CVE-2021-39753

A-200035185

ID

Moderate

CVE-2021-39755

A-204995407

ID

Moderate

CVE-2021-39756

A-184354287

ID

Moderate

CVE-2021-39757

A-176094662

ID

Moderate

CVE-2021-39754

A-207133709

ID

Moderate

**Media Framework**

   

CVE

References

Type

Severity

CVE-2021-39759

A-180200830

EoP

Moderate

CVE-2021-39760

A-194110526

ID

Moderate

CVE-2021-39761

A-179783181

ID

Moderate

CVE-2021-39762

A-210625816

ID

Moderate

**Platform**

   

CVE

References

Type

Severity

CVE-2021-39741

A-173567719

EoP

Moderate

CVE-2021-39763

A-199176115

EoP

Moderate

CVE-2021-39764

A-170642995

EoP

Moderate

CVE-2021-39767

A-201308542

EoP

Moderate

CVE-2021-39768

A-202017876

EoP

Moderate

CVE-2021-39771

A-198661951

EoP

Moderate

CVE-2021-25393

A-180518134

ID

Moderate

CVE-2021-39739

A-184525194

ID

Moderate

CVE-2021-39740

A-209965112

ID

Moderate

CVE-2021-39742

A-186405602

ID

Moderate

CVE-2021-39765

A-201535427

ID

Moderate

CVE-2021-39766

A-198296421

ID

Moderate

CVE-2021-39769

A-193663287

ID

Moderate

CVE-2021-39770

A-193033501

ID

Moderate

**System**

   

CVE

References

Type

Severity

CVE-2021-39776

A-192614125

EoP

High

CVE-2021-39787

A-202506934

EoP

High

CVE-2021-39772

A-181962322

EoP

Moderate

CVE-2021-39780

A-204992293

EoP

Moderate

CVE-2021-39781

A-195311502

EoP

Moderate

CVE-2021-39782

A-202760015

EoP

Moderate

CVE-2021-39783

A-197960597

EoP

Moderate

CVE-2021-39784

A-200163477

EoP

Moderate

CVE-2021-39786

A-192551247

EoP

Moderate

CVE-2021-39789

A-203880906

EoP

Moderate

CVE-2021-39790

A-186405146

EoP

Moderate

CVE-2021-39773

A-191276656

ID

Moderate

CVE-2021-39775

A-206465854

ID

Moderate

CVE-2021-39777

A-194743207

ID

Moderate

CVE-2021-39778

A-196406138

ID

Moderate

CVE-2021-39779

A-190400974

ID

Moderate

CVE-2021-39788

A-191768014

ID

Moderate

CVE-2021-39791

A-194112606

ID

Moderate

CVE-2021-39774

A-205989472

DoS

Moderate

**Additional Vulnerability details**

The section below provides details for security vulnerabilities that are being provided for disclosure purposes. **These issues are not required for SPL compliance.**

**Android TV**

   

CVE

References

Type

Severity

CVE-2021-1000

A-185190688

EoP

Moderate

CVE-2021-1033

A-185247656

EoP

Moderate

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, see Check and update your Android version.

Android 12L, as released on AOSP, has a default security patch level of 2022-03-01. Android devices running Android 12L and with a security patch level of 2022-03-01 or later address all issues contained in these security release notes.

**2\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**3\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

**Versions**

  

Version

Date

Notes

1.0

February 22, 2022

Security Release Notes Published

CVE-2021-39767: Android 12L Security Release Notes  |  Android Open Source Project

In incfs, there is a possible way of mounting on arbitrary paths due to a missing permission check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-198657657

CVE-2022-20002: Android 12L Security Release Notes  |  Android Open Source Project

Yubico ykneo-openpgp before 1.0.10 has a typo in which an invalid PIN can be used. When first powered up, a signature will be issued even though the PIN has not been validated.

*   Github

Tracking IDs: YSA-2015-1 and CVE-2015-3298.

**Summary**

The source code contains a logical flaw related to user PIN (aka PW1) verification that allows an attacker with local host privileges and/or physical proximity (NFC) to perform security operations without knowledge of the user’s PIN code.

**Mitigation**

The flaw is mitigated by the fact that an attacker would typically require some abilities that would enable the attack even without the logical flaw.

In particular, any attacker with access to the local host must be assumed to be able to learn the user’s PIN code, simply by intercepting communication with the OpenPGP card hardware or through key logging.

Alternatively, if the attacker has physical proximity to the card, it could wait for the device to be used normally over NFC and then learn the PIN code wirelessly and perform the attack at a later point.

If your device is stolen, attackers may use it to perform private-key operations. If an attacker has gone through the trouble of obtaining physical access to a key, the conservative approach is to regard it is possible that the attacker were able to learn the PIN earlier since the PIN is often unprotected. In situations like this, you should treat the key as potentially compromised and revoke the key.

Generally the OpenPGP Card specification does not protect against private key-usage by malware and/or PIN phishing, and any OpenPGP Card implementation is vulnerable to similar attacks.

Note that the private key is not at jeopardy, and malware cannot learn the private key — this is in fact the primary threat that the OpenPGP card specification protects against.

**Analysis**

The following description is courtesy of Joey Castillo.

The bug appears to be a typo in the first line of the computeDigitalSignature, decipher and internalAuthenticate methods. The goal of each is to establish that the PW1 has been validated, AND the proper mode has been set (mode 81 for signing, mode 82 for everything else). According to the spec, if either of these conditions are not satisfied, the security operation should not proceed.

The application mangles this a bit, as you can see in line 628:

if (!pw1.isValidated() && pw1\_modes\[PW1\_MODE\_NO81\])
    ISOException.throwIt(SW\_SECURITY\_STATUS\_NOT\_SATISFIED);
// otherwise execution continues

This truth table shows the outcome of the conditional, and the two cases where the logic fails:

     

Case

PIN valid

Mode 81

!(PIN valid)

Result

Outcome

1

true

true

false

false

No exception

2

false

true

true

true

Exception thrown

3

true

false

false

false

No exception (Incorrect)

4

false

false

true

false

No exception (Incorrect)

I discovered this bug due to case #3: OpenKeychain for Android mistakenly verifies the PIN with mode 82 for signing, which should not allow a signature to be generated. The Yubikey generates a signature anyway.

The dire case is #4: when the card is powered up, the PIN has not been validated, and both modes are set to false. In this state, the card will issue a signature even though the PIN has not been validated. The same bug is present in the decipher command (line 659) and the internalAuthenticate command (line 683), just with the mode set to 82. This means the card will also decrypt session keys and authenticate challenges unconditionally.

**Solution**

This is also courtesy of Joey Castillo.

The fix is to change each of the conditionals to the following:

if (!pw1.isValidated() || !pw1\_modes\[PW1\_MODE\_NO8x\])
    ISOException.throwIt(SW\_SECURITY\_STATUS\_NOT\_SATISFIED);
// otherwise execution continues

This way, if the PIN has not been validated, OR the proper mode has not been set, an exception is thrown. Execution is only allowed to continue if both conditions are true.

This fix has been integrated into ykneo-openpgp and is part of the version 1.0.9 release, but read on for some information about 1.0.10.

**How to check if you are affected**

Versions below 1.0.9 are affected by this problem. Unfortunately, some YubiKey NEOs shipped with a 1.0.9 release that did not contain the fix. To simplify version checking, we have released 1.0.10 and NEOs using that version is known to always include the fix. To be certain that your NEO has the fixed ykneo-openpgp applet installed, look for a version of 1.0.10 or later.

You may check the applet version with the following command.

 gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
 D\[0000\]  01 00 06 90 00                                     .....
 OK

The string "01 00 06" means version 1.0.6, which would be affected by this problem.

**Recommendation**

The logical flaw is real and violates assumption of how the OpenPGP applet works in principle. However its practical consequences are relatively small as a successful attack requires other privileged operations (such as local root access) that are normally not available to an attacker, and would have undermined the security anyway.

Regardless of this assessment, Yubico has decided to replace YubiKey NEO keys for those who are using the OpenPGP applet version 1.0.9 or earlier. This replacement program began on April 26, 2015. **Update: This replacement program ended on April 18, 2019.**

Therefore, we don't see any immediate need for users to upgrade existing deployed products. We will incorporate the improved code in future products sold, and add self-tests to our software project to detect any regression in this area.

For stolen devices, we continue to recommend users to follow best-practices and revoke the key as a conservative measure.

As we take all security related incidents seriously we have prepared a prompt security advisory and released all information about this incident that we know about. We welcome further analysis of the source code, as this will over time increase confidence in the product, and is the reason the source is available.

If you have additional inquiries related to your YubiKey NEO purchase, please contact your sales contact for further discussion.

This defect was present in the code we inherited from the “javacardopenpgp” project, and that project has been notified. There may be other forks, public or not, and we recommend the community to review other code with the same origin.

**History of events**

*   2015-04-11 Reported by Joey Castillo.
    
*   2015-04-11 Version 1 of security advisory circulated for review.
    
*   2015-04-13 Mitre assigned id for vulnerability as CVE-2015-3298.
    
*   2015-04-13 Upstream project “javacardopenpgp” notified.
    
*   2015-04-14 Security advisory published.
    
*   2015-04-20 Some 1.0.9 NEOs were shipped without the fix, text updated to recommend looking for 1.0.10 as a better minimum version.
    
*   2015-04-27 Add an update about Yubico replacement policy.
    
*   2019-04-18 Remove the update about Yubico replacement policy.
    
*   2019-05-02 Clarify previous update, adding date of policy expiration.

CVE-2015-3298: SecurityAdvisory 2015-04-14

Libarchive v3.6.0 was discovered to contain an out-of-bounds read via the component zipx_lzma_alone_init.

hello,i have discussed with security engineer from liblzma,the vulnerability may caused by zipx\_lzma\_alone\_init().if you have time,please debug to check it.look forward to you reply thanks. The Message records bellow: On 2022-03-18 jun ma wrote: &gt; oh，thanks for your reply ，i have debuged it using gdb and discussed &gt; with security&nbsp; engineer from libarchive,it &gt; &gt; high possibility caused by liblzma.when you have time, hope you can &gt; take some time to have a look.thanks! The problem is that lzma\_code() is called with lzma\_stream.avail\_in set to 18446744073709551607 which equals -9 when interpret as a signed value. That is, it's a bug in libarchive. I attached a patch that adds a few fprintf() calls to libarchive which show how the incorrect value comes from zipx\_lzma\_alone\_init() but I didn't debug how to fix it. Here is the output: DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1607: init DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1728: zip-&gt;entry\_bytes\_remaining = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1859: zip-&gt;entry\_bytes\_remaining = 1, bytes\_avail = 94559 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1916: zip-&gt;entry\_bytes\_remaining = 1, to\_consume = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1607: init DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1728: zip-&gt;entry\_bytes\_remaining = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1859: zip-&gt;entry\_bytes\_remaining = 1, bytes\_avail = 94501 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1916: zip-&gt;entry\_bytes\_remaining = 1, to\_consume = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1607: init DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1728: zip-&gt;entry\_bytes\_remaining = -9 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1859: zip-&gt;entry\_bytes\_remaining = -9, bytes\_avail = 94443 Can you forward the above information to libarchive developers? Thank you for your effort to look for bugs and reporting them! Two minor things for the future: I understand that sending the bad .zip file directly as an attachment doesn't work for some destinations because antivirus products can block such emails (GMail does). I could extract the .rar with 7z from p7zip so it wasn't a problem for me, but in general free software developers prefer exchanging information using fully open formats like .zip, .7z, or .tar + some compressor. .zip with its very old (and insecure) encryption is supported widely. I tested this with GMail: &nbsp; &nbsp; zip -e badfile.zip badfile.bin&nbsp; # password set to 123456 This worked. Without encryption it was rejected. I think the filename inside the encrypted .zip must be something like .bin instead of .zip since filenames aren't encrypted. The second thing is that I did receive the email with the subject crash-58af2238755ec09600f15fed6e3e606c09638f42 but I wasn't on my computer during those days, so I was slow to reply, sorry. (My email provider doesn't block attachments as easily as GMail does.) The email contained a 46-megabyte attachment (base64-encoded size) which I suppose was the test program binary. That is a fairly big file to attach and most people (me included) won't run binaries received in email. Again, thanks for your help in finding and reporting bugs!

…

\-- Lasse Collin

\------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "马骏" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年3月4日(星期五) 下午5:15 \*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;回复：转发：回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) Please ask if this vulnerability has been confirmed

\------------------ 原始邮件 ------------------ 发件人: "马骏" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年3月4日(星期五) 上午10:33 \*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;回复：转发：回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) Please ask if this vulnerability has been confirmed

\------------------ 原始邮件 ------------------ 发件人: "马骏" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年2月26日(星期六) 晚上6:31 \*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;转发：回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) i have send this mail ,you can see this

\---原始邮件--- 发件人: \*\*\*@\*\*\*.\*\*\*&gt; 发送时间: 2022年2月26日(周六) 下午5:45 收件人: \*\*\*@\*\*\*.\*\*\*&gt;; 主题: 回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) hello,the testcase 、 source file 、crash file see the attachments。Besides，i have Submit cve aim at this question

\------------------ 原始邮件 ------------------ 发件人: "libarchive/libarchive" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年2月26日(星期六) 下午5:12 \*\*\*@\*\*\*.\*\*\*&gt;; \*\*\*@\*\*\*.\*\*\*\*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;Re: \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) @icycityone what we need is a sample test file to reproduce the vulnerability — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: \*\*\*@\*\*\*.\*\*\*&gt;

CVE-2022-26280: The libarchive lib exist a READ memory access Vulnerability · Issue #1672 · libarchive/libarchive

The client applications in 3CX on Windows, the 3CX app for iOS, and the 3CX application for Android through 2022-03-17 lack SSL certificate validation.

`#############################################################   #   # COMPASS SECURITY ADVISORY   # https://www.compass-security.com/research/advisories/   #   #############################################################   #   # Product: 3CX Client for Windows (legacy), Android & iOS   # Vendor: 3CX   # CSNC ID: CSNC-2021-021   # CVE ID: CVE-2021-45490   # Subject: Missing Certificate Verification   # CWE-ID: CWE-295 (Improper Certificate Validation)   # Severity: Medium   # Effect: Network Traffic Decryption and Manipulation   # Author: Emanuel Duss <emanuel.duss@compass-security.com>   # Date: 2022-03-17   #   #############################################################  Introduction   ------------  3CX is an open-platform office phone system that runs on premise on Windows or   Linux. 3CX was built for mobility, with remote work apps that offer secured   communication for the whole team. With the Android, iOS and Windows apps,   business communication is no longer tied to the office building. [1]  During a customer project, we identified a security vulnerability in the 3CX   clients for Windows (legacy), Android and iOS. These applications do not verify   the TLS certificate of the 3CX server.  Affected   --------  - All versions of the 3CX application for Windows (legacy), Android and iOS are   affected.   - There is no fix from the vendor at the moment.   - The new Electron based 3CX Desktop App is not affected.  Description   -----------  The 3CX clients for Windows (legacy), Android, and iOS do not verify the TLS   certificate of the 3CX server.  This allows an attacker between the 3CX application and the 3CX server to split   the TLS traffic and therefore read and manipulate the transmitted data.  For example, the data required for provisioning a new device can be read every   time when the app is started. This data can then be used to provision another   app.  Thus, attackers can provision an own device and use the entire functionality of   the app. This includes:  - List companies in the phone book   - Make phone calls   - Listen to voice box   - etc.  This attack can for example be reproduced by performing an ARP spoofing attack   in the network against the target client and by using Burp Suite as a   transparent HTTP proxy.  Vulnerability Classification   ----------------------------  CVSS v3.1 Metrics [2]:  - CVSS Base Score: 6.5 (Medium)   - CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N  Workaround / Fix   ----------------  # 3CX Vendor  The app should correctly verify the server's certificate using the system CA   store or implement certificate pinning in the apps.  # 3CX Users  There is no security update for this vulnerability at the moment. According to   the 3CX, the vulnerability will be tackled in future redesigns of the mobile   apps.  Users of the legacy Windows client can switch to the new Electron based 3CX   Desktop App which is not affected.  Timeline   --------  2021-12-16: Vulnerability discovered   2021-12-17: Discussed vulnerability with our customer   Asked 3CX for security contact on Twitter, community forum, support   email and contact form.   Got response via support mail. Security contact was dpo@3cx.com   Provided details   Requested CVE ID @ MITRE   2021-12-25: Assigned CVE-2021-45490   2022-01-03: Asked vendor if they understood the vulnerability.   Answer: Report was distributed internally.   2022-01-18: Asked vendor for any updates.   2022-02-02: Asked vendor for any updates.   2022-02-10: Asked vendor for any updates. 3CX can't tell when the issue will   be fixed.   2022-03-11: Asked vendor for any updates. 3CX thanked for the report.   Issues will be tackled in future redesigns of the mobile apps.   2022-03-17: Coordinated public disclosure  Acknowledgement   ---------------  Thanks 3CX for the coordinated dicslosure.  References   ----------  [1] https://www.3cx.com/   [2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N&version=3.1  `

CVE-2021-45490: 3CX Client Missing TLS Validation ≈ Packet Storm

3CX System through 2022-03-17 stores cleartext passwords in a database.

`#############################################################   #   # COMPASS SECURITY ADVISORY   # https://www.compass-security.com/research/advisories/   #   #############################################################   #   # Product: 3CX Phone System   # Vendor: 3CX   # CSNC ID: CSNC-2021-022   # CVE ID: CVE-2021-45491   # Subject: Exportable Cleartext Passwords   # CWE-ID: CWE-257 (Storing Passwords in a Recoverable Format)   # Severity: Medium   # Effect: Credential Reuse   # Author: Emanuel Duss <emanuel.duss@compass-security.com>   # Date: 2022-03-17   #   #############################################################  Introduction   ------------  3CX is an open-platform office phone system that runs on premise on Windows or   Linux. 3CX was built for mobility, with remote work apps that offer secured   communication for the whole team. With the Android, iOS and Windows apps,   business communication is no longer tied to the office building. [1]  During a customer project, we identified a security vulnerability in the 3CX   system. The user passwords of the 3CX system are stored in plain text in the   database and are also exportable in the administration interface.  Affected   --------  - All versions of the 3CX application are affected.   - There is no fix from the vendor.  Description   -----------  The user passwords of the 3CX system are stored in plain text in the database   and are also exportable in the administration interface.  This can be verified by exporting the credentials via the admin interface or by   looking into the SQL database. This issue is also already documented in the   community forum since 2019 [2].  The storage of passwords in a recoverable format makes them subject to password   reuse attacks by malicious users. In fact, it should be noted that recoverable   encrypted passwords provide no significant benefit over plaintext passwords   since they are subject not only to reuse by malicious attackers but also by   malicious insiders. If a system administrator can recover a password directly,   or use a brute force search on the available information, the administrator can   use the password on other accounts. [3]  Vulnerability Classification   ----------------------------  CVSS v3.1 Metrics [4]:  - CVSS Base Score: 5.5 (Medium)   - CVSS Vector: AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N  Workaround / Fix   ----------------  # 3CX Vendor  A password hash function such as PBKDF2, bcrypt or scrypt should be used for   passwords. The passwords should also be provided with a salt that is generated   individually for each user. This can make attacks that use rainbow tables or   pre-calculated wordlists more difficult.  # 3CX Users  There is no security update for this vulnerability at the moment. According to   the 3CX, the vulnerability will be tackled in future redesigns of the   management console.  Timeline   --------  2021-12-16: Vulnerability discovered   2021-12-17: Discussed vulnerability with our customer   Asked 3CX for security contact on Twitter, community forum, support   email and contact form.   Got response via support mail. Security contact was dpo@3cx.com   Provided details   Requested CVE ID @ MITRE   2021-12-25: Assigned CVE-2021-45491   2022-01-03: Asked vendor if they understood the vulnerability.   Answer: Report was distributed internally.   2022-01-18: Asked vendor for any updates.   2022-02-02: Asked vendor for any updates.   2022-02-10: Asked vendor for any updates. 3CX can't tell when the issue will   be fixed.   2022-03-11: Asked vendor for any updates. 3CX thanked for the report. Issues   will be tackled in future redesigns of the management console.   2022-03-17: Coordinated public disclosure  Acknowledgement   ---------------  Thanks 3CX for the coordinated disclosure.  References   ----------  [1] https://www.3cx.com/   [2] https://www.3cx.de/forum/threads/klartext-passwort-willkommen-mail-also-auch-in-db.94280/   [3] https://cwe.mitre.org/data/definitions/257.html   [4] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N&version=3.1  `

Tag

#android