blog
    Hunting for Mass Assignme ...
    14 October 22

    Hunting for Mass Assignment

    Posted byPentester Academy
    facebooktwitterlinkedin
    news-featured

    If there is nothing preventing users from touching sensitive data, eventually an attacker will do so! This article shows you how to develop an intuition for Mass Assignment and exploit it like a pro.

    Introduction

    API Security is quite different from Web App Security! And this difference is profound and led to the creation of OWASP Top 10 for API Security exclusively.

    Why? Because we are seeing a shift towards API world due to the uniformity and the structure that it provides.

    This approach of developing applications using APIs makes them interconnect with each other in ways we weren’t able to imagine in the pre-API world.

    But as you can already imagine, what used to be internal is now exposed and this comes at a cost! And thus we come to Mass Assignment — an issue that happens quite a lot in APIs.

    What is Mass Assignment?

    0_NdrpE_5pAd7b5g5V.png

    Reference: https://andyinfosec.medium.com/owasp-api-top-10-part-2-4ec9f3f0f011

    Mass Assignment occurs when an API takes user input directly and maps the values passed by the user to the backend object models.

    What’s wrong with that?

    If there are sensitive fields in the data models like isAdmin, isPremiumUser, isASubscriber, etc, a malicious party who controls these values can wreck havoc! They could make themselves an admin/premium user/subscriber and (mis)use the product or service — not an ideal situation.

    Why does Mass Assignment happen?

    Oh that was intern’s mistake…

    Really? Nah… Let’s discuss the actual reasons!

    Let’s face it — developers are lazy! Many rely on a lot of frameworks and boiler-plate code. Any method that makes their tasks easy, finds its way into their code.

    Frameworks and programming languages help developers map user requests to object mapping just using a one-liner! As developers, we love the convenience but that’s what leads to this vulnerability in the first place!

    This is the reality of development work — not something I made up, but something I have experienced myself while I was a developer. It’s so profound and second-nature to the developers! If you are one, or have been there, I am sure you would have that smile on your face :)

    Mass Assignment is a cool bug that can get you a P1, if you are into pentesting or bug bounties! It’s not that common and that’s why it’s holds a 6th position in the API Security Top 10 list.

    Case Study: Mass Assignment Exploitation in the Wild

    While keeping up on API Security, we came across this interesting post, which demonstrates a methodology to perform mass assignment, which aligns with our own, so it’s worth sharing: https://galnagli.com/Mass_Assignment/

    Pentesting Methodology

    The researcher had 2 accounts — 1 with higher privileges and one with lower privileges. He then made profile updation requests to an endpoint and observed the parameters being passed in both the accounts — unprivileged and privileged.

    This gave him a hint that there was an extra parameter in the API requests which was sent in the privileged user’s profile update request.

    So the next natural step was to try setting the same parameter in the unprivileged user’s profile update request, and voila! That resulted in giving the unprivileged user privileged access! Bingo — that was Mass Assignment in action.

    In our experience, we have also seen that sometimes the response to the updation requests reveals such parameters as well, and thus those should also be looked at while hunting for this vulnerability.

    If none of these 2 tricks work, then try to use a fuzzer that injects various commonly used parameters in the request and see if the response contains anything interesting. This can definitely take you a long way ahead!

    How do I prevent Mass Assignment?

    Fire the intern?

    Nah… Let’s get to the real prevention steps!

    It’s simple enough! Maintain a safelist of the properties that you are expecting in the request and either reject extra properties or reject request with extra parameters altogether (with optional logging for log analysis later on…)

    You can even mark the properties that you wish not to be updated as readOnly in the schema and thus any write operation would either silently fail or alert you.

    This way, the restricted properties won’t be updated and this issue would be avoided!

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo