Bypassing the Shopify admin authentication

On September 28th, 2017, a bug bounty hunter called uzsunny reported a vulnerability on Shopify. They
got admin access by creating two different accounts that share the same email address. The application
had the option to define profiles for each user. In this case, Shopify had a profiled called collaborator,
which had more privileges than normal user accounts. To get these privileges, the user needed to
request the collaborator profile. When the application collaborated with the account, the other account,
which was different, automatically got the same privileges. What's more, the other account had access
to the sites controlled by the other account with the same privileges. If you want to read more about this
bug, visit https://hackerone.com/ reports/270981. These kind of problems are more common than you
think. From the developer's perspective, it is difficult to implement the user management modules and
the authorization modules. Usually you can implement the authorization privileges, and developers
create an access matrix, where the application's sections versus the user's profiles are defined. But, as in
this case, when an application is sharing information or needs with more than one authorization matrix,
developers create assumptions, where the developer never thought that the same email address could
access the same sites. As a tip, to find this type of vulnerability, I recommend testing all the sections that
you find using the spider with all the users you have. Usually, in bounty programs, at least two users of
each level of access are provided. If not, create different users with different accounts and with the same
accounts; if you think you find some strange behavior in a restricted section, ask for a user, explaining
your thoughts. It is possible that the owners will provide you access to tests. Application Logic
Vulnerabilities Chapter 5 [ 66 ] Starbucks race conditions On May 21st, 2015, a researcher from the
Sakuruty group published a bug about a race condition in Starbucks' payment module. To understand
this vulnerability, let me explain what a race condition is. In the computer science, there are shared
resources, for example, the memory, data, and environmental variables. So, what happens if process A
wants to access the same resource as process B? Well, the first process that accesses it will use it, but
not necessarily this resource will be blocked—it could be used at the same time by the other process
with unexpected results. Researchers from Sakurity bought three Starbucks' cards, and registered them
in the web application. This application had the feature of being able to transfer money between cards.
The researcher analysed the request to transfer money, and found that the process was as follows: Take
the values origin, destiny, and the session: After the money was moved, the application cleared the
session. This process was made by two POST requests. The application controls the session: Clearing the
session was the only mechanism to avoid multiple transfers. The researchers found a method to prevent
the application from clearing the session, so that in this moment, the value could be used more than
once, to get extra money. To do that, they created the following exploit: # prepare transfer details in
both sessions curl starbucks/step1 -H «Cookie: session=session1» --data
«amount=1&from=wallet1&to=wallet2» curl starbucks/step1 -H «Cookie: session=session2» --data
«amount=1&from=wallet1&to=wallet2» # send $1 simultaneously from wallet1 to wallet2 using both
sessions curl starbucks/step2?confirm -H «Cookie: session=session1» & curl starbucks/step2?confirm -H
«Cookie: session=session2» & Application Logic Vulnerabilities Chapter 5 [ 67 ] Why does it work? Well,
the developers always expected that the transference was made by the web browser. Why? Because
everybody needs to use a browser to access an application. Wrong! If you know the correct request, you
can make it using the command line, like the researchers, with CURL, a command-line tool in *NIX
systems, or you can even use an HTTP proxy. This scenario, where a user avoided the use of the browser
and made the request directly to the application, was never considered by developers, allowing the bug
bounty hunters to get free credit on the cards. If you want to learn more about this, you can find the
blog post here: https://sakurity.com/blog/2015/05/21/starbucks.html. How can we find vulnerabilities
such as this? Use the Repeater tool to modify the application's requests and analyze the responses with
little variations. To do that in Burp Suite, you can stop a normal request by using the Intercept is on
button in the Proxy tool: Then, use the secondary button to show the menu, and send the request to
Burp's Repeater tool: Application Logic Vulnerabilities Chapter 5 [ 68 ] The next time you want to send
the same request to see the response to certain modifications in the request, you do not need to follow
all of the application's flows. You just need to resend the request directly in the Repeater tool. For this
vulnerability, the developers used CURL to make the proof of concept. CURL is a command-line tool
that's used to make requests from the console to an application. Sometimes, it is normal to use CURL to
automate requests in a script. To learn more about CURL, type the following from the command line in
any UNIX-like system: $ man curl Application Logic Vulnerabilities Chapter 5 [ 69 ] Binary.com
vulnerability – stealing a user's money On November 14th, 2015, Mahmoud G., published a vulnerability
that allowed him to steal money from accounts in binary.com by modifying one parameter in a request.
Mahmoud G. created two accounts in the application, and then logged into them in two different web
browsers. Once logged in, he used the first one to deposit money by using the cashier option in the
application. The transaction generated this call: In this frame, the PIN parameter is used to identify the
user who will receive the deposit. So, in the other browser, Mahmoud G. modified the PIN in the request
so that the second account received the money, instead of the first one. The result is as follows: To
identify this type of vulnerability, you need to make a note of the following: Analyze each application's
feature using at least two users of each authorization level that the application has. Analyze all the
requests using an HTTP proxy and try to determine what each parameter is doing and the value used by
the application. Pay special attention to variables that are being used as control flow variables.

HackerOne signal manipulation This is one of the easiest bugs I have viewed in a report; it does not need
any advanced techniques to exploit it, but it has a real impact on the application's logic. On January 6th,
2016, a bug bounty hunter named Ashish Padelkar published a bug in HackerOne, related to HackerOne
itself. As you know, HackerOne is a bug bounty platform, and like on all bug bounty platforms, a user's
reputation is important. Reputation is used so that you can gain access to better payment programs. In
HackerOne, the final security teams are involved in the reporting and confirmation process. Having a
good reputation is important to get a quick response about a report. Well, Ashish Padelkar found that if
you created a report, and then closed it by itself, the user's reputation increases. That is all the bug was
about. As you can see, it is so easy, but it was an unexpected flaw in the development process. Offering a
specific tip to identify these types of vulnerabilities is hard. The only recommendation here is to test any
feature you find in the application, using a manual map to find all the possible flaw