Thank you for joining my talk.
I guess some of you are having night time
and some of you are having day time,
but again, thank you for joining in.
I would like to thank the DEF CON Red Team Village
for providing me the opportunity to speak on the subject,
which is from discovery to disclosure.
So I do the cybersecurity stuff
for a financial institution here in Pakistan.
And when I'm done with my official responsibilities,
I do the security researching, which is one of my hobby.
Before the information security career,
I used to develop mobile applications,
web applications, and vice versa.
Mobile applications and IoT industry
have been really fascinating
and I look forward to learn more about them
as they are one of the growing industries.
And with the stuff that is growing,
it also has vulnerabilities or bugs or risk around it.
Today, my focus of talk would be Android application
and their controls.
Why Android applications?
Because commonly used by the people around
for the ease of access.
So when you are developing mobile applications,
let's say an iOS or an Android,
you are required to integrate API
because that helps you to fetch the dynamic data
or the data that is stored in the database.
So with the help of API,
which is actually a bridge between a database
and an application,
you are able to perform your operations
more smoothly and easily.
Let's talk about some mobile application security breaches
that happened earlier.
One of them was Zigna that faced a data breach
for around 200 million customers.
The British Airways recently, a year back,
faced a huge fine due to the data breach.
And there was this health application
which used to suggest the weight
or the calories you were taking in.
So let's say you need to record the calories
you have taken in for the dinner or for the lunch.
It would predict the weight for you.
So you can maintain it more easily.
And in the data breach, 150 million accounts were affected
and the data is still out there.
This year, there was a security misconfiguration
in Firebase databases,
which allowed the malicious actors or the users
that could pass a specific and a simple parameter
would allow them to look into the whole database
or the whole data into the database.
With the passage of time,
the vulnerabilities of Android applications
or the Android have been increasing year by year.
So let's say in 2009, we had five vulnerabilities.
And when we see 2016 and onwards,
we have a large amount of vulnerabilities
in Android and Android applications.
So how did I discover vulnerabilities
in one of the applications I was looking into?
So this specific application had around 1.5 million
of downloads on the App Store
with a great amount of reputation.
They had been providing premium services to their customers,
to their premium customers.
So let's say you need to modify the notification,
the time of the notification,
and customize the notification for the premium users
for if you are one of them,
that would be very easy for you.
If you want to send greeting cards
or cards with subject to a specific occasion,
you could have easily do that
by going to the specific function
and generating a specific greeting card
or the occasion card
and write down whatever stuff you want to.
So while looking into the application
through a technical perspective,
I found the application was using Firebase
for the data storage.
And they were using Google Cloud Platform
for their dynamic stuff,
or let's say the stuff they wanted to host.
And as well as the Google Identity Toolkit,
let's say if you are a user,
you want to register on this platform,
all of the identity and access management
were handled by the relying party,
which is also known as Google Identity Toolkit.
So this area had really fascinated me
and I decided to look more into this perspective.
So when I went into the Google Identity Toolkit,
there were a lot of functions
that were visible in their documentation.
I went to their whole documentation one by one
and tried every function on this application
and tried to find out which of the functions
are enabled by this application
and which of them are disabled.
So one of the function which says get account info
was really fascinating for me
and really interesting for me.
So let's say I wanted to find details for an account
if it is registered on the platform
or if it is not registered on the platform.
This specific function was able to return the details
for a specific account or for a specific email address
or for a number, if known.
So what I did is I searched for the organization emails
and one of them was the no reply email
that was not registered
and I found that to be available for the signup.
I signed up to that email address.
Again, it wasn't sending a verification token
to the email address
and allowed the users to log in directly to the application.
So I signed up through this email address
and I was logged in as a corporate user
with the same privileges a corporate user would have.
So in the second attacking scenario,
the API, as we discussed about the API security,
this API was actually using local ID,
which was being, again, part of the Google Identity Toolkit.
The API was providing the local ID along with the username.
So what I did was I tried to replace the local ID one
with the local ID two and the username respectively.
And my request was submitted
and was requested, was approved and respond.
And I got a response to that request successfully.
So that means I can take over an account
or I can post anything from a specific account
by using the local ID and the username
if known.
So in the third attacking scenario,
the API, the marketing API was used by the APK.
So while reverse engineering the APK,
I found this specific marketing API.
And then when I Googled that marketing API,
I discovered the domains, the subdomains
that application were using it.
So that increased my attacking surface
for against that organization
in a more broader perspective.
And then I was able to access one of their internal portals
which was used for the support perspective.
Now I had found everything
and found all of the vulnerabilities
in this specific application.
It was time to disclose it responsibly
to the organization.
So I reached out to their platform,
their support platform.
Again, I knew the internal portal they were using.
So I reached out to their customer support
and requested them to look into the vulnerabilities,
but I just didn't submit those vulnerabilities
on a public platform.
Rather asked them for the email address
or the support platform
where I can post these vulnerabilities
in a very secure way.
And then they invited me to another platform.
I submitted all the vulnerabilities,
all the bugs to that platform.
I received the response from the engineering team.
Again, that take a lot of time.
That, I guess, took around a month.
But again, a response, a positive response
from such organization was really appreciating.
So I got this email from their head of platform engineering.
And this was an unexpected moment for me
because I wasn't expecting any kind of monetary support
or any kind of monetary benefit
in response to the bugs that I submitted.
So I was really kind enough
to their platform engineering team
and their head of platform engineering
for considering the vulnerabilities
and acknowledging my efforts.
So what is the conclusion of all of this exercise
or all of the effort that we had invested?
So when you are disclosing vulnerabilities
to an organization, you should act responsibly.
So let's say you are disclosing vulnerability
to an organization that doesn't have
any vulnerability disclosing program
or a coordinated vulnerability disclosure program.
You look for their engineering teams,
their development teams.
You can approach them in a very respectful manner
and provide as much as detail as you can.
Also respect the privacy.
So let's say if you found out a vulnerability
that is around insecure direct object reference
or that revolves around insecure ways of accessing data,
what you can do is create two accounts for yourself
and then you can play with your both of the accounts
and see if any of this has any vulnerability
or bugs in it.
And then you can submit that by claiming
both of the accounts being used by you.
Again, play within the boundaries,
as discussed earlier in my talk.
There are certain boundaries
and there are certain responsibilities
that lies on the shoulder
of the information security researcher.
So look through these boundaries and act responsibly.
And then again, patience
because that's what is needed the most.
So there have been certain vulnerability disclosure programs
out on the internet.
Yes, we had has a really cool plugin
for the Google Chrome, I guess,
and for the Mozilla Firefox, you can integrate that.
When you are visiting a website or an application,
you can get the details
for the vulnerability disclosure program.
And even though if they are not available
on these platforms,
you can approach them to their email address
they have specified in their usual security.txt folder.
There are a lot of bug bounty platforms
which support the vulnerability disclosure
or the coordinated vulnerability disclosure programs.
So you can approach these platforms as well
and submit your vulnerabilities in an efficient way.
And then again, as I discussed,
the development or engineering department
because they are the one who are developing the applications
and they know the stuff.
With that, I would like to thank everyone.
Again, for joining in.
Stay safe and hack the planet more responsibly.
I'll be available around the Discord Red Team channel.
So if you have any questions, please drop them in
or you have my email address and Twitter account,
The Handler.
So you can share your concerns or the email,
or I mean, you can share your concerns
and your questions over the Twitter or Discord
or whatever medium you would like to.
Thank you so much.
Goodbye.