Deserialization vulnerabilities exist in most languages, frameworks, and platforms, and in this post, we are going to give a brief and useful review of this vulnerability in NodeJS.
Deserialization in the NodeJS platform is easier to exploit than in other areas (my opinion + python).
If the input is given to the Unserialize function, this vulnerability occurs and even causes RCE or code execution on the server, but to increase the chances of exploitation, it is better to use the Immediately invoked function expression or IIFE technique.
Vulnerable code snippet: Here I have prepared a vulnerable code to better understand
Description of vulnerable code: First it is checked whether the user already has a cookie called Token or not, if not, there is a message saying “Reload the Page” that you should refresh the page:
And if you do not have a cookie, it will be set on your browser and you will see the following page:
If you pay attention to the above code, you will see that the set of tokens in the cookie storage is decoded and then unserialized. The mentioned vulnerability occurs here that the data sent to this function can be controlled by the user and ni security check on the server side is performed on it.
The Token value after decoding Base64 is as follows:
Now as you can see this object is sent to the Unserialize function and then the property called username is read from inside it, now all we have to do is create a Malicious Object and then Serialize it, until after the Vulnerable application Unserialized it we can execute the desired code
Execute the above code snippet so that we can have the exploit code output:
But the above exploit has a problem and does not run, because the exploit code never gets invoked and it will only just get defined , it never gets called, and therefore the exploit does not run.
so if we encode the above exploit code and send it as base64, you will see the following page.
To actually run our exploit (invoke), we must use the Immediately invoked function expression (IIFE) technique:
The definition of this technique is that:
To do this, just add parentheses to call the functions when defining the Object.
Now if we come and run the above code to get the result, that is, the exploit code to send, we will encounter the following output.
The reason why we do not see the exploited function object output to copy and send as base64 like last time is that unfortunately if we come and add parentheses, our code will get executed on our own system (attacker computer) and we can no longer have the exploit code to copy and send, to solve this problem it is enough to just run the previous exploit and add parentheses to the output ourselves.
Now if we put the above exploit as Base64 in the cookie and refresh the page, our code will be executed on the server side.
Now how can we upgrade this and get a Reverse Shell? here we go
I hope the article is useful and has been added to your knowledge.
Here we address the basic issues of the Subdomain Takeover vulnerability and examine how this vulnerability existed in the cafebazaar and is now patched.
Cafe Bazaar is an Iranian Android marketplace founded in April 2011, In April 2019 Cafe Bazaar announced it has surpassed 40 million users.
Subdomain Takover is the process of registering a non-existent domain to acquire all existing domains, if this vulnerability is discovered, the main domain as well as all subdomains of an organization will be compromised. (kind of)
To make the point more clear, let’s look at a basic topic in DNS.
Canonical Name Record is one of the DNS capabilities to build a pointer domain to another domain, so what does this mean? What is it good for?
Consider the following scenario for example
Consider that cafebazaar intends to launch a campaign for a limited time to receive user feedback about their organization’s website, now to design a survey form, you would prefer to use a survey form a third party system that has ready-to-go survey form templates. And it works in such a way that after registering in the website, you can easily design a survey form and then you can choose a domain address, but this domain is a subdomain of that company, for example, if the formmakers website address is formmakers.com and you create an account for yourself in that system and choose a username name, such as cafebazaar youre form will be available ar cafebazaar.formmakers.com website.
Using CNAME is useful here, you can create a CNAME record on your DNS server and say that every user who applied for form.cafebazaar.ir should be referred to cafebazaar.formmakers.com, but the difference is with redirecting the user.
The difference is that it is true that the displayed content belongs to the address cafebazaar.formmakers.com, but the address shown in the browser is form.cafebazaar.ir, and this issue increases the credibility of the organization and creates more trust for the user. See the iamge below:
As you can see in the image above, I designed the process of entering the address form.cafebazaar.ir in the browser until the final result in the image above.
Now that we understand the importance of the CNAME record and the rest is story, let’s look at how the vulnerability arises.
Follow the previous scenario we talked about. Now, cafebazaar will end its campaign and delete its account in the online form maker website, formmakers.com, and from now on, when people enter the address form.cafebazaar.ir Because the form-creating account related to the address cafebazaar.formmakers.com has been deleted, users will encounter the error “there is no such form-building account” and the site formmakers.com says that there is no such domain as cafebazaar.formmakers.com.
If you remember, at the beginning of the article we said that:
Subdomain Takover or subdomain acquisition is the process of registering a non-existent domain to acquire all existing domains, if this vulnerability is found, the main domain as well as all subdomains of an organization will be compromised.(kind of)
Did you understand? The site formmakers.com says that this account does not exist !!!! This means that we can create this account.
Now we have to get the name of the main account, Destination Domain, related to this Source Domain so that we can go and register it.
To get the original name, the domain name registered on formmakers.com, we have to ask the DNS Server for the form.cafebazaar.com domain to find out cafebazaar.ir refers to which subdomain of formmakers.com, to do this, we must request the CNAME record in the DNS Server of cafebazaar and see its value so that we can go and register it:
This means that if we register on the formmakers.com website and select the cafebazaar address for ourselves when choosing the domain name that I mentioned at the beginning of the article, the formmakers.com website will register the cafebazaar.formmakers.com address for us. And delivers to us.
But does that mean that from now on we will give the address cafebazaar.formmakers.com to people?
Answer: No, Because the cafebazaar DNS Server still has the old CNAME Record and is pointing to the address cafebazaar.formmakers.com and the value of this record is form.cafebazaar.ir, it means that we also own the form.cafebazaar.ir domain. And all this is due to the Misconfiguration applied to the DNS Server.
The following image is from the settings section of formmakers.com, where we apply the target domain name we want to takeOver:
Now why do we need to worry so much about subdomains? What happened now? Let me tell you what happened:
According to the browser cookie standard RFC6265, all cookies on a domain are sent to all subdomains, and all subdomains are readable.(kind of)
Ability to submit a survey form and collect user information from the trusted domain form.cafebazaar.ir
Ability to exploit potential OpenRedirect vulnerabilities in Cafe Bazaar, which has a whitlist and allow redirects to YYY.cafebazaar.ir subdomains, and since we have acquired the form.cafebazaar.ir domain, we can replace YYY and according to the mechanism OAuth implemented in CafeBazaar and start AccountTakeOver
Distribution of malicious applications by the largest market for distributing Android applications by the trusted domain form.cafebazaar.ir
Spreading false news and damaging the credibility of the trusted domain form.cafebazaar.ir And take more action with respect to infiltrator creativity
Well, in relation to the first topic, I must summarize that you can read cookies set on a domain by its subdomains (in certain condition)
To make this vulnerability critical and to address the security vulnerabilities mentioned above, I started to find ZeroDay XSS on this platform, and after finding 5 Reflected XSS vulnerabilities, after 3 days, I still have the a vulnerability that was low because a link containing XSS exploit had to be given to the user and I did not want to interact with the user because the vulnerability was low. what do we do? giveup ?! No.
On day 7, after hours of testing, I was finally able to find the Stored XSS vulnerability, which was where the vulnerability was at its highest. Critical
After reporting the vulnerability to cafebazaar team, initially the’ve misunderstood the vulnerability was out of scope
What should we do now? give up? Noooooooo!
I started to check the In Scopes of CafeBazaar and realized the following:
As we talked about in the middle of the article, the vulnerability was not related to the form.cafebazaar.ir domain, but to the old DNS record, and it had to be fixed. The image above is the In Scope list, the image below shows that the DNS Server for the cafebazaar is in this IP range:
after sending the above information, they’ve approved and rewarded me, thanks cafebazaar ❤
we will see how the largest e-commerce website in Iran can be vulnerable to SQL Injection, we present the techniques and methods that we used to exploit the vulnerability, abusing IDOR to have vanilla SQL injection
Digikala is an Iranian e-commerce company based in Tehran. By 2017, 62% of Iran’s households have been connected to the Internet and this development is driving demand for Internet services that mirror Western digital platforms such as Amazon. Digikala is ranked by Alexa as Iran’s 3rd most visited website. It is also the largest e-commerce platform in the Middle East. It has 1,700,000 unique visitors per day, and 85% of Iran’s ecommerce now takes place on Digikala
Where did the story begin?
The story begins where digikala launches an online game for a certain holiday in Iran, it’s like Halloween but it’s not, the goal for digikala was to get more users.
we’ll see lots of these events which for some kind of event a company will launch a campaign or a game to attract more users and often the new code is not tested for security issues and gets added to the main application which if vulnerable, well you know the drill (bug in the house)
from now to forward I will put some pictures and some of them are in Persian and I try to circle them and translate the words so you could understand better
The prizes awarded to the winners of this game can be seen in the image below, and the winners of the game are the ones who can get the most points.
BTW for the time this vulnerability was discovered getting a ps4 was a great deal so you could say it was the ps5 of it’s time :D
And what is the game about?
The game is exactly the same as the Chrome browser T-Rex, except that it uses a motorcycle character instead of T-Rex.
A little more technical
A friend suggested why not figure out how the game actually works, I was curious to check out the internals of this game, and after playing around, which also happened to get a low score, I noticed the part of the page that showed the highest score:
The first question that came to my mind was how this score is sent to the server and stored there?
I fired up burp, checked the exchange packages, and started playing again.
As shown in the image above, 2 interesting parameters with the newscore and user_id letters are being sent to the server, and in response, a True value is returned.
A brief examination of these parameters revealed that:
User_id parameter: plays the role of user ID and therefore I could change the value of other users by changing its value (IDOR vulnerability) Newscore parameter: sends the final score of each game round to the server as Base64 and uses the equal sign (=) in the above image Url Encoded to the value of 3D%.
in order to decode this we can use burp suite decoder
So far, we have found a vulnerability, and that was a change in our own or other users’ rating. But was this the only vulnerability? No!
The impression I had on the server side code to update the user rating was as follows:
With this in mind, I started testing the server for SQL Injection; But there was a problem. The code written on the server-side returns only one of the two answers true or null.
This is where I continued to try to find the Blind SQL Injection vulnerability.
(For the sake of confidentiality, I can not provide information from the Digikala database. So from now on, assuming our database is MySql)
Next, I used the Time Based technique to check if the server was vulnerable. In this technique, using database commands such as the Sleep () function, it can be determined whether the sent query is running on the server side or not.
Next problem? Assume that this vulnerability exists. Is it right to execute the sleep command on the largest store website in the country? Absolutely not!
So what do we do? It became a difficult issue! Of course, even if we went through the sleep method, there was still no way out! Extracting data from the database with the above techniques was really time consuming.
Well, let’s review it again:
Our vulnerability is Blind and the server returns only a True or Null response.
We can not use the Time Based technique for the problem space.
To solve these two problems, we can use the score parameter itself to receive information! But what do I mean?
This means that instead of sending a score to the server, for example, instead of newscore = 1000, we send a command to the database and then go to the output of that command in our profile, which shows the “highest score”!
What request should we send (what SQL statement should be used)?
The user() function in the MySql database returns the current user of the database. Therefore, we base code the above function and send it.
What happened? The values were correct, so why didn’t we get the True answer?
These problems occur the programmer configured data storage type for the newScore column in the database to Integer, so if you want to save a string (such as the string “current user” of the database) in that cell, You will encounter an error.
How to solve the problem of the above limitation?
Since we can only put the number inside the score cell, why don’t we convert the information we want (database username) into a number?
For this purpose, you can use the ascii() function inside MySql, which returns the numeric code of a character (a letter of a word).
Here because we have a word like [email protected] , we have to use another function with it called substring().
This function receives 2 inputs, and in order to extract from a source to a destination from the received string, we can say that the output of the SQL statement is converted to the ascii() code,and store that as our new updated score.
Finally, each time it is updated for each word, we have to convert our score from ascii code to “letter” and see the answer of our desired function by putting the output aside.
In the Python script below, we performed these steps automatically.
Anything can be inside the payload and it depends on the database. For example, waitfor and you must specify the amount of delay. waitfor delay ’00: 00: 10 ′
As much as I could, I tried to keep the content simple so that the content could be easily transferred. I hope this post has a good educational load for you and finally do not forget that you should always think outside the box 🙂
How I found the silliest logical vulnerability for $750 that no one found for 3 years
Sometimes even a well-tested program can have silly vulnerabilities, such as this one, a private program which I was invited and it was tested for 3 years, lots of lots of vulnerabilities even critical ones were reported, from SQL-i to XSS, Deserialization and whatnot, nobody reported a vulnerability for over 1 year, but after spending 3 days on it I found this really silly bug which even the team behind the software said, and I quote:
Vendor: I am very surprised to find such a simple vulnerability in this addon. This will be addressed by our development team. Thank you very much for your report.
the vulnerability was in a plugin, the program mentioned that you can find vulnerabilities in their plugins too
the vulnerability was Email blacklist bypass
in a certain plugin, they’ve introduced a feature to prevent usage of free mailing services such as temp mails, gmails, yahoo, etc.
I’m sure you’ve encountered examples of such mechanism in websites which prevent you from complete registration when you use a [email protected] well they mostly are using a list of known domains which provide free mailing service and if the domain part of you’re email [email protected]is using one of the blacklisted domains, then you can’t register.
since the program was open-source and I was reading through to make sure there were no implementation flaws I came across this subroutine
Did you found the vulnerability?
as mentioned in the added comments, the application is taking the user email address for example [email protected], and then checking to see if the domain part of the email is on the black-list
now if we input an email address which it’s domain part is not included in the blacklist, it’s not actually a bypass, but if we use a restricted domain and the application allows it, then that’s a bypass, so let's add some comments
as you can see the application is using the PHP in_array function which is actually a CASE-Sensitive check and vulnerable to case checking, meaning that we can change the [email protected]com to [email protected]and the in_array function returns false when checking if the domain is blacklisted.
As I mentioned the vendor response was this:
Vendor: I am very surprised to find such a simple vulnerability in this addon. This will be addressed by our development team. Thank you very much for your report.
A simple vulnerability yet no one was looking for after 3 years of hunters testing it.
I got rewarded 750$ for this bypass
hope you all enjoyed this write-up, see you next time
Penetration testing, one of the great aspects of cybersecurity, working in different projects will increase your contact with large and expensive software in organizations, enabling you to perform vulnerability assessment on products to which you may normally don’t have access. I still remember the first time my closest friend launched Enterprise solutions software and encouraged me to discover ZeroDays in them, constantly telling me did you found anything? growing the confidence in me to go after the white whale.
in one of my recent assessments, I encountered a PAM360 instance in which I was tasked to do a vulnerability assessment and check if there was any exploit or vulnerability published for it.
PAM360 is a comprehensive solution that enables enterprises to establish strict privileged access governance around their critical information systems and continuously monitor privileged operations, all from a unified platform.
one of the most basic tasks of PAM360 is to enable organizations to store passwords and share them with other users.
These passwords are stored as resources, such as a web, windows, Linux, LDAP.
After you’ve filled in the basic information about the resource then you can create accounts (credentials) for that resource
After you’ve created the resource and created accounts for that resource, you’ll be able to view the credentials of assigned accounts on that resource
Easy right? but what’s the usage here, well there are lots of usages that I can go over but one of the basic usages will be to share these credentials with other PAM360 users
enabling them to use those credentials to connect with resources, for example when you share a Windows resource with another PAM360 user, that user will be enabled to connect via RDP, VNC, etc to that resource.
These capabilities made PAM360 one of the major players out there and it still is, helping lots of organizations to have centralized management over their resources.
Now as I mentioned one of my tasks is to search around and see if there are any vulnerabilities out there or not, fortunately, there was nothing public for the version used by my client organization which was v5003.
Then I thought, does PAM360 have a release page? sure it does
Awesome, right? didn’t you get it? we can check out the release notes made by the PAM360 team to see if there are any Security fixes or not. my client was using v5003 so I should check any version after that:
The PAM360 (manage-engine) team is so professional to do security testing and patching vulnerabilities, I hope this encourages other vendors to do security testing on their products and accept external reports too.
Okay, the next part is much more exciting, now we know there is a vulnerability but there are no public exploits or PoCs for it, and we can’t just say update and show a release note to the client, cause we are not a vulnerability scanner we are penetration testers/hackers/researchers and we need to show Practical example of exploitation not just a plain report with charts and fancy designs.
The note is not saying enough about how to exploit this, but it’s helping a lot, you see PAM360 offers Browser Extension to make it easier for its users to access and save Resource passwords
The browser extension will use your authenticated session to PAM360 instance and communicates with a dedicated API and retrieves your resources.
Now you can use this browser extension to copy accounts credentials or even open a connection to them
now for the exploitation, PAM360 Administrator can restrict user ability to view the passwords
if the policy is disabled then PAM360 users can’t view the password anymore
now if you remember there is another place which we can view the password, let’s check if that place is protected or not
As you can see both places, User Dashboard and Browser extension both are not showing the password, BUT as mentioned in the Security Fix, by capturing the API call of the browser extension and re-using that call we can retrieve the password even when the browser extension is showing You are not allowed to view this password in the UI.
PAM360 implemented a different dedicated API for browser extension (my opinion) and the policy settings of the PAM360 main application were not affecting the access control of the browser extension API calls, hence the information disclosure vulnerability for retrieving passwords even when we’re not allowed to view plain passwords.
We can easily change the PASSWORDID parameter value and view other resources (owned by the user itself no IDOR here) and get those passwords too, like this
It’s common to see applications have additional features to connect/integrate with other components across the network, from setting up webhooks, connecting to SMTP servers, syncing LDAP, and whatnot.
Hello dear readers, SinSin is here, and this time we are going to research another application to Discover a ZeroDay in it. (Reported to vendor and got it patched)
A special program announced anyone who finds a vulnerability in their scope of IP addresses will be rewarded an enormous bounty
Expect The Unexpected: Discovering fresh ZeroDay for Bounty
Well this client had lots of software and appliances all of which were completely up to date, this got me thinking, I really wanted that quote on quote enormous bounty but it needed special care, so I've decided to find ZeroDays in this program, and here is the story
This company was using a software called SophosFastVue, this product is new and has not been around for a lot of years, so I thought why not give it a shot and start popping some ZeroDays in it
Fastvue Reporter, makes the log data from your firewall reflect real Internet usage activity. It removes images, scripts, fonts, ads, and other background traffic so you can send meaningful Internet usage reports and alerts, to the right person.
Now FastVue has multiple Reporter products which all of them were vulnerable:
Palo Alto Reporter
Let's cut to the chase, while looking around and testing functionalities, I’ve decided to test the “Active Directory / LDAP” Integration.
whenever you create a new LDAP / Active Directory setting, something called a “Source” entity is created.
An LDAP source consists of:
LDAP Server Address
SSL or Not
when you set this information through the dashboard, next time you visit the same menu, what you’ll see is the current setting but without the password field and the application is actually reading the LDAP information from its DB through this endpoint:
Now here is the thing, as you can see in the response, we are not able to see the stored “Password”
While looking to find a way to extract the “Password”, after a lot of testing I noticed that when we update the LDAP source settings, we can change information and we don’t need to provide the current password, then asked myself:
What happens if we change only the LDAP Server address to attacker controlled server?
To my surprise, it was possible to change only the LDAP server address
For doing this we just need the previous step “ID” Parameter and a SetLdapSource request to update the LDAP Settings and change the Server Address.
Okay, now we have changed the server address, how can I get a hold of the password?
Root Cause Analysis
There exist a function called SetLDAP which has a logical flaw leading to the information disclosure:
(1) as you can see when we are doing an update-setting for LDAP, first the ID is received from the request and then a search is done in the Database to find the corresponding LDAP source, after retrieving the object, FastVue will use all the parameters which you sent to it to update that object, but only for the Password parameter (2) it will check if the new password is not empty and it has been sent, then updates the previous password or else it will use the current value (previous password) by default, so by changing the server IP address and not sending the password field an attacker can direct the FastVue LDAP Sync action to force authenticate to a fake LDAP server and extract the secret
To extract the password, now we need to force the Application to do initiate LDAP Sync so the authentication process happens and the password gets extracted. to do a Force Sync, we need to request another endpoint
Listening on the other side is:
The vulnerability has been reported to the vendor, and they were so sharp and quick that they patched the vulnerability really fast
Thank you FastVue Team for being kind enough about the blog