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.
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:
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:
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:
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:
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/