Tokening The Tokens!

Spring is here!

Hope you guys enjoyed the last days of the winter, because this summer is going to be hot. And I don’t mean the temperature. More details about that later…

Our case-study today set some ground rules for a new Anti-CSRF attitude that I was working on for the past few months. This new attitude, or, for the sake of correctness – mechanism, basically catalogs CSRF tokens. Don’t freak out! You’ll understand that in no time.

First, I must say that I am probably not the first one to think of this attitude. During some researches I came across the same principals of the tokens cataloging method I am about to show you.

So, What the hell is tokens cataloging you ask? It’s simple. This is an Anti-CSRF security attitude (/policy/agreement/arrangement – call it what you want) where CSRF tokens are being separated to different actions categories. This means that there will be a certain token type for input actions, such as editing a certain field or inserting new data, and there will be a different type of tokens for output actions, such as fetching sensitive information from the server, or requesting a certain private resource. These two main token groups will now lead our way to security perfectness. Whenever a user will be supplied with a form to fill, he will also be supplied with an input action token – a one-time, about-to-expire token which will only be valid to this specific session user, and will expire x minutes after its creation time. This input token will then be related to this specific form tokens family, and will only be valid in actions of this family-type.

Now, after explaining the “hard, upper layer”, let’s get down with some examples:

Let’s say we have a very simple & lite web application which allows users to:
a. Insert new posts to a certain forum.
b. Get the name of each post creator & the date of the creation of the post.

Ok, cool. We are allowing two actions: an input one (a), and an output one (b). This means we’ll use two token-families: one for inserting new posts, and the other for getting information about a certain post. We’ll simply generate a unique token for each of these actions, and supply it to the user.

But how are we going to validate the tokens?
This is the tricky part. Saving tokens in the database is a total waste of space, unless they are needed for a long time. Since our new attitude separates the tokens to different families, we also use different types of tokens – some tokens should only be integers (long, of course), some should only be characters, and some should be both. When there is no need to save the token for further action, the token should not be kept in a certain data collection, and it should be generated specifically for each user.
What does it mean? That we can derive tokens from the session user’s details which we already have – we can use his session cookie, we can use his username (obfuscated, of course) and we can mix some factors in order to generate the token in a unique way, which can only be ‘understood’ by our own logic later in the token validation process. No more creating a random 32-chars long token with no meaning that could be used trillion times. Each action should have its own unique token.

“This is so frustrating and unnecessary, why should I do it?”
If you don’t care about resubmitting of forms, that’s OK. But what about anti brute forcing, or even anti-DoSing? Remember that each action that inserts or fetches data from the DB costs you in space and resources. If you don’t have the right anti brute forcing or anti DoSing mechanism in place, you will go down.
By validating that each action was originally intended to happen, you will save unnecessary connections to the DB.

If implementing this attitude costs you too much, simply implement some of the ideas the were presented here. Remember that using the same type of token to allow different actions may cause you harm & damage. If you don’t want to generate a token for each user’s unique action, at least generate a token for each user’s “general” action, like output and input actions.

Knocking the IDOR

Are you following FogMarks?

Hello to you all.

Sorry for the no-new-posts-November, FogMarks has been very busy experiencing new fields and worlds. But now – we’re on baby!

Today’s case-study is on an old case (and by old I mean 3 months old), but due to recent developments in an active research of a very known company’s very known product, I would like to present and explain the huge importance of an Anti-IDOR mechanism. Don’t afraid, we’re not biting.

Introduction

Basically, an IDOR (Insecure Direct Object Reference) allows attacker to mess around with an object that does not belong to him. This could be the private credentials of users, like the email address, private object that the attacker should not have access to, like a private event, or public information that should simply, and rationally – not be changed by a 3rd person, like a title of a user (don’t worry – case-study about the Mozilla vulnerability is on its way).

When an attacker is able to mess around with an object that does not belongs to him, the consequences might be devastating. I am not talking just about critical information disclosure that could lead the business to the ground, I am talking about messing around with objects that could lead the attacker to execute code on the server. Don’t be so shocked – it is very much possible.

From IDOR to RCE

I’m not going to disclosed the name of the company or software that this serious vulnerability was found on. I am not even going to say that this is a huge company with a QA and security response team that could fill an entire mall.
But I am going to tell you how an IDOR became an RCE on the server, without violent graphic content of course. For Christ’s sake, children might be reading these lines!

Ideally speaking,
An IDOR is being prevented using an Anti-IDOR Mechanism (AIM). Us at FogMarks have developed one a few years ago, and, know-on-wood, none of our customers ever dealt with an IDOR problem. Don’t worry, we’re not going to offer you to buy it. This mechanism was created only for two large customers who shared the same code base. Create your own mechanism with the info below, jeez!
But seriously, AIM’s main goal is to AIM the usage of a certain object only to the user who created it, or have access to it.

This is being done by holding a database table especially for sensitive objects that could be targeted from the web clients.
When an object is being inserted to the table, the mechanism generates to it a special 32 chars long identifier. This identifier is only being used by the server, and it is calld SUID (Server Used ID). In addition, the mechanism issues a 15 chars long integer identifier for the client side that is called, of course, CUID (Client Used ID). The CUID integer is being made from part of the 32 chars long SUID and part of the object permanent details (like name-if name cannot be changed afterwards) using a special algorithm.

In the users’ permissions table there is also a row of list of nodes that contains the SUID of objects that the user has access to it.

When the user issues a request from the client side (from the JS – a simple HTTP request (POST/GET/OPTIONS/DELETE/PUT…), the CUID is being matched with the SUID – the algorithm tries to generate the SUID from the supplied CUID. If it succeed, it then tries to match the generated SUID the SUIDs list in the users’ permission table. If it match, the requesting user gets one time, limited access to the object. This one time access is being enabled for x minutes and for one static IP, until the next process of matching CUID to SUID.

All this process, of course, is being managed by only one mechanism – The AIM. AIM handles request in a queue form, so when dealing with multiple hundreds of requests – AIM might not be the perfect solution (due to possible object changes by 2 different users).

In conclusion, in order to keep your platform cure from IDORs, requests to access sensitive objects should be managed only by one mechanism. You don’t have to do the exact logic like we did and to compile two different identifiers to the same object, but if you’ll like to prevent IDORs from the first moment (simply spoofing the ID), our proposed solution is for the best.

Here are some more examples of IDORs found by FogMarks in some very popular companies (and were patched, of course):

And The King Goes Down


Tokens are great. Well, sometimes.

Today’s case-study will discuss the importance of a Token Manager software.
Well, every site which allows login normally will use a token on each of the ‘critical’ actions it allows users to do. Facebook, for example, automatically adds a token at the end of any link a user provide, and even their own links! This mechanism is called ‘Linkshim’ and it is the primary reason why you never hear about Facebook open redirects, CSRFs or clickjacking (yeah yeah I know they simply not allowing iframes to access them, I’ll write a whole case-study about that in the near future).
Facebook’s method is pretty simple – if a link is being added to the page – add a token at the end of it. The token, of course, should allow only for the same logged-in user to access the URL, and there should be a token count to restrict the number of times a token should be used (hint- only once).

But what happens when tokens are being managed in a wrong approach?

A very famous security company, which still hasn’t allowed us to publish it’s name, allowed users to create a team. When a user creates a team, he is the owner of the team – he has the ‘highest’ role, and he basically controls the whole team actions and options – he can change the team’s name, invite new people to the team, change roles of people in the team and so on.

The team offers the following roles: Owner, Administrator and some other minor non-important roles. Only the owner and administrators of the team are able to invite new users to the team. An invitation can be sent only to person who is not on the team and does not have an account on the company’s web. When the receiver will open the mail he will be redirected to a registration page of the company, and then will be added to the team with the role the Owner/Admin set.

When I first looked at the team options I noticed that after the owner or an admin invites other people to the team via email, he can resend the invitation in case the invited user missed it or deleted it by accident. The resend options was a link at the side of each invitation. Clicking the link created a POST request to a certain ‘Invitation manager’ page, and passed it the invitation ID.

That’s where I started thinking. Why passing the invitation ID as is? Why not obfuscate it or at least use a token for some sort of validation?

Well, that’s where the gold is, baby. Past invitation IDs were not deleted. That means that invitations that were approved were still present on the database, and still accessible.

By changing the passed invitation ID parameter to the ‘first’ invitation ID of the Owner – It was possible to resend an invitation to him.
At first I laughed and said ‘Oh well, how much damage could it make besides spam the owner a bit?’. But I was wrong. Very wrong.

When the system detected that an invitation to the owner was sent, it removed the owner from his role. But further more – remember that I said that sending an invitation sends the receiver a registration page according to his email address? The system also wiped the owner’s account – his private details, and most important – his credentials. This caused the whole account of the owner to be blocked. A classic DoS.

So how can we prevent unwanted actions to be performed on our server? That’s kind of easy.
First, lets attach an authenticity token to each action. The authenticity token must be generated specifically and individually to each specific user.
Second, like milk and cheese – lets attach an expiration date for the token. 2 Minutes expiration date is the fair time to allow our token to be used by the user.
And last, lets delete used tokens from the accessible tokens mechanism. A token should be used only once. If a user has got a problem with that – generate a few tokens for him.

For conclusion,
This case-study presented a severe security issue that was discovered in the code of some very famous security company.
The security issue could have been prevented by following three simple principals – 1) Attaching a token to each action that is being performed by a user. 2) Setting a rational extirpation time for each token. 3) And most importantly – correctly managing the tokens and deleting used ones.

Should We Blame The Diet Coke Smuggler?


Everyone use user-controlled parameters. This is, as far as I concerned, the easiest way to create an effective http negotiation process. It means that in order to ease the interaction process between the site and the user, the site allows the user to tell him about essentials parameters that are needed for the next interaction. Even while this post is being written, after I’ll click ‘Publish’ a lot of POST parameters will be sent to the server and will be processed.

As you might have already guessed, today’s case-study will highlight the huge disadvantage of allowing users to ‘tell you what to do’.

Basically, I don’t believe in POST or GET. I know its sound funny or stupid, but when I see that so many security breaches were launched using a GET or a POST requests, I cannot live with that comfortably. I know that GET and POST are ‘just the messenger’ and it will be like blaming an innocent person who was used to smuggle diet Coke into a movie theater.

But I think that we all forgot one important thing – GET and POST are not alone. HTTP, especially on its latest version (and the next version) supports other request types. Like what? PUT, DELETE, OPTIONS. Those requests were made for a reason, and almost none of the latest players on the dev market are using them. Why? Because its not easy, and its not ‘widely used’. That idiotic term I heard a few days ago on a developer conference I participated. People kept explaining that a certain technology should not be used because “it is not widely used, and therefore there is not enough support or security research and maintenance”. And again – why exactly shouldn’t I use a unique software that no one else does? Why should I count on our security community to alert me whenever a software I’m using is breached?

As for HTTP requests, GET and POST are what I call ‘deprecated’. Too much companies and too much software use GET and POST requests with dozens of parameters to ‘get things done’. This is exactly the reason why XSSes vulnerabilities, along with IDORs and CSRFs, are being successfully executed – Websites use too much parameters and the developers, at some point, aren’t able to track the software’s behavior under certain conditions – from a general use by a client to an aggressive security research by professionals. That’s just the way it is. Another reason for security breaches is that websites count that the user will return them the parameters they expect, and if the user returns only a few parameters, some server side actions that are being executed by the missing parameters are not being executed, resulting in a security vulnerability.

Now, should we cry and bury GET and POST? No, of course that there is a way to keep using GET and POST and still be safe. All you have to do is to not blame the diet Coke smuggler, and to follow these 5 rules:

  1. Minimize the number of parameters that are being used. More parameters = more security breaches possibilities.
  2. Know exactly the purpose of each parameter.
  3. Know exactly what type of data each parameter should hold.
  4. Know what happens when each parameter is given the wrong type of data, or is MIA.
  5. And the most important thing – use all of the parameters! I can’t count the number of times a security breach was successfully launched because of a lack of using all the parameters. In fact, I’m writing these days another case-study about a Facebook security vulnerability just about that.

As for a finish, I’ll just drop this tiny note: FogMarks is looking nowdays for some new challenges. If you think you can interest us with something, simply DM us on Twitter (and make sure your’e following us) or send us an email on contact@fogmarks.com.

How Private Is Your Private Email Address?


After reading some blog posts about Mozilla’s Addons websites, I was fascinated from this python-based platform and decided to focus on it.
The XSS vector led basically to nowhere. The folks at Mozilla did excellent job curing and properly sanitizing every user input.

This led me to change my direction and search for the most fun vulnerabilities – logic flaws.

The logic flaws logic
Most people don’t know, but the fastest way to track logic issues is to see things logically. That’s it. Look at a JS function – would you write the same code? What would you have changed? Why?

Mozilla’s Addons site has a collections feature, where users can create a custom collection of their favorite addons. That’s pretty cool, since users can invite other users to a role on their collection. How, do you ask? By email address of course!

A user types in the email address of another user, an ajax request is being made to an ‘address resolver’ and the ID of the user who owns this email address returns.

When the user press ‘Save Changes’, the just-arrived ID is being passed to the server and the being translated again to the email address, next to the user’s username. Pretty wierd.

So, If the logic, for some reason, is to translate an email to an ID and then the ID to the email, we can simply interrupt this process in the middle of it, and replace the generated ID with the ID of another user.

The following video presents a proof of concept of this vulnerability, that exposed the email address of any of addons.mozilla.org users.

Final Thoughts
It is a bad practice to do the same operation twice. If you need something to be fetched from the server, fetch it one time and store it locally (HTML5 localStorage, cookie, etc.). This simple logic flaw jeopardized hundreds of thousands of users until it was patched by Mozilla.

The patch, as you guessed, was to send the email address to the server, instead of sending the ID.

Facebook Invitees Email Addresss Disclosure

Prologue

When Facebook was just a tiny company with only a few members, it needed a way to get more members.

Today, when you want more visitors to your site, you advertise on Facebook, because everybody is there.

Back than, the main advertising options were manually post advertisements on popular websites (using Google, for instance), or getting your members invite their friends using their email account.

Facebook’s Past Invitation System

When a user joined Facebook at its early days, there was literally nothing to see. Therefore, Facebook asked their members to invite their friends using an email invitation that was created by the registered user.

The user supplied his friends email addresses, and they received an email from Facebook saying that ‘Mister X is now on Facebook, you should join too!’.

Fun Part

As I came across this feature of Facebook I immediately started to analyze it.

I thought it would be nice to try and fool people that a user Y invited them to join, although the one who did it was the user X.

As I kept inviting people over and over again I have noticed something interesting: each invitation to a specific email address contained an invitation ID: ent_cp_id.

When clicking on Invite to Facebook a small windows pops up and shows the full email address of the invitee.

I wrote down the ent_cp_id of some email I would like to invite, and invited him once.

At this point I thought: “OK, I have invited this user, the ent_cp_id of him should not be accessible anymore”. But I was wrong. The ent_cp_id of it was still there. In fact, by simply re transmitting the HTTP request I could invite the same user again.

But the most interesting part of this vulnerability is the fact that any user could have seen the email address that was behind an ent_cp_id.

That means that anyone who was ever invited to Facebook via email was vulnerable to email address disclosure, because that invitation was never deleted and it was accessible to any user. All an attacker had to do next was to randomly guess ent_cp_ids. As I said, old ent_cp_ids aren’t deleted, so the success rate is very high.

Conclusion

When you are dealing with sensitive information like email address you should always limit the number of times that an action could be done. In addition, it is recommended to wipe any id that might be linked to that sensitive information, or at least hash-protect it.

Facebook quickly solved this issue and awarded a kind bounty.