Posts

Firebase Applications – The Untold Attack Surface

Introduction

In this blogpost, we will review some of the basic components of a Firebase application from a Security Perspective and talk about common issues that don’t get enough attention.

What is Firebase?

Firebase is a complete backend as a service with many different features that we can plug straight into our applications. For example:

  • Firestore – This is a NoSQL database, allowing you to store your application’s data
  • Firebase Auth– A service that allows you to add authentication & authorization into your firebase applications by configuring the Firebase Security Rules
  • Cloud Functions– Serverless service. Allows you to run a backend code (usually this is where you’d place your REST API backend)
  • Cloud storage – for storing files

There are more services such as Cloud Messaging, Analytics, Machine Learning, etc.

The list of features is really big and won’t be covered here. In this post, we’ll focus on the first two: Firestore DB and Firebase Auth.

Firebase Auth

Firebase Authentication is used to authenticate users to your app. It provides easy-to-use SDKs, and ready-made UI libraries. It also supports authentication using passwords, phone numbers and identity providers such as Google, Facebook and Twitter, and more.

Security Fun Fact: As long as the Firebase Auth service is enabled: registration is always open, meaning that it’s possible to create new users even if the application itself doesn’t have a registration page (for example: Internal Organization Applications where the accounts created by the company’s employees and not remote clients)

You can create a new account in your target application by utilizing the Client SDK and call createUserWithEmailAndPassword() directly with your own JavaScript code:

<script src="https://www.gstatic.com/firebasejs/7.15.5/firebase-app.js"></script>
<script src="https://www.gstatic.com/firebasejs/7.15.5/firebase-auth.js"></script>

<script>
    /*
    * Insert your target's application config in the firebaseConfig object below.
    * This information exists in the client-side and visible to everyone.
    */
const firebaseConfig = {
    apiKey: 'redacted',
    authDomain: 'redacted',
    databaseURL: 'redacted',
    projectId: 'redacted'
};

app = firebase.initializeApp(firebaseConfig);
authService = firebase.auth();
authService.createUserWithEmailAndPassword('appsec@pwn.com', '123456789').then( creds => {
    console.log(`Account created (${creds.user.email})`);
});
</script>

The snippet above will create a new account. This allows a remote attacker to test not only Authentication issues, but also Authorization issues, for example: Since the attacker now has a new account in the application, he can obtain a JWT using signInWithEmailAndPassword() and start performing queries in the Firestore DB that are not available to un-authenticated clients.

How to prevent
As it is right now (2020), you cannot disable sign-up without disabling the whole Auth service (meaning, disabling sign-in for all users too).

However, there’s a workaround for this: If you want to close the registration option but keep the Auth service alive (so other users will still be able to login), you can implement a custom Cloud Function that hooks into the user creation process using the Authentication Service Triggers.

Firestore DB

Firestore itself is a NoSQL database. Meaning that we don’t use columns, table and rows.
Instead, when we create a Firestore database, we split our data up into collections.
And inside each of those collections we store documents (which you can think of “records”).

For example: We have this collection called “books” and all those different documents stored inside it. Each one of those documents are given a unique identifier (usually generated by google)

Web Application / Mobile Applications’ front-end code uses Firestore client SDK to communicate directly with the Firestore DB in real-time and perform actions such as Update, Delete, Get, Create, and more.

We don’t want malicious users to perform queries on other legitimate user’s data in the Firestore DB. In order to enforce authentication and authorization between clients, every incoming request is filtered using the Firebase Security Rules, which we’ll review next.

Firebase Security Rules

Firebase Security Rules is an additional layer of access control and data validation which allows you to filter requests/Firestore DB queries before they are processed further in Google’s Cloud Environment. In order to create a user-based and role-based access system that keeps your users’ data safe, you should use the Firebase Auth service (which we reviewed before) with proper Firebase Security Rules set.

To identify the client that sends a request/query, Firebase Security Rules provides us a special object called request.auth:

  • If the client is not authenticated, this object will be null
  • If the client is authenticated / has a live session: This object contains the properties from the user’s JWT.

Note: Google’s server-side is responsible for validating the signature of the client’s JWT. Hence, when writing the security rules, we can assume that the data in request.auth object is coming from a trusted source.

How do I write Rules to enforce Authentication?

To enforce authentication, you just need to make sure that the request.auth object is not null when writing the Security Rules.

For example:

service cloud.firestore {
  match /databases/{database}/documents {
    match /usersBooks/{userId} {
      allow read, write: if request.auth != null;
    }
  }
}

How do I write Rules to enforce Authorization?

The snippet below shows how to use the request.auth object in order to identify who’s sending the request, and more importantly, to determine whether this client is authorized or not to perform a query:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the usersBooks
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /usersBooks/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Pentesting Firebase Apps

The most popular attack vector for Firebase Applications is checking if the Firestore DB can be accessed without authentication. There are a lot of tools/automated scripts on github that is doing this security check.

However, this security check is very simple and it covers just the tip of the iceberg. Besides authentication issues (which can be mitigated by adding a simple if request.auth != null rule), there’s a whole world of Authorization issues that was left undocumented.

Since this subject didn’t get enough attention, I decided to write firepwn: A tool for testing Firebase Authentication and Authorization issues.

The tool can be found here: https://github.com/0xbigshaq/firepwn-tool

Firepwn uses Google’s Client SDK to perform any query of your choice (get, set, delete and update), example:

This will allow you to “extend” the abilities of your target application and perform custom queries of your own.

Testing for Authorization Issues

If you want to check for Authorization issues, make sure you are authenticated to the target application. This can be done using the Auth Service (on the top right of the UI):

If you don’t have an account in your target application, you can register a new one by using the “Register” feature (above) and then login with those credentials to obtain a fresh JWT.

Testing Authentication Issues

To perform authentication checks: Simply perform queries and make sure that the “Auth Service” (on the right) says “not logged in”.

How to edit Char Sequence objects in net beans

In Net beans 8, during debugging (in my case, smali debugging), you cannot change char sequence variables, they are shown as read-only strings. An example of usage is Android text-elements (EditText) whose value is stored in Obj.mText.mText in a char sequence. The following screenshot, shows a Tree view, but you cannot change the field in table view either.

netbeans1
So, I tried do the same with Net beans 6.8 and I found that it let me edit char-sequence variables. After some research I figured out that in order to enable editing of those variables I need to disable the auto formatting. You do this in tools menu -> options and remove the V of Default Char sequence formatter:

Read more

Formula injection

About Formula Injection

Almost every website today provides social, financial or informative detail to the internet users. Websites that contain sensitive data about users, such as banks, social networks and online stores, restrict the access to private data by using access-control measures such as authentication, authorization encryption mechanisms and more.
However, hackers are still able to find their way to the “prize” with very clever attacking techniques, as their primary target is usually the sensitive data behind the application.

 
In the following post we will review an unusual injection type, with a great potential to cause some SERIOUS DAMAGE if initiated. Well… how can it be initiated? It depends, primarily on the web application programmers, BUT also on the user himself.

 
Let’s start by saying that every application uses untrusted data.

Since the application is intended to be used by the public – we don’t know whether the user is a legitimate one, or a hacker trying numerous types of attacks in order to hijack user sessions, credentials and/or sensitive data such as credit card numbers.
 
Read more

SoapUI Code Execution Vulnerability – CVE-2014-1202

In this blog post I will discuss a vulnerability I’ve found in the SoapUI product before version 4.6.4 (CVE-2014-1202).

I discovered this vulnerability during a penetration test in which I saw that the SoapUI software allows the clients to execute a Java code on the local machine by putting a Java code inside the following tag:

${=JAVA CODE};

The vulnerability allows the attacker to execute the java code on the victim’s machine, thereby putting in danger the SoapUI users, including developers, penetration testers, etc.

Read more

Resident XSS – Reflected Becomes Stored Thanks to HTML5

HTML5 is the newest version of the HTML. It offers new features that enhance support for creating web applications that can interact with the user and his/her local data and servers. HTML5 successfully does this more easily and effectively than has previously been possible.

In this article we will focus on the new client storage offered by HTML5. The new HTML provides us with the Local & Session Storage, which can hold  15MB and more of client data. The differences between them is that the Local Storage can be accessed from any window, while the Session Storage can by read/modified by the same window only. Additionally, the data within the Session Storage will be automatically deleted when the window is closed, whilst deletion of the data in the Local Storage must be done manually.

Let’s say that the web application stores your account number, the SessionId, username, and some other data that will be read later on in order to display the data without sending requests to the server. The website takes the data it previously entered to the storage and displays it when the page renders. This is how the page looks normally, along with the original information stored in the sessionStorage:

ScreenShot138(Click on the image to enlarge)

Notice that the message within the speech bubble takes its information from the Session Storage, as can be seen in the above image, right below the page. You can access the page’s Resources tab using Chrome’s Developer tools (a.k.a Inspect Element).

We can assume that the page’s code behind it looks something like this when retrieving the data from the Session Storage:
<script>
   var username = window.sessionStorage.getItem(“username”);
   var speech = window.sessionStorage.getItem(“Speech-of-the-day”);
   var action = window.sessionStorage.getItem(“Random-action”);
</script>

If this website is vulnerable to a Reflected XSS (which in the regular case would be executed once on the response that includes it) and if the website does not perform client-side encoding (escaping), then this Reflected XSS can become a Stored XSS.

Read more

Erez Metula is presenting at the International 2014 Cyber Security Summit in Tel Aviv, Israel

On January 16th, 2014, Erez will be giving an important presentation on Android Hacking in Mobile Application Security.

Full logistical details can be found here: http://cyber-security-tlv-summit.events.co.il/save-the-date

CYBERSEC-LUZ

We’d love to see everyone there and we’re looking forward to the exchange of ideas. For now, take a look at the  Synopsis so you have an idea of what’s ahead!

 Synopsis of his upcoming speech:

The mobile apps revolution has completely changed the way we use our mobile devices, that up until  recently were used just to make phone calls. Mobile applications nowadays handle our most sensitive data –  phone calls, SMS text messages, geographic location, financial information, internet browsing, etc., but the  question is “How can we really tell how secure are those applications? Who can assure us they are not spying on  us? Or, can it be abused by other applications taking advantage of security vulnerabilities in those apps?”

During this presentation we will answer such questions, while focusing on Android mobile applications. We will  start by describing the threat model of mobile apps vs. traditional apps, then we’ll demonstrate a couple of  common application level vulnerabilities, and the tools/techniques used to expose them.

Participants of this presentation will also witness the usage of the AppUse Android Penetration Testing VM – an open source virtual machine created by AppSec Labs for the sole purpose of pentesting Android applications.

 

Getting to know our experts: Chilik Tamir

Over the last few years AppSec Labs has been building a strong reputation for excellence in the field of Application Security. We offer services including pen-testing and full code review. As we’ve grown we’ve increased our experience, branching not only from pen-testing, but to in-company training and e-learning. We’ve developed a product line in e-learning which we are selling world-wide, and we’re expanding our market.

So, it’s about time that we show you who we are and what motivates us to do what we do. This will be the start to a few blog interviews letting you (our community) get to know us (your community) BETTER. We hope you enjoy hearing more about us and we look forward to hearing more from you.

Keep in touch with us via Twitter and Facebook!

@AppSecLabs

https://www.facebook.com/AppsecLabs

https://www.youtube.com/user/AppSecLabs/videos

Author: Jessie A. Pincus, International Sales Director and Academic Director, AppSec Labs

Getting to Know our Experts:

Chilik Tamir, Chief Scientist, AppSec Labs

Question: How did you originally get into the field of Cyber Security?
Chilik: It was a hobby that became a job.  I saw the WarGames movie back in the 1980’s and it intrigued me.

Question: Since you focus your research on the Apple iOS platform, what do you see as its main vulnerabilities, and where has it improved or made changes to compensate?
Chilik: Apple is beginning to implement security features that are set to ‘ON’ as the default setting, instead of relying on developers to officially turn them on. The pairing notification message and the protection class encryption are enabled by default. Until iOS 7 they weren’t enabled by default.

Question: What aspect of the field of Cyber Security initially grabbed your attention and made you say “I want to work in that field.”?​

Read more

Getting to Know Our Experts: Erez Metula

Blackhat 2013. Las Vegas, Nevada

Blackhat 2013. Las Vegas, Nevada

Over the last few years AppSec Labs has been building a strong reputation for excellence in the field of Application Security. We offer services including penetration testing and full code review. As we’ve grown we’ve increased our experience, branching from pen-testing to in-company application security training and e-learning. We’ve developed a product line in e-learning which we are selling world-wide, and we’re expanding our market.

So, it’s about time that we show you who we are and what motivates us to do what we do. This will be the start to a few blog interviews letting you (our community) get to know us (your community) BETTER. We hope you enjoy hearing more about us and we look forward to hearing more from you.

Keep in touch with us via Twitter, Facebook, and YouTube!

@AppSecLabs

https://www.facebook.com/AppsecLabs

https://www.youtube.com/user/AppSecLabs/videos

 

Author: Jessie A. Pincus, International Sales Director and Academic Director, AppSec Labs

Getting to Know our Experts:
Erez Metula, Application Security Expert, Founder of AppSec Labs

Jessie Asks: How did you originally get into the field of Cyber Security?
Erez Answers: I started coding at the age of 12. I was very interested in the subject of gaming and I got frustrated when I had to bypass stages in order to continue. So, I wondered how I could do it and I thus got into hacking and patching. Once I learned more I understood that it was all about coding. In order to do it properly I needed to be a developer, so I started learning Computer Science.

Jessie Asks: What aspect of the field of Cyber Security initially grabbed your attention and made you say “I want to work in that field.”?

Read more

SSL Vulnerabilities Analyzer 1.1 published

Hi people

After a few months of work and research we have updated the SSL Analyzer tool to version 1.1. So, here is a description about the SSL Analyzer and who should use it.

SSL Vulnerabilities Analyzer

What is it?

This tool was created for penetration testers and for site administrations who want to check if their server allows usage of insecure SSL algorithms.

SSL did not allow attackers to read/change the traffic between the client (computer/mobile browser) and the server, if the server allows insecure algorithms, the attacker can force the browser to use them and break the encryption (as they are named, they are insecure algorithms…).

Easy to use

SSL Vulnerabilities Analyzer has a nice interactive tool that makes it easy to run and check if the server contains insecure algorithms also for non-technical people.

Source code

SSL vulnerabilities analyzer shared with his source code under GPL v3 license, as a gift back to the open source community.

Download

You can download the current version (1.1) from here: SSL Analyzer version 1.1 zip

For more details, source code and versions, please visit the dedicated area in our website: https://appsec-labs.com/SSL_Analyzer

Read more