Note: Do not test web apps without permission. I reported this bug along with all other exposed actuator endpoints to the program and they have now fixed it.

Spring Boot Actuator

Spring Boot Framework provides some built-in features to help you manage and monitor your application. These features can be accessed via the actuator endpoints, and are meant to help developers to monitor and debug. Some of the common endpoints are:

• /health
• /info
• /trace
• /metrics
• /heapdump

There are many such actuator endpoints and you can find the complete list of these endpoints with description here. It's definitely worth adding these endpoints to your wordlist. In fact, that's how I discovered the endpoint, while directory bruteforcing the target.

Heapdump

The /heapdump endpoint returns a heap dump from the application’s JVM. It provides a dump file with hprof extension, which is a binary file that can be opened and examined in a memory analyzer tool.

When you visit the /heapdump endpoint, it will automatically download the file on your machine.

Visual VM

Once you have downloaded the file, you need to find a way to open the hprof file and find something interesting, with clear security impact. One way to read the hprof file is by using Visual VM Memory Analyzer tool. Visual VM is a tool that helps you read hprof files, and extract meaningful data out of the dump. You can download VisualVM from here. There is no installation required, you just need to download the tool and run the executable.

After downloading the tool, you can now import the heapdump file in Visual VM. Open the tool -> Go to File -> Load -> Import your file.

On successfully importing the file, Visual VM will give you an initial summary of the dump data on the screen. This includes the server information like JVM information, heap size, classes information, environment information, etc. You can certainly explore by yourself if you know what you're doing and look for interesting objects and classes. There are more than one way of exploitation from here on.

However, since we are looking for a security impact here, a much easier and quicker way of achieving that is simply executing OQL queries on the heapdump data to fetch sensitive information.

OQL

OQL stands for Object Query Language. It is very similar to SQL and used by Memory Analyzer to find interesting data from heapdump using SQL-like queries. OQL represents classes as tables, objects as rows, and fields as columns.

You can open the OQL console in Visual VM to run queries by clicking on the Summary dropdown, and selecting OQL console option.

This should open the OQL window in Visual VM where you can now enter and run queries.

Building queries

As mentioned earlier, OQL queries are similar to SQL, and allow you to query data from the heapdump. From a security impact standpoint, some of the sensitive information we can try and search for in the dump is probably things like session tokens, JWTs, hardcoded credentials, API keys, AWS credentials, etc.

First, I just tried to search for the term "AWS", and that in itself got me a lot of data to look at. There were URLs I could connect to, references to credentials I could try, etc.

select s from java.lang.String s where s.toString().contains("AWS")

The number preceding the variable name is the line where the reference of the variable is. For example, the AWS_SECRET_ACCESS_KEY is preceded by java.lang.String#80962. If we wanted to check the value/usage, we can right click on the variable name, click on 'Open Class in New Tab' and then scroll to the line 80962.

If you are familiar with the format of certain tokens: JWT always begins with "ey...." or AWS_ACCESS_KEY_ID always begins with "AKIA.....", you can tweak your query to directly search for those as well:

select s from java.lang.String s where s.toString().contains("AKIA")
select s from java.lang.String s where s.toString().contains("ey")

You can also try to fetch database strings or other data related to the DB configuration using keywords related to the DB. For example:

This is how we can extract sensitive information from a heap dump when the Spring boot actuator's /heapdump endpoint is exposed in production.

For further reading on this, do check out this awesome research paper: https://www.exploit-db.com/docs/50459

For any questions, feel free to reach out on Twitter

I logged into Hackerone, found a good broad scope private program and opened the main website on my browser. Usually, the first thing I do when I visit a website is check what Wappalyzer can tell me about the application. (Wappalyzer is a browser extension that shows what technology a web application is using).

In this case, Wappalyzer detected the CMS the website was using – Adobe Experience Manager (AEM). I had heard of AEM misconfigurations before. I had a few links and tweets bookmarked in my browser for the same, but I never really got the time to check any of it out. With a good ten days in hand, this was the perfect chance to finally get started with AEM hacking.

Great, but how do I start?

Twitter. Yes, that’s a good start. I started searching for tweets with the search query and hashtag “AEM #bugbounty”. I found a bunch of tweets with a bunch of test cases that I could try. But not knowing anything about AEM, it didn’t make sense to jump to exploitation directly. I stumbled upon a tweet that talked about the research Mikhail Egorov had done on AEM over the last few years, and I found links to a couple of talks where he had presented his research. (Highly recommend you check these talks, here and here ).

What next?

Watching the talks certainly helped. I knew more about AEM’s architecture than I did before. To summarize, AEM has a 3-layer architecture. The three layers are: Author, Publisher and Dispatcher layer. Author Instance is where the content is posted, Publisher is the instance that the user interacts with using the Dispatcher.

Dispatcher is the only security mechanism that protects publisher by stopping requests that do not meet policy. And things start getting really bad if the Dispatcher policy is not set correctly. Dispatcher bypasses are quite common, and a dispatcher can eventually expose servlets that ideally should not be exposed. In other words, Dispatcher bypasses allow to talk to insecure components of the publisher instances.

This can lead to Information Disclosure, XSS, SSRF and a lot of other issues. For the scope of this post, we will talk about the two issues I came across: Information Disclosure through QueryBuilderJsonServlet and HTML Injection via MergeMetadataServlet.

CVE-2016-0957

The dispatcher policy blocks requests when you try to access the QueryBuilderJsonServlet at the endpoint /bin/querybuilder.json However, it can be bypassed if the rules aren’t strict enough by appending the following to the endpoints.

• https[:]//aemsite/bin/querybuilder.json/a.css
• https[:]//aemsite/bin/querybuilder.json/a.html
• https[:]//aemsite/bin/querybuilder.json/a.ico
• https[:]//aemsite/bin/querybuilder.json/a.png
• https[:]//aemsite/bin/querybuilder.json;%0aa.css
• https[:]//aemsite/bin/querybuilder.json/a.1.json
• https[:]//aemsite/bin/querybuilder.json;%0aa.css
• https[:]//aemsite/bin/querybuilder.json.servlet.css
• https[:]//aemsite/bin/querybuilder.json.servlet.html
• https[:]//aemsite/bin/querybuilder.json.servlet.ico
• https[:]//aemsite/bin/querybuilder.json.servlet.png

Slide from: https://speakerdeck.com/0ang3el/securing-aem-webapps-by-hacking-them?slide=10

In my case .;a.css worked and I was able to bypass the dispatcher to access the QueryBuilderJsonServlet.

Cool, dispatcher bypassed. But how is it a security issue? There seems to be no impact here, right? The response to this request has not really retrieved any sensitive information. I had the same question and so I reached out to another security researcher on Twitter who seemed to know his AEM stuff. The guy suggested I read up on how to build queries manually on QueryBuilder.

So, that’s what I tried next. I started reading on how to build queries manually in Adobe’s docs. Also watched a couple YouTube playlists until I figured out a thing or two. I checked AEMSecurity’s Twitter account and found a couple of queries there as well. Fast forward, I came up with the following:

• https[:]//aemsite/bin/querybuilder.json.;a.css?path=/home&p.hits=full&p.limit=-1
• https[:]//aemsite/bin/querybuilder.json.;a.css?path=/etc&p.hits=full&p.limit=-1
• https[:]//aemsite/bin/querybuilder.json.;a.css?type=nt:base&limit=-1
• https[:]//aemsite/bin/querybuilder.json.;a.css?path=/content/dam&p.hits=full&p.limit=-1
• https[:]//aemsite/bin/querybuilder.json.;a.css?path=/libs/granite/core/content/login&p.hits=full&p.limit=-1
• https[:]//aemsite/bin/querybuilder.json.;a.css?path=/libs/granite/core/content/login/clientlib/login.less&p.hits=full&p.limit=-1
• https[:]//aemsite/bin/querybuilder.json.;a.css?type=nt:file&fulltext=*zip
• https[:]//aemsite/bin/querybuilder.json.;a.css?path=/content&type=cq:Page&p.limit=1000
• https[:]//aemsite/bin/querybuilder.json.;a.css?path=/content&type=cq:Page&p.limit=1000
• https[:]//aemsite/bin/querybuilder.json.;a.css?fulltext=*xml
• https[:]//aemsite/bin/querybuilder.json.;%0aa.css?p.hits=full&property=rep:authorizableId&type=rep:User

The above sample queries expose user information, UUIDs, paths on server, files on server, server snapshots, packages, etc. I reported this immediately and it turned out to be a duplicate, someone had already reported it.

MergeMetaDataServlet HTML Injection

I also found the MergeMetadataServlet exposed on the same web app, so I tried to look into exploiting that as well. The bypass for this one was quite simple, just had to add the .css extension to the metadata endpoint.

https[:]//aemsite/libs/dam/merge/metadata.css?path=/etc&.ico

As seen in the screenshot above, the data we input in the path parameter is reflected back on the webpage. Chance for a classic reflected XSS. I immediately started testing for reflected XSS, but got blocked by the WAF in place.

The WAF was blocking almost all HTML tags, =' " and other special characters, onXXX eventHandlers and a bunch of other stuff. After a series of failed attempts to achieve XSS, I ended up reporting it as an HTML injection. Apparently, h1,h2,li,a and a few other tags were not blocked by the WAF.

Note: The response of the MergeMetadataServlet is normally in JSON. In order to execute the HTML, we need to change the Content-Type of the response from application/json to text/html. The simplest way to do that is to append the endpoint with an HTML filename (check above screenshot). The /dMr.html in the URL ensures the server changes the Content-Type of the response to HTML.

Resources

There is a lot more to security misconfigurations on AEM. There is a possible SSRF attack via Opensocial (Shindig) proxy, ReportingServicesProxyServlet, SalesforceSecretServlet, AutoProvisioningServlet. There is a possible XSS via VideoPlayer.swf, SuggestionHandlerServlet, WCMDebugFilter and MergeMetaDataServlet. There are possible DoS attacks as well. If GroovyConsole is enabled on the web server, it could directly lead to RCE as well. I highly recommend going through Mikhail Egorov’s presentations and AEMSecurity’s Twitter account for more details on these:

• Talk 1
• Talk 2
• https://labs.f-secure.com/blog/securing-aem-with-dispatcher/
• https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/security-checklist.html?lang=en
• Automating Dispatcher checks: https://github.com/0ang3el/aem-hacker
• https://twitter.com/aemsecurity

Until next time :)

Note: Some of the attacks in this post require you to intercept traffic and manipulate requests/responses. So, having some knowledge of Burp Suite/OWASP ZAP will certainly help as you read through the article.

Case 1: Host Header Injection

1. Go to Reset Password page
2. Turn on Burp Proxy
3. Request password reset for your email and intercept the request
4. Manipulate the Host header in the request to a website you control, say attacker.com
5. Forward the request
6. If the password reset link that you receive in your email contains attacker.com as the host instead of the actual website, the implementation is vulnerable

If the Host header does not work, you can even try your luck with the X-Forwarded-Host: attacker.com header instead.

The reason why this is a security issue is because if the user clicks on the attacker.com link in the email, it will send a request on the attacker.com server where the attacker can easily harvest the reset token from the URL from his server's logs.

This usually happens in PHP applications when the password reset link is built using https://$_SERVER['HTTP_HOST']/resetpassword?token=wcsajcdncsdklcsdnkvcsdk

A simple mitigation would be to use $_SERVER['SERVER_NAME'] instead of $_SERVER['HTTP_HOST'] to build the password reset link.

Case 2: HTTP Parameter Pollution

Using HTTP Parameter Pollution, an attacker can introduce multiple parameters with the same name into the request. In case of Password Reset, we can add another email parameter within our password reset request.

1. Intercept Password Reset Request in Burp.
2. Add another parameter email in the request
3. Add attacker's email in the new parameter

If the web app is vulnerable, the email with password reset link will be sent to both the emails in the request.

You can also try some other variations of this:

URL encoding a space character: email=victim@email.com%20email=attacker@email.com

Adding a pipe: email=victim@email.com|email=attacker@email.com

Adding a cc mail: email="victim@email.com%0a%0dcc:attacker@mail.com"

Adding a bcc mail: email="victim@mail.com%0a%0dbcc:attacker@mail.com

Case 3: Manipulating JSON

Many times, the request parameters are passed as JSON objects to the reset password API. But the good news is, you can still do the same manipulations for JSON objects as well.

Some other things you can try with JSON:

Pass an array: {"email":["victim@mail.com","attacker@mail.com"]}

Pass wildcard operator in array: {"email":["victim@mail.com","*"]}

Pass null in array: {"email":["victim@mail.com","null"]}

Pass null: {"email":"null"}

Pass wildcard operator: {"email":"*"}

Note: JSON is funny, and different parsers work with JSON objects differently. For example, if two identical parameters are passed, Python may parse the second parameter first and Ruby may parse the first parameter first. This can result in interesting behavior across applications when we pass multiple parameters with the same key, or no parameters, or wildcards, etc.

And so, always try payloads like {"email":"*"} in every request that uses JSON and see how the application responds. Sometimes, wildcards or nulls on API endpoints can return highly sensitive data of all users, or error messages with sensitive info, etc.

Case 4: Token Reuse

Password reset tokens should expire once used. Users should not be able to use the same password reset links multiple times. While this cannot be exploited in real life unless you have some way of getting the victim's access token, but it is still not a good practice to implement password reset in one of the following ways.

Case 4.1:

1. Request password reset for person@email.com
2. Open the password reset link
3. Reset the password
4. Try to use the same link again to reset the password again
5. If the link doesn't expire and same link can be used again, the web application is vulnerable.

Case 4.2:

1. Request password reset for person@email.com
2. Do not use the reset link. Keep the link say L1
3. Request password reset for person@email.com again
4. Do not use the new reset link L2 as well
5. After requesting L2, now try using L1 to reset the password

L1 should not work. If L1 can still be used after requesting L2, the implementation of password reset is not secure as L1 should auto expire once L2 is requested.

Case 5: Password Reset Token Leakage via Referer header

The Referer header is an HTTP Request Header that helps web servers identify where request is coming from. When you make a request from webpage 1 to webpage 2, the Referer header is added to the request for webpage 2 to identify that the request came from webpage 1. This information is used for logging, caching and analytics.

However, this also means that requests originating from the password reset page may also leak the password reset token via the the Referer header. Sometimes, web applications have footers or sidebars with links to third party websites, links to the company's social media accounts, etc. And the Referer header may leak the token to these external links.

1. Request password reset.
2. Open the password reset link.
3. Start Burp proxy and turn the intercept on.
4. Click on any of the third party links/ social media links on the password reset page.
5. You may see the password reset token being leaked in the Referer header.

Again, this is more of a misconfiguration than a security issue as you would normally only have links to trusted websites on your web page. But this is definitely worth mentioning as this is a high risk issue for CMS' and LMS' which allow you to customize what links appear on UI.

Case 6: Hidden Parameters

This is a rather rare case where on requesting the password reset token, the reset link does not have the email parameter on UI. It only asks the user for new password. But when you intercept the request through a proxy like Burp, you can see that there is a hidden parameter email that goes along with the password.

In this case, you can just edit the email parameter in Burp and reset password for any user's account. This works only when the web server just validates if the token is valid and does not check which email the token links to.

Case 7: 2FA Bypass

Many applications implement password reset by sending an OTP to the user's email. And only when the user enters the right OTP, the application redirects the user to the password reset page.

OTP is probably not the best way to implement password reset as there are many ways of bypassing OTPs. In case there is no rate limiting implemented by the web server, bruteforcing a 6 digit OTP is just a matter of minutes with a tool like Burp Intruder. There are many other ways of bypassing 2FA like response manipulation, IP Rotate to get past rate limiting, etc.

Case 8: Guessing

This involves guessing the password reset token after observing how the token is generated multiple times. This is quite time consuming and complicated but very effective if it works. There is no general methodology but you can try a few things to figure out how the token is built.

Ideally, you would create atleast 3 accounts on the website and request multiple password reset tokens from each account. Then you can start looking at patterns in all these password reset tokens.

1. Look at the password reset token for visual clues. Sometimes you can identify how the token was generated by just looking at the string. For example, if the token starts with 'ey' and is a long string separated by 2 dots in between, the token is most likely a JSON Web Token(JWT). Similarly, you can visually identify if the token is Base64 encoded, MD5 hash, etc by the token characters and length.

2. Sometimes, the token may contain the user ID for which password reset is requested. You may notice this after requesting the password reset token multiple times for the same account and observing if there is a fixed part. You may even see this in payload data of a JWT.

3. After multiple attempts of password reset, you might notice that the token has a fixed part and a variable part that changes after every attempt. At such times, it is important to investigate if the variable part is the timestamp. One way to do it is to request multiple password reset links at the same time instant by using something like Burp Intruder. If the tokens requested at the same time instant have the same variable part, it is probably the timestamp in some form. You might be able to use it to construct your own token even if you're not able to completely decode the timestamp format.

4. Figuring out the fixed part of the token is the most difficult. Typically, you would like to collect basic information of the user like email, first name, last name, user ID and try to construct the fixed part out of this. You can try encoding and hashing the data against MD4, MD5, SHA1, SHA256, etc. In case the token is a JWT, you can go to a site like jwt.io and try signing all this collected information with context specific keys like company name, etc.

This article will be updated as I come across new techniques.

For any questions, feel free to reach out on Twitter or Instagram

Until next time.

The link looks legit, yet it takes you to his Twitter account. Did he just hack Google?

Not really. In order to understand what is happening here, we will need to first understand IDN homographs.

IDN

IDN stands for Internationalized Domain Names. It is a mechanism for handling domain names that contain characters other than normal ASCII characters. For example, domain names can contain Latin characters, Cyrillic characters, etc. But these International Domain Names can still not be represented in their Unicode format in URLs.

In comes Punycode. Punycode is a technique to represent these Unicode characters in their ASCII form. The corresponding ASCII code post Punycode conversion is in the form of hyphens, numbers and letters.

So let’s try to decode goᴏgle.com and see what its Punycode representation is. Head over to https://www.punycoder.com/ (Don’t worry, this is not a homograph link)

Next, paste the URL goᴏgle.com in the text box and click on ‘Convert to Punycode’.

There it is, xn--gogle-n29a.com is the unmasked URL in Punycode format that was hiding behind the International Domain Name goᴏgle.com. So what Simone(@evilsocket) probably did, was he bought the domain xn--gogle-n29a.com and redirected all requests on the domain to his Twitter profile.

If you’re interested in knowing more about the ToASCII and ToUnicode functions that are used for the conversion, you can get more details on RFC3490 here .

Now comes the interesting part. How can an attacker leverage the use of IDN homographs?

Phishing

The first and obvious way is phishing. Majority of us would definitely click on the Google link from that tweet without hesitation. So imagine an attacker does this on an application that requires login. He can easily mass harvest credentials of users by creating an identical phishing page on the IDN homographed domain.

Another way would be using these domains to download and install malware on the computers of users who visit the site.

URL Redirects

URL redirection is another scenario where an attacker could use IDNs. For instance, let’s say we have an application target.com . The application has redirects that are accepted as valid only when the redirects are to the same origin target.com/*. An attacker can replace any of the letters in URL with Cyrillic characters. And if the server is not configured to convert the hostname to Punycode before validating the URL, it could redirect the user to the malicious URL.

Original URL: http://target.com/login?redirectURL:http://google.com

Malicious URL: http://target.com/login?redirectURL:http://goᴏgle.com

The difference in the two URLs is not noticeable to the naked eye(here it is because hashnode is secure) but if a user clicks on the second URL, it will lead him to the malicious website. The attacker can potentially escalate the redirect to XSS if he can load and executes Javascript from the redirected URL.

Password Reset

IDNs can also be used on Password Reset functionality of applications to change password of any user. For example, let’s say arbaaz@gmail.com has an account on target.com. An attacker can send a password reset request for arbaaz@gmáil.com (notice the á).

If the password reset functionality is not configured to convert the email to Punycode and then validate it, it will send the password reset link to arbaaz@gmáil.com, i.e. xn--arbaaz@gmil-s7a.com in its ASCII converted form.

An attacker can buy the domain xn--arbaaz@gmil-s7a.com and get the credentials for arbaaz@gmail.com by requesting password reset on arbaaz@gmáil.com

So that is how IDN homographs work. I will leave you with this report where a security researcher was able to able to get a user’s OAuth token on SEMRush using IDN homographs.

For any questions, feel free to reach out on Twitter or Instagram

Until next time.

Nmap is one of the most important Information Gathering tools used by a Penetration Tester. Nmap or network mapper is a port scanning program that finds open ports on the target host. Based on which port is open, the penetration tester can further structure their plan of attack.

Nmap is a great tool and offers more than just finding open ports. It can be used to enumerate what services are running on the open ports and in some cases, also to find the exact version of the service running on that port. It also has some more advanced features like NSE(Nmap Scripting Engine) or the flags that it offers as commands, but its most important utility is the port scanning functionality.

Today, we will code a simple Nmap like port scanner using Python that will tell us which ports on a given host are open.

Imports

We will start with importing the modules we need to build our simple port scanner.

First, we need the socket module. We will use its functions to establish a TCP connection to the target ports on a target host. So, let’s import it.

Also, just to make our output look pretty, we will display the open ports in green and closed ports in red. For that, we will import termcolor module.

Code

Next, we need to create a socket instance.

In the first line, we create the socket instance. The first parameter AF_INET refers to the address family of IPv4 addresses. We are using this because the input to our scanner will be the IPv4 Address that our program will scan. SOCK_STREAM, the second parameter, because we’re creating a TCP socket and will be using the TCP protocol for connection.

The setdefaulttimeout() function takes the number of seconds as a parameter. In our case, we will set the default timeout for new sockets to 1 second.

In the third line, we take the target's IPv4 address as input from user and save it in the host variable. We will use this variable to connect to the host later.

Now, we will set up a for loop to iterate through the number of ports in a particular range.

We will scan the first 1000 ports. You can change the range if you want to. We will pass the port number in every iteration to the portScanner() function. But we haven't coded our portScanner() function yet, so let's do that now.

The portScanner() function is a simple if else conditional loop. The connect_ex() function will try to establish a connection to the host given by the user and at the port passed by the for loop's current iteration.

You can use connect() instead of connect_ex() as well, but you have to remember to surround it by try-except. On the other hand, connect_ex() returns a 1 or 0 indicating success or failure of the operation.

If we manage to connect to the target port successfully, we will simply print out the port number and a message that the port is open. Else, we will print the said port is closed.

Let’s have a look at the complete code now.

Time to Test

Now, it is time to check if our code works. To test the code, close your editor and run the code using python3 command.

The command for running the code is:

python3 filename.py

Enter the host IP address you want to scan. I’m going to enter the IP of my Windows 7 virtual machine.

The scan will continue for some time. Once it reaches an open port, it will print it out in green.

To speed up the scan and have a clear terminal, you can comment the print statement for closed ports.

And with that, we have completed our Simple Port Scanner in Python.

What next?

You can modify this simple port scanner to make it more user friendly. For example, our simple scanner only scans IP Addresses as of now. We can write a function that translates domain names to addresses. Next, instead of scanning for 1000 ports, we can ask the user to input the ports or port range he wants to scan.

For any questions, feel free to reach out on Twitter or Instagram

Until next time.

The Realization

Bug bounties are tough. They really are. The competition in public bug bounty programs is crazy and it is very difficult to find bugs as a beginner. To add to that, there are professional hunters out there who have built and setup their automation frameworks on VPSs that automate most of their processes. Leaving no low hanging fruits for you as a beginner (Not being salty, they absolutely deserve it for their hard work).

It took me a month to find my first bug on a public program after which I started getting private invites.

The Struggle

I have this habit of using Firefox in Incognito mode to search for stuff and have Burp Suite running in a normal Firefox window when I'm testing any web application. And funnily enough, that habit found me the bug!

I was going through the web app of the program in question, let’s call it target.com from here on. I had tried a number of things on target.com already, but couldn’t find a bug. My failed attempts included finding XSS, SQLi, IDORs, checking the password reset functionality, testing the JWT implementation and a lot of other things. But even after a week of sticking to the same program, no success!

The Accident

I was about to give up on my nth program and move on to the (n+1)th when something happened. I was on my normal browser window, logged in into the application. Burp’s content discovery had found me a bunch of endpoints in the application that were exposing some Javascript files. I had read enough bug bounty writeups where people found access tokens and other sensitive information in JS files. So I decided to go through those files before calling it quits.

One by one, I was copying the endpoints from Burp and opening them in my browser window. Because I was logged in, the application was allowing me to access the endpoints as well. This one time however, I accidentally copied an endpoint from Burp and paste it into the incognito browser window, that I use to Google stuff. That’s when it happened!

Open Redirect

The JS file didn’t load because I wasn’t logged into the web application in the incognito window. The browser took me to target.com’s Login Page. I noticed the URL and found something interesting. The URL looked like this:

https://target.com/login?targetURL=/path/of/js/file.js

Upon login, the application was going to take me straight to the JS file endpoint and not to the Dashboard. It was using the targetURL parameter to redirect me.

I immediately thought this could potentially be vulnerable to Open Redirect. And so, I changed the value of the targetURL parameter to https://maliciouswebsite.com

The complete URL now looked like

https://target.com/login?targetURL=https://maliciouswebsite.com/

I put my login credentials and hit enter. And the application now redirected me to maliciouswebsite.com!

For those who don’t know what Open Redirect is, an Open Redirect is simply when an attacker is able to redirect users from the target web application to another malicious web application controlled by the attacker. In this case, the attacker would be able to redirect the user from target.com to maliciouswebsite.com using the targetURL parameter.

Why is this a Security Issue?

Open Redirect on its own is not considered as a big security issue, especially in bug bounty programs. The most an attacker could do, is lead the user to a malicious phishing website that looks exactly like the target application.

But Open Redirects can be chained with many other security issues to increase their impact. Some chaining methods include:

• Open Redirect to trigger XSS (Cross Site Scripting)

• Open Redirect to steal tokens (OAuth, JWT Tokens, etc)

• Open redirect on Login/Password Reset pages to steal credentials

• Open Redirect chained with SSRF (Server Side Request Forgery)

The above chaining methods drastically increase the impact of an Open Redirect Vulnerability. At the time I found the bug, I did not know much about chaining, so reported it just as an Open Redirect.

But I'll leave you with these reports of Open Redirect chained with XSS vulnerability in Twitter and Uber.

For any questions, feel free to reach out on Twitter or Instagram

Until next time.

Ethereum 2.0 is the biggest upgrade to the Ethereum mainnet since the launch of Ethereum back in 2015. Ethereum 2.0 comes with some big improvements to the Ethereum blockchain to tackle some of its problems inherent from day one. In this post, we will learn what the issues of Ethereum are and why we need Ethereum 2.0.

Proof of Work

The Ethereum Blockchain currently uses the Proof of Work mechanism to reach consensus. In Proof of Work, miners compete with each other to solve a cryptographic puzzle. The miner who solves the puzzle first gets a reward for mining the block.

In order to become a miner, an Ethereum user must set up a full node on his/her computer. They also need to have some expensive hardware(GPUs/ASICs) that will ensure they solve the puzzle before other miners. This results in consumption and wastage of massive amount of electricity.

The problems with Ethereum 1.0

The current architecture of Ethereum (PoW) makes it extremely secure, there is no denying that. But the current Ethereum architecture also happens to have some flaws.

For example, Scalability and Accessibility are two of the biggest flaws of the current Proof of Work Ethereum Blockchain. The main goal of Ethereum 2.0 is to overcome these flaws of Ethereum 1.0. It plans to do so by moving from Proof of Work to Proof of Stake Consensus mechanism.

Scalability

The current Ethereum Blockchain mines blocks sequentially, with a limit on the size of data that can be added to a block. This is a problem because it restricts or limits the amount of data that is processed in a given amount of time.

When the number of transactions to be processed exceeds the amount of data that can be added to a block, many transactions have to wait for subsequent blocks to be confirmed. And hence, the current Ethereum architecture is not very scalable to handle many transactions. Ethereum 2.0 solves this problem using Shard Chains.

Accessibility

It has become very difficult for an individual to run a full node and start mining new blocks on the Ethereum blockchain. The mining hardware is quite expensive for an individual to start in the first place.

Moreover, a miner also needs to reside in an area where the electricity costs are comparatively less because of the energy consumption in the entire process of PoW mining.

This however, becomes profitable for companies and mining pools. Governments usually charge businesses and companies comparatively less for their electricity consumption. Normal individuals cannot compete with these companies and this leads to centralization of power in the mining process.

Proof of Stake in Ethereum 2.0 will try to reduce the centralization of power and will make mining more accessible to individuals interested in validating the blocks.

That is it for this post. I hope you found it useful and learnt something new.

Feel free to reach out on Twitter(@ar6aaz) or Instagram(@theblockchainblog)

Until next time.

A good cryptographic hash function must possess the following five properties:

One way

A cryptographic hash function must always be one way. That is, it should be possible to find the hash from an input easily. But, the reverse must not be possible. By no means should the input be recovered from the hash. This one way functionality of hashes is the reason why passwords are usually hashed before they are stored in the database.

So even if someone manages to get access to the database, they still won’t be able to reverse the hash.

Deterministic

A cryptographic hash function must be deterministic. For a given input value, the output must always give the same hash value if passed through the same cryptographic hash function. In addition, two copies of the same document should also always give the same hash when passed through the same cryptographic function.

Fast Computation

The cryptographic hash functions undergo a number of complex mathematical computations before they produce the hash. These computations make the hash one way, so they are important and can’t be ignored.

However, computers must also be able to perform these complex mathematical calculations involved in producing the hash in a short period of time. This property of producing the hash in a short time is also known as the hash functions being computationally efficient.

Must withstand collisions

A collision is a situation when the hash function gives the same output value for two different inputs. The perfect analogy for this is having two human beings with same fingerprints. The probability of two human beings having the same fingerprint is one in 64 million. Similarly, no two unique inputs should produce the same hash as output. This property of a hash function withstanding collisions is very important for blockchain based applications.

Avalanche Effect

The hashes generated from an input must not have any visible pattern of hash generation. This is because no user should be able to find a hidden way of guessing the hash; else they will be able to break the hash function easily. And so, for every single bit change in the input, the output hash should change completely. This is called the Avalanche effect.

So, “hello” and “Hello” will produce completely different hashes without showing any pattern.

These are the five important characteristics of any good cryptographic hash function. I hope you enjoyed this post.

Feel free to reach out on Twitter(@ar6aaz) or Instagram(@theblockchainblog)

Until next time.

Hash Cryptography is one of the main pillars of any Blockchain. It is what makes blockchains what they are, a securely linked chain of blocks. And today, we’re going to learn why.

What is the easiest way for us to uniquely identify humans?

“Just by looking at them” is not the answer. There are too many people with the same hairstyle, similar facial structure, skin tone and almost all other visual factors.

I’m going to save you time, and tell you the answer. Fingerprint.

The easiest way to uniquely identify humans is by their fingerprints. Almost every human has a unique fingerprint. And this can be(and is) used to uniquely identify us.

What about digital documents? Or a piece of text? Or an audio file? Or an entire Operating System?! How to identify these uniquely?

The answer is same. Digital fingerprint.

Digital Documents

Hash Cryptography helps us find these digital fingerprints. You take a piece of information (could be a pdf, a text, or a movie), pass it through a cryptographic hash function and the output you will receive is the hash (or digital fingerprint) of that document.

In the previous post , we saw how the chain of blocks is linked using the Previous Hash field in the Bitcoin Blockchain. The Previous Hash and the Hash field are computed using a cryptographic hash function.

The cryptographic hash function used in this case is SHA256. SHA stands for Secure Hash Algorithm, a family of many cryptographic hash functions like SHA256, SHA512, SHA128, etc. SHA256 was developed by the NSA (National Security Agency) and the code was later made open source. The 256 in the name denotes the number of bits it takes in memory. It is a 64 character long hexadecimal hash where 4 bits represent each hexadecimal number.

Below is an example SHA256 hash of the input string "Hello"

Bitcoin Blockchain

In the Bitcoin Blockchain, the current hash is computed by giving the Data Field and the Previous Hash field as input to the SHA256 function, and the function returns the output i.e. the hash or fingerprint of the given data.

You can use the SHA256 or any modern cryptographic hash functions to find the hash (fingerprint) of any piece of information. You can find the hash value of documents, strings, executables, binaries, movies, entire operating systems, etc.

An important property of cryptographic hash functions is that they are one way. Which means, you can go from a document to finding its hash, but not the other way. You cannot recover a document from its hash. This is what makes hashes secure and protects the immutability of blockchains.

In addition to being one way, a good cryptographic hash function should have five important properties. We will cover these five properties in detail in the next post.

Until next time.

Feel free to reach out on Twitter(@ar6aaz ) or Instagram(@theblockchainblog )

I’m sure you’ve stumbled upon this word called ‘Blockchain’ in the last few years. Today, if you use the words “Blockchain based” as a prefix to whatever you’re selling, you’re guaranteed to make 2x sales. The hype is real.

Anyway, we’re running out of time, I’ve only got five minutes to explain this. So let's start.

What is a Blockchain?

A Blockchain is a continuously growing list of records called blocks, which are linked and secured using cryptography. Sounds too Wikipedia-ish, I know. Let’s break it down.

First, let’s understand what a block is.

Block is the fundamental unit or the smallest indivisible part of a Blockchain. The image above shows what a block looks like. A block has many fields, but for the purpose of this post, we will consider only its three main fields viz. Data, Previous Hash and Hash.

The Data field of the block contains the information you want to store in your blockchain. Could be a vote in a blockchain based voting application, or a birth certificate in a blockchain based certificate registration application. In case of Bitcoin, the block stores Bitcoin transactions in its data field.

We’ll come back to the Previous Hash field later.

Next, we have the Hash field. The hash field contains the hash of the block.

What are hashes though?

A hash is a unique fingerprint of a piece of information. Hashes look different depending on the hashing algorithm, but usually, it is an alphanumeric string that looks like this: 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

You give the hashing algorithm some input, and get the hash(fingerprint) in return as output. The goal is to find to a unique signature of all the information input to the algorithm. You can find a hash of a string, a pdf file or even an entire Operating System! Play around with this site to understand how different hashes are generated for different inputs.

In our case, we give the hashing algorithm the data field and the previous hash field as input, and get the (current block’s) hash as output. Check the image below for reference. This hash value of a block is very important. Because in future, if someone tries to change even one bit of information in any of the past blocks, the entire hash computed for those blocks changes.

The hash of a block serves two purposes. One, it is the signature or fingerprint of that block. Second, it serves as the previous hash field in the next block. The previous hash field that is used to produce the hash of the current block comes from the previous block. (I know it sounds confusing at first, but read it a couple more times with the above picture in mind and you'll get it)

If some hacker tries to change or modify the information in the data field of a block, it changes the hash of that block completely. And consequently, it changes the previous hash field of the next block and so on. The blockchain realizes something is wrong as all the hashes are computing to be different. This raises an alarm and the network reverts back to its original unmodified state, making the blockchain an immutable ledger.

This ‘unhackable’, or as I like to call it, ‘difficult to hack’ nature of blockchain will be much easier to understand when we discover the Distributed Peer-To-Peer network of blockchains. But that’s a topic for another day.

In conclusion, a Blockchain is just a growing list of records called blocks, that are chained or linked to each other using cryptographic hashes.

That is it for my five minute explanation of Blockchain. Hope you found it helpful!

Feel free to reach out on Twitter(@ar6aaz) or Instagram(@theblockchainblog)

Until next time.