I am a huge open-source fan for a long time and since my last white paper on Drupalgeddon 2 I decided to carry out small security research on some large-scale open-source based sites and what I discovered was pretty shocking.
Open-source applications and CMS frameworks like Drupal, Laravel, and WordPress are being heavily adopted during the past few years in large-scale e-commerce sites, internal business critical systems and even by more traditional organizations like banks and healthcare companies, where security and privacy are huge concerns.
More organizations are realizing that open-source isn’t less secure, and even more secure than closed-source.
Today I will share a few interesting cases I encountered during my research.
The research consisted of two parts
- Finding a test subject — Finding open-source based large scale sites (some randomly, and some of potential clients as a gesture of goodwill)
- Check for too much information — Check for unprotected framework’s configuration files and source code disclosure, which is from my perspective the very basic of every application and server hardening
This story is less technical. If you are interested in the technicalities — I will soon publish those on another story with a few of my tips & tricks.
Case #1 — From source code disclosure to full internal APIs access (aka “I’m buying”)
The first case is an e-commerce website that has dozens of orders per day.
The website is one of a few applications in total, all using the same APIs which are based on the Laravel open-source framework.
When I first had a look on the website, I noticed it was API based. I manipulated some parameters on a specific request and got back PHP errors which told me that it is based on Laravel.
Now that I knew that it is based on Laravel, I recalled a story I read here on Medium a few months ago, where someone showed how .env files are sometimes not protected and can even be found using Google Dorks.
I tried accessing the application’s .env file and Voilà — it was wide open and revealed some secrets like AWS token, DB credentials and more.
I searched for a few more files that should be there, but shouldn’t be available for prying eyes (like composer.json and package.json) and those were also available and revealed some more interesting information like the server’s real IP address (which may allow an attacker to bypass the reverse proxy / WAF), vulnerable package versions and even deployment scripts.
I stopped investigating once I felt I had more than enough, and that feeling was right after I got access to internal APIs which allows to view customer data, place fake orders and more.
Case #2 — From source code disclosure to XSS
International e-commerce site with pretty heavy traffic based on Drupal.
Side note: CMS detection is usually pretty easy, and it isn’t necessarily a bad thing IMO.
The first thing I saw was that Drupal’s configuration file (settings.php), which holds some sensitive data like the DB credentials and the hash salt is being printed to the browser.
Well, they were at least lucky not to expose PHPMyAdmin or another database administrative tool publicly :)
Once I understood that some PHP files are printed to the browser, I made a quick “white-box” review and got a few custom code pieces which quickly revealed some vulnerabilities like exploitable XSS and possible DOS due to missing validation.
An attacker could have used those to steal cookies and perform session hijacking.
Case #3 — Two modules combination led to full administrative users list disclosure
This one isn’t bad like the previous two since this is “just” a corporate website, which doesn’t hold too much sensitive information (only contact requests and such), but I want to tell about that one because of its special essence.
It is a Drupal-based website, very ordinary, but the thing here was the combination of two Drupal contributed modules, that together (+ a misconfiguration issue) allowed me to list the managerial users of the site (names and emails), and maybe with a little more effort of social engineering attack or brute-force I could be able to log in as a site manager and steal data or deface the site.
This vulnerability wasn’t that trivial and required some familiarity with Drupal, which is exactly the type of vulnerabilities I love.
Case #4 — From source code disclosure to SQLi & RCE
And last but not least, the cream of the crop if I may say..
This one is also a Drupal-based e-commerce website with integrations to many systems such as the organization’s ERP system, SMS messages and more.
This site had two major vulnerabilities:
- SQL injection in a custom form, due to improper use of Drupal DB query APIs
- This case is pretty similar to the first two, but also a bit different.
I found out that the site isn’t protecting some common Drupal file extensions which allowed me to download significant parts of their code and that in its turn revealed most of their custom routes. After checking one after the other, I saw a custom route that provided a file upload capability without any validation of the uploaded file — that allowed RCE and also allowed overriding existing system files (e.g. index.php and settings.php), the 2nd vulnerability reminds the recent WordPress thumbnail zero day attack.
Worst case scenario: Access to other business systems via the hacked web-server.
Wrapping up
I think that using an application framework, is pretty much like buying a new smartphone. When you take it out of the box for the first time it works so fast! Then you start customizing it and installing things, and after 2 hours it goes from WOW to just great.
In my research I was able to find highly critical vulnerabilities on large scale e-commerce sites which probably couldn’t have been identified easily (or have been vulnerable at all!) if the basics of using these open-source frameworks were fulfilled.
Hope you enjoyed reading my story, and that it will drive a change to make the web a safer place for us all.
You are invited to follow me and be notified once my next technical AppSec tips & tricks and Drupal 8 specific insights stories will be published.