API Security Weekly: Issue #140

API vulnerability at LazyPay, API attacks on WD My Book Live NAS systems, LinkedIn profiles getting scraped, and a new detailed IDOR/BOLA pentesting mindmap.

This week, we take a look at the recent API vulnerabilities reported at LazyPay, API attacks on Western Digital My Book Live NAS systems, and LinkedIn profiles getting scraped. We also have a new detailed mind map for broken object-level authorization (BOLA/IDOR) vulnerabilities.

Vulnerability: LazyPay

LazyPay is a pay-later platform that has over 2 million active users in India.

Security researcher Ehraz Ahmed found that the API behind LazyPay’s mobile app was vulnerable. The story behind the link claims that this was an API for 3rd-party developers, but in a private chat with APIsecurity.io, Ahmed said that the journalist got it wrong and the API was in fact directly powering the mobile app.

LazyPay had an endpoint that had no authentication. Attackers could call the endpoint and supply a phone number to obtain sensitive personal information on the user in question, such as profile picture, name, gender, date of birth, postal address, primary and secondary email addresses, secondary mobile number, know your customer (KYC) status (verified or not), and account creation date.

Keep in mind that there is a limited number of phone numbers in India. Thus, attackers could write a script to easily iterate through all possible phone numbers and retrieve the data for all users.

Once Ahmed alerted PayU — the parent company behind LazyPay — to the vulnerability, they promptly fixed the issue. According to them, there was no evidence of it being exploited.

Lessons learned here:

• Even APIs that your own applications and their components use need authentication and authorization. Do not underestimate attackers’ determination and skill in finding and evoking any unprotected API endpoint.
• Avoid predictable identifiers, like sequential IDs or phone numbers, to make it harder to scrape your data.

Vulnerability: Western Digital My Book Live NAS

There have been multiple reports over the last week of attackers going after internet-connected Western Digital My Book Live NAS (Network-Attached Storage) systems and remotely wiping them, killing all customer data. There have also been some additional reports on the devices getting taken under a botnet control instead of wiping them clean.

The initial reports assumed that the attack was based on the vulnerability CVE-2018-18472 reported by WizCase back in 2018 that Western Digital did not fix because the affected devices are no longer officially supported.

The vulnerability boiled down to unauthenticated remote command execution through a PUT request to the endpoint /api/1.0/rest/language_configuration. This endpoint accepted XML configurations but did not properly validate the XML. External entities were allowed and attackers could use them to force the NAS to download and execute scripts from an attacker server:

Researchers at Censys looked at the later reports and logs on the exploit and found that besides the original vulnerability, at least some of the attacks used a POST request to the REST API endpoint system_factory_restore to wipe out the devices.

That endpoint didn’t require any authentication either. In fact, the researchers managed to get access to the code of the most recent (from 2015) software from the NAS and discovered that authentication check on that endpoint was intentionally commented out by developers:Java1

function post($urlPath, $queryParams=null, $ouputFormat=’xml’){

2

    //        if(!authenticateAsOwner($queryParams))

3

    //        {

4

    //            header(“HTTP/1.0 401 Unauthorized”);

5

    //            return;

6

    //        }

7

​

8

    parse_str(file_get_contents(“php://input”), $changes);

9

​

10

    ...

One can only speculate why this happened.

Since there is no patch available, Western Digital is urging all owners of the affected device to immediately disconnect it from the internet.

Lessons learned with this one:

• Authentication is the key: your APIs should be protected, no matter what. There are precious few cases where having no authentication is acceptable (login, password reset, etc.) and they need to be handled with great care to prevent abuse.
• Never trust API consumer inputs! Strictly define and enforce schemas for all API payloads.
• Test your API implementations to make sure those conform to the API contracts and do so automatically on every update! This way, if, say, your developers disable authentication to make their dev testing easier (or for some other reason), your tests catch that and prevent the insecure code from hitting production. For example, this is what 42Crunch API Conformance Scan does.

API Scraping: LinkedIn

Over the last few months, there have been several reports on scraped LinkedIn data. The latest one on this week was a set of 700 million profiles — that’s 92% of the total LinkedIn user base!

(There are different opinions in the community as to whether the data in this particular set is new or is a compilation of earlier sets such as the 500 million profiles set leaked in April.)

The sellers confirmed that they obtained the data through LinkedIn APIs. The details in the data set include:

• Full names
• Physical addresses
• Email addresses
• Phone numbers
• Geolocation records
• LinkedIn username and profile URL
• Other social media accounts and usernames
• Personal and professional experience/background
• Gender

Just like with the Facebook profile data leak that we reported in issue 129, even if the data is public, these large data sets scraped through APIs often amplify the power of the data and fuel phishing campaigns and other nefarious activities.

Thus, bulk user data scraping through APIs is a big problem and a risk that needs to be taken into account and addressed. Sadly, this seems to continue to be downplayed by many vendors arguing that it’s not a breach if legitimate APIs (as opposed to an infrastructure compromise) were used. In reality, the impact can be just as devastating.

Repeating the lessons learned that we posted previously:

• APIs are one of your primary attack surfaces. Treat them as such!
• Even public information can become dangerous once it becomes available as a large dataset. Information is power, after all: more information, more power. It should not be allowed to fall into wrong hands through negligence.
• APIs should not give access to more data than you are comfortable with (and allowed to!) sharing through user interfaces.
• Bulk operations are extremely dangerous. Always limit not just the rates at which APIs can be invoked and the amount of data that they can return.
• APIs need to be secured by design. Fixing issues only after they have been exploited can be disastrously late.
• Monitoring, alerting, and promptly reacting to vulnerability reports are good additional mitigation measures.

Pentesting: IDOR Mind Map

BOLA, also known as IDOR holds the number one spot among API vulnerabilities on the OWASP API Security Top 10 list. The vulnerability happens when APIs are allowed to access resources owned by one user when they have authenticated as another user that is not supposed to have access to the resources.

Mufaddal Masalawala has created a mind map that summarizes 19 methods that penetration testers can employ to find BOLA vulnerabilities:

Source: https://dzone.com/articles/api-security-weekly-issue-140

Department of Information Technologies: https://www.ibu.edu.ba/department-of-information-technologies/