There is a widespread opinion as big the company is as harder to find breaches there: all the well-known vulnerabilities are fixed and mitigated, DevOps know their job and firewalls are set properly. But is that so true and are companies configured correctly and securely enough? Today we will try to reveal the main relative aspects and find out is that a myth or a reality.
- Statistics
“There are three kinds of lies: lies, damned lies, and statistics.” © Mark Twain.
Every year well-known agencies publish their own charts about, for example, approximately amount of money which were lost by cybercrimes. As a source, generally, they point to another agency and so on till it’s come back to the first one. But let’s leave outside any already calculated charts and look at the original sources.
HackerOne, BugCrowd and Synack are vulnerability coordination and bug bounty platforms that connect businesses with penetration testers and cybersecurity researchers. U.S. Department of Defense, Yahoo, Adobe, Ford, Twitter and other middle and big companies all over the world are their customers, which offer money for the real vulnerabilities.
For instance, Yahoo has already spent more than $21,8M to pentesters,
Mail.ru – ~$2,5M,
Shopify – ~$1,9M.
Interesting. Let’s look into the logs and find out what the mistakes were.
I will start with Shopify whose developer forgot to remove GitHub Access Token in the source code. By the way, Augusto was awarded $50.000 for that finding.
Authorization bypass or even its absent is another widespread misconfiguration.
IDOR (Insecure Direct Object Reference) is not rare either.
As you may see, it does not matter how big the company is or how many professionals are working there – almost all companies are vulnerable, even by such kind of “Childhood diseases”.
- IDOR
Back in September 2021, I was served by one of the international non-profit organization headquartered in Milwaukee, Wisconsin, United States.
I registered on their website, uploaded all the necessary information and documents to the portal and started waiting for the response which I got in two weeks. I came back to the website to get the docs and, suddenly, my eyes stopped on the URL:
Seems too suspicious to be the true, I mean to be an IDOR vulnerability. By the way, that was a user portal main page with all of the personal information.
The first thing I tried to do was decreasing the last URL number by 1 – to 1205881. Can you imagine – that’s worked.
As you may see, I have got Dilyana’s personal information including her last and middle names, email, phone number and home address.
Then I tried to go deeper and decided to get, for instance, 1, 466 and 67832 ID customers information.
The next possible step could be creating Bash or Python script or using Burp Suit to harvest all the customers PII across the globe whom are more than 1.2 million persons (based on my ID – 1’205’882).
But, due to the company does not have a bug bounty program my further actions might be evaluated as black hacking so I stopped pentesting.
In 2 hours after I’d found the issue, I prepared a report marked as High severity with CWE 639: Insecure Direct Object Reference and sent it to the company’s security team.
I must admit they solved the issue within 6 hours (6 hours, Karl 🙂 since I’d sent a report which, I assume, a quite rapid. After a quick retest I stated the vulnerability was fixed.
- LFI
Having chatted a little with Anthony and got the permission for the further investigation I launched my application – Fast Google Dorks Scan (https://github.com/IvanGlinkin/Fast-Google-Dorks-Scan), to find something hided. And I’ve got it.
Interesting. Seems like we might have an LFI on the one of the subdomains. But let’s dig a little big deeper. Let’s recheck it by the google web-site:
I have got the link which redirects me to https://CENSURED.org/common/loadfile?filePath={absolut_path}. Perfect.
Now let’s try to get some internal files. I prefer to start with /etc/passwd due to its 644 permissions:
Let’s look into it:
We succeeded to download an internal file from the server and found out the CENSURED username.
Let’s go further and try to get /etc/shadow file with passwords:
Wow, that’s really weird. What does it mean? Having done that I have proved the web-server operates under the root, that’s why I have the full permission to read ANY FILE in the system including logs, source code, setup files with passwords, etc.
Further harvesting showed me sudoers rights …
and also hardcoded password in the root history.
Being an ethical hacker and proved enough the further exploitation was over.
Like the first time, I prepared a report marked as Critical severity with CWE 22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) under the root.
In the report I suggested to delete LOADFILE; due to the system was compromised, change all the passwords and check the logs if there is already an insider.
As a reward another appreciation email 🙂
Having received the email, I destroyed all the findings (except the reports) and finished the web-application vulnerability assessment.
- Conclusion
Having considered all the arguments above I may conclude there is no reason to fear big companies’ cyber security assessment for the “Childhood diseases” like IDOR, Path traversal, password hardcoded and other. As my personal experience multiplied by hackerone hacktivity shows it’s real and, sometimes, awarded well enough. You just have to start. Happy hunting … 😉