Attacking Aura - Beyond getItems

December 2024, by Andrew Schoonmaker

Before we start

You might have already read the enumerated.de article. If you havent, go read it! There is some foundational knowledge that is well organized there. Including a primer on lightning, aura, apex, FLS, etc.

Intro

This article seeks to build on those foundations and present a new workflow for testing. Everyone is talking about dumping Salesforce objects. Additionally, most people are talking about unauthenticated scanning. In my experience these paradigms miss the juiciest finds.

For the record, I am absolutely interested in unauthenticated issues, as we are usually talking about massive lead and pdf dumps on some forgotten site, or maybe some school forgot to unshare the contacts on the student registration portal and now a bunch of FERPA protected records are spewing social security numbers and birthdays. Better yet, it’s a medical institution and now you’ve got HIPAA problems and I’m keeping legal in business because I reported it and GRC missed it.

But let’s face it. Authentication is the gateway to all things wonderful. It is unfortunate that so many companies put up a “security boundary” of vetting only customers with a big credit card into their support community. The stuff behind that Okta tile is what you’re paying through the nose for and might subsequently be the reason you get impacted by a 3rd party breach (see cloudflare.) Similarly, SF Admins make the same mistake and get the guest user perfect and then are dropping the ball when it comes to the community user or their non admin employees.

In short, there are two main issues with the current object scanning paradigm:

  • Lack of authenticated visibility
  • Lack of field visibility

So lets assume we have an account. Maybe we spent $15 for an end user account, or we utilized the infostealer breach logs. Now how do we light the path and get visibility into fields?

But first, what are fields?

Think of Salesforce objects as records in a table. As you configure your org, you create custom objects, and add tables to your schema. These tables have columns and rows, where each row represents some sort record with attributes. These columns, or the attributes, are represented by fields in Salesforce. You can even add fields to standard objects. Most apps extend the base functionality by adding fields to one object or another.

But Wait, There’s More!

Of course, most users won’t be able to see these out of the box. Unless you’ve checked View All Data (DONT!) you will need to utilize a permission set or profile to configure access. Salesforce lets you granularly control these field visibility settings with Field Level Security.

A word on how SF presents FLS

https://trailhead.salesforce.com/content/learn/modules/data_security/data_security_fields

Unlike page layouts, which only control the visibility of fields on detail and edit pages, field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results. In fact, to make absolutely sure that a user can’t access a particular field, it’s important to use the field-level security page for a given object to restrict access to the field. There are simply no other shortcuts that provide the same level of protection for a particular field.

Plain and simple.

Email screenshot

Oh. It’s not simple. That’s why we created AuraQL. Check it out, it might just save you a couple million in fines when some guy in Bosnia figures out how to make cirrusgo work with a subdomain crawler.

Let’s recap:

Salesforce has a feature to restrict field level security on a per object per permission set basis. Companies repeatedly miss this and opt to simply configure a page layout. Scanners only use the default layout. But what does this mean?
Consider the organization has done their best. They’ve locked down the page layout. You run getItems and get back a list of users. But no one cares. It’s just a user list in a community. The nickname is obfuscated, other fields like CreatedDate don’t really get you anywhere.

Enter: getObjectInfo

One of the easier ways to extract fields is to use the getObjectInfo method. There are some other ways like with FieldDefinition and some other payloads to describe the record, but this is the most reliable. Obviously the records I’m talking about have sensitive data, so do your best to handle with care.

{
  "actions": [
    {
      "id": "222;a",
      "descriptor": "aura://RecordUiController/ACTION$getObjectInfo",
      "callingDescriptor": "UNKNOWN",
      "params": {
        "objectApiName": "OBJNAME"
    }
    }
  ]
}

Show me the way!

By incorporating field visibility into the workflow, we can better understand the object we are working with. Is it holding sensitive data beyond the norm? Cough cough ^.*__c$
You never know what might be hiding.
An email address? A mailing address? A birthday? A social security number? An integration’s api token?

What now?

Scale Up!

{
  "actions": [
    {
      "id": "222;a",
      "descriptor": "aura://RecordUiController/ACTION$getRecordsWithFields",
      "callingDescriptor": "UNKNOWN",
      "params": {
        "recordIds":["record"],
        "fields":["fields"]
    }
    }
  ]
}

You know a record id, but it doesnt stop there. You are being tricked. Don’t get fooled. Understand the object. Understand what you can and cant read. Understand what you shouldnt be able to read.
Finally, how do you know the record id? Record Ids are not a security boundary, they are just a number… enjoy.
https://help.salesforce.com/s/articleView?id=000385008&language=en_US&type=1
I normally give an exact count of the leaked objects in my reports just to blow people away and show them I mean business.

Turn this default username field Default username field

Into this

Into this

And this custom field

Into this

Into this

Into this2

And finally, the hed__ college issue I mentioned:

College issue

Notice things like mailing address and email aren’t there… boom. Sweet home Alabama alright.

Boom! Sweet home Alabama