Intro

Researchers at Checkmarx found that the Ring Android app could have allowed a malicious application installed on the user’s phone to expose their personal data, geolocation, and camera recordings.

Ring by Amazon operates in the home security space and manufactures products that include outdoor and indoor surveillance cameras. Their Android application has been downloaded over 10 million times.

Proof of Concept Video:

To view this video on YouTube, please go here.

Technical Details

The vulnerability was found in the com.ringapp/com.ring.nh.deeplink.DeepLinkActivity activity, which was implicitly exported in the Android Manifest and, as such, was accessible to other applications on the same device. These other applications could be malicious applications that users could be convinced to install.

This activity would accept, load, and execute web content from any server, as long as the Intent’s destination URI contained the string “/better-neighborhoods/”.

We could use adb to replicate a valid Intent:

The attacker-controlled web page could then interact with the WebView’s JavaScript interfaces, as long as it was served from a “ring.com” or “a2z.com” subdomain.

The team at Checkmarx was able to find a Reflected Cross-Site Scripting (XSS) vulnerability in  cyberchef.schlarpc.people.a2z.com, which allowed them to complete this attack chain.

Knowing of this vulnerability, an attacker could trick victims into installing a malicious application that triggered the following Intent to complete the attack:

This payload redirects the WebView to the malicious web page, which can access the __NATIVE__BRIDGE__.getToken() JavaScript Interface that grants access to an Authorization Token, which can then be exfiltrated to an attacker-controlled server.

This token is a Java Web Token (JWT), which is insufficient to authorize calls to Ring’s multiple APIs. Authorization is enforced using an rs_session cookie.

However, this cookie can be obtained by calling the https://ring.com/mobile/authorize endpoint with both a valid Authorization Token plus the corresponding device’s Hardware ID.

Luckily for our researchers, this Hardware ID was encoded into the token.

With this cookie, it was then possible to use Ring’s APIs to extract the customer’s personal data, including full name, email, and phone number, and their Ring device’s data, including geolocation, address, and recordings.

More specifically, the following APIs were used:

• https://acount.ring.com/account/control-center – used to obtain the victim’s
  personal data and device ID
• https://account.ring.com/api/cgw/evm/v2/history/devices/{{DEVICE_ID}} – used to obtain the device data and recordings

Let’s Scale the Attack

Looking at a vulnerability, with the potential of getting an attacker more videos than they can investigate, the researchers decided to take it one step further by using a computer vision technology that is capable of video analysis. We could have used Google Vision, Azure Computer Vision, or any other service, but we decided to go with the excellent Amazon Rekognition service. Rekognition can be used to automate the analysis of these recordings and extract information that could be useful for malicious actors.Rekognition can scan an unlimited number of videos and detect objects, text, faces, and public figures, among other things.

To further demonstrate the impact of this vulnerability, the researchers showed how this service could be used to read sensitive information from computer screens and documents visible to the Ring cameras and to track people’s movements in and out of a room.

Timeline

• 1-May-2022     Full findings reported to the Amazon Vulnerability Research Program
• 1-May-2022     Amazon confirmed receiving the report
• 27-May-2022   Amazon released a fix to customers in version .51 (3.51.0 Android , 5.51.0 iOS).

Amazon’s Response

Amazon considered this a high-severity issue and released a fix for it soon after it was reported:

“We issued a fix for supported Android customers on May 27, 2022, soon after the researchers’ submission was processed. Based on our review, no customer information was exposed. This issue would be extremely difficult for anyone to exploit, because it requires an unlikely and complex set of circumstances to execute.”

Epilogue

It was a pleasure to collaborate so effectively with the Amazon team, who took ownership and were professional through the disclosure and remediation process. For this reason, and a great researcher experience, we’re granting Amazon’s Security Team the Checkmarx Seal of Approval. 

And, as always, our security research team will continue to focus on ways to improve application security practices everywhere. 

The Amazon access token is used to authenticate the user across multiple Amazon APIs, some of which contain personal data such as full name, email, and address. Others, like the Amazon Drive API, allow an attacker full access to the user’s files.

Below is a proof of concept video demonstrating how the vulnerability could have been exploited:

The proof of concept video can also be viewed on the Checkmarx YouTube Channel.

This results from a misconfiguration of the com.amazon.gallery.thor.app.activity.ThorViewActivity component, which is implicitly exported in the app’s manifest file, thus allowing external applications to access it.

Whenever this activity is launched, it triggers an HTTP request that carries a header with the customer’s access token. Crucially, the researchers found that they could control the server receiving this request.

Below, you can see the definition of the vulnerable activity on the AndroidManifest file:

As can be seen, the activity is declared with an intent-filter used by the application to decide the destination of the request containing the access token.

Knowing this, a malicious application installed on the victim’s phone could send an intent that effectively launches the vulnerable activity and triggers the request to be sent to a server controlled by the attacker.

We used adb to replicate this intent:

As a result, the attacker-controlled server would receive the following request:

Note the x-amz-access-token header, which contains the access token.

This token could then be used to access all customer information available through the Amazon API, as shown below:

Additionally, this token could be used to list the customer’s files using the Amazon Drive API, and then to read, re-write or even delete the contents of each one:

Notably, we found that anyone with this access token was able to modify the files while erasing their history so that the original content couldn’t be recovered from file history. Another API endpoint could have allowed the deletion of files and folders in the Amazon Drive.

With all these options available for an attacker, a ransomware scenario was easy to come up with as a likely attack vector. A malicious actor would simply need to read, encrypt, and re-write the customer’s files while erasing their history.

Additionally, the APIs highlighted in this article are only a small subset of the entire Amazon ecosystem, so it’s possible that other Amazon APIs would also be accessible to an attacker with that same token.

Upon discovering this set of vulnerabilities, our first action was to contact the Amazon Photos development team. Due to the high potential impact of the vulnerability and the high likelihood of success in real attack scenarios, Amazon considered this a high severity issue and released a fix for it soon after it was reported.

• Nov 7, 2021    Full findings reported to the Amazon Vulnerability Research Program
• Nov 8, 2021    Amazon confirmed receiving of report
• Dec 18, 2021  Amazon declared issues are resolved and fix deployed into production

It was a pleasure to collaborate so effectively with the Amazon team, who took ownership and were professional through the disclosure and remediation process. For this reason, and for great collaboration, we’re granting Amazon’s Security Team the Checkmarx Seal of Approval.

And, as always, our security research team will continue to focus on ways to improve application security practices everywhere.

After investigating Zenly, the Checkmarx Security Research Team discovered a User Data Exposure vulnerability and an Account Takeover vulnerability that could have potentially put Zenly users at risk. The details of our discoveries are below. A Zenly representative told us, “We care deeply for our users, so we are grateful to the Checkmarx team who helped us fix issues before they could have any negative impact on the Zenly user experience.”

Vulnerability #1: Friend Request Flow Exposes User Data (rpc.znly.co)

(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) (5.3 Medium)

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Issue Description

When submitting a friend request to a user, Zenly will allow access to their phone number regardless of whether the friend request is accepted or not. To obtain this information, a malicious actor only needs to know their username. While obtaining a username could be a difficult task by itself, it is made easier by the fact Zenly also exposes an exhaustive list of friends of a user. This means that, for obtaining the phone number of a user, a malicious actor does not need to know their username at the start, but is able to follow a chain of friends until one of them has the victim in their friends list.

Why This Is an Issue

Exposure of user data can be used by attackers with malicious purposes. Obtaining this data can put at risk not only the users of the application, but also Zenly’s brand image.

Consider a scenario where a malicious actor wants to attack a company by targeting its CEO. An attacker can make use of this vulnerability and employ the following attack vector:

1. Search the web for an employee of the company and try to obtain their social media handle (for example, on Twitter).
   • Employees who work on communications or marketing fields are typically more exposed and represent easier targets.
2. Check if their handle is valid on Zenly.
3. Access their list of friends through Zenly, obtain the handle of the CEO.
4. Retrieve the phone number of the CEO through their username.
5. Carry out a spear phishing attack, using the phone number of the CEO.

An attacker can also repeat these steps to obtain the phone number of other employees and thus prepare a more credible attack.

Note that, according to documentation provided by Zenly, present at this link, it should not be possible to retrieve the phone number of a user unless we are already friends with them.

The following screenshot was obtained from this documentation (March 10, 2021).

Proof of Concept

To reproduce this issue, an environment that enables intercepting and decoding network requests is required. Once this environment is set up, we are able to gain visibility over network activity.

The vulnerability makes use of the “Add by Username” flow, which starts by searching a known username.

The interceptor that was previously set up can be used to view the requests that occurred during this search. Note that the “Add as Friend” button was never pressed, meaning a friend request was never sent.

By observing the response of the request that was executed on the /UserPublicFriends endpoint, a list of friends can be seen, although it is not displayed on the UI of the application. This list contains every friend of the user, one of them is Bogus_CEO (bogus CEO of Zenly, for demonstration purposes). Note that the response also contains their username, which could in turn be used to repeat this process and obtain their friends list instead.

Once we obtain the username of the target user, we can obtain their phone number through a flow that is almost identical. On the “Add by Username” view, we search for their username and complete the flow by tapping the “Add as Friend” button.

This friend invitation will trigger a request to the /FriendRequestCreate endpoint, whose response contains specific information regarding both our user (items 3, 5 and 6) and the target user (items 4, 7 and 8).

Note that the response contains both our phone number and the phone number of the target user, even though our friend request was never accepted by the target user.

Mitigation

The mitigation suggestion for this vulnerability can be split into two different steps.

The most severe impact comes from gaining access to Personally Identifiable Information (PII) of a user without authorization from their part. This could be mitigated by removing the target phone number field from the response that is returned when a friend request is created.

However, exploiting this vulnerability would be significantly more difficult if a malicious actor had to guess the username of their victims. With this in mind, the second step of this mitigation suggestion would be to effectively limit or shape the data that is returned by the /UserPublicFriends endpoint when a username search is made, instead of returning an exhaustive list containing the friends’ usernames.

If this data is being used as part of a requirement (for example, to show friends in common or to show a top of close friends), then consider only returning data of users which are relevant for these cases and, if possible, only their identifiers, instead of usernames.

Vulnerability #2: Account Takeover via SMS Authentication Flow (rpc.znly.co)

(CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N) (4.7 Medium)

CWE-287: Improper Authentication

Issue Description

During the authentication flow, an SMS is sent to the user in order to validate the session and proceed to the user account. The way Zenly API handles this flow is by:

1. Calling the /SessionCreate endpoint with the mobile phone number of the user.
   • A session for the user is created and a session token is returned, but no operations with this session are possible until the verification is complete.
   • An SMS message is sent to the user, containing a verification code.
2. Calling the /SessionVerify endpoint with both the session token and the verification code received by SMS.
   • Once this request is successfully completed, the session token becomes valid, and the user is now logged in.

After the first call to /SessionCreate, subsequent calls will return the same session token, until a call to /SessionVerify is made with a valid verification code.

Why This Is an Issue

An attacker can take over a user account by abusing the /SessionCreate endpoint, which will consistently return the same session token (although not yet valid) for the same user. Once the legitimate user validates the SMS code for that session token, the session will become valid for both the legitimate user and the attacker.

The main point of this issue is that the attacker needs to obtain a session token before the legitimate user calls the /SessionVerify endpoint. This can be done either before or after the legitimate user calls the /SessionCreate endpoint.

Allowing both the legitimate user and an attacker to have the same session token will give an advantage to the attacker. The verification code sent through SMS will remain valid for the same amount of time that the session token is valid, and it will not be regenerated within that time period, meaning that if the legitimate user inputs this code in the application (triggering a call to /SessionVerify), the session token that both the legitimate user and the attacker hold will become valid. This means that the attacker now has a valid session for the account of the legitimate user, even though the attacker never knew the verification code.

On the other hand, even if the attacker wasn’t able to obtain the session token (through a call to /SessionCreate) before the legitimate user, this attack is still possible while the legitimate user doesn’t input the correct verification code in the application, although this scenario would be less likely since the time window for carrying out this attack can be rather short.

Once the attacker has a valid session for the account of the legitimate user, they can access their location, notifications, conversations, and friends’ information just like the legitimate user could. While its impact is severe, carrying out this attack can be non-trivial since an attacker would need to:

1. Know the mobile phone number of the victim.
   • This can be achieved using the “Friend Request Flow Exposes User Data” issue.
2. Have knowledge of when the victim will login, sign up, register a new device, or go through the authentication flow for any other reason.

Proof of Concept

To reproduce this issue, an environment that enables intercepting and decoding network requests is required. For this purpose, we used the same approach followed for the “Friend Request Flow Exposes User Data” issue. Once this environment is set up, we are able to gain visibility over network activity.

By following a typical login flow, we can gain knowledge of the network requests that are involved. The flow starts by requesting the mobile phone number from the user. Once the user inputs their phone number, they will be prompted for a verification code that is sent through SMS.

At this moment, before entering the verification code, a request to /SessionCreate is launched. Note that this request (on the left) contains the mobile phone number of the user, and the response (on the right) to this request contains a session token, as shown below.

At this moment, if an attacker also sends a request to /SessionCreate with the mobile phone number of the legitimate user, they will obtain the same session token. The response to this request, initiated by the attacker, is shown below:

Note: In this example, the attacker called /SessionCreate after the legitimate user. However, the attacker could also have called /SessionCreate before the legitimate user. This would have caused Zenly (on the side of the legitimate user) to obtain the same session token that the attacker obtained.

At this moment, the legitimate user will receive an SMS message containing a verification code. The authentication flow is finished (meaning the session token will become valid) once the user inputs this code in their Zenly application. However, once the user does this, the attacker will also end up with a valid session token in their hands (since it is the same token).

The attacker can then use this token to impersonate the legitimate user, executing any request to the Zenly API with it. The attacker can also, at any time, check if the session token is valid by launching a request to /Me, an endpoint that returns information about the current session. If the  verification code has not yet been entered by the legitimate user, requests to /Me will return a 401 Unauthorized response. Once the code is entered, requests to /Me will return session information (such as phone number and user identifier), as shown below.

Once the attacker knows the session is valid, they can launch requests to /Notifications, /UserPlaces or /ChatMessagesLazy instead, thus gaining access to notifications, geolocation and conversations of the legitimate user and their friends. 

Mitigation

In order to mitigate this issue, the following steps could be taken:

• Session tokens should be unique for each call to /SessionCreate.
• A new SMS code should be sent on every call to /SessionCreate.
• Previous SMS codes should be invalidated once a new one is sent.
• Apply rate limiting to both /SessionCreate and /SessionVerify endpoints.

Note that if the first suggestion is applied, then not implementing the fourth suggestion could lead to a new account takeover issue. This is explained by the fact that constantly providing new session tokens for the same mobile phone number to an attacker (on the response to /SessionCreate) could also allow them to keep sending requests to /SessionVerify with new session tokens and random verification codes until a correct attempt is made.

Given that a user currently receives two verification codes per call to /SessionCreate, and each code consists of four digits, an attacker would have a probability of approximately 0.02% of placing a correct attempt when picking a code at random (2 in 10000). The probability of achieving success after a given number of attempts can be calculated using the formula below.

By plotting this function, one can expect to achieve a 50% probability of success after approximately 3470 attempts. Meaning if no rate limiting is in place and an attacker can launch an attempt per second, this probability of success would be achieved in under an hour.

Please note that even though some kind of rate limiting should be in place, these suggestions should be applied with moderation, keeping in mind that these should not allow an attacker to prevent a legitimate user from accessing their own account.

Summary of Disclosure and Events

The Checkmarx Security Research Team responsibly notified Zenly, providing detailed information of our research findings, instructions to reproduce the issues, and recommendations. Zenly has now fixed the issues we discovered.

Timeline

• 27-Jun-2021 – Full vulnerabilities report shared with Zenly through their bug bounty program
• 29-Jun-2021 – Zenly acknowledged receipt and asked for more details
• 02-Jul-2021 – Full detailed shared with Zenly
• 13-Jul-2021 – Zenly released a fix for the “Account Takeover via SMS Authentication Flow” issue
• 15-Jul-2021 – Checkmarx approved the fix
• 20-Sep-2021 – Zenly released a fix for the “Friend Request Flow Exposes User Data” issue
• 25-Sep-2021 – Checkmarx approved the fix

Final Words

It was a pleasure working with Zenly’s security team. Their professionalism and cooperation, as well as the prompt ownership they took, are what we hope for when we engage with software companies. Kudos!

This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among organizations who offer online services in an effort to improve security for everyone overall.

In previous years, similar tactics were often observed as attackers would use encodings to make filenames and types look harmless, for example, masquerading an executable file as a pdf. The recent research describes possible attacks that take a similar path, putting it into practice in source code to deceive human reviewers

This new vulnerability leverages the bidirectional algorithm in Unicode encoding that normally is used to help display left-to-right and right-to-left languages together in the same documents and files (e.g., Hebrew and English). Using this feature, attackers are able to change the order of words and characters in a way that will look harmless to a human reviewer, but can result in different, and even malicious functionality at runtime.

Cambridge researchers describe three techniques that leverage this vulnerability:

• Early Returns: cause a “return” statement that appears to be in a comment to execute and by that, make a function exit and potentially exclude wanted functionality.
• Commenting-Out: causing a similar outcome as the “Early Returns” technique of preventing code from being executed; doing so by commenting out code snippets that will be ignored at runtime, but look normal for a human reviewer.
• Stretched Strings: can be used to alter string comparison operations by causing portions of string literals to visually appear as code.

The authors of the article also mention an adjacent technique that is tracked as a vulnerability as well. The exploit of this vulnerability will include the use of the known homoglyphs characters as a part of functions’ names. This can mislead a reviewer to think a specific function is called, while in fact, another one is with potentially malicious functionality.

Checkmarx SAST to the Rescue

As previously mentioned, this vulnerability has been around for years, but with the recent increase in popularity, we wanted to make sure our customers are covered. “If our customers are in need of an answer to the growing fear of the Trojan Source vulnerability, we can easily assist them,” says Ori Bendet, Head of Product Management at Checkmarx. “Using our easily extensible query language, CxQL, we added a set of dedicated queries to look for those specific characters in the application source code. It will be added to the relevant presets and every customer can be sure that they are covered for any Trojan Source behavior in their application source code. It was really a no-brainer once we had several discussions around this matter with our customers. It also shows how robust and flexible our SAST solution is and how quickly we can add new scanning capabilities,” summarized Ori.

In addition to our SAST’s full coverage of this issue, Checkmarx supply chain dynamic protection can also detect malicious behavior hidden by these techniques in external open-source packages.

Our customers can be confident that they are covered for similar vulnerabilities like Trojan Source.

Make Sure You’re Updated

For organizations who already have Checkmarx SAST, ensure you are running version 9.2 or above to get the latest coverage for the Trojan Source vulnerability. You can learn more and download the latest version [here].

For organization who are not customers yet, but want to learn more about Checkmarx Application Security solutions, feel free to request a demo [here].

• Access data that you are otherwise not authorized to access normally as a learner (…)
• Affects another learner outside of normal interactions on the platform (…)
• Accessing Coursera’s internal administrative control systems.”

Through our research, we discovered multiple API issues, such as user/account enumeration via the reset password feature, lack of resources limiting on both a GraphQL and REST API, and a GraphQL misconfiguration. But specifically, the Broken Object Level Authorization (BOLA) issue we found perfectly fits Coursera’s access control concerns.

Impact Summary

The BOLA API vulnerability our team discovered affected the users’ preferences. Even anonymous users were not only able to retrieve their preferences, but also change them. Some of these preferences, such as recently viewed courses and certifications, also leaked some metadata (e.g. activity date/time).
This vulnerability could have been abused to understand general users’ courses preferences at a large scale, but also to somehow bias users’ choices, since manipulating their recent activity affected the content rendered on Coursera’s homepage for a specific user.

What We Found

While interacting with Coursera’s web application as regular users (learners), we noticed that recently viewed courses were displayed in the user interface. To render this information, we spotted several GET API requests to the same endpoint: /api/userPreferences.v1/{USER_ID}~{PREFERENCE_TYPE}.
The {USER_ID} was almost obvious and of course we started playing with it to test API1:2019 Broken Object Level Authorization. After several successful requests to retrieve preferences of several user accounts controlled by us, we were able to enumerate ten different preference types ({PREFERENCE_TYPE}): ONBOARDING, INVITATION, PAYMENT, saveCreditCard, HONORS, S12N_UPGRADE, ADMIN_SELECTED_PARTNER, PROMOTION_LANDING_PAGE, GENERIC, RECENTLY_VIEWED_XDP.
It was obvious that we were dealing with an authorization issue: one user was accessing another user’s data – and not only its preferences, but also some metadata such the exact date/time of its activity. As next step we started stripping the original request of cookies and headers, to come up with the conclusion that even anonymous users would have access to any user preferences (see Figure 1).

Figure 1: Anonymous request to retrieve arbitrary user recently viewed courses

But we were not done yet. Due to the predictability of REST APIs, the next natural step would be to replace the HTTP verb from GET to PUT to test whether we were also able to modify the user preferences. No special creativity was needed to craft a valid payload: we took it from one of our GET requests and replaced courses’ identifiers and timestamps. As shown in the picture below, the request payload was sent back in the HTTP response, suggesting preferences were successfully set.

Figure 2: Modifying another user’s recently viewed courses

You can watch the proof-of-concept video here.

Risk Assessment

Unauthorized users’ data access is critical by definition, becoming even more relevant when it is also possible to manipulate such data. Authorization issues directly impact data privacy, data integrity, user trust, and ultimately business reputation. The risk is increasingly high depending on what type of data unauthorized users get access to, or are able to manipulate (e.g., financial/payments).

Recommendations

Authorization issues are, unfortunately, quite common with APIs. It is very important to centralize access control validations in a single, well and continuously tested and actively maintained component. New API endpoints, or changes to the existing ones, should be carefully reviewed regarding their security requirements.

Summary of Disclosure and Events

The Checkmarx Security Research Team responsibly notified Coursera, providing a detailed security advisory with research findings, instructions to reproduce the issues, and recommendations, which Coursera followed to address and mitigate the security issues.
Timeline

• October 5, 2020 – Checkmarx sent full report to Coursera’s security team
• October 26, 2020 – Coursera acknowledged receiving the report and working on it
• December 18, 2020 – Coursera wrote they resolved all issues
• January 2, 2021 – Checkmarx sent a re-test report with one new issue
• May 24, 2021 – Coursera confirmed all issues are fixed
• July 8, 2021 – Public disclosure

Final Words

It was a pleasure working with the Coursera security team. Their professionalism and cooperation, as well as the prompt ownership they took, are what we hope for when we engage with software companies. Kudos!
Generally speaking, API access control issues are one of the biggest security problems facing APIs. As vulnerable APIs increasingly fall into adversaries’ sights, it’s critical that developers receive proper education on best practices for embedding security into their design from the get-go – which CxCodebashing can help with.
This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among organizations who offer online services in an effort to improve security for everyone overall.

What is the Issue?

The Checkmarx Security Research Team identified a document object model-based cross-site scripting (DOM XSS for short) vulnerability in Drupal Core. This type of XSS attack is achievable if a web application enters data to the DOM without being appropriately sanitized. In this case, an attacker can manipulate their input data to include XSS content on the web page, for example, malicious JavaScript code, which in-turn would be consumed by Drupal Core itself.

What is the Risk?

An attacker abusing this vulnerability can take over the administrator role of a Drupal-based website and get full control that allows changing of content, creating malicious links, stealing sensitive or financial data, or whatever else comes to mind.

Drupal Assigns CVE-2020-13663

Drupal labeled the Security Risk of this vulnerability our team discovered as follows:

• Risk: Critical
• Access Complexity: Complex
• Authentication: All/Anonymous Users
• Confidentiality Impact: Certain Non-Public Data is Released
• Integrity Impact: Some Data Can be Modified
• Exploit (Zero-day Impact): Theoretical or White-hat (no public exploit code or documentation on development exists)
• Target Distribution: All Module Configurations are Exploitable

Summary of Disclosure and Events

When the vulnerability was first discovered, the Checkmarx Security Research Team responsibly notified Drupal of its findings. Our team was asked to advise Drupal’s team after our disclosure, which we willingly did.
After we disclosed the vulnerability, the Drupal team’s sense of urgency and professionalism was quite notable, and a fix was made available within a week of our disclosure.
In accordance with Drupal’s disclosure guidelines and to give its users adequate time to update their software, Checkmarx will refrain from publishing a more technical report showing an in-depth walkthrough and proof-of-concept of exploiting this vulnerability for 60 days. In the meantime, we strongly encourage Drupal users to take action on recommended updates.

Recommendation

At this time, Checkmarx highly recommends that anyone using Drupal update the version in use immediately to the latest release, which contains a fix for this vulnerability.
Checkmarx customers using Checkmarx Software Composition Analysis (CxSCA) have already been automatically notified to update Drupal while running a scan of their code base.

Final Words

This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among all organizations in an effort to improve security for everyone. Checkmarx is committed to analyzing the most prominent open source packages to help development teams ship more secure software and improve their software security risk posture. Our database of open source libraries and vulnerabilities is cultivated by the Checkmarx Security Research Team, empowering CxSCA with risk details, remediation guidance, and exclusive vulnerabilities that go beyond the NVD.
For more information or to speak to an expert about how to detect, prioritize, and remediate open source risks in your code, contact us.

• In 2018, Denial-of-Service by External Contract, and Reentrancy, were the top 2 issues. However, the issues were are now remedied. You can learn more about Reentrancy in our recent research blog: Checkmarx Research: Solidity and Smart Contracts from a Security Standpoint. When Solidity v0.6.x was released that introduced a lot of breaking changes, 50% of scanned Smart Contracts were not even ready for Solidity compiler v0.5.0. This becomes even more relevant since 30% of the Smart Contracts use deprecated constructions (e.g., sha3, throw constant, etc.), and 83% had issues with the compiler version specification (pragma).
• Although visibility issues didn’t make it in the 2018 Top 10 list, nor in this updated version, they have increased by 48%. You can read more about this issue in our previous blog and the official documentation.

The table below compares the changes between the 2018 and 2020 Top 10 Common Issues lists. The issues were sorted by severity and prevalence.

Solidity Top 10 Common Issues

S1 – Unchecked External Call

This was the third most-common issue on our previous Top 10 list. Since the top 2 issues are now resolved, Unchecked External Call has moved up to the most common issue in the 2020 updated list.
Solidity low-level call methods (e.g., address.call()) do not throw an exception. Instead, they return false if the call encounters an exception. On the other hand, contract calls (e.g., ExternalContract.doSomething()) automatically propagate a throw if doSomething() throws.
Transferring Ether using addr.send()is a good example where unsuccessful transfers should be handled explicitly by checking the return value, but this is also valid for other external calls.

S2 – Costly Loops

Costly loops moved from forth on the Top 10 list to second. Despite the fact that the top 2 issues from our previous list are resolved, the number of affected Smart Contracts increased by almost 30%.
Computational power on Ethereum environments is paid (using Ether). Thus, reducing the computational steps required to complete an operation is not only a matter of optimization, but also cost efficiency.
Loops are a great example of costly operations: as many elements an array has, more iterations will be required to complete the loop. As you may expect, infinite loops exhaust all available gas.

If an attacker is able to influence the elements array length, then they will be able to cause a denial of service, preventing the execution to jump out of the loop. Although it was far from the Top 10 common issues, array length manipulation was found in 8% of the scanned Smart Contracts.

S3 – Overpowered Owner

This is a new entry in the Top 10 list, affecting approximately 16% of the scanned Smart Contracts.
Some contracts are tightly coupled to their owner, making some functions callable only by the owners address, as in the example below.

Both doSomething() and doSomethingElse() functions can only be called by the contract owner: the former uses the onlyOwner modifier, while the later enforces it explicitly. This poses a serious risk: if the private key of the owner gets compromised, then an attacker can gain control over the contract.

S4 – Arithmetic Precision

Solidity data types are cumbersome due to the 256 bits Virtual Machine (EVM). The language does not offer a floating point representation, and data types shorter than 32 bytes are packed together into the same 32 bytes slot. With this in mind, you should expect precision issues.

When division is performed before the multiplication, as in the example above, you should expect huge rounding errors.

S5 – Relying on tx.origin

Contracts should not rely on tx.origin for authentication, since a malicious contract may play in the middle, draining all the funds: msg.sender should be used instead.

You’ll find a detailed explanation of Tx Origin Attacks on Solidity’s documentation. Long story short, tx.origin is always the first account in the call chain, while msg.sender is the immediate caller. If the last contract in the chain relies on tx.origin for authentication, then the contract in the middle will be able to drain the funds, since no validation is performed on who’s calling (msg.sender).

S6 – Overflow / Underflow

Solidity’s 256 bits Virtual Machine (EVM) brought back overflow and underflow issues as demonstrated here. Developers should be extra careful when using uint data types in for-loop condition, since it may result in infinite loops.

In the example above, the next value for i when its value is 0 will be 2²⁵⁶-1, that makes the condition always true. Developers should prefer <, >, != and == for comparison.

S7 – Unsafe Type Inference

This issue moved up two positions, now affecting more than 17% of Smart Contracts then before.
Solidity supports Type Inference, but there are some quirks with it. For example, the literal 0 type-infers to byte, not int as we might expect.
In the example below, the type of i is inferred to uint8: the smallest integer type sufficient to store the right-hand side value. If elements has more than 256 elements, we should expect an overflow.

Explicitly declaring data types is recommended to avoid unexpected behaviors and/or errors.

S8 – Improper Transfer

This issue dropped from sixth to eighth in the Top 10 list, affecting now less than 1% of the scanned Smart Contracts.
There is more than one way to transfer Ether between contracts. Although calling the addr.transfer(x) function is the recommended way, we still found contracts using send() function instead.

Note that addr.transfer(x) automatically throws an exception if the transfer is unsuccessful, mitigating the Unchecked External Call issues previously discussed: S1.

S9 – In-Loop Transfers

When Ether is transferred in a loop, if one of the contracts cannot receive it, then the whole transaction will be reverted.

An attacker may take advantage of this behavior to cause a denial-of-service, preventing other contracts to receive Ether.

S10 – Timestamp dependence

This was fifth in the previous version of the Top 10 list.
It’s important to remember that Smart Contracts run on multiple nodes on a different time. The Ethereum Virtual Machine (EVM) does not provide clock time and the now variable, commonly used to obtain a timestamp, is in fact an environment variable (an alias of block.timestamp) which miners can manipulate.

Since miners can manipulate environment variables currently, its value should only be used in inequalities >, <, >=, and <=.
When looking for randomness, consider the RANDAO contract, which is based on a Decentralized Autonomous Organization (DAO) that anyone can participate in, being the random number generated by all participants together.

Conclusion

When comparing the 2018 and 2020 Top 10 Common Issues lists, we can observe some progress concerning development best practices, especially those impacting security. Seeing the 2018 top 2 issues, Denial-of-Service by External Contract, and Reentrancy, moving away from the top 10 is a positive sign, but there’s still important steps to take to avoid common mistakes.
Remember that Smart Contracts are immutable by design, meaning that once created, there’s no way to patch the source code. This poses a great challenge concerning security and developers should take advantage of the available application security testing tools to ensure source code is well-tested and audited before deployment.
Solidity is a very recent programming language that is still maturing. Solidity v0.6.0 introduced a few breaking changes and more are expected in the upcoming versions.
Discovering issues and risks like the ones mentioned herein is why the Checkmarx Security Research team performs investigations. This type of research activity is part of their ongoing efforts to drive the necessary changes in software security practices among organizations worldwide.

References

• Checkmarx Research: Solidity and Smart Contracts from a Security Standpoint
• Solidity official documentation
• Solidity Security Considerations: tx.origin
• Type Inference – Wikipedia
• RANDAO: A DAO working as RNG of Ethereum
• SmartCheck: Static Analysis of Ethereum Smart Contracts
• Recommendations for Smart Contract Security in Solidity

API6:2019 – Mass Assignment:

Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. What this means is that users should have the ability to update their user name, contact details, etc. (within their profiles for example), but they should not be able to change their user-level permissions, adjust account balances, and other administrative-like functions. An API endpoint is considered vulnerable if it automatically converts the client input into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update things that they should not have access to.

Example Attack Scenario:

To illustrate this further, imagine that a ride sharing application provides the user the option to edit basic information about themselves in their user profile. For example, they can adjust their user name, age, etc. In this case, the API request would look like this: PUT /api/v1/users/me with the following legitimate information {“user_name”:”john”,”age”:24}
However, the attacker determines that the request GET /api/v1/users/me includes an additional credit_balance property (field) as shown below.
{“user_name”:”john”,”age”:24,”credit_balance”:10}.
The attacker desires to increase their credit balance on their own and replays the first request with the following payload:
{“user_name”:”john”,”age”:24,”credit_balance”:99999}
Since the endpoint is vulnerable to mass assignment, the attacker can easily adjust their own credit_balance at will, for example changing it from 10 credits to 99999 as shown above.

API7:2019 – Security Misconfiguration:

Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system they want to attack. Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise.

Example Attack Scenario:

Say for instance that an attacker uses a popular search engine like Shodan to search for computers and devices directly accessible from the Internet. The attacker found a server running a popular database management system, listening on the default TCP port. The database management system was using the default configuration, which has authentication disabled by default, and the attacker gained access to millions of records with PII, personal preferences, and authentication data.

API8:2019 – Injection:

Injection vulnerabilities cause computing systems to potentially process malicious data that attackers introduce. To put it in its simplest terms, attackers inject code into a vulnerable piece of software and change the way the software is intended to be executed. As a result, injection attacks can be somewhat disastrous, since they normally lead to data theft, data loss, data corruption, denial of service, etc.

Example Attack Scenario:

Suppose an attacker starts inspecting the network traffic of their web browser and identifies the following API request designed to help a user recover their password. The attacker identifies the request responsible to start the recovery-password process as follows:
POST /api/accounts/recovery {“username“: “john@somehost.com”}
Then the attacker replays the request with a different payload:
POST /api/account/recovery {“email”: “john@somehost.com’;WAITFOR DELAY ‘0:0:5’–“}
By adding the ;WAITFOR DELAY ‘0:0:5’–” the attacker observes that the response from the API took ~5 seconds longer, which helps confirm the API is vulnerable to SQL injection. Exploiting the injection vulnerability, the attacker was able to gain unauthorized access to the system.

API9:2019 – Improper Assets Management:

Old API versions are often unpatched and can become an easy way to compromise systems without having to fight state-of-the-art security systems, which might be in place to protect the most recent API versions. Attackers may gain access to sensitive data, or even takeover the server through old, unpatched API versions connected to the same database.

Example Attack Scenario:

Say for instance that an organization redesigning their applications forgot about an old API version (api.someservice.com/v1) and left it unprotected, and with access to the user database. While targeting one of the latest released applications, an attacker found the API address (api.someservice.com/v2). Replacing v2 with v1 in the URL gave the attacker access to the old, unprotected API, exposing the personal identifiable information (PII) of millions of users.

API10:2019 – Insufficient Logging and Monitoring:

Without logging and monitoring, or with insufficient logging and monitoring, it is almost impossible to track suspicious activities targeting APIs and respond to them in a timely fashion. Without visibility over ongoing malicious activities, attackers have plenty of time to potentially compromise systems and steal data.

Example Attack Scenario

Imagine that a video-sharing platform was hit by a “large-scale” credential stuffing attack. Despite failed logins being logged, no alerts were triggered during the timespan of the attack, and it proceeded without being noticed. As a reaction to user complaints about a possible breach, API logs were analyzed and the attack was detected, way after the fact. The company had to make a public announcement asking users to reset their passwords, and report the incident to their regulatory authorities.
Pertaining to the five (5) risks above, one could easily imagine similar attack scenarios. Those provided were just examples of the nearly unlimited possibilities when attacking vulnerable API implementations. Hopefully, you can see the risks above are primarily caused by errors or oversights that could be easily remedied, especially when it comes to the way organizations utilize APIs today.

Google & Samsung Camera Vulnerabilities

After a detailed analysis of the Google Camera app, our team found that by manipulating specific actions and intents [2], an attacker can control the app to take photos and/or record videos through a rogue application that has no permissions to do so. Additionally, we found that certain attack scenarios enable malicious actors to circumvent various storage permission policies, giving them access to stored videos and photos, as well as GPS metadata embedded in photos, to locate the user by taking a photo or video and parsing the proper EXIF data [3]. This same technique also applied to Samsung’s Camera app.
In doing so, our researchers determined a way to enable a rogue application to force the camera apps to take photos and record video, even if the phone is locked or the screen is turned off. Our researchers could do the same even when a user was is in the middle of a voice call.

The Implications

The ability for an application to retrieve input from the camera, microphone, and GPS location is considered highly invasive by Google themselves. As a result, AOSP created a specific set of permissions that an application must request from the user. Since this was the case, Checkmarx researchers designed an attack scenario that circumvents this permission policy by abusing the Google Camera app itself, forcing it to do the work on behalf of the attacker.
It is known that Android camera applications usually store their photos and videos on the SD card. Since photos and videos are sensitive user information, in order for an application to access them, it needs special permissions: storage permissions. Unfortunately, storage permissions are very broad and these permissions give access to the entire SD card. There are a large number of applications, with legitimate use-cases, that request access to this storage, yet have no special interest in photos or videos. In fact, it’s one of the most common requested permissions observed.
This means that a rogue application can take photos and/or videos without specific camera permissions, and it only needs storage permissions to take things a step further and fetch photos and videos after being taken. Additionally, if the location is enabled in the camera app, the rogue application also has a way to access the current GPS position of the phone and user.
Of course, a video also contains sound. It was interesting to prove that a video could be initiated during a voice call. We could easily record the receiver’s voice during the call and we could record the caller’s voice as well.

A PoC of a Worst-Case Scenario

To properly demonstrate how dangerous this could be for Android users, our research team designed and implemented a proof-of-concept app that doesn’t require any special permission beyond the basic storage permission. Simulating an advanced attacker, the PoC had two working parts: the client-part that represents a malicious app running on an Android device, and a server-part that represents an attacker’s command-and-control (C&C) server.
The malicious app we designed for the demonstration was nothing more than a mockup weather app that could have been malicious by design. When the client starts the app, it essentially creates a persistent connection back to the C&C server and waits for commands and instructions from the attacker, who is operating the C&C server’s console from anywhere in the world. Even closing the app does not terminate the persistent connection.
The operator of the C&C console can see which devices are connected to it, and perform the following actions (among others):

• Take a photo on the victim’s phone and upload (retrieve) it to the C&C server
• Record a video on the victim’s phone and upload (retrieve) it to the C&C server
• Parse all of the latest photos for GPS tags and locate the phone on a global map
• Operate in stealth mode whereby the phone is silenced while taking photos and recording videos
• Wait for a voice call and automatically record:
  • Video from the victim’s side
  • Audio from both sides of the conversation

Note: The wait for a voice call was implemented via the phone’s proximity sensor that can sense when the phone is held to the victim’s ear. A video of successfully exploiting the vulnerabilities was taken by our research team and can be viewed here. Our team tested both versions of Pixel (2 XL / 3) in our research labs and confirmed that the vulnerabilities are relevant to all Google phone models.

Android Vulnerability: Watch the Explainer Video

Summary of Disclosure and Events

When the vulnerabilities were first discovered, our research team ensured that they could reproduce the process of easily exploiting them. Once that was confirmed, the Checkmarx research team responsibly notified Google of their findings.
Working directly with Google, they notified our research team and confirmed our suspicion that the vulnerabilities were not specific to the Pixel product line. Google informed our research team that the impact was much greater and extended into the broader Android ecosystem, with additional vendors such as Samsung acknowledging that these flaws also impact their Camera apps, and began taking mitigating steps.

Google’s Response

“We appreciate Checkmarx bringing this to our attention and working with Google and Android partners to coordinate disclosure. The issue was addressed on impacted Google devices via a Play Store update to the Google Camera Application in July 2019. A patch has also been made available to all partners.”

Mitigation Recommendation

For proper mitigation and as a general best practice, ensure you update all applications on your device.

Timeline of Disclosure

• Jul 4, 2019 – Submitted a vulnerability report to Android’s Security team at Google
• Jul 4, 2019 – Google confirmed receiving the report
• Jul 4, 2019 – A PoC “malicious app” was sent to Google
• Jul 5, 2019 – A PoC video of an attack scenario was sent to Google
• Jul 13, 2019 – Google set the severity of the finding as “Moderate”
• Jul 18, 2019 – Sent further feedback to Google
• Jul 23, 2019 – Google raised the severity of the finding to “High”
• Aug 1, 2019 – Google confirms our suspicion that the vulnerabilities may affect other Android smartphone vendors and issues CVE-2019-2234
• Aug 18, 2019 – Multiple vendors were contacted regarding the vulnerabilities
• Aug 29, 2019 – Samsung confirmed they are affected
• Nov 2019 – Both Google and Samsung approved the publication

Note: This publication was coordinated with Google and Samsung after their confirmation of a fix being released. Please refer to Google for information regarding the fixed version of the Android OS and Google Camera app.

Final Words

The professionalism shown by both Google and Samsung does not go unnoticed. Both were a pleasure to work with due to their responsiveness, thoroughness, and timeliness.
This type of research activity is part of our ongoing efforts to drive the necessary changes in software security practices among vendors that manufacture consumer-based smartphones and IoT devices, while bringing more security awareness amid the consumers who purchase and use them. Protecting privacy of consumers must be a priority for all of us in today’s increasingly connected world.
References

[1] https://en.wikipedia.org/wiki/Google_Camera
[2] https://developer.android.com/guide/components/intents-filters
[3] https://en.wikipedia.org/wiki/Exif